仕様通りにつくるだけではどこか物足りない　　日々の開発で、そんなエンジニアとしてのこだわりや「より良くしたい」という想いを抱いたことはないでしょうか。技術や環境に甘んじることなく、自らの手で能動的に課題に切り込む。そのスタンスこそが仕事の枠組みや手にする裁量を切り拓いていく力になります。

ニジボックスのBIエンジニア・中根さんは、中途入社1年目でありながらAIを活用したレビュー体制の起案や主要プロダクトのデータ設計の抜本的改善など、次々と仕事の枠を広げてきました。仲間からの「ありがとう」をモチベーションに、主体的に動く中根さんの具体的なアクションと、それを後押しする組織のリアルな反応に迫ります。

細分化された組織構造の中で、自ら「仕事の前後」を理解しにいく

　　これまでの経歴とデータエンジニアリングの道へ進んだきっかけを教えてください。

大学院では脳波や筋肉の電気信号など、人間の身体から取得できる生体データを測定する研究をしていました。いわゆるWeb系のプログラミングとは少し異なり、アカデミックな研究色が強い領域だったため、就職活動の際は一般企業のシステム部門や社内SEに絞って探しました。

無事に入社できた1社目は薬局チェーンの本社です。システム部門で社内SEとして勤務する中で処方箋などの大量のデータを扱うことになったのが、現在のキャリアの原点ですね。それまではデータベースに対してどこか苦手意識があったのですが、実際に「本物のデータ」に触れた時、頭の中が一気に変わりました。生活習慣病の方々の途切れない投薬履歴や、インフルエンザの時期の薬の需要など、膨大なデータの動きを通して社会のリアルが克明に見えてくる。その面白さに衝撃を受け、データ基盤の構築や分析の領域に深くのめり込んでいきました。

　　そこからニジボックスへ転職されたのは、どのような理由があったのでしょうか。

薬局チェーンで6年ほど経験を重ね、その分野でのデータ活用に一定の手応えを得られたころ、次はもっと多様なデータの世界を見てみたいという気持ちが強くなっていきました。「他の業界や企業は、どのようにデータを扱っているのだろう」という純粋な好奇心が芽生えたんです。

小売以外の多様なデータにも挑戦してみたい。そして、扱うデータの規模や種類を大きく変えることで、自分の専門性をもう一段深めたい。そう考え、データエンジニアリングの領域でよりモダンかつ広範囲な挑戦ができるニジボックスへの転職を決めました。

　　入社後、前職の環境とのギャップを感じた部分はありましたか？

印象的だったのはチームで運用する体制が整っていて、各チームの責務や役割が明確になっている点です。さすがリクルートグループの大規模なプロダクトを支えるデータ組織だけあり、多くのメンバーが関わる中でも業務がスムーズに回るよう進め方が整理されていました。

前職は少人数で、データの抽出から連携、仕組みづくりまで一連のプロセスを自分たちで幅広く担っていました。ニジボックスでは各チームが担う責務や役割がはっきりしていることで、
何でも屋のような業務の曖昧さはありません。最初は前職との進め方の違いに新鮮さを感じましたが、自分の担当領域に集中して専門性を深められるのは大きなメリットだと感じました。

　　役割が細分化されているからこそ、意識して動いたことはありますか？

自分の担当範囲を淡々とこなすのではなく、自分の「仕事の前後」で誰がどう動いているのか、仕組み全体の理解を自ら進めにいきました。

関わる人が多く、組織が細分化されている環境において、自分の工程で作業を遅延させるようなことはあってはならないと考えたからです。前職でプロセス全体を俯瞰して進めていた経験があったからこそ、ただ指示を待つ姿勢ではなく「自分の前の工程で誰がどう動き、後ろで誰が受け取るのか」というバトンの仕組みを把握しにいくことが重要だと確信していました。ここを能動的に理解することで「どうすれば自分たちの作業を最も効率化し、次の人へ最速かつ高品質な状態でバトンパスできるか」を常に考えられるようになりました。

　　その「効率化」の意識が、具体的なアクションにつながっていったのですね。

いかにスピードを落とさず、かつデータの品質を高められるか。この両立を追求する中で、今年に入ってから本格的に導入され始めていたAIを徹底的に活用してみようと考えました。

当時、バイブコーディングなど単発での効率化を試す動きはすでに各所でありました。しかしそれでは個人がその瞬間に楽になって終わりです。そうではなく、チーム全体で「誰が使っても同じ品質のアウトプットが出せる、使い回せる仕組み」としてAIを実装できないか。そんな想いから始まった試行錯誤が、のちの「コードレビュー体制の変革」という具体的な挑戦へとつながっていくことになりました。

「AIを3人目のレビュアーに」ミスから生まれた体制変革への挑戦

　　AIを活用したレビュー体制を発案されたそうですが、きっかけは何だったのでしょうか。

開発を進める中で、レビューをすり抜けてしまう細かな見落としが起こりうる場面に直面し、「これは仕組みで防げるはずだ」と強く感じたのがきっかけです。 

当時、プログラムの正しさを保証するために実装者と先輩レビュアーの2人体制をとっていました。しかしプロダクトの規模が拡大すれば、どんなに優秀な人間がダブルチェックしたとしてもポロッとこぼれ落ちてしまう死角は生じます。この問題を防ぐには、一般的なアプローチであれば「もう一人レビュアーを増やして3人体制にする」という手段が考えられます。しかしニジボックスは全社を挙げて生産性の向上を追求している組織です。ミスが起きたから人を増やすという解決策は、組織の方向性に逆行していると感じました。そこで人間を増やす代わりに「AIを3人目のレビュアーとして配置する」というアイデアを思いつきました。

　　そのアイデアを、周囲にはどのように提案されたのですか？

「AIで効率化しましょう」と口頭やテキストで主張するだけでは、周囲を納得させることはできません。私は精神論や抽象論ではなく、動かぬ証拠となる「実物」を持っていくことにこだわりました。

具体的には自分が過去に見落としたコードに対し、自作の「AI用セルフチェックプロンプト」を走らせました。その結果、AIがどのような指摘を吐き出すのかをテストし、その出力レポートと私のセルフチェック結果をセットにしました。そして「AIにレビューをさせてみたらこのようなレポートが得られました。人間が見落としがちなテクニカルチェックにおいてこれだけ具体的に稼働します」と、経験豊富なベテランレビュアーの方に直談判したのです。相手が自分よりはるかに社歴の長い先輩であっても、具体的な成果物さえ提示できれば、物怖じすることなくプロフェッショナルとして議論ができると確信していました。

　　提案を受けた先輩やチームの反応はどうでしたか？

全く否定されることなく、その場で「まずは試験的にやってみよう」と、即座に歓迎してくれました。AIが業務を奪うといった排他的な懸念は一切なく、むしろ「お互いの強みを活かした合理的な役割分担」として前向きに評価されたのです。

実際に試行を始めてみると、理想的な分業体制ができました。「コード値の変換」といった事業の複雑な仕様や仕様書のロジックといったドメイン知識を伴うチェックは、経験豊富な人間がじっくり担当。一方で変数や関数の表記ブレ、ファイルをまたいだ記述の不整合といった機械的なチェックはAIがミリ単位で徹底的につつきます。レビュー工数が削減されることはレビュアーにとっても非常に歓迎すべき変化であり、削られた時間を使って新しい事業の要件定義や、より高精度な設計といった上流工程に注力できると喜んでくれています。

　　その取り組みは、チーム全体にどのように広がっていきましたか？

自分一人で100%完成させてから配るのではなく、ある程度形になった段階で周囲にどんどん配り、フィードバックをもらうようにしました。以前からチームリーダーに「自分だけで突き詰めて最終形を出そうとすると煮詰まってしまうから、プロトタイプができたらすぐ配ってフィードバックをもらったほうがいいよ」とアドバイスをいただいていたんです。

実際に試験運用のデータを配ると、他のメンバーからも「これ、別チームのこういう作業のチェックにも応用できそうだね」とアイデアが乗っかったり、メンバーそれぞれが持つナレッジが上書きされてテンプレートがさらにブラッシュアップされたりと、チーム全体を巻き込んだ好循環が生まれています。最近は、AIエージェントである『Cursor』の「Agent Skills」機能を活用し、チャットで一言指示を投げるだけで「事前に設定したチーム全体の開発共通ルール」をAIが自動的に参照してコードを吐き出すような、誰が指示してもアウトプットがブレない「使い回せる仕組み」の開発にも注力しています。

　　AIを導入したことで、中根さん自身の働き方や意識に変化はありましたか？

もうAIがなかった時代には戻れません（笑）。ただ、それは「手が楽になった」だけであって、むしろ努力の難易度や作業の強度は一段上がったと感じています。

以前は完成図が見えていれば、あとは設計通りに実装していく時間も一定ありました。しかしいまは単純作業はすべてAIが肩代わりしてくれます。その代わり、AIがもっともらしく出力してきたコードに対し「このケースの処理は本当にカバーできているか」という死角や曖昧な部分を徹底的につつきにいく、鋭いチェック能力と思考の深さが求められるようになりました。脳の稼働率は格段に高まっていますね。

「見ていてムズムズする」設計の危機を救った当事者意識

　　データ連携の業務からスタートし、現在はより上流のデータマート設計にも携わっているそうですね。

入社当初は既存のデータベースからデータをそのまま持ってくる連携業務がメインでしたが、現在は複数のテーブルを組み合わせ、分析しやすい形に加工するデータマートの作成に深く関わっています。

依頼元から「こういうデータマートを作ってほしい」と設計書が降りてくるのですが、その仕様をただ実装するだけでなく、「分析の切り口としてあらかじめこういう変換データもあったほうが後々データサイエンティストの方が分析するときに使い勝手が良くないですか？」といった、一歩踏み込んだ提案を自分から投げかけるようにしています。

　　なぜそこまでこだわるのでしょうか。

極めてシンプルな理由なのですが、設計を見ていて違和感があるとなんだかムズムズして直したくなってしまうんです（笑）。

あとは前職での原体験が大きいかもしれません。データ分析の専門家から「こんなデータを抽出してほしい」と依頼された際、言われた通りに出すだけでなく「分析の目的に対して、こういう軸のデータもあったほうが扱いやすいのでは？」と追加で提案したことがありました。すると依頼主から「そこまで気が回らなかった、本当に助かった」と、ものすごく感謝されたんです。その時に、相手のためにこだわり抜くことは正しい、と確信したんです。

　　ご自身の能動的な提案によって、プロジェクトが大きく好転した具体的な一件があれば教えてください。

決済ブランド『COIN+』に関するデータマートの構築プロジェクトです。 実装を具体化する中で、後工程の分析や可視化をより行いやすくできる余地に気づき、代替案を整理して提案しました。関係者と仕様をすり合わせた結果、予定の範囲内で、より扱いやすい設計に見直すことができました。