2025/04/10 のシステム開発日記とそれにかかる議論のログをGPTで清書したもの
https://scrapbox.io/files/67f7c63a6b0bc30e6293ca26.webp
✒️GPT-4.5.icon handled by Summer498.icon
後で読み返したいけど会話形式よりも文語体のほうが読みやすいのでつくったSummer498.icon
いどばたシステム開発プロトタイプ作成
blu3mo.iconは気合いを入れて、いどばたの新しい分析＋チャットシステムのプロトタイプ作成に取り組んでいる。
その作業は4つのステップで進められた。
Step 1: ラフなメモによる設計
まず人間がゴール、設計、データ構造、アルゴリズム、UIなどの要素をラフにメモ書きする。
この段階で重要なのは要点をしっかり押さえたメモを書くことである。
blu3mo.iconは一度作った経験があるから書けるが、本当に初めての場合には難しいだろうと感じている。
nishio.iconもまた、余計なことを書きすぎるとAIが混乱したりデザインが歪む可能性を指摘した。
Step 2: AIによる詳細な設計ドキュメント生成
次にGemini 2.5 Proを使ってラフメモから詳細なシステム設計ドキュメントを生成する。
これによりプロトタイプ作成の具体的な設計が明確になる。
Step 3: 設計からTODOリストの生成
設計ドキュメントを元に再びGemini 2.5 Proで実装手順を具体化したTODOリストを作成する。
ここでポイントになるのは、各ステップでこまめに動作確認を挟むことである。
Step 4: Roo Codeによる実装作業
最後に、作成したTODOリストの各項目をRoo Codeに実行させる。
ただし定期的な動作確認を通じてバグや仕様の問題点を発見し、自力で修正を加えていく。
sta.iconはこの方法を仕様から設定ファイル、そしてTODOを書き、最後にAIエージェントに任せる流れと捉え、「SCAD」（Specification, Configuration, Actionization, Delegation）と名付けることを提案した。
システム開発を巡る議論
blu3mo.iconはこのプロセスにAIエージェントDevinを投入することを検討したが、Step 3までで実装と動作確認を自動化できるか疑問を感じている。
nishio.iconはこれに対し、コンテキスト溢れで性能が落ちる可能性を指摘した。
また、現在のDevinの主用途は企業内の複数人開発による非公開ソースコードの改善であり、直列作業よりも並行作業に向いていると述べた。
blu3mo.iconはさらにIssueの消化にもDevinを使いたいと考えたが、nishio.iconはAIによるIssue処理は結局PRが溜まるだけだと指摘した。
実際にblu3mo.icon自身も、OpenHandsによるPRが既に溜まっている状況を認識していた。
blu3mo.iconはこの短期間での実装成功を踏まえ、システムをモジュラー化し、頻繁にスクラップ＆ビルドを繰り返す開発手法がより効果的だと感じ始めている。
sta.iconは抽象を具体化して新たな知見を得るプロセスこそが重要であり、単に抽象だけをこねるのではなく、具体を通じて知見を更新するべきだと指摘した。
blu3mo.iconも具体を現実に投入して実験的な知見を得ることが重要で、人間ができない実験こそが面白さになると考えている。
一方、sta.iconは完全に抽象のみで実現するのは難しく、具体的な調整には人間が介入する必要があることを強調した。
最後にblu3mo.iconは、その人固有の知見、体験、執着、価値観、環世界が面白さの本質であり、それらは具体的な行動を通してのみ生まれるとまとめた。
sta.iconもまた経験は思考を生み、思考は行動から生まれるという考えに共感した。
Summer498.icon
ところどころ嘘が混ざっている気がするね
構造が複雑なので正確に読み取るのは難しい（人間も文章を誤読するし）
個人的にはこの文体はすごく読みやすいが、どのジャンルで見られる文体なのだろう？