【アレスグッド アドベントカレンダー Day2】開発生産性と向き合う＆どう他チームに共有するか
🎄このエントリーはアレスグッドの Advent Calendar 2023 という企画の2日目の記事です。
はじめに
私、あろです
夏から筋トレにハマって、今増量期のアローです。
+15kgほど増えて、年末に向けて増量の拍車をかけています。
68kgから90kgに増やしている過渡期です。
自分は株式会社アレスグッド(以下、AG社)のco-founder/VPoEで、「エシカル就活」のリリースから2年半開発に携わってきました。
今は開発しつつ、組織についてより考える時間が増えたように思います。
前職は他スタートアップ取締役CTO、アイデアベースの立ち上げ期のスタートアップのco-founder/ファーストエンジニアを何社かやっていて、フルスクラッチでフロント、バック、インフラ周り全てほぼ1人でこなす脳筋web developerでした。「開発すること」がどうしても先んじていた結果、なかなか組織形成やマネジメントに介入することができず、作っては壊しての苦しい時期でした。
今年の春からAG社にフルコミットに転換し、0→1ではない、次のステージを見たいと思っています。そのためには開発はもちろんのこと、組織、採用、マネジメント、経営・事業戦略までより密接に絡んでいく必要があります。
AIによるシンギュラリティが進む中で、「開発するということと、その生産性の躍進のために何が必要か、何がKGIになるか」を考えることが重要だと考えました。
去年の執筆について
去年もアドベントカレンダーを執筆したのですが（当時は業務委託）
今見ると「書いている内容すっごいうっすいな」って思いましたw
成長したということ、と思いたいです。
前置き
さて、今回の『開発生産性と向き合う＆どう他チームに共有するか』について話を移ろうと思います。
自分がこの議題について触れたかったのは、直近10~11月で特に考えていた内容であって「最新のトピックである」こと、また「他の組織でも起きていそうなありがちな課題」に思えたからです。
対象者
自分が思う対象者は以下です。
開発組織の変遷、チームとして目指すものを明確にしたい
開発のチームの人ではないからこそ、開発のチームの生産性をしっかり理解したい
部門部署関わらず「生産性どうなん」って聞きがち
生産性という言葉の事業上の意味・インパクトを抑えたい
我々が置かれている現況
今の開発組織はフルタイムのみで、
デザイナー兼PdM: 1人
フロントエンド: 2人
バックエンド、インフラ、（たまにフロントエンド）: 自分
ここに業務委託で参画いただいている、デザイナー、PdM、QA、バックエンド、AI関連のエンジニアが加わる形になります（前年より凝縮して少数精鋭に）
SMはチームメンバーに依頼をして、SRE、情シス、セキュ管の部分は自分で回してます（ここも切り分けたいところです）
その中での課題は
今のフェーズはそれぞれの役割はもちろん、どれだけ個人が「サービス価値の実現」に注力できるか、発送してその機能開発に焦点を当てられるか
開発のフローは整ったにしても、QAチェックでエラーが発覚するような開発チェック上の甘さが出る
技術状態から機能開発ごとの縦割りでの開発が難しく、明確に役割を分けた中での開発が多いため連携ミスなどが起こりがち
またAGにとって重要な指標は
「ビジョンや価値観の軸がある学生」と「他の就活サービスでは獲得できない優秀な学生を求める企業」をマッチングさせて、サクセスを生む
開発生産性への課題感を持った理由
上の前提から、自分が開発生産性について考えることになった理由は以下で、
【プラスとして伸ばす思考性】3ヶ月前、半年前、1年前の開発組織よりも「開発する」という行為は成長できているのか気になる
【マイナスを抑える思考性】今後人数が大きくなるにつれて、2:6:2のような「やる人はやるけど、やらない人はやらない、サボる」の構図が顕著に出そう
これが結果的に「生産性」を考えることになった起源です。
そんな中で、メンターしていただいている方からこんな資料を頂きました。
自分的にはこのスライドは最高に理論的かつ合理的で、納得感が脳天突き抜けるくらいやばかったです。おすすめです。理系なら尚更おすすめです。数学的なアプローチでワクワクすると思います。
本題＜開発生産性について＞
まず生産性とは
皆さんの思う「生産性」ってなんでしょう？
「時間あたりに書いたコード」のこと？「イテレーションあたりで捌けたタスクチケット、ストーリーポイント」のこと？
「生産性を考える」、特に同感してもらえるシチュエーションは
Biz側の人と話すとき
代表と話すとき
だと思います。
相手『おつかれい、最近のプロダクト開発どう？』
あなた『まずまずっすね！ユーザヒアリングで定性的な視点を得て、プロダクトに落とし込むような機能開発を進められてます。』
相手『チームとしてはどうなの？開発のメンバー増えてきたけどサボってる人とかいない？生産性上がってるの？』
あなた『』
このときどんな説明をしますか？また生産性の定義ってなんでしょう？
生産性の定義
上記のスライドの言葉を借りると、
生産性 = Output(獲得資源) / Input(投入資源)
です。
これはスッと理解できると思います。
経営的に構造化し直すと、以下になります。
ただし我々開発組織がやっているのは、工場や製品を作るような「物的製品」でもなく、コンサルのような「付加価値の提供」でもないです。
工場生産との違いは、「同じものを作るか」で、ソフトウェアは本質的には同じものを2度作ることはないです。今と未来で生産性に関して純粋な評価ができなくなります。
作っているものが『ソフトウェア』となったときに、生産性をどう定義するのか。
通例、スクラム開発をしていることが多いので、1イテレーションあたりの生産性を測るとしたとき、上記のような「完了したストーリーポイント、FP、機能価値」「PR数、コード行数」「売上」などから図ろうとしますが、いまいちピンときません。
これだと直感的ではないし、特に事業成長につながっている気がしません。
単に開発者のパフォーマンスを仕事量で測るには不足はないかもしれませんが、多分Bizサイドには納得しれもらえないでしょう。
その理由は以下の3つ
「完了したストーリーポイント、FP」には曖昧さが残る
「PR数、コード行数」はエンジニアの最低限のワーク（サボってないか）
「売上」は開発の段階、リリースした段階から見ると時間的ラグが大きすぎて、正常なモニタリングが難しい
仕事量以外の指標を見出す
どうしても「開発することだけ」にフォーカスすると、PR数だったり、だったり本質的でない定量数値に目が行きます。
ここで再度少し引用します。
なぜプロダクトチームは開発をするのでしょうか。
元来「システムを作る」ことは、どの時代の人間でもやってきたことで、人間の行動の一つである歩行もシステムの一部といえます。
歩行の目的は「移動すること」であって、地球上陸続きの部分であればどこへでも「アクセスすること」は可能です。
つまり、「なんのために作っているのか」を問われています。
『なんか良さそうだから作った』は通用しません。
作ることの意味と目的の理解が必要です。
なぜ作るのか、それは「顧客のニーズを満たすため」です。
となったときに開発チームは
「顧客に対して価値を届けるシステムを作る」が任務であり、達成しなければならない至上命題です。
顧客やユーザの価値を考えた機能を考案して作れているでしょうか？
自己満の機能をリリースして安堵してませんか？
付加価値の生産性
仕事量を評価してもプロダクトが本質的によくなるわけがない。
そう、我々が目指したいものはコレです、「付加価値」。
その中でも期待付加価値と実現付加価値があります。
実現付加価値は「価値の実現」、すなわち顧客からの声や売上に転化するもので、これを開発組織で追うのはスコープが広すぎます。
ということから、期待付加価値にフォーカスを置きました。
では、開発することだけで価値を提供し切れるでしょうか。
価値とは結局何か
提供した価値から得られるもの、それは売上です。
事業における最重要指標からの逆算からもわかるものですが、Bizサイドと違って開発によるアプローチの売上への実績表面化はものすごく遅いです。
これは感覚的に理解できると思うのですが、
作ってすぐに売上が上がるわけではなく、上記のような段階を追う必要があります。
それを数学的なアプローチで示したものです。
開発に関する事象はまさに「遅行指標」で、顧客価値を決定づけるもの「ビジネス生産力」にあたります。
イノベーションの生産性に必要な要素は当然「開発すること」ですよね。
これが「直感的な開発チームにおける売上貢献度」がわからなくなるカラクリです。
開発時の時間的指標は2つある
ここで、スループットとリードタイムについて触れます。
スループットとは単位時間あたりに捌けたタスクの量のことで、一般に工場作業などで言われる生産性の指標。
対してリードタイムは1タスクが開始からリリースまでにかかった時間のことを言う。
個人的にはどれだけスループットを最大化しきれてPRを作っておいておいても、PRチェック、QAチェックが行われない限りリリースはされないわけで、顧客に価値は提供できません。
特に我々のチームではよく起こります。
開発は終わっているのに、チェック体制までに時間がかかり、開発は3時間でできたのに、リリースが3日後になったり。めちゃくちゃ勿体無い。
結局、開発生産性とはなんだったのか
「不確実性のある環境への曝露によって、不確実性が削減されたとき」
すなわち、市場への曝露をどれだけできるか。
もっと簡素化すると、「どれだけ顧客に当てられるか」
結局、「どれだけの回数仮説を顧客に当てこんで、確認作業ができたのか」を問われている。それは仮設段階での期待付加価値を実現付加価値をすることに直結するからです。
結果的に顧客に当てて試す、ユーザヒアリングをするなどのサイクルを回そうと思うとネックになるのが、フロー効率。
CI/CDによって自動化と効率化が果たされているかなどが焦点になります。
最終的に必要な要素は
【思想と目標】期待付加価値の生産性、「期待できる価値」について考えられているか
【行動】スループット最大化できているか（ここにAIを適用することで加速できる）
【行動】リードタイム圧縮できているか
【サイクル】「期待できる価値」にアクセスするような仮説とそのタスクをスループット最大化＆リードタイム圧縮によって開発し、顧客からフィードバックを受け、別の仮説に昇華させられるか
【行動】サイクル最適化のために自動化、効率化を図れたか
そのサイクルによって得られるものが、真のプロダクトにおける価値であり、開発生産性となるでしょう。
本題＜他チームへの共有＞
では、明確になった開発生産性の文脈を週次でどう他チームに伝えるか。
前提
AG社では週次で「ビジネスモニタリング会議」なるものを持っています。
通称「ビスモニ」で、前1週間での各チーム（Sales, CS, User, Productから組成）の
数値的な共有＜定量＞
売上、社数、社単
ユーザ登録数
チャーン率
事業を進めていく上で発見できたこと＜定性＞
を1時間で共有していきます。詰まるところ、各チームの持ち時間は共有と議論の時間を合わせて15分です。
ここで疑問に思ったことは
『プロダクトチームがこの場で他チームに共有しないといけない内容は何か』
です。
改善前にProductチームで持っている指標は以下で
LPのCTR
MAU/DAU
開発予定のチケットリスト
リリースした機能リスト
どれも「限られた15分の時間で、他チームが知りたい内容」にダイレクトに当てはまる気がしませんでした。
開発生産性をどう他チームに伝えるか
まずは定量的な数値による改善の明確化です。
特にユーザ側の登録に関してはファネルを利用して、各チェックポイントでのCVRを算出しています。
仮設段階でも現状と理想状態のGAPを明確にし、それを埋めるためにどの施策を動かしていて、最終的にリリース後どのように変化をもたらしたのか、を引きつづき共有していきます。
もう一点大事な指標は、開発におけるfix/feat率です。
開発チームにおけるタスクにはbugを修正するfixと機能開発をするfeatureがあります。
我々が上記で言う開発生産性を最大化させるには、顧客への仮説検証の速さが重要なわけですが、その弊害の1つにbugがあります。
bugの修正をしている間、機能開発はできません。
週あたり40-50時間の活動の中で、bugに10時間使ったら機能開発は40時間しか使えず、もろに開発生産性を下げます。
bugを0にすることは目標ですが、「bugへの対応総時間そのものを減らす」ためにできることがいくつかあります。
【逓減・削減】リファクタ、綿密な設計、手厚いコードレビュー、シンプルなロジック
【高速化】Sentryでのエラー監視強化、即時対応への動線
これらの打ち手の表明と、実際のbug対応にかかる時間、またその半減期までにどれだけ時間と施策を打たないといけないのか、が共有の上でより分かりやすい指標となると思います。
最後に
ちょうどTimeeさんのアドベントカレンダーを拝見したのですが、Sentryでのエラー検知について述べられていて、この点は弊社も同様な辛口採点をされる状況に思いました。鋭意改善する方針です。
なおTimeeさんはエシカル就活掲載企業様でもあり、エシカル就活からTimee本サマーインターンシップに参加しMVP受賞を飾った学生柳田くんなど、関わりがあります。
アレスグッドではフルタイム、業務委託、副業、インターンなど問わず全ポジションで仲間を募集しています！
ご興味のある方は是非下記よりご覧ください。