早嶋です。5500文字。
APIの概念を、コンピュータから組織に持ち込むとどうなるだろうか？
APIとは Application Programming Interface の略称で、もともとはソフトウェア同士がやり取りするための「入り口と出口の取り決め」を指す。たとえば地図アプリに天気情報を組み込んだり、ネットショップがクレジットカード決済を外部サービスと連携したりするのは、APIを介して異なるシステム同士がつながっているからだ。
入口と出口のルールを共有することで、メーカーも言語も関係なく動く仕組みがAPIだ。つまり、中身の実装はブラックボックスでも、インターフェースが揃えば生態系が広がる、つまり汎用度が高くなる。これをそのまま人と仕事に適用すると、「人の頭の中（実装）」に依存せず、「入出力（判断条件・手順・成果物）」さえ合意できれば、誰がやっても一定の結果が出るという世界観が作れそうだ。属人化に悩む現場ほど、この視点が効くと思うのだ。
実際、企業の現場を見渡せば、形式知化されずに属人化が深まっている領域は少なくない。たとえば建設現場での設計や工程管理、プラント・エンジニアリングにおける見積もりや積算業務、あるいは法人営業での複雑な組織営業などは、その人の経験や勘に強く依存している。社員のベテラン化と高齢化が進めば進むほど、こうしたノウハウが次世代に引き継がれないリスクが現実味を帯びてくる。言語化や標準化が進まない企業ほど、「知っている人がいなくなれば途端に立ち行かなくなる」危うさを内包しているのだ。
ここでは、言語化されない状況を3つのパターンに分けて、それぞれの状況に対して打ち手を提案する。1つ目は、日常の仕事そのものが言語化を生む設計になっているかだ。次に、属人知を体系に落とすための棚卸しの型や習慣があるかだ。そして、3つ目は、資格や認定の仕組みを、現実のキャリア設計と噛み合わせて動機づけできているかだ。順に見ていこう。
（日常の仕事そのものの言語化を生む設計）
まず、日常の仕事そのものの言語化を生む設計についてだ。例えば、トヨタの改善提案は象徴的だ。現場の小さな気づきを毎日短く書く。上司がその場で評価し、良いものは標準作業に即反映し、さらに他ライン・他工場へ水平展開するのだ。提案は書かなければ次に進めない、つまり社員や従業員が必ず言語化して形式知として次の流れに活用させるのだ。結果として「仕事＝記録の更新」となり、確実にアップデートするようになっている。
Amazon は新規プロジェクトで、まず「プレスリリースとFAQ」を書くことから始めるそうだ。考えや概念を先に言葉にして、何が価値で、誰のためで、何ができないのかまで言語化する。IDEO はプロセスをストーリーボード化して共有する。そして、サイボウズは社内の意思決定をグループウェア上に開いたまま残す。GitHub 文化も同じで、変更は説明文とレビューを伴わないと統合されない。
これらに共通するのは、特別なナレッジ活動ではなく、普段のワークフローがそのまま言語化装置になっていることだ。だから日常の仕事の中で膨大な知見がナレッジとして蓄積されるのだ。そして、日常の習慣に組み入れることに成功したからこそ続くのだ。
トヨタの改善データベースの回り方は示唆が多い。現場で即時に試し、うまくいけば標準作業に昇格し、そこから水平展開する。溜まったものは教育資産にもなるし、分析すれば「どの工程に改善余地が集中しているか」「どの工場が強いか」といった経営の目にもなる。要するに、データベースは死蔵させないことがポイントだ。常に業務の中で使う前提で言語化し、使った結果でブラッシュアップするのだ。
私はこの仕組みを「ナレッジの Git 運用」と読んでいる。Gitとは、ソフトウェア開発で広く使われている分散型バージョン管理システムのことで、変更履歴をすべて記録し、誰がどこをどう修正したのかを追跡できる仕組みだ。さらに、複数人が同時に作業しても統合（マージ）でき、必要なら分岐（フォーク）させて独自に発展させることも可能だ。つまり、「知識や改善の履歴を残しながら進化させ、必要に応じて分岐・共有できる」運用スタイルを示す言葉として、Gitはとても相応しいのだ。
たとえば、現場から上がってくる改善提案は、ソフトウェア開発で言うところの プルリクエスト（Pull Request） に相当する。現場の小さな気づきを差し込み、既存の標準作業に変更を加える試みだからだ。それを受けた上司やリーダーの確認作業は、まさに コードレビュー のようなものである。提案の妥当性や安全性を確かめ、内容の筋が通っていれば、既存の標準作業書へと統合される。これはソフトウェアで言う マージ（merge） のプロセスだ。そして、そこで確立された標準は、他の工場や部署へと展開され、現場ごとに応用されていく。これはまさに フォーク（fork） に近い動きで、他拠点が同じ知識を引き取り、自分たちの環境に合わせて使い始める流れだ。
こうして見ていくと、改善活動を Git 的な運用になぞらえることは単なる言葉遊びではない。提案は履歴とともに記録され、改定理由が残り、承認プロセスを経て標準に反映される。そして、その標準は組織全体で再利用される。APIの概念が「入口と出口を定義することで、誰が呼び出しても同じ動きをする仕組み」だとすれば、この運用もまさにそれに重なる。改善という知識が、個人の暗黙知から「呼び出し可能な仕様」に変わり、組織全体で共有され、進化し続けるのだ。
（属人知を体系に落とすための棚卸しの型や習慣）
次に、すでに属人化が進んでいる現場で、どう棚卸しを始めるかだ。私は、ベテラン（あるいは、匠）が自分たちの活動を言語化することが出来ないと思っている。もし出来ていたら、既に世の中標準化されているのだ。そこで、ベテランにはこれまで通り仕事や作業をしてもらう。その代わり、ベテランの仕事を観察して逐一質問を投げかけ、事細かい行動や取り組みに対して言語化する役割をあてがうことが良いと思っている。この役割をナレッジエンジニアと称す。ナレッジエンジニアは、ベテランと一緒に仕事をして、ベテランを逐一観察するのだ。そして「今、なぜそれをした？」「次に進む判断の根拠は？」と問い続け、匠の思考や概念を逐一言語化するのだ。
ナレッジエンジニアがベテランの思考を言語化する際に、道具も使うと更に良い。単にペアでインタビューするだけではなく、ベテランの行動を動画で記録するのだ。また、インタビューのやり取りも録音する。これによってナレッジエンジニアがベテランの行動や仕事を言語化する仕組みも徐々に標準化されることが期待できる。
ベテランの頭の中にある暗黙知を引き出すには、本格的な認知工学の調査法を持ち込む必要はない。Applied Cognitive Task Analysis（熟練者の思考過程を分解して言語化する手法）や Critical Decision Method（具体的な事例をたどりながら判断の根拠を掘り出す手法）のような枠組みも、問いの型だけを借りれば十分だと思う。つまり、「なぜ今その作業をしたのか」「その判断の根拠は何か」「もし条件が違ったらどう動くか」といった素朴な質問を繰り返すだけで、ベテランが無意識に積み重ねてきた知恵をかなりの部分まで言語化できるからだ。
抽出した知恵は、長い文章のままでは回らない。私はそれらの体系化やプロセス化がポイントになると思う。仕事を小さなモジュールに分解し、目的、前提（入力）、手順、判定基準（合否の数値や状態）、例外分岐、使用ツールと安全、出力（記録様式）までを整理するのだ。これが蓄積することで、組織の API 仕様書になるのだ。
そして、平常時の手順は短く、例外対応は厚く、が基本設計だ。検証も忘れてはいけない。その仕様を新人やそのエリアの仕事の経験値が低い人材に渡し、実際に試してもらうのだ。そして、ここで再びナレッジエンジニアに登場してもらい、仕様の過不足を確認して、最終的に新人や経験値が低い人、つまり実際に試した人からのレビューを得るのだ。こうやって再現性を確認しながら標準化仕様に昇格させていく。
こうすることで、言語化できていない部分も蓄積される。勿論標準作業が整い始めた後の変更は、理由付きの改訂申請（プルリク）を徹底させる。これらの仕様が蓄積されたら、次はスキルマップと紐づけて、誰がどのレベルで教えられるかを可視化していく。
最後に、それぞれの仕様をベクトル検索に入れて「聞けば返る」ような、対話ボットにすることで、現場での参照性が飛躍的に向上するようになると思う。現場で活用するのであれば、キーボードで入力することも難しいだろうから、音声での入力にも対応するように初めから設計しておけば、リプライは画像の表示と音声でのフィードバックになり、使い勝手が良くなるだろう。
日常的に言語化されていない仕事は、時に、コンサル型の棚卸しが役立つ場面もある。マッキンゼーがやってきたのは、プロジェクトの知恵を使える単位で残す設計だ。案件ごとに「何の業界で、どんな課題を、どう解き、何が学びだったか」を Engagement Summary に落とす。汎用化できる手法は Toolkit 化して部品にするのだ。成果物は匿名化してアーカイブし、検索で引けるようにする。人のプロフィールも経験タグ（ケイパビリティマップ）として検索可能にする。MECE とピラミッド構造に従い、結論→要旨→詳細の順で残すから、後続がすぐに使えるようになる。これを現場の案件運営に移植すれば、建築現場や、インフラの保守メンテナンスの現場、設計や企画の現場などにも一定の効果を出す可能性は高い。更に、案件の事の仕様書を作るつもりでまとめ、例外と失敗も含めて要件化しておけば、次のチームはゼロから始めなくて済むようになるのだ。
ここまでの取り組みができるようになれば、1つ目の事例のように、その取組を日常にインストールするのだ。そうすることで、通常の仕事が進む範囲で作業や思考などのナレッジが常にデータベースに落ちるようにすることが可能なのだ。
（資格や認定の仕組みを現実のキャリア設計と噛み合わせる）
資格の話に移ろう。業界によっては資格が権限の保管庫になり、資格の有無だけが論点になっていることを観察する。しかし、資格を取得する人材には仕事が集中して他の無資格保持者よりも仕事が忙しくなるケースが観察される。そのような組織は、資格を取得すること＝罰ゲームのように捉えることさえある。一方で、一定のステージで資格を保持することが本人の成長の証で、資格を持たない者よりも当然に高い目線でみられる仕組みを有する組織もある。
後者は、評価と運用の設計が異なるのだ。資格取得を給与テーブルや昇進に直結させるのは当然として、資格に関わる学習時間と受験対策を業務時間内に組み込んでいることが多い。勿論、教材や模試は会社負担だ。取得者コミュニティを用意し、ロールモデルを可視化する。資格そのものは、社外でも通用するバッジとして見せ、社内ブランド（当社の○％が●●の資格保有）という具合に活用する。そして、何より大切なのは、「資格保有者＝お前しかできない仕事」にしない設計を考えることだ。取得者は標準のレビュワーや教育者という役割を担い、実務と育成の仕事を分散させるのだ。結果として、資格保持者は代替可能性の向上に効くようになる。ここを履き違えると、若手は逃げだしたい職場になるのだ。
では、資格と評価がまったく連動していない会社はどう動くべきかを考える。私は、三択（現状維持／手当／持たない人の減額）ではなく、第四の道を取るべきだと思う。それは、資格をキャリアの可視化に組み込むのだ。具体的には、職務グレードごとに担当できる仕事をある程度を定義する。そして、その一部に資格を要件として紐づける。要件や資格の習得は、通常の業務フローの中に設計して、合格後は上位の仕事と報酬が手に入る。合わせて、その仕組のメンテナンスと後輩の始動にも紐づけるのだ。評価や資格は単に保有することでは意味がない。あくまでも、使って組織の再現性を上げる際に価値が出る。そう、仕事上の仕組みに入れ込むことで、取らない人の減額というネガティブな圧力に頼らず、自然と上を目指す文化ができると思うのだ。
（まとめ）
企業の規模や業種にかかわらず、属人知を言語化する課題はどこにでも存在する。製造や建設の現場でも、営業や企画の仕事でも、経験や勘に依存したやり方が長く続けば、いずれ継承リスクに直面する。だからこそ、私はこの取り組みを三つの階層に整理して考えることを提案した。
第一に、日常業務そのものが言語化を生むようにワークフローを組み替えること。改善提案や記録の習慣を業務の必須手順に組み込めば、自然に知識は残っていく。
第二に、ベテランの暗黙知を体系に落とすために、観察や問いかけを通じて言語化し、Pull Request のように改定とレビューを繰り返す仕組みをつくる。
第三に、資格や認定の仕組みをキャリア設計と噛み合わせ、取得後は知識を独占するのではなく分配役になるよう設計することだ。
この三層の設計を踏めば、どの業界でもナレッジの再現性と持続性を高められると思う。
