設計ができないと感じるエンジニアは、どこで手が止まっているのか
実装なら任された仕様を理解して、コードを書ける。テストで見つかった不具合も修正できる。それなのに、設計書を作ってほしいと言われると、何から書けばいいのかわからない。
設計書のサンプルを見ながら項目を埋めてみても、これで十分なのか判断できない。レビューで「なぜこの構成にしたのか」「この処理が失敗したらどうなるのか」と聞かれると、答えに詰まってしまう。
一方で、そもそも設計を担当する機会がなく、実装を続けながら「この先、設計ができるようになるのだろうか」と考えているエンジニアもいます。
採用面接や開発現場でエンジニアの経験を聞いていると、実装から設計へ担当を広げてきた人には、共通する経験があります。それは、自分が作るものについて、実装する前に考え、判断し、その理由を他の人に説明する経験です。
実装の経験は、すでに設計の材料になっています。手が止まるのは、多くの場合、「なぜこの形にするか」を自分で決め、書き残す経験がまだ少ないからです。その経験は、実装に近い詳細設計から積めます。
ただし、詳細設計と基本設計では、判断する範囲が違います。詳細設計で決めるのは、決まった仕様をどう実現するか。基本設計では、顧客の業務や要求を理解し、何を作るべきかを決める仕事が加わります。
この記事では、実装経験を詳細設計につなげる方法と、そこから基本設計へ担当を広げる道筋を説明します。工程全体の違いは上流工程と下流工程は何が違うのかで、さらに前段階の要件定義については要件定義ができないSEに足りないもので解説しています。
実装の経験は、すでに設計の材料になっている
実装を経験しているエンジニアには、設計を考えるための材料がすでに溜まっています。他の人が書いた設計書を読んでコードを作るとき、設計書の記載だけでは判断できないことに出会ったことはないでしょうか。処理の順番が曖昧だったり、エラーが起きた場合の動作が決まっていなかったり、画面とデータベースの項目が一致していなかったりする。実装を進めるうちに、設計段階で決めておくべきだったことが見えてきます。
レビューで「この条件では正しく動かない」「ここは共通処理にした方がよい」と指摘され、修正した経験もあるはずです。こうした経験を重ねるうちに、どんな設計なら実装しやすいか、どこで不具合が起こりやすいか、何を事前に確認しておくべきかがわかってきます。
当社のキャリアステップでも、最初の段階で重視しているのは、仕様を正確に理解して実装・テストをやり切ること、報告・連絡・相談を徹底すること、レビュー指摘を自分のものにすることです。そこで身につくのが、技術の基礎体力と、設計意図を読み解く力です。
設計書を読んで、「ここで入力値を確認しているのは、不正なデータを登録させないためだろう」「この処理を分離しているのは、別の機能からも利用するためだろう」と考えられるなら、すでに設計の判断に触れています。その理解を、自分が設計する側になったときに使えるようにする。これが次のステップです。
実装経験を設計力につなげるには、コードがどう動くかという理解を、なぜその構造や処理が必要なのかという理解へ広げていくことです。その理解を自分の言葉で設計書に書き、レビューを受けることで、判断の精度が上がっていきます。
設計書が書けないとき、足りないのは「なぜ」を決めた経験
設計書が書けないという相談で、まず整理しておきたいことがあります。設計書を書くことと、設計をすることは、密接につながっていても別の作業だということです。設計書の書式を知っていても、何をどう作るかが決まっていなければ内容は書けません。反対に、頭の中で実現方法を考えられていても、他のエンジニアが理解できる形で残せなければ、チームでの開発は進みません。
例えば、業務システムに「申請情報を登録する」という機能があるとします。実装を担当するなら、指定された入力項目を受け取り、必要なチェックを行い、データベースに保存する処理を作ります。詳細設計を担当するなら、その処理について実装前に決めることがあります。入力値はどの条件でエラーにするのか。すでに登録されているデータとの重複をどう扱うのか。複数のテーブルを更新する途中でエラーが起きたら、どこまで処理を取り消すのか。エラーの内容は、利用者や運用担当者にどう伝えるのか。
もちろん、これらをすべて詳細設計の担当者が自由に決めるわけではありません。業務上のルールや基本設計で決まっている事項には従い、未確定の事項は関係者に確認します。そのうえで実装方法を選び、他の人が同じ理解で作業できるように書く。それが詳細設計の仕事です。
設計書に「入力チェックを行う」とだけ書いてあっても、何をチェックするのかはわかりません。「申請日が未入力の場合は登録せず、該当項目にエラーを表示する」と書いてあれば、実装担当者は迷いません。そこに、なぜそのチェックが必要なのか、どの業務ルールに基づいているのかまで添えてあれば、後から仕様が変わったときにも、変更の影響を判断しやすくなります。
設計レビューで「なぜこの形にしたのか」と聞かれたとき、答えられる人は判断の根拠を持っています。仕様、品質、保守性、既存システムとの整合性。何を考慮してその方法を選んだのかを説明できます。答えられない場合に抜けていることが多いのは、その方法が今回の仕様にも合っているかを自分で確かめる過程です。
設計書は、実装のための資料であると同時に、開発チームや顧客との認識をそろえ、後から判断をたどるための資料でもあります。当社では成果物を見るとき、受け取る顧客が安心して任せられる品質かという視点も大切にしています。記述が曖昧だったり、他の資料と矛盾していたりすれば、確認に余計な時間がかかります。
AIを使えば、設計書のひな形や記述案は短時間で作れます。それでも、採用する設計が適切かどうかを判断し、その理由を説明する役割は残ります。設計力を高めるうえで必要なのは、文章をきれいに書く練習よりも、自分が選んだ方法と、その判断の根拠を説明できるようになることです。設計書のレビューで、AIに確かめさせることと人が判断することの分け方は設計書のレビューにAIをどう使うかにまとめました。
詳細設計から広げる。書いて、レビューを通してから実装する
実装から設計へ担当を広げるなら、最初に取り組みやすいのは詳細設計です。すでに経験しているプログラムの処理やデータの扱い方をもとに、実装前に設計を考えられるからです。
当社にも、若手のころは実装を中心に担当し、その後、詳細設計や基本設計まで役割を広げたエンジニアがいます。直近のプロジェクトでは、設計内容をドキュメントにまとめ、レビューで確認を受けてから実装する進め方をしています。この流れの中に、設計力を身につけるための経験が詰まっています。
まず、担当する機能について、何を実現する必要があるのかを確認します。基本設計書や既存仕様、関連するプログラムを読み、入力・出力、処理の流れ、外部とのインターフェース、異常時の動作などを整理します。次に、それを詳細設計書として具体化します。ある機能を複数の処理に分けるなら、どの処理にどの責任を持たせるか。共通化した方がよい部分はないか、将来の変更で影響が広がりすぎないか、既存の設計方針と矛盾していないか。ここで実装経験が効きます。過去に変更しづらいコードを修正したことがあれば、同じ問題を起こさない構造を考えられます。テストで例外処理の漏れを見つけた経験があれば、設計段階で異常系を確認できます。
設計がまとまったら、経験豊富なエンジニアにレビューしてもらいます。当社では、詳細設計のレビューはベテランエンジニアが担当します。プロジェクトリーダー（PL）が見ることもありますが、PLかどうかよりも、その領域の経験が豊富かどうかで決めています。レビューで見るのは、仕様を満たしているか、処理の分担が適切か、異常系が考慮されているか、実装やテストで問題が起きそうな箇所はないか、といった点です。「この部分はなぜ分けたのか」「別の実現方法は検討したか」と聞かれれば、自分の考えを説明します。より適切な方法が見つかれば、設計書を直します。
こうしてレビューを通過してから実装すると、設計した内容が実際に成立するかを自分で確かめられます。実装してみて考慮不足が見つかったときも、どの設計判断に原因があったのかを振り返れます。開発手法やプロジェクトによって、設計書の粒度やレビューの進め方は違います。それでも、自分で設計を考え、他の人に説明し、指摘を受けて直す経験の価値は変わりません。
最初から機能全体の設計を任される必要はありません。担当する処理の一部分からでも、実装前に設計をまとめ、レビューを受ける機会は増やせます。経験を積むと、仕様をそのまま設計書に落とす段階から、「この構造の方が変更しやすい」「この条件では障害が起こりそうだ」と、自分から改善を提案できるようになります。当社が詳細設計を担うエンジニアに期待しているのも、この提案力と、品質上の問題を先回りして見つける力です。
基本設計ができないと感じたら、加わるのは「決める」仕事
詳細設計を経験したあと基本設計に進むと、仕事の範囲が変わります。詳細設計で考えるのは、決まった仕様を実現するためのプログラムの構造や処理方法です。基本設計では、顧客の業務や要求を理解したうえで、システムの機能や動作そのものを決めていきます。どんな画面が必要か、誰が操作できるか、操作した結果どうなるか。プログラム内部の技術的な判断に加えて、顧客の業務を理解し、仕様について合意を得る力が必要になります。
例えば、顧客から「申請を差し戻せるようにしたい」という要望があったとします。実装する処理を考える前に、確認することがあります。誰が差し戻せるのか。どの状態の申請を差し戻せるのか。差し戻された人は何を修正できるのか。再申請したときに、前の承認履歴はどう扱うのか。通知は必要なのか。顧客にとっては当たり前の業務でも、システムにするには、こうしたルールを一つずつ明確にしなければなりません。
要望をそのまま実装しようとすると、既存機能との整合性が取れなくなることもあります。その場合は、現在の業務の流れを確認し、複数の実現方法を比べながら、顧客と仕様を調整します。必要なら、費用や開発期間、運用への影響も説明します。ここで役立つのが、実装や詳細設計で得た技術的な知識です。どの方法なら既存システムへの影響が小さいか、どこで不具合が起きやすいか、開発にどの程度の負荷がかかりそうか。技術の裏付けを持って、顧客と相談できます。
ただし、技術的に実現できることと、顧客の業務にとって適切であることは、必ずしも一致しません。 基本設計で求められるのは、相手の業務を理解し、曖昧な要求を整理する力と、複数の選択肢から判断する力です。実装とは別の経験を積むことになります。
当社の官公庁・交通系システムの開発でも、PLは要件の整理、基本設計、顧客との仕様調整、品質レビューを担当しています。顧客と相談しながら実現すべき仕様を決め、その内容が設計・実装・テストまで一貫して反映されているかを確認する仕事です。
基本設計ができないと感じるなら、技術知識を増やすことに加えて、顧客がなぜその機能を必要としているのかを考え、確認する経験が役立ちます。実装や詳細設計の知識を活かしながら、新たに顧客や業務に向き合う力を身につける段階です。この工程を「最初の上流」として捉える考え方は、上流工程と下流工程の違いを解説した記事でも紹介しています。
設計力の身につけ方：明日の実装から変えられること
では、今の現場で設計を担当する機会が少ない場合、何から始めればよいのか。おすすめしたいのは、自分が担当している実装について、設計者の立場でも考えてみることです。
明日修正するプログラムがあれば、コードを書く前に、どの処理を変更するのか、どんな動作を実現するのか、既存の機能にどんな影響があるのかを整理します。そのうえで、「なぜこの形にしたのか」を短く書き残してみてください。「既存の共通処理を使えば、他の機能と入力チェックの条件を統一できる」「この処理を分離しておけば、別の画面からも同じ処理を使える」。その程度で構いません。
他の人が書いた設計書を、設計意図を読み解くつもりで読むのも効きます。処理の分け方やデータの持ち方について、「自分ならどうするか」「なぜこの方法が選ばれたのか」を考える。理由がわからなければ、設計した人や経験豊富な先輩に聞いてみてください。
レビューで受けた指摘は、次の設計で先回りして潰します。異常系の考慮漏れを指摘されたなら、次は設計段階で異常系を確認する。データの整合性を指摘されたなら、更新処理を設計するときに同じ問題が起きないか見る。一度受けた指摘を次から自分で見つけられるようにすることが、そのまま設計力の向上です。
機会があれば、上司やリーダーに、担当する機能の詳細設計を先に書いてレビューしてもらえないか相談してみてください。最初は小さな処理でも、設計してから実装する経験を重ねるうちに、任せてもらえる範囲は少しずつ広がります。
設計力は、設計書の書き方を覚えるだけでは身につきません。実装で得た知識を使い、自分で考えた設計を他の人に説明し、直す。その繰り返しで育っていきます。
スーパーソフトウエアで、実装から設計へ広げる道筋
スーパーソフトウエアでは、エンジニアが実装から設計・判断・推進へと役割を広げるキャリアステップを設けています。キャリアページで示している段階は、次の4つです。
STEP 1「実装・設計の基盤をつくる」では、仕様を正確に理解し、担当する詳細設計・実装・テストを確実に遂行します。
STEP 2「詳細設計に責任を持つ」では、自ら設計を考え、品質上の問題に気づき、改善を提案する役割へ進みます。
STEP 3「顧客と仕様を決める」では、顧客の業務を理解し、仕様調整から設計・実装・品質確保までを担います。
STEP 4「チームを率いる」では、設計・顧客・チームを見渡し、開発全体を前に進める役割を担います。
ステップは年次ではなく、現場で発揮した価値で決まります。中途入社なら、それまでの経験に応じてSTEP 2やSTEP 3から始まることもあります。実際に、中途入社後のプロジェクトで既存の仕様や資料を読み込み、システム全体を把握したうえで、開発の進め方や仕様調整を率先して担うようになった社員がいます。担える範囲を自分から広げていった結果が、顧客からの信頼につながりました。
当社が大切にしている「開発推進力」も、この成長の道筋と重なります。技術を形にする「作る力」を土台に、「理解する力」「判断する力」「進める力」「共有する力」を広げていく考え方です。PLを目指す段階で必要になる力は、PLになるには何が足りないのかで解説しています。
実装から上流へ役割を広げたいエンジニア向けの求人も公開しています。実装経験を活かしながら、設計や技術判断を担えるエンジニアへ成長したい方は、ぜひご覧ください。
この記事のテーマについて、もっと話を聞いてみたい方へ：
- カジュアル面談を申し込む — 30〜45分のオンライン面談
- 募集職種を見る — 実装から設計・上流へ広げられる求人一覧
- 上流工程と下流工程は何が違うのか — 最初の上流としての基本設計
- PLになるには何が足りないのか — 設計の意図を説明できる力
- キャリアを知る — 実装から、設計・判断・推進へ
- 他のキャリア記事を読む — PL／上流工程／キャリアに関する他の記事
