プロジェクトメンバーからの学び

改めて実感したことを書きます。
プロジェクトリーダーとしても以下のポイントを持って、大きな学びを得られました。

ポイント①：「原理原則ではどうなの？」を判断基準にする
ポイント②：メンバーに極力お任せする。

ここ2年ほど携わっているプロジェクトでは、自分の知見がない分野について、学んだことが多々あります。（現在進行形）
このプロジェクトでは、リーダーやってます。
リーダーであるがゆえに、自分の知らない分野のことについても判断をすることも多々あります。

問われたことについて、「どう判断したものやら？」というシーンは多々あります。私は「わからないのに判断したくない」という気質もあるので、わからないところはわからないのを自分で学んだり、教えてもらったりしています。
そんな時に、「どんなこと考えてるんだっけ？」というのを文章にしてみようかな、と思い、このnoteを書いています。

「原理原則ではどうなの？」を判断基準にする

最終的に判断するにあたって「なぜそれで良いのか？」「OKの基準は？」を考えるわけですが、それを考えてるときは「原理原則ではどうなの？」が基準になっています。

判断をした後に、設定を一つ一つ確認してみるとかして、「あぁ、判断は正しかった。よかった。」とか「あれ、間違ってるな。。。修正してもらうかな。」とか見返してみて、判断の良し悪しを現物で確認します。

この現物確認が、学びになります。
そこからドキュメントとも突き合わせてみると、「あぁ、そういう設定もあったのね」ということも改めて知れたりします。このような後からの体系化が自分にとっての学びになります。

このプロジェクトではおかげさまで、AWSについて学び、ネットワークの基礎を学ぶことができました。このあたりを意識しないままアプリケーションの開発ができてしまっていたのですが、このようなシステム構築にあたってのインフラにも目を向けられるようになったのは大きな進歩だったと思います。

メンバーに極力お任せする

以前のチームでは、比較的自分の知見でカバーできることが多かったため、「全部自分で指示しないといけない」と思っていました。

これだと、自分の理解以上のことはプロジェクトではできないし、仕事も自分がボトルネックになってしまうし、メンバーは指示待ちになるし、良いことはありません。

できるかできないかは自分では判断せず、まずはお任せしてみる。
「xxxのことは、▲▲さん！」という決め打ちもせずに、とりあえずお任せ。
ゴールも、若干ふわっとした状態のままでも構わず渡す。（丸投げに思われたかも？）

やってみてもらうと思ったよりできるものです。
自分の思っていた段取り通りの場合もあれば、思っていたのと違うけど、より良い成果が出たりして、自分の考えが浅かったと思わされたり。
自社の採用でもいい人取ってもらってるよね、というのも実感できたりします。

ただし、期間には余裕を持たせる。ここはリーダーの務めだと思います。
自分がやるなら3日と思ってるなら5日は確保する、といったように。
学ぶにしても、納期は守らないといけませんので。

さいごに

大きな山は越えられた感じがありますが、まだやることは残っています。
油断はせずにしっかり終わらせたいと思います。