はじめに
SEを目指すとき、「まずはプログラミングを覚えなければ」と考える人は多いと思います。
Java、Python、JavaScript、SQLなどを理解することは重要です。プログラムがどのように処理され、アプリケーションがどう動いているのかを理解するうえで、プログラミングの知識は大きな武器になります。
実際のシステム開発では、プログラムが正しく動くだけではシステムは完成しません。
たとえば、業務システムに「申請する」というボタンを1つ追加するとします。利用者から見えるのは、そのボタンと処理結果だけです。
設計する側では、誰が申請できるのか、誰が承認するのか、データをどこへ保存するのかを決めます。それだけではなく、アクセスが集中しても必要な性能を維持できるのか、サーバが故障しても業務を継続できるのか、障害を誰が検知するのか、データをどこまで復旧できるのか、本番稼働後に誰が運用するのかまで考える必要があります。
画面や機能の裏側では、アプリケーション、サーバ、データベース、ネットワーク、セキュリティ、性能、監視、バックアップ、ジョブ、移行、運用など、多くの仕組みが連動しています。
システム開発とは、単にプログラムを書くことではなく、業務を継続して動かせる仕組みを作り上げる仕事です。
この記事では、これからSEを目指す人や、システム開発に携わり始めて全体像を整理したい人に向けて、アプリケーションとシステム基盤、機能と非機能がどのように組み合わさって一つのシステムを成立させているのかを整理します。
システム開発の目的は「ITを作ること」ではない
システム開発の目的は、プログラムやサーバを作ることそのものではありません。
企業や組織がシステムを導入する背景には、業務上の目的があります。
- 売上を増やす
- 業務を効率化する
- 人手不足を補う
- 入力ミスや処理ミスを減らす
- 顧客への対応を早くする
- 情報を安全に管理する
- 老朽化したシステムを更改する
- 障害に強い仕組みにする
- 将来の利用者やデータの増加に対応する
たとえば、紙で行っていた購入申請をWebシステムへ置き換えるとします。
利用者が申請を登録し、承認者へ通知し、承認結果と履歴を保存する。ここまではアプリケーションの機能として比較的分かりやすい部分です。
本番システムとして成立させるには、その業務を何時から何時まで利用できるようにするのか、月末の申請集中に耐えられるのか、障害時にどこまで業務を継続するのか、承認履歴を何年間保存するのかといった条件まで決める必要があります。
つまり、システム開発では、業務上の目的をアプリケーションの機能へ変換すると同時に、それを本番で使い続けられる仕組みまで作ることが求められます。
「機能が動く」と「本番で使える」は違う
システム開発でまず押さえておきたいのが、「機能が動く」ことと「本番で使える」ことは違うという点です。
申請画面でボタンを押し、DBへ正しくデータが登録されたとします。
機能としては正常です。
本番で利用できるかを判断するには、さらに別の観点が必要です。
- 1人なら動く処理が、1,000人同時でも必要な性能を維持できるか
- 画面応答に10秒かかった場合、業務として許容できるか
- 月末に処理が集中しても耐えられるか
- サーバやDBが停止した場合、業務を継続・復旧できるか
- 夜間バッチが翌朝の業務開始までに終了するか
- 障害を監視で検知し、必要な担当者へ通知できるか
- バックアップから必要な時間内にデータを戻せるか
- 本番移行に失敗した場合、旧システムへ切り戻せるか
この違いは、性能試験でもよく表れます。
通常の業務画面をJMeterなどで負荷試験し、必要なレスポンスが出ていたとしても、それだけで本番性能を確認したことにはなりません。
リリース直後に多数の端末が一斉にアプリケーション資材をダウンロードすれば、Webサーバ、ネットワーク帯域、メモリ、接続数など、通常の業務処理とは異なる場所がボトルネックになることがあります。
たとえば、画面表示に必要なファイルを多くの利用者が一斉に読み込む場合や、アプリの更新ファイルを一斉に配布する場合、キャッシュが効かず元のサーバへアクセスが集中する場合なども、同じように通常業務とは異なる負荷が発生します。
性能を見るときも、「特定の処理が速いか」ではなく、本番で発生する利用パターン全体を見る必要があります。
機能試験で正常に動いていても、本番で必要な性能、可用性、復旧性、運用性を満たさなければ、システムとして十分とはいえません。
非機能要件は「本番で使える水準」を決める
ここで重要になるのが、非機能要件です。
機能要件が「システムで何ができるか」を決めるのに対し、非機能要件は、その機能をどの水準で提供し、どのような条件で運用するかを決めます。
| 観点 | 具体的に決めることの例 |
|---|---|
| 性能 | 画面応答時間、処理件数、バッチ完了時刻 |
| 可用性 | 稼働時間、冗長化範囲、障害時の業務継続 |
| 復旧性 | 復旧時間、復旧可能なデータ時点、バックアップ方式 |
| 拡張性 | 利用者数やデータ量が増えた場合の対応 |
| 運用性 | 監視、ジョブ、ログ、定常作業、障害対応 |
| 保守性 | パッチ適用、設定変更、バージョンアップ |
| セキュリティ | 認証、認可、暗号化、監査ログ |
| 移行 | データ移行、切替時間、切り戻し方法 |
利用者は、普段こうした仕組みを意識することはあまりありません。
本番で問題が起きたときに初めて、「画面が遅い」「システムが止まった」「障害に気づけなかった」「バックアップはあるのに戻せない」「移行したらデータが合わない」といった形で表面化します。
これらは必ずしもプログラムのバグではありません。要件定義、システム基盤、運用設計、移行設計などで決めるべき条件が不足していたことが原因になる場合もあります。
非機能は、利用者から見えにくいから重要ではないのではなく、見えにくいままシステム全体を支えている領域です。
機能要件と非機能要件の違いについては、以下の記事でさらに詳しく整理しています。
システム開発は複数の専門領域で成り立っている
「SE」と一括りにされることがありますが、実際のシステム開発には多くの役割があります。
業務要件を整理する人、画面や業務ロジックを設計する人、プログラムを書く人、データベースを設計する人、サーバやクラウドを設計する人、ネットワークを構築する人、監視やバックアップを設計する人、本番移行を計画する人、プロジェクト全体を管理する人。
大規模なシステムでは、これらを一人で担当するわけではありません。複数の専門チームが役割を分担しながら、一つのシステムを作ります。
たとえば、アプリケーション側で「月末に10万件のデータを短時間で処理する」という方式を設計した場合、その条件はアプリケーションチームだけの話ではありません。
DBが処理できるのか、CPUやメモリは足りるのか、ネットワーク転送量に問題はないのか、夜間バッチの実行時間内に終わるのか、バックアップと競合しないのかまで確認する必要があります。
各担当者が自分の範囲だけで最適な設計をしても、領域間の前提条件が合っていなければ、システム全体では成立しないことがあります。
SEの職種や担当領域については、以下の記事で詳しく整理しています。
アプリケーションとシステム基盤は別々には設計できない
利用者が直接操作するのは、主にアプリケーションです。
画面、帳票、検索、申請、承認といった機能は目に見えます。
システム基盤は、そのアプリケーションを本番で動かし続けるための土台を作ります。
たとえば、申請ワークフローを作る場合、アプリケーション側では申請画面、承認ルート、差戻し、履歴、通知などを設計します。
システム基盤側では、Web/AP/DBの構成、サーバ台数、冗長化、ネットワーク、ストレージ、バックアップ、監視、ログ、ジョブ、セキュリティなどを設計します。
この2つは別々に存在するものではありません。
アプリケーションが大量のファイルを保存するなら、基盤側には十分なストレージが必要になります。大容量ファイルをアップロードするなら、通信帯域やタイムアウト値にも影響します。
大量のDB接続を行う設計なら、DB側の接続上限やメモリ設計に影響します。24時間365日利用する業務なら、サーバの冗長化だけでなく、パッチ適用やバックアップをサービス停止なしで実施する方法まで考えなければなりません。
逆方向の制約もあります。
DBやクラウドサービスの仕様上、アプリケーションが想定した方式を実現できないことがあります。利用できる停止時間やコストの制約によって、アプリケーション方式を変更することもあります。
アプリの要求が基盤設計を決め、基盤の制約がアプリ設計へ戻ってくる。
システム開発では、このやり取りを繰り返しながら全体を成立させていきます。
アプリケーションエンジニアが、業務要件をどのように仕様へ落とし込み、設計・開発・テスト・障害対応まで関わるのかについては、以下の記事で詳しく整理しています。
システム基盤エンジニアは「サーバを作る人」ではない
システム基盤エンジニアやインフラエンジニアというと、「サーバを構築する人」というイメージを持つかもしれません。
構築作業も仕事の一つですが、本質はそこではありません。
システム基盤では、アプリケーションを本番で安定して動かすために、性能、可用性、復旧、セキュリティ、監視、バックアップ、運用、保守、移行、将来の拡張まで考えます。
利用者がシステム基盤の構成を意識することは、ほとんどありません。それでも、実際に求めているのは次のようなことです。
- 業務時間中は止まらないでほしい
- 遅くて使えないのは困る
- 障害が起きたら早く復旧してほしい
- データは失わないでほしい
- 個人情報は守ってほしい
- 運用担当者が対応できる仕組みにしてほしい
- 将来、利用者が増えても使い続けたい
これらをシステムの構成や設定、運用方式へ落とし込むのが、システム基盤設計の役割です。
たとえば、「サーバを2台にして冗長化した」というだけでは可用性を設計したことにはなりません。
1台が停止したときに自動的に切り替わるのか。アプリケーションやDB接続は正常に継続できるのか。監視は障害を検知できるのか。故障したサーバを交換・再作成したあと、どのようにサービスへ戻すのか。
バックアップについても、取得できているだけでは不十分です。
何をバックアップするのか、どの時点まで復旧するのか、何世代残すのか、どこへ保管するのか、リストアにどれくらい時間がかかるのか、実際に戻せることを試験しているのかまで考えます。
システム基盤の仕事は、正常時の構成を作るだけでなく、「止まったとき」「戻すとき」「変更するとき」まで設計することです。
システム基盤エンジニアの役割については、以下の記事で詳しく整理しています。
システム開発は「作る」前後にも工程がある
システム開発全体を単純化すると、次のような流れになります。
図 決める → 設計する → 作る → 確認する → 切り替える → 改善する
この流れを見ると、プログラミングはシステム開発全体の一部分であることが分かります。
その前には、何を作るのか、どの水準で動かすのかを決める工程があります。作った後には、正しく動くかを確認し、本番へ切り替え、その後も運用しながら改善していく工程があります。
業務系システム開発の工程名に置き換えると、次のようになります。
図 要件定義 → 基本設計・詳細設計 → 開発・構築 → テスト → 移行 → 運用保守
工程名を暗記することが重要なのではありません。
ある工程で決めたことが、次の工程の前提条件になるという点が重要です。
要件定義で曖昧だった条件は設計で判断できず、設計で残した抜けはテストや移行で表面化します。運用を考えずに設計したシステムは、本番稼働後に手順や監視、復旧方法が不足します。
現場で資料や会議の内容を見たときに、「これは要件定義で決める話なのか」「詳細設計で具体化する話なのか」「テストで確認する話なのか」と位置づけられるようになると、プロジェクト全体が見えやすくなります。
システム開発を全体で見るための3つの視点
システム開発では、個別の技術や担当作業だけを見ていると、全体のつながりが見えにくくなります。
まずは、次の3つの視点を持つと、アプリケーション、システム基盤、各開発工程の関係を捉えやすくなります。
1. 「何を作るか」だけでなく「どの水準で使うか」を見る
機能だけでなく、性能、可用性、復旧、セキュリティ、運用まで見る習慣を持ちます。
「動いたから完了」ではなく、本番で使い続けられるかまで考えることが重要です。
2. 自分の担当と隣の領域の境界を見る
アプリケーション、基盤、DB、ネットワーク、運用は互いに影響します。
すべての専門技術を自分で実装できる必要はありません。自分が決めた仕様が、隣の担当者に何を要求するのかを考えられることが重要です。
3. いまプロジェクトのどこにいるのかを見る
同じ論点でも、要件定義で決めるべきことと、詳細設計で具体化することは異なります。
会議や設計書を見るときに、今は何を決める工程なのか、その結果が次にどこへ渡るのかを考えると、システム開発全体を理解しやすくなります。
まとめ：システムはプログラムだけでは成立しない
プログラミングは、システム開発を支える重要な技術です。
それだけでシステム開発が完結するわけではありません。
業務上の目的を整理し、必要な機能を設計し、それを支えるサーバ、データベース、ネットワークを構築する。性能や可用性、セキュリティ、バックアップ、監視、運用まで設計し、テストで成立性を確認して、本番へ移行する。
こうした複数の領域と工程がつながって、初めてシステムとして利用できます。
すべての領域を最初から深く理解する必要はありません。
まずは、自分が担当している技術や作業が、システム全体のどこにあり、前後の工程や他の専門領域とどうつながっているのかを見ることが重要です。
この全体像が見えるようになると、プログラミング、DB、ネットワーク、クラウド、テスト、運用といった個別の知識が、ばらばらの技術ではなく、一つのシステムを成立させるための要素としてつながってきます。
システム開発の各工程を、さらに現場目線で見る
ここから先が、システム開発の本当の現場です。
RFPの曖昧な要件をどう具体化するのか。ログ保管期間ひとつで、なぜストレージコストが跳ねるのか。機能は動いているのに、なぜ運用テストで止まるのか。移行データに「存在しない日付」が入っていたら、どう扱うのか。
こうした問題は、要件定義、設計、テスト、移行、運用という工程が独立していると考えていると見えにくくなります。
前工程で残った曖昧さや設計上の判断が、後工程でどのように手戻りとして表面化するのか。次の記事では、各工程のつながりを実際の現場で起きる問題と合わせて整理しています。
システム開発の設計工程をさらに詳しく知りたい方は、以下の記事も参考にしてください。
コメント