Loading...

社内システム開発日記:その64

前書き

お疲れ様です!
小手投げです。

最近腕立てをプッシュアップバーでしています。
普通にやるよりも胸と肩に効いている感じがします。

今回は打ち合わせの様子です。

打ち合わせ

部:担々麺は結合テスト準備と実施、小手投げは結合テスト準備と修正とあるが、
  担々麺は修正、小手投げは実施をしなくていいのか
  粒度が揃っていない

部:リリース準備とリリースの期間が二人でずれている

部:フレームワーク調査と画面開発試行が0%なのは?
担:100%の間違い

部:アプリ設計が90%なのは?
担:DB設計が10%

部:このスケジュールはスケジュール通りに行くと思っているか
担:……
部:二人で肌感のすり合わせをした方がいい。
  お昼くらいにいけるかいけないか程度を確認

部:詳細を見ているとどんどん後ろ倒れになる気がする
  振り返れるタイミングで振り返りとスケジュールの更新をした方がいい
  見た感じ中タスクがないのでカテゴライズなりブロックなりを作ってやったら
  振り返り自体の工数は増えるけど、結果的に全体の工数は抑えられると思う
  二人とも一つ一つのタスクを期間内にこなす能力はあると思うが、
  タスクが複合、輻輳したときにオーバーヘッドに対するスケジューリング能力がない
  だから進捗管理のトレーニング

(プロジェクト情報の入力形式について)
部:現状の、折りたたみのチェックボックスから恩恵を感じられない
  手入力にしても労力は変わらない
  システムから強制させたいという考えだったのだろう

部:一つ構想があって、タイプしているときにjavascriptで入力補完が欲しい
  辞書を作るかSubstrで頭10文字くらい表示するか
  次フェーズ以降

部:DBはいったんこれで行こう
  AsIsは必要
  移行に関してはテストファーストの方が楽、バッチ的なデータ移行だから
  具体的には、あるカラムのデータを分割して二つのカラムに入れる場合を例に考える
  分割し移行後に二つのカラムがそれぞれnullでないというテストを書く
  全レコードについて移行、テストをし、エラーが出た箇所に対応してテストを修正する
  エラーが出なくなったら設計に起こす
  要件定義の範囲
  変わっていないことの確認も必要

小:会社マスタを各社DBに移したが、会社一覧を見るときは各社DBそれぞれからひっぱればいいのか
部:それでもいいし、会社一覧テーブルを作ってもいい
小:一覧とは
部:一覧を表示するためだけのテーブル。詳細がいらないなら

後書き

長かったDB定義がようやく終わってほっとしました。

データ移行のテストについてはまだ詳細が思い浮かびません。

ではまた次回。

情報戦略テクノロジー