astah* ver8.3でハイパーリンクと画像アイコンの機能強化がリリースされた

astah* ver8.3でハイパーリンクと画像アイコンの機能強化がリリースされたのでメモ。
待ち望んでいた機能なので、早速試してみた。

【参考１】
astah* 8.3リリースノート | astah

【参考２】
構造ツリー 　図上へのドラッグ＆ドロップ(2) - ハイパーリンクの作成| astah* 機能ガイド

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

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

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

astahで、ダイアグラム上のモデルに、別のモデルをD&Dすると、相互のモデルにハイパーリンクされるようになった。
この機能を使うと、あるモデル要素をクリックすると別のモデル要素に遷移される。

たとえば、上流工程の業務フローのアクティビティ図、ユースケース図の各モデル要素を実装フェーズのクラス図、シーケンス図へ詳細化した場合、このハイパーリンク機能によって、下位要素へトレースされることになる。
つまり、要件から仕様、実装までの下方追跡をモデリングツール上で実現できたことになる。

たぶんよく使われる要素は、ユースケース図のユースケース→アクティビティ図、アクティビティ図のアクティビティ→ユースケース、ユースケース→クラス図orシーケンス図のような流れだろう。
astahでは、モデル要素のハイパーリンクのアイコンをダブルクリックするだけで遷移される。

一方、実装フェーズのクラス図、シーケンス図から、上流工程の業務フローのユースケース図、アクティビティ図へトレースされることになる。
つまり、実装から要件までの上方追跡をモデリングツール上で実現できたことになる。

astahでは、構造ツリー上のダイアグラムにハイパーリンクのアイコンが表示されるので、ダイアグラムを右クリック＞ハイパーリンク＞モデル要素を選ぶような操作になる。

僕は、要求から実装までの下方追跡、上方追跡の機能は、モデリングツールで非常に重要な機能と考えている。
なぜならば、モデリングしながら、曖昧な要件をQCDの制約の中で実現可能な実装レベルまで詳細化していく時に、こういうトレーサビリティ機能によって、モデルの整合性や実現可能性を思考する必要があるからだ。

こういう試行錯誤しながらモデリングする作業は、できるだけモデリングツールで支援して欲しいと思う。
Excelや紙ベースでモデリングすることもよくあるが、ラフなスケッチではなく、モデリングする思考そのものをより深く、より良いものにするには、トレーサビリティ機能のように本来ツールで支援すべき機能は、モデラーがそこに注力するのではなく、透過的に支援して欲しい。
そうすれば、本来の業務要件のモデリングそのものに注力できる。

僕は、ハイパーリンク機能のように、トレーサビリティ機能はモデラー自身が手作業で追加・編集・削除して、後からそのリンクを辿れる操作で十分だと考えている。

なお、トレーサビリティマップにモデル間の相互ハイパーリンクを表示する機能も考えているらしいので、楽しみにしている。

【参考３】
フローチャート SVGやZIPのアップロード可！| astah* 機能ガイド

astah* 8.3リリースノート SVG形式の画像が使用可能に| astah

astahでAWSインフラ構成図が描ける方法がある: プログラマの思索

ネットワーク図・システム構成図作成に使えるアイコン集 - Qiita

AWS シンプルアイコン - AWS アーキテクチャーセンター | AWS

Network Topology Icons - Doing Business With Cisco - Cisco

astahで、フローチャートのフロー記号に複数の画像ファイルを一括登録できる機能が追加された。
この機能を使えば、例えば、AWSやCiscoのアイコンをastahに全部取り込めば、astah上でインフラ構成図を描くことができるようになる。
昨今、クラウドで開発するのが当たり前になったので、ソースコードのクラス図、シーケンス図だけでなく、インフラ構成図も同じモデリングツールで描けるのはとても心強い。

ただし、若干使い勝手が悪い面もある。
たとえば、複数のAWS画像ファイルを一括取り込みした後、約200個の画像ファイル名が全て「処理」になってしまうので、肝心の画像ファイルが選びにくい。
暫定の対処方法としては、画像ファイル情報が保持されているFlowSymbolTemplate.propertiesで、「element.106.name=EC2」のように画像ファイル名を置換すれば良い。
テキストファイルなので、ファイル名の置換操作が若干面倒だが、それさえ実施すれば、フロー設定で、目的の画像ファイルを選択できるようになる。
ただし、画像ファイル名がソートされていないので選択しづらい。

たぶん、次のバージョンで使い勝手は修正されるだろうと思う。
そうすれば、plantUMLよりもastahでインフラ構成図を描く方が楽になるかもしれない。

CiscoやAWSのアイコンが使えるので、インフラ構成図も論理構成図や物理構成図の両方が使えるのも便利。

いろいろ試してみたい。

組織は記憶能力を持つのか～トランザクティブ・メモリーという概念

「世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」を読んでいて、組織は記憶能力を持っているのか、組織は学習する能力を持つのか、という問いがあった。
内容がとても面白かったのでメモ。

せきねまさひろぐ: 『世界の経営学者はいま何を考えているのか』

「世界の経営学者はいま何を考えているのか」で明かされた9つの意外な事実 | netgeek

【新連載・入山章栄】経営理論は“モヤモヤ”を言語化する武器。｢思考の軸｣をつくる教養を磨け | Business Insider Japan

「世界の経営学者はいま何を考えているのか」書評と要約：旧・本を聴く日々：So-netブログ

トランザクティブ・メモリーとは | 人事のプロを支援する | HRプロ

トランザクティブメモリーとは？組織の知を最大化する方法 | BizHint（ビズヒント）- クラウド活用と生産性向上の専門サイト

トランザクティブ・メモリー・システムとは何か（村瀬俊朗）｜英治出版オンライン

組織のラーニングカーブは存在するのか？
組織は経験から学習するのか？

個人は経験から学習して、個人の能力を高めていく。
人は経験から記憶する。
組織も同じだが、その構造は異なる。

100人がばらばらに学ぶ場合と、100人が一つの組織で学習する場合、組織で得られる知の総量は違うのか？

結果は異なる。
組織は、トランザクティブメモリという、誰が何を知っているのか、という知識を蓄積することで、より多くの専門知識を持つことができる。
つまり、組織内の個人は機能別組織として、その専門性を発揮するが、ばらばらの専門性の知識は、組織内の権限と責任の一致によって、組織内の専門知識に自由にアクセスできる構造を持つ。

組織は、自然に形成されたトランザクティブメモリを持つが、それを新しい組織構造に変換して無理にゆがめると、組織内の軋轢を引き起こし、組織内の記憶力は著しく落ちていく。

このトランザクティブメモリの概念を、ソフトウェア開発に適用するとどのように解釈されるのか？

たとえば、専門性を持つ技術者が集まったチームが生産性を発揮しても、そのチームを一度解体してしまうと、組織の記憶力は低下し、組織の生産性も著しく落ちてしまう。

スクラムではチームを重要視する。
チームはブラックボックスとして扱い、プロジェクトマネージャのマイクロマネジメントは許さない。
チーム内ではメンバーの専門性は最大限発揮できるような環境が提供されている。
つまり、トランザクティブメモリが発揮できるような仕組みをスクラムは開発チームに提供している。
そういうトランザクティブメモリがスクラムチームに自然に埋め込まれているならば、困ったときに、専門性を持つ人に声をかけて支援してもらい、問題解決することが可能になる。

ソフトウェア開発では、長年保守してきたシステムの知見、技術、業務の知識を持つ技術者が非常に重要だ。
そういう属人生を排するような仕組みを組織的に作り出そうと四苦八苦してきたが、むしろ、そういう技術者が能力を最大限発揮できるような仕組みを作り出すほうが重要ではないだろうか？

トランザクティブメモリの豊かな組織では、組織が記憶力を高めて、組織の学習能力を高めてくれる。
ここで、組織の記憶力はあくまでも、専門性を持つ人の情報を共有する点に着目していること。
単に、Wikiで情報共有すればいい、というわけではないのだ。
誰が何を知っているのか、という暗黙知が知のインデックスカードのような役割を果たしている。

トランザクティブメモリのおかげで、知の探索、つまり、試行錯誤しながら新しい知見を蓄積しいていく試みが可能になる。
つまり、アジャイル開発を実践するには、組織にトランザクティブメモリという性質が必須要件なのかもしれない。

「世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」には、ほかにも面白い話がいくつかあるので、その内容も別でメモしておく。

ゆるふわPandasチートシートのリンク

Pandasを色々触っている時に、Pandasのチートシートを見つけたのでメモ。

ゆるふわPandasチートシート - Qiita

pandasのDataFrameのデータ操作をよくわすれるので、よく使用する操作を自分のためにまとめた - Qiita

やっぱり初めてのライブラリを触っている時はAPIを知らないので、そこを一つずつ覚えて使いこなすのが割と面倒。
こういうチートシートがあれば、触りながら感覚を身に付けられる。

経験者になれば、こういうチートシートは全て頭に入っているだろうが、初心者から駆け上がる時にとても役立つ。
ちょうど、英会話で中学生の初歩から英単語を覚えているのと同じ感覚に似てる。

Pandasを使いながら、SQLを代用できないか、R言語だとどれくらい違うのか、色々遊んでみたい。

マインドマップをFreeplaneに乗り換えた

マインドマップFreeMindからFreeplaneに乗り換えた。

Japanese - Freeplane - free mind mapping and knowledge management software

FreeMind Ver0.9が使いやすくなっている: プログラマの思索

FreeMindの応用的な使い方: プログラマの思索

【再考】GanttProjectとFreeMindとJude: プログラマの思索

FreePaneの方がGUIが充実していて、VerUpの頻度も多い。
アイコンも多いので、自由に発想しやすい。

僕にとって、マインドマップはなくてはならないツール。
アウトラインプロセッサの代わりに、アイデアを発散して構造化する時に使っている。
こういうツールがないと、文章は書きにくいと感じる。

最近感じるのは、知的労働者にとって、PC上のアプリの操作の慣れ次第で生産性が大きく違うこと。
道具が思考を促進する。
思考と道具は表裏一体。

この考え方は、モデリングツールでも同じ。
また、IntelliJのようなプログラミング開発ツールでも同じ。

この辺りで考えたことも記録しておく。

増刷記念「ここはウォーターフォール市、アジャイル町」の裏話の感想～日本人はフレームワークが苦手でいつも振り回されている

増刷記念「ここはウォーターフォール市、アジャイル町」-執筆者と編集者と書籍の表側と裏話と- - DevLOVE | DoorkeeperをZoomで聞いていた。
沢渡さんの発言がすごく面白くて、色々連想させられた。
ラフなメモ書き。

【1】日本人はフレームワークがすごく苦手。
ISO9001から、CMMI、DX、SDGｓに至るまで、こういうバズワードに振り回されている。
スクラムも良いアジャイル開発のフレームワークだが、日本人はアジャイル開発は理解できるのに、アジャイル開発のフレームワークを使いこなせているとは到底言えない。

その理由は、フレームワークは問題事象を抽象化した枠組みなので、抽象的思考のまま具体的に考えようとして、本来の目的を忘れてしまうのではないだろうか。
本来は、ISO認証が目的ではなく、品質改善が目的のはずなのに、本来の問題意識を忘れてしまい、いつの間にか手段が目的に変わってしまう。

こういうバズワードが会社の提案書に出てきたら、日本では要注意。
書いた本人も、その提案書を受け入れる経営者もたぶん、フレームワークを使いこなせないので、すぐに目的や問題意識を忘れて、道具を磨くことばかりに注力してしまう。

akipiiさんはTwitterを使っています 「#devlove 日本人は、フレームワークと言う道具が使いこなせない弱点がある。ISO認証もSDGsも、フレームワークに使われるだけで、本来の問題解決にならない。フレームワークに呑まれるな！！」 / Twitter

akipiiさんはTwitterを使っています 「#devlove 日本人はフレームワークに使われてしまうのは、手段が目的化する弱点があるせいだほう。ISO認証、CMMU、スクラム、そしてDX、SDGsまで、全て、日本人は振り回されてる。」 / Twitter
「手段を目的化するのは日本人の病」という記事もあったな。

手段を目的化するのは日本人の病: プログラマの思索
スクラムも開発プロセスのフレームワーク。
フレームワークだからこそ、全てのルールを受け入れることで、こんな問題にはこういうルールや道具が使えるのか、という新しい気づきを毎回得ている。それが面白いのだ、という講演者の言葉に惹かれた。

akipiiさんはTwitterを使っています 「#devlove スクラムはやるたびに、すげーと思う。問題解決のたびにスクラムの道具が使える。スクラムのフレームワークを全部入れると、こういう問題で使うのか、と気づきがある」 / Twitter

フレームワークは抽象化した枠組みなので、あらゆる具体的な事象から抽出した本質を確実に捉えている。
一つのアイデアや理論をいろんな観点で徹底的に分析し、そこから、これが本質なのだ、という一つのメッセージを取り出す。
欧米人の自然科学の本、社会科学の本、歴史学の本を読んでいると、こういう分析が上手いなあ、と思う時がある。
膨大な具体例を述べながら、一つのメッセージを一貫して補強するように論理的に組み立てて説明するのが上手い。

論文作成の技法part1～論文の構造: プログラマの思索

【2】アジャイル、という言葉は現場で使わないでいい。
問題解決にアジャイルの技法を駆使して使って解決して、最後に、今までやったのがアジャイルというものなんだよ、といえばいい。
この言葉にはしびれた。
ちょうど、好きな女の子に手取り足取り尽くして支援して、信頼関係を築いて、最後に振り向いてもらって、最後に好きだったんだよ、という感じ。
違うか。

akipiiさんはTwitterを使っています 「#devlove ウォーターフォールの環境ではアジャイルと言う言葉を使わずに問題解決したい。Issue Drivenが基本であり、問題解決の道具が偶然アジャイルであってゴールを達成したとき、今やった事をアジャイルと言うんだよ、と言ってやりたい。よく分かるなあ」 / Twitter

akipiiさんはTwitterを使っています 「#devlove 問題解決で上手くいってテンションが上がってる時に、実はこれがアジャイルなんだよ、と切り出すと効果的。このテクニックは他にも使えそう」 / Twitter

akipiiさんはTwitterを使っています 「執筆では、沢渡さんはスーパープログラマなので、プロセスや方法論も関係ない。アジャイルは、そういう能力のある人を最大限発揮するプロセスと言うオチかな？　 #devlove」 / Twitter

【3】問題解決に名前をつけよう。
そうすれば、名前のついた問題に対して、周囲の人達と同じ景色を見ることができる。
その言葉に共感できれば、問題解決のファンを増やしていける。
問題会計角ファンがどんどん増えれば、勇気づけられるし、問題解決できるリソースも選択肢も増えるメリットがある。

akipiiさんはTwitterを使っています 「#devlove 半径五メートル以内の問題課題に名前をつけよう。表現するとイメージできて解決に近づく。そして、問題解決のファンを増やすのが大事。同志になるし、動機付けになるので心強い。うん、コミュニティ誕生やコミュニティ運営も同じだ」 / Twitter

【4】執筆には、まず目次を書こう。
目次が書けるならば、その目次から、ストーリーが思い浮かぶはず。
こんな物語にしたいんだ、という思いが出てくる。
そして、決め台詞を入れたい。

この物語には、このフレーズを使いたい、このメッセージを伝えたい、みたいな。
このフレーズを使いたい、という時は、伝えたい内容にフォーカスしている。
このメッセージを伝えたい、と言う時は、そのメッセージに自分の気持が含まれている。

akipiiさんはTwitterを使っています 「執筆で大事なのは、目次を書く事。目次が書ければ、ストーリーに発展できる。自分の体験や知見をそこに埋め込める。 #devlove」 / Twitter

akipiiさんはTwitterを使っています 「目次は先に書くが、このフレーズは使いたい、このメッセージは伝えたい、と言う言葉は事前にメモして、目次に入れ込んでおく。このやり方は真似よう #devlove」 / Twitter

akipiiさんはTwitterを使っています 「#devlove システム運用で誰も読まなかったマニュアルを、ダイアローグ形式にしたら、すぐに広まった経験がある。そういう形式に変えるやり方は面白いな。FAQ方式みたいにするのか」 / Twitter

【5】チケット駆動のいい所は、一体感が出くること。
チケットをキャッチボールみたいにやり取りするうちに、相手はどんな反応をしてくるのか、待つようになってくる。

akipiiさんはTwitterを使っています 「#devlove チケットでやり取りすると一体感が出てくるよね、と。なるほど。」 / Twitter
一体感が出てくるとは、組織論の言葉では、バーナードの組織成立の3要件である「組織の共通目的」が誕生していることだ。
つまり、そこには、単なる人という物体の集まりではなく、心理的関係を持つ組織集団が暗黙的に生まれたわけだ。