Fool on a hill

読んだ本やら、趣味の話やらを徒然なるままに書いていきます。

(エンジニアの)チームづくりについて

先日、及川卓也さんの「ソフトウェア・ファースト」を読んだ。

厳密にいうと、1年ほど前に読んだことがあるので、2回目である。

何故、読んだかというと、社内のとある打ち合わせで、

  • 及川さんの「ソフトウェア・ファースト」という本に書いてある「ソフトウェアの手の内化」という考え方が大事である

という話があり、「その本は読んだはずだけど、その言葉を覚えていないな」と思い、読み直すことにした。

読み直して、

  • チームのリーダー、特に、エンジニアが主体のチームのリーダーになる前に読むべき本だな

と感じた。

というのは、やはり「チームのリーダーになる」というのは困難なミッションであり、それなりの心構えや自分なりのやり方を持っていないといけないということだと思う。

例えば、私は、約1年前から30人ぐらい(協働者も含めると50人ぐらい)のチームのリーダーとして働いているが、「チームのリーダーとして何をすべきか?」というのは、最近、ようやく少しずつ理解できてきた気がする。

少なくとも、私の場合は、その辺のやり方は誰も教えてくれなかったなと思う。もしかしたら、普通の人は、メンターのような人がいて、その人と相談しながら、そのようなやり方を身に付けるものなのかもしれないが。

というわけで、ここでは、「ソフトウェア・ファースト」に書いてあることをベースに、チームづくりのポイントについて、自分なりに整理してみたい。

文化(Culture)を明確に定義する(言語化する。紙に書く。)

文化の中身自体は、下に書く「チームとしてのあり方」みたいなものだが、それを明確に定義して、チームメートに伝えるというのが大事である、というのをまずは書いておきたい。

私は、チームリーダーになってから9か月後に、そういう文化みたいなものを定義するドキュメントを作ったが、もっと早く作るべきだったなと反省している。

ちなみに、私の目指すチームの文化とは、以下である:

  • 一人ひとりの「やりたい」を大事にする

  • 一人ひとりが主体的に、かつ、自由に発言・提案・アクションを行う(そして、お互いにそれを尊重する)

  • 圧倒的当事者意識で横に染み出す(チームとして助け合う)

  • 「BizDevOps」を追求する(事業と技術は不可分)

心理的安全性を高める仕組みを作る

これは最近いろいろなところで言われているので、その必要性自体はここでは割愛する。

私のチームでは、朝会での雑談、1on1、打ち合わせ前のCheck-ins、ニックネームで呼び合うなどを、試行錯誤しながらやっている。

日本人はShyなので、こういった仕組みは必須だと思う。

チームメートの「やりたい」を大事にする

日本人は「やりたい」をあまり言わない人が多いと思う。

一方で、やはり「やりたい」ことをやる場合に最も成果が高くなるし、チームメートの成長も最大化されると思う。

だからこそ、「やりたい」を大事にしたいし、チームメートが自分の「やりたい」を主張できるチームにしたい。

ミッションに共感した、多様性のあるチームを作る。Debateできるチームを作る。

心理的安全性があるチームは、いろいろなメンバーが自由に意見を言い合い、Debateすることで、新しい方向性への変革を起こせるのかなと思う。

もちろん、チームメートが自分の「やりたい」を自由に言い合えるチームであるというのがベースラインとしてある必要がある。

「どこでも働ける人材」を育てる

これはエンジニアのチームとして最も大事な点だと思う。

「外で勝負できるプロ」を育てる。

「そのような人材を目指してください」と伝えて、かつ、そのような環境を用意する必要があると思う。

この本に書いてある通り、そのような人材が、能動的に所属する組織を選んで働いているという状況を目指すべきだと思うし、組織は、強い個人を惹きつける努力を怠らないようにすべきである。

変化を恐れない。常に変化を求める。

一般的に、組織も人も変化を嫌う生き物だなと思う。

だからこそ、"Get out of your comfort zone!" を言い続ける必要がある。

後は、個人もチームも、

  • 好奇心
  • 持続性
  • 柔軟性
  • 楽観性
  • 冒険心

を常に持ち続けるようにしたい。

10xを目指す。高い目標を常に掲げる。

「変化を求める」と言っても、「で、何をするの?」となるので、この「10x を目指す」、「高い目標を掲げる」というのを意識すべきだなと思う。

チームのミッションステートメントを書く

文化と同じく、やはり言語化した方がいいなと思う。

と言いつつ、自分のチームではまだ書いていないなと思った。

ここで改めて書くなら

  • 社内のData-driven Innovationを支える
  • 社内の内製化、BizDevOpsを支援する
  • Speed
  • Secure

かなと思う。

プロダクトの骨太の方針を決める(言語化する。紙に書く。)

チーム内のいくつかあるProduct/ Serviceに対して、

  • What
  • Goals
  • Non-Goals
  • Why
  • Reference
  • To-Do

を書くべきである。

文化やミッションステートメントと同様、言語化することが大事だと思う。

その他もろもろ

  • 計測する仕組みを作る。内製の基本。
    • Active User数や手作業の量など、できる限り計測するというマインドが大事だと思う
  • 全員を幸せにする必要はない。
    • 100%のSLOを目指すという話と同質のものだと思う。