PR

 ユーザーから一貫した網羅性のある要件を引き出すことは難しい。To-be(理想)のビジネス要件定義からシステム要件につなげる際に,例外なくシステムの網羅性,整合性といった問題に突き当たる。

 要件定義フェーズでこの問題が見過ごされた場合は,下流フェーズで露見した際に,要件の再確認から設計,開発,テストのやり直しが不可欠となる。大きな手戻りとしてプロジェクトに跳ね返ってくるのだ。エンジニアは要件を伝えなかったユーザーの責任と唱え,ユーザー側は現行機能が保証されるのは当然と主張する。

 ユーザーがシステムのすべてを把握していると考えるのには無理がある。特に大規模システムの場合,過去に幾度となく改修が施され,ブラックボックス化しているケースが大半である。システム運用を実施している担当者でさえ,全容を把握し切れていないのが実態なのだ。To-beモデルからシステム要件を導くだけでなく,現行業務や現行システムの調査を綿密に実施することが極めて重要である。だが,現実には現行調査が軽視されたり,回避されたりする。その理由は,ブラックボックス化してしまったシステムの調査には多くの工数が必要なので,コストと時間がかかることにある。

問題発生を抑えるには「急がば回れ」

 ブラックボックス化したシステムでは,仕様書に不備がある(あるいは仕様書がない),運用担当者の頭の中に仕様があるといったことが常である。プロジェクトが投資できるリソースには限りがあり,現行システムをソースコードから文書化するのは非現実的といえよう。

 効率よく,確実に分析するには,UMLやDOA(Data Oriented Approach:データ中心アプローチ)などの手法を適用するとよいだろう。システムが変わっても適用業務で取り扱うデータ項目はほとんど変わらない,という考え方があてはまるなら,DOAを用いることにメリットが生じる。DOAによる分析結果を新論理モデルのインプットとして,要件定義作業に活用できるからである(図6)。なお,一般に現行分析手法を検討するときは,要件定義に適用するメソドロジを選ぶと作業効率が高まる。

図6●原稿調査におけるDOAアウトプット
図6●原稿調査におけるDOAアウトプット

 コストや時間に制約があるとしても,問題発生を抑えるには,現行調査は避けられない作業だと認識する必要がある。「急がば回れ」だ。現行調査の効果は,ユーザーから引き出した要件の整合性や網羅性を補えたり,現行機能を把握できたりすることにとどまらない。次のような目的をかなえるためにも不可欠だ。

●現行業務,現行システムの問題点を浮かび上がらせ,その解決策を検討するため
●移行設計(業務移行,システム移行,データ移行,運用移行)を行うため
●ROI(Return On Investment)測定の定量的評価基準を作成するため
●対象業務全体のシステム規模を把握するため

 現行システムがブラックボックス化しているという理由から,To-beのモデルで要件定義を進めた結果,移行処理で苦労するプロジェクトは多い。下流工程で現行調査の必要性に直面しないよう,要件定義フェーズで計画的に実施することが大切である。

村石 岳嗣(むらいし たけし)
日本IBM マネジャー エグゼクティブPM
1989年にキャリア採用で日本IBMに入社。複数のシステム構築プロジェクトでプロジェクト・マネージャを務める。PM学会代議員,PM学会リスクマネジメント研究会会員。著書(共著)に『プロジェクトマネジメント大全』(日経BP社)がある
水井 悦子(みずい えつこ)
日本IBM シニアPM
1996年にキャリア採用で日本IBMに入社。製造業や流通業の顧客を中心に,SIプロジェクト・マネージャとしてシステム企画,要件定義からデリバリーまでを担当。PM学会会員,PMI会員