ユーザ系SEの業務内容　外部設計

外部設計では画面設計、帳票設計、DB設計、処理概要の設計、IF設計、バッチ設計を行います。
要件定義書の内容をシステム化していくフェーズということでここからがSEの腕の見せ所です。

・画面設計
ユーザは画面や帳票を用いてシステムを利用します。
ユーザにとって必要な情報を表示し、業務を遂行できる機能を持ち、
入力が行いやすい画面を設計する事を目的として画面設計は行われます。
ユーザ業務に一番近いところの設計なので画面設計の進行は常にユーザの確認、レビューを受けつつ勧めていく事になります。
(レビューとは、決定権を持つ人に設計書の内容を確認、承認してもらうこと)
ユーザとの打ち合わせでは紙に画面のイメージを描いて、
画面上のボタンをクリックした際のアクションやチェック処理内容を画面動作の仕様書に書いて、
「ここのボタンを押したらこうなります」
「ここの画面ではこういう内容を登録します」
「データ登録時にはこのようなチェックを行います」
と言う事をユーザに説明します。ここでユーザから
「画面表示の項目が足りない」
「この機能も追加して欲しい」
等の画面設計上の要望が出るのでSEはそんな要望を聞き出して、設計に反映していきます。失敗するプロジェクトはユーザーによるレビューが不充分なのではないかと思います。
(そもそもレビューを担当するユーザがエンドユーザの業務をあまり理解しておらず、なんかよくわかんないけど承認して、後工程で動くモノを見て覆すなんてパターンもあります)
画面一つ一つに対して、ボタン動作、チェック処理、入力項目、画面デザインを入念に打ち合わせし、打ち合わせの議事録をしっかりとる、画面設計の進め方には王道は無く、地道な検討作業を時間をかけて行うしかないと思います。
ユーザが気づかない様なチェック仕様や画面仕様にどれだけ気づくことが出来るかがSEの良し悪しの分かれ目になります。
この「気づき」が出来るかどうかには経験がモノをいうと思います。
僕は数年前に始めて画面設計の仕様検討に参加したりしたのですが、悲しいぐらいに何もできなかったです。
ベンダーが作った設計書をユーザと共に確認、レビューする業務を担当しましたが当時の僕は中途で入社した1年目でプログラムや内部設計はひととおり経験したことはあれどデータ登録時の入力チェックには何を実装すべきか、といった観点で設計書を点検する事が出来ませんでした。
あらかじめユーザが画面で行う動作を想定して、どのような誤入力が発生するのか、入力内容のチェックにはどのようなものが必要なのかということを洗いざらい挙げていく必要があると思います。
(システムについて妄想しろ！ってよく上司に言われました)

かつての失敗では「検索結果をソート出来ない」画面を承認したこともありました。検索結果をソートしたいのはどこでもある要求事項でそれぐらいできて当たり前なんですが、設計書にはソートできることなんてどこにも書いていなかったんですね。設計書を作るときの考え方の基礎になる画面標準にもソートできるようにすることなんて書かれていませんでした。
だけど、単体テストが完了して動くものが見えてくると「あれ、ソートできないぞ、どういうことだ？」ってなるんです。

このソートできない問題は揉めに揉めて解決するまでに1年以上要しました。なんせほぼ全画面に影響しましたから。結局仕様変更ということで開発ベンダーにお金を払って修正してもらいましたが、画面設計の時点で
「これ、ソートできないよ！このままじゃ承認できない！」って気づくことができたらこのような無駄なお金や時間をつぎ込む必要もなかったのです。

画面設計フェーズではどんな些細な事でもいいので画面操作を阻む要素がないかを点検する必要があります。

あと地味だけどよくある失敗が「文字が小さくて見づらい」という指摘です。20代、30代の人間にはわかりずらいのですが、歳をとるとディスプレイ上の文字が小さいと読みづらくてなにかとよく指摘されます。
画面に表示する以上、ユーザに見えないと意味は無いのです。
可能な限り表示する文字は大きく表示する工夫をすると喜ばれると思います。

ユーザが後工程になってから「こんなはずではない！」と言う事が無いように画面仕様について合意し、その事実を文書で残すことがとても大切になります。ユーザ合意の上での画面仕様であることが後工程になってからもわかるようにユーザとの打ち合わせの議事録、レビューにおけるユーザ承認の記録はしっかり残す必要があります。
なぜかというと、ユーザは必ず後工程(受入試験等)になって、実際に動作する画面を確認すると、
「この値が画面に出ていないのは使いづらい」とか「このリストではこのようなデータの出方はしない」
と不具合の報告を挙げてきます。この不具合報告に対して本当に対処すべきなのかを切り分ける必要があります。そのときの判断の根拠となるものがユーザ打ち合わせの議事録です。
過去の会議で一旦決まった仕様を覆そうとしているのであれば、その不具合報告には対応する必要はありません。(仕様変更として別途開発費用を支払わない限り対応しなくても良い案件となります)