ワインバーグのシステム変革法（その２）

しかし最終的にはなすべきことを知るだけでは十分ではない。ソフトウェア障害の最大の原因は、管理層の性格と人格の障害であって、こうしたあまりにも人間的な障害が組織的変革を制限している。階層組織における管理者の職権故に、彼らの小さな愚行すら文化変革の最善の努力を水泡に帰してしまう。管理者は適合的に行動する必要があり、そうでないかぎり結果は破局に到る。

構成要素は根本的なだけに、改善をたやすいものと思ってはいけない。多くの組織で、改善を目指すソフトウェアプロセスを吟味する試みは、強い政治的反対に遭遇する。権力構造が専断的であればあるほど、あからさまな検討がもたらす脅威は大きい。

第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章　技術を導入する

必要なのはツールを増やすことではなく、またツールを特効薬と信じる管理者を増やすことでもなく、入手するツールからもっと多くの利益を引きだす管理方針なのだ。

ＩＶ　エピローグ

誰もが自分の運命を自分なりのやり方でまっとうしようとしており、親切で寛大で忍耐強くある以外に、誰しもそれを手伝うことはできない。---ヘンリー・ミラー