専門性の高いシステム開発の依頼｜業務知識の伝え方

専門性の高い業界のシステム開発を依頼するとき、業務の知識を開発会社にどう伝えるかで、仕上がりは大きく変わります。この記事では、依頼前に書き出しておきたい知識の種類、伝える順番、開発会社に確かめたい点、実物を見ながらズレを直す進め方を整理します。分厚い資料を作れない段階でも、取りかかれる手順を中心にまとめました。

なぜ専門性の高い業界のシステム開発は、知識の伝達でつまずきやすいのか

業界の「当たり前」ほど、言葉にされない

長く同じ業界にいる人にとって、当たり前になっていることほど、言葉にされないまま残ります。たとえば次のようなものです。

• ある手続きの前には、確認しておく書類が決まっている
• この種類の依頼だけは、別の担当者に回すのが慣例になっている
• 数字の端数は、業界の慣習で特定の方法で処理する

こうした知識は、経験者が無意識に使っている判断や手順であり、文書として残っていないことが多くあります。経験から身につき、言葉になっていない知識を「暗黙知」と呼びます。専門性の高い業界ほど、この暗黙知が業務の中心に入り込んでいます。

開発会社は、多くの場合その業界の外にいる

システム開発を請け負う会社は、さまざまな業界の案件を手がけます。そのため、依頼先がその業界の用語や慣習をすべて知っているとは限りません。

そこで次のようなすれ違いが起きます。

• 依頼する側は「業界の人なら分かる話だから、言わなくても通じるだろう」と考える
• 開発する側は「大事なことなら言ってもらえるだろう」と考える
• 結果として、誰も確認しないまま抜けが残る

どちらにも悪意はありません。ただ、言葉だけで要件を決めようとすると、こうした認識違いが起きやすくなります。この仕組みについては「システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせ」でも整理しています。

新規事業では、業務そのものがまだ固まっていない

もう一つ、新規事業ならではの難しさがあります。既存の業務を置き換えるのとは違い、新規事業では「この事業はどう回るのか」自体を、作りながら決めていくことがあります。業界の知識と、事業としての設計の両方を同時に扱うことになるため、伝えるべき内容が整理しにくくなります。

だからこそ、知識を「全部伝え切る」のではなく、「伝わっているかを確かめながら進める」前提で準備するのが現実的です。

依頼前に書き出しておきたい業務知識の5つ

ここでは、整った文書にする必要はありません。メモ書きや箇条書きで十分です。まず手元にある知識を、次の5つの切り口で書き出してみます。

1. 用語と略語

専門性の高い業界には、独自の用語や略語があります。同じ言葉が、社内と業界全体で別の意味で使われていることもあります。

• よく使う用語とその意味（簡単な説明で十分）
• 略語の元の言葉
• 似ているが区別したい言葉の違い

簡易な用語集を1ページ用意しておくだけで、打ち合わせでの確認の手間が減ります。開発会社が画面の項目名やデータの名前を決めるときにも、判断の拠り所になります。

2. 業務の流れと登場人物

次に、業務が始まってから終わるまでの流れを、時系列で書き出します。あわせて、誰がどの段階で関わるのかも整理します。

• 最初のきっかけは何か（問い合わせ、申請、発注など）
• どの段階で、誰が何を確認・判断するのか
• 完了とみなす条件は何か
• 社外の関係者（取引先、行政、利用者など）はどこで登場するのか

文章が難しければ、手書きの図でも構いません。矢印でつないだ簡単な流れ図があると、言葉だけの説明より誤解が減ります。

3. ルールと例外

専門性の高い業界では、守るべきルールが決まっていることがよくあります。法令やガイドライン、業界団体の取り決めなどです。どのルールが自分たちの事業に関係するかは業界によって異なるため、所管する官庁や業界団体が公開している資料で、最新の内容を確認しておくと安心です。

あわせて、書き出しておきたいのが例外です。

• 原則はこうだが、この場合だけ扱いが変わる
• 通常の流れでは処理できず、人が判断して対応するケース
• 過去にトラブルになった、注意が必要な場面

例外こそ、システムの設計に大きく影響します。普段の流れだけを伝えて例外が抜けていると、完成後に「現場では通用しない」という指摘が出やすくなります。

4. 判断の基準

経験豊富な担当者が「これは大丈夫」「これは確認が必要」と判断しているとき、何を見ているのかを言葉にしておきます。

• 判断に使っている情報や数値
• 迷ったときに相談する相手
• 判断を誤ると何が起きるのか

判断の基準は暗黙知の中心になりやすい部分です。完全に言葉にするのは難しくても、「何を見て判断しているか」を並べるだけで、設計の手がかりになります。

5. 現状のやり方と、その理由

最後に、いま行っているやり方と、そのやり方になっている理由を書きます。新規事業の場合は、想定している事業のやり方と、その根拠です。

理由まで書く点が重要です。理由が分かれば、開発側はその目的を満たす別の方法を提案できます。理由が伝わらないと、「現状どおりに作る」か「目的を外した提案が出る」のどちらかになりがちです。

この5つを書き出す作業は、要件定義の下準備でもあります。要件定義そのものの考え方は「要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方」で詳しく扱っています。

完璧な資料を作ろうとせず、伝える順番を決める

業務知識をすべて文書にしてから依頼しようとすると、準備に時間がかかり、肝心の開発が始まりません。知識は一度に渡すのではなく、順番を決めて少しずつ渡すほうが、現実的で確認もしやすくなります。

最初は「目的」と「使う人」から

最初に伝えるのは、細かい業務ルールではありません。次の2点です。

• この事業（システム）で、誰のどんな困りごとを解決したいのか
• 使う人は、どんな立場で、どんな場面で使うのか

目的と使う人が共有されていれば、細部が抜けていても、開発側が「この目的ならこうでは」と考える土台ができます。

次に、代表的な流れを1本だけ通す

次に、いちばん典型的な業務の流れを1本だけ、最初から最後まで具体的に説明します。たとえば、ある専門職の利用者が申し込みをし、資格の確認を経て、サービスが始まるまで、といった一連の流れです。

あれもこれもと広げず、まず1本を丁寧に伝えます。この1本を軸に、後から例外や別パターンを足していくほうが、全体を一度に説明するより理解が揃いやすくなります。

その後に、例外と用語を足していく

代表的な流れが共有できたら、例外のケースと用語を少しずつ足します。このとき、一度に全部出さず、打ち合わせのたびに「今回はこの例外を確認する」と範囲を区切ると、お互いの負担が軽くなります。

実物の資料を添える

言葉だけでなく、現場で使っている実物があれば、あわせて共有します。

• 現在使っている帳票、申請書、報告書のサンプル
• 画面のキャプチャや、手書きのメモ
• 現場の作業の様子が分かる写真

実物は、言葉では説明しきれない情報を一度に伝えてくれます。

ただし、資料には個人情報や取引先の情報、まだ公開していない事業のアイデアが含まれることがあります。共有の前に、秘密保持契約の内容を確認し、必要に応じて固有名詞や数値を伏せておくと安全です。確認すべき項目は「システム開発のNDA｜秘密保持で決める8つの項目」にまとめています。生成AIを使った開発で情報をどう扱うかは、「生成AI開発の情報漏洩を防ぐ確認点｜機密と事業アイデア」も参考になります。

窓口となる人を一人決めておく

業務知識は、複数の人が少しずつ持っていることが多く、人によって言うことが違う場合もあります。開発会社が複数の担当者から別々の指示を受けると、混乱の原因になります。

そこで、発注側で「業務知識の窓口」と「最終的な判断をする人」を決めておきます。判断する立場の人の役割は「発注側のプロダクトオーナーとは｜役割と判断のしかた」で整理しています。窓口の人がすべてを知っている必要はありません。分からないことを社内の詳しい人に確認し、答えをまとめて返す役割です。

開発会社に確かめたい質問

業務知識を伝える側の準備と同じくらい、受け取る側の姿勢も重要です。依頼先を検討するとき、次の点を確かめておくと、知識の伝達がうまくいくかを見通しやすくなります。

• 業界知識をどう補うのか：業界の経験者が在籍しているか、ヒアリングや調査をどう行うのかを聞く
• 用語の確認をどう進めるのか：用語集を一緒に作る、分からない言葉をその場で聞いてくれるなど、確認の仕組みがあるか
• 分からないことを「分からない」と言ってくれるか：分かったふりをされるほうが、後の手戻りは大きくなる
• 確認の頻度はどのくらいか：長い期間の後にまとめて確認するのではなく、早い段階で何度も確認できるか
• 例外の洗い出しをどう進めるのか：発注側の説明を待つだけでなく、質問して引き出してくれるか

会社選びの全体像は「システム開発会社の選び方｜新規事業で失敗しない7つの視点」にあります。AIを使う開発会社に依頼する場合の確認点は「AI受託開発に依頼する前に確かめたい6つのこと」にもまとめています。

また、打ち合わせの中で、こちらの説明を開発側が自分の言葉で言い直してくれるかどうかは、よい目安になります。言い直した内容に違いがあれば、その場で気づいて直せます。

実物を見ながら、知識のズレを直していく

どれだけ丁寧に書き出しても、最初から完全に伝わることはありません。そこで有効なのが、動く実物を早い段階で見て、業界の人の目で確かめることです。

「言われて気づく違和感」を拾う

専門性の高い業務では、実際に画面を触ると、文書では気づかなかった違和感が見つかります。

• 項目の並びが、現場の作業の順番と合っていない
• 業界の人なら使わない言い回しになっている
• 例外のケースで、操作が行き詰まってしまう

こうした指摘は、完成後より、早い段階のほうが直しやすくなります。仕様書を読むだけでは気づかなくても、触れば「ここは違う」と分かる、という場面は少なくありません。プロトタイプを使った確かめ方は「プロトタイプのユーザーテスト｜新規事業での確かめ方と質問」で扱っています。

業界の人に実際に触ってもらう

窓口の担当者だけで確認すると、見落としが残ります。可能であれば、実際にその業務を行う現場の人にも触ってもらいます。専門性の高い業界ほど、現場の人が持つ細かい知識が品質を左右します。

触ってもらうときは、「どう思いますか」と漠然と聞くより、具体的な場面を与えるほうが意見を引き出しやすくなります。

• 「この申し込みが来たとき、次に何をしますか」
• 「この画面で、足りない情報はありますか」
• 「普段、この判断は何を見て行っていますか」

動くものがあれば、事業の関係者や社内の決裁者との認識合わせにも使えます。企画書だけでは伝わりにくい内容を、実物で見せられるためです。その考え方は「稟議を通すシステム開発｜プロトタイプの使い方」でも紹介しています。

AIを使った開発でも、業務知識は人が確認する

近年は、AIが要件の整理や設計、実装を手伝う開発が広がっています。AIは広く一般的な知識を持っていますが、特定の会社の判断基準や最新の運用、業界内の細かい慣習までを正しく押さえているとは限りません。AIが整理した内容が、業務の実態に合っているかを確かめるのは人の役割です。

AIが整理し、人が決める範囲については「AI要件定義で変わること｜AIが整理し人が決める範囲」、品質の確認に人が必要な理由は「AI開発でも品質には人の確認が必要な理由」で整理しています。開発の進め方が変わっても、業務知識を持つ人が実物を見て確かめる工程の価値は変わりません。

まとめ

専門性の高い業界のシステム開発を依頼するときの要点は、次のとおりです。

• 業界の「当たり前」は暗黙知になりやすく、言葉にしないと開発側に伝わらない
• 用語、業務の流れ、ルールと例外、判断の基準、現状のやり方とその理由の5つを、メモ書きでよいので書き出す
• 全部を一度に伝えようとせず、目的と使う人、代表的な流れ1本、例外と用語の順に渡す
• 帳票や画面などの実物を添える。共有の前に、機密情報の扱いを確認する
• 発注側で業務知識の窓口と判断する人を決める
• 開発会社には、業界知識の補い方や確認の頻度、分からないことを伝えてくれるかを確かめる
• 動く実物を業界の人が触り、違和感を早い段階で拾って直す

業務知識を完璧に言葉にしてから依頼する必要はありません。伝わっているかを実物で確かめながら進めるほうが、専門性の高い領域では現実的です。

JustFitは、株式会社LEGAREAが運営する受託開発サービスで、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断していただく進め方をとっています。仕様が固まっていない段階でも相談できるため、業務知識の整理に自信がない状況でも、まず何に困っているかをお聞かせください。詳しくはJustFitのサービス紹介をご覧ください。