目次 - Lesson9

カリキュラムの改善要望はこちら

Lesson9

システム開発の流れ

Lesson 9Chapter 1
学習の目標

このレッスンでは、システム開発の流れを取り上げます。

システム開発は、コンピュータやネットワークといった基礎技術を踏まえたうえで、ビジネスに求められる機能を設計・実装し、継続的に運用・保守していく一連のプロセスです。

ウォーターフォールモデルやアジャイル開発など、開発手法によって作業手順や管理の仕方は異なりますが、いずれもプロジェクトマネジメントやチーム協力が欠かせません。

ここでは、これらのフェーズがどのように連動し、どこに注意すべきポイントがあるのかを整理します。

本レッスンの主な内容

システム開発とは
ウォーターフォールモデル
アジャイル開発
システム開発の各フェーズ
プロジェクト管理とチーム協力
システムの運用と保守

本レッスンのゴール

システム開発における主要フェーズの流れや役割を理解すること

本レッスンの前提条件

ビジネスパーソンに必要なITスキルを把握していること（レッスン1）
コンピュータの中身について正しいイメージを持っていること（レッスン2）
ネットワークとインターネットの基本的な仕組み、関連技術、およびそれらがどのようにつながり合っているかを正しく理解していること（レッスン3）
情報資産を守るための情報セキュリティの基本概念と3要素、リスク評価、脅威・対策技術、法規制を正しく理解していること（レッスン4）
アルゴリズムとプログラミングの基礎、システムとプログラムの関係を正しく理解していること（レッスン5）
データベースの基礎や設計・運用の考え方、SQLの基本を理解し、ビジネスでのデータ活用をイメージできること（レッスン6）
クラウドの特徴や利点、リスク、運用方法を理解し、ビジネスにおけるクラウド活用をイメージできること（レッスン7）
テクノロジーがどのように社会やビジネスを支え、今後の可能性を広げるのかを理解していること（レッスン8）

Lesson 9Chapter 2
システム開発とは

システム開発 は、企業や組織が抱える「ビジネス課題の解決」を行なうための仕組みを設計し、構築する取り組みです。

対象となる「システム」はさまざまです。

受発注管理を効率化する販売管理システム
データ分析基盤を整えるBIシステム
オンラインショッピングを支えるECサイトシステム、等々

システムの活用イメージ

ビジネスにおいてシステム開発がどのような意味合いを持ち、どのような工程をたどるのか、全体像を整理しましょう。

Lesson 9Chapter 2.1
システム開発の目的

システム開発の目的には、以下のようなものがあります。

業務効率化・コスト削減
- 受発注管理や在庫管理など、既存の業務フローを最適化し、人的コストやヒューマンエラーを削減します。
- RPA（Robotic Process Automation）やAIツールを活用し、定型・反復業務を自動化してコア業務に集中できる環境を整えます。
情報活用・データ分析
- BI（Business Intelligence）システムやデータウェアハウスの構築によって、蓄積されたデータを可視化し、経営判断やマーケティングの精度を高めます。
- 大量のデータをリアルタイムに分析し、意思決定に役立てる「データドリブン経営」の基盤を整えます。
顧客接点の拡大
- ECサイトやモバイルアプリなど、オンラインで顧客とやり取りできるシステムを構築し、新規顧客の獲得やリピート率向上を目指します。
- レスポンシブデザインや多言語対応など、ユーザビリティを向上させるための工夫が欠かせません。
新規ビジネスの創出
- AIやクラウドサービスといった最新技術を取り入れ、これまでになかったビジネスモデルを開発・運用することも大きな目的の1つです。
- 社内システムだけでなく、顧客向けのサービスやプラットフォームを構築し、新たな収益源を創り出す可能性があります。

いずれの目的も、根底にあるのは「ビジネス課題の解決」です。

そこで最初に、ビジネスパーソンがこれらのビジネス要件を明確にし、必要に応じてエンジニアなどの専門家と協力して実現方法を検討します。

そのうえで、市販のソフトウェアにはないカスタマイズ性や競争優位性、業務要件へのフィット感などが求められる場合に、「システムを開発する」という手段を選択することになります。

Lesson 9Chapter 2.2
ビジネス要件とシステム要件

システム開発に求められる要件には、「ビジネス要件」と「システム要件」の2つの観点があります。

ビジネス要件 ：何を達成したいか（組織が実現したい目標や成果指標）
システム要件 ：それをどう作るか（ビジネス要件を技術的に満たすための機能や性能、環境条件など）

ビジネス要件

ビジネス要件 とは「何を達成したいか」、組織が達成したい目標や成果指標を指します。ビジネス要件の例としては、以下のような項目が挙げられます。

売上向上やコスト削減：ECサイトでの売上を増やす、在庫管理を最適化して費用を減らす
業務プロセスの効率化：受発注処理時間を半分にする、問い合わせ対応の時間を削減する
顧客満足度の向上：レスポンス速度の向上やUIの使いやすさによる離脱率低下

システム要件

システム要件 とは「それをどう作るか」、ビジネス要件を技術的に満たすための具体的な機能や性能、環境面の条件を示します。

システム要件は、「機能要件」と「非機能要件」で構成されます。

機能要件 は、システムが「何をできるようになるか」を定義する要件です。具体的には、ユーザー登録やログイン、データ検索、注文処理など、システムが提供すべき機能や動作を明確に示します。

機能要件の例：

ユーザー登録機能：新規ユーザーをメールアドレスとパスワードを使って登録し、登録完了メールを送信する。
商品検索機能：商品名やカテゴリ、価格帯などで検索し、複数の候補が一覧表示されるようにする。
注文管理機能：カートに入れた商品の合計金額を計算し、在庫の引き当てを行ない、注文情報をデータベースに保存する。

非機能要件 は、「機能をどのように提供するか」や「システム全体の品質」を示す要件です。機能の実現方法や性能、運用時のセキュリティレベル、システムの可用性、拡張性などが該当します。

非機能要件の例：

性能要件：高負荷時でも1秒以内に検索結果を返すことができる処理速度を保証する。
可用性要件：システム稼働率を年間99.9%以上とし、障害発生時の自動復旧を実施する。
セキュリティ要件：すべての通信をHTTPSで暗号化し、認証情報は平文で保存しない。ログイン時に多要素認証を導入する。

ビジネス要件とシステム要件の橋渡し

システム開発を成功に導くためには、「ビジネス要件」と「システム要件」の橋渡しを正しく行なうことが不可欠です。

両者がかみ合わなければ、開発終了時に「本来やりたかったこととは違うシステムが完成した」という事態が起こりかねません。

橋渡しを上手に行なうためには、ビジネスパーソンとエンジニアなどの専門家との役割分担、および適切な工程や開発手法の選択が重要になります。

Lesson 9Chapter 2.3
役割分担

システム開発は、ビジネスパーソンとエンジニアが協力して行なうことが一般的です。ビジネスパーソンがビジネス要件を整理し、エンジニアはそれらをもとにシステム要件を整理、設計することになります。

ここで、両者の役割について、整理しておきましょう。

ビジネスパーソンの主な役割

ビジネス要件の定義・調整
- 目的・ゴールの明確化
  何を実現したいのか、なぜそれが必要なのか、といったビジネス側の視点から要件をまとめます。
- 利害関係者との折衝
  経営層、各部署（営業、マーケティング、人事など）の要望を集約し、優先順位を整理。エンジニアと合意形成を図りながら、システム開発の方向性を決めます。
プロジェクトマネジメント（PM・PMO など）
- スケジュール・予算・リソース管理
  システム開発に必要な期間や予算、人員などを把握し、プロジェクト全体の進捗を管理します。
- リスク管理・品質管理
  要件変更や技術的課題が起きた際のリカバリープランを検討し、スムーズなプロジェクト進行をサポートします。
ビジネス視点での検証・評価
- ユーザー視点やROIの検討
  開発したシステムが、実際の業務にどれだけ貢献するか、費用対効果が見合うかなどを評価します。
- 導入・運用サポート
  リリース後の運用体制を整え、現場への教育やマニュアル整備などを主導して、システムの定着を促します。

エンジニアの主な役割

技術要件の設計・実装
- アーキテクチャ設計
  システムの構成や使用する技術スタック（プログラミング言語、データベース、インフラなど）を検討し、最適な形を提案・設計します。
- 詳細設計・コーディング
  要件定義や基本設計をもとに、具体的なプログラムを実装。機能ごとに適切なデータ構造やアルゴリズムを設計します。
テスト・品質保証
- 単体テスト・結合テスト・総合テスト
  実装したコードが要件通りに動作するか確認し、不具合や仕様の食い違いを洗い出して修正。
- 運用・保守フェーズでの技術サポート
  リリース後に生じた不具合対応や、システムのパフォーマンスチューニング、定期的なバージョンアップ作業などを行ないます。
技術革新・最新動向のキャッチアップ
- 新しいツールや開発手法の導入提案
  アジャイル開発やクラウドネイティブ、DevOpsなど、プロジェクトに効果的な手法を検討し、導入をサポート。
- 将来的な拡張性・スケーラビリティの確保
  ビジネス成長に伴う利用ユーザー数やデータ量の増加を見据え、システムが拡張しやすい設計を心がけます。

Lesson 9Chapter 2.4
システム開発のフェーズ

システム開発は、大きく以下のフェーズに分けられます。

要件定義
ステークホルダー全員の声を集約し、どんなシステムを作るかを決めます。機能やデータの構成、操作イメージ、セキュリティ方針などを固め、開発範囲や期間、予算の目安を設定します。
設計
要件定義で決まった内容をもとに、システムの構造を具体化します。アーキテクチャの選定やデータベース設計、各画面の仕様など、開発チームがコーディングできるレベルまで落とし込みます。基本設計と詳細設計に分けることが多く、大規模なプロジェクトではドキュメント量が膨大になります。
実装
コーディングや設定、構成管理など、実際に手を動かしてソフトウェアを形にします。プログラミング言語やフレームワークなどの技術選定がプロジェクトの成功を左右します。開発チーム内のコードレビューや自動テストなどの品質管理も重要です。
テスト
開発した機能が設計どおりに動作するか、単体テストや結合テスト、総合テスト、ユーザー受入テストなど複数の段階で検証します。たとえば、利用者の業務シナリオに沿ったテストを行ない、本番環境で想定される操作を再現します。ここで課題を早期発見できれば、リリース後のトラブルを減らせます。
リリース
本番環境にシステムを導入します。利用者や顧客への周知、切り替え手順の策定、ダウンタイム対策などを検討します。大規模システムではリリースに伴うリスクが高いため、綿密な計画が必要です。
運用・保守
リリース後も不具合修正や機能追加、セキュリティ更新を随時行ないます。実際に運用してみると、新たな要望が発生することも多く、運用部門と開発部門が連携して定期的にシステムを改善します。

これらの工程を順序どおりに進める代表的な開発手法が「ウォーターフォール」であり、短いサイクルで計画・実装・テストを繰り返す方法が「アジャイル」です。いずれも要件定義から運用までの流れは同じですが、その進め方に違いがあります。詳しくは次のチャプターから説明します。

Lesson 9Chapter 2.5
製造業における生産方式とシステム要件

製造業向けのシステム開発を考える場合、どのような生産方式を採用しているかが要件定義や設計に大きく影響します。

受注生産：顧客からの注文を受けてから製造を始めるため、在庫リスクは低いが納期管理が重要。
見込み生産：需要予測に基づいて製品を先行生産し、在庫を確保しておく方式。予測精度や在庫管理システムが鍵となる。
JIT（Just In Time）生産方式：必要なモノを必要なときに必要な量だけ作る方式で、在庫圧縮とスピーディーな工程連携が求められる。
ライン生産方式：ベルトコンベアなどで工程を直列に配置し、大量生産に向いた生産方式。タクトタイム管理や設備稼働率の可視化が重要。
セル生産方式：1人または少人数のチームが製品の大部分を組み立てる方式で、多品種小ロット生産に対応しやすい。作業者のスキル管理や生産計画の柔軟性が求められる。

これらの生産形態を踏まえると、受発注管理や在庫管理、設備稼働状況のリアルタイム把握といった機能がシステム要件として求められます。要件定義の段階で現場の生産方式を明確に把握しておくことで、無理のないシステム設計を行ないやすくなります。

Lesson 9Chapter 3
ウォーターフォールモデル

ウォーターフォールモデル は、システム開発で長く用いられてきた伝統的な開発手法の1つです。

各工程を滝（ウォーターフォール）のように順番に進めていくことから、この名称で呼ばれています。要求定義から設計、実装、テスト、運用・保守へと一方向に流れるように作業が進行するため、開発プロセスを見通しやすい点が特徴です。

一方で、途中の工程を後から見直すことを前提としていないため、要件変更が頻繁に発生するケースなどに対しては、十分な柔軟性を確保しにくいという意見もあります。

近年はアジャイル開発などの手法が注目されていますが、ウォーターフォールモデルも依然として大規模な開発プロジェクトや公共事業など、明確な要件が求められるシーンでよく利用されています。

ここでは、ウォーターフォールモデルがどのような工程をたどり、どのようなメリットやデメリットを持つかを整理しながら説明します。

Lesson 9Chapter 3.1
ウォーターフォール開発の流れ

ウォーターフォールモデルでは、開発工程を明確に区切り、それぞれの工程が完了した段階で次の工程へと移行します。一般的には、以下のような流れでプロジェクトを進めます。

要求定義
最初に行なうのが、システムに求められる機能や性能を確定する要求定義です。ユーザーや顧客、関係部署からヒアリングを行ない、仕様や利用条件、予算や納期などの制約を明文化します。ここで合意した内容が、後の工程すべてに影響するため、慎重な検討と合意形成が欠かせません。
基本設計（外部設計）
要求定義をもとに、画面レイアウトや入出力の形式、データの流れなど、システムの大まかな構造を設計します。たとえば、ユーザーが利用する画面の項目配置や操作手順、データベースのテーブル一覧などを明確にし、後続の詳細設計に備えます。
詳細設計（内部設計）
基本設計をさらに具体化し、プログラムのモジュール構成や関数の仕様、アルゴリズムなどを定義します。データベースのテーブル構造におけるカラム定義や制約事項、ビジネスロジックの処理手順などを細部にわたって検討し、ドキュメント化します。
実装（コーディング）
設計をもとに、プログラム言語やフレームワークを使ってソースコードを作成します。この段階では、単体テストも同時に進められます。単体テストでは、モジュールやクラスなど、最小単位のプログラムが仕様どおりに動作するかを確認します。
結合テスト
実装された各モジュールを組み合わせて、機能どうしの連携が適切に行なわれるかを検証します。たとえば、ユーザー登録機能とログイン機能を連携させたときに、アカウント情報が正しく処理されるかなどをテストします。
システムテスト
結合テスト後、システム全体が要求定義で決めた要件を満たしているかを総合的に検証します。実際の利用環境に近い条件を整え、性能試験や負荷試験なども行ない、問題がないかを確認します。
運用・保守
システムテストをクリアしたら本番リリースを行ない、ユーザーが利用を開始します。運用開始後は障害対応や機能追加などを継続的に実施し、システムを安定的に稼働させます。ウォーターフォールモデルでは大幅な要件変更を想定していませんが、実際には新機能の要望などが出てくるため、追加開発や改修が行なわれることもあります。

このように工程ごとに明確なゴールを設定し、完了した段階で文書や資料を成果物として残す点がウォーターフォールモデルの大きな特徴です。工程間のレビューがしっかりしているため、品質を高めやすいというメリットがあります。

ただし、開発後期に要件変更の必要性が判明した場合、上流工程に立ち戻るためには多大なコストやスケジュール延長が発生します。これをいかに抑えるかがウォーターフォール開発における重要な課題です。そのため、要求定義の段階でどれだけ不明点を減らし、完成形を明確にしておけるかがプロジェクト成功の鍵を握ります。

Lesson 9Chapter 3.2
ウォーターフォールモデルの特徴、利点と欠点

ウォーターフォールモデルには、伝統的な開発手法として多くの実績があり、大規模プロジェクトや組織のルールが厳格な場合などに適した面があります。具体的に、以下のような特徴、利点と欠点が挙げられます。

特徴

工程の順番が明確
要求定義から運用・保守まで、上流から下流へと順序がはっきりしています。プロジェクト計画が立てやすく、各工程の成果物を見積もることが比較的容易です。
文書化が重視される
各工程の成果物を詳細に文書化するため、品質管理をしっかり行ないやすいです。大人数での開発やメンバー交代があっても、ドキュメントをもとに情報を共有できます。

利点

進捗管理がしやすい
工程ごとに必要な作業が明確に定義されているため、現在の進捗やスケジュールの遅れを把握しやすいです。特に大規模開発や官公庁プロジェクトでは、管理部門による厳密な進捗管理を求められることが多いです。
品質保証が組み込みやすい
各工程でレビューを実施し、ドキュメントを整備するため、品質チェックを厳格に行ないやすいです。後々のフェーズで不具合が見つかりにくくなり、トラブルを早期に発見できます。
大規模プロジェクト向き
要件が明確かつ変更も少ない状況であれば、ウォーターフォールモデルは長所を最大限に発揮できます。国や自治体、金融機関など、重要な基幹システムの開発でしばしば採用される理由の1つです。

欠点

要件変更に弱い
途中の工程で仕様変更が発生した場合、上流工程に戻って作業をやり直す必要があります。これによるコストやスケジュールの見直しが大きくなるため、柔軟な変更対応が難しいです。
プロトタイピングが難しい
完成イメージをつかむための試作品を早期に用意する文化が根付きにくいです。要件定義の段階で利用者の感覚をつかみにくく、後になってから機能の不足や使い勝手の問題が判明しやすいです。
リリースまでの時間が長い
要求定義から運用開始までの流れが一方向で、各工程の検討も入念に行なうため、実際にユーザーがシステムを利用できるまでに時間がかかる傾向です。市場や技術トレンドの変化に対応しづらい側面があります。

ウォーターフォールモデルをうまく活用するには、要求定義や設計段階でできる限り不明確な点をつぶし、手戻りのリスクを減らす必要があります。また、必要に応じてユーザーインタビューやプロトタイプ作成、受け入れテストを繰り返すなど、要件の確実性を高める工夫が重要です。プロジェクトにおけるステークホルダーの巻き込みや合意形成も早めに行ない、開発方針を固めておくことで、トラブルを最小限に抑えることができます。

ウォーターフォールモデルは、長年の実績や標準化された手順が存在し、上流工程から品質を確保していく形を重視します。安定した要求と長期的な視点でシステムを構築する場合に有効ですが、頻繁な要件変更や短い開発サイクルが求められる現場では、後述するアジャイル開発の考え方も参考にする必要があります。

Lesson 9Chapter 4
アジャイル開発

アジャイル開発 は、短いサイクルで機能を開発し、利用者や顧客からのフィードバックを素早く取り入れることで、継続的にシステムを改善していく開発手法です。

ウォーターフォールモデルが要求定義から運用・保守までを一方向に進めるのに対し、アジャイル開発ではイテレーション（反復）という単位で設計・実装・テストなどを小規模に繰り返します。要件が変化しやすいプロジェクトや、早い段階で利用者が触れるプロトタイプを求める現場において、その柔軟性が重宝されます。

実際、競争の激しいWebサービスやスマートフォンアプリの開発などでは、リリースサイクルを短縮しながらユーザーニーズに合わせて機能を追加していく手法が求められています。

アジャイル開発を成功させるためには、開発チームの自律性やコミュニケーションが不可欠であり、スクラムなどの具体的なフレームワークを導入することで、プロジェクトの進行を効率的に管理できます。

Lesson 9Chapter 4.1
基本概念とアジャイルの原則

アジャイル開発は、2001年に発表された「アジャイル宣言」で示された考え方を起源としています。

アジャイル宣言では、人やコミュニケーションを重視し、変化への柔軟な対応を可能にする姿勢が強調されています。

ウォーターフォールモデルのように長期で大規模な計画を詳細に立てるのではなく、短い期間ごとに計画を立て、実際に機能を作り込んだりテストしたりしながら方向性を微調整していく点に特徴があります。

アジャイル宣言の4つの価値観

アジャイル宣言で示されている4つの価値観は、以下のとおりです。

プロセスやツールよりも、個人と対話を重視する。
チームメンバーの対話や共同作業、意思疎通を優先します。コミュニケーションが円滑になるほど、問題の早期発見や解決が進みやすくなります。
包括的なドキュメントよりも、動くソフトウェアを重視する。
完成度の高いドキュメントを作り込むよりも、まずは動く形で機能を実装し、価値を提供することを大切にします。ただし、全くドキュメントを作らないというわけではなく、必要な範囲に絞った記述を心がけます。
契約交渉よりも、顧客との協調を重視する。
当初の契約事項へ厳密に縛られるのではなく、顧客と継続的に連携しながら要件をすり合わせます。こうすることで、変化の多いプロジェクトでも成果を最大化しやすくなります。
計画に従うことよりも、変化への対応を重視する。
計画どおりに進めることが難しい場合や、新しいアイデアや要望が出てきた場合には、計画の修正を柔軟に受け入れます。市場や技術の変化に対応しやすい体制を持つことが重要です。

アジャイル開発の主な特徴

反復的かつ増分的な開発
イテレーションと呼ばれる短い期間（1〜4週間程度）ごとに開発からテスト、リリースまでの流れを行ない、段階的に機能を拡張していきます。
早期でのユーザー確認
できるだけ早く動くソフトウェアをユーザーや顧客に示し、使用感や機能の不足・不備を確認します。これにより、プロジェクト後半での大掛かりな修正を回避できます。
自己組織化されたチーム
各メンバーが自主的にタスクを取り、連携を取りながら作業を進めます。プロジェクトマネージャーだけでなく、チーム全体でプロセスを改善する意識を持ちます。
継続的な改善
各イテレーションの最後には振り返りを行ない、プロセスやコミュニケーション、品質などを総合的に検討します。これにより、次のイテレーションではさらに効率的な開発が行なえます。

こうしたアジャイル開発の考え方は、頻繁に変化する要件への対応力を高め、高速でのリリースサイクルを実現するための基盤となります。チームメンバーの能力や裁量が大きく求められる一方で、開発スピードと柔軟性の両立を図れるというメリットがあります。

Lesson 9Chapter 4.2
スクラム開発の基本

アジャイル開発のフレームワークとしては、スクラムが最も広く知られています。スクラムでは、一定期間のスプリントと呼ばれる開発サイクルのなかで、優先度の高い課題から着手して機能実装やテストを進めます。担当者やプロセスが明確に定義されており、進捗を「見える化」するための工夫が充実しています。

主要な役割

プロダクトオーナー
プロダクトの方向性や優先順位を決める責任者です。顧客やステークホルダーとの調整を行ないながら、どの機能を先に実装すべきかを判断します。
スクラムマスター
チームがスクラムのプロセスを正しく実践できるようサポートする役割です。障害や課題を取り除くために動き、チームがスムーズに働ける環境を整えます。
スクラムチーム（開発チーム）
自律的に開発とテストを進めるエンジニアやデザイナー、テスターで構成されます。短いスプリントの間で共同作業を行ない、完成度の高い成果物を目指します。

主なイベント

スプリント計画
プロダクトバックログ（実装候補の機能一覧）から、スプリント期間中に完了させるタスクを選定します。各タスクの優先度や難易度を見極め、チームのリソースと照らしあわせてスプリントの目標を設定します。
デイリースクラム
毎日、短い打ち合わせを行ない、進捗や問題点を共有します。各メンバーが「前日やったこと」「今日やること」「困っていること」を簡潔に報告し、チームとしての方向性を確認します。
スプリントレビュー
スプリント終了時に、実装した機能をプロダクトオーナーや関係者にデモンストレーションして評価を受けます。その結果、新たな要望が出たり、既存のタスクの優先度が変わったりするケースもあります。
スプリントレトロスペクティブ
スプリント全体を振り返り、チーム内でうまくいったことや改善点を洗い出します。次のスプリントでは、改善策を取り入れてより良い開発プロセスを目指します。

スクラムでは、開発チームが毎日のデイリースクラムで情報を共有し、問題があればその場で解決を図るため、コミュニケーションロスが最小限に抑えられます。また、スプリントレビューやレトロスペクティブを通じて、顧客や開発チームからのフィードバックを迅速に得られるため、次のスプリントでの修正や新機能追加にスムーズに反映できます。

Lesson 9Chapter 4.3
アジャイルのメリットとデメリット

アジャイル開発は、多くのプロジェクトで採用されるようになってきましたが、すべてのケースに万能であるわけではありません。メリットとデメリットを正しく理解し、適材適所で導入することが大切です。

メリット

顧客満足度の向上
短いスプリントでリリースを繰り返すため、顧客が早い段階からシステムを利用できます。その結果、フィードバックを活かして機能の方向性を修正しやすくなり、プロジェクト終了時の満足度も高くなる傾向があります。
柔軟な対応力
要件変更や技術的な課題が発生しても、次のイテレーションで修正や追加を行ないやすいです。市場やビジネス環境の変化に素早く対応できるため、開発中のリスクを下げられます。
チームのモチベーション向上
自律的な開発チームが意思決定に深く関与できるため、メンバーそれぞれが自分の役割や価値を実感しやすいです。短期間で成果物をリリースし、ユーザーからの反応を得られるため、やりがいを感じられます。
早期の品質向上
イテレーションごとにテストを行ない、機能を本番に近い形で動かすため、不具合や機能不足が初期段階で発見されやすいです。大掛かりな手戻りを抑制できる利点があります。

デメリット

計画の立てにくさ
イテレーションごとに要件や優先度が変わり得るため、長期的なスケジュールやコストの見積もりが難しくなります。顧客や上層部に対して、確定的な納期を示しにくい場合があります。
ドキュメント不足のリスク
動くソフトウェアを重視するあまり、適切なドキュメントが残らないこともあります。特に大人数が関わる大規模システムや、長期間運用されるシステムでは、将来的なメンテナンス性を損なう可能性があります。
チーム力に依存
アジャイル開発は、各メンバーが積極的にコミュニケーションし、意思決定を行なうことを前提としています。メンバーの技術力やチームビルディングが十分でないと、混乱が生じてスケジュールがかえって遅延する場合もあります。
プロダクトオーナーの負荷
スプリントごとに優先度の見直しや要求の調整を行なうため、プロダクトオーナーの責任や負荷が大きくなりやすいです。適切な人材が確保できない場合、顧客との折衝やバックログ管理がスムーズに進まないことがあります。

アジャイル開発は、ウォーターフォールモデルと比べて開発の自由度が高く、短期間で価値を生み出すスタイルに向いています。特にスタートアップや新規サービスの開発、または要求が変動しやすいプロジェクトで有効です。一方で、堅牢な品質管理や厳密なスケジュール計画を求めるプロジェクトには適合しない場合があります。

アジャイルとウォーターフォールは対立概念ではなく、開発内容やチーム文化、プロジェクト規模に応じて使い分けたり、ハイブリッドで取り入れたりする動きも多く見られます。いずれにしても、ユーザーやビジネス環境の変化を見ながら、チームとして適切な開発手法を選択し続ける姿勢が大切です。

Lesson 9Chapter 5
システム開発の各フェーズ

システム開発が失敗なく進むためには、各フェーズで明確な目標を立て、必要な成果物を作り上げることが大切です。

ウォーターフォールモデルやアジャイル開発など、開発手法はさまざまですが、いずれの手法でも押さえておきたい共通点があります。

ここでシステム開発の各フェーズごとに、どのような作業を中心に行なうのか、どんな成果物が必要なのかを確認しましょう。

調達計画と実施
要求定義
設計
実装
テスト
運用・保守

Lesson 9Chapter 5.1
調達計画と実施

システム開発の前の段階として、調達計画と実施があります。具体的には、以下のようなステップで行ないます。

RFI（Request for Information）：まずはベンダーに情報提供を依頼し、市場にどのようなソリューションやサービスがあるかを把握する。
RFP（Request for Proposal）：RFIで得た情報をもとに、要件や予算・納期などを整理したうえで正式に提案依頼を行ない、複数ベンダーから比較可能な提案を受け取る。
契約締結：RFPの内容を精査してベンダーを選定し、契約条件（期間、支払い方法、納品物の範囲など）を取り決めて正式契約を結ぶ。

契約締結後、システム開発の各フェーズが始まります。

Lesson 9Chapter 5.2
要求定義

要求定義 は、開発プロジェクトの全体像を決める最初の工程です。

ユーザーや顧客が何を求めているかを明確にし、そこからシステムに必要な機能や性能、制約条件などを整理します。要求定義の成果物としては、要求定義書 や 要件仕様書 などの文書が代表的です。これらのドキュメントをもとに、チーム全体が同じゴールを共有できるようになります。

要求定義の作業は、ヒアリングやワークショップなどを通じて、現場の課題や業務フロー、期待される効果を洗い出すところから始まります。システムによって解決したい問題が曖昧なままだと、後続フェーズで仕様変更が頻発し、開発コストが大きく膨らむリスクもあります。そのため、要求定義フェーズでは、ユーザーや関係部署から多角的に意見を聞き、最終的な合意を得るまで丁寧に作業を重ねることが重要です。

また、開発するシステムがビジネスにどう貢献するのかを示すために、費用対効果の分析が行なわれる場合もあります。新規システムの導入にかかるコストを正確に試算すると同時に、導入によって得られる効率化や売上増などを試算します。これにより、ユーザーや経営層が導入の判断を下しやすくなります。

要求定義フェーズがスムーズに進むためには、以下のポイントを押さえておくことが大切です。

想定ユーザーの明確化：ターゲットとなるユーザーの属性や利用シーンを洗い出し、優先順位をつけます。
現状課題の把握：既存システムや業務フローで何が問題なのか、どのように解決したいのかを具体的にします。
利用環境の調査：システムを利用するOSやデバイスの種類、ネットワーク環境などを把握し、制約を確認します。
要求項目の優先度：すべての要件を一度に満たそうとすると開発期間やコストが膨大になるため、優先順位を設定します。

こうしたプロセスを踏むことで、開発チームとユーザーが目指すゴールの認識を一致させられます。要求定義の段階で誤りや曖昧さを最小限に抑えておくことは、プロジェクトの成功確率を高めるうえで非常に大きな意味があります。

Lesson 9Chapter 5.3
設計

設計フェーズでは、要求定義で合意された要件をどのように実現するかを具体的に考えます。

設計は大きく分けて、システムの構造や外部から見た振る舞いを定義する 基本設計（外部設計）と、内部の処理ロジックやデータの構造などを詳細に詰める 詳細設計（内部設計）に分類されます。

基本設計

基本設計では、ユーザーに見える部分（画面UI、操作フロー、出力帳票など）や外部システムとの連携方法、データの入出力の形式などを決定します。ここでは、利用者視点での操作性や効率性に配慮しながら、全体的な仕組みをざっくり定義します。

画面レイアウトやUI設計：ユーザーが操作しやすい画面構成やメニュー配置を検討します。
外部インターフェースの定義：他システムやAPIとのデータ連携方式を決めます。REST APIを使うのか、ファイルを取り込む形にするのかなどを検討します。
概念データモデルの策定：システムで扱うデータの種類や関連性を整理し、ER図などの形で可視化します。

詳細設計

基本設計をさらに細分化し、プログラムレベルの処理手順を定義するのが詳細設計です。データベースのテーブル定義（カラム名、型、制約など）や、機能ごとのビジネスロジックをフローチャートや疑似コードで表現するなど、技術的に明確な指示が示されます。

テーブル設計：列の型や制約条件（NOT NULL、UNIQUEなど）を詳細に決めます。
ビジネスロジックの定義：画面から受け取った入力をどのように加工してDBに格納するか、どのタイミングで外部APIを呼び出すかなどを決めます。
モジュール分割：システムを複数のモジュールに分割し、関数やクラスの責務を明確化します。単体テストの視点を意識した設計が望まれます。

設計フェーズでしっかりと仕様を固めることで、実装フェーズでの混乱や手戻りを抑えることができます。ただし、アジャイル開発などでは、基本設計と詳細設計を細かく区分せず、プロトタイプやスプリントのなかで徐々に設計を洗練させていくアプローチもあります。大切なのは、チーム全体が合意した設計情報を常に最新の状態に保ち、誰もが適切な判断をできるようにしておくことです。

エンジニアリングシステムとCAD/CAM

製造業のシステム開発や製品開発においては、CAD（Computer-Aided Design）やCAM（Computer-Aided Manufacturing）などのエンジニアリングシステムを活用するケースが多くあります。

CAD は製品の設計図や3Dモデルをデジタルで作成し、設計ミスの低減や設計変更への迅速な対応を可能にします。

CAM はCADのデータをもとに実際の工作機械を制御し、生産工程を自動化・効率化する仕組みです。

さらに、コンカレントエンジニアリング（同時並行開発）の考え方を取り入れると、設計と製造、品質管理などの工程を同時進行で進められます。これにより、リードタイム短縮や品質向上が期待できます。システム開発では、このように設計フェーズでCADやCAMを使って製造情報と設計情報を一元管理することで、生産現場との連携をスムーズにすることが重要です。

Lesson 9Chapter 5.4
実装

実装フェーズでは、設計で定義された仕様に基づき、プログラミング言語やフレームワークを使用してコードを書く作業を中心に進めます。

必要に応じてUIデザインや画像素材の作成、コンテンツの準備なども行なわれ、実際のシステムを形にしていきます。ウォーターフォールモデルの場合は、設計書に書かれた仕様をほぼそのまま実装するのが一般的ですが、アジャイル開発ではイテレーション単位で機能をコーディングし、テストを経てリリースサイクルを回すこともあります。

開発環境の整備

実装を開始する前に、ソースコードを管理するリポジトリやCI/CD（継続的インテグレーション/継続的デリバリー）の設定、開発用サーバーの構築などを行ないます。これらを整備しておくことで、チーム全員が同じ開発環境を共有でき、バージョン管理やテストの自動実行がスムーズに進みます。

コーディングと単体テスト

コーディングは、詳細設計で決めた手順やデータ構造をコードに落とし込む作業です。コードレビューの文化があるチームでは、プルリクエストを使ったレビューを行ない、品質を高めます。同時に、モジュール単位で「単体テスト」を実施し、仕様どおりに動作しているかを確認します。

単体テスト：小さな機能ごとにテストを行ない、不具合があれば早めに修正します。
テスト自動化：テストフレームワークを使って自動化テストを構築し、コミットごとにテストが走るよう設定するケースもあります。
継続的インテグレーション：チームのメンバーが書いたコードをリポジトリへマージするたびに自動でビルドやテストを実行し、問題の早期発見につなげます。

実装フェーズでは、要件定義や設計で取り決めた方針を守りながら、コードの可読性や拡張性にも配慮する必要があります。短期的には仕様を満たせるコードでも、保守性が低い実装では後のフェーズでトラブルを招きやすいです。開発チーム全体でコーディング規約やアーキテクチャのガイドラインを共有し、一定の品質を維持することが重要です。

Lesson 9Chapter 5.5
テスト

テスト フェーズでは、システム全体が期待通り動作するかを検証します。

アジャイル開発ではイテレーションごとにテストを行なうため、テストフェーズと実装フェーズが重なることもありますが、いずれにしても最終的にシステムをリリースする前には十分なテストが欠かせません。

単体テスト

単体テスト は、モジュール単位で仕様どおりに動作しているかを確認するテストです。前述のとおり、コーディング作業とあわせて行ない、自動化テストも多く採用されています。

結合テスト

結合テスト は、単体テストが終わったモジュール同士を組み合わせて、機能の連携が正しく動作しているかを確認するテストです。

たとえば、ユーザー管理機能と認証機能を連携させ、ユーザー登録直後にログインできるかを検証するなどが該当します。想定していない連携パターンが生じる場合もあるため、複数のシナリオを用意してテストを実施します。

システムテスト

システムテスト は、システム全体を実際に動かし、要求定義で定められた要件を満たしているかを総合的に確認するテストです。

ユースケースベースでテストシナリオを作り、使い勝手やパフォーマンス、セキュリティなどを多角的に検証します。外部システムとの連携が必要な場合は、実際に通信を試すか、テスト用のモックサーバーを用意することが一般的です。

受け入れテスト

受け入れテスト は、顧客や利用者が実際の利用環境に近い条件でシステムをテストするものです。

操作性や表示内容など、細部まで要求を満たしているかを確認し、最終的なリリース可否を判断します。この段階で重大な不具合や要求の食い違いが見つかると修正に手間がかかりますが、ウォーターフォールモデルの場合はこの工程での変更が難しく、アジャイル開発では比較的スムーズに修正しやすい傾向があります。

受け入れテストに問題がなければ「検収」となります。

検収：ベンダーの納品物が要求仕様を満たしているか、実際に受け入れテストなどを行ない、問題がなければ納品を完了させる。その後、代金支払い処理に進む。

Lesson 9Chapter 5.6
運用・保守

運用・保守 は、システムのリリース後、長期間にわたり安定したサービスを継続するためのフェーズです。

ここでは、システムの監視や障害対応、機能追加などを行ないながら、ビジネス要件や利用者の要望に合わせてシステムを進化させていきます。大規模なシステムの場合、専任の運用担当チームが24時間体制で監視を行なうケースも珍しくありません。

運用

リリース後は、ユーザーが実際にシステムを利用し始めます。サーバーやネットワークの状態を監視し、ログを分析することで、予期せぬ負荷や障害を早期に発見できます。運用中に得られる利用者のフィードバックは、次の改善施策を検討するための貴重な情報源です。クラウドサービスを活用している場合は、オートスケーリングなどの機能を使うことで急激な負荷増にも対応しやすくなります。

監視とアラート設定：CPUやメモリ使用率、アクセス数などを監視し、異常があれば通知が飛ぶように設定します。
ログの分析：エラーやレスポンス時間などを定期的に分析し、問題の兆候を早めにキャッチします。
問い合わせ対応：ユーザーからの問い合わせや不具合報告に素早く対応し、改善につなげます。

保守

運用中に機能追加や修正を行なう段階が保守です。バグ修正やパフォーマンス改善、新規の要件に基づく機能拡張などが含まれます。特に長期運用されるシステムでは、ハードウェアの老朽化やソフトウェアのバージョンアップなど、メンテナンスの課題が次々に発生します。

バージョン管理：コードやドキュメントを継続して管理し、どのバージョンで何が変更されたかを追えるようにします。
障害対応手順：障害が起きた場合の切り分け手順や連絡先を明確にし、復旧に必要な作業を迅速に行なえるよう備えます。
定期的なレビュー：保守のやり方やシステム構成を定期的に見直し、より良いサービス運用を模索します。

保守作業は、開発チームと運用チームの連携が不可欠です。運用中のログやユーザーフィードバックから得られた課題は、再度開発プロセスにフィードバックされ、次期バージョンの改善に役立ちます。近年では、開発と運用の境界をできるだけ曖昧にして連携を強化する DevOps の考え方が広まり、継続的インテグレーションや自動デプロイなどのツールや文化が定着しつつあります。

Lesson 9Chapter 6
プロジェクト管理とチーム協力

システム開発には、多くの人や組織が関わります。

要件定義を担当するビジネスサイドのメンバー、設計やプログラミングを行なうエンジニア、進捗を管理して品質を保つリーダーなど、それぞれの役割が明確になっているほどプロジェクトは進めやすくなります。

しかし、単に役割を定義するだけでは不十分です。何を成果物としているのか、どのように連携し、情報を共有していくのかが明確になっていなければ、やがてコミュニケーション不足や認識のズレが生じます。そうしたリスクを低減し、よりスムーズに開発を進めるためには「プロジェクト管理」の手法を取り入れることが不可欠です。また、チームメンバー同士が協力し合うことで、より高いパフォーマンスが発揮できるようになります。

ここでは、プロジェクト管理の基本的な考え方や、チームが力を合わせるためのポイントを整理します。

Lesson 9Chapter 6.1
プロジェクト管理とは

プロジェクト管理 は、定められた期間と予算のなかで、目標とする成果を効率的に得るための手法です。

プロジェクト管理は、システム開発の各フェーズにおいて「計画 → 実行 → 監視 → 完了」のプロセスを継続的に繰り返します。

システム開発の各フェーズで、プロジェクト管理を取り入れることで、期限や予算、品質などを保つことができます。

プロジェクトの立ち上げと計画

スコープ定義：どの機能を開発対象にし、どこまでをプロジェクトの範囲とするかを決めます。要求定義の段階で洗い出した要件をもとに、必要なタスクやリソースを明らかにします。
スケジュール策定：各タスクにかかる工数や依存関係を整理し、プロジェクト全体のタイムラインを作成します。ガントチャートやネットワーク図などを用いて可視化する方法が一般的です。
予算とリソースの割り当て：人件費やサーバー費用などを含む予算を見積もり、実際に確保できるリソースを踏まえて調整します。大規模プロジェクトでは、複数のベンダーと契約する場合もあるため、契約管理や支払いタイミングの調整が発生します。

プロジェクトの実行と監視

進捗管理：定期的にタスクの進み具合を確認し、予定とのズレを把握します。ズレが大きい場合はリソースの再配置やスケジュールの再調整を検討します。
品質管理：仕様通りに開発が行なわれているか、テストやレビューを通じてチェックします。ドキュメントの品質に注目する場合は、フォーマットやレビュープロセスを定義しておくことが効果的です。
リスク管理：開発中に起き得る問題を洗い出し、それぞれの対策方法を準備します。大規模なシステムだと、既存システムとの統合や、外部APIの仕様変更などがリスク要因になることがあります。あらかじめ対策を検討しておけば、問題発生時の影響を抑えやすくなります。

プロジェクトの終結と振り返り

成果物の引き渡し：システム自体のリリースに加え、設計書やマニュアルなどのドキュメントをそろえてユーザーや運用チームに引き渡します。
プロジェクト評価：当初のスコープやスケジュール、予算、品質などを振り返り、どの程度達成できたかを客観的に評価します。アジャイル開発では、プロジェクトの終結前にもイテレーションごとに振り返りを行なうため、あわせて評価しやすいです。
経験の共有：同様のプロジェクトを再び進める場合に備えて、今回得られたノウハウや失敗事例をドキュメント化し、組織で共有することが重要です。

こうしたプロジェクト管理の手法を定着させることで、進捗が遅れた際の対応や、品質不良を早期に察知するといったリスク対応がスムーズに進められます。特にシステム開発は、多種多様な役割と技術要素が絡み合うため、管理が疎かになるとあっという間に開発を混乱させる恐れがあります。十分なマネジメント体制を整えることは、成功への近道です。

Lesson 9Chapter 6.2
コミュニケーションとステークホルダー

プロジェクトが円滑に進むためには、複数の部門や組織、外部ベンダーなど、多数のステークホルダーと連携する必要があります。開発チーム同士のやりとりだけでなく、顧客や利用者、経営層、法務部門などが関わる大規模プロジェクトほど、コミュニケーションの難易度が高まります。

ステークホルダーの洗い出し

利害関係者の明確化：プロジェクトに影響を与える、もしくは影響を受けるすべての人や組織をリストアップします。
利害の把握：各ステークホルダーが求めるものや懸念点を把握し、プロジェクトが進むにつれてニーズが変化しないかを定期的に確認します。

コミュニケーション計画

会議や報告の頻度：定例ミーティングの開催スケジュールを決め、進捗報告の頻度やレポート形式を統一します。ウォーターフォールモデルでも、アジャイル開発でも、定期的な情報共有は共通して重要な要素です。
ツールの選択：社内チャット、タスク管理ツール、メール、Web会議システムなど、プロジェクトの性質やメンバー構成に合ったツールを選び、使い方を統一します。
情報の可視化：プロジェクトボードやバックログを関係者がいつでも閲覧できるようにしておき、最新の進捗や問題点が一目でわかる状態を保ちます。

合意形成と調整

要求変更への対応：要求の追加や仕様変更が出た場合、影響範囲や工数、コストを試算し、必要に応じてスケジュールを修正します。特にアジャイル開発では、このプロセスを短いスプリントのなかで繰り返すことが多いです。
コンフリクトの解消：ステークホルダー間で意見の相違がある場合、プロジェクトマネージャーや上位者が調整に入ります。事前に「優先度が高いのは何か」をはっきりさせておくと、判断がスムーズにできます。

大規模プロジェクトになるほど、チーム全体が向かうべき方向を見失いやすくなります。要件定義の段階で合意したゴールを定期的に再確認しながら、ステークホルダーとの密なコミュニケーションを続けることで、多くの人を巻き込むプロジェクトでも混乱を抑えられます。

Lesson 9Chapter 6.3
タスク管理ツール

プロジェクトのタスクを一元的に管理するためには、専用のツールが役立ちます。タスク管理ツールには、ガントチャートを使った計画型のツールや、カンバン方式でタスクを「To Do」「In Progress」「Done」のように見える化するタイプがあります。

backlogのガントチャート

主なタスク管理ツールの例

backlog
クラウドベースのプロジェクト管理ツールで、課題管理やWiki機能、Git/SVNリポジトリとの連携などができます。シンプルな操作感と多機能を両立しているため、幅広いチームに適しています。
backlog
Azure DevOps
マイクロソフトが提供するDevOpsプラットフォームで、ボードを使ったタスク管理からCI/CDパイプライン、リポジトリ管理まで、一連の開発プロセスをトータルにカバーします。Azure Boardsではバックログ管理やスプリント計画が可能で、アジャイル開発との親和性も高いのが特徴です。
Azure DevOps
Redmine
オープンソースのプロジェクト管理ツールで、チケット駆動開発を実践できます。進捗や担当者を一覧で確認できるほか、ガントチャートの機能も充実しています。
Redmine

タスク管理ツール導入のメリット

可視化による進捗把握：誰がどのタスクを抱えていて、どのくらい進んでいるのかが一目でわかります。複数プロジェクトを同時並行で進める場合でも、管理者が全体像をつかみやすくなります。
コミュニケーションの効率化：タスクごとにコメント欄で情報交換ができるため、後から経緯を確認するのが容易です。
作業の属人化を防止：タスクのステータスや担当者が明確になるので、特定の人しか把握していない作業を減らすことができます。

導入時の注意点

運用ルールの整備：ツールを導入するだけではチームが使いこなせない場合もあります。タスクの粒度や命名規則、ステータスの運用方法などをチームで統一し、定期的にメンテナンスする必要があります。
メンバーの教育：はじめて使うツールだと抵抗感を持つ人もいるため、簡単な使い方のマニュアルを用意したり、導入時に勉強会を行なったりするとスムーズです。
ツールの選定：プロジェクトの規模や開発スタイルによっては、シンプルなツールで十分な場合もあれば、高度なプロジェクト管理機能が必要な場合もあります。事前に要件を確認し、最適なツールを選ぶことが大切です。

タスク管理ツールを活用することで、チーム全体が「誰が何をいつまでにやるのか」を常に共有し、問題の早期発見や迅速な対応につなげることができます。

Lesson 9Chapter 6.4
チーム内での役割分担と協力

システム開発に関わるメンバーは、プログラマーやUIデザイナー、テスターなど技術的な専門家だけでなく、ビジネスアナリストやプロダクトオーナーなど、ビジネス面の専門家も含まれます。

それぞれが得意分野を活かしつつ、お互いの進捗や作業内容を把握し合うことで、高品質の成果物が生まれやすくなります。

役割分担の考え方

機能単位での分担
ユーザー管理機能、レポート機能など、大きな機能ごとにオーナーを決めて開発を進めます。この場合、オーナーが横断的にデザイナーやプログラマーを巻き込む必要があります。
職能別の分担
UIデザインはデザイナー、データベース設計はDBエンジニア、テストはQA担当といった形で専門分野を明確に分けます。機能間の調整が必要なときには、プロジェクトマネージャーやリーダーが連携をサポートします。

協力体制の築き方

デイリースタンドアップ
短いミーティングを毎日行ない、チーム全員が進捗や課題を共有する方法です。アジャイル開発のスクラムで採用されることが多いですが、ウォーターフォールでも参考にできます。
ペアプログラミングやコードレビュー
開発者同士が協力してコーディングやレビューを行なうことで、ノウハウ共有や品質向上が期待できます。
タスクの相互補完
あるメンバーがタスクを抱え込みすぎている場合は他メンバーがサポートし、逆に余裕があるときは他のタスクを手伝うなど、柔軟に役割をシェアします。

報連相（報告・連絡・相談）の重要性

情報共有のスピードアップ
問題や進捗をただちに「報告」することで、チーム内で早めに対策を検討できるようになります。
業務連携の円滑化
関係者に適切に「連絡」することにより、必要な人が必要なタイミングで情報を把握でき、タスクの相互補完やスケジュール調整もスムーズに行なえます。
トラブルの早期解決
行き詰まった際にはすぐに「相談」することで、知見のあるメンバーから助言を得られたり、リーダーや上位者が早期に意思決定できたりします。
チームの信頼関係の構築
積極的な報連相を通じて、お互いの作業状況や課題を把握し合い、より透明性の高いコミュニケーション文化を醸成できます。

モチベーション管理

フィードバックの仕組み
チーム内で成果物に対するポジティブなフィードバックを積極的に行ない、問題点は建設的に解決策を議論する文化を作ります。
目標設定
個人の目標とプロジェクト全体の目標を関連づけ、メンバーが自身の成長やキャリアアップを実感できるようにします。
コミュニケーションの活性化
対面でのコミュニケーションが難しい場合は、定期的にオンライン会議やチャットで近況報告を行ない、孤立を防ぎます。

このように、チームワークを意識したマネジメントによって、各メンバーのスキルが活きるだけでなく、全体的な生産性も高まります。報連相をはじめとするコミュニケーションを積極的に促すことで、小さな不安やトラブルを早期に解消し、互いに情報をオープンに共有できる環境を整えることが重要です。組織の文化や開発プロセスに合わせて、最適な方法を見つけていくのが理想的です。

Lesson 9Chapter 7
システムの運用と保守

システムの運用と保守 は、開発が完了したシステムを長期間にわたって安定稼働させるために欠かせない活動です。

開発フェーズでは、新しい機能を作り上げたり、設計書やテスト仕様を作成したりしますが、運用フェーズでは日々の障害監視やパフォーマンス管理、ユーザーからの問い合わせ対応などが中心になります。

また、保守フェーズでは、不具合修正や機能追加、セキュリティ対策などを行ない、必要に応じてシステムのリリースを繰り返します。

近年はクラウド環境の浸透により、リソースの増減やサーバー構成の変更を柔軟に行なえるようになったため、安定運用に対する要求レベルがより一層高まっています。

ここでは、運用と保守の重要性や具体的な取り組み方、DevOpsやCI/CDパイプライン、自動テストや自動デプロイなどを通して、開発と運用の連携をどのように実現するかを解説します。

Lesson 9Chapter 7.1
DevOpsの概念

DevOps は、開発（Development）と運用（Operations）を連携させることで、システムのリリースサイクルを短縮し、品質を高めるための考え方です。

従来のウォーターフォールモデルでは、開発チームが完成させたシステムを運用チームへ引き渡し、運用チームが独立して保守や障害対応を行なうケースが多くありました。これだと、運用段階で見つかった不具合や改善要望が開発チームに素早く届かず、システム改善に時間を要する問題が起こりがちです。

DevOpsが目指すのは、開発と運用が一体となってシステムのライフサイクル全体を管理し、継続的な改善を行なう仕組みです。具体的な実践としては、以下のような取り組みが挙げられます。

継続的インテグレーション（CI）の導入
開発チームが新しいコードをリポジトリへコミットするたびに自動でビルドやテストを実行し、不具合を早期に発見します。運用チームにとっては、常に最新の開発成果をテスト環境で確認できるメリットがあります。
継続的デリバリー（CD）の実践
開発した機能を本番環境にデプロイする手順を自動化し、短いスパンでリリースできるようにします。小さな機能追加や不具合修正を素早く反映できるため、ユーザーの満足度が高まりやすいです。
インフラストラクチャの自動化
運用チームが担うサーバー構築やネットワーク設定などをコードとして管理し、必要なときに自動で環境構築できるようにします。クラウドサービスとの相性が良く、負荷が増えた際のオートスケーリングなどもスムーズに行なえます。
監視とログ分析の強化
システム全体の稼働状況を可視化し、障害発生時や高負荷状態に迅速に対応します。クラウドベースの監視ツールやログ分析ツールを組み合わせることで、運用チームだけでなく開発チームもシステムの状態をリアルタイムに把握できます。

このような取り組みを行なうことで、システムリリースから保守・改善までのサイクルを短縮し、ビジネスの変化やユーザーの声に柔軟に対応できます。開発と運用の間にある情報の壁を取り払い、全員が同じゴール（安定稼働と継続的な機能拡張）を共有することが重要です。

Lesson 9Chapter 7.2
CI/CDパイプライン

CI/CDパイプライン は、ソフトウェアを継続的にビルド（構築）・テストし、本番環境へ反映するまでの工程を自動化する仕組みです。

従来の開発プロセスでは、手動でテストやビルド、デプロイを行なうことが多かったため、作業ミスやリードタイムの増加につながりやすい問題がありました。CI/CDパイプラインによって、これらの工程を自動化し、より頻繁で安全なリリースが可能になります。

CI（継続的インテグレーション）

継続的インテグレーション（CI） は、複数の開発者が同時並行でコードを変更している環境でも、こまめにコードを統合し、ビルドやテストを自動で実行する仕組みです。新しいコードがリポジトリにプッシュされると、CIツールが以下のような処理を行ないます。

ソースコードの取得：Gitなどのバージョン管理システムから最新のコードを取得します。
ビルド：プログラミング言語やフレームワークに合わせてソースコードをビルドし、コンパイルエラーなどがないか確認します。
テスト実行：単体テストや統合テストを自動実行し、エラーや警告が出たらレポートとして通知します。

代表的なCIツールとしては、Jenkins、GitLab CI/CD、CircleCI、GitHub Actions などがあります。いずれのツールでも、設定ファイル（YAMLなど）にビルドやテストの手順を書いておけば、自動的に実行して結果を可視化してくれます。

CD（継続的デリバリー／継続的デプロイ）

継続的デリバリー（CD: Continuous Delivery） は、CIの次のステップとして、テスト済みのソフトウェアをいつでも本番環境にリリースできる状態を保つ手法です。また、継続的デプロイ（Continuous Deployment） では、テストに合格したら自動で本番にデプロイするレベルまで高度に自動化されます。

ステージング環境へのデプロイ：CIを通過したアプリケーションをステージング（テスト）環境にデプロイし、動作を最終確認します。
本番環境へのデプロイ：ステージングで問題がなければ、本番環境にデプロイを行ないます。手動承認を入れる場合もありますが、完全自動化して継続的デプロイを実現する方法もあります。
デプロイ方式の選択：Blue-Greenデプロイ、Canaryリリース、Rolling Updateなど、システムを止めずにリリースするための方式が用いられます。

CDを活用すると、リリースに必要な作業が大幅に削減され、チームが新機能の開発や品質向上に集中しやすくなります。ユーザーからのフィードバックを迅速に取り込み、細かなアップデートを繰り返すことで、システムの完成度を着実に高められます。

Lesson 9Chapter 7.3
自動テストと自動デプロイの役割

DevOpsやCI/CDを実践するうえで、自動テスト と 自動デプロイ は大きな役割を果たします。どちらも人為的なミスを減らし、リリースサイクルを短くするために導入されます。特に大規模なシステムでは、テスト項目が膨大になるため、手動テストだけでは抜け漏れやコスト増加が避けられません。

自動テスト

自動テストには、以下のような種類があります。

ユニットテスト（単体テスト）：関数やクラスなど、最小単位のロジックが仕様どおり動くか確認します。
インテグレーションテスト（結合テスト）：複数のモジュールが連携する部分をテストし、データのやり取りに不具合がないか確認します。
エンドツーエンドテスト：ユーザー視点でアプリケーションを操作するシナリオを自動化し、実際の利用環境に近い形で機能を検証します。

これらのテストをCI環境で実行すれば、コードを修正した直後に不具合を検出できるため、後工程での大きな手戻りを抑えられます。

自動デプロイ

自動デプロイでは、テストに合格したアプリケーションをボタン1つ、もしくは完全自動でステージングや本番環境へ配置します。以下のようなステップを経る場合が多いです。

ビルド成果物の生成：コードをビルドして、実行可能なファイルやDockerイメージを作成します。
デプロイ先環境の準備：インフラストラクチャを自動構成ツール（AnsibleやTerraformなど）で整え、必要な設定を適用します。
デプロイ実行：S3やDocker Registryなどからビルド成果物を取得し、サーバーに配置してアプリケーションを起動します。
ヘルスチェック：デプロイ後にアプリケーションの稼働状況を確認し、問題があればロールバックする仕組みを用意します。

自動テストと自動デプロイを組み合わせると、開発チームや運用チームの負担を減らし、リリースまでのリードタイムを短縮できます。繰り返し行なわれる作業が少なくなり、作業品質も安定しやすくなります。

Lesson 9Chapter 7.4
開発と運用の連携の重要性

開発と運用が連携することで、プロダクトの品質やリリース速度が飛躍的に高まります。

ユーザーからのフィードバックが迅速に開発チームに届き、運用上の課題も早期に改善できるため、結果的にシステム全体の価値向上に直結します。また、近年はクラウドコンピューティングが主流となり、インフラのスケールや運用の高度化が進んでいます。

こうした環境変化に応じて、開発チームと運用チームが役割を明確にしつつ相互にサポートし合う体制が求められます。

連携を促進する施策

定期的な情報共有：デイリースクラムやウィークリーミーティングなどで、運用チームも含めたステータス報告を行ないます。
障害対応の振り返り：障害や不具合が発生した際に、運用と開発が共同で原因を追究し、再発防止策を共有します。
監視データの共有：CPU負荷やメモリ使用量、レスポンス遅延の情報を開発チームでも常時チェックできるようにしておき、リリース前後でのパフォーマンス変化を確認します。

運用メンバーの知識強化

開発スキルの獲得：スクリプトの書き方や簡単なプログラム修正を学ぶことで、運用中に起きた問題を一部自力で解決できるようになります。
インフラコード化：インフラ管理をコードで表現し、Gitなどでバージョン管理する文化を取り入れると、開発メンバーもインフラ構成を理解しやすくなります。
自動化の推進：定型的な保守作業はスクリプトやツールで自動化し、ヒューマンエラーを減らしながら運用の効率化を図ります。

これらの施策を通じて、開発と運用が同じプロジェクトの成功に向けて協力できる体制が整います。大規模な組織では部門間の壁が厚いケースもありますが、DevOpsの導入やチーム編成の工夫によって障壁を取り払い、システムの安定稼働と迅速な改善を両立させることが可能です。

Lesson 9Chapter 7.5
システムの運用と保守

システムが本番稼働を始めると、さまざまな運用タスクや保守業務が日常的に発生します。運用と保守の質が低いと、開発段階でいくら優れたシステムを作っても、その価値を十分に発揮できません。以下は、代表的な運用・保守の取り組み例です。

監視・障害対応
- サーバーやアプリケーションの稼働状況を監視ツールで常時監視します。
- 障害が起きた際にはアラートが上がり、運用担当者が速やかに原因を切り分けて対処します。
- 深刻な障害の場合は開発チームに連絡し、問題箇所を修正して再リリースする流れを確立します。
定期的なメンテナンス
- OSやミドルウェアのセキュリティパッチを適用し、脆弱性対策を継続します。
- データベースのチューニングやログの整理など、性能維持のための作業も定期的に実施します。
- メンテナンス時には、ユーザーへの告知や障害発生リスクのマネジメントが必須です。
機能追加・改善
- ユーザーやビジネス部門からの新しい要望を受け付け、開発サイクルに取り込みます。
- 運用チームが日々の問い合わせやサポートで得た知見を開発チームと共有し、使い勝手や効率を高める改善を行ないます。
- 機能拡張のリリース時には、CI/CDパイプラインを活用して素早く反映します。
バックアップ戦略と災害対策
- システムデータのバックアップを定期的に行ない、障害やデータ破損に備えます。
- 災害対策（DR：Disaster Recovery）の一環として、別地域のデータセンターにレプリカを作成することもあります。
- 復旧手順をドキュメント化し、運用チームがスムーズに対応できるよう準備します。

運用と保守は、システムが利用者にとって有用であり続けるための基盤を支える活動です。

特に安定性が求められる基幹システムや24時間稼働のサービスでは、障害発生時の迅速な復旧と、事前のリスク管理がシステム全体の信頼性を左右します。また、技術やビジネス要件が絶えず変化していく時代において、システムを継続的に更新し、常に最新のニーズに合わせる姿勢が不可欠です。

DevOpsやCI/CDをはじめとする現代的な手法やツールを適切に取り入れることで、開発と運用の垣根を超えて効率的にシステムを進化させられます。

Lesson 9Chapter 7.6
サービスマネジメント

サービスマネジメント とは、IT サービスを利用者（顧客・ユーザー）が満足できる形で提供し、その品質やコストを最適化する考え方です。ITサービスをスムーズに運営・改善していくために、サービスマネジメントのベストプラクティスとして広く利用されているのが ITIL（IT Infrastructure Library）です。

ITIL
ITIL は、ITサービスマネジメントのフレームワークとして、サービスライフサイクル全体（サービスストラテジ・サービスデザイン・サービストランジション・サービスオペレーション・継続的サービス改善）で考慮すべきプロセスや活動を体系立てたベストプラクティス集です。多くの企業が ITIL を参考に運用管理やサービスの品質向上に取り組んでいます。
サービスレベル合意書（SLA: Service Level Agreement）
サービス提供者と利用者の間で、サービスの品質や可用性などの合意事項を明確化した書類です。例えば「99.9% の稼働率を保証する」「問い合わせには◯時間以内に応答する」など、定量的な目標を設定し、それに基づいてサービスを運用していきます。

サービスマネジメントでは、単なる障害対応や作業効率化だけでなく、顧客満足度やコスト最適化などのビジネス視点を含めて考慮する点が重要です。

サービスマネジメントシステム

サービスマネジメントシステム は、組織が IT サービスを計画・設計・提供・運用・改善するときに必要となる仕組みやプロセスを体系化したものです。国際規格として ISO/IEC 20000 が有名で、ITIL の考え方をより標準化し、組織として運用管理体制を整備することを目的としています。

サービスマネジメントシステムの概要
組織全体のポリシーや役割分担、プロセス、手順書、監査・改善活動などを含む包括的な枠組みです。これにより、サービス提供体制が属人的にならず、継続的に高品質のサービスを提供できます。
サービスデスク（ヘルプデスク）
サービスマネジメントシステムの中心的な窓口として機能するのが、サービスデスク（ヘルプデスク）です。ユーザーからの問い合わせや障害報告を一元的に受け付け、エスカレーションや問題管理と連携します。開発チームや運用チームとも密接に連携するため、迅速なトラブルシュートや顧客対応が可能になります。

ファシリティマネジメント

ファシリティマネジメント は、ITサービスが稼働するための物理的な環境や設備（ファシリティ）を適切に整備・維持する活動を指します。データセンターやサーバールームの設計、電源や空調の確保、防災対策などは、システム稼働において非常に重要な要素です。

システム環境整備
システムを安定稼働させるために必要な電源・空調・ラック構成・ネットワーク配線などを計画的に整え、障害リスクを最小化します。ハードウェアのリプレイス時期や拡張性も考慮しておくことで、予期せぬダウンタイムやパフォーマンス低下を防ぎます。

ファシリティマネジメントの観点を踏まえたインフラ設計は、運用と保守がスムーズに進むための重要な基盤です。適切な物理環境を維持することで、サービスマネジメントシステムが想定どおりに機能し、ITサービス全体の安定性と可用性を高められます。

Lesson 9Chapter 8
まとめ

このレッスンでは、システム開発の全体的な流れと主要なポイントを解説しました。

ビジネスパーソンが、ITの基礎知識やシステム開発の流れを理解することは、企業競争力や意思決定のスピードを高めるうえで非常に重要です。

技術的な言葉やプロセスをある程度把握していれば、エンジニアと共通言語で対話し、要望や仕様を明確に共有できます。また、プロジェクト全体のスケジュール管理やコスト管理、さらにリスクヘッジなど、ビジネス視点からの助言が得られるようになるのも大きなメリットです。

チームメンバーとして「報告・連絡・相談」を重視し、プロジェクトの成功へ寄与できるようになりましょう。

このレッスンで学んだこと

このレッスンで学んだことを振り返り、理解度を確認しましょう。

システム開発の目的は、ビジネス課題を解決することであり、業務効率化やコスト削減、新規ビジネスの創出などが含まれる。
ビジネス要件（売上向上、コスト削減など）とシステム要件（機能要件・非機能要件）の双方を整理することで、必要な機能や性能を明確にする。
要件定義では、現場ヒアリングや利用者からのフィードバックを重視し、開発中の手戻りを抑えるための合意形成を丁寧に行なう。
ウォーターフォールモデルは、工程を上流から下流へ順番に進める伝統的手法で、進捗管理しやすい半面、要件変更には弱い。
アジャイル開発では短いスプリントを繰り返し、ユーザーからのフィードバックや要件変更に柔軟に対応できる。
設計フェーズは基本設計と詳細設計にわかれ、UIデザインやデータベース構造、ビジネスロジックなどを確定し、手戻りリスクを減らす。
実装フェーズでは、プログラミング言語やフレームワークを選定し、コーディングと単体テストを並行して進め、品質を確保する。
テストでは、単体テスト→結合テスト→総合テスト→受け入れテストの流れで不具合を洗い出し、要求通りに動作するかを段階的に確認する。
運用・保守では、障害対応や機能追加、セキュリティ更新などを行ないながら、システムを安定稼働させ続ける。
プロジェクトマネジメントでは、スケジュール管理やリスク管理、チーム内外のコミュニケーションが成功のカギを握る。
タスク管理ツールを使うと、担当者や進捗を可視化でき、情報共有や報連相が円滑になり、開発効率を高められる。
DevOpsやCI/CDを導入すると、開発と運用を連携し、頻繁なリリースや継続的な改善が可能になり、ビジネスニーズの変化に素早く対応できる。

課題システム開発の理解度確認

下記の5つの質問に答えてください。「回答フォーマット」をコピーして、コメント欄に記入して提出してください。

システム開発において、「ビジネス要件」と「システム要件」はどのように異なるのでしょうか。
ウォーターフォールモデルのメリットとデメリットを簡潔に説明してください。
アジャイル開発のメリットを、「スプリント」と「ユーザーからのフィードバック」という言葉を入れて説明してください。
プロジェクトを成功に導くため、ビジネスパーソンとしてどのような点に注意してコミュニケーションを行なうべきでしょうか。
要件定義フェーズで、手戻りを最小限に抑えるため、重要なポイントは何でしょうか。

回答フォーマット

1. 
2. 
3. 
4. 
5.