【Buyer's Voice】大手総合化学メーカー-セキュリティSaaS導入
Buyer's Voiceは、企業がどのように課題を整理し、解決策を把握、比較し、決断を下すのかという、Buyerの意思決定プロセスに焦点を当てた新しいメディアです。
第四弾は、大手総合化学メーカーの情報システム部門にて部長をされている方に、セキュリティSaaSを導入した際の意思決定プロセスについてインタビューを行いました。
■決済者プロフィール
企業規模：数万人
業界：化学
部署：情報システム部門
検討SaaS：セキュリティSaaS
導入結果：システム基盤として導入
購買プロセスにおける役割：次長（意思決定者） ※最終決済者は上席（部門長）
──まず、検討に入ったきっかけを教えてください。
まず、部の年度計画を⽴てていきます。部の年度計画は、前年度課題の進捗状況にその時々のトレンド等を加えて新たな課題が設定し、その課題に対するいろいろな対応が検討されていきます。
次に部の年度計画がブレイクダウンされて、課の年度計画になり、今度は係に下りて係の年度計画ができます。
例えば、部レベルの課題が「セキュリティーの強化」だったとすると、課レベルの課題はそれが少し具体化されて「パソコンのセキュリティー強化」ということになります。係レベルになると、それがまた細化されて「現状のアンチウィルスでは対処できない脅威への対応」ということになり、その具体的な対応として、「EDR導入」という流れになっていきます。
──計画外で通る予算感はどれくらいですか。
例えば、部の予算が1億円だとした時に、いろいろな案件を進める中で取りやめになることや、安く入れられるものもあるので、その余剰分を使うということになります。感覚的に言うと、計画外で入れられるものは年間1,000～2,000万円だと思います。
──課題はトップダウンで整理されてく事が多いですか。
部の年度計画を立てる時に、トップダウンのものもあれば、現場からボトムアップで積み上げていくものもあり、両方合わせて部の計画になっていきます。全てがトップダウンではありません。
──解決策はどのように調査したのでしょうか。
取引のあるベンダー、SIer、コンサルからまずは営業ベースで1次的に情報を⼊⼿・整理します。その後、より具体的に進めようということになると、次に、営業ベースで頂いた情報の中で筋が良いベンダーにRFIを出し、より細かい情報を入手します。ここで概算レベルの費用も含めて情報を集めます。
また、リサーチャーによる市場調査の情報も参考にしています。海外では、ガートナーのMQ（Magic Quadrant）は、よく参考にしています。国内では、総研系などの情報参考にして、幾つかの製品候補を挙げていきます。
──次に、解決策を構成する要件です。どのようにして、社内で具体的な要件を詰めていくのでしょうか。
製品・サービスが決まって、ベンダーやSIerに発注すると、要件定義・設計・開発、SaaSの場合は設定・実装になると思いますが、その後にシステムテスト・運用テストという、いわゆるウォーターフォール型のプロセスで製品・サービスを導入していくことになります。要件定義は、そういう工程の中でやっていきます。
──RFIの中に入っているというイメージですか。
ベンダーに発注する段階になるので、どちらかというとRFPですね。ただし、RFPを出す前に、こちらでも製品・サービスの機能や制約は、ある程度調査するのですが、あまり具体的な内容をRFPに記載すると、システムを実装するための要件定義になってしまうので、どちらかというと実現したいことを主に記載します。 われわれが知らないことを、SIerから、より細かく、より良い提案を出してもらうために、敢えてそのような書き方をするケースが多いです。
──サービス比較は、今のプロセスの中で、どこに位置付けられるのでしょうか。
複数のベンダーにRFPを出して、違う製品・サービスを持ってくるようにベンダーを選ぶのですが、そこで出てきたRFPに対する提案内容を比較すること、イコール、製品評価というプロセスに位置付けられます。
──この製品評価は何をどう評価していくのでしょうか。
まず提案内容をQCD（Quality、Cost、Delivery）で比較することが多いです。 クオリティーは、大きなウエイトを占めています。要は、実現したいことが、どれだけ実現できるのかということを評価します。 コストは、投資と経費トータルで見た時に、どれぐらい掛かるかという比較をすることが多いです。 デリバリー（納期）は、RFPに記載している実現した時期に対して、きちんとコミットメントできているかどうかを評価します。
──QCD以外でも比較しますか。
契約内容を加えるケースもあります。例えば、損害賠償、瑕疵担保、利⽤規約など、サービス継続に対してどのようにコミットメントしているかを評価します。どんな障害が起こっても⼀切関係ない、 1円も払わないというものは NGです。
──QCDは、○×比較表を作っていくのですか。
はい。導入するサービスの金額感にもよるのですが、細かく評価するものもあれば、大括りで評価するものもあります。
最終的に決裁を取る時の資料としては、上位者に報告するための資料としてパワーポイントに要約してまとめるのですけれども、関係者間ではExcelベースでの評価をすることが多いです。
──ベンダーがそのプロセスに直接入ることはありますか。
ないです。社内でやります。逆に、そこにベンダーを入れると、公平な評価になりません。
──中身の○×や評価は抜きにした形で、どういう項目で比較をしようとしているかということは、各ベンダーも認知していますか？
はい。それに対して回答をもらって、その回答を評価していきます。
──SaaS系では新しいプレーヤーがどんどん出てきますが、基本的にはQCDの基準で評価していくのでしょうか。それとも、クオリティーは足りないけれども、ビジョンがしっかりあって、そのビジョンに共感して検討することもあるのでしょうか。QCD以外の判断基準軸が発生する可能性があるのでしょうか。それともルールとして必ずここに落とし込むのでしょうか。
基本的にはQCDです。製品・サービスを選定する時に、基本的には勝ち馬に乗ることが大事だと思っています。「そのサービスは、どこの会社が出しているの？」、「その会社は大丈夫なの？」、「MQに載ってないじゃないか」など、誰も知らないようなサービスを選ぶことはないです。非常に素晴らしいとか、ビジョンもエッジが利いているといった、定性的なことで選ぶことはあまりないです。
──安定的に稼働して、十分な実績があるところに集約されていくイメージですね。
そうですね。特に実績は見ます。ファーストユーザーになってリスクを取ることは、あまりないです。
──今は、どのSaaS企業も事例・実績は、最低限、豊富に見える印象があるので、実績で判断しづらい部分もあると思いますが、どのように見極めていきますか。
サービス事業者から直接導入をする場合はそうだと思うのですけれども、基本的にはパートナーが導入支援をされるケースが多いです。そうすると、サービス自体がいろいろな会社に使われていたとしても、そのサービスを導入するSIerの力量も違ってきます。その力量を見極めるために、先ほど話したような情報を基に進めていきます。
──サービス開発をしている会社が直接営業するのではなく、そのサービスをSIerが担いで営業しているということですね。
はい。
──逆に言うと、SaaSの提供会社からの直接営業がないのでしょうか。
直接導入した製品は、あまりないです。
──勉強不足で大変恐縮ですが、それは「情報システム部門あるある」なのでしょうか。
いや、基本的にサービス事業者が直接やってくれるものがあれば、SIerを通すことはないと思います。SaaSの世界は、サービス提供をするほうに力を入れていて、エンタープライズ向けに実装していくところは外部を使うケースが多いように見受けられます。多分、そこまでの要員もいないのだと思います。
──料金によって、RFPまでは作らないなど、比較のプロセスが変わりますか。
あまりないのですけれども、製品やベンダーを決め打ちするような時には、複雑な手続きを省略することはあります。基本的には、複数ベンダーの相見積もりが原則なので、RFPを作って、提案を受領して、それを評価して、決定していくというプロセスが多いです。
──稟議プロセスで相見積もりが決められているので、決め打ちでも比較したという痕跡を残す必要があるというイメージですか。
弊社の購買ルールがそのようになっています。そこは情報システム部門が決めることではなく、「取引に関してはこういうことを守りなさい。相見積もりを取ってください。透明性を確保してください」と、結構細かいルールがあります。それに則って進めています。
──決め打ちで決める場合と、そうではない場合では、具体的な線引きがあるのでしょうか。
そのサービスはこのベンダーからしか導入できないというものです。近年は、そういうものはあまり経験がないですが、以前はそういうものもあったような記憶があります。
──そうですね。
最近はどのサービスでも、最低2～3社は競合がいそうですね。
はい。同じ製品・サービスを取り扱っている複数ベンダーにRFPを出して、評価するケースもあります。
──合意形成が発生したプロセスは、これまでお話し頂いた中でありますか。
合意形成というか、決裁プロセスになると思うのですが、先ほど⾔ったようなアプローチで製品を調査して、 2〜3の製品を1次選定して、担当の課や係で「この製品でいきましょう」ということを決めます。
次に、部内は合議制で決めますが、最終決裁者は部⾨⻑になります。
複数ベンダーの製品を評価して、「こういう結果で、これでいきたいです。 ⾦額はこれぐらいです。実現されるのはこのようなものです」という、先ほどのパワポで説明して、そこで決裁を受けます。
──何人ぐらいですか。
7～8人ぐらいです。
──多数決になるのですか。
それとも全員が同意しないと進まないのですか。
最終的には部門長の意思決定になります。1～2人、「それはどうかな」という人がいたとしても、部門長が「これでOKだ」と言えば、そこで決裁されます。
──稟議書を作って、最後にはんこを押してもらうというプロセスの前の話ですか。
部⾨⻑決裁、担当役員決裁、社⻑決裁など、 ⾦額によって決裁者のレベルがあり、ハンコをもらう部署も変わってきます。 今お話ししたのは部レベルでのプロセスになります。部以上の決裁プロセスになると、導⼊したい製品・サービスに関わる部⾨の部⻑に説明して、はんこをもらって、最終的には担当役員の決裁をもらいます。 担当役員決裁より⾼い決裁額だと、会社レベルの会議体で討議・審議されて、決裁されるということになります。
──決裁レベルで、必要な資料は変わってくるのですか。
変わってきます。部門内の決裁だと、情報システムで飯を食っている人間ばかりが聞いているので、専門用語を使っても違和感がないですけれども、部門外で説明する時には、なるべく専門用語を使わず、平易にして、分かるように説明しなければいけないので、だいぶ手間が掛かります。担当役員でも情報システムに明るいわけではないので、そこはいろいろ工夫しなければいけないケースがあります。
──ひっくり返されることはありますか。
ひっくり返されることはありませんが、「ここがよく分からない。ここはどうなっているのだ」ということで、2～3回、チャレンジするケースはあります。要は、ハンコを押してもらうまでに何回か繰り返し説明をするケースはあります。
──そこにはコストを掛けないという意思決定が出たこともあるのですか。 それとも何回かチャレンジすれば必ず通るのですか。
年度の予算計上をされているものについては、もともと入れることを計画しています。それをより具体的にしたものを持って決裁を取りにいくので、取りやめになるケースはあまりありません。年度計画外のもの、そもそも予算が計上されていないものについては、なかなか難しいところがあります。「今年やらなければ駄目なのか。来年度予算に計上して、来年やったらどうか」と言われます。経理部等に経営的／財務的な視点でチェックされます。
──心理的には、年度予算を決める時には多めに申請しておいたほうが、後々通しやすいと思ってしまいますが、そういうことはありますか。
年度の投資や経費を計上する時に、「昨年度並みにしなさい」とか「昨年度の10％減にしなさい」など、トータルでの指示があります。そこでふたをされて、べらぼうな金額を無条件に計上できるような仕組みにはなっていません。
──営業から提供される情報はバイアスが掛かっている場合があると思います。 その情報の検証はどのようにしていますか。
昔のように、「できる」と言っていることが、やってみたらできなかったというケースは、今はありません。したがって、頂いた情報を検証するケースはあまりないです。RFIを出して、幾つかの製品で簡易的なPoCを実施して、機能検証をするケースはあるのですが、基本的にはベンダーやサービス事業者の技術営業やSEから情報を入手し、デモをしてもらって、そこで検証することが多いです。
──セキュリティSaaSでは、トライアル的な検証機会を提供してくれるのでしょうか。
最近は実際に触れさせてくれるケースが多いです。お客さん用の環境だとは思うのですけれども、アカウントを払い出してもらって、そこで実際に使わせてもらうことはあります。
──購買プロセスを進める上で、決裁を取るまでに苦労したことは何でしょうか。
あくまでオープンかつ公平に製品を評価した結果こうなりましたと皆が納得できるようなものではなくてはいけません。部下が作る評価表やレポートなどに関して、「こういう視点が足りないのではないか」とか「こんな書き方をしたら恣意的に見える」などと指導するところが大変でした。
部内の決裁はさほどないのですけれども、部外の部門長や担当役員に説明する時は、部内で説明した資料をそのまま持っていっても意味が分からないので、聞く人のレベルに合わせて作り直して持っていくところが、手間のかかる作業でした。
──そういった資料は、SaaSを提供している営業が作ってくれることはありましたか。
もちろん資料に必要な情報の提供はしていただきますが、ベンダーに社内決裁用の資料を作ってもらうことは、ほとんどないです。自分たちで作っています。
──営業に期待することはありますか。
これは会社というより、営業個人の能力やマインドによることが多いと思うのが正直なところです。営業が窓口になって、仕様や技術的なことの質問・確認を受けてくれるのですが、なかなか回答が来ないこともあります。こういうことには、すぐにレスポンスをもらいたいです。
それから、導入時に問題や障害が発生した時に、即座に社内でエスカレーションして、部門横断的に人を集めて体制を整えていくことができるかどうかも、営業の力量だと思います。そのようにエスカレーションして、社内を動かすような営業は、非常に心強いと思っています。
また、特に外資系に多いのですけれども、人の出入りが激しくて、新しい担当が紹介されても引き継ぎがされていなくて、また一から説明しなければいけない場合があります。そういうところは、会社としてきちんとサポートしてほしいと思います。
──今までのプロセスで、御社の部門長や担当役員など、関係者に営業が直接プレゼンをすることはありましたか。
例えば、購買に関する製品やサービスを購買部門主導で導入するようなケースは、情シス部⾨も同席しますが、購買部門長に対してベンダーがプレゼンすることはあります。
──先ほどのセキュリティーSaaSだと、購買部門にも営業がプレゼンをするということですか。
セキュリティーに関しては情シス部主導で導入するので情シス部に対してのみプレゼンされますが、購買システムだったら購買部門、⼈事システムだったら⼈事部門というように、導入を主導する部⾨に対してベンダーが説明するというケースはあります。
──役職者レベルはありますか。例えば、部門長が直接話を聞いてみたいとか、このベンダーの偉い人と話したいというリクエストがあるものですか。
それは製品・サービスを入れるケースよりも、部門長や役員がどこかから話を聞き付けて、「このベンダーと話をしたいのだけれども、誰かいないか」というケースはあります。
──何かしらの機会でサービスを知って、詳細な話を受けたいという話もあるということですね。
そうですね。サービスを受けたいというよりも、そのベンダーの偉い人と取りあえずつながっておいたほうがいいというような、人脈形成のパターンが多いかもしれないです。
──現在は買う側にとって情報が多過ぎて、整理するのが大変ではないですか？
比較表を作ることは手間なので、そういうサービスがあれば使ってみたいです。
──社内説明用に資料を作る際、足りない情報があればどのように探しますか？
webでリサーチするよりも、困った時は「こういう情報がないか。こういう資料がほしい」という形で、営業に直接連絡していろいろな情報をもらって、物事を進めるケースのほうが多いです。
製品選定の段階であれば、情報システムに関するサイトが複数ありますが、1つの製品に対してそれぞれのサイトに行かないといけません。 製品起点で記事がまとめられているようなものがあれば便利だと思います。
──分かりました。本日はお時間を頂きまして、ありがとうございました。
ありがとうございました。
当メディアは、バイヤーイネーブルメントSaaS「GRiX（グリックス）」
を提供するAimyTech株式会社が運営しております。