プロジェクト体制図の作り方

普通のシステム開発はそれなりの人数の参加者がいるので「プロジェクト体制図」を作ります。関係者の名前を書いて適当に線を引いただけの資料をよく見かけるのですが、せっかく時間をかけて作るなら、いくつか押さえてほしいポイントがあります。

プロジェクト体制図に表現すべき要素

「プロジェクト体制図」には、役割と責任・権限が表現されていないといけません。よく聞く言葉なのでピンと来ないかもしれませんが、問題が起きた時のことをイメージしてみて下さい。

システム開発って最初はみんなモチベーション高くて、とても爽やかな感じで始まることも少なくないのですが、後半戦になると、色々と問題が起きてきて「それ、俺の仕事じゃないです。〇〇さんが担当じゃないんですか！」のような責任逃れ、責任の押し付け合いになることもしばしばあります。人間って怖い生き物ですね。

そういったケースを意識して「一体誰のせいなの？」が一目でわかる資料が「プロジェクト体制図」です。特にあなたが、組織の中で、それほど偉くない立場の方だったら、なおさらそのあたりを意識して資料を作りましょう。いざというとき、トカゲのしっぽ切りのように責任だけ押し付けられてしまう事態を避けるために。。。

そう考えると、組織間、担当者間に線を引くだけでなく、各組織・担当者の役割の定義・説明を言葉でしっかり書いていく方が、よりよい体制図の資料になります。たくさん書きすぎると可読性が落ちるので、ほどほどで構いませんが。

「コミュニケーションルート」とは、誰が誰に伝達すべきかということです。「プロジェクト体制図」では担当者間に線を引くだけの作業なのですが、この線を引くことで「報告の義務」「連絡・相談する際の相手」を明確化する意味があるので、ここは意識的にやりましょう。

特にユーザー体制の関係者間の役割・責任の明確化は大事です。システム開発に集中してもらうために、ユーザー側の担当者は、理想は開発が終わるまでは「専任」するのが理想ですが、現実は普段行っている仕事と「兼任」するケースが多いです。

そうなると、ユーザー担当者にとっては、一文にもならない（と評価されることも多い）システム開発の支援の仕事よりも、本業（普段の仕事）に力を入れるのは自然な流れです。そして、本業の片手間で「忙しいのに聞いてくんなよ」と冷たい態度でシステム担当者に接することもたまにあります。

誰がユーザーの取り纏め者として「責任」を負い、どういうコミュニケーションルートで、ユーザー間で要件を合意するのか、これを「プロジェクト体制図」に表現しましょう。

プロジェクトの最初にせっかく作った「プロジェクト体制図」ですが、その後はお蔵入りしてプロジェクト期間中に二度と目にしないことも結構あります。各開発工程のExit時点など、開発プロジェクトの節目で引っ張り出して、読み合わせする（役割・責任を再認識する）のがよいと思います。

「ここの責任者、お前だよな」とさりげなく再確認するために。

開発も後半になってから、色々と問題が起きますしね。前半の頑張り（さぼり）が、後半に無情に顕在化するのがシステム開発というお仕事なのですから。

また、「役割」とは、突き詰めていけば「誰が何をするか」ということなので、必ず対となるスケジュール表が存在します。「プロジェクト体制図」では「いつまでに（期限）」が表現できないので、一緒にWBSなどのスケジュール表を作りましょう。