モデリングの そだてかた 1 @NoriyukiMizuno みずのり（みずののりゆき） TOC/TOCfE北海道 RDRA MeetUp、TEF道など WACATE2024Summer

自己紹介：主にモデルに関係しそうな部分 2 time クリティカルシンキング学習 ロジカルシンキング学習 開催、テスト設計関連イベント多数実施 ※いろいろ学習有 特に効果的だったのは PFD(Process Flow Diagram) テスト設計コンテスト参加：準優勝1回、優勝1回 （社内） テスト設計技法 ドリル勉強会実施 社内での テスト改善 開催、思考プロセス関係イベント多数実施 TOCfE国際認定プログラム参加 思考プロセス系イベント多数参加 テストカタマリー提案 ワークショップ等実施 RDRA学習、業務適用 ETロボコン（初期名称：UMLロボコン）参加者→実行委員（審査担当など） 国際学会論文化 国際学会論文化 JaSST21東京 チュートリアル エンジニアのための 論理思考技術、作成 ※コンサルあり SEPA翻訳プロジェクト

今回のおはなし 3 「モデル」ではなく「モデリング」のそだてかた という枠で紹介します。 初期の学び方、チョットデキルための学び方を経験談を中心に紹介します。 自信 知識・経験 馬鹿の山 絶望の谷 啓蒙の坂 継続の大地 ※「完全に理解した曲線」こと、ダニング・クルーガー効果 モデリング難しい、 もっとうまくなりたい モデリング 楽しい！ あらゆるものは モデリング

コンテンツ 4 1．モデリングの原則・知識（実践ソフトウェアエンジニアリング（第9版）より） 2．モデリング実活動の例、活用されるモデル 3．モデリングのそだてかた モデリングに対する考え方の変遷（個人） モデリングをそだてる 4．チョットデキルモデリングへ モデリングのTIPS （捉え方、考え方） 「考え方」を鍛える 「考え方」の役立ちどころ 5．まとめ 6．おまけ

コンテンツ 5 1．モデリングの原則・知識（実践ソフトウェアエンジニアリング（第9版）より） 2．モデリング実活動の例、活用されるモデル 3．モデリングのそだてかた モデリングに対する考え方の変遷（個人） モデリングをそだてる 4．チョットデキルモデリングへ モデリングのTIPS （捉え方、考え方） 「考え方」を鍛える 「考え方」の役立ちどころ 5．まとめ 6．おまけ

1．モデリングの原則・知識（実践ソフトウェアエンジニアリング（第9版）より） 6 某書籍には丸ごと「モデリング」という部があります。 そこから抜粋した内容、モデリングの原則に関わる部分を少し紹介します。 ※書籍には数百回「モデリング」という用語が出てきます 第２部 モデリング 第６章 プラクティスの指針となる原則 第７章 要求エンジニアリング 第８章 要求分析モデリングの推奨手法 第９章 設計の概念 第１０章 アーキテクチャ設計の推奨手法 第１１章 コンポーネント設計 第１２章 UX設計 第１３章 移動体端末におけるソフトウェアの設計 第１４章 パターンに基づく設計 引用：実践ソフトウェアエンジニアリング（第9版） Roger.S.Pressman他、SEPA翻訳プロジェクト、オーム社、2021年

1．モデリングの原則・知識（実践ソフトウェアエンジニアリング（第9版）より） 7 モデリングを主要な活動の1つと定義。 引用：実践ソフトウェアエンジニアリング（第9版） Roger.S.Pressman他、SEPA翻訳プロジェクト、オーム社、2021年 1.3.1 プロセスフレームワークとフレームワークアクティビティ プロセスフレームワークは、次の5つの一般的なフレームワーク アクティビティから構成される。 （中略） モデリングアクティビティ（modeling activity） 庭師や橋梁架設者、航空機技術者、大工、建築家はいずれもモデル を用いて毎日の業務をこなしている。スケッチをすることで物ごと の全体像を理解する。構造的にはどうか、要素部分をどのようにつ なぎ合わせるか、等について考察する。 より深く問題を理解し、どのように問題を解くかを考えるために、 必要に応じて対象を深く詳細まで掘り下げて描いたスケッチを書き 直す。 同様にソフトウェアエンジニアはソフトウェアの要求、実現のため の設計をより深く理解するためにモデルを作成する。

1．モデリングの原則・知識（実践ソフトウェアエンジニアリング（第9版）より） 8 モデリングの原則をPickUp 引用：実践ソフトウェアエンジニアリング（第9版） Roger.S.Pressman他、SEPA翻訳プロジェクト、オーム社、2021年 6.2.3 モデリングの原則 第1原則 ソフトウェア開発者の一番の目的はソフトウェアを構築することで、 モデルを作成することではない 第2原則 不必要なモデルは作らず身軽に進める 第3原則 ソフトウェアや、ソフトウェアの解決する問題を、 簡潔に説明するモデルを作ることに努める 第4原則 変更を取り入れやすい方法で作成する 第5原則 モデルを作成した動機を明確に説明できるようにする 第6原則 作成したモデルを目の前のシステムに合わせる 第7原則 完全なモデルのことは忘れて、役に立つモデルを作る 第8原則 モデルの記法を押し付けてはいけない。 情報を伝えることができているなら表現は後回しでよい 第9原則 たとえ紙面で見る限り正しくても、直感が間違いを訴えるモデルには、 注意を向けるだけの理由がある 第10原則 できるだけ早くフィードバックを得る

1．モデリングの原則・知識（実践ソフトウェアエンジニアリング（第9版）より） 9 モデリングの原則をPickUp 引用：実践ソフトウェアエンジニアリング（第9版） Roger.S.Pressman他、SEPA翻訳プロジェクト、オーム社、2021年 8.1.3 要求モデリングの原則 第1原則 問題の情報ドメインを表現しなければならないし、理解されなければならない 第2原則 ソフトウェアの実現する機能を定義しなければならない 第3原則 システムの外部で発生したイベントに対する反応を表現しなければならない 第4原則 情報、機能、振る舞いを表現するモデルは、層状の（あるいは階層的な）構造で 詳細を隠蔽しなければならない 第5原則 分析タスクは、本質的な情報から実装の詳細へと進めよ

1．モデリングの原則・知識（実践ソフトウェアエンジニアリング（第9版）より） 10 モデリングの原則をPickUp 引用：実践ソフトウェアエンジニアリング（第9版） Roger.S.Pressman他、SEPA翻訳プロジェクト、オーム社、2021年 9.4.1 設計モデリングの原則 第1原則 要求モデルを追跡できるようにしなければならない 第2原則 常にアーキテクチャを意識しなければならない 第3原則 データの設計は処理の設計と同じくらい重要である 第4原則 内外のインタフェースはどちらも慎重に設計しなければならない 第5原則 ユーザインタフェースの設計はエンドユーザのニーズを満たさなければならない。 ただし、どんな場合でも使い勝手の良さを重視すべきである 第6原則 コンポーネントは機能独立性を満たすように設計しなければならない 第7原則 コンポーネントは他のコンポーネントや外部環境と疎結合でなければならない 第8原則 設計表現であるモデルは、容易に理解できるようにしなければならない 第9原則 設計は反復的に作成しなければならない 第10原則 設計モデルの作成は、アジャイルな開発アプローチを除外しない

コンテンツ 11 1．モデリングの原則・知識（実践ソフトウェアエンジニアリング（第9版）より） 2．モデリング実活動の例、活用されるモデル 3．モデリングのそだてかた モデリングに対する考え方の変遷（個人） モデリングをそだてる 4．チョットデキルモデリングへ モデリングのTIPS （捉え方、考え方） 「考え方」を鍛える 「考え方」の役立ちどころ 5．まとめ 6．おまけ

2．モデリングの実活動の例 12 今までの活動例：MATLAB/Simulink

2．モデリングの実活動の例 13 今までの活動例：テストカタマリー ※自分たちで設計する記法を自分で考えた テストベース：機能⇒ DFD参照モデル <<ユーザ接点機能>> 演奏系操作をする + 異常値 <<機能共通>> 演奏準備をする <<ユーザ接点機能>> SE操作をする + 機能組合せ <<ユーザ接点機能>> 検索をする + 機能組合せ + タイミング <<ユーザ接点機能>> 予約をする <<ユーザ接点機能>> オーナー設定をする + 機能組合せ + 異常値 + セキュリティ <<機能共通>> 課金判定をする + 機能組合せ + 異常値 + 互換性 + 性能効率性 <<機能共通>> 曲間表示をする + フェールソフト <<ストレージアクセス>> <<ユーザ接点機能>> バックアップをする + フェールソフト <<制約有機能>> <> <<ユーザ接点機能>> 配信をする + フェールソフト + 使用性 + セキュリティ + 機器組合せ <> 営業状態判定をする 営業状態状態遷移>状態遷移 ＜機能グループ＞コンテンツを使う + セキュリティ + 互換性 <> 録音、録画をする + 機能組合せ + 不具合確認 <> <<ユーザ接点機能>> 開局操作をする 引下げ不具合分析>シーケンス図 ＜機能グループ＞歌う <<制約有機能>> 映像再生する <<ユーザ接点機能>> 設置時設定をする <<制約有機能>> 演奏をする 演奏状態遷移>状態遷移 <> 採点をする <> HDD障害の通知をする + 異常値 <<機能共通>> カロリー表示をする <<制約有機能>> 楽曲演奏する + 不具合確認 + 信頼性 <> プログラムを更新する プログラム更新処理>アクティビティ図 + 処理重ね : 処理重ね + タイミング : タイミング <<制約有機能>> コンテンツを使う + 使用性 + 処理重ね + タイミング <<制約有機能>> 歌う テストベース：機能外要求、記述されている気がかり事項 + 機器組合せ + 周辺機器 外部機器互換 + 移植性 新採点移植確認 + セキュリティ セキュリティ + 通信費 通信費確認 「＋」項目はパターン以外 で追加した品質要素となる ~ 信頼性 ~ 使用性 ~ 性能効率 ~ 異常値 ~ 機能適合 ユーザ接点機能 + 予約同時入力(正常動作確認) : 同時入力・処理 + 予約TAT確認(性能評価) : 操作レスポンス + 操作手順の確認(分かりやすさ) : ナビゲーション + 予約オプション設定を確認する(結果網羅) : ふるまい + 検索結果から予約登録をする(結果網羅) : ふるまい + 曲Noで予約登録をする(結果網羅) : ふるまい ~ 同時入力・処理 : 信頼性 ~ 操作レスポンス : 性能効率性 ~ ナビゲーション : 使用性 ~ 異常値入力 : 異常値 ~ ふるまい : 機能適合性 予約系操作をする + キュー同時操作を確認する(正常動作確認) : キューデータへの同時処理 + キュー登録、操作、削除時入力(正常動作確認) : 同時入力・処理 + 予約途中、処理中取り消し(正常動作確認) : 途中取消 + キュー最大個数時処理(異常時処理確認) : 登録キュー超過入力 + 予約をキューから削除する(結果網羅) : ふるまい + キューの順番変更を行う(結果網羅) : ふるまい + 後回し登録を確認する(結果網羅) : ふるまい + 割込み登録を確認する(結果網羅) : ふるまい + キューへの追加と順番を確認する(結果網羅) : ふるまい + キューデータへの同時処理 : タイミング ~ 同時入力・処理 : 信頼性 ~ 途中取消 : 信頼性 ~ 登録キュー超過入力 : 異常値 ~ ふるまい : 機能適合性 予約登録をする 予約キュー処理検討 >OPモデル + 予約確認（キュー）表示を確認する(結果網羅) : ふるまい ~ ふるまい : 機能適合性 予約確認表示をする 異常値入力の確認は機能適合 のテストに含まれる + 予約登録因子組合せ(2因子網羅) : 因子組合せ + 因子組合せ : 機能組合せ + タイミング : タイミング ~ 信頼性 : 信頼性 ~ 使用性 : 使用性 ~ 性能効率 : 性能効率性 ~ 異常値 : 異常値 ~ 機能適合性 : 機能適合性 <<ユーザ接点機能>> 予約をする テスト要求詳細図 ≒各テストの構造 引用：https://www.aster.or.jp/business/contest/contest2017/pdf/presentation_studio_iburi.pdf

2．モデリングの実活動の例 14 今までの活動例：テストカタマリー ※自分たちで設計する記法を自分で考えた 引用：https://www.aster.or.jp/business/contest/contest2017/pdf/presentation_studio_iburi.pdf テスト要求モデル （網羅ビュー） テストベース：機能⇒ DFD参照モデル <<ユーザ接点機能>> 演奏系操作をする + 異常値 <<機能共通>> 演奏準備をする <<ユーザ接点機能>> SE操作をする + 機能組合せ <<ユーザ接点機能>> 検索をする + 機能組合せ + タイミング <<ユーザ接点機能>> 予約をする <<ユーザ接点機能>> オーナー設定をする + 機能組合せ + 異常値 + セキュリティ <<機能共通>> 課金判定をする + 機能組合せ + 異常値 + 互換性 + 性能効率性 <<機能共通>> 曲間表示をする + フェールソフト <<ストレージアクセス>> <<ユーザ接点機能>> バックアップをする + フェールソフト <<制約有機能>> <> <<ユーザ接点機能>> 配信をする + フェールソフト + 使用性 + セキュリティ + 機器組合せ <> 営業状態判定をする 営業状態状態遷移>状態遷移 ＜機能グループ＞コンテンツを使う + セキュリティ + 互換性 <> 録音、録画をする + 機能組合せ + 不具合確認 <> <<ユーザ接点機能>> 開局操作をする 引下げ不具合分析>シーケンス図 ＜機能グループ＞歌う <<制約有機能>> 映像再生する <<ユーザ接点機能>> 設置時設定をする <<制約有機能>> 演奏をする 演奏状態遷移>状態遷移 <> 採点をする <> HDD障害の通知をする + 異常値 <<機能共通>> カロリー表示をする <<制約有機能>> 楽曲演奏する + 不具合確認 + 信頼性 <> プログラムを更新する プログラム更新処理>アクティビティ図 + 処理重ね : 処理重ね + タイミング : タイミング <<制約有機能>> コンテンツを使う + 使用性 + 処理重ね + タイミング <<制約有機能>> 歌う テストベース：機能外要求、記述されている気がかり事項 + 機器組合せ + 周辺機器 外部機器互換 + 移植性 新採点移植確認 + セキュリティ セキュリティ + 通信費 通信費確認 「＋」項目はパターン以外 で追加した品質要素となる 実現へ システムテスト V2.0追加機能確認 オーナー系 機能確認 互換性・拡張性確認 主要機能（歌う系） 主要機能関連操作 コンテンツ関連 <<ユーザ接点機能>> 予約をする <<制約有機能>> 演奏をする <<制約有機能>> 楽曲演奏 <<制約有機能>> 映像再生 <<ユーザ接点機能>> 検索をする <<ユーザ接点機能>> 演奏系操作をする <<ユーザ接点機能>> SE操作をする <<ノミナル機能>> 演奏準備をする <> 採点をする <> 録音、録画をする <<ユーザ接点機能>> 録音・録画系操作をする 機能組合せ確認 <<制約有機能>> 歌う <<制約有機能>> コンテンツを使う 外部機器互換 <> <<ユーザ接点機能>> 開局操作をする <> 営業状態判定をする <<制約有機能>> <> <<ユーザ接点機能>> 配信をする <> プログラムを更新する <> HDD障害の通知をする <<ユーザ接点機能>> 設置時設定をする <<ユーザ接点機能>> オーナー設定をする システム 設定確認 センター間通信確認 <<ノミナル機能>> 曲間表示をする <<ノミナル機能>> 課金判定をする <<ストレージアクセス>> <<ユーザ接点機能>> バックアップをする セキュリティ 新採点移植確認 その他独立確認項目 テストサイクル① テストサイクル② シナリオ系確認 シナリオ ロングラン センター - 本体Integ (プロトコル) システムInteg回帰試験 主要通信確認 主要通信確認 センター間インタフェース センター間インタフェース 通信費 データ・コンテンツ互換 <<ノミナル機能>> カロリー表示をする テスト 調整項目 テスト 調整項目

2．活用されるモデルの例 15 いろいろモデル紹介 ・パターンランゲージ：テスト自動化パタン言語 例：3分クッキング、自動化ハイ、ビックバン自動化、建て増し旅館、など 引用：https://kencolle.github.io/AutomationPatternLanguage/Introduction.html

2．活用されるモデルの例 16 いろいろモデル紹介 ・品質モデル 引用：https://atmarkit.itmedia.co.jp/ait/articles/1911/13/news010.html

2．活用されるモデルの例 17 いろいろモデル紹介 ・USDM：例は記述済みの内容、USDM自体は表のフォーマット 引用：https://www.sessame.jp/workinggroup/WorkingGroup2/POT_Specification_v7.PDF https://amzn.asia/d/0c6RKwQq

2．活用されるモデルの例 18 いろいろモデル紹介 ・仕様項目＆期待結果（詳細）＠ゆもつよメソッド 引用：https://www.jasst.jp/symposium/jasst21tohoku/pdf/S3-5.pdf

2．活用されるモデルの例 19 いろいろモデル紹介 ・PFD 引用：https://speakerdeck.com/mizunori/how-to-draw-pfd-process-flow-diagram PFD参考資料：https://affordd.jp/koha_hp/process/PFDform3.pdf

2．活用されるモデルの例 20 いろいろモデル紹介 ・UML/デザインパターン 引用： https://en.wikipedia.org/wiki/State_pattern https://en.wikipedia.org/wiki/Iterator_pattern

2．活用されるモデルの例 21 いろいろモデル紹介 ・テスト観点モデル（例：テスト要求分析モデル） 引用：https://qualab.jp/materials/stdc-kansai2012.121103.bw.pdf

2．モデルっていろいろある：表現方法の軸、実装有無の軸で分類 22 （表現方法） （実装有） 情報ヒント有 （実装無） 情報ヒント無：枠だけ 図・絵 表 文字のみ システム及びソフト ウェア品質モデル （ISO25010） パターンランゲージ フレームワーク テスト自動化 パタン言語 ※実装有のパターン USDM＠XDDP （変更要求仕様書） 仕様項目＆期待結果 ＠ゆもつよメソッド テスト観点モデル （NGTなど記法メイン） UML PFD＠XDDP デザインパターン ※実装有UML テストカタマリー RDRA（元はUMLベース） 色付き：独自色あり ※偏見ベースの分類 DT：デシジョンテーブル ビジネスフレーム 3C、4Pなど CEG CFD マトリクス分析 （軸も決める） トレーサビリティ マトリクス@XDDP

2．モデルっていろいろある：表現方法の軸、実装有無の軸で分類 23 他にもこんなのが… ・MDD ・状態遷移→カバレッジ生成（ルール生成） ・機械学習モデル ・収益計算モデル ・3D/物理モデル …

2．モデルっていろいろある：モデル/モデリングのユースケース 24 モデル/モデリングのユースケースを考えてみます。 考える 共有する 応用する 基本的な使い方 生成（実装） ・MDD ・状態遷移→カバレッジ生成 （ルール生成） 予測 ・機械学習モデル ・収益計算モデル ・3D/物理モデル 本日、こちらは 対象外とします （表現方法） （実装有） 情報ヒント有 （実装無） 情報ヒント無：枠だけ 図・絵 表 文字のみ システム及びソフト ウェア品質モデル （ISO25010） パターンランゲージ フレームワーク テスト自動化 パタン言語 ※実装有のパターン USDM＠XDDP （変更要求仕様書） 仕様項目＆期待結果 ＠ゆもつよメソッド テスト観点モデル （NGTなど記法メイン） UML PFD＠XDDP デザインパターン ※実装有UML テストカタマリー RDRA（元はUMLベース） 色付き：独自色あり ※偏見ベースの分類 DT：デシジョンテーブル ビジネスフレーム 3C、4Pなど CEG CFD マトリクス分析 （軸も決める） トレーサビリティ マトリクス

2．モデルって何だろう？ 25 モデルとは、科学的方法において理論を説明、可視化、理解する為の簡単で具体的な もの（図形や物体、数式など）。解釈とモデルは、おおよそ1対1で対応する。 現実のモノや出来事を簡略化した表現です。 特定の側面を意図的に強調し、一方で、それ以外の側面を意図的に除外します。 モデルは用途を限定した抽象化です。 ── レベッカ・ワーフスブラック モデルの個人的解釈： 現実そのものではない。そのうえで、役に立つ道具 Wikipedia：モデル (自然科学) 引用：https://ja.wikipedia.org/wiki/%E3%83%A2%E3%83%87%E3%83%AB_(%E8%87%AA%E7%84%B6%E7%A7%91%E5%AD%A6) オブジェクトデザイン - 責務、コラボレーションによる設計技法 著者、 参考：https://amzn.asia/d/8RnP2pO

2．モデルって何だろう？モデリングとは？ 26 モデルの個人的解釈： 現実そのものではない。そのうえで、役に立つ道具 モデル/モデリングのユースケース： 考える 共有する 応用する 基本的な使い方 モデリングをする人の役割：右に行くほど難易度が高い 使う 作る 広める ※他人が作ったモデルを使う ※他人が使うモデルを作る ※より汎用的なモデルを拡散する

2．モデルって何だろう？モデリングとは？ 27 本日の対象は以下の範囲とします。 「考える・共有するためのモデル」を「使う・作る人」へ向けて紹介します。 考える 共有する 応用する 基本的な使い方 使う 作る 広める ※他人が作ったモデルを使う ※他人が使うモデルを作る ※より汎用的なモデルを拡散する 本日の対象範囲

コンテンツ 28 1．モデリングの原則・知識（実践ソフトウェアエンジニアリング（第9版）より） 2．モデリング実活動の例、活用されるモデル 3．モデリングのそだてかた モデリングに対する考え方の変遷（個人） モデリングをそだてる 4．チョットデキルモデリングへ モデリングのTIPS （捉え方、考え方） 「考え方」を鍛える 「考え方」の役立ちどころ 5．まとめ 6．おまけ

3．モデリングに対する考え方の変遷（個人） 29 time クリティカルシンキング学習 ロジカルシンキング学習 開催、テスト設計関連イベント多数実施 ※いろいろ学習有 特に効果的だったのは PFD(Process Flow Diagram) テスト設計コンテスト参加：準優勝1回、優勝1回 （社内） テスト設計技法 ドリル勉強会実施 社内での テスト改善 開催、思考プロセス関係イベント多数実施 TOCfE国際認定プログラム参加 思考プロセス系イベント多数参加 テストカタマリー提案 ワークショップ等実施 RDRA学習、業務適用 ETロボコン（初期名称：UMLロボコン）参加者→実行委員（審査担当など） 国際学会論文化 国際学会論文化 JaSST21東京 チュートリアル エンジニアのための 論理思考技術、作成 ※コンサルあり SEPA翻訳プロジェクト Phase1：モデリング難しい Phase2：モデリングたのしい Phase3へ

3．モデリングに対する考え方の変遷（個人） 30 Phase1：モデリング難しい、もっとうまくなりたい モデルとは ・難しいもの、できるとカッコよさそうなもの 行動 ・他人のモデルから理解しようと努める ・うまく使えるものもあれば、取り入れる …が、イマイチピンと来ないものも多い、だけど使いたい 特に使えたもの ・PFD：Process Flow Diagram ・テスト技法、DT、CFDだいすき うまく 使えなかったもの ・UML（一部は活用）、ビジネスプロセスモデリング ・各種マトリクスでの分析など PFD参考資料： https://affordd.jp/koha_hp/ https://affordd.jp/koha_hp/process/PFDform3.pdf テスト技法参考図書： https://amzn.asia/d/02Jw1IY6

3．モデリングに対する考え方の変遷（個人） 31 Phase2：モデリングたのしい モデルとは ・図表や数式で表現できるもの、お絵描きできるもの ※数式：数理モデル 行動 ・普段使いから図を書いて共有する ・多くのモデルに対して、 これは使える/ここでは使いづらい、が見えてくる ・自分で考えたモデルで遊ぶのが楽しい 試したもの ・テスト分析マトリクス（ゆもつよメソッド） ※各種マトリクス分析を多数実施 ・テスト観点モデル/NGT ・TOCfE各種ツール、ロジックツリー等の思考ツール ・テストカタマリー

3．モデリングに対する考え方の変遷（個人） 32 Phase3：あらゆるものはモデリング モデルとは ・あらゆる表現、思考がモデリングではないのか 行動 ・常に構造化、体系化がちらついてしまう よく使うも の ・マインドマップ（常時利用） ・様々なビジネスフレームワーク ・RDRA/UML

3．モデリングに対する考え方の変遷（個人） 33 ※現在の思考の例 ポイント：人の脳は3軸以上を同時に見るとつらいので、2軸までで表現するのが無難 分類するだけでも軸が多数ある ・表現方法 ・実装（情報ヒント）有無 ・一般的、独自的 ・使い方（参考とする、枠内に記述、etc） などなど 強調・主張する要素とあわせて軸を選ぶ ・文字だけでもモデルとなる ・実装が無い枠だけのものは難しい ・枠/軸を作る活動も難しい この軸の選択は、@irofさんの以下の内容も参考にしてます。 モデリングのきほん：https://irof.hateblo.jp/entry/2019/12/05/165232 （表現方法） （実装有） 情報ヒント有 （実装無） 情報ヒント無：枠だけ 図・絵 表 文字のみ システム及びソフト ウェア品質モデル （ISO25010） パターンランゲージ フレームワーク テスト自動化 パタン言語 ※実装有のパターン USDM＠XDDP （変更要求仕様書） 仕様項目＆期待結果 ＠ゆもつよメソッド テスト観点モデル （NGTなど記法メイン） UML PFD＠XDDP デザインパターン ※実装有UML テストカタマリー RDRA（元はUMLベース） 色付き：独自色あり ※偏見ベースの分類 DT：デシジョンテーブル ビジネスフレーム 3C、4Pなど CEG CFD マトリクス分析 （軸も決める） トレーサビリティ マトリクス

3．モデリングをそだてる 34 どのようにモデリングをそだてていったのか？を経験ベースでまとめます。 time クリティカルシンキング学習 ロジカルシンキング学習 開催、テスト設計関連イベント多数実施 ※いろいろ学習有 特に効果的だったのは PFD(Process Flow Diagram) テスト設計コンテスト参加：準優勝1回、優勝1回 （社内） テスト設計技法 ドリル勉強会実施 社内での テスト改善 開催、思考プロセス関係イベント多数実施 TOCfE国際認定プログラム参加 思考プロセス系イベント多数参加 テストカタマリー提案 ワークショップ等実施 RDRA学習、業務適用 ETロボコン（初期名称：UMLロボコン）参加者→実行委員（審査担当など） 国際学会論文化 国際学会論文化 JaSST21東京 チュートリアル エンジニアのための 論理思考技術、作成 ※コンサルあり SEPA翻訳プロジェクト Phase1：モデリング難しい Phase2：モデリングたのしい Phase3へ この辺です

3．モデリングをそだてる方法 35 以下のような活動が効果的でした。 ・事例や情報を集める ※種類と質の双方 - なるべく多くのモデルを知る - 良いモデルをみる ・実際に使う・試す - 素振りする ：勉強会の参加、自習、最近は練習可能な書籍が多い - 勉強会に参加：WACATE、JaSSTなど ・アウトプットする - 勉強会を企画：PFD勉強会では提唱者（清水吉男さん）が来てくれた - フィードバックをもらえるとよい：テスト設計コンテストはよい場 - 調子に乗ってオレオレモデルを提案して炎上 ・実践する - （特に素振りでは）失敗する！ - 業務で実践し、結果を判断、改善する。あわなかったらやめてもよい

3．モデリングをそだてる方法 36 自分の例、前ページの活動と対応した学習によって、ある程度使いこなしてます。 テスト技法の学習 ・テスト技法ドリルで学ぶ ※最初のWACATE参加がキッカケだった記憶 ・WACATE、JaSSTで学ぶ ・WARAI（関西ソフトウェアテスト勉強会）で継続的に紹介 ・業務で適用し大きく改善する ・業務でちょい失敗する ・テスト学習結果の資料化→繰り返し説明のため、講演的な資料として構築 テストマトリクス分析（ゆもつよメソッドなど）の学習 ・JaSST資料、ソフトウェアテストpressなどから学習 ・テスコンに参加、（その他ツールを含めて）試してみる ・実施結果をその他勉強会でも共有、フィードバックを受ける ・業務でも適用して、結果から改善していく ※社内の改善に適用してガイドライン化、論文化＆海外発表 事例や情報を集める 実際に使う・試す アウトプットする 実践する 事例や情報を集める 実際に使う・試す アウトプットする 実践する アウトプットする

3．モデリングをそだてる方法 37 当然、失敗もありまして…、（やらかし）経験からの教訓です。 ・チーム、組織への展開は特に丁寧にやること - 使う人、作る人の役割は大きく異なる - 自分ができても他の人はできないことも多い - 教育、原理原則の説明とセットとした方がよい - 他の人にモデルを使ってもらう時の成功のカギ：適切に対象を理解すること ・うまくいかない場合、無理やり使わない ※あえて「やってみる」ことは重要、ただし個人で＆結果は分析しよう - 適切な適用場所・範囲がある、それを（体験も含め）知ることは大事 - そのうちわかることも多い、認知限界を突破してからまた見るとよい - 無則の組合せテストの例（わかったこと）を紹介 条件 #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 #27 #28 #29 #30 #31 #32 #33 年齢 （0歳未満？） 〇 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 幼児：0-5歳 - 〇 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 子供：6-14歳 - - 〇 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 大人：15-199歳 ※仮 - - - 〇 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - （200歳以上？）INTMAX+1もOK - - - - 〇 - - - - - - - - - - - - - - - - - - - - - - - - - - - - 時間 18:00-21:00 - - - - - 〇 - - - - - - - - - - - - - - - - - - - - - - - - - - - 21:01-23:59 - - - - - - 〇 - - - - - - - - - - - - - - - - - - - - - - - - - - 時間 18:00-21:00 - - - - - - - 〇 - - - - - - - - - - - - - - - - - - - - - - - - - 21:01-23:59 - - - - - - - - 〇 - - - - - - - - - - - - - - - - - - - - - - - - 時間 18:00-21:00 - - - - - - - - - 〇 - - - - - - - - - - - - - - - - - - - - - - - 21:01-23:59 - - - - - - - - - - 〇 - - - - - - - - - - - - - - - - - - - - - - 時間 18:00-21:00 - - - - - - - - - - - 〇 - - - - - - - - - - - - - - - - - - - - - 21:01-23:59 - - - - - - - - - - - - 〇 - - - - - - - - - - - - - - - - - - - - 時間 18:00-21:00 - - - - - - - - - - - - - 〇 - - - - - - - - - - - - - - - - - - - 21:01-23:59 - - - - - - - - - - - - - - 〇 - - - - - - - - - - - - - - - - - - 時間 18:00-21:00 - - - - - - - - - - - - - - - 〇 - - - - - - - - - - - - - - - - - 21:01-23:59 - - - - - - - - - - - - - - - - 〇 - - - - - - - - - - - - - - - - 時間 18:00-21:00 - - - - - - - - - - - - - - - - - 〇 - - - - - - - - - - - - - - - 21:01-23:59 - - - - - - - - - - - - - - - - - - 〇 - - - - - - - - - - - - - - 時間 18:00-21:00 - - - - - - - - - - - - - - - - - - - 〇 - - - - - - - - - - - - - 21:01-23:59 - - - - - - - - - - - - - - - - - - - - 〇 - - - - - - - - - - - - 時間 18:00-21:00 - - - - - - - - - - - - - - - - - - - - - 〇 - - - - - - - - - - - 21:01-23:59 - - - - - - - - - - - - - - - - - - - - - - 〇 - - - - - - - - - - 時間 18:00-21:00 - - - - - - - - - - - - - - - - - - - - - - - 〇 - - - - - - - - - 21:01-23:59 - - - - - - - - - - - - - - - - - - - - - - - - 〇 - - - - - - - - 時間 18:00-21:00 - - - - - - - - - - - - - - - - - - - - - - - - - 〇 - - - - - - - 21:01-23:59 - - - - - - - - - - - - - - - - - - - - - - - - - - 〇 - - - - - - 時間 18:00-21:00 - - - - - - - - - - - - - - - - - - - - - - - - - - - 〇 - - - - - 21:01-23:59 - - - - - - - - - - - - - - - - - - - - - - - - - - - - 〇 - - - - 時間 18:00-21:00 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 〇 - - - 21:01-23:59 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 〇 - - 時間 18:00-21:00 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 〇 - 21:01-23:59 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 〇 結果：金額 1300円 〇 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1000円 - 〇 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 800円 - - 〇 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 500円 - - - 〇 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 無料 - - - - 〇 - - - - - - - - - - - - - - - - - - - - - - - - - - - - 結果：エラー通知 エラー - - - - - 〇 - - - - - - - - - - - - - - - - - - - - - - - - - - - 正常 - - - - - - 〇 - - - - - - - - - - - - - - - - - - - - - - - - - - 時間 18:00-21:00 - - - - - - - 〇 - - - - - - - - - - - - - - - - - - - - - - - - - 21:01-23:59 - - - - - - - - 〇 - - - - - - - - - - - - - - - - - - - - - - - - 時間 18:00-21:00 - - - - - - - - - 〇 - - - - - - - - - - - - - - - - - - - - - - - 21:01-23:59 - - - - - - - - - - 〇 - - - - - - - - - - - - - - - - - - - - - - 時間 18:00-21:00 - - - - - - - - - - - 〇 - - - - - - - - - - - - - - - - - - - - - 21:01-23:59 - - - - - - - - - - - - 〇 - - - - - - - - - - - - - - - - - - - - 時間 18:00-21:00 - - - - - - - - - - - - - 〇 - - - - - - - - - - - - - - - - - - - 21:01-23:59 - - - - - - - - - - - - - - 〇 - - - - - - - - - - - - - - - - - - 時間 18:00-21:00 - - - - - - - - - - - - - - - 〇 - - - - - - - - - - - - - - - - - 21:01-23:59 - - - - - - - - - - - - - - - - 〇 - - - - - - - - - - - - - - - - 時間 18:00-21:00 - - - - - - - - - - - - - - - - - 〇 - - - - - - - - - - - - - - - 21:01-23:59 - - - - - - - - - - - - - - - - - - 〇 - - - - - - - - - - - - - - 時間 18:00-21:00 - - - - - - - - - - - - - - - - - - - 〇 - - - - - - - - - - - - - 21:01-23:59 - - - - - - - - - - - - - - - - - - - - 〇 - - - - - - - - - - - - 時間 18:00-21:00 - - - - - - - - - - - - - - - - - - - - - 〇 - - - - - - - - - - - 21:01-23:59 - - - - - - - - - - - - - - - - - - - - - - 〇 - - - - - - - - - - 時間 18:00-21:00 - - - - - - - - - - - - - - - - - - - - - - - 〇 - - - - - - - - - 21:01-23:59 - - - - - - - - - - - - - - - - - - - - - - - - 〇 - - - - - - - - 時間 18:00-21:00 - - - - - - - - - - - - - - - - - - - - - - - - - 〇 - - - - - - - 21:01-23:59 - - - - - - - - - - - - - - - - - - - - - - - - - - 〇 - - - - - - 時間 18:00-21:00 - - - - - - - - - - - - - - - - - - - - - - - - - - - 〇 - - - - - 21:01-23:59 - - - - - - - - - - - - - - - - - - - - - - - - - - - - 〇 - - - - 時間 18:00-21:00 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 〇 - - - 21:01-23:59 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 〇 - - 時間 18:00-21:00 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 〇 - 21:01-23:59 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 〇 使い方を間違ったDT

3．モデリングをそだてる方法 38 当然、失敗もありまして…、（やらかし）経験からの教訓です。 無則の組合せテストの例（わかったこと） 10個のパラメータ（2水準（値）のパラメータ5つ、3水準が5つ） ※PICTMasterを用いて2因子網羅アルゴリズムでテストケースを作成 頭の中… ・テスト数 ： 2×5＋3×5 = 25ケース（データ） ・PICTで作成 ： 14ケース（データ） 実際… まとめてやるだけなら、3ケース（データ）でOK A A-1 A-2 B B-1 B-2 B-3 A A-1 A-2 B B-1 B-2 B-3 A A-1 A-2 B B-1 B-2 B-3 A A-1 A-2 B B-1 B-2 B-3 A A-1 A-2 B B-1 B-2 B-3 A B C D ケース1 A-1 B-1 C-1 … ケース2 A-2 B-2 C-2 ケース3 C-3

3．モデリングをそだてる方法 39 学習・使う時に意識すると成長につながるポイント ・自分にあう手法を使いこんでトレーニングする ※次ページ参考 - 引き出しにツールセットを持っていると、いろんな見方をすることができる ・結果からふりかえり、判断・改善をする - 素振りで適用有無を判断 - ある程度できるレベルで業務に採用 - 自分の手で感触を得る、そうでないと周りには説明できない - うまく行かない場合は「今じゃない」と考えることも大事 - 小さく適用して、実践結果から改善し、うまくいった部分から広げる ・モデルの読み方、モデル作成者に聞いてみる - コメントで意図を書いてあるようなモデルの方がよい場合が多い ※キレイすぎるモデルは逆に注意！ - そもそも意図を考えていないとモデルに反映されない、ひとこと作成者に聞いてみる（強制しないこと） ・パターン認識へ - 適用範囲がすぐに思いつくようになっていく - 最初は難しい、手を動かして結果を見ていくことで、感触がつかめるようになっていく - よいモデルの使い方をたくさん見ることが重要

3．モデリングをそだてる方法 40 自分にあう手法を使いこんでトレーニング、手法の良し悪しを理解して使おう 引用：https://jasst.jp/symposium/jasst19hokkaido/pdf/S1.pdf

3．モデリングをそだてる方法 41 役割により異なる部分がある。ここまで紹介した内容は「使う」が中心。 使う 作る 広める ※他人が作ったモデルを使う ※他人が使うモデルを作る ※より汎用的なモデルを拡散する 自分の作ったモデルで相手に仕事をしてもらう 分析のマトリクスや組織のベースを作る 他の人が作ったものを使う 例：テスト設計技法などを使う 多くの人に役立つモデル、 より広く使えるフレームを提供する 広げるための布教・サポートをする ここまでの 中心

コンテンツ 42 1．モデリングの原則・知識（実践ソフトウェアエンジニアリング（第9版）より） 2．モデリング実活動の例、活用されるモデル 3．モデリングのそだてかた モデリングに対する考え方の変遷（個人） モデリングをそだてる 4．チョットデキルモデリングへ モデリングのTIPS （捉え方、考え方） 「考え方」を鍛える 「考え方」の役立ちどころ 5．まとめ 6．おまけ

4．モデリングのTIPS（捉え方、考え方） 43 以下、個人的に意識している4点について紹介します。 TIPS1．目的を考える TIPS2．全体を見て、階層とつながりを整える TIPS3．複数のモデルで見る TIPS4．モデルを育てる前提で考える 再掲：モデル/モデリングのユースケース 考える 共有する 応用する 基本的な使い方 参考：考える、共有する、の2点を対象とした内容を紹介します。 ※「応用する」場合は別の技術・知識を必要とする場合が多いため除外

4．モデリングのTIPS（捉え方、考え方） 44 TIPS1．目的を考える ・モデリング・モデルは道具、手段ととらえること - 目的に応じて道具を選ぶことが重要、いわゆるPSfit（Problem-Solution fit） ・目的と手段の構造は階層的、とりあえず1段上だけは常に考えることを推奨 引用：https://speakerdeck.com/mizunori/approch-for-designing-convincing-test-case 新商品の売上 を向上させる ターゲットとして XXXに売り込む XXXへのTVCMを実施 商品のコンセプト をXXXとする 価格帯を XXXに設定する XXXを中心に広告 ・・・ ・・・ 理由 ・・・ ・・・ 販売チャネルとし てXXXと連携する ・・・ 理由 手段 / 目的 目的 手段

4．モデリングのTIPS（捉え方、考え方） 45 TIPS1．目的を考える 例：テストケースも目的を考慮した階層化ができる 引用：https://speakerdeck.com/mizunori/approch-for-designing-convincing-test-case テストケース テストケース目的 Target 「おとな」設定時 購入種別パラメータ を網羅的に確認する 購入計算 機能 入場時間パラメータ を網羅的に確認する パラメータの組合せ をパターン確認する ・・・の時 理由 テストケース テストケース テストケース テストケース 理由 １秒以内に計算が 完了することを確認 理由 ・・・ 理由

4．モデリングのTIPS（捉え方、考え方） 46 TIPS1．目的を考える 例：目的とセットでパターン的に使用する技法も決まる（技法の知識がある前提） 引用：https://speakerdeck.com/mizunori/approch-for-designing-convincing-test-case テストケース テストケース目的 Target 「おとな」設定時 購入種別パラメータ を網羅的に確認する 購入計算 機能 入場時間パラメータ を網羅的に確認する パラメータの組合せ をパターン確認する ・・・の時 同値分割・境界値分析 テストケース テストケース テストケース テストケース DT＆CFD １秒以内に計算が 完了することを確認 理由 ・・・ 同値分割

4．モデリングのTIPS（捉え方、考え方） 47 TIPS2．全体を見て、階層とつながりを整える ・用語を揃える、適切な言葉を使う ※用語集を作るだけでも効果的 ・階層をつくることが苦手な人は多い、用語も適当に使われることが多い -日本語の類語辞典を使う、日本語トレーニングも効果的 ・マインドマップを意識的に使うことでトレーニングが可能 引用：https://qualab.jp/materials/stdc-kansai2012.121103.bw.pdf こんな感じ？ 新規作成－初期値ーパラメータA 新規作成－パラメータB－1500 新規作成－データX－時間 新規作成－データY－初期値 処理時間－新規作成－データX https://amzn.asia/d/0hvXeULw

4．モデリングのTIPS（捉え方、考え方） 48 TIPS3．複数のモデルで見る ・1つのモデルですべて表現しようとしない ※人の頭には3軸以上は収まらない ・各モデルに対して、メリデメを知った上で使うことが重要 ダメな例：使い方を間違ったDT 引用：https://www.aster.or.jp/business/contest/contest2017/pdf/presentation_studio_iburi.pdf

4．モデリングのTIPS（捉え方、考え方） 49 TIPS4．モデルを育てる前提で考える ※すべてのモデルが対象ではないです ・完璧なモデルはないと考える、現状のモデルを「決める」ことも重要 ・継続的に成長させることで価値が高まる、成長プロセスに価値があるモデルも多い 対象例：パターンランゲージ成果物、テスト観点モデル、シナリオプランニング等 時系列

4．モデリングのTIPS（捉え方、考え方） 50 まとめ TIPS1．目的を考える TIPS2．全体を見て、階層とつながりを整える TIPS3．複数のモデルで見る TIPS4．モデルを育てる前提で考える モデリングに共通の捉え方、考え方が存在する でも、簡単に身につくものなら苦労しねぇよ！（心の叫び）

4．「考え方」を鍛える 51 では、モデリングをうまくやるための考え方、トレーニングの一例を紹介します。 time クリティカルシンキング学習 ロジカルシンキング学習 開催、テスト設計関連イベント多数実施 ※いろいろ学習有 特に効果的だったのは PFD(Process Flow Diagram) テスト設計コンテスト参加：準優勝1回、優勝1回 （社内） テスト設計技法 ドリル勉強会実施 社内での テスト改善 開催、思考プロセス関係イベント多数実施 TOCfE国際認定プログラム参加 思考プロセス系イベント多数参加 テストカタマリー提案 ワークショップ等実施 RDRA学習、業務適用 ETロボコン（初期名称：UMLロボコン）参加者→実行委員（審査担当など） 国際学会論文化 国際学会論文化 JaSST21東京 チュートリアル エンジニアのための 論理思考技術、作成 ※コンサルあり SEPA翻訳プロジェクト Phase1：モデリング難しい Phase2：モデリングたのしい Phase3へ この辺です

4．「考え方」を鍛えよう 52 「作る」活動へ、個人的に効果的だった内容を紹介します。※個人差あるかも 使う 作る 広める ※他人が作ったモデルを使う ※他人が使うモデルを作る ※より汎用的なモデルを拡散する 自分の作ったモデルで相手に仕事をしてもらう 分析のマトリクスや組織のベースを作る 他の人が作ったものを使う 例：テスト設計技法などを使う 多くの人に役立つモデル、 より広く使えるフレームを提供する 広げるための布教・サポートをする ここを ターゲット

4．「考え方」を鍛えよう 53 「作る」フェーズは難易度が上がる。 対象 ・テスト観点モデル、テストマトリクスによる分析など 悩み ・軸を決めるなど、根本から考える必要がでてくる、 どうやって考えるとよいか？ ・どこから手を付けて、どうまとめるとよいものができるのか？ ・多くの人が使う場合に、作ったものをどう説明すると、 うまく使ってもらえるか？

4．「考え方」を鍛えよう ※個人の体験 54 time クリティカルシンキング学習 ロジカルシンキング学習 テスト設計コンテスト参加：準優勝1回、優勝1回 社内での テスト改善 TOCfE国際認定プログラム参加 思考プロセス系イベント多数参加 テストカタマリー提案 ワークショップ等実施 国際学会論文化 国際学会論文化 ※コンサルあり 解決編 ・「考える技術」を共通の考え方として取り入れて、育てることで突破した。 - 考える技術：ロジカルシンキング、クリティカルシンキング、TOC思考プロセスなど ・組織で使う改善向けの活動が、思考の見直し機会となった

4．「考え方」を鍛えよう 55 自分の場合：大きな転換点となる要素は3つ存在。 1．思考技術の学習（ロジカル/クリティカルシンキング） ・XXシンキング（XX思考）は問題解決の手段 - 人の思考/脳に最適化した問題解決の手段がロジカル/クリティカルシンキング - 共通的な捉え方（人が考えやすい形式） - 階層構造で考える - 広く見る、狭く集中する ・書籍で紹介される枠組み→「考える」「共有する」と共通点あり - 考え方、伝え方、書き方などを体系化 - 書籍内の枠組みの例：「考える、書く」 、「考える、伝える」 - コミュニケーションの目的：理解、フィードバック、アクション ＠ロジカルシンキング

4．「考え方」を鍛えよう 56 自分の場合：大きな転換点となる要素は3つ存在。 2．思考技術の学習（TOC思考プロセス、TOCfE） ・要素をつなぐ（ツリーとブランチ） - TOCfEのブランチ（ロジックブランチ）は子供でもすぐ使えるレベルで、丁寧な体系化が行われている - 思考を図で整理するので、図で表現するモデリングもレベルアップする - ロジックツリー（＠ロジカルシンキング）の考え方と相互補完できる ・論理が正しいことを確認する問い：CLR（Categories of Legitimate Reservation） - 普段使いできるようになると、考える速度が上がり、精度もとても高くなる - 1つ1つ丁寧にロジックを確認する - 問いは次ページに記載 ロジックブランチ@TOCfE 時系列、因果の流れで分ける ロジックツリー 分類を切り口で分ける

4．「考え方」を鍛えよう 57 参考：CLRの4つの問い 引用：https://speakerdeck.com/mizunori/how-to-think-using-logic-branch-and-logic-tree?slide=93 CLR 項目 質問 内容 確認 対象 の図 意味の 明瞭性 実体の 存在 因果関係の 存在 原因の 不十分 どういう 意味 ですか？ それは 本当 ですか？ 因果が 繋がって いますか？ それで 十分 ですか？ ？ ？ ？ ？ 個々のエンティティ 記載の内容を 確認します。 個々のエンティティ が本当の内容か？ を確認します。 ２つの項目の 因果関係について 確認します。 因果関係について 不足の項目が 無いかを確認します。

4．「考え方」を鍛えよう 58 自分の場合：大きな転換点となる要素は3つ存在。 3．とある活動からの思考の見直し ・抽象度のコントロール - Googleマップでもう100m上がる/下がる、といったイメージ表現 - 粒度、抽象度をうまくコントロールして、要素を考えるトレーニングがスタート ・各ツール/フレームワークの特徴・メリデメを理解して使う - 1つのモデルで表現する際に、得意・不得意を知っている/知っていないで大きく変わる - 図や表の表現の限界を把握し、相互補完できる要素をうまく組み合わせる ・考え抜く - 中途半端な検討結果では、自信をもって大規模の展開はできない - どんな質問が来ても自信をもって答えるためには、とことんまで考え抜いた、と言えるまで突き進む ・おまけ：最後は国際学会の論文化 - 論文のひな形は問題解決の手続きと同じ - 論文にまとめる思考を身につけると、問題解決力も向上する 国際学会論文化 https://amzn.asia/d/0hMx4JtR

4．「考え方」を鍛えよう 59 自分の場合：大きな転換点となる要素は3つ存在。 →すべて「考え方」を鍛える内容 モデリング力を上げるには「考え方」をトレーニングするとよい派（個人意見） 1．思考技術の学習（ロジカル/クリティカルシンキング） 2．思考技術の学習（ TOC思考プロセス、TOCfE） 3．とある活動からの思考の見直し

4．モデリングのそだちかた（個人的な意見） 60 モデリングのそだちかたは大きく2パターンと考えます。 A．多くのモデリングを学び、使いながら共通の考え方を身につける B．モデリングを学びつつ、共通の考え方につながる技術を身につけ、活用する テスト技法 PFD UML 共通の考え方 テスト観点 モデル ・・・

4．モデリングのそだちかた（個人的な意見） 61 モデリングのそだちかたは大きく2パターンと考えます。 A．多くのモデリングを学び、使いながら共通の考え方を身につける B．モデリングを学びつつ、共通の考え方につながる技術を身につけ、活用する テスト技法 PFD UML 共通の考え方 テスト観点 モデル ・・・ クリティカルシンキング、ロジカルシンキング 思考プロセス、問題解決技術 ※コンセプチュアルスキルと呼ばれることもあります

4．「考え方」の役立ちどころ 62 モデリングにどう役立てるか？の例や知見を4つのTIPSと対応づけてみます。 TIPS1．目的を考える TIPS2．全体を見て、階層とつながりを整える TIPS3．複数のモデルで見る TIPS4．モデルを育てる前提で考える

4．「考え方」の役立ちどころ 63 TIPS1．目的を考える リバースモデリングの目的はなんだろう？ ・仕様変更のために、現在の正確なふるまいを（テスト成果物から）確認する ・時間のかかるテストケースの必要性判断のため、重複やテストの意図を確認する ・リグレッションテスト見直しへ、現在のテストと実際の仕様の全体像を比較する ・新システムを構築するために、現在の姿を把握する ← 本当に必要？

4．「考え方」の役立ちどころ 64 TIPS2．全体を見て、階層とつながりを整える ロジカル/クリティカルシンキングのロジックツリー構造がそのまま役立つ ※要トレーニング、実際に使う際にはマインドマップを活用している So What Why So MECE 引用：https://speakerdeck.com/mizunori/how-to-think-using-logic-branch-and-logic-tree

4．「考え方」の役立ちどころ 65 TIPS3．複数のモデルで見る：メリデメの把握 使ってみて把握もできますが、以下が参考となります。（以下、引用してます） ・（メリデメ） 組み合わせマトリクス型記法（例：状態遷移表、競合マトリクス） – 詳細に内容や意図を書きにくい – 組み合わせの網羅性は分かりやすい – 規模の増大に従って俯瞰性が急激に下がっていく – 巨大なマトリクスで空白のセルが多いと俯瞰性が低い – 組み合わせマトリクスだけでは完結しないので 他の記法と組み合わせねばならず俯瞰性が下がる – 構造を過度に抽象化しにくいため一貫性が保ちやすい 引用：https://qualab.jp/materials/stdc-kansai2012.121103.bw.pdf

4．「考え方」の役立ちどころ 66 TIPS3．複数のモデルで見る：メリデメの把握 使ってみて把握もできますが、以下が参考となります。（以下、引用してます） ・（メリデメ）フレームベースマトリクス型記法 （例：DT、直交表、ゆもつよマトリクス、スープカレー表） – 詳細に内容や意図を書きにくい – 上手に構造化をしないと網羅性は分かりにくい – 全体マトリクスと詳細マトリクスを分けないと俯瞰性が下がりがちになる – トリガ側を熱心に詳細化しやすいので俯瞰性が下がりがちになる – 構造化の段数を制約しなければ構造は歪みにくい – 構造を過度に抽象化しにくいため一貫性が保ちやすい 引用：https://qualab.jp/materials/stdc-kansai2012.121103.bw.pdf

4．「考え方」の役立ちどころ 67 TIPS3．複数のモデルで見る：メリデメの把握 使ってみて把握もできますが、以下が参考となります。（以下、引用してます） ・（メリデメ） ツリー・ネットワーク型記法 （例：マインドマップ、クラシフィケーションツリー、NGT） – 詳細に内容や意図を書きにくい – ノード間の関係を明示しないと網羅性は分かりにくい – 詳細ノードを折りたためれば俯瞰性は高い – 構造化の段数を制約しないため構造が歪みにくい – 特定のサブツリーばかり熱心に詳細化すると構造は歪みやすい – 構造を過度に抽象化しにくいため一貫性が保ちやすい – 同じ構造が複数の箇所に表れやすいため煩雑になることがある – ネットワーク構造の場合、上手に整理しないとゴチャゴチャになる 引用：https://qualab.jp/materials/stdc-kansai2012.121103.bw.pdf

4．「考え方」の役立ちどころ 68 TIPS4．モデルを育てる前提で考える 参考で紹介。（毎月リリースのリグレッションテストが対象） ・Phase0：最初はテストなど不要、とにかく売れるプロダクトにする ・Phase1：顧客がつき始める →特定顧客に対して確認ができればOKと割り切る、全機能は確認不要 ・Phase2：顧客がじわじわと増え続ける →顧客の切り口では大変、共通項目＋特殊企業という構成へ変更 ・Phase3：拡張ツール連携追加、将来の拡大を考慮 →構造見直し＋手動テストの負担削減で自動化も追加

4．「考え方」の例 69 理解しづらい概念を考える場合は、 その必要性を問うと理解につながることもあります。 実際に考えてみましょう。 ・テストタイプはなぜ必要なのか？ ・リバースエンジニアリング/モデリングの必要性

4．「考え方」の例 70 ・テストタイプはなぜ必要なのか？ ※個人的な理解、分類、考え方が含まれますので取扱い注意 不具合を 出したくない 効率的にテストケース を導出したい、 実施したい １つの詳細範囲に 集中検討すると 抜けが少ない テストタイプとして グルーピング、 整理して活用する！ 過去の不具合を テストの検討に 反映させる ※全ての不具合を １つずつ検討は 時間がかかる テストの検討時 抜けが無いことを 確認したい 上手なテスト検討、 他の人の検討を整理・ 抽象化して活用する 段階的に分割された 範囲で絞って 検討すると短時間で 考えやすい 全体を段階的に 抜け確認を することが 効果的 予算に似合った 最適なテストを 実施したい 重要度に応じて テストの優先 順位付けをしたい 引用：https://speakerdeck.com/mizunori/learn-test-and-testing-for-everyone

抜けなく 効率的に 状況に 応じて 4．「考え方」の例 71 ・テストタイプはなぜ必要なのか？ ※個人的な理解、分類、考え方が含まれますので取扱い注意 不具合を 出したくない 効率的にテストケース を導出したい、 実施したい １つの詳細範囲に 集中検討すると 抜けが少ない テストタイプとして グルーピング、 整理して活用する！ 過去の不具合を テストの検討に 反映させる ※全ての不具合を １つずつ検討は 時間がかかる テストの検討時 抜けが無いことを 確認したい 上手なテスト検討、 他の人の検討を整理・ 抽象化して活用する 段階的に分割された 範囲で絞って 検討すると短時間で 考えやすい 全体を段階的に 抜け確認を することが 効果的 予算に似合った 最適なテストを 実施したい 重要度に応じて テストの優先 順位付けをしたい 引用：https://speakerdeck.com/mizunori/learn-test-and-testing-for-everyone

4．「考え方」の例 72 ・リバースエンジニアリング/モデリングの必要性 ※自分なりの解釈 ビジネス的な必要性 ・他社が優れた製品を出した場合にビジネス上で負けないよう、 自社への取り込みを検討・実施する ・新しい業界・製品種別に入り込むため、他社製品を徹底的に分析 - 一時期の某社の製品は他社製品の特長を取り入れ、不要な機能を除外して安価に提供 特定の組織における必要性（都合） ・BtoB＆長期で使われ続ける大規模システムでたまによく発生する - 例：保守し続けていた20年ものの組み込みハードウェア（ソースコードすらないことも） - 担当者も引退して10年、ハードウェアも限界、更改で代替品を用意したいが… ・組織的なプロダクト開発でも起こる ※次ページ以降で紹介

4．「考え方」の例 73 ・リバースエンジニアリング/モデリングの必要性 ※自分なりの解釈 組織的なプロダクト開発の、以下3ケースを考えてみましょう。 - ケースA：インクリメンタルな開発で運用継続中 - ケースB：運用継続中のシステムを更改 - ケースC：大規模開発の途中 前提：大小、成果物あるなし、順序に関わらず、V字の開発の流れが存在している ※以下、構成は「要件」「仕様」「実装」に簡略化してます 要件 仕様 要件ﾃｽﾄ 仕様ﾃｽﾄ 実装・テスト

4．「考え方」の例：リバースエンジニアリング/モデリングの必要性 ※自分なりの解釈 74 ケースA：インクリメンタルな開発で運用継続中 ・大きな開発、その後に継続的な小さな修正が続く ・インクリメンタルな開発で運用を続ける 要件 仕様 要件ﾃｽﾄ 仕様ﾃｽﾄ 実装・ﾃｽﾄ 要件 仕様 要件ﾃｽﾄ 仕様ﾃｽﾄ 実装・ﾃｽﾄ 要件 仕様 要件ﾃｽﾄ 仕様ﾃｽﾄ 実装・ﾃｽﾄ … 時系列 変更 変更 変更 変更 変更

4．「考え方」の例：リバースエンジニアリング/モデリングの必要性 ※自分なりの解釈 75 ケースA：インクリメンタルな開発で運用継続中 ・開発途中から継続して変更は入る、運用中でも変更は入り続ける ・すべてをメンテナンスしきる規律・体力・胆力はまずない ※メンテ必須の業界もある ・たいてい、ドキュメント的な情報は置いて行かれ、断片的に散らばる ・時系列的にテストの方が新しい（正しい）情報が含まれる 要件 仕様 要件ﾃｽﾄ 仕様ﾃｽﾄ 実装・ﾃｽﾄ 要件 仕様 要件ﾃｽﾄ 仕様ﾃｽﾄ 実装・ﾃｽﾄ 要件 仕様 要件ﾃｽﾄ 仕様ﾃｽﾄ 実装・ﾃｽﾄ … 変更 変更 変更 変更 変更 Doc Doc Doc Doc Doc Doc Doc 実装には反映（たぶん）

4．「考え方」の例：リバースエンジニアリング/モデリングの必要性 ※自分なりの解釈 76 ケースA：インクリメンタルな開発で運用継続中 ・状況、傾向を把握すればやり方は見えてくる - 例：インクリメンタルなプロセスをコントロール、必要なドキュメントを残し「定期統合」をする - テストで最新の姿を見せるという考え方もできる ・捨てる前提があってもよい - ワンタイムモデル、手書きで共有できれば十分な場合も多い - ソースコード、コードの分析で分かるものは除外など ・見直し・つなぎあわせる際には、どこかの全体像＋差分の変更意図が伺えるとよい 要件 仕様 要件ﾃｽﾄ 仕様ﾃｽﾄ 実装・ﾃｽﾄ 要件 仕様 要件ﾃｽﾄ 仕様ﾃｽﾄ 実装・ﾃｽﾄ 要件 仕様 要件ﾃｽﾄ 仕様ﾃｽﾄ 実装・ﾃｽﾄ … 実装には反映（たぶん） Doc Doc Doc Doc Doc Doc Doc

4．「考え方」の例：リバースエンジニアリング/モデリングの必要性 ※自分なりの解釈 77 ケースB：運用継続中のシステムを更改 ・ケースAの運用の継続後、システムの更改が決まる 要件 仕様 要件ﾃｽﾄ 仕様ﾃｽﾄ 実装・ﾃｽﾄ 要件 仕様 要件ﾃｽﾄ 仕様ﾃｽﾄ 実装・ﾃｽﾄ … 時系列 変更 変更 変更 変更 要件 仕様 要件ﾃｽﾄ 仕様ﾃｽﾄ 実装・ﾃｽﾄ 更改 決定

4．「考え方」の例：リバースエンジニアリング/モデリングの必要性 ※自分なりの解釈 78 ケースB：運用継続中のシステムを更改 ・AsIsも必要だが、ToBeを洗い出す必要がある - むしろToBeが重要、ToBeのために必要に応じてAsIsを調べる ・厳密なAsIsを網羅的に求める作業は不要、必要に応じた調査で進める - 前段階の運用で、テストモデルでうまく全体像を拾い上げていればAsIs情報がすぐ拾えて便利となる ・テストのみでToBeを出すことはできないと考えた方がよい 要件 仕様 要件ﾃｽﾄ 仕様ﾃｽﾄ 実装・ﾃｽﾄ 要件 仕様 要件ﾃｽﾄ 仕様ﾃｽﾄ 実装・ﾃｽﾄ … 変更 変更 変更 変更 要件 仕様 要件ﾃｽﾄ 仕様ﾃｽﾄ 実装・ﾃｽﾄ 更改 決定 Doc Doc Doc Doc Doc

4．「考え方」の例：リバースエンジニアリング/モデリングの必要性 ※自分なりの解釈 79 ケースC：大規模開発の途中 ・ケースBの続き、もしくは新規の大規模開発の途中段階 ・「テストなんとかしてくれ」という謎リクエスト 要件 仕様 要件ﾃｽﾄ 仕様ﾃｽﾄ 実装・ﾃｽﾄ 変更 変更 変更 変更 変更 変更 変更

4．「考え方」の例：リバースエンジニアリング/モデリングの必要性 ※自分なりの解釈 80 ケースC：大規模開発の途中 ・業務や要件からの見直しが定石 ※ToBeがどこにもないため、生み出す必要がある ・ToBeはテストからリバースして生み出すことは不可能 - テストで何とかしてくれと言われても手遅れ ・RDRAでAsIs、ToBeを扱う方法が紹介されている https://www.rdra.jp/ 要件 仕様 要件ﾃｽﾄ 仕様ﾃｽﾄ 実装・ﾃｽﾄ 変更 変更 変更 変更 変更 変更 変更 Doc Doc

4．「考え方」の例 81 ・リバースエンジニアリング/モデリングの必要性 ※自分なりの解釈 以下の3ケースを紹介しました。 - ケースA：インクリメンタルな開発で運用継続中 - ケースB：運用継続中のシステムを更改 - ケースC：大規模開発の途中 3ケースそれぞれ、必要な活動、目的が変わります。 発生状況の背景、必要な活動や目的を捉え、 自分で「考える」ことによって、役立つモデルを選択し、モデリングしましょう！

コンテンツ 82 1．モデリングの原則・知識（実践ソフトウェアエンジニアリング（第9版）より） 2．モデリング実活動の例、活用されるモデル 3．モデリングのそだてかた モデリングに対する考え方の変遷（個人） モデリングをそだてる 4．チョットデキルモデリングへ モデリングのTIPS （捉え方、考え方） 「考え方」を鍛える 「考え方」の役立ちどころ 5．まとめ 6．おまけ

5．まとめ：モデル/モデリングの解釈 83 モデルの個人的解釈： 現実そのものではない。そのうえで、役に立つ道具 モデル/モデリングのユースケース： 考える 共有する 応用する 基本的な使い方 モデリングをする人の役割：右に行くほど難易度が高い 使う 作る 広める ※他人が作ったモデルを使う ※他人が使うモデルを作る ※より汎用的なモデルを拡散する

5．まとめ：モデリングのそだてかた 84 初級編 ※主に「使う」人 ・事例や情報を集める ・実際に使う・試す ・アウトプットする ・実践する 中級編 ※主に「作る」人 ・個人的な推奨：「考え方」を鍛えること ※各自の課題を把握して進め方を自分で考えて 活動してもらうとよいです

5．まとめ：モデリングのTIPS（捉え方、考え方） 85 4つのTIPSを紹介 TIPS1．目的を考える TIPS2．全体を見て、階層とつながりを整える TIPS3．複数のモデルで見る TIPS4．モデルを育てる前提で考える モデリングに共通の捉え方、考え方が存在する 「考え方」を鍛えるとモデリング力もアップする

5．まとめ：おしまい 86 ・各自の役割、スキル感と興味にあわせた 「そだてかた」を考えてもらえればと ・モデリングを考えるきっかけや、 そだてかたの参考になれば幸いです

5．まとめ：役立つ資料系、参考文献（スライド・モデリング関係） 87 にしさん資料 テスト設計コンテスト2013関西予選招待講演「てすとづくり ～質の高いテスト設計の原理～」 動画：https://www.youtube.com/watch?v=zhIk9G7S1Ok スライド：https://qualab.jp/materials/stdc-kansai2012.121103.bw.pdf いろふさん資料 モデリングのきほん https://irof.hateblo.jp/entry/2019/12/05/165232 いせりさん資料 テスト設計をより良くするモデリングと観点分析 https://speakerdeck.com/goyoki/improve-test-design-with-modeling

5．まとめ：役立つ資料系、参考文献（スライド・その他） 88 テスト設計技法、その前に～フェイスアップ、次にビルドアップ、その先にマインドアップ～＠JaSST19 Hokkaido https://jasst.jp/symposium/jasst19hokkaido/pdf/S1.pdf テスト観点モデル https://qualab.jp/materials/stdc-kansai2012.121103.bw.pdf ゆもつよメソッド関連資料＠JaSST21 Tohoku-レポート https://www.jasst.jp/symposium/jasst21tohoku/ テスト自動化パタン言語 https://kencolle.github.io/AutomationPatternLanguage/Introduction.html RDRA https://www.rdra.jp/ PFD https://affordd.jp/koha_hp/process/PFDform3.pdf https://speakerdeck.com/mizunori/how-to-draw-pfd-process-flow-diagram

5．まとめ：役立つ資料系、参考文献（書籍系：ソフトウェアエンジニアリング、ソフトウェアテスト） 89 実践ソフトウェアエンジニアリング（第9版）Roger.S.Pressman他、SEPA翻訳プロジェクト、オーム社、2021年 https://amzn.asia/d/08X9eofC [入門+実践]要求を仕様化する技術・表現する技術 清水 吉男、技術評論社、2010年 https://amzn.asia/d/0c6RKwQq [改訂新版]マインドマップから始めるソフトウェアテスト 池田 暁、鈴木 三紀夫、技術評論社、2019 https://amzn.asia/d/0hvXeULw ソフトウェアテスト技法ドリル【第2版】: テスト設計の考え方と実際 秋山浩一、日科技連出版社、2022 https://amzn.asia/d/0jhjQCaW

5．まとめ：役立つ資料系、参考文献（書籍系：思考関係） 90 ロジカル・シンキング 照屋 華子、岡田 恵子、東洋経済新報社、2001 https://amzn.asia/d/0bF5Irjg 3分でわかるロジカル・シンキング 大石 哲之、日本実業出版社、2008 https://amzn.asia/d/0dRrI14G 新版 考える技術・書く技術 問題解決力を伸ばすピラミッド原則 バーバラ・ミント(著)、山崎 康司（訳）、ダイヤモンド社、1999 https://amzn.asia/d/044WOlrn 考える力をつける3つの道具 岸良 裕司、きしら まゆこ、ダイヤモンド社、2014 https://amzn.asia/d/0cs0Yd0j

5．まとめ：参考文献（自己引用） 91 テストモデリング：STUDIO IBURI発表資料＠テスト設計コンテスト2017 https://www.aster.or.jp/business/contest/contest2017/pdf/presentation_studio_iburi.pdf テストモデリング：テストカタマリーワークショップ（説明のみ） https://speakerdeck.com/mizunori/test-conglomeration-workshop テスト関連：納得できるテストをつくるアプローチ https://speakerdeck.com/mizunori/approch-for-designing-convincing-test-case テスト関連：みんなに役立つ「テスト」を考えよう https://speakerdeck.com/mizunori/learn-test-and-testing-for-everyone 論理思考関連：論理的に考えよう!～ロジックツリー＆ロジックブランチの使いどころ～ https://speakerdeck.com/mizunori/how-to-think-using-logic-branch-and-logic-tree ※以下にまとまってます。 https://speakerdeck.com/mizunori

コンテンツ 92 1．モデリングの原則・知識（実践ソフトウェアエンジニアリング（第9版）より） 2．モデリング実活動の例、活用されるモデル 3．モデリングのそだてかた モデリングに対する考え方の変遷（個人） モデリングをそだてる 4．チョットデキルモデリングへ モデリングのTIPS （捉え方、考え方） 「考え方」を鍛える 「考え方」の役立ちどころ 5．まとめ 6．おまけ

6-1．モデリング、その先へ 93 その先に関して軽く触れておきます。※自分もできてる気がしません 使う 作る 広める ※他人が作ったモデルを使う ※他人が使うモデルを作る ※より汎用的なモデルを拡散する 自分の作ったモデルで相手に仕事をしてもらう 分析のマトリクスや組織のベースを作る 他の人が作ったものを使う 例：テスト設計技法などを使う 多くの人に役立つモデル、 より広く使えるフレームを提供する 広げるための布教・サポートをする ここを ターゲット

6-1．モデリング、その先へ 94 軽く、2点だけ紹介します。 常中の領域 多くの人に役立つモデル、 より広く使えるフレームを提供する 広げるための布教・サポートをする 広める領域 あらゆるものはモデリング 考える行為とモデリングの一致へ

6-1．モデリング、その先へ：常中の領域 95 常中の領域 あらゆるものはモデリング 考える行為とモデリングの一致へ （表現方法） （実装有） 情報ヒント有 （実装無） 情報ヒント無：枠だけ 図・絵 表 文字のみ システム及びソフト ウェア品質モデル （ISO25010） パターンランゲージ フレームワーク テスト自動化 パタン言語 ※実装有のパターン USDM＠XDDP （変更要求仕様書） 仕様項目＆期待結果 ＠ゆもつよメソッド テスト観点モデル （NGTなど記法メイン） UML PFD＠XDDP デザインパターン ※実装有UML テストカタマリー RDRA（元はUMLベース） 色付き：独自色あり ※偏見ベースの分類 DT：デシジョンテーブル ビジネスフレーム 3C、4Pなど CEG CFD マトリクス分析 （軸も決める） トレーサビリティ マトリクス ・文字のみの範囲も モデリングと捉えることで、 思考とモデリングが同一化 ・どんな枠を使うか 枠を作る必要があるか その枠をどうカスタムするか 適切な用語となっているか 常に考えることになる 枠を 作る

6-1．モデリング、その先へ：広める領域 96 多くの人に役立つモデル、 より広く使えるフレームを提供する 広げるための布教・サポートをする 広める領域 多くに人が使うモデルとは？実際に使われるモデルを考えると… ・XDDP ・UML ・RDRA 必要な活動はどうなるだろうか？ ・ツール化、使用例/事例・サンプル、サポート、書籍化、コミュニティ化 ・ルール・必ず守るもの、カスタマイズ性、自由度のバランス ・メリデメの補完方法の伝達、実利用からのフィードバックと改善

6-2．学ぶこと、考えること、実践すること 97 学ぶこと、考えること、実践することを繰り返していきましょう！ 考える 学ぶ 実践する 学んだものを試す 実践した結果から学ぶ 学んだものを活用して 自分の考え方を見直す 自分でしっかり考えた 内容で実践する 考え方を身につけて 効果的に学ぶ 実践した結果を 自分なりに考える （教訓とする）

6-2．学ぶこと、考えること、実践すること 98 「エフェクチュエーション」のプロセスが学びのプロセスの参考になります。 ※本来は不確実性への適応プロセスですが、学びにも役立ちます https://amzn.asia/d/0hxjHTSL 手中の鳥 ・何を知っているか ・誰を知っているか 何が できるか 出会う 人々との 相互作用 パートナー 知識の獲得 新たな 手段 新たな 目的 手持ちの手段 ではじめる 偶然を テコにする ・予期せぬ手段生成 できる範囲で 活動する 偶然を 受け入れる 認知限界を 超える