はじめに
こんにちは、株式会社Techouseでエンジニアをしている@kuragane1122です。
Kaigi on Rails 2025にて、nay3 (Yasuko Ohba) さんの「Railsによる人工的「設計」入門」を聴講しました。
本記事では、このセッションで得た学びを、私自身の経験と照らし合わせながら紹介します。
特に「いきなり実装」の失敗は、設計初学者が陥りがちなミスです。私自身も過去に、「影響範囲の調査」から始めた結果、設計が抜け落ちた状態に陥った経験があります。このセッションを聞いて、当時の自分が何を間違えていたのか、そしてどうすればよかったのかが明確になりました。
セッションの概要
nay3さんのセッションは、熟練者が初学者にどう設計を教えるか、という道筋を体系化する趣旨で進みました。
その中で、特に「設計ができない」状態のアンチパターンとして「手順による実装」というキーワードが紹介されました。
「手順による実装」とは
これは、設計初学者が陥りがちな状況を完璧に言語化するものでした。 セッションで語られた「手順による実装」の特徴は以下の通りです。
- 実装前に全体を考えるという意味での「設計」はしていない。手順ごとに狭い範囲で設計らしきことはする。
- 周囲に「手順」を説明して着手するので、“設計をしたから説明しているんだろう”と思われて、設計をしていないことに気づかれづらい。
- 実質「いきなり実装」なので、あとから未考慮の問題がどんどん出てきて、ハマり放題になる。
この説明を聞いて、私は思わずドキッとしました。「あとから未考慮の問題がどんどん出てくる」それはまさに、過去の自分がハマった状況そのものだったからです。 そうだと分かれば何をすればよかったのかは明白です。「設計」をすればよかったのです。
......ちょっと待ってください。私は確かに、実装前に「設計」を行いました。 では、あの時私がした「設計」とは、一体何だったのでしょうか。
私がした「設計」の正体
私は確かに新しい機能を実装するにあたり、要求を調査し、機能の仕様を策定しました。時には先輩エンジニアに相談をしながら「設計」を行い、ドキュメントにまとめました。 その結果、自分の作るべき機能の全景が見えてきました。
ここで自分は「設計が完了した」と思い実装に移ったのですが、それが大きな間違いだったのです。
nay3さんは発表の中で、「手順による実装」の問題点として次のように述べられていました。
「実装前に全体を考えるという意味での『設計』はしていない。手順ごとに狭い範囲で設計らしきことはする」 「周囲に『手順』を説明して着手するので、設計をしていないことに気づかれづらい」
どうやら自分が「設計」だと思っていたことは「設計らしきこと」に過ぎなかったようです。 では、実際に何をすれば「設計」をしたことになるのでしょうか。
その答えとして、セッションでは「設計」を以下のように定義していました。
- コードのレベル（詳細な行）で考えることではない
- 全体としてどういう構造、どういう技術的要素で作るのが良いかを考え、作業の段取りを考えても良い状態にすること
この定義に自分の仕事を照らし合わせたとき、全ての辻褄が合いました。
ズバリ、私の設計は「ゴールの清書」に過ぎなかったのです。
あくまで私が作ったドキュメントは「自分のゴールのイメージを共有するためのもの（What）」でしかなく、「いかにしてそのゴールを実現するか（How）」が完全に漏れていたのです。
確かに私は「設計」をやろうとしました。しかし、コードに落とし込むための「設計」を最後までしきれていませんでした。 結果、私は「理想のゴールはあるけど、どのように実現するのかはやってみないと分からない」状態に陥り、未考慮の問題にハマり倒してしまったのです。
そして、この「手順による実装」の対比として、「完成したシステムから考える」というアプローチが解決策として提示されました。
「完成したシステムから考える」とは
では、nay3さんが提示した「完成したシステムから考える」とは、具体的に何をすることなのでしょうか。
セッションでは、これを「手順の積み上げ（順算）」に対する「逆算」のアプローチとして説明していました。
「気になること」を潰していくプロセス
「完成したシステムから考える」とは、コードレベルでの完成形（プロトタイプ）を脳内でイメージし、そこから逆算して不確定な要素（変数）を確定させていく作業です。
私が陥っていた「理想のゴールはあるけど、どのように実現するのかはやってみないと分からない」という状態は、裏を返せば「気になること（未決定事項）が残ったまま」の状態でした。 対して、このアプローチでは以下のようなループを回します。
プロトタイプのイメージ: 「この機能が完成した時、コードはどうなっているか」を想像する。
気になることの洗い出し: そのイメージの中で、以下のような懸念点（気になること）をすべて書き出す。
- 「ここのデータ構造はどうなるか」
- 「この権限判定はどこでやるか」
- 「外部APIがエラーを返したらどう振る舞うか」
- 「ここでN+1問題は起きないか」
選択肢と仮決め: 懸念点に対して「A案、B案、C案」と選択肢を出す。調査や比較を経て「一旦これで行く」と仮決め（仮置き）する。
設計完了の定義とは
このサイクルを繰り返し、「気になることがなくなった状態」こそが、設計が完了した状態であると定義されていました。
「手順による実装」で失敗する最大の原因は、この「気になること（＝考慮すべき変数）」が残ったまま、見切り発車でコードを書き始めてしまうことです。
実装中に出てくる迷いや手戻りは、すべてこの「仮決め」が不足していることから生じます。
つまり、私がやるべきだった「設計」とは何だったのでしょうか。 それは理想のゴールとそれを共有するドキュメントを作ることではありません。実装前にプロトタイプを脳内で回すこと、そして全ての「気になること」へ根拠を持って「仮決め」を済ませておくことだったのです。
そうして初めて、迷いなくゴールへ向かうための「地図」が手に入ります。
おわりに
今回のセッションを通じて、私は「設計」という行為の解像度を大きく上げることができました。
設計とは、きれいなドキュメントを作ることでも、作業手順を書き出すことでもありません。脳内のプロトタイプから「気になること」を洗い出し、それら全てに「仮決め」という名の答えを用意してあげることです。
「実装してみないと分からない」という言葉は、思考放棄のサインです。
もし今後、私が「とりあえずコードを書いて確かめよう」と思った時は、一度立ち止まります。コードエディタを開く代わりに、「何が気になっているのか」「どんな選択肢があるのか」を言語化することから始めます。自分だけで「仮決め」ができない場合は、そのタイミングでチームの有識者に相談し、レビューを仰ぎます。
このプロセスを経ることで、実装は「未知の冒険」から、確信を持った「答え合わせ」へと変わるはずです。
素晴らしい気づきを与えてくださった nay3 さんに、心より感謝申し上げます。
Techouseでは、社会課題の解決に共に取り組むエンジニアを募集しております。 ご応募お待ちしております。
