本記事はこれからシステムエンジニアを目指してみようと思っている方や、システム開発がどのように行われているのかについて知りたい方に向けて工程ごとの業務内容を簡潔に解説しています！システム開発の各工程における業務内容を抑えていくことで、システムエンジニアやプログラマーとしてIT業界で働くイメージが付きやすくなります。私自身、システム開発の工程を聞くことでITって面白そうと感じることができ、今の職業に就くきっかけの一部となっています。初心者の方向けにSEの仕事内容について解説している記事もありますので、本記事を読む前にぜひ覗いてみてください。
システム開発における５つの工程とその解説
システム開発の工程は大きく「要件定義」、「設計」、「製造」、「テスト」、「リリース」の5つにわけられます。以下では各工程の業務内容について解説していきます。
要件定義
主な登場人物
- お客さん
- システムエンジニア
概要
要件定義とは、お客さんとどのようなシステムを作るかについてを決めていき要件定義書を作っていく工程になります。具体的に何を決めるのか、箇条で書き出してみました。
＜どのようなシステムを作るのか＞
・システムを作る目的
・目的を達成するために必要な機能の一覧（機能要件）
・目的と直結しないが、システムを利用するにあたり付随してくる要件（非機能要件）
例）通信速度はどれくらい ／ セキュリティ対策について
工程の意義
要件定義で決められたことは、システム開発を進めていくうえで最終的なゴールへの道しるべとなり、何か問題が起きたときの意思決定スピードを上げることができます。逆にこの工程でシステムを作る目的がブレていると、工程が進んでいくことで見えてくる課題にあれもこれも手が伸びてしまい、スケジュール遅延やコスト超過でプロジェクトが破綻してしまう原因となってしまいます。
設計
主な登場人物
- システムエンジニア
- プログラマ
概要
設計の段階に入ると、要件定義で定められた機能を実際に作るための設計書を作成していきます。一般的にここで活躍するのはシステムエンジニアになります。プログラマとのセッションを行っていく場合もありますが、システムの規模やチームの方針でもプログラマの介入の仕方は異なってくるでしょう。設計はユーザ視点からの状態遷移を考える「外部設計」とシステム内部の処理の仕方を考える「内部設計」に分けられます。
＜外部設計＞
ユーザ視点での状態遷移や画面配置を考える工程です。例えば、スマホアプリの場合における状態遷移とは特定の文字をタップしたら別の画面に飛ばすことで、画面設計とは文字入力をユーザ側に促す場合は入力ボックスをどこに配置するのかなどを考えていきます。
＜内部設計＞
システム内部の処理、動作を考える工程です。例えば、ユーザに個人情報を入力させてそれを保存するとします。ユーザ側は入力範囲に文字を入れて保存ボタンを押したら終わりですが（ここまでが外部設計）、その先の保存する情報の形(表とかファイルの形式)や情報のしまい方、取り出し方を考えていくというのが内部設計になります。
工程の意義
設計の1番の目的は、システムの作り方を明確にすることです。「このプラモデルを作ってください」と完成系の写真をみせられ部品を渡されても説明書がないと困ってしまいますよね。設計書＝説明書となります。また、システムに不具合があった時に原因がどこかを調査する際にも設計書は必須となります。
製造
主な登場人物
- プログラマ
- システムエンジニア
概要
設計書ができあがったら、実際にプログラミングをしてシステムを作っていく段階に入ります。ここでは設計工程で作成された設計書をもとにプログラマと呼ばれる人がプログラムを書いていきます。システムエンジニアは課題などの相談事の対処を行うがメインの役割でここではプログラマの独壇場です。自分はプログラムをバリバリかける人間ではないので憧れます、本当にかっこいいです…（笑）
工程の意義
製造工程の意義は単純明快です。皆さんや企業が使用するシステムを作ることそのものです。この工程では設計書に記載している項目を網羅できないシステムを作ってしまうと、次の工程のテストで不具合が大量に発生してスケジュール遅延、そのままサービスが開始してしまうとその時点で障害が発生してしまうため、確実にプログラミングをして設計された機能を再現していくことが重要になります。
テスト
主な登場人物
- テストエンジニア
- プログラマ
- システムエンジニア
＜補足：テストエンジニアとは？＞
ここで聞きなれないテストエンジニアなる人が登場しています。ひと言で説明すると、システムにおけるテスト専門に業務をする人のことです。システムエンジニアやプログラマがテストを実施してしまうと、自身が作成したシステムのため操作や処理の挙動に慣れてしまっており、思い込みが発生しテストで不具合に気づかない場合があります。このような時にシステムの設計、製造に直接的に関与していなければフラットな目線で確認できるよね、というからくりです。
概要
テスト工程では、製造が完了したシステムに対して、想定通りの処理がされるかの確認をしていきます。システムのテストは1つだけではなく目的に応じて様々な種類が存在します。今回はその中から代表的な3種類を紹介します！
＜代表的なテスト3種類＞
・単体テスト(UT: Unit test)
単一の機能ごとに動作確認をしていくテストのことです。
・結合テスト(IT: Integration test)
複数の機能を組み合わせたときに処理がうまくいくかを確認するテストです。
・総合テスト(ST: System test)
要件定義の時点で決められた、システムの要件を満たせているかを確認するテストです。
各テストにおいては主にテストエンジニアが実施して、不具合の対応をシステムエンジニアやプログラマが行う形となりますが、場合によってはシステムエンジニアやプログラマもテストを実施する側の人間として駆り出されることもあります。私の職場では実際にテストエンジニアという役割の人を作らず、製造工程で直接コーディングに携わっていないシステムエンジニアやプログラマがテストを行うという方法をとることが多いです。人手不足なのでね…。
工程の意義
テスト工程ではお客さんが求めるシステムが完成したのかを確認するために行います。十分なテストがなされていないと、お客さんのシステムがうまく稼働せず業務が停止してしまったり、ユーザがサービスを使用できなくなったりします。大規模なシステム障害が発生してしまうと、うん百億円、もしくはそれ以上の損害が発生してしまうため、システムをサービスとして提供する前段階として、とても重要の工程になっていきます。
リリース
主な登場人物
- お客さん
- システムエンジニア
- プログラマ
- テストエンジニア
概要
最後の工程、リリースはシステムのサービス開始をするための移行作業となります。事前に日程や体制をお客さんとエンジニア側ですり合わせをして、分単位のスケジュールに従い移行作業を実施していきます。案件の規模にもよりますが、基本的にはこれまで開発に携わってきた人全員の総力戦でその場の不具合にも対処できるような体制を整えておきます。
＜テスト後からリリースまでの流れ＞
①リリースの計画を立てる
決めるもの：日程、体制、詳細なスケジュール(手順)、不具合があった際の対処法、移行直後にテストがうまくいっていることの検証項目
②移行作業を実施する
③移行後の検証を実施
工程の意義
システムのサービスを開始するという事がリリースという工程の実施内容となります。しかし、すべての移行作業が絶対にうまくいくことはほとんどなく、不具合を発生させないもしくは発生したときに素早く対処できるような準備やスケジュール通りにサービスを開始させるようにするためにしっかりと計画を立てることが、とても重要になってきます。
まとめ
いかがでしたでしょうか？概要を説明するだけでも結構ボリューミーになってしまいましたが、システム開発ってこんな流れなんだよ～という全体像が伝わって入ればうれしいです。システムエンジニアやプログラマを目指すにはこの基本的な流れを抑えることは必須になります。システム開発って意外と各工程ごとに関わる人も実施する内容も異なり、個人的にとても魅力のある仕事だなぁと感じています。この工程を1通りやりきった時は何とも言えぬ快感があります。この記事を読んでくれた皆さんがシステム開発に興味を持ち、IT人材の人手不足を救ってくれることを祈っております。
コメント