ポストSIビジネスのシナリオ: アジャイル型請負開発（１）

アプリケーション | コンサルティング | システムインテグレーション | ビジネス

» 2014/07/30

システムを所有しないクラウドは、その資源を必要に応じて自由に拡大・縮小できる「スケーラビリティ」、変更や変化に柔軟・迅速に対応できる「アジリティ」、意志決定したことを直ちに実行に移せる「スピード」といった価値をもたらしてくれる。しかし、これまでの主流であるウォーターフォール開発では、これらの価値を引き出すことは難しい。

ウォーターフォール開発は、要件定義から始まる。しかし、ユーザーの要求は時間とともに変化する。ビジネススピードが加速するなか、要求が変化するスピードもまた速まっている。すべての要件を定義することからスタートするウォーターフォール開発では、この変化への対応は容易ではない。

また、早期に仕様を確定しようとすると、ユーザーはリスクを見越して何でも仕様に入れようとする。その結果、使われない機能が盛大に作り込まれることになる。そして、いざ完成してみると、「そんな機能は使えない、使わない」となり、無駄な工数と時間を費やしただけになってしまう。しかも、瑕疵担保があるので、工数に関係なく、現場が納得するまで変更要求に応えて改修しなければならない。

ウォーターフォール開発では、すべてが完成してからユーザーが検証することになる。そのため、リスクは後ろに片寄せされ、最後になって大きな負担を強いられることもめずらしくない。何を改善すればいいかも、最後にならなければわからない。そのため、仕様書に忠実であることに専心せざるを得ず、開発の過程で現場の要望に臨機応変に対応する機会を与えられることはない。

お客様の反応が見えない開発者。
どんなシステムが出来上がってくるのか、最後にならないとわからないユーザー。

両者がそんな不安を抱えながら、開発を進めている。

そもそも、ウォーターフォール開発で言う「要件定義書」とは、ユーザーの要求事項を固定し、要件の変更を受け付けないようにするための方便と解釈することもできる。これは、「ユーザーの要件を整理する」と言えば聞こえはいいのだが、ユーザーに要件を全部出させ、「変わっても受け付けませんが、いいですね」といって約束を取り付けているにすぎない。「要件を全部出す」といっても、決まっていないこと、予測のつかないことも多々ある。そのため、「こんなことがあるかもしれない」「何かあったら困るからこの要件も入れておこう」と推測し、どんどん要件を増やしてゆく。

たとえ現時点で必要とされる要件を並べても、ビジネス環境が変われば、想定していない事態に遭遇することは避けられない。要件は、時間とともに変質する。したがって、「要件が変わらない」という前提には、はじめから無理があるのだ。

結果として、開発者は使われないプログラムコードを作ることに手間を費やし、ユーザーは余計な費用を支払わされることになる。

「だからウォーターフォールは悪だ」と申し上げたいのではない。変更の可能性は少なく、あらかじめ要件をしっかりと確定しなければできないシステムもある。しかし、ビジネスサイクルやユーザーの嗜好がこれまでになく速いスピードで変化する中、あらかじめ要件をすべて確定できるシステムが少なくなってきたこともまた事実だ。そこで威力を発揮するのが、アジャイル開発の思想だ。これを受託開発にも取り込んでゆく必要があるだろう。では具体的にどのようにすればいいのだろうか。次回、事例を交えながら紹介しする。

＊更新しました＊　今週のブログ ---

専任の “「お客様の立場」責任者” を持つ

「なんで、俺たちが、そんなことしなきゃいけなんですか？」

ある社内プロジェクト会議で、ベテランのエンジニアが、営業の責任者にかみついていました。こんな不毛な議論を続けても、仕事がうまくすすむわけはありません。

なぜこんなことになるのでしょうか。どうすれば良いのでしょうか。

今週のプログは、そんなことを考えてみました。