第7回：「設計ができるエンジニア」になるために必要なスキルセット

コンテンツ

🔹 １．はじめに – 設計ができるエンジニアとは？
🔹 ２．「構築」と「設計」の違いを理解する
🔹 ３．「設計ができるエンジニア」に必要なスキルセット
🔹 ４．設計思考を鍛えるための実践的アプローチ
🔹 ５．アウトプット – 「システム設計の原則と事例集」を作ろう
🔹 ６．設計力は「視野」と「伝える力」で決まる

🔹 １．はじめに – 設計ができるエンジニアとは？

システムを「動かす」だけでなく、「使いやすく」「壊れにくく」「成長に備えた」形で設計できるエンジニアは、市場価値が非常に高い存在です。単に構築作業をこなすだけでは見えてこない視点――それが設計です。本記事では、運用や構築の経験を土台に、設計ができるエンジニアへとステップアップするために必要なスキルや思考法について解説します。3年目を迎える前に、設計力という新たな武器を手に入れましょう。

🔸 1-1. 構築だけでは不十分な理由

サーバーエンジニアとしての最初のステップは、構築作業に慣れることです。OSをインストールし、パッケージを導入し、ネットワークや監視の設定を行う――この一連の流れに慣れることで、確かに「一人前に近づいた」と感じるかもしれません。

しかし、実は構築作業ができるだけでは、市場価値はあまり高まりません。

🧱 構築作業は「作業者」としてのスキル

構築は、言ってしまえば「仕様に従ってサーバーを組み立てる」作業です。決められた要件を満たす構成を、マニュアル通りに手を動かして完成させることが目的です。

たとえば、こんな状況が考えられます。

上司に言われた通りのディスク構成でRAIDを組む
決められた通りのアプリを入れ、設定ファイルを修正する
手順書通りにネットワークのIPアドレスを割り当てる

これらはすべて「構築作業」であり、再現性があり、ある程度経験を積めば誰でもできるようになります。つまり、代替可能性が高い作業とも言えます。

🔍 構築だけでは「なぜそうしたのか？」が語れない

設計ができるエンジニアとの違いは、「なぜこの構成にしたのか？」を自分の言葉で説明できるかどうかです。

構築だけを繰り返していると、その背景にある理由や判断基準に触れる機会が少なくなります。

なぜこの構成は2台構成なのか？
なぜこのディレクトリ構造にしたのか？
なぜログ出力先は別ディスクにしているのか？

こうした問いに自分なりの答えを持っていないと、“作業者”としての成長にとどまり、設計者としての価値は育ちません。

⚙️ 「運用」「保守」「拡張」まで考えるのが設計者の役割

構築されたシステムは、運用されてこそ価値が発揮されます。そして運用中には、監視・障害対応・設定変更・スケールアウトなど、さまざまな事象が発生します。

設計ができるエンジニアは、こうした「未来の利用シーン」までを視野に入れて構成を決定します。

後からログが肥大化しないようにローテーションの仕組みを入れておく
バックアップ取得やリストアの運用を前提にデータ配置を考える
拡張性を確保するため、ネットワークやストレージに余白を残す

これらはすべて「構築」の中では見落とされがちなポイントであり、設計者ならではの視野が必要です。

🧠 構築の経験は、設計力を高める「素材」になる

ここまで読むと、「構築って意味がないの？」と思われるかもしれませんが、そうではありません。

むしろ構築経験は、設計力を育てる上での重要な素材です。

構築を通じて、

実際にどこでつまずくか
運用上、何が面倒なのか
どの構成が保守しやすいか

といった現場のリアルを体感することで、設計の精度は確実に上がっていきます。

ただし、「なぜその構成にするのか？」「もっとよい選択肢はあるか？」といった視点を持たなければ、経験がただの作業で終わってしまいます。

🏁 設計力は構築の“その先”にある

構築作業ができるようになることは、成長の第一歩です。しかし、市場価値の高いサーバーエンジニアを目指すなら、設計という次のステージへ進む視点が不可欠です。

設計とは、「このシステムが長く、安全に、運用され続けるにはどうあるべきか？」を考える仕事です。
構築だけで満足せず、常にその先を見据える姿勢が、あなたの価値をぐっと引き上げてくれるはずです。

🔸 1-2. 設計ができるエンジニアの特徴とは？

サーバーをただ「構築できる」ことと、「設計できる」ことは全く別のスキルです。設計ができるエンジニアは、単なる技術者ではなく、システム全体の未来を描けるクリエイターでもあります。

では、具体的に「設計ができるエンジニア」は、どのような視点と能力を持っているのでしょうか？ここでは、その代表的な特徴を詳しく見ていきます。

🧭 ① 要件から“構成”を自分で考えられる

設計ができるエンジニアは、「どう作るか？」ではなく「なぜこの構成にするのか？」を自分で考え、提案できます。

たとえば、次のような判断が求められます。

同時接続数が多いサービス → ロードバランサーを配置して分散
データベースの負荷が高い → 読み取り専用のリードレプリカを用意
夜間バッチ処理が重い → 処理専用サーバーをスケジュール起動で節約

構築担当者が「決まった構成」を実装するのに対し、設計者は条件に応じた“最適解”を自ら導き出す能力を持っています。

🔍 ② 常に「運用」を意識している

設計ができるエンジニアは、構築したその先、つまりシステムが運用される“未来”を想像しています。

エラーログが蓄積したときに、運用担当者が困らないか？
ハード障害が起きたときに、迅速に切り替えられる構成になっているか？
設定ファイルやスクリプトは、属人化せずメンテナンスしやすいか？

こうした視点があるからこそ、「使いやすく、壊れにくく、運用しやすいサーバー」を設計できるのです。

📈 ③ 拡張・変更に備えた柔軟性を持たせる

どんなシステムでも、1年後・2年後には必ず何かが変わります。トラフィックが増える、機能が追加される、他システムと連携するなど、未来は常に動的です。

設計ができるエンジニアは、将来の変化に対応できるよう、

サーバー台数を増やしやすい構成
設定変更が1箇所で済むディレクトリ構造
バージョンアップや置き換えに対応できるモジュール設計

など、「今」だけでなく「その先」も見据えた柔軟な設計を意識しています。

🧩 ④ 他者と連携しやすいドキュメントを残す

どれだけ優れた設計をしても、それが他のメンバーに伝わらなければ意味がありません。設計ができるエンジニアは、必ずドキュメントに意図と構成を残します。

サーバー構成図（物理・論理）
各コンポーネントの役割説明
監視・バックアップの設計方針
トラブル時の対応フロー

設計者の頭の中にある情報を、視覚的・論理的にわかりやすく共有するスキルもまた、設計力の一部です。

🤝 ⑤ 他部門や非技術者とも“話が通じる”

設計フェーズでは、開発チーム・セキュリティ担当・運用チーム、さらには業務部門など、さまざまな関係者との調整や折衝が必要になります。

設計ができるエンジニアは、こうした相手に対して、

専門用語を噛み砕いて説明できる
システム上のリスクや制約を整理して伝えられる
複数の選択肢を提示し、合意形成を図れる

といったコミュニケーション力とバランス感覚を備えています。

🏁 設計とは“全体を見て、未来をつくる”仕事

構築が「今をつくる」作業だとすれば、設計は「未来をつくる」仕事です。

設計ができるエンジニアの特徴は、単に技術に詳しいだけではありません。要件を読み解き、運用や将来を考え、他者と共有できる“全体視点と伝える力”を持っています。

この力は一朝一夕では身につきませんが、日々の仕事の中で少しずつ鍛えることができます。構築の経験を土台に、あなたも「設計ができるエンジニア」への一歩を踏み出しましょう。

🔸 1-3. なぜ設計スキルが市場価値を高めるのか？

「設計ができるようになりたい」と考える方は多いですが、それがなぜ市場価値に直結するのか？について明確に理解している方は意外と少ないかもしれません。

設計スキルが評価されるのは、それが単なる“技術力”にとどまらず、プロジェクトの中核を担うスキルだからです。ここでは、設計力がなぜエンジニアとしての市場価値を高めるのか、3つの観点から詳しく解説します。

💼 ① 設計は「上流工程」だから報酬・評価が高い

設計フェーズは、プロジェクトの初期段階であり、システム全体の品質・コスト・運用性を左右する超重要フェーズです。

要件を整理し、システム全体の構成を決める
技術選定を行い、将来性と安定性を両立させる
設計内容をもとに、構築・運用が進む

つまり、設計の良し悪しが、その後のすべての作業効率に直結します。だからこそ、企業は設計ができる人材を高く評価し、上流工程に関わる人ほど年収も高くなる傾向があります。

📝 実際、求人サイトを見ると「設計経験必須」「要件定義～設計ができる方歓迎」といった文言が多く見られます。

🧩 ② 設計スキルは「構築・運用・改善」を統合する力

設計力を持つということは、単にサーバーを作るだけではなく、運用・監視・セキュリティ・保守までを一貫して考えられる力があるということです。

たとえば──

スキル	枠にとどまると…	設計力があると…
構築	指示通りに作るだけ	最適な構成を自ら提案できる
運用	障害が起きたら対応	障害が起きにくい設計ができる
改善	作業効率を上げる	システム全体のボトルネックを見直せる

つまり設計スキルは、これまでの経験を「価値ある知的成果」に変換する力なのです。

🌐 ③ 転職市場で明確な“差別化ポイント”になる

現代のインフラエンジニア市場では、以下のような人材が多くいます：

構築はできるけど、設計は未経験
運用保守の経験が長いが、自ら提案した経験がない
指示通りに動くのは得意だが、仕組み全体を考えるのは苦手

そんな中で、「設計経験があります」「設計ドキュメントを作成しています」と言える人材は、一歩も二歩もリードできます。

特に以下のようなアピールができると強いです：

システム構成図をもとに、技術選定の理由を説明できる
運用設計（監視・バックアップ）も含めてドキュメント化している
チームでのレビューを前提にした設計を行っている

📌 こうした経験は、履歴書や面接、ポートフォリオでの強力なアピール材料となります。

🎯 設計スキルは「希少で、応用が利き、報酬も高い」

エンジニアとしての市場価値を高めるには、以下の3つの条件がカギになります：

希少性：誰にでもできる作業ではない
応用性：幅広いプロジェクトや環境に通用する
報酬性：評価や単価に直結する

設計スキルは、これらをすべて満たす「キャリアのブースター」です。

あなたが今、構築作業や運用経験を積んでいるなら、それはすべて設計力を高める“素材”になります。
その素材をどう活かし、どう見せていくか――それこそが、市場価値を高めるエンジニアとしての道です。

🔸 1-4. この先のステップで身につける力とは？

設計ができるエンジニアになるためには、いきなり高度な設計書を書けるようになる必要はありません。むしろ、今の業務を通じて少しずつ“設計的な視点”を鍛えていくことが、もっとも確実で、効果的な方法です。

ここでは、これから身につけていくべき具体的な力を4つのステップに分けて解説します。

🧠 ① 「構築」と「設計」の違いを理解する力

まず最初に必要なのは、「構築作業」と「設計業務」の違いを正しく理解することです。

構築：決められた通りに、正確に作ることが目的
設計：目的を達成するために、どう作るかを自ら考えるプロセス

この違いを理解して初めて、「自分がやっている作業の意味」「背景にある意図」への意識が芽生えます。

📌 構築作業をしているときに「なぜこの設定なのか？」と自問自答してみるだけで、設計者の視点が養われます。

📚 ② 設計に必要なスキルセットを段階的に習得する

設計と一言でいっても、必要なスキルは多岐にわたります。代表的なものは次の5つです。

要件整理スキル：何が求められているのかを正確に聞き出す力
構成設計スキル：最適なシステム構成を考える力
運用設計スキル：監視・バックアップ・保守性を含めて設計する力
セキュリティ設計スキル：リスクを想定して守りを固める力
ドキュメント作成スキル：設計の意図や全体像を伝える力

いきなりすべてを身につけようとするのではなく、今の業務に近い部分から少しずつ広げていくことがポイントです。

🔍 ③ 実務の中で「設計思考」を意識する

設計スキルは、実際に業務を通じて磨かれるものです。特別な勉強時間を取らなくても、日々の業務の中で以下のような問いを持つだけで効果的なトレーニングになります。

この構成にした理由は何だろう？
自分だったら、どう構成したか？
障害が起きた場合、この設計で復旧は速いか？
後任が見たときにわかりやすい構成になっているか？

🧩 思考を「目の前の作業」から「全体像」「先の運用」へと広げることが、設計力の土台を築きます。

📝 ④ 設計経験を“見える形”でアウトプットする

最後に重要なのは、設計に関する気づきや経験を「見える形」に残すことです。

サーバー構成図を簡単に描いてみる
自分なりの設計ポイントや工夫をメモに残す
先輩の設計書を読み、自分なりに再構成してみる
設計事例をまとめた「ミニ設計ノート」を作る

アウトプットは、自分の思考を整理するだけでなく、他者と共有してフィードバックを受ける機会にもなります。
それがさらなる成長につながります。

🚀 小さな視点の変化が、設計力の始まり

「設計ができるようになる」ことは、特別な人だけに与えられたスキルではありません。
日々の構築や運用の中で、「なぜ？」「どうすればもっと良くなる？」という問いを持つこと。
そこからすべてが始まります。

焦らず、しかし確実に、設計思考を少しずつ日常に取り入れていくことが、3年後の市場価値を大きく変えてくれるのです。

🔹 ２．「構築」と「設計」の違いを理解する

構築作業に慣れてくると、「設計もできるようになりたい」と思う方が増えてきます。しかし、構築と設計は似ているようでまったく別のスキルです。構築は決められた仕様に沿ってシステムを形にする作業ですが、設計はその仕様自体を考える工程です。この章では、両者の役割の違いや、設計に求められる視点の変化について解説します。設計力を身につける第一歩は、「何が違うのか？」を正しく理解することから始まります。

🔸 2-1. 「構築」とは何か？

サーバーエンジニアとして最初に携わる機会が多いのが、「構築」と呼ばれる作業です。構築とは、簡単に言えばシステムやサーバーの土台を形にする工程です。

ただし、構築作業は単なる“設定作業”ではなく、チームの一員として重要な役割を果たすステップでもあります。この章では、構築の意味・役割・やりがい、そして限界について詳しく解説します。

🖥️ 構築とは「形にする」仕事

構築は、あらかじめ決められた設計や要件に従って、サーバーやネットワーク、アプリケーションの環境を実際に動く状態にする作業です。

📌 具体的には以下のような内容が含まれます：

OSのインストールと初期設定
サーバーの役割（Webサーバー、DBサーバーなど）の割り当て
必要なパッケージのインストールと設定ファイルの調整
ファイアウォールやポートの設定
ネットワーク構成（IPアドレス、ルーティングなど）の設定
ユーザー・権限・ログ管理の初期設定

つまり、設計図をもとに実際のサーバーやシステムを「組み上げる」プロセスです。

🧑‍🔧 構築は“職人技”でもある

構築は一見するとマニュアル通りの作業に見えますが、現場ではそう簡単ではありません。

手順通りに進めても、環境差異や予期せぬエラーで止まることがある
バージョンの違いや依存関係により、微調整が必要になる
チームで作業する場合、進捗や影響範囲を考慮した段取りが求められる

このように、構築には実践的な判断力・対応力・段取り力が求められます。
特にオンプレミス環境では、物理サーバーやストレージの扱いも含まれるため、現地作業や機材対応の経験も大きな学びになります。

🧩 構築は「チームの信頼」を得る第一歩

新卒エンジニアにとって構築作業は、技術的スキルだけでなく、チームとの信頼関係を築く重要なフェーズでもあります。

指示通りに正確に構築できる
作業記録をきちんと残す
トラブル発生時に相談・報告ができる

こうした「基本を守れる人」は、チームの中で信頼され、「あの人に任せれば安心」と思われるようになります。これは、今後設計や改善といった上流工程に進むための土台になります。

⚠️ ただし、「構築だけ」では市場価値は上がらない

構築作業は重要ですが、それだけではキャリアの幅は広がりにくくなります。なぜなら──

手順さえ覚えれば他の人でもできる＝代替可能性が高い
自分の判断や工夫を入れる余地が少ない＝スキルの差が見えにくい
作業の目的や背景を理解せずに実行する人も多い＝思考力が鍛えられない

つまり、構築作業そのものには価値がある一方で、それを「どう捉えるか」「どう活かすか」が市場価値を左右するということです。

🧠 構築作業を“設計の視点”で見直すと成長が加速する

同じ構築作業でも、以下のように設計的な視点を持って行うと、成長スピードが格段に上がります。

なぜこの構成を選んだのか？
他に選択肢はあったのか？
運用・監視・保守のしやすさは考慮されているか？

📝 このような問いを持ちながら作業することで、単なる“作業者”から“考えるエンジニア”へとシフトできます。

🚀 構築はスタートライン、設計への入り口

構築とは、サーバーやシステムの“形”を作る重要な工程です。
確実に構築できるようになることは、サーバーエンジニアとしての第一歩であり、チーム内で信頼を得るための基礎でもあります。

しかし、そこにとどまらず、構築作業を通じて「なぜこの構成か？」「もっと良い形はないか？」と考えることで、設計力への道が開けてきます。

構築を単なる作業で終わらせず、“学びのフィールド”として捉えることが、あなたの市場価値を大きく育てる第一歩なのです。

🔸 2-2. 「設計」とは何か？

構築が「作ること」だとすれば、設計とは「どう作るかを決めること」です。もっと正確に言えば、設計は「目的を達成するために、最適な構成・仕組みを考えること」とも言えます。

サーバーやシステムの構築に着手する前に、「何のために」「どんな構成で」「どう運用されるか」を考え、仕組みに落とし込む――これが設計の本質です。

🧩 設計は“仕組みづくり”そのもの

設計の役割は、単なる技術的な仕様書づくりではありません。設計とは、「仕組みそのものを考える仕事」です。

例えるなら、建物の設計士が、

建物の用途（住宅？病院？）
必要な部屋数や動線
地盤や周囲の環境
将来の拡張性や耐震性

を考慮して、図面を描くように、

サーバーエンジニアの設計も、

システムの目的や使い方
想定されるユーザー数や負荷
運用・監視・障害対応のしやすさ
将来的な拡張や変更への対応

などを見越して、最適な構成を考える仕事なのです。

🧭 設計は“判断”と“責任”の連続

設計では「こうしたい」ではなく、「こうするべき」という判断が求められます。

たとえば：

台数を増やして可用性を上げるか、台数を減らしてコストを抑えるか
ミドルウェアは枯れたバージョンを使うか、新機能の多い最新版にするか
冗長構成を組むか、手動対応を前提にして単純化するか

これらはすべて「正解が1つではない」判断です。だからこそ、設計には論理性と責任感が求められます。
「なぜこの構成にしたのか？」に明確な根拠を持てることが、設計者としての信頼につながります。

🔄 設計は“現場に還元される”仕事

設計の影響は、構築だけでなく、その後の運用・保守・改善活動にまで及びます。

✅ 監視しやすい構成なら、障害対応が速くなる
✅ シンプルで統一された構成なら、引き継ぎやすい
✅ 拡張性があれば、新しいサービスへの対応がスムーズになる

逆に設計が甘いと…

⚠️ ログが肥大化し、運用でディスクが逼迫
⚠️ バックアップ対象が曖昧で、復旧できない状況に
⚠️ ドキュメントがなく、他のメンバーが構成を理解できない

というように、「設計の質」が現場の苦労に直結します。

👥 設計は“チームで使える知識”にすることでもある

設計とは、自分だけが理解している“個人の知識”ではなく、チーム全体が活用できる“共有知”にする作業でもあります。

設計ドキュメントを通じて、他のメンバーが構成の全体像を理解できる
後から入ったメンバーが、システムの背景を知ることができる
レビューを通して、設計方針の妥当性を確認・改善できる

このように、設計はチームで働くための“共通言語”を作る作業でもあります。伝える力も、設計の一部です。

💡 構築経験が“設計力の素材”になる

「設計なんて自分にはまだ無理かも…」と感じる方も多いかもしれませんが、安心してください。
実は、構築や運用の経験こそが、設計力を育てる最良の土台になります。

なぜなら、実際に構築して手を動かした人ほど、

どこでつまずきやすいか
どんな構成が運用しづらいか
どうすればミスが減るか

といった、“リアルな気づき”を持っているからです。
設計とは、こうした現場の学びを“先回りして活かす”仕事でもあります。

🏁 設計とは、「目的から逆算して最適を描く力」

設計は、システムの目的・運用・制約・将来を見据えて、最も合理的な構成を導き出す「思考力」と「判断力」の集大成です。
それは単なる図面作成でも、手順の調整でもありません。

設計とは、「なぜその構成にするのか？」を論理的に考え抜き、それをチームに伝えることのできる力」です。

あなたが構築で学んだ経験も、障害対応で得た教訓も、すべてが設計に生きてきます。
だからこそ、設計を「特別な誰かの仕事」と思わず、次の自分が挑戦すべき領域として、少しずつ意識を向けていきましょう。

🔸 2-3. 「構築」と「設計」の視点の違い

「構築ができれば、設計もすぐできるのでは？」と考える人は少なくありません。
しかし実際には、構築と設計は“見ている景色”がまったく異なると言っても過言ではありません。

ここでは、両者の違いを具体的な比較と実務例を交えながら、体系的に解説していきます。

🧭 「構築」と「設計」の定義を再確認

項目	構築	設計
定義	決められた仕様を形にする作業	要件に対して最適な構成を考えるプロセス
主な目的	正しく・安全に構築を完了させる	長期的に使いやすく・管理しやすい仕組みを作る
始点	設計書や仕様書があることが前提	要件や目的があるだけで“答え”は自分で導く
視点	作業対象に集中（部分視点）	システム全体や将来まで見据える（全体視点）

🔧 思考の違い – 「手順に従う」vs「自分で判断する」

構築の視点：

「何をすればいいか」は決まっている
ゴールは「仕様通りに構築を完了させること」
ミスをせず、手順通りに丁寧に進める力が求められる

設計の視点：

「どうするか？」をゼロから考える必要がある
ゴールは「課題を解決する最適な構成を作ること」
前提条件や制約の中で判断と説明ができる力が求められる

📌 つまり、構築は“正解に近づく力”、設計は“正解を創り出す力”です。

🏗️ 実務レベルでの違い – 同じ作業でも視点が違う

以下は、同じテーマに取り組んでも、構築と設計で視点がどう変わるかを示す例です：

テーマ	構築視点	設計視点
ログ保存	指定されたパスに出力する設定をする	長期保存に耐えられるディスク構成か？ログローテーションは？
サーバー構成	決められた台数・役割で構築する	可用性・負荷分散・コストのバランスを考えて台数・構成を決定する
監視設定	指示された監視項目をZabbixに登録する	どの項目を監視すべきか？閾値は？通知先は？の全体設計を考える
セキュリティ	指定されたIP制限やACLを設定する	脅威モデルに基づいたアクセス制御の設計。例：最小権限で運用可能か？

🌐 視野の違い – 見ている範囲が違うから責任も違う

構築作業の視野：

目の前の1台のサーバー、特定の設定ファイルに集中
いかに正確に、効率よく作業できるかが重視される

設計作業の視野：

サーバー間の連携、業務フロー、ユーザーの使い方、障害時対応まで見通す
「その構成にした理由」や「他の選択肢との比較」まで含めて語れる必要がある

📣 設計者は“全体の交通整理”ができる存在とも言えます。

📈 キャリアにおける価値の違い

項目	構築だけの人	設計までできる人
市場価値	再現性が高く、代替されやすい	応用力・提案力が評価され、希少性が高い
任される範囲	手元の作業・構築工程のみ	要件定義・構成検討・改善提案まで幅広い
単価・年収	一定止まり	高単価の案件やリーダーポジションが狙える
キャリア選択	作業者どまりになりやすい	上流・マネジメント・アーキテクトに進みやすい

🏁 「構築」と「設計」は見ている景色が違う

構築とは、決められた仕様に従って「形にする力」。
設計とは、課題や目的に応じて「形を考える力」です。

どちらが上ということではなく、構築のスキルがあるからこそ、設計の質も上がります。
しかし、市場価値の観点で見ると、設計の視点を持つことで一気に差別化が進むのも事実です。

明日からは、構築作業をただの“設定作業”で終わらせず、
「なぜこの設定なんだろう？」「自分ならどう設計するだろう？」と考える時間を少しだけ持ってみてください。
それが、設計者への第一歩になります。

🔸 2-4. 実務での具体例（ミニケーススタディ）

構築と設計の違いを理解するうえで、最も効果的なのは実際の現場に近い具体例をもとに考えることです。
ここでは、よくあるインフラ業務を題材に、構築と設計でどんな視点の違いが生まれるのかをケーススタディ形式でご紹介します。

✅ ケース①：ログ保存先の設定

🧑‍💻 構築視点：

手順書に従い、アプリケーションログを/var/log/app/に出力
ログローテーションはOSの標準設定を使用
保存期間や容量制限には特に意識を向けない

🧠 設計視点：

ログの重要性や参照頻度を確認し、保管ポリシーを設計
　例：「セキュリティ監査用ログは6か月保管」「アプリログは14日で削除」など
/var領域が肥大化しないよう、別ディスクマウント（例：/log/）を検討
ログローテーションの設定（サイズ/日数）と圧縮形式を調整
障害調査時に役立つログが残るよう、出力内容の粒度や構造も考慮

📌 ポイント： ログは「ただ出す」ものではなく、「後で活用できる状態で残す」ことが重要です。

✅ ケース②：サーバーの台数と構成の決定

🧑‍💻 構築視点：

要件に「Webサーバー×2、DBサーバー×1」とあるので、指示どおりにセットアップ
サーバー名の命名ルールや配置は、例に倣って設定

🧠 設計視点：

同時接続数・ピーク時負荷をもとに台数を算出（スケーラビリティ）
WebとDBの役割分離、通信経路（DMZ配置など）を設計
冗長化構成（LB配下のWeb×2、マスター・スレーブのDB）を検討
監視・バックアップ設計と合わせて構成に反映
将来的な拡張（例：APサーバー追加）を想定したIPアドレス設計やホスト命名

📌 ポイント： 台数は「与えられた数」ではなく、「目的達成に最適な数」を考える視点が設計です。

✅ ケース③：監視項目の設定

🧑‍💻 構築視点：

指定された監視ツール（Zabbix）を導入
監視テンプレートを適用して、CPU・メモリ・ディスク使用率を監視設定
通知先のメールアドレスを登録して完了

🧠 設計視点：

業務サービスにおいて「何が止まるとクリティカルか？」をヒアリング
監視すべき項目（プロセス死活、ログ出力停止、応答時間など）を洗い出し
アラートの閾値を**「通常時の挙動」や「障害履歴」から設計**
アラート通知先の優先順位・エスカレーション設計
誤検知やアラート疲れを防ぐためのチューニング

📌 ポイント： 監視は「数値を取ること」ではなく、「早く異常を察知し、動ける状態にすること」が目的です。

✅ ケース④：ユーザー権限の設定

🧑‍💻 構築視点：

ユーザー一覧に従い、必要なアカウントを追加
sudo設定やグループ追加なども指示どおりに実施
公開鍵は配布されたものをコピーして設置

🧠 設計視点：

最小権限での運用を前提に、ユーザー権限のポリシーを設計（例：管理者権限は限定、作業権限は用途別グループ化）
操作ログの取得範囲や保存期間を要件化
退職時や異動時のアカウント棚卸しのしやすさを考慮した命名ルール
自動化ツール（Ansibleなど）によるユーザー管理の整備も含めて検討

📌 ポイント： 「作業できるようにする」だけでなく、「安全に・確実に・継続的に管理できる状態」にするのが設計の視点です。

🏁 構築と設計の違いは“思考の深さと広さ”にある

構築と設計では、やっている作業そのものは似ていても、考えている内容の“層”がまったく違います。

視点の違い	構築	設計
作業内容	指示通りに設定・導入	最適な構成とルールを自ら考える
主な目的	正確な環境の構築	安定運用と将来を見据えた全体設計
思考範囲	単体の作業対象	システム全体・運用・チーム・将来

ぜひ、日々の構築作業を「作業だけで終わらせない」視点で捉えてみてください。
「もし自分がこの構成を決める立場だったら？」と問いを立てることが、設計者への第一歩になります。

🔸 2-5. なぜ違いを意識することが成長につながるのか？

構築と設計は「似ているようでまったく異なる役割」です。
しかし現場では、この2つの違いを意識しないまま日々の作業に取り組んでいるエンジニアが少なくありません。

この違いを早くから意識できる人ほど、吸収力と成長スピードが飛躍的に高まります。
では、なぜその“意識の差”がエンジニアとしての成長に直結するのでしょうか？
その理由を、4つの視点から深掘りしていきます。

🧠 1. 「作業」を「学び」に変えることができるから

構築作業は、言ってしまえば「手順通りにこなすだけ」の作業になりがちです。
しかし、設計視点を持つことで、同じ構築でも“なぜそうなっているのか”を考える学びの時間に変わります。

たとえば：

「なぜこのディレクトリ構成にしたのか？」
「なぜWebサーバーを2台構成にしたのか？」
「この設定は将来の運用にどう影響するのか？」

こうした問いを立てながら作業することで、設計者の思考プロセスを自然と追体験できるようになります。

📌 「ただ作業した」ではなく、「理由まで理解した」は、大きな差を生みます。

🔭 2. 将来のキャリアの“選択肢”が増えるから

構築スキルだけでは、どうしてもキャリアの選択肢が狭まります。
一方で、設計の視点を持ち始めると、以下のような“次のステージ”が視野に入ります。

要件定義を担うインフラリーダー
設計レビューができる信頼されるエンジニア
SREやアーキテクトなど、全体最適を考える職種へのステップアップ

つまり、構築と設計の違いを理解し、設計力を高めていくことは、自分のキャリアを広げるための“鍵”になるのです。

🧩 3. 他者との仕事の“質”が変わるから

設計視点を持つことで、チーム内での発言力や信頼度も大きく変わってきます。

作業の背景まで理解して行動できる
上流工程での議論にも参加できる
「なぜこの設定なのか？」と問われたときに、自信を持って答えられる

これは、「ただ動くものを作る人」から「納得して任せられる人」へと変わる瞬間です。
設計を理解している人は、周囲との連携もスムーズになり、結果的に仕事全体の質が上がります。

🚀 4. 自分で考え、判断し、提案できる力がつくから

設計の視点を持つということは、「考える習慣を持つ」ことでもあります。

設定の意味を考える
他の選択肢を検討する
問題が起きたときに、根本から見直す視点を持てる

こうした姿勢が身につくと、単なる“実行者”ではなく、改善提案や仕組みづくりができるエンジニアへと成長していきます。

📌 「任された作業をやる人」から「仕組み全体を考える人」へ――設計視点を持つだけで、役割が変わっていきます。

🏁 視点が変わると、成長のスピードが変わる

構築と設計の違いを意識することは、単なる“知識の話”ではありません。
それは、あなた自身の“考え方”をアップグレードするきっかけです。

日々の構築作業をただの作業で終わらせず、「なぜ？」「どうしてこの構成？」と問い続けることで、
あなたの技術は“知識”から“判断力”へと進化していきます。

そしてそれは、市場価値を高める“エンジニアとしての本質的な成長”につながっていくのです。
小さな視点の変化が、未来を大きく変えます。

🔹 ３．「設計ができるエンジニア」に必要なスキルセット

設計ができるエンジニアになるためには、単なる技術知識だけでなく、さまざまな視点やスキルが求められます。特に、要件の整理や構成の工夫、将来の運用やセキュリティを見越した判断力は、設計に欠かせない要素です。この章では、設計スキルを段階的に身につけるために必要な5つのスキルセットを紹介します。これらを意識することで、ただ作るだけのエンジニアから、信頼される設計者へと一歩近づくことができます。

🔸 3-1. 全体像をつかむ – 設計スキルは5つの柱で構成される

「設計ができるようになりたい」と思っても、設計という言葉は漠然としていて、「何から学べばいいかわからない」という人は少なくありません。

そこで大切なのが、設計スキルを構成する要素を“分解して理解”することです。

実は、設計スキルは次の5つの柱から成り立っています。
この5つの視点を意識することで、自分に足りないスキルや伸ばすべき力が明確になり、効率的に設計者としての力を育てていくことができます。

🧱 設計スキルの5つの柱とは？

要件整理スキル
構成設計スキル
運用設計スキル
セキュリティ設計スキル
ドキュメント作成スキル

それぞれの概要と、なぜ必要なのかを順に見ていきましょう。

📝 ① 要件整理スキル：設計のスタート地点を定める力

設計は、技術的な構成を考える前に「何を求められているか」を正しく理解することから始まります。

サーバーは誰が使うのか？（社内？外部顧客？）
どんなサービスを支えるのか？（Webアプリ？ファイル共有？）
パフォーマンスやセキュリティ、保守性への要望は？

🧠 ここを曖昧にしたまま設計を始めると、間違った方向に進んでしまう可能性が高くなります。

📌 POINT：「聞いたことをそのまま受け取る」のではなく、「なぜそれが必要なのか？」まで掘り下げて整理する力が求められます。

🖥 ② 構成設計スキル：システムの骨組みを描く力

構成設計では、要件に基づいてどんなサーバーを何台・どう配置するかを決めます。

Web、AP、DBなどの役割分担
台数、冗長構成、可用性の確保
ネットワーク設計やゾーニング（DMZ、内部ネットワーク）

設計者は、サービス全体を見通しながら最小限の構成で最大限の効果を発揮できる構成を考える必要があります。

📌 POINT： 単に「動く構成」ではなく、「運用しやすく、障害にも強く、コストバランスも取れた構成」にすることが設計者の腕の見せ所です。

🛠 ③ 運用設計スキル：使い続けることを見越した仕組みづくり

設計時には、構築後の運用・保守・障害対応のしやすさも考慮する必要があります。

どんな監視項目が必要か？（死活監視、リソース監視、アプリ監視など）
ログの出力先・保存期間・ローテーション設定はどうするか？
バックアップの対象と頻度、リストア手順の整備は？

🧠 構築時に「とりあえず動く」ではなく、「障害が起きたときにどうなるか？復旧できるか？」を想像する力が必要です。

📌 POINT： 実際に運用を担当する人の視点に立って設計できるかが、真の設計者の条件です。

🔐 ④ セキュリティ設計スキル：守るべきものを守る仕組みづくり

インフラ設計には必ず「どう守るか？」という視点が必要です。

誰がどのサーバーにアクセスできるか？（IP制限・ACL）
最小権限の原則は守れているか？（sudo・ユーザー権限の整理）
通信の暗号化や、ログの改ざん防止などの仕組みはあるか？

🧠 セキュリティは後回しにされがちですが、設計段階で考えておくことで、あとから大きなトラブルを未然に防ぐことができます。

📌 POINT： セキュリティ要件は「過剰でも不足でもNG」。目的とリスクに応じて適切な対策を選ぶ判断力が大切です。

📄 ⑤ ドキュメント作成スキル：チームで使える設計を残す力

設計ができる人と、「設計書が書ける人」は別物です。
どれだけ優れた設計も、他人に伝わらなければ存在しないのと同じです。

サーバー構成図
通信フローや冗長構成の概要
運用設計・セキュリティ設計のポイント
設計意図と判断理由（Why？）の記録

📌 POINT： シンプルで見やすく、他のエンジニアが読み解ける資料にする力は、設計の一部として非常に重要です。

🎯 設計は「5つの柱」を意識することで、実践力が身につく

設計スキルは、「経験が豊富な人だけのもの」ではありません。
5つの柱で捉えれば、今の自分に何が足りていて、何を意識して伸ばすべきかがはっきり見えてきます。

スキルの柱	初心者でもできるアクション例
要件整理	作業前に「誰が何のために使うか？」をメモする
構成設計	構築中に構成図を自分で描いてみる
運用設計	障害発生時に「監視設計に抜けがなかったか？」を振り返る
セキュリティ設計	sudoやログ管理をレビューしてみる
ドキュメント作成	先輩の設計書を真似してまとめてみる

この5つの柱を意識して、日々の業務に設計視点を取り入れていきましょう。
それが、3年後に「設計ができるエンジニア」として信頼される力をつくります。

🔸 3-2. ① 要件整理スキル 📝

設計の出発点は、「何を作るか」ではなく、「なぜ作るのか？」を正しく理解することです。
これを明確にするために必要なのが、要件整理スキルです。

サーバーをどんな構成にするか、どのミドルウェアを使うかといった“技術的な判断”は、すべて要件があってこそ成り立つものです。
要件整理が甘いと、どれだけ高性能な構成を組んでも「ズレた設計」になってしまいます。

🧭 要件整理とは「本当に必要なもの」を見極めること

要件整理とは、単に依頼内容を聞くことではありません。
その裏にある利用者の意図・目的・優先順位を読み解く力が求められます。

たとえば、こんなやりとりがあったとします：

利用者：「とにかく速いサーバーがほしいんです」
エンジニア（NGな対応）：「わかりました！SSD構成にしてCPUも最上位にします！」

これは一見よさそうですが、要件整理ができていません。

実際に深掘りしてみると…

利用者：「月に1回しか使わないバッチ処理なんです。5分以内に終われば大丈夫です。」

→ つまり、本当に必要だったのは「高速な性能」ではなく「一定の応答速度とコストパフォーマンス」だったのです。

📌 POINT： 「聞いたこと」をそのまま鵜呑みにせず、「なぜそれが必要なのか？」を掘り下げて整理するのが要件整理の本質です。

🧠 要件整理に必要な3つの視点

① 目的の明確化（Why）

そのシステムやサーバーは、何のために使うのか？
業務上どんな課題を解決したいのか？
成果はどう測るのか？（KPIがあるか）

② 条件の整理（What / How）

利用者は誰か？（部門・人数・スキルレベル）
同時アクセス数や処理内容は？（負荷の見積もり）
セキュリティ要件、運用体制、運用時間帯は？

③ 制約の把握（Limit）

予算やスケジュールの制限はあるか？
既存システムとの連携要件は？
利用できる機材やサービスの制限は？

📝 この3つの視点を意識することで、要件を“設計に落とし込める形”に整えることができます。

💬 ヒアリングのコツ：具体的な言葉を引き出す力

要件整理でよくある落とし穴が、「あいまいな表現をそのまま受け取ってしまう」ことです。

よくある曖昧な要望	掘り下げて聞くべき質問
安定した構成でお願いします	どの程度の可用性が必要ですか？年◯回までの停止でOKですか？
セキュリティを強化したいです	どのような脅威を想定していますか？内部・外部どちらを重視しますか？
管理しやすい構成がいいです	誰が、どの頻度で、どのように管理しますか？ツールの有無は？

📌 POINT： 技術者側の常識と、利用者側のイメージにはギャップがあることが多いため、“共通言語”をつくるための対話力が重要です。

🧩 要件整理が設計に与える影響とは？

要件整理がしっかりできていると、設計はブレなくなります。

要件整理ができていない場合	よくある失敗例
「何となく必要そう」で構成を決める	オーバースペックになりコストが増大
利用者の本音を聞き出せていない	運用しにくい構成で手戻りが発生
条件・制約を見落とす	導入直前で非対応が発覚し、再設計に

逆に、しっかりと要件を整理できていれば、

✅ 構成の根拠が明確になる
✅ 利用者に「なぜこの設計なのか」を説明できる
✅ 将来的な拡張・改善のベースにもなる

という、長期的に価値を生む設計が実現します。

🚀 要件整理は設計の“スタートライン”であり“成功の鍵”

設計は、「形を決める」ことではなく、「目的を実現するための手段を考えること」です。
そのためには、要件整理という“地ならし”が欠かせません。

表面的な要望だけでなく、その背景にある「真のニーズ」を聞き出す
あいまいな言葉は具体的な条件に置き換える
「なぜ必要か？」を常に問いながら、設計の根拠をつくる

こうした姿勢が身につけば、あなたは単なる構築者ではなく、相手の課題を技術で解決する“設計者”として信頼される存在になります。

まずは、自分の関わっている業務で「なぜこの構成なのか？」をひとつずつ掘り下げるところから、始めてみましょう。

🔸 3-3. ② 構成設計スキル 🖥

構成設計スキルとは、システムをどのような構成で組み立てるかを決める力のことです。
これは設計スキルの中でも最も中心的な役割を持ち、技術選定や運用方針、性能・拡張性・コストに大きな影響を与えます。

構成設計がしっかりしていないと、どれだけ性能の良い機材やツールを使っても、「運用しづらい」「障害に弱い」「変更に対応できない」などの問題が発生します。

🧩 構成設計の基本とは？

構成設計とは、以下のような要素を整理し、最適な組み合わせを考えるプロセスです。

要素	検討ポイントの一例
サーバーの台数	冗長化は必要？1台で十分？スケールは縦？横？
役割分担	Web / AP / DBの分離 or 統合？
通信構成	FW / LB / NATなどのネットワーク設計は？
ストレージ	ローカル or NFS or SAN？I/O性能は足りるか？
可用性	HA構成を取る？シングルポイントは？
拡張性	将来的にどこまで拡張を想定するか？
コスト	ハード・ソフト・人的コストのバランスは？

🧠 つまり、構成設計は「組み合わせの設計」かつ「バランスの設計」なのです。

⚖️ 構成設計で意識すべき3つのバランス感覚

構成設計を考える上で重要なのが、「最強の構成」ではなく「ちょうどいい構成」を導くことです。そのためには、以下の3つのバランスをとる力が求められます。

🛡️ ① 可用性とコストのバランス

例：可用性を高めたい → Webサーバーを冗長化（2台＋LB）
でも台数が増えればサーバー費・運用費・監視費も増える

📌 「落ちない仕組み」をどこまで求めるかは、システムの重要度と予算のトレードオフです。

🚀 ② 性能と運用性のバランス

高性能な構成（DB分散、キャッシュ導入）にしても、運用が複雑になると維持が難しくなる
拡張しやすいが運用コストが高い vs 運用が簡単だが限界が早い構成

📌 性能を追いすぎて複雑になりすぎると、日常運用で障害対応が困難になります。

🔧 ③ シンプルさと柔軟性のバランス

小さく始めてあとから拡張する設計（スケールアウト前提）
逆に最初から余裕をもって冗長化しておく設計

📌 「あとから変えられるか？」を常に意識しておくことが構成設計の鍵です。

📊 構成図が描ける＝考えを“形にできる”力

構成設計スキルがあるかどうかは、「構成図を描けるかどうか」で判断されることが多いです。
構成図は、設計者の思考をチームに共有するための必須ツールです。

サーバー・NW機器・ストレージの関係性を可視化
役割・冗長構成・通信の流れを一目で理解できる
設計レビューや障害対応のときに意思疎通を助ける

📌 POINT： 構成図を描くクセをつけると、設計力とドキュメント力が一気に伸びます。

💡 新卒でも構成設計を学ぶ方法

構成設計は、現場での経験がある人でなければできない…そんなイメージを持っていませんか？
実は、小さなところから設計練習は始められます。

✅ 自分が触っているサーバーの構成図を自作してみる
✅ 実案件で使われている構成図を見て、理由を想像する
✅ 「この構成にしている理由は？」と先輩に質問してみる
✅ 自分だったらどう構成するか？を仮想で考えてみる

📌 小さなサーバー1台でも、構成設計の視点で見ることで成長につながります。

🏁 構成設計は「全体を見てバランスを整える力」

構成設計スキルは、設計者として最も問われる中核スキルです。
単に技術を知っているだけではなく、「何のために」「誰のために」「どのように」構成するかを考える力が問われます。

動くだけの構成ではなく、「運用され続ける構成」へ
最強よりも「ちょうどいい構成」へ
バラバラの技術を「最適な組み合わせ」に変える力を育てましょう

構成図を描くことから、今日からでも一歩踏み出せます。
あなたの頭の中の“構成のイメージ”を、チームと共有できるスキルへ。
それが構成設計スキルの第一歩です。

🔸 3-4. ③ 運用設計スキル 🛠

システムは「構築して終わり」ではありません。
本当に重要なのは、そのシステムが継続的に安定して使われ続けることです。

つまり、設計者として求められるのは、「運用する人の立場になって考えられる力」です。
それが、設計スキルの中核である運用設計スキルです。

🧠 運用設計とは？

運用設計とは、「そのシステムをどうやって運用・監視・保守していくか」をあらかじめ仕組みとして設計することです。
運用設計の出来不出来は、運用開始後の負担、トラブル対応の速さ、引き継ぎのしやすさに直結します。

🔍 構築視点との違い：

視点	構築	運用設計
目的	動かす	安定して動かし続ける
スコープ	今この瞬間の構成	将来の変化や障害まで含めて考える
重視点	完成させる	維持できる・直せる・改善できる

📌 POINT：「今動いている」より、「壊れたときどうするか？」を考えるのが運用設計です。

🧩 運用設計で考えるべき5つの要素

① 監視設計：異常を“気づける”構成か？

どんな項目を監視するか（CPU, メモリ, ディスク, 死活監視, アプリ監視）
どのような閾値でアラートを出すか
誰に・どの方法で通知するか（メール／Slack／PagerDutyなど）
誤検知や過検知をどう防ぐか

🧠 「サービスが止まっているのに誰も気づいていない」という状態をなくすことが目的です。

② ログ設計：原因を“追える”構成か？

ログ出力の種類と粒度（アクセスログ／エラーログ／アプリログ）
ログの保存期間・保存先（容量を圧迫しないか？）
ログローテーションや圧縮の設定
ログの検索性（grepできる形式か、構造化されているか）

📌 POINT： トラブル時に「ログを見れば状況がわかる」状態を作るのが設計者の責任です。

③ バックアップ設計：戻せる“仕組み”になっているか？

どのデータを、どの頻度でバックアップするか（DB？設定ファイル？アプリ？）
世代管理（何日分／何世代保持？）
保存先（別ストレージ？オフサイト？）
リストア手順（簡単に戻せるか？定期的な検証は？）

📌 POINT： バックアップは「ある」だけでなく、「使えること」が大前提です。

④ 障害対応設計：トラブルに“備えている”か？

よくある障害に対して「即時対応できる構成」になっているか
冗長化の設計（シングルポイントを排除しているか）
初期対応マニュアルや連絡先の整備
障害を“設計段階”で潰せているか（予測と未然防止）

🧠 トラブルはゼロにできなくても、「起きたときの影響を最小化する設計」が可能です。

⑤ 保守性設計：人が“迷わず運用できる”構成か？

ディレクトリ構成や設定ファイルの配置にルールがあるか
命名規則（ホスト名、ログ名、スクリプト名）が整理されているか
作業手順がドキュメント化されているか
属人化していないか？チームで共有できているか？

📌 POINT： 「誰が見ても理解できる」「引き継ぎやすい」状態を意識するのが保守性設計です。

💡 運用設計スキルがあると何が変わるか？

Before（運用を意識しない設計）	After（運用設計されたシステム）
ログが膨らみすぎてディスクがパンク	ログローテートと監視で予防できている
バックアップはあるが復元に3時間	リストア手順が整備されており10分で復旧
監視アラートが頻繁に鳴り過ぎて疲弊	適切な閾値と通知先設計で静かに運用
初めて触る人がどこを見ればいいかわからない	ディレクトリとドキュメントが明確で迷わない

🧠 “実際に使われる未来”を想像して設計する人は、現場で圧倒的に信頼されます。

🚀 新卒から始められる運用設計のトレーニング法

✅ 障害が起きたら、「この障害は設計で防げたか？」と振り返る
✅ 構築時に「この設定でちゃんと気づける？復旧できる？」と自問する
✅ 自分の書いた構成に「ログ・監視・復旧・ドキュメント」の視点を1つ追加する
✅ 運用担当者に「どこが困ってるか？」を聞いてみる

📌 小さな設計改善提案を1つでもできると、そこから見える景色が変わっていきます。

🏁 運用設計は“未来の現場を救う設計”

運用設計スキルは、「使い続けられる仕組みを作る力」です。
華やかな技術ではありませんが、最も“現場に感謝されるスキル”であり、設計者としての信頼を生む土台になります。

構築できることは入口にすぎません。
そこから一歩踏み出して、「この構成、明日も来週も安心して使えるか？」と問い続けることが、設計者への道を開いてくれます。

そしてそれが、あなたの市場価値を高める“信頼の証”となるのです。

🔸 3-5. ④ セキュリティ設計スキル 🔐

「セキュリティは専門のチームがやるもの」と思っていませんか？
実はそれは大きな誤解です。

サーバーエンジニアも、設計段階から「守る仕組み」を考え、仕込んでおく責任があります。
セキュリティ設計スキルは、インフラエンジニアとしての信頼と市場価値を大きく左右する“必須スキル”です。

🔍 セキュリティ設計とは何をすること？

セキュリティ設計とは、システムにおける「守るべき対象」「考えられるリスク」「現実的な対策」を洗い出し、具体的な仕組みに落とし込む作業のことです。

単に「パスワードを強化する」「FWで制限をかける」だけではなく、「何を守るのか？なぜその方法か？」を考える視点が求められます。

🧭 セキュリティ設計における3つの基本原則

✅ ① 最小権限の原則（Least Privilege）

すべてのユーザーやプロセスに対して、「必要最小限の権限のみを与える」こと
例：rootではなく、特定の作業に限定された一般ユーザーで操作させる

✅ ② 境界の分離（Defense in Depth）

ネットワーク・アプリ・認証など、多層防御を意識した設計
例：外部からのアクセスはDMZに限定し、内部ネットワークには直接触れさせない

✅ ③ ログと可視化（Auditability）

すべてのアクセス・操作を記録し、後から追える状態にする
例：重要操作はログを残す／ログは改ざんされないよう保存する

📌 POINT： セキュリティ設計は「防ぐ」だけでなく、「見える化」することも重要です。

🔐 セキュリティ設計で見るべきポイント一覧

対象領域	チェックすべき視点	具体例
アカウント・認証	誰が・どうログインするか	SSH鍵運用、パスワードポリシー、二段階認証
ネットワーク	どこからアクセスを許可するか	IP制限、FWルール、VLAN分離、DMZ構成
OS・サービス	不要な機能を無効化できているか	使用していないポートやサービスは停止
アクセス権限	ファイル・ディレクトリの権限が適切か	`/etc/` や `/var/log/` のアクセス制御確認
ログ・監査	操作・アクセスの記録があるか	sudoログ、SSHログ、アプリログの整備と保存ポリシー
ソフトウェア更新	脆弱性のあるソフトが放置されていないか	yum/aptでの定期アップデート、EOLの確認

🛠 セキュリティ設計の例：シンプルなLinuxサーバーの場合

たとえば、1台のWebサーバーを設計する際でも、以下のようなセキュリティ設計が求められます：

対象	セキュリティ設計の例
SSHログイン	rootログイン禁止、公開鍵認証、特定IPからのみ許可
ファイアウォール	HTTP/HTTPSのみ開放、それ以外のポートは拒否
sudo設定	作業ユーザーは限定されたコマンドだけsudo許可
ログ監視	`/var/log/secure`やApacheログを日次でローテート＋保管
パッケージ管理	定期的に`yum update`を実施し、脆弱性パッチを適用

🧠 こうした“設計時点での仕込み”が、のちの安心感に直結します。

💡 「脅威ベース」で考えると設計の質が上がる

セキュリティ設計を磨くうえで有効なのが、「脅威ベースで考える」視点です。

脅威（Threat）：攻撃や事故の原因となるもの
資産（Asset）：守るべきデータ・システム・ユーザー
対策（Control）：リスクを抑えるための技術や運用

例）
脅威：「外部からSSHにブルートフォース攻撃がある」
→ 資産：管理者アカウント／サーバー本体
→ 対策：rootログイン禁止＋fail2ban導入＋公開鍵認証

📌 POINT： 「この構成で、何が攻撃されうるか？」と問い続けることで、設計力が深まります。

🧱 新卒が実践できるセキュリティ設計トレーニング

✅ SSHログインまわりの設定理由を言語化してみる
✅ 不要なサービス・ポートが開いていないかss -tulnで確認
✅ ログが残っているか・改ざんされていないかを定期確認
✅ 自分で構築したサーバーに「脅威シナリオ」を想定して対策を考える
✅ 先輩やセキュリティチームの設計書を見て学ぶ（+なぜそうしているかを考える）

🏁 セキュリティ設計は「守る力 × 想像力」

セキュリティ設計は、“技術力”だけではなく、想像力・危機意識・現実的な対応力が求められる領域です。

システムのどこが攻撃されやすいか？
誰が操作するか？どう悪用されるか？
トラブルが起きたとき、どうやって痕跡を追えるか？

これらを設計の段階から織り込めるエンジニアは、圧倒的に信頼されます。

セキュリティは“最後に付け加える”ものではなく、“最初から組み込む”もの。
設計時に「この構成は安全か？」と問い続けることで、あなたの設計は一段階上のレベルへと進化していきます。

🔸 3-6. ⑤ 設計ドキュメント作成スキル 📄

「設計ができる」とは、考えた構成を正しく“伝えられる”ということでもあります。
どれだけ優れた設計でも、それがチームに共有されず、運用や構築担当者に理解されなければ、
その設計は「存在しない」のと同じです。

そのため、設計スキルにおいて欠かせないのが「設計ドキュメント作成スキル」です。
これは単なる“書類作成”ではなく、設計者の思考を他者と共有するための橋渡しの力なのです。

🧠 設計ドキュメントとは何のためにあるのか？

設計ドキュメントの目的は、単なる記録ではなく、以下の3つです：

他のメンバーに設計意図を正しく伝える（構築・運用・レビュー担当者）
トラブル時や保守時の判断材料を提供する（過去の経緯を可視化）
自分の設計を“再現可能なノウハウ”として残す（学びと資産の蓄積）

📌 POINT： 設計は“個人の頭の中”ではなく、“チームで使える情報”にして初めて価値があるのです。

🧱 設計ドキュメントに求められる3つの条件

✅ ① 誰が読んでも理解できる

技術レベルの異なるメンバー（新人〜シニア）にも伝わる構成
“書いた本人しか理解できない”では意味がない

✅ ② 構成だけでなく「なぜそうしたか」が書かれている

例：「Webサーバーを2台にした理由 → 可用性確保＋分散目的」
意図や判断の背景があると、レビューや引き継ぎがスムーズ

✅ ③ メンテナンスしやすい（更新される前提で作る）

ExcelやPowerPointよりも、MarkdownやNotionなど変更に強い形式が好まれる
「図や表だけ」ではなく「文章での補足」もセットで書く

📚 設計ドキュメントの基本構成（例）

以下は、一般的なシステム設計書の構成例です：

概要
　- システムの目的／利用者／重要度／背景
構成図
　- サーバー／ネットワークの全体構成（物理・論理）
各コンポーネントの説明
　- Web/AP/DBなどの役割と設定概要
非機能要件の設計
　- 監視、ログ、バックアップ、セキュリティ、拡張性など
設計方針・判断理由
　- なぜこの構成にしたのか／他案と比較してどう考えたか
今後の注意点・制約
　- 運用にあたっての留意点／今後の拡張時の考慮事項

📌 POINT：「構成」と「思考」をセットで残すのが、良い設計書です。

✍️ 新人がやるべきドキュメント作成トレーニング

新卒や若手のうちは、いきなり完璧な設計書を書く必要はありません。
まずは以下のような“部分的なアウトプット”から始めてみましょう：

✅ 作業したサーバーの構成図を描いてみる（draw.ioやLucidchartなど）
✅ 「なぜこの設定にしたか？」をメモに残す（設計理由ログ）
✅ 先輩の設計書を読み、「どんな書き方・順番か」を研究する
✅ チームのWikiやNotionに、自分の作業メモを共有してみる

🧠 アウトプットの経験を積むことで、設計の視点と“伝える力”が自然と育っていきます。

🤝 設計ドキュメントが“信頼”と“キャリア”につながる理由

レビューや会議で「説明が的確で、資料もわかりやすい」と評価される
異動・転職時に「設計書が書ける人」としてアピールできる
GitHubやポートフォリオに設計ドキュメントを公開することで市場価値を可視化できる

📌 「作れる人」ではなく「伝えられる人」が、設計者として評価される時代です。

🏁 設計ドキュメントは“考える力 × 伝える力”の証明

設計ドキュメント作成スキルは、「ただ書ける」ではなく、
“考え抜いた設計を、わかりやすく形にして、他者に届ける力”です。

設計の「中身」だけでなく「伝え方」も鍛える
チームで共有できる設計書は、あなたの価値を何倍にも高める
小さな構成図や理由メモから始めて、アウトプットの習慣をつけよう

設計力の成長は、ドキュメントの質に表れます。
その一枚が、あなたの実力と信頼を証明する名刺になります。

🔸 3-7. スキルを磨くために意識したいこと

設計スキルは、ある日突然できるようになるものではありません。
特別な天才だけが持つ能力でもありません。

毎日の業務の中で「どんな視点を持つか」「どう取り組むか」によって、
少しずつ、でも確実に伸ばしていくことができます。

ここでは、設計スキルを着実に身につけていくために、新卒や若手エンジニアが日常で意識すべき具体的な行動指針を紹介します。

🧠 ① 小さな設計から練習する

「設計」と聞くと、サーバー構成図や冗長化の話など、スケールの大きなものを想像しがちですが、
最初はもっと小さな“設計的判断”の積み重ねから始めるのが最適です。

たとえば：

ディレクトリ構成をどうするか？（目的別？時系列？）
ログの出力場所やフォーマットはどうするか？
ユーザー名やホスト名はどんなルールにするか？

これらはすべて、「運用しやすくするための設計」です。
構築や運用の中にも、“設計の種”はたくさん転がっています。

📌 POINT：「構築しながら設計する」習慣を持つことが、設計者への第一歩です。

📖 ② 他人の設計資料から学ぶ

設計スキルを高めるうえで、他のエンジニアのアウトプットを見ることは極めて有効です。

社内の過去プロジェクトの設計書
オープンソースの構成事例や構築ガイド
技術系ブログの構成図や選定理由の記述

他人の設計を読むと、「なぜこうしたのか？」「他に選択肢はなかったのか？」と考えるクセがつき、
自分でゼロから考えるときの“引き出し”が増えていきます。

📌 POINT：「良い設計は良い模倣から」――真似て学ぶのは、成長の近道です。

🗣 ③ 設計の意図を言葉で説明してみる

設計スキルは、考える力だけでなく“説明できる力”まで含めて初めて実力になります。

日常業務の中で、こんな練習がオススメです：

「なぜこの設定にしたのか？」を先輩に説明してみる
作業後に「どんな工夫をしたか？」をチャットやWikiに残してみる
設計資料に「判断理由（Why）」を書くクセをつける

説明することで、自分の思考の“浅い部分”に気づくことができ、
フィードバックを受ければ、それが設計力の修正ポイントになります。

📌 POINT： 言語化は“頭の中の設計”を“チームの知識”に変える力です。

🔍 ④ 失敗やトラブルを“設計視点”で振り返る

設計力を育てる最大の教材は、過去のトラブルや課題です。

なぜこの障害は起きたのか？
設計段階で防げなかったか？
どこに設計の抜け・甘さがあったのか？

トラブルの背景を設計視点で分析することで、
次に設計をする際の「引き算の知識」「リスク感覚」が身につきます。

📌 POINT：「失敗した構成を記録に残す」ことも、大切なアウトプットです。

🛠 ⑤ 小さくても“自分の設計”をつくる

最終的には、「自分で考えて、自分の構成を形にする」経験が成長を一気に加速させます。

趣味で立てたサーバー環境を、設計書にまとめてみる
構築手順書に、設計上の工夫や判断理由を添える
「構成の選定理由」まで含めたアウトプットを社内Wikiやブログに投稿する

こうしたアウトプットは、自分の考えを整理するだけでなく、周囲からのフィードバックを得る機会にもなります。

📌 POINT： 「設計者になってから設計を学ぶ」のではなく、「今の立場で設計を始める」ことが成長への近道です。

🏁 設計力は“毎日の積み重ね”で身につく

設計スキルは特別な才能ではなく、視点・習慣・行動によって確実に育てられる技術です。

成長につながる意識	具体的な行動例
小さな判断も設計と捉える	ログの出力形式や命名ルールに意味を持たせる
他人の設計から学ぶ	社内ドキュメントを定期的に読み込む
説明力を鍛える	設計意図をチーム内で共有・発信する
失敗を次に活かす	障害や不具合の設計的な原因を探る
自分の設計を形にする	簡単な構成でも図解＋意図をセットで残す

今日からでも始められる“小さな設計の練習”を、日々の業務の中に取り入れてみてください。
その積み重ねが、1年後、確かな「設計力」として形になっていきます。

🔹 ４．設計思考を鍛えるための実践的アプローチ

設計スキルは一朝一夕で身につくものではありません。しかし、日々の業務の中で「設計思考」を意識して取り組むことで、確実に力を伸ばすことができます。この章では、設計経験が少ない方でも取り組める実践的なトレーニング方法を紹介します。「なぜその構成にするのか？」を考える癖をつけることが、設計力の土台となります。小さな判断の積み重ねが、やがて全体を見通す力へとつながっていきます。

🔸 4-1. 「設計思考」とは何か？

「設計できるようになりたい」と思ったとき、最初に必要になるのが “設計思考”という視点です。

設計思考とは、「何を作るか」よりも先に「なぜそうするのか？」「それは最適か？」と問いかける考え方であり、単なる技術の話ではありません。
技術と状況を冷静に見極め、“最適な仕組み”を選び抜くための思考法です。

🔍 「構築思考」と「設計思考」の違い

まず、設計思考を理解するには、構築時にありがちな「作業中心の考え方（構築思考）」との違いを知る必要があります。

比較項目	構築思考	設計思考
出発点	「どう作るか？」	「なぜ作るのか？」
目的	手順通りに動くものを完成させる	要件に合った最適な構成を考える
判断基準	手順書・仕様書通り	背景・目的・運用まで含めて判断
視野の広さ	個々の作業に集中	システム全体・運用・将来を含めて考える

📌 POINT： 設計思考とは、「背景」「目的」「制約」「利用者視点」まで含めて、システム全体を捉える思考です。

🧠 設計思考に欠かせない4つの視点

設計思考を実践するうえで意識すべき、代表的な視点は次の4つです。

✅ ① 利用者視点（ユーザー中心の思考）

このシステムは誰が使うのか？
運用する人・保守する人・利用者にとってわかりやすく使いやすいか？
説明が不要な仕組みになっているか？

📌 利用者にとって「迷わず運用できる」「すぐ異常に気づける」構成が、良い設計の第一条件です。

✅ ② 目的逆算の思考（Whyから始める）

「その構成を選んだ理由」は何か？
他の選択肢はあったか？なぜ採用しなかったのか？
本当にその手段が最適か？「やりたいこと」に戻って考える

📌 技術の選定や構成を決めるときは、「目的→要件→構成」の順で考える癖をつけましょう。

✅ ③ 制約とリスクの思考（理想より現実）

時間、コスト、人的リソース、既存システムなどの制約を踏まえて判断する
完璧な設計より、現実的に運用できる設計を選ぶことも重要
「障害が起きたらどうなる？」「変更はどこまで対応可能か？」と想像力を持つ

📌 設計とは、「現場で本当に動く・守れる」構成を選ぶプロセスです。

✅ ④ 将来視点（スケーラビリティ・拡張性）

システムは変わることを前提に設計する
台数が増える、負荷が上がる、構成が変わるときに対応できるか？
手作業に頼りすぎない、自動化・ドキュメント化しやすい構成か？

📌 1年後に「なぜこの構成にしたのか？」と聞かれても、自信を持って答えられる構成が理想です。

💡 設計思考を鍛える実践的トレーニング

🔄 日々の構築作業で「なぜ？」を3回問う

「なぜこの設定にしたのか？」
「なぜこの構成になっているのか？」
「なぜこれが正解とされたのか？」

📝 すぐに答えが出なくても、問いを立てることが学びになります。

🔍 障害やトラブルの事後分析をする

このトラブルは設計で防げたか？
設計段階での想定ミス・抜けはなかったか？
どう設計しておけばもっと良かったか？

🧠 障害から逆算して設計を振り返ると、現場に即した“リアルな設計思考”が育ちます。

✏️ 自分で構成を「選ぶ・比べる・理由を添える」

A案・B案を自分で比べて、「なぜAにしたか？」を書き出してみる
たとえ小さな構成（ログ保存先、ユーザー権限）でも、自分の言葉で説明してみる

📌 “選択肢から選ぶ経験”を積むことが、設計者への第一歩です。

🏁 「設計思考」は、すべての判断を“意味づける力”

設計思考とは、構築の上位にある“判断のための考え方”です。
「何を選ぶか」ではなく、「なぜそれを選んだか」を考え抜く力。
そしてその理由が、運用・保守・改善まで一貫して説明できる力です。

✅ 目の前の作業に「なぜ？」を加える
✅ 選んだことに「理由」を持つ
✅ トラブルに「設計でどう防げたか？」と問いを立てる

この3つを日々の仕事の中で意識することで、設計思考は確実に育っていきます。

設計とは、技術の話でありながら、「人」と「運用」と「未来」を想像する力。
その第一歩は、今日の構築作業を“思考のフィールド”に変えることから始まります。

🔸 4-2. アプローチ①：構築時に「なぜ？」を問いかける習慣

サーバーエンジニアの仕事は、最初は「構築作業」から始まることがほとんどです。
しかし、ただ構築しているだけでは、設計力は身につきません。

大きく成長する人は皆、構築の最中に「なぜこの設定なんだろう？」「なぜこの構成を選んだのか？」という問いを自然に持っています。
この「なぜ？」という問いこそが、設計思考への扉です。

🧠 「なぜ？」を問うことの価値とは？

人は、作業を「こなす」だけでは深く学べません。
しかし、その背後にある意図や理由を考えることで、知識は“思考”に進化します。

たとえば、次のような場面を想像してください：

/var/log にログを保存するように設定されていた
👉 なぜここに保存する？ログのローテーションや容量制限は？
Webサーバーを2台構成で冗長化
👉 なぜ2台？負荷分散だけ？可用性？コストとのバランス？
ApacheではなくNginxを使っていた
👉 なぜNginx？軽量だから？リバースプロキシ用途？

📌 POINT： 「なぜ？」を問うことは、自分の作業を“設計者の視点で再構築する”ことに他なりません。

🔍 構築中に問いかけたい「なぜ？」の具体例

以下は、実務でよくある構築作業に対して、設計思考を鍛えるために役立つ問いかけ例です：

✅ ネットワーク設定の場面で：

なぜこのIPアドレス？サブネット構成の意図は？
ゲートウェイ設定は固定か？ DHCPか？その理由は？

✅ ミドルウェア導入の場面で：

なぜこのバージョン？安定性？互換性？
なぜこの設定ファイルの値？運用を想定した最適化か？

✅ アカウント設定の場面で：

なぜrootログインを禁止するのか？セキュリティ的にどう違う？
なぜこのグループ構成？役割分担のため？運用効率？

✅ サーバー台数や構成の場面で：

なぜこの台数？可用性・負荷・コストのバランス？
1台停止したら業務は止まる？どうリカバリする設計か？

📌 POINT： どんな作業にも“背景”がある。そこに目を向けるだけで、構築作業が学習に変わる。

✍️ 「なぜ？」を問い、メモするだけで設計力は育つ

「なぜ？」と問いかけた結果、すぐに答えが出ないこともあります。
それでもかまいません。

自分で調べる
先輩に質問してみる
答えがわからなくても、メモに「疑問」を残す

この行動こそが、設計者の視点を持ち始めた証拠です。

📘 例：「Webサーバーが2台構成だったが、なぜ3台ではないのか？可用性の観点？コスト面？今後調査。」

🧠 こうしたメモの積み重ねが、後に設計書を読むとき・自分で設計をするときの「判断の引き出し」になります。

🚀 新卒が今すぐ実践できる“思考トレーニング”

実践内容	目的	所要時間
作業中に「なぜこの構成なんだろう？」を1つ考える	思考の習慣化	5分
わからない点を1つメモ or チャットで先輩に聞いてみる	学びの深掘り	10分
作業後に「気づき・意図・反省」を3行で記録	振り返りと知識定着	10分

📌 たった1日15分の設計視点トレーニングで、1年後の思考の深さが変わります。

🏁 「なぜ？」を問い続ける人が、設計者になる

構築作業を通じて成長できるかどうかは、“手を動かす量”ではなく“考えた深さ”で決まります。

「なぜこの設定？」「なぜこの構成？」
その問いが、ただの作業を“設計学習の場”に変える
答えがわからなくても、疑問を持ち、残すことで設計力は育つ

設計者になる準備は、すでに構築の中にある。
あとは、そこに「なぜ？」と問いかける視点を持つだけです。

小さな気づきが、あなたの思考を“設計者の思考”へと変えていきます。

🔸 4-3. アプローチ②：障害対応を設計に活かす

障害対応というと、「トラブル対応は辛い」「早く終わらせたい」と感じる方も多いでしょう。
しかし、設計スキルを伸ばすうえで、実は障害対応ほど“濃い学び”が詰まった機会はありません。

構築中のトラブル、運用中の障害――
その一つひとつの裏には、「設計段階で気づけたはずの何か」があります。

障害対応を単なる応急処置で終わらせず、「どうすれば防げたか？」という視点で振り返ることで、設計者としての視点が育っていきます。

🔍 なぜ障害対応が設計力を鍛えるのか？

障害対応は、以下の3つの要素が揃った“実践型の学びの場”です：

現実的なシナリオと制約条件がある（＝リアルな設計力が問われる）
原因と結果が明確で、「構成の弱点」が浮き彫りになる
改善につなげることで、“防げる設計”への反映ができる

📌 POINT： 設計スキルとは「最初から完璧な構成を作る力」ではなく、「繰り返し失敗から学び、反映していく力」です。

🧠 障害対応から学ぶべき設計視点とは？

✅ ① 「設計のどこが弱かったか？」を掘り下げる

冗長化されていなかった（シングルポイント構成だった）
ログが残っていなかった（原因特定に時間がかかった）
通知が届かなかった（監視設定に抜けがあった）
手順が属人化していた（復旧が遅れた）

👉 どんな障害にも、「設計レベルで防げた可能性」があります。

✅ ② 「再発防止策」を設計に落とし込む

障害報告書や対応メモを書く際、「再発防止策」の粒度を一段深く掘り下げることで、設計スキルが磨かれます。

対応レベル	例	設計視点の強化度
× 作業レベル	設定を直した、再起動した	変化なし（再発リスクあり）
△ 手順レベル	チェックリストを追加した	作業漏れ防止には有効だが根本対応ではない
◎ 設計レベル	ログ出力を強化、監視項目を追加、冗長化を導入	同じ問題が発生しない構成へ進化

📌 POINT：「どう設計していれば防げたか？」という問いが、改善と成長の鍵です。

🔄 障害を“設計改善”に昇華するためのプロセス

✅ ステップ①：障害内容の「全体像」を整理する

いつ・どこで・なにが・なぜ起きたのか？
システム構成上のどこが関係していたのか？
復旧に時間がかかった要因は何か？

📝 この時点では、感情や結果よりも「事実ベースで可視化」することが大切です。

✅ ステップ②：「設計上の抜け」を仮説として立てる

「監視設計」に抜けがなかったか？
「運用設計（手順・通知・ログ）」に盲点はなかったか？
「構成設計」の冗長性や拡張性が不十分だったのでは？

🧠 これは設計レビューの練習にもなります。

✅ ステップ③：「設計レベルの再発防止策」を検討・記録する

構成図に追記する
障害対応ログとセットで設計改善案を書く
社内Wikiなどに「改善前→改善後」を図付きで残す

📌 POINT： 障害は、設計力を「見せられる」「高められる」絶好のチャンスです。

💡 障害対応を通じて得られる設計スキル

得られる力	学べること
判断力	限られた時間と条件で最善を選ぶ力
想像力	障害を起点に、どんな予防策が設計で可能だったかを考える力
伝達力	トラブルの再発防止策を設計書・手順書に落とし込む力
視野の広さ	障害を通して、構成・運用・監視・ログ・保守を一体で考える視点

🏁 障害対応は“設計者としての視点を鍛える特訓の場”

障害対応は、「面倒な業務」ではなく、“実践を通じて設計力を育てる最高の教材”です。

✅ トラブルの背後にある「設計の盲点」を探す
✅ 応急処置だけでなく、再発防止の“設計案”を自分の言葉で考える
✅ 設計レベルでの改善提案を“見える形”で残す

障害は必ず起きます。重要なのは、そこから「次の設計」をどう変えるか。

あなたの設計力は、一度のトラブル対応で大きくレベルアップします。
「なぜ起きたか？」から「どう防ぐか？」へ――
その問いを持つ人こそ、次の時代を支えるサーバー設計者です。

🔸 4-4. アプローチ③：小さな設計から始める

設計と聞くと、サーバー構成図や冗長化、高度な技術選定など、「ベテランがやる仕事」という印象を持つかもしれません。
しかし、設計力はある日突然身につくものではなく、日々の小さな積み重ねの中で育っていく力です。

つまり、設計スキルを身につけたいなら、最初は「小さな設計」から始めるのが正解です。
小さな設計とは、「作業の中にある小さな判断や工夫を、自分で考えて決めること」です。

🧠 なぜ“小さな設計”が大事なのか？

✅ すぐ実践できる（現場で学べる）
✅ 自分で考えて決める経験が増える
✅ 「設計的な視点」を日常に組み込める

設計は「図面を描くこと」だけではありません。
“どう作るかを自分で考えること”すべてが設計なのです。

🔍 実際にできる「小さな設計」の例

🗂️ ディレクトリ構成の設計

/home/user/logs/2024/04/ にする？それとも /var/logs/app/？
担当者が見てすぐわかる構造か？運用や保守を考慮しているか？

✅ 問いかけ例：「後から見た人が迷わず探せる構成になっているか？」

📝 ログ出力の形式と場所の設計

標準出力だけ？ファイル出力？構造化（JSONなど）？
ログの粒度は十分か？トラブル対応時に使えるか？

✅ 問いかけ例：「ログだけで原因を特定できる構成になっているか？」

👤 ユーザー・権限の設計

作業用ユーザーは用途ごとに分ける？1つにまとめる？
sudo設定やアクセス権は最小構成になっているか？

✅ 問いかけ例：「万が一のとき、被害が最小で済む権限構成になっているか？」

📂 スクリプトやファイル名の命名ルール

backup.sh ではなく db_backup_daily_YYYYMMDD.sh にするなど、
名前で内容や頻度がわかるようにできるか？

✅ 問いかけ例：「誰が見ても“役割・実行タイミング”が伝わるか？」

📄 簡易なドキュメント設計

「構築手順」だけでなく「背景」や「設計意図」も一言書けるか？
自分が半年後に読んでも思い出せる内容になっているか？

✅ 問いかけ例：「自分以外の人が読んでも“なるほど”と思えるか？」

✏️ 小さな設計に「理由」を添えると成長が加速する

ただ「設定する」だけでなく、「なぜこのように設定したか？」を一言でも言語化してみると、
設計的な思考がどんどん定着していきます。

作業	設計意図の言語化（例）
ログを `/var/logs/app/` に出力	→ 運用監視が `/var` を標準としているため
ユーザー名に業務名＋IDを付ける	→ 担当者が分かりやすく、棚卸ししやすい構成にするため
バックアップを3世代保持	→ 誤削除などに備えて最低3日分の復元が必要なため

📌 “自分なりの設計意図”を持つことが、あなたの設計スキルの源になります。

🛠 新卒エンジニアでも今すぐできる実践ステップ

ステップ	内容	所要時間の目安
① 作業の前に「設計ポイント」を1つだけ決める	ログの出力場所／ディレクトリ構成など	5分
② 作業の後に「なぜそうしたか？」を書き残す	自分だけの設計メモでもOK	5分
③ 先輩に「こうしたのはこの理由です」と共有する	小さなレビュー・フィードバックをもらう	5〜10分

🧠 こうした習慣が、やがて「構成設計」「運用設計」「セキュリティ設計」にまでつながっていきます。

🏁 「小さな設計」は、大きな設計力への第一歩

設計者になるために、いきなり大きな構成を任される必要はありません。
「小さな判断を、自分の頭で決める」ことが、最も価値のある練習です。

✅ 日々の構築の中にある“設計ポイント”を探す
✅ 決めたことに「理由」を添える習慣を持つ
✅ 自分なりの工夫や意図をアウトプットする

その積み重ねが、3年後には「設計書を作り、レビューをリードできるエンジニア」への確かな土台となります。

“設計は特別なものではなく、今日の自分が始められる行動そのもの”です。
まずは、小さな設計をひとつ、自分で決めてみましょう。

🔸 4-5. アプローチ④：他人の設計書を読む・真似る

設計力を伸ばす上で、最も効果的かつ再現性の高い方法のひとつが、
「他人の設計書を読む」こと、そして「真似ること」です。

「設計ができるようになりたい」と思っても、自分だけで設計をゼロから始めるのはハードルが高いですよね。
そんなときこそ、実際に現場で使われている“生きた設計”に触れることが、最短の学びになります。

📘 なぜ「読む・真似る」が設計力につながるのか？

✅ ① 設計の“思考過程”が見える

設計書には、「なぜこの構成にしたのか」「どんな観点で設計したのか」という、経験者の思考の痕跡が詰まっています。

読むことで、「自分なら見落としそうな視点」「優先順位のつけ方」などが学べます。

✅ ② “引き出し”が増える

構成例・監視設計・バックアップ設計・セキュリティ設定など、テンプレート的に使える知識や表現が身につきます。

「あ、こういう場面ではこう書けばいいのか！」という“型”が自分の中に蓄積されていきます。

✅ ③ 比較することで“自分の癖”に気づく

「自分の書いた設計書と何が違うか？」を比べることで、思考の偏りや抜けに気づくことができます。

🔍 良い設計書から学ぶための“読み方”のコツ

✏️ ① まずは全体の構成を把握する

見出し・章立ての流れを確認し、「どんな粒度で」「何を」設計しているかを捉えます。

✅ 例：「構成図 → 各サーバーの役割 → 非機能要件 → 運用設計 → 判断理由」の順

✏️ ② 各章に込められた“意図”を考える

「なぜこの構成になっているのか？」
「なぜこの選択肢が採用されたのか？」
「他にどんな方法がありえたか？」

📌 “正解探し”ではなく、“思考をたどる”ことが重要です。

✏️ ③ 気づきをメモする

良い表現・工夫されている構成・参考にしたい設計視点をメモし、自分の「設計ノート」をつくりましょう。

📚 読み方だけでなく“真似方”も戦略的に行う

設計書を読んだあとは、部分的でも良いので積極的に取り入れて真似てみることが重要です。

🛠 真似して取り入れやすいもの

項目	真似方の例
構成図の描き方	アイコン・色・矢印・凡例の使い方を模倣してみる
項目名・章立て	「構成方針」「設計方針」「制約事項」などを取り入れる
用語の定義	「○○とは～である」と簡潔に定義している書き方を参考にする
選定理由の表現	「○○の観点で比較し、○○を選択した」といった書き方を使ってみる

📌 「自分なりの設計書テンプレート」を作るつもりで吸収していきましょう。

💡 設計書が手に入る情報源・参考先

情報源	内容
社内の過去案件の設計書	最もリアルな教材。業務フローや運用前提も含まれる。
社内Wiki・ナレッジベース	省略版の設計意図・構成背景が書かれていることも多い。
OSSプロジェクトのアーキテクチャドキュメント	公開資料で学べる構成設計の考え方。GitHubなどで閲覧可能。
技術系ブログ・Qiita・Zenn	実際の構築・運用経験に基づいた構成設計が豊富。
書籍『インフラ設計の教科書』等	フレームワーク的な設計書構成や判断軸を学べる。

🧠 比較・模倣・改善の3ステップで設計力を鍛える

比較：「他人の設計」と「自分の理解・経験」を照らし合わせてみる
模倣：「良い」と感じた表現・構成・視点を取り入れてみる
改善：次に自分が設計書を書くときに“アップデート”として活かす

📝 このサイクルを繰り返すことで、設計スキルは実践を通して自然と磨かれていきます。

🏁 他人の設計から“設計者の視点”を盗め

設計書を読むことは、「設計スキルのショートカット」と言えるほど効率的な学びです。
そして真似ることは、自分の設計力に“現場の経験値”をインストールすることに他なりません。

✅ 他人の設計書を“読んで終わり”にしない
✅ 意図・構成・表現を分解してメモする
✅ 少しずつでも自分の業務に取り入れていく

設計者の視点は、設計書の中に眠っています。
まずは1枚の設計書をじっくり読み、そこから“思考を盗む”ことから始めましょう。
それが、未来の「自分が書く設計書」の質を決定づける第一歩になります。

🔸 4-6. アプローチ⑤：設計レビューで学ぶ

設計スキルを高めたいなら、「設計レビューに参加すること」は非常に有効な学びの機会です。
レビューの場には、設計者の思考、プロの視点、実運用の知恵が凝縮されています。

設計書を「読むだけ」でなく、「レビューされる・する」という双方向の場に身を置くことで、
どんな視点が重視されるか／何が良い設計かが、体感として理解できるようになります。

📌 設計レビューとは？

設計レビューとは、システム構成や仕様に関する設計内容を、関係者と一緒に確認・議論する場です。
目的は「間違い探し」ではなく、より安全で運用しやすい設計にブラッシュアップすることにあります。

✅ レビューでチェックされる主な観点：

観点	具体的な質問例
要件との整合性	この構成で本当に要件を満たせるか？
安全性	セキュリティ上の抜けはないか？
可用性	障害時のリカバリが想定されているか？
拡張性	将来の構成変更に耐えられるか？
保守性	運用者が困らないか？ドキュメントは十分か？

🧠 設計レビューで得られる3つの学び

✅ ①「設計の判断基準」がわかる

設計レビューでは、「なぜこの構成を選んだのか？」という判断の根拠が問われます。

それを聞くことで、以下のような“設計者の裏側”が見えてきます：

技術的な優劣だけではなく、コスト・スキル・運用体制まで加味している
複数の選択肢を比較したうえで、現実的な最適解を選んでいる
あえて“理想より現実”を選ぶ場面もある（運用上の理由など）

📌 設計とは「総合的な判断力」であることが、リアルに理解できます。

✅ ②「抜けやすい視点」が見えてくる

ベテランのレビュー担当者がチェックするポイントを聞くことで、
自分では見落としがちな視点が明確になります。

「その構成、バックアップどうなってる？」
「ログ出力の形式は標準化されてる？」
「冗長化してるけど、フェイルオーバーの手順は設計されてる？」

こうした指摘を聞くたびに、設計時に考えるべき“チェックリスト”が頭の中に増えていきます。

✅ ③「どう伝えれば設計が伝わるか」を学べる

レビューで設計意図がうまく伝わらないと、指摘されたり、誤解されたりします。

「構成図がわかりにくい」
「設計理由が省略されている」
「読んでいて意図が見えない」

この経験を通じて、設計の“見せ方・書き方”の大切さに気づくことができます。

📌 “考えた”だけでは設計ではない。チームに“伝えられてこそ”設計は価値を持つのです。

👥 新卒がレビューでできる関わり方5選（実践編）

✅ ① 設計レビューに“聴講者”として参加する

まずは先輩の設計がどう評価され、どんな視点でレビューされるかを観察しましょう。

✅ ② 「レビュー記録」をメモする

指摘された内容・議論されたテーマをメモし、自分の設計メモに加えましょう。

✅ ③「もし自分だったらこう考える」と仮想レビュー

指摘された部分を自分なりに考えてみる癖をつけると、思考が深まります。

✅ ④ 自分が構築に関わった構成のレビューに関心を持つ

たとえ一部だけの関与でも、「自分の設計」としてフィードバックを受けてみましょう。

✅ ⑤「レビュー後の改善点」を追ってみる

レビュー結果がどう設計に反映されたかを見ることで、フィードバック→改善の流れが学べます。

💬 設計レビューでよくある“学びポイント”集

指摘内容	背景となる設計視点
「構成が複雑すぎる」	運用しやすさ／保守性の視点が抜けている
「この構成、ログ追える？」	トラブル時の原因調査が想定されていない
「冗長化はされてるけど、切替手順がないよね」	可用性＝冗長化＋復旧設計
「DBが単一障害点になってない？」	SPOF（Single Point of Failure）への配慮不足
「なぜこの構成にしたかが書かれてない」	設計理由の可視化＝伝える力の不足

🏁 レビューの場には“設計者の思考”が詰まっている

設計レビューは、経験値の高いエンジニアたちの“思考の型”や“視点の優先順位”を盗める最高の学びの場です。

✅ 設計判断の背景を理解できる
✅ 抜けやすい観点を知り、設計視野を広げられる
✅ 「伝わる設計書」とは何かが体感できる

自分が設計を担当していなくても、レビューに参加し、観察し、メモを取り、真似ることで、
「頭の中の設計スキル」は着実に育っていきます。

レビューに積極的に関わる＝設計の上達を加速させる最短ルートです。
次のレビューには、ぜひ“学ぶ気持ち”を持って参加してみましょう。あなたの設計思考が一歩深くなるはずです。

🔸 4-7. 思考を積み上げることで設計力は自然と育つ

「設計ができるようになりたい」――
その思いは多くの若手エンジニアが抱える目標ですが、“設計”という言葉が漠然としていて、どう始めていいかわからないという人も多いのではないでしょうか。

でも安心してください。
設計力は、特別な才能や肩書きのある人だけが持つスキルではありません。
むしろ、日々の業務の中で積み上げた「考える習慣」こそが、設計力の正体です。

🧠 設計力とは“積み重ねた思考の集積”である

構築、運用、障害対応、ドキュメント作成――
それぞれの業務において「なぜこの設定なのか？」「もっと良い方法はないか？」と問い、
「誰が、どう使うのか？」を考えて行動していく中で、自然と設計者の視点が育っていきます。

設計とは、構成図を描くことではなく、目的に対して「最適な仕組み」を構築する思考プロセスそのものなのです。

🪜 学びを積み上げて設計者へ近づくステップ

✅ 小さな判断に「理由」をつける

→ ログ保存先、ユーザー権限、構成ファイルの書き方一つひとつに「なぜ？」を考える

✅ 失敗やトラブルから「学び」を拾う

→ 障害や構成ミスが発生したとき、「どうすれば防げたか？」を設計視点で振り返る

✅ 他人の設計を読んで「視点の広さ」を真似る

→ 社内の設計書、技術記事、OSSの構成などから“設計の型”を学ぶ

✅ 1つの構成に複数の選択肢を持ち、自分なりの判断をしてみる

→ 正解探しよりも、「なぜこの案を選んだか」を説明できるようにする

📌 これらはすべて、今日から始められる設計力のトレーニングです。

🏗️ 設計は“センス”ではなく“仕組み化された思考”

よく「設計ってセンスが必要ですよね」と言われますが、
実際の現場では「再現可能な思考プロセス」に基づいた判断が圧倒的に求められます。

要件の整理 → 制約の把握 → 選択肢の比較 → 運用視点の考慮 → 最終判断
この思考を、何度も何度も繰り返していくことで、判断のスピードと精度が上がり、“設計力”と呼べるレベルに達するのです。

🌱 「設計できる人」は、“考え続けた人”である

設計ができるようになるために必要なのは、
特別なプロジェクトの経験や、誰かからの指示ではなく、
「自分で考え、試し、反省し、また考える」という地道な積み重ねです。

はじめは先輩の設計書をなぞるだけでもいい
自分なりに考えた構成に「理由」を添えるだけでもいい
トラブル時に「どう設計していればよかったか？」を1つ考えるだけでもいい

📌 毎日の中にある小さな“設計”に気づき、向き合い続けることが最大の成長要素です。

🚀 これからのあなたに贈る行動指針

目の前の構築に「なぜ？」を持とう
障害から「設計に生かせる視点」を拾おう
先輩の設計から「思考の型」を盗もう
小さくても、自分で「決めた」設計を持とう
設計を“伝える力”として形に残そう

🏁 設計者への道は、もう始まっている

あなたが毎日行っている小さな判断や作業にも、設計の要素は必ずあります。
そしてその一つひとつに、ほんの少し意識を向けるだけで、確実に“設計者としての視点”が芽生えていきます。

設計は「何かができるようになること」ではなく、
「常に考える人であり続けること」。

思考を積み重ねることで、設計力は必ず、自然と育ちます。
あなたの3年後は、「設計ができる人」として信頼される未来です。

まずは、今日の構築作業でひとつ、
「なぜ？」と問いかけてみましょう。そこから、すべてが始まります。

🔹 ５．アウトプット – 「システム設計の原則と事例集」を作ろう

設計スキルを本当の意味で身につけるには、「実践」と「振り返り」が欠かせません。自分が関わったシステムの設計について、判断の根拠や工夫したポイントを言語化しておくことで、知識が経験として定着します。この章では、「設計の原則」と「実際の設計事例」をまとめたアウトプットの方法を紹介します。記録に残すことで、自分の成長が見えるだけでなく、チームや後輩への貢献にもつながります。

🔸 5-1. なぜ設計をアウトプットに残すべきか？

設計力を身につけたいなら、「考えたことを外に出す」＝アウトプットの習慣が欠かせません。
どれだけ頭の中で考えていても、それがドキュメントや構成図などの形として残っていなければ、設計とは言えません。

そしてこの「設計をアウトプットに残す」という行為こそが、あなたの設計スキルを磨き、証明し、評価されるきっかけになるのです。

🧠 設計をアウトプットすることの本当の意味

設計をアウトプットするとは、単に構成図を書くことではありません。
それは以下のような複数の価値を生み出す“技術的コミュニケーション”の手段です。

✅ ① 設計意図が「他人に伝わる」状態になる

設計とは「なぜこの構成にしたのか？」という思考と判断の記録でもあります。
それを構成図や設計書、構成メモなどに落とし込むことで、チームの誰もがその意図を理解できるようになります。

状態	伝わり方
アウトプットなし	「何を考えて設計したのか分からない」
アウトプットあり	「なぜこの構成か？背景と意図が理解できる」

📌 POINT： アウトプットは、設計を「個人の思考」から「チームの資産」に変える鍵です。

✅ ② 自分の考えを“振り返る材料”にできる

設計を文字や図に落とすことで、客観的に自分の判断を見直すことが可能になります。

後から読み返して「ここは甘かったな」と気づける
他人に見せる前に「わかりにくいかも」と気づける
他人の指摘を受けて「意図が伝わっていなかった」と理解できる

🧠 頭の中の思考は曖昧でも、アウトプットにすれば“設計の質”を自己改善できる材料になります。

✅ ③ 評価・共有・再利用がしやすくなる

設計をアウトプットに残しておけば、他の人のレビューやアドバイスが受けやすくなり、そこから学びが生まれます。

さらに、設計書や構成図は一度作っておけば、次回以降の構築・設計時にテンプレートや参考事例として再利用もできます。

レビューされる → 視点が増える
引き継がれる → 価値が広がる
再利用される → 時間短縮につながる

📌 POINT： アウトプットされた設計は、チームや未来の自分を助ける“ナレッジ資産”になります。

✅ ④ 自分の「設計力」を“証明”できるようになる

アウトプットには、スキルを「見える形」にする力があります。

設計書、構成図、設計メモ、改善レポートなどを蓄積しておくことで、
社内での信頼や任される仕事の幅、さらには将来的な転職活動においても、「自分が何を考えてどう構成したか」をアピールする材料になります。

✅ GitHubに構成図を公開
✅ ブログに設計意図を整理して記事化
✅ ポートフォリオに「構成の背景」もまとめて掲載

📝 設計力は“言語化できて初めて武器になる”のです。

✏️ 新卒でもできるアウトプットの始め方

✅ 小さな構成でも図にしてみる（draw.io / Excalidrawなど）

→ たとえ1台構成でも、構成図を描けば設計の習慣が身につきます。

✅ 作業メモに「なぜそうしたか？」の一言を添える

→ ログ保存先や設定値の選定理由など、小さな設計意図も立派なアウトプットです。

✅ 社内Wikiやチームチャットに「設計メモ」を投稿

→ フォーマットがなくてもOK。「こういう理由でこの構成にしました」と書くだけで学びになります。

📌 まずは「自分の頭の中の設計を1つだけ外に出す」ことから始めてみましょう。

🏁 設計力はアウトプットしなければ“存在しない”のと同じ

設計力は、考えるだけでは育ちません。
アウトプットすることで初めて、育ち、伝わり、評価されていきます。

✅ 設計の意図を“見える形”で残す
✅ 振り返り・改善・共有のサイクルを回す
✅ 自分の技術力を「言語化できるスキル」として磨いていく

たとえ最初は粗削りでも構いません。
「アウトプットする習慣」を持つ人こそ、設計者として大きく成長していける人です。

明日からの構築作業で、「なぜこの設定にしたのか？」をメモに残すこと。
それが、設計者としての最初の一歩です。

🔸 5-2. 「原則と事例集」ってどういうもの？

「設計力を高めたい」「設計を学びたい」と思ったとき、役に立つのが“設計原則と事例集”です。
これは、「なぜその設計をするのか？」という考え方（原則）と、「実際にどう設計したのか？」という具体例（事例）をセットでまとめた学びの武器です。

この「原則と事例」を自分の経験として蓄積しておくことで、次の設計に迷わず判断できる力が身についていきます。

🧭 設計の“原則”とは何か？

✅ 原則 = 判断の軸となる考え方・ルール

設計原則とは、「こういう時はこう考える」「この目的にはこの構成が合っている」といった、
場面ごとに共通する“判断の指針”です。

たとえば：

原則	内容例
最小権限の原則	ユーザー・プロセスには最小限の権限しか与えない
冗長化の原則	1台止まっても業務が止まらない構成を心がける
ログはトラブル対応の命綱	ログ出力と保存形式は設計時点で決めておく
目的から構成を逆算する	技術選定は「要件ありき」で行う

📌 POINT： 原則があると、「迷ったときの判断軸」ができる。設計に一貫性が生まれます。

📚 設計の“事例集”とは何か？

✅ 事例 = 実際に使った構成・構築経験の記録

事例とは、「こういうシステムで、こういう構成にした」というリアルな設計・構築の記録です。
実際に動かしてみた結果や、構成の選定理由、改善ポイントなどをまとめることで、
過去の経験が“再利用できる知識”になります。

たとえば：

システム	選んだ構成	設計理由	成功点／改善点
社内Wiki	Nginx + PHP + MariaDB	シンプル構成・低負荷想定	構築が速かった／ログの出力粒度が足りなかった
バッチ処理	1台構成・cron定期実行	高可用性不要・コスト重視	設定がシンプル／障害時の通知がなく対応に遅れた
ファイル共有	Samba + Active Directory連携	社内統合認証を実現	操作性◎／アクセス制御の設計が複雑になった

📌 POINT： 成功・失敗どちらも「再現可能な知識」として残しておくことで、設計者としての判断材料が増えます。

🛠 「原則と事例集」の作り方 – 実践ガイド

✅ ステップ①：「よく使う設計判断」を洗い出す

「ログ保存先どうする？」
「WebとDBは同居 or 分離？」
「バックアップはどこまで必要？」
こうしたよく出てくる迷いポイントをリストアップします。

✅ ステップ②：「こう考えるとよい」という原則を書き出す

「トラブル対応を想定して、ログは外部ストレージに出す」
「CPU使用率が高いアプリなら、APとDBは分離したほうがいい」

→ 実体験ベースの原則でOKです。抽象化しすぎなくて大丈夫。

✅ ステップ③：「実際にやった構成」とセットで残す

実際に構築した内容（構成図／構成ファイル抜粋／設計理由）を簡潔に整理
可能なら「良かった点／困った点」も書くと、将来の判断材料になります

🧠 どんな場面で役立つのか？

シーン	活用ポイント
✅ 新しい案件で構成を検討するとき	「似た事例があったか？」を振り返って再利用できる
✅ 上司や先輩に設計を説明するとき	原則に基づいた説明ができると納得感がある
✅ 障害対応後の振り返り時	「この障害はどの原則が欠けていたか？」と自己評価できる
✅ チームのナレッジ共有	他のメンバーが設計に迷ったとき、事例として役立つ

📌 “原則と事例”があることで、設計の判断スピードと説得力が上がります。

📝 新卒でも今日から始められる実践例

✅ 自分が担当した構築作業について、「なぜそうしたか」をメモで残す
✅ 先輩の設計を見て、「これは原則化できそう」と思うポイントをストック
✅ チームWikiに「設計ノート」セクションを設け、簡易的に共有してみる

📌 小さなことでも、「自分の頭で考えたこと」を書き残すことが、将来の“設計力の辞書”になります。

🏁 「原則と事例集」は、設計者の“武器と盾”になる

✅ 原則は「ぶれない判断の軸」
✅ 事例は「過去の知見を再利用する資産」
✅ セットで残すことで、設計判断のスピード・質・再現性が高まる

設計に迷ったとき、白紙から考えるのは大変です。
だからこそ、「自分の原則と事例集」を持つことが、考える負荷を減らしつつ質を高める強力な手段になります。

まずは一つ、あなたが関わった構築案件について、
「なぜそう設計したのか」「次に活かせるポイントは何か」をメモに残してみましょう。
それがあなた自身の「原則と事例集」の第一歩です。

🔸 5-3. 作成のステップ（具体例つき）

設計力を伸ばしたいなら、自分だけの「原則と事例集」を持つことが非常に効果的です。
これは、あなた自身の経験や気づきを「いつでも見返せる判断材料」として形に残す、“思考の資産化”とも言えます。

ここでは、ゼロからスタートしても作れるように、具体的なステップと記録のフォーマット例を紹介します。

🪜 ステップ①：小さな判断・気づきを書き留める

まずは、「これって毎回迷うな」「いつもこうしてるけど、理由って何だろう？」という小さな判断の積み重ねを拾うことから始めましょう。

✅ 具体例（初級）：

🔹 テーマ：ログの保存先の決め方
🔸 気づき：/var/log/appname/ にまとめると、他部署がログ監視しやすい
✏️ メモ：「標準パスを使えば監視・保守が楽になる」

📌 ポイント： 最初は“思いつき”でOK。完璧な設計じゃなくて大丈夫です。

🪜 ステップ②：「なぜそうしたか？」を言語化する

単に「こうした」ではなく、「なぜそうしたか？」という設計理由や背景を言葉にして残すことが重要です。
これが“原則”に育っていきます。

✅ 具体例（中級）：

🔹 テーマ：WebとDBを同居させるか分離するか
🔸 選択：社内ツールで同居構成にした
✏️ 理由：「同時アクセスが少なく、リソース競合のリスクが小さいため」
✅ 学び（原則化）：「低負荷システムは、同居構成でも十分対応できる」

📌 ポイント： 意図を残すことで、次回同じ判断を迷わずに行えるようになります。

🪜 ステップ③：「よかった点」と「改善点」を振り返る

設計は“完璧”でなくてもいいのです。むしろ「次はこうしたい」まで含めて書くことが設計思考の訓練になります。

✅ 具体例（上級）：

🔹 テーマ：サーバー監視設定
🔸 構成：CPU、メモリ、ディスクをZabbixで監視
✅ よかった点：閾値設定を根拠ある数値にできた
⚠️ 改善点：アプリケーションの死活監視を入れ忘れた → 次回はURL監視を追加

📌 ポイント： 「振り返り」こそが、事例を“再利用可能な学び”に昇華させます。

🪜 ステップ④：テンプレート化する

続けていくうちに、「こう書けば整理しやすいな」という自分なりのフォーマットが見えてきます。
以下のようなテンプレートを使うと、整理しやすく継続もしやすくなります。

✏️ 【原則と事例フォーマット例】

🔹 テーマ：Webサーバー構成の分離

🔸 原則：
- 可用性が求められる場合、WebとAPを分離する
- ロードバランサーを活用し、メンテ性も考慮する

🧠 判断理由：
- 同時アクセス数が高く、負荷分散の必要あり
- 今後のスケールアウトも見据えた構成とした

🛠 実践事例：
- Nginx（2台）+ PHP-FPM（2台）+ DB（1台）
- HAProxyでのLB構成／死活監視あり

📈 成果：
- 想定より高い安定性と応答性能を維持できた

⚠️ 改善点：
- ログの統合管理が不十分だったため、次回はFluentd連携を検討

🧠 ステップ⑤：社内Wikiや個人メモで“設計ナレッジ”を蓄積する

完成した原則と事例は、自分のためのナレッジベースとして社内WikiやNotion、Markdownファイルなどにまとめておきましょう。
チームと共有できれば、他のメンバーの学びにもつながり、組織全体の設計品質が向上します。

📌 POINT： 共有する前提で書くと、自然と「伝わる設計思考」も身につきます。

🏁 「小さな記録」が“未来の設計判断”を支える

✅ 「気づき」を残すことで、設計の原則が蓄積される
✅ 「背景」や「意図」を書き残すことで、再利用できる事例になる
✅ 記録をテンプレート化すれば、設計スキルの定着と成長が加速する

原則と事例集は、“未来の自分を助ける設計辞書”です。

今日の構築作業で「ちょっと迷ったこと」「工夫した点」があれば、
その理由を1行だけでもいいのでメモしてみましょう。
それが、あなた自身の設計力を支える第一歩になります。

🔸 5-4. 記録しておくと役立つテーマ例

「原則と事例集を残そう」と言われても、
「何を書けばいいの？」「どこを切り取れば原則になるの？」と戸惑う方も多いかと思います。

そこでこのセクションでは、実務で特に設計判断を求められるテーマを厳選して紹介します。
これらのテーマをベースに記録を残しておけば、次回以降の設計判断やチームメンバーへの説明にも活用できます。

✅ 1. ログ設計の判断と構成

💡 なぜ記録すべき？

トラブル対応・監査・性能分析など、ログは運用の生命線。設計時の判断が後々まで影響を与える。

🔍 観点の例：

ログの保存先は /var/log/？別ボリューム？
ログの形式はプレーンテキスト？JSON？
ログローテートの設定は？何日保持？
複数サーバーのログを集約する仕組みは？

📝 記録例：

原則：「障害調査や分析に活用できるよう、ログは構造化・集中管理する」
事例：「nginxアクセスログをJSON形式で出力し、Fluentd経由でElasticsearchに送信」

✅ 2. ユーザー・権限設計

💡 なぜ記録すべき？

最小権限の原則に基づく設計は、セキュリティだけでなく運用効率にも直結。

🔍 観点の例：

一般ユーザー／作業用ユーザーの分離方法
sudo の制限設定（特定コマンドのみ許可）
作業ログの取得方法
共有アカウントの管理方法（極力避ける）

📝 記録例：

原則：「作業は特定ユーザーで行い、ログを残す。root操作はsudo経由」
事例：「Web管理者用アカウントに限定したsudo設定を導入し、操作ログを/var/log/sudo.logに記録」

✅ 3. サーバー構成と冗長化の考え方

💡 なぜ記録すべき？

システム停止や性能劣化を防ぐために、構成の選定理由や可用性の考え方を記録しておくことで、将来的な再設計や引き継ぎに役立つ。

🔍 観点の例：

Web/AP/DBの分離・統合判断
冗長化構成（HA構成・LB構成）の種類
シングルポイントがどこか？回避策は？
フェイルオーバーの仕組み・手順

📝 記録例：

原則：「冗長化は“高可用性が本当に必要な箇所”だけに絞る」
事例：「社内ツールのWebサーバーはHA構成、DBは単一構成＋定時バックアップで対応」

✅ 4. バックアップとリストア設計

💡 なぜ記録すべき？

「バックアップはあるが、戻せない」構成は意味がない。設計の背景と実行可能性が重要。

🔍 観点の例：

何を、いつ、どこに、どの方式でバックアップするか？
世代管理の方針
リストア手順があるか？検証されているか？
バックアップファイルの暗号化・転送方式は？

📝 記録例：

原則：「バックアップは“戻せること”を前提に設計する」
事例：「PostgreSQLをpg_basebackupで毎日取得し、週1回は実際に検証リストアを実施」

✅ 5. ミドルウェアの選定理由と構成方針

💡 なぜ記録すべき？

選定理由や構成の背景を記録しておくことで、後継者や運用担当者が安心して保守できる。

🔍 観点の例：

なぜApacheではなくNginxなのか？
なぜMySQLではなくPostgreSQLなのか？
コンフィグの初期値からの変更点とその理由
既存資産との互換性や制約条件

📝 記録例：

原則：「選定理由は“性能・保守性・運用コスト”のバランスで判断する」
事例：「API GatewayにNginxを採用。軽量＋リバースプロキシ用途に適しているため」

✅ 6. 監視設計・アラートルールの方針

💡 なぜ記録すべき？

障害を早期に発見し、無駄なアラートに悩まされないためには、設計の工夫と判断の記録が不可欠。

🔍 観点の例：

監視対象（サーバー／アプリ／ネットワーク）の選定理由
アラート閾値の決め方（過検知・過小検知の対策）
通知方法・ルーティング設計
アラート発生時の自動対処の有無

📝 記録例：

原則：「アラートは“対応が必要なもの”だけに絞る」
事例：「CPU使用率85%超で通知 → 数値の根拠：通常利用でのピークが70%前後のため」

✅ 7. セキュリティに関する設計判断

💡 なぜ記録すべき？

セキュリティは「なぜこうしたか？」の設計意図を記録しておくこと自体がリスク管理の一部。

🔍 観点の例：

SSHポートの変更／rootログイン制限の理由
FirewallやIP制限のポリシー
ソフトウェアアップデートの方針
セキュリティログの保存先と保持期間

📝 記録例：

原則：「操作は“記録に残す”“即時アラートで気づける”状態を設計する」
事例：「SSHは公開鍵認証＋内部LANからのみ許可。すべてのアクセスログは1年間保存」

🏁 テーマの選び方に迷ったら“繰り返し迷ったポイント”を残す

設計原則と事例集のテーマに正解はありません。
しかし、次のような問いに対して「毎回迷うな」「判断が曖昧だな」と思ったポイントは、記録に最適です。

「この構成で大丈夫だろうか？」
「何を基準に選べばいいのか分からない」
「先輩に“なぜこの設定なの？”と聞かれて困った」

📌 それこそが、あなたが設計者として“思考した証拠”であり、将来の判断力の材料になります。

まずは、今日の作業で「迷ったこと」を1つだけ書き留めてみましょう。
それが、あなただけの設計辞書の第一ページになります。

🔸 5-5. 継続的にアップデートすることで価値が増す

「原則と事例集」を一度作っただけで終わってしまっていませんか？

実はそれ、“半分だけの設計者”になってしまっている状態です。

設計の知識やノウハウは、一度まとめたら終わりではなく、使いながら育てていくものです。
日々の実務やトラブル、技術の変化を通じてアップデートすることで、あなたの設計ノートは「単なる記録」から“価値ある資産”へと変わっていきます。

🔁 アップデートが必要な3つの理由

✅ ① 設計は“現場で進化する”ものだから

システムは変わります。
サーバーの構成、運用の体制、使う人の数、要求される可用性――
同じ構成がずっと正解であり続けるとは限りません。

当初は単一構成でも問題なかったが、利用者が増えて冗長化が必要になった
手作業でも回っていたが、監視対象が増えて自動化が求められるようになった
社内ルールが変わり、ログの保存ポリシーが更新された

📌 現場の変化に対応できる設計書は、“使えるドキュメント”として重宝されます。

✅ ② 自分の視点が深まるから

初めて設計したときには見えなかったことも、
障害を経験したり、他の人の設計に触れたりすることで、“新たな視点”が得られるようになります。

ログの保存期間が短すぎて調査に困った → 保存方針を見直し
アラートの閾値が厳しすぎて誤検知が多発 → 適切な設計指針を追加
監視対象を選ぶ際に“重要度と復旧性のバランス”という新たな軸に気づいた

📌 あなたの“気づき”は、すべて設計資産としてアップデートのタネになります。

✅ ③ 情報は“更新され続ける”から

使用するOS、ミドルウェア、監視ツール、バックアップツール――
すべての技術は日々進化しています。

バージョンアップによって設定項目が変わった
新しいツールに乗り換えたことで構成がシンプルになった
セキュリティポリシーに新しい要件が追加された

設計原則や事例も、それに合わせて柔軟に進化させていかなければ“古くて使えない知識”になってしまいます。

📌 アウトプットは“鮮度”が命。常にメンテナンスする意識が大切です。

🛠 どうアップデートすればいいか？

📝 1. トラブルや改善があったら、即メモ＋反映

「障害が起きた」→ どの設計でカバーできていたか？できなかったか？
「構成を変えた」→ なぜ？どこが変わった？判断の根拠は？
「運用担当に褒められた」→ 何が役に立った？なぜうまくいった？

📌 小さな気づきほど、設計書・事例集に反映する価値があります。

📅 2. 月に1回、自分の設計メモを読み返す日を作る

使っていない原則はあるか？古くなっていないか？
最近の案件で適用できたか？できなかったか？
もっと汎用化できる記述にできないか？

📌 設計は“読み返すことで成長する文書”です。

🤝 3. 他のメンバーと“設計振り返り”を行う

他人の原則・事例を見ると、新たな視点が得られる
「あ、それうちの構成にも使える！」という気づきが生まれる
お互いにレビューすることで、設計の“伝え方”の質も高まる

📌 ナレッジは、チームで共有・改善してこそ生きた設計資産になります。

🚀 継続的なアップデートが“市場価値”につながる理由

✅ 信頼につながる：「この人はちゃんと考えて設計している」
　→ 設計書に“更新履歴”があるだけで、周囲の評価が変わります。

✅ 振り返りに使える：「この3年間で何を設計してきたか」が整理されている
　→ 転職・異動時のポートフォリオとして活用できます。

✅ 再利用性が高い：「あの構成、また使えるね」と言われる知識になる
　→ 他人に頼られる存在へ。ナレッジリーダーの一歩です。

🏁 「書きっぱなし」ではなく「育てるアウトプット」を目指そう

原則と事例集は、一度作って終わりではなく、“成長し続ける設計ノート”です。

✅ トラブル、改善、新しい気づきをどんどん反映する
✅ 定期的に読み返して、設計の質を見直す
✅ 他人と共有・フィードバックを受けて磨き上げる

設計力は、積み上げた思考と経験の「メンテナンス」で伸びていきます。

ぜひ、自分の設計アウトプットを「育てる感覚」で扱ってみてください。
それが、3年後に“市場価値の高い設計者”として評価されるあなたをつくる確かな一歩になります。

🔸 5-6. 設計力は“記録力”で差がつく

設計ができるようになるには、経験が必要です。
しかし、ただ経験するだけでは、設計力は思ったほど伸びません。

同じように構築・運用を経験していても、「記録している人」と「記録しない人」では、数年後に大きな差がつきます。

それはなぜか？
記録とは、思考の「見える化」であり、知識の「再利用化」であり、自分の成長の「証拠」でもあるからです。

🧠 記録することで設計力が育つ3つの理由

✅ ①「考える習慣」が定着する

設計を記録するには、「なぜこの構成にしたのか？」「他に選択肢はなかったか？」と考える必要があります。

適当にやっただけでは書けない
手順だけでは足りない
意図を持って判断しないと記録にならない

📌 記録する行為そのものが、“設計者の思考トレーニング”になるのです。

✅ ②「経験」が“知識資産”に変わる

どんなに良い構成を考えても、それを残していなければ次に活かせません。

似た案件が来てもまたゼロから考える
昔の判断理由を忘れて同じミスを繰り返す
チーム内でナレッジが共有されず、属人化が進む

📌 記録することで、設計の経験が“自分とチームの資産”になります。

✅ ③「技術力」が“伝える力”として評価される

記録とは、自分の設計を他者に伝えられる状態にすることでもあります。

チームに設計意図を共有できる
レビューでの指摘が具体的になる
転職・異動時に「設計力の見える化」ができる

📌 スキルは“見える形”にしてはじめて、評価されるのです。

🛠 記録力で設計スキルを差に変えるための習慣チェックリスト

✅ 習慣	説明
構築後に「なぜそうしたか？」を1行で残す	思考を言語化する癖がつく
トラブル発生後に「防げた設計」を書き出す	改善・再発防止に直結
他人の設計書から学んだことをメモする	自分の視野が広がる
記録内容を月1で見直し、更新する	知識の鮮度が保たれる
社内WikiやNotionで共有する	チーム設計力が向上する

📌 どれも今日から実践できる、設計力を伸ばす“思考の習慣化ツール”です。

🚀 記録を続ける人は、なぜ市場価値が高いのか？

✅ 「設計力があります」と言わなくても、“設計書”がそれを証明する
　→ 実績ベースで信頼される／転職や昇格でも説得力がある

✅ 「この人に任せれば残る」と思われる
　→ 属人化を避け、ナレッジを共有できる人として重宝される

✅ 「引き継ぎしやすい」「他部署にも説明できる」技術者になる
　→ 技術とビジネスの橋渡しができる存在へ

🏁 記録とは、設計者になるための“最強の練習帳”

✅ 記録することで思考が深まり
✅ 思考が深まることで設計に意図が生まれ
✅ 意図が伝わることで信頼と評価が生まれます

つまり、設計力とは“記録力”にほかなりません。

「まだ設計経験が少ないから…」と思わず、
まずは1つ、今日の判断を言葉にして残すことから始めてください。

それがやがて、あなた自身の設計辞書となり、
“市場価値の高いエンジニア”への確かな道標になります。

🔹 ６．設計力は「視野」と「伝える力」で決まる

設計力は、技術だけでなく「どれだけ広い視野で物事を捉えられるか」、そして「それを他者にどう伝えるか」で決まります。正しい構成を選べても、それが相手に伝わらなければ、設計としては不完全です。設計とは、技術と運用、セキュリティ、チームとの連携など、すべてをつなぐ橋渡し役です。この記事の最後に、設計スキルを高めるために意識すべきマインドセットを整理しましょう。次のステップに自信を持って進むために。

🔸 6-1. 設計力とは「広い視野」と「伝える力」の掛け算

「設計ができるエンジニア」とは、どんな人でしょうか？
構成図が描ける人？ツールに詳しい人？トラブルに強い人？

どれも大切なスキルですが、実は設計力の本質はもっとシンプルです。
それは――
「広い視野」と「伝える力」の掛け算である、ということです。

👁‍🗨 ① 広い視野がなければ、“良い設計”にはたどり着けない

設計には、技術力だけではなく「どれだけ多くの要素を見渡せるか」が求められます。

✅ 広い視野とは、以下のような観点を同時に持てることです：

視点	質問例
利用者視点	この構成は、運用者や利用者にとって使いやすいか？
将来視点	サーバーやアクセス数が増えたときも耐えられるか？
トラブル視点	障害が起きたときに、復旧しやすい構成になっているか？
セキュリティ視点	権限や通信経路にリスクはないか？
コスト視点	必要以上に台数・スペックを盛っていないか？

📌 広い視野＝多面的な想像力。技術だけでなく「人・未来・運用」まで想定して設計する力です。

🗣 ② 伝える力がなければ、“設計”は共有できない

いくら優れた構成を考えていても、他人に伝わらなければ、それは設計として成立しません。

✅ 伝える力とは、以下のような技術です：

構成図で「全体像」をわかりやすく伝える
設計書に「なぜそうしたか？」を言語化する
レビューで設計意図を論理的に説明できる
引き継ぎや障害時に、他人がすぐ理解できるドキュメントを残す

📌 伝える力＝設計をチームの「共通言語」に変えるスキル。

🧠 なぜ“掛け算”なのか？

設計力は「視野の広さ」×「伝える力」で評価されます。
どちらかが欠けても、設計者としての力は半減してしまいます。

📌 設計者として信頼される人は、常に「広く見て、正しく伝える」ことができる人です。

🛠 今日からできる「視野」と「伝える力」の鍛え方

🔍 広い視野を持つために：

✅ 他のチームの構成や設計を観察する
✅ 障害報告書を読み、「どこに設計の抜けがあったか？」を考える
✅ 1つの構成に対して、「セキュリティ・コスト・運用性」の3視点で見直す習慣を持つ

✍️ 伝える力を磨くために：

✅ 構成を「図＋理由」のセットでまとめるクセをつける
✅ 社内Wikiや日報に「なぜこの構成にしたか」を一言で書く
✅ 説明を受けるときに「この人はどう伝えているか？」を観察する

🚀 設計力は“掛け算”であるからこそ、伸びしろが大きい

視野を少し広げるだけで、設計の深みが増す
伝え方を少し変えるだけで、設計の説得力が上がる

つまり、ちょっとした意識と習慣の変化が、設計力を何倍にも伸ばす要因になります。

🏁 設計者としての信頼は「視野の広さ」と「伝える力」で決まる

「この人の設計は信頼できる」
「この構成なら任せられる」

そう思われるエンジニアは、ただ技術に詳しいだけではありません。
運用・トラブル・将来を見据えた視点を持ち、
その思考を他人にわかる言葉で伝えられる人です。

それこそが、これからのサーバーエンジニアに求められる設計力の本質です。

📌 視野の広さ × 伝える力 = 市場価値の高い設計者

まずは、小さな構成でもいいので「意図」と「理由」を誰かに説明してみてください。
それが、設計者への最初の一歩となります。

🔸 6-2. この記事で学んだキーポイントの振り返り

本記事では、「設計ができるエンジニアになるために必要なスキルセット」として、単なる構築作業から一歩踏み込んだ“設計力の育て方”について解説してきました。

ここでは、各セクションで紹介したキーポイントを7つの重要視点として整理し、あなたのこれからの実践に直結する形で振り返ります。

✅ ① 「設計思考」を持つことが出発点

設計は単なる技術作業ではなく、「なぜそうするのか？」を問い続ける思考法です。

構築作業の背後にある“目的”を考える
複数の選択肢を比較し、理由を持って選ぶ
現実的な制約や運用のしやすさも含めて判断する

📌 POINT：設計思考を身につけるには、「構築時に3回なぜ？と問う」習慣から。

✅ ② 障害対応は“設計者の訓練場”

障害やトラブル対応は、設計の弱点が明確になる最高の学習機会です。

「この障害は設計で防げたか？」と振り返る
応急処置で終わらせず、構成の見直しまで踏み込む
その経験を設計ノートに記録する

📌 POINT：「障害 × 設計視点」で見直すことで、再発防止力＝設計力が育ちます。

✅ ③ 小さな判断も立派な“設計”

設計は大きな構成図だけの話ではありません。
日々の小さな判断も“設計的行為”の一部です。

ログの出力場所
ディレクトリ構成
権限の設定方針

📌 POINT：一つひとつに“理由”を添えて記録することが、設計者としての視点を育てます。

✅ ④ 他人の設計から“視点”を盗む

設計スキルは、自分の経験だけでは限界があります。
他人の設計書を読むことで、自分にない発想や構成方針を吸収できます。

「なぜこの構成にしたのか？」を考えながら読む
良い設計は真似る・取り入れる
気づいたポイントは設計ノートにメモ

📌 POINT：「読む・比べる・真似る」で、設計の引き出しが広がります。

✅ ⑤ 記録することで“設計力が見える化”される

設計スキルは、アウトプットして初めて実力になります。

なぜその構成にしたのかを書き残す
設計メモ・Wiki・構成図などで見える形にする
書いたものをレビュー・振り返りで活用する

📌 POINT：設計力＝「考える力」×「伝える力」。どちらも“記録”で育てられます。

✅ ⑥ 原則と事例集で“自分だけの辞書”を作る

日々の判断やトラブル経験を蓄積し、再利用できる知識の形にすることが、継続的な成長のカギです。

「こういう場面ではこう考える」を原則化
「実際にやった構成・判断」を事例化
繰り返し見返し、改善・更新していく

📌 POINT：1つずつ記録すれば、それはあなただけの「設計辞書」になります。

✅ ⑦ 設計力は“視野の広さ”と“伝える力”の掛け算

最後にもう一度、設計力の本質はこの掛け算です：

👁【視野の広さ】× 🗣【伝える力】＝ 📈【設計者としての信頼】

技術・運用・将来を見据える多角的な視野
それをチーム・ドキュメントで明確に伝える力

📌 POINT：「広く見て、正しく伝える」人が、真の設計者として信頼されます。

🏁 設計力は、“考えたことを残す習慣”から育つ

今日からできる小さな行動で、設計者への道は必ず開けます。

✅ 「なぜ？」と問いかけて考える
✅ 考えたことを記録する
✅ それを振り返ってアップデートする
✅ 他人と共有して広げる

これらの習慣こそが、3年後に“市場価値の高い設計ができるサーバーエンジニア”になるための土台です。

あなたの原則と事例集が、
設計力を証明する“武器”になり、
チームを導く“地図”になり、
キャリアを切り拓く“羅針盤”になる。

それを今日から、1つずつ積み上げていきましょう。
設計力は、あなたの手の中にあります。

🔸 6-3. 次のアクション – 明日から取り組めること

「設計ができるようになりたい」――
そう思ったときに最も大切なのは、明日から実践できる“小さな一歩”を明確にすることです。

本記事を読んだあなたは、すでに「設計思考」の重要性や、「原則と事例を記録する価値」について理解できています。
あとは、それを実際の行動に落とし込むだけです。

ここでは、“明日からできる具体的なアクション5選”として、どんなに忙しくても取り組める実践例を紹介します。

✅ ① 構築作業の中に「なぜ？」を1つ加える

🔹 アクション内容：

構築中の設定や構成に対して「なぜこの方法なのか？」を1つだけ問いかけてみましょう。

🔸 具体例：

「なぜログは /var/log/ に出しているのか？」
「なぜこの順番で構築しているのか？」
「なぜこのポート番号にしているのか？」

📝 考えたことはメモ帳や自分の日報に記録するだけでOKです。

✅ ② 作業後に3行だけ設計メモを残す

🔹 アクション内容：

作業が終わったら、「判断したこと」「理由」「気づき」を3行にまとめて記録します。

🔸 具体例：

WebとDBを同居させた。  
同時アクセスが少なく、分離のメリットが小さいため。  
次回は負荷状況を事前に調査して判断したい。

📌 ポイントは完璧さより“習慣化”です。書くことが設計力のトレーニングになります。

✅ ③ 他人の設計書を1つ読んで、1つ真似る

🔹 アクション内容：

先輩の設計書や過去プロジェクトのドキュメントを読み、「いいな」と思った部分を1つだけ自分の作業に取り入れてみましょう。

🔸 具体例：

構成図の矢印の描き方を真似する
用語定義の章立てを流用する
設計理由の書き方をそっくり使ってみる

📌 学びを“模倣→実践”につなげると、理解と定着が一気に深まります。

✅ ④ トラブルの振り返りで「設計視点」から考える

🔹 アクション内容：

障害やミスが発生したら、「設計で防げたか？」という視点で必ず振り返ります。

🔸 具体例：

「監視が設定されていなかった → 初期設計に監視項目の洗い出しを入れるべきだった」
「復旧に時間がかかった → ログ出力設計を見直す必要あり」

🧠 “構築の後ろに設計がある”ことを、体験を通じて理解できます。

✅ ⑤ 原則と事例を1件だけ書いてみる

🔹 アクション内容：

今日または最近の構築経験から、「1件だけ」で良いので、設計原則と事例を書いてみましょう。

🔸 フォーマット例：

🔹 テーマ：バックアップ設計

🔸 原則：「バックアップは“戻せること”を前提に考える」

🧠 判断理由：過去にリストア手順が曖昧で復旧に時間がかかった経験があったため

🛠 実践事例：Webサーバーの設定ファイルを毎日cronでS3に保存＋月1回復元テスト

📌 たった1件でも、“自分の設計資産”が1つ増えることになります。

📅 【1週間で設計力を育てるミニチャレンジ】

曜日	やること
月	構築作業に「なぜ？」を1つ加える
火	作業後に3行だけ設計メモを残す
水	他人の設計書を1つ読んで、真似る
木	過去の障害を1つ「設計で防げたか？」の視点で振り返る
金	設計原則＋事例を1件だけ記録してみる

📌 5日間で「考える→記録する→応用する」の設計ループが体験できます。

🏁 行動に落とせば、設計力は必ず伸びる

✅ 考える力（設計思考）
✅ 伝える力（設計の言語化）
✅ 残す力（記録・可視化）
この3つを日々少しずつ鍛えるだけで、あなたは確実に“設計ができるエンジニア”に近づいていきます。

設計力に魔法はありません。
日々の仕事を「設計の学び場」に変えるかどうかだけです。

📌 まずは、「今日の構築作業」に“ひとつの問い”を加えてみてください。
それがあなたの設計者としての第一歩です。今この瞬間から、始めましょう。

🔸 6-4. 設計力は、キャリアの武器になる

サーバーエンジニアとして働く中で、
「このまま運用や構築の仕事だけで良いのだろうか？」
「将来的に転職するとき、どんなスキルが武器になるのか？」
そんな不安や疑問を抱いたことはありませんか？

その問いに対する最も強力な答えの一つが「設計力」です。

構築や運用スキルだけでは差別化しにくい時代だからこそ、
設計ができるエンジニアは“希少価値の高い存在”として重宝されるのです。

🔧 なぜ「設計力」がキャリアの武器になるのか？

✅ ① 価値ある仕事を“上流”から担えるようになるから

構築や運用は、仕様が決まったあとに行われる“下流工程”です。
一方、設計は仕様を決める・形にする“上流工程”です。

要件定義に参加できる
技術選定に関与できる
プロジェクトの初期段階から声がかかる

📌 設計力を持つことで、より裁量のあるポジションを任されやすくなります。

✅ ② トラブルに強く、信頼される存在になれるから

設計力とは、単に構成図を描けることではなく、トラブルに備え、未然に防ぐ力でもあります。

なぜこの冗長構成なのか？
なぜこの監視設計なのか？
どうしてこのログ設計が有効なのか？

これらを説明できる人は、チームや顧客からの信頼が圧倒的に高まります。

📌 「この人に任せれば安心」と思われる設計者は、どんな現場でも引っ張りだこです。

✅ ③ 転職市場で「差がつく実力」として評価されるから

構築や運用の経験は、応募者全員が持っていることも珍しくありません。
そこで目を引くのが、「設計経験」「改善提案」「構成図・設計書の成果物」です。

🔍 実際に評価されやすい設計アウトプット：

システム構成図（オンプレ／クラウド）
障害を踏まえた改善提案書
運用設計ドキュメント
技術選定の根拠資料や比較表

📌 “自分の言葉で構成を説明できるか”が、評価の分かれ目になります。

✅ ④ SREやアーキテクトへのキャリア発展につながるから

設計スキルは、キャリアをより専門的・戦略的な方向に広げるための“踏み台”になります。

方向性	活かせる設計スキル
✅ SRE（信頼性エンジニア）	可用性設計、監視・復旧設計、トイル削減設計
✅ クラウドアーキテクト	スケーラブルな構成設計、セキュリティ設計
✅ テックリード／PL	チーム全体の設計方針立案、レビュー能力
✅ フリーランス／独立	設計〜提案までを一人で完結できる力

📌 “設計ができる人”は、どんなキャリアパスにも強い柔軟性を持っています。

💡 キャリアに活きる設計スキルの“見せ方”

設計力は、見える形でアピールしてこそ、キャリアの武器になります。

✅ おすすめのアウトプット形式：

ポートフォリオに構成図＋設計理由を掲載する
ブログで「構築の裏にある設計意図」を発信する
GitHubに構成テンプレートやAnsibleプレイブックを整理する
社内向けWikiに事例集として蓄積し、レビューの材料にする

📌 記録 × 公開 × 振り返り＝市場価値を高める設計資産

🏁 設計力は、キャリアの“突破力”になる

✅ 現場での存在感を高めたいなら → 設計で信頼を得る
✅ 上流に関わりたいなら → 設計で価値を示す
✅ 転職やキャリアの選択肢を広げたいなら → 設計を武器にする

設計力は、単なるスキルではありません。
それはあなたの「技術を形にし、意図を伝え、価値を生み出す力」です。

だからこそ――
設計を学ぶことは、“あなた自身のキャリアを設計する”ことでもあるのです。

📌 明日から1つの構成に、「なぜこうしたか？」を考える習慣を。
それが、5年後のあなたの市場価値を大きく変える第一歩になります。