良い花は後から

エンジニアのキャリアや働き方、転職などについてお話するブログ

チームビルディングをするときに考えていること

本記事では僕がマネージャとしてチームの立ち上げを任された時や運営していく時に考えていることやアクションをまとめてみます。エンジニアとしてどこかの組織に所属するとチームに所属することがほとんどだと思います。今回はそのチームを立ち上げる時や運営していく時に考えていることをお話します。

f:id:masayuki5160:20200215142007j:plain

チームビルディングをするときに考えていること

開発のリズムをつくる

一番はじめに考えることがこの開発のリズムをつくるということです。具体的にはアジャイル開発を取り入れる話になるのですがやりたいこととしては、

 

  1. 開発計画を立てる
  2. 開発開始とチーム内での定期的な進捗確認
  3. リリース

 

を1週間や2週間などの短い期間で繰り返し行うサイクルをつくるということです。これはアジャイルの考え方ですのでチームのメンバーがアジャイル開発(スクラムなど)に慣れているのであれば、

 

  • イテレーション期間の設定(1週間 or 2週間など)
  • 各種セレモニーの実施日の決定(ex. 朝会(デイリースクラム))
  • カンバンやバックログの用意(ex. JIRAの導入)

 

ということをささっとすり合わせをすればすぐに整えることができます。仮にもしこの設定で議論になりそうであれば一旦仮決めをしてしまって初回のスプリントを始めることが良いです。もし数スプリント実施してみて課題があるのであれば修正をすれば良いです。また、アジャイル開発に慣れていないメンバーが多いケースでははじめ方は工夫する必要があるでしょう。その場合は経験のある方がスクラムマスターとして少しずつアジャイル開発について啓蒙していきスプリントを始めることになると思います(これは組織によっては難しいこともありケースバイケースではあると思いますので一概には言えませんのでいくらか割愛しています、ご容赦ください)。

 

というわけでまず一つ目のチームビルディングをするときの大事なこととして開発のリズムを作ることを取り上げました。アジャイル 開発、特にスクラムというフレームワークを導入することである機関で開発とリリース、そしてチームの経験学習を進める仕組みを導入することができます。ですのでチームを立ち上げる時にはこの方法はある程度うまくいく再現性もあると考えています。

チーム内での心理的安全性を確保する(相談しやすい雰囲気をつくる)

心理的安全性について、最近話題になることがあると思います。

www.hrpro.co.jp

記事中でも紹介されていますが心理的安全性が高い状態ですと、平たくいうと相談しやすいのでチームのパフォーマンスが向上するということにつながります。それはそうだろうと思うかと思いますが、実際にこの状態に持っていくためには細かな工夫が必要になってくると考えています。例えば僕がこの状態を目指すために取り組んでいることは以下です。

 

  • 雑談を意識的にする
  • 1on1を定期的に実施
  • ランチや懇親会の実施

 

これくらいしているよ、という方が多いと思います。本当にそうでしょうか?雑談一つをとっても意外に難しいものです。特にリモートワークが中心のチームにおいては一苦労です。ですので僕がしていることとして、毎朝の朝会で意識的にメンバーと仕事と関係のない話題をふっておしゃべりをしています。他の会議の場でもそうです。本格的に会議を始めるまではおしゃべりをするようにしています。とても些細なことですがこういったことの積み重ねはチームの雰囲気を作っていくことにつながります。特にエンジニア特有のことでいうと、

 

  • こんなことわからないといったら馬鹿にされるのでは?
  • こんなことも知らないの、と思われそうで恥ずかしい・・・

 

などエンジニア特有かと思いますが知識や経験がないことを不必要に意識することがあります。これについては多くのケースで考えすぎであり、他の方も同様に悩んでいたことだった、ということがあります。ですので、こういった技術的な質問を気軽にしていける雰囲気をいかに作っていくかということがチームとして良いパフォーマンスを出していくことにつながっていきます。現在多くの開発チームでは非常に多くの技術や経験を要求されることがあり、一人で解決できることというのは少なくなっていると思います。フルスタックエンジニア、という言葉はありますが正直に言いまして僕はあまり良い印象がありません。多くのケースでそれぞれの技術分野についての知識や経験が中途半端であることが多いからです。それよりはそれぞれのメンバーが得意分野があり、その知識をチームで持ち寄って問題を解決していく方が現実的に良いアプローチだと思います。そのアプローチをうまくするために心理的安全性の確保は大切だ、と考えています。

OKR(チームの目標)

OKRはご存知の方も多いと思います。以下記事が詳しいですのでご紹介しておきます。

www.kaonavi.jp

 

一言でいうと目標設定のためのフレームワークとなるかと思います。OKRの良いところはフレームワークが軽量なのでわかりやすい点です。僕はチームビルディングをする時に毎回OKRを使うわけではないですが、例えばチーム全体として直近半年の目標があった方が今やっているタスクに意味を持たせることができてモチベートすることにつながりそうでしたら導入をします。イメージとしては3人のレンガ職人のお話に近いです。

www.total-engagement.jp

目の前にある不具合を直すことはごく短期の目標としてはわかりやすいので良いのですが少し先に目を向けた時にやはりチームとして向いている方向がチーム全体で共有できているのと、できていないのでは大きく違います。ですのでOKRのようなフレームワークを使いチームとしての定性的な目標を掲げ、それを達成するための定量的な目標をいくつかブレイクダウンしてチーム内で共有しておくと良いと思います。OKRについてより詳しく知りたい場合は以下書籍が参考になるかと思いますのでぜひ。

 

OKR(オーケーアール)

新品価格
¥1,485から
(2021/10/8 09:29時点)

DX(Developer Experience)

DX(Developer Experience)は平たくいうと開発者が楽しくシステム開発・運用をできるかという概念です。この数年でよく話題に上がるようになりました。日本語のちょうど良い記事がなかったので英語の記事を参照します。

developerexperience.io

 

記事中ではDXが良いと解決できる問題として以下のようなことを挙げています。

 

Problems the Good Developer Experience Solves

  • Knowledge hoarding
  • Bad Product-Market Fit
  • Demotivated Team
  • "Not My Problem" Mentality
  • Unsuccessful Product
  • Unhappy Clients
  • Disconnect Between Business and IT
  • Toxic Team Culture
  • Poor Code Quality
  • Increased Cost
  • Meaningless Work

引用:

Good Developer Experience | Developer Experience Knowledge Base

 

開発者が気持ちよく開発できる時、もちろんコードの品質も上がりますしプロダクトが成功する可能性も上がる、そしてステークホルダーにも良い影響があるということが書かれています。記事でも記載がありますがDXを向上させるためにはお金と品質、時間のバランスを考えることが必要になります。例えばDXを改善するための良いツールがあればそれを導入する交渉は必要です。そしてそれはチームをリードするエンジニアリングマネージャの役目の一つだろうと僕は考えています。その時になぜそのツールが必要なのかをステークホルダーに説明して説得していけることも大事な役割でしょう。というわけでDXを向上することがチームビルディングをする時に考えていることの一つです。

ステークホルダーとの関係性

最後の項目です。これは他のチームや仕事の仲間とも仲良く良い関係を築こうというお話です。組織の中でチームは他のチームの方と仕事をすることになります。その時、例えばチームのリーダーがそのチーム(ステークホルダー)と良い関係性を持っていれば事前に話を通しておくことも可能です。そしてそれは業務がスムーズに進むことにつながります。ほんのちょっとしたことかもしれませんがステークホルダーが多い案件や複雑な案件であればあるほど事前のすり合わせや調整はその後の業務のスムーズな進行につながっていくと考えています。エンジニアの方の中でこういったことは興味がない、という方もいると思います。僕も正直にいうとそうなのですが、担当している案件や開発業務を円滑に進めるためにはある程度必要だと仕事を通して学んできました。ですので僕がチームのリードを担当する場合はこういったステークホルダーとの関係性は大切にしていますし、チームの成果にもそれが貢献することになると考えています。チームのメンバーは開発業務に集中することができ良いアウトプットも出てきやすいので、結果的にチームの雰囲気も良くなります。当たり前ではありますが、仕事がうまくいっている状況の方がチームの雰囲気は良いですよね。

まとめ

僕がチームビルディングをする時に取り組んでいることについてまとめてみました。僕がこれまで経験してきたインターネット系の企業やスタートアップでは同じような方法でチームビルディングをすることで良い結果につながるかと考えています。再現性はあるだろうと思います。もう少し日本的な組織(ex. メーカー系)ではアプローチを工夫する必要があるかもしれません。ただ、チームを立ち上げる時に考えるべき観点は同じだと思いますので参考にしていただければ幸いです。それでは以上です。