ソニックガーデンの倉貫さんから、「納品をなくせばうまくいく - ソフトウェア業界の "常識" を変えるビジネスモデル」を献本いただきました。ありがとうございます。
http://www.amazon.co.jp/dp/4534051948
倉貫さんとは昨年末にはじめてお会いしました。情報産業新聞社の企画による今年の新春座談会で倉貫さん、戦略スタッフ・サービスの戸田さんと私の3名で放談する機会をいただいたのがきっかけのご縁です。
このブログを書いている時点での Amazon のベストセラー商品ランキングでは「ビジネス・経済>IT>情報・コンピュータ産業」で1位、「コンピュータ・IT>インターネット・Web開発」で6位と、すでに本書はトレンドを形成する勢いです。ここでは私の視点から本書の紹介を通して、システム開発の将来に思いを馳せたいと思います。
本書は誰のためのものか
何といってもWebを中核とした新しいビジネスモデルを立ち上げるスタートアップ企業(または既存企業で新規参入を担当する部署)に有益です。素早くシステムを手に入れたいが巨額の開発費は出せない、ユーザーの声を聞きながらシステム仕様を変えていきたい、自社では高度なスキルをもったエンジニアを雇用することは難しいといった要望を抱えるところは、まさに自分たちのためのサービスだと思われるでしょう。事例として紹介されていた AsMama やトライフのようなニーズを支えるには、これまでの「はじめに仕様ありき」ではカバーできません。
しかし本書が提唱する新しいビジネスモデル(以降、倉貫さんモデルと呼びます。)は、同業他社に刺さるものです。おそらく多くの経営層が「このモデルは今後、主流になるのか」「同じことを自分たちも実践できるだろうか」「これは、儲かるビジネスなのか」といった観点で検討しているはずです。倉貫さんの茶目っ気を感じるのは、自社のビジネスモデルやノウハウを余すところなく本書で公開しているところです。そんなことをして真似されたらどうするのか - いえ、倉貫さんは真似してほしいという意図で執筆されています。が、それは「おいしいところをつまみぐい」するだけでは成立しないことも明記されており、これまでの常識をすべて捨て去る気持ちでルビコン河を渡ってほしいというメッセージになっています。倉貫さんにとって、同じようなビジネスモデルを掲げる会社が増えるかどうかは重要です。これについては後述します。
そして本書は現場のプログラマにとっても光明になるでしょう。いえ、すでに倉貫さんは多くのプログラマー向けコミュニティで活動されていますので、すでに期待を一身に背負う立場といってもいいはずです。私が最初にアジャイルと、ワークライフバランスという概念を知ったのは、チェンジビジョンの平鍋さんと出会ってからでした。もう10年前になります。その後、平鍋さんには沖縄で講演をお願いし、多くのプログラマに「エンジニアとしての幸せ、価値観を見つめ直す」きっかけを与えていただきました。倉貫さんの提唱するビジネスモデルはその流れにつながっていると感じます。余談ですが、今年の「Agile Japan 2014 サテライト沖縄」(28日)には平鍋さんと、倉貫さんが来沖します! つくづく縁があると感じます。
「納品のない受託開発」の広がりがもたらすもの
本書には "ソフトウェア業界に革命をおこす" という節があります。このモデルが社会に認知されるまでには10年はかかるだろう、しかし10年後には当然のようになっているはず、という未来予測が込められています。ではこのモデルが成功するための条件は何か。それは、このモデルを支持する顧客がどれだけ増えるかということに尽きます。倉貫さんも私も共通で課題としている「一括請負」ですが、実際にはこれを支持する顧客層が存在します。なぜ支持するかといえば、顧客にとってリスクを最小化できるというメリットがあると考えられていたためです。しかし過去数十年にわたる開発事例から、一括請負の弊害も明らかになっています。私自身が感じる最大の弊害は、発注側である顧客を楽にしようとすればするほど、システムのイニシアティブ(主導権)が失われ、結果的に問題の多いシステムを高いコストで維持せざるをえないという高コスト体質に陥いるという罠です。"革命" とは、突き詰めれば顧客がシステムのイニシアティブを取り戻すことです。そして顧客と開発者の距離を縮め、開発者が直接、顧客と対話しながらシステムをつくっていく。一見、正論で良さそうに見えますが、なぜこれが傍流であるのか。ここに重大な鍵があります。
顧客にとって一括請負が良いと思える最大の理由は、経営陣に対する予算獲得の説明が行いやすいこと、というのが私の考えです。いくらの開発費で、こういうシステムが手に入る。それ以上の追加コストはかからないと約束した開発企業に発注すればいい。これが「納品」モデルの本質です。そして倉貫さんは、この「納品」をなくせばうまくいく、と断じています。そのためにはシステムに完成はないということ、常に開発と運用が並行して実践されること、一度に大きな予算を獲得して機能を盛り込むのではなく、毎月一定額の予算で少しずつシステムを成長させるという発想を顧客側に持ってもらうことを挙げています。多くの顧客がこの思想を共有できるなら、それはまさに "革命" 的と呼ぶにふさわしいです。これまでに多くの業界関係者がトライして、変えることができなかったのが納品至上主義というパラダイムでした。それは企業の予算主義とセットだからです。この壁に対して、今度こそ変われるのか、という熱い視線で倉貫さんを応援する人は多いと思います。それは顧客にとってもメリットがあると同時に、開発側にとってもメリットがあります。どちらが先というより、両方とも盛り上げていこうというのが倉貫さんのアプローチと理解しています。この10年で、納品しない開発という市場を立ち上げることが大切ですので、トライしてみたいと思うところは(顧客でも同業他社さんでも)積極的に倉貫さんに接触をとるとよいと思います。これが倉貫さんがノウハウを公開する理由だろうと感じています。
「超高速開発」との相性
最後に超高速開発コミュニティの発起人の一人という立場から、この倉貫さんモデルを論じます。私の中では「納品のない受託開発」と「超高速開発」はまったく競合しません。むしろ高い相乗効果が見込めると考えています。
超高速開発とは、設計情報(リポジトリ)を中心としたシステム開発という思想が中核になっています。これは規模を問わず、またウォーターフォールかアジャイルかといった体制も問いません。よって「納品しない契約 x 超高速開発ツールの活用」というビジネスモデルは容易に成立するどころか、最強の組み合わせではないかと思うほどです。
しかし整合性をとらないといけない部分はあります。その一つが、本書では「動いているソフトウェアが仕様そのものであり、文書や資料は存在しない」という点です。これは開発したソフトウェアの中身に精通している技術者が、その顧客をずっと担当するという前提によって担保されています。私はしかし、プログラムのソースコードイコール仕様という世界も変えたいと思っており、ソースコードより一段、抽象度の高い「リポジトリ」を文書や資料という位置づけで管理する方がよい、という立場です。この違いがどのように影響を及ぼすかは、私の中ではまだ落とし込めていません。
この相違はあれど、倉貫さんモデルが超高速開発の思想と折り合わないことはないと思っています。使う技術体系が異なっても、倉貫さんモデルは汎用性があるため対応できるのではないでしょうか。
最も影響を受けるのは現場のエンジニア
倉貫さんも私も、あるゴールを共有しているように思います。それは「一名の開発者が何でもこなす」という世界を実現することです。倉貫さんはそのために顧客との契約の見直しに着手し、開発者がその能力を余すところなく使える環境を提供しようとしています。私はツールの能力の向上によって開発者を支援する道を選びました。アプローチは異なりますが、その目指すところは「少数の開発者が、どう作るかだけではなく、何を作るかまでを顧客と一緒になって取り組むようにする」という姿です。
これは中長期的には、意欲のある人材が活躍できる環境になるでしょう。そして高スキルと高給与がセットになる世界です。このビジョンは超高速開発コミュニティが共有し、目指す世界と同じです。多くの関係者が「高スキルと高給与がセットになりにくい現状」を憂いており、それぞれのアプローチでこれを改善したいと考えています。
方法は多種多様でいいと思います。組み合わせもありでしょう。結果的に現場のエンジニアが「この仕事を選んで良かった」と胸を張れるような業界にしないといけません。
私自身、この業界に入って20年を超えました。できればあと10年で、業界の課題に自分なりの回答を出したい、と思っています。倉貫さんモデルの登場と広がりは、有望な可能性として、私も大いに注目しています。