開発会社の体制紹介｜役割と案件別の確認窓口を示す

開発会社のサイトに「PM、エンジニア、デザイナーが伴走」と書いてあっても、発注を考える人は次に迷うことがあります。最初の業務相談は誰が聞くのか。画面の確認は誰へ返すのか。仕様が変わりそうなときは、営業窓口に伝えるのか、開発担当へ直接伝えるのか。役職名を並べるだけでは、顧客が参加する場面と確認先が見えません。

体制紹介ページでは、会社として通常説明できる役割と、案件ごとに決める担当者・連絡方法を分けます。公開ページには、発注前の顧客が何を誰に確認できるかを、現在の提供範囲に沿って示します。実在しない専任体制や全工程の担当を約束しないことも大切です。この記事は開発プロジェクトの管理制度や契約上の責任分担を決めるものではありません。営業、進行管理、開発の資料を照合し、体制紹介と問い合わせの改修範囲を判断します。

組織図と案件の連絡網を混ぜない

会社の組織図は、部門や職種の構成を示します。一方、案件の連絡網は、その顧客の業務、工程、契約、担当者によって決まります。公開サイトで固定の組織図だけを載せると、そこに描かれた全員がどの案件にも参加すると受け取られるかもしれません。逆に一件の案件で用いた担当表をそのまま載せると、別の相談でも同じ名前と確認先が使えるように見えます。

まず現行サイトの「開発体制」「進め方」「お問い合わせ」を並べ、同じ役割名が異なる意味で使われていないか調べます。「PM」は進行を管理する人なのか、顧客の業務を聞く窓口なのか。「開発担当」は設計・実装・テストのどこまで関わるのか。協力会社と分担する工程があるのに、全員を自社社員として紹介していないか。これらは一般論で埋めず、事業責任者と担当者が確認した説明を原稿にまとめます。

IPAの要件定義に関する解説は、利用者側の企業と開発者側の認識を合わせ、関係者と要求を確認する重要性を示しています。役割が複数あることは自然ですが、どの会社でも同じPMや開発担当の構成になるわけではありません。サイトでは、役割の名称より「何を、どの場面で確認するか」を読み手に伝える方が役立ちます。

役割図に確認場面と窓口を示す

次の表は、公開用の体制図を作るための設計例です。実際に対応する工程や確認方法は、各社の提案書と運用資料で確定します。

表は左右にスクロールして確認できます。

表の中で「公開ページに書けること」は、会社の提供範囲に基づく役割の説明です。「案件ごとに確定すること」には、個人名、参加人数、レビューの回数、会議の頻度、協力先の有無などが入ります。全案件で同じ条件と断定しないため、実際の契約・提案段階で確認すると明示します。公開の役割図には固有の顧客名やシステム構成を入れず、顧客側、進行窓口、専門担当の関係が読める最小限の情報にします。

IPAのビジネス分析に関する案内は、現在の開発ではユーザー企業とベンダー企業の役割を一律の境界に分けることが適切でない場合もあると述べています。そのため公開図に「顧客は要件を決め、開発会社は作るだけ」といった固定的な矢印を引くのは避けます。顧客側の業務確認者が何を確かめ、開発会社側の誰が整理して返すかを、実際に行う範囲で表現します。

公開する役割と案件別の担当を分ける

「経験豊富なPMが必ず専任で担当します」は、その配置をすべての対象案件で確かめられなければ公開文にできません。公開ページでは、たとえば「初回の相談では業務の状況を伺い、担当工程と確認方法を提案時に示します」と、会社として実際に行う行動を書く方が正確です。案件開始後には、進行の窓口、専門事項を確認する人、顧客側の判断者、連絡方法を個別に案内します。会社として行うことはサイトの役割図に、案件ごとの担当者や連絡方法は提案・開始時の資料に記載します。両者を分ければ、公開後に人員が変わっても誤案内が起きにくくなります。

ただし、役割名だけを抽象化しすぎても読み手は動けません。「進行管理」には、どの資料を受け取り、何を整理して返すのかを一文で添えます。「専門担当」には、どの工程や疑問で意見を聞くのかを添えます。顧客が直接連絡する先を原則一つにするか、内容別に分けるかは実際の運用で決め、公開図と問い合わせ画面を同じ説明にします。担当者の顔写真や経歴を載せる場合も、役割の説明を置き換える飾りにせず、本人の確認と更新方法を定めます。

相談の段階ごとに受付先を示す

体制紹介を読んだ人がそのまま問い合わせへ進むなら、ボタンは「PMへ直接相談」より「開発の進め方を相談」のように、今できる行動を示します。まだ案件が始まっていない段階で、特定の担当者に届くと約束しないためです。初回相談、進行中の案件、保守・運用の問い合わせで実際の受付が異なるなら、ページ上にも入口を分けます。既存顧客用の窓口が契約資料や管理画面にある場合、一般問い合わせへ機密の仕様を入力させないようにします。

初回フォームで聞くのは、会社名、連絡方法、対象業務、相談したい段階、現在ある資料の有無など、一次返信に必要な範囲です。まだ仕様が定まっていない人には「業務の困りごとから相談」を選べるようにします。技術条件が決まっている人には、利用環境や連携先を後で安全に確認する手順を案内します。自由記述欄に認証情報、実データ、顧客情報を貼り付けさせない説明も必要です。資料添付を設けるなら、形式、容量、保存場所、閲覧権限を先に決めます。

受信後の案内には、誰が最初に内容を確認し、必要に応じて進行・技術の担当へ確認するかを書きます。ここでも「担当者が決定しました」と自動表示しないことが重要です。返信の目安を載せるなら現行の営業日と受付体制に照らし、未確認なら期間を創作しません。案件中の連絡先を公開ページに載せる場合も、個人のメールアドレスを常設するか、共通窓口へ集約するかを運用資料に合わせて判断します。

フォームから届く情報は「質問の種類」と「確認する資料」を分けて受けます。最初の業務相談なら、現在の手順、困っている場面、関係する部署が分かれば、次の聞き取り先を検討できます。具体的な改修相談なら、現行システムの種類、変えたい操作、利用者、希望時期を聞くことが考えられます。保守に関わる問い合わせは既存契約や受付経路の確認が先です。これらを一つの長いフォームで全部必須にせず、相談段階に応じて項目を出します。「分からない」を選べる欄には、後で誰が確認するかも受信票に示します。

通知メールの件名を「お問い合わせ」一種類にすると、営業・進行・保守のどこで受けるべきか本文を開くまで分かりません。相談段階、対象サービス、参照したページを必要な範囲で引き継ぎ、一次受付の担当へ届けます。案件固有の技術情報を広い配信先へ送らないよう、通知先と管理画面の閲覧権限も確認します。送信テストでは、選択した段階と受信側の分類が一致し、担当者が変わった時も未対応が残らないかを見ます。

体制・事例・採用の説明を分ける

体制ページは「誰がどう確認するか」に集中します。開発事例は、特定の案件で何を担当したか、公開許可を得た範囲で説明する場所です。採用ページは、エンジニアがどの技術に触れ、どう働くかを求職者へ伝える場所です。顧客向けの体制図へ技術スタックや採用制度を一緒に詰めると、発注担当者の確認先が埋もれます。関連する事例や技術のページへリンクし、本文では窓口と確認場面を先に示します。

実績から体制ページへ来た人には、「この事例と同じ人数で対応できる」と誤解させないことも必要です。事例の担当範囲はその案件の事実として示し、体制ページでは一般的な役割と相談方法を説明します。受託開発だけでなく常駐支援や協力会社を扱う場合も、現在提供するサービスと各案件の分担を区別してください。社員数や保有資格を示すなら、対象範囲と確認日を添え、案件の実際のアサインを保証する書き方にしません。

「営業から開発へ引き継ぐ」だけでは、顧客が何を返せばよいか分かりません。たとえば初回の業務相談では現状の困りごと、要件確認では画面と業務の判断、試作の確認では使い方と不足点、といった確認材料を、対応する役割の説明とあわせて示します。これはプロジェクト管理手法を教えるためではなく、体制紹介ページの文と相談導線が同じ場面を指すようにするためです。実際に行わない試作やレビューを例示のまま公開しないよう、担当部門で確認します。

図の内容と連絡先を照合する

役割図には、顧客側の業務確認者、進行の窓口、専門担当の関係を短い言葉で示します。人物の顔写真や肩書を載せる場合は、本人の許諾、在籍・担当の最新状態、更新する責任者を確認します。担当者の異動が多い会社なら、公開ページは役割名を中心にし、案件開始後に個人名と連絡方法を別に案内する方が保守しやすいこともあります。最初から「専任PM」と書くなら、すべての対象案件で事実かどうかを確認します。

図の矢印は、指揮命令や契約上の責任を示すものに見える場合があります。単に相談や確認の流れを示すなら、「相談を受ける」「専門事項を確認する」「顧客へ返す」など、矢印の意味を言葉で示します。協力先が入るかどうかが案件で変わるなら、公開図に固定の会社名を入れず、どの段階で体制を確定するかを書きます。技術情報や守秘対象の資料を図へ描き込む必要はありません。

サイト制作時は、営業の説明資料、提案書、案件開始時の連絡票、保守の案内を照合します。公開できる役割の名称、担当工程、顧客が確認する場面、案件ごとに変わる項目を一覧にまとめ、営業・開発・運用の各責任者へ回します。原稿だけでなく、図の矢印、写真のキャプション、問い合わせ先、受信メールの通知先まで同じ内容にそろえます。変更があったときは体制ページと問い合わせの両方を更新できるようにします。

承認の際は、一覧の各行に「公開してよい役割」「現時点では案件別に案内すること」「確認する部署」を記します。たとえばレビューを実施することは公開できても、回数や参加者は案件によって異なるなら、その差を原稿に残します。協力先が参加する可能性を示す場合も、どの工程を外部へ依頼するか、顧客への説明をいつ行うかを事業責任者に確かめます。決まっていない値を架空の標準として埋めず、提案時に確認する項目として示します。

公開前には、初めて相談する人の視点で、サービス説明から体制図を読み、何を誰に伝えるか分かるかを確認します。次に既存顧客の視点で、進行中の質問と一般相談が混ざらないかを確かめます。スマートフォンでは図の役割名と矢印が読めるか、リンクとフォームへ進めるかを試します。実際のフォーム送信では受付通知と担当への引継ぎも読み戻します。問い合わせが多い工程や確認先の聞き直しを後から記録すれば、説明を直す優先順位を判断しやすくなります。効果は現状を測ってから判断します。

参考資料

• IPA DX SQUARE「要件定義とは？」（利用者側と開発者側の認識合わせ、関係者の確認を参照）
• IPA「システム構築はビジネス分析から始まる」（ユーザー企業とベンダー企業の役割の一律な境界に関する記述を確認）
• IPA「ユーザのための要件定義ガイド 第2版」（利用部門の関与と要件確認の資料を確認）