プロジェクトが崩れるとき、原因が技術やスケジュールそのものであることは意外と少ないです。多くの場合、関係者の間で少しずつズレていた前提が、終盤になって一気に表面化します。
やっかいなのは、途中では誰も困らないことです。それぞれが自分の理解の中では正しく進めているので、進捗確認では引っかかりません。ズレが見えるのは、成果物を突き合わせる段になってからです。
私が経験した中で一番きつかったのは、同じ言葉を使っているのに意味が違っていたケースでした。この場合、会話は最後まで成立してしまうので、ズレていることに誰も気づけません。
目次
1. 「精度90%」で合意したのに揉めた話
ある分類モデルの案件で、「精度90%以上」という目標を顧客と合意していました。文書にも残っていて、双方が署名しています。
モデルができて、検証したところ全体の正解率は92%でした。目標達成です。私はそう報告しました。
ところが顧客の反応は「これでは使えない」でした。
原因は、扱っていたデータが不均衡だったことです。全体の95%が「異常なし」で、検出したい「異常あり」は5%しかありませんでした。全体の正解率で見れば92%ですが、肝心の異常を拾えている割合、つまり再現率は50%程度しかなかったのです。
顧客が「精度」という言葉で想像していたのは、異常をどれだけ取りこぼさないかでした。私が報告していたのは、全体でどれだけ間違えないかでした。どちらも日本語では精度と呼ばれます。
この件が厄介だったのは、揉めるまで一度も会話が噛み合わなかったことです。「精度は順調です」「分かりました」というやり取りを何度もしていて、その間ずっと違うものの話をしていました。
2. 同じ言葉を使っているうちは気づけない
この経験以来、私は用語の定義を最初に潰すようにしています。特に、次のような言葉は要注意だと思っています。
- 精度：正解率なのか、適合率なのか、再現率なのか
- テスト：単体テストなのか、顧客側の受入確認まで含むのか
- 完了：実装が終わった状態なのか、レビューまで通った状態なのか
- 対応する：今回のスコープでやるのか、次フェーズで検討するのか
- リアルタイム：秒単位なのか、数分の遅延は許容されるのか
どれも、日常会話では問題なく通じてしまう言葉です。だからこそ確認が省かれます。
やり方としては大げさなことはしておらず、キックオフの資料に用語の定義を1ページ置いておくだけです。「本案件における『精度』とは再現率を指す」と書いて、口頭でも一度読み上げます。作るのに30分もかかりませんが、あの一件と比べれば安いものです。
機械学習の場合、そもそも顧客が何を期待しているかが人によって大きく違うので、この確認は特に効きます。そのあたりはリスクマネジメントの役割とプロジェクトの成功にも書きました。
3. 進捗確認は「成果物ベース」で行う
用語を揃えても、進捗の確認が主観的なままだとズレは残ります。
「順調です」という報告は嘘ではなくても、何がどこまでできているのかは伝わりません。受け取る側が自分の期待に合わせて解釈するので、そこでまた差が生まれます。
そのためには、各成果物の達成基準を先に決めておく必要があります。ソフトウェアなら「コードの完成」ではなく「対象機能の実装とテストが完了し、コードレビューを通過した状態」まで書きます。ここまで決めておくと、完了したはずのものが差し戻される回数が減ります。
そして、報告は数えられるもので出してもらいます。完了率、マイルストーンの通過状況、レビューの残件数。数字であれば、解釈の幅が狭まります。この進捗の測り方についてはITプロジェクトマネジメントの基本知識と実践方法に詳しく書きました。
区切りを小さくしておくのも効きます。大きな塊のまま進めると、突き合わせるのが終盤になり、そこで初めてズレが見つかります。小さく区切っておけば、ズレてもその区間の中で見つかります。
4. 「そんなこと言う！？」が齟齬のサイン
最後に、実務でいちばん役に立っている見分け方を書いておきます。
相手の発言に違和感を覚えたときは、認識がズレているサインです。
「その仕様だと困る」「そのスケジュールでは無理だ」と言われたときに、「自分が相手の立場なら、そんなことは言わないはずだ」と感じたなら、それは意見の相違ではなく前提の食い違いを疑った方がいいです。
冒頭の精度の件も、実は兆候がありました。顧客から「異常のサンプルをもっと集めた方がいいのでは」と一度言われていたのです。私は全体の正解率を見ていたので「今のデータ量で足りています」と答えました。今思えば、あそこで「なぜそう思うのか」を聞いていれば、その場で気づけたはずでした。
違和感を覚えたときにやることは単純です。その発言の背景にある前提を一つずつ確認して、こちらの計画書や仕様書と突き合わせます。どこで分かれたのかが特定できれば、関係者を集めて合意を取り直せます。
面倒に感じますが、この確認にかかるのはせいぜい30分です。ズレたまま終盤まで進んだときの手戻りは、日数単位で返ってきます。
5. まとめ
認識のズレを防ぐために、私がやっていることは三つです。
- 用語の定義を最初に文書化する。 「精度」「テスト」「完了」のような、日常会話で通じてしまう言葉ほど危ない。
- 進捗を成果物と数字で確認する。 「順調です」は解釈の余地が大きすぎる。
- 違和感を覚えた時点で前提を確認しに行く。 「そんなこと言う？」と感じたら、意見の相違ではなく前提の食い違いを疑う。
どれも特別な手法ではありませんが、忙しくなると最初に省かれます。省いた分は、たいてい終盤に手戻りとして返ってきます。
個人の作業レベルで同じことが起きたケースは、最後にやり直しになる人は、最初に納品物の形を見ていないに書いています。最終成果物の形式を確認しないまま定例報告を出し続けて、終盤に詰め替え作業が発生しかけた話です。
報告しているのに信用されない状態についてはプロジェクトマネジメントにおける説明責任とは？に、情報の流れそのものの設計はチームワークを高める：ITプロジェクト管理におけるコミュニケーション戦略にまとめています。管理全体の枠組みはITプロジェクトマネジメントの基礎とその重要性です。