#はじめに
　ソフトウェア開発の各工程について独断と偏見でまとめてみました。これは、会社ごとやプロジェクトの性格で大きく変わるのでひとつの例と思ってください。

#工程
開発工程ですが、ざっくり言って下のような感じのことが多いようです。
これは、プロジェクトの規模や性格で下の工程の一部が省略されたりすることもあります。また、会社により呼び方が違うことがあります。

受注前の作業
要件定義
基本設計
詳細設計
製造・単体テスト
結合テスト
システムテスト
移行
運用

#受注前の作業
これを行う機会があるとすれば、元受の正社員が主だと思います。営業からの案件情報を元に客先にプロポーザルを作ったりします。
新規案件だと競合他社が受注してしまい、せっかくの資料が無駄になることもあります。当然、この作業は間接費で行うので、あまり時間はかけられません。そのため、短時間で説得力のある資料が作れる社内でも特に優秀で経験の豊富な人が担当することになります。
客先とは、技術的な内容だけでなく費用についての事項も確認して、どこからどこまでが有償なのかを明確にして、覚え書きのようなものを作り決済権のある方の承認印をもらっておきます。

#要件定義
ここからが普通、有償作業になりますが、客先との共同作業なので見積通りに作業が進まず、予算オーバーということもあります。さらに、聞いていた話より規模が大きくなりそうなんてこともよくあります。
よって、場合によっては、予算の見直しが必要になるかもしれません。

要件定義の成果物として「要件定義書」が作られます。この中では、すべての要件が網羅されている必要があります。

要件があいまいであると目的とするアプリケーションとは違ったものができてしまう可能性があるので、完全にあいまいさを排除する必要があります。そのため、客先の担当者と要件の文言一つ一つについて詰める必要があります。

文言は「～すること」「～できること」のようにし、～は可能な限り具体的な文言にします。さらに、わかりやすいように図表を入れて誤解がないようにします。

「要件定義書」は客先との共同作業で作られた成果物であり、双方が内容に責任を持ちます。よって、双方の責任者の承認を得る必要があります。

通常、要件定義は経験豊富で情報技術のスキルの高い上位エンジニアが行います。ただし、客先との交渉や打合せが頻繁に行われるので、いくら優秀でもコミュニケーション不足のエンジニアには向きません。

さらに社内向けの要件を追加します。これは、不具合が発生したときに、その解析に使用するためのログや性能要件などです。

#基本設計
基本設計はそのシステムが外から見てどのようなものであるかを定義する工程です。そのため、外部設計やインタフェース設計などと呼ばれることもあります。

また、具体的にどのように機能を実現するかの方式設計もこの工程に含まれます。方式設計にはハードウェア構成やタスク設計、データベース設計、通信設計などが含まれます。

さらにできあがったものがテストできないと困るので、テスト設計もここで行っておきます。

この工程の入力は「要件定義書」ですが、社内の設計規約のようなものがあれば、それも入力となります。

要件定義書だけでは、入力として十分な情報量がないことが多いので、客先の担当者との Q/A (質問とその回答一覧) も要件の一部になると考えられます。このようなものも会社間のやり取りなので通常、責任者の承認が必要です。

この工程の成果物は、プロジェクトの性格により異なりますが、例えば、次のような感じになります。

システム構成図
外部設計書
インタフェース設計書
方式設計書
テーブル定義書
ファイル定義書

さらに、要件がすべて盛り込まれているのを確認するための「要件/設計値対照表」のようなものも成果物として必要です。これは、詳細設計の入力というよりは、客先向けの資料で、客先の承認を得る必要があります。

#詳細設計
詳細設計は基本設計の成果物の内容をコンピュータプログラムとして実装するかを設計する工程です。そのため、実装設計などと呼ばれることがあります。

この工程の入力としては、基本設計の成果物の他、独自フレームワークのマニュアルなどがあります。

ただし、これらを完全に適用した場合、未経験者が習熟に時間がかかったり、規約違反でやり直しなんてことも有り得るので、どこまで適用するのかを決めておく必要があります。

詳細設計では基本設計の成果物から開発ツール(例えば Visual Studio)でのプロジェクトイメージに展開します。具体的には、プロジェクト名の定義やシンボルの定義、クラスの定義など具体的な実装イメージを定義します。

詳細設計の成果物としては「詳細設計書」を作ることになりますが、これはかなりの量になり、そのレビューや保守には多大の時間がかかります。

よって、保守が不要な設計メモ程度の扱いにした方が現実的です。

そして、レビューはチーム内で簡単に行う程度でよいかと思います。

レビューの観点は主に基本設計の内容が適切に盛り込まれているかとか、とんでもない勘違いをしていないかとかでよいと思います。

もし、詳細設計書ではなく設計メモ程度の物しか作らないのであれば、プロジェクトとその構成物を作ってコーダー(プログラマー)にばらまけるようにします。

具体的には、Visual Studio で言えば、ソリューションエクスプローラーに表示されるプロジェクト構成とその構成物(クラス、フォルダ、スタイルシート、スクリプト・・・)です。

これら構成物の中身は空っぽでコメントのみ記述しておきます。

##この工程で必要なスキル

プログラミングスキル
単体テストの経験(テストのことも考えてプログラミングできる)
ExcelやWord(最近はExcelでドキュメントを作ることが多い)

#製造・単体テスト
この工程は人手がかかるので、プロジェクトルームは満杯になるかもしれません。もしかしたら、工程ごと外注ということもあります。

この工程では、詳細設計の成果物を元にコーディングを行います。コーディングに際しては、「コーディング規約」のようなものが決まっていることが多いです。その場合、コーディング規約にしたがってコーディングしますが、規約が何年も前に作られたもので古かったりすると、便利な機能が使えなかったりするので、あまり厳密に適用すると現実的でないこともあります。

コーディングは一気に行うのではなく、少しづつ動作確認を行いながらやった方が効率的です。

単体テストは、メソッドごとに行い、ある入力に対して結果がどうなったかを確認します。画面などは自動テストは難しいですが、ロジックだけのメソッドなら自動テストを行えるようにしておくと効率的です。

ただし、自動テストのためのテストプログラムはけっこう長くなるので、それなりの手間が必要です。

また、外部環境が整っていないと実行できないメソッドもあるはずですが、そういうものは「スタブ」(テスト用のデータを供給し結果を受け取るテストプログラム)を作成する必要があります。

この工程の成果物は、プログラムソースと単体テスト成績書、自動テストプログラムなどです。単体テスト成績書には、「エビデンス」(画面ハードコピーや出力ファイルなど）を添付します。

ただ、一般的にこの工程ではテスト項目が多いので、エビデンスは代表的なものだけに絞ります。

テスト項目は「正常系」「異常系」に分けて定義します。テストの入力値は「限界値」「境界値」などを含めます。
限界値とは整数で言えば最大の整数値や最小の整数値、境界値は整数なら０などのことです。日付で言えば、うるう年の2月29日などの検証も必要です。

テーブルを扱う場合などは、テーブルが空の場合なども必ずテスト項目に含めます。

##この工程で必要なスキル

プログラミングスキル
単体テストの経験(デバッガの使用)
Excel(単体テスト成績書作成)

#結合テスト
結合テストは、基本設計どおりにシステムが出来上がっているかを検証するために行います。

結合テストは、文字通りサブシステムを結合してシステムとしてテストする工程ですが、実際には、チーム内で作成したクラスどうしの結合テストもあります。このようなテストは、通常は単体テストフェーズで行います。

また、製造・単体テストを一括外注したときは、「受け入れテスト」を行う必要があります。

この工程は、製造・単体テストの後から始まるのではなく、基本設計の後から始めます。というのは、テスト仕様書を作る必要があり、さらにテスト環境の整備やテストデータの準備が必要なためです。

受け入れテストが必要な場合は、受け入れテスト仕様書の作成が必要であり、受け入れテストはシステムインテグレーション(各チームの成果物を結合する作業)の前までに終わっていなければなりません。

この工程では人手があまり要らなくなるので、各チームのプログラマレベルの人は終了となり、リーダーやサブリーダークラスの人だけで対応することが多いです。

この工程の成果物として、結合テスト成績書とプログラム(ソースと実行プログラム)が作成されます。

#システムテスト
システムテストは、要件定義の結果がシステムに完全に盛り込まれているかを検証するために行われます。

結合テストは検証環境で実施されますが、システムテストは実環境と同等の環境、小規模なものなら実環境で実施されます。

この工程もテスト仕様書を作成するため、基本設計が終わったら開始します。

テストは実際の運用と同じテスト項目を実施して問題のないことを確認します。よって、実際の運用を考えてシナリオを作りそれに基づいて検証を行います。

例えば、売り上げはあったが入金がなかったケースとか、消費税が１０％に上がったとき、その前後の月の消費税の請求が伝票に正しく反映されるかとか、ありとあらゆるケースを想定してシナリオを作ります。

この工程は、客先のあらゆる業務に精通している必要があるので、シナリオ作りには客先の担当者も参加する場合があります（が普通です）。

最終的にテストが終了すると、テスト成績書を客先に提出して承認を受けます。これにより納入が可能になり、元受はやっと検収をしてもらえることになります。

#移行
全くの新規でない限り、既存システムが稼働しており、その移行が必要になります。

移行の前には新システムを使っていしばらくテスト運用を行います。安定稼働が確認できたらシステム移行が行われます。

移行に際しては、移行手順書のようなものを作り、リハーサルを行います。

移行手順書には、発生しうるありとあらゆるケースを含めておく必要があります。

もし、移行に失敗したら、業務が停まらないように旧システムに戻す必要があります。

#運用
移行がうまくいったら、新システムに切り替えて運用を行います。

それでも安定稼働しないケースがあり、旧システムに再び切り替えるということもあります。

大きいシステムでは、安定稼働と復旧のため、SEが常駐などということがよくあります。これは、有償のこともありますが、出来の悪いシステムだと無償になり開発会社が大手でない場合は損失が穴埋めできなくなり経営的に大きな打撃になりますね。

不具合が見つかったら、ログを解析して原因を見つけますが、簡単に直せないようなものだと、元の開発者が呼び出されて対応させられるなどというケースもあります。

稼働開始からずっと安定しないようだと、損害賠償を請求されるケースもあります。