ID:63512さん

開発組織全体の理想のチーム作りへ向けたマインド・カルチャー作り

- 機能横断できるチーム体制 - 全員が最低限のドメイン知識と解像度を持った状態 - レビュー方向が一方通行ばかりとならない様なレビュー体制 - 失敗や不足を非難や苦言などではなく、事実やチームの課題として見直せるような仕組み

# 前提 ジュニアエンジニア : ミドル〜シニアエンジニアが7:3くらいの組織 # 考えと工夫 ## 機能横断できるチーム体制 ### 考え・工夫 ジュニア層が多いため、まずは最低レベルの底上げ。開発フローの明確化やレビュー、UI検討、設計や技術選定の意思決定フロー、必要な技術のキャッチアップの一覧化など、個人の能力の最大化に注力できるようにガイドラインなどを制定した ## 全員が最低限のドメイン知識と解像度を持った状態 ### 考え・工夫 ドメイン知識やプロダクト解像度を高めるには、とにかくユースケースやユーザーの思想・考え方を知る必要があると考えた。 そのため、エンジニアとして、PdM(PO)などに「これは表示or非表示すべきか？」といった「仕様」を聞きがちであるが、要件ではなく、要求や具体的なユースケースを聞く文化を意識づける様に工夫した。 ## レビュー方向が一方通行ばかりとならない様なレビュー体制 ### 考え・工夫 知識や技術力に差があると、「〇〇さんが言ったから正解」と言った雰囲気やプルリクのレビューが指摘や指示のような雰囲気になってしまう。 しかし、開発においてベターはあっても正解は少なく多角的な視点や意見がより良いプロダクトを生み出すと考えた。 そのためレビューは一方通行でなく - 分からなかったことを知れたことを伝える - 悩んだが分からなかったことを伝える - 認識や解像度の違いがあったことを伝える - レビューに対する理解度を伝える などを提案して、レビューを一方通行の指摘の場でなく、議論の場となるように工夫した ## 失敗や不足を非難や苦言などではなく、事実やチームの課題として見直せるような仕組み ### 考え・工夫 スクラムを採用してるとスプリント毎に必然的に振り返る場があるため、場を作ることは特に意識せずその振り返りの時間を最大化することに取り組んだ。 スプリント内にチーム内で後戻りや認識ミスと言った失敗があっても振り返りの場では、誰かの失敗として名指ししたりせず、全てチームの課題・失敗として言及・表現するようにした。 しかし、その中でも一定数不足を認めたり改善することができないメンバーはいる為、反感が生まれることもあった。 信頼関係の構築が重要だと考え、チームメンバーには普段の雑談から「腹を割って話せる」関係作りを心がけ「親しき仲でもそのメンバーの為にはっきり言ってあげられる」リーダー像を意識していた