この記事は「SE・システム開発入門」2部作の前編です。
後編では、要件定義、設計、テスト、移行、運用保守まで、システム開発の流れを現場目線で解説しています。
後編はこちらです。
はじめに
SEを目指す人の多くは、最初に「まずはプログラミングを覚えないと」と考えます。
もちろん、それは間違いではありません。
Java、Python、JavaScript、SQLなどを理解できれば、アプリケーションがどう動いているのかをイメージしやすくなります。
実際、プログラミングはシステム開発において重要なスキルです。
ただし、SEの仕事はプログラミングだけでは終わりません。
現場に入ると、コードを書く前後に考えることが、想像以上に多いことに気づきます。
たとえば、Web画面に「申請する」というボタンを1つ作るだけでも、裏側では多くのことを考えています。
- 誰が申請できるのか
- 誰が承認するのか
- 申請データはどこに保存するのか
- 同時に多くの人がアクセスしても耐えられるのか
- サーバが1台壊れても業務を続けられるのか
- データはバックアップされているのか
- 障害が起きたときに誰が検知するのか
- 本番リリース時に旧システムからデータをどう移すのか
- 個人情報や機密情報をどう守るのか
- 本番稼働後、誰がどう運用するのか
利用者から見えるのは、画面やボタンや検索結果です。
しかし、その裏側には、サーバ、データベース、ネットワーク、セキュリティ、監視、バックアップ、運用設計、移行設計など、非常に多くの要素があります。
つまり、システム開発とは、単にプログラムを書く仕事ではありません。
業務を動かす仕組みを、アプリケーションとシステム基盤の両方から作り上げる仕事です。
この記事では、これからSEを目指す人、初級SEとして働き始めた人、またはシステム開発の全体像がつかめずに悩んでいる人に向けて、システム開発の見方を整理します。
一般的なアプリ開発の説明だけではなく、インフラエンジニア／システム基盤エンジニアの視点も交えながら説明します。
なぜなら、実際のシステムは、機能が動くだけでは不十分だからです。
システム開発とは、一言でいえば、業務上の目的を実現するための仕組みを作ることです。
ここで重要なのは、ITやプログラミングそのものが目的ではないということです。
企業がシステムを導入する理由は、もっと現実的です。
- 売上を増やしたい
- 業務を効率化したい
- 人手不足を補いたい
- ミスを減らしたい
- 顧客対応を早くしたい
- 情報漏えいを防ぎたい
- 古いシステムを安全に入れ替えたい
- 障害に強い仕組みにしたい
- 将来の利用者増加に耐えられるようにしたい
つまり、システム開発の目的は、企業や組織の活動をよりよくすること
です。
たとえば、社内の物品購入申請を考えてみます。
紙の申請書に記入し、上司にハンコをもらい、決裁者が承認し、担当部門が処理する。こうした業務があったとします。
これをシステム化すると、次のようになります。
- 担当者がWeb画面から購入申請を登録する
- 承認者にメールやチャットで通知が届く
- 承認者がリンクから内容を確認する
- 承認ボタンを押す
- 承認履歴が記録される
- 後から監査や確認ができる
ここまでは、よくある業務アプリケーションの説明です。
しかし、インフラエンジニアの視点では、さらに裏側を見ます。
この申請システムを本番で使うなら、次のようなことも考えなければなりません。
- 何人が同時にアクセスするのか
- 画面は何秒以内に表示されるべきか
- サーバが1台停止したら業務は止まるのか
- データベース障害時にどこまで復旧するのか
- 承認履歴は何年間保存するのか
- 夜間バッチは何時までに終わる必要があるのか
- ログはどこに出し、何日保存するのか
- 監視アラートは誰に通知するのか
- バックアップはいつ取得し、復旧確認はするのか
- 本番移行時に、旧システムの未承認データをどう扱うのか
これらは、利用者からは見えにくい部分です。
しかし、この見えにくい部分が弱いと、システムは本番で使えません。
画面がきれいでも、アクセス集中で遅くなる。
機能が正しくても、サーバ障害で止まる。
承認処理ができても、障害時に復旧できない。
データが登録できても、バックアップから戻せない。
運用手順がなければ、夜間障害で誰も対応できない。
こうなると、システムとしては失敗です。
だからこそ、システム開発では、機能だけでなく、非機能も重要になります。
「機能が動く」と「本番で使える」は違う
初心者SEが最初に理解すべき大事なことがあります。
それは、機能が動くことと、本番で使えることは違うということです。
たとえば、申請画面があり、申請ボタンを押すとデータが登録される。
これは「機能が動く」状態です。
しかし、本番で使えるかどうかは、さらに別の観点で確認する必要があります。
- 1人が使うと動くが、1,000人が同時にアクセスしても動くのか
- 画面表示に10秒かかっても業務上許されるのか
- DBサーバが停止した場合、何分で復旧できるのか
- 障害発生時に、どのデータまで戻せるのか
- 月末に申請が集中しても処理できるのか
- 夜間バッチが朝の業務開始前に終わるのか
- セキュリティパッチ適用時にサービスを止める必要があるのか
- 本番移行に失敗した場合、切り戻せるのか
こうした観点を考えるのが、システム基盤／インフラ領域の重要な仕事です。
特に「1人が使うと動くが、1,000人が同時にアクセスしても同じように動くのか」という観点は、実際の現場では非常に重要です。
たとえば、アプリケーションそのものは正常に動いていても、リリース直後に多数の端末やブラウザが一斉にアプリ資材をダウンロードし、配布元のWebサーバやネットワーク、メモリ、接続数を圧迫して業務影響が出ることがあります。
最近であれば、SPAのJavaScriptファイル、Electron系アプリの更新資材、コンテナ環境でのイメージpull、CDNキャッシュ切れ後のオリジン集中などでも、似た構図は起こり得ます。
通常の業務画面をJMeterで試験して問題がなくても、リリース直後の資材配布、リトライ、同時接続、キャッシュ設計、サーバ設定まで見ていなければ、本番で初めて問題が出ることがあります。
つまり、性能問題は単に「画面が速いか遅いか」だけではありません。
機能として動くことと、本番運用で耐えられることは違います。
このあたりは、「性能・サイジング」「非機能テスト」の回で、実際に現場で起きたトラブルの考え方も交えながら詳しく解説します。
非機能とは何か
ここで、「非機能」という言葉について簡単に説明します。
非機能とは、画面やボタンのように利用者から直接見える機能ではありません。
しかし、システムを本番で安心して使うために必要な品質のことです。
初心者向けに言えば、非機能とは、そのシステムが本番でちゃんと使えるかを決める条件です。
たとえば、次のようなものが非機能に含まれます。
- 処理速度
- 止まりにくさ
- 障害時の復旧
- バックアップ
- 監視
- セキュリティ
- 運用しやすさ
- 将来の拡張性
- 移行のしやすさ
利用者は、普段こうしたことをあまり意識しません。
しかし、本番でトラブルが起きると一気に表面化します。
「画面が遅い」
「システムが止まった」
「障害に気づくのが遅れた」
「バックアップから戻せない」
「移行したらデータが合わない」
「運用担当が手順書を見ても対応できない」
こうした問題は、プログラムの不具合だけで起きるわけではありません。
システム基盤、運用設計、移行設計、非機能要件の詰めが甘いことで起きることも多いです。
SEの仕事はプログラミングだけではない
SEという言葉は、とても広く使われています。
現場によっては、プログラマーに近い仕事をする人もいます。
お客様と要件を詰める人もいます。
プロジェクト全体を管理する人もいます。
サーバやネットワークを設計する人もいます。
データベースを専門にする人もいます。
運用設計や監視設計を担当する人もいます。
つまり、SEといっても、役割はかなり幅広いです。
システム開発には、たとえば次のような役割があります。
- 業務要件を整理する人
- 画面や機能を設計する人
- プログラムを書く人
- データベースを設計する人
- サーバ構成を設計する人
- ネットワークを設計する人
- 監視やバックアップを設計する人
- 性能テストを計画する人
- 障害復旧テストを行う人
- 本番移行を計画する人
- 稼働後の運用を設計する人
この中で、プログラミングは重要な一部です。
ただし、システム開発全体で見ると、プログラミング以外の仕事も非常に多いです。特に企業向けの業務システムでは、「作ったら終わり」ではありません。
何年も使われます。
利用者が増えます。
データも増えます。
法律や業務ルールも変わります。
障害対応も発生します。
セキュリティ対策も継続的に必要です。
そのため、システム開発では、最初から運用や保守まで見据えて設計する必要があります。
インフラエンジニア視点で見るシステム開発
インフラエンジニア、またはシステム基盤エンジニアは、システムの土台を作る役割です。
ただし、ここでいう土台とは、単にサーバを用意することではありません。
本番でシステムを安定して動かすために、次のようなことを考えます。
- 可用性：障害が起きても使い続けられるか
- 信頼性：壊れにくく、安定して動くか
- 性能：必要な処理速度を満たせるか
- 拡張性：利用者やデータが増えても対応できるか
- 運用性：監視、バックアップ、障害対応ができるか
- 保守性：変更やメンテナンスがしやすいか
- 移行性：旧システムから安全に切り替えられるか
- セキュリティ：不正アクセスや情報漏えいを防げるか
お客様は、画面や機能だけを求めているわけではありません。
本当は、こう思っています。
「業務時間中は止まらないでほしい」
「遅くて使えないのは困る」
「障害が起きたら早く復旧してほしい」
「データは失わないでほしい」
「個人情報は守ってほしい」
「運用担当者が対応できる仕組みにしてほしい」
「将来、利用者が増えても使い続けたい」
これらは、すべてシステム基盤の設計に関係します。
だからこそ、システム開発を理解するには、アプリケーションだけでなく、インフラ／基盤の視点が必要です。
システム開発の全体工程
ここからは、システム開発が現場でどのような順番で進むのかを見ていきます。システム開発は、かなり単純化すると次の流れで進みます。
プロジェクトごとに呼び方や細かい進め方は違いますが、まずは
「決める → 設計する → 作る → 確認する → 切り替える → 改善する」
という流れをつかめばOKです。
この図を見ると分かる通り、システム開発は「プログラミング（コーディングとコンポーネントの開発）」だけで完結しません。
多くの人は、システム開発というと「プログラミング」を思い浮かべます。
もちろん、プログラミングは重要です。
しかし実際には、その前に要件定義や設計があり、その後にテスト、移行、運用保守まで続きます。
つまり、システム開発とは、単にコードを書く仕事ではありません。
業務を動かす仕組みを、作って終わりではなく、本番で安定して使える状態まで持っていく仕事です。
この全体像を最初に理解しておくと、SEの仕事がかなり立体的に見えるようになります。
業務系システム開発の工程名に置き換えると、次のようになります。
初心者SEは、まずこの流れを頭に入れておくとよいです。
現場で資料名や会議名を聞いたときに、
「ああ、これは基本設計の話だな」
「これは基盤テストの話だな」
「これは移行工程の話だな」
と位置づけられるだけで、かなり理解しやすくなります。
システム開発では、いま自分がどの工程にいるのかを意識することが大切です。
要件定義の段階で話すべきこと。
設計の段階で決めるべきこと。
テストの段階で確認すべきこと。
移行の段階で慎重に見るべきこと。
運用保守で継続的に確認すべきこと。
それぞれの工程には役割があります。
この工程のつながりが見えるようになると、SEの仕事はかなり分かりやすくなります。
そして、システム開発はアプリ開発と基盤構築が並行して進みます。
システム開発は、アプリケーション開発だけで進むわけではありません。
画面や機能を作るアプリケーション開発と並行して、システム基盤の設計・構築・テストも進みます。
たとえば、申請ワークフローシステムを作る場合、アプリ側では次のようなことを考えます。
- 申請登録画面をどう作るか
- 承認ルートをどう判定するか
- 差戻しや再申請をどう扱うか
- 承認履歴をどう表示するか
- メール通知をどう送るか
一方、基盤側では次のようなことを考えます。
- Web/AP/DBサーバをどう構成するか
- サーバを冗長化するか
- ロードバランサを使うか
- DBをActive-Standby構成にするか
- バックアップを何時に取得するか
- 障害時に何分以内で復旧するか
- ログをどこに出すか
- 監視アラートを誰に通知するか
- セキュリティパッチをどう適用するか
- 本番移行時にどの順番で切り替えるか
利用者から見えるのは、主にアプリケーションです。
しかし、システムが本番で安定して動くかどうかは、基盤設計に大きく左右されます。
ここを理解していないと、システム開発を「画面と機能を作る仕事」だけだと誤解してしまいます。
実際には、システム開発は、アプリケーションとシステム基盤を組み合わせて、業務を動かす仕組みを作る仕事です。
ここまでで、システム開発が「プログラミングだけでは終わらない」ことは、かなり見えてきたと思います。
ここから先が、システム開発の本当の現場です。
RFPの曖昧な要件をどう具体化するのか。ログ保管期間ひとつで、なぜストレージコストが跳ねるのか。機能は動いているのに、なぜ運用テストで止まるのか。移行データに「存在しない日付」が入っていたら、どう扱うのか。
こうした話は、教科書的な説明だけではなかなか見えてきません。
後編では、各工程で初級SEがどこを見ればよいのか、現場の落とし穴を具体的に整理しています。
【後編】システム開発の流れを現場目線で理解する｜要件定義・テスト・移行・運用保守のリアル
コメント