スポンサードリンク

毎年楽しみのプロジェクトマネジメントDAY
今回７回目とのこと

これからのPM/PLが使うべきフレームワークとは？
ここでいうフレームワークは
きっとPMBOKのことだろうなと思いつつ参加

フルに聞く時間はとれなかったので
８つセッションのうち
厳選して２つに参加です

参加したセッション

見上げるか、見下ろすか

プロジェクトとプログラムの視線
神庭ＰＭ研究所 神庭 弘年 氏

SI系のプロマネをずっと経験されている神庭さん
毎年楽しみに聞いています

DXは・・・日本はどうもかなり遅れているらしい
アメリカとの比較で顕著
アジャイル、協調、マインド・スキル、人材の質と量

プロジェクトマネジメントの価値理解について
グローバル５５％・日本８６％
日本は勝ちがあると認めている
世界最高クラス！
ところが上位（PgMP・PfMP）の
フレームワークを理解していない

効率の追求から視点を切り替えよう
産出÷費用
費用を小さくする努力が続けられていた
これを、産出できるものをどれだけ大きくできるかの努力が必要
アイディアとトライ、創造力＝スキルと発想の尊重＝多様な個人の尊重

年功序列・前例踏襲ではダメ

デジタル投資は既存ビジネスの維持・運営に約８割がしめられている
成果が出ているのは１割未満

・トップダウンで一斉にやらないと無理
・行動指針を示す
・グローバルに通用するように
・顧客志向を徹底
・組織レベルに集約する
どうやって変容（トランスフォーメーション）するか

現行システムのスリム化が必要になっている
新しい試みをしていかないと
サイロ化とクラウド化が分断を助長している

やろうとしているがなぜできないかを
解きほぐして「できる」にしていくことにある
→論理的な構造を描いて具体的な方法に展開する

プロジェクトにしてから考えては遅い

上流の検討はいつも小規模
いろんなスキルの人を集めないとできない
アジャイルのマインドが必要
プロジェクトマネジメントだけでは足りない
単一プロジェクトで達成できることは殆ど無い

ポートフォリオ・プログラム
プロジェクトはプログラムの中にある
認識不足ではうまく行かないよ

大きなプログラムのなかでどうやって達成するか
構造化した枠組みで実践することが必要

プロジェクトの前に戦略部分が変わってきている
企業の戦略がまず変わるのだ

全体を俯瞰し
組織変革を具体的な実行計画に展開でき
実行できる人材が必要

Program　Managementの枠組みの適用
個人流・自社流ではダメ

BRM（ベネフィットマネジメント）の話
企業戦略、経営計画はトップダウン構造
中期経営計画が目指しているものを
一貫性ある枠組みで捉え、分解し施策として実行し
狙った価値が継続的に得られていることの確認という
全ライフサイクルを視野に入れる

修羅場になる領域でもある
ベネフィットを定義する
→ベネフィットマッピング　事業計画に近い
普段からやっているはず・似たようなことをやっているはず
難しくないけどなんでできてないの？
ベネフィットの分解　アウトカムの明確化
なんのためのシステムかも明確にする

ベネフィット実現計画書
優先順位を決めていくのが
ポートフォリオマネジメント

我流でやると他人の経験を利用できないのが弱点

ベネフィットマネジメントライフサイクル
冗長なベンダー契約、企業インフラ、組織体制、不良なプロセスなどを廃止するのが目的
→　つぶす・やめる・かえる　必ず軋轢が生じる
時間も人も金もかかる　測定しないといけない

プログラムマネジメントオフィスにもフォーカスが当っている
プログラムマネージャを置く・努力し続ける必要がある
プロジェクト終了後の成果が出ているか
５年から１０年見ていく必要もある
実行部隊ではなく報告部門になる

持続性が必要
喉元過ぎたら・・・ではダメ
ベンダー丸投げでもダメ
プロジェクトを追っているとなかなか見えてこない

DXは手段であり達成するためのプロセス
同じことをやってたら同じ結果にしかならない

上流は規模が小さい　良いチームであることが必要
戦略主導　その変化に徹頭徹尾対応、追従すること

多様なリスク
情熱・公平・責任感・誠実・正直
まとめるリーダーに雛形はない、全人格がさらされる
リーダーは自分にできる自分なりのスタイルでしか対応できない

自分の強みを知り、無理なく強みを発揮できることが一番確かなやり方になる
（コンピテンシーと言う）

こういうチームが機能するメンバーでは、PMBOK第７版は腑に落ちるはず
文化が大きく変わっている

プログラムの視点を身につければどうすればいいか
これからのチャレンジとなる
自分事として考えられるかが必要

なぜ今、「原理・原則」なのか

PMBOK®ガイド第7版から見るこ
れからのシステム開発現場に必要な考え方
株式会社アイ・ティ・イノベーション 奥田 智洋 氏
もともと富士通
自動車関連の基幹システム開発をやられていた奥田さん

プロジェクトとは
独自・有機的　つまり
やったことないことを決められた期日までにやりきること
難しい・・・
知識スキルツールを活用しプロジェクト作業を導く

システム開発が難しい理由
・人に依存
・要求機能が変動
・品質測定が困難

それに加えて
・手法の変化
・ユーザが要求事項を描けない
・外部との接続増加、範囲拡大
で更に困難に

ＰＭＢＯＫ７版から原理原則、パフォーマンス領域へ

なぜ、原理原則なのか
DX時代は今の延長線上には無い

◯スチュワード・ステークホルダー・価値
スチュワード
執事に代わって家の様々なことを取り仕切る職責
価値の提供
いままでは単独で価値提供していたが、
より高い価値を生み出すには
業界内・業界外を巻き込んだ価値創出
ステークホルダーと開発側の認識違いがある
違う目的では高い価値は出せるのか？？？
無理な依頼があると・・・
メンバーが疲弊せず攻めの姿勢
→何が望みか考える・共に創る
　自分のプロジェクトとして考える
構想も一緒になって推進する必要がある
Why・What・How

◯チーム・リーダーシップ
チーム内の発想の多様性
MyTeam 期待というより信頼（信じる）
仲間を知るのは自分を伝える
愚痴を吐き出せる場
愚痴の中に本音が出てくる

◯テーラリング
なぜテーラリングが必要か
標準が土台だが
DX時代の場合は、そのまま使っていいのか？
それをやってれば大丈夫は危険
どこに向かうのかを理解した上で
新たな価値創造にむけて仕立て直しが必要

感想

神庭さんの話は５回位聞いていますが
毎回新しい発見だったり
トライする内容が具体化される
越境だとか心理的安全性だとか
サーバントリーダーシップだとかパーパス組織とかの
端的な表現ではなく
プログラムマネジメントを軸にした
つまり複数のまたがったプロジェクトマネジメントをどうやって
良い成果に繋げていくかということ

ＰＭＢＯＫ７版は
どこに進むかを把握した上で
原理原則を理解して、うまく活用する
原理原則の理解度を少しずつ上げていけばいい
今、隔週で読書会やってる効果もあるかも

自分ごと化はいつも大事だ
自分の生き方を場に晒せ
それが結果として一番早い