発注・外注の進め方
業務アプリ開発で失敗する会社の共通点｜発注前に避けたい落とし穴
時間と費用をかけて作った業務アプリが、現場で使われずに終わってしまう。開発の途中で仕様が変わり続け、予定より大幅に遅れる――業務アプリ開発のつまずきには、いくつかの共通したパターンがあります。そしてその多くは、技術の問題ではなく、発注前後の進め方に原因があります。代表的な5つの落とし穴と、発注前後にできる予防策を紹介します。
落とし穴1：目的が曖昧なまま始めてしまう
「業務を効率化したい」「DXを進めたい」という目的だけで開発を始めると、何を作れば成功なのかが関係者の間で共有されません。その結果、機能の追加や変更の判断がぶれ、範囲が膨らんだり、完成後に評価できなかったりします。
予防策：「どの業務の、どの作業が、どうなればよいか」を一文で書き出します。たとえば「問い合わせ対応の状況を1か所で確認でき、対応漏れがなくなる状態にしたい」のように、業務の言葉で書くのがポイントです。
落とし穴2：範囲が少しずつ膨らんでいく
開発を進めるうちに「ついでにこれも」「せっかくならあれも」と要望が増え、当初の範囲から大きく広がってしまうパターンです。範囲が広がれば、費用も期間も増え、最初に解決したかった課題への対応が遅れます。
予防策：「今回やらないこと」を最初に決め、後から出てきた要望は「次の段階の候補」として記録しておきます。今の範囲に入れるかどうかは、目的に照らして判断します。小さく始める進め方はWebアプリ開発を小さく始めるには？で紹介しています。
落とし穴3：実際に使う現場が関わらない
管理者や経営者だけで要件を決め、実際に入力する現場の担当者が開発に関わらないまま完成させてしまうパターンです。完成後に「この順番では入力しにくい」「この項目は現場では分からない」といった声が上がり、使われなくなることがあります。
予防策：要件を決める段階で、現場の担当者に今の業務の流れを聞きます。そして、初回納品の確認には、必ずしも全員でなくてよいので、日々使う担当者に参加してもらいます。
落とし穴4：確認とフィードバックが遅れる
開発会社から確認を求められても、社内の担当者が忙しく返答が遅れる。初回納品を受け取っても、しばらく触らないまま時間が過ぎる。こうした遅れが重なると、全体のスケジュールが延び、開発会社側も作業を進められなくなります。
予防策：窓口、最終判断者、確認担当を発注前に決め、初回納品の確認日を予定に入れておきます。フィードバックは気づいた順に小出しにするより、まとめて伝えるほうが手戻りが少なくなります。詳しくは開発を依頼したあと発注者がやることをご覧ください。
落とし穴5：公開後の運用を決めていない
完成して公開したものの、旧来のExcelでの管理も並行して続けている。使い方の問い合わせ先が決まっておらず、困った人が使わなくなる。改善の要望が出ても、誰に伝えればよいか分からない。公開後の運用が決まっていないと、仕組みは少しずつ使われなくなっていきます。
予防策：切り替え日以降は旧来の方法での入力をやめる、使い方の社内の問い合わせ先を決める、改善要望を集める場所と判断する人を決める。この3点を公開前に決めておきます。保守の考え方は小規模Webアプリの保守・運用費はどう考える？でも解説しています。
5つの落とし穴の早見表
| 落とし穴 | 起きやすい結果 | 主な予防策 |
|---|---|---|
| 目的が曖昧 | 判断がぶれ、評価できない | 業務の言葉で目的を一文にする |
| 範囲の膨張 | 費用・期間の増加 | 「今回やらないこと」を決める |
| 現場の不在 | 完成後に使われない | 現場の担当者に確認してもらう |
| 確認の遅れ | スケジュールの遅延 | 確認担当と確認日を先に決める |
| 運用の未決定 | 旧来の方法に戻る | 切り替えと問い合わせ先のルールを決める |
共通する予防策は「早く、小さく、確認する」
5つの落とし穴に共通して効果があるのが、最初の版を小さく作り、早い段階で実際に動くものを確認する進め方です。紙の資料や打ち合わせだけでは気づけない認識のずれも、実際に画面を触ると早い段階で見つかります。ずれに早く気づけば、修正の範囲も小さく済みます。
発注前に社内で決めておくべきことは、社内ツール開発を外注する前に決めておくべき7つのことにまとめています。
開発会社との関係でつまずくパターン
5つの落とし穴に加えて、開発会社との関係の中でつまずくパターンもあります。
「言わなくても分かってもらえる」と思ってしまう
業界の慣習や社内の常識は、開発会社にとっては初めて知ることです。「当然こうなるはず」と思っていることほど、言葉にして伝える必要があります。
専門用語が分からないまま進めてしまう
説明の中に分からない言葉があっても、そのままにして進めると、後で「そういう意味だったのか」となりがちです。分からない言葉は、その場で質問しましょう。分かりやすく説明してくれるかどうかも、依頼先を選ぶ判断材料になります。
決まったことを記録していない
打ち合わせで口頭で決めたことが記録されていないと、後で認識が食い違います。簡単なメモでもよいので、決まったことは文書にして双方で共有しましょう。
発注前に確認したいチェックリスト
- 目的を、業務の言葉で一文にしている
- 今回やらないことを決めている
- 現場の担当者が、要件の整理と確認に参加できる
- 窓口、最終判断者、確認担当が決まっている
- 初回納品の確認日を予定している
- 公開後の運用（切り替え日、問い合わせ先、要望の集め方）を考えている
うまくいっている開発の共通点
反対に、うまく進む開発には、目的が一文で共有されている、最初の版が小さい、現場の担当者が早い段階から触っている、確認とフィードバックが速い、といった共通点があります。どれも特別な技術ではなく、進め方の工夫で実現できることです。
早く触れる初回納品で、ずれを小さくします
Tailboneでは、要件を整理したうえで早い段階で初回納品を行い、実際に操作しながら確認していただきます。紙の資料だけでは気づけない認識のずれを、手戻りが小さいうちに見つけるための進め方です。初回納品後は、事前に合意した範囲内で、実際に使える状態まで調整します。
よくあるご質問
開発の途中で「思っていたものと違う」と感じたら、どうすればよいですか？
気づいた時点で、できるだけ早く伝えることが大切です。後になるほど修正の範囲が広がります。その際、何が違うのかを「この画面で、この操作をしたときに、こうなってほしい」と具体的に伝えると、認識のずれを解消しやすくなります。
失敗しにくい開発会社の選び方はありますか？
要件の整理に一緒に取り組んでくれるか、範囲について提案があるか、早い段階で動くものを見せてくれる進め方か、といった点が判断材料になります。依頼先の選び方は、別の記事で詳しく解説しています。
小さな社内ツールでも、ここまで準備が必要ですか？
規模が小さいほど準備は軽くて構いません。ただ、目的、範囲、確認する人の3点だけは、規模にかかわらず決めておくことをおすすめします。この3点が決まっているだけでも、多くのつまずきは避けられます。