Singleton

とあるパッケージの保守を10年ほどしていて、問い合わせを全てRedmine のチケットで管理していた。 カスタムフィールドにどの機能の話なのかカテゴリを用意して、チケット作成時に保守担当者に選択してもらっていた。ただ、後から分析しようと思ってカテゴリを見てみると、結構担当者によってまちまちというか、間違っていることも多かった。 これまでは分析のときにそれぞれ直していたが、どうにかチケット作成時に正しいカテゴリを選択してもらえないかと思い、fastText で自動化することにした。 fastText の導入環境 fastText とは、Facebook が作成した自然言語処理のライブラリだ。高速かつ簡単に利用できる。 今回は、これまでRedmine に蓄積した約2000の問い合わせを教師データに、問い合わせの内容から対象カテゴリを分類するようにした。 環境、ライブラリは以下の通り。 Windows10 PyCharm fastText janome 日本語をfastTextで処理する場合は、事前に分かち書きという処理をする必要がある。分かち書きにはMeCab というライブラリを使う情報が多いが、この自動化をした当時はpip install で ERROR: Command errored out with exit status 1: のエラーが出て解消するのが面倒だったので、簡単に入れられるjanome を採用した。 (※現在はmecab もpip install で簡単に入れられる様子) 事前準備 まずはfastText とjanome を導入する。 PyCharm でプロジェクトを作成し、View - Tool Windows - Terminal で以下を実行。 git clone https://github.com/facebookresearch/fastText.git cd fastText pip install . pip install janome モデルの作成 まずはRedmine からチケットをCSV エクスポートする。そしてカテゴリと問い合わせの題名+本文だけに加工する。こんなイメージだ...

メールからタスクが発生することはまだ多い。その時メールの本文をコピーして、Redmineを開いて、チケット作成画面を開いて、説明欄に貼り付けてチケットを作成すると思うが、煩雑ではないだろうか。 Outlook からRedmine のチケットを作成するアドイン そこでOutlook アドインを作成した。以下からダウンロードできる。 https://f.easyuploader.app/20210804205153_6456326c.zip このアドインはOutlook(デスクトップ版)に、「Redmineに送る」右クリックメニューを追加する。 「Redmineに送る」右クリックメニューをクリックすると、メールの件名と本文を転記した状態でチケット作成フォームが開く。 チケット作成フォームを確定することで、Redmine にチケットを作成する。 インストール方法 SendToRedmine.zip をダウンロードして解凍する。 setup.exe を実行する。 SmartScreen のメッセージが表示された場合は、詳細情報→実行をクリックする。 インストールをクリックする。 インストール時にOutlook が起動していた場合は、アドインを読み込むため一度Outlook を再起動すると有効になる。 初期設定 Outlook 上部の「アドイン」 → 「設定」をクリックする。 RedmineUrl とApiKey を入力して、Project選択ボタンを押して確定すれば使用できるようになる。 各項目は以下の通り。 ・設定名：任意の文字列(※Project選択ボタンでプロジェクト選択すると上書きされる) ・RedmineUrl：Redmine のURL (http://example.com/redmine...

これまでRedmine の導入推進をしてきて、導入失敗しているプロジェクトにいくつかの共通項があったので、アンチパターンとしてまとめる。 Redmine 運用のアンチパターン 荒れ地 何も決めずにRedmine を使い始めて失敗した残骸。乱立したプロジェクト、カスタムフィールド、更新されないチケットたち。 最低限、チケットのトラッカーとステータスを決めて、定期の運用にRedmine をどう組み込むか決めてから始めよう。 溶岩流 大量の入力項目と必須項目。チケットを開くとカスタムフィールドで画面が埋まっている。 担当者にチケットの更新どころか作ることすらためらわせる。Excel台帳の列をそのままカスタムフィールドにしたときにありがち。 項目を1つにまとめられないか、そもそも必要か？を検討してからカスタムフィールドにしよう。管理項目はCSV エクスポート後に別で付与することも検討する。 神トラッカー タスクやToDoなどなんでもありなトラッカー名。 トラッカーで分類ができないので、溶岩流になりやすい。Redmine を使い始めるときにまず作業の分類はどんなものがあるかを考えてから、それをトラッカー名にすることを検討する。 ワープ 途中経過を記載しないチケット。ステータスの開始、終了だけが残っている。 ノウハウが全く残らないので、Redmine を使うメリットが感じられなくなる。作業の途中経過がノウハウ、資産になるのでコメントを記載しよう。 アンデット 終わらないチケットたち。 メモや備忘録のような完了基準がないチケットを作ると発生する。チケットが残り続けるので、残タスクの量が分かりづらくなったり、チケット一覧が大量に見えるので精神的負担になっていく。 そういったチケットは作らず、作業チケットの中にコメントで記載するようにする。 肥満児 1チケットに延々と記載が続く。担当者のモチベーションがガリガリ削られていく。 作業がどこまで進んだのか、また後から振り返って見たときに何が問題だったのか、どう解決したのか分かりづらくなる。 最初からある程度の作業で分けて子チケットにする。途中で長くなった場合は子チケットを作成する。 迷路 カスタムフィールド...

プロダクトのタスク管理にRedmine を10年ほど使い、他の部署にもRedmine の導入推進をしている。 その中で見えてきたRedmine 運用に失敗しないためのポイントを記載する。 今回は運用編。設定編はこちら 運用を失敗しないためのポイント(運用編) 定期のミーティングにRedmine を組み込み、チケットをベースに会話する まず、定期のミーティングでRedmine を利用することが最も重要だ。 普段の作業記録はRedmine で、ミーティングは別資料でとなっていると、作業者からは手間が増えただけと捉えられる。結果チケットの更新がされなくなっていく。 デイリーミーティングなどの定期の場でチケットをベースに会話することで、作業者にチケットを更新することの必要性を意識付ける。 なおRedmine 運用を始めたばかりのチケット更新で特にありがちなのが、ステータスの開始、終了だけが記録されていて、途中経過を書いていないケースだ。こうなると以前の台帳管理と何も変わらないと判断されて廃れていく。 Redmine の強みは随時更新できて作業の開始から終了までの記録が残ることだ。ミーティングの場では、作業状況のコメント入力と時間入力をチェックしよう。書いていなければ、話しながらその場で更新してもいい。 また作業の途中経過で調べた情報やハマったポイントは随時チケットに書いてもらおう。長期間プロジェクトを運用していると、後からその経緯を追うタイミングが必ずある。コメントと時間記録が大きなノウハウ、資産になる。 チケットは気軽に更新していいものだと作業者に意識付けをする 台帳管理に慣れている作業者は、チケットに誤った情報、調査途中の情報を書いてはいけないと思いがちだ。そのままRedmine 運用を始めると、これまでの進捗会、報告会のようにサマリした情報しかチケットに残さない。 前述の通り、Redmine の強みは随時更新できて作業の開始から終了までの記録が残ることだ。サマリされた情報にそこまで意味はない。結果を見れば分かるからだ。途中経過こそが重要な情報だ。チーム、メンバが辿った道のりを記録することが大きなノウハウ、資産になる。 私の場合は、最初に「チケット、コメントは報告書ではないので、調査途中の情報で仮に誤っていても問...

プロダクトのタスク管理にRedmine を10年ほど使い、他の部署にもRedmine の導入推進をしている。 その中で見えてきたRedmine 導入時に陥りがちな設定ミスと、中長期で使う場合に避けたほうがよい設定がある。それらを避け、Redmine 運用に失敗しないためのポイントを記載する。 今回は設定編。 運用編はこちら 運用を失敗しないためのポイント(設定編) カスタムフィールドは最低限にする 典型的なアンチパターンとして、管理や分析用のカスタムフィールドが大量に登録され、チケット画面がカスタムフィールドで埋まっている状態がある。 こうなると入力する側としては、チケット作成のたびに多数の項目を埋める必要があり、チケット作成自体がされにくくなる。また更新するときも情報量が多くて気が滅入るので更新の頻度も下がる。こうなるとまずRedmine が定着しない。 まず重要なことはRedmine 使ってもらい定着させることだ。管理や分析に必要なカスタムフィールドは最小限にする。そういった項目はエクスポートしてからExcel などで追加し、管理、分析する方法もある。 あくまでRedmine は開発者、作業者ためのツールでFlyweight であるべきと考える。 モジュールは最低限にする 最初に導入したときは色々な機能を表示したくなる。しかし多く表示すればするほどRedmine に難しい印象を持たれて定着しづらくなるし、せっかくの情報が分散してしまうモジュールもある。なのでモジュールは最低限にしたほうがいい。 特に不要だと思うのは文書とフォーラム。 文書はファイル機能で代替できる。なおファイル機能の利用にも注意が必要だ。ファイルからチケットに飛べないので、どのタスクで発生したファイルなのか分かりづらくなるためだ。固定の設定ファイル等だけを登録するよう指導が必要だ。 フォーラムは議論がチケットに紐付かないので、ノウハウと作業が分散してしまう。あとから経緯を追いづらくなるため、議論の内容はチケットに残したほうがいい。 プラグインは最低限にする 色々と有用なプラグインはあるがRedmine のメジャーバージョンアップで動作しなくなることが割と多い。 Redmine のバージョンアップでは、レスポンスの向上や良い新...