モデリング

2020/11/05

第73回 SEA関西プロセス分科会 「モデルベースシステムズエンジニアリングの活用」 の見所 #seakansai

2020/12/12土の夕方に、SEA関西プロセス分科会 「モデルベースシステムズエンジニアリングの活用」が開催されます。

私も関わっているastah関西コミュニティの高井さんをお招きして、SEA関西にて「モデルベースシステムズエンジニアリングの活用」の講演2本が実現しました。

特に、自動車業界などで組込みソフトウェア開発を担当している技術者やアーキテクトに対し、上流工程におけるモデリング技法並びにモデリングツールを活用した設計技法のお話は参考になると思います。
興味のある方はぜひご参加ください!

講演の見所を少しだけメモ。

【申し込み】
第73回 SEA関西プロセス分科会 「モデルベースシステムズエンジニアリングの活用」 | Peatix

(引用開始・一部入れ替え)
開催日時: 2020年12月12日(土)16:00~18:00

開催形式: オンライン(ZOOM)

講師: 高井 利憲 氏(株式会社チェンジビジョン)

講演1:モデルベースシステムズエンジニアリングにおける形式手法の効果的な活用
 最近のシステム開発では上流工程での検証の必要性が高まっています。
 本講演では、モデルに基づくシステムズエンジニアリングアプローチと形式手法を組み合わせて活用する方法について、自動車分野のシステム開発を例に、ツールによる支援可能性を中心に議論します。

講演2:モデルベースシステムズエンジニアリングにおけるシナリオ生成手法の効果的な活用
 最近のシステム開発においては、シナリオベースの検証や妥当性確認を求められることが多くなってきています。
 本講演では、自動運転車の安全規格の一つであるISO21448(SOTIF)や同じく自動車分野のセキュリティ規格であるISO21434(車両サイバーセキュリティ)を例に、システムズエンジニアリングにおける効果的な実施方法を紹介します。
 講演1と同じ例題モデルを用いることにより、モデルの再利用可能性についても議論します。

本講演1及び2は名古屋大学倉地亮先生とdSpace藤倉俊幸様との共同研究の結果に基づいています。

主催: ソフトウェア技術者協会(SEA)関西支部

プログラム:
 15:30 アクセス受付開始
 16:00 講演1「モデルベースシステムズエンジニアリングにおける形式手法の効果的な活用」
 16:30 質疑応答
 16:45 講演2「モデルベースシステムズエンジニアリングにおけるシナリオ生成手法の効果的な活用」
 17:15 質疑応答・フリーディスカッション
 18:00 閉会

 閉会後、オンラインでの懇親会を持ちたいと思います。
 お時間の許す方は、お好きな飲み物をご用意の上、お気軽にご参加ください。

定員:
 100名
 お申し込み順です.定員になり次第受け付けを締め切ります.

(引用終了)

実は、過去に高井さんの講演や資料を見聞きして、刺激を受けた部分がたくさんある。
一つは、モデリングツールを経由して、開発プロセスと成果物のトレーサビリティを保証する仕組みを作り出すお話は面白かった。

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

ソフトウェア開発に置いて、開発プロセスが重要な理由は、単に手順を標準化して、作業の効率化を図るだけではない。
作業と成果物の間でトレーサビリティを保証することで、プロダクト品質とプロセス品質の両方を保証することだ。
例えば、ソースにバグがあれば、過去の変更履歴からどこでバグが埋め込まれたのか、どんな変更理由や要件の変更があったのか、を探れる。
あるいは、たった一つの仕様変更がどれだけの範囲のソースに影響を及ぼすのか、ということも追跡できるはず。
つまり、作業と成果物のトレーサビリティは、ソフトウェア構成管理に直結する。
ソフトウェア開発では、ソフトウェアの構成管理こそが、開発プロセスの本質ではないか、と思う。
そういう仕組みの実現に、実はastahというモデリングツールが一役買っている、という話が興味深かった。

2つ目は、SysMLというモデリング言語が、組込みソフトウェア開発において、メーカーのプロダクトオーナー、ハードウェア技術者、ソフトウェア技術者、自然科学者の間で、共通のコミュニケーション言語になっている、という講演も面白かった。

第2回astah関西の感想 #astahkansai: プログラマの思索

特に、組込みソフトウェア開発では、ハードウェア技術者が設計したハード機器に対して合うようなソフトウェアを開発するために、ソフトウェア技術者はどうしても弱い立場になりやすい。
そして、ハードの仕様変更や要件の理解不足などで、どうしてもソフトウェアの品質を担保するのは難しい。
その真因には、ハード技術者とソフト技術者の間で、コミュニケーションが不足しているから、ということがあるだろう、と思う。
ハード技術者にも理解してもらうために、UMLではなく、ハードの構造も表現できるSysMLを使うことで、ハード技術者とソフト技術者がSySMLという共通言語で会話できるようになった。
さらに、製品を市場にフィットさせる責任を持つプロダクトオーナーや、ハードに電気・流体・機械などの自然科学の制約を与えるドメインまで、すべての話をSysMLで会話できる。

多様なドメインを持つ製品開発では、こういう人工的なモデリング言語があるからこそ、ソフトウェアも含むハードを開発できるという点が面白い。
つまり、モデリング言語が我々の思考そのものを規定し、効率化させる部分があるわけだ。

今回の講演1本目は、モデルに基づくシステムズエンジニアリングと形式手法を組み合わせて検証する時に、astahというモデリングツールを使った事例を紹介してくれる。
モデリングツールによる検証方法の実装がどれだけ実現性があるのか、興味がある。

講演2本目は、自動運転車の安全規格などについて、システムズエンジニアリングにおける効果的な実施方法の事例を紹介してくれる。
自動車業界は今、ガソリンエンジンから電気自動車に大きく変更しつつある時代なので、こういう機能安全規格をいかにモデリング技法で実現するか、は、色んな観点で興味を引くはず。

最近、「モデルに基づくシステムズエンジニアリング」も読んでとても面白かったので、感想はまた今度書く。


| | コメント (1)

2020/09/28

課題は問題点をひっくり返す表現だけで良い場合もある

問題と課題の違いをメモ。

【参考】
リスクと問題と課題を再考: プログラマの思索

問題と課題の違い【改善活動の基礎講座-カイゼンの基本編:第3章】|カイゼンベース

「問題」と「課題」の違いとは?書き方や解決への対策も紹介 | TRANS.Biz

僕は、課題は問題解決のアクションと捉えていた。
問題は、現状とあるべき姿のギャップから発生した症状のこと。
問題はネガティブな表現、課題はポジティブな表現で書くべき、と考えていた。

しかし、課題は問題点を抽象化したもので書くべき、と言われた時があって混乱した。
その観点では、問題点と課題は同じ現象を少しだけ言い換えているに過ぎないので、問題と課題は同じ意味になってしまう。

そういう意図で聞かれた内容を色々考えあぐねた結果、課題は「問題点を改善すること」と言い換えれば良いと考えた。
つまり、課題は問題解決の具体的なアクションまで書く必要はなく、課題は悪い症状である○○を改善すること、とひっくり返した表現でいいみたいだった。

課題を具体的なアクションで書いてしまうと、レベル感が違うように受け取られるようだ。
あくまでも、抽象的なレベルで、課題は問題点をひっくり返す表現で十分であり、その後で具体的なアクションを書けばいい。


| | コメント (0)

2020/09/02

問題解決アプローチを見極める『クネビンフレームワーク』のメモ

問題解決アプローチを見極める『クネビンフレームワーク』を知ったのでメモ。
結論のないメモ。

【参考1】
akipiiさんはTwitterを使っています 「クネビンフレームワークの説明が参考になった。問題のドメインが時代で変化しているからソフトウェア開発プロセスも変化する。非開発者のためのアジャイル開発入門 by @haradakiro #agile #complex https://t.co/2iCYVDeddY」 / Twitter

More Effective Agile ? “ソフトウェアリーダー”になるための28の道標|かず|note

複雑な世界を捉えるためのカネヴィンフレームワーク(Cynefin Framework) ? ゲームを用いた企業研修なら| 株式会社HEART QUAKE

(引用開始)
カネヴィンフレームワークは1999年にIBM Global Servicesのデイブ・スノーデン(Dave Snowden)らが提唱したもので、状況・問題を大きく4つのドメインに分類するフレームワークです。(上画像)

1.Simple(シンプル):単純
⇒問題の因果関係・構造が明確

2.Complicated(コンプリケーティッド):煩雑
⇒少し分析すれば、因果関係・構造が明確

3.Complex(コンプレックス);複雑
⇒因果関係が複雑、調査・探索が必要

4.Chaotic(カオス):混乱
⇒因果関係が不明確で、状況や問題を理解することも難しい

その他.Disorder(ディスオーダー):無秩序
⇒直面する問題に適切な解決策がない

さらに、1のSimpleと、2のComplicatedを予測可能な問題、3のComplexと、Chaoticを予測不可能な問題と分類することもできます。
(引用終了)

製造業における製品製造の大量生産方式のビジネスと、エンジニアやコンサルタントなどの知的労働者がプロジェクトで仕事するビジネスは、本質的に何かが違うといつも思っていた。
その理由の一つは、問題解決アプローチが全く違う、という指摘を、クネビンフレームワークは教えてくれる。

クネビンについて講演してきました | サーバントワークス株式会社

(引用開始)
(クネビンフレームワークが必要とされる)背景としては、「正解がない」多様化した問題と現実解に対しての理解を深めることが第一義です。第二儀としては、アジャイルの必然性の腹落ち感があります。
(引用終了)

アジャイル開発が昨今必要とされる背景には、従来の問題解決の手法が通用しなくなってきていて、新しいフレームワークや考え方による問題解決手法が必要とされているのだろう。
「More Effective Agile ~“ソフトウェアリーダー"になるための28の道標」では、アジャイル開発による問題解決の観点はクネビンフレームワークの「複雑(Complex)」に当たるのではないか、という内容があるらしいので、今度読んでみたい。

【参考2】
複雑な世界を捉えるためのカネヴィンフレームワーク(Cynefin Framework) ? ゲームを用いた企業研修なら| 株式会社HEART QUAKE

クネビンフレームワーク Cynefin Framework :臨機応変の意思決定手法 ? I & COMPANY / アイ&カンパニー

カネビン・フレームワークで問題解決策を見極める

クネビンフレームワークを使ったテクニカルサポートチームの行動指針の立案 | Developers.IO

問題の解決アプローチを見極める『クネビンフレームワーク』をざっくりまとめる - コード日進月歩

(引用開始)
これをエンジニアのロールに置き換える広木さんのツイートはすごいなと思ったので参考まで
(引用終了)

広木 大地/ エンジニアリング組織論への招待さんはTwitterを使っています 「CTO/VPoE/TechLead(スペシャリスト)の仕事って一体どう言う役割分担なの?みたいなことを聞かれる。 これはクネビンフレームワークで捉えるとわかりやすい CTO は Chaoticな問題 -> Complex VPoE/EMは Complexな問題 -> Complicated TechLeadは Complicatedな問題 -> Simple 不確実性が減っていく https://t.co/un1FX3QQ53」 / Twitter

akipiiさんはTwitterを使っています 「クネビンフレームワークでカオスで複雑・複合的な問題を分類する。CTO/VPoE/TechLeadというエンジニアのロールはクネビンフレームワークで整理すると分かりやすいという指摘。 問題の解決アプローチを見極める『クネビンフレームワーク』をざっくりまとめる - コード日進月歩 https://t.co/exz3rCJnfw」 / Twitter


| | コメント (0)

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)

より以前の記事一覧