拓海先生、最近部下から「手続きのナレッジを可視化するべきだ」と言われまして。うちの現場は経験頼みで、暗黙知が多いんです。要するに、論文で言うところの手続き知識ってどう役に立つんですか？
素晴らしい着眼点ですね！大丈夫、整備すれば現場の属人化を減らし、初心者でも高い品質を出せるようになりますよ。まず結論を三行で言うと、1) 手続き知識を構造化すると再現性が上がる、2) 実行の履歴が取れると改善サイクルが回る、3) ツールと組み合わせることで現場の学習を支援できる、ということです。
それはありがたい説明です。ただ、うちの現場だと手順書はあるけれど、現場のやり方と違っていることが多いんです。これまで通りのやり方を変えさせるのは投資対効果が不明でして。
確かにそこが肝ですね。投資対効果を示すには、まず現状の差分を可視化することが先決です。手順の“形式”をオントロジーとして表現し、実際の実行ログと突き合わせることで、どの手順に時間がかかり、どの手順が頻繁に逸脱されるかを定量化できます。要点は三つ、可視化、定量化、改善の順で動くことです。
これって要するに、手順をデータとして整理してから機械に見せると、どこにムダがあるか分かるということですか？
正解です！まさにその通りですよ。もう少し正確に言うと、論文の提案は手続き（Procedure）とその実行（ProcedureExecution）を構造化するための枠組みを作ることにあります。これにより、個々のステップ（Step）ごとの実行状況やフィードバックまでトラッキングできるようになるんです。
トラッキングするには現場に何かセンサーを付けたり、作業者に入力させないとダメですよね。現場は高齢層も多いし、そこが心配です。
それも想定内ですよ。論文では、専門家が使いやすいWebフォームを用意して、段階的に情報を入力できる仕組みを示しています。現場には最初は少ない負荷でデータを取らせ、徐々に自動化（センサーや音声入力）へ移すのが現実的です。ポイントは最初から全部をやろうとしないことです。
先生、用語が少し難しいので確認させてください。ProcedureExecutionとかStepExecutionとかは、要するに「いつ誰がその手順をやったか」を記録するための単位という理解でよろしいですか？
その通りです！ProcedureExecutionは手順全体の実行記録で、StepExecutionは各ステップの実行記録です。加えて、UserFeedbackOccurrenceは作業者が残すフィードバック、UserQuestionOccurrenceは作業中に生まれた疑問を記録するための項目です。これらを結び付けると、現場の「なぜ」を辿れるようになりますよ。
なるほど。最後に一つだけ。うちのような中小企業が取り組む順序として、まず何をすれば一番効果が見えやすいでしょうか。
良い質問ですね。結論を三つで示します。第一に、頻繁に問題が起きる業務一つを選んで、手順の構造化から始めること。第二に、その業務の実行ログ（誰が、いつ、どれくらい時間をかけたか）を取り、可視化すること。第三に、そのデータをもとに改善仮説を立て、短いサイクルで試すこと。これで早期に効果を示せますよ。大丈夫、一緒にやれば必ずできますよ。
分かりました。要するに、手順をきちんと型にして実行記録を取り、問題点を数値で示してから改善するという流れですね。まずは一業務から始めて、効果が出たら横展開する。私の言葉で整理するとそんな感じです。
