読者です 読者をやめる 読者になる 読者になる

プロマネブログ

とあるSIerでプロマネやっているオッサンです。主にシステム開発ネタや仕事ネタ、気になった三面記事ネタの解説なんかしてたりします。

炎上プロジェクトの責任はプロマネが9割

テクノロジー プロジェクトマネジメント論

サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ

 

前回からの続きです。

以下、3部作の3本目となります。

  1. ウォーターフォール開発とアジャイルの本質 - プロマネブログ

  2.  サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ

  3.  炎上プロジェクトの責任はプロマネが9割 - プロマネブログ

 

追記)ブコメで誤字の指摘がありましたので、訂正します。。。お恥ずかしい

NetPenguinさん、ご指摘ありがとうございます

 

改めて考えたいプロマネの仕事

プロマネの仕事とは、PMBOKのプロジェクト管理に関する観点をマネジメントする、と言えます。

  1. 統合   ・・・ チーム内の意思統一
  2. スコープ ・・・ 目標、成果決定
  3. タイム  ・・・ 期限、スケジュール管理
  4. コスト  ・・・ 予算、費用管理
  5. 品質   ・・・ そのまま。品質管理。バグ管理。
  6. 人的資源 ・・・ メンバーの能力管理、生産性向上
  7. コミュニケーション ・・・ チーム内外との調整、情報共有
  8. リスク  ・・・ 人的リスク、時間リスクなど。
  9. 調達   ・・・ リソース調達、メンバー教育など。

 

上記のような形で1~9の事項を如何に管理するか、が腕の見せどころになるわけです。

 

開発手法とPMBOK観点の関係

さて、繰り返しとなりますが、前回までウォーターフォール(以下WF)とアジャイルでは本質が違うと話してきました。

この本質の違いがプロジェクトにどのように影響を与えるのか、上記のPMBOK観点に照らし合わせて考えてみましょう。

 

まず、WFからです。オッサンの経験から、良い点を赤悪い点を青、中立は黒で記載してます。

  1. 統合   ・・・ 目標、行動など全てを形式知化するため、意識の統一は測りやすい
  2. スコープ ・・・ 分割などの管理は基本しない。与えられた内容のまま
  3. タイム  ・・・ 期限は固定的
  4. コスト  ・・・ 形式知形成のためのドキュメント整備にコストがかかる
  5. 品質   ・・・ 品質の管理はドキュメントと実装(ソフトウェアなど)の両方で確定する。ドキュメントの品質依存が高い。
  6. 人的資源 ・・・ メンバーの教育の観点よりも、形式知の共有化の観点が強い。要は、メンバーの能力によらない開発を目指している
  7. コミュニケーション ・・・ 利害関係者との複雑な調整に強い
  8. リスク  ・・・ リスクは開発工程の後半によりがち
  9. 調達   ・・・ 形式知の形成により、メンバー教育は比較的容易(きちんと管理されたプロジェクトでは、初心者でもそれなりに活躍できるようにする)

 

同様にアジャイル

  1. 統合   ・・・ 「なぜこう作ったのか」がしばし暗黙知化され、成果物から辿れないことがある
  2. スコープ ・・・ 分割管理を行う。開発者側が手綱を握る。
  3. タイム  ・・・ 期限は可変的
  4. コスト  ・・・ 1回あたりのイテレーションでははるかにコストは少ないが、イテレーションを繰り返すとテストに関わるコストが増加する。
  5. 品質   ・・・ 品質の管理は主に実装(ソフトウェアなど)で確定する。ドキュメントなどを実装と2重で作成することは最小限で済む。
  6. 人的資源 ・・・ 暗黙知が主体のため、メンバーのスキルに左右される場合がある。
  7. コミュニケーション ・・・ スコープ分割された案件は見通しが良く、コミュニケーションも取りやすい。反面、様々な利害関係者が発生するとスコープ分割しづらくなり、アジャイルの良さが出なくなる。
  8. リスク  ・・・ リスクは分散されており、細かく対処可能
  9. 調達   ・・・ メンバー調達後の教育負担が比較的高い

とまあ、開発手法がざっくりですがPMBOK観点に与える影響が考えられるわけです。

※あくまでオッサンの経験なので、違うって意見もあるかもしれませんが。。。悪しからず。

 

このように、開発手法の本質から導かれたプロジェクトに与える影響を理解すれば、「今現在の案件特性に応じて、種々の開発手法を上手く利用して、リスクとコストを最小限化し、利益最大化を実現しよう」という考え方ができるのではないかと思います。

 

例えば、「メンバーのスキルにばらつきがあるので、WFに寄せて形式知化しておいてリスク軽減しておこう」とか、「お客さんが要件を整理出来ないので、アジャイルに寄せてスコープを管理するようにしよう」だとか。

 

結果、複雑な案件特性への開発手法の適応度合いを高めるため、新たな開発技法としてのハイブリッド開発手法が生きてくるわけです。

 

開発手法における「守・破・離」

オッサンは開発手法の習熟度に応じて、以下の段階を踏むと考えてます。

 

  • 習熟度なし ・・・ 形式知がないWFやスコープ分割されてないアジャイルなどを運営し、デスマを起こしながら、あるいはメンバーの高度なスキルに依存してプロジェクトを運営する
  • 「守」の段階 ・・・ WFやアジャイルなどの開発手法を理解し、デスマを起こすことなく安定したプロジェクト運営を行える
  • 「破」の段階 ・・・ WFやアジャイルなどの開発手法の本質を理解し、案件特性やチーム特性に応じて開発手法を複合させ、効率的なプロジェクト運営を行える
  • 「離」の段階 ・・・ 未知の案件に対して、従来のWFやアジャイルなどとは異なる新たな開発手法を生み出し、最善のプロジェクト運営を行える

 

よく、「ウチはアジャイルを使って効率的な開発を行ってます」とか、「WFを利用し、大規模な案件でも対応できます」みたいな話ってあると思いますが、これは「守」の段階ですね。

前回提唱したハイブリッド開発手法は、更に一步進み「破」の段階を目指してます。ここまでくれば、大方のプロジェクトを成功させることができると思います。

 

ま、「離」についてはどこぞかの天才様にお任せしておきましょ。

 

 

まとめ

色々書きましたが、オッサンが考えるに、できるプロマネってのは「開発手法」を武器に、チームを円滑に運営できる人を指すんじゃないかなって思います。

 

これは、PGがプログラミングスキルを、SEがシステム設計スキルを鍛えて仕事するのとおんなじです。

そして、メンバーの力を活かす、死なせるのもプロマネがきちんとチームを運営できるかにかかっているかと思います。どんなに優秀なPG、SEだって、チームが活動していなければ何もできなくなってしまいますから。。。

プロジェクトをデスマ炎上させるも、毎日定時早帰りにするも、プロマネの腕次第になると思ってます。

 

ですが、いろんな仕事をみていると、しばし、マネジメントスキルが軽視されてるなって場面を見ることがあります。

マネジメントスキルを、ただのコミュニケーションスキルや机上の空論などとしてしか見ていない企業の悪癖だと思います。

※とある雑誌のプロマネ関連の記事などみるに、マネジメントスキルを専門に教育するのではなく、なんとなくコミュニケーションができる現場のメンバーなら誰でも出来るんじゃないかな、なんて思われているフシも感じますし。。。

 

前回、前々回と開発手法をベースに、マネジメントスキルの見える化を目指していろいろまとめてみました。誰かの役に立てれば幸いです。

 

※ちなみに、タイトルの炎上プロジェクトの責任、残り1割はリスクバッファです。1割ぐらいは免責させてください。。。

 

ブックマークコメントをもらって 新しく気づきがあったので記事を追加しました。

次回は、

曖昧なプロマネ権限と責任がプロジェクトを炎上に導く - プロマネブログ

です。

 

以上

広告を非表示にする