失敗を防ぐ「要件管理」 　I0929b

※プロジェクト管理の原点は、要件定義（業務仕様）から

〇要件定義とは
・主要目的は、「新システムの仕様を確定すること」
… ユーザの要望をまとめればよいと誤解しているひとがいる
・主要成果物は、「新業務仕様」で、顧客の承認が必要となる … 「要件一覧」のこと
… 業務を設計する「狙い」や「設計方針」だと勘違いしてはならない

 

〇要件定義の困難さの要因
・ユーザニーズそのものに潜む問題
~ 経営者のニーズは複雑で抽象的、業務も熟知しているわけでなく、システムの認識も曖昧なもの。

・効率化という視点の限界
~ 経営戦略の視点はもちろん、内部統制や業務管理の視点も必要で、業務効率化の視点だけでではありません。

・実現可能性の問題
~ 業務を遂行する人間の能力を忘れていたり、業務が運用できなかったり、現状業務をそのままシステム化してしまい効率が上がらない結果になったりします。
⇒ 人間への配慮を欠いたシステムは、ユーザ(経営者、担当者)が満足しません。
それだけではなく、経営者のポリシーに反する業務改善は拒否されるし、業務改善により部門や個人が既得権を失う場合には、抵抗されるものです。… 抵抗勢力の協力を取付けることも重要です。（要注意）

・業務知識の不足 … 要件を確定するには、ＳＥ自身が“業務知識”を身につける必要がある
＠ プロジェクトの成否にかかわると言っても過言ではない！

・“暗黙の要件”に気付かない
~「既存機能の継承」は”暗黙の了承”のうちにあるもので、気付かないと大切な要件が抜け落ちてしまう。
⇒ これが大きな失敗の原因となります。

 

〇プロジェクト遅延の際は、“業務仕様”に注目する
・既存システムの業務仕様の把握と機能継承が出来ているかどうか？
・新システムの設計方針が明確でなく、結果として新業務仕様が作成できない状態にあるかどうか？　とりもなおさず、要件が確定(顧客承認)されていないことだ！
・要件定義ができるスキルが不足していないかどうか？
~ 要件定義作業では、広範囲な能力が試されます。
~ 設計方針の理解と具体化能力、過去のプロジェクトで培われた設計能力、仕様確定の仕方など

 

◎システムの規模が大きくなると
・既存機能の多くが抜けてしまう“原因”は、個人の理解の限界を超え、頭の中に既存システム/業務の仕様が入り切らないからで・・・
~ 頭の中にある複数の仕様の整合性をとることは通常は難しいものです。

・現場も把握しにくい業務仕様がある
~ 膨大な画面・帳票を見ても既存機能の継承はできないし、まして、ユーザから見えない機能は把握できず、理解の遠く及ばない状態が発生してしまう。

・ 大規模プロジェクトの既存機能継承は、既存システムからの継承・移行が大半で
~ この作業を怠ると、プロジェクトは最初からやり直しになる危険性がある。
(注) 「ユーザからの要求のみを信じて新システムの仕様を確定させた」場合は、既存機能の大半は継承されていない！　と認識すべきだ。　（要注意）

 

●プロジェクト経験なしには身につかない能力
※プロジェクトの置かれた状態は一様ではないので、プロジェクトで直面する問題・課題・リスクはそれぞれ異なり、経験で培われた判断力・指導力・実行力が要求されるものです。

また、経験で身につく能力もあります　… 「経験知・暗黙知」といわれる要素が多い思われます。
・現状認識から、今後発生する結果を想定する能力
・時々の問題点を認識し、対応策を立案する能力
・プロジェクトメンバーを動かす能力
・極度の緊張状態でも自分を見失わない能力　など