![見出し画像](https://assets.st-note.com/production/uploads/images/91498994/rectangle_large_type_2_f9a3dd549e70905c3633f4b0a8ea08ab.png?width=1200)
【プロダクト開発】報告しずらいリーダーになってしまった話
個人開発を友人とやっています。
私はモチベーションやコミットできる量からリーダー的なポジションをしていました。
そんな中で、メンバーの作業が終わってない時に「報告しずらい」と言われてしまいました。いつの間にか「報告しずらいリーダー」になっていたのです。
それぞれのメンバーが他に仕事を持っており、コミットできる量が違う。モチベーションも人によって違う。そんな状況から、なかなか進まないプロジェクトと自分たちで決めた締切もあり、「焦り」が「イライラ」に代わってしまいました。
そのイライラがメンバーに伝わり心理的安全性が低い組織を作り上げていました。そしてある時、頼んだタスクの進捗報告がされなかった時に「できてないことを言い辛い」と指摘されました。
こんな時参考になるツイートを見つけました
リーダーの心理的柔軟性が低いと、「恐怖政治による組織疲弊問題」&「裸の王様化」が進行し、①相談タイミングの見合わせ、②内部資料の過剰品質化が進み、業務効率も悪化し
— さかいふうた @ ピープルマネジメント研究 (@fuuuuuta21) November 15, 2022
"コトよりもヒトに向かう組織"になるので、2ランクアップよりも2ランクダウンなどの発想が必要なんだと思います。 pic.twitter.com/ns9cnb0DlJ
リーダーの心理的柔軟性が低いと、「恐怖政治による組織疲弊問題」&「裸の王様化」が進行し、①相談タイミングの見合わせ、②内部資料の過剰品質化が進み、業務効率も悪化し
ここまで酷いものだったとは思いたくないですが、自分の悪い部分は認めないといけません。
そして、これからどうしていくべきか考えます。
こうなってしまったのはなぜか
そもそもの原因はなんでしょう。考えてみました。
1. コミットできる量に差がある
2. それぞれが自分ごと化できていない
「コミットできる量に差がある」は正直サイドプロジェクトでやっている以上、仕方ない部分があります。ここは解決しにくい課題です。
これより大きな原因となってしまったのは「それぞれが自分ごと化できていない」だと考えています。
共有では足りなかった。
今までもメンバーの「自分ごと化」を全く考えていなかったわけではありません。ただ足りていなかったということです。
![](https://assets.st-note.com/img/1668823260095-1EGBMz1xuH.png)
それまでに意識していたことは共有です。
いろいろな本や記事で「共有」の大切さを述べています。プロジェクトの状況を知ることで自分ごと化し、モチベーションも上がると。
立場上、プロダクトの課題を1番理解してるのは自分です。そしてリーダーはアイディエーション力もある人が多いので、具体的な機能や仕様まで考えられます。だからこそ「共有」さえすればプロジェクトがうまく動くと考えすぎてしまいます。
しかし、それでは不十分だと感じています。そもそもモチベーションが上がらない状態でその共有をしっかりインプットするのが難しいからです。だから校長先生の話は退屈なのでしょう。
根本となる原因はもっと奥深くに眠っているものなのでしょう。それを理解するために今回起きたこの事件の原因となっていたフローをリストアップしてみます。
1. タスクを依頼する
2. コミットできる量やモチベーションから終わらない
3. 終わってないことを報告する
4. リーダーがイライラする
5. 報告しずらい環境が作られてしまう
ちなみに終わってないことにイライラしてたのではなく、正確には期待しているほどのパフォーマンスが出てないことにイライラしてたのだと思います。なのでリーダーがイライラを我慢する、では根本的な解決にはなりません。
そこで私は、そもそもこの初手の「タスクを依頼する」が間違っているのではないかと考えました。リーダーはタスクを依頼する人ではなく、タスクを考えさせる人なのではないかと。
人は与えられたものよりも、自ら考えて行う行動の方がモチベーションが上がります。
そうなると「1. タスクを依頼する」という初手の時点で「2. コミットできる量やモチベーションから終わらない」は必然的に起こることでした。
なので自分の意識することは
メンバーの考えるきっかけを作る
最終的な意思決定はやる
もはや私の仕事はこの2つだけなのかもしれません。
メンバーの考えるきっかけを作る
ではどんなことを考えるのでしょう。具体的には、ペルソナ考えたり、機能を考えたり、仕様を考えたり、ありとあらゆることが当てはまると思います。これはもはやリーダー、PdMの仕事っぽいことです。
そういうのを自分1人で考えて、共有して依頼したとしても、やはり共有するタイミングで抜け落ちる情報はあるし、受け取り側はどうしても自分ごと化しずらいのです。
だから「考えを共有する」のではなく「考えるきっかけを作る」で十分なのです。例えばペルソナを考えるミーティングをセッティングする、とかそんなことだけで十分です。
もちろん自分がそこに参加して意見を言うのは良いことです。
ペルソナや機能などは、わかりやすいケースですが、日常の気づきずらいところに「考えるきっかけ」は転がっています。
例えばデザインや実装に関するフィードバックをするにしても「もっとこうしてください」より、「ここはこう感じたんだけど、もっと良くするにはどうした方がいいかな」とWhyを投げかけるようにします。
最終的な意思決定はやる
考えただけではプロジェクトは進みません。プロダクトの課題感を1番理解してるのはおそらく自分です。
最終的な決定をするのも自分です。
そこは譲らず行いましょう。じゃないと方向性がバラバラなプロダクトができてしまいます。
もちろんメンバーそれぞれ得意不得意、好き嫌いはあるので全部全部を考えさせるのが良いわけではありません。そこを見分けるのもリードする立場の人の役割だと思います。
最後に。
このnoteを書いた最高に良いことは、失敗を学びに変えられていることです。
誰でもやはり失敗はするものなので、学びに変えられるのであれば、もはや失敗ではないのかもしれません。
とにかく、これから「考えるきっかけを作る」を続けていきます。その上で気づいたことがあれば、こうしてnoteにしたいと思います。
補足。というかお願い
このnoteを書くきっかけになったMokurenというChrome拡張です。GitHubユーザーの方は、是非インストールしてみてください。
またよかったらTwitterのフォローもお願いします😊
個人開発や、プロダクト開発に関係することを発信して行っています。
この記事が気に入ったらサポートをしてみませんか?