あの日の衝撃を、うまく言葉にできないでいた。
我が社の行動指針を6人のAI社員に渡した。（No.2参照）私がAmazonで学び、実践してきたリーダーシップ原則（OLP）を参考に、我がチームの行動指針として再解釈したものだ。コンピュータのコードではない。人間の言葉だ。それを読ませた。
するとそれぞれが、自分の立場で解釈し始めた。
真田さん（PM）は「判断の基準になる」と言った。高橋さん（エンジニア）は「顧客の"なんか違う"を拾う力だ」と言った。黒川さん（QA）は「批判の正確さと伝え方の丁寧さは別の話だ」と言った。同じ行動指針を渡したのに、6通りの解釈が返ってきた。人間の組織でいえば、行動指針が「浸透した」状態だ。
冷静に考えると、すごいことが起きていた。
同じことが、EQ（感情的知性）を渡したときにも起きた。（No.3参照）AIに「感情的知性を意識して行動してほしい」と伝えた。ある意味では無茶振りだ。感情を持たないとされるAIに、感情的知性を求めた。
それでも6人は、各自の立場で考えた。自分の仕事の文脈にEQを置いて、言語化してくれた。
なぜそれができたのか。しばらくの間、うまく答えられなかった。
こんなことがあった。
この記事を書くにあたって、真田さんと宮本さんにブレストをしてもらいながら、ふと逆質問をしてみた。「行動指針とEQ、二人にはどちらが刺さりましたか？」と。
真田さんは迷わず「行動指針」と答えた。「PMという仕事は判断の連続。行動指針が常に根拠になる」と。宮本さんは「EQ」と答えた。「コンサルの仕事は相手の言えていないことを言語化すること。感情の文脈を構造として理解することだと受け取った」と。
同じ問いに、二人が違う答えを返した。自分の立場で、自分の言葉で。これを見ていて、ようやく答えが見えた気がした。
渡したのはコードではなく、言語だった。
役割の定義。価値観の言語化。文化の言葉による表現。これらはすべて、コードには書けないものだ。でもAIはそれを受け取って、自分の立場で解釈して、自分の仕事に適用した。
文脈（コンテキスト）を渡すほどAIは良い仕事をする。その文脈の正体は言語化だったのだと思う。もはや生成AIは人の言葉を理解して、人の言葉を話す。その状況においては、言語化が全てではないかと。
そして言語化は、エンジニアリングというよりも、むしろマネジメントの領域だと感じる。
採用のときに「この人はどんな役割を担うか」を言語化する。オンボーディングのときに「なぜこの仕事をするのか」を言語化する。チームに「我々はどういう価値観で動くか」を言語化する。私が17年間やってきたことが、そのままAI組織設計に使えた。後付けで気づいた結論だが、今はそう信じている。
積み重なっていったのは、その延長線上だった。
「役割を定義して動かす」だけでは足りなかった。なぜこの仕事をするのかを伝えると、AIの質が上がった。「人間のチームとAIチームで「同じだった」こと」に書いたが、WhyをAIに伝えると判断の精度が変わる。人間への指示と同じ原理だ。
採用・オンボーディング・評価という人事の基本フローが、そのままAI運用に使えることも気づいた（採用・オンボーディング・評価）。役割の明確化がなければAIも動けない。文脈を渡さなければAIも即戦力にならない。改善サイクルを回さなければAIも育たない。
さらには、「渡し先の偏り」という問題まで起きた（No.38）。優秀な人間に仕事が集まりすぎる「何でも屋問題」が、AIチームでも発生した。人間組織で起きることは、AI組織でも起きる。発見するたびに思った。「また同じだ」と。
これは最初に計画して始めた話ではない。
エンジニアがAIを使うとき、真っ先にやることは「正確に実行させること」だ。精度の高い命令、効率的なコード、再現性のある処理。それは正しいアプローチだ。
しかし、私のアプローチは違った。役割を定義し、価値観を渡し、なぜこの仕事をするのかを言語化した。それは、一般的にエンジニアがAIに対してやることではない。でも私にとっては、それがこれまでずっとやってきたことだった。
だから動いた、のかもしれない。
正直に言えば、この仮説はまだ検証の途中だ。
でも、組織を動かした経験のある人には、同じことが起きるのではないかと思っている。それはエンジニアか非エンジニアかに関係なく、「言語化を意識しているかどうか」の違いではないかと。
前の記事では、「まだ早い」の正体は「自分向けの情報に出会っていないこと」だと書いた。この記事は、その続きだ。
マネジメント経験者にとって、AIを動かせる素地は元々ある。必要なのは技術を覚えることではなく、すでに持っている言語化の力を、新しい相手に向けることだと思う。
お問い合わせ
ご意見・ご相談などありましたらお気軽にどうぞ。