【ITニュース解説】Building Domain Expertise: How Our Developers Became Camping Experts

システムエンジニアを目指す上で、技術的なスキルはもちろん重要だが、それと同じくらい、あるいはそれ以上に大切なのが「ドメイン知識」である。ドメイン知識とは、ソフトウェアを開発する対象となる特定の業界や業務に関する深い理解を指す。このニュース記事は、キャンプ場の予約管理システム「Camprs」の開発を例に、なぜ開発者がドメイン知識を持つことが不可欠なのか、そしてそれをどのように習得したのかを詳細に解説している。

ある時、システムのデータベース設計を進める中で、リードバックエンド開発者のアレックスは、「なぜ3種類の異なるサイトタイプが必要なのか。1つの『キャンプサイト』テーブルに属性を追加するだけではだめなのか」と疑問を呈した。彼にとって、キャンプサイトはすべて同じように見えたからだ。しかし、RVサイト、テント専用サイト、キャビンレンタルといった種類には、料金体系、顧客の期待、運用上の要件など、技術仕様だけでは語れない本質的な違いがあった。その数カ月後、アレックスが実際にキャンプ場で繁忙期に2週間働いた後、彼はコードの該当箇所をすべて書き直した。現場での経験を通じて、これらの違いが単なる技術的なものではなく、ビジネスの根本を形作るものであると理解したのだ。

このように、単にコードを書くだけの開発者から、対象となる業務を深く理解する開発者へと変革することは、あらゆる業界で価値あるソフトウェアを構築する上で極めて重要となる。特に、アウトドアレクリエーションのような専門的でニュアンスの多い分野では、その重要性が際立つ。

多くのソフトウェア開発者は、キャンプ場を運営したり、アドベンチャーツーリズム事業を管理したりした経験がないため、開発対象となるドメインを理解していないという根本的な課題に直面する。従来の開発アプローチでは、プロダクトマネージャーやドメインエキスパートがこの知識ギャップを埋める役割を担い、開発者はコードに集中し、ビジネスロジックや要件を技術仕様に変換してもらう形をとることが多かった。しかし、この方法は単純な問題には機能するものの、データ構造、ワークフロー設計、インターフェースの選択など、数十もの細かい決定が業務の実際の運営方法に対する深い理解を必要とする複雑なドメイン特化型ソフトウェアを構築する際には、機能不全に陥る。

なぜなら、どれほど詳細な仕様書を作成しても、キャンプ場運営者が持つ「暗黙知」を完全に伝えることはできないからだ。彼らは天候によって予約パターンがどう変化するか、サイトの割り当てが運営効率にどう影響するか、特定のアクティビティの組み合わせがなぜ一緒に予約できないのかなどを直感的に理解している。この知識は言葉にするのが難しく、実際に業務を経験して初めて明らかになることが多い。

さらに、非技術系のドメインエキスパートとドメイン知識を持たない開発者がコミュニケーションを取る際、情報は失われやすい。運営者が問題を彼らの言葉で説明し、プロダクトマネージャーがそれを要件に翻訳し、開発者がその要件を解釈して実装する。この過程で、最終的に完成した機能が、運営者が本当に抱えていた問題とは異なる問題を解決しているという事態が発生する。開発者がドメインを理解していない場合、機能の開発サイクルは高価になる。仕様書に基づいて機能を作り、ユーザーに見せ、ニーズと合致しないことが判明し、再設計、再構築を繰り返す。各サイクルに数週間から数カ月かかり、手戻りのコストが膨大になるのだ。

そこで「Camprs」チームは異なるアプローチを採用した。開発者自身がキャンプのドメインエキスパートになることを決めたのである。彼らは、新入社員のすべての開発者に、入社後6カ月以内に少なくとも2日間、提携するキャンプ場で実際に働くことを義務付けた。これは単なる見学ではなく、実際にゲストのチェックイン、問い合わせ対応、予約処理、繁忙期の混乱への対処など、実際の業務を経験するというものだった。開発者は早朝勤務や多忙な週末を含む実際のシフトに入り、長いチェックインの列のプレッシャー、ゲストの到着時間管理の複雑さ、タスクを完了するのを妨げる絶え間ない割り込みなどを体験した。この経験は即座に、そして本能的な学びをもたらした。開発者たちは、この現場での勤務から、多くの気づきや、既存のソフトウェアに対する不満、そしてオフィスでは決して思いつかなかった改善アイデアを持って戻ってきた。

例えば、あるフロントエンド開発者のサラは、現場での経験を通じて、インターフェース設計へのアプローチを大きく変える知見を得た。一つは「電話による中断の現実」である。キャンプ場のスタッフは常に電話などで中断されており、複数の画面を行き来してコンテキストを維持するようなワークフローは、数分おきに中断されるため実質的に使えないと判明した。この洞察により、チェックインプロセスは中断されても進捗が失われないよう、小さく完結する部分に分解して再設計された。二つ目は「空間的な思考パターン」である。経験豊富なスタッフは、サイト番号ではなく「大きな樫の木の近くのサイト」や「遊び場の近くのRVスポット」のように、キャンプ場を空間的に捉えて考えていることに気づいた。この観察から、視覚的なサイトマップが補完的な機能ではなく、主要なインターフェースとなり、ユーザーがシステムと対話する方法が根本的に変化した。三つ目は「天候への依存」である。キャンプ場スタッフが行うほぼすべての運営上の決定は天候に左右される。このことから、天候情報をシステム全体に組み込むことが必須であると認識した。

このような没入型のアプローチは、単なる知識だけでなく、「共感」を生み出す。予約が失われた顧客の不満に直接対応したり、実際に利用可能なサイトを把握するのに苦労したりする経験を積むことで、開発者はソフトウェアの作り方を変える。ユーザーが置かれた状況を理解することで、エッジケース（例外的な状況）により注意を払い、エラーメッセージの分かりやすさにより配慮し、現場で本当に重要な機能に優先順位をつけられるようになるのだ。

この初期の没入体験にとどまらず、開発プロセス全体にドメイン学習を組み込む努力も継続している。具体的には、キャンプ場運営者からなる「顧客諮問委員会」を設け、開発チームが直接、作成途中の機能についてフィードバックを得る機会を設けている。また、すべての開発者は四半期ごとに1週間、カスタマーサポート業務に従事し、顧客からの問い合わせやトラブルシューティングを通じて、どの機能が分かりにくいか、どのワークフローが実際の業務と合わないか、どの問題が頻繁に発生するかを直接学ぶ。さらに、主要な機能を構築する前には、開発者がキャンプ場に出向いて、解決しようとしている問題の原因を観察し、検証する。これにより、機能要望の裏にある真のニーズを把握し、より良い解決策を導き出す。業界のカンファレンスや展示会への参加も奨励し、規制の変更、競合状況、経済情勢、顧客の期待の変化など、顧客が事業を運営する上での広範なビジネス環境を理解するよう努めている。

ドメイン知識は、単に適切な機能を構築するだけでなく、ソフトウェアの技術的な品質も根本的に向上させる。例えば、キャンプ場の運営を理解している開発者は、外部からは明らかでない関係性や制約を理解しているため、より優れたデータベーススキーマ（データベースの構造）を設計できる。キャンプ場によってサイトの割り当て方が異なることなどを理解していれば、システムが硬直せず、様々な運営モデルに対応できるようになる。また、季節ごとのトラフィックパターンを理解していればキャッシュ戦略に影響を与え、キャンプ場がインターネット接続の悪い場所にあることが多いと知っていれば、どの操作をクラウドベースにするか、ローカルベースにするかといったアーキテクチャ上の賢明な決定を下すことができる。

テストにおいても、ドメインを理解している開発者は、どのエッジケースが重要かを把握しているため、より良いテストを書ける。顧客が頻繁に到着日を変更したり、複数のサイトにまたがる滞在を許可したり、天候によってキャンセルや再予約が連鎖的に発生したりするような、稀だが重要なシナリオを予測し、テストに組み込むことができるのだ。API設計においても、ドメインを深く理解している開発者は、抽象的な技術構造を押し付けるのではなく、ドメインの実際の動作に合致するAPIを設計できる。これにより、APIがキャンプの業務を理解している人にとってより直感的になり、重要なワークフローを確実にサポートする。

しかし、開発者をドメインエキスパートにする取り組みには課題も伴う。まず、開発者がキャンプ場で数日間働くことは、コーディングから離れる時間を意味し、顧客サポート業務も機能開発の時間を奪うため、短期的な開発速度は遅くなる。しかし、この投資は、正しいものをより良く構築することにつながり、長期的にはより価値のあるものだと信じられている。次に、すべての開発者がキャンプ場で働くことを望むわけではないため、採用対象が狭まる可能性がある。顧客と直接対話することや、典型的なソフトウェア開発の枠を超えた経験に好奇心を持つ開発者を探す必要が生じる。チームが拡大するにつれて、一貫したドメイン知識を維持することも難しくなるが、ドキュメント化、顧客セッションの記録、詳細なケーススタディなどを活用し、直接経験を補完する努力が続けられている。さらに、キャンプ運営に集中しすぎるあまり、より広範なソフトウェアエンジニアリングの原則や新しい技術から疎遠になるリスクもあるが、開発者が幅広い技術コミュニティとのつながりを保つよう奨励することでバランスを取っている。

このようなドメイン知識構築の取り組みは、予期せぬメリットも生み出している。開発者が顧客と直接話すことで、顧客は開発チームが自社のビジネスを理解していると感じ、信頼関係が構築され、より生産的な議論につながる。また、顧客がバグや混乱する挙動を報告した際、ドメイン知識を持つ開発者は問題が発生した状況を理解しているため、根本原因をより迅速に診断できる。チーム全体が共通の製品ビジョンを持つことで、優先順位付けや意思決定が容易になり、内部での議論が減り、より迅速に行動できるようになる。

この経験は、他の技術チームにも普遍的な教訓を与えている。ドメイン知識はプロダクトマネージャーやカスタマーサクセスチームに完全に外注できるものではない。開発者は日々の業務で何十もの決定を下しており、これらの決定にはドメイン知識が不可欠である。仕様書や要件定義書だけでは、ソフトウェアがサポートする業務の一次体験には及ばない。教師向けのツールを開発するなら実際に教える時間を、医療向けのツールなら臨床現場で過ごす時間を設けるべきだ。ドメイン知識を構築するための時間投資は、短期的に見れば高価に思えるが、長期的に見ればより良い決定、少ないミス、そして強固な顧客関係を通じて大きな見返りがある。アーキテクチャ、データモデリング、インターフェース設計といった技術的決定は、しばしばドメイン上の決定の姿を変えたものであるため、ドメイン知識を持つ開発者はこれらの決定をより効果的に行える。

ドメイン知識の構築は一度きりのプロジェクトではなく、継続的なコミットメントである。業界や顧客のニーズは常に変化し、新しいチームメンバーも加わるため、常に学び続ける必要がある。しかし、キャンプ運営を深く理解することが、キャンプ場向けソフトウェアをより良く構築する上で不可欠であるという確信は変わらない。コードも重要だが、コードが何をすべきか、そしてなぜそれをすべきかを理解することの方が、より重要なのだ。

かつてサイトタイプの違いを理解できなかったアレックスは、今ではキャンプ業界のカンファレンスでテクノロジーについて講演することもある。彼は、単に自分たちが作るソフトウェアだけでなく、キャンプ場運営についても本当に知識を持つようになった。彼が顧客と話すとき、機能や技術的能力から入るのではなく、季節性ビジネスの管理の課題、多様な宿泊タイプの複雑さ、そしてキャンプ場が実際に運営される方法に合わせたソフトウェアの構築について語る。

開発者からドメインエキスパートへの変革は一晩で起こるものではない。それは意図的な投資、継続的な学習、そしてサービスを提供する業界への真の好奇心を必要とする。しかし、その結果、より良く機能するソフトウェア、より信頼してくれる顧客、そして現実の人々の現実の問題を解決することに真の誇りを感じるチームが生まれる。最高の開発者は、必ずしも最も優れた技術的経歴を持つ者ではない。彼らはキャンプ場がどのように機能するかを学ぶことに興奮し、運営上の課題について思慮深い質問をし、技術的に面白いだけでなく本当に役立つものを作りたいと願う者たちなのだ。

「Camprs」の開発を通じて学んだことは、ドメイン知識が技術的専門知識とは別個のものではなく、その不可欠な構成要素であるということだ。キャンプ運営を理解することは開発者としての能力を高め、同様にソフトウェア開発を理解することは顧客であるキャンプ場運営者の能力を高める。目標は、開発者をキャンプ場運営者に変えることでも、その逆でもない。深い技術的知識と深いドメイン知識を組み合わせ、どちらか一方だけでは構築できないものを作り出すために、相互理解を十分に構築することである。ソフトウェアが本当に価値を持つのは、技術とそれがサポートする業務の両方を理解する人々によって構築された時なのだ。