Redmineを受け入れて貰うためのプラグイン紹介の記事が素晴らしい

Redmineを受け入れて貰うためのプラグイン紹介の記事が素晴らしいのでメモ。
WF型開発に固執した古い体質の現場で、Redmineをいかに使いやすくするか、という観点で読むと、とても参考になる。

【参考】
Redmineを受け入れて貰うためのプラグイン紹介 - Qiita

親チケットの詳細ページに表示される子チケットの一覧項目 - Google グループ

【1】(引用開始)
Redmineは小規模なチームでも比較的簡単に導入できる、素晴らしいソフトウェアだと思います。
ただ、このようなツールを知らない人や絶対Excelマン達にとっては、得体の知れない面倒なモノと思われてしまうこともあります。
そういった人たちにも積極的に利用して貰うためには、日々の業務で感じるイライラを極力減らす努力が必要ではないでしょうか。
この記事では、Redmineを少しでも快適に使って貰うため、開発者にとって有用なプラグインを紹介していきます。
以下は中の人の背景です。

Redmine 3.1.2～3.3.2
運用を始めて1年ちょっと
WBSっぽく運用すべく親子チケットをがんがん使う

対象プロジェクトの性質
保守
ウォーターフォール
古い体質
(引用終了)

最近は、Redmineが良さそう、という話を聞いて導入し始める人達が多い。
しかし、WF型開発に固執した古い体質の現場では、RedmineをBTSとして扱うだけでも、アレルギーを起こす人たちもいて、導入に苦労する時が多い。
では、そういう古い体質の現場で、導入のボトルネックになる部分はどこなのか？

【2】個人的には、ボトルネックになる部分はUIの部分ではないか、と思う。

WF型開発に固執した古い体質の人達であっても、障害管理や課題管理の重要性は分かっている。
そして、自分なりのやり方も持っている。

だが、ExcelやMSProjectに慣れすぎているために、そういう使い方ができないとイライラしてしまうのだろう、と思う。
だから、BTSを使おうとしても、結局はExcelに出力してExcelで管理を周囲に強制していまいがち。

こういう問題点は、おそらく他の業務システムでもよく出てくる。
ERP、SFA、原価管理システムなどでも、データを入力すれば、後は自動的に集計してくれるのは便利。
しかし、そのデータを出力してカスタマイズしたい、とか、もう少し見やすくして欲しい、とか、細かな要望は数多く出てくる。
結局、ExeclのようなUIが欲しいのだ。

だから、ERPのような業務システムでは、Excelライク、Windowsライクなデスクトップ上のクライアントアプリが重宝される。

では、どうやれば解決できるのか？

【3】一つの対策としては、上記のように、Redmineのプラグインを導入して、ExcelライクなUIや入力を促すような通知機能を機能追加してみることだろう。

【3-1】上記の記事の紹介プラグインで思うことはいくつかある。
一つは、親子チケットに関する機能改善が多いこと。

MSProjectでガントチャートをバリバリ使う人ほど、Redmnieの親子チケットを多用する。
従来の管理イメージをそのままチケットに表現できるからだ。
しかも、Redmineでは、チケットの階層は無制限なので、いくらでも深く作れるので、すぐに慣れる。

しかし、いくらRedmineの親子チケットが良いと言っても、従来のExcelやMSProjectに似た感覚にはならない。
そこで、下記プラグインが紹介されている。

たとえば、チケット一覧画面では、親子チケットの構造の表示がイマイチ。
そこで、subtask_list_accordionプラグインを導入すれば、子チケット一覧のツリーを折り畳みできるようになる。

Redmine Subtask List Accordion - Plugins - Redmine

また、子チケット画面の表示項目をカスタマイズできるプラグインもある。

Subtask list columns - Plugins - Redmine

つまり、subtask_list_accordionやsubtask_list_columnsのプラグインを使うことで、親チケットから子チケットへドリルダウンするUIが強化される。
親子チケットが使いやすくなることで、従来のWBS管理のやり方を変えることなく、Redmineへスムーズに移行しやすくなるはず。
さらに、こういう機能が強化されることで、チケットにより多くの情報を入力する動機づけにもなるだろう。

なお、Redmineの親子チケットに関するアンチパターンは以前書いた。
Redmineの機能制約によってアンチパターンが生まれるけれど、Redmineはプラグインを簡単に開発できるので、解決のハードルは低いと思う。

Redmineの親子チケットの功罪: プログラマの思索

最近よく聞くRedmineのFAQ～Excel添付のチケットから野良Redmineまで: プログラマの思索

【3-2】もう一つは、チケットの状態を通知する機能改善があること。

Redmineのようなチケット管理ツールの最大のメリットは、情報共有だ。
各メンバーの作業や障害の情報は、チケットに記載されて公開されることで、誰もがアクセスして情報共有できる。
しかし、最新情報を常に取得するのは面倒、という声も多い。
また、初めてRedmineを使う人がよく発する声は、チケット更新通知メールが大量に来るので困る、という内容。

そこで、それらの苦情を和らげるプラグインがいくつか紹介されている。
これは便利だと思う。

In App Notifications - Plugins - Redmine

（引用開始）
チケットの変更通知をRedmine上で受け取れます
メールを見に行く面倒さがなくなります
リアルタイム性が増します

「通知の在り方はこうあるべきだ」と思わせてくれる快適さです。
現行バージョンで動作させるには若干変更が必要かもしれませんが、その手間を掛けるだけの価値はあります。
自分でカスタマイズすればより便利です。
（引用終了）

Issue Badge - Plugins - Redmine

（引用開始）
このUIは、担当チケットを早く消化したいという気持ちにさせてくれます。
（引用終了）

ameya86/redmine_news_balloon: 新しいニュースがあれば、吹き出しでページ右下に表示するプラグインです。

（引用開始）
新着ニュースを右下にバルーン表示してくれます
能動的に情報を取りにいかない人にも、新たな情報の存在を知らしめることができます
要現行バージョン対応

積極的に情報を取りに行く習慣がない人が多いチームでは、こういった機能は有効です。
（引用終了）

個人的には、@akiko_pusuさんのBannerプラグインも追加したいかな。
システム管理者が一斉通知したいニュースもあるから。

Banner - Plugins - Redmine

これらプラグインによって、担当チケットを消化していくべきだ、とか、メールボックスを逐一見る必要がなくなる、とか、PJ管理者が書いたニュースを自然に見るようになる、とか、色々なメリットが出てくる。

いくらツールを入れても受動的な人は、性格や行動はそう簡単に変わらない。
人という生き物は保守的だから、そう簡単に昔の習慣は変えられない。
そこで、特にUI部分に着目して、使いやすいUIや気づきやすいUIにすることで、受動的な人たち、保守的な人たちも最新情報を共有するようになるだろう。

【4】そういう問題や解決策を考えると、システムのUIは機能面と同じくらい重要なのだろうと思う。
いくら機能が豊富でも、UIが使いにくければ誰も使わない。
使わないシステムは、ウン千万円もするおもちゃに過ぎなくなる。

つまり、信頼性と同じくらい、使用性もすごく重要な品質特性なのだ。
特に、最近はそういう傾向が強いせいだろうか、ユーザエクスペリエンス（UX）のような概念が提唱されているのではないか、と想像する。

また、RedmineはRailsという柔軟な開発基盤のおかげで、プラグイン開発が容易であるだけでなく、昔からJavaScriptとの相性も良い。
だから、ViewCustomizableプラグインを使って画面の細かなレイアウトを即座に修正できるし、WebアプリであってもデスクトップアプリのようなUIも実現しやすい。

ViewCustomizeプラグインでRedmineをマイクロコア化できるか: プログラマの思索

プログラミングできるプロジェクト管理者なら、Redmineみたいに、自分が考えた開発プロセスを実現できるだけでなく、自分が欲しいけど不足している機能を簡単に追加できるツールはとても重宝するのではないか。

【5】Redmineを段階的に運用していく場合、@MadowindaheadさんのPMxTMマトリクスによるポジショニングマップが参考になると思う。
Redmineを使うユーザのレベルに対し、Redmineをどのように導入すれば運用が定着するか、という観点で読めば参考になると思う。

第12回東京Redmine勉強会の感想 #redmineT: プログラマの思索

第12回redmine.tokyo参加報告 あるPMOの独り言/ウェブリブログ

メールアドレスの正規表現でユーザグループを自動設定するプラグインredmine_auto_assign_group

@two_packさんが、メールアドレスの正規表現でユーザグループを自動設定するプラグインredmine_auto_assign_groupを公開されていたのでメモ。
これは面白い。

【参考】
Tatsuya Saitoさんのツイート: "Redmineにユーザー追加時、メールアドレスに対して正規表現で設定したルールに従って、グループを自動的に設定するプラグインです。 会社ごとなどで対象プロジェクトなど、利用範囲を自動的に限定するような用途を想定しています。 https://t.co/YXEEfBkrK5"

two-pack/redmine_auto_assign_group: Redmine Auto Assign Group Plugin

akipiiさんのツイート: "協力会社のユーザ管理に便利そう。RT @two_pack: Redmineにユーザー追加時、メールアドレスに対して正規表現で設定したルールに従って、グループを自動的に設定するプラグインです。会社ごとなどで対象プロジェクトなど、利用範囲を自動的に限定するような用途を想定しています。"

使い方は下記に画面キャプチャ込で記載されている。

Usage ・ two-pack/redmine_auto_assign_group Wiki

管理画面でルールタブを開き、メールアドレスに対して正規表現にマッチするルールとユーザグループを対応付けて設定する。

使い道としては、社内にいる協力会社ユーザをユーザグループで自動設定でまとめたい時に有効だろう。
例えば、協力会社ユーザが＠XXX.com、＠YYY_ZZZ.co.jpのようなメールアドレスのルールがあれば、ルールごとにユーザグループを指定すればよい。
案件ごとに一括請負しているベンダーのユーザのメールアドレスが違うならば、たぶんそのまま使えるだろう。

Redmineのチケット管理では、担当者にユーザグループをアサインできるので、こまめにユーザグループを作っておくと使いやすくなる。
しかし、実際はその保守の方が面倒。
そこで、redmine_auto_assign_groupプラグインを使えば、メールアドレスのルールによってユーザグループを自動設定できるので、便利。

RedmineのLDAPユーザ管理と組み合わせれば、ユーザマスタ保守やユーザグループ保守がかなり楽になるのではないか。

こういうプラグインを@two_packさんが開発された背景を想像すると、Redmineのユーザマスタ保守をもう少し便利にしたい、という動機があったのだろうと推測する。
その動機やアイデアを元にOSSでプラグインを公開されているのは、本当に素晴らしいと思う。
なぜなら、特に日本の企業では、同様の利用シーンを持つユーザが多いだろうと思うからだ。

柔軟なソフトウェア設計はOSSコミュニティを活発化させる～OSSソフトウェアとOSSコミュニティの密接な関係: プログラマの思索にも書いたけれど、RedmineコミュニティにいるOSSプラグイン開発者は、とても重要な存在と思う。
彼らが活発に開発して公開してくれることで、Redmine標準で物足りない部分をカバーしてくれるし、Redmineの新たな使い道や機能を実現してくれるからだ。

今後も、Redmineプラグインの動向については色々探ってみたい。

柔軟なソフトウェア設計はOSSコミュニティを活発化させる～OSSソフトウェアとOSSコミュニティの密接な関係

@t_wadaさんのBlogを読んでいたら、「プラグイン機構はソフトウェアの構造がコミュニティの構造に及ぼす事例に相当する」という重要な指摘があった。
考えたことをラフなメモ書き。

【参考】
OSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか? - t-wadaのブログ

続: OSSプロダクトとコミュニティの話 - たごもりすメモ

akipiiさんのツイート: "「ソフトウェアの構造に「プラグイン機構」を設け、ユーザコミュニティから開発者コミュニティへの質的な転換を図るのは、ソフトウェア設計からエコシステム設計へとつながる、非常に重要な考え方である」 https://t.co/07wYG0M7yf"

akipiiさんのツイート: "Redmineもプラグイン機構を持ちカスマイズしやすい特徴もここに理由があるのかな？「組織構造がソフトウェアの構造に影響を及ぼす(Conwayの法則)と同じように、ソフトウェアの構造がコミュニティの構造に影響を及ぼしうる」　https://t.co/07wYG0M7yf"

【1】上記の記事では、「良い OSS 開発と良いソフトウェア設計の間には緊張関係があると思いますか?」という質問が発端になっている。
意図としては、OSSが良い設計であるには、ユーザからの多数の要望を五月雨式に取り入れると、アーキテクチャとしてもUIとしても一貫性がなくなり、複雑化するだけなので、取り入れないべき。
一方、OSSが活発に活動を維持するには、熱心なユーザがフィードバックやパッチをどんどん送り、ソフトウェアをバージョンアップしながらどんどん機能改善していくミッションがあるべき。

(引用開始)
しかし、それは結果的にソフトウェアの構造をゆがめることにつながらないだろうか。活発さを志向するあまり、機能やコードベースの肥大化を招いてしまい、統一感のある小さく単機能なソフトウェアの姿を保てなくならないだろうか。
もし活発さを志向する OSS 開発にそのようなバイアスがかかるのであれば、そこには構造的な問題、不幸な構図があるように見えてしまう。
(引用終了)

つまり、OSSコミュニティの活発さとより良いソフトウェア設計の間には、トレードオフがある。
では、どうやってその折り合いを採るべきなのか？

一つの解決策としては、OSSにプラグイン機構を設けて、「ソフトウェアを汚さずに、ソフトウェアを拡張する機構」というI/Fを用意しておくことだ。

(引用開始)
プラグイン機構による開発者コミュニティへの質的な転換

その意味で、モリスさんの講演にあったようにソフトウェアの構造に「プラグイン機構」を設け、ユーザコミュニティから開発者コミュニティへの質的な転換を図るのは、ソフトウェア設計からエコシステム設計へとつながる、非常に重要な考え方であると再認識した。
組織構造がソフトウェアの構造に影響を及ぼすというのは最近よく聞く話だが（コンウェイの法則）、ソフトウェアの構造がコミュニティの構造に影響を及ぼしうるというのは重要な気づきであったと思う。

OSS プロダクトがメジャーになればなるほど、コントリビューションを取り入れつつ、全体の整合性は壊さないような舵取りが大事になってくるのだろう。
大きめの OSS プロダクトや言語設計者のバランス感覚や調整能力が際立つのもわかる。
(引用終了)

つまり、プラグイン機構とは、ユーザコミュニティが単に、ソフトウェアを使用するだけの受動的立場から脱却して、自ら必要な機能はプラグインで実装するように、誘導するためのソフトウェア設計機構なのだ。

よって、プラグイン機構は、「ソフトウェアは組織構造に従う」というConwayの法則の逆パターンのコミュニティ版と言えるのではないか。
つまり、「より良いソフトウェア設計はOSSコミュニティという組織を活発化させる」。

【2】上記の記事を読んで、改めてRedmineについて思いを巡らせた。

【2-1】RedmineはRailsを開発基盤としているので、ソースも読みやすいし、プラグイン機構でユーザが機能拡張することも容易だ。
実際、Railsのプラグインの作成手順は、ネット上にいくらでも転がっている。

日本では、自分たちの組織に合った開発プロセスや業務プロセスに、Redmineを従わせて、Redmineを自由に使いたい、という要望が多い。
日本人はパッケージ製品をそのまま導入するのは嫌で、自分達なりにカスタマイズしたがる、という特徴が、Redmineにも出てくるわけだ。

Redmineが日本人好みのツールであるという仮説: プログラマの思索

Redmineが日本人好みのツールであるという仮説 part2～日本の硬い組織構造をRedmineが柔らかくしてくれる: プログラマの思索

その時、Redmine本体を修正するのではなく、プラグイン機構を使えば、Redmine本体の影響を最低限に抑えて、カスタマイズすることが可能だ。
そうすれば、Redmine本体のVerUPに追随しながら、カスタマイズした機能の保守コストを下げることができる。

【2-2】では、なぜ、「プラグイン機構＝ソフトウェア本体を汚さずにソフトウェアを拡張する機構」がRedmineにあえて必要なのか？

以前、Redmine勉強会では、JPLのRedmineの開発スタイルは非常に保守的である、という話があった。
実際、大幅な機能追加はやらないし、FunctionalTestが通らないパッチは受け取らない。
テストカバレッジは基本は100％になるまでリリースしない。

第8回東京Redmine勉強会の感想 #redmineT: プログラマの思索

JPLの美的感覚、設計思想が、熱心なユーザの機能改善要望を全て実現するのではなく、Redmineの発展に必要な機能、さらに、Redmineの品質低下を起こさないような機能だけに絞り込んでいるのだろう。

すると、確かにRedmine本体はVerUpしても安定しているだろうが、ユーザにとっては、標準機能だけでは機能不足と感じる場面も多くなる。

そんな時に、Redmineのプラグイン機構を用いて、Redmine本体に手を加えずに、自分たちの組織やプロセスに見合った機能を追加するわけだ。

換言すれば、プラグイン機構という柔軟なソフトウェア設計が、OSSアプリの標準機能では物足りないと感じるユーザに、自分達でカスタマイズできる余地を残しておき、それを利用させるような雰囲気を奨励している、とも言えるだろう。
それによって、Redmineは標準単体で安定した品質を保ちながら、ユーザはプラグインを入れて、自分達の環境に合ったプロセスを実現できる。
つまり、Redmineの柔軟なプラグイン機構が、ユーザにプラグイン開発を促進させ、多様なプロセスを実現することを促進させているわけだ。

【2-3】だから、Redmineのように、自由に機能拡張できるI/Fを持つOSSソフトウェアは、日本人向きなのだろう。

実際、Redmineはプラグイン機構以外にもREST APIやメールによるチケット登録、rakeコマンドなどの数多くのI/Fがあり、それらを適材適所に当てはめれば、機能をカスタマイズしやすい特徴がある。
以前、この辺りの事情は分析していた。

Redmineの裏の顔～開発基盤としてのRedmine: プログラマの思索

但し、この特徴はRedmineに限らず、SAPなどの著名なERPにおいても、パッチ当てをプラグインのような機構で実現しているので、そんなに特別なわけではない。

【2-4】一方、Redmineは「プラグイン機構＝ソフトウェア本体を汚さずにソフトウェアを拡張する機構」の特徴を持つことで、Redmineコミュニティ自身が活発になりやすいこともあるだろう。

日本のRedmineコミュニティではプラグイン開発者が多い、という特徴を以前、@agilekawabataさんが指摘していた。

Redmineが日本人好みのツールであるという仮説part3～日本のRedmineコミュニティにはプラグイン開発者が多い: プログラマの思索

この意味は、日本企業はRedmineを自分たちの組織にあわせてカスマイズしたがるので、プラグイン開発者を必要としていることだ。
そして、そういうプラグイン開発者が日本のRedmineコミュニティには結構多い。

OSSの日本人Redmineプラグイン開発者として、@akiko_pusuさん、@tkusukawaさん、@haru_iidaさん、@two_packさん、@onozatyさんたちがすぐに思い浮かぶ。
また、日本企業でも、アジャイルウェアなど、Redmineプラグインを専門に開発するSI企業も結構いる。

そういうプラグイン開発者や開発ベンダーは、RedmineというOSSコミュニティの活動にとても貴重な人達だ。
なぜなら、彼らはRedmine本体に取り込まれなかった機能を無償・有償でプラグインを公開してくれており、ユーザも恩恵を受けられるからだ。

また、彼らはRedmineの機能改善や利用事例に関するニーズも多数保持しているだろう。
そこで得られた知見も多いに違いない。
そして、実際、そういう知見をRedmineコミュニティで発表して、ユーザと共有してくれている。

そんな事を考えると、プラグイン機構というソフトウェア設計は、OSSソフトウェア本体を汚さずにOSSコミュニティを活発化させていくために必要な特性と言えるのだろうと思う。

つまり、柔軟なソフトウェア設計は逆に、OSSコミュニティという組織構造に良い影響を与えているわけだ。

【3】「Redmineは組織構造に従う」「柔軟なソフトウェア設計はOSSコミュニティを活発化させる」という二つの経験則は、正直面白い。

似たような経験則として、逆コンウェイ戦略「望ましいアーキテクチャに合わせて、アジャイルな開発チームを作る」という話もあった。

逆コンウェイ戦略のメモ～望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

これ以外にも、Redmineインスタンスとプロセスの密接な関係もある。
「唯一のRedmineインスタンスで、組織内の多種多様な状況に合わせた標準プロセスを実現する」という観点と、「それぞれの開発チームの組織文化や開発プロセスに合わせて、あえて、Redmineインスタンスを複数個立てて運用する」という観点の二つのやり方がある。

Redmineインスタンスとプロセスの関係～Redmineは組織に従うのか、Redmineに合ったチームを作るべきか: プログラマの思索

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

どちらが正しい、というのではなく、それぞれの前提条件、組織の状況に応じて、コンテキストは変わる。

今の僕の興味は、Redmineのような柔軟なOSSソフトウェア、それを運用する組織構造やプロセスとの間に、どんな関係があり、どのようなコンテキストが発生しているのか、を経験則として抽出して、その本質を探ってみたい、と思っている。

astahを起動せずにJavaScriptで情報を取得する方法

tokudiroさんが、astahを起動せずにJavaScriptで情報を取得する方法を公開されていたのでメモ。

astah APIをjjsを使って楽に呼び出す - Qiita

やり方は、java8 のjavascript 実行エンジンjjsを使って、下記のようなコマンドを実行すればよい。
詳細は上記参照。

jjs.exe -cp astah-api.jar;astah-community.jar openProject.js hoge.js closeProject.js -- fuga.asta

使いたい状況としては、astahファイルからクラス情報などを一括出力したい時、hoge.jsにJSスクリプトで取得プログラムを書いておき、JJSエンジンで実行すればよい。
これは便利だ。

astahにはスクリプトエディタがあり、そこにJavascript、Ruby、Groovyなどを書けば即実行できるが、バッチ出力したい状況も多い。
プログラムは使い慣れたテキストエディタや開発環境の方が書きやすいから。
また、astahのスクリプトエディタではなく、プログラムを別ファイルで保存できるので、バージョン管理もやりやすい。

たぶん、JavaScriptだけでなく、Ruby、Groovyでも、上記と同じようなやり方で実行できるだろうと推測する。

利用シーンは、たとえば、本番稼働中の既存ソース群をastahへリバースして、クラス図などで設計図を書き起こした後、astahAPIでソフトウェアメトリクスを計算するJavaScriptをプログラム化しておき、上記のJJSエンジンでメトリクスを一括出力する、とか。

astahのモデルからソフトウェアメトリクスを出力して、既存のソフトウェア工学の理論を実証実験したい時に有効活用できるような気がする。

astahのシーケンス図をPlantUMLへ変換する方法

astahのシーケンス図をPlantUMLへ変換する方法が公開されていたのでメモ。
これは興味をくすぐる。

【参考】
astah*で描いた図をPlantUMLやmermaid用に変換 | astah in 5 min

Avens666/Astah_Jude_UML_export_to_Markdown-mermaid-Plantuml-: Use Astah JS plugin, export astah diagrams data (such as flowchart, class chart ) to mermaid text fomat and Plantuml format

PlantUML インストール方法 - unhurried

UML図を描画するための単純なテキスト記述を使用したオープンソースのツール。

テキストでUMLを書く - Qiita

【1】手順はこんな感じ。

astahのシーケンス図を開く
↓
astahのスクリプトエディタ起動
↓
Jude_sequence_to_plantuml.jsを貼り付ける
↓
スクリプトエディタからRunで実行
↓
実行結果に、PlantUMLのソース（シーケンス図）が出力される

たとえば、PlantUML Web Serverに、PlantUMLのソースを貼り付けると、シーケンス図が表示される。
これは便利だ。

Jude_sequence_to_plantuml.jsを読むと、astahのシーケンス図の要素をAPIで取得して、PlantUMLの記法にセットしているだけでシンプル。
このやり方を真似れば、PlantUMLのクラス図、ユースケース図、アクティビティ図、コンポーネント図などにも適用できるだろう。

【2】PlantUMLを使いたい場面は、UMLの各種ダイアグラムで基本設計や詳細設計の成果物を作りたい時。

以前は、RationalRose、EnterpriseArchitect、Astahなどの設計ツールか、ExcelやVisioなどのOfficeソフトでお絵描きするのが普通だったが、こういうお絵かきツールはちょっとした仕様変更にすごく弱い。

メソッドが１個増えただけで、レイアウトが大きく変わり、お絵かきの修正にかなりの時間が取られたりする。
お絵かきがしたいのではなく、クラス設計に注力したいのに、実際は、線1本のレイアウトに時間を取られる時の方が多くないだろうか？

また、お絵かきソフトは、バージョン管理が弱いので、修正履歴がない場合が多い。
すると、ちょっとした変更で間違えたので元に戻したい、という作業ができなくなる。

そんな場面では、PlantUMLのように、UMLの各種ダイアグラムもテキストで書いた方が楽。
テキストであれば、Gitでバージョン管理できるので、Undo・Redoがいつでもできるので、試行錯誤しながら、設計することもできる。
バージョン管理の環境がない作業は、UndoやRedoができないので、今何をやっているのか、常にログを残して覚えておく、というプレッシャーが残り、本来の創造的な作業がやりにくいように思う。

但し、ラフなスケッチでお絵描きしたい時もある。
だから、astahで書いてPlantUMLに出力し、その後はPlantUMLのソースを修正していく方が楽かもしれない。

【3】上記のやり方を発展させると、以下のような機能へ発展できないか、と思う。

・astahから、PlantUMLの各種ダイアグラム（クラス図、ユースケース図、シーケンス図等）のソースを出力する
・PlantUMLのソースから、astahへリバースしてダイアグラムを復元する

つまり、astahとPlantUMLで相互にエクスポート・インポートできるようになれば、色んな可能性が出てくると思う。
たとえば、astahでラフなスケッチをしてからPlantUMLに出力して、ソース管理する。
本番稼働中の既存ソースをastahへリバースしてクラス図を作り、PlantUMLへ出力してバージョン管理しておく、とか。

あるいは、PlantUMLからastahへインポートして、さらにastahからJavaやC#のスケルトンクラスを出力する、とか。

プラグイン化できたら面白そう。

【追記】
RedmineにPlantUMLを表示するプラグインは、既に公開されている。
海外の開発者のコメントを見ると、好評らしい。

plantuml - Plugins - Redmine

dkd/plantuml: PlantUML Plugin for Redmine

RedmineでPlantUMLを使う事例: プログラマの思索

Redmine で技術仕様書を書こう | Aiming 開発者ブログ