設計書って、なんで書くんだろうと思っていた
Office-Chronosの開発を通じて、たくさんのことを学びました。
まずは設計の話から。
最初のころの私は、アイデアが浮かぶたびにすぐ実装を依頼していました。
「これをやりたい」「あれもやりたい」と思いつくままに伝え続ける。
戦略会議の実装をしていたかと思えば、次の瞬間には「深夜の内省ではこんなことをさせたい」と言いだす。
まるでちぐはぐでした。
これはわたしのADHDの特性が結構出ていたと思います。
「やっぱり今のなし、こっちがいい」なんてこともやりました。
実装してもらったものを、すぐひっくり返す。

それでもしばらくは「まあいいか」と続けていました。
問題に気づいたのは、バグが増えてからです。
一つ直せばまた別のところが壊れる、という状態が続きました。
そのとき初めて、自分の指示の仕方が悪かったと気づきました。
答えられない質問があった
もう一つ、設計不足を痛感した場面がありました。
実装中にAIから質問されると、答えられないことがあったのです。
焦って適当な答えを返してしまったこともありました。
答えられなかった理由は、そういう質問があることを想定していなかったからです。
「わかってたけど決めていなかった」ではなく、何一つ考えていなかった。
自分が何のために何をやりたいのか。
そのやりたいことを実現するために、どの順番で何をしていくのか。
それがわかっていないと、ダメだと思いました。
今は「相談してから実装」に変えた
今は、アイデアが浮かんだらまず idea.md にいったん入れておきます。
実装するときは「企画要件書→仕様書→設計書→実装プラン」という流れで、少しずつ落とし込んでいきます。
状況によって端折るものの、「やりたいこと→やる手順」という流れはほとんどの場合持つようにしています。
1セッション1テーマという粒度でステップを組み、実装プランに沿って進める。

おかげでコードは壊れにくくなりました。
多少のエラーがあっても、なんとなく見当がつくようになっています。
実装プランを読んでいるおかげで、何をどうしているかの概念が頭に入っているからです。
アイデアが出た瞬間にそのまま実装するより、確実だし、結果的に早かったりもします。
この記事のまとめ
Office-Chronosの開発を通じて、設計について学んだことをまとめます。
- アイデアが浮かんでもすぐ実装しない。まず
idea.mdに入れておく - 実装前に「相談」の時間を設ける。「やっぱりなし」を減らせる
- 「やりたいこと→やる手順」の流れを先に持っておく
- 1セッション1テーマの粒度でステップを組む
- AIに質問されて答えられなかったら、設計が足りていないサイン