「まあいっか」と分業が産む混沌【仕様の伝え方】

製品開発に携わるとよく手詰まるのが、『仕様・機能が矛盾まみれ』になること。

量産開発か、オーダーメイド開発かにもよりますが、顧客要望に対し伝言ゲームの中で、満たすべき要件がすげ変わってしまう現象。

特段際立った理由がないのに、伝言の精度が悪いために変質してしまうのは、手戻りコストで誰も嬉しくありません。どうすれば予防できるのか。。。
まず原因を洗い出し、次に対策を考える必要があります。

【①原因を考える】

そもそも、エンドユーザが抱えている状況や要望を、全て言語化するのは難しいです。
言葉は人類が考えた意思疎通のプログラム・符号ですので、単語が指し示す意味は1対1対応(つまりシンプル)にしなければなりません。

当たり前とはいえますが、意外と実践できてないポイントです。

適した単語の例で、わかりやすいのは「名詞」「数詞」です。りんご、と聞けば、(品種の差はあれ)皆さん赤い果実🍎を思い浮かべます。また、数字は数量そのものを的確に表します。

逆に、意思疎通が難しい単語は「形容詞」「副詞」です。「美味しい」りんごは感性人それぞれですし、「素晴らしい」プログラム、は、その計算速度が早いのか、結果の見せ方がわかりやすいのか、状況なしには想像が絞れません。「赤い」言われても、RGBのカラーコードがなければ、どの赤色か定められません。

【例】
計算速度が速いプログラム(曖昧でBadな例)
↓
計算速度が〇〇個/秒のプログラム
(形容詞を避け、数詞で具体化)

【②登場人物を揃える】

①と別軸で考えなければならないのが、「製品を構成するすべての登場人物を揃える」ことです。アプリで有れば、誰が運営者で誰がユーザで、どのような経路でお金や情報が巡って、幾つの会社が関連して、、など。ソフトの中身でも、どの機能が更新周期を定めて、どのUIから設定を新規入力/変更/削除できて。。。など。
登場人物が揃わない限り、運用を議論することができず、出来上がってから運用が破綻することは往々にあります。(そして追加の改廃コストが。。。)

さらに困るのが、①と②を同時に満たさないとNG、ということ。
①のみカンペキでも②がダメ→NGだし、逆も然り。どちらかに目を奪われてしまうとダメです。

①で例に出した
計算速度が〇〇個/秒のプログラム
も、②の要素がまだまだ欠けています。
・(What)計算に必要な引数・入力信号は何なのか
・(Who)誰が入力するのか、人かBOTかセンサか
・(How)入力UIはあるのか。有線か無線か。出力はどこにどうやって表示するのか
・(When)更新は手動On時の1回のみか、定期反復か。反復なら周期はいくつか。回数限界はあるのか。
etc...

①＋②で、もう一度まとめ直してみると、、

【例】
計算速度が速いプログラム(曖昧でBadな例)
↓ (①を実践)
計算速度が〇〇個/秒のプログラム
↓ (①＋②を実践)
計算周期が、各回:〇〇個/秒のプログラム
・入力：エンドユーザが指定のWebUIから
　　　　・設定値Aをテキスト入力
　　　　・設定値Bをプルダウン入力
　　　　・設定値Cを数値入力
　　　　・日時はPC時刻から取得
・処理：無人、サーバで計算
・更新周期：60秒に1回、上限回数なし
・出力：画面コンソール部にテキスト表示
　　　　動作/エラーログは「××.txt」に別途出力

具体的にまとまったと思います。
これは正常な条件で動く場合なので、
本当はさらに異常モードも考えますが、割愛します。

メンバーと協力し、情報を伝言する上で、少しでも参考になればと思います！
お読み下さり、ありがとうございました！！