実装はできるのに設計ができないエンジニアへ。原因は3つに分かれ、直し方がそれぞれ違う

チケットを渡されれば実装はできる。レビューもおおむね通る。でも「この機能、設計から任せたい」と言われた瞬間に手が止まる。

実務経験3〜5年くらいで、この状態にいる人は少なくありません。Q&Aサイトにも「SE4年目で設計業務ができないのはまずいですか」という質問が普通に並んでいます。

先に結論を書くと、設計ができない原因は、知識不足ではないことのほうが多いです。そして原因によって直し方がまったく違います。

設計ができない原因は3つに分かれる

「設計ができない」とひとまとめに言いますが、実際には手が止まる場所が人によって違います。

この3つは、見た目は同じ「設計ができない」ですが、足りていないものが違います。

1. 選択肢が思い浮かばない：引き出しが足りない

これは本当に知識の問題です。「状態をどこに持つか」「処理をどの層に置くか」といった判断の型を、単純に見たことがない。

見たことがない型は、思い浮かべようがありません。

2. 選択肢はあるが選べない：判断の基準が無い

案は出るのに決められない人は、知識は足りています。足りないのは「何を優先して比べるか」という基準です。

設計はほぼ常にトレードオフです。変更に強くすると複雑になる。単純にすると後で困る。どちらが正しいかではなく、この状況で何を優先するかを決める作業なので、基準が無いと永遠に決まりません。

3. 選んだ理由を説明できない：言語化していない

実はこれがいちばん多いと感じています。案を出して、選んで、実装もできている。でもレビューで「なぜこうしたの？」と聞かれると答えに詰まる。

本人の中では判断しているのに、それを言葉にしていないので、他人から見ると「設計していない」ように見えます。そして自分でも、判断していたことに気づいていません。

自分がどれに当てはまるかを見分ける

見分け方は単純です。次に実装するタスクで、コードを書く前に「どう作るか」を紙に書いてみてください。

ここを見誤ると、たとえば3の人が設計の本を読み続けることになります。知識は十分あるので、本を読んでも手応えがありません。

原因ごとの練習法

引き出しを増やす：本より「良いコードの理由」を読む

設計の本は役に立ちますが、抽象的なぶん実務に結びつきにくいです。それより効くのは、良いとされているコードを読んで「なぜこう分けたのか」を考えることです。

社内のよく書かれたモジュールでも、有名なOSSでも構いません。「なぜこのファイルは分かれているのか」「なぜこの処理はここにあるのか」を1つずつ説明できるようになると、それがそのまま自分の引き出しになります。

判断基準を持つ：必ず2案出して、捨てた理由を書く

判断の練習は、1案で決めないことから始まります。どんな小さなタスクでも、必ず2案出して比べる。

比べるときの軸は、だいたい次のどれかです。

• 変更が入ったときに、どこまで影響するか
• 初めて読む人が、どれくらいで理解できるか
• テストが書きやすいか
• 今のチームの慣習と揃っているか

大事なのは、選ばなかった案と、選ばなかった理由を書き残すことです。選んだ理由より、捨てた理由のほうが判断基準を鍛えます。

言語化する：設計メモを1枚書く

判断しているのに説明できない人は、判断を書き残す習慣をつけるのがいちばん早いです。形式は何でも構いませんが、次の3つだけは入れます。

これを数回やると、レビューで「なぜ？」と聞かれても答えられるようになります。判断は元からしていたので、書き出すだけで設計ができる人になります。

設計を任されない職場なら、どうするか

「そもそも職場で設計を任せてもらえない」という人もいると思います。その場合でも練習はできます。

• 自分の担当タスクの中で小さく設計する。 関数の分け方、ファイルの置き場所も設計です
• 個人開発で、設計メモを残しながら作る。 成果物より、判断の記録のほうが転職で評価されます
• 外の人に見てもらう。 社内に設計まで踏み込んでレビューする人がいないなら、外に求めるしかありません

3つ目は、「自走できるエンジニア」とは何かでも触れた「判断の材料を自分で集める力」と同じ話です。設計は、自走の中でもいちばん差がつく部分です。

まとめ

「設計ができない」と感じている人の多くは、実は3番目です。判断はしているのに、書いていないだけ。その場合、身につけるべきは新しい知識ではなく、書き残す習慣です。