アプリケーションのポイント

point

・誰が何を求めているのか

要件定義書に沿ってアプリケーションを開発したにも関わらず
使い物にならないアプリケーションが出来てしまう。
開発側としては「言われたことはやりました。言われてない事はやりません。当たり前でしょ?」
依頼側としては「言わなくても常識的に考えてやるのがプロなんじゃないの?」
プロダクトがほぼ完成の段階でこのようなやり取りが行われ、追加費用だ責任だと言った話から裁判に至った話も耳にします。

なにが問題だったのでしょうか。
依頼側が常にITのプロフェッショナルというわけでもありません。
初めてITを導入する企業に対し、要件定義書が云々と言われても不幸な結果しかないのです。
また、開発側も依頼側の業界に理解があるかと言えば必ずしもあるわけではありません。
まずはお互いのギャップを埋める為にも要求というものをはっきりさせる必要があります。

・ソフトウェア要求

要求とは一体何でしょうか?簡単に言えば「~したい」といったものになります。
しかし、開発における要求は様々な定義があります。
ここではWiegersの著書「ソフトウェア要求」を参考に記載します。

・ビジネス要求
ソフトウェアを導入する企業のビジネス目標。
「ビジョン/スコープ記述書」に記述します。

・ユーザー要求
ユーザーの目標、ユーザーが実行できなければならない仕事。
「ユースケース記述書」に記述します。

・機能要求
特定条件下におけるシステムの振る舞い。
「ソフトウェア要求仕様書(SRS)」に記述します。

この上記3つの要求はそれぞれ異なるレベルの要求であり、各レベルで整合が取れていなくてはいけません。
ビジネスの目的を達成するために、ユーザーの仕事があり、ユーザーの仕事の達成のためにソフトウェアがあるのです。
また、各レベルにおいてはソフトウェア外の要求が関連する場合が多々あります。

・ビジネスルール
ビジネスの特定の側面を定義する制約、または方針、ガイドライン、標準、規約。

・制約条件
設計、構築における開発者の選択肢に課される条件。

・外部インターフェイス要求
ソフトウェアとユーザー、別のソフトウェアシステム、ハードウェアとの繋がり。

・品質属性
プロダクトのサービスやパフォーマンスの特性。

・システム要求
複数のサブシステムを含むプロダクトの最も概要レベルの要求。

・非機能要求
システムが示さなければならない特性、特質、システムが順守しなければならない制約条件。
品質属性や制約条件、外部インターフェイス要求などプロダクトの機能以外の要求。

・フィーチャー
ユーザーに価値を提供する1つ、または論理的に関連する複数システムの能力。

上記の要求も含めた関係について見ていきましょう。

・ビジネスルールは、ビジネス、ユーザー、機能の3要求の他に品質属性にもかかわってきます。会社の方針、政府の規制、業界標準、計算アルゴリズムなどが含まれ、要求の根拠をたどればビジネスルールに行き着く場合があります。
ソフトウェアの開発を依頼する側にとってビジネスルールは常識レベルであるかもしれませんが、開発者にとっては不明点の多い領域です。
このルールについても要求に含めないと後々齟齬が生じることとなります。

・フィーチャーは複数のユーザー要求を含み、各ユーザー要求がさらに機能要求群を持つ、ユーザーの為の機能群です。

以下の4つは機能要求の根拠となります。
・品質属性は性能、安全性、可用性、移植性などの特性についての要求。

・外部インターフェイス要求はシステムとその外側のやり取りの定義であり、ユーザーの操作にかかわる部分や、別システムとの通信規約、システムに接続しているハードウェア機能の実装などが含まれます。

・システム要求はシステム全体の機能、相互作用からプロダクト要求を表します。

・制約条件は開発における言語やデータベース、プラットフォーム依存の制限などの技術的なものからコーディング規約や法規制など多岐にわたります。

ソフトウェアのプロダクトとしての要求は上記のようなものから構成されます。
但し、ビジネスのプロジェクトとしてマニュアル類やSLA、教育関連などのプロダクトとは別の要求もあります。
プロジェクト要求についてはの話はビジネスアナリストやプロジェクトマネージャーのスコープの為、今回は除外します。

・要求開発

要求開発とは顧客が真に求めているものを取り出す作業です。
これは開発側が依頼された事だけをやるのではなく、顧客目的を理解し、
そのビジネスに最適なプロダクトを提案することも意味します。

要求開発の活動は以下の4つになります。
・引き出し
ユーザークラス(システムから見て同じ要求を持つグループ)とステークホルダー(プロジェクトに影響を受ける、もしくは与える関係者)を特定する。
ビジネス要求とビジネスを達成するためのユーザー目標、仕事に対する理解。
プロダクトの使用環境の理解。
各ユーザークラスの代表者の機能へのニーズと品質への期待を理解する。

・分析
引き出した要求を、ビジネス要求、ユーザー要求、機能要求に分類する。
概要レベルの要求を適切な詳細度に分解する。
他の要求情報から機能要求を導き出す。
品質属性の相対的な重要度を理解する。
要求をシステムに定義された機能に割り振る。
実装の優先順位について折衝する。
定義されたスコープと要求のギャップを識別する。

・仕様作成
要求を文書化する。

・妥当性確認
要求のレビュー。
要求のテスト。
受け入れ基準の定義。
要求のシミュレーション。

この4つの活動を逐次繰り返すことで要求の精度を高め、
ステークホルダーの要求合意に至ります。
但し、この合意はその時点でのベースラインであり、今後の変更を受け付けないといった
凍結を意味するものではないことに注意してください。
ビジネスの変化に合わせ、要求変更は常に発生します。
ベースラインの定義以降は要求管理という要求開発とは別のプロセスが担います。

要求開発について触りの部分をご紹介しましたが、
要するに問題解決する為には問題を正しく認識する必要があり、
そのためには問題解決を依頼する側、される側のお互いがコミュニケーションを取り
信頼によって結ばれる必要があるということです。

アプリケーション開発はビジネスのビジョン達成の為の活動であり、
開発側もビジョンを共有することが重要であると言えます。

TO TOP