システム開発を行っていくにあたり、いくつかの段階があります。
その段階を「工程」と呼びます。
工程には、様々な工程があり、それらはどのような作業を行うのか？
それら各工程で行う作業を通して、どんなことを意識しなければいけないのかを学んでください。
それらを学ぶことで、成功へ一歩近づくことができるのです。
目次
システム開発の各段階で行う工程とは？
システム開発で行う各工程は、以下で構成されます。
システム開発の工程に関しては、こちらの記事で詳しく書いていますのでご参照ください。
- 要件定義
- 外部設計
- 内部設計
- 製造（実装やプログラミング、コーディングという場合もあり）
- 単体テスト
- 結合テスト
- 総合テスト
- 受入テスト
- 納品（リリース）
- 運用・保守
それでは、各工程の作業内容について、詳しく見ていきます。
システム開発の各工程では何をするのか？
要件定義
あるユーザーが、困ったことや悩みや苦しみを、コンピューターでなんとかできないかと考えます。
例えば、日々の商品の売上伝票をいちいち紙で管理するのは面倒だし、売上の傾向や分析を行うにしても、あまりに情報が膨大で時間がかかりすぎるなどなど・・
かつて、効率化を図りたいという目的でシステム化されるケースが多く、今や事務処理は売上データをシステムに入力して、あとはそのデータをもとにさまざまなことに利用できることでしょう。請求書や領収証などもそうです。
また、ジョギングが好きな人は、走りながらでも好きな音楽が聴きたいと思い、その悩みを解決したのが、SONYのウォークマンであることは有名です。今では、iPodをはじめ、iPhoneやAndoroidのスマートホンでも、自由に自分の好きな曲を聴きながら走ったり、歩いたりできます。
このように、ユーザーが何かをコンピューターでなんとかできないか？という思いを実現させるために、解決したいことは何なのかを突き詰めて整理する工程が「要件定義」です。
解決したいことが何なのかをしっかりと理解しなければ、間違ったシステムが出来上がり、こんなシステムいらない！という終末を迎えることになります。どんなにスキルが高い技術者でも、そもそも間違った理解を正すことはできないのです。なぜなら、間違っているのが、正しいと思っているからです。
ですから、極めて重要な工程であることを認識してください。
また、通常は、この要件定義は、システム開発には含まない場合が多いです。
まずは、要件定義だけを契約し、その後、システム化を進めるかを再度確認するためでもあります。
この考えは良いと思いますが、ここで頓挫することは希です。
システム会社がお金を確実にもらうための施策と考えたほうがよいです。
この要件定義では、プロジェクトマネージャーが選出され、システム化の目的や予算や納期、必要なメンバースキル、開発手法など決めていくことが多数あります。これらが、QCDの基礎となるのです。
そして、必要なメンバーを集めていくことになるのです。
外部設計・内部設計
外部設計から、実質的なシステム開発の出発点になります。
要件定義が終わり、システム化する内容が明確になり、予算や納期が決められ、必要なメンバーも確保されたことを前提として、システム開発がスタートします。
よく外部設計と内部設計の違いが分からないという人がいますが、違いは、ざっくり以下のイメージです。
外部設計は、ユーザーの要望をシステム化していくために必要なことを決めていく作業です。
例えば、売上伝票を画面から入力させるというイメージがある場合、どんなデータ項目が必要なのか、どういうデータとしてまとめて行けばよいのか、また画面のレイアウトはどうすればいいかなどなどを考えていく作業となります。
要件定義または外部設計にて決められたことは、のちのち「仕様」として、システム開発の軸になります。
INPUTとして、ユーザーがもつイメージ
↓
外部設計
↓
OUTPUTとして、外部設計書（画面設計書、データベース定義書、データ通信仕様書などなど）
次に、内部設計ですが、こちらは、外部設計の設計書をINPUTとして、プログラミングできるレベルにするための作業となります。つまり、処理の手順を明確にしていく作業です。
INPUTとして、外部設計書
↓
内部設計
↓
OUTPUTとして、内部設計書（処理遷移図、処理手順書などなど）
製造（実装・プログラミング・コーディング）
この工程は、いわゆる、プログラミングと呼ばれる工程です。
呼び方は、Java系のプロジェクトに多い「実装」というのがイメージしやすいかもしれません。
よく学校やスクールでは、簡単な題材をもとにプログラムを書いていくことをしていますが、実際のシステム開発の現場では、プログラムを０から作ることはまずありません。
誰かが前に作ったソースコード（プログラム）を改造していく作業がほとんどです。
ですから、その現場で使われているルールに沿って、修正をしていかなければなりません。
ここに、スクールと実際の現場でのプログラミングとのギャップがあります。
自分はこう書きたいのに、ルールではできないことになっているので、やりづらい、またなんでこんな作り方してるの？と疑問に思ったり腹を立てたり、さまざまな感情が襲ってくる工程でもあります。
コメント一つにもルールがありますから、このルールに沿っていないと、バグ扱いとなり、のちのち修正せざるを得なくなることさえあります。
たとえ、プログラムの動作に関係なくてもです。
それが品質を守ることにつながるのです。
統一性があり、共通的にメンバーがイメージできるものであることは、それだけ無駄に悩む時間を省けるということにつながるのです。
単体テスト
実装したプログラムが正しく動作するのかをチェックする工程です。
このテストには、段階があります。
まずは、自分が作ったプログラムを自分がチェックする単体テスト。
この工程は、あくまで自分の範囲内で行うため、必要な試験データを手作りしたり、プログラムの動作をデバッガというツールを使いながら、ひとつひとつ確かめて行くなど、自由度が高いテストとなります。
ここの工程で自分の範囲内で起こる間違いを直すことになります。
逆にここで間違いを発見できないと、のちのち面倒になっていくのです。
例えば、請求額を画面表示させるテストの場合、マイナス金額なら、赤字で表示させるという仕様に対して、黒字のまま表示されてしまえば、これは間違い（バグ）ということになります。
これを赤字で表示されるように修正し、再度確認を行い、見事赤字で表示されればOKとなるのです。
このテストを行わなかった、あるいは気付かなかったとして、単体テストを終わらせ、次工程の結合テスト、総合テスト、ユーザーテストと移行していき、ユーザーテストで赤字にならないことが発覚した場合、当然、マイナス金額を画面表示させる全機能の再テストが要求されるわけです。
直接発覚した箇所は当然修正することになりますが、類似テストとして、同じようにマイナス金額を赤字表示している画面については、全て横並びに再テストをすることになるのです。
ひとつやふたつならまだしも、これが１００箇所、１０００箇所と数が膨大になれば、いったいどれだけの遅れになるのか、恐ろしいです。
結合・総合・受入テスト
単体テストが終わると、個人でテストをする段階が終わるということです。
そのシステムでやり方は異なりますが、機能間単位で行うのが結合テスト、システム全体として行うテストが総合テストとなります。
簡単に言うと、経理システムのような事務処理系をイメージするとわかりやすいかもしれません。
経理システムには、契約サブシステム、請求サブシステム、受発注サブシステムなどがあると思ってください。
このうち、あなたが、請求サブシステムを担当しているとしましょう。
請求サブシステムには、お客様情報管理機能、料金計算機能、請求書発行機能、入金管理機能などで構成されていることが考えられます。
そして、あなたは、請求書発行機能を担当していたとすると、単体テストは、自分が担当した請求書発行画面のみに関するテストを行うことでした。
結合テストは、請求サブシステムとして、仕様通りに動作するのかを確認するテストになります。
お客様のある月の利用分の料金を計算し、その結果をもとに請求書を発行する。そして、入金がされるのを確認するという請求サブシステム内での一連の流れを確認していくのです。
ここで、あなたの担当した請求書発行機能で何かしらの間違い（バグ）があれば、修正することになります。しかし、ここでの間違いは、機能間であればこその間違いであることが理想なのです。
それ以外は、単体テストで発見可能であり、修正できるからです。その間違いをあぶり出すためにも、単体テストではどんな確認をするべきなのかをしっかり考えることが必要となります。その項目の洗い出しは重要なのです。
そして、総合テストは、経理システム全体として、システムを確認していくのです。
たとえば、契約サブシステムは北海道で、請求サブシステムは名古屋でなどと開発拠点が分散している場合、けっこう厄介です。
間違いが発覚した場合、政治的な駆け引きがはじまり、混沌とする機会が増えます。お前らが悪いという犯人探しが活発になります。これを経験すると、地獄絵図かと思えるほどです。
そのためにも、極力、自由度の高いテストでバグを潰すことを考えてください。
最後に、ユーザーによる、受入テストです。
ここでは、ユーザーが実際にシステムを使い確認していきます。使い勝手や想定している動作になっているかなどを細かくチェックしていきます。
このテストでは、原則バグは０件のはずです。
しかし、所詮、人間がやることです。出るものは出るのです。極力出ないように努めるしかないのですが、出るときは、出ます。
そうすると、一気に信用を失います。最悪の展開しか予想できません。
そうならないように、そうしないための考え方を日頃から学ぶことをお勧めします。
納品（リリース）
受入テストに合格したら、本当にお疲れ様でした。というところです。
あとは、無事にユーザーに、そのシステムを引き渡せばシステム開発自体は終了です。
しかし、ことはそう単純ではありません。
旧バージョンからのバージョンアップだった場合、現バージョンのシステムは稼動中です。いつ、どのような手順で新しいシステムへ移行させるのかをあらかじめ計画しておかなければならず、移行計画とも呼ばれます。
実は、一番どきどきする瞬間でもあるのです。
移行に失敗し、もともとあるデータを全て削除してしまったという最悪の自体にならないよう最善の注意を払います。
この移行時は、なにかあればすぐに対応できるようにと、休日でも出勤させられたり、自宅待機させられたり緊張度が高まります。
リハーサルをして綿密に準備を行っていても、いざ本番のシステムを入れ替えるときには、魔物がいたりしますので、要注意です。それだけ、緊張度の高い作業と言えます。
運用・保守
システムを納品したあとは、システム開発のメンバーたちは、解散となります。
そのあとは、運用・保守という作業を行います。
ヘルプデスクとも呼ばれ、なにかあった時に対応する役割を担います。いわゆるアフターフォローです。
この工程で活躍する人の中に、システム管理者と呼ばれる人がいます。
ヘルプデスクのほかに、データのバックアップや、OSのバージョンアップ、ハードディスクの増設など、システムのメンテナンスを行う人です。
特に、データベースのメンテナンスとして検索スピードの改善など、かなり裏方として活躍している人たちは、かなりなスキルをもつ人たちが多いのです。
カテゴリ：システム開発の本質
