前回までの状況

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

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

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

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

大塚先輩：

中山君、今日からメンバーが合流したはずなんだけど、もう会ったかい？

中山君：

はい、女性が一人合流したので、作業の指示を出しておきました。

大塚先輩：

で、その彼女はどこにいるんだい？

中山君：

え？ たぶん自席じゃないですか？

大塚先輩：

そうだ、確かに自席にいた。しかし、その自席は今のプロジェクトではない。直前までいたプロジェクトの自席だ。

中山君：

あれれ？そうなんですか？

大塚先輩：

今のプロジェクトの作業場所を見てきたけれど、とても新しい人員を受け入れる準備がされているようには見えなかった。

中山君：

だって、突然彼女が来たので準備する暇なんて…

大塚先輩：

人員計画は以前に作ったはずだ。だから突然という話ではないよ。

中山君：

すみません、作業スケジュールしか見てませんでした。人員スケジュールは気にしていませんでした…

大塚先輩：

人を受け入れるということに、そんな態度では困る。プロジェクトにメンバを追加するということことは人を雇うということだ。人的リソースというものを真剣に考えていないことがわかるよ。

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

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

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

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

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

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

いきなり指示はNG

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

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

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

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

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

トレーニングの実行を想定しておこう

ひとしきり雷を落とした大塚先輩は、千秋ちゃんと小川君を会議室に呼びました。今後の作業を進める上で、できるだけチームメンバの意識と理解を同じ方向に向けておく必要があると判断したためです。ほどなくやってきた千秋ちゃんに大塚先輩は質問をしました。

大塚先輩：

さて、今回テストケースを作成してもらっているけれど、作業上問題はないかい？

千秋：

えぇと、いろいろあるんですが...

そういうと、千秋ちゃんは少々顔を曇らせます。その様子を見た中山君、今回の失敗を挽回しようと声をかけました。

中山君：

なんでもいいから言ってみてよ。

千秋：

ソースコードを見ないで、どうやってテストケースを書くんですか？

中山君：

えっ？　テストケース書くのに今回はソースコードは使わないよ？

千秋：

でも、私は今までそういうように仕事をしてきました。間違っていないと思います！

キツイ視線に、かっこいい先輩を見せようとした中山君はひるんでしました。その様子をみた小川君が助け舟を出します。

小川君：

千秋ちゃん、ひとつ質問だけれど、今まで担当したテストレベルの経験は？

千秋：

テストレベル？　その言葉は良くわからないけど、周りの人は単体レベルのテストとか言っていたわ。

小川君：

なるほど、どうやらコンポーネントテストしか担当したことがなさそうだね。それならさっきの言葉も理解できる。

小川君：

このテストプロジェクトで行うテストの範囲は、今まで千秋ちゃんがやってきた単体レベルのテスト、つまりコンポーネントテストではなく、システムテストと呼ばれるテストレベルなんだ。今までやってきたテストと考え方が異なるところも多いから、今までの考えは、ひとまず置いといてくれないかな。

そういうと小川君は大塚先輩に視線を移した後、中山君に向き直りこう言いました。

小川君：

中山さん、彼女にはシステムテストの経験がありません。テストケースの作成作業に入ってもらう前に、なんらかのトレーニングを行う必要があると思います。

トレーニングが必要な場合のために代替案を用意しておく

計画を立てた時点では人数だけが決まっており、実際にはどのようなスキルをもったメンバが参画するのかがわからない場合があります。ですから、いざ人員が追加されたときに、作業内容とスキルやそのレベルが合わなくなってしまう場合があります。また、その道のエキスパートという触れ込みで協力会社の方を面接採用したら、実際はそうではなかったということもあります。

しかしながら、多くの場合、メンバの変更はできません。つまり、スキルがアンマッチの状況でもなんとか作業を行ってもらわねばなりません。そこで必要になるのが「トレーニング」です。

トレーニングについてのあれこれを新しい人がプロジェクトに参画してから考えるのは遅すぎます。計画段階において、トレーニングが必要になった場合のプランを用意しておく必要があります。つまり、人員計画を立てる際にスキルがマッチしている場合の受け入れ計画（プランA）とアンマッチの場合の受け入れ計画（プランB⁠）⁠、それに付随するトレーニング計画を立てておく必要があります。

通常の場合はプランAを利用し、アンマッチであった場合に代替案としてプランBを利用するということです。当然ながら、増員されるメンバの詳細がわかったら、随時その情報をプランにフィードバックして計画をメンテナンスする必要があります。

状況を立て直す

黙って聞いていた大塚先輩が口を開きました。

大塚先輩：

中山君、どうやらいったんここは状況を立て直すことが必要だね。

中山君：

建て直し…ですか？

大塚先輩：

現在のメンバである小川君と千秋ちゃんは中山君の方針が見えないから、いったいどのように動けばいいかわからくなっているだろう。

千秋：

たいした指示もなく、今までのことはひとまず忘れろって言われても、どうしたらいいかわからなくなっちゃうわ。

小川君：

差し出がましくて申し訳ないのですが、中山さんが今後の作業をチームとしてどのように行っていきたいのか、そしてどのようなことを私達に望んでいるのかが見えないので、判断に困ることがあります。

大塚先輩：

ということだ。ここは、メンバの声を聞いてみて、チームの形を共有してみたらどうだい？

中山君：

そうか、僕は常に言いっぱなしで、背景や意図といったものについては説明していませんでした。

中山君：

皆さん、ごめんなさい。この際細かいことでもいいので、疑問があれば言ってください。

メンバの生の声を聞く

メンバが増えてきたり、作業が忙しくなってくると、どうしてもメンバとのコミュニケーションがおろそかになってきがちです。ですが、コミュニケーションが希薄になると、プロジェクトにおけるさまざまな情報の伝達が行われなくなってしまいます。実作業のこともあれば、プロジェクトの問題点、改善につながる情報、メンバの体調やメンタルの状況などさまざまです。情報が流れないということは何か大きな問題が発生した場合のエスカレーションも行われなくなるということです。

こうなると、ある日突然問題が顕在化して、いわゆる「炎上」状態となりかねません。日ごろからメンバの声を聞くことはリーダとして必要な仕事です。常にメンバのことを気にかけたり、ときに懇親会を開くなどして生の声を聞く努力を怠らないようにしましょう。

プロジェクトの方向性を伝える

プロジェクトの進む方向性を伝えることは、リーダの仕事の中でとても大切なことです。「⁠プロジェクトの方向性は、テスト計画に書いてあるのでそれを読めば分かる」と言ってメンバに説明しないリーダもいます。しかし、それは間違った姿勢です。自らの言葉で説明し、メンバが誤解しているようであれば、即座に正すようにすべきです。

このような状況を立て直さなければならない事態に陥った場合は、プロジェクトが何に向かって進んでいるのかを説明しなければなりません。ただでさえ蛇行しているのですから、プロジェクトに軸を作らなければ、立ち直らないからです。

プロジェクトの目的やゴールを再確認する

個人ごとの作業が増えてくると、どうしてもその個人レベルでの視点で物事を見がちになり、ひとつの作業を終わらせることが目的やゴールと錯覚してしまいます。そこで、今一度本来のプロジェクトの目的やGoalはなんであるかを確認し、各自の作業の位置づけを確認してもらいます。これにより、プロジェクトの中で自分がどの役割と責を担っているのかが明確になり、作業がブレなくなります。

また、目的を共有することで皆の意識の方向を同じ方向に向き、プロジェクトの目的に向かって全員が一丸となることができます。「⁠われわれは今回何をするのか」「⁠なんのためにするのか」などを常に意識する文化の醸成もリーダの仕事かもしれません。

今一度指揮系統を確認する

プロジェクトが混乱しているとき、多くの場合指揮系統や報告ルートも混乱しています。誰から指示を受けて誰に報告すればよいのかわからないのであれば、責任の所在が不明確になったり、報告が適切に行われなくなってしまい、さらなる混乱を招きます。

千秋ちゃんはこのあたりの説明をされていないため、大塚先輩を事実上のリーダとして理解し、中山君をリーダとして意識していません。つまり、千秋ちゃんの報告は中山君ではなく大塚先輩にされることになり、本来その報告を受けるべき中山君はその内容を知らないままになってしまいます。

体制図はこれを防ぐためのひとつの策です。単なるメンバ構成図ではないことを意識しておかねばなりませんし、リーダとしては指揮系統や報告ルートをメンバに対し徹底しなければなりません。

膠着したら仕切りなおそう

大塚先輩：

話し始めるといろいろと問題点が出てくるね。どうだい、中山君？

中山君：

えぇ、いかに自分がリーダの仕事をしていなかったか痛感してます。

大塚先輩：

そこでだ。いったんここで仕切りなおしてみたらどうだい。

小川君：

そうですね、私もそう思います。これだけ話が盛り上がってくると際限がなくなってきて、愚痴レベルの話も出てきますし、雑談になってもいけませんから。

千秋：

そうね、一度クールダウンしたいわね。随分長いことしゃべっちゃったし、もう疲れちゃった。

中山君：

実は僕も頭がパンパンです…。

大塚先輩：

じゃぁ、そうしよう。休憩だ。

会議は長いと能率が低下する

大塚先輩はメンバに疲労の色が見え始め、膠着し始めたのを察知して、会議の仕切り直しを提案しました。だらだらと会議していても意味がありません。むしろ少し時間を置いて、各自の頭の中が整理できた段階で再開したほうがよほど能率があがります。中山君は自分の頭がパンパンであることもあり、一度仕切りなおすことにしました。

3時間後、メンバは再度会議室に集合し、冷静になった頭でチームの状態やプロジェクトについての情報を整理・確認して意識をあわせることができました。そして、その場で小川君から作業レベルでの問題点や疑問も共有しておこうという提案があり、トレーニングの件もあるのでまずは千秋ちゃんの作ったテストケースを見ていくこととすることになりました。

さてさて、どうなることでしょう。