Lockiron / The Fortress of a Solo IT Manager | 一人情シスの砦
| | Columns

一人情シスが設計していいインフラの「上限」：自作Kubernetes基盤が退職後に負の遺産になる理由

#インフラ #クラウド #運用設計 #一人情シス #技術的負債

情シス（あるいはエンジニア）としてスキルが上がってくると、「自前で作り込みたくなる」病にかかることがあります。

「AWSのリファレンスアーキテクチャ通りに、Auto ScalingとMulti-AZを組んで……」 「コンテナオーケストレーションは流行りのKubernetesで、CI/CDパイプラインも完全に自動化しよう」 「VPNはOpenVPNサーバーを自分で立てれば、月額費用が浮くぞ」

技術的な挑戦心は素晴らしいものです。その構成は美しく、効率的で、コストパフォーマンスも高いかもしれません。 あなたがいる間は。

しかし、一人情シスの現場において、この「高度で美しい自作インフラ」は、あなたが退職した瞬間、後任者にとっての「解読不能な魔窟」と化します。 本稿では、インフラエンジニアとしてのプライドをぐっと飲み込み、**「一人情シスが設計していいインフラの複雑性の上限」**について、維持可能性（Maintainability）の観点から定義します。

理想と現実のギャップ

技術者の理想

  • ゼロトラスト：全てのアクセスを動的に検証する。
  • IaC (Infrastructure as Code)：Terraformですべての構成をコード管理する。
  • コンテナ化：EKS/GKEでマイクロサービスを運用する。
  • ベンダーフリー：OSS（オープンソース）を駆使してライセンス料を極限まで下げる。

一人情シスの現実

  • 突発対応：インフラ作業中に「プリンターが詰まった」と呼び出される。
  • 引継ぎ：後任が未経験、あるいは総務兼任のおじさんかもしれない。
  • 障害対応：夜中の2時にサーバーが落ちた時、対応できるのは自分だけ。

この現実の中で「理想」を追求すると、運用負荷があなたのキャパシティを超え、やがて破綻します。

原則：あなたが辞めても動くか？

インフラ設計の上限を決める唯一の基準。 それは**「自分が明日交通事故で入院しても、あるいは退職しても、このシステムは動き続けるか（または後任がボタン一つで直せるか）」**です。

NG：自作サーバー（EC2 / VM）でのミドルウェア運用

「Active DirectoryサーバーをEC2で立てて運用」 「ファイルサーバーをLinux + Sambaで構築」

これは原則禁止と考えるべきです。 OSのパッチ当ては誰がやりますか？ ディスクが溢れた時の拡張手順は？ バックアップスクリプトが動かなかった時のリカバリは？ あなたがスクリプトを書けるとしても、後任は書けません。

OK：フルマネージドサービス（SaaS / PaaS）

「認証基盤はEntra ID（旧Azure AD）にお任せ」 「ファイルサーバーはBoxかGoogle Drive、SharePoint」

これなら、OSの面倒を見る必要はありません。障害が起きても「Microsoftの障害です」と言えば、経営陣も納得します（あなたが直す必要がないからです）。 コストが高くても、マネージドサービスを選ぶことは「あなたの睡眠時間」と「会社の安定」を買う行為です。

インフラ設計の「上限」ガイドライン

では、具体的に「どこまでならやっていいか」のライン引きをします。

1. ネットワーク：家庭用ルーターに毛が生えた程度まで

Ciscoのコマンドライン（CLI）でゴリゴリにVLANを切り、BGPで経路制御をする……というのは、100人規模・一人情シスではやりすぎです。

  • 推奨ライン：Web GUIで設定できるクラウド管理型Wi-Fi（Meraki GoやAruba Instant Onなど）。
  • 理由：スマホアプリから「再起動」ができるからです。コマンドを叩ける人がいなくなっても、物理配線を挿してGUIでポチポチすれば復旧できるレベルに留めます。

2. VPN：アプライアンスかゼロトラストSaaS

OpenVPNやSoftEtherをLinuxサーバーに入れるのは、趣味の範囲ならOKですが、業務インフラとしてはリスクが高すぎます。証明書の更新漏れで全社員が繋がらなくなる事故が必ず起きます。

  • 推奨ライン：FortiGateなどのアプライアンスの機能を使う、またはTailscaleやCloudflare Zero TrustのようなSaaS型VPNを使う。
  • 理由：これらも「管理画面」で完結するからです。黒い画面（ターミナル）での操作を必須要件にしないことが鉄則です。

3. Webサーバー：PaaSかレンタルサーバー

自社HPや簡単なWebアプリのために、VPSを借りてApache/Nginxの設定を書くのはやめましょう。SSL証明書の更新（Let’s Encryptの自動更新設定）すら、後任にはハードルが高いです。

  • 推奨ライン：WordPressならKinstaやWP Engine、静的サイトならVercelやCloudflare Pages、GitHub Pages。
  • 理由：インフラのメンテナンスが不要だからです。「サーバーが落ちた」という概念自体がほぼなくなります。

4. IaC (Terraform / CloudFormation)：ドキュメントの代わり程度に

「インフラ構築の自動化」は魅力的ですが、一人情シスでは**「復旧の自動化」までは求められても、「構築の頻度」**は高くありません。 年に1回いじるかどうかの設定のために、複雑なTerraformコードを書くと、1年後の自分自身が「これどうやって書いたんだっけ？」と悩みます。

  • 推奨ライン：基本はコンソール（GUI）で設定し、設定値のキャプチャをドキュメントに残す。あるいは、ごくシンプルな構成定義のみコード化する。
  • 理由：コードのメンテナンスコストが、手作業のコストを上回るからです。

「技術者としての敗北」ではない

「OSSを使わず、高いマネージドサービスばかり使うなんて、エンジニアとしてレベルが低い」 そう感じるかもしれません。

しかし、一人情シスのミッションは「高度な技術力を見せつけること」ではなく、**「ビジネスを止めないこと」**です。 高度にカスタマイズされた不安定な（属人的な）システムより、凡庸だが誰もが扱える堅牢なシステムの方が、企業にとっては価値があります。

AWSのソリューションアーキテクト試験に出てくるような構成図を書くのがあなたの仕事ではありません。 **「月額980円のSaaSを契約して終わり。あとは全部ベンダーがやってくれます」と言い切れること。 この「作らない勇気」**こそが、一人情シスにおける最高の設計力です。

退職する日、「引き継ぎ資料、これ（ベンダーのサポート電話番号リスト）だけですか！」と驚かれるくらいシンプルなインフラを残して、颯爽と去りましょう。 それが、あなたがこの会社に残せる最大の功績です。

AIに相談するためのプロンプト（テンプレート）

自分が作ろうとしているインフラ構成が「やりすぎ（オーバーエンジニアリング）」でないか、AIに壁打ちしてもらうためのプロンプトです。

あなたは「維持管理コスト（Maintenance Cost）」に厳しいインフラアーキテクトです。
一人情シスである私が、自社の新しいシステム基盤を設計しました。
これが記事にある「退職後も回る維持可能なインフラ」の基準を満たしているか、辛口で評価し、よりシンプルな代替案があれば提示してください。

# 構築しようとしているシステム
*   目的: [例: 社内用のタスク管理アプリのホスティング]
*   構成案: [例: AWS EC2にDockerを入れて、Nginxとアプリをコンテナで稼働させる。DBはRDS]
*   IaC: [例: Terraformで全構成をコード化する予定]

# 私のスキルセット
*   [例: Linuxコマンドは叩ける。Dockerもなんとなく分かる]

# 将来の懸念（制約条件）
*   後任者は「総務のおじさん（IT未経験）」になる可能性があります。
*   私が退職した後、サーバーが落ちたら誰もコマンドラインで復旧できません。

# 出力してほしい内容
1.  **生存判定**: この構成は「一人情シスの卒業制作」として適切か、それとも「負の遺産」になるか。
2.  **改善案**: よりマネージド（PaaS/SaaS）に寄せた、メンテナンスフリーな構成案。
3.  **コスト比較**: 提案構成にした場合の、構築工数と運用工数の削減効果の概算。
ホームに戻る