読者です 読者をやめる 読者になる 読者になる

SideCI TechBlog

SideCIを作っているアクトキャットのエンジニアによる技術ブログです。


エンジニア組織において元エンジニアの代表が心掛けていること

こんにちは。SideCIを運営しているアクトキャットの代表の角です。SideCIは日本発の数少ないCI系サービス、エンジニア向けサービスの1つであり、全員がエンジニア経歴の持ち主であるエンジニア組織で運営しています。

今回は、普段私が組織づくりにおいて心がけていることをご紹介します。

はじめに

エンジニア兼代表という私の肩書きについて色々ご質問頂く機会があったので、いくつか回答してみます。

「元エンジニアだとコード書きたくならない?」
もちろん、なります。が、書けていません。書いていません。そして、それを心がけています。
直近1年間の私のGitHub上での草の生え具合は次のようになっています。

f:id:sideci-dev:20160525102329p:plain

「コードを書かないって寂しくないですか?腕が鈍っていく感覚とかありますか?」
やっぱり、寂しいです。また、腕が鈍っていく感覚もあります。
ただ、これもまた、生き方の選択によるもので、書かないことが今の私には適切だと判断しています。

「エンジニアが書いているコードに口を挟みたくなることってないですか?」
当然、あります。が、設計や実装レベルで口を挟むことはめっきり無くなりました。
これもやはり、私の役割ではなくなりました。

エンジニアの代表が心掛けていること

1. 開発の意思決定は開発チームに任せる

私たちは「自由である」「自由であるために、自ら進んで努力する」組織を目指しています。そのために「自走する」ことも不可欠です。

そのチームを目指すにあたって、代表がエンジニアのトップに立っている組織ではダメだと考えました。もちろん、エンジニアがエンジニアのトップに立っているトップダウン組織というのもまた違います。フラットな組織を目指さなければなりません。

設計で揉めたら?技術選定で揉めたら?言語選定で揉めたら?
ここで代表が口を挟む事は、組織全体の最終的な意思決定者である代表がその意思決定を行い、責任を取ることが明確になります。

意思決定者が定まり、責任の所在が明確になる事で、一時的に開発や意思決定のスピードは上がるかもかもしれません。その代わり、意思決定が全て代表に回ってくる、代表がボトルネックになる組織になってしまいます。

『ザ・ゴール』シリーズなどでも何度も語られている通り、組織のスループットはボトルネックによって決定されます。ボトルネックを改善しない限りは全体のスループットは向上しません。代表というボトルネックを開発チームから取り除くことは不可欠なことです。

開発の意思決定は開発チームに任せる。
たとえエンジニア兼代表であっても、開発の意思決定には介入しない

ザ・ゴール ― 企業の究極の目的とは何か

ザ・ゴール ― 企業の究極の目的とは何か

2. 担保したいことは数値と仕組みで担保する

たとえばシステムの安定性、バグの発生率など、ビジネスサイドとしては100%の安定性とバグ0を求めたくなります。また、それを追うことは間違ったことではありません。

しかしながら、実際開発を行っていると予期しないトラブルやバグの発生はどうしても起こってしまう事があります。このとき、「安定性を高めてくれ!」「バグが多い気がする。発生を限りなくゼロに近づけてくれ!」といったことは依頼しないようにしています。

代わりに、バグの発生件数や、安定性、ダウンタイムなどについて、それぞれを数値化し、いくつまでは許容するというのをビジネスチーム(つまり私です)とエンジニアの間で合意形成するようにしています。

f:id:sideci-dev:20160525102300j:plain Slackに毎朝投稿される担保したい数値とその他のKPIの一例

それによって、エンジニアはこれらの問題に過剰に時間を取られることがなくなります。また、数値が悪くなるようであれば、エンジニアチーム自体がこれの解決に自発的に動くため、ビジネスチームも、ビジネスに専念することが出来ます。
また、これは自走する組織、フラットな組織にも活きてきます。

これは私が心がけている、というよりはチームが心がけている事なのですが、

サービスとして担保したいことは常に数値化する仕組みを作る。
その数値を遵守するようエンジニアチームが自発的に動く事によって、常に担保される

3. 工数を見積もらない

「マネージャーがエンジニア出身じゃないから工数が見積もれない、無茶な要望が飛んでくる」みたいな声を伺う機会がありました。

私は代表ですが、元エンジニアであり、その上、サービスの初期開発を担当していました。そのため、工数はなんとなく見積もれます。また、より正確に見積もることもおそらく可能かもしれません。
けれども、工数を見積もらないように心がけています。

これもフラットな組織を目指すために必要不可欠なことだと考えています。代表・ビジネスサイドが工数を見積もり、スケジュールを切り、開発チームに依頼することは、「本来もっと早く完成するはずだったのに、スケジュールに合わせて別の機能や改修を追加してしまった」といった開発速度を下げる要因に成り得ます。スケジュールが与えられるとそれに自然と従ってしまうものです。逆に、工数を短く見積もりすぎた場合には、スケジュールが厳しくなります。

工数の見積もりは常に難しい問題ですから、たとえエンジニア出身であっても、現場から離れてしまっている元エンジニア代表が、正しい見積もりを出すことは難しく、また、時がたつ毎にその乖離は広がっていきます。

代表は工数を見積もらない。見積もらないことで、
エンジニアチームが工数を見積もり、誤差を修正していく、自発的な行動を促す

補足

実際のところ、私が開発の意思決定をすることは問題をはらんでいますが、コードを書くこと自体は問題にはなりません。

しかしながら、サービスを成長させていくためには、コードを書く以外のすべきことも沢山あり、開発以外のチームを組成する以前である今は、それが出来るのは私しかいませんので、今はコードを書くよりもそちらを優先すべきと判断しています。組織全体が勝手に成長するように出来れば、またコードを書ける機会がくるかもしれません。

もっとも、一度エンジニアの道を離れて代表としての業務をしている者がエンジニア業務を行うより、エンジニアの道一本で行っている人の方が遙かに生産性が高いのは事実としてありますが。

今後はもっとどうしていくのか

さも組織が非常に上手くいっているかのごとく書いてきました。もちろん心がけることによってより良くなった部分は多いと思うのですが、まだこの組織になって日が浅く、今後も継続的に組織を見続け、改善していこうと考えています。

また、実はSideCIのチームはこの記事を執筆時点で1桁のメンバーしかいません。組織の在り方の理想は保ちながら、チームをスケールさせていくことが今後一番の課題です。

そんな弊社ではWebエンジニアの方、インフラエンジニアの方、Webデザイナーの方を積極採用中です!社員1桁台のスタートアップに興味がある方はぜひWantedlyからご応募ください!