アジャイル開発のボトルネック

アジャイル開発のボトルネック

「お金なら出しますから、4ヶ月のところを2ヶ月で作ってくれませんか?」

システム開発で、顧客からこう言われた時、どうするか?

SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。

ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。

冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているから出る発言だろう。

さて、この話の前提として、タイミングは「仕様」がまだ完全に固まっていない状態であり、ここで言う「仕様」とは、ユーザから見たシステムの挙動(正しい動き)のことを指している。開始前に「仕様」が完全に固まった(夢のような)プロジェクトは見たことがないため、おそらく一般的な話。

また、発注者と開発者の2つのロールがあり、「仕様」を決めるのは発注者の役割で、「仕様」に従ってプログラムを作るのが開発者の役割、また、完成したプログラムが「仕様」に沿ったものかの確認をする(検収する)のも発注者の役割、としている。

この前提が違う、という場合は、この話は当てはまらない。しかし、発注側とした役割もSIerがやっている場合があるだけで、ソフトウェア開発の工程/手順としてはそれほど違いはない筈である。

改めて。そんな状況で本当に開発者の開発速度がボトルネックになるのだろうか?コストをかければ、完成が速くなるのか?「仕様」が完全に固まっており、発注側による「検収」を含まない、ということであれば可能かもしれない。しかし、「仕様」が完全に固まっていることって本当にある訳がないし、きちんと「検収」されていない状態を完成とは呼ばない。しかし、「要件定義」->「開発」->「検収」という流れが1度しかないウォーターフォールであれば、そう考えたっておかしくない。

しかし、今はアジャイル開発におけるボトルネックの話をしている。アジャイル開発であれば、その流れは何度も繰り返されるし、ただ単に作るだけで完成かといえば、そうではない。本当に発注側が欲しいと思っているソフトウェアが提供されてこそ完成と言える。

繰り返しながら、「仕様」を決め「開発」をし「検収」していくとしたら、開発する速度と同等の速度で、仕様を決めていかねばならないし、作られたソフトウェアの確認をしていかなければならない。そう考えたら、かなりの時間を発注側が割かねばならないはずである。おそらく、開発と同等かそれ以上のコスト(工数)がかかるのではないか。つまり「オンサイト顧客」という状態だ。

そう考えると冒頭の言葉はありえない。お金を出して時間内に開発側が作れる量を増やすという解決策だけでは駄目で、発注側にも、コストをかける用意が必要になる。しかし、発注側の人間は多くの場合、色々なプロジェクトや業務に携わっていることがあり、容易に沢山の工数をかけることは実質不可能なはず。そう考えると、開発にいくらコストをかけても、仕様の決定と成果の確認が追いつかなければ、意味がなく開発側も持て余すことになる。

実際に、週に2〜3度の2〜3時間の打ち合わせで、開発側と発注側のコミュニケーションが間に合うかというとそんなことはなく、発注側からの回答を待つために、無駄なスイッチングコストが発生したり、回答結果によっては無駄な開発をしていたことが発覚したり、ということを経験した方は沢山いるのではないだろうか。私はある。

逆に今、私は発注側として仕様を決める作業と確認の作業をしているが、開発側の速度を最大限にするために、平日の朝までに、毎日の確認と仕様の決定を行い、なるべくリアルタイムで開発側からの質問に答えるようにしている。ここで速度の限界は、発注側である私の速度になっている実感がある。

つまり、発注側のかけるコスト(工数)の限界が、ソフトウェア開発における速度の限界点なのだ。プロジェクトが成功するかどうかの分水嶺と言える。

これは実はアジャイル開発に限らず、一般的なウォーターフォールのソフトウェア開発でも、まとめて要件定義や検収テストをしているだけで、結局、同じくらいの工数がかかっていたのではないだろうか。もちろん、要件定義の前のビジネスや業務検討のフェーズを含めれば、である。

アジャイル開発では発注側が行う作業へのコミットが細分化されて見えるので、開発と同程度の工数が必要だという傾向が顕著に見えるだけかもしれない。発注側と開発側にかかる工数比があるように思わせたのは、そうしないと儲からないSIerの罪であろう。

『ソフトウエア開発においては、開発側が必要とする工数と、発注側が必要する工数を同等にするべきである』こんな法則があるのではないだろうか。そして、『発注側は、自社がかけれる工数(コスト)以上の、発注をしてはいけない』というルールでもあれば、うまくいくのではないだろうか。

開発における生産性だけを考えるだけでなく、全体としての視点を持ちたいものである。

倉貫 義人

株式会社ソニックガーデン代表取締役社長。経営を通じた自身の体験と思考をログとして残しています。「こんな経営もあるんだ」と、新たな視点を得てもらえるとうれしいです。

ニュースレター

ブログの更新情報や、ここだけの執筆裏話など、3ヶ月に1度のペースでお届けします。

購読する
書影: 私はロボットではありません
倉貫書房の新刊

私はロボットではありません

長瀬光弘 著

「嫌な未来なら変えればいい」

あなたの毎日にも、きっと繋がる。株式会社ソニックガーデン代表倉貫義人のブログ「Social Change!」のノベライズ化第一弾。

BASEで注文する
ページ上部へ