今参画しているSES先のQAチームで、プロジェクトのリーダーを任されることが増えた。プロジェクトといっても一つのプロジェクトは工数でいうと30人日とかそういう規模なので、小さいものなのだけど。
1人きりのプロジェクトを任されることもあるので、必ずしも「リーダー＝メンバーを抱える」ではないのだけど、メンバーを抱えた場合に非常に苦労している。特に以下の2点で苦労している。
- テストケースの抜け・漏れのせいで、実施時にメンバーから質問がくる
- 仕様を把握してない or 誤った把握でテストケースを作っていて質問がくる
改めて書き出してみると「全て自分のせい」であることがわかり頭を抱えている。こんなリーダーの元で作業をしなくていけないメンバーは苦労するだろう。じゃあ逆に良いリーダーってどんなリーダーなのか。実は今までよく考えてきたことがなかった。
このエントリーでは、あくまでのQAのプロジェクトに関してのリーダー論になるので、対象が非常に限定的になります。いわゆるシステム開発におけるリーダー論とも多少ずれてくる部分はあると思うし、あまり一般的な話にはならないかもと思っています。
良いリーダーとは
実際メンバーとしてプロジェクトに参加しているとき、「なんかこのプロジェクトは嫌だな」と感じることが少ない時があるが、そういう場合「良いリーダーがプロジェクトを率いている時」なのだろうと思う。じゃあ具体的にはどういうことなのだろうか？
- 仕様の抜け漏れがない
- 仕様についてメンバーからの問い合わせにすぐ回答できる
- 把握できていない仕様についての問い合わせ先を把握している
- 必要な情報を社内ネットワークなどからすぐに取得できる
- 必要な情報を察知できる
- 質問をしやすい雰囲気を持つ
- 突発的なことに割と冷静に対応できる
仕様の抜け漏れがない
もちろん全てを完璧に把握しているわけではないが、抑えるべきところは抑えている。たとえ漏れや抜けがあったとしてもリカバリーできる程度にきちんと理解している。
仕様についてメンバーからの問い合わせにすぐ回答できる
Slackで問い合わせがあったときなど、レスポンスが早い。2時間とか放置しない。問い合わせへの回答があるまで作業が止まることもある。
把握できていない仕様についての問い合わせ先を把握している
完璧超人ではないので、ど忘れしてしまうこともあるがそういった時に、どのチームの誰に問い合わせをすればいいか、把握している。日頃からそういった人との信頼関係を築いていて聞きやすい確認しやすい人間関係を構築している。
必要な情報をすぐに取得できる
最近はConfluenceなどの社内ワークスペースを使うことが当たり前になってきているが、それらに格納されている情報に対して検索してすぐに情報の取得を行うことができる。またConfluenceに書かれている情報がシステム寄りだったり、英語だったりしても理解することができる。
必要な情報を察知できる
個人的にはこれが結構大事だと思ってるのだけど、仕様書などに書かれていないが、実は当たり前となっている機能や処理やまた単純に仕様書を記載した人が書き漏らしたことに対して「これも必要ですね？」と察知できる。当然ある程度業務や機能に対しての経験値が必要な部分ではあるがたとえ業務知識が浅くても「AだったらBも必要になる」という風に頭の中で紐付けがすぐに出来る人がいるが、そういう人に私はなりたい。
質問をしやすい雰囲気を持つ
質問を受け付けるのを嫌がる人、感情の波が激しい人（普段穏やかでも忙しくなってきてキャパシティを超えたら急に不機嫌になる人）、そういう人は割と多いが、そうではなく常に安定した態度で、質問そのものを受け付ける人。「これは前にも言いましたよね？」と言いつつちゃんと聞いてくれる人がいいですね。
突発的なことに割と冷静に対応できる
プロジェクトの最初から最後まで一つも例外が起きずに終わることはまずないが、実際に想定してないような事象が起きた際にどれだけ冷静に対応できるかというのはある程度リーダーの資質に必要なことじゃないだろうか。自分で対処できること、自分だけでは対処不可能なこと、今の段階では判断つかないこと、それぞれを的確に判断して対処できるようなリーダーにはどうやったらなれるのか...
ダメなリーダーとは
ほとんど自分のことなので、挙げるのはしんどいのだけど、多分こんな感じではなかろうか（あまり自己批判に終始するのも新興宗教とかセミナーぽいので嫌なのだけど）
- 対象のプロダクト、またはプロジェクトの概要・仕様を把握できてない
- テスト設計段階で抜け・漏れが発生する
- 作業の分担をうまく捌けない
- 作業を抱え込みすぎてパンクする
- 質問への回答レスポンスが遅い
- 作業進捗を把握してない
- 想定外の事象にうまく対応できない（パニックになる）
対象のプロダクト、またはプロジェクトの概要・仕様を把握できてない
例えばいろんなプロジェクトを抱えるPMが関わるプロジェクトの全てのプロダクト仕様を把握できてないのは仕方ないが、プロジェクト専任のリーダーがプロダクトやプロジェクトの概要や仕様をきちんと把握できてないのはまずい（気がする）。
設計段階で抜け・漏れが発生する
プロダクト、プロジェクトにおける設計仕様を把握できていなければ当然そのテスト設計時に「抜け漏れ」が発生するのは当然といえる。テスト設計で抜けや漏れが発生すればテスト実行時に実際のプロダクトとの齟齬が発生する。
「テスト仕様書は正しく書かれている」前提にあるからテスターは「なぜか仕様書とプロダクトが一致した動作をしない。これはバグなのか、それとも仕様書の不備なのか」と本来不要である思考する時間が発生し、時間を取られることになる。そしてその疑問を解消するためにリーダーに質問し、リーダーが確認し回答するという二重三重の時間が取られることになる。これではテストが予定通りに進まない。
作業の分担をうまく捌けない
作業分担は結構悩ましいもので、全員が同じ知識経験を持っていれば平均的に割り振ればいいだけの話だがそうもいかない。メンバーそれぞれの経験や知識をある程度把握した上で割り振らないといけないわけだが、これって決まった方法論があるのだろうか？例えば自分より後から参画したメンバーでもテスト経験という意味では何倍も知識量が上のメンバーがいたりするケースもあったりして（つまり業務経験が乏しいだけ）判断に迷う。
作業を抱え込みすぎてパンクする
作業の割り振りがうまくいかず、「だったら自分でやった方がいい」と抱え込んだ結果、週次のミーティングや割り込み作業・ミーティングにより時間が取られて想定のパフォーマンスを出せず潰れる。実際自分がメンバー時に作業の割り振りをされた時でも「割り振られたからには頑張る」という認識に立って作業を実施するのに、なぜか自分が作業を割り振る立場になった途端に「こんなに作業を押し付けていいのだろうか？」という「遠慮」のようなものが発生してうまくできなくなる現象。
質問への回答レスポンスが遅い
タイミングにもよるが、妙にレスポンスの遅い人がいる。特にリモートワークをしていると質問先の人がどのような状態にいるか把握できないのでレスポンスが遅いと「寝てるのか？」と思ってしまう。そうでないにしても質問者は今の作業を進めるために質問をしているので、素早いレスポンス（それが直接回答にならなくても、質問を受けたことを了解するレスポンスをするなど何らかのアクションを取らないと質問者の作業が止まる場合もある）が必要。
作業進捗を把握してない
作業を割り振ったはいいが、どこまで作業を進められているか把握できてない。これは「今日はここまでやる」というような目標がないことも要因にあると思う。つまりその日の作業目標を立てられていないか漠然としている。作業の進捗がよくわかってないといつまで作業を続けるべきなのか困惑するメンバーも出てくるだろう。
想定外の事象にうまく対応できない（パニックになる）
これはリーダー業務に関わらず、なのだけど想定外の事象があったときに思考が停止してしまうことが多い。近い過去に同じことが起きていればある程度対処する方法について考えられることもできるが、全く知らないことだったりするとその時点で何をすべきかが浮かばない。当然ボーッとするわけじゃなくて「誰か」に対処方法を聞いたりすることくらいはできるのだけど、マズイのは「どうしましょうか？」という質問などに対してあまり考えもせずに勘で「こうしましょう」などと回答してしまう場合がままあるということ。
はっきりいって自分自身を見つめ直すいい機会になったエントリー、というだけで果たしてこれが記事を読みにきた方の参考になるのかどうか・・・
