モダン・ソフトウェアエンジニアリングEssenceの紹介

BPStudy#197〜モダン・ソフトウェアエンジニアリング( https://bpstudy.connpass.com/event/307202/ )の資料です。

Essenceを紹介するとともに、匠Methodを「エッセンシャル化」した事例を紹介しています。

Transcript

1. 1 モダン・ソフトウェアエンジニアリング Essenceの紹介 株式会社システム情報 CMMIコンサルティング室 小林 浩 2024年1月31日 1.0 1
2. 2 はじめに 感謝 きっかけをくださった 増田 亨さん 企画してくださった 佐藤 治夫さん 資料の使用を快諾してくださった 鷲崎 弘宜さん 角 征典さん 参加してくださった 皆様 ありがとうございます！
3. 3 自己紹介 小林 浩 株式会社システム情報 フェロー、CMMコンサルティング室 室長。 IBMとアクセンチュアにてエンジニア、PM、品質管理等を経験後、現在は組織能力向上を支援する コンサルティングサービスを提供。 ◼ 主な資格や活動 ➢ CMMI高成熟度リードアプレイザー（開発,サービス） ➢ AgileCxO認定APHコーチ・アセッサー・インストラクター、SAFe SPC/LPM、 ➢ Scrum Alliance認定ScrumMaster、PMI認定PMP ➢ SEMAT日本支部メンバー、SE4BS検討メンバー、QA2AQ翻訳メンバー、 PMI日本支部DAコミュニティWG3メンバー など ◼ 株式会社システム情報のブログ 「CMMI&アジャイルコンサルタントのブログ」 https://www.sysj.co.jp/blog
4. 4 会社紹介 （株）システム情報・・・グループ全体で社員数1000人超の独立系SIer。 https://www.sysj.co.jp/ MBO、TOB、現在大変革の真っ最中
5. 5 参考資料 ▪セミナー Smart SEセミナー： モダン・ソフトウェアエンジニアリングのエッセンス（ 2020年7月21日） https://smartse.connpass.com/event/178626/presentation/ にある以下の資料 (資料2) ソフトウェアエンジニアリングとエッセンスの広がり（鷲崎弘宜） (資料3)モダン・ソフトウェアエンジニアリングのエッセンスの概要（角 征典） ▪勉強会 第3回SEMATカーネル勉強会 (2013年10月29日 ) https://www.slideshare.net/hironoriwashizaki/3semat-semat にある以下の資料 (資料4)SEMAT: ソフトウェアエンジニアリングのエッセンス（鷲崎弘宜） ▪書籍 （資料1）モダン・ソフトウェアエンジニアリング 2020年5月29日、Ivar Jacobson (著), Harold “Bud" Lawson (著), Pan-Wei Ng (著), Paul E. McMahon (著), Michael Goedicke (著), 鷲崎 弘宜 (監修), 角 征典 (翻訳)
6. 6 目次 ◼ モダン・ソフトウェアエンジニアリングのEssenceの紹介 ➢ ソフトウェアエンジニアリングの問題 ➢ SEMATとEssence ➢ アルファ ➢ アクティビティスペース ➢ カーネルの拡張とエッセンシャル化 ◼ Essenceの適用事例 ➢ 適用事例一覧 ➢ 事例１：某社「プロジェクト状況チェックリストの改善」 ➢ 事例２：ITA「アルファを活用した障害事例集の改善」 ➢ 事例３：SE4BS 「匠Methodのエッセンシャル化」
7. 7 目次 ◼ モダン・ソフトウェアエンジニアリングのEssenceの紹介 ➢ ソフトウェアエンジニアリングの問題 ➢ SEMATとEssence ➢ アルファ ➢ アクティビティスペース ➢ カーネルの拡張とエッセンシャル化 ◼ Essenceの適用事例 ➢ 適用事例一覧 ➢ 事例１：某社「プロジェクト状況チェックリストの改善」 ➢ 事例２：ITA「アルファを活用した障害事例集の改善」 ➢ 事例３：SE4BS 「匠Methodのエッセンシャル化」
8. 8 資料1(日本語版まえがき xiii,xiv) 、資料4 ソフトウェアエンジニアリングの問題 ユースケースやUML、オブジェクト指向開発の父であるIvar Jacobsons氏は、 「ソフトウェアエンジニアリングは言わばファッション業界のように手法やプラク ティスの流行り廃りを50年間繰り返してきている」 と喝破。 20年前 オブジェクト指向 15年前 UML, RUP 12年前 CMMI 数年前 XP 現在 Scrum、 リーン、かんばん 明日は？ どれも優れているが、我々の求める全てではない！ 背景 I. Jacobson, et al.: Tutorial: Essence - Kernel and Language for Software Engineering Practices, ICSE'13
9. 9 • Boehm: COCOMO • Parnas: 情報隠蔽 • Constantine: 凝集度、結合度 • Conwayの法則 • Dijkstra: 構造化、Goto文撲滅 • Wirth: ステップワイズリファインメント • Meyer: 契約による設計 などなど しかし、いずれも共通基盤ではない 背景 Ivar Jacobsons氏 理論がない「わけではない」 Jacobson, et al.: Tutorial: Essence - Kernel and Language for Software Engineering Practices, ICSE’13, 資料2 ソフトウェアエンジニアリングの問題
10. 10 Ivar Jacobsons氏 誰もが自身のソフトウェアの作り 方を知っている。 しかし、コミュニティとして我々 は受け入れられた共通基盤を持っ ていない。 プラクティスの整理やカスタマイ ズ、組み合わせなどを的確に進め るための共通基盤が必要だ。 手法・プロセス プラクティス 手法・プロセスに プラクティスが埋もれている ソフトウェアエンジニアリングの問題 資料1(日本語版まえがき xiii,xiv) 、資料2
11. 11 共通基盤が無い場合 ソフトウェアエンジニアリングの問題 知識の島々（アイランド） 知識 経験、ガイド プロフェッショナリズム ベストプラクティスに 裏打ちされた能力 ユースケース アジャイル UML CMMI かんばん リーン Java C# 資料4
12. 12 ソフトウェアエンジニアリングの問題 共通基盤があれば 知識 経験、ガイド プロフェッショナリズム ベストプラクティスに 裏打ちされた能力 ユースケース アジャイル UML CMMI かんばん リーン Java C# 資料4
13. 13 ソフトウェアエンジニアリングの問題 共通基盤があれば 産業界のプラクティス 学術的研究 UP Scrum ・・・ ・・・ カーネル（共通基盤） 言語（図形言語） 手法・プロセス プラクティス Essence 共通基盤 資料4
14. 14 目次 ◼ モダン・ソフトウェアエンジニアリングのEssenceの紹介 ➢ ソフトウェアエンジニアリングの問題 ➢ SEMATとEssence ➢ アルファ ➢ アクティビティスペース ➢ カーネルの拡張とエッセンシャル化 ◼ Essenceの適用事例 ➢ 適用事例一覧 ➢ 事例１：某社「プロジェクト状況チェックリストの改善」 ➢ 事例２：ITA「アルファを活用した障害事例集の改善」 ➢ 事例３：SE4BS 「匠Methodのエッセンシャル化」
15. 15 SEMATとは SEMATはIvar Jacobson氏らにより2009年に始まったソフトウェアエンジニアリン グの共通理解・再定義の運動。 2009年創設 https://semat.org/ 堅固な理論、実証原則・ベストプラクティスに基づくソフトウェアエンジニアリング 再建（共通理解） • 理論的基礎の定義 • 広く受け入れられた要素によるカーネル 日本国内では早稲田大学の鷲崎弘宜教授が代表を務める形でSEMATの日本支部を 2013年に設立してEssenceの普及啓発に努めている。 (Facebook：SEMAT Japan Chapter Community) 資料1(日本語版まえがき xiii,xiv) 、資料2
16. 16 Essenceとは ◼ SEMATから生まれた、ソフトウェアエンジニアリングの文字通り “エッセンス”（本質）として整理された基盤。 ◼ 手法やプラクティス、プロセスを共通にモデル化する枠組みである とともに、そのうえで個々のソフトウェア開発・運用プロジェクト の進捗や健全性を多面的に捉える枠組みでもある。 資料1(日本語版まえがき xiii)
17. 17 鷲崎弘宜教授 「本格的なDX時代を迎えてアジャイル開発が当たり前になっている中で、 • さまざまなアジャイル開発プラクティスの真価を捉え、 • 立場を超えて理解を共有し、 • AIやIoTに代表される最新の技術や考え方を無理なく取り入れて、 真にアジャイルマインドでものごとを進める ためにEssenceは必須の共通基盤と言える。」 Essenceとは 資料1(日本語版まえがき xiv) なぜいま、Essenceを学ぶべきなのか？
18. 18 共通基盤としてのEssence • 実行可能、拡張可能、実用的 • ソフトウェア「以外」の大切さ • 状態指向（NOT プロセス指向） 原則 Essence 従来方式 実行可能 • アルファによって、活動すべき目標を指 示できる。 • ソフトウェア開発活動の健全な進行状態 を示す本質的な要素がアルファである。 • 文書などの成果物 拡張可能 • 多様な開発に適用できる。 • 必要に応じて実践的手法を追加できる。 • 類似した手法の集まり。 • 手法変更で、良い手法を悪い手法で 置き換えてしまう。 （方法論の総取り替え） 実用的 • 実践的で具体的な思考の枠組みにより、 実務担当者を支援。 • プロセスエンジニアや品質エンジニ アを支援 Essenceとは 山本修一郎、SEMATの概要、Business Communication, 2013 https://www.bcm.co.jp/site/youkyu/youkyu103.html 資料2 Essenceと従来のソフトウェアエンジニアリングとの比較 特徴
19. 19 手法・プロセスに埋もれている“プラクティス”を解放！ SEMATのメソッドアーキテクチャ Essence(カーネル＋言語）がOMGにおいて2014年に標準化された。 UP Scrum ・・・ ・・・ カーネル（共通基盤） 言語（図形言語） 手法・プロセス プラクティス Essence 要求 機会 作業 ステーク ホルダー ソフトウェア システム チーム 作業方法 ソリューション 活動 顧客 ＜ を実行／計画する ＜ を満たす ＜ を提供する ＜ にフォーカス する ＜ のスコープと 制約を設定する ＜ を使用／ 消費する を構築する ＞ ＜ をサポートする に対応する ＞ Essenceとは ※「カーネル」はSEMATのリーダー たちが定義したソフトウェアエンジ ニアリングの共通基盤 アルファ を持つ> アルファの状態 を目的にする> を含む> アクティビティスペース ワークプロダクト <の根拠となる を作成する/ 更新する> をまとめる> アクティビティ コンピテンシー パターン 手法・プロセス プラクティス 資料1(日本語版まえがき xiii) 、資料4
20. 20 Essenceの図形言語 Essenceとは 名称 図形 説明 アルファ Aspiration Led Process and Health Attribute 進捗と健全性の把握 が必要な事柄 状態 アルファのある状態、 チェックリストによ る確認 アクティビティ スペース 実施すべき作業のス ペースホルダー アクティビティ 作業の具体的活動 ワークプロダクト 作業の成果物 パターン 典型的な問題に対す る汎用的なソリュー ション アルファ を持つ> アルファの状態 を目的にする> を含む> アクティビティスペース ワークプロダクト <の根拠となる を作成する/ 更新する> をまとめる> アクティビティ コンピテンシー パターン ソフトウェア開発・技術活動のコンテキストの表現と評価 資料1 p58. p59, 70, 資料4
21. 21 目次 ◼ モダン・ソフトウェアエンジニアリングのEssenceの紹介 ➢ ソフトウェアエンジニアリングの問題 ➢ SEMATとEssence ➢ アルファ ➢ アクティビティスペース ➢ カーネルの拡張とエッセンシャル化 ◼ Essenceの適用事例 ➢ 適用事例一覧 ➢ 事例１：某社「プロジェクト状況チェックリストの改善」 ➢ 事例２：ITA「アルファを活用した障害事例集の改善」 ➢ 事例３：SE4BS 「匠Methodのエッセンシャル化」
22. 22 資料1: p39～p41, p50 アルファとは 名称 図形 説明 アルファ Aspiration Led Process and Health Attribute 進捗と健全性の把握 が必要な事柄 状態 アルファのある状態、 チェックリストによ る確認 アクティビティ スペース 実施すべき作業のス ペースホルダー アクティビティ 作業の具体的活動 ワークプロダクト 作業の成果物 パターン 典型的な問題に対す る汎用的なソリュー ション
23. 23 • ソフトウェアエンジニアリングの重要な要素で、進捗や健全性の評価に関する開発活動の必須要素 • ３つの関心領域に７つのアルファを定義。 • アルファは拡張可能であるため、以下の７つは「カーネルアルファ」とも呼ばれる。 資料1: p39～p41, p50 アルファとは 要求 機会 作業 ステーク ホルダー ソフトウェア システム チーム 作業方法 ソリューション 活動 顧客 ＜ を実行／計画する ＜ を満たす ＜ を提供する ＜ にフォーカス する ＜ のスコープと 制約を設定する ＜ を使用／ 消費する を構築する ＞ ＜ をサポートする に対応する ＞
24. 24 資料1: p39～p41, p50 満たすべきニーズを持つ顧客が いる。 ➢ 対処すべき問題や機会を 誰かが持っている。 ➢ 開発したソリューション を使用したり、そこから 恩恵をうけたりするス テークホルダーがいる。 その中に開発の資金を提 供する者もいる。 関心領域「顧客」に関するアルファ 要求 機会 作業 ステーク ホルダー ソフトウェア システム チーム 作業方法 ソリューション 活動 顧客 ＜ を実行／計画する ＜ を満たす ＜ を提供する ＜ にフォーカス する ＜ のスコープと 制約を設定する ＜ を使用／ 消費する を構築する ＞ ＜ をサポートする に対応する ＞
25. 25 提供するソリューションがある。 ➢ 満たすべき要求がある。 ➢ なんらかのソフトウェア システムが開発される。 関心領域「ソリューション」に関するアルファ 要求 機会 作業 ステーク ホルダー ソフトウェア システム チーム 作業方法 ソリューション 活動 顧客 ＜ を実行／計画する ＜ を満たす ＜ を提供する ＜ にフォーカス する ＜ のスコープと 制約を設定する ＜ を使用／ 消費する を構築する ＞ ＜ をサポートする に対応する ＞ 資料1: p39～p41, p50
26. 26 関心領域「活動」に関するアルファ 実施する活動がある。 ➢ 作業を開始する必要がある。 ➢ 有能な人材からなるチーム に権限と適切な作業方法を 与える。 要求 機会 作業 ステーク ホルダー ソフトウェア システム チーム 作業方法 ソリューション 活動 顧客 ＜ を実行／計画する ＜ を満たす ＜ を提供する ＜ にフォーカス する ＜ のスコープと 制約を設定する ＜ を使用／ 消費する を構築する ＞ ＜ をサポートする に対応する ＞ 資料1: p39～p41, p50
27. 27 カードでの表現
28. 28 https://www.dropbox.com/s/prps8wi55hix5lb/SEMAT_SWEngKernel_Cards_Ja.pdf SEMATカーネルカード アルファのカード
29. 29 https://www.dropbox.com/s/prps8wi55hix5lb/SEMAT_SWEngKernel_Cards_Ja.pdf SEMATカーネルカード アルファのカード
30. 30 https://www.dropbox.com/s/prps8wi55hix5lb/SEMAT_SWEngKernel_Cards_Ja.pdf SEMATカーネルカード アルファの状態 アルファの名前 アルファの 概要 アルファのカード ソフトウェアシステムを開発、あ るいは更新するための理由になり 得る十分な状況 良い機会は... • ソフトウェアシステムで解決すべき機 会が特定されている • ソフトウェアシステム導入の価値が定 義されている • QCDに見合ったソフトウェアシステム が導入されている • 明確な利益を生み出すことができる
31. 31 https://www.dropbox.com/s/prps8wi55hix5lb/SEMAT_SWEngKernel_Cards_Ja.pdf SEMATカーネルカード アルファの状態カード アルファのカード その状態に至ったことをどう判断 するの？ →アルファの状態カードを見れば いい！
32. 32 https://www.dropbox.com/s/prps8wi55hix5lb/SEMAT_SWEngKernel_Cards_Ja.pdf SEMATカーネルカード アルファの状態カード チェック リスト アルファのカード • ソフトウェアによる解決策に よって対応できる課題が識別 されている • ステークホルダーは潜在的な 価値を良く理解して投資した いと願っている • ステークホルダー間で識別さ れた課題が共有されている 課題の識別
33. 33 https://www.dropbox.com/s/prps8wi55hix5lb/SEMAT_SWEngKernel_Cards_Ja.pdf SEMATカーネルカード
34. 34 https://www.dropbox.com/s/prps8wi55hix5lb/SEMAT_SWEngKernel_Cards_Ja.pdf SEMATカーネルカード
35. 35 https://www.dropbox.com/s/prps8wi55hix5lb/SEMAT_SWEngKernel_Cards_Ja.pdf SEMATカーネルカード
36. 36 https://www.dropbox.com/s/prps8wi55hix5lb/SEMAT_SWEngKernel_Cards_Ja.pdf SEMATカーネルカード
37. 37 https://www.dropbox.com/s/prps8wi55hix5lb/SEMAT_SWEngKernel_Cards_Ja.pdf SEMATカーネルカード
38. 38 https://www.dropbox.com/s/prps8wi55hix5lb/SEMAT_SWEngKernel_Cards_Ja.pdf SEMATカーネルカード
39. 39 https://www.dropbox.com/s/prps8wi55hix5lb/SEMAT_SWEngKernel_Cards_Ja.pdf SEMATカーネルカード
40. 40 資料1: p96～p101, p50, 資料3 使用例１：「状態を追え」ゲーム(1/2) ステークホルダー 機会 ソフトウェアシステム チーム 作業方法 要求 作業 チームが合意 した現在地 未達成
41. 41 資料1: p96～p101, p50, 資料3 使用例１：「状態を追え」ゲーム(2/2) ステークホルダー 機会 ソフトウェアシステム チーム 作業方法 要求 作業 チームが合意 した現在地 次のステップで 目指す目的地 未達成
42. 42 資料4 使用例２：開発全体の計画 承認前 ビジネスケース構築 開発中 ソフトウェア開発 運用中 ソフトウェア運用 ▲ 開始の 決定 骨格システム 完成 有効システム 作成 ▲ 運用の 決定
43. 43 Excelでの表現
44. 44 小林作成 Excelでの表現：ダッシュボード（Type1） 機会 ステークホルダ ソフトウェアシステムを開発、あるいは ソフトウェアシステムに影響を与えたり、 更新するための理由になり得る十分な 影響を受けたりする人、グループ、組織 状況 良い機会は… 健全なステークホルダは… ・ ソフトウェアシステムで解決すべき ・ ソフトウェアシステムに関与する 機会が特定されている グループや組織の代表者 ・ ソフトウェアシステム導入の価値が ・ ステークホルダ間で約束した役割 定義されている を果たす ・ QCDに見合ったソフトウェアが導入 ・ 要求の合意形成のために協力する されている ・ ソフトウェアシステムの恩恵を受ける ・ 明確な利益を生み出すことができる 要求 ソフトウェアシステム ソフトウェアシステムが機会に対応する システムはソフトウェアとハードウェア ためにすべきこととステークホルダを およびソフトウェアが作り出す価値ある 満足させるためにすべきこと データで構成される 良い要求は… 良いソフトウェアシステムは… ・ 現実的なニーズにマッチしている ・ 要求を満たしている ・ スコープが明確になっている ・ 相応しいアーキテクチャを採用 ・ 一貫性があって体系化されている している ・ 開発推進を手助けしてくれる ・ メンテナンス性、拡張性、テスト可能性 を有す ・ 低コストでサポートできる 仕事 チーム 成果を獲得するために行う精神的、 特定のソフトウェアシステムの開発、 あるいは肉体的な努力をともなう活動 保守、供給、サポートに積極的に携わる 集団 健全な仕事は… 健全なチームは… ・ 規模が明らかに見積できて ・ 効果的にチーム目標を達成している 　 トラッキング可能 ・ 効果的に協力できるメンバーで構成 ・ 作業項目間の依存性を減らすために されている 分解できる ・ 自分たちの仕事に集中している ・ リスクを常に管理下に置くことが ・ 継続的な改善に取り組んでいる できる 仕事の仕方 チームの仕事をガイド、サポートするため に適用された最適なプラクティスと ツール群 良い仕事の仕方は… ・ チームに同意されている ・ リスクとテクニカルな負債を低減 できる ・ 効果的であり重複した仕事や無駄 を取り除ける ・ 仕事の仕方自身を改善できる 定着 67 活用 75 廃止 0 原則決定 100 準備完了 100 使用 100 完結 0 休止 0 終了 0 開発開始 75 協調 100 制御可能 75 最適化 100 着手 100 立上げ 100 準備完了 100 組織化 100 実装 50 運用 0 満足 50 退役 0 一貫性・体系化 60 使用可能 40 受理可能 33 準備完了 33 構想 100 アーキテクチャ決定 100 スコープ定義 100 論証完了 100 利益獲得 0 利用満足 100 価値の設定 100 活動の協業 100 解決策決定 100 合意形成 100 課題の識別 67 関係者の特定 100 解決策の方向付け 100 代表者の選定 100 課題解決 25 展開合意 100 識別する 利用する フォーカスする スコープと制約 識別する 満たす 計画と 実行 提供する 対応する 支援する 顧客 解決策 取り組み ダッシュボードType1 （７つのアルファの関連図で表示） チェックリストシート（機会） 機会 ダッシュボードへ戻る 領域 （Areas of concern) カーネル　アルファ (Alpha) 状態 (States) 達成 度 チェックリスト (Checklists) 補足情報 達成? 判断根拠 ソフトウェアによる解決策によって 対応できる課題が識別されている Yes ステークホルダは潜在的な価値を 良く理解して投資したいと願ってい る No ステークホルダ間で識別された課 題が共有されている Yes ソフトウェアによる解決策のニーズ が裏付けれている Yes ステークホルダが特定されている Yes 潜在的な問題と本質が判明してい る Yes 少なくとも1つのソフトウェアによる 解決策が提案されている Yes 解決策が成功したときの価値が設 定されている Yes 解決策の影響をステークホルダが 理解している Yes ソフトウェアシステムの価値が理解 されている Yes 解決策の主要な部分が描かれて いる Yes 解決策を開発、展開するときの制 約が明らかになっている Yes リスクが管理下に置かれている Yes 機会に対応するための論証された 解決策が提供されている Yes 有効なシステムが利用可能である No ステークホルダは展開する価値に 同意している No ステークホルダは機会の解決策に 満足している No 運用で明らかな利益が生み出され ている No 少なくとも予想通りの投資効果が 得られている No 5/6 課題解決 (Addressed) 25 顧客 (Customer) 機会 (Opportunity) 1/6 課題の識別 (Identified) 67 2/6 解決策の方向付け (Solution Needed) 100 3/6 6/6 利益獲得 (Benefit Accrued) 0 価値の設定 (Value Established) 100 4/6 解決策決定 (Viable) 100
45. 45 機会 ダッシュボードへ戻る 領域 （Areas of concern) カーネル　アルファ (Alpha) 状態 (States) 達成 度 チェックリスト (Checklists) 補足情報 達成? 判断根拠 ソフトウェアによる解決策によって 対応できる課題が識別されている Yes ステークホルダは潜在的な価値を 良く理解して投資したいと願ってい る No ステークホルダ間で識別された課 題が共有されている Yes ソフトウェアによる解決策のニーズ が裏付けれている Yes ステークホルダが特定されている Yes 潜在的な問題と本質が判明してい る Yes 少なくとも1つのソフトウェアによる 解決策が提案されている Yes 解決策が成功したときの価値が設 定されている Yes 解決策の影響をステークホルダが 理解している Yes ソフトウェアシステムの価値が理解 されている Yes 解決策の主要な部分が描かれて いる Yes 解決策を開発、展開するときの制 約が明らかになっている Yes リスクが管理下に置かれている Yes 機会に対応するための論証された 解決策が提供されている Yes 有効なシステムが利用可能である No ステークホルダは展開する価値に 同意している No ステークホルダは機会の解決策に 満足している No 運用で明らかな利益が生み出され ている No 少なくとも予想通りの投資効果が 得られている No 5/6 課題解決 (Addressed) 25 顧客 (Customer) 機会 (Opportunity) 1/6 課題の識別 (Identified) 67 2/6 解決策の方向付け (Solution Needed) 100 3/6 6/6 利益獲得 (Benefit Accrued) 0 価値の設定 (Value Established) 100 4/6 解決策決定 (Viable) 100 SEMAT Essence Alpha カーネル ダッシュボード　（Type 2) The essence of Software Engineering　 p112. Figure 13-1 Aligning the kernel to the governance framework ビジネス ケース 作成 ソフト ウェア 開発 システム 運用 退役 0 廃止 0 休止 0 利用満足 100 利益獲得 0 準備完了 33 完結 0 運用 0 終了 0 展開合意 100 課題解決 25 満足 50 実装 50 最適化 100 活用 75 合意形成 100 使用可能 40 定着 67 受理可能 33 制御可能 75 協調 100 組織化 100 解決策決定 100 使用 100 開発開始 75 準備完了 100 活動の協業 100 一貫性・体系化 60 論証完了 100 アーキテクチャ決定 100 準備完了 100 原則決定 100 代表者の選定 100 価値の設定 100 スコープ定義 100 解決策の方向付け 100 構想 100 立上げ 100 関係者の特定 100 課題の識別 67 着手 100 顧客 解決策 取り組み ステークホルダ 機会 要求 ソフトウェアシステム 仕事 チーム 仕事の仕方 ダッシュボードType2 （3つのフェーズ「ビジネスケース作成、「ソフトウェア開発」、 「システム運用」で求められる状態を表示） チェックリストシート（機会） Excelでの表現：ダッシュボード（Type2） 小林作成
46. 46 アルファの全要素（名前、概要、状態、チェックリスト）をA3一枚にまとめた SEMAT Essence Alpha カーネル 全体図 機会 ステークホルダ 良い機会は・・・ 健全なステークホルダは… 要求 ソフトウェアシステム 良い要求は・・・ 良いソフトウェアシステムは… 仕事 チーム 健全な仕事は… 健全なチームは… 仕事の仕方 良い仕事の仕方は… 全てのメンバーが仕事を進めるためにプラクティスと ツールを入手できる チーム全体が仕事の仕方の監査と改善に取り組んで いる 活用 仕事の仕方がチームで最適な形で活用されている チームメンバーが計画通り進歩している プラクティスが当たり前に適用されるチーム風土が 整っている プラクティスを実践する上でのツールの課題が解消さ れている 仕事でやるべき全てのことが達成されている 教訓とメトリクスが資産化されて再利用できる状態 となっている チームの仕事をガイド、サ ポートするために適用された 最適なプラクティスとツール 群 原則決定 原則と制約が決定されている 原則と制約が宣言されている プラクティスとツールが同意されている チームは扱い方を理解している 準備完了 重要なプラクティスとツールが準備されている プラクティスとツール間のギャップが分析され、理解さ れている ・チームに同意されている ・リスクとテクニカルな負債を 低減できる ・効果的であり重複した仕事 や無駄を取り除ける ・仕事の仕方自身を改善でき る 能力のギャップが分析され、理解されている プラクティスとツールが統合されている 使用 チームの一部メンバーが利用している 使用するプラクティスとツールが定期的に監査されて いる プラクティスとツールがチームによって改善されている 廃止 チームに利用されていない 次の利用時のために教訓が共有されている フィードバックの手続きが整っている 定着 チームメンバー全員が利用している ・効果的にチーム目標を達成 している ・効果的に協力できるメン バーで構成されている ・自分たちの仕事に集中して いる ・継続的な改善に取り組んで いる 合否基準が決まっている メンバーは仕事の進め方を知っている 管理手順が同意されている リスクの影響度が理解されている 仕事の依存関係が明確である 開発が開始している 仕事が順調に進み、リスクが管理下に置かれてい る 最適化 チームは効果的、効率的に動いている 未計画の仕事や再実施の作業が管理下に置かれ ている 状況変化に対応することができる 見積内に作業アイテムが完了している 高い品質の成果物が作り出されている 仕事の評価基準が追跡できている 撤回とやり直しが最低限である 常に無駄が排除されている 成果提供まで完了している 休止 チームに責任は生じない 仕事の成果が完成している 準備完了 費用と労力が見積もられている 組織化 チームは任期開始に必要なリソースを保有している 仕事を開始する資金とリソースが準備万端である ・規模が明らかに見積できて トラッキング可能 ・作業項目間の依存性を減ら すために分解できる ・リスクを常に管理下に置くこ とができる チームの組織構造と個人の役割が理解されている 開発開始 成果を獲得するために行う 精神的、あるいは肉体的な 努力をともなう活動 協調 チームの組織メンバーが一つのユニットになって仕 事に取り組んでいる 仕事の進捗が計測されている メンバー間のコミュニケーションがオープンで正直 である 明確に定義された作業アイテムレベルまで仕事が 詳細化されている メンバーがチームの任務に集中している チームメンバーが作業アイテムを受理して作業を進 めている メンバー個々人の目的の先にチームの成功がある 制御可能 完結 役割は移管されている 開発したソフトウェアシステムが顧客に受理されて いる メンバーは他の仕事に割当て可能である 終了 全ての残作業が完了しており、公式に仕事がク ローズされている システムの全機能を運用した事例が少なくとも一つ ある システム保守のサービスレベルが同意されてい る。 特定のソフトウェアシステム の開発、保守、供給、サポー トに積極的に携わる集団 着手 仕事を立ち上げた人物が周知されている 立上げ チーム任務が明確である 仕事の制約が明確である チームは任務達成に必要な育成プランを持ってい る 資金調達の目処が立っている 要求される能力が識別されている 仕事の優先度が明確である チーム規模が決定されている ・要求を満たしている ・相応しいアーキテクチャを 採用している ・メンテナンス性、拡張性、テ スト可能性を有す ・低コストでサポートできる 要求管理の仕組みが同意されている 重要なインタフェースとシステム構成が論証できて いる 制約と前提が識別されている 一貫性・ 体系化 明確な全体像が関係者に共有されている 使用可能 システムは使用可能であり、要求された品質特性 を達成できている 重要な利用シナリオが共有されている 受理可能 関係者が受理可能な解決策が示されている 準備完了 ユーザドキュメントが利用できる 同意された要求が変更される確度は低い ステークホルダがシステムを受理している 価値が明確である ステークホルダがシステムの運用方法を準備しよう としている 要求の優先度が明確である 機能と性能がテストされており、検収済みである 認識の不一致が対応されている 欠陥レベルが許容されている 要求がもたらす影響力が理解されている リリース内容が周知されている スコープ定義 システムの目的とスコープが同意されている 論証完了 重要なアーキテクチャの特性が論証できている 成功の判断基準が明確である ・現実的なニーズにマッチし ている ・スコープが明確になってい る ・一貫性があって体系化され ている ・開発推進を手助けしてくれ る アーキテクチャが適切であることをステークホルダ が同意している ユーザがシステムを操作可能である ソフトウェアシステムが機会 に対応するためにすべきこと とステークホルダを満足させ るためにすべきこと 満足 システムは要求とニーズを満足している 退役 システムは保守されていない 完成を妨げる未解決の要求が存在しない システム更新によるリリースはない システムは置き換えられるか開発が中止されてい る 実装 システムの受理に必要十分な要求が実装されてい る 運用 運用環境でシステムが使用されている システムを稼働させる価値のある状態にあることに ステークホルダが同意している 想定されたユーザに利用されている システムはソフトウェアと ハードウェアおよびソフトウェ アが作り出す価値あるデータ で構成される 構想 新しいシステムのニーズが明確である アーキテクチャ 決定 重要な技術リスクに対応可能なアーキテクチャが 採用されている ユーザが識別されている アーキテクチャの採用基準が同意されている 最初の出資者が識別されている 使用するプラットフォーム、技術、言語が選択されて いる 購入、構築、再利用の方針が決定している 利益獲得 運用で明らかな利益が生み出されている 利用満足 システムはステークホルダの最小限の期待以上で ある 少なくとも予想通りの投資効果が得られている ステークホルダのニーズと期待は満足されている 課題解決 機会に対応するための論証された解決策が提供さ れている 展開合意 ステークホルダの視点でシステムに対するフィード バックを提供している 有効なシステムが利用可能である システムの展開に対する準備が整ったことを確認 できている ステークホルダは展開する価値に同意している ステークホルダは機会の解決策に満足している 解決策決定 解決策の主要な部分が描かれている 合意形成 ステークホルダにとっての価値が定義され、チーム に受け入れられている 解決策を開発、展開するときの制約が明らかに なっている ステークホルダは優先度を同意している リスクが管理下に置かれている システムの展開による最小限の期待値について同 意している ・ソフトウェアシステムに関与 するグループや組織の代表 者 ・ステークホルダ間で約束し た役割を果たす ・要求の合意形成のために 協力する ・ソフトウェアシステムの恩恵 を受ける 潜在的な問題と本質が判明している ステーホルダが協業するやり方が同意されている 少なくとも1つのソフトウェアによる解決策が提案さ れている ステークホルダーがチームの仕事を尊重している 価値の設定 解決策が成功したときの価値が設定されている 活動の協業 ステークホルダが役割を果たしている 解決策の影響をステークホルダが理解している 解決策の 方向付け ソフトウェアによる解決策のニーズが裏付けれてい る 代表者の選定 ステークホルダが任命されている ステークホルダが特定されている ・ソフトウェアシステムで解決 すべき機会が特定されてい る ・ソフトウェアシステム導入の 価値が定義されている ・QCDに見合ったソフトウェア が導入されている ・明確な利益を生み出すこと ができる 自身の役割と権限について同意している チームにタイミング良くフィードバックを与えたり、決 断の場に参加している ソフトウェアシステムの価値が理解されている ステークホルダ間のコミュニケーションが良好であ る ソフトウェアシステムを開発、 あるいは更新するための理 由になり得る十分な状況 ソフトウェアシステムに影響 を与えたり、影響を受けたり する人、グループ、組織 課題の識別 ソフトウェアによる解決策によって対応できる課題 が識別されている 関係者の特定 ステークホルダが識別されている ステークホルダは潜在的な価値を良く理解して投 資したいと願っている ステークホルダ間で代表者が同意されている ステークホルダ間で識別された課題が共有されて いる ステークホルダの役割が定義されている 識別する 利用する フォーカスする スコープと制約 満たす 計画と 実行 提供する 対応する 支援する 顧客 改善策 取り組み SEMAT Essence Alpha カーネル 全体図 機会 ステークホルダ 良い機会は・・・ 健全なステークホルダは… 利益獲得 運用で明らかな利益が生み出されている 利用満足 システムはステークホルダの最小限の期待以上で ある 少なくとも予想通りの投資効果が得られている ステークホルダのニーズと期待は満足されている 課題解決 機会に対応するための論証された解決策が提供さ れている 展開合意 ステークホルダの視点でシステムに対するフィード バックを提供している 有効なシステムが利用可能である システムの展開に対する準備が整ったことを確認 できている ステークホルダは展開する価値に同意している ステークホルダは機会の解決策に満足している 解決策決定 解決策の主要な部分が描かれている 合意形成 ステークホルダにとっての価値が定義され、チーム に受け入れられている 解決策を開発、展開するときの制約が明らかに なっている ステークホルダは優先度を同意している リスクが管理下に置かれている システムの展開による最小限の期待値について同 意している ・ソフトウェアシステムに関与 するグループや組織の代表 者 ・ステークホルダ間で約束し た役割を果たす ・要求の合意形成のために 協力する ・ソフトウェアシステムの恩恵 を受ける 潜在的な問題と本質が判明している ステーホルダが協業するやり方が同意されている 少なくとも1つのソフトウェアによる解決策が提案さ れている ステークホルダーがチームの仕事を尊重している 価値の設定 解決策が成功したときの価値が設定されている 活動の協業 ステークホルダが役割を果たしている 解決策の影響をステークホルダが理解している 解決策の 方向付け ソフトウェアによる解決策のニーズが裏付けれてい る 代表者の選定 ステークホルダが任命されている ステークホルダが特定されている ・ソフトウェアシステムで解決 すべき機会が特定されてい る ・ソフトウェアシステム導入の 価値が定義されている ・QCDに見合ったソフトウェア が導入されている ・明確な利益を生み出すこと ができる 自身の役割と権限について同意している チームにタイミング良くフィードバックを与えたり、決 断の場に参加している ソフトウェアシステムの価値が理解されている ステークホルダ間のコミュニケーションが良好であ る ソフトウェアシステムを開発、 あるいは更新するための理 由になり得る十分な状況 ソフトウェアシステムに影響 を与えたり、影響を受けたり する人、グループ、組織 課題の識別 ソフトウェアによる解決策によって対応できる課題 が識別されている 関係者の特定 ステークホルダが識別されている ステークホルダは潜在的な価値を良く理解して投 資したいと願っている ステークホルダ間で代表者が同意されている ステークホルダ間で識別された課題が共有されて いる ステークホルダの役割が定義されている 識別する 利用する フォーカスする 支援する 顧客 Excelでの表現：アルファ一覧図 小林作成
47. 47 目次 ◼ モダン・ソフトウェアエンジニアリングのEssenceの紹介 ➢ ソフトウェアエンジニアリングの問題 ➢ SEMATとEssence ➢ アルファ ➢ アクティビティスペース ➢ カーネルの拡張とエッセンシャル化 ◼ Essenceの適用事例 ➢ 適用事例一覧 ➢ 事例１：某社「プロジェクト状況チェックリストの改善」 ➢ 事例２：ITA「アルファを活用した障害事例集の改善」 ➢ 事例３：SE4BS 「匠Methodのエッセンシャル化」
48. 48 資料1: p39～p41, p50 名称 図形 説明 アルファ Aspiration Led Process and Health Attribute 進捗と健全性の把握 が必要な事柄 状態 アルファのある状態、 チェックリストによ る確認 アクティビティ スペース 実施すべき作業のス ペースホルダー アクティビティ 作業の具体的活動 ワークプロダクト 作業の成果物 パターン 典型的な問題に対す る汎用的なソリュー ション アクティビティスペースとは
49. 49 あらゆる開発活動において、いくつものアクティビティを実行 することになる。しかしながらEssenceではアクティビティは 定義していない その代わりアクティビティスペースを定義している。 アクティビティスペースは ➢ アクティビティを入れる汎用的な（つまり手法に依存しな い）プレースホルダーを定義している。 ➢ 関連するアクティビティをまとめるパッケージとして使える。 ➢ チームがアルファの状態を達成するときに、３つの関心領域 （顧客、ソリューション、活動）でやるべきことのガイダン スを提供している。 アクティビティスペースとは 資料1: p66 アクティビティスペース アクティビティ アクティビティ
50. 50 プラクティスのアクティビティスペース（こと） プラクティスのアクティビティを入れる「ことの入れ物」 ソリューション 活動 顧客 要求を 理解する システムを 形成する システムを 実装する システムを テストする システムを デプロイする システムを 運用する 可能性を探索する ステークホルダーの ニーズを理解する ステークホルダーを 満足させる システムを使用する 作業を準備する アクティビティを 調整する チームを サポートする 進捗を追跡する 作業を停止する 資料1: p66, 資料3 要求 機会 作業 ステーク ホルダー ソフトウェア システム チーム 作業方法 ソリューション 活動 顧客 ＜ を実行／計画する ＜ を満たす ＜ を提供する ＜ にフォーカス する ＜ のスコープと 制約を設定する ＜ を使用／ 消費する を構築する ＞ ＜ をサポートする に対応する ＞ チームがアルファの状 態を達成するときに、 ３つの関心領域でやる べきことのガイダンス を提供している。
51. 51 プラクティスの足りないところがわかる ソリューション 活動 顧客 要求を 理解する システムを 形成する システムを 実装する システムを テストする システムを デプロイする システムを 運用する 可能性を探索する ステークホルダーの ニーズを理解する ステークホルダーを 満足させる システムを使用する 作業を準備する アクティビティを 調整する チームを サポートする 進捗を追跡する 作業を停止する アクターとユース ケースを発見する ユースケーススラ イスを準備する ユースケースをス ライスする アクターとユース ケースを発見する マイクロサービス を特定する 進化可能にする マイクロサービス を進化させる ユースケーススラ イスをテストする スプリント プランニング デイリースクラム スプリント プランニング スプリント レトロスペクティブ スプリント レビュー 資料1: p253, 資料3
52. 52 目次 ◼ モダン・ソフトウェアエンジニアリングのEssenceの紹介 ➢ ソフトウェアエンジニアリングの問題 ➢ SEMATとEssence ➢ アルファ ➢ アクティビティスペース ➢ カーネルの拡張とエッセンシャル化 ◼ Essenceの適用事例 ➢ 適用事例一覧 ➢ 事例１：某社「プロジェクト状況チェックリストの改善」 ➢ 事例２：ITA「アルファを活用した障害事例集の改善」 ➢ 事例３：SE4BS 「匠Methodのエッセンシャル化」
53. 53 ⚫ 「Essenceカーネル」とはSEMATのリーダーたちが定義したソフト ウェアエンジニアリングの共通基盤 ⚫ 前述の７つのアルファは「カーネルアルファ」と呼ばれる ⚫ カーネルにある「カーネルアルファ」（もの）や「アクティビティス ペース」（こと）では不十分なことがある カーネルの拡張とエッセンシャル化 カーネルアルファ 要求 機会 作業 ステーク ホルダー ソフトウェア システム チーム 作業方法 ソリューション 活動 顧客 ＜ を実行／計画する ＜ を満たす ＜ を提供する ＜ にフォーカス する ＜ のスコープと 制約を設定する ＜ を使用／ 消費する を構築する ＞ ＜ をサポートする に対応する ＞ ソリューション 活動 顧客 要求を 理解する システムを 形成する システムを 実装する システムを テストする システムを デプロイする システムを 運用する 可能性を探索する ステークホルダーの ニーズを理解する ステークホルダーを 満足させる システムを使用する 作業を準備する アクティビティを 調整する チームを サポートする 進捗を追跡する 作業を停止する アクティビティスペース 資料1: p28, 資料3
54. 54 ⚫ プラクティスの作成時に「カーネルアルファ」を継承して拡張すれば よい • e.g.「要求」を継承した「プロダクトバックログアイテム」 • e.g.「作業を準備する」を継承した「チームのキックオフ」 カーネルの拡張とエッセンシャル化 カーネルアルファ 要求 機会 作業 ステーク ホルダー ソフトウェア システム チーム 作業方法 ソリューション 活動 顧客 ＜ を実行／計画する ＜ を満たす ＜ を提供する ＜ にフォーカス する ＜ のスコープと 制約を設定する ＜ を使用／ 消費する を構築する ＞ ＜ をサポートする に対応する ＞ ソリューション 活動 顧客 要求を 理解する システムを 形成する システムを 実装する システムを テストする システムを デプロイする システムを 運用する 可能性を探索する ステークホルダーの ニーズを理解する ステークホルダーを 満足させる システムを使用する 作業を準備する アクティビティを 調整する チームを サポートする 進捗を追跡する 作業を停止する アクティビティスペース 要求 プロダクト バックログ アイテム を含む> 作業を準備する チームのキックオフ を含む> 資料1: p28, 資料3
55. 55 資料1 p58, 180 ◼ Essenceのツールである図、説明、チェックリストのカードを使えば、プラク ティスを簡潔に記述できる。このアプローチをエッセンシャル化と呼んでいる。 ◼ エッセンシャル化することで、チームはプラクティスのギャップの存在に気づく ことができるようになる。 ➢ 新しい明示的なプラクティスが必要になるところ ➢ 既存の明示的なプラクティスに改善が必要なこと がわかるようになる。 アルファ を持つ> アルファの状態 を目的にする> を含む> ワークプロダクト <の根拠となる を作成する/ 更新する> をまとめる> アクティビティ コンピテンシー パターン
56. 56 スクラムの全体像 スクラムチーム プロダクト オーナー スクラム マスター 開発者 プロダクト バックログ スプリント バックログ スプリント プランニング デイリー スクラム スプリント レビュー スプリント レトロスペクティブ スプリント 出荷判断可能な インクリメント 資料1:p156、 資料3
57. 57 Essence言語にマッピング スクラムチーム プロダクト オーナー スクラム マスター 開発者 プロダクト バックログ スプリント バックログ スプリント プランニング デイリー スクラム スプリント レビュー スプリント レトロスペクティブ スプリント インクリメント プロダクト バックログ アイテム 資料1:p159 、 資料3
58. 58 Essence言語で表現したもの スクラム チーム プロダクト オーナー スクラム マスター 開発者 [作業] （カーネル） [要求] （カーネル） [ソフトウェアシステム] （カーネル） プロダクト バックログアイテム スプリント スプリント バックログ インクリメント を含む> に記述されている> をターゲットにする> として デリバリーされる> を含む> に進化して 記述される> スプリント プランニング デイリー スクラム スプリント レビュー スプリント レトロスペクティブ [アクティビティを調整する] （カーネル） [進捗を追跡する] （カーネル） [チームをサポートする] （カーネル） で優先順位 付けされ ている> プロダクト バックログ 資料1:p160 、 資料3
59. 59 目次 ◼ モダン・ソフトウェアエンジニアリングのEssenceの紹介 ➢ ソフトウェアエンジニアリングの問題 ➢ SEMATとEssence ➢ アルファ ➢ アクティビティスペース ➢ カーネルの拡張とエッセンシャル化 ◼ Essenceの適用事例 ➢ 適用事例一覧 ➢ 事例１：某社「プロジェクト状況チェックリストの改善」 ➢ 事例２：ITA「アルファを活用した障害事例集の改善」 ➢ 事例３：SE4BS 「匠Methodのエッセンシャル化」
60. 60 適用事例一覧 主な適用事例 実施者 使用した要素 事例# 某社「プロジェクト状況チェックリストの改善」(2014) 小林 • アルファ 事例1 ITA「アルファを活用した障害事例集の改善」(2016) ITAメンバー 小林 鷲崎教授 • アルファ 事例2 XP祭り2016「プロジェクトの多面的な振り返りワーク ショップ」 鷲崎教授 小林 • アルファ ー XP祭り2017「7つのSEMATアルファとScrumの関連付け ワークショップ」 鷲崎教授 小林 • アルファ ー SE4BS 「匠Methodのエッセンシャル化」(2020) 小林 • アルファ • アクティビティスペース • ワークプロダクト • エッセンシャル化 事例3
61. 61 目次 ◼ モダン・ソフトウェアエンジニアリングのEssenceの紹介 ➢ ソフトウェアエンジニアリングの問題 ➢ SEMATとEssence ➢ アルファ ➢ アクティビティスペース ➢ カーネルの拡張とエッセンシャル化 ◼ Essenceの適用事例 ➢ 適用事例一覧 ➢ 事例１：某社「プロジェクト状況チェックリストの改善」 ➢ 事例２：ITA「アルファを活用した障害事例集の改善」 ➢ 事例３：SE4BS 「匠Methodのエッセンシャル化」
62. 62 （事例1）視野の拡張 某社「プロジェクト状況チェックリストの改善」 （アルファの活用）
63. 63 現場力向上のためのSEMATチェックリストの活用に関する取り組み事例 2014/11/28 (小林浩) 工程完了チェックリスト（主に品質保証チームが使用） ダッシュボード チェックシート 9つの工程用、全422項目 • 現時点でのプロジェクトの状況が把握しにくい • 現場のPMやメンバーが日常的に使うには項目が多すぎる 現在のチェックリストの課題
64. 64 現在のチェックリストをEssenceを使って改善 工程完了チェックリスト アルファの状態チェックリスト 特に関係の深い項目を選んでリンクした 現場力向上のためのSEMATチェックリストの活用に関する取り組み事例 2014/11/28 (小林浩)
65. 65 現在のチェックリストをEssenceを使って改善 質問項目の合理化 ⚫ アルファの状態チェックリストと紐づいた項目（４割 程度）は、特に重要な項目と思われる。 ⚫ それ以外は、まとめたり、簡略化できるかもしれない。 現場力向上のためのSEMATチェックリストの活用に関する取り組み事例 2014/11/28 (小林浩) 工程完了チェックリストの項目の４割程度は、アルファの状態チェックリストと 関連していることがわかった。 工程完了チェックリストをアルファの状態チェックリストの項目と紐づけてみたら
66. 66 現在のチェックリストをEssenceを使って改善 工程完了チェックリストがカバー していない弱い領域が見えてきた 大きな視点でのチェック漏れを無くす （続き）工程完了チェックリストをアルファの状態チェックリストの項目と紐づけてみたら 現場力向上のためのSEMATチェックリストの活用に関する取り組み事例 2014/11/28 (小林浩) 「機会」に関する項目が少ない 全体的に、”計画”に比べて”監視・ 制御・改善”が弱い
67. 67 目次 ◼ モダン・ソフトウェアエンジニアリングのEssenceの紹介 ➢ ソフトウェアエンジニアリングの問題 ➢ SEMATとEssence ➢ アルファ ➢ アクティビティスペース ➢ カーネルの拡張とエッセンシャル化 ◼ Essenceの適用事例 ➢ 適用事例一覧 ➢ 事例１：某社「プロジェクト状況チェックリストの改善」 ➢ 事例２：ITA「アルファを活用した障害事例集の改善」 ➢ 事例３：SE4BS 「匠Methodのエッセンシャル化」
68. 68 （事例2）原因の深堀 ITA「アルファを活用した障害事例集の改善」 （アルファの活用）
69. 69 ITA（Information Technology Alliance）とは 独立系情報サービス会社による任意団体 http://ita.gr.jp/about 発足：1995年2月10日、 加盟：17社 合計従業員：約8,200人、売上高：約1,260億円） 目的： お客様へ高付加価値の情報サービスを提供するにあたって、メーカーやユーザーに依存しない 独立系会員各社が、独自の技術的競合力を高めるために、共同研究活動や情報交換などを行う とともに会員各社が営業面、技術面で協力し合うことにより個々の企業の能力を超えた事業展 開を図る。（ＩＴＡ規約より）
70. 70 ITAシステム高信頼化研究会の成果物 2015年の成果物 障害事例集 4つのサブシステムでの情報を関連付けして表示するシステム開発で、参照でき ない情報があり、使えないとUATでクレームをもらってリリース判定でNGとなり リリースが1か月延期となった。 運用保守で新たに立ち上がったプロジェクトだが現有のコアメンバは基幹システム の別案件で多忙であり、PMもそちらにかかりきりとならざるを得ない状況であった。 そこで比較的ゆとりのあったメンバ（当該システム経験2年程度）を2名アサインして その他5名は外部から追加のメンバでプロジェクトを始めた。 客先の担当も、システムを熟知してない担当であった。 スケジュール通りにタスクは進行し、レビューも適宜行われており、ユーザ側担当 からはたいした指摘がなかった。実際に、設計通りにプログラムは作成され、設計 で謳った内容は、テストされていた。ただし、業務視点でのレビュー指摘がまったく されておらず、ある業務フロー分のデータ抽出が全くと言っていいほどダメだった。 タスクのリーダは、別プロジェクト遂行中のサブシステムを熟知しているメンバへの レビュー依頼を躊躇し、UATになるまで特定パターンの対応ができていないことに 気付けなかった。 問題 設計通りでも業務視点が欠けては意味がない 原因 PM 約2年経験しているし、スケジュール通りだから問題ないだろう・ 基幹のほうに注力して大丈夫だ タスクリーダ 基幹メンバは忙しそうだ。特に指摘もないし、わざわざレ ビューしてもらうのも申し訳ない。このままで行けるだろう。 顧客担当者 このシステムのことわからないし、スケジュールさえ問題なけ れば、任せておけばいいだろう。 コアメンバにITA仕様書を業務的視点からチェックさせ、欠けている業務フローを 割り出してもらい、それを元に再テストと不具合改修を行った プロジェクトをアサイン優先ではじめないこと。 業務視点での見極めを第一とすること 業務視点の見極めができない時は、どんなに多忙でも有識者の意見を求めること ユーザ担当者の力量も見極めること 対策 教訓 業務的視点が 欠けた設計 設計不備を見 抜けない レビュー 使えない業 務パターン 発生 リリース 延期 業務視点での 設計確認 有識者の アサイン 有識者に対す る遠慮 リリース判定 NG プロジェクト教訓集の改善へ向けたSEMAT適用の利点と課題の考察 (2016年 ITAシステム高信頼化研究会) ◼ 参考にした取り組み・資料 ◼ 当研究会のアドバイザー • (当時)IPA 山下 博之 氏 • 早稲田大学 鷲崎 弘宜 教授 • 早稲田大学 新谷 勝利 氏 情報処理システム 高信頼化教訓集 （IPA/SEC） https://www.ipa.go.jp/archive/digital/iot-en-ci/system/system.html
71. 71 課題と改善アプローチ 課題 原因分析が不十分の可能性 対策検討が不十分の可能性 分析方法が属人的で、まと め方も統一されておらず分 かりにくい 広い視野を保ち、かつ深堀 した原因分析が可能になる 視野が狭いかも、 視点にもバラつき がありそうだ し。。。 SEMATのEssence が視野を広げ、共 通の視点を提供し てくれますよ なかなか いいぞ！ 十分な対策が洗い出される 分析方法やまとめ方が統一 される 4つのサブシステムでの情報を関連付けして表示するシステム開発で、参照でき ない情報があり、使えないとUATでクレームをもらってリリース判定でNGとなり リリースが1か月延期となった。 運用保守で新たに立ち上がったプロジェクトだが現有のコアメンバは基幹システム の別案件で多忙であり、PMもそちらにかかりきりとならざるを得ない状況であった。 そこで比較的ゆとりのあったメンバ（当該システム経験2年程度）を2名アサインして その他5名は外部から追加のメンバでプロジェクトを始めた。 客先の担当も、システムを熟知してない担当であった。 スケジュール通りにタスクは進行し、レビューも適宜行われており、ユーザ側担当 からはたいした指摘がなかった。実際に、設計通りにプログラムは作成され、設計 で謳った内容は、テストされていた。ただし、業務視点でのレビュー指摘がまったく されておらず、ある業務フロー分のデータ抽出が全くと言っていいほどダメだった。 タスクのリーダは、別プロジェクト遂行中のサブシステムを熟知しているメンバへの レビュー依頼を躊躇し、UATになるまで特定パターンの対応ができていないことに 気付けなかった。 問題 設計通りでも業務視点が欠けては意味がない 原因 PM 約2年経験しているし、スケジュール通りだから問題ないだろう・ 基幹のほうに注力して大丈夫だ タスクリーダ 基幹メンバは忙しそうだ。特に指摘もないし、わざわざレ ビューしてもらうのも申し訳ない。このままで行けるだろう。 顧客担当者 このシステムのことわからないし、スケジュールさえ問題なけ れば、任せておけばいいだろう。 コアメンバにITA仕様書を業務的視点からチェックさせ、欠けている業務フローを 割り出してもらい、それを元に再テストと不具合改修を行った プロジェクトをアサイン優先ではじめないこと。 業務視点での見極めを第一とすること 業務視点の見極めができない時は、どんなに多忙でも有識者の意見を求めること ユーザ担当者の力量も見極めること 対策 教訓 業務的視点が 欠けた設計 設計不備を見 抜けない レビュー 使えない業 務パターン 発生 リリース 延期 業務視点での 設計確認 有識者の アサイン 有識者に対す る遠慮 リリース判定 NG 適用効果の仮説 結果 新たな真の原因が発見でき た。 追加の対策を洗い出すこと ができた。 統一には至らなかった。 Essenceの解釈方法の統一、 ITA参加企業の実情に 合わせたカスタマイズ の必要性を感じた。 SEMAT Essence Alpha カーネル 全体図 機会 ステークホルダ 良い機会は・・・ 健全なステークホルダは… ソフトウェアシステムを開発、あ るいは更新するための理由に なり得る十分な状況 ・ソフトウェアシステムで解決す べき機会が特定されている ・ソフトウェアシステム導入の 価値が定義されている ・QCDに見合ったソフトウェア が導入されている ・明確な利益を生み出すことが できる ソフトウェアシステムに影響を 与えたり、影響を受けたりする 人、グループ、組織 ・ソフトウェアシステムに関与す るグループや組織の代表者 ・ステークホルダ間で約束した 役割を果たす ・要求の合意形成のために協 力する ・ソフトウェアシステムの恩恵を 受ける 展開合意 利用満足 システムの展開による最小限の期待値について同意 している ステークホルダの視点でシステムに対するフィード バックを提供している システムの展開に対する準備が整ったことを確認でき ている システムはステークホルダの最小限の期待以上であ る ステークホルダのニーズと期待は満足されている 少なくとも予想通りの投資効果が得られている 関係者の特定 代表者の選定 活動の協業 合意形成 ステークホルダーがチームの仕事を尊重している ステークホルダが役割を果たしている チームにタイミング良くフィードバックを与えたり、決断 の場に参加している ステークホルダ間のコミュニケーションが良好である ステークホルダにとっての価値が定義され、チームに 受け入れられている ステークホルダは優先度を同意している ステークホルダが識別されている ステークホルダ間で代表者が同意されている ステークホルダの役割が定義されている ステークホルダが任命されている 自身の役割と権限について同意している ステーホルダが協業するやり方が同意されている 有効なシステムが利用可能である ステークホルダは展開する価値に同意している ステークホルダは機会の解決策に満足している 運用で明らかな利益が生み出されている 解決策の 方向付け 価値の設定 解決策決定 課題解決 利益獲得 解決策の影響をステークホルダが理解している ソフトウェアシステムの価値が理解されている 解決策の主要な部分が描かれている 解決策を開発、展開するときの制約が明らかになって いる リスクが管理下に置かれている 機会に対応するための論証された解決策が提供され ている 課題の識別 潜在的な問題と本質が判明している 少なくとも1つのソフトウェアによる解決策が提案され ている 解決策が成功したときの価値が設定されている ソフトウェアによる解決策によって対応できる課題が 識別されている ステークホルダは潜在的な価値を良く理解して投資し たいと願っている ステークホルダ間で識別された課題が共有されている ソフトウェアによる解決策のニーズが裏付けれている ステークホルダが特定されている 識別する 利用する フォーカスする 支援する 顧客 【ガイド】 ノウハウ集の最初の事例「(1)要件 定義」で、問題発覚時の状況を、 SEMATのアルファのステータスを 使って表す。 ▪やり方 (1)事例を読んで、問題発覚時の状 況を自分なりに想定する (2)想定した内容を基に、全アル ファの全ステータスにある全チェッ ク結果を次の要領で色分けする 赤：できていない 青：できている 黄：何とも言えない (3)必要に応じて付箋を貼るような 形でメモを残す 合意形成する方法やその機会 が決まっていない。 他部署との連携が取れていな い。 前提 ・登場人物（PM、運用管理者、作業者)の上長視 点でチェック 考察 ・決まったルールよりも属人的経験を重視する職 場環境になっている。それ故、ルールが形骸化し ても最適化されない為、更に属人化が進む悪循 環が発生している。 ・ルール無視を長年続けている内、問題認識が 組織的に麻痺してしまっている。 早大鷲崎教授 プロジェクト教訓集の改善へ向けたSEMAT適用の利点と課題の考察 (2016年 ITAシステム高信頼化研究会)
72. 72 改善例 プロジェクト教訓集の改善へ向けたSEMAT適用の利点と課題の考察 (2016年 ITAシステム高信頼化研究会) 因果関係図 凡例 まとめ・教訓 ⑩サービス開局遅延 ①組織的なモラル ハザードが常態化し ていた ⑤運用管理者が承 認部署を通さずに手 順書を修正した ⑧膨大なデータ入力 を手作業で行ってい る (A)関連するシステム への影響調査および 関連部署への調整を 行った後、データ入力 作業の自動化の提案 を検討。 (B)些細なルール違反 であっても遵守するよ う日頃から指導する。 ※破れ窓理論の実践。 (C)既存の工程や規制に対し て、本当に必要なものか、出 来ない事を押し付けていな いかなど点検し、必要に応じ て定められたルールの見直 しを行う。 ⑨本番データの手入 力ミスがあった ⑥作業手順書に書 き間違いがあった 最終的な問題 原因 根本原因 解決策 (D)定期的なミーティングを開 催するなど、状況把握と情 報収集に努める。 ⑦異常ステータスを 正常と誤認した ④作業者が承認部署 を通していない手順 書を受理した ②改善案や相談事が 放置されていた。 ③効率重視でルール 破りが横行していた。 破れ窓理論の実践。些細な緩みがやがて大きな事故を生む。 守れない規則や制限を掛ける事は逆効果。可用性を考えて必要ならルールを修正すべき。 悪い話しでも話し易い環境作り。自然に情報が巡回する風通しの良い職場の空気をつくろう。 因果関係図（オリジナル） アルファの観点で因果関係を再度追ってみた ＋
73. 73 改善例 プロジェクト教訓集の改善へ向けたSEMAT適用の利点と課題の考察 (2016年 ITAシステム高信頼化研究会) 機会 ステークホルダ 良い機会は・・・ 健全なステークホルダは… 要求 ソフトウェアシステム 良い要求は・・・ 良いソフトウェアシステムは… 仕事 チーム 健全な仕事は… 健全なチームは… 仕事の仕方 良い仕事の仕方は… 全てのメンバーが仕事を進めるためにプラクティスと ツールを入手できる チーム全体が仕事の仕方の監査と改善に取り組んで いる 活用 仕事の仕方がチームで最適な形で活用されている チームメンバーが計画通り進歩している プラクティスが当たり前に適用されるチーム風土が 整っている プラクティスを実践する上でのツールの課題が解消さ れている 仕事でやるべき全てのことが達成されている 教訓とメトリクスが資産化されて再利用できる状態 となっている チームの仕事をガイド、サ ポートするために適用された 最適なプラクティスとツール 群 原則決定 原則と制約が決定されている 原則と制約が宣言されている プラクティスとツールが同意されている チームは扱い方を理解している 準備完了 重要なプラクティスとツールが準備されている プラクティスとツール間のギャップが分析され、理解さ れている ・チームに同意されている ・リスクとテクニカルな負債を 低減できる ・効果的であり重複した仕事 や無駄を取り除ける ・仕事の仕方自身を改善でき る 能力のギャップが分析され、理解されている プラクティスとツールが統合されている 使用 チームの一部メンバーが利用している 使用するプラクティスとツールが定期的に監査されて いる プラクティスとツールがチームによって改善されている 廃止 チームに利用されていない 次の利用時のために教訓が共有されている フィードバックの手続きが整っている 定着 チームメンバー全員が利用している ・効果的にチーム目標を達成 している ・効果的に協力できるメン バーで構成されている ・自分たちの仕事に集中して いる ・継続的な改善に取り組んで いる 合否基準が決まっている メンバーは仕事の進め方を知っている 管理手順が同意されている リスクの影響度が理解されている 仕事の依存関係が明確である 開発が開始している 仕事が順調に進み、リスクが管理下に置かれてい る 最適化 チームは効果的、効率的に動いている 未計画の仕事や再実施の作業が管理下に置かれ ている 状況変化に対応することができる 見積内に作業アイテムが完了している 高い品質の成果物が作り出されている 仕事の評価基準が追跡できている 撤回とやり直しが最低限である 常に無駄が排除されている 成果提供まで完了している 休止 チームに責任は生じない 仕事の成果が完成している 準備完了 費用と労力が見積もられている 組織化 チームは任期開始に必要なリソースを保有している 仕事を開始する資金とリソースが準備万端である ・規模が明らかに見積できて トラッキング可能 ・作業項目間の依存性を減ら すために分解できる ・リスクを常に管理下に置くこ とができる チームの組織構造と個人の役割が理解されている 開発開始 成果を獲得するために行う 精神的、あるいは肉体的な 努力をともなう活動 協調 チームの組織メンバーが一つのユニットになって仕 事に取り組んでいる 仕事の進捗が計測されている メンバー間のコミュニケーションがオープンで正直 である 明確に定義された作業アイテムレベルまで仕事が 詳細化されている メンバーがチームの任務に集中している チームメンバーが作業アイテムを受理して作業を進 めている メンバー個々人の目的の先にチームの成功がある 制御可能 完結 役割は移管されている 開発したソフトウェアシステムが顧客に受理されて いる メンバーは他の仕事に割当て可能である 終了 全ての残作業が完了しており、公式に仕事がク ローズされている システムの全機能を運用した事例が少なくとも一つ ある システム保守のサービスレベルが同意されてい る。 特定のソフトウェアシステム の開発、保守、供給、サポー トに積極的に携わる集団 着手 仕事を立ち上げた人物が周知されている 立上げ チーム任務が明確である 仕事の制約が明確である チームは任務達成に必要な育成プランを持ってい る 資金調達の目処が立っている 要求される能力が識別されている 仕事の優先度が明確である チーム規模が決定されている ・要求を満たしている ・相応しいアーキテクチャを 採用している ・メンテナンス性、拡張性、テ スト可能性を有す ・低コストでサポートできる 要求管理の仕組みが同意されている 重要なインタフェースとシステム構成が論証できて いる 制約と前提が識別されている 一貫性・ 体系化 明確な全体像が関係者に共有されている 使用可能 システムは使用可能であり、要求された品質特性 を達成できている 重要な利用シナリオが共有されている 受理可能 関係者が受理可能な解決策が示されている 準備完了 ユーザドキュメントが利用できる 同意された要求が変更される確度は低い ステークホルダがシステムを受理している 価値が明確である ステークホルダがシステムの運用方法を準備しよう としている 要求の優先度が明確である 機能と性能がテストされており、検収済みである 認識の不一致が対応されている 欠陥レベルが許容されている 要求がもたらす影響力が理解されている リリース内容が周知されている スコープ定義 システムの目的とスコープが同意されている 論証完了 重要なアーキテクチャの特性が論証できている 成功の判断基準が明確である ・現実的なニーズにマッチし ている ・スコープが明確になってい る ・一貫性があって体系化され ている ・開発推進を手助けしてくれ る アーキテクチャが適切であることをステークホルダ が同意している ユーザがシステムを操作可能である ソフトウェアシステムが機会 に対応するためにすべきこと とステークホルダを満足させ るためにすべきこと 満足 システムは要求とニーズを満足している 退役 システムは保守されていない 完成を妨げる未解決の要求が存在しない システム更新によるリリースはない システムは置き換えられるか開発が中止されてい る 実装 システムの受理に必要十分な要求が実装されてい る 運用 運用環境でシステムが使用されている システムを稼働させる価値のある状態にあることに ステークホルダが同意している 想定されたユーザに利用されている システムはソフトウェアと ハードウェアおよびソフトウェ アが作り出す価値あるデータ で構成される 構想 新しいシステムのニーズが明確である アーキテクチャ 決定 重要な技術リスクに対応可能なアーキテクチャが 採用されている ユーザが識別されている アーキテクチャの採用基準が同意されている 最初の出資者が識別されている 使用するプラットフォーム、技術、言語が選択されて いる 購入、構築、再利用の方針が決定している 利益獲得 運用で明らかな利益が生み出されている 利用満足 システムはステークホルダの最小限の期待以上で ある 少なくとも予想通りの投資効果が得られている ステークホルダのニーズと期待は満足されている 課題解決 機会に対応するための論証された解決策が提供さ れている 展開合意 ステークホルダの視点でシステムに対するフィード バックを提供している 有効なシステムが利用可能である システムの展開に対する準備が整ったことを確認 できている ステークホルダは展開する価値に同意している ステークホルダは機会の解決策に満足している 解決策決定 解決策の主要な部分が描かれている 合意形成 ステークホルダにとっての価値が定義され、チーム に受け入れられている 解決策を開発、展開するときの制約が明らかに なっている ステークホルダは優先度を同意している リスクが管理下に置かれている システムの展開による最小限の期待値について同 意している ・ソフトウェアシステムに関与 するグループや組織の代表 者 ・ステークホルダ間で約束し た役割を果たす ・要求の合意形成のために 協力する ・ソフトウェアシステムの恩恵 を受ける 潜在的な問題と本質が判明している ステーホルダが協業するやり方が同意されている 少なくとも1つのソフトウェアによる解決策が提案さ れている ステークホルダーがチームの仕事を尊重している 価値の設定 解決策が成功したときの価値が設定されている 活動の協業 ステークホルダが役割を果たしている 解決策の影響をステークホルダが理解している 解決策の 方向付け ソフトウェアによる解決策のニーズが裏付けれてい る 代表者の選定 ステークホルダが任命されている ステークホルダが特定されている ・ソフトウェアシステムで解決 すべき機会が特定されてい る ・ソフトウェアシステム導入の 価値が定義されている ・QCDに見合ったソフトウェア が導入されている ・明確な利益を生み出すこと ができる 自身の役割と権限について同意している チームにタイミング良くフィードバックを与えたり、決 断の場に参加している ソフトウェアシステムの価値が理解されている ステークホルダ間のコミュニケーションが良好であ る ソフトウェアシステムを開発、 あるいは更新するための理 由になり得る十分な状況 ソフトウェアシステムに影響 を与えたり、影響を受けたり する人、グループ、組織 課題の識別 ソフトウェアによる解決策によって対応できる課題 が識別されている 関係者の特定 ステークホルダが識別されている ステークホルダは潜在的な価値を良く理解して投 資したいと願っている ステークホルダ間で代表者が同意されている ステークホルダ間で識別された課題が共有されて いる ステークホルダの役割が定義されている 識別する 利用する フォーカスする スコープと制約 満たす 計画と 実行 提供する 対応する 支援する 顧客 改善策 取り組み ②③④ ・ルールは存在するが、運用管理者のルール違反 が常態化していた ①②③ ・組織的なモラルハ ザードが起きていた ・改善案や相談事放 置 ・ルール破りが横行 ・運用管理者は、課 題や問題は自分なり に理解していた。つ まり改善策に対する 要求は理解していた。 ・しかしその要求は 周りに共有されず、 運用管理者は独断 で手順書を修正し、 展開していた。 ・手作業の自動化の 必要性に関する議 論は行われていない （「構想」にも至って ④⑤ ・運用管理者及 び作業者が、承 認部署を通さず 手順書変更・実 施。 ⑥⑧ ⑥⑧ ・手順書に誤りが あった ・運用管理者の 独断で、同意され たものではなかっ た ・改善策の一つと 思われる「手作業 の自動化」に検 討はされていな い（「アーキテク チャー決定にも 至っていない」） ⑩ ⑩ ・復旧に二時 間かかった ・支店窓口 社員は顧客 照会を手作 業で行った ・窓口で待たされた お客様からたくさん のクレーム ・CEOから直々の叱 責を受けた （コメント） ・この事例での改 善策とは何だろ う？ -->「修正された手 順書」「自動化」の 二つを改善策とみ なすと良いと気が （コメント） ・この事例の場合ソフトウェアという より「改善策」とみなすと良いと思っ （全体に関するコメント） ・NGとしたステータスの前段階のステータスはとりあ えず問題無さそうだと判断したが、実際にはあった 可能性もある。もしそのようなものが見つかれば、 新たな原因や根本原因の有力な候補になる。 （特に「チーム」「仕事の仕方」について、気になっ た） （気がついたこと） ・「ソフトウェア」=「解決策」と考えると、どんなフェー ズでも使えると思った。更に言えば、ソフトウェア開 発に限らず使えると思った。（チェックリストだけその ビジネス領域に合ったものに変えれば良い） アルファの全体図上での因果関係分析 SEMAT版因果関係図 αS/Wシステム(改善 策): 「論証完了」NG α機会: 「利益獲得」NG αステークホルダ: 「利用満足」NG α要求: 「一貫性・体系化」NG α仕事: 「制御可能」NG αチーム: 「協調」NG α仕事の仕方: 「使用」NG 顧客 改善策 取り組み アルファの状態のまとめ（どこがNGだったのか）
74. 74 改善例 プロジェクト教訓集の改善へ向けたSEMAT適用の利点と課題の考察 (2016年 ITAシステム高信頼化研究会) 因果関係図 凡例 まとめ・教訓 ⑩サービス開局遅延 ①組織的なモラル ハザードが常態化し ていた ⑤運用管理者が承 認部署を通さずに手 順書を修正した ⑧膨大なデータ入力 を手作業で行ってい る (A)関連するシステム への影響調査および 関連部署への調整を 行った後、データ入力 作業の自動化の提案 を検討。 (B)些細なルール違反 であっても遵守するよ う日頃から指導する。 ※破れ窓理論の実践。 (C)既存の工程や規制に対し て、本当に必要なものか、出 来ない事を押し付けていな いかなど点検し、必要に応じ て定められたルールの見直 しを行う。 ⑨本番データの手入 力ミスがあった ⑥作業手順書に書 き間違いがあった 最終的な問題 原因 根本原因 解決策 (D)定期的なミーティングを開 催するなど、状況把握と情 報収集に努める。 ⑦異常ステータスを 正常と誤認した ④作業者が承認部署 を通していない手順 書を受理した ②改善案や相談事が 放置されていた。 ③効率重視でルール 破りが横行していた。 破れ窓理論の実践。些細な緩みがやがて大きな事故を生む。 守れない規則や制限を掛ける事は逆効果。可用性を考えて必要ならルールを修正すべき。 悪い話しでも話し易い環境作り。自然に情報が巡回する風通しの良い職場の空気をつくろう。 因果関係図（オリジナル） 因果関係図 凡例 まとめ・教訓 ⑩サービス開局遅延 ①組織的なモラル ハザードが常態化し ていた ⑤運用管理者が承 認部署を通さずに手 順書を修正した ⑧膨大なデータ入力 を手作業で行ってい る (A)関連するシステム への影響調査および 関連部署への調整を 行った後、データ入力 作業の自動化の提案 を検討。 (B)些細なルール違反 であっても遵守するよ う日頃から指導する。 ※破れ窓理論の実践。 (C)既存の工程や規制に対し て、本当に必要なものか、出 来ない事を押し付けていな いかなど点検し、必要に応じ て定められたルールの見直 しを行う。 ⑨本番データの手入 力ミスがあった ⑥作業手順書に書 き間違いがあった 最終的な問題 原因 根本原因 解決策 (D)定期的なミーティングを開 催するなど、状況把握と情 報収集に努める。 ⑦異常ステータスを 正常と誤認した ④作業者が承認部署 を通していない手順 書を受理した ②改善案や相談事が 放置されていた。 ③効率重視でルール 破りが横行していた。 破れ窓理論の実践。些細な緩みがやがて大きな事故を生む。 守れない規則や制限を掛ける事は逆効果。可用性を考えて必要ならルールを修正すべき。 悪い話しでも話し易い環境作り。自然に情報が巡回する風通しの良い職場の空気をつくろう。 （追加）改善案等が 一覧管理されておら ず、ステータストラッ キングができなかっ （追加）課題や改善 案の管理がタスク化 されておらず、責任 者が不明確であった (追加)課題や改善案の管理 をWBS上に追加し、責任者を 明確にする 因果関係図（改善後） ②改善案や相談事が 放置されていた。 （追加）改善案等が 一覧管理されておら ず、ステータスト ラッキングができな かった （追加）課題や改善 案の管理がタスク化 されておらず、責任 者が不明確であった 【ソリューション】 (追加)課題や改善案 の管理をWBS上に追 加し、責任者を明確 にする 主に「仕事の仕方」 「仕事」「チーム」の アルファからヒントを得た
75. 75 目次 ◼ モダン・ソフトウェアエンジニアリングのEssenceの紹介 ➢ ソフトウェアエンジニアリングの問題 ➢ SEMATとEssence ➢ アルファ ➢ アクティビティスペース ➢ カーネルの拡張とエッセンシャル化 ◼ Essenceの適用事例 ➢ 適用事例一覧 ➢ 事例１：某社「プロジェクト状況チェックリストの改善」 ➢ 事例２：ITA「アルファを活用した障害事例集の改善」 ➢ 事例３：SE4BS 「匠Methodのエッセンシャル化」
76. 76 （事例3）プラクティスの真価の把握 SE4BS「匠Methodのエッセンシャル化」
77. 77 SE4BS（Software Engineering for Business and Society） ◼ SE4BSとは、ソフトウェアを「個人・社会・ビジネスのために、柔軟で創造的な未来の価値を生み出すもの」と捉え、その 価値を生み出すためにエンジニアリングを適用するコミュニティと，コミュニティが実施する活動，コミュニティが生み出す 成果物の総称です。 ◼ 2019年に永和システムマネジメントの平鍋健児氏、豆蔵の羽生田栄一氏、早稲田大学の鷲崎弘宜氏、匠BusinessPlaceの萩本 順三氏が立ち上げました。 ◼ 顧客価値、ビジネス価値や社会価値に基づいてソフトウェア開発・運用を進めること、また産業界で広く受け入れられている アジャイル開発をうまくソフトウェア工学に取り入れていくことの一つ方策として、SE4BSは価値駆動プロセスを以下のよう に提案します。 SE4BSとは https://se4bs.com/sites/introduction/
78. 78 SE4BS 鷲崎教授 「私はDX時代に必要な新たな ソフトウェア開発のあり方を SE4BSと称して追求する中、 あらためてさまざまなプラク ティスの組み立ての基盤の必 要性を痛感し、Essenceの価 値を再認識しているところで す。」 資料1: 日本語版まえがき (xiv) より
79. 79 を推奨メソッドと している。 SE4BSと匠Method
80. 80 匠Methodとは ◼ ビジネスをデザインするための手法 ➢ ビジネス企画における問題を価値の視点でまとめ上げ、組織全体が一体となって推進していける戦略・業務をデザインすることができる手法 ➢ 要求開発の発展形として、ビジネス価値を表現するモデルの導入やITを含まないビジネス活動にも使えるように拡張されている ➢ 株式会社匠BusinessPlaceから提供されている日本生まれの誰もが使えるオープンな手法であり、同社代表取締役会長の萩本順三さんが開発 した ◼ 活用領域 ⚫ ビジネスデザイン（製品やサービス企画） ⚫ 業務改革・改善 ⚫ 企業・中長期戦略 作用 行動力UP 動機力UP 要求分析ツリー 価値分析モデル 価値デザインモデル ゴール記述モデル 業務フロー 現業務フロー プロト開発等 change ※「モデル」とは、形式を持った図のことです。 価値の要素 ステークホルダー モデル 基本は６枚の図でビジネスデザインを仕上げる ビジネス コンテキストフロー 要求 価値 業務 活動 理想 現状 お客様 ⚫ 部門デザイン ⚫ プロジェクトデザイン（ITシステム開発、業務活動） ⚫ キャリアデザイン https://www.takumi-businessplace.co.jp/takumi-method/
81. 81 問い （１）匠Methodは、ソフ トウェアエンジニアリング のどの部分をカバーしてい るのか？ （２）どのようにカバーし ているのか？ エッセンシャル化して確かめてみよう！ SE4BSと匠Method
82. 82 Essenceのカーネルと匠Methodのモデルの関連 まずは、匠Methodの５つのモデルと、Essenceカーネルの関連を考えてみました。 要求分析ツリー 価値分析モデル 価値デザインモデル ゴール記述モデル ステークホルダー モデル Essenceカーネル カーネルアルファ（もの） 要求 機会 作業 ステーク ホルダー ソフトウェア システム チーム 作業方法 ソリューション 活動 顧客 ＜ を実行／計画する ＜ を満たす ＜ を提供する ＜ にフォーカス する ＜ のスコープと 制約を設定する ＜ を使用／ 消費する を構築する ＞ ＜ をサポートする に対応する ＞ ソリューション 活動 顧客 要求を 理解する システムを 形成する システムを 実装する システムを テストする システムを デプロイする システムを 運用する 可能性を探索する ステークホルダーの ニーズを理解する ステークホルダーを 満足させる システムを使用する 作業を準備する アクティビティを 調整する チームを サポートする 進捗を追跡する 作業を停止する アクティビティスペース（こと）
83. 83 要求 機会 作業 ステーク ホルダー ソフトウェア システム チーム 作業方法 ソリューション 活動 顧客 ＜ を実行／計画する ＜ を満たす ＜ を提供する ＜ にフォーカス する ＜ のスコープと 制約を設定する ＜ を使用／ 消費する を構築する ＞ ＜ をサポートする に対応する ＞ Essenceのカーネルアルファと、匠Methodのモデルとの関連 ステークホルダーモデル 価値分析モデル 価値デザインモデル 要求分析モデル ゴール記述モデル 匠Methodの５つのモデルは、カーネルアルファの主に「ステークホルダー」、「機会」、「要求」、「作業」に関連すると思われます。 【機会】ソフトウェアシステム を開発、あるいは更新するため の理由となり得る十分な状況 【ステークホルダー】ソフトウェアシステ ムに影響を与えたり、影響を受けたりする 人、グループ、組織 【要求】ソフトウェアシス テムが機会に対応するため にすべきこととステークホ ルダを満足させるためにす べきこと 【作業】成果を獲得するため に行う精神的、あるいは肉体 的な努力をともなう活動
84. 84 Essenceのアクティビティスペースと、匠Methodのモデルとの関連 匠Methodの５つのモデルは、アクティビティスペースの主に「可能性を探索する」、「ステークホルダーのニーズを理解 する」、「要求を理解する」、「作業を準備する」に関連すると思われます。 ソリューション 活動 顧客 要求を 理解する システムを 形成する システムを 実装する システムを テストする システムを デプロイする システムを 運用する 可能性を探索する ステークホルダーの ニーズを理解する ステークホルダーを 満足させる システムを使用する 作業を準備する アクティビティを 調整する チームを サポートする 進捗を追跡する 作業を停止する ステークホルダーモデル 要求分析モデル ゴール記述モデル 価値分析モデル 価値デザインモデル 資料1: p67, 68 ソフトウェアシステムの可能性を 探索する。ここには機会の分析 やステークホルダーの特定も含 まれる ステークホルダーの関わり、ニーズを理解し て、適切な結果が生まれるようにする。 これから作るシステムが何をするかを皆で理解する チームと作業環境を設定すること。作業を完了することを理解して尽力する。
85. 85 [ステークホルダー] [カーネル] [機会] [カーネル] [要求] [カーネル] [作業] [カーネル] [可能性を探索する][カーネル] [ステークホルダーのニーズを理解する][カーネル] [要求を理解する][カーネル] [作業を準備する][カーネル] 価値分析モデル ステークホルダーモデル 価値デザインモデル 要求分析ツリー ゴール記述モデル を含む> を含む> を含む> を含む> 全モデル の調整 ステー クホル ダーの 洗い出 し 戦略要 求の洗 い出し ステーク ホルダー の思いの 記述 価値の 文章化 目的の 記述 価値と 目的の 結びつ け ビジョン 作成 コンセプ ト作成 全要素 作成 ステー クホル ダーの 関連付 け 業務要 求の洗 い出し IT要求 の洗い 出し ツリーの 調整 要求の 優先順 位付け テーマ の作成 計画の 作成 まずは匠Methodの５つのモデルのアルファとアクティビティと成果物を定義してみました。 またカーネルアルファやアクティビティスペースとの関連も定義してみました。 カーネルアルファ 継承して拡張されたアルファ（匠Method） 匠Methodの各モデルのアクティビティを定義し、 匠Methodのモデルのエッセンシャル化 カーネルのアクティビティスペースに、
86. 86 [可能性を探索する][カーネル] [ステークホルダーのニーズを理解する][カーネル] [ステークホルダー] [カーネル] [機会] [カーネル] [要求] [カーネル] [作業] [カーネル] [要求を理解する][カーネル] [作業を準備する][カーネル] 価値分析モデル ステークホルダーモデル 価値デザインモデル 要求分析ツリー ゴール記述モデル ステー クホル ダーの 洗い出 し 戦略要 求の洗 い出し ステーク ホルダー の思いの 記述 価値の 文章化 目的の 記述 価値と 目的の 結びつ け ビジョン 作成 コンセプ ト作成 全要素 作成 ステー クホル ダーの 関連付 け 業務要 求の洗 い出し IT要求 の洗い 出し ツリーの 調整 要求の 優先順 位付け テーマ の作成 計画の 作成 全モデル の調整 を含む> を含む> を含む> を含む>  認識できた  代表者がいる  関与している  合意できた  デプロイに満足している  利用に満足している  洗い出された  関連付けられた  思いが記述された  全モデルと整合性が取 れた  特定された  ソリューションが必要になった  価値が確立された  実行可能になった  対応済みである  メリットが発生した  企画されている  明確化されている  論理的である  受け入れ可能である  対応済みである  満たされている  開始された  準備できた  着手した  制御中  完了した  終了した  価値と目的が記述された  価値と目的が調整された  全モデルと整合性が取れた  ビジョンとコンセプトが記述された  全要素が記述された  全モデルと整合性が取れた  要求が記述された  ツリーが完成した  優先順位が付けられた  全モデルと整合性が取 れた  テーマが作成された  計画が作成された 匠Methodの５つのモデルのアルファの状態を定義してみました。関連するカーネルアルファの状態も記載しました。 匠Methodのモデルのエッセンシャル化
87. 87 [可能性を探索する][カーネル] [ステークホルダーのニーズを理解する][カーネル] [ステークホルダー] [カーネル] [機会] [カーネル] [要求] [カーネル] [作業] [カーネル] [要求を理解する][カーネル] [作業を準備する][カーネル] 価値分析モデル ステークホルダーモデル 価値デザインモデル 要求分析ツリー ゴール記述モデル ステー クホル ダーの 洗い出 し 戦略要 求の洗 い出し ステーク ホルダー の思いの 記述 価値の 文章化 目的の 記述 価値と 目的の 結びつ け ビジョン 作成 コンセプ ト作成 全要素 作成 ステー クホル ダーの 関連付 け 業務要 求の洗 い出し IT要求 の洗い 出し ツリーの 調整 要求の 優先順 位付け テーマ の作成 計画の 作成 全モデ ルの調 整 を含む> を含む> を含む> を含む>  認識できた  代表者がいる  関与している  合意できた  デプロイに満足している  利用に満足している  洗い出された  関連付けられた  思いが記述された  全モデルと整合性が取 れた  特定された  ソリューションが必要になった  価値が確立された  実行可能になった  対応済みである  メリットが発生した  企画されている  明確化されている  論理的である  受け入れ可能である  対応済みである  満たされている  開始された  準備できた  着手した  制御中  完了した  終了した  価値と目的が記述された  価値と目的が調整された  全モデルと整合性が取れた  ビジョンとコンセプトが記述された  全要素が記述された  全モデルと整合性が取れた  要求が記述された  ツリーが完成した  優先順位が付けられた  全モデルと整合性が取 れた  テーマが作成された  計画が作成された 匠Methodのアクティビティがどのアルファの状態に影響を与えるか定義してみました。 匠Methodのモデルのエッセンシャル化
88. 88 [可能性を探索する][カーネル] [ステークホルダーのニーズを理解する][カーネル] [ステークホルダー] [カーネル] [機会] [カーネル] [要求] [カーネル] [作業] [カーネル] [要求を理解する][カーネル] [作業を準備する][カーネル] 価値分析モデル ステークホルダーモデル 価値デザインモデル 要求分析ツリー ゴール記述モデル ステー クホル ダーの 洗い出 し 戦略要 求の洗 い出し ステーク ホルダー の思いの 記述 価値の 文章化 目的の 記述 価値と 目的の 結びつ け ビジョン 作成 コンセプ ト作成 全要素 作成 ステー クホル ダーの 関連付 け 業務要 求の洗 い出し IT要求 の洗い 出し ツリーの 調整 要求の 優先順 位付け テーマ の作成 計画の 作成 全モデ ルの調 整 を含む> を含む> を含む> を含む>  認識できた  代表者がいる  関与している  合意できた  デプロイに満足している  利用に満足している  洗い出された  関連付けられた  思いが記述された  全モデルと整合性が取 れた  特定された  ソリューションが必要になった  価値が確立された  実行可能になった  対応済みである  メリットが発生した  企画されている  明確化されている  論理的である  受け入れ可能である  対応済みである  満たされている  開始された  準備できた  着手した  制御中  完了した  終了した  価値と目的が記述された  価値と目的が調整された  全モデルと整合性が取れた  ビジョンとコンセプトが記述された  全要素が記述された  全モデルと整合性が取れた  要求が記述された  ツリーが完成した  優先順位が付けられ た  全モデルと整合性が取 れた  テーマが作成された  計画が作成された 匠Methodのモデルのエッセンシャル化（各アクティビティが支援するアルファの状態） 匠Methodのアルファの状態とカーネルアルファの状態の関連を定義してみました。
89. 89 要求 機会 作業 ステーク ホルダー ソフトウェア システム チーム 作業方法 ソリューション 活動 顧客 ＜ を実行／計画する ＜ を満たす ＜ を提供する ＜ にフォーカス する ＜ のスコープと 制約を設定する ＜ を使用／ 消費する を構築する ＞ ＜ をサポートする に対応する ＞ （問1）匠Methodは、ソフトウェアエンジニアリングのどの部分をカバーしているのか？ （答え1）カーネルアルファの、「機会」 「ステークホルダー」「要求」「作業」の４つ （答え2）アクティビティスペースの中の、 可能性を探索する」「ステークホルダーの ニーズを理解する」「要求」を探索する」 「作業を準備する」の４つ ソリューション 活動 顧客 要求を 理解する システムを 形成する システムを 実装する システムを テストする システムを デプロイする システムを 運用する 可能性を探索する ステークホルダーの ニーズを理解する ステークホルダーを 満足させる システムを使用する 作業を準備する アクティビティを 調整する チームを サポートする 進捗を追跡する 作業を停止する
90. 90 （問2）匠Methodは、ソフトウェアエンジニアリングをどのようにカバーしているのか？ [ステーク ホルダー] [カーネル] [機会] [カーネル] [要求] [カーネル] [作業] [カーネル]  認識できた  代表者がいる  関与し ている  合意できた  デプロイに満足している  利用に満足している  特定された  ソリュ ーション が必要になっ た  価値が確立された  実行可能になっ た  対応済みである  メリットが発生し た  企画されている  明確化されている  論理的である  受け入れ可能である  対応済みである  満たされている  開始された  準備できた  着手した  制御中  完了した  終了した （答え） 「機会」「ステークホルダー」「要求」「作業」の、主に前半のステータスに至るための具体的な 方法を提示している。 全モデル の調整 ステー クホル ダーの 洗い出 し 戦略要 求の洗 い出し ステーク ホルダー の思いの 記述 価値の 文章化 目的の 記述 価値と 目的の 結びつ け ビジョン 作成 コ ンセプ ト作成 全要素 作成 ステー クホル ダーの 関連付 け 業務要 求の洗 い出し IT要求 の洗い 出し ツリーの 調整 要求の 優先順 位付け テーマ の作成 計画の 作成 カーネルアルファとステータス
91. 91 匠Method以外の推奨メソッドについても同様にエッセンシャル化して 検証することで、SE4BSの価値駆動プロセスをシームレスに繋げて、必 要なプラクティスの特定の手助けになると思われる。 今後の展望 SE4BSの価値駆動プロセス を推奨メソッドと している。
92. 92 まとめ
93. 93 ◼ モダン・ソフトウェアエンジニアリングのEssenceの紹介 ➢ ソフトウェアエンジニアリングの問題 ✓ ファッション業界みたい、プラクティスが埋もれて いる、共通基盤が必要 ➢ SEMATとEssence ✓ Ivar Jacobsons氏らによる取り組み(SEMAT)と共通 基盤(Essence) まとめ UP Scrum ・・・ ・・・ カーネル（共通基盤） 言語（図形言語） 手法・プロセス プラクティス Essence
94. 94 ◼ Essenceの概要 ➢ アルファ ✓ ソフトウェアエンジニアリングの重要な要素で、進捗や健全 性の評価に関する開発活動の必須要素(もの) ➢ アクティビティスペース ✓ アクティビティを入れる汎用的なプレースホルダー（こと） ➢ カーネルの拡張 ✓ 「カーネルアルファ」やアクティビティスペースは継承して 拡張可能 ➢ エッセンシャル化 ✓ Essenceの図、説明、チェックリストを使用してプラクティ スを簡潔に記述すること。これによりチームはプラクティス のギャップの存在に気づくことができるようになる。 まとめ カーネルアルファ 要求 機会 作業 ステーク ホルダー ソフトウェア システム チーム 作業方法 ソリューション 活動 顧客 ＜ を実行／計画する ＜ を満たす ＜ を提供する ＜ にフォーカス する ＜ のスコープと 制約を設定する ＜ を使用／ 消費する を構築する ＞ ＜ をサポートする に対応する ＞ ソリューション 活動 顧客 要求を 理解する システムを 形成する システムを 実装する システムを テストする システムを デプロイする システムを 運用する 可能性を探索する ステークホルダーの ニーズを理解する ステークホルダーを 満足させる システムを使用する 作業を準備する アクティビティを 調整する チームを サポートする 進捗を追跡する 作業を停止する アクティビティスペース Essence言語で表現したもの スクラム チーム プロダクト オーナー スクラム マスター 開発者 [作業] （カーネル） [要求] （カーネル） [ソフトウェアシステム] （カーネル） プロダクト バックログアイテム スプリント スプリント バックログ インクリメント を含む> に記述されている> をターゲットにする> として デリバリーされる> を含む> に進化して 記述される> スプリント プランニング デイリー スクラム スプリント レビュー スプリント レトロスペクティブ [チームをサポートする] （カーネル） で優先順位 付けされ ている> プロダクト バックログ 要求 プロダクト バックログ アイテム を含む> 作業を準備する チームのキックオフ を含む>
95. 95 まとめ ◼ Essenceの適用事例 ➢ 事例１：某社「プロジェクト状況チェックリストの改善」 ✓ （効果）視野の拡張と合理化 ➢ 事例２：ITA「アルファを活用した障害事例集の改善」 ✓ （効果）視野の拡張と原因の深堀、改善策の追加 ➢ 事例３：SE4BS 「匠Methodのエッセンシャル化」 ✓ （効果）メソッドがソフトウェアエンジニアリングの どの部分をどのようにカバーしているかの理解 機会 ステークホルダ 良い機会は・・・ 健全なステークホルダは… 要求 ソフトウェアシステム 良い要求は・・・ 良いソフトウェアシステムは… 仕事 チーム 健全な仕事は… 健全なチームは… 仕事の仕方 良い仕事の仕方は… 全てのメンバーが仕事を進めるためにプラクティスと ツールを入手できる チーム全体が仕事の仕方の監査と改善に取り組んで いる 活用 仕事の仕方がチームで最適な形で活用されている チームメンバーが計画通り進歩している プラクティスが当たり前に適用されるチーム風土が 整っている プラクティスを実践する上でのツールの課題が解消さ れている 仕事でやるべき全てのことが達成されている 教訓とメトリクスが資産化されて再利用できる状態 となっている チームの仕事をガイド、サ ポートするために適用された 最適なプラクティスとツール 群 原則決定 原則と制約が決定されている 原則と制約が宣言されている プラクティスとツールが同意されている チームは扱い方を理解している 準備完了 重要なプラクティスとツールが準備されている プラクティスとツール間のギャップが分析され、理解さ れている ・チームに同意されている ・リスクとテクニカルな負債を 低減できる ・効果的であり重複した仕事 や無駄を取り除ける ・仕事の仕方自身を改善でき る 能力のギャップが分析され、理解されている プラクティスとツールが統合されている 使用 チームの一部メンバーが利用している 使用するプラクティスとツールが定期的に監査されて いる プラクティスとツールがチームによって改善されている 廃止 チームに利用されていない 次の利用時のために教訓が共有されている フィードバックの手続きが整っている 定着 チームメンバー全員が利用している ・効果的にチーム目標を達成 している ・効果的に協力できるメン バーで構成されている ・自分たちの仕事に集中して いる ・継続的な改善に取り組んで いる 合否基準が決まっている メンバーは仕事の進め方を知っている 管理手順が同意されている リスクの影響度が理解されている 仕事の依存関係が明確である 開発が開始している 仕事が順調に進み、リスクが管理下に置かれてい る 最適化 チームは効果的、効率的に動いている 未計画の仕事や再実施の作業が管理下に置かれ ている 状況変化に対応することができる 見積内に作業アイテムが完了している 高い品質の成果物が作り出されている 仕事の評価基準が追跡できている 撤回とやり直しが最低限である 常に無駄が排除されている 成果提供まで完了している 休止 チームに責任は生じない 仕事の成果が完成している 準備完了 費用と労力が見積もられている 組織化 チームは任期開始に必要なリソースを保有している 仕事を開始する資金とリソースが準備万端である ・規模が明らかに見積できて トラッキング可能 ・作業項目間の依存性を減ら すために分解できる ・リスクを常に管理下に置くこ とができる チームの組織構造と個人の役割が理解されている 開発開始 成果を獲得するために行う 精神的、あるいは肉体的な 努力をともなう活動 協調 チームの組織メンバーが一つのユニットになって仕 事に取り組んでいる 仕事の進捗が計測されている メンバー間のコミュニケーションがオープンで正直 である 明確に定義された作業アイテムレベルまで仕事が 詳細化されている メンバーがチームの任務に集中している チームメンバーが作業アイテムを受理して作業を進 めている メンバー個々人の目的の先にチームの成功がある 制御可能 完結 役割は移管されている 開発したソフトウェアシステムが顧客に受理されて いる メンバーは他の仕事に割当て可能である 終了 全ての残作業が完了しており、公式に仕事がク ローズされている システムの全機能を運用した事例が少なくとも一つ ある システム保守のサービスレベルが同意されてい る。 特定のソフトウェアシステム の開発、保守、供給、サポー トに積極的に携わる集団 着手 仕事を立ち上げた人物が周知されている 立上げ チーム任務が明確である 仕事の制約が明確である チームは任務達成に必要な育成プランを持ってい る 資金調達の目処が立っている 要求される能力が識別されている 仕事の優先度が明確である チーム規模が決定されている ・要求を満たしている ・相応しいアーキテクチャを 採用している ・メンテナンス性、拡張性、テ スト可能性を有す ・低コストでサポートできる 要求管理の仕組みが同意されている 重要なインタフェースとシステム構成が論証できて いる 制約と前提が識別されている 一貫性・ 体系化 明確な全体像が関係者に共有されている 使用可能 システムは使用可能であり、要求された品質特性 を達成できている 重要な利用シナリオが共有されている 受理可能 関係者が受理可能な解決策が示されている 準備完了 ユーザドキュメントが利用できる 同意された要求が変更される確度は低い ステークホルダがシステムを受理している 価値が明確である ステークホルダがシステムの運用方法を準備しよう としている 要求の優先度が明確である 機能と性能がテストされており、検収済みである 認識の不一致が対応されている 欠陥レベルが許容されている 要求がもたらす影響力が理解されている リリース内容が周知されている スコープ定義 システムの目的とスコープが同意されている 論証完了 重要なアーキテクチャの特性が論証できている 成功の判断基準が明確である ・現実的なニーズにマッチし ている ・スコープが明確になってい る ・一貫性があって体系化され ている ・開発推進を手助けしてくれ る アーキテクチャが適切であることをステークホルダ が同意している ユーザがシステムを操作可能である ソフトウェアシステムが機会 に対応するためにすべきこと とステークホルダを満足させ るためにすべきこと 満足 システムは要求とニーズを満足している 退役 システムは保守されていない 完成を妨げる未解決の要求が存在しない システム更新によるリリースはない システムは置き換えられるか開発が中止されてい る 実装 システムの受理に必要十分な要求が実装されてい る 運用 運用環境でシステムが使用されている システムを稼働させる価値のある状態にあることに ステークホルダが同意している 想定されたユーザに利用されている システムはソフトウェアと ハードウェアおよびソフトウェ アが作り出す価値あるデータ で構成される 構想 新しいシステムのニーズが明確である アーキテクチャ 決定 重要な技術リスクに対応可能なアーキテクチャが 採用されている ユーザが識別されている アーキテクチャの採用基準が同意されている 最初の出資者が識別されている 使用するプラットフォーム、技術、言語が選択されて いる 購入、構築、再利用の方針が決定している 利益獲得 運用で明らかな利益が生み出されている 利用満足 システムはステークホルダの最小限の期待以上で ある 少なくとも予想通りの投資効果が得られている ステークホルダのニーズと期待は満足されている 課題解決 機会に対応するための論証された解決策が提供さ れている 展開合意 ステークホルダの視点でシステムに対するフィード バックを提供している 有効なシステムが利用可能である システムの展開に対する準備が整ったことを確認 できている ステークホルダは展開する価値に同意している ステークホルダは機会の解決策に満足している 解決策決定 解決策の主要な部分が描かれている 合意形成 ステークホルダにとっての価値が定義され、チーム に受け入れられている 解決策を開発、展開するときの制約が明らかに なっている ステークホルダは優先度を同意している リスクが管理下に置かれている システムの展開による最小限の期待値について同 意している ・ソフトウェアシステムに関与 するグループや組織の代表 者 ・ステークホルダ間で約束し た役割を果たす ・要求の合意形成のために 協力する ・ソフトウェアシステムの恩恵 を受ける 潜在的な問題と本質が判明している ステーホルダが協業するやり方が同意されている 少なくとも1つのソフトウェアによる解決策が提案さ れている ステークホルダーがチームの仕事を尊重している 価値の設定 解決策が成功したときの価値が設定されている 活動の協業 ステークホルダが役割を果たしている 解決策の影響をステークホルダが理解している 解決策の 方向付け ソフトウェアによる解決策のニーズが裏付けれてい る 代表者の選定 ステークホルダが任命されている ステークホルダが特定されている ・ソフトウェアシステムで解決 すべき機会が特定されてい る ・ソフトウェアシステム導入の 価値が定義されている ・QCDに見合ったソフトウェア が導入されている ・明確な利益を生み出すこと ができる 自身の役割と権限について同意している チームにタイミング良くフィードバックを与えたり、決 断の場に参加している ソフトウェアシステムの価値が理解されている ステークホルダ間のコミュニケーションが良好であ る ソフトウェアシステムを開発、 あるいは更新するための理 由になり得る十分な状況 ソフトウェアシステムに影響 を与えたり、影響を受けたり する人、グループ、組織 課題の識別 ソフトウェアによる解決策によって対応できる課題 が識別されている 関係者の特定 ステークホルダが識別されている ステークホルダは潜在的な価値を良く理解して投 資したいと願っている ステークホルダ間で代表者が同意されている ステークホルダ間で識別された課題が共有されて いる ステークホルダの役割が定義されている 識別する 利用する フォーカスする スコープと制約 満たす 計画と 実行 提供する 対応する 支援する 顧客 改善策 取り組み ②③④ ・ルールは存在するが、運用管理者のルール違反 が常態化していた ①②③ ・組織的なモラルハ ザードが起きていた ・改善案や相談事放 置 ・ルール破りが横行 ・運用管理者は、課 題や問題は自分なり に理解していた。つ まり改善策に対する 要求は理解していた。 ・しかしその要求は 周りに共有されず、 運用管理者は独断 で手順書を修正し、 展開していた。 ・手作業の自動化の 必要性に関する議 論は行われていない （「構想」にも至って ④⑤ ・運用管理者及 び作業者が、承 認部署を通さず 手順書変更・実 施。 ⑥⑧ ⑥⑧ ・手順書に誤りが あった ・運用管理者の 独断で、同意され たものではなかっ た ・改善策の一つと 思われる「手作業 の自動化」に検 討はされていな い（「アーキテク チャー決定にも 至っていない」） ⑩ ⑩ ・復旧に二時 間かかった ・支店窓口 社員は顧客 照会を手作 業で行った ・窓口で待たされた お客様からたくさん のクレーム ・CEOから直々の叱 責を受けた （コメント） ・この事例での改 善策とは何だろ う？ -->「修正された手 順書」「自動化」の 二つを改善策とみ なすと良いと気が （コメント） ・この事例の場合ソフトウェアという より「改善策」とみなすと良いと思っ （全体に関するコメント） ・NGとしたステータスの前段階のステータスはとりあ えず問題無さそうだと判断したが、実際にはあった 可能性もある。もしそのようなものが見つかれば、 新たな原因や根本原因の有力な候補になる。 （特に「チーム」「仕事の仕方」について、気になっ た） （気がついたこと） ・「ソフトウェア」=「解決策」と考えると、どんなフェー ズでも使えると思った。更に言えば、ソフトウェア開 発に限らず使えると思った。（チェックリストだけその ビジネス領域に合ったものに変えれば良い） アルファの全体図上での因果関係分析 SEMAT版因果関係図 αS/Wシステム(改善 策): 「論証完了」NG α機会: 「利益獲得」NG αステークホルダ: 「利用満足」NG α要求: 「一貫性・体系化」NG α仕事: 「制御可能」NG αチーム: 「協調」NG α仕事の仕方: 「使用」NG 顧客 改善策 取り組み アルファの状態のまとめ（どこがNGだったのか） 工程完了チェックリストがカバー していない弱い領域が見えてきた 大きな視点でのチェック漏れを無くす • 「機会」に関する項目が少ない • 全体的に、”計画”に比べて”監視・ 制御・改善”が弱い 現場力向上のためのSEMATチェックリストの活用に関する取り組み事例 2014/11/28 (小林浩) [可能性を探索する][カーネル] [ステークホルダーのニーズを理解する][カーネル] [ステークホルダー] [カーネル] [機会] [カーネル] [要求] [カーネル] [作業] [カーネル] [要求を理解する][カーネル] [作業を準備する][カーネル] 価値分析モデル ステークホルダーモデル 価値デザインモデル 要求分析ツリー ゴール記述モデル ステー クホル ダーの 洗い出 し 戦略要 求の洗 い出し ステーク ホルダー の思いの 記述 価値の 文章化 目的の 記述 価値と 目的の 結びつ け ビジョン 作成 コンセプ ト作成 全要素 作成 ステー クホル ダーの 関連付 け 業務要 求の洗 い出し IT要求 の洗い 出し ツリーの 調整 要求の 優先順 位付け テーマ の作成 計画の 作成 全モデ ルの調 整 を含む> を含む> を含む> を含む>  認識できた  代表者がいる  関与し ている  合意できた  デプロイに満足している  利用に満足している  洗い出された  関連付けられた  思いが記述された  全モデルと整合性が取 れた  特定された  ソリ ュ ーションが必要になった  価値が確立さ れた  実行可能になった  対応済みである  メリットが発生し た  企画されている  明確化されている  論理的である  受け入れ可能である  対応済みである  満たされている  開始された  準備できた  着手した  制御中  完了した  終了した  価値と目的が記述された  価値と目的が調整された  全モデルと整合性が取れた  ビジョンとコンセプトが記述さ れた  全要素が記述さ れた  全モデルと整合性が取れた  要求が記述さ れた  ツリーが完成し た  優先順位が付けられ た  全モデルと整合性が取 れた  テーマが作成された  計画が作成さ れた
96. 96 ご清聴ありがとうございました お問い合わせ 株式会社システム情報 CMMIコンサルティング室 小林 浩 kobayashi-hiroshi@sysj.co.jp