新規プロダクトの立ち上げ期には、成果の裏で、「誰も見ていないが、誰かが必ずやらねばならない仕事」が数多くあります。 今回紹介する DevTool は、新規プロダクト立ち上げの裏で有志メンバーにより実装された、数値計算結果の可視化・検証を支える社内向けフロントエンドツールです。
当初は開発効率を上げるための副次的な取り組みでしたが、いまではQAチームやステークホルダーを含めた、“数値を扱うチーム全員の共通基盤” に成長しました。
このブログでは、その0→1の過程と、チームがどのようにそれを活かしたかを紹介します。
※ツール開発が必要になった新プロダクト「eClear」についての詳細は、以下の記事をご覧ください。 techblog.enechain.com
- 背景：数値検証がボトルネックになっていた
- きっかけ：開発の合間に生まれた小さなツール
- 広がり：チームにとっての共通ツールになった
- 試行錯誤：0→1 開発のリアル
- AI Agent の導入：ただのコード生成ではなく“新しい開発体験”へ
- 成果：ツールがチーム文化を変えた
- まとめ：小さな効率化が、チーム文化を変えた
背景：数値検証がボトルネックになっていた
新eClearの中心には、複雑な数値計算を担うバックエンドがありました。 膨大な入力パラメータをもとに演算し、その出力により顧客の意思決定を支えるシステムです。
問題は「計算結果が正しいかどうか」を確かめる検証プロセスでした。
本システムにおける数式の組み合わせや条件分岐はかなり多く、単純に「入力 → 出力」の組み合わせで網羅的なテストを書くことが難しい状況でした。数値同士の相関や、グラフとしての傾向そのものを見て初めて「違和感」に気づけるケースも多く、 一般的なユニットテストだけでは検証が完結しない、という前提がありました。
そのため当初は、検証のたびに開発者がExcelに計算結果を吐き出し、その結果をグラフ化し、傾向を確認するという方法を取っていました。
しかしこの方法では、
- 修正を反映するたびに再出力・再グラフ化が必要
- 値の比較が人間の目頼み
- 検証時間が膨張し、本流の開発を止めてしまう
といった課題がありました。
当初は『一時的なので手作業で十分だろう』とエンジニアチーム内では考えていました。 エンジニアの作業は、「値を入れ、計算し、結果を確かめる」の連続です。多くのケースでは、デバッグ用にローカルで出力を確認できれば十分だと考えがちです。
しかし、プロダクトの規模が拡大するにつれ、検証そのものが開発のボトルネックとなっていきました。
「検証に時間をかけすぎて、本質の開発をより効率よく進める時間がなくなる」
—— これが当時のチームの課題でした。
きっかけ：開発の合間に生まれた小さなツール
転機は、「就業時間の合間にちょっと作ってみたツール」から訪れました。
エンジニアとして、単純作業を繰り返すのがもったいない。 それなら、ブラウザ上で結果を見られる小さなツールを作ってしまおうと考えました。
この動きは、enechainのカルチャーである 「😌 余白 。」 とも相性が良かったと感じています。
業務を効率化するためだけでなく、「一度立ち止まって、もっと楽にできないか」を考える余白を持つこと。合理性だけに寄り切らず、遊び心を持って試してみること。
結果的に、この“余白”から生まれた小さな試みが、後にチーム全体を支えるツールへと育っていきました(本ツールの開発チームは自分たちで「チーム余白」と名乗ったりもしていました)。
最初のバージョンは、ほとんど実験的なものでした。
- 入力する値が記載されたファイルを投げるフォーム
- 出力結果をダウンロードできるようにテーブル表示
- グラフ化のための簡易UI
UIは社内デザインシステムのコンポーネントを利用し、表形式の計算結果はスタイルを揃え、グラフ描画には Recharts を採用しました。
この時点では、個人の生産性を高める「開発者のためのツール」でした。
しかし、たったそれだけで“Excel→グラフ化→再確認”という往復がなくなり、検証作業にかかる時間が大幅に減少しました。 実際にデプロイ先で動くものができるまでに超短期間で辿り着けたのも良かったと考えています。
エンジニアが主導して作ったツールにより、目に見える結果として小さく高速に修正サイクルを回せるようになり、それが後々のチームのアウトプットにも影響していったと思います。
広がり：チームにとっての共通ツールになった
この小さなツールは、すぐに他の開発者にも使用されるようになりました。
「自分のロジックもこの出力フローで見てみたい」 「パラメータを変えて挙動を比較したい」
そうした声から、機能を少しずつ拡張していきました。
入力を手軽に切り替えられるようにし、比較グラフを描けるようにし、最終的にはQAチームでも利用されるようになりました。
今でも鮮明に覚えているのは、非エンジニア層にも活用が広がっていった時の感動です。 CLIやExcelに慣れていなくても、ブラウザ上で「見る」「変える」「確かめる」ができる。
これにより、数値検証が特定の開発者だけのものではなくなり、“プロダクトチーム全員で共有できる知識” になっていきました。
試行錯誤：0→1 開発のリアル
ツール開発は常にスピード感を重要視しながら進めていきました。
- 「この機能をUIで編集可能にするか」
- 「型安全を優先するか、開発速度を優先するか」
- 「eslint ruleを整備してから進めるか、とりあえず動かすか」
今振り返ると、AI Agentを利用することで、以前よりも気軽に他の開発者がコントリビュートを行えるので、eslint ruleを早い段階で整えればよかったと思います。
ただ、当時は「触って動かして確かめる」ことを最優先にしていました。
動くものを出して、ビジネスサイドも含めたチーム全員に見せることが、一番の推進力だったからです。
特に印象に残っているのは、何も参考がない中での設計判断です。当初のスタートラインが、「就業時間の合間にちょっと作ってみた」であったために、もちろん要件やデザインは存在しておらず、開発者同士の会話でよりどうするのが良いかを模索し続けていました。
また、社内に類似のツールがなかったため、小さな意思決定を積み重ねるしかありませんでした。
それは効率的でなかったかもしれませんが、逆にその過程で「チームの現場に即した正解」を見つけられたと思っています。
AI Agent の導入：ただのコード生成ではなく“新しい開発体験”へ
開発が進んでいくと、「更なる新機能を追加したい」というフェーズに突入しました。
ここで目を向けたのが AI Agent です。
よくある「AIがコードを書いてくれる」的な話ではなく、自分はそれを “開発の共通コンテキストを保つための存在” として考えていました。
たとえば：
- デザイントークンを敢えてこまめに全ての実装に反映することで、デザインシステムを利用したコンポーネント活用が当たり前になる
- 過去の実装方針や型設計の意図を既存実装を踏まえて対話的に確認する
- 既存モジュールを踏まえた設計草案を生成する
0→1で立ち上げているプロジェクトのため、参考となるコードも少なかったので、当初は読まれることをかなり意識して丁寧に自身の手で実装しました。 これにより、フロントエンド未経験メンバーでも安心して貢献できる環境が整いました。
DevToolの開発はAI Agentのサポートを受けながら加速し、 現在では10近い機能群をサポートするアプリケーションへと拡張しています。
成果：ツールがチーム文化を変えた
DevToolがもたらした最大の成果は、“可視化の文化”です。
単に検証が楽になっただけでなく、「理解して共有する」というチームの姿勢に繋がったと感じています。
- 開発者とQAチームが同じUIを見ながら議論できる
- データの異常を定量的に説明できる
- フロントエンドに不慣れなメンバーでもUI改修に参加できる
上記を踏まえ、自分自身はツールが成果物であると同時に、チームの開発土台になったと信じています。
まとめ：小さな効率化が、チーム文化を変えた
DevToolの開発は、「誰かが困っていることを自分ごととして解決する」というシンプルな動機から始まりました。
最初は小さな改善にすぎなかったものが、いまではチーム全体の開発体験だけでなく、プロダクトへの向き合い方そのものを変える存在になりました。まさに「小さな効率化は、いつか文化になる」を体現した取り組みだったと思います。
0→1の開発とは、最初から大きなビジョンを掲げることではなく、“手元の違和感を放置しないこと”なのだと思います。
enechainでは、一緒に事業を拡大していける仲間を絶賛募集中です。 herp.careers
