※この記事は 2021年07月07日に Medium で公開されたものを、ブログ移行に伴い再掲載したものです。内容は当時のままですので、一部情報が古くなっている可能性があります。
ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。
今回は、マネージャー向けに「もしメンバーに自走してほしいなら、個人のメンタリティに期待するのではなく、組織で相互にアドバイスし合うプロセスを構築したほうがいい」という話をしたいと思います。
エンジニアの求人サイトを検索してみると、求める人物像や歓迎するスキルに「自走力のある人」と書いている企業がたくさんヒットします。 これだけ書いてあるということは、自走する能力を備えていることがもはやエンジニアの必須条件のように思えてきます。
ですが、自走するかどうかはその人個人のメンタリティよりも外部要因のほうが遥かに大きいと私は考えています。どんなに自走できる人でも、ほとんどの場合で権限移譲された範囲までしか自走はできないからです。上司の知らないうちに「新サービスリリースしておきました！」とかちょっと考えにくいですよね。
つまり「自走力のある人」を募集する以前に、まず自分たちの組織の権限移譲が適切になされているかどうかが重要なわけです。
権限移譲とは自己決定できること
では、エンジニア組織にとっての権限移譲とは何でしょうか？ それは自分自身で意思決定ができるかどうかという点に尽きます。
システムのアーキテクチャを自分で決めてそれをリリースまで持っていけるのであれば、それは権限が移譲されている証拠になります。 ですが、逆に自分で決めたはずのアーキテクチャが後でテックリードにひっくり返されたりすると、それは権限が移譲されていないということになるでしょう。
つまり自己決定できる環境づくりさえ構築できれば、自走するエンジニアが育ちやすい土壌になるはずです。 そして『ティール組織』という本の「助言プロセス」という考え方が、この自己決定できる環境についての答えになるのではと思っています。
助言プロセスとは
この本では、上下関係を持たないメンバーが自由に、かつ自主的に組織へ影響を与えることができる状態を「ティール組織」と定義しています。そしてそのティール組織では意思決定を各メンバー自身が行うルールとなっています。
ですが、それぞれが勝手に意思決定してしまうとめちゃくちゃになってしまうのは容易に想像できるかと思います。一般的な組織ではメンバー全員のコンセンサスを得ることでそれを防ぎます。一方、ティール組織では「助言プロセス」を用いることで防ごうと提案しています。 各メンバーは自分の考えを開示し、周りからアドバイスをもらうが、最終的には自分で決めてね、というプロセスになるわけです。
この開示とアドバイスの組み合わせさえあれば、正しいゴールに向かって自分自身で意思決定をしてもらうことができるようになります。 そして、これは組織構造に手を入れずに比較的かんたんに取り入れることができるシロモノなのです。
ということで、弊社のエンジニア組織で実際に行っている5つの「助言プロセス」を紹介します。
様々な助言プロセス
1. issue issue は「助言プロセス」すべての出発点となります。 ※1 issue は全員に開示された達成すべきゴールであり、そのゴールがあるからこそ適切なアドバイスをし合えるからです。
2. Design Doc そこそこ大きめの機能を作るときには必ず Design Doc を書くようにしていますが ※2、この Design Doc に書かれた内容は何らかの試行錯誤の結果としての実装方針のはずです。
なので、その経緯も書くことで他者からアドバイスをもらうプロセスを経ることができ、より良い実装方針を打ち出せるようになります。
3. times channel Slack 上の times channel、いわゆる分報は実装しているときの頭の中の開示であり、アドバイスし合うきっかけとなります。
自分の考えに対して他者がフィードバックするループが自然発生することが理想なので、なるべく自分の考えをアウトプットし、他のエンジニアのアウトプットで気になるところがあれば積極的にコメントするように心がけています。
times channelでのコメント例
4. ペア/モブプログラミング ペアプログラミングは実装そのものの開示であり、より直接的なアドバイスをもらうことができます。
依頼タイミングについては別途ちょっとした工夫が必要だったりするので、また別でポストしたいと思います。
5. draft pull request ドラフト状態で pull request を作る行為は実装そのものの開示であり、これもアドバイスし合える役割を担っています。
完璧に動くコードを提示することは高コストであり、コードに問題があったときに気づくのが遅れるほど影響は大きくなってしまいます。 なので、私もなるべく早くアドバイスをもらえるよう、自分のコードを共有するようにしています。
これら5つの「助言プロセス」を通じてアドバイスをし合うのはかなりの労力が必要です。しかし、自走するエンジニア組織にすることとのトレードオフになるのかなと思います。
まとめ
弊社もバリューで「自分で考え自分で動く」と定めていますが、あくまで自走力は後天的なものと捉え、このバリューをすでに持っている人のみを採用しているわけではないです。 自然とそうなるよう組織の仕組みを考えることが正しいはずだと、弊社では考えています。
そして『ティール組織』の本の内容全てを実行するのは組織全体の話となってしまうため、はっきり言って難しいです。 ですが、ティール組織の考えを完璧に取り入れる必要はありません。部分的にでも取り組むことができる考え方です。一番取り組みやすいのはこの「助言プロセス」だと思うので、ぜひやってみてください。
※1）弊社は GitHub を使っているので issue という表現を用いていますが、一般的にはチケットとかそういう文脈になります
※2）Design Doc が issue と実装の接着剤となるドキュメントという位置づけです
ピナクルズ社では一緒に働く仲間を募集してます！
弊社では社内で『ティール組織』の輪読会をしたりしています。店舗／倉庫／工場などで働く「デスクレスワーカー」の教育課題にご興味がある方だけでなく、『ティール組織』を参考にした組織づくりに興味がある方は、オールポジションで絶賛採用してますので、ぜひご応募ください！ 3.エンジニア の求人一覧 - Tebiki株式会社 Tebiki株式会社が公開している、3.エンジニア の求人一覧ですherp.careers
