今の仕事の流れを見えるようにして、依頼から届けるまでの遅れを減らす

## 依頼から届けるまでの、今のサービスのやり方から始める フロー管理は、あらゆる役割、プロセス、ツールを置き換える理由ではなく、既存のサービスに加える改善の層として扱う。非公式な引き継ぎや例外対応も含め、現在実際に行われている仕事から始める。 依頼から成果物が受け入れられるまでの範囲でサービスを定義する。顧客、顧客が期待する成果、サービスの提供者、提供に貢献する作業を特定する。 誰かを責めることなく、現在の不満の原因を記述する。依頼の遅れ、完了時期の予測不能、手戻り、優先順位の衝突、過負荷の工程、満たされていない期待を探す。 観察して見直せる小さな変更を通じて改善することに合意する。問題を明らかにする、支援を調整する、より良い方針を試すといった行動を取れる人なら、誰であってもリーダーシップを発揮できるようにする。 サービスを再設計する前に、次を確認する。 - どの顧客依頼がサービスの開始点になるか。 - どの出来事を、成果物の受け入れ完了とみなすか。 - どの活動と依存関係を対象範囲に含めるか。 - 変更を裏づける証拠が得られるまで、どの既存慣行を維持するか。 ## 入ってくる依頼、これまでかかった時間、作業が待つ所を調べる 管理方法を設計する前に、流入する需要を調べる。同じような挙動を示す依頼をまとめ、その頻度と緊急度を記録し、価値のある需要と、不具合、不明確な入力、過去の失敗によって生じた回避可能な作業を区別する。 過去の証拠を使って能力を把握する。どれだけの作業が完了するか、依頼にどれほど時間がかかるか、どこで作業が待機するか、各工程でどれだけの作業が進行中かを調べる。 待ち行列、レビュー、依存関係、並行活動、着手の確約、提供完了を含め、実際に運用されているワークフローを描く。正式な手順と観察した現実が異なる場合、現実を正式な手順に置き換えてはならない。 関係する役割の代表者を設計に参加させる。1つの役割だけで作ったワークフローモデルでは、制約、顧客の期待、運用上の知識を見落としやすい。 最初のモデルで、次の問いに答えられるようにする。 - どのような種類の依頼がサービスに入るか。 - 各依頼をどこで評価し、着手を確約するか。 - どの活動が作業を変更または検証するか。 - どこで作業が妨げられたり遅れたりする可能性があるか。 - 現在の実績を示す証拠は何か。 ## 進行中の作業と、次へ進める決まりを1か所で見えるようにする 依頼から提供完了までの現在のワークフローを表す共有ビューを作る。進行中の各項目について、その種類、現在の活動、重要なリスク、妨げられているかどうかを示す。 順番に進む活動は、順序のある工程として表す。並行作業、特別扱い、別の作業種別は、その区別が意思決定に役立つ場合にだけ示す。 運用ルールは、適用される場所の近くに置く。開始条件と完了条件、優先順位のルール、能力の上限、着手確約のルール、作業を次へ進める条件を含める。 方針は少数に絞り、明確で検証可能にする。影響を受ける全員がルールの意味を説明し、一貫して適用し、成果の改善に役立たなくなったときに変更を提案できるようにする。 次の場合は、可視化したモデルを見直す。 - 作業が、表現されていない経路を繰り返し通る。 - 同じ状態や方針について、人によって解釈が異なる。 - 隠れた待ち行列や依存関係が現れる。 - 視覚的な要素が意思決定に役立たず、保守コストだけを増やす。 ## 同時に進める作業の数に上限を決め、空きがある時だけ始める サービス全体または制約のある工程について、進行中の作業量に明示的な上限を設ける。上限はフローと集中を守るためのものであり、常に満たすべき目標ではない。 新しい作業は、需要が存在し、下流に受け入れ能力がある場合にだけ始める。利用可能な空きが、次の適格な項目を選ぶ合図になる。 上限に達したら、その領域への作業追加を止める。既存作業の完了や障害解消を支援する、制約を調べる、または証拠に基づいて方針を見直す。 変動、調整、学習、復旧のために、能力の一部を余裕として残す。全員の稼働率を最大にしようとすると、通常は待ち行列、作業の切り替え、提供時期の不確実性が増える。 作業を補充するときは、次を行う。 - 候補作業が準備完了の基準を満たしていることを確かめる。 - 緊急度、価値、リスク、依存関係、遅延による損失を比較する。 - 現在の能力で支えられる量の作業だけを選ぶ。 - 例外的な扱いが正当である理由を記録する。 - 提供工程に入れるべきでない候補は、対象外にするか延期する。 ## 止まった作業にすぐ印を付け、急ぎの割り込みは少なくする 日々の調整では、個人の活動報告ではなく、作業の進み方に焦点を当てる。何が完了を妨げているか、どのような支援が必要か、次にどの項目を進めるべきかを確認する。 障害は判明した時点で印を付ける。繰り返し同じ制約を発見し直すのではなく分析できるように、停止期間、原因、解決責任者、次の行動を記録する。 遅延リスクの違いによって異なる扱いが必要な場合にだけ、別々のサービス区分を使う。各区分について、適用条件、優先順位、能力への影響、終了条件を定義する。 例外的な優先処理はまれなものとし、明示する。1つの項目を先に進めると、ほかの項目の提供見込みが変わるため、そのトレードオフを見える形にし、サービス責任者が受け入れなければならない。 フローが悪化したときは、次を行う。 - 流入量が提供能力を超えていないか確認する。 - 増え続ける待ち行列や、長期間滞留する項目を探す。 - ボトルネック、依存関係、手戻り、作業の切り替えを特定する。 - 新しい作業を始める前に、既存作業を完了させるか障害を解消する。 - 上限や方針を変えるのは、理由を明示できる場合に限る。 ## かかった時間と終わった数を、数字のごまかしが起きないように測る サービス上の意思決定に役立つ少数の指標を使う。まず、提供完了までの経過時間、期間ごとの完了項目数、進行中の作業、障害、必要に応じて回避可能な需要を測る。 各指標について、開始点、終了点、単位、対象母集団、除外条件、確認期間を正確に定義する。異なる作業種別やサービス区分を混ぜることで重要な差が見えなくなる場合は、それらを一緒にしてはならない。 平均値だけに頼らず、分布と傾向を調べる。過去の範囲は将来の提供見込みを推定する助けになるが、不確実性をなくすものではない。 フローの表示を使って、作業の蓄積、不安定な流入と流出、制約のある工程を検出する。パターンの変化を改善または悪化と判断する前に、その変化を調べる。 指標の操作を防ぐため、次を守る。 - 個人の忙しさではなく、サービスを測る。 - 速度の指標と、品質および手戻りの兆候を組み合わせる。 - 比較期間中は定義を安定させる。 - データに影響する方針や需要の変化を記録する。 - 意思決定に役立たなくなった指標は、使用を終える。 ## 今ある会議を使って、止まっている所を取り除き結果を見直す 会議やレビューは、観察結果が意思決定や行動につながる場合にだけ、フィードバックの循環として使う。対応の仕組みがない状態情報だけでは、仕組みは改善されない。 必要な目的を果たせる場合は、既存の会議を再利用する。最初から新しい会議体系一式を作るのではなく、参加者、頻度、時間、議題をサービスの状況に合わせて調整する。 即時のフロー調整と、より深い改善およびリスクのレビューを分ける。毎日または高頻度の調整では障害を取り除いて作業を選び、定期的なレビューでは実績、需要、リスク、方針、実験を検討する。 各定例活動では、作業とサービス成果に焦点を絞る。証拠の理解、意思決定、決定後の行動に必要な人だけを招く。 定例活動ごとに、次を定義する。 - 意思決定の目的と、入力する証拠。 - 責任を担う参加者。 - 期待される行動または成果物。 - 確認の頻度と時間制限。 - 未解決の行動を追跡する方法。 ## 元に戻せる小さな変更を試し、効いた物だけ残す 観察したサービス上の問題を、検証可能な仮説に変える。期待する効果、仮説を支持または棄却する証拠、評価に必要な期間または標本数を明示する。 悪影響が限定される小さな変更を優先する。変更によって提供、品質、顧客成果、または接続する別のサービスに害が生じた場合に、変更を元に戻すか見直す方法を定義する。 実験中にデータを収集し、適切な基準値と比較する。見かけ上の改善を誤った原因に帰属しないように、状況の変化を記録する。 証拠に基づいて仮説を採用、棄却、または修正する。実験が失敗した場合も有用な学びを残し、実装に労力を使ったという理由だけで変更を維持しない。 次の循環を繰り返す。 - 需要、フロー、能力、顧客成果を観察する。 - 最も重大な制約または不確実性を特定する。 - 方針またはワークフローへの最小限の変更を提案する。 - 定義した範囲内で変更を試す。 - サービス参加者と結果を確認する。 - 変更を維持、修正、または元に戻す。