リバースモデリングという名の深い沼 - WACATE2024夏に参加して思ったこと
WACATE2024夏に参加してきました。参加しての感想、というかリバースモデリングという言葉にまつわる理解を簡単に書いておきます。
WACATEについては前回の2023冬に参加したのが初めてですが、当時はそもそもオフラインのイベント参加自体が初めてで、それなりに緊張していたことを思うと、今回は前日まで存在を忘れていたくらいには余裕があり、この半年で随分こなれを得たなあと感慨深いものがあります。
今回のテーマは「テストケースには、必ず作った人の意図が存在する」で、リバースモデリングがワークショップの題材として扱われました。最近、PFDを勉強して実務で使ってみたりしていることもあって、モデリングに対する興味がにわかに高まっていたところでしたので、とても興味がありました。リバースモデリングそれ自体についても多くは知らないので、面白そうだなあという気持ちでした。
しかし、このリバースモデリングというのがちょっと厄介な概念で、2日間のワークを通して苦労することになりました。これについて、もう少し自分の中で整理しておこうと思います。
リバースモデリングってなんなん？
今回、自分の中で腑に落ちるレベルで整理するのが難しかったのは以下の点です。
リバースモデリングとリバースエンジニアリングの関係は？
リバースモデリングとモデリングの関係は？
あるいは、リバースってなに？
そもそもモデリングってなに……？
WACATEの開催概要でも「今回はリバースモデリングを通して～」と当たり前のようにリバースモデリングという言葉が使われていますが、それほど有名でもなければ、確たる定義のある概念でもないのではないかと思います。
近い言葉でいうと「リバースエンジニアリング」というのがあります。こちらのほうが有名で、具体的にイメージすることも可能です。実際の作業としても似ている気がしますが、何が違うのでしょうか？
そしてモデリングとの関係、つまりリバースと呼ばれるのはどうしてなのか。そもそもモデリング自体何を指す言葉なのか。
全体的な話は、2日目のワーク終了後の招待講演でみずのりさん（水野昇幸氏）がご説明くださいました。
明確な定義があったわけではないものの、様々な具体例を交えながら説明くださったおかげで、自分としてはかなり理解が深まりました（公開スライドでは多くの具体例が削除されているようです）。
現在は以下のように理解しています。
モデリング
具体的な事柄をある構造に着目して抽象的に表現したもの
リバースエンジニアリング
開発工程を遡るように、具体的なアウトプットの分析からその設計や構造などを理解・把握すること
また、それらの理解を元に、改良されたアウトプットを設計・実装すること
リバースモデリング
開発工程を遡るように、具体的なアウトプットの分析からその設計や構造などを理解・把握し、それをもとに改めてモデリングすること
これはあくまで自分の整理であり、定義ではありません。それぞれ用途が広い言葉なので、厳密に表現することは極めて難しいと考えます。
リバースの意味合い
まず「リバースとは何か」ということについては、「正規のプロセスが存在することを前提に、それを遡るような順序で作業を行う」からリバースと呼ぶのだと思います。
つまり、行っていること自体はリバースエンジニアリングであればエンジニアリングを、リバースモデリングであればモデリングを行っているはずです。
リバースエンジニアリングの具体的な事例で、製品の分解をすることがあります。ああいうのをイメージすると「リバースだなぁ」と感じられるわけですが、テストケースのリバースモデリングなんかは、作業だけ見ると普通にモデリングなので、うっかりすると「どこがリバースなの？」と思ってしまいそうになります。
正規のプロセスとの関係の中で「リバース」していることを考えると、「リバース」とは目的の表現と言えるのではないかと思います。
また、2日目ワーク終了後、ブロッコリーさんから「リバースモデリングはアンチパターン」というお話がありました。リバースではない正規プロセスが存在するという意味で、王道に対する邪道、という捉え方もできますから、アンチパターンというのはまさにそうなのだろうと感じました。
リバースエンジニアリングとの関係
そのうえで、リバースエンジニアリングとリバースモデリングの関係についても考えていました。
リバースモデリングは、例えばテストにおけるリバースモデリングであれば、テストケースという具体物の分析からテスト設計を、テスト設計からテスト分析を再度モデリングする行為です。ここでは、モデリングを行うことが含意されています。
対してリバースエンジニアリングは、例えば他社製品を分析し、その設計を学ぶことを指して言いますが、こちらでは設計を再現するなどでモデリングを行うことがスコープに含まれているのかが謎です。
とはいえ、ほとんどの場合は何かしらモデルを作ることになる気がします。その場合は、リバースモデリングはリバースエンジニアリングのいち工程と捉えることができそうです。
しかしであれば、リバースエンジニアリングの一環としてモデリングを行っていると表現すべきであって、別途リバースモデリングと呼ぶのはなんだか不思議な感じがします。エンジニアリングに限らず使える言葉として、考えられているのかもしれません。確かに、デザインの分野でもリバースモデリングという言葉が使われますね。ではテストにおいてリバースモデリングという言葉が採用されたのはなぜなのだろう？ QAエンジニアと呼ばれていますが、やはりエンジニアリングはやってないのだろうか。いろいろと気になってしまう。
まあ実際は、誰かが計画的に名付けたものではないので、深読みしても何も出てこないのではと思われます。実用の中で生まれた言葉は、定義がはっきりしておらず、他の言葉との綺麗な棲み分けが考えられていなかったりします。リバースエンジニアリング、リバースモデリングの関係は、そういう曖昧さによって理解しづらいものになっているのではないかと思います。
ワークをやっての感想
ワークではいくつかの点でつまづいてしまいました。まず「リバースモデリング」の明確な定義がなかったので、何のためにやるのかというのがハッキリとイメージできず、迷いながらワークを進めてしまいました。
「テストの意図を読み取る」というのが目的なのは分かるのですが、その手段としての「リバースモデリング」に対する理解が足らず、手が止まることが多かったです。
例えば、ワークではテストケースをリバースモデリングしてテスト設計の成果物を、その成果物をリバースモデリングしてテスト分析の成果物を作る、という流れで進みました。
これを自分の感覚に自然にやると、テストケースをリバースモデリングしようとてしたとき、そのままテスト分析レベルの成果物でまとめてしまいたくなりました。そうでなくわざわざテスト設計の成果物（つまり状態遷移図やらデシジョンテーブルやら）を作るのは、モデリングのためのモデリングなのでは？ と感じてしまいました。
ワークショップとして丁寧な設計をしていただいていたのだとは思います。つまり深く考えず、テストケースからテスト設計時のモデルを作り、そのモデルからテスト観点のツリーを作り、というようなことをやれたら良かったのだと。そうするだけで、自然とリバースモデリングの工程を踏むことができる設計になっていたのだと思います。それをいろいろ難しく考えやってしまったなぁ……と反省したりしていました。
が、まあ2日間のワークを終えるころには、リバースモデリングの全体像がなんとか掴めている状態になりました。加えて「あくまでアンチパターン」という補足もあり、ワークの内容を腑に落とすことができました。純粋に、モデリングのバリエーションとして、面白かったし経験になりました。テストにおけるモデリングの立ち位置も理解が深まりました。
モデル／モデリングとかいう真の深淵
あとは今回のワークショップとは関係ない内容ですが、モデルとかモデリングとかいう言葉が広い概念すぎて困ってしまいますね。みずのりさんのスライドでも、定義ほど強い意味合いでは仰っておられませんでしたが、モデルに対する「現実そのものではない。そのうえで、役に立つ道具」との解釈をうかがって、初学者からすると扱い切れない広大さにめまいがしました。
そもそも、モデルやモデリングという言葉の使用にはいつも疑念がありました。というのも、モデリングという言葉には、モデルを「使う」とモデルを「作る」という別の行為が混ざって表現されているような気がしたのです。
例えば、様々なテスト技法ではモデルを活用します。状態遷移テストでは状態遷移図を作ります。しかし、テスト技法はモデリングと言えるのでしょうか？ 状態遷移図に「当てはめて」考えているが、それは既存のモデルを使っているだけで、モデルを作っていると言えないのでは？
みずのりさんの講演では、モデリングする人の役割として「使う」「作る」が含められていました。またモデルの分類として「実装有無」を軸に置いていて、実装が無いもの（枠だけ、記法など）と、実装が有るもの（デザインパターンなど）とが、すべてモデルの分類とされていました。ものすごく幅広い考え方ですが、広すぎてちょっと納得いかなさがあります。
しかし、様々なモデリングの具体例を見せてもらったことで、モデリングの「使う」におけるイメージはやや変わりました。むしろ、この「使う」のほうがモデリングなのではないか。逆にみずのりさんの整理とは異なりますが、「作る」はモデリングとは言わないのでは？
例えば先ほどの状態遷移図の例でいえば、「状態遷移図というモデルに当てはめて考えている」ではなく「状態遷移図を描くための記法に則って、状態遷移図を描いている＝モデリングをしている」というのが正確な表現なのではないかと理解しました。つまりモデルと、モデルを作るための記法がひっくるめて「モデル」と呼ばれているが、そこは分けて考えるべきではないか。
しかし、何がややこしいって、記法と記法によって作られたものとが、同じ名前で呼ばれることです。
UMLなどは正式名称が「Unified Modeling Language」であり、Languageを名乗っているということは記法のほうの名前と分かります。いっぽうPFDはProsess Flow Diagramであり、Diagramなので記法というよりは記法によって作られた図を指す言葉に見えます。
そのような違いがありますが、「UML」と「UMLで作られたもの」はどちらも「UML」と呼ばれるし、「PFDの記法」と「PFD」はどちらも「PFD」と呼ばれるわけです。ヘンな話ですよね。
でもまあ、自分の中では整理がついたので、良しとします。
２日間の感想まとめ
そんなわけで、この2日間はずっとモデリングとは何なのか……と考えていました。もっとモデリングを使いこなせるようになりたい！ と思って参加しましたが、こんな原理的なところに自分の頭が捉われてしまうとは思いませんでした。といいつつ、原理でつまづくとそれ以降のことに集中ができないのはそういう性格なので、定めだったのかもしれません。
あとはもっと、他の人の考えや価値観を聞きたかったのですが、ちょっと余裕がありませんでした。2回目参加の謎の責任感もありファシリっぽい立ち回りしてしまったのですが、お題の難しさも相まって、グループワークを回すだけで精一杯になってしまいました。
ファシリをやるのも、ちゃんとファシリやりますって宣言してからやったら良かったですね。その辺あいまいだったので他のメンバーを混乱させたかも。上手い立ち回りがまだまだ出来ません。リバースモデリングよりも人間関係のほうが圧倒的に難しい。やはり人間のほうがマジもんの深淵。
その辺りの埋め合わせとして、打ち上げに参加して参加者の皆さんの話をいろいろ聞かせてもらいました。「成長しました！」という話。「最近悩んでて」という話。普通に地元とかの話。結局、ここで聞く話がいちばん面白いんですよね。たくさんの方と知り合いになれました。とてもハッピーです。
記事もこれで終わりなのですが、2日間で1枚も写真を撮っていないことに今気が付きました。なので貼る写真もないまま、またなんかダラダラまとまりなく書いただけの記事になってしまった。
この記事が気に入ったらサポートをしてみませんか？