セカイノカタチ

世界のカタチを探求するブログ。関数型言語に興味があり、HaskellやScalaを勉強中。最近はカメラの話題も多め

マーブルワーズ

「納品」をなくしてもうまくいかない(読書感想文『「納品」をなくせばうまくいく』)

「納品」をなくせばうまくいく ソフトウェア業界の“常識

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

たまに発生する読書感想文です。

今回は、「ザ・山の民」といった感じの本書について、感想を垂れたいと思います。

どんな本か

2014年6月20日に初版発行された本で、発行当初、割りと話題になっていたような記憶があります。

システム受託開発の肝要とも言える「納品」をなくすという大胆なコンセプトで山の民*1からの注目を集めました。

似たようなコンセプトの商品に永和システムマネジメントさんの価値創造契約があります。

こちらは、奇しくも本書が発売された3ヶ月後に3年ほどの取り組みがうまく行かなかったことを発表しています。→俺の価値創造契約

上記の発表を読んだ時にも同じように、感想記事を書きました。

「価値創造契約」と企業のシステム開発を覆う暗黒ロジック - セカイノカタチ::Techlog

感想

ソニックガーデンさんの場合、ギブアップしていないので、「失敗した」とは書きにくいですが「納品のない受託開発」で検索した感じでは、失敗とまでは言わなくても大きく成功しているとも言い切れなさそうな感じですね。

営業力さえあれば、スモールビジネスとしては、継続可能だと思いますが、日本のSI業界に風穴を開ける存在になることは、難しいでしょう。

納品をなくすことで解決するのか?

「納品」が本質的な問題を引き起こしているという意見には賛成できません。

そもそも、本書で書かれている方法は、「発注→納品」のサイクルを短くするというアジャイル的な手法であって、「納品」自体がなくなっているわけではないです。

エンジニア「このIssueは2週間かかります」
顧客「その根拠は?」
エンジニア「・・・」

2週間後

エンジニア「2週間では出来なかったです」
顧客「チケット払ってるんだ寝ずにやれ」
エンジニア「・・・」

端的に表すと、このような会話になると思います。

システム開発というのは、どのような粒度で見ても、本質的には投機的です。

誰も、開発コストの根拠も示せないし、正確な見積もりなんてできません。

「作ってみなければわからない」のです。

受託開発から「納品」を無くすことで、受発注間の責任分担はなくなるかもしれませんが、エンジニア個人の責任は取り払うことができません。

「納品のない受託開発」は、あくまでシステム開発会社社長の視点から見たブレイクスルーでしかありません。

システム開発のコスト(期間)やリスク(失敗・延長の可能性)は、担当エンジニアであっても、発注者であっても利用者であっても、事前に正確に見積もることはできません。

ある程度の見積もりはできても、最終的なリスクは残ります。

そして、このリスクは発注側(の経営者)が負うべき問題なのです。

その急所をケアできなければ、受託開発の根本的な問題を解決することはできないでしょう。

萎縮してバッファを取り、技術的な挑戦に臆病になり、技術力が落ち、更に萎縮していくというSIの抱える本質的な悪循環をエンジニア単位に分解しただけです。

理想的な関係

システム開発は、投機的です。

なぜなら、マニュアル化がほぼ不可能な、ナレッジワークであり、メタワークだからです。

常に失敗する可能性、長期化する可能性、その他色々なリスクがつきまとってきます。

このリスクは、受託側が受け持つ性質のものではないです。

エンジニアが見積もり、経営者が責任を取るという関係が理想といえます。

大企業には稟議の存在

言うは易しですが、実際行うにはハードルがあります。

普通の会社では、失敗を前提とした費用なんて払えませんし、1円でも払うのであれば、稟議が必要になります(1円で稟議は言いすぎですけど)。

これは、俺の価値創造契約にも書かれていますが、その通りだと思います。

本書にも書かれていますが、それらのハードルを超えるには、直接経営者が判断を下しやすい、ベンチャー体質の会社やスタートアップ企業を相手にすることになると思います。

ベンチャーには2つの根本的な問題

そして、ベンチャーやスタートアップのビジネスは、一つにはお金がなく、もう一つには、ほぼ失敗するという問題を孕みます。

数多のスタートアップの中からユニコーンを見つけ出す必要があります。

つまり、顧客を捕まえることが非常に難しいビジネススタイルだといえます。

そのため、営業力のある会社であれば、スモールビジネスとして存続可能かもしれませんが、大規模にSI業界をひっくり返すことはほぼ不可能という結論になります。

エンジニア派遣との競合

発注側としては、いつでも取り出せるエンジニア力と言うのは魅力的です。

しかし、それであればエンジニア派遣で事足りるわけで、わざわざリスクを犯す「納品のない受託開発」を選択するメリットが見えにくいです。

もちろん、この業界に十年以上どっぷりと漬かっている自分のような人間には、メリットがありありと見て取れますが、あまりに直感に反する説明になるために、他業界の素人を短期間で説得できる自身はありません(そのため「営業力」と言っています。多少強引にでも売り切ってしまう営業と言うのは極少数存在しますので)。

雇用上の競争力

自由なエンジニアライフを標榜して、良いエンジニアを雇用するというのは作戦としてありだと思います。

しかし、SIという事業形態が不人気であり、ソーシャルやサービス提供会社が直接エンジニアを雇用するケースと比べて、強い訴求力があるようにも見えないです。

賃金に関しても、サービス自体を「割安」で提供しているみたいですが、どう考えても「割高」にしないと採算が取れそうにありません。

そうすると、雇用者に対する支払いも「割安」にならざるを得ない計算になるのですが。。。

まとめると

最終的に、急所を外している感じですが、個々の分析や方策、解決方法については、その通りだと思います。

僕自身は、本質的にSIをひっくり返すようなビジネスモデルの登場を心待ちにしている山の民の一人です。

自分でも、細々とでありますが、取り組んでいるプロジェクトがあります。

血を吐いても再び飛ぶ鳥のように繰り返し繰り返し挑戦し、約束の大地にたどり着くところをいつの日かご覧に入れたいと思います。

*1:主にビジネス用途向けのシステムを受託開発することを生業とするSIerとそのピラミッドに組み入れられた子請け孫請けひ孫受けなどの中小SIerとそこに属するシステムエンジニアやプログラマーを自分は「山の民」と呼んでいます