Hatena::ブログ(Diary)

サンフランシスコ出羽守手記(masayangの日記 このページをアンテナに追加 RSSフィード

2009-01-29 曇り一時小雨

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

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

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

  • どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。
  • 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。
  • 紙芝居感覚で交渉できるからわかりやすい。
  • だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。
  • 実装をフィーチャとして捉える可能性。
    • 例えば「利用者は正しいIDとパスワードを入力することでシステムにアクセスする権限を得られる。権限には一般利用者、部門管理者、前者管理者が存在する。」というのは実はフィーチャではなく実装の話である。
    • 「部門管理者として、私は所属社員の電子メールアドレスを初期設定できる」、といった具合にストーリを記述することで「部門管理者ができること」を表現できる。
    • にも関わらず、認証の実装をフィーチャとして捉えると、その分工数は確実に増える。
    • そしてその受入テストは認証の実装を確認するテストと何が違うんだ? というくらい重複したものとなるはずだ。
  • ストーリの数が増えちゃう可能性
    • 実装をフィーチャとして捉えちゃうと、ストーリがどんどん増えてしまう可能性がある。
    • なぜなら実装を言葉でもって表記しているから...
    • 当然受入テストも増える。本来なら結合テストでやるべき話が受入テストにやってきてしまうのだ。
  • 硬直化の可能性
    • 作っているうちに「こうUIを変えた方がいい」などの改善案が生まれるのは避けられない。
    • 先に画面を固めてしまうと、こういう改善を拒むような力が働く。
    • Agileじゃないでしょそれって。

対策

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

危険信号

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

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

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

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

追記

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

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

  • id:fujiyoshisyoutaさん「発注側が自分たちの仕事をよく判ってないせい。」
    • 補足しておきますと、このプロジェクトは発注側にも受注側にも「未踏」分野なんです。なので、発注側も受注側も「よくわかってない」状態です。そういう状態で、最初に画面をきっちり決めるのは相当リスクがでかいのではないかと。
  • id:yamuyamさん 「まずは画面のモックがないと誰も完成図をイメージできない罠。どういうマンションができるのかCGで見せてあげないとローンを組んでもらえない」
    • マンションは形がありますが、ソフトウェアは形がありません。画面は静的な形をもっていますが、その挙動は紙芝居では表現できません。挙動については「触ってみて初めてわかる」ことがしばしば(あるいは頻繁に)あります。そして、触って初めてわかった結果、画面の中身を変えたくなることもしばしばあります。マンションは一度建てたら内装を変えるのが精一杯。なので、マンションを例えにするのは不適切でしょう。
  • id:tkt33さん 「権限って要件の場合もあんじゃないの?」
    • 要件ではありますが、敢えてフィーチャとして切り出す必要はないです。
  • id:osiireさん 「画面設計を軽視していると思われる節がある。ユーザーインターフェイスって難しいと思う。少なくとも「アジャイル」とか言いつつ気軽に変更できるものじゃない気がする。」
    • 設計とは実装、と考えれば上記発言はでてきませんよね。画面の実装を重視するからこそ、最初に画面を確定させないわけですよ。「じゃない気がする」などと想像で物事を判断しないためにも、Agileでちゃんと開発することをおすすめします。
  • id:matebuさん 「いいたいことはなんとなくわかるんだけど、ユーザがどんな情報を持っていて(入力できて)、どんな情報を見たいか(引き出したいか)を分析し、ユーザにその仕様をコミットさせるために画面を介するのは最短な方法。」
    • 見本でやるのは否定しません。ただしそれは「画面」ではなく、もっと小さな単位(フォームとその実行結果)でやるべきでしょう。それをRESTで実装し、それらの部品の組み合わせで画面を表現していくことで、実際に動作する仕掛けの上でUIを検討・調整できるようになるわけです。
  • id:moonsさん 「会計システム開発チームとWebチーム協同で案件やったときに、紙芝居作った方が良いと主張してたのはWebの人だったなあ。たしかに、デザイン変えづらかった印象があるけど、納期は短く仕様変更も少なく済んだ。」
    • もしかしたら、デザイン変えづらいから仕様変更を受け入れないようにしていた...なんてことはないですかね?

追記(2)

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

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

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

trshugutrshugu 2009/01/29 00:47 これは激しく気をつけないといけない点ですね・・・
おそろしい!

なまえなまえ 2009/01/29 08:01 要件に実装を書くべきではないというのは真。
しかし、発注側に要件が書ける人が少ないし、受注側が要件から実装に落とせないというのもよくあること。啓蒙は必要だけど、プロジェクトにいる人材を見てケースバイケースで道具を変えるのが良いかと。。

masayangmasayang 2009/01/29 08:16 >>なまえさん

まあ現状から一気飛びというのは難しいかもしれませんが、「あるべき姿」を描き、そこに向けて人を育成していかないと、いつまでも同じことの繰り返しですよね。

なまえなまえ 2009/01/29 16:10 このエントリしか見てません。はてブコメも。
・お客さんに納入するものであるならば、システム発注者であるお客さんにわかる姿で見せ、説明し、納得してもらわなければならない。これは要件だろうが実装だろうが関係ない。それはそれを請け負ったプロの仕事であり責任範囲です。あなたは家を買うときに図面だけで判断でき、材料の扱い方や釘の使い方、接着剤の種類や塗り方は気にならないのだろうか?別の面では、最近医者に掛かると事細かに薬の効能を説明し、選択させてくれるのをどう思いますか?
・教育問題は、構築が社内で完結する場合と、社外要員を使い構築する場合では話が異なると思います。社外発注するということは、会社としてそういう専門スキルを社員に身につけさせるという選択肢を選んでいないだけです。社内システム要員がいる場合や、またはあなたが社内SEならば書いている通りだと思います。
・システムの規模は最重要でしょう。すべてをアジャイルで行いそれでお客さんに説明でき、かつ納得してもらえるのであれば、おっしゃるとおりです。しかし1,000人月(たぶん嫌いな言葉でしょうが)を超えるような大規模なシステムではそれは通用しません。
・もちろん上流コンサルの仕事が必要だとか十分だとか言ってる訳ではありません。やり方が間違っている可能性も高いでしょう。しかし、お客さんがシステム化を決めた後、見積もりからシステム導入を決め発注し、最後納入しシステムを利用し始めた後まで、必要な作業やステップはどのようなことかを考えてみてはどうかなと思います。コンサルは上流、あなたは納品まででしょうが、まさに家と同じくお客さんにとっては入居後(システム利用開始後)が一番大事なのです。プロと同じように開発スキルを勉強して身につけるべきだと言えば言うほど、プロの存在意義がなくなってくるのだと思います。

技術者は視野が狭くなりがちです。ついシステムの設計・開発・運用・保守効率だけを考えてしまいがちです。しかしシステムはあくまで使うためにあるわけで、使う人を最優先に考えるべきです。もちろん、それを重視するあまりコスト高になる場合には専門家としてアラートを発するべきでしょう。
私は以前、いわゆる上流から下流まで、要件分析から納品保守まで、数百人月規模のシステムを担当していた人間です。

masayangmasayang 2009/01/29 17:26 >要件分析から納品保守まで、数百人月規模のシステムを担当していたななしさん

でっかいプロジェクトをやっていたということはわかりましたが、その規模が本当に適切だったかどうかの考察はしましたか? 

要件定義の段階から水脹れになり、できあがったものは冗長重複無理無駄だらけで、テストは原始時代みたいに人力でやった結果、数百人月規模になってただけじゃないですか?

「使う人を最優先」に考えた計画管理・開発手法の集大成がAgileなんじゃないですか? Agileで開発したら、その数百人月規模のシステム開発がどうなっていたか、考えてみましたか?

trshugutrshugu 2009/01/29 18:50 >別の面では、最近医者に掛かると事細かに薬の効能を説明し、選択させてくれるのをどう思いますか?

これもやはりケースバイケースですよ。
効能なんて知りたくない!接着剤の種類なんてどうでもいい!
っていう人はたしかにいます。
それは怠慢ではなく、時間がないとかそんなこと考えてられない人たちです。


>Agileで開発したら、その数百人月規模のシステム開発がどうなっていたか、考えてみましたか?

人力でやらざるを得ないときってあるじゃないですか。
こんなに人間いらねぇよ!みたいな。
そういう管理者に対してその問いはとても残酷だと思います。

呆れるわww呆れるわww 2009/03/18 02:30 こりゃ酷いな、醜いなぁww
まともな議論の末が、これか、とほほほほ。
本性出しちゃってまぁ。このブログで何したいんだろかねぇ?

反論されて妄想書き連ねるのそ精神、もっと鍛えたほうがいんでねぇか?
あんた、要件定義する立場の人間になっちゃいかんよww

masayangmasayang 2009/03/18 11:07 >>220.213.237.160(posmail.toshin.com)から書いた人

誰に向かって何をいってるのかよくわからんのでもう一度書き直し希望。

マモーマモー 2010/05/21 22:14 ユーザーにとっては画面が製品そのものです。