ポスト「モダンPM」とはいうけれど

日経SYSTEMSの最新号（2016年5月号）の特集が『ポスト「モダンPM」』

2月号では『「本物のプロマネ」七つの条件』（特集2）がありその記事の感想はすでにご紹介済みだが以下にポイントだけを引用する。

• 『結局PMBOKから始まったモダンPMの話が中心。　勿論PMBOKの勘どころを軽くおさらいしたいなら読んでみる価値はあるが「スキル変革」「本物のプロマネ」というテーマから推測される内容とはちょっとかけ離れていたようだ。』
• 『最終頁で「今後はイノベーション創造型プロマネが重要になってくるだろう」が、結局抽象的ななことしか書いてなかった為、結局中身はよくわからなかった。そこで私なりに「イノベーション創造型プロマネ」を何回かに分けて深堀していきたいと思う』

そして、その三か月後に組まれた記事が今回の『 ポスト「モダンPM」 』だった。　前回の件があったのであまり期待はしてなかったが、なんといっても今回はメイントピック（特集１）であることを考えると、少しはましになったのでは？という期待感から20頁程の”大特集”を読んでみた。

結論から言うと「また肩透かしを食らった」というとちょっと手厳しいだろうか？

記事の内容と論評

ここの編集者はどうも用語の定義を明確にしないまま新しい単語を繰り出すのが好きなようなのでフォローをしながら簡単に紹介する。

Part1（前ふりで事例紹介）, Part2（神庭氏など3名の座談会）

【記事の骨子】

「モダンPM」とはPMBOKをベースにプロジェクトを運営するプロマネのことらしい。　しかし最近はプロジェクトに４つの質的変化が起きている。　それは①「イノベーション創造型」、②「新技術前提」、③「超高速（爆速）」、④「小規模集合体」の4つだ。　このような要求リスクや技術リスクが高いプロジェクトに対応するには「モダンPM」では通用しなくなっている。　そこでSoR(System of Record)からSoE(System of Engagement)に主眼を置くポスト「モダンPM]が求められている。

【論評】

私は30年以上前から上記4つのタイプのプロジェクトを担当してきている。　つまりこれらのプロジェクトの特性は何も今始まったことではない。　まあ、この辺は講演や論文・記事の冒頭でよく使われる枕詞、「昨今の急激な環境の変化は・・・」とか「かつてないほどの経営環境の厳しい中で・・・」的なものと同じだと考えておこう。

ただ、記事の中の別枠で紹介されている木野准教授の「PMBOKガイドの特徴ゆえの限界」の内容には賛同できない。　もともとPMBOKは業界横断のプロジェクト管理に関する知識体系なのでプロジェクトの特性に合わせてカスタマイズするのが前提で当たり前のことだ。

IT系、特にソフトウエア開発では建設など他の業界に比べスコープの変更要求が発生しやすい。　文中で引用している「大規模プロジェクトでウォーターフォール型（以下WF型）のプロセスを前提にしているという批判がある」との指摘はそういう背景があってのことだろう。

しかし「PMBOKは1997年にはスパイラルモデルの例も掲載している。ところがこの柔軟性が逆にカスタマイズを難しくしている」という下りになると何を言っているのかわからなくなる。

更に「だからPMBOK以外でこれを補う必要があり、アジャイル系のプロセスを考慮した「拡張版」が出ている」とあるが、知識体系やプロセスでアジャイル開発（少なくともSCRUM)を語るのは読者に誤解を与える可能性すらある。(*1)。

まあ、それはともかくこの2つのPartで言わんとすることは昔からあったとはいえ上記4つの質的変化に対応すべきだという主張には反対する理由はないだろう。

だとするともっとストレートにアジャイル開発の話をすべきではないだろうか？
座談会にPMBOKの大御所、神庭氏をお呼びしている所を見ると編集部はもともとそのような話はしたくはない事情があるのだろうか？。
神庭氏はPMI日本支部でもお世話になり大先輩ではあるが、つい最近の講演の途中でいきなりPERT図（PDM)作成のワークショップを始めびっくりしたのをも覚えている（アジャイル開発では役に立たない）

(*1)知識体系やプロセスでSCRUM（アジャイル開発）を語れない理由。
詳細は別稿に譲るが、世界の企業の7割が採用しているSCRUMを2011年から推進しているが、導入時の失敗談を紹介したい。

誰しも新しいことにチャレンジするにはお手本から入る。

・2週間ごとにスプリント計画会議やレビューをやりながら要件変更に対応していくんだね。
・WBSの代わりにバックログやユーザーストーリーを作成して、
・EVMやPDMの代わりにバーンダウンチャートをタスクボードの横に見える化して、
・要件変更に備えてTDD、ペアプロ、CI等を導入するんだよ。
・朝はチームでスタンドアップミーティング,「やったこと」,「やること」,「課題」を話そう。

等など、いろいろ勉強して万全の体制で取り組んだが、その結果大失敗した。
それは頭の中（価値観、文化、意識等）がWF型だったからだ。　（これ以降は趣旨を外れるので別稿にて）

Part3 (ポスト「モダンPM」）

【骨子】

ここではポスト「モダンPM」を実践している6人のプロジェクトマネジャーの事例を紹介している。
以下にポイントだけ一言で説明する。

１、失敗マネジメント：失敗を早期に発見する「チーム規範」により変更により手戻りの最小化。
２、プル型マネジメント：変更が起きやすい社内イベントから先取りして対応する仕組みを導入
３、本気マネジメント：「個人の負担からチームの成功へ」のあたりはSCRUMの価値観と類似。
４、目標マネジメント：３C分析をベースに目指す姿をステークフォルダ間で共有し変更を抑える。
５、F/Sマネジメント：最上流での優先順位の明確化により不確実性を排除してから後工程へ。
６、自動化マネジメント：基本設計を徹底して自動化ツールを導入（NTTデータで独自開発）

【論評】

実際にご苦労されているプロジェクトマネジャーの取り組みが紹介されている。　そのような個別事例に論評するつもりはないが、このようなカスタマイズや工夫は積極的に行うべきだ。　そういう意味ではPart3の記事は是非とも参考にして頂きたいが、単なるモノマネではうまくいかないのは言うまでもない。

私が気になるのはやはり編集部がこのような事例をポスト「モダンPM」と言っている点だ。
私の知る限りPMBOKは勿論、それが世の中に出る前の「社内標準」に対してですら多くのプロマネはこのような工夫やカスタマイズをしてきた。　なぜ今頃になってポスト「モダンPM」なるバズワードまで作って騒ぎ立てているのだろうか？

Part4 （プロマネが持つべき「イノベ案件」６つの心構え）

【骨子】

ここでまた新しい用語「イノベ案件」が出てきたが、これは「イノベーション創造型」の案件のことらしい。
（そして「ノベーション創造型」の定義は2月号でも明確にされてないのだが）

6つの心構えとは以下のことらしい。

１、スコープの変化を許容する
２、評価するものだけを作る
３、失敗を自然なことと受け入れる
４、自前主義から脱出する
５、多様性を尊重する
６、外部の意見を重視する

【論評】

記事の内容は「価値命題（バリュープロポジション）」、「インセプションデッキ」、「ユーザーストーリー」、「コスト、期間、要件の関係」、「ステークフォルダの巻き込み」・・・　らしき説明や図が続くがこれらはアジャイル開発手法で使われるものだ。

何故正面からアジャイル開発の事例紹介などをしないのか？

編集方針なのか、何か別の背景や事情があるのかは知る由もないが、WF型のPMBOKに軸足を置いたままアジャイルの解説をするのは記者としてもしんどいはずだが、それは「余計なお世話」というものか。

まあ、それでもどれだけ同じようなことを言っているのかは『百聞は一見に如かず』、上記のうちの一つだけ例をあげてみよう。

アジャイル開発では、「要件からリソース、期間を見積もるのではなく、与えられたリソース、期間からコストを見積もる」ことを基本としているが、それを説明するすこぶる有名な絵があるのでそれらを比較してみよう。

 

【アジャイル開発でよく使われるバイブル的な絵】

 

 

【日経Systemsが5月号のプロマネの6つの心構えに登場する絵】

 

全体所感

私が初めて初めてプロマネを担当したのは今から30年以上前のことだ。
ようやく一人前のプロマネとして認められた頃にPMBOKと出会ったが、最初の印象は最悪のものだった。

「プロジェクトは生き物だ、こんな頭でっかちの知識等意味がない」

しかしその後、PMBOK等を使いながら後輩たちの指導に当たる中で考え方が変わった。
もし自分も最初にこれを勉強していたらプロマネのスキルがもう少し早く上がったはずだ、そしてPMBOKを適用する際にどのようにカスタマイズするのかまで含めて教えればいいんだ、ということが実感できたからだ。

PMBOKが素晴らしいと思うのは、はアジャイル開発をやってもその知識体系は決して無駄にはならない、その普遍性がバイブルと言われる所以だろう。

ただ、だからといってITの世界ではこれだけアジャイル開発の導入が浸透しているなら（IPAのセミナー時に使われた右図参照）PMBOKもそれに合わせるべきかだ、という意見があるが私はそれには反対だ。

「逆はまた真なり」はこの場合には通用しない。なぜなら価値観やチームメンバーの意識がその成否を決めるアジャイル開発をPMBOKのようなプロセス体系や手法で語るべきではないからだ。

アジャイル開発を意識してPMBOKの「拡張版」が出版されているらいしが、アジャイル開発はPMBOKの「拡張」というとらえ方にも賛同できない（まだ読んでないので断定はできないが）

じゃあどうすれな良いのかは今後の課題、PMI日本支部の仲間たちとも議論してみたい。

ソフトウエア開発プロジェクトを成功に導くために

PMBOKは業界横断のプロジェクト管理のための知識体系、　特にプロジェクト特性の違いが大きいIT系のソフトウエア開発では必ずプロジェクトに合わせてカスタマイズする。

その際、プロジェクトを成功に導くために重要なポイントを3つ挙げておく。

①プロジェクト当初にどれだけ期間中に起きることを正確に予測できるか？

②ステークフォルダとの円滑なコミュニケーション。

③部下の思いをくみ取りチームへの貢献がやりがいに感じられるようにチームビルディングを行うこと。

これを実現するには上流工程でリスクを徹底的につぶしておくこと、そのために有効なのがプロトタイプ開発だ。
新規技術採用のリスクがあるならその実態がわかるまで使い倒してみること、UI(UX)の変更リスクがあるならステークフォルダが納得するまで試作・検証を繰り返すことだ。

プロトタイプ開発は手戻りのリスクを低下させるとともに、そのコードは製品版の開発でも参考になる、つまり後工程を短縮させる効果もあるのだ。

そのような活動を続けていると「難しい」と思ったプロジェクトが次第に簡単に思えてくる。　そうなればしめたものでプロジェクトの成功は半分約束されたというとちょっと楽観的だろうか（笑）。

ただし、これらの作業がいくら重要だからと言っていつもまでもやっているわけにはいかない。
目安は『全期間の三分の一が過ぎた段階で詳細要件まで決まってない場合には日程遅延するリスクが急激にあがる』ことを念頭に入れてプロジェクトの組み立てを行うこと。　これは理屈ではなく何百とみてきたプロジェクトから得られた経験則なので一つの羅針盤として使ってみてはどうだろうか？

そして、最初から要件が決まらない、あるいはビジネス上の優位性の為に途中で要件を受け入れざるを得ない場合（Time2Marketを狙う）には躊躇なくアジャイル型の開発にすることだ。

アジャイル開発に対応するにはWF型の価値観や文化を変える必要があるので机上での学習以外に、ワークショップへの参加やコンサルによる指導などを通じてすぐにチーム編成し立ち上げられるようにしておくとよいだろう（少なくともスクラムマスターは育てておくべきだ）

 

1986年にフレデリック・ブルックス氏がソフトウエアエンジニアリングについて語った

” No Silver Bullet”  　（銀の弾丸はない）

この言葉はプロジェクト管理にもそのまま当てはまる。　我々は魔法を使えない限り、できることは限られている。

それは「手戻りの最小化」だ。

それを改めてかみしめること、そして貴方も素晴らしいプロジェクトマネジャーになられることを切に願ってやまない。

以上

 

 

 

 

2016年5月18日