Redmine

2019/11/24

Redmine Advent Calendar 2019のリンク

今年もRedmine Advent Calendar が作られたのでリンクしておく。
@ryouma_nagareさん、ありがとうございます。

【参考】
Redmine Advent Calendar 2019 - Adventar

Redmine Advent Calendar 2018 - Adventar

Redmine Advent Calendar 2017 - Qiita

まだ空きがあるので、書きたい人は是非。


| | コメント (0)

Redmine互換のディストリビューションRedMica

先日、Redmine互換のディストリビューションとしてRedMicaがリリースされたので、メモ。
あくまでも一つの意見。

【参考】
Redmine互換課題管理システム「RedMica」 リリースの狙い - ファーエンドテクノロジー株式会社

Redmine 4.0.5 を RedMica 1.0.0 に移行する - Qiita

Redmine を RedMica に移行する | JI0VWLのFreakな日常

redmine tokyo の衝撃|makoto0119|note

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

【1】RedMicaが「Redmine互換のディストリビューション」という意図は、プレスリリースの通り。

(引用開始)
RedMicaはRedmineと別れて新たな道を歩むものではありません。
「今日使える明日のRedmine」という言葉が示す通り、Redmineの開発成果をより早く利用者に届けるのが目的です。
Redmineから枝分かれして独自に進化する「フォーク」ではなく、むしろRedmineの一つの配布形態、「ディストリビューション」とご理解いただければと思います。
(引用終了)

以前、RedmineからフォークしたChiliProjectがあったが、結局EOSになった。

Redmineから分岐したChiliProject: プログラマの思索

RedmineクローンChiliProjectが終了されたらしい: プログラマの思索

OpenProjectもRedmineからフォークして独自開発されているようだが、その後の発展はよく知らない。

「近代化Redmine」ことOpenProjectでスクラム開発のプロジェクト管理 - Qiita

他にも、PHP版Redmineクローンがあったが、その後の発展はよく知らない。

最近のCandyCane - PHP版Redmineでタスク管理を始めよう

Redmineは開発が非常に活発なので、フォークしたとしても、本家の機能より見劣りすると使われなくなるのだろう。
過去にRedmineからフォークしたソフトウェアがいずれも、事実上活動していない状況を見ると、フォークするリスクは大きいと考える。
よって、RedMicaがRedmineのtrunkに追随する方針にしたのは賢明だと考える。

【2】なぜ、RedMicaを開発したのか、という目的は、プレスリリースの通り。

(引用開始)
しかし、現在のRedmineはリリースが不定期かつ間隔が長めで、スケジュールも明示されていません(コミッターである私にも分かりません)。
せっかく開発しRedmine本体に取り込み済みの新機能をいつお客様の環境にデプロイできるのか全く不明です。
リリース時期の目処がまったくわからないまま開発済みの新機能を長期間お客様にお届けできないことを大変残念に思っていました。

RedMicaはこの問題を解決するための手段です。
Redmineの最新のソースコードに常に追従するファーエンドテクノロジー版Redmine「RedMica」をリリースすることにしました。
当社が主体となってメンテナンスするソフトウェアであればリリースを自由にコントロールできるので、Redmineの最新の開発成果をこれまでより早くお客様に届けることができるようになります。
(引用終了)

Redmineのリポジトリを見れば、使いやすさを中心とした細かな機能改善は、活発に行われている。
しかし、リリース時期は不定であるので、パッチとして取り込まれた改善機能はすぐには利用できない弱点があった。
その弱点を解決する方針の一つとして、RedMicaが生まれた、とのこと。

RedMicaのメリットは、@g_maedaさんがコミッタなので、Redmineを十分に知り尽くしているだろうから、気兼ねなく使えるだろう、という安心感があること。

一方、redmine tokyo の衝撃|makoto0119|noteの通り、たとえRedMicaがディストリビューションであっても、Redmineからフォークするリスクがあるのではないか、という意見もある。

個人的意見としては、Redmineコミュニティで長年、@g_maedaさんがRedmine愛を持って活動されてきた言動を見る限り、Redmine本家を大切にしながら開発されるだろうと思っている。


| | コメント (0)

2019/11/11

View customizeプラグインによるRedmineのカスタマイズ事例集のリンク

ファーエンドテクノロジーさんから、View customizeプラグインによるRedmineのカスタマイズ事例集が紹介されていたので、自分用メモ。

【参考】
GitHubにView customizeプラグインによるRedmineのカスタマイズ事例集を公開しました! - ファーエンドテクノロジー株式会社

GitHub - farend/redmine-view-customize-examples: Redmineのプラグイン「View customize」を利用したRedmineカスタマイズ集

Redmineのプラグイン「view customize plugin」のカスタマイズ例 - Qiita

GitHub - onozaty/redmine-view-customize-scripts: Script list for Redmine View Customize Plugin

全員に案内文を見せる、ちょっとしたデータの整形など、細かなUI改善を手早くやりたい時にView customizeプラグインは重宝する。
おそらく、このプラグインはRedmineユーザなら必須ではなかろうか。


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

第20回Redmine大阪の感想 #RedmineOsaka

今日のRedmine大阪が無事に終わりました。
参加者、スタッフの皆さん、ありがとうございました。
疲れているのでラフなメモ書き。

Redmine-osaka-020 - Redmine.Osaka

2019/8/31 第20回Redmine大阪 - Togetter

第20回 Redmine大阪 - connpass

redmine大阪勉強会 コアなメンバーが集まる madowindahead

redmine Osaka の感想|makoto0119|note

【1】今回の勉強会では、会場が大阪にも関わらず、遠方からたくさんの参加者が来られた。
東京、名古屋、松江、福岡、神戸など。
いつもの@MadoWindaheadさん、@ryouma_nagareさんだけでなく、@akiko_pusuさんまで東京から参加してもらって、非常に盛り上がったと思います。
また、大阪でも20代から40代までと幅広い年齢層で女性も割と参加されていた。
参加者層が多様であることは、勉強会の活気にも繋がり、とても良い雰囲気であるように感じた。

DirectPollの投票結果では、Redmine歴が4年以上が参加者の半数以上。
バージョンも3.x以上が多い。
つまり、Redmineを長年かなり使いこなしている人たちが多い。
よって、講演内容も細かい技術の話だけでなく、導入や運用、開発プロセスの話もあるので、内容が非常に幅広くなっている。
その分、いつ聞いても、新鮮な感じを受けるので飽きない。

たくさんの講演があったので、興味を引いた内容だけメモしておく。

【2】@g_maedaさんのRedmineのVer4.1の紹介を聞くと、「今回のバージョンでは攻めている」。
つまり、Ver4.0ではRailsのバージョンアップを重視していたので大幅な機能追加はできなかったが、Ver4.1では割と数多くの機能改善がなされている、とのこと。

履歴タブ、通知メールやリマインダメール、インポート時に親チケットの仮IDを付与して親子チケットの関係を保持する機能改善、など、Redmineをより使いやすくする機能改善がたくさんあった。
RedmineはUIが使いにくい、という話もよく聞くが、頻繁に機能改善が取り込まれている現状を見ると、最新版に追随した方が恩恵を受けやすい。

実際、@ryouma_nagareさんのLTでは、RedmineをVer4.xへバージョンアップしてPostgresSQLへ変更したことで、AWS上のログを解析すると性能が大きく改善された、とのこと。

akipiiさんはTwitterを使っています: 「#RedmineOsaka Redmine 4にバージョンアップしたら、ログ解析すると、圧倒的に高速になった報告。Postgresなら、サブクエリもインデックスが働くのでMySQLよりも速い。」 / Twitter

また、@netazoneさんのLTでも、Ver4へバージョンアップしても、数多くの日本人作者のRedmineプラグインは互換性を維持でき、より使いやすくなった、とのこと。

よって、Redmineの機能改善してどんどん機能が肥大化したとしても、RubyやRailsのバージョンアップに伴う高速化により、Redmine本体の性能は良くなっている。
RedmineがRubyやRailsの相性がとても良い、という事例でもあるのだろう。

【3】「とあるメーカーのRedmine 活用事例 RedmineとTableau」の講演も面白かった。
この会社では、情シスが部門ごとにRedmineインスタンスを配布しているので、30個以上のRedmineが社内にある。
社内はVM、社外はAWS。

Redmineのポリシーは、各部署にお任せ。
その理由は、各部署で自由に使いたい、という意見が強かったらしい。
実際にRedmineを使っている部署では、リーダーとその部下が頻繁にRedmineを使っているが、管理職や役員はほとんどRedmineに触れておらず、そもそもRedmineを知らないらしい。
そういう話を聞くと、日本ではあるある、だなと思う。

akipiiさんはTwitterを使っています: 「そこがすごいですよねー。RT @kazuhito_m: 「全社同一Redmine」じゃなくて「データは全然分かれてるインスタンスを多く立ててる」のかな? #redmineosaka」 / Twitter

そこで、Tableuが有効活用できる。
RedmineのデータをTableuで集計して、上司に見せるビューを作るわけだ。

Tableu連携では3パターンある。
RedmineのDBに直接連携、REST API経由でデータを取り込む、カスタムクエリで出力したCSVを取り込む。
話を聞くと、RedmineのDBのミラーリポジトリを作り、そこでTableuで集計しているらしい。

デモでは、CSVを取り込んでTableuで集計ビューを見せていた。
話を聞くと、Redmine導入以前は、Excelでガントチャートを計算・表示させるマクロまで作り込んでいたらしいので、このやり方が一番使いやすいらしい。

つまり、従来はExcelによる開発プロセスは既に出来上がっていたので、Redmineで運用するプロセスに乗り換えるだけでよい。
すなわち、Redmineの導入は非常に楽だったのだろう、と想像する。
そこに足りない集計機能の部分は、Tableuでフォローするというやり方は洗練されていると思う。

akipiiさんはTwitterを使っています: 「既にエクセルでガントチャートのマクロも作り込んでいた話がありましたね。運用プロセスはあったので、Redmine 乗り換えはスムーズかも。@saito0119: すごく斬新な話で驚きました。開発用ではなくいわゆる今まで ITメーカーのやってきた「基幹システム」を手作りしているような話でした #redmineOsaka」 / Twitter

【4】@akahane92さんの「Redmine全文検索システムの実際」では、全文検索の性能要件の話だけでなく、機能強化にも興味があった。

akipiiさんはTwitterを使っています: 「Redmine 全文検索プラグインでついに、添付ファイルもリポジトリ内の文書も検索が可能になった。Redmine に全てのデータを集約すれば、いつでも即座に探し出せる意義は大きい。Redmine はナレッジシステムに近づいてきたかな。検索機能はトレーサビリティの代替にもなりうる可能性がある。 https://t.co/0dUz1GAHEq」 / Twitter

つまり、Redmineのチケットがストック型で、たくさんの情報を埋め込む運用プロセスの場合、Redmineの全文検索プラグインは非常に有用な機能になるだろう。
いつでも簡単に有用な情報が検索できるだけでなく、情報のトレーサビリティをより強化してくれるからだ。
添付ファイルやリポジトリ内のソースや設計書も検索できることで、成果物のトレーサビリティを優れた検索機能で支援してくれるわけだ。

akipiiさんはTwitterを使っています: 「#RedmineOsaka GitHub のソースにクリアコードさんと島津製作所の名前が記載されて、オープンソースで公開されてるのは、製造業の人ならすごいなと分かるのではないか。知財管理などをクリアされて、みんなが共有できるのが有難いですね。」 / Twitter

製造業では、知財部が必ずあり、知的財産は特許などで守り、ビジネスにしていく。
あるいは、不正競争防止法の営業秘密として、知的財産を盗まれないようにひた隠しにする。
にも関わらず、開発したプラグインをオープンソース化して公開できたことは、非常にすごいと思う。

僕の考えでは、特許や不正競争防止法の営業秘密のような知財を防御するような手法は、ソフトウェア開発ではあまり馴染まないだろうと思う。
むしろ、OSSコミュニティと密接に関係する方が、今後の保守もやりやすいし、優れたソフトウェア技術者も確保しやすくなるメリットの方が大きい。

【5】懇親会で話をしながら、Redmineコミュニティの参加者層に関するヒントを教えてもらった。
どうやら、Redmineのユーザ経験はあるがシステム管理者の経験がない人達がRedmineでプロジェクト管理したくて、Redmineに興味を持ち始めている、というセグメントがあるらしい。

akipiiさんはTwitterを使っています: 「#RedmineOsaka 懇親会から離脱しました。参加者、スタッフの皆さん、ありがとうこざいました。飲みながら議論して気づいた事は、以前Redmineのユーザーで使用経験あるが今の職場ではエクセルで不自由なので自らRedmineシステム管理者になったが詳しく知らない。そこで勉強会に来てみた層が割といる」 / Twitter

akipiiさんはTwitterを使っています: 「#RedmineOsaka つまり、Redmine ユーザーの経験はあるがシステム管理者の経験がないがプロジェクト管理がしたい人というセグメントがRedmine 勉強会のターゲット層になってる。ちょうど、プログラマ上がりの新米リーダーがRedmine でプロジェクト管理を始めたという自分の経験と既視感あるのが面白い。」 / Twitter

以前、@MadoWindaheadのPMxTMマトリクスの話の通り、上記のセグメントの参加者は、Redmine力をつけることでPJ管理力を身に付けやすい。
支援するだけで、彼らは自身の力だけで、問題解決できるはず。

そんなことを思うと、Redmineコミュニティは非常にニッチなマーケットにも関わらず、非常に良いユーザ層を持っているなあ、と思う。
ユーザが成長している場面をコミュニティが共有できるのは、活気があってすごく楽しいから。

そんな気付きがあった。

【追記】
redmine Osaka の感想|makoto0119|note

(引用開始)
 ユーザディスカッションで聞いた話で、心に残ったのは以下。
「こうやって勉強会に来る人はそう考えないと思いますが...」「現場に理解のない管理職が...」などなど。
そうなんですよね、勉強会に来る段階でフィルターがかかっていて、そこでの「他人の芝生」はかなりバイアスがかかっているということ。
良い意味での「意識の高い人」が「自分の悩みを他の人はどう考えているのか」を聞きに来ているような状況。
実際、redmine の利用経験は「4年以上」の人が多数で、驚きました。
 一般的な OSS とは違い、redmine Osaka はソフトそのものの使い方やバージョンアップ情報を共有するコミュニティではなく、日頃現場で戦っている「同士の懇親会」の様相なのです。
(引用終了)

【追記2】

(3) みうら かずひと(三浦 杏仁)さんはTwitterを使っています: 「本編・懇親会一次・二次…すべてで「すごく有用なことを教えてもらった」気がします。なんというか…勉強会に「行き始めた」頃の感覚を思い出しました。一緒に話して頂いた方、質問に答えていただいた方、多くの人にありがとうです。 #redmineosaka」 / Twitter

(3) みうら かずひと(三浦 杏仁)さんはTwitterを使っています: 「ちょっと抽象的な表現になっているのは「いっぱい”これは聞いて良いのか?"なことにも快くお話してくれた方」が多かったからです。そういう意味でもありがとうです。」 / Twitter

(3) akipiiさんはTwitterを使っています: 「@kazuhito_m 行き始めた頃の感覚とは、どんな感じなんでしょうか?」 / Twitter

(3) みうら かずひと(三浦 杏仁)さんはTwitterを使っています: 「@akipii 「すごい人々がいるな憧れるわ」「有用な情報やな」「学んで帰らな」というような、そんな気持ちです。」 / Twitter

| | コメント (0)

2019/08/30

Redmineインスタンスを分割したい状況の考察

@nekosanzさんから、Redmineインスタンスを分割したいつぶやきがあって、色々考えさせられたのでメモ。 論理的でないラフなメモ書き。

【参考】 かるね@nekosanzさんはTwitterを使っています: 「Redmineの今後について、やはり複数に分ける方向に進んだほうが幸せかも。なやましー」 / Twitter

かるね@nekosanzさんはTwitterを使っています: 「@yassan168 そんな感じです。お客さんによって規模と契約が極端に違うせいか、同じ部門でも求められる成果や粒度が違います。大企業向けのチームはロールや作業時間、カスタムフィールドに対する要望も多くなってます。サーバーのEOSLの兼ね合いもあるので、方針決めを楽しんでます。」 / Twitter

りょうま@Redmine大阪LTするよさんはTwitterを使っています: 「@nekosanz1 @netazone @yassan168 多分、利用者同士は各Redmineの中で話するので困らないと思いますが、nekosanzが「どのインスタンスの?」と聞く手間が増えますね。」 / Twitter

akipiiさんはTwitterを使っています: 「@kam1nchu @netazone @nekosanz1 @yassan168 組織とRedmine の間がどれだけ密結合なのか、という基準になると思います。一人のユーザーが複数のRedmine インスタンスに関わるような組織、つまり組織とRedmine が疎結合ならば、運用は煩雑になるでしょうね。」 / Twitter

かるね@nekosanzさんはTwitterを使っています: 「@yassan168 @akipii @kam1nchu @netazone 複数あるとめんどい部分もありますね。ただ、それなりの組織の活用レベルを上げる(密な状態になっていく)と特定のビジネスに合わせて特化してくような感じです。トラッカーやカスタムフィールド、作業時間、インターフェイスとか。今の環境見直しだけでも出来そうですが、他への影響を考慮してます」 / Twitter

neta@ 8/31(土) Redmine 大阪で会いましょうさんはTwitterを使っています: 「@nekosanz1 @yassan168 @akipii @kam1nchu 1人 1 Redmine と正しくスコープ設計ができるならいいと思います。私は失敗した。顧客共有用 Redmine が開発から保守フェーズに入った際に社内用分離→内緒話を不適切な方に書く事故多発。 ワークフローやロール数は増えるかもしれないけど、分割しないと解決できないケースはなんだろう?外部共有?」 / Twitter

黄巻紙さんはTwitterを使っています: 「@netazone @nekosanz1 @yassan168 @akipii 「分割しないと解決できない」とはちょっと違いますが、例えば「特定の部署ではものすごく欲しいけど、ほかの部署では不要なプラグイン」を入れたとして、そのプラグインが原因でバージョンが上げられなくて迷惑するみたいなケースは想像してました。実際の運用経験からのものではないですが…」 / Twitter

かるね@nekosanzさんはTwitterを使っています: 「@kam1nchu @netazone @yassan168 @akipii まさしくそんな感じです。かなり特殊な事例ですが、特定対象(うちだと顧客)において、1番でかくて複雑な運用を大人数で回してるプロジェクト群を「根本見直し」するケースですね。トラッカーやロール、時間管理、プラグイン、諸々変えるのですが、他の部門には関係ないですし、既存運用もあるので。」 / Twitter

akipiiさんはTwitterを使っています: 「@kam1nchu @netazone @nekosanz1 @yassan168 なるほど、Redmine に対して、部署ごとに要求が違うのに真因があるわけですね。単一の標準Redmine では、多種多様な社内のニーズに耐えきれなくなる事例。面白いですね。」 / Twitter

やっさん??さんはTwitterを使っています: 「@akipii @kam1nchu @netazone @nekosanz1 Redmineというか無償なOSSあるある問題な気がします。管理者コストを代償にフレキシブル&ニッチオブニッチに対応し、それらの影響でVer.UP出来ないとか、運用が複雑になってしまって、構築した人しか扱えないものになってしまうとか、割とアンチパターンに成り易いので注意がいるパターンです??」 / Twitter

やっさん??さんはTwitterを使っています: 「@akipii @kam1nchu @netazone @nekosanz1 とは言え、何でもかんでも断るのも、良い関係性保てないし、そもそも改善出来ないので、改善の本質を考えたり、とてもバランス感覚が必要なところじゃないかなぁと思います。」 / Twitter

neta@ 8/31(土) Redmine 大阪で会いましょうさんはTwitterを使っています: 「@yassan168 @akipii @kam1nchu @nekosanz1 以前はノリでプラグイン入れてたけど、全社利用になったので「安定、信頼、長期利用」に方針転換した。 バランス大事なのほんとにそう。ウチは幸にもヘビーな要望がないので、コミュニティの知恵を借りることで結構なんとかなってる感謝。 Redmine 管理者レベルが上がると思って楽しんでます(まだ)」 / Twitter

akipiiさんはTwitterを使っています: 「@netazone @yassan168 @kam1nchu @nekosanz1 みんなの意見が参考になります。Redmine はカスタマイズしやすい特徴があるが、組織が大規模になり、高品質な運用が求められてくると、安易なカスタマイズが仇になるわけか。組織構造よりも組織文化とRedmine の間の課題かもしれない。」 / Twitter

【感想と考察】 【1】会社標準の単一Redmineインスタンスから複数のインスタンスを立ち上げたい時、どんな考え方が判断基準になるだろうか?

僕は、組織とRedmineの間でどれだけ密結合になっているか、という基準で区別できるだろう、と考えている。

たとえば、組織とRedmineが疎結合の場合、Redmineインスタンスは所属部署に関係しないので、一人のユーザは複数のRedmineにログインする運用になる。 よって、ユーザは各Redmineのログインパスワードを別途記憶せざるを得ないし、Redmineに書き込んでいる時に自分が今どのRedmineインスタンスにいるのか、逐一存在確認する状況が発生してしまう。 特に、システムごとにRedmineが乱立していると、作業日報や障害・問い合わせの記録をする時に、複数のRedmineチケットに記入する時の入り口の判断にパワーを取られるのが、あまり楽しいものではない。

一方、組織とRedmineが密結合の場合、Redmineインスタンスは所属部署に強く関係づけられているので、一人のユーザは所属部署が持つ単一Redmineだけの運用になる。 ユーザの作業全ては単一Redmineのチケットに起票するだけなので、ブラウザでどのRedmineだっけ?と考える手間は全く無い。 たぶん、ユーザにとっては入り口が楽な分、運用も定着しやすいだろう。

【2】では、Redmineと組織の関係にはどんなパターンがあるのか?

たぶん2種類ある。 組織を単一Redmineインスタンスに標準化するパターンと、組織ごとに複数のRedmineインスタンスが混在するパターン。

前者では、単一RedmineのRedmineプロジェクトに組織構造の情報が埋め込まれているはずだ。 しかし、Redmineの設定は標準化されているので、部署単位の文化はあまり埋め込まれていないだろう。

ただし、組織とRedmineの関係は密結合になっている。 Redmineで実現された標準プロセスに埋め込まれたワークフローや諸々の運用ルールに、組織に属する全ての人達が規定されられているはずだ。 何となく窮屈な気もする。

後者では、Redmineインスタンスごとに組織(部署)が対応付けられているはずだ。 よって、Redmineには組織の情報だけでなく、部署単位の組織文化がふんだんに埋め込まれているだろう。 たとえば、ワークフローやカスタムフィールドに、業務やシステムの特徴がもろに出ていたり、部署の管理職が欲しがる情報がカスタマイズして埋め込まれているだろう。

ただし、組織とRedmineの関係は疎結合になっている。 一人のユーザは、こちらのRedmineに入ればその組織文化を受け入れ、あちらのRedmineに入れば別の組織文化を受け入れる。 たとえば、ある組織のレビュープロセスが普通と思っていても、別の組織のレビュープロセスが違っていれば、Redmineのワークフローは大きく異なっているはずだ。 おそらく、新規加入した委託契約の開発者は、乱立したRedmineごとの開発プロセスの違いで混乱してしまうのでは、という気がする。

だから、複数のRedmineの集計ビューを一つのRedmineで見たい、という要望も発生しがちだ。 特に、PMOのように複数の組織やPJを横断する情報が欲しい場合、複数のRedmineのビューを手軽に見たくなる。

複数Redmineの内容を一つのRedmineに集約して見る方法: プログラマの思索

【3】とはいえ、会社標準の単一のRedmineインスタンスで運用を始めて全社に展開していくと、ユーザから細かな改善要望が結構出てくる。 Redmineの良さは、カスタマイズのしやすさなので、割と簡単に要求を受け入れて、その会社特有の業務に使いやすくできる。 しかし、カスタマイズしすぎると、Redmine本体が複雑になってしまい、ユーザの多様なニーズに添えなくなる時がある。

つまり、単一の標準Redmineでは窮屈すぎて、組織内にある多種多様なニーズを実現できなくなる臨界点が現れるわけだ。

上記の議論の通り、Redmineのカスタマイズのしやすさが、逆にRedmineの普及や浸透に制限をかけてしまう場合がある。 そう言えば、Jenkinsでも同様な話があった気がする。 例えば、Jenkinsでデプロイ作業やデプロイのパイプラインをどんどん作り込んでいくと、どんどん複雑になってしまい、Jenkins職人と言われる属人化した人しか触れなくなる、みたいな。 たぶん、Redmineでも、Redmine職人しか会社のRedmineをカスタマイズできない、と言った症状が出てくるかもしれない。

では、単一Redmineが複数のRedmineに分離したくなる臨界点とは、どんな条件があるのだろうか? その臨界点では、組織とRedmineの間に、どんな緊張関係が出てくるのだろうか?

実際、単一Redmineでは使いにくい、という不満が大きければ、その不満を発する組織と単一Redmineには大きなコンフリクトが発生しているからだ。

たぶん、いろんな状況や理由があると思うので、色々聞いてみたい。

続きを読む "Redmineインスタンスを分割したい状況の考察"

| | コメント (0)

2019/07/20

Redmineの口コミ評判の記事のリンク

Redmineの口コミ評判の記事を見つけたのでリンクしておく。読んでいると面白い。ラフなメモ。

【参考】プロジェクト管理ツール「Redmine」の評判と実態|徹底した比較・調査結果をご紹介! | 発注業者比較なら【アイミツ】

Redmineのレビュー(口コミ・評判) |【ITreview】IT製品のレビュー・比較サイト

【1】口コミ評判記事のユーザを見ると、メーカー・営業・事務など、IT系以外の人が多い。そういう人達までRedmineが利用されているのが面白いと思った。

RedmineはRuby製なので、WordpressのようなPHPアプリに比べると、IT初心者にとってセットアップが難しいのではないか、と思う為だ。でも、そういう心配も無関係に広がっているみたい。

やはり、Redmineでオンラインのタスク管理、コミュニケーション、情報共有を期待して成果を出しているみたい。

【2】最も興味がある内容は「改善してほしいポイントは何でしょうか?」の箇所だ。最も多い内容は「古臭いと思われるUI改善」だが、それ以外の箇所も気になった。

(一部引用開始)スレッドが続くと、個人の意見と複数関係者の意見の区別が仕分けづらくなるケースがあり、再度スレッドを立てるケースがある。

チケットのリマインダー機能を標準で実装して欲しい。例えばチケットの期日●日前にリマインドする機能や、チケットの期日が●日過ぎた場合にリマインドする機能が欲しい。(引用終了)

リマインダー機能はrakeバッチで付属しているが、IT初心者にとってハードルは高いだろう。画面上からリマインダー機能が使えるようになれば、ユーザに優しいUIになるだろうと思う。

スレッドの件は、チケットが掲示板代わりになっているからだろう。チケットに全ての記録が残る点はメリットだが、たくさんの情報が散在したり、テーマが発散する場合もある。Redmineの機能よりも、運用ルールも考えた方がいいかもしれない。一方、Redmineの全文検索プラグインがあれば、散らばった情報であってもRedmineにデータが集約されていれば、いつでも検索できるので、気にしなくてもいいかもしれない。

(一部引用開始)ガントチャートをExcelへエクスポートできる機能が欲しい。PDFへExportできますが、資料として使用したい場面があるため、追記が容易なExcelにエクスポートする機能が欲しいです。

個々のタスクの依頼ややり取り管理のし易さの反面、プロジェクトマネジャー目線ではEVM等コストや全体がやや見えにくい印象。(引用終了)

Redmineは開発者の観点では十分すぎる機能があると思う。しかし、管理者の観点では、レポート出力の機能が物足りないだろう。報告書をもっと手軽に作りたい、コストやスケジュールを鳥瞰したり特殊な観点で見たい、など、いろんな要望があるはず。こういう要望に対しては、Redmineの標準機能ではなく、プラグインによるアドオンや外部連携ツールなどで対応すべきと考える。

(一部引用開始)メジャーバージョンアップ時の移行の手間を軽減してもらいたい。メジャーバージョンアップとなると、データや拡張機能の互換性に問題が発生しやすい。(引用終了)

Redmineのバージョンアップやデータ移行に関する要望は割と多い。RedmineはOSSの割には進化が速いので、バージョンアップに追随することはIT初心者にとってハードルは高いだろうと思う。以前から、@acha_821 さんが「RedmineもJenkinsみたいに自動アップデートする仕組みが欲しい」と要望を出していたが、他のユーザも同じように思っているのだろう。

2018年初頭におけるRedmineの動向に関するメモ: プログラマの思索

Redmineの直近の課題~競合ツールGitlabに対抗できるか: プログラマの思索

現時点では、おそらくBitnamiのVMイメージやDockerなどがその解決策の一つになるだろうと思う。最終的には、Redmine本体で自動更新機能ができるといいのだろうと思う。

| | コメント (0)

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)

より以前の記事一覧