専門用語が多い業界の発注で、事前に用語集を渡すべき理由

看護師、税理士、栄養士など、専門職の経験を活かしたツールを開発する場合、業界特有の専門用語が、開発会社とのコミュニケーションの壁になることがあります。この記事では、専門用語が多い業界の発注で、事前に用語集を渡すべき理由を解説します。

この記事で分かること

用語集を事前に渡すことは、単なる資料の準備にとどまらず、開発全体の質を高める効果があります。この記事では、用語集を渡すべき理由と、その作り方を紹介します。

結論を先に示すと、押さえておきたいポイントは次の3つです。

• 口頭説明の聞き漏らし・忘れを防げる
• 開発チーム全体（担当者以外にも）に、正確な知識が共有される
• 後から仕様を確認する際の、参照資料になる

理由1：口頭説明の聞き漏らし・忘れを防げる

打ち合わせの場で専門用語を説明しても、開発会社側の担当者が、その場ではメモを取っていても、後で正確に思い出せないことがあります。用語集という形で、書面に残しておくことで、聞き漏らしや、記憶の曖昧さによる誤解を防げます。

用語集があることで、開発が進む中で、担当者が「これはどういう意味だったか」と確認したいときに、いつでも参照できるという利点もあります。

たとえば、栄養士が「栄養指導」に関する記録アプリの開発を発注する場面を考えてみましょう。打ち合わせの中で「食事摂取基準」「エネルギー産生栄養素バランス」「特定保健指導」といった用語が次々に出てくると、開発会社の担当者はその場でメモを取りつつも、意味を完全には把握できないまま話を進めてしまうことがあります。後日、担当者がエンジニアに要件を伝える段階になって、「エネルギー産生栄養素バランスって、具体的に何を指すのか分からない」と質問が飛んでくることも珍しくありません。このとき、用語集がすでに手元にあれば、担当者はその場で確認でき、発注者に再度質問する手間も、回答を待つ時間も省けます。

口頭説明だけに頼った場合、特に起こりやすいのが「言葉は聞いたが、意味を自己流に解釈してしまう」というパターンです。専門用語は、似たような言葉でも意味が微妙に異なることが多く、開発会社側が一般的な国語辞典的な理解で解釈してしまうと、発注者が意図した意味とズレたまま開発が進んでしまうことがあります。このズレは、打ち合わせの直後には発覚しないことが多く、実装がある程度進んだ段階で初めて「思っていたものと違う」という形で表面化しがちです。修正のタイミングが遅れるほど、手直しの範囲は広がり、スケジュールへの影響も大きくなります。

もう一つ見落とされがちなのが、打ち合わせの「時間的な制約」の問題です。初回相談や要件定義の打ち合わせは、多くの場合1〜2時間程度に収まるよう設定されます。この限られた時間の中で、業務の全体像を説明しながら、同時に個々の専門用語の意味まで丁寧に解説しようとすると、時間がいくらあっても足りません。結果として、発注者は用語の意味を早口で説明してしまい、開発会社側も「なんとなく理解した気になる」程度の消化不良のまま、打ち合わせが終わってしまうことがあります。用語集を事前に渡しておけば、打ち合わせの時間を、用語の説明ではなく、業務フローや要件の擦り合わせといった、より重要な議論に充てることができます。

さらに、口頭説明には「発注者の言い回しのブレ」という問題もあります。同じ用語であっても、発注者が打ち合わせの中で毎回微妙に異なる言い方で説明してしまうことは、決して珍しくありません。たとえば、ある打ち合わせでは「特定保健指導」を「保健指導」と略して話し、別の打ち合わせでは正式名称で話す、といったブレが生じることがあります。開発会社側は、これらが同じものを指しているのか、別の概念なのか、判断に迷ってしまうことがあります。用語集で正式名称と、よく使われる略称・言い換え表現をあわせて明記しておけば、こうした表記のブレによる誤解も防げます。

理由2：開発チーム全体に、正確な知識が共有される

開発プロジェクトには、打ち合わせに参加する担当者だけでなく、実際にコードを書くエンジニアや、デザインを担当するデザイナーなど、複数の人が関わることが一般的です。口頭での説明は、打ち合わせに参加した担当者にしか伝わりませんが、用語集という書面があれば、チーム全体に、正確な知識を共有しやすくなります。

専門知識の理解が、担当者間でばらついてしまうと、成果物にも一貫性のなさが生じることがあるため、用語集による知識の共有は、この問題を防ぐ効果があります。

具体的には、次のような場面で、用語集の有無が成果物の質に直結します。

• 画面設計を担当するデザイナーが、専門用語を含む項目名を扱う場面：用語の意味を正確に理解していないと、画面上の表示順序や、グルーピングの仕方を誤ってしまうことがあります。たとえば、税理士向けの帳簿ツールで「仮受消費税」と「仮払消費税」を単に見た目が似ている項目として並べてしまうと、実際の業務フローとかみ合わない画面になりかねません。
• 後から参加したエンジニアが、既存のコードを引き継ぐ場面：プロジェクトの途中でメンバーが交代したり、増員されたりすることは珍しくありません。このとき、打ち合わせに参加していなかった新しいメンバーは、口頭で説明された内容を知る手段がありません。用語集があれば、新規参加者もこれを読むことで、業務知識のキャッチアップにかかる時間を短縮できます。
• テスト担当者が、動作確認の基準を判断する場面：専門用語の意味を正しく理解していないと、「これは正しい挙動なのか、バグなのか」を判断できず、テストの精度が落ちてしまいます。

このように、用語集は打ち合わせに出席した担当者だけの理解を助けるものではなく、プロジェクトに関わる全員が同じ前提に立つための、共通のインフラのような役割を果たします。

特に、開発規模がある程度大きくなり、複数のエンジニアが分担して機能を実装するような体制になると、この「共通の前提」の重要性はさらに増します。エンジニアAが担当する機能と、エンジニアBが担当する機能が、同じ専門用語を扱っているにもかかわらず、それぞれが独自の理解で実装を進めてしまうと、機能間で用語の扱いに矛盾が生じ、後になって整合性を取るための修正作業が発生してしまいます。用語集という一つの拠り所があることで、担当者が違っても、同じ定義に基づいて実装を進められるようになります。

また、開発会社によっては、要件定義や設計のフェーズと、実際の実装フェーズを、異なるメンバーが担当する体制を取っていることもあります。要件定義を担当したディレクターが専門用語を理解していても、その理解が仕様書に落とし込まれる際に、細部の情報が失われてしまうことがあります。仕様書だけを読んだエンジニアが、用語の背景にある業務上の意味まで正確に理解できるとは限りません。こうした「フェーズ間の情報の欠落」を防ぐ意味でも、用語集を関係者全員がいつでも参照できる場所（プロジェクト管理ツールや、共有ドライブなど）に置いておくことが有効です。

理由3：後から仕様を確認する際の、参照資料になる

開発が進む中で、「この機能は、どういう業務ルールに基づいて作られていたか」を、後から確認したくなることがあります。用語集があれば、この確認作業がスムーズに行えます。

また、将来的に別の開発会社に運用を引き継ぐ場合にも、用語集は、業務知識を正確に引き継ぐための重要な資料になります。

個人・複業でサービスを立ち上げる場合、最初に発注した開発会社と、長期的に付き合い続けるとは限りません。担当者の異動や、開発会社自体の契約終了、あるいは費用面での見直しなどの理由で、運用を別の会社に引き継ぐ場面は十分に想定されます。このとき、業務知識が発注者の頭の中にしかない状態だと、引き継ぎ先の開発会社は、ゼロから業務知識を聞き取り直す必要があり、余計な時間とコストがかかってしまいます。用語集という形で業務知識が文書化されていれば、引き継ぎ先はまず用語集を読むことで、最低限の前提知識を得た上で打ち合わせに入ることができます。

また、発注者自身にとっても、用語集は「なぜこの機能をこう作ったのか」を思い出すための手がかりになります。開発から時間が経つと、発注者自身も、当時どういう業務ルールを前提に要件を伝えたかを忘れてしまうことがあります。用語集を見返すことで、「そうだ、この用語はこういう意味だったから、この機能はこう動くようにお願いしたのだ」と、経緯を思い出しやすくなります。

個人・複業でサービスを立ち上げる場合、開発を発注してから実際にサービスが本格的に稼働するまでに、数ヶ月から1年以上のブランクが空くことも珍しくありません。本業と並行して進める場合、開発会社とのやり取りは、まとまった時間を確保できるタイミングに限られ、打ち合わせの間隔が空いてしまうこともあります。このような状況では、前回の打ち合わせで何を話したかを忘れてしまうことも起こりえます。用語集という形で記録が残っていれば、久しぶりに開発会社と話す際にも、用語集を読み返すだけで、当時の議論の前提をスムーズに思い出せます。これは、発注者自身の負担を減らすという意味でも、見落とされがちな効果です。

なお、用語集を渡した後の打ち合わせそのものの進め方にも工夫の余地があります。開発会社とのコミュニケーション全般でつまずきやすいポイントについては、ヒアリングでつまずかないコツでも詳しく取り上げられているので、あわせて参考にするとよいでしょう。

用語集の作り方：基本的な構成

用語集には、次のような項目を含めることをおすすめします。

• 用語（専門用語そのもの）
• 意味（一般の人にも分かる、簡単な説明）
• 使われる場面（その用語が、業務のどの場面で使われるか）
• 関連する用語（意味が近い、あるいは対になる用語があれば）

すべての専門用語を網羅する必要はなく、開発に直接関わる、重要な用語に絞って作成することをおすすめします。

用語集の形式は、特別なツールを使う必要はありません。表計算ソフトで一覧表を作るだけでも十分に機能します。項目を横一列に並べ、用語ごとに1行を使う形にすると、後から見返すときも、追加するときも扱いやすくなります。以下は、栄養士向けのツールを例にした、用語集のイメージです。

このように、意味だけでなく「使われる場面」を書いておくことが重要です。用語の意味だけを説明されても、開発会社側は、それがシステムのどの機能に関わるのかを結びつけて理解することが難しい場合があります。「使われる場面」を明記することで、開発会社側は、用語の意味と、実際の機能への影響を同時に理解できます。

用語集を作る際には、優先順位をつけて取り組むことも大切です。すべての用語を同じ丁寧さで書こうとすると、時間がかかりすぎてしまいます。まずは、システムの中核となる機能に直接関わる用語（先の例であれば「特定保健指導」や「食事摂取基準」など）を最優先で整理し、次に、それに付随する周辺の用語を補っていくという順序で進めると、効率よく作業できます。また、専門用語の中には、業界内でも意見が分かれるような、定義が曖昧な言葉が含まれることもあります。そうした用語については、「このシステムでは、この用語をこの意味で扱う」という、プロジェクト内での定義を明記しておくと、開発会社側との解釈のズレを防げます。

用語集を渡すタイミング

用語集は、開発会社に相談する初期の段階で渡すことをおすすめします。要件定義の工程が始まる前に渡しておくことで、開発会社側が、早い段階から正確な知識をもとに、要件を整理できます。

開発が進む中で、新たに説明が必要になった用語が出てきた場合は、その都度、用語集を更新していくことをおすすめします。

初回相談の場に用語集を持参する、あるいは事前にメールやチャットで送付しておくと、開発会社側は打ち合わせの前に用語集を読み込んでから参加できます。これにより、打ち合わせの時間を、用語の説明だけに使うのではなく、実際の要件の深掘りに使うことができ、打ち合わせ全体の効率が上がります。

一方で、「完璧な用語集を作ってから発注しよう」と考えすぎると、いつまでも発注に踏み出せなくなってしまいます。最初は主要な用語10〜20個程度の簡易的な用語集で構わず、開発会社との対話の中で、必要な用語を追加していくという姿勢で十分です。用語集は一度作ったら終わりのものではなく、プロジェクトの進行に合わせて育てていく資料だと捉えると、心理的な負担も軽くなります。

用語集を更新するタイミングとしては、次のような場面が目安になります。

• 打ち合わせの中で、開発会社側から「この言葉の意味を教えてほしい」と質問された用語が出てきたとき
• 新しい機能の追加を検討する際に、これまで扱っていなかった業務領域の用語が必要になったとき
• 開発会社が作成した仕様書やデザインの中で、用語の使い方に誤りや齟齬を見つけたとき

これらのタイミングで随時追記していくことで、用語集は開発が進むにつれて自然に充実していきます。逆に、最初から数百項目にわたる用語集を一気に作ろうとすると、作成自体が大きな負担になり、発注のスタートが遅れてしまう本末転倒な結果になりかねません。あくまで「今、必要な範囲」から始めることを意識しましょう。

用語集がない場合の、開発会社側の負担

用語集がない状態で、専門用語を口頭でのみ説明すると、開発会社側は、その都度、メモを取り、自分たちで整理し直す必要があり、負担が大きくなります。この負担が大きいと、専門知識の理解に時間がかかり、開発全体のスケジュールにも影響することがあります。

用語集を事前に用意しておくことは、発注者自身の手間を増やすように感じられるかもしれませんが、結果的に、開発全体を効率化することにつながります。

実際に起こりやすい失敗パターンを、いくつか具体的に見てみましょう。

失敗パターン1：用語の解釈が担当者ごとに割れる

打ち合わせでは発注者の説明に「なるほど」とうなずいていた担当者が、社内に戻って要件をまとめる段階で、自分なりの解釈で用語を言い換えてしまうことがあります。たとえば税理士向けのツールで「仕訳」という言葉が出てきた場合、開発会社の担当者が会計の知識に乏しいと、「仕訳＝入力フォームの1行分」のような、実務とはズレた理解で仕様書に落とし込んでしまうことがあります。この仕様書がそのままエンジニアに渡ると、実務上おかしな挙動をするシステムが出来上がってしまいます。

失敗パターン2：確認の往復が増え、スケジュールが遅延する

用語の意味が曖昧なまま開発が進むと、実装の途中で「これはどういう意味でしたか」という確認が、何度も発注者に飛んでくることになります。1件1件の確認は小さなやり取りに見えても、それが積み重なると、発注者の対応時間も、開発会社の待ち時間も増えていきます。特に、発注者が本業を抱えながら個人・複業でサービスを立ち上げている場合、確認への返信が翌日以降になってしまうことも多く、その分だけ開発のスケジュールが後ろ倒しになっていきます。

失敗パターン3：納品後に「思っていたものと違う」と気づく

最も避けたい失敗が、納品直前、あるいは納品後になってから、専門用語の解釈違いが発覚するケースです。この段階まで解釈違いに気づかないのは、開発会社側が「分かったつもり」で進めてしまい、発注者側も「伝えたつもり」で安心してしまっているためです。修正が必要な範囲が、画面のラベル程度であれば軽微ですが、業務ロジックの根幹に関わる部分だと、大規模な作り直しが必要になり、追加の費用と時間が発生してしまいます。

これらの失敗パターンに共通するのは、「専門用語の意味は、一度説明すれば伝わっているはずだ」という思い込みです。用語集という書面を用意し、開発会社側が随時参照できる状態を作っておくことが、こうした失敗を未然に防ぐ、地味ながら効果の大きい対策になります。

失敗パターン4：見積もり段階での前提のズレ

用語の解釈違いは、実装フェーズだけでなく、見積もりの段階でも問題を引き起こします。開発会社は、要件定義の内容をもとに、機能の複雑さを見積もり、工数や費用を算出します。このとき、専門用語の意味を正確に理解していないと、実際よりも簡単な機能だと誤解して見積もりを出してしまうことがあります。たとえば、税理士向けのツールで「消費税の課税区分」という用語が、実際には10種類以上の細かい区分を扱う複雑な処理を指しているにもかかわらず、開発会社側がそれを「単純な二択の設定項目」程度に理解してしまうと、見積もりの工数が大幅に不足してしまいます。

このズレは、開発が始まってから「思っていたより複雑な機能だった」という形で発覚し、追加費用の交渉や、スケジュールの見直しにつながることがあります。発注者側としても、当初の予算内で収まると思っていたプロジェクトが、途中で予算超過を迫られるのは望ましくありません。用語集を見積もりの段階で共有しておくことで、開発会社側も、専門用語が示す業務の複雑さを踏まえた、精度の高い見積もりを作成しやすくなります。

失敗パターン5：属人化した知識が担当者退職とともに失われる

もう一つ見落とされがちなリスクが、開発会社側の担当者の退職や異動です。打ち合わせの中で専門用語を丁寧に説明し、担当者がそれをよく理解してくれていたとしても、その担当者が別のプロジェクトに移ってしまったり、退職してしまったりすると、その理解は引き継がれない可能性があります。口頭で伝えた知識は、担当者個人の頭の中にしか残っていないことが多く、担当者が変われば、また同じ説明を最初からやり直す必要が出てきます。

用語集という書面があれば、担当者が変わっても、新しい担当者は用語集を読むことで、一定の前提知識を得た状態でプロジェクトに合流できます。属人化のリスクを減らすという観点からも、用語集を文書として残しておくことには大きな価値があります。

用語集を渡す際のチェックリスト

用語集を作成し、開発会社に渡す前に、次の点を確認しておくと、より効果的に活用してもらえます。

• 開発に直接関わる用語だけに絞られているか：業界の用語をすべて網羅しようとすると、量が多くなりすぎて、開発会社側が読み込む負担が増えてしまいます。今回のシステムで扱う機能に関係する用語に絞りましょう。
• 一般の人が読んでも理解できる説明になっているか：用語集を作る発注者自身が専門家であるため、無意識に専門用語で専門用語を説明してしまうことがあります。家族や友人など、業界に詳しくない人に一度読んでもらい、理解できるか確認するのも有効です。
• 「使われる場面」が具体的に書かれているか：意味の説明だけでなく、その用語がシステムのどの機能・画面と関わるのかを明記しましょう。
• 関連する用語や、対になる用語が整理されているか：似た用語同士の違いが分かるようにしておくと、開発会社側の誤解を防ぎやすくなります。
• 更新できる状態で管理されているか：表計算ソフトなど、後から追記・修正しやすい形式で管理し、開発が進むにつれて随時更新できるようにしておきましょう。
• 開発会社に、初回相談時までに共有できているか：要件定義が始まる前に渡すことで、早い段階から正確な知識をもとに要件を整理してもらえます。

専門知識の伝達における、用語集以外の工夫

用語集に加えて、具体的な業務の場面を示すことや、業務ロジックの背景を伝えることも、専門知識を正確に伝える上で重要です。これらの工夫については、専門分野の業務知識を正確に伝える工夫を扱った別記事で、詳しく解説しています。

用語集は「言葉の意味」を伝えるための資料ですが、実際の業務は、言葉の意味だけでは説明しきれない、複雑な判断や例外処理を含んでいることが多くあります。たとえば「なぜこの場合だけ特別な計算をするのか」といった業務ロジックの背景は、用語集の一項目としてまとめるよりも、具体的な業務シナリオを示しながら説明するほうが伝わりやすいことがあります。用語集と、業務シナリオの説明は、どちらか一方で十分というものではなく、両方を組み合わせることで、開発会社側の理解がより深まります。

たとえば、看護師が訪問看護の記録システムを発注する場合、「バイタルサイン」という用語の意味を用語集で説明するだけでなく、「体温が37.5度を超え、かつ呼吸数が異常値の場合は、システム上で警告を表示してほしい」といった、具体的な業務シナリオを併せて伝えることで、開発会社側は用語の意味と、実際の機能要件を一体的に理解できます。用語集は「単語カード」のような役割に留め、業務ロジックの背景や例外的なルールについては、別途、業務フローの説明資料や、ケーススタディの形で補足するとよいでしょう。両者を組み合わせることで、開発会社は専門用語の「意味」だけでなく、「なぜそのルールが必要なのか」という背景まで理解した上で、要件定義や設計に取り組めるようになります。

この記事の次に読みたい記事

用語集を渡すべき理由を理解したら、次はRFP（提案依頼書）の必要性についても確認しておきましょう。あわせて次の記事も参考にしてください。

• 専門分野の業務知識を、開発会社に正確に伝える工夫
• RFP（提案依頼書）は必要か。個人発注の現実的な進め方
• 開発会社との初回打ち合わせで、必ず聞くべきこと