【事例】新業務・現行踏襲のアプリケーション開発の１つの失敗例

まずはどうでもいい話。
本文とは何も関係ないが、自分のBlogが読みづらい。
読んでいて、まじむかつく。
なので他の読みやすいBlogを参考に分析した。
結果として、①事実→②分析→③自分の意見となる傾向があることが判明
自分も真似しようと思う。
だって、どうせ書くなら読みやすいほうがいいもんね（自己満足）。

さて、以下が本文。

現場の経験から

新業務の要件定義を担当している。
企業のシステム開発活動であり、使い手も企業内の人間なので、ユーザー部と企業の業務フローとともに議論を行っている。
しかしながら、設計も後数日といったところで、ユーザから要件追加があった。まぁベンダーとしては追加工数でウハウハなんだけど、そもそも論で言うと、要件定義に不備があったってことなんだよなぁと反省。

要件定義の漏れの原因

原因は何だったかというと業務フローを詳細まで抑えていなかったこと。
言い換えると、ユーザが既存の画面について熟知していることを前提としていたこと。
そのため、既存業務フローの踏襲として修正対象外としていた機能、実は一部が新業務フローにかわることが判明し、仕様を変更せざるおえなかった。

要件定義の粒度について

今までユーザが業務フローを書いて終わりだったのだが、たぶん、きっと、システム開発者も業務フローの粒度をシステム使用レベルで抑えるべ きなんだなと思った。いわゆる、ユースケースだったり、シーケンス図だったりするんだと思うんだが、この辺の知見を時間不足や工数不足でサボったのが本質 的な原因だったのだと思う。ついでにいうと、担当したプロジェクトは要件定義の期間が短かった。
というわけで、要件定義のフレームワークは重たいものであるということをクライアントのシステム部と共有する必要があるのだと感じた。しかしながら、システム部は要件定義を甘く見ている傾向があるため、それを如何に伝えるか、リードしていくかが課題である。

余談

うーん、事実、分析、解放と端的に書いてみたが、読んでみて面白くないな。コレは何故だろう。やっぱ、文章力とボケの力が不足しているのか。
くやすぃ。。。。

ではまた。