2015.8.28（金） SWEST’17 セッションS2B 資料1

ソフトウェアプロセス改善手法
さ ぴ っ どSaPID のご紹介
SaPID：Systems analysis / Systems approach based Process Improvement method
株式会社HBA
Software Quasol（Software Quality Solution Service）

安達 賢二 adachi@hba.co.jp
http://www.software-quasol.com/
SaPIDは、株式会社HBAの日本における登録商標です。
本スライド中では、TMおよび（R）は明記しておりません。

安達 賢二（あだちけんじ）
株式会社HBA Quality Solution Service（Quasol）
adachi@hba.co.jp quality-sol@hba.co.jp【経歴】 1987年HBA入社
システム保守・運用・開発業務を経験後、部門品質保証担当、システム監査委員、
全社品質保証担当、全社品質・セキュリティ・環境管理統括責任者、
全社生産革新活動スリーム技術リーダなどを担当。
2012年社内イントレプレナー第一号事業者として品質向上支援コンサル事業を立ち上げ【研究論文や著書】「レビュープロセスの現実的な改善手段の提案」：ソフトウェアテストシンポジウム2006札幌 の他
SPI Japan2007/2011/2012（最優秀賞）/2013（実行委員長賞）
SPES2012（Best Presentation賞）/2013、SQiP2011-SIG7・2013-SIG運営
テスト設計コンテスト2012・2013（準優勝）、派生開発カンファレンス2013、SS2013（最優秀発表
賞） SEC BOOKS『プロセス改善ナビゲーションガイド』～なぜなに編～（2007.3）～プロセス診断活用編～（2007.4） ～虎の巻編～（2009.2） ～自律改善編～（2013.3）
以上、独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター編 共著

ソフトウェアプロセス改善手法SaPID入門

日科技連出版社（2014.3）

VSE標準 導入の手引き JISA標準化部会VSE 標準普及ワーキンググループ共著（2014.4）【その他社外活動】
NPO法人 ソフトウェアテスト技術振興協会（ASTER）理事、JSTQB（テスト技術者資格認定）技術委員、
JaSST北海道実行委員、日本科学技術連盟 SQiPソフトウェア品質委員会 委員、
JCT1/SC7/WG24（Very Small Entities）エキスパート、ソフトウェア・シンポジウム（SS）プログラム
委員、SPINA3CH User Group運営メンバー、6WCSQアジア地域プログラム委員、SQuBOKプロセス改善
調査・研究Grリーダ・TEF（Test Engineer’s Forum）北海道テスト勉強会お世話係 など

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved使用する用語• モデルベース改善
ソフトウェアやシステムの構築や保守・運用に関連するプロ
セスのあり方とその評価方法などを体系的に定めた「プロセスモデル」による評価結果をベースとして改善を行うこと。
代表的なプロセスモデルとしてISO9001・ISO/IEC15504・
CMMI・ITIL・SPEAK-IPA版・Automotive SPICEなどが存在する。

• 個別改善実務管理者や担当者が自ら持つノウハウや経験則にもとづき、現状評価、改善手段導出、改善実施などの一連の対応を進める改善活動方法の総称。
QC７つ道具や新QC７つ道具、なぜなぜ分析などの手法が活用されることも多い。
P.151 P.152

Copyright © Kenji Adachi@HBA Quasol , All Rights Reservedコンテンツ1. SaPID構築の背景
2. SaPID流：改善のあるべき姿
3. SaPIDの全体像と詳細
4. SaPIDの適用と期待効果
5. まとめCopyright © Kenji Adachi@HBA Quasol , All Rights Reservedコンテンツ1. SaPID構築の背景
2. SaPID流：改善のあるべき姿
3. SaPIDの全体像と詳細
4. SaPIDの適用と期待効果
5. まとめCopyright © Kenji Adachi@HBA Quasol , All Rights Reserved

SaPID開発の経緯
1996

プロセスモデル
ベース改善
ISO9001・CMMI等

2000

2010

2005

部門QS
構築・保守・
運用

全社QMS・ISMS・PMS・EMS⇒統合MS
構築・保守・運用

ISO9001：1994
ベースQS

ISO9001：2000ベースQMS＆他MS統合

SW-CMM

CMMI・ISO15504

1997～
障害データ分析に基づく改善2007
プロセスモデル
併用内部監査2005
SA＆なぜな2002～
ぜ併用型改
SA併用型改善善検討・トラSAトレーニング
イアル

個別改善
↓
我流・なぜなぜからシステムズアプ
ローチ（SA）ベースの業務・プロセス改
善へ

2013

2009～
全社事業計画連携
全員参画生産革新：
スリーム

2006～
SAに基づく課題解決・自SO業務
律型業務・プロセス改善
システムズ
アプローチ
型業務改善

SaPID

1993
SA研修受講2000～01
SA研修再受講2011.7SPINA3CH Ver1.0
Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

摘要モデルベース改善がうまくいかない場合の典型的な問題構造
やらされ意

原因

原因が存在すると
結果になりやすい

識をもちやすい
アセスメントや監査
結果は自ら出した
答えではないアセスメントや監査
結果は網羅的で指摘が大量・広範囲になる

評価結果が専門的で難しい全体は見えるが関係性や構造（からくり）は把
握しにくい

適合優先対応＝形式的な改善対応（例：プロセスモデル規定事項に短絡的に合致させる）に終始することが多い
アセスメント・監査＝数週間・改善計画立案＝数週間・改善実対応＝１年～
数年の長い取り組みになることが多い

P.7

実際に改善
を行う現場
の参画を得
にくい。
事務局など
の推進組織
だけがあくせく活動する

結果サイクルを回すほど強化

モデルベース
改善に特化した要素

形骸化しやすい例：やっていることにするなど改善運営が重たい。
改善活動を進める
たびに開発プロセ
スも重くなる。

「改善は面倒で意味がない」という認識を強化なかなか改善効果を実感できない。成功体験を得にくい。

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

個別改善がうまくいかない場合の典型的な問題構造 無計画に
何を効果と
実施する
ことも多い

するか不
明確なまま
進める

問題が発散してどれに取り組むのか収拾
がつかない
内輪の活
動になり
やすい

思いつきで自分が知っている手段を行使しようとする
声の大きな人が決めてしまう
ことも多い

長期化
しやすい

形式対応・断片対応が多くなる

部分最適対応になりやすいサイクルを回すほど強化P.9

特定のDomainに特
化した対応
が多くなる

他チーム・
組織に拡
がりにくい

原因

結果

原因が存在すると
結果になりやすい改善効果が実感できない・成功体験が得ら
れにくい「改善は面倒で意味がない」という認識を強化

不適切な
改善手段
ならロス大

自然消滅しやすい・続かない・根づかない手段が目的化
しやすい

既存スキルとリソース枠の範疇でしか改善できない

摘要

特定の担当
だけが進め
ることになりがち

Copyright © Kenji Adachi@HBA Quasol , All Rights Reservedコンテンツ1. SaPID構築の背景

2. SaPID流：改善のあるべき姿
3. SaPIDの全体像と詳細
4. SaPIDの適用と期待効果
5. まとめCopyright © Kenji Adachi@HBA Quasol , All Rights Reserved

SaPIDで目指すこと①：自律運営＜イメージ＞
各自が自らが関わっている仕事＝ビジネスの経営者になる
ビジネス
ゴール？

外部規格
要求事項

ビジネス価値最大化
責任者
管理者

責任者
管理者

第三者
審査員・監査員・
アセッサなど

改善
推進者

客観的
結果

顧客

リーダ

メンバー
ビジネス
ゴール

現状
分析

やらせる・
やらされる改善

効果
共有
改善
設計

改善
実践

メンバー

メンバー
メンバー

自律運営（自らやる改善）
P.18

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

SaPIDで目指すこと②：ビジネスの有効性・価値向上
ビジネス
価値・
生産性

目指す領域
③有効＆適合SaPIDが目指す
理想の実績線

SaPIDで対応可能
な実績線

現状
最低許容
レベル

▲
①着手

▲
②適合

迷走したモデル
ベース改善の典型的実績線
適合性

P.20

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

SaPIDで目指すこと③：QCD三方よし
製
品
品
質

製
品
品
質

Q

Q

経済性 C・D

QCDトレードオフ

P.21

経済性 C・D

QCD全体の改善（QCD三方よし）

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

SaPIDで目指すこと④：顧客・会社・現場三方よし
現場だけが
楽になる

＜お客様＞
正しいモノを提供して課題を解決する＝お客様に喜んでも
らえる改善

会社だけが
得をする

＜会社＞
顧客が喜び、余計なコストが減る＝利益が上がる
会社がうれしい改善
P.22

三方
よし

お客様だけ
が得をする
会社・現場が疲弊する＜現場＞
品質向上により手戻りが減って余計な工数・期間、苦労が減る＝現場がうれしい改善

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

改善を成功させるために
これまでの試行錯誤時の意図脱却したかったこと

対応方針

指示／受身・他者依存

自律・自立

特定担当のみ対応
別モノ・形式対応

全員参画
業務への組込み

部分最適・適合性優先

ビジネス有効性重視

ロス・消耗が多い
効果実感できない
頓挫・自然消滅

ロス最小・価値蓄積
効果実感獲得価値ある継続
やる気・モチベーション

Copyright © Kenji Adachi@HBA Quasol , All Rights Reservedコンテンツ1. SaPID構築の背景
2. SaPID流：改善のあるべき姿

3. SaPIDの全体像と詳細
4. SaPIDの適用と期待効果
5. まとめCopyright © Kenji Adachi@HBA Quasol , All Rights Reserved

SaPID（さぴっど）
Systems analysis / Systems approach based Process Improvement methoD

ソフトウェア関連業務に携わる組織やチーム、管理者
やエンジニアが期待する成果を得る、そして成長するために、当事者自らがシステムズアプローチを実践しながら段階的にゴールを目指すプロセス改善手法。
システムズアプローチ
対象領域に存在するさまざまな要素の関係性、相互作用全体を一つのシステムと捉え、システム的な思考と各種手法を駆使しながら分析・評価・最適化などの段階（フェーズ）を経て複雑な問題の解決を探る方法論。
問題はさまざまな要素の相互作用・関係性が引き起こしている、という立場で解決策を見出す。
関係者からさまざまな情報（構成要素）を収集して「問題構造図」に表し、関係者間で共有することで自らの背景や現状に対する適切な解決策を探る。

P.22

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

SaPIDの全体像
STAGE 0
ビジネスの現状の共有
STAGE 1
現状把握

STEP 0
ビジネスゴール・成果状況／テーマ共有

STAGE 3
改善の実行

STEP 1
問題洗い出し・引き出し

STEP 2

STEP 3

事実確認・
要素精査

問題分析・
構造化
STAGE 2
改善の
検討

P.16

STEP 7
改善計画
立案

STEP 8STEP 9改善ﾄﾗｲｱﾙと
評価・ﾌｨｰﾄﾞﾊﾞｯｸ

全体適用と評価･ﾌｨｰﾄﾞﾊﾞｯｸ

STEP 4
改善ターゲットの検討・特定STEP 5

STEP 6

改善策の
検討・決定

改善目標の
検討・決定

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

STEP0：ビジネスゴール・成果状況／テーマ共有①ビジネスのあるべき姿と現状の成果を共有
例：P.F.DRUCKERの5つの問い②は当初から必須①は任意（チームの状況でやる／やらないを決める）

Q1：ビジネスのミッションは何か？
Q2：ビジネスの顧客は誰か？
Q3：顧客にとっての価値は何か？
Q4：ビジネスの成果（目指す成果）は何か？
Q5：ビジネスの計画は何か？
自律改善への本質的なアプローチは①：

価値を認識していない仕事を進んで改善する人はいない②ビジネスの問題・課題を洗い出すためのテーマを設定し、共有
例：○○開発プロジェクトの運営と成果について※テーマは、関係者が考慮すべき切り口と範囲を決める意味を持つ
P.33

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

必要に応じてチェックリ
ストを併用すると効果的

STEP1：問題点洗い出し・引き出し
納品後に多
くの障害が
発生

毎日残業＆
休日返上対
応が多い

特にプロジェクト後半に進捗遅延が常態化
した
協力会社A
は危ないの
ではないか

システムテス
ト時に大量バグ検出

プロジェクトの収支が赤字
顧客クレーム
多発

無責任な
奴がいる

開発標準や
各種判定基
準がない

要求事項
が何度も
変更された

役割が長い
間固定されて
いる
実装内容
がバラバラ

設計書は
あったり、な
かったりする

要求事項
の決定が
遅延する
実装・テスト
は担当者の
経験則に任
せている
要求事項は
記録されな
いことが多い
設計書レビュー
では有効な欠陥
指摘が少ない良い・悪いは抜きにして、何が起きているのか、どう感じているのか等をありのまま収集する

P.38

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

STEP2：事実確認・要素精査
納品後に多くの
障害が発生
15件
218人時

毎日残業＆
休日返上対
応が多い
IT以降
平均残業315h/m

顧客クレーム多発

IT以降毎週10日以上の遅延が継続クレーム8件
4回客先説明計画132件→実績208件

協力会社A
は危ないの
ではないか

P.48

プロジェクトの
収支が赤字
対計画150%

特にプロジェクト後半に進捗遅延が常態化

システムテスト時に大量バグ検出

不適切な感覚・感情論などもすべてを手掛かりにして実在する問題・課題を捉える

開発標準や各
種判定基準が
ない

実装内容
がバラバラ
コーディング規約
違反有が57%

設計書はあったり、な
かったりする存在13／対象42

要求事項
の決定が
遅延する
対期日45日遅延

無責任な
奴がいる

要求事項が何度も変更・追加された
記録分のみ

実装・テスト
は担当者の
経験則に任
せている
コード・テストケー
スのレビューなし

要求事項は
記録されな
いことも多い存在15／対象28

変更35・追加42

役割が長い間固定されている
5年間同一担当

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

設計書レビュー
では有効な欠陥
指摘が少ない誤字脱字衍字系指摘が73%

文章表現の原則・禁則（貴重な手掛かり）
文章表現の原則
事実準拠の原則
断定・推測区分の原則
個性化の原則共通理解の原則
具体化の原則一文一義の原則
簡潔性の原則禁則
体言止め・紋切型
不足型・不十分型

対策型
疑問型
断定型・推論型

P.52

内容
事実に即して記載する。
推測を含める場合は事実と分けてはっきりと記載する。
決まり文句や流行語、一般論的な表現を避け、実際に存在する個別事項を記載する。
訴えたいことがそのまま関係者に理解されるように表現する。
抽象的な表現を避け、どのような状態や結果なのかを具体的に把握できるように記載する。
一つの文に一つの内容を記載する。
余計な修飾語や冗長な説明を削り落として簡潔に記載する。
悪い例

適切な見直し方法
モラル
内容を具体化して生々しい出来事を記計画
載する。
レビュー不足不足・不十分となっている内容を具体
テストが不十分的に示す／不足していることで発生している出来事を明確にする。
□□基準が存在しない それがないために発生している困った出来事や状態を記載する。
○ ○ ス キ ル に 問 題 あ 疑問に思った経緯や背景・出来事を具り？
体的に記載する。
Aさんはやる気がない
そう考えた経緯や背景・出来事を具体
最 初 か ら ム リ な 計 画 な 的に記載する。
のではないか？
Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

STEP3：問題分析・構造化

摘要【要約】顧客の言いなりで要求事項が不明確なままプロジェクトを進めているた
め、途中から仕様変更や進捗遅延が多発し、レビューが追い付かず、テストで大量のバグが検出され、 納品後クレームが多発している。

要求事項
の決定が
遅延する
要求事項
が何度も
変更される
要求事項は
記録されな
いことが多い役割が長い間固定されている
P.55

特にプロジェクト後半に進捗遅延が常態化
設計書はあったり、な
かったりする
設計書レビュー
では有効な欠陥
指摘が少ない実装・テスト
は担当者の
経験則に任
せている

原因

結果

原因が存在すると
結果になりやすい

問題発生のメカニズムを見える化し、共有する

毎日残業＆
休日返上対
応が多い

プロジェクトの収支が赤字

システムテス
ト時に大量バ
グ検出

実装内容
がバラバラ
Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

納品後に多
くの障害が
発生
顧客クレー
ム多発

関係者の認識共有が重要

特にSTEP1(0)～STEP4は関係者全員でやり遂げることが重要

改善がうまくいかない要因の一つ：関係者間での合意形成の難しさ

構築する／保守する／運用するシステム（＝対象）や目的・目標、現在の状態、ノウハウ等への関係者間認識共有が重要
組織内のそれぞれの要員が、自分の見ている範疇で対象や目的・目標、現状、ノウハウ等を認識している。
関係者で認識を共有することが成功への大きな一歩となる。

各自はそれぞれの立場で、自分が考えた、聞いた、感じた、身に付けたことを元に自分の認識を持っている
P.59

関係者が対象（の現在状況や求められる本当の姿）に対する認識を合わせる

改善成功への基盤

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

STEP4：改善ターゲット検討・特定
要求事項
の決定が
遅延する
要求事項
が何度も
変更される

要求事項は
記録されな
いことが多い役割が長い間固定されている
立ち位置により見えるもの・感じ
P.62 ることが異なる

他者は変えられない。
でも自分は変えられる。

特にプロジェクト後半に進捗遅延が常態化
設計書はあったり、な
かったりする→自ら打開可能な要因の中から短期間で実現できる費用対効果が高いものを絞り込む【目安：3ヶ月以内に完了】

毎日残業＆
休日返上対
応が多い

プロジェクトの
収支が赤字

改善要因
設計書レビュー
では有効な欠陥
指摘が少ないシステムテス
ト時に大量バグ検出

実装・テスト
は担当者の
経験則に任
せている
実装内容
がバラバラ
Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

納品後に多
くの障害が
発生
顧客クレー
ム多発

改善目的
とする要素

ものづくりの大きな流れ

ある時点で改善要因とする答えは一つではない！
持っている背景や制約によってどこから攻めるのかを決める＆継続して全体を良くしていくことが重要

要求事項の決定が遅延する
要求事項が何度も変更される「根本原因を除去せよ！」
は毒にも薬にもなる

要求事項は記録されないことが多い
設計書はあったり、なかったりする

納品後に多くの障害が発生

設計書レビューでは有効な欠陥指摘が少ない

システムテスト時に大量バグ検出

実装内容が
バラバラ

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

顧客クレーム多発

STEP5-1：改善対象の掘り下げ
設計書レビュー
では有効な欠陥
指摘が少ないレビュー
チェックリストが抽象的レビュー観点はレビューアの解釈で実施要求事項が記述されていない
場合がある
誤字・脱字・
衍字が多い

仕様書の記述内容は担当者
ごとにまちまちP.69

上位問題構造図の改善要因
改善目的要素の現状

有識者が多忙なためほとんど参加できない

後工程でレビューの見逃し／修正
漏れ･ミスを原因②結果内訳とする手戻りが発
の掘り下げ
生している

有効な欠陥指摘が少ないテストや導入後に検出される上位3事項①条件ELSE側不備②エラー処理不備③文字数Max、指定文字以外未考慮①レビュープロセスの掘り下げ
レビュー工数が無駄に多いレビュー結果が残らない

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

レビューの効果を実感できない

STEP5-2：改善手段検討・決定
改善要因
有識者が多忙なためほとんど参加できないレビュー
チェックリストが抽象的レビュー観点はレビューアの解釈で実施要求事項が記以下事項を確実に検出する手段を検討す
述されていないる（現実的で費用対効果＋継続性を考慮場合がある①条件ELSE側不備

有効な欠陥指摘が少ない

レビューの本質的な改善に着手する例

改善目的要素後工程でレビューの見逃し／修正
漏れ･ミスを原因とする手戻りが発
生している
テストや導入後に検出される上位3事項①条件ELSE側不備②エラー処理不備③文字数Max、指定文字以外未考慮②エラー処理不備③文字数Max、指定文字以外未考慮
誤字・脱字・【改善案】衍字が多い①～③を含めた優先確認事項の絞り込み結果と具体的確認
仕様書の記述方法が把握できるチェックリスト
内容は担当者の採用
レビュー工数でまちまち
が無駄に多い

P.70

レビューの効果を実感できない

レビュー結果が残らない

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

STEP5-2：改善手段検討・決定（別解） 先行して無駄な工数を削減し、余裕を確保してから本質的な改善に着手する例

有識者が多忙のためほとんど参加できないレビュー
チェックリストが抽象的レビュー観点はレビューアの解釈で実施要求事項が記述されていない
場合がある

後工程でレビューの見逃し／修正
漏れ･ミスを原因とする手戻りが発生している

有効な欠陥指摘が少ない

改善要因
レビューの効果を実感できない

誤字・脱字・
衍字が多い
仕様書の記述内容は担当者
ごとにまちまち

レビュー工数が無駄に多いレビュー結果が残らない

改善目的要素P.72

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

STEP6：改善目標の検討・決定
改善要因
設計書レビュー
は実施していな
い場合が多い改善目標も個人・チーム・組織の状況に応じて段階的に高度化することが重要
テスト時に大量バグが検出され、想定以上の工数と期間がかかる

施策系改善目標
例１：レビュー実施
例２：レビュー実施率

改善要因

改善目的要素設計書レビュー
は実施していな
い場合が多いテスト時に大量バグが検出され、想定以上の工数と期間がかかる

施策系改善目標
例１：レビュー実施
例２：レビュー実施率

P.78

P.79

成果系改善目標
例１：規模あたりのテスト時バグ検出量減少
例２：規模あたりのテスト工数減少
例３：規模あたりのテスト期間の短縮

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

複合型改善目標設定の例
成果系改善目標
例：規模あたりの①②③
検出量増加

成果系改善目標
例：規模あたりの①②③
検出量減少

改善要因
有識者が多忙なためほとんど参加できないレビュー
チェックリストが抽象的レビュー観点はレビューアの解釈で実施要求事項が記述されていない
場合がある

有効な欠陥指摘が少ない

改善目的要素後工程でレビューの見逃し／修正
漏れ･ミスを原因とする手戻りが発生している
納品後・システムテストで検出される事項

ベスト3①条件ELSE側不備②エラー処理不備③文字数Max、指定文字以外未考慮

レビューの効果を実感できない

以下事項を確実に検出する方法を検討す
誤字・脱字・る（現実的＆費用対効果+継続性を考慮）
衍字が多い①条件ELSE側不備②エラー処理不備③文字数Max、指定文字以外未考慮

仕様書の記述内容は担当者
ごとにまちまちP.80

レビュー工数が無駄に多いレビュー結果が残らない

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

総合的な指標による改善目標設定の例

施策系改善目標
例１：レビュー実施
例２：レビュー実施率
設計書レ
ビューは実施していない場
合が多かった

改善要因
実施した設計書レビューで有効な指摘が出せなかった成果系改善目標
例１：欠陥検出比率の改善（レビュー：テスト＋それ以降）
例２：欠陥対応工数比率の改善（レビュー：テスト＋それ以降）

プロジェクトが大幅な赤字に
なった
テスト時に
大量バグが
検出された

テスト時想定以上の工数と期間がかかり混乱した

成果系改善目標
例１：規模あたりのテスト時バグ検出量減少
例２：規模あたりのテスト工数減少

成果系改善目標例１：有効欠陥指摘数の増加
例２：有効欠陥指摘比率の改善

P.81

体感と定量評価結果が一致していることが重要

改善目的
要素
納品後障害に
より顧客に迷惑をかけた

成果系改善目標
例１：プロジェクト収益の改善
例２：顧客クレーム数の減少

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

改善計画立案段階で初めて様式に書き始めるのは形式対応になりやすいので注意

STEP7：改善計画立案
チーム名：やってみなはれGr

体制

テーマ：○●運営の効果向上＆効率化を目指す□■情報作成～共有方法の改善

出島（L）

安達（SL）

猪股（TL）

1.業務概要△▲部の統括運営・管理を行っています。
部署運営の効果・効率に直結する運営の最適化を目指しています。

2.着目した問題

・内部、外部関係者間で共有、活用する□■情報の作成・修正・共有に手間と時間がかかっている。共有情報が有効活用されていない。部署内で共有情報活用が進まない理由に情報提供のタイムリーさの欠如が存在している。

3.要因と改善方法 要因1：共有情報の作成を元ネタ情報FIX後に手作業で行い、その後再確認、共有、連絡※参照：5.改善前後の運営イメージ

4.改善期待効果
と改善目標

様式記載例

P.84

発信の流れになっている。
→改善方法1：元ネタ情報がFIXするまでの過程で同時並行で作成・関係者確認を行う。
要因2：共有情報が紙媒体のため、ロケーションが離れるとアクセスできない。
→改善方法2：情報を格納する共有フォルダを構築し、そこにテキストコピー可能のPDFで格納し、各関係者がアクセスすることにする。
評価指標

現状
直近2カ月間、対象9回の平均

改善目標

実績
（計画時空欄）①情報作成～共有・関係者連絡までの期間（日数）

5～6日間

0日間（当日完了）

0日間
1.5時間程度②手戻り工数（人時）・問合せ14件
・対応工数7.5人時

0件、0人時に近づける

2件 3分程度③共有情報活用率
39%
80%以上
Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

82%

5.改善前後の運営イメージ （After欄：計画時は想定・完了時は確定した内容を記載）

Before

×実施後対応であるため記録漏れ・受取違いなどによる手戻り対応が発生

開催の1W
～数日前

開催の
数日前
開催案内
（ﾒｰﾙ）

検討・調整

運営実施
資7

１Ｗ程度

通常翌日
～2日後

通常2～3日後

通常3～4日後

通常5～6日後

共有情報
案作成

情報案確認
依頼・調整
（内部）

情報案確認
依頼・調整
（外部）

情報確定配
付（ﾒｰﾙ・ﾌｧｲ
ﾙ添付）

7案

当日資料配付（ある時とない時がある）

After

7

5～6日程度当日の資料を
下さい

共有情報
う活用率
39%
当日の
資料を
下さい

×個別問合せ対応の発生②手戻り工数の低減

開催の1W
～数日前

開催の
数日前

検討・参加
者調整

会議時（０日）
資7

開催案内
（ﾒｰﾙ）

１Ｗ程度

その場で確認

作業実施
情報案
同時作成

情報案確
認依頼・調
整（内部）

情報案確
認依頼・調
整（外部）

情報確定当
日資料を含めて共有・ﾒｰﾙ
連絡のみ

①期間短縮

Ａ7 7

0～1日程度格
納③共有情報活
用率の向上
4

様式記載例

P.84

5

6

資4 資5

共有DiskCopyright © Kenji Adachi@HBA Quasol , All Rights Reserved

7資7６．対応計画・実績
基本計画要素

終了予定日

①現状分析

実績（計画時空欄）
2014/1/20②関係者認識共有～適用準備2014/2/1

2014/2/2③トライアル～トライアル評価

2014/2/3

2014/2/3④全面適用

2014/4/5

2014/4/6⑤全面結果評価

2014/4/6

2014/4/7⑥ふりかえり／関係者認識共有

2014/4/7

2014/4/8

管理者コメント欄 管理名：菅野■計画立案時：2014.1.10
現状分析に時間がかかることが予想されるので、遅れの無い様、進めること■計画見直し時－

７．評価指標・評価方法／達成内容
評価方法

改善後実績
（計画時空欄）

評価指標

現状①情報元ネタFIX日から情報共有・連絡
までの日数

5～6日間
（直近2カ月対象9回の平均）

対象毎に最終打ち合わせ～発行・連絡完了までの日数を確認する。

トライアル：0日
全面適用0日：平均1.5時間（2月～3月対象6回の平均）②手戻り工数（人時）・問合せ14件
・内容不備・疑問12件＋まだ？2件
・対応工数7.5人時（直近2カ月対象9回の平均）

内容の不備、疑問、まだできないの？などの問合せの件数・内容・対応工数を確認する。

トライアル：2件（内容確認2）
対応工数7分
全面適用：2件（内容確認2）
対応工数3分（2月～3月対象6回）③共有情報活用率39%（直近2カ月対象9回）

様式記載例

P.85

現状よりよくなったら効果有とするトライアル：100%
全面適用：82%（2月～3月対象6回）
Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved
対象毎に共有情報の活用有無を関係者全員に確認する。

STEP8：改善トライアルと評価・フィードバック
STEP9：全体適用と評価・フィードバック
トライアルからのフィードバック
改善計画立案・見直し
改善目的・目標、改善活動の内容、体制、役割分担、スケジュールなどの明確化トライアル評価・フィードバック

トライアル～全体適用の実施方法、改善の効果
確認方法の明確化

合 トライアル
意
実施
形
成

トライアル
評価

トライアル
ふりかえり・
フィードバック

トライアルからのフィードバックを反映した改善計画（見直し版）
評価・フィードバック
全体適用

P.89

P.92

全体適用
評価

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

改善活動のふりかえり・
フィードバック改善トライアルの例
時間の流れ

サービス設計フェーズ 作業スケジュール
取扱説明書
試作①

取扱説明書
試作③
取扱説明書
試作④

レビュー

取扱説明書
試作⑤

レビュー

トライアル評価・
フィードバック

トライアル対象

取扱説明書試作 成果物名
改善対象外← ① クイックガイド（ポイントガイドのみ）② 利用者向けガイド（詳細）③ 画像・映像関連操作編④ 音声関連操作編
改善対象⑤ お好みカスタマイズ編⑥ こんな時は（トラブル対応編）⑦ メンテナンスガイド（システム保守編）

レビュー
レビュー

トライアル評価・フィードバック
内容を次のレビューへ展開

予定規模
15 Page
120 Page
80 Page
40 Page
10 Page →これをトライアル対象に選定＜判断要因＞
20 Page・試したい特徴を備えている
130 Page ・規模が小さい
・着手時期が早期

P.88

Copyright © Kenji Adachi@HBA Quasol , All Rights Reservedふりかえりの例

P.109

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved今回のふりかえりの主な観点
A.事例発表会の成果
観点には運営面と成果面の両面を含める
B.実運営面
B1：各種準備・調整対応
構成要素が多い
場合は詳細化
B2：当日の運営対応
B3：終了後～完了までの対応
C.実際に開催して思ったこと、感じたこと
D.その他
観点以外でも受け付ける
P.114

思ったこと・感じたことも大事にする（ただし事実確認が必要）

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

遠慮なく
ほめる

①KEEP：良い点・継続するべき事項 同じ気持ち

には賛同

＜成果＞

＜当日の運営＞

A.○○部みたいに皆で発表者をサポートしようという姿勢が見える

B2.●●Ｊの司会力で、場が和んだ。途なでうまくHＪに質問がないか指名したことなど（い）（同感：あ・い）のは良い。（な）同感：い・あ・な２ ○○ナイスプレー！
C.毎回のことだが、発表資料だけではわからない情報が得られるのでとても良いと思う（い）C.S賞をもらったGrの喜び方を見ると、モチベーション向上につながったのではないかと思う（い）C.受賞者がゴールドリールもモチベーション向上につながったのではないかと思う（い）▼▼さんナイスプレー！
A：レベルが低いながらも、今後につながりそうな内容のグループが複数あったこと、スリームやってたんだということをみんなに思い出してもらったのは一つの成果なのかな。（あ）
Ａ：発表を見るとそのチームの取り組む姿勢が感じられるので、よかった。（む）

成果と過程
の両面で

モチベーション向上！
＜実施準備＞
B1.●●Ｊの事前の各種調整・準備によって表彰までスムーズに進行できた。（い）→実はイントラへのアップや賞金配付等の後作業も大変なのよ（な）B1.S賞候補選定を全員で行ったことで、発表内容の理解にもつながった（い・あ）
B1：事前準備、役員や部門調整が適切だったので、変なストレスや混乱なく実施できた。（あ）
B1:新しい機材（タイマー用のＰＣ、テレビ会議）を使用したが、何のトラブルもなく進められたのが当然だがすばらしい。（な２）B1：実践研修も翌日にあり、作業が重なる中で、協力して進められたことがすばらしい。（む）P.114

準備も協力できた！

（俺、ナイスプレー！）
B2.各自役割を遂行できた（い）B2.休憩時間のとり方がちょうどいいと思う（い）B2：すべてではないものの、事務局で選出した推奨グループの多くが社長賞になった。成果重視・今後の発展重視の視点は役員とも共有できていたのではないか。（あ）

成果や発展重視を共有できてる！
＜終了～完了＞
B3：イベント対応や節目が来ると誰もが「ふりかえりやらなくちゃ」と言いだして実施する、そしてその結果を次の実践で当たり前に使うようになったのはすごいことだ。（あ）同感：ふりかえりをすることが定着した（む）「ふりかえり」が定着しているよ！
＜開催して感じたこと＞
Ｃ.普段あまりプレゼンの機会がない発表者（入社数年の社員）にとって、大勢の前で自分たちがやってきたことをプレゼン・説明することが一種のトレーニングになっているよね！（あ）

プレゼンの機会はトレーニング！

できて当たり前ではなく、できた＝良いこと

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved言いにくいことでもズバッと

メンバー全員参画②PROBLEM：問題事項・改善必要事項→重要事項はTRYで対策
＜成果＞

＜参加者＞

A：改善内容を共有し、それらを参考にして今後に生かすことにつなげる成果にはなっていないよね。（あ）
Ａ：まだまだ、定量的成果としても「効果が出ているなあ～」と実感できるものが少ない。（む）C.相変わらず質問が少なく司会者泣かせ。司会者もツラい（中）B1.９月末納期があって支社や技本は参加しづらいかもしれない。
９月上旬開催の方が良いかも。その代わり活動の立ち上がりを早める必要はある。（な）C.やはり自部門の発表だけ聞いて帰るのは、次の発表者としてはやりづらい？最低限、休憩時間だけの出入りにするなどは必要ないか？（い）
C．役員席の後ろに座るよう何度も促したが、誰も座ろうとしなかった何をいやがっているのかがよく分からない（な２）

成果はまだまだ！
＜事務局運営：実施準備＞
B1.今回は9/1に開催通知を出すことになり、もっと早く出すべきだった。（な）B2.S社長賞が６グループも出たので、次回の賞状が足りなくなった。
忘れずに発注せねば。（な）B1.連絡事項スライド作成完了がギリギリの状態になってしまった（い）
B2.役員の後ろの席は、ほとんど空いている状態。
２Ｆ大会議室で実施する場合、役員の後ろの席はなくして、別のスペースに配置するなどしたい（い）

分類して
まとめる

＜各部門の準備＞C.△本部みたいに発表者以外は誰も参加していないってどうなの？（中、に、あ）
C.9月末だから？発表資料提出が全体的に遅かった（い）＜当日の運営＞
B2.自部門発表だけしか出席しない／質問がほとんどないのは、事例共有（今後の参考に）する気がない、井の中の蛙になっている証
拠だ。（あ）

早め早めの準備が必要だ！

P.115

大事なこと
は強調

入退室は休憩時間のみにすべき！

＜取り組み内容＞

取り組み内容が（安っぽい内容として）完全にパターン化されている。
頭を使っていない証拠。（お）あの内容でS賞６チームは多いかな？モチベーションが上がるのはいいがこの活動でいいんだと思われることが、かえって活動のレベ
ルアップを阻害することにならないかな。（な２）

活動内容のレベルアップを求む！
＜感じたこと＞ 感じたことも忘れずに
Ｃ：S運営がすでに形骸化しつつある、いや形骸化しているように感じた。発表した内容をすべて実践したのかどうか怪しいグループもあった。（あ）Ｃ：□部門の取り組みが・・・どうも目的を理解していない気がする。
この活動で価値を生み出そうという気持ちが感じられない。（む）すでに形骸化していないか？

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

③TRY：主要事項はKeep・ProblemにかかわらずTryに
つなげる
Keep

Try

K1：皆が能動的に動いたので管理能力向上 K1→
目標メンバーあたり“リスク識別3事項”は全 ×：次の能力向上目標を明確化する
員達成！すごいぞ！（あ）○：次の能力向上目標を□□としよう！
P1→△：受け手でも分かる言葉で表現する
ProblemP1：作成者側の言葉で記載されていたため、 ○：成果物レビューチェック観点Keywordに“受け手側の言葉（今回の場合は×非機能
受け手側で理解できず質問が相次いだ。
要求→○性能・レスポンス・使いやすさなど（い）
詳細に）”を追加し、レビュー時に確認する

Tryは次の活動でそのまま使えるレベルに落とし込む
P.116

Copyright © Kenji Adachi@HBA Quasol , All Rights Reservedふりかえり結果（例）Keep K

その場ですぐK1：皆が能動的に動いたので管理能力向上 K1→
目標メンバーあたり“リスク識別3事項”は全 ×：次の能力向上目標を明確化するに次の活動
員達成！すごいぞ！（あ）○：次の能力向上目標を□□としよう！
準備
P1→
Problem P
Try T△：受け手でも分かる言葉で表現する
P1：作成者側の言葉で記載されていたため、 ○：成果物レビューチェック観点Keywordに受け手側で理解できず質問が相次いだ。
“作成者側のローカル言葉”を追加し、レ（い）
ビュー時に確認する

業務プロセスKnow-Howリスト
管理

実施事項
リスク対策
注意事項
H24管理能力向上目標□□

よかったことP
リスク
課題事項
H23能力向上目標全員達成！

設計・実装

受け手が分かる言葉で表現する

Review

Keyword12“作成者側のローカル言葉”

作成者側の言葉で記載されていたた
め、受け手側で理解できず質問が相次いだ。

Process

P.117

T

K

次の活動時にそのまま使う
Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

改善の手ごたえ（実感）「自分にもできる！」「イケそうだ！」「やれそうだ！」 が大事

結果はよい方がBest／しかし悪くても問題なし⇒“今後につながる手ごたえがあったかどうか”
それを“実感できたかどうか”が重要
その実現のために、自ら納得しながら考え（仮説でも構わない）
狙いを定めて打ち抜けたかどうか、その結果（うまくいった、うまくいかなかった）の要因を自ら特定できるかどうかが重要⇒改善計画立案までの過程の踏み方とふりかえりのあり方が問われる
目指す結果・成果をずばり射抜く＆現実的な改善手段の導出
改善対象の粒度は小さく、効果確認までの期間は短く
よかったことも、うまくいかなかったこともふりかえり、実感し次につなげる
P.140

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

短期的な手応え実感の継続が重要
大きな目標を目指すと長期化する
改善そのものに携わる量・頻度、記憶やﾓﾁﾍﾞｰｼｮﾝは薄くなる

大目標
失敗しや
すい改善

SaPID

改善対象1～4の改善対応※大きな目標は抽象的にな
りがち

改善対象1
の改善対応

目標1

成果1

実感

成果？

ところで何だったかな？

改善対象2
の改善対応

目標2

成果2

実感

改善対象4
の改善実践

改善対象3
の改善対応

目標3

成果がよく
分からない

成果3

目標4

成果4

実感

実感
時間t

P.98

Copyright © Kenji Adachi@HBA Quasol , All Rights Reservedコンテンツ1. SaPID構築の背景
2. SaPID流：改善のあるべき姿
3. SaPIDの全体像と詳細

4. SaPIDの適用と期待効果
5. まとめCopyright © Kenji Adachi@HBA Quasol , All Rights Reserved

SaPID適用の4段階
原則：「改善が必要だ」「もっとよくしたい！」と思った本人が始める＜自らが変化の起点になる＞【段階1】改善に慣れる 改善の確実な成功よりもまずは改善を回す・
継続することを優先する（その分、軽く・短く回して次につなげる）↓【段階2】現状分析を高度化しながら取り組む↓【段階3】当面の最終目標を定め、徐々に規模・難易度を高めながら取り組む↓【段階4】総合的な実践による自律運営の実現
P.97

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

SaPID運営バリエーションの例
個人・チームの状況に応じたアプローチ
チーム種別
運営方針

STAGE
STAGE0
ビジネス要件の共有

上級者チーム

STAGE3
改善の実行

P.100

初心者チーム

自律して業務～組織
成果目標を伴う改善を まずは改善に慣れて成果向上への取組実践する。
もらう。
みを実践する。
大枠の方針を示し任せる（議論を開始する）。

STAGE1
現状把握
STAGE2
改善の検討

中級者チームSaPIDを自らフルスペックで実践する。

事前オリエンテーショ
ンをベースに自分た
ワークショップなどで問 ちでテーマ・目標・改
題構造を分析し改善計 善策などを明確化し画を立案する。その内 て取り組む。ふりかえ
容にもとづいて改善を りを実施して次につ実施し、結果をふりか なげる。
えり、次につなげる。

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

自律改善を促進するSaPIDファシリテーター

摘要
SaPID実践者

個人

リード

リード
サポート

実践

実践

当初～しばらくの間
SaPIDファシリテーターがサポートしてノウハウ移転
チーム

リード

最終形
自己完結実践

リード

サポート

サポート
実践

実践

当初～しばらくの間
SaPIDファシリテーターがサポートしてノウハウ移転

P.102

一つの最終形SaPIDリーダーがメンバーに
実践サポートを行いながら改善を実践する

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

SaPID実践支援
を受ける者
SaPID
ファシリテーター

組織全体適用 SaPID品質統括マネージャー
組織

SaPID品質統括
マネージャー

事業方針
品質方針
改善
プログラム

SaPIDファシリテーター
SaPIDリーダー

SaPID実践者

改善範囲

P.104

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

SaPIDファシリテーターの心構えと支援時の注意事項
支援者の
心構え
●
（1）手法の価値を把握・実感しておく●（2）一緒に成長する●（3）対等な立場で、同じ目線でアプローチする●（4）過剰に嫌われたくないと思わない●（5）理解することによって理解してもらう●（6）誠実に対応する●（7）待つ勇気を持つ●（8）失敗を許容しそこから学ぶことを促進する●（9）「～させよう」的な下心を持たない●（10）改善推進役が主役にならない●（11）事実の伝達が必ずしも良いとは限らない（12）相手の特性や状況を把握してアプローチする－（13）まずは相手の話をよく聴く（傾聴）－（14）自らも理解するために必要な情報を取得する－（15）相手のことをありのまま理解する－（16）質問の仕方には注意する－（17）何を求めているのかを把握する－（18）良いこと・当たり前の敷居を下げる－（19）良いことを見つける－（20）良いことはその場で知らせる－（21）良くないことは本人に気づいてもらう－（22）無用な疑問や不安はタイムリーに解消する－（23）見通しを示す－（24）自ら動く意思がなければ支援しない－（25）うまくいったら本人の手柄－（26）手応えを得る、そして共有する－
Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

心構えと注意事項

P.132

支援時の
注意事項
－
－
－
－
－
－
－
－
－
－
－
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●

SaPIDの組織的適用結果
6部門・700名・120グループが3年間実践した生産革新活動“スリーム”の結果

1年目

狙いと方針
目指すこと（狙い）3年目

全員参画・組織的 生産面改善および定 事業成果の向上につ
改善運営の確立
量的成果獲得率向上
ながる改善成果獲得
広く浅く、やりや 広く浅く、を維持し 広く浅く、を継続しすいところからは つつ、徐々に実のあ ながら、狭く深く＆三方よしを1部門あた
じ め る こ と で 改 善 るものを増やす。
に慣れる。
り最低1グループ以上。

運営方針

1年目

運営効果メトリクス
改善参画率
平均グループメンバー（人数）
事業成果向上に つながる成果達成グループ数
定量的成果目標設定グ
ループ比率
定性的成果目標設定グ
ループ比率
施策系目標設定グルー
プ比率

P.150

2年目

74%
4.7
0
0%
14%
86%

2年目

90%
5.2
0
1%
81%
18%

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

3年目

86%
5.1
6
42%
39%
19%
51

業務運営との一体化：ふりかえり駆動型業務運営の例
主にイベント系ふりかえりで使用

観点
共有

リアルタイム
各自
ふりかえり 事前KPT確認
K P T
対象活動

計画

K

P

T

各自記
録化

共有

保管
共有

問題構造分析・
定量評価実施

主に定例
ふりかえり
で使用

観点
確認

K

対象活動

K

P

各自記
録化

P

保管
共有

P

共有

T

記録化

保管
共有

次の観
点・目標・
運営方法

ふりかえり
集合Meeting
事前KPT確認T

記録化 保管

T

K

Input情報
として活用

各自
定性・定
量評価 事前KPT確認

観点
共有
計画

P.127

記録化 保管

ふりかえり
集合Meeting
事前KPT確認

観点
確認

K

P

T

記録化

保管
共有

次の観
点・目標・
運営方法

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

改善実践開始当初～
ふりかえり結果に基づき改善成果領域と改善対象を特定→次のプロジェクト・業務で改善実践
設計書はあったり、な
かったりする

要求事項＝顧客が言ってきたことのまま
要求事項は記録されない
こともある

要求事項
の決定が
遅延する

チェックリストの形式チェッ
ク中心
レビューが
形式的な場
合がある

設計は担当
者の経験則
に任せている

要求事項が
何度も変更
される

設計書記載内容＝機能と正常系中心

改善
対象 残業＆休日返上対応が多いP.105

実績情報をベースに改善対象を特定し、次のプロジェクト・業務運営に活用する⇒ フィードバック（FB）

プロジェクト
が赤字
顧客
クレーム
発生

納品後に障
害が発生
バグ内訳
①機能間不連携納品②使いにくい・手続き不明③組合せ時動作不備

実装・テストは担当者の経験
則に任せている

実装内容
がバラバラ

改善効果
獲得領域

システムテスト時に想定以上のバグ検出

納品後障害・システ
ムテスト発生バグのテストが未実施
Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

改善実践継続後の発展形
進捗管理・ふりかえり活用→次フェーズ以降の運営を再設計して実践
顧客
旧設計書【事例】設計Phase完了ふりかえり時
難易度の高いZ機能と重要なK機能の設計は担当者の経験設計
設計 則に任せた

K機能の要
求事項決
定が遅延

要求事項
明確化

レビュー

Z機能担当
は別業務
でも多忙

要求事項
打ち合わせ 記録 K機能の要求
毎に記録さ
れている

K機能を中心に最新要求事項全体を一覧化

要求事項への対
応漏れ＋誤りが発生するリスク

新code

信用失墜
採算性悪化

発生

顧客

納品後障害
発生

新シス
テム

納期遅延
システムテス
トで想定外の
バグ検出多発納品

実装

途中までの実績情報をベースにそ
システ
判定
ムテスト
QA担当が設計書の先のプロジェクトリスクを特定し、結果をテスト設計する
テスト
以降のプロセスを再設計・実践す課題・問題
フィードバック事項対応
る⇒フィードフォーワード（FF）
システム

設計結果と顧客・有識者
Review

プロジェクト・業務の節目・Phase単位にそれまでの実績から以降のリスクを特定し、プラクティスレベル
の対策を実践する（プロジェクト・業務内予防処置）

P.106

システ
ム利用
顧客クレーム

設計書記載内容＝機能と正
新設計書
常系中心

事項が再三
変更された

変更が多いK機能を
旧code
中心に最新要求事
項全体が不明チェックリストの形式チェッ
形式的なレ
ク中心
ビュー／欠
陥検出ほと
んどなし

テスト結果
単体・結合
テスト結果

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

事項(実績)
リスク

納品判定リスク対策

SaPID自律改善トレーニング
・SaPIDシステムズアプローチワークショップ
2012年から首都圏、中京、関西で開催し、高い評価を得ています。
SaPIDの10STEPを解説し、受講者自らが改善対象を分析～改善計画立案ワークを実践することで、自律改善に必要なシステムズアプローチのノウハウを体得します。
※2014年度～日科技連様が主催する“JUSE SEMINAR”に採用されました！

・SaPID問題モデリングワークショップ
自律改善手法SaPID流の問題モデリングのポイントを理解し、ふりかえりを活用しながら、どのような段階を経てチームとしての自律運営を成し遂げるのか、の道筋を検討し、現実的かつ効果的に実践する方法を体得します。

・SaPIDファシリテーター実践ワーク（ケーススタディ）
組織やチームが自律改善を進める上で重要なカギを握る「SaPIDファシリテーター」養成講座。
ケーススタディを通じて、自律改善を進める過程で発生するさまざまな事象に対してどのように反応し、対処していけばよいのかを体得します。

Copyright © Kenji Adachi@HBA Quasol , All Rights Reservedコンテンツ1. SaPID構築の背景
2. SaPID流：改善のあるべき姿
3. SaPIDの全体像と詳細
4. SaPIDの適用と期待効果

5. まとめCopyright © Kenji Adachi@HBA Quasol , All Rights Reserved

人・チーム・組織の行動と結果
SaPIDが目指す
改善アプローチ
表面的な改善アプローチ
現状
把握

改
善

結果・成果

行動・活動

現
状
把
握

目に見え
る領域
改
善

思考・認識
価値観
意識
P.25

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

目に見え
ない領域

人が中心になる
原因

鍵は「チームワーク」

主体性
を持つ

計画的
に行う

全員が
参画する

結果

原因が存在すると
結果になりやすい

事実に基づ
き行動する
明確な目的・
目標を持つ

摘要

現実的に
進める
関係者間で
認識共有

成功を分
かち合う

活動を
継続する

出典：プロセス改善ナビゲーションガイド 虎の巻編―改善のゴールに一歩 近づくために (SEC BOOKS)＜技術は人の上に載っている＞①人的問題をクリアしない限り、本質的な技術コミュニケーションが成り立たない②技術を活かすのも殺すのも人間の意図と行動が決める

P.4

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

改善→成長～新しい自分に出会う
昨日の自分を越えていく

改善は自分が、そして仲間と組織が一緒に成長するた
めに、自らの意思と行動で行うものです。

毎日の仕事を惰性で、やらされ感満載で送るのも、より楽しく、価値あるものにするのも、すべて自らの考えと行動にかかっています。
自律した改善により、自らが成長し、ソフトウェアの仕事を楽しく、より価値のあるものに変えていきましょう！
その実現のためにSaPIDがお役にたてるなら、こんなにうれしいことはありません。
Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved参考文献・Webサイト
•
•
•

•

•

•

•
•

高度情報化人材育成標準カリキュラム準拠第一種共通テキスト14：
問題発見・解決技法 財団法人日本情報処理開発協会 中央情報教育研究所
天野勝（2013）：「プロジェクトファシリテーション 実践編 ふりかえりガイド第24版」
http://www.objectclub.jp/download/files/pf/RetrospectiveMeetingGuide.pdf
独立行政法人情報処理推進機構ソフトウェア・エンジニアリング・センター編（2009）：『プロセス改善ナビゲー
ションガイド～虎の巻編～』オーム社
http://www.ipa.go.jp/files/000005138.pdf
SPI Japan2007事例発表： 『現場の様々な事実情報分析に基づく現実的な改善アプローチのご紹介－システム
ズアプローチを活用した改善実践事例－』http://www.jaspic.org/event/2007/SpiJapan/2A3.pdf
SPI Japan2011事例発表：ふりかえり実践方法の変遷による業務運営プロセスと成果の改善
http://www.jaspic.org/event/2011/SPIJapan/session3B/3B4_ID008.pdf
SPI Japan2012事例発表：システムズアプローチに基づくプロセス改善メソッド：SaPID（Systems
analysis／Systems approach based Process Improvement methoD）が意図するコト〜プロセスモデルをより有効活用するために／そして現場の自律改善運営を促進するために〜
http://www.jaspic.org/event/2012/SPIJapan/session3A/3A4_ID023.pdf
派生開発カンファレンス2013事例発表：「問題構造分析とPFDの併用による現実的・段階的な改善実践方法の提案～PFDを使いこなす能力を確実に身に着けるために～」
http://www.xddp.jp/conference2013/xddp2013_p8.pdf
SPI Japan2013事例発表：SaPID実践事例より～改善推進役がやるべきこと/やってはいけないこと 現場が自らの一歩を踏み出すために
http://www.jaspic.org/event/2013/SPIJapan/session2B/2B3_ID011.pdf

SaPID、当資料への問い合わせ先はこちらです
株式会社HBA Quasol 安達賢二 ： adachi@hba.co.jp

P.155

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

2015.8.28（金） SWEST’17 セッションS2B 資料2

システム企画・開発／プロジェクト管理／プロセス改善など、さまざまな「現状分析」に活用できる
自律したチーム運営を促進する
SaPID® 流

問題モデリング
SaPID＝Systems analysis／Systems approach based Process Improvement methoD

株式会社HBA
Software Quasol（Software Quality Solution Service）

安達 賢二 adachi@hba.co.jp
http://www.software-quasol.com/®

※“SaPID”は株式会社HBAの日本における登録商標です。以降のスライドでは 表記を省略します。
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved1Work1
実務における現状の問題点

各自が抱えている実務における問題点（主要なものが理想）を1つ記載してください。
※後ほど自ら記載したものを相手に見てもらい、問題点を把握・理解してもらいます。

Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved

2

Work2
問題共有
当初記載した「問題表現」の内容をグループ内で具体的に把握してください。
①ペアになってまずはどちらかの一枚（書かれたもの）をもう一人が黙読し、頭の中にどのようなことかをイメージします。
②イメージしたことを「こういうことですね？」自分の言葉で説明してみましょう。同じ認識になっていますか？
③不足していた情報があれば特定してください。
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved3

問題モデリング解説

Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved

4

SaPID流問題モデリングとは？
• チームや組織に存在するたくさんの問題がどのように関連して何が起きているのかを把握し、わかりやすく表現すること。表現した結果、関係者全員が問題を（最終的には全体構造と、個別詳細の両面で）把握・理解し、納得することを目指す。
→関係者全員にチームの問題解決や改善実践の“当事者”になってもらうのが最終目標
モデリング＝対象の主な特徴を的確に捉え、主な要素を構造化し、枝葉情報は除外して表現するまでの試行錯誤の過程と結果を指すことが多い。
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved5こんなことになっていませんか？
よくある出来事＜①システム企画～開発・導入＞
ITシステム企画～開発・導入の過程で、システムの利用者とその管理者、経営者など関係者のニーズや要望がバラバラで折り合わず、要求や仕様変更が多発し、プロジェクトが迷走・頓挫する。

＜②プロジェクト管理＞
プロジェクト・業務・組織運営に存在するリスクや問題が見えない。
突然大きな問題が発生するなど、いつも後手に回っている。
＜③プロセス改善＞
プロセス改善対象のメンバーが当事者意識に欠け、形式対応に終始したり、自然消滅するなど改善効果が得られない。
あるいは関係者の意見が合わず迷走する、声の大きな人の一言で決まるが誰も納得していない、など。

これらは“問題モデリング”で解決可能です
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved6自律したチーム運営を促進する・・・

自律とは？
http://www.weblio.jp/ 他• 自分の気ままを押さえ、または自分で立てた規範に従って、自分の事は自分でやって行くこと。
• 他からの支配や助力を受けず，自分の行動を自分の立てた規律に従って正しく規制すること。
• 自己の欲望や他者の命令に依存せず，自らの意志で客観的な道徳法則を立ててこれに従うこと。
• 「自立」は他の助けや支配なしに一人で物事を行うことであるが，それに対して「自律」は自分の立てた規律に従って自らの行いを規制することをいう。
• 反対語
自律←→他律 自立←→依存

SaPIDが目指すのは「自律したチーム運営」
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved7よくある光景
毎朝ミーティング

週次進捗報告書

何か問題はありませんか？
↓
特にありません。。。

Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved8問題共有を促す／阻む要因• 場• 人、信頼関係• リーダやチームの価値観• 暗黙の固定観念• 表現＆伝達－受取能力• 問題の捉え方 など

Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved

9

チームで共有すべき問題とは？
仕様書が
間違って
いる
計画外作
業の依頼
が来た
かわい
い女性
がいない

価値観や認識により見えるものが変わる
情報はいつも目の前にすべて存在している

品質基準
がない
これかな？

作業が
進まない

顧客が
怒ってる

仕事が楽
しくない
このコー
ドはわか
りにくい

Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved

進捗が遅
れている
テスト設
計よくわ
からない
作業場所
が暑い
10

モノゴトの取り込み～反応まで
ヴァージニア・サティア（Virginia Satir）の交流モデル
取り
込み

意味
づけ

意義
づけ

反応

事象
刺激と反応の間に選択の自由を持っている
ビクター・フランクル（心理学者）
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved

11Conditional Response 目標達成理論
習慣は“多くの条件（状況）に対する反応のセット”
習慣 ＝ （ 状況 → 反応 ） × ｎ → 執着へ■習慣の解消方法①習慣的行動を小さな条件（状況）反応に分解する②分解した条件反応の中から対応が容易なものを選ぶ③選んだ条件反応の鎖を断ち切る④①～③を繰り返し、（状況→反応）のセットを減らす⑤習慣への執着が弱まる⑥自らコントロールできる領域を広げる→喜びを実感
領域を拡大

自分でコントロールできない領域（執着）

自分でコントロー
ルできる領域

継続するためには短期間での実感獲得が重要
Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

12事象→判断表現
伝達
受取共有
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved

13

共有
取り
込み

事象

意味
づけ

意義
づけ

反応

受取

事象

事象
事象

事象

事象

伝達
事象→判断
Aさん
表現
場の雰囲気

Bさん

14

よくある関係者の認識違い
出典：http://images.uncyc.org/ja/3/30/Project_comedy_l.gif

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved15適切な関係者の認識
出典：http://images.uncyc.org/ja/3/30/Project_comedy_l.gif

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

16組織・チーム運営：関係者の認識
組織内のそれぞれの要員が、自分の見ている範疇で現状を認識している。しかもそこには問題・事実ではな
いものも混在している。
こうする
べきだ
全然問
題ないよ

これに困っ
てるんだ
こんな問題
がある

こうして欲
しい

各自はそれぞれの立場で、自分が見た、聞いた、感じたことを元に自分の認識を持っている（事実の断片、事実以外のものも混在） → 認識が合わない → 思うように解決・改善が進まない
Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved17自律したチーム運営に向けてあらためるべき誤認識とその結果の例
担当作業は責任を持ってやり遂げる。わからないことを安易に周囲に聞くのは無責任。

問題が起きても（周囲も忙しいから声がかけにくく）自分で抱え込む。進捗遅延になりやすい。

大きな問題に発展
しやすくなり、結果
的にチーム全体に大きな迷惑がかかる。

問題とは、自分が問題だと思ったものがそうだ。それを自分の表現で伝えれば他者はわ
かってくれるはず。

各自の経験則や育ちなどから問題の捉え方が異なる＆伝達方法が不適切なことも多く、他者にわかりにくい。

チームとしての問
題把握は実は非常に困難であり、問題を共有できな
い＝解決できない
可能性が高まる。

Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved18自律したチーム運営に向けてあらためるべき誤認識とその結果の例
他者よりも知識・技能が高い方が差別化しやすい。だから身につけた知識・ノウハウや経験情報はひけらかさない。

情報共有で解決できる作業でも、誰もが毎回同じように苦労し、工数をかける。チームとしての生産性があがらない。

知識・ノウハウ・経験を持った人に作業が集中し、チームとしての進捗が遅延する。
一方で以外のメン
バーは待ち(楽)→以降
大変な状態になる。

改善は業務とは別モノ。
依頼がないならやらない。形式的で運営が重くなるだけ。効果を実感したことがない。

契約した作業とは異なる＆別工数を使うのでリーダや担当が実施すればよい。メンバーや協力要員がやるものではない。

参画者少のため、解決すべき問題や要因が特定できず、手段も不適切に、そして失敗しやすい。

Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved19自律したチーム運営に向けて

問題情報のリアルタイム認識共有の必要性
関係者は自分の立ち位置（役割）や価
値観が違う＜変えられない要因＞

問題
モデリング

全体の一部
しか認識できていない
見えているものから感じる
ことが違う

関係者全員が問題
構造（全体像）と個別
詳細の両面を把握・理解し、納得する

チーム・組織内で意見や見解が合わず問題解決や改善が迷走・混乱・頓挫しやすい

関係者の合意当事者としての問
題解決への全員参画

Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved20自律したチーム運営に向けて

問題情報のリアルタイム認識共有の必要性
リソース、時間、スキル、人間性など制約条件が厳しい＜変えられない要因＞

チーム・組織にはたくさんの問題が存在する
問題
モデリング

問題解決が
後手に回り
やすい

大きな問題にならないと解決行
動が始まらない

対応しやす
い問題に手
を出しがち

どれも未解決／中途半端な対応
で終わる

小さな個別問題を早期に発見し・解決できる
多くの問題から少ないリ
ソースを投じる価値ある問題を発見・解決できる
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved

バッファー量が増え、ミッション達成確率が高まる
21

SaPID流問題モデリングは「どう表現するか？」だけではない• 問題の表現形式や表現方法だけを磨いても目的（関係者全員が問題を（最終的には全体構造と、個別詳細の両面で）把握・理解し納得することを目指す）は達成できない。

• 問題の表現形式や表現方法と同時に、その過程で関係者とどのように関わり、どのように巻き込み、どのように認識を共有し、合意を形成するのか、が問われる。
実務の現場では、人間系の問題と技術的な問題の両方を丸抱えで解決する必要がある
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved

22

“問題”とすべき事項とは？
• チームに新しいメンバーが入りました。
• その方に、「われわれのチームでは、チームパ
フォーマンスを上げるため、○○のようなことを“問題”としています。」「問題をできるだけ早く共有・解決するため、作業中にそれを把握したら、みなにすぐ知らせてください。」と説明するとします。
• どのような説明をすると、新しいメンバーに的確に伝わり、意図通り行動してくれそうですか？
23文章表現の原則・禁則
文章表現の原則
事実準拠の原則
断定・推測区分の原則
個性化の原則共通理解の原則
具体化の原則一文一義の原則
簡潔性の原則禁則
体言止め・紋切型
不足型・不十分型

対策型

疑問型
断定型・推論型

P.52

内容
事実に即して記載する。
推測を含める場合は事実と分けてはっきりと記載する。
決まり文句や流行語、一般論的な表現を避け、実際に存在する個別事項を記載する。
訴えたいことがそのまま関係者に理解されるように表現する。
抽象的な表現を避け、どのような状態や結果なのかを具体的に把握できるように記載する。
一つの文に一つの内容を記載する。
余計な修飾語や冗長な説明を削り落として簡潔に記載する。
悪い例

適切な見直し方法
モラル
内容を具体化して生々しい出来事を記計画
載する。
レビュー不足不足・不十分となっている内容を具体
テストが不十分的に示す／不足していることで発生している出来事を明確にする。
□□基準が存在しない それがないために発生している困った出来事や状態を記載する。
○ ○ ス キ ル に 問 題 あ 疑問に思った経緯や背景・出来事を具り？
体的に記載する。
Aさんはやる気がない
そう考えた経緯や背景・出来事を具体
最 初 か ら ム リ な 計 画 な 的に記載する。
のではないか？
Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved

24Work3
問題表現レビュー
当初記載した「問題表現」をレビューしてください。
①問題として適切なものかどうか②ありのまま、具体的に把握できる内容
かどうか→どういうところがよいか／まずいか？
可能なら修正案も検討してください
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved25

Work4
問題点を共有しにくいチームの特徴

グループで、問題を共有しにくいチームの特徴を洗い出してください。
各自が付箋紙に問題を共有しにくいチームの特徴を記載し、随時提示。
→全員で内容を把握してください。

Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved

26風通しの良い／悪いチームの特徴例
風通しの悪いチーム

風通しの良いチーム

問題があってはならない・間違いを許さない 問題があって当然・人間は間違うもの
挨拶なしor固い挨拶

気持ちいい挨拶・ありがとうが普通に言える

笑顔少ない・よそよそしい態度

笑顔多い・バカ話・うちとけた雰囲気

不平・グチは違反（暗黙）

不平・グチも手掛かりに問題を共有

問題を言えず自分で抱える→大きくなる

早期に問題を共有しチームで解決へ向かう

弱い立場のメンバーを軽視・不公平

メンバーの特徴を理解・受容する・公平

上司やリーダ（鬼軍曹）に黙って従う
一方的に指示・命令で動く／消極的

おかしなことはおかしいと言える
お互いの提案と調整で動く／積極的

監視・締め付け・やらせる／やらされる

見守り・支援と協力／まかせる・やってみる

判断を仰ぐ・判断基準は「〇〇さんが言った」「△△基準で定められている」

各自で判断・判断基準は目的に適切で公平な事実情報や根拠に基づく

原因は人・魔女狩り

人を憎まず・原因はプロセス改善の意図は「反省しろ！」・悪い知らせ言われたらやる改善は成長
自ら必要にかられて実施する

Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved27

問題解決・改善の実践状態※経験則に基づきモデル化したもの
問題解決・
改善工数

問題を共有しにくいチーム
問題が大きくなってから解決行動→指示に従い改善を実施※改善の費用対効果が低い傾向
時間の流れ
問題解決・
改善工数

自律運営チーム
毎日問題を共有して即座に解決行動
必要な改善も問題解決と区別せずに実施※改善の費用対効果が高い傾向
時間の流れ
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved28

問題モデリングによる自律したチーム運営へのシナリオ■問題の早期発見・解決の実践①初期の問題モデリングを行う。
②チーム内の問題が早期に発見でき、解決しやすくなる。
③問題モデリングを高度化する。
④個別問題の改善に自然と取り組む。取り組みやすくなる。

■プロセス改善の実践①問題モデリングを高度化する。
②関係者全員が「われわれは確かに今こうなっている！」と納得して問題構造を認識共有できる。
③関係者ひとり一人が、自ら提示した問題事項を含めた問題構造から当事者の一人としてどこを解決すべきかを考える。
④関係者全員による適切な解決すべき問題の特定とその合意形成＋解決策の導出、解決のための活動への参画が得られる。
⑤改善が成功しやすくなる。→継続しやすくなる。
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved

29ふりかえり（KPT）運営サイクルに乗せ問題モデリングを高度化していく
月

火

水

木

金

月

火

水

木

金

月

火

水

木

金

K

K

K

K

K

K

K

K

K

K

K

K

K

K

K

T

T

T

T

T

P

P

P

P

P

個別
KPT

個別
KPT

個別
KPT

個別 個別
KPT KPT
K

T

T

T

T

T

T

P

P

P

P

P

個別
KPT

個別
KPT

個別
KPT

個別 個別
KPT KPT
K

T

T

T

T

T

P

P

P

P

個別
KPT

個別
KPT

個別
KPT

個別 個別
KPT KPT

T

P

K

T

P

P

P

Team
KPT

Team
KPT

Team
KPT

Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved30自律したチーム構築への取組み例
試行期間目安＝3か月間①毎日の個別ふりかえり→チーム内即共有→早期の問題解決+個別改善実践②週次の集合ふりかえり③月次集合ふりかえり→実践内容、運営方法へのフィードバック→問題解決・改善実践④チームによるプロセス改善実践
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved31いろいろなノウハウが必要• 関係者が納得できる趣旨、アプローチ、内容や結果の適切さなどの説明力・説得力• 適切な問題SCOPEの置き方• 必要な問題情報の引き出し方• 具体的な内容の把握の仕方• 誰にでも理解できる表現への変換• 因果関係を中心とした関係性分析力• 人間性や信頼関係• 問題発見解決のあり方に対する価値観 など
Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved32問題モデリングの効果は実践の積み上げチームとして協調しながら
自然と問題解決実践
できる価値観を持つ
問題

手間
解決策の
狙いどころ

効果を実感共有できる

解決策をしっかり実践できる

効果

具体的かつ適切な解決策と目標を導き出せる問題

簡単な個別問 対処する優先度
事象を具体的に題を協力して を適切に決めら
理解・共有できる
れる
解決できる問題をチーム内で提示できる（問題を提示しても安全な場）
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved33

問題モデリング事例

Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved

34ふりかえり結果例
Y:やったこと＆結果

W:わかったこと

T：次にやること□Aさんのモデレートのよいところをまとめる・モデレータ1名＋レ〇ウォークスルーで作成者が説明すると、著 ・アイスブレイクから入る
ビューア3名者の意図と記述内容の差異が明確になり、・目的、注意事項共有・それぞれに観点割り付 指摘事項を的確に伝達しやすい。
・笑顔でハキハキ伝える
け→個別レビュー後に〇レビューア毎に観点を割り付けて実施す・自分が対象の内容を理解
集合レビューると検索範囲を絞りやすく、集中できるのでする過程をみなで共有する・集合レビューではよい！
など
ウォークスルーを採用〇Aさんのモデレート、神ってる！みんなを・一度レビュー終了後、 前向きにしつつ、コメントを引き出していた！ →次のモデレータが自分でできるところから真似て進め
追加観点で再レビュー〇余計な機能や基本構造の不備等が指摘てみる。
実施できたので費用対効果がすごい！

◆やったこと◆Keep：実践・継続したいこと

Problem：問題・課題事項◆結果◆
・欠陥指摘10件
重大5･通常3・軽微2

・速度 500L/h
・欠陥密度 8件/KL・費用対効果80!!

×観点がピンポイントに偏ったかも。指摘事
項にムラがある＆欠陥密度が低い。
→仕様・機能詳細などモノづくりの視点の指摘が少ない→追加レビュー実施
×1分間に8.3行。レビュー速度、速いんじゃないか？

□観点設定結果をモデル図で示し、有識者と簡単に抜け・漏れ確認をしてから割り振る。
□試行：パラグラフ単位にレ
ビュー速度（5行/分程度まで）を確認しながら進めてみる。→その結果何が変わるか評価する。

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved35

【質問】現在の業務やチームにおけるテストに関して、みなさんが実感している問題事項や問題意識があればそれぞれお知らせください。（特になければ「なし」とご回答ください）
日程・終了判定があいまい／なんとなく工程移行している
レビューアによって観点が異なる
場合がある・認識が不統一

変更影響範囲情報
不足の場合あり・顧客に伝達された情報だけが頼り自前のテスト（作業）方針・戦略はない

仕様分析しているが仕様記述内
容＋αが対象実施結果判定がばらつく（OK／NG）

独自の指標はない

顧客方針と戦略に従うつもりが理解不足で行き違いもある

不具合なしを前提の計画になっている

製品リスク評価していない／顧客から評価結果を取り寄せたりなどはない
テスト設計の
進め方が決
められない

実質作業
期間が短く
なる

テストは未完了でも日程で終了することがある
個別設計・仕様→テストケース化がメイン

そもそも進捗
が見えない

生産性指標
がない

過去バグや（変更経緯・理由などが把握できていない
ST完了判定基準がピンとこない

レビューで
の問題指摘
が多い

技法適用されていない（例：
境界値分析できていない）
同類のテスト
条件を横展開
できない

手戻り作
業が多い

チームごとの役割で動いている・全体
共通や連携の役
割・活動はない

期待結果が曖
昧になっていることがある

Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved

手戻り・横槍などに対応する
リソースが不足しがちケースにFB
を出せない
人が多い）

36

日程・終了判定があいまい／
なんとなく工程移行している

生産性指標
がない
独自の指
標はない

顧客方針と戦略に従うつもりが理解不足で行き
違いもある

そもそも
進捗が見
えない

不具合なしを前提の計画になっている

ST完了判定基準がピンとこない
手戻り・横槍などに対応する
リソースが不足しがち

レビューアによって観点が異なる
場合がある・認識が不統一

テスト設計の
進め方が決
められない
受身な作業
自前のテスト
仕様分析し（作業）方針・戦
ているが仕
略はない
様記述内容
過去バグや（変更＋αが対象
経緯・理由などが製品リスク評把握できていない
価していない変更影響範囲情／顧客から報不足の場合あ
評価結果をり・顧客に伝達さ取り寄せたりれた情報だけがなどはない
頼り

テストは未完了でも日程で終了す
ることがある

実質作業
期間が短
くなる

技法適用されていない（例：
境界値分析できていない）
個別設計・仕様→テストケース化がメイン

レビューで
の問題指摘
が多い

同類のテ
スト条件
を横展開
できない

手戻り
作業
が多い

実施結果判
定がばらつく
（OK／NG）
ケースにFBを出せない人が多い）

期待結果が曖
チームごとの役割
昧になっているで動いている・全ことがある
体共通や連携の役割・活動はない
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved37問題モデリングの実践効果例＜プロジェクト・業務管理＞
マイクロレベルの進捗管理から、プロジェクトリスクマネ
ジメント（予防処置）実践への進化

Copyright © Kenji Adachi@HBA Quasol , All Rights Reserved38

問題モデリングは様々な「現状分析」で活用可能
ID

使いどころ

対象領域

① IT関連ソリューション企画・提案に ITシステム導入対おける現状分析～要求定義時
象領域② プロジェクト・業務・組織運営（計プロジェクト・業
画立案・進捗管理など）における 務・組織
現状分析時
③ プロセス改善における現状分析時 プロセス改善対象（SaPIDでは“STAGE1:STEP1～3”） 領域
迅速、かつ適切な問題発見・解決の鍵はコミュニケーション・情報共有・チームワーク
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved

39

まとめ

Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved40自律したチームの構築に必要なこと• 安心して気持ちよく仕事ができる場• 当事者意識（モチベーション：内的要因）• 信頼関係• チームワーク（One for all/All for one）を発揮し、「三方よし」が実践できる適切な価値観• 認識共有と一体感（良質なコミュニケーション）• そして、技術力+エンジニアリング力→結果：操舵実感と成長実感、仕事へのやりがいや喜びに繋がる
リーダの人格・価値観や組織文化は、これらに相当なインパクトを与える
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved41相応しい価値観～実践方法へ• 誰かに依存し、単に従う（思考停止する）のではなく、実践→ふりかえり→改善・実践→ふりかえ
り・・・を繰り返しながら相応しい価値観を自ら（チーム全員で）、徐々につくりあげていく、そしてそれを実践し、さらに磨き続けるのが理想。価
値観も実践方法も固定化することはない。
• 相応しい価値観や実践方法に絶対解はない。状況や環境変化によりタイムリーに変えていく。
• 終わりのない探索の旅を続ける。
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved42三方よしの実践
売り手よし、買い手よし、世間よし• 鎌倉時代～戦前までの近江（滋賀県周辺）商人の思想・行動哲学• 永続的に繁栄するビジネスのあり方• 自分だけ、他者だけの考えでは長続きしない。
• 自分も、チームも、組織も、顧客も、業界も、みながうれしい状態を作るために必要なことを実践する。
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved

43

「信頼」は積み重ね• 信頼は毎日の積み重ね• 信頼残高はいくらでしょうか？
振込＞＞＞＞＞＞＞＞＞＞＞＞＞引出• モノゴトに誠実に対応する、相手を理解する、
小さなことを大切にする、約束を守る（何でも簡単に約束しない）、もし信頼を損ねるようなことをしたら素直に謝る、などあたり前のことをあたり前に実践し続けるしかない。
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved44

If I wasn’t hard, I wouldn’t be alive. If I couldn’t
ever be gentle, I wouldn’t deserve to be alive.
Philip Marlowe

タフじゃなくては生きていけない。
（優れていなくては、）

優しくなくては、生きている資格（チームで仕事をする）はない。
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved45

【Last Work】
今日のセッションのふりかえり
このセッションをふりかえってください。
総評：素直な感想と100点満点で何点？

Keep：わかったこと、気づいたこと、うれしかったこと、などProblem：よくわからなかったこと、うまくいかな
かったこと、など

Try：実務で取り入れてみたいこと、やってみる
こと、など
Copyright © Kenji Adachi@HBA Quasol, All Rights Reserved

46