設計工程の中盤に入ると、課題管理表の行数が跳ね上がる。二百件を超えたあたりで週次の定例が課題の読み上げ会になり、三百件を超えると読み上げも終わらなくなる。ステータス欄には「協議中」「確認中」「継続審議」が並び、起票日が二か月前のものが上のほうに沈んでいる。それでもプロジェクトは進んでいるように見える。設計書は書かれ、開発は始まり、テスト計画も引かれるからだ。詰まりが表に出るのはテストの直前で、そのとき「この論点、まだ決まっていませんでした」が十件単位で出てくる。課題が決まらないのは担当者が怠けているからではなく、その課題を誰にいつまでに上げるかが定義されていないからだ。 会議体の数を増やしても解決しない。増やすべきは階層でなく、上げる基準と判断の期限である。
課題管理表が膨らむのは、上げ先が定義されていないから
課題管理表の列を見ると、その組織が課題をどう扱っているかが分かる。だいたい入っているのは、起票日、起票者、内容、影響する工程、対応期限、ステータス。ここまではどのプロジェクトも同じだ。差が出るのは、その先に「判断者」と「付議先」の列があるかどうかである。
この二列が無いと何が起きるか。起票した担当者は、まず隣の担当者に相談する。二人で結論が出なければ、それぞれの上長に持ち帰る。上長同士の見解が割れると、次の定例で「調整中」と報告される。誰も判断を放棄していないのに、判断が発生する場所がどこにも無い。二か月後、同じ課題が別の切り口で再起票される。
課題を三種類に分けると、この構造は整理できる。ひとつめは、情報が足りないだけの課題だ。現行の運用を調べれば答えが出る。これは会議に出す必要がなく、調査の担当と期限を決めれば閉じる。ふたつめは、選択肢が二つ以上あって、どちらを取るかを決める課題。これが本来の付議対象になる。みっつめは、決めるべき人が社内に存在しない課題で、部門横断のルール変更や、業務そのものをやめる判断がこれにあたる。三つ目を二つ目と同じ場に出すと、その会議は必ず結論が出ないまま終わる。
課題管理表を眺めて「多すぎる」と感じたら、まずこの三分類で仕分ける。実務上、半分以上は一つ目の調査課題で、会議に出す必要のないものだ。残った本当の論点だけを会議体に流すと、定例の議題は二桁に収まる。
会議体は三階層で足りる。増やすほど決まらなくなる
会議体が足りないと感じると、人は会議を足す。設計調整会、業務検討会、課題対策会議。名前は違うが参加者はほぼ同じで、扱う論点も重なる。増えた分だけ、起票した担当者は「これはどの会議に出すのか」を考えなければならず、その迷いが滞留になる。
必要なのは三階層だ。それぞれに、扱う範囲、頻度、決裁できる範囲、そして滞留の上限日数を書く。
| 会議体 | 頻度・時間 | 参加者 | 決裁できる範囲 | 判断待ちの上限 |
|---|---|---|---|---|
| モジュール分科会 | 週2回・60分 | モジュールリード、業務側キーユーザ、開発担当 | 設計書の中で閉じる論点。他モジュールと工数に影響しないもの | 5営業日 |
| プロジェクト定例 | 週1回・90分 | 両社PM、各モジュールリード、発注側の各部門代表 | 工程をまたぐ論点、部門をまたぐ運用分担、一定工数までの追加対応 | 10営業日 |
| ステアリングコミッティ | 月1回・60分 | 発注側役員、事業部門長、ベンダー側責任者、プロジェクトオーナー | 予算、カットオーバー日、スコープの増減、組織構造、業務そのものの変更 | 20営業日（臨時開催の発議条件を明記） |
この表で最も重要なのは右端の列だ。上限日数が書かれていない会議体は、必ず滞留を溜める。逆に日数さえ切ってあれば、階層が三つしかなくても課題は流れる。
ステアリングコミッティを月1回に置くなら、臨時開催の条件も先に書いておく。「カットオーバー日に影響する判断が必要になった場合、PMの発議により五営業日以内に臨時開催する」といった条項がないと、月次のサイクルが判断の最大遅延になる。設計工程の後半では、一か月の遅れがそのままテスト期間の圧縮になって返ってくる。
分科会を週2回にしているのは意図がある。週1回だと、前回の宿題を持ち帰って調べた結果を出すのが翌週になり、一つの論点に二週間かかる。週2回なら同じ論点が三日で二巡する。会議の総時間は増えるが、決まる速度は倍近くになる。
付議基準は金額でなく「後戻りの範囲」で書く
付議基準を金額で書いているプロジェクトは多い。「五十万円を超える追加対応はステアリングコミッティ」といった形だ。契約上の変更管理では金額基準が要るが、課題の付議基準としては機能しない。設計工程で出てくる論点は、その時点では工数見積りが出ていないからだ。見積りを取るために付議したいのに、付議の可否が金額で決まるという循環に入る。
代わりに使うのは、その決定を後から覆したときに、どこまで作り直すかという基準だ。これは工数見積りが無くても判定できる。
四段目に入るものは限られている。会社コードと管理領域の構造、利益センタと事業セグメントの対応、期首残高をどの粒度で持つか、カットオーバー日と業務凍結期間の長さ、そして展開する法人の範囲。このうち組織構造は、稼働後の作り直しが事実上できない領域でありながら、プロジェクトの初期に現行組織図の写しとして二、三週間で決まってしまうことが多い（SAPの組織構造設計（会社コード・管理領域・利益センタ）｜アドオンで直せない唯一の領域）。ここを分科会で決めているプロジェクトは、階層の設計を間違えている。
三段目の「移行データと運用まで」は、判定を誤りやすい。設計上は小さな変更でも、業務手順が変わる決定は他部門の作業を動かす。部門長の同意を取らずに定例で決めると、稼働直前に「聞いていない」が出て、そこから調整が始まる。
決裁権は役職でなく、その決定の結果を運用する側に置く
決裁権限表を作るとき、多くの会社は役職で線を引く。課長まで、部長まで、役員まで。プロジェクトの決定でこの線を使うと、稼働後に守られないルールが量産される。
置くべきなのは、その決定の結果を毎日運用する側だ。会計伝票の入力ルールを決めるのは、システムを作る情報システム部門でなく、毎月その伝票を起こして締める経理である。マスタの登録権限を誰が持つかは、マスタの誤りで困る部門が決める。承認の階層をどこまで作るかは、承認が遅れて業務が止まる側が決める。この原則を外すと、稼働後に現場が自分たちのやり方に戻し、システムの設定と実際の運用がずれる。
もう一つ、決裁権とセットで書いておく必要があるのが「決めないという決定」の扱いだ。会議で結論が出ない場合、次回に持ち越すのではなく、その場で三つのいずれかに落とす。決める、調査を指示して期限を切る、あるいは次フェーズ送りにして今回は現行運用のまま行く。持ち越しという選択肢を残しておくと、同じ論点が毎週アジェンダに載り続ける。
標準機能で足りない部分を作るかどうかの判断は、この決裁権の設計が最も試される場面になる。判断軸を先に合意していないと、一件ごとに同じ議論を繰り返し、そのたびに上位へ上がる（SAPアドオン（追加開発）をどこまで作るか｜Fit-to-Standardの判断基準）。契約側でも、変更要求の判断期限と決裁者を条項に書いておけば、社内の会議体とベンダーの手続きが同じ時計で動く（SAP導入の見積りと契約をどう読むか｜追加費用が生まれる境目を先に潰す）。
- 三階層それぞれの扱う範囲、頻度、時間、参加者（氏名まで）
- 判断待ちステータスの上限営業日数と、超過時に自動で載る上位の会議体
- 付議基準（後戻りの範囲による四段階と、起票者がその場で判定する手順）
- 決裁者の一覧（役職でなく、その決定を運用する部門の責任者名）
- ステアリングコミッティの臨時開催の発議条件と、開催までの営業日数
- 会議で結論が出なかった場合の既定の扱い（持ち越しを選択肢に残さない）
- 決定事項を記録する台帳の様式と、設計への反映を確認する担当
- 発注側の各部門から、決める権限を持つ人が誰か（代理出席の可否も）
最後の項目は、要員供出の議論と直結する。会議に出てくる人が決める権限を持っていなければ、その会議は情報共有の場にしかならない。誰を何割の稼働で出すかを決めるとき、その人がどこまで自分で決めてよいかを同時に決めておく必要がある（SAP導入に現場のエースを何ヶ月出すか｜要員供出の判断と抜けた席の埋め方）。
エスカレーションは、人の判断でなく滞留日数で自動的に起こす
エスカレーションの規定を「重要な課題は速やかに上位へ報告する」と書いているプロジェクトは、エスカレーションが機能しない。重要かどうかを判断するのは現場の担当者で、その人にとって上げることは「自分たちで解決できませんでした」の表明になるからだ。上げるコストが個人にかかる限り、報告は遅れる。組織の中で悪い情報が上がってこない構造は、決算の着地見込みが下方修正されない現象とまったく同じ形をしている（悪い数字が経営に上がってこない会社｜着地見込みの下方修正を遅らせない仕組み）。
外し方は単純で、判断を人から日数へ移す。課題管理表のステータスが「判断待ち」に入った日を記録し、営業日数がしきい値を超えたら、その課題は自動的に上位の会議体のアジェンダに載る。載せる作業はPMO事務局が機械的に行い、現場の担当者に上げるかどうかの裁量を持たせない。この運用にすると、上位に上がること自体が失点でなくなるので、担当者は早めに判断待ちのステータスへ動かすようになる。
しきい値を設定するときの目安は、工程の残り期間から逆算する。設計工程が残り三か月なら、分科会の上限は五営業日で足りる。残り一か月に入ったら、同じ課題でも上限を三営業日に縮める。工程の終盤で日数を縮めない運用は、テスト直前の駆け込みを防げない。
決めたことを設計に落とすまでが会議体の仕事
会議で結論が出ても、それが設計書に反映されなければ、決まっていないのと同じだ。この最後の一歩が落ちるプロジェクトは多い。理由は、記録の形式が議事録だからである。
議事録は時系列の記録で、検索性がない。三か月前の会議で決めたことを設計に反映したかどうかを確認するには、議事録を遡って読むしかない。代わりに持つべきは決定台帳だ。列は、決定事項ID、決定日、決定した会議体、決定者、決定内容、そう決めた根拠、影響する成果物名、反映担当、そして反映確認日。最後の列が埋まるまで、その決定はクローズしない。
この台帳には二つの効き目がある。ひとつは、反映漏れが週次で見えること。反映確認日が空欄のまま二週間経った決定は、定例のアジェンダに載せる。もうひとつは、根拠を残せることだ。稼働後に「なぜこの設計になっているのか」を問われたとき、根拠の列があれば答えられる。無ければ、当時の判断を知る人が異動した時点で、その設計は触れない領域になる。
根拠が残っていることは、受入テストの設計にも効く。テストで期待値を作るには、その処理がなぜその挙動であるべきかの根拠が要る。決定台帳の根拠列は、そのままテストの期待値の出どころになる（SAPの受入テスト（UAT）で経理は何を見るか｜シナリオの粒度とテストデータの決め方）。
会議体の設計は、プロジェクトの初期に一度作って終わりにするものではない。工程が進むにつれて、扱う論点の性質も、許される滞留日数も変わる。手を入れる順番は決まっている。まず課題管理表を三分類し、会議に出す必要のない調査課題を外へ出す。次に付議基準を後戻りの範囲で四段階に書き、起票者がその場で判定できる形にする。それから決裁者を役職でなく運用を担う部門で埋め、判断待ちの上限日数を会議体ごとに設定する。最後に決定台帳を立て、反映確認日が埋まるまでクローズしない運用にする。この順でやると、会議の数を増やさずに決まる速度が上がる。逆に、会議を増やすところから始めると、上げ先を選ぶ迷いが増えて滞留はむしろ悪化する。
