私は昔からシンプルに正しい事を書いているつもりだった。実際、一部の人には正しく意図する通りに伝わる。特に混乱する要素もないし、文章が上手いと褒められた事すらあった。自分で文章が上手いかどうかは判断できなかった（それどころか、実は上手い文章とは何か、私は未だに全くわからない）のだが、いわゆる国語の成績は昔からかなり良く、その自分としては間違った事は書いていないだろうとは思っていたし、正しく読めば伝わるだろうと思っていた。
しかし、別の一部の人には全く意図が伝わらなかった。20年ぐらい前に、そのような事象がある、という事に気付いた。20年ぐらい前というのは気付いたタイミングなので、もっと昔からそうだったのかもしれない。ただ、私はそれまでに気づく事がなかった。学校ではそのように困る事はなかったからだ。それは、"能力"的な問題もあったのかもしれないし、そんなに深く人と関わる事がなかったのかもしれないし、あるいは両方かもしれない。何にしても、私はそのことをある種の能力の問題なのだと解釈していた。
その後社会人になると、いろんな人と関わるようになった。特に、いわゆる地頭と呼ばれるような能力において、かなり幅広く関わるようになった。中学校の頃はむしろ学力の低い層の方が仲良くなりやすかったが、高校・大学と学力の低い相手がいなくなり、社会に出てまたいろんな人と関わるようになった。そうすると、この問題が身近でそこそこ発生するようになった。
ただ、私の実感では、これはいわゆる学力に依存するものではなかった。いわゆる学力のない人でも、過去の私の言葉でいえば「真剣に仕事に向き合っている人ならば」それが伝わらないことはほとんどなかった。
＜私の言葉でいえば＞というのはセンシティブかつ傲慢な表現で、というのは、私が言っている事が伝わらない人はただちに真剣に仕事に向き合っていない、という解釈ができてしまう。ここで言いたいのは、別の尺度でなんとなくこの人は真剣に仕事に向き合っているよなと思える人については、このパターンの問題は発生しなかった、という事なのだが、それでも結局は私の言葉に対する振る舞いで真剣に仕事に向き合っているか否かが規定されうる、みたいなめちゃくちゃな表現と思える。
でも、私にはそのようにしか思えなかった。
少なくとも学力や頭の回転のようなものではない、というのは客観的な事実から明らかだった。難しい言葉や常識に欠ける、いわゆる試験の成績が良くない、数量的な分析を行おうとするとセンスがない、...これらはすべて客観的な事実として示せるものだが、それらの条件に合致する人においても、私の書いた"難しい言葉"は正しく理解されていた。これは覆しようのない事実だった。
この事が私を一層混乱させた。学力や頭の回転のようなもので言えば低そうな人にも伝わるので、それより"頭の良い"人には正しく伝わる事だと思うのに、なぜ正しく伝わらない場合があるのか。
本人に確認をしたわけではないが、私の以前の職場の社長も本質的に同じ事を思っていたのだと思う。仕事に向き合え、真面目にやれ、表現としてはめちゃくちゃ陳腐なものになってしまうのだが、しかしそうとしか表現できないように感じる事象は山のようにあった。この社長はとても優秀な人だったが、これは"能力"的な部分ではない、もっと別の事への指摘なのは明らかだった。
ただ、「真剣に仕事に向き合っていない人」が本当に真剣でないのかというと、少なくとも苦しんで仕事をしてはいたし、社会の半数の人よりはまあ努力をしていると言って差し支えない程度にも見えた。まあ、作業指示者の要求を満たせていないという時点で十分な成果が出ていなくて、その結果を評価して努力が不足しているとするのは、成果主義的には正しいだろうが、でも向き合っていないと言うべきなのか、よくわからなかった。
プログラミングで仕事をすることは、人を動かして仕事をすることと比べれば、遥かに簡単だった。プログラムは書いた通りに動いてくれるが、人は書いた通りに動いてくれない。思い返せば、私が教育とプログラムを書く仕事を比較してプログラムを書く仕事を選んだのも、様々な人を動かせると全く思えなかったからだった。
そんな私の気持ちは、ChatGPTによって決定的なものとなった。ChatGPTやClaudeを利用するとき、いつも私は人間に対して作業依頼するときと同じ温度感で利用している。普段の口調もあるのだが、ChatGPTに対して私は常に敬語だし、お願いや質問を人間に対してするのと全く変わらないように入力している。率直に言うと、ChatGPTが答えられる範囲の内容であれば、それは「一部の言葉が通じない人」よりも圧倒的に精度が高い。
ChatGPTに依頼するとき、私は事細かにコンテキストを書かない事の方が多い。もちろん必要な説明はすべきだが、私の説明は必要最低限の内容になっている（という事を普段は考えてもいないのだが、実際そうなっていると思う）。対照的に、世の中の多くの質問サイト等では、質問テンプレートとして「やりたいこと」「ためしてみたこと」みたいな事を延々と書かせるようなテンプレートが推奨されているが、敢えて言葉を選ばずに言うと、そんなのはゴミだとずっと思っている。もっと聞きたい事は端的かつ正確に書けるのに、駄文を延々と書かせるのは本当にバカバカしい。実際、ピンポイントに聞きたい事を聞いた結果として、ChatGPTは私の望む回答をきちんとしてくる。根本的に解が無い事や世間に解が知られていない事を除いて、私が意図的にChatGPTを頼った時にそれが解決しなかった事はほとんどない（もちろん、解決するだろうという予測の元でChatGPTを使っているし、根本的に難しそうな事は避けているとはいえ）。つまり、ChatGPTとのコミュニケーションに苦しんだ事はない。私はChatGPTと一緒に生活をしている訳でもなんでもなく、またGPTsやRAGを追加で利用するといった事も一切せずに、本当にただ新しいタブを開いてまっさらな状態で端的な質問を入力して、正しい答を秒で得ている。質問をするためにめちゃくちゃ考え込むような事もなく、タブを開いたらほぼ直ちにタイピングを始めている。こうして、ChatGPTとは端的な文章以外のコンテキストを共有していないのに、全く苦しむことがない。
こうなると、「The cold never bothered me anyway.」と述べた雪の女王エルサの気持ちになってしまう（coldを作業指示と読み替えて）。少なくともChatGPTが正しく解釈できる程度に、私は正しい事を書いているが、一方で一部の人間にはそれが全く伝わらない事もある。（自分の指示を正当化したいのではなくて、単純に一定の作業量を担保しながらうまくコミュニケーションをする事の難しさを嘆いている）
そうしてようやく、私は「人間は指示を正しく読めない」という事を理解した。人間は根本的には指示を正しく読めない、理解できないのだ。もちろん、レベルの差があるだけで私自身もそうだが。
だから、プロジェクトを進める時にも、それを前提にしないといけない。つまり、レベルの差はあるが、人間は指示を正しく読めないし、指示の通りに行動しない。それぞれの人が、最終的に思ったように行動するのだ。指示の通りではなくて、それぞれの人の認知・判断に従って行動する。指示は認知と判断を変える道具の一つにすぎない。
昔から、私がプロジェクトをマネジメントして何かをするとき、指示を指示通りにできる人とは相性が良く、指示を指示通りにできない人とは相性が良くなかった。私のマネジメントにおいて、指示というのは、WBSを適切な粒度まで細分化したときのタスクの説明にあたる。（実際にはWBSを明確に定義していない場合もあるが、それでも頭の中でこういう作業が必要だろうという洗い出しは存在していて、それを適切だと思う粒度でタスクとして分配している）
WBSはプロジェクト全体の設計にもなっている。したがって、指示と論理整合性のない作業をされると、全体の設計が狂ってしまう場合がある。私自身はこれまで、本当に2024/6/1まで全く意識していなかったが、実はこの設計はおそらく思ったより緻密で、この設計の狂い、指示に対する論理整合性の無さに対しておそらく私は相当厳しい。計画が破綻することになり得るので、そういう矛盾には厳しくならずにいられないのだと思う。結果的に時間が単純に無駄になってしまうように見えることもあるし、それが単純な無駄でなかったとしても間に合わなくなるし、何より「その失敗をする人に対してどういった作業指示をすればそれが発生しなくなるのか」がわからないのでどうすればよいかがわからず、最終的に途方に暮れるしかなくなってしまう。「いやー、だからこう言ったじゃん」と言いながら作業指示に明示されている事柄を示す、という事象が起こる。
そうなると、小さいタスクの指示の文章や方法を短時間で改善する事は難しく、「もはや自分でやった方が早い」となってしまう。もちろん、長期的な成長という考えは持っていて、単純に自分でやった方が早いというのはかなり厳しい状態だとは思っているのだが、ChatGPTなら読める指示を正しく読めないことを、果たして改善できるのか。私には、読解力を効率的に改善できるようには思えなかった。「仕事に向き合え」でそれを解決できる人は多くない気がしている。
さて、このようなプロジェクト推進には、少なくとも二つの課題がある。一つは、指示と論理整合的でない作業が直ちにマイナスになってしまうフラジャイルな構造の問題。もう一つは、（仮に構造を解決してマイナスになりにくくしたとしても）指示によってプロジェクトの設計と論理整合的な作業が引き出せるようにすること。
これらの課題が発生している大きな要因の一つは、指示とプロジェクトの設計がほぼイコールである、という事である。つまり、私はプロジェクトの設計（WBS）を頭の中で分解整理したうえで、それの必要な部分を指示しているが、これがプロジェクトの設計と一致しすぎていてアソビがない。指示と設計の間のアソビもないし、設計上許容されるアソビもない。指示と設計の間にアソビがあれば指示と作業内容の不整合があったとしても正しくワークするし、設計上許容されるアソビがあれば設計と作業内容の不整合があったとしても正しくワークする。
補足しておくと、これまでも私の考えとしてはアソビがあった。つまり、「論理不整合がなければ任意の作業が認められる」あるいは「論理不整合がなければ少なくとも作業者の責任にはならない」という程度のアソビがあった。ただ、指示・設計との論理不整合が発生しようものなら、それは基本的には許されない。
これはシステム開発の難しいところでもあり、システム開発で発生した不整合は作り直しによって解消ができてしまう。そのため、プロジェクト設計の修正ではなくて実装・作業の方の修正での対応が多くの場合に可能となってしまう。元のWBSが破綻していなければ作業を修正すれば完遂できるはずなので、必然的に作業の方を修正することになる。そのような意味で設計にアソビがなかった。別の言葉でいえば、当初計画に対して妥協しない、ということだ。これが、当初計画に対するズレが常に減点になるような構造を発生させているとも言える。フラジャイル、想定外の進行に対して弱いと言っているのはそういう意味だ。ズレが常に減点になる。
さらに難しいのは、このズレが何によるズレなのかで私の反応が変わるということだ。現実的に回避不能なズレであれば私はむしろ積極的に許容して対応している。現実的に回避可能で、かつ当初計画の方が筋が良い場合に限って、ズレが許容できない。言い換えると、"私の中では"現実的に回避不能な事については不整合が発生しないような設計をしていて、不整合が発生するとだいたいは回避可能というような設計になっているので、それもあって不整合に厳しく見えるようになっている。
私の場合は作りたいものが論理整合的にある程度具体的に見えていて、その上でそれのための作業を指示して分配しており、ChatGPTのレベルであれば指示だけで不整合なく作業できるが、人間は不整合のある作業をしてしまう場合がある。そのため、私としては指示と設計を分離したり、設計自体をアンチフラジャイルにしていくという事が必要になる。
結果的にアンチフラジャイルとなる一つの例としては、仮に思い通りのものができなかったときに、それに時間をかけて作り直すか、敢えてそのまま運用することで実は十分だったという"利益"を得るか、といったことがある。
一方、指示によってプロジェクトの設計と論理整合的な作業が引き出せるようにすることも課題であった。その鍵となるのが、「国語力があまり高くない人がどうやって私との会話において答を導いているのか」である。これも今日の重要な気づきで、国語力が高くない人は真剣に仕事に向き合っているのだが、それは論理的思考あるいはChatGPT的思考によって書かれている事を純粋に言葉として読み取って解釈して答を導いているのではなくて、それまでに業務ドメインに向き合って仕事をしてきた事によって蓄積された経験や知識によって非論理的に答を導いているのである。もちろん、実際にはいずれかの方式でのみ導くという事ではなく、複合的に導かれる答なのだと思うが。
これが物凄く重要なことで、これまで仕事に向き合っている人で話がずれる人はほぼいない、と思ってきた事の答にもなっている。つまり、いわゆるドメイン知識が豊富な人は、その文脈を通して非論理的にも見ることで自然に答を導けるようになるのだ。これの例外的な状況が、プログラマがプログラミングだけに集中している場合だ。プログラマがプログラミングだけに集中しているとき、書いてある事を正しく読める人はやはり正しい答を導けるのだが、書いてある事を正しく読めない人は、どんなにプログラミングそのものに集中していたとしても、正しい答を導けない。"認知が足りない"のだ。
この場合は、認知を改善することが必要で、例えばシステム開発においては業務と向き合うという事なのだ。業務と向き合うことはおそらく手間も時間もかかるが、しかしそれによって、書いてある事を正しく読めなくても答にたどり着けるようになり、貢献できるようになる。さらには、"敢えて"当初の指示とずれた視点で作業をすることで、もっと想定されていないプラスを生じるようにもなり、アンチフラジャイルな状態を導くだろう。少なくとも私は、自分の指示通りに動く集団を作りたいのではない。自律的に個別に考えて動ける中で、必要なら私がサポートをするぐらいのものでよいのだ。（はやく座敷わらしになりたい）
プログラムは正しい言葉で動き、またそれ自体はタイポで壊れるなどフラジャイルな構造をしているが、プログラムを作る我々の動くプロジェクトはフラジャイルな構造でなくてよい。正しい言葉でのやり取りを前提としないからこそ、逆にアンチフラジャイルなプロジェクトを作れる。
多分、そういうこと。
私は他の人の国語力・読解力の部分ばかりを見ていた。純粋なプログラマとしての能力、複数のドメインにわたるプログラミングの本質みたいなものはそうなのかもしれないが、少なくとも全員がそういう種類のプロである必要はない。ドメインの知識でそれは補える。
もちろん、WBSを守ることには時間に間に合わせてプロジェクトを遂行するための管理をするといった効用があるのだが、構造上減点方式・フラジャイルになりやすい。想定外もプラスに変えられる、そのようなプロジェクト推進の可能性を感じられたことが、素晴らしい気付きだった。
具体的な認知の改善は、作業の仕方を変えるとかそんなチャチな話ではない。もっと根本的に、自分たちが対象とする業務領域やシステムそのものへの理解を深めるための具体的な動作が求められている。ChatGPTではない人類は、そうやって仕事をしないといけない。