システム開発工程ver5

『システム開発工程ver5』のサムネイル

皆さんは、システムエンジニアとしてどの工程を担当していますか?
上流工程を担当していますか?それとも下流工程を担当していますか?
 
フリーランスで働く以前に、システムエンジニアとして働く以上、システム開発工程を理解しておく必要があります。
 
そこで、シリーズ企画として、システム開発工程の概要から各工程の大切なこと、やっていく上でのコツをこのシリーズ企画でお届けしています。
 
今回はver5として、遂に「下流工程」の話になります。
 
ここからは、上流工程で作成した設計書がどのように下流工程で利用されているかを中心に纏めていきます。
 
ぜひ、下流工程に従事されている方、下流工程の仕事をされたい方は、ぜひご覧ください。

下流工程(プログラミング~テスト)

まずはこちらの図をご覧ください。
この図が、「上流工程と下流工程の関係性」を表しています。

左側が上流工程で、一番最下部と右側が下流工程になります。
一つずつ解説していきます。

【4】プログラミング

一番最下部の「開発実施」は「プログラミング」で、上流工程で作成した以下設計書を元に、実際のシステムを構築していく工程になります。
<使用する設計書>
・外部設計書(基本設計書)
・内部設計書(詳細設計書)

この工程で、遂に「プログラム言語」を利用します。
「java」、「perl」「ruby」、「html」など様々な言語の中から、構築したいシステムに適した言語でプログラミングしていきます。

実際にモノを創り、そしてモノが形になる工程です。
モノを創り上げるという楽しさが一番実感できるので、モノ創りが好きな方には向いている工程だと思います。

ただ、基本的には、設計書通りにプログラミングしていくので、「自由な発想」は求められず、「設計書通り」にプログラミングしてくことになります。
ここで、自由にプログラミングすると、予期せぬバグや仕様を満たせないことになるので自由な発想で仕事をしたい方には、少し窮屈感を感じることがあるかもしれません。

プログラミング言語の特徴などは、また別の記事で纏めてみようと思います。

【5】単体設計(単体テスト)

プログラミング工程が完了したら、実際に構築したプログラミングが正しく動作するかをテストします。
システム開発では、「小さい単位」から「大きい単位」という流れでテストするため、一番初めのテストは「単体テスト」です。
ここでは、「プログラミングの対象単位(モジュール)」毎にテストします。

この工程では上流工程で作成した以下設計書を元にテスト観点をまとめる「単体テスト仕様書」を作成。そして、「単体テスト」を実施し、プログラム(モジュール)が正しくプログラミングされていることをテストします。
<使用する設計書>
・内部設計書

<サンプル>単体テスト仕様書。

【項目説明】
 分類:設計書内の一番大きな処理。
 試験・確認項目:処理内の一つ一つの動作
 試験・確認内容:処理内の一つ一つの動作が仕様通りに動くときの挙動

代表的なテスト観点は以下です。

【テスト観点】
 ・正常系テスト
処理が正しく動くことを確認するケースで、設計書通りの挙動になることを確認します。

<例>
「文字列に「ようこそ」を格納する」処理があった場合
①文字列に「ようこそ」が格納されることを確認

 ・条件網羅テスト
ロジックのIf文などの条件を網羅するテストケースです。
全ての条件式に対して、正しく条件通りに処理されるかを確認します。

<例> 
「If (文字列=A or 文字列=B)」があった場合
以下3パターンのように条件網羅するようにテストするのが基本です。
①文字列=Aの場合、条件一致
②文字列=Bの場合、条件一致
③文字列=Cの場合、条件不一致

 ・境界値テスト
ロジックの不等号(<,>,=など)を確認するテストケースです。
全ての不等号に対して、不等号通りに処理されるかを確認します。

<例>
「If(数値<10)」があった場合
3点検証だと以下①~③を、2点検証だと以下①②をテストケースとします。
①数値=9の場合、条件OK
②数値=10の場合、条件NG
③数値=11の場合、条件NG
3点検証は、対象の数値とその数値の前後±1を検証する方法で、
2点検証は、対象の数値と、対象数値-1を検証する方法です。

私の経験上では、産業系システム開発などの速さを優先するところでは2点検証で実施し、金融系や公共系システム開発などの品質を優先するところでは3点検証が使用されているように思います。

 ・異常系テスト
異常値や、エラーが発生した場合の挙動を確認するテストです。
ロジックに応じて、様々な検証を行う必要がありますが、ここでは「日付」と「文字列」を例として挙げます。

 <例>
1.「If(日付=2021/2/28)」があった場合
①日付=2021/2/28の場合、条件OK
②日付=2021/2/29の場合、存在しない日付のため、条件NG

2.「If(文字列=A or 文字列=B)」があった場合
①文字列=Aの場合、条件OK
②文字列=10の場合、文字列ではなく数値のため、条件NG


単体テスト工程もプログラミング工程と同じで、創り上げたモノが実際に動く楽しさを一番実感できる工程なので、モノ創りが好きな方には向いていると思います。

ただ、この工程も自由な発想よりは、設計書通りに作業することが大切です。
工程の目的が、仕様通りに稼働することを確認するため、自由な発想はあまり必要としないためです。

【6】結合テスト

単体テスト(モジュール単位)で問題が無ければ、各モジュール同士を結合してテストを行います。

この工程では上流工程で作成した以下設計書を元にテスト観点をまとめる「結合テスト仕様書」を作成。そして、「結合テスト」を実施し、データの受け渡しや画面の切り替わりなど、プログラム同士が正常に連携するかをテストします。
<使用する設計書>
・外部設計書

<サンプル>結合テスト仕様書

【項目説明】
 単体テスト仕様書を同じ

単体テストとは元にする設計書が違うため、確認内容が「ロジック」単位ではなく、実際の「画面機能や帳票機能」単位の確認内容になります。

代表的なテスト観点は以下です。
 
【テスト観点】
 ・機能テスト
ソフトウェアの機能が、上流で決めた仕様通りに動作するか検証するテストです。
<テスト観点例>
「画面に 「ようこそ」を表示する」があった場合
①画面に「ようこそ」が表示されることを確認

 ・疎通テスト
システム間でリクエストとレスポンスが成立するかどうかを検証するテストです。
<テスト観点例>
ネットワークを経由するシステムA、システムBでデータ連携があり、システムAで、「名前」、「性別」、「住所」のデータが必要な場合
①システムBから、正しいインタフェース(*1)を利用し必要な項目が連携されていることを確認
(*1)インターフェース
システム間で必要となるデータを連携するために使用するもの

 ・回帰テスト
回帰テストは、リグレッションテストや退行テストとも呼ばれます。
システムの改修を行っていない部分に不具合が発生しないか(デグレ)検証します。
<テスト観点例>
処理A,Bを使うC処理があり、A処理のみ改修した場合
①処理B,Cが既存通りの挙動をすることを確認

結合テスト工程も単体テスト工程と同じで、創り上げたモノが実際に動く楽しさを実感できる工程なので、モノ創りが好きな方には向いていると思います。

この工程も自由な発想よりは、設計書通りに作業することが大切なのですが、単体テストとは違った作業を行います。
それは、「関連システムとの調整」が発生することです。
「疎通テスト」では、関連システムと正しく疎通ができることを確認するため、関連システムと「実施日の調整」や、「実施内容の調整」を行うため、テスト実施だけではなく、調整を行う必要性がでてくる工程です。
そのため、実際にモノを創るだけでなく、他のシステムの調整を経験したい方は、結合工程を経験しても良いと思います。

【7】システム(総合)テスト

プログラム同士の連携が問題なければ、ユーザが要求する機能や性能を満たしているかをテストする工程に入ります。

この工程では、この工程では上流工程で作成した以下設計書を元にテスト観点をまとめる「システムテスト仕様書」を作成。そして、「システムテスト」を実施し、開発したシステムを使用してユーザ業務が行えるかをテストします。
<使用する設計書>
・要件書

単体テスト/結合テストとは元にする設計書が違うため、確認内容がロジック/画面単位ではなく、実際の「ユーザ業務」の確認内容になります。

代表的なテスト観点は以下です。


【テスト観点】
 ・ユーザビリティテスト
開発したシステムで実際に業務を行うことや、業務シナリオを想定してユーザの操作感や使用感などを検証することが、ユーザビリティテストです。
<テスト観点例>
決済処理を行うための機能を作成した場合
①以下の画面の流れで決済処理を行えることを確認する。
決済受付画面→決済画面→決済確認画面→決済帳票出力

 ・性能テスト
実際のユーザの利用に耐えられるかどうか検証を行います。
<テスト観点例>
同時に画面アクセスした場合に、レスポンスが5秒以内の要件があった場合
①5人で同時に画面アクセスして想定時間通りにレスポンスが返却されることを確認する。

この工程も自由な発想よりは、設計書通りに作業することが大切なのですが、大きく他のテスト工程とは違った作業を行います。
それは、「顧客折衝が発生すること」「ユーザ業務を知れる」ことです。

「システムテスト」では、ユーザさんに実際にシステムを使用していただくため、システムの使用方法の説明を行う必要が出てきます。
また、実際にユーザ業務通りにテストを行うため、ユーザはどの業務でこのシステムを使用するかを知れるため、業務知識を身に付けることができる工程です。

そのため、実際にモノを創るだけでなく、実際に顧客折衝や、業務側の仕事に興味がある方は、システム工程を経験しても良いと思います。

システムリリース

ここまでが、下流工程と呼ばれる工程になり、この工程が終われば、あとは「【8】運用テスト→【9】システム移行(リリース)」の流れでリリースを行い、システム開発は完了します。
リリースしたシステムは、「【10】運用・保守工程」で、常にシステムを監視し、不具合が生じた際には即座に修正する工程になります。
この工程では、システム利用がなくなるまで発生しますが、システム開発よりは少ない人数でこなしていくことになります。

また、この工程では「保守案件」と呼ばれるシステムを改善/拡張する開発が発生します。この「保守案件」が立ち上がると、「【1】要件定義~【9】システム移行(リリース)」のサイクルで、小規模なシステム開発がスタートします。

そのため、システムリリースしたからといって、システム開発が終わりではなく、システム利用がなくなるまで開発作業は発生するので、このサイクルを続けていくことになります。

まとめ

いかがでしたでしょうか?
こちらが下流工程になります。
この工程は、実際にモノ創りの楽しさや、チームで何かを創り上げる楽しさも実感できる工程です。モノを創りたいと思っている方には、もってこいの工程ですね。

また、巷ではこの工程がITの仕事だと思っている方が大半です。
このITの醍醐味である工程に興味ある方はぜひ、チャレンジしてみてくださいね。
 
ちなみにこのシリーズ企画はこれで最終回です。各工程の良さが伝わりましたでしょうか?
私自身は、下流工程より上流工程の方にやりがいを感じますが、上流工程の良さや、下流工程の良さがこのシリーズ企画を通じてお伝えできていれば幸いです。
また何かの記事でお会いしましょう!

エンジニアのみなさまへ

フリーランスとしてより良い職場環境に行きたい・会社員だけどフリーランスになりたい等のお悩みはありませんか?
エンジニアファーストを運営している株式会社グラントホープでは転職の相談を受け付けております。

  1. 1.スキルに見合った正当な報酬を
  2. 2.忙しく働く方へ自分と向き合う時間を
  3. 3.キャリア形成のサポートを

みなさまへ新しい働き方を提案し、オンラインや対面のご相談でご希望に沿ったキャリア形成を全力でサポートいたします!

登録・応募はページ
チャットボットから!

土谷 貴志(つちたに たかし)

土谷 貴志(つちたに たかし)

システムエンジニアとして案件をこなしつつ、ライターとして執筆活動にもチャレンジ中。株式会社グラントホープ所属のフリーランスエンジニア。 システムエンジニアの他に、キャリアコンサルタントとして若者のキャリア支援や、LifeTime-Smileというコミュニティ運営など幅広く事業を展開中。 ごく稀に、コミュニティメンバーの記事を投稿するかも。お楽しみに! LifeTime-Smile:https://www.lifetime-smile.com/