こんにちは。
株式会社フルーデンスの小巻です。

今回は、タイトルの通り、ソニックガーデンさんの有名な本『「納品」をなくせばうまくいく』を読んだので、感じたことや考えたことを書きたいと思います。

少し長いですが、以下のようなことがきっかけで、この本と出会いました。

ーーーーーーーーーー

今まで、様々なプロジェクトでFileMakerの開発をしてきましたが、以下のような困るケースに出会うことがありました。

• 仕様が分からない状態にも関わらず、お客様から見積りを求められる。
• 要望を確認し、要件定義をし、開発を進めていると、途中で新しい担当者がプロジェクトに参加することになり、そのことがきっかけで仕様が変更される。
• 要件定義をし、ドキュメントやモックを作り、お客様と開発者で同意ができており、開発を進めていたが、途中で動くソフトウェアのデモをすると、認識が間違っていたことに気づき、仕様が変更される。

上記のようなケースは一例ですが、想定通りに、スムーズに進むことの方が珍しいと思います。
プロジェクトの途中で仕様変更は必ず発生するものですが、タイミングによっては、

• 再見積りをして、費用や納期など、対応方法を検討する。
• 限られた予算の中で、機能の削減や優先順位を検討する。

などの調整をすることになります。

また、納期が迫っている状態で、仕様変更などが発生する場合、より良い実装方法に変更する時間や、設計について考える時間が十分に取れずに実装することも起こるかもしれません。

開発会社としては、本来あるべき姿ではないことは分かってはいるものの、納品をしなければ売り上げになりませんので、何かを犠牲にすることもあると思います。

一括請負の受託開発への疑問

今までの一括請負の受託開発は、お客様にとって本当に良いことなのだろうか？と長いこと疑問に感じていました。

一括請負の受託開発で感じた様々な課題は、どのようにすれば解決できるのだろうか？と考えた結果、私は「見積り」の伝え方や対応方法を見直すことで解消できるのではないか？と仮説を立ててみました。

というのも、課題の原因は、費用部分にあると考えたためです。

では、具体的に「見積り」の伝え方や対応方法を、どのようにすれば良いのか考えました。

• 仕様が分からない状態では、見積りは提出しない。
• 仮に提出するにしても「不確実性のコーン」を考慮し、プロジェクトの初期の見積りでは金額や納期に大きな幅(16倍の差)があることを伝える。
• 精度の高い見積りを提出するためには、時間もコストもかかることを伝える。
• 仕様変更があることを前提にし、最低でもN回は、再見積りを提出することを伝える。
• 見積りの幅が大きい場合、金額や納期など、計算して提出する。

※上記の内容は「ソフトウェア見積り　人月の暗黙知を解き明かす」という本に詳細に記載されています。
「ソフトウェア見積り　人月の暗黙知を解き明かす」を読んで考えたことは、別途書きたいと思います。

また、以下の「不確実性のコーン」のグラフを見ても分かるように、プロジェクトの初期に作られた見積りは、見積りが多い方から少ない方までの全範囲を通して見ると、16倍もの差があります。

引用：「ソフトウェア見積り　人月の暗黙知を解き明かす」図4-1

実際のプロジェクトのカレンダー時間を基準にコーンを引き直すと、以下のグラフになります。

引用：「ソフトウェア見積り　人月の暗黙知を解き明かす」図4-2

参考：プロジェクトの本質とはなにか | 日経クロステック（xTECH）

上記の内容を、お客様に納得してもらえれば、一括請負の課題はある程度解消できるはずです。
しかし、お客様の視点で考えると、以下のように感じるかもしれません。

• できる限り精度の高い見積りを出してもらいたいが、見積りに対して、そこまで費用をかけることができない。
• 見積りのブレ幅が大きすぎると、見積りの意味があまりないので、社内で調整できない。
• 不確実性のコーンの中盤(ユーザーインターフェイス設計の完了)まで行かなければ、見積りは分からないということなのか？

矛盾するようですが、「見積り」の伝え方や対応方法を見直したとしても、お客様に納得してもらうのは、難しいと思います。

今のところ、良い解決策は見出せていません。

プロジェクトへの参加と内製化で感動

話は変わりますが、昨年、とあるプロジクトに参加させて頂く機会がありました。

そのプロジェクトは、一括請負契約ではなく、準委任契約でした。
規模感もあり、難易度の高いプロジェクトだったと思います。

難易度は高いものの、以下のように理想的な形でプロジェクトが進みました。

• 開発者は、お客様の要望を確認しながら、実際に動くソフトウェアの開発を進める。
• お客様は、実際に動くソフトウェアを操作し、開発者にフィードバックをする。
• プロジェクトメンバーは、チケットを共有し、チケット内容の確認や優先順位を一緒に調整する。
• 開発者は、チケットに開発のログや経緯を記録しながら開発を進める。
• 定例ミーティングでは、進捗の確認、チケットの共有、チケットの棚卸、などを一緒に調整する。

上記のように開発を進めることで、内製化を検討されている場合は、以下のようなメリットがあります。

• 一通りの機能を開発し終えた後に、内製化する際に、チケットのログを見ることで、実装の背景や履歴がわかる。
• 開発者の作業手順や作業記録が見れるため、内製化する際に、どのように開発をすれば良いのかが具体的にわかる。
• 簡単なチケットをお客様自身に対応してもらうことで、開発環境でのペアプログラミングができる。
• インハウス開発者の方は、開発の難しさや、開発の勘所が理解できる。

また、内製化を進めるということでしたので、以下の内容についても、ペアプログラミングをしながらインハウス開発者の方々に共有しました。

• 環境の構築方法
• 開発方法や運用方法
• 開発ルール
• 命名規則
• 分離モデル
• PSOSの使い所
• API連携
• 保守性の高い実装方法
• などなど…
• 開発環境から商用環境へのリリース方法
• 差分の確認方法
• 各種ツールの使い方
• リリースシナリオ
• リハーサル
• リリース

内製化の環境作りがしっかりできれば、インハウス開発者の方々でも上記のようなしっかりとした運用ができることが分かり、大変感動しました。

このプロジェクトの成功は、
プロジェクトリーダーの方が経験豊富で、大変素晴らしい方だったことはもちろんのこと、お客様など関わる方が本当に協力して下さった点が成功の要因だと思います。

そのため、契約内容を「一括請負契約」から「準委任契約」にするから、プロジェクトが上手くいく、という簡単な話ではありません。

しかし、このプロジェクトが「一括請負契約」で要件定義をして開発を進めていたら、同じように成功していたかどうかは、なんとも言えないところです。

さらに、上記のような、レベルの高い内製化が実現できたかどうかも分かりませんが、おそらく難しかったのではないかと思います。

ーーーーー

話を戻しまして…

日頃から、さまざまなジャンルの本を探して読んでいるのですが、
「一括請負契約」の課題や「準委任契約」についての本を探していた際に、この本に出会いました。

「納品」をなくせばうまくいく

有名なソニックガーデンさんの本なので、概要はソニックガーデンさんのWebサイトをご確認ください。

「一括請負契約」や「ソフトウェア開発の費用対効果」に疑問を感じている方は、是非とも読んでみてください。

納品のない受託開発を詳しく知る – SonicGarden 株式会社ソニックガーデン

印象的な部分

ここからは印象的な部分を簡単に抜粋します。

一括請負というビジネスモデル

発注者の視点

• 要件定義さえできれば、予算が確保でき、その予算範囲内で少なくともソフトウェアそのものは、ほぼ確実に手に入れることができる。
• 完成リスクを開発会社が引き受けてくれる。
• 納品時に要件が変化している可能性がある。
• ソフトウェアは、使い始めることで初めて価値が生まれる。
• 本来であれば、少しでも早いうちに、業務に取り入れて使うべき。

開発者の視点

• 納品することがゴールになる。
• 納品後に使えるものであろうがなかろうが、知ったことではない。
• 要件定義は難しい。
• 本来は、積極的に改良をし、現場の反応を見て臨機応変に改善すべき。

本にある通り「要件定義さえできれば」と言うことは簡単ですが、実際は、要件定義は簡単には終わらないですし、十分に考慮し、要件定義に漏れのないように慎重に進める必要があります。

また、十分に要件定義に時間を割いたとしても、コーディングする(不確実性を具体的にしていく)過程で、気づくことも多く、考慮が足らない部分は必ず発生します。

以下の引用部分の数字を見て頂ければ、いかに難しいかが伝わると思います。

「ソフトウェア見積り　人月の暗黙知を解き明かす」
3.2 ソフトウェア業界における見積りの実績

ソフトウェア業界の見積もりの実績を見ると、ソフトウェア見積もりの問題の本質にいくつかの興味深い手がかりが得られる。
このところ、Standishグループは「カオスレポート」と呼ばれる2年ごとの調査を発行している。
これは、ソフトウェアプロジェクトの実績を記述したものだ。

2004年のレポートによると、プロジェクトの54%が遅れ、18%が完全に失敗し、当初の予定期間と予算内で開発されたのは28%とされている。
図3-2に、1994年から2004年の10年間の結果を示す。
Standishグループのデータで注目すべきなのは、「早く終わったプロジェクト」については、そのカテゴリさえないということだ。
起こり得る最良の実績は、期待に沿うこと(予定どおり/予算どおり)なのだ。その他の実績は、全てそこからの下り坂だけだ。

Capers Jonesは、プロジェクトの実績に別の考えを示した。
彼は、「プロジェクトの成功はプロジェクトの規模によって決まる」と長年言っている。
つまり、大規模なプロジェクトは小規模なプロジェクトよりも困難が伴うということだ。
この点は、表3-1を見ると明らかにわかる。

Jonesのデータからわかるように、プロジェクトの規模が大きいほど、予定どおりに完成する可能性は低くなり、完全に失敗する可能性が高くなる。

全体として見ると、極めて多くの調査結果が、StandishグループやJonesの報告と一致していることを認めざるを得ない。

つまり、予定通りに開発されたのは全プロジェクトの約4分の1であり、役4分の1はキャンセルされ、役半分は遅れるか予算を超過するか、あるいはその両方となっている。

開発者は「納品することがゴール」という感覚はゼロではありませんが、私自身や、周りのClaris Parnerを見ていて、ほとんどのケースでは納品後もお客様のサポートをしますし「納品して終わり」と考えている開発者はゼロだと思います。

発注者のビジネスの課題を解決することを第一優先に考えれば、少しでも早いうちに、実際に使ってもらえるような環境や動くソフトウェアを作る方が良いという点は、全く同じ意見です。

納品をしない受託開発について

• 本当に柔軟に無駄なく良いソフトウェアを作りたければ、エンジニアを雇用して内製するのが一番良い。
• しかし、優秀なエンジニアを採用するのは難しい。
• 顧問弁護士や顧問税理士のような概念に近いサービス。
• 実績を積んだ社外のプロフェッショナルとして継続的にサポートを提供する。
• 毎週の定例ミーティングでの進捗の共有、動作確認、次週の方針の共有など。

顧問弁護士や顧問税理士に近しいという表現は、大変わかりやすく勉強になりました。

本当に柔軟に無駄なく良いソフトウェアを作りたければ、エンジニアを雇用して内製するのが一番良い。

この本の中で、私が最も注目したポイントです。

一般的なプログラミング言語では、内製化は難しいと思いますが、FileMakerのようなローコードツールを活用することで、内製化を実現することができます。

内製化にはすごく大きなメリットがありますが、(本の中でも紹介されてますが)デメリットもあるので、考慮して環境を作る必要があると思います。

• 教育や採用の問題
• 評価の問題
• 属人化の問題
• 担当者の退社や引き継ぎの問題

さいごに

「納品のない受託開発」の必要性や概要を学ぶことができて大変勉強になりましたし、弊社にも良い部分を取り入れていきたいと思いました。

会社によっては、ソフトウェア開発時に「一括請負契約」でしか依頼できないケースもあると思います。

その際は、開発会社にすぐに相見積りをするのではなく、社内で以下のようなことを整理してからでも、遅くないと思います。

開発者としても、見積りの判断材料が増えることで見積りのブレ幅が軽減されると思います。

見積り依頼時にやっておいた方が良いこと

• 要件定義や、見積り、不確実性のコーンについて調べ、概要を理解する。
• 可能であれば…
• 関連書籍を読む。
• 業務を整理する。
• 整理するための方法などについても、書籍を読み実践する。
• パッケージソフトから学ぶ。
• どのような機能があるか確認する。
• 使う機能、使わない機能を整理する。

一括請負の受託開発の終了

今までの「一括請負契約」での課題や、非常に素晴らしいプロジェクトでの貴重な体験をしたこともあり、弊社では「一括請負契約」での受託開発を終了することにしました。

そのため、内容にもよりますが、基本的に見積りのご依頼はお断りしています。

引き続き、さまざまな本を読んで考えたことを整理し、記事にしたいと思います。