システム開発者が押さえるべき”超上流から攻めるIT化の原理原則17ヶ条”について

こんにちは！わさおです！

今回は、独立行政法人情報処理推進機構が定めた「超上流から攻めるIT化の原理原則17ヶ条」を紹介したいと思います。

こちらは、システム開発に関するあるあるをまとめたもので、システム開発に携わる人にはぜひ読んで欲しい内容です。

先人たちがシステム開発においてどのようなポイントで苦労したのかを把握し、自身のプロジェクトにも活かしていただきたいと思います。

超上流から攻めるIT化の原理原則17ヶ条

超上流から攻めるIT化の原理原則17ヶ条は下記の通りです。

1.ユーザーとベンダの想いは相反する

ユーザ企業は自分たちが使うシステムなので、慎重に要件を決めたいと考えているのに対して、ベンダは仕様を早めに確定させたいという思いがあります。

ここにお互いのギャップが生まれ、要件定義が難航することがあります。

それぞれの立場を理解し、歩み寄ることが重要ですが、個人的には「エンドユーザーの利便性」を基準に考えるべきと思います。

2.取り決めは合意と承認によって成り立つ

合意と承認無しに要件定義や設計・開発を進めるのはトラブルの元です。「勝手に進めましたが、実装できませんでした。」となると手戻りになってしまいます。

ウォーターフォールの開発の場合、手戻りは工数負担が非常に大きいため、一つずつ合意と承認を取る必要があります。

ただし、アジャイル開発の場合はスピード重視かつ手直しが前提となるため、必ずしもこの限りではありません。

いずれにしろ、ユーザー目線での開発が重要だと考えます。

3.プロジェクトの成否を左右する要件確定の先送りは厳禁である

要件確定は慎重に行われるため、先送りにされがちです。しかし、要件確定を先送りにすると後工程に大きく響いてきます。

後工程は、設計、開発、テストなどシステム開発においてトラブルになりやすい工程のため、少し余裕を持たせることが重要です。

そのため、要件確定はスケジュール通りに行うべきです。

4.ステークホルダ間の合意を得ないまま、次工程にはいらない

近年、業務のシステム化が進むについて、ステークスホルダは増えています。これらのステークスホルダの合意を得ないまま、システム開発を進めるとトラブルに発展する可能性があります。

特に、利用ユーザー部署の意見は重視し、手戻りにならないように進めましょう。

5.多段階の見積りは双方のリスクを低減する

システム開発の見積は非常に難しく、プロジェクト発足前に正確な見積を取ることはかなり困難です。

そのため、プロジェクトを進めてみたら、ユーザー側から予想以上の要件が出てきたとか、想定していない開発リスクが出てきたなどが起こります。

ユーザー側としては予算を早めに確定させたい思いがあるのですが、それに縛られてしまうと使えないシステムが出来てしまうこともあり得ます。

個人的には、プロジェクト計画時と要件定義後の最低2段階で見積り取得することをおススメします。

また、このときに重要なのはユーザー側にシステム開発に知見がある人をいれることです。ベンダ側の言いなりにならないようコントロールすることが重要です。

6.システム化実現の費用はソフトウェア開発だけではない

これはユーザー・ベンダともについ忘れがちなのですが、システムは作って終わりではありません。

システムが完成し、受入テストが無事に完了したとしても、その後には「移行」「FT(Field Test)」「マニュアル作成」「研修」「周知」「運用・保守」などの工程が残されています。

これら全てをやるとは限りませんが、少なくともソフトウェア開発だけではシステム化とは、なりません。

7.ライフサイクルコストを重視する

システム開発においては、開発、運用・保守のコストを考慮すべきです。

例えば、業務パッケージを導入する際はカスタマイズを前提にすることは避けましょう。

カスタマイズはコスト増大になる上、余計なメンテナンス等も増えることになります。

個人的には、これからの時代はグローバル基準のソフトウェアやオープンソースソフトウェア(OSS)を採用することをオススメします。

独自システムと比較し、安価に構築でき、拡張性も高いグローバル基準のソフトウェアはこれからのシステム構築の主流になっていくと考えられます。

8.システム化方針・狙いの周知徹底が成功の鍵となる

システム開発の関係者間で、システム化の方針や狙いについてしっかりと認識共有することが重要です。

これらが関係者間でズレていると出来上がるシステムにもズレが生じます。

プロジェクト発足時にプロジェクト計画書を作成し、関係者間で認識共有するのが良いでしょう。

また、関係者が増えたタイミングで同じく認識共有を徹底しましょう。

9.要件定義は発注者の責任である

要件定義は発注者(つまりユーザー側)が責任を持って行うべきです。

システム化を行いたいのはユーザー側ですので、当然責任を持って、要件定義を行う必要があります。

10.要件定義書はバイブルであり、事あらばここへ立ち返るもの

システム開発のゴールはユーザー側の要求を満たすことです。

要件定義書はユーザーの要求が反映された成果物ですので、困った時には要件定義書に立ち返ることが重要です。

11.優れた要件定義書とはシステム開発を精緻にあらわしたもの

発注者は機能要件、非機能要件ともに要件定義書に落とし込む必要があります。

決めるべきことはユーザー側とベンダ側で話し合い、要件定義書に反映させましょう。

12.表現されない要件はシステムとして実現されない

要件定義書は「設計・開発フェーズ」以降、一人歩きします。

要件定義時はユーザー側とベンダ側で綿密に議論しますが、設計・開発フェーズはベンダ側の主タスクです。

設計・開発から新たに加わるメンバもいるため、その人にとっては要件定義書に忠実に沿うことが全てです。

つまり、要件定義書の行間を読むということは難しく、あくまでも要件定義書に書かれていることしか実現されないと考えたほうが良いでしょう。

13.数値化されない要件は人によって基準が異なる

システム開発の認識齟齬を避けるために、出来る限り定量的に要件定義しましょう。

あいまいな表現をいかに使わないかが重要です。

14.「今と同じ」という要件定義はありえない

ユーザー側からよく出てくる要件として、「今と同じ」というものがあります。

しかし、「今と同じ」はかなり曖昧な表現です。例え、本当に同じだとしても曖昧さを排除し、要件に落とし込むことが重要です。

15.要件定義は「使える」業務システムを定義すること

システムはあくまでも業務ありきです。

システム化する際は業務をゼロベースで再設計し、業務の無駄を排除しましょう。

出来る限り、シンプルな業務設計にすることがポイントです。

16.機能要件は膨張する。コスト、納期が抑制する

業務要件定義をすると、ユーザー側が今よりも便利にしたいという思いが強く、アレもコレもと機能を盛り込もうとします。

しかし、システムの最初のリリースのときに機能を盛り込み過ぎると失敗します。

それは、コストだったり、スケジュール遅れだったり、ユーザーの使い勝手だったりします。

システム化の目的に立ち返り、本当に必要な機能を実現するように心がけましょう。

17.要件定義は説明責任を伴う

要件定義の認識齟齬は徹底的に避けるべきです。

そのために、成果物は精緻なものを作成することが大事です。

また、ユーザー側とベンダ側で綿密にコミュニケーションを取ることも重要です。

ユーザー側は要件定義しっぱなしではなく、ベンダ側にその内容を説明する責任があるのです。

まとめ

いかがでしたでしょうか。

今回はIT化の原理原則17ヶ条について解説しました。

システム化の失敗の多くはコミュニケーションミスと言えます。

関係者間が同じ認識でシステム開発に臨めるように、今回の17ヶ条を意識しましょう。

↓↓このブログが少しでもお役に立ったならば、応援クリック頂けると嬉しいです！↓↓