古典から読み解く、炎上プロジェクトの防ぎ方
https://images-na.ssl-images-amazon.com/images/I/513Y-C2739L._SX355_BO1,204,203,200_.jpg
著者は「銀の弾丸」で有名なフレデリック・ブルックス
IBMでOS/360の開発グループマネージャなどを務めた
1999年のチューリング賞受賞者
ソフトウェア工学/プロジェクト管理の本
正直、詩的/散文的でわかりにくい…
初版は1975年(マイクロソフト創業年)
20年後に再検証した章を追加した増訂版
具体例は確かに古いが、本質的な部分は未だ色あせず
タイトル
「ソフトウェア開発の単位である「人月」という概念が、神話に過ぎない(つまり、意味をなさない)」=人と月が交換可能だという”幻想”は捨てなさい
結論
10人月の仕事=1人で10か月かかる仕事は、「人月という単位が絶対であれば”10人で1ヶ月”でできるハズ」だが、そんなことは起こりえない。そして、この状況を打破し、遅延したプロジェクトに100人投入して一瞬でシステムを完成させるような「魔法の道具(=狼男に決定打を与える”銀の弾”)」は存在しないという結論。
すっごい武器はないが、まぁまぁ効く武器は結構ありそう。
⇒ 「人月の神話」の内容を紹介しつつ、ラボのプロジェクト管理について考えてみたい
「☆」は最後にラボの現状に対して提言したい部分
目次
「人月の神話」の内容
1. タールの沼:システム開発は難しい
2. 人月の神話:なぜプロジェクトは失敗するのか
3. 外科手術チーム:生産性を上げるには
ラボのプロジェクト管理について
4. 銀の弾丸はない:できるところから
タールの沼:システム開発は難しい
システム開発の難しさ
本質的な難しさ( = 抽象概念をシステムとして具象化するという作業に付随する難しさ)
複雑性
大きさの割におそらく他のどの人工構造物よりも複雑
同調性
他のもの(社会制度、人の振る舞い、業務のあり方、既存のシステム)に合わせなくてはならない
複雑な人間/人間社会を写像するために、その複雑性を内包する
可変性
物理的なものと違って変更しやすい、変更が当たり前
媒体(PCやスマホなど)の進化も早いので、それに合わせた変更も必要になる
不可視性
プログラムの構造などは基本的にビルほど単純には視覚化できない
複数人での共通認識形成を困難にしている
付随的な難しさ
言語、開発環境、スペックなどの制限
付随的難しさは解消されつつある
高水準言語
タイムシェアリング(メインフレームを複数人で同時に使用するための方式)
統一されたプログラミング環境
では本質的な難しさを解決するには?(長期的、包括的な目線で)
市販品の利用
自分で作らないで、できてるものを買えばいいんじゃないか?
⇒パッケージの利用やXaaS/APIの広がり
ラピッドプロトタイピング
要件を定義するのがメチャメチャ難しい上に、メチャメチャ重要なんだから、仕様を決めきって作るんじゃなくて、プロトタイプ作成と仕様作成を往復しながら進めるべきなんじゃないの?
⇒アジャイル開発とfigmaなどのデザインツールの進化
インクリメンタル開発
システムを「構築する」のをやめて「育成する」ことにしたらどう?とりあえず動くものを作ってから、ちょっとずつ機能拡張していこうよ。
⇒☆アジャイル開発
偉大なデザイナ( ≒ カタリストとデザイナ)
デザイナを育てませんか?結局、画期的なソフトウェアって、少人数の天才がつくるもんだから、そういう”天才的な人”を育てるしかないよ。
まずはデザイナの重要性を認識する
早期にトップデザイナを認定、有望な人材を弟子にする
キャリアアドバイザを認定、キャリア開発計画を策定/実行
育成中のデザイナが互いに交流・刺激し合う機会を与える
人月の神話:なぜプロジェクトは失敗するのか
上記の困難性を持っているのはわかったが、それでも成功させなければならない
では、プロジェクトがなぜ失敗するのか=スケジュールに時間的余裕がないことが原因のほとんど
1. 楽観的/あいまいな見積もり
2. 進捗が監視されていない
3. 人と月が交換可能だと仮定している
4. 遅延が見つかったときに要員を追加する
1. 楽観的/あいまいな見積もり
エンジニアは楽観主義:「みんなうまくいくに違いない」
システムテストに十分な時間をとる事が重要
見積もり比率(テストが半分)
1/3 計画
1/6 コーディング
1/4 単体テストおよび初期システムテスト
1/4 すべてのコンポーネントを統合して行うシステムテスト
投下工数の半分くらいは、プログラミングやデバッグ”以外”の作業に費やされる(書類作成や打ち合わせなど)
一日にプログラミングできる時間は50%(ハード等トラブル、ミーティング、書類作成、社内事務、病気、私用など)
PMが見積もりに自信がなく、思いやりのある頑固さに欠ける
得意先の希望する納期に合わせた間違ったスケジューリングは、他のどのエンジニアリング分野よりも、ソフトウェアエンジニアリングで頻繁に行われている。
顧客が何を言ったかということに依らず、常に「正しい見積もり」を行うことが、破綻しないシステム開発を行うための鍵
⇒☆生産性やバグ発生率の数量化、見積もり基準などを開発すること。そしてそれを公にすること。
2. 進捗が監視されていない
「プロジェクトはなぜ1年も遅れるようになるのか? … 一度に一日ずつ。」
まずはスケジュールを作る
☆自分も欺けないレベルでマイルストーンを定義する
遅れは悪だと認識せよ
1日の遅れにも躍起にならなければならない。この程度の遅延こそが、まさしく破局の要素なのだから。
遅延を隠さない
遅延を上司に隠す理由
自分自身で解決できる可能性があり、それこそが自分自身の仕事の本分のはずだ、という自負
問題を報告したら、権限を奪われ、今のままでも上手くいくはずの他のことまで台無しにされてしまうのではないか、という危惧
⇒上司が、現場リーダーの話を落ち着いて聞き、パニックに陥ることもなければ、頭越しに権限を発動したりしないこと
⇒マイルストーンを逐一確認する
3. 人と月が交換可能だと仮定している
「家を建てる」という場合に、100人日(5人月)かかるとする。それを3人の大工さんで2ヶ月弱で作る、というのが一般的だとした場合に、100人連れていたら1日でできる、、、ハズがない。
交換性
単純作業
交換可能→システム開発にはほとんど存在しない
コミュニケーションが必要な場合
人を増やしても、コミュニケーションも増える
テクノロジー、仕事のゴール、総括的戦略、作業計画について絶えず教育必要。要員数に線形比例
https://bst-image.imgix.net/prod-gixo/content/uploads/2015/06/man_month_08_001.png?auto=compress%2Cformat&ixlib=php-3.3.0?auto=compress%2Cformat&ixlib=php-3.3.0横軸:人、縦軸:かかる時間
複雑な相互関連を持つ場合
交換すると破綻する
https://bst-image.imgix.net/prod-gixo/content/uploads/2015/06/man_month_08_002.png?auto=compress%2Cformat&ixlib=php-3.3.0?auto=compress%2Cformat&ixlib=php-3.3.0横軸:人、縦軸:かかる時間
⇒単純な人月の交換計算をしないこと
仕事(この場合は「家を建てる」)を”プロセス”に分解し、その順序・必要リードタイムを明確にしたうえで、それぞれのプロセス内で「人月」を算出。
その上で最適な増員数を算出する
4. 遅延が見つかったときに要員を追加する
もし遅れた時の対応
残人月を計算し、人員を投下する。納期は変えない ⇒ たいていうまく行かない
リスケ
仕事の縮小(仕様変更、あるいはQを削る、テストを削る)
遅れているプロジェクトへの要員追加は、さらにプロジェクトを遅らせるだけである
新たに投入された開発者が生産性の向上に貢献するまでには、時間がかかる。
人員の投下は、チーム内のコミュニケーションコストを増大させる。
タスクの分解可能性には限界がある。
遅延しているプロジェクトにさらに要員を追加することは、つねにコストがより高くつくことにはなるが、完了をつねに遅らせるわけではない
プロジェクトの初期段階で要員を追加するべき
⇒実際には上記の複数の対策が取られる
ブルックスの法則を考慮した上で、QCDの優先度を鑑みて、要員追加を検討する
米谷さん:普段見積もりどうやってるのか
津崎さん)経験則+α
米谷さん)TLEの方が見積もったらどうなるか基準
見積もった人が対応するケースはあまりない
実際には✕◯◯をバッファとして載せる
組織の生産力(平均値)で見積もるべき
田村さん)新卒基準で見積もることが多い
籾井さん)バッファは誰が載せる?
最後に1.3とかかけてる
係数をなににするのかはカタリストに任せる
上妻さん:1975年の前提
外科手術チーム:生産性を上げるには
生産性の高い「精鋭チーム」で大規模システムをつくろう
「少数精鋭の方が、大量のメンバーで臨むよりも生産性が高い」→規模が小さい時の話
少数精鋭で取り組めば、(生産性が高いので)トータルコストは押さえられるけれど、開発期間が長くなりすぎる
ミルズの案:少数精鋭で大規模システムに取り組むための方法
いくつかのカタマリ(セグメント)に分解して、それぞれを少数精鋭で取り組もう→フロントチームを作るってことか
外科手術チームの構成:執刀医と副執刀医は、討議においては対等で、意思決定においては主従であるべき
執刀医:チーフプログラマ。自分でコードも書くし、文書も作る。責任者。
副執刀医:経験は浅いが、執刀医のスキルセットを持っていて、対等に議論したり意見交換ができる。スキルはあるので、仕事を分担されたらそれを担当してこなす。
管理者:プロジェクト管理上のバックオフィス機能を担当。人事とか昇給とか設備の手配とか。
編集者:執刀医の文書作成を支援。
2人の秘書:管理者と編集者、それぞれに秘書をつける。
プログラム事務係:技術記録全般のメンテナンスを担当。各プログラムの更新記録をすべて記録し、メンバー全員に共有化する。
ツール製作者:執刀医が求める”生産性向上のためのツール”をつくったり、メンテナンスする。
テスト担当者:テストケースをつくったり、デバッグ用テストデータをつくったりする。テストの計画や環境準備も行う。
言語エキスパート:執刀医の”デザイン能力”とは別のスキルである”言語の特性を活用して、問題をうまく解決する能力”で執刀医をサポートする。
作業の分割と機能の専門化
n人いると(n^2 - n)/2通りのインタフェースがあり、潜在的には調整を必要とするグループの総数は2^nとおりとなる
チームを横断したシステム全体での「コンセプトの完全性」
このチーム間でのコンセプトの完全性担保のために「インターフェースの統一」などの打ち手が求められてくる
誰かが決めなければ、みんなが不幸になる
コンセプトは「完全」でなければならない
コンセプトの完全性は、デザインは一人または互いに意見が同じで共鳴しているごく少数の頭脳から考え出されなければならない
民主主義は無責任を生じさせる
何かを”決める”という行為は、ごく限られたメンバーが強い意志と責任を持って行うべき作業
しかしスケジュールの圧力によって多くの要員が必要
アーキテクチャとインプリメンテーションを分ける→カタリストとエンジニア
インプリメンテーション専門チームを作る→フロントチーム
「1人か2人でマニュアルをつくりあげる」ことを推奨
小さな判断が全体を通して一貫していることは、決して取るに足らないことではなく本質的なこと
⇒アイデア出しなどへの複数人の参画は否定しないが、意思決定は限られたメンバで実施されるべき
銀の弾丸はない:できるところから
ラボの運営は基本線は理にかなっているのではないか
ただし、細かい点は詰めていく必要がありそう
☆アジャイル開発
案件によってはありかもしれないが、ある程度の習熟度が必要
実質似たような状態になっているものもプロジェクトもあるので、アジャイルの概念を取り入れることはできそう
見積もりも難しいので案件の性質を見極める必要がありそう
☆生産性やバグ発生率の数量化、見積もり基準などを開発すること。そしてそれを公にすること。
見積もり基準がばらつきすぎている(人によって前提が違う)
そもそもどういった前提が必要なのかモレがち
実装に必要なコンテンツ
見積もり前提者の能力
1人日4時間で見積もったほうがいいのかもしれない
基準があったほうが、そこからの案件ごとの特性を考慮した見積もりもしやすい
☆自分も欺けないレベルでマイルストーンを定義する
「◯日に終わります」が、どこまで終わるのかくらいはきちんと定義した方がいいかも
動作検証、実装、エラー等ハンドリング、機能テスト
PR提出、レビュー修正、機能テスト、マージ
内部テスト、修正
そしてそこからある程度の逆算を行う
この本はマネジメント/要件定義寄りの議論だったが、システム設計とかもかなり大事だと思うので勉強していきたい
Q)炎上とはなにか?の定義がしっかりしていないと、そもそも対策できないのではないか
参考
👍 Yuki Agatsuma YukiAgatsuma.icon がいいねしました on 2021/8/25