皆さんはどのように理解しているでしょうか。またリーダとしてどのように取組めばよい工程でしょうか。
中山君の例で一緒に考えていきましょう。
【今回の登場人物】
- 大塚先輩：
- 入社10年目。5年前に柏田マネジャーと一緒にソフトウェアテスト事業を立ち上げた。カメラが趣味で、暇さえあれば写真を撮りに出かける。
- 中山君：
- 入社5年目。本連載の主人公。入社以来ソフトウェアテスト一筋で経験を積んできた。そろそろ大きい仕事をしたいと考えている。
テスト設計
前回大塚先輩に大目玉をくってしまったテスト分析もなんとか終了。「なんとなく」で行ってしまったテスト分析にもう一度しっかりと取り組み、何回かのアドバイスをもらいつつ大塚先輩に再提出することになりました。
大塚先輩：- さて、テスト分析も終了だね。
中山君：- はい、ようやく終わらせることができました。本当にボクはなにもわかっていなかったんですね。ご迷惑をおかけしてばかりです…。
中山君は、はじめてまともに取り組んだテスト計画とテスト分析の苦労に、精神的にも肉体的にも疲労がたまりつつありました。いつになく神妙な中山君を見た大塚先輩、次のように声をかけました。
大塚先輩：- 初めてのときは誰もが上手くいかないものだよ。…スケジュールを見ると、マイルストーンだね。このマイルストーンがなにかわかるかい？
-
中山君：
- あ！ 中打ち上げって書いてあります！
実は、この時期にそろそろ精神的にも疲れてくるだろうと読んでいた大塚先輩は、テスト分析の終了後に「中打ち上げ」を計画に入れるようにアドバイスをしていたのでした。
-
大塚先輩：
- そういうわけで、今日は仕事を早めに切り上げて飲みにでも行ったらいい。本日ばかりは定時きっかりに仕事を切り上げること。残業はナシ。これは命令だ。
-
中山君：
- 「お心遣いありがとうございます！ リフレッシュして、また明日から頑張ります！」
中山君は初めてのリーダーということもあり気が回りませんでしたが、メンバのモチベーションと健康状態を注意深く観察し、必要ならば休養などを与えるのも大切な仕事です。
プロジェクトが始まり作業が進むと、最初は高かったモチベーションもだんだんと低下していきます。また、作業が遅れていると、残業に次ぐ残業でメンバは体力的にも疲弊していきます。気力も体力も低下すると注意力が散漫になります。そうすると、ミスが多くなりますから、プロジェクト全体としてもパフォーマンスが下がっていき、開発スピードが遅くなっていきます。そうすると日程が遅延していくことになります。日程が遅延するため、リーダがメンバに残業を強いるとさらにメンバは疲弊していき…
リーダーはこういう状況に陥らないように、定期的なプロジェクトの疲労のリフレッシュを行う必要があります。日ごろからメンバ一人一人の気力・健康状態にまで気を配り、問題があれば早めに手を打たねばなりません。
またもちろんのこと、そういった健康やモチベーションの維持のための施策はプロジェクトの計画に入れておくべきです。日々強いられる残業の連続で体調を崩してしまった人に対して「アイツは打たれ弱い」などと簡単に評価するのは、リーダとして傲慢で、職務の怠慢であることを強く理解しておくべきです。
次の日
次の日、中山君は幾分スッキリした顔で出社しました。それを見つけた大塚先輩、ほっと安心したようです。
-
大塚先輩：
- うまくリフレッシュできたようだね。
-
中山君：
- はい！ 残念ながらまだチームといっても私だけなので旧友と飲みに行ったのですが、仕事を忘れて盛り上がることができて、いい気分転換になりました！
-
大塚先輩：
- それは良かった。昨日君が体験したようなことは、リーダーとして必要になる仕事のひとつだ。そろそろメンバも増員されるから、意識しておくように。
-
中山君：
- わかりました！ さて、いよいよテスト設計ですね。今度こそは頑張ります！
気分的にひとつ整理がついた中山君、最初の頃のやる気を取り戻したようです。
-
大塚先輩：
- 僕は今までテスト計画とテスト分析でいろいろとアドバイスをしてきた。今回はそれを活かして取組んでみなさい。
-
大塚先輩：
- ただし、これまでは全体を作り込んでから確認を行ってみたけれど、まず小さい範囲でやってみて、それを確認してみたい。
中山君：- まず一部だけ設計して、先輩に見てもらうってことですか？
-
大塚先輩：
- そうだ。もし基本的なミスが指摘事項が多かった場合、その修正に大きな労力がかかるからね。
-
中山君：
- 傷は小さな方がいいってことですね！ 了解です。まずは基本的なテスト設計を行ってみます！
席に戻ってきた中山君、今の失敗とアドバイスを振り返りました。
-
中山君：
- さて、まずは、テスト分析の後の工程だな。えーと…。
今まで中山君は「自分の思い込み」で仕事を進めてきましたが、ようやくそれからは卒業できそうです。早速、イントラネットで参照できる「社内の標準テストプロセス（図1）」を確認しました。
図1 SEPIAシステム社のシステムテスト・標準テストプロセス
-
中山君：
- あれれ？ 『テスト設計』って工程がないぞ？
標準テストプロセス図を見ても「テスト設計」という工程が見当たりません。実は中山君の社内プロセスでは特別にテスト設計という工程は定義されていません。ただし、この標準テストプロセス図とは別に用意されているテストプロセス詳細という文書では、テスト設計は「テスト実装」の中で行う"作業"として定義されています。
しかし、連載第1、2回で作成したテスト計画では「テスト設計」工程を定義しています。
これはいったいどういうことなのでしょうか？ 実は大塚先輩は、まだまだ経験が浅い中山君にテスト設計という作業をちゃんと行わせたいがために、"敢えて"テスト計画時にテスト分析とテスト実装の間にテスト設計を入れる事を指示していたのでした。これはメンバの資質にあわせて「プロセスをカスタマイズ」したということです。
テスト計画を立てた時点では、まだ中山君は社内のテストプロセスについての意識がほとんどありませんでした。ですから、「先輩がそう言うのなら」と何の疑問も持たず工程として設定しました。残念なことに（この時点においても）中山君は大塚先輩の意図を理解はしていません。
-
中山君：
- 小さい範囲って言っていたから、要するにテストケースの雛形を作ればいいのかなぁ…。
また悪い癖がでました。わからなければ大塚先輩に聞きに行けば良いのに、怒られれるのがイヤで大塚先輩のところに行きません。
-
中山君：
- まぁ先輩がやれっていうんだから、やらなきゃいけないんだろうなぁ。
ふと過去自分が仕事をしていたプロジェクトを思い出すと、同じテストチームの先輩達が「テスト設計は大事だよなぁ」とか「今回のテスト設計は難しいな」とか話していた事を思い出しました。なんとなく、やらなきゃいけない作業であることは想像できました。
-
中山君：
- うーん、これはきっとテストケースを作るときに注意して、テストケースのたたき台を作るってことなんだよね
-
中山君：
- よし！ 今度こそは頑張るぞ！
そう意気込むと、中山君は早速テストケースを書き始めました…。
2日後
2日がたちました。先輩の言いつけ通り、まずは基本的なところだけ（図2、図3）のテスト設計に取組んでみました。その結果が図4となります。
図2 画面仕様書からの抜粋（1）
図3 画面仕様書からの抜粋（2）
図4 テストケースのたたき台（テスト設計のドキュメント）
さて、皆さん。
このテスト設計結果は、どのような問題点があるでしょうか？ また、中山君にどんな指導をしたらよいでしょうか？
皆さんも大塚先輩の立場になって考えてみてください。
