このエントリーをはてなブックマークに追加LINEで送る

7.2. 要件定義プロセスにおける課題

ハッピィ・エンジニアリング表紙

 システムの欠陥の多くは、不正確な要求、誤解された要求、そして要件リークや要件クリープに起因している場合が多い。これらの「間違った」要求は、設計者の解釈によって設計書に反映され、実装されていく。2005年に発生した東京証券取引所でのシステム停止やみずほ証券による誤発注など、「システム障害」として語られるものであっても、その障害は、要件の抽出が甘かったためなのか、設計や実装に瑕疵が発生していたのか、あるいはテストが十分でなかったために障害として顕在化したのか、という点については十分な報道がなされていない。とはいえ、これが要件の抽出を原因としたものであったならば、責任はユーザ側が持たざるを得ない事故であったといえる。ユーザ企業側が要件定義プロセスをSIベンダに丸投げすることは、これほどのリスクを持つということを、再度認識しておかなければならないだろう。

 

 要件定義はユーザ企業の企画部門・システム部門・ユーザ部門、そしてSIベンダのプロジェクトマネージャ・システムアナリストなどの多くの関係者の共同作業ということになる。社会的な意味が大きいシステムや、一次災害が人命に関わるようなシステムでは、自分の立場による「勝手な」責任境界を作るわけにはいかない。

 

 しかし、現実的な問題として、ユーザ企業とSIベンダの両者では、要件定義プロセスは方法論や社内調整などのさまざまな課題への解決が急務とされているが、本質的な解決策に至ってはいないという側面がある。

 

 要件定義においては、以下のような問題を解決することが命題のひとつである。

 

  • ユーザとSIベンダとの考え方の違い
  • 要件定義そのものの難しさ
  • ユーザ企業側の体制
  • 変更管理
  • プロジェクトメンバへの徹底

 

登場人物

立場

エンドユーザ 日常的な業務はルーチンワーク化されており、業務の本質が見えにくい立場である。さらに、現状から大きく異なる業務体系には強い抵抗を感じる。
ユーザ企業のシステム担当者 業務への理解度は、あくまでも現行のシステムを通じての理解にとどまっている。業務の本質的な意味や本質とのギャップを理解するに至らない。
システム屋 システム構築に関してのみプロフェッショナル(ただし、レベルは人それぞれである);

表7-1 欲しいものが明確ではない理由

 

 このような状況における結果は明白である。システムのモデルが徐々にできあがっていく中で、少しずつ要件が明確になってくる。さらに、プロジェクト開始当初では誰もが想像していなかった要件が追加される。そして、実際のシステムと「本当の要件」とのギャップの発生を防ぐことはできない。

 

 実際のシステムと「本当の要件」とのギャップを埋められるのが、システムが完成した後だとすれば、解決策は次の2つに限定される。

 

  • BPRの徹底
  • 業務プロセスを最適化し、最適化された業務にマッチしたシステムを構築する。

  • 速く、安くシステム化する
  • まず、きちんと動くレベルのシステムを作り、保守プロジェクトでギャップをフィットさせるための活動を行う。

 

 業務プロセスを最適化し、それに合致するシステムを構築するのは、業務システム開発のあるべき姿ではある。しかし、雇用の流動性が高く、組織の改編に抵抗感の少ない米国ならともかく、日本でこれを実現することは非常に難しい。日本企業では、仕事のスタイルへの慣れや既得権益などから、やり方を変えることへの抵抗感は非常に強いものがある。

 

 

 

 

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

7.2. 要件定義プロセスにおける課題 ハッピィ・エンジニアリング関連ページ

7.1. 要件定義の重要性
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
7.3. 歴史的背景
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
7.4. 相互誤解
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
7.5. 要件定義プロセス
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
7.6. 要件定義の未来像
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング