僕は「納品をなくせばうまくいく」という「納品のない受託開発」の書籍が出版されてすぐに購入し、何度か繰り返し読んだのですが、毎回「これは面白いわ−！」と読む度に思えました。時間が経ち自分の腹に落ちてきた部分もありますので、今日は僕が思う「納品のない受託開発」で何が素晴らしいのか自分のなりの意見を書いてみたいと思います。

最初にお断りしておきますが、これはウォーターフォールやアジャイル開発をdisっている訳ではなく、あくまで「納品のない受託開発」の良さに注目しております。

「納品のない受託開発」が提供する価値とは「お客様が失敗でき、ビジネスを柔軟に軌道修正できること」だと僕は思います。

通常の受託開発には様々な問題があります。そして一般的な企業などでアジャイル開発なら上手くいくのではないか？とその新しいアプローチを導入したりします。なかなかアジャイル開発をうまく導入することさえ難しい問題ですが、仮にアジャイル開発をうまく導入できたとしてアジャイルなら全てが問題なく解決できるのか？それをうまくやれた時は理想的で素晴らしい開発になるのだろうか？と考えた場合、いくらか問題があることに気が付きます。

アジャイル開発は、イテレーションを小さく回しながらリスクを軽減します。そしてリスクが分かった時点で軌道修正します。アジャイルは基本的に仕様変更に柔軟に対応することがスタンスとしてありますが、仕様変更をいくらでも受けれるという訳ではないと思います。予算が決められているため、仕様変更は無い方が、あるとしてもできるだけ少ない方が良いはずです。いくら「Embrace Change(変化を抱擁する)」とアジャイル開発のマインドを持っていてもあまりにも仕様変更が多い場合は「お客さん、そろそろいい加減にして頂けないかと。。。」となるはずですし、ビジネス的にも赤字プロジェクトになっていきます。

またスタートアップなどで、まだ類似するものが世の中にないビジネスを立ち上げようとする機運がクラウドの影響もあり、多くなってきました。そしてビジネスの移り変わりも激しくなりました。昔は海外で流行ったものを数年後に日本で展開すれば成功したビジネスが今では出来ません。世界で段階的に発生するのではなく同時に発生するリアルタイムでスピードが早い時代にインターネットがしてしまいました。サービスを立ち上げるコストは10年前と比べるとかなり安くなっています。これまで大手でないとできなかったビジネスも個人で立ち上げることが可能になってきました。昔は金銭的な問題、地理的な問題があり、チャレンジしなかったもしくはできなかった人が今はインターネットの力を借りてチャレンジが可能です。このようなスタートアップでビジネスを立ち上げようとする数は、これからもまだまだ増えていくと思います。

このようなスタートアップの開発のサポートは、通常の受託開発では扱いきれなくなってきたと思われます。最初は外注で試して駄目だったから自社で開発者を雇って内製化して今があるといった会社も多く出てきました。しかしそのように内製化にシフトすることにより結果的に成功した企業はよいですが、外注が駄目だったから内製という移行フェーズで失敗する企業や、そもそも発注したシステム会社のリスクを取り過ぎて上積みされまくった見積り金額に驚き、予算が無く先に進めない経営者の方も多いと思います。

以上の「アジャイル開発の限界」、「ビジネスのスピードの早さ」、「時代の変化」などの理由から、これからのビジネスをサポートし、加速させるには、新しい開発のアプローチが必要になってきます。「納品のない受託開発」は社外CTOが出来ることだとよく言われます。開発をし、ビジネスをサポートするコンサルタントとも言われます。しかし、お客様のビジネスの成功は保証できませんし、あくまで決定するのは経営者です。経営者は事業をやろうと思った時点でアイデアがいくらかあるはずですし、ある程度の自信もあるはずです。ですが多くは失敗していきます。当然です。人間ですから。

これまでの受託開発は経営者の失敗を許さなかった開発方法だったと思います。僕はこれまでそのようなことを意識したことは一度もありませんでしたが「納品のない受託開発」が出てきたことによって初めてそれに気づかされました。受託開発とは要件定義をして仕様を確定して、ある程度の長い期間をかけて実装し、その仕様どうりに動くかどうかテストして開発が終わります。その後は細かい機能追加やシステムを安定稼働させるための運用フェーズに移ります。この運用フェーズを知らないまま、開発の一部のみ携わっただけの開発者も多くいますし、それは珍しいことではありません。このやり方だと最初に青写真を描いた経営者が「間違っていない」ことが前提条件になります。もし間違っていた場合はまたさらに多くの出費をし、思いどうりのシステムにするか、予算がなければ「使われないシステム」となってしまいます。私達プログラマでさえ組んでみないと分からないことが多くあります。にもかかわらず、経営者はシステム開発においては、段階的に試しながら軌道修正したりすることができません。よくよく考えれば非常に厳しい仕組みです。

「納品のない受託開発」はこの問題に風穴を空けました。アジャイル開発では開発者に変化を要求し「Embrace Change(変化を抱擁する)」をさせます。その主体はあくまで開発者です。「納品のない受託開発」では、そうではなく主体は経営者(とサポートするプログラマ)で、「ビジネスの主役である経営者に変化を抱擁させた」のではないかと思います。プログラマに求められるものは変化に対する柔軟性や失敗した時にお客様からの相談に答えられ、現状の適切な説明とアドバイスが出来ることです。成功するまで共に戦ってくれ、失敗が許される安心感を与えられることが僕は一番の価値だと思います。

「納品のない受託開発」が生み出したものは「ビジネスの変化を抱擁する」というパラダイムシフトになります。ですから仕様変更は当たり前ですし、仕様変更が必要な時は、問題があることが分かったということですから、今後の方向性を決定する材料にもなります。これまでの受託開発とは考え方がずいぶん変わってきます。この開発には色々な特徴、魅力、価値がありますが、既存の仕組み自体を変えてしまっていることが、僕が「納品のない受託開発」に惹きつけられる一番の魅力になります。

個人的にソニックガーデンはこれまで働いたことがないため、正確には分かりませんが、倉貫さんのやられている会社ということで外からはアジャイルをやっているのだと思われがちですが、実はソニックガーデンの内部ではアジャイル開発をやっている意識や実感がほとんどないのではないか？と想像しております。

倉貫さんからコメントを頂きましたので追記します。

これまでの受託開発は経営者の失敗を許さなかった開発方法

そうなんですよね。開発側は理解できなかったところかもしれないですけど、そうなんです。

ソニックガーデンの内部ではアジャイル開発をやっている意識や実感がほとんどないのではないか？

その通りです。社内でアジャイルなんて言ったことないです。

ということで、見当違いなことを書いた訳ではないことが分かってホッとしました。技術コミュニティにはアジャイルの亜種のように思われたりしますし、経営者の方には「ほんとうにこの本に書かれたとおりのことが出来るのだろうか？」と思われる方もいらっしゃるかもしれませんが、まずは書籍を読んで分からないことがあれば、直接ご本人にお聞きすればよいと思います。僕は「ビール片手に納品の無い受託開発を語る会」があり、そこで直接、倉貫さんにたくさん質問をしました。その都度、理路整然とした答えが返ってきました。不思議と論破されているような感じはなく、逆に清々かったです。