AIのせいか年をとったせいか、おそらくその両方で、ビジネスのやり方が変わって、ふんわりした話にばかり関わっている。
「生成AIを使って暗黙知化したプロセスを形式知化して、御社のサプライチェーンをオプティマイズして、セールスをグロースさせます」とか「エンジニア間のスキルギャップをスクラムによってファシリテリテーションして御社のデベロップメント課題をイシュー化します」とか、なんだかそういった感じの話に関わっているのだ。
こういうふんわりした案件は、会議で何を発言しても面映ゆくなるというか、口に出せば出すほど脳が痒くなってくるような感覚があって、結局お前達の求めているものは売り上げと人員整理によるコストカットであって、もっと言えば人間の求めるものは不老と美食とセックスなんだから、そうはっきりと言え、と会議室の真ん中で叫びたくなってくるのを必死でこらえているのだった。
以前は、私の仕事はこんなではなかった。月間8000万PV程度のCMSを稼働できるWebサーバーとMySQLサーバーを高可用性構成をディザスタリカバリ付きで構築しろ、とか、納期が1ヶ月後に迫って壊滅寸前のPHPシステム案件に加勢しつつ、マイルストーンを設定して顧客がブチギレないようにクロージングしろ、とかそういった、確固たるゴールと、泥沼のプロセスがあった。
要求された性能が出せるか出せないか、スケジュールは間に合うか間に合わないか、顧客がブチ切れるかブチ切れないか、全て具体的で、地面は凍りついたように硬く、少なくとも自分が何をすればいいのかはわかっていたのだ。
それがいつの間にか、Typescriptの型定義から何マイルも離れた場所に私はいる。理由の一つはそういった地上の仕事を若手がAIを手助けを借りてできるようになったらしいこと（確認してはいない）、もう一つはこういう空中の雲の中でするような会話のほうがより価値を生むらしい、ということがわかってきたからだった。
なぜか。一つ目の答えは、ビジネス用語を使うと「レバレッジ（てこ）」だ。 「硬い」仕事、たとえばPHPのコードを一行書く価値が「1」だとすれば、「柔らかい」会話は、エンジニア100人の努力を「A」ではなく「B」に向かわせる「舵」を切る仕事であり、その価値は掛け算で効いてくる。舵の角度が1度変われば、到着地点は何百マイルも変わるというわけだ。 少なくとも理論上は、そうだ。
まだ地上にいた時、私は今ひとつその理屈が理解できないでいた。以前書いたこともあるが実感として上手くいった「施策」というものに巡り会ったことがないからだった。奇妙な研修、全社会議の方針発表、自己研鑽としか答えようがない目標管理シート、明らかにsyslogの存在を知らないプロマネ、打ち合わせの度に担当者が変わる外注先、転職を決意させるためだけに行われるボーナス査定と上司面談、そういった種々の思い出があって、上部のふわふわした雲の中で行われている意思決定というものを信用することがどうにもできなかったのである。
だが、私がわかってきたのは、もう一つの側面だ。 それは、「舵の切り方」そのものと同じくらい、「結果の測り方」も柔らかくなる、という事だ。
「硬い」地上の仕事は、結果が残酷なまでに出る。8000万PVに耐えられなければサーバーは落ちるし、納期に遅れれば顧客はブチ切れる。失敗は硬い事実だ。
一方で、「柔らかい」仕事はどうか。 「デベロップメント課題をイシュー化します」という決定が、本当に正しかったのか？ 「オプティマイズ」した結果、セールスは本当に「グロース」したのか？
その結果を測る指標自体が、イシューの消化率やKPIの相対的改善といった、奇妙な「柔らかい」言葉で再定義されていく。 もしプロジェクトが現場の人間に直感的に理解できるぐらい、成功をしなかったとしても、それが「硬い」失敗として記録されることはない。「プロセスは形式知化された」「ファシリテーションは適切に行われた」という別の「柔らかい」成果が光を浴びることになる。
もちろんビジネスの成果が、常に「柔らかい」基準で判断されるわけではないだろう。アル・カポネと孫正義は会議室でバットを素振りしているというし、一度立てたKPIやKGIを無策に悪化させれば、恐ろしい制裁が待っているに違いない。しかし、というべきなのか、だからこそ、なのか、その計画の立案段階では、いかに失敗のインパクトそのものを「柔らかく」吸収してしまう構造を作るか、というところに注意が払われているように私には思えるのである。
我々が「柔らかい」会話で生み出している価値とは、その「掛け算」の可能性への期待であると同時に、この「誰もが決定的な失敗を直視しなくてよい」という、構造的なクッション機能に対する対価でもあるのだろう。
この「硬さ」の感覚の違いを理解すると、過去の色々な疑問に答えが見つかったような気がするのである。
かつて営業の人間から「失敗したって、命までは取られないじゃないですか？」と言われたことがある。私はどうにもその感覚がわからなかった。 サーバーの構築に失敗し、サービスが開始時刻にオープンできなかったら？ 比喩ではなく、それこそ命を取られるほどに落ち込む私としては、どうにも理解しきれない忠告だった。
確かに命がなくなるわけではない。が、死という不明瞭な状態と、現世での決定的な失敗という状態は、主観的に見て、大きな違いがどうにも見いだせなかった。自分もまだまだ死というものが、人生というものがわかっていないのだなあ、とぼんやり考えたりもしたのだが、今思うと、そういう哲学的な話でも何でも無くて、彼が言う「失敗」とは、おそらく商談の失注か何かだろう。今の私に言わせれば、それは「柔らかい」失敗なのだ。顧客の虫のいどころ、タイミングの問題、なんとでも言えるような失敗だからなのではないか。
この感覚のズレは、他のPMとの会話でも感じた。 プロジェクトの遅延が濃厚になった時、私はPMにこう聞いたことがある。「プロジェクトが遅れてても、自分が手を出して早めるわけにはいかないのって、辛くないですか？」と。 私は、かつて自分がそうしてきたように、手を動かしてでも「硬い」納期に間に合わせることを考えていた。だが、彼はピンとこない顔をしていた。
今ならわかる。彼の仕事は、私のような「硬い」タスクの実行ではなかったのだ。彼にとってのプロジェクトとは、それ自体が「柔らかい」不確定性の塊であり、そのマネジメントこそが仕事だった。遅延もまた、マネジメントすべき「柔らかい」事象の一つに過ぎないのだ。だからPMは計画に間に合わせるために自分が徹夜でプログラミングする代わりに、プロジェクトの完遂に向けて仕様と要件を整理し、各方面の面目が立つようにリスクをコントロールする手段を講じれば良いのであって、そこにもどかしさはないに違いないのだった。
*
私は、打ち合わせから帰宅すると、自宅のPCの電源を入れた。地上の仕事を奪われた私にとって、最後の安住の地は、この趣味のプログラミングをする時間だった。
難しい処理の実装にさしかかって、私は、ふとその部分をAIに書かせてみることにして、すぐにAIは、それらしいコードを吐き出した。だが、それは要件を満たしているのか満たしてないのか、今ひとつよくわからないコードだった。私はAIにコードについての質問をしたが、どうにも要領を得なかった。チャットUIの外側にある注意書きが目に入った「生成AIは不正確な情報を表示することがあります。生成されたコードは再確認するようにしてください」再確認？何を？誰が？
その時、私は奇妙な心境になって、ひどく不安になった。PMも、営業も、そして今やAIさえも、みんな「柔らかい」霧の中にいる。 みんなが宙に浮いている。 かつて私が立っていた、あの凍りつくように「硬い」地面には、もう誰もいないのかもしれないのだった。
