発注・外注の進め方
開発を依頼したあと発注者がやること｜確認・修正・公開までの進め方
開発会社に発注したら、あとは完成を待つだけ――そう考えていると、思わぬところで開発が止まったり、完成したものが想定と違ったりします。業務用のWebアプリは、発注者の業務の中で使われるものです。発注後に発注者が担う役割と、確認から公開までを滞らせないためのコツをまとめました。
発注後の流れと、発注者の役割
| 段階 | 開発会社が行うこと | 発注者が行うこと |
|---|---|---|
| 開発 | 画面と機能を作る | 質問への回答、必要な資料やデータの提供 |
| 初回納品 | 実際に触れる状態で渡す | 業務の流れに沿って確認し、フィードバックする |
| 修正 | 合意した範囲内で調整する | 修正内容を確認する |
| 公開 | 本番環境の準備、公開作業 | データの登録、社内への周知、切り替えの判断 |
開発中：質問に早く答える
開発の途中では、「この項目は必須ですか」「このケースではどう表示しますか」といった質問が届きます。業務のルールに関わる質問は、開発会社だけでは判断できません。回答が遅れると、その部分の作業が止まります。
- 窓口と、最終判断をする人を決めておく
- すぐに判断できない質問は、いつまでに回答できるかを伝える
- 回答した内容は、関係者にも共有する
初回納品：業務の流れに沿って確認する
初回納品は、実際に操作できる状態のWebアプリです。ここでの確認が、使える仕組みになるかどうかを大きく左右します。
- 業務の流れに沿って操作する：画面を一つずつ見るのではなく、実際の業務の順番で、登録から完了まで通して操作する
- 現場の担当者にも触ってもらう：日々使う人にしか気づけない使いにくさがある
- 実際のデータに近いもので試す：長い名前、多い件数、例外的なケースなど、実際に起こる条件で確認する
- スマートフォンなど、実際の環境で確認する：現場で使う端末やブラウザで試す
フィードバックの伝え方
確認して気づいたことは、伝え方によって修正のスピードと正確さが変わります。
| 伝わりにくい例 | 伝わりやすい例 |
|---|---|
| 一覧が使いにくい | 案件一覧で、担当者で絞り込んだあとに並び順が戻ってしまう。期限の近い順のままにしてほしい |
| 登録できない | 顧客登録画面で、電話番号にハイフンを入れて保存するとエラーになる（スクリーンショット添付） |
| もっと見やすくしてほしい | 詳細画面で、対応履歴を新しい順に表示してほしい |
「どの画面で」「何をしたら」「どうなったか」「どうしてほしいか」を一つずつ書き、可能ならスクリーンショットを添えると確実です。
ポイント：気づいた順ではなく、まとめて伝える
気づいたたびに一つずつ伝えるより、確認の担当者で意見をまとめ、一覧にして伝えるほうが、修正の手戻りが少なく済みます。社内で意見が分かれている点は、社内で結論を出してから伝えましょう。また、不具合（合意した内容のとおりに動かない）と、要望（別のやり方にしてほしい）を分けて書くと、優先順位をつけやすくなります。
公開前：切り替えの準備をする
- 本番で使うデータ（顧客、品目、設定など）の登録
- 利用者のアカウントの作成と、使い方の案内
- 旧来の方法（Excelなど）から切り替える日の決定
- 切り替え後の、旧来のファイルの扱い（参照用として保管するなど）
- 使い方が分からないときの、社内の問い合わせ先
切り替えの日を決めずに並行運用を続けると、どちらが正しい情報か分からなくなり、新しい仕組みが使われなくなる原因になります。開発期間全体の考え方は小規模Webアプリの開発期間はどれくらい？、進め方でつまずきやすい点は業務アプリ開発で失敗する会社の共通点で解説しています。
確認のときに見ておきたい観点
初回納品の確認では、画面の見た目だけでなく、次のような観点で操作してみると、公開後に困る点を早めに見つけられます。
| 観点 | 確認の例 |
|---|---|
| 業務の流れ | 登録から完了まで、実際の業務の順番で操作できるか |
| 例外的なケース | 取り消し、差し戻し、途中での変更などを行ったときにどうなるか |
| 権限 | 役割の違う人のアカウントで、見える範囲と操作できる範囲が想定どおりか |
| データの量 | 件数が多いときに、一覧や検索が使いやすいか |
| 入力のしやすさ | 毎日使う担当者にとって、入力の順番や項目は自然か |
| 表示する言葉 | ボタンや項目の名前が、社内で使っている言葉と合っているか |
すべてを一度に確認する必要はありません。毎日使う操作から優先して確認し、例外的なケースは後から確認する、という順番でも構いません。
公開後に発注者が続けること
公開して使い始めた後も、発注者の役割は続きます。
- 使い方の問い合わせに答える社内の窓口を決める
- 現場から出てくる改善の要望を、一か所に集める
- 要望に優先順位をつけ、次の改善の範囲を決める
- 退職者・異動者のアカウントを止めるなど、利用者の管理を行う
改善の要望を思いついた順に依頼するのではなく、一定期間ごとにまとめて相談すると、費用を管理しやすく、全体の使い勝手もそろいやすくなります。
発注者の負担を減らす工夫
発注者の役割は少なくありませんが、工夫次第で負担を減らすことができます。確認の担当者を一人に集中させず、業務ごとに分担する。質問への回答は、決まった時間にまとめて行う。フィードバックは共有の一覧に書き込み、社内で意見をそろえてから伝える。こうした進め方を最初に開発会社と決めておくと、日常の業務と並行しながらでも、開発を滞らせずに進められます。
開発会社とのやり取りの中で、範囲や修正の扱いについて認識をそろえておく方法は、小規模開発の要件定義はどこまで必要？でも解説しています。
Tailboneでの確認の進め方
Tailboneでは、制作を始める前に確認の担当者と日程の目安を一緒に決め、初回納品は実際に触って確認できる状態でお渡しします。フィードバックは一覧にまとめていただければ、事前に合意した範囲内で、実際に使える状態まで調整します。範囲を超える要望が出た場合は、作業前に内容と費用を別途ご相談します。
よくあるご質問
開発中に、どのくらいの時間を割く必要がありますか？
毎日の対応が必要になるわけではありませんが、開発会社からの質問への回答と、初回納品後の確認にはまとまった時間が必要です。特に初回納品の確認は、実際に操作しながら行うため、あらかじめ予定に入れておくことをおすすめします。
確認中に新しい要望を思いついたらどうすればよいですか？
合意した範囲内の調整なのか、範囲を超える追加なのかを分けて伝えると、話が進めやすくなります。範囲を超える要望は、今回入れるか、次の段階に回すかを、費用と期間を確認したうえで判断します。
不具合と要望の違いは何ですか？
一般的には、合意した内容のとおりに動かないものが不具合、合意した内容とは別に「こうしてほしい」と思うものが要望です。区別して伝えると、開発会社も対応の優先順位をつけやすくなります。