■ 1. 曖昧な依頼の危険性
- 「大体こういう感じで」という頼み方:
- 最も危険な依頼の仕方
- 委託側は分かっているつもりでも、受託側は具体的に何を作ればよいか分からない
- 結果として、委託側にとって「それではない」ものが出来上がる
- 機能は合っているのに使えない成果物:
- 曖昧な依頼から生じる非常に困った状況
- 止めておくべきだった案件の事例:
- あるサービス部署から「なんとなく顧客情報が取れるようにしてほしい」程度の依頼があった
- そのサービスにとってどう動けば役に立つのか分からないまま作り上げてしまった
- サービス部署から使えないというクレームが上がった
- 結局、一から全部作り直すことになった
- 契約前の期待値調整:
- 受託前、契約前の段階で、互いに何をゴールにするかを調整する必要がある
■ 2. 「できます」と言ってしまう理由
- 営業側の事情:
- 戦略的に付き合いたい会社だとして、営業が受注を強く求めてくることがある
- 技術者側の心理:
- 仕様を自分の中で最も簡単なものに置き換え、できそうだと納得して進めてしまう
- 「技術的に不可能ではない」の誤解:
- 技術的に不可能ではないという発言が、相手には「できる」と受け取られる
■ 3. 潰すべき曖昧さ
- ソフトウェアを作る目的:
- どの顧客のどんな未解決の課題を解決するのかを明確にすることが基本
- 受託側であっても、委託側から目的を聞き出せなければ間違える
- 非機能要件の記載不足:
- 後から大きな問題になりやすい曖昧さ
- 例として、作業者が1日分の測定データをPCへ転送するのに1時間かかる場合がある
- その場合、5時に作業が終わっても帰りが6時になり、残業が発生する
- こうした点は使い手にとって問題になる
■ 4. 仕様書だけでは仕様は伝わらない
- 仕様書の位置づけ:
- 仕様書はコミュニケーションの1つの手段にすぎない
- 仕様書だけで仕様は基本的に伝わっていないと考えるべき
- 仕様書の網羅性の限界:
- ソフトウェアの全てを仕様書で網羅することは不可能
- 当たり前の動作は仕様書に書かれにくい
- ドラッグ＆ドロップの事例:
- 海外の会社に測定ツールの開発を委託した
- 複数ファイルをドラッグ＆ドロップすれば全データが取り込まれることを想定していた
- 実際の実装は、10個選択しても最初の1ファイルしか扱わないものだった
- 受託側の実装傾向:
- 委託側が「普通こうなる」と思う動作でも、受託側は最も楽な実装方法で実現してくることがある
■ 5. 相手の望みを確認する方法
- ユースケース仕様書の作成:
- 営業、品質担当、デザイナーなど、ステークホルダーを全員集める
- 作るソフトウェアがどのようなシーンで使われるかを合意していく
- 要求仕様書と要件定義書のやり取り:
- 委託側が要求仕様書を受託側に渡す
- 受託側はそれを元に要件定義書を出す
- 受け入れ検査仕様書の作成:
- 非常に重要なもう1つのポイント
- 要件定義書をもとに、どのようなテストをしてどの基準に合格すればOKかを記載する
- 受託側の成果物がそのテストに合格すれば検証OKとする取り決め
- 簡単に言えば「何ができたらOKか」を先に相手と合意しておくこと
■ 6. 小さく区切った委託
- 早期の問題発見:
- 最終段階でNGと言われると、どうしようもない状況になる
- なるべく早く問題に気づき、問題を小さくすることが重要
- 軌道修正のためには、委託の単位をなるべく小さくする必要がある
- 3ヶ月サイクルでの委託:
- 約3ヶ月単位で委託し、その期間に収まる検査仕様書を作成して依頼していた
- 検査工数自体を小さくできる
- 誤りがあれば次の委託で修正を依頼できる
- USB機器の事例:
- USB機器を10台接続する機器の開発をある会社に委託した
- 当初はできると言っていたが、途中で難しいと申告があった
- 結局、コア部分は別の会社に委託し直した
- 早めに申告があったためリカバーできた
- 完成まで隠されていたら、仕様を満たさないものが出来上がっていた可能性がある
- 長期委託のリスク:
- 期間を長く取るほど、こうしたリスクを抱えたまま進めることになる
- 委託側の工数確保:
- 受け入れ時には委託側も自らテストする必要があり、丸投げはできない
- 委託側にもその工数を用意しておかなければ失敗する
■ 7. 失敗事例を集めた理由
- 自身の失敗経験:
- 自分が失敗をやらかしまくってきた人間であることが出発点
- 他の人も多く失敗しているはず
- 成功と失敗の再現性の違い:
- 成功の秘訣は状況、プロジェクト、人、環境などに左右され、ケースバイケース
- 成功のための決まったやり方はなかなかない
- 失敗は再現性が高く、こうすれば必ず失敗するというものがある
- 執筆の動機:
- 元部下たちに自分の失敗を理解してもらうため
- 大きく踏み抜かないように、踏み抜いても立ち上がれるようにという思い
- 本書の活用:
- 本書で失敗を仮想的に経験し、危険の匂いを嗅ぎ分ける力を養ってほしい
■ 8. 重要な3つのポイント
- 「できます」と言う前に前提を確認する
- 仕様は伝わっていない前提で確認する
- 小さく区切り、受け入れ基準を先に決める
■ 9. 次の案件で最初に確認すべきこと
- ソフトウェアの目的:
- 何のためのソフトウェアかという目的が見えない案件は危険
- 仕様書、委託文書、口頭のいずれでも目的が伝わってこなければ要注意
- 自分たちが何を作ろうとしているか分かっていない案件は非常に危険
- 受託時の確認事項:
- 誰の何のためのソフトウェアか、どんな課題を解決しようとしているかをまず確認する
- 本書の42の事例:
- 自分の案件に照らして読むことを勧める