導入
こんにちは。エンジニアのYamaです。
私は現在4人の開発メンバーと共に社内アプリの開発を行っており、その中でリーダーを務めています。
プロジェクトは昨年から始まっており、まだチームができてから1年も経っていません。
この間にチームを良くするために私がやってきたこととその中で良かったこと微妙だったことをそれぞれ3つずつ紹介していこうと思います。
チームの特徴
チームメンバーは全体的に技術好きというタイプがほとんどです。
逆に開発は好きだけど、あまり他の領域には足を踏み入れたくないという点もほとんどのエンジニアに共通しています。
年齢も20代から40代までとバラバラで、全員リモートワークです。
やって良かったこと
3位: 振り返り
私のチームでは毎週金曜の夕方にオンラインで、1週間の振り返りを行なっています。
これは割とチームができてからすぐに始めました。
理由としては、自分自身と他のメンバーの業務内容を理解することや業務改善ができたらと思い、始めました。
方法としては「KPT法」を少し変えて行っています。
KPT法はKeep(よかったことや続けていきたいこと)、Problem(問題、課題)、Try(今後やっていくこと)の3つの観点を洗い出していくものです。
上で「少し変えて」と書いたのは、Keepで、良かったことや続けていきたいこと以外にメンバー間で感謝していることやドヤりたいことなども挙げるようにアレンジしているからです。
実際にメンバーからもプラスの声が上がっていました。
- お互いの課題を知れた
- それまでProblemとして抱えていたものが、この振り返りですんなり解消した
- Tryでネクストアクションまで考えることができた
このようにチーム力の向上に寄与した取り組みでした。
2位: 分報
分報とは、情報の断片をリアルタイムで報告することです。
具体的に何をやったかというと、Slackでチームメンバー全員がそれぞれ個人のチャンネルを作成し、自由なタイミングで近況を書き込むというものです。
チャンネルの名前は「#Times_hoge(hogeは本人の名前)」としました。
困っていること・できたこと・業務内容問わずそれ以外のことも自由に書き込めるという割と自由なルールにしました。
また、Slackのリアクションを増やして、コミュニケーションを活発化させました。
これにより、朝MTGや振り返りを待たずにお互いの課題に気づくことができ、スムーズに課題解決することができていました。
特にリモートワークという状況だからこそ役立った取り組みだったと思います。
1位: モブプロ
モブプロ(モブプログラミング)とは、1台のコンピュータで1つのプロジェクトやタスクに対して、複数のメンバーが協力してプログラミングを行う手法のことで、特に2人で行うペアプロ(ペアプログラミング)は有名かと思います。
モブプロにおける役割は「ドライバー」1名とそれ以外が「ナビゲーター」の2つがあります。
ドライバーはプログラミングを行い、ナビゲーターはアイデアを出したり、問題解決の方向性を示したりします。
私のプロジェクトでは、大体1時間ごとにドライバーを交代して実装を進めていますが、この交代時間はプロジェクトによってまちまちかと思われます。
モブプロは、複数人からアイデアを出してもらえるということで、問題解決の視野が広がり、問題解決自体の効率化を図ることができます。
また、レビュー時間の短縮や知識共有といったメリットがあるため、チームができて、3, 4ヶ月してから導入しました。
結果、上述したメリットが得られただけでなく、熟練者から的確なアドバイスによりチーム全体の技術力の向上が見られたので、プロジェクトの成長だけでなく、エンジニア自身の成長につながった点が最も良かったと感じる一番の理由です。
やったけど微妙だったこと
上記にやって良かったことを書きましたが、本記事に書いていない取り組みも複数行ってきました。
ここからは残念ですが、効果が見られず、やったけど手応えがなかったものです。
他のプロジェクトでは、やり方によってはもしかしたら効果があるものもあると思いますので、これはあくまで私のやり方・私のプロジェクトで失敗した取り組みとして理解していただけたらと思います。
3位 アウトプットの習慣化
私の所属する会社では、外部イベントでの登壇や社内でのLT発表や技術記事の投稿などのアウトプットを奨励する仕組みが存在します。
しかし、ただ漫然と仕事をしているとそれらの時間を確保できず、実際にこれらの活動が行えているエンジニアはあまりいませんでした。
そこで、私のプロジェクトチームは隔週で2時間、技術記事の執筆やLTの準備などを行う時間を確保するようにしています。
その結果、アウトプットは習慣化され、チームメンバーも喜んでいる面はありました。
その一方で、それ以外の時間に、全くアウトプットに関連することができず、前回途中まで考えていたことを忘れてしまったりすることがしばしばありました。
また、その時間内で何か成し遂げようとした結果、品質の低い技術記事やLTになってしまったという声もあり、この取り組みは現状失敗としています。
とはいえ、ないよりは良いので、今も継続的に行っていますが、どこかのタイミングで改善しなければならない取り組みです。
2位 MTGのファシリテーションのローテーション
私の会社では、全員が活発でリーダー格を担うことが望まれています。
そのため、評価基準の中に「リーダー」という内容が含まれています。
現状チームのリーダーは私ですが、私だけがリーダー業務を行っていては全員の成長につながりません。
そこで、朝MTGなどの内部の打ち合わせのファシリテーションを毎日ローテートしていました。
全員がファシリテーションのスキルを身につけることで、会議の進行能力やコミュニケーション能力が向上にもつながりますし、多様な視点や責任感の醸成に繋がると考えました。
結果、会議の進行方法が毎回異なるため、混乱や一貫性の欠如を招いたため、一旦取り組みとしてはストップしました。
ただ、リーダーを目指すメンバーからは、またファシリを行いたいとの声もあるため、立候補で行うスタイルを採用しようと考えているところです。
1位 全員にMTGでの発言を求めること
最後です。タイトルからして失敗しそうな内容です。
基本的にMTGでは、話す人は話すし、話さない人は話さないという雰囲気がありました。
一方で、上述した通り、会社でリーダー格が求められている以上、思考力や発言力や判断力が求められます。
その成長につながると思い、この取り組みを始めましたが、発言を強制されることにより、心理的負担を感じ、発言がしにくくなるメンバーがいたため、割と早い段階でやめました。
必要になる能力ではあるものの、そもそも各人が求めているスキルにも差はあるので、上記のような能力の鍛え方は別の方法でチーム内で相談しながら行っていく方針となりました。
最後に
今回紹介した取り組みは、私たちのチームがこの1年で試行錯誤しながら進めてきた結果です。
それぞれの取り組みには成功と失敗の両面がありましたが、重要なのは、チームのニーズやメンバーの特性に応じて柔軟に対応することだと感じています。
これからもチーム力向上のために、改善を重ねながら新しい挑戦を続けていきたいと思います。
同様の状況にある皆さんの参考になれば幸いです。