エンジニアはドメイン知識とどう向き合うべきか？

はじめに

GO株式会社次世代事業本部 GX統括部 GXシステム開発部の武田です。 GX（グリーントランスフォーメーション）事業におけるシステム開発を担当しています。

私の所属するGXシステム開発部では、タクシー事業者向けにEV（電気自動車）や充電インフラの導入を支援し、それらを活用したエネルギーマネジメントシステムの構築を行っています。

また、街中に設置した充電器の検索・予約・決済をオンラインで完結できるシステムの開発にも取り組んでいます。

部内では月に1〜2回のペースでLT（ライトニングトーク）を実施しており、本記事はその中で発表した内容の共有です。

テーマは 「エンジニアはドメイン知識とどう向き合うべきか？」 です。

詳細は以下のスライドで説明しています。

スライドは発表向けに要点を絞っているため、ここでは背景や実務での具体的な取り組みを補足します。

スライドでは「必要なときに参照できる状態が大事」とまとめていますが、ここに至るまでには遠回りがありました。

転職当初は、ドメイン知識を「とにかく覚えないといけないもの」として捉え、業界本を読み漁ったり、用語集を自作したりしていました。

ただ、実際には次のような状態になりがちでした。

転機となったのは、 「必要な知識を、必要になったタイミングで調べる」 スタイルに切り替えたことです。

実装の手が止まりにくくなり、調べた知識も実コードと紐づくため、自然と定着していきました。

全部を頭に入れておくことよりも、 「必要なときに、どこを見れば正解がわかるか（参照可能な状態）」 にしておくことの方が、実務では重要だと感じています。

スライドで触れた「用語の統一」は、個人的にはかなり実感のあるテーマです。過去に、用語の定義を曖昧にしたまま実装を進めてしまったことがありました。

そのときは一見すると大きな問題には見えなかったのですが、後になって次のような形で問題が表面化しました。

修正コストは想像以上に大きく、設計の根本まで戻って手を入れる必要が出てきました。この経験以降、以下を強く意識するようになりました。

いわゆるユビキタス言語ですが、一度ずれた言葉を後から揃え直すのは本当に大変です。あとからプロジェクトに参画する場合でも、まずはここを最優先で把握するのがよいと思っています。

どう作っても「とりあえず動くもの」は作れます。特に参画初期は、スピードを優先してこのように業務にあたることが多いかと思います。

ただ、 業務の実態からずれたコードは、じわじわと問題を引き起こします。

たとえば、業務上は明確に区別されている概念を、実装上は同じデータとして扱ってしまうケースがあります。

その時点では動いているように見えても、例外ケースでバグが生まれやすく、仕様変更が入ったときに「どこを直せばいいのか」が追いきれなくなります。結果として、通常よりも多くの手戻りが発生し、品質も下がることになります。

業務への理解が浅いままコードを書くことのコストは、実装中よりも「後になってから」のほうが大きく現れます。

それを何度か経験してから、 「動くかどうか」だけでなく「業務の実態に合っているかどうか」 を設計の重要な基準に加えるようになりました。

スライドでは「境界を引く」という話をしましたが、最初からこの考えを持っていたわけではありません。当初は、開発に関わる以上「全体を完璧に理解していなければいけない」という強迫観念に近いものがありました。

ただ実際には、関係する領域は非常に広く、短期間ですべてを同じ深さで理解するのは現実的ではありませんでした。

そこで、現在は次のように割り切るようにしています。

このように境界を引くようになってからは、設計判断に迷う時間が減り、自分が責任を持って考えるべき範囲も明確になりました。

変更要求に対しても、「どこまでが自分の責務で、どこから先は別の文脈として扱うべきか」を整理しやすくなったと感じています。

ドメイン知識は難解で、向き合い方に唯一の正解があるわけではありません。しかし、自分の経験を振り返ると、以下の4点を意識するだけでも、当時感じていた苦しさはずいぶん和らいだはずです。

同じようにドメインの広さや複雑さに悩んでいる方にとって、本記事が何かしらのヒントになれば幸いです。