リスクとコストの低い開発
前述のポイントをまとめると
- 内部(Sales Cloud) 向けの機能で
- 独立したオブジェクト・情報だけを用い
- 外部システムとの連携がなく
- 参照のみの機能で
- 同等の標準機能を残す前提で
- 標準機能を拡張する機能
であれば（もしくは当てはまらないものが１つ程度であれば）業務への効果が期待できるものからどんどん開発者に作ってもらう、というのも手です。そのような融通の利く『作る人』チームがいると、小さなところからどんどん改善を進められます。また、小さなチームでもこのような内容の開発であればうまく回すことができ、なにより仕様やリスクを調整するリーダー・マネージメントの負担が大きく減ります。
逆に、上記に当てはまらない開発は計画的に、予算と工数を確保して十分検討と開発に時間を割いて行うべきです。言い方を変えれば、開発フェーズ中は上記に当てはまらない、優先順位の高い要件を集中的に対処し、上記に当てはまる要件で初期リリースに必須でないものは運用しながら拡充する、といった考え方もできるということになります。
では、具体的にどのような例があるか見てみましょう（実装方法は次回をお楽しみに！）
詳細ページに情報を表示する画面部品が欲しい
リスクやコストが低い割に最もビジネス上効果を発揮するのがこの要望です。画面部品であるため、標準の表示・編集機能は疎外せずに機能を追加するため開発と言えど標準機能の良さを阻害しませんし、更新のない参照のみの機能です。前述の条件の多くを満たします。
そのため、その画面部品を配置する対象のオブジェクトの情報（取引先の詳細ページであれば取引先やそれに関連する項目の値）を、数式では表現しきれない複雑な計算や表示方法（色や表示形式、グラフなどを含む）出力する画面部品があれば、分かりやすく且つ様々な角度で情報を見ることができます。特に対象のオブジェクトの明細に当たる情報を集計したり特定のもののみを表示したりすることは標準機能では十分できないためニーズがあります。もちろん、その表示方法の要件が複雑になるほどリスクやコストは高まりますが、仕様が明確でコロコロ変わるものでなければ、技術自体はグラフなども便利な無料のライブラリがあるため、『作る人』と相談すると意外とすぐに作ってくれたりするかもしれません。
この「参照のみ」「標準機能を阻害しない」といった条件があまりにも大きいため、実は他システムの情報であっても条件が整えば意外と容易に表示用画面部品を作れる可能性があります。その条件とは、以下のようなAPIを提供していることです。
- Web API、できればJSON形式で返すRESTful APIである
- インターネットから特定のIPアドレスでなくともアクセスできる
- 認証方式はOAuth、Open Connect、あるいはBasic認証のような固定の認証情報を用いたもの
なので、例えばGoogle API（Google Spreadsheetとか！）やAWS Gatewayなどを介したAWS上のサービス、そのほかモダンなAPIを公開しているクラウドサービスだと、認証情報さえ確立できれば上記の条件を満たすことができ、意外と容易に情報を取得して加工・表示ができる可能性があります。既にクラウドを取り入れている企業では、是非検討すべきです（ただし、『作る人』の意見をよく聞いてください）。
一部の情報に対して特殊な入力ができる画面部品が欲しい
これは、先の例の「添付ができる編集画面」のように丸ごと画面開発が必要となるものではなく、詳細画面に配置して保存後に追加で入力したり、編集を容易にしたりする画面部品を指します。これは更新機能にはなりますが、本来標準の編集画面でできることをするわけなので、他のオブジェクトを更新しにいかない限りはリスクやコストを抑えることができます。
例えば手元にあるもので言うと、自作のカラーピッカーがこれに当たります。弊社のタイムカードアプリ（色で取引先／商談を示す行動レコードをクリックとドラッグ＆ドロップで作成・編集できる自作カレンダーアプリ）では、各商談に色をカラーコードで指定する必要があります。それほど頻度が高いわけではないですが、さぼるとタイムカードを使わなくなってしまうので割と重要な作業です。ただ、カラーコードを暗記しているわけではないので、カラーピッカーが欲しくなります。そこで、商談の詳細ページに張り付けて、商談の色指定カスタム項目に選択した色を挿入してくれる簡単な画面部品を作ったわけです。
同様に、複雑な計算処理をさせて結果を確認してから特定項目に保存する、といった要件も「編集画面上で保存前に入力したい」と言わない限りはそれほどリスクの大きい話ではありません。この「編集画面上で保存前に」か「詳細画面上で保存後に」の違いは、『作る人』にとって全く次元の異なる開発なのです（後者の方がとても楽です）。
実はこれも条件が整うと、他システムの情報を取得して選んで入力、といった要件であってもリスクやコストを抑えられる可能性があります。要は前述の「他システムの情報を取得して表示する」画面部品に「選択した値を特定の項目に保存する」機能を加えればいいだけだからです。まず他システムと連携できる条件は前述のとおりです。もう１つ大切なのは「他システムから情報を取得する」と「値を保存する」を一度にしないということです。一度にする、つまり同じトランザクションで行う（保存時に入力した値に基づいて他システムから情報を取得して項目に設定する、など）と途端に難易度が上がることに注意です（保存⇒API呼出、の順では呼べないため、実装時や要件変更時にこの制限に抵触することに気づくと大変です）。
更に言えば、他システム側の更新による影響が小さいという前提ですが、Salesforce上でレコードを作成後にその情報（採番された番号など）を他システムに送って保存し、それをリアルタイムで確認する、といった機能も、条件と 『作る人』の技量によっては意外と実現性が高い手段があります。これは「リアルタイムで確認する」という条件があることで、逆に異常系処理はユーザに対するエラー表示で済む（前提）、など様々な意図がありますが、これに関してはまた別の機会にご説明したいと思います。一般的にはリスクやコストの高い実装ですので、『作る人』の意見を尊重していただければと思います。
繰り返しになりますが、大切なのは「部分的であること」「詳細画面に配置する画面部品であること」です。多少使い勝手は悪いかもしれませんが、『作る人』に対する大きなトレードオフ条件になることを覚えておきましょう。
チェックボックスや選択リストを更新する代わりとなるボタンが欲しい
これは前述の「特殊な入力ができる画面部品」の一例となります。つまり、本来は「チェックボックスや選択リストを、編集ボタンを押して（あるいはインライン編集のためにダブルクリックして）」「値を変えて」「保存する」、という３アクションが必要な操作を、ボタン押下１アクションで行いたいという要件です。地味ですが、こういった部分でユーザの利用意識を阻害しないことは、定着化ではとても重要なポイントです。
「このチェックボックスをONにする」や「この選択リストの値を～にする」と要件が明確で、この部品が使えなくなっても（適さないケースでも）標準のチェックボックスや選択リストの編集で代替できるため、開発や運用のリスク・コストがとても低い要望と言えます。
例えば、ステータスを「完了」にする代わりに押す「完了ボタン」、「見ました」チェックボックスをONにする代わりに押す「見ましたボタン」、レコードタイプを特定のものに変更するボタンなど、「なくてもいいけどあるととても便利」なボタンの需要は、特にSalesforceを正しく使って社内の利用を拡大したい、と活動するお客様の中には多くあります。汎用的に作ればとても便利な部品となるでしょう。
関連するページへ遷移するボタン／リンクが欲しい
これは多くの場合、例えば特定の項目の値を元に遷移先のURLが決まる場合は、数式項目によるリンクで実現できます（『作る人』にご相談ください）。
しかし、例えば子レコード（明細レコード）の中の特別な１つに遷移する、多くのファイルの中から「契約書」という名前のあるファイルを開く、といった場合は開発が必要です。しかし、そのURLを特定するロジックが明確で可能であるならば、画面遷移をするボタンやリンクを表示する画面部品を開発するのはそれほど難しい事ではありません。標準ではもちろん開ける画面ですから、もし何かがあっても、数ステップ踏んで対象の画面を開けばいいだけですし、間違って権限のない画面が開いても権限設定がきちんとなされていれば、権限がありませんというエラーメッセージが表示されるだけです。それで便利になるのであれば、検討するのも１つの考えだと思います。
保存時にそのオブジェクトの項目に値を挿入したい／差し替えたい
最後に、保存時に保存される値に細工をしたい場合のポイントです。同一オブジェクトの項目更新は「ワークフロールール＋項目自動更新」で設定のみで実現することができます。ただし、参照項目などは対応できないため、「プロセスビルダー」や「フロー」でチャート形式の設定を行うことで、これも開発なしで実現することが可能です。それでも実現できない、もしくはプログラムを書いた方がシンプルな処理は、オブジェクト毎に更新されると起動するトリガーと呼ばれるプログラムを開発する必要があります。
しかし、実はこれらの更新は（同じトランザクションですが）「新たな更新」としてとらえられ、その更新によりまたこれらの仕組みが起動します（起動しない場合もあります）。先に述べた通り、これが連鎖するとどんどん何度も仕組みが起動し、ひどい時には無限ループに陥ってエラーとなります。特にあるオブジェクトの更新時に、他の関連するオブジェクトを更新すると、そこにある仕組みが起動して・・・と範囲がどんどん広がっていくわけです。これはプログラムを書かない場合でも同じ注意が必要です。
ただ、もしも対象のオブジェクトに対して既にトリガーを作ろうとしている場合、ある条件の処理であれば最小のリスクや影響範囲で追加の項目更新を実装することができます。その条件とは、「同じオブジェクトの項目を更新する」「作成時にそのレコードのレコードIDが必要ない」というものです。『作る人』には「beforeトリガー」と言えば通じます。
実は、この「beforeトリガー」以外の更新は全て「新たな更新」を発生させるのですが、「beforeトリガー」はその名の通り、最初の更新の前に本来更新する値を「差し替える」処理が実装できます。新たな更新は発生しません。なので、本来画面から保存しようとしていた処理とほぼ等しい実行状態になります。もちろん、この処理の中で他のレコードを更新処理してしまっては他の場合と同じようにリスクや影響範囲が拡大してしまいます。あくまで、本来更新しようとしているレコードの項目を差し替える場合だけです。
例えば、「画面からは商談参照項目を入力してもらうが、別の理由でその商談に紐づく取引先も取引先項目に設定したい。でもユーザには二重の手間になるので商談だけ入れさせたい」という場合、商談の取引先を拾って設定する実装があればよいのですが、参照項目なので項目自動更新は不可、プロセスビルダーやフローの実装が必要です。しかし、既にそのオブジェクトのトリガーを開発する予定があるのであれば、そこに処理を混ぜてもらうのが一番リスクが少なく工数も少なく済むでしょう。
もちろん、既存のトリガーに手を加える場合、既存処理の影響を加味したテストが必要です（トリガーでなく標準機能の更新処理でも既存の更新処理に影響がないかはテストが必要です）が、あるプロジェクトの中でどのみち作成・改修するトリガーであれば検討を依頼するのも１つの考え方です。このように、リスクと工数が比較的高い更新処理の中にも、なるべくリスク・工数を軽減させることができる工夫や選択の余地があるのです。
いかがでしたでしょうか？いずれも、それほど重要でない「あったらいいな」という要件かもしれませんが、「あったらいいな」という要件だからこそ、リスクや工数のかからない方法で実現したいものです。一度「あったらいいな」リストを作り、このような観点で実現性を『作る人』と議論して、リスクや工数の少ないものをどんどん実現していく、というのも１つの進め方です。
次回は、今度は『作る人』向けに、開発のリスクやコストを抑える実装テクニックや考え方を具体的にサンプルを見ながらご説明できればと考えています。お楽しみに！