システム開発において「これをつくる!」に至る前の、見積もりと考慮すべきこと プロジェクト

システム開発において「これをつくる!」に至る前の、見積もりと考慮すべきこと。

「それできますね」という前に、以下の4つは考慮したほうがいいというもの。

これらを事前に頭に描いてないと、なかなか開発のゴーサインがだせないけど、
実際は見切り発車してる現場が多い。結果、使いにくくて、不満が多いシステムができあがったりする。
しかし、わがままなユーザはそこまでもとめてることが多い。
これらを考える機会があったので忘れないように自分用にもメモ。

少なくとも以下の4つの考慮が必要

■サマリ
・1 その機能は技術的に実現可能なのか。その方法論は最適なのか。
・2 業務システム全体として組み込み可能なのか
・3 限られた資源の中で実現可能なのか
・4 いい感じで使いやすいのか


■詳細説明
・1 その機能は技術的に実現可能なのか。その方法論は最適なのか。
この機能はそもそも技術的につくることはできるのか
あと実現できるけど、効率の悪いシステムを構築しようとしてないか。
例)webシステム構築すれば簡単に実現できるのに、windowsクライアント側にRPAツールぶっこんで
結果、使いにくい野良自動化ツールをつくろうとしてないか


・2 業務システム全体として組み込み可能なのか
単体レベルでなく、全体感として無理なく組み込み可能なのか。
なので判断するためには連携する他システムのことも技術レベルで知っておくことが必要となる。
例)他システムと連携する場合に他システムがapi対応してないので、つくっても組み込めないなど。


・3 限られた資源の中で実現可能なのか
自分たちの限られた資源で、照準を合わせてピントを合わせたシステム構築ができるのか
- 時間(期限):1年ぐらいでできるならOK。5年、10年かかるならNG
- お金(予算):数百万円~5000万円ぐらいでできるならOK。10億、100億とか必要ならNG
- 人:2 3人ならOK。50人 100人いないとできないならNG


・4 いい感じで使いやすいのか
機能として実現できるかもしれないけど、ものすごくわかりにくいとかはNG。
昔のガラケーみたいに機能はあるけど、誰も知らないし、説明書に書いてあったとしてもわかりにくいとか。
直観的に使いやすいのか。



それいつまでに、できますね!という前に
そのスケジュールで上記を納得のいく範囲で実現可能なのかを把握しておかないと危険。
またできないなら、早い時点でその理由を具体的に落とし込んで、説明する。(ごり押しされそうなら撤退する)
たまにExcelやsalesforceやoktaみたいなの自前でゼロからつくって、でもお金はないよ。
みたいな無理難題言ってるの気づいてないユーザがいるのでやばい。


あとこれらはシステムを発注するユーザ側にも求められるスキルでもある。
エンジニア側から今の技術なら低価格でこれできますね、とはなかなか言いにくい。
なぜならできなかった場合のリスクが生じるから。

一方、それやりましょうとコンサルがもちかけてくる場合があるが、彼らは
実際の開発工程にはすでに高いコンサル料だけとって、とんずらしてる場合もある。

なのでこれらはエンドユーザ側も把握しておくべきだし、できないならシステム開発を
外注するのではなく、自社で(高い給料払っても)エンジニアをかかえこまないとその判断は難しいと思う。