第二弾は、某大手商社の情報システム部門にて本部長をされている方に、経費精算SaaSを導入した際の意思決定プロセスについてインタビューを行いました。

■決済者プロフィール
企業規模：数百人
業界：商社
部署：情報システム部門
検討SaaS：経費精算SaaS
導入結果：全社導入
購買プロセスにおける役割：提案部署の責任者かつ実行責任者

──はじめに経費精算システムの検討のきっかけを教えてください。
どの会社もそうだと思いますが、交通費や出張の経費精算は、意外と煩雑なものですよね。 上司からの承認を得ながら、ホテルの宿泊可否やグリーン車の利用可否といった細部まで検討しなければならず、それは結構な手間がかかるものです。そして、申請から精算までの過程も結構面倒くさいです。
これまではExcelで精算表を作成し、印刷してはハンコを押す、という流れでした。しかし、コロナによる在宅勤務が増え、紙を物理的に回すのが難しくなりました。このような状況を見て、今の時代ならもっと効率化できるのではないかと感じました。そんな時に「経費システムA」（仮名）を見つけました。
私のポジションからはグループ全体の動向を把握することが可能で、すでに外資系サービスを利用しているグループ関連会社も知っていたので、私たちが新しいサービスを導入する為のハードルも低く、ただ適切なタイミングを見つけるだけでした。 ただし、優れた製品が必ずしも市場で成功するとは限らないため、その品質だけでなく、その製品が市場で生き残る可能性も考慮し、その視点から新しいサービスの導入を検討しました。
一応、いろいろ比較しましたが、私は決め打ち型で、最初から経費システムAだろうと思っていました。導入事例は多いし、たまたま当時付き合っていたITベンダーもそのサービスの販売代理のようなことをやっていました。
あとは社内でロビー活動ですね。 稟議を回す時に、どうしても社長、経理部長、営業部長などが合意しないと物事が進まないので、この人たちに事前にロビー活動をしておきます。この問題の場合、ほとんどの方が困っているので、「この問題を解決しましょう」と提案すると、「ぜひやってくれ」という話になるわけです。
あとは選定時に、「本当に必要なのか」という話になるので、比較検討対象を幾つか選んで、比較表のようなものを作って、それを付けて「かくかくしかじかだから、経費システムAがいいと思うので、導入したい」という稟議を書いて回すという感じです。

──全体の流れが理解できました。サービスは既に認知していて、課題感も明らかだったので導入を決定したが、社内の手続きに沿って、他の選択肢との比較を行い、最終的に提案書をまとめたということですね。
そのような感じです。

──社内へのロビー活動についてもう少し教えてください
月1回の定例の経営会議があるのでそこで話すのは勿論ですが、 後は昼飯を一緒に食べに行くとか、そういうことが日本の会社では大事です。
また、予算を取っていないことは、とてもやりにくいのです。 社長などは、株主や親会社に、四半期決算や今期決算などをコミットしていますから、それに対して数字が悪くなることは賛成してもらえません。
予算計画は大体年次ごとに策定され、その中には中期計画も含まれます。我が社では中期計画は3年周期で、その中にも年間の計画が組み込まれています。「このような考え方で、このような事を進めていこう」という方向性については全員の合意を得る形で進行します。こうした状況下では、IT部門が業務効率化の推進を提案すると、それに反対する者はいません。
ただ、IT領域ほど足が短いものはありません SaaSの場合は物理的な償却が存在しないかもしれませんが、代わりにバージョンアップの要求が頻繁にあり、新しい投資が求められます。 これが経営陣には違和感を与え、ITの更新速度は非常に速いという事実を理解してもらうのは難しい部分です。それを如何に効果的に説明し、理解してもらうかが重要な課題となります。

──そこを説得する一番の武器は何でしょうか。
皆が現在の作業の非効率さをよく分かっていたので、経費精算システムの導入は簡単でした。
難しいものは、セキュリティー対策などです。入ってくるかどうか分からない泥棒が怖いから、お金が掛かるという話だからです。お金を掛けないと、泥棒を妨げられないのかという話になり説明が難しいです。
もっと面倒くさいのは、パソコンの入れ替えです。「この間、Windows 10を入れたばかりで、あの時、何年か持つと言ったよな」、「いや、Windows 11にしないと、、」という感じです。最近、そういうこともポピュラーになってきましたが、昔は大変ですよ。出ていくお金が半端ではないのです。

──経費システムAの時は、「これぐらいの無駄が発生しています」と数字を弾いたのですか。
あまり弾かないで済んだと思います。なるべく弾かないようにしているのです。 「もしこのままやったら、1人何時間で、何日で、会社全体で幾らです」というようなことをやらされる時はあるのですが、個人的にそれは意味がないと思っています。
例えばあるプロジェクトで、基幹システムを再構築した時に、数十億円の投資をしたことがあります。数十億の投資となると、皆、臆病になってしまい、「そんなにお金を掛けなくてもできるだろう」と言う人が出てきます。
そうすると、いろいろな数字を作らなければいけません。このプロジェクトの時は、私の前任者が「数十億円を掛けても、効果が数百億とでます」ということをやるわけです。 ただ、後々それが首を絞めことになるのです。

──それはどういう意味ですか。
要するに、七転八倒しながら何とか稟議を通すわけです。 しかし「本当に費用対効果が出たかどうか、レビューをしろ」という話になります。 さらに、社内監査が入った時に、システム投資は絶対に狙われるわけです。 そうすると、「おまえらは稟議の時にこう言っていたのだが、その目的は達成できたのか」と言われます。稟議を通したいが故に、苦し紛れに無理やり作ったようなそろばん勘定だと、後から見ると「なぜこんなことを言うのか」というものも結構あります。
私は長年やってきて、そういうことで苦しめられることを知っているので、そういう書類はなるべく残さないのです。最後は「いいものを入れたくないのだったら、もう入れないよ」と開き直っていました。自分だけが入れたくて周りを説得するというよりも、「いい加減、経費精算システムを入れましょうよ」と周りに言わせるのです。そういう方向に持っていく感じです。
そのために毎月1回、社長と定例会をやって、説得するのが難しい話は、「こんなことを考えているのですが、どう思いますか」とサウンドしておきます。相手がいろいろ心配していることを言わせておいて、裏で一生懸命に対策を考えて、あわよくば「うん」と言わせてしまいます。社長が乗り気になってしまえば、周りの取り巻き連中は大丈夫です。

──一般的な購買プロセスでは、 まず課題を整理し、その課題を解決する為の様々な施策やサービスを検討します。解決策の大枠が決まれば具体的な要件定義を作成し、その要件を満たす類似サービスを比較していきます。その結果を元に、合意形成や検証を進めます。このようにプロセスを分解し取り組む会社も存在します。
やっていないわけではないです。分解してやります。3カ月、6カ月という期間を設定して、その間にいろいろ調べ上げて、資料を作って、最後に提案します。 ただし、最初に答えは決めて、その答えに対して、時間をかけて、理由付けをしていく感じです。あとは周りを説得していくというか、周りにそれを言わせていくという感じです。
変な言い方になりますが、結局積み上げても裏切られるのです。最後に責任を取るのは自分です。日本の会社では、責任は全部自分で取れないのですが、暗黙的にはIT領域で失敗したらIT責任者の責任になります。周りがいくら要望しようが、いくら「これがいい」と言おうが、最後にうまくいかなかったら、全部自分の責任になります。データを調べたらこちらになったから、自分は納得できないけれども、取りあえずやってみるということは、絶対にうまくいかないと思っています。自分で納得できることは、いろいろなことが起こっても頑張ることができます。経験的にそれが正しいと思っています。
プロセスを踏んでいないわけではないのですが、どちらかというと後付けだと思ったほうがいいです。

──一方で、ご自身が巻き込まれたケースはありますか。最初はそう思っていなかったのだけれども、部下にうまく乗せられたというような。
部下に乗せられたことはあまりないかもしれませんが、上が暴走して、止めたけれども、やらざるを得ないということはあります。 とあるシステムを導入するという話だったのですが、生煮えのシステムだったので、 私はその時、上司と一緒に責任者に反対の説明をしに行きました。我ながら説得力のあるパワポを作り説明できたのですが、最後に当人は「そうなんだけれども、入れると言ってしまったんだよな」と言ったのです。社外に発表してしまったので、入れないと格好がつかないという話です。

──ありがとうございます。ご自身がプロセスに直接関わるというよりも、部下の方が、導入の背景、選定理由、競合はどこで比較したのかということをまとめて報告したと思います。ご自身の観点で、「ここが甘いので、もう少しやったほうがいい」という指摘は多かったですか。
あまりないです。私は暴走しないので、自部門の中でも定例的に打ち合わせをして、合意を形成していました。別に自分の意見を押し付けるほうでもないし、だんだん合意を形成しながら物事を進めていくので、あまりひっくり返すようなことにはならないです。

──そのプロセスの中で、例えば「もっと比較検討をきちんとやりなさい」、「機能要件は大丈夫か」など、アドバイスとして多かったことはありますか。
一番心配だったのは、自社が期待していることに全部対応できるかどうかという要件的なところです。弊社のやり方と合うかは、結構注意深く見ました。そこを間違えてしまうと、現場から「使えない」と言われてしまいます。多少のことは調整していけばいいと思うのですが、「これは仕様で、これしかできない」という話になって、現場には受け入れ難いものであったりすると、「誰がこれを選んだのだ」という話になってしまいます。そこが一番心配です。

──どのように、その懸念をつぶしていったのですか。
コンペ時にSaaSベンダーを呼んでいろいろな説明をしてもらう時に、 現場メンバーなど関係者にも集まって貰い、彼らにも積極的に質問して貰います。 導入サポートもして貰う事になるので、質問に対する対応がかみ合うかということも、結構ポイントだと思います。それがかみ合わない人たちだったら、導入はうまくいかないです。

──CS能力ですね。ただ、すべての懸念を質問だけでつぶせないですよね。
そうなんですよ。 だから私は事例を重要視します。質問にも限りがあるので、自社と似たような会社で導入実績があって、その会社の人たちが喜んでいれば、かなり保険になるというか、安心できるんです。そういうもの以外は導入しないようにしています。 他社で実験をさせるみたいな。ITの世界では、それは鉄則だと思っています。

──ファーストペンギンになるデメリットのほうが大きいということですね。
デメリットのほうがはるかに大きいです。ITベンダーがものすごい手弁当でやってくれて、しかもそれが大変魅力的で、これは絶対に勝てると思うことができればやるかもしれませんが、まずそういうことはないです。

──経費システムAのケースは、ある程度決め打ちだったということですが、一応比較検討する上で、何社比較しましたか？
多分、3つぐらいで比較したと思います。
あまり多いと、調べるのも大変だし、このケースの場合は、当時はライバルがあまりいなかった記憶です。

──比較表は最終的に○×表ですか。
○×表です。ただし、根拠が分からないと困るので、評価コメント付き○×表です。

──比較表における項目について教えてください。
結局、評価項目を何にするかということは、あえて言えば恣意的です。勝たせたいものに勝たせるように作られています。それをあからさまに見えないようにする感じです。客観的に見せているのですが、勝たせたいものが勝つようにしています。

──営業側からすれば、自社が勝つような○×表は持っていると思うので、結構協力的になると思います。
もちろん、あれば参考にします。それはウェルカムです。

──営業資料やHPなど、そもそも営業が提供するコンテンツは、検討を進める上でどれくらい見ましたか。
たくさん見ました。やはり実績重視で、導入事例をよく見ました。
似たような会社で事例があれば、こちらの心配事を1つ言っただけで、10ぐらい分かってくれるわけです。「それはこうやりました」と言われると、とても響きます。しかし、事例がない場合は、その業界の課題も知らないし、10を説明して、やっと5だけ分かってくれる世界ではないですか。そこが全然違います。

──他に気にするコンテンツはありますか。
サービスの手触り感は気にします。現場のITリテラシーは、会社によって全然違うと思うのでが、私がいるような会社は、全く駄目ではないけれども、全然素晴らしくもない状態なので、分かりにくいシステムは問い合わせ対応も大変になってしまうのです。 特に小さい会社は、社内のヘルプデスクが充実してないので、数少ない担当者に問い合わせが殺到して、その人の仕事が回らなくなってしまうことが起きます。いかに現場が人に聞かずに操作できるかというところは、とてもチェックします。

──どのようにチェックしますか？
自分で触っていて、このぐらいだったら大丈夫だと大体分かります。 ただ、複雑なシステムは判断が難しいです。そうであるが故に、実績があって、「この会社で使っているのだったら、弊社でも大丈夫だろう」というところが、とても大事だと思います。

──事例を何社か聞いた上で”経費システムA”になったのか、その前から目星は付いていて、事例を聞いて、「やはりこれで良かった」となったのでしょうか。順番で言うと、どちらですか。
事例がないとその気にならないので、「そろそろかな」というような、タイミングで導入検討をしました。

──常に頭の中にあって、そろそろ”経費システムA”の事例がたまっていそうだということですね。
そうですね。会社に入れたいものが、引き出しの中には常にいろいろ入っているわけです。
それをどのタイミングで実行に移すかということを、いつも考えている感じです。

──事例が重要という話ですが、一方で最近のSaaS、どこも事例が豊富だと思います。 事例での差別化はなかなか難しいと思ったのですが、どうでしょうか。
確かに、今だったらそうかもしれません。当時は類似サービスも多くなかったです。今、ゼロから考えて比較したら、確かにおっしゃるとおり、難しいかもしれません。あるいは、そうやって社内でロビー活動をした時に、経費システムAではなくて、他のサービスがいいと言っている者が経理部門にいて、彼が「うん」と言わないと入らないという話だったら、費用や機能など、私が気にしているようなことがクリアできそうであれば、他のサービスになったのかもしれません。
また、当時付き合いのあったSIerがそれを担いでいたということもあります。もし「こちらのほうがおすすめです」と言われて、それが変ではなかったら、そちらにいった可能性もあります。

──いろいろなところから「経費システムAが良さそう」、「皆が触っている」ということが若干あって、空気感ができ上がっていたという感じがありますね。
そうですね。それで説明を受けたら、とても良かったということで、とんとん拍子に進んでいった感じはあります。

──事例が少ないサービスを導入した経験はありますか？
あります。
経営陣から「いいから使ってやれよ」という感じで導入されました。私は当時、「どうかな」と思っていたのですが、入れてみたらとても良かったです。彼らも、まだ駆け出しだったから、ものすごくディスカウントしてくれました。使ってみたら本当に良かったので、他のメンバーからも喜ばれ、自然に定着していきました。

──事例主義が崩れることはなかったのですか。その後、事例がなくても新しいサービスも試してみようというふうにはならなかったのですか。
なりませんでした。上記ケースの場合は、システム部門だけの導入だったからです。 それが全社だったら、やはり怖いです。私の部長が「入れろ」と言って、その部長の責任範囲内であり、「使ってみなければ分からない。嫌だったらやめればいいだけの話だ」という感じです。リスクがきちんと取れているというか、バランスが取れていた規模でやったわけです。
私もとあるシステムを入れてみたことがありましたが、それも自分の権限で、自分の部門だけでやりました。「われわれがやってみて、それで便利だったら、それでいい。お金は全然問題ないし」というところであればチャレンジします。しかし、会社全体ということになると、あまり冒険はできないです。

──いろいろと深い話までお答えいただきまして、誠にありがとうございました。
ありがとうございました。