第24回redmine.tokyo勉強会の感想 #redmineT

第24回redmine.tokyo勉強会の感想をラフなメモ書き。

【参考】
第24回勉強会 - redmine.tokyo

第24回redmine.tokyo勉強会(2023/6/3) #redmineT - Togetter

【毎月更新】Redmine リリース前の新機能を先行チェック！チケットのフィルタでOR検索ができる「いずれかを含む」など（2023年4月コミット分） | Redmine.JP Blog

【毎月更新】Redmine リリース前の新機能を先行チェック！関連するチケットの番号を複数指定した絞り込みなど（2023年3月コミット分） | Redmine.JP Blog

【毎月更新】Redmine リリース前の新機能を先行チェック！オートウォッチ「自分が作成したチケット」の追加（2023年2月コミット分） | Redmine.JP Blog

【1】@g_maedaさんの講演では、Redmineで未リリースだが取り込まれたパッチの機能改善が紹介された。
興味深い機能は、検索機能の強化だ。

チケットのフィルタでOR検索ができる「いずれかを含む」は、チケット項目だけでなく、フィルタ演算子にも適用できる。
たとえば、添付ファイル名の後ろが .png または .jpg で終わるチケットを抽出とか。
チケット一覧でSQLのように扱うことができるだろう。

また、「現在・過去の値、過去の値、履歴に一度もないの3つで検索する」機能も追加された。
使い方の例として、担当者が自分になったことがないチケット、 担当者が過去に自分だったチケット、Closeしたけど過去に自分が携わったチケット、などがあった。
過去レビューしたチケットを検索したい時に、細かな検索条件を追加することで対応できる。

akipiiさんはTwitterを使っています: 「チケットのJournalテーブルを参照して、現在・過去の値、過去の値、履歴に一度もないの3つで検索する。更新日の検索条件を入れた感じかな。OR検索といい、検索の細かい機能改善をやってますね。 #redmineT」 / Twitter

仕組みとしては、Journalテーブルの更新日を検索している。
よって、過去の履歴をより詳細にフィルタリングできるわけだ。
本来は直接SQLを書ければいいのだろうが、こういう機能改善によって、SQLの検索条件をチケット一覧のUIでカバーできるようになったのはありがたいことだ。

一方、Redmineの右上の検索ボックスの機能と全く同じであるため、チケット数が20万件以上になると性能要件に問題が出てくるだろう。

akipiiさんはTwitterを使っています: 「全検索対象テキストの機能は、性能要件は大丈夫なのかな？　チケットが数万件、数十万件でもレスポンスは問題ない？　インデックスを張ってあるのだろうな。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています: 「#redminet 質問タイムで同じ質問あり。Journalテーブルの件数が多くなると遅くなる。検索ボックスの機能と全く同じなので、検索ボックスのボトルネックを感じるなら同じ現象が起きる、と。」 / Twitter

akipiiさんはTwitterを使っています: 「#redminet 質問タイムで同じ質問あり。full_text_searchの検索結果と検索ボックスの検索結果は異なるケースが発生する。クリアコードさんに機能改善を対応してほしいなあという依頼ありw」 / Twitter

RedmineのデフォルトDBはPostgresSQLなので、パラレルクエリを使って、複数のCPUを活用するクエリプランを生成しクエリの応答をより速くする方法がある。
このチューニング方法を使ってもいいかもしれない。

akipiiさんはTwitterを使っています: 「#redminet Oracleのマテリアライズド・ビューみたいな機能を使ってクエリ検索の性能を上げたいアイデアがありました。PostgresSQLならパラレルクエリの機能があるんですね。なるほど。」 / Twitter

第15章 パラレルクエリ

【2】ChatGPTでRedmineチケットを自動作成する方法を試す事例があった。

akipiiさんはTwitterを使っています: 「Redmineの連携方法をChatGPTに聞いてみた。 #redmineT https://t.co/UzMAAe7dCj」 / Twitter

しかし、チケットの内容が微妙で思ったような内容でないらしい。
プロンプトエンジニアリングとか色々テクニックが必要な気がした。

akipiiさんはTwitterを使っています: 「#redminet Redmineチケット作成にも、プロンプトエンジニアリングが必要なのかもしれませんね。」 / Twitter

ボウコバさんはTwitterを使っています: 「@akipii ChatGPTは、知らないことは適当な情報で埋める傾向があるので、知らないことは勝手に決定せず、自分に質問しろと指示する案も出ていますね。」 / Twitter

akipiiさんはTwitterを使っています: 「@bowkoba なるほど、機械の中身は統計処理の推測ですからね。どういう立場で情報がほしいとか、前提条件や制約条件をかなり追加する必要がありそう。」 / Twitter

しかし、ポテンシャルはあるから、ChatGPTで、埋もれたナレッジを再活用するとか、バグチケットに類似バグ調査、過去の類似チケット検索とか、AIで補完してほしいと思う。

akipiiさんはTwitterを使っています: 「Bingに同じことを聞いてみた。埋もれたナレッジを再活用するとか、まだマシかな？？ #redminet https://t.co/HKtFgxwrjG」 / Twitter

【3】川端さんから、逆引きでわかる！ Redmineハンドブック バージョン5.0対応の紹介。
今までの、いかにも土壇場で作ってきました講演と異なり、Redmineの事例紹介の内容がかなり詳しかった。
たぶん、7千社近い顧客企業の事例を持っているので、Redmineのチケット管理でタスク管理するにはどういう使い方がその企業に向いているのか、かなりノウハウが溜まっているのだろうと感じた。

(1) りょうまさんはTwitterを使っています: 「川端さんが真面目な話してるの、超久々に聞くんだが #redmineT」 / Twitter

Redmineのチケット管理でハマりやすい問題は、いくつかある。
1つ目は、ワークフローの複雑さと親子チケットの階層の深さのトレードオフだ。
講演では、レビュー中というステータスを外し、ワークフローを単純化して親子チケットで対応する方法が紹介されていた。
この手法は、トラッカーの種類を減らし、ワークフローを短縮化する一方、親子チケットの階層を深くしてでも対応することに相当する。
プログラマやガントチャート好きなマネージャはツリー構造に慣れているので、このやり方が向いているかもしれない。

2つ目は、PJで現れる工程やフェーズはRedmineバージョンで使うか、親子チケットで対応するか、というトレードオフだ。
一般に、WF型開発では、Redmineバージョンを要件定義、設計、開発、テストのように割り当てる時が多い。
しかし、このやり方では、システムとしてリリースできるタイミングはPJの最後の1点だけになり、リスクが大きすぎる。

講演では、バージョンを使わず、親子チケットのうち子チケットでフェーズ分けする手法が紹介されていた。
つまり、親チケットは実装する機能とし、子チケットで要件定義・設計・開発・テストごとに作成して、親チケットでタスク全体を管理する。
このやり方であれば、親チケットをどのイテレーションでリリースするか、だけ決めるだけでいい。
WF型開発であっても、小規模な改善が多い案件、保守案件ではこのやり方の方がアジャイル開発に似ているので運用しやすいだろう。

【4】中村さんの講演では、Redmineを外部記憶装置として扱い、少ない脳内メモリを有効活用しようという話だった。
GTDにある「頭の中で動く猿を追い出す」ことと同じだなと思う。

(1) アカベコさんはTwitterを使っています: 「チケットや Wiki などを外部記憶装置と認識、よくわかる。外部記憶、かつ長期記憶で起票とかメモすることで短期記憶のスタックを明け渡すようにしてる #redmineT」 / Twitter

【5】@yukiaさんの講演では、チケット管理ツールを個人向け、チーム向け、組織向けの3階層で分類していた。
個人＜チーム＜組織の順に、統制や標準化という押しつけが大きくなるイメージだろう。

中村さんの話でも、チケットに記載しない内容として、個人タスク、案件化していない情報などがあった。
だから、GoogleKeep＋Redmineを使っているとのこと。
確かに、GoogleKeppならメモやちょっとした履歴にも使える。
つまり、個人のタスク管理、メモ管理としてRedmineを利用する方法は実はあまり議論されておらず、今後、もっと試してみる価値はあるだろう。
僕の直感では、GTDのようなワークフローやUIをRedmineで実装できるかどうか、が鍵を握ると感じる。

(1) akipiiさんはTwitterを使っています: 「タスク管理ツールは3種類ある #redmineT https://t.co/IIOkSESd5Y」 / Twitter

(1) akipiiさんはTwitterを使っています: 「チームのためのツールは課題管理がメイン #redmineT https://t.co/WeJGHxZEAD」 / Twitter

(1) akipiiさんはTwitterを使っています: 「組織のツールはワークフローで統制できること #redmineT https://t.co/bX9m8iwioG」 / Twitter

【6】@ryouma_nagareさんが紹介してくれたpython-redmineは試したみたいと思う。
REST APIはありがたい機能なのだが、チケット全件を取ろうとすると100件という制限があったりして割と面倒。
もっと手軽にデータを扱いたいから。

maxtepkeev/python-redmine: Python Redmine is a library for communicating with a Redmine project management application

【7】@MadoWindaheadさんから、チケット管理システム有識者の集いを開催したい、という要望があった。
チケット管理ツールの同盟を組んで、想いを実現したい、と。

(1) akipiiさんはTwitterを使っています: 「プロダクトマネジメントはプロジェクトマネジメントと確かに違うね。アジャイル開発やSaaSで多いかな #redmineT https://t.co/XSlKg04ykI」 / Twitter

(1) akipiiさんはTwitterを使っています: 「PJ管理ツールと同盟を組んだ #redminet https://t.co/OY0bUqbf3Q」 / Twitter

(1) akipiiさんはTwitterを使っています: 「チケット管理ツールの同盟を組んで、想いを実現したい #redmineT https://t.co/e9sCIQZWCt」 / Twitter

今は色んなチケット管理ツールが有償・無償であり、それらの機能を比較して考えていくと、ああそういう使い方がしたかったのか、そんな利用シーンがあったのか、と気づく時がある。
プロジェクト管理の手法はまだまだ枯れておらず、色んなやり方を試せると思う。

統計学の考え方をastahでまとめた

統計学の考え方を自分なりにastahでまとめた。
初心者のラフなメモ書き。

【参考】
計量経済学における統計上の根本問題: プログラマの思索

「推計学のすすめ」「経済数学の直観的方法～確率統計編」の感想: プログラマの思索

データ分析の課題はどこにあるのか: プログラマの思索

データ分析の面白さはどこにあるのか: プログラマの思索

経済学や心理学の実験で得られた理論は再現性があるのか？～内的妥当性と外的妥当性の問題点がある: プログラマの思索

経済学は信頼性革命や構造推定により大きく変貌している: プログラマの思索

統計学の考え方に関する感想: プログラマの思索

ランダム化比較試験はなぜ注目されて利用されるようになったのか: プログラマの思索

【1】統計学はいつも習得したいと思うのに、習得にすごく時間がかかる気がするのはなぜだろうか？
その理由は、統計学の考え方は独特な世界観があるからではないかと思う。

なぜ正規分布がそんなに重要なのか？
なぜならば、世界の物事のばらつきは最終的に正規分布に収まるから。
だから、観測や測定でデータを採取したら、まず正規分布を書いて、測定値がどこにプロットされるかイメージたらいい。

最小二乗法の基本思想は何か？
観測や調査で得られた測定値の誤差は正規分布に従う。
ゆえに、測定値のデータの背後にある正規分布の中心線を予測すること。
ガウスが誤差論から生み出した。

統計的仮説検定とは結局何なのか？
そのロジックは確率的な背理法。
だから、ややこしく感じる。

従来の数学や物理の理論や哲学と、昨今のビッグデータやAIなどの違いは何なのか？
従来の理論は演繹的にトップダウンで、世界を説明しようとする。
一方、昨今では、統計理論と強力なコンピューティングパワーで、ビジネスの副産物で得られた大量データを元に因果関係まで帰納的に推測してしまう。

【2】推測統計学の考え方

統計学の攻略_推測統計学の考え方.pdf from akipii Oga

母集団のデータを全て調査できればよいが、実際はその中の一部のサンプルしか集められない場合が多い。
調査には時間もコストも掛かるから。

では、集めた測定値から母集団はどのような構造になるのか？
大数の定理より、サンプルから推測される母集団の背後にある正規分布を予測する。
そのためにt検定など色んなツールがある。

サンプルデータの抽出方法が上手くないと母集団のデータ構造を推測しにくい。
複数の標本を独立に選ぶことが大事。
つまり、マーケティングのセグメンテーションと同じ考え方。

母集団の平均・分散を既に知っているか、全く知らないか、で推測方法が変わってくる
母集団の平均・分散を既に知っていれば、推測する正規分布の精度は高くなるだろう。
しかし、一般には母集団の平均・分散は全く知らない場合が多いので、推測してもその分誤差は出る。

母集団が1個なのか、2つなのか、で推測方法が変わってくる。
母集団が１つなら、母集団の構造を知ることが重要。
測定したサンプルは母集団のどこにプロットされるのか、が重要なテーマになるだろう。
つまり、内的妥当性の問題になるだろう。

一方、母集団が２つなら、2つの母集団を比べて、優劣や評価を比較することになるだろう。
たとえば、補助金を与えた集団と、補助金なしの集団ではどんな行動の差があるのか、とか。
すると、その行動の差から得られた知見は、その他の母集団に適用できるか、という問題に発展するだろう。
たとえば、米国で得られた統計結果は、日本でも当てはまるのか？とか。
つまり、外的妥当性の問題になるだろう。

【3】正規分布ファミリーの全体像

統計学の攻略_正規分布ファミリーの全体像.pdf from akipii Oga

正規分布には色んな種類がある。
Z分布、t分布、F分布、χ2乗分布とか。

これらの分布は、母集団の平均値や標準偏差を知っているかどうかで変わってくる。

【4】統計的仮説検定の9パターン

統計的仮説検定が理解しにくいと思う理由は、2つあると思う。
1つは、仮説的統計検定の基本思想が確率的背理法であること。
背理法の考え方でつまずきやすいのではないか。

もう一つは、推測したい母集団の平均値や標準偏差が既知なのか未知なのか、で手法が変わってくること。
たくさんの検定手法があって名前から手法の中身を推測しにくい。
前提条件をIF文で分岐処理して検定手法が確定するので、そのパターンをイメージしておかないといけない。

【5】統計検定2級は6年前に取得した。
その時に上記の考え方を自分のastahの中で色々書き込んでいた。
その時のメモを残しておいた。

これらをベースに機械学習がある。
分類（classification）、回帰（regression）、クラスタリング（clustering）、次元圧縮（dimensionality reduction）とか。
PythonのScikit-Learn のチートシートも公開されているので、またまとめておく。

Pandas Cheat Sheetのリンク: プログラマの思索

scikit-learn「アルゴリズム・チートシート」のリンク: プログラマの思索

JSTQBのテストプロセスの概念モデルを描いてみた

JSTQB Fondation試験を勉強した時に、JSTQBのテストプロセスの概念モデルを描いてみた。
気づきを書き残す。
まだ理解があやふやなので、間違えていたら後で直す。

【参考】
テストアイテムとは何か？概要や定義、現場での使われ方について解説

JSTQB_テストマネジメントとレビュープロセス.pdf from akipii Oga

JSTQB_テストプロセスの概念モデル.pdf from akipii Oga

【1】JSTQBのテストの専門用語は、普段使っている言葉と意味が違っていたり、別の言葉で置き換えられる時があると分かった。
たとえば、テストレベルはテスト工程のテストプロセス、テストタイプはテストの種類に相当するだろう。

テストオラクル、テストベースなどはJSTQBで初めて知った。
たぶん、テストケースの発生源や出処となる概念を明確に区別すべきという考え方があるのではないか。

テストオラクルの用語定義: プログラマの思索

また、テストプロセスの概念モデルを描いてみて気づいたのは、JSTQBにたくさん出てくるテストの専門用語は、テスト管理ツールやテスト支援ツール、テスト自動化ツールなどのツールで使う場面をかなり意識しているのではないか、と直感している。

たとえば、テストスイートは、一般にテスト自動化ツールに読み込ませるテストケースやテストデータをイメージできる。
テストハーネスはドライバやスタブみたいなものだし、テスト環境そのものも今ならDockerで最初から環境構築を自動化できる。

【2】エラー(誤り) error、欠陥 defect、故障 failureは明確に区別される。

エラー・欠陥・故障の用語定義: プログラマの思索

一般に不具合と言われる事象は故障に相当するだろう。
不具合をバグ、障害と断定しない理由は、実際に調査してみたら、仕様通りで問題ないとか、テスト手順ミスやテスト環境の不備が原因だった、という場合があるからだろう。
不具合は、故障、不正の事象も包み込む曖昧な現象を指す場合が多いと思う。

欠陥があったからといって、故障が発生するわけではない。
欠陥のあるプログラムが実行されて初めて故障が発生する。
欠陥がプログラムに埋め込まれても、テストで発覚せず、運用していても発生しなければ、システムは問題なく動く。
しかし、欠陥そのものは存在しているわけだから、いつかは故障として発生する。
いわゆる潜在バグに相当するのだろう。

欠陥の根本原因の分析はなぜなぜ分析がよく使われるだろう。
しかし、なぜなぜ分析を現場で実際に使ってみると、なかなか効果を出すのが難しい。
メンバの力量にかなり依存するので、原因があらぬ方向に行ってしまいがち。

【3】JSTQBでは、テストチームの役割には、テストマネージャとテスト担当者の2つが少なくとも定義されている。
テストマネージャはテスト計画フェーズで中心的役割を果たす。
テスト実行フェーズ以後の具体的な作業はテスト担当者に任せるようだ。
つまり、テストマネージャはプロジェクトマネージャやストラテジストに近いイメージを持った。

JSTQBのAdvancedLevelはテストマネージャ試験がある。
ただし、業務経験が必須らしい。

【4】テスト管理や品質管理については、TestLinkを試していた頃に随分色々考えていた。

TestLink: プログラマの思索

プログラミングやシステム設計とは異なる考え方を知ったり、試したりするのが面白かった。
残念なのは、テスト管理ツールはほとんどが有償であり、OSSのTestLinkしか試せなかったことだった。

テスト管理ツールTestRail、CAT、QualityForwardの感想: プログラマの思索

テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク: プログラマの思索

今持っている問題意識は、2023年の現在、ソフトウェアテストを支援するテストツールはどんな方向に進化しようとしているのか、ということ。
上記の記事にも書いたが、日本のIT企業やユーザ企業が考える品質と、欧米企業が考える品質は異なる。
日本人は機能の細かい品質までこだわるが、現代はアジャイル開発が普及して一般的になっていて、その考え方が時代に合わない部分もある。
アジャイル開発に適した品質とは何なのか？
そして、AIなどを使ってもっとテストそのものを進化させることはできるのか？

この辺りは色々考えてみたいと思っている。

第85回IT勉強宴会の感想～概念データモデルからビジネスモデルを構築すべきという考え方

土曜に開かれた第85回IT勉強宴会で、真野さんがデータモデリングの観点でエンタープライズシステム設計を講演されたのでオンラインで聞いた。
講演内容を知った前提で、感想をラフなメモ書き。

【参考】
概念モデルの効用を知ろう - connpass

概念モデルの効用を知ろう(第88回IT勉強宴会inZOOM/大阪サテライト) | ＩＴ勉強宴会blog

第39回IT勉強宴会の感想～花束を作る花屋の業務モデルをT字形ERと三要素分析法で比較する: プログラマの思索

第62回IT勉強宴会のメモ～２人の方法論者によるデータモデリング激レア対談: プログラマの思索

「データモデリング入門－astah*を使って、TMの手法を使う－」はとても良いモデリング資料: プログラマの思索

業務ロジックをデータモデリングはどこまで表現できるか？: プログラマの思索

リソース数がビジネスの可能性に関係する理由: プログラマの思索

【1】講演のメッセージは、DXで新規ビジネスを創出したいなら、概念データモデルを描くことから出発しよう、ということ。

メッセージの背景にある課題は、昨今、IOTやSaaSなどのSoE、既存の業務システムのSoRなど色んなところから数多くのデータがビジネスの副産物として簡単に入手して蓄積できるようになった
そのデータをAIや機械学習に食わせて分析するようにしたい。
しかし、色んな入り口から源泉データが発生し、途中で加工されて雪だるま式に派生データが積み重なり、複雑なトランザクションデータになっている。
そのためにそのデータを利活用しようとすると、派生データを取り除き、源泉データを区別して本来のデータを抽出する仕組みが必要だ、という問題意識。

akipiiさんはTwitterを使っています: 「我々が扱おうとしているのは、大半が加工・集約された派生データである。データがどこで加工されたのか、出処はどこなのかを探ることが重要。源泉データを突き止めるためにデータの系統図、データの変遷をたどるのが必要。イベントを時系列に並べてリソースを抽出する、ということかな？ #benkyoenkai」 / Twitter

そこで、SoE領域、SoR領域などの源泉データからどのように加工されてデータ連携基盤ハブにたどり着くのか、をデータモデルの観点から整理分類し、データクレンジングしたきれいなデータをデータ活用基盤へ連携してAIや機械学習に使ってもらうという仕組みにする。

akipiiさんはTwitterを使っています: 「源泉データがレガシーなSoRだったり、SaaSのSoEだったり、データレイクからだったり色々ある。そういう風にデータが時系列で加工されていく過程が見える。 #benkyoenkai」 / Twitter

講演では、製造業のサプライチェーン全てをデータモデル化し、コスト最適化の観点でシミュレーションとして使う事例が紹介されていた。

akipiiさんはTwitterを使っています: 「取引先や原材料、中間加工品の調達関係を描いたデータモデルが必要となる。制約条件は、取引先や原材料、中間加工品の調達関係を描いたデータモデルが必要となること。事業部間のデータ統合ができていることが前提。プロセスの再現だけではデジタルツインは実現できない。 #benkyoenkai」 / Twitter

akipiiさんはTwitterを使っています: 「デジタルツインでは、データ連携基盤Hubが重要。SoRが源泉データ。SoRからデータ連携基盤Hubを経てデータ活用基盤へデータが流れることになる。 #benkyoenkai」 / Twitter

僕の感覚では、雪だるま式に加工されて複雑化したトランザクションデータを時系列に並べて、マスタ（リソース）をトランザクション（イベント）と区別して抽出し、イベントやリソースをそれぞれ管理する仕組みを作る、というように捉えた。
実際の分析手法では、データモデルの正規化も使うし、クラスとインスタンスを区別することでクラスを抽出しロールとしてポリモルフィックに振る舞わせるように整理する。

講演では、顧客というクラスは、顧客、消費者、代理店、法人客というロールがある例が紹介されていた。

akipiiさんはTwitterを使っています: 「データモデリングは分類学である、とデータ総研の方は言っておられた、と。顧客、消費者、代理店、法人客などのロールを分類して、特化・汎化のER図で描く。IDEF1Xなのでオブジェクト指向設計と同じ。パーティモデルの概念と同じ。 #benkyoenkai」 / Twitter

【2】データモデルを作る目的は3つ。

akipiiさんはTwitterを使っています: 「データモデルを作る目的。3つある。ビジネス構成要素や業務ルールを把握する。保有するデータをAI機械学習の入力源にする。新規ITシステム構築に活用する。 #benkyoenkai」 / Twitter

【3】概念データモデルを描くメリットは何か？
メリットは2つある。

1つ目は、ビジネス構成要素を資源（リソース）と活動（イベント）の2種類に整理統合することによって、今後新たなビジネスモデルを生み出す材料として扱えること。

akipiiさんはTwitterを使っています: 「ビジネスの構成要素は資源（リソース）と活動（イベント）からなる。リソースは普通のマスタ、イベントは普通のトランザクションとみなせるね。羽生さんの本ではイベントに注目するとデータモデルを作りやすいと言っていたなあ。時系列に並べれば自然にDFDみたいなER図が描けるから #benkyoenkai」 / Twitter

データモデルのエンティティをイベントとリソースの2種類に整理するアイデアは、T字型ER（旧）や羽生さんのデータモデリング手法でも出てくる。
羽生さん本では、イベントは必ず日付があること、そこからイベントとリソースを区別しましょう、と言っていた。

「データモデリング入門－astah*を使って、TMの手法を使う－」はとても良いモデリング資料: プログラマの思索

業務ロジックをデータモデリングはどこまで表現できるか？: プログラマの思索

ここで、イベントの数とリソースの数を数えて、もしイベントの数がリソースよりも少ないならば、リソースを組み合わせて新たなイベント（トランザクション）を生み出すことで、新たなビジネスモデルを考える切っ掛けの一つになりうる。

リソース数がビジネスの可能性に関係する理由: プログラマの思索

第39回IT勉強宴会の感想～花束を作る花屋の業務モデルをT字形ERと三要素分析法で比較する: プログラマの思索
（引用開始）
リソースの数よりもイベントの数が少ない場合、リソースの組合せで発生する可能性のある対照表というイベントは、その会社の業務として存在していない事実がある。
すなわち、新しい業務を生成することで、新規ビジネスを作り出す根拠になりうる。
（引用修了）

2つ目は、講演では、プロセス指向設計で使われる業務フロー図では、既存の業務フローで業務を入れ替え・削除したり、担当組織を入れ替える程度であって、BPRや業務改善しかできない。
DXで本来やりたい新規ビジネスモデルを生み出すことは、業務フロー図からでは発想できない弱点がある。

akipiiさんはTwitterを使っています: 「データモデルの活用例の１つはDXへの適用。経営者、業務部門、IT部門のコミュニケーションツールとして使う。ビジネス創出のためには業務フローアプローチではBPRや業務改善に留まり、新規ビジネス抽出につながらない。順序入れ替え、組織分担変更のレベルにすぎない #benkyoenkai」 / Twitter

akipiiさんはTwitterを使っています: 「都度受注モデルからサブリスクプション契約モデルへビジネスを変更する。エンティティの置き換えだけでなく、新規イベント、新規リソースの追加が必要になることが明確に分かる。すると、新規イベント、新規リソースを保守管理する組織も必要になるだろう。 #benkyoenkai」 / Twitter

概念データモデルでAsIsモデルを描き、そこからエンティティを出し入れすることで、新規ビジネスモデルを生み出せるはず、と講演では説明されていた。

この部分については、なるほどと納得できる部分もあるが、本当にそうなのかという疑問も生じる。
確かに、講演で例に出た、AsIsの受注契約モデルとToBeのサブスクリプション契約モデルでは、業務フロー図でAsIsからToBeは出てこないだろう。
なぜなら、サブスクリプション契約モデルは誰も知らない初めてのビジネスモデルなので、業務フローをそもそも描くことすら難しい。
どんな業務が必要で、どの組織が業務のどのプロセスを担当して回すのか、そういう具体的な細かい粒度まで落とし込むのは至難の業だ。

しかし、AsIsの受注契約モデルとToBeのサブスクリプション契約モデルでは、概念データモデルを描いてみると構造はかなり違う。
契約エンティティなどの一部のエンティティは同じだが、AsIsモデルでリレーションシップや新たなエンティティをちょっとだけECRSでいじればToBeが出てくる、というのはちょっと無理があると思う。
実際、QAタイムでは、既存のAsIsモデルの概念データモデルでエンティティをECRSで出し入れする程度でToBeモデルが作れるのか、という質問もあった。

概念データモデルで新規ビジネスモデルを描く重要性は理解できるが、具体的なデータモデルを整合性が取れるように生み出すことは、別次元の作業なのだろうと思う。

【4】概念データモデルとオブジェクト指向設計、ドメイン駆動設計の違いは何なのか？

講演で紹介された概念データモデルはIDEF1Xで描かれていた。

ER図 (Entity-relatonship Diagram) | astah* 機能ガイド

IDEF1Xのエンティティ同士の関連線はクラス図と異なるが、多重度を書いたりロールを書いたりするのでクラス図に似ている。
オブジェクト指向設計やドメイン駆動設計が好きな人は、たぶん違和感なくIDEF1Xの概念データモデルを理解できるだろうと思う。

akipiiさんはTwitterを使っています: 「受注出荷のデータモデルをIDEF1XのER図、DFDで描かれた事例。クラス図に読み替えやすい。 #benkyoenkai」 / Twitter

akipiiさんはTwitterを使っています: 「受注出荷モデルの例。受注と出荷の関係が1対1、1対多では何が違うか？受注単位の出荷、一括受注して分割出荷。IDEF1XのER図はクラス図に似てるのでドメイン駆動設計が好きな人は読みやすいと思う　 #benkyoenkai」 / Twitter

akipiiさんはTwitterを使っています: 「抽象化したエンティティはロール概念を用いて関連付けることができる。真野さんが説明されるデータモデルはクラス図にそのまま置き換えられるね。 #benkyoenkai」 / Twitter

データモデリングがなかなか普及しない原因の一つは、ドメイン駆動設計が好きな人はデータモデルを読み解きにくい現象が多いのではないか、と推測するので、この辺りは1つのきっかけになるかもしれない。

【4】渡辺さん式データモデルと真野さんの講演で出てくる概念データモデルの違いは何なのか？

真野さんの講演で出てくるデータモデルは概念モデルレベルなので、エンティティ名しか書かれていない例が多い。
一方、渡辺さん式データモデルは、すべての属性を書き出し、関係従属性の意図まで明確に表していて、実際のデータの例も書いているので、より具体的だ。
実装モデルそのものと言っていい。

だから、渡辺さん式データモデルではテーブル仕様書をそのまま出力できるレベルであり、Railsのようなフレームワークを使えばすぐにCRUD画面も作れる。
つまり、どんな画面や帳票が必要で、どんな業務や画面操作でデータが生成されて更新されていくか、というレベルまで全て把握できている。
だから、ローコード開発やノーコード開発と相性がいい。
たぶん、SalesforceやKintoneのようなローコード開発ツールと相性が良いと思う。

akipiiさんはTwitterを使っています: 「真野さんのデータモデルはIDEF1Xで描かれてるので、渡辺さんのER図とは見た目は違う。個人的には、渡辺さんは関係従属性の意図まで明確にしインスタンスも例示するので、より実装モデルに近いと思う。だからローコード開発と相性がいい。 #benkyoenkai」 / Twitter

しかし、関数従属性やキーの種類の理解が深くないと、データモデルを読み解くのは難しいと思う。

再入門：「正規化崩し」としてのサロゲートキー - connpass

（引用開始）
・候補キー(candidate key)：レコードを一意に特定するキー。１テーブルに複数存在することがある
・主キー(primary key)：代表として定めた候補キー。項目値の変更は許されない
・単独主キー(single primary key)：１項目で出来ている主キー
・複合主キー(composite primary key)：２つ以上の項目で出来ている主キー
・自然キー(natural key)：業務上意識されている候補キー。単独主キーか複合主キーかは問わない
・サロゲートキー(surrogate key)：業務上意識されていない単独主キー。代理キーともいう
（引用修了）

サロゲート単独主キー vs 複合主キーの話、予習編 - たなかこういちの開発ノート

アーキテクトは、データモデルから業務フロー図、画面帳票、組織構成までイメージできる能力を求められる。
たとえば、渡辺さんの本を読めば、ほとんどデータモデルばかりでDFDは少しだけしか紹介されていないので、実際にどんな業務フローが必要になってくるのか、は自力で考えなければならない。
渡辺さんの本に出てくるデータモデルでは、複合主キーや外部キー、特に2次識別子（Alternative Key）が巧妙に使われていて、業務ルールや制約条件を表しているので、注意深く読まなければ割と読み落としやすい。

【5】概念データモデルはどの工程で使われて、どんな役割の人が担当すべきなのか？

講演では明示的な説明がなかったように思うが、常識で考えると、企画フェーズや要件定義で概念データモデルが作られる。
担当者はアーキテクトのレベルの人になるだろう。

作られた概念データモデルの粒度は、講演で紹介された粒度ならば、エンティティ名だけでかなり曖昧。
渡辺さん式データモデルの粒度なら、論理モデルまで落とし込む必要がある。
その場合、そこからすぐに実装モデルに置き換えられるから、ローコード開発ツールを使うことを前提にしているだろう

最近はデータモデリングから離れていたので、講演を聞いてすごくワクワクしながら聞いていた。
改めて、データモデリングのテクニックを自分なりに整理してみたいと思う。

テストオラクルの用語定義

テストオラクルが分かっていなかったのでメモ。
Oracleがなぜこんなところで出てくる？と勘違いしていた。

【参考】
テストオラクル（てすとおらくる）：情報システム用語事典 - ITmedia エンタープライズ

JSTQB-ALのお勉強(2周目) ─ 2.1～2.4 - ソフトウェアの品質を学びまくる2.0

テストオラクルとは何か - ソフトウェアの品質を学びまくる2.0

テストオラクルとは何か？概要や対象物について解説

test oracle - ISTQB Glossary

A source to determine an expected result to compare with the actual result of the system under test.

テストオラクルとは「ソフトウェアテストの正しさや妥当さを判断する根拠となるもののこと。テストケースやテスト項目、あるいはその出処をいう。」
下記の例がわかりやすい。

(引用開始)
テストオラクルになる情報元
「記載例の通り、入力値の積を出力する。例：1*1=1、1*2=2、1*3=3 … 9*9=81」

テストオラクルにならない情報元
「入力値の積を出力する。」
(引用修了)

テストオラクルという概念が必要になってくるケースは、テスト設計ツールやテスト管理ツールだろう。
テスト設計ツールに投入するテストケースの発生源がテストオラクルになる。

たとえば、テスト設計ツールに投入するテストケースは、仕様書や業務マニュアル、ドメイン知識を元に具体的に作られる。
あるいは、「回帰テストの“前回は通った”ことを保証するテストスイートはテストオラクルといえる」だろう。

特に、ツールを使ってテストケースを再利用したい場合にテストオラクルという概念が必要になってくるのではないか。
なぜなら、ツールに投入されたテストケースを管理していくと、発生源となる仕様や要件がわからなくなる場合があるからだろう。

すると、テストオラクルという概念は、テストケースと要件をリンクさせるトレーサビリティの役割を担っているとも言えるのではないか。
TestLinkでも要件カバレッジの機能があったので、最終的には、テスト管理ツールの中に要件管理機能も含まれて、テストケースと要件のトレーサビリティを実現するような機能が埋め込まれることになるのだろうと想像した。