設計って何をする仕事？新人エンジニアが初めて設計を担当して大変だったこと
はじめに
こんにちは、たけとりと申します。
私は去年2025年にWebエンジニアに転職した新人エンジニアです。
これまでは主に開発を担当してきた私ですが、エンジニアとして働き始めて約1年。
いよいよ開発だけではなく、要件定義や設計に少しずつ関わるようになりました。
ついに先日、初めて「新規機能の設計」を任されるという経験をしました。
何も知らないまま、初めてやってみた感想としては…
設計って、本当に考えることが多い…！大変でした。
結論から言うと、設計は「コードを書く前に、起こりうる未来を全部考える仕事」でした。
この記事では、新人エンジニアである私が、自身の体験談をもとに以下3点についてまとめています。
これからエンジニアを目指す方や、新人エンジニアの方が「設計ってどんな仕事？」とイメージする助けになれば嬉しいです。
設計って何をするの？私が担当した設計の内容
設計では、主に次のようなことを考えます。
- この機能は、どんな流れで使われるのか？
- どんなデータを、どこで、どう扱うのか？
- 例外的な操作やエラーが起きたら、どう振る舞うのか？
つまり、コードを書く前に「仕様と動作の全体像」を言語化・図式化する仕事です。
今回私が担当したのは、既存システムに対する新規機能の設計でした。
実際の作業の流れは、次のようなものでした。
- 必要な機能・要件を整理する
（この機能は何のために必要なのか？どんな使われ方をするのか？） - 処理の流れをフローチャートで可視化する
（どの条件で、どの処理に分岐するのかを図で整理） - フローチャートをもとに、設計書として文章・表に落とし込む
（実装する人が迷わないように、具体的に書く）
この段階では、まだコードは1行も書きません。
それでも、「ちゃんと動くかどうか」を徹底的に考える必要がありました。
設計は、実装をスムーズに進めるための「地図」を作る仕事なのだと、今回の経験を通して実感しました。
大変だったこと①：要件が曖昧だと、設計で必ず詰まる
設計を進めていると、こんな場面に何度も遭遇しました。
「あれ？この場合ってどうするんだっけ？」
要件がはっきりしていないと、以下の状態に陥ってしまいます。
私は後から気づいたのですが、要件定義フェーズの会議で、先輩エンジニアはすでに以下の点をきちんと詰めていました。
- この使い方はするのか？
- このフラグがONなら、この動作で問題ないか？
会議中は理解しきれていなかったのですが、設計を担当して初めて、
「ああ、ここを決めておかないと設計できないんだ……」
と実感しました。
設計は、要件定義の精度に大きく依存する仕事だと痛感した瞬間です。
要件定義で大変だった体験は、以下の記事でもまとめていますのでご覧ください！
大変だったこと②：フローチャートは「想定力」がすべて
設計で一番苦労したのが、フローチャートの作成です。
最初の私は、「ユーザーはこう使うはず！」という理想的な1パターンしか想定できていませんでした。
しかし、実際の設計では、
- このフラグが ON の場合は？
- 途中でデータを削除したら？
- 想定外の操作をされたら？
といったあらゆる分岐を考える必要があります。
レビューで先輩エンジニアから、「このケースはどうなる？」「ここで例外が起きたら？」と指摘されて初めて、「確かに……そのケース考えてなかった……」と気づくことが何度もありました。
設計では「正しい使い方」より「間違った使い方」を想像する力が求められるのだと学びました。
なお最近は、フローチャートを作ったあとにAIに「想定漏れがないか」を確認してもらうのも有効だと感じています。
大変だったこと③：設計書は「誤解されない」ことが最優先
設計書を書いていて意識するようになったのが、
「自分が分かる」ではなく「他人が誤解しない」
という視点です。
たとえば、以下のような表現は、後から読む人にとっては非常に曖昧です。
- 「このテーブル」
- 「このフラグ」
- 「ここで更新される」
設計書では、テーブル名・カラム名・値の意味などを具体的に書くことが重要だと学びました。
コードと違い、設計書は曖昧でも動いてしまいます。
だからこそ、誤解を生むという怖さがあります。
設計前に確認したいチェックリスト
最後に、今回の設計経験を通して「これを最初から意識しておけばよかった…！」と感じたポイントをチェックリストにまとめます。
設計に入る前・設計書を書き終えた後に、ぜひ一度見直してみてくださいね。
要件定義・仕様のチェック
- ✅ 要件が曖昧なまま、設計を進めていないか？
- ✅ 「この場合どうする？」と後から悩みそうな点はないか？
- ✅ 顧客・関係者と事前に決めておくべき仕様が抜けていないか？
- ✅ 仕様として「やらないこと」も明確になっているか？
- ✅ 判断に迷ったとき、誰に確認すべきか分かっているか？
フローチャート・処理設計のチェック
- ✅ フローチャートに例外ケースはすべて書けているか？
- フラグがON/OFFの場合
- データが存在しない場合
- 想定外の操作をされた場合
- ✅ 「理想的な使い方」だけでなく「間違った使い方」も想定できているか？
- ✅ この処理は「なぜ必要なのか」を説明できるか？
- ✅ 将来仕様変更があった場合、影響が出そうな箇所はどこか？
設計書の書き方チェック
- ✅ 「これ」「ここ」「そのテーブル」など誤解を生む表現を使っていないか？
- ✅ テーブル名・カラム名・値の意味は具体的に書いているか？
- ✅ 初見の人が読んでも、処理の流れを追えるか？
- ✅ 実装者が「確認なしで書ける」レベルの情報が書かれているか？
- ✅ レビューする人・実装する人の立場で読み返したか？
まとめ：新人のうちに設計を経験できて良かった
初めて設計を担当して感じたのは、設計は「難しい」以前に考える量が圧倒的に多い仕事だということです。
正直、最初は分からないことだらけで、先輩に指摘されて初めて気づくことばかりでした。
それでも設計を通して、「実装でなぜ迷ってしまうのか？」「仕様変更がなぜ辛いのか？」が少しずつ分かるようになってきました。
新人エンジニアのうちは設計が分からなくて当然だと思います。
私自身、最初の設計は決してうまくはいきませんでした。
ただ、設計を経験することで、実装だけでは気づきにくい以下の視点を学ぶことができたと思っています！
- 想定漏れをなくそうとする姿勢
- 要件を曖昧にしない意識
- 誰かに伝えるための文章を書く力
大変でしたが、とても良い勉強になりました！
この記事が、これから設計に関わる方、設計に不安を感じている方の心構えやヒントになれば嬉しいです。
