IT導入・システム開発においてプロジェクト頓挫の原因となる要件・仕様に関する問題とは

この記事は約4分で読めます。
ITシステム要件と仕様


IT導入・システム開発のプロジェクトが頓挫に向かっていて、末期状態にある時には、要件や仕様に関する問題が累積されています。

要件は何を作るのか、仕様はどう作るのか、ということで少し違うのですが、末期状態においては、よりITシステムが具体的になっているので、どちらもごちゃまぜに語られていることのほうが多いです。
ここで改めて要件と仕様とは何かということと、どのように問題が発生し、失敗に向かってしまうのかを見ていきたいと思います。

IT導入・システム開発における要件とは

要件とは一言でいうと何を作るのか、ということになります。何を、というのは例えば顧客管理システムを作る、といった大括りなものはなく、もう3段階くらいブレークした、機能として何を作るのか、というものが基本となります。

作る、といっても一過性の作業も中には含まれます。新システムを稼働させるために、既存システムからデータを移行するという作業は主だったものです。

要件とは似たような言葉で、要求というものがあります。これらを明確に区別していない場合も多いですが、別物として段階的に捉えたほうがよいです。

要求は、何をしたいか、を示します。要件は、何をしたいかを実現するために、何を作るか、ということになります。
実は、何をしたいか、というのは初めに明確になっているべきですが、抽象的な話になっていて、明確でないことがあります。

要求は何をしたいかを実現するのですが、要求が例え明確でなかったにしても、要件として盛り込まないといけないことがあります。

例えば顧客管理システムにおいて、営業担当がお客さんの情報を登録し他の担当でもリアルに参照できるようにする、というのが要求であったとします。
要件としては、システム要件定義を行うことで明記されます。例えばこの場合ですと、営業担当がお客さんの基本情報と来訪履歴を登録する。基本情報が変わったら、一から登録し直す。他の担当でも編集可能で、誰が編集したか履歴をわかるようにする。などといった必要なシステム機能を定義していきます。実際は、何件表示できる、担当が変わった時の管理をどうするなど、さらに多くの観点から明記されるべきものです。

要件は要求よりもよりシステムとして実現するものを具体的にしないといけないことがわかります。要件はエンジニアが要求として特に言っていなかったことも具体的にしていくために、自らの知見や発注側へのヒアリングなどから作り上げます。

最初の段階では形がないものに対して、言葉を中心として定義していきますので、非常に難しい作業になります。

IT導入・システム開発における仕様とは

要件は何を作るかを定義したものに対し、仕様は実際どのように設計され、どのように作られているか、というものになります。

ITシステムは画面などの見える部分と内部のデータベースや処理といった外からは見えにくいものからできています。

どのように実際作るかはエンジニアの設計次第です。

エンジニアが要件を具体化し、設計していきます。設計は基本設計、詳細設計、プログラム設計と段階的に行われます。そうして作られたものの元になるものが仕様です。
仕様は初めに決まっていて作りこんでいくように思われますが、実際は様々な影響を受け、最終的な仕様が決まっていきます。

他のシステムに繋げる場合は、その他システムの仕様に影響されます。また、パッケージシステムに対してアドオンとして追加で作りこむ場合は、パッケージの仕様に影響されます。
具体的にITシステムが作られた段階においては、仕様はゆるぎないものであるはずです。なぜならば、仕様イコール作られたものであるからです。

ところが、IT導入・システム開発においては、この仕様により揉めます。仕様は具体的に作られた段階のものであり、様々な制約や影響により、要件や要求と異なったものになったり、要件を満たしていたとしてもイメージと大きく違ったりすることが起きてしまうからです。

まとめ

IT導入・システム開発での要件とは要求に対して何を作るかということを定義したものです。
仕様は具体的に作られた設計やプログラムの元となるものです。

ITシステムは具体的になっていくにつれ、仕様がはっきりしてくる一方で、要件を満たしていなかったり、少し違ったりといった問題が生じがちです。
仕様が作りこまれてしまっている段階で要求と違うので作り直し、いったこともありがちです。

問題が累積してどうにもならなくなったら、発注内かどうか、あるいは発注側と受注側のどちらが悪かったか等のやり取りが必要となってしまいます。

問題の多くは要件を固める段階で兆候が出ています。出来上がるのがまだ先だからといって検討を先延ばしせずに、何を作るのかは細かく決めていきたいものです。

発注側として要件を決めていくにしても、パートナーとしてITベンダーの質も重要であるのは間違いありませんが、場合により第3者も自分の味方として参画してもらう、というやり方もあります。

コメント

タイトルとURLをコピーしました