開発者目線でみる「リスクとコストの低い開発」

リスク

今回は少しテーマから外れ、Salesforceの生産性 ー プロトタイピングによる効果的な『要件定義』にて取り上げた「5.要件定義 ー 実装方針案作成」等で役立つ「リスクとコストの低い開発」の判断基準についてご説明します。

何か課題を解決するためにSalesforceにて機能を作ろうとし、標準機能では完全に要件を実現できないと判断した場合にはカスタム開発を検討します。しかし、その手段には様々なものがあり、その利用者や重要度、とれるリスクに応じて検討する必要があります。その際、『使う人』側から分かりにくいのが「リスク」と「コスト」の判断です。『使う人』にとってのリスクとは、例えば以下のものが考えられます。

  • 開発工数がかかり過ぎて予算と納期を実現できない
  • 障害が起きたときに業務やお客様に大きな影響を与える
  • 複雑すぎてリリース後に保守・運用できない

どのようなカスタム開発であれば、上記のどの項目にどれくらいの影響を与えるかを考えるために、『作る人』の観点も挙げてみます。

  • 仕様が複雑で度々要件変更が発生しうる
  • 技術的に課題がありその回避に複雑な実装を必要とする
  • 他の実装箇所に影響を受ける/与える可能性がある

それぞれの関係はこのような形になるでしょうか。

『作る人』観点と『使う人』観点のリスクマップ

それでは、実際にどのような機能や開発が『作る人』にとってどのようなリスクとなるのでしょうか?そこまで掘り下げてみることで、『使う人』には分かりづらい判断基準のヒントとなれば幸いです。

機能や開発方式の判断軸

『作る人』目線で言うと、例えば以下のような判断軸が考えられます。

  1. 内部(Sales Cloud) か 外部(Experience Cloud) か?
  2. 取引先など他の業務・部署が利用するオブジェクトを利用するか?
  3. 外部のシステムと連携するか?
  4. 参照機能か更新機能か?
  5. 同等の標準機能を実現手段として残しているか?
  6. 標準機能を拡張する機能か?隠ぺいする機能か?

以下で1つ1つ、どちらの選択がどの程度のリスクをはらむのかをご説明していきます。

内部(Sales Cloud) か 外部(Experience Cloud) か?

内部
 (Sales Cloud)
リスク外部
(Experience Cloud)
 仕様
 
 技術
 
 影響
 

内部(社員)向けの機能か、外部(代理店、お客様)向けの機能かの違いは分かりやすいところです。外部向けの方が機能・デザイン・品質にこだわる必要があるため仕様にもこだわりがあり、要件定義やUIデザインにも時間がかかる傾向があります。当然、社内の関係部署も多くなり、社外という制御不能な広い影響範囲に向けての機能となります。

ここで覚えておきたいのは、Experience Cloud(ポータルサイトを実装する仕組み)という特別なプラットフォームでの開発となるため技術的にも難しくなるということです。Sales Cloudで使える標準コンポーネントや機能が使えなかったり、画面遷移1つにしてもサイト名がURLに含まれてくるので単純ではなくなってきます。

しかし、外部向けの機能というのはビジネスにとって重要なポイントとなってくるため、やるならば気合い(予算と時間)と覚悟をもって挑むべきであるということです。また、特に要件定義以降、ましてやテスト中などに思いついたことを「ちょちょっとお願い」と頼むのは危険です。『作る人』とよく相談し、彼らの意見を尊重して挑むべき箇所です。


取引先など他の業務・部署が利用するデータ(オブジェクト)を利用するか

利用しない (専用) リスク 利用する(共用)
 仕様
 
 技術
 
 影響
 

これはSalesforceの業務的によい面であり、技術的に難しい面であることから、よく見られるジレンマです。取引先や商談、活動は全社で共有してこそ最大の価値を発揮する情報ですが、Salesforceが1プラットフォームで全ての機能を実現する性質上、共有はしやすいものの変更や障害も容易に伝播してしまうという課題があります。この課題を意識しないで「必要だから追加しよう・削除しよう・必須にしよう」(経験者には悪寒を催す文章ですね・・・)と策無しに実施してしまうとリリースの次の瞬間から電話が鳴り響きます・・・

まず、このことを一番注意すべきケースは「Salesforceを1部門で使っていたものを、複数部門・全社で利用するよう拡張する」場合です。1部門で使っている頃は自分達だけの世界ですので、好きなように設計しますし、アクセス権限も気軽に「全員に公開」としてしまいがちです。このような場合に、既に使っている情報(テーブル、Salesforceではオブジェクトと呼びます)に他の項目や機能を追加すると、どちらの側にも予想外の振る舞いが起きる可能性があります。これを避けるためにまずは現状を時間をかけて調査するのですが、リリース後も複数の部門が並行で開発・運用する場合はお互いへの影響を考えつつ保守運用する必要があります。

そして、そのような情報だからこそそれぞれの部門が独自の仕様を持ちたいと思うのが常です。当然、その個所の仕様は複雑になってきます。これを回避するための様々な技術を利用する中で、技術的な課題にも触れてくるわけです。例えば、単純に項目数が足りなくなる(エディションによって1つのオブジェクトに追加できる項目数が限られている)、といった状況が予想されます。その場合、初めから共通部分を残してを部門ごとにオブジェクトを分離し関連付ける構造にする、等といった工夫ができます。他にも、リリース前に他への影響を事前チェックする方法を確立するなど、技術に頼る部分は大きいです。

とはいえ、情報を共有する、そのために全社で1つのオブジェクトにデータを蓄積し更新する、というのはSalesforceの最大の特長であり醍醐味です。部門をまたいで利用する情報や機能ははじめから目星をつけ、そこに十分な予算・時間・技術者を充てるよう心掛けるべきです。


外部のシステムと連携するか

しない
(Salesforce完結)
リスク する 
(他システム連携)
 仕様
 
 技術
 
 影響
 

SalesforceはAPIが充実しているため、技術者とインフラの条件が整っていれば比較的システム連携しやすいシステムです。ただし、いかなる場合も他システムと連携するということは外国と交流・貿易するのに等しく、相手の習慣や文化を正しく理解するところから始める必要があります(でないと戦争に発展するリスクがあります・・・)。

次の軸で説明する「参照のみ(どちらも更新されない)」の連携、例えば他システムの情報をSalesforce上で見えるようにする、等は影響も少ないですが、更新が発生すると連鎖的に障害が全社に波及し、プログラムの改修だけでなくデータの不整合を解消するために多大な工数と時間を要し、その間ビジネスを止めなければならない、という事態も起こりえます。誰にでも想像が容易いリスクかと思います。

ここで注意したいのが、Salesforceの技術者でもシステム連携に関する機能の知識や経験がある人は少ないということです。Salesforceの情報を外部から取得・更新する連携は、Web APIの知識と適切なツール・インフラがあればそれほど難しくはありません。ただ、Salesforceから他のシステムの機能・情報にアクセスする、Salesforceから情報を送る機能は状況に応じて様々なものが用意されており、それを正しく選んで使いこなすのは難しく、このような設計ができる「アーキテクト」と呼ばれる技術者は少ないのが現状です。

最も注意すべきで見落としがちなのが「連携の方向」と「認証」です。

Salesforceはインターネット上にあるサービスです。会社のサーバは会社の閉ざされたネットワークにあるのが普通で、会社のサーバからSalesforceにアクセスするのは「内⇒外」になるため多くの場合問題ありません。皆さんがウェブサイトを閲覧するのと同じです(しかし厳重なデータセンターでは外に出るにも特別なルートや処置が必要な場合があります)。ところが、Salesforceから会社のサーバにアクセスする「外⇒内」となると話は別です。特別な「穴」をあけるか、外と内の間にツールを置いて「外⇒中⇒内」のように中継しなければならず、そのような前例や設備がない企業では特に実現が難しくなります。連携が必要な場合、まずはシステムと方向を洗い出し、インフラ技術者とよく検討することが必要です。

また、このように「誰がいるとも分からない世界」からのアクセスですので、今までどのシステムからも自由にアクセスされていたサーバだったとしても突然「認証」が必要になるケースが出てきます。もちろん全く認証なしでアクセスさせていることはないと思いますが、社内用の簡易的な認証(Basic認証)では通用しなくなり、新しい認証方式を導入する必要があるケースが多いです。そしてSalesforceから利用できる認証手段も、世界標準のものばかりとはいえ、限られているのが現状です。これも、連携対象のシステムの技術者と早い段階からよく検討すべき内容です。

逆に、条件と業務上の仕様をうまくクリアすれば、意外と簡単に他システムと連携できるのがSalesforceの良いところです。これはまた別の機会にお話しできればと思います。


参照機能か更新機能か?

参照機能 リスク 更新機能
 仕様
 
 技術
 
 影響
 

これも、言葉だけ捉えると『使う人』にも当たり前なことに聞こえますが、思った以上に『作る人』をうろたえさせるのが「更新があるかないか」です。特に経験者ほど、更新機能には敏感です。

まずは仕様です。『使う人』にとっては「見え方」の方にこだわりがあるので参照機能の方が要件が複雑になると思いがちです。しかし、『作る人』が最も苦労するのはデータの仕様と、それを守ることです。『使う人』にとっては、「説明文、テキストだよ」であっても、それが検索できるべきなのかどうか、長さの最大は何文字か、システムは気にします。どのようにチェックすべきか、そもそも間違えないで入力させるためにはどうするか、間違えたらどう知らせるべきか、すべてを考える必要があります。標準機能ならばSalesforceがやってくれますが、開発の場合は選択肢が増えるため検討の余地が出てきます。そのため、どちらかというと『作る人』から確認したい、決めたいことが出てくるわけです。

たとえ「標準と同じでいいよ」でも、今度は保存には他への影響が発生し得ます。更新時に起動する処理(ワークフロールール、プロセス、フロー、トリガーなど)があり、それがまた更新すると・・・と限りなく影響範囲が広がってしまう、これが更新処理です。これにより他の業務への影響を気にしなければいけないだけでなく、他の業務の処理によって予期せぬ業務エラーや入力規則で処理が止まったり、極端に性能が悪くなったり、それによってSalesforceの制限に抵触してエラーとなったりする可能性があります。他の業務が使っている情報だったり、他システムとの連携があったりする場合は、同じ業務でも更新の話となると急に腰が重くなる、それが『作る人』側の事情なのです。

更に気にしたいのが技術的な課題です。更新処理には「トランザクション」というものが関わります。これは一度に行いたい更新処理を保証する仕組みです。例えば取引先と取引先責任者を同時に作りたい、つまり片方が失敗したら両方やめたい、という場合に考えるべきものです。特に採番したい(通し番号を管理するために数を数えること)、という要件は、実はこの点で非常に難しい要件です。このあたりの技術が、詳しくない人にとっては苦痛ですし、詳しい人にとってはSalesforceが多くの機能を提供しないため苦労するところなのです。他にも更新処理にはクリアすべき技術課題が多く、『作る人』とよく相談すべき機能です。


同等の標準機能を実現手段として残しているか?

残している リスク 残していない
 仕様
 
 技術
 
 影響
 

このあたりから、致命的というよりもどれだけリスクと不安を軽減できるか、というレベルの話になってきます。標準機能では実現できない要件を開発して実現する場合、元の標準機能が残っているか?という問いです。

例えば「編集画面でファイルを添付したい」という要件があったとします。Salesforceにはファイルを添付する標準機能がありますが、これは、情報を一旦保存した後、参照画面にあるボタンから改めてファイル添付画面を立ち上げ添付する(もしくは参照画面上にドラッグ&ドロップする)機能であるため、保存前に一緒に入力して1回で保存したい、とよく聞かれる要件です。この際、(前述にある通り更新処理なのと、後述にある通り標準の編集画面を隠ぺいするものなので、この時点でリスクが大きいですが)編集画面そのものを開発したとして、元の参照画面から添付する標準機能を残すかどうかということです。この例では、残しておいて損はないと思うので残せばよいのですが、残せないような改修要件もあるかと思います。

同等の標準機能を残さない(残せない)ことの何がリスクかというと、「何かあったときに業務が回らないという最悪の事態になる」可能性があるということです。そして、それを恐れてより良い改修を続けていくモチベーションを下げてしまうことになりかねないということです。

先の例だと、後に業務プロセスが変わり「後から添付したいケースが増えた」「稀に複数のファイルを添付したい場合がある」など要件が変わった際、作った編集画面上の添付機能ではすぐに対応ができない、もしくは不便になる、ということが起こりえます。その際、標準機能は元々多くのケースを加味して考えられている(だからあるケースでは不便見えることもある)ため、対応できることが多いのです。添付の場合でも、実は標準機能である参照画面からの添付の方が様々なケースで利用でき、ドラッグ&ドロップによる大量添付にも対応できていたりします。なので、残してさえ置けば「不便かもしれませんがしばらくは標準機能を使ってください」と言えるのです。そう言えると思えば、思い切ってよい機能を開発しようと取り組める、というわけです。

なので、「標準機能を残す」というより、標準機能はより汎用的なケースに対応できていると信じ、「特殊なケースをより便利にするために機能を追加する/別ルートを用意する」という考えで開発した方が圧倒的にリスクは少ない、ということになります。「使う人」にとってもそのように説明した方が「何故機能が2つあるの?」と疑問に思うこともなく、慣れてくると「こういうケースで実は苦労しているから、次の機会に別ルートを作って!」と言いやすいのです。


標準機能を拡張する機能か?隠ぺいする機能か?

拡張 リスク 隠ぺい
 
仕様
 技術
 
 影響
 

この軸は分かりにくい部分がありますが、Salesforceを利用する上で特徴的な観点です。例えば前述の「編集画面を開発する」というケースは、「ある項目の入力部分だけを開発する」という部分的な開発ができません。あるオブジェクト(データベーステーブル)を編集する際の画面そのものを開発して標準の編集画面と「挿げ替える」必要があります。ある種、標準の編集画面機能を「隠ぺいする」開発です。なぜなら、開発した編集画面で特別なチェックや入力処理を行っている場合、標準の編集画面を「使って欲しくない」はずだからです。つまり、「新しい編集画面を作る」という作業のほかに「既存の編集画面を隠す」という作業を同時に行う必要があります。「隠してください」という要件であれば、機能を拡張するよりも要件はシンプルです。なので仕様を決めるという行為において、リスクやトラブルは軽減します。

しかし、「隠す」という行為そのものに様々なリスクがあります。

まず第一に、Salesforceは様々なユーザが様々な用途で便利に用いることを大切にしているため、様々な入り口が用意されているということです。つまり技術的に困難、もしくは実質実現不可能なケースがあるということです。先の「編集画面を隠す」というケースにしても、編集画面そのものは「開発した画面と挿げ替える設定」が公式に用意されているため、どんな時でもユーザがそのレコードを「編集する」という行為を行うと挿げ替えた開発済の編集画面が開くようになっています。このようなケースですら、例えば「リストビューのインライン編集」や「他オブジェクトからの自動更新」、「APIやDataLoaderからの更新」などそのレコードを更新する入り口は数多くあり、すべてをカバーすることは容易ではありません。無理にカバーしようとして他の既存業務やユーザに影響を与えてしまう可能性すらあります。

この場合、『作る人』としては、例えば特定のチェック処理を走らせたい、という理由があるならば、「すべての入り口を探してふたをする」のではなく、入力規則やトリガーなどで一番下流にあるデータベース処理側にチェック処理を置くことを考えます。画面にて対処しなければいけない、という『使う人』側の考え方にとらわれないことが重要です。

もう1つの大きな理由は、隠したいと思っている機能の裏側には多くの別の便利な機能が付随しており、それらも失うことになるということです。先の「編集画面を隠す」というケースでは、「編集画面のレイアウトを開発することなく設定画面から変更できる」というメンテナンス性を失うことになります。もちろん、標準機能の便利なチェック機能や入力方法が今後新たに導入された時もその恩恵を受けることができなくなります。『使う人』側からは見えない、想像できない部分で大きな損失があるかもしれないことを留意すべきですし、『作る人』はそれを常に分かりやすく説明すべきです。

上記のリスクを考えると、「Salesforceのある機能を隠す」という考え方よりも「Salesforceの機能を使って元から停止する(元栓から締める)」という考え方をベースにするべきです。最もよく言われ、最も困る要件が「特定の情報を表示させなくない・検索させたくない」というものです。本来、表示させない・検索結果に出ないといった要件は、元栓にあたる「アクセス権限制御」で参照アクセス権をレコードレベルではく奪して実現します。これが諸々の条件で簡単には実装できないからと言って「タブを隠してアクセス権限はあるがアクセスする手段を奪えばいい」と安易に考えると、後々大変なことになります。Salesforceにおいて「探して表示する」という機能はあまりにも重要で基本的であるため、あらゆるユーザのあらゆるケースに対応できるよう様々な機能が用意されています。他のレコードが参照していたり、レポートで表示出来たり、と様々な入り口があり、それに1つ1つふたをするのは事実上不可能です。いくら塞いでも、新機能が新たな入り口を作る可能性もありますし、Salesforceの最終手段「ブラウザのURLに”/<レコードID>”と入力すれば開ける」を防ぐことはできません。「列挙されるとうざいので普通に検索しても出てこないように」という理由であればまだわかりますが、セキュリティの観点からくる要件であれば、入り口をふさいだからOKとするのは非常に危険であり、なんとしてでもアクセス権限の制御で実現すべきです。

『作る人』はこのことを知っているため、『使う人』の「隠せないんですか?」という無邪気な質問や要件に多くの調査や説明時間を要することになります。回答や説明を求めることは重要ですが、容易ではないことは考慮してしかるべきです。


いかがでしたでしょうか?『作る人』側から見ると当たり前のことばかりかと思いますが、意外と『使う人』側には理解されていないことが多いのが現状です。

いずれも「だから開発しない」ではなく、事前に予算と時間を確保する、もしくはそのために優先順位をつける検討・判断をすべきで、その際にこの情報を活かしていただければ幸いです。

次のページで簡単にこの内容をまとめ、今度は『使う人』側の立場から、どのようなケースでどのような開発であればリスクが少ないのか例を挙げてご説明したいと思います。

Salesforceの生産性 ー プロトタイピングによる効果的な『要件定義』(3/3)

プロトタイピングは要件定義の難しさを解決するのか?

Salesforceの生産性 ー プロトタイピングによる効果的な『要件定義』(1/3)では、要件定義が何故難しいかを以下の3点で説明しました。

  1. 『使う人(利用者)』は作るべきものが何か分からない
  2. 『作る人(開発者)』にイメージが伝わらない
  3. 「リスク」は議論されない

果たして、プロトタイピングはこの3つの問題を解決しているのでしょうか?

  1. 『使う人(利用者)』は作るべきものが何か分からない
     『使う人』は、というよりも、一般的に人は、「何が欲しいですか」とオープンクエスチョンで聞かれると答えに困るものです。でも、「○○は欲しいですか?」とYES/NOで聞かれると答えられるもので、「何故ですか?」「どこがよいですか?」と聞くとどんどん答えていけるものです。そのため、プロトタイプで出発点を示し、「これでよいですか?どこか問題がありますか?」と問うと、少なくともそこから議論が始まるのです。
     しかし、最も大切なことは「出発点がどこか」ということです。「作るべきものが何か分からない」ことの最も恐ろしい点は、「大切ではないことにこだわってしまう」ことです。実は大切でないものを大切だと思ってしまうと、本当に必要なものにはたどり着きません。
     例えば「ボタンの位置が悪い」「操作が1つ多い」といったことは、電話を受けながら注文を代理入力するような業務では大切かもしれませんが、商談を入力するような数日に1回行う業務では商品やビジネスモデル、プロセスの変化に柔軟にシステムを対応させたり、受注率や売り上げを上げるために戦略的な分析ができることの方が重要です。ここで「ボタンの位置」など「操作性」にこだわり過ぎて全面開発してしまうと、もっと重要な「保守性」や「Salesforceの標準業務機能の活用」を阻害してしまう可能性があり、少なくともそういった議論に費やすべき時間を大きく浪費してしまいます。
     ただ、作るべきものが分からない『使う人』にとって、最初に思い浮かんだそれらしいことの方が重要に思えるものなのです。今のお客様の、対象の業務に最も重要なことは何か、Salesforceのどの機能、どの理念、どの特長に注目すべきか、それを冷静に分析でき「出発点」として誘導できる専門家の「プロトタイプ」と「デモンストレーション能力」が重要になってくるというわけです。その専門家の魔法のような「プロトタイプ」と「デモ」の重要な材料が、前工程である「企画」段階の課題検討、あるべき姿の議論であることは言うまでもありません。

     プロトタイプは、専門家が落とし穴を避けて適切な出発地点からお客様の頭の中の「完成形」を構築・誘導していくための強力なツールなのです。
     
     ただし、「落とし穴を避ける」とは「誤解されそうな点は見せず誘導したい完成形だけを見せつける」という意味ではありません。『作る人』は、落とし穴になりそうな「『使う人』の小さな心配」も適切に拾って見せるべきです。むしろ、『使う人』がそれに気づく前にプロトタイプで見せてその点を説明すべきです。
     大切なのは、Salesforceの専門家として、それが「どうして重要でないのか」「Salesforceがそのようにしている理由(利点・狙い)」をきちんと説明することです。それが慣れの問題であるならばそのようにデモし、またSalesforceの狙いがあるならばそれを具体的に示して見せ、『使う人』に納得してもらうことが重要なのです。

Salesforceの生産性 ー プロトタイピングによる効果的な『要件定義』(2/3)


プロトタイピングを用いたSalesforceでの要件定義と開発

画像に alt 属性が指定されていません。ファイル名: work-5382501_640.jpg

ここで、筆者がお勧めするSalesforce導入時の要件定義、及びそれ以降のプロジェクトの進め方をご紹介します。今回は『使う人』があまりシステムに詳しくなく、『作る人』チームがリードして開発を進める場合を想定し、『作る人』チームの視点から進め方を記載することにします。

  1. 企画
    プロジェクトを始める前に『使う人』と『作る人』でやっておくべきことがいくつかあります。
    • 『使う人』の現在の業務上の課題や今回のプロジェクトで成し遂げたいこと等、プロジェクトの目標を明確にして関係者と共有する
      • 例:売上が伸びない ⇒ 新規顧客/商談開発・クロスセル/アップセルにつながる営業活動ができるCRM機能を充実させる
      • 例:営業が事務処理に忙殺され営業活動の時間が十分に取れない ⇒ 営業プロセスの効率化と営業支援チームとの連携強化を実現する
    • 『使う人』と上記を達成するために必要な「プロジェクトの基本方針」を決める
      • 例:CRM機能を充実させる ⇒ 営業支援・マーケティングに関する機能に関しては標準機能を利用し、カスタム開発は極力避ける
      • 例:効率化とチーム連携の強化を実現する ⇒ 自動化とコミュニケーションに関する機能はカスタム開発もしくは外部サービスの利用を促進、営業プロセスに関する機能は変更に素早く対応できるようカスタム開発を極力避ける
    • 『使う人』と以降に記載するプロジェクトの進め方を説明し、『使う人』代表として参画して頂けるキーパーソンを選出する(「この人が決めたことならばまずは従ってみよう」と『使う人』が納得する人物・組織であることが望ましい)
    • 『使う人』に業務の概略を聞き、業務データの参考になる資料を入手する
       
  2. 要件定義 ー プロトタイプ作成
    業務データベースのドラフト版をSalesforce上で作成し、1.で聞いた業務の概略をSalesforce上でデモできるよう準備する
    • この時、業務用語や英語表記(システムの設定名に用いる)の辞書を作ってそれなりに正しい綴りにしておくと後工程が楽になる
    • 顧客管理システムや商談管理システムなど、Salesforceが提供する業務機能を利用する場合、ここでSalesforce業務機能の仕組みと理念、効果を伝えるようにする
      ※ Salesforce専門家の助けが必要かと思います
    • この時点で複雑な設定やコーディングはしない。なるべく日を置かないでデモを実施することを優先する
       
  3. 要件定義 ー プロトタイプ確認
    準備したデモを『使う人』に説明し、業務の流れがあっているかを確かめる。そして、『使う人』に使い方を説明する。
     
  4. 要件定義 ー プロトタイプ体験
    『使う人』にデモを動かしてもらう。本業務で使ってもらうのがベストだが、時間を貰って一緒に動かしてみる、位でもよい。
     
  5. 要件定義 ー プロトタイプフィードバック
    『使う人』に、使ってみて困ったことを出してもらう。実際の画面で説明してもらう。例えば以下のようなもの:
    • 項目が多すぎて目的のものが探せない
    • 同じ情報を転記するのが大変で業務が回らなさそう
    • 別システムにある情報は自動で埋まって欲しい
    • 目的の情報をうまく探せない(検索がうまくできない)
    • 計算や集計を自動で行って欲しい(できればグラフも)
       
  6. 要件定義 ー 実装方針案作成
    それぞれの「困ったこと」1つ1つに対して対策案を以下のように用意する。
    • 工数・リスクの観点で「松」「竹」「梅」案を用意する。
      「松」案はコーディングを用いて細部の要件まで適えた案
      「梅」案は標準機能だけで実現した案
      「竹」案は工数・リスクの観点で真ん中の案
    • それぞれの案の工数・納期、できれば価格を記載する
    • それぞれの案のリスク・懸念点を記載する。
      特に「松」案ではリリース後の保守運用も視野に入れる
       
  7. 要件定義 ー 実装方針案検討
    対策案の一覧を『使う人』と『作る人』の間で確認し、議論する。必要であれば対策案のプロトタイプを作成し、デモする。最終的に以下を決める。
    • それぞれどの案で対応するか(もしくは対応しないか)
    • どの順で「困ったこと」を解決するか(優先順位)
    • 最初のリリースで絶対に解決すべきライン

      ここまでを繰り返して初回リリースに含める機能とその実装方針を定め、『使う人』と『作る人』の両者で合意する(要件定義完了)
      ※ 対策案の一覧の説明情報を充実させた「業務機能一覧」とこれまでに用いた説明資料をもって要件定義の資料とする
       
  8. 設計・開発・単体テスト
    あらためて全体最適となる設計を行い、コーディングを含めた開発を行う
    ※ 細かな仕様はデモに立ち戻って『使う人』に実機で確認してもらう
     
  9. テスト(結合テスト・システムテスト・ユーザ受入テスト等)
    要件定義で説明した業務の流れが細部まで実現できるか、要件定義で出した「困ったこと」が十分に解決されているか、『使う人』と『作る人』の両者の観点でテストする
     
  10. リリース & 保守改善
    リリースする。その後も本番環境を要件定義におけるデモとみなして同じサイクルを繰り返す

次のページでは企画、要件定義、設計・開発・単体テスト、テスト、リリースのポイントとなる点をご説明します。

Salesforceの生産性 ー プロトタイピングによる効果的な『要件定義』(1/3)

前回お話しした「Salesforceの生産性 ー ローコード開発の秘訣」について1つ1つ解説していくローコード開発の秘訣シリーズ、1つ目のキーワードは「要件定義」です。

要件定義の難しさ

要件定義はシステム構築プロジェクトにとって、「システムがどう動いて何を実現するべきか」を決めるとても重要な工程です。この工程で最も話を難しくする要素は「『使う人(利用者)』と『作る人(開発者)』が異なる」ということです。つまり、作るべきものを知っている『使う人』が『作る人』に「システムがどう動いて何を実現するべきか」を伝える工程と言えます。

「両方知っている人が考えて作ればいいじゃないか」、そう思われる方もいるかもしれませんが、例えいたとしても1人ではどれだけ時間があっても足りません。作る側も作ってもらう側も組織として責任があるため、法的にトラブルにならないよう「依頼する」という形をとる必要もあります。何より、利用者の業務や課題、開発に必要なシステム構築・運用の知識は、どちらも直ぐに理解できるほど浅いものではありません。それどころか、多くの場合、『使う人』はシステムのことを全く知らず、実際に手を動かす『作る人』は利用者の業務など全く知らないことがほとんどです。「ノーコード・ローコード開発」が直接この問題を解決するのはまだ先の話でしょう。

そのような2者が、「システムがどう動いて何を実現するべきか」を議論すると、以下のような問題が発生します。

  1. 『使う人(利用者)』は作るべきものが何か分からない
    システムを『使う人』は、自身の業務をよく理解しているものの、システム、特にこれから使う新しい技術が何をしてくれるかを知りません。まだ古いシステムを使っていれば「今のシステムのココを直してほしい」と言えるのですが、特に新規に導入するシステムの場合は「何ができるようになるとよい」という要望すら出すのが難しいのです。
     
  2. 『作る人(開発者)』にイメージが伝わらない
    この有名な絵をご存じでしょうか?このサイトによると、オリジナルは1970年代に遡るほど昔のもので、それほど有名な絵のようです。これは、『使う人』である顧客が「作るべきもの」として伝えた要件が『作る人』側のチームの各メンバーに伝わるさまを揶揄したものです。


    顧客が本当に必要だったもの(出典:顧客が本当に必要だったものとは (コキャクガホントウニヒツヨウダッタモノとは) [単語記事] – ニコニコ大百科

    つまり、例え『使う人』が何を作るべきかを分かっていたとしても、それを業務や背景を知らない『作る人』に伝え、全員が同じイメージを共有することはそれほど難しいということです。少なくとも私にはこのジョークは笑えません・・・(あまりに現実を捉えすぎています)
     
  3. 「リスク」は議論されない
    これは少し悲観的過ぎる考えかもしれませんが、実際によく起こることです。『使う人』は、頼めば作ってくれると思い『作る人』に要件を伝えます。この際に、それを実現する際の難易度やそれに伴うリスク、工数などを考慮することはまずありません。『作る人』が考慮してくれると思い込みます。
    一方、「作る人」も、実は作ることが技術的に可能と分かればその難しさやリスク、工数を積極的に議論しようとしないケースがあります。少し不思議な気がしますが、『使う人』と『作る人』が違う会社の場合、『作る人』側にとっては契約違反にならない事が最も重要、もっと言えば、折角「大きな開発になる」方向に進んでいるのにわざわざブレーキをかけたくない、と思ってしまうのがビジネスです。
    よって、『使う人』がこうして欲しい、と言った要件は、多少???と思ってもそのまま受け止めて作ってしまう、ということが起きて得てしまうのです。

次のページでは、この問題に対する有効な解決策の1つ「プロトタイピング」についてお話しします。