Value Stream ManagementとDevOpsの実現 ～前編～

Value Streamという言葉はトヨタ生産方式で提唱された考え方で、システム開発においても　Lean開発手法に引き継がれて現在でも活用されています。

システム開発の方式がウォーターフォール型からAgile型へ変化し、そして開発と運用が連動するDevOpsが求められる現在、Value Streamの重要性は更に大きくなっていると感じています。

～ Value Stream Managementとは ～

VSM Consortium(https://www.vsmconsortium.org/)によると

”バリューストリームマネジメントは、アイデアから開発、生産に至る異種ソフトウェアデリバリーパイプラインにおけるビジネスバリューの流れをマッピングし、可視化、測定、最適化、管理する人、プロセス、テクノロジーの組み合わせである。”

とされています。

IT系の会社であってもそれ以外の業種であっても、課題を持つユーザに価値（Value）を届けることを目的としている訳ですから、その流れをしっかりと把握して正しくかつ効率よく流れるようにすることが出来れば関係者全てが幸せになることが出来る、という意味だと捉えて良いのではないでしょうか。

Value Stream（価値の流れ）を分析するために、Value Stream Mappingという手法を用いて図を作成する場合もあります。

Value Stream Mapping手法の詳細に関しては、このブログの第三回でとりあげる予定ですので、そちらを参照下さい。

ここで注意が必要なのは、トヨタ生産方式から始まるValue Streamの考え方は工場などでの生産や関連した物流に注目して作られており、我々が扱っているソフトウェアシステムの開発とは同じようには扱えない点です。

車にももちろん設計書が必要であり、構想から設計や実験の工程で多くの努力がなされていることと思いますが、設計書が完成してからはその関連する部品を集めて組み立て完成品を納品する作業が長期間にわたって繰り返されるものであり、トヨタ生産方式ではその生産ラインでのムリ、ムダ、ムラを減らしていこうという取り組みになっています。

対して、システム開発プロジェクトにおいては毎回その要件は異なります。そのため、工程の前半では要件分析から要件定義などシステム設計に多くの工数が必要となります。

このブログで取り上げるのは、システム開発における Digital Value Stream の分析と改善を行う流れの部分です。

～ Value Stream Managementにおける数値化と測定 ～

“If you can’t measure it, you can’t manage it.”

“計測出来ないものは、管理出来ない”

というのは有名なピーター・ドラッカー（Peter Drucker）の言葉です。

ビジネスバリュー（価値）を測定／最適化するにはバリュー（価値）を数値化／可視化する必要がありますので、まずはその数値化の方法を確認してみましょう。

～品質目線での数値化～

～これまでの開発プロジェクトにおける数値化～

コード行数（LOC : Lines Of Code)はシステム・プログラムの規模を図るために使用されていた歴史があり、現在でもニュース等で“数百万行のコードで作成された大規模システム”という表現がされる場合があるくらい、規模の大きさを表すものとして多くの場面で使用されています。

コード行数は単純にソースコードの行を数えただけであり、言ってしまえばコピー＆ペーストで同じような機能を複製して作っていった場合にいくらでも数が増えてしまい、たいして複雑ではないシステムでもLOCの数はやたら大きいものとなってしまう可能性もあります。

類似性チェックツールを使用してコピーされた無駄なソースコードを減らすのも有効であり、ソースコードの複雑さを数値化して一定の値以下に保つことで、システムのメンテナンス性を向上させることも可能です。
ソースコードの複雑さを構造から測るため考え出されたサイクロマティック複雑度は以下のように計算され、関数・メソッド単位での分岐の数からソースコードの複雑度、メンテナンス性などを図る目安にすることが出来ます。

オブジェクト指向言語が主流の現在では、コード行数やサイクロマティック複雑度ではなく「継承の深さ」や「クラス結合、戻り値やインターフェースなどによる結合度計測」によってクラス設計が適切かどうかを判断されているケースも多いかと思います。

また、「カバレッジ率」、「パフォーマンス解析ツール」などの品質基準は、ソースコードやプログラムがあればツールを使って分析することで数値として結果が出ることもあり、明確な指標として使用されている方も多いでしょう。

カバレッジ率にはソースコードの行単位でテスト網羅性を図る「コードカバレッジ」と、テストの件数によってその実行率を図る「テストカバレッジ」があります。

コードカバレッジは更にソースコードのどのレベルでの網羅率を図るかによって「C0（シーゼロ）」「C1（シーワン）」などの計測方法があります。

ツールで最も対応が多いのが「C0（シーゼロ）」カバレッジで、ソースコードの行単位でテストによってどの部分が実行されたのか計測出来るようになっており、「ステートメントカバレッジ」とも呼ばれます。

以下の図では、テストで実行されたステートメントと実行されていないステートメントを色分けして分かりやすく表示しています。また、図の下部ではメソッド単位でのカバレッジ率を表示することでテストの網羅率、進捗率を確認することが出来るようになっています。

以下の図では、要件に紐づいたテストケースが何件あり、その何件がテストに成功しているかを数値によって確認するテストカバレッジによって、要件の完了を確認することが出来るようになっています。

以下の図では、実際にアプリケーションを実行してパフォーマンスを計測し、どのクラスのどのメソッドで一番時間がかかっているのかを分析することが出来るようになっています。

テストに関連した数値の殆どのものは閾値を設けて品質判定基準として使用することも可能なはずです。

今回のまとめ

プロジェクトの管理には数値による見える化が重要であり、そのために使用する品質管理の面での様々な数値化の方法に関して代表的なものを紹介しました。

次回は、システム開発において進捗を管理するための工数の数値化と、Value Stream Managementで使用される価値の数値化に関してお話します。