🤦‍♂️

良くないリーダーにありがちなこと

2023/10/12に公開

プロダクトマネジメント

idea

はじめに

自身の経験を踏まえ、こんなリーダーはプロジェクトを失敗させてしまいがちだよねという内容を挙げました。

絶対的な正解だと主張するものではないので、「あるあるー」とか「いやそこは違うでしょ」とか思いながら気楽に読んで頂ければと思います！

最悪自分でなんとかすればいいやと考えてしまう

ある程度実装力を持ったエンジニアになると、「人に任せるより自分でやった方が早いんじゃないか・・・？」という考えが頭をよぎったことは1度や2度はあると思います。
リーダーとしてメンバーにタスクを割り振る時も、もし遅れが出たり、タスクをこなせそうなら自分が巻き取ってしまえばいいや、という考えを持ったこともあるのではないでしょうか？

その理論はミクロな視点で見れば正しいですが、マクロな視点で考えると誤りです。
1人月を「20日*8時間=160時間」と仮定して考えてみましょう。
毎日2時間ずつ残業すると、40時間追加で時間を確保でき、1.25人月となります。
さらに、月4回土曜日も8時間仕事をして32時間追加で時間を確保したとしましょう。この場合、作業時間は1.45人月となります。

どうでしょう？毎日２時間残業して土曜日に出勤をしたとしても、追加で作業できるのは約0.5人月となります。
メンバー２人から0.2ずつタスクを巻き取ろうとしただけでも、あなたの働き方は過酷なものになってしまいます。
メンバーがさらに増えればあっという間に破綻してしまいますし、『自分でなんとかすればいいや』は、プロジェクトの進め方としては最悪な部類に入る選択肢です。

タスクを握りすぎてボトルネックになってしまっている

設計書のレビュー、コードのレビュー、クライアントとの打ち合わせ、リーダーとしてやるべき仕事は多岐に渡ります。しかし、今自分がリーダーとして抱えているタスクは、果たして本当に自分がやるしか選択肢は無いのだろうかと考え、見直すことは大切です。
リーダーのレビューが終わるまで次の作業ができない、とりあえず次の作業を進めてもらったはいいが結局大幅な手戻りが発生した、といった事態が発生すればするほど、プロジェクトは遅延してしまいます。

リーダーが上、メンバーは下という勘違いをしてしまう

リーダー、メンバーという呼び方を使っていると、どうしてもリーダーの方が偉いというイメージを誰しもが持ってしまいがちです。しかし、プロジェクトにおける役職はあくまで役割の定義に過ぎず、プロジェクト内での上下関係を定義するものではありません。（上司・部下といった、社内での上下関係はまた別の話です！）

これをリーダー本人が勘違いしてしまうと最悪で、タスクを割り振り「やれ」と命令することが自分の仕事だと錯覚してしまいます。冷静に考えれば分かることですが、やれと命令するだけの人間などプロジェクトに置いておく必要がなく、スピーカーに録音して流すのとなんら変わりません。

そうするうちに、全体を管理する立場だからこそ考えられる視点や方法を使ってプロジェクトの問題を解決するという意識も力も失い、ただただ遅延して雰囲気の悪いチームが出来上がってしまうのです。

ではリーダーはどうするべきか？

メンバーの力量を考えて適切な工数を見積もる

自分でなんとかすればいいやという考えは、タスクの工数見積もりを納期に合わせる形で行なったり、大雑把でいいだろうという気持ちで行うことが原因となり生じるケースが多いです。
特に厄介なのが前者で、『納期があるのだから間に合うようにスケジュールを組み立てるしかない』という気持ちは分かります。ただ、納期に間に合わせるよう体裁だけ整えたスケジュールなど最初から破綻しているのです。

工数合計がスケジュールに収まるかという観点は一度抜きにして、メンバーの力量を考慮した上で工数見積もりを算出することを考えてみましょう。
例えば、タスク①はメンバーAが作業したら２人日かかる見込みだが、メンバーBなら１人日でできそうだ、という事が工数見積もりの段階で分かっていれば、そのタスクをメンバーBに割り当てることが適切だと判断することができます。
また、タスク②についてはメンバーAとBの間に差はほとんど生じないと分かった場合は、BではなくAに割り振ることが適切だと判断できます。

このように、自分だったらこのくらいの工数でできるだろう、このタスク内容だったら大体これくらいの工数だろう、という曖昧な見積もりを避けることで、チームの実状から乖離が少なく意味のあるスケジュールを組み立てることができます。

納期に間に合わないスケジュールになってしまったらどうするの？

メンバーごとの力量を踏まえて適切な工数を見積った結果、納期に間に合わないスケジュールになってしまったとしましょう。ここで再度思い出していただきたいのは、納期に間に合う形で無理やりスケジュールを組み立てることにはなんの意味もないということです。
後々かなりの高確率で発生しうる問題、遅延が先に判明したのですから、これはポジティブなことです。ここからどのような方法でリカバリーをするかは、会社やプロジェクトごとに異なってくると思いますが、リーダーとして提案できるいくつかの選択肢を紹介します。

稼働時間を高めて対応する

納期は絶対に変更できない場合、最大限スケジュールを効率化した上で残業をするなど、稼働時間を増やして対応するという選択肢がよく取られると思います。
スケジュールが最適化されており実状からの乖離が無いという前提で、納期からはみ出している工数が少ない場合には、これも最適な選択の1つと言えるでしょう。

納期変更を打診する

スケジュールを最適化したうえで、稼働時間を高めても納期に収めることが難しい場合、そもそものプロジェクト計画がおかしいという可能性も考えられます。
クライアントの要求が無茶なのか、契約金額に対して投入しているエンジニアの数が少ないのか、経歴に見合った生産性をあげられないメンバーがいるのか、原因は様々考えられますが、とにかく「今のままだと間に合わない」ことを上位者に伝えましょう。どんな内容であれ、プロジェクトの状況を正確に伝えることが大切です。

メンバー構成の見直しや、追加投入を打診する

プロジェクトとして達成すべきタスクに対して、明らかに人数が不足している場合や、エンジニアのスキルが不足している場合には構成の見直しを打診するのも1つの方法です。
繰り返しになりますが、リーダーとして上位者に伝えるべきなのは「やります！」という根性論ではなく、正確な情報です。
追加で何人必要な想定なのか、どういった技術を持つエンジニアが必要なのか、具体的な情報を交えて相談してみましょう。

メンバーにタスクの一部を分担してもらう

『メンバーの仕事はプログラミングだけ』、『溢れたタスクはリーダーが全て拾う』という考えを一旦捨てることも大切です。
とは言うものの、突然なんの情報もなく仕事を分担されてもメンバーは困るでしょうし、あなたが期待するレベルの成果はあがってこないことと思います。
タスクを分担できるようにするため、日頃からどのような対策を取るべきかの具体例をいくつか紹介します。

情報を自分ひとりで握らないようにする

タスクを意味ある形でこなすためには、「なぜ、どういった経緯で、何のために行うのか」の情報は必要不可欠です。
この情報を知らないままタスクをこなしても、全く的外れな成果となってしまいます。

あなたしか知り得ない情報が増えるほど、それに比例してあなたしか実施できないタスクも増えていきます。

・あなたしか出席していない会議があるのならメンバーも参加してもらう、または議事録を残して必ず読んでもらう

・各々の作業の経緯や意思決定の根拠をドキュメントとして残すようにする（ADRのようなものを作るイメージ）

・一次情報が集まる場所（クライアントも参加しているSlackやTeamsなど）には、自分だけではなくメンバーも参加させる

といった対策を行い、属人化してしまうタスクを減らすようにしましょう。

プロジェクト内の役職は、あくまで役割の違いを定義したものにすぎないと自覚する

リーダーやメンバーといった肩書きは、プロジェクトを進める上で何を主担当とするかを定義したものであり、立場の上下を定義したものではありません。
これについては方法論どうこうではなく、誤った認識を持っているのであれば正すしかないです。

誤った認識による弊害の例

仮に、リーダーとメンバーの間に立場的な上下関係を発生させてしまったとしましょう。
すると、メンバーはあなたの意見が絶対だと認識するようになり、次第に自分の意見を主張しなくなります。自分では黒に見えるものも、あなたが白だと言えば白として理解し作業を進めてしまいます。
あなたが1から100まで完璧に指示をできる人間であれば問題無いですが、そうでない場合は無駄に弊害を発生させることとなります。

さいごに

自分自身にも言い聞かせてることですが、プロジェクト運営に絶対的な正解は無いと思っています。
なぜなら、プロジェクトによってクライアントもメンバーも技術もツールも変わりうるからです。

だからこそ、どんな状況でも活かせる方法論や知識をなるべく蓄えておき、少しでも安定したプロジェクト運営を行えるように努めることが大切だと考えます。

こんな方法もおすすめだよ！というのがあれば、是非教えて頂けると嬉しいです！