設計書って、なんで書くんだろうと思っていた

Office-Chronosの開発を通じて、たくさんのことを学びました。

まずは設計の話から。

最初のころの私は、アイデアが浮かぶたびにすぐ実装を依頼していました。

「これをやりたい」「あれもやりたい」と思いつくままに伝え続ける。

戦略会議の実装をしていたかと思えば、次の瞬間には「深夜の内省ではこんなことをさせたい」と言いだす。

まるでちぐはぐでした。

これはわたしのADHDの特性が結構出ていたと思います。

「やっぱり今のなし、こっちがいい」なんてこともやりました。

実装してもらったものを、すぐひっくり返す。

思いつきが次々あふれて、頭の中がちぐはぐになっている様子のイラスト
当時の頭の中。思いつきをそのまま投げ続けていました

それでもしばらくは「まあいいか」と続けていました。

問題に気づいたのは、バグが増えてからです。

一つ直せばまた別のところが壊れる、という状態が続きました。

そのとき初めて、自分の指示の仕方が悪かったと気づきました。

答えられない質問があった

もう一つ、設計不足を痛感した場面がありました。

実装中にAIから質問されると、答えられないことがあったのです。

焦って適当な答えを返してしまったこともありました。

答えられなかった理由は、そういう質問があることを想定していなかったからです。

「わかってたけど決めていなかった」ではなく、何一つ考えていなかった。

自分が何のために何をやりたいのか。

そのやりたいことを実現するために、どの順番で何をしていくのか。

それがわかっていないと、ダメだと思いました。

今は「相談してから実装」に変えた

今は、アイデアが浮かんだらまず idea.md にいったん入れておきます。

実装するときは「企画要件書→仕様書→設計書→実装プラン」という流れで、少しずつ落とし込んでいきます。

状況によって端折るものの、「やりたいこと→やる手順」という流れはほとんどの場合持つようにしています。

1セッション1テーマという粒度でステップを組み、実装プランに沿って進める。

アイデアをidea.mdに入れ、企画要件書→仕様書→設計書→実装プランの順に落とし込む流れの図
今の流れ。idea.md からプランまで、順番に落とし込んでいきます

おかげでコードは壊れにくくなりました。

多少のエラーがあっても、なんとなく見当がつくようになっています。

実装プランを読んでいるおかげで、何をどうしているかの概念が頭に入っているからです。

アイデアが出た瞬間にそのまま実装するより、確実だし、結果的に早かったりもします。

この記事のまとめ

Office-Chronosの開発を通じて、設計について学んだことをまとめます。