経緯
この記事は以下の記事の続き。第2回です。
https://qiita.com/Programmer-cbl/items/480767f026ae8316b72d
以下は前回ChatGPTで作成した全体工程です。今回は「設計」に取り掛かります。
| 工程 | 詳細工程 | 担当者 | 説明 | インプット | アウトプット |
|---|---|---|---|---|---|
| 要件定義 | ユーザーインタビュー、要件整理 | システムエンジニア | ユーザーが求める機能や要件を明確化する | ユーザーの要件や提案書 | 要件定義書、プロジェクト計画書 |
| 設計 | アーキテクチャ設計、画面設計、データベース設計 | システムエンジニア | システムのアーキテクチャや画面、データベースを設計する | 要件定義書、技術仕様書 | 詳細設計書、画面設計書、データベース設計書 |
| 実装 | プログラム作成、単体テスト | プログラマー | 設計書に基づいてプログラムを作成し、単体テストを行う | 詳細設計書、プログラム仕様書 | プログラム、テスト仕様書 |
| 結合テスト | モジュールの結合テスト、システムテスト | テストエンジニア | 実装されたモジュールの結合テストを行い、システムテストを行う | プログラム、テスト仕様書 | 結合テストレポート、システムテストレポート |
| ユーザーテスト | ユーザーによるテスト | ユーザー | 実際のユーザーによるテストを行い、不具合を洗い出す | 結合テストレポート、システムテストレポート | 不具合報告書、テスト結果報告書 |
| 保守・運用 | システムの保守・運用 | システムエンジニア | システムの保守や運用を行う | システム仕様書、ユーザーマニュアル | システム保守報告書、運用マニュアル |
詳細化
前回の要件定義工程と同様に、設計工程を詳細化します。
前回同様になんか増えたましたが、まぁきちんと詳細化できているということで良しとします。
アーキテクチャ設計
というわけでアーキテクチャ設計からやってみます。
とりあえず前回作成した「要件定義書」「全体工程表」と先ほど作成した「設計工程」の詳細化版を全て読み込ませます。
～～中略～～
そしてようやく設計書作成を指示!!
↑うーん。。この設計書要るか？なんか、わざわざ作る必要なかった気がする。
↓インフラ設計書も、、まぁスペックとかは本来必要だけど、今回はそこまでは検証しなくていいかなぁ。
というか微妙にインフラ構成図間違ってるし。。nginxとPostgreSQL直通はできんだろ。。uWSGI通せよ。。
というわけで、この二本の設計書は書いてはもらったものの、、あんまり意味ないので破棄します。
画面設計
なんかそれっぽいものが出てきた!! 合ってんのか知らんけど。
～～中略～～
要件定義書に書いてあった画面一覧は以下の7画面。
- ログイン画面
- ホーム画面（収支一覧、グラフ表示）
- 収支入力画面
- カテゴリ管理画面
- 予算設定画面
- 銀行口座連携画面
- アカウント設定画面
これ対して、画面設計書は明らかに過剰に生成されていました。
垂れ流しにしたので全体像がつかみにくくなったので、画面一覧を作成してもらいます。
すっきり全体像が分かりました。アカウント設定画面までは良かったんですが、収支一覧画面以降は勝手に増えたものですね。
ホーム画面の説明が「収支一覧やグラフ表示などの機能へのリンクを提供する」とありますので、むしろきちんと詳細化できている、と言えそうです。
この要件でいいのかどうか知りませんが、一旦これで良しとします。
また、画面プロトタイプは省略されてしまいました。まぁ仕方ないですね。
データベース設計
データベース設計を指示しましたが、これはDB名、テーブル一覧とテーブル定義書は分けて出力した方がよかったかもですね。
相変わらず合ってるかどうかは知りませんがそれっぽいものが出てきます。
なんとなく、要件に挙がっていた「銀行口座連携」と「家族単位での情報管理」をどうやるかが怪しいので指摘します。
なんと！ 複数のユーザーが共有できるカテゴリや予算が実現可能？ちょっと、、意味は分かるけど、
それでどうやって家族管理するのかイメージできませんが、まぁいいでしょう。
できるといってるなら信じましょう（本来こういう対応は絶対ダメですね）。
銀行口座連携の方はミスを認めているようなので、抜け漏れは普通にあるようですね。
前回のレビュースレッドのように、抜け漏れチェック用の別スレッドを用意するとこの辺りは防げるのかもしれません。
長くなってきたので今回はここで切ります。
まとめ
今回は概要→詳細の作業の繰り返しでした。
詳細化すると概要の時に書かれていなかった内容が出てくる、という当たり前のことではありますが、
ウォーターフォールプロセスでのシステム設計工程そのもの、という感じで可能性を感じさせるものがありました。
次回はAPI設計から、の予定です。
おまけ
- 文書の読み込ませ方
ChatGPTは長めの文書を読み込ませると、要約するかそのままオウム返ししてくることが多いです。
これは今回のように前工程で作ったドキュメントを大量に読み込ませた時には、出力が終わるまで結構待たされることになって時間の無駄です。
なので、指示の最後に「OKかNGで」と書いて返事のパターンを限定することで回答にかかる時間を節約しています。
こういう感じで↓
ChatGPTは「会話としてありそうなもの」を再現するらしいのですが、このやり方でもちゃんと文書の文脈を踏まえて次の回答をしてくれます。
リンク
第3回はこちら