TOC
単語
帳票設計 | 表单设计 | ||
意匠設計 | いしょうせっけい | 美术设计 | |
完成予想図 | かんせいよそうず | ||
クライアント・サーバー系 | client-server | ||
専門の方 | せんもんのかた | 专业人士 | |
紙芝居 | かみしばい | 拉洋片,连环画 | |
作り直し | つくりなおし | (在某个基础上)修改 | |
つながり | 连接 | ||
不明なこと | 不明确的地方 | ||
伴い | ともない | 伴随 | |
基幹系 | きかんけい | 业务应用类 | |
旧来 | きゅうらい | 过去的 | |
コンボ・リスト | 复合列表 | ||
連動する | れんどうする | 互相联动 | |
セッション | session | ||
好ましい | このましい | 期望的,喜欢的 | |
コストかかる | 话费代价 | ||
パフォーマンス | 性能 |
ポイント
-
少し、違います。 → 还是稍微有所不同的。
-
そんなに簡単とは思わないのですけど。 → 可是,我并不认为那样简单。
-
納品するつもりです。 → 〇〇つもりです。
-
相当無理があるようです。 → 好像非常困难的哦。
-
あまり好ましくありません。 → 不太喜欢。
会話
会話の背景
- 詳細設計に入る前に、最後の作業として画面設計と帳票設計がある。
- ここで言う画面設計とは画面の意匠設計ではなく、システムとしての完成予想図をユーザーに伝えるための設計のことである。また、ウェブ系のシステムの画面設計は従来のクライアント・サーバー系と相当違いがあるので、十分気を付けなければならない。
登場人物
- 石田:プロジェクトマネージャー
鈴木:開発チームリーダー
山田、田中:開発チームメンバー
会話内容
-
石田:
- こんにちは。今週までに、ユースケースをはじめ、用語辞書まで出来上がりましたので、いわゆる要求分析段階のドキュメントはほとんど出来ました。
- 今週からは画面設計に入りたいのですが。
-
山田:
- 画面設計とは、先日鈴木さんなどが画面のレイアウトなどをやっていたことを時々見ましたが、それのことですか?
-
鈴木:
- ええ、それは画面設計とも言えますが、少し、違います。私が先週からよその意匠設計専門の方と打ち合わせしたりして、今回のシステムのすべて画面のレイアウトやアイコン、また会社ログなどは大体決まりました。
- 石田さんが言った画面設計とは、おそらく我々のシステムの全部の画面作成だと思います。そうでしょう、石田さん?
-
石田:
- その通りです。
- 今日皆を集めて、画面設計をやってもらうことは、我々のシステムの完成予想図を示すためのものです。もっと具体的に言うと、今回はウェブシステムなので、HTMLで全てのデモができる画面を作り出すことです。
-
山田:
- HTMLなら簡単だと思いますので、大丈夫だと思います。
-
鈴木:
- そんなに簡単とは思わないのですけど。今回皆に作ってもらうHTML画面はシステムの紙芝居のように動かないといけないという要求があります。というのは、各画面では、例えば特定のリンクを押すと、指定した画面へ遷移することが必要です。
-
田中:
- それは大変ですね。
-
鈴木:
- そうですけど、いわゆる紙芝居のようなものなので、例えば10行のリストがあり、リストの各行には追加、削除というボタンがあるという場合に、設計したHTML画面中の各行に追加と削除ボタンをつけますが、おそらくただ一行だけ追加ボタンが有効で、また別のある行だけでは削除ボタンを有効にしているかもしれません。すべての行にすべてのボタンを有効にする必要はありません。
-
田中:
- なるほど。しかし、それでも工数が必要ですね。
-
石田:
- そうですが、やはりやらないといけないと思います。
- なぜというと、まずは、我々ここまでユースケースなどをたくさん書きました。これらはユーザーさんのIT部門の方にチェックしていただきますが、普通のエンドユーザーには、それだけだと、ちゃんと理解するのに無理があります。それで、このシステムの完成予想図として、動いているようなものを見せないといけない。エンドユーザーに、開発出来たらシステムはこのようなものだ、と言いたい訳ですから。
-
鈴木:
- これには、相当的な工数がかかりますが、無駄とは思いません。
- 我々は今回の実際的なシステムでは、画面の部分はJSPで書きますので、HTMLで書いた画面設計のファイルを徐々にJSPへ作り直していけばいいと思いますから。
- 今は画面のレイアウトやアイコン、また会社ログなどができましたので、サンプルとして皆に配布します。皆がこれをベースにして、各自のユースケースに基づいて作ってもらいたいです。
-
山田:
- ユースケースだけだと、画面と機能のつながりが不明なことがよくありますが、どうすればいいでしょうか?
-
鈴木:
- これはいい質問です。私の方は1つの機能リストを書きました。このリストでは各画面上でどんな機能がありそうだ、どこへ遷移するなど、大体書きましたので、皆に参考してもらいます。
- それと、皆の作業に伴い、私のほうがこの機能リストを画面遷移フローへ変換しますから。最後には、私たちの画面設計と私の画面遷移フローと一緒に開発ドキュメントとして納品するつもりです。
-
山田:
- 分かりました。ところで、今のHTMLで作るウェブの画面設計と以前のクライアントサーバーの画面設計とはどんな違いがあるのでしょうか?
-
鈴木:
- そうですね。ウェブの画面にはいくつかの特徴があります。
- まずは、特にビジネスあるいは基幹系のシステムでは、ウェブの画面はなるべく簡単にする必要があります。例えば、大抵1つの画面では1つのテーブルしかなく、1つのテーブルには2、3個のボタンが独立して存在するようなものです。旧来のクライアントサーバー系の画面設計のように、1つ画面では複数のテーブルやコンボリストがあって、あちこち連動することはウェブには相当無理があるようです。
- それと、ウェブ上ではセッションの概念があるので、複雑で長いセッションはあまり好ましくありません。今の画面設計と後の実現では、ビジネスのアクションをできるだけ単純で短くした方がいいと思います。いくつかのビジネスアクションが連続していて長くなると、ネットワーク上で何が発生するのか予想できませんから。
-
山田:
- 通常のウェブサイトでは皆がフラッシュなどをよく使って、動画的な効果を出していて、感動しますが、我々も使いますか?
-
鈴木:
- それはケースバイケースですね。動画的な効果にはコストがかかると思いますから。今回我々が開発しようとするシステムはビジネスシステムなので、ビジネスの正確性、操作の簡単さ、システムのパフォーマンスなどが最優先なので、動画的な効果はなくてもいいでしょう、残念ですけど。
-
山田:
- そうですか。分かりました。
-
石田:
- それでは、皆さん、鈴木さんの書いた機能リストと各自分担したユースケースにより、画面設計の作業に進んでください。
- 今日のミーティングはここで終わりにします。皆さん、ありがとうございます。
-
皆:
- どうもありがとうございます。
「真诚赞赏,手留余香」
真诚赞赏,手留余香
使用微信扫描二维码完成支付
