モデリングのそだてかた

モデリングのそだてかた 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．おまけ

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原則設計モデルの作成は、アジャイルな開発アプローチを除外しない

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

2．モデリングの実活動の例 13 今までの活動例：テストカタマリー ※自分たちで設計する記法を自分で考えたテストベース：機能⇒ DFD参照モデル <<ユーザ接点機能>> 演奏系操作をする + 異常値
<<機能共通>> 演奏準備をする <<ユーザ接点機能>> SE操作をする + 機能組合せ <<ユーザ接点機能>> 検索をする + 機能組合せ + タイミング <<ユーザ接点機能>> 予約をする <<ユーザ接点機能>> オーナー設定をする + 機能組合せ + 異常値 + セキュリティ <<機能共通>> 課金判定をする + 機能組合せ + 異常値 + 互換性 + 性能効率性 <<機能共通>> 曲間表示をする + フェールソフト <<ストレージアクセス>> <<ユーザ接点機能>> バックアップをする + フェールソフト <<制約有機能>> <<IF接点機能>> <<ユーザ接点機能>> 配信をする + フェールソフト + 使用性 + セキュリティ + 機器組合せ <<IF接点機能>> 営業状態判定をする営業状態状態遷移>状態遷移＜機能グループ＞コンテンツを使う + セキュリティ + 互換性 <<IF接点機能>> 録音、録画をする + 機能組合せ + 不具合確認 <<IF接点機能>> <<ユーザ接点機能>> 開局操作をする引下げ不具合分析>シーケンス図＜機能グループ＞歌う <<制約有機能>> 映像再生する <<ユーザ接点機能>> 設置時設定をする <<制約有機能>> 演奏をする演奏状態遷移>状態遷移 <<IF接点機能>> 採点をする <<IF接点機能>> HDD障害の通知をする + 異常値 <<機能共通>> カロリー表示をする <<制約有機能>> 楽曲演奏する + 不具合確認 + 信頼性 <<IF接点機能>> プログラムを更新するプログラム更新処理>アクティビティ図 + 処理重ね : 処理重ね + タイミング : タイミング <<制約有機能>> コンテンツを使う + 使用性 + 処理重ね + タイミング <<制約有機能>> 歌うテストベース：機能外要求、記述されている気がかり事項 + 機器組合せ + 周辺機器外部機器互換 + 移植性新採点移植確認 + セキュリティセキュリティ + 通信費通信費確認「＋」項目はパターン以外で追加した品質要素となる ~ 信頼性 ~ 使用性 ~ 性能効率 ~ 異常値 ~ 機能適合ユーザ接点機能 + 予約同時入力(正常動作確認) : 同時入力・処理 + 予約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操作をする + 機能組合せ <<ユーザ接点機能>> 検索をする + 機能組合せ + タイミング <<ユーザ接点機能>> 予約をする <<ユーザ接点機能>> オーナー設定をする + 機能組合せ + 異常値 + セキュリティ <<機能共通>> 課金判定をする + 機能組合せ + 異常値 + 互換性 + 性能効率性 <<機能共通>> 曲間表示をする + フェールソフト <<ストレージアクセス>> <<ユーザ接点機能>> バックアップをする + フェールソフト <<制約有機能>> <<IF接点機能>> <<ユーザ接点機能>> 配信をする + フェールソフト + 使用性 + セキュリティ + 機器組合せ <<IF接点機能>> 営業状態判定をする営業状態状態遷移>状態遷移＜機能グループ＞コンテンツを使う + セキュリティ + 互換性 <<IF接点機能>> 録音、録画をする + 機能組合せ + 不具合確認 <<IF接点機能>> <<ユーザ接点機能>> 開局操作をする引下げ不具合分析>シーケンス図＜機能グループ＞歌う <<制約有機能>> 映像再生する <<ユーザ接点機能>> 設置時設定をする <<制約有機能>> 演奏をする演奏状態遷移>状態遷移 <<IF接点機能>> 採点をする <<IF接点機能>> HDD障害の通知をする + 異常値 <<機能共通>> カロリー表示をする <<制約有機能>> 楽曲演奏する + 不具合確認 + 信頼性 <<IF接点機能>> プログラムを更新するプログラム更新処理>アクティビティ図 + 処理重ね : 処理重ね + タイミング : タイミング <<制約有機能>> コンテンツを使う + 使用性 + 処理重ね + タイミング <<制約有機能>> 歌うテストベース：機能外要求、記述されている気がかり事項 + 機器組合せ + 周辺機器外部機器互換 + 移植性新採点移植確認 + セキュリティセキュリティ + 通信費通信費確認「＋」項目はパターン以外で追加した品質要素となる実現へシステムテスト V2.0追加機能確認オーナー系機能確認互換性・拡張性確認主要機能（歌う系）主要機能関連操作コンテンツ関連 <<ユーザ接点機能>> 予約をする <<制約有機能>> 演奏をする <<制約有機能>> 楽曲演奏 <<制約有機能>> 映像再生 <<ユーザ接点機能>> 検索をする <<ユーザ接点機能>> 演奏系操作をする <<ユーザ接点機能>> SE操作をする <<ノミナル機能>> 演奏準備をする <<IF接点機能>> 採点をする <<IF接点機能>> 録音、録画をする <<ユーザ接点機能>> 録音・録画系操作をする機能組合せ確認 <<制約有機能>> 歌う <<制約有機能>> コンテンツを使う外部機器互換 <<IF接点機能>> <<ユーザ接点機能>> 開局操作をする <<IF接点機能>> 営業状態判定をする <<制約有機能>> <<IF接点機能>> <<ユーザ接点機能>> 配信をする <<IF接点機能>> プログラムを更新する <<IF接点機能>> 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 本日の対象は以下の範囲とします。「考える・共有するためのモデル」を「使う・作る人」へ向けて紹介します。考える共有する応用する基本的な使い方使う作る
広める ※他人が作ったモデルを使う ※他人が使うモデルを作る ※より汎用的なモデルを拡散する本日の対象範囲

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

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ケースそれぞれ、必要な活動、目的が変わります。発生状況の背景、必要な活動や目的を捉え、自分で「考える」ことによって、役立つモデルを選択し、モデリングしましょう！

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

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 手中の鳥・何を知っているか・誰を知っているか何ができるか
出会う人々との相互作用パートナー知識の獲得新たな手段新たな目的手持ちの手段ではじめる偶然をテコにする・予期せぬ手段生成できる範囲で活動する偶然を受け入れる認知限界を超える

モデリングのそだてかた

モデリングのそだてかた

みずのり

More Decks by みずのり

Other Decks in Business

Featured

Transcript