複雑なプロジェクトを、小さなチームで短いサイクルをくり返して進める

## 作業を見えるようにし、決まった間隔で確かめて計画を直す 複雑な仕事は、予測だけでは制御できない。現在の根拠を適切な時期の判断へ変える反復ループを作る。 - 作業、成果、重要な制約を、作業する人と価値を受け取る人の双方に見えるようにする。 - 一定の間隔で進捗と結果を点検する。 - 根拠から重大なずれが分かったら、計画やプロセスを速やかに適応させる。 - 予測は判断を支えるために使い、観測した結果の代わりには決して使わない。 可視化しても点検しなければ、制御は改善しない。点検しても適応しなければ、問題を見つけるだけで終わる。ループ全体を維持するか、プロジェクトが別の制御モデルを使うことを明示する。 ## 自分たちで分担を決める、小さなチームを1つ作る 結束した部門横断型のチームを一つ置き、一度に一つの成果へ集中させる。チームは、有用な成果を提供するために必要な技能を備えるか獲得し、誰が何をいつどのように行うかを内部で決める。 調査、提供、検証、関係者との連携、継続的な運用に対する責任を同じチーム内に置く。内部の小チームや役職階層によって責任を分断しない。 直接やり取りできるほど小さく、意味のある仕事を完了できるほど大きなチームにする。規模の拡大によって複数チームが必要になった場合は、同じ成果、優先順を付けた作業一覧、価値判断の責任者、品質基準を共有して足並みをそろえる。 根拠に基づく仕事を可能にする行動を強める。 - 共通の成果に責任を持ち、互いを支える。 - 進行中のサイクルに集中する。 - 作業と困難を点検できる状態にする。 - 貢献者を能力ある専門家として扱う。 - 厳しい事実を示し、難しい問題に取り組む。 一回のサイクルを越えて集中と一貫性を保てるよう、持続可能なペースで進める。 ## 優先順位を決める1人、作業する人、困り事を取り除く支援役の3つの役を分ける 成果提供チームが有用な成果への共同責任を保ったまま、少数の明確な役割責任を定める。 価値責任者は、投票で決める委員会ではなく、一人の責任者とする。長期的な成果を設定して伝え、作業一覧の順序を決め、各項目を明確にし、提供する価値を最大化する。作業を委任しても、価値責任者の責任は残る。優先順位の変更を求める関係者は、この役割を通して働きかける。 成果提供担当者は、利用可能な進捗を生み出し、サイクル計画を維持し、共通の品質基準を守り、根拠の変化に応じて計画を適応させ、専門家として互いに責任を持つ。実際に作業する人が、見積もりと実装計画を担う。 プロセス支援者は、自己管理の指導、障害の解消、根拠に基づく計画の強化、目的が明確で時間を限定した調整会の維持を通じて、チームの有効性を高める。これは指揮命令の階層ではなく、支援と能力強化を担う役割である。 ## 決まった長さの短いサイクルを続け、途中で目標を崩さない 費用、労力、判断上のリスクを抑えられるほど短い、固定長のサイクルを使う。プロジェクトの運用リズムを安定させるため、前のサイクルが終わったら直ちに次のサイクルを始める。 進行中のサイクルでは、次を守る。 - その成果を危うくする変更を加えない。 - 合意した品質基準を下げない。 - 理解が深まるにつれて、将来の作業を洗練する。 - 成果を暗黙に変えることなく、必要に応じて範囲を明確にし、再交渉する。 サイクルを短くすると、学習と軌道修正の機会が増える。サイクルを早期に終了してよいのは、その成果が不要になった場合だけとし、その判断は明示した価値判断の責任者に委ねる。 計画、短い調整、成果の見直し、プロセス改善をサイクル内に置く。各会合に明確な目的と最長時間を設け、サイクルが短い場合は補助的な会合も短くする。 ## サイクルごとに「なぜ・何を・どうやって」で計画する サイクル計画は共同で完成させ、三つの問いに答える。 1. このサイクルには、なぜ価値があるのか。 2. このサイクル内で何を完了できるのか。 3. 選んだ作業をどのように利用可能な成果へ変えるのか。 計画が終わる前に、サイクルの成果を一つ定める。目指す価値を説明しながら、その達成に使う具体的な作業には柔軟性を残す。 現在の優先順位、過去の提供実績、今後の対応能力、共通の品質基準を使って作業を選ぶ。成果提供担当者が実装方法を決め、日々の点検ができる細かさまで選択項目を分解する。 完成したサイクル計画では、成果、選んだ作業、実行可能な提供方法を結び付ける。新しい事実が明らかになるたびに、サイクルを通して計画を更新する。 ## 順番を付けた作業一覧を、見える形で1つだけ持つ 製品やサービスの改善に必要な作業を、見える状態で優先順を付けて発展させる一覧にまとめる。価値責任者が明確さと順序に責任を持ち、実際に作業する人が見積もりを担う。 大きな項目の分割、判断に必要な詳細の追加、学習に応じた順序や規模の見直しによって、作業一覧を継続的に洗練する。属性は分野によって異なってもよいが、各項目は次の着手判断に十分なほど理解できる状態にする。 現在の品質基準を満たしながら成果提供チームが無理なく完了できる場合だけ、その作業をサイクルに選ぶ。その後は、進行中のサイクル計画が、作業の重要性、選んだ内容、チームが提供しようとする方法をリアルタイムで示す。 隠れた優先順位リストを複数運用しない。競合する情報源があると透明性が損なわれ、トレードオフを点検できなくなる。 ## 「完了」と言える品質の共通基準を決める 進捗は、長期的な成果へ向かう、統合済みで検証済みの利用可能な一歩として扱う。完了した各段階は、孤立した実演として存在するのではなく、それ以前の結果とともに機能しなければならない。 提供は、予定された見直しより前に行ってもよい。見直しは学習の機会であり、リリースの関門ではない。 必要な品質指標を示す共通の完了基準を定める。基準を満たさない作業は完了ではなく、提供済みの価値として示すこともできない。将来の検討対象として、優先順を付けた作業一覧へ戻す。 組織全体の基準がある場合は、それを最低基準として使う。同じ製品に複数の成果提供チームが携わる場合は、同じ完了基準を共有し、守らなければならない。 ## 毎日の打ち合わせと、結果と進め方の見直しをする 毎日の短い調整会で、サイクルの成果に向けた進捗を点検し、次の作業期間に向けた実行可能な計画を作る。形式は成果提供担当者が選ぶ。計画はいつでも適応させてよく、この会合だけが変更の機会ではない。 成果の見直しは、関係者との実務的な会合として行う。利用可能な成果、環境の変化、長期的な成果への進捗を調べ、今後の優先順位を共同で更新する。この会合を発表だけで終わらせない。 プロセスの見直しでは、人、やり取り、手法、道具、品質慣行、前提を調べる。何が役立ち、何が失敗し、その理由は何かを特定する。最も価値の高い改善を可能な限り早く適用し、有用なら次のサイクルに含める。 これらの点検機会を一定の間隔で設け、リズムを作り、追加の進捗報告会を減らす。