設計で気を付けること

##神は激怒した
要件定義から進めていた案件がある。
詳細設計、開発工程までいって、順風満帆だと思われた…のだが。
神の一声¹で設計書の手戻りが起きた。

今後のため、設計書を見直すときのポイント、
新たに設計するときに気を付けるべきポイントをまとめてみる。

##設計で気を付ける事
###原則は開発工数＜ユーザ利便性
開発者のためのシステムではない。
工数がかかるなら、見積もり出すときに聞けばよい。

###現行システムの保守・機能追加なら親切度を合わせる
本当はあるべきな親切機能だったとしても、既存の機能でやってない事なら慎重に。
なんでここにはあるのに、ここではないの？とか聞かれるリスクがある。

###顧客説明用資料と実設計書の整合性
実設計書を正として顧客説明用資料を捨てるプロジェクトもあれば
顧客説明用資料も同時に修正しないといけないプロジェクトがある。

###開発サイドの意思は明確に示す
A案B案ある場合は、顧客に判断を丸投げしない。
原則はこうしようと思うけどいいですよね？という姿勢で。
判断をゆだねると、先に進まない事が多い。

###画面名、機能名は正式名で書く
開発現場での通称とかで書いちゃう事が多い。

###画面項目名は正式なもので書いているか
「～名」という項目が、が「～名称」という項目名になってたり。

###画面のレイアウトと設計書の項目定義の順序は一致しているか
単体テストで気づくとは思うけど、tabindexとかも見直しが必要。

###画面の遷移方式に変更がないか
ポップアップ、遷移、etc...。

###新規テーブル作るなら、IDに変更はないか
自分が知らない間に進んでる別案件で、いつの間にか採番されて使えなくなってる事がある。
まぁこれはプロジェクトそのものの管理体制の問題だけど。

###DB項目に増減がないか
要件が変化する中で、主キーが変わる場合がある。

###DB項目にお作法がないか
機能的にはいらないけど、暗黙のお作法で主キーに設定しないといけないものとか。
あとは作成日時とか論理削除とか、使わなくても絶対つけようねって項目があったりする。

###制限は変わっていないか
文字数制限とか変化しているとき見落としがち。

###図形の中身も変わっているか
吹き出しとか、フローチャートとか。
一括置換とかしたときに取り残されやすい。
自分の中に旧仕様の知識があるので、見逃しがち。

###バックアップは細かくとる
gitとかあるならブランチ切ってちょこちょこ入れる。
先行して改修したけど、やっぱいらないよねってなる事も多い。
たまに残ってる、ファイルサーバでの人力バージョン管理システムは早く絶滅してほしい。

###体裁を統一する
段落の附番方式、フォント、罫線、英数字の全半角。
MSゴシックとMSPゴシックがこっそり混在してたりする場合がある。
全部等幅にすればよいのに

あとは設計書の上のほうにある作成日付、作成者、更新日付と更新者とか。新規作成時も更新日付書くのか？
プロジェクトによってルールはまばら。
ここの履歴情報って、バージョン管理システムで対応するべきものだと思うので、廃止していただきたいが・・・。

###リンクとボタン
aタグで画面遷移するやつをリンクというところもあればボタンっていうところもある。
何が違うのって話だけど、使い分けるところもあればどっちかに表現寄せるとこもあるので気を付ける。

###判定条件に可変項目を指定するとき
ユーザが入力する項目を判定条件にする場合は入力パターンを考慮する。
システムでしか入れないと思ってたワードも、手入力される場合があったりする。

###承認が必要？
あれやってこれやってって要件を言われて、それが技術的に実現可能だとしても。
具体的にこの資産のここをこう直しますよっていうのと、本当にその対応していいのかって
いちいち顧客に聞かないといけない場合がある。

##終わりに
他にも出てきたら、追記する。

1. 顧客と合意した仕様であったが、第三者の指摘で要件が変化した。所謂メテオフォール型開発である。神が１人で助かった。 ↩