Redmine

2019/07/03

Redmineのワークフローをバリューストリームマップで描いてみるとどう改善できるか

バリューストリームマップを使う機会があったので、ラフなメモ書き。

【参考】
VSM (Value Stream Mapping) のススメ?開発プロセス可視化? - Qiita

バリュー・ストリーム・マップを作る 22 のステップ ? リーンシックスシグマの現場

バリューストリームマップを描く時のポイント - Togetter

「リーン開発の現場」はアジャイルサムライの再来となるか: プログラマの思索

「リーン開発の現場」はアジャイルサムライの再来となるかpart2~重要な概念は仕掛り(WIP)とサイクルタイム: プログラマの思索

「リーン開発の現場」はアジャイルサムライの再来となるかpart3~サイクルタイムとリトルの法則の関係: プログラマの思索

「リーン開発の現場」の感想part4~トレーサビリティ、プロセスサイクル効率、構成管理: プログラマの思索

「リーン開発の現場」の感想part5~かんばんと因果関係図がセットで運用されるのは何故か: プログラマの思索

【1】バリューストリームマップを使ってみて、Redmineのプロセス改善に使える感触を持った。
特に、Redmineのワークフローを見直す時に有効だろうと思う。

一般に、Redmineのワークフローは既存業務のワークフローをそのままマッピングする場合が多い。
すると、ToBeでなくAsIsの業務フローをそのままマッピングしてしまうので、既存の問題点を残したままRedmineに実現してしまう。
その問題点はRedmineで可視化されるので、改善すべきだという意識改革にはつながるが、改善の方向性はすぐには決まらない。
問題点のどこに着目すればよいか、観点が発散してしまいがちだからだ。

そこで、バリューストリームマップでワークフローを見える化し、問題点を明確にしてみるやり方が有効のように感じた。

一般に、日本企業は縦割り組織なので、業務フローも縦割りで分断されてしまう為に、ワークフローが非常に長くなりがちだ。
そういう部分をバリューストリームマップで描くと、タスクは必ず担当する組織・部門で表現され、そのタスクごとにステータスが割り当てられる。
いわゆる官僚制組織になりがち。

バリューストリームマップでは、ステータスが切り替えられるタイミングで、リードタイム(経過時間)とプロセスタイム(作業時間)、作業人数を必ず書く。
この点が非常に重要だ。
なぜなら、リードタイム-プロセスタイムに当たる待ち時間が長い部分こそが、このワークフローのボトルネックだからだ。
そのボトルネックをいかになくすか、という観点がプロセス改善策につながるからだ。

【2】実際にやってみると、ワークフローの最初から最後までのリードタイムに対し、待ち時間は80%を超える場合が意外に多い。
その原因は様々だ。
たとえば、プロマネの承認、レビューアのレビュー承認、顧客の仕様変更の承認など、第三者の承認で待ち時間が長期間発生する。
あるいは、並行タスクで忙しいために、本来着手すべきタスクを放置してしまった、とか。
あるいは、IT全般統制の成約のために、開発部門とインフラ部門の間で無駄にキャッチボールしている、とか。

実際、放置チケットで、新規から完了ステータスまでの日数と、チケットで実際に作業した稼働日数を比べると、チケットの稼働率は10%とかひどい数字になりがちだ。
そういう状況は、バリューストリームマップで一目で表現できるので、どこに問題があるのか、分かりやすいメリットがある。

【3】バリューストリームマップをワークショップで描いてみて面白いと感じる部分は、全体のワークフローを知る人が実はその会社にはいない、という事実が判明した時だ。
各担当者は担当する業務だけに閉じていて、タコツボ状態になっている。
実は、ワークフロー全体を統括するプロマネがいないわけだ。
だからこそ、既存の業務フローに問題が発生しているわけだ。

Redmineで放置チケットが発生しやすい問題も、実は、チケット管理のワークフローの全体に責任を持つ人がいないことが最大の原因だろうと思う。
チケットを完了ステータスへ持っていく、という責任感をチームのメンバー全員が認識していなければ、当然、チケットが放置されても、自分は関知しない態度に落ち着くからだ。

その解決手段として、その責任感を自然に生み出す仕組みとして自己組織化が使われていたり、その責任感の重さを感じさせないような仕組みとして心理的安全性が生み出されたりしたのだろうとも思う。

アジャイル開発からDevOps、自己組織化、心理的安全性へつながる昨今のマネジメント技術の流れは、そういう一連の流れから捉えると理解しやすいと思う。

一方、Redmineによるチケット管理の観点では、チケット管理のプロセスを守る守護神は、Redmineエバンジェリスト、Redmine警察やRedmineマイスターになるのだろう。

【4】バリューストリームマップでは、LT(リードタイム)、PT(プロセスタイム)だけでなく、手戻り率や直行率を求めている点が面白かった。
そこまで計算しているのか、と。

自動車メーカーに勤務しているんですが、合格率と直行率の求め方(計算式)、... - Yahoo!知恵袋

直行率(%)=一発合格数÷製造実績数×100

たとえば、手戻り率が10%ならば、直行率=90%になる。

実際にソフトウェア開発の業務フローで計算してみると、各タスクの手戻り率を合計していくと、直行率は50%を切る場合が多かった。
つまり、完成品の中身の半分は、手戻り作業で作られたことになる。
一般の現場は知らないが、この事実を悪いと見るかどうか?

【5】バリューストリームマップをRedmineの一機能として実現できると面白いと思う。
具体的には、Redmineのワークフローにおけるステータス間の稼働日数(プロセスタイム)と滞留日数(放置日数)がグラフィックに表現されると良い。
例えば、レビュー待ち→レビュー完了のステータス間では、稼働日数は1日以下なのに、滞留日数が5日以上とか普通にありがちだ。

あるいは、1チケットのサイクルタイム(新規~完了までの日数)と稼働日数の割合を各プロジェクト、各バージョン単位で集計する、とか。
つまり、プロセスサイクル効率(=作業日数/経過日数)を表現したいわけだ。

【6】実は、この概念は「プロセスサイクル効率」として、既に「リーン開発の現場」で既に紹介されている。

「リーン開発の現場」の感想part4~トレーサビリティ、プロセスサイクル効率、構成管理: プログラマの思索

プロセスサイクル効率=作業日数/経過日数

・作業日数=実際に開発(作業)していた日数。
 ⇒WIPステージ(開発中→システムテスト準備OK→システムテスト中)で貼られていた期間。
・経過日数=サイクルタイム。
 ⇒開始日(次の10機能→開発中)から終了日(システムテスト中→受入テスト準備OK)までの期間。

「リーン開発の現場」では、プロセスサイクル効率を効率化する意識がない限り、普通の企業では10~15%程度だろうと言っている。
つまり、一般企業では、1チケットのサイクルタイムのうち、85~90%は待ち時間であり、真の稼働時間(プロセスタイム)はわずか10~15%に過ぎない事実を示している。
すなわち、チケット管理の計画を立てた時点で、チケットの予定期間の9割は無駄な時間を消費しているわけだ。

この事実が自分のRedmineに当てはまるのか、実際に試してみればいい。
Redmineでは予実の全情報が蓄積されているので、プロセスサイクル効率の検証は可能なはずだ。
もしその事実が自分のRedmineに当てはまるならば、改善すべき点が山ほどあることを示している。

Redmineエバンジェリストは、まさにそのボトルネックを改善すべき役割を担っているのだろう。

| | コメント (0)

2019/06/27

RedmineのUserPrefernceにはシリアライズしたデータを格納している

RedmineのUserPrefernceにはシリアライズしたデータを格納している記事があったので、メモ。
以下、脈絡のないポエム。

【参考】
あらためて感心したRedmineのデータ利用方法(UserPrefernce 編) - ファーエンドテクノロジー株式会社

【1】UserPreferenceには、マイページに表示したいブロックの情報がハッシュ化されてシリアライズされてテキスト文字列で登録されている。
この実装のおかげで、ログインIDに紐づく情報はシリアライズされたデータに含めることができる。

例えば、直近の機能改善「プロジェクトセレクタにブックマークと最近使用したプロジェクトを表示」には、この実装を使っているらしい。
なるほど、この実装のおかげで、プロジェクトのプルダウンが非常に使いやすくなった。

Patch #31355: Bookmarks and recently used projects for the project jump box - Redmine

「Redmine 4.1 新機能選抜総選挙」で紹介できなかった新機能 10選 - ファーエンドテクノロジー株式会社

【2】データモデリングにこだわっていると、正規化されていないデータで設計しているように思えてしまうが、プログラムの観点では、集約(Aggregate)されたオブジェクトで格納されている方がはるかに扱いやすい。
一つの情報の中に芋づる式にすべての情報にアクセスできるからだ。

一方、T字型ERでは、「エンティティが他のエンティティとの関係を内部に取り込んでいることを「純度の低下」と考えている」という立場もあるらしい。
つまり、こういう情報は別テーブルで保持すべき、という考えになる。

「ドメイン駆動設計」感想(1) - なぜファットモデルになるのか - 極北データモデリング

たぶん、この観点の対立は一昔前に流行したORインピーダンスマッチの問題点に行き着くのだろう。
昨今の流れでは、データ永続化の手段はRDBだけとは限らないので、状況に合った利用方法が勧められるだろう。

O/Rマッパーが悪いのはオブジェクト永続化にRDBを使おうとしたことが悪い | Qrunch(クランチ)

【3】上記の記事で興味を引いたのは、UserPreference と同等の機能を持つProjectPreference のようなモデルが作られれば、Redmineのあらゆる機能をプロジェクト単位で制御できるのではないか、という指摘だ。

(引用開始)
個人的には Redmine.org - Feature #4016: Make app settings overridable at project level で UserPreference と同等の機能を持つ(ProjectPreference のような)モデルが組み込まれればプロジェクトごとの設定項目を拡張することも容易になる (画面テーマなどもプロジェクト単位で設定が可能になる)はずです。これによりRedmineはさらに使い勝手が良くなると思います。
(引用終了)

Feature #4015: Make app settings overridable at project level - Redmine

以前から、Redmineの管理画面をユーザ権限やプロジェクト単位で制御したい、という話があった。
その時に、ProjectPreferenceに似たオブジェクトがあれば、機能改善の実現のハードルがすごく下がるかもしれない。

Redmineのワークフロー設定を拡張する機能提案~Redmineは汎用的なBPMツールになりうるか: プログラマの思索

この辺りも色々考えてみる。

【追記】
りょうま@夏競馬行きたいさんのツイート: "DBにJSON型がない時代にはグループウェアのカスタマイズなど、追加テーブルを作りたくない場合にシリアライズして予備カラムに投入というのはよくやってました。… "


| | コメント (0)

2019/06/13

Redmineのガントチャート改善パッチに注目しているpart2


「ファーエンドテクノロジーによるRedmine開発状況(2019年1~4月)」の記事が公開されていたのでメモ。

【参考】
ファーエンドテクノロジーによるRedmine開発状況(2019年1~4月) - ファーエンドテクノロジー株式会社

Redmineのガントチャート改善パッチに注目している: プログラマの思索

【0】2019年5月現在、@g_maedaさんの積極的なコミットのおかげで、ほぼ毎日trunkが更新されている。
内容は特に、画面UIの細かな機能改善が多い。

redmine trunk changesも合わせて読むと、コミット内容の理解も捗る。

【1】個人的に興味がある機能改善は、ガントチャート機能の改善だ。

Redmineのガントチャート改善パッチに注目している: プログラマの思索に書いたけれど、日本人のユーザの心を惹き付けるには、ガントチャート機能の改善が重要と考える。
なぜなら、日本企業はどうしてもメーカーの発想に近いWF型開発を基本に考えているので、PJ管理ツールにガントチャートは必須の機能だからだ。

おそらく、日本のRedmineユーザは、Redmine本体のガントチャート画面に独自パッチを当てている利用シーンは多いのではないだろうか?
なぜなら、Redmineのガントチャート機能は、その潜在能力が高いにも関わらず、UIも機能もまだまだ改善の余地がたくさんあるからだ。

【2】ガントチャート画面の下位WBSを折りたたむ機能が追加された。

Feature #6417: Allow collapse/expand in gantt chart - Redmine

WBSの階層と管理する職層はほぼ1対1に対応するので、この機能を使えば、たとえば、第1~3階層は経営層向け、第4層以下はチーム向けでガントチャートのビューを使い分けられる。

※画像は、Redmine本家のチケットからリンク。

【3】選択した項目をガントチャートに列として追加される。

Feature #27672: Show selected columns in gantt chart - Redmine

ガントチャート画面に担当者を表示したい要望は元々多かった。
さらに、予定・実績の開始・終了日、予定工数などもガントチャート画面で表示できれば、プロジェクトリーダーは使いやすくなる。

※画像は、Redmine本家のチケットからリンク。

【4】個人的に最も注目する機能改善は「プロジェクト一覧にフィルタ・オプション機能追加」だ。

Patch #29482: Query system for Projects page - Redmine

※画像は、Redmine本家のチケットからリンク。

SIやメーカーの大企業ならば、社内に数百以上のシステムを持っている場合が多いだろう。
彼らは、汎用機の頃から、長年数多くの社内システムを開発してきた。
すると、Redmineでシステム開発・運用保守を管理したい場合、Redmineプロジェクトに社内システムを単純に1対1に対応づけるだけでも、プロジェクト数は数百に増えてくる。
しかも、社内の申請承認ワークフロー、庶務業務、チーム単位の子プロジェクトなどを作れば、あっという間にRedmineプロジェクト数は膨大に増えてしまう。

しかし、現状のRedmineでは、全PJを一覧として見る画面の機能が弱いので、横串でPJそのものの状況を把握するのが難しい。
開発チームだけのPJ管理ならば現状のRedmineでも問題ないが、部長や役員などの経営層もRedmineを見たい場合、彼らが見たがるビューは違うからだ。
PMOや部長は、重点PJの集まり、事業部単位で複数PJを横串で状況を比較・把握したいのだ。
つまり、Redmineのユーザ層が現場のプログラマ、現場リーダーだけでなく、経営層まで拡大したことにより、PJ一覧画面を改善する動機が生まれたわけだ。

上記のパッチを見る限り、チケット一覧画面のようにプロジェクト一覧を検索できるようになる。
この機能だけでも十分ニーズに応えられるだろう。

そして、Redmineを長年運用している現場では、数百のプロジェクトを横串で参照する機能が追加されることで、いろんな使い方が提案されてくるだろう。
たとえば、PJ一覧画面で、PJの進捗率を表示したい、とか、PJメンバー人数を表示したい、とか、色々出てくるのではないか。
つまり、ほんの少しの機能改善が、ユーザの潜在ニーズを刺激し、新たな利用シーンに沿った機能改善が生まれてくるだろう。

今後もRedmineの機能改善に着目していく。

| | コメント (0)

2019/05/29

redmine trunk changesブログが参考になる

最近、redmine trunk changesブログが公開されていて、参考になるのでメモ。

【参考】
redmine trunk changes

/ - リポジトリ - Redmine

Redmine本家のリポジトリやチケットを見た後で、 redmine trunk changesを読むと、より理解が進むので便利。

著者の方は知らないけれど、福岡のRuby会議でRedmineをハックした開発者の方らしいので、いつか会ってお話してみたい。

akipiiさんのツイート: "おお、この内容は詳しく聴きたいな。RT @hanachin_: コード懇親会でRedmine本体のテストを動かしてみたらrubyがtrunk・2.6、RDBMSがMySQL・PostgreSQL・SQLite3の3環境で同じテストが落ちてrubyのバージョンやRDBMSの違いではなさそうというのが即座にわかった #rubykaigi"

Miyagiさんのツイート: "RubyKaigi参加されてますか?頭が緑色なのでもしお見かけされたらお話ください!(もし参加されてなければアルコール抜けてからリプライします…!)… "

Miyagiさんのツイート: "こういう感じです。今システム環境の時刻が日本時間のマシンでGitHubのredmine/redmineをcloneしてきてbundle installしてマスターブランチで bin/rails test test/functional/issues_controller_test.rb:358 すると再現すると思います。 https://t.co/cVqQWS1QN4… https://t.co/nONOkLU9lR"

Miyagiさんのツイート: "@yancya さんと @watson1978 さんと @jimlock さんと #rubykaigi の2つかめのあとの @speee_pr さん提供のコード懇親会でもくもくしていて見つけた感じです。 https://t.co/rODISb3AyE 時間内にバグレポ出来てなかったので今https://t.co/uLs49iin5xのアカウント登録したところ...です!… https://t.co/IBBIlOtgGw"

akipiiさんのツイート: "@hanachin_ さん、ご連絡ありがとうございます。確かにRedmine本家にパッチを送る時に、プルリクで無い事が面倒だ、という弱点はありますが、GitHubのパッチのリンクをTwitterに流してもらえれば、 @g_maeda さん他、Redmineユーザが必ず見つけてくれます。… https://t.co/6Debb5HOAd"

MAEDA Goさんのツイート: "これに関連してそうでしょうか。 Defect #30288: Group name and group count are incorrect when grouping by date (TimeWithZone) https://t.co/JHXZopn9L2… https://t.co/JprKwHV2zn"

第15回東京Redmine勉強会の感想~Redmineの2つの顔が相異なる2つのユーザ層を生み出している #redmineT: プログラマの思索にも記載したけれど、他の競合のチケット管理ツールに対し、オープンソースのRedmineが競争優位性を保つには、もっと多くのRuby開発者を巻き込む必要があると考える。

なぜなら、Jira、Backlogなどの有償ソフトウェア製品、Gitlabなどの大規模なオープンソースソフトウェアに比較すれば、Redmineの立場はすごく弱いと思うからだ。
一方、日本ではRedmineコミュニティが盛り上がっているので、コミッタやユーザとRuby開発者の間で有意義な議論ができるといいな、と思う。

今後もRedmineの機能改善に注目していく。


| | コメント (0)

Redmineにチャート画面が追加された

Redmineにチャート機能を追加されたのでメモ。

【参考】
Feature #31418: Stacked bar charts in the issue details report - Redmine

redmine-trunk-changes 2019-05-24 - redmine trunk changes

redmine-trunk-changes 2019-05-26 - redmine trunk changes

(引用開始)
チケットのサマリーから更に虫眼鏡アイコンを押した先の画面にissueの積み上げ棒グラフを表示するようにしています。
(引用終了)

※画像は、Redmine本家のチケットからリンク。

Redmineのサマリ画面では、チケットの集計情報が表示されるのですごく便利だが、数字の羅列なのでちょっと読みにくい。
しかし、チャート機能の追加により、一目でチケット集計結果が分かるようになるので、初心者や管理職にアピールしやすくなるだろう。

日々チケット運用している現場では、チャート機能がなくてもあまり困らないけれど、Redmineを時々しか見ない管理職や経営層にはインパクトが大きい機能だろうと思う。
こういうかゆい所に手が届く機能改善が頻繁にRedmineに取り込まれる点は、オープンソースならではのメリットなのかもしれない。

【追記】
2週間前の東京Redmine勉強会で紹介されたmessage_customizeプラグインの事例がさっそく公開されていた。
色々遊べそう。

Redmineの notice/error/field/setting/permission/button メッセージに”にゃん”を付加する(今のところPostgresだけ) - Qiita

| | コメント (0)

2019/05/19

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

昨日の第16回東京Redmine勉強会の感想をラフなメモ書き。
疲れているのでラフなメモ。

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

第16回東京Redmine勉強会『Ver4に上げよう Redmineのさらなる進化と多用性!』 #redmineT (18ページ目) - Togetter

第16回redmine.tokyo勉強会 まとめ

redmine.tokyo 16 感想 - アカベコマイリ

redmine.tokyo 第16回東京Redmine勉強会に参加してきました。 - みずりゅの自由帳

「Redmine 4.1 新機能選抜総選挙」で紹介できなかった新機能 10選 - ファーエンドテクノロジー株式会社

【1】昨日のRedmine勉強会でちょっと嬉しかったことは、@rechiba3 さんに初めてお会いできたことと@ohnukiさんに5年ぶりにお会いできたこと。

akipiiさんのツイート: "#redmineT 東京Redmine 勉強会から離脱しました。講演者、スタッフ、参加者の皆様ありがとうございました?? 懇親会の参加率が約7割で50人で盛り上がりが凄いと思います。今回は7年越しに @rechiba3 さんとお会いできたのが収穫でした。ユーザー層も老若男女、開発者からPMOまで幅広くて来る度に面白い"

@rechiba3 さんの下記の資料を以前読んでBlogに感想を書いたことがあったので気になっていた。

TiDDでウルトラハッピーな開発フロー実践しちゃおう!

WebディレクターによるRedmine運用事例: プログラマの思索

また、@ohnukiさんは、5年前の勉強会が大雪だった時にLTで講演して頂いたことを覚えていたから。

第6回勉強会 - redmine.tokyo

他にも@MzRyuKaさんから、懇親会でこんな話もあって盛り上がった。

みずりゅさんのツイート: "#redmineT https://t.co/XfSENoynLn 初参加、どれも凄く楽しかったけど、あえて一番を選ぶとしたら懇親会でakipiiさんとお話しできたこと。 数年前に会社のブログで書いた記事を取り上げてもらったことに、やっとお礼を言うことができました。"

チケット駆動開発の運用例part4: プログラマの思索

BlogやSNSのおかげで、実際に会ったことがなくても、すぐに仲良くなれる。
そういう場をコミュニティが提供してくれて本当にありがたい。

【2】10個以上の講演があったので、記憶に残った所だけ書き残す。

【2-1】@netazoneさん「ある工場の Redmine バージョンアップ」では、プラグイン作者にVer4.0対応を自らお願いしまくった結果、そうなったからには自分のRedmineをバージョンアップしなくては、という行動に至った気概に強く共感した。
数多くの日本人プラグイン開発者が対応してくれたからこそ、Ver4.0に安心してバージョンアップできるからだ。

つまり、Redmine本体だけでなく、主要なプラグインがVerUpに追随することは、Redmineユーザにとって非常に重要な要素である、という事実を明示していると思う。
よって、RedmineコミュニティがRedmineプラグイン開発者を巻き込んでRedmineを盛り上げていくことは、非常に重要な活動なのだ、と改めて感じた。

【2-2】@agilekawabataさん「LycheeカンバンとRedmine運用の事例紹介」では、Lycheeプラグインの機能紹介が多くなってしまったけれど、メーカーのRedmine利用事例の話に興味を惹かれた。

akipiiさんのツイート: "#redmineT 複数案件を複数チームで進捗管理するにはどうする?メーカーなら、エンジンチーム、ボディチームなどの複数チームがあるが、トラックプロジェクトと乗用車プロジェクトの親チケットから派生した子チケットは、それぞれのプロジェクトで管理したい。"

例えば、自動車メーカーでは、トラックプロジェクト、乗用車プロジェクトの2つのプロジェクトが別々にある一方、エンジンチーム、ボディチームの2チームも別々にある。
トラックプロジェクトの機能(親チケット)には、エンジンチーム、ボディチームの開発タスク(子チケット)でぶら下がるが、チームごとのプロジェクトで扱いたい。
理由は、チーム単位のタスク管理がしたいこと、各プロジェクト単位で他者には情報を見せたくないことがあるから。
現状の標準Redmineでは、Redmineプロジェクトを跨ぐ親子チケットや関連チケットは作ることができるので、ある程度は運用できるだろうが、もっと細かなニーズを実現して運用する場合は、色々問題が噴出するだろう。
おそらく、それら問題となる利用シーンでは、Redmineのカスタマイズやプラグインによる機能拡張が必要になるだろうと想像する。

つまり、複数プロジェクトと複数チームのタスク管理を横串でプロジェクト管理する手法を、Redmineが支援できる可能性がある。
そうすれば、組織をまたいだ複数案件のPJ管理のように、より大規模なPJ管理もRedmineがカバーできるようになるだろう。
本来、Redmineという一つの箱にWF型開発案件もAgile案件もデータが格納されているので、横串のデータ集計はRedmineのようなチケット管理ツールが得意な所。
その機能をさらに大規模なPJ管理にも適用していくには、Redmineにどんな機能が標準で必要になってくるのか、という問題を提起してくれた点が面白かった。

【2-3】@yassan168さんのLTでは、クラウド上でDockerを使って、Redmineを含めたサーバー構築を行った、という点が興味を惹いた。
Redmineサーバーだけでなく、リバースプロキシやDNS設定などは、オンプレサーバー上のインフラ構築作業と全く同じなのに、クラウドの方がものすごく簡単に構築できるわけだ。
オンプレミスのインフラ構築は、本当に面倒な作業だった。
たとえば、iptableをいじったり、hostsをいじったりしていたから。

しかし、@akabekobekoさんと話しながら、簡単に構築できる理由は、DockerでOSに依存しないミドルウェアの構築ができるので、後はそれらをつなぐ構成をすればいいだけ、ということで理解した。
よって、今後はAnsibleよりもDockerの方が有用だろうという気がした。

【2-4】hin-tさんのLTでは、定期的にチケット登録するプラグインを紹介していた。
営業事務の定形業務で、物忘れせずに役立つんですよ、という発言があった。
どのプラグインか忘れたので後で探しておく。

定期的なタスクをチケット登録するRedmineプラグイン: プログラマの思索

【2-5】石川さんのLTでは、message_customizeプラグインが興味を引いた。
このプラグインは、ymlに書かれた文言を修正して表示できること。
メリットは、ymlを書き換えなくても、管理画面で修正できるので、viewCustomizeプラグインに似た感覚で管理者が操作できることだろう。
すると、@netazoneさんが発した問題「海外ユーザと1個のRedmineインスタンスを共有する時、ステータスやトラッカーを日本語・英語で併記しない方法はあるか?」に対応できないか、考えてみたくなる。
一方、@g_maedaさんの話では、Redmineの画面をリロードしたらhtmlからlang=ja,enは取得できるので、その情報を元に、ログインユーザ毎に修正文言を表示できるはず、と言っていた。
たぶん、message_customizeプラグインとviewCustomizeプラグインを駆使すれば、その問題は解決可能だろうと思う。

GitHub - ishikawa999/redmine_message_customize: This is a plugin for Redmine.

GitHub - onozaty/redmine-view-customize: View customize plugin for Redmine

【2-6】堂端さんのLTでは、Redmine大阪で話したGitHub連携プラグインの続きだった。
興味を引いたのは、RedmineチケットとGitHubブランチを紐づけた後、Github上でプルリク受付、プルリク承認、masterマージという一連の作業ごとに、Redmineチケット一覧画面でチケットのアイコンが更新される機能があったこと。

つまり、GitHubからRedmineへフックさせているわけだ。
裏では、GitHubのクローンがRedmineサーバー上にあるので理解できるが、Redmineチケット一覧でプルリクのステータスをアイコンで判別できる機能は良いな、と思った。

但し、RedmineチケットとGitHubブランチを紐づける時に、「xx@#チケット番号」のようにブランチ名にプレフィックスを付ける手順がいる点は注意。

GitHub - agileware-jp/redmine_github

【2-7】@miokakusuさんのLTでは、MSのVisualStudioからTFSへチェックインする時に、Redmineチケットと同期させる仕組みを作った事例。
TFSの通知メールからRedmineとREST APIで連携する処理が面倒ですね、という話が興味を引いた。
仕掛けについては、@ryouma_nagareさんからアドバイスをもらったので理解できた。

akipiiさんのツイート: "#redmineT TFSの通知メールをRedmine がキャッチして、RESE APIで、チェックインとチケットを紐づけた。ごめん、この辺りがよく分からない。"

りょうま@redmine.tokyo終了でRedmineロスさんのツイート: "ですね。 メールサーバで受信したメールを標準出力でスクリプトが受け取る 本文解析して、チケット番号、内容、ステータスを生成 REST APIでRedmineサーバにアクセス です。メールサーバかRedmineに同居している必要もないです… "

【2-8】@naitohさんのアンケート集計では、Git利用率が下がっている点が気になった。
たぶん、Git中心で開発する場合、GitHubやGitlabだけの運用に流れているのかもしれない。
つまり、RedmineとGit連携の機能が弱い点は、今後、Redmineの弱点になってくるかもしれない。

【3】@ohnukiさんから、コミュニティ運営を褒められたことは一スタッフとして嬉しかった。

Hiroshi Ohnukiさんのツイート: "久しぶりの参加、第一印象ですが運営が素晴らしい #redmineT"

【4】Redmineコミュニティに関わって8年経つが、なぜRedmineコミュニティを継続できたのか、とふと疑問に思う。
僕はコミュニティ経験がまだ浅いけれども、過去を振り返ると、コミュニティの浮き沈みはとても激しいと感じる。
長期に渡って熱気を維持できるコミュニティは正直多くない。

その理由は、Redmineというツールが、日本における市場の潜在ニーズをうまく汲み取ってきたから、ではないかと考えた。
つまり、日本の官公庁や大企業における非効率な業務にRedmineが当てはまるケースが多いのだろう、と考える。

たとえば「プラットフォーム革命」にはこんな一節がある。
プラットフォームビジネスの機会を見つけるには、「取引コストが高い所」「複雑で見過ごされているネットワーク」「大規模で分断された未活用な資源がある所」に注目せよ、と。

この言葉を念頭に置いて、以前、CoderDojoの関係者と話していたら、まさに日本の教育業界はとても非効率な業界なので、ベンチャー企業が参入しやすいという印象を受けた。
実際、日本の学校ではIT化が進んでおらず、プログラミング教育や英語教育などの外部環境の大きな変化に揺さぶられていて、教育者だけで自力解決できず、袋小路になっている印象だ。
そんな非効率な業界だからこそ、CoderDojoなどのITコミュニティやITベンチャー企業はちょっとした改善ツールを導入するだけでも、すごく通用する。
そういう話を聞きながら、CoderDojoは本当に良いマーケットを持っているなあ、今後しばらくはその業界でビジネスをやっていけるだろう、という印象を持った。

同様に、日本の官公庁や大企業は、メールやExcel帳票の文化で凝り固まっている現場が多いので、昨今の最先端のIT企業から見れば、非効率極まりない利用シーンが非常に多く見受けられるだろう。
だからこそ、そういう業務にRedmineを単純に導入するだけでも、それなりの改善効果を得やすい状況があるのだろう、と思う。
よって、そういう非効率な市場が残っている限り、まだ今後しばらくは、Redmineは日本で根付いていくだろうと思っている。

| | コメント (0)

2019/05/07

第16回東京Redmine勉強会の見所 #redmineT

来週末に行われる第16回東京Redmine勉強会の見所を書いておく。

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

第16回redmine.tokyo勉強会 みどころ

「エンジニアの知的生産術」読後メモ(自分用) - Qiita

【1】今回のテーマは『Ver4に上げよう Redmineのさらなる進化と多用性!』。
テーマに関しては、スタッフ内で議論が色々あった。
ViewCustomizeプラグインをもっと使った事例が欲しいね、という話から、多様な講演内容がそろったと思う。
Redmineの利用事例がかなり増えたおかげで、色んな人達が自分なりの改善ノウハウを持っているみたいだ。
そんな話が聞けるのが面白い。

【2】いくつか興味深い講演はある。

一つは、アジャイルウェアの川端さんの講演「LycheeかんばんプラグインによるScrum開発事例の紹介(仮)」。
最近、Lycheeかんばんプラグインの評判がいいので詳細を知りたい、という話から講演が決まった。

チケットボード | Lychee Redmine(ライチレッドマイン)でプロジェクトの見える化を。そして管理ももっと楽にしよう。

標準Redmineでは、チケットという元ネタはあるが、それを多種多様な利用目的に応じて集計表示できるビューの機能は少ない。
そこで、チケット集計に関する数多くのプラグインが生まれてきた。
その中で、かんばんというビューは、色んな使い方ができる可能性がある。

本来、かんばんはアジャイル開発に最も適した進捗管理用のビューだ。
たとえば、タイムボックス形式で、タスクをフローで管理する。

しかし、WF型開発でもかんばんは有効な場面が多い。
特に、結合テストや総合テストなどのテスト工程では、障害管理とかんばんは非常に相性が良い。
日々溢れ出てくる障害を一つずつ潰していくには、かんばんのように、日々の作業ステータスがリアルタイムに見れる方が管理しやすいからだ。

一方、かんばんは担当者の手持ちの作業が明確に判別しやすい。
日々の作業がスムーズに流れているならば、特に朝会とセットで運用すればいい。
WIPを導入すれば、チームの能力に合わせたリソース管理がしやすくなるはずだ。

「Lycheeプラグインは500社以上の導入事例がある」とWebページで記載されているので、個人的には、日本の企業はRedmineにどんな事を期待しているのか、そして、Redmineの標準機能のどこに不満を持っていて、Lycheeプラグインがどうやって上手く適合してきたのか、という点が知りたい。
つまり、日本企業とRedmineがなぜ相性が良いのか、という本質を聞いてみたいわけだ。

【3】もう一つは、多様で盛り沢山なLT。

@forenoonMさんの「ViewCustomizeのHTML埋め込みによるRedmineの機能拡張」は、一時期ツイートで有名になった「Redmine上で動くティラノサウルス」のことかな、と思う笑。

akipiiさんのツイート: "面白すぎる!RT @netazone: Redmine に例の「暴れ回るティラノサウルス」降臨。 ありがとう @forenoonM 。 そして view customize plugin をこんなことに使ってごめんなさい https://t.co/5L3jSWuPV5"

akipiiさんのツイート: "元ネタはこれでしたか!RT @forenoonM: Redmineに例の「Wordで暴れ回るティラノサウルス」をそのままリアルタイムレンダリングしてみた。さすがはView Customize Pluginとthree.jsだぜ! https://t.co/xZZG0efuji"

他にも、Git連携や構成管理ツールTFSに関するLTが3本もあるので、やはり構成管理ツール連携の機能はニーズが多いのだろうと思う。

【3】@MadoWindaheadさん「カスタムクエリーを使って状況を見やすく斬る」、@yuki476さんの「チケット文化定着までに気をつけたこと」、hin-tさんの「(仮)毎月のTodoを自動チケット作成プラグインでもっと簡単に」のLTは、Redmineの運用方法に関する講演で興味がある。

@MadoWindaheadさんと話しながら、「エンジニアの知的生産術」本にある一節「タスクの優先順位付け」を思い出していた。
その本では、タスクの優先度付けの話があり、優先度をつける観点1の最優先、または、観点2の最優先が本当の全体最適ではなく、観点1と観点2の中くらいが利益最大になる場合もある、という話があった。
つまり、制約条件が複数の場合、全体最適な解は線形計画法で計算するパターンになる。
よって、人間の頭ではすぐに全体最適の解を見つけるのは難しいので、あえて1次元に落としているのかな、と思った。
1次元に落とせば、ソート順に並べるだけで優先度が即座に決定されるからだ。

実際、タスクの優先順位付けこそがプロジェクトリーダーの最大の仕事だ。
しかし、タスクの優先順位付けの解空間は、そのパラメータの個数分であるN次元空間になるが、変数の個数が多かったり、説明変数が相互依存していたりするなど、人間の頭では処理しきれない。
よって、あえてN次元→1次元へ射影して単純化することで、スピーディに優先順位付けできるようにする手法が、特にScrumのProductBacklogなどのアジャイル開発で発達してきた、と考えている。

一方、解空間の次元を落とすことは、必要な情報も削ぎ落としているリスクがあり、それにより優先順位付けを間違えている可能性も大きい。
その辺りのトレードオフをどのように解決するのか、@MadoWindaheadさんが自身の経験談を元に、どのように解決してきたのか、を聞いてみたいと思う。

【追記】
着々と準備は進んでいるみたい。


neta@ 5/11(土) Redmine 4.0 化(まもなくしぬ)さんのツイート: "Today I upgraded my main #redmine to 4.0 ! I am grateful to all Redminers (developers and plugin authors, users)! :) … https://t.co/fxwhF8o7HI"


第16回redmine.tokyo開催前夜に、仲間と愉しきやり取りをメモした。
ときめくバグチケットとは? 第16回redmine.tokyo開催前夜の眠れぬ夜の会話- Togetter

| | コメント (0)

2019/04/07

「プログラミングのできる羊とできない山羊を区別する方法」の記事のリンク

「プログラミングのできる羊とできない山羊を区別する方法」の記事をリンクしておく。
プログラミングの向き不向きに関する興味深い記事。

【参考】
プログラミングできる人とできない人との間の深い溝 - masatoi’s blog

(引用開始)
実に多くの人がリンクしているこの論文(PDF)では、プログラムやプログラミング言語に触ったことがない学生達を対象に、「プログラミングのできる羊とできない山羊を区別する方法」を提案している。
おしなべてプログラミングの教師はプログラミングができる学生とできない学生の二つの山ができることに気付いている。それぞれの山は独立な正規分布を成している。プログラミング教育に関する研究のほとんどすべてが教授法についてのものである。すなわち、言語を変え、応用分野を変え、IDEの利用法や仕事へのモチベーションの維持について教えるわけだ。しかしそれらの試みはなかなか上手くいかず、二つの山は依然として残り続けている。
(中略)

この論文の著者は計算機科学における最初のハードルは以下のようなものになると仮定している。
代入と系列
再帰 / 繰り返し
同時並列性

上から順にハードルは高くなっていく。従ってテストは新米プログラマに対する最初のハードルである代入から始めていく。このテストの結果は3つのグループに綺麗に分かれる。
学生の44%は代入がどのように働くかについて一貫したモデルを持つに至る(たとえ正しくなくとも)
39%の学生は代入のモデルとして一貫したものを形成できない。
8%の学生はふてくされて回答を空白のままにする。

このテストは2回実施された。最初の一回目を何の説明もなしに行い、3週間後にもう一度行った。印象的なことは、一回目と二回目では実質的にグループの変化がほとんど無かったことである。つまり、一回目のテストであなたが心の中に一貫したモデルを得られるかどうかが最初のハードルになっている。
著者はプログラミングができることと一貫したモデルを心に持てるかどうかの間には極めて高い相関があることに気付いた。
(引用終了)

つまり、プログラミング教育の講座では、プログラミングにすぐに慣れる人と、プログラミングがずっと分からない人から成る正規分布の2つの山に分かれる現象らしい。
確かにそうかもしれない。

個人的に興味があるのは、小学生からプログラミング教育が義務化された状況において、プログラミングを知らない子供がどうやってプログラミングのスキルを習得していくのか、を観察してみることだ。
子供が母国語を自然に覚えるように、プログラミング言語を自然に習得できるのか?

それとも、40代を過ぎたおじさんがTOIEC対策のために英語習得に非常に苦労している風景と同じく、プログラミング初心者も、通常の論理体系とは異なるプログラミング言語を習得することに、非常に苦労するものなのか?

上記の記事を理解した後で振り返ると、数学の公理体系と同じく、それ自体は無意味な論理規則の集合体であるプログラミング言語をどうやって操れるようになるのか、その習得過程に興味がある。
それが分かれば、ソフトウェア開発の難しさという本質に触れられるような気がするから。

| | コメント (1)

2019/03/10

第19回Redmine大阪の感想 #redmineosaka

昨日の第19回Redmine大阪が無事に終了した。
スタッフの皆さん、参加者、そしてJiraやBacklogのパネラーの方、ありがとうございました。
感想をラフなメモ書き。
Mroongaはまだ分かっていないので、間違っていたら後で直す。

【参考】
第19回 Redmine大阪 - connpass

第19回 Redmine大阪(2019/3/9) #redmineosaka - Togetter

第19回Redmine大阪の見所 #redmineosaka: プログラマの思索

redmineエバンジェリストの会 メンバー4人がRedmine大阪へ

続・姫路IT系勉強会で

Node.js meets Redmine (第19回 Redmine大阪 LT発表内容)|足羽川永都(あすわがわえいと)|note

【1】今回の勉強会では、参加者層が多様だったので、大変盛り上がったように思う。
大阪圏の参加者だけでなく、東京・名古屋・福井・京都・神戸・姫路・松江・福岡などの遠方から多数の参加者があった。
また、Jiraのエバンジェリストの方も来て頂いて、チケット管理ツールに関する有用な議論もできた。

直前のキャンセルがあったにも関わらず、補欠の参加者が全員参加されて、参加率100%超になったのはすごいな、と思う。
それだけRedmineのニーズが広がっているのかな?

【2】@akahane92さんの講演では、特に全文検索プラグインの仕様と性能評価が興味を惹いた。

Redmineチューニングの実際と限界 - Redmine performance tuning - Speaker Deck

clear-code/redmine_full_text_search: Full text search for Redmine

@akahane92さんの会社では、クリアコードさんと共同開発して、GitHubに公開されている全文検索プラグインに対し、RedmineのチケットやWikiなどの全文検索を更に強化した機能も含めて公開されている。
今後は、添付ファイルやSVNなどのリポジトリ情報も全文検索の対象としてプラグインの機能に含めていく、という。

【2-1】この講演内容を聞いて重要と考えた事は2つある。
一つは、メーカーという知的財産に非常にセンシティブな企業であっても、オープンソースの方が価値がある、という考え方に同意してくれていること。

もう一つは、Redmineに蓄積されたチケットやWikiだけでなく、添付ファイルや構成管理ツールのリポジトリ情報もテキスト情報として全文検索の対象に含めること。

Redmine本家では、添付ファイルの全文検索も機能追加するチケット(Planio提供 #306)があるが、@g_maedaさんや@akahane92さんに聞いた所、Redmineの検索機能が更に劣化する可能性があること、パッチの規模が大きすぎることから入らないのではないか、とのことだった。
しかし、全文検索プラグインでその機能が実現されるならば、問題はない。

Redmineチューニングの実際と限界 - Redmine performance tuning - Speaker Deck

つまり、全文検索プラグインによって、Redmineに蓄積されたチケット・Wiki・添付ファイル・リポジトリは全て検索対象となり、Redmineを真のナレッジ基盤として実現できるわけだ。

(引用開始)
Redmineのファイル内容 全文検索
添付ファイルの内容検索がパッチとして提供されている(Planio提供 #306)が、 大量の添付ファイルを検索対象とした場合、全文検索の性能は低いと予想される。
想定される課題は3点:

1)検索処理時間
実運用環境の35万ファイルを使用して、全文検索(非索引型)の応答性能を計測すると、10億文字分の検索処理が長時間かかってしまい、日常的に使うには性能が不足するだろう。将来のデータ増加を最大200億文字と想定すると、このままでは厳しい。
→ Full Text Searchプラグインによる、検索機能の拡張開発「添付ファイルの索引型高速全文検索」により改善できる(もうすぐ)
2)検索結果の精度
SQL検索では探している情報が大量のデータに埋もれてしまうため、見つけるまでに時間がかかってしまう。
→ Full Text Searchプラグインによる、 検索機能の拡張開発「高精度検索」により改善できる(予定)
3)リポジトリ内容の検索機能が無いため、ソースコード検索、ドキュメント検索ができず、効率が悪い。
→ Full Text Searchプラグインによる、検索機能の拡張開発「リポジトリ内容の索引型高速全文検索」により改善できる(予定)
(引用終了)

【2-2】@akahane92さんに聞いた所、Redmineの全文検索プラグインでは、プロジェクト単位に全文検索できる仕様が重要である、という点が興味を惹いた。

なぜなら、プロジェクトは新製品開発など、情報アクセスに厳しい制約があるため、Redmineユーザは所属しないプロジェクトにアクセスできない仕様が必要だからだ。
おそらく、ISOやISMSの制約上、重要な機密情報は限定されたユーザだけがアクセスできるような仕組みが必要なのだろう。
Redmine本体の検索機能には、既に検索時の絞り込み条件が設定されているので、問題ないわけだ。

【2-3】全文検索プラグインの実装仕様、特に機械学習によるAI検索について、@akahane92さん、@ryouma_nagareさんの説明を聞いて、ようやく概要を理解できた。

チケット登録時に、チケットの情報とともに、Mroongaが検索用インデックスを保持する。
Redmineで全文検索を行う時、その検索用インデックスを使うので検索時間はかからない。

また、Mroongaが保持する検索アルゴリズムは、定期的にメンテナンスする。
例えば、Redmineの外で、GPUを使った特別のサーバーを用意して、AIエンジンで別途、機械学習させて、その学習結果をMroongaに週1回または月1回のように定期的に取り込む。
したがって、Mroongaの検索アルゴリズムは定期的にアップデートして、Redmineの検索精度を高めるように運用すればよい。

僕はMroongaを機械学習エンジンと勘違いしていたが、そうではなく、全文検索用の語彙表テーブルとインデックスカラムを自動生成してくれるミドルウェアだと理解した。

他に、お話を聞くと、MroongaはRedmineのver3.4, 4.0にも対応済みらしい。
そしてOSS化されている事から、MroongaはRedmineの最新版に追随してくれることが期待できる。

【3】アジャイルウェアの堂端さんのGitHub連携プラグインのデモも興味深かった。

仕掛けとしては、RedmineでGitHubの接続情報を設定しておくと、Redmineサーバー上にGitHubのBareリポジトリが作られて、そのリポジトリをRedmineが参照すること。

agileware-jp/redmine_github

【4】JiraとBacklogパネラーを含めたパネルディスカッションも面白かった。

BacklogやJiraが向いていない利用シーンは、大規模なWF型開発の案件です、という発言を聞いて、Redmineのチケットやプロジェクトの階層無制限の機能がそこに有効に作用している、という点を改めて認識した。
つまり、日本の企業でRedmineが好まれているのは、従来のWF型開発にとてもフィットしているツールとして使われているからだろう。

【5】今回の勉強会を一スタッフかつ一参加者の立場で楽しんだ後、Redmineコミュニティは今後どのように進んでいくのだろうか、と思った。
懇親会でも、最近の東京Redmine勉強会は盛り上がっているが、Redmine大阪はどうなんですか、という質問もあった。

僕は、JiraとBacklogのパネルディスカッションを聞きながら、2011年当時のチケット管理ツール大決戦のイベントを思い出していた。
2011年のRedmine勉強会発足当時、大阪や東京のRedmineコミュニティではアジャイル開発者が率先して試行錯誤していた。
たとえば、以前は、@daipresentsさん、岡本さん、小久保さんなど数多くのアジャイル実践者は、Redmineでいかにアジャイル開発を運用するか、を試されていた。
その過程で、Scrumのプラグインを作られたり、Gitと連携するプラグインを作られていた。

しかし、その後、Redmineのユーザ層が変化したように思う。
実際、最近のRedmine勉強会のユーザは、PMOやSEPG、情報システム部門のユーザが多い。
また、Redmineを全社で展開しているので、Ruby開発者よりもインフラ関係のエンジニアが多いように思う。

つまり、Redmineのユーザ層は、アジャイル開発者ではなく、日本のソフトウェア開発や現場の業務に合うように実運用する立場の人達に変化した。
そんな流れを振り返ると、日本のユーザはRedmineが自分たちのニーズに向いていることに気づき、多種多様な現場に片っ端から適用してみることで、Redmineをより深く理解しようとしているのではないか、と思った。
今回の勉強会では、そんな気づきがあった。

| | コメント (0)

2019/02/24

RedmineとAIエンジンを連携する事例のリンク

RedmineとAIエンジンを連携する事例があったのでリンクしておく。
以下は自分が理解した内容のラフなメモ書き。
間違っていたら後で直す。

【参考1】
その問い合わせ、AIが解決します!~Redmineチケットレコメンドシステムのご紹介~ | Future Tech Blog - フューチャーアーキテクト

社内ヘルプデスクをAIで! | Future Tech Blog - フューチャーアーキテクト

【1】後者の事例は、チケットの内容をAIエンジンが自動判断して、カテゴリ振り分けを自動設定する。
前者の事例は、チケット登録時の情報を元に、AIエンジンが類似チケットを自動で関連付ける。

上記の例で興味深い内容は、下記の点だ。

(引用開始)
検索アルゴリズムは、「類似文書検索」と「キーワード検索」のハイブリッド手法を用いることにより、より精度を向上させる試みを行いました。
類似文書検索は、機械学習のトップカンファレンス1 で発表されたSCDV(sparse Composite Document Vector)と呼ばれるEmbedding手法を用い、キーワード検索は現在有力とされているBM25を用いました。
本システムのもっとも肝な部分は、SCDV(文書検索)×BM25(キーワード検索)のハイブリッドアルゴリズムを実装した点にあります。
(引用終了)

なるほど、類似文書検索とキーワード検索を元に、チケット内容の類似度の度合いを相関関数で測定して、精度を高めているわけだ。
類似文書検索だけ、キーワード検索だけ、ではなく、2つを組み合わせた多重度分析にして重みを教師あり学習で精度をさらに高めている点は、面白いな、と思った。

【2】アーキテクチャとしては、AWS上にRedmineとJenkinsとAIエンジンがあって、Jenkinsが定期的にRedmineをポーリングしてAIエンジンに連携し、カテゴリ振り分けや類似チケットを推定して、Redmineへ情報を返却する流れみたい。
Redmineのチケットにカテゴリ振り分けや類似チケットを関連チケットとしてリンクさせる処理は、RedmineプラグインまたはREST APIで実装しているみたい。

確かに、Redmineの外側にAIサーバーを置いて、Redmineのデータを定期的に渡すようにするサーバー設計ならば、既存の仕組みを組み合わせるだけで作れそうな気がする。
Redmineのデータをやり取りするI/Fの部分だけは、REST APIやRedmineプラグインで実装すればいい。

この発想は、Redmineの外部にBIサーバー(例えば、Tableauとか)を置いて、Redmineのデータを定期的に集計表示させる仕組みにも似ている。
つまり、Redmine単体はチケットというデータ収集基盤とみなし、AIサーバーやBIサーバーがRedmineのチケットを定期的に取得して、類似データを分析したり、いろんな観点のメトリクスを集計する仕組みが作れるわけだ。

【3】上記の事例は非常に面白い。
なぜなら、「少人数・短期間で、簡単に構築することができた」からだ。
つまり、RedmineとAIエンジンを組み合わせる手法は、昨今のOSSライブラリを上手く流用できれば、そう難しくないのだろう。

現在、Redmineを長年運用してチケット枚数が数万~数十万件まで蓄積された開発現場はたぶん、割と多いのではないか、と思う。
AIサーバーで類似チケットを自動設定したり、カテゴリ振り分けを自動設定したりする事例があるならば、他に、別のチケット振り分けの観点でチケットの属性にデータを設定する機能も実現可能だろう。
つまり、@ktohさんが以前話していたように、Redmineにスマートナビまたはコンシェルジュのようなエンジンを実現することで、チケット入力者に事前に情報を提供したり、チケット入力を支援することも可能だろう。

この辺りのアイデアは色々考えてみたいと思う。

| | コメント (0)

より以前の記事一覧