プロジェクトの活動計画 －複数のチームで開発を行うような、中・大規模の2つの事例－
Ｃ社の事例
C社はカーオーディオやカーナビゲーションシステムを自動車メーカから受託して開発している企業で、通常はメカ、エレキ、ソフトの各部門から集められたメンバで構成されたチームで開発を行っている。
C社のような企業にとっては顧客である自動車メーカの納期を死守するのが至上命題だが、開発の主幹部門がメカ、エレキ、ソフトの部門ごとの計画を統合し整合をとった後で各部門の承認をとっている。この全体計画と整合がとれた3ヶ月程度の中日程を部門計画として別途作成している。その理由は、部門固有の活動は他部門では理解できないためと、全体計画１つに記載すると膨大な活動数のために一覧性が失われ俯瞰しにくいためである。
全体計画と部門計画の整合を取るために部門の代表者が出席する調整会議が設けられている。また、部門間で対立せず円滑に調整を進める役割を持ったコーディネータも存在する。各個人は部門の中日程から１週間レベルの小日程を作成している。
開発計画は壁に貼り、必ずその場所で進捗管理を行う。関係者全体で議論しないとなかなか決まらないためで、品証や製造部門のメンバも議論に参加している。また積み残しをしないために、その都度問題を壁に貼り付けている。
Ｄ社の事例
自社ブランドを持つ事務機メーカのD社では、プロジェクトマネージャ（以下PM）がマスタースケジュール（大日程）を決め、それを受けて、メカ、エレキ、ソフト等の各部門で中日程レベルの開発計画を作成している。
開発計画には、日程、コスト、品質、調達、工数を計画することになっており、コストをいくらまで、品質をどこまでというような目標設定まで行なっている。計画の見積りは、過去実績に効率化を加味してPMが作成しているが、作成を支援するために標準的な工数や日程の根拠となるデータが用意されている。
開発の標準ルールがあるので、PMによって開発のやり方が大きく変わるようなことは無い。標準的なルールがかなり根付いているから、能力ある人間であれば若手でもPMができる状態になってきている。この開発の標準ルールはISO9001に則って決めている。さらに、各プロジェクトの失敗例等のデータベースが用意されており、OJT以外にも若手のPMが学ぶ環境ができている。
進捗はQCDの観点で確認している。特に可視化が難しい品質について、例えばこの時期までに性能確認項目数を70%達成という計画に対して、実績がどうだという定量的なチェックを月に一回以上実施している。工数については担当者が日々工数を入力しており、機種ごとにリアルタイムで監視できる仕組みを構築している。
考察
開発規模が大きくなれば小さい開発と比べて関与する関係者の数が増大し、プロジェクトの状態が見えにくい、コミュニケーションが取りづらいなどの問題がおきる。そのため、情報共有やチーム間の調整を行なう必要がでてくる。そのために、計画書には、プロジェクトに参加する各チームを方向つける製品化の狙いや開発方針、各チームが協調して活動するタスク、コミュニケーション方法やルール等が記載され、組織には以下のような仕組みが存在している。
- 過去実績をベースに根拠ある工数見積、日程見積を実施する
- 基準となる計画をベースに部門別に活動を詳細化し関係者が使える形にする
- 計画に対して関係者の明確なコミットがある
- 基本的な情報共有と関係者間の調整を行なう環境がある
開発規模が大きくなると段々と計画書の中身がPMBOKの知識エリアをカバーして行くようだが、この事例からもわかるとおり、成功するプロジェクトの活動計画は、計画書の中身だけでなく、それを成立させる組織の仕組みを整える必要があるようだ。
また、これらはプロセスとして標準化している事例もあったが、必ずしも明文化されているというわけではなく、組織の常識として、暗黙の了解として習慣化しているものもあった。いかにも日本的だ。
さらに、良く見られる失敗事例として、根拠や裏付けが薄く実行性を伴わない計画、関係者のコミットを得ていない計画、ラフすぎて場当たり的な対応しかできない準備不足の計画などがあるが、事例では計画に対するレビューを担当部門長が行なう、有資格者が行なうなど、レビューが有効に機能し失敗を未然に防止していることも見逃せない。時間がなくてレビューをうまくまわせない組織は、計画の不備に起因した手戻りにかかっている無駄な工数や時間のことを考えてほしい。
◆7つのキープロセスのインデックス
