「納品」をなくさなくてもうまくいく

倉貫さんから直接献本をしていただいきましたので感想がてらに。

本書はいわゆる“アジャイル”を清く正しく実践している実績と、その仕組みを丁寧に解説した本です。しかも、開発体制は「事業会社の内製化」ではなく「外部のソフトウェア開発企業を継続的に利用する」というスタイルであることに大きな意味があります。

（ソフトウェア開発企業という名称ですが、もはや「ソフトウェアだけを開発している」わけではないので、本来は「ITサービスを開発している」企業というような名称が最適なのですが、ここでは一般的な名称として使います）

これまでアジャイル開発方法論は「事業会社における保守運用フェーズの内製開発」に最適であるとされてきました。実際、多くのウェブ企業が社内にエンジニアを抱え、継続的な保守運用の中でイテレーティブに開発を行うスタイルを実践しています。

しかし、実際には世の中の大半の企業が“優秀なエンジニア”を雇える状況ではありません。優秀なエンジニアが少ないというより、そもそも「優秀なエンジニアを雇う」ことが簡単ではないのです。理由は「優秀なエンジニアは優秀なエンジニアによってのみ評価される」からです。日本の企業の多くは人事制度上もエンジニア向きではありません。もちろん、これから緩やかに変わっていく可能性はありますが、現段階では事業のプロフェッショナルとして能力がある企業は「いかに社外のエンジニアと協業するのか」と考えた方が効率的なのです。

一方、ソフトウェア開発企業としても、複数クライアントの案件を抱えることはITサービスの構成要素が複雑化するなかで社内にノウハウを蓄積できるという点において大きな意味があります。事業会社のIT部門では事業の安定性が最優先されるために新しい技術に取り組みにくい状況にあるのは言うまでもないでしょう。

もちろん、先進的な一部の事業会社では、新規技術も取り入れながら高いソフトウェア開発能力を維持しています。しかし、世の中は、そういう「一部の企業」だけで成り立っているわけでもありませんし、成り立つことは不可能です。

私としては「ソフトウェア開発に対して先進的でない企業」であっても、高い事業能力を保有している場合、一方で進んでいく世の中のIT化に対して、もっと“社外のITプロフェッショナル”として支援できることがあると信じています。

よって、事業のプロフェッショナルとITのプロフェッショナルが受託契約を通じて協業するモデルが求められていくべきで、本書は、そのための1つのモデルを示したものといえるでしょう。特にオフサイトでの完結を前提にしている点が特徴的だと感じました。

だが、しかし。本書に不満がないわけではありません。

「納品のない受託開発」はエンジニアを持た（て）ない事業会社にとって価値があるし、ソフトウェア開発企業にとっても事業継続性が高い点で優れたアイデアです。

しかし、開発規模が拡大できない。本書に書かれているとおりですが、小規模なスタートアップに最適なのです。もうちょっと大きな規模をこなせるようなモデルを作らないと日本の優れた事業会社の支援は難しいのではないかと考えています。

そして、開発規模を拡大しようとすると、この本に書かれていることにいくつかの事項には違和感を覚えます。

たとえば、

（要件定義とは）「事前に何を作るかをしっかり決めてく」（中略）それが顧客にとっての価値に直結しないことが一番の問題なのです。

とありますが。「決められてない未来を無理に決めることはない」と思いますが「決まられる未来については十分に決めた方が効率的」です。規模が大きくなると「決めないで進んでいく無駄」と「決めて作ってから修正していく無駄」の場合に、後者のほうが効率的になってきます。

我々の会社では「要件定義をしっかりやって8割完成させてから、残りの2割を調整していく」というスタイルを実践しています。こうすれば数百人月規模の案件でも対応することが出来ます。もちろん一括請負で契約をすることになります（ハイブリッドになることも多いですが）。

一方でエンジニアのあり方として、

私の言うプログラマーとは（中略）企画の段階から考えて、画面のデザインや仕組みの設計ができて、それを自らプログラミングし、クラウドでの運用まで、ソフトウェア・エンジニアリングに関わるすべての工程をこなせる人のことを指しています

というのは共感しつつも、規模が増えると「一人で全部」というのが難しくなってきて、チームマネジメントや顧客折衝が重要になります。エンジニアリングにおいて実際に手が動くことは間違いなく重要ですが、それだけではない能力を高めることはエンジニアの成長として認められていいはずです。

これは「プログラマは35歳を過ぎたらプロジェクトマネージャーになれ」などというレベルの低い話ではないです。上記のプログラマーの定義を前提としつつ、クライアントの事業理解、全体アーキテクチャ設計、顧客との合意形成、スケジューリングやリソース調達、チームマネジメントといった能力を身につける必要があるでしょう。

実際に出来るのか？という疑問な方は、今度の夏サミ 2014で弊社のクライアントである（株）東京商工リサーチ（以下、TSR）様と「創業122年の企業と顧客価値にコミットした開発を実現する試みと成果について」という講演をするので聞きに来てください。企業情報提供サービスと言えば（株）帝国データバンクが業界1位ですが、創業は業界2位のTSRの方が早いです。日本のレガシーな企業と数百人月の開発をする際に、いかにアジャイルを実現しようとしてきたのか、という話をします。なお講演はアトラシアンの提供です。

要するに、納品をしないとか一括請負契約をしないといったことはどうでもよくて、顧客と信頼関係を築き、優秀なエンジニアが真のパートナーになることが重要なのです。言い換えれば、事業会社とソフトウエア開発企業という両者のビジネス持続性において最も効率的で無駄のない方法を構築するのです。

こういう前提無しに「常識」と言う言葉で「一括請負はディフェンシブ」とくくり、「納品のない受託開発こそがオフェンシブ」とすることに苦言を呈したいと思います。オフェンシブにするために一括請負をやったっていいんですよ。

というわけで、本書については「目的には大賛成だけど、限界がある方法」というのが率直な感想です。もちろん、参考になった手法もありますが。

ただ、ここで立ち止まる倉貫さんでもないでしょう。おそらく、本書が出たことでクライアント数は一気に増えるし、面白い案件も転がり込んでくるはずです。そうなって開発規模を拡大しなくてはいけなくなったとき果たしてどうするのか。倉貫さんにはもっと進化したソフトウェア開発企業の経営に取り組んでもらいたいと思いました。