今日12月1日は朝から雨となったここ南関東ですが、お昼には青空が広がって寒さも和らぎ過ごしやすくなってきました。気分もよく師走の入りとしてはまずまずの感じです。
アジャイル開発の最大のメリットである（とキットPMが考えている）のは、現実的で確実な要件定義を可能にすることでした。なぜなら、実際に動くシステムを評価（または批評）しながら、必要な機能仕様”だけ”を実現することを目指すことができるから。
でも、アジャイルの考え方はそれは一つの文化であり、既存の文化を破壊してしまうパワーを持っているため、なかなか国内の企業に浸透していくのが難しく、その知識としての認知は進んでいますが、実際の取り組みはまだまだといったところではないでしょうか。
そこでアジャイルの特性を生かしつつ、IT開発プロジェクトのオーナーであるユーザー企業も納得し、開発投資を行い易くする方策はないかと考えようというのが、前回明らかにした今回のテーマです。
前々回、一つのアイデアとして要件定義フェーズをアジャイルで、基本設計（外部設計）以降をウォーターフォールスタイルで実施することを提案してみました。
ただこれも、要件定義フェーズで評価可能なシステム（実際に動くシステム）を作成できることが必要となります。これができないとユーザーが動くシステムを批評することで、本当に必要な機能のみを実装するというアジャイルスタイルの良さを生かせないことになります。
と、ここまで考えてきて気付いたのは、この方法論は従来からある「プロトタイプ開発」とほぼ同等の手法だということです。
なーんだ。と思われた方申し訳ありません。これまで長々お付き合いいただいて結局結論は「プロトタイピング」かということですが、これはこれで面白い結果かもしれません。
さて、プロトタイピング手法も概念は一般的なのですが、実際に利用されているITシステム開発の現場はそれほど多くはないようです。
その原因は幾つか考えられますが、一つはプロトタイプ開発にそれなりの手間がかかってしまうということです。そのため、何らかのツールを利用することが必須となるのですが、業界基準になるツールが存在していないこと（帯に短し、タスキに長しです）、方法論が確立されていないこと、メジャーなマンジメントガイドラインが存在しないことなどが障害となっているようです。
話しを先に進める前に、「プロトタイプ開発手法」の概念を確認しておきましょう。
プロトタイプ手法もしくはプロトタイピング開発と呼ばれるITシステム開発は、仕様を検討するためのお試しステムを作って、それを評価することで要件を固めて行こうという考えです。
実はこの考えにスパイラルという、繰り返し（開発＞評価＞開発）の概念を持ち込んだ考え方もあります。これになるとほぼアジャイルの考えによく似たものとなりますが、評価用に作成したプロトタイプは、最終的に破棄してしまうのでそこはアジャイルとは根本的に異なるところです。
次回はプロとタイピング手法とアジャイルスタイルについて考えて行くことにします。