会話の背景：
システム分析段階では、用語辞書の作成を大事にしなければならない。
ユースケースやコンセプト図または詳細設計時のクラス図などもこの辞書で定義される用語に基づいて作成する必要がある。
用語辞書のライフサイクルはプロジェクトまたはシステムと同じであり、用語辞書をシステム分析からメンテナンスまで、ずっと維持する必要がある。また、すべてのプロジェクト参加者は、必要に応じて用語辞書を参照しなければならない。そうすることにより、コミュニケーション上（じょう）で起こる相互理解の不足や誤解を回避（かいひ）することができる。
登場人物：
近藤― システムアーキテクト
鈴木― ＰＬ
山田、田中―ＰＧ
会話：
鈴木：こんばんは。今日の昼には時間がなかったため、午後のミーティングはいまからしますが、よろしくお願いします。
そろそろユースケースの作業が終わり、前回議論していたコンテキスト図やコンセプト図なども作成しています。今日は近藤さんに用語辞書のことを皆さんに説明してもらいたいと思います。
田中：われわれも辞書を作るのですか？
近藤：そうです。ここでの用語辞書と言うのは、われわれがこのシステムを開発するために必要な辞書のことです。
田中：それにはなにを載せるのでしょうか？
近藤：基本的には、われわれがいまから使う言葉、名詞や動詞でも、用語辞書に入れてもらいます。
田中：その辞書の目的は？
近藤：そうですね。今、われわれは分析をしていますが、これから詳細設計に入り、その後はコーディングをします。そのときクラスを定義したり、メソッドを定義したりしますから、用語をちゃんと定義しないと、今話していることが、これから開発するシステムと整合性が取れなくなる恐れもあると思います。
田中：そうすると、各項目には、どんなものがありますか？
近藤：これははっきりとルールはないですが、われわれの経験だと、ひとつの項目には名前、英語名、意味・記述、連語、用例などが必要と思います。
鈴木：例をあげていただけるでしょうか？
近藤：いいです。
たとえば、見積という項目を例として、以下のようになると思います。
名前：見積
別名：見積もり
英語名：Quotation
意味．記述：お客様が注文する前に、品物の値段や品番などをまず調べる。そのときの問い合わせは見積と定義する。
連語：見積依頼、見積書作成、見積情報の照会など。
用例：お客様が見積を依頼する。
山田：それはわかりやすいですね。これだと開発するときにはみんなで、同じ言葉を使うことができます。
近藤：用語辞書は開発するときに使うだけではなく、メンテナンス時にも使います。こんな辞書がないと、メンテナンスの人は大変ですから。
山田：そうすると、この用語辞書のライフスタイルはプロジェクトまたはシステムとおなじになりますね。
近藤：そうです。
全てのプロジェクト参加者は用語辞書を参照しますから、システム分析からメンテナンスまで、用語辞書をずっと維持する必要があります。
鈴木：それはいいですけど、しかし、だれが責任を持ってこの辞書を作るか、誰が責任を持ってこの辞書を維持いていくかが問題ではないかと思いますけど。
近藤：その通りです。用語辞書に関しては、まず作成また編集の責任者が重要です。というのは、用語はシステムの各側面から出てくるので、できるだけ、みんなから集める必要があります。その集める方法を考えなければなりません。
鈴木：そうですね。用語辞書の配布（はいふ）も問題になると思います。これまでのやり方だと、紙に印刷して開発チームメンバーに配ることはできます。しかし、特に特に分析設計段階では用語辞書もよく変更されますので、いちいち配布すると、紙も無駄だし、皆に混乱を生じる恐れもあります。
近藤：最近、ウエブの方法で用語辞書を作ったり管理したりする方法が普及して来ました。というのは、用語辞書のサイトを立ち上げれば、皆が追加することができます。またどこでもいつでも参照することもできます。いかがでしょうか？
鈴木：それはいいと思います。
山田：最近ＷＩＫＩというものを見ました。あれを使えば、チームメンバーが自由に追加したり、参照したりすることもできます。できれば、適当なＷＩＫＩエンジンを使って、用語自称を作ったらどうでしょうか？
鈴木：それはいい考えかもしれませんね。早速参考にして作ってみましょう。
今日はここまでにしましょう、近藤さん、どうもありがとうございました。皆さん、どうもありがとう。
皆：どうもありがとうございました。
８．画面設計
会話の背景：
詳細設計に入る前に、最後の作業として画面設計と帳票設計がある。
ここでいう画面設計とは画面の衣装設計ではなく、システムとしての完成予想図をユーザーに伝えるために設計のことである。また、ウエブ系のシステムの画面設計は従来のクライアント・サーバー系と相当違いがあるので、十分気をつけなければならない。
登場人物：
石田― プロジェクトマネージャー
鈴木― ＰＬ
山田、田中― ＰＧ
会話：
石田：こんにちは。
今週までに、ユースケースをはじめ、用語辞書までできあがりましたので、いわゆる要求分析段階のドキュメントはほとんどできました。今週からは画面設計に入りたいのですが。
山田：画面設計とは、先日鈴木さんなどが画面のレイアウトなどをやっていたことを時々（ときどき）みましたが、それのことですか？
鈴木：ええ、それは画面設計ともいえますが、少し、違います。私が先週からよその意匠設計専門の方と打ち合わせとしたりして、今回のシステムの全て画面のレイアウトやアイコン、また会社ロゴなどは大体決まりました。
石田さんが言った画面設計とは、おそらくわれわれのシステムの全部の画面作成だと思います。そうでしょう、石田さん？
石田：その通りです。
今日皆を集めて、画面設計をやってもらうことは、われわれのシステムの完成予想図を示すためのものです。もっと具体的に言うと、今回はウエブシステムなので、ＨＴＭＬですべてのデモができる画面を作り出すことです。
山田：ＨＴＭＬなら簡単だとおもいますので、大丈夫だと思います。
鈴木：そんなに簡単とは思わないのですけど。今回皆に作ってもらうＨＴＭＬ画面はシステムの紙芝居のように動かないといけないという要求があります。とういうのは、各画面では、たとえば特定のリンクを押すと、指定した画面へ遷移することが必要です。
田中：それは大変ですね。
鈴木：そうですけど、いわゆる紙芝居のようなものなので、たとえば10行のリストがあり、リストの各行には追加、削除というボタンがあるという場合に、設計したＨＴＭＬ画面中の各行に追加と削除ボタンをつけますが、おそらくただ一行だけ追加ボタンが有効で、また別のある行だけでは削除ボタンを有効にしているかもしれません。全ての行にすべてのボタンを有効にする必要はありません。
田中：なるほど。しかし、それでも工数が必要ですね。
石田：そうですが、やはりやらないといけないと思います。
なぜかとういうと、まずは、われわれここまでユースケースなどをたくさん書きました。これらはユーザーさんのＩＴ部門の方にチェックしていただきますが、普通のエンドユーザーには、それだけだと、ちゃんと理解するのに無理があります。それで、このシステムの完成予想図として、動いているようなものを見せないといけない。エンドユーザーに、開発できたらシステムはこのようなものだ、といいたい訳ですから。
鈴木：これには、相当的な工数がかかりますが、むだとは思いません。われわれは今回の実際的なシステムでは、画面の部分はＪＳＰで書きますので、ＨＴＭＬで書いた画面設計のファイルを徐々にＪＳＰへ作り直していけばいいと思いますから。
今の画面のレイアウトやアイコン、また会社ロゴなどができましたので、サンプルとして皆に配布します。皆がこれをベースにして、各自のユースケースに基づいて作ってもらいたいです。
山田：ユースケースだけだと、画面と機能のつながりが不明なことがよくありますが、どうすればいいでしょうか？
鈴木：これはいい質問です。私の方は一つの機能リストを書きました。このリストでは各画面上でどんな機能がありそうだ、どこへ遷移するなど、大体書きましたので、皆に参考してもらいます。
それと、皆の作業に伴い、私の方がこの機能リストを画面遷移フローへ変換しますから。最後には、私たちの画面設計と私の画面遷移フローと一緒に開発ドキュメントとして納品するつもりです。
山田：わかりました。
ところで、いまのＨＴＭＬで作るウェブの画面設計と以前のクライアントサーバーの画面設計との違いがあるのでしょうか？
鈴木：そうですね。ウェブの画面にはいくつかの特徴があります。まずは、特にビジネスあるいは基幹系のシステムでは、ウェブの画面はなるべく簡単にする必要があります。例えば、大抵（たいてい）一つの画面では一つのテーブルしかなく、一つのテーブルには２，３個のボタンが独立存在するようなものです。旧来のクライアントサーバー系の画面設計のように、一つ画面では複数のテーブルやコンポリストがあって、あちこちの連動することはウェブには相当無理があるそうです。
それと、ウェブじょうではセッションの概念があるので、複雑で長いセッションはあまり好ましくありません。いまの画面設計とあとの実現では、ビジネスのアクションをできるだけ単純で短くしたほうがいいと思います。いくつかのビジネスアクションが連続していて長くなると、ネットワーク上（じょう）でなか発生するのか予想できませんから。
山田：通常のウェブサイトでは皆がフラッシュなどをよく使って、動画的な効果を出していて、感動しますが、われわれも使いますか？
鈴木：それはケースバイケースですね。動画的な効果にはコストがかかると思いますから。今回われわれが開発しようとするシステムはビジネスシステムなので、ビジネスの正確性、操作の簡単さ、システムのパフォーマンスなどが最優先なので、動画的な効果はなくてもいいでしょう、残念ですけど。
山田：そうですか。わかりました。
石田：それでは、皆さん、鈴木さんの書いた機能リストと各自分担したユースケースにより、画面設計の作業に進んでください。きょうのミーティングはここで終わりにします。皆さん、ありがとうございます。
皆：どうもありがとうございます。
