頭の中だけでは設計が進まない
「考えるということは手を動かすことである」という言葉が、ずっと印象に残っています。
最近、その意味を仕事の中でよく感じます。
設計や要件整理をしていると、頭の中にいろいろな情報が同時に入ってきます。
- やりたいこと
- 技術的な制約
- 既存システムとの整合性
- セキュリティ
- パフォーマンス
- スケジュール
- 誰が使うのか
これらを脳内だけで持ち続けるのは、なかなか厳しいです。
考えているつもりなのに、同じ論点をぐるぐる回って終わることがあります。
そういうとき、私にとって一番現実的なのは、まず書くことです。
書くと、論点が外に出る
頭の中で考えていると、論点が混ざります。
でも、書くと分かれます。
たとえば、通知機能を考えているとします。
やりたいこと:
- ユーザーに重要なお知らせを出したい
迷っていること:
- DBに保存するか
- メールだけで送るか
- 既読管理を作るか
気になること:
- 通知が増えたときのパフォーマンス
- 誰に通知するかの条件
- 管理画面から送れるようにするか
これだけでも、少し前に進みます。
頭の中では一つの「通知どうしよう」だったものが、書くことで複数の論点になります。
論点に分かれれば、次に考える順番を決められます。
書くことは、判断を残すことでもある
書くことの良さは、整理だけではありません。
判断の理由を残せます。
設計では、正解が一つではないことが多いです。
A案もあり。
B案もあり。
でも今回はA案にする。
このとき、なぜA案にしたのかを残しておくと、未来の自分やチームが助かります。
今回はDB保存にする。
理由:
- 既読管理が必要
- 後から一覧表示したい
- 最初は外部サービスを増やしたくない
懸念:
- 通知数が増えたときのクエリ
- 古い通知の削除方針
これがあるだけで、あとから見たときに「なぜこうなっているのか」が分かります。
記録は未来の自分への申し送りである と同じで、書いたものは未来の判断材料になります。
AIに相談する前にも、まず書く
AIを使うときも、まず書くところから始めたいです。
いきなりAIに「設計を考えて」と投げると、一般論が返ってきやすいです。
でも、自分の状況を書いてから渡すと、返ってくる内容が変わります。
前提:
- Railsアプリ
- 通知対象はログインユーザー
- 最初は画面内通知だけでよい
- 将来的にメール通知もありそう
相談:
- DB設計の案を出してほしい
- 既読管理を入れる場合の注意点も知りたい
ここまで書くと、AIも答えやすくなります。
AIに質問する前に、AIが理解しやすい文章へ直す にもつながりますが、AI時代ほど、人間側が前提を言語化する力が必要になります。
書くと、相談の質も変わる
人に相談するときも同じです。
「通知機能どうしたらいいですか？」と聞くより、
今考えている案:
- DBにnotificationsテーブルを作る
- user_id, title, body, read_at を持つ
迷っていること:
- 種別ごとにテーブルを分けるか
- read_at で既読管理してよいか
- 古い通知をどう消すか
と書いてから相談したほうが、相手も答えやすいです。
相談する側も、自分が何に迷っているのか分かります。
書くことは、自分のためだけでなく、相談相手への配慮でもあると思います。
書くときは、きれいに書かなくていい
最初からきれいなドキュメントにしようとすると、手が止まります。
最初は雑でよいです。
- 箇条書き
- メモ
- 疑問文
- 途中の仮説
- 間違っているかもしれない案
こういう状態で出してよいと思っています。
大事なのは、頭の外に出すことです。
きれいにするのは後でできます。
間違っていても記録する。未来の自分に判断材料を残す のように、途中の状態にも価値があります。
明日からできること
設計や要件整理で止まったら、まず次の型で書くと進みやすいです。
やりたいこと:
前提:
迷っていること:
選択肢:
今の仮説:
確認したいこと:
これだけで十分です。
全部埋める必要はありません。空欄があれば、それが次に考える場所です。
まとめ
考えることは、頭の中だけで完結しません。
書くことで論点が外に出ます。
書くことで判断が残ります。
書くことでAIにも人にも相談しやすくなります。
設計が進まないときほど、まず書く。
自分にとっては、それが一番現実的な進め方です。