のみほーだい!

アジャイル・プロセス（Ａｇｉｌｅ　Ｐｒｏｃｅｓｓ）の導入について

第２回　ＸＰの光と影

■はじめに

前回はXPの概略を紹介しましたが、何事でも表面だけを捉えて使うと大怪我をすることがあるので、今回は批判的な視点も含めて再度検討します。特にXPに限らず全てに効く万能薬というものは存在しないので、これだけ覚えればプロジェクトが成功するなどとは決して思わないでください。場合によっては副作用で余計悪化することもあり、本当に導入が効果的かプロジェクトマネージャ・リーダーが判断して、流行に流されないように注意しなくてはなりません。
　また、今回は最後に載せた参考図書のダイジェスト版ともいうもので、詳細については必ず各文献に当たって自分なりの判断を下すようにしてください。

■ソフトウェア開発の経済学

XPを導入するにあたり特にマネージャー・リーダークラスの人間が最初に意識しておかなければいけないことは、

●我々は会社に所属している人間としてプロジェクトで利益を追求しなければならない 　（我々は学者でも生徒でも「パソコンおたく」の道楽でやっているわけでもない） ●同時に技術者としてのプライドを持ち、利益のために故意に品質を犠牲にしてはならない 　（メンバの自尊心を傷つけ、やる気をなくさせるだけでなくユーザの信用もなくす）

ということです。

このことを理解していれば全ての判断基準は、「品質を落とさずに利益を出す」ということが分かります。
　迷った場合は、ここに立ち戻って考えましょう。

（注意）これは各メンバが勉強する必要がないということではありません。技術者が勉強し続けなければならないのは言うまでもないことで、強調したいのは「仕事」に費やした時間と「勉強」に費やした時間をきちんと区別しろ、ということです。管理者はそこを正確に把握しないとプロジェクトに関係のない内容や単にメンバの興味本位で行なっていることにまで費用計上することになってしまいます。

ではプロジェクトとして利益を増やすには何が考えられるでしょうか。

　　１．費用を減らす。

おそらく誰もが最初に考えることでしょう。しかし本当に必要な経費まで削減すると品質に影響し、トラブル発生によって結果的に余計な出費をすることになる場合も多くあります。あくまで無駄をなくすということに専念すべし。

　　２．収益を増やす。

マネージャは営業としての役割を担うことも多いのですが、今回は説明を省きます。

　　３．遅く支払い、早くもらう。

使った経費に対する利子をできるだけ減らし、稼いだ売上に対する利子を増やします。
商人なら不良在庫を抱えない努力は基本中の基本ですが、ソフト開発の管理者は意外と忘れがちです。

　　　　

　・初期投入人員を必要最低限に抑えます。

開発初期は要件も定まらず基本的なクラスなど開発環境も整っていないので、最初から一度に人員を投入してもその分の費用が結果的に無駄になることが多いのです。初期リリースで提供する機能を吟味して必要最低限に抑えることにより、少人数で対応できるように努力します。

　　　　

　・リリース単位を細かくし、それに応じて検収回数を増やしてもらいます。

　　４．プロジェクトが存続する可能性を増やす。

プロジェクト後期に多額の支払を受けやすくします。

また、プロジェクトの経済学を一連のオプション（選択肢）として考えると

　　１．廃止するオプション

プロジェクトをキャンセルしてもそこから何かを得ることができるなら、検討に値します。

　　２．切り替えるオプション

プロジェクトの方向を変えます。

　　３．遅延するオプション

プロジェクトの失敗により結果的に納期に間に合わず遅延するという意味ではありません。
状況が整理されるまで取り掛からずに待ちます。それだけ資金を使うのが遅れ、その分の利子を計算すると今実装してしまうよりも有利になる場合があります。
特に不確実性が高いとき価値のないことをしてトラブルを抱えるよりも、待って何も悪化させない方がユーザにとっても有利になります。

　　４．成長するオプション

マーケット的に好機であれば、素早くプロジェクトの規模を拡張します。

各オプションの価値を計算するには、投資量・付加価値の購入価格・現在の価値・費やせる時間・将来的価値の不確実さを目安にします。特に不確実性が高い場合は、

• 正確で頻繁な進捗のフィードバック
• 要求変更の機会を増やす
• 初期投資をできるだけ少なくする
• 早く行なう機会を与える

■プロジェクト管理の４つの変数

• コスト
• 時間
• 品質
• スコープ（システム化の範囲・実装する機能）

一般に初めの３つは外部要因によって制限されてしまって、開発チーム（マネージャーを含め）では決定できず、開発側は４番目のスコープを制御することになります。通常ユーザはスコープまで制御して自分の言った機能を全て実装させようとしますが、ほとんどの場合、品質が後回しになって期待はずれの結果になるので、マネージャはこの調整に全力を尽くさなければならないのです。

前回の２０－８０の法則にもあるようにユーザは決して欲しいもの・必要なものを正確には教えてくれません（というより教えられない）。ソフトウェアの一部が完成するとユーザの要望はどんどん変わっていきます。つまり実際に動いているものを見るまで本当に欲しいもの、次に欲しいものはユーザにも分からないのです

このように経験からしか学べないものをユーザに期待しても無理だし、どんなに優秀なSEでも要求を引き出すことはできません。ここで注意するのは従来のプロトタイプ法のように断片的に切り出したものでは本当の経験にはならず、正確な要望は引き出せないことです。機能は少なくてもシステムとして完結していて、実際に業務で使用できて初めて本当に必要なものが見えてくるのです。

以上のことを誠意をもってユーザに説明して納得してもらうことです。それができなければ多分XPは失敗します。

■XPに対する反論の紹介

ここは研究の場ではないので、従来の方法論に囚われている人とのパラダイム論争的なことは省き、僕らが実務的に注意しなければいけない点をピックアップして述べます。参考までに筆者個人の考察も加えました。

・最終的に納品されるスコープが不確実である

XPは反復開発を行なう中で工数見積もりの精度を上げていき、予測可能で無理のないペースでの開発を前提としている。個々のイテレーションに於けるスコープは当然ユーザの要望が取り入れられるとしても、契約時点に於いてユーザは最終的にどこまでやってもらえるのか不明な状態である。

（筆者の考察）
　これに対し、従来の方法はスコープの精度は高いが調達日（契約上ではなく実際の納期）が不確実と言えます。

ただし、これは契約上、追加料金が請求できるかどうかの違いのみで、契約段階での納入予定日にリリースできる範囲が不明確なのは同じである。逆に従来の方法はこの点をごまかして契約していた為に、納期直前になって慌てて限定リリースならびに納期延長をユーザに頼み込まなければならなかったのではないでしょうか。

「半年先のことは分かりません」等と正直に言ってはユーザの不信感を招く危険性もあり、自分たちが技術不足であると認めるようで抵抗があるのは理解できます。しかし、今、アジャイルが注目される背景には、それがあくまで理想論であり、現実に不確定要素があるのならそれに応じた対応の必要性を皆が認識しだしたことにあるのです。

ここは営業との関連もあり難しい問題ですが、前章の内容及びリスク管理の面から説得するしかないと思われます。

・価値の高いソフトウェアは本当に今後も保守・拡張され続けるのか

XPでは、価値の高いソフトウェアはずっと保守・拡張され続け、その間はずっと同じチーム（メンバの異動や増員は途中で発生する）が作業することを前提としている。しかし従来のプロジェクトのメンバは、できるだけ生産性を向上させて早く納品を済ませ次の挑戦をしたいと思い、いつまでも保守を続けたいなんて思っていない。

（筆者の考察）
営業や経営サイドからすると一般に保守の方がリスクが少なく利益も上がるのでXPの方が良いかもしれませんが開発の現場のモチベーションを保てるか、管理者の手腕によるところが大きいと思います。

ただし、一過性のプロジェクトだから後のことを考えなくて良いとは言えません。そんなことをすれば次の仕事なんて来ないのではないでしょうか。

・メンバの技量に重きを置きすぎている

従来の管理手法では一部の者に重要な決定・標準の策定を行なわせそれを一般の要員に実行させることで失敗の芽を摘み取ってきた。XPは、世界のソフトウェア開発者人口の４９．９９９９％は平均以下の能力しか持っていないということを忘れている。

（筆者の考察）
　この反論はリスク回避という面では論点がずれているようです。XPでは各自の能力に合わせてスケジューリングをするので失敗の危険性は低いです。それより問題は、最初の反論にあるように要員の能力が低すぎるとスコープが狭くなりすぎて最終的にユーザの要望が満たせないことでしょう。

ただ、要員の能力が低かった場合、従来の方法であっても成功するとは思えません。結局メンバ間のコミュニケーションによって相互に能力を高めていくしかないのではないでしょうか。

逆に従来の方法での標準化は、「羹に懲りて膾を吹く」の例え通り、やたら防護壁が厚くなり機敏に動けません。その反省がアジャイルという概念を生み出したのです。

・XPは開発者の｢恐れ｣に囚われすぎている

XPの始祖Kent　Beckは、先ずプロジェクトが直面するリスクを整理することから始めたが、実際はそれらのリスクから開発者には様々な恐れがうまれている。XPはこれらの恐れに対する処方箋であったために開発者の熱狂的な指示を得たが、リスクはあくまで見掛けの「症状」であって「病気」の本質そのものではない。「病気」そのものに焦点を当てなければ根治できない。「病気」は「無知」と「焦り」の２つの魔物から生み出されているのである。

「無知」に対する処方箋は、問題を「断片的な知識だけで成功する方法」と捉え直してチームが議論の席に着くことです（要件を完全に把握していないのに気づかず見切り発車していないか皆で反省するのです）。　「無知の知」

「焦り」は、我々の業界の風土病と言えます。今まで時間的に余裕のあるプロジェクトなど経験したことがない者が殆どではないでしょうか。ここではリヒターの法則「人は急かされても速く走れない」を思い出しましょう。納期遅れなどでチームに時間的な圧力が加わった時、メンバは本質的な解決方法よりも自分を忙しそうに見せることに注力してしまう傾向があります（無意味な徹夜など）。これは管理者がユーザに言い訳するためにそうすることも多いです。

XPは結果的にはこれら２つの魔物に対する良い処方箋となっています。

「無知」に対してはチームを同じ場所に配置し、またユーザをチームに取り込むことで断片的な知識による仮定（推測）のもとの作業をなくすことを奨励し、チーム全体のやり取りを活性化することによって重要な問題、特にユーザに確認しなければならない問題を見過ごすことを防止しています。

「焦り」に対しては既に周知の通り無理のないペースで継続的に行なっていくことで解消しています。

（筆者の考察）
　これはXPに対する反論というよりも、実際には見過ごされている問題の本質に対する警鐘であり、我々が肝に銘ずるべきものです。これを忘れて表面的な技術論で中途半端にXPを導入すると問題が発生します。

・テストファーストは品質を完全に保証できるか

この問題に関しては別途「テストファースト」の回で考察します。

・XPは大規模プロジェクトには不向き

XPは元々大規模チームへの適用を想定したものではなかった（Kent　Beckは、２０名程度までは可能と言っているが現実的には１０名前後が妥当と思われる）。開発者が１００名を超えるような大規模システムには適用できないのではないか。

（筆者の考察）
　懸案されているような大規模システムの場合、必ずサブシステム単位等でチームの階層化が行われるはずです。

一人のリーダーが２０人以上を管理しては方法論によらず無理が生じるので、チーム編成の誤りとしか言えません。

また、オブジェクト指向の導入（コンポーネントやクラスライブラリといったフレームワークの充実）によって少人数でも以前よりずっと大規模のシステム構築が可能になった現在、この問題がそれほど致命的とは思えません。

ただし、大規模開発を複数のXPチームに分割した場合のチーム間の連携については未だ実績がないので不明です。

・XPよりも従来の方法の方が安く安定している

メインフレームでの開発のようにユーザの要望が安定していて頻繁に変更が発生しない時は従来のウォーターフォール型の方が安く良質なものが提供できる。

（筆者の考察）
　そんなおいしい仕事がなくなってきているから問題なのですが、この点についてはKent Beck自身が言及しています。

「いつXPを使うべきか。それは要求が曖昧で変化している時である。」

従来の方法の方が良いというのなら「仕様変更が多くて堪らない」等と愚痴をこぼすべきではありません。