「すべてを作らない」 ～アジャイルを使った新しいシステム開発 (2)
前回書いたエントリの中に「紛れ込む不要な要件」として、当初定義した仕様のうち多くが、システム稼働時には不要になってしまう話を書いたのですが、そういったシステム開発を繰り返した結果どうなるか、というデータが以下にあります。
このスライドの 5 ページ目に、一般的なソフトウェア開発プロジェクトで機能のどれだけが実際に使われているかを調査した結果が出ています。実装された機能のうち、「常に使われる」「よく使われる」「たまに使われる」を合わせても 36%。「ほとんど使われない」「まったく使われない」が 64% ということです。元データを見つけられなかったので詳しいことはわからないのですが、皆さんの感覚的にもこんなものではないでしょうか?
「すべてを作らない」プロジェクトの進め方
さて、それでは今回の本題です。「すべてを作らない」ためにはどうしたら良いのか? ひとつの例を挙げて考えてみましょう。
顧客の要求仕様で要件が 200 件、開発期間 2 年のプロジェクトがあったとします。これに A 社、B 社、C 社が応札したとします。A 社と B 社の提案内容は大体同じで、2 億円くらい。(同じ RPF で適正に見積もれば、見積額は概ね似たような金額になるものですよね) しかし、C 社はちょっと変わった提案をします。
「要求項目のうち、『すぐにでも使いたい、絶対に必要な項目』を50個選んで下さい。それを、半年間・5千万円で開発し、納品します。それで足りなければ、『さらに必要な機能』を50個選んで下さい。」
これを4回繰り返すと、他社と同じ2年間、2億円のプロジェクトになりますが、途中で機能に満足した場合にはその段階で開発を止めれば良く、それ以上の費用はかかりません。もし、この要求項目の中に「ひょっとしたら必要になるかもしれない」項目が80個紛れ込んでおり、そのうちの50個が最終的に「やはり必要無かった」項目であったとするならば、このプロジェクトは一年半・1億5千万で完了することになります。顧客側も開発側も、無駄な時間やコストを負担する必要はありません。
これは一見、2年のプロジェクトを半年単位のウォーターフォールに分割すれば良いようにも思えますが、ウォーターフォールの「途中で変えにくい」問題点は残ります。この問題が、アジャイル開発の手法を使うことによって解決できるのです。
アジャイルを使った開発の実際
アジャイル開発をWikipediaで調べると「開発対象を多数の小さな機能に分割し、(中略) 1 つずつ機能を追加開発してゆく」とあります。戸田社長が手がける実際の開発プロジェクトは、概ね以下の様な形で進みます。
まず一番最初に、「動く」プロトタイプを作ります。ここで大事なのは「動く」ことです。ツールは何でも良いですが、紙芝居では駄目。実際の画面遷移や操作感を実際に見て頂いて、イメージに合っているかどうかを確認します。結局、人間の想像力にはバラつきがありますし、限界もあります。紙芝居を見せて「分かったはず」と考えてしまうのが、後で問題になる元なのです。これは何もアジャイルに限った話では無く、ウォーターフォールでも活用できるやり方でしょう。
開発にかかると、最初に最も基本となるモジュールから作り始めます。とにかく動くものを速く作るために、機能はミニマムです。エラーチェックなどは省き、「絶対に正しいデータ」がきちんと処理されることを目標にします。最初のリリースはこのモジュールになります。お客様は、この段階からレビューを行います。動作が想定と違う場合にはどんどん要望を出して頂き、次のリリースに反映させていきます。(お客様へのリリースは 1 週間毎が基本です) その次が、想定を外れたデータが来ても大丈夫なように異常系の処理を加えたもの、さらにその次は想定を外れたオペレーションを行っても大丈夫なもの、といったように、リリース毎に機能を増やしていきます。
具体的なプログラミング手法については次回書きますが、開発期間中、チームは毎朝ミーティングを行い、その日何を開発するかを決め、その日の最後にそれまでできあがったすべての機能を統合してテストします。お客様へのリリースが週に一回、あるいは2週間に一回だったとしても、それまでの間、毎日テストが行われるわけです。テストでエラーが出れば、翌日すぐに修正されますから、お客様にリリースされるモジュールはバグが非常に少ない状態です。
得られる効果
これによって、どんな効果が得られるのでしょうか?
実際のプログラムを使って機能を検証できる
紙芝居やドキュメントで画面遷移や動作を説明されても、なかなか具体的なイメージは沸きません。それよりも、「本番の」プログラムを使ってみることができれば、動作の不具合や想定との解離をすぐに見つけられます。
変更要求は大歓迎
アジャイルでは機能が細分化されていますから、変更に必要な時間は最低限で済みます。このため、変更作業による工程への影響はほとんどありません。むしろ、変更によってシステムがお客様の望む形になれば、最終的に顧客満足度が上がります。仕事量を増やさずにお客様に感謝して頂けるのですから、変更要求は大歓迎なのです。
開発期間中、徹底的に繰り返されるテスト
このやり方では、一番最初に作った部分 (= 最も重要な部分) は開発期間中「毎日」テストされることになり、最後までバグが残るようなことは無くなります。ウォーターフォール型開発では、プロジェクトの最後の部分で統合テストが行われますが、この時点で根本的な問題が発覚すると、修正に多大な時間がかかります。アジャイルでは、最も重要な部分が最も多くテストされることになり、非常に合理的です。
進捗会議不要
ウォーターフォール型では必須とされている進捗確認会議も、不要になります。どこまでできたか、毎週実物をお客様に納品しているからです。お客様は、実際に動かして機能を確認できますから、どんな説明資料よりも説得力があります。バグや修正要求があれば、次回のリリースで修正されます。
関係者を集めて進捗を確認する会議を行うのは、お客様が不安だからです。実物があれば、会議の必要などありません。開発チームも、会議用の資料を作ったり会議のために移動するよりはプログラムを書いた方が良いに決まっています。
ドキュメント不要
機能説明や使い方などのドキュメントは必要ですが、仕様確認書やシステム設計書、作業報告などのドキュメントは、(お客様が固執しない限り) 必要無くなります。動いているプログラムがすべてだからです。変更の必要があれば、要求はいつでも、いくらでも受け付けます。
次回は、アジャイル型開発の迅速さと適応力、高品質を実現する数々のテクニックについてご紹介します。
ITソリューション塾【第18期】を2月4日から開講します
インターネットで得られる断片的な情報を「いろいろ知っている」だけでは、お客様に信頼される営業にはなれません。様々な情報の関連性を把握し、組合せ、想像力を働かせなければ、本質は見えてこないのです。
最新の情報を全体の中に位置づけ、大きなトレンド、これからの方向性を見つけ出すためには、これまでのITの歴史に学び、様々なキーワードの関連を頭の中に構築しなければなりません。この塾が、そのようなアプローチの一助になればと考えております。