チームとか雑感
Webサービスにおけるチームでの開発についてのふわっとした雑感です
エンジニアそれぞれの成長がゆくゆくはチームの成長につながるという面もあるんだと思います。
そして、チームを成長させるためにはドライな計画と実行ではなく人同士の関係に起因するウェットな部分も含んでいて、心理的安全性が重要なんじゃないでしょうか。
人の成長という視点で見ると、オンボーディングのプロセスとかの設計とも関連してくるとは思うのですが学習ステージを理論立てて考える必要がある。
全体的にはティーチングからコーチングに移行して信頼の形を変えていくという視点が必要そうに思っています。
これは「信じて任せる -> フィードバック」 を繰り返しやることになることになるとおもうのですが、「ここで頑張れないパターンもあるんじゃね？」と思っています。
原因としては、体力やメンタルやスキル足りないとかスキル足りないとか単純に忙殺とか。
サポートしてトレーニングする体制が重要そうですけど、「ゆくゆくのこと」に対してどれだけ投資できるかが多分重要なんだと思います。正確にいうと「重要だけど緊急性がない」エリアに所属することなのです。
緊急な事項、あるいは日々のお金を稼ぐのに必要な事項にこの項目は侵食されることが多そうで、あらかじめ「やる」とトップダウン的に意思決定しておかないと難しいことになりそうです。(ここをOKRにするには、やりたいのは誰なのか、そのゴールデンサークルはどうなっているのかなどの議論も必要そう。)
DDDのワークショップをチームにジョインするオンボーディングの過程でやっていた開発会社の話とか聞いてすごくいいなと思ったんです。
Guildworks中村さんのスライドとかをみていると、「やがてチームになる」とか、バスにちゃんと乗る過程がとても大事なんよと思っています。
たぶん、そうしたヒントは「Fearless Change」とか「Omoiyari.fm」にあり、あるいは苦労しているマネージャー(PdM, PjM)の言葉の端々にも現れていると思います。
１年後、３年後、５年後を見越した「学習のステージ、段階の設計」はチームとしての視点で多分もっと知識化、実践知化などやらないといけなくて、実際にはそれにプラスして、プロダクトの視点での学習のステージ、段階の設計をミックスしていかないといけないんだろうなと思います。
今回のDevLOVE300のイベントで市谷さんが語られたことから連想して、こんな感じの雑感を思い浮かべました。