目次


ソフトウェアを対象としたフロー測定

DevOps のインスツルメンテーション方法

Comments

DevOps とは、リーン手法を適用したものです

DevOps のプラクティスで目指しているのは、IT 運用チームとソフトウェア開発チームをより緊密に統合し、ビジネスからの変更要求に、共同で対応する能力を強化することです。ビジネスからの変更要求には、問題チケットへの対処や、ビジネスに必要な新しいサービスの提供などが挙げられます。DevOps には以下の目標があります。

  • 変更要求に対応して結果が承認されるまでの時間を短縮する
  • 無駄な時間と作業を減らして変更に対処する
  • 運用チームから開発チーム、そしてデプロイメント・チームへと要求を渡すパイプラインを合理化する
  • 組織間で処理能力のバランスを取って変更に対応する

これらの目標は、無駄を省いた (「リーン」と呼ばれます」) コンピューティングの原則を採用する際の目標と同じです。リーンとは、あるプロセスを始めから終わりまで 1 サイクル行うのに要する時間 (リード・タイム) を管理および短縮し、組織の能力を最大限活用してパイプラインを通る材料 (インベントリー) のフローを最適化するための考え方、そして一連の手法であると言えます。バリュー (価値) ストリーム・マッピングなどのリーン可視化手法では、よく引用される「測ることとは知ることである (To Measure Is To Know)」というケルヴィン卿の言葉の影響を受けて、製品フロー測定を取り込んでいます。フロー測定には、インベントリーに関する処理全体の (ブラック・ボックス) 測定と、処理ステップごとの (ホワイト・ボックス) 測定、プロセス時間、バックログでの作業成果物の処理待機時間などがあります。

最近では、DevOps に対する IBM の視点は、当初のスコープから以下の原則へと拡大しています。

  • DevOps とは、継続的ソフトウェア・デリバリーによって、組織が市場機会を捉え、顧客からのフィードバックに対応するまでの時間を短縮するためのエンタープライズ機能である
  • DevOps は、リーンの原則とアジャイルの原則をソフトウェア・デリバリー・ライフサイクル全体および企業全体に広げ、あらゆる部分でフィードバック・サイクルをより充実化する
  • 企業全体をリーンに変換することで、デリバリーの効率性が向上し、継続的なフィードバックによってより効果的な企業運営が実現する
  • DevOps を導入すると、組織はデリバリー速度と信頼できる成果との間でバランスを取れるようになる

こうした視点から、次の原則が浮かび上がってきます。

  • DevOps とは以下のように、ソフトウェアを含めて拡張されたライフサイクルを合理化することである
    • IT: 問題の識別から問題が無事解決されるまで
    • 継続的エンジニアリング: 組み込みソフトウェアの仕様策定から統合が成功するまで
    • 製品開発: 初期発想から市場での成功まで
    • サービス・デリバリー: ビジネスからの要求を受けてから顧客の熱烈な支持を得るまで
  • DevOps とは、これらの領域にリーンの原則とプラクティスを適用することです。

従来、リーン手法が適用されてきたのは、製造工程、バックオフィス・プロセス、ロジスティクスです。これらのプロセスは、DevOps で必要になるプロセスと比べると、予測しやすく、変動性もそれほどありません。しかし、リーン手法をソフトウェアへ適用したり (Poppendieck 夫妻共著、2013年)、知識労働へ適用したり (Odegard 著、2013年) することは、新しいことではありません。この記事では、DevOps を成果物中心のビジネス・プロセスとして扱うことで、既存のプラクティスの適用範囲を拡大します。この成果物中心のビジネス・プロセスという視点によって、リーンのプラクティスと方法を DevOps プロセスに適用できるようになります。

リーンのプラクティスと原則を採用する場合には、ボトルネックと非効率的な部分を検出するために、フロー測定のインスツルメンテーションを行うことが不可欠です。これにより、改善の余地を見つけて対処することが可能になります。この成果物中心の視点による主な利点の 1 つは、フロー測定の指定とインスツルメンテーションが簡単であることです。

以降のセクションでは、成果物中心の視点と、この視点を DevOps に適用する理由について説明することから、成果物中心の視点を適用してフロー測定を指定する方法を学ぶことになります。記事では最後に、プログラム・ステアリングと継続的改善という 2 つの主要な使用モデルについて概説します。

DevOps とは、成果物中心のプロセスです

プロセスを可視化するには、次の 2 つの方法があります。

  • アクティビティー中心: プロセスを実行して作業成果物を作成するために必要な一連の処理とそれらの順序によって、プロセスを記述します。これらの一連の処理とその順序は、フロー・チャートや IDEF 図で適切に記述されます。
  • 成果物中心: 作業成果物とそのライフサイクルによって、プロセスを記述します。作業成果物は、状態遷移を実行するステート・マシンとして扱われます。作業成果物の状態遷移を通して、プロセスの各ステップを指定します。

すべてのプロセスは、作業成果物をそのライフサイクルを通して処理することであると言えますが、成果物中心の視点の場合は、行うべき作業を記述し、アクティビティー中心の視点の場合は、作業を実行するためのステップを記述します。例えば、ソフトウェア開発プロセスを定義する場合、成果物中心の視点では、実行すべきコード・モジュールにとって、ソフトウェア開発プロセスとは何を意味するのかを記述します。一例としては、コードはドロップされて、ビルドされ、システム結合試験に合格しなければならないといった記述です。プログラマーは、コード・モジュールを「設計済み」の状態から「完成」した状態にするように指示されます。この状態遷移を実現するために従うべきステップは、プログラマーには指示されません (つまり、IDE を開き、ファイルを作成し、コーディングを行い、コードをレビューし、ユニット・テストを実行し、バグをドキュメント化するなどの具体的な手順は指示されないということです)。作業の方法を指示されるのを、プログラマー (実際のところ、知識労働者のすべて) が不快に感じるのには正当な理由があります。プログラマーが実施する実際のステップと、各ステップで必要となる作業のレベルを前もって予測することはできません。知識労働には、正確なステップを的確に予測するにはあまりにも大きな変動性が伴います。

通常、リーン手法が適用されるプロセスは、まったく同じか非常によく似た作業成果物の作成を扱うプロセス (製造工程など) です。実際、これらのプロセスでは、生産物のばらつきを最小限に抑えることを目標とします。このようなプロセスには、アクティビティー中心の視点が適しています。例えば、電球を製造しているとしたら、すべての電球は同じであるため、プロセスの各ステップを前もって指定することができます。一方、問題チケットやビジネス要求に対処しているとしたら、そのそれぞれが異なるため、実際のステップも異なる可能性があります。作業者は、ログを徹底的に調べることもあれば、カーネル・ダンプを大量に出力することもあります。問題を再現しようと努力することや、新しいトレースを追加して新しいテスト・スクリプトを実行することもあります。あるいは、実際のステップがこのどれにも該当しない場合さえあります。したがって、リーン手法を DevOps に適用するには、作業成果物やプロセスの変動性を考慮に入れなければなりません。つまり、成果物中心の視点が必要になるというわけです。

成果物中心のプロセスでのバリュー・ストリーム・マッピング

中心的なリーン変換手法の 1 つは、バリュー・ストリーム・マッピングです (図 1 を参照)。バリュー・ストリーム・マップ (VSM) の使用法と、リーン変換を実施する際のメトリクスについては、『トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!』(Rother、Shook、Womack、Jones 共著、1999年) で説明されています。VSM は、以下のようにさまざまな方法で使用することができます。

  • VSM を使用して、関係者の誰もが作業成果物の現状のフローを可視化できるようにします。
  • フロー測定を使用して、どこで時間と作業が無駄に使われているかを特定し、ベースラインと目標を設定します。
  • インプロセス測定を使用して、効率性の改善 (自動化や、付加価値のないアクティビティーを排除するなど) または処理能力の強化によってボトルネックを解消できるかどうかを判断します。
  • この情報を基に、合理化されたフローでの潜在的 VSM を特定します。
  • 現在使用している VSM からターゲットとする VSM に移行するために必要な変更計画を策定します。
  • 継続的改善を導入するために、測定によって進捗状況をモニタリングし、変更計画を調整します。
図 1. 単純なバリュー・ストリーム・マップ
図 1. 単純なバリュー・ストリーム・マップ
図 1. 単純なバリュー・ストリーム・マップ

図 1 は、単純なバリュー・ストリーム・マップの例です。ここには、プロセス・ステップと各ステップでの時間が示されています。一般に、各プロセス・ステップには、そのプロセスを実行するために必要なアクティビティーに関する詳細な説明が関連付けられます。このような、アクティビティーに関する説明は、例えば製造工程の場合は、以下のようなステップで記述することができます。

  1. 在庫から部品を入手する。
  2. 部品にざらつきがないか点検する。
  3. 部品をボール盤治具に配置する。
  4. 15 mm のビットを使用して、ドリルで穴 1 と 4 を開ける。
  5. 22 mm のビットに変える。
  6. ドリルで穴 2 と 3 を開ける。
  7. 部品を取り外す。
  8. スチールウールで穴を磨く。
  9. ・・・

図 1 で使用している記号の意味は、以下のとおりです。

  • 左端にある棚のようなアイコンは、プロセスで使用される部品のインベントリーを表します。
  • Iアイコンは、インベントリーに含まれるアイテムの数です。
  • 点線矢印は、プル矢印です。これは、作業者がインベントリーから部品をプルすることによってステップ 1 が開始されることを表します。
  • その他の矢印は、プッシュ矢印です。これは、1 つのステップを完了した作業者が成果物を次のステップにプッシュすることを意味します。

バリュー・ストリーム・マップを成果物中心のプロセスに適用するには、まず、プロセス成果物を識別するところから始めます。成果物には、その成果物に固有のライフサイクルがあります。ライフサイクルは、開始されてから完了するまでの一連の状態からなります。

例えば、単純なビジネス要求の状態モデルには、以下の段階があります。

  • 提出済み
  • 承認済み
  • 開発済み
  • デプロイ済み
  • 顧客による評価済み

成果物中心の作業では、プロセス・ステップは状態の遷移で構成されるという概念が重要となります。

具体的には、バリュー・ストリーム・マップ内のプロセス・ブロックは、成果物をある状態から次の状態に遷移させる作業を表します。この例では、プロセス・ステップにアクティビティーの説明は関連付けられていませんが、状態遷移を実現するための基準の指定は関連付けられています。

この手法を採用すると、2 つの利点がもたらされます。

  • 作業を行う方法ではなく、行うべき作業を伝えるという目的を果たします。
  • 真に価値を取り込むことができます。成果物がそのライフサイクルを経て進化すると、おそらく価値が高まります。

このマッピングでは、「インベントリー」は特定の状態にある成果物の数であり、「時間」は、特定の状態にある成果物群の経過時間数の統計的傾向によって測定されます。これらの方法については、次のセクションで説明します。

DevOps チームの作業形態により近いバリュー・ストリーム・マップを作成するには、より精巧な状態モデルが必要です。バリュー・ストリーム・マッピングでは、成果物の状態は次のいずれかとなります。

  • 処理中: 割り当てられた数々のリソースの 1 つを使用して状態遷移が行われている最中であることを意味します。
  • 待機中: バックログで、チームによって取得され、状態遷移に影響を及ぼすリソースが割り当てられるのを待機している状態を意味します。

次の DevOps の例を検討してみましょう。ビジネス・アナリストが新しい Web サービスへのニーズがあると判断したとします。ビジネス・アナリストは、その Web サービスの機能を IT 組織に提出します。すると、IT 組織はその機能に優先順位を割り当て、開発チームのバックログに入れます。ある時点で、開発マネージャーが、その機能をバックログから取り出します。この時点で、ソフトウェア・プロセス全体が機能し始めます。この例の場合、ソフトウェア・プロセスは完全にカプセル化されたサブプロセスとして扱われます。最終的に、開発チームが機能を追加してアプリケーションを更新すると、その成果物は、IT チームによってデプロイされるのを、IT チームのバックログで待機する状態になります。IT チームがバックログから取り出した成果物は、再び待機状態になります。今回は、アナリティクス・チームからの顧客フィードバックを待つためです。この例では、デリバリーが済んで顧客による機能の評価が行われた状態が、成果物の最終状態となります。

このソフトウェア・アプリケーションの新機能の例には、以下のフロー状態モデルが考えられます。

  • 優先順位付けのために提出済み (待機中)
  • 検討中 (処理中)
  • 開発承認済み (待機中)
  • 作業中 (処理中)
  • 完了済み (待機中)
  • デプロイ中 (処理中)
  • デプロイ済み (待機中)
  • 顧客による評価中 (処理中)
  • 顧客による評価済み (最終状態)

この例のバリュー・ストリーム・マップは、図 2 のようになります。

図 2. DevOps の例のバリュー・ストリーム・マップ
図 2. DevOps の例のバリュー・ストリーム・マップ
図 2. DevOps の例のバリュー・ストリーム・マップ

上記のバリュー・ストリーム・マップでは、以下の点に注目してください。

  • プロセス・ブロックは、状態遷移に対応しています。
  • インベントリー (つまり、バックログ) は、待機状態にある成果物です。
  • チームは、自分のチームのバックログから成果物をプルし、次のチームのバックログに成果物をプッシュします。
  • プッシュは、アップストリームの方向に行われることもあります (実際、これはよくあることです)。例えば、デプロイ時のテストに失敗した新機能は、開発チームのバックログにプッシュされて戻されます。

バリュー・ストリーム・マップを使用するといっても、決してウォーターフォール型プロセスを意味するわけではありません。ただし、さまざまなプロセスに伴う非効率性を示すために、バリュー・ストリーム・マップを使用することはできます。一例として、従来のウォーターフォール型プロセスでは、次のフェーズを待機する成果物が一連のバックログに積み重ねられます。すべてのコードが収集されると、例えばシステム・テストを待機中の状態になります。バリュー・ストリームは、チームが従っているプロセスが何であれ、そのプロセスでの作業の流れを理解するために使用されます。

測定

図 3 を見るとわかるように、バリュー・ストリーム・マップには 2 種類の測定が含まれます。

  • ストリーム測定: 状態遷移によって成果物がどのようになっていくかを測定します。測定対象には、処理全体の時間 (リード・タイム)、プロセスにおける各状態の時間 (一番下の線)、文字 I で示された各状態 (記号) の成果物数などが含まれます。
  • 処理中の測定: 状態遷移を実行時の、チームの効率性を測定します。これらの測定により、処理能力の不足や非効率的なプロセスが原因で、ボトルネックが生じていないかを調べます。図のプロセス・ブロック内の黄色いボックスが、プロセスの非効率性を測定します。
図 3. バリュー・ストリーム・マップでの測定
図 3. バリュー・ストリーム・マップでの測定
図 3. バリュー・ストリーム・マップでの測定

ストリーム測定とプロセス測定は併せて使用されます。ストリーム測定によって注意を必要とするプロセスを特定し、プロセス・ブロックの測定によって、プロセスをどう改善できる可能性があるかを明らかにします。例えば、あるプロセス・ステップでボトルネックを発見した場合、チームの処理能力が十分であるかどうかを検討します。それと同時に、プロセスの合理化、プロセスの自動化、あるいはその両方によって無駄な作業を取り除くことで、そのボトルネックに対処できる可能性を探ります。

ストリーム測定

リーンな組織は、インベントリーを最小限に抑え、明示的にバックログを管理し、バッチ・サイズをチームの処理能力に合わせるものです。これらのリーンのプラクティスがもたらすメリットについては、『The Principles of Product Development Flow: Second Generation Lean Product Development』(Reinertsen 著、2012年) で説明されています。リーンのプラクティスは、製造工程、バックオフィスの基幹システム、ロジスティクスで十分に確立されています。リーンの目標を達成する目的でリーンのプラクティスを導入するのに必要な情報は、ストリーム測定によって提供されます。

ストリーム測定には、次の 2 種類があります。

  • ボリューム: 各種状態のアイテム数の傾向。これらの測定により、フロー内のボトルネックが明らかになります。
  • 時間: 成果物がフローの各種状態で費やした時間、またはフローの状態の組み合わせで費やした時間の統計的傾向。

ボリューム測定

ボリューム測定は比較的簡単です。ボリューム測定は、待機状態および処理中の状態のそれぞれにあるアイテム数の傾向を示します。図 4 に、グラフの例を示します。

図 4. 特定の状態にある作業アイテム数の傾向
図 4
図 4

時間測定

時間測定は、ボリューム測定よりも興味深い点があります。ある特定の状態または状態の組み合わせで費やす時間は、それぞれの成果物によって異なる可能性があります。この変動性は、ソフトウェアに本来伴うものであり、プロセスを制御できていないために生じるものではありません。製造工程の場合、すべての作業成果物は同じであることが求められ、差異は調整する必要がある領域を示しますが、それとは異なり、ソフトウェアの場合の作業成果物はそれぞれに異なるため、時間と作業に差異が生じるのは当然とされています。

こうした理由から、フロー原則をソフトウェア開発に適用する場合に重要な要素の 1 つとして、作業成果物がキューに到着する時間は常に変動することが挙げられます。また、状態遷移を成立させるための作業のレベルにも差があります。

特定の母集団からの成果物がある特定の状態で費やした時間を測定するということなので、時間の母集団を統計的に測定する必要があります。製造工程での作業成果物は同様であるため、標準の統計としては平均時間が使用されます。チームは、バックログにある平均経過時間のアイテム、または作業が進行中のアイテムを追跡する場合もあります。

製造工程での成果物はすべて同じです。したがって通常は、時間の分布は 1 つの値の近くに集まっていて、差異は少ないことが想定されます。より正確に言うと、時間の分布は、標準偏差の幅が狭い正規分布 (ガウス分布とも呼ばれます) にモデル化されます。この場合、分布の平均がとても役に立ちます。製造工程のワークフローでは、製品はほぼ同一だからです。一方、ソフトウェアを作成する場合は、すべてのアプリケーションがそれぞれに異なります。ソフトウェアでの時間の分布は、通常、正規分布ではなく、標準偏差の幅も狭くありません。IBM の調査では、図 5 のような分布になることがわかっています。

図 5. 標準的なサイクル・タイムの統計。矢印は T80 ポイントを示しています。
特定の状態で費やした日数ごとのアイテム数を示す棒グラフ
特定の状態で費やした日数ごとのアイテム数を示す棒グラフ

この分布は意外に思えるかもしれませんが、ピークが左軸の近くにあると見込むのは妥当です。アイテムのほとんどは短時間で対処されますが、なかには、ある状態に長時間とどまるアイテムもあります。測定点としての賢明な選択は、80 パーセントのポイント (T80) です。このポイントは、現在の状態にある成果物群のうち、T80 以下の経過時間となっている成果物は 80% であることを意味します。経過時間が T80 を超えている他の成果物は、分布の裾に該当します。T80 ポイントを使用することで、成果物がバックログで費やす時間、または状態遷移で費やす時間について、傾向を一定期間にわたって測定することができます。

さらに微妙な問題について検討しましょう。それは、作業成果物はそれぞれ異なるため、成果物に対処するのに必要な時間は、成果物ごとに変わってくるという問題です。作業アイテムは次のチームのバックログに散発的にプッシュされることから、作業成果物が到着する間隔が変化します。このような到着時間に有効な数学モデルは、ポアソン分布です。この状況は、ステーション間での製品フローが安定している製造組立ラインとは異なります。ソフトウェアの場合、特定のステーションでの処理能力が一定であれば、バックログのサイズに差異が現れるのは当然のことです。この差異はライフサイクル全体に広がっていることから、図 5 のようなヒストグラムになっているわけです。

時間の統計的傾向を捉えるには、T80 ポイントの履歴が適しています (図 6 を参照)

図 6. 時間の傾向グラフ
図 6. 時間の傾向グラフ
図 6. 時間の傾向グラフ

測定ループ

ソフトウェア開発の顕著な特性は、製品フローのアップストリームの方向に作業成果物が移動してくる場合がよくあることです。例えば、コード・モジュールが特定のレベルのテストに失敗すると、開発遷移プロセスのバックログにプッシュされて戻されます。このアクションは、ボリュームや全体の時間を測定する方法には影響しません。全体の時間には、成果物が各状態で費やした時間の合計が含まれます。

ただし、個々の状態の経過時間に関する統計については、どのように扱えばよいかという疑問は残ります。成果物には、その状態で費やした時間 (その状態に戻ってからの経過時間) を割り当てるのでしょうか?それとも、ライフサイクル全体でその状態であった合計時間を割り当てるのでしょうか?両方とも重要であるというのが、その答えです。使用目的はそれぞれに異なり、前者は進行中プロセスの調整に使用し、再作業を測定する後者は、プロセス全体を改善するために使用します。

プロセス・ブロックの測定

リーン手法の実践者は、プロセス・ブロック間のフローを測定し、チームの効率性と処理能力を測定します。

成果物中心の作業には、以下の測定が適しています。

  • 要員の可用性 (AOP): 割り当てられた従業員が、状態遷移に実際に取り組んだ時間のパーセンテージ。
  • 機器の可用性 (AOE): 割り当てられた機器 (例えば、サーバーなど) が、状態遷移関連の処理に使用された時間のパーセンテージ。
  • 作業コンテンツ時間 (WCT) 実際に状態遷移を行うために費やされた作業のパーセンテージ。
  • 非付加価値時間 (NVA): 作業成果物を進化させることのない処理に費やされた作業のパーセンテージ。

上記の最初の 2 つから、状態遷移に対処するチームの効率性を把握することができます。残りの 2 つからは、チームの処理能力を把握することができます。

情報アーキテクチャーとドリルダウン

ソフトウェアおよびソフトウェア開発において、成果物のステータスは、従属する一連の成果物に左右されることがよくあります。例えば、ビジネスからの要求を分析するシステム・アーキテクトが、一連の計画アイテムを生成して、1 つ以上の開発チームに割り当てるとします。割り当てられた計画アイテムは、さらに詳細なユーザー・ストーリーにされて、コード・モジュールという形になります。コード・モジュールは、システムのテストおよびリリースに向けてビルドされます。出来上がったコードが当初のビジネス要求にどれだけ近いものであるかを判断するには、そのステータス、子成果物 (ユーザー・ストーリー、コード・モジュール、テスト・ケース) の状態、そしてこれらの成果物のアプリケーションおよびリリースへの統合を把握する必要があります。同様に、子成果物のフローにおけるボトルネックが原因で、ビジネス要求やいずれかの計画アイテムを実現する上でボトルネックが生じる可能性もあります。例えば、新機能の実現に関する状態は、コード・モジュールの状態に左右されます。新機能を実現するために必要なモジュールをすべて特定し、それらのモジュールのすべてが開発中の状態になって初めて、新機能を開発中であると言うことができます。そして、すべてのモジュールがコーディングされて変更セットに統合されるまでは、その機能は完成しません。

このことから、成果物のストリーム測定をサポートするためのクエリーには、成果物の情報アーキテクチャーを取り込むリンクが必要になります。そのため、プロセス・ブロックの注釈には、親成果物と子成果物への参照が含まれます。

測定の使用方法

ビジネスでは、測定を検知および対処のループで用いて、組織を目標達成へと促します。これらの測定を用いることで、リーン・コンピューティングの以下の側面の両方をサポートすることができます。

  • リーン変換
  • リーン・プロジェクトまたはプログラムによるモニタリング

これらの目的をサポートするには、この 2 つの微妙な違いを理解して、測定対象を把握する必要があります。

リーン変換

リーン変換は、一連の運用プラクティス (例えば、以下のアクションなど) を徐々に適用することによって行われます。

  • キューの明示的な管理
  • バッチ・サイズの管理
  • 需要に対する処理能力のバランシング
  • 付加価値のない作業の削減

これらの原則をうまく適用するには、組織の文化を変える必要があります。文化的な問題に対処することが、リーンのプラクティスを適用する際の中心となります (『The Lean Mindset: Ask the Right Question』(Poppendieck夫妻著、2013年))。前述のとおり、バリュー・ストリーム・マップとそのメトリクスは、変換を行う際の共通ツールです。

測定は真実を示します。そのため、プロセスのボトルネック、時間が浪費されている箇所、そして処理能力が余っている可能性のある領域など、改善の可能性を関係者全員が把握することができます。その情報を基に、チームは取るべきステップを判断することができます。実際、測定を用いることで、チームを強化することができます。

リーン変換のケースでは、ターゲットとする一連の遷移に関する一定期間の最新履歴では、組織がどのようなパフォーマンスを行っていたのか、その傾向に注目します。基本的に、答えを出すべき質問は、「成果物 X を状態 A から状態 B にするまでにどれだけの時間がかかるか?」という質問です。この概念を図 7 に示します。測定を用いて、組織を垂直方向で理解します。例えば、複数のチームがある種の成果物の同じ状態遷移を管理している場合は、これらのチームのバックログと状態遷移のパフォーマンスの両方に関する測定を含む集約測定を用いて、組織全体を把握するとともに、チーム同士を比較することを検討してください。

図 7. リーンを導入する場合のストリーム測定
図 7. リーンを導入する場合のストリーム測定
図 7. リーンを導入する場合のストリーム測定

このようなフロー測定を用いることで、ニーズが最も高い箇所に重点を置きながら、徐々にリーン手法を導入することができます。

リーンでのモニタリング

リーンでのモニタリングのケースでは、リーン変換はすでに進行中になっていて、測定フレームワークがすでに配備されていると想定してください。ソフトウェアには変動性が伴うため、ボトルネックに対処できるように、常にフローをモニタリングする必要があります。フローのサイズと時間の統計をモニタリングすることで、管理者とチームが協力して、サブミッションの削減などの微調整による変更や、開発者をテストに回すなどの一時的なスタッフの役割転換を行うことができます。この場合、状態ペアのそれぞれについて、成果物の数と経過日数を調べなければなりません (図 8 を参照)。

図 8. モニタリングの場合のストリーム測定
図 8. モニタリングの場合のストリーム測定
図 8. モニタリングの場合のストリーム測定

フロー測定は、作業の完了状態を理解するために用いることもできます。プログラムの完全性を判断する最善の方法は、成果物の状態を評価することです。標準的なバーンダウン・チャートは、完成した成果物と進行中の成果物を示すことから、重要な意味を持ちますが、ここには、ライフサイクルを通して進行中の成果物の詳細なステータスは示されません。フロー測定を用いれば、最も時間がかかっている成果物を把握することができます。このようなレポートの重要な特徴は、情報アーキテクチャーを使用して、特定の状態にある時間が長すぎるアイテムをドリルダウンし、従属成果物の進捗状況を明らかにできることです。

まとめ

リーン手法を実装する場合、焦点を当てるのは、作業者ではなく、作業そのものだと言われています。作業成果物とそれらの状態遷移を重視するより、作業を重視するに越した方法はありません。そうすることで、一定の作業成果物のセットを処理する極めて繰り返しの多いプロセスだけではなく、極めて変動性の大きなプロセスにもリーン手法を適用することができます。

状態遷移のインスツルメンテーションをすると、以下の目標を達成するための測定を定義する基礎が提供されます。

  • リーン変換を計画して、その結果を追跡し、DevOps の目標を達成するとともに、DevOps のプラクティスを導入することでもたらされた結果を測定する
  • DevOps 組織をモニタリングして運営する

謝辞

この記事を執筆する上で有用な会話を常にしてくださった Lean Systems Institute の Frode Odegard 氏と、IBM の Cindy Vanepps 氏および Walker Royce 氏に感謝いたします。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=DevOps
ArticleID=983860
ArticleTitle=ソフトウェアを対象としたフロー測定
publish-date=10022014