#33:あるプロジェクトの軌跡〜プロジェクト計画（3）

前回の続き。

無事にベンダー選定が終わり（なぜか承認もらうのにグループCIOや自社の社長まで報告を要したが）、新年度が始まるとともにプロジェクト計画を承認するステアリングコミッテイを開催することになった。

すっきり始められるかと思いきや、新年度の人事異動や体制変更もあり、部長、課長、メンバーのB君という自分以外全員がプロジェクトから外れた。新メンバーに引き継ぐ時間もなく、独りでステコミの準備に追われていた。

この時は瞬間的に焦ったが、振り返るとこの総取っ替えがターニングポイントだった。ここを起点に大きくコントロールを握ることができた。過去の経緯を知らない部長や課長に対し、自分の考えをベースにプロジェクト計画を作成して報告することで、要員配置や工程定義など多少コントロール幅のある部分を采配できた。

当然ながらビジネス部門やベンダーとの合意をベースで動くことから、その関係者達とうまく合意形成ができることを前提とする、そういう幅での裁量権。自由には責任が伴う良い例だ。

その代わり、この頃、プロジェクトに全身全霊をかけて取り組んでいた。異動の端境期、かつプロジェクト計画という最重要期間をほぼ独りでワークして乗り切る非常事態であり、関係者のあらゆる感情の機微や計画上の僅かな綻びなどを全て敏感に感じとる必要性があった。この期間で、全方位に神経を張り巡らせる”円”をある程度使えるようになった。（詳細は↓参照）

ステコミに向けた資料作成時には、約20年の社会人生活の中でも、一番のゾーン状態だった。休みの日も寝る前も、お風呂の時も計画書の各項目について考えていた。そして、それが全く苦にはならず、なぜか楽しくて仕方なかった。

休みの日に手書きでラフスケッチした体制図はその後３、４回書き直してから、会社のPCで清書してチームに見せた。ステアリングコミッテイからオーナー部門、アプリ/基盤チーム、関連システムの担当メンバーまで含めると、社員/ベンダーで総勢40名近い重厚な体制になった。

スケジュールやWBS、会議体、スコープ定義などもひとつずつ噛み応えのあるテーマだったが、体制図に並び重かったのはリスク管理だ。社内のリスク抽出手順に従って洗い出していくと全部で20個以上あり、その中から主要なリスクに絞っても大きく9個が残った。ステコミ層に正しくリスク認識を伝えるため、相当リスクが高いプロジェクトだ、と繰り返し発信した。

そうして無事にプロジェクト計画は承認されたが、ここまでのプロセスを通じてベンダー体制やビジネス部門、基盤部門からのプロジェクトメンバーがかなり粒揃いで信頼できる人が多いことが分かった。リスクが高い高難度のプロジェクトには変わらなかったが、主要メンバーを中心にがっちり組めばかなり計算できることでだいぶ勝ち筋が見えてきた。

（4に続く）

◆記事一覧〜あるプロジェクトの軌跡〜◆
（１）検討開始
https://note.com/susumuy/n/n1931de0dc542
（２）ベンダー選定
https://note.com/susumuy/n/n93de96f156bf
（３）プロジェクト計画
https://note.com/susumuy/n/n242ed6a8efad
（４）クラウド検討
https://note.com/susumuy/n/n68326494925e
（５）クラウド選定基準
https://note.com/susumuy/n/ne6eb0d7ec88c
（６）要件定義完了
https://note.com/susumuy/n/n17d0ecf889ae

　後半に続く
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆