技術力の高い組織を作るにはどうすれば良いのかってお題で考えてみたいなと思い、せっかくなのでメモとして残す。
表題の通り[雑]で、とりあえず思いついた内容を書いただけなので随時更新していく形にしたい。
アウトプットの数編としてるのは、今後の自分に期待して拡張性を持たせておきたいから。
まずはそもそも技術力が高い組織はどのような組織なのか、どのような数値に現れるのか考える必要があると
思う。
技術力が高い組織とは？、でいくらでも考察できそうだが、とりあえずここでは登壇数などのアウトプットをKPIとする形で考える。
執筆や登壇数が多いから技術力が高いのか、それとも技術力が高いから執筆や登壇数が多いのかなど、因果関係がいまいちわからない点はあるが、少なくとも一定関係はあると言っても良さそう。
アウトプットのためにはインプットが必要で、アウトプットによってインプットが定着するのは事実なのでそういう意味でも効果はあると推測してる。
後は技術力が高い、というのも一部は他者(他社)からの評価次第で、相対的な部分もあると思っているので、プレゼンスをあげる事が結果として技術力が高い組織として認知されることにも繋がると思っている。
アウトプットの質も重要な話だが、まずは量質転化の考えに則り、量の改善についての話に絞りたいので質については今回はスルーする。
ということでアウトプットを増やす方法について考えたいが、まず前提としてアウトプットする場自体がハードルの高さ毎に、ピラミッド型の構造となる。
一番上はおそらく執筆やトップカンファレンスの登壇。その次がもう少しカジュアルな勉強会でその後に社内の勉強会やチームの勉強会。最後にチーム内での直接仕事に関係する議論やslackなどでの雑談などが続くんだと思う。
正直会社、組織レベルで考えると本当の一番上にはOSSやRFCレベルでの貢献があるような気はする。例えばKubernetesの前身であるGoogleのBorgとかOAuth3.0とかGNAPの仕様検討に貢献するとかそういう話。
とはいえこの辺りは想像もつかないのでこれまたスルー。いずれ考えれるようにはなりたい。
で話を戻すと、このあたりの具体的な階層については自分の頭で考えきれていないのと、そもそも以下Podcastを聞いてて学んだことなので、興味がある場合はこちらを聞くのが一番かなと思う。
44. Spotify型およびゆめみにおける組織モデルの変遷 w/ raykataoka
前述したようにアウトプットする場所はハードルや難易度毎にピラミッド型になっていて、数自体も同じようにピラミッド型になるんだと思う。社内勉強会や社外のカジュアルな勉強会でのアウトプットが皆無なのに書籍執筆率が異常に高い、と言うことはあまりイメージがつかない。
中途で出来る人を集めている場合はありうるかなと思うが、その場合は新卒などジュニアエンジニアを採用し始めると、そこで断絶が起きて、彼らがステップを踏んでアウトプットに慣れると言う環境が存在しないので育成面では問題が起きそう。
直接仕事に関係するチーム内での議論などをどういう扱いにするかに関しては、あくまでも仕事を行う上で必要な内容であり、技術感度が高い組織であることを表す指標にはならないのではとも思ったりした。
ただ仕事で扱った内容をまとめ、抽象化して社内の勉強会で発表した場合にはまた話は変わるし、そもそもアーキテクチャに関する議論など内容にも寄る。議論を重ねることでチーム全体の力が上がっていくみたいなのもあると思うので、このレイヤーの充実度も意識すると良さそう。
でこのピラミッド型を意識した上で、どこのステップが足りていないのか考え、ボトムアップで対応していくのが良いはず。
社内や部署、チーム内で全く勉強会や技術的な議論、アウトプットが行われない環境で、そこに全く手を入れずにいきなりトップカンファレンスへの登壇数だけを掲げるのは少し難しいかなと言う気がしている。
もちろん目標として掲げるのはありだと思うが、具体的な施策の話になると下のレイヤーから取り組むのが良いのではと思う。
自分が所属している会社/部署に関しては、社内の勉強会を意識するのは会社の規模が大きく、部署内での勉強会の時間を毎週スケジュールに入ってはいるが基本的に誰も発表しないと言う状態になっているので、まずはここを改善するのが最善手段かなと思う。
後は、やはりアウトプットに対してインセンティブというかモチベーション与える環境、制度にするのも大事かなと自分の経験からも実感する。
アウトプットを心掛けたり、組織的なアウトプット数改善に取り組んでも評価という形で返ってくるかは怪しいのであれば、なかなか取り組む気にはなれないのが人間だと思う。。。
そして、では具体的にどういう施策を取るのが良いかはまた別途考える。