物事を成し遂げるには、しばしば複数人・チームでの作業が必要となります。チームで作業をするとき、しばしばマネージャやプロダクトオーナー等が思い描いた作業結果と異なる作業結果にたどり着く事があります。
それは、もちろん良い場合もありますが、悪い場合もあります。ここで悪いと言っているのは、単純にバグっているとか、単純に品質が低いとか、表面的には言われたことを満たしていそうに見えても少し掘り下げると本質的に言われたことを満たしていないとか、そういったことを表します。

これをどうハンドルするか。これを繰り返してしまう状態からどうやって抜け出すか。

この事象は、私が仕事を始めてすぐに出会ってから、ずっと非常に本質的かつ根深い問題でした。
これについて、ようやく答を得られた気がしたので、その答についてまとめます。

結論

認知を揃える、特にメンタルモデルを揃えることによって 、具体的な作業指示がなくても、メンバーが自発的に意味のある開発を進められるようにする。

作業指示道からは卒業する。作業指示やそれに伴うコミュニケーションは大事だが、しかしそれを改善しなくても（≒国語力の改善をしなくても）認知が揃えば行動は自然と揃う。

以下、結論に至るまでの過程を記述します。

作業者として

いわゆる作業者の立場においては、私は以下のような事をやってこの問題から抜け出しました。

指示を正確に読む、指示によって言いたい事がなにかを理解する
指示に限らず、本質的に達成すべき事を考える
全体を見る、自分の作業がどこにどう繋がるかを可能な限りすべて追いかける
- その結果を受け取る側が、受け取って何をどうするかを考える
見解の相違があった場合などに、なぜそれが発生したのかを都度振り返る
- 特に全体で大問題のある水準でなかったとしても、細かく改善点を振り返る
少なくとも相手に悪意はないのだという事を信じる

私自身がこうした事に取り組んだ結果、それによって過去に発生していたトラブルと同じパターンのトラブルは発生しなくなりました。はっきりと成果を出せるようになり、例えば自分の仕事が対外的にプレスリリースとして出せるようになる、取引先などから表彰される、といった形になりました。
ただ、この頃の成果のほとんどは、開発としては私個人によるもので、チームでの成果として成果を実感できるものではありませんでした。マネージャーや依頼者と私はずれない作業ができて、その意味ではチームなのですが、「チーム開発」、開発者複数人によって一人でやるより大きな成果を出す、みたいな形ではありませんでした。

作業指示者、監督者になって

成し遂げたい物事の作業量が一人でできる量を超えると、チームを組む必要があります。
私自身はプレイヤーで構わなかったのですが（今でもプレイヤーで構わないと思っていますしコードを書く作業自体もやっていますが）、作業依頼・指示が必要となったので、流れで作業依頼や指示をするようになりました。
開発の作業指示に関して、私としてはほぼ２極化するというような極端な印象を受けました。つまり、

特別なコミュニケーションはほとんど取っていなくても意図がきちんと伝わり、（意図を論理的制約とみなすと）意図を逸脱しない
質問などもあってそこそこ答えているつもりなのに意図が伝わらず、出来上がってくるものも意図を逸脱して実際に品質が低い

という2つの場合に分かれる、それもシチュエーションや場面というよりは、ざっくりと 人で分かれる という印象を受けました。これは作業者の頃にもよく横目で見ていた光景でしたが、ほぼ一発で十分な品質で上がってくる人と、ダメな品質で上がってくる人にだいぶ２極化するということです。
ダメな品質のものはそのまま上げられないので、当然ですがダメな部分については指摘せざるを得ません。ただ、それを繰り返していくと、そこそこの頻度で「次回以降の作業で一層逸脱していく負のスパイラル」があるように感じていました。

ちなみに、以前この問題を構造的に解決する一つの方法が「デュアルマネジメント」だと思い、このデュアルマネジメント（造語）については「差し戻しをするとうまく承認できない問題」とどう向き合うかという記事で詳しく書きました。これは実際に有効だと今でも思っていますが、ただ、完全ではなくて、上述の負のスパイラルに入るパターンを防ぎ切れてはいませんでした。

作業指示道

諦めたって変わんないぜああまだまだまだ

意図がうまく伝わらないので、私は自分の作業指示を改善しようとしました。つまり、論理的に正しい説明にする、正しく読めば一意にしか取れないようにする、ある程度具体的な記述を増やす、といった事です。
しかし、作業指示道に邁進しようとすると、作業指示道の奥深さに気付かされます。
どうも作業指示について努力をすればするほど、以下のような事がありました。

作業着手前のピントのずれた質問が増える
- 実装してから指摘した事が多くあったことから、実装前に認識相違がないかを確認しようとしているが、ピントが加速度的にずれていく
- 質問を単純に書く量が増え、質問の質を高めようとする時間（？）を取ることで時間もかかるようになる
- 私が質問に回答しないと作業を進められないみたいな状態になるが、私がすべての質問に答えようとすると私の工数が増えてボトルネックになる
質問の応答も含めて、記述された事しかやらない
- 具体的な記述を増やすと、同じ粒度で網羅されていない事象があったら、それが直ちに欠損する
- かつ、記述された事を表面的に解釈すればそうかもしれないが、そうはならんやろみたいな事が増える
  - 実際に作業指示に対して論理的に正しい場合もあるが、そうでない場合の方が多い
一方で、質問したら秒で解決する問題については抱え込んでしまう
- この事象があるので質問をとにかくしてくれと言うが、ただピントずれで増えるとそれはそれで困る
- これが一種のダブルバインドみたいな状態になる（質問しろと言うのに、実際質問するとすぐ聞くなと言われる的なやつ）

これは、悪意があればまだ救いがあるのですが、お互いに悪意がない場合は特に不幸で、救いがありません。この状況が続くと作業者のパフォーマンスは落ちます。
難しいのが、このタスクをやったら色々理解が深まるかなと思って、作業自体は10分で終わるであろう作業を依頼して、1日かけても様々な原因で終わらなくて、結局のところ理解が深まった感じはないどころか、次のタスクでは質問の内容や相談までの時間などあらゆるパフォーマンスが落ちていく...
多分、人によって認識は様々で、その状況に申し訳ないと思うが改善できない作業者もいれば、事前の質問を増やすことで効率的に作業ができていると信じている作業者もいたりするのでしょう。

それでも普通にできる人もいる

ただ、全員がそうなるのかというとそうではなく、普通に作業ができる人も沢山いました。特にインターンや未経験からの転職者でも、参画してすぐ、相当なスピードで開発を進められる人が何人もいました。
また、もはや人間ではないですが、タスクの種類によってはChatGPTも私の指示で（特別な注意をしなくても）意図する処理ができました。

開発者以外にはここまで困った事がないのに

私が一番よくわからなかったのは、仕事において、開発者とのコミュニケーション以外でこんなに困った事は全くなかったということです。例えば、単純に理解が速いとか遅いとかいう事であれば、営業メンバーとの会話でも人によって差がありますが、根本的な解釈が分かれるとか、ピントのずれた質問はまず発生しませんでした。（作業指示とは若干異なりますが、例えば要望の内容の整理や、複雑なオペレーション、仕様に関する質疑などにおいてそうでした。）
そのような点で、この事象が単純な頭の良さとか、単純な国語力とか、そういった要素によって発生しているものでない事は明らかでした。

人間は書いてある事を書いてあるとおりに読めない

なぜこのような状態が発生していたのか、ということの答は「作業指示を理解する道筋としては、指示を正確に読み取って理解する場合と、指示が正確に読めなくても認知によって意図を理解する場合の2つがある」です。別の言い方で「人間は書いてある事を書いてあるとおりに読めない」と言った方がわかりやすいかもしれません。
つまり、どのように失敗しているのかというと、「作業指示に対して、それを受け取る側が 自身の認知によって 別の意味を考えてしまい、誤った行動を取る」ということです。明文化しても、結局人間は間違えるということ。
だから、認知によって意味を書き換えられなければ正しく作業ができるし、また認知による書き換えがあるにしても 作業指示者と同じ認知であれば結果的にずれない・正しい答にたどり着く ということです。

別の言い方をすると 作業者の読解が認知による影響を受けやすい場合、作業指示をいくら改善しようが、認知が変わらなければ本質的に改善しない ということです。

認知を揃える

変わらないはずはないよ手を伸ばして

ここまで来ると答ははっきり見えていて、つまり作業指示がうまくいかなさそうな時点で負け戦です。その前に認知を合わせておかないといけない、という事になります。例えばスポーツでいえば、サッカーの試合で高度な作戦を実行するには、事前に作戦の趣旨や具体的な動きなど、基本的な認知を共有しておく事があたりまえです。同じように、作業指示においても、いざ作業するぞという前にそもそも認知が共有されているべきである、ということです。これは技術的な事についてもそうですが、必ずしも技術的でないこと、例えばいわゆるドメイン知識などもすべて含まれます。
私が会社で仕事をする場合に特に認知的に揃える必要があると思ったのは、次のようなことです。

Mission Vision Values
基礎的な物事のメカニズム
- 例えば「レバレッジ」について
現状に対する認知
- 「時間が無いなかで、必死に取捨選択しながら必要になる事をやらないといけない」みたいな気持ちとか
具体的な目標
- 売上や開発目標など
後発参画者としてはキャッチアップが必要だという事実と、その方法
- メンタルモデルの修正についてのメンタルモデル
  - メンタルモデルについては「プログラマー脳」の本の感想と賛辞〜意味波と具象と抽象との記述を参照

こうした基礎的な認知が合って、かつ業務領域に関する認知も合えば、自然と「自分が何をすればよいか」ということがわかるようになります。これはもちろん、コミュニケーションを取らない・減らすというような事ではなくて、むしろコミュニケーションを取る前提で、ただ認知の方向が揃っていれば効率的あるいは深いコミュニケーションができる、という事です。コミュニケーションの質を高めるためにも、自然と認知の軸を揃える必要が出るわけですね。

メンタルモデルの修正について

例えば作業者がなにか作業をしたとき、それが求められているものではない、想定の乖離があると手戻りが発生します。これの修正をするためのメンタルモデルをまず作りましょう。
ちなみに、作業者の目線では例えば質問を沢山するというメンタルモデルにもなり得ますが、ここでは別の方法を取ります。

想定の乖離のメカニズムを考えると、以下のような原因に分けられると思います：

単純な考え不足（時間や量的なこと）
方向性の間違い
- 知識、文化
- 考え方、戦略

まず、この枠組みで各原因を列挙して、乖離の原因となった事象について、作業指示者とメンタルモデルを合わせるようにします。知識が足りなければ知識を増やす、文化的にずれていれば直す、考え方や戦略がずれていれば正しいものを中心に据える、といったことです。これを、一事象・一知識をすり合わせるという事を目的とせず、根本的な認知や考え方を合わせていく、という気持ちでやっていきます。
そうして認知を揃えると、考え自体がずれるという事がなくなり、各チームメンバーの成果を積み重ねられるようになります。かつ、できる限り一人の判断者に依存しなくても判断できるようになることで、全体のボトルネックも減らせます。
こうしたメカニズムにより、認知を揃える、特にメンタルモデルを揃えることがチーム開発においても重要なのでした。

質問でも自分で考えるでもなく、単純にインプットを増やす

一般に、認識が合わない場合にそれを直そうとすると、質問や考えるという行動を取りがちです。それはそれで大事ですが、それと同等にやらないといけない事があります。それは、単純にインプットを増やす ということです。場合によっては、質問したり考えたりする前にまずインプットをする事が重要なこともあります。例えば、よく否定的に扱われる、「会議に出席だけして発言しない人」も、状況によってはインプットとして重要な可能性もあります（議事録を読めば済むことかもしれませんが）

むすび

いつものように、結論としてはめちゃくちゃ当たり前に言われている事を書いているように思います。
こんな事も分かっていなかった自分はただのヤバい人なのでは、といった事も思います。
ただ、チーム作りにおいて、なんとなく大事そうなことを、どういう理屈で・何を目指してやればよいのかという事がずっとわからなくて、「みんなの意識を揃える」みたいな事が宗教になってしまいそうでずっと苦手で避けてきたところがあるのですが、ようやくどれぐらい重要な事なのかとか、何が目的なのかといった事がわかったので、これからは頑張れそうな気がします。
例えば1on1も、人によってはうまく使い切れていないと感じる事がありましたが、仕事をする上で必要な認知を揃えるための時間なのだと思うと、非常にすっきりします。その認知の範囲も、私はずっと過小評価していました。
理想的な技術者としては、逆に認知が揃っていなくても成果を出せる事が重要なのだと今でも思いますが、ただ全員がそうである必要はなく、認知に助けられながらも成果を出せるならば、それで十分だと思います。

何もかも君次第で僕次第さ

おまけ

ChatGPT-4oにコメントを求めたところ、具体的な方策として以下のような提案がありました。参考まで。

定期的なフィードバックと振り返りの実施

チーム全体で定期的にフィードバックと振り返りを行い、認知のズレがないか確認することが重要です。これにより、早期に問題を発見し、対策を講じることができます。

認知の一致を図るためのトレーニング

チームメンバー全員が同じ認知を持つためのトレーニングやワークショップを定期的に開催することが効果的です。例えば、シミュレーションやケーススタディを用いたトレーニングが考えられます。

技術的なドキュメントの共有

プロジェクトに関する技術的なドキュメントやガイドラインを共有し、全員が同じ情報を持つようにすることも重要です。これにより、個々の解釈のズレを減らすことができます。