※本記事にはプロモーション（広告）が含まれています。
「メモでいいって言ったよね？」――。この記事では、ビジネスの現場で起きるこの現象の裏にある「OSのバグ」を、アーキテクトの視点で解剖します。
よくある場面
「メモでいいって言ったよね？」
私は机に置かれた分厚い資料を指で叩きながら確認します。
「はい。メモは書いたんですが、そもそもの定義や構造の認識にズレがあると議論が破綻するので、明確にできるようにまとめました」
「……それにかけた時間は？」
「……一晩です」
「……これ、最終成果物として必要？」
「……不要です」
「不要なものを、一晩かけて作ったということ？」
「……」
これは実際にあったやり取りです。そして、この「一晩かけて不要な資料を作った部下」とは、かつての私自身です。
ここで重要なのは、部下（私）の「意図」自体は間違っていなかったということです。上流工程で定義や構造の認識を合わせておくことは、プロジェクトの致命的なズレを防ぐ上で極めて有効なアーキテクチャ設計です。間違っていたのは、その「実装方法（言動）」です。
定義や認識のすり合わせは、数分の口頭コミュニケーション（軽量な通信）で済むはずです。そこに徹夜という膨大なコスト（CPUとメモリ）をかける意味はありません。
なぜ起きるのか ― バグの構造
ではなぜ、部下はコストをかけてまで過剰な資料（オーバーエンジニアリング）を作ってしまうのでしょうか？
それは、部下自身が定義や構造を正確に捉えきれておらず、「間違えること」に極度に怖え、過剰武装しているからです。
例えば「あまおう（イチゴ）」の定義。部下が適当に「あまおう＝イチゴです」とメモを持っていくと、PMから「いや、あまおうは『あかい、まるい、おおきい、うまい』の略だから、青くて小さいイチゴはあまおうじゃないよね」と突っ込まれる。このエラー（指摘）を恐れるあまり、「あまおうとは福岡県産の……」という分厚い資料を徹夜で作り込んでしまうわけです。
しかし、PMとのすり合わせの場は「正しい知識を発表する場」ではありません。「どの認識が合っていて、どの認識がズレているか」を検知するための場です。
これは「学校のテスト」の呪いと同じです。テストの本来の目的は、いい点数を取ることではなく「自分がわかっていないバグ（間違い）を特定すること」です。しかし、認知の歪みにより「正解することこそが絶対の善」というOSが組み込まれているため、間違えることを「学習の機会」ではなく「悪（減点）」だと捉えてしまいます。
システム開発において、初期段階でエラー（ズレ）が見つかることは、後戻りコストをゼロにする「極めてラッキーなイベント」です。
この「テストの目的」を履き違えた部下に対し、アーキテクト（PM）はどのように「正解主義の呪い」を解き、最速で未完成のメモを出力させるべきでしょうか？
まず試せる一手：打ち合わせを「テスト」だと宣言する
部下が徹夜で資料を作り込むのは、打ち合わせを「正解を発表する場」だと思っているからです。PMの側から、場の定義を変えます。
「明日の打ち合わせは、正解を持ってくる場ではありません。お互いの認識のズレを早く見つけるための場です。箇条書き3行で来てください」
ソフトウェア開発には、先にテストを用意してからつくる「テスト駆動開発（TDD）」という考え方があります。ズレ（バグ）は早く見つかるほど、直すコストが小さくなります。打ち合わせでズレが見つかれば、それは失敗ではなく成功です。
ここまでが、最初の一手です。この一手を習慣にして、同じバグを繰り返さない仕組みにするための残りの手順は、noteで公開しています。
残りの解決策（How）はnoteで公開中
ここから先の具体的な解決策・コマンドは、noteの記事「アーキテクトの過去問」として公開しています。
このテーマを深めるおすすめの本
『失敗の科学』（マシュー・サイド）
「間違えること＝悪」という思い込みを外し、失敗を早く小さく出して学ぶ組織の考え方がわかる一冊。
▶ 楽天で探す
▶ 耳で読むなら：新作続々追加！オーディオブック聴くなら – audiobook.jp
※本記事は、noteで公開した「「メモでいいって言ったよね？」徹夜の資料と正解を求める部下の「学校のテスト」の呪い」の無料部分をブログ向けに再構成したものです。
コメント