ITアーキテクトとプロジェクトマネージャーの違い【役割～スキル～仕事内容】

本記事ではプロジェクトマネージャー(以下、PM)とITアーキテクトの役割や具体的な仕事内容、求められるスキル・KPIの違いについて触れていきます。
イメージしやすいように、以下のような架空のプロジェクトを前提とします。

■プロジェクト例
・とある会社の社内システムのうち、一部をオンプレミス環境からクラウド環境へ移行することが主目的。
・移行するシステム上に構築されているアプリケーションをビジネスフロー含めて見直すことが副目的。
・システム移行プロジェクトは1年半で本稼働することとし、プロジェクト全体予算は5億円。

【目次】

1. プロジェクト内での役割の違い
2. 仕事で求められるスキル・KPIの違いと共通点
3. 実際の仕事内容での違い
4. まとめ

プロジェクト内での役割の違い

ここではPMとITアーキテクトの役割の違いを具体例を挙げて説明します。

プロジェクト目的を達成できるよう管理することがPMの役割、プロジェクト要求事項をシステム構造の観点で実現することがITアーキテクトの役割

PMの職責はプロジェクトをマネジメントすることであるため、具体的なビジネスフローやアプリケーション作成、システム移行に対して直接的な責任を負いません。その代わり、プロジェクトの全体スコープを踏まえたうえでのスコープやコストを俯瞰的に管理することが求められます。これは、システム毎の担当者やインフラストラクチャーを構築する担当者、ビジネスフローを検討する担当者といったような個々の領域担当者の目線ではなく、プロジェクト全体・システム全体を通した目線での管理をする必要があるためです。

ITアーキテクトの職責は単なるシステムのアーキテクチャ最適化ではなく、ビジネスとシステム上の要求事項を満たすことになります。具体的なビジネスフローを作成することはしないものの、ビジネスフローを実現するに当たり最適なシステム構造を検討・具体化することが求められます。加えて、プロジェクトスコープとなるシステム全体の構造を最適化するために、1つのシステムに留まらない、システム全体を俯瞰的に見る能力が必要です。

IT関連の知識が必要な一方、ビジネス要求事項についての理解も必要な役割がITアーキテクト

上段で記載したプロジェクト想定であれば、オンプレミス環境からクラウド環境への移行がプロジェクトの主目的のため、ITアーキテクトの役割として最も重要なことは「クラウド環境でもオンプレミス環境と同等、あるいはそれ以上のアーキテクチャを構築すること」となります。

また、このアーキテクチャには「ビジネス要求事項を円滑に実現できるアーキテクチャである」ということも求められるため、ビジネス側で達成したいことを理解するとともに、アーキテクチャチームに目的を説明して必要なものを作成する方法やプロセス、スケジュールを明確化する必要があります。
まとめると、ITアーキテクトの役割は「アーキテクチャ構築」「ビジネス側とシステム側とのコミュニケーションハブ」という2点に大別されると言えます。

多角的な観点でのプロジェクト管理と意思決定が求められる役割がPM

プロジェクト全体のベースライン(品質、コスト、スケジュール、スコープ)を管理、あるいは意思決定する役割がPMとなります。
品質管理の観点では、プロジェクトで作成する成果物に対する品質基準を定義して品質実績値を管理することが求められます。
スケジュールの観点では、プロジェクトのゴールの定義や各工程をそれぞれどのようなスケジュールで進めるかを定義して進捗の実績(問題なく進捗しているか、遅延しているか、など)管理することが求められます。
コストの観点では、プロジェクト全体を把握したうえで予算がどの程度必要なのか、予算を踏まえて人員がどの程度必要なのかを決定・管理することが求められます。
スコープの観点では、プロジェクトで取り扱う対象・範囲を定義したうえで抜け漏れなく対応されているかを管理することが求められます。

まとめると、PMの役割は「プロジェクトを完了させるための戦略やベースラインを管理し、意思決定すること」「定義した管理内容を円滑に運用するためのコミュニケーション、調整を行うこと」という2点に大別されると言えます。。

仕事で求められるスキル・KPIの違いと共通点

システムに特化した能力が求められるITアーキテクトと、そうではないPM

ITアーキテクトはビジネス・システム要求を具体的なシステムアーキテクチャに反映させるという高度なシステム知見が必要不可欠になります。一方でPMにはそこまでのシステム知見は必要ではありません。
例外的な共通点として、両者ともにビジネス・システム要求を咀嚼したり、プロジェクトにおける課題・リスクを関係者からヒアリングして見える化するといった、コミュニケーション能力が必要となります。

ハードウェア、ネットワーク領域のスキル、ビジネス要求をシステム要求に落とし込む能力が特に求められるITアーキテクト

クラウド上での環境構築(IaaS、PaaS、SaaSなど)に関するスキルが求めらます。KPIはシステムのサービスレベルやビジネスフロー・システムフローの工数の観点で設定されることが多いです。
上記のプロジェクト例であれば、構築後のシステムではサービスレベルが○%向上した、以前と比べてビジネスフローやシステムフローが○%効率化された、といった観点で評価されます。

体系的なプロジェクト管理手法が求められるPM、QCDの観点でKPIが設定されるPM

PMBOKに代表されるようなプロジェクト管理手法に関するスキルがあることが求められます。KPIはQCD(品質、コスト、納期(スケジュール))の観点で設定されることが多いです。
上記のプロジェクト例であれば、構築後のシステムでバグなどが多く発生しておらず品質上問題ないか、当初予定通り1年半でプロジェクトが完了するか、予算5億円内で収まっているか、といった観点で評価されます。

実際の仕事内容での違い

ものづくりをするITアーキテクトとプロジェクト管理と方針決定をするPM

ITアーキテクトは、システムのアーキテクチャや構築を行うといった、直接的なものづくりのタスクが中心となります。
PMは直接的なものづくりのタスクはほとんどなく、ものづくりの結果現れてくる各種数値の管理や意思決定を行うタスクが中心となります。

プロジェクトにおけるシステムグランドデザインを作成することがITアーキテクトのタスク

プロジェクト対象となるシステムのグランドデザインを作成し、構築することがタスクとなります。
システムグランドデザインを作成するためにビジネス側からの要求事項をヒアリング・整理するタスクが発生し、システム構築時には利用サービス、ハードウェア、ネットワークの最適な組み合わせの調査、検討、動作検証というタスクが発生します。
プロジェクト途中で追加のビジネス・システム要求が発生した場合は、追加要求の実現による影響確認を行い、システムグランドデザインや構築するシステムへの影響度を明確化するタスクも行います。

プロジェクトを円滑に進行させることがPMのタスク

先ほどPMの役割で触れたように、プロジェクトのQCDやプロセスに関連した管理がPMのタスクとなります。
プロジェクト全体における進捗管理方法を策定して定期的に進捗を把握し、進捗遅延要因やプロジェクト全体に影響のある課題やアリスクを検知する、ということがPMに求められます。

プロジェクト途中で追加のビジネス・システム要求が発生した場合は、追加要求の実現による影響確認を行い、プロジェクトの稼働スケジュールや全体コストへの影響度を明確化するタスクも行います。ここでプロジェクトへの影響があまり無ければ追加要求を適用させる判断をすることとなりますが、プロジェクトへの影響が大きくスケジュールやコストに甚大な影響がある場合は追加要求を適用せずに別のアプローチを取る、という判断をすることもあります。

まとめ

これまで述べてきたITアーキテクトとPMの違いを要約すると以下のとおりとなります。

・プロジェクト全体のベースライン(品質、コスト、スケジュール、スコープ)に強い責任を求められる役割がPM。ITアーキテクトもベースラインとは決して無関係ではないものの、PMほどは求められない。
・ビジネス観点とシステム観点の両面で、プロジェクトの要求事項を満たすことができるシステム構造を作ることに強い責任が求められる役割がITアーキテクト。
・両者に共通する点は、対象(PMならプロジェクト全体、ITアーキテクトならシステムアーキテクチャ)への客観的・俯瞰的な目線とコミュニケーション能力が必要であること。

＜ITアーキテクトのキャリアに関するコラム＞

「ITアーキテクト」と「ITコンサルタント」の違い【年収～スキル・経験～キャリアパスまで】

AWSソリューションアーキテクト資格を取得したエンジニアのキャリアパス【転職事例含む】

“ITアーキテクト”のキャリアパス【よくある転職理由～転職者の生の声～企業選びの注意点など】

=================

今回の記事では、ITアーキテクトとプロジェクトマネージャーの違いについてご紹介しました。

キャリアについてお悩みの方は、ぜひアクシスコンサルティングにご相談ください。