要求開発は、システム開発の意思決定(予算決定やRFPの作成など)の前に行われるもので、従来のシステム開発の予備検討(フィジビリティスタディ)や要求定義・要件定義より上流の位置付け(超上流)になる。
企業から見ると、これまで経営戦略決定についてはビジネスコンサルティングがサービスを提供し、システムインテグレーターがシステム開発サービスを提供してきたが、この間には谷間があった。要求開発は、この谷間を埋める=「ビジネスとシステムをつなぐ」ための改善プロセスの一種という位置付けである。
一般にシステム開発部門が費やす時間と費用のうちの40%を再作業(手戻り)が占めているとされる。この手戻り作業の大半は、要件に対する欠陥の修正に集中している。最初に要件を把握することによって、開発コストを抑制し、ソフトウェア開発工程全般にわたってビジネス要求とITとの連携を確実にすることができる。
要件定義を詳細かつ正確に行うとともに要求変更をきちんと管理することが重要だ。それら要件定義・変更管理を支援するツールも各種提供されている。
(「月刊アイティセレクト」2007年4月号のトレンドフォーカス「事業戦略とシステム構築を融合させる『上流開発』の新発想」より)
- システムは出来上がったのに役立たず?――「上流設計」を考える
ITが経営に対する貢献を求められている昨今、「要求」を決めるプロセスの重要性が増している。「システムは出来上がったが役に立たない」という結果を招かないためには、どうすればよいか?
- 残された分厚い報告書――上流と下流の分断
外部コンサルタントの力を借りて自社の「あるべき姿」を描いた報告書を作成するケースは多い。しかしこれらは具体的には経営に役立てられないまま眠ってしまっていることもしばしばだ。
- 現場カイゼンは若手が担う――下流工程のエキスパートを自覚させる
若手社員が現場で取り組んでいる仕事は本当に「替わりの人間がいくらでもいる」仕事だろうか。上司も若手社員本人も気づかないが、実は現場のロスを改善するヒントを多く含んだ仕事なのかもしれない。早く卒業したい仕事をもう一度振り返る意義は大きい。
- システム開発を失敗させない“現実的な処方せん”とは?
昨今、大規模なシステム開発の現場において“失敗プロジェクト”が常態化していると聞く。“失敗プロジェクト”とは、目的そのものに到達できなかった、または、予算・期限を超過して終了したプロジェクトのことであるが、一体なぜ常態化するほど多くのプロジェクトが失敗してしまうのだろうか。
- “コミュニケーションネック社員”の存在をチェックする
情報連携における最も大きな問題点は、重要な情報の流れを阻害する“コミュニケーションネック社員”の存在である。彼らの行動様式が、どのようにプロジェクトに影響しているかを確認することも重要である。
Copyright© 2010 ITmedia, Inc. All Rights Reserved.