フィーチャ・モデルで過去経緯を残す

@ITの記事で、長期的な要求を定義するフィーチャ・モデルの紹介がされています。
今まわりの開発現場を見渡すと、長期に渡る保守開発で、顧客も開発者も人の出入りも激しく、過去の意思決定背景が分からず、「何でこんな設計になっているんだ」と怒号が飛び交う毎日です。
フィーチャ・モデルの優れた点は、結果採用に至らなかった代替案も、記述できるというところにあると思うのです。ユースケース図でも別にコメント等を駆使して表現できないわけではありませんが、フィーチャ・モデルとはフォーマットとして定まっている/いないの違いがあります。
このフォーマットが重要なんですね。最近、設計書フォーマットの標準化を行ったのですが、その評価として、「そこそこ重要な仕様であるが、フォーマットに書く場所がないから記述しなかった」という、驚くべきコメントが得られました。大衆化したシステム開発の現場においては、期待している「適切な判断」がなされないことがあるのです。

また、IT投資に関して非常に慎重な昨今、機能の優先順位は要件定義中にもコロコロ変わります。
記事中では、

フィーチャ・モデルは、直感的にはエンドユーザーが選択可能な機能を示している。しかし、厳密には前述したように、エンドユーザーにとっての機能の選択性よりも、アーキテクチャが提供する長期的に再利用可能な機能（要求）の表現である。

と言っていますが、エンドユーザーが選択可能な機能を、「見える化」できるという価値は見過ごすことはできません。機能要求変化の激流の中で、やりたいことの本質を見失わず、より多くのオプションを考えるツールとしての活用が期待できます。

ということで、設計の過去経緯を残す(解決領域のフィーチャモデル)・要件の優先順位付けに(問題領域のフィーチャモデル)、早速適用してみたいと思います。