👏

チーム発足時にしておきたいルール・理想づくりについて

2022/02/06に公開

2022.3.23 理想のチームについて追記

これは何か?

一からチームを作る際、または節目の際に作成する(見直す)チームとしての方針決めのようなものについての記事です。

最近になって私が始めた「チームとしてこうなろうね。こういう文化のチームにしようね」という合意について、釈迦に説法ですが書いてみております。

事の発端

私は人より遅めの20代後半でエンジニアの世界に飛び込みました。

そのため技術的にはへっぽこなのですが、年齢的に20代前半の方とチームを組むときは必然的にまとめ役のような立場を求められることになりました。

これまでチーム4チームほど所属したのですが、感じていたのが「個々人の考え方の違い」による摩擦・やりづらさという点でした。

個人の技術的経験値、職業人としてのバックグラウンド、もって生まれた性格の違いなどは多様性としてチームに成長を促すための要素となるはずなのですが、どうにもプラスの方向に転嫁しにくい感じです

例えば以下のような問題というか、課題のようなものを感じていました。

  • 「技術的経験が豊富なエンジニア」ばかり発言したり、その人に対して意見が言いにくい
  • 「周りの人の気持ちが全く気にならないエンジニア」 vs 「人の気持ちをセンシティブに考えすぎてしまうエンジニア」
  • 「開発・設計だけ担当したいエンジニア」vs「運用こそ顧客の信用を獲得できると考えるエンジニア」
    • もっとチームや評価者に自分を認めてほしい運用作業大事派エンジニア
    • もっと技術力を高めたい開発したい派エンジニア
  • みんなチームを良くしたいと思っているはずなのに、なかなか意見を合わせれない

人と人とが集まるので多少なりとも意見の食い違いが出るのは当然なのですが、そのような際にチームとしてまとまるための 価値基準・ルール というものがないと、落とし所を探したり同じ方向をみるのが難しくなっている気がしました。

喧嘩イメージ

もちろん会社・部署としてのビジョンのようなものはあるのですが、いまいちそれを現場のレベルまで落とし込めていないというか・・・

そもそも個々人でビジョンへの共感度とかも違うので、それを基準にするのは難しいし、抽象化されすぎていると言う感じでしょうか。

そんなことを同僚に話していた時に、ペパボさんが勉強になる資料をあげてくれているのでみた方が良いということを教えてくれました。

https://speakerdeck.com/pyama86/pepabotupoi-enziniakarutiyawochuang-ru-yan-xie-toshi-zu-mi

失敗から成長する(学ぶ)みたいな文化を面白い感じで表現した感じがとても素敵だと感じました。

それまで文化は与えられた環境の中で自然に醸成されていくものという認識でいたのですが、「どのようになりたいか」という考えをチーム共通で持っておき、それに沿ってそれぞれが行動する事でなりたいチームに近づくのではないかと考え始めました。

名著「Effective DevOps」にも以下のように記載されております(7.3.3 目標 より)

https://www.amazon.co.jp/Effective-DevOps-―4本柱による持続可能な組織文化の育て方-Jennifer-Davis/dp/4873118352

ひとりで仕事をすることに力を注ぐ人もいれば、メンタリングやカンファレンスでのスピーチのようなネットワークの拡大、コミュニティ活動への参加を大切に考えている人もいる。後者のグループは、下を向いてコードばかり書いているエンジニアをお高くとまっているとか、大局観がないと評価することがある。それに対し、書いたコードの行数やクローズしたチケットの枚数に重点を置いている人たちは、コミュニティ絡みの問題のことを「本当の」仕事には寄与していないと考えることがある。いろいろなメンバーがいるなかで、チームや企業が期待することを明確にすれば、不満を軽減するために大きな効果がある。

なるほど。 チームや企業が期待することを 明確に しておくことは確かに、何かあった時にそこにチームで立ち返れてよいかもしれないということで、チームとして向かっていきたい方向・最低限のルールを明文化してみることにしました。

ぼくが考えるさいきょーのチーム

そもそも良いチームとは何か

私が考える良いチームとは

チームメンバーのこだわりを活かして、チームとしての「良さの基準」を持って執着できるチームです。

これについては、こちらの書籍の影響をもろに受けています。

https://d21.co.jp/book/detail/978-4-7993-2808-8

要するにそれぞれの才能や長所を活かして、チームの強さに変えようよという少年漫画的な展開です。

チームのこだわり

個々人が仕事をする上で、もしくは日々の生活の中でこだわっているポイントがチームとしての強みになるポイントだと思います。

個人のこだわり・こだわりにある経験や背景をお互いに分かっておくことで、自然とお互いに発言しやすく、結果的に心理的安全性も高まるのではないかと思います。

普段から以下のような質問をして、相互理解を深めたいところですね。

  • このプルリクエスト、○○の部分が大変だったと思うけど、何かこだわったポイントとかあるの?
  • ○○の対応ありがとう。すごい上手だけど、普段から何かこだわってるポイントとかあるの?
    • いつ頃からこだわっているの?
    • 何かきっかけとかあるの?

大事にしたい文化

いきなり「みんなで文化を考えよう!」とか言っても話が進まないので、まずは自分がこういうチームになるのはどうかという案を考えてみることにしました。

それが以下のようなものとなります。
(あまり多くても頭に入らないので10項目以下くらいにしたい)

協働のイメージ

  • 組織の目標とチームの目標は齟齬なく共有しましょう
    • メンバーによってゴールの解釈に齟齬がないように
    • 具体化しておきましょう
      • 長期的なゴール例: 組織全体から手作業のテスト・デプロイがなくなって専任のDevOpsチームが必要なくなること
      • 短期的なゴール例: ○○プロダクトのデプロイをまずは自動化。その後自動テストの時間を○分に短縮すること
  • それぞれのこだわりを把握しましょう
    • 技術のことでなくても良い。顧客折衝、チャットコミュニケーション、健康面での意識
    • それぞれのこだわりを把握して、チームの強みに変えていきましょう
  • 失敗・ミスは学習のチャンス。非難、自身を責めるの厳禁ですよ!!
    • 「あぁすればよかった・・・」「○○さえ知ってれば・・・」は言わない!言わせない!
    • 何かことが起きた時には所謂、非難なきポストモーテムを開くのが理想的
      • 何がおこったか
      • なにが原因で発生したのか
      • タイムラインを整理
      • 次に同じことが発生しないようにするには仕組み的に何が足りないか
  • 目標に向かうために必要な作業なら全てチケット化しましょう
    • 運用作業やドキュメント作成も尊い作業
    • 必ずチケットとして起票し、成果が目にわかるようにしましょう
  • このチームでは目標に向かうための、全ての改善が尊い
    • 必要な機能開発
    • 機能開発を効率化させるためのツールの導入・提案
    • 手動作業が必要な箇所の洗い出し、手順起こし
    • イケテナイ仕組みのIssue立て
    • 目標に一歩でも近づくのであれば、それはどんな内容の作業でも尊い
  • このチームでは知識・経験のアウトプットが尊い
    • zennやqliita, 社内向けのNotePM、媒体は何でも良いです
    • 昨日見たLT・記事の共有でも良いです
    • あなたのアウトプットが組織・チームの学習につながります
  • 尊いことには具体的な感謝を
    • 1日の振り返りで意図的に「今日感謝したいことありますか?」「今日尊かったの誰?」という時間を設ける
    • 上司との定期的なミーティングや、評価の場面で尊かったことを上司に伝える
      • 公式の場で褒められるとより嬉しいよねっていう
    • え?俺は感謝を求めないから、感謝を強要するな?言うだけタダだからやってみましょう!
  • ぬるいのではなく、健全に意見を言える場所に
    • 人の話は必ず最後まで聞く(遮らない!)
    • 批判・攻撃はしない
    • 意見を言う時には肯定的な言葉で終わらせよう!(ブレスト方式)
      • (悪い例) 自分のレビュー観点が言えないってことは成長していないってことだと思うんで
      • (良い例) 一人一人がレビュー観点を言える方が成長につながると思うんです
  • 今できないことでも課題は課題として認識できるようにしましょう
    • チケットとして起票してもよし
    • 技術的な課題ならIssueに上げてよし
    • 実装方法やリファクタなら TODO, FIXMEなどのコメントを残しても良し

以上のようなことを提案すると「痛々しくみられるかな・・・」「面倒じゃないですか?」「意味あります?」みたいなことを言われると心配だったのですが、存外みんな乗り気になってくれます。
(今のところ2チーム中、2チーム)

これをベースに他のメンバーからの前向きな意見を取り入れたり、修正・削除したりするようにしてみました。

そして実際にこれをいつでもみれる場所に用意しておき、チームメンバーに変化があるたびに見直したり、説明する時間を作るようにすると良い効果が現れ始めました。

  • 地味な作業でも貢献した人は、評価者の前でスポットを当てられる
    • 地味な作業をすることが「いやな作業」感が少なくなる
  • 会議で若手の発言も増える
  • ミスをチームの学習の機会として捉えられる人が増えてくる

などです。

今のところ明文化することによるデメリットというのはあまり感じられていません。

ただ重要なのは中身というよりも「チーム全員で合意している」ものをいつでもみれるようにしておくことなのかもしれません。

とはいえ、まだまだ・・・

とはいえこれで全ての問題が解決するわけではありません。

摩擦も対立も、当然発生するときはします。

まだまだ自分もチームと一緒に勉強中なので、これからもどんどんアウトプットして、フィードバックを受け、良いチームになれるように頑張っていきたいと思います。

皆さんも、チームとしてこうすると良い!等ありましたら、ぜひ教えてください!!

よろしくお願いいたします。

GitHubで編集を提案

Discussion