プロジェクト ガバナンスにおけるソリューション アーキテクトの役割
プロジェクトにおけるソリューション アーキテクトの役割は、経験と専門知識を生かして問題と変更を評価することです。 ただし、特に Microsoft Power Platform ではプロジェクトでの変更の監視は非常に簡単です。 その結果、ソリューション アーキテクトはプロジェクトを確実に進めることよりも、変更の監視に集中しすぎる可能性があります。 したがって、ソリューション アーキテクトは問題や変更の評価と分析を行う際に、他のプロジェクト チーム メンバーを支援する必要があります。
新しいソリューション アーキテクトが直面する課題の 1 つが、作業者の役割を離れ他の人を導き支援する役割になるプロセスです。 ソリューション アーキテクトは、他のプロジェクト チーム メンバーに時間を割き、成長をサポートする必要があります。
ガバナンスの定義に取り組む
Microsoft Power Platform プロジェクトでは、変更を行うのは単純でしょう。ただし、複数の小さな変更を行った結果ガバナンス プロセスが低下すると、プロジェクトが失敗することもありえます。 たとえば、ソリューション アーキテクトは変更を評価するプロセスが、変更を実装することよりも時間がかからないようにする必要があります。
プロジェクト ガバナンスのプロセスと手順の定義には、ソリューション アーキテクトの関与が不可欠です。 その関与により、使用される Microsoft Power Platform テクノロジに対して適切で、不必要なオーバーヘッドを引き起こさないプロセスと手順を実現できます。
実践的なフィードバックの送信
ソリューションアーキテクトは、多くの場合顧客とチーム メンバーの仲介者です。 したがって、両者にフィードバックを提供する必要があります。 主に、ソリューションの形成に役立つフィードバックを提供する必要があります。
フィードバックは、提案依頼 (RFP)/作業明細書 (SOW) の作成の早い段階で行うことができます。 ただし、フィードバックはプロジェクト全体で継続的に実行する必要があります。
ソリューション アーキテクトは、フィードバックが建設的で実用的であることを確実にする責任があります。
問題の処理
場合によっては、ソリューション アーキテクトは受け入れがたい問題に関するフィードバックを提供します。 問題は時間とともに解決しません。 ソリューション アーキテクトはプロセスの早い段階で問題を認識し、共有する必要があります。
ソリューション アーキテクトが提供を差し控えてはいけない問題の例を次に示します。
- 書かれている要件のまま進めると、ユーザー ライセンスのコストが 87% まで上がる。
- この機能は非推奨である。
- 追加されたリレーションシップで、データのインポートに 30 日かかる。
- データ移行により 200 個の新しい列が特定され、このデータから文書化されていない 3 つの新しいプロセスが検出された。
ソリューション アーキテクトは、フィードバック (特に問題に対するもの) を実践可能なものにする必要があります。 「何かがおかしい」と言うのは無意味です。明確な行動喚起がされず、受け手は何が問題なのか見つけ出そうとしたまま放置されるからです。 そうではなく、ソリューション アーキテクトは、明確な問題ステートメントを作成し、参照やプロジェクトに対する潜在的な影響を提供する必要があります。
関与したプロジェクトを検討し、問題の処理方法と、それがプロジェクトにどのような影響を与えたかを思い出してみましょう。
人々が同じ結論に達するよう支援する
ソリューション アーキテクトは最も専門知識を持っているかもしれませんが、プロジェクト チームのメンバーと顧客が問題の解決に至るのを支援する必要があります。 「それはうまくいきませんよ」と言うことで、相手が身構えてしまうことがあります。 ソリューション アーキテクトは常に建設的であり、駄目出しし過ぎてしまうことを避ける必要があります。 代わりに、オプションを提供するか、要件を交渉しましょう。
「その構成は 100 万回の Power Automate クラウド フローの実行が必要な原因になりませんか?」といった回答を誘導するような質問をしてください。回答を誘導することで、相手が提案の影響について考えるようになります。 相手には、ソリューション アーキテクトが持っているプロジェクトの全体像が見えていない可能性があることに留意してください。
提案されたソリューションや変更に懸案事項がある場合は、その懸案事項を強調し、相手に検討して解決するよう促す必要があります。
他の人々の作業を確認する作業は、ソリューション アーキテクトの重要なタスクです。 誰かが行った作業を確認することと、自分で作業を行うことの違いはごくわずかです。 他の人の作業を確認する場合、ソリューション アーキテクトは建設的であるべきで、どこで答を見つければいいのか提案する必要があります。 たとえば、堅実な設計が提案されているのか明らかでない場合、ソリューション アーキテクトは概念実証またはその他のテストを作成を推奨し、提案されたソリューションの検証をする場合があります。
基本的に、ソリューション アーキテクトの役割は、プロジェクトに関係する人々と絶えず話し合い、プロジェクトのビジョンを確実に達成できるようにすることです。 メンバーに協力してソリューションが見つかるよう支援することよりも、チームを避け、アーキテクチャ設計を更新することに時間を費やすソリューション アーキテクトはうまくいきません。
次のユニットでは、ソリューション アーキテクトがプロジェクトで使用できる手法について説明します。