モデリング

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"

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

| | コメント (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)

2018/08/19

モデリング技術の習得とモデリングツールの習得は表裏一体

1ヶ月前に、関西IT勉強会で「ITアーキテクチュアのセオリー」出版記念講演に出て、データモデリングの話を聞いてきた。
その講演者から、赤俊哉さんをお手本にしている、という話があり、赤俊哉さんの書籍をいくつか読んでみて、感じたことをメモ。

【ITアーキテクチュアのセオリー】出版記念講演<第64回IT勉強宴会in新大阪> | IT勉強宴会blog

赤俊哉さんの本「SE職場の真実 どんづまりから見上げた空」という本を読んだ。
著者が派遣プログラマ、ユーザ企業の社内SE、そしてユーザ企業のCIOへ築き上げたキャリア遍歴の話がメインで、自分の経験を振り返りながら、そうだなあ、と頷いていた。
その本の中で興味を惹いたのは、業務システムのリプレースの時に、有償の設計モデリングツールXupperに出会い、データモデリングを興味を持ち、データモデリングの技術習得に努め、業務システムの設計情報をXupperのリポジトリに集約させた事で、プロジェクトが成功した、という話があった。

Xupperとは? | 製品情報 | XupperII

Xupperの製品は僕も詳しくは知らない。
しかし、SoRのようなレガシー業務システムの設計情報をDOAモデリングツールのリポジトリに集約することの意義について、色々考える所があった。

SoRのような業務システムでは、どうしても上流工程の設計技術が起点になると僕は思う。
すると、DFD・ER図・CRUD表というDOAの3種の神器のような設計資料がどうしても必要になってくる。
なぜなら、業務の流れをつかむためにDFDが必要だし、データの構造をつかむためにER図が必要だし、仕様変更の影響範囲の調査やテスト設計のためにCRUD表が必要になるからだ。
しかし、それら設計資料をExcelドキュメントで手作業で作り出すのは正直面倒だ。

そこで、例えばXupperのようなモデリングツールが威力を発揮する。
設計情報がモデリングのリポジトリに一元化されていれば、そのリポジトリから、DFD・ER図・CRUD表は最新状態で出力でき、その内容を元に設計作業を効率化できる。
特に、仕様変更の影響調査では、設計情報が三位一体となったモデリングツールがなければ、システム保守でどんどんコストが増加していき、業務システムが経営環境の変化についていけなくなってしまう。

そういう観点では、DOAをマスターする事とモデリングツールを使いこなす事は表裏一体ではないか、と思う。
つまり、データモデリングを理解して自由自在に使いこなすには、モデリングツールがあればその成長速度を速められるし、他方では、モデリングツールを使いこなしていくうちにデータモデリングの技術を習得し、その作法に慣れていく、という側面があるだろう、と思う。

そういう背景やニーズが20年以上前からあるからこそ、最近、超高速開発という分野も脚光を浴びるようになったのだろうと思う。
僕は、超高速開発とは、データモデリングツールとそこから自動生成されたソースとそのシステムをシームレスにつないだもの、と思っている。
その本質は、モデリングツールで業務システムの設計情報をリポジトリ化できたからこそ、設計資料の出力だけでなく、システムの自動生成という所まで行えるのだ、という点にあるのだろう、と思う。

そんな事を考えると、モデリング技術の習得とモデリングツールを使いこなすことは表裏一体ではないか、と改めて感じる。
僕がUMLモデリングツールastahが好きな理由の一つに、そういう考え方を持っている事がある。

丁度それは、プログラミングの習得には、そのプログラミング環境の構築と習得が含まれていることと同じような気がしている。

【追記】
9/8土にastah関西の勉強会をやります。

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

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

| | コメント (0)

2018/06/07

7/7土の第2回astah関西の見所 #astahkansai

2018/7/7土にグランフロント大阪で、第2回astah関西勉強会を開催します。
勉強会の見所と、最近僕が考えているモデリングに関する問題意識についてラフなメモ書き。

【告知】
astah関西 第2回勉強会 - connpass

【参加申し込み】
Osaka Mix Leap Study 特別編 - astah関西 第2回勉強会 - connpass

【過去の資料】
第1回astah関西勉強会の感想 #astahkansai: プログラマの思索

【告知】astah関西 第1回勉強会を7/14金に開催します #astahkansai: プログラマの思索

【1】今回のテーマは、「開発現場のモデリング事例紹介」です。

(引用開始)
実際にastahを使っているエンジニアに、開発現場でastahを使ったモデリング利用事例を語って頂きます。
具体的には下記になります。

・astahをより良く使えるためのTips
・リバースエンジニアリングによるモデリング技法に関する事例
・STAMP等の機能安全規格のモデリングに関する事例
・astahを使って、匠メソッドによるビジネスモデリングを行う事例
・astahのRedmineプラグインの利用紹介

また、グループディスカッションでは、モデリングの初心者も気軽に質問できたり、モデリング経験者の経験談を共有できる場を設けます。
(引用終了)

第2回勉強会では、チェンジビジョンの開発者の方2名だけでなく、astahフレンドというastah公認ユーザ、匠メソッド勉強会スタッフをお呼びして、幅広く講演していただけることになった。
たとえば、ビジネスモデリングやリバースエンジニアリング、astahのより良いTips、STAMP等の機能安全規格など、業務システム設計に限定されず、幅広い充実した内容になった。

【2】「モデリング思考とモデリングツールは表裏一体である」という考え方

スタッフ打合せで、@kawakawaさんから「astahとモデリングのどちらをやりたいのですか?」という質問があった。
また、稲田さんから「勉強会の目的、ターゲットは何ですか?」という質問もあった。
以下、自分の考えを書いておく。

僕は以前から、モデリングの技術とその思考にはIT業界に入ってからずっと興味を持っていた。
理由は、いくつもの失敗プロジェクトの原因には、プロジェクト管理やチームビルディングだけでなく、システムを業務やアーキテクチャの観点できちんと設計できていなかった事の方が多いのでは、と痛感していたから。

そのうち、astahを使って、自分が思いつくまま、ラフなスケッチをたくさん書いてきた。
そうするうちに、モデリングという思考技術とモデリングツールは表裏一体ではないか、と感じてきた。

たとえば、UMLでは7つのダイアグラムを用いて、一つのシステムを複数の観点で徹底的に分析する。
UMLの中に、複数の観点でシステムを分析する、という思考方法が既に埋め込まれている。

あるいは、データモデリングでは、T字形ER手法のように、マスタとイベントの間の外部キー・複合キーの制約には、業務上の制約が反映されている、という考え方がある。

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

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

そういうモデリング作業で重要なノウハウというものは、紙でモデルを書いてもいいが、モデリングツールを使うことで自然に身に付く、という場合が多いことに気づいた。
実は、モデリングツールの機能に、そういう数多くのノウハウがいくつか埋め込まれているからだ。
他に、モデリングツールを使うと、気軽にモデルを描けるため、自分の頭で空想していたモデルを書き出すと、たくさんの矛盾や曖昧さが出てきて、色々書いていくうちに、気づきが多くなる、という経験もあった。

そうして、数多くのモデルをモデリングツールで描くことで、自分の中に数多くの暗黙知が溜まってきているのは感じていた。
だから、そういう経験をコミュニティと言う場でみんなと共有して、議論を深めたい、という気持ちがあった。
たぶん、僕なんかよりも、もっと深く考えている人はたくさんいるだろうし、そういう人たちと数多く議論して、気づきを得たい。
あるいは、自分が持っているモデリング上の問題意識を公開することで、誰かに気づきを与えたり、逆に、自分が教えられる場合があるかもしれない。

例えば、モデルと設計書、プロセスの間で発生する「モデルの粒度」「モデルのトレーサビリティ」「モデルの変更管理・構成管理」に関する疑問は、astahに限らず、モデリングツールを使いながら、ずっと問題意識を持ち続けてきた。
その辺りも色々議論してみたいと思っていた。

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

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

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

そういう僕のわがままな要望に賛同してくれたスタッフが数多く集まってくれたことで、昨年初めてastah関西コミュニティを開催できたし、今年も開催にこぎつけることができた。
ゆえに、astah関西のスタッフには特に感謝したい。
そして、第2回勉強会に既に多数の参加申し込みもあり、とてもワクワクしている。

【追記】
大雨のため、9/8土曜に順延となりました。

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

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

| | コメント (0)

2018/05/25

「大学生・社会人のための言語技術トレーニング」の感想

「大学生・社会人のための言語技術トレーニング」の本がとても良かったので、感じたこと、考えたことをラフなメモ書き。
自分の考えと感想を混ぜて書いているので、ロジカルでない。

大学生・社会人のための言語技術トレーニング - 発声練習

医学書院/週刊医学界新聞(第3054号 2013年12月02日)

7月の言語技術教室: タイガ日記

言語技術の有効性 三森ゆりかさん | 女王様のブログ

【0】書店に行くと、ロジカルシンキングや論理的思考の書籍がたくさん並んでいるし、たくさん売れている。
なぜ、そんな本が売れるのだろうか?

「大学生・社会人のための言語技術トレーニング」を読んだ後、たぶん、日本人は小学校から大学まで論理的思考の訓練を習得しないまま就職して、実際のビジネスで数多くの論理的思考を使う場面に遭遇するので、慌てて勉強し直す必要があると感じているから、と思った。

【1】ロジカルシンキングとかクリティカルシンキングとか、色んな本を読んできたけれど、「大学生・社会人のための言語技術トレーニング」を読んで、ようやく、日本語での思考と英語での思考では方法が違うのだ、という事がよく分かった。
もちろん、英語でも日本語でも、言語を使うのだから、論理的な思考を行う方法は双方とも適用できるし、同じ結果も得られる。

しかし、日本語というツールは、その内包する弱点を特に意識しなければ、たぶん、論理的に思考する時に数多くの落とし穴にはまってしまいがちなのだろう、と感じた。

【2】日本語の最大の弱点は、主語なしでも書けること。

【2-1】「私は」「あなたは」「彼が」という言葉を使わなくても、自分の主張を公表できる。
むしろ、日本語では、「私は~と考えます」といつも使っていたら、自己主張が強すぎ、のように思われて、引いてしまう雰囲気になる。

しかし、英語だろうが他の言語では「I think~, because~」という表現は普通だ。
そういう構造が言語に埋め込まれていれば、自然な発言が自己主張につながるし、自分の立場を明確に公表する、という言動につながっていく。

日本の小学校・中学校の国語の試験問題を見ると、「この文章の主語は誰でしょう?」みたいな問題があったりする。
こういう主語探しの問題は、英語ではありえない。

日本の文学では、主語なしの文章で、故意に複数の解釈を埋め込む技法もある。
例えば、川端康成の「雪国」の最初では、トンネルを抜けたら雪だった、という文章の主語を故意に省略し、後で、主人公の発言であったかのようにストーリーが進む。
しかし、こういう文学的技法は、政治やビジネスのように交渉する場面では全く不要。

日本人は自己主張が弱い、という理由は、たぶん、「私は~と思います。理由は~だからです」という文章が日本語の構造として形式的すぎて、日常会話で話すと不自然に感じてしまう、という弱点があるからだろう。
よって、「主張→根拠→結論」という一般の3段階論法を、日本語で自然に話すのが、上手くフィットしない雰囲気を感じてしまうからだろう。

【2-2】「大学生・社会人のための言語技術トレーニング」で興味を惹いた点は、中学生向けのドイツ語の小説で、文章の主語が3人称→1人称→3人称に変遷する時に、読者である中学生がその文章の主人公に意識を挿入しやすいことがある、という指摘。

実は、その小説で男の心理を3人称で語っている文章は、第三者的視点で客観的に語っているのだが、1人称で語っている場面では、男の心の中の動きであり、主観的であり、実は狂気な言動、という仕掛けになっている。
つまり、中学生は、日常生活ではありえない狂気の男性の心の中に入り込むことで、小説内で疑似体験しているわけだ。
そういうテクニックもあるらしい。

【2-3】他の日本語の弱点として、時制がないという点もある。

「大学生・社会人のための言語技術トレーニング」の一節では、ドイツの小説には過去形の文章が続いた後で、現在形の文章に急に変わった場面がある。
実は、過去形の文章は他人事だが、現在形になることで読者がその状況に入り込むことで、小説内で疑似体験するように仕向けている、と言う。

しかし、そういう技法を日本語で翻訳しようとすると、変な日本語になってしまって読みづらい、という事もあるのだろう。

【3】「大学生・社会人のための言語技術トレーニング」で「説明の黄金律」というものが紹介されている。
空間配列、時系列、重要度(度合い)の3つだ。
この考え方をドイツでは小学生低学年から叩き込まれるのに、日本の小学生は国語でも習わない。

【3-1】特に、空間配列(Spacial Order)という考え方を日本人は意識していない。
これは構造の順序そのもの。
説明の順序は、外から内へ、大から小へ流れる。

しかし、日本人のよくある説明は、空間配列の順序で整理して話さないために、あちこちの論点に散在する説明になってしまい、主張や結論が曖昧に聞こえてしまう。

「大学生・社会人のための言語技術トレーニング」では、フランスの国旗の説明で空間配列を説明せよ、という問題があり、良い回答と悪い解答の比較が非常に面白い。

また、「大学生・社会人のための言語技術トレーニング」によれば、絵の分析は、空間配列の考え方の強化に最適らしい。
絵の分析は、事実と意見の違いを明確に区別する訓練にもなるらしい。

たとえば「偉大な物理学者アインシュタイン」という文章では、どこまでが事実で、どれが意見解釈なのか?
それを即座に読み取れるか?

【3-2】空間配列=構造の順序、時系列=時間の順序、重要度=比較の順序。
実はこの考え方は、バーバラ・ミントの名著「考える技術・書く技術―問題解決力を伸ばすピラミッド原則」にも記載されていた。
彼女の本には、この考え方は小学生頃から知っているから、という一節が書かれているが、実は、日本の小学校の国語ではこんな考え方を僕は習って来なかった。
だから、論理的に思考する、論理的に話す、という手法に苦労してきたのかもしれない。

【3-3】「大学生・社会人のための言語技術トレーニング」では、物語の構造についても詳しく説明してくれている。
簡単な具体例は、桃太郎。
物語の構造は、英語であれ日本語であれ、古今東西同じ。

物語の構造は、状況→複雑化→疑問→答え、という流れになる。
しかし、英語圏ではこの物語の構造という考え方を明確に小学生の頃から教わっているのに、日本の小学校では明確に教えられていない。
実は「状況→複雑化→疑問→答え」という考え方は、バーバラ・ミントの名著「考える技術・書く技術―問題解決力を伸ばすピラミッド原則」の最初に記載されている。

「考える技術・書く技術―問題解決力を伸ばすピラミッド原則」では、プレゼンのイントロ部分では、古典的な技術であるストーリー形式(物語形式)で始めると聴衆を引き込みやすい、という一節がある。
その一節で、「状況→複雑化→疑問→答え」という考え方が紹介されていた。

僕が、バーバラ・ミントの名著「考える技術・書く技術―問題解決力を伸ばすピラミッド原則」を最初に読んだ時、とても堅苦しくて読みにくい本だ、どこが名著なのか分からない、と感じていたが、「大学生・社会人のための言語技術トレーニング」を読んで理解した後で読み直すと、なるほど、そういう背景があったのか、とようやく理解することができた。

【4】パラグラフ・ライティングという技法も、日本の国語の授業で習わない。

トピック・センテンス→サポーティング・センテンス→コンクルーディング・センテンスという流れ。
トピックセンテンスには、コントローリングアイデアが必要。

パラグラフ・ライティングには5つのルールがある。
・各段落に話題(テーマ)は一つ。
 →日本語なら、意味段落に相当する。
  「意味段落◆----形式段落」のような構造。
  日本語の文章は、形式段落がむやみに多すぎるので、意味段落にまとめる作業が別途発生する。
  「形式段落を意味段落にまとめよ」という国語の試験問題もあるらしい。

・話題文(トピックセンテンス)は段落の先頭に置く。
・話題文だけで話を成立させる
 →コントローリングアイデアに相当。

・不用意に接続詞を置かない。
・論理を整理しておく。

パラグラフ・ライティングを発展させると、「序論→本論→結論」という学術論文の基本構成になる。
つまり、小学生が習うパラグラフ・ライティングを起点として、10年かけて論理的思考を徹底的に訓練した後、大学生の卒業論文という結果になる。

【4-1】日本人の文書が分かりにくい、と言われる原因のうち、最大の原因は、起承転結のスタイルで書いているからだろう。

起承転結のスタイルでは、前置きが長く、結論が一番最後になるので、すぐに結論を判別できない。
だから、エレベータートークで話すように訓練しろ、と、新人社員はよく言われるわけだ。
日本語の文章は、結論が後回しになりやすい。

他にも原因がある。
一つは、空間配列の技法を習得できていないために、情報を構造として整理できていないこと。
情報を外から内へ、大から小へ、という構造で整理していないので、情報の粒度がバラバラで、論点が分かりづらい。
ちょうど、外部設計から内部設計へ、というソフトウェア設計の考え方と同じ。
いきなり、プログラムの詳細設計レベルの話をされても、そのシステムは結局何ができるのか分からない、という問題と同じ。

もう一つは、日本語特有の論理スタイルが悪いこと。
たとえば、主語なし文章のようなゾンビ文。
時制が曖昧。
形式段落が多すぎて、意味段落としてまとめられていない。

【4-2】日本でオブジェクト指向が普及しなかった、という理由の一つは、オブジェクト指向の日本語の文章が感覚的に変、という事もあるだろう。

「オブジェクトが~する」という文章は、まるでモノが人のように振る舞う点が日本語として感覚的でない。
むしろ日本語としては、「オブジェクトは~される」という受動態で表現する方が感覚的に読みやすい。
つまり、逐次実行的な受動態の文章スタイルの方が、詳細設計の文章は肌感覚で合う。

【4-3】「空間配列・時系列・重要度」という考え方は、チケット管理にも即座に適用できる。

空間配列は、チケットの粒度そのもの。
WBSのように、工程→作業→成果物のように粒度を詳細化していく考え方と同じ。

時系列は、チケット登録日、更新日の順序と同じ。
重要度は、チケットの優先度、チケットの並び順、リリース順、と同じ。

【5】「大学生・社会人のための言語技術トレーニング」では、自分の意見を立証するための構造として「トゥールミンモデル」が紹介されている。
たとえば、絵の分析で、こういう人物が描かれているので、私はこう考えた、と主張する時、その証拠とその論拠を明確にして、主張を支える技法だ。

この技法を発展させると、クリティカルシンキング、クリティカルリーディング、批判的思考につながっていく。

トゥールミンモデルの考え方は、ゴール思考モデル(GSN)につながるし、昨今の自動車業界における機能安全規格の要件適合やシステム適合性にもつながる。
つまり、なぜこの自動運転システムは機能安全といえるのか、という主張を支えるための証拠や論拠を揃えて、論理的に組み立てる必要性があるわけだ。

【6】「大学生・社会人のための言語技術トレーニング」に書かれている素材は、小学生の国語の内容と同じ。
しかし、ロジカルに読む・書く・考えるという技法は、実は日本人は意識していないのかもしれない。
僕自身も明確に意識していなかったので、改めて、理解できた部分は書き残してみた。

| | コメント (0)

より以前の記事一覧