生産性可視化プロジェクトをこれから始める人への贈る言葉
パキシーノ株式会社という会社をやっている@masudakと申します。
この記事は、開発生産性 Advent Calendar 2022の11日目の記事です。
10日目の記事は@isanasan_さんの「開発生産性は企業にとって競争力そのものであるという話」でした。本当に同意で、開発生産性は企業の競争力を高める大きな要因になると考えます。
開発生産性専門のチームを組成している上記のランサーズさん・カカクコムさんや、Findy Team+というサービスを作り自社でも色々トライされているFindyさん始め、開発生産性を重要視し、組織として取り組む例が非常に増えております。
本記事を執筆するにあたりどういう内容にしようかと考えたのですが、開発生産性可視化プロジェクト立ち上げを人生で2回（一回目はメルカリ、二回目はソウゾウで）やっておりまして、
得られた知見を話すことで、これからプロジェクトを立ち上げる人にためになるのではないかと思うに至りました。
本記事では、生産性可視化プロジェクトの立ち上げについて、注意すべきポイントやオススメのポイントをみなさまに共有して参りたいと思います。
結論から申し上げると、以下の3点に集約されます。
①最初の指標は多くて2つ。できれば1つで十分
② 5W1Hを押さえろ
③ 定性・定量どちらでも戦えるように
それでは、一つ一つ取り上げていきます。
① 最初の指標は多くて2つ。できれば1つで十分
まず真っ先に考えていただいたいのは、指標は少なければ少ないほど良いということです。
生産性可視化プロジェクトが発足し、少しでも多くのデータを取得し、完璧にPDCA回そうと意気込む方もいるかもしれません。しかしながら、人間はそこまで多くのデータを取り扱うことができません。
まずシンプルに1つ、多くても2つの指標だけを取り上げ、すぐPDCAを回すようにしましょう。
過去の経験を振り返ると、色々取得するため開発したものの、そのデータは使われることなく、誰も見ないダッシュボードと化したことがありました。
みなさまのプロジェクトでも、生産性の可視化とともに、売上みたいとか、人員数みたいとか色々出てくるかもしれません。
そういう流れになったら「必要になったら入れます！」「実装難易度高くすぐできなさそうなので、あとで入れます！」と強い口調で阻止しましょう。
ソウゾウさんでプロジェクトを始めたときも、デプロイ頻度とリードタイムだけで行いました。一週間でダッシュボードを開発し、まずPDCAを行えるようにしました。
自分がこれから関わるプロジェクトで大量の指標を扱おうとしていないか、気をつけましょうというのが1つ目のポイントになります。
指標についてはhikaruさんの記事が分かりやすく素晴らしいので、ぜひ読んでみて下さい。
② 5W1Hを押さえろ
扱うべき指標を決めた、であればあとはうまくいくだろうと思うものの、現実はそう甘くありません。
指標はあくまでツールであって、そのツールを適切に扱う場・人が必要になります。
ということで、その指標を用いる5W1Hを押さえることが重要です。
なぜ（Why）
ex: リリースがスムーズにいっておらず、早急に取り組む必要がある、世界トップレベルの開発組織を作るため等
いつ（WHEN）、どの会議体（WHERE）で
ex: 毎週水曜10時の経営会議、EM会議等
誰が（WHO）
ex: 会議に出席している本プロジェクトの責任者、テックリード等
何を（WHAT）、どのように（HOW）
ex: デプロイ頻度の傾向と分析結果、対応策を議題にあげる
①で指標を最低限にと書きましたが、指標が多いとWHATのところが100%まとまりません。他の議題もあるなかで、指標が多いと、おそらく対応策は上げられず、ただ数字を読み上げて終わりなんてこともありえそうです。
なので、5W1Hの設計をしましょう。
ということで、2つ目のポイントは、5W1Hを押さえろ、でした。
また、普段はEM会議等で取り扱っていたとしても、月に一度は経営会議でもアジェンダとして上げられると良いです。
ビル・ゲイツは会議で、プロジェクトがどれほど同時進行できるかを気にしていたようですが、デリバリーの状況についても経営が留意していると、より強い組織になると考えています。
※そうではなくても伸びている企業はありますし、売上や各種重要課題など喫緊の問題があるなかで取り上げるのは非常に難しいと思いますが、そういうのが当たり前になってほしいという願いも込めて
定性・定量どちらでも戦えるように
指標が決まり、会議でも取り上げ、PDCA回す流れができてきた、そこまでできればPDCA回っていく可能性は高いですが、それでもハマるポイントはあります。
ソウゾウさんで支援した際に実際あったのですが、非常に生産性が高く、定量的に取り組んでも課題感が少ないというものでした。
毎日複数回デプロイし、リードタイムも1日以内のものも多いという組織ですと、定量的に可視化するだけでは、課題を共有できず、プロジェクトが前進しにくくなります。
そういう場合は定性的な取り組みも行いましょう。
エンジニアやPMに個別にインタビューしたり、アンケートを取ったり。定量的には課題が少なくても、定性的には問題山積みということもあります。
開発ローカル環境が整っていない、レビューが一人に集中している、ソースコードがかなりカオスになってる、前任者がいなくなりドメイン知識を持ってる人がいない、といった課題はあるかもしれません。
アンケートの質問等、上記の記事にも書いてありますので良かったら読んでみて下さい。
ので、3つ目のポイントは、定性・定量どちらでも扱えるようにという話でした。
終わりに
ふとした流れで、生産性可視化プロジェクトの立ち上げを2回やるという経験に恵まれました。
最初始めたときは何も分からず、色々遠回りしてしまったと感じています。
自分みたいにならないよう、少しでも知見を共有できたらと思い書いてみました。少しでも参考になれば幸いです。
明日12日の記事はegchhstさんの「ココナラにおける取り組み」になります。
記事を読んでいただき、ありがとうございました！
よろしければサポートお願いします！ いただいたサポートはクリエイターとしての活動費に使わせていただきます！