既存システムの改善がビジネスの効果に結びつかないことがしばしば起こる。その大きな原因の一つは、要望をそのままシステムに反映することにある。重要なのは要望の分析。既存システム改善に特化した要件定義の手順を解説する。

 利用部門からの要望を受けて、ITエンジニアが残業もいとわず既存システムを改善したのに、追加した機能がほとんど使われない。あるいは、ビジネス上の効果に結びつかなかったり、同じような改善要望が繰り返し依頼されたりする―。ITの現場でよく見られる光景である。

 このような状況が発生する原因は大きく二つある。一つは、利用部門が既存システム改善(保守開発)の要望を十分に吟味しないまま依頼してくること。もう一つは、開発担当あるいは運用担当(以降では両者を合わせて「ITチーム」と呼ぶ)が、依頼された要望をそのままシステム化してしまうことだ。つまり、既存システム改善における要件定義のやり方に、大きな原因がある。

 ビジネス上の効果につながる既存システム改善を行うには、ITチームが利用部門から依頼された要望の重要性や有効性を十分に理解、分析して、真に効果のある改善内容をシステム要件として決める必要がある。それには、要望の「分析」というステップを組み込んだ、要件定義の手順をしっかりと踏むことが必要だ。受け付けた要望の内容を必要に応じて利用部門に確認し、予算や人的リソースの空き状況から実施可否を決める、という一般的なやり方には「分析」のステップがない。これでは不十分である。

 筆者は現在、「要件定義チームジャパン」注1)という有志のコミュニティーに参加し、他の有識者と侃かん々かん諤がく々がくの議論を戦わせながら、要件定義の方法論を策定している。ここでは、そのコミュニティーで整理した「既存システム改善における要件定義の方法論」を紹介する。

この先は日経クロステック Active会員の登録が必要です

日経クロステック Activeは、IT/製造/建設各分野にかかわる企業向け製品・サービスについて、選択や導入を支援する情報サイトです。製品・サービス情報、導入事例などのコンテンツを多数掲載しています。初めてご覧になる際には、会員登録(無料)をお願いいたします。