ネーミングや共通認識の重要性を改めて見つめ直したい。

ネーミングと共通認識から、IT部門の仕事を考える

あくまでも素人の考えであり、既存の論文の理解も生成AIの力を借りており、間違いを含む可能性があります。研究で示されていることと、そこから私が考えたことは、できるだけ分けて書いています。

例えば、MicrosoftのCopilot Studioをどうするかについて議論をしたいとする。

ある人は、以前触ったときの印象から「チャットbotが作れるやつね」と思うかもしれない。ある人は「Copilotのライセンスで使えるものだと思っていた」と言うかもしれない。またある人は「どの機能を、誰が、どう使う話なのか。課金や他サービスとの役割分担も含めて、まずはそこから整理しないと」と思うかもしれない。

これは製品仕様の説明ではなく、会議に持ち込まれる認識の例である。全員が「Copilot Studio」という同じ言葉を使っているのに、頭の中にあるものは違う。

誰もが事細かに理解する必要はない。担当者と管理職と現場の利用者では、必要な知識も違う。ただ、何を論点にして、何と何を比較して、今日は何を決めるのか。その前提が揃っていないと、議論が始まらない。

変化が激しい今の時代において、この「議論を始められる状態にする」という仕事が、とても難しくなっていると感じる。

しかも、会議をして揉めるなら、まだ問題が見えている。そもそも何を相談すればいいか分からず、議論が始まらないこともあるのではないか。一部の詳しいユーザーから問い合わせが来て、その都度対応する。その対応自体は必要でも、個別の判断が積み上がった結果、組織全体として何を目指しているのか分からなくなってしまう。

その間に、始められたはずの仕事を始められずにいるかもしれない。ただ、何も始まっていないので、機会を逃したことすら表面化しにくい。そして失敗をすることもなく、そこから学ぶこともない。

では、どういう状態になっていればいいのだろうか。

私は、関係者が過剰な労力を消費せずに建設的な議論を行い、後から見直してもいいので、必要なタイミングで意思決定できることだと思う。そして、決まった後は、自分たちが何をしているのかを毎回確認し直さずに仕事ができることだ。

そのために、意外と侮れないのがネーミングと、仕事をちゃんと定義することなのではないか。始めるときは理解していても、1か月後は誰も思い出せない。思い出せないものは評価できない。評価できないものは学習に繋げることができない。限りある人生の時間を使うのであれば、失敗ももれなく有効活用したいではないか。

サービスの名前は、提供する側の仕事でもある

英国政府のService Manualに「Naming your service」というページがある。利用者が使う言葉を選び、何をするサービスなのかが伝わる名前にする、という考え方が示されている。

例えば、次のような名称が紹介されている。

後者については、利用者と裁判所職員への調査で、旧名が混乱を招き、サービスを理解しにくくし、提供コストを高めていたと記録されている。具体的な削減額までは示されていないが、名前による混乱を、提供する側が改善する問題として扱っている。英国政府「Naming your service」

私はここが大事だと思った。

詳しい人からすれば、正式な名称を書いてあるのだから、調べれば分かるでしょうと思うかもしれない。しかし、その名前を見た人が何のことか分からず、毎回説明が必要になるなら、その負荷はどこかで誰かが引き受けている。

社内の会議名も同じだと思う。「打ち合わせ」だけでは、何を準備して参加すればいいか分からない。「生成AIサービスの利用方針を決める」とあれば、少なくとも何のために集まるかは見える。そこに、今回決めることと事前に見ておくものがあれば、話を始めやすくなる。

もちろん、名前に全部を詰め込めばいいわけではない。名前で入口を作り、その先に短い説明を置けばいい。

「この資料は何のためのものか」「この会議では何を決めるのか」。それを受け取る側に推測させ続けないことも、仕事の一部なのだと思う。

名前は、受け取り方にも影響する

名前が変わると、人の行動まで変わることがあるらしい。

Libermanらの「The Name of the Game」という研究では、囚人のジレンマの実験で、ゲームの名前を「Wall Street Game」「Community Game」などに変えている。同じ利得構造でも、付けられた名前によって、協力するかどうかの選択に差が生じたという。Liberman, Samuels & Ross（2004）

これは、分かりやすい名前を付ければプロジェクトが成功する、という実験ではない。ただ、名前が「ここはどういう場なのか」を受け取る手掛かりになり、行動にも関わり得るという点は興味深い。

例えば、「AIツール導入」と「現場の調査業務を短縮する」では、同じツールを扱っていても、検討の中心が変わりそうだ。前者なら、ツールを入れることがゴールになってしまうかもしれない。後者なら、そもそも何に時間がかかっているのか、導入して本当に短縮できるのか、という話になるだろう。

これは私の考えだが、名前を考える行為には、自分たちが何をしようとしているのかを問い直す効果があると思う。そしてこれは、上役の仕事でもあると思う。現場の担当者は視野が狭い。なぜなら経験が浅く、担当している業務で手いっぱいだからだ。担当者が自分の与えられた仕事に全力で取り組んだとしても、そもそものゴール設定が間違っていたら、あまり意味のない仕事になってしまう。山口周さんの「コンテキスト・リーダーシップ」でも、こんなことが書かれていた。

ワイクの理論の中核には「行為が理解を生み出す（Enactment）」という考えがあります。状況は受動的に観察するだけでは捉えられず、行動によって初めてその輪郭が浮かび上がります。行動と学習を結びつけるこの対話の繰り返しによって、組織全体のコンテキスト理解は徐々に揃っていきます。 　観察・解釈・行動の三つのステップは、単なる作業手順ではなく、リーダーとメンバーが対話を通じて共通の物語を育てるための循環です。この循環を意識的に回し続けることが、組織におけるコンテキストの共有を可能にするのです。 　言い換えれば、リーダーとは単なる意思決定者ではなく、「意味を作る存在＝Sence Maker」であるべきだ、ということです。

出典：山口周『コンテキスト・リーダーシップ 「最高の上司」と「最悪の上司」は文脈で決まる』（光文社新書）、Kindle版、pp. 42–43。

つまりネーミングにおいて、リーダーはそこに自分が作った意味を載せるという大きな仕事がある。それをやらずして、担当者の成果を判断するのは本当に可能なのだろうか。

そして、仕事ではもう一つのパターンがある。そもそも名前も定義もないまま、ぬるっと始まることだ。

我々は、一体何をしているのか

とりあえず集まる。とりあえず調べる。次回も話す。

そうしているうちに、定例会議だけが続いていく。これはいつからいつまでやるのか。何ができたら終わりなのか。誰が決めるのか。関係者は誰なのか。よく分からないが、何となく仕事として存在している。10人を超えるオンライン会議に何の意味があるのだろうか。

こういうことは、日常茶飯事なのではないだろうか。

例えば旅人が目的地にたどり着くためには、何が必要だろうか。地図や目的地、コンパスだけで十分だろうか。たとえ地図を持っていても、自分が今どこにいるか分からなければ、どっちに進めばいいかすらわからない。

仕事も同じではないだろうか。目的地は何を達成したいか、現在地は何ができていて何がまだ分からないか。そこを押さえて初めて、次に何をするかを考えられる。誰と、いつまでにたどり着くのかも決まっていれば、進み方を相談しやすい。

途中で道が変わったら、地図も予定も見直せばいい。そのためにも、まずは今の現在地と目的地を共有しておきたい。

だから私は、少なくとも次のことを定義したいと思っている。

• 名前：関係者が同じ仕事を指して使える名前は何か。
• 目的と範囲：何のために、何をするのか。今回はどこまで扱うのか。
• 終了条件：何が決まる、あるいは何ができたら、この仕事は終わるのか。
• 関係者と役割：誰が進め、誰が決め、誰に相談し、誰に共有するのか。
• 開始日と終了日：いつ始めて、いつまでに何をするのか。

書いてみると、バカみたいに基本的なことだ。

ただ、これが揃っているだけで、「それは今回やることだっけ」「誰に決めてもらえばいいんだっけ」「この調査はいつまで続けるんだっけ」に戻る場所ができる。

最初から全部を確定できないこともある。その場合は、仮の期限を置くとか、まずは範囲を決めるための調査期間にするとか、未定の部分をいつ誰が決めるかを書いておけばいいと思う。

変わることを前提にしていても、その時点での定義は持てる。今の考えが書かれていれば、後から何が変わったかも話せる。

定義すると、仕事の重複も見えてくる

例えば、AI戦略、エージェント検討、市民開発検討。この三つは、完全に別々の仕事なのだろうか。

名前だけを見ると別の活動に見えるが、対象となる利用者やサービス、決めるべき方針を並べてみると、かなり重なるかもしれない。

ここで定義することの意味が出てくる。

「これには上位の施策があるから、そこにつなげて進めよう」「この二つは同じことを調べているから、一緒にやろう」「利用方針を先に決めないと、個別サービスの比較をしても決まらない」。そういう順序や関係を考えられるようになる。

そもそもこれは何をしようとしているのか。定義するという行為は、無秩序に仕事を増やす前に、そのワンテンポを作ることでもあると思う。

最近、私はプロジェクトの情報を記録できるSharePointのリストと、そのプロジェクトを参照するLookup列を持ったドキュメントライブラリを整備した。

資料を見たときに、何のプロジェクトのものかをたどれるようにしたかったからだ。プロジェクトの目的や関係者と、実際に作っている資料がつながっていれば、途中から参加する人も状況をつかみやすいのではないかと思っている。

フレームワークをチームに馴染ませるために、普段使う仕組みに組み込んでしまう。これも一つの方法なのだと思う。「入力が仕事になっちゃうんじゃないですか？」という、賢そうな発言（人は肯定よりも、否定的な発言をする人の方が頭が良さそうと認識するらしい）が出たとする。

回答はただ一つだ「仕事だよ。」

もちろん、使われない項目を入力させるのは無駄である。しかし、後から目的や関係者を確認できるように情報を残すことは必要だ。それを残さなかったために、後から複数人が何度も確認し、説明し、調べ直すことまで考えると、どちらが効率的か賢い人ならご理解いただけるのではないだろうか。

プライベートで作ってみたときのXへの投稿。

共通認識を揃える時間は、無駄なのか

そうは言っても、そこまで整理する時間がもったいない、と思うこともある。

ここで参考になったのが、Shared Mental Model、共有メンタルモデルの研究だった。

DeChurchとMesmer-Magnusによる2010年のメタ分析では、23の独立研究を統合し、共有メンタルモデルとチームの活動過程・成果との関係を調べている。共有メンタルモデルはチームの成果と正の関係にあり、チームの活動過程との関係では、知識の構造やつながりを捉える測定が重要だった。DeChurch & Mesmer-Magnus（2010）

私がここから考えたのは、共通認識として揃えたいものは何か、ということだ。

例えば、全員がエージェントという単語を知っていても、誰が作り、誰が使い、誰が管理し、どこで費用が発生するのか。その関係を違って捉えていれば、判断は噛み合わない。

プロジェクトでも同じだと思う。我々は何のためにこれをやっているのか。自分の作業は、他の人の仕事とどうつながるのか。何を優先し、どこで誰の判断が必要なのか。協働に必要な範囲で、その見取り図を共有したい。

もちろん、この研究が、名前や開始日・終了日を決めることの効果を直接証明しているわけではない。共通理解と成果の関係を、名前を付けるだけの効果に置き換えることはできない。

当然、認識合わせにも時間はかかる。ただ、その時間を省いた結果、後から複数の人が調べ直し、説明し直し、作り直していたら、全体ではどちらが高くつくだろうか。

最初の資料を作る人の負荷だけでなく、それを受け取って動く人まで含めて考えたい。共通認識を作る作業を、ただの事務作業として片付けてしまうのはもったいないと感じる。

「分かっているつもり」を、少し減らす

もう一つ、Common Groundという考え方がある。

Clarkらは、人が会話を進めるときに土台とする、互いに共有しているとみなす知識や前提、そして理解を確かめ合う過程を論じている。Clark & Brennan（1991）「Grounding in Communication」

仕事に引き寄せると、「ここまでは相手も分かっているだろう」と思って話していたら、実はそこが違っていた、ということだと思う。

「この件を進めてください」と言った人は調査のつもりで、受け取った人は導入まで進めるつもりかもしれない。「方針を決める会議」のつもりで参加したら、他の人は情報共有だけのつもりかもしれない。

こうしたずれを毎回、仕事が進んだ後に見つけるのはしんどい。

では、どうやって「分かっているつもり」を減らすのか。ここで私は、文書に残すことが必要だと思う。

一人ひとりに聞けば、たどたどしくても一応それっぽい回答が返ってくる。それだけで、同じ理解をしていると言えるのだろうか。「この資料で言っているエージェントは、こういう意味です」と、まずは目に見える形にしたい。

そのうえで、「今回やるのはここまで」「この判断はこの人にお願いする」と、実際の仕事に当てはめて確かめる。書いてあるものを一緒に見れば、どこが違うのかを指して話せる。文書を置いただけで共通認識ができるわけではないが、確認するための足場にはなると思う。

バカみたいだが、関係者が入れ替わったり、一時的にアサインされた人が入ってきたりしたときにも、この足場があるかどうかは大きい。誰かの頭の中にしかない前提を毎回聞き出すより、参照できる形で残しておくほうが、一定レベルの仕事を続けやすいのではないだろうか。

この辺りは、宇田川元一さんの『他者と働く──「わかりあえなさ」から始める組織論』で書かれているナラティヴ・アプローチで説明ができるかもしれない。

IT部門が、議論を始められる状態を作る

私は、こうしたことをIT部門が率先してやる意味は大きいと思っている。

特に気になるのは、議論が始まらないことのリスクだ。

何かを導入して問題が起きれば、報告も振り返りもある。ところが、何を相談すればいいか分からず、検討にすら上がらなかった仕事はどうだろうか。報告する案件になっていないのだから、誰の目にも留まらないままかもしれない。

「問題は起きていません」の陰で、改善できたかもしれない業務や、試せば学べたかもしれないことが、そのままになっている。私は、こういう状態も気にしたい。

もちろん、検討しなかった案が全部有望だったとは言えない。ただ、検討したうえで「今はやらない」と決めたのか、前提を整理できずに議論が始まらなかったのか。この違いは見えるようにしておきたい。

新しいサービスが出る。名前が変わる。機能が増える。利用条件が変わる。そのたびに、現場の利用者や上司がそれぞれ調べて、違いを整理し直すのは大変だ。

そこでIT部門が「公式資料はこちらです」と渡すだけだと、情報は共有できても、判断するための前提が揃ったとは限らない。

このサービスは何をするものなのか。既存のサービスとどう違うのか。社内では何に使うことを想定しているのか。今回、誰に何を決めてほしいのか。

その整理を、まずIT部門が引き受ける。技術や契約の細かな比較をしたうえで、関係者が自分の立場で判断できる形にする。

例えば、「Copilot Studioについて相談」では話が広すぎるかもしれない。「社内問い合わせを支援するエージェントの試行範囲を決めたい」とすれば、対象業務、利用者、扱う情報、費用、運用責任者といった論点に進みやすくなる。

現場には業務の必要性を、予算を持つ人には費用と優先順位を、運用する人には管理方法を判断してもらう。それぞれに必要な情報と、判断のつながりを整理することも、IT部門の仕事なのではないだろうか。

そして、自分たちが持つプロジェクトについても、同じように名前、目的、関係者、期限を明らかにしておく。何を検討していて、何が決まっていて、何がまだ決まっていないのかが見えれば、周囲も動きやすい。

変化が速いからこそ、全部を理解してからでないと進めない状態はつらい。いま分かっていることと未確認のことを整理し、誰がいつまでに確認するかを決め、その時点でできる判断をする。必要になったら見直す。

そのための前提を用意できれば、IT部門自身が変化への対応を止めるボトルネックにならずに済むのではないか。

さらに、同じ説明を担当者が何度も繰り返す状態も減らしたい。必要な情報がプロジェクトやサービスにひも付き、参照できるようになっていれば、毎回詳しい人を捕まえなくても進められることが増えるはずだ。

当たり前のことを、ちゃんとやって楽にしたい

結局、言いたいことはとても陳腐なことだ。

仕事に名前を付ける。何をするものなのかを一文で書く。関係者と役割を決める。開始日と終了日を置く。何ができたら終わるのかを考える。そして、それを関係者で共有する。

そんなの当たり前でしょう、と思う。でも、当たり前のことを当たり前にやるのが、難しい。そして、当たり前すぎて侮られる。

毎回「これは何の話でしたっけ」から始めなくてよくなれば、その分、決めるべきことに時間を使える。「誰に聞けばいいんだっけ」「どこまでやるんだっけ」で止まる回数が減れば、その分、迷わず手を動かせる。

名前を付けて、仕事を定義する。たったそれだけに見えることが、正しい意思決定や、無駄に疲れずに仕事を進めるための土台になるのではないか。

IT部門が率先して、そこを丁寧にやっていきたい。Outlook カレンダーを会議で埋め尽くすゲームをしている場合ではない。

変化が激しくて、覚えることも考えることも多すぎる。だからこそ、同じ前提の確認に何度も労力を使わずに済むようにしたい。

バカみたいに基本的だけど、そこをちゃんとやって、もう少し負荷を減らして仕事をしていこうぜ、と思う。

そして、ええ感じのネーミングをつけるために本質を理解することや、若干のカリスマ性を含んだ芯を食った発言ができるようになりたい。

私は「自分の発言は芯食ってないなあ」と思うことが多々あります笑

参考文献

• Government Digital Service. Naming your service — Service Manual.
• Liberman, V., Samuels, S. M., & Ross, L. (2004). The Name of the Game: Predictive Power of Reputations versus Situational Labels in Determining Prisoner’s Dilemma Game Moves. Personality and Social Psychology Bulletin, 30(9), 1175–1185.
• DeChurch, L. A., & Mesmer-Magnus, J. R. (2010). Measuring Shared Team Mental Models: A Meta-Analysis. Group Dynamics: Theory, Research, and Practice, 14(1), 1–14. DOI
• Clark, H. H., & Brennan, S. E. (1991). Grounding in Communication. In L. B. Resnick, J. M. Levine, & S. D. Teasley (Eds.), Perspectives on Socially Shared Cognition, 127–149.