ユアマイスター株式会社エンジニアブログ

ユアマイスター株式会社のエンジニアが日々徒然。

スタートアップ1人目エンジニアが、仲間を増やしEngineering Managerを志した

f:id:yourmystar_engineer:20181208084847j:plain


この記事は Engineering Manager Advent Calendar 2018 8日目の記事です。


こんにちは。ユアマイスター 星(@inase17000)です。

今年読んだ本の中で最もインパクトを感じているのが「エンジニアリング組織論への招待」で、Engineering Manager*1になりたい(でありたい)と強い衝動に駆られた一年でした。

僕自身、2017年3月からユアマイスターで働き始めてからを思い返してみると、「エンジニアリング組織論への招待」に書かれていたような問題に直面することがありました。

今回は、「最初から知識として持っていたらもっとうまく解決できたのか?」というタラレバ話はあまり意味がなく、全力で駆け抜けてきた自分を少しだけ褒めてあげながら、とあるスタートアップでこんな「あるある話」があったよ、というのをEngineering Managementの観点から振り返ってみようと思います。

エンジニアが1人しかいない初期フェーズ

ユアマイスター自体はエンジニア0人で起業された会社です。創業当時は開発会社にアウトソースする形で初期の「あなたのマイスター」の開発を行っていました。

その状態から、開発体制の内製化に向けて、開発環境の引き継ぎや案件の切れ目のコントロールなどから関わり始めた、という感じです。まだメンバーがいないということもあり、Engineering Managementする相手は主に自分になります。

この時期に強く意識していたことは、とにかく「無駄なものを作らない」ことです。エンジニアの数が少ない=リソースが最小であるということ。つまり、サービスの立ち上げ時期において、有限の時間をどう使うかが、プロジェクト成功可否を決めるかなと考えていました。

まだ立ち上げ直後ということもありシステムの複雑度は低く改修は容易で、アクセスも全然なかったのでパフォーマンス面も気にしていませんでした。改修要件は明確なものが多く、とにかくスピードを意識していたことを記憶しています。

開発速度にフォーカスして進める一方で、マーケットに受け入れられるか(マーケットの不確実性)に保証がない状態が続くため、できるだけ安心な方向に倒しておきたくなります。前職で盛大に、ユーザーが全然使わない機能を作り上げた経験と反省を持ってユアマイスターにjoinしていたこともあり、特に意識してプロダクトに向きあっていた点でした。

  • 無駄なものは作らない
  • 無駄だとわかったら、即効で退却する

そのときには直感的にやっていたことではありますが、要件をできるだけ小さく切り出し変化に対応できるような開発を繰り返していました。目的不確実性をいかにコントロールできるか、ということがテーマだったと後々本を読んでから言語化できたものでした。

エンジニアが2〜5人に増えたフェーズ

少しずつ仲間がエンジニアが増えていきました。スタートアップ独特の高揚感で毎日があっという間に過ぎて行きます。

幸い、メンバー間のいざこざや無益なマウンティングを取るようなイベントは発生しなかったものの、ユアマイスターはインターンも多くいるため、若手社員もいきなり後輩がいる状態でスタートするというカオスになりやすい状況。

無駄が起きないよう、開発のチケットをレベルや経験に合わせて一人ひとりに渡していたんですが、どうしても目の前のことに集中してしまって、同じようなミスを繰り返したり連携不足により手戻りが発生したりしてしまいました。

そこで真っ先に始めたのは1on1でした。週に1回〜2週に1回のペースで30分、開発業務から離れてひとりひとりと向き合う時間を作りました。

各個人のリフレーミングを促すレベルには達するのはなかなか難しく、沈黙が怖くて自分が喋りすぎてしまうことも。今ひとつ手応えを感じない1on1を過ごしました。

後で本人たちからフィードバックを聞いてみると、話せる時間が持てるのが良かった、という「エンジニア→僕」の情報伝達の場としては成功していたようですが、それをうまく引き出す安心感のある雰囲気づくりは及第点だったと思います。

  • 1on1大事。時間かければいいというわけではなく、エンジニア自身がどれだけしゃべるか
  • 一緒にパズルを解いてあげるのではなく、パズルの問題の構造を明らかにする手助け

そんなことを学べた時期だと思います。偉そうに書いてますが、ほんとまだまだだと自覚してるので、今後も改良を加えながら続けていきたいなと思います。うん、難しい!!

前にストレングス・ファインダーで調べた僕の強みを調べたことがあるんですが、

  1. ポジティブ
  2. 成長促進
  3. 回復志向
  4. 達成欲
  5. 信念

という感じになっていて、「成長促進」が上位にあることがわかっていたので、他メンバーへの考えるきっかけを与えるような時間は楽しくてたまりません。それが結果として成長につながっているのかというのは目に見えるパフォーマンスで判断していくしかありませんので、定期的に向き合う場は大切にしていきたいです。

エンジニアが6人以上のフェーズ(イマココ)

一人ひとりのエンジニアに向き合うことよりも、プロダクトに向き合う時間が増えたというのが正直な感想です。自分がコードを書かずに他のエンジニアに任せ、徐々に自分は少しだけ先のことを考える時間をもらえたのもこのタイミングになります。

実は、僕はもともと1人でタスクを抱えがちになる性質を持っているので、前職ではいっぱい怒られていました*2。自分の弱い部分を見せたくないという防衛本能が働いていて、勇気を出してチームに曝け出せない。

問題が起きているのに時間が経てば立つほど、選択肢は減っていく。個人の重荷が増えていく。そんなチームはいやだ!楽しくない!

あえて自分を逆に振るために考えたテーマは「On the table」。これが僕の支えになっています。

みんなのテーブルの上に全部出しきってから、どれが一番いいかみんなで考えようよ、ということです。丸裸。ここでいうテーブルは、四角いテーブルではなく、丸いテーブルをイメージしています。

f:id:yourmystar_engineer:20181208090745j:plain 裏紙ですみません。

セールス、ディレクター、エンジニア、いろんな立場の人が四角いテーブルに対してそれぞれ真正面から向き合うことに抵抗を感じるのではなく、ただ一つの中心点に向かう丸いテーブル(円卓)に集まり、全員のポケットの中身を出し切って、それらの中で一番いいと思われるアイディアを形にすることに時間を使いたいという思いでした。

実際は円卓があるわけではないので、付箋に書き出して貼りだしたり、会話しながらホワイトボードに書いて見える化したり、とにかく同じものを見て感じたことを口にするということを都度繰り返しました。チームでも少しずつその癖は拡がってきていると感じていて、立ち話からホワイトボードに移動する様子をよく見かけます。

チャットで話して3ラリーくらい続けてるのを見つけると「直接話そう!」と集まることをしつこく繰り返しました。URLや資料を貼り付けたいシチュエーションじゃない限り絶対、超高速音速伝達技術*3である「直接の対話」に勝るものはありません。

これからもっと人数増やしていくとキツくなるんでしょうが、それでもやっぱり対話にこだわっていきます。

まとめ

人数規模に応じて少しずつ、チームメイト同士の会話は時間が減っていくことは避けられない。(n角形の対角線の数はn(n-3)/2本!二乗の関数)

いまのところ僕らのチームは、情報の非対称性をなくすことが全員のパフォーマンスを最大化するための最初の取り組みだったかなと思います。

具体的には、

  • 1on1で自省を促す
  • アウトプット中心の行動喚起
  • コミュニケーションが作りやすい機会設定

そんなことをやりながら、激動の2年間をエンジニアたちの手で支えてきました。(まだ続いていますがw)

僕自身が途中からコーディングから離れたという経緯+劇刺さりな本に出会うことがあった2018年。少しだけEngineering Managerに近づけたと思います。

最後に、この前 #EM.FM の話題にあった、Engineering Managerはスーパーマンじゃない。本当にそうだなと思いますw

管理する人っていうイメージはきっといらなくて、なんとかする人なんだよ、って考えるようになりました。

Engineering Managerは、Engineering で事業や会社やプロダクトを「なんとかする人」だという信念を持って、チームのために貢献していきたいと思います。

以上、ありがとうございました!

*1:Engineering Managerってなぜか英語で書く人が多いのはなぜなんだろうか。。。まだ答えは出ていないが、合わせます

*2:今も時折みんなに怒られますw

*3:Joy,Inc.の受け売りです