システム開発・IT受託会社向け 技術広報制作業務支援
開発事例に、選んだ理由まで。
受託実績が、開発した機能の一覧で止まっていませんか。技術者への取材から、何が難しく、なぜその設計を選んだかを整理し、発注側が依頼を検討できる開発事例や、応募者が仕事を想像できる技術記事を制作します。
公開できる案件概要、既存の開発事例、見直したい採用記事のいずれかからご相談ください。
01 制作見本
同じ開発案件を、事例と技術記事に。
製造現場の設備点検を題材に、発注側が知りたい対応範囲と、エンジニアが知りたい設計の判断を、一つの取材から書き分けました。
A ／ 発注検討者向けの開発事例
紙の点検表を端末に移し、設備番号で記録を探せるように。
点検を紙で記録し、作業後に事務所で転記していた製造現場。通信が途切れる区画があるため、端末への入力とサーバーへの登録を分ける構成としました。
当社の担当範囲は、点検項目の整理、現場端末の入力画面、設備番号で記録を探す管理画面、試行後の運用手順の整備です。試行では、通信が切れたあとに同じ端末から記録を送れることと、管理側で対象設備の履歴をたどれることを確認しました。
掲載想定 受託開発の事例ページ。業務条件・担当範囲・受け入れ時の確認項目を示す。
B ／ 応募者向けの技術記事
点検中に回線が切れたら。送信と保存を分けた設計判断。
試作の初期案は、入力と同時に送信する設計でした。現場を見て、通信が戻るまで点検を止めずに進められるよう、記録を端末に一時保存し、担当者が復帰後に送信する方式を選びました。
同じ記録を再送した場合に備え、端末で発行した記録IDをサーバー側で照合します。テストでは「入力途中で回線を切る」「同じ記録を送信し直す」を分け、画面の状態表示と登録件数を確かめました。
掲載想定 エンジニア採用ブログ。採用した設計、選んだ理由、テストの着眼点を示す。
貴社の案件なら、どの判断をどこまで語れるか。公開できる概要から整理します。
自社案件の事例化を相談する02 支援範囲
発注の検討と、応募の検討に合わせて。
受託相談では対応範囲と進め方を、採用では技術者が担う役割やチームの判断を伝えます。両方に使う事実を整理し、案内先は分けて設計します。
開発事例と商談資料
業務課題、現場の制約、担当した範囲、移行・運用時に確認したことを、受託事例ページや営業資料にまとめます。
技術記事と採用コンテンツ
設計上の選択肢やテスト、担当者間の役割分担を取材し、技術ブログや採用ページに使える記事・図を制作します。
得意領域と開発体制の説明
どんな業務、既存環境、開発段階から相談できるかを整理し、会社案内やサービスページ、受託相談の入口に反映します。
03 制作と公開前の確認
公開できる範囲を、取材の前にすり合わせる。
お客様名、画面、数値、構成情報について、公開できる素材と社内でのみ扱う素材を分けます。
- 着手時 使う媒体と素材、貴社・お客様側の確認担当を決める。
- 取材・制作 技術者に設計判断を聞き、掲載可能な言葉と図にする。
- 掲載前 事実と公開可否を確認し、営業用と採用用の原稿を仕上げる。
04 ご相談の前に
よくあるご質問
お客様名や画面を出せない案件でも相談できますか？
公開の許可が取れる情報と、匿名化や描き直しができる範囲を確認します。業務課題、担当範囲、設計判断のどこまでを公開できるか整理したうえで構成を決めます。
エンジニアが原稿を用意する必要はありますか？
公開可能な案件概要や既存資料を出発点にできます。技術者に判断の背景を聞き取り、原稿と図にしたあとで事実を確認していただきます。
制作費用と納期は何で決まりますか？
対象案件と成果物の数、取材相手、図解や画面加工、社内・お客様側の確認工程を整理してお見積もりします。
05 技術広報のご相談
まずは、公開を検討している1案件から。
開発した業務システムの概要と、事例・営業・採用のどこで使いたいかをお聞かせください。
相談後に分かること
- 優先する制作物発注側に見せる開発事例か、応募者に見せる技術記事か。
- 取材先と公開確認技術者・営業・お客様の確認が必要な箇所と、使える資料。
- 見積もりに必要な範囲案件・媒体の数、取材、図解や素材加工、承認工程。
開発事例・技術広報の制作を相談する
公開済みの事例URLや、機密を含まない案件概要をお知らせください。お客様名や未公開の仕様は、公開可否を確認してからお取り扱いします。