プロジェクトガバナンスとは何か ― ITプロジェクトを支える「仕組みと体制」
itpjstudy
ITプロジェクトは、優秀なメンバやリーダが集まってチームを編成するだけでは不十分です。プロジェクトチームを有機的・効果的に機能させるためには、意思決定・認識合わせ・責任の所在を支えるための仕組みが必要です。そのための「仕組み」と「仕組みを機能させる体制」が不可欠であり、これがガバナンスです。
ガバナンスというと難しく聞こえるかもしれませんが、要は、「誰が何を決めて、誰が責任を取るのか」「そのために、どのように情報共有・コミュニケーションするのか」を仕組みにしたものです。
ITプロジェクトにおけるガバナンスとは何か
ここではまず、「ガバナンス」という言葉がなぜ誤解されやすいのか、そして本来何を指すのかを整理します。
ガバナンスは、優秀な人に任せることではない
多くのプロジェクトで見られるのが、「この人がいれば何とかなる」という期待です。
確かに、経験豊富で判断力のある人材は貴重です。しかし、その人が会議に出られない、異動する、忙殺される──その瞬間に、判断が止まる体制は健全とは言えません。
優秀な人材がいても、その人が不在だと判断が止まる… それが、ガバナンスが必要な理由です
- 個人依存のプロジェクトは属人化しやすく、リスクが高い
- ガバナンスは、個人の能力に頼らず組織で意思決定を回す仕組み
管理・統制と誤解されがちな理由
「ガバナンス」と聞くと、「管理が厳しくなる」「現場が縛られる」と感じる人も少なくありません。これは、ガバナンスと管理・統制が混同されているためです。
ガバナンス＝管理・統制ではありません。迷わず判断できる体制です
- 管理・統制：ルールや手順を守らせること
- ガバナンス：判断や意思決定を支える体制
- 現場が窮屈に感じるのは、誤解による運用のせい
ガバナンスは、判断と認識を支える仕組みである
ガバナンスが機能しているプロジェクトでは、判断に迷いが少なく、認識ズレも早期に解消されます。それは、「正解を知っている人」がいるからではなく、判断と認識を支える仕組みがあるからです。
誰が決め、誰が責任を取るかを明確にすることが、ガバナンスの本質です
- 判断に迷わない
- 部門間・チーム間で認識が揃う
- 誰が責任を取るか明確になる
ガバナンスは「体制」として実装される
ガバナンスは思想やスローガンではなく、体制として描けて初めて機能します。
体制図は、ガバナンスの設計図である
体制図は単なる組織図ではありません。「誰がどの判断をし、どこまで責任を持つのか」を示す、意思決定の設計図です。
- 単なるチームの羅列ではなく、「意思決定ルートと責任所在を示す設計図」が必要
- 迷ったときに誰が決めるかが一目で分かる
体制図を描くと、誰が判断し、誰が情報を流すかが一目で分かります
体制図に描かれていない役割は、存在しないのと同じ
「誰かが見ているはず」「暗黙的に分かっている」という前提は、プロジェクトが大きくなるほど破綻します。
- 暗黙知や個人裁量に頼ると、プロジェクト全体で機能しない
- 体制図に役割・会議体・権限を明示することが重要
プロジェクトリードにすべてを集約する体制の限界
責任感の強いリードほど、判断を抱え込みがちです。しかし、それはボトルネックを生みます。
- 判断が集中し、意思決定が遅れるボトルネックが発生
- 横串やレビュー役を設け、情報を分散させることが必要
役割を一段挟む体制は、横串で判断するための仕組み
各アプリや各業務が最適に見えても、全体では歪みが出ることがあります。それを防ぐために、「一段挟む」体制が有効です。
アプリ横断や業務横断の役割を一段挟むことで、全体最適の判断が容易になります
- プロジェクトリーダと各チームの間に「PMO」を置く [PMOは情報流通の要]
- 各アプリリードとプロジェクトリードの間に「業務・アプリ全体リード」を置く
- 横串で確認・判断ができる
業務側の体制が曖昧だと、ガバナンスは成立しない
IT側だけ体制を整えても、業務側の責任が曖昧だと判断は止まります。
業務側が曖昧だと、判断や承認が停滞します
- 業務側責任者やリードを明確化
- 両側の役割をはっきりさせることで体制が機能
会議体もまた、ガバナンスのための体制である
体制図を描くだけでは、ガバナンスはまだ「半分」です。もう半分を担うのが、会議体です。
会議は単なる進捗報告の場ではありません。どの会議で、誰が、どのレベルの判断をし、どこまで合意するのか。それを明確にして初めて、体制は実際に動き出します。
会議体の意義とは何か
多くのプロジェクトで、会議が「報告を聞いて終わる場」になっています。しかしそれでは、判断も責任も宙に浮いたままです。
会議は単なる報告の場ではなく、判断・認識・意思疎通を支える仕組み [プロジェクトの規律はPMOが守る]
- 誰が何を知るべきか
- どこで判断されるのか
- 誰がその判断に責任を持つのか
これらを明確にすることが、会議体の役割です。
会議体を設計することでガバナンスが機能する
ガバナンスが弱いプロジェクトほど、「その場で話して決めよう」「後で調整しよう」が繰り返されます。一方、会議体が設計されているプロジェクトでは、迷ったときに立ち戻る“判断の場”が決まっています。
事前に決定ルートや責任、情報流通を設計すると、迷わず意思決定できます
- 誰が決定するか
- 誰が責任を取るか
- 認識を揃えるタイミング
これらを会議体として定義することで、判断が滞らなくなります。
ガバナンスを実装する会議体の具体例
実際のプロジェクトでよく使われる会議体について、どのようにガバナンスを支えているか簡単に例示します。
- プロジェクト全体進捗会議： プロジェクト関係者全員が、共通認識を持てるようになる場[プロジェクト全体会議は粛々と運営されているか]
- リーダ会議： 大人数の会議体では話せないような話題も含めて、議論を尽くす場 [リーダ会議は喧々諤々できているか]
- 各種横串の会議： アプリ×基盤、アプリ×移行、アプリ×周辺システムなど、部分最適/サイロに陥るのを防ぎ、全体最適をはかる場
「会議が多すぎる」と感じることもありますが、一つの会議ですべてを賄うことはできません。それぞれのレイヤーで、異なる認識合わせと判断が必要です。
ガバナンスが弱いプロジェクトに共通する体制の特徴
ここまで見てきた内容の裏返しとして、ガバナンスが弱いプロジェクトには、共通した兆候があります。
体制はあるが、機能していない
役割はあるけど機能していない… 形だけのガバナンスです
- 名ばかり役割や会議体
- 権限・責任が曖昧で意思決定停滞
体制が「描かれている」だけでは不十分です。
問題が起きてから体制を作り始める
問題が顕在化してから体制を整えても、その時点ではすでに手遅れなことも多くあります。
- 初期設計が重要
- 後付けのガバナンスは効果が薄い
エース依存の体制が招くリスク
エース頼みの体制は、抜けた瞬間にプロジェクトが迷走します。また、エースが問題児になってしまうことも珍しくありません [エースが問題児になることもある]
- 個人依存による属人化
- 迷走や手戻りが増加
カバナンスは、単なる思想ではありません。具体的に、体制や会議体に仕組みとして組み込むことで、初めて機能します。優秀な人材だけに頼らず、仕組み化することで、属人化を防ぎ、大きな無理をしなくても、円滑に情報共有・意思決定がなされるようにすることが大事です。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
