【タスク管理】生成AIを使いつつつDB設計をば【#4】

生成AIとの付合いと開発順序の見直し

このタスク管理ツールを作るにあたって、なるべくは
生成AIを使わないでやっていこうと思ったが、
あるものは使って楽したくなるのが人の性ってやつで、
Geminiに協力してもらって、手順の見直しを図ったら
こうなりました。

フェーズ0：データ構造と基盤設計
    まずはCSVや画面に依存しない「統一データモデル」を定義します。

    ステップ1: DBスキーマ設計とデータ型の統一
        可変ツリー構造（parent_task_id）、依存関係テーブル、担当者履歴テーブルの定義。
        日時精度（日時・日単位）をブレさせないため、DB内の時刻データ型をISO8601文字列またはUnixタイムスタンプに一元化。

    ステップ2: Pythonでのデータモデル（Class）と自動計算ロジックの実装
        タスクオブジェクトの定義と、重要度合成スコア（日ごと×当日）の計算ロジック実装。
        依存関係の循環参照（デッドロック）を防止するDAG（有向非巡回グラフ）チェック関数の作成。

フェーズ1：データ層の作成（CUI ＆ DB / CSV）
画面を作る前に、データの保存・読込処理を確定させます。

    ステップ3: SQLCipher（DB）の接続・CRUD処理の実装
        PythonからSQLCipherへ接続し、タスクの作成・読み出し・更新・削除（CRUD）を行うデータアクセス層（Repository）を作成。

    ステップ4: CSVインポート/エクスポート機能の実装（CUI）
        「CSV ⇔ DB」の変換ロジックをCUIで実装（※CSVに直接依存させるのではなく、DBのデータをCSV形式で出力・取り込む機能として位置付け）。

フェーズ2：GUI基本機能（マトリクス表示 ＆ データ同期基盤）
操作の拠点となるマトリクス（テーブル/ツリー）画面を作り、データ更新の仕組みを確立します。

    ステップ5: PySide6によるマトリクス（ツリー）表示
        QAbstractItemModel または QTreeWidget を使用し、DBのデータを可変階層構造でGUIに描画。

    ステップ6: 単方向データフロー（更新・同期）の実装
        GUI上でのセル編集・行追加・削除イベントを発生させ、「GUI操作 → DB更新 → GUI再描画」を一元的に処理するシグナル設計（無限ループ防止）。

    ステップ7: 起動時自動判定ロジックの実装
        アプリ起動時に「期日」と「現在日時」を比較し、ステータス（順調・遅延）や日ごと重要度（今週中→今日中など）を自動一括更新する処理を追加。

フェーズ3：マルチビュー展開（看板形式）
データ構造が整った状態で、マトリクス以外の見せ方を追加します。

    ステップ8: 看板（カンバン）ビューの表示
        マトリクスのデータを元に「未着手 / 作業中 / 完了 / 中断」のレーンを作成。
        フィルタースイッチ（今日 / 今週 / 今月）を設置し、表示対象カードを切り替え。

    ステップ9: 看板上でのステータス変更・並び替え
        ドラッグ＆ドロップまたはステータス変更操作を、ステップ6で作った共通DB更新ロジックへ流す。

フェーズ4：ガントチャート機能の実装（最難関）
最難関となるガント描画を、土台が完成したこのタイミングで組み込みます。

    ステップ10: マトリクス連動型のガントチャート描画（閲覧メイン）
        マトリクスのタスク行と同期したタイムライン描画（日・週・月表示の切り替え）。

    ステップ11: ガントチャート上での依存関係（前後関係）の視覚化
        先行タスクと後続タスクを繋ぐ矢印線の描画。

    ステップ12: ガントチャートからの双方向編集（操作 → マトリクス・看板反映）
        ガントバーの期間変更やドラッグ操作イベントを受け取り、DBを更新して全画面（マトリクス・看板）へ変更を波及させる。

フェーズ5：セキュリティ・最終調整
実用に向けた最終仕上げを行います。

    ステップ13: DBの暗号化（SQLCipher鍵管理）の適用
        アプリ起動時にパスワード入力を求め、DBを完全暗号化状態で開くセキュリティ処理を適用。

    ステップ14: 担当者遷移履歴・例外ハンドリングのGUI化
        担当変更ログの表示ダイアログや、CSVインポート時のエラー判定などの仕上げ。

ほんと良くできてますよ、正直DB設計は後回しでいいかと思っていたけども、
先にやったほうが骨組みが固まるという意味でいいんだろうなーと

今回はそんなgeminiと決めた手順の第0会のDB設計をやってみました。

##DB設計について
今回使うのはSQLiteになるので、実務で使っている
SQLSERVERと違うところもあり、ちょっと戸惑ったけども、
geminiの助けもあり、無事できたものがこちら

データベース詳細設計書 (SQLCipher)

1. 概要・共通仕様

• 物理DB: SQLCipher（SQLite3互換暗号化データベース）
• 文字コード: UTF-8
• 日時精度・書式: YYYY-MM-DD hh:mm:ss（ISO8601準拠テキスト形式 / 19桁）
• キー採番方針:
  • 主キー（PK）は基本的に INTEGER PRIMARY KEY AUTOINCREMENT（自動採番）を使用。
  • 識別コード（PJ_CD, TASK_CD, WORKER_ID）は表示・CSVインポート/エクスポート用のユニークキーとして定義（CHECK(length(...) = 10) により右詰めスペース埋め等の10桁固定長を強制）。

---

2. ER図 (Entity Relationship Diagram)

---

3. テーブル一覧

物理テーブル名	論理テーブル名	主な役割
PROJECTS	プロジェクトテーブル	タスクをグループ化して管理する上位プロジェクト情報
TASKS	タスクテーブル	タスクの基本情報（名称・ステータス・階層構造等）
PRIORITY	重要度テーブル	タスクの2軸重要度（日ごと/当日）と計算された合成スコア
SCHEDULES	予定テーブル	タスクの予定期間（開始〜終了）および履歴フラグ
WORKLOGS	実績テーブル	タスクに対する実際の作業時間ログ（複数回の中断・再開に対応）
INDEPENDENCY	依存関係テーブル	先行タスクと後続タスクの関連性（多対多対応）
ASSIGNMENT	担当テーブル	予定または実績に対する作業担当者の割り当て
ASSIGNMENT_LOG	担当履歴テーブル	担当者変更の追跡ログ（単体完結型）
M_WORKER	担当マスタテーブル	作業担当者のマスター情報
M_PRIORITY	重要度マスタテーブル	重要度（日ごと/当日）の名称・順序・重み付けマスター

---

4. テーブル詳細定義書

1. プロジェクトテーブル (PROJECTS)

物理カラム名	論理カラム名	データ型	PK	FK	UK	NotNull	初期値・制約事項
PJ_NO	プロジェクト番号	INT	○	-	-	○	AutoIncrement
PJ_CD	プロジェクトコード	TXT	-	-	○	○	右詰めスペース（10桁固定）
PJ_NM	プロジェクト名	TXT	-	-	-	○	-
UPD_DATETIME	更新日時	TXT	-	-	-	○	YYYY-MM-DD hh:mm:ss

2. タスクテーブル (TASKS)

物理カラム名	論理カラム名	データ型	PK	FK	UK	NotNull	初期値・制約事項
PJ_NO	プロジェクト番号	INT	-	○	-	○	FK: PROJECTS.PJ_NO
TASK_NO	タスク番号	INT	○	-	-	○	AutoIncrement
TASK_CD	タスクコード	TXT	-	-	○	○	右詰めスペース（10桁固定）
NAME	タスク名	TXT	-	-	-	○	-
TASK_MEMO	タスクメモ	TXT(MAX)	-	-	-	-	-
STATUS	ステータス	INT	-	-	-	○	初期値 1 (1:未着, 2:作業中, 3:完了, 4:中断)
PARENT_TASK_NO	親タスク番号	INT	-	○	-	-	FK: TASKS.TASK_NO（可変ツリー構造）
UPD_DATETIME	更新日時	TXT	-	-	-	○	YYYY-MM-DD hh:mm:ss

3. 重要度テーブル (PRIORITY)

物理カラム名	論理カラム名	データ型	PK	FK	UK	NotNull	初期値・制約事項
TASK_NO	タスク番号	INT	○	○	-	○	FK: TASKS.TASK_NO (PK兼FK)
DAY_PRIORITY_NO	日ごと重要度番号	INT	-	○	-	○	FK: M_PRIORITY.PRIORITY_NO (CATEGORY=1)
INTRADAY_PRIORITY_NO	当日内重要度番号	INT	-	○	-	-	FK: M_PRIORITY.PRIORITY_NO (CATEGORY=2)
PRIORITY_SCORE	合成優先度スコア	INT	-	-	-	○	自動計算値（重みの合算）
UPD_DATETIME	更新日時	TXT	-	-	-	○	YYYY-MM-DD hh:mm:ss

4. 予定テーブル (SCHEDULES)

物理カラム名	論理カラム名	データ型	PK	FK	UK	NotNull	初期値・制約事項
TASK_NO	タスク番号	INT	-	○	-	○	FK: TASKS.TASK_NO
SCHEDULE_NO	予定番号	INT	○	-	-	○	AutoIncrement
SCHEDULE_BGN	予定開始日時	TXT	-	-	-	-	YYYY-MM-DD hh:mm:ss
SCHEDULE_END	予定終了日時（期限）	TXT	-	-	-	○	YYYY-MM-DD hh:mm:ss
IS_AVAILABLE	最新フラグ	BOOLEAN	-	-	-	○	1:最新（有効）, 0:過去履歴
SCHEDULE_MEMO	予定メモ	TXT(MAX)	-	-	-	-	-
UPD_DATETIME	更新日時	TXT	-	-	-	○	YYYY-MM-DD hh:mm:ss

5. 実績テーブル (WORKLOGS)

物理カラム名	論理カラム名	データ型	PK	FK	UK	NotNull	初期値・制約事項
TASK_NO	タスク番号	INT	-	○	-	○	FK: TASKS.TASK_NO
WORKLOG_NO	実績番号	INT	○	-	-	○	AutoIncrement
BEGIN_DATE	作業開始日時	TXT	-	-	-	○	YYYY-MM-DD hh:mm:ss
END_DATE	作業終了日時	TXT	-	-	-	○	YYYY-MM-DD hh:mm:ss
WORKLOG_MEMO	作業メモ	TEXT(MAX)	-	-	-	-	-
UPD_DATETIME	更新日時	TXT	-	-	-	○	YYYY-MM-DD hh:mm:ss

6. 依存関係テーブル (INDEPENDENCY)

物理カラム名	論理カラム名	データ型	PK	FK	UK	NotNull	初期値・制約事項
INDEPENDENCY_NO	依存関係番号	INT	○	-	-	○	AutoIncrement
PRE_TASK_NO	先行タスク番号	INT	-	○	※	○	FK: TASKS.TASK_NO
SUB_TASK_NO	後続タスク番号	INT	-	○	※	○	FK: TASKS.TASK_NO
INDEPENDENCY_TYPE	依存関係種別	TXT	-	-	-	○	初期値 'FS' (FS, SS, FF, SF)
UPD_DATETIME	更新日時	TXT	-	-	-	○	YYYY-MM-DD hh:mm:ss

※補足: (PRE_TASK_NO, SUB_TASK_NO) の組み合わせに対して複合ユニークキー（UNIQUE）制約を設定。

7. 担当テーブル (ASSIGNMENT)

物理カラム名	論理カラム名	データ型	PK	FK	UK	NotNull	初期値・制約事項
ASSIGN_NO	担当割り当て番号	INT	○	-	-	○	AutoIncrement
SCHEDULE_NO	予定番号	INT	-	○	-	-	FK: SCHEDULES.SCHEDULE_NO（条件付き必須）
WORKLOG_NO	実績番号	INT	-	○	-	-	FK: WORKLOGS.WORKLOG_NO（条件付き必須）
WORKER_NO	担当作業者番号	INT	-	○	-	○	FK: M_WORKER.WORKER_NO
ASSIGN_MEMO	割り当てメモ	TXT(MAX)	-	-	-	-	-
UPD_DATETIME	更新日時	TXT	-	-	-	○	YYYY-MM-DD hh:mm:ss

※補足 (CHECK制約): SCHEDULE_NO と WORKLOG_NO はいずれか一方のみが入力（もう一方はNULL）となるよう制御。

8. 担当履歴テーブル (ASSIGNMENT_LOG)

物理カラム名	論理カラム名	データ型	PK	FK	UK	NotNull	初期値・制約事項
ASSIGN_LOG_NO	担当履歴連番	INT	○	-	-	○	AutoIncrement
ASSIGN_NO	担当割り当て番号	INT	-	○	-	○	FK: ASSIGNMENT.ASSIGN_NO
WORKER_NO_OLD	変更前作業者番号	INT	-	○	-	○	FK: M_WORKER.WORKER_NO
WORKER_NO_NEW	変更後作業者番号	INT	-	○	-	○	FK: M_WORKER.WORKER_NO
ASSIGN_MEMO_OLD	変更前メモ	TXT(MAX)	-	-	-	-	-
UPD_DATETIME	更新日時	TXT	-	-	-	○	YYYY-MM-DD hh:mm:ss

9. 担当マスタテーブル (M_WORKER)

物理カラム名	論理カラム名	データ型	PK	FK	UK	NotNull	初期値・制約事項
WORKER_NO	作業者番号	INT	○	-	-	○	AutoIncrement
WORKER_ID	作業者ID（コード）	TXT	-	-	○	○	右詰めスペース（10桁固定）
WORKER_NM	作業者氏名	TXT	-	-	-	○	-
UPD_DATETIME	更新日時	TXT	-	-	-	○	YYYY-MM-DD hh:mm:ss

10. 重要度マスタテーブル (M_PRIORITY)

物理カラム名	論理カラム名	データ型	PK	FK	UK	NotNull	初期値・制約事項
PRIORITY_NO	重要度定義番号	INT	○	-	-	○	AutoIncrement
CATEGORY	重要度カテゴリ	INT	-	-	-	○	1:Daily (日ごと), 2:Intraday (当日内)
PRIORITY	重要度名称	TEXT	-	-	-	○	例: '至急', '今日中', '最優先' 等
RANK	表示順序	INT	-	-	-	○	カテゴリ内でのソート順
WEIGHT	重み付け数値	INT	-	-	-	○	合成スコア計算用スコア
UPD_DATETIME	更新日時	TXT	-	-	-	○	YYYY-MM-DD hh:mm:ss

なんかhh:mm:ssの形式がいかれて国旗になる
とか言う謎事象があったけど、適当なhtmlタグを
:の前に入れてやるとエスケープできた、うっとしすぎるわこれ

何にせよDB設計はできたのでまた次回は、次のステップに進んで、
開発の方を進めていこうと思います。

というわけで今回はこれで終わり
ではまたー (｀･ω･´)ﾉｼ