実績事例

どこで止まっているか、隠せなくなった

不具合品の処置が滞っていた。この処置プロセスが、とにかく複雑だった。国際共同開発では、設計権が部品ごとに分かれている。それも一部品に一本ではない。同じ部品の中でも部位ごとに、ここは自社、ここは相手先——と持ち主が違う。不具合が一件起きるたびに、その箇所の設計権を持つ会社の、しかるべき部門の承認を取りに行くことになる。経路は社内外の10を超える部門にわたる。どの承認段階で何件止まっているのか、誰も答えられなかった。前任者が滞留の数を一度は減らしたが、そこから先は動かなくなっていた。

複雑な承認経路をマップ化し、どのプロセスに何件溜まっているかをデータベースにした。それを毎週のプロジェクト会議で共有し、どこで止まっているのか、誰の目にも分かる状態を作った。そのうえで月あたりの処置件数に目標を置き、届かない部署には対策を求めた。

社内で最も溜めていた部署は、処置の人手が足りていなかった。課長は増員したいが、人事権を持つ部長を説得しきれずにいた。滞留の根拠資料を課長へ渡し、同時に上層部には、部長への働きかけを要請した。採用が動いた。

社外は構造から違った。相手先にとって、不具合処置を積極的に進めるインセンティブがない。だから共同事業全体の損得の話に変えた。トップ同士で「処置は全体最適のためにやる」という合意を取り、月次の処置計画に具体化してその数字を合意させた。ただ合意しただけでは、計画どおりには進まない。ステアリングコミッティを設け、遅れるたびに状況を見せ、相手に対策を出させて、追い続けた。

動かなかった滞留数が、下がり始めた。増員した部署は処置が進み、社外の相手先2社は計画を守るようになり、詰まりは一つずつ外れていった。私が離れる頃には、下降トレンドが定着し、あとは見守るだけの状態になっていた。見える化とは、グラフを作ることではない。どこが止まっているかを、全員の目に見える場所へ置くことだ。

会議は減って、決定は速くなった

週次のプロジェクト会議に、10名以上が出ていた。だが、決める会議になっていなかった。議題の当事者が不在のまま、周りの人間が延々と話している。資料は前回のまま更新されず、質問しても答えが返ってこない。その場で決められる人が来ておらず、誰が止めているのかも曖昧なまま、全員が問題を放置する。議事録は配信されず、前回決めた議論を次の会議でまた繰り返す。会議を増やすほどチームは疲弊し、決定は遅れていった。

議題は、機能部門ごとの報告から成果物ごとの報告へ組み替えた。一つの成果物について各部門の報告が続けて並ぶから、部門をまたいだ議論がその場で成立する。資料は1リスク1スライドに揃え、毎回更新させた。フォローの頻度はスライドごとに決めた。毎週すべてを追うのではなく、緊急度の高いリスクほど高い頻度で見る。各部門には「部門を代表して、その場で決められる人を出してください」と要求し続けた。決められない人が来ているなら、代わってもらう。進行では、埋もれている問題を拾い上げ、「これはこういうリスクですね」と言葉にして、答えられる人に質問をつないだ。議事録には、誰が何を言い、何を引き受けたかまで書いて配信する。配信後に異論がなければ、組織の決定として確定させた。

出席率は70%から90%に上がった。出ろと命じたからではない。この会議に出れば物事が決まる。その価値を、参加者が認めた結果だった。会議体の数は減らしながら、決定は速くなった。狙いは会議改革ではない。意思決定が通る構造を作り直したら、チームが自走し始めた。

危機の回し方が、型になった

航空エンジンの国際共同開発プログラムを回していると、大きな問題は年に2〜3回の頻度で起きた。サプライヤーからの工場移転連絡。自社の機械加工設備が壊れる。認証試験に失敗する。部品が全数不具合で落ちて、翌月の出荷がゼロになる。サプライヤーの品質不正。何の前触れもなく発生した実例だ。

問題が起きたら、その日のうちにリスクの一枚資料を作らせた。書くことは3つ。何が起きたのか。プログラムのどこに、どれだけ影響するのか。初動をどうするか。バッドニュースほど早く上げろ、影響評価は1週間以内に出せ——これをチームへの要求にした。

資料と並行して、粗くてもいいからスケジュールを引き、暫定対策を立てさせる。対策は４～５本を複数案ならべ、それぞれに担当者を付けて、同時並行で走らせた。2本だけでは潰れた時点で手詰まりとなるが、5本もあれば何本か死んでもプログラムは前に進む。対策の同時並行はリソースがかかるが、やらないと詰む。

リスクの大きい問題は、毎日フォローの場を持った。新しい情報が入るたびに一枚資料を書き換え、対策を入れ替える。回していくうちに、生き残る対策が絞られてくる。影響の全体が見え、抑え込める目処が立ったら、その問題は定例の進捗管理に戻すことができる。危機対応は、ここで終わる。

この回し方を、危機のたびに繰り返すとPJメンバー達も型を覚える。次にとるべき行動を各自がわかっているので、初動スピードが変わった。問題が閉じるまで一か月は速くなった。ここで稼いだ一か月がPJメンバーを次の問題に目を向けさせる。危機そのものは避けられないが、立ち直る速さは組織に覚えさせられる。

私が抜けた後、危機が来た

プログラムマネジメントを後任に引き継いだ。そのとき既に、半年先に部品供給が枯渇するリスクが見えていた。全体の取りまとめも、リスクの把握も、対策の遂行も、ここから先は後任チームの仕事だ。自分が作ってきたものが仕組みなら、チームは自力で回るはず。個人技で回していただけなら、ここで止まる。正直、不安はあった。

引き継ぎのとき、後任に渡したものは少ない。仕組みを続けること。なぜこの仕組みを作ったのか。この二つだけだ。コミュニケーションを密に、とも、リーダーシップを発揮しろ、とも言っていない。言う必要がないように、最初から作ってきたからだ。PMミーティングの進め方。関係部門が自分からリスクを上げる運用。決められる人が会議に出ること。危機対応の回し方も含めて、型はチームの共通認識になっていた。属人の手腕は、引き継げない。型は、引き継げる。

危機は実際に来た。部品供給が枯渇しかけ、自社の部品がエンジンの組立ラインを止める寸前まで行った。後任チームは立てた対策をやり切り、供給を安定軌道へ戻した。後任者の言葉が残っている。「型ができているから、やりやすい」。平時は、誰がやってもプロジェクトは進む。仕組みの真贋は、作った本人が抜けた後の危機だけが証明する。コンサルの成果も、同じ基準で測られるべきだと考えている。去った後も、回るか。