2006年10月07日
アジャイル（ａｇｉｌｅ）プロセス
先日、実装グループの幹部に「Web構築手法にアジャイル（ａｇｉｌｅ）の考え方を取り入れてみては？」とニタっとしながら質問すると、苦笑交じりで「ん～～～」と考え込んでしまって返答がいただけなかった。
アジャイル（ａｇｉｌｅ）プロセスに対峙するものとしてウォーターフォールプロセスがある。ウォーターフォールプロセスを一言でいえば、システム開発分野において、厳格な設計書に基づいてプログラミングを行う手法で、一般的な解釈では「手戻り」を許さない逐次開発型。納期になるまでユーザーは完成品を見ることができないという欠点が存在する。
アジャイル（ａｇｉｌｅ）プロセスは、最近よく話題になるシステム開発の手法。2001年に「アジャイル開発宣言」が採択。アジャイル（ａｇｉｌｅ）は元来「俊敏な」「機動的な」という意味。最も大きな特徴は「要求の変更を受け付ける」ということ。つまりウォーターフォールプロセスの欠点である「手戻り」を許そうという特徴がある。
Web構築の場合、表現手法やツールが多彩であるため、最初「要件定義」を明確にしておかないとトンデモナイ方向に行ってしまうことがある。特に「スコープ（範囲）定義」は重要だと認識している。受託企業サイドの視点で考えると納期・品質・収益に極めて重大な影響を及ぼすからだ。しかしながら将来の方向性としてある程度「手戻り」を許す仕組みを組み込む必要を感じている。
-
理由は下記の通り。
顧客企業様と合意したプロジェクトにおける最初の「要件定義」は、顧客企業様にとって「本来あるべき要件定義」とは限らないという現実的な問題が存在しているからだ。言い換えれば、最初の「要件定義」＝顕在化した要求であるだけで、実際は、潜在的要求が潜んでおり、そこに本当の要求が存在しているということ。従来のウォーターフォール型では納品時までその存在が明らかにならない場合が多い。これでは顧客企業様にとって不幸な事態が生じることになる。
Web構築を担う企業の一員として我々は上記のような現実的問題をさけて通ることは許されないだろう。ではどのようなアプローチが考えられるだろう？
いくつかの切り口が考えられるが、僕的には次のようなことを考えられるのではと思っている。
１．自助努力型（成熟度モデルを活用）
２．サンプル提供型（見える化）
３．アジャイル型（手戻りを許す）
上記に関して個別に解説してみる。
自助努力型（成熟度モデルを活用）は、過去のプロジェクトにおいて「要件定義書」に基づいて開発したものが成果物として納品されていく段階において、どのようなギャップが発生したかを記録し、データベース化し、傾向をつかみながら、将来発生するプロジェクトにおいて「要件定義書」を作成する段階で、クリティカルな部分を協議のテーブルにのせるというやり方。方法論としては、成熟度モデルのレベル３～５のプロセスを活用する。
サンプル提供型（見える化）は、《プロジェクトにおける最初の「要件定義」は、顧客企業様にとって「本来あるべき要件定義」とは限らないという現実的な問題が存在している》本質的な問題は、顧客企業様にとって「見えないものはイメージできない」というシンプルな理由によるもの。そこでプロジェクトで使用するツールや手法を見える化し、最終成果物がどのような姿になるかを予め把握していただく。
アジャイル型（手戻りを許す）は、上記で説明したように基本的には開発プロセスに手戻りを許す仕掛けを予め組み込んでしまう。
それぞれ一長一短があるが・・・・・
自助努力型（成熟度モデルを活用）は、時間がかかるし、組織的活動が必要になるが、将来にわったって組織のレベルを上げることに貢献するものと思われる。
サンプル提供型（見える化）は、企画部門、マーケティング部門、商品開発部門との連携が必要になるだろう。具体的には、顧客企業様による「要件定義」を「実装計画」に落とし込む段階で、それらに使用するツールや手法をサンプル化し、予め納品時のイメージを顧客企業様が理解できるようにする。日頃の努力が必要になるが、自社のWebサイト等を活用し、ツール、手法などの開示や、それぞれに対してサービス化や商品化するなどということも有効であり、顧客企業様に対して理解や信頼の促進に役立つものと思われる。
アジャイル型は、手戻りを許すタイミングをプロジェクト計画書に予め組み込む仕掛けが必要だと認識する。どのタイミングでどの範囲に関して手戻りが許されるかを明確にしておくことによって、顧客企業様と受託企業との間の関係性を損ねることなくプロジェクトが進行していくだろう。
--
システム開発とWeb構築は近い領域ではあるがイコールはないので、今ブーム化しているアジャイル（ａｇｉｌｅ）プロセスを妄信的に活用する気にはなれない。しかしながら、いくらウォーターフォールプロセスという理想形を追ったところで、プロジェクトがうまく行かないようでは問題だ。その点、アジャイル（ａｇｉｌｅ）プロセスは現実的な解決策を開発プロセスに組み込もうとしているような気がする。
まず一歩として、よい考え方を部分的にでもいいから導入しても面白い。たとえば、ウォーターフォールプロセスをベースにしておきながら、「中間成果物レビュー」をフェーズごとに設け、その作業を発注者と受託企業が一緒に行う。そのレビュー（見直し）のときに手戻りを許す仕掛けを作っておくだけでも、大きく前進するものと思われる。
いろいろ研究していただきたい。
コメント
はじめまして。
Ebiと申します。
アジャイルについて検索していてこのブログを見つけました。
Web構築にアジャイル手法の利用を検討されているようですが、
変化の激しいWebシステムの構築にはスピード重視のアジャイルが開発手法としては良いと思います。
(私の場合、Web構築にはアジャイルでの経験しかないので きっちりと比較した結果という訳ではないのですが…)
また、ブログ内で「アジャイル=手戻りを許す」とありましたが、
アジャイルが手戻りを許すのは結果論であり、手戻りを許すからアジャイルという分けでは無いと思います。
例えば、禁煙をするとニコチン摂取量は減りますが
軽いタバコを吸う事は禁煙とは呼べないのと同じです。
(分かりにくい例えでスイマセン…)
最近ではアジャイルという開発手法が注目されているのですが、
どこの企業も興味はあるがウォータフォールからの
切り替えが難しいとの理由からなかなか手を出せていないのが現状のようです。
資料や、情報をもってアジャイルに移るのではなく
アジャイル手法を利用して開発を行っている
企業からやり方を学ぶのも良い方法だと思います。
以下、私の経験から感じた事なので必ずしもそうとは限らないのですが、
・大手製造業(売上が数兆クラス)
・小さいソフトハウス(社員数1桁)
上記のような企業は比較的アジャイルな手法で
開発している事が多いと思います。
おそらくスピードが会社の運命を左右する場面が
多いからではないかと思います。
Posted by: Ebi : 2007年02月28日 23:09
Ebi様、コメントありがとうございます。
＞また、ブログ内で「アジャイル=手戻りを許す」
＞とありましたが、アジャイルが手戻りを許すの
＞は結果論であり、手戻りを許すからアジャイル
＞という分けでは無いと思います。
大変勉強になります。
その他興味深い情報をいただき感謝いたします。
今後ともよろしくお願いいたします。
高橋
Posted by: 高橋 : 2007年03月02日 10:21
