プロトタイピングは問題を解決しない、問題を解決するのは・・・
Salesforceの生産性の鍵を握る「要件定義」、その問題解決するためのプロトタイピングを用いた要件定義とプロジェクトの進め方をご紹介してきました。しかし、もうお気づきかと思いますが、プロトタイピングそのものが問題を解決するわけではありません。ましてや生産性を向上させるわけでもありません。
プロトタイピングは、『使う人』と『作る人』が共に実現したい姿を共有し、利益とリスクを具体的に検討することを助ける「ツール」なのです。プロトタイピングをすれば何かが改善するわけでもなく、プロトタイピングをしなければ問題を解決できないわけではないのです。そもそも、「要件定義には『使う人』と『作る人』の間の問題がある」「要件定義の問題がプロジェクトの生産性に大きく影響する」ということを認識しないままプロジェクトを進めることが最も大きな問題と言えるでしょう。
Salesforceは「作ること」より「実現したいこと」に注力したい人達の仕組みです。そのためのクラウド、そのためのローコードプラットフォームです。そこにこそ「生産性」の秘密があり、特に「要件定義」にこそ今までのやり方の落とし穴があります。「実現したいこと」の利益とリスクを議論して、そこに注力することにプロトタイピングを上手に利用してみてはいかがでしょうか。
最後に、ここまでご説明したプロジェクトの進め方を成功させるために必要な『使う人』『作る人』両陣営の体制をご紹介しましょう。
問題を解決するのは、人、『使う人』『作る人』なのですから。
『使う人』陣営
- 意思決定者
要件の責任を持つ人物。実際に細かな要件を述べたり検討したりする役ではなく、「この人が決めたのであれば一度使ってみよう」と『使う人』側の皆が納得するような、その業務で大きな影響力を持つキーパーソンであることが必要。できれば検討会に参加していただき、方向性に迷ったときに、「どちらの価値観を重要視するか」「どちらをより大きなリスクと取るか」の判断をその場でして頂く。参加できないときは、その方の代理として認められている方に参加していただき、意思決定者の判断を仰ぐ宿題を受けて頂く。パイロットフェーズがある場合はこの意思決定者の直下の組織で行うのが最も効果的。
- Salesforceチャンピオン（候補）
検討会等で『作る人』と共に具体的な要件や仕組みを検討する人物。『使う人』としてSalesforceを理解して使いこなしていくことになる。『使う人』として業務や状況、既存システムの調査を引き受け取りまとめる役でもある。意思決定者の意思をよく理解する、若くて行動力のある人物が最適である。ゆくゆくはパイロットフェーズや初期リリースで利用ユーザの中心となり、推進を進めていく「Salesforceチャンピオン」になる。ITに明るい人材だと望ましいが、それよりも現状の問題意識を持ち、Salesforceを使ってよくしていこうと行動に移せる素質の方が重要である。
- プロジェクトマネージャー
『使う人』の様々な調整をする役。特に要件の検討会ではそれぞれの業務について「ゲスト」を招いて議論していかなければならず、それらの調整という非常に重要かつ煩雑な仕事をこなさなければならない。調整・管理能力の優れた人物である必要がある。また、意思決定者とは別のプロジェクト決裁者もしくはその他の経営陣に対し、適切な報告を行って時には適切な支援を求める必要がある。そういった、『使う人』側の調整や広報を行う役割を担う。
- ゲスト
各業務を検討するにあたり、プロジェクトメンバーが資料と想像で要件を述べることはきけんである。各現場からその時々の検討会に必要な「ゲスト」を招いて意見を聞くべきである。こうすることで、システムリリース後には各部門で「ゲスト」が中心となって推進してもらえる可能性が高い。そういう意味では、「業務をよく知る人」と「業務の主（ぬし）」といったペアで来ていただけるのが望ましい。
『作る人』陣営
- Salesforceマスター（プロジェクトマネージャー）
「スクラムマスター」のように、Salesforce流のプロジェクトの進め方や機能の活用方法を熟知した人が、『使う人』『作る人』がその方向性から外れないように気を配る役割。『使う人』の参画者にSalesforceの哲学や心得を伝えていく中心人物となる。Salesforceやその哲学、メソドロジーへの理解が深いこともさることながら、『使う人』がどれだけそこから離れているか、どうやって離れていきがちか、など『使う人』の特性やシステム開発プロジェクトの「闇」をよく知っている必要がある。最も貴重で育成したい人材。
- プロトタイプ開発者
検討会で用いるプロトタイプを開発し、デモする人材。前述の通り、プロトタイプは業務を理解する宿題であり、実現性を検証する研究でもあるため、ただ単にSalesforceの開発ができるだけでは役不足である。『使う人』に対して、その業務理解と実現に伴う課題がきちんと自分の言葉で説明できる必要がある。具体的には、『使う人』が違和感のないデモデータを作れ、説得力のあるデモンストレーションができるかどうかでスキルを測るとよい。実はこのようなスキルをきちんと身に着けている開発者はそれほどいないのが現状である。
- プレゼンテーター
検討会をリードする人物。プロトタイプのデモだけでは、なんとなく感覚でしか理解した気持ちにならない。さらに言えば、デモを見ていない人には情報共有や意見を求めることもできない。わかりやすく、要件定義書として残せる形の資料を毎回作成し、検討会をリードできるスキルが必要である。そのためには、Salesforceの哲学や基本的な機能の知識と、資料作成スキル、議論を引き出すためのファシリテーションスキルが必要である。プロトタイプ開発者とタッグを組んでうまくスキルを補完しあい、検討会を成立させていく必要がある。
次回は、次のテーマに移る前に、実装方針案作成時に用意する「松」「竹」「梅」案の「竹」案について少し経験談を述べたいと思います。『作る人』としてリスクの少ない開発とは何か、『使う人』に何とか納得して頂ける落としどころとはどこか、そのような「竹」案に使えそうなテクニックをいくつかご紹介できればと思います。お楽しみに！