行動・結果・蓄積：一つの仕事を組織能力につなげるには

一つの仕事がうまく終わると、チームはその手順を書き残し、次も同じように進めようとします。ところが、しばらくして同じ問題に出会うと、資料は残っているのに、また以前の担当者を探し始めます。

何が足りないのでしょうか。

私は、もう少し掘り下げて考える必要があると思います。あのとき、なぜうまくいったのか。どのやり方なら、もう一度試す価値があるのか。ほかの人にも使えるのか。そして、使った後は誰が確認するのか。これらがつながって初めて、一度の仕事で得た経験が、その後の組織を支える力になり得ます。

「行動・結果・蓄積」を、考える際の軸にできます。何を残すかは、選択と検証を経て決める必要があります。残した後も、継続して見直す人が必要です。

一、何が起きたかを確認してから、何を残すかを考える

仕事が終わったら、まず三つに分けて考えます。

行動とは、実際に何をしたかです。誰が、どのような条件で、どの資料や資源を使い、どんな手順を取り、例外にどう対応したのかを確かめます。

結果とは、何が変わったかです。成果物は要件を満たしたか。次の工程は仕事を続けられるか。どれだけの時間と費用がかかったか。未完了の責任は何か。顧客や経済的成果に関わる仕事では、対応する業績チェーンに戻り、ニーズ、受注、契約履行、代金回収などの結果も確認します。

蓄積とは、何を次の仕事に生かす価値があるかです。より明確な判断ルールかもしれません。繰り返し使える方法かもしれません。避けるべき条件が分かった、という場合もあります。

この三つは、そのまま同じ意味にはできません。顧客が一度の見積もりを受け入れた背景には、需要の切迫、競争条件、それまでの関係があるかもしれません。責任者がその場で資源を融通し、納品を間に合わせたとしても、それだけで従来のプロセスが信頼できるとはいえません。

一方、失敗から役立つ知見が残ることもあります。特定の供給条件では従来の納期を約束できない。ある資料が欠けているときは、いったん止まって確認すべきだ。こうした知見です。ただし、事実を確認し、どの状況に当てはまるかを残す必要があります。一つの説明を、急いで一般的な結論にしないことです。

業績が期待に届かない場合は、まず業績チェーンのどこに問題があるかを探し、その上で、どの階層の仕事を変えるかを決めます。チェックリストの追加や行動の細分化も、実際の問題に対応してこそ取り組む価値があります。

二、一つの経験を四つの状態に分けて見る

実務で判断しやすくするために、経験を次の四つの状態に分けて記録することを提案します。これは本稿で提案する使い方です。状態の名前を付けただけで、検証が済んだことにはなりません。

一つ前の状態から次へ進むには、新たな根拠が必要です。ファイルをアップロードした、研修を実施したという理由だけで、組織がすでに身に付けた能力として扱うことはできません。

特に注意したい場合があります。「方法」と呼んでいても、実際には、以前の熟練者が多くの判断を補っている場合です。試行中はその人が横で助言し続けるので、結果はよく見えます。しかし、その人がいなくなると仕事が進まなくなります。この場合は、必要な経験的判断を明らかにし、訓練、補助ツール、例外対応の支援を用意します。それでも熟練者の関与が必要な範囲は、正直に残しておきます。

組織能力ができたかどうかは、実際の仕事に戻って確かめます。記録、プロセス、ツール、訓練はその支えになります。その上で、定めた条件の下でチームが仕事を継続して完了し、例外にも対応できるかを検証する必要があります。

横にスクロールするか、図を大きく開いて確認できます。

図を大きく開く ↗編集可能な SVG をダウンロード ↓

三、振り返りの判断を、試せるやり方に書き換える

振り返りで「次は早めに連絡する」と言っても、次回に実行するのは難しいままです。いつなら早めといえるのか。誰に連絡するのか。何を確認するのか。意見が分かれたら誰に判断を委ねるのか。まだ明らかになっていないからです。

試す価値がある経験については、少なくとも六つを説明できるようにします。

1. 問題と状況：どの種類の仕事で、どんな問題が繰り返されるのか。どの条件が判断を変えるのか。
2. 根拠と説明：何を記録したか。何がまだ不確かか。なぜこの変更が役立つ可能性があると考えるのか。
3. 採用を検討するやり方：どの条件から始め、具体的に何をし、何を渡し、どう完了を判断するのか。
4. 例外と適用限界：そのまま使えないのはどんな場合か。いつ中断し、誰に対応を委ねるのか。
5. 試行の計画：誰が、どの範囲で試すのか。誰が資源を用意し、いつ再確認するのか。
6. 観察の方法：何の改善を期待し、どう比較するのか。どのような追加の費用や影響にも注意するのか。

長い資料にする必要はありません。引き継ぐ人が理解して試せること、確認する人が根拠をたどれれば、まず始められます。

ここでは、PDSA（Plan–Do–Study–Act：計画・実行・検討・行動）の学習の考え方を参考にできます。Deming Institute の PDSA の説明では、実際の結果と予測を比較し、それを基に、やり方や当初の説明を修正できることが重視されています。[1] IHI の試行ガイドはさらに、実行可能な小さな範囲から始め、意図しなかった影響を観察し、異なる条件でも検証を重ねることを提案しています。改善につながらない方法は、試行を止めることもできます。[2]

これらの資料は試行を設計する際の参考になりますが、本稿の方法が各種の企業で効果を上げたと証明するものではありません。どの程度の検証が必要かは、それぞれの事業と、失敗した場合の代償に応じて決める必要があります。

四、「見積もり前に納期を確認する」で試してみる

以下は操作方法を説明するための架空の例です。対応する企業の効果測定データはありません。

ある設備サービスのチームが、顧客の指定時刻までに提案を提出できました。後から確認すると、最終的な納期は責任者がその場で調整したものでした。営業担当者が見積もりを準備していた時点では、供給パートナーが以前に示した参考日程しか持っていませんでした。

今回の結果は確認できますが、やり方にはまだ疑問が残ります。「責任者が調整する」を毎回の必須プロセスにすれば、責任者の判断待ちが新たな滞留箇所になります。供給条件も、毎回調整を許すとは限りません。

まず、小さな改善仮説を立てられます。納期を約束する必要がある受注仕様品について、見積もり前に今回の供給条件を確認する。その際、確認日、有効な範囲、未解決事項を明示する。そうすれば、その後の納期変更を減らせるかもしれません。

次に、試行の計画を具体化します。

試行の前には、何をどう比較するかも決めます。注文の種類、複雑さ、供給条件に大きな違いがある場合、前後の変化をすべてこの確認記録の効果とすることはできません。案件数が少ない場合も、しばらく問題が再発しなかっただけで、検証済みとはいえません。

「何回成功したら標準として定着させてよい」という共通の回数はありません。影響する範囲が大きいほど、失敗した場合に取り返しにくいほど、確認と試行を十分に行う必要があります。実際の業務で試行錯誤できない条件もあります。その場合は、過去の仕事、模擬的な状況、専門的なレビューを使い、先に検証できます。

この例で残そうとしているのは、範囲を限定し、その後も確認を続けられるやり方です。受注や経済的成果の改善につながるかどうかは、顧客ニーズ、価格、競争条件なども合わせて観察し続ける必要があります。

五、問題の性質に応じて、何として残すかを決める

試行結果がそのやり方を支持したら、次はどのような形で残すかを決めます。

こう分けるのは、使いやすくするためです。実際の文書は事業の必要に合わせて構成できます。単純な問題なら、説明の一文や帳票の一項目を直すだけで済むかもしれません。権限や責任を変える場合には、対応する権限に基づく決定が必要です。すべての経験を制度にする必要はありません。

採用を決めたやり方は、実際に使う場所に置きます。対応する標準作業手順（SOP）、価値創出に貢献する役割の業務マニュアル、研修の演習、補助ツールなどです。使用者には、どこから始め、どんな場合に参照するのかが分かるようにします。

AI は、記録の集約、版の比較、手順の整理、抜け漏れの確認を手伝えます。事実、適用条件、採用するかどうかの判断は、業務を理解し、対応する責任を持つ人が確認する必要があります。AI の実行ガイド（Skill）にする内容は、安定した方法を基礎に設計を進め、入力、出力、適用限界、人による受入確認の要件を明確にします。

六、現行版には保守する人が必要で、中止も選べるようにする

採用した後に抜けやすいのが、その後の運用です。

現行の方法には、少なくとも、適用範囲、版と発効日、保守責任、関連する業務での参照先、次の再確認時期またはきっかけとなる条件を明記することを提案します。業務条件の変化、同じ例外の繰り返し、負担の明らかな増加は、予定を早めて再確認する理由になります。

再確認の後は、三つの判断ができます。

使い続ける：現在の根拠が、従来の範囲での使用を引き続き支持している。確認記録を残し、次の確認予定を明確にします。

修正して再試行する：解決すべき問題は残っているが、条件、手順、例外対応を調整する必要がある。新版は、まず試行範囲を明示し、検証の後に採用するかを決めます。移行期間中は、どの仕事でどの版を使うかをはっきりさせます。

使用を中止する：期待した改善が得られない、追加の負担を受け入れられない、適用条件がなくなった、といった場合です。日常業務の参照先から外し、中止理由と発効時点を明示して、影響を受ける役割の人に知らせます。引き続き対応が必要な仕事には、代替方法や上位の判断者に委ねる経路を用意します。

旧版は、当時の根拠をたどれるよう、実際の管理上の必要に応じて保存できます。保存先では失効したことを明示し、過去の資料が再び現行の要件として扱われないようにします。すでに行った約束や、すでに生じている責任については、別途引き継ぎを手配する必要があります。文書の使用中止とともになくなるものではありません。

横にスクロールするか、図を大きく開いて確認できます。

図を大きく開く ↗編集可能な SVG をダウンロード ↓

七、誰が経験を日常業務に戻すのか

資源、運営・管理、顧客、資本という四つのエコシステムでは、さまざまな役割の人が、自ら改善を提案することも、実際の要望に応えることもあります。誰が、どのように参加するかは、具体的な業務に即して明らかにします。

実行や協働を担う役割の人は、実際の作業、困難、例外を説明します。成果を受け取る役割の人は、その成果物を次の仕事で使いやすいかを確かめます。顧客やパートナーの意見は、変更が組織の外に与える影響を把握する手がかりになります。少数精鋭の運営・管理チームは、対応する意思決定、ルール、資源の手配と、価値の生産、販売チャネル、顧客関係の間の調整を担います。専門知識が必要な場合は、適切な人による確認を手配します。

保守担当者は、情報の整理、試行のフォロー、更新の推進を担当できます。ただし、一人で全員の役割に代わって判断することはできません。ある変更で内部の仕事が減っても、顧客の記入やパートナーの確認の負担が増えるなら、それも再確認の対象に含めます。

貢献の記録も残せます。誰が問題を見つけ、誰が根拠を提供し、誰が試行に参加し、誰が有効な改善を実現したかです。評価や権益に関わる場合は、実際の業務について事前に明確にした制度に従って扱います。経験を記録しただけで、特定の権益が自動的に生じるわけではなく、収益を約束するものでもありません。

米国 GAO は、2002 年の NASA の経験学習の仕組みに関する調査で、経験を収集・共有する手順があっても、それが後続の任務に活用される保証にはならないと指摘しました。[3] これは特定の時期の歴史的な調査ですが、経験のデータベースを整備することと、実際に使われることは、分けて確かめる必要があると教えてくれます。

そのため、蓄積を確認するときは、残した文書の数を見るだけでなく、実際の仕事を一つ取り上げます。使用者は現行のやり方を見つけられたか。適用条件を理解していたか。仕事を完了できたか。例外が生じた後、保守や意思決定の工程に戻せたかを確かめます。

まずは、繰り返し起き、影響がはっきりした問題を一つ選んで始められます。今回の事実を確認し、範囲を定めた変更を提案する。適切な人に試してもらい、その後に判断する。次の仕事に何を使えるか、どこにはまだ人の判断が必要か、どのやり方を取り下げるべきか。それぞれに、明確な答えを残します。

参考資料

1. The W. Edwards Deming Institute：PDSA Cycle。予測、観察、説明の修正の関係を示す資料として参照しています。本稿の四つの状態と六つの記録項目は、本稿で提案する方法です。
2. Institute for Healthcare Improvement：Testing Changes。質改善の方法に関する資料です。本稿では、小さな範囲での試行、異なる条件での検証、効果のない試行を止めるという考え方を参考にしています。
3. U.S. GAO：NASA — Better Mechanisms Needed for Sharing Lessons Learned，GAO-02-195、2002-01-30。本稿は歴史的な調査結果のみを参照しており、NASA の現在の状況を述べているものではありません。

関連資料（任意）

1. 一度の取引の後に、企業には何が残るのか？（中国語）：取引後に残る関係、協働、能力の蓄積を理解するための資料です。

2. 企業のコンテンツを、一貫した表現と継続的な更新につなげるには？（中国語）：知識を採用した後、関連する資料をどう保守するかをさらに扱っています。

研究上の説明：本稿は、初期の「行動―結果―蓄積」という研究の方向性を引き継ぎ、『SOP の整理・設計方法論』にある試行、フィードバック、反復的な改良、版の保守に関する考え方を参考に、実務で検証するための方法を提案しています。例は架空であり、図は提案する仕組みを示しています。本稿の方法を企業で直接検証したデータは、現時点ではありません。