##案件初期調査
開発業務にて、クォーターごとに案件対応をしていくと思いますが
依頼のきた案件について、開発側から調査を行います。
・業務上どんな目的で実装するか
・システム的に実現可能か
・現行システム的に実現すべきか、沿っているか
・モデルの変更が必要そうか、ソリューションさえ変えれば実現可能か
・どの程度の規模になりそうか（別途見積りは行うが一応把握しておきたい）
などを調査するかと思います。
その際の注意点や観点などを、私の経験で書き連ねます。
##観点と注意点一覧
| 観点 | 注意点 | 例 |
|---|---|---|
| 業務上の目的 | 大まかにでも把握しておきたい | システムによるので割愛 |
| 実現可能か | そもそもロジックが製造可能か | 現状の情報だと実現できない業務ロジックとかね |
| データモデル | テーブル追加なら画面とテーブルのデータ関係が1対1か1対多かなど | マスタ画面とマスタテーブル追加とか、めんどうなのは多対多のパターンかも。 |
| 規模感 | いきなり1Q分で無理そうな規模なら注意だよ | システム基盤追加する系なら今Qにて基盤のみ、次Qにてロジック入れる、とか増員するとか |
| 他シス影響 | 扱うデータが自システムのみで触るものならいいけど、他システムからの変更があり得るなら注意。他シスで実現可能かどうかも確認が必要。 | 自システムでのみ使う値だけがある画面に、他システムから参照される値があったりしたら影響確認しないといけないね |
| IF | システム連携の改修ならIF修正有無が大切。ないならなしでいいけど外結はするよね | IFの形は変わらないが連携項目が追加になる、など |
| 影響範囲と改修必要一覧 | 漏れなく調べること | - |
##データモデルについて
###1対1の場合
1つの入力に対して、1つのカラムが対応する
→1つにしか影響しないので安心感あるね
【例】
マスタテーブル「名前マスタ」があり
画面「名前マスタメンテナンス」があって
画面からの入力をテーブルに更新するだけ など
###1対多の場合
1つの入力に対して、多数のカラムに影響がある状態
→既存のデータに対する影響範囲が大きい
【例】
1つのマスタ項目を、複数のレコードが見ている
神を変えれば、紐づく人間たち全員の思考が一気に変わる.
神
L人間(1)
L人間(2)
L人間(3)
...
###多対1の場合
複数の入力に対して1つのレコードのみにしか影響しない状態
→入力元が多いため、影響範囲も広いし、テストすべきオペレーションの種類が増える
【例】
複数入力が1つのテーブルにつながっている
どの操作からも結局一つのテーブルや一つのレコードが更新される.
北の扉------
西の扉------
中央の扉---- 根源テーブル
東の扉------
南の扉------
###多対多の場合
複数の入力によって複数のレコードが変わる
→もっとも面倒なタイプ。状況に応じてしっかり考えましょう
【例】
双方向に参照先が多数ある状態
テーブル.
ユーザテーブル1→サービステーブル1, サービステーブル2, ...に紐づく
サービステーブル1→ユーザテーブル1, ユーザテーブル2, ...に紐づく