（HF）つれづれてみました。 - IBM 現場SEのITな日々

現在は、基盤構築案件のPMを担当していますが、日々の仕事で忙殺されていると、普段はあまりゆっくり考えたりしないのですが、プロジェクト管理の切り口でキーワードをいくつか連ねてみたいと思います。

１．「プロジェクトの成功」と「経営の視点から見た成功」

プロジェクトメンバーの視点

情報システム開発ではプロジェクトメンバーにとっては、プロジェクトの成功裏の開発・完了こそが「プロジェクトの成功」を意味しますが、それだけではだめなんでしょうね。

経営の視点

お客様/自社含めて経営する立場からすると、プロジェクトのアウトプットが、運用に至って初めて、投資に見合った成果かどうかを評価出来る訳ですが、通常そのタイミングにはプロジェクトは解散していたりする場合があります。

やはり狙った効果を達成できなければ、たとえ予算内・期限内で、品質要求を達成してたとしても成功ではないんですね。

システム化構想の最上流は運用局面にあり、運用部門でシステム効果の結実が確認されて終結となるべきという考え方です。（運用局面での実証性あっての投資となる）

２．「プロジェクト」と「プログラム」・「ポートフォリオ」

環境変化が多い状況では、プロジェクトマネジメントの実践だけでは「組織戦略と目標」の達成が困難となりつつあるので、上位概念が考え出されています。

ポートフォリオ：

戦略的目標を達成するためにグループとしてマネジメントされるプロジェクト、プログラム、サブポートフォリオ、および定常業務の集合の事をいいます。

経営戦略の単位を識別し、規模や優先順位、リスクの判断と決定を通じて戦略達成を図り、プログラムマネジメントや、プロジェクトの取捨選択と資源配分の意思決定を行うのが、ポートフォリオ・マネジャー となります。

プログラム：

ポートフォリオ内でグループ化されており、ポートフォリオを支援するように調和のとれた方法でマネジメントされる、サブプログラム、プロジェクト、またはその他の作業によって構成されます。

切り出された戦略施策の塊を、プログラムとして定義。業績の達成を実現するフレームワークとして“プログラマブルな意思決定”プロセスを適用するのが、プログラム・マネジャー となります。

当然、上記を担当する人は会社の経営戦略や、戦略の施策に関して理解・把握している必要があります。

普段プロジェクトを担当している範囲では、あまり上記を意識せず、プロジェクトの成功裏の完了を目指して日々の活動をする訳ですが、経営者の立場から俯瞰してみると、全体の中から限られた箇所しか見ていない事に気がつきます。

３．プロジェクトと経営の期待を結びつけるためのプロジェクトマネージャの視点

近年のプロジェクトは、戦略プログラムと機能別組織（LOB:Line Of Business）が交差する機能の部分で発生するケースが増えてきているとの事で、プロジェクトの価値や責任、役割が、単体のプロジェクト・スコープからでは見えづらくなってきています。

プロジェクトを担当するプロジェクト・マネジャーにとって、プロジェクトと経営の期待を結びつけるためには、もう一段高い視点から状況を把握する枠組みが必要となってきているんですね。
（プログラムも群をしてとらえ、企業戦略を実装するためのポートフォリオマネジメントに統合された枠組み）

f:id:users-6h324:20170929142944p:plain

４．「ITIL V3」と「プログラムマネジメント」及び「ポートフォリオマネジメント」

ITサービスマネジメントのベストプラクティスを集めたフレームワークである「ITIL V3」は、開発したシステムの運用への移行、確実な運用、継続的な改善活動、そして再びサービス・ストラテジーのプロセスへの、ライフサイクルとしてまわしていく枠組みを提唱しています。

PMIの「ポートフォリオマネジメント」、「プログラムマネジメント、「ITIL V3」共にサービスライフサイクルの視点で捉え、ビジネス管理とのAlignmentを強く意識しています。

作るだけでなく、運用して、改善して作り直すといった事を継続して回す事が重要なんですね。

ITIL® (Information Technology Infrastructure Library)

５． BRM（Business Realization Management）

プロジェクトを進めるにあたって、プロジェクト管理の方向感や、期待されていること、経営戦略とプロジェクトの関係を理解している事が求められてきています。

ベネフィット(Benefits)の具体的な実現の枠組が必要という事で、PMI（Project Management Institute Inc.）にて、 BRM（Business Realization Management）が発表されています。

ベネフィットをもたらす事がプロジェクトの目的であり価値である

組織にベネフィットをもたらす事がプロジェクトの究極の目的であり、プロジェクトの本質を再認識したうえで実践することが大切という事で、フレームワークが考え出されています。

BRMのフレームワークでは、3つの段階

　１）ベネフィットの特定（Identify Benefits）

　２）ベネフィットの実行（Execute Benefits）

　３）ベネフィットの維持（SustainBenefits）

が定義され、各段階における課題や実践例が簡潔にまとめられています。

６．マイクロサービス・アーキテクチャー

クラウド上で稼働する IT システム開発プロジェクトからのフィードバッを集めたもので、小さなサービスを組み合わせて、一つのアプリケーションを開発します

以下の9つの特徴を持ちます。

・Componentization via Services（サービスによるコンポーネント化）

・Organized around Business Capabilities（ビジネス機能に基づいたチーム編成）

・Products not Projects（プロジェクトではなく製品として捉え開発運用する）

・Smart endpoints and dumb pipes（インテリジェントなエンドポイントとシンプルなパイプ）

・Decentralized Governance（非中央集権的な言語やツールの選択）

・Decentralized Data Management（非中央集権的なデータ管理）

・Infrastructure Automation（基盤の自動化）

・Design for failure（障害、エラーを前提とした設計）

・Evolutionary Design（先進的な設計）

上記に、Products Not Projects（プロジェクトではなく製品として捉え開発運用する）というのがあります。

製品として捉えるとの事です。

プロジェクトのアウトプットを一連の機能として見るのではなく、製品としてどのようにユーザーのビジネス能力を高める事の助けができるのかといった事に焦点が当てられます。

いままでの、アプリケーション開発ではプロジェクトを通して一連の機能を作成・提供し、完了後はメンテナンス組織に渡され、それを構築したプロジェクトチームは解散する事となります。

それが、プロジェクトではなく製品として捉え開発運用するとなった場合には、開発チームが本番プロダクトの全面的な責任を負う「開発した人が構築し、実行する」とう流れに変わります。

作るだけでなく、運用して、改善して作り直すといった事を継続して回すところを主眼においているところは、サービスライフサイクルの視点で捉え、ビジネス管理とのAlignmentを強く意識する「ポートフォリオマネジメント」、「プログラムマネジメント、「ITIL V3」とも通じるものがあると思ったりしています。

７．フルスタック・エンジニア

「開発した人が構築し、実行する」という事になるのであれば、必要となるのは、

Webアプリサーバー関連技術だけでなく、ネットワーク、OS、DB、ビジネスロジックの知識が必要になります。

従来であれば専門の技術者が分業してプロジェクトを進めるのに対し、フルスタック・エンジニアはすべて一人で対処出来うるスキルを持っているイメージだそうです。

ちなみに、フルスタックの世界には、専任のPMはいないとの事。

どちらかといえば、開発者がFull-stack Engineerスキルを身に付け、PMPレベルのPM知識を付け、アーキテクティングが出来るようになる事が求められていくそうです。

おわりに

最近の流れを受けて、「デベロッパーこそ新しいキングメーカー」と言われているようです。

（The New Kingmakers: How Developers Conquered the World

　ISBN: 978-1449356347（オライリー））

デベロッパーのコミュニティでは新しいルネッサンスが進行中だそうで、そちらの動向も注目しておいた方が良いと思います。

（開発者が数人でビジネスを小さく立ち上げて、大きく起業）