以前の 「準委任契約の特性について考える（その３）」 という記事で、
システム開発の各プロセスにおける準委任契約の適用などについて記載しました。
その際、超上流工程からシステム運用テストまでについての記事を、一旦、この時期に整理してみようと思いつきました。
そのような理由から、以下のプロセスに分けて、今までの記事を整理したいと思います。
１．システム化企画
２．システム要求定義
３．システム要件定義
４．システム基本設計
５．システム詳細設計～結合テスト
６．ソフトウェア総合テスト
７．システム総合テスト
８．システム運用テスト
９．その他、データ移行など
１．システム化企画
まずシステム化企画については、事業戦略の理解が重要になります。
その際、戦略が曖昧な場合には、ロジカルシンキングを用いて経営環境（外部／内部）や事業戦略などを構造化・整理する必要性があります。
そのロジカルシンキングに関する私の考え方などついては、次の記事をご参照下さい。
「ロジカルシンキングの実践（その１）」
「ロジカルシンキングの実践（その２）」
「ロジカルシンキングの実践（その３）」
また事業戦略等の理解に向けて、私が特に参考にした図書を次の記事で紹介しています。
「〔参考図書〕事業戦略」
「〔参考図書〕バランス・スコアカード」
その他、システム化構想策定までの全般的なポイント等については、次の記事をご覧下さい。
「超上流工程（広義の要求定義）の基本プロセス（その２）」
２．システム要求定義
このプロセスは、ユーザ企業が独力もしくは（私のような）外部コンサルタントの支援を受けつつ、システムへの要求事項（機能要求、非機能要求）を導出し、「システム要求定義書」または「システム要求仕様書」としてとりまとめしていくプロセスになります。
その後、ＲＦＰ（システム提案依頼書）の発行と提案評価等により、システム構築ベンダーを選定していきます。
私は、このシステム要求定義プロセスの品質が、それ以降のシステム構築プロジェクトの成否を決定づけるように感じています。
そのシステム要求定義等のポイントに関する私の考えは、次の記事をご参照願います。
「超上流工程（広義の要求定義）の基本プロセス（その３）」
「要求定義と要件定義」
その他、このプロセスでは「業務分析」が重要になります。
その点に関しては、次の記事をご覧下さい。
「現状業務の分析」
「業務プロセスの記述について」
３．システム要件定義
このプロセスは、システム構築ベンダーの支援を受けて、ユーザ企業の責任で実施することが大切です。
なお、２．で高品質な要求定義が完了している場合、また、中規模以下のプロジェクトにおいては省略します。
また、このプロセスもしくはシステム基本設計プロセスあたりから、構築ベンダーが本格的にプロジェクトに参画し、一般的には「システム構築プロジェクト」がスタートすることになると認識しています。
そのプロジェクトのスタート等に関しては、以下の記事をご参照願います。
「プロジェクトのキックオフ会議」
「プロジェクトのキックオフ会議（その２）」
なお、プロジェクト計画にとって、ＷＢＳ（Work Breakdown Structure）」は最重要ポイントになります。
そのＷＢＳに関する私の考えは、以下の記事をご参照願います。
「ＷＢＳはプロジェクト計画のポイント」
「ＷＢＳはプロジェクト計画のポイント（その２）」
４．システム基本設計
このプロセスでは、ユーザー部門にしっかりと関与していただくことが大切になります。
その点に関する私の考え方は、次の記事をご参照下さい。
「基本設計フェーズにおける注意事項など」
５．システム詳細設計～結合テスト
６．ソフトウェア総合テスト
ソフトウェアの総合テストにおいては、網羅性のあるテストケースづくりが重要であると考えています。
それに関しては、次の記事で私の考え方を記載しています。
「ソフトウェアの総合テスト」
７．システム総合テスト
システム総合テストでは、パフォーマンステストや負荷テストなど、非機能要求に対応するテストが重要に
なります。
それに関しては、次の記事で私の考え方を記載しています。
「システム総合テストの重要性」
８．運用テスト
運用テストは、顧客の状況も考慮した上で、いろいろな支援の方式を考える必要があります。
それらについての私の考え等は、次の記事をご覧下さい。
「顧客のシステム受入テスト（運用テスト）」
９．その他、データ移行など
例えば、基幹業務システム刷新時などについては、データ移行やシステムの切り替えなどを、
極力、段階的に実施したいと考えています。
その点に関する私の考え方については、次の記事をご参照願います。
「データ移行は慎重な対応を」
「システム切り替えは慎重な対応を」
その他、操作研修なども大切です。
これを実施しないで運用テストに突入せざるを得ないケースも発生しますが、混乱？に拍車をかけることになりますので、やはり操作教育はしっかりと実施したいものです。
その点に関する私の考え方については、次の記事をご参照願います。
「システム操作研修を定義する」
以上、今までの記事を整理してみました。
ご覧になられた方に対し、少しでも参考になればうれしく思います。
なお本ブログの記事は、随時、修正していく可能性があります。
あらかじめご了承願います。
＜その他の関連記事＞
「超上流工程におけるＢＡＢＯＫの有効性（その1）」
「超上流工程におけるＢＡＢＯＫの有効性（その2）」
「超上流工程におけるＢＡＢＯＫの有効性（その3）」
「超上流工程におけるＢＡＢＯＫの有効性（その4）」
「超上流工程におけるＢＡＢＯＫの有効性（その5）」
「プログラムマネジメントの有効性（その1）」
「プログラムマネジメントの有効性（その2）」
「情報システムのテストに関する顧客企業側のポイント」
「〔参考図書〕システム要求定義の基本」
「準委任契約の特性について考える」
「準委任契約の特性のついて考える（その２）」
「準委任契約の特性について考える（その３）」
「準委任契約の特性について考える（その４）」
システム開発の各プロセスにおける準委任契約の適用などについて記載しました。
その際、超上流工程からシステム運用テストまでについての記事を、一旦、この時期に整理してみようと思いつきました。
そのような理由から、以下のプロセスに分けて、今までの記事を整理したいと思います。
１．システム化企画
２．システム要求定義
３．システム要件定義
４．システム基本設計
５．システム詳細設計～結合テスト
６．ソフトウェア総合テスト
７．システム総合テスト
８．システム運用テスト
９．その他、データ移行など
１．システム化企画
まずシステム化企画については、事業戦略の理解が重要になります。
その際、戦略が曖昧な場合には、ロジカルシンキングを用いて経営環境（外部／内部）や事業戦略などを構造化・整理する必要性があります。
そのロジカルシンキングに関する私の考え方などついては、次の記事をご参照下さい。
「ロジカルシンキングの実践（その１）」
「ロジカルシンキングの実践（その２）」
「ロジカルシンキングの実践（その３）」
また事業戦略等の理解に向けて、私が特に参考にした図書を次の記事で紹介しています。
「〔参考図書〕事業戦略」
「〔参考図書〕バランス・スコアカード」
その他、システム化構想策定までの全般的なポイント等については、次の記事をご覧下さい。
「超上流工程（広義の要求定義）の基本プロセス（その２）」
２．システム要求定義
このプロセスは、ユーザ企業が独力もしくは（私のような）外部コンサルタントの支援を受けつつ、システムへの要求事項（機能要求、非機能要求）を導出し、「システム要求定義書」または「システム要求仕様書」としてとりまとめしていくプロセスになります。
その後、ＲＦＰ（システム提案依頼書）の発行と提案評価等により、システム構築ベンダーを選定していきます。
私は、このシステム要求定義プロセスの品質が、それ以降のシステム構築プロジェクトの成否を決定づけるように感じています。
そのシステム要求定義等のポイントに関する私の考えは、次の記事をご参照願います。
「超上流工程（広義の要求定義）の基本プロセス（その３）」
「要求定義と要件定義」
その他、このプロセスでは「業務分析」が重要になります。
その点に関しては、次の記事をご覧下さい。
「現状業務の分析」
「業務プロセスの記述について」
３．システム要件定義
このプロセスは、システム構築ベンダーの支援を受けて、ユーザ企業の責任で実施することが大切です。
なお、２．で高品質な要求定義が完了している場合、また、中規模以下のプロジェクトにおいては省略します。
また、このプロセスもしくはシステム基本設計プロセスあたりから、構築ベンダーが本格的にプロジェクトに参画し、一般的には「システム構築プロジェクト」がスタートすることになると認識しています。
そのプロジェクトのスタート等に関しては、以下の記事をご参照願います。
「プロジェクトのキックオフ会議」
「プロジェクトのキックオフ会議（その２）」
なお、プロジェクト計画にとって、ＷＢＳ（Work Breakdown Structure）」は最重要ポイントになります。
そのＷＢＳに関する私の考えは、以下の記事をご参照願います。
「ＷＢＳはプロジェクト計画のポイント」
「ＷＢＳはプロジェクト計画のポイント（その２）」
４．システム基本設計
このプロセスでは、ユーザー部門にしっかりと関与していただくことが大切になります。
その点に関する私の考え方は、次の記事をご参照下さい。
「基本設計フェーズにおける注意事項など」
５．システム詳細設計～結合テスト
６．ソフトウェア総合テスト
ソフトウェアの総合テストにおいては、網羅性のあるテストケースづくりが重要であると考えています。
それに関しては、次の記事で私の考え方を記載しています。
「ソフトウェアの総合テスト」
７．システム総合テスト
システム総合テストでは、パフォーマンステストや負荷テストなど、非機能要求に対応するテストが重要に
なります。
それに関しては、次の記事で私の考え方を記載しています。
「システム総合テストの重要性」
８．運用テスト
運用テストは、顧客の状況も考慮した上で、いろいろな支援の方式を考える必要があります。
それらについての私の考え等は、次の記事をご覧下さい。
「顧客のシステム受入テスト（運用テスト）」
９．その他、データ移行など
例えば、基幹業務システム刷新時などについては、データ移行やシステムの切り替えなどを、
極力、段階的に実施したいと考えています。
その点に関する私の考え方については、次の記事をご参照願います。
「データ移行は慎重な対応を」
「システム切り替えは慎重な対応を」
その他、操作研修なども大切です。
これを実施しないで運用テストに突入せざるを得ないケースも発生しますが、混乱？に拍車をかけることになりますので、やはり操作教育はしっかりと実施したいものです。
その点に関する私の考え方については、次の記事をご参照願います。
「システム操作研修を定義する」
以上、今までの記事を整理してみました。
ご覧になられた方に対し、少しでも参考になればうれしく思います。
なお本ブログの記事は、随時、修正していく可能性があります。
あらかじめご了承願います。
＜その他の関連記事＞
「超上流工程におけるＢＡＢＯＫの有効性（その1）」
「超上流工程におけるＢＡＢＯＫの有効性（その2）」
「超上流工程におけるＢＡＢＯＫの有効性（その3）」
「超上流工程におけるＢＡＢＯＫの有効性（その4）」
「超上流工程におけるＢＡＢＯＫの有効性（その5）」
「プログラムマネジメントの有効性（その1）」
「プログラムマネジメントの有効性（その2）」
「情報システムのテストに関する顧客企業側のポイント」
「〔参考図書〕システム要求定義の基本」
「準委任契約の特性について考える」
「準委任契約の特性のついて考える（その２）」
「準委任契約の特性について考える（その３）」
「準委任契約の特性について考える（その４）」