業務のためにSaaSを選定するテックリサーチの思考の流れ

このスライドでは、自部門、他部門、もしくは顧客の業務のためにSaaS（Software as a Service）を選定するプロセスとしてのテックリサーチについて、私の思考の流れをモデル化してみようと思います。

正直日々鍛錬の状態なので、ご先達に指摘されたり、1年後に読み返したりすると恥ずかしい内容もあるかもしれませんが、それもご愛敬ということで。

Transcript

1. 業務のためにSaaSを選定する テックリサーチの思考の流れ 2021年 5月 那須野 拓実
2. Copyright © 2021 Takumi Nasuno. All Rights Reserved. 2 はじめに このスライドでは、 自部門、他部門、もしくは顧客の業務のために SaaS（Software as a Service）を選定する プロセスとしてのテックリサーチ について、 私の思考の流れをモデル化してみようと思います。 正直日々鍛錬の状態なので、ご先達に指摘されたり、 1年後に読み返したりすると恥ずかしい内容もあるかも しれませんが、それもご愛敬ということで。
3. Copyright © 2021 Takumi Nasuno. All Rights Reserved. 3 自己紹介 那須野 拓実 （なすの たくみ） https://takuminasuno.com/ja/ たなぐら応援大使（福島県棚倉町）。 トリプレッソを勝手に応援する人。 元語学屋。時々写真垢とか手芸垢。 本業はナレッジマネジメントとかオントロジーとか データ分析とかの何でも屋です。 ※上記の自己紹介は、2021年5月執筆当時のものです。 コンタクトはこちらからどうぞ！ ⇒ takumi_nasuno
4. Copyright © 2021 Takumi Nasuno. All Rights Reserved. 4 目次 ①テックリサーチを定義する ②テックリサーチの型『MEDLESモデル』 ③全体として気を付けたいこと
5. Copyright © 2021 Takumi Nasuno. All Rights Reserved. 5 ①テックリサーチを定義する
6. Copyright © 2021 Takumi Nasuno. All Rights Reserved. 6 ①テックリサーチを定義する 業務ニーズに適切なSaaSを選定し、 運用への滑らかな導入・定着へと繋げること。 運用定着 （オンボーディング） 業務ニーズ発生 運用導入 テックリサーチ
7. Copyright © 2021 Takumi Nasuno. All Rights Reserved. 7 ②テックリサーチの型 『MEDLESモデル』
8. Copyright © 2021 Takumi Nasuno. All Rights Reserved. 8 ②テックリサーチの型『MEDLESモデル』 Map ・Extract ・Drill ・Level ・Estimate ・Sprint の各段階で 業務要件とツール要件を反復する思考モデル。 Map (俯瞰) Extract (抽出) Drill (深掘り) Level (ならし) Estimate (見積もり) Sprint (全力疾走) ツール要件（対ベンダー） (1) 業務要件をざっくりヒアリング (3) 業務要件をある程度具体化する (5) 要確認項目を洗い出す (7) 業務に沿ってヒアリング内容を整理 (9) 発注プランの具体化 (11) 発注先の内定 (2) 市場にあるツールをざっと調べる (4) 候補となるツールを数個に絞る (6) 商談で個別に徹底ヒアリング (8) 他候補で挙がる論点を追加ヒアリング (10) 詳細見積もりの取得 (12) 追加提案を捌きつつ発注orお祈り 業務要件（対ユーザー部門）
9. Copyright © 2021 Takumi Nasuno. All Rights Reserved. 9 ②テックリサーチの型『MEDLESモデル』 個別に見ていきます
10. Copyright © 2021 Takumi Nasuno. All Rights Reserved. 10 Map (俯瞰) ツール要件（対ベンダー） (1) 業務要件をざっくりヒアリング (2) 市場にあるツールをざっと調べる ②テックリサーチの型『MEDLESモデル』 局所最適リスクを抑えつつ、ドメイン知識を身に付け、 スピード感ある立ち上がりを意識する。 Extract Drill Level Estimate Sprint Map ユーザー部門に今どんな業務をしていて、どんな問題を 抱えていて、それをどう改善したいのか、何がきっかけ で改善を志したのか、ツール名やジャンル名が具体的に 浮かぶかをざっくりヒアリング。最速最短で実行する。 ※現状に対する認識は人によってズレる可能性がある ので、たとえ自分がユーザー部門の所属だとしても 同僚へのヒアリングは必須。 ※ユーザー部門が思いつく手段は最適なものではない 可能性があるため、手段としてツール名やジャンル 名をヒアリングするがあくまで参考に留める。 ※自分が該当業務に詳しくない場合、この段階で専門 用語や言い回しなどドメイン知識をインプットする。 ヒアリング内容をもとに、ジャンル名でググったり、カ オスマップやまとめ記事などを漁ったりして、市場にあ るそれっぽいツールを高速でリスト化する。その際に、 15～30文字程度でツールの印象を記録し、サービスLP のURLを付記する。ジャンルにもよるが、1～2時間で 10～20ツールぐらいが列挙できると良い。 そのうえで、列挙したツールを俯瞰して、ツールを分類 するのに適切そうな2軸をとりあえず直感で考えて、 ツールを4象限にマッピングする。2～4時間で、とりあ えず作る。よく設定する軸は、モダンさ、共存性、自動 化力、カスタマイズ性、知名度、市場シェア、価格帯、 スケール性、撤退性など。後工程で全体感を維持するの に使うイメージ。そしてとにかく早く(3)を実現する。 業務要件（対ユーザー部門）
11. Copyright © 2021 Takumi Nasuno. All Rights Reserved. 11 Extract (抽出) ツール要件（対ベンダー） ②テックリサーチの型『MEDLESモデル』 風呂敷を広げて業務要件にバランス感を持たせつつ、 深く調べる候補に絞り込んで実効性を生み出す。 Extract Drill Level Estimate Sprint Map (1)で挙がった業務要件はユーザー部門が『やりたいこ と』として認知しているものばかりが挙がりやすい一方 で、『やらなくてよいこと』が挙がりづらい傾向にある。 そのため、(2)のマッピングをもとに一歩引いた議論を することで『やらなくてよいこと』を明確にする。 なお、ユーザー部門に対して、 (2)のマッピングという 『外からの（相対的に）客観的な情報』を提供すること で、情報を提供し合う対等なパートナー関係を構築し、 多面的な議論を生み出せるかどうががポイント。 ※このテックリサーチ最初のアウトプットをいかに早 く出せるかがユーザー部門からの評価に強く影響す る。70点を1週間で出すよりも、50点を1日で出す 方が評価されやすい印象。 (3)である程度具体的になった『やりたいこと』と『や らなくてよいこと』をもとに『限られた業務時間の中で それなりに時間をかけて調べるに足る候補』、つまり 『個別商談をするに足る候補』を絞り込むことで、テッ クリサーチにビジネスプロジェクトとしての実効性を持 たせる。だいたい3,4個、多くて5個ぐらいの印象。 ※絞り込みをできないテックリサーチは調べることが 目的化して、情報を大層に並べて満足してフェード アウトするリスクが高まる印象。 (3) 業務要件をある程度具体化する (4) 候補となるツールを数個に絞る 業務要件（対ユーザー部門）
12. Copyright © 2021 Takumi Nasuno. All Rights Reserved. 12 Drill (深掘り) (5) 要確認項目を洗い出す (6) 商談で個別に徹底ヒアリング ツール要件（対ベンダー） ②テックリサーチの型『MEDLESモデル』 業務要件の確認だけでなく、リスクを明らかにすること、 そしてツールの設計思想を押さえることが大事。 Drill Level Estimate Sprint Map (4)で選定した候補について、改めてユーザ部門と認識 合わせをしたうえで、『どんな業務要件を満たすと確認 できれば』採用に至れるかを改めて列挙する。 実際にツール名が見えると、「アレが欲しい」,「コレ も欲しい」などユーザー部門からの要望が増えるので、 それらを上手くまとめつつ、目的感にさかのぼって優先 順位を付けておくのがポイント。 盲点となりがちなのがお金回り。たとえば課金単位や契 約更新、契約解消の流れ、支払いサイト、オプションの 種類など。SaaSは利用拡大に応じて料金が増えるので、 料金増に繋がる要素はしっかり要確認項目に立てておく。 ※(3)～(5)は、1回の打ち合わせで終えることも可。 (5)で設定した要確認項目を軸に、個別商談で徹底的に ヒアリングする。何か違和感を持ったら即座に質問して クリアになるまで深掘りしてリスクを洗い出す。 「アレはできる？」,「コレはできる？」といったク ローズドクエッションは話術巧みに返されがちでネガな 部分が出づらいため「何が一番得意なツールなのか？」, 「どんなユーザーがターゲットなのか？」といったオー プンクエッションでツールの設計思想から情報を得る。 ※個別商談は時間がかかるので、余裕を持ったスケ ジューリングを意識しておく。 ※この段階で有力な競合ツールが新たに出てきた場合、 工程を調整のうえ、調査対象に追加するべき。 Extract 業務要件（対ユーザー部門）
13. Copyright © 2021 Takumi Nasuno. All Rights Reserved. 13 Level (ならし) (7) 業務に沿ってヒアリング内容を整理 (8) 他候補で挙がる論点を追加ヒアリング ツール要件（対ベンダー） ②テックリサーチの型『MEDLESモデル』 1周目の商談で足りていなかった部分をならして 全体感を持たせるイメージを持って、強く踏み込む。 Drill Level Estimate Sprint Map (6)の個別商談でヒアリングした内容をユーザー部門と 共有し、具体的な業務フローを仮置きで設計し、不明瞭 な箇所を追加質問として挙げる。 また、ヒアリングした内容をツールごとの比較表にする ことで、とあるツールではしっかり聞けているものの、 他のツールではからっきしな要素が出てくる。それらの ような自然と出てこない情報の多くはそのツールの弱み であるため、これらもしっかり追加質問として挙げる。 ※業務フローは初期段階からイメージできるのがベス トだが、多くの場合、想定していなかった嬉しい機 能が個別商談で出てくるわけで、実務として業務フ ローをイメージできるのは商談後のことが多い。 (7)で挙げられた追加質問について、個別商談にてベン ダーから回答を得る。踏み込んだ質問が多くなりがちな ので個別商談にて先方のトークの温度感含めて判断でき ると効果的。そのため、(6)の商談の終わりに1週間後 あたりに2回目の商談を設定させてもらっておくとス ムーズになる。 ※業務フローに沿った質問については、実際に画面を 見せてもらいながらの確認とすることで、思わぬ （ポジや）ネガを発見できる。導線の分かりにくさ やロード時間の長さ、一覧性の弱さなどは、プレゼ ンスライドではなかなか気づきにくいので要注意。 ※流れに任せる1周目の商談と違って、相手の弱みかも しれない部分に踏み込む2周目には度胸と話術が必要。 Extract 業務要件（対ユーザー部門）
14. Copyright © 2021 Takumi Nasuno. All Rights Reserved. 14 Estimate (見積もり) (9) 発注プランの具体化 (10) 詳細見積もりの取得 ツール要件（対ベンダー） ②テックリサーチの型『MEDLESモデル』 お金まわりはしっかりと！ シミュレーションを立てて先のことまで見通しを作る。 Drill Level Estimate Sprint Map 候補となるツールについて、一通りの情報が揃った段階 で、改めて業務要件や予算感を踏まえて発注プランを具 体化する。 多くのSaaSの場合、エントリープラン、スタンダード プラン、エンタープライズプランのように松竹梅が設定 されていることが多く、加えてオプションが多く用意さ れていることも多いため、「このツールを発注するとし たらこのプランかな…」というのを明確にできるのはこ の段階からだと思われる。100%自由に調整できるわ けではないが、料金に影響しやすいユーザー数もしっか り時系列でシミュレーションのうえ調整しておく。 ※あまり好ましいことではないが、プランを絞り切れ ない場合は複数プランの見積もりを依頼する。 (9)にて発注プランが明確になったら、ベンダーに詳細 の見積もりを依頼する。1,2日で取得できることが多い が、カスタマイズが多い場合は1週間ほどを見ておく。 SaaSはマーケット全体としてみると料金体系が非常に 複雑。月額固定のサブスクリプションと同一視されがち な一方で、ユーザー増や利用機能増での料金増が頻繁だ と実質的に月額固定に思えないような料金増をすること もあるうえ、キャパシティ制やクレジット制などと言わ れるような従量課金モデルでは見積もりの金額とキャッ シュフローがズレることもあるなど、注意すべきポイン トが多い。お金まわりは事前になるべくヒアリングはす るものの、実際の見積書や契約書を見て気付くことが圧 倒的に多いのが実務だと思われる。 Extract 業務要件（対ユーザー部門）
15. Copyright © 2021 Takumi Nasuno. All Rights Reserved. 15 Sprint (全力疾走) (11) 発注先の内定 (12) 追加提案を捌きつつ発注orお祈り 業務要件（対ユーザー部門） ツール要件（対ベンダー） ②テックリサーチの型『MEDLESモデル』 心して迎える最後。 契約締結まで全力で疾走する。 Drill Level Estimate Sprint Map (10)までの内容を踏まえて、コストパフォーマンスの 最も良いツールを発注先として内定させる。 内定にあたっては関連部署の確認や管掌役員の確認が必 要となることが多く、ステークホルダーが多い場合は各 人に最終確認を取る流れをスムーズにしておけるとよい。 ※注意点として、まずは十分な運用ができるかどうか のプロダクト力を最優先にして、金額は二の次にす ることが挙げられる。というのも、SaaSは素晴らし いツールも多い一方で安かろう悪かろうのツールも 混じる玉石混交なマーケットであり、値段を最重視 するとほぼ無条件に安かろう悪かろうのツールに手 を出してしまうからである。 発注先に選んだベンダーには速やかに発注の意思を伝え て発注手続きに入りつつ、同時並行で他ベンダーにはご 縁がなかった旨を伝える。 しかし、ここからが実は最終戦。 発注先が内定してから実際の契約を交わす間に稟議や リーガルチェックなどが入るケースが多く、契約締結ま でに数日から1週間ほどを要しがちなため、お断りの旨 を伝えた他ベンダーから押し込みの追加提案が来るケー スが散見される。会社によっては物凄いPUSHが来る。 限られた業務時間の中で、プロジェクトのデッドライン を前に、その様相はさながらSprint (全力疾走)。真摯 に対応しつつも上手く幕引きを迎えたい。 Extract
16. Copyright © 2021 Takumi Nasuno. All Rights Reserved. 16 ③全体として気を付けたいこと
17. Copyright © 2021 Takumi Nasuno. All Rights Reserved. 17 (1) ベンダーをパートナーとしてリスペクトする テックリサーチの過程では、商談という形でベンダーの時間をいただくことになる。ビジネス上しかたないことだが、商談の段階では相手に 一銭もお金が入らない。限られた貴重な時間をいただいているということを常に頭に浮かべ、相手に対する敬意を持ち、真摯に応対すること。 そして、自分がお金を払う側だからと横柄になるようなことがないように。当然である。 (2) それなりにパワーと時間がかかるものと心得る こういったテックリサーチは、既存の運用を継続しつつ並行にて進捗させるのが基本となるが、片手間でやれるものではなく、それなりにパ ワーと時間がかかるものと心得るべきで、つまるところ、テックリサーチを始める前に他タスクの調整をしてまとまった時間をとれるように しておくべきである。ツールが関与する運用領域や部門領域にもよるが、テックリサーチは概して最速で1ヶ月、順調に進んで2,3か月はかか ると頭に入れて、プロジェクト全体のスケジューリングをしておくと良い。 (3) 今の業務をリスペクトはするが、先入観なく再考して組み直す プロダクトありきのツール導入は、業務のリアルを加味せず失敗に至るリスクが高い。だが、ユーザー部門が何を考え、どう運用しているか に対して畏敬の念を抱くことが必須な一方で、既存の運用をそのまま引き継ぐべきというわけでもない。というのも、既存の運用は多くの場 合、デジタル面がボトルネックとなって非効率に業務遂行するしかない前提で局所最適に設計された可能性があり、デジタル面が改善される ことで見直す余地が出てくるからである。今に対するリスペクトと、未来に対する先入観なき再考の、バランスとりが腕の見せ所となる。 (4) 導入してからの運用管理を誰がやるかも考えておく この手のツールは、導入するのもひと苦労だが、運用を継続するのもひと苦労という側面がある。ツールを熟知した人が管理者として切り盛 りしていく必要があるわけで、それを自分が継続できるならそれでもよいかもしれないが、そうでない場合は誰が管理者として動けるかの落 としどころを作る必要がある。即戦力がユーザー部門にいればよいが、そうでなければ素養のある人を育成する、他部門から異動させるなど も考える必要が出てくるかもしれない。導入したら後はお任せで回るツールはほとんどない。上手く考える。 ③全体として気を付けたいこと
18. Copyright © 2021 Takumi Nasuno. All Rights Reserved. 18 最後まで お読みいただき ありがとうございました