テストリーダへの足がかり,最初の一歩

第8回 テスト実装(中編)

この記事を読むのに必要な時間:およそ 4 分

【今回の登場人物】

大塚先輩:
入社10年目。5年前に柏田マネジャーと一緒にソフトウェアテスト事業を立ち上げた。カメラが趣味で,暇さえあれば写真を撮りに出かける。

中山君:
入社5年目。本連載の主人公。入社以来ソフトウェアテスト一筋で経験を積んできた。そろそろ大きい仕事をしたいと考えている。

小川君:
入社2年目。新人研修後,その有望さから半年間顧客先に常駐。テスト業務の他,設計作業も経験を積んできた。趣味はベースで,定期的に仲間とライブを行うなど仕事と趣味を両立している。

千秋ちゃん:
入社2年目。小川君の同期で,開発部門所属。今までコーディングと単体テストは経験があるが,システムテストに関わるのは初めての経験。趣味は自分磨き。

前回までの状況

新しくチームに合流した千秋ちゃんに資料を渡し,一言「テストケース作っておいて」といい残し会議室を後にした中山君。作業場所すら指示されなかった千秋ちゃんですが,だまっていてもしょうがないと直前までいた現場で使っていた席に戻り作業を開始しました。

その少しあと,中山君に任せてはみたもののやはり心配になった大塚先輩はプロジェクトルームに足を運んでみましたが,本日から合流しているはずの千秋ちゃんの姿が見えません。

元のプロジェクトの席に戻っている千秋ちゃんとその作成中の成果物を見た大塚先輩は,中山君に内線電話をかけ,会議室にくるように指示を出しました。

メンバの受け入れは計画を立てて行う

大塚先輩:
中山君,今日からメンバーが合流したはずなんだけど,もう会ったかい?
中山君:
はい,女性が一人合流したので,作業の指示を出しておきました。
大塚先輩:
で,その彼女はどこにいるんだい?
中山君:
え? たぶん自席じゃないですか?
大塚先輩:
そうだ,確かに自席にいた。しかし,その自席は今のプロジェクトではない。直前までいたプロジェクトの自席だ。
中山君:
あれれ?そうなんですか?
大塚先輩:
今のプロジェクトの作業場所を見てきたけれど,とても新しい人員を受け入れる準備がされているようには見えなかった。
中山君:
だって,突然彼女が来たので準備する暇なんて…
大塚先輩:
人員計画は以前に作ったはずだ。だから突然という話ではないよ。
中山君:
すみません,作業スケジュールしか見てませんでした。人員スケジュールは気にしていませんでした…
大塚先輩:
人を受け入れるということに,そんな態度では困る。プロジェクトにメンバを追加するということことは人を雇うということだ。人的リソースというものを真剣に考えていないことがわかるよ。

人員はプロジェクトのリソースである

読者の皆さんも経験があるかと思いますが,プロジェクトの途中で新たにメンバを増員することがあります。この場合は,テスト実装工程における人員の追加ということになります。この人員は社員であれ協力会社の方であれ,タダではありません。コストがかかっています。

ですから,リーダはそのコストが無駄にならないように,スムーズに業務についてもらうための手を打っておく必要があります。

中山君は人員が増えるというのに,受け入れ準備をまったく行っていませんでした。これから千秋ちゃんの座席やPCの手配をするとして,それがまる1日かかれば,その1日分のコストの無駄が発生してしまいます。PCやツール,機材などの物的リソースの導入計画と導入実行と同様に人的リソースについてもしっかりと考えて行動する必要があります。

逆にメンバがプロジェクトを離れることもありますが,このときは引継ぎ計画など,プロジェクトの進行に(できる限り)支障が出ないように手を打つ必要があります。

たとえば,あるツールのメンテナンスを担当している人がなんの資料も残さず,後任になにも伝えなかったとするならば,後任はイチからそのツールの情報を調べ,メンテナンス手順を立てなければならないでしょう。メンバがプロジェクトや職場を離れるとき,それはさまざまなノウハウが失われるということを意識しておきましょう。

いきなり指示はNG

プロジェクトに人員が追加されたときよく見かけるのが「いきなり指示」です。これは多くの場合追加された人員を単なる「お手伝い」としてみている場合におきます。お手伝いですから,たいした説明もせずに取りあえず何かをやってもらおうという意識のときに起こりがちです。実際にお手伝いであったとしても,スムーズに仕事をしてもらうために最低限の説明は必要です。

テスト実行工程が切迫し混乱している現場に,その状況の打開を目的として急遽他部署から応援で人員をまわしてもらうこともありますが,このときも「いいきなり指示」が往行しがちです。しかし,混乱している現場だからこそ,応援でまわされた人員が混乱しないように正確に状況を伝え,指示を出して,作業をやってもらうように気を配るべきです。

人員が追加された場合,状況にもよりますが,製品の概要はもとより,プロジェクトに関する説明,現場のルールや勤務体系,そして指揮系統などを説明する必要があります。その上ではじめて今から担当する作業の説明を始めねばなりません。

たいていの場合,いきなり指示型のリーダがいる現場は,担当者はロボット扱いされているように感じてモチベーションがどんどんと低下します。このようなリーダがいる場合は,対処を考える必要があるでしょう。入ったばかりの人になんの説明もなく,いきなり指示だけを出すのはリーダやマネージャとしては完全に失格と心得ておかねばなりません。

今回,中山君は千秋ちゃんを単なる「お手伝い」としか見ていませんでした。ですから直近の作業だけを指示しましたが,これは致命的な失敗です。

著者プロフィール

鈴木三紀夫(すずき みきお)

1992年,(株)東洋情報システム(現TIS(株))に入社。複数のエンタープライズ系システムの開発に携わり,現在は社内のソフトウェアテストに関するコンサルタントとして活動中。ASTER理事,JaSST実行委員,JSTQB技術委員,SQiPステアリング委員 他。

著書


池田暁(いけだ あきら)

2002年日立通信システム(現日立情報通信エンジニアリング)に入社。設計,ソフトウェア品質保証業務を経て,現在は開発に関する設計/テストツールの導入や,プロセス改善に関する業務に従事。ASTER理事,JaSST実行委員,品質管理学会・ACM正会員。

著書

コメント

コメントの記入