Synamon’s Engineer blog

Synamonでは、VR空間に複数人が同時に接続可能で、多彩な標準機能を搭載している『NEUTRANS』という独自のVRシステムを開発しています。ビジネスなどの現場でも使いやすいよう、独自の機能や技術を日々追究しています。このブログでは、『NEUTRANS』開発の裏側にあるVR技術と、それを支えるUnityやC#といった技術の話を書いていきます。

PMBOK 7th 勉強会 第2回 【Section2: 価値提供のためのシステム】開催しました

PMBOK 7th 勉強会 第2回 開催しました

エンジニアの松原です。先日社内でPMBOK 7th 勉強会の第2回目が開催されました。開催の経緯などは以下の記事を読んでいただけると分かりやすいかと思います。

synamon.hatenablog.com

また、前回の記事は以下になります。

synamon.hatenablog.com

今回も第2回の勉強会で行った内容についてとその振り返りについて記事に書き起こしました。今回はThe Standard for Project ManagementのSection2から読み進めた内容になります。

PMBOKとは

PMBOK(Project Management Body of Knowledge)とは、PMI(Project Management Institute)がプロジェクトマネジメントに関するノウハウや手法を体系化してまとめた本です。

1996年の初版出版以来、4年に1度くらいの頻度で改訂が繰り返されており、2021年8月に第7版が出版されましたが、まだ日本語訳された本が無いので、勉強会では英語版を参加者各自が日本語に翻訳して読み進めています。

Section2: 価値提供のためのシステム

The Standard for Project Management(以下ではPMBOKと略します) のSection2では前回の勉強会でも項目に登場した『価値提供のためのシステム』について、またそれがガバナンスやプロジェクト、機能、プロジェクトの環境、またはプロジェクトマネジメントとどう関わるのか、そして組織にとって何が価値になるかを説明しているセクションになります。

サブセクションでは以下のように分かれており、それぞれの目線からの組織の価値に関する要素を説明しています。

2.1 価値の創造

組織における価値の創造について説明しています。組織はステークホルダーに向けて価値を生み出しており、価値の例として以下のようなものがあります。

  • 新しいプロタクトやサービスを作ることや、顧客またはエンドユーザーのニーズを見つけること
  • 社会的または環境的な貢献を行うこと
  • 効率、生産性、有効性や応答性の向上
  • あるべき将来のための組織の変化を促す取り組み
  • 既存のプログラムやプロジェクトから継続的な利益を生み出す

ポートフォリオやプログラム、プロジェクトや運用は上記の例に挙げた価値を生み出す要素となっており、組織戦略をもって価値を生み出すシステムとして成り立ちます。 これらの要素はアウトカムをもたらし、アウトカムは利益を生み出し、さらにその利益が金銭的な価値や重要性、有益性などの価値を生み出すと説明されています。

PMBOKではさらにこれらの要素がお互いにどう関わってくるか、影響し合うかについて掘り下げていますが、この記事では割愛させていただきます。

2.2 組織のガバナンスシステム

ガバナンスシステムは、価値提供のシステムと連携して機能し、スムーズなワークフローを可能にし、問題を管理し、意思決定をサポートします。またガバナンスシステムは監視、制御、価値評価、コンポーネント間の統合、および意思決定の機能などを備えています。

PMBOKではこのサブセクションに詳細項目が置かれておらず、特筆する図表を使った掘り下げもなかったので、ここでの組織のガバナンスとは一般的な組織体制として捉えています。

2.3 プロジェクトに関連した機能

プロジェクトを効果的かつ効率的に実行するために必要な要素があります。ここではその各要素を『機能』と呼んでおり、プロジェクトに関連する機能は、1人の人物、グループ、または定義された役割に組み合わせることができます。 このサブセクションでは各機能の説明を掘り下げています。記事にすると長くなってしまうので、下記に機能の項目のみピックアップしました。

  • 監視と調整の提供
  • 現在の目的とフィードバック
  • ファシリテーションとサポート
  • 作業遂行、見識への貢献
  • 専門性の適用
  • ビジネスの取締や見識の提供
  • リソースと方向性の提供
  • ガバナンスの維持

これらの項目は職務内容として表せるものがある一方、職務として表現できる範囲よりも広い内容を含むものもありました。

2.4 プロジェクトの環境

プロジェクトは、価値の提供にさまざまな程度の影響を与える内部環境と外部環境内に存在し、運用されています。これらの環境は、計画やその他のプロジェクト活動に影響を与える可能性があります。さらに環境はプロジェクトの特性、ステークホルダー、またはプロジェクトチームに良い影響、悪い影響、または中間的な影響を与える可能性があります。

内部環境について

内部環境は組織内部で、組織自体、ポートフォリオ、プログラム、別のプロジェクト、またはこれらの組み合わせから発生する可能性があります。成果物や取り組みやプロジェクトから学んだ内部知識を含んでいます。それらの分類についてピックアップしました。

  • プロセス資産
  • ガバナンスのドキュメント
  • データ資産
  • 知識資産
  • セキュリティと安全対策
  • 組織文化、ガバナンス構造
  • 施設とリソースの地理的分布
  • インフラストラクチャー
  • 情報技術ソフトウェア
  • リソース可用性
  • 従業員の能力

PMBOKではこれらの項目について簡単な説明はありますが、深い掘り下げはなかったので、こちらも一般的な組織にあるものと同じかと考えています。

外部環境について

外部環境は組織内のプログラムやプロジェクトとは異なる外的な要因として紹介されていました。組織の外部の要因は、プロジェクトの結果を強化、制約、または中立的な影響を与える可能性があります。こちらも分類化されてましたのでピックアップしました。

  • マーケットプレイスの状況
  • 社会的および文化的影響または課題
  • 規定環境
  • 商用データベース
  • 学術研究
  • 業界標準
  • 財務上の考慮事項
  • 物理的環境

これらの項目についても簡単な説明のみでしたので、説明も一般的な内容で、特に目立った特徴はありませんでした。

2.5 製品管理に関する事項

ポートフォリオ、プログラム、プロジェクト、および製品管理の分野は、より相互に関連するようになっています。このサブセクションでは製品管理の分野について、また製品管理の分野がポートフォリオ、プログラム、プロジェクトにどう関わってくるかが書かれています。 製品管理には、人、データ、プロセス、およびビジネスシステムの統合が含まれ、製品のライフサイクルを通じて製品またはサービスを作成、維持、および開発します。

製品のライフサイクルのサンプルが図表で示されており、ポートフォリオのガバナンス、プログラム、プロジェクトがどのように製品のライフサイクル(導入期、成長期、成熟期、衰退期)と関連するかを表していました。

以下に製品管理の形態の例について挙げます。

製品ライフサイクルのプログラムマネジメント

関連するプロジェクト、補助プログラム、およびプログラム活動が組み込まれています。 非常に大規模または長期実行の製品の場合、1つ以上の製品ライフサイクルフェーズが十分に複雑であるため、一連のプログラムとプロジェクトを連携させる価値があります。

製品ライフサイクルのプロジェクト管理

継続的なビジネス活動としての製品機能の開発と成熟を監視します。 ポートフォリオガバナンスは、必要に応じて個々のプロジェクトをチャーターして、機能強化や改善を実行したり、他の独自の成果を生み出したりします。

プログラム内の製品管理

製品管理は製品のライフサイクルに組み込まれているプログラム内に適用されます。 製品の特定の利益を達成するために一連の補助的なプログラムまたはプロジェクトが実行されます。競合分析、顧客獲得、顧客支援を製品管理のコンピテンシー適用することでさらに利益をもたらします。 製品管理は独自の知識体系を持つ別個の分野ですが、プログラム管理およびプロジェクト管理分野内の重要な統合ポイントを表しています。

ここでいう製品管理は、明記はされていませんが、おそらく分析をもとにした一般的な製品のアップグレード、メンテナンスも含んでいるかと思います。

勉強会を実施してみて感じた課題

課題

  • Section2までの翻訳に手を付けられていないメンバーが多かった
  • 抽象度が高く、一般的な意味に対する紐づけが難しかった
  • 前回よりは進行はスムーズに感じたが、やはり時間繰りが難しかった(Section2は文章量自体は少なかったが第2回の勉強会で収まりきらなかった

対策

  • 議論時間を設けるため、本の内容を全部読み上げるのではなく、簡単に要約する程度にとどめる
  • 翻訳の効率化など

勉強会を終えた後の振り返り

今回から中身が入った内容が含んでいましたが、同じ系統の本を読みなれていないと単語の直訳の意味に引っ張られやすい印象がありました。細かいところでメンバーごとに感じている意味も違っていたのが印象的でした。(OperationやFunctionが取りうる意味、ProgramとProjectの違いなど)

また、私は上記の『外部環境』は自分で翻訳した際にあまり良い意味が含まれていないように感じていましたが、参加メンバーと議論した結果、良い意味も含んでいたことが良い発見になりました。

手作業での翻訳は個人のニュアンスが含まれるため、議論で意味を擦り合わせるのはやはり必要であると感じました。

次回予定

次回はSection3についてレポートする予定です。