急成長サービスの開発責任者として意識している４つの『やらないこと』と１つの『大切なこと』
この記事は eureka Advent Calendar 2016 — Qiita の25日目の記事です。
24日目はCEO石橋による「大規模サービスにおけるシステム構成の変遷」でした。
10月より、石橋から引き継いでCTOになりました kaneshin です。就任後はエウレカの技術組織のことをより深く考えたり、兼任のマネージャーとしても組織マネジメントの改善などで奔走していましたが、2016年にやりたかったことがたくさん残ってしまっているので、2017年が今から楽しみです。
さて、今回はPairsの開発責任者として技術面の責任者、即ち、テックリードをしているとき、物事の判断の基準において、常に意識していることを紹介します。
テックリードとは？
そもそも、「テックリードとは？」という方もいると思いますので、エウレカで定義しているテックリードの役割を紹介します。
- 高い技術力を有し、プロセス・ビジネス課題に対する技術的投資を行う
- チームの技術責任者として、開発・運用プロセス全体を管理し、最終責任を持つ
- チームの生産性を向上させるべく、非エンジニアと適切な表現を用いてコミュニケーションをする
- プロダクトの価値を正しく理解し、ビジネス成長にコミットする
つまり、『高い技術力を有し、技術責任者として、プロダクトと技術を融合させ、チーム全体のスループットを最大限に向上させる』ことに対し、責任を持つ人となります。
Pairsチームにおけるテックリード
Pairsチームには明示的なテックリードのポジションはありませんが、開発責任者がサービスのテクニカル面について責任を持っています。そのため、責務としては VP of Engineering と Tech Lead の兼任となるので、状況をよく踏まえた上で、取捨選択していくことも重要になります。
兼任による意思決定のスピードアップに加え、急成長しているPairsでは常に『選択と集中』を適切に実行。事業規模の拡大に伴うチーム体制のマネジメントや、プロダクトの品質改善を目的とした守りの開発、プロダクトオーナーや各チームの責任者との綿密なコミュニケーションを開発責任者が行ってきました。
意識している４つの『やらないこと』
ToDoリストにおける『やらないこと』と、いうわけではありません。
物事の意思決定において、自身が持つ 軸をぶらさない ことと、 迅速な意思決定 を行うために、 『やらないこと』 を価値観として持っています。
『やらないこと』の明確化においては、『やること』を定めるよりも、自身の役割を正確に理解し、事業の成長状況を常に把握しておくことが重要だと思っています。
そして、事業の成長に合わせて、組織のフェーズも常に変化するので、状況に合った意思決定を迅速に行わなければ自身がボトルネックとなり、事業の成長を阻害してしまうこともあり得ます。
1. 組織文化に反する選択は行わない
- 組織文化に反する選択
- 組織文化にそぐわない選択
は行わないようにしています。
・組織文化に反する選択
組織文化というのは、 『今まで企業が事業を成長させてきた結果』 によって醸成されるものです。これを無視して、組織文化を変え、何かを実行するということは目的と手段が逆転している状態になります。この状態で物事を進めていると、自分たちがどこを目指して進んでいるのかが不明になり、カオスな状態に陥ると思っています。
・組織文化にそぐわない選択
企業の掲げるミッション・ビジョンや行動規範にそぐわないことを実行した結果として、価値が企業に見合わなければやる意味がありません。
ただ、ここで注意していただきたいのは、文化を緩やかに変更させながら成長させるということはもちろんあると思っています。つまり、『結果として、組織文化が変わった』という選択は全く問題ありません。
2. 評論家になってはならない
これはテックリードというより、私自身が新卒の頃から大切にしていることです。図書館のように、知識だけふんだんに持ち合わせているが、形として何もアウトプットを行わない人を指しています。
『エンジニアだからコードを書け』と言っているわけではなく、テックリードであるからこそ、高い技術スキルを使って設計・コードレビューを行うことや、開発や運用のプロセスと向き合い、それの改善のために自身がアウトプットすることを指しています。口だけ動かしている人のもとに、誰も付きたいと思いません。
そして、評論家というより、知識収集家観点ですが、他者・他社の成功体験のナレッジを鵜呑みにせず、常に俯瞰した視点でナレッジを吸収することも重要だと思っています。
成長している事業の過程は企業によって異なりますし、組織の文化ももちろん違うので、他社の成功の方程式がそのまま自社でも当てはまるとは限らないです。組織・事業・技術・人の変数によって、最適解は異なります。
あと、評論家については 『ピーターの法則』 の 『組織が無能な人で埋め尽くされる』 に陥ってしまったときだと思っています。
3. 完璧を目指さない
完璧主義になると、結果として停滞を生んでしまいます。
エンジニアとして優れている人は設計やコード・テストの品質がとても素晴らしいかもしれませんが、完璧主義を持ち合わせてしまうと、いつまでも設計に時間をかけてコーディングを始めようとしません。
ー “Done is better than perfect”
ー “Move fast and break things”
これらはFacebook社の社是ですが、このような意識をもって事業の改善に取り組み、 『許可を求めるな謝罪せよ』 の気持ちで、とにかく最初は完璧を目指すことをせず、エンジニア文化として 『PR大歓迎』 を根付かせてしまいましょう。
4. 一日のデプロイ回数を減らす選択は行わない
前に述べた３つと比べると、かなり技術の方に寄っていますし、粒度も小さいように見えますが、技術選択において、価値のデリバリ速度を落とさないという指標は、事業成長に寄与すると思っています。
- プロダクト改善した 価値 を素早くデリバリするため
- 継続かつ高速にデリバリするために 技術的負債を適切に返済 する
技術選択として、デプロイ回数を減らす選択は、価値の提供を遅くすることに繋がり、事業の成長を鈍化させる要因に繋がると思っています。
もちろん、安全にデプロイすることは極めて重要なので、安全にデプロイする方法を確立しておかなければなりません。
これらの点をチームの共通認識として、自分たちが抱えている技術的課題をお互いに出し合うことも重要です。
意識している１つの『大切なこと』
『やらないこと』とは違い、私がエンジニアとして常に心がけていることです。
謙虚・尊敬・信頼 — HRT
『謙虚・尊敬・信頼』はエンジニアなら知っている人が多いと思いますが、書籍「Team Geek」に書かれている言葉で、この『謙虚・尊敬・信頼』の欠如によって人間関係の衝突が生じます。
私自身、エンジニアとしての価値観を持っているし、他のエンジニアはまた別の価値観を持っています。また、エンジニア以外の方からすると、エンジニアの生態は非常に理解し難い存在だとも思っています。
そのようなことをエンジニア自身がしっかりと理解し、複数のエンジニアが関わる場面では個のスキルを立たせて成功を勝ち取るのではなく、チームメンバー全員が最終目標に向かって協力しなければ、チームとして仕事をしている意味がありません。
先ほどまで、４つの『やらないこと』を述べましたが、この「Team Geek」に具体例が書かれています。
HRTの結果として『最終責任者』となる
形としての『最終責任者』は肩書きが付けば良いだけです。この、肩書きではなく、自身のスキルとして『最終責任者』としてコミットするには、技術的な最終責任を負える人材、かつ、『◯◯さんが言うなら大丈夫』 という尊敬・信頼を積み重ねることもとても大切です。
そのためには謙虚であり続けなければいけませんし、尊敬されるだけでなく、相手を尊重することも重要です。
このように、全員が動くことができれば『心理的安全性』が保たれたチームにもなり、発言が活発でプロダクティビティなチームに成長するとも思っています。
おわりに
責任を持つ立場の人は、常に意思決定をしなければなりません。そのときに、軸がブレた回答をしていると、『信頼』されない可能性があります。
また、自身がチーム開発の責任者である場合もそうですし、メンバーとしてコミットする側であっても、『謙虚・尊敬・信頼』は絶対に意識しなければならないポリシーだと思っています。また、注意して欲しい点として、「Team Geek」の第4章に書いてありますが、『謙虚・尊敬・信頼』が欠如している人は自身がそのことに気づいていないパターンが多いらしいので、この記事を引き合いに出して会話をするのではなく、お互いにしっかりと理解を深めて行くのが最良パターンとなります。
最後に、「Team Geek」を読んでいないエンジニアは是非読みましょう。チームで開発する上で知っておくべきエンジニアの生態です。
