プロボノプロジェクトの実現可能な範囲の定義

学習の目的

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

組織をエンゲージするためのベストプラクティスを適用する。
ユーザーストーリーを使用して要件をドキュメント化する。
妥当な作業範囲を定義する。

成功する範囲を定義するには

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

プロボノの特別な力を効果的に適用するには、プロジェクトの範囲を適切に定義する必要があります。具体的にはどういう意味でしょうか? 簡単に言うと、プロジェクトの範囲定義とは、組織が達成したいことを理解し、使用可能なリソースとタイムラインを前提に、できること (できないこと) について合意するプロセスです。

2014 年に Salesforce.org がプロボノプログラムを開始して以来、数千名の Salesforce 従業員が非営利団体や教育機関とのプロボノプロジェクトを無事に完了しています。こうした組織のなんと 82% が、プロジェクトの結果、Salesforce の管理やミッションの達成がより効果的になったと行っています。Salesforce のプロボノボランティアがプロジェクトの範囲をどう定義するかがプログラム成功の主要な促進要因となります。ここではそのベストプラクティスを共有しましょう!

初心者の気持ちになる

プロボノプロジェクトを始めるにあたり、初心者の気持ちになることが重要です。プロジェクトに対して好奇心を持ち、素直に心を開きます。自分の経験が常に組織に当てはまると思い込まないでください。

たとえば、お客様が Salesforce でページレイアウトを変更したり、メールを送信したりする方法を知らないこともあるため、知っていることを前提にしてはいけません。過去に一般企業で楽々とできたことでも、非営利団体や教育機関ではさらに実地のガイダンスが必要になる場合があります。

Salesforce 従業員 Matthew Watson の画像。

Matthew Watson、APAC プラットフォーム & サービスソリューションエンジニアリング、Salesforce: 「非営利団体は、一般企業のお客様とは異なる言葉を使用し、異なる課題に直面していて、テクノロジープロジェクトの管理経験も多くありません。」

非営利団体や教育機関が Salesforce を活用できるようにするために必要なのは基本的なことです。次の点が重要です。

組織の活動のしくみを正確に理解する。
組織のプロセスに沿ったユースケースを調査する。
時間を取って機能を説明する。
組織がシステムを容易に操作できることを確認する。

データのインポートのようなプロセスはあなたにとっては普通かもしれませんが、お客様が容易に実行できることを確認する必要があります。

初心者の気持ちを持ってプロボノプロジェクトに取り組めば、組織にとって持続可能なソリューションを順調に作成することができます。

短くする

時間内で沢山の要望に対応することになります。今は少し空いている時間があっても、いつ新たな仕事のチャンス、多くの作業が必要なプロジェクト、家族の重大事が発生するかわかりません。それは、ボランティアとしてプロボノプログラムに取り組む Salesforce 従業員でも同じです。

そのため、Salesforce では、プロボノプログラムによるプロジェクトの範囲を、完了まで 20 時間以内と定めています。プロジェクトを 20 時間以内に保つことで、予期しない業務または個人の事情で完了する前にプロジェクトを離れる可能性を最小限にしています。

かといって、この時間数を超えて貢献したければ、できないわけではありません。Salesforce 従業員はみな寛大なので、2 ～ 3 個のプロボノプロジェクトを連続してつなげることで、熱意を注いでいる目標をサポートすることがよくあります。

範囲を作業の小さなかたまりにすると、いつでも次のプロジェクトまでの間に自分のコミットメントを再評価できるという大きな利点があります。これにより、一度に 1 つの個別のタスクに集中できるだけでなく、柔軟に活動できます。

時間的制約のあるプロジェクトやミッションクリティカルなプロジェクトは避ける

マントを身に付けた女性が手足の付いた時計から逃げている図。

あなたは社会に還元し、世界に大きな効果をもたらしたいと考えています。そのため、組織から実装のすべてを行ってほしいとか、ほんの数週間先の大規模な資金調達ガライベントをサポートできるように組織を設定してほしいと頼まれると、「はい」と答えたくなるかもしれません。そうした場合に「いいえ」と答えてもまったく問題ありません。もっとはっきり言うと、ミッションクリティカルなプロジェクトや時間的制約のあるプロジェクトは辞退してください。

ボランティアの能力では、長期のコミットメントを維持することや、厳しい期限のある急ぎのプロジェクトを遂行することは非常に困難です。業務や家庭の事情がいつ変わるかは誰にもわかりません。そして、最も避けるべき事態は、完了前にプロジェクトを離れることです。非営利団体や教育機関への支援に合意すると、最後までやり遂げることが期待されます。

あなたが途中で抜けたら、非営利団体や教育機関は専門知識やリソースが足りずにプロジェクトを続行できないでしょう。やり遂げられるとわかっているコミットメントをすることが非常に重要です。

具体的にする

前の単元で学んだように、最初の計画ミーティングでは、プロジェクト全体の目標を明確にします。プロジェクトの範囲定義フェーズでは、日々の作業に Salesforce や他のツールを使用する具体的な方法をユーザーに説明する必要があります。簡単にできる操作と、困難やストレスを感じる操作を調べます。必ず、プロジェクトの目標に関連がありそうなユースケースに焦点を合わせ、自動化が可能な手動の反復作業はないか探します。

目標とするのは、問題とそれが組織に与える影響、改善後のプロセスを明確に理解して、適切なソリューションを推奨できるようにすることです。エクスペリエンスについてユーザーに次のような質問をします。

[X] タスクのやり方を手順に沿って説明してください。
このプロセスはうまくいっていますか? 簡単なのはどのような点ですか? 困難やストレスを感じるのは?
あなたの仕事にとってこのタスクはどの程度重要ですか? これを迅速化/改善できたらどうでしょうか?
収集しているデータについて教えてください。追跡しているデータの種類と量は? データの状態はどうなっていますか?

こうした質問への答えを参考にして、課題がどこにあり、組織のミッションや活動に対する課題の相対的な重要度を把握できます。ここから、機能要件をドキュメント化し、どのようなソリューションが可能かブレインストーミングを開始することができます。

重要なのは、わかったことをドキュメント化し、組織と共有することです。ささいな誤解でも、プロジェクトで間違った道に進む原因になりかねません。

要件をドキュメント化する

ユーザーストーリーの作成は、組織の具体的な要件をドキュメント化して認識を合わせるための優れた方法です。各ユーザーストーリーには、ユーザーのニーズを技術用語ではない平易な言葉で記述します。

椅子に座り、コーヒーを飲みながら本を読む女性の図。

たとえば、青少年育成のために無料で学習指導サービスを提供する、小規模なコミュニティベースの非営利団体をボランティアとして支援するとします。この組織は、指導者への支払をカリフォルニア州からの多額の助成金に頼っています。

毎月、この非営利団体の事務局長は、助成金の条件として州に財務報告書を送っています。この報告書の作成に毎月 4 ～ 5 時間かかっており、できればその時間を、新しい財源を見つけるために使いたいと考えています。

この場合、次のようなユーザーストーリーを書くことができます。

「事務局長である私は、財務報告書が自動的に作成されるようにして、報告書の作成にかかる時間を短縮し、新しい財源を見つけるための時間を増やしたいと考えています。」

ユーザーストーリーが事務局長 (「ユーザー」) の視点で書かれていて、そのニーズ (「何」) とニーズの理由 (「なぜ」) が記述されていることに注目してください。この文章は平易な言葉で書かれており、技術者ではない人が簡単に理解してフィードバックを提供できます。

組織がユーザーストーリーをサインオフしたら、具体的な要件を定義できます。上記の例の場合は、レポートの自動化作業を行う前に、含める項目、絞り込み条件、実行日、レポート期間を識別する必要があります。

範囲に含まれるもの (含まれないもの) を決定する

各ユーザーストーリーの要件をドキュメント化したら、それらの要件の実現にかかる時間を見積る必要があります。これは、科学というより技であり、あなたが目的の機能にどの程度習熟しているか、また、他の製品ドキュメントを調査する必要があるかどうかで異なります。控えめな見積を出すように努力してください。

その後、組織と協力して、現在のプロジェクトに含める要件と、今後のプロジェクトに持ち越す要件を決定する必要があります。これで現実的なプロジェクトの範囲を定義できたので、次は Salesforce の特別な力を解き放ってソリューションの設計と構築を行います。