プロジェクト新規加入メンバーに一週間で成果を示せと言われている

のである。ここでは、自分の考えを整理するためにつらつらと書いていく。

もともとは、２人のＢＰさんのうち欠けた１人をプロパーでまかなうことになったのだが、その人のキャリアや人柄？がお客様のＰＭには魅力的に映らなかったらしい。プロジェクトも佳境の折、人員が減るのと新規メンバー加入によるスタートアップの手間が増えるのとで天秤に掛っているわけである。

メンバー加入は明日の月曜からなのだが、部長の計らいで木曜の夕方にその人に会う機会をいただいた。一週間で何かを残さなければいけいときに、弊社メンバーにとっても月曜に「初めまして」ではうまくないだろうということだ。もっともである。常駐先のオフィスの近くのコーヒーショップで彼と顔合わせをした。彼は自分よりも１年だけキャリアと年齢が上であるそうだ。卒業後すぐにキャリアがスタートしたのならば院卒ということになるが、そうでない場合はちょっと困ったちゃんであるということになる。他の業界から移ってきたのか、２年どこかで足踏みしたということだからだ。まぁ自分もその後者であるわけだが……。

物静かな印象が過ぎ、進んで仕事の中に自分の居場所を見つけていこうという姿勢は感じられなかった。かねてより「自分から動いてくれ」と言っているお客様のＰＭならばこのような人柄は敬遠されるのだろうと第一印象からは感じられた。

自分はその後の親睦会（まぁ飲み会）には用事があって参加できなかったのだが、それに参加した先輩のＭＰＭによるとずいぶん控えめな人柄だということである。自分の印象では「お酒を飲むと人が変ったようにおしゃべりになる」というものだったが、そんなことはないようである。

一番長く経験したプログラム言語はJavaだということで、４年くらい経験があるらしい。しかし、仕事も保守ばかりで、バージョンも1.4までだということだった。プロジェクトはJava6で開発しており覚えることも多かろう。うちのＰＭは木曜の会見では「気楽に」とか「大丈夫」を連発していたが、本当にそんな気構えで来られたら現場の自分たちが大変である。緊張感と使命感は持っていてもらいたいと思う。

致命的だなと思ったのはJUnitの経験がなく、最近ＰＭにそれを連絡され急いで勉強しているところだと発言されたことだった。JUnitの経験がないJava開発者は数年前まではそれほど珍しくはなかった。ただ、自分よりもキャリアが長い割に「テストの自動化」や「回帰テスト」に興味を持つことがなかったとはどういうことだろうと思う。しかも、その発言の中に既にエクスキューズが入っており、先が思いやられるなぁと思ったものである。

ただ言われたことをずっとやっているタイプだとＭＰＭは感じているようだ。「何か問題があったら一人で抱え込んでないですぐに言って欲しい」と言う。自分は積極的に周囲に話しかけて行くタイプではないし、逆に周囲の人間に話し掛けてもらえるような雰囲気作りも苦手だ。それもあり、自分としては、初めのうちは何か問題があったら何でも質問してきてもらいたい、というよりは、彼が困っているようなオーラを出していたら傍観していないで周囲がフォローすればいいと考えている。その方が質問で自分の作業を止められることもない。

さて、本題はここからだ。彼に、月曜から何をしてもらおうかということだ。

自分は一応開発現場のリーダーを任されており、彼に何をやってもらうか指示をしなければいけないのである。問題なのは、Javaの経験も極めて薄く、JUnitについては経験もない彼に一週間で成果を出してもらえるようなことをしてもらわなければならないということだ。

彼のタスクとしては、

1. スタートアップに際して現場の人間の負担も少なく、
2. 定量的に日々の作業の成果をお客様のＰＭに示すことができ、
3. その作業自体がプロジェクトに実際に貢献するようなもの

これが最良だ。ＰＭはJUnitをやってもらうのが良いと考えている。現在は開発ばかりが先行されJUnitは後回しになっている。もちろんそれは手が足りないためで、彼を加入させる必要性を説く際にＰＭがお客様ＰＭに言ったのも「このまま一人減らしてしまうと品質を保てない」ということだった。確かにJUnitならばテストケース数や発見バグ数、担当プログラム数、カバレッジ率など定量的な評価基準も豊富でお客様への報告がしやすい。

しかし、それには現時点で次のような問題がある。

1. システムの仕様や業務内容が不明で、そもそもJUnit未経験の人間が一人前のテストケースを書けるのか
2. 当然、自分やＭＰＭがサポートをするが、そもそも彼の人柄と不明なことだらけのJUnitではほとんどつきっきりになる可能性が大である。それではお客様ＰＭにも「手間が増えている」の印象が強く映りはしないか
3. JUnitは慣れれば単純作業であるが、自分くらいの年齢の人間がひたすらテストをやり続けることができるのか
4. 現在、評価基準のひとつでありお客様ＰＭが比較的重要視しそうなカバレッジ率を効率よく取得する手段が確立できていないため、その報告がしにくい
5. だいたい、プロジェクトの成果物として実際に有用なJUnitを書くことは非常に難しい。 次のようなことを満たしているかレビューが必要である。
   1. 正しいJUnitが書けたのか、
   2. テストケースの条件は満たされているか、
   3. そもそもケースは有用か、重複するケース、意味のないケースはないか
   4. テスト対象のプログラムに追加や修正があった場合に対応しやすいか、
   5. 他の人がメンテナンスしやすいか

2.に関しては、お客様ＰＭが会議中などでいないときに席を囲んだり、昼休みの外食時を利用することが挙げられる。この一週間はスクランブル状態であり、昼休み返上で仕事の話をすることも我慢してもらわなければいけない。

3.については、短いコンタクトで感じたところでは、彼の人柄はこれに耐えられそうである。テストケース数、プログラム本数という結果が明確に出ることもあり、単純作業も淡々とやっていってくれそうである。自分にはとてもまねできないのであるが、、。

4.は全く取得できないということではないし、取得するタイミングと報告のタイミングを調整すれば最新の結果を報告することも可能だと考えている。ただ、１ケースでもテストに失敗するとカバレッジが取れないという条件付きであるため、完成度の高いテストプログラムが求められることになる。

1.、5.は自分がレビューするしかないと思う。自分は一応JSTQB Foundation Levelの資格保持者だからね。この資格自体は大したことないのだけれど。会社の資格報奨金の対象外でもあるし、そもそも人事はこの資格のことなんて知らないんじゃないだろうか。

ここまで考えてみると、自分が、自分のタスクを他の作業者にちゃんと振ることができるか、という問題であるように思う。自分はチケットに上がったタスクのうち、誰にも振られていないものを「とりあえず自分が」とたくさん抱えている状態なのである。

とりあえず月曜に出社して自分が真っ先に行うべきことは、未消化のタスクを列挙、整理して、他のメンバー（自社のメンバーではないため本当は自分に指揮・命令の権限はないのだけれど）に割り振ることだろう。

なんのことはない。新加入の彼の技術力やモチベーション、コミュニケーションスキルを論じる前に、自分のリーダーとしての仕事を全うすることが解決の近道なのかもしれない。

もちろん、自分が作業をするということではなく、他人に作業をやってもらうという仕事という意味だ。