「顧客に対して確かな価値を提供し続ける」CTOが語る、ミッション実現に向けた開発組織とは

DIGGLE株式会社を立ち上げた1人であるCTO水上に、DIGGLEが目指す組織像とビジョンを語っていただくインタビュー。DIGGLEのミッション、プロダクト作りへの想い、プロダクトの展望、開発組織のありたい姿を聞きました。

▼CTO水上のプロフィールがわかる記事
CTO・水上駿が語るサービスの歴史とこだわり

Dig the Potential　━テクノロジーで、企業の成長可能性を掘り起こす。

ー最近DIGGLEのコーポレートミッションを定義したとお聞きしました。どのようなミッションか教えてください。

DIGGLEはコーポレートミッションとして「Dig the Potential テクノロジーで、企業の成長可能性を掘り起こす。」を掲げています。すべての企業には、まだ見ぬ成長可能性が広がっています。テクノロジーの力でその一つひとつを掘り起こし、企業のありたい姿の実現を支援することで、産業と社会の在り方を革新していきたい。それが、DIGGLEが会社として未来を目指す上での使命であり、存在意義です。

PMF（プロダクトマーケットフィット）が見えてシリーズAも調達し、会社組織の規模も大きくなる中で、会社としてどこに向かっているのかを、経営陣と現メンバーの思いを元に考え、言語化したコーポレートミッションです。

ビジネス全体のサイクルを理解した上で確かな価値を提供する

ーミッション実現に向けて、開発組織はどのような考えで開発していますか？

大前提として、どの会社も共通だと思いますが、高い技術力・製品開発力を持った組織を作っていきたいと考えています。一方で、開発の組織だからといって製品作り以外に目を向けないような状態は避けたいと思っています。一つのソフトウェア企業として、きちんとお客さまに価値を提供できるものを作り、その結果として対価を得るのがビジネスです。価値があると自分たちが思うものを作って出して終わりではなく、お客様に実際に価値を届け、対価を得るところまで意識しなければなりません。あくまで考え方ですので、「エンジニアが営業もするべき」みたいな話ではなく、こうしたビジネス全体のサイクルを理解し、それがどうすればもっと良くなるかを考え、組織の中で役割を全うしていくことを大事にしています。

DIGGLEのバリュー（行動/価値基準）の1つに、「経済志向」があります。経済学用語でいう「2財の交換」を常に意識して行動することを意味しています。顧客に対して確かな価値を提供し続け、社会に適切な利益を生み出すグッドサイクルを回していける開発組織でありたいと思っています。

ー創業当初は水上さん一人での開発からスタートしたDIGGLEというサービスですが、どのような考えで開発をされてきたのでしょうか？

0→1のプロダクト作りは、ミニマムで取り組んで、それが市場やお客さまに刺さるとわかったらそれを強化していくというものでした。ただし、0→1の何もわからない状況では失敗率が高く、プロダクトを作り直すことになる可能性も高くなります。プロダクト作りの最初の壁を突破するにはトライアンドエラーの数がキーになると思っています。

トライアンドエラーの数を増やすためにできることは、まず早く作ることです。ドメインにもよるため一概にはいえませんが、私たちの場合は、最初は多少のバグがあっても構わないので、仮説検証をいち早く実現する必要がありました。そこで、記述量も少なくて済み、ライブラリやアセットが充実しているという理由で「Ruby」を選びました。

また、フロントエンドについては、流行り廃りが激しい領域なので、フレームワークによっては、後からリプレイスが必要になったり、ロックインされてしまう懸念があります。私たちのサービスは、数字をいじって分析や結果を見て、またいじるというような業務フローを想定する必要があり、フロントエンドについては他のB2Bサービスに比べると、どちらかといえばシビアな要求がありました。そこで、ある程度チューニングを想定し、かつ当時最も伸びると思われていたフレームワークとして「React」を選びました。一方で、言語としてはTypeScriptを選ぶのかどうかの議論もありましたが、プロダクト全てを0から作り直すような可能性があることを考え、スピード優先という判断からあえて選択はしませんでした。

最初は僕1人で開発を行っていたため、このような技術選定も1人で行っていましたが、現在は6人ほどのチームですので、僕がやるべきことはあくまで全体的な方向性を示すまでに留め、後戻りが難しいものを除いて、技術選定は現場で決めることが多いです。

メンバーは個々の能力が高く、チームへのフィット感も高い人たちが集まっています。個人がチームのベースになるため、まずは個人を重視しています。エンジニアはアスリートに近いものだと思っています。サッカーのように能力の高い人たちが集まって協調して動くことで優秀なチームができるように、全体を指揮する監督は必要ですが、個々が自律して動けることが大切です。

複雑なデータをよりシンプルに早く。インプット・アウトプットの両面から追求

ープロダクト作りで重視しているポイントはなんでしょうか？

DIGGLEでは、さまざまなデータを扱いますし、その量が非常に多い場合もあります。というのも、DIGGLEのドメインである管理会計、予実（予算・実績）管理は意思決定が目的であり、そのために必要なデータを網羅していなければなりません。お客様は意思決定をする手前で、データ分析を行うので、いわゆるOLAP（Online Analytical Processing）に向いた構造でデータを保持する必要があります。こうした部分は、特に目新しい技術ではありませんが、基本として押さえておく必要があります。

これに加え、予実管理ではデータの収集が重要です。お客さまが入力する部分のデザインや使い勝手にも気を配る必要がありますし、複数のユーザが関わってきますので、組織のコラボレーションが行いやすい機能を追求する必要があります。

以上のように、インプット・アウトプットの両面から追求することを重視していますが、総合格闘技のような難しさがあります。

長期的な視点で機能開発を行い、技術力で価値を高めたい

ープロダクトの今後の展望や取り入れたい技術について教えてください。

現在、一通りの機能がそろい、お客さまに売って実際に使っていただいたデータも集まっており、プロダクトのベースが整ってきています。チャーンレートも1％前後と安定しており、短期的にはビジネスサイドで伸ばしていく時期です。エンジニアサイドとしては、2024年以降のさらなる成長のためのベースとなる機能を作っていきたいです。プロダクト全体で長期的な目線を持って開発していきます。

基本的には、お客さまにとっての価値を高めていくことがポイントです。価値が高まれば結果として、単価も上げていける可能性が生まれます。予実管理の市場はまだできたばかりなので、どうやってこの市場を取りに行くのかも考えていかなければなりません。私たちはまだ市場の一部しか取れていませんから、見えていない部分のお客さまが何を求めているのかを深掘りし、それに合わせた機能を提供できるようになる必要があります。

また市場だけでなく、技術的にも優位性を確立していくために、うちにしかない技術を作り込んでいきたいです。そして、その強みを価値強化のベースに織り込むことができればより成長できるのではないかと思います。具体的な方向性は研究途上ですが、データ面、UI面あるいはカスタマイズ性など、様々な方面から優位性を作り上げる余地があると思っています。

フルスタックに開発できる環境で、個人の強さがチームの強さに

ーCTOとして、DIGGLEの開発組織をどんな組織にしていきたいですか？

ビジネス感覚を持って、きちんと価値を作り上げられるエンジニアチームになってほしいです。それに加えて、先にお話ししたアスリート的な個々の能力の高さも大事にしたいと思います。

DIGGLEでは、フロントエンド専門チーム・バックエンド専門チームのように細かく役割分担をしないフルスタックを基本スタンスとしています。単純に両方できたほうが早いですし、少ない工数で精度の高いものを作ることができます。役割分担を細かくしすぎないことで、個々人が出せる価値を最大化しています。

ーどのような価値観やスキルを持った人と働きたいですか？

幅広く領域をまたいで手を伸ばせる環境で、エンジニアとして高い価値を発揮できる、もしくは、今後価値を発揮していきたいと考えている人と働きたいです。

また、今後メンバーが増えることで、これまでのようなスピードを出すのが難しくなる可能性があるので、何らかの形でチームを分けることも必要だと思います。その際に、組織としてのスケールを意識しながら、どういう基準でチームを分けるかといった、開発チームの在り方を一緒に考えながら開発できる方であれば理想的です。