ユースケース駆動開発を考えてみる
こんにちは、ようへいです。
風邪引いてしまい、やりたいことができません。
なので、色々と考え事をしています。
（大人しく寝てればいいものを・・・）
なぜシステム開発って失敗が多いんでしょう？
そんなことをぼんやりと考えた記事です。
これまでのシステム開発を振り返ってみると、顧客のニーズを正しく理解できずにスタートしたプロジェクトは、例に埋もれず炎上していたと思います。
例えば、、、
基本設計の時は紙面上では合意してたものの、受け入れテストで「やりたいことと違う」と多くの指摘。
これが塵積で工数がかさんでくると、納期に間に合わなくなったり、間に合わせる為の突貫工事となってしまい、品質課題へ。
その後は火を見るより明らかです。
ウォーターフォールモデルの開発の場合、上流工程から順に成果物を作っていきます。
この開発モデルは、工程ごとにきちんと成果物を完成させることが目的。
後戻りは（本来は）許されません。
経験上、上流工程に問題があるプロジェクトは炎上率は高いです。
それを少しでも下げるにはどうすべきか？
ことの発端は業務の理解不足である、と仮定した時、どうすれば業務の理解力は上がるでしょうか？
（即ち、設計品質が上がるか？）
自分なりの解としては、ユースケース駆動開発が使えるのでは？と思っています。
ユースケースを整理することで、その業務は誰がどんな目的で行うのか整理できます。
目的とプロセスがしっかり整理できるので、業務の本質を捉えた設計ができると思います。
故に、ユーザーニーズに沿ったシステム開発になるのでは、と考えました。
とは言えきっと、この開発モデルもメリット・デメリットがあると思います。
適切な開発規模もあると思います。
どんな開発規模・条件ならこの開発手法が適用できるか期待しつつ、この1冊を読んでみて、答え合わせしてみようかと思います。
この記事が気に入ったらサポートをしてみませんか？