IBM Rational Software Conference 2009基調講演レポート

Rationalが考えるスマートなソフトウェア開発とは？

アジャイルの極意はどこにある？

IBMのVicePresident　ウォーカー・ロイス氏。ワールドワイドのサービス担当。コンサルティングを実践し、ソフトウェア開発のスタンダードを作成して広めるミッションを担っている

　3番目に登壇したIBM Vice President　ウォーカー・ロイス氏の講演は、アジャイル開発における要点が主な内容で、Rationalのみならずソフトウェア開発全般に関係するメッセージを発信した。

　ロイス氏は、ソフトウェアの提供形態が「開発からデリバリーへ」変わってきていると切り出した。従来のソフトウェア“開発”は、明確な開発フェイズのもと、要求→設計→コーディング→テストという流れで進められるものであった。また、フェイズや役割で固有のツールを使い、チームも同じ場所に存在し、エンジニアリング・ガバナンスも標準的なものが用いられてきた。そして、開発が終われば保守のフェイズに引き渡されるのが当たり前だ。

　しかし、新しいソフトウェア“デリバリー”では、開発と保守の間には、明確な境界はない。なぜなら、ソフトウェアは顧客に“価値”を提供し続けるものであるからだ。そのためには、共通のプラットフォームで統合されたプロセスやツールが必要となり、より柔軟な対応のために分散したWebベースのコラボレーションによる開発、さらには、リスクや利益に合わせた（エンジニアリングではなく）経済的なガバナンスが必要であり、仕様を満たしたかどうかではなく、ビジネス的な価値＝結果主導の成果が求められる状況となってきた。

　つまり、ソフトウェアには、経済的な規律が求められるという厳しい現実が一点。ソフトはビジネスプロセスになりつつあるというわけだ。また、ソフトの世界には物理的な法則が適用されないので、どのようなものができるか分からない。それは相互につながった知的素材を組み合わせたやりとりの中で生まれるものだからだ。

　ならば、（開発）プラットフォームで何ができるのか？　不確実性にどのように対応していくか？　というところに、焦点が移っていくだろう。

従来のガバナンスとアジャイル・ガバナンスの違い

　特に、ガバナンスという面では「ソフトウェアの経済性を改善する上で重要な文化的変化」と題して聴衆に価値観の変換を促した。すなわち、従来のガバナンスはPMI/PIMBOKによって詳細に計画してから差異を追跡する形態を採るのに対し、これからのガバナンス（同氏は「アジャイル・ガバナンス」と呼んだ）は、結果ベースの管理をするべきだという。つまり計画→推進→計画→推進というサイクルを回していくような形態だ。

　さらに、発注者と開発者との関係も、従来の書類の交換とその解釈といったような“対立的な関係”ではなく、前進し、ズレを修正していくような「誠実で協調的なコミュニケーション」が必要だという。

　従来の開発手法は、開発の前に「ユーザーが何を求めているか分かっている」ことが前提になり、それを実行する考え方だが、ユーザーの理解度がどの程度まであるかはわからない。より経済的に、アジャイルに開発を進めていくには、細かいところを計画するのではなくて、計画を立てて舵取りを氏、問題があったらまた修正をして……という、新たなガバナンスが必要というわけだ。

あなたがPMだったら？

11ヵ月で完了すると、見積もり担当者は答える

　ここでロイス氏は、「あなたがPM（Project Manager）だったら」と、シミュレーションをしながらアジャイル開発を説明しはじめた。

　たとえばミッションクリティカルなシステムを12カ月以内にデリバリーする状況があったとする。見積もり担当者は、「11カ月で完了する」と報告してきた。「どう思いますか？」Royce氏は問いかける。

プログラムのコスト、スケジュール、工数、品質は、確率変数である

　プロジェクト管理がよく分かっているPMであれば、それは憶測に過ぎないと分かるだろう。なぜなら、コストやスケジュールのインプットになったものは、変数であるからだ。見積もり担当が出した「11カ月」という結果は、それらを元にした中央値に過ぎない。ならば、偏差が出てきて当然だ。実際、その日に完了する可能性は、50％にも満たないものとなってしまう。

点線の、最初に計画されたパスをそのままトレースしなくても、実際の顧客の要求に近づく形で開発は進む。それには、要求文書をがちがちに決めるのではなく、交渉の連続によって計画を進化させ、変化させる

　ではどうするか？　完了日を遅らせるか？　品質や内容を犠牲にして間に合わせるか？　いずれもクライアントがいい顔をするわけはない。ならば、偏差を小さくするしかない。不確実性があればあるほど偏差の幅が広がり、不確実性を排除すれば、当然幅が狭まる。アジャイルでは、結果が出るまで待つのではなく、利害関係者が満足する範囲＝スコープを設定し、ユースケースを反復して不確実性を排除していく。

　こうすると、当初の計画からはずれていくかもしれないが、すべての利害関係者が満足の行く方向に向かうことは間違いない。なぜなら、従来の開発手法に比べて早期に修正を加えられるからだ。もちろん、こうした開発には連続的なレポートが必要不可欠で、それによって交渉を繰り返していくという。

　「これは、開発手法と言うよりも一つの文化だ」（ロイス氏）。

　こうした開発をするためには、3つの重要なポイントがある。

1. 完了日は一時点ではなく、確率分布で。納期日は当然あるが、それを管理する側は確率分布で結果を狭めていくこと。
2. スコープはライフサイクルの早い段階で規定するものではない。すべての要素は交渉可能であり、要求ではない。スコープは交渉の連続で、アジャイルの中では中核的な考え方である。
3. 計画は規定ではなく、目標とする。計画を立てたり期待値設定は重要だが、さらに重要なのは、計画が変わることを率直に認めることである。利害関係者と率直に話し合うこと。それには、優れた測定値とメトリック（方向性）がなければならない

MCIFの4つのフェーズ

　これだけ聞いていると、なんとなく都合のよいような印象も受けるが、これは当然、Rationalが10年以上かけて展開してきた「Measured CapabilityImprovement Framework（MCIF）」というフレームワークに則ったもので、80件以上のIBMアジャイル・プロジェクトで使用してきたという裏付けがある。「MCIFは我々の生活そのものだ」と、ロイス氏は語る。

　MCIFは4つのフェーズに分かれている。詳しくは画面を参照していただきたいが、フェーズ1を実行したなら、あとはフェーズ2～4を繰り返していく中で、ソフトウェアをスコープに向かって進化させていくというわけだ。

RationalのJazz

　ロイス氏は、「どんどん進化する、実行できるコードが真実だ」と語り、紙や人を通じて提供されるベストプラクティスは組織内では普及しないと言う。そして、MCIFの2～4フェーズを実現するのがJazz（IBMが開発したチーム開発環境のしくみ）であり、Jazzに準拠したRational製品の重要性を訴えた。

次ページに続く