内容
期待マネジメント
不確定要素が多くて、難易度が高いプロジェクトであればあるほど、「期待マネジメント」に取り組む必要がある。
具体的には、「二つの期待」をマネジメントする。
①内側の期待：チームにおける期待
②外側の期待：プロジェクト関係者における期待
内側の期待と、外側の期待は両輪と考えて欲しい。
4つの質問
①自分は何が得意なのか？
②自分はどうやって貢献するつもりか？
③自分が大切に思う価値は何か？
④チームメンバーは自分にどんな成果を期待していると思うか？
スキルマップ
（誰）：誰がどんなスキルを持っているのか？
（何）：何を誰にどれくらい任せることができるのか？
（支援）：どの作業に誰の支援が必要なのか？
（リスク）：チームとして足りない要素は何か？
（成長）：チームとして手薄で強化したいスキルは何か？
（育成）：個人として長期的に成長したいスキルは何か？
そんなときに活用したいのが星取表だ。
星取表（スキルマップ）とは？
星取表（スキルマップ）とは、チームのメンバーがどのようなスキルを持っているかを見える化して、俯瞰するための道具だ。
横軸にはプロジェクトで必要なスキルを並べ、縦軸はメンバーの名前で構成される。
その中にメンバーのスキルの習熟度合いを 5段階で書き込んでいく。
例えば、こんな感じだ。
☆：エース級
◯：一人前
△：ヘルプが必要
↑：習得希望
─：できない
チームビルディング三種の神器
□インセプションデッキ：プロジェクトやプロダクトの目的や方法論
□ドラッカー風エクササイズ：チームメンバーの価値観
□星取表：目的を達成するために必要なスキル
モブプログラミング
モブプログラミングは、みんなで一つの画面を見ながらワイガヤでプログラミングするんや。
＜方法 ＞
□チーム全員が1カ所に集まって、全員で同じ画面、一つのPCで作業する
□ PCを操作できるドライバーは一人、他はナビゲーターとして頭脳になる
□ナビゲーターはドライバーに指示する
□全員が交代でドライバーをする
□ドライバー役は10分くらい（時間で交代せず流れに任せても構わない）
□一つのテーブルに5人前後が望ましい
モブプログラミングのメリット
メリットは大きく分けると4つある。
①プロセスフロー効率性
②コミュニケーションカイゼン
③学習効果
④達成感
リードタイムとプロセスタイム
局所最適化になってしまわないようにすることだ。
「プロセスタイム」を短くすることにのみ集中しても、価値を生み出す流れ全体の「リードタイム」の削減には効果が薄い場合がある。
□プロセスタイム：事実上そのプロセスを実行している作業時間
□リードタイム：プロセスが次のプロセスに移行するまでの所要時間
業務改善の方法論
ECRSです。
ECRSは、Eliminate（排除）、Combine（結合）、Rearrange（交換）、Simplify（簡素化）の英語の頭文字を取ったものです。
① Eliminate（排除）：必要な業務・プロセスなのか見極める。形骸化していないか？
② Combine（結合）：待ち時間のムダや過剰な作業分担がムダを発生させていないか？
③ Rearrange（交換）：順番を変更することで中間生成物ややりとりを削減できないか？
④ Simplify（簡素化）：複雑なタスクは本当に価値を生成しているのか？単純化できないか？
計画づくり
プロジェクトが進んで当初の計画の算段が狂い始めたとき、実行不可能な計画にコミットしたままにするよりも、新たな学びや獲得した知識を計画に適応させ、価値の提供に注力していきましょう。
当初の計画を変更せず済むプロジェクトは皆無でしょう。
計画とはその時点でわかっていることをベースにした単なるスナップショットでしかありません。
計画ではなく、計画づくりをしましょう。
活動そのもの、過程そのものに価値があるのです。
変更があるのは何かを学んだ証です。
当初の計画に固執せず、学んだ証を計画に反映させましょう。
パーキンソンの法則というのがあります。
仕事の量は完成のために与えられた時間を満たすまで膨張する、という法則です。
CCPMとは、各タスクには個別のバッファを持たずに抑えた見積もりをして、全体としてのバッファを持ってプロジェクトを管理する方法です。
個々のタスクが遅れた場合、この全体バッファであるプロジェクトバッファから消費していくという考え方です。
プロジェクトというのは非常にたくさんの種類の不確定要素を持っています。
その不確かさに対するバッファなので、いくら時間をかけて精度を上げようとしたところで限界があります。
プロジェクトバッファを消費したときに、バッファを使ったことを責められない場づくりが必要です。
アーキテクチャと組織
コンウェイの法則にあるように「アーキテクチャは組織に従う。組織はアーキテクチャに従う」のです。
かつては小さい組織だったのにもかかわらず、プロダクトの成長とともに人員が増加して、専門性に特化した組織に分割されていきます。
まさに組織はアーキテクチャに従うのです。
分割が進むと、自分のオペレーションだけをやっていけば仕事が回るようになります。
成熟していけばいくほど、この傾向は強くなるのです。
同時に、組織の壁でコミュニケーションが減っていくのです。
同じプロダクトを扱っているにもかかわらずです。
すると、アーキテクチャは個々の組織で増強を始めます。
今度は、アーキテクチャは組織に依存するようになるのです。
デイリーカクテルパーティー
デイリーカクテルパーティーでは、ミーティングが3階層になっています。
一つ目は、各機能開発チームで行うスタンドアップミーティング（本書でいう朝会にあたります）。
その後に開催されるのが、テスターや、アナリスト、各機能開発チームのチームリーダーがそれぞれ集まる専門担当者によるミーティング。
機能開発チームのミーティングに参加している専門担当者もいるため、それぞれの開発の現場で起きていることを共有できます。
最後に、各専門担当者やプロジェクトマネージャーが横断的に集まり、プロジェクト全体を俯瞰するミーティング。
このミーティング参加者は、ここで行われるプロジェクト全体に関わるような大きな意思決定を各機能開発チームに展開する役割も担います。
この3階層を通じて、例えばある機能開発チームで起きている問題を拾い上げ、専門担当者が検討したり、プロジェクト全体として手を打ったりすることができるようになるわけです。
ギャレットの5段階
□表面（ Surface）：視覚的デザイン
□骨格（ Skelton）：インフォメーション・デザイン／ナビゲーション・デザイン／インターフェース・デザイン
□構造（ Structure）：インフォメーション・アーキテクチャ／インタラクション･デザイン
□要件（ Scope）：コンテンツ要求／機能要件
□戦略（ Strategy）：ユーザーニーズ／サイトの目的
面白かったポイント
着眼点はいいのだが、「ザ・ゴール」のようにもっと面白いストーリは作れると思う。
満足感を五段階評価
☆☆