フェーズが変わる今だからこそ、エンジニアがDIGGLEに入る面白さとは
DIGGLE株式会社は、「組織の距離を縮め、企業の未来の質を上げる。」をプロダクトビジョンに、迅速で質の高い意思決定を支援する経営管理プラットフォーム「DIGGLE」の開発・提供を行っています。
現在の累計調達額は約10億円に到達し、事業も組織も急成長しているDIGGLE。会社の根幹となるDIGGLEの開発組織では、どんな変遷をたどってきたのでしょうか？今回は、開発組織を支えるメンバー3名にインタビューし、これまでの開発組織についてやこれからについてお話をお伺いしました。
＜メンバープロフィール＞
水上 駿（共同創業者・取締役CTO）
名古屋大学大学院多元数理科学研究科修了。
動画制作スタートアップにて、動画視聴ビッグデータ解析に基づく動画プランニングツールの開発を担当。2016年DIGGLEを共同創業。11歳の時に独学でプログラミングを始め、有用なプログラミング言語やクラウド等の技術の組み合わせを見極め、スケーラブルな設計に落とし込むことを得意とする。
岡崎 正徳（エンジニアリングマネージャー）
Java、C#などサーバサイドを中心に開発業務を10年あまり経験。30歳を超えた辺りからリーダー業務に就く事が多くなり開発業務から遠ざかっていたが、エンジニアとして再度挑戦したくなりDIGGLEへ転職。現在はフルスタックエンジニアとして開発業務を行いつつマネジメント業務も担当する。
本田 大晟（プロダクトマネージャー ）
立教大学卒業後、Retty株式会社に入社し、データアナリスト、プロダクトマネージャーの業務に従事。2022年8月にDIGGLEへジョインし、PdMを担当。
PMF前から大事にしている、開発組織の軸とは
本田：現在DIGGLEの開発組織は10人弱ですが、初期の頃は2名体制でしたよね。エンジニアの採用はいつからスタートされましたか？
水上：エンジニア採用を本格的にスタートしたのは3年前くらいからですね。PMF（プロダクトマーケットフィット）が見えてきて、DIGGLEという事業がグロースし始めるのがわかってきたタイミングです。
顧客も増え、プロダクトが使われてきたので既存機能の改善や新規機能開発などが必要になりました。
岡崎：PMFするまでは少数精鋭でやっていこう、ということは水上さんが当時から言ってましたね。「船頭多くして船山に登る」という言葉がありますが、人が多ければ多いほどプロダクトの軸となる部分がぶれてしまうので、敢えて少ないメンバーで開発していました。
本田：当時の採用基準などはあったんですか？
水上：少数精鋭で開発をしていたこともあり、マネジメントできるリソースがなく手を動かせる人を求めていました。とにかく改善、新規機能開発という感じだったので、入社して自分自身でスタートダッシュが切れるかという点を大事にしていました。
岡崎：あとは少数精鋭の開発組織だったこともあり、特にカルチャーフィットを大事にしていましたね。
スキルももちろん大事ですが、少ない人数で組織をつくるとなると人柄が合うかどうかがすごく大事だと考えていまして、昔も今もなるべく多くのメンバーと会っていただくようにしています。カジュアル面談、面接、オファー会食などそれぞれメンバーを変え、いろんなメンバーと話す機会をつくっています。
本田：少数精鋭だからこそ、カルチャーフィットの部分がないと双方にとってキツくなってしまいますもんね。DIGGLEのプロダクトチームの目指す姿は当初からあったんですか？
水上：正直考えている暇はそんなになかったですね（笑）
ただ、言語化こそしていなかったものの、理想像としてはアスリート的な組織を目指したいと考えていました。個々のスキルは当然ながら高く、そういった人たちがコラボレーションしてチームでしかできないことをやる、そんな組織を目指し続けています。
その点プロダクトチームでは、当時からプロフェッショナルなスキルを持っている人が多いので、現在のDIGGLEでは限りなく理想に近い状態で開発が進められてますね。
岡崎：あとは、フロントエンド、バックエンドに特化した人というよりはフルスタックな人を採用していましたね。
やりたいことがたくさんある中で、一人が一つずつユースケースを実装すればより早く顧客に価値を届けることができます。逆に、フロントエンドまたはバックエンドしか開発できないとなるとツーマンセル以上で開発する必要があります。また、タスクの比重も、その時々でバックエンドの比重が高かったり、フロントエンド側のタスクが枯渇したりします。そういった時に、メンバーのスキルによってタスクを止めない、できるできないで開発を止めない組織がDIGGLEだと実現できています。今後もそんなチームであり続けたいですね。
本田：当時から採用のこだわりはしっかり持っていたんですね。岡崎さんは大企業での開発組織でのマネジメントも経験されていますが、DIGGLEと大企業の違いはありますか？
岡崎：大企業では、詳細設計など実装に近い部分までしっかりと作り込んだうえでタスクを渡さないといけなかったり、メンバーのタスクが終わるかのスケジュール管理をしたりと、メンバーのマネジメントをしないといけないシーンばかりでしたが、DIGGLEでは自走できるメンバーばかりです。そんなメンバーが集まっているので、誰がどのタスクを担当するかの割り当てだけすれば、あとはやらなきゃいけないことに対して自らやってくれています。
逆に、メンバーからもこれ取り組まなきゃいけないよね、ということが上がってくるのが嬉しいですね。
本田：岡崎さんがエンジニアリングマネージャーになった時、水上さんと期待値のすり合わせなどはされたのですか？
水上：どんなことを期待しているかは伝えていましたね。当時の開発組織は現場の手を動かしながら、人も動かさないといけないという状況で組織づくりも含め自分ひとりではカバーできませんでした。
初期から岡崎さんが入ってくれて、開発組織の全体最適化をしてくれたのはありがたかったです。
岡崎：DIGGLEだと優秀なメンバーが揃っているので、マネジメントという面ではタスクの入れ替えのような交通整理程度しかしてないんですよね。
要件を渡してあとはよろしくね！で進められていて、前職で求められていたマネジメントを行う必要がないので、自分自身もプロダクトに向き合い続けられています。
本田：確かにDIGGLEでは、自分たちで課題を発見し必要なことをすり合わせた上で開発を進めるメンバーばかりですよね。そんなDIGGLEのプロダクトチームの良いところを教えてください。
岡崎：みんなが受け身にならず、自分たちで課題を発見・解決してくれるのはすごく良いところだと思っています。「よしなに」力が高いと思います。
タスクを渡すとよしなにやってくれるので、良い意味で任せられます。前職ではマイクロマネジメントせざるをえない状況でしたが、マイクロマネジメントしていくと双方にとって辛いですし、DIGGLEだと最低限のマネジメントだけで回るというところが良いですね。
本田：なるほど、自走できるメンバーばかりだからこその体制ですよね。冒頭でアスリート的な組織を目指したいと水上さんが仰られてましたが、プレイヤーでもマネジメントをやれることって大事ですか？
水上：マネージャーが必要だからマネージャーを採用する！という頭でっかちな考えだと柔軟性に欠けてしまいます。DIGGLEではマネジメントコストはそもそも低かったので、薄く見ておけば大丈夫くらいの感覚でした。
そんな状況なので岡崎さんには現場をやりながら人の部分も見てもらっている今の体制はベストな状態ですね。
フェーズが変化しているからこそ、感じるDIGGLEの面白さ
本田：2名体制でスタートしたところからチームになり、フェーズとして変化は感じますか？
水上：少しずつ組織を作っていくフェーズになってきていると思います。
PMFをする前は、顧客が使ってくれている状態をつくるのが一番重要でした。一定売れる、事業を伸ばせるという状況が見えてくると、成長角度をどうしたら伸ばしていけるのかという話になってきますよね。
伸びていく角度を上げると、プロダクトの価値を大きくしていかないといけません。単発的でなく継続的に伸ばしていく必要があるので新しいプロダクトをつくっていく必要もあります。持続的に新しいものをつくるチーム体制を整えるターニングポイントが今です。そういったフェーズに挑戦していけるのは面白いと思いますね。
岡崎：水上さんの仰る通り、フェーズが変わっていくという感覚はありますね。
その上で、一番気にしないといけないことは軸をぶらさないこと。新しい風は取り入れていく必要はあるが、良いところは持続的に継続していかないといけない。そのぶらしてはいけない軸を現在水上さんと考えているところです。
アスリートの集合体であるというところは変わりません。今はアスリートとして出来上がっている人を採用していますが、今後はアスリートになれそうな人を採用して育てていくという育成フェーズが必要になってきます。成長性も含め採用が必要になってきたという意味だとフェーズが変わってきていますね。
本田：その軸をぶらさないよう、守破離会というものを開発組織では行っていますが、その会っていつから始められているんですか？
岡崎：開発メンバーが3名のときは、人数が少なかったこともありスクラムの振り返りで行っているKPTの中で、問題提起や改善についてしっかりと話す時間を確保できていたんですよね。ただ、人が増えていく中で、KPTの時間だけだと目先の問題解決しかできず、深いところまで充分に話すことができなくなってきたと感じたタイミングがありまして、守破離会の開催に至りました。
守破離会とは、自分たちで決めたルールや仕組みを実践する（「守」）ときに感じた改善点を考え実践し（「破」）、時にはルールや仕組み自体を取り止めたり新しく作る（「離」）ことをみんなで考える会になります。
何でもかんでも壊して作り直せば良いわけではないので、組織として重要なものを守った上で改善し、必要に応じて止めたり作り直したりといった動きをとっていく。今ある仕組みの中で、この部分は足りないんじゃない？これってなんで必要なんだっけ？というところを列挙して、現在のフェーズに応じて直していく取り組みを続けています。
本田：最近岡崎さんはDevチームのエンジニアリングマネージャーとして、プロダクトに関する職種全てをプロダクトチームと呼ぶようにしていますよね。それこそ「守破離」という文化があるからこそなのかなと思います。エンジニアやデザイナー、PdM全てをプロダクトチームと呼ぶことは意識的にやっているんですか？
岡崎：そうですね。組織に人が増えてくると、組織間の縦割りや対立が発生してきてしまいます。
プロダクト開発においてそんな対立は邪魔でしかないですね。プロダクトをどう良くしていくか？という話をチームでしないと本質的な話はできません。
デザイナー、エンジニア、PdMがそれぞれ大事にしているポリシーや将来的にどんなプロダクトを描いているか？今後どうしていくべきか？という共通認識は全ての職種で持つべきだと思います。という点を踏まえて、プロダクトチームを主語にしようと意識的にしていますね。
本田：それぞれが共通認識を持ち、同じ方向を向いてプロダクトを作っていくことってすごく大事ですね。今後どんな人と働きたいなどありますか？
水上：人が増える中で縦割りにしすぎないことは大事だと思う一方で、マイルドな統制は必要だと思います。そんな状況を楽しめる人と働きたいですね。
やんわりとした統制感は持ちつつ、共感性を持つだけでなく守破離という文化でそこから少しはみ出していく動きをしていきたいです。
岡崎：私は何かしらで「これは負けない」というものを持っている人と働きたいですね。
そう聞くと、フロントエンドだと誰にも負けない！であったり、インフラなら任せておけ！みたいな特定分野に特化した方を想像されるかもしれませんが、それだけではなく、全部満遍なくできるゼネラリストとして、なんでも任せろ！といった方とも働きたいですね。
何かにプライドを持っている人って成長しやすいので、DIGGLEではそんなメンバーが多く刺激を受けられると思います。
本田：今DIGGLEでは積極的に採用を進めていますが、エンジニアが今こそDIGGLEに入るメリットってありますか？
岡崎：DIGGLEはそもそもの技術レベルが高いですね。エンジニア同士が新しい状況を共有し、強制されることなくスキルアップできる文化ができているので、そこはすごく良いところです。
一点特化で何かが強いのであれば、それをメンバー全員に伝える。逆に他のメンバーから色々仕入れ、ゼネラリスト的な視点を広げてもらう。それができる環境であるので、成長や刺激を受けられる環境だと思います。
現在、契約いただいている企業様も増えてきていて、かなりパフォーマンスが求められるようになってきました。ただ、通常考えるようなインデックス設計の見直しなどの対応は既に済んでいるので、現在は根本的にプロダクトをどうしていくべきか？というところから立ち戻って考えなおしているフェーズになっています。例えば、RDBで取り扱うにはデータ量が多いので、「そもそもRDBで良いのだろうか」という点から考えたり、プロダクトの特性上、巨大な表を表示しなくてはいけないケースが存在するので、フロントエンド側の描画をどうすれば高速化できるかを検証しています。
このような「立ち戻って考えなおす」というフェーズに立ち会える機会は本当に少ないと思うので、面白く感じていただけそうですね。
水上：どれだけ技術的に良くても、プロダクトが使われていないと意味がないですよね。DIGGLEは、業務系サービスの中でも特にユーザに使い込まれるタイプのサービスなので、エンジニアとしてそこはかなりやりがいを感じてもらえるのではないかなと思います。
直接技術が顧客価値になり、事業の価値につながる。それが今のグロースフェーズであるので、さらにプロダクトのこだわりがつくれるのはかなり面白いはずです。その面白いフェーズはまさに今なので、そういった領域に挑戦したい方はぜひDIGGLEにジョインしてください！
ーーありがとうございました！
DIGGLEではメンバーを積極採用中です！
今回のカルチャーに少しでも共感いただけたら、ぜひまずはお話しさせてください。
採用ポジションは以下よりご覧ください。
DIGGLEのメンバーインタビューはこちらから。
この記事が気に入ったらサポートをしてみませんか？