メインコンテンツへスキップ
ブログ一覧に戻る
Web制作・運用

Web担当がいないとき、何から相談すればいいか

2026年6月10日
最終更新: 2026年10月8日
6分で読めます

この記事でわかること

Web担当者がいない会社の相談を、制作発注ではなく利用者の困りごと・意思決定権・役割・運用境界をそろえる発見工程として整理します。GOV.UK Service Manualのユーザーニーズ、サービスチームの役割、継続改善と証拠に基づく判断を参照し、相談前の1枚メモと外注・内製の分界を更新します。も追記。

2026年10月8日にGOV.UK Service Manualの利用者ニーズ、Service manager、Service teamの必要範囲を再確認した。相談では解決策の前に利用者の問題と仮説を調査し、サービスオーナーは開発・運用・継続改善に責任と意思決定権を持つ役割として置く。ユーザーニーズ、実ユーザーテスト、セキュリティ、性能測定、運用支援を相談後の検証欄へ記録することは記事提案で、肩書き、契約責任、費用、納期、事業成果を資料だけで確定しない。

30秒で要点

Web担当者がいないことより、困りごと、判断者、運用責任、見直しの条件が見えないことが相談を難しくします。

  • 相談の入口は、作るものではなく、利用者が達成したい結果と困りごとから始める
  • GOV.UK Service Manualは、ユーザーニーズを証拠で確かめ、サービスオーナーや各専門職の責任を分ける
  • 制作、更新、計測、改善の境界を一枚へ置き、誰が決めるかと誰が実行するかを分ける
  • 相談前のメモは発注書ではなく、発見・選択・検証の順番をそろえるために使う
Web相談を利用者の困りごと、判断者、役割、検証へ分ける図解
担当者の有無より、判断と運用の境界を先に見える化する。

1. 解決策ではなく利用者の結果から始める

GOV.UKのユーザーニーズ資料は、サービスを作る前に利用者を理解し、可能な解決策ではなく利用者の問題へ焦点を当てるよう説明しています。意見や提案は、利用者調査で確かめるまで仮説として扱います。

相談前の一文は、次の形にします。

「[どの利用者]が、[どの状況]で、[何を達成したい]が、[どこで止まっている]。」

例:「既存顧客がスマートフォンで保守窓口を探すとき、連絡先が見つからず電話へ戻っている。」制作物の名前を先に置かないことがポイントです。

2. 判断者と役割を分ける

GOV.UKのサービスチーム資料は、プロダクトマネージャー、サービスオーナー、ユーザーリサーチャー、コンテンツデザイナー、デザイナー、開発者など、異なる役割をチームへ置きます。サービスオーナーは、開発・運用・継続改善に責任を持ち、意思決定の権限を持つ役割として説明されています。

小さな会社で一人が複数役を担うことは問題ではありません。役割を一人の名前に隠さず、次の欄で分けます。

表が収まらない場合は、横にスクロールできます

欄相談前に書くこと
現場の声問い合わせ、営業、採用、更新を知る人
最終判断目的、予算、優先順位を決める人
実行原稿、デザイン、実装、公開を担う人
運用更新、計測、問い合わせ、障害対応を担う人
再評価いつ、何の証拠で見直すか

決める人が会議に出られない場合も、後から承認できる記録を残します。

3. 相談前の1枚メモ

表が収まらない場合は、横にスクロールできます

欄例
利用者の困りごと問い合わせ前に料金条件が分からない
いまの証拠検索語、問い合わせ、離脱、担当者の観察
3か月後の結果条件を理解してから相談できる
変更の範囲構成、原稿、フォーム、計測のどこか
制約予算、期限、権限、既存システム
判断者・担当決める人、作る人、運用する人
見直し指標、期間、停止・継続の条件

完璧な要件定義は不要ですが、「分からない」と書く欄を残します。不明点を制作会社の提案だけで埋めず、調査・選択・実装の順に見積もります。

4. 内製と外注の分界

GOV.UKのサービスチーム設計では、利用者ニーズの分析、設計・構築・テスト・反復、セキュリティ、実運用、性能測定までをチームの能力として挙げています。会社の規模にかかわらず、作って公開した後の責任を表へ残します。

表が収まらない場合は、横にスクロールできます

領域社内が持つ判断外部へ委ねやすい作業
目的・優先順位顧客、事業、制約の知識整理の支援、選択肢の比較
原稿・更新事実、承認、更新期限編集、デザイン、実装
計測成果指標、分母、利用許可計測設計、タグ実装
運用問い合わせ、障害、停止判断保守、監視、専門対応

境界は永続的な契約ではなく、内製できる条件、外注の終了条件、引き継ぎ方法と一緒に決めます。

5. 発見から検証へ進む

GOV.UKのサービスチーム設計は、各段階でユーザーニーズ、セキュリティ、実ユーザーとのテスト、性能測定、運用支援を扱える技能が必要だと説明します。

相談後は、次の小さな順で進めます。

  1. 利用者の困りごとと証拠を確認する。
  2. 解決策を複数案にし、目的・制約・費用を比較する。
  3. 1ページまたは1導線で試す。
  4. 完了、質問、離脱、問い合わせ内容を記録する。
  5. 継続、修正、中止、内製化の判断を残す。

「リニューアルするか」を先に決めず、結果と判断権限をセットで見直します。

6. 相談資料から言えないこと

GOV.UK Service Manualは、特定の制作会社、費用、納期、会社の成果を保証するものではありません。公共サービスの資料なので、自社の顧客、法令、契約、技術条件へ適用できるかを確認します。

相談の判断軸をさらに分解するならWebリニューアルの判断軸、利用者の声と分母の扱いはデータドリブンUX改善も参照してください。

よくある質問(FAQ)