サイトアイコン プログラマー(PG)・システムエンジニア(SE)になるための入門講座

将来の拡張を考える設計のコツとは？IT初心者が知っておきたい変更に強いシステムの作り方

pgse

将来の拡張を考える設計のコツとは？IT初心者が知っておきたい変更に強いシステムの作り方

結論から言うと、将来の拡張を考える設計では「何でも変更できるようにする」のではなく、「変更される可能性が高い部分を見極め、影響を小さくできる構造にしておく」ことが重要です。

ITシステムは、一度作った状態のまま使われ続けるとは限りません。利用者の増加、機能追加、サーバー増設、クラウド移行、組織変更、セキュリティ要件の変更などによって、後から仕様が変わることがあります。

そのたびに大規模な改修が必要になる設計では、費用も作業時間も増えてしまいます。

一方で、将来起こりそうな変更をある程度想定しておけば、少ない修正で対応できる可能性があります。

社内SE、情シス、インフラエンジニア、運用保守担当者が設計に関わるときも、「今動くか」だけではなく「将来変わったときに困らないか」という視点が重要です。

  1. 将来の拡張を考える設計とは
  2. なぜ将来の拡張を考える必要があるのか
  3. 初心者が最初に覚えたい「予想しすぎない」という考え方
  4. 将来の拡張を考える設計のコツ1：変更されそうな部分を洗い出す
  5. 将来の拡張を考える設計のコツ2：機能を分けて考える
  6. 将来の拡張を考える設計のコツ3：設定値をプログラムから分ける
  7. 将来の拡張を考える設計のコツ4：利用者数の増加を考える
  8. 将来の拡張を考える設計のコツ5：サーバーを増やせるか考える
  9. 将来の拡張を考える設計のコツ6：IPアドレスやネットワークを余裕を持って考える
  10. 将来の拡張を考える設計のコツ7：権限をユーザー単位で管理しすぎない
  11. 将来の拡張を考える設計のコツ8：データ量の増加を忘れない
  12. 将来の拡張を考える設計のコツ9：外部システムとの連携を分離する
  13. 拡張性だけでなく運用担当者・保守担当者も意識する
  14. 障害発生時の影響範囲も考えて拡張する
  15. Windowsで確認できる基本情報
  16. 障害調査ではイベントビューアーも確認する
  17. 筆者が感じた「将来を考えなかった設計」の失敗
  18. 初心者がやりがちな拡張設計のミス
  19. 現場で評価される拡張設計の確認手順
  20. 上司へ報告・相談するときのポイント
  21. エスカレーションするタイミング
  22. 拡張時に注意したい危険な変更
  23. 新人が覚えておきたい拡張しやすい設計の5つのポイント
  24. 関連して覚えておきたいIT用語
  25. 将来の拡張を考える設計についてよくある質問
    1. Q．最初から最大規模を想定して作るべきですか？
    2. Q．拡張性を高くすると設計は複雑になりますか？
    3. Q．インフラでも拡張性を考える必要がありますか？
    4. Q．将来の拡張で最初に考えることは何ですか？
    5. Q．拡張性と保守性は同じですか？
  26. まとめ

将来の拡張を考える設計とは

将来の拡張を考える設計とは、利用者や機能、データ量、サーバー台数などが増えた場合でも、大きな作り直しをせず対応しやすい構成にすることです。

この性質を「拡張性」と呼ぶことがあります。

例えば、現在は社員50人だけが使うシステムでも、数年後には500人が利用するかもしれません。

最初から500人分の高性能な設備を用意する必要はありませんが、「利用者が増えたらサーバーを追加できるか」「権限管理が複雑にならないか」といった点は考えておく価値があります。

なぜ将来の拡張を考える必要があるのか

システムを取り巻く環境は変化します。

こうした変更が発生するたびにシステム全体を作り直していては、コストや障害リスクが大きくなります。

拡張しやすい設計にしておくことで、将来の変更による影響範囲を小さくできます。

初心者が最初に覚えたい「予想しすぎない」という考え方

将来の拡張を考えると聞くと、「考えられる機能を全部入れておこう」と思うかもしれません。

しかし、使う予定のない機能まで作り込むと、設計が複雑になり、現在の開発や保守が難しくなることがあります。

重要なのは、将来を完全に予測することではありません。

変わりそうな部分と、変わりにくい部分を分けることがポイントです。

例えば、会社名やメール送信先のような設定値は変更される可能性があります。一方、システムの基本的な目的は簡単には変わらないこともあります。

変更されやすい部分だけを柔軟にする方が、現実的な設計になります。

将来の拡張を考える設計のコツ1：変更されそうな部分を洗い出す

最初に「将来何が変わりそうか」を整理します。

確認項目 将来起こりそうな変更
利用者 社員数や利用部署が増える
機能 新しい申請や検索機能が追加される
データ 保存件数やファイル容量が増える
サーバー 性能不足により増設する
ネットワーク 拠点やクラウド接続が増える
認証 Active Directoryや多要素認証との連携が変わる
外部連携 API連携するサービスが増える

こうした変更候補を整理すると、どこに柔軟性を持たせるべきか判断しやすくなります。

将来の拡張を考える設計のコツ2：機能を分けて考える

複数の機能が強く結び付いていると、一つの変更がシステム全体へ影響しやすくなります。

例えば、ユーザー管理、メール送信、帳票出力、データ保存などを適切に分けて設計しておけば、メール送信方式だけを変更するときに他の機能へ与える影響を減らせます。

このように役割ごとに機能を分けることは、保守性や拡張性の向上にもつながります。

「この機能を変更したら、どこまで修正が必要になるか」を考える習慣が重要です。

将来の拡張を考える設計のコツ3：設定値をプログラムから分ける

変更される可能性がある値をプログラムへ直接書き込むと、変更のたびにプログラム修正が必要になります。

例えば次のような値です。

必要に応じて設定ファイルや管理画面などから変更できるようにしておくと、将来の変更へ対応しやすくなります。

ただし、重要な設定を誰でも変更できる状態は危険です。

アクセス権限、変更履歴、承認方法なども合わせて設計します。

将来の拡張を考える設計のコツ4：利用者数の増加を考える

最初は少人数で利用するシステムでも、利用者が増えることがあります。

利用者数が増えると、単純にアカウント数だけが増えるわけではありません。

そのため、「現在の50人で動く」だけではなく、「100人、500人になった場合にどこが最初に限界になるか」を考えます。

将来の拡張を考える設計のコツ5：サーバーを増やせるか考える

アクセス数が増えた場合、サーバー性能を上げる方法があります。

1台のサーバーのCPUやメモリを増やして性能を高める方法を、一般にスケールアップと呼びます。

一方、サーバー自体の台数を増やして処理を分散する方法をスケールアウトと呼びます。

方式 考え方
スケールアップ 1台のサーバーを高性能にする
スケールアウト サーバー台数を増やして処理を分散する

どちらが適しているかはシステムによって異なります。

将来アクセス数が大幅に増える可能性がある場合は、サーバー追加が可能な構成か確認しておくとよいでしょう。

将来の拡張を考える設計のコツ6：IPアドレスやネットワークを余裕を持って考える

インフラ設計では、IPアドレス設計も将来の拡張に関係します。

現在必要な端末数だけを基準にネットワークを作ると、PC、プリンター、無線LANアクセスポイント、サーバーなどが増えたときにIPアドレスが不足する可能性があります。

DHCP（Dynamic Host Configuration Protocol）を利用する環境では、DHCPで配布できるIPアドレスの範囲にも注意します。

ただし、必要以上に巨大なネットワークへすることが正解とは限りません。

セキュリティや障害影響範囲も考え、部署、用途、端末種類などに応じてネットワークを分割することがあります。

将来の拡張を考える設計のコツ7：権限をユーザー単位で管理しすぎない

社内システムや共有フォルダでは、利用者が増えるほど権限管理が複雑になります。

例えば100人のユーザーへ一人ずつ個別にアクセス権限を設定すると、人事異動や退職のたびに確認が必要です。

Active Directory環境では、セキュリティグループを利用して権限管理する方法があります。

例えば「営業部共有フォルダ編集」「営業部共有フォルダ閲覧」のようなグループを作成し、ユーザーを所属させます。

人に直接権限を付けるのではなく、役割やグループを通して管理できる設計にすると拡張しやすくなります。

将来の拡張を考える設計のコツ8：データ量の増加を忘れない

初心者が見落としやすいのがデータ量です。

稼働開始直後は問題なくても、数年間利用するとログ、添付ファイル、データベースなどが増えていきます。

設計時には次の項目を確認します。

特にログを無制限に保存すると、ディスク容量不足によってサービス停止につながることもあります。

将来の拡張を考える設計のコツ9：外部システムとの連携を分離する

社内システムでは、メールサービス、認証サービス、会計システムなど外部の仕組みと連携することがあります。

外部システムは将来仕様が変わる可能性があります。

そのため、外部連携部分と業務処理を強く結び付けすぎないようにします。

例えば外部サービスへの接続処理を一か所へまとめておけば、接続先が変わった場合も修正範囲を限定しやすくなります。

拡張性だけでなく運用担当者・保守担当者も意識する

機能を増やしやすくても、運用や保守が難しくなっては意味がありません。

拡張後にも次のことができるか確認します。

拡張性、運用性、保守性は別々に考えるのではなく、合わせて考えることが重要です。

障害発生時の影響範囲も考えて拡張する

システムを拡張すると構成要素が増えるため、障害原因の切り分けも複雑になります。

例えば社内システムへ接続できない場合は、次のように確認します。

  1. 1人だけか複数人か確認する
  2. 特定拠点だけか確認する
  3. Windows端末側を確認する
  4. IPアドレスを確認する
  5. DNSによる名前解決を確認する
  6. ネットワーク通信を確認する
  7. サーバーやサービスを確認する
  8. Active Directoryなど認証側を確認する
  9. アプリケーションログを確認する

機能やサーバーを増やすときは、「障害が発生したらどこを見ればよいか」まで設計しておくと現場で困りにくくなります。

Windowsで確認できる基本情報

Windows 11では、GUIとCUIの両方から端末やネットワークの状態を確認できます。

GUIでは「Windowsキー + I」で設定画面を開き、「ネットワークとインターネット」から接続状態などを確認できます。

コマンドプロンプトやPowerShellでは次のような確認が可能です。

コマンド 主な確認内容
ipconfig /all IPアドレス、DNS、DHCPなどを確認
ping 通信相手へ到達できるか確認
nslookup DNSによる名前解決を確認
whoami 現在のログインユーザーを確認
Get-NetIPConfiguration PowerShellからネットワーク設定を確認

障害調査ではイベントビューアーも確認する

Windows 11やWindows Serverで障害が起きた場合、イベントビューアーが原因調査に役立つことがあります。

  1. 「Windowsキー + R」を押します。
  2. 「eventvwr.msc」と入力します。
  3. Enterキーを押します。
  4. 「Windowsログ」を開きます。
  5. 「システム」や「アプリケーション」を確認します。
  6. 障害発生時刻付近のイベントID、ソース、エラー内容を確認します。

ただし、イベントビューアーにエラーがあるだけで障害原因と判断してはいけません。

障害の発生日時、利用者の操作、ネットワークやサーバーの状態などと合わせて確認します。

筆者が感じた「将来を考えなかった設計」の失敗

私自身、最初は「現在必要な数だけ用意すれば十分」と考えてしまったことがあります。

ところが利用対象が増えた際、設定や権限が個別管理になっていたため、一件ずつ追加する必要があり、思った以上に作業が増えてしまいました。

技術的には対応できても、件数が増えると運用負荷が大きくなります。

この経験から、将来の拡張とはサーバー性能だけではなく、「人や設定が増えたときに管理できるか」まで考える必要があると感じました。

初心者がやりがちな拡張設計のミス

現場で評価される拡張設計の確認手順

将来の拡張を考えるときは、次の順番で整理すると分かりやすくなります。

  1. 現在の利用者数と構成を確認する
  2. 将来増えそうなものを洗い出す
  3. 変更されやすい部分を特定する
  4. 変更による影響範囲を確認する
  5. 機能や設定を分離できないか検討する
  6. 容量や性能の限界を確認する
  7. 監視・バックアップ方法を確認する
  8. 障害発生時の切り分け方法を考える
  9. 変更手順と切り戻し方法を準備する

「将来何が増えるか」だけでなく、「増えたときに誰がどう管理するか」まで考えられると実務的な設計になります。

上司へ報告・相談するときのポイント

拡張性について上司やリーダーへ相談するときは、「将来困ると思います」だけではなく、具体的に整理します。

例えば「現在は利用者100名ですが、来年度に200名程度まで増える予定です。現在の権限設定はユーザー単位なので、グループ管理へ変更した方が運用負荷を抑えられます」と説明すると判断してもらいやすくなります。

エスカレーションするタイミング

将来の拡張によって次のような影響が想定される場合は、上位担当者や専門担当へ相談します。

拡張時に注意したい危険な変更

拡張のためであっても、本番環境の設定を安易に変更してはいけません。

特にActive Directory、グループポリシー、DNS、DHCP、ファイアウォール、ネットワーク、アクセス権限、データベースなどの変更は、複数ユーザーへ影響する可能性があります。

変更前に影響範囲、現在値、バックアップ、作業手順、切り戻し方法、作業後の確認内容を整理し、社内ルールに従って承認を得てください。

新人が覚えておきたい拡張しやすい設計の5つのポイント

  1. 分ける：変更される部分を他の機能から分離する
  2. 増やせる：利用者やサーバーが増えても対応できるようにする
  3. 変えられる：設定変更を安全に行えるようにする
  4. 影響を抑える：一つの変更が全体へ広がらないようにする
  5. 運用できる：拡張後も監視・保守・障害対応できるようにする

関連して覚えておきたいIT用語

用語 初心者向けの意味
拡張性 利用者や機能が増えても対応しやすい性質
スケーラビリティ 負荷や利用規模の増加に対応できる能力
スケールアップ 1台のサーバーを高性能にする方法
スケールアウト サーバー台数を増やして処理能力を高める方法
保守性 システムを修正・変更しやすい性質
可用性 必要なときにシステムを利用できる度合い
Active Directory Microsoft環境でユーザーやPC、認証などを管理する仕組み
DNS Domain Name System。名前とIPアドレスを対応付ける仕組み
DHCP Dynamic Host Configuration Protocol。IPアドレスなどを自動配布する仕組み

将来の拡張を考える設計についてよくある質問

Q．最初から最大規模を想定して作るべきですか？

必ずしも必要ではありません。将来使うか分からない規模に合わせるとコストや構成が過剰になる可能性があります。現実的な成長予測をもとに、後から拡張しやすい構成にすることが大切です。

Q．拡張性を高くすると設計は複雑になりますか？

複雑になる場合があります。そのため、すべてを柔軟にするのではなく、変更される可能性が高い部分を中心に設計します。

Q．インフラでも拡張性を考える必要がありますか？

必要です。サーバー性能、ストレージ容量、IPアドレス、ネットワーク帯域、DNS、DHCP、バックアップなどは、利用規模が増えると影響を受けます。

Q．将来の拡張で最初に考えることは何ですか？

利用者、データ量、機能、接続先などのうち「何が増える可能性が高いか」を整理します。そのうえで、変更箇所と影響範囲を確認します。

Q．拡張性と保守性は同じですか？

同じではありません。拡張性は規模や機能を増やしやすい性質、保守性は修正や変更をしやすい性質です。ただし、実際の設計では両方を合わせて考えることが重要です。

まとめ

将来の拡張を考える設計では、未来のすべてを予測する必要はありません。

利用者、データ、機能、サーバー、ネットワークなど「将来変わりそうな部分」を見極め、変更による影響を小さくできる構造にしておくことが重要です。

IT初心者のうちは、「現在の要件を満たしているから完成」と考えがちですが、実際のシステムは稼働後も変化していきます。

設計時には「利用者が10倍になったらどうなるか」「サーバーを追加できるか」「設定変更だけで対応できるか」「権限や監視を管理し続けられるか」と考えてみてください。

「分ける・増やせる・変えられる・影響を抑える・運用できる」という視点を持つことが、将来の変更に強い設計への第一歩です。

モバイルバージョンを終了