View on GitHub

bok

IDPro Body of Knowledgeの日本語訳を載せていきます

抄録

この記事では、IAMプロジェクトのプロジェクトマネジメントの実践について、基本的なプロジェクトマネジメントの用語と実践について説明しています。IAMプロジェクトは、一般的に影響を受けるシステムの数が多いため、プロジェクトマネジメントの要件と、複数のチーム、部門、組織をまたいだ連携が期待されることは、関係するステークホルダーにとって特に重要である。

キーワード ガントチャート、プロジェクトマネジメント、アジャイル

どのように引用するか。

Williamson G. & Scholefield C., (2020) “Introduction to Project Management for IAM Projects”, IDPro Body of Knowledge 1(1).

IAMプロジェクトのためのプロジェクトマネジメント入門

グラハム・ウィリアムソンとコリー・スコールフィールドによる

© 2020 Graham Williamson, Corey Scholefield, and IDPro

プロジェクトマネジメントの重要性

IAMの実務家は、正式なプロジェクト・マネージャーなしで、ITシステム・グループの管理の下でIAMプロジェクトを進めるというシナリオに精通しているかもしれません。新製品やサービスを導入するこの方法は、システムをインストールしたり更新したりするのに便利な方法と考えられるかもしれませんが、長期的には組織のコストが高くなる可能性があります。IAMサービスは、組織内の多くの重要なシステムに接続されています。接続されている様々なシステムへの影響を考慮せずに、必要なリソースを管理せずに、あるいはすべての利害関係者にその取り組みについて助言を与えずに、そのサービスに変更を加えることは、標準以下の展開をもたらすことになります。

プロジェクト管理にはコストがかかります。通常、プロジェクトの総支出の5～10%程度ですが、他の投資と比較すると最高のリターンが得られます。

専門用語

プロジェクトマネージャーの特徴

IT部門では、プロジェクトマネージャーは下っ端の社員と思われがちです。プロジェクトマネージャーは、上層部からの援助を最小限に抑え、組織内での可視性を最小限に抑えながら、プロジェクトを期限内に予算内で実施することを期待されています。実際には、プロジェクト・マネージャーには、プロジェクトを適切に監視・管理できる十分な権限とリソースが必要です。また、上層部の代表者で構成される運営委員会との定期的なコミュニケーションも必要です。

プロジェクトマネージャーに必要不可欠な2つの主要な特性があります。

予測可能性 経営者は驚きを好まない。プロジェクトマネージャーは、プロジェクトの期間と関連コストを、一定の信頼度で決定し、報告しなければなりません。 柔軟性 プロジェクトマネージャーが承認されたガントチャートに忠実に従っていた時代は終わりました。IT プロジェクトは通常、スコープの変更、他のプロジェクトへの依存、リソースの可用性の変化に対応するために、実行中に何度もベースラインの変更を行うことになります。 プロジェクトマネージャーはプロジェクト管理の5つの構成要素の能力を要求する。

PMIフレームワーク

定義によれば、プロジェクトには開始と終了がなければなりません。通常の業務は決してプロジェクトワークではなく、プロジェクトマネージャーのスキルを必要としません。プロジェクトの開始前には、コンセプトを定義するための準備作業があります。開始から完了までの間に、プロジェクトの仕事を定義する離散的な段階があります。プロジェクト完了後、成果物は運用状態に入る。

コンセプト

プロジェクトは必要性から生まれます。IAM の世界では、そのようなニーズの例として、スタッフのオンボーディングとオフボーディングのために ID 情報をよりよく使用することでコストを削減し、セキュリティを向上させる必要性や、エンタープライズ LDAP ディレクトリのアップグレードの必要性などがあります。このようなプロジェクトは通常、ビジネス・リソースではなく IT リソースによって開始されますが、事業部門のリソースがプロジェクトを開始することもあります（例えば、CAPEX 予算を節約するためにアプリケーションをオンプレミス環境からクラウドに移行する場合など）。プロジェクト・スポンサーは、要件を伝え、プロジェクト・チャーターを設定し、必要な活動のコストと期間の評価を開始します。スポンサーは通常、この段階で資金を提供し、プロジェクトマネージャーを雇って計画段階を完了させます。

プランニングステージ

プロジェクトを進めるための承認が得られたら、プロジェクトマネージャーは、プロジェクトのスコープを定義するために利害関係者と関わることになります。この時点でプロジェクトの規模と複雑さが増大するのは通常のことである。最初は電子メール・アカウントと AD アカウントの割り当てのために ID マネージャを配備することになっていたかもしれない IAM プロジェクトの場合、企業アプリケーションへのプロビジョニングを含むように拡大し、定期的な認証報告や再認証などの追加機能を含む可能性がある。この時点までに適切なプロジェクト利害関係者を関与させ、プロジェクト範囲の適切な定義を確保する必要がある。

プロジェクト・マネージャーは、必要な作業を定量化し、プロジェクト・スケジュールを構築するために、サブジェクト・マ ターの専門家を関与させる。計画段階は以下を含むプロジェクト計画を開発する。

スケジュール スケジュールは古典的なプロジェクト管理のGanttの図表によって普通表現される。高レベルのガントチャートはまた、アジャイルプロジェクト管理のために推奨されます。

スケジュールは費用が計算されるようにするためにプロジェクトに必要な時間枠および資源を定義する。

Stakeholder Analysis プロジェクトマネージャーはプロジェクトのstakeholdersのリストを組み立てる。このリストには、スポンサー、財務マネージャー、人事マネージャー、システムオーナー、ITグループの代表者などが含まれます。 資源計画 プロジェクト管理の基本的な考え方は「最高の資源は決して利用できない」ということである、彼らは典型的に完全に他の活動に従事している。プロジェクトマネージャーは、適切な利害関係者と交渉して、必要なリソースを確保し、それに応じてプロジェクトのスケジュールを変更しなければなりません。 コミュニケーションの計画 プロジェクト・コミュニケーション・プランは、プロジェクト・マネージャーがプロジェクトの進捗状況を報告するために、「誰が」「どのように」報告するかを定義します。プロジェクトチームは、プロジェクト用のファイルフォルダ、wiki、またはSharePointサイトを持つことになるでしょう。プロジェクトマネージャーは、定期的にプロジェクト報告書をステークホルダーに電子メールで送信し、プロジェクトレビュー会議の前に、会議の議題とステータスサマリーを運営委員会に送信します。

プロジェクト計画には、利害関係者やプロジェクトチーム内のすべてのコミュニケーションを記録するコミュニケーション登録簿を含めるべきである。

品質管理 プロジェクト成果物の適切な品質を確保するためのメカニズムを定義すべきである。このメカニズムには、プロジェクト文書のマネジメントレビューと、適切に構築されたテストとリリースの手順が含まれるべきである。 リスク管理 プロジェクトマネージャは、予測されるリスクを特定し、そのリスクを確率と影響度の観点から定量化し、適切なリスク軽減活動を盛り込んだリスク登録簿を作成する。 計画段階の最終段階では、プロジェクトの活動内容、期間、コストを十分に理解しておく必要がある。一般的に、プロジェクトのコストと期間は、10％以内のマージンで把握できる。

時間とお金の面でのプロジェクトコストのこの理解は、組織がプロジェクトに必要なリソースを提供するかどうかについての情報に基づいた決定を行うことを可能にします。プロジェクトを進めないという決定は、プロジェクトを進めるという決定と同じくらい、プロジェクトマネージャーにとって成功した結果である。それは、組織がそうでなければ早期に終了していたかもしれないプロジェクトへのリソースの支出を免れたことを意味し、その結果、関連するサンクコストが発生します。

展開ステージ

プロジェクトの展開は、使用するプロジェクト管理の仕組みによって異なります。

古典的なプロジェクト管理

従来のプロジェクト管理では、プロジェクトマネージャーは、個々のタスク、割り当てられたリソース、期間を示す詳細なスケジュールに従って、すべてのプロジェクト活動を管理します。プロジェクトチームは定期的にミーティングを開催して進捗状況を確認し、プロジェクトマネージャーが運営委員会にエスカレーションする必要のある問題について議論します。

古典的に管理されたプロジェクトの構成要素は以下の通りです。

チームミーティング プロジェクトチームは、定期的に（毎週または隔週で）進捗状況を確認するミーティングを開催する。これらの会議では、ガントチャートに対する進捗状況を全員で確認し、運営委員会にエスカレーションすべき問題があるかどうかを判断することができる。 運営委員会 プロジェクトマネージャーは、定期的に運営委員会に出席し、プロジェクトスケジュールの進捗状況を確認し、チームが特定した問題に対処する。プロジェクト状況報告書には、前回の会議以降の進捗状況、運営委員会で解決すべき問題点、次の期間の活動予定などを記載する。 フェーズの移行 プロジェクトのスケジュール（ガントチャート）には、プロジェクトを構成するフェーズが示される。各フェーズの終了時には、運営委員会がそのフェーズの成果物を確認し、フェーズ移行を承認するかどうかを決定します。 成果物の承認 各プロジェクトの成果物は、正式に承認されなければならない。この承認には、通常、適切な品質レベルで成果物が作成されていることに同意しなければならない適切な利害関係者が関与する。 プロジェクトの終了 プロジェクトには、常に適切なプロジェクト終了手順が含まれていなければなりません。この手順は、通常、うまくいった活動とプロジェクトからの学習を文書化する正式なプロジェクトレビューを含むでしょう。”歴史から学ばない者は、それを繰り返す運命にある。

アジャイル

現在、多くの組織がプロジェクトの実行フェーズにアジャイルプロジェクト管理を採用しています。アジャイルプロジェクトでは、プロジェクトの進め方を簡単に変更することができ、問題解決が運営委員会の会議を待っている間、「古典的」に管理されているプロジェクトで起こりうる遅延を回避することができます。アジャイルプロジェクトでは、プロジェクトを短いタスクに分割し、数日ごとに「立ち上げ」会議で検討します。

プロジェクトウォール アジャイルプロジェクト管理の本質は可視性です。プロジェクトウォールは、プロジェクトチームが完了したタスク、現在のタスク、待機中のタスク、リソースの割り当てを見ることができる物理的または仮想的な場所を提供します。 スプリントとスクラム これらの用語は文脈によって使い分けられています。スクラムは、定義された機能を提供するために反復プロセスを使用するフレームワークです。それは製品やサービスであったり、既存の製品の新しい機能の一部であったり、例えば、DBMSコネクタをIAM環境にデプロイするなどです。スプリントとは、通常、スクラムコンポーネントと呼ばれる、スクラム成果物に貢献する期間限定の活動のことを指します。 成果物の受け入れ アジャイルプロジェクト管理アプローチを使用している場合、成果物のレビューと受け入れに悩まされることがあります。スプリントチームは、ある作業の完了をアドバイスし、成果物を正式に受け入れることなく次の作業に移ることがあります。モジュールや成果物の受け入れを記録するメカニズムが必要です。受け入れテストは、実行可能な製品のために確立された要件が達成され、実証可能であることを確認します。 プロジェクトの終了 古典的に管理されたプロジェクトでは、必要なプロジェクトレビューのためにチームミーティングを行うことができます。しかし、多様な数の参加者が成果に貢献しているアジャイルプロジェクトでは、プロジェクトの終了を管理することが困難な場合があります。プロジェクトが完了したことをすべての参加者が同意し、使用されたリソースを再割り当てできるようにするためのメカニズムが必要です。

PMOの問題

プロジェクトマネジメントオフィス（PMO）がある組織では、IAMプロジェクトは企業の手順に従わなければなりません。通常、PMOには、すべてのプロジェクトが通過しなければならない「ゲート」が定義されています。例えば、一般的には、プロジェクト承認ゲートがあり、適切な管理者がプロジェクト計画をレビューし、承認を示す。通常、リソースの割り当てを承認するための予算のレビューがあるだろう。ソリューションアーキテクチャを承認するためのアーキテクチャレビューがあるかもしれない。ガバナンスの成果のレビューも行われるべきである。PMOはこの活動を指揮するべきである。

PMOの利点の一つは、組織内のプロジェクトを可視化できることである。この可視性は IAM チームにとって有益であり、IAM チームは、ID コンポーネントを含むプロジェクトが適切に識別され、 適切な作業プログラムに組み込まれていることを確認する機会を得ることができる。たとえば、認証ゲートウェイがインストールされている場合、開発中のアプリケーションは、LDAP ルックアップを維持するのではなく、ゲートウェイを使用するように変更する必要があります。PMO がなければ、IAM チームがプロジェクトに影響を与えることは困難な場合があります。

PMO は、アイデンティティの問題についてプロジェクトマネージャを教育し、組織内の IT プロジェクトに IAM 要件を挿入する機会を提供します。プロジェクト・マネージャーは、PMOのフレームワークを使用して以下のことを行います。

プロジェクトの “ゲート “を通してプロジェクトを管理する。

プロジェクトの進捗状況を組織の管理者に伝える。

プロジェクトの目標が承認された予算とスケジュール内で完了したことを組織内で承認してもらう。

IAMプロジェクト

優秀なプロジェクトマネージャーは、テーマに関係なくプロジェクトを軌道に乗せることができる可能性が高いのに対し、IAMプロジェクトのプロジェクトマネージャーがテーマに精通していない場合は、そのテーマに精通しているプロジェクトリーダーが必要となります。プロジェクトマネージャーにとって最も重要な要素は、プロジェクトのスコープです。スコープを適切に決定するためには、プロジェクトの性質を理解し、他のシステムへの影響を理解する必要があります。以下の質問は、IAMプロジェクトの計画段階で質問される質問の例である。

アイデンティティ管理

アクセス制御

ガバナンス

結論

プロジェクト管理の方法論は、たとえ小さなものであっても、あらゆるIAMプロジェクトに適用されるべきである。プロジェクト管理は、構造化されたプロセスが活動に適用され、影響を受けるビジネスユニットへの活動の影響が考慮され、必要に応じて計画に含まれていることを保証します。IAM活動をプロジェクトとして管理しないと、ミスが発生し、追加コストが発生する可能性が高くなります。

Project Management Institute, “PMBOK® Guide and Standards - Practice Standards & Framework” https://www.pmi.org/pmbok-guide-standards/framework