アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン [プログラミング]
抽象化は人間だけのものだが、パターン認識はそうではない。
飼い犬だって週末のお出かけの前兆をかぎつける。
でも、パターン認識の先、「ああ、またアレだ！」といいう気づきは動物にはやってこない。
パターンは時間をかけて吸収され、洗練され、精神の奥深くへしまいこまれ、直感という形であらわれる。
それだけでも価値はあるが、じっくり考えそこから明確な知見を導き出せればその価値はずっと高くなる。
右脳の直感と左脳の言語が結びついたとき、本質をとらえて言葉にすることができる。
言葉があれば、書き留めたり、他の人と共有したり、他の人の知見と融合させたりできる。
この本は150年にわたって吸収してきたパターンを6人の人間が文章にしたもの。
順番は特に意味はない。楽しく読めるようには工夫した。
必ずしも読者の組織にあわないかもしれないが、以前は直感に過ぎなかったものをチームの知見にする手伝いになるとうれしい。
よく考えられた抽象化はどのような題材でもわかりやすく人に伝えることができる。
１ アドレナリンジャンキー
みんなが猛烈に必死に働いている、いつも緊急で重要な仕事でいっぱいだ。でも生産性をたかめる本質的に重要なことは緊急はないので置き去りだ。だから生産性はいつまでもあがらないし、少人数で必死に働いてなんとかなる範囲のものしかつくれないので、大きなプロジェクトは行えない。
こうした組織の特徴は、優先順位が絶えず変化すること。いつも「きのう」必要だという。
２ スピード勝負
スピードの速いチームは、議事録が届かないうちに決定した行動経過のうち1項目めか2項目めが終わっている。
もしかして、会議中にインスタントメッセージで問い合わせ、会議が終わるまでに報告できるかも。
速いチームは強いチームで、以下のような文化をもっている。
・本能的に切迫感をもっている。
・個人とチームの能力に絶大な自信をもっている
・反復に価値があると信じている・・・間違ってもいい、修正するから。
弱いチームの会議はトークショーである
・完璧な情報をもとめる・・・それが得られるまで何一つ決まらない
・なんでも「保留」しただる・・・決定や行動を後回しする理由をさがしている
・左かっこのオンパレード・・・思いつきで会議が進む
・キャンプファイヤーを囲んでおしゃべり・・・組織の過去や現在についてとめどもなく語る
・すべの道は設計に通ず・・・アーキテクトや開発者の力がつよいと設計議論におちいりやすい
・次の会議の予定をたてるための会議
３ 死んだ魚
時には手ごわいプロジェクトに挑戦して、譲歩する前に精一杯の努力をするこも必要だ。
しかし、最初から納期にまにあわないとわかっているのにそのままプロジェクトをすすめ、「一生懸命がんばったのにできなかった」というのが文化なら問題だ。
死んだ魚＝最初から納期にまにあうとだれも思っていないプロジェクト
４ 幸福礼賛会議
時間も労力もつかわずに士気が高くなる方法として使われることが多い。
全員が参加して上司が「問題があればなんでもきかせてください」というが、実際に厳しい質問をすると後で叱責される。求められているのは意見ではなく賛同。
それは間違いなく幸福礼賛会議。
５ 乳母
良いプロジェクトマネージャーはイギリスの乳母と共通するスキルをもっている
乳母は子どもを守り、運動させ、外の世界で生きていけるように教育する。環境をととのえるのだ。
良いマネージャは、開発者が雑用にわずらわされないように気を配り、必要な情報を伝え（ウワサ話の時間が減る）、機材や職場環境をととのえ、コミュニケーションの時間（朝のコーヒー会や、金曜午後のブックレビューなど）を用意する。自分を支援者ととらえて、メンバーが役割をこなし、生産性が高まり、自分の仕事に満足してくれることを喜びとする。
この反対は、マネージャーの関心が社内での駆け引き、出世にあり、チームと話をするより、PERT図やガントチャートをつくったり手直しするのが大事、あるいは開発にかかりきりである。
６ 関連痛
関連痛・・・原因箇所ではない身体の部分に痛みがあらわれる状態のこと
プロジェクトを立ち上げるときに、目に見える問題に目をうばわれて、肝心の問題が解消できないことがある。
また、使い慣れた技術でなんでも解決しようとして、最適でない技術を使ってしまうこともある。
回避策を多用しないといけない状況が続くなら、関連痛にかかっている可能性が高い。
本質を解決するのは困難だが、見返りは大きい。
７ マニャーナ
マニャーナ・・・スペイン語で「いつかそのうち」
たいていのプロジェクトは人間の切迫感の時間枠（30-90日）より長くかかる。だから30か月後の納期に切迫感を感じることはない。
こんなときはメンバーの意識を時間枠に集中させるために90日あるいは30日以内に成果物を仕上げるように指示をだす。もちろん本当のゴールに向かうために必要なものでなくてはならない。
あと、50％など判定が難しい設定は切迫感がでにくい
また作業やテストの用のツールを必要以上に探し回るなども、たちの悪いマニャーナだ。
８ アイコンタクト
フルタイムの熱心なプロジェクトメンバーが1か所に集まると、ある種の奇跡が起こる。息をあわせるには物理的に近くにいる必要がある。
緊急かつ複雑ならば、要因は同じ場所に配置すべきである。
９ ムードリング
結論のない進行形の活動ばかりに注目するプロジェクトマネージャーは、自分たちが最終的に何を達成しようとしているかわかっていないことが多い。
こういったマネージャの報告の特徴
・感情や熱意に重点がおかれ（がんばっています、間に合わせるべく努力しています）
・現在に集中している（全体のどこではなく）
・計画通りにすすんでいないことには感情でかたる（少々心配です）
・結論がなく進行形で語る（あといくつかの機能もすぐに完成させてくれるにちがいありません）
・マイナス要素にはふれるが全体的に楽観的
なにをすべきかわかっているマネージャの報告の特徴
・作業内容、成果物の状況によって評価する。
・中断、問題、計画変更に注目、必要な修正と決定項目を明示
・だらだらせず区切りがある
・客観的情報と判断的要素のバランスがとれている。
ほとんどのマネージャは上と下の中間。上の要素が多くなってきたら、自分を修正しよう。
１０ 信者
特定の技術を信奉しなんでもそれで解決しようとするひとがいる。
しかし、どの手法やツールにも限界がある。
異なる教義の信者が争いを起こすと収集がつかなくなる。
「異なるプロジェクトには異なる方法論が必要である」 アリスター・コーバーン（アジャイルソフトウェア開発）
１１ 魂を貸す
一流のプロは魂を貸しても、売らない。
確立された個人やチームの技能を問題にあてはめるのではなく、問題に合わせた解決策をさがそうとする。
慣れ親しんだやり方を、いつでも捨てる勇気があり、かつ流行りの方法に安易にのらない。
大事なのは「この技術は何に適しているか」であって「どうしたらこの技術でこの問題を解決できるか」ではない。
１２ レミングサイクル
プロセス改善プログラムの一環として、開発プロセスの社内基準をもつ企業は多い。
しかしなにがなんでも標準プロセスを守ろうとすると、いらない仕事を増やしていることも多い。
万が一失敗した場合、標準プロセスを守っていなかったからだといわれる。
またどのプロセスを削るべきか検討する時間が惜しい。
このような理由でやみくもに標準プロセスに従うのは、厳格にレシピを守る料理人のようなもので、優れた料理人にはなれない。
１３ ベンチに人なし
組織をスリム化しすぎて、予備要員がいなくなっていませんか？
プロジェクトの主要メンバーのだれにでもとってかわれる幅広い人物を一人か二人用意すべき。
コストはかかるが、プロジェクトにとって足りなくなるのはコストより時間のはずだから。
１４ フェイスタイム
小数精鋭チームの開発効率がいいのは30年もまえからいわれている。
今日なら、ここに「同じ場所で働く」がつくだろう。
しかし分散プロジェクトが普及して、難しくなっている。
それでもメンバーはできるかぎり会うべきだとして、その一般的ガイドラインをあげていた。
・サイト間の作業を担当する人（プログラムマネージャー、プロジェクトマネージャーなどの肩書）はリリースサイクルごと。3か月に1回では少ない
・開発者、QAエンジニア、テクニカルライターのなかなら、リリースサイクルに最低1回、各サイトのベテラン同士が顔をあわせるべき
・若手メンバーが他のサイトを訪れることで、自分たちの仕事の一や、他のサイトのベテランからの教育、評価がうけれることがある。
サイト間で、あそこは使えないサイトなどと序列ができたりするのは最悪。
１５ 「どうしてミケランジェロになれないんだ？」
「たがね」はミケランジェロが手にとらなければ、へりの鋭い金属片にすぎない。
ツールを導入しても、使いこなすためのスキルがなければ、生産性はまったく上がらない。
１６ ダッシュボード
車のではなく、プロジェクトやビジネスプロセスの状態を視覚化して伝える手段として普及したもので、各種指標を通常は図表と数値の両方で表示し、プロジェクトやプロセスの進捗状況を全体的に描きだす文書やWebページのこと。
トップレベルにはかくパフォーマンス指標の要約が表示され、ユーザーがそれらをドリルダウンしてさらに詳しい情報を見られるタイプのものがある。
ダッシュボードは強いチームが使えば役にたつが、弱いチームが使うと全く役にたたないどころか邪魔になる。
弱いチームがダッシュボードを使っているときの兆候
・赤は失敗を意味すると信じている。音がうるさいからと煙感知器をきっているようなもの
・橙は現実から目をそむけた赤である・・真実に向き合えないで、警鐘をならすことを避けたがる
・緑はあまり見るなという意味である。・・・ぎりぎりに突然赤になる。そこには赤だとダメだという文化がある
このようなチームは成功への情熱でなく批判への恐怖を原動力としている。
強いチームの有効なダッシュボートの特徴
・ダッシュボードを使ってもデータに圧倒されない・・・すべてを報告するのではなく、限られた指標を慎重にえらんで報告する
・ダッシュボードを抜粋・編集できる・・・どの情報をフロントページんに表示し、どの情報を3階層下に埋めるかを決める過程で、重要項目がはっきりする
・情報を示すだけでなく判断を促す・・・現状の報告だけでなく、判断を促すようになっている
・現状を反映するだけでなく未来を予測する・・・現状を報告するだけでなく、将来なにが起きて何がおきないか予測を示せる「バランス・スコアカードー新しい経営指標による企業変革」
・長期的なトレンドを示す・・・現在のスナップショットだけでなく、いままでの軌跡、黄色の前は何色だったのか？がｗかる
・チームが主観的な評価を報告しなければならないときに、比較をするための枠組みがある
色は主観であり、そうあるべきだが、定義はあるべきだ
緑＝順調で、修正はいらなそう 黄＝ただちに十分な修正措置をとる必要あり 赤＝プロジェクトは計画にほど遠い、ただちに変更措置がいる
成功する確率を高める為にただちに修正すべき天意チームの注意をむけることができる
１７ 永遠の議論
プロジェクトリーダーが、不満を述べるのを許している限り、決定に従わない人がでる。
こういう人は賛同するまで決定に従わなくていいと思っている。
組織として行動するなら、意見をきいて決定するまでの期間をきちんときめて、いったん決まったら賛同していなくても決定に従うという文化が必要である。
そうでなければ永遠の議論が続くことになる。
１８ 子犬と老犬
組織に一定以上の若者がいると、そこはみながよく働き、明るくくつろいだ雰囲気で、いい意味で「楽しい」職場になる。若い人々は高揚感がある、これからスキルを身につける最中で、次第に成長を実感し、いい仕事がしたいと思っている。それにつられて老犬も若返る。
老いぼれ犬ばかりの組織になってしまうのは
・組織が成長していないため、若者を雇う機会がほとんどない・・・政府機関のような場所に多い
・組織が経験者だけ採用することにしている・・・XMLの経験15年！
・組織が徹底的に冒険を避けている
パートタイムでいいので若者を起用しよう。
１９ 映画評論家
プロジェクトの成功とは別の成功を目指している人。
プロジェクトが終わりに近づいたとき、プロジェクトの間違いを指摘したりする、あくまで指摘するだけで、修正方法などは言わない。
プロジェクトは失敗しても、自分は成功できると信じていて、事実上黙ってプロジェクトチームから分離している。
この映画評論家が生まれやすい組織は、経営者の文化として間違いを犯さない文化をもっている。ひとの間違いを指摘せよと組織にシグナルをおくるので、参加しているプロジェクトに対して他人事のように映画評論を行う。
そういう人を許容すると、責任あるリーダーやメンバーになるより映画評論家になるのは簡単だから増えることになる。
プロジェクトの成功を目的としない人が参加することで、誰の努力も実をむすばない、逆効果になる場合がある。
２０ 一人一役
一人一人が責任をもち、その責任がどういうものかを理解していることが、人々のやりがいになりチームとして力を発揮する。
一人で責任を引き受けたから、同僚や関係者に協力を求めたり、必要な意見を得たりしてはいけないということではない。
すべを全員の責任にしたら、全員があらゆることを心配し、どれ一つうまくいかない
閑話 プロジェクト言葉
このスケジュールは果敢です・・・おれたちはおしまいだ。
もうすぐ遅れは取り戻せます・・・やっぱりもうおしまいだ。
２１ ソビエト式
意図された機能ははたすが、やり方がまずい、いらだたしい。
あるいは使い勝手が悪い、見た目や雰囲気に魅力がない、必要な安全性に欠けているという利用する人に魅力を感じさせるという要求を満たしていない。
こんなソビエト式製品を作ってしまったことはないだろうか、こういったものは修正が異常に多いか、極端に少ない（使われないから）
優れたチームは、機能面以外の要求をシステマティックに引き出すことを重要なプロセスの一環と位置付け、これらの分野でユーザビリティモデルを構築し、スペシャリストを採用している。
プロトタイピングを行い、ユーザーに好まれる機能面以外の品質について有意義なフィードバックを集めることが重要
２２ 自然な権威
権威は、能力のある人に備わる。
大事なのは知識があってその分野をよく理解している人に相談し、権威ある人が判断すること。
階級が↑=権力のあるひとが、権威のある人を無視して判断をしてもうまくいかない。
沈黙は同意とみなされるので、あなたが権威のある人ならば、だまっているのは責任の放棄である。
しかし文化として権力が権威を無視する企業では、だれもそんなことは気にしなくなる。
２３ 静かすぎるオフィス
廊下歩くだけでソフトウエア開発チームのことはわかる。
チームのメンバーが目的をもって楽しそうに動き回っている職場は良いチーム
人々が家に帰れる時間を待ち、次の給料日を待ちながら、何かおもしろいことはないか、あるいは早く退職する日がこないか考えている職場は静かすぎる。
２４ 白線
システムやビジネスエリアは、データを変化させるプロセスで構成されている。
プロセスは属性セットを別の属性セットに変換し、データの状態を変えてからそれを次のプロセスへ渡す。
このようなプロセスとデータの集合体をかき、そこに白線を引くことでシステムのスコープが明確に定義できる。
２５ 沈黙は同意とみなされる
約束の誤解が起きるよくあるパターンは、要求に対して、沈黙でこたえること。相手は異を唱えなかったら同意とみなし、こちらはYesといわなかったらNoだと思っている。
これは双方にとっていいことはない。
これを避けるには、少数の重要な約束を公言し、文書化して、関係者全員に配ること。
そして「同意しなければ同意とみなされない」というルールを作ること。
２６ かかし
人は白紙から答えをつくることは嫌がるが、すでにあるものは平気で批判する。
だから、優秀なアナリストは「何をお望みですか？」とは聞かない。相手を不快にするから。
「かかし」のソリューションは、クライアントの望みを引き出すために提示される。最高の「かかし」は意図的に間違いを組み込みさえする。そうして最速でソリューションやデザインに近づくのだ。
早いうちに間違え、何度も間違えることが、できるだけ早く正解にたどり着く方法。
われわれが直面する問題は複雑すぎて、一人の頭ではどうにかすることはできないのだｋら、覚悟をきめて「これはどうだろう？」と聞いてみよう。それが有効な「かかし」になる。
２７ いつわりの緊急任務
リスクを取らないの間違いであることは理解されつつあるが、最初から失敗するとわかっている開発期間に挑戦するのはいつわりの緊急任務であって、リスクをとることではない。
いつわりのリスクを生み出すと、組織は本物のリスクに挑戦する機会を失う。
２８ 「時間」に切り札を奪われる
プロジェクトに影響を与えるのは、マネージャがごく早い時期に下した決定である。
早い段階での人員増加は、有効だが、のこり2か月の人員増加は失敗の可能性を高める。
機能を早い段階で絞り込むのは、重要なものを完成させるため。さもないと締め切り間際に完成間近な多くの重要な機能と、完成した小さなこまごました機能に直面して、何を先にリリースするべきかの選択肢はなくなっている（完成しているものをいれるしかないだろう）
優秀なプロジェクトマネージャは「時間」に負けないためにいつ切り札を切るべきかしっている。
２９ ルイス＆クラーク
1803年あめりかが五大湖と大西洋海岸の州だけで独立したあと、フランスから西の領土を買った。
1804年から1805年にかけて、ジェファソンの命で新領土の調査をおこなったのがルイス＆クラーク。
二人は何を見つけるべきか指示されなかった（できなかった）
プロジェクトの探検隊は抽象的な意味で仕事を調査する。しかし結果は必ず有益なものがみつかるわけではないことは承知しておくべき。しかし、有益なものがみつかれば、無駄な探索の分も十分カバーできる利益が得られるものだ。
３０ ちびた鉛筆
コスト削減が続くと、組織の競争力は落ちる。
最初のコスト削減では、利益が増えたことだけがクローズアップされるが、一時的なものであり、コスト削減が続けば組織はやる気を失い、やがて売り上げがおちていく。
１つくらいコスト削減プログラムを実施するのは賢明だが、さらにコストを削減しようとするより、自分自身の幸せを考えるべきた。
３１ リズム
リズムのあるプロジェクトは、巨大で複雑な仕事にひるむことなく、小さく規則的なステップを踏んでいくうちに、一定のテンポをきざんで目標へたどりつくことがでる。
そのとこを理解しているので、まず目標をきめ、通常は1か月で完了しそうな計画をたて、毎日あつまって進捗やアイデア質問をかわし翌日の計画をたてる。プロジェクトの目標、毎月の目標となる成果物、毎日のフィードバック会議が作業のリズムをつくる。人々がリズムと認識できればサイクルの長さは問題でないが、6か月以上になるとマニャーナが起きるので注意。
リズムのあるプロジェクトはリズムのないプロジェクトより短期間で役立つ製品をつくりだせる。個人個人が他のチームメンバとの約束を果たしているから。リズムにあわせて働くのは自己強化型の活動になり、健全な駆動力になる。
ただし、マネージャーが強制的にリズムをつくったり、リズムをあげたりしてはいけない。リズムはチームが作り出すものだ。
３２ 残業にみる予兆
若いマネージャは、部下が残業するのをみると、意欲の表れとみて喜ぶ。
追い込みの時期の残業ならいざしらず、早い段階の残業にはチームの恐怖があらわれている可能性が高い。
組織が恐怖の文化にとらわれいる場合のよくある原因
・恐怖によるマネジメント・・・トップから最下層まで恐怖で運営されている。やめるのをすすめていた
・コスト削減のための人減らしへの恐怖・・・首切りをかわせないかと長時間働く
・個人的な失敗に対する恐怖・・・仕事に自信のないメンバーは、能力を高めてくれる追加研修やコーチングより長時間働く方を選ぶことがある
・プロジェクトの失敗に対する恐怖・・・計画通りのスケジュールで時間が足りないとおもうとスタートダッシュをかけることがあるが、続かない。
・プロジェクトの失敗が確実な場合の個人的避難位対する恐怖・・・きたるべき大失敗の咎を逃れる為に、あえてこれ見よがしに長時間はたらく
早い段階の残業は、プロジェクトが思わしくない予兆
３３ ポーカーの夕べ
職務に関係ない活動のために組織のあちこちから従業員があつまり、顔見知りなるのは、組織にとって有効である。
しかし人為的にコミュニケーションの流れを円滑化しようとしても、個人が自らの意志で参加しているという意識が乏しいのであまり有効でない。人々が集まり、楽しみ、とに成功する状況をつくるだけでいい。あるいは集まった人の活動をつぶさないようにすればいい。
例としてポーカーの夕べ、マラソンの給水所のボランティアなど
３４ エセ品質ゲート
意味が欠落しているのに、形式の心配をしても仕方がない。
We eat breakfast in the evening.
構文は正しいが意味は通っていない。
エセ品質ゲートの兆候は、フィードバックのうち、内容でなく形式が大半を占めていることでわかる。
無益な手続きに時間が浪費させられたうえ、内容の欠陥が見過ごされることになる。
３５ テストの前のテスト
製品開発のごく初期の段階や各イテレーションの初期にテストを開始する。
プロジェクトで予定されている成果物が完成したときに、間違いがないかどうかテストできるするためのテストは、あとのテストの有効性を高め、エラーを避けられる。
これを行わないのは「期待通りに動く」とはどういうことかが正確にわかっていないから。
初期テストは要求だけでなく、あらゆる成果物に有効。製品の設計、プロジェクト計画、スコープ文書などテスト可能な形式で提出されれば初期テストのメリットを享受できる。テストされると思えば製作者の意識もちがうので中間成果物がわかりやすくなる。
製品ができあがってからテストしてもプロジェクトの成功の役にはたたない。
テストの前にテストすることは、最初から品質管理を導入することである。
３６ サイダーハウス・ルール
現場にいないひとが決めたルールは、無視されるか回避される。
ルールは必要だが、策定には作成者が現場に入り、現場の人の世界を共有することが必要である。
３７ まず話す、次に書く
大企業や分散チームは文書に頼る傾向があり、小規模なチームは会話に頼る傾向がある。
優れたチームは、その時その時の作業に応じて、文化的にあまり慣れていないコミュニケーションでも採用するよう心がける。意思決定を短時間で効率的に行うには会話を使い。あとに残すべき決定を伝えるときは文書を使う。
３８ ダボハゼ
心の中で仕事は多いほどいいと持っていませんか？
しかし、最大限の側で処理できる以上の仕事をひきうけていると、いずれ遅くなるのは当然。
多くの組織は膨大な量の仕事を完成させようとして、ほぼ停滞状態にまで減速してしまう。
立ち止まって価値あるものとないものに選り分ければ、自分たちが山ほどのカスのために遅くなっていることに気が付くはず。
３９ アトラス
アトラス＝なんでもできる優秀なプロジェクトリーダー
一見問題ないようにみえるが、自分でなんでもやってしまうために他のリーダーが育たない。だから運営できるプロジェクトの規模に限界があり、アトラスが抜けた後はだれもフォロー不可能である。
４０ 裸の組織
情報が多すぎると注意力はなくなる。
全員がすべてのことを知っている必要があるならその組織はおしまいである。
多くの情報を抱え込むことの問題は、情報をうけとってそれに文句をいわなければ事実上同意したことになること。
多くの情報を抱え込もうとして、自分の情報プレートをあふれさせてしまうのは、はじめて大人の宴会に参加した子供がおいしそうなものをすべて口に抱え込んでしまうようなものである。
４１ ピア・プレビュー
採用候補者と同僚になるスタッフを採用プロセスに参加させるのは、採用される側、受け入れる側双方にメリットがある。もちろん一次審査などはマネージャの判断が優先されるべきだが、面接はスタッフで行い、多数決で決める。
チームリーダーの採用もそうしてはどうか？
４２ シュノーケリングとスキューバーダイビング
広い範囲をみるならシュノーケリング、深く潜って調べるならスキューバダイビング。優れた開発者は自分を制限しないで、なにをみるべきかによって方法を選ぶ。
４３ いまいましいインターフェース
まだ細部まで煮詰まっていないプロジェクトの初期段階で、実装が可能なほど厳密にインターフェースを宣言するのは難しい、しかしわかるかぎりのインターフェースを定義しなければならない。インターフェースの欠陥をよく知っているマネージャはプロジェクトチームのインターフェースに気を配り、どこかのグループがインターフェースについて誤った仮説をたてる可能性とたたかう。
プロジェクトの人間のインターフェースが複雑だと製品のインターフェースも複雑になる
４４ ブルーゾーン
プロジェクトの任務を割り当てるには、3つの権限ゾーンをつくること
・グリーンゾーン・・・明確に任務の一部であること、つまり遂行すべき仕事の核である。
・レッドゾーン・・・任務の範囲から明確に除外されるものがすべて含まれる
・ブルーゾーン・・・それ以外のすべて、任務で求められても禁じられてもいない活動。
ブルーゾーンで行動し、ときにレッドゾーンで行動させてほしいという人物は貴重である。ひやひやさせられるときもあるが、その大胆さのおかげで、当初の任務で想定されていたものよりも革新的で優れたソリューションを創り出すこともよくある。
４５ ニュースの改良
組織によっては悪いニュースがまったく上に伝わらないことがあるが、それ以上に多いのが悪いニュースが1階層上がっていくたびに改良される例。
チームリーダー「おそらく1月は無理です」
↓
プロジェクトマネージャ「正直言って1月では不安です」
↓
アプリケーションマネージャ「1月というのは難題だと思いますが・・・」
↓
CIO「1月には間に合うと自信をもってご報告します」
原因は組織の文化として「悪いニュースを伝えた人が災難にあう」がある。
プロジェクトが困難な状況にあることを証明できるまで時間がかかる。早くに間に合わないといえば臆病者といわれる。だから惨事がだれの目にも明らかになるまでだまっている。
悪いニュースを隠すと解決できる問題が解決できない問題になってしまうことがある。
４６ 真実はゆっくり告げる
本当のことをゆっくり告げる理由は
・企業文化として散らかっていることに気付いたものが片付けろという空気があるので、真実を告げると尻拭いをさせられる。
・すぐに対策をたてられないのに問題をもちだすと「泣き言」といわれる
・他の誰かがもっと大きな問題を暴露して自分たちの問題が陰にかくれるのをまっている。
こうして真実を話したらつらい目にあるだけだと学ぶ。
組織は真実を知りたくない、できるだけ長く幸せに浸っていたいのだ。
４７ エンドゲームの練習
エンドゲームの練習をするチームは、プロジェクトの早い段階でリリース基準を作成する。次に製品がリリース基準をみたしているかどうかを評価するために必要なテストを開発する。開発のイテレーションが完了するたびにこれらのテストを実行し、そのあとで簡単なレビューを行う。
こうすることで、
・チームは開発のどの段階でも、製品を出荷するための残りの作業にあらためて専念できる。
・以前満たしていた基準から後退した場合、早い段階で気付くことができる。
・途中でリリース基準を見直す機会が何度もある
もし早い段階で測定が難しいなら、大きく未定と書いておくだけでも効果はある。
４８ ミュージックメーカー
IT組織には音楽をたしなむ人が多い。
自分の組織で周囲に田津寝て、音楽家の同僚が何人ぐらいいるかたしかめてみよう。結果はiPadへ
４９ ジャーナリスト
プロジェクトマネージャーが、なんのためにプロジェクトの状態に注意を払うのか、それを見失うとジャーナリストになってしまうことがある。プロジェクトの状態を正確に描写するのが目的になり、プロジェクトの成功とは別の成功をおいかけてしまうのだ。映画評論家と似ている。
５０ 空席
多くのプロジェクトには「ユーザーの立場に立って、製品が完成したときにビジネスプロセスがスムーズに機能するように考える」という任務を負った人が一人足りないために本当の成功をおさめることができない。
プロジェクトマネージャやリーダーではなく、ユーザーと製品がどのようにかかわり合うかということだけに神経を使う人をおくべきだ。（顧客サイドにいるのでもいい）
多くのプロジェクトはこの席が空いている。
５１ いとこビニー
良い解決策を求めて議論するメンバーは、お互いを尊重している。お互いのことが好きだといってもいい。そうでなければ生産的な議論はできない。議論が流れているとき、チームのメンバーは自分たちのアイデアを議論を精査することは攻撃ではないとしっている。最高の製品を効率的な方法で完成させようとしているだけだ。
経営陣やチームリーダーの発言はたとえ好意的でも、悪意がなくても同じようには受け取られない。仲間内（いとこのビニーだとわかっているから）安全なのだ。議論は上下関係を確立するためでも、個人の知識をひけらかすためでもない、相手のアイデアを試し、進化させようとしている。
５２ 機能スープ
人は普通自分の要求が最も大事だと考える、同じ組織でも場所が違っていたり顧客が違ったりすれば、自分たちの独自の機能がほしくなる。その要求がビジネス全体の整合性を考慮していないのも普通のこと。
この問題にアナリストが適切に対処しなければ、無関係の断片をはぎあわせた製品ができることになる。
そうしないために
・何がプロジェクトの目的で、何が目的でないか、可能な限り早い段階で明確に定義している。
・プロジェクトのスコープを、入出力データの正確な定義と対照して宣言し、つねに更新している
・明言された目標に寄与せず、プロジェクトのスコープの範囲外であることがあきらかな要求は鉄の意志をもって拒否する。
・新しい要求は、承認・変更・追跡という一連のプロセスを通して、その過程でプロジェクトの目標と比較評価する。
機能のスープを避けるには自制が必要。スープになって困るのは断片的な要求をしたひとではなく自分である。
５３ データエラーの真犯人
データベースソフトの品質より、処理するデータの品質の方が劣っているのはよくあること。
でも、数の少ない方がシステムの品質低下の原因とされ、ソフトの方を変えようとする。
データが壊れているなら以前のバックアップが使えるし、同じデータを複数のシステムに別々に記録している場合に自動データクレンジグが使える。
しかし、データの品質が低下する最大の原因は変更で、そのような損傷は手作業でなおすしかない。他の方法を空想してもツケを先延ばしにするだけだ
５４ その名は「ベン」
ベンは素晴らしい数学の才能をもつエンジニアである。通常のプロジェクト業務の他に、一人で解決できない問題を抱えている人たちを手助けする。問題がベンの職務の範囲外であること、部署の範囲外であることさえある。でも仲間と一緒に考えているうちに、たいてい良い解決策を思いつく。
ベンは仕事を楽しんでいる、仕事を愛し、仕事にやりがいを感じ、仕事をクールだと感じて、決して金のために働いているのではない。
ベンはいたるところにいる。さまざまな仕事をしている。そして扱いやすい。だから扱いを間違えやすい。
あるマネージャは欠員がでたときベンに仕事をまわして欠員を補充しなかった。最初はよかったが、仕事が耐えられないレベルに達したとき、ベンは仕事が楽しくなくなって会社を去った。
ベンの仕事はすぐみつかるだろう。でも、マネージャはベンを見つけるのは難しいだろう。
５５ ミス・マナーズ
仕事の結果と仕事をした人間がいっしょくたにされるのは間違い。
人を批判するのをさけようと、礼儀をまもっているのは、弱気。
こういったミス・マナーズの職場では批判は許さないという暗黙の掟がある。
５６ 知力の集中
一つの演目に集中したほうが舞台はうまくいく。
プロジェクトもフルタイムで参加したほうが、切り替え時間の無駄がなく、個人のパフォーマンスは最高になる。
５７ 野球に泣くなんてのはないんだ！
自分の仕事に情熱的になれる人をプロジェクトに投入することは、成功の秘訣である。
情熱は時に爆発するが、その後始末くらいは高い目標を達成するために支払う代償の一部にすぎない。
仕事を大事にしていなければ、仕事に感情が入り込むこともない。
５８ 暴力脱獄
仲間同士の意見の違いを「コミュニケーションの失敗」にするのは間違いである。
仕事の対立はプロらしくないというのは思い込み。
品質と生産性は常にバランスをとる（対立している）。
そこらじゅうにれっきとした対立があることを認めよう。そして実証された対立解決手法を使おう。
その方がコミュニケーションの対立より確実によい結果が生まれる。
５９ 期日はかならず守る
必ず期日をまもるなら、品質基準はゆるんでいるはずだ。
組織にあるプロジェクトのかじ取りのための５つの「レバー」
1.人 2.技術 3.スコープ（どのような機能を開発するか） 4.時間（いつ完成させる予定か） 5.出荷時の品質基準
時間がたつにしたがって、使えるレバーは４と５だけになる。
６０ フード＋＋
「千と千尋の神隠し」は夏の公開に間に合わせる為に長時間働くことにした。そのためチームの誰かが全員の夜食の用意をするようになった。一緒に調理して食事して後片付けをすることでチームの結束は強くなり、映画は期日までに完成した。
食べ物は人々を結びつける。
一緒に食事をしたからといって、チームが成功する保証はない。しかし、成功するチームは一緒に食事をつくって食べることで生まれる豊かな対話を利用することが多いようだ。
６１ ほったらかしの成果物
あらゆる成果物のなかで間違いなく必要なものは製品だ。しかし他のものはどうだろう。
もし、品質管理や再利用のために作成する成果物があるのなら、その作成のリソースにはスポンサーを探すべきだ。
コストにみあう効果があるかどうかを検討しないで、あれをつくれこれをつくれというのは簡単。しかし資金も人間も出さないのに現場がすんなり受け入れるとは限らない。また作成されてもほったらかしになる。
アイデアがいいならスポンサーを探すべき。
６２ 隠れた美
指定された機能が果たせるかだけが仕事の成果であり、美観など関係ないというのは間違い。
すべてのデザインには美的要素があり、すぐれたマネージャは部下のデザインを詳細に見る能力と意思を持つ。すばらしい設計を評価する。
すばらしいデザインはそぎ落とすことにある。どんなに機能をつけたしてもデザインはよくならない。
６３ わかりません
「わかりません」をやる気のない証拠とみる組織は、すべてのことを知ることができないという真実を無視している。
「わかりません」ということで、助けが得られる機会が得られるのをすてて、余計な時間をかけている。
「わかりません」が言えるのは、人々が安心して助けを求められるということ、あらゆる階層で真に協力を推し進め成果を得ることができるということ。
６４ レイクウォビゴンの子ども達
大規模チームのメンバーの間では、ソフトウェア工学の能力にケタ違いの差があると何十年もいわれている。
それなにに、成績評価はほぼ全員平均以上の評価をうける企業が多すぎる。
この場合マネージャが真実をつたえているのは本当に中程度のぶかだけで、成績優秀な部下に彼の仕事の素晴らしさを伝える機会を失い、成績の悪い部下に、このままでは首が危ないと知らせる機会を失う。
そのかわり、成績の悪い部下のコーチ役になったり、任務を縮小して失敗しないようにしてしまう。そんなことより恐れず建設的に向き合った方がよい。水準に達していないことを知れば努力して人並み以上になるかもしれない。
６５ 共同学習
プロジェクトが始まるときに、将来どのような状態になるのが望ましいのか、個人やグループが理解していると考えるのは非現実的である。
つくり手は消費者が要求を完璧かつ正確に列挙できないとしるべきだし、消費者は作り手が要求を正しく理解できると考えてはならない。
必要なのは共同学習である。
開発が始まらないうちに要求仕様書の作成を済ませようとするのは間違いだ、初期プロトタイプや試験モデルをつくり発見と学習を繰り返すべきｄ。
ステークホルダーの中には、自分は何が必要かわかっているという人がいるが、そのような人が必要だとするのは目の前ｎ問題に対して思いついた解決策で、もっと大きなニーズに応じられる解決策ではない。全員が理解するのは問題であって、解決策はそのうちでてくるものである。
学習は早くはじめるのがよい、プロジェクトが進行するとアイデアが固まってしまう。早いうちに機会をとらえイノベーションを成功させよう。
ステークホルダーはそれぞれ何かを、それもかなり多くのことを知っている。互いに教えあるために共通の言語が必要で、モデリングを繰り返し、それをすてて学習は進む。
もっとも難しいのは共同学習に努めることが必要だと認識すること。
６６ 魂の仲間
仮に「ゲリラ」チームと呼ぶ開発チームがある。アジャイルの世界によくみられる。非常にイノベーションに優れたチームである。
特徴は
・予定された会議は嫌うが臨機応変に少人数の会議を何度も行い、そのほとんどが設計会議になる。
・アイデア、デザイン、ToDoリストをメモするのにホワイトボードを好む
・不完全で高水準な要求定義書をもとに作業する。せっけいぶんしょはすべて省略し、開発プロセスのごく初期からコーディングに移る
・大量のコードを破棄しては書きなおす。機能のデモを行うと、すぐに改良にとりかかる
・これらを非常に速く行う。一般的な機能の開発にかかる時間は1-3日、極めて複雑なら10日、多くのタスクは半日で完成してテストできるようになる。
従来型のソフト開発では「問題を見つけて修正するコストは開発サイクルが進むにつれ急激に上昇する」という考えに基づいて、できるだけ早く要求と設計をきちんと定義しておきたがる。またきちんと機能するソフトの構築と検証には時間がかかるので、それは1回か2回だけとする。
ゲリラチームは何を構築すべきか発見する過程で迅速にコードを開発してテストするため、実に大量のコードを破棄する。こういったチームは新製品のバージョン１にむいている。得意なのは比較的新しい問題涼気を探索し、革新的なソリューションを考案すること。耐久性と安全性に優れたコードもつくれるが、イノベーション志向である。
たいていは一人か二人の魅力的なリーダーの周りに有機的に発生し、ゆっくりと増えていき、結束が弱まるとあっという間にバラバラになる。命令によってつくることはできないし、ずっと維持することもできない。
ゲリラチームに仕事をさせるなら新天地を与え、システムが確立してしまったら他の新天地を探せるようにすべき。
最後に「偽物が多い」、このモデルはあらゆるレベルの開発者にとって魅力的なため、少人数チームの多くは自分たちをゲリラチームだと思っているが、本物は稀。まかせるなら相手が本物かたしかめよう。
６７ 十字穴付きねじ
ヘンリー・F・フィリップスが十字穴付きねじを開発したのは1930年代初頭だが、使われだしたのは1985か1990年ごろ。
明らかに優れたアイデアであってもすぐに受け入れられるとは限らない。
トーマス・アルバ・エジソンは、何度も新しいアイデアを考え付く能力があった。
一つのアイデアを推奨する人はプロモータであり、過去にいくつもの優れたアイデアを考え付いてきた人はイノベータである。イノベータになるには何年もかかるが、地道な努力を伴うが、予想外の恩恵がある。実績のあるイノベータの提供するアイデアは人々にうけいれられやすい。
６８ イノベーションの予測
プロジェクトのイノベーション・・・チームがそれまで経験したことのないなにかをやるということであり、メンバーが問題を違った方法で解決できるかどうかにプロジェクトの成否がかかっているということである。
一方で完成する時期をかなりの精度で予測する必要がある。
マネージャは開発者にイノベーションの時間を提供しつつ、顧客にはプロジェクト完成について正確な予測を提供しなければならない。
どちらかの領域に迷い込まないためには、開発プロセスのイテレーションをおこなうこと、それぞれのイテレーションの器官は1回につき1-4週間で、１－３までは未知の要素を洗い出し、開発作業に持ち越す不明点を減らすためにあてられる。この間のコードは次のイテレーションに使われる必要もない。
決められた開発期間の中でイノベーションを必要とする問題領域を何度か通るようにすることで、バランスをとる。
プロジェクトの成功の源はイノベーションであるが、予測可能性も必要である。
６９ マリリン・マンスター
「マンスターズ」はモンスター一家のはなしである。金髪美人のマリリンは一家の親戚で美人な人間の容姿をもっているが、一家の仲では不器量で役立たずといわれる。
マリリンのような人生を送っている開発者の組織は、マネージャが主役だ、開発者はコストの一部であり、取り換えの聴く部品だと思われている。給料もマネージャのほうが断然多い。変化形として営業があらゆる権限をもている組織もある。
反対に開発者の能力の差が大きいことを理解して、よい開発者を雇うために努力している組織もある。そのような組織は自社のソフトウェアまたは製品の主要部分を自社で開発しているところが多い、
開発者がキングの文化が行き過ぎると、自分の仕事を最適化しすぎて、プロジェクト全体の最適化を妨げることがある。
組織の成功のために品質とイノベーションが重要であり、そのためには本当に有能な開発者が必要である。
あなたが優秀な開発者なのに、マリリンのような気持ちなら、他の家庭を探すべきである。
７０ ブラウン運動
プロジェクトの最初に人数を投入するのは間違い、ビジョンを形成するのは少人数のグループである。
Linuxのビジョンは一人がつくり、C++もそうである。
７１ 音吐朗々
プロジェクトの目標はもっとも高いレベルでの要求と制約である。
相容れない個人的目標がある人間たちがまとまってプロジェクトの成功に向かって働くために必要である。
よい目標は、ステークホルダーが対立しない目標になっており、そして目にみえるところに常に掲げられるべきである（会議室では椅子を与えよう）
７２ 安全弁
チームは仕事の緊張に立ち向かうため、ガス抜きの方法を考え出す。
「シークレット・アサシン」・・・それぞれのメンバーに標的が割り当てられ、同時に他のメンバーの標的になる。みなはナーフガンを携えて標的に忍び寄るが、標的が自分のデスクにいるときには暗殺することはできない。
シークレット・アサシンが生産性を高めることがわかっている。
ただし、チーム内で自然に発生したものでないと意味がない。上司やマネージャが指示しないこと。
みつけたら、黙ってみのがそう。奨励もいけない。
７３ バベルの塔
お互いが使っている言語が、同じ意味か確認することは重要だ。
しかし組織は常に変化し、言葉の定義も変わっていくものだ。それでも定義にこだわっていくことが大切
チームが一貫した言語をつくっても、その努力は外部から評価されないが、言葉の定義につりつかれたようにこだわるチームは成功するチームだ。
７４ サプライズ
ささやかなサプライズ報酬を提供する弊害。
こんなはした金のために、貴重な家族との時間をすてたのではないといわれる
プロジェクトが終わったらどんなサプライズ報酬？がもらえるかと期待する人がでる
７５ 冷蔵庫のドア
すべての情報を伝える必要はないが、すべての情報を開示する意味はある。
冷蔵庫のドアのように、みんなにみえるところ（廊下や作戦会議室）に成果物や進捗状況をはっておく。
冷蔵庫のドアは面倒な文書配布やバージョン管理の手間をはぶき、メンバー間の信頼関係をよくし、不完全な点やスケジュール遅れを他の人に見つかるのを恐れる必要がなくなり、ねつ造はなくなる。全員同じ基準で作業できるようにあうる。
７６ 明日には日が昇る
マネージャは将来の進捗の平均を、過去の進捗の平均より上になると信じている。
しかし、それは危険だ。
たとえ、現在の進捗が偶発的要素による不幸な結果であっても。この先もそういった事態が起こらないという保証はない。
いままでの進捗速度で将来をみて、スケジュールの変更やスコープの変更を行うのが賢明である。
７７ パイリングオン
アメリカンフットボールのパイリングオン・・・すでに倒れているボールキャリアの上に守備側のプレーヤーが飛び乗る反則行為
プロジェクトを失敗させたかったら、パイリングオンをおこなえばよい、すなわちそのプロジェクトをもっとよくすると称して追加機能をいれるのだ。
開発期間を複数のイテレーションに分けているプロジェクトでは、パイリングオンに対する免疫がある。初期のイテレーションで重要な機能のみを実装し、その他は最後に追加するのだ。追加するコストが、効果より高ければ機能追加をやめるという選択肢をとることができる。
７８ 変更の季節
スコープ（白線）の定義はプロジェクトへの影響が大きい。
しかし、いつでもスコープが変更できるようにすることは、開発の遅れを引き起こす。
イテレーションの間に限定すべきである。もちろん長すぎるイテレーションはいけないが。
７９ 製紙工場
文書を作成する人に「なぜ」と聞くと「プロジェクトのこの段階ではこの文書を作成しないといけないから」という。
「その文書は正確にどういうことを書くんですか？何のための文書ですか？誰が意思決定に使うんですか？」ときくと、そこまでわかっていないことが多い。このようなプロジェクトは製紙工場になっている可能性がある。
みんながコピーを欲しがる。文書さえあれば、プロジェクトの目標に貢献する有益な仕事をしているかどうかを検証しなくなる。
製紙工場でないプロジェクトチームは自動的に文書をつくるのでなく、その他の方法で進捗状況を伝えることを考える。ホワイトボード、テレビ会議、ブログ、プロトタイプなどだ。成果物はプロジェクトライブラリに置き、だれでも自由に入手できるようになっている。
重要なのは、作成される文書はすべて何らかの明確なニーズを満たすもので、その内容はプロジェクト全体の知識にもとづくべきであるということ。
８０ オフショアの愚行
サブコンポーネントのインターフェースの複雑さを最小限にするようにシステムを分割するように、開発チームのワークフローの設計もするべきだ。
サイト間コミュニケーションとサイト間イテレーションのコストを甘く見積もってはいけない。
オフショア開発資源を利用するなら
・イテレーションはローカルで、一つのサイトで行う
・オフショア開発モデルの最初の数回は国内で同じことをするより時間がかかると認識すること
・オフショアチームは国内開発チームとかわらない、やりがいのある仕事をしたいと思っている
・各サイトの目的を育てる。活気あるサイトは具体的使命がある。雑多で多数の開発をおこなっていて、共通の目的もなく各チームをサポートするサイトはエネルギーも士気も低い。（国内でも同じだ）
８１ 作戦会議室
専用の作戦会議室をもつプロジェクトはまっしぐらの成功へ向かう傾向がある。
直接会って存分に対話することがプロジェクトの成功のために必要だという姿勢の表れ
成果物を壁に貼って掲示するのはチームの結束を強めるためにも、作業を推敲するためにも重要だという主張の表れ
プロジェクトのメンバーは作戦会議室の近くにいて、プロジェクトマネージャは作戦会議室にいることが多い。
ただし、ただ作戦会議室のスペースを確保するだけはだめで、作戦会議室をプロジェクトの活気あふれる有機的なプロジェクトの要素にすることである。
８２ 何のにおい？
組織の中にいる人は、組織の根底にある生命力にも腐敗にも気が付かない。それはパン屋のにおいのなかでも鴨の農場でも人間はにおいに慣れてしまって気が付かなくなるようなものだ。
外からの新鮮な鼻を持ち込み自分の周りのにおいをかいでもらおう。そして次の行動をきめよう。深呼吸して何もかえないか、窓を少し開けるか、燻蒸消毒するか
８３ 身につかない教訓
プロジェクトが終わってから反省し教訓を引き出すのは難しい。
問題がチームの外にあったり、内にあったら変化を起こすのは気が遠くなるほど難しいからだ。
反省会のプロセスがガス抜きで終われば、公表されるのは所見ばかりでアクションアイテムはない。
反省で成果をあげる勇気ある組織になりたければ、チームの権力の内外に実現可能で明確なアクションアイテムをあげることだ。
８４ 生半可なアイデアの美徳
チームのメンバが生半可なアイデアをだしあえる文化があるべきだ。
人は新しく考えるより、あるものを改良するのを好む。たいていのアイデアは根気よく取り組めば改良できる。すぐれたアイデアでなくてもたたき台になる、議論を通じてアイデアは成熟し向上する。
生半可なアイデアを封印すればイノベーションがおきる可能性を封じてしまうだろう。
８５ リーク
時間とコストは、注意深く測定されるカテゴリーからさほど厳しく測定されないカテゴリに逃れる傾向がある。
これは割り当て時間いっぱいまで作業してしまって、まだ完成していないからと別の作業に、今使っている時間をわりあてたり、締め切りがまだ先の作業に割り当てたりすることである。割り当てが残り少ない仕事、締め切りの近い仕事は注意深く観察されるからである。
こうしてリークはプロジェクトがコントロールを失う。
８６ テンプレートゾンビ
製品を完成するために必要な思考プロセスではなく、テンプレートによって作業をすすめる。
こういうチームは文書の内容と検討するより、標準文書を作成することに懸命になる。
テンプレートが埋まっていればよしとするのだ。
アイデアがテンプレートの項目にあわなければ無視したりする。
テンプレートはチェックリストやフレームワークになる良い方法だが、固定化して埋まっていたら成功と考えるのは間違いである。
飼い犬だって週末のお出かけの前兆をかぎつける。
でも、パターン認識の先、「ああ、またアレだ！」といいう気づきは動物にはやってこない。
パターンは時間をかけて吸収され、洗練され、精神の奥深くへしまいこまれ、直感という形であらわれる。
それだけでも価値はあるが、じっくり考えそこから明確な知見を導き出せればその価値はずっと高くなる。
右脳の直感と左脳の言語が結びついたとき、本質をとらえて言葉にすることができる。
言葉があれば、書き留めたり、他の人と共有したり、他の人の知見と融合させたりできる。
この本は150年にわたって吸収してきたパターンを6人の人間が文章にしたもの。
順番は特に意味はない。楽しく読めるようには工夫した。
必ずしも読者の組織にあわないかもしれないが、以前は直感に過ぎなかったものをチームの知見にする手伝いになるとうれしい。
よく考えられた抽象化はどのような題材でもわかりやすく人に伝えることができる。
１ アドレナリンジャンキー
みんなが猛烈に必死に働いている、いつも緊急で重要な仕事でいっぱいだ。でも生産性をたかめる本質的に重要なことは緊急はないので置き去りだ。だから生産性はいつまでもあがらないし、少人数で必死に働いてなんとかなる範囲のものしかつくれないので、大きなプロジェクトは行えない。
こうした組織の特徴は、優先順位が絶えず変化すること。いつも「きのう」必要だという。
２ スピード勝負
スピードの速いチームは、議事録が届かないうちに決定した行動経過のうち1項目めか2項目めが終わっている。
もしかして、会議中にインスタントメッセージで問い合わせ、会議が終わるまでに報告できるかも。
速いチームは強いチームで、以下のような文化をもっている。
・本能的に切迫感をもっている。
・個人とチームの能力に絶大な自信をもっている
・反復に価値があると信じている・・・間違ってもいい、修正するから。
弱いチームの会議はトークショーである
・完璧な情報をもとめる・・・それが得られるまで何一つ決まらない
・なんでも「保留」しただる・・・決定や行動を後回しする理由をさがしている
・左かっこのオンパレード・・・思いつきで会議が進む
・キャンプファイヤーを囲んでおしゃべり・・・組織の過去や現在についてとめどもなく語る
・すべの道は設計に通ず・・・アーキテクトや開発者の力がつよいと設計議論におちいりやすい
・次の会議の予定をたてるための会議
３ 死んだ魚
時には手ごわいプロジェクトに挑戦して、譲歩する前に精一杯の努力をするこも必要だ。
しかし、最初から納期にまにあわないとわかっているのにそのままプロジェクトをすすめ、「一生懸命がんばったのにできなかった」というのが文化なら問題だ。
死んだ魚＝最初から納期にまにあうとだれも思っていないプロジェクト
４ 幸福礼賛会議
時間も労力もつかわずに士気が高くなる方法として使われることが多い。
全員が参加して上司が「問題があればなんでもきかせてください」というが、実際に厳しい質問をすると後で叱責される。求められているのは意見ではなく賛同。
それは間違いなく幸福礼賛会議。
５ 乳母
良いプロジェクトマネージャーはイギリスの乳母と共通するスキルをもっている
乳母は子どもを守り、運動させ、外の世界で生きていけるように教育する。環境をととのえるのだ。
良いマネージャは、開発者が雑用にわずらわされないように気を配り、必要な情報を伝え（ウワサ話の時間が減る）、機材や職場環境をととのえ、コミュニケーションの時間（朝のコーヒー会や、金曜午後のブックレビューなど）を用意する。自分を支援者ととらえて、メンバーが役割をこなし、生産性が高まり、自分の仕事に満足してくれることを喜びとする。
この反対は、マネージャーの関心が社内での駆け引き、出世にあり、チームと話をするより、PERT図やガントチャートをつくったり手直しするのが大事、あるいは開発にかかりきりである。
６ 関連痛
関連痛・・・原因箇所ではない身体の部分に痛みがあらわれる状態のこと
プロジェクトを立ち上げるときに、目に見える問題に目をうばわれて、肝心の問題が解消できないことがある。
また、使い慣れた技術でなんでも解決しようとして、最適でない技術を使ってしまうこともある。
回避策を多用しないといけない状況が続くなら、関連痛にかかっている可能性が高い。
本質を解決するのは困難だが、見返りは大きい。
７ マニャーナ
マニャーナ・・・スペイン語で「いつかそのうち」
たいていのプロジェクトは人間の切迫感の時間枠（30-90日）より長くかかる。だから30か月後の納期に切迫感を感じることはない。
こんなときはメンバーの意識を時間枠に集中させるために90日あるいは30日以内に成果物を仕上げるように指示をだす。もちろん本当のゴールに向かうために必要なものでなくてはならない。
あと、50％など判定が難しい設定は切迫感がでにくい
また作業やテストの用のツールを必要以上に探し回るなども、たちの悪いマニャーナだ。
８ アイコンタクト
フルタイムの熱心なプロジェクトメンバーが1か所に集まると、ある種の奇跡が起こる。息をあわせるには物理的に近くにいる必要がある。
緊急かつ複雑ならば、要因は同じ場所に配置すべきである。
９ ムードリング
結論のない進行形の活動ばかりに注目するプロジェクトマネージャーは、自分たちが最終的に何を達成しようとしているかわかっていないことが多い。
こういったマネージャの報告の特徴
・感情や熱意に重点がおかれ（がんばっています、間に合わせるべく努力しています）
・現在に集中している（全体のどこではなく）
・計画通りにすすんでいないことには感情でかたる（少々心配です）
・結論がなく進行形で語る（あといくつかの機能もすぐに完成させてくれるにちがいありません）
・マイナス要素にはふれるが全体的に楽観的
なにをすべきかわかっているマネージャの報告の特徴
・作業内容、成果物の状況によって評価する。
・中断、問題、計画変更に注目、必要な修正と決定項目を明示
・だらだらせず区切りがある
・客観的情報と判断的要素のバランスがとれている。
ほとんどのマネージャは上と下の中間。上の要素が多くなってきたら、自分を修正しよう。
１０ 信者
特定の技術を信奉しなんでもそれで解決しようとするひとがいる。
しかし、どの手法やツールにも限界がある。
異なる教義の信者が争いを起こすと収集がつかなくなる。
「異なるプロジェクトには異なる方法論が必要である」 アリスター・コーバーン（アジャイルソフトウェア開発）
１１ 魂を貸す
一流のプロは魂を貸しても、売らない。
確立された個人やチームの技能を問題にあてはめるのではなく、問題に合わせた解決策をさがそうとする。
慣れ親しんだやり方を、いつでも捨てる勇気があり、かつ流行りの方法に安易にのらない。
大事なのは「この技術は何に適しているか」であって「どうしたらこの技術でこの問題を解決できるか」ではない。
１２ レミングサイクル
プロセス改善プログラムの一環として、開発プロセスの社内基準をもつ企業は多い。
しかしなにがなんでも標準プロセスを守ろうとすると、いらない仕事を増やしていることも多い。
万が一失敗した場合、標準プロセスを守っていなかったからだといわれる。
またどのプロセスを削るべきか検討する時間が惜しい。
このような理由でやみくもに標準プロセスに従うのは、厳格にレシピを守る料理人のようなもので、優れた料理人にはなれない。
１３ ベンチに人なし
組織をスリム化しすぎて、予備要員がいなくなっていませんか？
プロジェクトの主要メンバーのだれにでもとってかわれる幅広い人物を一人か二人用意すべき。
コストはかかるが、プロジェクトにとって足りなくなるのはコストより時間のはずだから。
１４ フェイスタイム
小数精鋭チームの開発効率がいいのは30年もまえからいわれている。
今日なら、ここに「同じ場所で働く」がつくだろう。
しかし分散プロジェクトが普及して、難しくなっている。
それでもメンバーはできるかぎり会うべきだとして、その一般的ガイドラインをあげていた。
・サイト間の作業を担当する人（プログラムマネージャー、プロジェクトマネージャーなどの肩書）はリリースサイクルごと。3か月に1回では少ない
・開発者、QAエンジニア、テクニカルライターのなかなら、リリースサイクルに最低1回、各サイトのベテラン同士が顔をあわせるべき
・若手メンバーが他のサイトを訪れることで、自分たちの仕事の一や、他のサイトのベテランからの教育、評価がうけれることがある。
サイト間で、あそこは使えないサイトなどと序列ができたりするのは最悪。
１５ 「どうしてミケランジェロになれないんだ？」
「たがね」はミケランジェロが手にとらなければ、へりの鋭い金属片にすぎない。
ツールを導入しても、使いこなすためのスキルがなければ、生産性はまったく上がらない。
１６ ダッシュボード
車のではなく、プロジェクトやビジネスプロセスの状態を視覚化して伝える手段として普及したもので、各種指標を通常は図表と数値の両方で表示し、プロジェクトやプロセスの進捗状況を全体的に描きだす文書やWebページのこと。
トップレベルにはかくパフォーマンス指標の要約が表示され、ユーザーがそれらをドリルダウンしてさらに詳しい情報を見られるタイプのものがある。
ダッシュボードは強いチームが使えば役にたつが、弱いチームが使うと全く役にたたないどころか邪魔になる。
弱いチームがダッシュボードを使っているときの兆候
・赤は失敗を意味すると信じている。音がうるさいからと煙感知器をきっているようなもの
・橙は現実から目をそむけた赤である・・真実に向き合えないで、警鐘をならすことを避けたがる
・緑はあまり見るなという意味である。・・・ぎりぎりに突然赤になる。そこには赤だとダメだという文化がある
このようなチームは成功への情熱でなく批判への恐怖を原動力としている。
強いチームの有効なダッシュボートの特徴
・ダッシュボードを使ってもデータに圧倒されない・・・すべてを報告するのではなく、限られた指標を慎重にえらんで報告する
・ダッシュボードを抜粋・編集できる・・・どの情報をフロントページんに表示し、どの情報を3階層下に埋めるかを決める過程で、重要項目がはっきりする
・情報を示すだけでなく判断を促す・・・現状の報告だけでなく、判断を促すようになっている
・現状を反映するだけでなく未来を予測する・・・現状を報告するだけでなく、将来なにが起きて何がおきないか予測を示せる「バランス・スコアカードー新しい経営指標による企業変革」
・長期的なトレンドを示す・・・現在のスナップショットだけでなく、いままでの軌跡、黄色の前は何色だったのか？がｗかる
・チームが主観的な評価を報告しなければならないときに、比較をするための枠組みがある
色は主観であり、そうあるべきだが、定義はあるべきだ
緑＝順調で、修正はいらなそう 黄＝ただちに十分な修正措置をとる必要あり 赤＝プロジェクトは計画にほど遠い、ただちに変更措置がいる
成功する確率を高める為にただちに修正すべき天意チームの注意をむけることができる
１７ 永遠の議論
プロジェクトリーダーが、不満を述べるのを許している限り、決定に従わない人がでる。
こういう人は賛同するまで決定に従わなくていいと思っている。
組織として行動するなら、意見をきいて決定するまでの期間をきちんときめて、いったん決まったら賛同していなくても決定に従うという文化が必要である。
そうでなければ永遠の議論が続くことになる。
１８ 子犬と老犬
組織に一定以上の若者がいると、そこはみながよく働き、明るくくつろいだ雰囲気で、いい意味で「楽しい」職場になる。若い人々は高揚感がある、これからスキルを身につける最中で、次第に成長を実感し、いい仕事がしたいと思っている。それにつられて老犬も若返る。
老いぼれ犬ばかりの組織になってしまうのは
・組織が成長していないため、若者を雇う機会がほとんどない・・・政府機関のような場所に多い
・組織が経験者だけ採用することにしている・・・XMLの経験15年！
・組織が徹底的に冒険を避けている
パートタイムでいいので若者を起用しよう。
１９ 映画評論家
プロジェクトの成功とは別の成功を目指している人。
プロジェクトが終わりに近づいたとき、プロジェクトの間違いを指摘したりする、あくまで指摘するだけで、修正方法などは言わない。
プロジェクトは失敗しても、自分は成功できると信じていて、事実上黙ってプロジェクトチームから分離している。
この映画評論家が生まれやすい組織は、経営者の文化として間違いを犯さない文化をもっている。ひとの間違いを指摘せよと組織にシグナルをおくるので、参加しているプロジェクトに対して他人事のように映画評論を行う。
そういう人を許容すると、責任あるリーダーやメンバーになるより映画評論家になるのは簡単だから増えることになる。
プロジェクトの成功を目的としない人が参加することで、誰の努力も実をむすばない、逆効果になる場合がある。
２０ 一人一役
一人一人が責任をもち、その責任がどういうものかを理解していることが、人々のやりがいになりチームとして力を発揮する。
一人で責任を引き受けたから、同僚や関係者に協力を求めたり、必要な意見を得たりしてはいけないということではない。
すべを全員の責任にしたら、全員があらゆることを心配し、どれ一つうまくいかない
閑話 プロジェクト言葉
このスケジュールは果敢です・・・おれたちはおしまいだ。
もうすぐ遅れは取り戻せます・・・やっぱりもうおしまいだ。
２１ ソビエト式
意図された機能ははたすが、やり方がまずい、いらだたしい。
あるいは使い勝手が悪い、見た目や雰囲気に魅力がない、必要な安全性に欠けているという利用する人に魅力を感じさせるという要求を満たしていない。
こんなソビエト式製品を作ってしまったことはないだろうか、こういったものは修正が異常に多いか、極端に少ない（使われないから）
優れたチームは、機能面以外の要求をシステマティックに引き出すことを重要なプロセスの一環と位置付け、これらの分野でユーザビリティモデルを構築し、スペシャリストを採用している。
プロトタイピングを行い、ユーザーに好まれる機能面以外の品質について有意義なフィードバックを集めることが重要
２２ 自然な権威
権威は、能力のある人に備わる。
大事なのは知識があってその分野をよく理解している人に相談し、権威ある人が判断すること。
階級が↑=権力のあるひとが、権威のある人を無視して判断をしてもうまくいかない。
沈黙は同意とみなされるので、あなたが権威のある人ならば、だまっているのは責任の放棄である。
しかし文化として権力が権威を無視する企業では、だれもそんなことは気にしなくなる。
２３ 静かすぎるオフィス
廊下歩くだけでソフトウエア開発チームのことはわかる。
チームのメンバーが目的をもって楽しそうに動き回っている職場は良いチーム
人々が家に帰れる時間を待ち、次の給料日を待ちながら、何かおもしろいことはないか、あるいは早く退職する日がこないか考えている職場は静かすぎる。
２４ 白線
システムやビジネスエリアは、データを変化させるプロセスで構成されている。
プロセスは属性セットを別の属性セットに変換し、データの状態を変えてからそれを次のプロセスへ渡す。
このようなプロセスとデータの集合体をかき、そこに白線を引くことでシステムのスコープが明確に定義できる。
２５ 沈黙は同意とみなされる
約束の誤解が起きるよくあるパターンは、要求に対して、沈黙でこたえること。相手は異を唱えなかったら同意とみなし、こちらはYesといわなかったらNoだと思っている。
これは双方にとっていいことはない。
これを避けるには、少数の重要な約束を公言し、文書化して、関係者全員に配ること。
そして「同意しなければ同意とみなされない」というルールを作ること。
２６ かかし
人は白紙から答えをつくることは嫌がるが、すでにあるものは平気で批判する。
だから、優秀なアナリストは「何をお望みですか？」とは聞かない。相手を不快にするから。
「かかし」のソリューションは、クライアントの望みを引き出すために提示される。最高の「かかし」は意図的に間違いを組み込みさえする。そうして最速でソリューションやデザインに近づくのだ。
早いうちに間違え、何度も間違えることが、できるだけ早く正解にたどり着く方法。
われわれが直面する問題は複雑すぎて、一人の頭ではどうにかすることはできないのだｋら、覚悟をきめて「これはどうだろう？」と聞いてみよう。それが有効な「かかし」になる。
２７ いつわりの緊急任務
リスクを取らないの間違いであることは理解されつつあるが、最初から失敗するとわかっている開発期間に挑戦するのはいつわりの緊急任務であって、リスクをとることではない。
いつわりのリスクを生み出すと、組織は本物のリスクに挑戦する機会を失う。
２８ 「時間」に切り札を奪われる
プロジェクトに影響を与えるのは、マネージャがごく早い時期に下した決定である。
早い段階での人員増加は、有効だが、のこり2か月の人員増加は失敗の可能性を高める。
機能を早い段階で絞り込むのは、重要なものを完成させるため。さもないと締め切り間際に完成間近な多くの重要な機能と、完成した小さなこまごました機能に直面して、何を先にリリースするべきかの選択肢はなくなっている（完成しているものをいれるしかないだろう）
優秀なプロジェクトマネージャは「時間」に負けないためにいつ切り札を切るべきかしっている。
２９ ルイス＆クラーク
1803年あめりかが五大湖と大西洋海岸の州だけで独立したあと、フランスから西の領土を買った。
1804年から1805年にかけて、ジェファソンの命で新領土の調査をおこなったのがルイス＆クラーク。
二人は何を見つけるべきか指示されなかった（できなかった）
プロジェクトの探検隊は抽象的な意味で仕事を調査する。しかし結果は必ず有益なものがみつかるわけではないことは承知しておくべき。しかし、有益なものがみつかれば、無駄な探索の分も十分カバーできる利益が得られるものだ。
３０ ちびた鉛筆
コスト削減が続くと、組織の競争力は落ちる。
最初のコスト削減では、利益が増えたことだけがクローズアップされるが、一時的なものであり、コスト削減が続けば組織はやる気を失い、やがて売り上げがおちていく。
１つくらいコスト削減プログラムを実施するのは賢明だが、さらにコストを削減しようとするより、自分自身の幸せを考えるべきた。
３１ リズム
リズムのあるプロジェクトは、巨大で複雑な仕事にひるむことなく、小さく規則的なステップを踏んでいくうちに、一定のテンポをきざんで目標へたどりつくことがでる。
そのとこを理解しているので、まず目標をきめ、通常は1か月で完了しそうな計画をたて、毎日あつまって進捗やアイデア質問をかわし翌日の計画をたてる。プロジェクトの目標、毎月の目標となる成果物、毎日のフィードバック会議が作業のリズムをつくる。人々がリズムと認識できればサイクルの長さは問題でないが、6か月以上になるとマニャーナが起きるので注意。
リズムのあるプロジェクトはリズムのないプロジェクトより短期間で役立つ製品をつくりだせる。個人個人が他のチームメンバとの約束を果たしているから。リズムにあわせて働くのは自己強化型の活動になり、健全な駆動力になる。
ただし、マネージャーが強制的にリズムをつくったり、リズムをあげたりしてはいけない。リズムはチームが作り出すものだ。
３２ 残業にみる予兆
若いマネージャは、部下が残業するのをみると、意欲の表れとみて喜ぶ。
追い込みの時期の残業ならいざしらず、早い段階の残業にはチームの恐怖があらわれている可能性が高い。
組織が恐怖の文化にとらわれいる場合のよくある原因
・恐怖によるマネジメント・・・トップから最下層まで恐怖で運営されている。やめるのをすすめていた
・コスト削減のための人減らしへの恐怖・・・首切りをかわせないかと長時間働く
・個人的な失敗に対する恐怖・・・仕事に自信のないメンバーは、能力を高めてくれる追加研修やコーチングより長時間働く方を選ぶことがある
・プロジェクトの失敗に対する恐怖・・・計画通りのスケジュールで時間が足りないとおもうとスタートダッシュをかけることがあるが、続かない。
・プロジェクトの失敗が確実な場合の個人的避難位対する恐怖・・・きたるべき大失敗の咎を逃れる為に、あえてこれ見よがしに長時間はたらく
早い段階の残業は、プロジェクトが思わしくない予兆
３３ ポーカーの夕べ
職務に関係ない活動のために組織のあちこちから従業員があつまり、顔見知りなるのは、組織にとって有効である。
しかし人為的にコミュニケーションの流れを円滑化しようとしても、個人が自らの意志で参加しているという意識が乏しいのであまり有効でない。人々が集まり、楽しみ、とに成功する状況をつくるだけでいい。あるいは集まった人の活動をつぶさないようにすればいい。
例としてポーカーの夕べ、マラソンの給水所のボランティアなど
３４ エセ品質ゲート
意味が欠落しているのに、形式の心配をしても仕方がない。
We eat breakfast in the evening.
構文は正しいが意味は通っていない。
エセ品質ゲートの兆候は、フィードバックのうち、内容でなく形式が大半を占めていることでわかる。
無益な手続きに時間が浪費させられたうえ、内容の欠陥が見過ごされることになる。
３５ テストの前のテスト
製品開発のごく初期の段階や各イテレーションの初期にテストを開始する。
プロジェクトで予定されている成果物が完成したときに、間違いがないかどうかテストできるするためのテストは、あとのテストの有効性を高め、エラーを避けられる。
これを行わないのは「期待通りに動く」とはどういうことかが正確にわかっていないから。
初期テストは要求だけでなく、あらゆる成果物に有効。製品の設計、プロジェクト計画、スコープ文書などテスト可能な形式で提出されれば初期テストのメリットを享受できる。テストされると思えば製作者の意識もちがうので中間成果物がわかりやすくなる。
製品ができあがってからテストしてもプロジェクトの成功の役にはたたない。
テストの前にテストすることは、最初から品質管理を導入することである。
３６ サイダーハウス・ルール
現場にいないひとが決めたルールは、無視されるか回避される。
ルールは必要だが、策定には作成者が現場に入り、現場の人の世界を共有することが必要である。
３７ まず話す、次に書く
大企業や分散チームは文書に頼る傾向があり、小規模なチームは会話に頼る傾向がある。
優れたチームは、その時その時の作業に応じて、文化的にあまり慣れていないコミュニケーションでも採用するよう心がける。意思決定を短時間で効率的に行うには会話を使い。あとに残すべき決定を伝えるときは文書を使う。
３８ ダボハゼ
心の中で仕事は多いほどいいと持っていませんか？
しかし、最大限の側で処理できる以上の仕事をひきうけていると、いずれ遅くなるのは当然。
多くの組織は膨大な量の仕事を完成させようとして、ほぼ停滞状態にまで減速してしまう。
立ち止まって価値あるものとないものに選り分ければ、自分たちが山ほどのカスのために遅くなっていることに気が付くはず。
３９ アトラス
アトラス＝なんでもできる優秀なプロジェクトリーダー
一見問題ないようにみえるが、自分でなんでもやってしまうために他のリーダーが育たない。だから運営できるプロジェクトの規模に限界があり、アトラスが抜けた後はだれもフォロー不可能である。
４０ 裸の組織
情報が多すぎると注意力はなくなる。
全員がすべてのことを知っている必要があるならその組織はおしまいである。
多くの情報を抱え込むことの問題は、情報をうけとってそれに文句をいわなければ事実上同意したことになること。
多くの情報を抱え込もうとして、自分の情報プレートをあふれさせてしまうのは、はじめて大人の宴会に参加した子供がおいしそうなものをすべて口に抱え込んでしまうようなものである。
４１ ピア・プレビュー
採用候補者と同僚になるスタッフを採用プロセスに参加させるのは、採用される側、受け入れる側双方にメリットがある。もちろん一次審査などはマネージャの判断が優先されるべきだが、面接はスタッフで行い、多数決で決める。
チームリーダーの採用もそうしてはどうか？
４２ シュノーケリングとスキューバーダイビング
広い範囲をみるならシュノーケリング、深く潜って調べるならスキューバダイビング。優れた開発者は自分を制限しないで、なにをみるべきかによって方法を選ぶ。
４３ いまいましいインターフェース
まだ細部まで煮詰まっていないプロジェクトの初期段階で、実装が可能なほど厳密にインターフェースを宣言するのは難しい、しかしわかるかぎりのインターフェースを定義しなければならない。インターフェースの欠陥をよく知っているマネージャはプロジェクトチームのインターフェースに気を配り、どこかのグループがインターフェースについて誤った仮説をたてる可能性とたたかう。
プロジェクトの人間のインターフェースが複雑だと製品のインターフェースも複雑になる
４４ ブルーゾーン
プロジェクトの任務を割り当てるには、3つの権限ゾーンをつくること
・グリーンゾーン・・・明確に任務の一部であること、つまり遂行すべき仕事の核である。
・レッドゾーン・・・任務の範囲から明確に除外されるものがすべて含まれる
・ブルーゾーン・・・それ以外のすべて、任務で求められても禁じられてもいない活動。
ブルーゾーンで行動し、ときにレッドゾーンで行動させてほしいという人物は貴重である。ひやひやさせられるときもあるが、その大胆さのおかげで、当初の任務で想定されていたものよりも革新的で優れたソリューションを創り出すこともよくある。
４５ ニュースの改良
組織によっては悪いニュースがまったく上に伝わらないことがあるが、それ以上に多いのが悪いニュースが1階層上がっていくたびに改良される例。
チームリーダー「おそらく1月は無理です」
↓
プロジェクトマネージャ「正直言って1月では不安です」
↓
アプリケーションマネージャ「1月というのは難題だと思いますが・・・」
↓
CIO「1月には間に合うと自信をもってご報告します」
原因は組織の文化として「悪いニュースを伝えた人が災難にあう」がある。
プロジェクトが困難な状況にあることを証明できるまで時間がかかる。早くに間に合わないといえば臆病者といわれる。だから惨事がだれの目にも明らかになるまでだまっている。
悪いニュースを隠すと解決できる問題が解決できない問題になってしまうことがある。
４６ 真実はゆっくり告げる
本当のことをゆっくり告げる理由は
・企業文化として散らかっていることに気付いたものが片付けろという空気があるので、真実を告げると尻拭いをさせられる。
・すぐに対策をたてられないのに問題をもちだすと「泣き言」といわれる
・他の誰かがもっと大きな問題を暴露して自分たちの問題が陰にかくれるのをまっている。
こうして真実を話したらつらい目にあるだけだと学ぶ。
組織は真実を知りたくない、できるだけ長く幸せに浸っていたいのだ。
４７ エンドゲームの練習
エンドゲームの練習をするチームは、プロジェクトの早い段階でリリース基準を作成する。次に製品がリリース基準をみたしているかどうかを評価するために必要なテストを開発する。開発のイテレーションが完了するたびにこれらのテストを実行し、そのあとで簡単なレビューを行う。
こうすることで、
・チームは開発のどの段階でも、製品を出荷するための残りの作業にあらためて専念できる。
・以前満たしていた基準から後退した場合、早い段階で気付くことができる。
・途中でリリース基準を見直す機会が何度もある
もし早い段階で測定が難しいなら、大きく未定と書いておくだけでも効果はある。
４８ ミュージックメーカー
IT組織には音楽をたしなむ人が多い。
自分の組織で周囲に田津寝て、音楽家の同僚が何人ぐらいいるかたしかめてみよう。結果はiPadへ
４９ ジャーナリスト
プロジェクトマネージャーが、なんのためにプロジェクトの状態に注意を払うのか、それを見失うとジャーナリストになってしまうことがある。プロジェクトの状態を正確に描写するのが目的になり、プロジェクトの成功とは別の成功をおいかけてしまうのだ。映画評論家と似ている。
５０ 空席
多くのプロジェクトには「ユーザーの立場に立って、製品が完成したときにビジネスプロセスがスムーズに機能するように考える」という任務を負った人が一人足りないために本当の成功をおさめることができない。
プロジェクトマネージャやリーダーではなく、ユーザーと製品がどのようにかかわり合うかということだけに神経を使う人をおくべきだ。（顧客サイドにいるのでもいい）
多くのプロジェクトはこの席が空いている。
５１ いとこビニー
良い解決策を求めて議論するメンバーは、お互いを尊重している。お互いのことが好きだといってもいい。そうでなければ生産的な議論はできない。議論が流れているとき、チームのメンバーは自分たちのアイデアを議論を精査することは攻撃ではないとしっている。最高の製品を効率的な方法で完成させようとしているだけだ。
経営陣やチームリーダーの発言はたとえ好意的でも、悪意がなくても同じようには受け取られない。仲間内（いとこのビニーだとわかっているから）安全なのだ。議論は上下関係を確立するためでも、個人の知識をひけらかすためでもない、相手のアイデアを試し、進化させようとしている。
５２ 機能スープ
人は普通自分の要求が最も大事だと考える、同じ組織でも場所が違っていたり顧客が違ったりすれば、自分たちの独自の機能がほしくなる。その要求がビジネス全体の整合性を考慮していないのも普通のこと。
この問題にアナリストが適切に対処しなければ、無関係の断片をはぎあわせた製品ができることになる。
そうしないために
・何がプロジェクトの目的で、何が目的でないか、可能な限り早い段階で明確に定義している。
・プロジェクトのスコープを、入出力データの正確な定義と対照して宣言し、つねに更新している
・明言された目標に寄与せず、プロジェクトのスコープの範囲外であることがあきらかな要求は鉄の意志をもって拒否する。
・新しい要求は、承認・変更・追跡という一連のプロセスを通して、その過程でプロジェクトの目標と比較評価する。
機能のスープを避けるには自制が必要。スープになって困るのは断片的な要求をしたひとではなく自分である。
５３ データエラーの真犯人
データベースソフトの品質より、処理するデータの品質の方が劣っているのはよくあること。
でも、数の少ない方がシステムの品質低下の原因とされ、ソフトの方を変えようとする。
データが壊れているなら以前のバックアップが使えるし、同じデータを複数のシステムに別々に記録している場合に自動データクレンジグが使える。
しかし、データの品質が低下する最大の原因は変更で、そのような損傷は手作業でなおすしかない。他の方法を空想してもツケを先延ばしにするだけだ
５４ その名は「ベン」
ベンは素晴らしい数学の才能をもつエンジニアである。通常のプロジェクト業務の他に、一人で解決できない問題を抱えている人たちを手助けする。問題がベンの職務の範囲外であること、部署の範囲外であることさえある。でも仲間と一緒に考えているうちに、たいてい良い解決策を思いつく。
ベンは仕事を楽しんでいる、仕事を愛し、仕事にやりがいを感じ、仕事をクールだと感じて、決して金のために働いているのではない。
ベンはいたるところにいる。さまざまな仕事をしている。そして扱いやすい。だから扱いを間違えやすい。
あるマネージャは欠員がでたときベンに仕事をまわして欠員を補充しなかった。最初はよかったが、仕事が耐えられないレベルに達したとき、ベンは仕事が楽しくなくなって会社を去った。
ベンの仕事はすぐみつかるだろう。でも、マネージャはベンを見つけるのは難しいだろう。
５５ ミス・マナーズ
仕事の結果と仕事をした人間がいっしょくたにされるのは間違い。
人を批判するのをさけようと、礼儀をまもっているのは、弱気。
こういったミス・マナーズの職場では批判は許さないという暗黙の掟がある。
５６ 知力の集中
一つの演目に集中したほうが舞台はうまくいく。
プロジェクトもフルタイムで参加したほうが、切り替え時間の無駄がなく、個人のパフォーマンスは最高になる。
５７ 野球に泣くなんてのはないんだ！
自分の仕事に情熱的になれる人をプロジェクトに投入することは、成功の秘訣である。
情熱は時に爆発するが、その後始末くらいは高い目標を達成するために支払う代償の一部にすぎない。
仕事を大事にしていなければ、仕事に感情が入り込むこともない。
５８ 暴力脱獄
仲間同士の意見の違いを「コミュニケーションの失敗」にするのは間違いである。
仕事の対立はプロらしくないというのは思い込み。
品質と生産性は常にバランスをとる（対立している）。
そこらじゅうにれっきとした対立があることを認めよう。そして実証された対立解決手法を使おう。
その方がコミュニケーションの対立より確実によい結果が生まれる。
５９ 期日はかならず守る
必ず期日をまもるなら、品質基準はゆるんでいるはずだ。
組織にあるプロジェクトのかじ取りのための５つの「レバー」
1.人 2.技術 3.スコープ（どのような機能を開発するか） 4.時間（いつ完成させる予定か） 5.出荷時の品質基準
時間がたつにしたがって、使えるレバーは４と５だけになる。
６０ フード＋＋
「千と千尋の神隠し」は夏の公開に間に合わせる為に長時間働くことにした。そのためチームの誰かが全員の夜食の用意をするようになった。一緒に調理して食事して後片付けをすることでチームの結束は強くなり、映画は期日までに完成した。
食べ物は人々を結びつける。
一緒に食事をしたからといって、チームが成功する保証はない。しかし、成功するチームは一緒に食事をつくって食べることで生まれる豊かな対話を利用することが多いようだ。
６１ ほったらかしの成果物
あらゆる成果物のなかで間違いなく必要なものは製品だ。しかし他のものはどうだろう。
もし、品質管理や再利用のために作成する成果物があるのなら、その作成のリソースにはスポンサーを探すべきだ。
コストにみあう効果があるかどうかを検討しないで、あれをつくれこれをつくれというのは簡単。しかし資金も人間も出さないのに現場がすんなり受け入れるとは限らない。また作成されてもほったらかしになる。
アイデアがいいならスポンサーを探すべき。
６２ 隠れた美
指定された機能が果たせるかだけが仕事の成果であり、美観など関係ないというのは間違い。
すべてのデザインには美的要素があり、すぐれたマネージャは部下のデザインを詳細に見る能力と意思を持つ。すばらしい設計を評価する。
すばらしいデザインはそぎ落とすことにある。どんなに機能をつけたしてもデザインはよくならない。
６３ わかりません
「わかりません」をやる気のない証拠とみる組織は、すべてのことを知ることができないという真実を無視している。
「わかりません」ということで、助けが得られる機会が得られるのをすてて、余計な時間をかけている。
「わかりません」が言えるのは、人々が安心して助けを求められるということ、あらゆる階層で真に協力を推し進め成果を得ることができるということ。
６４ レイクウォビゴンの子ども達
大規模チームのメンバーの間では、ソフトウェア工学の能力にケタ違いの差があると何十年もいわれている。
それなにに、成績評価はほぼ全員平均以上の評価をうける企業が多すぎる。
この場合マネージャが真実をつたえているのは本当に中程度のぶかだけで、成績優秀な部下に彼の仕事の素晴らしさを伝える機会を失い、成績の悪い部下に、このままでは首が危ないと知らせる機会を失う。
そのかわり、成績の悪い部下のコーチ役になったり、任務を縮小して失敗しないようにしてしまう。そんなことより恐れず建設的に向き合った方がよい。水準に達していないことを知れば努力して人並み以上になるかもしれない。
６５ 共同学習
プロジェクトが始まるときに、将来どのような状態になるのが望ましいのか、個人やグループが理解していると考えるのは非現実的である。
つくり手は消費者が要求を完璧かつ正確に列挙できないとしるべきだし、消費者は作り手が要求を正しく理解できると考えてはならない。
必要なのは共同学習である。
開発が始まらないうちに要求仕様書の作成を済ませようとするのは間違いだ、初期プロトタイプや試験モデルをつくり発見と学習を繰り返すべきｄ。
ステークホルダーの中には、自分は何が必要かわかっているという人がいるが、そのような人が必要だとするのは目の前ｎ問題に対して思いついた解決策で、もっと大きなニーズに応じられる解決策ではない。全員が理解するのは問題であって、解決策はそのうちでてくるものである。
学習は早くはじめるのがよい、プロジェクトが進行するとアイデアが固まってしまう。早いうちに機会をとらえイノベーションを成功させよう。
ステークホルダーはそれぞれ何かを、それもかなり多くのことを知っている。互いに教えあるために共通の言語が必要で、モデリングを繰り返し、それをすてて学習は進む。
もっとも難しいのは共同学習に努めることが必要だと認識すること。
６６ 魂の仲間
仮に「ゲリラ」チームと呼ぶ開発チームがある。アジャイルの世界によくみられる。非常にイノベーションに優れたチームである。
特徴は
・予定された会議は嫌うが臨機応変に少人数の会議を何度も行い、そのほとんどが設計会議になる。
・アイデア、デザイン、ToDoリストをメモするのにホワイトボードを好む
・不完全で高水準な要求定義書をもとに作業する。せっけいぶんしょはすべて省略し、開発プロセスのごく初期からコーディングに移る
・大量のコードを破棄しては書きなおす。機能のデモを行うと、すぐに改良にとりかかる
・これらを非常に速く行う。一般的な機能の開発にかかる時間は1-3日、極めて複雑なら10日、多くのタスクは半日で完成してテストできるようになる。
従来型のソフト開発では「問題を見つけて修正するコストは開発サイクルが進むにつれ急激に上昇する」という考えに基づいて、できるだけ早く要求と設計をきちんと定義しておきたがる。またきちんと機能するソフトの構築と検証には時間がかかるので、それは1回か2回だけとする。
ゲリラチームは何を構築すべきか発見する過程で迅速にコードを開発してテストするため、実に大量のコードを破棄する。こういったチームは新製品のバージョン１にむいている。得意なのは比較的新しい問題涼気を探索し、革新的なソリューションを考案すること。耐久性と安全性に優れたコードもつくれるが、イノベーション志向である。
たいていは一人か二人の魅力的なリーダーの周りに有機的に発生し、ゆっくりと増えていき、結束が弱まるとあっという間にバラバラになる。命令によってつくることはできないし、ずっと維持することもできない。
ゲリラチームに仕事をさせるなら新天地を与え、システムが確立してしまったら他の新天地を探せるようにすべき。
最後に「偽物が多い」、このモデルはあらゆるレベルの開発者にとって魅力的なため、少人数チームの多くは自分たちをゲリラチームだと思っているが、本物は稀。まかせるなら相手が本物かたしかめよう。
６７ 十字穴付きねじ
ヘンリー・F・フィリップスが十字穴付きねじを開発したのは1930年代初頭だが、使われだしたのは1985か1990年ごろ。
明らかに優れたアイデアであってもすぐに受け入れられるとは限らない。
トーマス・アルバ・エジソンは、何度も新しいアイデアを考え付く能力があった。
一つのアイデアを推奨する人はプロモータであり、過去にいくつもの優れたアイデアを考え付いてきた人はイノベータである。イノベータになるには何年もかかるが、地道な努力を伴うが、予想外の恩恵がある。実績のあるイノベータの提供するアイデアは人々にうけいれられやすい。
６８ イノベーションの予測
プロジェクトのイノベーション・・・チームがそれまで経験したことのないなにかをやるということであり、メンバーが問題を違った方法で解決できるかどうかにプロジェクトの成否がかかっているということである。
一方で完成する時期をかなりの精度で予測する必要がある。
マネージャは開発者にイノベーションの時間を提供しつつ、顧客にはプロジェクト完成について正確な予測を提供しなければならない。
どちらかの領域に迷い込まないためには、開発プロセスのイテレーションをおこなうこと、それぞれのイテレーションの器官は1回につき1-4週間で、１－３までは未知の要素を洗い出し、開発作業に持ち越す不明点を減らすためにあてられる。この間のコードは次のイテレーションに使われる必要もない。
決められた開発期間の中でイノベーションを必要とする問題領域を何度か通るようにすることで、バランスをとる。
プロジェクトの成功の源はイノベーションであるが、予測可能性も必要である。
６９ マリリン・マンスター
「マンスターズ」はモンスター一家のはなしである。金髪美人のマリリンは一家の親戚で美人な人間の容姿をもっているが、一家の仲では不器量で役立たずといわれる。
マリリンのような人生を送っている開発者の組織は、マネージャが主役だ、開発者はコストの一部であり、取り換えの聴く部品だと思われている。給料もマネージャのほうが断然多い。変化形として営業があらゆる権限をもている組織もある。
反対に開発者の能力の差が大きいことを理解して、よい開発者を雇うために努力している組織もある。そのような組織は自社のソフトウェアまたは製品の主要部分を自社で開発しているところが多い、
開発者がキングの文化が行き過ぎると、自分の仕事を最適化しすぎて、プロジェクト全体の最適化を妨げることがある。
組織の成功のために品質とイノベーションが重要であり、そのためには本当に有能な開発者が必要である。
あなたが優秀な開発者なのに、マリリンのような気持ちなら、他の家庭を探すべきである。
７０ ブラウン運動
プロジェクトの最初に人数を投入するのは間違い、ビジョンを形成するのは少人数のグループである。
Linuxのビジョンは一人がつくり、C++もそうである。
７１ 音吐朗々
プロジェクトの目標はもっとも高いレベルでの要求と制約である。
相容れない個人的目標がある人間たちがまとまってプロジェクトの成功に向かって働くために必要である。
よい目標は、ステークホルダーが対立しない目標になっており、そして目にみえるところに常に掲げられるべきである（会議室では椅子を与えよう）
７２ 安全弁
チームは仕事の緊張に立ち向かうため、ガス抜きの方法を考え出す。
「シークレット・アサシン」・・・それぞれのメンバーに標的が割り当てられ、同時に他のメンバーの標的になる。みなはナーフガンを携えて標的に忍び寄るが、標的が自分のデスクにいるときには暗殺することはできない。
シークレット・アサシンが生産性を高めることがわかっている。
ただし、チーム内で自然に発生したものでないと意味がない。上司やマネージャが指示しないこと。
みつけたら、黙ってみのがそう。奨励もいけない。
７３ バベルの塔
お互いが使っている言語が、同じ意味か確認することは重要だ。
しかし組織は常に変化し、言葉の定義も変わっていくものだ。それでも定義にこだわっていくことが大切
チームが一貫した言語をつくっても、その努力は外部から評価されないが、言葉の定義につりつかれたようにこだわるチームは成功するチームだ。
７４ サプライズ
ささやかなサプライズ報酬を提供する弊害。
こんなはした金のために、貴重な家族との時間をすてたのではないといわれる
プロジェクトが終わったらどんなサプライズ報酬？がもらえるかと期待する人がでる
７５ 冷蔵庫のドア
すべての情報を伝える必要はないが、すべての情報を開示する意味はある。
冷蔵庫のドアのように、みんなにみえるところ（廊下や作戦会議室）に成果物や進捗状況をはっておく。
冷蔵庫のドアは面倒な文書配布やバージョン管理の手間をはぶき、メンバー間の信頼関係をよくし、不完全な点やスケジュール遅れを他の人に見つかるのを恐れる必要がなくなり、ねつ造はなくなる。全員同じ基準で作業できるようにあうる。
７６ 明日には日が昇る
マネージャは将来の進捗の平均を、過去の進捗の平均より上になると信じている。
しかし、それは危険だ。
たとえ、現在の進捗が偶発的要素による不幸な結果であっても。この先もそういった事態が起こらないという保証はない。
いままでの進捗速度で将来をみて、スケジュールの変更やスコープの変更を行うのが賢明である。
７７ パイリングオン
アメリカンフットボールのパイリングオン・・・すでに倒れているボールキャリアの上に守備側のプレーヤーが飛び乗る反則行為
プロジェクトを失敗させたかったら、パイリングオンをおこなえばよい、すなわちそのプロジェクトをもっとよくすると称して追加機能をいれるのだ。
開発期間を複数のイテレーションに分けているプロジェクトでは、パイリングオンに対する免疫がある。初期のイテレーションで重要な機能のみを実装し、その他は最後に追加するのだ。追加するコストが、効果より高ければ機能追加をやめるという選択肢をとることができる。
７８ 変更の季節
スコープ（白線）の定義はプロジェクトへの影響が大きい。
しかし、いつでもスコープが変更できるようにすることは、開発の遅れを引き起こす。
イテレーションの間に限定すべきである。もちろん長すぎるイテレーションはいけないが。
７９ 製紙工場
文書を作成する人に「なぜ」と聞くと「プロジェクトのこの段階ではこの文書を作成しないといけないから」という。
「その文書は正確にどういうことを書くんですか？何のための文書ですか？誰が意思決定に使うんですか？」ときくと、そこまでわかっていないことが多い。このようなプロジェクトは製紙工場になっている可能性がある。
みんながコピーを欲しがる。文書さえあれば、プロジェクトの目標に貢献する有益な仕事をしているかどうかを検証しなくなる。
製紙工場でないプロジェクトチームは自動的に文書をつくるのでなく、その他の方法で進捗状況を伝えることを考える。ホワイトボード、テレビ会議、ブログ、プロトタイプなどだ。成果物はプロジェクトライブラリに置き、だれでも自由に入手できるようになっている。
重要なのは、作成される文書はすべて何らかの明確なニーズを満たすもので、その内容はプロジェクト全体の知識にもとづくべきであるということ。
８０ オフショアの愚行
サブコンポーネントのインターフェースの複雑さを最小限にするようにシステムを分割するように、開発チームのワークフローの設計もするべきだ。
サイト間コミュニケーションとサイト間イテレーションのコストを甘く見積もってはいけない。
オフショア開発資源を利用するなら
・イテレーションはローカルで、一つのサイトで行う
・オフショア開発モデルの最初の数回は国内で同じことをするより時間がかかると認識すること
・オフショアチームは国内開発チームとかわらない、やりがいのある仕事をしたいと思っている
・各サイトの目的を育てる。活気あるサイトは具体的使命がある。雑多で多数の開発をおこなっていて、共通の目的もなく各チームをサポートするサイトはエネルギーも士気も低い。（国内でも同じだ）
８１ 作戦会議室
専用の作戦会議室をもつプロジェクトはまっしぐらの成功へ向かう傾向がある。
直接会って存分に対話することがプロジェクトの成功のために必要だという姿勢の表れ
成果物を壁に貼って掲示するのはチームの結束を強めるためにも、作業を推敲するためにも重要だという主張の表れ
プロジェクトのメンバーは作戦会議室の近くにいて、プロジェクトマネージャは作戦会議室にいることが多い。
ただし、ただ作戦会議室のスペースを確保するだけはだめで、作戦会議室をプロジェクトの活気あふれる有機的なプロジェクトの要素にすることである。
８２ 何のにおい？
組織の中にいる人は、組織の根底にある生命力にも腐敗にも気が付かない。それはパン屋のにおいのなかでも鴨の農場でも人間はにおいに慣れてしまって気が付かなくなるようなものだ。
外からの新鮮な鼻を持ち込み自分の周りのにおいをかいでもらおう。そして次の行動をきめよう。深呼吸して何もかえないか、窓を少し開けるか、燻蒸消毒するか
８３ 身につかない教訓
プロジェクトが終わってから反省し教訓を引き出すのは難しい。
問題がチームの外にあったり、内にあったら変化を起こすのは気が遠くなるほど難しいからだ。
反省会のプロセスがガス抜きで終われば、公表されるのは所見ばかりでアクションアイテムはない。
反省で成果をあげる勇気ある組織になりたければ、チームの権力の内外に実現可能で明確なアクションアイテムをあげることだ。
８４ 生半可なアイデアの美徳
チームのメンバが生半可なアイデアをだしあえる文化があるべきだ。
人は新しく考えるより、あるものを改良するのを好む。たいていのアイデアは根気よく取り組めば改良できる。すぐれたアイデアでなくてもたたき台になる、議論を通じてアイデアは成熟し向上する。
生半可なアイデアを封印すればイノベーションがおきる可能性を封じてしまうだろう。
８５ リーク
時間とコストは、注意深く測定されるカテゴリーからさほど厳しく測定されないカテゴリに逃れる傾向がある。
これは割り当て時間いっぱいまで作業してしまって、まだ完成していないからと別の作業に、今使っている時間をわりあてたり、締め切りがまだ先の作業に割り当てたりすることである。割り当てが残り少ない仕事、締め切りの近い仕事は注意深く観察されるからである。
こうしてリークはプロジェクトがコントロールを失う。
８６ テンプレートゾンビ
製品を完成するために必要な思考プロセスではなく、テンプレートによって作業をすすめる。
こういうチームは文書の内容と検討するより、標準文書を作成することに懸命になる。
テンプレートが埋まっていればよしとするのだ。
アイデアがテンプレートの項目にあわなければ無視したりする。
テンプレートはチェックリストやフレームワークになる良い方法だが、固定化して埋まっていたら成功と考えるのは間違いである。
アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン
- 作者: トム・デマルコ
- 出版社/メーカー: 日経BP社
- 発売日: 2009/10/22
- メディア: 単行本
タグ：トム・デマルコ
コメント 0