スマホサイト・アプリをつくろう。

今回は、前回決定したコンセプトに基づいて「システムの要件定義」を行います。

要件定義とは？

言葉の解釈が業界や会社単位で異なっているため、何をもって「要件定義」とするかはケースバイケースですが、ここでは「そのシステムが何のためにあり、どういった機能を持たせたいのか」をまとめたものを指します。そのため「要求定義」という言葉の方がしっくりくるかもしれません。この「要件(要求)」を元にそれを実現するための「機能」や「仕様」を決定し、成果物として「要件(要求)定義書」「仕様書」「設計書」など各種ドキュメントを作成することになります。

要件定義の重要性

このフェーズは私がシステム開発にあたり最も重要であると感じているものでもあります。なぜなら、プロジェクトがデスマーチに陥る原因のほとんどが仕様変更によるものであり、それらの仕様変更が起こる原因のほとんどが要件定義時の詰めの甘さから来るものだと言われているからです。もちろん、やむを得ない事情から「要件」そのものが変わるケースも存在しますが、開発作業の前に確認すべき事を確認し、行うべき事を十分に行えば回避出来る問題である場合が多いでしょう。少なくとも被害は最小限に抑える事が出来るはずです。

近年導入されるケースが多くなってきている「アジャイルソフトウェア開発」を、このフェーズを省略、又は簡略化するものであると捉える方が多いようですが、それは大きな誤解だと思います。アジャイル型の開発手法では「機能」単位で「計画、要求分析、設計、実装(コーディング)、テスト、文書化」まで行い、それらを反復し繰り返す事でシステム全体を完成させるものとされていますが、システム全体の果たすべき役割（要件定義）をじっくり詰めておかなければ、各機能を判断する基準が明確で無いため、それぞれの「機能」に対しても正確な判断が出来ないでしょう。

「要件(要求)」とは「目的」を達成するためのものです。「要件定義」をおざなりにし「目的」を理解しないまま仕様を策定してしまうと、いくら仕様どおりの高性能なシステムが完成したとしても、それが「目的」を達成出来るものになるとは限りません。システムとは「目的」を達成するためのものであり、それが出来無ければ無意味・無価値であると言えます。そして、システム導入の「目的」を達成する事によって「成果」を挙げる事こそがプロジェクトにおける「成功」であるはずです。

これらの事からも、「要件定義」というフェーズには十分な時間と労力をかけるべきだと私は考えており、参考にさせて頂いた記事内でも下記の様に触れられています。

筆者の経験から要件定義に関するアドバイスを述べる。それは，「要件定義には十分な時間をかけるべき」ということだ。実際，日本IBMで請け負った近年の大規模プロジェクトでは，20～25％のコスト・期間を要件定義に当てている。小規模・短納期開発であれば，30％以上を要件定義にかけてもよいだろう。

日本IBMの標準的な作業手順とは？

「二次会への出欠を確認・管理するサイト」の要件を定義する

ここまで「要件定義」にはかなりのコストを費やす必要があると強調してきたため、拍子抜けするかもしれませんが、今回は極めて個人的かつ小規模のシステムであることから、このフェーズで最低限決定しておくべき項目とその内容を「要件」と「機能」に絞り、それぞれを整理し列挙していくところまでを行ってみます。実際の案件で行う「要件定義」については、その概要を後述する事にさせて頂きます。

システムに要求されるもの

• ３G以上の携帯であれば３キャリア問わず利用出来る
• 招待者は出欠の連絡が出来る
• 招待者は会場の情報が確認出来る
• 幹事は地図など会場の情報を登録出来る
• 幹事は出欠の回答内容をメールで受信出来る
• 幹事は回答状況を画面上で確認出来る
• 幹事はTOPに表示されるメッセージを指定できる

これが今回の「要件」になります。実際の案件であればここで、更に詳細なケースに分けた要求や、どの様な動作をするのか、また、稼動する環境やパフォーマンスなどにも言及する必要があるかもしれません。

システムに実装される機能

これらが「システムに要求されるもの」から導き出された「機能」になります。各機能をグループ分け、リスト化したのみで、機能については概要を記載するのみとなっています。そのため、機能設計ではなく機能一覧となっています。この辺りは画面ごとに作成したりと様々な方法があり、案件の規模・内容によって「仕様書」「設計書」などの必要になってくるドキュメント類も変化するでしょう。

実際の開発における要件定義

今回は個人的に開発する小規模システムである事から、簡略化された内容になっています。繰り返しになってしまいますが、実際の開発案件では、ここでプロジェクトの成否が決まってしまうといっても過言ではないというほど重要なフェーズです。と同時に非常に難しい作業でもあります。

顧客のいる場合や複数の人間が関わる場合には、要件(要求)を定義するという作業は更に難しい作業になるでしょう。顧客の業務内容を理解し、現状の問題点を把握し、問題点を解決するための方法を提案、もしくは顧客から要求というカタチで引き出し、予算やスケジュール・技術面など様々な条件からそれらの要求を整理し、結果に対して顧客との合意を取り、決定事項を関係者全員に共有し、その内容を保守管理するのですから、非常に労力の必要な作業になる事が想像できるかと思います。

「要件定義」とは、先述の【要件定義の重要性】にある様に重要であり、この様に労力（コスト）のかかるフェーズです。プロジェクトのスケジュールを建てる際や、工数や費用の見積もりの際には十分に考慮しておく必要があるでしょう。

また、冒頭でも述べたとおり「要件定義」や「仕様」といった言葉への認識にズレが生じる事が良くあります。そのため複数の人間が関わるプロジェクトや大規模な開発に際しては、事前に「要件定義書」「機能設計書」「詳細設計書」などといった用語の定義から始め、「どの段階で何をどこまで決定するか」といった計画を建てておくと、比較的スムーズにプロジェクトを進める事が出来るかと思います。他にも小さな打ち合わせであっても議事録を取っておく事や、各フェーズで提出するドキュメントを決定しておくなど、ちょっとした注意でその後のトラブルを防ぐ事になり、プロジェクト進行に大きく影響するという事もあります。

参考

• 要求定義の方法論を知る【後編】
• 第1回 いまさら聞けない要求管理の基本
• 本当の要件定義とは何か・新しい方法論と契約形式