システム開発全体の中での、工程としての要件定義の位置付けを考察し、記載しました。要件定義を修正するタイミングや場面、システム開発の主な2つの開発方法と要件定義の関係を軸とした内容です。

ウォーターフォール型開発における要件

ウォーターフォール型開発では「業務分析」「要件定義」「基本設計」「詳細設計」「実装」という工程を、水の流れのように一方向で行っていきます。一方向が原則とはいえ、大前提として、工程を考える上では反復を想定して、「要求→要件→設計→実装のトレーザビリティを可能にすること」を考慮すべきと筆者は考えています。そのためには、少なくとも「要件定義」においては、開発対象のシステムについて「大枠の方向性と規模が具体的に明確になっているレベル」でなければなりません。変更の発生時に、要件の変更を遡って反映できるようにしておくことは、システム開発の工程全体の整合性を担保する上で欠かせません。一般的にもウォーターフォールと反復型のハイブリッドという現実解が定着しつつあります。結果的に手戻りを認めない理由は、コストが高くつくからに尽きます。要件定義の不備を要件定義中に解消する場合と、設計や実装·テスト段階に解消する場合のコストを比較すれば、違いは一目瞭然です。このことは「手戻りコストを抑制する」というウォータフォール型開発の理念と相反するものではありません。

「手戻り」と反復~なぜ反復を可能とするか?

ウォーターフォール型開発を採用する場合にも、必要であれば、ある程度の反復開発は認めるという立場をとっています。なぜ、そんなことを考えるようになったのか? それは、ウォーターフォール型開発においても、「要件の確定」だけではなく、システム開発プロジェクトの「時間軸」を考慮する必要があると考えるからです。要件の妥当性を合意するために、工数が超過していいはずがありません。そうした場合には、要件として確定すべき範囲を狭めて、次工程に進むしかありません。アジャイル型の開発は、ウォーターフォール型へのアンチテーゼとして成立した経緯があるので、時間軸の問題は解消していますが、大きな要求が変更された場合には、イテレーション(反復)よりも以前に遡る必要が生じます。いずれの場合も重要なことは、「実装段階にあっても、要求→要件→設計→実装のトレースがきちんととれていること」であると筆者は考えています。トレースできないシステムは、ライフサイクルが短くなる恐れが大きいでしょう。

手戻りについて

ウォーターフォール型開発において「手戻り」は、特に避けるべき事項として認識されています。そもそも手戻り云々を嫌ってアジャイル信仰が広まっていった歴史があります。アジャイル派の意見としては、「そもそも仕様確定を手戻りなしで行うのは不可」というところだと思います。実は、筆者も同じ感想を持っています。しかし、読者の皆さんは「ウォーターフォールに近い要件定義手法を推奨している」と感じていないでしょうか。それには理由があります。まず基本形を押さえた上で「崩す」、基本を踏まえた上でカスタマイズ可能なやり方が万能であると、確信しているからです。システム開発は様々な局面に遭遇します。まず基本をふまえた上で、どんな開発手法を使おうと、ある程度の手戻りは起こりうると覚悟し、各工程にて反復を可能とする必要がある、という考えを持っています。

アジャイル型開発における要件

アジャイル型開発でも、要件の考え方はいくつかあります。「要件までは確定した上で反復を行うべき」、あるいは「要件定義も繰り返しの中で行うべき」、大きくはこの二つでしょうか。前者はエンタープライズ系に類するシステムや、外部連携を伴うシステムとの親和性が高いといえます。その場合、「要件定義の後半」から「実装」までを、イテレーションの中で行っていきます。後者は、単独で動くシステムや、仕様変更が他システムへ影響せず、現場で仕様を確定できるシステムとの親和性が高いといえます。その場合、ある程度の前準備の後(この作業を要件定義と呼んでもいいかもしれません)、繰り返しの中で、本来は要件定義工程で行うべき作業を行っていきます。前者の場合、操作レベル(ユーザービリティの改善)や項目追加ならば、即時に修正は可能でしょう(これはウォーターフォールでも同じです)。後者の場合、何でも対応可能なように見えますが、現実には全体性を見失う危険性を伴います。大きな変更については、ある程度の枠組みをきちんと定めた上で、繰り返しを実施するのが現実的です。ウオーターフオール型でもアジヤイル型でも、ビジネス要件レベルの修正が生じた場合には、要件定義をきちんと再考した方が却って近道になります。逆に考えてみると、要件定義は、後から遡って修正できるレベルで留めておかないと、仕様変更なんて無理という話です。要件定義で仕様確定を目指すあま詳細の議論に入り込んでしまうと、当然のことながら修正は難しくなります。

2種の開発手法における要件定義

ウォーターフォール型開発とアジャイル型開発における要件定義の違いを比較してみます。なお、ここでのウォーターフォール型には、「反復型」つまり、ウォーターフォール型を基本としつつも、ある程度の反復を認める開発手法を含めます。上記ウォーターフォール型の場合、要件定義では機能レベルあるいはプロセスの機能(概要)レベルまで定義します。プロジェクトによっては、業務プロセスの定義、機能の仕様確定までを行います。アジャイル型開発の場合、要件定義で行うべき作業は基本的には変わりませんが、そもそも「アジャイルは新しい価値を生み出すプロセスであり、要件は固まらないもの」という前提に立っています。それでも最低限の要件(方向性と制約)の明確化は必要です。機能分割可能な状態まで持っていく必要はあります。まず方向性を検討し、その上で、真の要求はアジャイルで設計と共に行います。開発手法により、必要とされる要件定義の「粒度」が異なることがありますが、基本的には相違がない、と考えています。あくまでシステム開発の目的、方向性を明確にし、機能を想定可能とする状態です。

【広告】Librus Tech Communityのお知らせ

Librus株式会社が運営する、システムエンジニアやプロジェクトマネージャーの方向けに展開するコミュニティにぜひご参加ください。「互いに助け合い、学び合う空間」をコンセプトに、システム開発に関するセミナーや勉強会をはじめ、案件や転職先のご紹介、相談対応も行います。エンジニア初心者の方や起業、現在フリーランスをされている方、フリーランスを目指している方も大歓迎です。

▼Slackコミュニティ入会フォーム
https://forms.gle/1D5duKwVJhm1vFb18