「システム開発とは？」5つの工程ごとに業務内容をわかりやすく解説

「システム開発って普段どんな仕事をしているの？」

システム開発と言われても、未経験からIT業界への就職・転職を考えている方にとって、業務内容のイメージがなかなか沸きづらい仕事だと思います。
私自身も就活生時代、本を読んだり企業説明会で話を聞いたりして、だいたいの概要は知っているけど本当に知りたい情報を得ることができず苦労していました。

そこで今回は、システムエンジニアとして業務経験をした情報を集約して、同じような悩みを抱えている方のために業務内容の概念的なものから普段の過ごし方までを解説していきます！

現役システムエンジニアの私いけやんが普段の仕事を棚卸した内容ですのでリアルな情報が知りたい方はぜひご覧になってみてください。

システム開発における5つの工程について

システム開発の工程は大きく以下の5つに分けられます。
始めはそれぞれの工程における概要について説明していきます。

• 要件定義
• 設計
• 製造
• テスト
• リリース

要件定義

概要

要件定義とは、「社内の業務やサービスをシステム化したい」「既存のシステムがいまいちだから改善したい」というお客さんと一緒にどのようなシステムを作るのかを考えていく工程です。
基本的にはお客さんが思い描くシステム像をヒアリングし、それに必要な機能は何か、サービスとして満たしておきたい条件は何かをすり合わせしていくという流れになります。
この工程で整理、決定される事項は大きく分けると以下の3点です。

• システムを作る目的
• 目的を達成させるために必須な機能
• より良いシステムにするために必要な機能

業務内容と過ごし方

この工程ではどんなシステムを作るかをすり合わせることが最大の目的となるため、必然的に会議とその準備に要する時間が多くなります。
会議用の資料を作り、お客さんに提案やヒアリングを行い、そこで決まった情報を持ち帰ったうえで内部の作戦会議をして、個人での情報収集や資料作成に取り掛かるを繰り返していくといった流れになります。

要件定義工程では一日中誰かと会話をしてることが多く気を張っているため、気疲れが多くなりますね…。
ただ、仕事の始めの方なので『よりよいシステムを作るぞ！』といった気持ちが先行し、メンバーやお客さんのモチベーションも高く、トラブルさえなければ個人的はとてもやりがいのある工程です。

設計

概要

設計の工程では、要件定義で定められた機能について具体的な仕様を決めていきます。
この工程で作り上げられるものは主に以下の5つで、システムエンジニアがお客さんの要望を実現するために設計図を描くことがメインの仕事です。

• 外部設計書
• 内部設計書

どのサイトや本を読んでも設計工程における説明には上記の「外部設計」と「内部設計」というワードが出てきます。
システムの利用者側が気になること、システム利用者が目に見える部分が「外部設計」、エンジニアが気にするべきところ、目に見えないがシステムを動かすために必要な部分が「内部設計」みたいなイメージで押さえておきましょう。
なかなか概念を理解するのが難しいと思いますが、はじめは上記のようなニュアンスで覚えておけば問題ありません。
一応それぞれのもう少し細かい説明も補足として書いておきますね。

＜外部設計＞
ユーザ視点での状態遷移や画面配置を考える工程です。
例えば、スマホアプリの場合における状態遷移とは特定の文字をタップしたら別の画面に飛ばすことで、画面設計とは文字入力をユーザ側に促す場合は入力ボックスをどこに配置するのかなどを考えていきます。
＜内部設計＞
システム内部の処理、動作を考える工程です。
例えば、ユーザに個人情報を入力させてそれを保存するとします。
ユーザ側は入力範囲に文字を入れて保存ボタンを押したら終わりですが（ここまでが外部設計）、その先の保存する情報の形(表とかファイルの形式)や情報のしまい方、取り出し方を考えていくというのが内部設計になります。

業務内容と過ごし方

設計工程は設計書が大きな成果物となります。
まずは、要件定義書を軸にシステムエンジニアが設計書を作成　⇒　プロジェクトリーダやシステムの有識者がレビューを繰り返し行い、設計書を完成までもっていきます。
システムエンジニア側のレビューが完了したら、次はお客さん側のレビューを経て納品となります。

論理的な思考力がとても重要な工程で、要件定義とは打って変わって誰かと会話する機会も少なく、じっと考え込んだりパソコンとにらめっこしている時間が長いのがこの工程の特徴です。

製造

概要

設計書をもとにプログラミングを行う工程が製造工程です。

『プログラミングってなに？』と思った方のために簡単に説明。
システムを動作させる機械は”０”と”１”の2文字を使った2進数によって命令をすることができます。
しかし、人間がこの文字をいちいち使って命令文を書くのは難しいため、人間が使う文章と2進数（機械語）の仲介をしているのがプログラミング言語なのです。
もう少し詳しく知りたい方はこちら記事を参照してみてください。

業務内容と過ごし方

製造工程では設計書をもとにプログラミングをして、動作確認を行い、うまく動作しない部分に関してはその修正を繰り返し行っていきます。
プログラミング技術は専門性が高い技術で、品質が個人のスキルや経験に依存する場合が多いため、プログラマーというプログラミング専門の人を雇うことがあります。
その際システムエンジニアはプログラマーの進捗管理や業務の中で発生する課題に対してコントロールを行うことに注力するようになるのです。
システムエンジニアがプログラミングをする現場があると聞いていますが、実際私が経験した現場ではプログラミングはすべてプログラマーに任せるというパターンでした。

また製造工程ではお客さんの専門外になるため、システムエンジニアやプログラマー側のみが主体となるのも特徴です。

テスト

概要

製造工程によって作成されたプログラムを使用して要件定義書や設計書に記載した通りの処理ができることや性能を確認する工程になります。
テスト工程は「テスト計画、テストケースの作成」、「テスト実施」という2段階に分けられます。

テスト計画ではテストの目的やテストの方式を整理し計画書を作成します。
どんなデータを使いどのような条件でテストを実施するか、テストの結果どのような動作をしたらOKかNGかを事細かにテストケースというドキュメントに記載するのです。
計画書とテストケースができたのちにテストを実施していくという流れになります。
テスト計画で定める項目は以下の通りです。

• テスト日程
• テストの目的
• テスト方式（実施方法）
• 検証観点

テストでは製造した部分が想定通りに動作することはもちろん、既存のシステムと連動して機能するかや処理速度、使いやすさなど様々な観点から検証をします。
テストによって確認する項目は主に以下の４つです。
それぞれのテストによって検証する目的や範囲が異なり、各テストについてわかりやすくまとめられている記事がありますので、気になる方はぜひこちらをご覧になってください。

• 単体テスト
• 結合テスト
• システムテスト
• 運用テスト

業務内容と過ごし方

製造工程ではお客さんの介入がほとんどない状態で仕事をしますが、テスト計画書の作成やテスト実施の進捗報告などシステムエンジニアと綿密なセッションが増えていきます。
テスト工程でのトラブルは納期遅延に直結していくので緊張感がグッと高まる工程ですね。
テスト計画書やテストケースを作成した後は、基本的に以下のスケジュールの通り、テスト、不具合解析、プログラム修正、再テストの繰り返しになります。

リリース

概要

リリース（移行）はシステムのサービス開始をするための最後の工程となります。
事前に日程や体制をお客さんとエンジニア側ですり合わせを行い移行計画書を作成したのち、必要な資材の準備や手順書の準備を着々と進めていきます。
そうして、いよいよリリース当日、分単位のスケジュールに従い移行作業を実施していくことになるのです。
案件の規模にもよりますが、基本的にはこれまで開発に携わってきた人全員の総力戦でその場の不具合にも対処できるような体制を整えておきます。

移行計画書で定めておく内容はざっくり以下の通りです。

• 移行の日程
• 体制
• 用意するもの
• トラブル時の対応
• 移行後の検証観点　※うまくリリースできたかどうかの検証

業務内容と過ごし方

この期間は経験上いつもバタバタと忙しくなります。
移行計画書を作成してお客さんから承認をもらえたら、リリースに向けて必要な資材（プログラムや手順書）の準備を進めていきます。
他の工程に比べるとそこまで長期スパンでのタスクはなくスピーディな対応が求めらることが多いですね。

まとめ

今回はシステム開発とは5つの工程があり、それぞれどのような仕事をしているのかという内容について解説しました。
システム開発について概要を理解ができると、そこで活躍するシステムエンジニアやプログラマーの仕事の内容もより理解しやすくなります。
以下の記事ではシステムエンジニアの仕事内容について解説していますのでぜひ合わせて読んでみてください！

この記事を読んでくれた皆さんがシステム開発に興味を持ち、IT人材の人手不足を救ってくれることを祈っております。