テックリード＆スモールチーム体制の導入で開発効率が凄く上がった話

こんにちは、たむらです。
皆さんは”テックリード”という言葉を耳にしたことがありますか？主にアメリカのIT企業などで広まっている役割名なのですが、最近日本でもその名前が使われる会社が増えてきているようです。

テックリードの明確な定義がある訳ではありませんが、一般的に下記の様な役割を担っています。

• 開発チームの生産性を最大化させる
• 採用した技術や設計に責任を持つ
• 品質面で責任を持つ・コードレビューの実施

ざっくり言うならば開発現場の責任者という感じでしょうか。ポイントは開発業務という部分にフォーカスした役割であり、いわゆるマネージメントにあたるような予算管理や人事考課といった業務は範囲外ということです。

さて、ラクーンではテックリードという名称ではありませんが、まさに上記の役割を担うポジションがあります。以前「ここ数年で技術部で定着した制度２つ」という記事で書きましたが、ラクーンではユニットチームという少人数チームで開発を行っており、そのユニットチームにはユニットセンターという代表者がいます。そして、このユニットセンターがまさにテックリードの役割に近しいことを行っています。
ユニットセンター体制は運用を始めて既に５年近くが経っており、運用実績も十分あるので今一度この体制についてユニットセンターという切り口で説明してみようと思います。

ユニットセンター体制の概要

まず、ラクーンで運用しているユニットセンター体制のおさらいです。※詳細は前掲の過去のブログを参照下さい。

• ２名～４名の小チーム
• プロジェクトや開発業務はこのユニットチームの単位で行う
• ユニットセンターという代表者が１ユニットチームに１名存在。報連相の仲介役
• ユニットチームは緩やかに担当するサービスが決まっている
• ユニットチームの再編やユニット間の人の移動は年に１回程度人事異動的に行う
• ユニットチームには名前を付ける（←大事！名前があると思い入れが違います）

当初ここに書いていた通り、ユニットセンターは”報連相の仲介役”でした。チーム内のメンバーはフラットなものとし、ユニットセンターはあくまでも代表者で、誰でも交代できるもの、という位置付けで考えていました。しかし、運用を経るに従って役割が自然と変わってきました。ユニットセンターを担当するメンバーは技術的にも経験的にも秀でていることが多く、結果下記の様な役割を担うようになっています。

ユニットセンターの役割

ユニットチームの運営

言葉通りになりますが、ユニットチームの「代表」というより、「運営」をしてもらってます。ユニットチームがベストなパフォーマンスを出せるように自身やユニットメンバーの役割を定めたり、チーム内での開発手法やルールの整備を行ってくれています。「会社で統一した開発フローを用意すればいいんじゃない？」と思われるかもしれませんが、開発手法や運用はサービスの規模や携わる人数、チームの個性によってベストなものは変わります。そのため、最低限の統一ルールは部門で定めていますが、それ以外の部分はユニットチームでの運用に任せています。また、開発案件の割振りやスケジューリングをする際は、単純に開発案件だけにフォーカスするのではなく、その開発を通してチームとチームメンバーをいかに育てるかという観点を持って開発管理をする様お願いしています。

開発（サービス）に関しての判断を行う

元々、業務仕様に関しては開発現場であるユニットチームで決めるという方針でしたが、現在はその裁量が拡大し、開発案件の検討やそこで用いる技術・設計方法など、担当しているサービスに関してのほぼすべてを意思決定する様になっており、ユニットセンターはその中心となっています。
例えば、スーパーデリバリーでは出展企業から小売店向けにメルマガを配信する機能があり、2017年にシステムリニューアルを行っています。その開発では出展企業がメルマガを設定するWEBフォームなどの他、メール配信システムをどうするか？という点が大きな検討項目となっていました。大量のメール配信、プライオリティの高いメールとの住み分けなど様々な要件を踏まえ、自社で用意するのか？外部サービスを利用するのか含め決めていく必要がありました。こういったことも、基本的にはプロジェクトを受け持ったユニットチーム内で検討を行い決定していっています。

チームとしての開発品質を高める

ユニットセンターはメンバー間のクロスレビューやコードレビューなどを通して、ユニットチーム内の品質管理を行っています。品質管理はレビュー等に留まらず、テスト手法の研修や計画的なリファクタリングなどに及び、包括的な品質管理に努めてくれています。

先に挙げたテックリードの役割と見比べてもらうとユニットセンターの立ち位置がほぼ一致していることがお分かりになると思います。

ユニットセンター体制のポイント

ユニットセンター体制のポイントだと感じていることを３つ挙げます。

１．スモールチームを監督してもらう

チームのメンバーは多すぎない方が良いです。ラクーンではユニットチームに割当てているので最大でも４名程度ですがこれがベストだと思います。人数が多くなるとユニットセンターがチームの運営やレビューに時間が取られる割合が相対的に上がり、結果としてユニットセンターの開発生産性が下がって全体のパフォーマンスも落としてしまうからです。

２．情報共有のハブの役割も担ってもらう

各ユニットチームへの情報共有やユニットチームからの情報開示はユニットセンターを通して行います。こうすることで、ユニットセンターは情報をくまなく集めることができ、精度の高いジャッジをすることができる様になります。また、必然的にユニットチームの把握や状況確認も行うことになるのでチームビルディングとしても有効です。
ちなみに情報はすべてオープンにして取捨選択は個人に任せよという考え方もありますが、ある程度情報のフィルタリングがされて必要な情報が必要な人に届くという方がスマートだと考えています。

３．権限委譲を明確にする

どの様な体制でもそうですが、役割を明確にして全員が理解していることは重要です。ラクーンでは下記の様に役割を分けており、役職者は基本的にサービスの開発案件に口出ししません。
 

役職者も得てして開発現場を経験しているので、ともするとアドバイスの域を越えた口出しをしたくなっちゃいますが、そこはぐっと堪えましょう　。信頼し権限委譲を行うことと、致命的な失敗が起きないように正しく見守ること、もしもの時には責任を取れることこそがこの体制の役職者の務めになります。

ユニットセンター体制にしたことによるメリット

ユニットセンター体制のメリットは前掲ブログでも書いていますが、運用を経て改めて大きなものを書くと以下の３点になると思います。

１．開発生産性が上がった

一番大きなメリットです。ユニットチームがそれぞれ自律的に動くことで開発の並行性と意思決定の速度が上がりました。更に個々のユニットチームがユニットセンターの牽引のもとでチームの開発生産性の向上を図ってくれており、改善が継続できているのも大きいです。
例えば、ユニットセンター体制にする前の２０１１年から２０１３年の年間平均プロジェクト実施件数は６．３件／年だったのですが、直近の２０１５年から２０１７年ではなんと１２．０件／年にまで増加し、約２倍程にもなっています。これは人員の増加率（約１．３倍）を差し引くとしてもかなり効果を実感できる数値になっていると思います。

２．品質が上がった

品質管理（QA)は以前は専門の担当がいたのですが、サービスが拡大し複雑化するに従ってサービスの理解度が追いつかなくなり、結果QA効率と指摘検出率が落ちていました。そこで、QA業務をユニットチームに移管しました。ユニットチームは担当するサービスが決まっているので、そのサービスの業務知識やバックグラウンドに対するナレッジが集積されており、第３者のQAよりも適切なQAを行うことができます。また前述の通り、ユニットチーム自体でQAの品質管理も行えているので全体的なQAの品質はかなり向上しました。
こちらも一例を示すと、２０１３年度と２０１７年度に発生した障害件数を比較すると３１％も件数が低減しています。更にその内クリティカルな障害に関しては、実に５５％の低減となっていました。

３．よりサービスに沿ったアプローチができる

自分たちで判断して決めていくという責任は、開発メンバーのサービスに対しての当事者感覚をより強くしました。その結果、事業部からの要望に対してより自発的な提案や意見が出るようになり、より価値の高い開発ができる様になっていると思います。事業部側として多くのプロジェクトに携わったプロダクトオーナーからはユニットセンター体制になってから「技術部がサービスに対して一緒に考えてくれてると感じる機会が増えた」という感想をもらっています。自社サービスの醍醐味であり、仕事の面白さに繋がる部分なのでそういった意味でも良かったポイントです。

ユニットセンター体制にしたことによるデメリット

逆にデメリットと思える部分も挙げておきます。

１．情報共有を意識的に行う必要がある

メリットの裏返しになりますが、意思決定をユニットチームで行うのでその情報を意識的にユニット外にも共有していく必要があります。ラクーンでは、定期的なユニットセンター会議とSlackを利用した適宜の情報共有をすることで意識的に情報共有を行える様にしています。

２．チームメンバーの入替えが大変

元々ユニットチームのメンバー変更は「人事異動的に」年に数回、数人程度で行うこととしていました。これはそれぞれのサービスの業務習得のために、ある程度腰を据えて取り組んでもらいたいという固定化の部分と、様々なサービスを経験してもらいたいという流動化の部分を考慮したものです。
しかし、４名程度のスモールチームで元のチームバランスを大きく崩さずメンバーを入替えるのはかなり検討が要ります。現状は年２回程ユニットチーム再編の検討機会を設けていますが、毎回頭を悩ませています。
ただ、チームの移動や担当サービスの変更は成長機会と考えているので、若手層や希望するメンバーにはできる限り積極的に入替えをしていくスタンスで臨んでいます。短期スパンで見れば一時的にチームの生産性は落ちることが多いですが、長期スパンではチームとメンバーの成長に繋がり結果的にメリットになっていくものと考えています。

いかがでしたか？適切に権限委譲を行い、責任と権限を持ってもらうことでチームやメンバーの成果は幾らでも変わってくると思います。興味を持たれた方は是非試してみて下さい！

以上、運用実績を踏まえたラクーンのテックリード＆スモールチーム体制についての改めての紹介でした。