2017/07/19

情報システム部門の問合せ管理をRedmineで行う事例のリンク

情報システム部門の問合せ管理をRedmineで行う事例のリンクをメモ。

【参考】
情シスへの申請・問い合わせ管理を Redmine で効率化する | KDL 情's Cafe BLOG

neta@世界は私のオイスターさんのツイート: "イイっすね! ウチも『情シスへの依頼・問合せ』という Redmine の全社公開プロジェクトがありますが、残念ながらそこに入れてくれるのは1割程度、残りはメールか電話。 現状はこちらで起票して、チケットで返事を返してる。 早くここまでたどり着きたい。 https://t.co/RgEGCmbfpw"

【1】社内の情シス部には、社内のユーザから数多くの問合せを毎日受け取る。
単純な質問から、クレームのメール、怒りの電話まで、日々多数発生しているだろう。
情シスは、コールセンターでないのに、その業務に忙殺される時も多いのではないか。

上記の記事では、情シスの問合せで色々試行錯誤していたらしい。
やはりどこにでもある問題。

(引用開始)
情シスはもともと兼任で運用していたため、情シス宛てのメーリングリスト宛てに定型フォーマットで申請する簡易的な運用をしていましたが、下記の問題がありました。

・申請タイプが増える度に定型フォーマットを用意しないといけない(そして守られない)
 ⇒申請者、対応者双方に負担。
・誰が担当者になっているのか分かりにくい
・申請のステータス状態が分かりにくい
・メールだと情シス担当者や組織変更に伴い過去の履歴や共有が困難
・申請数や対応数など、運営業務としてのデータ分析と改善サイクルが回しにくい

そしてこれらの問題を解決するためにシステムやサービス利用も検討しましたが、スモールスタートで始めるには機能過多でした。
(引用終了)

【2】そこで、Redmineを導入してみたらしい。

(引用開始)
情シスといえば、ユーザーからの申請や問い合わせなどのユーザーサポートが多いですよね。
完全に無くなるものではないので、いかにして効率化するかというのが重要になりますが、弊社情シスでは Redmine をうまく利用すると良い感じで運用できていますので、カスタマイズ方法をまとめておこうと思います。
(2014年~のため、3年以上運用しています)
(引用終了)

(引用開始)
メール運用時代の問題はすべて解消され、運営業務としての効率は格段に向上しました。
(引用終了)

興味を惹くのは、ワークフローとカテゴリ。
ワークフローは、新規→対応中→対応済み→フィードバック→完了 のようにシンプル。
チケットを申請者と情シスの間で、キャッチボールするように扱うのがコツ。

(引用開始)
申請・問い合わせ = Redmine チケット として対応を管理しますが、申請者と情シス担当者間でチケットステータスに関する認識を合わせておくことで、「今どういう状態だったっけ?」となった時にすぐ把握できるようにしています。
(引用終了)

つまり、ステータスにアサインされた担当者がボールを持っていることになるので、ボールをできるだけ離すように回すようにすれば、自然にチケットはCloseされていくはず。

また、カテゴリを上手く利用している。
カテゴリを設定することで、申請後のチケット集計がやりやすくなるし、集計結果を元に是正対策も取りやすくなるだろう。
問合せ内容の件数を期間別に集計するだけでも、十分に見える化できるから。

(引用開始)
情シス管理対象のリソースへの申請・問い合わせを、カテゴリ、種別で整理しています。

カテゴリ例:
・PC
・メール
・ライセンス
・ファイルサーバ
・ネットワーク

種別例:
・PC アサイン申請
・PC 故障申請

定型申請は「種別」として切り出し、非定型は問い合わせしてもらい、問い合わせ内容から同じようなものが増えた場合は定型申請として専用リンクを用意する運用です。
また、「種別」は Redmine のトラッカーで分離しており、月次レポート等でどの申請・問い合わせが多いのかの分析にも利用しています。
(引用終了)

【3】他に興味深い点は、幾つかのプラグインを利用していること。

Wiki Extensions en - r-labs

About en - Issue Template - r-labs

martin-denizet/redmine_custom_css: Redmine plugin to easily input CSS to customize Redmine appearance.

Wiki Extensionsで、「FAQ や 各種手順、ポリシー など、良く参照されるものを Wiki にまとめ、グローバルメニューに表示させる」。
つまり、グローバルWikiを情シスのポータルサイトみたいに扱うわけだ。

Issue Templateで、「特定の トラッカー に紐付くチケットタイトルと本文にテンプレートを適用」する。
つまり、申請の種別ごとに説明テンプレートを作っておき、申請者が記入しやすくなるようにしておくわけだ。

Redmine Custom CSS pluginは知らなかったけれど、CSSをカスタマイズできるプラグイン。
DBマイグレーションが不要なのは良い。
「申請・問い合わせ画面としてより使い勝手を向上させるため、微修正に使っています」。

確かに、問い合わせ画面の色やレイアウトをカスタマイズした方が、ユーザにとっては使いやすくなるだろう。
個人的には、ViewCustomizeプラグインでも、ほぼ同じカスタマイズ内容を実現できるだろうと思う。

【4】最終的には、メール運用→Redmine→kintone へ移行したいらしい。

(引用開始)
当時はベストな方法でしたが、運用している中で色々と問題はあるため、今後は kintone に置き換えられたらいいなと画策しています。
管理表を Excel から kintone に移行したため、そもそも kintone で同様の運用が実現できればよりシームレスになる!
このあたりは、情シスが Excel 管理表を脱却して kintone へ移行した話としてまとめようと思っています。
(引用終了)

確かに、kintoneみたいな「超高速開発ツール」の方が、もっと自由にカスタマイズできる。
但し、kintoneは有償製品であり、外部APIで実現できない場合は部品作りも必要なので注意。

個人的には、Redmineはサポートデスクに向いているのだから、サポートデスクの運用に必要な機能はプラグインで実現すれば、基本的には十分に運用が回るだろうと思っている。
なぜなら、サポートデスクの業務は、さほど難しい内容ではないし、むしろ、その問合せの内容を随時記録していくことが重要な業務の一つだからだ。

この辺りの運用ノウハウもまとめてみたい。

| | コメント (0)

2017/07/16

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

最近、Redmineのガントチャート改善パッチに注目している。
以下、ラフなメモ書き。

【1】Redmineの導入メリットの一つは、ガントチャート機能が標準で付属している点だろう。
開始日・期日のチケット入力さえ徹底できれば、ガントチャートは即座に表示できる。

日本ではSIであれ、製造業であれ、ガントチャートによる進捗管理が普通なので、ガントチャート機能は必須の要件。
Redmineユーザの観点では、頭の固いマネージャに対しては、きれいなガントチャートを見せておき、実際の開発現場では、チケット管理でアジャイルに作業していけばいい、と思っている。

ガントチャートは所詮、マネージャ向けのビューの一つに過ぎない。
本来は、チケット管理の運用が重要なのであり、そこが上手く回れば、進捗管理のビューはガントチャート以外にもいくらでもあるのだから。

しかし、Redmineのガントチャートは、まだまだ改善の余地がたくさんある。
たとえば、FS関係の表示、イナズマ線の表示、ガントチャートの日付の表示など、いくつかの機能改善はされてきたが、MS Projectに比べるとまだ機能不足の面がある。

それらに関しては、過去に色々考えてきた。

RedmineのガントチャートはMS ProjectのWeb版になりうるか?: プログラマの思索

Redmineのガントチャート機能改善の要望チケット: プログラマの思索

Redmineのガントチャート改善part2: プログラマの思索

Redmineのガントチャートに担当者を表示するプラグイン: プログラマの思索

Redmineのガントチャート画面に暦週や日付を表示するプラグイン redmine_gantt_with_date: プログラマの思索

Redmineでガントチャートの幅を広げるパッチ: プログラマの思索

MS Projectを使いこなせない理由: プログラマの思索

【2】最近、Redmine本家にガントチャート改善パッチが出ていて、いくつか注目すべきチケットがある。

【2-1】Feature #20481: Gantt: right and left resizable panel - Redmine

MAEDA, Goさんのツイート: "Redmineのガントチャートでチケットの題名の列をリサイズできるようにするパッチ。ガントが少しずつでも改善されてほしい。 Feature #20481: Gantt: right and left resizable panel https://t.co/XVwlWJhuHG"

akipiiさんのツイート: "親子チケットの階層が深いほど、ガントチャートのパネル幅を変更したい要望が多いのですごく欲しい。RT @g_maeda: Redmineのガントチャートでチケットの題名の列をリサイズできるようにするパッチ。 https://t.co/RiHNjL3BgO"

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

ガントチャートのチケット欄の幅をリサイズするパッチ。
これはとても欲しい機能だ。

利用シーンとしては、たとえば、親子チケットの階層が5階層のように階層が深くなった場合、チケット欄が狭いとタイトルが隠れてしまうので、そんな時に幅を広げたい。
僕も、Redmineでガントチャートの幅を広げるパッチ: プログラマの思索のように、わざわざ本体のソースにパッチを当てたりしていたので、このパッチが実現されれば、個人パッチが不要になる。

日本の利用企業では、おそらく、WF型開発でRedmineを運用しているだろうから、ガントチャートのチケット欄の幅を広げる機能改善は、ユーザにとってすごく大きなメリットだろう。

そして、リサイズのパッチが実現されれば、次は、チケット欄に担当者を表示する機能改善に注目されることになるだろう。
リサイズできるようになって画面に余白ができるようになれば、担当者を表示したくなるからだ。

Redmineのガントチャートに担当者を表示するプラグイン: プログラマの思索のように、担当者を表示するプラグインなども提供されているが、Redmine本体の機能の一部になればいい。

【2-2】Feature #10485: Add new context menu in Gantt view for each issue - Redmine

akipiiさんのツイート: "これはぜひ欲しい!!RT @g_maeda: Redmineガントチャートの右クリックでコンテキストメニューを表示。 Add new context menu in Gantt view for each issue https://t.co/diIt1pmeyw"

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

ガントチャート画面上で、チケット編集のコンテキストメニューを追加するパッチ。
これも非常に欲しいパッチ。

現在のRedmineのガントチャート画面は、単純な表示機能だけであり、編集することができない。
編集するには、別画面でチケット編集画面を表示する必要があり、操作が面倒。

ガントチャートにチケット編集のコンテキストメニューがあれば、チケット一覧画面の編集コンテキストメニューのように直感的に操作できる。

パッチの中身を見ると、RedmineにはコンテキストメニューのAPIが既に用意されているので、それをガントチャート画面のオブジェクトで呼び出しているだけ。
つまり、パッチの中身は難しくないので、おそらくバグもないだろうと思うので、本家に取り込んで欲しい。

但し、このパッチで、ガントチャート編集が全て解決できるわけではない。
最終的には、下記チケットのような大幅な機能改善が必要だろうと思う。

Feature #2024: gantt chart editing - Redmine

上記チケットを見ると、2008年から2012年にかけて、数多くの日本人がパッチを提供していた。
日本の開発現場では、とても欲しい機能なのだろう。

【3】個人的には、Redmineのガントチャートは、最終的にはMS Projectが持つ機能をすべて実現する方向へ進化していくだろうと思う。
他に欲しい機能は下記があるだろう。

・ガントバーをD&Dで、期間を移動
・ガントバーをD&Dで操作して、期間を短くしたり、長くしたりする
・ガントバーの進捗率をD&Dで操作して、進捗率を設定
・先行後続の関連をD&Dで引く
・チケット欄で、チケットをD&Dして、階層間を自由に移動する
・チケット欄で、チケットを自由にソート
・予定と実績の明確な区別と表示
・クリティカルパスの表示

つまり、MS Projectにあるガントチャート機能は全てWeb画面上で操作したいのだ。
そうすれば、MS Projectのような高額なパッケージ製品を購入しなくても、OSSのRedmineで十分に運用できるようになるはず。

今後のRedmine本体の改善に注目している。

【追記】
やっさんさんのツイート: "ガントの改善もすごく嬉しいのだけど、UIとしてカンバンも標準で欲しいなぁ…。そうするとweb系の人も使うようになって本家へのフィード・バックも増え、更に開発が加速しそう。 / “Redmineのガントチャート改善パッチに注目して…” https://t.co/yZZFxG8gj1"

| | コメント (0)

第1回astah関西勉強会の感想 #astahkansai

第1回astah関西勉強会が無事に終わりました。

参加者は少なめでしたが、参加者層は、普段のアジャイル系の人達とは違った顔ぶりの人達が多かった。
astahを使っているか挙手を尋ねてみたら、大半の人は使用経験があるみたい。

一部の人達から感想を聞いてみると、マニアック過ぎた、という感想から、スクリプトやOffice連携のようなマニアックな使い方は面白いですね、という感想まで様々。
以下、ラフなメモ書き。

astah関西 第1回勉強会 - connpass

【告知】astah関西 第1回勉強会を7/14金に開催します #astahkansai: プログラマの思索

akipiiさんのツイート: "#Astahkansai 第1回目勉強会に参加者23人で狭い部屋が超満員です笑。関西でこんなにastahに興味を持つ人がいたんですね"

Masatoshi 0w0さんのツイート: "コードからモデル、モデルからコードはもちろん、モデルからXML出力やモデルデータ出力からのoffice連携。スクリプトやAPIすごいな。 #astahkansai"

Masatoshi 0w0さんのツイート: "限定的な使い方しかできてなかったことを再認識できました。もっとastah活用しよう。 #astahkansai"

Yoichi Nakayamaさんのツイート: "スクリプトプラグインで色々できそう。今度遊んでみよう #astahkansai"

Yoichi Nakayamaさんのツイート: "細合さんの濃い話面白かった。 #astahkansai"

勉強会の内容は、私から、ユーザの立場からのastahを使った感想やastahを使ったモデル(プロセス、システム設計、ビジネスモデル)の事例紹介。
細合さんから、astahの製品シリーズの紹介、astahプラグインの作り方、スクリプトプラグインを入れてEcmaScriptやGroovyやJRubyでスクリプトを書いてastahにメニューを追加したり、astahのモデルを操作する例、また、Office連携プラグインを入れてastahモデルとWordのクラス図を同期させる例などの紹介。

今回の勉強会では、チェンジビジョン社長の熊谷さんも参加されていて、astah製品の利用事例やastahの使い方のコメントを時々発言されて、とても興味深かった。

たとえば、astahGSNを使って、組込みシステムの開発プロセスだけでなく、業務システムの業務プロセスを設計してモデル化する時、リスク内容をモデルの中に埋め込みたい場合がある。
その場合、モデルに、リスク用のタグやステレオタイプを埋め込んでおき、スクリプトプラグインやastahプラグインを使って、モデルからリスク一覧を抽出して、リスク対策へつなげることもできる、という話もあった。

つまり、単にモデルをツールで描くだけでなく、astahのAPIによってモデルから必要な情報を抽出して別の用途に役立てる利用事例もある。
この手法のメリットは、モデルを再利用できること、さらに、モデルを色んな観点のビューで提供できることだ。
すなわち、個別のユースケースに応じて、モデルを再利用できるわけだ。

この観点は、熊谷さんの言葉「astahでモデルをしゃぶり尽くす」につながると思う。

僕としては、この勉強会を上流工程からのモデリング技法の探求、という観点だけでなく、プログラマの観点で、作ったモデルから、ビューを提供したり、ソフトウェアメトリクスを抽出したり、プログラムでモデルを再利用する議論もしたい、と思っていた。
単なるお絵かきの話だけで終わらせたくなかった。
だから、こういう濃い話ができて面白いな、と思っている。

astahのメリットは、直感的な操作がやりやすく、モデルを描きやすい、というのが最大のメリットだが、もっとプログラマの観点を入れてみたいのだ。

「プログラマの立場からのモデル再利用、モデリング技法の探求の勉強会」みたいな場にできたらいいな、と思っている。

| | コメント (0)

2017/07/13

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

最近投稿されたRedmineの添付ファイルを全文検索するパッチが興味深いのでメモ。
ラフなメモ書き。

【参考】
Feature #306: Full Text Search of files? - Redmine

MAEDA, Goさんのツイート: "Redmineの添付ファイルの内容を全文検索できるようにするパッチが今朝投稿された。全文検索エンジンは使わずSQLで実現。 Feature #306: Full Text Search of files? https://t.co/eZHH3QRq5W"

akipiiさんのツイート: "このパッチが実現されれば添付ファイルもチケットと同じく全文検索できる。RT @g_maeda: Redmineの添付ファイルの内容を全文検索。全文検索エンジン無しでSQLで実現。 Full Text Search of files? https://t.co/gajeIjh0t6"

akipiiさんのツイート: "しかしDB容量肥大化や検索性能劣化の課題が気になる。@g_maeda: Redmineの添付ファイルの内容を全文検索できるようにするパッチ。全文検索エンジンは使わずSQLで実現。Full Text Search of files? https://t.co/gajeIjh0t6"

【1】(Google翻訳による引用開始)
私はPlanioのためにこれを最近調べており、この機能のコードを提供したいと考えています。
私たちのパッチは、添付ファイルが作成された後、できるだけ添付ファイルのプレーンテキスト表現で満たされている添付ファイルテーブルに全文列を追加します。
XMLベースのオフィス文書(LibreOffice / OpenOffice / MS Office)(RubyZIP / Nokogiri経由)古いバイナリMSオフィス形式(外部catdoc、catppt、xls2csvコマンドを使用)PDF(pdf2textを使用) RTF(外部unrtfコマンドを使用)プレーンテキスト、CSV他のフォーマットを追加することができます。
つまり、imagemagickを使用してイメージメタデータを抽出することができます。
外部コマンドは適切なデフォルトを持ち、configuration.ymlで設定することができます。
すべての機能が同じ場所でオフになっている可能性があります。
添付ファイルの検索が有効なときに検索された列の一覧に全文が追加されます。
また、デフォルトで添付ファイルの検索を有効にすることを選択し、添付ファイルの内容が検索されるという事実を反映するようにオプションの表現を少し変更しました。
Redmineのほとんどのインストールではないにしても、より複雑な外部インデックス作成ソリューションと比較して、これは「十分に良い」ソリューションだと思います。
ほとんどの添付ファイルのアップロードがJavascriptを介して非同期的に行われることを考慮すると、テキスト抽出のための処理時間の増加は、ユーザーにほとんど気付かれないはずです。
さらに、その作業をActiveJobワーカーに任せることで、管理者はテキスト抽出をインラインで実行するか、DelayedJobやその他の遅延処理バックエンドをセットアップするかどうかを判断できます。
あなたの考えを教えてください!
(引用終了)

(Google翻訳による引用開始)
この機能はPlanioの優先順位リストで高い評価を受けていましたので、Redmineユーザーにも人気があると思います。
次のメジャーリリースでこの機能を提案したいと思います。
ところで、テキスト抽出に必要なバイナリの多くはWindowsでも利用できます。
したがって、この機能は主にクロスプラットフォームでなければなりません:pdftotext:http://www.foolabs.com/xpdf/download.html unrtf:http://gnuwin32.sourceforge.net/packages/unrtf.htm catdoc / catppt / xls2csv (docx、ppt、xls)、新しいXMLベースのフォーマット(docx、pptx、xlsx)はrubyzipとnokogiriを使ってサポートされています。
外部のバイナリが必要です。
(引用終了)

【2】Redmineの添付ファイルを全文検索するパッチは、Planioから提供されている。
このパッチがRedmine本体に取り込まれると、テキストだけでなく、Officeファイル(docx、ppt、xls)やPDFファイル、それらを固めたZipファイルも、テキストベースに一旦変換された後、SQLでLike検索されて、検索結果を表示するようだ。
また、Unixだけでなく、Windows上でも利用できるのも良い。

このパッチのメリットは、Redmineに蓄積されたチケットやWikiだけでなく、添付ファイルも検索対象に含まれるようになるので、Redmineがナレッジを蓄積する情報システムに完全に一体化できることだ。

つまり、共有ファイルサーバーに設計書を配置するのではなく、Redmineの文書やファイル(Redmineのタブ)やチケットの添付ファイルにアップしておけば、Redmineに過去の全ての情報が蓄積されているので、必要な時にいくらでも検索できるようになる。

Redmineがナレッジシステムになるために、とても可能性のあるパッチだと思う。
Redmineに全ての情報を集約するキッカケにもなるし、その動機づけを強化してくれるだろう。

また、Planioで既に利用されているので、ある程度枯れた機能であると推測できる点もメリットになる。
初歩的なバグは既に解決済みだろうし、ユーザが使えるレベル程度までの性能要件もクリアしているだろう、と推測できるからだ。
つまり、このパッチは機能要件も性能要件も信頼できるだろうと推測できる。

【3】Redmineをナレッジシステムとして使えないか、というアイデアに関しては、過去に色々考えていた。
その場合、蓄積された情報をいつでも即座に検索できるという要件が必要になってくる。

redmineでナレッジを蓄積していく方法: プログラマの思索

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

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

Redmineをナレッジシステムとして扱うようにするには、幾つかの課題があると思う。

一つ目は、チケットやWikiだけでなく、添付ファイルや設計書などのOfficeファイルも検索対象に含めること。
二つ目は、全文検索のレスポンスが速いこと。
三つ目は、検索の結果がGoogleのPageRankのように、有用な内容が検索結果の上位に表示されるようにソートされること。

【3-1】一つ目の要件に対し、過去のRedmineユーザはいろんな提案を出している。

たとえば、DMSFプラグインはその一つの解決手段だ。
DMSFプラグインは、Redmineの文書機能を拡張して、文書機能にOfficeファイルを添付すれば、申請・承認ワークフローを通したり、検索対象に含めるようにできる。
JAXAの資料では、JAXAで利用中のRedmineにも導入されている。

DMSF - Plugins - Redmine

“CODA” チケット管理システム | JSS2@JAXA

Redmineの文書ファイルを全文検索するプラグインのリンク: プログラマの思索

他には、Subversionに設計書などのOfficeファイルを履歴管理して、ApacheSolrやElasticSearchのような全文検索ツールを使って検索インデックスを生成する方法などもある。
一般に、ファイルサーバーの全文検索を実現する機能とみなせば、いくらでも実現手段があるので、ノウハウも多い。

SVNでOfficeファイルを管理するメリットは、Officeファイルの更新履歴が明示的に残ること、SVNのような構成管理ツールのおかげで版管理が容易になる点があるだろう。
また、チケットNoとSVNにあるOfficeファイルの修正履歴を紐付ければ、成果物のトレーサビリティもRedmineの標準機能で実現できるメリットもある。

【3-2】二つ目の要件は、検索の性能要件に相当する。
Redmineの右上にある検索ボックスで、全てのPJを全文検索すると遅い場合がある、という症状は昔から知られていた。
現在は、特定のPJに絞り込み検索するようにデフォルト設定して、その症状を和らげる方策でカバーしている。

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

しかし、本来は、ユーザが好きなスコープで、好きな検索条件で検索できるようにしたい。
また、ユーザがイライラしない程度で検索結果が応答するように、性能要件をチューニングしたい。

この点に関しては、@akahane92さんのRedmineの性能チューニングが全て。
RubyやMySQLやApacheなどのミドルウェア、SSD導入や仮想環境でのCPUコア数の追加などのインフラをチューニングすることで、Redmineを高速化することは十分に可能。

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

第14回RxTStudy勉強会「Redmineの未来を考える - 機能・運用・コミュニティ」の感想 #RxTStudy: プログラマの思索

【3-3】三つ目の要件は、検索結果からノイズが排除されて、有用な結果が表示されるようにしたい要件だ。
普通にLike検索すると、単純に検索条件の単語と一致した内容が大量に表示されてしまい、本来の欲しい情報が埋もれてしまう場合が多いだろう。
たとえば、URLやファイルパスなどが引っ掛かってもあまり意味がない。
チケットの障害内容、過去の仕様変更の内容が検索結果の上位に表示されてほしいのだ。

【3-4】二つ目と三つ目の要件に対しては、クリアコードさんのRedmine全文検索プラグインがその解決手段になるだろう。

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

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

redmine.tokyo第12回勉強会:GroongaでRedmineを高速全文検索 #redmineT - ククログ(2017-05-15)

全文検索プラグインのメリットはいくつかある。
一つは、検索機能が非常に高速である点。
Redmineの全文検索が遅い、という弱点は、このプラグインで完全に解決できるだろう。

もう一つは、GoogleのPageRankみたいに、有用な内容を検索結果の上位に表示したり、更新時刻順にソート順を制御できる機能がある点。
「重要なものを見つけやすくする」という要望を強力に実現してくれる点は非常にありがたい。

【4】上記のような課題を考えながら、Planioが提案したパッチを評価してみると、幾つかの課題もあると思う。

一つは、数百万のチケットのような大規模環境で、性能要件はクリアできるか?
もう一つは、検索結果が有用な内容になるようにソートしてくれるか?

この課題は、上記に挙げた課題と同じであり、おそらく、クリアコードさんの全文検索プラグインとを組合せて利用することで、完全に解決できるのではないか、と思う。
つまり、Redmineの添付ファイルや文書・ファイル機能にアップロードされたOfficeファイルは、Planioのパッチとクリアコードさんの全文検索プラグインによって、好きな時に、好きな単語で、即座に有用な検索結果を表示してくれるようになるはず。

すなわち、Redmine本体の機能改善と全文検索プラグイン追加によって、Redmineをナレッジシステムとして実現することは技術的に可能だと思う。

【5】では、なぜ、それほどまでに、Redmineをナレッジシステムにしたいのか?
Redmineにナレッジを蓄積していく情報システムになった場合、Redmineの利用範囲が格段に広がるだろうと思うからだ。

過去の障害や仕様変更の経緯、ソース修正の理由を追跡したい、検索したい、という要件は当然ある。
特に、長年のシステム保守では、障害修正や機能改善の作業内容を一つのRedmineに集約していくことにはメリットはある。

でも、それだけではなく、ISO9001やITIL、ISMSなどのシステム監査の作業軽減に、ナレッジシステムとなったRedmineを使いたいという要望も多いと思う。

たとえば、システム監査で必要な書類の提出を求められた時、Redmineの高速かつ有用な内容を表示する全文検索機能を用いて、即座に必要なチケットとOfficeファイルを検索して、回答内容をリストアップする。
あるいは、組込製品の開発プロセスで必要な成果物が全て網羅できているか、という観点で調査したい時、あらかじめ必要な成果物の資料名やその内容をリストアップしておき、その内容を検索条件として、Redmineの高速かつ有用な内容を表示する全文検索機能を用いて、全ての成果物を洗い出す。

つまり、IT業界のソフトウェア開発におけるナレッジシステムだけでなく、製造業の製品開発におけるナレッジシステムにもRedmineを適用できるはずだ。

特に、日本では最近、製造業でRedmineの利用が広がりつつある。
だからこそ、Redmineを単純な帳票ワークフローシステム、サポートデスクとして利用するだけでなく、ナレッジシステムという本来欲しかった機能として実現できてもいいはずだ。
つまり、Redmineが持つ柔軟なワークフロー管理や成果物のトレーサビリティ、チケットやWikiに記録などの機能を使いながら、作業履歴を蓄積していけば、Redmineに自然にナレッジが蓄積されていく、という仕組みになればいい。

日本の製造業の現場を見ると、さほどIT化されているわけではなく、大量の帳票という紙媒体と、大量のOfficeファイルに埋もれている場合が多いように思う。
そして、ISOやISMSなどの監査作業に、大量の間接作業要員と管理工数が費やされて、IT化によって逆に無駄な作業が増えているのではないか。

そんな現場にRedmineを導入し、上手く運用することで、製造業が本来やるべき製品設計や製品開発に注力するように支援できるはずだ、と思う。

Redmineには色んな可能性が秘められていると思うので、その辺りのアイデアも考えてみたい。

| | コメント (1)

2017/07/10

Redmineを主題にした小説「Redmineで始める異世界人心掌握術」が流行しているらしい

Redmineを主題にした小説「Redmineで始める異世界人心掌握術」が巷で流行しているようなので、リンクしておく。
以下は、自分が参照するためのリンク。
特に主張はなし。

【参考】
Redmineで始める異世界人心掌握術(足羽川永都(えいと)) - カクヨム

(引用開始)
チケットを制する者が異世界を制す!? 貴方もプロジェクトマネジメント!
(引用終了)

(引用開始)
藤倉紅子、26歳。
IT業界勤務。
なんでもエクセルで済ませる奴が大嫌い。
ある日突然紅子が転移した世界は、チケットによって魔法が発動し、チケットによって魔物が出現する異世界。
紅子はこの仕組みを構築した天才PM兼SE兼PGであるレイラの意思を受け継ぎ、彼女の娘レヴィとタッグを組んで、プロジェクト管理ソフト「Redmine」を用いて魔族をマネジメントすることに。
No Ticket, No Work! な異世界ファンタジー、ここにロールアウト!
(引用終了)

【1】SEならば、小説の中にある専門用語とその意図が何となく分かるので、小説はサラリと読めると思う。

一式鍵@カクヨム/小説家になろうさんのツイート: "これはもっと評価されて欲しい。 SE経験者はニヤニヤできるし、 そうじゃない人にはSEの脳内を垣間見るチャンスでもあるw 難しくはないので覗いてみたら良いのです。 Redmineで始める異世界人心掌握術 - カクヨム https://t.co/DBPdDtCbdB"

金屋 かつひささんのツイート: "#カクヨム で足羽川永都(えいと) @8amjp さんの『Redmineで始める異世界人心掌握術』を読む https://t.co/SP80sk5iUE 評判に違わず面白い。Redmine ちょっと勉強してみようかな"

やっさんさんのツイート: "良く出来てる。 レヴィのupgradeって、CPUやDiskなどのスケールアップとかDBチューニングとか、Redmineのpluginで機能追加とかかねぇ。 Redmineで始める異世界人心掌握術 - カクヨム https://t.co/eJcSfqiWBE"

akipiiさんのツイート: "いつも内容が気になる笑。RT @8amjp: 技術系異世界ファンタジー「Redmineで始める異世界人心掌握術」を連載中です。プロジェクト管理ソフト「Redmine」を使って魔族をマネジメントする話。毎週月・火・水曜に更新予定 https://t.co/OKHPRQyKZk"

足羽川永都(えいと)@Web作家見習いさんのツイート: "@akipii 恐縮です…ありがとうございます。akipiiさんのブログは頻繁に読ませていただいており、業務にたいへん参考にさせていただいてます。Redmineが好きになり過ぎてこんな変わったもの書いてしまいました…"

akipiiさんのツイート: "@8amjp Redmine小説はまだ読んでないのですが、すごく気になってます笑。「とある弁当屋の統計技師(データサイエンティスト) ―データ分析のはじめかた―」みたいな表紙や挿絵があると気軽に読めそうな気がします。 https://t.co/noJIlnH4OP"

akipiiさんのツイート: "@8amjp その本は、R言語を操る若手のデータサイエンティストが、ある弁当屋にコンサルで入って、その弁当屋の娘である女子高生と、売上向上の対策を統計学を駆使して練り、成功させるストーリーみたいです。Redmine小説もそんな萌え系の女性のストーリーになるのでしょうか?"

足羽川永都(えいと)@Web作家見習いさんのツイート: "@akipii チケットを発行しないと魔法が発動しないとか、魔物をアサインできないというルールの世界があったら面白いかな?と思いまして… 萌え系技術書というよりは単なる娯楽小説ですが、Redmineとファンタジー世界の両方好きな人はより楽しめるかも、という作品を目指してます。"

【2】挿絵が欲しくなった、と呟いたら、@akiko_pusu さんの挿絵が出てきて、すごくイメージが湧いた笑。
画像は、@akiko_pusu さん作成の画像をリンクしている。

あきこさんのツイート: "こちらを読んでます。 (古くさい絵しか描けなくてすみません…!ルートになった紅子さん。) https://t.co/yjZctNRTKf https://t.co/x9argoux4x"

あきこさんのツイート: "明日は会社か...。絵も相当練習しないと描けなくなってるのが切ないのですが、ちょっとずつ。(今回はレヴィちゃん) https://t.co/JQwtCmrb0Q https://t.co/MQX9qXVnku"

足羽川永都(えいと)@Web作家見習いさんのツイート: "あきこさんに『Redmineで始める異世界人心掌握術』のレヴィを描いていただきました!めっちゃ可愛い! 紅子に続いてレヴィまで……ホントに幸せ者です。ありがとうございます! https://t.co/00piN5HJ1w"

【3】登場人物には色んな意味があるらしい。

tkusukawaさんのツイート: "redmineは「紅の宝庫」か。なるほど!リアルタイムな状況と過去の経緯や関連案件が継続的に蓄積される、まさに宝庫 https://t.co/C0M16jorFd #fb"

akipiiさんのツイート: "紅は気づいた笑。RT @8amjp: ここで登場人物の名前の由来でも。 瀬尾絵子、篠宮樹里(恋に落ちる?) →イニシャルをes、jsにしたかった。あとはフィーリングで。 藤倉紅子(Redmineで?) →「紅」を入れたかった。あとは(略) レヴィ(同) →Rubyをもじった。"

akipiiさんのツイート: "緑の意味は何?RT @8amjp: 「…OK、緑は、敵だ」 プロジェクト管理ソフトRedmineの力でPM藤倉紅子の活躍を描く物語。 現在、第3章「草原を渡る紅風」を連載中です。 Redmineで始める異世界人心掌握術 - カクヨム https://t.co/OKHPRQyKZk"

足羽川永都(えいと)@Web作家見習いさんのツイート: "@akipii 緑は、敵国のイメージカラーであり、某表計算ソフトのイメージカラーでもあります。 元々、敵国の象徴として「表計算ソフト『のみ』でプロジェクト管理でも何でもしたがる人」というのがありまして、その習慣を打ち破るために戦う、というのもテーマの一つになっております……"

あきこさんのツイート: "@akipii @8amjp わたしは割とすぐに分かりました^_^ グリーンボードで。"

あきこさんのツイート: "こちらの緑のレディはエクセルの擬人化かな?キャラが立ってる! https://t.co/AE73MlCrPp"

【4】色々工夫しているらしい。

足羽川永都(えいと)@Web作家見習いさんのツイート: "「Redmineで始める異世界人心掌握術」では、1話あたり1500文字を目安に書いてるんですが、これが非常に書きやすい。原則、1話=1シーンとして(場面転換しない)、心理描写やらキャラ付けの為のエピソードやらを適量入れると、だいたい1500〜1600文字になる。ちょうどいい。"

足羽川永都(えいと)@Web作家見習いさんのツイート: "で、その1500文字の中にも起承転結を持たせるよう気をつけてますが、同様に重要視してるのが「読者がツッコミやすい箇所を作る」こと。ツイッターなどで話題にしてもらいやすくなるように。この読後のツイートの数こそが、Web小説の命運を左右すると考えている。"

あきこさんのツイート: "絵の引用ありがとうございます!画力鍛えねば! 赤い宝石vs巨人ではなく、vs緑の格子です。毎回の字数がちょうど良く読みやすいです。情シスやインフラ系の方も楽しめると思います。 https://t.co/15zXBxgU06"

【5】2017/7/10時点で第3章26話まで話が進んでいる。

足羽川永都(えいと)@Web作家見習いさんのツイート: "「…OK、緑は、敵だ」 プロジェクト管理ソフトRedmineの力で異世界をマネジメントするPM藤倉紅子の活躍を描く物語。 現在、第3章「草原を渡る紅風」を連載中です。 Redmineで始める異世界人心掌握術 - カクヨム https://t.co/0qhzXKj8Zb"

足羽川永都(えいと)@Web作家見習いさんのツイート: "@akipii 小説をフォローして継続的に読んでくださってる方は34名いらっしゃいます。また全話合計で約1800ページビューと、たくさんの方に読んでいただいてます。ありがたいです。"

akipiiさんのツイート: "Redmine小説のフォロワーはそんなに多いのですね! @akiko_pusu さんの挿絵ですごくイメージが湧きました笑 https://t.co/W7YmTVOCWz"

【6】個人的には、「とある弁当屋の統計技師(データサイエンティスト) ―データ分析のはじめかた―」みたいに、表紙は萌え系の女性かもしれないけれど、中身はRedmineをベースとして、アジャイル開発のプロジェクトマネジメントやソフトウェア工学の知見などが書かれた骨太の小説になるといいな、と思っている。

| | コメント (0)

2017/07/04

RedmineのVerUp手順はSVNチェックアウトが最善

RedmineのVerUp手順はSVNチェックアウトが最善である記事があったのでメモ。

【参考】
Redmine 3.4 にリポジトリ(SVN)からアップデートしてみた - netazone.net

(一部引用開始)
【前提条件】
稼働中のRedmine をSVNチェックアウトで構築していること

【方針】
SVN経由で更新すると、当然そのディレクトリが更新されるので、事前にコピーをとっておく
Redmine ディレクトリをコピーすることでテーマやDBの設定ファイルを引き継ぎ
プラグインは一旦全部外す(サブディレクトリに退避)

【感想】
リポジトリ(SVN)からソースをチェックアウトでのバージョンアップをやってみて

すごく簡単。設定ファイルのコピー漏れなどつまらない失敗も起きない

自分でパッチ当てたところもキャッチできる
(手動でパッチを当てたファイルを失念しており、conflict が発生)
(一部引用終了)

tar.gzではなく、SVNチェックアウトでVerUpする利点は、いくつかある。

一つ目は、以前の設定ファイルの情報などが引き継がれること。
つまり、設定ファイルの移行作業は必要ない。

二つ目は、手動でパッチを当てたファイルは、svn updateでconflictが起きるので、事前に危険なファイルやマージを検知できる。
conflictが起きたソース一覧を事前に洗い出しておけば、こういうマージ作業でRedmineが正常動作しなくなるリスクを減らせるはず。

三つ目は、VerUp作業を自動化できる可能性があること。
稼働中のRedmineソースとDBを毎日バックアップしていれば、その環境を使って、svn updateとDBマイグレーションなどのVerUpコマンドをシェルにしてしまえば、VerUp作業そのものを自動化できる。
つまり、何度でもVerUp後の検証環境を作れるし、何度でも検証作業を試せる。

マイナーバージョンアップ(たとえば、3.3.x→3.3.4)であれば、DBマイグレーションもないので、svn updateによるファイル更新だけでVerUp作業が完了できる。
つまり、マイナーバージョンアップなら、VerUp作業を自動化した時に失敗するリスクも小さい。

さらに、DockerやAnsibleなどでサーバー環境そのもので自動構築したりバックアップしているならば、VerUp手順だけでなくサーバー構築手順も合わせて自動化してしまえばいい。

そうすれば、ブルーグリーン・デプロイのように、古いバージョンと新しいバージョンの環境を切り替えるようにしたり、イミュータブル・デプロイのように、古いバージョンの環境は捨てて、新しいバージョンの環境を使うこともできるだろう。

継続的デプロイ&ダウンタイムなしのデプロイのために - Qiita

DevOps時代の開発者のための構成管理入門(終):継続的デリバリ/デプロイを実現する手法・ツールまとめ (1/2) - @IT

ブルーグリーン・デプロイやイミュータブル・デプロイの導入によって、OSやRubyのようなミドルウェアのバージョン依存で本番システムが動かなくなって、元に戻せなくなるリスクが格段に減らせる。

いわゆる継続的デリバリーの概念をRedmineのVerUp作業にも適用できるわけだ。

| | コメント (0)

2017/07/03

Redmine3.4.0 Released !

待望のRedmineの最新バージョン3.4がリリースされた。
ラフなメモ書き。

【参考】
Redmine 3.4.0, 3.3.4 and 3.2.7 released - Redmine

Redmine 3.4 新機能紹介 | Redmine.JP Blog

Redmine 3.4.0のCHANGELOG 日本語訳 | Redmine.JP Blog

Redmine3.4.0 新機能のご紹介(1) - Qiita

Redmine3.4.0 新機能のご紹介(2) - Qiita

Redmine3.4.0 新機能のご紹介(2) - Qiita

Redmine 3.2.0 released!: プログラマの思索

Redmine 3.0.0 released!: プログラマの思索

akipiiさんのツイート: "世界中の開発者が、最新版のRedmine リリースを心待ちにしてる。RT @redmine_news: Development: RE: Why don't you just release 3.4.0? https://t.co/6gMEaql0f1"

Why don't you just release 3.4.0? - Redmine

Kuniharu AKAHANEさんのツイート: "痒いところに手が届く細やかな改善が多く、非常にありがたい。 #Redmine の利用者が増えて、幅も広がっている証左か /Redmine3.4.0のCHANGELOG 日本語訳 ファーエンドテクノロジー株式会社 前田剛さん https://t.co/6YeCDaf9tM"

【1】1年ぶりのメジャーバージョンアップ。
リリース済みチケットは200件もあり、数多くの機能が追加・改善されている。
詳細な内容は、下記参照。

Redmine 3.4.0のCHANGELOG 日本語訳 | Redmine.JP Blog

Redmine 3.4 新機能紹介 | Redmine.JP Blog

【2】目玉の機能は、チケット一覧や工数管理、マイページの機能改善だろう。

チケット一覧画面に新たなフィルタ「ファイル」「更新者」「最終更新者」「対象バージョンの期日」「対象バージョンのステータス」、バージョンに対するカスタムフィールドなどが追加される。

たとえば、直近で更新されたチケットの内容を検索したり、添付ファイル名で検索できる。
また、ファイル形式のカスタムフィールドが追加されたので、バイナリファイルもカスタムフィールドに設定できるし、CFゆえに検索も可能。

また、「長いテキスト」形式カスタムフィールドの「ワイド表示」オプションも追加されたので、障害や課題、ヘルプデスク用チケット、稟議申請チケットなどにも適用できる。
この機能のおかげで、業務のフィットギャップ分析さえしっかりできれば、ほとんどの帳票はRedmineのチケットで全て表現できるだろう。

「チケットのフィルタ「対象バージョン」の選択肢をステータスごとにグループ化」によって、プルダウンで完了したバージョン、生存中のバージョンを選択しやすくなった。
チケットが大量に増えるほど、チケット一覧画面で検索する操作が増えるので、細かなUI改善はありがたい。

また、作業時間の一覧に、検索フィルタが保存できるようになり、チケット一覧画面に似た操作ができるようになった。
実績工数を入力する運用ができていれば、作業時間の一覧画面から、予定・実績工数のデータを自由に検索できるので便利だ。

さらに、マイページ画面にカスタムクエリを選択できるようになった。
マイページ画面は、自分の活動ログが表示されるので、必要なチケットだけ表示されるのは良い。
@g_maedaさんが言う通り、マイページ画面やプロファイル画面はもっと機能改善すれば、より使いやすくなるだろうと思う。

MAEDA, Goさんのツイート: "Redmineのプロフィール画面(users/:user_id)と個人設定画面(my/account)は統合されるべき。Redmineを10年近く使っているが、いまだに時々間違える。"

【3】今後のRedmineの課題は、Rails5対応だろう。
Rails5に対応されると、Rubyの2.2.1以前はサポートされなくなるので、影響がすごく大きい。
Ruby2.4には対応できたが、Rails5に対応されると、Redmineの利用ユーザに多大な影響が生じるだろう。

Feature #23630: Rails 5 support - Redmine

Feature #25538: Drop support Ruby 2.2.1 and ealier - Redmine

一方、コミットログを見ると、JPLはテストコードから、ちょっとずつ対応しているみたい。
Rails5はリリースされて既に1年ほど経っているので、ある程度運用もこなれているはずなので、Redmineもそろそろ対応しても良いタイミングだと思う。

過去のRedmineを振り返ると、RubyやRailsのようなVerUpの激しい開発基盤の上で、それらのVerUpに良く追随してきたと思う。
Railsを基盤とした有償・無償の製品の中で、Redmineほど、移植性や保守性という品質を保持できたツールは、そう多くはないのではなかろうか。
昨今のStrutsのセキュリティホールのニュースを聞くたびに、そんなことを思う。

RedmineがVer2.0でRails3へ移行予定: プログラマの思索

もう一つのRedmineの課題は、UIの改善だろう。
レスポンシブデザイン対応もあったけれど、昨今のWebやスマホに見合った画面UIにも改善したい。
JPLも既にその認識はあるようなので、今後のVerUpに期待している。

【4】また、Redmineコミュニティに関わる一人として、Redmineのコミッタ・ユーザ・ベンダーの三者による相互交流を今後どのように発展させていくべきか、という点も興味はある。

Redmineコミュニティに関わる動きのメモ: プログラマの思索

幸いなことに、日本のRedmineコミュニティは非常に活発であり、日本人のプラグイン開発者も多く、Redmineサーバーの管理者も多い。
つまり、日本ではRedmineに知見がある人達が多いので、コミュニティ側から何かしらの支援ができればいいな、と思っている。

| | コメント (0)

«「「愚直」論 私はこうして社長になった」の感想