各工程のポイント
前のページで示したプロセスの各工程では以下のポイントが重要となります。
企画
この工程では、今回のプロジェクトを何故行うのか、何故Salesforceを使うのかを明確にして関係者と共有することが重要です。そうしなければ、「○○さんの気に入ったシステムを作る」ことが目的になりがちで、そうなると『使う人』『作る人』双方にとって無駄な時間とお金を費やすことになってしまいます。
「何故Salesforceを使うのか」が明確になってくると、アーキテクトと呼ばれる人たちが「Salesforceで実現する部分」と「Salesforceで実現しない部分」を色分けし、それぞれをどう実現してどうつなげるかを考えることができます。これにより、どのような製品を幾らで購入し、どのような技術と方針で作っていくかを関係者に伝え、予算と人的リソースを準備することができます。
上記の「目指す姿」と「方針」と共に、『作る人』が対象業務や現行システムを理解するための情報を集め、要件定義に備えます。
要件定義
この工程ではプロトタイプを用いてSalesforceの実現イメージや機能・制限について、実際に動くアプリケーションを見ながら検討を重ねます。Salesforceの機能や制限を意識しながら進めますが、それでも重要なのは「『使う人』の意図を汲み取る」ことです。つまり、『使う人』の都合を反映させる工程だということです。
プロトタイプを用いてSalesforceで実現するときの実装方針やそのリスクを検討しますが、これは『作る人』の都合を押し付けているのではなく、『使う人』が長期的に得られるメリットや負うことになるリスクを理解したうえで判断してもらうためなのです。
例えば、「標準機能を使うと多少画面と操作に慣れる必要があるが、今後Salesforceが出す新機能にも自動的に対応でき、改修も管理者が設定ですぐに対応できる」「カスタム開発すると思い通りの画面・操作が実現するが、ちょっとした修正を行うにも開発者に頼む必要があるので改修に時間とコストがかかる」の2択をきちんと説明し、仮に『使う人』が「改修に時間とコストをかけてでも思い通りの画面・操作を実現したいからカスタム開発にする」と決めたら、それは『使う人』の意図であり都合なのです。大切なのは「改修に時間とコストがかかる」というリスクを理解して選択したことを『使う人』『作る人』の両者で合意をとることです。もちろん、この例で標準機能を使うと決めた場合でも、「多少画面と操作が思っているものと違う」ことを承知で決めたと合意を取ることに意義があるわけです。
どのような利益を享受するためにどのようなリスクを選択したのか、この判断を１つ１つ記録していくことが、要件定義の重要な目的だといえるでしょう。この「利益」と「リスク」をなるべく具体的に表現し、実際の業務に近い形で体験して精査することがプロトタイプを作る目的なのです。
設計
この工程では、『作る人』の意図や都合を少しだけ加味し、『使う人』の意図や都合に少し修正を入れてよいかを伺い同意を得ることが目的となります。
具体的には、
- 「読みやすいレイアウトにする」という要件に対し、どのような順番で項目を並べることが「『使う人』にとっての『読みやすい』」に当たるのかを決める
- 「～を比較できるダッシュボードを作る」という要件に対し、そのためにSalesforceでとらなければいけないテーブル（オブジェクト）構造が多少他の入出力画面に影響を与えることを了承してもらう
といった、項目レベルの粒度まで落とした仕様定義になります。次工程の『作る人』の意図・都合をいきなり取り込むのではなく、設計フェーズにて『使う人』の意図・都合と軽くすり合わせをしておくのが開発をスムーズに行うコツ（『作る人』のテクニック）です。
開発
この工程では『作る人』の意図や都合を加味していくことになります。
要件定義で実際に動いているプロトタイプを見ると、「これをリリースしてしまえばいいじゃないか、何故この後に余計なお金と工数をかけて作り直すようなことをするのか」と、この工程をスキップもしくは大幅に短縮しようとする『使う人』が、たまに、います。逆に、そう言われることを恐れ、過剰に時間と工数をかけてプロトタイプを作る『作る人』も、たまに、います。
『作る人』の立場で誤解を恐れずに述べるならば、「作り直す」ことは機能的な実装を長く保つために必要不可欠であり、また方針が決まり技術課題が解決されていればSalesforceにおいて「作り直す」ことは大した労力ではありません。
プロトタイプを作るときは分かりやすさやメンテナンスのしやすさを一切忘れ（当然コメントやドキュメントは作らない、もしくは時間を掛けません）、「利益」と「リスク」を説明するのに必要最低限の実装をします。その代わりに、その場で目の前で作るぐらいの素早さで作ります。その方がより多くのことを試行錯誤できるからです。
作り直すときには仕様も課題解決策も決まっているため、今度は分かりやすさやメンテナンスのしやすさ、業務のバリエーションや例外処理、運用機能の追加等、つまり『作る人』の腕の見せ所に注力するわけです。もちろん、プロトタイプを部分的にコピペしたりしますので、本当にゼロから作り直すわけではありません。
開発時も、できれば要所で『使う人』に実物を見てもらう、特に作り直す際に考慮したり新たに発覚した制限に対応したりして若干の仕様が変わった部分は要件定義や設計時と同じように実物を見せて『使う人』の意見や合意を得るべきです。
次工程の単体テストに含まれる「テストクラスの作成」を含めれば、最低でもプロトタイプを作るのにかけた全時間と同じ程度の時間を取っておく必要があるかと思います。
単体テスト
この工程は開発の一部、つまり『作る人』の都合（責任範囲）と考えるべきです。なので、今回は敢えて「テスト」という工程に含めていません。
Salesforceでは本番環境にリリースするプログラムには「テストクラス」（プログラムをテストするプログラム）を作る必要があり、これをもって単体テストとする人たちが多いです。しかし、私は『作る人』の範疇でプログラムに問題がないことを示すためには画面からの打鍵などとも合わせて実施すべきと考えます。
逆に言えば、無理に「テストクラス」で全ての単体テストケースを実装してしまうのではなく、プログラムでやった方が都合がよい部分（機械的にテストケースが作れる仕様や、計算など試験結果を機械的に判定できる実装部分）は「テストクラス」で、画面からの入力に基づく総合的な結果の判断（でも粒度的に機能テストではなく単体テストの範疇）が必要な場合は画面からの打鍵、と使い分けて考え、テストクラスの開発に過剰な工数をかけない考え方が一番労力と時間を効果的に使えると考えます。
もちろん、再起テストなど、何度も繰り返しテストすることを想定しているのであれば、多少無理をしてでもすべてをテストクラスで実装し、単体テストを完全自動化することも考えます。ただしこの場合、仕様や実装に手を加えたらプログラム改修と同じ程度の時間をかけてテストクラスも改修する必要があることを覚悟するべきです。
つまり、ここも『作る人』の腕と経験の見せ所なわけです。
テスト
この工程は、これまでの工程で加味された『使う人』『作る人』それぞれの意図・都合が正しく実装されているかを確認するためのものです。よって、意図・都合を示した人が責任をもって確認するべきです。結合テストは『作る人』の間での責任分界点を埋めるためのもの、システムテストは『作る人』の目線から見た『使う人』の意図・都合を確認するためのもの、ユーザ受入テストは『使う人』自身が自身の意図・都合を確認するためのもの、となります（開発プロセスにより呼び方は変わります）。
リリース
Salesforceのリリースには1癖も２癖もあります。十分に時間をかけてリリース手順を実際の環境で試し、精査することが重要です。タイミングとしては、ユーザ受入テストの環境をSandbox（本番環境のコピーとして簡単に作れるSalesforceの開発・テスト環境）で作る際が最初のリリース手順の検証機会になります。更に何度もSandboxを作ってはリハーサルをしてリリース手順を試し問題があれば改善する、を繰り返しすのですが、それでも本番環境ではうまくいかないことがあるのがSalesforce。経験と対応力の見せ所です。
リリースしたその日から、『使う人』からのフィードバックとそれを受けての改修が始まります。『使う人』側では、要件定義から参画している「『使う人』代表の人・組織」を中心に、今回のリリースの良さを広く『使う人』たち全体に自慢して（伝えて）行きます。今回のリリースを最も自慢できる人は要件定義で『使う人』の意図と都合を唱えた人だからです。
一方、『作る人』側では『使う人』のフィードバックに素早く応えることに全精力を注ぎます。「意見を言うと素早く対応してくれるんだ」と『使う人』に思ってもらえれば、次のリリース時に「いずれ素早く対応してくれるからまずはリリースして使ってみたい」と思ってもらえ、様々な調整をスムーズに進められます。そして積極的に機能を使ってもらえます。Salesforceを使い始めた最初の数か月でよいので、素早い対応、最低限でも「いつ対応できる」「このような優先順位で対応する」といった回答を示していくことが重要です。
いかがでしたでしょうか？一般的な開発プロセスとは幾分異なっているかもしれませんが、『使う人』と『作る人』が正しく、協力してシステムを構築するためには、Salesforceの特長をうまく活かし、両者が同じイメージを持って積極的に「利益」と「リスク」を語り、実現し、確かめていく必要があります。その一例として参考になればと思います。
次回は、「Salesforceの生産性 ー プロトタイピングによる効果的な『要件定義』」のまとめとして、ここまでに示したプロトタイピングを用いた開発プロセスがなぜ要件定義の課題を解決するのか、しいては、これがなぜ「ローコード開発の秘訣」の１つとなりえるのかを確認していきます。お楽しみに！