「すべてを作らない」　～アジャイルを使った新しいシステム開発 (1)

あけましておめでとうございます。今年初投稿です。

ネットコマースさんと一緒に開催しているITソリューション塾では、様々な最新ITキーワードを、その歴史的背景や他の技術との繋がりと共に解説しています。その中で一昨年から (株) 戦略スタッフサービスの戸田社長にゲスト講師としてお越しいただいて、アジャイル開発について講義をしていただいているのですが、これがもう目から鱗のお話なんです。それについてずっと書きたかったんですが、なかなか手を付けられずにおりました。ここでは書けないこともありますので、うまく説明できるかどうか不安なのですが、自分の考えを整理するためにも書いてみたいと思います。おそらく数回にわたるシリーズになると思いますが、よろしくお付き合い下さい。

戸田社長は外資系コンピューター企業のご出身で、退社後、米国で日系企業の CIO/CEO を歴任され、今ではコンサルタントとしてアジャイル開発の伝導を行っています。戸田社長が手がけたプロジェクトの成果について、いくつかキーワードを書いておきます。

• 残業/休日出勤無しで納期厳守、利益確保
• 顧客満足度は最大級
• 進捗管理会議、ドキュメント不要

いかがでしょうか? いろいろと刺激的な言葉が並んでいます。開発プロジェクトの多くが納期遅延や予算超過に苦しんでいると言われる中で、にわかには信じられない言葉です。しかし、これが戸田社長が取り組む「アジャイル開発をベースにした新しいシステム開発」の姿なのです。

アジャイル開発の目的とは

何回か戸田社長の講義を受けてみて私が理解したことは、戸田社長が取り組むアジャイル開発は、開発手法という枠を越えた、システム開発の進め方・理念であるということです。

アジャイル開発は、一般にはソフトウェア開発を迅速化・効率化するためのプログラミング手法とされています。Wikipediaには「ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である」と説明されています。アジャイルについては別の回でご説明しますが、機能を小分けにして短い期間の開発を繰り返してプログラムを作っていく手法で、有名なものでは、スクラムやエクストリームプログラミング (XP) などがあります。
このアジャイル型の開発手法をうまく使いこなすことで、大規模なシステム開発を非常に効率的に行おうというのが、戸田社長が取り組むアジャイルなのです。これには、プログラミング手法、人事評価制度、要件定義の方法、プロジェクトの見積り方法の変更などを包含するシステム開発のための手法・理念までが含まれます。この開発手法が目指しているものとは何なのか?

それは、「すべてを作らないこと」です。

「すべてを作らない」とは、どういうことか？

アジャイル開発と比較されるウォーターフォール型開発は、先のWikipediaでは「要件定義、分析、設計、実装、テストの各工程を、厳格に、予め計画された順序に従って行う。 」と解説されています。また、ウォーターフォール・モデルの項には「ウォーターフォール・モデルの利点は、工程の進捗管理がしやすいことである。」とあり、大規模なシステム開発を計画的に遂行していくために向いているとされています。

ウォーターフォール型開発の最初にある「要件定義」は、アジャイルを含め、あらゆるシステム開発において必要な手順でしょう。何を作るかが決まらなければ、作り始めることができないからです。しかし、ウォーターフォールにおいては、この段階ですでにプロジェクトが破綻する可能性をはらんでしまいます。

ウォーターフォールでは、要件を決めて、そのシステムが完成して稼働するまでには短くて数ヶ月、大きなプロジェクトでは何年もかかることがあります。完成までに1年かかると見込まれるプロジェクトがあったとすると、要件定義は最低でも1年先のことを考えねばならず、システムを3年使うことを考えれば、できれば4年先のビジネスニーズを見越して作らなければなりません。これは非常に困難です。(個人的な感想を言えば、不可能でしょう) これが何を引き起こすかというと、要件の肥大化です。

紛れ込む「不要な要件」

発注側は、安全を見越して必要になる「かもしれない」要件をどんどん盛り込みます。開発する側も、あとからいろいろ追加されるのは困りますし、要求が増えれば見積額も増えますから、それを推奨します。こうして要件はどんどん膨れあがり、開発期間が延長され、見積額が増大します。

ある調査によると、このようにして定義された要求の25%が24ヶ月後には「変質」する、あるいは必要無くなる、ということです。もともと必要かどうか疑わしい機能が盛り込まれているわけですから、ある意味、あたりまえとも言えます。ビジネス環境の変化が激しくなってくれば、この比率はもっと上がるでしょう。

これが何を意味するかというと、顧客は必要の無い機能にお金を払い、開発者は必要の無い機能をプログラミングし、結果としてシステムが複雑化し、テスト工数が増え、プロジェクトが遅れたりコストが膨らむリスクが高くなります。しかし、だからといって予算が無制限に増えるわけでも無く、増えた分のコストは開発側が負担することもあるでしょう。実際に、納期を守れなかったり、コストが膨らんで赤字になったというプロジェクトの話は良く聞きます。

これが、ウォーターフォールモデルが潜在的に抱える問題点です。そしてそれは、あらかじめ立てた計画に沿って開発を進めることによって進捗管理を行うため、いったん動き出した場合に途中での修正が行いにくいというウォーターフォール型の特徴に根ざしています。

不要な機能は作らない

この問題を解決するためにはどうすれば良いのでしょうか? その答えが、「すべてを作らない」なのです。言い換えれば、「不要な機能は作らない」ということです。あたりまえのことですが、実はこれは簡単なことではありません。どうしたらこの目的を達成できるのか、そして戸田社長がアジャイルを採用した理由とは? 次回以降でそれをご紹介します。

ITソリューション塾【第18期】を2月4日から開講します

インターネットで得られる断片的な情報を「いろいろ知っている」だけでは、お客様に信頼される営業にはなれません。様々な情報の関連性を把握し、組合せ、想像力を働かせなければ、本質は見えてこないのです。
最新の情報を全体の中に位置づけ、大きなトレンド、これからの方向性を見つけ出すためには、これまでのITの歴史に学び、様々なキーワードの関連を頭の中に構築しなければなりません。この塾が、そのようなアプローチの一助になればと考えております。