process-management - プロセスを改善するためにどのような測定を使用しますか?

Question

この質問はもともと、「ソフトウェア開発組織でどの KPI を使用していますか」というものでした。残念ながら、KPIは 4 文字の単語のようであり、KPI は常に誤用されていると思われます (実際に誤用されているのでしょうか?)。

そのため、KPI が役立つと当初考えていた根本的な目標に到達するように質問を改善できれば幸いです。あなた (またはあなたの組織) がソフトウェアを開発する方法について何らかのプロセスがあると仮定します。次に、あなた (またはあなたのチーム) が、ソフトウェアの開発と配信をより上手に行いたいと考えているとします。最後に、改善する方法の 1 つがプロセスを改良することだとします。

これらすべてを考慮して、プロセスの改善がプラスの影響を与えているかどうかをどのように知るのでしょうか? これらがKPIまたは [SMART 目標]( http://en.wikipedia.org/wiki/SMART_(project_management))である場合は、効果的であるとわかった KPI/SMART 目標の個別またはグループを提供してください。最後に、プロセスの改善が有用だと思わない場合は、それについても説明できると思います。

私が役立つと思う改善点は、品質、リリースの適時性、生産性、柔軟性です。個人または開発者チームの他の側面がある場合は、それを知るのは興味深いことです。

明確化のための注意:

問題は、プロセスを最適に適応または変更する方法や、優れたプロセス改善プロセス (カイゼン、ふりかえりなど) についてではありません。また、根本原因の分析や、プロセスの特定の側面を改善する必要があるかどうかを判断するために使用されるその他のアプローチに関するものでもありません。

プロセス改善が達成されたかどうかを判断するための手段の使用は、進行中のプロセス改善と混同されるべきではありません。(それは良いことですが、質問の内容ではありません!)

プロセスは何でもかまいません。スクラム、アジャイル、エクストリーム、ウォーターフォール、アドホック。この質問は、特定の種類のソフトウェア開発に最適なプロセスは何かということではなく、時間の経過とともにそのプロセスを改善する方法です。

明らかに、特定の指標は、関連するプロセスと、改善しようとしていると認識されている問題によって異なります。この質問は、使用されている指標の例を取得することを目的としており、さまざまなプロセスや改善領域にまたがっていることは明らかです。

メトリクスは常に使用されるものである必要はありません。たとえば、プロセスの変更が機能するかどうかをテストするときにのみ使用できます。（たとえば、常に測定して追跡するには、時間やお金の面で費用がかかりすぎる可能性があるため、追跡するだけでプロセスを微調整できます）。

メトリクスの実装が不十分な場合、開発者がシステムを操作したり、その他の方法でゲームを行ったりする際に、メトリクスの使用が悪影響を与える可能性があることは当然のことです。プロセス変更を実施する担当者は、この問題を認識しており、それを軽減するための効果的な措置を講じているものと想定されます。

すべてのソフトウェア組織は、会社にどのように適合するかが異なるため、会社内で期待される特定の事柄が異なりますが、製品の品質、生産性、柔軟性、およびリリースの適時性は、すべてではないにしてもほとんどの組織に適用できると思います. （特定の組織に応じて明らかに異なる重点を置いています。）

この質問はコードのソース行とは何の関係もありません! 特に、プログラマーの生産性を測定することには興味がありません。特に、SLOC や修正されたバグの数、またはその他の素朴な測定に関してはそうです。チームまたは個人が改善を測定するより高いレベルの方法に興味があります。単一の KPI を使用して誰かのパフォーマンスを測定することに興味はありません。チームのソフトウェア開発プロセスを測定および改善するために、さまざまな KPI を使用することに関心があります。

KPI が誤用されて効果がないという恐ろしい話を知っていますが (それらを見つけるために一生懸命検索する必要はありません)、プロセスを継続的に改善しようとしている人が誰もいないとは信じられません。 KPI の良い例がいくつかあります。

個々のソフトウェア プログラマーに適用される単純化されたメトリックの欠点については、すべて知っています。私が KPI を使用すべきではないすべての理由ではなく、人々が有用であると判断した KPI または代替戦略の例を取得することを本当に望んでいます。

私は主に、ソフトウェア開発会社全体ではなく、大企業内の開発組織に関連するプロセスとパフォーマンスに関心があります。たとえば、ソフトウェア会社は製品が市場に適した機能を備えていることを確認する必要がありますが、一般的にそれはエンジニアリングではなく製品管理の役割です。はい、エンジニアが製品管理に関与する理由と程度については、まったく別の議論がありますが、それは別の議論です。

Answer 1

キー パフォーマンス インジケーターを聞くと、少し心配になります。通常、次に行うことは、パフォーマンスを報酬にリンクすることであり、そうすればすぐに立ち往生することができます。バグ修正に関する報酬システムを決定したソフトウェア会社のことをいつも思い出します。テスターはバグを発見したことに対して報酬が与えられ、開発者はバグを修正したことに対して報酬が与えられます。バグの挿入、検出、および修正を中心に即座に闇市場が形成されたため、開発は停止しました。

組織の KPI は、顧客を重視する必要があります。作成しているソフトウェア製品のタイプに応じて、次の方法で測定できます。

• 販売 - あなたの製品は顧客の要求を満たしていますか? これは、ソフトウェアのプレゼンテーションと売上の比率、または Web サイトの購入ページへのアクセスと実際の購入の比率で測定できる場合があります。
• 品質 - あなたのソフトウェアは理解しやすく、信頼できるものですか? 顧客ごとに 1 日あたり何件のサポート コールを受けますか? 何かを行う方法についての質問ですか、それともエラーですか?
• 顧客満足度 - 顧客は製品にどの程度満足していますか? 顧客を調査し、満足度を高めるために何ができるかを見つけ、後でもう一度調査して、改善されたかどうかを確認します。（たくさんの質問をしたり、頻繁に質問したりして、お客様を困らせないでください）

はい、これらの指標は、見つかったバグや生成されたコード行などの基本レベルのソフトウェア メトリックとは何の関係もないようです。ただし、見つかったバグの問題は、バグの重大度を評価する必要があり、リファクタリングによって多くの場合、コード行が削減されることです。タイムリーな配達に対する顧客の期待に応えている場合にのみ、タイムリーさが問題になります。

ビジネス目標に集中します。ソフトウェアを購入する顧客がいて、それを使用するために多くのサポートを必要とせず、顧客が満足している場合、ソフトウェア組織は成功しています。バグの検出、スケジュールのずれなど、これら 3 つが整っていなければ意味がありません。

あなたのソフトウェア プロジェクトが大多数の場合、遅れたり、予算をオーバーしたり、予定より少ない機能で出荷されたり、バグがあったりします。これらのことで自分を打ち負かすのではなく、それらに対処して先に進んでください. はい、バグ データベース、ソース管理、テスト、およびプロジェクトの速度を測定する方法が必要ですが、最終的にビジネスの成果を達成できなければ成功することはできません。いくつかのバグがあります。

改訂された質問に対処するための更新

KPI を使用したい場合は、ターゲットが移動することが多い無形の製品を提供する場合は困難です。今年会計システムで使用した KPI は、来年文書管理システムを実装するときに同じ意味を持ちますか?

例として、KPI が広く使用されている職業である弁護士を取り上げてみましょう。弁護士の測定では、次のような KPI を使用します。1 か月あたりの請求時間。債務者元帳の年齢; 請求されていない作業の平均年齢。請求された料金の償却率。等々。ここで傾向に気付くはずです。これらの KPI はすべて、クライアントが提供したサービスに対して支払う意思がある (または支払わない) ことに関連しています。これが成功の最終決定者であり、ソフトウェア ビジネスの KPI としてこの種の測定を使用できるいくつかの方法を (上記で) 提案した理由です。

あなたが提供する価値に対してクライアントが支払う意思とは関係のない KPI を設定しようとすると、私たちが何を測定しているか、どのように測定しているか、どのような違いがあるかという問題に突き当たります。測定値、または昨年とは対照的に今年測定されているもの。

「顧客が支払った金額」は毎年一定の値を持ちます。「ソフトウェアのバグ」、「リリースの適時性」、「柔軟性」などの恣意的な指標には固定値がなく、KPI の増加は直接的なものではない場合があります。 「バグが多いほど品質が低下する」など、KPI によって測定されることを意図した基本的な値との関係。

たとえば、コロンビア大災害の後、調査チームは数百の勧告と調査項目を思いついたことを思い出します。これらの新たに発見された「バグ」は、スペースシャトルの品質が突然大幅に低下したことを意味するのでしょうか? 実際、調査の結果、スペースシャトルの方が品質が高くなりました。そのため、バグに関する KPI は、大規模な QA セッションによって簡単に歪曲される可能性があり、報告されたバグが多いほど、実際にはソフトウェアの品質が高いことを意味する場合があります。

リリースの適時性に関する生産性は、クライアントがカスタム開発を行うためにあなたにお金を投げかけるなどの商業的要因によって簡単に歪められます. リリース スケジュールは遅れますが、ビジネスは改善されます。

柔軟性に関して言えば、これほど目に見えないものをどのように測定するのか、推測することさえできません。

クライアントの財布のこちら側で価値があると私が考えることができる唯一の測定値については、プロジェクトの速度です。最後のイテレーション/サイクル/リリースをどれだけ見積もって、実際にどれだけ完了したか? 次に、この数値を次のイテレーション/サイクル/リリースに利用できる時間に当てはめて、今回はどれだけの作業を完了できるかを見積もります。イテレーション中に、残り時間をバーンダウン チャートなどに表示できます。

残りはプロセスに帰着しますが、これを KPI に限定することはできないと思います。あなたにできることは、開発者が全員が何をしているか (毎日の開発者会議) を把握し、拡張されたチームが情報を得て (毎週または隔週のチーム会議)、前回何が機能し、何が機能しなかったか (ふりかえり) を理解することだけです。あなたは透明で効果的なコミュニケーションを持っています。

残念ながら、あなたが求めているような魔法の KPI はないと思います (ただし、KPI としてクライアントからお金を得ることの関連性を見落とさないでください)。

Answer 2

圧倒的に最良の単一の指標は、「テストされた機能が提供され、受け入れられた」ことです。アジャイルの世界では、通常、「ユーザーストーリー」の観点から「機能」を測定しますが、顧客に受け入れられる、提供およびテストされた実際の機能を測定する限り、任意の便利な形式にすることができます。

SLOC、SLOC /スタッフアワーなどの通常の他の測定は、チャーリーの最初の管理法のために失敗します。これは次のとおりです。

人々は、彼らが提供するために報われているものは何でも提供します。

メジャーをSLOCとして設定すると、多くのSLOCを取得できます。SLOC / hrを使用すると、多くのSLOC/htが得られます。彼らに残業のボーナスを与えてください、あなたはたくさんの残業を得るでしょう。

ああ、そして相関関係も覚えておいてください：

人々が提供しているのは、提供する価値があると彼らが考えるものです。

必要なものが得られない場合は、実行されていることを実行することがなぜやりがいがあるのか​​を尋ねてください。

Answer 3

ベンノ、私はあなたのコメントに答えていますが、答えるのに十分な文字数がありませんでした.

これは、解決する問題によって異なります。たとえば、開発者がコードをチェックインしてから実際に本番環境に配置されるまでの時間が長すぎるように見えるという問題があるとします。次に、所要時間のベースライン測定値を取得します。次に、変更を入れてから、一定期間測定して、時間がかからなくなったかどうかを確認します。また、解決策が機能しないと判断され、その前後に再作業のために送り返された回数などをチェックして、解決策が高速ではなく低品質であることを確認することもできます。

現在、これらの測定に関する IT の問題は、一部の問題は頻繁に再発しないため、十分なデータを蓄積するのにかなりの時間がかかる可能性があることです。この場合、変更が適切かどうかを判断するのに十分なデータが蓄積されるまで、主観的なデータに頼ることから始めなければならない場合があります。ただし、ユーザーが慣れるまで、改善点があるかどうかを尋ねないでください。新しいプロセスの最初の 1 ～ 2 週間は、変化に対する抵抗に直面するため、あまりにも早い段階で質問すると、主観的な結果が悪くなります。

もう 1 つ気をつけなければならないことは、あなたが何かを測定していることを人々が知っている場合、彼らは自分のパフォーマンスが測定されているのではないかと恐れ、システムを操作して良い結果を得ようとすることです。多くの場合、すでに導入されているシステムに基づいて測定を行うことが最善です (ソフトウェア変更の要求を管理するシステムがあり、データベースにクエリを実行して、過去に期限を過ぎた要求の数、変更後に再開した数を調べることができます)。閉鎖された、または過去のリクエストに関連しているなど、開発者の終了とコードが本番環境に移行されるまでの時間差など）。特に、古いシステムと新しいシステムの両方の期間にまたがる場合は、重大な異常値を排除することも検討する必要があります。たとえば、悪いからではなく、QA に可用性の問題があり、これは優先度が最も低いため、100 日以上 Qa に置かれている 1 つのリクエストがあり、優先度の高い作業にぶつかり続けています。この時間は、時間の改善を測定する上では価値がありません。時間を長くする要因は、修正しようとしているプロセスではないからです。データをグラフ化すると、除外が必要な外れ値を簡単に確認できます。

Answer 4

コスト、品質、スケジュールに基づいてKPIを作成することは、良いスタートです。測定したいそれぞれの属性を検討してください。

これらの各測定値を分割してバグのコストを表示できると便利です。プロジェクトの後半で多くのバグ修正作業を行うと、コスト/スケジュールが急増します。コードベースのどの部分にバグがあるかをプロファイリングできると、追加のテストやコードの書き直しの可能性をターゲットにするのに役立ちます。通常、バグの80％はコードの20％に起因します。それがどこにあるかを知ることで、チームはより集中できるようになります。

編集：品質コスト（CoQ）や品質不良コスト（CoPQ）などの指標を見てください。

生産性などの測定値は常に定量化するのが困難です。たとえば、LOC /日を使用すると、コードの行が正確に何であるかについての議論につながりますか？また、開発者がこれらのものが追跡されている理由を理解していない場合、または個人的な測定値として認識している場合、生産性を「高める」ための愚かなコードフォーマットにつながる可能性があります。LOC /日が開発者レベルで測定されていない場合でも、チームのライバル関係を獲得して同じ結果を得ることができます。

編集：スティーブマコネルのConstruxウェブサイトで見つけられるべきいくつかの良い議論があります。[はい、それはコードコンプリートの名声のスティーブマコネルです]

Answer 5

私は14年間専門的にプロセス改善を行いました。これが私のアドバイスです。定量化するのをやめて、人々と話し始めてください。測定は、特定の問題（問題を理解すると、何を測定するかについてより良いアイデアが得られます）および製造などの反復可能なプロセスに対して正常に機能します。あなたの人々は問題のある領域がどこにあるかを正確に知っているので、あなたの顧客とユーザーも（非常に異なる視点から）知っています。懸念がある領域の実際のプロセスをフローチャート（コンピュータープログラミングシンボルではなくインダストリアルエンジニアリングシンボルを使用）で示します（プロセスのふりをするのではなく、観察するだけでなく、質問する必要があります）。プロセスのフロー全体を確認したら、遅延、作業が重複している領域、不要なプロセスがある領域（通常、人為的エラーを説明するためにプロセスにステップを追加するため）を探します。したがって、ヒューマンエラーの可能性のある領域がさらに多く作成されます）。各ステップの必要性と、各ステップを実行するためのより良い方法があるかどうかを質問します。潜在的な変化をテストし、実際にそれらが改善であるかどうかを確認します（何度も状況を悪化させ、良くはしません）。いかなる状況においても、問題の感触をつかんだり、フローチャートを作成したりするときにのみマネージャーと話をしないでください。あなたは本当の姿を得ることができないので、間違った問題を解決するでしょう。

Answer 6

廃棄物とバリュー ストリーム マッピングを理解すると、どこを改善する必要があるかがわかります。その知識から、何を測定する必要があるかがわかります。リーンとかんばんの原則がここに適用されます。無駄とそれがソフトウェアの生産に与える影響を理解することは、必然的にあなたの組織に固有の改善への特定の道を歩み始めるでしょう. 型にはまったアプローチを取ることはできません。「The Goal」と「Lean Thinking」を読んで (または聞いて)、何が問題なのか、それを修正する方法について、この本当に驚くべき目を見張るような視点について詳しく学んでください。

Answer 7

実際に全員を集めて、何が機能していて何が機能していないかを理解する以外に、あなたがしていることを改善するのに役立つプロセスはありません。私が現在率いるチームでは、一連のふりかえりを通じてこれを行っています (中でもこの本を強くお勧めします)。チームは通常、どの部分を改善したいかを知っています。秘訣は、実際にそれらを測定して改善する権限をチームに与えることです。

はい、確かにマクロ レベルを見ている人が必要です。トヨタのような組織を見ると、ビジネスと生産の境界線にまたがるチーフ エンジニアがいます (詳しい説明については、Scott Bellware のブログ投稿を参照してください)。私たちの組織にも似たような人がいます。私の上司は 20 年近く前に私たちの製品の最初の開発者の 1 人であり、技術面で非常に活発に活動していますが、顧客面にも多額の投資を行っています。私の仕事は、チーム全体を見て改善を提案することでもあります。

測定するには、まず私たちが目指している改善がチームが実際に変更できるものであることを確認してから、改善が測定可能になるようにSMART 目標に似たものを使用します。回顧録からのメモを投稿する大きな、目に見える壁があります。これはたまたま私たちが毎日のスタンドアップを開催する場所でもあるので、何が起こっているのかに集中することができます.

エグゼクティブ ミーティングに統計情報をまとめるため、提供されるコード行ではなく、コードの提供に焦点を当てています。私は意図的にチームを漠然とした単位で測定することから除外しました。つまり、私たちが働いた時間数や日数などを報告しないということです。彼らが見ているのは、私たちが機能をどれだけうまく提供しているか、どのように改善しているかを示すトレンド チャートです。チームが共有したいと感じた場合は、興味深い情報も含めます。

このすべての最大の利点は、1 か月試してみて、わずか 4 週間後に再評価できることです。これにより、新しいことを試すための参入障壁が大幅に低くなります。チームは、影響がある場合はすぐにキャンセルするか、再評価して次のふりかえりでより良い方法を見つけるかを知っているからです。

悪い点は、それがまさにあなたが探しているものではないということです。私たちが継続的にフォローしている 1 つの指標または一連の指標はありません。私たちは常にトレンドを監視し、興味深いと思われるものを測定しますが、それはほんの少しだけであり、チームが特定の目標を達成しようとしているときだけです。しかし、全体として、私はその仕組みに非常に満足しており、プロセスの改善に対するチームの関与が著しく改善されていることを確認しました。私たちは完全にカイゼンではありませんが、毎日良くなっています。

Answer 8

キー パフォーマンス インジケーターの最適な用途は、運転(または必要に応じてステアリング) です。リアルタイムでの進路修正用。

(このサブトピックの詳細については、「ダッシュボードは運転用です」を参照してください。注意: 私はこの記事の著者です。)

それで、あなたに返される質問は次のとおりです。あなたは事後的にパフォーマンスを評価しようとしていますか、それについて何かをするのに遅すぎるときですか、それとも軌道に乗るのに役立つKPIを見つけようとしていますか?

前者の場合、組織が関心を持っている指標 (バグ数、出荷日の遅れ、コメント付きのコード行、顧客返品率など) は問題ありません。製品を出荷してからアップグレードするまでの間に、距離を測って頑張ってください;-)

後者の場合は、velocityを選択します。もちろん、テスト駆動開発 (TDD) を使用していると仮定します。

編集：それは前者です。さて、あなたがおそらく運が悪い理由は次のとおりです。

後処理 KPI として顧客から報告されたバグの数を測定することによって、"品質" を定量化するのが最適であると判断したとします。TDD を使用していて、チームが製品 #1 を 6 か月で納品し、現場で 6 か月後に顧客から報告されたバグが 10 件あることに気付いたとします。では、プロセスを改善するために正確に何をするつもりですか? もっとテストしますか？報告されたバグの原因などについて、具体的にテストしますか? すでにテストを行っており、バグが発見された場合 (顧客によるかどうかに関係なく)、特定のバグに対する回帰テストと追加の単体テストを追加して、類似のバグがこれ以上ないことを確認します。言い換えると、であるため、この KPI は、プロセスの改善にはほとんど役に立ちません。ポイントは、バグがリリースから 6 か月後に発見された場合でも、コーディングの 2 日後に発見された場合でも、プロセスを改善する方法は同じであるということです。したがって、これはマネージャーの壁や部門のニュースレターに載せる輝かしい KPI かもしれませんが、プロセス改善メカニズムを実際に変更することはありません。(そして、この KPI は自分では制御できない要因によって大きく影響を受ける可能性があるため、この KPI に過度に投資しないように注意してください!)。つまり、バグの数を知っていても、改善には役立ちません。

(ここには別の危険があり、それはビジネスだけでなく軍隊でも一般的に見られるものであり、事後分析によって貴重な情報が明らかになったという錯覚です。そのため、事後分析で学んだ教訓は次のプロジェクトに積極的に適用されます。これはおそらく最後のプロジェクトと同じではありません.これは「最後の戦争を戦う」として知られています.)

顧客の返品/返金の数が「品質」の選択した KPI であるとします。この数が 5 の場合、これは何を示していますか? 顧客が返金を要求した具体的な理由は、品質上の問題 (「遅すぎる」、「XYZ システムとインターフェースしない」など) を示している可能性がありますが、そのような事例の数だけでは何もわかりません。期待される返品率に対する差異は、品質が向上しているかどうかを示す場合がありますが、この数値は改善には役立ちません。数字から得られる以上の情報が必要です。

では、「リリースの適時性」については、どのような測定が適切でしょうか? 出荷遅延日数は？元の見積もりに基づくオーバーランの割合は? 数字は改善に役立たないので、それは問題ではありません。

製品が完成した後に「生産性」を測定できる場合は、おそらく製品の開発中に測定できます (速度など)。違いは、開発中に予想よりも低い生産性がすぐに改善され、全体的な生産性の数値が測定されることです。開発が完了した後は、粗すぎて平均的すぎて、何の役にも立ちません。6か月後に予想を下回った理由は推測することしかできませんでした...

マーケティングの専門用語のように聞こえる「柔軟性」をどのように測定するのか、私にはわかりません ;-)

この釘を強く打ちすぎていないことを願っていますが、進行中に測定できない事後測定できる有用なものはないと思います. そして、原因がわからないままでは役に立たない事後測定がたくさんあります。

Answer 9

http://www.dashboardzone.comで、KPI とダッシュボードの例に関する多くのアイデアを得ることができます。

業種別、機能別のKPIがあります。