プロボノボランティアとしての持続可能なソリューションの設計と構築

学習の目的

この単元を完了すると、次のことができるようになります。

  • 適切なソリューション設計原則を適用する。
  • 組織が維持できるソリューションを構築する。

重要なのは持続可能性

地図、双眼鏡、テント、カヤックの図。

ここまで、Salesforce の特別な力を社会貢献に使用する方法についてはうまくいっているようです。多くのプロボノスーパーヒーローに共通する弱みを 1 つ挙げるとしたら、組織で維持できないソリューションを構築してしまうことです。 

あなたの責務は、組織の具体的なニーズと使用事例に合った、組織が長期的に維持できるソリューションを推奨することです。組織がバックグラウンドで何が行われているか理解していなかったり、不具合があっても調整できなかったりすれば、簡単なオートメーションさえ維持できなくなります。プロジェクトの完了後は、非営利団体のお客様がソリューションを維持できるようにする必要があります。

まず適切な設計

持続可能なソリューションを構築するには、まず推奨事項をドキュメント化し、作成を開始する前に組織と一緒にレビューします。あなたが何をなぜ推奨したかを組織が理解していることを確認し、あなたが去った後に組織がソリューションを維持できるようにするための計画について合意します。 

マントを身に付け、住宅を背景に設計図を見ている女性の図。

推奨事項をまとめるときには、次の点に留意してください。

  • あなたが去った後のソリューションの維持におけるお客様の役割を強調する。
  • 可能な場合は常に標準のオブジェクトと機能を推奨する。
  • カスタム開発と複雑なワークフロー自動化については必要性をもう一度よく考えてみる。
  • 構築しながら何を行っているかを組織に教える。

構築のベストプラクティスを適用する

組織があなたの推奨事項を承認したら、ソリューションの構築を開始できます。構築中は、次のベストプラクティスを念頭においてください。

変更は必ず Sandbox で行う

本番環境で直接ソリューションを構築したいと思うこともあるでしょう (特に、お客様の既存のデータでテストする必要があり、Full Sandbox を使用できない場合)。ただし、それではミスをすると業務が中断しかねません。また、元に戻せない変更を加えてしまうおそれがあります。 

Sandbox でソリューションを構築しておけば、非営利団体を去るときに、開始時より悪い状態になることはありません。開始する前に、必ず新しい Sandbox か、既存の Sandbox のリフレッシュを要求します。

Enterprise Edition の Salesforce には Partial Sandbox が含まれています。これは、お客様の既存のデータを使用する必要がある場合のテストに使用します。非営利団体のお客様が Sandbox テンプレートを作成し、コピーするデータを選択するとき、必要に応じて支援をします。

簡単にする

Salesforce 従業員 Jimmy Hua の画像。

Jimmy Hua、リードソフトウェアエンジニア、Salesforce: 「Salesforce には多くの素晴らしいテクノロジがあります。とはいえ、組織で Einstein のような製品を使用する準備ができていない場合、使用できないものに時間を投じてはいけません。」

構築時には常に、簡単なほどよいということを念頭に置いてください。あなたの目標は、組織が理解して維持できる持続可能なソリューションを作成することです。理想的には、宣言型プログラミング (コードではなくクリック操作) を使用してソリューションを構築し、将来的に要件が変わったら Salesforce システム管理者が簡単に更新できるようにします。

変更に備える

構築中に要件を明確にする必要が生じ、結果的に設計した内容に変更が必要になることがあります。定期的にお客様に連絡を取ることで、こうした変更を迅速かつ効率的に特定できるようになります。あなたのやるべきことは、制限内で柔軟に対処すること、そして要件がプロジェクトの範囲外になったら特定して、優先度またはタイムラインを調整できるようにすることです。

組織と一緒に構築する

マントを身に付けた女性と 2 人の建設作業員が住宅の前に立っている図。

適宜、あなたが組織で何を行っているかをお客様に見せ、作業の一部を自分たちでやってもらいます。こうすることで、プロジェクトの完了後に、あなたが行ったことをお客様が維持できるようになります。人手が増えて、思っているより多くのことを完了できるかもしれません! 必ず、お客様の作業結果をチェックし、ミスがあれば指導します。 

作業しながらドキュメント化する

構築した内容を技術面と機能面の両方の観点から記述して、導入したソリューションを誰もが理解して構築を継続できるようにします。作業しながらドキュメント化すると、結果的に時間を節約でき、プロジェクトの終了時に確実に引き渡すことができます。テストが完了したら、忘れずにドキュメントを更新します。

テスト、テスト、テスト! 

構築したものはすべて、リリース前にあなたと組織の両方が Sandbox でテストする必要があります。必ずユーザストーリーごとに定義した要件をテストします。失敗したら、調整して再テストします。 

たとえば、Salesforce の機能を使用して、受け取った支援の支援レコードが作成されたら常に、支援者へのお礼のメールを自動送信するように設定したとします。オートメーションが適切に機能していることを確認するには、テスト支援の支援レコードを作成し、メールが正しく配信されて書式が適切であることを確認する必要があります。テストには、自分のメールアドレスを使用すると簡単です!

実装内容の複雑さに応じて、あなたとお客様の両方が参照できるテストスクリプトを使用することを検討します。サンプルスクリプトについては、「Resource Guide for Pro Bono Volunteers」 (プロボノボランティアのためのリソースガイド) を参照してください。

ほとんどの場合、構築したソリューションはお客様と一緒にウォークスルーしてから、お客様に引き継いでテストできるようにします。お客様に作業結果のテストを依頼する前に、デモ、トレーニング、質問への回答ができるように準備する必要があります。

リソース