要件定義におけるタスク
要件定義とは
要件定義はIT導入・システム開発において、最重要工程と言えます。
というのは、プロジェクトの失敗は要件定義の問題が多いからです。
要件定義とは、ITとして実現したい要求に対し、どのように実現するかを要件として定義することです。
定義するということは、どうするかを決めるということになります。
方向性を決めるのはなく、どう実現するかを決めるということになります。この違いは立ち会った人でないとわからないかもしれません。
大抵は決めきれずに設計工程持ち越しがいくつか発生します。
ある程度持ち越しは発生しますが、最大限マネジメントにより防ぎたいところです。
要件定義のタスク
前段階の確認
要件定義のゴールはシステム化要件定義が確定していることです。
要件には業務要件もあります。業務としてどう実現するかを決めることです。
業務要件は、前段階で決まっていることが前提となります。
しかし、業務要件が明確でないまま、要件定義を進めることになることがあります。
そのようなことをできるだけ防ぐために、要件定義前工程にて説明したタスクを実行しておきます。
もし、できていないことが確認されたのであれば、前段階から始めないといけません。そうしないと要件定義としての目的がぶれてしまい、結果要件変更が後から発生する原因となります。
前段階が終わっている前提で、以下タスクを進めていくことになります。
機能要件定義
機能として実現すべきものを定義します。
どのように実現するかと同時に、実現できないものも定義します。
実現できない者は制約事項になるので、その点も定義します。
コード・マスタ・データ要件定義
コード体系について決める必要があるのであれば、決めます。
多くの場合は、既存ITとのデータ連携やデータ結合のためにコード体系を合わせることが必要となります。
何も考えていないと、連動できないITシステムとなってしまい、あとから苦労します。
また、マスタや主要データのコードや属性に関するデータ要件についても定義していきます。
この作業は設計工程では遅いです。
機能要件と同時に決めていかないと、設計上の矛盾が多く発生します。
非機能要件定義
非機能要件は、可用性、性能、拡張性、運用・保守性、移行性、セキュリティなどです。
可用性はどれだけ稼働できるかです。システム構成に関係してきます。
その他、使うための機能ではないが、ITシステムとして決めておくべきものということになります。
セキュリティ要件定義
セキュリティはITシステム構築にあたっては、重要な要素となっています。
個人情報を普通に扱っている企業は多いです。
リスクに応じた対策・方式を決めます。
システム方式
ITシステムを実現するために、ハードウェア、ネットワーク、ソフトウェア、サービスといった要素の組み合わせと構成を決定します。
方式を決定するにあたっては、技術評価の上決定することになります。
開発手法
今回のITシステムの特性を踏まえて、開発手法についてウォーターフォールかアジャイルか、またどのような工程やサイクルとするかを決めます。
既存ITが比較的大規模で、既存をベースに構築するようなケースはウォーターフォールとなります。
新規開発で要求に不確実性があるのであれば、アジャイルとなります。
運用・サービス要件
非機能要件の一部ではありますが、重要になりますので切り出して記載しています。
移行要件
移行も非機能要件の一部ですが、極めて重要ですので、切り出しています。
移行に関する要件は、いざ移行する段階となって発注側と受注側のITベンダーで揉めることがあります。
それは、ITベンダーは新たなITシステムを構築する責任はあるが、旧システムから新システムへ移行するのは、発注側の仕事であると認識していることがあるからです。
実態は、認識はしているものの、新システム構築が間に合っておらず、移行まで手が回らなくなっているだけの場合もあります。
責任分担の意味においても、移行設計は誰が実行するかもきちんと決めておく必要があります。
内容としては、まず大きいのは移行による影響を想定し、対応策を定義することです。
そして、移行対象の明確化です。その中でも移行データの扱いについては、特に注意が必要です。
移行データは旧システムや業務で利用しているデータから移行するケースが多いです。
その場合、ITベンダーは発注側作業を認識し、何もしないことがあり得ます。
データは、抽出、変換・加工、投入という作業に分かれますが、一連の者として設計しないと、まともに移行できません。
一流ベンダーであっても、移行元データをすべて把握することは困難なため、苦戦を強いられます。
よって、要件定義段階で、どのように移行していくかを精度高く決めておきたいところです。
ところが、得てして機能要件の定義に時間を取られて、移行が疎かになることが多いです。
プロジェクト計画のタスク
要件定義と同時に、以後のプロジェクト計画について決定していくことが多いです。
タスク内容としては以下です。
スケジュール計画
スケジュールは日付を伴うものです。
工程のスケジュールと同時に、重要会議等のイベントもマイルストンとして定義します。
リソース・要員計画
プロジェクトで必要な外部調達のリソースを決めます。
内部の要員についても、プロジェクトマネージャを始めとして決定します。
コスト計画
費用を見積り、予算を策定します。
また、いつ支出が発生するかを計画します。
品質管理計画
どのように品質を保証するために管理していくかを決定します。
発注側としては、受注側のITベンダーがどのように品質保証するかを提示させます。
リスク管理計画
リスクを抽出し、分類し、優先度を決めます。
場合により、リスク対策のタスクを起こし、実行計画を策定します。
リスクの一覧は、以後監視し、発生したらどうするかを決めておきます。
また監視の頻度や管理方法について計画します。
コミュニケーション計画
体制に応じた会議体制を決めます。
また会議以外においても、意思決定方法や、日常のコミュニケーション方法についても計画します。
ツールや情報共有方法なども、後々生産性に響いてきますので、計画しておきます。
要件定義およびプロジェクト計画におけるマネジメント
要件定義は構想・企画という目に見えない状態から、実物に移していく最初の工程であり、重要な位置づけとなります。
また、以降の本格的な構築工程の前段階での重要な位置づけとなります。
マネジメントという段取りをうまくもっていかないと、以後進めていくにあたって大きな欠陥を生み出す可能性があります。
キックオフ会議の開催
要件定義はいよいよ始めるぞ、という段階となりますし、発注側としては適確な情報を出し、適確な判断をしていかないといけないので、関係者の意識を合わせていかないといけません。
よって、始めるという合図をキックオフ会議として実行します。
その場では目的を関係者で共有し、皆が目的に迎えるようにします。
もちろん、その場では今後どのようなことをしていくかという段取りを共有する必要がありますので、会議の日までに段取りを取りまとめる必要があります。
要件定義・計画タスクの計画
検討論点会議の設定
要件定義と計画のフェーズをどのように実行していくのかを計画します。
要求一覧は既にできているものとして、検討論点を見出します。
検討論点はレベルの違いが出てきますので、多くて3レベルくらいで見ておきます。
要求から機能を間違いなく導き出せるものは、論点が一つという扱いになります。しかし、論点というからには、検討事項があるものがおおいです。
一つの機能を決めるにあたっても、方法としては3通り考えられて、それぞれ検討の上でないと結論が出せないということであれば、論点が３つあることになります。
検討論点の数と検討から結論までの時間を想定し、検討会議回数を設定します。
関係する人たちを考慮して、会議に出られない等の問題が出ないように設定します。
発散と収束の計画
すべての論点を検討しても、さらに論点が増えることがあります。
プロジェクトを始めると発散するからですが、発散は要件定義においては必要なプロセスです。
一旦発散しないと、決まったことになんとなく不満や不十分さが残り、後から発散の種になってしまいます。
一旦発散させてから収束に向かうという計画にします。
よって、発散しそうな検討論点を先に持ってくるようにします。
並行検討事項の計画
検討論点と並行して、調査等の作業で進められるタスクもあります。
並行して進められるものは進めるよう計画します。
最終承認の計画
発散し収束させ、最終確定に持っていくように全体計画を行います。
最終確定は後述しますが、期間が必要なので、収束させるように計画して必要があります。
要件ヒアリング・検討論点会議の実行監視
会議については当初計画を立てたものに対して、こなしている数を見てマネジメントとしての監視を行います。
ただし、会議の実行数だけでは本当の進捗になっていないかもしれません。
会議は終わっても論点が未完了になっているものがあるかもしれません。
よって、会議の数だけではく、検討すべき論点もカウントして定量的に追っていきます。
もし、予定どおりこなせていなかったら、原因分析により対策が必要です。
調査タスクとレビュー会議の実行監視
ヒアリングや検討の会議の他には、調査タスクがあります。
調査については調査期間を見積り、計画します。
それに加え、調査結果をレビューにより精査し、他のタスクとの整合をとるという行為が必要です。
よって、調査を期限まで行っているわけには行けません。
計画として、調査の目的を果たすタスクを組み込んで、予め調査が終わるよう計画します。
計画に基づいて、進捗を監視しマネジメントします。
調査については、終わるまで進捗がわからないという問題があります。
調査を一つとっても、詳細に見ると、3つ調査してから、共通項により調査することで完了する、といったように分けられることが多いです。
よって、詳細調査項目の数にて確認すべきです。
課題のマネジメント
IT導入・システム開発全般のプロジェクトにて重要なことではありますが、特に要件定義において重要なマネジメントがあります。
それは課題のマネジメントです。
要件定義においては、発散と収束が重要ですが、その状況を測るのは課題の状況でもあります。
課題が発生して当然ということです。
課題の数が出し切れていないと、その後収束しません。設計以降で課題が噴出することになります。
よって、課題の状況を監視し、マネジメントする必要があります。
課題はリストで管理し、終わったら減っていくことをビジュアルで分かるようにします。
課題一つひとつはタスクとなりますので、タスクとして進捗度合いを定期的に確認していきます。
本来タスクに加えて発生しているため、放置されている可能性もあります。
そのようなことがないよう、協業化を図り、対応していきます。
要件定義においては、課題によっては新たな論点発生となります。
そして、タスクとして数件に1件の割合で、大きなものになります。
大きな課題は、解決をステップとしてタスクを組みます。
現状把握、解決の選択肢、選択肢のメリットデメリット検討、結果合意といったステップに分けて進捗を見ます。
場合によっては、中間での資料作成、会議設定も含めてタスクとして認識する必要があります。
最終レビューと承認のマネジメント
要件定義は全体として要件定義書が成果物となります。
以後のプロジェクト計画も成果物となります。
これらが意味するところは、以後の工程における拠り所になることです。
構築工程については多くは請負となります。それはやるべきことが確定しているからです。
確定しているということは、それ以外のことが発生すると変更になるということです。
変更の元になるものが要件定義書になります。
つまりそのつもりで、完成させ、オーナーの承認を得る必要があるということになります。
完成した次の日に見て完了、ということにはならないです。
よって、最終レビューを計画し、最終期日までに確実に終わらせるようマネジメントします。
要件定義およびプロジェクト計画でのありがちな問題
ITベンダーの提案してきた期間だとほぼ遅延してしまう
要件定義期間を含めて全体の計画をITベンダーが提案してきたときに、そのまま鵜呑みにするのは危険なことが多いです。
というのは、開発規模から見て、要件定義の規模と期間はこのくらいだ、という指標に基づいて出してきているからです。
要件定義前段階では、要求一覧や企画書がインプットとなります。
それらがそれなりに仕上がっているように見えるとなおさら要件定義の規模見積は甘くなります。
ようするに、ほぼやることは決まっているから、設計に入れるように確認するだけだ、と思ってしまっていることです。
しかし、実際は、検討すべきことが多くあり、時間が掛かってしまうことがあります。
なにより、ITベンダー側は専任者が対応するのに対し、発注側の事業会社のほうは、専任で対応できるとは限りません。
むしろ専任でできないことのほうが多いのではないでしょうか。
専任ではない中で、内部関係者の会議設定や、合意形成そして経営者承認まで考えると、思ったより時間は経っていきます。
よって、設計までにちょっと確認するレベルでは済まないことのほうが多いはずです。
あまりに過少計画になっていると、後から大変なことになります。
終わらなし、決まらないし、高くつくということになってしまいますので、発注側は自分たちがどのくらい仕事ができるかを考えたうえで、計画を立てるように是正しましょう。
要求が広がってしまう
要求は初めに取り決められていたはずでしたが、要件定義を実施している段階で広がってしまうことはよくあります。
要求の取り決めにおける精度にもよってくることなのですが、検討していくうちに要求が広がってしまうということは、一定量以上はありえることとして計画しないといけません。
要求、要件、設計は、何をしたいか、どう実現するか、どう作るか、という観点で詳細化して決めていきます。
特に、本工程であるどう実現するかという段階は、間にある位置づけであり、要求側とエンジニア側で歩み寄って決めないといけません。本来エンジニア側が歩み寄らないといけませんが、要求は自社の仕事を背景としてものであり、その人しかわからないということも多々あります。
よって、どう実現するかということを考えている内に、そんなこともできるのであればもっとこうしたい、というような発想が出てきてしまい、要求が広がることとなります。
この事象は防ぎようがありませんので、計画として一回話せば決まると思わず、３つのうち一つは検討幅が広がると思って、予定しておくことにこしたことはありません。
当初考えていた予算を大幅に超えそう
先に説明した、要求が広がってしまうということは予算超過に直結します。
要求はそもそもやりたいことが増えたということですので、大幅な増加となりますし、目立ちますので話題となります。
ところが、目立たずに、増えてしまうのは要件が増えているということです。
要求と要件の増え方は少し違います。
ある要求に対して、要件がふえるというのは、実現の方法によって機能が増えていくことになります。
したいことは大きな意味では変わらないので、少しずつ増えてくるイメージとなります。
しかし、この増加分はコストに影響してきます。
発生した要件はカウントし、最終的にどこまで実現するかを確定しなければなりません。
途中経過においても、要件が増えている傾向であれば、実施すべきかどうかの判断をするポイントを設ける等で、予算のコントロールをしたいところです。
課題解決が中途半端で終わりを迎えてしまう
課題は発生状況と解決状況をマネジメントしながら、すべて解決していきたいところです。
ところが、やはり解決が間に合わなくなってしまうことはよくあります。
解決していない場合、申し送り事項として、引き続き検討していくことになりますが、往々にして次の段階に入ってしまうと、解決のスピードはますます遅くなってしまいます。
課題解決のタスクは難しいものが残ってしまいがちです。
元々進めようとしていたタスクもあるので、プロジェクト進行は困難なものとなっていきます。
結果、中途半端に終了となり申し送りとなってしまうと、後からますます仕事を増やしてしまいますので、課題解決タスクの優先順位は謝らないようにしたいです。
また、困難なタスクは解決のステップと担当を分けてタスク化し、少しでも前に進められるようコントロールし、未解決を防ぎたいところです。
最終承認と構築の開始承認の段取りが悪く、次が始まらない
要件定義書の最終承認についてはやるべきタスクとして説明してきました。
最終承認においては、以後のベースラインとなるため、実施範囲、期間、コストについて一旦確定となります。
よって、厳密な確認の上、最終承認となるはずです。
要件定義の確定から以後の構築フェーズでは間が開くケースがあります。それは判断と意思決定に時間を要する点と特にITベンダー側の立ち上げ準備によります。
しかしいつまでも伸ばしていては次が始まりません。
時期を逸すると、ITベンダー側も体制を確保できず、提示したコスト・期間での実施ができなくなる可能性があります。
意思決定が発注者側の責務であれば、責務を果たすべく、次のフェーズへの移行も見据えて計画・段取りを組まないといけません。
とはいいつつ、受注者側の責務のケースも実は多々あります。
というのは、意思決定のための情報はITベンダーにて提示されているものが多いからです。
例えば、コストが膨らみかけていたとすると、要件別になったコストを見て実施する範囲を決めたいところです。
ところが、全体ではコストが出ていても要件別には出ておらず、コスト分析に時間を要するといったケースです。
意思決定に必要な情報のとりまとめについても、タスクとして計画しておかないと結果、次が始まらない状況になりますので気を付けましょう。
最後に慌てて段取りして、結果次が始まらない状況に陥らないためには、意思決定に必要なことを途中時点で決定できる場を設けることです。
要件定義およびプロジェクト計画で本当にやるべきこと
要件定義は、何を実現するのか、どうしていくかということを確定することです。
よって以後確定されたことに従って実行するベースとなるものです。
しかし、多くの失敗プロジェクトの事例において、要件定義の漏れや検討不足ということが原因となっています。
それだけ、確定させることが難しいものとなります。
しかし、確定させることはよく知っているメンバであればやれなくはないことです。
一定規模を超えてくるとよく知っていることを超えた要件が出てくるため、確定が困難となります。
一定規模は課題が発生することを想定し、計画し対処していくしかありません。
また、その確定のための行為は、設計以降の開発、テスト段階においても発生しえます。要件不明確や要件変更といったことが続くからです。
発注側の稼働と確定段取りを考慮したスケジュール設定や、途中経過における確定状況の確認といったことを行いつつ、プロジェクトを成功に導きましょう。
コメント