「納品をなくせばうまくいく」の感想part1～ソフトウェア業界のビジネスモデルが抱える問題

「「納品」をなくせばうまくいく ソフトウェア業界の常識を変えるビジネスモデル」を購入してさっそく読んでいる。
感想を書く前にメモ。

【参考】
Twitter / akipii: ビジネスモデルの劣化コピーは誰も幸せにしない指摘 RT @kuranuki: 岡島さんもブログ書いてくれました。ありがとうございます！ link:書評。『「納品」をなくせばうまくいく』を読んで身を引き締める - Happymanブログ http://happyman.hatenablog.jp/entry/2014/06/20/002521

Twitter / akipii:ビジネスモデルの因果ループ図で説明できるはず RT @yasuohosotani: はてなブログに投稿しました 「納品をなくせばうまくいく」を読みました - Yasuo's Notebook http://htn.to/wGcxpe

Twitter / akipii: 発注側の観点が良く分かる RT @_eurk: はてなブログに投稿しました 『「納品」をなくせばうまくいく』というパラダイム - ヘウレーカを廻って http://htn.to/3jYcDg

Twitter / akipii: 同感。縦書きの本なのに脚注が1ページごとにあって読みやすい。 RT @mitsugeek: 「納品」をなくせばうまくいく ~ ソフトウェア業界の"常識"を変えるビジネスモデル - developer's diary http://htn.to/LKcaKb

Twitter / akipii: 凄く良い記事。 RT @mat_aki: ソニックガーデン本（『「納品」をなくせばうまくいく』）は想像以上に熱い本だった - この国では犬がコードを書いています http://enk.hatenablog.com/entry/2014/06/15/153731

【1】IT業界で働き続けてきて、この業界のビジネスモデル「請負契約と準委任契約」にずっと違和感を持ち続けてきた。

【2】普通のSIの開発案件は、一括請負契約が普通。
最初の要件定義で、開発スコープと中身を確定してから請負契約を結び、設計→開発→テストに進んでいく。
一括請負契約は、悪名高いWF型開発とセットで実施するのが普通。

最初に全ての仕様を凍結できなければ、せっかくの見積りが狂い、実行予算や要員表のやり直しが発生する。
それは利益が下がることを意味する。
だから、一度決めた要件や仕様のスコープを拡大解釈させないように、SIは契約という名で縛ろうとする。
顧客も、仕様が確定する前に、要求をどんどん詰め込もうとし、最初の契約を守らせようとする。

【2－1】また、WF型開発では、工程ごとに開発要員の変動が大きいリスクが発生しやすい。
つまり、要件定義や設計などの上流工程では少数精鋭のメンバーで作業するが、その後の開発とテストという下流工程では、大量の開発者を動員して短期間にシステムを作り上げるやり方が多い。

すると、元請けは顧客から請負契約で受注するものの、上流工程は自分たちで設計書を作って、その後の下流工程は下請けやオフショアに流すように持っていく。
その理由は、開発要員の変動が大きいので、そのリスクを下請けに押し付けたいからだ。

つまり、短期間の開発は下請けのSIへ一括請負契約で任せて、開発の原価を自社の開発者の人件費という固定費ではなく、変動費化させようとする。
下流工程で開発工数が自社が抱える要員よりも多くなるのなら、不足した工数は下請けへのスポット対応でカバーさせたい思惑がある。

【2－2】多段階の請負契約は、元請けも下請けも双方ともに不幸な組合せだ。

下請けは、システムの実現可能性や非機能要件の検討もできていない設計書を渡されて、その責任を押し付けられて、開発せざるを得ない。
元請けも、下請けから、納期までにとにかく間に合わせただけのプログラムを納品されて、その検収作業で、ひたすらバグ潰しに追われる。
本番リリースできる品質にまで、システムを持っていくのが元請けも下請けも大変なのだ。

元請けも下請けも、「システムを本番稼動させる」ことだけに注力するから、システムがユーザの業務で長く使われるように運用するまで考慮する余裕は実際はない。
新規顧客のシステム開発ならば、なおさら、納品するだけで精一杯だ。
正直、顧客の業務のあるべき姿をシステムに反映させる所へ持っていくのは至難の業だ。

このような多段階の工程で分断された請負契約の悪しき風習は、昔から今まで、その不合理性をずっと言われ続けている。

【3】かと言って、準委任契約の開発案件が、顧客にもSIにも良い契約とは限らない。
準委任契約では、SIが役務の提供をするだけであり、検収物件が仮にあっても、実際は作業報告書だけで済まされる。

SIには、成果物の完成責任はないから、限られた期間に決められた工数だけ提供すれば、売上がもらえる。
顧客から見れば、要求した検収物件をもっとブラッシュアップして欲しいのに、準委任契約ではそこまで要求できない。

また、SIが下請けに下流工程を準委任契約している場合、成果物の完成責任はないから、事実上の派遣社員の作業と同じ品質ぐらいしか要求できない。
下請けの開発者も、準委任契約なら、残業するほど割増請求できるから、少ない工数で効率の良い作業を実施して品質を高めようとするインセンティブも働きにくい。

この症状は、松原友夫さんが以前書いた記事ですでに指摘されている。

真髄を語る - 日本のソフトウエア産業、衰退の真因：ITpro

【4】従来のSIのビジネスモデルである「請負契約と準委任契約」が本来の姿ではない原因は、顧客も元請けSIも下請けSIも、インセンティブが働かない仕組みにあることだと思う。

【4－1】SIでは、受注した開発案件は時期によって変動があるから、自社で抱えている開発者でまかなえればいいが、仕事がない場合は、人件費を支払うだけで赤字になる。
SIもサービス業なので、小売業の販売員や散髪屋の従業員のように、社員の稼働率が高いほど売上が高くなる。

だから、SIの管理職は、自分の部の社員が暇で遊んでいないように、常に受注した開発案件にアサインした状態にしておきたい。
すると、能力の高い開発者ほど、複数の案件を掛け持ちするようになり、常に忙しくなる。
SEやPGの稼働率で売上が決まるビジネスモデルは、能力のある開発者ほど疲弊させる。

【4－2】そして、受注した案件が自社の開発要員の工数よりも大きくなると、生産性の高い開発チームから人を引きぬかれてしまう。
他の案件でデスマーチで忙しい案件に、君のチームは暇そうだから、ちょっと手伝ってやってくれ、と言われて、チームからメンバーを減らされるのだ。
開発チームの生産性を上げても、逆に必ずデスマーチに巻き込まれてしまう。

だから、日本のSIでは生産性を上げても、はかどっていないような仕事ぶりをする。

つまり、開発者や開発チームが生産性を上げても、デスマーチに巻き込まれるリスクの方が大きいから、生産性を上げようとするインセンティブが働きにくい。

【5】顧客も開発者もSIも、より良くしていこうというインセンティブが働かない「請負契約と準委任契約」というビジネスモデルはおかしい、とつくづく思ってきた。
だから、アジャイル開発にはずっと興味を持ち続けてきたし、アジャイル開発のビジネスモデルは何か、ということにも興味がある。

「「納品」をなくせばうまくいく ソフトウェア業界の常識を変えるビジネスモデル」を注意深く読んでみると、顧客もSIも開発者も、品質の高いシステムを作ろうとするインセンティブが働くような仕組みが整っているように思える。

「納品のない受託開発」のビジネスモデルが絶対正しいとは思わないけど「ソフトウェア開発のビジネスモデルのあるべき姿」を提示しようとする点がすごく良いと思う。
この辺りを分析したいと思う。

【追記】
他のBlogで参考にされたようなのでメモ。
発注者の観点で、従来のソフトウェア開発のビジネスモデルの問題点を上げているのがとても参考になる。

Twitter / kuranuki: 斬新すぎる。 RT @shibu_jp: 読書してない感想文書いた: 「納品をなくせばうまくいく」を読んでません http://blog.shibu.jp/article/100415587.html