Redmine

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)

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)

より以前の記事一覧