DIGGLE株式会社でエンジニアとして開発に取り組む本田に、開発の効率化の実態とその根底にある思いを語っていただきました。数値検証の自動化がプロダクトと人にもたらした効果とは？その背景には、DIGGLEに根付く問題解決への姿勢と個人を大切にするカルチャーがありました。

ー簡単に自己紹介をお願いいたします。

本田と申します。前職はSESで3年ほど組み込みシステムの開発に携わっていました。そこで大企業のプロジェクトに参画している中で、大人数のプロジェクトの運用の難しさやSES業界ならではの辛さを感じ、他の業界に入りたいと考え転職活動を始めました。

転職先の条件として重視していたのは、小回りのきく自社開発で、ある程度エンジニアが自発的に動ける環境であることです。そしてDIGGLEと出会い、面接で話をする中で水上をはじめDIGGLEの人と組織の考え方に惹かれました。職場としても率直に「ここに入りたい」と思えたため入社を決め、現在は入社4年目で、バックエンド・フロントエンドを中心に関わっています。

チームの負債を解消する数値検証プロジェクト

ー最近、数値検証（QA）プロジェクトを実施されたとお聞きしましたが、数値検証の自動化が必要だった理由と、自動化実現による効果を教えてください。

DIGGLEのプロダクトは管理会計のためのシステムで、予算・実績など経営判断にかかわる数値を表示するレポートの正確性は非常に重要です。品質保証（QA）として損益計算書（PL）の数値が正しく算出できていることと、予実の差異を見る「差異分析レポート」が正しく出力できていることの数値検証を行います。これまでは、リリース時期になるとチーム内でQA担当を決めて、担当となった人が目で見て手で直すという方法で検証していました。

しかし、数値を人の目で検査するのはやはり大変で、担当したときにはその労力だけでなく、自分の作業にミスがなかったかという不安も感じます。また、かなりの工数がかかるため、エンジニア個人やチームへの負担も大きかったです。これをなんとか自動化できないかということで、QAの自動化プロジェクトを立ち上げました。

実際はプロジェクトというほど大層なものではなくほとんど私1人で行いました。チームとしても、テストは重要である一方で現状のままでは負荷が大きいと感じていた部分でした。それを自動化できたことは非常に良かったです。

また、数値を人の目で検査するのはやはり大変で、メンバーの心理的な負担の面でもいい影響があったと思います。メンバーに安心感を与えることができたことはとてもよかったです。

ーCIについてはどのような点を改善しましたか？

DIGGLEではCIツールが導入されており、開発者がCIツールを通じてインテグレーションを行っています。僕はそのCIツールの処理速度を改善しました。

以前、開発環境のバージョンアップが影響してバックエンドのテストにとても時間がかかるようになってしまったことがありました。それによってCIを1回処理するのに30分程度かかるようになったため、チーム全体への影響が大きいと判断し、テストがパラレル処理を行うよう改善しました。それまでは1本ずつ行っていたテストを4本並列でできるようにすることで、CIの待ち時間を7分〜10分程度に短縮できました。

このほか、Dockerイメージのサイズを減らすなど、開発者の負担が減らせるような小さな改修をときどき行っています。

「自分はチームにどのような価値を与えられるのか」を皆が当たり前のように考えている

ーどのような考えで開発の効率化に取り組んでいますか？

単純に周りが困っていることに対して役に立ちたい、助けたいという思いで取り組んでいます。QAやCIの効率化に取り組もうと思ったきっかけも、チームが困っていることが明らかで、その問題を解決できれば開発チーム全体としての効率が上がると確信できたからです。

このような問題に取り組む際、例えば大きな組織では「これを解決したい」「もっとこうできたらいいのに」と皆が思っていることでも、ボトムアップで提案しずらい場合や、目の前の仕事に手一杯で時間が割けないことがあると思います。その点でDIGGLEは問題に取り組む際の障壁が少なく、「問題があるなら解決しよう」「具体的にアクションしていこう」という意思を全員が持っていますし、「これについては工数をとって取り組みたいです」と言えば、周りもゴーサインを出してくれます。

すぐに困るような問題でなくても、長い目で見て問題ならなるべく早く解決したいと思いますし、現段階で解決が不可能なのであれば、解決するための計画を立てて段階的に取り組んでいきたいと思います。

これは僕だけでなく、チームの一人ひとりが自分がチームにどういった価値を与えられるのかを当たり前のように考えており、その考えのもと個人個人が自律して動ける環境があるため、このような問題解決の意識が組織全体に根付いています。

ー開発や社内の体制に関して、今後取り組みたいことを教えてください。

早急の課題としては、今後参画する新たなエンジニアの受け入れ体制を整えることが必要だと感じています。DIGGLEがプロダクトとして扱っている管理会計は、ほとんどのエンジニアにとって聞き慣れない言葉です。そのため、新しく入ってくる人がスムーズに管理会計を理解できるようなものや、どの程度理解できれば大丈夫なのかがわかる基準も作れるといいですね。加えて、プロダクトを使用する上での資料も整えていきたいと思います。

またプロダクトに関しては、保有しているデータをより高速で扱えるようにし、レポートの集計スピードを上げていきたいです。柔軟性の高いレポートはDIGGLEのコアな機能の一つだと考えているので、これはお客さまの満足度を高めることと、提供価値を強化することに繋がる重要なポイントだと思っています。

立場にかかわらず提案・問題提起ができるカルチャー

ーDIGGLEの人の特徴や共通する価値観があれば教えてください。

DIGGLEには真面目な人が多いと感じます。加えて、立場にかかわらず人からの提案や申し出をきちんと聞いて、よければ同意しますし、問題点があればしっかり指摘するというように人の意見を尊重し、かつより良くするための労力を惜しまない人が多いです。

エンジニアチームは、効率的かつ効果的な開発や問題解決方法、ROIを考えて実践しようという意識があるメンバーが多いです。全員がはじめからそういう思考を持っていたわけではありませんが、CTOの水上やほかのメンバーが仕事に向かう姿勢を見て真似ていくうちに、変化しているのだと思います。

そのようなカルチャーが浸透している背景には、日常的に水上や経営陣とコミュニケーションできる環境があります。一般的な会社では社長は遠い存在で、社長から直接影響を受けて成長できる機会は少ないのかもしれません。しかし、DIGGLEでは経営陣とミーティングで話し合いをする機会も多く、かなり近い存在です。

また、3ヶ月に1回の「キックオフ会」では、全社で集まって各チームや会社としての今後の方針を共有します。ディスカッションも活発に行われ、会社の今を知ることができるので、一社員としての自覚を高められる機会になっていると思います。

ーどんな価値観やスキルを持った人にDIGGLEに入ってほしいですか？

自分から動ける人に入ってほしいです。自主的に問題解決のために動けるだけでなく、そもそもここに問題があるということを自ら見つけにいける意識が大切だと思います。また、僕個人としてソフトウェア開発は常に改善の繰り返しで完璧はないと思っているので、そのような開発の実体をきちんと認識している人がいいですね。