特徴(Feature)、粗筋(Story)、脚本(Scenario)
- Agile開発に限らないが、システム*1業界用語ってカタカナ*2表記が多すぎる。
- 「いや、元々が舶来なので日本語では微妙に表現できないのですよ」という人もいるかもしれない。
- でも、この「カタカナ表記のまま」ってのが意思決定者の判断を誤らせたり、新規参入者に対する壁を高くしたりしている可能性は排除できないのではないかな。
- 今日、この後打ち合わせが入ってるプロジェクト*3もFeature、Story、Scenarioがごっちゃになりかけている。
- なんとかわかりやすく表現できないかと悩み中。
- 以下、自分の案。名訳があったら、是非教えていただきたい。
Feature=特徴
- 自分は今までFeatureを「機能」と紹介してきた。
- 同じ「機能」でも開発者が対象にするのはFunctionで、利用者が対象にするのはFeatureですよ、と説明してきた。
- でも、安井さんと角谷さんの本29頁を読むと「特徴」がいいのかな、と思った。
Story=粗筋
- その特徴(Feature)を利用者が具体的に体験する過程を記述したのがStory。
- AgileではこのStory単位で見積りや計画を行い、開発が進められる。
- これは「粗筋」かな、と。
- 理由は、この後にでてくる「Scenario」との関係で。
Scenario=脚本
- 粗筋(Story)をより具体的に記述したもの。
- 受入検査*4の根拠となる。
特徴→粗筋→脚本、と具体的になっていく。で、この分析をよくまとめた資料がRailsConf 2009で紹介されていた。RSpecの話がからんでいるけど、別にRSpec使わない人達にも役に立ちそうな説明だ。
特徴(Feature)は「なぜ？」を突き詰めて抽出。
カンファレンス*5登録システムの話。
- 「カンファレンス参加者自身が申込をできるようにしたい」
- 「なぜ？」
- 「何人が申込を済ませたか知りたいから」
- 「なぜ？」
- 「目標人数までの到達度を知りたいから」
- 「なぜ？」
- 「カンファレンス運営原価を管理したいから」
→たぶん、この「カンファレンス運営原価管理」が特徴(Feature)。そして、「目標人数までの到達度を知る」とか「何人が申込を済ませたか知る」とかいうのは粗筋(Story)。さらにその粗筋をより具体的に記述したのが脚本(Scenario)。
粗筋(Story)例
概要: カンファレンス目標人数までの到達度を測定する
- (As a)カンファレンス主催者として
- (I want)カンファレンス申込状況の報告書を見たい
- (So that I can)これにより、申込目標人数までの到達度を知ることができる。
英語だと「As a hogehoge, I want hoehoge, so that I can do honyahonya.」という形になる。日本語だと「hogehogeとしてはhonyahonyaするために、hoehoeしたい」となる。
脚本(Scenario)例
脚本： 一人の登録が1%進捗と表示される場合
- (Given: 前提) 200人が目標人数の場合
- (When: 操作) 一人が申込登録すると
- (Then: 結果) 1%進捗と表示される*6
脚本： あと一人の登録で99%進捗と表示される場合
- (Given: 前提) 200人が目標人数の場合
- (When: 操作) 199人が申込登録すると
- (Then: 結果) 99%進捗と表示される*7
前提があって、操作があって、期待される結果がでてくる。これは受入テストの項目でもあり、RubyだとRSpecでほぼそのまま記述できちゃう、と。
まとめ
「フィーチャ」「ストーリ」「シナリオ」を大和言葉で表記できないかと考えてみた。英語を母国語とする人達はこれらの言葉の間に記述粒度の差があるのを最初から理解しているのかもしれないけど、日本語を母国語とする自分にはそこが理解しにくい。
特徴・粗筋・脚本という訳は、多少なりともこの「粒度」を表現できているのではないかな。
追記
- 粗筋・脚本という概念と比べるとFeatureの「特徴」ってのはちょいと異質だよな...
- ブックマークコメント*8でid:kakutaniさんも「悩んだあげくカタカナにした」と書かれているけど、確かに悩ましい。
- id:shuji_w6eさんが「元の用語（英語）にも解釈がいろいろあって、その翻訳語が決まっていなくて、さらに解釈がバラバラ。それなら、英語のままのがマシなのかと」と書かれているけど、それならば最初から全部英語でやればいいじゃん、と思ってみたり。
- id:erokonsaiさんの「カタカナだと英語でググりたいときに便利。変に日本語化されているために元々どういう英語だったのか分からなくて悶絶する」という理由も「ああ、そういうのってあるよね」と開発者の立場では思ってしまうが、だからといってお客さん(特に意思決定者)にまで同じ土俵に立つことを強要するのはよろしくないであろう。
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
- 作者: Mike Cohn,マイクコーン,安井力,角谷信太郎
- 出版社/メーカー: 毎日コミュニケーションズ
- 発売日: 2009/01/29
- メディア: 単行本（ソフトカバー）
- 購入: 74人 クリック: 764回
- この商品を含むブログ (226件) を見る
