【アジャイル社内開発】 チームビルディング

※ この記事は、こちらの続きとなります。

https://qiita.com/hiroyuki-abe/items/b7906e5cf3464a14f929

---

こんにちは！
今回はプロジェクト立ち上げ時のチームビルディングについてお届けします！


## 1. はじまり
最初は私とテックリードの2人でプロジェクトがスタートしました。
部署の管理職2名がサポートとしてチームの外から協力してくれました。


最初は次のことを同時進行で進めました！

- メンバー集め
- プロセス整備（この記事では触れません）
- 開発環境整備（この記事では触れません）


<br/>

## 2. メンバー集め

### POスカウト

最初に取り掛かったのは、PO（プロダクトオーナー）のスカウトです。

アジャイルなプロジェクトにおいて、POは非常に重要な役割です。
最初は管理職2名がPOをするという話でしたが、以下の条件にマッチしなかったので、思い切ってスカウトして管理職に提案してみました！

- チームと一緒に働ける人
- (忙しそうにしている等で)話しかけるのに気を使ってしまう人はNG
- チームと壁がなく話せる人

ちょうど中途入社の同期にピッタリな候補がいたので声をかけたところ、嬉しい返事をいただきました！
管理職の方も提案を快く承諾していただきました！

PO初挑戦だったのですが、失敗を恐れずチャレンジし、チーム全体のモチベーションを高めてくれています！
とても身近に感じられる話しやすい人で、チームと一緒になって働いてくれています。

<br/><br/>


### サポート役

サポート役として影響力のある方が参加してくれました。役職にとらわれず影響力がある方で、調整や協力者募集などでは本当に助かってます。チームの痒い所に手が届くサポートをしてくれる頼もしい存在です。

アジャイルって巻き込み大事です！

<br/><br/>

### チームメンバー募集

さらに、チームメンバーを募集しました。プロジェクトメンバー募集は社内の応募で参加プロジェクトを決める仕組みを活用しつつ、紹介やスカウトを通じてメンバーを集めました。

最終的に集まったメンバーは、以下の通りです。


- プロダクトオーナー 1名
- スクラムマスター (私)
- アーキテクト兼テックリード 1名
- インフラエンジニア 1名(2週間だけスポット協力)
- エンジニア 2名
- (後にデザイナー1名が合流することになります)


メンバー集めに協力してくれた方々、参加していただいたメンバーには本当に感謝です！
繰り返しになりますが、巻き込みや助け合いの大切さを実感しました！

<br/>

## 3. チームの主な目的

- 社内業務改善
- メンバーの育成と体験の場提供

※ メンバーの入れ替えが発生することを前提としています。

<br/>

## 4. チームイメージ
目指したいチームイメージはこんな感じです。

- 共通の目的・想いを持ち、そのために個々が考え行動する
  - 全員がユーザー価値とプロダクト価値向上を目指し、主体的に行動することを大切にする。
  - 自分達のプロダクトを使って何を実現したいかを合わせる。
  - 想いを合わせることが大事。
  - (モノ作り、タスク完了が目的にすり替わらないように注意)
  - (決まったものを作る、工業的なモノ作り思考にならないよう注意)
- 対話を大切にする。(ステークホルダもチーム内も)
- お互いに理解を深める。尊重する。
- 多様性、集合知を大切にする
  (本当に色んなバックグラウンドを持つメンバーが集まったので、ハッっとする意見が認知外から飛んできて心地良いです。)
- 自己組織化
  - みんなで協力して自律的に考え、判断し、行動する。
  - 全員が主体的。
  - セルフマネージメント。
  - (他人事、「管理してもらわないといけない」は避ける)
- 常に「より良い」を探す。そして良くしていくためにトライする。
- ROIやフロー効率を理解し、常に向上させることを考える。
  (トライは極力小さく速く) 
- Whyに目を向ける。考える。
- 楽しむことが大事！
  ストイックな開発も大切ですが、笑顔で楽しむことがモチベーションの源であり続けていく秘訣です。
- 集合知を活用する(ブレスト、モブワーク、デザインスプリントなど)
- 心理的安全性をみんなで作る。
  - 与えられるものではない。みんなで作る。
  - ネガティブな課題も率直に出し合いチームの課題として受け止める。
  - 個人を責めない。悪くしようとしてる人なんかいない！
  - (実は受け取る側も大事です。 前職での話になるのですが、追及文化の悪影響なのか個人で必要以上に責任を感じてしまう人がいました。無意識に刷り込まれているので簡単には変えられない場合が多いです。ナーバスになってしまうこともあり注意が必要です。私は今のところ、重く受け止め過ぎず、あせらずゆっくり時間をかけてデトックスしていくという方法しか持っていません。)
- チームと個人の成長を大事にし、自律的に改善していく。
- 全員が全てのことを知っている状態が自然に維持される。
  (自律的に動くには判断材料として情報がとても重要です)


<br/>


## 6. チーム作り(成長するチームを作る)

前述の「チームイメージ」に書いたことを実現するため取り組みをご紹介します！

基本的には「チームイメージ」に書いたことが「当たり前」になるように、常にそれが当たり前という価値観でチームが話せる場づくりが主だと思っています。

※ そのために様々なプラクティスを使うのですが、プラクティスは方法・ツールであって、プラクティスをやればアジャイルな成果が得られるというわけではありません。ちゃんと目的をもって実施すること、高い成果が得られるようにプラクティスを使いこなすことが大切だと思います。


- 最初に
  - 目的感をしっかり合わせる。
  - 文化をしっかり伝える。
  - チーム内の相互理解を醸成。(ドラッカー風エクササイズ、ペア/モブ、振り返り等)
- チームみんなで楽しくやる雰囲気を作る。
  (私はそこまではできてないですが取り組み中)
  - 朝会などのファシリテーションはMCになったつもりで明るい雰囲気を作る。
  - メンバーの話をうまく引き出したり、話を振ったりしていく。
- メンバー一人ひとりをよく見る＆ケアする。
  - 些細な変化もキャッチできるアンテナが欲しいです。
  - 特に現場未経験の方はイメージと合わないことが多く不安を抱えがちです。
  - 不安を抱えているメンバーには真摯に向き合いましょう。
  - 1on1, NonNを活用しましょう。
- コミュニケーションを促進する。対話を大切にする。
  - チェックポイント
    - [x] ファシリテーター以外マイクオフ多くないですか？
    - [x] ブレストで発言するの決まった人だけになってないですか？
    - [x] 何かあったら気軽に「会話いいですか？」ってなっていますか？
    - [x] 「パーキングロットで話し合いましょう！」「パーキングロットで共有させてください」は多いですか？
    - [x] 振り返り盛り上がってますか？
    - [x] 気軽に「ペア/モブしましょう！」 ってなってますか？
    - [x] 「それ分からないです。教えてください！」は多いですか？
- 良い行動へのフィードバックを積極的におこなう。
  - これは良いことなんだという自覚がないことが意外と多いです。同様に自信持ててないということも意外と多いです。
    なので明示的に伝えることの効果が意外と高かったりします。
  - 良いことを良いということでチーム全体の「これは良い」という価値観ができていきます。
  - 雰囲気が明るくなります。
  - 記憶に残るので身に付く効率が高くなります。
- ユーザー価値、プロダクト価値、ROI、フロー効率の観点を要所で出していく。
- 自分の失敗は積極的に見せる。自分の無知を率先して晒す。
  - 親近感に繋がりやすいです。
  - 失敗や知らない事を受け入れやすくなります。
  - 「それ知らないんですけど、何ですか？ 教えてください」って言いやすくなります。
- 個人を責めずに、チーム全体で受け止める文化を醸成する。
- 早期検知、対応、計画アップデート の方が大事という文化を醸成する。
- 以下はネガティブなものとして扱う。
  - 指示、および、指示や答えをもらおうとする姿勢。
  - タスクを完了させることが目的になる。
  - 主体的じゃない、他人事、リードオンリーでのディスカッション参加。
  - Howに寄る。Whyを見失う。
  - 必要以上に個人で責任を感じる。
  - 失敗を無かったことにする。
- 考える、判断する、行動するをチームが主体的におこなえるようにする。
  (できてない。。。 エンジニアとしてもディスカッションに参加しているので難しいです。。。。)
- 問いで上手く、考えること、判断すること、行動を引き出す。
  (やってはいるけどまだまだ。。。。)
- 必要に応じてティーチングで初期インプット。


あと、本題とは少し外れますが、スプリントレビューの雰囲気作りも大事だと思っています。
プロダクトを良くしていくための対話をステークホルダーとDEVチームがいい雰囲気でできる場作りは、とても大事だと思っています。


<br/><br/>

## 7. (おまけ) メンバー受け入れでやること
おまけで、メンバー受け入れでおこなっていることを紹介します！
(初期メンバーもそうなんですが、途中参加メンバーも含めてです)

新しいメンバーを受け入れる際に行うことは次の通りです。

- プロダクトの説明
- プロセス類の説明
  (タイムテーブル、開発フロー、ブランチ戦略、品質保証戦略、DONE/UNDONE定義、カンバン、ダッシュボード)
    - だいたいこんな感じ程度。具体的なことはペア/モブで実作業をして慣れてもらう。
- 開発環境の説明
- スキルマップ入力のお願い
- チームのみんなとドラッカー風エクササイズ(兼 自己紹介、アイスブレイク)

<br/><br/>

必要に応じてティーチング
- 心理的安全性
- アジャイル(マインド、やりたいこと、なぜアジャイルか？ 中心)
- スクラム(スクラム自体はシンプルなので、1枚ものの説明WEBページを見てもらう)



<br/><br/>
だいたい次のようなステップで慣れて参画1週間で「ちょっと自律してやってみようかな」ってなります。
1. 1～2時間 上記を説明
2. 半日～1日 開発環境構築
3. 3～5日 ペア/モブで慣れる

<br/>

## 8. 最後に
文章整ってなくて読みにくいと思いますが、みなさんの参考になればと思い公開することを優先しました！
少しでも参考になれば幸いです！