看護師、税理士、栄養士など、専門職としての経験を活かしてツールを作りたいと考える人にとって、自分の専門知識を開発会社に正確に伝えることは、開発の成否を左右する重要な工程です。専門分野の知識は、当事者にとっては当たり前でも、開発会社側にとってはまったく前提のない情報であることが多く、伝え方を工夫しないと、仕様に正しく反映されないまま開発が進んでしまうことがあります。この記事では、専門分野の業務知識を、開発会社に正確に伝える工夫を解説します。
この記事で分かること
専門知識は、自分にとっては当たり前のことでも、開発会社側にとっては未知の情報であることが多く、伝え方を工夫しないと、正確に理解してもらえないことがあります。この記事では、専門知識を伝える際の具体的な工夫を紹介します。
結論を先に示すと、押さえておきたいポイントは次の3つです。
- 専門用語は、使うたびに簡単な説明を添える
- 具体的な業務の場面（ケース）を、複数示す
- 「なぜそのルールがあるのか」という背景も伝える
なぜ専門知識の伝達に工夫が必要なのか
専門職としての業務経験が長ければ長いほど、自分の中では「常識」になっている判断や手順が増えていきます。ところが、開発会社のエンジニアやディレクターは、その業界の常識を共有していません。ここに、発注者と開発会社の間の「暗黙知の差」が生まれます。
この暗黙知の差が放置されたまま要件定義が進むと、次のようなことが起こりやすくなります。
- 開発会社が「一般的なパターン」で仕様を推測し、実際の業務とずれた機能ができあがる
- 例外処理（特殊なケース）が仕様に反映されず、リリース後に「このケースでは動かない」という不具合として発覚する
- 業務ルールの意味を理解していないため、後の改修で誤った変更をしてしまう
つまり、専門知識の伝達は「説明のマナー」の話ではなく、システムの品質そのものに直結する工程です。以下では、具体的にどう伝えれば伝達の精度が上がるのかを、3つの工夫に分けて解説します。
工夫1：専門用語は、使うたびに簡単な説明を添える
専門分野で日常的に使っている用語は、開発会社側には伝わらないことが多くあります。専門用語を使う際は、「〇〇（これは、こういう意味です）」というように、簡単な説明を添える習慣をつけることをおすすめします。
例えば、医療・介護分野であれば「バイタル（体温・血圧・脈拍・呼吸などの基本的な生命状態の指標）」、税務分野であれば「みなし譲渡（実際には売買していなくても、税務上は売買があったとみなして課税する仕組み）」のように、一言添えるだけで、開発会社側の理解度が大きく変わります。
用語集を作成し、事前に開発会社に渡しておくことも、効果的な方法です。専門用語が多い業界で用語集を渡すべき理由については、別記事で詳しく解説しています。
用語の説明を添えるときの具体的なコツ
口頭での打ち合わせ中に、専門用語を使うたびにいちいち説明を挟むのは、会話の流れを止めてしまい、現実的ではないと感じる人もいるかもしれません。そういった場合は、次のような方法が有効です。
- 打ち合わせの冒頭で、その日話す予定の専門用語をまとめて簡単に紹介しておく。会話の途中で説明を止める必要がなくなります。
- 議事録やチャットで、専門用語が出てきた箇所に、後から注釈をつけて共有する。口頭では説明しきれなかった部分を、テキストで補完できます。
- 同じ用語でも、業界内で意味が微妙に異なる場合があることを伝える。例えば「顧客」という言葉が、業界によって「契約者本人」を指すのか「契約者の家族も含む」のかが違う、といったケースです。こうした細かなニュアンスのずれは、開発会社側からは質問しにくいポイントなので、発注者側から先に伝えておくと誤解を防げます。
工夫2：具体的な業務の場面（ケース）を、複数示す
抽象的な説明だけでは、開発会社側が業務の実態を正確にイメージすることが難しい場合があります。「こういう場面では、こう判断する」という具体的な業務の場面（ケース）を、できるだけ複数示すことで、業務ロジックの全体像を、より正確に伝えられます。
例えば、「通常のケースではこう対応するが、こういう例外の場合は、別の対応が必要になる」というように、通常のケースと例外のケースを、両方示すことをおすすめします。開発会社は、こうした具体的なケースをもとに、システムの条件分岐（どういう条件のとき、どう動くか）を設計していきます。
ケースを示す際に意識したい3つの型
具体的な業務の場面を示すとき、次の3つの型を意識すると、開発会社側が整理しやすくなります。
- 典型ケース：もっとも頻度が高く、業務の基本形となる場面。まずこれを共有することで、システムの土台となる処理の流れを理解してもらえます。
- 例外ケース：頻度は低いが、発生したときに対応を誤ると業務に支障が出る場面。「この条件のときだけ、通常と違う処理が必要」という形で伝えると、条件分岐として仕様に反映しやすくなります。
- 境界ケース（グレーゾーン）：典型と例外のどちらに当たるか、専門職の判断が必要になる場面。実務では「ケースバイケースで判断している」ことも多く、ここを言語化して伝えるのが最も難しい部分です。「基本的にはAで判断するが、こういう条件が重なるとBになる」というように、判断の優先順位まで含めて説明すると、開発会社側が実装方針を立てやすくなります。
失敗しやすいケース共有の落とし穴
ケースを示す際に、次のような伝え方をしてしまうと、開発会社側の理解が浅いまま進んでしまうことがあります。
- 典型ケースだけを伝えて、例外ケースを後回しにする。開発が進んだ後で「実はこういう例外もあった」と伝えると、すでに完成した機能に手を入れる必要が出てきて、修正コストが大きくなります。
- 「基本的にはこうです」という説明で終わり、頻度や重要度を伝えない。開発会社側は、頻度の低い例外ケースにどれだけ開発リソースを割くべきか判断できず、優先順位づけを誤る可能性があります。「月に1回程度しか発生しないが、対応を誤ると重大な問題になる」など、頻度と重要度をセットで伝えると、開発会社側が適切な優先順位で実装を進められます。
- 口頭だけで説明し、記録に残さない。打ち合わせの中で話したケースが議事録に残っていないと、開発が進む中で「言った・言わない」の食い違いが起きやすくなります。示したケースは、簡単な一覧表やメモの形で、開発会社側と共有しておくことをおすすめします。
工夫3：「なぜそのルールがあるのか」という背景も伝える
業務のルールを伝える際、「このルールがある理由・背景」も、あわせて伝えることをおすすめします。理由が分からないまま、ルールだけを実装してしまうと、開発会社側が、そのルールの重要性を正確に判断できず、後から仕様の見直しが必要になることがあります。
背景を理解していれば、開発会社側から、「その目的なら、こういう実装のほうが効率的かもしれません」という、より良い提案を受けられる可能性もあります。
背景を伝えることで得られる、もう一つのメリット
背景を共有しておくメリットは、開発会社からの提案の質が上がることだけではありません。開発が進む中で、当初想定していなかった状況（仕様に明記されていないケース）が出てきたとき、背景を理解している開発会社は、「このルールの目的に沿って考えると、こう対応するのが妥当だろう」と、自律的に妥当な判断を下せるようになります。
逆に、ルールの背景を共有せずに「とにかくこの通りに作ってください」という伝え方をしてしまうと、仕様書に書かれていない状況に遭遇するたびに、発注者への確認が発生し、開発のスピードが落ちてしまいます。すべての状況を事前に仕様書へ書き切ることは現実的に難しいため、背景・目的を共有しておくことは、仕様書の「行間」を正しく埋めてもらうための投資と言えます。
なお、こうした専門知識の伝達は、要件定義という工程全体の中に位置づけて考えると、より効果を発揮します。要件定義そのものの進め方については、要件定義のヒアリングを成功させるコツでも詳しく解説されている。
専門知識を伝える際、避けたい伝え方
避けたい伝え方1：業界内の常識として、説明を省略する
「これは、この業界では当たり前のことなので」と、説明を省略してしまうと、開発会社側の理解が不十分なまま、開発が進んでしまう可能性があります。当たり前だと思うことも、あえて言葉にして伝えることを心がけることをおすすめします。
専門職としての経験が長い人ほど、「これくらいは誰でも知っている」という感覚が強くなりがちです。しかし、開発会社のエンジニアやディレクターは、その業界の実務経験を持っていないことがほとんどです。「説明するのが恥ずかしいくらい基本的なこと」だと感じても、あえて言葉にして伝えることが、結果的に手戻りを減らします。
避けたい伝え方2：一度にすべてを説明しようとする
専門知識を一度にすべて伝えようとすると、情報量が多すぎて、開発会社側が全体を理解しきれないことがあります。要件定義の段階で、重要度の高い業務ロジックから、段階的に説明していくことをおすすめします。
一度の打ち合わせで業務のすべてを網羅的に説明しようとすると、開発会社側は情報を処理しきれず、重要な部分と重要でない部分の区別があいまいになってしまいます。まずは「システムの中核となる業務ロジック」を優先して説明し、細かな例外処理や周辺的なルールは、開発が進む段階に合わせて、少しずつ補足していく進め方が現実的です。
避けたい伝え方3：資料やデータを見せずに、口頭説明だけで済ませる
口頭だけの説明は、開発会社側の記憶やメモに依存してしまい、時間が経つと情報が薄れたり、誤って伝わったりするリスクがあります。次に紹介するように、資料を併用することで、この問題をある程度防げます。
専門知識の伝達に、資料を活用する
口頭での説明だけでなく、業務フローを示した図や、実際に使っている書類・記録のサンプル（個人情報などを除いたもの）を、開発会社に示すことも、効果的な方法です。実物に近い資料があることで、開発会社側の理解が、より深まります。
活用できる資料には、次のようなものがあります。
- 業務フロー図：普段の業務を「誰が」「いつ」「何をするか」の順に書き出した簡単な図。フローチャートのような形式でなくても、手書きのメモ程度でも十分に効果があります。
- 実際に使っている書類・記録のサンプル：紙の申請書、Excelの管理表、記録用紙など、実際に業務で使っているものを見せることで、開発会社側は「最終的にシステムがどういう情報を扱うのか」を具体的にイメージできます。個人情報や機密情報が含まれる場合は、該当部分をマスキング（黒塗りや伏せ字にする処理）してから共有することを忘れないようにしましょう。
- 既存の紙運用・Excel運用のルールブックやマニュアル：もし業務手順をまとめたマニュアルや、独自のルールブックが社内に存在するなら、それをそのまま渡すことも有効です。ゼロから言葉で説明するより、既存の資料をベースに補足説明を加えるほうが、効率的に伝わることがあります。
これらの資料は、開発会社が要件定義書や仕様書を作成する際の「一次情報」として活用されます。口頭説明と資料をセットで提供することで、認識のずれが生じるリスクを大きく減らせます。
専門分野別に見る、伝達で特に注意したいポイント
専門知識の伝え方に関する基本的な工夫は共通していますが、専門分野の特性によって、特に注意すべきポイントが異なります。ここでは、いくつかの専門職を例に、伝達時に注意したい点を紹介します。
医療・介護分野の場合
医療・介護分野では、「利用者の状態が日々変化する」という前提を、開発会社側に理解してもらうことが重要です。一般的な業務システムは、比較的安定したデータを扱う前提で設計されることが多いため、「同じ利用者でも、時間帯や日によって記録すべき内容が変わる」という業務特性を、具体的な記録例とともに伝える必要があります。また、記録の正確性が利用者の安全に直結するため、「入力ミスが起きたときに、どう気づき、どう修正するか」という運用ルールも、あわせて伝えておくと、システムの設計に反映されやすくなります。
税務・会計分野の場合
税務・会計分野では、法令や制度の改正によって、業務ルールが定期的に変わるという特性があります。開発会社側に「このルールは、法改正によって将来変わる可能性がある」という点を伝えておくことで、ハードコーディング（ルールをプログラムに固定的に書き込んでしまうこと）を避け、後から設定変更できる形で実装してもらえる可能性が高まります。ルールが変わりやすい部分と、変わりにくい部分を区別して伝えることが、保守性の高いシステムにつながります。
栄養士・食品関連分野の場合
栄養士や食品関連の分野では、数値の単位や基準値の考え方が複雑になりやすい特性があります。「同じ食品でも、加工状態によって栄養価の算出方法が変わる」といった細かいルールは、開発会社側が見落としやすい部分です。具体的な計算例を複数示し、「どの数値を、どういう手順で算出しているか」を、実際の計算過程まで含めて伝えることをおすすめします。
建築・不動産分野の場合
建築・不動産分野では、地域ごとの規制や慣習の違いが、業務ロジックに影響することがあります。「全国共通のルール」と「地域特有のルール」を分けて伝えることで、開発会社側がシステムの拡張性（将来、対象地域を広げる際の対応しやすさ）を考慮した設計をしやすくなります。
専門知識の伝達に関する、よくある失敗パターン
ここまで紹介した工夫とは別に、専門知識の伝達がうまくいかなかった発注者に共通して見られる失敗パターンがあります。自分の伝え方が、これらに当てはまっていないか、振り返ってみましょう。
失敗パターン1：担当者が変わることを想定していない
打ち合わせの初期段階で丁寧に説明した専門知識が、開発会社側の担当者交代によって、引き継がれないまま失われてしまうことがあります。口頭で伝えた内容は、担当者の頭の中にしか残らないことが多く、担当者が変わると、伝達した知識がリセットされてしまうリスクがあります。専門知識は、口頭だけでなく、必ず文書やメモに残し、開発会社側の社内で引き継げる状態にしておくことが重要です。
失敗パターン2：「伝えた」と「伝わった」を同じものとして扱う
発注者側が「あのとき説明したはずだ」と思っていても、開発会社側の理解が浅かったり、そもそも聞き逃していたりすることは、珍しくありません。「伝えた」という行為と、「正確に伝わった」という結果は、別のものだと意識しておく必要があります。前の章で紹介した理解度の確認は、この失敗パターンを防ぐための具体的な対策です。
失敗パターン3：専門知識を、要件定義書に反映する責任を、開発会社に一方的に任せる
専門知識を口頭やメモで伝えたあと、「あとは開発会社が適切にまとめてくれるはず」と考え、要件定義書のチェックを怠ってしまうケースです。開発会社側も、限られた情報の中で解釈して文書化しているため、発注者が意図した内容と、微妙にずれた形で要件定義書に落とし込まれることがあります。要件定義書は、必ず発注者自身が読み、自分の業務知識と照らし合わせて確認する工程を省略しないようにしましょう。
失敗パターン4：例外ケースを「稀なので後回し」と判断してしまう
発生頻度が低い例外ケースを、「めったに起きないから、開発の優先順位を下げてよい」と判断してしまうことがあります。しかし、専門分野の業務においては、発生頻度は低くても、対応を誤ると重大な問題（法令違反、安全上のリスク、顧客からの信頼失墜など）につながる例外ケースが存在します。頻度だけでなく、「対応を誤った場合の影響の大きさ」も基準に入れて、開発会社に優先度を伝えることが大切です。
専門知識を伝える前に準備しておきたいチェックリスト
打ち合わせに入る前に、次のチェックリストを使って準備状況を確認しておくと、専門知識の伝達がスムーズになります。
- [ ] 業務の中で日常的に使っている専門用語を、リストアップしたか
- [ ] それぞれの専門用語について、一言で説明できる言葉を用意したか
- [ ] 典型的な業務ケースと、例外的な業務ケースを、それぞれ書き出したか
- [ ] 例外ケースについて、発生頻度と、対応を誤った場合の影響の大きさを整理したか
- [ ] 業務ルールについて、「なぜそのルールがあるのか」という背景を説明できる状態にしたか
- [ ] 業務フロー図や、実際の書類・記録のサンプル（個人情報を除いたもの）を用意したか
- [ ] 説明した内容を、開発会社側がどう理解したか確認する手順を、打ち合わせに組み込んだか
- [ ] 打ち合わせで話した内容を、議事録やメモとして記録に残す体制を整えたか
すべての項目を最初から完璧に用意する必要はありませんが、打ち合わせを重ねるたびに、このチェックリストを見直し、少しずつ準備の精度を高めていくことをおすすめします。
開発会社側の理解度を、確認しながら進める
専門知識を伝えた後、開発会社側が、どの程度正確に理解しているかを、確認することも重要です。「今説明した内容を、あなたの言葉で説明してみてください」と依頼し、理解のずれがないかを確認することをおすすめします。
この確認作業は、一見遠回りに感じるかもしれませんが、実際には手戻りを防ぐための効率的な工程です。開発会社側の説明を聞くことで、次のようなことが分かります。
- 正しく理解できている部分：そのまま開発を進めてもらって問題ありません。
- 理解が浅い、あるいは誤解している部分：この段階で気づければ、要件定義書や仕様書に反映される前に訂正できます。開発が進んでからの手戻りに比べると、修正コストは圧倒的に小さく済みます。
- 説明が抜けていた部分：開発会社側の説明の中に、自分が伝えたつもりのない情報が含まれていたり、逆に伝えたはずの情報が抜けていたりすることがあります。これは、伝え方そのものを見直すきっかけになります。
理解度の確認は、1回の打ち合わせで完結させる必要はありません。要件定義の各フェーズの終わりに、簡単な確認を挟む習慣をつけておくと、専門知識の伝達精度を継続的に高めていけます。
専門知識の伝達がうまくいかない場合の対処法
何度説明しても、開発会社側の理解が深まらない場合、その分野の開発経験が少ない、あるいは、専門知識を正確に理解しようとする姿勢が不足している可能性があります。この場合、開発会社の変更も含めて、慎重に検討することをおすすめします。
ただし、変更を検討する前に、次のような点を振り返ってみることも大切です。
- 伝え方に、改善できる余地がなかったか。この記事で紹介した3つの工夫（用語の説明、複数ケースの提示、背景の共有）を、実際に試したうえでの結果かどうかを確認しましょう。
- 開発会社側から、質問や確認が積極的に出ていたか。理解しようとする姿勢がある開発会社は、分からない点について質問を重ねてきます。逆に、質問がほとんど出ないまま開発が進んでいる場合は、理解が浅いまま作業が進んでいる可能性があります。
- 理解の確認を、十分な頻度で行っていたか。前の章で紹介した確認作業を、実際に行っていたかどうかも振り返るポイントです。
これらを振り返ったうえで、それでも理解のずれが解消されない場合は、専門分野の開発実績がある別の開発会社への切り替えを検討する価値があります。専門知識の伝達は、発注者側の努力だけでなく、開発会社側の理解しようとする姿勢があってはじめて成立するものだからです。
専門知識の伝達と、開発コストの関係
専門知識の伝達を丁寧に行うことは、一見すると打ち合わせの時間や準備の手間が増え、開発コストを押し上げる要因のように感じられるかもしれません。しかし、実際には逆の効果が期待できます。
要件定義の段階で専門知識の伝達が不十分だと、開発が進んだ後の工程で「実はこの業務ルールが反映されていなかった」「この例外ケースを考慮していなかった」という問題が発覚しやすくなります。開発の後半で発覚した仕様の誤りは、修正のためにすでに書かれたプログラムを書き直す必要があり、要件定義の段階で発覚した場合と比べて、修正コストが何倍にも膨らむことが一般的に知られています。
つまり、専門知識の伝達に時間をかけることは、開発の初期段階でのコストを増やす代わりに、開発の後半や、リリース後に発生する手戻りのコストを大きく減らす投資だと捉えることができます。特に、専門性の高い業務を扱うシステムほど、この投資の効果は大きくなる傾向があります。
専門知識の伝達を、契約・見積もりの段階でも意識する
専門知識の伝達は、要件定義が始まってから初めて意識するものではなく、契約や見積もりの相談をしている段階から、少しずつ始めておくことをおすすめします。
見積もり依頼の際に、業務の概要や専門用語を交えた説明を行うことで、開発会社側が「この分野の開発経験があるか」「専門知識をどの程度理解できそうか」を、発注者自身も見極めやすくなります。もし、見積もりの相談段階で、専門用語を伝えてもほとんど質問が返ってこない開発会社があれば、それは「専門知識を深く理解しようとする姿勢が弱い」というサインの一つかもしれません。逆に、分からない部分について積極的に質問してくる開発会社は、専門知識の伝達がスムーズに進みやすい相手だと言えます。
このように、専門知識の伝達は、要件定義というひとつの工程だけでなく、開発会社選びの初期段階から、契約後の運用・改修フェーズまで、継続的に意識しておきたいテーマです。
まとめ
専門分野の業務知識を開発会社に正確に伝えるためには、専門用語に説明を添えること、具体的な業務ケースを複数示すこと、ルールの背景まで伝えることの3つが基本になります。加えて、資料の活用や、開発会社側の理解度の確認を組み合わせることで、伝達の精度をさらに高められます。
専門知識の伝達は、要件定義における一度限りの作業ではなく、契約前の見積もり相談から、開発中、そしてリリース後の改修フェーズまで、継続的に行っていく工程だと捉えておくと、結果的にシステムの完成度も高まります。自分の専門知識は、開発会社にとって「他のプロジェクトでは得られない、価値のある情報源」でもあります。丁寧に伝える工夫を積み重ねることが、最終的には、自分が本当に使いたいと思えるシステムを手に入れるための、もっとも確実な近道になるはずです。
この記事の次に読みたい記事
専門知識を伝える工夫を理解したら、次は専門用語の多い業界で用語集を渡すべき理由についても確認しておきましょう。あわせて次の記事も参考にしてください。
