現場から逆算して設計する
フルスタックなシステムづくり

Djangoを選んでいる一番の理由は、「現場の変化に追従しやすいこと」です。 要件が最初から完璧に固まっている現場はほとんどなく、運用を回しながら 「やっぱりここはこうしたい」「この項目も欲しい」といった声が必ず出てきます。 Djangoの管理サイトやORM、フォーム周りの仕組みを活かすことで、 そうした変更を比較的安全かつ短いサイクルで反映していくことができます。

例えば、ファイルサーバーと連携した社内向け共有フォルダや、ログ解析・可視化のためのダッシュボード、 Microsoft 365 や各種APIと連携したワークフローなど、 「既存の仕組みを壊さずに、現場の手触りを少しずつ良くしていく」ことを意識して設計してきました。 画面の見た目だけでなく、権限やログ、障害時の切り戻しといった運用面も含めて、 トータルで現場に馴染むことを大切にしています。

また、Djangoのsignalsやmiddlewareを活用し、監査ログの自動記録や、 特定の操作に対する通知・検知なども実装してきました。 「誰が・いつ・何をしたか」が追えることは、トラブルシュートだけでなく、 現場の安心感にもつながります。 フロントエンドはBootstrapや軽量なコンポーネントを組み合わせ、 過度に凝りすぎず、しかし使い勝手は犠牲にしないバランスを意識しています。

ここに載せているのはあくまで一部ですが、どの画面にも共通しているのは 「現場の人が、説明書なしで触ってもなんとなく分かる」こと。 そのために、ボタンの配置やラベル、エラー時のメッセージなど、 細かい部分を何度も現場で試しながら調整してきました。

サーバー構築では、AlmaLinux / Ubuntu などのLinuxディストリビューションをベースに、 Webサーバー、PHPやPythonの実行環境、メールサーバー、データベースなどを組み合わせて構成してきました。 特に、PHP環境のバージョン共存やソースビルド、拡張モジュールの管理など、 一度構築して終わりではなく、長期的に運用しながらアップデートしていけるような設計を重視しています。

現場では、「古いシステムを止められない」「でも新しいバージョンも試したい」といった要望がよくあります。 そのためコンテナ、仮想環境などを組み合わせ、 既存環境に影響を与えずに新しいバージョンを導入・検証できるような構成を取ることが多いです。 こうした工夫によって、リスクを抑えながら段階的な移行を実現してきました。

また、ログの設計や監視の仕組みも、構築段階から組み込むようにしています。 障害が起きたときに「何が起きているのか分からない」状態を避けるため、 アプリケーションログ・OSログ・ミドルウェアログを整理し、 必要に応じて外部の監視ツールや通知システムと連携させます。 これにより、問題の早期発見と、復旧までの時間短縮を狙っています。

セキュリティ面では、ファイアウォールやSELinuxの設定、権限設計、バックアップポリシーなどを 現場の運用体制に合わせて調整します。 「理想的なセキュリティ」と「実際に回せる運用」のバランスを取りながら、 無理なく続けられる仕組みを一緒に作っていくことを大切にしています。

Azureでは、仮想マシン（IaaS）だけでなく、Microsoft 365 や各種SaaSとの連携を前提にした設計を行ってきました。 すべてを一気にクラウドへ移行するのではなく、認証やファイル共有、ワークフローなど、 効果が出やすい部分から少しずつクラウドサービスを取り入れていくスタイルです。

例えば、Azure EntraID を軸にした認証基盤の整備や、SharePoint / OneDrive を使ったファイル共有、 Graph API や AI Foundry を用いた各種APIや自動化など、 「人が手でやっている定型作業を、少しずつサービス側に寄せていく」ことを意識しています。 その際、既存のオンプレADやファイルサーバーとの連携も考慮し、 現場の運用を止めずに移行できるように設計します。

IaaSについては、オンプレのサーバー構成をそのまま持ち込むのではなく、 バックアップやスケール、可用性の考え方をクラウドに合わせて見直すことを心がけています。 監視やログ収集も、Azure Monitor や各種サービスと連携させることで、 オンプレ時代よりも「見える化」を進めることができます。

クラウド導入で大事にしているのは、「技術的にできるか」だけでなく、 「現場の人が、ちゃんと使いこなせるか」という視点です。 そのため、運用フローや問い合わせ窓口、権限の付け方なども含めて、 一緒に整理しながら進めていくことを意識しています。

ネットワーク構築では、論理設計だけでなく、実際の配線ルートやラックの空きスペース、 電源容量、既存機器との干渉など、物理的な制約を踏まえた設計を行ってきました。 現場に足を運び、天井裏や床下、盤の中を確認しながら、 「このルートなら安全に通せる」「将来の増設も見込める」といった観点で配線計画を立てます。

実際の工事では、LANケーブルや光ファイバーの敷設、パッチパネルへの結線、 無線APの設置位置の調整などを行います。 見た目の美しさも大事ですが、それ以上に「トラブル時に追いやすい配線」であることを意識しています。 ラベルの付け方や系統の分け方ひとつで、障害対応のスピードは大きく変わります。

また、ネットワーク機器の設定だけでなく、現場の利用シーンを想像しながら VLAN設計やセグメント分割、無線のチャンネル設計などを行います。 「セキュリティを高めたい」「でも、現場の人が困らないようにしたい」という 相反する要望のバランスを取ることが、ネットワーク設計の面白さでもあります。

システム側と物理側の両方を見てきた経験から、 「この設計だと、現場でこういう詰まり方をするかもしれない」といった 具体的なイメージを持ちながら提案できることが、自分の強みだと感じています。

これまで、Djangoを使ったWebアプリケーション開発、Linuxサーバー構築、 Azureを中心としたクラウド活用、ネットワーク設計・配線工事など、 システムに関わるさまざまなレイヤーを横断して携わってきました。 共通して大事にしているのは、「現場で実際に使われる姿をイメージしながら設計すること」です。

机上の設計だけで完結させず、自分の手で構築し、運用し、トラブルにも向き合う。 その繰り返しの中で、「この設計だと、運用がしんどくなる」「ここはもう少し自動化できる」といった 感覚的な部分も含めて、少しずつ引き出しを増やしてきました。 失敗したことも含めて、次の現場に活かしていくことを意識しています。

また、技術的な正しさだけでなく、「現場の人が納得して使えるか」という視点も大切にしています。 どれだけ高度な仕組みを作っても、現場の運用フローや文化と噛み合わなければ、 結局は使われなくなってしまいます。 だからこそ、要件定義やヒアリングの段階から、現場の声を丁寧に拾うことを心がけています。

このページでは、そんな自分の仕事の一部を、Django・サーバー構築・Azure・ネットワーク工事という いくつかの切り口で紹介しました。 もしどこか一つでも、「こういう考え方は自分の現場にも合いそうだ」と感じていただけたなら、 それが一番うれしいことです。