エンジニアの数が10倍になっても、開発スピードは10倍にならない　開発生産性向上に取り組むために専門チームをつくる3つのメリット

開発生産性の可視化・改善のために専門チームをつくった

pospome氏：では、「組織全体で開発の生産性に取り組むためにチームを作ったよ」という話をしようと思います。pospomeです、よろしくお願いします。

今回の発表では、DMMプラットフォームという組織において、開発生産性の可視化や改善に取り組んでいるわけですが、それをやるためにわざわざ専門のチームを作ったよという話をしようと思います。

けっこうサクッと話すので、なにか聞きたいことがある人は、懇親会や質問などで聞いてもらえればいいかなと思います。

DMMプラットフォームの組織規模

まず、僕が所属するDMMプラットフォームという組織について話します。このDMMプラットフォームという組織は、DMMの中では1つの部署になります。どういった部署かというと、DMMの会員のマイページや決済のWeb APIなど、DMMの各種サービスで共通利用されるような機能や画面を開発・運用している組織です。

1つの部署ではあるのですが、エンジニア数は120名以上で、2016年くらいからマイクロサービスに取り組んでいます。こういった規模感の組織の開発生産性を可視化したり向上したりしようとしているという話になります。

エンジニアの数が10倍になっても、開発スピードは10倍にはならない

開発生産性の話をする前に、まず大きな組織と開発効率の関係について話そうかなと思っています。みなさん知っているとおり、大きな組織ほど開発効率は下がるんですよ。エンジニア数が10倍になっても開発スピードは10倍にはなりません。例えば8倍とかそのぐらいに抑えられるわけですね。

なぜかというと、原因としては2つあります。まず1つ目は、コミュニケーションコストの増加です。大きな組織になるほど、なにか決定をする時に特定のステークホルダーと話さないといけなかったり、「このタスクを進めるためにここのチームに連絡しないといけない」といったかたちになって、コミュニケーションのパスがどうしても増えてしまうんですよ。

そのコストを低くする工夫はできるかもしれないのですが、やはりどうしても必要最低限のコストはかかってしまうので、開発効率が下がっていくというかたちになります。

そして2つ目が、横断的関心事に関する開発工数の増加。今回はこちらをメインで取り上げようかなと思うので、少し説明していきます。

まず「横断的関心事って何？」という話なのですが、僕はこの単語をプログラミングの文脈で知りました。横断的関心事の実装というのですが、これは、例えばプログラミングでいうログやトランザクションといった、アプリケーションのいろいろなところで必要となる実装、機能のことをいいます。

組織の開発体制といったところにもこのワードは適用できるかなと思っていて、今回の文脈では、組織全体に共通して必要となる作業のことを、横断的関心事と表現しています。（スライドを示して）スライドの図では、CI/CDパイプラインの例を挙げています。

DMMプラットフォームは120名の開発組織なので、中に開発チームがいっぱいあります。そういった開発チームが普通に開発を進めると、各チームがCI/CDパイプラインを作ることになります。なので、各チームが結局なんとなく同じようなことをやっていて、組織全体で見た時の開発効率はちょっと悪いんですよ。横断的関心事を各チームでシンプルにそのまま扱ってしまうと、開発効率が悪くなってしまいます。

開発生産性を「横断的関心事」として取り組む

ではどのようにアプローチするのが良いのかというと、このスライドの図にあるように、専任のチーム、スライド上ではプラットフォームチームという名前になっているのですが、こういった1つのチームをまず作ります。

そしてそのチームが、各チームが利用するCI/CDパイプラインを1つドンと用意します。そして各開発チームはそれを共通で利用します。（スライドを示して）スライド上だとCI/CDパイプラインがそれぞれ1つずつあって、それらを2つの開発チームが使っています。これが例えば20チームとかになると、この開発効率の削減、改善の効果というのは、ものすごい効果になっていきます。

最近ではこういったものはプラットフォームエンジニアリングみたいな文脈で説明されたりするのですが、開発生産性も特定のチームだけ取り組まなければいけないものとかではなく、基本、どの開発チームも横断的に取り組むようなものなので、横断的関心事に属します。

DMMプラットフォームのような120名のエンジニアリング組織だと、さすがに「各チームでいい感じにやってくれよ」と言うことはちょっと難しい。効率が悪くなるので、専任のチームを作って取り組むというアプローチに倒しました。

専門チームを作るメリット1　各チームが同じようなことをする工数を削減できる

ということで、僕はDeveloper Productivity Groupというグループを作りました。今回は、専門のチームを作るメリットについて3つ簡単に話そうと思います。

まず1つ目です。各チームが同じようなことをする工数を削減できる。これは先ほど説明した「各チームで同じようなことをするの無駄だよね」みたいな話とそのまま同じです。

例えば開発生産性を可視化するという時に、「まずFour Keysを可視化してみようかな」みたいなことはけっこうあるあるだと思うんですよ。でも、Four Keysを可視化するのも意外と大変なんですよね。

例えば、デプロイの頻度はCI/CDパイプラインから取らないといけない。変更のリードタイムは「GitHub」かな？　変更の障害率や復元時間みたいなものは「監視ツールから取ってこよう」みたいな感じで、可視化するにもけっこう面倒なんですよ。

さらに、Four Keysを実際に可視化したことのある人だとわかると思うのですが、各メトリクスに外れ値などがあったりして、平均を取ってもうまくいかなかったり、最頻値みたいなのが欲しいとかで、これを可視化するのにもけっこう大変だったりするんですよね。

具体例としてFour Keysを出しましたが、開発生産性は別にFour Keysだけ可視化すればいいというものじゃないので、各チームが同じようなことをする工数というのは、開発生産性に真面目に取り組めば取り組むほど、コストが大きいものになってきてしまいます。

こういった問題があるので、Four Keysに限らず、Developer Productivity Groupが、なにかしらの共通の仕組みをドンと作って、各チームのメトリクスを見られるダッシュボードを作るみたいなことをすると、工数を削減できるというアプローチになります。

専門チームを作るメリット2　各チームのノウハウをシェアできる

そして2つ目。各チームのノウハウをシェアすることができる。やはり大きな会社だと、いろいろなエンジニアがいて、それぞれ得意分野があったりするので、それらの知見をいかに組織全体に浸透させるかといったことがけっこうポイントになってきたりします。

「各チームで開発生産性をいい感じにやってね」と普通に言うと、やはり120名もエンジニアがいると、エンジニアのレベル感はピンキリなんですよ。

みなさん学生時代に定期試験とかやったことあると思うのですが、学年1位の人の学力と学年120位の人の学力ではけっこう差があった記憶がありません？　エンジニアリングもそれと同じで、うまくできる人とできない人がいて、結果的にうまくできるチームとうまくできないチームに分かれちゃうんですよ。

なので、普通にやると、特定のチームだけうまくできているけど、ほかはうまくできていませんといったかたちになってしまいます。

組織全体で見た時は、全チームがうまくやれるようにする必要が当然あるので、専任のチームが組織全体の最適化をちゃんと進めていくというアプローチが必要になります。

そして、組織全体の最適化を進めていくという、こういったマインドを持っているからこそ、「各チームの状態をまず相対的に比較しよう」とか、「課題を可視化して解決しよう」というような発想が生まれてくるんですよね。

こうなると、「ここのチームはこれがうまくいっているけど、ここのチームはこれがうまくいっていないから、それぞれのチームにヒアリングして、なんでできていないのかというのを情報共有しよう」とか、こういったノウハウの共有が可能になります。

（スライドを示して）例として、開発生産性アンケートと書いてあるのですが、実際のものはこちらになります。各チームに「あなたたちのチームは、どのぐらいうまくやっていますか？」ということをヒアリングした結果になりますね。表の説明はしませんが、数字の低いところがあったり、高いところがあったりと、各チームで得意な分野と苦手な分野がけっこうばらついていたりするんですよね。

こういったヒアリング結果を基に、各チームに直接話を聞きにいって、開発生産性の良いところを共有したり、問題点を改善したりしていくというアプローチをすることができます。

こういった表を作って組織全体をいい感じにしようということは、専任のチームがいないと、おそらくこの発想にならないんですよ。各チームでやった場合は、「それぞれのチームがうまくいっていればOK」というかたちになっているので、全体的に各チームの相対評価をしてノウハウを共有するという、大きな組織だからこその強みを活かすという発想にならないわけですね。

専門チームを作るメリット3　その領域にフルコミットできる

そして3つ目。各チームが開発生産性に取り組む工数は限られている。これも当たり前の話ですが、例えばDMMプラットフォーム内には決済チームというチームがあります。この決済チームは何をするかというと、より使いやすい決済や失敗しない決済といった、決済領域にとにかくフルコミットするべきなんですよね。

なので、開発生産性の向上にフルコミットできないんですよ。というか、むしろフルコミットすべきではないんです。なぜかというと、決済領域を改善できるのは決済チームしかいないので、この決済領域にいかにフルコミットさせるか、そのほかの横断的関心事に対する工数をいかに削減するか、削減してあげるかがポイントになってきます。

そして開発生産性の可視化が終わった後は、スコアが悪いところとか、問題になっているところを改善していくと思うのですが、課題によっては、「改善するにはけっこう大きく工数を割かないといけないな」みたいなものがあります。

先ほど説明したFour Keysの可視化とかも入ってくるのですが、例えば「負荷試験にやたら工数がかかっているな」と。ゼロからツールを選定して、ゼロからなにかをやってみたいに、すごく時間がかかって（しまって）いるという時に、それっぽい負荷試験基盤を作りたいなという発想になるかもしれないのですが、各チームで負荷試験基盤のような仰々しいものを作っている工数はないんですよね。

そして、負荷試験自体も実は横断的関心事です。負荷試験をしないチームはないですよね。

なので、「こういった負荷試験基盤を作れば開発生産性が改善できるんじゃないのか」と。そして、その領域にフルコミットできるのは、専任チームならではの話になってきます。

（スライドを示して）3つ目に書いてある、コードの品質の可視化とか改善とかもそうです。コードの品質の可視化に関して、DMMプラットフォームの場合は、「SonarCloud」というSaaSを使っています。

こういったSaaSの選定や、そのツールを使う費用をどのチームが、どの部署が負担するのかといった細かいことも含めて、専任のチームがあれば自ずと「そのチームがやるべきだよね」というかたちになって、物事の決定も早くなっていきます。

大きな組織になったら“手が回りきらない部分”を担当するチームが必要

ということでまとめです。各チームの手が回りきらない部分を担当するチームが、大きな組織になれば必要になるよという話です。

2つ目がけっこう重要ですね。みなさんたぶん薄々感づいていると思うのですが、ある程度の組織規模じゃないとコスパが悪いです。DMMプラットフォームは100人を超えるエンジニアがいて、多くのチームがあるからこそ、専任のチームを作るという方向に投資することができるんですね。

でも例えばですが、エンジニアの数が30名に満たないとか、20名に満たない、そういった規模だと専任のチームを作るというよりは、例えば会社の中に3つのチームがあったら、3つのチームで情報共有しながらなんとなく開発生産性に取り組んでいくみたいな、そういったファーストステップを踏むのが良いんじゃないのかなと思っています。

ということで以上になります。ありがとうございました。