チームとして働く
ソリューション アーキテクトは、通常、プロジェクトで最も経験が豊富であり、プロジェクトの多くのタスクで最も高いスキルを持つ人がなります。 しかし、ソリューション アーキテクトが 1 人ですべてをこなせるわけではありません。 ソリューション アーキテクトは作業を分類し、それぞれをチームで最も適切なメンバーに委任する必要があります。
ソリューション アーキテクトの重要な役割はプロジェクトのテクニカル ソリューション全体に対してビジョンを持ち、そのビジョンをチームに伝えることです。
ロール モデルになる
どのプロジェクトでも、ソリューション アーキテクトには、チームのメンバーから一目置かれる、ロール モデルとしてふさわしい人がなります。 エンゲージメント マネージャーとプロジェクト マネージャーはプロジェクトを率いる一方で、ソリューション アーキテクトは「真のリーダー」として、チームの調子やペースを整え、チームワークを促します。 そのため、ソリューション アーキテクトは、他のメンバーに対し模範的な行動を示す責任があります。
さらに、ソリューション アーキテクトは、プロジェクト チーム メンバーのスキルや経験を高め、指導し、新しいことに挑戦してスキルを得るよう促す必要があります。
チーム スキルを評価する
ソリューション アーキテクトは、メンバー全員のスキルについて内訳を作成し、それに基づいて機能的および技術的なデザインを行います。 ソリューション アーキテクトがチームを選べることはほとんどなく、また最高に優秀な人材だけがチームに集められるわけでもありません。
そのため、ソリューション アーキテクトはメンバーのスキルや弱点を評価し、メンバーそれぞれに作業を適切に割り当てる方法を学ぶ必要があります。 ソリューション アーキテクトは、チームのメンバーが Microsoft Power Platform についてどの程度理解しているかを、履歴書を見ただけで判断するべきではありません。 それよりも、たとえばマネージドとアンマネージドのソリューションをどのように使い分けるかや、ビジネス ルールや Power Automate クラウド フローの使い方についてメンバーにインタビューで細かく質問し、答えてもらうことで、知識をテストする必要があります。
また、小さなタスクや概念実証をメンバーに割り当てて、結果を評価するのもよいでしょう。 さらに、ソリューション アーキテクトは、メンバーが提案したソリューションについて説明を求めることで、メンバーが自らの試行プロセスを理解しやすくする必要もあります。
プロジェクトが進むにつれてスキル マトリックスを作成すれば、ソリューション アーキテクトはチームの強みを活かし、プロジェクトをより発展させることができます。
融和を保つ
ソリューション アーキテクトの多くは、相当な知識と経験を持ち、チームをより広い視点で見ることができる人です。 しかし、他のメンバー全員も同じようにスキルや知識、経験を持ち、プロジェクトを深く理解していると思わないでください。
勝手な思い込みや、一般論で考えることは危険です。 ソリューション アーキテクトには、情報をチーム メンバーに適切なタイミングで伝えるという重要な役割があります。 明確に説明し、また、伝える相手を間違えないようにしなくてはなりません。 メールでは十分に伝わらない可能性があるので、チーム メンバーに定期的に話しかけて、チーム全体をまとめてください。 コミュニケーションは双方向で行わなくてはなりません。つまり、メンバーから話を聞くことも重要です。
作業を分類する
ソリューション アーキテクトの典型的な作業は、作業を分類してチームのメンバーに割り当てることです。 ソリューション アーキテクトは、Customer Service や Customer Acquisition などのアプリケーションに含まれる機能を論理的に分類する必要があります。 また、ドキュメント管理やコンピューター テレフォニー統合 (CTI) など、水平ソリューションにも注目する必要があります。
標準を策定する
どのプロジェクトでも、チームが従うべき標準を策定することは重要です。 Microsoft Power Platform には、スキーマ接頭辞や、テーブルと列の名前など、後から変更することが難しい要素もあります。
ソリューション アーキテクトは、次の要素について標準を定義し、一貫性を保つ必要があります。
- コンポーネントの命名
- 列のデータ型
- UI - フォーム レイアウトの選び方や、複数のフォームの使用などについて
- 自動化 - Power Automate のクラウド フロー、従来型のワークフロー、ビジネス ルール、クライアント スクリプトなどのさまざまな自動化オプションの使用について
- セキュリティ - ロール、列セキュリティ、階層セキュリティなどの使用について
- 開発 - たとえば、バインドの定義のタイミングやエラーの処理など
詳しくは、「モデル駆動型アプリケーションのベスト プラクティス」、「アプリケーション デザインのベスト プラクティス」、「開発者のベスト プラクティス」などの Microsoft ドキュメントをご覧ください。
作業環境
構成や開発を行う環境を定義することにも、ソリューション アーキテクトには責任があります。 これは、チームのスキルや、メンバーが同じ場所で作業しているのか、それとも離れた場所で作業しているのかなど、さまざまな要件に応じて定義する必要があります。
開発環境のトポロジに加えて、何らかの種類のテスト環境も選択する必要があります。 既定では、Microsoft Power Platform にはバージョンを管理する追跡機能は含まれていません。
ソリューション アーキテクトはこれまで担当したプロジェクトを振り返り、チームの連携を強めるために自分に何ができるかを考える必要があります。