Slide 1

Slide 1 text

開発活動の参照モデルを使った ベンチマーキングと最適化 2024年3月27日 有限会社システム設計 増田 亨 BPStudy #199 1 Essence カーネル

Slide 2

Slide 2 text

自己紹介 業務系アプリケーションのソフトウェア開発者 モデル駆動設計 Java/Spring Boot/IntelliJ IDEA/JIG 有限会社システム設計 代表 株式会社コミューン 技術顧問 2

Slide 3

Slide 3 text

アジェンダ ① 開発活動のモデリング ソフトウェア開発活動の構成要素とそれらの関係性を要約する ② Essence カーネルの概要 基本概念:観測対象、活動空間、遂行能力 顧客、解決策、取り組み ③ 開発活動のベンチマーキングと最適化 Essence カーネルモデルの使い方(模索中) 3

Slide 4

Slide 4 text

4 ① 開発活動のモデリング

Slide 5

Slide 5 text

開発方法論や開発手法のこれじゃない感 a. ソフトウェア開発活動は完全に文脈依存 • どのソフトウェア開発も世界にたった一つの独自文脈のユニークな活動 b. 一方、どのソフトウェア開発もやっていることは同じに見える • 「この道はいつか来た道」「あるある」「そうだよねえ」 c. 「同じに見える」感をうまく表現し伝達できるモデルがなかった • 重厚な開発方法論は、複雑すぎて、現場で使えない • 軽量な開発手法は、単純すぎて、開発活動の複雑さを表現できていない いろいろな方法論や手法を学んでみたが、どれも、これじゃない感 5 CASE*Method, RUP, SAFe, … XP, SCRUM, …

Slide 6

Slide 6 text

6 そこで出会ったのが

Slide 7

Slide 7 text

Essence カーネルモデル 7 ・ソフトウェア開発のやり方を評価し議論するための共通言語 ・開発活動を対象にした(ある種の)ドメインモデル OMGで公開されている 仕様書(PDF) 鷲崎先生の プレゼン資料 角さんの翻訳と プレゼン資料 状態追跡ゲーム用のカード by イヴァー・ヤコブソン

Slide 8

Slide 8 text

8 BPStudyの佐藤さんに 「このテーマで有識者のお話が聞きたい」 とおねだりしてみた

Slide 9

Slide 9 text

BPStudy #197 の事例発表 9 具体的かつ詳細な活用例 これは使える!

Slide 10

Slide 10 text

私にとってのEssence カーネル a. ソフトウェア開発活動の参照モデル • 主要な構成要素とそれらの関係性が体系的に整理されている • 一貫性のある言語化と可視化 • プロセスを対象にしたドメインモデリング(概念モデリング)の事例研究 b. 開発活動の状況を観測し判断する道具 • 観測対象、観測方法、測定基準 • 複数の開発活動の特性を比較(ベンチマーキング) c. 開発活動を改善するための仮説を組み立てる道具 • 状態を変えるために必要な行動は何か? • その行動を効果的に進めるために必要な能力は何か? 10 AとBの差異分析ではなく XとA,XとBの差異どうしの比較分析 でAとBの特徴を明らかにする

Slide 11

Slide 11 text

11 ② Essence カーネルの概要

Slide 12

Slide 12 text

基本概念 12 運用レベル (実体) 知識レベル Essence カーネル アルファ (観測対象) 開発活動の状態 (観測結果) 活動空間 遂行能力 成果物 活動 持つ 必要とする めざす つくる/ 変える 証明する 組織化する 組織化する 結果を生む 多くの開発方法論は このレベルのモデル 開発方法や手法を説明 するためのモデル ロール さまざまな開発のやり方を 一貫した表現で説明できる

Slide 13

Slide 13 text

エッセンスであり軽量といっているが… 13 アルファ (観測対象) 状態 (観測結果) 7つ 観測対象ごとに 6または5段階 状態ごとの チェック項目 75の活動分類 活動空間 15スペース 5項目前後 スペースごとに 5種類程度の活動 遂行能力 5つの分野 分野ごとに 5種類程度のスキル領域 209チェック項目 25のスキル分類

Slide 14

Slide 14 text

三つの関心領域で開発活動を構造化 14 顧客 解決策 取り組み プロジェクト管理者や、 スクラムマスターの関心事? アーキテクトの関心事? プロダクトマネージャーの関心事? 開発のWhy 目的と制約 開発のWhat 要求とシステム 開発のHow チームと仕事のやり方 参考:Scaled Agile Framework(SAFe)も、この三つで構造化している

Slide 15

Slide 15 text

15 アルファ 開発活動の観測対象

Slide 16

Slide 16 text

アルファ:状態を観測する対象 16 顧 客 解 決 策 取 り 組 み 開発機会 利害 関係者 要求事項 ソフトウェア システム 仕事 仕事の やり方 チーム ① 開発の目的、価値、制約条件が どのくらい明確か or あやふか かを扱っている ② 要求事項は「顧客」ではなく、 「解決策」の関心事 ③ チーム、仕事、仕事のやり方を 別の関心事として分離 (仕事のやり方とは、コミュニ ケーション、役割分担、進捗管 理など)

Slide 17

Slide 17 text

観測対象の状態区分(観測結果の表現) 17 利害関係者 関係者を特定 代表者を選定 協業できている 合意形成 デプロイに満足 利用に満足 開発機会 課題を識別 解決策が必要 価値の評価 着手に合意 解決策の実装 価値の実現 要求事項 構想 スコープ定義 一貫性 記述された ニーズに対処 関係者が満足 システム 技術方式の選択 有効性の実証 動作可能 デプロイ可能 稼働中 引退 チーム 立ち上げ 組織化 協調 最適化 停止 仕事 着手 準備完了 開発開始 制御可能 完遂 終了 仕事のやり方 原則の確立 土台づくり完了 一部が取り入れ 定着 活用 廃止 ① 状態ごとに、5項目前後のチェック項目がある。 ② チェック項目を使うことで、不健全な状態(偽りの進捗?)を検出可能 ③ 状態を前に進めるために、なにをすべきかが活動空間 で提示されている 「SEMAT カーネルカード」で検索すると、PDF版が見つかる

Slide 18

Slide 18 text

アルファ(観測対象)間の関係 18 顧 客 解 決 策 取 り 組 み 開発機会 利害 関係者 要求事項 ソフトウェア システム 仕事 仕事の やり方 チーム 提供する 使う 焦点 ガイド 適用 満たす 支援する ① 始点側の状態が不健全 だと終点側の状態にマ イナスの影響を与える ② 別の言い方をすると、 依存関係は、矢印と逆 の方向になる

Slide 19

Slide 19 text

19 活動空間 観測対象の状態を変える方法

Slide 20

Slide 20 text

活動空間:状態を変えるためにすべきこと 20 顧 客 解 決 策 取 り 組 み ① 状態を変えるためにす べきことのモデル (次スライド参照) ② 一つの活動空間に具体 的な活動(複数)が入 る 運用レベルで記述する 開発方法論と、 知識レベルで記述する Essence のアプローチ の違い 要求の 理解 システム の形 実装 テスト デプロイ 運用 関係者 の満足 ニーズ の理解 システム の利用 可能性 の探索 作業の 停止 作業の 準備 活動の 調整 進捗の 追跡 チーム の支援

Slide 21

Slide 21 text

活動空間と状態の関係 21 要求事項 構想 スコープ定義 一貫性 記述された ニーズに対処 関係者が満足 要求の 理解 システム の形 テスト チーム 立ち上げ 組織化 協調 最適化 停止 作業の 停止 作業の 準備 活動の 調整 進捗の 追跡 チーム の支援 利害関係者 関係者を特定 代表者を選定 協業できている 合意形成 デプロイに満足 利用に満足 関係者 の満足 ニーズ の理解 システム の利用 可能性 の探索 開発機会 課題を識別 解決策が必要 価値の評価 着手に合意 解決策の実装 価値の実現 進捗追跡は 組織化や協調の状態に 進む活動ではない 要求事項の記述には 設計やテストの活動が必要 合意形成の活動は? ○○の状態に達するには □□の活動を行う

Slide 22

Slide 22 text

22 遂行能力 観測対象の状態を変えるために必要な能力

Slide 23

Slide 23 text

基本概念 23 運用レベル (実体) 知識レベル Essence カーネル アルファ (観測対象) 開発活動の状態 (観測結果) 活動空間 遂行能力 成果物 活動 持つ 必要とする めざす つくる/ 変える 証明する 組織化する 組織化する 結果を生む 多くの開発方法論は このレベルのモデル このレベルで一般化した 開発活動の説明モデル ロール 遂行能力と活動空間は 直接、関連させていない

Slide 24

Slide 24 text

遂行能力の分野 24 顧 客 解 決 策 取 り 組 み 利害関係者の 意図の代弁 分析 開発 テスト リーダー シップ マネジ メント 遂行能力の5段階 補助できる 単純な文脈で自力で遂行できる 通常の文脈で自力で遂行できる 困難な文脈に適応できる 考え方とやり方を革新できる

Slide 25

Slide 25 text

遂行能力の基本スキル 25 利害関係者の 意図の代弁 • 交渉 • ファシリテーション • 人脈づくり • 意図の伝達(文書、口頭) • 共感力 リーダー シップ マネジ メント • 創造性 • 意欲 • 交渉 • 意図の伝達 • 意思決定 • 意図の伝達 • 運営 • 組織 • 資源計画 • 財務報告 分析 開発 テスト • 意図の伝達(口頭、文書) • 詳細の観察、理解、記録 • 合意促進 • 要求の捕捉 • 全体の分解 • 要求項目から全体を見る • 技術知識 • プログラミング • プログラミング言語の知識 • クリティカル・シンキング • リファクタリング • 設計 • 鋭い観察力 • 探索的・破壊的思考 • 探究心 • 細部へのこだわり ① 15の活動空間に対して遂行能力の領域は6つ ② 基本スキルがあればさまざまな活動に貢献できる ③ 重複している基本スキル(意図の伝達)もある

Slide 26

Slide 26 text

26 ③ 開発活動のベンチマーキングと最適化

Slide 27

Slide 27 text

取り組みの状況 開発の現場で(個人的に)Essence カーネルモデルを使ってベン チマーキングしている • どういう特徴が表れているか? • Essenceカーネルモデルをどう使えるか? ツールを自作し始めた • Essenceカーネルモデルをプログラミング言語で構造的に記述 • モデルのブラウザー • 会話式の評価入力と可視化 • 開発活動のシミュレーター(評価履歴から状態変化の様子を可視化) 27

Slide 28

Slide 28 text

ベンチマーキング 最初はSEMATカーネルカードで状態追跡ゲームをやってみた もともとは、実プロジェクトを評価、分析し、ここで発表するつもりだった アルファの状態だけではなく、活動空間や遂行能力の評価もやりたくなった デジタル化の試み Take One エクセルでやってみた 面倒くさい プログラマーとして、敗北感 デジタル化の試み Take Two 動くツールを作っちゃえ 28 いまここ

Slide 29

Slide 29 text

ツールを自作中 29 ソースコード記述 ⇒ クリッカブル図表の自動生成