Redmine

2020/03/09

Redmineのステータスに説明機能が欲しい要望の背景

Redmineのステータスに説明機能が欲しい要望のやり取りがあったのでメモ。

【参考】
Feature #2568: Description for issue statuses - Redmine

akipiiさんはTwitterを使っています 「なるほど。トラッカーの説明機能はあるが、ステータスも説明欄が必要な利用シーンが聞きたい。RT @minazou67: Redmineの運用が上手くいくかどうかはトラッカーとステータスとワークフローの設定次第と言っても過言ではない。そしてステータスにはコメント欄が欲しい…」 / Twitter

齋藤さんはTwitterを使っています 「@akipii @minazou67 私もステータスのコメント欄に一票。独自に作ることが多く、人によって定義が違ってブレますから。もちろん、wikiに書けば良いという話もありますが、初心者に解りやすいのは、コメントかなと。 #redmine」 / Twitter

みなぞう@脱OL系エンジニアさんはTwitterを使っています 「@saito0119 @akipii プロジェクト毎に独自のトラッカーを作成するシーンが多くて、進捗率の値の関係で同じ様なステータスが複数あったりするので。トラッカー単位でグルーピングされたステータスを作成できれば良いのですが、そうすると管理画面とDBが複雑になってしまうので。」 / Twitter

みなぞう@脱OL系エンジニアさんはTwitterを使っています 「@saito0119 @akipii 1人の管理者が上手くコントロールすれば良いのですが、専任の管理者を置くのは無理なので複数のPMがトラッカーやステータスを管理している状態だとどうしても乱雑になってしまいます。」 / Twitter

みなぞう@脱OL系エンジニアさんはTwitterを使っています 「@saito0119 @akipii なのでステータスが20個とかできてしまい、一覧には進捗率で並ぶので何がなにやら分からない状況に。。説明欄があれば、このトラッカーで使っていてこの状態の場合はこのステータスと分かるのでありがたいです。」 / Twitter

みなぞう@脱OL系エンジニアさんはTwitterを使っています 「@saito0119 @akipii Redmineを分ければええやんと言われればそれまでなのですが、プロジェクト単位で立てるのは管理コストが厳しいのです。。saasを使えば楽ですが、使えないプロジェクトも多いのと、数が増えすぎると横断的に把握し難いというデメリットもあるので悩ましいです。」 / Twitter

u6k_yu1さんはTwitterを使っています 「@akipii @minazou67 わかる。作業がどういう状態になったらそのステータスに変更するのか、というのが認識統一しづらかったりする。「作業中」が、事前調査段階なのか、課題で詰まってるのか、手を動かすだけなのか、みたいな。」 / Twitter

akipiiさんはTwitterを使っています 「@u6k_yu1 @minazou67 なるほど、Redmine のステータスは、トラッカーごとに意味が異なると。同音異義語みたいですね。すると、トラッカーごとにステータスの説明機能が必要?」 / Twitter

みなぞう@脱OL系エンジニアさんはTwitterを使っています 「@akipii @u6k_yu1 そこは難しいですね。そこまでするならトラッカー毎にステータスを管理するのが素直だと思うのですが、そこまですると既存からの変更が大き過ぎるのでNGかと。なので単純にステータスに説明欄があれば個人的には満足です。」 / Twitter

akipiiさんはTwitterを使っています 「@minazou67 @u6k_yu1 さっそく @g_maeda さんが本家チケットを掘り返してくれてます。 Feature #2568: Description for issue statuses - Redmine https://t.co/B6aglS4ZMY」 / Twitter

【1】Redmineのステータスに説明機能が欲しい要望の背景としては、各部門ごとにRedmineのトラッカーやステータスに独自の意味を付与して運用しているので、メンバーに説明するために欲しいらしい。
トラッカーやステータスは単一のインスタンスであっても、各部門ごとに独自の意味を持って運用している。
すなわち、トラッカーやステータスは同音異義語のような振る舞いを持っているらしい。

こういう背景が発生した要因も何となく理解できる。
日本企業では、現場の権限が強いので、自分たち独自の共通言語を発展させてきた場合が多い。
すると、各現場では、単一のワークフローであっても、自分たち流に読み替えて運用することで、自分たちの現場の文化に合わせようとする。

特に大企業の場合、事業部門はプロフィットセンターなので声も権限も大きい。
したがって、事業部門ごとに組織文化も育まれてくるので、業務フローの同音異義語も発生しやすくなるのだろう。

ただし、ワークフローごとにステータスの説明機能を付ける事までは不要で、単にステータスの説明だけで十分とのことだった。

【2】他方、トラッカーの説明機能は、Ver4.1で実装された。

Redmine 4.1 新機能紹介 (2/3) | Redmine.JP Blog

Feature #442: Add a description for trackers - Redmine

つまり、独自のトラッカー名称で運用している場合、この説明機能があれば、新規加入したメンバーや派遣社員も理解しやすくなるだろう。

同様に、ステータス機能も本家チケットに10年以上前からあがっているので、実現できるといいだろうと思う。

Feature #2568: Description for issue statuses - Redmine

【3】こういう話を聞くと、Redmineは会社で単一の標準Redmineで運用するのがベストではなく、Redmineインスタンスを各部門にVMで配布して自由に使ってもらうという運用もベターではないか、という気持ちになってくる。
特に、大企業ほど各事業部門ごとに組織文化も業務フローも大きく異るので、単一Redmineで開発プロセスや業務フローを標準化するのは所詮無理があるからだ。

一方、デメリットは、RedmineインスタンスのVMを沢山ばらまいた場合、複数のRedmineインスタンスのVerUp作業が非常に煩雑になる点だ。
しかし、このデメリットも、AWSのコンテナサービスやマネージドサービスを上手に使いこなせれば、解決できるだろうと考えている。
実際、ファーエンドテクノロジーでは、RedmineホスティングサービスをAWS上でRedmineの複数インスタンスを提供している訳だが、そういう問題点は既に解決されている。
つまり、似たような発想で、複数個のRedmineインスタンスのVerUp作業をコンテナ化&自動化することで解決できるだろう、と思っている。

AWS上でクラウドネイティブで再構築した「My Redmine Gen.2」リリース! - ファーエンドテクノロジー株式会社

Redmineのホスティングサービスをクラウドネイティブで再構築 | RubyWorld Conference 2019

つまり、複数個のRedmineのインフラ構築そのものも、Infrastructure as Codeを実現してしまえばいい訳だ。
この辺りも色々考えてみる。

| | コメント (0)

2020/03/01

AWSクラウドデザインパターンの感想~RDP(Redmine Design Pattarn)の構想

「AWSクラウドデザインパターン」を読み直した。
以下、AWS初心者によるラフなメモ書き。

【参考】
AWS-CloudDesignPattern

【1】「AWSクラウドデザインパターン」本を買ったのは、2013年のデブサミの時だった。
玉川さんにサインを書いてもらった。
「Work hard, Have fun, Make history!」と。

あの頃はまだCDP(クラウドデザインパターン)理解しきれてなかった。
AWSに触れて、ようやくCDPの威力を理解することはできた。
ただし、CDPに記載されたAWSサービスは2012年頃の内容なので、Lambdaなどが含まれていないから、そういう最新のサービスで置き換えられる部分はいくつかある。

振り返ると、2010年代前半にCDP本が出たからこそ、AWSが日本に普及し始めたのだと思う。
CDPは、システムのアーキテクチャ設計、インフラ設計において、AWSのサービスや機能をどの場面で適用するとどんな効果が得られるのか、を明確に示唆してくれる。
クラウドによる設計や実装を試行錯誤していた頃に、CDPを用いることで、より良いクラウドによるアーキテクチャ設計が実現可能になったためだ。
また、アーキテクト同士で、クラウドによるアーキテクチャ設計について、共通の言葉を使って議論できるようになった。
そういうメリットがCDPにはあった。

CDPの形式はGOFのデザインパターンに似ている。
CDPの形式はもっとシンプルだ。
解決したい課題、クラウドでの解決、AWSによる実装、利点、注意点、その他の関連パターン、という項目で必要最低限に絞り込まれている。
CDPというカタログを読んでいくと、どのユースケースでは、どんなパターンを用いるとどんな利点があるのか、クラウドでの解決方針に沿ってAWSはどんなサービスや機能を提供してくれているのか、が理解しやすくなる。
実際に、オンプレのインフラ構築や運用で苦しんできた経験のある人ほど、AWSによる実装方法で、なるほど、と気づく場面が多いはずだ。

イントロの部分もすごく惹かれた。
AWS普及に心血を注ぐ3人が、ある居酒屋にて、クラウドを語る上で共通言語となるデザインパンターンのようなものが必要である、という議論が白熱し、その場で40種類以上のクラウドデザインパターン(CDP)の種をノートに書き出した、とある。
この文に触れて、クラウドの導入でつまずいているプロジェクトがあって苦労したり、オンプレの設計思想に囚われすぎてAWSの良さを活用しきれていない場面で歯ぎしりしたりしたのではないか、と勝手に想像した。
そういう経験を元に、CDPが生み出されたのだろう。

【2】そんなことを考えているうちに、Redmineデザインパターン(RDP)みたいなものが作れないだろうか、と想像したりした。
Redmineの導入・運用も既に10年以上の蓄積があり、必要な運用ノウハウはネット上にたくさん語られているし、運用で必要なロール(組織上の役割)もいくつか語られている。
しかし、そういうノウハウはバラバラに散らばっているに過ぎない。
それらを一つの体系として、暗黙知となっているものを形式知化することには意義があるはず。
なぜなら、まだ困っている人も多いだろうし、経験者が議論する時の共通言語はまだ暗黙知になっている部分が多いからだ。

僕も以前、チケット駆動開発のパターン集みたいなものを編み出そうと考えていた。
そのパターンの根底は、アジャイル開発にチケット駆動開発を適用するにはどんな考え方が必要なのか、があった。
でも、それから5年以上たち、今は情報システム部門の人達が一般ユーザに使ってもらう運用基盤に変化したので、異なるパターン集が必要になっていると思う。

今僕のアイデアとしては、パターンに4つほどのレイヤで階層化して詳細化できないか、と考えている。
イメージは、ユースケース層>マネジメント・ロール層>アプリ・機能層>ソース・実装層。
たとえば、ユースケース層では、課題管理・ソフトウェア開発・サポートデスクなどの実際の利用シーンでカテゴライズする。
マネジメント・ロール層では、Redmine職人・Redmineエバンジェリスト・Redmine警察のようなロール、PMxTMマトリクスのような組織への導入方法。
アプリ・機能層では、Redmineの各機能のベストプラクティス。たとえば、チケットのワークフロー、JAXAが生み出したカスタムフィールドやプロジェクトのOR・AND条件など。
ソース・実装層では、ViewCustomizeプラグインによる課題解決、プラグインやカスタマイズによる課題解決など。

このようにパターンをレイヤ化して区別することで、パターンの粒度を区別できること、初心者や経験者が会話できる共通言語を提供できること、というメリットがあると思う。
僕が以前考えていたパターンはアジャイル開発への適用に特化しすぎていたので、2020年現在の実情に合わせたデザインパターンを作れたらいいなあ、と考えた。


| | コメント (0)

2020/02/09

Redmineのトラッカーをヘーゲル弁証法とフッサール現象学の観点で議論してみた議論のリンク

@tw_yukiaさんとの楽しい会話と、自分のラフな考えをメモ。

【参考】
Redmineのトラッカーをヘーゲル弁証法とフッサール現象学の観点で議論してみた - Togetter

Redmineをどうも好きになれない人のための、20%の基礎を抑えれば、80%位の業務に対応できると気がついた長話。|ゆきあ|note

「Redmineのトラッカーは弁証法の結論的なので、人に向けて説明する事でしか適切な説明が出来ない」という@tw_yukiaさんの仮説は、僕も完全に分かっていない。
おそらく「トラッカーとは行動パターンの大分類である」という主張から、実際に行動してみて初めてトラッカーの意義が分かることかな、と推測したりするが分からないので、今度聞いてみようと思う。

僕が理解する弁証法は、「勝つための論文の書き方」に記載のある、人文科学や社会科学でよく使われるアウトラインのイメージ。
つまり、ある人の主張に対し、その主張の穴を見つけて論理的に崩し、最後に自分が正しい回答を提示するイメージ。

論文作成の技法part1~論文の構造: プログラマの思索

僕が理解するトラッカーは、ワークフロー、帳票、Issue Trackingの3種類。
個人的には、@g_maedaさんが主張される「トラッカーとは帳票である」意見が重要と考える。
理由は、業務のExcel管理台帳や紙の帳票は、トラッカーにマッピングできれば、全てチケット管理で実現できるからだ。
そのおかげで、Redmineがソフトウェア開発以外に社内の簡単な業務ワークフローにも応用された事実があると思う。

だから、@g_maedaさんはRedmineの「トラッカー」を「チケット種別」へ変更するチケットが提案されたのだ、と理解している。

Redmineの「トラッカー」を「チケット種別」へ変更するチケットが提案されている: プログラマの思索

一方、@akahane92さんが主張されるIssue Trackingの意見も重要と思う。
僕は、Issue Trackingとは、No ticket, No commitに代表されるトレーサビリティがその性質の核心にあると考えている。
単にチケットにログが記載されているだけでなく、構成管理の配下にあるソースや設計書の変更履歴とチケットが密接に連携されることで、変更管理もチケット管理で代用できる、という考えだ。

Patch #29045: Change Japanese translation for Tracker - Redmine

(引用開始)
--- Japanese Part ---
意見者の背景
Redmineを利用して10年余りになります。主に製造業の業務システムと装置研究開発向けのIssue Tracking System及び知識基盤としてRedmineを利用しています。現在、国内外1400名の利用者があり、300プロジェクトに40万チケットが記録され、閲覧回数は70万ページビュー/月です。( 事例紹介論文とスライド )
意見
この翻訳提案には賛成できません。
「トラッカー」のままに維持するか、どうしても和訳を変更するなら「課題追跡様式」が良いと私は思います。
理由
Redmineの最大の価値は「追跡パターンの選択によって課題解決を促進させる仕組み」にあると私は考えています。
現実社会の多様かつ難解な課題を解決に導くには、戦略(ここでは「課題解決のための追跡パターン」を指す)の選択が不可欠です。
どのような戦略で課題にアプローチするのかが、複雑な課題を解決できるかどうかの決め手になります。
Redmine における Issue Trackerとは、課題を解決に導くための戦略をパッケージ化して、ITSプロジェクト毎の取捨選択を可能にしたものなのです。
なぜなら、解決対象のプロジェクトの領域と目的よって、選択すべき戦略(パターン)の組み合わせは異なるからです。
ゆえに、Redmineの最大の価値を体現している Issue Tracker の和訳には、追跡戦略、パターンといった特徴が包含され、利用者に向けて表現されていなければなりません。
(引用終了)

こういう議論も次回のRedmine大阪でやってみたいと思う。

第21回 Redmine大阪 これからはじめる Redmine 2020(令和2年) 2020/04/04(土) 13:00~- connpass


| | コメント (0)

2019/12/22

今後のRedmineコミュニティで議論してみたいアイデア

今後のRedmineコミュニティで議論してみたいことを書く。
ラフなメモ書き。

【参考】
Redmine Advent Calendar 2019 - Adventar

【1】今年のRedmineコミュニティで一スタッフで活動してきて、気になったことは、参加者のターゲット層が変わってきているのに、ちょっとコンテンツが限られているかな、と思う時があったこと。

コミュニティの参加者のアンケートを取ると、2年以上Redmineを利用しているユーザが多いが、Redmineを管理者として長年携わって色んな知見を持つ人だけでなく、Redmineを利用する立場から管理者になった人がRedmineの情報が欲しくて来ている人もいる。
たとえば、派遣や下請けでRedmineを利用していたが、自社に戻って自分が管理者権限を持ってRedmineを利用したい時に、どんなノウハウが必要なのか、を知りたがっている層がいると感じた。

そういう人達に、Redmineのカスタマイズ方法や機能紹介などの技術面に特化した話が多かったかな、と思う時があった。
本来は、Redmineをプロセスへ適用する方法、情報システム部門としての運用方法、ソフトウェア開発以外にRedmineを利用する事例紹介などがもっとあってもいいかな、と考えている。

もちろん、そういう企画をRedmine大阪や東京Redmineでもやってきた。
たとえば、Backlog・JiraとRedmineの比較に関するパネルディスカッションや、チケットに馴染む文化に関するパネルディスカッションも企画して、実際に好評だった。

よって、来年のRedmineコミュニティでは、Redmineのカスタマイズや機能紹介などの技術面だけでなく、Redmineの運用やプロセスの議論もできる企画を取り入れてみたい、と思っている。

【2】その観点で自分が考えているテーマはいくつかある。
思いついたことをラフにあげてみる。

【2-1】Redmineと組織が相互にどのように関係し合っているのか?
その観点では、「Redmineは組織や業務に大きく依存する」「Redmineの導入によって、組織の文化が静かに変化を受ける」の2つがある。

前者は、Redmineはカスタマイズしやすい特徴があるので、組織のこだわりや組織の独自プロセスを実装しやすい一方、大きくカスタマイズしてしまいがちな面もある。
後者では、Redmineによって、メンバー間のコミュニケーションを活性化させ、メンバーの貢献意欲を引き出し、チームが活性化する面もある。
そういう双方向の内容を汎用的なノウハウとして提示できればいいなあと思う。

第15回東京Redmine勉強会の感想~Redmineの2つの顔が相異なる2つのユーザ層を生み出している #redmineT: プログラマの思索

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

【2-2】Redmineのインスタンスが複数個に分裂したり増殖する発端は何か? 
Redmineインスタンスと組織の規模には何かしらの関係があるのか?

過去にも色々考えてきたが、Redmineインスタンスの数と組織の規模には、何かしらの関係があると思う。
今の僕の仮説は、会社内に組織文化や業務が全く異なる部署が2つ以上存在した場合、Redmineのインスタンスそのものを分けた方がいい、というもの。
つまり、Redmineのトラッカーやワークフローそのものが全く異なると認識できるならば、単一のRedmineで無理に標準化しない方がいいだろう、というもの。

以前は、社内には単一の標準Redmineでやるべきであり、そのためのノウハウを収集していくべき、と考えていたが、実際にはそんなケースばかりではない、という事例を勉強会で何度も聞いてきたからだ。

極端には、情報システム部門は、各事業部にRedmineインスタンスをクラウド上のVMで払い出して、各事業部で自由に使ってもらうユースケースもあるだろう。
ただし、複数個のRedmineを同時にVerUpして社内のバージョンを統一する運用ノウハウも必要になるだろう。

Redmineインスタンスを分割したい状況の考察: プログラマの思索

Redmineインスタンスとプロセスの関係~Redmineは組織に従うのか、Redmineに合ったチームを作るべきか: プログラマの思索

他に、Redmineの柔軟性がRedmineコミュニティを活性化させている、という観点の議論も可能と思う。

柔軟なソフトウェア設計はOSSコミュニティを活発化させる~OSSソフトウェアとOSSコミュニティの密接な関係: プログラマの思索

【2-3】Redmineで運用しやすいチームビルディングやファシリテーション技法はあるか?

プロジェクトリーダーの立場でRedmineをチームで使っている時に、すでに知られているチームビルディングやファシリテーションの技法と組合せることで、チーム運営を円滑化できる経験をしてきた。
個人的にはアジャイル開発のプラクティスが非常に相性が良かった。

最近では、Redmineを情報システム部門の立場で使う場合が多いので、そういう利用シーンではどんなファシリテーションを用いることで、組織文化に良い影響を与えられるのか、というノウハウも集めてみたい。

【2-4】Redmineを普及促進するために、Redmine職人・Redmine警察・Redmineエバンジェリストのような人達はどんな役割を担うべきなのか?

大規模な組織でRedmineを普及促進しようとする時、あるいは、情報システム部門の立場で各部門にRedmineを普及促進したい時、Redmine職人・Redmine警察・Redmineエバンジェリストのような役割が必要になってくる。
では、彼らは、問題が噴出した時に、どのように解決しているのか?
その辺りの事例を集めてみたい。

【2-5】Redmineと他ツールではどんな違いがあるのか?

JiraやBacklogを使ってきた人がRedmineを利用したとき、そこに感じる違和感をもっと聞いてみたい。
僕はRedmineから入ったので、JiraやBacklogの機能に違和感を感じていたが、逆のケースの人たちの意見も聞いてみたい。
その意見を聞くことで、Redmineの特異性や差別化できる機能がより的確に現れるだろうと思うから。

【2-6】Redmineをソフトウェア開発以外で利用できるユースケースは何か?

情報システム部門がRedmineを現場に提供した場合、今まで思いついたことがない利用方法があるだろうと思う。
例えば、サポートデスクや課題管理はすぐに思いつくが、議事録、本などの蔵書、サーバーやルータ、稟議書、交際費の管理に使っている事例も聞いた。

その本質は、Excelの台帳で従来管理していたものは、全てRedmineのチケットに置き換えられる、という点にあると考える。
その場合、いろんな現場では、どんな台帳が必要とされていたのか、聞いてみたい。
そういう事例を集めることで、Redmineの利用シーンがより広がっていくだろう。

| | コメント (0)

2019/12/21

Redmine 4.1.0 released !!

待ちに待ったRedmine 4.1がついにリリースされた。

Redmine 4.1.0 released - Redmine

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

MAEDA GoさんはTwitterを使っています: 「Redmine 4.1.0のタグ打たれた。 https://t.co/RyLiewo9wp」 / Twitter

1年間の機能改善が盛り込まれているので、たくさんある。
僕が興味を持つ機能改善は、Issue history tabs、Allow pasting screenshots from clipboard 、Query system for Projects pageの3つだ。
つまり、チケットのコメントが整理されたこと、プラグイン無しで画像のクリップボード貼り付けが可能になったこと、プロジェクトのフィルタ機能が追加されたこと、だ。
これらの機能改善によって、Redmineがより使いやすくなった。

その他の機能などを見ると、今ある機能を改善していく内容が多い。
つまり、Redmine本体に機能を大幅に追加するのではなく、ユーザビリティを上げるために、より直感的に使いやすくする機能改善が多いように思う。

そういう背景を鑑みると、Redmineの機能はほぼ成熟されていて、昨今のUIやフレームワークに関する技術的なトレンドを取り入れる方向に進んでいるように思える。
すなわち、Redmineを劇的に変化させる方向ではない。
この方向性は、ユーザに戸惑いを与えず、UIや機能に一貫性を持たせている点で良いことだが、昨今の技術的トレンドからやや遅れている点もあるかもしれない。

そういう辺りも色々調べてみたいと思う。


| | コメント (0)

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)

より以前の記事一覧