アジャイル型開発を推進するために必要なことを考える

きたる2011年4月15日は記念すべき「Agile Japan 2011」が全国で開催されます。
http://www.agilejapan.org/

沖縄でも "沖縄サテライト" ということで、Java Kueche 主催のパネルや LT が開催されます。
http://www.java-kuche.org/modules/eguide/event.php?eid=19

先日、この会を盛り上げる資料が IPA より公開されました。
アジャイル型開発を推進するための活動成果を公開」
http://sec.ipa.go.jp/reports/20110407.html

これは大変、興味深いレポートです。とりまとめていただいた関係者の皆様に謝意を表するとともに、ここで、レポート「非ウォーターフォール型開発WG活動報告書 (PDF形式)」の一部を抜粋しながら、私見を述べたいと思います。

アジャイルの導入には、利用企業の覚悟が求められる。

pp.17 に、アジャイルが主に自社開発(内製)で普及している点を触れています。

自社開発においては、開発者と利用者(提供者)が一体化している、 もしくは開発者と利用者(提供者)に共通的な意志決定者(責任者)がいる、といった特徴がある。これらによって、受委託によるものに比べて、開発スコープのコントロールや、 何か問題が起きたときの対処が容易になると思われる。

では「丸投げ」で開発を SIer に委託し、できたものを使うというお客様にはアジャイルは向かないのでしょうか。この点について pp.18 でずばり、指摘しています。

ウォーターフォール型開発は、ソフトウェア開発手法ではあるが、従来のように、プ ロジェクトチームだけが関与すべきものではない。とりわけ利用企業の経営者は、開発手法の採用決定から開発成果の確認にいたるまで、関与することが不可欠である。しかしながら、この点に関する理解は必ずしも高くない。技術的な問題であり経営上の問題であるとは認識されていないからである。

従来のソフトウェア開発において、CEO、COO、CIO など企業の経営層は、開発費用と効果目標を設定した後は、情報システムの実現をプロジェクトチームに、いわば、丸投げ、してきたケースが多い。つまり開発プロセスに経営層が自ら関与する必要がないと考えていたのである。

アジャイルの普及には、利用企業(発注側)の意識改革が必要ということです。この点について異論ありません。日本では丸投げ開発が今もって横行していますが、それではうまくいかないのだという共通認識を発注側も、開発側(SIer)も持っておくことが求められます。

これは利用企業の責任が大きくなるということを意味します。この点を躊躇されることは明白ですが、レポートでは pp.25 にて、次のように畳み込んでいます。

非ウォーターフォー ル型プロセスが強制するソフトウェアプロセスへのOwnerの濃密な参加という過大な負担を問題視することで、新しいプロセスの採用を拒否しようとしてきた 。実際、アジャ イルプロセスでは、それが大規模になるほどOwnerの負担は大きくなる。それでも、効果的な情報システムを作るには、これらの負担は必要不可欠であると考えられる。

「必要不可欠」とはどういうことでしょうか。それは pp.28 にてさらに強い意志が込められています。

ウォーターフォール型開発へ戻らない覚悟を持つためには、アジャイル開発でしかビジネス上の成功を得ることができない、ウォーターフォール型開発でも開発は完了するだろうけどビジネス上の成功を得ることができない、という裏づけが一番強いと考える。逆に言うと、アジャイル開発でしかビジネス上の成功を得ることができない、というプロジェ クトへアジャイル開発を導入していく。

アジャイルの導入には、利用企業(発注側)が「これしか成功の道はない」と退路を断つ覚悟がいるということです。すなわち、開発企業(SIer)ではなく、利用企業への啓蒙活動が欠かせません。

しかし利用企業にとって最大の懸念は、開発コストです。一括契約(丸投げ)と異なり、上限が青天井というのは受け入れられないでしょう。しかし、これまでの一括契約が必ずしも予算(上限)を超えていなかったかについては、実は疑問が残ります。この点を pp.32 で触れています。

ウォーターフォール型開発では、あえて先の設計はせずに、直近のイテレーションサイクルのみの見積りを行うのが普通である。したがって、見積りが常に概算となり、 ウォーターフォール型開発と比べ、不正確であるとの懸念が生じるのもやむを得ない。

見積りは当初は不確実性が高く、プロジェクトが進捗するにつれて正確さが増大することは知られている。その際に、2つの点を考慮したい。まず、当初のあいまいな時期に要求仕様を確定することが困難であるにも関わらず、工数や費用を確定することによって、 この見積りに制約され、プロジェクトの失敗を助長してしまう可能性がある。要求仕様に基づいて正確に見積もることに精力を費やすよりも、現実的には、過去のデータから、どの程度の工数だったのか、あるいは、期待効果から、投入可能な予算を推定する方が現実的であろう。これは製品の価格を、原価を積み上げるのではなく、市場で受け入れ可能な価格を参照して設定することと同じ方法である。そしてプロジェクトの進捗に応じて仕様が明確になるにつれて実現可能性を考慮しながら、工数、費用を見直すのが、まさしく非ウォーターフォール型開発にふさわしい見積り方法といえるだろう。

避けなければならないのは、従来のように要求仕様があいまいかつ変更の可能性があるにもかかわらず、IT ベンダに見積り依頼を行い、契約を締結してしまい、その費用に拘束されてしまうことである。もし、あいまいな時期に契約をする必要があるならば、それは確定一括発注方式をとるべきではなく、変更可能な出来高方式、単価方式など、状況に応じた柔軟な契約方式をとるべきである。この点は、調達部門の理解が不可欠であり、部門横断的であるがゆえに、経営者の理解が必要となる。

巨大プロジェクトであるほど不透明な部分が強まるため、開発はリスクを伴います。そのリスクに蓋をして、みかけ上、経営者を安心させるのが一括発注方式の罪なところです。多くの失敗プロジェクトでは裁判までもつれていますが、発注企業は係争によって、本来は達成できていたシステム化による業務利益を逸失するだけでなく、これまで費やした時間も取り戻せなくなります。そのデメリットを勘案すると、これまでのような丸投げプロジェクトはリスクが高いとみなすのがむしろ妥当です。

システム開発の不確定要素を一方に押し付けるのではなく、どうシェアするか

システム開発には不確定要素がつきものです。この点を誰に押し付けるか、について発注側と開発側は常にせめぎあっていました。このため、両者は常に対立する立ち位置にあり、一緒にシステムを開発するというチーム体制づくりを困難としていました。

アジャイル開発は、この不確定要素を両者でシェアすることで、対立関係を解消しようという枠組みと言えます。当初はペアプログラミングテストファーストといったテクニック的な次元が注目されましたが、実際には両者の関係性を対立からパートナーに変えるという契約の視点を提供している点が重要です。

しかしリスクシェアとは、つまるところ発注側にも責任を持っていただくということです。それは通常、コスト負担を意味します。アジャイルとは負担のタイミングや説明責任についての枠組みを提供することで、追加負担の必要性をご納得いただくための考え方といってもよいかも知れません。これが発注側がアジャイルを受け入れるかどうかの分水嶺になると考えています。これまで、日本の組織は予算至上主義であり、一度決裁された金額を変えることは困難でした。しかし、誰がこれを困難たらしめたかを突き詰めていくと、経営陣です。アジャイルは経営陣にとって「これしかない」と理解していただくことで、この壁を超えようとしています。

突き詰めていくと、発注側の知恵と工夫こそが、コスト負担増を抑える要諦です。開発側に対する押しつけが結果的に発注側に益をもたらさないことを関係者全員で認識することが前提です。それを受け入れた発注企業は、システム開発の内製に回帰するのでしょう。それを受け入れらない企業と、これまでどおりトラブルという時限爆弾を抱えたまま受注する SIer 企業では、そこに働く人が報われません。その関係性の中でプロジェクト管理を徹底し、コストを押さえることには限界があります。私にとってのアジャイルは働く人のワークライフバランス向上という側面も持ちながら、開発プロセス全体を変えようとする意欲的な枠組みのように見えます。

沖縄サテライトでパネルを行います

Agile Japan 2011 沖縄サテライトでは、各社から集まった技術者と、アジャイルについてのパネルを開催します。主に次のような点にフォーカスをあてる予定です。

発注側・開発側企業の双方にとって今後の枠組みを考える、重要な一日にしたいと考えています。
平日開催ではありますが、是非ともお越しいただければと思います。

お申し込みはこちらから。懇親会も是非。
http://www.java-kuche.org/modules/eguide/event.php?eid=19