Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)

Akatsuki Hackers Labは株式会社アカツキが運営しています。

エンジニア組織マネージメント7つの習慣

この記事はAkatsuki Advent Calendar 2017の4日目の記事です。

こんにちは、ゆのん(id:yunon_phys)です。この記事では、アカツキのVP of Engineering(以下、VP)として、どういったことに日々気をつけてエンジニア組織のマネージメントを行っているのかを述べます。

1. 組織をフラットに保つ

アカツキでは、1人1人の自主性を重んじていて、個人の行動を妨げるようなことを可能な限り排除します。この1つのhowが、組織をフラットに保つということです。階層構造の組織では、上司が部下に指示を出す/部下が上司に許可を求める、という行動を取るようになります。しかし、これは上司が常に正しい意思決定をすることが前提です。実際には現場にいるメンバーの方が正しい意思決定が出来るケースの方が多く、メンバーが自分の判断で行動するほうが合理的であると考えます。自分も立場的に上の立場として見られがちなので、良く◯◯していいですか、という質問が来ますが、許可を求めるな、謝罪せよ、の精神でまずやってみよう、と言うようにしています。

2. 全員で組織をつくる

役割としてはVPがエンジニア組織の責務がありますが、組織をつくるのはそこに属する全員です。このため、各々は必ず善い行動をすると信じ、可能な限り情報をオープンにして意思決定の過程が誰でもわかることを大事にしています。また、何かを決めるときも多数決ではなく、熱量のある人の意見を採用することで、それぞれのメンバーの想いを尊重する風土をつくり、全員が組織づくりに貢献出来るようにしています。

3. ワクワクする個人目標を立てる

個人目標を半年に1度設定しますが、半年後や1年後にどういう人になっていたいかを想像し、それを達成するための行動であったり指標を評価者と握ります。やる前から明らかにむちゃな目標は立てないように注意しつつ、一見むちゃではあるものの出来たらしっかりとレベルアップを実感出来るような、ギリギリ到達可能なラインの目標とします。こうすることで、全員が目標を追いたいと思えるようなものになり、組織としてもより強固になります。

4. マネージメントをエンジニアリングの成れの果てにしない

エンジニアが昇格すると必ずマネージャーになる、というのが昔からある日本企業で良くあります。エンジニアがマネージャーになることしかキャリアパスが無いのが大本の問題点なのに、なぜかエンジニアがマネージャーになることはイケてない(成れの果て)、とされる風潮があります。そこで、エンジニアのマネージャーをイケてる役割とするために、まずマネージメントをやりたくない人にマネージャーを任せないようにしています。技術をひたすら尖らせたい人、プロダクトに最適な技術選定が出来る目を養いたい人向けのキャリアパスアカツキでは用意しています。 また、マネージメントもエンジニアリングと同様に、"スキル"である(先天的に備わったものではない)とし、理論を学び、最新のマネージメントを学習し続けることを推奨しています。その下支えとして、認定スクラムマスター/プロダクトオーナーの研修参加支援、Management3.0の勉強会であったり、プロジェクトでやった施策でやって良かったこと、やらない方が良かったことを共有する場を設けるなどしています。

5. カンファレンスに誰でも行けるようにする

最近ではカンファレンスの発表資料や動画が公開されるので、どういった内容が発表されるかを行かなくても知ることは出来ます。しかし、その場の雰囲気だったり、自分たちが遅れている、といった危機感については、行かなければ体感出来ないものです。こうして体感したものは個人の目線を上げることにつながり、長期的には組織を活性化させるものになると考えるため、手を挙げた人であれば誰でも行けるようにしています1。これまでの実績ベースだと、RubyKaigi、React Conf、LinuxCon、Elixir Conf、Unite、CEDECなどがあります。

6. エンジニアが主体となって採用をする

一緒に働く人は自分たちが決める、の原則の基、エンジニアが前にたって採用活動を行うようにしています。具体的には採用イベントで必ずエンジニアが話すようにしていたり、自分たちが一緒に働きたい人とはどういう人であるかをエンジニア同士で議論したり、インターンの内容・設計を自分たちで行ったりしています。自分たちが達成したいことを実現するために、将来の投資としての採用を重視しています。

7. 量のために採用しない

ブルックスの法則にあるように、遅延しているプロジェクトに人が入ると、さらに遅延していきます。また、急な組織拡大はこれまでに挙げた組織文化を壊す要因となりかねないため、慎重に行っていく必要があります。遅延しているプロジェクトがあれば、なぜ遅延しているのかの原因分析を冷静に行い、今いるメンバーで対処出来る方法が無いかを探します。どうしても採用するとしても、今いるメンバーよりも何かしら優れている要素を持っている人の採用を原則とします。

まとめ

エンジニア組織をマネージメントするにあたり、心がけていることを書いていきました。ここで書いたことは、これからも守り続けるものではなく、メンバーの状態や時代の風潮などによって、変化していくものです。実際これを書いていく過程でも、こうした方がもっと良い組織になるのではないか、というアイデアが湧いてきました。1人1人が輝けるよう、最高の組織とは何かをこれからも追求し続けます。


  1. 本音を言うと、まだまだこちらの想定よりも頻度は少ないので、みんながどんどん申請して、予算取りを困らせるぐらいになって欲しいなあ・・・なんて思います。(そうなっても予算取りを戦い続けるつもりですが)