コミュニティ

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/10/24

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

昨夜行われた第3回astah関西勉強会の感想をメモ。講演者、スタッフ、参加者の皆さん、ありがとうございました。

【参考】第3回astah関西勉強会「もやもやを分解しよう」 - connpass

「モデリング事例紹介」10月23日に大阪で開催 ? 参加申し込み受付中! | astah in 5 min

PlantUML Example for モデルベース要件定義テクニック - Qiita

【1】ツイッターやastah blogぐらいしか流していないのに、狭い部屋に参加者が30人以上も来てくれました。懇親会でも、以前から勉強会の存在は検知していて、今回初めて参加できた、という人もいた。勉強会のターゲット層、議論するドメインは非常に狭いと思うのに、興味を持つ人が多くて正直嬉しかった。

僕は、astah関西コミュニティでは、プログラミングとモデリングの間をモデリングツールや事例紹介の観点で行ったり来たりする議論ができるといいな、と考えている。そういう思いに共感してくれる人たちが少なくとも存在する、と気づけたのはとても嬉しかった。

【2】以下、講演の内容で感じたことをメモしておく。

【2-1】@ogomorさんの講演PlantUML+RDRAの話は、以前から聞きたいと思っていた。過去に色々書いてきた。

PlantUML Example for モデルベース要件定義テクニックの記事のリンク: プログラマの思索

さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナーの感想 #RDRAセミナー: プログラマの思索

リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンク: プログラマの思索

RDRAについては、システム地図という考え方が重要と考えている。要件定義から論理モデルや実装モデルまで、要件をトレースする仕組みがシステム地図として実現されている。つまり、RDRAでは、トレーサビリティを重視した手法であると思っている。僕は、モデリングではトレーサビリティが重要と思っているので、RDRAの考え方は好きだ。

但し、RDRAでは、UMLを拡張した図を多用するので、astahなどのUMLモデリングツールでは、UMLの制約に引っかかって全ての絵を書くことができない弱点があった。そこで、PlantUMLを使うと、自由に描けるので、RDRAの技法を全て実現できる。しかも、テキストベースなので、設計書をMarkdownで書けば、プログラムから設計書まで全てGitで構成管理の配下に置ける。

akipiiさんはTwitterを使っています: 「#astahkansai RDRA はUMLを拡張してるので、astah などの普通のモデリングツールでは制約に引っかかって書きにくい時がある。plantuml なら自由に描けるので、RDRA の記法も問題ない。」 / Twitter

興味深い点は、PlantUMLのソースを見るだけで脳内にUMLモデルの絵がイメージできるし、逆に、UMLモデルの絵からPlantUMLソースをイメージできるようになる、ということ。
右脳と左脳で行ったり来たりしている点はすごいな、と思う。

akipiiさんはTwitterを使っています: 「Astahkansai 慣れてくると、plantuml のソースから、頭の中で絵をイメージできる一方で、UMLの絵からplantuml のソースが頭の中にイメージできる、と。なるほど、まさに右脳と左脳で行ったり来たりしてるわけだ」 / Twitter

講演では図書館モデルの事例紹介で、ユーザの要望をコンテキスト図で表す時に、アクターアイコンの吹き出しに要望を書くことで、あたかもユーザが声に出して要望を話しているように見える、という箇所は非常に興味深かった。また、VSCodeでPlantUMLをライブコーディングしながらUMLを書いていく説明も分かりやすかった。PlantUMLは奥が深そうなので、色々試してみたい、と思う。

【2-2】とくぢろうさんの講演ユースケースリファクタリングでは、ファウラーのリファクタリング本を元に、ユースケースのリファクタリングのカタログを作ってみよう、という話で、面白かった。

ユースケースの削除、抽象化、分割、共通化、などは、ソースのリファクタリングの手法と全く同じように考えられるので、理解しやすい。実際の場面でユースケースを使う利用シーンは少ないけれど、その考え方は要件定義に活かせると思う。

但し、リファクタリングはTDDと表裏一体なのに、ユースケースのリファクタリングはTDDがないので、その部分の弱みはある。他にも課題はあったが、思考は深められそう。

akipiiさんはTwitterを使っています: 「#astahkansai Cソースの依存関係をastah のユースケースで描くと、ユースケースの依存関係の機能を使えるので便利」 / Twitter

【2-3】高井さんの講演では、GSNを使って、組込みシステムのタスク実装の意図を残す事例。僕は、GSNはロジカルな手法なので、厳密に説明するもの、と思っていたが、事例紹介の話を聞くと、説明する人の立場で論理を組み立てるので、意外に緩やかに使える印象を持った。

僕は、GSNやフォルトツリー解析、STAMPなどの手法はどのような違いがあり、どのように使い分けられるのか、が分かっていないので、この辺りも考えてみたいと思う。

【2-4】細合さんの講演では、テストケースの組合せ爆発を、フィーチャーモデルを使って制約条件を表現し、astahを基盤とした開発ツールでテストケース生成を行った話。フィーチャーモデルはソフトウェアプロダクトラインにも出てくるが、実際の記法を見ていたら、原因結果グラフに似ているような印象を受けた。だとすれば、組合せたテストケースの精度は非常に高いだろうと推測する。

【3】2時間の勉強会にたくさんの講演を押し込んでしまったので、質疑応答の時間が取れなかったのは反省点だけど、熱心に聞き取る参加者を見て、開催できてよかった、と思った。とても小さなコミュニティだけど、今後も緩く長く続けられればいいな、と思っている。

| | コメント (0)

2019/09/21

第3回astah関西勉強会の見所「もやもやを分解しよう」 #astahkansai

第3回astah関西を1年ぶりに開催します。
興味のある方は、ふるってご参加ください。

【参考】
第3回astah関西勉強会「もやもやを分解しよう」 - connpass

(引用開始)
要件定義やシステム開発で袋小路に陥った時、何か「もやもや」していることはありませんか?
そこで、そんな「もやもや」をモデルに書き出して、どんどん分解して、もやもやの真因を突き止めていきましょう。

そんな時に役立つモデリング手法の実践事例を講演者から紹介して頂きます。 具体的には、下記になります。

・モデルベースの要件定義手法(RDRA)とPlantUMLを使った実践モデリング
・ユースケースのリファクタリング・テクニック
・設計やプロジェクトのゴールに関するモデリング技術:ゴール指向表現(GSN)
・フィーチャー図によるテストスィートのモデリング技術
(引用終了)

一番の見所は、@ogomrさんの「PlantUML Example for RDRA 2.0」 。
PlantUMLで要件定義や設計の作業をどれだけ書ききれるのか、に興味がある。

@ogomrさんの下記の記事はとても参考になる。
PlantUML Example for モデルベース要件定義テクニック - Qiita

UMLで全ての設計ができるわけではないだろうが、UMLを一部カスタマイズして、業務システムの要件定義やシステム設計に合わせるようなモデリング技法(RDRA)を組み合わせると、ほとんどの内容をモデルとして描くことができる。
さらに、PlantUMLでテキストベースにUMLモデルを書けば、設計モデルもソースも全てGitの構成管理の配下で管理させることができる。
そうすれば、自動デプロイすることで、最新の設計書とビルドモジュールがいつでもリリースできる流れになる。

このあたりのアイデアは以前色々考えていた。

PlantUML Example for モデルベース要件定義テクニックの記事のリンク: プログラマの思索

仕様書にもExcel脱却が求められている: プログラマの思索

PlantUMLを使ってExcel設計書をテキスト化するアイデア: プログラマの思索

PlantUMLが優秀な点は、UMLだけでなくER図も書けるし、画面インターフェイスの部品を使って画面設計書も書けたり、マインドマップやガントチャートまで対応している点だ。
つまり、設計資料以外にも、PJ管理資料まで全てテキストで管理できる可能性がある。

また、VSCodeを使えばPlantUMLを簡単にプレビューできるので、開発環境も揃っているのも良い。
もしかしたら、astahでモデルを描くよりも、VSCodeの方が馴染む人もいるかもしれない。

設計者が自分の意図を開発者に伝えたい時、シーケンス図を書くときが多いだろうが、その時に、PlantUMLで書いたシーケンス図を渡す利用シーンも考えられる。

特に、シーケンス図の修正はPlantUMLでテキストベースで書いている方が、仕様変更の対応にも強い。

そんなことを考えると、設計というモデリング技法は、モデリングツールの開発という観点も含めて、まだまだ発展途上の技術のような気がしている。
そういう内容も合わせて、色々議論できると楽しいと思っている。

| | コメント (0)

2019/06/16

業務系エンジニアが生き抜くのは難しい時代になった

業務系エンジニアが生き抜くのは難しい時代になったという記事をリンク。
以下、脈絡のないポエム。

【参考】
業務系エンジニアはどうしていくべきか? - 急がば回れ、選ぶなら近道

【1】日本のSIなら、プログラマからマネージャになるにつれて、実装技術から離れてしまい、どんどん技術から離れていく。
すると、一番怖いのは、技術の目利きが落ちることだと思う。
最新技術のメリット、デメリットをいち早く見抜き、どの場面で適用すると上手くいくのか、逆に失敗するのか、という目利きができなくなると、正直怖くなる。

結局、技術の全部を抑えておかないと難しい。

【2】「最終的にはシステムはIOに行き着く」という指摘は秀逸。
アプリ、ミドルウェア、インフラなどの層別アーキテクチャ(N-Tier)はいつの時代も基本。
最近は、インフラが熱い。
インフラを押さえれば、最近の技術の動向はいち早く把握できる。

【3】イノベーションを常に強いられる業界は、そこで働く人にとっては苦痛に思える人も多いだろう、と思ったりもする。

実際、若かった人も年を取ればどうしても、過去の経験値に縛られたり、集中力や瞬発力が落ちるので、新しい文化を取り入れるのが難しくなる。
広岡達朗の著書の中で「人間は常に保守的な存在だ」という文言を以前読んだことがあったが、たぶんその言葉は真実なのだろう。
人間は、従来成功したやり方を明日からいきなり変える、ということに抵抗感があるのだろう。

経験値がゼロで、獲得した資産や家族がなければ何も怖くはない。
しかし、長年蓄積してきた資産、経験、家族が増えてくれば、それを全て捨て去り、一から作り出すのは心理的に難しくなる。
一方、イノベーションのジレンマでは、過去の資産を活用できるプロセス・イノベーションを前提にしていない。
むしろ、イノベーションを阻害するような過去の経験は無い方が、イノベーションを生み出しやすい。

イノベーションを常に強いられるIT業界は、脱落するエンジニアが多く、経験豊富な人よりも若者の方が有利、という特徴が出てくるのだろう、と思う。
そして、「IT業界はイノベーションが激しい」ということと「IT技術は後方優位性が強い」ということは同じ意味なのだろうと思う。


| | コメント (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/04/07

「プログラミングのできる羊とできない山羊を区別する方法」の記事のリンク

「プログラミングのできる羊とできない山羊を区別する方法」の記事をリンクしておく。
プログラミングの向き不向きに関する興味深い記事。

【参考】
プログラミングできる人とできない人との間の深い溝 - masatoi’s blog

(引用開始)
実に多くの人がリンクしているこの論文(PDF)では、プログラムやプログラミング言語に触ったことがない学生達を対象に、「プログラミングのできる羊とできない山羊を区別する方法」を提案している。
おしなべてプログラミングの教師はプログラミングができる学生とできない学生の二つの山ができることに気付いている。それぞれの山は独立な正規分布を成している。プログラミング教育に関する研究のほとんどすべてが教授法についてのものである。すなわち、言語を変え、応用分野を変え、IDEの利用法や仕事へのモチベーションの維持について教えるわけだ。しかしそれらの試みはなかなか上手くいかず、二つの山は依然として残り続けている。
(中略)

この論文の著者は計算機科学における最初のハードルは以下のようなものになると仮定している。
代入と系列
再帰 / 繰り返し
同時並列性

上から順にハードルは高くなっていく。従ってテストは新米プログラマに対する最初のハードルである代入から始めていく。このテストの結果は3つのグループに綺麗に分かれる。
学生の44%は代入がどのように働くかについて一貫したモデルを持つに至る(たとえ正しくなくとも)
39%の学生は代入のモデルとして一貫したものを形成できない。
8%の学生はふてくされて回答を空白のままにする。

このテストは2回実施された。最初の一回目を何の説明もなしに行い、3週間後にもう一度行った。印象的なことは、一回目と二回目では実質的にグループの変化がほとんど無かったことである。つまり、一回目のテストであなたが心の中に一貫したモデルを得られるかどうかが最初のハードルになっている。
著者はプログラミングができることと一貫したモデルを心に持てるかどうかの間には極めて高い相関があることに気付いた。
(引用終了)

つまり、プログラミング教育の講座では、プログラミングにすぐに慣れる人と、プログラミングがずっと分からない人から成る正規分布の2つの山に分かれる現象らしい。
確かにそうかもしれない。

個人的に興味があるのは、小学生からプログラミング教育が義務化された状況において、プログラミングを知らない子供がどうやってプログラミングのスキルを習得していくのか、を観察してみることだ。
子供が母国語を自然に覚えるように、プログラミング言語を自然に習得できるのか?

それとも、40代を過ぎたおじさんがTOIEC対策のために英語習得に非常に苦労している風景と同じく、プログラミング初心者も、通常の論理体系とは異なるプログラミング言語を習得することに、非常に苦労するものなのか?

上記の記事を理解した後で振り返ると、数学の公理体系と同じく、それ自体は無意味な論理規則の集合体であるプログラミング言語をどうやって操れるようになるのか、その習得過程に興味がある。
それが分かれば、ソフトウェア開発の難しさという本質に触れられるような気がするから。

| | コメント (1)

2019/03/10

第19回Redmine大阪の感想 #redmineosaka

昨日の第19回Redmine大阪が無事に終了した。
スタッフの皆さん、参加者、そしてJiraやBacklogのパネラーの方、ありがとうございました。
感想をラフなメモ書き。
Mroongaはまだ分かっていないので、間違っていたら後で直す。

【参考】
第19回 Redmine大阪 - connpass

第19回 Redmine大阪(2019/3/9) #redmineosaka - Togetter

第19回Redmine大阪の見所 #redmineosaka: プログラマの思索

redmineエバンジェリストの会 メンバー4人がRedmine大阪へ

続・姫路IT系勉強会で

Node.js meets Redmine (第19回 Redmine大阪 LT発表内容)|足羽川永都(あすわがわえいと)|note

【1】今回の勉強会では、参加者層が多様だったので、大変盛り上がったように思う。
大阪圏の参加者だけでなく、東京・名古屋・福井・京都・神戸・姫路・松江・福岡などの遠方から多数の参加者があった。
また、Jiraのエバンジェリストの方も来て頂いて、チケット管理ツールに関する有用な議論もできた。

直前のキャンセルがあったにも関わらず、補欠の参加者が全員参加されて、参加率100%超になったのはすごいな、と思う。
それだけRedmineのニーズが広がっているのかな?

【2】@akahane92さんの講演では、特に全文検索プラグインの仕様と性能評価が興味を惹いた。

Redmineチューニングの実際と限界 - Redmine performance tuning - Speaker Deck

clear-code/redmine_full_text_search: Full text search for Redmine

@akahane92さんの会社では、クリアコードさんと共同開発して、GitHubに公開されている全文検索プラグインに対し、RedmineのチケットやWikiなどの全文検索を更に強化した機能も含めて公開されている。
今後は、添付ファイルやSVNなどのリポジトリ情報も全文検索の対象としてプラグインの機能に含めていく、という。

【2-1】この講演内容を聞いて重要と考えた事は2つある。
一つは、メーカーという知的財産に非常にセンシティブな企業であっても、オープンソースの方が価値がある、という考え方に同意してくれていること。

もう一つは、Redmineに蓄積されたチケットやWikiだけでなく、添付ファイルや構成管理ツールのリポジトリ情報もテキスト情報として全文検索の対象に含めること。

Redmine本家では、添付ファイルの全文検索も機能追加するチケット(Planio提供 #306)があるが、@g_maedaさんや@akahane92さんに聞いた所、Redmineの検索機能が更に劣化する可能性があること、パッチの規模が大きすぎることから入らないのではないか、とのことだった。
しかし、全文検索プラグインでその機能が実現されるならば、問題はない。

Redmineチューニングの実際と限界 - Redmine performance tuning - Speaker Deck

つまり、全文検索プラグインによって、Redmineに蓄積されたチケット・Wiki・添付ファイル・リポジトリは全て検索対象となり、Redmineを真のナレッジ基盤として実現できるわけだ。

(引用開始)
Redmineのファイル内容 全文検索
添付ファイルの内容検索がパッチとして提供されている(Planio提供 #306)が、 大量の添付ファイルを検索対象とした場合、全文検索の性能は低いと予想される。
想定される課題は3点:

1)検索処理時間
実運用環境の35万ファイルを使用して、全文検索(非索引型)の応答性能を計測すると、10億文字分の検索処理が長時間かかってしまい、日常的に使うには性能が不足するだろう。将来のデータ増加を最大200億文字と想定すると、このままでは厳しい。
→ Full Text Searchプラグインによる、検索機能の拡張開発「添付ファイルの索引型高速全文検索」により改善できる(もうすぐ)
2)検索結果の精度
SQL検索では探している情報が大量のデータに埋もれてしまうため、見つけるまでに時間がかかってしまう。
→ Full Text Searchプラグインによる、 検索機能の拡張開発「高精度検索」により改善できる(予定)
3)リポジトリ内容の検索機能が無いため、ソースコード検索、ドキュメント検索ができず、効率が悪い。
→ Full Text Searchプラグインによる、検索機能の拡張開発「リポジトリ内容の索引型高速全文検索」により改善できる(予定)
(引用終了)

【2-2】@akahane92さんに聞いた所、Redmineの全文検索プラグインでは、プロジェクト単位に全文検索できる仕様が重要である、という点が興味を惹いた。

なぜなら、プロジェクトは新製品開発など、情報アクセスに厳しい制約があるため、Redmineユーザは所属しないプロジェクトにアクセスできない仕様が必要だからだ。
おそらく、ISOやISMSの制約上、重要な機密情報は限定されたユーザだけがアクセスできるような仕組みが必要なのだろう。
Redmine本体の検索機能には、既に検索時の絞り込み条件が設定されているので、問題ないわけだ。

【2-3】全文検索プラグインの実装仕様、特に機械学習によるAI検索について、@akahane92さん、@ryouma_nagareさんの説明を聞いて、ようやく概要を理解できた。

チケット登録時に、チケットの情報とともに、Mroongaが検索用インデックスを保持する。
Redmineで全文検索を行う時、その検索用インデックスを使うので検索時間はかからない。

また、Mroongaが保持する検索アルゴリズムは、定期的にメンテナンスする。
例えば、Redmineの外で、GPUを使った特別のサーバーを用意して、AIエンジンで別途、機械学習させて、その学習結果をMroongaに週1回または月1回のように定期的に取り込む。
したがって、Mroongaの検索アルゴリズムは定期的にアップデートして、Redmineの検索精度を高めるように運用すればよい。

僕はMroongaを機械学習エンジンと勘違いしていたが、そうではなく、全文検索用の語彙表テーブルとインデックスカラムを自動生成してくれるミドルウェアだと理解した。

他に、お話を聞くと、MroongaはRedmineのver3.4, 4.0にも対応済みらしい。
そしてOSS化されている事から、MroongaはRedmineの最新版に追随してくれることが期待できる。

【3】アジャイルウェアの堂端さんのGitHub連携プラグインのデモも興味深かった。

仕掛けとしては、RedmineでGitHubの接続情報を設定しておくと、Redmineサーバー上にGitHubのBareリポジトリが作られて、そのリポジトリをRedmineが参照すること。

agileware-jp/redmine_github

【4】JiraとBacklogパネラーを含めたパネルディスカッションも面白かった。

BacklogやJiraが向いていない利用シーンは、大規模なWF型開発の案件です、という発言を聞いて、Redmineのチケットやプロジェクトの階層無制限の機能がそこに有効に作用している、という点を改めて認識した。
つまり、日本の企業でRedmineが好まれているのは、従来のWF型開発にとてもフィットしているツールとして使われているからだろう。

【5】今回の勉強会を一スタッフかつ一参加者の立場で楽しんだ後、Redmineコミュニティは今後どのように進んでいくのだろうか、と思った。
懇親会でも、最近の東京Redmine勉強会は盛り上がっているが、Redmine大阪はどうなんですか、という質問もあった。

僕は、JiraとBacklogのパネルディスカッションを聞きながら、2011年当時のチケット管理ツール大決戦のイベントを思い出していた。
2011年のRedmine勉強会発足当時、大阪や東京のRedmineコミュニティではアジャイル開発者が率先して試行錯誤していた。
たとえば、以前は、@daipresentsさん、岡本さん、小久保さんなど数多くのアジャイル実践者は、Redmineでいかにアジャイル開発を運用するか、を試されていた。
その過程で、Scrumのプラグインを作られたり、Gitと連携するプラグインを作られていた。

しかし、その後、Redmineのユーザ層が変化したように思う。
実際、最近のRedmine勉強会のユーザは、PMOやSEPG、情報システム部門のユーザが多い。
また、Redmineを全社で展開しているので、Ruby開発者よりもインフラ関係のエンジニアが多いように思う。

つまり、Redmineのユーザ層は、アジャイル開発者ではなく、日本のソフトウェア開発や現場の業務に合うように実運用する立場の人達に変化した。
そんな流れを振り返ると、日本のユーザはRedmineが自分たちのニーズに向いていることに気づき、多種多様な現場に片っ端から適用してみることで、Redmineをより深く理解しようとしているのではないか、と思った。
今回の勉強会では、そんな気づきがあった。

| | コメント (0)

2019/01/26

第19回Redmine大阪の見所 #redmineosaka

第19回Redmine大阪の見所を書いておく。

【参考】
第19回 Redmine大阪 - connpass

(引用開始)
テーマ~「次世代プロジェクト管理システム Redmine の未来を考える」
約1年ぶりに、待望のRedmine のメジャーバージョン4.0がリリースされました。
今回の勉強会では、さらに機能改善されたRedmineの解説だけでなく、下記の内容を提供します。

最新バージョンのRedmineでのチューニング結果報告
国内で代表的なプロジェクト管理ツール Redmine・JIRA・Backlog の有識者を招いて、プロジェクト管理ツールについてディスカッション

Redmineの初心者から、Redmineをバリバリ使う経験者まで、興味のある方はぜひお越しください。
(引用終了)

1年ぶりの勉強会の見所は、次の3つがある。

【1】@akahane92さんの「Redmineチューニングの実際と限界 ~ 200万チケットでもサクサクなRedmineの作り方~ 改訂4版」

Redmineチューニングに関しては、世界トップクラスの@akahane92さんが最新バージョン4.0の性能評価、チューニング技術に関して報告して頂く。
特に興味深い点は、全文検索プラグインを使った性能評価だ。

Redmineの全文検索プラグインが、Redmineにとってとても重要な理由は、Redmineをナレッジシステムとして実現する為に重要な機能であるからだ。
その理由は下記に書いた。

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

Redmineの全文検索プラグインには、Redmineに蓄積された過去のチケット、Wikiなどの情報を高速に検索できるだけでなく、GoogleのPageRankのように重要度の高い順にソートしたり、Amazonのお勧め商品のように類似チケットを表示する機能などがある。
この機能がRedmineに組み込まれれば、システム保守や顧客問合せなどのデータをRedmineに蓄積するほど、Redmineにその会社のナレッジが蓄積されていくので、Redmineは有用なナレッジシステムになる。
さらに、昨今の機械学習や人工知能のライブラリをアドオンで組み込むなどすれば、より的確な情報を提供するだけでなくアドバイスすることも可能になるだろう。

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

第17回Redmine大阪の感想 #redmineosaka: プログラマの思索

@akahane92さんの講演内容は今後、詳細が明らかになっていくと思うが、既にRedmineをIT全般統制(ITSMS)に適用して実運用されている背景を考えると、Redmineの全文検索プラグインがIT全般統制の内部監査で重要な役割を担っているのではないか、と推測される。

すると、ISO9001やITSMSのマネジメントシステムにRedmineをうまく当てはめる事が出来れば、Redmineの導入対象は、ソフトウェア企業だけでなく、製造業などの会社にも導入できることになり、Redmineの活用範囲が広がるだろう。
実際、既にITILとRedmineは相性が良いのは知られているので、ISO規格にあるマネジメントシステムとのフィットギャップ分析さえできればいい。
その辺りも色々聞いてみたい所。

SQIP2014の論文「「効率、品質、統制」の共通課題に着目した現場主導によるITS導入の効果検証」がすごい #redmine: プログラマの思索

Redmineの理想と現実~RxTStudy #12 「ITS活用最前線~現場からの実践報告」の感想: プログラマの思索

日本の大企業におけるRedmineの利用事例の資料のリンク: プログラマの思索

そうなると、今後の課題は、Redmineの添付ファイルも全文検索プラグインの対象に入れて、Redmineを真のナレッジシステムにすることになるだろう。
なぜなら、RedmineのチケットやWikiだけでなく、チケットに添付されたExcelファイルまで全文検索の対象になれば、より重要な情報を的確にいつでも高速に抽出できるからだ。
そうすれば、Redmineにどんどん情報を蓄積していこう、というユーザの動機付けにも役立つだろう。

Ver4.1で、添付ファイルを全文検索する機能が提案されているので、今後の動向も要チェックだ。

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

【2】アジャイルウェア 堂端さんの「GitHub連携プラグイン」

Redmineの課題の一つには、Git連携がやりにくい、という点が10年前からあった。
現状の機能では、Bareリポジトリを手動で作ったり、Gitlabと連携できるように構築するなど、手間がかかる場合が多い。

今回の講演では、GitHub連携プラグインを提供されるということ。
このプラグインは、Redmineユーザにとってメリットが大きいと思う。

GitHub連携プラグインのメリットは2つある。
一つは、GitHubとRedmineと連携できることで、チケット管理はRedmine、プルリクやフォークなどのソース修正はGitHubという使い分けが簡単に実現できること。
以前から、RedmineとGitlabの連携は試みがされてきたが、GitHubでも使い分けが可能になる。

もう一つは、GitHubが無料のプライベートリポジトリを使用可能にしてくれたおかげで、個人のソース管理やドキュメント管理はGitHub、プライベートなタスク管理はRedmine、で置き換えられること。

GitHub、無料ユーザーもプライベートリポジトリを使い放題に - ITmedia NEWS

GitHubが無料でプライベートリポジトリも使えることで小説家にもGitが必須になってきたのではないか: プログラマの思索

マイクロソフトがGitHubを買収した後、GitHubが非常に使いやすくなったので、GitHub連携プラグインはとてもタイムリーな内容だと思う。

【3】「プロジェクト管理ツール Redmine・JIRA・Backlog によるうちの子の良い所、他の子の欲しい所」

現在調整中だが、Redmine、Jira、Backlogという著名なプロジェクト管理ツールのエバンジェリストをお呼びして、それぞれのツールの良い所を紹介してもらい、自由に議論してもらおう、という企画。
企画の隠れた目的には、そういう議論の内容をRedmineの機能改善に役立てたい、という気持ちも込められている。
個人的には、とても楽しみな内容。

なお、このパネルディスカッションの企画を手伝っている時に、過去の「チケット管理ツール大決戦」の企画を思い出していた。
2011年のデブサミで、チケット管理ツール大決戦という企画が非常に盛り上がって、その企画がユーザ投票で3位にランクインされたのを思い出す。

チケット管理システム大決戦第二弾 Trac vs Redmine vs JIRA vs Backlog を開催しました!勝者は? - I18n and L10n in My Life

デブサミ2011レポート~チケット管理システム大決戦: プログラマの思索

[#TiDD]チケット管理システム大決戦 JIRA vs Redmine vs Trac - デブサミ2011 その3 - #itsjp #devsumi: ソフトウェアさかば

2/17: デブサミ 2011 / チケット管理システム大決戦

チケット管理システム使用状況の調査結果(デブサミ) | Atlassian Blogs

【資料公開】チケット管理システム大決戦 第二弾 | Ryuzee.com

Excel大好きな日本企業の組織文化は、たぶんその頃から変わっていないように思う。
だから、それぞれの製品のメリットを強調するだけでなく、世の中の業務の問題解決にプロジェクト管理ツールが役立てればいいなあ、と思っている。

【4】既に満員御礼になっていますが、懇親会は人数を増やせるので、懇親会からの参加もOKです。

| | コメント (0)

2018/11/11

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

第15回東京Redmine勉強会が盛況で無事に終わりました。
スタッフ、参加者の皆さん、ありがとうございました。
また、コミッタの前田さん、数多くのプラグイン開発者・パッチ開発者の方にも感謝です。
以下は、講演を聞いて、感想をラフなメモ書き。

【参考】
第15回勉強会 - redmine.tokyo

2018/11/11 第15回勉強会 - redmine.tokyo - Togetter

日本のRedmineコミュニティの活動報告と今後の抱負: プログラマの思索

第15回redmine.tokyo勉強会の見所: プログラマの思索

第15回redmine.tokyo勉強会のLT資料の事前公開~今後のRedmineコミュニティの方向性について: プログラマの思索

Redmineでやってみた - うさぎまんじゅう - BOOTH

【1】参加者の方から、以前の勉強会では講演の数が少なくて、時間を持て余す時が多かったのに、今回の勉強会では講演の数が多すぎて盛りだくさんだった、という感想を聞いた。
確かに、大LT大会になったので、詰め込みすぎたかもしれない。

他方、それだけのコンテンツが集まる事実は、日本のRedmineコミュニティで数多くの事例やカスタマイズのノウハウが蓄積されていることを示しており、コミュニティとして成熟していることかな、と思った。

【2】今回の勉強会のテーマは「Redmineの次バージョン4.0に向けて、皆のノウハウを共有しよう」だったが、隠れたテーマは「日本のプラグイン開発者やコミッタ、パッチ貢献者にコミュニティから感謝の声をあげよう」だったと思う。
@g_maedaさん、@akiko_pusuさん、@tkusukawaさん、@haru_iidaさん、@two_packさん、@onozatyさん、@naitohさん、前田みのるさん他多数のプラグイン開発者に声が届けられて良かったように思う。

中村さんの講演では、現場のRedmineに15個もプラグインを入れていて、プラグイン開発者に拍手喝采を、という内容はまさにそうだった。
Discord上でRedmineコミュニティを運営しているMaxさんの講演も、Redmineのテーマ改善など機能拡張をコミュニティドリブンで開発しよう、という内容だった。

そして、僕のLTでは、Redmineコミュニティがマネージャ層とRuby開発者という二つの全く異質なターゲットから成り立っている特徴を強みとみなし、異質な特徴を持つ彼らが相互交流することで、Redmineの進化を加速させるエンジンになりうるはず、という主張を試みた。

実際、今日の参加者とグループディスカッションや懇親会で話を聞くと、マネージャ層の人達もいれば、プラグインやパッチ等の開発者も多く、多様な参加者から成り立っていた。
たぶん、こういう交差しないセグメントのターゲットが2つ以上もあるようなコミュニティは、非常に稀で、貴重な場ではないか、と思う。

普通のOSSコミュニティは、利用ユーザだけとか、実際の開発コミュニティとか、セグメントがどこかに特定されているような気がする。

【3】では、なぜ、Redmineコミュニティはそのような異質なセグメントのターゲットを2つ以上持つことができたのか?

理由は、Redmineには2つの顔があるからだ。
一つは、「ソフトウェア工学の理論を実験できるプロジェクト管理ツール」という側面で、マネージャ層に対応する。
もう一つは、「汎用的なプロジェクト管理の開発基盤」という側面で、こちらがプラグイン開発者やRuby開発者に相当する。
つまり、全く異なる出身を持つ二つの層が生まれたことで、Redmineの機能改善を相互に議論しあえる場が生まれたように思っている。

たとえば、マネージャ層は、自分達の管理作業を楽にしたいためにRedmineを使うが、Rubyの開発はおそらく殆どの人ができない。
一方、プラグイン開発者は、実際の現場のニーズを元にRedmineに不足した機能を実装し、プロセス改善に役立てる。

Ruby開発者は、マネージャを顧客に見立てて、Redmineに不足した機能を実現できる力を持つ。
一方、マネージャは、プラグインを利用することで、自分達の開発プロセスや組織文化に合わせてRedmineにカスタマイズを施し、彼らのあるべき姿にRedmineをFitさせる。
たぶん、新たなプラグインがマネージャ層の潜在ニーズを刺激し、新たな改善アイデアを生み出すだろう。

実際、今日のLTでもリソース予約プラグインを開発した話があり、タスク管理に使われるRedmineを会議予約システムとみなして使う、という事例もあった。
つまり、柔軟なRedmineのおかげで、マネージャや利用ユーザの潜在ニーズが刺激され、数多くのアイデアが生まれる、という良い意味でのらせん構造が生まれている。

【4】すると、今後のRedmineコミュニティの発展に必要な要素は2つあると思う。
一つは、Ruby開発者をRedmineコミュニティにもっと巻き込みたい、ということ。

なぜなら、他の競合のチケット管理ツールに対し、Redmineが競争優位性を保つには、もっとRedmineの進化の速度を上げたいからだ。
現状のRedmineには、いくつかの課題があると思う。

僕が感じている課題については、以前書いた。

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

また、Maxさんも同じく、Redmineの画面UIをもっと今風に改善したい、と思われている。

換言すれば、次の3つに課題が集約されるのではないか。

1・シングルページアプリケーション化などの画面UIの改善
2・プルリク実装などのGit連携の機能強化
3・プラグインのGem化、RedmineのVerUpの自動化などの、VerUp自動更新機能

おそらくそれらの課題の解決は、そう簡単なものではない。
だが、多くのRuby開発者をRedmineコミュニティに巻き込めば、実現のハードルは下がるだろう、と思う。

Redmineのマイクロコア化は可能か~Redmineを開発基盤にして追加機能は着脱可能コンポーネントにできるか: プログラマの思索

【5】もう一つは、Redmine運用に関する数多くの知見を一つの体系にまとめ上げて、誰もが再利用できるようなプラクティスや知識を提供すること。

なぜなら、大阪や東京のRedmine勉強会で参加者から要望されるニーズは、Redmineの運用事例が知りたい、という内容が多いからだ。

実際、Redmineが生まれて10年以上経った今、障害管理だけでなく、タスク管理、会議の管理、資産管理、ヘルプデスクなど数多くの事例がRedmineで実現されている。

たとえば、今日のグループディスカッションでは、ITILのプロセスをRedmineで完全に実装した事例を持つ参加者がいた。
具体的には、Zabbixで検知したエラーメールはRedmineにチケットで自動登録され、インシデントとして認識される。それらチケットを精査して、修正対応すべきと判断されたチケットは、問題管理へエスカレーションされ、対応策の検討後、リリース管理で開発・リリースされる、という流れ。
つまり、この参加者の方は、システム保守・運用の立場の人なのだろう。

この話は僕も以前経験していて、ITILとRedmineは非常に相性が良いと思っている。
しかし、インシデント管理・問題管理・リリース管理などの各プロセスをRedmineにどのようにFitさせるか、については、運用してみると理論通りにうまく行かない部分がある、というのも経験している。

TiDDにITILの概念を持ち込む: プログラマの思索

Redmine for ITIL: プログラマの思索

残業申請ワークフローやITIL運用プロセスをRedmineで実現した事例の記事: プログラマの思索

エスカレーションをRedmineで運用する方法: プログラマの思索

そういうアンチパターンやプラクティスなどのノウハウを、利用シーンごとにまとめて、体系化してみたい。
おそらく、そういう知見を集めて体系化して、その知識を普及させる役割が、Redmineエバンジェリストであり、Redmine警察に相当する人達だろうと思う。

【6】今日の勉強会の中で、ツイートしながら生み出せた考え方は、「Redmine運用の4原則」のようなものがあるのではないか、ということ。
Redmine運用の4原則とは、Redmineがチームに馴染むには、プロセス・ツール・スキル・マインドの4つの要素がいるのではないか、ということ。

この考え方の発端は、Jiraのような多機能なチケット管理ツールの場合、プロセスを実装した経験がない管理者がJiraを使って運用させようとすると、失敗しやすいのでは、という話から生まれた。

ツールを使いこなすには、プロセスを知っておくことが大前提。
そして、ツールを使いこなしたり、プロセスをテーラリングできるスキルも重要。
また、プロセスやツールを受け入れるマインドもいるね、と話が広がった。

しかし、本当にこの4つで十分なのか、MECEに整合性が取れているのか、この4原則でアンチパターンの事象を演繹的に説明できるか、については検証が必要、と思っている。
でも、この4原則を検証してみるのは価値がある、と思う。

【7】最近の僕が個人的に持っているRedmineのテーマは「組織とRedmineは相互にどんな影響を与えているか」だ。

具体的には、組織構造がRedmineにどんな影響を与えて、Redmineをどんな方向に複雑化させるのか。
一方、Redmineを導入し運用することで、組織文化にどんな影響を与えて、組織にどんなメリットを与えてくれるのか。

例えば、縦割りのガチガチの組織構造は、単一の標準Redmineのワークフロー設定、トラッカー設定を複雑化させる。
その複雑化に現場が対応できなくなると、各事業部や各チームごとにRedmineインスタンスが乱立し、野良Redmineが生まれ、IT統制が効かない状態になりうる。
つまり、組織のやり方にRedmineをカスタマイズしてフィットさせて、プロセスをテーラリングしたいが、実際は理論通りにテーラリングはうまくいかない場合が多い。

一方、縦割りの組織にRedmineを導入すると、Redmineの機能に埋め込まれたベストプラクティスをメンバーが自然に受け入れることで、チームの作業が効率化されることもあるだろう。
また、Redmineがメンバー間のコミュニケーションを活発化させ、より良いプロセス改善がもっとできるのでは、というメンバーの貢献意欲を引き出す場面もあるだろう。
つまり、Redmineはチームの文化を変容させる力を持っている。

そんな経験を踏まえて、「Redmineは組織構造に従う」「Redmineは新たな組織文化を生み出す」という二つの双方向な事象を整理したいと思っている。
実際、Redmineを利用しているマネージャは大企業の方が多いので、組織構造や組織文化とRedmineのバランスを見出すことに苦労しているのではないか、と思うからだ。

Redmineは戦略に従う。そして、Redmineは組織に従う~システム運用フローの背後にある組織構造の影: プログラマの思索

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響: プログラマの思索

Redmineに向いている組織はPJ型組織やマトリクス型組織ではないかという仮説: プログラマの思索

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

グループディスカッションでも、懇親会でも、参加者が持つRedmine運用の問題意識にはこれらが関係しているような気がした。

以前「Redmineによるタスクマネジメント実践技法」で当時の自分が考えていたアイデアは全て書いたけれど、上記のテーマでまた新たに書いてきたくなるなあ、と思った。




| | コメント (0)

2018/11/09

第15回redmine.tokyo勉強会のLT資料の事前公開~今後のRedmineコミュニティの方向性について

第15回redmine.tokyo勉強会のLT資料を事前公開しておく。

【参考】
日本のRedmineコミュニティの活動報告と今後の抱負: プログラマの思索

第15回redmine.tokyo勉強会の見所: プログラマの思索

第15回勉強会 - redmine.tokyo

【1】Redmineには2つの顔がある。

一つは、ソフトウェア工学の理論を実験できるメトリクス収集集計基盤/開発プロセスの運用基盤である顔。
Agile開発もWF型開発も運用可能であり、ワークフロー設定できるならば、全ての開発プロセスをRedmineで一元管理できる。
そこから、Redmineは開発プロセスの運用基盤になり、ソフトウェア工学やプロジェクト管理に関するメトリクス収集・集計基盤になりうる。
つまり、定量的なプロジェクト管理の手段をRedmineによってようやく手に入れられることになる。

もう一つは、汎用的なプロジェクト管理ツールの開発基盤である顔。
RubyとRailsの基盤のおかげで、機能のカスタマイズがやりやすい。
REST APIやrakeなどの外部接続I/Fもあるので、システム連携もやりやすい。

そのおかげで、Redmineに不足する機能をプラグインで実現できるので、プラグイン開発者が多い。
特に日本では、ガチガチの縦割りの組織や自社の開発プロセスに合うように、Redmineをカスタマイズしやすいので、ニーズが多い。

また、Redmineが柔軟な開発基盤を持つおかげで、Redmineコミュニティ自体が活発化している事象もある。
柔軟なソフトウェア設計は、OSSコミュニティを活発化させるメリットがある。
他方、OSSコミュニティの活発化は、ソフトウェアをさらに進化させる、という双方向のメリットがある。
その考察は以下に書いた。

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

【2】言いたいことは2つ。

Redmineコミュニティの参加者の多様化を図ること。
もう一つは、Redmineのエコシステムを作ること。

Redmineコミュニティの参加者層は2種類あると思う。
一つは、プロジェクトマネージャなどのマネージャ層。
もう一つは、プラグイン開発者などのRuby開発者層。

つまり、プロジェクトマネージャかつRuby開発者である層は非常に少ないだろうから、コミュニティで相互の交流を図ることで、斬新なアイデアが出てきて、Redmineを更に進化させる余地がたくさんあるだろう。

マネージャのニーズはRuby開発者にとって、新たなプログラミング体験のチャンス。
Ruby開発者が提供するRedmineの新機能やプラグインは、マネージャのニーズをさらに刺激して、より良いものへ発展させるだろう。

その場合、Redmineベンダーも実はコミュニティのステークホルダーの一人なのだ。
彼らも有償ツールではあるが、Redmineのマーケット拡大に寄与している部分がある。
最終的には、彼らも含めて、Redmineコミュニティが熱気を維持し続ける方向へ持っていきたい。

そういう活発な議論を提供する場をコミュニティで実現したいと思う。

| | コメント (0)

より以前の記事一覧