自分が今開発チームを持つとしたらどういうチームを作るかまとめ #マネジメント

多分、3年後に同じ内容で記事を書こうとすると違ったものになるんだろうと思いつつ、間違いを正しながらブラッシュアップしていけたら良いというマインドで今正しいと思うことを記していこうと思います

共通マインド

心理的安全なチームであること
- 心理的安全なチームとは決して生ぬるく仲良しなチームの事ではない
- 活発に意見・議論することで最適解を導き出し、納得感を持って仕事ができる環境であること（結果的に仲良しであることは大歓迎）
リスク提言を賞賛するべし、結果的に起きなかったことに後ろ指をささず、単純に喜ぼう
- 指摘があることをそれ自体が素晴らしいことであると理解しよう
- 「なんとなくダメな気がする」という指摘には掘り下げる努力をみんなでしよう
マネージャーやリーダーは権力者ではなく、ただの役割である
- マネージャーやリーダーがこう言うから正しいという誤解はなくそう
- マネージャーやリーダーが間違ったことを言っていると個人的に思ったら意図を聞き指摘しよう
- 同じ人間なので等しく間違うということを理解しよう
HRTの原則を意識しよう（とらわれる必要はない）
- 謙虚（Humility）：世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善していこう。
- 尊敬（Respect）：一緒に働く人のことを心から思いやろう。相手を1人の人間として扱い、その能力や功績を高く評価しよう。
- 信頼（Trust）：自分以外の人は有能であり、正しいことをすると信じよう。そうすれば、仕事を任せることができる。
遠慮は無しで配慮することを考えよう
- 自分が思い、伝える必要があると思ったことはちゃんと伝えよう。遠慮して沈黙することは誰のためにもならない
- ただし内容や時間など自分本位にならずにお互いに配慮を欠かさぬようにしよう
失敗を恐れない。失敗をしたらなるべく共有する（共有しやすい雰囲気作りをする）
- 失敗してしまったら、失敗の種類をまず考える
  - 回避可能な失敗や複雑さゆえに起こる失敗である場合は、仕組み作りや仕組みの再構築を行い再発防止する
  - 挑戦によって起こった賢い失敗については、みんなで褒めたたえる
- 失敗したまま終わりではなく、必ず失敗から学ぶようにする。あなたがその失敗をしたなら、おそらく他の誰かもその失敗をする
- 怠慢によってルールを逸脱し起こった失敗は素直に謝る
迷った時、QCDのどれを軸におくかをプロジェクトチーム内で決めておく　平時/有事
- 有事とはどういう時かを正しくプロジェクト内で定義すること（それ以外は平時）
  - スケジュール遅延の程度？要件が制御できないほど増えた？など
- 軸を据えた場合の行動の変化を定義すること

仕組みづくり

朝会
- ファシリテーターはローテーション
- 作業報告は各自で共通の場所に記入からの読み上げ
- MTGが開催できなくても、書面開催のみは必ず行う
振り返り会
- 2 ~ 3週間に一度、振り返り会を実施する
- 困ったことや良かったことを共有する
- 改善が必要な進め方はないかプロジェクトメンバーの意見を募る
- 状況に応じて役割分担なども見直せると良い
質問がため込めるような場を用意すること
- 各種連絡に埋もれることがない、専用の場であること
- どういう属性の人に、いつまでに回答が必要かをわかりやすく表現できていること
チケット起票前だけど、タスクが発生することが確定してるものを溜め込める場を作成する
- チケット起票というものは結構大変である場合が多い。ただしやることが漏れないため、ライトに書き込める場を用意する
- こまめに棚卸しを行い、チケット起票するようにする（＝時間がある時にってやつ）
業務以外での交流の場を定期的に設けること
- 関係値があがらないと、業務で必要なQAやレビューの質が比べて低くなる現象が存在するかを考えること
- 関係があってこその有意義な議論が存在するかと言うことを考えること。（よく知らない人に指摘をすると喧嘩に発展する現場を見たことが無い人はいないんじゃないだろうか）
- 「業務以外」と言う観点だとどうしても嫌だという人もいるので、それはそれでちゃんと理解すること

ちょっといいなぁと思っている取り組み

もくもく会
レビュー会
3割レビューの仕組み

子チームづくりを意識すること

ピザ2枚ルール
5 ~ 7名を想定しているようだが感覚的にはもう少し小さく3〜4人のチームに分割して統制するのが良いと思われる
また、少数とはいえ複数人となると管理や決めが必要なときに代表して意思決定をする人間が必要不可欠となる
そのため、チームリーダーを必ず任命すること

チームは大きくなりすぎると言い方が悪いがサボる人がでてくる
これは本人が全部悪いわけではなく、大人数の中で自分の意見が発信できない、しても埋もれてしまう状況を作っているマネジメントの責任もあると認識するべき
逆にチームが小さければ全員が意思決定に関わることができ当事者意識が生まれやすくなる
当事者意識が持てれば自然と生産性は高くなる

設計・実装

ドキュメント

実装やテストに必要のないドキュメントは極力作らない（＝無駄な工数をかけないという意）
ドキュメントを作る際はバイナリファイルとなるものをなるべく利用しない（代表的なものはexcel）
他者との合意形成や認識齟齬を埋めるためのドキュメントは積極的につくる
また、せっかく作ったドキュメントは引き出しやすく誰でも見れる場所に保存することを心がける
最近だとホワイトボード系のアプリを積極的に利用すると良いのかなと思っている

実装

独自実装にこだわらない
一般的に普及するサードパーティーライブラリの利用余地がないかを都度調査する（他者が書いたドキュメントや技術記事が存在するということをアドバンテージと捉えるべき）
新しいものは積極的に採用する
半年前に無かったものが今はあるというのが当然に起こる時代であるので、常に調べるもしくはチームメンバーから意見を募ることから始める

タスク / スケジュール

1日2チケットぐらいが消化できるぐらいにタスクはなるべく細分化する
あらかじめ細分化する必要はない、着手が近くなったら細分化すればよい
細分化されていることで着手中に迷子になりずらくなるし、たくさんチケットを完了できている方が気分良く仕事が続けられる
スケジュール作成は誰か一人で行うのではなく、作業者本人で見積もり行うことを心がける（最低でもかなり細分化されたチームの長それぞれがする）
自らスケジュールをたてることで納得感が生まれそれが責任感へと繋がるため
初めから正確な見積もりをする必要はない。消化のガイドラインとなるようなスケジューリングを心がけよう（無理する必要ないだいたいで良い）
もし仮に知識不足で見積もりができない人がいる場合には、最初のうちはチームのより近いひとがそれを代行しよう
各個人が行った見積もりの結果がマスタースケジュールから外れるようであればそれはタスクの総量に対してチームのスキル総量が足りていないことを意味するため、増員等を検討するきっかけとする（逆もまた然り）

レビュー

質の高いレビューやそのフィードバックを生むには心理的安全な場が必要

レビュワーは常に、「余計な指摘かもしれない」「正しいことを言えているかな・・」「教えたいことがあるけど余計なお世話か」などの不安を抱えているもの
一方レビュイーは「どういう直し方を求めているのだろうか」「指摘されたこれは必ず直さなきゃいけないものなのか」「こんな指摘のされ方は気分が悪い」などと考えているもの。

この意識の差を埋めなければ健全なレビューとそのフィードバックは行われないものと思うべし

まずは参考記事にある通り意識の差を埋めるための工夫をする
コメントの内容がどのような意図のものなのかを正しく定義することで、不必要な衝突や第一印象の齟齬を極力減らす努力をすること

ルール

ビジョンを一つ設定する
- お客様の課題を解決する / 自社の売り上げを立てる / 新しい技術に挑戦していく
タスクには必ず具体的なゴールを設定する
- プロジェクトのゴール、フェーズごとのゴール、細分化された一つのタスクのゴール、etc
チケットの運用方法を全員で考える
- 起票のテンプレート、ステータス遷移、タスク/バグチケットの運用方法の違いなど
最初にルールを作りすぎない
- 必要なルールは運用途中で増やせば良い
- 最初から決められたルールは形骸化するし必要性の実感を得れない

最後に一番重要なこと

このルールは私が考えてそれぞれ挙げたものなので、実際のプロジェクトに適用する際は、必ずプロジェクトメンバーと一緒に内容の精査をすること
そしてそれぞれが定義された内容に十分の理解と納得感を持つこと

弊社、株式会社SORICHは、クラウドネイティブなアプローチを得意とするシステム開発会社として2006年4月からサービスを提供しています。コロナウイルスの流行を受け、2020年3月から社員の9割以上がテレワークで勤務をするようになりましたが、現在も変わらず大手外資系企業をはじめとしたお客様からご愛顧をいただいております。

　代表・馬屋原は学生時代にエンジニアの過酷な労働環境を目の当たりにし、「エンジニアが幸せに働くことができる場所を作りたい」という思いから大学を卒業後すぐに当社を設立いたしました。社名の由来でもある「社会を豊かに」という企業理念のもと、会社に関わる全ての人の豊かさのループの始点となれるよう、今後も技術力を活かして社会に貢献してまいります。

SORICHでは常時、システム開発部の採用窓口をオープンしております！
2023年9月現在ではクリエイティブ事業部の窓口もオープンしています！
typeさんやen転職さんで募集がストップしている場合でもこちらからご応募いただけます！

noteでは、社内活動について記事を執筆し、投稿してます。
こちらもぜひ！