詳細設計までは任される。
でも、基本設計になると急に別の人が入る。
その境界がどこにあるのか。実装だけを続けていて、いつか基本設計に辿り着けるのか。不安になることがあります。
特にSESで実装中心に働いていると、詳細設計書をもとに画面を作る、APIを実装する、DB更新処理を書く、といった仕事は経験できても、基本設計の場にはなかなか入れないことがあります。
その結果、「基本設計は自分とは別の世界の仕事なのではないか」と感じやすくなります。
ただ、実務で考えると、基本設計は実装経験と切り離されたものではありません。
基本設計に必要な視点は、日々の実装の延長線上にあります。違いがあるとすれば、「どう実装するか」だけでなく、「変更されたらどこに影響するか」「その責務をどこに置くか」「運用時に困らないか」まで見ているかどうかです。
この記事では、詳細設計から基本設計へ進むために必要な視点を、実装者の立場から整理します。
詳細設計と基本設計は何が違うのか
詳細設計と基本設計の違いは、単にドキュメント名の違いではありません。
詳細設計では、すでに決まった仕様をもとに、画面項目、入力チェック、処理手順、DB更新内容などを具体化していきます。実装者が迷わずコードを書けるように、「この機能をどう作るか」を明確にする工程です。
C#/.NETの業務アプリであれば、Controllerでリクエストを受け、Serviceで処理を行い、RepositoryやDbContextを通してDBにアクセスする、といった実装の流れを具体化していくイメージに近いです。
一方で基本設計では、その機能をシステム全体の中でどう成立させるかを考えます。
たとえば、あるステータス更新機能を作るとしても、単に「ボタンを押したらステータスを更新する」と考えるだけではありません。
そのステータスはどの画面で参照されるのか。別のバッチ処理や帳票出力に影響しないか。更新後に通知やログは必要か。後からステータスの種類が増えたとき、どこを直すことになるのか。
こうした影響範囲を見ながら、機能の置き場所や処理の責務を決めていくのが、基本設計で必要になる視点です。
もちろん、詳細設計と基本設計の担当範囲は、会社や現場によって異なります。基本設計の中でかなり細かい処理まで決める現場もあれば、詳細設計で仕様の整理や影響範囲の確認まで求められる現場もあります。
そのため、「ここからここまでが基本設計」と工程名だけで固定して考えすぎる必要はありません。
多くの現場で共通しているのは、システム全体への影響をどこまで考えるかという視点の差です。
基本設計で見られるのは、システム全体への影響
実装では、目の前の機能を正しく動かすことが重要です。
入力値を受け取り、業務ルールに沿って判定し、DBへ保存し、結果を返す。まずはこの流れを正しく作れなければ、機能として成立しません。
ただ、基本設計ではもう少し広い範囲を見ます。
影響範囲を見る
この機能はどの業務フローの一部なのか。ほかの機能と同じルールを使っているのか。今後条件が増えたときに、どの画面、どのService、どのテーブル、どのテストに影響するのか。
こうした問いは、抽象的な設計論ではありません。実装していると、実際に何度も直面する問題です。
たとえば、同じ条件分岐が複数の画面に散らばっていると、仕様変更のたびに修正箇所を探すことになります。1か所直して終わりだと思っていたら、別画面だけ古い判定のまま残っていた、ということも起こります。
このとき問題になるのは、コードが動くかどうかだけではありません。
業務ルールをどこに置くべきだったのか。画面ごとに持つべき処理だったのか。Serviceに集約すべきだったのか。Modelとして表現した方がよかったのか。
この「どこに置くべきか」を考えることが、設計視点です。
責務分離は、変更に耐えるために考える
責務分離という言葉は、少し堅く聞こえるかもしれません。
ただ、実務で考えると、責務分離は「あとから変更しやすくするために、判断や処理の置き場所を分けること」です。
たとえば、画面側に業務ルールを書きすぎると、その画面では動きます。しかし、同じルールを別の画面やAPIでも使うことになった瞬間に、同じ処理をもう一度書くか、どこかへ移す必要が出てきます。
最初からServiceに業務ルールを置いておけば、画面は入力を受け取り、結果を表示する役割に集中できます。
Serviceは業務判断を担当し、Repositoryはデータ取得や保存を担当する。Modelは状態やルールを表現する。
ここでいうModelは、画面表示用のデータ入れ物というより、状態や業務ルールを表現する役割として使っています。現場によってModelという言葉の意味は変わるため、役割を確認しながら読むのが大事です。
もちろん、すべてをきれいに分ければよいという話ではありません。小さな機能に対して過剰に層を増やすと、かえって読みにくくなることもあります。
大事なのは、「この判断はどこに置くと、次の変更に耐えやすいか」を考えることです。
C#/.NETの実装であれば、入力チェックひとつを取っても分け方があります。
必須入力や文字数のようなUI都合のチェックは画面やリクエストモデルに近い場所で扱いやすい。一方で、「この状態では申請できない」「この区分では金額計算のルールが変わる」といった業務ルールは、画面だけに閉じ込めると後から困りやすくなります。
この違いを意識するだけでも、実装は基本設計に近づきます。
変更影響を考えると、設計の見え方が変わる
実装中に「この条件が変わったら、どこを直すことになるか」と考えるだけで、見えるものが変わります。
具体例として、料金計算の条件が追加される可能性があるなら、計算処理をControllerに直接書くより、Serviceや専用のModelに寄せた方が変更しやすいかもしれません。
ステータス更新のルールが複数画面で使われるなら、画面ごとに判定を書くのではなく、状態遷移のルールとしてまとめた方がよいかもしれません。
DBアクセスの都合と業務判断が同じメソッドに混ざっているなら、後から読んだ人は「これはデータ取得の処理なのか、業務ルールなのか」を判断しづらくなります。
変更影響を見るというのは、将来を完璧に予測することではありません。
むしろ、実務ではすべての変更を予測することはできません。だからこそ、変わりそうなところと、変わりにくいところを分けて考えます。
条件が変わりそうなら、その条件を一か所に寄せる。複数機能で使いそうなルールなら、画面に閉じ込めない。運用で確認が必要になりそうなら、ログや状態を追えるようにする。
こうした小さな判断の積み重ねが、保守しやすい設計につながります。
つまり、「動くか」だけではなく、「変更されたときにどう壊れるか」まで見るようになると、設計の見え方が変わります。
保守性は、未来の実装者への配慮でもある
保守性というと、きれいなコードを書くことだけを想像するかもしれません。
しかし実務での保守性は、半年後の自分や、別の担当者が安全に変更できるかという問題です。
今は自分が仕様を覚えているので、多少複雑な条件分岐でも読めるかもしれません。ですが、数か月後に別の人が修正する場合、その人は当時の背景を知りません。
そのときに、メソッド名から意図がわかるか。業務ルールがServiceにまとまっているか。画面、Service、Repositoryの責務が大きく崩れていないか。テストで重要な条件が確認できるか。
こうした点が、保守性に効いてきます。
コメントで説明することも必要ですが、コメントがないと理解できない構造になっている場合は、責務の置き方を見直した方がよいこともあります。
設計視点とは、難しい図を書けることだけではありません。
あとから読んだ人が、なぜその処理がそこにあるのかを理解できるようにすることも、十分に設計です。
運用まで考えると、基本設計に近づく
実装中は、どうしても「正常に動くか」に意識が向きます。
しかし、システムはリリースして終わりではありません。実際には、問い合わせが来る、障害が起きる、データを確認する、再実行やリカバリが必要になる、といった運用が続きます。
基本設計では、この運用時の見え方も重要になります。
失敗した後を追えるか
たとえば、処理が失敗したときにログで追えるか。どのIDを見れば対象データに辿り着けるか。ステータスが途中で止まったとき、どの状態なのか判断できるか。手動で直す必要が出たとき、何を確認すればよいか。
これらは、実装者にとっても無関係ではありません。
ログを出す場所、例外の扱い、ステータスの持ち方、更新タイミングは、コードを書くときに決まります。つまり運用しやすさは、実装の中にも入り込んでいます。
「この処理は失敗したときに追えるか」と考えることは、基本設計の視点そのものです。
正常系だけでなく、失敗した後に追えるか、直せるかまで考えると、実装は運用に耐える設計へ近づきます。
実装経験は、基本設計の土台になる
基本設計に進みたいと思ったとき、「自分は実装しかしていないから不利だ」と感じることがあります。
しかし、実装経験は上流工程に進むうえで不利な材料ではありません。むしろ、設計判断の土台になります。
実装したことがあるからこそ、どこが壊れやすいかがわかります。どこに条件分岐が散らばると修正がつらくなるか、どの処理がテストしにくいか、どの構造だと仕様変更に弱いかを現実的に想像できます。
これは、コードを書いてきた人の強みです。
基本設計では、理想だけでなく実現可能性も見ます。きれいな構成に見えても、実装やテストが複雑になりすぎるなら、その設計は現場で扱いづらいかもしれません。
実装経験がある人は、その違和感に気づけます。
だから、「実装しかしていない」と考えるより、「実装を通じて、変更に弱い場所や保守しにくい構造を見てきた」と捉えた方がよいです。
その経験を言葉にできるようになると、基本設計に近づいていきます。
実装者でも今日からできること
基本設計に進むために、いきなり大きな設計書を書けるようになる必要はありません。
まずは、次の実装タスクでひとつだけ考えてみてください。
「この条件が変わったら、どこへ影響するか」
たとえば、入力チェックの条件が変わったら、画面だけで済むのか。Serviceの業務ルールにも影響するのか。DBに保存している値や、既存データの扱いまで変わるのか。
ステータスの種類が増えたら、一覧画面、詳細画面、検索条件、バッチ処理、通知処理、テストデータのどこに影響するのか。
完璧に洗い出す必要はありません。最初は1つか2つで十分です。
大事なのは、コードを書く前に影響範囲を考え、それを短くメモに残すことです。
「この条件が変わる場合は、Serviceの判定と一覧表示に影響する」
この程度でも構いません。
そのメモは、レビューで設計意図を説明するときにも役立ちます。なぜその処理をControllerではなくServiceに置いたのか。なぜ同じ条件を共通化したのか。なぜログを残すようにしたのか。
実装中の小さな判断を言語化することが、設計視点を育てます。
まとめ
詳細設計は、「決まった仕様をどう実装するか」を具体化する工程です。
基本設計は、「その仕様をシステム全体の中でどう成立させるか」を考える工程です。
ただし、両者の境界は現場によって変わります。大事なのは工程名ではなく、変更、責務、運用、影響範囲まで見ているかどうかです。
基本設計は、実装者にとって別世界の仕事ではありません。
同じ条件分岐が散らばってつらかった経験。画面に業務ルールを書きすぎて後から直しにくくなった経験。ログが足りずに調査で困った経験。そうした実装の中の違和感は、すべて設計視点につながります。
1記事目の「SESエンジニアが『実装だけでは物足りない』と感じた理由」では、実装だけでは物足りないと感じる背景を整理しました。
2記事目の「SESエンジニアが上流工程へ進むために最初にやること」では、上流工程へ進むために、まず今の実務の見方を変えることを扱いました。
この記事は、その次の一歩として、詳細設計や実装の中で基本設計につながる視点を整理したものです。
次の実装タスクで、ひとつだけ試してみてください。
「この変更はどこへ影響するか」
そう考えて、短くメモに残す。
最初から完璧に影響範囲を洗い出せなくても大丈夫です。
まずは「どこに影響しそうか」を考える習慣を持つだけでも、視点は変わり始めます。
その小さな習慣が、実装経験を設計判断の土台に変えていきます。
コメント