2024年11月15日、ファインディ株式会社が主催するイベント「開発生産性Kaigi スタートアップが目指す、開発と事業成長の接続〜価値創造への挑戦〜」が開催されました。

本記事では、株式会社はてなでチーフエンジニアを務める大仲 能史さんによるセッション「強いチームと開発生産性」の内容をお届けします。

■登壇者プロフィール 大仲 能史(@onk) 株式会社はてな チーフエンジニア

2018年4月 中途入社。複数のサービスやチームを経験した後、2023年2月よりエンジニアリングマネージャーとしてサーバー監視サービス「Mackerel」の開発を担当。チーフエンジニアとして技術組織全体のマネジメントにも携わる。

3つのレベルで表す開発生産性、アウトプットとアウトカム

大仲：「強いチームと開発生産性」というタイトルで発表させていただきます。まずは自己紹介です。大仲と言います。インターネット上では、onkという3文字のIDで活動しています。芸歴20年目で、得意領域はバックエンドとインフラです。株式会社はてなに所属しており、今は京都からつないでいます。いろいろな役割を持っていますが、今日は開発チームの一員という立場でお話ししようと思います。

まず開発生産性とは、という話からしていきましょう。生産性というのは、そのまま生産する能力のことですね。これはアウトプット/インプットという形で表せます。つまり、突っ込んだ量（インプット）を分母として、それに対して返ってくる量（アウトプット）の割合を表したものが生産性です。

大仲：インプットには、次のようなものが考えられます。まず、労働人数や労働時間、人月ですね。人月は、一人ひとりの給料やスキルの差を表していないので、そのあたりまで含めると、開発にかかった人件費全部になることもあると思います。また、マーケティングにかかった費用やインフラ費など、事業に関わるすべてのコストをインプットとすることもあるでしょう。

アウトプットは、書いたコードの量とすることもあるでしょうし、コードをたくさん書いても施策がリリースできていなければダメだということで、リリースできた施策の数とすることもあるかもしれません。また、その施策がちゃんと効果につながっているか、最終的なKGI、売り上げにつながっているかも大事だったりしますよね。

はてなでは、「新しい体験を提供し、人の生活を豊かにする」というミッションを掲げていますが、こうしたミッションがどれだけ達成できているかをアウトプットとすることもありえると思います。

今回はある程度そろえないと話が進まないので、インプットの方は時間にそろえようと思います。なので、単位時間当たりのアウトプットを、開発生産性と定義していきます。これには3段階あり、まず書いたコードの量やリリースできた施策の数は、自分たちの仕事量に結びつくアウトプットですね。

その施策が想定しているKPIの変化、例えばユニークユーザーが増えるとか、回遊率が上がるとか、そういった期待を増やした数が、レベル2の開発生産性。そして、本当に実現された付加価値を表すものとして、実際に変化したKPIや売り上げが変化した数を、レベル3の生産性と呼んでいきます。

大仲：Qiitaに広木 大地さんが書かれた「開発生産性について議論する前に知っておきたいこと」というエントリーがあります。そこでは、レベル1が仕事量の生産性、レベル2が期待付加価値の生産性、レベル3が実現付加価値の生産性として、このような図にされていました。

どれだけの量の仕事を終えることができたか、どれくらいの価値が期待される仕事をできたか、実際にどれぐらいの価値が実現できたか。そういった3つの生産性になっています。

大仲：続けて、アウトプットとアウトカムの話をしていきます。アウトプットとは、そのまま自分が出力した量のこと。なので、レベル1生産性ですね。そこから、期待できる付加価値をどれくらい実現したのかという、リリースした施策の数あたりもアウトプットになっていくと思います。

大仲：対して、アウトカムというのは結果なので、自分が出力したことによって起きた対象の変化の量がアウトカムになります。期待付加価値や実現付加価値、実際に売り上げがどう変化したのか、ユーザーにどんな価値を届けられたのかといった部分ですね。

先ほどの図で表すと、アウトプットはレベル1からレベル2にかけて、アウトカムはレベル2からレベル3の生産性を表していると考えられます。

大仲：アウトプットがすごくてもアウトカムがない、ということはありえて、どういうことかというと、結果に結びついていない無駄な努力をものすごくしている場合です。これは高速にゴミを作っていると言い換えることもできて、俗にビルドトラップと言われています。アウトプットの量だけに着目した結果、何を作っているのかがあまり目に入らなくなっている状態ですね。

開発チームとして、とにかく高速なアウトプットを目指す

大仲：少し別の話になりますが、デュアルトラックまわりの話をさせてください。デュアルトラックアジャイルは、仮説検証サイクルを早く回すことを大事にした考え方です。仮説検証で最も遅い方法は、実際に製品を作ってリリースすることだと思っていて、コストをかけて本物を作り、それを出してやっとフィードバックがある形だと、すごくサイクルが遅いんですね。

なので、コストをかけて本物を作る前にダメな案を高速に潰したり、フィードバックを経てブラッシュアップするためにプロトタイプを作ったりする。そういうふうに高速に仮説検証を回していく考え方が、デュアルトラックです。

デュアルトラックでは、ディスカバリートラックとデリバリートラックの2つに分けて考えます。ディスカバリートラックの方では、この施策はどれくらい当たるのかといった、確からしさを検証する。検証して潰れずに次のトラックまで届いたものを、デリバリートラックで作ります。

ディスカバリートラックは、主にプロダクトマネージャーの仕事で、作るものを決めていきます。ここでユーザーインタビューをしたり、プロトタイプを作ったり。プロトタイプを作るところは、エンジニアも絡んできますね。図の途中にあるように、仮説検証した結果、ゴミ箱の中に入っていくこともよくあるので、必ずしも新しいアウトプットが出てくるわけではありません。

図の下側がデリバリートラックですね。こちらがコーディングを伴う作業で、スクラムチームの仕事になります。作ってリリースしてユーザーの反応をうかがって、学習したことからまた新しいことを次の施策に生かしていく、そういうサイクルです。

大仲：このデュアルトラックを目的地にたどり着くことに例えると、ディスカバリーは地図やカーナビ。どこに向かうのかを見定めるための装置ですね。デリバリーは車で、目的地にたどり着くための手段です。そこには遅い車があったり速い車があったりすると思います。

地図と車、どちらも大事なんですよね。地図がないと迷子になってしまうし、車が三輪車だったらすごく時間がかかって、目的地にたどり着けません。このどちらも大事であることを、よく「正しいものを、正しく作る」と表現しています。

“正しいもの”は、ちゃんとユーザーに価値が届くものを作れているかという、ディスカバリーの方ですね。“正しく作る”は、高速に回していきましょうというデリバリーの方です。こういった考え方は、シフトレフトという言葉でも言い表されています。

シフトレフトはセキュリティ界隈で始まった言葉だと思いますが、リリースされた後にセキュリティの問題が見つかって修正すると、すごくコストがかかってしまうので、リリースする前、テストの段階、コードを書いている最中に見つけたい。そうやってどんどん前倒していく、右側がリリースされたものだと考えたとき、左側に倒していくということで、シフトレフトと言われています。

施策そのものに価値があるのかを考えたとき、価値がないものに対してコードを書いていると遅くなるので、企画段階で潰せた方がいい。なので、企画に対してもシフトレフトしていこうという考え方です。

大仲：ディスカバリーとデリバリーは両輪だと言われています。ですが、ここでちょっと逆張りを仕掛けたいと思っていまして、開発チーム目線だと両輪ではないんですよね。私の考えでは、圧倒的にデリバリーが先で、ディスカバリーが後です。

遅い車というのは、とにかく問題なんですね。どれだけ地図がピンポイントな場所を指し示していたとしても、そこが何キロか先だとしたら、三輪車では一向にたどり着けません。地図が指し示す方向がベクトル90度以内に収まっていれば、とりあえず近づくことはできます。

絵のコンパスが左上を指していますが、45度ズレて北に歩いていっても、本来指し示していた左上には近づいているわけです。なので、それ以上の精度が本当に必要かは疑問で、多少精度が悪くても近づくことができるなら、どんどん回した方がいいと思っています。

大仲：イテレーションを素早く回せば、修正していくこともできます。行き過ぎたり、方向がズレてしまっても、2回目のイテレーションでより正しそうな方向に軌道修正すればいい。これが1回しか回せないと、ウォーターフォールのようになっていきます。だから、イテレーションをバンバン回していく方が上手くいくと、僕らは知っているのではないかと思います。

アウトプットとアウトカムと言われますが、アウトプットの方が低いと話にならないんですね。なので、私の考えでは、高速ゴミ製造機でありたいと思っています。ゴミを作るかもしれないけど、良い企画に当たったら、高速にアウトカムを作れる能力を持っているということですよね。止まった時計でも1日2回は正しい時間を指すので、たまには大当たりもある。そういうときに、高速にアウトカムが出せる開発チームでありたいと考えています。

高速に回せることは、チームの強さにもつながっていて、PDCAを回した数だけチームとして強くなっていきます。振り返りを経て、改善しているという実感が手に入り、改善を続けるなかで、自然とチーム内の役割分担もされていく。どんどん目標達成に対してコミットできるチームになっていくので、イテレーションを回すことそのものに価値があると思っています。

もちろん場合によるところもあって、打席に立てる回数には限りがあります。もしその事業が半年後に潰れるかどうかの瀬戸際であれば、ゴミを作っている余裕なんてありません。そういう状況であれば、打率を上げることに注力する必要がありますが、普段の開発チームは、高速のアウトプットに対して注力していることが自然な姿だと思っています。

まずはアウトプットで80点を狙いましょうということですね。アウトプットが80点になっていれば、アウトカムの方に手を伸ばす余力が生まれます。

開発生産性を阻害する“ツラみ”の検知とFour Keys

大仲：どれくらい生産性が高いのかというアウトプットの評価については、皆さんが言われている通り、Four Keysを見ていけばいいと思っています。Four Keysは、デプロイの頻度、変更のリードタイム、変更障害率、サービス復旧時間の4つの指標ですね。

こちらのデータでは、ローパフォーマーからエリートに分かれています。今はエリートがなくなっていますが、2019年当時のデータです。リードタイムとデプロイ頻度が開発速度に対する指標、変更失敗率と障害復旧時間が品質に対する指標ですね。これは大量のサーベイ結果をクラスタリングしたデータで、開発速度と品質がトレードオフではないということがわかります。

大仲：ローパフォーマーはすべての数値が低く、エリートはすべての数値が高くなっているんですね。デプロイ頻度では、半年に1回しかしていないローパフォーマーと、1日何回もしているエリートとの間に、数百倍もの差が生まれています。これには、継続的デリバリーやDevOpsの組織的な投資が大きな差になって表れていると考えられます。そのため、強いチームはDevOpsが前提です。

DevOpsとは、この図のようにDevとOpsが無限ループで回り続けているものですね。DevOpsツールチェーンを活用していることや、自動化されていること。そして、継続的にデリバリーされていることも、1日複数回デプロイするためには当然必要になってきます。また、DevとOpsが分かれていてリリースをお願いするような体制ではなく、組織文化そのものからDevOpsに最適化することを考えていく必要があります。

大仲：2021年になると、ローパフォーマーとエリートの差はさらに広がっています。DevOpsに投資しているエリートはより高い数値になっていく一方で、投資できていないローパフォーマーはズルズルとジリ貧になっていることが見て取れます。

大仲：ただ、開発生産性にはそれを阻害する力というのがあって、自然と溜まっていくんですね。このツラみが溜まっていく例を、いくつか挙げます。サービスを運営しているとユーザーデータなどが蓄積して、レスポンスの速度が徐々に悪化していくとか。仕様の変更によって設計に無理が生じて、増改築したコードベースになっていくとか。

世の中では新しいライブラリがどんどん生まれるわけですが、その更新への追随を怠っていると自分たちのプロダクトが古びていってしまうとか。あとは、サーバーが突然応答しなくなったり、人が流動したりもします。人がいなくなると、チームのノウハウは低下していきます。なので、何もしなければツラみが徐々に溜まっていって、開発生産性は悪化する一途になります。

大仲：そうはなりたくないので、何かしたいわけなんですね。そのためには、ツラみが溜まってきたことを検知したい。ツラみの検知に、Four Keysがどれくらい使えるのかが気になるところです。

デプロイ頻度は、ツラみが溜まってきたからといって、1日に1回のデプロイを2日に1回に下げるようなことはあまりないと思うので、おそらく変わらないだろうと。変更のリードタイムは、コードベースが徐々に複雑になって、リリースが遅くなっていくことはあるでしょう。変更障害率は、ここも複雑になっていくのでミスが生まれやすくなって、徐々に悪化していくことが考えられます。

サービス復旧時間は、DevOpsのツールをどれだけ使いこなしているかだと思っていて、例えばコンテナイメージをデプロイするだけになっていたら、ロールバックは別のイメージIDを指し示すだけですよね。それならロールバックは一瞬なので、ここが急激に劣化することは考えづらく、チームの練度がどこまで下がるか次第かなと思います。

なので、ツラみが溜まってきたとき、Four Keysでは変更のリードタイムや変更の障害率には表れてくるだろうなと考えられます。ただ、ツラみを検知するだけではなく、「ここまでいったら対応しなければいけない」という基準が欲しいじゃないですか。

そこで、ここからSLOの話をします。SLO（Service Level Objective）、サービスレベル目標ですね。サービスにおいて目標値とされる、適切な信頼性のレベルを表すものです。

大仲：信頼性は100%を目指すとものすごくコストがかかるので、適切なレベルを見極める必要があります。可用性99.9%だとしたら、1ヶ月に43分の停止が許容されます。43分というのは、30日に対しての0.1％ですね。ですが、これが99.99%になると、月に4分しか落とせない。99.999％になると、月に26秒しか落とせません。このように信頼性を上げていくとコストがかかるので、適切なレベルを見極めましょうというのが、SLOの考え方です。

SLOと開発生産性の指標には関係があって、まず開発生産性の指標から見ていきます。デプロイ頻度と変更失敗率と平均修復時間、これらを掛け合わせると障害の予想時間が算出できます。

例えば、毎日デプロイしていると、営業日換算で30日に20回デプロイしますよね。変更失敗率が今5%だとしましょう。すると、20回に1回失敗するチームであると言えます。平均修復時間が30分なら、1回の障害に対して平均で30分障害になる。これを全部掛け合わせると、30日に対して30分程度障害になる、そういうチームのパフォーマンスであるということがわかります。

大仲：次にSLO側ですね。先ほど可用性99.9%だったら、1ヶ月に43分のダウンタイムが許容されるという話をしました。この43分のなかには、変更が起因の障害とそうでない障害が混ざっています。

新しいコードベースをリリースするとき（Binary Push）や、設定値を変えるとき（Configuration Push）は変更が起因の障害ですが、例えばAWSが落ちたりGoogle Cloudが落ちたりしたときは、僕らの変更が起因ではありませんが、ユーザーから見ると障害ですよね。

なので、障害全体のうち変更起因の障害の割合を、43分から掛け算することになります。障害全体の60%が変更起因の障害とすると、43分×0.6で26分程度。これが変更起因で障害になる許容時間になります。

ここで2つが比較可能になります。今のチームのパフォーマンスを開発生産性の指標から見ていくと、障害予想時間は1ヶ月に30分。一方で、SLOから見ていくと、障害許容時間は1ヶ月に26分。ということは、許容される時間よりも予想される時間が多いので、このチームのパフォーマンスだとSLOに違反する可能性があると言えます。

SLOを決めるときは、ユーザー行動とビジネスの価値から決めていきます。これ以上落ちると売り上げに影響するから死守したいというラインがSLOになるので、そのSLOのパーセンテージからエラーバジェットが算出できます。ツラみが積み重なった結果として、変更障害率やサービス復旧時間に影響が出てくることが考えられるので、SLOからそれが許容できなくなるラインを決められるのではないでしょうか。

大仲：続いては、リードタイムに関してです。変更リードタイムが劣化するということは、チームのベロシティが劣化しているということです。ベロシティが劣化するというのは、同じ難しさだったら同じ見積もり、つまり同じベロシティになっているはずなのに、見積もりが外れているということです。なので、見積もりの予実を見ていれば、変更リードタイムが徐々に悪化していることが検知できるのではないかと思います。

こちらは、DMM.comの石垣 雅人さんのスライドから持ってきたものです。横軸がフェーズで、企画からリリースするまで。縦軸がその工数の予測です。最初の企画の段階で、一般的にこれくらいの時間でリリースできるだろうという超概算の予測がありました。それに対してPRDやデザインドックを書いていくと、より詳細になります。ここで始めの見積もりから少しズレて増えているんですね。

そして、書いたデザインドックをバックログアイテムに分解します。それをリリースまで開発していくと、結果として倍くらいかかったと。このように、最初は1人月くらいかなと思ったものが10人月くらいになるというのは、時々あることかなと思います。 「技術負債による事業の失敗はなぜ起こるのか」

大仲：この見積もり精度のズレを見ていきます。一般的にこれくらいだろうという予測から、デザインドックを書いてみて大きくズレているとき、自分の感覚と現行システムがズレている。つまり、何か複雑なことが起きているとわかります。

次に、デザインドックをバックログアイテムに分解するところは、タスク分解の技術なので、それほどズレることはないと思います。ここでズレるとしたら、デザインドックが間違っている可能性があります。

最後のバックログアイテムに分解したものを積み上げてリリースしたときとの差ですが、これは現場で実際に開発してみたら、思っていた設計ではたどり着けなかったとか、そもそも作るべきもの、ゴールの方がズレていくとか、そういうことがよくあるのではないかと思います。

この最後の部分にはいろいろな要因が混在していること、そしてデザインドックをバックログアイテムに分解するところでは、あまりズレはないと考えられること。これらを踏まえると、一般的にこれくらいだろうという予測から、PRDやデザインドックを書いたときに「思っていたより複雑だな」と感じる、ここのズレが劣化したコードベースの難しさを表す指標になるのではないかと思われます。

というわけで、アウトプット量を減らす力をSLOや見積もり、事業計画の方から見ていきました。SLOも事業計画も、事業責任者の関心事なんですよね。Four Keysというのは、ただの開発生産性の指標ではなく、事業責任者の関心事に沿った形で、僕らの開発生産性がどうなったかを示すことができる値です。

これをもって、「今は溜まった負債を何とか解消しなければいけない。前にばかり向かっているわけにはいかないんですよ」と説明することができます。なので、僕らはFour Keysを武器にしながら、SLOや見積もり、事業計画に結びつけて、事業責任者の関心事に沿った形で計画を提示できるといいのではないかと思います。

大仲：これは僕の持論ですが「作業8割、仕事2割」とよく言っています。“作業“は今日の飯の種を得るための業務で、“仕事”は未来のお金をつくるための業務と位置づけています。未来のお金はだいたい時間に換算できると思っていて、自動化して機械にやらせたり、精査しなくても一目でわかるようにしたり、誰にでも判断できるようにしたりといった、今の仕事をもっと上手くやれるようにするための時間の使い方を指しています。

未来のお金をつくるための“仕事”が1割を切ると、全然生活が良くなっていかず、ずっと同じことをやり続けている感覚でしんどくなります。逆に3割を超えると、なんだかひたすら改善しているなという印象になるので、15～20%をアウトプットを阻害する力との戦いに使っていくと、バランスがいいのではないかと思っています。

お互いの“得意を知る”コミュニケーションと個人技

大仲：アウトプットの評価の話をしてきましたが、アウトプットを作るチームの話もしていきます。「グループからチームへ」というのが、よく言われることですね。グループは、ただ人が集まっているだけの集団。チームは、相互にコミュニケーションしながら、個々の能力の合計よりも高い効果を得る、相乗効果を生むものだと、『組織行動のマネジメント』という本に書かれています。

グループは個人の目標に紐づいていて、チームは共通の目標に紐づいているという違いがあるので、共通の目標を持てるように、インセプションデッキを書いたり、ゴールをみんなで共有したり、キックオフをしたりします。成功または失敗が、個人に紐づいているのかチームに紐づいているのかという違いもあります。

大仲：ここで「毛づくろい」が大事になるんですね。サルや猫がお互いに毛づくろいをする行為は社会的グルーミングといって、集団の絆を維持するための社交であるとわかっています。面白いことに、動物は集団のサイズが大きくなると、毛づくろいの時間が増えるんです。コミュニケーションに時間を取らなければいけないことがわかっているんですね。

サルにおける毛づくろいでは、する側は相手のノミ取りに自分の時間を使っている、される側は触られることが不快じゃないよというメッセージになっているんですね。このお互いのメッセージングを通して、信頼の土台を築いていくわけです。

人間における毛づくろいとは、雑談ではないかと思っています。関係性を構築していく行為ですね。関係性を構築していくためには、「得意を知る」ことが大事だと私は思っています。

これは僕のすごく好きな話なんですけど、大阪の小学校で先生が「起立、礼、着陸！」と言ったら、クラスの3分の1が笑いながら座って、3分の1が「なんでやねん！」とツッコみ、3分の1が飛行機のポーズで座ったと。これが大阪か～という感じですが、すごく良いなと思ったのはボケ、ツッコミ、客の役割が分かれていることです。

大仲：「こういう発言をしたら、この人はこう拾ってくれるだろう」という安心感がある、これはすごくハイコンテキストな相手の想像がつく状態です。心理的安全性にもそのままつながっていると思っていて、お互いが相手の得意に合わせて、行動を想定しながら動くことができるようになる。これがチームなのではないかと思っています。

これはいろいろなアクションに表れるもので、例えば仕様を伝えるときに具体で伝えるのか、抽象で伝えるのか。マイクロマネジメントがいいのか、放任してほしいのか。その場で瞬発的に考えて話すのか、じっくり考えてから話すタイプなのか。あとは、出社したいかリモートがいいか、といった話にもつながると思います。

こういうことを知っていくには、やはり時間がかかるので、雑談をくり返していくことでしか達成できない。阿吽の呼吸のチームをつくるには時間がかかります。

『チームトポロジー』の一節に、「ハイパフォーマンスなチームを解散するのは、単なる破壊行為では済まない。企業レベルのサイコパスと呼ぶべきものだ」という強い言葉があるんですが、これかなり好きなんですよね。ハイパフォーマンスなチームをつくり上げたら、それを維持しながらやっていきたいものです。

あとは、マネージャー目線で普段、得意を組み合わせる座組を考えています。ちょうどドラクエ3が発売されましたが、全員戦士だと勝てないじゃないですか。回復がいないと困りますよね。なので、役割を網羅できるように考えるわけなんですが、サービス開発にはプロダクトマネージャー、プロジェクトマネージャー、テックリードなどといった役割が必要です。

大仲：他の切り口として私がよく考えるのは、問題発見、課題化、遂行です。これは問題を見つけられる人、タスクに落とし込める人、タスクを遂行する人、それぞれがそろっているかということですね。考える人ばかり集めても、忙しくて手を動かす時間が取れなかったら、問題が見つかるだけで何ひとつ解決していきません。なので、問題と遂行との間で解決すべきことを課題にできる人や、それをちゃんと遂行する人がいるかを考えます。

他にあるロールとしては、専門家やジェネラリスト。専門家は、深く掘らないと解決できない問題を解決まで持っていける人です。ジェネラリストは、複数の領域が必要な問題において人と人をつなげたり、両方の仕事をやって解決まで持っていけたりする人。例えば、スマホアプリを作っているときに、APIとアプリ両方とも触れるとか。これは強いですよね。人と人のコミュニケーションはコストがかかるので、その間をつなげられる人は大事です。

その他に必要なのは、ハードな状況でもポジティブなムードに持っていける、ムードメーカー。何か提案すると「面白そう」と言ってくれて、チームが盛り上がる。そういう人がいないと、チームがどんどん硬くなっていってしまうので、座組にデフォルトで考えられているといいなと思っています。あとは、気が利く人。漏れているものを拾ってくれたり、人ごとにムラがある状態を直そうとしてくれたり、そういう人も必要だと感じます。

体制づくりで気をつけることとして、これは私の好きなところてんさんのポストですが、この図がすごくいいんですよね。どう役割分担するかという建前のもとで始めたとき、若い組織は役割を超えた仕事の仕方をする。一方で、年老いた組織、成熟した組織になると、役割のちょっと内側をやるので微妙に遠慮のかたまりの穴が生まれてしまう。これは『技術の創造と設計』という本に書かれている図です。

大仲：これはハフィントンポストのエントリーにあったものですが、ドイツ人の仕事と日本人の仕事で、ドイツ人はよくはみ出すけど塗り切って終わる。強い塗り残しもあったりするけど、とりあえず全部終わる。日本人ははみ出さないように丁寧に塗るんだけど、終わらないと言われていました。

ここにすごく示唆があると感じていて、個人技が必要という話なんだろうと思っています。個人技が足りないと手を伸ばす余力を持てず、自分の仕事で手一杯になって、小さく縮こまってしまう。そうすると、個人技に期待ができないので、そもそも役割分担を座組として設計しようにも、領域を重複するような座組をつくれなくて、穴だらけのまま走り始めるしかない状況になります。

大仲：これは『人月の神話』を模して、小野マトペさんが言った面白い比喩ですね。「猫踏んじゃったしか弾けない人間を500人集めても、ショパンの曲は演奏できない」と。能力というものは、やっぱり存在するんだなということがわかります。

大仲：縛りプレイをしていると、低レベルクリアはすごく戦い方が限られていて、バラモスより素早くベホイミを撃てなければ詰むから、素早さが高い回復役を絶対に1人入れなければならないとか、そういうことになってしまうんですね。なので、今の戦力で限られた戦い方を探すよりも、それぞれの個人技を鍛えて、どんな戦い方でもだいたい勝てるようにした方が楽になることが多いと思います。

ということで、まとめです。アウトプットとアウトカムの話をしました。開発チームとしては、アウトカムももちろん大事なのですが、まずはアウトプットで80点を目指すべきだと思っています。

次に、アウトプットを阻害する力について話しました。これは負債を見える化すること、SLOを決めて対応を判断していくことで、アウトプットを阻害する力と戦っていきましょう。

最後に、強いチームは生産性が高いということを見てきました。強いチームをつくっていくには、コミュニケーションと体制設計と個人技が必要だと思っています。以上です、ありがとうございました。