何年か前に、仕事でプロジェクトのリーダーをやったことがあって。
リーダーと言っても、チーム自体は自分含めて3人の小さな規模だったけれども
そこで犯した失敗について、最近ふと思い出すので書いてみようと思います。

 

チームメンバーは、
・私(リーダー)
・自社の後輩(PG)
・パートナー会社からの常駐(PG)
という構成。

私がお客さん(元請。我々は2次請けにあたる)に対する窓口となり、
プロダクトの仕様について話し合った後に、
決まったことをPGメンバーに下ろして、実際にコードを書いてもらう。
で、出来上がったプロダクトの動作をチェックして、
問題が無ければ、お客さんに連絡して確認してもらう。
そういう業務フロー。

割と順調に進んでいた(と思っていた)プロジェクトでしたが、
ある時、常駐のPGが、体調不良を理由に欠勤する頻度が増えた。
最終的に、欠勤の頻度を理由に、常駐PGとの契約は切れたのだが、
常駐PGは弊社の営業に対し、「出社するのが嫌になった」と語ったという。

その時はその理由に対して、あまりピンとこなかった私だったが、
時が経って当時を振り返ってみると、原因は私にあったのだと痛感する。

当時、常駐PGにも自社の後輩にも均等に仕事を割り振っていたが、
彼らが書いたコードをチェックする際、
仕様理解の齟齬などによる軽微なミスを見つけた際に、
彼らに差し戻すのではなく、私の方で修正をしていた。

当時の私は、
「説明しながら差し戻すよりも自分で直した方が早い」
くらいの気持ちで修正していたと思う。
多分それが不味かったんだろうな。と、今になって思う。

こうした場合の正規のフローとしては、
コードを書いた担当者に対し、
仕様と挙動との不整合を説明した上で、修正を依頼するのがセオリーだろう。
それを私せず、彼らの成果物を勝手に改修していた。

ある日、常駐PGのコードをレビューしていた際、以下の記述を見つけた。

「// このコードは完成しているため変更禁止」

当時の私は、この記述について特に気にしてなかったか、
笑いながら見ていたと思う。
「いやいやいやいや。」
「完成してるかどうかを判断するのはこちらの仕事だから」
と。

今思えば、常駐PGのこの「訴え」に、真摯に耳を傾けるべきだった。
時間をかけて、自信を持って書いたコードが、知らぬ間に書き換えられているのは、
あまりいい気分ではなかったと思う。
そうした配慮を、私の方で欠いていた。
チームメンバーに対する敬意が足りていなかった。

思い返せば、学生時代にも同じようなことをやっていて。
高校の生徒会時代や、大学のゼミ時代にも、後輩に
「もっと周りを頼ってください」
「もっと俺たち(後輩)を信じてください」
と言われたのを、今でも時々思い出す。

多分なんだけど、他人を信じて何かを任せるというのは、そうしたスキルなんだと思う。
私は、今でこそ後輩に仕事を振ったり、上司に仕事を投げたりしているが、
そうすることが出来なかったことにより、鬱を発症し休職したことがある。
そうした経験が無ければ、今でも人に何かを任せるという「能力」を
培うことは出来ていなかったかもしれない。

「自分を守る為に、誰かを信じる」という選択は、ありなのだと思う。
 あなたも、誰かに「もっと私に頼って欲しい」と思われているのかもしれません。