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

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

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

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

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

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

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

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

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

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

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

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

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

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