〇要件定義とは
・主要目的は「新システムの仕様を確定すること」だが、ユーザの要望をまとめればよいと誤解しているひとがいる
・主要成果物は「新業務仕様」だが、業務を設計する「狙い」や「設計方針」だと勘違いしてはならない
設計方針は、既存システムや現行業務に対して、あくまでも変更すべき部分の設計方針を示しているに過ぎない

〇要件定義の困難さの要因
・ユーザニーズそのものに潜む問題
～経営者のニーズは複雑で抽象的、業務も熟知しているわけでなく、システムの認識も曖昧
・効率化という視点の限界
～経営戦略の視点はもちろん、内部統制や業務管理の視点も必要で、業務効率化の視点だけでではない
・実現可能性の問題
～業務を遂行する人間の能力を忘れていたり、業務が運用できなかったり、現状業務をそのままシステム化してしまい効率が上がらない結果になったりする
⇒ 人間への配慮を欠いたシステムは、ユーザ（経営者、担当者）の満足が得られない
それだけではなく、経営者のポリシーに反する業務改善は拒否されるし、業務改善により部門や個人が既得権を失う場合には抵抗されるものだ　・・・抵抗勢力の協力を取付けることも重要です（注）
・業務知識の不足
～要件を確定するには、ＳＥ自身が“業務知識”を身につけて、主体的にＩＴ機能を決定していかなければならないことになるが・・・、業務知識を吸収・習得することは難しいのが現状だが、非常に大事なこと
⇒　プロジェクトの成否にかかわると言っても過言ではない！

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

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

◎大規模システムの場合
・既存機能の多くが抜けてしまう“原因”は、
～個人の理解の限界を超え、頭の中に既存システム/業務の仕様が入り切らないからで、頭の中にある複数の仕様の整合性をとることは通常は難しいものなのだ
・現場も把握しにくい業務仕様がある
～膨大な画面・帳票を見ても既存機能の継承はできない
まして、ユーザから見えない機能は把握できず、理解の遠く及ばない状態が発生してしまう
大規模プロジェクトの既存機能継承は、既存システムからの継承・移行が大半であり、この作業を怠ると、プロジェクトは最初からやり直しになる危険性がある
「ユーザからの要求のみを信じて新システムの仕様を確定させて場合」は、既存機能の大半は継承されていないと認識すべきだ！ （注）

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

経験で身につく能力は、
・現状認識から、今後発生する結果を想定する能力
・時々の問題点を認識し、対応策を立案する能力
・プロジェクトメンバーを動かす能力
・極度の緊張状態でも自分を見失わない能力　など

【Ｎの流儀】 H0123.