メールでRedmineチケットを登録する機能の可能性
メールでRedmineチケットを登録する機能の可能性について考えたことをメモ。
【2016/3/5 更新】
@netazoneさんのおかげで、現在も動作するThunderbirdのアドオンを見つけられました。
Redmine連携 :: Add-ons for Thunderbird
ThunderbirdとOutlookのRedmineアドオン: プログラマの思索
【元ネタ】
Thunderbirdで受信したメールをRedmineのチケットとして登録できる「Quick Ticket to Redmine」 | Redmine.JP Blog
Email-ext plugin - hudson - Hudson Wiki
RedmineとHudsonやTestLinkを連携させるプラグイン: プログラマの思索
Hinemos+Redmine for ITILで運用保守を改善する: プログラマの思索
Redmineのチケット登録をITILへ応用する: プログラマの思索
RedmineのVer0.8の頃から、メールでRedmineチケットを登録できる機能は付いていた。
おそらくRubyのライブラリを使えば、実装はそんなに難しくない機能だろうが、メールによるチケット登録機能は、ソフトウェア開発のバックエンドの業務をサポートしてくれる可能性を秘めている。
使い道としては、インシデント管理におけるサポートデスクの作業を自動化する点だ。
サーバー監視ツールがOSやHDDのダウンを検知したり、ネットワーク障害を検知したら、普通は緊急障害のメールを自動で流す。
そのタイミングで、Redmineチケットを登録するメールを流せば、一つのインシデントとしてRedmineの障害管理として扱われる。
障害に対する応急処置、そして抜本的な是正措置に対する作業ログは全てチケットに追記すればいい。
Redmineの優れたワークフロー管理によって変更管理をリアルタイムにモニタリングできるし、SCM連携によるトレーサビリティによって、SCMリポジトリにあるソースや設計書、リリース手順書の変更も追跡できるようになる。
ここで、Thunderbirdで受信したメールをRedmineのチケットとして登録できる「Quick Ticket to Redmine」 | Redmine.JP Blogの記事で面白いのは、ユーザから届いたメールをサポートデスクのオペレータがメールソフトで受信した時、メールを転送するだけでRedmineチケットを登録できる仕掛けがあること。
Redmineチケットに起票すれば、一つのインシデントあるいは障害として見なされて、変更管理プロセスの一部として管理できる。
オペレータが解決できないインシデントは、開発チームや上級管理職へエスカレーションして、彼らに対応してもらえばいい。
そのワークフローもRedmineの優れたワークフロー管理機能で透過的にサポートしてくれる。
あるいは、@haru_iidaさんの講演内容Hudson × Redmineによれば、Hudsonのビルドエラーを検知したメールからRedmineチケットに登録するアイデアも紹介されていた。
この機能は、PFのソフトウェアあんどんの発想と全く同じだ。
ビルドエラーと言う重大な障害をすぐに皆で共有できる。
昨今のサーバー障害検知ツールやビルド管理ツールなどには、メールを自動で流す機能があるので、宛先をRedmineにするだけで、簡単にチケット登録できる。
緊急障害が発生した時は、チケットを起票したり更新したりする手間が惜しい場合が多いけれど、この機能があれば、チケットを関係者の情報共有の場にできる。
更に、Redmineのチケットに登録できれば、ワークフローを厳格に管理して運用もできるし、チケット終了後にRedmineの優れたチケット集計機能を使って、障害やインシデントの傾向分析を行うことも可能だ。
この機能は特に、ITILのインシデント管理に有効だろうと思っている。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「Redmine」カテゴリの記事
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
「ソフトウェア工学」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
「チケット駆動開発」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
コメント