ベンダーがプログラム開発期間に入ります。ベンダーとの打ち合わせの間隔が空きます。
ほっと一息つきたいところです。
しかし最近は開発期間が短めになっていることもあり、まだまだ気を抜けません。
仕様確認
いざ開発の段階で仕様の問題点が具体化し、ベンダーから「どうしましょう」と連絡が入ります。基本的には、仕様策定のフェーズと同様のやり方で対応します。
細かいことはメーリングリストで同意を取り、必要ならすぐに社内打ち合わせを行います。
もちろん打ち合わせを行う際は、解決策の叩き台を持って・・・
恐らくベンダーはExcelなどの課題管理表で管理しているでしょうから、それをメンバーに配布し、更新してベンダーに返す、を繰り返す流れとなります。
※最近はBacklogとかクラウドで管理ですかね。やり取りの手間が省けますね。
テスト作成
要件定義と並ぶもう一つの重要ポイントです。「ベンダーとのフェーズ認識の違い」でも書きましたが、次の仮稼動フェーズは時間が足りません。
準備なしでは慌ててしまい、抜け・漏れなくテストなどできません。
事前にテスト内容を細かく考えて、テストの効率化につなげます。
関連記事：
テストシナリオは必ず各チームに考えてもらいます。
情シスでは現場の業務がわからないので、必ず抜け・漏れがあるからです。
もちろん量的にも情シスがこなせるものではありませんし。
各チームのやる気がない場合は「やらないならその部門が困るだけです」という突き放すスタンスで行きます。皆の前で言ってしまって良いです。
テストの作成と実施は、キックオフミーティングで各チームの役割に入っていたはずです。
関連記事：
基幹システム導入 仕様策定1/3-キックオフミーティング
テストシナリオは、業務的な視点で作ります。販売管理システムなら、通常の受注業務から、受注キャンセルや返品など、業務上ありうるパターンを考えます。
頻度の高い業務からイレギュラーな処理を考えると漏れが少なくなります。
最初は作るのが大変かもしれませんが、慣れるとどんどん作業が進みます。
「まず着手してみることです」と現場に伝えると良いです。
挙げた業務ごとにシナリオを考えるのですが、その際は入力値も予め記入しておきます。
具体的には、受注日や得意先コード、商品コードなどです。
販売管理システムなら、受注→出荷→売上と整合性が取れていないといけないので、それを追う際には具体的なコード類が記載されているほうが良いのです。
業務内容だけの記載ですと「さっき受注で何て打ったっけ？」となります。
コードなどをテストシナリオに記載しておくことで、テスト作業自体に集中できるようにします。
また明細部が空白状態で伝票登録するなど、ユーザは思わぬ操作をします。その辺りもテストに盛り込んでおくよう周知しておきます。
情シスの業務のテスト作成も忘れずに・・・
テストシナリオの作成状況は、定期的に全体打ち合わせでチェックし、遅れているチームにプレッシャーをかけます。
それでもやらないチームは、上司や役員に報告しておきましょう。後でトラブルだらけになった時に、情シスのせいにされないためです。
テストシナリオが出来上がったらベンダーに渡し、納品前にテストしておいてもらいます。
先にテスト内容を渡すのは邪道ですが、バグを出すこと自体がテストの目的ではないです。予めバグを取っておけるならそれで良しと考えます。
事前にテスト問題をカンニングさせているのに、それでもバグが出ます。
ベンダーさん、それは恥ずかしいことなんですよ。
次は仮稼動フェーズです。
関連記事：
