今週は台風で散々な目にあいました。こちら関東地方では最近お天道様を見ていません。これから本格的な秋を迎えますが、良い天気が続くといいですね。
前回は要件定義のプロセスで、現状業務フロー作成の必要性と作成した現状業務フローから、ビジネス課題と業務課題を導き出す際の視点、視野について考えました。
業務フローから何を導き出すのか、前回業務フローに時間の要素を付加することで、ビジネス価値を阻害している部分を見つけ易くなると言いました。
他にも、色々な分析手法があり、それについて考えるのは重要なことですが前回も言ったように、ここでは本論ではないので一旦脇に置いておくことにします。まずはテーマである、「要件定義の構造」について考えを進めて行きます。
これまで考えて来た「要件定義の構造」ですが、復習のためここらで一旦整理することにしましょう。
まず挙げたのは要件定義の最終段階でいかにシステムを利用するユーザーに、その内容を正確に伝えるかということでした。最終段階の問題を最初に持ってきたのは結局、要件定義の内容の良し悪しに関わらず、それをちゃんとユーザーが理解できないことがITシステム開発の大きな課題となるからです。
このことを逆に言うと、伝える開発者側がちゃんと正確に伝えきれていないということになります。
この”伝える”ことの難しさと、それを克服するためのアイデア、方法論について考えて行きました。
次に、要件定義作業における時系列による意識の階層について考えました。
第一階層はしかるべき人が持っている「なんとなくの感覚的な問題意識」で、第二階層はおの問題を解決するための「ビジネスの要求」でした。さらに、この要求を業務単位に落とし込んだ第三階層と続くことになります。
そしてこの第三階層で、まず最初に必要になるツールが”現状業務フロー”でした。
次回は現状業務フローから導きだした、改革、改善点にどう向き合うのかについて、考えを進めて行きます。