身近なプロジェクトマネジメント例 （５）

こんばんは、ズッキーです。

最近、嫁さんにUMLをレクチャーしています。
レクチャーした後は、なんだかすごく眠い感じなのですが、寝る前の体操って感じです。

さて、今回のテーマ「身近なプロジェクトマネジメント例」です。

マネジメントといえるかどうかは、わかりませんが、現在、携わっている組み込み開発ビジネスについて書きたいと思います。


現在、会社で組み込み開発をやろうということで調査、及びビジネスパートナーの開拓をしています。
構成メンバーは4人です（役職1人、営業1人、調査・開発2人）。
私は、調査・開発担当です。

当プロジェクト開始時、私は他の開発プロジェクトをプロジェクトリーダーをやっていたので、こちらの組み込みプロジェクトには、あまりパワーを入れていませんでした。しかし、組み込みプロジェクト２～３か月後、このプロジェクトが頓挫しました。

それはなぜか？

●プロジェクトスケジュールが、現場（調査・開発）スケジュールと同じであったこと。
●行き当たりばったりの方向性であったこと。（具体的な方向性がなかったこと）

そこで、私は意思決定方式をトップダウンから、ボトムアップに変更するように提案しました。
つまり、上司から指示を受けるのではなく、現場からプロジェクトの方向性を提案することにしました。
最初は、トップダウンの意思決定でいいかと思います。しかし、現場を動かすフェーズやプロジェクトのリーダーがただの管理者で現場を何も知らない場合には、ボトムアップの意思決定が効果的だと思います。
第一に現場のモチベーションが上がります。

また、当初、役員から受けた指示（組み込み開発ビジネスの開拓）を現場が実践できる具体的な目標に落とし込んでいきました。そうすることで、自分たちの中で漠然としていた方向性を一つの方向に向けることができました。

そして、スケジュールを組み直しました。そのスケジュールでは、１か月単位でのプロジェクト判断会を行うようにしました。この定例では、ビジネスの方向性の検討や、このプロジェクト自体を続けるかどうかなどを判断を下すものです。


しかし、スケジュールを組みなおして、さあ再スタートだ！という矢先に、我々現場が所属している部から他の作業が入りまくりました。そのうち、組み込み開発ビジネスを推進する部に所属している役職（プロジェクトリーダー）も弱気になってしまい、「できるだけ今の業務に専念して欲しい。」という有様でした。


現在でも、組み込みプロジェクトは何とか生きていますが、風前の灯です。

このプロジェクトの最大の失敗は、異なる２つの部でメンバーを構成したことです。
（役職、営業は新しく立ち上がった部、我々、調査・開発は既存の部）

プロジェクト開始時は、互いの部でプロジェクトを推進することにコミットしていましたが、
時間が経過するにつれて、そのコミットはなかったかのようになりました。

部が違うことで、一番大変なのは現場です。
こういうプロジェクトは、雲行き怪しいことが多々ありますので、皆さんの参考にでもしてください。