自社サービスの開発をしている僕が "「納品」をなくせばうまくいく" を読んだけど、とてもおもしろかったという話

ずっと積ん読されてた "「納品」をなくせばうまくいく" を、ようやく読んだ。株式会社ソニックガーデンの社長である倉貫義人さんの本。

読む前は、正直、「自分たちのビジネスモデルを顧客に手っ取り早く啓蒙するための本、ってところなんじゃないかなー」というひどい思い込みがあったし、僕がこれを買ったのもこの本の kindle 版が何かのセールだったのを見つけたから、なんだけど、読み終わった今、食わず嫌いせずに読んで良かった、セールでもなんでも、買う気になって良かった、と、心底思っている。

目次は↓なかんじなんだけど、

はじめに
1章　常識をくつがえす「納品のない受託開発」とは
2章　時代が「納品のない受託開発」を求めている
3章　顧客から見た「納品のない受託開発」の進め方
4章　事例に見る「納品のない受託開発」
5章　「納品のない受託開発」を支える技術とマネジメント
6章　エンジニアがナレッジワーカーになる日
7章　「納品のない受託開発」をオープン化する
おわりに

流れとしては、

既存の受託開発の・一括請負スタイルの開発の問題点を紹介
"納品" がその諸問題の根源になってしまっていることの解説
ソニックガーデンが推し進めている「納品のない受託開発」の進め方を、"顧客視点で" 紹介
そして、実際の顧客の声も紹介（2社）
「納品のない受託開発」を、今度は内部視点での紹介・解説
今後のソニックガーデンの・「納品のない受託開発」の展望
そして、今後のエンジニアに求められるもの・生き方の解のひとつについて

...というかんじで、話は進んでいく。だいぶざっくり書いちゃってるけど。

その開発の仕方は何のためのものなのか？

読み始めてまず、僕は、 ソニックガーデンが推し進めている「納品のない受託開発」の進め方を、「顧客視点で」紹介 のところでだいぶ衝撃を受けた。それが自分にとって目新しいものだったから、とか、別にそういう理由ではなく。

僕は、自分自身のことを、たぶん少なめに見積もっても、 アジャイル開発（特に、スクラム）に傾倒している 、と言っていい状態だと思っている。スクラム開発のエッセンスがパワーを発揮する場面は開発の現場においてたくさんあると信じているし、今自分がいる会社（BtoB の自社サービス開発をしています）、チームでも、実際に、スクラム開発から多くの事柄を参考にして開発を進めている。日々の開発に活用できそうなヒントはきっとスクラムにある、と、日々考えたりしてるし、どうやったらうまく取り入れられるか、といったことも、あれやこれやと考えてみたりもしている。なかなかうまくいかないけどね。

でも、この本の前半部分では、 スクラム どころか、 アジャイル という言葉すら出てこない。出てこないのに、そこで紹介されているのは紛れも無く アジャイル開発 であり スクラム開発 で、顧客も含めて、立派な スクラムチーム が形成されているように見えた。

「納品のない受託開発」では、「ビジネスの成長」を望む顧客に対して、ソフトウェアのエンジニアリングの全てを担当するというサービスを提供します。−− 倉貫義人・著　「納品」をなくせばうまくいく　より引用

「納品のない受託開発」では、仕様変更や優先順位の変更はいつだってウェルカムです。（中略）優先順位をいつでも変えられる代わりに、手に入るタイミングも随時変わるということです。−− 倉貫義人・著　「納品」をなくせばうまくいく　より引用

実際に開発に入る前に、また、どんなソフトウェアを作るのかという話をする前に、そもそもなぜそのソフトウェアが必要なのか、その事業で実現したいこと、そのために妨げになっている課題は何か、という点について話し合います。−− 倉貫義人・著　「納品」をなくせばうまくいく　より引用

最初は３ヶ月以内にユーザーに対して公開できる最小限の機能と画面の設計を行います。そこで最初に公開する内容が決まったところで、毎週の開発に入ります。顧客とエンジニアとの打ち合わせは毎週行い、その打ち合せで前週１週間分の成果と次の１週間で開発すべきことを確認します。（中略）毎週の打ち合わせは、単なる進捗報告だけの場ではなく、実際に毎週プログラムを作って、でき上がった画面を見ながら操作性や機能面の確認をしています。−− 倉貫義人・著　「納品」をなくせばうまくいく　より引用

ソフトウェアをユーザーに公開する前も公開した後も、変わらずこのサイクルを繰り返していきます。ビジネスプランも３か月程度ごとに見直しを行って、これを繰り返します。この大小の繰り返しがずっと続いていくのが「納品のない受託開発」なのです。−− 倉貫義人・著　「納品」をなくせばうまくいく　より引用

このように紹介されているのは「アジャイルというステキな開発の仕方があるので、私達もアジャイル開発します」というようなことは微塵も感じさせるものではなくて......、、その開発スタイルに主眼が置かれているのではなくて、あくまで「顧客にとっての価値を効率よく最大化する」というプロセスの過程の一部としてこの開発の仕方がある（と、顧客側もそう思える、はず）ので、非常に無理なく・自然に受け止められる。

私たちの会社で働くエンジニアたちは、自分たちがアジャイル開発を実践しているという意識はまったくありません。今のビジネスの中で開発と運用をうまく回そうとすれば、自然と「アジャイルな」姿勢になっているのです。−− 倉貫義人・著　「納品」をなくせばうまくいく　より引用

自社サービスの開発をしてる、僕らは？

衝撃のあとに感じたのは、嫉妬みたいなきもち。

プロデューサーもディレクターも同じ会社・フロアにいて、自社のサービスを開発している僕らよりも（つまり、受託開発の会社よりも色んな面で "やりやすい" 環境なはずの、僕らよりも）、この本の中に書かれている "チーム" は、よっぽど "チーム" になっている気がしたし、僕らに負けず劣らず、いろんな人を幸せにしてそうに思えたから（決して「僕らよりも上手にアジャイル開発・スクラム開発できてる！」という妬みではないｗ）。

ここで一言断っておくと、別に僕は、今の僕の現場の悪口を言いたいわけではないｗ。むしろ、僕が今いる現場には本当に多くの素晴らしいエンジニアがいるし、世の中の課題を解決するために一緒に取り組んでいる仲間がいる。と思っている。でも人間、現状に満足してしまったら終わりなのとの同じで、課題はやっぱりいくらでもあるし、何よりもっともっと、良い状態になりたい。これはきっとソニックガーデンの実状（本を読むだけでは見えてこないもの）においてもきっとあることで、それが見えていないからこそ、"隣の芝生は青い" ように感じているのだろうし、自分のチームの解決策のヒントこそここにある！というように思えてしまうんだろう。

んで。

後ろの方の章での 「納品のない受託開発」を、今度は内部視点での紹介・解説 のところで、ようやく アジャイル という言葉が出てくるんだけど、「自分たちの開発スタイルはアジャイル開発から多くのエッセンスをもらってるんですよ」、というこのメッセージは、この本の意味合いを考えると確かにここらへんの位置（5章）での発するのがベストだと思うし、そうした倉貫さんの気持ちもわかる気がする。とか言っちゃって。

「自社サービス開発」という名の受託開発になってしまっていないか？

僕も、新卒入社した会社ではいわゆる一括請負での開発を仕事にしていた。そんな僕が「な〜んか、受託開発よりも自社サービス開発がいいよなぁ」などとおぼろげながらに感じていたその理由が、下記引用のように単純かつ明快に、記されている。

一括請負で契約している開発会社にとっては「納品すること」がゴールなので、極端なことを言えば、納品後にそのソフトウェアが使えるものであろうがなかろうが知ったことではありません。−− 倉貫義人・著　「納品」をなくせばうまくいく　より引用

要件定義はいわば「未来に対する予測」です。（中略）そもそも、要件定義は本当に顧客にとって必要なことなのでしょうか。顧客が実現したいのは、そのソフトウェアを使ってビジネスで成果を上げることです。（中略）たとえ要件定義をしてその通りにソフトウェアを作り上げたとしても、それだけではまだ価値は生まれていないのです。−− 倉貫義人・著　「納品」をなくせばうまくいく　より引用

それでも要件定義をしっかりやろうというのは、どちらかといえば、開発会社の都合によるところが大きいのでしょう。「ソフトウェアを作ってお金を頂く」というビジネスモデルを採用している限り、「事前に何を作るかをしっかり決めておく」と考えるのは自然なことです。ただし、それが顧客にとっての価値に直結しないことが一番の問題なのです。−− 倉貫義人・著　「納品」をなくせばうまくいく　より引用

「一括請負」での受託開発における顧客にとってのメリットは、要件定義さえできれば予算が確定でき、その予算範囲内で少なくともソフトウェアそのものは、ほぼ確実に手に入れることができる、ということでしょう。つまり、ソフトウェアの「完成リスク」を開発会社が引き受けてくれることが最大のメリットになります。−− 倉貫義人・著　「納品」をなくせばうまくいく　より引用

ただこれは、受託開発ビジネスにおけるリスクだったり困難なことだったり、についての話。そのリスクや困難だったりが、僕が受託開発から遠ざける理由にもなっているかもね、という話だ。

一個人としてシステム開発に向き合う、となったときに、従来までの受託開発となにがどう違うのか、というと、僕は、「これから解決しようとしている課題を、自分ごとのように捉えられるかどうか」だと思う。

繰り返しの開発段階に入る前の打合せは、顧客によっては一度で終わることもあれば、短くて数回から、長ければ数ヶ月に及ぶケースもあります。（中略）この期間に、顧客の事業にかける思いや、解決したい課題、そして実現したい世界について話し合うことで、顧問として担当するエンジニアにとっても、顧客の事業を「自分ごと」として理解できるようになります。顧客と私たちが一つのチームになるためのチームビルディングの時間でもあるのです。−− 倉貫義人・著　「納品」をなくせばうまくいく　より引用

そう、僕が自社サービス開発をしたかったのは、何よりも、ある課題を自分事のように捉えたい・自分の課題となったそれを一緒に解決したいから、なんだ。自社サービスの開発をすること、イコール、そういうことだよね、と思っていたから。そしてそれは、既存の受託開発スタイルでは叶いにくい（と思っていた）からだ。

自社サービス開発よりも受託開発に良いイメージが持てないことがおおいのは、その開発を自分ごとにできない・できてないから、なのかな
— いのうえ (@a_know) 2015, 3月 17

でもこうなってくると、"受託開発" "自社サービス開発" なんて分類すらも、ばかばかしく、意味をなさないものに思えてくる。「納品のない受託開発」は、受託開発を自社サービス開発に変える処方箋だ。開発の対象が自社サービスかどうか、が問題の本質なんじゃない。

「納品をなくせばうまくいく」読んでる。まだ読み始めたばっかだけど、この考え方でいくと、受託開発という形式ではあっても、その実、自社サービスを開発してるのと変わらないメンタリティになれそうな気がするな。
— いのうえ (@a_know) 2015, 3月 15

僕たちは、自社サービス開発の仕事だからといって、自分たちの開発スタイル、自分たちが作ろうとしているものをどう作ろうとするのか、それを継続的にどう良くしていこうとするのかというところを常に考えるということを怠ってはいないだろうか？ "僕たち" ってのは、エンジニアだけじゃない、全員だ。よいプロダクトは、エンジニアだけでは生み出せない。

おわりに

...結構な量の引用をしてしまった...orz。でも、これらは本のごくごく一部で、原著にはもっと多くの金言が散りばめられている。自社サービス開発の現場にいる人こそ、深く考慮せず受託開発を忌避してしまっている人にこそ、読んで欲しい一冊だと思う。

システム開発で良いものを作ろうとすると場合の良いやり方の一つにこういうのがあると思いませんか、っていうのを、非エンジニアに理解してもらうのにも、良いかもしれない。冒頭で "自分たちのビジネスモデルを顧客に手っ取り早く啓蒙するための本" なんて書いたけど、他でもない、システムを生み出す僕らこそ読んだほうがいい本だ、と思った。