名古屋の業務自動化システム開発、要件定義でよくあるすれ違い|中川区のエンジニアが見た失敗例

名古屋の業務自動化システム開発、要件定義でよくあるすれ違い|中川区のエンジニアが見た失敗例

半年かけて作った業務システムが、リリースから3ヶ月後にはほとんど誰も触っていなかった。こういう話を、これまで何度か聞いてきました。特定の会社の話ではなく、業種を問わずよく起きているパターンです。作った側は仕様通りに動くものを納品していて、機能的には何も間違っていない。それなのに使われない。この記事では、私が現場でよく見聞きする失敗のパターンを2つ取り上げ、なぜそれが起きるのか、どうすれば防げるのかを書いていきます。

Three professionals engaged in a collaborative office meeting with laptops and notes.
Photo by Tima Miroshnichenko on Pexels
目次

よくある失敗①:経営者の頭の中だけで仕様を決めてしまう

一番多いのがこのパターンです。発注する側の経営者や管理者が「こういう機能があれば便利だろう」とイメージを固め、そのイメージをそのまま開発会社に伝えて作ってもらう。しかし実際にその業務を毎日やっているのは現場のスタッフであり、経営者本人ではないケースがほとんどです。

結果として、経営者が便利だと思った機能と、現場が本当に困っている作業がずれてしまいます。私がヒアリングをする際は、依頼者本人だけでなく、実際にその業務を回している担当者に話を聞かせてもらうことをお願いしています。ここを飛ばすと、後になって「思っていたのと違う」という状態になりやすいです。

Team of professionals in office analyzing financial documents for business strategy.
Photo by Vlada Karpovich on Pexels

よくある失敗②:一度に全部を自動化しようとして開発が終わらない

もう一つは、欲張りすぎるパターンです。「どうせ作るなら、あの業務もこの業務も全部自動化してほしい」という要望はよく分かりますが、対象範囲が広がるほど要件定義(作りたいシステムに何ができればよいかを事前に整理し、関係者ですり合わせる工程)に時間がかかり、途中で仕様がぶれ、結果として開発期間も費用も膨らみます。最悪の場合、途中で予算が尽きて中途半端な形でリリースされることもあります。

私はこの相談を受けたとき、まず「今一番時間を取られている作業はどれですか」と聞くようにしています。範囲を絞って小さく作り、実際に使ってもらいながら次の範囲に広げていくほうが、結果的に無駄が少なく済みます。

Business professionals engaged in a strategic meeting in a modern office setting with natural light.
Photo by Vlada Karpovich on Pexels

本当に必要なものを見極めるという考え方

この話をすると、以前「アプリを作りたい」と相談を受けたときのことをよく思い出します。よくよく話を聞いてみると、アプリでなければいけない理由がなく、Webで十分に目的を果たせるケースでした。アプリ化はAppleの審査対応や初期費用の負担が大きく、必要がないなら止めたほうがいいと正直にお伝えしました。

業務自動化システムも同じで、「作れるからといって作るべきとは限らない」と私は考えています。お客様にとって不要なものは、たとえそれが売上になる話であっても勧めません。この判断ができるかどうかは、開発を依頼する相手を選ぶうえで意外と大きなポイントになります。

自分がまず使ってみるという開発の仕方

私はこれまで、note自動投稿ツールや売上自動報告bot、AIOチェッカー(AIの検索・要約に最適化されているかを確認するためのチェックツール)など、いくつかの自動化ツールを自作してきました。どれも最初から誰かに頼まれて作ったものではなく、自分がまず使いたいと思って作り、実際に自分で使ってみて、そのうえで需要がありそうならお客様にも提供する、という順番で開発しています。

この順番を守ると、机上の仕様だけでは気づけない使いにくさに自分で気づけます。業務自動化システムの要件定義でも、実際に手を動かす人の目線を通してから形にするという考え方は、規模の大小にかかわらず共通していると思います。

失敗しないための進め方

  • 対象の業務を1つか2つに絞ってから開発を始める
  • 実際にその業務をしている担当者にヒアリングの場を設ける
  • 完成形を待たず、途中の段階で一度触ってもらう

この3つを押さえるだけで、リリース後に「思っていたのと違う」となる可能性はかなり下げられます。

業務自動化システムの開発費用はどれくらいかかる?

結論から言うと、対象業務の範囲と既存システムとの連携の有無によって費用は大きく変わります。単純な入力作業の自動化やbot程度であれば数万円台から相談できる場合もありますが、既存の業務システムとAPI(異なるシステム同士がデータをやり取りするための仕組み)で連携するような開発になると、要件定義の工数だけでもそれなりの時間がかかります。私はまず「今どんな業務にどれくらいの時間を取られているか」を聞いたうえで、範囲を絞った見積もりを出すようにしています。安さだけで比較すると、後から範囲を広げるたびに追加費用がかさむことも多いので、最初の見積もりに何が含まれているかを確認しておくことをお勧めします。

制作会社・エンジニアを選ぶときの判断軸

判断軸は色々ありますが、私が特に大事だと思うのは次の2点です。

要件定義の前に、現場へのヒアリングを提案してくれるか

いきなり見積もりや仕様書から入る相手より、「実際に使う人の話を聞かせてください」と言ってくる相手のほうが、後々のずれが少ないです。

公開後も一緒に育てていく姿勢があるか

作って納品して終わりではなく、公開してからのほうが「思っていたのと違う」という声が出やすいものです。私は公開から3ヶ月間は、デザインや文言の修正を何度でも受け付ける形にしています。作ってみて初めて分かるずれがある前提で、安心して相談できる体制かどうかも確認しておくといいと思います。

まとめ

業務自動化システムの開発で起きる失敗の多くは、技術力の問題というより、仕様を決める段階でのすれ違いから起きています。経営者の理想だけで決めてしまわないこと、範囲を欲張りすぎないこと、この2つを意識するだけでも結果は変わってきます。

今すぐできることとして、まずは「毎日どの作業に一番時間を取られているか」を1つだけ紙に書き出してみてください。それが、要件定義の最初の一歩になります。書き出した内容を持って相談に来ていただければ、そこから一緒に範囲を絞って考えていきます。名古屋市中川区周辺で業務自動化やシステム開発を検討している方は、気軽にお声がけください。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

コメント

コメントする

目次