『Developers Summit 2012』2月17日(金) - 2日目メモ

今更ながら、『Developers Summit 2012』2月17日(金) - 2日目メモ。




17-C-1 Business Model generation

◆ビジネスモデルとは

・全ての（会社だけではなく、NPOやその他のものも含めた）組織が持っているもの。

・組織がどう回っているのかを書いたもの。

・誰の為にどのような価値を生み出しているのかを表現するもの。

◆ビジネスモデルキャンバス

・これにビジネスモデルを記述する。ビルディングブロックで構成される。

・コンサルタントや管理職だけではなく、一般の社員も理解できるもの。

・これを使えば、この中の共通の言葉で話すようになるので、非常にパワフル。

・組織というとより、事業のモデルを記述する為のもの。

ただし、組織の分析や改革にも使用できる。

◆ビジネスモデルを変更したい場合

・キャンバス内のオブジェクトを動かし、その際の影響を考える。

◆ビジネスモデルキャンバスと、その構成要素（ビルディングブロック）について。

・収益と支出について、キャンバスを2分する。

収益と、それを生み出す構成要素が右側。

支出と、それを作り出す構成要素が左側。

◇収益に関するビルディングブロック

・レベニューストリーム

　これらがうまく繋がれば、収益の流れが生まれる。

　収益を生み出す構成要素

・カスタマ

　最も重要な顧客だけを書く。

・バリュープロポジション

　顧客にもたらす価値。サービスそのものではない。

・チャネル

　顧客との接点。マーケティングの5Pと同じもの。

・カスタマリレーション

　コミュニケーションの手段。

　どれだけ自動化されているかが重要。

　新規顧客と既存顧客のどちらを重視するのかという優先順位がはっきりしていることも重要。

◇支出に関するビルディングブロック

・コストストラクチャ　ビジネスを回す為に必要な支出。

　支出を生み出す構成要素

・キーリソース

　モデルを回す為に必要最低限のものだけ。

　それが無くなったら、即座に業務が止まるようなものを書く。

　例えばgoogleなら、キーリソースは社員ではなくプラットフォーム。

　googleのサービスに繋がらなくなれば、その瞬間にビジネスモデルは成り立たなくなる。

　社員が全員いなくなったとしてもすぐに収入がなくなるわけではない。

・キーアクティビティ

　毎日BPをつくり、カスタマとコミュニケーションする為のもの。

　普段当たり前にしていること。

・キーパートナー

17-C-2 仕事のバトン、渡っていますか？ - プロジェクト管理におけるコミュニケーション基盤作り

◆waterfall or agile

・パッケージ開発など、見積もりが効くものはウォーターフォールがよい。それ以外はアジャイルの方がよい。

◆excel or チケット

・まともなプロジェクトかつ、時間軸が不安定なタスクばかりならチケット駆動開発がよい。

タスクの前後関係が見えなければいけない or 安定しているならexcelで管理するのがよい。

◆課題管理について

・まずは時間管理ができていなければならない。

・切り出したタスクの中で、それでも不確定なものを課題管理システムで管理する。

・情報公開範囲との兼ね合いがあるので、Q&Aやバグなど機能毎に切り分けること。

・リーダーがタスクを割り振ること。

・計画的な（繰り返して行う）ものには使わない。

◆課題管理表のデザインのポイント

・タスクを階層化しすぎない

・複数のコミュニケーションツールを併用せず、一本化する

（電話での依頼はexcelに書き、メールの依頼はnotesに書く、みたいな使い方は駄目）。

◆課題管理表の書き方のポイント

・誰がクローズするのかを決める。

・言葉使いには気をつける。

・事実のみを書かせる。

17-A-4 Scrumで組織改革

◆はじめに

市場・会社が急拡大している。人を増やしているが、次のようになっていた。

◇経営

・業務遂行の質やスピードが上がらない。

・意味のあるアウトプットが増えない。

・スケールする為の取り組みがない。

◇現場

・周囲や自分のしていることが分からない。

このような課題を自己解決できるような会社にしようと考えた。 

◆仕事の現状

次のとおり。

◇スケジューリングが困難

・案件が突発でやってくる。

・状況認識できない。

・今が忙しい。

・タスクが多い。

・優先順位がついていない。

◇責任範囲が不明瞭

・可視化できていない。

◇課題・問題が放置される

・目先の仕事もそうでない仕事も、価値はどのくらいかを図る必要がある。

・目先はアウトプットの価値が図りやすい。

・結果として目先の仕事ばかり処理される。

スクラムなら解決できそうだと思われた。 

◆1回目

◇やってみた結果

・スプリントで優勢順位が付いた

・なんだかんだで、スクラム外の仕事もせざるをえない。

・ツールなどが意図したとおりには機能しない。

・リリース品質に近づかない。

・助け合うマインドができた。

・大きな問題が後回しになった。

・バックログが増えていく。

・明確化や意思決定が遅れた。

◇振り返り

・問題の可視化・共有ができる。

・スプリント毎に成長する。

・スクラムは難しい。

これなら課題を解決ができそう。

◆2回目

◇したこと

・開発者を一箇所に。

・スクラム前に1週間ほどスプリント0を行なう。

・ミッションの明確化。

・責任分割。

・優先順位。

・バックログを作成。

・ツールを整備。

◇振り返り

・タスクをストーリー化したが、意思決定で迷う状況があった。

・振り返りを嫌うチームがでてきた。

◇この段階での結論

・スクラムを知らない（理解が浅い）人にただ行わせるのは逆効果。

・スクラム意外の方法で解決すべき問題がある。

・スクラム自体は有効。

◆3回目

◇ 行ったこと

・各チームにアレンジしてもらった。

・突発の対応を許可した

・大規模な開発に適用した

・チーム内メンバーの入れ替えをした

・業務改善に適用した

・スプリント0の前にプレプランニングをした。

・スクラムマスター会議をした。

・チームを超えた共通なルールを作った。

・チーム毎の個別のルールを作った。

・エピックというストーリーの上位概念を入れた。

現在実施中。

◆結論

・組織間のコミュニケーションが増えた。

・自己解決するように組織化された。

・メンバーが自分からやりたいことをするようになった。

Tim Clark様、今津 美樹様、鈴木 雄介様、貝瀬 岳志様、お疲れ様でした。