astahでPJ管理もプロセス設計もアイデア発想も全て表現したい

astahでPJ管理もプロセス設計もアイデア発想も全て表現したい。
つまり、astahで描けるUML、データモデリング、マインドマップを駆使して、仕事のすべての場面でアイデア発想、アイデア収束、展開するパワポ資料のアウトラインまで作成したい。

【参考】
astah システム設計、ソフトウェア開発支援ツール | astah*

ダイアグラム思考 次世代型リーダーは図解でチームを動かす | 髙野 雄一

第4回astah関西勉強会の感想 #astahkansai｜akipii

astah*の因果ループプラグインがいいね: プログラマの思索

astahで使える無償プラグイン一覧

astah*のデータをiPadで持ち運ぶ | 雲の巣

【1】なぜ、astahをそんなに使いたいのか？

1つ目は、単純に僕はastahが好きだから。
PlantUML、Mermaidも良いが、直感的に絵を描きたい時、astahの方が手に馴染む。
EnterpriseArchitectも良いツールだし、多機能なので何でも描けるが、僕の感覚に合ってなかった。

2つ目は、モヤモヤした状況をいろんな観点で図示して、構造を見える化したいからだ。
システムやソースコードの分析だけではない。

日々の業務では、定常業務の手順や業務フローをアクティビティ図やDFDで描けば、誰に何をどのタイミングで渡せばいいのか、理解できる。

PJ管理では、PJのゴールや成功条件に対し、中間目標には何があって、それを解決する手段は何なのか、紐づけて可視化したい。
ステークホルダー分析では、アクターとなるステークホルダーと要求事項、期待値を紐づけて、どんなコミュニケーションを実施すればいいのか、色んな観点で案を探るために、ユースケース図でイメージしたい。
発生した問題に対し、その事象にはどんな要因が原因と結果の流れでつながっていて、因果ループ図のようなシステマティックな構造で発生している構造を可視化し、本来の真因やボトルくネックを特定することで、効果的な対策を実施したい。
展開するパワポ資料を作る時、いきなり書き出すのではなく、アウトラインや目次の構成を考えるために、メッセージやアイデアを発散して収集する。意味ある因果関係で整理するために、マインドマップを使いたい。

つまり、仕事のあらゆる場面で、astahを使うことで手順の可視化、計画の可視化、問題の可視化に使いたいのだ。

【2】では、astahをどの場面でどんな技法を使うと有効なのか、考えてみたい。

UML、データモデリングは一通り使える。

【2-1】個人的に好きなツールは、ユースケース図に因果ループ図の構造を把握してくれるプラグインだ。
因果ループ図を使う場面は、PJ管理上でQCDに関する問題が発生した時に、複数の事象や複数の原因がどのように因果関係でつながっているかを可視化して、ボトルネック特定や対策策定に役立つときだ。

astah*の因果ループプラグインがいいね: プログラマの思索

【2-2】最近、アクティビティ図にInput、Outputをオブジェクトとして追加し、DFDぽく表現するやり方をやってる。
一連の業務フローに帳票、システムへの入出力となる情報、メール送信などを入れると、理解しやすくなる。
単純なDFDは順序が表現されないので、その弱点を解決できるのもメリットだ。

【2-3】最近、チームの状態やチームの能力成熟度を状態遷移図で表現するやり方をやってる。
たとえば、ファシリテーションなら、会議の中で、チーム内の議論の状態が、共有→発想→収束→展開のように流れるので、そのまま状態遷移図で表現してしまう。
すると、どんなトリガーで次の状態に移るのか、条件を考える気づきがある。

この考えを進めると、CMMIの能力成熟度モデル5段階、マズローの欲求5段階説も同様に、状態遷移図で表せる。
1段上の能力に上がるにはどんなトリガーや条件を満たす必要があるのか、を表現できるわけだ。

【2-4】ユースケース図のうち、ロバストネス図の機能を使って、DFDみたいに書く時がある。
デマルコ記法のDFDよりもロバストネス図の方が、クラス図やシーケンス図にも連動しやすいので便利だ。

【2-5】マトリクスで4象限を表現したい時、アクティビティ図でレーンで枠を囲って、無理やり表現している。
迷うのは、4象限に配置した概念をアクティビティにするか、ノートにするかだ。
長い文字列で表現するときはノートにせざるを得ないが、アクティビティの方がそれらしく見えやすいので悩んでる。

【2-6】ユースケース図をアクティビティ図の代わりに業務フローで表す手段も試してる。
ユースケース図で業務の流れを表現するメリットは、アクターやInOutのオブジェクトをクラスやロバストネス図のオブジェクトなど、色んなツールで多彩に表現できることだ。
そもそも、アクティビティ図も本来は、一つのアクティビティがユースケースになり、そこからクラス図やシーケンス図へ落とされていくので、ユースケース図の方が詳細化する他の図に連動させやすいメリットがある。

【2-7】今度試したいのは、タイミング図だ。
たとえば、時系列で推移や変動をグラフで表現したい時がある。
タイミング図では、時系列に状態を表現できる機能があるので、時系列グラフをうまく表現できないか、考えている。

【2-8】マインドマップはアイデア発散に使える。
僕は、資料構成のアウトライン作成で使って、そこからパワポ出力する機能を愛用してる。
他に、たくさんの図を残していて、それらを整理するために、マインドマップにドラッグ・アンド・ドロップしてリンク集みたいに使っている。
マインドマップ上で、リンクされた図をカテゴリすればさらに見やすくなる。

【2-9】ER図にようやくパッケージ構造の機能が追加されたので、フォルダ分けすることで、複数のER図を作りやすくなった。
DBリバース、DBエクスポートプラグインを使えば、ExcelのDB定義書と同期できるので便利。

【2-9】astahの図を全てHTML出力するプラグインも入れた。
astahの100個以上の図を貯めているので、HTMLで出力してiPhoneやiPadに入れて、暇な時に読んでいる。
自分が書いた図なのに、後で読み返すと気づきがあってすごくいい。

DiagramToHTMLプラグイン | Astah

astah*のデータをiPadで持ち運ぶ | 雲の巣

【3】結論は、astahで全て書ききれると思う。

書きづらい場面は、マトリクスや表形式で詳細にまとめたい時、パワポ資料に描くポンチ絵だろう。
その辺りもまた解決方法を考えてみたいと思う。

astahでPJ管理もプロセス設計もアイデア発想も全て表現することで、自分のアイデアも手順も全て可視化したい。
そうすれば誰にでも説明できるし、自分の中でストーリーも作りやすい。
もっともっと試してみたい。

astahでPJ管理もプロセス設計もアイデア発想も全て表現したい

第22回 Redmine大阪の感想 #RedmineOsaka

第22回 Redmine大阪の感想をメモ。

【参考】
2025/9/21 第22回 Redmine大阪 #RedmineOsaka - posfie

Redmine-osaka-022 - Redmine.Osaka

入門Redmine第6版 : 石原佑季子, 前田剛: 本

5年ぶりの開催で盛り上がりを心配したが杞憂だった。
スタッフも参加者もテンションが高くて楽しかった。
東京、岐阜、福岡から参加者が来てくれた。
初めての参加者も若手で数人おられたが、すぐに馴染んで、本音ベースで話せた。

講演内容も多様だった。

【1】前田さんの話では、Ver4以前のRedmineは最新機能が全く取り込まれていないので、早くアップデートしましょうという主張だった。
メンション機能、チケット一覧での検索、フォントサイズやフォントの変更、テーブルタグを見やすくするUI改善が目に留まった。
次バージョンでは、いいね機能もリリースされる。
昨今のスマホのようなUIを取り入れていく改善は、地味だけれども、ユーザ体験をより良くするために重要だと思う。

【2】赤羽根さんの話では、チケット20万件以上、ユーザ数3900人以上の大規模な運用事例。
製造業という非常に縦割り組織の中で、10年以上Redmineを運用して、設計情報をRedmineに蓄積しナレッジ基盤とした運用はすごいと思う。
後で聞いた話では、Redmineをフローの管理、つまりタスク管理や進捗管理に使うのではなく、チケットに設計情報や製品に関する情報だけをどんどん蓄積していく運用に振り切った、とのこと。
だからこそ、10億字以上の文字が蓄積されるわけだし、全文検索エンジンGroongaの必要性が出てくる流れを理解できる。

【3】三浦さんの話では、自分はなぜかドキュメント管理の整備にアサインされるという話から始まって、ドキュメント管理の経験を語られた。
Wikiでナレッジが集約されるメリットがある反面、ドキュメントは負債にもなり得ること、ドキュメントの保守には工数がかなりかかる。
インセンティブや強制力を使って、ドキュメントを残し集約し、検索できるようにする基盤として、Redmineも候補になりうる。

【4】アジャイルウェア様の会場をお借りして本当に楽しかった。
広くて綺麗で、液晶モニタもすごく大きくて、プロジェクタ無しで投影できて素晴らしい会場だった。
ありがとうございました。

【5】Redmineコミュニティの良い所は、講演内容がRedmineの機能紹介やカスタマイズに偏ることなく、運用事例やプロジェクト管理、情シス部門の考え方、ナレッジ蓄積やタスク管理の考え方まで幅広く紹介されること。
このあたりが面白いなと思う。
だからこそ、かなり特殊なコミュニティもかかわらず、テーマが多様なお陰で、コミュニティが長続きしているのだろうと思う。

また次回も開催したいなと思います。

データモデリングとドメイン駆動設計の違いは何か

データモデリングとドメイン駆動設計の違いは何かを考えている。
アイデア段階で書き殴りのメモ。

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

「データモデル大全」は良い本だ: プログラマの思索

システム開発・刷新のための データモデル大 | 渡辺 幸三 |本

達人に学ぶDB設計徹底指南書 第2版 | ミック

【1】問題設定
僕は、データモデリングもドメイン駆動設計もどちらも好きだ。
データモデリングは生産管理や販売管理などの具体的な業務ドメイン知識をベースに、どんなER図を描くべきか、具体的な実現方法まで示唆してくれる。
ドメイン駆動設計は、オブジェクト指向設計をベースに、どんなプログラムに実装すべきかまで具体的な実装方法まで示唆してくれる。

しかし、双方の考え方や価値観には大きな相違があるように思える。
たとえば、クラウド上でシステム構築するのが当たり前の現代では、ドメイン駆動設計はマイクロサービス設計につながる設計手法として再定義されているように思える。
一方、データモデリングの手法は２０年以上前のやり方と全く変わらず、今のシステム設計の文脈で置き換えられる内容が伴っていないために、古臭い手法のように感じてしまう。

【2】データモデリングの観点ではマイクロサービス設計とは何なのか？
では、マイクロサービス設計やドメイン駆動設計の考え方をデータモデリングの観点で言い換えるとどんな説明になるか？
データモデリングはどんな新しい観点をもたらしてくれるのか？

【3】データモデリングのパターンやイディオムは何か？
ドメイン駆動設計ではパターンやイディオムがあって共通言語になっている。
開発者同士で会話する時に認識を共有できる。
たとえば、リポジトリ、集約、境界づけられたコンテキスト、など。

一方、データモデリングでは、関数従属性ぐらいしか概念がなく、モデリングに関する共通言語がないように思う。
だから、関数従属性というメタ的な内容でしか話せず、生産管理や販売管理、会計などの特定の業務領域で具体的な議論にはまり込んでしまい、何かすごいことが分かった気がするのに、それを上手く伝えられていないと思う。
データモデリングでも重要な概念はあるので、パターンやイディオムを提示すべきではないか。
そうすれば、開発者同士で共通言語を用いて議論できると思う。

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

パターンやイディオムとしてあげて欲しいキーワードを挙げておく。
パターン言語にある状況・問題・フォース・解決方法・効果として整理できるはず。

・2次識別子とボイスコッド正規化
　2次識別子はもう一つの主キーなので、ボイスコッド正規化せざるを得ない。

・2次識別子とテーブルの抽象化・統合化
　具体例は動的参照関係、テーブルの派生関係になる

・2次識別子とサロゲートキー
　複合主キーを2次識別子にする

・サロゲートキーと強属性
　2次識別子（代替キー、Alternative key）は強属性（追加されたら削除されるまで更新不可）になる

・派生関係
　たとえば品番、取引先
　オブジェクト指向の継承関係とは異なる観点を明確化したい

・導出属性（作出属性）
　たとえば、在庫数とか
　渡辺式ER図では、導出属性をマスタ（リソース）に配置する例が多い
　リソースやイベントでない場合、サマリテーブルとしてバッチ処理で作る

・イベントとリソースの見分け方
　テーブルをイベントとリソースで区別できれば、ER図での配置基準が明確になる
　イベントには日付がある

・イベントの先行・後続関係の見分け方
　イベントのテーブルに順序関係が発生し、業務フローを書き起こせる
　データモデルから業務フローをイメージできるか
　ER図を見れば、業務フローを具体的にイメージできる
　ER図をベースに、業務フローやDFDを作成できるはず

・サマリテーブル、集計テーブルの作り方
　どのイベントからサマリテーブルや集計テーブルを作るのか？
　DWHの設計手法を整理できるか？

・動的参照関係と暗黙的リレーションシップ
　複数のテーブルを結合したときに、参照関係が発生する
　暗黙的リレーションシップになる
　ER図だけでは読解しづらく、開発基盤の上で動的参照関係を実現するしかない

・時限NULL
　レコード生成時はNULLだが、業務イベントを通じて値がセットされる
　一時的なNULLの項目なので、NULLの項目であっても存在を許す

・再帰構造とLLC
　LLC（Low Level Code）は、再帰となるツリー構造の深さを表す
　LLCを使って再帰構造のロジックをプログラム上で実装しやすくする

・もう1つの再帰構造
　階層構造は入れ子集合を使うと、ツリー構造をRDBに綺麗にマッピングできる

・フィーチャオプション
　テーブルに項目を横持ちで持たせるのではなく、縦持ちで持たせる構造にする
　リソース（マスタ）のテーブル設計で使われる
　◯区分、◯種別が項目で横持ちに増えるのを防ぐ

・制約条件や業務ロジックの表現
　業務のルール、業務ロジックを関数従属性を使って表現する
　業務ルールは、特定の組み合わせや特定の性質で表現される場合が多い
　そういう事象は、レコードという命題で表現されるので、関数従属性として表現されるべき
　渡辺式ER図では推移的関数従属を参照関係を使って上手く排除している

・◯◯区分や◯◯ステータスは状態遷移を表す
　テーブルにある◯◯区分や◯◯ステータスは、状態遷移を表すので状態遷移図を発生させる
　◯◯区分や◯◯ステータスは、開発基盤の上では、条件分岐を発生させる

・ActiveRecordとORマッピング、ORインピーダンスマッチング
　オブジェクト指向プログラミングとリレーショナルデータベースは異なるデータモデルを持つ。
　ActiveRecordはORインピーダンスマッチングを解決する一つの手法

RedmineJapan vol.4の感想part1～Redmine AI HeplerプラグインはRedmineのナレッジ活用を強化してくれる #RedmineJapan

RedmineJapan vol.4で紹介されたRedmine AI Heplerプラグインが素晴らしかったのでメモ。

【参考】
Redmineによるタスクマネジメント実践技法

逆引きでわかる！ Redmineハンドブック バージョン5.0対応

2025/7/25 Redmine Japan Vol.4 #RedmineJapan - posfie

Redmine Japan Vol.4

Redmine AI Helperプラグイン更新

Redmine AI Helperプラグインを公開しました

【1】Redmine AI Heplerプラグインは、RedmineからAI機能をコールして、チケットやWikiの要約などをしてくれるプラグインだ。
今年5月のredmine.tokyoでも講演されていて、参加者の多数がすごく興味を持っていた。

実際はOpenAIやGeminiなど外部のAIへトークンを発行してコールしている仕組みだけだが、AIがさらにRedmineを使いやすくしてくれる可能性を秘めている。

Redmineを長年使い込んでいくと、チケットに過去の作業、障害修正、課題対応などのノウハウがナレッジとして蓄積されていく。
しかし、そのノウハウはそのまま使えるわけではない。
内容が何なのか、ポイントを抽出したり、過去のコンテキストを元に現状の環境ではこういうナレッジになる、という仕掛けがほしい。

要約はAIが得意とする機能なので、要約機能を使えば、現場で使う詳細な進捗報告書を経営層などトップ層へサマリ化、要約して報告書を生成することもできるはず。
たとえば、詳細な障害一覧や課題一覧を見せられても彼らは分からない。
むしろ、どこにリスクがあるのか、現状はどんな評価なのか、を知りたい。
そんな時に、AIの要約機能は使えるはず。

つまり、Redmineにプロジェクト報告書を追加する機能がより具体化できるだろう。

【2】RedmineJapan vol.4ではさらに、edmine AI Heplerプラグインが進化していた。
Redmine AI Helperプラグイン更新の記事の通り、チケットの回答案生成、子チケット作成、プロジェクト報告も機能追加されていた。

チケットの回答案作成は、カスタマーサポートのような定型的な文章を書く場面で有効だろう。
主張したいことを箇条書きで提示すればAIが上手く文章を作ってくれる。

子チケット作成は、プロジェクトリーダーの管理作業を代行してくれるような機能だ。
デモでは、不具合チケットを元に、調査、原因分析、障害対応、検証、リグレッションテスト、デプロイ、リリースなどの子チケットをワンクリックで自動生成してくれていた。
つまり、障害修正のような定型作業では、手順は標準化されているので、その手順に沿ってタスクを詳細化して作成し、それぞれのタスクに担当者を割り振ればいい。
よって、プロジェクトリーダーの管理作業をかなり楽にしてくれるはずだ。

プロジェクト報告では、該当プロジェクトのチケット群をベースに、その時点のプロジェクトの進捗・品質・コストを自動で報告文を生成してくれる。
プロジェクト報告のQCDを数値で評価する機能もあり、たぶん、占いエージェントを作った経験から作られたのだろうか。
また、おれおれ報告というカテゴリもあり、AIが勝手にプロジェクトを診断して、良いか悪いかバッサリ評価した文章を生成してくれる。
遊び心があっていいと思った。

今後、プロジェクト報告機能では、定期的なタイミングでプロジェクト報告の履歴を残す機能も作りたい、と話されていた。
確かに、報告は履歴が重要で、推移を元に比較評価したい。
だから、プロジェクト報告機能の強化は、Redmineがさらにプロジェクト管理ツールとして進化する可能性を大いに秘めていると思う。

【3】RedmineにAIの機能が追加されることによって、何が大きく変わるのか？

やはり、Redmineに蓄積された作業、障害、課題、問い合わせのナレッジを元に、より精度の高いノウハウを蒸留し、抽出してくれることで、プロジェクトリーダーの管理作業や意思決定を支援する仕組みを提供することだろう。

従来のチケット管理システムでは、チケットの更新情報や活動履歴を元に、進捗・品質・コストをリアルタイムに集計できることによって、プロジェクトリーダーの意思決定を支援できる点がメリットだった。
つまり、強力なチケット集計機能がチケット管理システムの主なウリだった。

一方、チケット管理システムには案件や組織特有の情報がチケットとして蓄積されるので、ナレッジシステムにもなりうる。
ナレッジシステムであるからには、いつでも簡単にデータが検索できて、欲しい情報がすぐに得られるようにしたい。
だから、チケット管理システムでは、強力な全文検索機能も重要な要件になりうる。

しかし、全文検索機能はあくまでも文言にヒットするだけであり、本当に欲しい情報を得るには、検索結果から取捨選択する手間もかかる。
そこが弱点だった。

そこで、チケット管理システムにAI機能が追加されることにより、本当に欲しい情報が蓄積されたチケットから蒸留されてサマリ化された情報を取得できるようになる。

つまり、AI機能は、チケット管理システムがナレッジシステムでもある特徴を効果的に利用可能にするはずだ。

しかし、AI機能を単純に機能追加すればすべてが解決できるわけではない。

講演者の@haru_iidaさんが話されていたが、ある案件で担当者をアサインする時、その人の予定表をOutlookで見れば確保できる工数は限られていれば、そう簡単に意思決定できるわけではない。
つまり、Redmineだけでは、本来のリソース管理を意思決定できない。
そこで、Outlookの予定表データをAI機能でアクセスして予定情報を取り込んだり、社内システムや人事システムも取り込んで、より多角的に判断できる仕組みも必要になるだろう。

すなわち、Redmineを情報系基幹系システムとみなすことで、案件管理を強化し、プロジェクトリーダーのチーム運営や意思決定を強化する方向へ進化できるはずだ。

その辺りも今後の発展が楽しみだと思う。

Jiraの機能はTracに似ている気がする #redmine

最近、Jiraを触り始めた。
Jiraの感想は一言で言えば、昔のTracにすごく似ている気がする。

Redmineユーザの観点では、Jiraは非常に使いにくい。
Jiraのどこが使いにくいのか？

使いにくい原因は、Jiraがアジャイル開発機能に特化していること、Tracのような古い機能が残っていることだと思う。

Tracのワークフロー: プログラマの思索

RedmineとTracの機能比較: プログラマの思索

Jira Cloud ユーザー向け 入門ガイドブック第２版 : リックソフト株式会社

Confluence ユーザー向け 入門ガイドブック | リックソフト株式会社

【1】一般に、JiraはScrumのようなアジャイル開発、カスタマーサポートのようなサービスデスクなどのユースケースに特化している。
Jiraには、アジャイル開発の機能がすでに盛り込まれている。
チケットと呼ばず課題（Issue）と呼ばれている。
課題には、エピック、ストーリー、タスクが既に存在していて、ストーリーポイントのような見積もり項目もある。
課題のビューには、バックログとスプリントバックログが既に存在している。

しかし、一般の日本企業では、WF型開発が主流であり、ExcelのWBSとかガントチャートを使いたい。
結局、リックソフト社のガントチャートプラグインを入れて、Scrumの機能は全く使わず、ガントチャート上でタスク管理している事例がすごく多い。
つまり、日本企業の現場では、実際のタスク管理とJiraのアジャイル開発機能にギャップが発生している。

しかも、日本企業の現場では、Jiraのスプリント機能を使っていない。
スプリントをなぜ使わないのか？

Jiraではプロジェクトを階層化できないため、１個のプロジェクトで１つの大規模案件をアサインする。
すると、１個のプロジェクトに複数チームのタスク管理に使うため、複数チームのタスクが混在してしまう。
だから、複数チームのタスクを区別するために、WBSのトップ階層を各チームに割り当てて、タスクを階層化して使っている。
非常に使いにくいこと極まりない。
Redmineならプロジェクトを階層化できるので、子プロジェクトをチームごとに割り当てることで、タスクを分別できるし、親プロジェクトで横串で横断して管理もできるのに。

しかも、JiraのスプリントはRedmineのバージョンと同様に、１プロジェクトに依存するために、複数チームのタスクに１つのスプリントがアサインされる。
しかし、現場では、チームごとにチーム特有のスプリントを決めたいケースは多い。
大規模案件ではリリースバージョンというメインターゲットが決まっていても、各チームのタスク管理では、各チームごとにこまめにリリースしたいバージョンがあって、それをスプリントにアサインしたいが、スプリントはPJ固有であるために、チームごとにスプリントをアサインできない。

Redmineならば、親子プロジェクトができるから、子プロジェクトでチーム独自のバージョンをアサインできる。
つまり、全チームはアジャイルリリーストレインのごとく、最終ターゲットであるリリースバージョンに向けて作業していく。
ただし、チームごとにリリースバージョンに向けて細かなバージョンを作成してマイルストーンを決定したいし、各チームごとにロードマップを詳細化すればいい。
そういう作業計画がJiraでは非常にやりにくいと感じる。

【2】Jiraのチケット項目には、解決状況というバグ管理システムの遺産みたいな項目がまだ残っている。

たとえば、TracやMantisでも解決状況の項目があったし、解決状況＝解決済みor取り下げを設定しなければ、チケットを完全にCloseできなかったり、ロードマップの画面に取り消し線でCloseされた意図が表示されない機能があった。

Jiraでも同様に、解決状況＝解決済みor取り下げを設定しなければ、チケットを完全にCloseできない。
チケット駆動の初心者にとって、チケット完了させるためにはステータスを完了にするだけでは不十分なのはなぜ？　解決状況って何なの？と思うだろう。
Redmineのようにシンプルに、解決状況はステータスと同一視して、無くしてしまえばいいのにと思う。

RedmineとTracの機能比較: プログラマの思索

また、チケット管理ツールで最重要な機能であるワークフロー管理機能は、JiraではUIエディタ上で設定する仕組みになっている。
UIエディタ画面上で、ステータスに先行後続の関係を線で引っ張るのが鬱陶しい。
Redmineならば、状態遷移表のようにステータスの先行後続はチェックボックスをつけるだけなので、状態遷移図をイメージできれば記入しやすいし、事前にチェックリストのように作っておけば間違えにくい。

たぶん、TracのワークフローはINIファイルにPlantUMLみたいに記述するやり方だったが、Jiraもそのやり方を踏襲しているが初心者でも使えるようにUIエディタ上で見た目は分かりやすく表現しているのだろうと想像する。
正直使いにくくて鬱陶しい。

Tracのワークフロー: プログラマの思索

さらに、Tracのチケット集計ビューはSQLで直接書くことができたように、JiraでもJQLというSQLに似た構文を使って、ダッシュボードというビューを自由自在に作れるメリットがある。
Jiraを使う場合、Confluenceとセットで使う場合が多いので、Confluenceにダッシュボードを埋め込んで、Wordみたいにきれいに文書化できる。
この点はRedmineよりも優れている点だろうが、解決状況やワークフロー機能の使いにくさを思い出すと、改めてTracにすごく似ているように思える。

【3】とは言え、たぶん僕がまだJiraを使いこなせていないだけなのかもしれない。
自分がやりたいのは、Jiraでスプリント機能を使って、複数チームのタスク管理をイテレーション単位に管理して、アジャイル開発のペースを実現したいことだ。
その観点でさらに試してみたいと思う。