情報システムのテストに関する顧客企業側のポイント

今回の記事では、少し「情報システム」のテストについて、顧客側でのポイントについて記載したいと思います。
なお、情報システムのテストにつきましては、今まで以下の記事で、自分なりの考え方をご紹介しました。

　　「ソフトウェアの総合テスト」
　　「顧客のシステム受入テスト（運用テスト）」

それらに記載されている内容も含めて、今回、ＩＰＡ「共通フレーム２００７」や経済産業省「情報システム・モデル取引・契約書」で整理されている事項と関連付けし、少し私の考え方を再整理してみたいと思います。


なお、明らかに構築ベンダーの責任範囲となる「単体テスト」や「ソフトウェア結合テスト」については、今回の記載内容には含まれません。
あらかじめご了承願います。


まず、「共通フレーム２００７」や「情報システム・モデル取引・契約書」において、
原則として顧客側で実施責任があると解釈可能なテストを列挙してみます。

＜共通フレーム２００７＞
1.6.10_システム結合　※開発者による実施や支援も必要に応じて選択する
1.6.11_システム適格性確認テスト　※同上
1.6.13_ソフトウェア受入れテスト
1.7.2_運用テスト

＜情報システム・モデル取引・契約書＞
・システムテスト（共通フレーム２００７の「1.6.11_システム適格性確認テスト」に相当）
　　　※構築ベンダーも関与する場合、請負契約または準委任契約で業務委託する
・受入・導入支援（共通フレーム２００７の「1.6.13_ソフトウェア受入れテスト」等に相当）
　　　※構築ベンダーの支援を求める場合、準委任契約で業務委託する
・運用テスト（＝共通フレーム２００７の「1.7.2_運用テスト」に相当するものと認識）
　　　※構築ベンダーの支援を求める場合、準委任契約で業務委託する

おおむね以上のようになります。

以下、基本的にＩＰＡ「共通フレーム２００７」の言葉を用いて記載を進めます。
（一部、あえて別の言葉を利用します。）


これらのテストでは何をテストするのか？についてですが、所謂「Ｖモデル」がその答えになります。
1.6.10_システム結合　は、1.6.3_システム方式設計　のとおりに開発されたかのテスト、
1.6.11_システム適格性確認テスト　は、1.6.2_システム要件定義　のとおりに開発されたかのテスト、
などの考え方により、テストを実施することになりますね。


それらも考慮しました上で、私はまず、
「上流工程において、顧客が構築ベンダーへ請負契約で業務委託していない範囲については、原則、それに対応するテストは顧客の責任で実施する必要がある」
と考えています。

しかし、顧客側の組織体制や技術力などでは、十分なテストを独力で実施できない場合が多々あります。
その場合においては、「構築ベンダーによるテスト支援」を受けて実施する必要性がある、と考えています。

更には、それらの支援作業をシステム構築契約の締結前に明確化しておく必要があります。
それらを明確化するノウハウが顧客側にない場合、（私のような）外部コンサルタントの支援を受けることが得策であると考えています。

また構築ベンダーのテスト環境ではＯＫでも、顧客側の環境ではＮＧという事態も発生します。
そのため、前述の「構築ベンダーによるテスト支援」の必要性はやはり高いと考えられるのですが、
それ以前に、十分な総合テストを構築ベンダーに実施いただくことが重要です。

あらかじめ利用環境を明確化しておき、それに極力近い環境での総合テスト（実運用予定のハードウェアやＯＳ等の提供、または実運用環境での構築ベンダーによるテスト）の実施を構築ベンダーの責任範囲で実施していただくことが大切です。

私は、それがソフトウェア総合テスト（1.6.11_システム適格性テストに近い概念）のポイントであるように感じています。
顧客側の情報システム部門の人員が乏しい（または情報システム部門が存在しない）場合などにおいては、原則として、構築ベンダーに請負契約で実施いただくことを明確化します。
また実際のテスト内容についても構築ベンダーから確認し、不足していると感じられる事項（テストケースを含む）は是正していただくよう、顧客側をご支援します。

次に、受入テストや運用テストについてですが、
これも顧客側の情報システム部門の人員が乏しい（または情報システム部門が存在しない）場合などにおいては、十分な実施が難しい場合があります。

よって、受入テストについては、
　　・構築ベンダーサイドで実施した総合テストのケースを利用して受入テストする
　　・特定部門や店舗についての過去（できるだけ長期間）の伝票を再入力してもらってテストする
　　・操作研修を受入テスト期間で実施する
などの工夫が必要になる場合があります。
少し乱暴に思われる内容もあるかもしれませんが、気をつけませんと、結局のところ受入テストをユーザー部門に協力していただけない、ということも発生する場合がありますので、いろいろ工夫も必要だと私は思っています。

また、運用テストについてですが、
これは既存システムの更改時には、完全並行運用を実施いただく必要があります。
実際のところ、この完全並行運用の結果をもってシステム合否判定がされますので、私は受入テストと運用テストを一体のものとして見なす場合があります。
更に、ユーザーの負担を軽減する工夫が必要になる場合があります。
完全並行運用の期間や拠点等を最小限にする、などの対応が、その一例になります。
これらにつきましては、過去の記事「顧客のシステム受入テスト（運用テスト）」をご参照下さい。


以上、情報システムのテストについて、私が考える顧客企業サイドのポイント等を再整理してみました。
少し疑問に思う内容もあるかもしれませんが、何かの参考になれば嬉しく思います。


＜関連記事＞
「超上流工程からシステム運用テストまでにおける考慮事項」

「準委任契約の特性について考える」
「準委任契約の特性のついて考える（その２）」
「準委任契約の特性について考える（その３）」

リスク・タスク・課題の管理

さて、前回「超上流工程からシステム運用テストまでにおける考慮事項」という記事で、
システム構築プロセス全般において、私が顧客をご支援する際の考え方などに関する本プログの記事を一旦整理してみました。

そのシステム構築においては「プロジェクトマネジメント」は重要です。

また、システム化の「超上流工程」や　システム構築を含まない「施策」の検討をご支援させていただく際にも、「プロジェクトマネジメント」の手法・考え方などを参考にしています。

その「プロジェクトマネジメント」の実践時によく感じることについて、今回、記載してみようと思います。


それは「リスク管理」「進捗管理」「課題管理」についてです。

私は、簡単に記載しますと、次のような理解をしています。
「リスク管理は、リスク・リスク要因と対策を検討し、問題発生の予防・軽減策をあらかじめ実施するためのもの」
「課題管理は、顕在化した問題への対策を検討し、発生した問題を解決するためのもの」
「進捗管理は、プロジェクトの進捗管理そのもので、（タスクの集合体の）スケジュールの進捗状況を統合して管理するためのもの」

このリスクへの対応、課題への対応、そしてタスクの管理についてですが、
すべてが混在してしまうケースがあります。

例えば、
「本来は各フェーズのタスクの一つであるはずなのですが、重要なタスクが漏れていた、あるいは重要視すべきタスクであることを後で気づいた、ということ等から、そのタスクを課題として『課題管理表』で管理する」
「リスク分析と管理まで手がまわらず、途中で発見されたリスクへの対応については、課題として『課題管理表』で管理する」
というケースです。

これらのケースは、未熟なプロジェクトマネジメントの例として紹介されているようですが、
実際のところ、私がご支援するプロジェクト（顧客の課題・施策検討プロジェクトを含む）でも発生することが多いです。

いろいろ悩むこともあったのですが、私は、それでも良いと思っています。

課題・施策検討や超上流工程（システム化企画から要求定義まで）（注１）をご支援させていただく際、
いろいろ不明確な状況から課題・施策・要求などを導出・明確化していくことになりますので、
「実際には、当初のＷＢＳやプロジェクト計画からでは、詳細なタスクを決定できない場合も多い」
と感じています。

（注１）
私は要求定義と要件定義は言葉を使い分けています。それについては本ブログの記事「要求定義と要件定義」をご参照願います。
また、超上流工程プロセスに関する私の考え方は、次の記事をご参照願います。
　　「超上流工程（広義の要求定義）の基本プロセス（その１）」
　　「超上流工程（広義の要求定義）の基本プロセス（その２）」
　　「超上流工程（広義の要求定義）の基本プロセス（その３）」


特に顧客サイドのみに実施していただくタスクは、プロジェクトの状況に合わせてつつ、具体的に決めていくものもあります。

その際、「通常のタスクだが、特に重要なタスク」「リスクへの対応のためのタスク」「問題解決のためのタスク」が混在するような状況になります。

しかし繰り返しになりますが、私は「課題・施策検討」「超上流工程」に関するプロジェクトにおいては、それでも良いと思っています。

よって、今は「タスク・課題管理表」というものを使って、プロジェクト・マネジメントをご支援しているプロジェクトがあります。
これで顧客サイドで対応すべき「重要なタスク」「リスク対応へのタスク」「問題解決のタスク」を明確化し分類しながら、実行状況を管理させて頂きます。

これは、大規模なシステム構築プロジェクト（注２：要件定義以降）ではマズい方式であるとは理解しています。

しかし、その方式で十分な効果が得られる、または、その方式でないと（マネジメントする場合の）実践が難しい、というケースにおいては、それで良いと思っています。


今回の記事については、異なる考えの方も多いと思います。
しかし、私が顧客サイドのご支援をする場合には、プロジェクトの特性にもよりますが、実際に効果的であると感じています。


＜関連記事＞
　超上流工程からシステム運用テストまでにおける考慮事項

現状業務の分析

あるプロジェクトで、現状分析がスタートしています。
現状分析は、お客様との信頼関係を構築していく段階の場合も多くあり、
いろいろな面で神経を使うことも多いですね。

さて、この現状分析については、プロジェクトの目的や性質により異なるのですが、
概ね、次のような進め方をしています。

　　　① 目的や方向性（目標、暫定版レベルの「あるべき姿」）の確認
　　　② 現状の把握
　　　③ 問題点の導出と原因分析
　　　④ 課題設定

この、「①目的や方向性の確認」と「②現状の把握」がプロジェクトとして効果的に進めば、
自ずと「③問題点の導出と原因分析」　と　「④課題設定」　も円滑に進むと思っています。

よって、「現状の把握」は重要ですね。

その「現状の把握」は、主に、次のような手段を用いています。

　　　・既存ドキュメント類の確認
　　　・指標や関連数値の確認
　　　・インタビュー
　　　・アンケート等による意見収集
　　　・上記を業務プロセス図等のドキュメントで整理

繰り返しですが、これらはプロジェクトの目的や性質によって、柔軟に対応します。


この「現状の把握」の段階で、ある程度、顧客の気持ちを捕らえる必要があると思っています。
逆の言い方をしますと、顧客に不安を与えてはいけない、ということです。

少しレベルの低い話になりますが、

まだ全社レベルも含めた信頼関係が構築されていない場合、
顧客企業のミドル層やロアー層は「こいつは何者？」という感情を抱く場合も多いと、私は思っています。
この感情に負けず（？）、お客様からの「信頼」を獲得していく必要があります。

そこで大切になるのは、「インタビュー」だと、私は思っています。

うまくお伝えできませんが、
インタビューで、相手方に程よい好感を抱いていただく必要があると思います。

これは、「相手のご機嫌を取る」ということではありません。
ポイントは、相手の話を傾聴し、「しっかり伝わった」という風な印象を持っていただくことに尽きると思います。
さらに、トップ層やミドル層が相手の場合には、インタビューのテーマに沿う意見交換も交えるべきだと思っています。

言うは易しですが、実際には困難な場面にも遭遇します。
具体的な事例は省略しますが、
しかし、いろいろな困難は、「実践による経験」と「事前準備」でしか解決できない、と考えています。


なお、「現状業務の分析」においては、やはり、業務プロセスを記述することは大切です。
それらの考え方については、過去の記事の、
「業務プロセスの記述について」
をご参照下さい。
ＵＭＬによる業務モデリングに関する参考図書も紹介しています。

また、問題点の導出や原因の分析においては、ロジカルシンキングが大切です。
それらに関します私の考え方は、過去の記事の、
「ロジカルシンキングの実践（その１）」
「ロジカルシンキングの実践（その２）」
でご紹介しています。

プロジェクトのキックオフ会議（その２）

もう直ぐ、あるプロジェクトのキックオフ会議が実施されます。
ちなみに、システム関連がメインではなく、「業務プロセス見直し」（業務改善）がテーマです。

私は、極力、キックオフ会議には、組織ＴＯＰ（経営層など）に参加していただきます。

理由は、組織ＴＯＰから、
　　・本プロジェクトが組織にとってたいへん重要であること
　　・本プロジェクトの成果に大きな関心と期待をもっていること
などを、直接、キックオフ会議で伝えていただくことで、メンバーのモチベーションを高めていただくためです。


少し話しは変わるのですが、各フェーズの区切の会議でも、組織ＴＯＰに参加していただきます。
また普段から、「どうなっている？」とメンバーへ質問していただくことも良いですね。

このように、組織ＴＯＰには、プロジェクトのモチベーション維持へのご支援もお願いしています。


いずれにしても（当然ですが）、
キックオフ会議は、ただの顔合わせではなく、有意義な場にする必要があります。

あらためていろいろ考えて見ますと、キックオフ会議の目的は、以下のようなことかな？と思えてきました。

　　１．プロジェクト計画の共有
　　２．プロジェクト運営上の基本ルールの共有
　　３．当面の実施事項、スケジュール、役割分担の共有
　　４．プロジェクト目標達成に向けたモチベーションの向上


以前の「プロジェクトのキックオフ会議」という記事では、
情報システム構築のキックオフ会議について、上記の１～３について触れました。

それに４．が加わるようなイメージです。


ちなみに、４．の「モチベーション向上」などのために、キックオフ会議後の「飲み会」を実施する場合もありますね。
私は、プロジェクト完了後の「飲み会」は大好きなのですが、キックオフ時は少し苦手です。
しかし、比較的大きな規模のプロジェクトの場合、キックオフ後に「飲み会」は実施するようにしています。

プログラムマネジメントの有効性（その1）

ある２つのプロジェクトで、少し悩んでいることがあります。
それは、プロジェクト全体のマネジメントと、各テーマ・各施策ごとのマネジメントについてです。

今までは、あまり悩むことなく対応してきました。

事業戦略（重要戦略課題）からブレイクダウンされた各テーマ（システム化テーマ、施策など）については、
論理的に整理可能な内容で構成し直し、
その１つの集合体ごとを１プロジェクトとして立ち上げ、
その中の重要な工程、課題・テーマ、施策については、サブプロジェクトとしてマネジメントしてきました。

記載してみてのとおり、
実は、私なりに戦略課題や各テーマ（上位／下位）とプロジェクト（プロジェクト／サブプロジェクトイ）との関係を、うまく整理できていなかった可能性があるようです。

（ただし、単一システムや基幹システム刷新などのプロジェクトで且つ機能別の段階リリースが不要なものについては、今までの考え方で問題ないと思っています。）


そこで、今まで勉強してこなかったのですが、
「プログラムマネジメント」の考え方が使えないかを、少し調べてみようと思いました。

「プログラムマネジメント」とは、
「新版Ｐ２Ｍプロジェクト＆プログラムマネジメント　標準ガイドブック」（企画：日本プロジェクトマネジマント協会／編著：Ｐ２Ｍガイドブック改訂委員会／発行：日本能率協会マネジメントセンター）
におきましては、
「全体使命を実現する複数のプロジェクトが有機的に結合された事業である」と定義されています。

少し抽象的ですが、私は、ある戦略課題を複数の施策（システム化含む）で実現する場合、
その個別施策が「プロジェクト」で、その施策群と戦略課題（または戦略課題群）が「プログラム」に位置づけられる、と現段階では解釈しています。

そのように解釈・整理し実践（マネジメント）ができれば、かなりスッキリするように感じています。


しかし、その「標準ガイド」の内容は、少し抽象的で、具体的なものではないように感じています。
あくまでも、「標準ガイド」ですので、それで当然（十分）なのかもしれません。

その内容をどのように咀嚼し実践に取り入れようか（仕組み化しようか）を、少し検討し試行実施したいと思います。

また、プロジェクトマネジメントのように、もう少し実践的で具体的な手法が記載されている図書や雑誌記事が出てくることも期待したいと思います。


＜関連記事＞
　プログラムマネジメントの有効性（その2）

　超上流工程からシステム運用テストまでにおける考慮事項

新版 P2Mプロジェクト&プログラムマネジメント標準ガイドブック 日本プロジェクトマネジメント協会 日本能率協会マネジメントセンター このアイテムの詳細を見る