このエントリーをはてなブックマークに追加LINEで送る

8.2. プロジェクトマネジメントの現実

ハッピィ・エンジニアリング表紙

 方法論なきプロジェクトマネジメントは、管理そのもののあり方を否定しているといえよう。プロジェクトマネジメントは、プロジェクトをスムーズに進め、QCDを満足させるために行うべきものである。しかし現実に目を向ければ、たいていのプロジェクトは「管理のための管理」のような百害あって一利なしという状況である。

 

 いかに正しい姿でプロジェクトマネジメントが行われていないかを一番理解しているのは、管理されている技術者たちである。彼らは、プロジェクトマネジメントが形骸化していることを十分に認識している。技術者から見れば、プロジェクトマネージャは常に「無計画でその場しのぎ」に作業を押しつけているにすぎないと感じている。

 

 どれだけ「無計画でその場しのぎ」なのか、ありがちなものを挙げてみよう。

 

  • マネジメント技法の導入で解決すると考えている
  • コストのかかる作業が計画されていない
  • 計画の修正や改善が行われない
  • むやみかつ暗黙に責任を委譲している(ただし、権限はないに等しい)
  • 判断が必要なときに、適切な判断を下せない

 

マネジメント技法の導入で解決すると考えている

 プロジェクトマネジメントにおける一番の誤解は、マネジメント技法の導入で問題が解決すると考えているプロジェクトマネージャがあまりにも多いことである。*1

 

 しかし、技法の導入はプロジェクト計画時に検討されたわけではなく、そのほとんどがプロジェクト実施段階におけるトラブルを起因として開始される。例えば、ユーザ企業から設計と実装の乖離を指摘された瞬間に、「ライブラリ管理を徹底しなければならない」と言い出したり、プロジェクトに想定外の事象が発生し、その解決に時間を要した場合に、「リスク管理をする必要がある」と言い出したりするようなケースである。

 

 マネジメント技法がプロジェクトの初期段階に計画されていたものであれば、そのとおりに実施するか、問題点を改善して行えばよいだけのことだが、問題が発生した後で、その原因を分析せずにマネジメント技法を導入することは百害あって一利なしである。さらに、無目標・無目的な技法の導入は、やみくもに工数を増加させるだけで、その工数に見合う効果が期待できない。

 

 技法の導入自体に問題があるわけではない。原因を分析し、根本的な問題を取り除かずに、技法を導入することで解決しようという考えが問題なのである。

 

 例えば、「役割、権限、責任」が明確になっていないプロジェクトは多い。開発プロジェクト内の各チームや、プロジェクトマネージャ・プロジェクトリーダ・チームリーダそれぞれの「役割、権限、責任」はかなりあいまいである。このあいまい性によって、成果物に対する相互チェックが失われたり、リスクどころか、すでに顕在化している問題を放置したりするようなことが行われる。例えば、システムの基盤設計を行うチーム、アプリケーションを開発するチーム、サーバの構築を行うチームが分かれていたとしよう。基盤設計チームは、サーバ構築側で実装上の問題への指摘や、テストによる欠陥の回避を望んでいるかもしれない。しかし、サーバ構築チームは、基盤設計チームが設計した通りに実装することが自分たちの役割であると認識している場合には、「設計どおりのサーバ実装」以上のことは望めない。さらに、アプリケーションを開発するチームは、目先の開発で手いっぱいであり、アプリケーションが稼働する環境のことまで十分に意識しながら開発をしていないかもしれない。

 

 このように、「役割、権限、責任」が明確ではない体制においては、本番環境にシステムを構築したときに、まともに動作しない、当初想定していたパフォーマンスが出ないなどの問題が起きる。

 

 誰がどの作業に責任を持つのか、誰がシステム構築の最終責任を持つのか、などをきちんと明確にするのは、プロジェクトマネージャの仕事である。これらをチームリーダに調整させてはいけない。各チームの作業範囲は、ある部分は重なり合い、ある部分では空白地帯が生まれる。このような場合においては、チーム間の利害が対立するため、チームリーダ同士で調整するのは無理がある。

 

 このように、「役割、権限、責任」の明確化を行っていないことが原因の場合でも、トラブル事例を見て、「品質管理」「リスク管理」「ライブラリ管理」などという掛け声だけかけても意味がない。もろもろの問題に対処するには、原因の分析と本質的な解決策を図ることが重要なのである。

 

大きな負荷のかかる作業が計画されていない

 プロジェクトには、大きな負荷がかかる作業がある。例えば、システムのテストにおいては、そのテスト管理は多大な工数を必要とする。しかし、そのためのスケジュールやリソースの割り当てが的確ではないようなケースが生まれる。結局、プロジェクトマネージャは個々の作業に対しての認識がなく、技術者に丸投げしている状態のため、このような作業では常に適切なツールや人的リソースが割り当てられない。結果として、スケジュールが圧迫するようなことが発生する。

 

 これらは、過去のプロジェクトにおけるすべての工数や所要時間の実績を集計し、その実績数値の根拠となるボリュームなどを分析したうえで、現在のプロジェクトにおける見積もりに発展させていくべきものなのである。

 

計画の修正や改善が行われない

 プロジェクト計画がいいかげんなうえ、修正や改善が行われていない。現場のメンバに周知されるわけがなく、プロジェクトのコアメンバが部分的に共通認識を持っているにすぎない。計画書を修正し、プロジェクトメンバに周知徹底することで、プロジェクトメンバにとって、すべての作業は「計画されたもの」となる。スケジュールやリソースの割り当てなど、プロジェクトにおける変更が順次計画書に記載されることで、プロジェクトメンバは「想定外の作業の発生」で疲弊することが減り、「計画された作業」を淡々とこなしていくことができる。

 

むやみかつ暗黙に責任を委譲している

 チームやチームメンバの役割や責任の範囲が明確になって、初めて権限や責任の委譲を行うことができる。しかし、上述したように、適材適所に要員が配置されていないばかりか、役割、責任、権限が明確化されていないことで、生産性や品質に問題が出てくるのが現実である。無限の結果責任が下請けに連鎖し、結果的にプロジェクト全体が無責任な状況になる。そして、最後にプロジェクトが火事場となり、技術者がますます疲弊していく。

 

 例えば、要件定義や基本設計の品質が低いことで、結果的に詳細設計やプログラミングのプロセスで、SEやプログラマが要件や仕様レベルの検討をしている実態がある。さらには、SEやプログラマに各作業プロセスや管理手法までも検討させているようなケースもある。

 

 システム開発技術者は「職人」に例えられる。職人は、あくまでも決められた仕様に従いモノ作りをする立場だ。そこにむやみに本来の仕事とは異なる頭脳を求めすぎている。これでは、本来の職人として発揮すべき生産性を望むことに無理がある。現在におけるシステム開発技術者のレベルダウンは著しいといわれている中で、そこに本来の仕事とは異なる頭脳を求めることが、さらなる生産性の低下を生んでいるのである。

 

 プロジェクトマネージャが本来の役割を果たしておらず、適材適所に要員がアサインされていない上に、むやみに権限と責任の委譲が行われている典型的な例といえよう。

 

判断が必要なときに、適切な判断を下せない
 場当たりで計画性がないため、プロジェクトマネージャやプロジェクトリーダが本来やるべきではない個々の作業を担当してしまうことが多い。個々の作業を引き取るようなことが発生するために、技術者が判断を求めたときに、適切な判断を下す時間が取れない。適切に判断しないことにより、プロジェクトマネージャやプロジェクトリーダと技術者の間に、コミュニケーションの断絶が生まれる。プロジェクトマネージャやリーダは、技術者から「どうせ、いっても何もしない」と評価されるのだ。

 

 さらに、判断の遅れによりトラブルが生まれたときに技術者を責めるような行動を取れば、プロジェクトマネージャは技術者からの信頼を失う。

 


*1 マネジメント技法の導入を考えるプロジェクトマネージャは、まだレベルが高いといえる。本当にレベルが低いプロジェクトマネージャは、プロジェクトマネジメントが「コミュニケーション」や「プロジェクトメンバと仲よくなること」で達成できると思っている。当然、技術者は「こんなやつと仲よくしているつもりはない」のだが、人より上位に立ってしまうと、そんなことすらわからなくなるものだ。
シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

8.2. プロジェクトマネジメントの現実 ハッピィ・エンジニアリング関連ページ

8.1. 経験、勘、度胸
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
8.3. プロジェクトマネージャの役割
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
8.4. KKDからの脱却
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
8.5. プロジェクトマネジメントを浸透させるために
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング