PMFまで4年、全社でCSに集中した決断──DiggleCTO・水上駿氏が語る、経営管理のスタンダードづくり

ディグル株式会社

数字の可視化から、経営のアクションにつなげる

──　まずは、御社の事業内容について教えてください。

現在は、祖業である予実管理を軸に、人員管理、設備投資管理、リベート管理、売上予実管理など、複数のプロダクトを提供しています。

予実管理では、予算を策定し、実績と突き合わせて差異を把握し、次のアクションにつなげる一連の業務を支援しています。特に上場企業では、こうした業務をExcelで行うことに苦労されているケースが多く、そこに対してプロダクトを提供しています。

もともとの対象は、売上、原価、販管費、利益といった損益計算書(PL)が中心でした。ただ、人員の動向や設備投資など、PLの数値につながる手前の情報も把握したいというニーズがあります。そうした領域に対応し、管理できる範囲を広げています。

──　データがつながることで、経営判断はどのように変わるのでしょうか。

例えば、人員管理で数字を変えたときに、それにひもづく売上のKPIや人件費、最終的な利益がどう変わるかまで分かるようになります。すると、「本当にここで人員を増やすべきなのか」「別のところに配分したほうがよいのではないか」といった議論ができます。

私たちが大事にしているのは、単に数字を可視化することではありません。その結果から、どのようなアクションを取るべきか、示唆まで提示することです。

予実の差異に加えて、その要因を示し、経営会議で具体的な議論につなげてもらう。さらに1か月後には、取ったアクションの結果を振り返れることも大切です。

人員の変化までたどれれば、「人件費を下げよう」という話だけでなく、「こちらで予定していた採用を、別のところに振り向けたほうがよいのではないか」といった、踏み込んだ判断ができる。データがつながる価値は、そこにあると思います。

掲示板への興味から、顧客に届く価値への関心へ

──　プログラミングを始めたきっかけを教えてください。

10歳頃、親がパソコンを買ってきたのですが、親はあまり使わず、ほぼ私のものになっていました。最初はゲームの攻略サイトを見るためにインターネットを使っていたのですが、掲示板やチャットで人とやり取りできることが面白くて、夢中になったんです。

そのうち、自分でも同じようなサイトを作れないかと思うようになりました。調べる中で、ホームページ・ビルダーやHTML、CGIの存在を知り、触っているうちに少しずつ作れるようになった。それがきっかけです。

──　大学では、なぜ数学を選んだのでしょうか。

中学生の頃はゲームを作るのも面白そうだと思っていましたが、自分自身がゲームに飽き始めて、ゲーム業界に進むのは違うかもしれないと考えるようになりました。

高校生になって、プログラミングや工学系に進むのが自然だろうと思いました。ただ、プログラミングは自分で調べて学べるので、大学に行くなら、大学でこそ深められることをやりたいとも考えたんです。数学は得意だったので、もっと突き詰めようと思い、数学科に進みました。

大学院では、プログラムを使って定理の証明を書き、検証する定理証明支援系を研究していました。受託開発会社でアルバイトもしていました。

──　スタートアップのインターンには、どのような経緯で関わったのですか。

ちょうど「クラウドサービス」という言葉を聞くようになり、子どもの頃から触れていたWebの技術が、企業の業務にも役立つものになっていると知ったんです。自分がやってきたことも仕事になるかもしれないと思い、企業を調べて話を聞きに行きました。

そこで経験を伝えると、「やってみない？」と声をかけてもらい、関わり始めました。

顧客への関心が、Diggleへの参画につながった

──　Viibarでは、後にDiggle代表となる山本さんと出会っています。どのように関係が深まったのでしょうか。

私はインターンのエンジニアとして入り、山本は営業マネージャーとして入社しました。

仕事をする中で、私はプログラムを書くことだけに強い関心があるわけではないと気づきました。作ったものがお客様に価値を感じてもらえて、実際に使われることが大事だと思うようになったんです。

当時は会社も転換期にあり、どうすればプロダクトを使ってもらえるのか、お客様にとっての価値は何かを考える必要がありました。私はそこに関心があって、顧客インタビューや営業同行をしていました。

営業やビジネスの経験はなかったので、価値をどう伝え、購入につなげるのかを知れたことは、大きな学びでした。山本にもいろいろ聞いていたので、ビジネスの話にも興味を持つ、少し変わったエンジニアに見えていたのかもしれません。

──　そこから、Diggleへの参画につながったのですね。

私がフリーランスになるために退職するタイミングで、山本も会社を辞めることになりました。そのとき、予実管理の領域で起業したいと聞き、「一部、手伝いましょうか」と声をかけたのが始まりです。

当時は、15人ほどの規模だったSmartHRなど、複数のスタートアップに関わっていました。ただ、本当にゼロからプロダクトを作る機会はなかったので、面白そうだと思ったんです。最初のプロダクトは、ほぼ一人で作りました。

──　経営にフルコミットする決め手は何でしたか。

経営企画の方々に話を聞くと、ファイルを開くまでに2分かかる、数字を一つ変えると10秒待つ、数百メガバイトあるExcelファイルをメールでやり取りする、といった状況がありました。いずれやり方が変わっていく領域だろうと感じ、市場として大きな機会があると思いました。

転機になったのは、2016年のTechCrunchのピッチイベントです。ファイナリストになって賞もいただき、ブースではファイナンスの経験があるVCの方々から「これは伸びるから、やったほうがいい」と言われました。

実務を知る人たちがそこまで可能性を感じているなら、自分が思っている以上の機会なのかもしれない。山本からも経営に参画してほしいと言われていたので、フルコミットすることを決めました。

契約は取れても、使い続けてもらえない──PMFまでの4年間

──　フルコミットで参画してからは、いかがでしたか。

私自身の経験不足もあったと思いますが、想像以上に苦戦しました。2016年に始めて、PMFに至ったのが2020年頃なので、約4年間、プロダクトを作ったり変えたりしていました。その間に、2、3回は作り直しています。

課題は明らかに存在していました。ただ、それを解決するソリューションとして、きちんと成立するプロダクトを作るのが難しかったんです。

──　最初の壁は、何だったのでしょうか。

対象を広く捉えすぎたことです。予実管理は、スタートアップにも大企業にもニーズがあります。大企業の中でも、マーケティング部門の予算管理だけをしたいというケースもあります。

すべてに対応しようとすると、プロダクトはどんどん汎用的になります。工夫すれば何でも表現できるものにはなりましたが、改善の方向性が定まりませんでした。あるお客様の要望に合わせると、別のお客様には使いにくくなる。すべてに応えることもできません。

何でも中途半端にできるけれど、どれも十分にはやり切れない。このままでは厳しいと感じ、ユースケースを絞りました。

その結果、対象となる業務に集中して開発できるようになりました。営業でも、どのような課題を解決するのかを伝えやすくなり、契約が増えていきました。

──　その後には、どのような課題がありましたか。

カスタマーサクセスです。当時、私たちはツールを提供すれば、うまく使ってもらえるのではないかと考えていました。十分に伴走しないままになっていて、導入から1年ほど経っても、使いこなせないケースが次々に出てきたんです。

難しかったのは、新しい契約自体は取れていたことです。売上は立つのですが、解約によってARRが削られるので、積み上がっていかない。一方で、営業・マーケティングや開発は続けているため、手元の資金は徐々に減っていきました。

いずれPMFして成長するのではないかという期待はありましたが、このままでは資金が尽きることも見え始めていました。それでも、どうするかを決め切れずにいた。2019年頃までは、そこが最も大きな課題でした。

──　そこから、営業や新規開発を止め、全社員でCSに集中したと伺っています。どのような判断だったのでしょうか。

当時は全社で10名弱でした。営業・マーケティングを止めれば、新しい契約が入ってこなくなるので、資金が尽きるタイミングは早まります。

だからこそ、その間にお客様が使い続けられる状態を作らなければなりませんでした。それができれば、営業・マーケティングを再開することで成長できる。そこまで持っていけるかが、大きなリスクでした。

ただ、そのまま続けても、資金はいずれ尽きてしまう。難しい意思決定ではありました。

──　V字回復を通じて、どのような学びがありましたか。

振り返ると、CSにきちんと取り組めていなかったことが原因でした。そこに向き合ったことで、状況が変わったんです。

学んだのは、ボトルネックを見定めて、そこにリソースを集中させたほうがよい局面があるということです。

いろいろな仕事があると、どれも大事だから全部やろうと考えがちです。でも、その時点で本当に重要なのは一つだけ、という場合があります。そのときに、やらないことを明確に決め、手放せるかどうかが大事なんです。

頭で理解していることと、実際に行動できることには、大きな違いがあります。今も、取り組むことが増えすぎていると感じたときには、当時の経験を思い出して、集中する対象を見直しています。

CTOの役割を変え、再び新規事業の開発へ

──　事業の成長に伴い、水上さんの役割はどう変わりましたか。

成長し始めた頃から、自分でプログラムを書いている場合ではなくなり、採用やマネジメントに集中していた時期がありました。

実装を任せること自体は、すぐにできました。優秀なメンバーがいて、任せれば進めてもらえる状態だったからです。難しかったのは、プロダクトマネジメントの移譲でした。私の頭の中にある方向性も共有する必要があり、PdMを採用してから約1年間は、かなり密に伴走しました。

その後、開発組織が30人を超え、ミドルマネージャーも育ってきた頃に、会社全体のボトルネックが新規事業の立ち上げに移っていきました。

リソースの配分などを工夫しましたが、ゼロイチには、既存の事業を1から100へ伸ばす開発とは異なる力が必要だと感じました。そこで昨年、一度自分でモデルを作ろうと判断したんです。マネジメントを任せ、再びかなりコードを書くようになりました。

──　ゼロイチには、どのような力が必要なのでしょうか。

まず、エンジニアリングだけに閉じずに動く力です。私が取り組むときは、開発だけでなく、プロダクトマネジメントや営業・CSの仕事も一部担います。

役割ごとに人を置くと、情報のリレーが発生し、お客様の一次情報が途中で失われてしまいます。直接聞けば「そこがポイントなのか」と分かることも、人を介すると伝わりにくくなる。時間もかかるので、私は商談の段階から入っています。

リベート管理でも、最初はリベートが何かも知りませんでした。お客様のところへ行き、なぜその業務を行っているのか、何に困っているのかを聞き、理解していきました。

もう一つは、自分で決める力です。上流からインフラ、フロントエンドまで担うと、判断することが非常に多くなります。

私自身は普段から自分自身で判断せざるを得ない環境にいたので決めることには慣れており、特別なスキルだとは元々思ってなかったのですが、経験がない方だと決めきれないか、あるいは時間がかかりすぎてしまうことがあり、最近は重要なスキルの一つであると考えるようになりました。

──　マルチプロダクト化の共通基盤は、先に整備するのでしょうか。

必要かどうか分からないものは、先に作らないようにしています。「この基盤がないと始められない」という状況にしてしまうと、新規プロダクトのスピード感には合わなくなります。そもそも新規事業は、撤退する可能性もあります。

まずは共通基盤などに依存せず個別にプロダクトを作って、事業として成立するかを確かめることを優先する。事業が伸びてきて、プロダクトが別々になっていることがお客様にとって不便につながり、それが全体の事業上のボトルネックになってきた段階で、統合する方向に動いています。

業務の進め方まで含めて、経営管理のスタンダードを作る

──　経営管理プロダクトには、どのような特有の難しさがありますか。

一つは、業務の形式が一律に決まっていないことです。会社によって進め方が異なりますが、お客様自身も、今のやり方が正解だと思っているとは限りません。こちらから最適な業務のあり方を提案するほうがよい場合もあります。

そのため、各社に合わせてカスタマイズするだけでなく、私たちが最適だと考える業務の進め方を確立していく必要があります。最初から答えは分からないので、時間をかけて積み上げることが難しいところです。

技術的には、計算処理も難しい。Excelが重くなるのは、シート間の参照や集計など、もともとのロジックが複雑だからです。プロダクトに移しても自動的に軽くなるわけではなく、効率よく計算する工夫が必要です。

UIも、決められた項目を入力して終わるものではありません。数字を入力し、結果を見て修正し、また確認する。そうした繰り返しの検討に適した設計が求められます。ユーザーへのインタビューや個別の最適化を重ね、一つずつ改善しています。

──　御社が考える「スタンダード」には、業務の進め方も含まれるのですね。

はい。管理会計は、ツールだけで解決するものではありません。

最近、コンサルティング会社を買収したのも、プロダクトを導入する前に業務を整理したい、でもどう進めればよいか分からない、という企業に対応するためです。

まず、予実管理を何のために行うのかを明確にする。その企業のビジネスモデルでは何を重視すべきか、どこはそれほど重視しなくてよいかを考え、業務の進め方へ落とし込む。その整理の仕方自体も、スタンダードの一つだと思っています。

そのうえで、プロダクトも業務に合う形で作る。この全体を含めて、私たちはスタンダードと捉えています。

職種の壁をなくし、顧客に向き合う開発組織へ

──　現在の開発組織の体制を教えてください。

全社約150名のうち、3〜4割ほどが開発に携わっています。2025年12月から、職能ごとの体制を変更し、ミッションごとにチームを組むクロスファンクショナルな形にしています。

エンジニア、デザイナー、PdMがいますが、職種によって役割を固定してはいません。エンジニアがPdMのような仕事をしてもよいですし、その逆もあります。誰もがチームのミッションにコミットできる形です。

──　エンジニアが直接、顧客と話す機会もあるのでしょうか。

はい。既存プロダクトのエンジニアも顧客インタビューに参加し、対話から改善すべきポイントを探っています。最近のAI関連のプロジェクトでは、いわゆるFDEに近い動きも始めています。

もともと、必要なら役割を横断して取り組むメンバーが多いことは、組織の強みです。一方、経営管理の業務を理解し、コードを書くところまで一気通貫で担えるようになるには、時間がかかります。複数のお客様から話を聞き、さまざまなパターンを知る経験が必要です。

──　 採用では、どのような点を重視していますか。

基本的なコミュニケーション力に加えて、アンラーンできるかを見ています。「技術者である自分」にとらわれず、これまでの考え方をいったん手放せることが大切です。

エンジニアは専門性があるからこそ、物事をシステム的に捉えようとします。ただ、その考え方を顧客とのコミュニケーションにそのまま適用しても、うまくいくとは限りません。

別の領域に来たのだから、ゼロから知識を蓄積する。どう考え、どう整理するかを新しく組み立てる。その切り替えができるかは、大きなポイントです。

役割を広げることの重要性は、AI以前からあったと思います。AIによって、その流れが加速しました。最初から完璧でなくても、実際に挑戦し、必要なスキルを言語化して、自分のものにしていく。自分から行動できるかどうかが、大きな分かれ道になると考えています。

AIに作業を任せ、正確な計算はツールに委ねる

──　経営管理とAIの相性を、どのように考えていますか。

経営管理には、人が対応しなければならない部分が、さまざまな場所に残っています。これまで「ここは人に整理してもらい、その後をシステムで処理しましょう」と区切っていた箇所が多い分、AIが価値を出せる余地も大きいんです。

例えば、将来の支出を入力する「見込みの管理」では、その手前に稟議申請などの情報があります。これまでは人が確認して整理する必要がありましたが、AIが申請内容や請求書を読み取り、承認状況などと合わせて支出の時期や金額を把握することが考えられます。

経営報告資料も、AIに指示してデータを集め、グラフやレポートを作ってもらうことが可能になります。こうした作業が数多く点在していることが、相性のよさにつながっていると思います。

──　 正確性については、どのように対応していますか。

AIの結果が100％正確とは限らないことを踏まえて使う必要があります。一方、経営管理には、必ず正確でなければならない部分があります。代表的なのが、数字の集計です。

計算そのものをAIに任せるのではなく、従来のアルゴリズムで処理するツールに任せる。AIには、自分に向いていない仕事をツールへ委ねる形で動いてもらいます。私たちも、AIとツールを組み合わせる構造で実装しています。

──　FP&Aエージェント®︎(DiggleのAIエージェント※¹)では、どのような姿を目指していますか。

究極的には、FP&Aの業務の大部分をAIに任せられるようにしたいと考えています。

ただ、人が一切関わらなくなるわけではありません。AIの判断を確認したり、「ここはこうしてほしい」と指示したりする役割は残るはずです。その会社ならではの事情や背景も、人が伝える必要があります。

人はアウトプットだけ見てコントロールし、作業部分はFP&Aエージェントに任せれば全体の仕事が完了する状態を目指しています。

※「FP&Aエージェント®」はディグル株式会社の登録商標

顧客価値から考え、経営に貢献するプロダクトを作る

──　今後の事業や組織について、どのように考えていますか。

引き続き、ARRを2倍程度に伸ばす成長を続けたいと考えています。そのためには、営業だけでなく、プロダクトサイドも何をすべきかを考えなければなりません。

もともとは従業員数100〜1,000人ほどの企業に強みがありましたが、今は3,000人、5,000人規模の企業も増えています。規模が大きくなるほど、期待される水準や課題の性質も変わります。その期待に応えられなければ、受注できなかったり、解約につながったりします。

プロダクトだけでなく、コンサルティングも含めて提供価値を広げる必要があります。まず、顧客にどのような価値を届けるかを考え、そのために必要なプロダクトや組織を分解していく。

実現方法は、新規事業かもしれませんし、既存プロダクトへの機能追加かもしれません。「この価値を作るために何が必要か」から考えられる組織にしていきたいと思っています。

──　水上さんが感じる、この事業の面白さは何でしょうか。

企業の経営に直接貢献できることです。加えて、まだスタンダードが確立されていない領域で、そのスタンダードを作れる立場にあることも魅力です。

管理会計では、長くExcelで十分だという考え方が残っていましたが、最近はツールで管理したほうがよいという認識が広がり始めています。いずれツールを使うことが当たり前になる。その大きな流れの中にいることに、面白さを感じています。

──　最後に、Diggleで働くことは、エンジニアのキャリアにどのような経験をもたらすと思いますか。

エンジニアという枠に収まらなくなるかもしれません。コンサルティングの知識に触れたり、ハイタッチなCSと連携したりしながら、お客様にどのような価値を提供するプロダクトを作るべきか、考えられるようになると思います。

技術的には、データを深く理解する経験が得られます。その企業がどのようなビジネスモデルで、どう事業を進めているから、この情報が重要なのか。そこを理解したうえで、データから何が分かり、どのような形で持つべきかまで考えます。

経営上の目的にひもづけて、必要なデータやその持ち方を設計に落とし込む。そうした経験を得られることが、Diggleで働く魅力の一つだと思います。