※このお話はフィクションです。

前提

• 要件定義が済んでいる(風)、だけど具体的な仕様は未定

• 要件から工数を緻密に見積もり済みで受託している

• 事前にPoCや技術検証をやっている、だけど具体的な仕様は未定

• 実は大規模100名２ヶ年プロジェクト

• 発注している人たちも提案する受託側の人たちもそれを作ったことはない

これで何が起こる？

仕様だけで会話される

このやり取りで危ないのは

• 「リアルタイム」の情報自体が欠如している

• そもそも「いつ」「誰が」「なぜ」リアルタイムでみたい画面なのかが欠如している

で、その状態で作り進めると、

• ユーザーが調整したいパラメーターが想像しにくいため設計に影響する

• システム上の制約が発生しても対処すると手戻りや手遅れにつながる

10秒を中心に会話することによる弊害はとても大きいです。
そんなことしないと思っていても、簡単に起こります。プロジェクトを始めて1ヶ月とか、ちょっと慣れてきた頃。ちょっと納期やマイルストーンが迫ってきた頃。

仕様と真剣に向き合ってきているからこそ、背景も根拠も整っているからこそ、10秒という数字を伝えたくなります。しかし、それは机上の空論じゃありませんか？

はい、そうです。リアルタイムを求められていたら、遅くても1秒間隔とか想像しませんか？令和の日本ですし。
専門家が10秒と言っていたら、お客様はそれが正しいと信じますよね。見てみて納得してくだされば良いのですが。

仕様同士の不整合が機能間で発生している

仕様を伝える側が伝えられる側よりも仕様を把握できないケース。
過去に書いていたドキュメントでは自分でちゃんと書いていたとしても、忘れてしまうこともありますよね。

ドキュメントがメンテナンスされてくれれば良いかもしれませんが。別チームの仕様を大幅に変えないと実現できない仕様を、曖昧だった要件を固めていたつもりで持ち帰ってくる。なかなか怖いです。

議事録に書かれていることだけを正としてしまうと、どこかで破綻して、不正やデスマーチのようなモチベーションや倫理観に影響が出てくる次元にまで発展しかねません。

もちろん、開発する人たちで不整合を発生させたり、作ってから気づいたりすることもありますよね。
１チームのお話ならまだ対処しやすいかもしれませんが、チームを跨るとかは・・・想像したくないです。はい。結合が遅くなればなるほど事態の発覚も遅れて、手戻りや手遅れにつながります。

仕様が確定していないけどなんとか進めたいバイアス

自分の意思で決めきれない状態、
スクラムではプロダクトオーナーのアンチパターンど真ん中です。
もしくは生煮えのプロダクトバックログアイテム問題。

意思決定の質が低い状態の積み重ねは活動の生産性を損ないます。
稼働やベロシティ上は問題なさそうに見えますが、作業期間中（スクラムならスプリント毎）のROI（投資対効果）を著しく下げます。

開発者も仕様が決まりきっていない状態の開発には慣れているので、悪気なく仮実装をしてみてくれます。作ってみてからフィードバックをもらって微調整していく考えはとても大事です。けど、スケジュールはリリースまでギリギリな見積もりで引いていませんか？

早く安く仮設検証をするために、実装しなくても確かめられる方法、工夫次第でたくさんあります。文字や議事録だけでは、なかなか共通認識は作りにくいです。ビジネス的な意思決定を早めたり質を高めたりすることは、文字通りビジネス価値を高めることに直結するので、チームで組織で向き合っていきましょう。

終わりに

誰かの課題や実現したいことがあって、それを解決する手段として企業活動を行います。
誰かの課題や実現したいことにはWhy（なぜ？）があります。他の人が考えたり当てずっぽうで決めたHow（やり方）やWhat（モノとかコトとか）は元々の解決策になっているでしょうか？

要件はWhat、仕様はHowの要素が強いです。すなわち、Whyはドキュメントからは得にくいことが多いです。
Whyを意識していても、手戻りやアップデートは発生します。
Whyなしの作業では、手戻りはもちろんのこと、設計上の欠陥が埋め込まれやすく、手遅れにつながります。（少しそれますが、もう一回作ってみよう！ができるケースはとても良いです。）

Whyの解決のために、しかるべきコミュニケーションを行って、WhatやHowに関する質の高い意思決定を積み重ねていきましょう。