チケット駆動開発

2021/01/04

変更管理プロセスが弱いとトラブルが多い

以前、ITILの研修を受けた時、講師から「変更管理プロセスが弱いとトラブルが多い 」という話を聞いて、非常に心に残った。

【1】ITシステムは変更に起因するインシデントによって、必ず変更が起き、それが遠因となってトラブルが起きやすい。
例えば、OSやソフトのバージョンアップ、システム移行、マイグレーションなど。

つまり、今まで「あるべき姿」で稼動していたのに、ある時点で「おかしくなった現在の姿」へ方向が変わり、時間が経つにつれて、ギャップが生じる。
このギャップがトラブルだ、と。

だからと言って、ITシステムの変更を生じるインシデントを全て拒否することはできない。
むしろ、ITはバージョンアップすることで、使いやすくしていくのが最大の特徴だから。
そこに矛盾がある、と。

【2】ITシステムは変化があって当然だし、その変化を受け入れて、その変化をコントロールする技術を持つことが重要だ。
その技術が、変更管理プロセスであり、構成管理プロセスであったりすると考える。

つまり、プログラミングやモデリングそのものに問題があるわけではない。
それら技術の進化が激しく、5年も経てば老朽化が当たり前で、5年おきにリプレースしてシステム移行だけでなく業務移行も伴う。
そういう変化をコントロールする術をあなたは持っていますか?と問われている気がする。

ITILはそういう変更管理プロセスに着目した考え方だと思う。

僕は、そういう変化をコントロールできる開発基盤として、Redmine+Gitが必要ではないか、と考えている。
そのアイデアも膨らましてみる。

変更管理の基盤は構成管理が支えている: プログラマの思索

XDDPと言う派生開発: プログラマの思索

派生開発プロセスXDDPの講演メモ: プログラマの思索

開発プロセスを管理することでしか、ソフトウェアの品質は管理できない: プログラマの思索

| | コメント (0)

2021/01/02

カンバンはステータス名が大事

カンバン仕事術」を読んで、気づいたことをメモ。

【1】カンバンの運用では、ステータスはどんな観点で作るべきなのか?

カンバンはチケット管理と相性が良い。
なぜなら、カンバンのステータスはチケットのステータスと同じだから。
チケット一覧をタスクボードでビジュアライズすれば、障害修正プロセスのどの工程でボトルネックが発生しているのか、一目で分かる。

では、カンバンのステータスはどんな観点で作るべきなのだろうか?
一般に、Redmineのワークフローでは、新規→進行中→解決→完了 がデフォルトだが、現場で運用する場合は必ず変更した方がいい。
チケットのステータスと同じ、と言っても、それぞれの現場でワークフローはかなり違う、という経験をしてきた。

たとえば、デフォルトステータスのまま運用すると、実は、ステータスに対応する担当者がいない時もあれば、複数人もいる時がある。
たいていの場合、SIの開発プロセスはインフラ基盤・デザイナー・アプリ開発・DB基盤・設計レビュー担当のように部門ごと、役割ごとに縦割り組織になっているので、割と複雑だ。
よって、ステータスが組織と対応付けられていないと混乱しやすい。

では、カンバンのステータスはどんな観点で作るべきなのか?

【2】カンバンのステータスは、役割やチームごとに割り当てる

カンバン仕事術」のイントロでは、Jiraを例として、カンバンのステータスを決める場面がある。
最終的には、ToDo→分析→開発→テスト→受入→運用待ち→本番 に決まる。
決め方は、各ステータスに役割ごとの担当者がアサインされる。

最後に「完了」ステータスがない理由は、チケットのタスクを実装して運用待ちになっても、リリース作業は別のベンダーが担当するので、自分たちで本番リリースしてバグがなかったことを見届けられないからだ。
本番リリースしたとしても、バグが出れば、また戻ってくるので、完了という呼び名が合わない、とチームで決めたからだ。

この場面を読んでいると、カンバンのステータスは、作業の役割ごとに決められる点だ。
開発プロセス、組織構造の部門ごとに、作業の役割は細分化されるので、その単位ごとにステータスが対応付けられる。
Redmineのデフォルトステータス「新規→進行中→解決→完了」ではステータスが少なすぎる場面が現実では多い。

経験上、メーカーのように生産工程が、生産計画部・製造部・品質保証部などのように縦割りになっている場合、ステータスの個数が増える傾向が多い。
メーカーの生産工程を模倣したWF型開発や、ソフトウェア工場のプロセスでは、通常のソフトウェア開発よりもさらにステータスが多くなりがち。

たとえば、開発者がバグ修正してコミットしても、テストサーバーにアップするには、構成管理担当者に連絡してアップしてもらい、別のテスターに検証してもらう、といった手間がかかる場合は、「構成管理担当者によるリリース待ち」「リリース終了・テスト検証前」のようなステータスがないと、誰がボールを持っているのか、混乱しやすい。

とは言え、現状を表したステータスをつけて、ワークフローを作るべき。

別の話では、リーン開発の考え方により、バリュ・ストリーム・マッピングの手法を使って、複雑になりすぎたワークフローをリファクタリングしてプロセス改善しましょう、というやり方もある。

【3】ボトルネックになるステータスの前に、キューを置け

役割ごとにステータスをアサインして実際に運用すると、ボトルネックとなる作業者の前に仕掛作業が滞留し、ボトルネックとなる場合が多い。
その原因を探ると、単純に、WIPが少ないからだけではない。

たとえば、受入ステータスのWIPが4になっているが、常に受入可能なチケットが埋まっているわけではない。
基本は、受入可能なチケットがあれば、担当者はすぐに検査・テストして、リリース可能と判断できれば、運用待ちステータスへ流す。
しかし、WIPが4より小さいと、テスターは常に張り付いて作業しないといけないが、出張や会議などで不在の時は対応できない。
一方、WIPが4より大きいと、テスターがフィードバックを戻す前に、開発者は別の作業に仕掛中になってしまって、すぐに対応してくれなくなる。

よって、受入フェーズでは、バッファとなる「準備完了」と、実際の「作業中」でステータスを分ける。

つまり、何らかの理由で制約がある工程の前にキュー(バッファ)を置くことで、ワークフローの一連の流れが停滞しないようにする。

キューの役割は、作業の流れを平準化することだ。
すなわち、フローの中で、流量(つまりタスク)のばらつきを抑える役割を果たす。

一般にキューは、ボトルネックとなる作業の前後で置かれる場合が多い。
たとえば、ToDo、開発準備完了、開発完了、テスト待ち、リリース待ち、レビュー待ち、受入待ち、などの呼び名がある。

キューの有無を判断するには、ステータスの入出条件、退出条件から考えればいい。

【4】カンバンは奥が深い

キューは、アルゴリズムの基本の一つ。
FIFO。
ワークフローを作る際に、流れが悪い場面で使う事が多いと思う。
ふりかえりでプロセス改善する時に、思いつきやすいと思う。

カンバンが面白いのは、2つある。
一つは、ワークフローの改善に役立つこと。
もう一つは、メトリクスやKPIを採取しやすいので、プロセス改善の材料に簡単に昇華できることだ。

なぜなら、カンバンはフロー管理に特化しているので、流量を速度にたとえれば、チケットの枚数で計測化しやすい。
完了ステータスとなったチケットはアウトプットなので、生産性にたとえられる。

カンバン仕事術」では、下記のKPIを紹介している。

リードタイム:1枚のチケットが最初のステータスから最後のステータスに入るまでにかかった時間
スループット:一定期間(例:1週間)ごとに完了したチケット数

こういうKPIはグラフ化すると分かりやすい。
たとえば、チケット完了日xチケットのリードタイム で散布図をプロットすれば、問題解決について、色々議論しやすい。
なぜ、このチケットはこんなに時間がかかり過ぎたのか?
そこからどんな原因が分析できるか?

たとえば、リリース週xスループットを折れ線グラフにすれば、納期遵守の工夫が見つかるかもしれない。

つまり、これらのKPIを開発プロセスにフィードバックすることで、各ステータスのWIPを減らしたり多くしたり、ステータスを統合・分割する解決法が見つかり、プロセスを改善する行動につなげられる。

元々、Redmineはカンバンと相性が良いので、どのKPIがプロセス改善に役立つのか、そういうノウハウも蓄積できるはずだ。
いろいろ考えてみる。

| | コメント (0)

2020/12/09

GTDは箱の使い分けが鍵を握る

GTDは興味を持つけど、なかなか使いこなせない。
GTDは箱の使い分けが鍵を握ると気づいたのでメモ。

【参考】
何かとわかりづらい GTD について、エンジニア向けにざっくり説明してみる - Qiita

GTDを噛み砕く

【1】GTDが難しいのははぜか?
Inboxに溜まったタスクをふるい分ける箱の数が多すぎて、迷ってしまうからではないか。

GTDを噛み砕く 第1章 GTD をわかった気になる

(引用開始)
ただ、この「箱」が曲者で、GTD では何個も「箱」が登場します。
(引用終了)

7 つもあるの? 何かとわかりづらい GTD について、エンジニア向けにざっくり説明してみる - Qiita

(引用開始)
GTD ではリストを 7 つほど使う。この 7 つのリストについて解説する。

7 つもあるの?
7 つというと多そうだが、「気になること」およびそこから派生するタスクには色々性質があり、ちゃんと運用したいなら役割分担がどうしても必要になる。GTD では「こんなリストがあったら便利だよね」という発想で、異なる役割を持つリストをつくって厳選した結果、7 つほどになった。

プログラミングでも神クラスをつくったりはせず役割ごとにクラスを分けたりするが、発想としては同じである。
各リストについて、名前だけ

インボックス(Inbox)
いつかやる(Someday)
資料(Pointer)
カレンダー(Calendar)
連絡待ち(Waiting)
プロジェクト(Project)
次に取るべきアクション(NextAction)
(引用終了)

GTDでは、頭の中にあるモヤモヤしたアイデア、不安なこと、ちょっとした気付きなどは全て、Inboxに吐き出す。
そこから、箱に分けていくのだが、そこで手が止まる。
どこに入れればいいのか、迷ってしまうのだ。
はじめてのGTD ストレスフリーの整理術を読むと、なぜか混乱してしまう。

結局は、それぞれの目的に箱があるだけと思えばいい。
プログラム的には、IF文で条件分岐しているだけと思えばいい。
下記のPythonプログラムが分かりやすい。

何かとわかりづらい GTD について、エンジニア向けにざっくり説明してみる - Qiita


(引用開始)
フローチャートというとひるみがちになるが、イメージとして以下のとおり、ただの条件分岐の列挙なのでひるむことはない。

def proceed_inbox(list_inbox, list_itukayaritai, list_siryo, ...):
for kininaru_koto in list_inbox:
if kininaru_koto means 'いつかやりたい':
list_itukayaritai.append(kininaru_koto)
continue
if kininaru_koto means 'あ、これ改めて見たら不要だわ':
continue
if kininaru_koto means 'これってただの情報源だよね':
list_siryo.append(kininaru_koto)
continue
...
# 全部処理したのでインボックスを空にする
list_inbox = []
(引用終了)


【2】GTDが難しい理由のもう一つが、箱を整理するタイミングが混乱しやすいこと。
「週次レビューが重要だ」とはじめてのGTD ストレスフリーの整理術でよく書かれているのだが、ピンとこなかった。
結局は、箱に溜まったタスクを整理するだけのことだ。

箱ごとに、中身を整理するタイミングは微妙に異なる。
重要度が高ければ、日次レビューだし、随時レビューすることもある。
一方、レビューのタイミングは、週末だけ、月末だけ、年に1回だけのこともある。

リストとは 何かとわかりづらい GTD について、エンジニア向けにざっくり説明してみる - Qiita

(引用開始)
各リストは以下の設定(使い方などのルールを定めた設定)を持つ。

Write Timing …… いつ書き込むか。書き込む頻度はどの程度か。
Write Content …… どんな内容を書き込むか。
Review Timing …… いつ見直すか。見直す頻度はどの程度か。
Review Action …… 見直しとして具体的に何を行うか。
要するに「いつ、何を書き込むの?」と「いつ読み返すの?読み返して何をするの?」を定める。
(引用終了)

【3】「GTDとはリスト駆動生活である」ということだ。
リストを作っておき、1日の生活をリストから駆動して、タスクをこなしていく。
チケット駆動開発と発想は似ている。

(引用開始)
リスト駆動生活とは、リストを中心に生活を回すこと。具体的には

朝起きたらリストを見る
やることが書いてあるので、一つ選んで消化する
リストに戻ってきて、次のやることを選ぶ
...
こんな生活。窮屈そうだが、リストにさえ書いておけば忘れない という状態を手に入れることができるため、ほぼ必須の概念である。

GTD では、「次に取るべきアクション」リストがこれに相当する。
(引用終了)

GTDはリスト駆動開発であり、箱の整理のタイミングを重視している。
その発想をチケット駆動開発に適用すれば、チケット駆動開発でも、チケットの整理や棚卸しはタイミングが重要だ。
チケットの整理のタイミングに対し、プロジェクトのイベントを対応付ければ、チケット駆動開発は上手く運用できるはず。

| | コメント (0)

2020/12/05

ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説

「チケット駆動開発がまわりはじめるまでの取り組み」のAdventCalendar記事を読みながら、ツールとプロセスの因果関係や、良い組織文化を生み出すきっかけは何なのか、を改めて考えてみた。
ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説を持っている。
ラフなメモ書き。

【参考】
マインドセットに至るまでの話 - TypeError:

#ssmjp Advent Calendar 2020 - Adventar

タイムテーブル「チケット駆動開発がまわりはじめるまでの取り組み」 | Redmine Japan

【1】僕がすごく興味を惹かれて、同感したのは下記の言葉。

(引用開始)
ゴールの明文化し全体像・規模感を見通し 「誰が」「どこまで」「何を」するのかの明確化しチームで同じゴールを目指して進めていくということに対してチケット駆動開発が非常に強力なツールであることを最後に改めて実感しました。
(引用終了)

困難な状況に直面しているプロジェクトを運営したり支援する立場にいると、技術やプロセス云々ではなく、まず火消しを行って、チーム全員が地に落ちたモラールに火を付けて、プロジェクトのエンジンを回す所から始めるのが必要な時がある。
しかし、火消しはできるが、メンバーのモラールを高めるのは割と難しい。
色んな事情や背景はあるだろうが、何をやっても駄目じゃないのか、みたいな負け犬みたいな雰囲気が出たり、それは私の仕事や責任範囲ではないですから、みたいな縦割り組織の雰囲気があったりする。

それを解決する手法は色々あるし、既に知られているものも多いだろうが、僕は、結局は、ショートカットせずに王道のスタイルを貫くしかないのだ、と思っている。
プロジェクトリーダーはリーダーシップを発揮して、共通目的を掲げてメンバーと共有し、メンバーに権限を委譲し、業務と責任を一致させて、メンバーと目標を共有して、目標を達成するための意欲を引き出す、という王道の方法しかない。

そういう状況において、道具立てとしてRedmineがあって、そういう組織文化を生み出すプロセスとしてチケット駆動開発を当てはめると、メンバーのモラールを向上させる仕組みが整った、という事例ではないか、と思っている。

【2】ツールがプロセスを明確に定義し、プロセスがメンバーのモラールを引き出し、プロジェクトの推進力を加速させる。
たぶん、そういう仕組みを作ることが、プロセス設計であり、プロジェクトリーダーが本来やるべき仕事であるはずだ。

そういう方法を実現する為に、チームビルディングの手法が特にアジャイル開発では数多く生み出されてきているし、参考にもなっている。

ツールでプロセスを透過的に設計して、メンバーにはプロセスを意識させずに運用してもらうが、実はそのプロセス設計にチームビルディングの手法やアジャイル開発のプラクティスを植え付けておけば、自然に、メンバーの自発的な行動を促し、チームはどんどん加速していく。
そういう仕組みを本来は作りたいはず。

スケジュールを厳格に予実管理してメンバーを半ば脅して、進捗遅延の責任を取らせる管理手法がやりたいことではないはずだ。

【3】では、メンバーの貢献意欲やチームの活性化を促すのは、ツールなのか?プロセスなのか?

以前の僕は、Redmineでいかにアジャイル開発というプロセスを実装するか、に興味を持って色々試行錯誤していた。
その結果を振り返ると、結果的にメンバーの自発的行動を促し、チームは活性化するという気付きが得られたが、当初は、Redmineというツールがチケット駆動開発を生み出し、Redmineがチームを活気にさせる仕組みを生み出している、と思っていた。
つまり、ツールがプロセスを生み出し、そこからチーム運営が上手くいく結果が得られたことから、ツールこそが全てだ、と思っていた。

しかし、考え直してみると、アジャイル開発というプロセスが、メンバーに責任感と自律性を促し、チームを活性化させたのではないか、と思う。
アジャイル開発にはプラクティスが豊富で、チームビルディングの手法が様々にあるので、メンバーやチームに自然に影響を与えて、自然に良い行動を促すように仕向けることができる。
すなわち、ツールはプロセスを生み出すが、プロセスの良し悪しがメンバーの貢献意欲やチームの活性化に大きな影響を与えているわけだ。

【4】以前の僕は、官僚化した日本企業がもたらす組織構造によって、Redmineというツールで実装したプロセスがどんどん複雑化する点に興味を持っていた。
「アーキテクチャは組織構造に従う」というコンウェイの法則が、実は、Redmineにも見られる、という点に驚いて、非常に興味深かったからだ。

一方、最近では、メンバーの貢献意欲やチームの活性化を促す組織文化はどうやったら生まれるのか、に興味を持っている。
そもそも、プロジェクトリーダーや中間管理職、経営層にとっては、会社を活性化させる組織文化を作り出す方に大きなインセンティブがあるはずだ。
彼らは、最終的に、戦略に基づいた事業に利益をもたらすための組織文化をいかに作り出すか、に腐心している。

今の仮説は、ツールが定義したプロセスの設計が上手くはまれば、メンバーの貢献意欲や責任感、チームの一体感や使命感を生み出すことは自然にできるはず、というものだ。
では、どんなプロセスで設計すると、メンバーの貢献意欲やチームの一体感を生み出すことができるのか?

この仮説を色々試してみたいと思っている。

| | コメント (0)

2020/10/28

チケット管理ツールの用途が変わってきている

チケット管理ツールのクラウドサービスAsanaの記事を読んで、チケット管理ツールの用途が変わってきていると感じたのでメモ。

【参考】
チームの仕事、プロジェクト、タスクをオンラインで管理 ・ Asana

Asanaが好きなもので。|なかやけんいち|note

Asana - Wikipedia

asanaの活用方法を徹底解剖!基本的な使い方から応用編までご紹介 |マケフリ

タスク管理ツールAsana(アサナ)とは?特徴や使い方を徹底解説

(引用開始)
人によって「使いやすい」の基点が違う
そして困ったことに「使いやすさ」「快適さ」は職種や人でそうとう異なるんですね。そもそもプロジェクト管理ツールに対する期待値や使う人の環境が違うという問題があります。

エンジニア系の人々は「プロジェクト」という生物を飼育するための運営連絡帳的な視野で利用しているようです。
飼育してる生き物(プロジェクト)が突然病気になったり死んでしまわないよう、チームみんなで協力して連絡帳つけましょう、やるべきことしっかりまとめましょう、とかなり几帳面に運用します。そして当然のように仕事の間ずっと目の前にPC画面があるので頻繁に丁寧にアクセスして記入してくれます。

非エンジニア系=管理・営業・マーケティング系の人々は「パーティ開催の準備リスト」的な視野で利用しているようです。
すべきことのリスト作りは直感的にスピーディにできるのが理想的。そして突発的なタスクの発生・変更にも対応し易く、メンバーが相互に確認できる手軽さが大事です。そして、打ち合わせなどの移動中などにスマホなどからさっと確認・処理できるのがうれしかったりします。
こうした違う種類の人たちが混在するプロジェクトのニーズを同時に満たすのは簡単ではありません。まさに今この瞬間にもうまくいかないと困ってるチームはあると思います。

あえて「エンジニア系」と「非エンジニア系」と書いてみましたが、細かいことを言い出すと、同じ職種でも人によって「快適」のツボは異なったりして、全員が満足するツールを見つけるのはなかなか大変です。
(引用終了)

自分はエンジニア系なので、ソフトウェア開発のプロジェクトを管理したい。
だから、プロジェクトが変な方向に行かないように、成果物とチケットの更新履歴を見ながら、頻繁にチケットを更新して、メンバー間のコミュニケーションを取るようにする。
朝顔に水をやり、変な虫を取り、こまめに手入れするみたいな感じ。
社内の定型業務や一般業務の管理も同じイメージだろう。
Scrumのバックログでチケットを登録して、それらを逐一細かく追跡したい。

一方、営業・マーケティング系の人たちは「パーティ開催の準備リスト的な視野で利用している」指摘が面白い。
確かに、エンジニア系の人でも、コミュニティでのイベント管理や日々の運用管理では、成果物とそれに紐づけた作業の2つを管理するよりも、今どれだけの課題やタスクがあって、抜け漏れはないよね、という点を確認したい。
もっと気軽にチケットを管理したい。
ToDo管理やGTDに近い感じで、サクサク閉じていきたい。

Redmineは良いツールと思うが、他のSaaSを見ていると、気軽に使えるな、と思う時がある。
そのあたりを色々考えてみる。


| | コメント (0)

2020/05/15

Docker ComposeにRedmineとFull Text Search pluginを入れる記事のリンク


Docker ComposeにRedmineとFull Text Search pluginを入れる記事があったのでメモ。

【参考】
Docker Compose を使って自分好みの Redmine 実行環境を作ってみた - Qiita

さらに、添付ファイルの全文検索のために、ChupaText サーバーを入れたらしい。

Docker Compose で作った Redmine だって Full Text Search plugin と ChupaText サーバーを連携させたい - Qiita

下記はまさにその通り。

(引用開始)
Redmine の良いところの 1 つに、本体だけでなくプラグインにも素晴らしい機能がたくさんあることが挙げられると思います。有志のみなさんにはいつも心から感謝しています。

しかし、Redmine は構築するのが難しいので、せっかくこのような素晴らしい機能があってもセットアップすることができずにメリットを享受する機会を失っているのではないかと危惧しております。
(引用終了)

ツイートを見ていると、Redmineのセットアップでつまずいている人も多い。
Dockerなどのツールで罠にはまらないようにしたい。

| | コメント (0)

2019/11/03

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

第17回東京Redmine勉強会が無事に終わりました。
参加者、スタッフ、講演者の皆さん、ありがとうございました。
感想をラフなメモ書き。

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

第17回勉強会 - redmine.tokyo (2019/11/2) - Togetter

第17回redmine.tokyoで自動化の極意と形式知を育む #redmineT | マドびっ! Madosan's View

【1】Redmineコミュニティは1年のうち、大阪で2回、東京で2回、合計4回行われる。
この定期的なリズムが非常に心地よいと感じている。
Redmineを通じて、運用プロセス、プロジェクト管理、インフラ周りやプラグイン開発などの情報をユーザ同士で共有できる場があるのは非常に役立つし、何よりも楽しい。
今回の勉強会で心に残った箇所だけ書いておく。

【2】前田剛さんの発表では、ファーエンドテクノロジー版RedmineであるRedMicaの発表があった。
意図としては、Redmine本家のメジャーVerUpが年1回になっているので、最新機能のパッチが取り込まれているのにユーザに使ってもらえない問題に対し、Redmineの安定版バージョンにtrunkのパッチを当てて、定期的にリリースする、とのこと。

実際、Ver4.1には200個以上の機能改善が含まれているが、1年以上リリースされていないため、せっかくのパッチが使われていない。
この問題意識は重要と思う。

(1) akipiiさんはTwitterを使っています: 「#redmineT ファーエンド版Redmine では、半年ごとにtrunkプラスで最新機能パッチを定期リリースする。リリース計画のお話。気になるのは、Redmine 本家との互換性だが、trunkベースで、相互に移行できるようにする、とのこと」 / Twitter

(1) akipiiさんはTwitterを使っています: 「この考え方は重要。RT @akahane92: 今朝リリースされた Redmica(レッドマイカ) https://t.co/bXt3Pl37Lt Redmine本家のFork版ではない。独自の機能開発は行わず、Redmine本家の機能を先行して提供することに特化するつもり。 #redmineT」 / Twitter

(1) akipiiさんはTwitterを使っています: 「#redmineT Redmine 正式バージョンのリリースが遅い問題意識あり。そこで、ファーエンドテクノロジー版Redmine として、最新機能を盛り込んだフォーク版を公開した。なるほど、パッチを取り込んだ最新機能を早く使えるようにしたいわけか」 / Twitter

一方、Redmineプラグイン開発者の観点では、RedMicaにプラグインを追随させることで、メジャーバージョンアップに事前に対応できる、というメリットもある。

(1) akipiiさんはTwitterを使っています: 「なるほど、プラグイン開発でむ有用なのか。RT @agilekawabata: RedMicaのLychee Redmine対応ですが、本家Redmineのバージョンアップに追随はインパクト大きくて急に大変になるので、定期リリースしていくRedMicaに追随していこうと思います #redmineT #LycheeRedmine」 / Twitter

気になる点は、過去にRedmineをフォークしたChiliProjectのように、Redmineコミッタとギクシャクした関係になったりしないか、という点。
この辺りは、前田剛さんももちろん考えておられて対処している、という印象を持った。
Redmine本家に追随しながら、Redmineの発展を支援していく方向になるといいな、と思う。

【3】アカベコさんのRedmineテーマの開発も興味深い。
テーマは、RedmineのUIを手軽に改善できる手法の一つだ。
沢渡さんの「Redmineをお化粧する方法」という言葉がまさに的確と思う。

(1) akipiiさんはTwitterを使っています: 「お化粧の言葉がいいですね!RT @amane_sawatari: アカベコさん @akabekobeko の講演。「あなたも作れる!Redmineテーマ」 →CSSとJavaScriptでRedmineのUIをお化粧する方法 #redmineT」 / Twitter

SCSSやDockerコマンドの説明は、初心者にも分かる様にすごく丁寧に話されてる点が良かったと思う。

RedmineのUIが古い、UIが使いにくい、という話は以前からよくあがっていた。
Redmineテーマの種類が増えたり、テーマの開発が活発になることで、よりユーザフレンドリーなUIに進化できるきっかけになるといいなと思う。

【4】@akahane92さんの全文検索プラグインのお話は、過去のIT全般統制の事例、性能チューニングの話を振り返りながら聞くと思い出深い。

akipiiさんはTwitterを使っています: 「#redmineT @akahane92 さんは、7年前にRedmine によるIT全般統制の事例を紹介された。その後、性能チューニング、そして全文検索プラグイン開発、と着々とプロセス改善されてる。そういう経過を振り返るとすごいですね」 / Twitter

僕が理解したストーリーとしては、メーカー情報システム小会社の立場として、Redmineを社内システムのPJ管理基盤として導入し、IT全般統制も取り入れて、プロセス基盤を固める。
すると、Redmineが持つチケット管理機能やトレーサビリティの恩恵を受けた後、次に出てくる課題は、チケット40万以上の蓄積されたデータを活用して、ナレッジシステム化していくこと。
もちろん、Redmineが肥大化することで、性能チューニングの課題も出てくる。

そこに、全文検索プラグインを導入することで、Redmineのチケット、Wiki、果ては添付ファイルやSVN配下の文書に至るまで全文検索の対象になり、Redmineは真のナレッジシステムになったわけだ。

@netazoneさんが全文検索プラグイン導入のLTをしてくれたが、@akahane92さんの話を聞くと、単に全文検索プラグインを入れるだけでなく、ChuperTextによる形態素解析、検索Jobの設定などミドルウェアの設定もかなり多い。
つまり、全文検索の精度向上や性能チューニングの為に相当なノウハウが込められている点は注意。

【5】パネルディスカッション「チケットを切れる人切れない人/なじむ文化なじまない文化」にパネラーとして参加させてもらった。
沢渡さんのお話は非常に軽快で楽しかった。
沢渡さんの発言から刺激を受けた内容を話したいという気持ちが強すぎて、言いたいことの半分も話せず、あっという間に終わってしまい、消化不良感が残ってしまった笑。

akipiiさんはTwitterを使っています: 「経験に基づくので参考になります。RT @amane_sawatari: 経験から学ばない残念な組織「4つのない」 ?言わない ?既知か未知か判断できない ?記録しない ?クローズしない (パネルディスカッションでの沢渡のキーメッセージ サマリ) #redmineT」 / Twitter

akipiiさんはTwitterを使っています: 「#redmineT 今日は皆様ありがとうこざいました。いつも熱気があって元気づけられます。久しぶりのパネラーで、Redmine には組織の色が出る、一方Redmine 導入でチームが活性化し、メンバーの貢献意欲を引き出してRedmine が組織文化を変える時もある、話までしたかったのに時間切れで消化不良でした笑。」 / Twitter

自分が話したかった事をここで書き残しておく。

【5-1】Redmine導入の成功パターンは経験上2つある。
一つは、トレーサビリティの概念は経験済みであったこと。
つまり、すでに開発プロセスのイメージは僕の中で持っていたので、後はRedmineにプロセスを実装するだけだったので簡単だった。

ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか: プログラマの思索

「Redmineによるタスクマネジメント実践技法」の感想を集めてみたpart17: プログラマの思索

もう一つは、システム保守のように、ルーチン作業と突発的作業が混在している環境だったこと。
こういう環境では、チケット管理ツールのような基盤がないと、正直仕事がやってられない。
沢渡さんはチケット管理ツールの特徴として「備忘録のようなもの」という発言をたびたびされていたが、システム保守の現場ではまさに備忘録の基盤が必要。
「備忘録」というキーワードは、@sakaba37さんもチケット駆動開発の説明でも使われていたので、既視感を感じた。

【5-2】チケットには「ストック」「フロー」という2つの特徴を持つ。
物理学における光が粒子と波動の二重性を持つのと同じように、チケットはフローとストックの二重性を持つ点が非常に重要と考える。

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索

Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索

チケット管理の上手な人は、チケットをストックだけ、フローだけで回すのではなく、チケットという1個のインスタンスを状況に応じてストックで扱かったり、フローに見せたりして、2つの性質を同時に使わせようとしていると考える。
一方、Excel管理では、この二重性を持たせるのが非常に難しいので、上手く回らない。

WBS駆動チケットというアンチパターンは中身がスカスカのチケット、と紹介して、他のパネラーも共感してくれた。
チケットをトップダウンでフローだけで扱おうとして、ストックにならないから、中身がスカスカになってしまうわけだ。

【5-3】沢渡さんの話で、オフショアチーム連携では、チケット管理ツールとチャットツールの2つあれば回るという経験談が興味深かった。
NTTデータのお仕事のときは、自社製のITSやチャットツールで運用されていたらしい。

akipiiさんはTwitterを使っています: 「#redmineT 今日はお忙しい中パネルディスカッションありがとうございました。オフショアチーム連携では、チケット管理ツールとチャットツールの2つ有れば回ると言う話は共感しました。」 / Twitter

僕は、沢渡さんの考えでは、仕事をする環境では、タスクや課題を共有する基盤とリアルタイムにコミュニケーションする基盤が必要なのだ、と理解した。
沢渡さんの発言の中ではたびたび、口頭でのやり取りでは後に残らないので仕事にならない、チケットに残して安心して忘れるべきだ、と話されていたが、それを実現する基盤がそれらなわけだ。

今ならば、Redmine はストック、Slackはフローで役割分担するだろう。

akipiiさんはTwitterを使っています: 「@saito0119 #redmineT Redmine はストック、Slackはフローと言う役割分担ですね。」 / Twitter

個人的には、そういうチケットやコミュニケーションする環境を作るためには、心理的安全性という概念が重要になるだろうと思っている。
チケットには、課題やリスク、バグなど、プロジェクトの悪い話が出やすい。
そういう内容をどんどん見える化して、一つずつ解決する必要があるのに、悪い話を出すと周りから叩かれてしまう、という雰囲気では、チケットを切る文化は生まれない。
この辺りも同意してくれる人が多くて嬉しかった。

akipiiさんはTwitterを使っています: 「#redmineT パネルディスカッションのチケットを切る文化の話の中で、心理的安全性の言葉に反応してくれた参加者もいてくれて、嬉しかったな。チケットにはプロジェクトの悪い話が出やすい。そういう話題を1人が抱え込まずに見える化して、皆と共有できる場にしたい。」 / Twitter

【5-4】Redmineは組織に従う、という経験則があると思う。
特に、日本では、Redmineには日本の組織の色がすごくにじみ出る。
自分たちのプロセスに強いこだわりがあるため、Redmineのワークフローやトラッカーだけでなく、RedmineのUIや機能を組織に合わせようとして、カスタマイズして作り込んでいくパターンが非常に多い、と経験上感じる。
この点は、メリットなのか、デメリットなのか?も、参加者に問うてみたかった。

僕の考えでは、メリットもデメリットもある。
デメリットは、Redmineがカスタマイズされすぎた結果、Redmineの運用プロセスが複雑になりすぎてメンバーが使いにくくなること、VerUPの追随が難しくなることがあげられるだろう。
SAPなどの業務システムがいい例だ。

また、会社標準の単一Redmineを導入したとしても、複雑すぎて、現場に合わなければ、各チームごとに立てたRedmineインスタンスが乱立し、野良Redmineがはびこってしまい、標準プロセスから逸脱してしまう状況にもなるだろう。

だが、気象庁や田村さんの事例のように、各部署にRedmineインスタンスを配布して各部署に運用を任せた方が上手く回る、という事例もあった。
つまり、Redmineインスタンスは社内標準の1個がいいのか、各部署が複数個のRedmineインスタンスで個別運用したほうが良いのか、という課題が出てくる。
この辺りも、参加者に問うてみたかった。

一方、メリットは、Redmineが組織文化を変えてくれる場合があることだ。
既存のプロジェクト管理ツールのパッケージ製品には、その会社のプロセスが埋め込まれているので、自分たちのプロセスとフィットしない弱点が多い。
しかし、Redmineは非常に柔軟なので、自分たちの組織のプロセスにフィットさせやすいため、メンバーは慣れ親しんだやり方を変える必要がない。
Redmineの導入や普及の敷居は非常に低い。

すると、Redmineを導入することで、チームが活性化したり、オフショアチームとの信頼関係が強化されたりする場面がよく見られる。
マネジメント経験の浅いリーダーが、Redmineというツールを通じてプロジェクト管理を経験して成長する場面を僕も見てきた。
つまり、Redmineという一つのツールが、リーダーやチーム、そして組織を変化させていく力を持っている。
すなわち、Redmineは組織を変革する潜在能力を持ったツールなのだ、とみなせる。

むしろ、Redmineを導入したい人は、Redmineにそういう効果を期待しているはずだ。
そういうRedmineが人や組織を変化させるような話や事例をもっと集めたいし、聞いてみたいと皆思っているはず、と思っている。

【追記】
akipiiさんはTwitterを使っています: 「#redmineT チケットを切る文化の話が定着すると、次に出てくる問題が放置チケットやチケット棚卸しになる。ぼくはここがマネジメント層の腕の見せ所と考えてる。アジャイル開発はこの辺りのノウハウが上手いと感じる。」 / Twitter


| | コメント (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/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)

2019/01/26

第19回Redmine大阪の見所 #redmineosaka

第19回Redmine大阪の見所を書いておく。

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

(引用開始)
テーマ~「次世代プロジェクト管理システム Redmine の未来を考える」
約1年ぶりに、待望のRedmine のメジャーバージョン4.0がリリースされました。
今回の勉強会では、さらに機能改善されたRedmineの解説だけでなく、下記の内容を提供します。

最新バージョンのRedmineでのチューニング結果報告
国内で代表的なプロジェクト管理ツール Redmine・JIRA・Backlog の有識者を招いて、プロジェクト管理ツールについてディスカッション

Redmineの初心者から、Redmineをバリバリ使う経験者まで、興味のある方はぜひお越しください。
(引用終了)

1年ぶりの勉強会の見所は、次の3つがある。

【1】@akahane92さんの「Redmineチューニングの実際と限界 ~ 200万チケットでもサクサクなRedmineの作り方~ 改訂4版」

Redmineチューニングに関しては、世界トップクラスの@akahane92さんが最新バージョン4.0の性能評価、チューニング技術に関して報告して頂く。
特に興味深い点は、全文検索プラグインを使った性能評価だ。

Redmineの全文検索プラグインが、Redmineにとってとても重要な理由は、Redmineをナレッジシステムとして実現する為に重要な機能であるからだ。
その理由は下記に書いた。

Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索

Redmineの全文検索プラグインには、Redmineに蓄積された過去のチケット、Wikiなどの情報を高速に検索できるだけでなく、GoogleのPageRankのように重要度の高い順にソートしたり、Amazonのお勧め商品のように類似チケットを表示する機能などがある。
この機能がRedmineに組み込まれれば、システム保守や顧客問合せなどのデータをRedmineに蓄積するほど、Redmineにその会社のナレッジが蓄積されていくので、Redmineは有用なナレッジシステムになる。
さらに、昨今の機械学習や人工知能のライブラリをアドオンで組み込むなどすれば、より的確な情報を提供するだけでなくアドバイスすることも可能になるだろう。

Redmineの全文検索を高速化するプラグインfull_text_searchのリンク: プログラマの思索

第17回Redmine大阪の感想 #redmineosaka: プログラマの思索

@akahane92さんの講演内容は今後、詳細が明らかになっていくと思うが、既にRedmineをIT全般統制(ITSMS)に適用して実運用されている背景を考えると、Redmineの全文検索プラグインがIT全般統制の内部監査で重要な役割を担っているのではないか、と推測される。

すると、ISO9001やITSMSのマネジメントシステムにRedmineをうまく当てはめる事が出来れば、Redmineの導入対象は、ソフトウェア企業だけでなく、製造業などの会社にも導入できることになり、Redmineの活用範囲が広がるだろう。
実際、既にITILとRedmineは相性が良いのは知られているので、ISO規格にあるマネジメントシステムとのフィットギャップ分析さえできればいい。
その辺りも色々聞いてみたい所。

SQIP2014の論文「「効率、品質、統制」の共通課題に着目した現場主導によるITS導入の効果検証」がすごい #redmine: プログラマの思索

Redmineの理想と現実~RxTStudy #12 「ITS活用最前線~現場からの実践報告」の感想: プログラマの思索

日本の大企業におけるRedmineの利用事例の資料のリンク: プログラマの思索

そうなると、今後の課題は、Redmineの添付ファイルも全文検索プラグインの対象に入れて、Redmineを真のナレッジシステムにすることになるだろう。
なぜなら、RedmineのチケットやWikiだけでなく、チケットに添付されたExcelファイルまで全文検索の対象になれば、より重要な情報を的確にいつでも高速に抽出できるからだ。
そうすれば、Redmineにどんどん情報を蓄積していこう、というユーザの動機付けにも役立つだろう。

Ver4.1で、添付ファイルを全文検索する機能が提案されているので、今後の動向も要チェックだ。

Redmineの添付ファイルを全文検索するパッチの可能性~Redmineをナレッジシステムにするための要件とは何か?: プログラマの思索

【2】アジャイルウェア 堂端さんの「GitHub連携プラグイン」

Redmineの課題の一つには、Git連携がやりにくい、という点が10年前からあった。
現状の機能では、Bareリポジトリを手動で作ったり、Gitlabと連携できるように構築するなど、手間がかかる場合が多い。

今回の講演では、GitHub連携プラグインを提供されるということ。
このプラグインは、Redmineユーザにとってメリットが大きいと思う。

GitHub連携プラグインのメリットは2つある。
一つは、GitHubとRedmineと連携できることで、チケット管理はRedmine、プルリクやフォークなどのソース修正はGitHubという使い分けが簡単に実現できること。
以前から、RedmineとGitlabの連携は試みがされてきたが、GitHubでも使い分けが可能になる。

もう一つは、GitHubが無料のプライベートリポジトリを使用可能にしてくれたおかげで、個人のソース管理やドキュメント管理はGitHub、プライベートなタスク管理はRedmine、で置き換えられること。

GitHub、無料ユーザーもプライベートリポジトリを使い放題に - ITmedia NEWS

GitHubが無料でプライベートリポジトリも使えることで小説家にもGitが必須になってきたのではないか: プログラマの思索

マイクロソフトがGitHubを買収した後、GitHubが非常に使いやすくなったので、GitHub連携プラグインはとてもタイムリーな内容だと思う。

【3】「プロジェクト管理ツール Redmine・JIRA・Backlog によるうちの子の良い所、他の子の欲しい所」

現在調整中だが、Redmine、Jira、Backlogという著名なプロジェクト管理ツールのエバンジェリストをお呼びして、それぞれのツールの良い所を紹介してもらい、自由に議論してもらおう、という企画。
企画の隠れた目的には、そういう議論の内容をRedmineの機能改善に役立てたい、という気持ちも込められている。
個人的には、とても楽しみな内容。

なお、このパネルディスカッションの企画を手伝っている時に、過去の「チケット管理ツール大決戦」の企画を思い出していた。
2011年のデブサミで、チケット管理ツール大決戦という企画が非常に盛り上がって、その企画がユーザ投票で3位にランクインされたのを思い出す。

チケット管理システム大決戦第二弾 Trac vs Redmine vs JIRA vs Backlog を開催しました!勝者は? - I18n and L10n in My Life

デブサミ2011レポート~チケット管理システム大決戦: プログラマの思索

[#TiDD]チケット管理システム大決戦 JIRA vs Redmine vs Trac - デブサミ2011 その3 - #itsjp #devsumi: ソフトウェアさかば

2/17: デブサミ 2011 / チケット管理システム大決戦

チケット管理システム使用状況の調査結果(デブサミ) | Atlassian Blogs

【資料公開】チケット管理システム大決戦 第二弾 | Ryuzee.com

Excel大好きな日本企業の組織文化は、たぶんその頃から変わっていないように思う。
だから、それぞれの製品のメリットを強調するだけでなく、世の中の業務の問題解決にプロジェクト管理ツールが役立てればいいなあ、と思っている。

【4】既に満員御礼になっていますが、懇親会は人数を増やせるので、懇親会からの参加もOKです。

| | コメント (0)

より以前の記事一覧