実践 ICONIXプロセス : 要求レビュー ユースケース記述

もっとも重要なユースケースから順番にレビューしてもらう。

ICONIXプロセスでは、ユースケース記述は、画面名やボタン名と用語集(ドメインモデル)の言葉を使って、具体的に簡潔に書くので、文章形式でも、レビューは十分やってもらえる。

ドメインモデルとユースケース図のレビューと改良が終わっているので、内容に違和感はないはず。

さらに効果的にやるために、ユースケースに登場する「すべての画面」を線画などで模型を作って、それを紙芝居風に順番に見せながら、ユースケースを説明していく。

すべてのユーザアクションと代替コースの説明ができる程度に、画面の詳細も描いておく。(ユースケースを書くときに、必ず画面の線画を描きながらユースケースを書いていく)

まず、基本コース。 
・晴れの日のシナリオは、ほんとうにユーザの期待にぴったりか?
・晴れの日のはずなのに、ユーザに何かひっかかりはないか?

それが終わったら、代替コースをひとつづつ順番に。

・雨の日のシナリオに違和感はないか?
・雨の日のメッセージ内容、画面の動きは、ユーザを混乱させないか?

最初は、ユーザ側と開発者の間にいろいろな意識の違いがあることがはっきりします。そもそも、画面名やボタン名が、ユーザには違和感があることが多い。

そこが重要。実際に動く画面まで作ってからのレビューは、手戻りが多い。そもそも時間的に修正がまにあわないかもしれない。

ユースケース記述のレビューの段階で、そういう違和感を検出し、修正できる効果は絶大です。

そのためにも、ユースケースの記述は、
・画面名、ボタン名は具体的に決めて記述する。
・代替コースのメッセージも含め、すべての画面の模型(線画)を描きながら、ユースケースを記述する。

ICONIXプロセスのユーズケース記述は、ユーザにわかる用語を重視して書きますが、記述の内容は、画面フローと画面処理のコーディングときわめて近い。

代替コースの記述は、そのまま if 文のコーディングになる感じ。

これがICONIXプロセスの手品のネタの一つです。

技術者からみるとコードの設計・記述にとても近い。
要求側からみると、自分たちにわかりやすく書かれている。

理解や考え方の違いが、ユースケース記述という最初の段階で、かなり具体的に発見でき、その修正は、コードの改良と直結している。

現場で実践してみると、これがマジックでもなんでもないことがよく実感できます。業務ニーズについて、技術者の勘違いや見落としを、いとも簡単に発見できます。

実践 ICONIXプロセス : 要求レビュー ユースケースパッケージ図とユースケース図

ユースケースパッケージ図
機能一覧であり、メニュー体系です。

アクター名、ユースケース名、パッケージ名がユーザにしっくりくる名前になっていて、パッケージのまとめ方も違和感がなければ、ユーザから特に指摘はでません。

ユーザから何か発言があったら、丁寧に受け止めましょう。どこに見落としがあったか、どこがユーザと感覚が違っていたかを発見することに集中しましょう。

全体の機能の中で、現在は、この部分(パッケージ)から取りかかっている、という優先順位が正しいかも、このユースケースパッケージ図で確認できます。

ユースケース図

それぞれのパッケージ単位とか、優先して取り掛かっているユースケースについて、ユースケース図で確認してもらいます。

このとき、気をつけること。
・アクターとユースケースの線はできるだけ少なくする。なくとも良い。
・ユースケースの包含、拡張は「絶対に」やらない。
・ユースケースから別のユースケースへの連携( precedes や invoke ) は、単に矢印で示す。

ようするに、UML 的な表現は一切やめるということ。

・顧客が使う機能は、これこれです。
・操作の流れは、これこれです。

ということがぱっと理解できる図にする。

ユースケース図も、ユースケースパッケージ図も、ユーザに説明が不要なレベルを目指してください。

もちろん、質問やコメントは丁寧に受け止める。要求する側の意図、優先度を開発者が取り違えている兆候です。 どこが理解が一致していないのかを把握して、図を修正しましょう。

【注意】
思考を停止して、言われたとおりに図を修正してはだめ。
自分で考えて、理解しなおした内容を確認するために、図を修正する。修正したら、レビューしてもらい、理解が一致していることを確認する。

関係者でいろいろな理解の不一致がある。優先順位の考え方の違いがある。これが大前提です。だから、誰にでも共通にわかる言葉と表記方法で、ドメインモデリングとユースケースモデリングをやり、レビューして、不一致点を早く見つける。

それが、ICONIXプロセスの「要求レビュー」の目的。この時点の不一致の発見の価値はほんとうに大きい。

コードを書いてからの、リリースが迫ってからの不一致の発覚は悪夢です。

実践 ICONIXプロセス : 要求レビュー ドメインモデル

要求レビューで、ドメインモデルはクラス図の形式なので、ユーザが引いてしまうことがあります。

これを避け、実りあるレビューにするために。

ユーザにわかる言葉だけ使う

ICONIXプロセスでは、ドメインモデルは「用語集」です。システムが何ができるべきかを説明するときの、関係者の共通の言語です。
Domain-Driven Design ( DDD : ドメイン駆動設計 ) の ユビキタス言語パターンですね。

ドメインモデル図上の言葉は、ユーザが分かる言葉を使うことに時間とエネルギーを使ってください。「ユースケース駆動開発実践ガイド」では、最低でも80%の用語は、ユーザにわかる言葉にすべきとガイドしています。 

ドメインモデリングの過程でユーザが作成した資料とは別の、より妥当と思われる言葉が見つかることがあります。 概念がわかりやすくなるのであれば、そういう言葉は積極的に使うべきです。 (ユーザに分かりやすいこと、が前提です)

もし、ユーザの言葉と新しい概念(言葉)が一致しないときは、画面の紙芝居のほうは、ユーザの言葉にしておいて、ドメインモデルの用語との対応関係を画面で説明すると、わかりやすい。

例えば、画面の「足跡」情報はドメインモデルでは「アクセス履歴」としています、という感じですね。

ドメインモデルのレビューは「違和感のある言葉や意味の通じない言葉を指摘してください。」と切り出します。
指摘は素直に受け取りましょう。ユーザにぴんとこない言葉は、たぶん理解のズレを表しています。 説明して納得してもらうのではなく、別のより適切な、ユーザに分かりやすい言葉をいっしょに探しましょう。

汎化

汎化のシンボルの説明はしないこと。「汎化・特化」なんていう言葉はタブーです。

モデルを説明するときに、
「支払い方法」の種類には「クレジットカード」「現金振込み」「代金引換」があります。
と具体的に説明する。図の配置もこのグルーピングがわかるように描く。

これ以上、よけいな説明は不要です。概念(用語と整理のしかた)に違和感がなければ、ユーザからは質問はでてきません。

汎化・特化は、人間の思考であたりまえのやり方なので、概念が自然を描ければ、UMLの知識がまったくない人にも違和感は生じません。

集約

集約は、菱形の記号がみなれないため、多くのユーザがとまどいます。まちがっても「集約」という言葉で説明しないこと。

ドメインモデルの「集約」のほとんどは、
・ひとつの画面にいっしょに表示する情報 (それも中核の画面)
または
・ある画面からリンクでナビゲートする情報
として実現します。

ですから、画面イメージでこの集約関係を説明するとわかりやすい。

説明の例:

「書籍一覧」画面から「書籍」画面に遷移します。
「書籍」画面に、「著書」・「出版社」・「顧客レビュー」を表示します。

もちろん、ドメインモデル図は、すべての画面遷移を表しているわけではありません。
「基本」の遷移のみを示します。

集約の説明を、画面遷移の説明にすりかえる(?)ことで、いろいろな指摘がでてきます。

顧客レビューは、顧客プロファイルからも遷移できる、とかね。
その時に、「もっとも基本的な遷移はこれだと思うですが、どうでしょう?」という確認が効果がある。

そのソフトウェアをどう利用しようとしているか、何が重要な機能かの確認ができるわけです。

アプリケーションによっては、顧客プロファイルからたどる顧客レビューのほうが、書籍画面に顧客レビューを表示することより重大な関心ごとの可能性はある。

ドメインモデルの集約関係は、
・中核の画面とそこに表示する情報のグループの定義
・ミニマムな必須の画面遷移の定義
をあらわします。

ここを作らなくても良いから、こっちが欲しい、という指摘があれば、ドメインモデル図の関連を修正しましょう。

ここはもちろん必要。でも、こういう遷移も、という指摘は、ユースケースの追加候補です。

ユースケースとしてもおかしい「どこでもドア」が欲しいという画面遷移の要求は、私は、利用者にわかりにくい操作だと思うので、実装に反対します。「今は基本の流れをまず完成させましょう」とね。

言葉と配置

経験上、言葉がしっくりきて、上下や左右が自然な配置になっているドメインモデルはUML クラス図の形式でも、ユーザは違和感を持ちません。

・言葉がしっくりこない
・位置関係がしっくりこない
・線の意味がわからない

という指摘がでてきたら、良いことです。 ドメインモデルの問題箇所が見つかりました。 われわれの理解と顧客の理解が一致していない点が見つかりました。
しっくりくるようにモデルの改良に取り組みましょう。

受け入れテスト段階になって大騒ぎになる心配はまずなくなります。

早い段階で、ユーザとの理解の不一致を見つけることが、ICONIXプロセスの第3ステップ「要求レビュー」の目的です。

実践 ICONIXプロセス : 要求レビュー 小さくやる

ドメインモデルとユースケースモデルは、ユーザにレビューしてもらい理解の不一致を見つけ修正しましょう。

実りあるレビューは、レビューの範囲を小さくすることがコツ。

全体図の扱い

・ドメインオブジェクトの全体図
・ユースケースパッケージ図の全体図

全体の見通しとしては、この全体図は用意したほうが良い。
全体範囲についての議論が始まることもあるから。
でも、全体をレビューしようとすると、それぞれの出席者がばらばら視点や論点で話を始めてしまう。
議論を発散させないために、全体図を直接レビュー対象にしないこと。あくまでも参考の補助的な情報でであることを明確にする。

いちばん重要な部分を抜き出す

・現在、もっとも重要と考えているユースケース(記述)を1つか2つ
・そのユースケースに関連するドメインオブジェクトの部分図
・そのユースケースに関連するユースケースパッケージ図の部分図

レビューをやりやすくし、効果を最大にするために、かならず、重要な部分、問題の中核に絞った資料を用意して、その資料に集中してレビューをしてもらう。

大切なのは「重要」な部分に限定すること。
この時点で、モデル作成者が考えている「重要」なことと、顧客、利用者、アーキテクトが考えている「重要」なことの不一致が見つかる。

小さく限定すると、何を重要と考えるかの判断基準の不一致が簡単に発見できる。この不一致の発見は、ものすごく価値がある。
とりえあず、このユースケースを選びました、ではなく、「重要」だから選ぶ、その判断がみんなで一致しているか、確認する。 これが要求レビューの大きな目的です。

実践 ICONIXプロセス : 要求レビューのコツ

ドメインモデリングとユースケースモデリングをやったら、必ず顧客、利用者に要求レビューをしてもらう。

要求レビューは、使う側と作る側の理解の違い、意識のギャップを無くすことが目的。

ということは、要求レビュー中に、理解の違い、意識のギャップが見つかる、ということです。 ユーザ側から、なんの指摘もでない要求レビューは大失敗です。
かといって、ユーザ側と開発側とのギャップが大きすぎると、レビューは破綻しますね。

実りのある要求レビューをやるポイントは
・小さくやる
・ユーザの言葉にこだわる
・画面の模型を活用する
の3点です。

いずれも「ユーザーにわかりやすく」が基本思想。

実践 ICONIXプロセス : ステップ3 要求レビュー

ICONIXプロセスの第3ステップは「要求レビュー」

・ドメインモデル( 概念クラス図=用語集 )
・ユースケースパッケージ図 (メニュー体系)
・ユースケース ( 利用場面ごとのシナリオ )
・画面の模型(紙芝居、線画、モックアップ、プロトタイプ)

を用意して、

・顧客の代表者
・実際の利用者
・マーケティングの担当者
・開発者

が集まって、作っているものが「期待するシステム」なのか確認してもらう。

レビューではたくさんの理解の不一致が見つかります。
作ろうとしているものと、期待しているものとが合っていない点が見つかる。
それが、レビューの成果です。
要求レビューは、この理解の違いを早く見つけて、修正するための活動です。

ICONIX プロセスの最初の大きなハードルが、この要求レビューです。

なんの準備もなく、いきなりやろうとしても

・関係者が集まらない
・集まったが、会話がかみ合わない
・ムダな時間、気まずい時間(何のための会議?)

になりがちです。

でも、要求レビューがうまくできた時、ICONIXプロセスのやり方に大きな手ごたえを感じることができます。

ICONIX プロセスは、顧客と開発者、利用者と開発者の間のコミュニケーションを活発にするちょっとした手品です。

手品のコツや種明かしを書き留めてゆきます。

calendar
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< December 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM