開発における「当たり前」の基準を高く持つ。DIGGLE開発組織のあり方
DIGGLE株式会社は、「組織の距離を縮め、企業の未来の質を上げる。」をプロダクトビジョンに、データドリブンな経営の意思決定を支援する経営管理プラットフォーム「DIGGLE」の開発・提供を行っています。
現在の累計調達額は約10億円に到達し、事業も組織も急成長しているDIGGLE。会社の根幹となるDIGGLEの開発組織では、どんなことを大事にしているのでしょうか？今回は、開発メンバー3名にインタビューし、DIGGLEの開発組織のこだわりやこれからについて話をお伺いしました。
＜メンバープロフィール＞
＜北村 大助＞
札幌のSIerやスタートアップ企業での開発経験などを経て、北海道で大きなシェアを持つ小売業のDX推進プロジェクトに携わる。その後DIGGLEに転職し、現在はDIGGLEの開発リーダーを担当。
＜三好 哲＞
新卒で独立系SIerに就職し、スタートアップの開発プロジェクトを経験。より深くスタートアップの開発に携わっていきたく、DIGGLEのエンジニアとしてジョイン。
＜筑後 之善＞
フリーランスとしてWeb開発やアプリ開発など、複数プロジェクトを経験。良いプロダクトをつくりたいという想いからDIGGLEのエンジニアとしてジョイン。
仕組みで解決する、DIGGLEの開発組織のあり方
ーーまず、みなさんのそれぞれのご経歴と、DIGGLEに入社した理由を教えてください。
北村：札幌にある独立系のSIerから、エンジニアとしてのキャリアをスタートしました。東京で3-4年ほど働き、札幌のSIerや帯広のスタートアップ企業を経て、北海道で大きなシェアを持つ小売業のDX推進プロジェクトのエンジニアとしてジョインしました。
そちらで2年ほど勤めた後にDIGGLEに入社したのですが、予実管理という新しい領域に挑戦することに対してはワクワクしていましたね。前職で、小売業での大規模な事業運営を経験し、企業の方向性をコントロールするための予算管理の大切さを学びました。経営の意思決定に直結するプロダクト開発ができるという点にも魅力を感じまた考え方の幅が広がりました。複数のやり方を知ってから、DIGGLEで再び小回りの利くスタートアップならではの取り組みをすることで、これまでのキャリアよりさらに面白さを感じています。
三好：私は情報系の大学を卒業後、中小の独立系SIerに就職し、主に大手メーカーの受託開発に携わっていました。数年前にスタートアップの開発プロジェクトにアサインされ、その事業を支援する過程で、今まで担当していた大手とは働く環境や仕事の進め方が大きく変わり、すごく新鮮でしたね。プロジェクト自体はとても面白かったのですが、顧客のシステムだったためどうしてもがっつり中に入っていくことが難しく、もどかしさを感じていました。
そこから規模の拡大を目指すスタートアップ、ベンチャーで自社サービスの開発に携わりたいという強い思いが芽生え、転職活動をスタートしました。そんな中、DIGGLEからスカウトを受け話を聞きにいったのですが、DIGGLEのプロダクト開発のフェーズが1から10をつくるタイミングでとても面白そうだと感じたんです。選考過程でお話しいただいたDIGGLEの課題も明確で、その課題に取り組み、解決していきたいと思ったことも大きいですね。
筑後：私は25歳でエンジニアになってからは、Webやアプリ系の開発に主にフリーランスとして携わってきました。もともとフリーランスとして働くことに特別なこだわりがあったわけではなく、良いプロダクトをつくりたいと思い案件に携わっていました。そんな中、今後のキャリアを考えたときに正社員も視野に入れ転職活動を始めていたときにDIGGLEと出会いました。
選考で話を聞くうちに、DIGGLEが提供する予実管理というサービス領域や、モダンな開発環境が良いなと思い、入社を決めました。DIGGLEのメンバーの人柄や、開発におけるコード意識の高さを知り、スキルアップができる環境も魅力的でしたね。
ーーみなさんサービスの面白さや、開発組織の取り組みを魅力に感じご入社されているんですね。DIGGLEの開発チームは新規機能開発だけではなく、改善にも積極的に取り組んでいるとお伺いしています。新規機能開発と改善を並行して行う、DIGGLEの20%ルールについて教えていただけますか？
北村：開発作業は単に新しい機能を作り出すことだけではなく、作業を進めていく中で「この部分を整理整頓しておくと、開発者が機能を知るのに費やす労力も減らせるし、将来の機能追加もスムーズに行えるだろう」というケースにぶつかることがあります。そこでDIGGLEでは改善が必要なものに対し、20%の時間を割いて改善作業に当てていこうという20%ルールを設定しています。
どの組織でも新しい機能を開発するためにはある程度の整理整頓が必要ですが、その改善活動を明確に経営陣とコミュニケーションを取りながら進めているDIGGLEは珍しいと思います。DIGGLEでは、持続可能なプロダクトにすることを目指しているので、プロダクトが時間とともに複雑になるのを避け、拡張性を保持することを重要視しています。そのため、開発時間の20%をメンテナンスや改善に充てるという指標を設けています。
この取り組みを明文化しているのは、経営陣がプロダクトの改善の必要性を深く理解していることが大きいですね。CTOであり、創業経営者である水上さんが細かい改善の必要性を大事にしていたからこそ、この文化は最初から会社に浸透していました。エンジニアが整理整頓の必要性を説いて考え方を理解してもらわなくても既に合意がとれているので、合意形成のための力を使わずに開発に振り向けることができますし、また改善を継続的に行うことができ、開発生産性の向上に役立っています。エンジニアにとってもやりやすい環境と言えます。
三好：DIGGLEが20%ルールを適用できているのは、2週間ごとに消化するストーリーポイントを設定するスクラム開発を採用していることも大きいですね。例えば「タスクに対し、50ポイントのタスクを消化する」などの目標を立てています。このストーリーポイントがタスク毎に細かく設定されているからこそ、わかりやすくタスクの20%を改善活動に充てられるようになっています。
DIGGLEで採用している開発手法が、ウォーターフォールだった場合、改善活動にどれだけの時間を割くかを具体的に決めるのは難しいと思います。スクラム開発を採用しているからこそ、改善に必要な時間を明確に設定し、実行に移すことができています。
高品質なプロダクトを維持するための、「当たり前」の基準の高さ
ーー明文化しているルールがあるからこそ、質の高いサービスを提供できているんですね...!DIGGLEの開発組は当たり前の基準が高いとお伺いしています。それはなぜか教えていただけますか？
北村：チームメンバーの技術に対する意識がもともと高いということもあり、新しく加わるメンバーもそのレベルに引き上げられていますね。DIGGLEのエンジニアメンバーはコードを綺麗に書くことが当然という共通認識を持ってるからこそ、コードの品質にこだわり、潔癖症なくらいコードを綺麗に保っています。
他の企業でも、エンジニアは綺麗なコードを書きたいと考えていると思います。ただ、納期のプレッシャーや新機能の開発を優先するなど、コードの綺麗さを優先することが難しい場合が多いです。DIGGLEでは良質なプロダクトを提供することを最優先としているので、コードの品質を高めるために納期を調整したり、開発する機能の量を調整するなど柔軟に対応しています。それが高品質なコードを維持し、より良いプロダクトを作り出す文化を支えていますね。
筑後：今までDIGGLEがスクラップ&ビルドを繰り返してきた経緯もあって、潔癖症なくらいコードを綺麗に書くという表現になっているかもしれません。潔癖症というキーワードがハードルが高いと思われがちなので、これから一緒に働くメンバーとよりDIGGLEらしさの出るような言葉に変えていきたいとは思っています。
ーーコードを綺麗に書く、当たり前の基準の高さによってどんな効果が生まれていますか？
北村：コードの綺麗さ、品質を保つための取り組みによってコードレビューのゴールがすごく早いですね。プルリクエストで上がってきたものに対し、レビューの内容が本質的なものに集中できるので、結果的にスピーディーに開発が進みます。
三好：あとは、新しい機能を追加するのも楽に進められますよね。綺麗なコードがあることで、新しい機能やアップデートを迅速に開発し実装できます。コードの品質が高いので、どのメンバーが新しく機能を開発しようとしても、そのコードを理解しやすい状態になっているので、開発全体のスピードを上げられています。
エンジニアメンバーが語る、開発組織の魅力とこれから
ーー転職して、改めて感じるDIGGLEの開発組織の魅力はありますか？
三好：前職では、将来的に改善したいと考えている箇所があるものの、新機能開発の優先順位が高かったので、改善活動が後回しにされることがよくありました。DIGGLEでは、20%ルールにより改善点をタスクとして具体的に設定し、しっかり改善に取り組んでいけるところが良いですね。開発と改善活動のバランスが取れているため、持続可能なサービスがつくれていると思います。
筑後：今まで多くのプロジェクトに参加してきましたが、20%ルールのような明確な基準を設けているプロジェクトはほとんどありませんでした。
サービスの品質を上げるために、どうするべきかを議論し必要なものを仕組み化していく。それはDIGGLEのカルチャーがあるからこそですね。
ーー開発組織の今後について、挑戦していきたいことや今後も取り組んでいきたいことなどを教えてください。
北村：DIGGLEはコードの清潔さを維持でき、また未知のものに肯定的なメンバーばかりだからこそ行動、挑戦しやすいという環境です。DIGGLEには「高速考動」というバリューがあるのですが、新しいことに積極的に挑戦し、結果を見てから評価するというスタンスがあるからこそ生まれているカルチャーだと思います。明確な効果が見込めることにのみ取り組むという姿勢も企業文化によっては妥当なものだと思いますが、私は机上にとどまらず実践しながら学んでいこうというDIGGLEの文化が好きなので引き続き維持していきたいですね。
ただ、現在の人数では期待される速度で成果を出すために必要な手数がまだまだ足りません。今後もDIGGLEのカルチャーを維持しながら、採用を進めてチームを拡大していきたいです。
三好：DIGGLEに入って、振り返りの機会が非常に多いと感じました。KPTや機能リリース後、その機能がどれだけ利用されているかを振り返る機会などが設けられています。開発プロセスにおいて予測と実際の開発期間の差異を振り返る時間もあります。
また、「今すぐには対応しなくても年内には解決したい」という課題に対して、年末の大掃除のような形で12月に一斉に取り組む期間もあります。20%ルールを含め、定期的に集まって何を優先して進めるかを決め、その優先順位に従って作業を進めることで、振り返りと改善のサイクルを確立しています。
この振り返りを行う文化は、DIGGLEの良いところだと思います。ただ、振り返りって意識的な努力が必要で、放っておくと実施されなくなる可能性が高いですよね。振り返りを行わなくてもプロジェクトは進むかもしれませんが、定期的に振り返りを行うことでより良い成果を出すことができるので、組織が拡大しても振り返りの機会は意識的に設けていきたいですね。
筑後：DIGGLEは心理的安全性が高いですよね。チーム内でのギスギスした雰囲気は生産性を下げ、意見が出にくくなってしまいます。
現在の開発メンバーは人が良く、意見を出しやすいのでそこは維持していきたいですね。「これを言っちゃダメ」という雰囲気がなく、オープンで肯定的なコミュニケーションが大事なので、これからもその文化を続けていきたいです。
ーーありがとうございました！
DIGGLEではメンバーを積極採用中です！
今回のカルチャーに少しでも共感いただけたら、ぜひまずはお話しさせてください。
採用ポジションは以下よりご覧ください。
この記事が気に入ったらサポートをしてみませんか？