Four Keysが改善しても、生産性が上がらない不都合な真実　〜指標を変えて挑んだ改善の道のり〜

はいそれではよろしくお願いします
はい初めましてリンク&モチベーションの伊藤遥と申します
本日は4Keysが改善しても生産性が上がらない不都合な真実というタイトルで発表させていただきます
よろしくお願いします
簡単に自己紹介させてください伊藤遥と申します
この写真は去年モンサンミッシェル行った時でしたね
夕日に照らされてモンサンミッシェル一本道続いていて本当綺麗で感動したんですが
プラットフォームエンジニアリングもそれくらい分かりやすい一本道が連なっているといいなと思いました
はい簡単に企業紹介もさせてくださいリンク&モチベーションと申します
経営と現場をつなぐオールインワンのサービスとしてモチベーションクラウドを提供しております
現在これくらいの1万2000社500万人という風な国内最大級の組織診断改善の実績とデータを持っております
その結果をもとに組織の改善に向けたアクションを回すためのサービスを広げていっております
はい
それではですね本日のこのセッションの中で私がお伝えしたいことは
顧客価値に近い指標をゴールにおいて改善をしていこうということです
ちょっとこのままじゃわからないとは思うんですが
本日はですね弊社における生産性向上の取り組みの歴史
その中でぶつかった壁や打ち手そして学びというところをお話しできたらなと思います
生産性の定義であったりはこういろんなところで既にお話しされていると思うので
今日はお話ししないというところと
いろんな改善の取り組み出てくるんですが
全部は拾えないので
ぜひ本日ブースが地下のエスカレーター下って
左にこの真っ赤のTシャツ着た人と真っ赤の旗があるので
ぜひブースで意見交換させてください
はいでは本題に入っていけたらなと思うんですが
そもそもプラットフォームエンジニアリングってっていうのを
チャットGPTとかに聞いてみたんですが
開発者体験と生産性の向上を通じて
そこにプラットフォームを提供してっていうところが入ると思うんですが
顧客価値の創出を加速させることっていう風に言うんですけど
もちろん意味は分かるんですけど
分からんなと
こんな悩みありませんかというところですとね
何から着手したらいいんだろうか
いろんなプラクティスであったり事例っていうのが
もう最近はいっぱい共有されているかなと思いますし
それをプラットフォームエンジニアリングのチームだけでは
進められないというところで
関係者とどういう風に進めていったらいいのか
そしてむやみやたらに進めてもしょうがないかなと思うので
どんな指標を置けばいいのか
特にそれやる意味あるのっていう風なのを
もちろん経総とかからはしっかり聞かれると思うので
そこに対する説明っていうのをしていくのがやっぱり難しいなと思います
なのでですね
弊社がここまでの取り組みの中で
いろんな悩みだったり
壁に直面しながら
乗り越えていったその過程っていうのを
今日はお話できたらなと思います
ざっくり2020年くらいからですね
現在に至るまで
3つのフェーズに分けて
取り組みをお伝えできたらなと思います
まず
第1弾はですね
土台作り機ということで
当時の私たちのミッションとしては
外部指標を取り入れて
アプリチームと一緒に改善しようというのが
ミッションでした
2020年ですね
CTOにですね
ごめんなさい
実際はハゲてもないですし
ヒゲも生えてないので
ごめんなさい
うちって開発生産性高いの?
っていうのをポーンと聞くわけですね
経営としては当たり前
当然気になるところかなと思います
当時はなんかいろんなアンケートであって
指標みたいなのをチラホラ見たりはしてたんですが
ちゃんと測ったこともないですし
どうしたらいいかわからんなと
というところでですね
多くの企業が導入していたりとか
生産性の相関というのも
しっかり研究されていた
ドーラのフォーキーズ
皆さんご存知の方多いかなと思うので
説明はちょっと端折っちゃいますが
こちらを測ることにしました
計測した結果ですね
結果ローでした
もう分かりやすく
開発生産性低いぞと
定量的に自分たちの今の現在地っていうのを
認識することができました
分かりやすくていいですよね
本当に測りやすいですし
数字でローだと
突きつけられました
なんでですね
まずはこれを上げていって
最終的には
はいっていうところを
はいの基準まで上げるっていうのを
目標に改善活動を進めていきました
一番最初はですね
Pチーム中心に
インフラの仕組みを改善していきました
当時は
デプロイも手動で
2時間とかかかっていたところから
自動化したりだとか
コンテナ化したり
IACも取り入れたりとか
こういうインフラ中心の改善っていうのは
進めていけました
ただ一方ですね
アプリ領域
4Keysいろいろバランス取れてていいなと思うのは
インフラだけじゃなくて
ちゃんとアプリ側の改善っていうのも
していかないと
基準が上がらないと
リードタイムだったり
バグの混入
こういうのはアプリメンバーの協力が必要だったんですが
まだまだやれていませんでした
なんでですね
ハイの基準には全然到達できなかった
というところで
アプリチームに働きかけていきました
いやリリースちょっとでかいんじゃない
少ないんじゃない
もっと分割して出そうよとか
フルリクエストは貯めたら
それは忘れるよね
貯めないようにしようよみたいな
言うんですけど
自分ももともとアプリケーションの方
やっていたのも
分かるんですけど
余裕なかったり
自分の仕事忙しかったり
そもそも課題に感じてないっていうこともありました
なのでですね
分かりやすく
関わり方っていうのを変えました
何のための4keysであるかっていう
その目的であったり
そのなぜっていうところを
しっかり伝えるところから
分かりやすく
同席する会議体っていうのを
しっかり作り
横断チームっていうのを
ちゃんと組成してですね
もう毎週
金曜の夕方とかに集まって
今週出てきた障害はどうだったか
リリースどうだったか
みたいなのをしっかり確認する
そういう会議体っていうのも
設計して進めていきました
これによってですね
アプリからインフラ
幅広く当時抱えていた技術課題っていうのを
解決できたかなと思います
ここに挙げたのだけでも
いろいろあるんですが
本当にチームの中に入ったり
一緒にやりながら
改善っていうのをしていきました
こう改善を積み重ねていった結果ですね
2020年に始めて
もう3年経ってるんですけど
2023年
2年ぐらい前ですかね
やっとこう
ハイ基準っていうところまで
達成することができました
一部はもう当時でいうところの
エリートっていう
もう一個上の基準の
基準を達成しているものもあるくらい
すごく変わったっていうところもありましたので
開発者から本当リリースが楽になったよとか
当時プルリクエスト本当に
100ファイルとかみたいなのが
ザラにあったりしたので
ちっちゃくなって
レビューが楽になったよとか
障害対応も本当に
回せる人が限られてるんで
その人の周りにみんなで集まってみたいな
こともあったところから
しっかり俗人化がなくなって
みたいなところで
こう開発者からの喜びの声っていうのも出てきました
ただ一方でですね
いろいろ距離近くなったからこそ
単にスコアが改善された割には
なんかまだ生産性上がった実感ないんだよな
という風な声も一緒に上がってくるようになってきました
例えばプロジェクトの管理がもうバラバラで
なんかうまくいったりいかなかったり
その原因がわからないとか
バックエンドがどんどんどんどん大きくなっちゃう
プロダクト増えて
デザイン統一させるの毎回大変なんだけど
こんな話がちらほら出てくるようになりました
アプリ側との共同一緒に働く
そして成功体験を作るっていうのもできていたので
より具体的な開発者のペイン解消っていうのに
取り組むことにしていきました
フェーズ2ですね
この時は開発者のペインを解消しよう
っていうのを掲げてやっておりました
距離も本当に近くなっていたので
ヒアリングして解消
もう一個一個上がってきたのに
打ち返すようなぐらいの勢いで進めていっていきました
単に進めるだけじゃなくてですね
フォーキーズとツイになるように
スペースっていう風なフレームワークもあるんですけど
それを元にして
楽しく誇らしく開発ができていますかっていうのを
定量でやったり
訂正的なコメントももらいながら
声っていうのもちゃんと収集していっていました
活動の結果としてですね
本当にいろんな大小
いろんなものあると思うんですが
いろんなペインを解消できました
アンケートの結果も徐々に良くなってですね
開発者からさらに喜びの声があふれて
本当に開発者体験すごく良くなりましたと
ここからちょっと伏線回収に入ってくるんですが
ある日ですね
剥げてないCTOから
生産性は上がったの?
リリース増えた?
めっちゃ改善してきたんで
上がっているはずですよ
見てみます
変わってねえな
あれれれ?
当時起こっていたこの不都合な真実っていうのは
4Keysは改善した後
いろんなペイン
開発者のペインを解消し
開発者体験は非常に良くなった
それはもう声とかから
結果からも分かっているんですが
顧客価値
機能リリース数っていうのは
増えていませんでした
そこで
フェーズ3ですね
顧客価値に近い指標っていうのを
ゴールにおいて改善しようというのを
掲げることになりました
改めて
当時何が起こっていたかっていうのを
振り返るとですね
ちょっとこれは極端な例なんですが
顧客価値
開発者体験あった時
いろいろ打っていた改善の活動
施策っていうのは
開発者体験の向上を
一番のゴールに置いていました
もちろんそれが繋がることもあるんですが
極端に言えばこんな状態でした
ただやっぱり
あるべきで言えば
しっかりとやっていったことの
その先に
顧客価値が繋がった状態
顧客価値の創出が
最終的なゴール
になるように
ぶれずに
本質的な改善に
力を入れていくべきだったなと
振り返って分かりました
さっきも出てきたの
改めてなんですが
プラットフォームエンジニアリングの
活動っていうのは
開発者体験と生産性の向上を通じて
顧客価値の創出を加速させる
そこに我々のミッションがあったなと
ということでですね
新たに指標として
機能リリースの総量っていうのを
追いかけるようにしました
単なるデプロイの数ではなく
機能リリースとしたところは
やっぱり
顧客に提供する
新たな価値っていうのは
何かしら機能リリースしないことには
生まれないかなと思いますし
これが
シンプルに
一番ダイレクトに
顧客の価値につながっている
指標として
良いなというところで
これを2倍にするっていうのを
目標に定め
改めて
改善をしていくことにしました
機能リリース数の増加っていうのも
一番ゴールとして
左において
それは何によって
生み出されているものなのか
それの
これをゴールとしたときの
KPIは何なのか
っていうのを
もちろんボトムアップ的な
前もあった
開発者からの課題とか
感じていること
それをもちろん
ヒアリングもしつつ
それって顧客リリースに
つながるのかっていうのを
プラットフォームエンジニアチームだけじゃなくて
現場の開発者
そしてPDMだったり
いろんなところにヒアリングしながら
目標っていうのも逆算して
じゃあここを上げたら
これくらいいけるんじゃないか
みたいなのを
試算しながら
改善っていうのを進めていきました
機能リリースっていうのを
改めて目標に置いたことでですね
これまでにはなかった
いろんな挑戦っていうのを
しなきゃいけないですし
していくことができたかなと思います
例えば
AIこう
最近ですと
いっぱい性能が上がった
みたいな話もありますが
これまではあまりうまく使えていなかったところから
次世代の開発プロセスはこれだと思って進めていったりですとか
これまでやっぱりアプリの開発者に向けての改善活動多かったんですが
改めて見てみると
開発のリードタイム全体で見たとき
要件定義すごく長くないっていうのに気づいて
PDM領域にまでにじみ出していったり
開発の集中時間
皆さんが開発しているときの時間っていう
これまではあんまり時間の使い方
俯瞰した見方での改善っていうのもやってなかったところから
そこにも手を出したり
障害対応
これまでここが塞いだよ塞いだよって声は聞くんですが
結構小粒な改善をどうしてもやって
簡単に良かったよっていう声をもらっていっちゃってた部分もあるので
ただ今は顧客リリースっていうのを一番ゴールに置いているので
しっかりROIっていうのを計算した上で
それを提示し
負債の返済っていうのをちゃんと芸人とも説得しながら進めていく
そんな活動ざっくりですが
受けました
一個一個ちょっとお話できたらなと思うんですが
AIエージェント弊社だと
Devinとかカーソルとかクロードコードとか
こういうのを使えるようにはなっているんですが
単に配るだけではなく
かつ
単に配るだけではなくですね
しっかりとどれくらい使われているかっていうのの
可視化っていうのも行っております
定義はここにある通り
プルリクエストにラベルを付けてもらって
それの数がどれくらいかっていうのを割合を見ながらですね
でそれだけじゃなくって
プラットフォームチームをハブに
いろんな
ナレッジであったりノウハウプロンプトだったりの共有っていうのも
行いながら
生成AIの比率
これはもう60%は
達したんですが
ただ
もともと置いていた実装工数
これAIに任せてるんだから下がるんじゃないって言ってたところが
下がってなくて機能リリース増えるまでには
まだ繋がってないなっていうところで
続けていってます
なのでこれもともと
機能リリースっていうのをゴールに置いていなかったら
おそらく自分たち60%達成したからやったねって言って
満足して終わっちゃってたんじゃないかなと思ってます
なのでしっかり機能リリースっていうのがゴールにあるからこそ
単に比率上げるだけじゃダメなんだな
じゃあそのために何をするっていうところから議論をちょうど今したりしているところです
2つ目にお話しするとしたらですね
先ほども話した
開発のリードタイム
いろんな定義あると思うんですけど
企画から実際にお客さんに届くまでっていうところを
いざ測ってみようとすると
当時はですね
測れないぐらい
いつから始まったかわからない
そんな状態でした
状況でした
別にこれはPDMが悪いとかそういう話ではなく
いろんな並行で持っていたりとか
管理がそもそもされていないっていう状況だったので
そこにしっかり
Pチームとして持ってる
計測して
可視化して
目標設定して
一緒に改善していく
このプラクティスをですね
PDMと一緒に
実践することで
回していくことができました
ちょっと企画からのリードタイムっていうところから
しっかりアウトプットの基準であったりとか
ゴールっていうのをこう決めながら
フェーズを分けて
で、やるものによってもちろん
その難易度に応じて
時間、必要な時間っていうのが変わってくるかなと思うので
課題の不確実性や
それを解消するための解決策の不確実性っていうのを元に
目標を設定して
これ実際どうだったのかっていうのを振り返りを
PDMと一緒に回していくことができました
で、これはやっぱり
単に
インフラ領域であったり
プラットフォームの提供っていうのに
固執して
で、開発者のペインを解消すればいいやって
考えていた当時の自分たちでは
やっぱりできなかったなと思っているので
これがやっぱり昨日リリースっていうのを
ゴールに置いたおかげかなと思います
こちらの取り組みはもう完了してですね
当時と比較すると
リードタイム本当に半減することができてですね
しっかりこのプロジェクトの改善の
サイクルっていうのも回っているところかなと思います
で、あと開発の集中時間
ちょっと開発集中時間っていうと
伝わりにくいかなと思うんですが
ざっくり言うと
月曜日朝ミーティングがあって
で、13時からミーティングがあって
で、30分で終わるんだけど
15時にまたミーティングがあって
途切れ途切れで
開発に集中できないっていうのが
結構起こっていました
なのでですね
しっかりフロー状態となって
開発に集中できる時間の定義
っていうのを定めました
弊社では2時間
空いている時間っていうのが
週にどれくらい
月に45時間ちゃんと確保できているのかっていうのをですね
カレンダーの情報をもとに計測し
目標も決める
で、これをもう部署のルールとしました
もう少し詳細にお伝えすると
月曜日と火曜日と木曜日の午後は
基本的に定例のミーティングを入れてはならないと
それはもうエンジニアだけと限らず
部署全体のルールとして決めました
そうするとですね、自然とミーティングはこう、ちょっと大変ではあるんですけど
まとまり、空いた時間がしっかりまとまった空いた時間ができるので
そこで開発が進むという風な工夫ができております
で、もうこれも完了していてですね
あの、メトリクスの監視とか通知であったりはやっているんですが
各グループであったりチームにその運用っていうのはもう
任せている状態です
で、最後にですね
あの、これまで
障害に当てている時間なんか体感すごく辛いし
多いような気がしてたんですけど
分からないっていうふうな状況でした
なのでですね、あの横断的に過去の障害っていうのを
どれくらいでしたかね
1年半、過去1年半ぐらい
ちょっとあんまり
数は大きな声では言えないんですが
とってもたくさんの量の
あの、障害の振り返り資料っていうのがあったので
それをもとにですね、もう1個1個見ながら
で、特にその障害に
復旧までにかかった
コース、そしてそれを直すために使ったコース
ちょっと書いてはいないんですけど
直すのが長期化しそうだった場合は
さらにプロジェクト立てて直さなきゃいけなくなったコース
そういうのを1個1個ちゃんと分析していきました
さらにですね、発生したパターンは何か
どんな変化によって
この障害は発生したのか
であったりとか
関わってくるようなキーワードっていうのを
この機能に関わるところだ
こんなテーブルに関わるところだ
みたいなのをちゃんとラベリングしていって
その成績も行いました
で、ここで分かったのがやっぱり
いろんな振り返り資料を見ていく中で
これやったらいいんじゃない
あれやったらいいんじゃないっていうのが
上がってるんですけど
あんまり実行されていなかった
振り返ってるんだけども
それがしっかり計画に乗るっていうところまで
いっていなかったの
これは本当にもったいないなというところで
障害がしっかり畳み終わったらですね
AIによるサマリーと一緒に
振り返りの資料のひな形も作ったり
それに合わせて管理するための対応チケット
弊社Jira使ったりしてるんですが
Jiraに作り
それをもとにして
しっかりステータスを監視していきました
これが期日までに終わってなかったら
担当者大丈夫なのっていうのを通知しながら
しっかり再発防止策っていう
この振り返りで出てきた改善が
行われてるかっていうのを
チェックしながら回していくのと
あとですね
この中で
障害がバーってあったんですけど
その中で
約3割から4割とか
かなり大部分を
一個の大きな石間が増えて増えて増えていっちゃった
テーブルのこの複雑さが原因なんじゃないのかっていうふうな
のが見えてきました
で、もちろんそれは
アプリの開発者からすると
もともと分かっていたことではあったんですが
なかなかそれを計画に乗せるっていうところまではできなかった
なぜならば
それの費用対効果をしっかり説明することができなかったから
なのでですね、ここでしっかり分析したので
そのROIっていうのを
確からしさをもとに
後回しにしていた課題っていうのにも
今、絶賛着手していっているところですね
なのでこう
単に
振り返りをして終わりというだけではなくて
それを
改善したらどんなリターンがあるか
そのROIの提示っていうのを通して
改善のプロジェクトっていうのを推進できているような
まあ、これは仕掛かりなんですけど
やっていっているところです
でも、こんなにわーっていろいろやっているのは
どうなのっていうのが気になるところだと思うんですが
実際ですね、あの2024年
これやり始めた去年と比較して
今年はしっかり
機能リリースっていうのは
1.5倍ぐらいには増加の見込みが立っているというところで
しっかり成果にまでつながっているっていうのを
確認できているところです
まとめに入りますが
やっぱり改めて
顧客価値っていうのに
それを顧客価値の提供を加速させるのが
我々のミッションかなと思うので
そこに近いダイレクトな指標っていうのを
ゴールにおいて改善することが大事だったかなと思います
でまぁちょっと
越境に欠けちゃってるところはあるんですが
そうすることで
先ほどもお話ししたような
これまでに立てれなかった目標であったりとか
ビデンまでにじんでいくような行動とか
自分の役割を超えた
そういう
越境っていうのが生まれていくんじゃないのかなと思っております
はい
発表は以上となりますが
最後にですね
先ほどもお伝えしましたが
ブース下にございます
モチベーションチップスというのを
お配りしているのと
ノベルティもプレゼントしておりますので
よろしければぜひお立ち寄りください
では発表は以上となります
ありがとうございます
拍手
はい
ありがとうございました
結構質問が来ているので
できる限り回答できれば
回答いただければと思ってます
一番上ですね
この点の指標を目標とすると
どうしても
指標をハックしてしようとする意識というか
モチベーションが働いてしまいますと
そういった問題って起きてないでしょうかと
フック風とかあればというところですね
お願いします
はい
そうですね
数字の魔法といいますか
ハートマンの法則みたいなのがあるかなと思うんですが
グッドハートの法則か
あるかなと思うんですが
そこにもやっぱり
最終的なゴールとしての
機能リリースっていうのを掲げているのが
大事かなと思っております
例えばですと
先ほどのちょっとお話ししたところでもあるかなと思うんですが
PR作成にAIどれだけ使われているかっていうのは
今はプルリクエストにラベルを付けるっていう
ちょっと人間にお任せしている部分もあったりします
なのでいくらでもハックはできるかなと思います
ただ
単に生成AIで
作ったコードの比率が60%って置いているわけではないので
先ほどもあった通り
いやでも結局プルリクエストの数そんなに増えてないよねとか
リードタイム短くなってないよね
そこら辺よくなんないと機能リリースつながらないよねっていう風な
ゴールからの逆算で他の指標で
見直すことができるかなと思うので
そういうのがやっぱり効いてくるんじゃないのかなと思います
ありがとうございます
では次の質問です
要件的なリードタイムを減らすことについて
詳細が気になりましたというところで
会社では余計的な非エンジニアとエンジニアのやりとりが多くて
コミュニケーションコストが遅くなっているという話になっています
ありがとうございます
そうですね
詳細というところでいきますと
弊社でも実際これは結構起こったりしています
なのでそこはまた別物として測るようにしているところです
先ほどの話でいくと
まずは要件定義書っていう
うちアウトプットのフォーマットがあるんですが
それが5が出るタイミングっていうのを
測っているので
そこにしっかり
弊社ではアプリのエンジニアのレビューであったり
コメントっていうのもしっかり反映させていっているので
おそらく弊社でも起こっているときでいけば
要件定義を書いているフェーズでの
目標を多分大きく外すことになってくると思うので
じゃあそれなんでっていう形で
改善が進むんじゃないのかなと思います
なんでごめんなさい
その詳細を
どうやって減らすかというところは
かなり個社によって違うところもありますし
弊社でいってもプロジェクトでかなり違うところがあるので
一概にこれっていうのはお伝えできないんですが
しっかり目標の計測と目標の設定と
振り返りっていうのをしていくことで
一個ずつ改善が進んでいくんじゃないのかなと思います
ありがとうございます
次ですね
機能リリース2倍という目標は誰が定めたものですか
PDMですかと
PDM以外からだった場合
どういった反応がありましたかというところです
誰が決めたものですか
最終的に決めたのは
むしろ私たちプラットフォームエンジニアリングチーム側かなと思います
もちろんそこに2倍ってどうかなっていうのは
PDMの人たちとも話したりはしたんですが
最終的に決めたのはこちら側です
逆にPDMたちにお願いしたい
むしろPDMだけじゃないですね
アプリを作っているエンジニアにお願いしたいのは
一個のリリースに込める
期待する見込みの価値
アウトカムであったり
ノーススタンメトリックスどれくらい改善するんだ
そういう風な数値の大きさっていうのを
彼らに持ってもらって
代わりにプラットフォームチーム側で
どんどん物的生産性
どれだけアウトプット出せるかっていうのを
改善していく
そのオーナーシップは我々が持つべきかなと思うので
この2倍っていう数字は
若干勢いももちろんありますが
技術的に可能だなと
いろいろ行ったり来たりして
数値目論で立てたので
いけそうだっていうところで
プラットフォームエンジニアリングチーム側で決めました
はい
ご清聴ありがとうございます
多数の質問がいただいているようで
質問をいただきたいんですけど
時間の都合上これだけとさせていただきます
リンクアウトモチベーションさん
ブースがありますので
質問がありましたらそこで
質問していただければなと思っております
はい
改めて拍手で終わりたいと思います
ありがとうございました
本日はありがとうございました