開発チームのメンバー全員が「幸せ」になるチームを目指して

前提

こちらの記事が長くなってしまったため分割しました。
開発プロセスの部分を読んでいただければ前提は理解できるかと思います。

[意識したこと] チームメンバー全員が「幸せ」になるチーム作り

結果を最初に述べておくと、この目標の達成率は(私の体感では)30%程度という感じでした。「チームメンバー全員を幸せにする」ことと、「(限られた時間で)プロダクトとして価値のあるものを提供する」ことを両立する難しさを実感しました。

さて、本トピックは「チームメンバー全員が「幸せ」になるチーム作り」についてですが、そもそも「幸せ」とは何か、私の現状の理解を共有する必要があります。

私にとって「幸せである」という状態は「欲が満たされている状態である(と本人が自覚できている)」ことだと考えています。
例えば、「寝たい時に寝ることができる」「食べたいものを食べることができる」など、「やりたいことをやることができる(できていると自覚している)」というのが「幸せ」には必要不可欠だと考えています。休みの日に二度寝する瞬間は最高に幸せな瞬間だと思いませんか？

つまり、私がこの開発を通して意識していたことは「チームメンバー全員がやりたいことをやることができるチームを作ること」になります。
極端な例を挙げると、「何もせず単位を取りたい！」という希望するメンバーがいれば、(極力)何もせず単位を取れるようにしたいと考えていました。
とはいえ、人によって「幸せ」は異なると思いますので、「やりたいことができて嫌な気持ちになる人はいないだろう」という仮説の基、チームをより良くするための提案を行ってきました。

具体的な取り組みとして、「チームメンバーにやりたいことを直接聞き」、「miroに"今不安なこと"を書いてもらい」ました。これらを踏まえて、開発中のタスクの割り振りを行いました(行いたかった…)。
チームとしては「メンバーの意思を尊重する」「チームの意思を尊重する」という2つの共通認識を持っておくことで、無法地帯になることを防ぎました。つまり、「自分のやりたいことをするために他人(チーム)に迷惑をかけないようにしましょう。その条件の上ではどんな希望もすべて尊重されます(しましょう)。」ということです。その観点で考えると、「何もせず単位を取りたい！」という希望はチームの意思を尊重していない、という点で棄却された(というか、そもそもそういう考えに至らない)可能性が高いですね。

ここまで色々と説明してきましたが、はじめに結論として述べた通り、達成率は30%程だと考えています。なので、原因を考察していきます。主な原因は以下の3つだと考えています。

1. メンバーの希望よりも「価値のあるプロダクトを作りたい」という私の希望を優先したため[7]。

2. 私が持つ「各メンバーのやりたいこと」に対する理解が甘かったため。

3. 「やりたいこと」を具体化・言語化できない可能性を認識していながら、それらを解決するためのコミュニケーションを私が怠ったため。

私は、プロダクトの開発プロセスにおいてタスクの分割や割り当てを担当していました。そのなかで、「開発できる(コードを書ける)ようになりたい」と言っていたメンバーにFigmaによるプロトタイプ作成をやってもらう、というような状況が生じていました。

そのような選択をした主な理由としては、時間が無い状況で、より価値のあるプロダクトを提供するのに必要だと考えたためです(ただ、この選択に関しては、「各メンバーのやりたいこと」をきちんと理解していれば、より良く出来たのではないかと考えています)。
特に、チーム内でも「技術力に差がある」という点は課題として挙げられており、共通認識としてありました。しかし、ショートスプリントの開発時間はふりかえりなどを除いて100分程度しかなく、スプリント内で技術のキャッチアップをするにしても、25時間(100*15回で1500分)しか時間を取れません。別途Next.jsに関する勉強会を行いました[8]が、圧倒的に時間が足りませんでした。
そのような状況で、メンバーが「開発できるようになった」と思えるほどのスキルを(自主的に勉強せずに)身に付けるのは難しいと考えました。

解決策としては、「属人性をある程度許容して、特定の領域を任せる」ということが考えられます。
今回の開発では、属人化を防ぐため、「領域を問わず、簡単なタスクから任せる」方法を取りましたが、リソース(主に時間)が足りず、中途半端に終わってしまったと思っています。
属人性を排除することは、単一障害点を無くすのに有効ですが、経験が少なく、多くの技術に一度にキャッチアップする必要があるメンバーが多い状況には適していないようでした(使える時間や人などのリソースがたくさんある状況では例外かもしれません)。

また、理想としては各メンバーが「これやりたい！」とタスクに対して立候補してくれることでしたが、なかなかそのようにはなりませんでした。
私としては「(限られた時間で)価値のあるプロダクトを作りたい」という希望とコンフリクトしていたことが、技術的な挑戦をしづらい状況を作っていたのではないかと考えています。
そして、やりたいことが具体化されておらず、自発的に挙手するほどではなかった、という可能性もあると思います。

これらを踏まえて、「やりたいこと」についての掘り下げるコミュニケーションを行うとともに、特定の領域をメンバーに任せることで「新しい機能を0から作ることができた」というような開発者としての成功体験を積み重ねることができれば、より良い結果になったのではないかと考えています。