プロジェクト管理: 2007年9月アーカイブ
Quality Software Management Volume4 Anticipating Change
Gerald M. Weinberg
Ｇ．Ｍ．ワインバーグ
大野�僅� 監訳
共立出版株式会社(2000)
この本は会社員時代に、ワインバーグに心酔していた時期に購入し、途中まで読んで、数年間そのままになっていたものです。
原題は、ソフトウェア品質管理 Vol.4、「先を見越した変革」。シリーズの4冊目で、組織としての変革に焦点が当てられています。
中身が濃い本で、要約は不可能なのですが、いつものように抜粋でエッセンスを感じてください。
I. 変革の実現をモデル化する
ソフトウェアの管理者は単にソフトウェアを育成するだけではない。同時に、ソフトウェア組織も育成しなければならない。このとき、組織の育成に比べれば、しばしばソフトウェアの育成努力など造作もないように見える。
2.サティアの変革モデル
システムは、外部要因を無視しようとはするが、まったくは無視しきれない。組織はふつう外部要因を排除して、「いままでの状況」に戻ろうとする。というのも、サティアが言うように、
慣れは、つねに快適さより強力である。
3.変革に対する反応
歴史的に、ソフトウェア工学組織において、ほとんどの戦略的な変革計画はうまくいかなかった。ツールは購入されても棚ざらしになった。方法論は何年間も取り組まれた挙句に決して定着しなかった。そこで、ナオミ・カーテンが言う通り次のように一時的流行がやってくる：
人びとは最新かつ最大の一時的流行を信じ込んで、人々が体験すべき変革がとてつもなく大変でめったにうまくいかないのを理解しないで、一時的流行に猪突猛進する。リエンジニアリングが良い（つまりは、悪い）事例である。突然、リエンジニアリングの偉大な導師（グル）たちは、人的要素の問題を過小評価したと尻尾を巻いている次第だ。
これらの事例のいくつかでは、計画がまったくなかった。しかしながら、計画にあったときでさえ、変革に対する個々人の反応が留意されなかった。これが、「予知」（パターン４）組織が変革計画者と変革実線家あるいは変革アーティストの双方を必要とする理由である。
あまりにも性急に速く、多くの変革を組織に押しつける管理者は、加速しようとしているまさにその変革を遅らせてしまう。同時に、もし管理者が「多くの変革を試みよ。そうすればそのうちのいくつかは定着するだろう」という戦略を採用すると、最後にはそれらのいずれも定着しないことを思い知らされる。
第9章 戦術的変革計画
リスクアセスメントはリスク管理ではなく、リスク管理の第一ステップにすぎない。第二ステップはリスク低減計画作業、すなわち予測不可能な環境下で予測可能な結果を得るための計画作業である。
第10章 ソフトウェアエンジニアのように計画する
工学とは、ある環境下でできるだけ多くを獲得するアートであるから、欲しいものすべては獲得できないときにこそ行使するものなのだ。工学とは、何かをあきらめる代わりに何を獲得するか、それはなぜかについての意識的な意思決定を意味するのである。
ソフトウェア工学管理は一連の選択であって、一連の強制ではない。良いソフトウェア工学管理とは、ベストプラクティス曲線上かその近辺にある。変数間のもっとも望ましい取捨選択（トレードオフ）を表すある地点に留まる能力のことなのである。
誰だろうとどんなグループだろうと、上下に安定したシステムから逸れて作業遂行することは全く不可能だ。システムが不安定だと何でも起こる。見てきたように、管理の仕事はシステムを安定化させることだ。不安定なシステムは管理層に対するバツ印なのである。
第11章 安定的ソフトウェア工学の構成要素
しかし最終的にはなすべきことを知るだけでは十分ではない。ソフトウェア障害の最大の原因は、管理層の性格と人格の障害であって、こうしたあまりにも人間的な障害が組織的変革を制限している。階層組織における管理者の職権故に、彼らの小さな愚行すら文化変革の最善の努力を水泡に帰してしまう。管理者は適合的に行動する必要があり、そうでないかぎり結果は破局に到る。
構成要素は根本的なだけに、改善をたやすいものと思ってはいけない。多くの組織で、改善を目指すソフトウェアプロセスを吟味する試みは、強い政治的反対に遭遇する。権力構造が専断的であればあるほど、あからさまな検討がもたらす脅威は大きい。
第12章 プロセス原則
テストの省略や後工程への遅延を許すな。工程周期の終りのほうへ押しやられたものはなんであれ、スケジュールのために犠牲にされる。
統計的プロセス制御は、ソフトウェア制御に適用できないと主張する人々を信用するな。彼らに欠けているのは、そうした制御を適用する正しいレベルととるべき適切な行動である。たとえば、彼らはコードの欠陥を計測するかもしれないが、その情報を設定されたしきい値を満足しない個人を責め苛むために用いるのだ。
どんな事柄でも不可視になるのを許すな。要件も、設計も、コードも、とくにテストはいけない。予防は治療よりもはるかに容易なのだ。
第13章 文化とプロセス
長い目で見て社会の強さは、ふつうの人々が自主的に行動するしかたに依存する。ふつうの人々は非常に大勢いるから重要なのであり、始終すべての人びとの監視などできないから、自主的な行動が重要なのである・・・。この自主的な振舞いこそ、わたしのいう「文化」なのだ。----J.ファローズ
管理層が伝達するすべての主題が意図的だとは考えられない。今日のソフトウェア組織に共通する主題は、意思決定してもそれを遵守できないことである。この主題は、管理層がする何かによってではなく、ほとんどは管理層がしない何かによって伝達される。
中間管理者が、自分の仕事を適切にしている場合、何がなされるかではなく、どのようになされるかにかかわっている。つまり彼らは、実際になされる事柄の背後にある理想モデルにかかわっているのだ。
フィル・フーラーの示唆：「わたしが組織文化に使用するリトマス試験は、別種の問題に遭遇した時の彼らの生産性である。たとえば、あるスイッチングシステム開発組織は非リアルタイム・クリティカルシステムにどのように取り組むだろうか？彼らに、新しい状況にどのように取り組むか尋ね、それから学習にどんなプロセスを用意するか注視すれば、多くの事柄を発見できる。」
第16章 要求定義プロセスを改革する
多くのソフトウェア組織にとって、高品質実現の主要な障害は不十分な要求定義（要件）プロセスである。
要件文書はソフトウェア製品によく似ている。それはソフトウェアのように情報製品であるから、
・可視化しなければならない
・安定させなければならない
・制御可能にしなければならない
粗悪な管理状況下では、要件の可視性はコードのそれより低くなったりする。プロジェクト内の人びとは少なくともコードについて考えるが、往々にして要件のことは忘れてしまうのだ。もっともよくあるタイプの要件欠陥はおそらく、プロジェクトの内の誰もある分野の要件について考慮しなかったというものである。よく忘れられる要件はたとえば、性能、操作性、保守性、セキュリティ、現行データの変換、現行システムとの統合、そして製造へのカットオーバーである。
管理者が要件落ちのないように保証する最も効果的な方法は、疑いもなく、要件開発をちょうどソフトウェア開発のように現実のプロジェクトに仕立てることによって可視化することである。
第17章 プロジェクトを正しく開始する
プロジェクトを制約する意思決定につながる一連の高レベルの交渉が、すべてのプロジェクトに先行している。情報が揃っていてかつ適合的な交渉でなければ、プロジェクトは開始以前から命運が尽きている。
以前この企業の「計画作業」たるや、リスク問題を提起した者全員がすでに策定済みの「計画」にコミットするまで、焼きを入れるという意味だった。
問題はしばしば、明確化に対する組織の恐怖に根ざしている。顧客は明確な要求定義を文書化すると、文書化した要件を満たすシステムが現実の必要を満たさなくなる場合、変更を発案した責任を負わなければならなくなる。開発者のほうは明確な要件を文書化すると、それを満たす説明責任を負わなければならなくなる。コストとスケジュールの見積りが不正確だとわかってしまうと、自らをリスクにさらす可能性がある。したがって。顧客と開発者は正反対の動機で動いているにしても、暗黙のうちに共謀して、「成熟度モデル」の要件管理慣行の履行を阻止しかねない。
注力時間報告をプロジェクト追跡に用いるな：それは単なる入力の計測であって、出力の計測ではない。努力ではなく成果を計測せよ。
管理レビューは、管理層への輝かしい報告ができないプロジェクトを懲罰する方法として、非難文化において愛好されている。
第18章 プロジェクトを正しく持続させる
計画は、敵の最初の一手までは有効である。----チェスの格言/軍事の格言
プロジェクト途中の管理者の仕事の多くは、不測の事態に対処するために一種類のスラック（余裕）を他の種類のスラックと交換することなのだ。
逆説的だが、人びとはスラック（余裕）を時間の浪費と考えて嫌悪するが、ほとんどのプロジェクトは、スラックを許容したほうが速く進捗する。
第19章 プロジェクトを正しく終結させる
これらのプロジェクトはスターリンの産業化政策の特徴だった。それは、小規模のプロジェクトよりも巨大プロジェクトを、安全性よりも成果を、人間よりも技術を、現場の自発性よりも硬直した中央集権的計画を、批判的論争を犠牲にする密室的意思決定を、そしてとりわけ狂気じみた猛進を重視したのであった。---L.R.グラハム
おそらく良い管理者の最大の挑戦と試練は、終結すべきプロジェクトを終結すべきときに終結する能力である。
「レビュー可能でない」ということは、それ自体が一つのレビュー結果である。もしレビューできていないなら、それが正しいわけがないし、出荷すべきではない。
ほとんどの遅延プロジェクトは、コーディングがかなり進捗するかもしくはテスト作業が始まるまで、日程通りにいっているように見える。そのとき、早期に行ったあらゆる便法的作業がテスト作業を遅らせて行き詰まり、プロジェクトが頓挫する。欠陥予防あるいはインスペクションを通じて早期に品質管理をしたプロジェクトは、テスト作業を一気に通過する。---ケイパース・ジョーンズ
士気は、プロジェクトの成功確率についての全メンバーによる総合評価と考えることができる。
第20章 小さく構築し、構築を加速する
構築プロセスの加速に活用できる基本戦術が二つある：
・構築能力を増強する
・構築規模を縮小する
結論からいえば、スケジュール延長が遅い時は、必ず少なくとも2週間は無駄になると覚悟したらいい。つまり、スケジュールを2週間延長しても、読者にとって何にもならないということだ。もしそれが読者への最良の提案でも、それを呑むな。スケジュールと資源の余裕（スラック）は、問題を増幅させるためではなく問題を解消するために、許容しなければならない。読者がもっと早くに延長すれば、こうした影響は軽減される。事実人びとは、おそらく予定日の2か月前ならばわずかな延期は気にもとめない。
後から出てくる要件を追加するために、わずかな追加時間をやすやすと受け入れる罠にはまるな。システム規模のダイナミックスは非線形だから、後から出てくる要件の影響の見積りにあたっては、かなり気前よく構える必要がある。
これらすべてを勘案すると、当初計画が200人日のプロジェクトは、所要規模が10パーセント増加すると、うまくいっても250人日以上にはやすやすと延長しかねない。既に100日経過した後で新規案件が出てきた場合は、その撹乱効果のために延長分はもっと大きくなる。
「人助けモデル」を銘記せよ：ほとんどの場合、見かけによらずすべての人びとは協力的たろうと心がけている。一般的に、顧客はただソフトウェア品質ダイナミックスを理解していないだけであり、それは読者の専門で彼らの専門ではない。
第21章 情報資産を保護する
通常、標準の影響は多くの小さな節約からなるため、標準の資産価値はややもすると見落とされる。読者に標準があれば、すくなくとも管理すべきコードがはるかに少なくなるので、構成管理ははるかにやさしくなる。
多くの開発者は、コードを書いているときはかなり慎重でも、単体テスト作業のときには修正作業に熱中して、原バージョンが保有していた設計完全性をすべて破壊してしまう。この過程で彼らはまた、モジュール履歴についての価値ある情報も破壊する。
「予知」（パターン4）組織を創造するには、読者は過去を知らなければならないが、それは他に未来予測法がないからだ。マシン上で開発したものはなんであれ、アーカイブに格納できるし格納すべきであり、アーカイブはたえず更新しアクセス可能にしておくべきである。
第22章 設計を管理する
プロセスエラーもまた管理の悪い組織では深刻であるが、ほとんどの欠陥は要件と設計で発生する。重複作業、完全消去、更新不履行、そしてソースコードの版管理のようなプロセスエラーは、開発プロセスが原因となっている。これらの多くはプロセス改善で対処でき、それはまさに管理の責任である。
良い設計が本質的であるのは当然として、管理者たる読者はそれについて何をすべきか？一つはっきりしているのは：読者自身が設計者たらんとはしないことである。もし読者がそうしたいなら、管理者をやめて第一線に戻ることだ。しかしちょっと努力すれば、組織が最悪の設計ミスを予防するのに少なくとも手を貸すことはできる。
人びとに修正モードの思考を強要するな。圧力をかけるな。そうすればシステム寿命は長くなる。これが単体テスト作業をコーダーにさせない一つの理由である。
性能の最後の10パーセントが、コストの3分の1と問題の3分の2をもたらす。
読者があるホテルにいるとしよう。誰かが火事だと叫ぶのを聞く。消火器のところへ走り、警報気を引いて消防署を呼ぶ。全員外に出る。消火活動はホテルを改善しない。それは品質の改善ではない。それは消化なのだ。
設計にスラックを許容せよ。設計を限界までプッシュするな。スラックを性急に譲歩するな。スラックは鬼札のようなものだ：ほとんどどんな手でもそれを使えばよくなるが、一度使えばそれきりである。
要求を小さく、スラックを大きく保つことによって、要求と可能性のギャップをなるべく大きくせよ。多くのソフトウェア企業の没落は、これまでつねに、自社製品にすべての種類の機能を搭載した結果、2年の遅れをきたしてマーケットシェアを失ったことが原因だった。
設計が障害を起こしてしまう環境を三つ考えつかなければ、その設計についてまだ検討が足りないのだ。
設計が解決しなければならない矛盾（パラドックス）がまるっきりないなら、あなたは問題を理解していないのだ。
第23章 技術を導入する
必要なのはツールを増やすことではなく、またツールを特効薬と信じる管理者を増やすことでもなく、入手するツールからもっと多くの利益を引きだす管理方針なのだ。
ＩＶ エピローグ
誰もが自分の運命を自分なりのやり方でまっとうしようとしており、親切で寛大で忍耐強くある以外に、誰しもそれを手伝うことはできない。---ヘンリー・ミラー
アート・オブ・プロジェクトマネジメント
スコット・バークマン
村上雅章 訳
オライリー・ジャパン(2006)
★★★★
「そこには莫大な量の試行錯誤が存在している。・・・・・・観察と理論を行きつ戻りつすることになるのだ。理論を持たずして何を探すべきかを知ることはできず、事実を観察せずして理論を確認することはできないのだ。・・・・・・たった一つのことを探求する過程で数千回、あるいは数百万回にも及ぶ試行錯誤が存在していると私は確信している。」----ジョシュア・レダバーグ（ノーベル賞受賞者、1958年）
ラピッド デベロップメント
Steve McConnell
出版社/レーベル アスキー
出版日 1998-05
★★★★★
「コードコンプリート」や「ソフトウエアプロジェクト
サバイバルガイド」のMcConnellの2冊目の著作。「サバイバルガイド」と共に管理者、リーダーの必読書。サブタイトルは「無茶なソフトウェアスケジュールを軌道に乗せる」。本書は３編から成る。「効率的開発の基本」「考慮すべき事項」「最良の手法（ベスト・プラックティス）」。実例と共に、いくつかの架空のケーススタディがちりばめられているが、私は「２−２」のケーススタディを読んで素直に感動してしまった。そうだ、ソフトウェア開発はこうでなくては・・・。テクニカルリーダーであるサラのプロジェクトのスタートにあたってのメンバーへの言葉である。
「このチームにあなた達を選出したのは、それぞれが開発の基本をよくわかっているからです。あなた達は,要求の収集と設計においてどうすればよい仕事ができるかわかっているはずです。ですから,下流工程で必要のない修正作業に時間を浪費することはないはずです。このプロジェクトに関連する全ての人に一生懸命ではなく、賢く仕事をしてもらいたいのです。働きすぎる人は非常に多くのミスをします。私達には、ミスをしている時間はありません」
「また、リスク管理の計画も一緒に立てます。スケジュールが非常にきついため、避けることができるリスクはきちんと回避しなければなりません。このリストの最も高いリスクは,スケジュールが達成できないかもしれないことです。週末にスケジュールを再評価して、達成できない可能性があれば,問題が何かをはっきりさせます」
熊とワルツを
リスクを愉しむプロジェクト管理
日経BP社(2003)
ソフトウェア・プロジェクト
トム・デマルコ/ティモシー・リスター
★★★★
第1部 なぜリスク管理をするのか
まったくリスクのないプロジェクトに手を出すのは負け組みだ。かならずといっていいほど、何も得るものはない。そうでなければ、とっくの昔に誰かが片づけているはずだ。時間と労力を節約して、もっと価値のあることに使ったほうがいい。
リスク管理の反対を「危機管理」といい、問題が発生した後に何をするべきかを考えることを意味する。
リスク管理を構成する主な活動
・リスク発見・・・ブレーンストーミングによるリスク選別と、新しいリスクを発見するための継続的なプロセスの導入
・エクスポージャー分析・・・それぞれのリスクが実現する確立と、その影響を数量化する。例えばリスクの発生確率が20パーセントで、発生した場合に100万ドルのコストがかかるとしたら、リスク・エクスポージャーは20万ドルである。
・危機対応計画・・・リスクが実現した場合に何をするべきかを計画する。これのみをリスク管理と誤解されることが多い。
・軽減・・・リスクの発生を検出する指標を考え、発生までにとる処置を計画する。例えば火災のリスクに対し、消火器、火災報知機の設置避難訓練など。
継続的な移行監視・・・管理するリスクを追跡し、実現しないかどうかを監視する。
デンバー国際空港 この失敗は、言われているようなソフトウェアの開発プロセスの問題ではなく、リスク管理がなされなかったことが問題である。
第3章 リスク管理の方法
「測定していないものはコントロールできない」のデマルコの言葉通り、数量化し、リスク図で考える方法が示される。
リスク図とは縦軸に確率、横軸にスケジュール、あるいはコストをあらわしたグラフである。
例えばプロジェクトの完了を、「プロジェクトは年内に完了します。」という代わりに「年明けまでに完了する確率は０です。完了する確率が最も高いのは来年4月の始めです。少なくとも5月以降でしたら５分以上です。」などと説明する。
いくつかの原因リスクおよび、開発規模のパラメータと技術要因が合成されて、結果としての全体リスクの図ができる。
例として、ソフトウェア・プロジェクトのスケジュールのリスク図を作成するExcelのマクロで作られたRISKOLOGYの使い方が示される。（無償で使える）
RISKOLOGYでの原因リスク（コア・リスク）としているのは、
(1)スケジュールの欠陥
(2)要求の増大
(3)人員の離脱
(4)仕様の崩壊
(5)生産性の低迷
の５つである。
リスク発生の検出における、進捗メトリック、特にEVR（稼得価値）の重要性。
さらにリスク軽滅のためのインクリメンタル手法の説明。
究極のリスク軽滅戦略は「早くスタートすること」。
第4章 数量化の方法
プロジェクトのスケジュールとコストをリスク図を使って考えるのと同時に、発注者は、プロジェクトの利益をリスク図を使って同じ精度であらわさなければいけない。
本書は会社の中でのソフトウェア・プロジェクトのリスク管理の方法を述べていますが、SOHO事業者の立場から、リスク管理を考えるきっかけになりました。
SOHOとしては、いいニュースは、リスク管理に反対する人は誰もいないこと、悪いニュースは、人員の離脱（健康の問題でしょうか）等に対応するすべをもたないことです。
この辺の弱点を、パートナーとのコラボレーションで補うというのが、今後のあり方かなと考えさせられました。
内容はソフトウェア･プロジェクトに特化されていますが、業種、業態を問わず、全ての方にお勧めです。
ワインバーグのシステム行動法
感情の渦巻く難しい人間関係の中で、いかに適切な行動をとるか？
共立出版(1996)
ソフトウェア・プロジェクト
G.M.ワインバーグ
★★★★☆
ワインバーグの4巻本の3冊目。Congruent Actionとは、”適合的行動”と訳されているが、要は状況にふさわしい適切な行動である。どのようにしたら適合的に行動できるかがテーマである。CMMとのアプローチとの違いを鮮明にしている。すなわち「人」に焦点を当てるのである。
ソフトウエア開発において、適合的でない例は次のようなものである。
・時間とおりプロジェクトを完成させる見込みがほとんどないとわかっていながら、それを認めて上司に報告し、代わりの計画や手法を議論できない。
・遅れているプロジェクトに新たに開発者を投入しても、さらに遅らせるだけだと知りながら、何もしないように見えるのが我慢できない。
・どなりつけると事態はさらに悪化すると知りながら、やめられない。
・解決すべき問題を明確に理解しなければプロジェクトは進展しないと知っていながら、開発者のコードを書きはじめたいという熱意に抵抗できない。
・「定義された工学プロセスは、健全な管理慣行の欠如から生じる不安定性を克服できない。ごく希にとびきり有能で、力強い管理者だけが、そのような圧力に抵抗できる。」（ハンフリーとカーティス）
これより以下が導かれる。
1.無能で力のない管理者しかいなくても、不安定性を克服するために定義された工学行動を組織的に導入する。(CMMのアプローチ）
2.非常に有能で力のある管理者を組織内で発掘し養成する。（ワインバーグのアプローチ）
・SEIや他の学会が1の方針を追求しているのは誠に重要である。それは、この方針がコンピュータに携わっている私たちがいつもよく追求し、よく知っているものだからである。すなわち、方程式から人を消去して、品質達成の方法を理解しようとするからだ。
・「お粗末な管理は他のどんな要因よりもソフトウエアのコストを急速に増大させる」（ベーム）
・リップ・バン・ウインクルの手法：2年後に目が覚めて「どうしてこのプロジェクトは2年も遅れているんだ？」ということを知りたがる。
・フィーディーニの手法：こみいった公式と変換で煙に巻き、じっさいになにをやっているのかわからなくする。
・適合性へ移行するために内なるメッセージを再構成する例
非適合的：誰かが私を批判するだろう
適合的 ：批判は避けられないものだ。贈り物として受け取ろう。
非適合的：私はよくないと思われるかもしれない。
適合的 ：誰かが私をよくないと思ったとしても、私は生き残る。
非適合的：私は完全でないと思われるかもしれない。
適合的 ：私は完全ではないので、完全であるとみなされる必要がない。
・多くの専門家は彼らのやることにほとんど成功しているので、めったに失敗を経験しない。彼らはめったに失敗したことがないから、失敗からどう学ぶかを学習したことがない。したがって、単一ループの学習戦略がうまくいかなくなると、いつも防衛的になり、批判を遮断し、自分以外のあらゆる人に「非難」を浴びせる。要するに彼らの学習能力は、もっともそれを必要とする瞬間にまさしく停止してしまう。（ハーバード・ビジネス・レビュー）
・私たちはソフトウエアの仕事はみな論理的だと考えがちであるが、多くの行動が感情に基づいて選択されている。
・性格の差異を資産と認識する--ソフトウエアの仕事は、多様な仕事から構成されているので、ある一つの性格やタイプや一連の技術や、一つの見解だけでは仕事のすべての部分に適応できそうもない。これこそ、私たちがソフトウエアに携わる人々の間の差異を必要とする理由である。
・品質とスケジュール目標のトレードオフが出来ないと感じると、管理者は人々の交流の質を犠牲にしたいという気になりがちだが、そうすればすぐに品質とスケジュールの両方に代償を支払わなければならない羽目になる。
・非難の中毒をやめさせる--一般的には、批評は、非難や罰としてではなく情報として与えられた方がもっと受け入れやすい。非難を行っても、人々に非難を回避する方法を見つけようと動機づけるだけである。
・ＭＯＩモデルはチームや個人がうまく機能していないときには、失われた要素が何かあるかもしれないことを示す。動機（Ｍ）かもしれないし、組織（Ｏ）かのしれないし、情報（Ｉ）かもしれない。読者の仕事はどれであるかを見つけ、それに応じて介入することである。
・私自身にしたところで、気分がよくないとき、人をいじめ、無視し、非難し、自分を非難し、困難な状況から逃げ出し、抽象の中に雲隠れしたことがある。こうしたことを通し、自分が適合的でないとき、ソフトウエア工学の問題を解決しようとしたり、ソフトウエア工学の組織を作ろうとしたりすることは無意味だということを学習したのだった。それでわたしは、まず最初に適合的になると言う要の行動をとる、読者にもそうしてもらいたいと希望しているのである。
デマルコ 大いに語る
ソフトウェア２４の閃きと冴え
日科技連(1998)
ソフトウェア・プロジェクト
Tom DeMarco
★★★★★
「ピープルウエア」のデマルコのエッセイ集。PowerPCプロジェクトの担当プログラム・マネージャーであったシーラ・ブラディとの対談は必読である。デマルコの著作の中では本書を第一に勧める。
・ソフトウェア開発の作業の大部分は圧縮できない。圧縮されたスケジュールに対しては、まず無駄な作業を省こうとする。次に残業するようになる。最後には品質を犠牲にしてスケジュールを守ろうとする。このようなアプローチは数回の戦闘には勝てるかもしれないが戦争には勝てない。かつての米国の自動車産業のように。
・計測性機能不全の例（日立ソフトウェア・エンジニアリング）単体テストでの発見バグ数が多いほどシステムテストで多くのバグを発見しなければならないと言うプレッシャーから、開発者は単体テストのバグを隠すようになった。
・作業者にプロであることと、実績評価の単純な計測値表示も追及せよと両方を追求するのは無理である。
・自分たちの成功や失敗を分析しない本当の理由は「怖いから」。
・ソフトウェアプロジェクトの納期遅れは、生産性が低いことが問題とされるが、もっと妥当なスケジュールを設定することに焦点を当てなければいけない。
・大切なのは貴重な資源つまり時間の燃焼率を測ることである。プロジェクトの初期に稼いだ1週間は、大詰めの1週間と同じだけ大切である。
・人は失敗からの逃避として否認の態度を続ける場合がある。計測が高くついても割に合うのは、否認が始まる前に対応できるからだ。納期まであと3ヶ月になっても不具合発生率がこうだったらどうなるかと言う質問が出来る。
・残業は短距離走ではよいかもしれないがマラソンには向かない。
・たいていのソフトウエア技術者は、予定を達成するために残業するんじゃなくて、達成できないことをやましく感じないように残業している。
・一番下っ端の開発作業者が、日程遅れも品質不良もみな自分たち自身の落ち度になると知ったら、こう考えるしかない：どんな間違いだったらボスの落ち度になるのかな、と。
・出荷日が近づくにつれて仕事量の減る人が出てくる。納期前に全員まだ多くのやるべき作業があったとしたら、それは工程計画が全部間違っていたということである。
・過剰機能の例。部下の仕事までも何でも完璧にこなそうとする模範指導型管理職。本来マネージャーは触媒である。マネージャーの仕事のうち、やさしいほうは制御と調整に関係する。難しいほうは、動機づけ、調和、チームワーク、個人の成長、そして仕事に対する満足度のような人間的な配慮に関係する。模範指導型マネージャーにはとても手が回らないのが、この人間的側面なのである。
・「何か一つだけ手を打つとしたら」・・・4対1の確率で次が役に立つ。「部下に一度に一つの仕事だけをさせること」
人月の神話
狼男を撃つ銀の弾丸はない
アジソン・ウェズレイ・パブリッシャーズ・ジャパン 発売 星雲社(1996)
ソフトウェア・プロジェクト
フレデリック・Ｐ・ブルックス Jr.
★★★★
有名な本の20周年記念増訂版。「ソフトウエア開発の神話」に、「狼男を撃つ銀の弾丸はない」を加え、さらに現在の時点で、これらが正しかったかどうか検証している。
前者は人と月は交換可能ではないという主張を中心にした考察。（つまり、3人で4ヶ月かかる開発は、6人にかければ2ヶ月でできるわけではない。）後者は、ソフトウエア生産性を飛躍的に向上させる特効薬はない、という主張。
・遅れているプロジェクトに人を追加した場合に発生する本来の作業以外の工数は、経験ある人から受ける教育・訓練、仕事の再分割により既に完了している仕事で無駄になるものも出てくる上、システムテストをより長くしなければならない。ブルックスの例では人を追加しなかった場合と同じ遅れとなる。
・ブルックスの法則-遅れているソフトウエアプロジェクトへの要員追加は更に遅らせるだけだ
・マイルストーンを鋭利な刃のようにあいまいさをなくすこと。こうすることで人は、マイルストーンの進捗をごまかそうとはめったにしない。しかしマイルストーンがファジーなら、上司は異なる意味に解釈してしまう。ごまかそうというつもりはなくても表現を和らげてしまいがちだ。
・「どうせ他のところも遅れているのだから」-１日の遅れにもやっきにならなければならない。この程度の遅延こそが、まさに破局の要素なのだ。
・成功のためには、プロジェクトに携わる人々の質、及びその組織形態と管理こそが、使用するツールや採用する技術的アプローチよりもはるかに重要な要因であると考えている。
ソフトウェア プロジェクト サバイバル ガイド
日経ＢＰソフトプレス(1998)
ソフトウェア・プロジェクト
Steve McConnell
★★★★★
マイクロソフトプレスの1冊。私が読んだプロジェクト管理の教科書の中で最良の１冊。全てのリーダー、管理者に強く薦める。
数十年にわたるソフトウエア業界の知識を凝縮した、銀の弾丸に頼らないオーソドックスな手法である。
計画・準備に時間をかけ、工程をきちんと定義し、各工程内で間違いが流出しないよう管理された段階別分納（「中間目標アプローチ」）による開発である。
以下、参考になった部分を挙げる。
・十分に検討され設定された開発工程は、不可欠である。開発工程を明確にすることで、時間を生産的な活動に使うことができる。工程が不完全だと誤りの訂正に時間を割くことになる。
・プロジェクトを成功の鍵となる作業は、プロジェクトの上流で行われる。
・工程の定義は創造力や勤労意欲を妨げることはない。
・上流の問題は上流で修正できるよう、要件［要求仕様］とアーキテクチャを徹底的に注意深く見直す。
・プロジェクトの初期段階では、予算とスケジュール、及び作りこむ機能の両方を厳密に設定することは不可能である。
・平均的なプロジェクトでは、時間の80%を計画になかったやり直し作業に費やしている。その時間の数パーセントを計画立案に当てればよい。
・危機管理-最良の結果を期待しながら最悪の結果に備える。
・ソフトウエア プロジェクトのリスクには先手を打って対処する。
・「管理されたプロジェクト」の逆は「管理されない（自由な）プロジェクト」ではなく、「管理できない（手のつけられない）プロジェクト」である。
・段階別分納では、重要な機能を早い段階でリリースでき、リスクを早い段階で排除でき、問題を早い段階で明確にできる。
・８分の２法則：工程の作業の８割が完了してから次工程の作業を開始する。
・変更管理の要点-変更管理委員会の設置、変更は前もって決めた点に制限すること、作業の成果を変更管理の下に置くこと。
・全ての情報は良いものも悪いものも,あらゆる立場の人に制限されずに伝わらなければならない。
・危機管理では危機管理計画を作成し、担当者を選任し、トップ１０リスク一覧を使用し、個々のリスクに対する危機管理計画を作成し、匿名によるリスク報告経路を設定する。
・品質が悪いという評判は,開発が早かったという評判よりももずっと後まで残る。
・テストはソフトウエアの品質を調べる手段であり,ソフトウエアの品質を保証するものではない。
・アーキテクチャの目標は複雑性を減らすことにあり、組み込む機能だけでなく、組み込まない機能についても十分な吟味が必要。
・プロジェクトのコストに対する影響が上流で大きいことを考えると、悪い知らせは,早い時期に知らされるほうがよい。
・見積もりは、プロジェクト完了までに何度か再見積りを行うことを計画し、変更管理の下に置く。
・小規模マイルストーンを採用し、完全なマイルストーン一覧を作る。
・プロジェクトが成功するかどうかは,チームがどれだけ間違いを速く発見して簡単に修正できるような体制を作れるかどうかで決まる。
・技術審査［レビュー］にはそのコストの何倍もの効用がある。
・ソフトウェアがほとんど完成するまでテストの計画を立てる人がいないため、テストは,しばしばプロジェクトの完成を遅らせるネックになる。テスト計画は、一朝一夕には作れない。結果的にテストはどうしても簡略化される。
・ソフトウエアの欠陥については、便りのないのは悪い知らせである。欠陥が見つからないのは、開発作業が優れているのではなくテストが不充分であることの証拠である。
・進捗状況と品質に関する情報は公開する。
・スケジュールの遅れを取り戻せるプロジェクトはほとんどなく、その後さらに遅れが拡大する場合が多い(1991年の300以上のプロジェクトの調査結果)。
ワインバーグのシステム洞察法
ソフトウェア文化を創る２
共立出版(1996)
ソフトウェア・プロジェクト
Gerald M. Weinberg
★★★★★
ワインバーグの４巻シリーズの２巻目である。ここでは、“１次計測(First-Order Measurement)−ソフトウエア開発で何が起こっているかを観察し観察の意義付けを理解する能力−”がテーマである。
「1次」の意味は、ラフスケッチのようなものである。２次はもっと精密な計測になるが、管理者の日々の問題には焦点を当てていない。「自分が何について話しているのか分からないときに、正確であっても何にもならない。」本書は２次計測を有効に利用できるように支援するものである。
本書はサティアの交流モデルに沿って展開される。これは観察から行動にいたるモデルで、「情報の取り込み」->「意味付け」->「意義付け」->「反応」の流れからなる。「意味」は取り込んだデータにはないものである。また「意義」は「意味」の「意味」であり、私たちの頭脳が扱える大きさに変えるフィルターである。
印象に残った部分を挙げる。
・パターン２（慣習的文化）では、過去の実績統計は変革のために用いられるのではなく、全てがうまくいっていることを証明するために用いられる。
・なぜ観察は重要か-危機の突然さは危機の尺度ではなく、管理者の気づきの尺度である。もし管理者が効果的に観察しつづけていたのであれば−彼らはがっかりさせられたかもしれないが、驚かされはしなかっただろう。
・文化パターンを見分ける方法は、“病気”の処方を観察することである。舵とり（パターン3）組織は病気をうまく扱うほうだが、ときどき同じ症状を繰り返す。組織が健康であること（プロセスレベル）よりもそれぞれの病気を治すこと（製品レベル）に注力するからである。慣習的（パターン2）組織は病気を罪悪のように扱い、人々が症状を隠すのを望むようになり、病気を悪化させる。
・あることが繰り返して起こるとき、それは偶然の出来事であるはずがない。
・慣習的文化(パターン２)では、管理者の非難を免れるための何にも優るこつは気づかないことである。
・あることを監察しているという単なる事実が、開発に使われる努力の大部分を、計測システムを打ち倒すのに注がれる恐れがある。例えば、LM中のビット”1”の割合を増やせという理不尽な指示を出すと、増えた実績があがってくるであろう――。
・製品を可視化する-可視でなければ、制御は不可能であり、制御できなければ、品質を保証することはできない。
・地図と土地とが一致しないとき、つねに土地を信じよ。地図とは測定値に対する複数の像である。ソフトウェアに対する像は地図であり、これは土地そのものではない。
・図表は重要ではない、図表を作ることがすべてだ。
・顧客満足度を計測できるが、 5.0の満足度はよいのか、悪いのか、知ることができるのは、トレンド図の助けを借りて、率が時間的にどのように変わるかである。変化は、管理者がもっと調査すべきだと言う信号である。
・受け取ったものについて少なくとも三つの異なった解釈を思いつかないならば、その意味を十分に考察していないのだ。
・慣習的（パターン２）組織のプログラマのほとんどは、何事も規則どおりだ−という錯覚がもはや維持できなくなるまで−管理者を満足させるために始終罪のないうそを創作する。
・品質さえ気にしなければ、品質以外のどんな要求でも満たすことができる。
・“努力は計算できるものに注がれる。”（デマルコ）。コスト計算はコスト削減を導く。価値計算は価値の増大を導く。コストと価値は異なる。
・Xドルの損失はいつでも財務上の責任がXドルを超える取締役の責任である。
・パターン１と２の組織では誤りが起こったときに、非難と処罰に時間を使い、早期に故障を把握し、予防する手順の確立という管理者の責任から注意を逸らす。
・悪い兵士などいない、いるのは悪い将校だ
・もっとも危険な反応は、危機が実際にどれくらい深刻なものであるかを気づかせるような情報源から自身を切り離すという傾向である。
・官僚主義の尺度は、なぜそれをするのか関係者が理解できないパーセンテージである。
・レビューは、スケジュール効率を改善し、冗長作業を除去し、テストを補い、そして訓練をもたらす。
ワインバーグのシステム思考法
ソフトウエア文化を創る１
共立出版(1994)
ソフトウェア・プロジェクト
Ｇ．Ｍ．ワインバーグ
★★★★★
"Quality Software Management"の4部作の第1巻。「複雑な状況を理解する能力」に焦点を当てる。
最初に「品質パターン」として、ハンフリーのプロセス成熟度をベースにした６つのソフトウェアサブカルチャーの
パターンが定義される。だがアプローチはCMMと全く違う。ワインバーグはパターン１とパターン２からパターン３
へ移行するために思考パターンを変えなければならず、そのために本書を書いたと言っている。CMMの
アプローチに関しては、「方程式から人の項を消去するようなもの」と批判している。要するにキーは人であり、
優秀な管理者になるためにはどうすればよいかということである。私はワインバーグのアプローチに全面的に賛成する。
ワインバーグの著作では他に「コンサルタントの秘密」「プログラミングの心理学」を強く勧める。（後者は残念ながら絶版のようだが・・・）
以下、印象に残った部分を挙げる。
・他の全ての原因よりもカレンダー時間の切迫が､ソフトウエアプロジェクトにその失敗の現実を直視させる。
・縮尺の錯覚-大きなシステムは､小さなシステムと似たようなもので､単により大きいだけだ。
・行動は早めに、かつ少しずつ-パターン２のマネージャーは楽天的であり、物事がまずくなった時、自ずと良くなっていくだろうと想像する。問題を認め、かつ非線型システムが、それ自身では直らないことを悟った時、彼らはとてつもなく大きな訂正を試み、さらに悪い非線型サイクルをはじめる。
・大切なのは出来事ではない、出来事に対する反応だ（火災に見舞われた２つのプロジェクトを比較する。片方は成功し、他方は失敗した例を分析する）
・欠陥フィードバック率(ＦＦＲ＝生成された欠陥／解決された欠陥）の適用例。ある企業では規模の小さい訂正の方が大きいFFRを持っていたことが分かり、規模によらずレビューするようになった。
・ブーメラン効果-品質を手っ取り早く片づけようとすればするほど、問題はますます悪くなる。
