なぜ要件定義に入る前にやることがあるのか？
要件定義工程はIT導入・システム開発プロジェクトにおいて、後々問題の起因となる工程です。
要件定義は、やりたいことをどう実現するかを決める工程ですので、そこが間違っていると誤ったものが作られることになります。動かないという現象はまさに要件定義が誤っていたことが多いです。
要件定義は次回説明しますが、要求を要件として決めて定義していくことになります。
従って要求が決まっていないといけないわけですが、往々にして要求は曖昧さが残っています。
通常要件定義に着手すると、それなりに決められた工程の中で進めていくことになりますが、不十分さがそのまま進んでいってしまいがちです。
要件定義は設計の前段階ですので、それとなく出来上がったかのように見えて一旦完成となることはあります。しかしよく見ると設計に入る前段階として十分になっていないことがよく起こります。
したがって、要件定義をきちんと進めるためには、要件定義前に要件定義が進められる状態にしておく必要があります。
要件定義前に実施すべきことは、プロジェクトのタイプにより異なります。
要件定義前に実施すること
要件定義前に実施すべきことは、一言で言うとよりイメージを鮮明化するための行為です。
要件定義は、主に要求を提示した人からヒアリングにより、実現すべきものを具体化していきます。
要件定義前は、具体化のために、要求を提示した人以外からの情報も加える行為と言えます。
主なタスクは以下のとおりです。
- 要求のモデル化
- 概念検証
- お試し期間
- プロトタイプ
- 既存IT詳細調査
- フィット＆ギャップ分析
要求モデル化のタスクとマネジメント
要求モデルとは
要求のモデル化は、要件定義の中で実施されるべきものにも思われますが、要件定義が始まると疎かにされることがあります。
それは、モデル化がなされていなくても要件定義は進められなくもないからです。
しかし、モデル化が必要なのは、IT全体が整合性のとれたものであり、要求に漏れがないことを確認するものです。
要求を提示する人は気づかない要求があります。それは、明示的には見えないバックグランドの処理などです。
それらの要求も明確化していくためには、モデル化していくことで対応が可能です。
要求のフローモデル
モデル化の主だったものは業務フローです。
ただし、ITシステムを進めていくためのモデルとしては、システム化業務フローといったデータやシステムの関連と処理概要を組み合わせたものが、実現性を把握するのに役立ちます。
要求のデータモデル
またデータに関連するモデルもあります。ITユーザにとってデータは最も重要であり、その構造を理解することはITシステムを知る上でも重要です。よってデータの概念モデルも構築したほうがよいです。
パッケージソフトやクラウドサービスを使って、連携やカスタマイズで自分のITシステムを構築していくにあたっては、データの内部構造がブラックボックスとなっています。しかし、ブラックボックスなりに概念レベルのデータを把握し、さらに外部システムやカスタマイズ部分のデータとの関係をモデル化しておくことで、全体のデータ関連を整備することができます。
要求モデル化のマネジメント
要求モデル化は、要件定義前の企画段階にて行われているべきものですが、できていなければ工程として組み込んで対応したいです。
要件定義の前段階としてスケジュールを組み込んでマネジメントしていきます。
対象成果物を定義し、作成期間を設定します。
作成にあたっては、プロセスの基本である認知・展望、定義・計画、実行・作成、仕上・受入のプロセスに則り、タスクを計画していきます。
既存ITや周辺IT、パッケージ内部などの情報を認知し、モデル化すべき対象を展望します。
対象物を定めたら、作成物の作成に取り掛かります。
作成物は関係者でレビューを行い、全体像を確認します。対象の規模に寄りますが3回ぐらいレビューを設けておくべきです。
作成のプロセスが最も大きいですが、その前後プロセスを関係者含めてタスク化することで、確実に成果の完成に近づけることができます。
概念レベルモデルではありますが、要件定義着手前に確定すべきレベルにしないといけないので、漏れなく作成されるようマネジメントされる必要があります。
概念検証(POC)のタスクとマネジメント
要求を実現するにあたって、全く新しい技術要素を使うなど、先が見えにくいケースについては、概念検証（POC）という工程を経て実際のシステム開発に向かうことがあります。
ITベンダーが、自信がないので先にちょっとだけ作らせてほしいということがあるかもしれませんが、レベルの違う話なので注意すべきです。
この工程は本来やらなくていいものです。しかし、実際にやってみないとわからないということもあります。AIを使ったモデル作成ということになると、確実にできるかどうかはわからないこともあるでしょう。
実現性が担保できる方式や機能であれば、この工程はやらなくても進められるはずです。よって、本当に先進的で、開発することで他に売ることができるぐらいのこと以外は、やらなくていい方向を模索しましょう。
実行することになった場合は、コストをかけて実行することになりますので、きちんとマネジメントしていかないと、成果が出ないリスクがあります。
概念検証のコストが無駄になるばかりでなく、本当はできたのにできないと判断してしまった場合、プロジェクトそのものが頓挫になり、機会コストを逸失することにもなりかねません。
タスクの組み方としては、実現性の未確定度合いによります。
未確定度合いが大きいものについては、検証サイクルを3回など複数回設定します。
調査・検証等がある程度見えているものであれば、1回検証することを計画します。
検証サイクルごとに結果がどうなるかによって、次のサイクルはどうするかを決めておきます。
結果が想定通りで進むべき方向であればいいですが、芳しくなかった場合は、そこでやめるのか、もう1回チャレンジするのか等を決めておく必要があります。そうしないといつまで経っても終わらないということなります。
成果が出なくても諦めるという決断もありえます。
お試し期間のマネジメント
クラウドサービスなどにおいては、お試し期間が1カ月など設定されているケースがあります。
いくつかのサービスが候補になっていたり、ほぼ決めているものの、実際使ってみないとわからなかったりする場合は、お試し期間を最大限活用します。
お試し期間は大抵決まっているので、試しにやることを計画的に実行しないと結果が検証できません。
よって、実行し検証すべきタスクを決めます。
そしてタスクが期間内に実行されていることをマネジメントします。
最後は評価・決定プロセスとなります。その期間も確保したうえで、実行・検証を実行していかないと、終わらせられなくなりますので、タスクとして計画しましょう。
評価の観点としては、使い勝手や見た目の分かり易さといったものはありますが、機能網羅性が最も重要です。
こだわっている機能がなければその他機能の見た目が良くても意味がありません。
性能やバックアップなどの非機能についても重要ですが、必要な機能に比べればなんとかなることが多いです。
こだわっている機能が何なのかは、事前にわかっていないケースがあります。
というのは、自分たちは当たり前だと思っていることが、サービス側は当たり前じゃないことがあるからです。
よって、当たり前の中にも重要なプロセスがあるということを認識したうえで、要求一覧を作成しておくことが、お試し精度をあげるコツとなります。
プロトタイプのマネジメント
プロトタイプとは
プロトタイプは概念検証とも似ていますが、実際に一定の完成物を作成することが違います。もう一歩進めた工程と言えます。
プロトタイプは実現性についてはほぼ担保できていて、見た目や動きを早い段階で確認しておきたいという場面で作成されますので、要件定義や基本設計といった一連の開発行為に含まれるケースも多いかもしれません。
要件定義前に実施するということは、やはり実現性について確認しておく必要があるということですので、タスクを組んでマネジメントしておくことになります。
プロトタイプのマネジメント
プロトタイプはコストを掛けて実行するものです。ただ概念検証よりは結果がNGになるケースは少ないと思います。
どういった方向性にするかということを決定しておくことで、今後の工程がスムーズになるというほうが、目的として大きいです。
まずは、何を対象とし、何を作るかを決めるプロセスが最初となります。
そして作っていく計画を策定します。
次に作っていくスケジュールを立てます。
そして、検証・評価することになります。
プロトタイプは、できればその後実際に作るようにし、後の開発工数を下げるということを狙いとしたいです。
また対象とする機能は、核となる機能とすべきです。重要なプロセスを実行する機能であり、最も使うものになります。
重要なプロセスの機能は、得てして複雑で要求が多いものです。よって、すべてを作りきるのではなく、その中でもコアな部分を対象として作成することで、全体がよくイメージできるようになるようなことを目指します。
プロトタイプは完成しなくていいという考えから、ITベンダーのエンジニアが期待不足なものを納品してこないよう、品質のマネジメントもしていく必要があります。
既存IT詳細調査のマネジメント
既存ITが存在する場合には、新たにITを導入するにしても影響を受けるのは間違いありません。
要求を明確にしたと思っても、既存ITの隅々まで確認して要求を洗い出しているとは限りません。
わからないところは、既存ITどおりというのが、要求になります。
そのとおりではあるのですが、実際その後要件として具体化するにあたっては、既存ITとして実現されていることを明示的にしないといけません。
この工程を軽んじて大失敗に陥ったプロジェクトは多数あります。
既存ITに関わる要件漏れの問題は、発注側の問題と受注側の問題両方のケースがあります。
既存IT詳細調査では、既存ITで実装されている要件を洗い出すことです。
要件となるための漏れを確認すると同時に今回実現した要求と矛盾がないかも確認します。
実行するタスクの量は、既存ITの設計書や資産からボリュームを見極めます。
そしてスケジュールなどの計画を立てます。
調査にあたって課題は発生します。
それは既存のドキュメントが完全とは限らないからです。その場合実物を確認します。
そのことも含めて工数を見極めることになりますが、既存ITの規模が大きいと、その工数見極めのブレが大きくなるというリスクがあります。
フィット＆ギャップ分析のマネジメント
フィット＆ギャップのゴール
ERPなどのパッケージソフトを導入するケースでは、すでにある機能と業務とのフィットとギャップの分析を行います。
現状業務と新たな要求を含めた業務全体とパッケージの持つ機能が合うのかどうかを分析しないと、そのまま導入してもうまくいきません。
分析を行うことで、要件定義では機能を適用する部分とアドオンで開発する部分について、どのような機能にするかを決めていきます。
よって要件定義で必要な、利用する機能・作る機能が決まっていることがゴールです。
フィット＆ギャップ分析のマネジメント
企画段階で要求が漏れなく洗い出せていれば、パッケージソフトの機能一覧との比較により、すんなりと決めることができます。
比較によりできること、できないことが明確になり、そのまま使える機能がどのくらいの割合なのかを知ることができます。
機能の数により、確認会議の回数を設定し、マネジメントしていくことが可能です。
しかし、実際はすんなりといくことは少ないです。
その原因の多くは、要求一覧が不十分であることです。
またパッケージの機能一覧も不十分であることがあります。
表面的には同じように見えることがあるので、設計やテスト段階で、違うことに気づいてしまうこともあります。
要件定義前にやるべきことが不十分であることで要件定義以降発生するありがちな問題
要求のモデル化が終わっておらず、役に立たない
要求のモデル化は抽象化されたモデルということもあり、難易度が高いです。
どのくらい詳細レベルで作成するかは、作成する人の力量によります。
大規模なITだと難易度が極めて高いです。
業務範囲が広いとモデルが単純なまま完成扱いとなってしまい、実は多くの業務を表現できていないということがおきます。
そうなった場合、ITシステム開発は進んでいきますが、設計段階でリカバリすることになります。
モデルと設計の差が大きくなり、本来はモデルに立ち返ってテスト範囲を考えたり、業務影響を考えたりしたいところですが、活用できないものとなっています。
結果的に労力を掛けて作成しても無駄に近いものになっていることがあります。
アジャイルで開発していったが、1回目すら出来上がらない
POCである程度実現性が確認できたということで、そのまま続きを実行していったとします。
需要予測を行い、実行計画を策定する業務を、AIを使って自動化するようなケースでは、チャレンジングなものになる可能性があります。
そして、ほんの一部を試した段階で、なんとなく結果が出たとしても、範囲を広げたとたんにまったく使い物にならない、というケースもよくあります。
アジャイルで進めていくことになるでしょうが、何度実行しても思った結果にならないなどということにもなりかねません。
POCの範囲は評価を決めておかないと、途中でやめられずずるずると埋没コストを膨らませてしまうことになります。
肝心な機能が確認できておらず、実は不便
試用期間において難しいのは、大抵機能が限られていることです。
お試しできる機能の範囲では十分と判断できても、実は使えていなかった機能は期待外れのことがあります。
期待外れだけであればまだいいですが、自社にとって重要な機能が欠けているということもあり得ます。
この問題は、事前に確認できるであればしたいところです。
得てして、重要な機能というものを把握できていないことのほうが多いのかもしれません。
要求を見出しておくことのほうが、実は難しく、大事です。
プロトタイプは見た目だけで、結局全然違った
ITベンダーの提案によりまずはプロトタイプを作成してから、進めることとしました。
必要な機能イメージをすり合わせたら、OKとなり、引き続き進めました。
そころが、設計・実装段階になったら、別なものと思われるようなものが出てきました、ということはたまにあります。
プロトタイプの認識が発注側と受注側で食い違っているということが、原因のひとつです。
この場合は、ITベンダーはイメージを合わせるつもりだったのですが、商談・確認段階のメンバと開発段階でのメンバが異なっており、実際は、実装されるものは違うものだったということです。
なんとか動けばいいですが、最悪動かないこともありますので、発注側においても実現性についてある程度見極められる力量が必要でしょう。
システム開発の規模と難易度が実は倍だった
既存ITが大きく影響するITシステム開発は、難易度が高いです。
それは、既存ITのすべてがわかっていないことが多いからです。
保守運用段階になっていれば、既存ITの内部構造まで詳細に把握できている人は減っています。
あまり保守が発生していなければ、割り当たっている要員も少ないため、なおさらでしょう。
そのような背景で、新たにパッケージなり、新規開発なりでITシステムを導入するとなると、既存ITがリスクとなります。
既存ITは規模が仮にわかったとしても、インタフェースの数などで難易度は大きく異なります。
システム開発の規模や難易度が初めからわかっているのと、途中からわかったのでは、プロジェクトに与えるインパクトは相当違います。
うちのITの規模はそんな大きいはずがない、という誤った認識から起きる事故もあります。たった一人で保守していたとしても、5年経っていたら膨大になっています。
明らかに機能不足で、アドオンがテスト中に増加し続ける
フィット＆ギャップ分析の時点で、パッケージソフトの機能がすべて網羅出来てわかっていたら苦労はしません。
やはり進めていくうちにわかってくることが多いです。
それにしても、できるだけフィット＆ギャップは精度を高くしたいです。
場合によってはギャップがあっても、業務をシステムに合わせればいいという方針のもと進められることがあります。
それで済むものであればいいですが、ある程度の会社であればそれで済まないことも多くあります。
承認行為が増えたり、伝票入力順番が変わったりといったことはまだいいです。
問題は、自動で計算されていたものが手動になるといったケースです。
昨日は網羅していても処理件数までは考慮されていないことがあります。そうすると判断を誤って、あとからアドオンになってしまうこととなります。
要件定義前に本当にやるべきこと
要件定義の前工程である本工程は、要件定義を始めとしたそれ以降の工程をうまくいかせるために、非常に重要な場面です。
以降をうまくいかせるためにわざわざやっているのですが、期待値が大きいだけに、外すと以降への影響も大きいです。
しかし、初期段階であるが故に高精度であることも難しいことが多いです。
やりすぎて始める前からコストが掛かりすぎてしまうこともあるかもしれません。
加減が難しいところではあるのですが、適当な労力で最大の成果を上げるよう、皆で集中して取り組むことが必要なのでしょう。
言うのは簡単ですが、やるのは難しいこの適当という見極めは、やはり実現したい目的に立ち返って、何度も確認しつつ実行していきましょう。
コメント