プロダクトマネジメントプロセス概要

より価値を届けていくためにどのようにプロダクトマネジメントをすればよいのか？をまとめてみました。

Transcript

1. プロダクトマネジメント プロセス概要 「速さ」と「価値」を届けるための考え方 VERSION 1.3 2024.2.28 @ryurock SRE アーキテクチャ USE TEMPLATE Click 1
2. 自己紹介 Click 2 木村 竜介 (@ryurock) SRE アーキテクチャ 高校卒業後、クライミングにハマりフリー ターをしながら海外クライミングに明け暮れ る。その後、システムエンジニアとして様々 な業務に従事。ここ７年ほどは SRE 領域を主 戦場としている。 システムリアーキテクトや SRE チームの立ち 上げ等、ハード(技術)とソフト(組織)の両軸か ら戦略を考える事を得意としている。
3. Agenda 3 ➔ 01 プロダクトマネジメントプロセス ◆ どのように要求がくるのか？ ➔ 02 どのようにプロセスを整理するのか？ ◆ 「ムダ」、「ムラ」を減らすためのアプローチ ➔ 03 何を計測するのか？ ◆ 生産性と事業指標の 2 軸で考える
4. 4 プロダクトマネジメントプロセス
5. 5 01 プロダクトマネジメントプロセス どのように要求がくるのか？
6. 01 プロダクトマネジメントプロセス 6 Sales Inside Sales Customer Success Marketing Field Sales Product Developement Team リード獲得 リード育成 リード選定 商談 受注・契約 オンボー ディング カスタマー サポート コンサル ティング トレー ニング 課題解決 Issue 要望解決 Feature 運用・保守 Maintenance 障害 Hotfix Product Development Continuance Development 各役割のフロー
7. 7 Sales Inside Sales Customer Success Marketing Field Sales Product Developement Team 課題 Issue 要望 Feature 運用・保守 Maintenance 障害 Hotfix Product Development Features & Issues Continuance Development Maintenance & Hotfix 課題 Issue 要望 Feature Marketing Product Features & Issues 課題 Issue 要望 Feature Sales Product Features & Issues 課題 Issue 要望 Feature Customer Product Features & Issues 各役割からくる要望と課題の関係 01 プロダクトマネジメントプロセス
8. 8 Sales Inside Sales Customer Success Field Sales Product Developement Team 課題 Issue 要望 Feature 運用・保守 Maintenance 障害 Hotfix Product Development Features & Issues Continuance Development Maintenance & Hotfix 課題 Issue 要望 Feature Sales Product Features & Issues 課題 Issue 要望 Feature Customer Product Features & Issues 顧客からの要望は永遠と減らない 01 プロダクトマネジメントプロセス 利用後 ユーザー 利用前 ユーザー Many Features & Issues Few Maintenance & Hotfix Marketing 課題 Issue 要望 Feature Marketing Product Features & Issues 利用前 ユーザー
9. 9 課題 Issue 要望 Feature Sales Product Features & Issues 課題 Issue 要望 Feature Customer Product Features & Issues 開発部門は、サービスの安定性に割く時間が 常になくメンテナンスコストが取りづらい 01 プロダクトマネジメントプロセス Many Features & Issues Few Maintenance & Hotfix 課題 Issue 要望 Feature Marketing Product Features & Issues Sales Inside Sales Customer Success Field Sales etc.. 声の相対量に 勝てない ソフトウェアの安定性 算出しやすいサービスのプラスの価値 に対して、算出しづらいマイナスの 価値は、専門家(エンジニア)しか わからない。
10. Click 10 サービスの不安定さは、カスタマーサクセスの コスト増大や KPI の指標に影響する 経営指標や売上原価に影響する カスタマーサクセスは、売上原価に計上される ことが多い。 また SaaS 等の重要な指標として扱われる LTV やチャーンレートにも影響する。 サービスが 不安定 カスタマーサクセス のコストの増大 LTV (顧客生涯価値) チャーンレート (解約率) 01 プロダクトマネジメントプロセス
11. 11 システムやアーキテクトのカイゼンは 開発部門の問題だけではない 参考: 経済産業省 デジタルガバナンス・コード2.0 時代変化の中で、持続的な企業価値の向上を図っていくためには、 ① IT システムとビジネスを一体的に捉え、新たな価値創造に向けた戦略を描いていくこと ② デジタルの力を、効率化・省力化を目指したITによる既存ビジネスの改善にとどまらず、新たな収益につな がる既存ビジネスの付加価値向上や新規デジタルビジネスの創出に振り向けること ③ ビジネスの持続性確保のため、IT システムについて技術的負債となることを防ぎ、計画的なパフォーマンス 向上を図っていくこと ④ 必要な変革を行うため、IT 部門、DX 部門、事業部門、経営企画部門など組織横断的に取り組むこと が重要であり、企業全体の組織構造や文化の改革、中長期的な投資を行う観点から、経営者の関与が不可欠なも のである。 持続的な価値を創出するためには 01 プロダクトマネジメントプロセス
12. 12 どのようにプロセスを整理するのか？
13. 13 01 スプリントサイクル 「ムダ」、「ムラ」を減らすためのアプローチ
14. 14 スプリントサイクル Sprint 2 Weeks 計画 要件定義・デザイン 2 Weeks 実装 2 Weeks リリース Minispecs DesignDocs QA Sprint Feature Review プロダクトの Feature コンセプトをシェアして 社内フィードバックをもらう Sprint α or β Review プロダクトの α 版または β 版を シェアして 社内フィードバックをもらう Product Release 本番環境に β版 または GA 版をリ リースする 計画 振り返り会 この Sprint の気付きと学びを 振り返り、次の Sprint に向けた カイゼンを議論する スプリント計画 スプリントで次に何をする か？を計画する。 様々な部署の要望や課題を並 べて決める PDCA P C D A 01 スプリントサイクル
15. 15 02 スプリントサイクルの「計画」 顧客が本当にほしいものは何か？を精査する
16. 16 Developer 課題 Issue 要望 Feature 運用・保守 Maintenance 障害 Hotfix Product Development Features & Issues Continuance Development Maintenance & Hotfix 課題 Issue 要望 Feature Sales Product Features & Issues 課題 Issue 要望 Feature Customer Product Features & Issues 各部門の Features & Issues を整理して プロダクトの問題と価値に変換する 02 スプリントサイクルの「計画」 課題 Issue 要望 Feature Product Features & Issues 価値 Value 問題 Problem Product Problem & Value 課題 Issue 要望 Feature Product Development Features & Issues 計画
17. 17 Minispec 価値 Value 問題 Problem Product Problem & Value 解決すべき課題 ユーザーボイス ユーザーストーリー (Why) を記載する バリュー 代替案等 (Who) を記載する (What) 何をしたいのか？を記載する (Value) 得られるものは何か？を記載する (Replacement) 他に実現方法はないか？ を記載する 要望 Feature 要望 Feature 課題 Issues 声の量を分析する 本当の声を分析する プロダクトに求めている ストーリーを記載する どの KPI 指標がどのくらい カイゼンされるか？の仮説を 記載する スプレッドシートで代替できる 他の機能で代替できる等 02 スプリントサイクルの「計画」 要望 Feature 要望 Feature 要望 Features 計画
18. 18 生産性 vs 売上の対立構造を避けるためには 生産性を証明する難しさから逃げないこと 02 スプリントサイクルの「計画」 計画 運用・保守コスト 生産性 売上 見込み 売上 目に見えやすい領域 売上等を目標に持つ部門 効率性等を目標に持つ部門 バリュー 得られるものは何か？ 1 年で 2000 万円の売上見込 バリュー 得られるものは何か？ そもそも見込みが 計算しづらい 対立構造が生まれがち 目に見えづらい領域 スピード (生産性) 工数 販管費 一人当たり 月 20 h のコスト 一人当たり 月 15 h 削減 Before 1.5 人月 After 1.2 人月 Before xxx 円 After xxx 円 運用・保守 Maintenance 要望 Feature
19. 19 価値の「速さ」は生産性の「速さ」に依存する 02 スプリントサイクルの「計画」 計画 バリュー A 1 年で 2000 万円の売上見込 スピード (生産性) 工数 一人当たり 月 20 h のコスト 一人当たり 月 15 h 削減 Before 1.5 人月 After 1.2 人月 課題 Issue 要望 Feature Product Development Features & Issues 運用・保守 Maintenance 障害 Hotfix Continuance Development Maintenance & Hotfix 速さ (生産性) バリュー B 1 年で 1000 万円の売上見込 速さ(価値) 依存 影響
20. 20 03 スプリントサイクルの「要件定義とデザイン」 ビジネス要求をソフトウェア要求に変換する
21. 21 DesignDoc 価値 Value 問題 Problem Product Problem & Value 概要 Overview ユーザーインターフェース User Interface アーキテクチャ Architecture Minispec の URL とソフトウェアで表現するもの やらないこと What not to do リスク Risk GUI, CUI があるならば記載する モデル定義やアーキテクト図等 明確にやらないものが決まっている場合記載する リスク事項があるならば記載する Minispec 課題 Issue 要望 Feature Product Features & Issues 03 スプリントサイクルの「要件定義とデザイン」 要件定義・デザイン ポイント Point バックログ全体の難易度を記載する
22. 22 Minispec からシステム要求に変換して 要素分解をする 文章と会話で考える時間を確保する 会話とドキュメントを通して、声を聞く 時間や価値を考える時間で本当に 必要なものは何か？の気づきを与える。 重要なのは、ムダなものを作らない事 また、持続的なサービスの開発には、 ドキュメントをしっかり整えることが 重要。 03 スプリントサイクルの「要件定義とデザイン」 要件定義・デザイン Minispec 課題 Issue 要望 Feature Product Features & Issues DesignDoc Backlog Backlog Backlog Product Developement Team Minispec 提案者 会話をする 2 Weeks
23. 23 Point で難易度を記載する リリースを意識する 「実装 → QA → リリース」のサイクル にリリースが入るので、リリースできる ようにスコープを調整する。 03 スプリントサイクルの「要件定義とデザイン」 Minispec DesignDoc Backlog Backlog Backlog 高 低 Point 30 pt? 15 pt? 合計Point 高 低 優先順位 要件定義・デザイン 2 Weeks
24. 24 やってみないとわからないものは 技術スパイクを済ませておく Minispec 課題 Issue 要望 Feature Product Features & Issues DesignDoc 03 スプリントサイクルの「要件定義とデザイン」 Product Developement Team やってみないと わからない... 技術スパイク 新しい技術や調べたりしないとわからな い事を少し手を動かしてある程度わかる 状態にすること。 期限を決めてスパイクをする 技術スパイクは永遠と時間をかけてしま うもの。 「3 日以内でわかる範囲」等 区切りをつけて実施する。 目的は Backlog の分解 Backlog Backlog Backlog 要件定義・デザイン 2 Weeks
25. 25 全てを並べて Ready な状態にする 価値 Value 課題 Problem Product Problem & Value Minispecs 課題 Issue 要望 Feature Product Features & Issues 運用・保守 Maintenance Continuance Development Maintenance DesignDocs 実装のスプリントで収まる範囲か？ チームの Point 消化率を分析して 実装のスプリントで収まるように 調整する。 帳尻が合わない場合は、スコープを調整 する。 03 スプリントサイクルの「要件定義とデザイン」 安定 or 挑戦の認識をあわせる 必ずしもスプリント内で終わらせる事が 正しい事ではない。 意欲的な挑戦には、失敗がつきもの。 最後に挑戦的なスプリントか？をチームで 認識しておく。 要件定義・デザイン 2 Weeks
26. 26 見積もりは大概当たらないが、事業責任者は 投資に対する ROI で得られる価値で判断する 大概の事業責任者は脳内でバッファを入れている 概算見積もり時点での工期と実際の工数のブレが 感覚的にあるので、実際に事業計画を立てる時に 初期時点の工期にバッファを足して 事業計画を立てている。 Developer 事業責任者 ジレンマ 工期が遅れる 事実を知っている 事業計画の プレッシャー 03 スプリントサイクルの「要件定義とデザイン」 要件定義・デザイン
27. 27 見直すべきは、不確実性の幅を小さくする事 Developer 事業責任者 工期と工数のブレ幅を小さくする 解決すべき課題 工数のかかる 事業計画の修正の「ムダ」と「ムラ」 を減らす 解決すべき課題 初期時点の工期のブレの大きな要因にな る追加仕様を要求時点で小さくするのと 要求変更によるスケジュール修正の 「ムダ」と「ムラ」を減らす 03 スプリントサイクルの「要件定義とデザイン」 要件定義・デザイン
28. 28 見直すべきは、不確実性の幅を小さくする事 03 スプリントサイクルの「要件定義とデザイン」 DesignDoc Minispec YAGNI 原則 You ain't gonna need it 機能は実際に必要となるまでは 追加しないのが良い KISS の 原則 Keep it simple stupid シンプルで愚直にする。 必要な複雑さを避けてできる だけ簡潔な設計を心がける 小さくする 要件定義・デザイン
29. 29 04 スプリントサイクルの「実装」 スプリントゴールに向かって走る
30. 30 モブプログラミング等でチーム一丸となって スプリントを達成する 知識の差を埋める Team メンバーには、 ドメイン知識や技術知識の差がある。 モブプロ等を通じて、知識の分配が より Team を成長させる。 04 スプリントサイクルの「実装」 実装 2 Weeks
31. 31 差込は、本当に緊急か見極める 04 スプリントサイクルの「実装」 実装 2 Weeks Sprint 2 Weeks 実装 リリース QA 計画 差込依頼 Product Developement Team 次のスプリントで対応する 実装に集中する 2 Weeks フロー状態を意識する 差込依頼が本当に緊急か？を実装のスプ リントでは見極める。 フロー状態を維持することで生産性の 「ムラ」と「ムダ」が削減される。
32. 32 スイッチングコストによる生産性の弊害を避ける 04 スプリントサイクルの「実装」 フロー状態になれる時間を調整する 会社の予定や部署間の調整で難しい部分 もあるが、なるべく集中できる状態 「フロー状態」を作れるように調整する 月 火 10:00 予定1 11:00 予定1 12:00 予定2 13:00 予定2 14:00 予定3 15:00 予定3 月 火 10:00 予定1 実装 11:00 予定1 12:00 予定3 13:00 実装 14:00 15:00 予定1 実装 2 Weeks
33. 33 05 スプリントサイクルの「レビュー」 作った成果物からフィードバックをもらう
34. 34 言葉による概念のフィードバックと 動くソフトウェアのフィードバックをもらう Sprint 1 Weeks 要件定義・デザイン 実装 Sprint Feature Review Sprint α or β Review 05 スプリントサイクルの「レビュー」 Sprint Feature Review Minispec で価値を言葉に表して フィードバックをもらう。 1 週目でフィードバックをもらって その翌週にフィードバックの反映がベスト Sprint α or β Review 1 週目でプロトタイプを作りきり、 フィードバックをもらって その翌週にフィードバックの反映が ベスト。 Minispec 計画 2 Weeks 1 Weeks 1 Weeks 1 Weeks リリース QA 計画 1 Weeks 1 Weeks 実装 動くソフトウェア 1 Weeks DesignDoc 動くソフトウェアからの フィードバックが一番 大きいのでここで帳尻を あわせる 全体のバッファ
35. 35 06 どのようにプロセスを整理するのか？ まとめ
36. 36 「ムダ」「ムラ」を減らせば、結果的に市場への 価値を多く届けられる Sprint 2 Weeks 計画 リリース QA 要件 実装 計画 リリース QA 要件 実装 再要件 実装 1 Weeks 当初の計画 実際の現実 Sprint 2 Weeks 2 Weeks 2 Weeks 計画 要件 実装 リリース QA 3 つの価値をまとめて 計画して整理する 3 つの価値を まとめて実装する 「ムダ」「ムラ」 を整理した計画 06 どのようにプロセスを整理するのか？ 6 Weeks で 2つの価値 6 Weeks で 3つの価値 「ムダ」「ムラ」をなくす 計画プロセスと実装プロセスの 「ムダ」と「ムラ」を減らす。 「ムダ」と「ムラ」を減らして価値を多く 創出する。 価値創出は中長期的に考える 「ムダ」と「ムラ」がある場合 2 (価値) x 4.5 (週) = 9 (1ヶ月の価値) 9 (価値) x 12 (月) = 108 (年間の価値) 「ムダ」と「ムラ」が少ない場合 3 (価値) x 4.5 (週) = 13.5 (1ヶ月の価値) 13.5 (価値) x 12 (月) = 162 (年間の価値)
37. 37 プロダクト開発で何を計測するのか？
38. 38 01 生産性と事業指標の 2 軸で考える 価値の指標とプロセスの指標
39. 39 事業の KPI を明示する 01 生産性と事業指標の 2 軸で考える 例: SaaS の代表的な KPI MRR ARR ARPU 「成長性」を計測する 代表的な KPI LTV CAC ユニット エコノミクス 「効率性」を計測する 代表的な KPI チャーン レート Active Users NPS 「継続性」を計測する 代表的な KPI Minispec バリュー (Value) カイゼンされる指標は 何か？を記載する 仮説であることを認識する 諸説はあるが、一般的に施策に対する成功率は 1/10。 ただ、確度を上げていくために仮説に対して結 果どうなったか？を計測する必要がある
40. 40 生産性を明示する 01 生産性と事業指標の 2 軸で考える 例: 生産性の指標 Minispec 提案数 Minispec 採択数 提案成功率 提案の質と量を 計測する 予想工期 実績の工数 見積もりの ブレ幅 工期と工数の差分を 計測する Minispec の 仮説 実際の KPI の変化 仮説の精度 価値仮説の精度 会社の評価基準にしないこと 生産性を測ること自体がそもそも難しい。 内的要因はカイゼンできるが、外的要因はカイゼン ができない。 全ては、「カイゼン目安の指標」として扱うことで 心理的安全性が生まれて「ムダ」なプレッシャーが なくなり、数字に対して素直になれる。
41. 41 02 「計画」「要件定義・デザイン」の指標 価値の指標と工数の指標
42. 42 計画で測るべき指標 「Minispec 提案数」と「Minispec採択数」 02 「計画」「要件定義・デザイン」の指標 計画 要件定義・デザイン 実装 リリース QA Minispec 提案数 Minispec 採択数 解決すべき課題 ユーザーボイス ユーザーストーリー バリュー 代替案等 Minispec 提案者 カイゼンポイントを見つける 提案の質と量を計測する 諸説はあるが、一般的に施策に対する成 功率は1/10。 ただ、確度を上げていくために仮説に対 して結果どうなったか？を計測する必要 がある Minispecs
43. 43 要件定義・デザインで測るべき指標 「バッチサイズ」 02 「計画」「要件定義・デザイン」の指標 計画 要件定義・デザイン 実装 リリース QA 適切なバッチサイズを測る 持続的に価値を届けるためには、 「テンポ」を維持する事が重要。 DesignDocs Minispec スコープ数 適切なバッチサイズか？ を計測する Sprint 総 Point 数 Minispecs ビルドトラップの罠に注意 沢山機能を作っても、ユーザーの満足度 は上がらない。 どれだけ Point 数を消化できたか？ (アウトプット)で成功を計測すると、 価値(アウトカム)の本質を見失う。 2 Weeks 実装 リリース QA 計画 2 Weeks 4 Weeks以内に収める Sprint Done 率
44. 44 ビルドトラップ 02 「計画」「要件定義・デザイン」の指標 計画 要件定義・デザイン 実装 リリース QA ネット世代 に人気の商品 TV 世代 に人気の商品 ユーザーが求めているものは？ 機能を増やせば、ユーザーが喜ぶのでは なく、ユーザーが求めるもの (アウトカム)にフォーカスすること 参照: Amazon ソニーテレビリモコン 参照: Amazon Fire TV Stick 第3世代
45. 45 要件定義・デザインで測るべき指標 「予想工期」と「実際にかかった工数」 02 「計画」「要件定義・デザイン」の指標 計画 要件定義・デザイン 実装 リリース QA 見積もりのブレ幅を計測する 要件定義・デザインで計画した予想工期 と実際の工数を計測して、不確実性の ブレ幅を小さくするためのカイゼンを 行えるようにする。 DesignDocs 合計Point 予想工期 実際の工数 不確実性を小さくする カイゼンポイントを見つける
46. 46 部署間のコンフリクトを避けるために 数字を変換する 02 「計画」「要件定義・デザイン」の指標 計画 要件定義・デザイン 実装 リリース QA Product Developement Team 事業責任者 経営者 スループット (1人月あたりの 生産性) 工数 人件費 P/L (販管費) 事業 予算 変換 変換 参照: 開発生産性の現在地点～エンシニアリングが及ぼす多角的視点 / Current status of 役割が見るべき指標を理解する 事業責任者は、事業予算。 経営者は、PL/BS に対する責任があり、 その指標で経営判断を行う。 チームが見ている指標を変換して上げる ことでお互いのコンフリクト(衝突)を 避けることができる。
47. 47 03 「実装」の指標 PDCA の「テンポ」を計測する
48. 48 実装で測るべき指標 「差込数」と「差込割合」 03 「実装」の指標 計画 要件定義・デザイン 実装 リリース QA PDCA サイクルの健全性 差込は大きく 2 種類。 運用・保守・障害等のサービス維持の ための差込。 追加要望・課題の優先順位変更による 差込。 どちらも 0 にはできないが、カイゼンは できる DesignDocs Minispecs 計画されたもの 運用・保守 Maintenance 障害 Hotfix Continuance Development Maintenance & Hotfix 課題 Issue 要望 Feature Product Features & Issues 計画外のもの Backlogs Backlogs Backlogs 運用・保守 の差込数 要望・課題 の差込数
49. 49 04 「QA」の指標 「外部品質」 と「内部品質」を計測する
50. 50 QAで測るべき指標 「システム/ソフトウェア製品品質」 04 「QA」の指標 計画 要件定義・デザイン 実装 リリース QA システム/ソフトウェア製品品質 JIS X 25010:2013（IEC25010：2011） セキュリティ 機能適合性 性能効率性 互換性 使用性 信頼性 保守性 移植性 機能完全性 機能正確性 機能適切性 時間効率性 資源効率性 容量満足性 共存性 相互運用性 適切度認識性 習得性 運用操作性 ユーザエラー防 止性 ユーザインタ フェイス快美性 アクセシビリ ティ 成熟性 可用性 障害許容性 (耐故障性) 回復性 機密性 インテグリ ティ 否認防止性 責任追跡性 真正性 モジュール性 再利用性 解析性 修正性 試験性 適応性 設置性 置換性 参照: IPA システム・ソフトウェア品質標準 SQuaRE シリーズの歴史と概要
51. 51 QAで測るべき指標 「外部品質」「内部品質」「セキュリティ」 04 「QA」の指標 計画 要件定義・デザイン 実装 リリース QA システム/ソフトウェア製品品質の分類 セキュリティ 機能適合性 性能効率性 互換性 使用性 信頼性 保守性 移植性 外部品質 内部品質 セキュリティ 内部品質が外部品質に影響する 外部品質は内部品質に依存して、 内部品質は外部品質に影響する。 ユーザーが目に見える外部品質をあげる ためには、内部品質をあげる事が重要。 依存 影響
52. 52 05 「リリース」の指標 「フィードバック」を計測する
53. 53 リリースで測るべき指標 「フィードバック」 05 「リリース」の指標 計画 要件定義・デザイン 実装 リリース QA リッカート尺度 5 段階 非常に満足している やや満足している どちらともいえない あまり満足していない まったく満足していない 高評価 中立 低評価 作り手の思い込みを排除する リッカート尺度 5 段階で客観的意見を 聞き出し、製品に反映する。
54. 54 まとめ
55. プロダクト開発とは？ Click 55 プロダクトマネジメントプロセス どのように要求がきて、どのような因果関係があるのか？を整理する どのようにプロセスを整理するのか？ 「速さ」という一つの指標だけにとらわれず、プロセスの「ムラ」と「ムダ」にフォーカスする プロダクト開発で何を計測するのか？ 「事業 KPI」「生産性 KPI」にフォーカスする。数字は「カイゼン目安の指標」として扱うことで心理的 安全性が生まれて「ムダ」なプレッシャーがなくなり、数字に対して素直になれる。
56. プロダクト開発とは？ Click 56 ムダ プロダクト開発のプロセスの「ムダ」を排除する。 ムラ プロダクト開発の見積もりや仮説の「ムラ」を小さくする 全てはサービスの成長を加速させるために
57. 参考文献 Click 57 • 経済産業省 デジタルガバナンス・コード2.0 • ナレッジワークの開発体制 • 新機能をつくる前に整理しておきたい10のこと • 不確実性コーンの話 • SaaS アーキテクチャ概要 • 開発生産性の現在地点～エンシニアリングが及ぼす多角的視点 / Current status of development productivity • IPA システム・ソフトウェア品質標準 SQuaRE シリーズの歴史と概要 • ソフトウェアアーキテクチャメトリクスの基礎: Software architecture metrics in a nutshell