デジタルと生産性

URL
作成日時
2022/7/23 7:26
最終更新
2022/7/27 13:32
タグ

Lifull事例

エンジニア現場視点でのKPIを真剣に考えてみた - LIFULL Creators Blog
こんにちは。エンジニアの加藤です。 普段はLIFULL HOME'Sの注文住宅領域にてエンジニアグループのマネジメントを担当しております。 マネジメントに携わり3年目となりますが、エンジニア組織の成果を定量的に測る難しさを常に感じておりました。 そのような中、今期より全社的にKPIマネジメントが導入され、その考え方を元に自身の担当するエンジニアグループとして目指すべき指標が明確化されたため、今回はその内容を紹介したいと思います。 弊社では中尾隆一郎さんが提唱するKPIマネジメント( 最高の結果を出すKPIマネジメント)を取り入れており、そちらには以下の4つのメインキャラクタ( 4MC )が定義されています。 Goal 最終的に目指すべき状態。 KGI Key Goal Indicator = 重要目標達成指標 最終的に期末に到達したい最も重要な目標数値。 CSF Critical Success Factor = 重要成功要因 最重要プロセス = 事業成功の鍵。 KGIを達成するためにいくつかあるプロセスの中から、最も重要なプロセス。 KPI Key Performance Indicator = 重要業績評価指標 KGIの先行指標であり、CSFの数値目標。 最も重要なプロセスであるCSFをどの程度実施すれば、期末にKGIを達成できるかを表した数値。 KPIマネジメントでは上記4MCの関係性を理解したうえで適切に設定し、運用・計測・改善することが重要となります。 KPIマネジメントを構成する4MCに対し、私たちのグループでは以下のように設定致しました。 Goal 開発生産性の向上 KGI 開発生産力 = 価値創出数(= Pull Requestマージ数) / 開発に関わるコスト(= 人件費 + 業務委託費 + システム利用料) CSF 1タスクにかかる開発速度の向上 KPI Pull Requestマージ数 これらの4MCを選定したプロセスを紹介していきたいと思います。 まずGoalとKGIについてですが、弊社では各組織単位においてそれぞれ4MCを設定し、KPIマネジメントの運用を行っております。 そのため、私がマネジメントするグループの上記組織であるユニット・部においても同様に4MCの設定がなされております。 そこで、ユニット・部を含めた組織全体として同じ方向性を持ち意識を揃える意図として、最終的な目標であるGoalとKGIは上位組織を踏襲することと致しました。 ただし、目標を達成する上での課題や状況、最適なプロセスは組織ごとに異なると考えられるため、Goalに対しての手段(CSF、KPI)はグループとして検討を行います。 中尾さんの提唱するKPIマネジメントではCSFを選定する上でのポイントは以下のように言われております。 これらを踏まえCSFを選定するにあたり、まずはKGIを構成する要素を分解し以下の2つをCSFの候補として比較致しました。 開発に関わるコストは人件費やシステム利用料などであり、ある程度固定費としてかかるため、価値創出数に対し現場の努力により変動する幅の狭い要素であると判断しました。 そのため、この時点で開発に関わるコストはCSFの候補から除外し、 価値創出数を増加 させるプロセスを深堀りすることと致しました。 KGIの要素である価値創出数はPull Requestマージ数に置き換えているため、Pull Requestマージ数の増減に影響する要素を以下のように分解しました。 実開発時間(= 総業務時間 - 運用時間 - ミーティング時間 - 社内行事時間) / 1タスクあたりの開発時間 * 1タスクあたりのPull Request数 これらの要素に対し分析を行い、最終的なCSFの決定を行います。 総業務時間 運用時間 運用時間を削減することで価値創出数が増加 運用業務の削減、効率化、自動化することで運用時間の短縮を図ることができる 体感として運用業務が発生することで意識が分散し、実時間以上に生産性の妨げになっている可能性がある しかし、日次採算システム上、全体に占める割合は約5% 改善すべきポイントではあるが、最重要プロセスとはいい難い ミーティング時間 ミーティング時間(以降MTG)を削減することで価値創出数が増加 不要なMTGの廃止、必要なMTGのみへの参加、MTGの効率化などにより削減可能 ただし日次採算システム上、全体に占めるMTGの割合は13%ほど 在宅勤務により必要なコミュニケーションも存在するとの考え方もあるため、一番弱いプロセスとしては考えづらい ...

Circle CI

Accelerate

  • デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
  • 変更のリードタイム - commit から本番環境稼働までの所要時間
  • 変更障害率 - デプロイが原因で本番環境で障害が発生する割合(%)
  • サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間

組織生産性と技術投資

私見です
  • 全体の生産効率の俯瞰の必要性
    • 工程A、Bがあった場合、Aの生産性が上がってもBの速度が律速になることがある。
    • 工程のクリティカルパスの生産性の向上が必要
    • 一方で、全体のプロセスの見直しによってA,Bの依存関係を解消する効率化も可能
    • 多能工化・多工程持ちにすることで、エンジニアを様々な工程に自由に再配置することで全体の効率を上げることも論理的には可能だが、学習曲線を考えると再配置による効率の低下は一定レベル起きる。
    • 一定規模を超えた組織生産(たぶん50〜100以上)において、単工程の改善の占める効果割合は下がっていく
    • この工程上の複雑度がいわゆる「技術負債」の根底にある
  • 技術による新しい問題の解決
    • 生産性は出力の量だけではなく、出力がもたらす結果によって最終的に測られる
    • レコメンド技術によるパーソナライゼーションによって顧客の購買が促進されている。2013年時点でAmazonの購入の35%はレコメンデーションによる
    • レコメンド技術は、ITによって顧客に「提案する」という新しい意味のある問題を作り出した。それまでのECサイトはあくまで顧客が買いに来るのを待つ場所だった。
  • 将来にむけた技術投資
    • Googleの収益源の多くはインターネット広告によっており、Googleにとってより多くの情報がインターネット上で行われる未来は都合が良い。それがGoogleプラットフォーム上であればなお良い。(今後どうかはなんとも言えないけど)
    • Googleが開発するChrome、Android、Pixel、GSuiteのすべては、インターネット上により多くの情報を集中させる未来をつくることにつながる戦略投資であるとも言える。
    • Googleのインフラへの投資は、世界中のデータをインターネットにあげて参照可能にすることで、よりインターネット市場を拡大させることに寄与している。それは、巡り巡って自社の利益に還元される。(情けは人のためならず)
    • AI技術はGoogleにとっては大量のデータを人間が参照可能なように検索・要約・提示するための不可欠な技術であり、投資するのは妥当であった。IT企業がGoogleと同様の投資をAIにすべきかはそれほど明らかではない。
    • 5年〜10年をかけた戦略投資をするのであれば、市場へのインパクトを前提とし、インパクトを与えた市場が自社にとって都合が良い未来になっているという絵を書く必要がある。

Googleのソフトウェア・エンジニアリング

  • トリアージ:そもそも計測するほどの価値があるか
    • 計測結果が肯定的であれ否定的であれ行動が取れるか
  • ゴールとシグナルを伴う、意味のあるメトリクスを選ぶ
    • LOC、コード行数は意味ないよね
    • GSM Goals/Signals/Metricsフレームワーク
      • Goal:望ましい結果。特定の指標に結びつかないようにする。街頭効果(見える範囲を探しても望む結果は得られない)を防ぐ。トレードオフを入れる。(速さと品質、など)
      • Signal:ゴールを達成したことを知る手段。
      • Metrics:シグナルをどう計測するかを決定する。シグナルと同じではない。計測できる代用品である。
    • GSMの例
      • Goal:エンジニアはリーダビリティのプロセスの結果としてより高品質なコードを書いている。
      • Signal:リーダビリティを認められたエンジニアが、リーダビリティを認められていないエンジニアよりコードが高品質であると判定している。
      • Metrics:四半期ごとの調査:自分自身のコードの品質に満足していると報告するエンジニアの比率。メトリクスは定性的なこともある。
    • QUANTS
      • Quality of Code
      • Attention from Engineers
      • Intellectual Complexity
      • Tempo and Velocity
      • Satisfaction
    • SignalとMetricsの違いは、測れるかどうか。計測可能性と正しさのトレードオフをSignalとMetricsで表現している。SignalはGoalを測るために達成すべき条件、MetricsはSignalを計測可能にするため代替品。Signalは妥当なコストで計測可能であるとは限らない。
    • Signalを計測するためのMetricsは複数あるかもしれない。複数あるMetricsが矛盾する可能性もある。それはあくまでMetricsがSignalの代替品であるため。その場合、Metricsを再検討すべきかもしれない。
    • 重要なのは追跡可能性を維持すること
  • Googleはエンジニアリングの生産性についての専門家チームを配置している。
  • エンジニアリングのプロセスの変更に伴うトレードオフの大半は正確な計測が難しく意図しない結果をしばしば生む
  • データ駆動であることを維持し、主観的アドバイスを排除を目指さないといけない。
  • 開発者のワークフローやインセンティブ構造の中に組み込まれる推奨事項の作成を目指すべき。トレーニングやドキュメンテーションの推奨が必要なこともあるが、日々の習慣にクコこまれるほうが変化させやすい。

Space Framework

Reference

エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud Blog2022/7/27 13:282022/7/27 13:2810歳の minne から、これから長く続くプロダクトを作るすべての人へ2022/7/29 6:322022/7/29 6:3210Xはどのようにロードマップを運用していくのか2022/7/30 4:232022/7/30 4:23TJOさんの下請けとGoogleの違い2022/7/31 14:532022/7/31 14:54システムインテグレーター - Wikipedia2022/8/1 4:402022/8/1 4:40カミナシでの技術的負債プロジェクトとその決断 / Beyond tech debts at Kaminashi - Speaker Deck2022/9/2 2:512022/9/2 2:51