先日より、長沢流の変訳を開始しました投稿について、ちょっと書きたいと思います。

【WITブログ(訳)】マイクロソフトの開発部門でのTFSの活用 - 第1章(我々のプロセス)
http://blogs.msdn.com/tomohn/archive/2008/04/22/wit-tfs-1.aspx

において、「シナリオ」―「バリュー プロポジション」-「エクスペリエンス」-「フィーチャ」という構造をご覧いただきました。この構造になじみのある方、なじみのない方、いらっしゃると思います。

この用語を用いるかの違いはありますが、この構造は特に製品(とりわけソフトウェアだと、パッケージ製品)においてはよくある要件構造です。

もっとわかりやすーい例を挙げてみましょう♪

市販の製品やソフトウェア パッケージのパンフレット/プローシャを思い浮かべてみてください(手元にこれらがあればそれを手にとって眺めてみてください)。おおむね、この構造になっているものです。

大見出しやサブタイトルあたりで、シナリオにあたるこの製品の位置づけや目的が記述され、次に、この製品を導入するとどんないいことがあるのかというバリュー プロポジションが記述され、そして事例であったり、こういうケースを想定しているといった情報があり、そしてそして、それらを実現するための機能が紹介されている(さらに価格や導入への道筋(評価キットや導入支援サービスなど))が記載されているものです。

素直にこの順番で並んでいるとは限りませんが、ロジカルにお客様に価値を感じていただくためのパンフレットやブローシャといったものは、概ねこの構造になるわけです。そしてそれがお客様にとって一番わかりやすいんですね。

ということで、パンフレット/ブローシャを見る機会があったら、そういう視点でも見てみてください。「おお、これがバリュー プロポジションか」とか (^^)

意外と、その製品の本当のコンセプトが見えてきたりもします。とくに製品を購入するか検討しているときは、直近の困ったことに目がロックオンされがちで、その製品のビジョンなどに目が行ききれないこともあったりします。そうすると「機能」と「価格」に極端に偏った判断をしてしまうことになってしまうかもしれません。

違った視点で見ることで、面白い発見があるかもしれません。ぜひお試しを。これやると要件定義なんかのコツをつかむ、養うのにもいいですよ (^^)

# 私もセミナーコンテンツや執筆記事を考えるときは、この視点を忘れないようにしています。




ながさわともはる