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

by ryurock

Slide 1

Slide 1 text

プロダクトマネジメントプロセス概要「速さ」と「価値」を届けるための考え方 VERSION 1.3 2024.2.28 @ryurock SRE アーキテクチャ USE TEMPLATE Click 1

Slide 2

Slide 2 text

自己紹介 Click 2 木村竜介 (@ryurock) SRE アーキテクチャ高校卒業後、クライミングにハマりフリーターをしながら海外クライミングに明け暮れる。その後、システムエンジニアとして様々な業務に従事。ここ７年ほどは SRE 領域を主戦場としている。システムリアーキテクトや SRE チームの立ち上げ等、ハード(技術)とソフト(組織)の両軸から戦略を考える事を得意としている。

Slide 3

Slide 3 text

Agenda 3 ➔ 01 プロダクトマネジメントプロセス ◆ どのように要求がくるのか？ ➔ 02 どのようにプロセスを整理するのか？ ◆ 「ムダ」、「ムラ」を減らすためのアプローチ ➔ 03 何を計測するのか？ ◆ 生産性と事業指標の 2 軸で考える

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

5 01 プロダクトマネジメントプロセスどのように要求がくるのか？

Slide 6

Slide 6 text

01 プロダクトマネジメントプロセス 6 Sales Inside Sales Customer Success Marketing Field Sales Product Developement Team リード獲得リード育成リード選定商談受注・契約オンボーディングカスタマーサポートコンサルティングトレーニング課題解決 Issue 要望解決 Feature 運用・保守 Maintenance 障害 Hotﬁx Product Development Continuance Development 各役割のフロー

Slide 7

Slide 7 text

7 Sales Inside Sales Customer Success Marketing Field Sales Product Developement Team 課題 Issue 要望 Feature 運用・保守 Maintenance 障害 Hotﬁx Product Development Features & Issues Continuance Development Maintenance & Hotﬁx 課題 Issue 要望 Feature Marketing Product Features & Issues 課題 Issue 要望 Feature Sales Product Features & Issues 課題 Issue 要望 Feature Customer Product Features & Issues 各役割からくる要望と課題の関係 01 プロダクトマネジメントプロセス

Slide 8

Slide 8 text

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 利用前ユーザー

Slide 9

Slide 9 text

9 課題 Issue 要望 Feature Sales Product Features & Issues 課題 Issue 要望 Feature Customer Product Features & Issues 開発部門は、サービスの安定性に割く時間が常になくメンテナンスコストが取りづらい 01 プロダクトマネジメントプロセス Many Features & Issues Few Maintenance & Hotﬁx 課題 Issue 要望 Feature Marketing Product Features & Issues Sales Inside Sales Customer Success Field Sales etc.. 声の相対量に勝てないソフトウェアの安定性算出しやすいサービスのプラスの価値に対して、算出しづらいマイナスの価値は、専門家(エンジニア)しかわからない。

Slide 10

Slide 10 text

Click 10 サービスの不安定さは、カスタマーサクセスのコスト増大や KPI の指標に影響する経営指標や売上原価に影響するカスタマーサクセスは、売上原価に計上されることが多い。また SaaS 等の重要な指標として扱われる LTV やチャーンレートにも影響する。サービスが不安定カスタマーサクセスのコストの増大 LTV (顧客生涯価値) チャーンレート (解約率) 01 プロダクトマネジメントプロセス

Slide 11

Slide 11 text

11 システムやアーキテクトのカイゼンは開発部門の問題だけではない参考: 経済産業省デジタルガバナンス・コード2.0 時代変化の中で、持続的な企業価値の向上を図っていくためには、 ① IT システムとビジネスを一体的に捉え、新たな価値創造に向けた戦略を描いていくこと ② デジタルの力を、効率化・省力化を目指したITによる既存ビジネスの改善にとどまらず、新たな収益につながる既存ビジネスの付加価値向上や新規デジタルビジネスの創出に振り向けること ③ ビジネスの持続性確保のため、IT システムについて技術的負債となることを防ぎ、計画的なパフォーマンス向上を図っていくこと ④ 必要な変革を行うため、IT 部門、DX 部門、事業部門、経営企画部門など組織横断的に取り組むことが重要であり、企業全体の組織構造や文化の改革、中長期的な投資を行う観点から、経営者の関与が不可欠なものである。持続的な価値を創出するためには 01 プロダクトマネジメントプロセス

Slide 12

Slide 12 text

12 どのようにプロセスを整理するのか？

Slide 13

Slide 13 text

13 01 スプリントサイクル「ムダ」、「ムラ」を減らすためのアプローチ

Slide 14

Slide 14 text

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 スプリントサイクル

Slide 15

Slide 15 text

15 02 スプリントサイクルの「計画」顧客が本当にほしいものは何か？を精査する

Slide 16

Slide 16 text

16 Developer 課題 Issue 要望 Feature 運用・保守 Maintenance 障害 Hotﬁx Product Development Features & Issues Continuance Development Maintenance & Hotﬁx 課題 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 計画

Slide 17

Slide 17 text

17 Minispec 価値 Value 問題 Problem Product Problem & Value 解決すべき課題ユーザーボイスユーザーストーリー (Why) を記載するバリュー代替案等 (Who) を記載する (What) 何をしたいのか？を記載する (Value) 得られるものは何か？を記載する (Replacement) 他に実現方法はないか？を記載する要望 Feature 要望 Feature 課題 Issues 声の量を分析する本当の声を分析するプロダクトに求めているストーリーを記載するどの KPI 指標がどのくらいカイゼンされるか？の仮説を記載するスプレッドシートで代替できる他の機能で代替できる等 02 スプリントサイクルの「計画」要望 Feature 要望 Feature 要望 Features 計画

Slide 18

Slide 18 text

18 生産性 vs 売上の対立構造を避けるためには生産性を証明する難しさから逃げないこと 02 スプリントサイクルの「計画」計画運用・保守コスト生産性売上見込み売上目に見えやすい領域売上等を目標に持つ部門効率性等を目標に持つ部門バリュー得られるものは何か？ 1 年で 2000 万円の売上見込バリュー得られるものは何か？そもそも見込みが計算しづらい対立構造が生まれがち目に見えづらい領域スピード (生産性) 工数販管費一人当たり月 20 h のコスト一人当たり月 15 h 削減 Before 1.5 人月 After 1.2 人月 Before xxx 円 After xxx 円運用・保守 Maintenance 要望 Feature

Slide 19

Slide 19 text

19 価値の「速さ」は生産性の「速さ」に依存する 02 スプリントサイクルの「計画」計画バリュー A 1 年で 2000 万円の売上見込スピード (生産性) 工数一人当たり月 20 h のコスト一人当たり月 15 h 削減 Before 1.5 人月 After 1.2 人月課題 Issue 要望 Feature Product Development Features & Issues 運用・保守 Maintenance 障害 Hotﬁx Continuance Development Maintenance & Hotﬁx 速さ (生産性) バリュー B 1 年で 1000 万円の売上見込速さ(価値) 依存影響

Slide 20

Slide 20 text

20 03 スプリントサイクルの「要件定義とデザイン」ビジネス要求をソフトウェア要求に変換する

Slide 21

Slide 21 text

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 バックログ全体の難易度を記載する

Slide 22

Slide 22 text

22 Minispec からシステム要求に変換して要素分解をする文章と会話で考える時間を確保する会話とドキュメントを通して、声を聞く時間や価値を考える時間で本当に必要なものは何か？の気づきを与える。重要なのは、ムダなものを作らない事また、持続的なサービスの開発には、ドキュメントをしっかり整えることが重要。 03 スプリントサイクルの「要件定義とデザイン」要件定義・デザイン Minispec 課題 Issue 要望 Feature Product Features & Issues DesignDoc Backlog Backlog Backlog Product Developement Team Minispec 提案者会話をする 2 Weeks

Slide 23

Slide 23 text

23 Point で難易度を記載するリリースを意識する「実装 → QA → リリース」のサイクルにリリースが入るので、リリースできるようにスコープを調整する。 03 スプリントサイクルの「要件定義とデザイン」 Minispec DesignDoc Backlog Backlog Backlog 高低 Point 30 pt? 15 pt? 合計Point 高低優先順位要件定義・デザイン 2 Weeks

Slide 24

Slide 24 text

24 やってみないとわからないものは技術スパイクを済ませておく Minispec 課題 Issue 要望 Feature Product Features & Issues DesignDoc 03 スプリントサイクルの「要件定義とデザイン」 Product Developement Team やってみないとわからない... 技術スパイク新しい技術や調べたりしないとわからない事を少し手を動かしてある程度わかる状態にすること。期限を決めてスパイクをする技術スパイクは永遠と時間をかけてしまうもの。「3 日以内でわかる範囲」等区切りをつけて実施する。目的は Backlog の分解 Backlog Backlog Backlog 要件定義・デザイン 2 Weeks

Slide 25

Slide 25 text

25 全てを並べて Ready な状態にする価値 Value 課題 Problem Product Problem & Value Minispecs 課題 Issue 要望 Feature Product Features & Issues 運用・保守 Maintenance Continuance Development Maintenance DesignDocs 実装のスプリントで収まる範囲か？チームの Point 消化率を分析して実装のスプリントで収まるように調整する。帳尻が合わない場合は、スコープを調整する。 03 スプリントサイクルの「要件定義とデザイン」安定 or 挑戦の認識をあわせる必ずしもスプリント内で終わらせる事が正しい事ではない。意欲的な挑戦には、失敗がつきもの。最後に挑戦的なスプリントか？をチームで認識しておく。要件定義・デザイン 2 Weeks

Slide 26

Slide 26 text

26 見積もりは大概当たらないが、事業責任者は投資に対する ROI で得られる価値で判断する大概の事業責任者は脳内でバッファを入れている概算見積もり時点での工期と実際の工数のブレが感覚的にあるので、実際に事業計画を立てる時に初期時点の工期にバッファを足して事業計画を立てている。 Developer 事業責任者ジレンマ工期が遅れる事実を知っている事業計画のプレッシャー 03 スプリントサイクルの「要件定義とデザイン」要件定義・デザイン

Slide 27

Slide 27 text

27 見直すべきは、不確実性の幅を小さくする事 Developer 事業責任者工期と工数のブレ幅を小さくする解決すべき課題工数のかかる事業計画の修正の「ムダ」と「ムラ」を減らす解決すべき課題初期時点の工期のブレの大きな要因になる追加仕様を要求時点で小さくするのと要求変更によるスケジュール修正の「ムダ」と「ムラ」を減らす 03 スプリントサイクルの「要件定義とデザイン」要件定義・デザイン

Slide 28

Slide 28 text

28 見直すべきは、不確実性の幅を小さくする事 03 スプリントサイクルの「要件定義とデザイン」 DesignDoc Minispec YAGNI 原則 You ain't gonna need it 機能は実際に必要となるまでは追加しないのが良い KISS の原則 Keep it simple stupid シンプルで愚直にする。必要な複雑さを避けてできるだけ簡潔な設計を心がける小さくする要件定義・デザイン

Slide 29

Slide 29 text

29 04 スプリントサイクルの「実装」スプリントゴールに向かって走る

Slide 30

Slide 30 text

30 モブプログラミング等でチーム一丸となってスプリントを達成する知識の差を埋める Team メンバーには、ドメイン知識や技術知識の差がある。モブプロ等を通じて、知識の分配がより Team を成長させる。 04 スプリントサイクルの「実装」実装 2 Weeks

Slide 31

Slide 31 text

31 差込は、本当に緊急か見極める 04 スプリントサイクルの「実装」実装 2 Weeks Sprint 2 Weeks 実装リリース QA 計画差込依頼 Product Developement Team 次のスプリントで対応する実装に集中する 2 Weeks フロー状態を意識する差込依頼が本当に緊急か？を実装のスプリントでは見極める。フロー状態を維持することで生産性の「ムラ」と「ムダ」が削減される。

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

33 05 スプリントサイクルの「レビュー」作った成果物からフィードバックをもらう

Slide 34

Slide 34 text

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 動くソフトウェアからのフィードバックが一番大きいのでここで帳尻をあわせる全体のバッファ

Slide 35

Slide 35 text

35 06 どのようにプロセスを整理するのか？まとめ

Slide 36

Slide 36 text

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 (年間の価値)

Slide 37

Slide 37 text

37 プロダクト開発で何を計測するのか？

Slide 38

Slide 38 text

38 01 生産性と事業指標の 2 軸で考える価値の指標とプロセスの指標

Slide 39

Slide 39 text

39 事業の KPI を明示する 01 生産性と事業指標の 2 軸で考える例: SaaS の代表的な KPI MRR ARR ARPU 「成長性」を計測する代表的な KPI LTV CAC ユニットエコノミクス「効率性」を計測する代表的な KPI チャーンレート Active Users NPS 「継続性」を計測する代表的な KPI Minispec バリュー (Value) カイゼンされる指標は何か？を記載する仮説であることを認識する諸説はあるが、一般的に施策に対する成功率は 1/10。ただ、確度を上げていくために仮説に対して結果どうなったか？を計測する必要がある

Slide 40

Slide 40 text

40 生産性を明示する 01 生産性と事業指標の 2 軸で考える例: 生産性の指標 Minispec 提案数 Minispec 採択数提案成功率提案の質と量を計測する予想工期実績の工数見積もりのブレ幅工期と工数の差分を計測する Minispec の仮説実際の KPI の変化仮説の精度価値仮説の精度会社の評価基準にしないこと生産性を測ること自体がそもそも難しい。内的要因はカイゼンできるが、外的要因はカイゼンができない。全ては、「カイゼン目安の指標」として扱うことで心理的安全性が生まれて「ムダ」なプレッシャーがなくなり、数字に対して素直になれる。

Slide 41

Slide 41 text

41 02 「計画」「要件定義・デザイン」の指標価値の指標と工数の指標

Slide 42

Slide 42 text

42 計画で測るべき指標「Minispec 提案数」と「Minispec採択数」 02 「計画」「要件定義・デザイン」の指標計画要件定義・デザイン実装リリース QA Minispec 提案数 Minispec 採択数解決すべき課題ユーザーボイスユーザーストーリーバリュー代替案等 Minispec 提案者カイゼンポイントを見つける提案の質と量を計測する諸説はあるが、一般的に施策に対する成功率は1/10。ただ、確度を上げていくために仮説に対して結果どうなったか？を計測する必要がある Minispecs

Slide 43

Slide 43 text

43 要件定義・デザインで測るべき指標「バッチサイズ」 02 「計画」「要件定義・デザイン」の指標計画要件定義・デザイン実装リリース QA 適切なバッチサイズを測る持続的に価値を届けるためには、「テンポ」を維持する事が重要。 DesignDocs Minispec スコープ数適切なバッチサイズか？を計測する Sprint 総 Point 数 Minispecs ビルドトラップの罠に注意沢山機能を作っても、ユーザーの満足度は上がらない。どれだけ Point 数を消化できたか？ (アウトプット)で成功を計測すると、価値(アウトカム)の本質を見失う。 2 Weeks 実装リリース QA 計画 2 Weeks 4 Weeks以内に収める Sprint Done 率

Slide 44

Slide 44 text

44 ビルドトラップ 02 「計画」「要件定義・デザイン」の指標計画要件定義・デザイン実装リリース QA ネット世代に人気の商品 TV 世代に人気の商品ユーザーが求めているものは？機能を増やせば、ユーザーが喜ぶのではなく、ユーザーが求めるもの (アウトカム)にフォーカスすること参照: Amazon ソニーテレビリモコン参照: Amazon Fire TV Stick 第3世代

Slide 45

Slide 45 text

45 要件定義・デザインで測るべき指標「予想工期」と「実際にかかった工数」 02 「計画」「要件定義・デザイン」の指標計画要件定義・デザイン実装リリース QA 見積もりのブレ幅を計測する要件定義・デザインで計画した予想工期と実際の工数を計測して、不確実性のブレ幅を小さくするためのカイゼンを行えるようにする。 DesignDocs 合計Point 予想工期実際の工数不確実性を小さくするカイゼンポイントを見つける

Slide 46

Slide 46 text

46 部署間のコンフリクトを避けるために数字を変換する 02 「計画」「要件定義・デザイン」の指標計画要件定義・デザイン実装リリース QA Product Developement Team 事業責任者経営者スループット (1人月あたりの生産性) 工数人件費 P/L (販管費) 事業予算変換変換参照: 開発生産性の現在地点～エンシニアリングが及ぼす多角的視点 / Current status of 役割が見るべき指標を理解する事業責任者は、事業予算。経営者は、PL/BS に対する責任があり、その指標で経営判断を行う。チームが見ている指標を変換して上げることでお互いのコンフリクト(衝突)を避けることができる。

Slide 47

Slide 47 text

47 03 「実装」の指標 PDCA の「テンポ」を計測する

Slide 48

Slide 48 text

48 実装で測るべき指標「差込数」と「差込割合」 03 「実装」の指標計画要件定義・デザイン実装リリース QA PDCA サイクルの健全性差込は大きく 2 種類。運用・保守・障害等のサービス維持のための差込。追加要望・課題の優先順位変更による差込。どちらも 0 にはできないが、カイゼンはできる DesignDocs Minispecs 計画されたもの運用・保守 Maintenance 障害 Hotﬁx Continuance Development Maintenance & Hotﬁx 課題 Issue 要望 Feature Product Features & Issues 計画外のもの Backlogs Backlogs Backlogs 運用・保守の差込数要望・課題の差込数

Slide 49

Slide 49 text

49 04 「QA」の指標「外部品質」と「内部品質」を計測する

Slide 50

Slide 50 text

50 QAで測るべき指標「システム/ソフトウェア製品品質」 04 「QA」の指標計画要件定義・デザイン実装リリース QA システム/ソフトウェア製品品質 JIS X 25010:2013（IEC25010：2011）セキュリティ機能適合性性能効率性互換性使用性信頼性保守性移植性機能完全性機能正確性機能適切性時間効率性資源効率性容量満足性共存性相互運用性適切度認識性習得性運用操作性ユーザエラー防止性ユーザインタフェイス快美性アクセシビリティ成熟性可用性障害許容性 (耐故障性) 回復性機密性インテグリティ否認防止性責任追跡性真正性モジュール性再利用性解析性修正性試験性適応性設置性置換性参照: IPA システム・ソフトウェア品質標準 SQuaRE シリーズの歴史と概要

Slide 51

Slide 51 text

51 QAで測るべき指標「外部品質」「内部品質」「セキュリティ」 04 「QA」の指標計画要件定義・デザイン実装リリース QA システム/ソフトウェア製品品質の分類セキュリティ機能適合性性能効率性互換性使用性信頼性保守性移植性外部品質内部品質セキュリティ内部品質が外部品質に影響する外部品質は内部品質に依存して、内部品質は外部品質に影響する。ユーザーが目に見える外部品質をあげるためには、内部品質をあげる事が重要。依存影響

Slide 52

Slide 52 text

52 05 「リリース」の指標「フィードバック」を計測する

Slide 53

Slide 53 text

53 リリースで測るべき指標「フィードバック」 05 「リリース」の指標計画要件定義・デザイン実装リリース QA リッカート尺度 5 段階非常に満足しているやや満足しているどちらともいえないあまり満足していないまったく満足していない高評価中立低評価作り手の思い込みを排除するリッカート尺度 5 段階で客観的意見を聞き出し、製品に反映する。

Slide 54

Slide 54 text

54 まとめ

Slide 55

Slide 55 text

プロダクト開発とは？ Click 55 プロダクトマネジメントプロセスどのように要求がきて、どのような因果関係があるのか？を整理するどのようにプロセスを整理するのか？「速さ」という一つの指標だけにとらわれず、プロセスの「ムラ」と「ムダ」にフォーカスするプロダクト開発で何を計測するのか？「事業 KPI」「生産性 KPI」にフォーカスする。数字は「カイゼン目安の指標」として扱うことで心理的安全性が生まれて「ムダ」なプレッシャーがなくなり、数字に対して素直になれる。

Slide 56

Slide 56 text

プロダクト開発とは？ Click 56 ムダプロダクト開発のプロセスの「ムダ」を排除する。ムラプロダクト開発の見積もりや仮説の「ムラ」を小さくする全てはサービスの成長を加速させるために

Slide 57

Slide 57 text

参考文献 Click 57 ● 経済産業省デジタルガバナンス・コード2.0 ● ナレッジワークの開発体制 ● 新機能をつくる前に整理しておきたい10のこと ● 不確実性コーンの話 ● SaaS アーキテクチャ概要 ● 開発生産性の現在地点～エンシニアリングが及ぼす多角的視点 / Current status of development productivity ● IPA システム・ソフトウェア品質標準 SQuaRE シリーズの歴史と概要 ● ソフトウェアアーキテクチャメトリクスの基礎: Software architecture metrics in a nutshell