Redmine Advent Calendar 2019のリンク
今年もRedmine Advent Calendar が作られたのでリンクしておく。
@ryouma_nagareさん、ありがとうございます。
【参考】
Redmine Advent Calendar 2019 - Adventar
Redmine Advent Calendar 2018 - Adventar
Redmine Advent Calendar 2017 - Qiita
まだ空きがあるので、書きたい人は是非。
2019年11月
2019/11/24
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本家を大切にしながら開発されるだろうと思っている。
2019/11/21
「英語が楽天を変えた」本の感想
「英語が楽天を変えた」本の感想をメモ。
結論のないポエム。
【参考】
「大学入試の英語テストはTOEFLに変更せよ」 楽天・三木谷社長が提言する「英語革命」（BLOGOS編集部）
最近、大学入試でTOEFLのようなグローバルなテストに変革しようとして、結局挫折した記事があった。
その背景には、どうやら楽天社長の意見もあったらしい。
そこで、「英語が楽天を変えた」本を読んでみた。
楽天は｢英語公用語化｣でどう変わったのか | 英語学習 | 東洋経済オンライン | 経済ニュースの新基準
「英語が楽天を変えた」本で興味を惹く点はいくつかある。
【1】１つ目は、英語公用化に対する反応集団が３つあり、それぞれ異なる特徴を持っていたこと。
その集団は、「日本で働き日本語を母語とする社員（言語的疎外者）」「欧米で働き英語を母語とする社員（文化的疎外者）」「アジア、アフリカなどで働く英語・日本語以外を母語とする社員（二重疎外者）」の3つ。
言語的疎外者、文化的疎外者の特徴は分かりやすいが、二重疎外者という集団も存在し、二重疎外者は積極的に英語を通じた日本文化や組織文化を素直に取り入れた、という話が面白かった。
彼らは、日本人よりも英語を習得しやすく、それによって仕事の幅が広がり、昇格のチャンスも増えるインセンティブが働いたためだろう。
【2】２つ目は、英語公用化は欧米化ではなく、日本の企業文化で統一されたこと。
文化的疎外者にとって、英語化によって、自分たちの欧米文化が日本の組織に取り込まれると期待していたが、実際はそうではなかった。
言語的疎外者が英語をマスターすることで、自分たちの日本の組織文化を世界中の支社に発信できたり、その意図を浸透させる手段を持ったことで、文化的疎外者に組織文化を押し付けることができるようになった。
楽天といえども、日本企業であるからには欧米企業とは異なり、日本企業らしい手続きの多い組織文化は多少はあったし、その文化の背景にある共通目的を社員に反映させやすくなったわけだ。
文化的疎外者にとってはありがた迷惑だったのかもしれない。
以前は、自分たちの職場では日本とは異なる欧米文化だったのに、たとえ米国の職場であっても、日本本社に統制されるようになったわけだ。
一方、言語的疎外者は自信を持って自分たちの組織文化を主張できる手段を持つインセンティブが生まれたわけだ。
【3】３つ目は、英語公用化というケース事例を統計学と組織行動学の観点で緻密に分析された手法が興味深いこと。
組織行動学では、組織内の集団は、環境に応じてどのような態度や行動を取るのか、という問題を前提として研究されていると思う。
では、その問題をどのように把握して、分析する手段があるのか？
その手法はアンケート収集とその統計処理にあるようだ。
おそらくランダム比較テストになるように、組織内の集団をセグメント別に分けて、アンケートを収集し、そこから集団の特徴を表すような変数を洗い出し、そこから仮説を導き出す。
その仮説が正しいか、新たなアンケートを集団の別のセグメントへ適用し、その反応をさらに分析していく、みたいなイメージかな、と想像した。
昨今では、コンピューティングパワーのおかげで、ABテストによるランダム比較実験がやりやすいし、膨大なデータがあっても即座に統計処理できる。
つまり、組織行動学や行動経済学のように、組織や集団の行動変数を抽出して新たな知見を見出す学問は、統計処理やコンピューティングパワーとすごく相性が良いのだろう、と思う。
そして、こういう学問の研究で得られたノウハウは、従来の古い考えをひっくり返すような、地動説のような特徴があるのだろう、と思う。
そう思うと、すごくワクワクする。
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ユーザなら必須ではなかろうか。
2019/11/09
Scrum@Scale入門のリンク
原田さんのScrum@Scale入門のリンクをメモ。
【参考】
スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門（前編）。Developers Summit 2019 － Publickey
スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門（後編）。Developers Summit 2019 － Publickey
Scrum@Scale Guide | Scrum at Scale Guide | Guide for Scaling Scrum
Scrum@Scale 入門 | Attractor Inc
大規模Scrumの話は最近良く聞くけれど、どのように拡張しているのか分かっていなかった。
上記の記事を読んで、何となくイメージが浮かんだ。
Scrum@Scaleで優れていると思った点は、課題管理などの意思決定プロセスが階層化されているにも関わらず、意思決定のスピードが速いことだ。
Scrum of Scrumを組織構造に合わせてマッピングさせている点がうまいな、と思った。
(引用開始)
これをSAAB Technologiesという会社、戦闘機のグリペンの開発でやっています。ゲームの「エースコンバット」をやっている人なら、グリペンは良い機体だっていう人、いますよね？
彼らは製造業なので朝が早いです（笑）
7時30分 SCRUMチームのデイリースクラムがあります。
7時45分 SoSのデイリースクラムがあります。
8時00分 SoSoSのデイリースクラムがあって、
8時15分 SoSoSoSのデイリースクラムがあって、
8時30分 EATがあります。
というわけで、スクラムチームが価値を届けることに困るような課題があれば、1時間後にはトップエグゼクティブの知るところとなって、そのEATでさっさと課題に対応できると。圧倒的に早いですよね。
(引用終了)
EATは取締役会に相当するらしい。
最終的な意思決定の責任は、会社の最高意思決定機関に委ねられる。
会社法上の仕組みとScrumの仕組みを上手く調和させるように作っているわけだ。
AgieTourOsakaに行ってきたが、最近の大規模Scrumの事例では、IT企業に限らず、一般企業にも導入されているよ、と聞いた。
話を聞くと、どうやらソフトウェア開発だけでなく、会社の一般業務にもScrumを適用しようとしているらしい。おそらく、Scrum@Scaleのように、課題に対する意思決定プロセスという現場のプロセスと、会社法上の組織としての意思決定の責任を上手く調和させるように、Scrumの仕組みを拡張しているのだろう、と直感している。
そういうことを考えると、Scrumは大したマネジメント・フレームワークなのだな、と改めて思う。
詳細は今後も調べていく。
【追記】
原田さんから、Scrum Patternの本が出版されているのを教えてもらった。
ペーパーバックで高価だが、オンラインでも一部は読めるらしい。
2019/11/03
第17回東京Redmine勉強会の感想 #redmineT
第17回東京Redmine勉強会が無事に終わりました。
参加者、スタッフ、講演者の皆さん、ありがとうございました。
感想をラフなメモ書き。
第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年以上リリースされていないため、せっかくのパッチが使われていない。
この問題意識は重要と思う。
一方、Redmineプラグイン開発者の観点では、RedMicaにプラグインを追随させることで、メジャーバージョンアップに事前に対応できる、というメリットもある。
気になる点は、過去にRedmineをフォークしたChiliProjectのように、Redmineコミッタとギクシャクした関係になったりしないか、という点。
この辺りは、前田剛さんももちろん考えておられて対処している、という印象を持った。
Redmine本家に追随しながら、Redmineの発展を支援していく方向になるといいな、と思う。
【3】アカベコさんのRedmineテーマの開発も興味深い。
テーマは、RedmineのUIを手軽に改善できる手法の一つだ。
沢渡さんの「Redmineをお化粧する方法」という言葉がまさに的確と思う。
SCSSやDockerコマンドの説明は、初心者にも分かる様にすごく丁寧に話されてる点が良かったと思う。
RedmineのUIが古い、UIが使いにくい、という話は以前からよくあがっていた。
Redmineテーマの種類が増えたり、テーマの開発が活発になることで、よりユーザフレンドリーなUIに進化できるきっかけになるといいなと思う。
【4】@akahane92さんの全文検索プラグインのお話は、過去のIT全般統制の事例、性能チューニングの話を振り返りながら聞くと思い出深い。
僕が理解したストーリーとしては、メーカー情報システム小会社の立場として、Redmineを社内システムのPJ管理基盤として導入し、IT全般統制も取り入れて、プロセス基盤を固める。
すると、Redmineが持つチケット管理機能やトレーサビリティの恩恵を受けた後、次に出てくる課題は、チケット40万以上の蓄積されたデータを活用して、ナレッジシステム化していくこと。
もちろん、Redmineが肥大化することで、性能チューニングの課題も出てくる。
そこに、全文検索プラグインを導入することで、Redmineのチケット、Wiki、果ては添付ファイルやSVN配下の文書に至るまで全文検索の対象になり、Redmineは真のナレッジシステムになったわけだ。
@netazoneさんが全文検索プラグイン導入のLTをしてくれたが、@akahane92さんの話を聞くと、単に全文検索プラグインを入れるだけでなく、ChuperTextによる形態素解析、検索Jobの設定などミドルウェアの設定もかなり多い。
つまり、全文検索の精度向上や性能チューニングの為に相当なノウハウが込められている点は注意。
【5】パネルディスカッション「チケットを切れる人切れない人／なじむ文化なじまない文化」にパネラーとして参加させてもらった。
沢渡さんのお話は非常に軽快で楽しかった。
沢渡さんの発言から刺激を受けた内容を話したいという気持ちが強すぎて、言いたいことの半分も話せず、あっという間に終わってしまい、消化不良感が残ってしまった笑。
自分が話したかった事をここで書き残しておく。
【5-1】Redmine導入の成功パターンは経験上2つある。
一つは、トレーサビリティの概念は経験済みであったこと。
つまり、すでに開発プロセスのイメージは僕の中で持っていたので、後はRedmineにプロセスを実装するだけだったので簡単だった。
ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか: プログラマの思索
「Redmineによるタスクマネジメント実践技法」の感想を集めてみたpart17: プログラマの思索
もう一つは、システム保守のように、ルーチン作業と突発的作業が混在している環境だったこと。
こういう環境では、チケット管理ツールのような基盤がないと、正直仕事がやってられない。
沢渡さんはチケット管理ツールの特徴として「備忘録のようなもの」という発言をたびたびされていたが、システム保守の現場ではまさに備忘録の基盤が必要。
「備忘録」というキーワードは、@sakaba37さんもチケット駆動開発の説明でも使われていたので、既視感を感じた。
【5-2】チケットには「ストック」「フロー」という2つの特徴を持つ。
物理学における光が粒子と波動の二重性を持つのと同じように、チケットはフローとストックの二重性を持つ点が非常に重要と考える。
ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索
Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索
チケット管理の上手な人は、チケットをストックだけ、フローだけで回すのではなく、チケットという1個のインスタンスを状況に応じてストックで扱かったり、フローに見せたりして、2つの性質を同時に使わせようとしていると考える。
一方、Excel管理では、この二重性を持たせるのが非常に難しいので、上手く回らない。
WBS駆動チケットというアンチパターンは中身がスカスカのチケット、と紹介して、他のパネラーも共感してくれた。
チケットをトップダウンでフローだけで扱おうとして、ストックにならないから、中身がスカスカになってしまうわけだ。
【5-3】沢渡さんの話で、オフショアチーム連携では、チケット管理ツールとチャットツールの２つあれば回るという経験談が興味深かった。
NTTデータのお仕事のときは、自社製のITSやチャットツールで運用されていたらしい。
僕は、沢渡さんの考えでは、仕事をする環境では、タスクや課題を共有する基盤とリアルタイムにコミュニケーションする基盤が必要なのだ、と理解した。
沢渡さんの発言の中ではたびたび、口頭でのやり取りでは後に残らないので仕事にならない、チケットに残して安心して忘れるべきだ、と話されていたが、それを実現する基盤がそれらなわけだ。
今ならば、Redmine はストック、Slackはフローで役割分担するだろう。
akipiiさんはTwitterを使っています: 「@saito0119 #redmineT Redmine はストック、Slackはフローと言う役割分担ですね。」 / 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が人や組織を変化させるような話や事例をもっと集めたいし、聞いてみたいと皆思っているはず、と思っている。
最近のコメント