はじめに
開発生産性をテーマとした技術イベントに出まくった結果、ある程度体系化された知識のおすそわけ記事です。
この記事を読めばわかること
- 開発生産性のトピックでよく語られている前提の部分
- 開発生産性を語るうえで大事なざっくりとした体系的な知識
- 開発生産性を測るためによく使われるメトリクス
雑に言えば、数字とってデータ駆動でPDCA回そうという話です。
この記事を読んだ後に、「開発生産性の議論 ﾅﾝﾓﾜｶﾗﾝ ...。」という人でも「まずはこの辺調べてみよう」ができる状態になればいいなと思って書いてます。
この記事を読んでもわからないこと
- 開発生産性の文脈におけるビジネスサイドとのコミュニケーションらへん
- 開発生産性の文脈における経営層とのコミュニケーションらへん
目次
- 開発生産性についての前提
- 開発生産性と言うクソデカワードの認識をそろえる
- 開発生産性には３つのレベルがあることを知る
- なぜ開発生産性を考えるべきなのかを知る
- 開発生産性を可視化する目的を明確にする
- 開発生産性の定性的評価（開発者体験）にも着目する
- 計測可能なメトリクスを知る
- メトリクス導入の注意点を理解する
- 最近は「テンポのいい開発」が流行っている（ように見える）
- 周りの巻き込み方を知る
- おわりに
開発生産性についての前提
まずは一度、以下の記事を読んでみてください。この記事の内容を起点（あるいは前提）に各企業でいろいろと取り組みがされていることが多い印象です。この記事を読むだけでボヤっとしていた「開発生産性」というワードの解像度が上がります。
開発生産性と言うクソデカワードの認識をそろえる
「開発生産性」という言葉は、その定義が多様であるため、個々人の理解が曖昧になりがち（認識がズレがち）です。その理由は、この言葉をどの視点から考えるかによってその意味合いが変わるからです。
生産性とは、ざっくり言えば「アウトプット / インプット」ですが、分子と分母に何の指標を入れて考えるかは生産性を考えるレイヤーによって変わるでしょう。より経営層に近い立場であるならば生産性をROIとして分子には利益を、分母には投資額を入れて考えるかもしれません。開発メンバーであるならば分子には書いたコード量を、分母には時間をいれて生産性を測るかもしれません。
このように「開発生産性」は多面的な概念であり、たとえ同じ開発メンバーレベルであっても、理解を共有するためにはその定義を明確にして認識を揃えることが重要です。
開発生産性には３つのレベルがあることを知る
生産性向上の文脈で何かしようと思ったときに、開発生産性を3つの段階で分けると具体的なアクションプランをイメージしやすいかと思います。
Lv.1 生産性
決まった時間でどの量の仕事を終えることができたか
Lv.2 生産性
決まった時間で、どのくらいの価値が期待される仕事ができたか
Lv.3 生産性
決まった時間で、どのくらいの価値が実現できたか
（引用元：開発生産性について議論する前に知っておきたいこと > 開発生産性の3階層）
このように３つのレベルで開発生産性をとらえることで、
- 生産性を大きな枠組みで俯瞰しつつ、
- 段階的な改善アプローチの検討と実践ができるので、
- 効率よく開発生産性向上を実現できそう
な気がしてきます。また、生産性レベルに応じた計測のための指標を準備することで、所属している組織のボトルネック特定や、生産性レベルアップ、生産性改善の評価がしやすくなります。
実際に、この考え方をマネージャー研修に取り入れ、各メンバーが実践すべきアクションを明確に示している企業もあるみたいです。
したがって、何か行動を起こそうと思ったときに下記のような、
- どの生産性の段階に焦点を当てるべきか
- 生産性レベルに応じて何の指標を活用すべきか
- 改善の結果をどのように評価するべきか
については、この前提の理解の有無がかなり効いてくると思います。
なぜ開発生産性を考えるべきなのかを知る
ところで、なぜ生産性向上がホットなトピックとして語られている（語られてきた）のか、それは以下２つの観点から考えられそうだと思っています。
不確実性には、組織のアジリティを高めてPDCAで対抗する
現代のビジネス環境は、技術の進歩 / 市場の変化 / 競合の台頭など、不確実性が高まっている...という話は耳タコではあるのですが、このような状況では、組織のアジリティ（適応力や柔軟性）を高め、迅速に変化に対応する能力が求められます。
市場の変化への対応（新しい競合が現れた場合）
- アジリティ高：迅速に戦略を見直し、新しい製品やサービスを開発して対抗する
- アジリティ低：戦略の変更に時間がかかり、市場の機会を逃す可能性が高い
技術の進歩への対応（新しい技術が登場した場合）
- アジリティ高：新しい技術を迅速に取り入れ、製品やサービスの改善に活用する
- アジリティ低：新技術の導入に消極的 or 導入できず、競争力を失う可能性が高い
顧客のニーズへの対応（顧客のニーズが変化した場合）
- アジリティ高：顧客の声を迅速にキャッチし、製品やサービスを改善して顧客満足度を高める
- アジリティ低：ニーズの変化に気づくのが遅く、対応するのに時間がかかる
組織が何かに直面した際にそれを乗り越えることができるか？つまり組織が不確実性に対するアジリティを持てているのか？はどう測ればいいでしょうか。
すごくざっくりと回答するならば、組織のアジリティとは 組織としてPDCAを回すスピードと回数 で測ることができそうだ、と言えそうです。開発生産性が高まるとPDCAがよく回るようになるため、変化に柔軟に対応ができるようになるからです。また、組織が迅速かつ効果的に市場のニーズに対応できることで、競争優位性を獲得し続けられる可能性が高まるからです。
開発生産性の向上でアジリティが高まり、アジリティの向上でアウトカム（結果や成果）を生む可能性が高まる、アウトカムが高まればインパクト（収益）が高まり、我々のお賃金も高まるかも...！ そんなイメージです。
ん～～～生産性向上、アツい。
アウトプットがあって、はじめてアウトカムの議論ができる
さきほど「アジリティの向上でアウトカム（結果や成果）を生む可能性が高まる」と説明しましたが、アウトカムはどう生み出すのでしょう。
より多くのアウトカムを生み出す手段のうちの１つは、より多くのアウトプットを生み出すことです。生産性が向上するとというのは、新しい機能の追加 / 不具合の修正 / 改善の実装など、開発組織に関連するすべての作業が、同じ時間内により多く生み出すことができるようになるということです。つまり、 より多くのアウトプットはより多くの成果を出すための基盤となります。
組織のアウトプットの増加に伴って、アウトカムが増加する可能性も高まります。これはあくまで可能性の話であって必ずしもそうであるとは言えませんが、アウトプットが増えれば増えるほど、PDCAをより多く回すことができるようになるので、アウトカムに直結するアクションを実行できる可能性が高まると言えます。これは、顧客満足度の向上 / 製品の品質向上 / 市場での競争力の強化など、ビジネス上の利益に直結します。
それゆえ開発組織のアウトプット（生産性）向上は、企業のアウトカム（提供価値） / インパクト（収益）を増やすための重要な手段であり、ビジネス上の競争優位性を確保するためには欠かせない要素であると言えます。
開発生産性を可視化する目的を明確にする
シンプルに、数字って可視化するといろんなことに使えますよね。数値化の目的は各社共通で以下のようなものが多いかなと思います。
組織の現状を把握する
理想と現状のギャップを知ることで、現状の理解と改善の必要性を明確にすること。
- 組織は今どこに立っているのか
- 組織は今どこに向かっているのか
を理解・共有するための第一歩です。
また、数字を見ることで「改善が必要なかった！」という事実を確認するきっかけになるかもしれません。これはこれで組織が既に効率的に機能していることを確認し、数字を維持するための基盤たりえます。
課題のボトルネックを特定する
シンプルな改善のためのアプローチです。伸びしろがある場所を改善することで、大きな効果を得ることができます。
改善すべきはエンジニアリングではなく、開発のプロセスや関係者間のコミュニケーションなど、他のかもしれません。全体的な生産性を向上させるための包括的な視点が大事です。
改善活動を評価する
打った施策が正しかったかどうかを数字の変化をもとに評価することで、次のステップを計画するための洞察を得ることができます。
数値の活用によって、どのように改善していくべきかのより具体的なアクションプランを考えるきっかけになるはずです。
ヘルスチェックとして活用する
開発プロセスの健康状態を可視化することで、問題の早期発見と対策が可能になります。改善活動ばかりに焦点が当てられがちですが、組織が健全に機能していること知るための重要な視点だと思います。
問題が起きたときにすぐアクションができる状態を保つことで、開発組織の生産性維持に貢献できます。ヘルスチェックは組織が常に最高のパフォーマンスを発揮できるようにするための重要な要素だと思います。
目指すべき目標の備忘録として活用する
事業の成長に伴い、今まで見えていなかった新たな課題が増えていきます（見えてきます）。
その際に目先の中間的なアウトプットに意識を持っていかれることがありますが、常に組織が向かっていくべき最終的なインパクトを意識し続けること、近視眼的な見方に陥らないようにメトリクスを活用するという手もありますね。
開発生産性の定性的評価（開発者体験）にも着目する
開発生産性の文脈においてセットで語られることも多い開発者体験（DevEx）の理解も必須です。（開発者体験もまたクソデカワードなのである。）
例えば以下のような経験はないでしょうか。
- ドキュメントが整備されておらず、いちいちキャッチアップコストが高い...
- ソースコードの変更容易性が低く、修正が困難...
- CI の実行速度が遅く、フィードバックを得るまでの待ち時間が長い...
- 技術的負債が蓄積されていて運用のコストが高い...
これらは開発者体験がよくない状況を示しています。開発者個人の生産性向上に注力したとしても、開発者体験がボトルネックとなっていて全体の生産性が向上しないケースも十分考えられます。
上記の研究では開発者体験を大きく以下の３軸でとらえており、
- フィードバックループ：高速にPDCAを回すことのできる環境
- 認知的負荷：コードやツールの認知的複雑度、コンテキストスイッチなど
- フロー状態：作業に没頭できるまとまった時間の確保
チームや組織はこれら 3 つの主要な領域に焦点を当てることで改善に向けた一歩を踏み出すことができると説明しています。
開発生産性の向上と開発者体験の向上は密接な（相互に影響を与える）関係があり、入り混じったような関係です。後述の SPACEフレームワーク でも、開発生産性を測る指標として開発者体験の側面を尺度として加えています。
つまり、開発生産性の中にはより 物的で定量的な側面 と 開発者体験という定性的な側面 が存在しており、バランスよくアプローチしていく必要がありそうな気がしています。（一般的には開発者体験の向上が開発生産性の向上に先行することが多そうだな～という印象）
以下には開発者体験（DevEx）の中で触れられている大きな３軸についての説明を軽くまとめておきます。
フィードバックループ
ソフトウェア開発組織において重要なのはフィードバックループを短縮することで、バリューストリーム（顧客に価値を提供するために必要な活動を全体的な視点で捉えたもの）を最適化し、競争力を高めることです。
また、開発者にとっても高速なフィードバックは重要です。
速いフィードバックループは、開発者が最小限のやりとり・起動修正で迅速に作業を完了することを可能にします。対照的に遅いフィードバックループは、開発プロセスの中断 / 開発者の待ち時間の増加 / タスク切り替えのためのスイッチングコストの増加 などの要因となり、フラストレーションや開発活動の遅延を引き起こします。
認知的負荷
ソフトウェア開発において、増加し続けるツールやテクノロジーによって開発者の認知的負荷は日々増大しています。
認知認知的負荷負荷は開発者の精神的処理の量を指しており、例えば一般的に、困難で複雑なタスクに取り組んでいる場合や、不慣れな開発フレームワークを理解するために学習している際に認知的負荷は増加します。
認知的負荷は開発者の最も重要な責任である「顧客への価値提供」を妨げる要因になります。認知的負荷が高い状態（不十分なドキュメントや複雑なコードなど）の結果として、開発者はタスク完了までに余分な時間・労力を割くコストが生まれてしまいます。
フロー状態
フロー状態は開発者が活力に満ちた集中と楽しさを感じる精神状態であり、生産性やイノベーションにつながります。フロー状態を体験するためには中断や遅延を最小限に抑える必要があり、主体性や明確な目標、やりがいのある仕事も重要になります。
開発者のフロー状態の実現には、ミーティング間の空き時間をなくすことや差し込みタスクの排除、チャットツールにおける特定の個人に対するメンション数を減らすこと（ここは意訳）などの対策をする必要があります。
参考事例
計測可能なメトリクスを知る
以下によく見るものを上げてはいますが、計測できる数値は無限にあります。自社の課題や関心事に応じて適切な指標を活用することが重要です。
FourKeys
ソフトウェア開発チームのパフォーマンスを示す 4 つの指標
| 指標 | 説明 |
|---|---|
| 変更のリードタイム | 変更のコミットから本番環境デプロイまでの時間 |
| デプロイ頻度 | 本番環境へのリリース頻度 |
| 変更失敗率 | 変更がシステムに障害を引き起こす確率 |
| 平均修復時間 | システム障害発生後、復旧するのにかかる平均時間 |
SPACEフレームワーク
生産性のさまざまな側面を捉えるために開発されたフレームワーク
| 指標 | 説明 |
|---|---|
| Satisfaction and well-being |
・開発者が自分の仕事、チーム、ツール、文化に対して感じる充実感 ・開発者の健康や幸福度、そして仕事がそれらに与える影響度合い |
| Performance | システムまたはプロセスの結果。単純化すると「開発者が書いたコードは、期待されたことを確実に実行したか?」というもの |
| Activity | 仕事を遂行する過程で完了した行動やアウトプットの数 |
| Communication and collaboration |
個々人やチームがどのようにコミュニケーションをとり、協力し合うかの指標 |
| Efficiency and flow |
個人であれシステムであれ、中断や遅延を最小限に抑えて仕事を完了させたり、進捗させたりする能力 |
ソースコードのメトリクス
ソースコードについて様々な角度から計測した数値
| 指標 | 説明 |
|---|---|
| Cognitive Complexity | 認知的複雑度：コードの読みやすさを定量的に評価する指標 |
| Cyclomatic Complexity | 循環的複雑度：プログラムの複雑度を定量的に評価する指標 |
| Coverage | テストスイートが実行されたときにソースコードがどれだけ実行されたかを示す |
| Code Smells | ソースコードに深刻な問題が存在することを示す何らかの兆候のこと |
フロー効率・リソース効率
- フロー効率：作業がスムーズに進行し、待ち時間が最小限に抑えられている程度を示す指標
- リソース効率：利用可能なリソース（人員、時間など）が最大限に活用されている程度を示す指標
| 指標 | 説明 |
|---|---|
| PR作成数 | PRがどれだけ作成されているか（そのまま...） |
| PRマージまでのリードタイム | PRが作成されてからmergedになるまでの時間 |
| 開発サイクルのサイクルタイム | PR作成からレビューまで / レビューからApproveまで / Approveからmergedまで / PR作成からmergedまで の時間など |
| WIP数 | 並行して着手するタスクの数 |
| まとまった作業時間 | 集中して作業できる時間の総量 |
| 個人宛てメンション数 | 個人への負荷の偏り |
その他よく使われてるメトリクス
いや、ほんとに指標は無限です。いろいろと組み合わせるのもアリです。
| 指標 | 説明 |
|---|---|
| チケットのクローズ数 | 開発者が完了させたタスクの数 |
| コード変更行数 | 開発者がどれだけのコードを書いているかを表す |
| ファンクションポイント | ソフトウェアの機能規模や複雑さを客観的に測定する指標 |
| ストーリーポイント | タスクの規模、複雑さ、リスクを踏まえた相対的な数値 |
| 作業工数の内訳 | 何にどれくらいの工数を投入しているか |
参考
メトリクス導入の注意点を理解する
いろいろと気を付けるべきポイント（メトリクス導入アンチパターン）が存在します。
追うべき指標はチームの状況を加味して決める
組織に有効な指標は開発生産性のレベルによって変化します。向上させるべきはLv.2 生産性ではなく Lv.1 生産性かもしれませんし、それ以外の課題かもしれません。メトリクス導入の前に、まずはいろいろと数字を取ってみて現状の確認、それから検討してみることを勧めます。
また、追いかける数字を個人とチームの２軸で分けてもいいかもしれませんね。
The figure provides examples of individual-, team- or group-, and system-level measures.
引用元：The SPACE of Developer Productivity > Framework in Action
他社事例が自組織にフィットするとは限らない
同じような課題であったとしても、他社の特定の組織と自分が所属する組織は全く違います。技術スタック / アーキテクチャ / 組織文化 / 人材の特性など、変数があまりに多いので、同じ数字を追いかけても必ずしも結果が出るとは限らないことには注意が必要です。
メトリクスはあくまでツールであり、その数値の解釈は組織の特性や目標によって変わる可能性があります。例えば、Four Keys や SPACE フレームワークに関しても、その目的と背景を理解した上で自社の状況に合わせて適用する必要があります。
複数チーム間で結果を比較することの危うさ
他社組織と同様、同じ組織内の別チームであっても、組織の状況や抱えている課題が同じことは稀でしょう。それゆえ同じ指標を用いたとして、このチームはあのチームに比べて結果が出てないからダメ！という判断は非常に安直で危険かと思います。
あくまで改善のサイクルを回すための指標として、各チームの個別の課題などに対して利用する方がよさそうです（組織共通で目指す指標は分けて考えたらいい）。測定それ自体は共通化できても、具体的なアクションまで同じ、あるいは同じアクションでも同じ効果がでるとは限らない、そんなイメージです。
アウトプットだけ増えても意味がない
開発生産性向上の目的は、あくまでも組織のアジリティを高めてアウトカムの確度を上げようぜ、総量を大きくしようぜ、的なところにあると思っています。
アウトプットを増やすための活動がアウトカムやインパクトにつながらないものであれば頑張ってやっている意味は薄いと思うので、そこは注意が必要です。
また、やっているうちに数値を上げることが目的になってしまっては本末転倒です。
人事評価の指標として使う危うさ
上記と同様、「メトリクスを上げること」が目的となり、手段の目的化が起きそうな予感がプンプンします。
導入の際には個人レベルで理解できるよう背景の部分まで説明、合意形成し、意味のある目標を追いかけていきたいですね。
その数字は組織内だけで完結しないかもしれない
計測を 入口 / 出口 の観点で分けて考えることをお勧めします。
例えばデプロイ頻度を計測するとして、自組織の他に CI/CDチーム・QAチーム・出荷チーム が関わっていたらどうでしょうか。これでは組織内で改善できない変数が多く、チームの努力で改善しようがないかもしれません。
組織全体でやる場合は他チームとの関わりも含めた「出口（デプロイ周りやその後の計測）」を選択してもいいかもしれませんが、最初は所属するチームで完結する「入口（PR作成からmergedまでなど）」を計測するといいと思います。
数値計測の自動化ツールをつくる必要があるかもしれない
Findy Team+ とかをサクッと導入できたら楽なのですが（ステマじゃないよ...）、手動でやるわけにはいかないのでツールを作る必要がありますよね。
例えば Pull Request / Merge Request まわりであれば、GitHub や GitLab で提供されているAPIがかなり充実しているので、とりあえず動くツールはサクッと作れます。
最初は小さく始めてみましょう。
最近は「テンポのいい開発」が流行っている（ように見える）
ちょっと認知バイアス感が否めないのですが、「1日2PRを目標にしてます！」「PRのopenからmereまで24時間以内にしてます！」など、テンポのいい開発が流行っているように思います。
というのも、アジャイルやスクラムの文脈で仮説検証と改善を繰り返す経験主義的な文脈が受け継がれていることもあり、「迅速なフィードバックループ」と「短いリリースサイクル」が重視される傾向にあるからでしょうか。
実際に話を聞いている感じ、効果はけっこう出ていそうな印象を受けます。
例えばチームの Lv.1 生産性を上げるために、「1日あたり2つPRをつくろう」「PRのopenedからmergedまでのリードタイムを24時間以内にしよう」という目標を設定した場合、メンバーはいろんなことを考えなければいけません。目標達成のためにメンバーは、
- レビューする人が差分を理解しやすいコミットメッセージ
- レビューする人がすぐに見られるPRのサイズ
- タスク分解をPR単位で表現する意識
- 開発に着手するためのWIP制限
- フロー状態を意図的に生み出すために不要なミーティングの棚卸し
など、数字を意識するようになったことでそれを最大化させるための努力をするわけです。その結果としていままで問題視されてなかった、あるいは負担だったがマネージャーのマンパワーでどうにかなっていた部分が顕在化して、組織としていい課題を乗り越えるような良いサイクルが回り始めます。
余力が生まれてくると CI実行時間の短縮や、日常の定型タスクの自動化などが活発に行われ、開発者体験も向上していきそうですよね。結果として開発生産性も開発者体験も向上して、開発チームは素早く新機能をリリースし、ユーザーからのフィードバックを即座に取り入れることが可能になっていく...。
めっちゃよくないですか？特に「なんか知らんがタスクがめっちゃ進んでいる」という感覚はバカにできないですよね。
最近ではスクラム開発も一般化しつつあるので、テンポのいい開発の実現は Lv.1 生産性を向上させるためのベストプラクティス化してそうな気がします。
周りの巻き込み方を知る
流れとして、特定のチームで結果が出れば自然に他のチームに伝播していくと思うので、まずは自組織や近い場所から結果を出したい。
で、いざ自組織で取り組み始めようと思っても、さすがに１人だけではスケールしていかないので、途中で誰かを巻き込む必要があります。マネージャーに相談してすぐやってみよう！となれば一番いいのですが、必ずしもそうでない場合もあるかと思います。
確証はありませんが、以下一般的に効果があると言われる思考のフレームワークなので、マネージャーなどが「えーーー？」とか言ってきたらプレゼンしましょう。
TOC（制約の理論）：抵抗の６階層
TOC思考プロセスは、「組織の中に変化を生み出し、実行するための体系的なアプローチを提供するもの」です。つまり、組織のゴール（目的）に向かって変えるべきものと変えなくてもよいものとを明確にし、変えるべきものをどのように変えていくか（変化させていくか）を明確にする、組織的な問題解決です。
以下の抵抗を乗り越えろ！
- 抵抗１．対応しようとしている問題を、問題として認めない
- 抵抗２．解決策の方向性に同意できない
- 抵抗３．解決策が問題を解決するとは思わない
- 抵抗４．この解決策は、もし、実行するとマイナスの影響を引き起してしまう
- 抵抗５．提案されている解決策の実行を妨げる障害がある
- 抵抗６．その結果起こる未知のことへの恐怖感
AIDMA モデル
消費者の購買行動をモデル化したものが、AIDMAモデル（AIDMAの法則）ではありますが、アクションを促すという点では有用な気がしています。
- Attention：認知させて、
- Interest：興味を引いて、
- Desire：欲求を顕在化させて、
- Memory：やりたいかも～と思わせて、
- Action：行動を促す（巻き込む）
ADKAR モデル
組織変革の根幹となる要素をシンプルに抽出したモデルであり、変革に対する体系的な手法として利用されることが多いらいしいです。
組織変革のための 5 つのステップ
- Awareness：変革の必要性を認識させる
- Desire：メンバーが自ら変革を実施したいと感させる
- Knowledge：変革を実施するために必要な知識を習得する
- Ability：知識を活用して実際に行動に移す
- Reinforcement：変革の成果を認め、変革をさらに進める
ジョン・コッターの「変革の8段階のプロセス」
組織の変革を成功させるための8つのステップで、8 つの「つまずきの石」を蹴っ飛ばすフレームワーク。
- 危機意識を高める
- 変革推進チームを結成する
- ビジョンの策定
- ビジョンの伝達
- 社員のビジョン実現へのサポート
- 短期的成果を上げるための計画策定・実行
- 改善成果の定着と更なる変革の実現
- 新しいアプローチを根付かせる
シンプルに応援してくれそうな人を見つける
なんだかんだこれが一番効くと思ってます。自分の主張（こういうことやりたい！）を後押ししてくれるキーマンを探すことですね。私事にはなりますが、幸い弊組織には同じ課題意識を持つとても忙しいマネージャー陣がたくさんいるので、若手が勝手にやってるとすんごい後押ししてくれます。（むしろ若手を追い越していく）
私は環境に恵まれていることを再認識しつつ、こういうのって組織の文化・風土にもよるんだろうなぁと思ってしまうのですが、開発生産性向上に対して一緒に走ってくれる仲間探しができれば一番いいんだと思います。継続的かつ効率的に取り組んでいくためには熱量も大事なのですが、課題の解消をイイネ！と言ってくれる文化が一番大事だと思っているので...。
記事の本筋とはズレるけど「失敗を許容する文化です！」とか「挑戦を後押しする文化です！」とかよりも「誰かの関心事にみんなでよってたかってお祭り騒ぎする文化です！」で働けたら一番楽しいなーと思う。弊組織はそれに近い気もしなくない。
おわりに
生産性向上のチームや組織があったとしても、必要なツールやデータなどを提供されたとしても、実際に改善していくのは結局開発側になります。やっていくためにはモチベーションが必要で、モチベーションを形成するのは明確なロジックと少しずつよくなっている実感です。
なのでやらされ仕事でなく、「これやったらよくなりそう～！」というワクワクや「駆逐してやる...!!」という憎悪を開発側が持てたらいいのかなと思います。
弊組織でも個人的にやっていきたいことがたくさんあるので、また変化があれば記事にしようかと思います。おわり。