要件定義の疑問

要件定義や設計という上流工程について以前から感じていた疑問をメモ。

【1】以前から、オブジェクト指向モデリングやらデータモデリングやらビジネスモデリング等の本を漁ってきたけれど、どれもあまり役立たない気がしている。
何故だろう？

モデリングや要求分析が必要になる場面は、新規顧客の受託開発で、顧客からシステムの要件をヒヤリングしたり、その後の仕様確認の時だ。
つまり、設計しながら要件を詰めていく作業で、モデリング技術が必要になる。

しかし、OOAもDOAもあまりピンと来ない。
RUPは確かに勉強になるが、膨大すぎて現場の実践に向かない。

UMLを使ってモデリングするのは確かに思考の整理に役立つが、それはむしろ実装に近いフェーズだ。
概念モデルのクラス図を書いたとしても、ユースケース記述で業務仕様を書いたとしても、何か物足りない。

むしろ、OOAよりもDOAの方が実践的だと感じる時がある。
テーブル設計をしながら、実際に実装している感覚だ。
特に、RailsやSeasarのように優れたフレームワークがあるおかげで、DBの箱さえ決まれば、RubyやJavaで簡単に作ることができる。

でも、DOAのデータモデルパターンは洋書しかなく和書が存在しない。
良書は、渡辺さんの本や「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」などごく一部だけだ。

OOAの本は抽象的過ぎる。
確かにクラス図を描くスキルは上がるが、実装モデルに程遠い。

OOAは最終的にはMDAがやりたいだけなのだろうと思う。
モデルさえ書ければ、プログラムを自動生成してくれるというMDAの発想。
その発想は理想的過ぎるように思う。

顧客の業務のフローやエンティティを導出するのにOOAは非常に役立つが、むしろ、システム設計ではクラス図よりも状態遷移図の方が重要だという気がしている。
我々SEがシステムエンジニアであるという意味は、業務を知ることよりも、業務をシステムへマッピングすることがSEの役割だからだ。

システム化する上で最も重要なポイントは、業務をシステムとみなした場合、システムの状態を導き出し、その遷移を全て記述することだ。
システムの状態とは、そのシステムで最も重要なエンティティの状態を表し、DBに落としたらフラグとして現れる。
そのフラグのCRUDを表した物がシステムの状態遷移図に当たる。

システムの状態遷移図を緻密に描くほど、システムの整合性を考えやすく、そこから要件漏れや設計漏れに気づく。
状態遷移図があれば、それからテストケースを作ることができる。
そして、普通は、システムが大きいほど状態遷移図は複雑であり、状態爆発を起こす。
テストケースは膨大になり、どこまでテストすれば品質を担保できるか、SEとしての技量を問われる。

【2】要件定義でいつも疑問な点は、システム化する技術力よりも顧客へのヒヤリング能力と言う人間関係構築能力の方を重要視されることだ。
昨今の人間系、特にファシリテーションもその一環と捉えることもできるだろう。

しかし、技術力が軽視されていないか？
ヒヤリング能力が重要と言っても、顧客の業務をロジカルに整理して、要件の一覧をMECEで導き出す技術も必要なはずだ。
ヒヤリング能力、ファシリテーションだけでは、要件定義を解決できない。

その点で、清水吉男さんが提唱する派生開発プロセスXDDPに興味はある。
XDDPでは、要求を発見することよりも、要求を表現することに力点を置く。
要求仕様と機能仕様を厳密に区別し、変更理由も書きながら、要求仕様を機能仕様へ階層化しながら詳細化していく手法。
この手法ならば、機能仕様へ詳細化する時に、仕様に漏れがないか、重複がないか、自然に考えれるようになる。

また、XDDPで面白いと思ったのは、要求には機能要件だけでなく、保守性や信頼性、性能要件のような非機能要件も含めるという点だ。

例えば、保守性の要件では、関数の複雑度は15以下とする、など。
信頼性や性能要件でも、ボタン押下後のレスポンスは1秒以内とする、など。

これらの非機能要件は実際のSW開発では設計漏れしがちなのだが、漏れなく仕様化できるプロセスがXDDPにはある。

普通のSW開発では、顧客はSEでないからシステム化の技術に疎く、顧客の言うがままに作ってしまうと、必ず要件漏れが発生する。
要件定義では、要件を漏れなく全てを洗い出すこと(MECE)が重要だと最近は思う。

【3】アジャイル開発は、要件定義に関して一種の諦めがあるように思う。
アジャイル開発における要件定義の特徴は、仮説検証スタイルであることだ。
つまり、短期間のイテレーションを繰り返して開発しながら、顧客のストーリーを少しずつシステム化しては、顧客に確認してもらい、フィードバックを受けながら、更に修正していく。

この繰り返し型開発スタイルは、全ての要件は最初に決められないという仮定の下で、安定した重要な要件から少しずつ開発していくという発想に基づく。
WF型開発のように、最初に全ての要件を決めていくのは現実のSW開発では無理で、すごくリスクがあるという仮定に基づいている気がする。

また、オンサイト顧客というXPのプラクティスでは、顧客を開発チームの近くに置き、常に要件を確認できる状態にする。
実際の受託開発では、顧客を開発チームの内部に配置できないケースも多い。
その場合、顧客と関係が近く業務が詳しい上級SEが顧客の代わりになるという顧客プロキシという手法もある。

また、Scrumのプロダクトバックログというアイデアもある。
顧客の要求を一旦バックログと言う貯蔵庫に貯めて、リリース計画から、そのスプリントで実現する要求をプロダクトバックログからスプリントバックログへ移す。
つまり、要求をリリース計画や優先度に基づいてふるいにかけるというマネジメントが含まれている。

アジャイル開発では、要件定義や開発スタイルに関しても、従来のWF型開発では明示されない解決方法を提示しているように思う。
まさに「1回のリリースは100回のレビューに勝る(プログラマの思索)」。

【4】要件定義や設計プロセスで重要だと思う点は、要件カバレッジと要件の追跡だ。

顧客が提示した要件は、漏れなく全て、仕様書やプログラム、テストケースに反映されているか？
顧客が提示した要件が、どの設計書に仕様化されて、どのプログラムに実装されて、どこでテストされて、どのバージョンのモジュールに反映したのか？

現場では、上記の作業をプロジェクトリーダーやSEが手作業で確認し合っているようなものだ。
だからすごく非効率で生産性が低く、結果的にシステムの品質も低い。

開発プロセスが整っていないプロジェクトでは、要件や仕様にIDが振られていない時が多い。
すると、今どれだけの要件がテストで検証されたか、どこまで要件を網羅しているか、集計できない。

「要求は数えられたら品質が上がる(プログラマの思索)」のだ。

要件にIDが振られて初めて、要件の追跡が可能になる。
現状のチケット駆動開発では、「BTSチケット→SVNリビジョン→Hudsonのビルド番号」までは相互のトレーサビリティを実現できている。
そして、TestLinkでは「要件→テストケース」の相互のトレーサビリティが実現できている。
だから、BTSとTestLinkの間のトレーサビリティを可能になれば、要件やテストケースがチケット経由でビルドモジュールのビルド番号まで追跡可能になる。

このアイデアを膨らませたものが「プロジェクト管理サーバー」。
そのアイデアは「アジャイル開発の弱点をプロジェクト管理サーバーが助ける: プログラマの思索」に書いた。

つまり、「プロジェクト管理サーバー」の最終ゴールの一つは、要件カバレッジと要件の追跡をリアルタイムに集計して、管理作業を減らし、本来の開発作業に専念できるようにすることだと思っている。