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要件である「組織の共通目的」が誕生していることだ。
つまり、そこには、単なる人という物体の集まりではなく、心理的関係を持つ組織集団が暗黙的に生まれたわけだ。

情報はハイパーリンクでつながることで一つの知識体系になる～Scrapbox情報整理術の感想～Scrapboxはカード型のビジュアルWiki

Scrapbox情報整理術の本を読んで、こういうWikiの機能をRedmineにも取りれられられたらいいのにな、と思った。
ラフなメモ書き。

Scrapboxの使い方 - Scrapbox ヘルプ

「Scrapboxはカード型のビジュアルWiki」が言いたいメッセージ。
単なるWikiではなく、入力のしやすさ、使いやすさが埋め込まれている。

Scrapboxの特徴は2つある。
一つは、Tabキーを押しながら、箇条書きで書くのが基本なこと。

文章の基本はやっぱり、アウトラインプロセッサと同じ。
Wordのアウトライン機能のように、詳細なメッセージはツリー構造にする。

また、英語で習うパラグラフ・ライティングと同じ。
Topic sentence、Supporting sentence、Concluding sentenceで1個のメッセージをつくる。

パラグラフライティング　英語レポートの書き方・例文 トピックセンテンスとは？ | 脱中級！　37歳からの英語学習

Scrapboxがいいのは、Web上のWikiなのでスマホやPCで気軽に書けるし、リファクタリングしやすいことだ。
思いついたことをどんどん書いておいて、後で読み直す時に書き直せばいい。

Wikiは「永遠の未完成」でいいのだ。

もう一つは、[]でページリンク、＃でハッシュタグを付けながら、リンク先の未作成のページをどんどん作っていくこと。
たとえば、「[Redmineのチケット管理]」みたいにいったん書いて、後続の文章をどんどん書いていく。
すると、「[Redmineのチケット管理]」のリンクができるが、その先は未作成のWikiなので空っぽ。
後で気づいた時に、そこに、チケット管理の気づきを書き込めばいい。
つまり、リンクしながら文章をリファクタリングしている。

リンク先の空っぽのWikiは用語集みたいなもの。
そこに何かを埋めようと思って書き始めると、自分だけの用語集が出来上がる。

僕は、Scrapboxのリンク機能が上手いなと思った。
ページタイトルは自然にWiki新規ページになるが、タグにもなりうる。
つまり、「#Redmineのチケット管理」と同じなのだ。
思いつきを故意にリンクできるわけだ。

こういう用語集をたくさん作り出すことで、Scrapbox上のページは、ネットワーク構造でフラットな構造として構造化される。

元来、情報整理術は、梅棹 忠夫さんの知的生産の技術以来、日本人の文化人が連綿と引き継いできた。
平成に入る前までは、京大型カードみたいにアナログのカードに穴を開けて、図書館の本の目録を作ったり、研究者が自分のテーマをアナログのカード型データベースで集めて整理したりしていた。
彼らは、集めた情報を畳の上に広げたり、並べたり、ばらすことで、色んな発想を生み出していた。

では、情報整理術はどんな歴史で発展してきたのか？

Scrapbox情報整理術では、情報整理術にはバージョンが3つある。
Ver1.0は、情報はツリー構造で整理する。
情報の粒度で整理できるが、見通しは悪いし、色んな情報をひと目で見にくい。

Ver2.0は、時系列順に整理する。
重要な情報は、LIFO、スタックみたいな構造になっているものだ。
実際、頻繁に取り出される情報ほど上澄みにあり、使われない情報は深海に沈んでいく。
しかし、やはり情報から発想するのが難しい。

Ver3.0は、ハイパーリンクで情報を紐付けること。
これは、Webができたからこそ実現した仕組みだ。
GoogleはPagerankによって、ハイパーリンクの参照度合いで、情報の信用度をランキングすることまでやり遂げた。
ScrapboxやWikiは、情報のハイパーリンク化の産物だ。

では、ハイパーリンクの情報整理術はどんなメリットをもたらしたのか？

一つは、知識はネットワークであること。
情報がハイパーリンクでリンクされることで、一つの情報の連想先が明示される。
それらをたどっていくうちに、色んな情報を手に入れることができる。
つまり、情報はハイパーリンクでつながることで、一つの知識体系になる。

Scrapboxでは、ページリンクやハッシュタグでハイパーリンクが簡単に作れる点が一番のメリットだ。
Scrapboxはハイパーリンクをタグ書きする面倒さをなくしてくれる。

2つ目は、知識は再編され続けること。
Wikiページで書かれた内容は、いつでも編集できる。
間違っていれば直せばいいし、情報が古ければ更新すればいい。
あるいは、別の情報と関係することが分かれば、別のハイパーリンクを付ければいい。
つまり、ハイパーリンクでつながった知識は、常に更新され続ける。

知識はネットワーク構造だからこそ実現できる性質だ。
これは、知識は追加されず固定的な概念である、という一時代前の考え方に対する、一つのパラダイムシフト。

3つ目は、隠れた知識がある事。
哲学者のポランニーは「人は言葉にできるよりも多くの事を知ることができる」と言ったらしいが、まさに、Wikiページタイトルにある一つの言葉は、Wikiページの内容で説明されたたくさんの情報を表している。
同様に、哲学者ソシュールの「記号（言語、知識）とは概念（シニフィエ）と名前（シニフィアン）が表裏一体となって結びついたもの」と同じ意味合いだなと思う。

「人工知能は人間を超えるか ディープラーニングの先にあるもの」の感想: プログラマの思索

機械学習が抱える問題: プログラマの思索

Scrapbox情報整理術では、ここからさらに、野中郁次郎先生のSECIモデルに話を膨らませている。
知識という形式知と暗黙知はお互いに関連しあっていて、そこからさらに色んな情報を想起させてくれるわけだ。

SECIモデルの具体例(Scrum・チケット駆動開発など) from akipii Oga

知識は形式知で死ぬわけではない。
人間は一つの言葉の背後に数多くの暗黙知を持っていて、その時代背景やその一個人の価値観がさらに情報を膨らませていく。
昔使っていた言葉が、時代を経るごとにどんどん変わっていくのと同じ。

Redmineでも、こういう設計思想をWikiの機能に実現できないだろうか？
Wikiのリンクは、Wikiの新規ページタイトルになるのはよいが、どうように、ハッシュタグの機能も追加して欲しい。
そうすれば、自分たちで入力したナレッジのWikiは、自分たちだけの用語集として実現される。
それこそが本来のナレッジ資産であるはず。

VSCodeでDraw.ioが使える記事のリンク

VSCodeでDraw.ioが使える記事のリンクをメモ。

【参考】
VSCodeでDraw.ioが使えるようになったらしい！ - Qiita

draw.ioでAWSのインフラ構成図を書く - Qiita

PlantUMLでAWSのインフラ構成図を描くやり方: プログラマの思索

インフラ構成図やシステム構成図で使えるアイコン集のリンク: プログラマの思索

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

最近、インフラ構成図もエディタとかastahで描きたいと思って、色々探している。
VSCode＋PlantUMLやastahでAWSとかオンプレのサーバー構成図を書けるのは試していた。

VSCodeでDraw.ioが使えるなら、Visioみたいな感覚で何でも書ける。
最近のVSCdeはすごいね。

以前、Redmineパッチ会で、モブプログラミングをVSCodeのLive Shareプラグインでリモートで実現できていたのに驚いた。
レビューイが打ち込んでいるフォーカスやデバッグの画面が全て画面共有できる。

モブプロにVisual Studio Live Shareを使う - Qiita

最近は在宅勤務が当たり前なので、新人教育がやりにくい意見があった。
しかし、リモートでプログラミングのペアプロができるならば、新人プログラマの育成教育でも使える。
ツールが業務をどんどん改善していく。

インフラ構成図もUMLの一種のように書けるならば、単にモデルを情報共有できるだけでなく、そこからモデリング技術の知見も生まれるかもしれない。
いろいろ試してみたい。

第19回東京Redmine勉強会の感想 #redmineT

第19回東京Redmine勉強会に久しぶりに出て楽しかった。
ラフなメモ書き。

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

2020/11/14 第19回勉強会 - redmine.tokyo #redmineT - Togetter

フルリモート開催2回めのredmine.tokyo 日々の悩みと笑いと感動あり #redmineT | マドびっ！ Madosan's View

【1】@g_maedaさんのRedMicaの講演では、細やかな機能改善の紹介があった。
Wikiにテーブル挿入ボタン、Ctrol＋Enterでフォームサブミット、ユーザマスタCSVインポート機能など。

akipiiさんはTwitterを使っています 「#redmineT　2要素認証の機能追加に伴い、ユーザリストCSVの項目追加、メール送信のドメイン制御などセキュリティ面の配慮がなされている。」 / Twitter

セキュリティ面の機能強化に意識されているのはいいね。

【2】2本のパネルディスカッションは面白かった。
各パネラーの体験談を元にした失敗談、成功談をショートストーリーで紹介し、それを他のパネラーが突っ込む。
そういう意見が出るのか、脱線した話もあっていい感じ。

【2-1】話を聞いていると、ツールでプロセスを実装するか、目的のあるプロセスをツールにフィットさせて実装するか、という議論がごちゃ混ぜで面白い。
@saitoさんと話ししていると、やっぱり僕も、やりたいプロセスが既にイメージできていて、そのプロセスをツールに当てはめて、ツールの設計思想に上手く組み込む感じ。
一方、ツールを使いながら、ああ、こういう機能はこういう時に使うのか、こういう時に役立つのか、と気づく時もある。
しかし、最初はスモールスタートで運用し始めていくと上手く行っても、他チームが相乗りしてどんどんRedmineが複雑化してコントロールしにくくなる話もあったな。

(1) akipiiさんはTwitterを使っています 「Redmineの話ではなく、社内のプロセス改善の話になってる。ツールにプロセスを乗せるか、プロセスにツールを合わせるか、どちらも混じって面白い。　#redmineT」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT ユーザディスカッションは、@saito0119 さんと2人で盛り上がる。Redmine の思想は分かって欲しい。トラッカーはチケット種別ではなく、ワークフロー管理が基本、は同意見。プロセスありきで設計しないと後で混乱するから。」 / Twitter

齋藤さんはTwitterを使っています 「@akipii プログラマって、アプリに納得できるかどうかは、設計思想で決まると思ってます。redmine の設計思想が理解できると、後は簡単な気がする。 #redmineT」 / Twitter

【2-2】心理的安全性のテーマはよく出る。
チケット駆動では、メンバーが自発的に登録して、タスクを他人に振って、自分でクローズする運用でないと効果的にならない。
しかし、日本の現場では、派遣契約や外部委託などの契約のために、上からの指示になり、変な忖度をしがち。
おそらく、心理的安全性が日本で盛り上がるのは、上意下達の組織に慣れすぎてしまって、自分からリーダーシップを発揮する訓練が不足しているのだろうと思う。

【2-3】TeamsとRedmineの話も個人的にはとてもヒットした。
GSuiteからTeamsに変わって、とても便利。
Teamsでチャットもできて、TV会議もできて、Googleドライブみたいにファイル管理できるし、Plannerでちょっとしたカンバンもあるし、SharepointでWikiみたいに使えるし、何でもできる。
すると、チーム内のコミュニケーションは全てTeamsでカバーできる。
しかし、課題管理やタスク管理はTeamsでは辛いので、Redmineを使いたくなる。

akipiiさんはTwitterを使っています 「#redmineT Teamsを使ってると、簡単なカンバンはPlanner、テレビ会議も2人だけのチャネルもあり。ExcelファイルやOneNoteもTeamsでGoogle ドライブみたいに共有できるし、Sharepointにもアクセスできて、確かに便利。」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT ただし、課題や日々のタスクはTeamsでは管理しにくい。当たり前だがRedmine の方が一括管理できて、履歴が残るので、やりやすい。他事例で、TeamsのPlannerとRedmine チケットをリンクさせてストーリーカードとタスクカードで運用してる話もあった」 / Twitter

チャットを使うことで、Redmineのチケットのコメントがきれいになった、というメリットは同意する。
コメントは掲示板みたいな機能かなと思うが、もっとリアルタイムに速くやり取りしたい時に、チケットのコメントは遅い気がする。

akipiiさんはTwitterを使っています 「これをメリットと思うかデメリットと思うか。コメントは掲示板みたいな機能だった。RT @juno_nishizaki: チャットが使えるようになってからチケットの注記に書くにはノイジーだなって思うような会話をチャットに移せるようになったのでチケットがスッキリするようになったかと感じています #redmineT」 / Twitter

Teamsでこれだけコミュニケーションができると、正直、メールは仕方ないから使っているだけ。
メールはFaxと同じレベル。いい意味でも悪い意味でも。

akipiiさんはTwitterを使っています 「“@saito0119 さん曰く、メールは仕方ないから使ってますよね。メールはFAXと同じですね。本当に同感。 #redmineT」 / Twitter

【2-4】@satioさんと話していて面白かったのは、リモートワークになって、新人や若手が苦労しているね、という話。
オフラインでOJTができないので、初めての設計、レビュー、プログラミングのデバッグなどがやりにくいらしい。
すると、困ったことを誰にも話せず、自分一人で困っていて、何も成果を出せない結果になりがち。
だから、頻繁なコミュニケーションを取りながら、逐一フォローできる仕組みや環境が必要みたい。
つまり、経験者だけでなく新人ですら、成果主義が求められている。
僕は会社から教育された経験がないので、自分一人で勉強してスキルを身に着けていくべきでは？と思っている。

akipiiさんはTwitterを使っています 「リモートワークでRedmineでタスク管理を強制導入しでて、リーダーは馴染めなくていつの間にか異動で消えた、なんてリアルすぎる笑。　　　#redmineT」 / Twitter

【2-5】Redmineでは、通知メールよりも活動タブをもっと使うべきだ、という意見は、ツイートでも賛成意見が多かった。
詳細が知りたいのではなく、PJの活発度合いを見たいのだ。

(1) akipiiさんはTwitterを使っています 「#redmineT 活動タブでなく、活躍！タブか？」 / Twitter

一方、PMOは特定の複数PJを全部見たい時があるが、活動タブでも親PJで全てのPJの活動履歴を見るしかない、みたいな意見もあった。
この辺りは、活動タブのフィルタリング機能だけでなく、プロジェクト階層構造など色々工夫が必要な感じ。

akipiiさんはTwitterを使っています 「活動タブが通知メールよりいいね、と議論が活発。ただし複数プロジェクト全般で見る管理者は、こまる時があった。特定プロジェクトだけ見る時は良かった。 #redmineT」 / Twitter

【2-6】また、ガントチャートのWBSチケットとチケット駆動のチケットは粒度が違うので、いつもミスマッチが発生してトラブルが起きる。

あいちゃん2号の代理人さんはTwitterを使っています 「だけど、 ガントチャートを描くのって、 結構難しいと思う。 いかに仕事の全体像と、 チーム力が試される。 #redmineT #redmine」 / Twitter

akipiiさんはTwitterを使っています 「#redminet ガントチャートのタスクの粒度と、チケット駆動のチケットの粒度はミスマッチな点に問題があると思います。ガントチャートは荒すぎて、毎日見ても、進捗が進んでないように見えてイライラする」 / Twitter

【2-7】RedmineのUIが機能改善されるのを見ていると、メンバーがもっと楽しく使えるような機能が欲しいと思ってくる。
どうしても、Redmineは管理ツールなので、管理者の観点で使ってしまいがち。
しかし、本来は、メンバーが自由に自分たちのために使って欲しい。
そういう時に、感謝の気持ちや同意する気持ちを簡単に表明できる機能が欲しい。

FacebookやTwitterはそういう機能が上手だし、Teamsでも、いいねアイコンが6個ぐらい追加されて、微妙なニュアンスが表現できるようになった。
ちょっとした機能に過ぎないだろうが、メンバーの貢献意欲を引き出し、PJのゴールに向けて一致団結していく雰囲気を醸し出す機能が欲しいのだ。

akipiiさんはTwitterを使っています 「#redmineT Redmine にメンバーの意欲を盛り上げる機能が欲しい。いいねボタン、GoodJobボタン、GitHubの草、とか、もっとあるはず。大した機能でないけど、楽しく運用したい」 / Twitter

【3】LTも個性的な講演ばかり。

Planioはカンバン機能もあるのは知っていたが、サポート用メルアドが既にあり、サポートデスクの機能は便利だな、と思った。

akipiiさんはTwitterを使っています 「#redmineT planioのサポートデスク機能は、メールによるチケット登録機能を使ってるわけか。なるほど。」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT planioでタスク管理、作業時間管理、サポートデスク、リポジトリなどを使って、便利に使ってる。確か、アジャイルのタスクカンバンもありましたね」 / Twitter

しんやさんのLTは、アンチパターンのお話。
2017年にリツイートした人だったのですね。
最後は退職をチケットに書いた、というオチ。
誰が承認するの、完了にするの、却下できるの？みたいな議論があった笑。

akipiiさんはTwitterを使っています 「面白すぎる。RT @NAGAYASU_Shinya: Redmineにて塩漬けチケットがしぬほどある部署にいたとき、ついカッとなってここ1ヶ月更新のないチケットを一気に却下にしたったことある ……すごい怒られた、そして別に業務になんの支障もなかった。」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT アンチパターン。全員チケット全員ウォッチャー。通知メールが数千件？も届く！怖い」 / Twitter

JAXA木元さんのLTでは、親子チケットのアンチパターンの話があった。
確かに、親子チケットが使える場面は、WBSのようにあまり変化しないケースの方が向いている。
ツリー構造よりも、関連チケットで表現したい時が多くなる。

akipiiさんはTwitterを使っています 「JAXA木元さんの話。親子チケットでこうぞを見える化したいブームがあったが合わなかった。WBSのようにキッチリしたケースは良いが、課題管理のように関連チケットや親子チケットが混じるとエラーが出てフラストレーションが溜まる。 #redmineT」 / Twitter

Nishizakiさんが、Redmineの設計情報をまとめたいという心意気は同意する。
Redmineの設計思想は僕はとても優れていると思う。
オープンソースで10年以上も存続できて、RubyやRailsの激しいVerUpに耐えながら品質を保ってきたのはすごいと思う。
しかし、外部接続のAPI一覧やデータベースの知見などがもっと欲しい。
そういう設計思想を手動でWikiで集めるのも良いし、SwagarAPIみたいに、APIの仕様書とテスト環境を一緒に作ってしまう、とか、色々やり方があるので実現できるといいなと思う。

奈良さんの話では、複数のRedmineサーバーを建てる場合、マスターのRedmineサーバーにあるユーザ・グループなどの基本マスタをセカンダリーの他Redmineサーバーに同期させるやり方を紹介していた。
今はPoC段階です、と言っていたが、このやり方であれば、LDAPのユーザ情報だけ管理できれば、PJ等のその他のマスタは各Redmineインスタンスで自由に使ってもらえれば良い。

akipiiさんはTwitterを使っています 「#redmineT Redmine サーバーのマスターのユーザ、グループなどをセカンダリーのRedmine サーバーに同期させる運用のお話し。確かにこれなら、複数インスタンス管理は楽になりそう」 / Twitter

【4】Redmine勉強会のスタッフとして10年関わっているが、Redmineの面白さを改めて痛感した。
Redmineの面白さは、PJ管理や開発プロセスの実装というソフトウェア工学の観点、そして、Redmineの複数インスタンス制御とかRedmineのデータベース設計などのPJ管理ツールの開発基盤の観点の2つが議論できること。

だから、PJ管理などのマネジメントの話ばかりしていると飽きてしまうけど、飽きたら、Railsやデータベース設計、インフラ構築などの技術の話に行ってもいい。

僕のイメージでは、ソフトウェア工学の話をしている時はサイエンティスト、開発基板の話をしている時はエンジニアの気持ちになっている。
サイエンティストはあるべき姿の理想を延々と話すが現実は違うし、その理想を実装すると、性悪説に基づくPJ管理ツールになってしまう。
一方、エンジニアは、あるべき姿の理想を仕様に落とした時、現在の技術の範疇でどこまで実装できるか、技術や品質・コスト・納期のトレードオフを考えて、現実的な解を出す。
自分の中に2つの人格があって、心の中でお互いに議論しあって、衝突した結果、全く別のアイデアが生まれたりするのが楽しい。

「製造業アジャイル、静岡での実践！」を聞いてRedmineはコミュニケーション管理ツールなのだと気づいた #devlove #静岡ギルド

今夜行われた「製造業アジャイル、静岡での実践！」を聞いてRedmineはコミュニケーション管理ツールなのだと気づいた。
ラフなメモ書き。

【参考】
静岡ギルド(準備中)勉強会「製造業アジャイル、静岡での実践！」 - DevLOVE | Doorkeeper

詳細は上記ページの通り。
1回目は、POもSMも開発チームもScrumの初心者だった。
やる気はあったが、やはり色んなトラブルが出て、POや開発チームのコミュニケーションも悪くなり、進捗遅延で増員されるたびに開発案件がどんどん膨らんでしまう。
最後に、SMの役割を果たせず、案件から抜けてしまう。

再起を期した2回目はいろんな工夫をした。
その話を聞くと、ポイントは2つあると思う。
それは、組織構造と組織文化の２つ。

組織構造の面では、POを2人体制にしたり、開発チームに進捗報告担当のトラッカーを立てたり、SMも時には開発に入ったり課題管理に直接関わったりしたこと。
Scrumの本来の姿ではないかもしれないが、各人の役割と責任に対し、権限と責任が一致できていないならば、補佐を立てて強化したり、あるいは自ら作業に加わったりする。
目的は、Scrumを運用することではなく、開発案件を成功させることなのだから。

組織文化の面では、TeamsでPOと開発者が頻繁にコミュニケーションする。
コメントに、いいねやハートのアイコンをつけることで、ちょっとしたニュアンスを伝えられた。
TeamsのPlannerでPBIを書いて5つのステータス（ToDo、Ready、Doing、Reviewing、Done）でかんばん風に管理したり、TeamsのPlannerで書き足りない内容はRedmineのチケットに詳しい仕様や課題を管理し、Sprint計画はRedmine上でロードマップ画面を使った。
スプリントレビューのデモでは、Teamsのカメラ機能を使って、実際にスマホアプリの動作をステークホルダーに見せて、その場でフィードバックをもらえた。

最初は、TeamsのPlannerでストーリーカードをかんばん風に管理して、詳細化したタスクカードをRedmineのチケット管理で実現したと思っていたが、TeamsのPlannerにはたくさんの情報を書き込みできないなどの不便があったので、Plannerはステータス管理に注力し、Redmineチケットのリンクを書いておいて、課題や状況の管理はRedmineで行っていたらしい。
後で、Redmineのチケットパネルプラグインを入れたら、親チケットはチケットパネル機能でかんばんで管理し、詳細なタスク管理は子チケットで管理するといいのでは、と提案してみた。

そんな話を聞くと、RedmineやTeamsはコミュニケーション管理ツールなのだと感じた。
ガチガチの進捗管理をツールで実現するのはすぐに可能だが、実際はそう簡単には回らない。
一方で、チーム内のコミュニケーションを活性化するには、POやメンバー同士の信頼関係が前提条件だ。
そのために、デイリースクラムではSMはメンバーに進捗遅延を責めることはしないし、POは開発メンバーに見積もりが多すぎるのではとあえて口を挟む権限を付与したりする。
つまり、お互いに本音で言い合える関係をツールで実現することが重要だと感じた。

もちろん、ツールさえあれば開発案件が成功するわけではない。
自分の経験を振り返ってみると、結局は、ソフトウェア開発案件は開発者とリーダーの能力にすごく依存する。
開発者とリーダーの能力を最大限に発揮するには、プロジェクトの体制図という組織構造で権限と責任を明確にし、権限と責任を一致させて、各メンバーの意思決定を迅速させることが重要だし、メンバー全員が最終ゴールを認識していて、その実現のために目標達成意欲を高揚させる雰囲気作りが大事だ。
そして、コミュニケーションを円滑に進める基盤として、RedmineやTeamsのようなツールがあるわけだ。

組織構造を整える部分は、プロジェクトの体制図を決める時に決まるから、おそらくプロジェクトの立ち上げ時に既に決まっている。
組織文化を整備する部分も、RedmineやTeamsを事前に整備しておく必要があるから、プロジェクトの立ち上げ時に既に決まっている。
そんなことを考えていると、Scrum云々というよりも、プロジェクトマネジメントという基盤の考え方が使えるのかな、と思ったりもした。

「Linuxで動かしながら学ぶTCP/IPネットワーク入門」のリンク

「Linuxで動かしながら学ぶTCP/IPネットワーク入門」が割と良かったのでリンクをメモ。

【参考】

「Linuxで動かしながら学ぶTCP/IPネットワーク入門」という本を書きました - CUBE SUGAR CONTAINER

『Linuxで動かしながら学ぶTCP/IP入門』でネットワークを実践しながら理解できた（Docker環境つき） - Qiita

「Linuxで動かしながら学ぶTCP/IPネットワーク入門」を読みました - くじらにっき++

Cisco機器を自分で買って構築するほどでもないし、AWSでサービスを組み合わせて構築するにはまだ知識が足りない。
「Linuxで動かしながら学ぶTCP/IPネットワーク入門」を読みながら、Linux上の仮想ネットワークなら色々試せると思った。

著者のブログで下記の言葉に惹かれた。
プロはたくさんの失敗を経験しているからこそ、初心者がつまずきやすい部分に気づきやすい。

（引用開始）
私の好きな言葉のひとつに「特定の分野におけるプロフェッショナルとは、その分野でひととおりの失敗を経験した人のことをいう」という言葉があります。
ぜひ、この本を使って、たくさん失敗できる環境を手にしていただければ幸いです。
（引用終了）

手段を目的化するのは日本人の病

「手段を目的化するのは日本人の病」という言葉にすごく惹かれたので、メモ。
ラフなメモ。

【参考】
「手段を目的化するのは日本人の病」元最強の会社員・田端信太郎が語る“会社で働く”意味 20’s type - 転職type

(引用開始)
僕は会社って乗り物みたいなもので、会社選びは交通手段を選ぶのに似ていると思っています。目的地を定めて、そこまで最短で行くなら新幹線や飛行機を使えばいいし、寄り道しながら行くならレンタカーが適しているかもしれない。

僕は自分一人では行きにくいところに連れていってもらうための手段として、ある程度まで新幹線で行き、目的地に近づいたらレンタカーを借りて自分の思うように進むような組み合わせが一番いいと思って、昨年末に会社を辞めて独立しました。

とはいえ、今はレンタカーで自由気ままに楽しんでいるけれど、遠方に行きたくなったらまた電車に乗るでしょう。結局はその時々に何がしたいかですよね。

要は自分のゴールと行き先が一致している限りは乗っていればいいし、そうじゃなくなったら降りればいいわけです。例えば東京から奈良に行くのに、新大阪までは新幹線に乗るとする。その時に、乗り心地がいいからって新大阪で降りない奴はバカでしょ？

忘れてはいけないのは、乗ること自体は手段だということ。「なんとなく乗り心地が良いと聞いたから」って動機で就活している人が多いけど、乗ることが目的になってしまうのは寂しいと思うんですよ。それこそコロナショックで在宅勤務になって、グリーン席に座れなくなった人もいるわけだし。

手段が目的化しがちなのは、就活に限らず、日本人の病。就職が全てではなくなり、選ぶのはより難しくなったけれど、本質は「どこに行きたいか」であることは変わりません。それだけは忘れずにいてほしいなと思いますね。
(引用終了)

戦略家ポーターも、日本人経営者には経営戦略の思考がない、みたいな意見があったな。
ソフトウェア開発のプロセス改善、製造業のQCサークルなどを振り返ると、日本人は現場のプロセス改善が大好きだし、すごく向いている。
全体最適よりも、現場での局所最適の方が正確的に向いているのかも。

「選択と集中」による経営戦略は何となく日本企業に向いていない気もする。
むしろ、自社の強みをベースに、既存ドメインの事業を横展開しながら事業を広げてチャンスを伺うという多角化戦略の方が、日本企業の経営戦略に向いているのかもしれない。

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

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

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

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

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

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

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

開催形式：　オンライン（ZOOM）

講師：　高井 利憲 氏（株式会社チェンジビジョン）

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

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

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

主催：　ソフトウェア技術者協会（SEA）関西支部

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

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

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

（引用終了）

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

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

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

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

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

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

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

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

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

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

テスト管理ツールに必要とされる機能要件は、欧米と日本で異なるのではないか

テスト管理ツールに必要とされる機能要件は欧米と日本で異なるのではないかという記事を見つけたのでメモ。

【参考】
欧米のテスト管理ツールとCATにおける、要求の違いについて - CAT Tech Blog

TestLink利用に際して参考になるブログ - misc.log

テスト工程の管理をするツール、TestLinkについて - Qiita

脱Excel！ TestLinkでアジャイルにテストをする (1/6)：エンジニアがお薦めする 現場で使えるツール10選（5） - ＠IT

テストを育てるためにテスト管理ツール「TestRail」を使ってみた | 「世界」旅と子育てを愛するアジャイルコーチのブログ

ちょっと今、テスト管理ツールをもう一度調べている。
10年前はTestLinkを使っていて、それなりにテスト管理の技法は研究していた。
しかし、TestLinkそのものに不満が色々あって、結局使わなくなってしまった。

とはいえ、テスト管理をExcelでやるのは時代遅れ。
テスト管理のように、数千～数万のテストケースの予実管理を行う管理作業こそ、ツールで自動化すべきだ。
なのに、なぜ、特に日本では、テスト管理の重要性は知っているにも関わらず、テスト管理ツールが普及しないのか？

上記の記事では、欧米と日本では、品質に関するリスク管理の観点が異なるからではないか、と指摘している。
欧米では、シェア確保と先行者優位を優先するので、品質よりも市場投入のタイミングを重視する。
よって、品質よりリリースタイミングを優先し、バグがあれば機能制限を設けたりする。

一方、日本では、リリースタイミングよりも、予定されていた機能の品質が担保できていることを重視している。
なぜなら、いくら機能が良くても品質が悪ければ、クレームの嵐になり、ブランド価値が毀損されるからだ。
つまり、日本では、製品の機能と品質は表裏一体とみなす。

この違いから生じる、テスト管理ツールへの要件は何か？
欧米では、重要な利用シーン（ストーリー）をベースに品質を評価する。
よって、ストーリー（シナリオ）を分割し、テストケースのタイトルにStep1、Step2の順に確認項目を記載し、テストを実行していくGUIになる。

一方、日本では、機能テストをベースに品質を評価し、全項目で一定の品質を確保する必要がある。
よって、全ての機能を網羅したテスト仕様書がまず準備されて、各テスト項目はかなり詳細に手順や確認項目を書き込み、1つずつ潰していく。

上記記事にあるTestLinkのテストケース編集画面と、CATのテストケース編集画面の違いが面白い。
TestLinkでは、テストケースのタイトルがツリー構造で表示され、その一つを選ぶとポップアップされ、テストケースを編集する。
一方、CATでは、テストケース編集画面はExcelの表形式と全く同じ。

確かに、TestLink、あるいはTestRailsでも、テストケースのタイトルが一覧表示されていて、その詳細はポップアップで編集するイメージだ。
なぜなら、ストーリーベースなので、テストケースの詳細を見なくても、業務のストーリーを元に、その手順を踏めばいい。
テストケースをグルーピングする機能の方が重要だ。
つまり、欧米のテスト管理ツールでは、テストケースの粒度は荒い。

一方、日本のテスト管理では、機能ベースで全てのテストケースを網羅すべきというプレッシャーがあるので、テストケースの粒度はかなり細かい。
テストケースをテスト観点のカテゴリで分ける方が大事だ。
ゆえに、テスト管理ツールでテストを実行する場合、テストケースの詳細をじっくり読み込まないと、テスターはテストできないだろう。

おそらく、日本のテスト管理では、テストケースをグルーピングする機能よりも、テストケースにハッシュタグを付ける、とか、ツリー構造で階層化する機能の方が重要なように思える。
なぜなら、機能ベースのテストケースでは、グルーピング機能を強化しても、ツリー構造が深くなるので、肝心のテストケースを表示させるためのUIの導線が複雑になりやすいからだ。

TestLinkは個人的には好きだったが、テストケースの元ネタとなるテスト仕様書はExcelで作りこんでTestLinkにインポートしたり、テストケースを一括編集する時はTestLinkからExcel出力した後でExcel上で一括編集して再度TestLinkに取り込む、などの作業をしていたのを思い出した。
つまり、TestLinkというテスト管理ツール上でそういう作業はやりにくかったのだ。
すなわち、日本では品質を担保するためのテスト管理の概念が違う点が、根本原因にあったのだろう。

テスト管理ツールの利用、という古くて新しい問題については今後も色々考える。

Redmine の画面を2ペイン化する～Redmineを発散系のナレッジ基盤にするためには何が必要なのか

Redmine の画面を2ペイン化するツイートが流れていたのでメモ。

【参考１】
redmine-view-customize-scripts/2-pane_issue_list.md at master ・ sk-ys/redmine-view-customize-scripts

（引用開始）
説明
対象の画面を2ペイン化し，対象の画面とチケット詳細を1画面内に同時に表示します．
これにより，対象の画面を確認しながら，チケット詳細の確認と編集が可能になります．
また，チケット詳細画面で行った変更は都度対象の画面に反映されます．
現在，チケット一覧画面，ガントチャート画面に対応しています．
（引用終了）

【参考２】
YasakuさんはTwitterを使っています 「Redmine のチケット画面をリストとチケット詳細の2ペインにしたら判りやすいだろうか．公式のフォーラムにもあるが，特に発展している様子は無い様だ． https://t.co/VMcNAnHcLW https://t.co/7MRbUzjYZV」 / Twitter

YasakuさんはTwitterを使っています 「Redmine のチケット一覧画面2ペイン化を応用してガントチャートでも2ペイン化出来そう．ガントチャートはページ読み込み後に Javascript で色々描画されている事がわかった．勉強になった． https://t.co/xQniqJTnB0」 / Twitter

YasakuさんはTwitterを使っています 「改めて以下に公開．少し無理矢理感があり，更新処理時にテーブルをほぼ丸ごとJSで書き換えているため，他プラグインやテーマとの相性は要確認．パスのパターンの設定で，リストのみへの適用も可能です． https://t.co/Hd0i7CLDn2」 / Twitter

YasakuさんはTwitterを使っています 「通知バーに閉じるボタンを追加．2-Pane Mode と組み合わせると良い感じ． https://t.co/jsTn3WxjGW https://t.co/xapX7MMLFW」 / Twitter

YasakuさんはTwitterを使っています 「境界を強調させ，色々修正した．サイドバー関連の動作が安定した...と思う． https://t.co/6vxBJD4V0I https://t.co/tuJFSzVVoD」 / Twitter

YasakuさんはTwitterを使っています 「View customize plugin を使用した Redmine チケット一覧画面の2ペイン化．色々と考えていたらコードが長くなってしまった．何とかIEに対応した．ここまでするとプラグイン化した方が良いのだろうか． https://t.co/Hd0i7CLDn2 https://t.co/0TgXWcnIaP」 / Twitter

Redmineのチケット一覧画面やガントチャート画面の下部に、チケット画面も表示して２ペイン化する。
裏では、他プラグインとview-customize-scriptsを使っているらしい。

２ペイン化したい場面としては、大きなディスプレイ画面で、一覧とリンクした詳細情報の２つを表示したい時だろう。
最近のスマホやブラウザのUIを見ても、画面上部は詳細な記事があり、画面下部には被写体の画像や広告がスライドショーのように流れるようなパターンもある。
その方が、一つのモニタで大量の情報を即座に見ることもできる。

２ペイン化して一覧と詳細の情報を表示するツイートを見て、ふと、Scrapboxを思い出した。
Scrapboxでは、１ページに書いた記事は、一覧では並列に全てが表示される。
最初にScrapboxを見た時は、何かゴチャゴチャしているな、と思ったが、実は、タグやリンクによってページを絞り込み検索できるし、数多くの記事を時系列に眺めるだけで、色々なアイデアを連想するきっかけにもなる。
つまり、ツリー構造にこだわらず、ネットワーク構造で情報を配置することで、複数の既知の情報を組み合わせるだけで、色んなアイデアや発想が生まれる時も多い。

名著「アイデアのつくり方」には、「アイデアは新しい組み合わせである」という一節がある。
アイデアは何もない所から生まれるのではなく、既知のアイデアを組み合わせるだけで、今までにない常識に囚われない発想が生まれる。
他にも「新しいアイデアは古いアイデアを新しい場所に置いただけ」みたいな言葉もあったな。

２ペイン化を発展させて、チケットをタスクボードのように並べるだけでも、このチケットはあのチケットと関係していないか、などと気づきが得られるかもしれない。
そこから、メンバー同士でいろんな議論ができるかもしれない。

Redmineは単なるチケット集計ツールではなく、蓄積したデータを元に、アイデアを生み出すナレッジ基盤にもなりうるはずだ。
そういう発散系のナレッジ基盤になるにはRedmineには何が必要なのか、今一度考えてみたい。