成功するアーキテクトが従う3つのソリューション設計プラクティス
オリジナル記事
Successful Architects Follow These 3 Solution Design Practices
パンデミック以前は考えていなかったとしても、顧客は今ではほぼ確実にデジタルへの移行を検討しています。つまり、顧客はデジタルへ移行する準備ができています。実装ジャーニーは始まったばかりです。
これが適切な方向への一歩であることは間違いありませんが、新しいSalesforceライセンスの購入は始まりにすぎません。このジャーニーはエキサイティングですが、実際には、実装は容易に（そして頻繁に）失敗します。
単に運、偶然、または購入するだけでは、組織は成功しません。多くの顧客はクラウドに移行すればすべての問題が解決すると考えていますが、テクノロジーはプロセスの一部にすぎません。
デジタル変革で成功するための鍵は適切なソリューションアーキテクチャです。そしてアーキテクチャはテクニックです。優れたアーキテクトは、Salesforceへの投資を十分に活用するには、特定のプラクティスに従う必要があることを理解しています。
漸進的な改善から真の変革まで、次のSalesforce実装を引き受ける際に役立つ重要なベストプラクティスをいくつか見ていきましょう。
1.変革を受け入れる
変革は心地良くないものです。気の弱い人には向いていません。「（過去25年間実行してきたものではなく）この新しいアプローチを推奨します」と話すと、エグゼクティブの笑顔が消えます。
「しかし、これまでずっとこの方法でやってきた。それに、財務責任者は決してこの新しいプロセスにゴーサインを出さないだろう」
変更を提案すると多くの抵抗に遭うため、ビジネス要件をそのまま受け入れたくなるかもしれません。しかし、関係者の現在のテクノロジーとプロセスがうまくいっていたのなら、なぜ多額のお金を新製品に費やしたのでしょうか。すべての雑音、組織階層、そしてその不可解な権力闘争の真っただ中で、製品の本来の機能に不利に作用する設計、つまり技術的負債を取り除くのではなく増やすような設計を行うことは非常に簡単です。既成の機能および業界のベストプラクティスから大きく逸脱し、プロジェクトのコストとリスクを増やしているアーキテクチャを開発していることに気付いたなら、今こそ変革を行うときです。
では、どのようにしてデジタル変革を実現しますか？
関係者の視点に立ってください。以前に聞いたことがあると思いますが、私が本当に言いたいことを明確にさせてください。クライアントの関心の観点からのみ話してください。組織の専門用語を学び、1日を体験しました。それを使用して、変革が収益に与える影響を示します。プロセスの変更が、どのように、収益に影響するか、競争上の強みをもたらすか、または将来の管理者の悩みを解消するか？会話は常に顧客中心でなければなりません。したがって、必ず設計に関する決定事項をKPIと関連付け、会話の焦点を常に顧客の問題点の解消に合わせてください。
価値を指標と結び付ける方法の例については、このアーキテクト価値マップを参照してください。
もう1つの説得手法は、説得力のあるイメージを示すことです。顧客が求めているものを経験させ、長所と短所を明らかにします。これは、アーキテクチャフェーズの概念検証（PoC）の際に行うのが適切です。これにより、クライアントに、何が得られるかだけでなく、特定の設計アプローチをとることのすべての意味を示すことができます。これらの意味には、アプローチを実装するために必要なコストと時間、必要になる追加トレーニング、メンテナンス、パフォーマンスへの影響、プロジェクトの開始後に必要になる可能性がある新規雇用（現在のチームにコーディング方法を知っている人がいないため）、他にも数多くの要素が含まれます。大幅にカスタマイズされたソリューションの短所に対するプロセス変更の長期的な利点をデモやPoCによって早期に説明すると、説得力が高まります。
古い要件を新しいシステムへ”リフトアンドシフト”し、それを行うためのどのような手段でも使用したくなります。しかし、できるからといって、すべきということではありません。厳しい会話を避けないでください。クライアントがそのような会話がメンテナンスや拡張性のような”小さな”領域での大きな改善にどのようにつながるかを理解したときに感謝されます。確実なソリューションアーキテクチャにとって、メンテナンスと拡張性は、付け足しではなく要件です。ソリューションアーキテクチャが調整または適応可能でない場合、その品質はすぐに低下します。
機能マップを使用すると、組織の目標状態を視覚化できます。機能マッピングは、常に確実に前進できるよう、プロジェクトを順調に進め、ギャップを分析し、技術的負債を回避するのに役立ちます。
2.大部分のユースケースに対して設計する
誰もが経験していることですが、手遅れになる段階で、クライアントの”主要”プロセスが製品によってネイティブでサポートされていなかったことを発見しました。要件（現状）をサポートするには、ライセンスの”Plus”バージョンを購入する必要があります。ソリューションが完全にカスタムになり、少なくとも1か月はタイムラインを延ばす必要があることは言うまでもありません。
結果として大量のエスカレーションが発生しました。ダメージコントロールに数日費やしました。その時点で、さらなる質問を開始しました。「どの程度の頻度でこのプロセスを通過していますか？実際に使用しているのは何人ですか？実際に使用している案件はいくつありますか？」結局、この非常に重要（だとされていた）プロセスが実際にはそれほど頻繁に必要とされておらず、あまり多くの収益を生み出していないことがわかりました。
同様のシナリオにまだ遭遇していないとしても時間の問題です。力強い（ただし丁寧な）一連の質問を使用して、ほとんど使用されないものを実装するために数千ドルを費やすことは理にかなっていないことを顧客が理解できるようにします。すべての要件をテクノロジーで解決する必要があるわけではありません。まれに発生する変則的なユースケースを処理するための明確なプロセスを定義し、その各部分を小規模のミドルオフィスチームの助けを借りて手動で管理します。
重要な情報を手遅れになる段階で発見するこのストーリーから、アーキテクチャフェーズの重要性が浮き彫りになります。多くのクライアントは、計画および設計に数か月を費やす価値を見い出しません。多くの場合、これらの領域を省こうとします。早期の段階での手間を惜しまないでください。透明性を確保し期待値を前もって管理できるようにするために、アーキテクチャフェーズで、こうした種類の発見を行うことができます。また、行う必要があります。
3.物事を全体的に見る
詳細は重要ですが、全体像から外れないようにしてください。
Salesforce CPQの例を見てみましょう。CPQはクライアントのツールボックスにある多くのソリューションの1つで、ビジネスの運営を支援します。また、CPQを使用するエンタープライズ企業が外部システムに保存されている商品、価格、またはインベントリ管理情報とリアルタイムで接続していることがよくあります。アーキテクトとして、これらの連携が単に円滑なだけでなく、技術的に実行可能であることを確認することが重要です。
必ず、すべての連携タッチポイントについて事前に考え、それらを設計する際に考慮してください。
ソリューションの基盤を設定するときは広く浅く構築し、実際の例に取り組むときはユニットテストを忘れないようにしてください。連携が鍵である場合は、最後まで待つことなく、見積から収益管理までのプロセス内のすべてのプレーヤーが適切に動作していることを確認します。早期および頻繁にテストして、すべての連携が実装されている状態で見積が作成から請求へとシームレスに移行できることを確認します。CPQを使用する担当者による販売をフルフィルメントできない、または注文に変えることができない場合、クライアントは満足しません。
まとめ
優れたソリューション設計とは、すべての要件をそのまま実装することではありません。変革の推進担当者になり、テクノロジーとプロセスのバランスをとり、戦略的なビジョンを持てば、成功に向けた基盤を築くことができ、最終的に顧客はSalesforce実装をフルに活用できます。経験と知識を頼りに、信頼できるデジタルアドバイザーになってください。そして、正しい方向へと導く、根拠にもとづくビジネス上の意思決定をクライアントが下せるよう支援してください。
著者紹介
Garima Totlani
Revenue Cloudのシニアコンサルタントを務めていたGarimaは、Revenue CloudとB2Bアーキテクチャの分野でのEMEAパートナーエコシステムの実現を担当しています。Linkedinでつながることができます。
