画面設計とか外部設計とか、もうやめようよ

• 昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。
• よくよく見ると、FeatureとFunctionとがごっちゃになっていた。
• つまり、要件分析の段階で実装のことを考えていたのである。
• なぜ、そうなったのだろう？

画面から要件分析をすると、こうなる

• どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。
• 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。
• 紙芝居感覚で交渉できるからわかりやすい。
• だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。

• 実装をフィーチャとして捉える可能性。
  • 例えば「利用者は正しいIDとパスワードを入力することでシステムにアクセスする権限を得られる。権限には一般利用者、部門管理者、前者管理者が存在する。」というのは実はフィーチャではなく実装の話である。
  • 「部門管理者として、私は所属社員の電子メールアドレスを初期設定できる」、といった具合にストーリを記述することで「部門管理者ができること」を表現できる。
  • にも関わらず、認証の実装をフィーチャとして捉えると、その分工数は確実に増える。
  • そしてその受入テストは認証の実装を確認するテストと何が違うんだ？　というくらい重複したものとなるはずだ。

• ストーリの数が増えちゃう可能性
  • 実装をフィーチャとして捉えちゃうと、ストーリがどんどん増えてしまう可能性がある。
  • なぜなら実装を言葉でもって表記しているから...
  • 当然受入テストも増える。本来なら結合テストでやるべき話が受入テストにやってきてしまうのだ。

• 硬直化の可能性
  • 作っているうちに「こうUIを変えた方がいい」などの改善案が生まれるのは避けられない。
  • 先に画面を固めてしまうと、こういう改善を拒むような力が働く。
  • Agileじゃないでしょそれって。

対策

• 画面を忘れて、本来のフィーチャに集中して再度分析中。
• 今度は要件と実装とがきれいに区別できそう。

危険信号

要件定義の段階で下記にあるようなことを分析していたら、それはなんか変だと思ってよい。

• 「○○画面に対し、△△のデータを入力し...」→画面とかデータとかは実装。要件なら(極論だけど)紙と鉛筆、電話だけでも実現できるはず。
• 「権限」「ステータス」など、システム内部の話がでている。→明らかに実装と要件とを勘違いしている。

画面設計から入るのは、もうやめよう

• なぜ、先に画面設計からはいるのか考えたことある？
• 「昔からそういわれてきたから」とかそういう理由ではないか？
• あるいは「分業体制でそうせざるを得ない」とか？
• ツールや手法がその分業体制を無意味なものにしようとしている状況のもと、いつまで分業にこだわる必要があるのかね。
• 画面設計からはいる手法は、もうやめにしよう。

追記

• 議論のたたき台のために画面の見本を描くのは否定しないし、それで効率が上がるのならぜひやるべき。
• でも、「見本」は「設計書」ではない。その「見本」作成のために労力を投入しすぎるのはアホだよね。
• 「画面をどう実現するかを考えて要件分析する」というのは本末転倒。だけど、最初に画面を固めるとそうなりやすいし、結果として工数増加につながるよ、というのを言いたかったのですよ。

• 前にも書いてた→http://d.hatena.ne.jp/masayang/20071116/1195199460
• これとか...→http://d.hatena.ne.jp/masayang/20070402/1175584867

第一回ブックマークコメントへのお返事

• id:fujiyoshisyoutaさん「発注側が自分たちの仕事をよく判ってないせい。」
  • 補足しておきますと、このプロジェクトは発注側にも受注側にも「未踏」分野なんです。なので、発注側も受注側も「よくわかってない」状態です。そういう状態で、最初に画面をきっちり決めるのは相当リスクがでかいのではないかと。

• id:yamuyamさん　「まずは画面のモックがないと誰も完成図をイメージできない罠。どういうマンションができるのかCGで見せてあげないとローンを組んでもらえない」
  • マンションは形がありますが、ソフトウェアは形がありません。画面は静的な形をもっていますが、その挙動は紙芝居では表現できません。挙動については「触ってみて初めてわかる」ことがしばしば（あるいは頻繁に）あります。そして、触って初めてわかった結果、画面の中身を変えたくなることもしばしばあります。マンションは一度建てたら内装を変えるのが精一杯。なので、マンションを例えにするのは不適切でしょう。

• id:tkt33さん 「権限って要件の場合もあんじゃないの？」
  • 要件ではありますが、敢えてフィーチャとして切り出す必要はないです。

• id:osiireさん　「画面設計を軽視していると思われる節がある。ユーザーインターフェイスって難しいと思う。少なくとも「アジャイル」とか言いつつ気軽に変更できるものじゃない気がする。」
  • 設計とは実装、と考えれば上記発言はでてきませんよね。画面の実装を重視するからこそ、最初に画面を確定させないわけですよ。「じゃない気がする」などと想像で物事を判断しないためにも、Agileでちゃんと開発することをおすすめします。

• id:matebuさん　「いいたいことはなんとなくわかるんだけど、ユーザがどんな情報を持っていて（入力できて）、どんな情報を見たいか（引き出したいか）を分析し、ユーザにその仕様をコミットさせるために画面を介するのは最短な方法。」
  • 見本でやるのは否定しません。ただしそれは「画面」ではなく、もっと小さな単位（フォームとその実行結果）でやるべきでしょう。それをRESTで実装し、それらの部品の組み合わせで画面を表現していくことで、実際に動作する仕掛けの上でUIを検討・調整できるようになるわけです。

• id:moonsさん　「会計システム開発チームとＷｅｂチーム協同で案件やったときに、紙芝居作った方が良いと主張してたのはＷｅｂの人だったなあ。たしかに、デザイン変えづらかった印象があるけど、納期は短く仕様変更も少なく済んだ。」
  • もしかしたら、デザイン変えづらいから仕様変更を受け入れないようにしていた...なんてことはないですかね？

追記(2)

いろいろコメントをいただいているが、「先に画面ありき」という人達には

• 「要件をどうやって、いくらの原価をかけて検証するのか？」
• 「検証した結果、要件を満たしていないときにどうやって修正するのか」

という視点が抜けているんじゃないか、と思った。

アジャイルモデリング―XPと統一プロセスを補完するプラクティス (OOP Foundationsシリーズ)

データベース・リファクタリング