システム開発における「要件定義」と「見積もり」あるある話

ふとしたきっかけでとある会社の方からアプリ開発について相談したいというお話をいただきました。

今のご時世だったり、自身のバックグラウンド的にシステム関連の相談をよく受けるのですが「アプリ開発」と、その単語1つだけ聞くと

・何を

・どういう目的で

・どういう経緯で

・いつまでに

・いくらくらいかけて

作るのか？という疑問などがわっと頭の中に押し寄せてきます。

アプリやシステム開発をしよう！ということは決まっていても、これらの内容が綺麗にまとまっており、スムーズに進むケースは思った以上に少ないなというのが現状かと思います。

例えば「来店予約を管理できるアプリ」だったとします。

これが3ヶ月後までに欲しい、いくら以内で作って欲しいみたいな話だったりします。

詳細が決まってなかったり、なんでそれを管理したいのかとか具体的な話がなく、

「最近アプリ必要でしょ？アプリだったら予約入って売上あがるよね」

みたいな希望的観測のような漠然としたアプリ至上主義的なイメージ・考えで話がくることもあります。

そうなると目的だったり色々分解して本当に大事なものを見つけ出す作業をするのが困難になります。

思い込みやイメージが大きくずれているため、そこをすり合わせるのに苦労しますし、発案者の方のイメージと違うことを話すと「お前話わかってないな」みたいに思われたりもします。

極端な例ですが、そういうことも多々あるのでアプリ作りたいと言われると、同じアプリという単語でイメージするものが大きく違ったりするので慎重に話を聞かないと割と怖かったりします。

課題は物差しがないこと

ただ今回の相談者の方は予算がある程度しっかり組めており、作りたいもののイメージも概ねある、紙でやっていたものをデジタル化してオペレーションのコストカットや情報管理をしやすくしたいなど内容もしっかりしています。

また開発依頼先も名があるところに見積もりをお願いしてほぼ依頼することは確定していました。

素晴らしい、ここまで良い条件が揃っているのはあまりなく、相談すらも必要ないのではないかと思いました。

ただ相談者の方からは「私たちはシステム開発をしたこともなければ知見もない、相手から出てきた見積もりが高いか安いかも測る物差しがない。なのでそこを助けていただきたい」という申し出でした。

素直に凄く出来る方なんだなと思いました。

ご自身の専門領域でない部分の「分からないこと」を「分かっている」というこの１つの点を、へりくだることもなければ下手に知ったかぶりをしてマウントを取るようなこともしないのは、素直素晴らしいなと思いました。

ビジネスをされている方は何かしらの分野で特出していたり、経験が色々あるため、不慣れなシステム関連のお話でも「そんなことは分かっている！」や、「言った通りにやってくれたらいいんだ！」などおっしゃられる方が多かったりします。

そんな中で、素直に分からないことを聞いていただける素直さがあるため、おそらく私が何もお手伝いしなくてもプロジェクトはスタートし、そこまで大きな失敗なく進むと思います。

また、お金で解決出来てしまえそうな企業体力もありそうです。

ですが、分からないまま進むことはリスクだと感じられてるようですし、予算に関しても決して厳しいわけでないですがゆるいわけでもない。

しっかりと会社の社員の方々が日々の努力から生まれた利益から出される貴重な資源であることも理解されています。

個人的にはそういう方々をご支援し、不透明なIT予算が無駄に流れる可能性を下げて、分からないままシステム開発会社の言われた通りになってしまったりすることにならないようにしたいという思いが強くあるのでご協力させていただくことにしました。

私の役割

基本的に役割としては、社内で何を決めるとシステム開発会社側とコミュニケーションが取りやすくなるかという点の洗い出し、漠然とした全体ゴールではなく本当に最小単位でいけそうなものとそうでないものの仕分け、それに対してシステム開発会社が提示してくれるスケジュールと見積もりに対してのフィードバックです。

システムの見積もりの難しさ

特にお金面は大事です。

将来的なことややりたいこと、構想レベルなものまであるので、最初の絵が大きいとリスクヘッジも含めて基本的にシステムの見積もりは大きく返ってきます。当初出てきたのが何千万という見積もりでした。

ただこれもシステム開発会社側としても、見積もり時は車が欲しいから作って欲しいと言われ、軽自動車なのかワゴン車なのかスポーツカーレベルなのか100%分かっているわけでありません。

これで軽自動車の金額で見積もりを出して契約してしまい、万が一あとで「スポーツカーが欲しかったんだ！」と言われても困ります。

そういった認識のすり合わせを事前に100%できれば問題はないのですが、いかんせん形があるものが出てくるわけでなく無形資産というイマイチ目に見えない、対象のものが見る人によって同じように認識できないものに対しての価値の定義は本当に難しいです。

パッと見凄い華やかで過ごそうに見えても裏側はボロボロでバグだらけ、最悪システム停止するようなくらいの品質の場合と、見た目は簡素で特段華やかでない、ただし裏では人がやる仕事を最小限に出来るようにしっかりとした仕組み・処理が動いている場合、後者の方がシステム自体の価値も事業に与えるインパクトという点でも価値がありますが、それがパッと見では全く分からないのです。

なので分からないままにシステム開発をお願いして、出てきたものが見た目だけまともであれば良しというわけではありません。

いきなり大きなものを描くのではなく本当に必要なものだけを取り出して、小さく作れること考えます。

小さく作ることの大切さ

小さくともどういった情報をどう扱うか、見るもの（デバイス）がパソコンからなのかスマホからなのか、誰がどういうタイミングで使うかなど色々考えると小さいシステムであっても考えることは無数にあります。

特にシステムを使うのは人なので、使う時のことを第一に考える必要があります。

小さく、そして必要なことを考えて洗い出してみるとそれだけでも割と多くのことが出てきますが、全体把握できない規模ではなければ、見積もりの範囲・精度もあがりますし何よりスケジュールも立てやすくなります。

こうしてリスクを減らしたなかで、作りたいものの要件を出してまとめたり、それを実際に作ってもらうことを繰り返していくと社内にも知見がたまり、システム開発会社とのコミュニケーションも取りやすくなると思います。

そこまでいけたら一安心です。

これが分からないままに丸投げ依頼してできたものを待つばかり、それが思ったのと違う！請求金額は高い！！みたいなことになってしまいやすいのです。

その後に

最初漠然と大きく描いていたものだと見積もりが何千万という単位で来てしまっていましたが、小さく作ることで1/10程度になり、必要なものがクリアになったことからスムーズに最初のシステムが出来上がりました。

小さくシンプルなためバグ等もそこまでなく出来上がったものを実際の現場に使ってもらいフィードバックを集め、次のフェーズの開発に進むようです。

これがもともと最初の漠然としたものを依頼して出てきた見積もりを「分からないけどそうなのか仕方ないのかな・・・」と思って納得してしまっていたら最初の完成もかなり先になっていたでしょうし、途中の変更もしづらくなっていたかと思います。

システムは分からないことが難しさ・複雑さになってしまうので出来るだけシンプルにできないかと考えて、分かるシステムを作れることを今後も大切にしてもらえたらどんどん良くなると信じています。

このようなケースは多々あると思うので、同じようなお悩みやお困りごとがあれば気軽に相談いただければと思います。