モデリング

2019/06/27

RedmineのUserPrefernceにはシリアライズしたデータを格納している

RedmineのUserPrefernceにはシリアライズしたデータを格納している記事があったので、メモ。
以下、脈絡のないポエム。

【参考】
あらためて感心したRedmineのデータ利用方法(UserPrefernce 編) - ファーエンドテクノロジー株式会社

【1】UserPreferenceには、マイページに表示したいブロックの情報がハッシュ化されてシリアライズされてテキスト文字列で登録されている。
この実装のおかげで、ログインIDに紐づく情報はシリアライズされたデータに含めることができる。

例えば、直近の機能改善「プロジェクトセレクタにブックマークと最近使用したプロジェクトを表示」には、この実装を使っているらしい。
なるほど、この実装のおかげで、プロジェクトのプルダウンが非常に使いやすくなった。

Patch #31355: Bookmarks and recently used projects for the project jump box - Redmine

「Redmine 4.1 新機能選抜総選挙」で紹介できなかった新機能 10選 - ファーエンドテクノロジー株式会社

【2】データモデリングにこだわっていると、正規化されていないデータで設計しているように思えてしまうが、プログラムの観点では、集約(Aggregate)されたオブジェクトで格納されている方がはるかに扱いやすい。
一つの情報の中に芋づる式にすべての情報にアクセスできるからだ。

一方、T字型ERでは、「エンティティが他のエンティティとの関係を内部に取り込んでいることを「純度の低下」と考えている」という立場もあるらしい。
つまり、こういう情報は別テーブルで保持すべき、という考えになる。

「ドメイン駆動設計」感想(1) - なぜファットモデルになるのか - 極北データモデリング

たぶん、この観点の対立は一昔前に流行したORインピーダンスマッチの問題点に行き着くのだろう。
昨今の流れでは、データ永続化の手段はRDBだけとは限らないので、状況に合った利用方法が勧められるだろう。

O/Rマッパーが悪いのはオブジェクト永続化にRDBを使おうとしたことが悪い | Qrunch(クランチ)

【3】上記の記事で興味を引いたのは、UserPreference と同等の機能を持つProjectPreference のようなモデルが作られれば、Redmineのあらゆる機能をプロジェクト単位で制御できるのではないか、という指摘だ。

(引用開始)
個人的には Redmine.org - Feature #4016: Make app settings overridable at project level で UserPreference と同等の機能を持つ(ProjectPreference のような)モデルが組み込まれればプロジェクトごとの設定項目を拡張することも容易になる (画面テーマなどもプロジェクト単位で設定が可能になる)はずです。これによりRedmineはさらに使い勝手が良くなると思います。
(引用終了)

Feature #4015: Make app settings overridable at project level - Redmine

以前から、Redmineの管理画面をユーザ権限やプロジェクト単位で制御したい、という話があった。
その時に、ProjectPreferenceに似たオブジェクトがあれば、機能改善の実現のハードルがすごく下がるかもしれない。

Redmineのワークフロー設定を拡張する機能提案~Redmineは汎用的なBPMツールになりうるか: プログラマの思索

この辺りも色々考えてみる。

【追記】
りょうま@夏競馬行きたいさんのツイート: "DBにJSON型がない時代にはグループウェアのカスタマイズなど、追加テーブルを作りたくない場合にシリアライズして予備カラムに投入というのはよくやってました。… "


| | コメント (0)

2019/04/22

IT企業が経済学者を雇い始めた理由が面白い

最近、IT企業が経済学者を雇い始めた理由を解説する記事をちらほら見かける。
記事が面白いのでリンクしておく。
以下は、自分の理解のラフなメモ書き。
間違っていたら後で直す。

【参考】
IT企業はなぜ経済学者を積極的に雇い始めたのか | HBR.ORG翻訳マネジメント記事|DIAMOND ハーバード・ビジネス・レビュー

米アマゾンらが経済学者を雇う理由~デジタル経済学者のシェアエコ化(石角 友愛) | マネー現代 | 講談社(1/3)

IT企業による経済学の活用 : 遠い呼び声の彼方へ!

(引用開始)
第一に、最先端の経済学の理論は、IT企業が必要とするサービスの要素技術になり得るからです。
例えば、日経ビジネスに掲載されたハル・ヴァリアン教授のインタビューによれば、ヴァリアン教授が主導し、広告オークションの設計にオークション理論を取り入れ、AdWordsの設計を行ったそうです。
(中略)
第二に、最先端の経済学者はIT業界が必要とする統計のエキスパートであるという点です。
最先端の研究では、経済学者は統計理論を活用し、事象をモデル化することが要求されます。
結果、経済学者は統計によるデータ処理のエキスパートとなっています。
一方でIT業界も、データを活用するためのは統計処理が不可欠です。そしてビッグデータの時代になるほど、高度な統計処理が要求されます。
結果、ITサービスの開発やグロースに必要なデータ処理やそのモデル化に、統計学者の知見が活かされているのです。
(引用終了)

【1】昨今のAIや機械学習の隆盛を見ると、心理学や経済学のような文系の学問とIT技術の組合せが非常に相性がいいのだろう、と感じる。
その理由は2つある。

【2】一つは、心理学や経済学が過去数百年に渡って蓄積してきた理論や知見は、「市場や社会集団に対し、どのような社会制度や経済政策を整備すれば、人にインセンティブで動機づけさせて、あるべき正しい方向に人の行動を律することができるか」という問題をずっと考えてきたからだ。

その手法は、政治、経済の分野だけでなく、ショッピングサイトやオークションサイト、Uberやエアーアンドビーなどのマッチングサイト、などの多数のWebシステムに簡単に適用できる。
特に、マッチングサイトでは、情報やサービスを提供する生産者とそれを購入する消費者の間で、お互いに最大の利益を得るようなマッチングを計算する必要があるが、まさにそのアルゴリズムは、どのような仕組みをWebサイトに導入すれば取引が全体最適化されるか、という問題に置き換えられるからだ。

あるいは、SNSや広告エンジンのマーケティングでは、どのようなターゲット層にどんな広告内容を表示すればマーケティング効果が得られるか、という問題に対し、心理学の知見を活かすことで、ターゲット層に具体的なペルソナを作り出して、ABテストでマーケティング手法を実験する、ということも簡単に実行できるからだ。

つまり、既存のIT技術を使った結果に、心理学や経済学の過去の知見を適用すれば、そのデータに価値観を与えることができる。

まあ、振り返ってみれば、経済学はマンキューによれば「インセンティブの学問」でもあるし、一方、心理学も人間の性格に関する理論を数多く生み出してきたので、その内容を昨今のWebシステムに適用できるのは当たり前ではある。

【3】もう一つは、心理学者や経済学者は統計のスペシャリストであること。
実際、心理学や経済学の学部の卒論、修士論文は、アンケートから統計的有意性を評価したり、膨大な行動・経済データから因果関係を導いて理論化するなどの内容ばかりだ。
つまり、彼らは、統計学を自分達の学問で理論化するときの手段として普通に使っている。
その作業はまさに、最近もてはやされるデータ・サイエンティストの作業と全く同じだ。

昨今のコンピューティングパワーのおかげで、統計処理という煩雑な計算は全てプログラムで代用できる。
それにより、心理学や経済学が本来やりたかった「人にどんなインセンティブを与えると、あるべき方向へ行動を誘導できるか」という問題を簡単に実験できるようになった。

実際、Uberでは、ミクロ経済学の授業の最初に出てくる需要曲線や消費者行動曲線をリアルに導き出すことに成功した事例があった。
需要曲線が分かれば、供給曲線は生産者自身が制御できるので、均衡する価格を生産者自身が誘導する事ができる。

他に、たとえば、税金をどのように表示すれば、消費者の需要を損なわずに購買意欲を引き立てることができるか、という行動経済学の実験もあった。
この実験で得られた内容は、まさに政府の経済政策に取り入れれば、消費税率が上がったとしても景気の腰折れをさせないような効果を生み出す可能性があるだろう。

【4】他方、個人的には、機械学習やニューラルネットワークなどのAI分野において、昨今のIT技術で、過学習の問題をどう解決しているのか、に興味がある。

いくらコンピューティングパワーが上がったとしても、間違った方向で計算して過学習の状態、つまり鞍点に陥れば、本来の全体最適された結果が得られない。
この問題は古くから知られていて、解決方法も色々あげられているが、まだしっくりと来るものは感じない。

【5】「心理学や行済学のような文系の学問とIT技術の組合せが非常に相性が良い」事が分かれば、今後、IT技術者には、心理学や経済学の学習も必要にされてくるかもしれない。

IT技術者はプログラミングという道具には詳しいが、ビジネス上の問題を解決する手法は知らない。
たとえば、「eショッピングやマッチングサイトでどんな設計にすれば売上が増大するのか」「生産者や消費者にどんなインセンティブを与えれば、売上向上につながるような行動を誘発できるか」という問題を解決するには、心理学や経済学の知見を使って、ユーザを誘導するシステム設計を実現することが求められるからだ。

一方、心理学や経済学は膨大な理論を蓄積してきたので、彼らの手法をIT技術で実現するだけで、簡単にその有効性を評価できるはず。
手当たり次第、彼らの手法をIT技術で試してみてもいいわけだ。

そんな事を考えると、面白い時代だな、と思う。
文系の学問は役に立たないと昨今言われるけれど、実は、こういう場面で非常に有効と分かるからだ。

【6】でも、心理学や経済学の理論によって「人のインセンティブで行動を誘発させる」手法を悪用すれば、甚大な影響も起きるだろう。

たとえば、アメリカのトランプ現象、英国のEU離脱などの政治現象を見ると、FacebookのようなSNSを使って民衆の政治行動を悪い方向へ誘導させることも実現可能になったのかな、とも思う。
また、炎上マーケティングのように、過激な発言に数多くの人が「いいね」「リツイート」させられることで、莫大な広告収入が得られるなら、そういう方向へどんどん過激化させていく方向に進んでしまう。
つまり、売上向上の最適化を図るアルゴリズムが暴走すれば、「人のインセンティブに故意にエネルギーを注ぎ込むことで、過激な行動へ走らせる」方向へ進んでしまうわけだ。

実際、一人の人間として知性があったとしても、集団心理学の観点では、リスキーシフトのように、より過激な意思決定に進んでしまう事例は、過去の日本の敗戦や米国のベトナム戦争のように、既にある。

今は、ビジネスに限らず、政治経済の分野で、心理学や経済学とIT技術の組み合わせによる壮大な実験が平行で行われている時代のように思える。

| | コメント (0)

2019/03/31

システムエンジニアリングとしての SysMLの記事のリンク

青木淳さんが書かれたSysMLの記事が分かりやすかったのでリンクしておく。
ラフなメモ。

【参考】
「システムエンジニアリングで SysML を使いこなす」第1章 概要編-システムエンジニアリングとしての SysML | オブジェクトの広場

「システムエンジニアリングで SysML を使いこなす」第2章 実践編-電光掲示板を設計する(1) | オブジェクトの広場

「システムエンジニアリングで SysML を使いこなす」第2章 実践編-電光掲示板を設計する(2) | オブジェクトの広場

上記の記事を読んで面白いと思った点は2つある。
一つは、SysMLという共通言語が複数の専門家集団の意思疎通に重要な役割を果たすこと。

ソフトウェア組込製品でも、システムの大規模化・複雑化によって、開発作業はハードウェア技術者やソフトウェア技術者に細分化され専門化した。
結局、開発プロセスや開発組織そのものも局所最適化されてしまっている。

一方、市場要求や技術革新によって、どんどん製品や技術が陳腐化していくので、製品自体をその次代の技術に合わせて全体最適化する必要が出てくる。

しかし、今までの日本人が得意とする、すり合わせ技術だけでは、システムの複雑化や市場変化の速度に付いていけない。
そこで、モデルベースエンジニアリングのように、システムアーキテクチャを全体最適の観点で構築し直し、ハード・ソフトの専門家も一緒に開発していくスタイルへ変化せざるを得ない。
そういう場面で、ハード・ソフトの専門家同士で会話するための共通言語となるSysMLが必要となり、役立つのだ、というストーリーと理解した。

確かに、例えば、製品ドメインの専門家、熱力学や電気・ロボットなどの自然科学の専門家、そして、機械学習やクラウド等のソフトウェアの専門家のように、多数の専門家から成る集団で開発する場合、共通言語がなければ、価値ある製品を作ることは難しいだろう。
共通言語だけで解決できるわけではないが、必要条件の一つにはなりうる。

もう一つは、あらかじめ全ての顧客要求や製品の部品やアーキテクチャを決める必要はなく、未決定の要素をリスク管理の対象とみなして開発を進めて、必要な時に随時決定すれば良いこと。

製造業の製品開発ではどうしてもWF型開発になりやすいが、各工程の内部は実際はアジャイル開発っぽい雰囲気が出てくる。
原材料や部品の発注があるので納期厳守でWF型開発が王道だが、中身の開発は試行錯誤が普通。

昨今の開発では、要件を全て決めてから開発する、という流れの方が少ないだろう。
その時に、製品のアーキテクチャをSysMLで表現した時、どの部分の要件が未決定であるか、を明確に区別して管理することは重要になってくる。
その未決定の要件はリスク管理の対象として扱い、リスクが顕在化してきた時に、アーキテクチャを明確に固めていく。

そのプロセスでは、SysMLにあるユースケース図、ブロック図、シーケンス図、アクティビティ図などを使えば、複数の観点でアーキテクチャを分析することで整合性が取られることになる。
つまり、SysMLというモデリング言語によって、リスク管理を支援していることになるわけだ。

そんな事を考えると、設計と開発プロセス、モデリングは表裏一体のように思える。
それらを操れることで、開発をコントロールできるわけだ。

| | コメント (0)

2019/02/11

法律のケース問題をモデル化するアイデア

法律のケース問題を図解する事例を、ネットサーフィンしながら見つけたのでメモ。
アイデアをラフなメモ書き。

【参考】
中小企業診断士試験 一発合格道場 ≫ Blog Archive ≫ 【法務】ケース問題を打破する図解術

UMLの概念モデルで法律を理解するアイデア: プログラマの思索

法務脳の作り方part1: プログラマの思索

【1】上記の記事によると、法務のケース問題を図解するパターンは2つある。

【1-1】一つは、民法のように「誰がどんな権利を主張できるか」のケース。
重要ポイントは、利害関係者とその権利・義務の関係を明確にすること。
つまり、利害関係者の関係を明確にできるようにモデル化すること。

なぜなら、民法では、被害者・加害者、あるいは背信的悪意者のようなステークホルダーのうち、誰が権利を持っているのか、権利を主張できるのか(対抗要件)をケースごとに見抜くのが重要だからだ。

(引用開始)
1. 図解術その1~登場人物を整理してみる
冒頭にトラブルについての長い状況説明があり、「どのような権利を主張できるか」等の設問があるタイプの問題です。
主に民法関連の問題に多い形式です。

例として、H18年度の第9問-設問1を見てみましょう良い
不法行為と債務不履行の問題です。
(中略)
「X社が主張できるもの」を問われているので、X社をとりまく登場人物とその関係を図で整理してみます
(中略)
作図する際に意識した点は、大きく以下3点です。

・登場人物を明確にする (X社/Y/Z社/B社)
・登場人物の属性を示す (X社はライセンス利用者/Yは保持者/等)
・登場人物の関係性を示す (ライセンス契約/等)

このように登場人物が多く事象が複雑な場合には、一目で全体を俯瞰できることが重要なポイントになると思いますキー
(引用終了)

【1-2】もう一つは、知的財産法のように「ある時点で権利の出願を行うが、他社より「権利侵害である」と言われる」ケース。
重要ポイントは、時系列で権利の出願・公開・侵害の申請などのイベントを整理すること。
なぜなら、「多くの知的財産権は、基本的に”先願主義”を取っているため、誰の行動が一番先なのかを意識することが重要である」ためだ。

(引用開始)
2. 図解術その2~時点を意識する
知的財産権関連の問題に多い形式、過去のある時点で権利の出願を行うが、他社より「権利侵害である」と言われるようなタイプの問題です。

例として、H21年度の第9問を見てみましょう
商標権の問題です。

商標権登録を行うためにライバルであるD社への対処を問われているので、C社とD社の現在までの行動を時間の流れと共に整理してみます。
例えば、こんな感じです。

作図する際に意識した点は、大きく以下3点です。

・誰が (C社またはD社)
・いつの時点で
・何を始めたのか

多くの知的財産権は、基本的に”先願主義”を取っているため、誰の行動が一番先なのかを意識することが重要であると思っています
(引用終了)

【2】上記の事例より、下記でまとめられるだろう。

・民法は「利害関係者の図」が有効。
 なぜなら、権利・義務・対抗要件を明確にしたい為。
 →パッケージ図、クラス図、ユースケース図、コラボレーション図が有効か?

・知財は「イベントの時系列」が有効。
 なぜなら、先願主義なので、誰の行動が一番先なのかを明確にしたい為。
 →アクティビティ図、タイミング図?

過去にも、UMLの概念モデルで法律を理解するアイデア: プログラマの思索で、刑法の概念をクラス図でドメインモデルで描いてみる、という事例もあった。

この辺りを整理してみたいと思う。

| | コメント (0)

「サピエンス全史」「ホモ・デウス」の図解のリンク

一世を風靡した本「サピエンス全史」「ホモ・デウス」を図解した記事があったのでリンクしておく。
書籍を一度読んだ人であれば、この図解を見れば、そういうストーリーだったことを思い出せるはず。

【参考】
サピエンス全史図解(詳説版)|きょん|note

ホモ・デウス図解|きょん|note

akipiiさんのツイート: "この図解はすごく分かりやすい。plantUMLで書き換えてみたいな。サピエンス全史図解(詳説版)|きょん @kyon_hcj|note(ノート) https://t.co/kpZUiXCvgR"

akipiiさんのツイート: "利害関係者の図をPlantUMLで書く事例。分かりやすい。面白い。2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない https://t.co/8B15anmKAj"

【1】「サピエンス全史」「ホモ・デウス」は歴史好きの人にはたまらない本ではないか、と思う。
欧米人の学者は、歴史上の数多くの事実を一つの理論や体系、思想を元に整理して、一つの壮大な絵巻物で表現するのが上手だと思う。
でも、その膨大な量に圧倒されて、結局何が言いたいのか、を掴むのに結構時間がかかる。

そこで、上記の図解を読めば、まずは一つのストーリーを即座に理解できるので、その理解をもとに書籍を読み直すと理解しやすくなると思う。

【2】最近、歴史や法律など文系の知識をモデル化する事例に興味がある。
たくさんの文章に、言いたいことが埋もれてしまっていてすぐに理解できない時に、図解やモデリングの技術を使って、概念を鳥瞰して理解したいのだ。

例えば、利害関係者の図はパッケージ図やクラス図、歴史の流れはシーケンス図、といったモデルで表現すると、実は意外に分かりやすくなる。

2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない

歴史の流れをPlantUMLのシーケンス図で書き起こす事例のリンク: プログラマの思索

akipiiさんのツイート: "この発想はいいな。歴史や政治、法務はモデル化したい。RT @naruyo_t: UMLで図を描くというのはおもしろい。ただ見栄え気にしたい派の私としてはpptがなじんでて下書きでの整理に良さそうと思った。 “2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない” https://t.co/8B15anmKAj"

色々試してみたいと思う。

【追記】
hekitterさんはTwitterを使っています: 「「サピエンス全史」「ホモ・デウス」の図解のリンク https://t.co/6KSKQH4Dph 今日UMLのことを調べてたら、思いがけず興味深いのがあるやんとみてたら、やはりakipiiさんの記事だった。(まだちゃんと読めてないので改めて読む)」 / Twitter

| | コメント (0)

astahのモデルをGitで差分比較する方法のリンク

astahのモデルをGitで差分比較する方法の記事があったのでリンクしておく
この方法は使えそう。

【参考】
astah*とGit | astah in 5 min

【1】UMLでモデルを書いていると、差分比較を取りたくなる時がある。
顧客の要求事項を一つずつモデルに反映して、課題を一つずつ潰していく作業は地道で労力がかかる。
だから、顧客のヒヤリングのたびに、想定したモデルをどんどん洗練させていく時、前回の状態とどれだけの変更箇所があったのか、後で振り返りたくなる。

また、マイルストーンごとに、モデルの差分比較もやりたい時がある。
仕様変更のスコープだけ、顧客に見積もりを請求したいからだ。

その為には、たとえモデルがバイナリファイルであっても、ソースと同じような差分比較機能が欲しくなる。

【2】(引用開始)
astah*には、プロジェクトの比較機能というものがあります。これをコマンドラインから利用できるようになっていることはあまり知られていないかもしれません。
このastah-commandコマンドは、インストールフォルダに配置されています。下記のように、-diffオプションに、比較対象の2つのファイルを指定して実行すると、モデルの差分や図の差分を確認する画面が開くというものです。

astah-commandw.exe -diff file0.asta file1.asta

このコマンドを利用することでGitリポジトリで管理するastah*のプロジェクトファイルのリビジョン間の比較をすることが可能です。
(引用終了)

なるほど、astahのコマンドにDiffオプションがあるので、それを使うという方法。
差分履歴を持つ2個のastahファイルがあれば、コマンドを使ってプロジェクト間の差分比較ができる。
このコマンドをスクリプト化しておけば、気軽に差分比較できるわけだ。

さらに、記事によれば、SourceTree上でもastahモデルを差分比較できるらしい。
これは便利だ。
Gitの履歴のリビジョンを取得して差分比較するスクリプトも用意しておけばいい。

色々試してみたいと思う。

| | コメント (0)

2019/01/04

PlantUML Example for モデルベース要件定義テクニックの記事のリンク

@ogomrさんのPlantUML Example for モデルベース要件定義テクニックの記事がとても参考になるので、リンクしておく。
以下は、論理的でないラフなメモ書き。

【参考】
PlantUML Example for モデルベース要件定義テクニック - Qiita

akipiiさんのツイート: "この発想は面白いな。RT @ogomr: PlantUML はテキストだけど意外と表現力があって モデルベース要件定義テクニック のUMLを拡張した図も描ける。GitLab なら RDRA をブラウザで表示できて便利 https://t.co/IpCRFQ4XDu"

akipiiさんのツイート: "後で試す。RT @zenzengood: PlantUML Example for モデルベース要件定義テクニック https://t.co/IpCRFQ4XDu #Qiita テキストベースでRDRAモデルを書きたい方はとても参考になります。"

歴史の流れをPlantUMLのシーケンス図で書き起こす事例のリンク: プログラマの思索


【1】最近、PlantUMLに着目していて、色々試しているのだが、@ogomrさんのPlantUML Example for モデルベース要件定義テクニックの記事がとても参考になった。

ストーリーは、モデルベース要件定義テクニック(RDRA)で使われるUML技法を、PlantUMLを使って書いてみよう、という流れ。
モデルベース要件定義テクニックは、UMLの技法をプロファイルで拡張していて、Enterprise Architectにはそのテンプレートがあるが、astahでは使えないので、いつも残念に思っていた。
だから、PlantUMLでモデルベース要件定義テクニックの技法を使えるのは非常に嬉しい。

記事では、コンテキスト図、概念モデル、ユースケース、データモデルなどがPlantUMLで紹介されている。

【2】RDRA(モデルベース要件定義テクニック)については過去に色々試していた。
僕は、UMLを要件定義に使う場合にRDRAの技法や考え方が非常に役立つ、と思っている。

さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナーの感想 #RDRAセミナー: プログラマの思索

リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンク: プログラマの思索

理由は、UMLを要件定義に使おうとすると、要件を複数の観点で分析したい時に、粒度やトレーサビリティがバラバラになりやすい弱点があるが、モデルベース要件定義テクニックを使えば、その弱点を克服できるから。

実際、UMLやオブジェクト指向分析の技法を使うと、中間成果物が多い割には、結局、どんな要件が決まったのか、という事が分かりにくい時がある。
一方、モデルベース要件定義テクニックでは、システム地図の一部にUMLの各種ダイアグラムが埋め込まれ、それらがどんな粒度でどのように関連しているか、システム地図を鳥瞰する観点で要件を整理できる。

僕は、下記の記事にあるシステム地図の中で、「システム外部環境」「システム境界」の部分が一番重要と思っている。

要件定義支援ツール「要件のツボ」によるRDRAの実践 (1/3):CodeZine(コードジン)

なぜなら、人とシステムが相互作用するI/Fは、それら2つの観点で整理でき、相互に関連させることで、トレーサビリティを確保できるからだ。

結局、モデリングで一番重要で、かつ、難しい部分は、各モデルの粒度を揃えてレイヤ化することと、各モデルのトレーサビリティを保証することだと思う。
だから、モデルベース要件定義テクニックのような考え方を、具体的な技法で表現できると非常に心強い。

【3】PlantUMLには非常に可能性があると思う。
システム開発がプログラミング主体であるのと同じく、設計書もテキスト化して、構成管理の配下に置きたい野望があるから。
そのイメージは1年前に書いていた。

PlantUMLを使ってExcel設計書をテキスト化するアイデア: プログラマの思索

仕様書にもExcel脱却が求められている: プログラマの思索

一般ユーザやプログラマへ業務イメージや技術イメージを説明する時に、何らかの図や絵を描いた資料を作るが、それらはExcelやパワポでは作りたくない。
そこで、PlantUMLを使えば、プログラミングと同じ感覚で書けるし、Webで情報共有もしやすい。

さらに、PlantUMLで描いたモデルも、モデルベース要件定義テクニックのように、各モデルの粒度やトレーサビリティを意識した規則に当てはめれば、その精度も上がるだろう。

PlantUMLが普及すれば、UMLは中間成果物が多すぎて使いものにならない、という声よりも、プログラミングの概念設計の一部として普通に使う、という考え方に変わるだろうと期待できる。
@u6k_yu1さんと同意見だ。

akipiiさんのツイート: "すごくいいね!RT @u6k_yu1: なんかこう、PlantUMLとか、モデルベース要件定義テクニックとか、ICONIXプロセスとかが広まることで、UMLが背負ってしまったトラウマとか業とかが払拭されて、みんな気軽にUMLを使えるようになるといいと思う。"

そして、最終的には、モデリングの根本問題の一つである「モデルの粒度を揃えてレイヤ化すること」「モデルのトレーサビリティを保証すること」も、PlantUMLとモデルベース要件定義テクニックを併用することで、具体的な解決方法を持って解決できそうな気もしている。
そのアイデアも試してみる。

astahで設計書とモデル、プロセスをつなぐ為の資料のリンク: プログラマの思索

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

【追記】
u6k_yu1さんのツイート: "PlantUMLのパーサーが欲しい。モデリングツールとして機能させたい。"

u6k_yu1さんのツイート: "はい、そうですね。と最初は思っていたのですけど、どうも私のイメージはPlantUMLのIDEっぽいです。VSCodeにPlantUMLのプロジェクト管理機能とモデル間のトレーサビリティ検証やバリデーションやチェック機能が欲しい、みたいな。… "

| | コメント (0)

2018/12/30

歴史の流れをPlantUMLのシーケンス図で書き起こす事例のリンク

歴史の流れをplantUMLのシーケンス図で書き起こした事例がツイートされていいたのでリンクしておく。
これは分かりやすい。

【参考】
読書猿『問題解決大全』4刷、『アイデア大全』9刷さんのツイート: "右手を痛めてから手書きを減らすべくAtom+PlantUMLで図を描くようにしてる。 画像は、大化の改新の前後をシーケンス図でまとめたもの。… "

akipiiさんのツイート: "歴史はシーケンス図で書くと面白いな。RT @kurubushi_rm: 右手を痛めてから手書きを減らすべくAtom+PlantUMLで図を描くようにしてる。 画像は、大化の改新の前後をシーケンス図でまとめたもの。 https://t.co/4FBraKNyco"

読書猿『問題解決大全』4刷、『アイデア大全』9刷さんのツイート: "実は「UMLで描く日本史」という企画もあってですね。… "

apple][ (28)さんのツイート: "あーこれはわかりやすいかも。 歴史の教科書って、時系列に文字で説明されているだけだから、相互関係や因果関係がすごく分かりにくいんだよね。図があってもすごく分かりにくかった。結局単なる暗記ものの域を脱しなくて、学問として全く興味が湧かなかったのもそれが大きな要因と思う。… https://t.co/kEoyxxbWNg"

akipiiさんのツイート: "「UMLで描く日本史」だけでなく「UMLで描く世界史」も期待しております! PlantUMLでソースをGitHubで公開してくれると、日本の高校生や受験生にも役立つと思いました。… "

てるりん🍙お結び隊 No.6🎸TEAM Mさんのツイート: "納品ドキュメントにWordやExcelが求められたりした場合は仕方ないけど、納品対象にならない内部設計のドキュメントやチームメンバー間での情報共有目的なんかは、SublimeTextやVSCodeとPlantUMLで書いてMarkdownで埋め込んでPDF化とか、最近よくやる。… https://t.co/ZxsDIBnsmJ"

【1】日本史や世界史のような歴史は大嫌い、という人も多いと思う。
理由は、暗記が大嫌いだからだ。
訳の分からない人名、関連して覚えにくい年号、など、丸暗記しなければ解答できないものばかりだから。

でも、僕自身は数学と歴史は好きだった。
理由は、数学はロジカルに組み立てられているので、基本的な公式さえ理解すれば、後は、そこから演繹的に導くだけで暗記が不要だから。

また、歴史も、その時代の政治的な背景や経済的な構造という仕組みを理解すれば、歴史上の大事件をマグマの噴火の現象として捉えることで、一連の流れで捉えることができるから。

たとえば、一昔前の歴史物であれば、マルクス主義史観や民主主義史観みたいに、歴史は経済中心で発展していくべきものであり、最終的には独裁政治から資本主義を経て民主主義へ落ち着く、という流れの中で、その国の歴史をプロットする、という考え方もある。
実際、民主主義に発展した国と歴史を考えれば、英国→フランス・米国→ドイツ・日本→ロシアの順で民主主義化されてきた。
あるいは、一人あたりGDPがある一定水準を超えると、中産階級の政治的発言力が高まり、独裁政治から民主主義に政治体制が変わる、とか。
とは言え、そういう進歩主義的歴史観が中国に当てはまるのかどうか、分からないが。

【2】では、そういう考え方で、歴史を捉えたい時、どんなモデリング手法を扱えばいいだろうか?

その答えの一つは、歴史をシーケンス図で書き起こしてみる事ではないだろうか。

たとえば、上記では、大化の改新前後の歴史的事件を、シーケンス図で書き起こしている。
さらに、吹き出しに、年号と事件名を書いている。
ゆえに、シーケンス図を見ると、誰が誰に何しているか、というのが一目で読み取れるので、理解しやすい。

シーケンス図のメリットは、アクターやオブジェクトの相互作用を表現できることだ。
そこから、UMLモデリング手法の考え方も適用できるだろう。

たとえば、Fatなオブジェクトがあって、メッセージの発信源が集中しているならば、他のオブジェクトが実は他に存在しているのではないか、と疑ってみると面白いかもしれない。
実は、XX事件の黒幕とか、他の重要人物が隠れているのかもしれない。

あるいは、「責任の委譲」を使って、メッセージが階段状になるように書き起こしてみて、歴史的事件のステーク・ホルダーが誰なのか、ステーク・ホルダー同士でどんなやり取りがあったのか、を書いてみると、より詳細に理解しやすくなるのではないか。
特に、XX戦争における敵と味方の区別、とか。
たとえば、新聞の国際欄では、シリア紛争の複雑な利害関係者の敵と味方の区別をクラス図に近いモデル図で表現している。

【3】そこで、歴史をシーケンス図で書き起こす時、VSCode+PlantUML+Gitを使うと非常に書きやすくなるだろう。

なぜならば、シーケンス図をプログラミングのように書けて、即座にプレビューできるので、試行錯誤しながら考えをまとめられるから。
また、Gitで構成管理の配下に置けば、理解した内容を継ぎ足していくことで、歴史のシーケンス図を一つの絵巻物として書き上げられるから。

上記の日本史のシーケンス図を見ていると、PlantUMLと歴史は相性が良い、という気がした。
日本史や世界史の年表を全てシーケンス図で書き起こしてみたら、世の中の高校生に貢献できるのではないだろうか??

たとえUMLを知らない高校生であっても、シーケンス図のように箱と矢印だけの絵を見れば、だいたいのイメージは分かるはずだろうから。

【4】PlantUMLの可能性については、以前から考えていた。

僕は、日本のSIで広く使われているExcel設計書は、全てテキスト化してGitで構成管理させたい。
そのためには、PlantUMLのような何らかのモデルの絵が必要だろうと思う。

一昔前の詳細設計書のような自然言語のドキュメントは現代では不要だが、システムの構想やアーキテクチャのイメージは、何らかのモデルという絵で表現したいからだ。
そうすれば、アーキテクトは、顧客やプログラマに説明しやすくなるから。

仕様書にもExcel脱却が求められている: プログラマの思索

PlantUMLを使ってExcel設計書をテキスト化するアイデア: プログラマの思索

ツイートを読み流していると、世界中の人達がPlantUMLを使って色んなアイデアを試そうとされているのがよく分かる。
業務フローやシステムのアーキテクチャだけでなく、ER図、ジョブフロー図、ガントチャートもPlantUMLで実現できる。
さらに、リスク関連図(?)みたいな、因果ループ図までPlantUMLで実現しようと試されている人もいるみたい。

akipiiさんのツイート: "後で読む。RT @pdl_runa: 現場で役立つシステム設計の原則にあるUMLをPlantUMLで書いてみる https://t.co/LIRmSOsBWW"

akipiiさんのツイート: "後で読む。RT @tech_advent: OPENLOGI Advent Calendar: plantUMLで業務フローを整理する https://t.co/2LWksWSyuI"

akipiiさんのツイート: "なかなか良いな。RT @abe4tawa8: PlantUMLでER図を描く! – VELTRA Engineering – Medium https://t.co/7eVRHuFjFC"

akipiiさんのツイート: "ジョブフロー図も書きたくなるな。RT @jiro_saburomaru: 定期実行のバッチとかのタイムチャートをテキストから生成できないのかな。plantuml みたいに"

akipiiさんのツイート: "I think it interesting. RT @DinisCruz: Here is the first draft and @PlantUML version of our revised @Jira schema for risk management What do you think? Does it make sense? Created by @madplatt #IN https://t.co/76Fy4FM1me"

立花優斗さんのツイート: "PlantUMLめっちゃいいな… "

【5】PlantUMLを用いて、Excel設計書をテキスト化するだけでなく、日本史や世界史もモデルで書き起こす事例のように、他の分野にも適用して試してみたくなってきた。

来年のastah関西でも、そういう話をしてみたいな。

【追記】
@kurubushi_rmさんが、「大化の改新前後.pu」「環大西洋革命.pu」をGitHubでソースを公開されている。
とても参考になる。

kurubushi--rm/history-in-UML: We will use UML to summarize Japanese history and world history

読書猿『問題解決大全』4刷、『アイデア大全』9刷さんのツイート: "@akipiiさんのご提案を受けて、このPlantUMLでソースをGitHubを公開しました。https://t.co/I8kF93dALf これだけだと日本史なので、世界史のサンプルとして「環大西洋革命」を追加しました。 何れにせようろ覚えなので、修正パッチなど遊んでいただけると幸いです。 https://t.co/aaYZyrlmSJ"

akipiiさんのツイート: "年末年始の忙しい時にありがとうございます! 歴史だけでなく、新聞の国際欄にある利害関係者の図、例えばシリア紛争、をクラス図やコラボレーション図で描く、とか、色々アイデアが膨らみます。… "

akipiiさんのツイート: "@kurubushi_rmさんが日本史と世界史のシーケンス図がPlantUMLでソースをGitHubを公開されてます。https://t.co/RzJsYwXpUj 中国の王朝変遷の歴史、歴史上の戦争とか、色々描けそう。 他に、民法や会社法、知財法などの理解の為に、UMLが使えないかな?と思ってる。"

akipiiさんのツイート: "すごくいいね!RT @u6k_yu1: なんかこう、PlantUMLとか、モデルベース要件定義テクニックとか、ICONIXプロセスとかが広まることで、UMLが背負ってしまったトラウマとか業とかが払拭されて、みんな気軽にUMLを使えるようになるといいと思う。"

【追記2】
y503Unavailable@非公式Redmine調理法unofficialcookingさんのツイート: "Redmine界隈をネタに作成してみました。(記載判断は自分の主観) 振り返り易くすることは必要ですね。… "

【追記3】
ステークホルダーの関係をPlantUMLで図式化した事例が面白い。
歴史の内容は、全てPlantUMLで置き換えた方が分かりやすいのではないだろうか。

2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない

| | コメント (0)

2018/10/09

第66回IT勉強宴会の感想~データモデリングに数多くの流派が発生している理由

先週土曜に、関西IT勉強会に行ってきた。
渡辺さんの話を聞きながら、日本で、なぜ、データモデリングに数多くの流派が発生しているのか、そんな理由が垣間見えた気がした。
以下は、とりとめもないラフなメモ書き。

【参考】
予算テーブルと実績テーブルを分ける?: 設計者の発言

方法論科学研究会(情報システム学会) <第66回IT勉強宴会in新大阪> | IT勉強宴会blog

【1】渡辺さんのデータモデリングの最大の特徴は、ER図に描かれるデータモデルは、関数従属性だけの観点で書き切ること。
つまり、あるべき業務イメージやあるべき業務フロー、あるべき組織構造とは全く無関係である点。
また、現状の業務フロー、現状の組織構造の観点も入れない。
あくまでも、関数従属性だけの観点でモデリングする。

こういう基本に忠実なデータモデリング手法は、実は普通ではない、という事実が、パネルディスカッションで明らかになったのが面白かった。

どうやら、熟練のデータモデラーも含めて、一般人も、関数従属性だけに従ったデータモデルを更に細かく分割するのが普通らしい。

例えば、小関さんのモデリング手法では、最初にAsIsの業務フローをヒヤリングしながら、頭の中ではデータモデルの項目群を関数従属性の束でまとめながら、ER図をイメージしていく。
そして、ToBeの業務フローを描く時に、データモデルを具体化して確定させる。

たぶん、普通のモデラーならば、小関さんと同じように、AsIsとToBeの業務フローを描きながら、ToBeのデータモデルを描くという同時並行スタイルが普通だろうと思う。

でも、渡辺さんのデータモデリング手法である三要素分析法では、業務フローのヒアリングはしない。
データモデルを描くためのヒヤリングに限定し、業務の問題点や課題、ToBeの業務イメージは聞かず、あくまでも関数従属性の情報だけを集めることに注力する。

【2】では、なぜ、渡辺さんは、そういう手法にこだわるのか?

なぜなら、データモデルをその場で聞きながらモデリングするためには、関数従属性の観点だけに絞った方がやりやすいから。
そこに、ToBeの業務イメージやAsIsの業務フローの話が混じると、モデルを描くという目的とズレた議論になってしまいがち。

聴衆の方からも、渡辺さんのライブモデリングを側から見ていると、切れ味が鋭くて気持ちいいくらい。
なぜなら、ユーザは自分が抱えている課題や問題点を他人に話したい習性があるので、モデラーにそれらをぶつけたい気持ちがあるが、それを表に出すと、渡辺さんはそれは議論の範囲外です、とバッサリ切ってしまう、と。
面白い。

また、そういうライブモデリングにこだわるもう一つの理由は、データモデルさえ確定すれば即座に画面UIが決まり、プロトタイプのシステムが作れるから。
そうすれば、ユーザにプロトタイプを見せて、早くフィードバックがもらえて、より明確なシステム像が見えてくるから。

【3】では、渡辺さんのデータモデリング手法では、あるべき業務やあるべき組織構造はモデルに表現できないのか?

実は、渡辺さんのデータモデリングである三要素分析法では、データモデルは関数従属性の束の観点に絞るが、業務を担当する組織構造や業務フローの要件は、機能や業務という別の側面で捉えて分析する仕組みになっている。
たとえば、三要素分析法では、「業務」「データ」「機能」の3次元の絵で説明される時が多いが、それらの次元の軸がそれに相当する。

つまり、業務システムは3次元の軸で実現されるものであり、データ軸はあくまでも関数従属性の束だけでよく、それ以外の要件はそれぞれの次元の軸で捉えれば良い。

この分析手法のメリットは、データモデルの構造とデータモデリング手法そのものがシンプルになること。
つまり、渡辺さんがこだわる「ライブモデリング」に大変適しているし、モデリング手法も関数従属性の束だけ考えれば良いので、業務知識を知らなくても描けるメリットがある。

一方、パネルディスカッションの議論を聞いてみると、TM手法(T字型ER)やTH手法では、データモデルにあるべき業務イメージや業務フローの要件も組み込んでいる。
おそらく、一般のデータモデラー、普通の設計屋もそういう手法を取るだろう。

しかし、そういうデータモデリングは多分、初級者や中級者には難しい。
あるべき業務イメージや業務フローを描くには、その業界の業務知識、あるいは簿記1級レベルの会計知識が必要にならざるを得ない。
また、そういう業務知識とデータモデリングの整合性を取るのは、相当難しいのだろうと思う。

【4】渡辺さんのデータモデリングを見ると、システム設計を多少でも知っている人ならば、違和感を感じる所がある。

たとえば、直近のメーリングリストでは、予算実績テーブルという、予算と実績の2つのデータが1つのテーブルにまとめてもよいのか、分けた方が良いのか、という議論があった。

渡辺さんのモデリング手法では、関数従属性の束の観点だけなので、ユーザのヒヤリングでそういう要件だけならば、予算と実績のテーブルに別々に分ける必要はない。
だから、他のデータモデラーから見ると、すごくFatなテーブル、太ったテーブルのように見えて、とても違和感がある。

予算テーブルと実績テーブルに分けるべきではないか、と。
疎結合の設計思想、クラウドとの親和性、データ管理のライフサイクルの観点では、予算実績テーブルで一つにまとめるのはおかしいのでは、と。

しかし、関数従属性の束だけの観点だけのデータモデリング手法の立場であれば、関数従属性がないのに、テーブルを別々に分ける方がおかしい。

渡辺さんが描くデータモデルでは、太陽系みたいに、トランザクション系のFatなテーブルが中心にあって、その周囲に関連するマスタ・イベントのテーブルが配置されるシーンをよく見かける。

たとえば、佐野さんもブログに書かれているように、商品マスタに在庫数という導出属性が混じっていて、すごく違和感を感じた、というのと同じ。
普通は、商品マスタから在庫数は外し、サマリ系テーブルに在庫数を入れて、定期的なバッチ処理で集計するのが普通だろう。

しかし、渡辺さんの商品マスタのモデルでは、倉庫がない中小企業の事例なので、そういうモデルになった。
今後、倉庫を新たに持つのであれば、在庫数を持つ倉庫テーブルが出てくるのでしょう、と。

でも、そういう考え方を知って、渡辺さんが描いてきた過去のデータモデルを振り返ると、なぜ、すごくFatなテーブルが多いのか理解できた。
そして改めて、そういう技法にあえてこだわる理由も理解できた。

【5】そのパネルディスカッションの中で、@sakaba37さんから、こんな質問があった。

我々システム屋は、分割統治の手法が身に染み付いているので、何でも細かく分割して最終的に組み合わせるという設計手法に慣れている。
だから、渡辺さんのデータモデリング手法では、分割統治されていないように見えるので、違和感を感じるのではないか、と。

また、そうは言っても、渡辺さんの頭の中には、過去の経験を踏まえて、業務パターンのような暗黙知があるので、ライブモデリングのように素早くモデリングできるのではないか。
その業務パターンを形式知化できるといいですね、と。

その話を聞いて、確かに、モデリングでも分割統治して、モデルの対象となる粒度は細かい方が良いのだ、という先入観が強すぎるのかもしれない、と感じた。

【6】他に、パネルディスカッションでは、関数従属性の束でまとめたとしても、それら項目の中で特別な属性で、何かしら強いイメージを持つような「強属性」のものはありますか、という質問があった。

意図としては、項目の関数従属性でテーブルとして洗い出した時、主キー以外にも、特別な役割を持つ項目があるのではないか、ということ。

渡辺さんの回答では、ありますね、と。
たとえば、この属性は主キーではないが、参照は可能だが更新は不可である、という特徴を持たせたい時があります、と。
たとえば、サロゲートキーが主キーであっても、複合キーを主キーとして同格に持たせたい時に使いたい場面が考えられる。
渡辺さんが作ったX-TEA Modelerには、そういう機能をあえて作っている。

データモデリングしてますか? - TECH BLOG | 株式会社テラスカイ

Salesforceのデータモデリング手法の記事のリンク: プログラマの思索

【7】そんな話を聞きながら、日本でデータモデリングに数多くの流派が発生している理由は、渡辺さんのようなシンプルなデータモデルに、あるべき業務イメージや業務フロー、組織構造などを入れ込む手法の方が多いから、その入れ込む観点や手法で数多くの流派が生まれているのだろう、と思った。

初心者の僕から見れば、データモデラーとは、渡辺さんのように関数従属性の束だけに着目してデータモデルを描くのが普通の人なのだ、と思った。
けれど、実際はそうではなく、色んな考え方を持つ人が多い、ということは分かった。
あるべき業務、あるべき組織構造を考えるには、それなりの業務経験や業務知識が必要で、データモデリングそのもの以外の内容も含まれるだろうから。
そこにコンサルティング会社としての価値もあるのだろう。

だからこそ、たぶん、データモデリングの初心者がモデリングを習得するには、渡辺さんのようなシンプルな技法に特化した方が良いのだろうと思う。
業務知識を知らなくても、関数従属性だけにこだわって、データモデルを描くことに注力すればいいから。

そんな話が聞けて面白かった。

| | コメント (0)

2018/09/09

第2回astah関西の感想 #astahkansai

昨日の第2回astah関西の感想をラフなメモ書き。

【参考】
第2回astah関西勉強会「開発現場のモデリング事例紹介」 - connpass

Mix Leap Study 特別編 -「開発現場のモデリング事例紹介」(astah勉強会) - connpass

7/7土の第2回astah関西の見所 #astahkansai: プログラマの思索

第2回astah関西勉強会(2018/9/8)のスライドが公開されました | astah in 5 min

【1】7月の西日本豪雨で1度流れ、4日前の台風の影響で参加者は減りましたが、参加者の熱気もあって盛り上がり、雰囲気はとても良かったように思います。
講演の内容もビジネスモデリングから組込み系、astahのより良い使い方など盛りだくさんで、飽きない感じでした。

講演中のアンケートでは、astahの利用または経験者が多数いた事、組込みエンジニアまたは組み込み系コンサルタントの方が半数以上いた点が興味深かったです。
僕自身は、業務系Webシステム開発をベースとしたビジネスモデリング系だったので、グループディスカッションでは、全く違う層の人たちと、最近の電気自動車や組み込み機器のセンサー化、機械学習の動向などの話が聞けて面白かったですね。

以下、講演内容について感じたことをメモしておく。

【2】兒玉さんの講演では、astahに描いたアクティビティ図から、astahAPIで情報抽出するデモを見せてくれた。

考え方としては、レガシーなCプログラムから手作業でastahのアクティビティ図へリバースしてモデリングする。
その時、アクティビティ図の吹き出しに、該当ソースの行番号も書いておく。
その後、astahAPIを用いて、JavaScriptでアクティビティ図の吹き出しにあるソース行番号の情報を抽出し、Excel設計書に貼られたCプログラムと照合して、合致した行番号に色塗りする、という仕組み。

つまり、astahのモデルとCプログラムの照合作業をastahAPIを使って自動化する、という作業を実現されている。
もちろん、astahのモデルは手作業で描くし、ソース行数も手作業でモデルに埋め込む必要はあるが、モデルを作っておけば、後はastahAPIでいくらでも情報を抽出できるので、照合やカバレッジなどの作業を自動化できる点は面白い。

astahを起動せずにJavaScriptで情報を取得する方法: プログラマの思索

また、astahAPIは、公開されているJavaDocだけでなく、astahからXML出力されたXMLファイルのXPATHを参考にすると良い、という話もあった。
つまり、XPATHからJavaDocにあるメソッドを連想しやすくなる、ということで、これは面白いなと思った。

astah* API

astah* API概要

astahAPIを使いたいと思っていても、大量のJavaDocから見当を付けるのが面倒でいつも何とかならないかな、と思っていたので、この発想は使ってみたいと思った。

【2】高井さんの講演では、組込みシステムのソースのリバースエンジニアリング作業は、プログラマだけでなく、熱力学など自然科学の専門家、自動車や家電機器などの業務の専門家も関係していて、彼らドメインの専門家のリバースエンジニアリングの観点は異なるので、SySMLという共通言語によって有益な情報を組合せることができる、という主張が面白かった。

確かに、プログラマはCやC++は強いだろうが、熱や振動などの自然力学の法則に詳しいわけではないから、アルゴリズムの本来の意味まで分からない。
自然科学の知識を持つ専門家であれば、このアルゴリズムが表す制約条件は、鉄板の強度や耐熱や振動の範囲を示す、などの知見を言い当てることができる。
そうすれば、自動車や家電製品の設計エンジニアは、材料の強度や耐熱、振動などの制約条件を元に、製品の形状や大きさはこういう範囲で設計しなければならない、等の知見が得られる。

すなわち、リバースエンジニアリングした内容は、プログラム層、自然科学のドメイン層、業務ドメイン層等で解釈が異なるわけだ。
そんな事を理解すると、ソフトウェアを組み込んだハードの設計や開発を真に理解するには、プログラミングだけでなく、自然科学の知識や製品の知識まで知る必要があり、膨大な範囲になる。
だから、組み込み機器の設計開発は、どんどん難しくなっているのだろう、と推測した。

もう一つ面白いと思った話は、SysMLはソフトウェア技術者の地位を高めた、という話。
つまり、今まではハードの部品ができた後で、ソフトウェア開発を行うので、ソフトウェア開発者は限定された仕様の中でプログラミングせざるを得ず、主導権を取ることができなかった。
しかし、ハードの部品が開発される前に、SysMLを用いて、製品の論理構造をモデル化できるようになり、ハード技術者へソフトウェア開発に必要な仕様や制約条件を事前に伝えられるようになった、と。

確かに、ハードの部品や製品は、材料の購買・発注・組み立てなど数多くのコストがかかるので、そう簡単に作り直しはできない。
一方、ソフトウェアはいくらでも変更できるので、無理な要望を受けてしまいがち。
しかし、ハードを発注する前の設計段階で、ソフトウェア開発では、これだけのメモリや性能は必要です、という情報を事前にハード設計者に伝達できれば、ソフトウェア開発もやりやすくなる。
SysMLはそういう波及効果があった、という話が面白かった。

【3】細合さんのSTAMPの講演後、僕は、そういう機能安全設計のモデリング技法は、一般事象のリスク識別に適用できるのではないか、と質問してみた。

僕の理解では、自動車の機能安全設計のモデリング技法STAMPでは、対象のハード製品の利用シーンをユースケースとみなして、そこからハザード分析し、人命に関わるリスクを識別し、そのリスクを潰す為の安全設計の仕様を導き出す。
そうならば、PMBOKのリスク管理に出てくるリスク識別において、ある事象のリスクを、何らかの対象の相互作業(I/F)をユースケース(利用シーン)とみなすことで、STAMPの技法を適用できるのではないか、と連想したからだ。

しかし、後で、宿口さんから、STAMPとリスク管理は観点が違いますよ、と教わった。
宿口さんの話を理解した限り、PMBOKに出てくるリスク管理は発散系の技法に近いが、STAMPは収束系の技法である。
仕様が固まっている製品に対し、製品の利用シーンを想定して、それを元にハザード分析していく手法なので、根本から手法が異なる、と。
話を聞いた限り、STAMPの技法は、ロジカルに説明できるような資料作りに役立てる技法の一つ、という印象を受けた。
僕はPMBOKもSTAMPも詳しくないので、この辺りはまた考えてみる。

【4】稲田さんの匠メソッドによるビジネスモデリングでは、経験に基づいた試行錯誤の話が興味深かった。

彼の講演の中で、ビジョンから業務要求・IT要求・仕様へ至るまでモデリングしていく中で、モデルを書いていると、ダブリやつじつまが合わなくなる時がある。
特に、数多くのステークホルダーにヒヤリングしてその内容を収集すると、そういう傾向が出やすい。
だから、その内容を早めにフィードバックして、何を最優先すべきなのか、何を妥協すべきなのか、を決めていく、と。

【5】僕の講演では、astahのRedmineプラグインの紹介。

AstahのRedmine連携プラグインが公開されました: プログラマの思索

言いたかったことは、単にプラグインの紹介だけでなく、その背景にあるモデリングツールが今後発展するために必要な機能追加の要件だ。
それは、モデルのグルーピング機能とモデル間の相互リンク機能を追加することだ。
それらは、モデルの粒度やモデルのトレーサビリティという、モデリング作業の問題解決に直結すると考えている。

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

astahで設計書とモデル、プロセスをつなぐ為の資料のリンク: プログラマの思索

高井さんと話していて、モデルを沢山書いていくと、astahでもモデルのタブを切り替えるのが面倒になってくる、という話があった。
モデルが3個ぐらいなら問題ないが、10個、50個と書いていくと、モデルを探す作業に相当の時間が取られるから、とのこと。
つまり、モデルの関連や情報を検索するのに時間がかかっているのだ。

その問題の真因には、モデルの粒度とモデルのトレーサビリティがあると思う。
大規模なシステムになるほど、概念モデル、論理モデル、物理モデルなどモデルにも数多くのレイヤが発生し、区別せざるを得ない。
すると、それらモデルの粒度を合わせるために、グルーピングしたくなる。
しかし、そういう機能がUMLの仕様そのものにないし、astahにもない。

また、一つのシステムを静的な観点、動的な観点、状態遷移図、利用シーンなど数多くの観点で分析したモデルを作ったとする。
それらモデルは、一つのシステムの射影にすぎないので、相互にリンクさせることで、追跡できるようにしたい。
そうすること、重複や考慮漏れに気づくことができ、モデルの精度を上げることができるはず。
しかし、そういう機能がUMLの仕様そのものにないし、astahにもない。

つまり、astahを含めた既存のモデリングツールは、大規模なシステムの分析にはたぶん力不足。
もっと大規模で複雑なシステムを、数多くの観点で数多くのモデルで分析した時に、それらモデル間の整合性をとるために、モデルの粒度とモデルのトレーサビリティという考え方が必要になってくると思う。

一方、アプリ開発者の観点では、モデルのグルーピング機能は所詮、フォルダ分けという機能にすぎない。
また、モデルの相互リンク機能は、モデル間の相互のハイパーリンクという機能にすぎない。
つまり、モデルの粒度とモデルのトレーサビリティという問題解決に必要なモデリングツールの機能改善は、さほど難しいわけではない。

しかし、そういうちょっとしたUIの機能改善が、モデリングツールを洗練させるし、モデリング作業そのものを効率化させていくものと思っている。

モデリング技術の習得とモデリングツールの習得は表裏一体: プログラマの思索

【6】本勉強会のスコープは、「製品astah」「astahで描けるモデリング技法全般」というかなりマニアックな内容だったので、今後の勉強会の継続を懸念していた。
いくら僕が勉強会をやりたい、と思っても、そもそも人が集まるのだろうか、という不安があった。

しかし、参加者から好意的な感想も多く、また、本勉強会を以前からウォッチしていた、という方もいて、勉強会のニーズはある、と感じ取った。

いつまで続けられるか分からないけど、緩く長く続けられればいいな、と思う。


| | コメント (0)

より以前の記事一覧