Redmine

2018/05/27

第14回東京Redmine勉強会の感想 #redmineT

第14回東京Redmine勉強会が盛況で無事に終わりました。
スタッフ、参加者の皆さん、ありがとうございました。
感想をラフなメモ書き。

【参考】
2018/5/26 第14回勉強会 - redmine.tokyo #redmineT - Togetter

第14回勉強会 - redmine.tokyo

redmine.tokyo 14 で登壇してみた – アカベコマイリ

【1】グループディスカッションで話を聞くと、最近Redmineを運用し始めた、という人から、10年近く触っている人まで幅広いユーザ層でした。

また、1年前から参加者の女子率が上がっているように感じてます。
女性陣もデザイナー、品質保証部、PMO、インフラ管理者など幅広い分野で活躍しており、Redmineに関する問題意識も当然高い。
以前は、40代のおっさんばかりがRedmineコミュニティにたむろしていたのを振り返れば、感慨深い。

ゆえに、参加者層が幅広くなったおかげで、ユーザコミュニティの雰囲気は、毎回開催するにつれて良くなっていると思う。

【2】個人的には、Twitterでやり取りしている人と対面できたのも嬉しい。
講演してくれた@akabekobeko さん、@nekosanz1 さん、グループディスカッションでお話できた@endo_5501 さん、@kabukawaさんを認識することができた。
もちろん、@kaorabeさん、@MadoWindaheadさん、@acha_821さん、@aj15_aj15さん達ともお話できたのも楽しかった。
また、Redmineコミュニティが縁で結婚されたカップルも居る。

コミュニティを通じて、輪が広がるのも楽しい。

【3】山崎さんの講演では、Redmineとツール連携する例として、MSProjectからRedmineへインポートするプラグイン、RedmineとSlackを同期するプラグインが紹介されていた。
(たぶん、山崎さんの会社でプラグインを作成されているだろう)

プロジェクトマネージャの要望としては、立上げ時にMSProjectで作ったプロジェクト計画をRedmineへインポートしたい要望が多い。
ざっくりしたスケジュールを引いてクリティカルパスを表示させるのは、やはりMSProjectの方が楽だから。

しかし、予定はMSProjectで作ったとしても、その後の実績管理はRedmineの方がはるかに運用しやすい。
日々の進捗はどんどん変わるし、複数人が編集して最新化する手間を考えると、MSProjectに拘る必要はないと思う。

このプラグインで面白いのは、親子チケットの構造をRedmineでも再現できる点。
現状のRedmineのREST APIでは、ツリー上のWBSを作る時、どうしても2回発行しなければならない。
なぜなら、親チケットが決まった後で、子チケットをぶら下げる更新処理が必要だから。
ゆえに、1回の更新で、しかもチケット番号を昇順に採番して更新するような仕組みがあると便利だろう。

【3-1】また、Slack連携では、Redmineの活動ログをSlackに流すだけでなく、SlackからRedmineへチケット登録する運用が紹介されていた。
仕組みとしては、Slack上で、「タイトル:~、内容:~」のようにコメントすれば、RedmineのREST API経由で登録される仕掛け。

Slackからチケット登録できるメリットは、Slack上で障害を見つけたやり取りをしている時に、Slackから即座にチケット登録したい時もあるだろう。
すなわち、Slackの運用が既に定着していて、Redmineに情報を集約して記録して残したい場合に、有効に使えるだろう。

【3-2】似たような例として、@netazoneさんがGoogle Homeで、ボイス入力した内容をRedmineにチケット登録する利用事例のLTがあった。
仕組みとしては、Google HomeからIFTTT(IF This Then That)・GMail経由で、Redmineへチケット登録メールを送って、メールによるチケット登録機能を使っていた。
Google HomeからRedmineのチケット登録ができるメリットは、PC操作無しで会話するだけでチケット登録できること。
たとえば、カスタマーサポートや事務担当者などの非エンジニアが使う利用シーンが考えられる。

このように、Redmineの優れた外部I/Fを上手く使えば、チケット管理のコストを下げることが出来るだろう。
また、現場の利用シーンを考えながら、Redmineと連携する設計を考えるのも楽しい。

【4】@akabekobekoさんの「なじむ Redmine」も面白かった。

個人的には「Redmineを浸透させるために、故意に「活況を演出する」」という考え方が面白かった。
つまり、流行っているレストランは、流行っているから更に新規顧客も増える、という現象と同じ。
特に日本人は、皆がやっている雰囲気に弱いので、故意にRedmineの活況を演出し、Redmineに触らざるをえない雰囲気に持っていく。

事例としては、Wikiで議事録や設計メモをまとめることから入り、その後チケットの運用に入っていく。
どうやら、初心者にとって、チケットを登録するのはハードルが高いらしい。
チケットのUIはボタンが多いし、ちょっとの更新でも履歴が残ってしまうので、変な更新ができない、完璧に書かないといけない、という心理が働くらしい。
几帳面で完璧主義の古き良き日本人にありがちな行動だろう。
だから、そんな時は、周囲がサポートする。
たぶん、Redmine警察とか、Redmine職人、とか、Redmineエバンジェリストの出番なのだろう。

【5】実は、今回の勉強会では、RedmineのGit連携が最大のテーマだったと思う。
パネルディスカッションで取り上げられた。
@akabekobekoさんの講演でも、最後の課題にあげられていた。

(引用開始)
最近、日本のRedmine 界隈で話題?になった記事
Redmineの直近の課題~競合ツールGitlabに対抗できるか: プログラマの思索
↑で挙げられている内容はRedmine 運用していて強く 実感させられる課題です。
私的には環境面の運用が厳しい。インストール、更新、プラグインやテーマの配布と互換性など。
(引用終了)

【5-1】パネルディスカッションで、パネラーや参加者の声を聞く限り、RedmineユーザはSVNとRedmineの連携はよく使っているが、Git連携を使っている人は少ない印象を持った。
つまり、SVNの知見は皆良く知っているが、Gitの知見を持つ人は少ない。

話を聞いた印象としては、プロジェクトマネージャやPMOとしてRedmineでチケット管理している人たちは、そもそもGitを運用する利用シーンがそもそも無い。
彼らのモチベーションはチケット管理による作業の進捗管理やリソース管理がメインだから。

【5-2】一方、RedmineとGitを連携して運用する場合、2つのパターンの事例があった。

1つ目は、RedmineとGitlab、Gitoliteと連携して、Redmineではチケット管理、Gitlab側ではブランチ管理で分けている。

Redmineサーバー側にGitのBareリポジトリをクローンし、Redmineのリポジトリ画面と連動させる運用をしている。
もちろん、Redmineのチケット番号をGitのコミットログに埋め込むので、トレーサビリティは維持できている。

しかし、Gitlabのプルリクは使えていない。
あくまでも、Gitのブランチ管理とマージ作業だけに限定されている。
よって、昨今のGitHubで最も優れている運用方法「プルリク時点のコードレビュー」が仕組みとして提供されていないデメリットがある。

2つ目は、Redmineのチケット管理とGitHubのソース管理は明示的に連携せず、Redmineではプロダクトバックログや障害チケットの管理を行い、GitHubではマージやプルリクを使う、と運用を分けている。

すると、GitHubでは活発なプルリクが行われるので、プルリクのタイミングで必ずコードレビューが行われて、masterの品質は維持される仕組みになる。
このプルリクとコードレビューが密接に関係することで、エンジニア同士のコミュニケーションが促進され、お互いの理解も進み、ソースの品質も維持される仕組みが作られた点にあると思う。

しかし、Redmineのチケット管理と連動していないので、チケット管理ツールの最大のメリットの一つであるトレーサビリティ機能が使えていない。
結局、Redmineのチケット単位にトピックブランチを手動で作り、トピックブランチをプルリクする時点で、Redmineチケットを更新するという手動の運用ルールでカバーしている。

すなわち、現状のRedmineのGit連携には、昨今のGitHubのプルリクという優れた機能を埋込できていない。
よって、Gitの恩恵を最大限活用できているとは言えない。

MAEDA Goさんのツイート: "https://t.co/9GswyYgo4P にコミットするときいつもすごく緊張する。コミットログをスペルチェッカーにかけ直したり、diff見直したり。 #redmineT"

【5-3】RedmineのGit連携の機能が不十分である、という課題は、おそらく有識者は皆知っていて、何とか解決を図ろうと色々試されている、と思う。

@agilekawabataさんは、RedmineのBareリポジトリを作成するプラグインを作ったら欲しい人はいるか、という質問を投げかけていた。
初心者にとって、GitのBareリポジトリを作成する作業はハードルが高いので、プラグインがあれば、その部分のハードルは下がるだろう。

onozatyさんのツイート: "Bareリポジトリを画面側からクローンできると確かに楽だなぁ。 (回数がそこまで多くないので耐えられているけど、、)… "

onozatyさんのツイート: "そですね、きつすぎますね。 GitLab+Redmineで使っているのですが、新規プロジェクト立ち上げる時の手間がそれなりにかかるので、そのあたりもう少し便利になるといいですね。 画面からBareリポジトリ作れるようになると、画面操作だけで完結するので敷居も下がるかなと。… https://t.co/tJVZYxcff5"

また、maeda-m さんのredmine_git_work_in_progress プラグインでは、作業ブランチとマージ先のブランチのDiffやブランチの状況を可視化する機能を紹介されていた。

matsukei/redmine_git_work_in_progress: This is a plugin that provides Reduine's Issue like "Work In Progress Pull Request" and makes it easy to share knowledge.

あるいは、RedmineとGitlabを連携したり、RedmineとGitHubを連携する方法で運用をカバーするやり方もある。

akipiiさんのツイート: "#redmineT Gitlab からベアリポジトリを作ってRedmineと連携してるのね。では同期はどうしてる?"

taikiixさんのツイート: "(会場で結論が出ているかもしれませんが)私はこのプラグイン使っています。 https://t.co/C0DQ7APwxL… "

koppen/redmine_github_hook: Allow your Redmine installation to be notified when changes have been pushed to a Github repository.

たむさんのツイート: "うちは、gitlabとredmineは独立したインスタンスなので、nfsマウントしていますよ… "

MAEDA Goさんのツイート: "mod_perlがRHEL 7から標準ではなくなったので、https://t.co/YqxU0tFwwx のインストールめんどくさそう。 #redmineT"

【5-4】RedmineとGitlabの連携で最大の問題となるのは、GitのプルリクとRedmineチケットが密接に連携できない点がある、と思う。

例えば、プルリクを作る前に、その作業のチケットがない場合、Redmineにチケットを書いて、Gitにチケット番号を書いてコミットしてプルリクを送る、という面倒な作業が発生しないか。

あるいは、トピックブランチの作業とチケットが連動できていても、プルリクを送りたい場合、プルリクに相当するリビジョンをチケットに明示的に書いて、チケットを「プルリク」ステータスに変更して、作業するのは面倒ではないか?

akipiiさんのツイート: "#redmineT @tkusukawa さんの質問はとても重要。そもそもソース修正の発端、変更管理はどこでやるの?GitHub のプルリクでやるとしても、発端のチケットが登録されてから、ソース修正が発生する。プルリクは発生チケットの後になる。ではどうやって紐づけるの?"

門屋浩文@redmineエバンジェリストの会さんのツイート: "修正変更の出発点と完了条件を決めるツールによるということか? #redmineT… "

おそらく一般の運用ルールでは、GitのトピックブランチとRedimneチケットは1対1に対応させるはず。
たとえば、Redmineチケットを発行後、チケット番号をGitブランチ名に明示的にSuffixとして入れて、対応付けて運用するだろう。
たとえば、#12ブランチみたいな感じ。
すると、masterにマージしたい時に、プルリクしたい、というステータスをRedmineチケット上に設けざるをえない。
つまり、Redmineチケット上のステータス変更でプルリクを検知し、コードレビューが行われ、OKならば、マージされてチケットもCloseされる運用になるだろう。

本来はこの運用がRedmineの機能として、手軽に操作できるように実現できたらいい。
現状は、Git上でマージ作業を行い、Redmineのチケットを別途更新する、といった作業が2つのシステムで発生するので、正直面倒に感じやすい。
実際、GitHubでは一つの画面で操作できているから、尚更そう感じてしまう。

一方、Redmine本家のPatchチケットのように、パッチファイルとRedmineチケットが1対1の場合もある。
つまり、Redmineチケットが発行されないまま、トピックブランチが作られ、マージして欲しいなと思う時点でパッチファイルを出力して、Redmineチケットにパッチファイルを添付する運用スタイル。

この運用では、trunkが成長するにつれて、パッチファイルが古くなってしまい、マージされるタイミングを逸失されがちになる。
昨今のように、ビジネスレベルでもアジャイルが求められる時代では、このパッチ主導の運用は正直、時代に合っていないと思う。

よって、今後のRedmineのGit連携の機能改善としては、下記3点が必須になるのではないか。

(1)GitのBareリポジトリ作成を画面上の操作で行える。
さらに、GitのBareリポジトリはリアルタイムに同期される。
(2)GitのトピックブランチとRedmineのチケットを1対1に明示的に対応付ける操作を画面上で行える
(3)GitHubのようなプルリク機能をRedmineにも取り入れて、GitのマージをRedmine画面上で操作できるだけでなく、チケットCloseも自動更新できるようにする

【6】参加者に聞いてみたら、東京Redmine勉強会ではいつも講演が盛り沢山なので、たとえば午前10時から午後17時までRedmineカンファレンスを開催する、とか、限定されたテーマでRedmine勉強会を開催してはどうか、という意見があった。

Rubyカンファレンスには及ばないけれども、Redmineカンファレンスみたいなイベントがいつか開催できるといいな。

| | コメント (0)

2018/05/25

第14回東京Redmine勉強会の見所


第14回東京Redmine勉強会の見所についてラフなメモ。
そして、今後のRedmineコミュニティの方向性について、最近個人的に考えていることをラフなメモ書き。

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

第14回redmine.tokyo勉強会 - connpass

【1】今回の勉強会では、講演者もLTを含めて11人と豪勢な内容になった。
また、Git連携に関するパネルディスカッションを入れたり、グループディスカッションも入れているので、相当盛りだくさんの内容になっている。

【1-1】今回のテーマは『Redmineとその周辺ツール活用事例』。
REST APIやGit連携、他システムの連動に関する事例がある。

僕は、Redmineの醍醐味は外部ツールと色んな手段で連携できるI/Fを持つことではないか、と思っている。
なぜなら、Redmine単体で不足している機能は、Redmine標準で用意しているI/Fを使って外部ツールに任せることができるから。
そういうシステム設計や運用を考えるのも楽しい。

また、Redmineは構成管理ツール連携が当初から標準だったので、この機能を使ってトレーサビリティがどんな性質を持つものなのか、実体験できたのも良かった。

但し、今後はGit連携の強化がRedmineの鍵になると思っている。
その内容に関する議論は、パネルディスカッションで盛り上がるだろうと期待している。

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

【1-2】個人的には、@akabekobekoさんに講演して頂けることがとても嬉しい。
以前から、下記の記事は参考にしていた。

Redmine 運用について 1/3 ? はじめに ? アカベコマイリ

Redmine 運用について 2/3 ? 運用ルールと諸設定 ? アカベコマイリ

Redmine 運用について 3/3 ? 普及の施策と課題 ? アカベコマイリ

(引用開始)
つきあいの長い Redmine について以前からまとまった文章を書いてみたかったのだが、なかなかその気にはならなかった。書きはじめたら長くなるのは必然で、そのため腰が引けていた。そんな折、Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例: プログラマの思索はてブの反応はよい刺激になった。
Excel 中心で管理したい上司をどう説得するか。説得を諦めて現実解として Excel ジェネレーターを実装するのか。
幸い私は理解ある環境に恵まれて Redmine 導入に成功したが、そうではない人や環境に対して知見の一部でも役立てば、という気持ちで記事にしてみた。
(引用終了)

既存のExcel中心の組織文化の中で、いかにRedmineを浸透させて効果を上げていくか。
そんな組織の中で、現実的で実現可能な方法やレベルはどこにあるのか。
その辺りも聞いてみたいと思う。

【2】今後のRedmineコミュニティの方向性について、最近色々考える点はある。

一つは、Redmineユーザのレベル感や興味に関するセグメント別に、Redmine勉強会を定期的に開けたらいいな、と思うこと。
理由は、東京Redmine勉強会はいつもすぐに満席になってしまうので、せっかくRedmineに興味を持っている人達を取りこぼしてしまっているのが残念だから。

最近の勉強会に参加する人達とグループディスカッションで話を聞いてみると、長年の経験者もいれば、今から触ってみたいと思いますという初心者まで幅広かった。

そんな状況をふりかえると、経験者や初心者というレベル別に向けた勉強会を別の日程で開催してみる、とか、ViewCustomizeプラグインの使い方や効果的な事例のような特別テーマに関する勉強会を開催してみる、とか、もっとバリエーションを増やしてもいいかなあ、と思う。
既に、Redmineエバンジェリスト会のように、組織とRedmineをテーマにした勉強会も運営されているので、もっと増えたらいいな、と思っている。

もう一つは、Redmineコミュニティを東京や大阪だけでなく、各地でも開催できたらいいな、と思うこと。
なぜなら、東京でも大阪でも、福岡や福井、名古屋などの遠方からの参加者が意外に多いからだ。
今の自分のパワーでは東京と大阪ぐらいしかタッチできないけれど、Redmineユーザが各地にいるならば、各地で開催できるといいなあ、と思う。

こういうオープンソースのコミュニティ活動に好きで関わっているけれど、じきに、こういうコミュニティを半永久的に維持していければいいなあ、とぼんやりと思っている。
どんな実現方法があるのか、正直分からないけれど、いつか実現できるといいな。

| | コメント (0)

2018/04/25

Redmineの直近の課題~競合ツールGitlabに対抗できるか

2018年4月現在、Redmineの今後の課題について考えてみる。
以下はラフなメモ書き。

【1】Redmine大阪や東京Redmine勉強会にスタッフとして活動してきた中、参加者も大幅に増えて、参加者層も初心者から経験者まで広がり、業種もIT業界だけでなく特に製造業にも広がっている印象を持っている。

たぶん、RedmineはRailsアプリ、そしてチケット管理ツールの中で、日本で最も普及したアプリの一つだろう、と思う。

しかし、技術革新の流れが早い中、Redmineにも課題がチラホラ見えてきたように思う。
僕は、Redmineの直近の課題は、Redmineのシングルページアプリケーション化、Redmineのコンテナ化、Git連携の強化だろうと思う。

【2】1つ目は、RedmineのUIが古臭いと言われる問題意識だ。
たとえば、スマホに慣れていると、Redmineのように画面更新のたびにリフレッシュされる仕組みは正直手間がかかるイメージだ。
一つの画面内で、必要な箇所だけ更新するだけで、画面全体がリフレッシュされる必要はないはず。
その分、処理速度も早くなるし、ユーザの利便性も上がる。
つまり、昨今のUIで主流のシングルページアプリケーションのような仕組みをRedmineにも導入していくべきだろう。

以前、RailsはJavascriptと相性が良いので画面UIもリッチで使いやすかった。
しかし、Railsフロントエンド技術も、昨今の時代の流れの影響を受けて、どんどん進化している。

Railsフロントエンド技術の今とこれから - Hack Your Design!

rails × AngularJSでシングルページアプリケーションを作るTips - Qiita

Rails5.1に向けてフロントエンド周りで起こっている革命まとめ - Qiita

一方、競合の状況を見ると、有償のチケット管理ツールであるJiraやBacklogに比較されやすい。
それらツールは、昨今の時流に合わせてUIフレンドリーな画面になっている。
もちろん、OSSのRedmineに対し、営利目的の会社が多数の開発者というリソースを持つ競合の方が恵まれている点は否めない。

【2】2つ目は、Redmineのインストールやバージョンアップが難しいと言われる点だ。
初心者にとって、RubyやGemをインストールする時、バージョン違いによって、ハマってしまう場合が多い。
Redmineを使いたいだけなのに、セットアップに手間取ってしまって断念するケースも多いのではないか。

Redmine 3.4をCentOS 7.3にインストールする手順 | Redmine.JP Blog

この点に関しては、最近、Gitlabにも注目している。
特に、Gitlabでは、バックアップやコンテナ化など技術的にも優れている点が見えてくる。

たとえば、バックアップやリストアはrakeタスクで用意されているので、Cron化しておけば、保守で気にする必要はない。

Rake tasks | GitLab

また、GitlabCIまでセットアップすれば、Redmine+Jenkinsよりも使いやすい点はあるだろう。
インストール対象が2つのツール(RedmineとJenkins)よりも1個のツール(GitlabCI)の方が楽だから。

Gitlab + Gitlab CI をためす - LGTM

個人的には、RedmineのバージョンアップをiOSの自動更新みたいに、もっと手軽にすべきだろう、と思う。
現状でも、プラグインをGem化するアイデア、RedmineをDockerでコンテナ化する、等が色々試されている。

Feature #27705: Gemify redmine plugins - Redmine

これらアイデアをさらに発展させて、Redmineのバージョンアップの自動更新がワンクリックで可能になるように、改善されるべきだろう。
たぶん、Dockerのようなコンテナ化に解決の鍵があると感じている。

なぜなら、ちょうど今はコンテナ化や仮想化のように、インフラ基盤をプログラム化する技術が一番ホットな話題であること、それら技術がクラウドと相性がすごく良い事もあるからだ。

【追記】
RedmineのDockerは下記でインストールできる。
Windowsでも問題なくインストールできるのはすごく良い。

Redmineインストール from Docker Hub - Qiita

【3】3つ目は、RedmineはGit連携の機能が弱い点は、従来からずっと知られていた。

一方、Gitlabのチケット管理もRedmineより弱いとは言え、着実に改善されている。
一般に、SVNよりもGitを使うのが普通なので、この点に関してRedmineは多少不利な面がある。
いつか、Redmineの競合候補になってくるのではないか。

RedmineとGitLabを連携すると、RedmineをGitHub化できるか: プログラマの思索

RedmineとGitを巡る疑問点~Gitとの連携機能の強化がRedmineの課題: プログラマの思索

【4】個人的には、Redmineの競合ツールは有償ツールであるJiraやBacklogではなく、OSSのGitlabになるのではないか、と思っている。

理由は、ポジショニングマップで書くと、RedmineとGitlabはちょうど正反対の位置に配置されるからだ。
実際、「Git連携が強い・弱い」軸と「チケット管理機能が強い・弱い」軸の2次元でプロットしてみれば、「Git連携が強く、チケット機能が弱い」GitLabと、「Git連携が弱く、チケット機能が強い」Redmineで斜め方向にプロットできる。

よって、RedmineとGitlabは全く正反対の性質を持つツールなので、現在は双方を連携することで相互補完する方向に進化している。
すなわち、Redmineでチケット管理して、Git管理やプルリクエストはGitlabで行い、WebhookによりチケットとGitを連携できるようにする運用スタイルだ。

GitLabとRedmineを連携してみるの巻 - アルパカDiary Pro

GitlabとRedmineを連携させる方法の覚書。 - Qiita

でも、RedmineもGitlabもGit管理やチケット管理の機能を強化していく方向へ進化するならば、競合することになるだろう。

なお、Gitlabには、GithubクローンとしてOSS版とエンタープライズ版が提供されている。
ビジネスモデルとしても、うまいやり方だと思う。
なぜなら、OSSで提供することにより、ユーザ数を増やせること、また、ユーザのフィードバックを受けて有償ツールに反映してどんどん機能拡張できること、があるからだ。

GitlabもRedmineと同じくRails基盤なので、改修しやすいし、機能改善の進化も速いので、近い将来、現在のRedmineの優位性は変化していくかもしれない。

たとえば、Gitlabが強力なチケット管理機能を実装したら、プログラマ層は皆、RedmineよりもGitlabに流れてしまい、Redmineのユーザ数は減ってしまうだろう。

現在は、たまたま、日本のRedmineユーザに熱いパッションを持つ人達が多いので、最新機能をいち早く試して人柱になったり、数多くの運用事例を紹介してくれたりして、コミュニティ中心に盛り上がっているけれど、いつまでもそういう幸運は続かないかもしれない。

GitLabでタスク管理してみた感想(主にRedmineとの比較) - YoshinoriN's Memento

【5】とはいえ、そういう課題がRedmineに見えてきたが、たぶん、解決できるだろうと楽観視している。
また、技術者として、ツールの課題を技術面から解決していったり、それについて色々試行錯誤して技術を試すことは楽しい。

今後もいろいろ考えてみる。

【追記1】
Gitlabの場合、RPMが提供されている。
よって、yum updateだけで簡単にバージョンアップできる。

Manually Downloading and Installing a GitLab Package | GitLab

GitLabを7.9.2から7.12.0にアップデートした時の話 - Qiita

Git lab rpm でインストール - Qiita

Redmineでも、RPMを提供できないだろうか??
また、Redmineのバックアップ用のrakeタスクも実装できないだろうか?

そうすれば、プラグイン無しの標準Redmineであれば、DBバックアップと添付ファイルバックアップだけすれば、VerUp作業そのものを自動化できるからだ。
RedmineやRubyの初心者であっても、インストールやバージョンアップ、バックアップに苦労する問題はなくなるだろう。

【追記2】
皆同じ事は考えている。

taikiixさんのツイート: "現代の開発フローがGitとPRを中心としていることを考えるとPRの実装は喫緊の課題だと思います。でもそれ以上に、半年でメジャーバージョンアップするGitLabに対抗するには今の開発スピードでは歯が立たない。だからRedmineはGitHubに開発の場を移し、広くcontributorを集める必要があると思います。… https://t.co/jt4Kmk9pCx"

MAEDA Goさんのツイート: "gitへの移行はJPLがその気になる必要があるため、簡単には進まないと思います。本家のやり方を変えずに開発への参加のハードルを下げる方法として、非公式のミラーリポジトリでプルリクエストを受け付けて私がGitHubとチケットの中継をするのはありだと思います。私が中継するので日本語でOKです。… https://t.co/LIFzu4B1lk"

【追記3】
akipiiさんのツイート: "日本の熱心なRedmine ユーザーは自らモルモットとなり、自ら海に飛び込んでいくのです!その結果は如何に?… "

あさこさんのツイート: "大きな海に溺れるも、無人島にたどり着く。そこの名は、redmineアップデートセンター…‼… "

akipiiさんのツイート: "@agilekawabata さんに解決してもらって、 @g_maeda さんに本家に取り入れてもらいましょう。。。… https://t.co/svy5cW1puI"

やっさんさんのツイート: "GitHubがメインリポジトリならもっと参加者増えて開発も回りそうな気もするんですけどねぇ🤔… https://t.co/YekJeR0RRl"

【追記4】
門屋 浩文さんのツイート: "こちらこそー。これは感覚論だけど、同じシステムを使う人は似たような振る舞いをするようになる。社会や文化と同じように。redmine関係者の振る舞いや感性は、正直好きだね。いろいろおいてきた、できなかったことが少しずつできるようになるヨ・カ・ン… "

akipiiさんのツイート: "似た振る舞いになる、と言う話は同感。たぶんチケット管理してれば、Redmine でもJiraでもTrelloでも手法や考え方は同じ。以前できなかった事がチケット管理ツールで実現できる予感も同感。ソフトウェア工学は本来はこういう開発基盤が欲しかったはず、といつも思う。… https://t.co/3OzYY4e39R"

akipiiさんのツイート: "Redmine にある機能は、細かな一機能に過ぎないかもしれないが、人の行動を変えさせるきっかけになる、と言う事例は心当たりがないですか? 是非エバンジェリスト会でネタを集めてください笑… "

akipiiさんのツイート: "Redmine でバージョンアップごとに改善された機能には、世界中の開発者が試したベストプラクティスが反映されてる。ツールの機能とプラクティス、そして開発プロセスは表裏一体と思います。特に最近のRedmine,Gitlab,Jenkinsはそう強く感じる。… https://t.co/N1LJQ69erp"

あさこさんのツイート: "redmineにも、アップデートセンター入れてほしい。… "

あさこさんのツイート: "あわわわわわ… 川口さんが、jenkinsはアップデートセンター入れてから爆発的に広がったと言っていたので、同じような経路をたどるかもしれませんね。。 そうすると、redmineバージョンアップの毒沼地はいい感じで消えていってくれる…かもしれませんね(・_・;)… https://t.co/tSddJPec3O"

akipiiさんのツイート: "似た話として、Gitlabにはrakeコマンドで自動バックアップするコマンドがあった気がする。Redmine と同じRailsアプリならば、他ツールの機能をパクるやり方もありですね。… "

【追記5】
RedmineのREST APIにも、SwaggerのようなI/F仕様書のWebサーバーがあれば、もっと使い勝手は良くなるだろう。

SwaggerでRESTful APIの管理を楽にする - Qiita

SwaggerでWebAPIドキュメントをExcel仕様書から脱却するアイデア: プログラマの思索

あきこさんのツイート: "RedmineのAPIはドキュメントが分かりにくいかな? 公式サイトにも載ってるけれど、GETしか対応してなかったり。 apipieやswagger docのようにソースコード中のコメントや説明がそのままドキュメントとして表示できるようになってたらなあ...なんて思います。"

あきこさんのツイート: "他はわからないんだけれど、JenkinsはRest APIのドキュメントのページがアプリケーションの一部としてくっついてた。JIRAやConfluenceも、ローカルで動かしたとき、Rest API Browserっていうのがあって、APIの仕様の確認がしやすかったなー。"

| | コメント (0)

2018/03/16

複数Redmineの内容を一つのRedmineに集約して見る方法

複数Redmineの内容を一つのRedmineに集約して見る方法について、ツイートされていた内容を@y503unavailableさんがまとめてくれたのでメモ。

【元ネタ】
気づき #764: 複数Redmineの内容を集約して見たい。 - Unofficial Redmine Cooking - redmine.tokyo

【発端】
@j15_aj15さんから、社内に複数のRedmineインスタンスが起動されていて、それらRedmineのチケット内容を一つのRedmineの画面上に集約して見たい、という要望があった。

昌。さんのツイート: Wiki Extensionsプラグインのiframe使ってよそのRedmine見よ!って思ったけど動かない。バラけてるタスクをメインの子で見れたら幸せだったのに。

【関連ツイート】

りょうまさんのツイート: "自ホストのapacheなりnginxでリバプロしてやって、自ホストのURLとしてiframeに埋めれば見られるのではないでしょうか。 パスの階層違うと別な対処が必要ですが。… "

あきこさんのツイート: "iframeで他のサイトに埋め込みできると、クリックジャッキングという攻撃(悪用)ができてしまうので、レスポンスヘッダに「ブラウザさん、このサイトはほかのサイトのiframeに読み込んじゃだめねー」という情報を渡すのです。多分これかなと。… https://t.co/dozV8W5zBx"

あきこさんのツイート: "更新系の操作ができるサイトはiframeで意図せず埋め込まれるのに気をつけないといけないです。 https://t.co/NsfRjWF9PW… "

あきこさんのツイート: "Redmine (というかRails4以上かな) デフォルトでsameoriginです。 ソースを変えない前提なら、各Redmineが同じドメインでSub URIで複数稼働してるケースなら行けると思います。https://t.co/Fixggi7YmP, https://t.co/eOhIZmak4f みたいな感じだったら。安全性を鑑みてAPIで統合が良いとは思います。… https://t.co/q1y6F9QVHm"

昌。さんのツイート: "解除できたらいいなー。情報一元化したい。 現実問題、他方のRedmineにタスクが散らばってること、結構あるんですよね。… "

neta@筋肉 筋肉〜💪さんのツイート: "https://t.co/gcFS9svZF5第12回勉強会/ のLT4 が(jvasseurさん)「複数 Redmine での開発のためのツールを作ってる」話でした(Private になってるようなのでスライド直リンクできず)。 これもAPI経由ですね、チケットを見るのではないかもですが… https://t.co/SVNfI5GRkH"

昌。さんのツイート: "もんのすごく乱暴ですが、とりあえず自分の環境でタスク一元確認するために、Ignore X-Frame Headerで一時的に回避してみました。少しだけ幸せ。皆様、有効なご意見色々ありがとうございました。さらに精進します。… https://t.co/zlcb3ZDv0J"

【一つの解決方法】
(引用開始)
(1)リバースプロキシの利用

RedmineのWebサーバ側でリバースプロキシし、
参照先Redmineの表示内容を自ホストのURLとして表示可能にすることで、iframeを利用して表示できる。

(1-1)iframe , X-Frame-Options ヘッダ設定

Wiki Extensionsプラグインのiframe使って別Redmine上の内容も表示させたいが、
X-Frame-Options ヘッダで制限されている。
→X-Frame-Options ヘッダのALLOW-FROMで、参照先サーバを許可サイトに追加するなどの対応が必要。

iframeの利用には、セキュリテイ面の注意が必要(クリックジャッキング攻撃などの対策)
『クリックジャッキング』に関するレポートに関するレポート(IPA 技術本部 セキュリティセンター)
(引用終了)

(2)あるいは、PCクライアントにて、X-Frame-Options ヘッダを無効化するChromeエクステンションなどを入れておく。

ローカル環境でX-Frame-Optionsを無効化する - 仕事中の問題と解決メモ。

【X-Frame-Options レスポンスヘッダ】
X-Frame-Options レスポンスヘッダ - HTTP | MDN

X-Frame-Optionsの設定 | 勉強したことのメモ

【クリックジャッキング攻撃】
IPAテクニカルウォッチ 知らぬ間にプライバシー情報の非公開設定を公開設定に変更されてしまうなどの『クリックジャッキング』に関するレポート:IPA 独立行政法人 情報処理推進機構

(引用開始)
サイトへの攻撃はX-FRAME-OPTIONSヘッダが付与されていないからというだけで、攻撃を受けてしまうとは必ずしもいえませんが、IPAではこの対策が最も有力な手段であると考えています。
(引用終了)

クリックジャッキングとは?その攻撃事例と対策方法を解説 | サイバーセキュリティ.com

Webエンジニアだったら当然知っておきたい「 クリックジャッキング対策 」とは? | ヌーラボ

≫ クリックジャッキングって? TECHSCORE BLOG


【感想】
社内にRedmineが複数個インスタンスが立ち上がっている利用シーンはとても多い。

自分たちのチーム専用のRedmineが欲しいニーズもあるし、RedmineインスタンスはBitnamiやDockerなどですぐに立ち上げられるからだ。
すると、社内にRedmineが乱立してしまい、PMOや品質保証部の立場では、各プロジェクトの進捗状況を知るために、各Redmineインスタンスにログインしてデータを取得する手間が発生してしまう。
だから、PMOが主体で管理しているRedmineに、各プロジェクトのRedmineの進捗データを集約するようにしたい。

では、どうやって、複数個のRedmineインスタンスの情報を、一つのRedmineサーバー上に集約させて表示させるか?

この解決方法のアイデアは、@netazoneさんがRedmine大阪のLTにて披露してくれた、RedmineにGoogleカレンダーや動画、Googleスプレッドを埋め込むためにiframeタグを使う方法を公開したノウハウが発端になる。

Redmine にいろいろ埋め込んて゛みた

(引用開始)
今回のテーマは”Embed”(埋め込み)。
Redmine にカレンダーやら動画やら埋め込んでみたところ、意外にうまくやれて捗ったのでご紹介。
(引用終了)

留意点としては、クリックジャッキング攻撃のようなセキュリティリスクの可能性があるので、社内LANの閉じた中だけで行う方が安全だろうと思う。
しかし、社内LANの中でさえも、セキュリティ対策上、許可されない場合もあるかもしれないので、細心の注意を払う必要がある。

とはいえ、Redmineユーザとしては、ちょっと危険な香りのする(笑)ノウハウが蓄積されることも楽しい。


| | コメント (0)

2018/03/12

RedmineもOSLC規格を導入してトレーサビリティを強化すべきか

@agilekawabataさんが、RedmineにOSLC規格を実装すべきでは、と提案されていたのでメモ。
詳細は知らないので、ラフなメモ書き。
間違っていたら後で直す。

【参考】
Feature #8678: Provide OSLC support - Redmine

(引用開始)
Open Services for Lifecycle Collaboration(OSLCまたはオープンサービスとも呼ばれます)は、ライフサイクルツールを組み合わせて使用しやすくすることで、製品ライフサイクルとアプリケーションライフサイクルの間の障壁を解消するためのオープンコミュニティです。
(引用終了)

Kawabata Mitsuyoshiさんのツイート: "チケットによく気付きましたねー。 ツール連携の標準規格です。JIRAは対応してて、こういうのが世界標準としては必要だなあと。 https://t.co/RV0KgGh56u… "

Kawabata Mitsuyoshiさんのツイート: "自動車業界など、欧米の大手企業には必須な感じです。ただ、RedmineもWebAPIがそれなりに揃ってるので、もしかしたら対応できてるのか、どこまで対応すれば良いのかがよく分からない。。… "

Kawabata Mitsuyoshiさんのツイート: "規格に対応することで、他のツールが標準で連携をサポートするようになり、複数のツールによってシステム構築するような大手には導入が進みます。JenkinsやGitHubと連携するようなことと同じです。世界的に広めるには結構重要な要素だと思います。… "

Open Services for Lifecycle Collaboration

OSLC CM Plugin - Jenkins - Jenkins Wiki

OSLC Japan Wiki : 1.OSLC とは

【1】OSLCとは、アプリケーションライフサイクル管理(ALM)でツール連携する時の公式規格のように思える。

OSLCの利用 - Enterprise Architect 13.5 日本語版 ヘルプ

(引用開始)
Open Services for Lifecycle Collaboration (OSLC) とは、ツールを統合するための仕様を定義するオープンなコミュニティです。
この仕様により、利用者の設計開発プロセスにおいて、さまざまなツールを連携させ設計データとワークフローを統合した環境を作ることができます。

OSLCはW3C Linked Dataに基づいています。OSLCでツール間を繋ぐ主要な技術の一つは、HTTPでデータを繋ぐことです。HTTPやRDFのような標準的な技術で、データの作成・参照・編集・削除を実現します。
HTTPのGETやPOSTのような標準的な方法で内容を編集できます。
(引用終了)

OSLCに対応したアプリ一覧では、Jira、Bugzilla、Mantis、Jenkinsなども含まれる。
よって、ツール連携する時に、この規格を使うことも可能。

Software - Open Services for Lifecycle Collaboration

【2】では、このOSLC規格を使うと、何が嬉しいのか?
僕は正直分からない。
今の所、OSLC規格がなくても、Redmineの運用で困った経験はない。

しかし、2012年の古い記事だが、自動車業界の安全規格ISO26262に準拠するために、このOSLC規格を持つALM管理ツールは必須だ、という主張があった。

ISO26262 日本IBM インタビュー:規格準拠は“入場券”にすぎない、ISO26262をきっかけに製品開発力の強化を (2/2) - MONOist(モノイスト)

(引用開始)
MONOist オープンという意味では、「Redmine」のようなOSS(Open Source Software)ベースのプロジェクト管理ツールも候補になりませんか。

根城氏 OSSベースのツールを組み合わせてトレーサビリティを確保することもできますが、プロセスが複雑になります。その上、ISO 26262のPart.8で求められる「Qualification of Software Tools」を満足させるための情報入手が困難です。
 また、ISO 26262に準拠するということは、その製品の企画から廃棄まで最低でも20~30年はデータを管理し続ける必要があります。そのISO 26262と関連するツールも、長期間のサポート継続が確保されていなければなりません。
 小規模の企業のツールやOSSベースのツールは、このサポート継続に不安があります。これに対して当社は、DOORSやRTCについて継続的なサポートを約束していますし、世界的な大企業であることから買収の恐れもありません。
(引用終了)

上記の意見に僕は納得できていないが、そういう発想もあるのだろう。

【3】ここで、上記のOSLC規格の背後にある意図を推測すると、チケット管理・ビルド管理・構成管理の全ツールで、OSLC規格に準拠していて、このOSLC規格が使いやすいものになれば、ツール間連携でトレーサビリティを明示しやすくなる、というメリットを導き出したいのだろう、と思う。

なぜなら、自動車業界の安全規格ISO26262では、機能や要件から成果物に至るまでのトレーサビリティを明示することがプロセス管理の観点で重要である事により、OSLC規格を満たすツール同士を連携して、要件から成果物までを明示的にトレースできますよ、と言った事がやりたいのだろう、と推測されるから。

但し、その方向性をOSLC規格で解決できるのか否かは分からない。
過去にも、SOAPやらソフトウェアタグやら、WSDL・UDDIなど、数多くの規格が提唱されては、消えていった歴史があった。
OSLCは残っていく規格なのか?

【4】Redmineにおけるトレーサビリティについては、Redmineを使い始めてから、トレーサビリティの可能性、そして、トレーサビリティを実現できる範囲をどこまで拡張できるか、をずっと考えてきた。
未だに僕の中では解はない。

Redmineにおけるトレーサビリティの課題は何か?: プログラマの思索

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

Redmineをもっと強化できるポイントpart1~上流工程のトレーサビリティ強化: プログラマの思索

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

チケット駆動開発がもたらした新しい観点part2~トレーサビリティの拡張: プログラマの思索

実際、僕自身、Redmine大阪でも、Redmineでのトレーサビリティの実験結果を発表したが、まだまだたくさんのハードルがあって、思い通りの結果は得られていない。

Redmineにおけるトレーサビリティ管理の現状と可能性(第66回 SEA関西プロセス分科会&第18回 Redmine大阪) #RedmineOsaka

いろいろ考えてみる。

【追記】
akipiiさんのツイート: "内容を聞きたい。そもそも今必要な規格か?RT @ir9: ぶっちゃけ当時そこそこ関係する(糞な)ソフトを創っていた(ぉ // RedmineもOSLC規格を導入してトレーサビリティを強化すべきか https://t.co/mJwHYSu4j6"

いろきゅうさんのツイート: "直接OSLCには関わらないお話で恐縮ですが… リンク記事のようにその昔の車業界の一部では、仕様書からソースまでを紐付けて仕様変更時の影響範囲を知りたい…という飯ネタがあり、そのようなソフト開発に関わってました。「そのうちOSLC対応する」と意識していましたが対応はしていません(申し訳ない… https://t.co/PygxMeoimR"

いろきゅうさんのツイート: "作成してたツールとしては… たとえば、EAのアプリ上にあるUML要素を選択して「関連要素検索」→「wordのxx章 / Excelのyy表 が関連」等出てるのは便利感ありましたが…… アプリ超えた要素の紐付け作業が面倒というのが正直な所でした…… "

akipiiさんのツイート: "ありがとうございます。やはり規格倒れな感じですかね。JenkinsのOSLC対応プラグインも2012年から更新停止だし。Redmine への実装優先度はかなり低そうですね。… "

| | コメント (0)

2018/03/09

ステルス駆動開発でRedmineを浸透させるアイデア

Redmineを浸透させるには、陰でこっそり運用して、ボトムアップで普及させる「ステルス駆動開発」が良い、というツイートを見つけたのでメモ。
以下、主張のないラフなメモ書き。

【参考】
akipiiさんのツイート: "ステルス駆動開発と言うネーミングがイイ!RT @natsucotech: ステルス駆動開発は地味に効くぞ! 偉い人の許可を取らずに勝手に会社に Redmine を導入し、最初はめちゃくちゃ怒られたけど、だんだん「Excel でのタスク管理より楽じゃん!」と評価されつつある"

【1】大企業や規律のうるさい現場では、標準ツールとか標準プロセスなどが押し付けで入っていて、使いにくい場合が多い。
だから、こっそり陰で、自分たちのチームに合ったツールとプロセスでやりたい時がある。

では、どうやって進めればいいのか?

上記のツイートから類推すると、上司の見えない場所でツールを導入して、現場で使ってみて、各チームに浸透させて、ボトムアップで認めさせる方法がある、という。
「ステルス」にはそんな意味合いが含まれているのだろう。

【2】上記のやり方は、以前、@sakaba37さんが言っていた「補完チケット方式」や「アダプタブルWF」に似ている。
つまり、ExcelのWBS管理が既に運用されているけれど、その運用からこぼれ落ちた障害管理、課題管理などをチケット管理でフォローする、というやり方だ。

さかばさんのツイート: "本人的には、保守本流のつもりです。 RT @akipii: 補完チケット方式はチケット駆動開発の先祖返り http://t.co/Q3xj7EuK"

gomasaさんのツイート: "WF型開発にチケット駆動を取り入れる時の考え方: アダプタブルWFや補完チケット方式について、考えたことをラフなメモ書き。 【参考】 「チケット駆動開発」の適用について考える|コラム「ITよもやま話」|特集│株式会社JS... http://t.co/JE12CXBsDe"

実際のシステム開発では、プロジェクトリーダーが引いた理想的なガントチャート通りに進むことはなく、むしろそこからこぼれ落ちた数多くの細かな作業・障害・課題の管理の方が重要だ。
それらを漏れなく、1つずつ解決していくことで、納期が見えてくる。

そんな時に、きれいなガントチャート管理にこだわるよりも、泥臭く一つずつチケット管理してこなしていく方が、リスク対策になると思う。
但し、Excelとチケット管理の二重運用になるので、面倒な部分はある。

【3】上記では、ステルス駆動でRedmineを運用してきたことで、アジャイルな雰囲気が出てきた、という話があった。
おそらく、チケットで作業が見える化され、チケットがどんどん消化されていく様子なのだろう。

それは、Redmineの導入時に目指していた当初の目的とは違うかもしれない。
でも、そういうRedmineの副作用こそが、面白い点だと思う。

良いツールは、想定していなかった数多くのメリットや効果をもたらしてくれる。
そういう副作用をもっと調べて整理してみたいのだ。

【4】他に、会社で標準Redmineがあるけれども、自分たちのチームに合ったRedmineを陰でこっそり導入するという「野良Redmine」「闇Redmine」という症状もあった。
つまり、会社内に複数のRedmineインスタンスが存在している状況になる。

ステルス駆動開発では、複数Redmineインスタンスの運用も含まれるのだろうか?
もちろん含まれるだろう。

ステルス駆動開発で生まれた野良Redmine、闇Redmineは良いものなのか? 悪いものなのか?
以前考えたことをふりかえると、状況によって評価が違うのだろう。

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

気象庁の数値予報課におけるRedmine利用事例: プログラマの思索

【その他】
「ほげほげ駆動開発」を調べた人がいたので、リンクしておく。
もちろん「チケット駆動開発」も含まれている笑

○○駆動開発(xDD)がどれだけあるか調べてみた - shouhの日記

【追記】
門屋 浩文さんのツイート: "最近の話ですがなかなかredmineを準備しないが、このままではヤバイ案件があり自分の把握のためにチケット化して成果物とのヒモ付けを毎日してたらそのまま使われ始めました まずは第一歩… "

門屋 浩文さんのツイート: "まあ、そのプロジェクトは利用経験者も効果も知ってるメンバーが多かったので時間の問題なだけでしたが 自己把握にも使えるredmine(笑… "

akipiiさんのツイート: "僕は、ステルス駆動開発、とか、こういうネーミングが好きです。名前付けされると、今まで経験してきた暗黙知を他人に説明しやすくなる。喩え話で使えるし、Redmineをステルス駆動、と言えば、イメージしてもらえるし。パターン言語につながります。… "

| | コメント (0)

チームの開発環境が開発プロセスの品質を向上させるのに導入されない理由

以前のSQIP2016で、チームの開発環境が開発プロセスの品質を向上させる点を指摘していた資料があったのでメモ。
そこから、未だにチームの開発環境が導入されない理由も考えてみた。
途中で書きかけなので、後で書き直す。

【参考】
モダンなチーム開発環境を追求しよう : SQiPシンポジウム2016 SIG8 - MassKaneko.Out

(引用開始)
チーム開発 とはソフトウェア開発における技術分野の呼び名であり、"チーム開発実践入門(技術評論社, 2014)"*1 の発刊を機に日本で普及している技術分野名だと思います。バージョン管理・課題管理・継続的インテグレーションなどの技術分野をひとまとめにしているのが特徴で、組織的におけるソフトウェア開発のワークスタイルを大きく決定づける技術分野だと考えています。国際的に "チーム開発" と同義の用語が存在するか確認が取れていませんが、ソフトウェアライフサイクルプロセスの規格である ISO/IEC 12207 におけるサポートプロセスと多くの技術領域が重なります。

ここ5年くらいの国内のチーム開発分野におけるトレンドを振り返ると、チケット駆動開発, Pull Request, 継続的インテグレーション, ChatOps が思い浮かびます。例えば2012~2013年には国内大手/有名サービス企業においてGitHub Enterprise の導入事例が報告され*2、SlideShare にてツールの名前で検索すると、カンファレンスや勉強会における企業からの発表資料が多くヒットします。

一方、SQiPシンポジウムはソフトウェア品質を扱うシンポジウムであり、企業での事例が毎年20件以上報告されるのですが、チーム開発技術にフォーカスをあてた発表は何年か振り返っても多くは見当たりません。本文執筆時点で公式ウェブサイトでは2009年からの発表資料・論文が公開されていますが、それらのうち私から見てチーム開発技術にフォーカスをあてている、またはチーム開発のツールが発表内容に大きく関係していると判断できるものは5件でした。
(中略)

私は経験上、チーム開発技術は品質向上に大きく寄与し、数あるソフトウェア工学技術の中でも優先的に取り組むべきものと考えておりますので*3、なぜSQiPシンポジウムではチーム開発の発表が少ないのだろうと疑問を持ちました。理由として "もう当たり前で語ることが少ない" ということも考えられますが、「いや、絶対そのようなことは無いし需要はあるはずだ。」と信じてSIGを主催することにしました。
(引用終了)

【1】僕は、「私は経験上、チーム開発技術は品質向上に大きく寄与し、数あるソフトウェア工学技術の中でも優先的に取り組むべきものと考えております」という意見に、完全同意だ。

製造業の品質管理に影響を受けすぎている人達は、Excelドキュメントによる標準プロセスの構築ばかりに意識が行きたがる。
しかし、そのやり方が実際の案件で作業にブレーキを掛けたり、逆にシステムの品質を向上させない症状を生み出している現場を色々見てきた。

むしろ、チームによる開発を支援する共通基盤を準備した方が、開発スピードも早くなるし、品質向上にも役立つ結果になる。

では、なぜ、彼らはチーム開発の開発基盤を構築して運用する方向に目が向かないのか?

【2】いくつかの理由が考えられる。

【2-1】開発環境の構築に投資する発想がない。

開発基盤を作ると、保守コストがかかる。
日本のプロジェクトマネージャには、開発環境に投資する、という発想がない。
管理コストに投資する発想がない。
案件をまたいだ共通の開発基盤に投資する場合、社内の稟議申請が必要になり、経営層を納得させるだけの理由が作りにくく、普通は通りにくい。

但し、OSSの開発基盤ならば、プロジェクトマネージャに技術力さえあれば、自身の人件費以外はほぼ無料で導入できる。

【2-2】従来通りの開発スタイルによる過去の成功体験があるから

以前、新しい開発ツールを導入して失敗した経験がある。
新しい開発ツールの考え方に慣れることを嫌う。

特に、有償のパッケージ製品には、販売元の会社のプロセスが埋め込まれている為、現場のプロセスにはなかなかフィットしない。

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

標準化作業は、SDCAの考え方。
つまり、誰もがいつ、どこでも同じ作業をやれるような仕組みを標準として定め、その標準に従って、DCAを回すべき、という発想。

PDCAサイクルとSDCAサイクル【品質改善と維持管理の考え方】

この標準化の考え方は、工場のブルーカラー、外食チェーンや他店舗展開の小売業の作業者、コールセンターやサポートデスクのオペレータの管理には向く。
しかし、IT技術者のようなクリエイティブな人には向かない。

アジャイル開発は常識だ: プログラマの思索

なぜなら、IT技術者である限り、最新技術のキャッチアップは必須。
よって、過去の経験が全てクリアされて、一から学習し直す覚悟がいる。
しかし、その学習コストを各自で責任を負うのはハードルが高い。

【2-3】既に投資した社内ツールを捨てられないから

社内に既に、内製化したツールがある。
従来の社内ツールを捨てられない。
従来の社内ツールに、数多くのプロセス資産が蓄積されているので、埋没コストになる。

一般に、2000年頃にBTSが必要と認識した、レベルの高い会社で、そういう社内ツールを内製化した場合が多い。
しかし、OSSの発展に比較すると、UIが古かったり、機能改善が追いつかず、OSSよりも機能が劣っている場合が多い。
なのに、社内ツールを廃棄すると、埋没コストになるから捨てられない。

Redmine運用の感想を集めてみた: プログラマの思索

Sean Osawaさんのツイート: そういうのってホントにあるんだなぁ〜 RT @sonoyu670 あるお客さんのところでは「それredmineでええやん」という使い勝手の悪い独自のPJ管理システムを持ってて、これウン千万とかかけて作ったんだろうな、馬鹿だな、って思ってた。

(引用開始)
フリーのBTSがまだ普及していない頃、障害管理やタスク管理の重要性に気づいた会社は独自でBTSやITSを作り込んでいた。
そういう会社は先見の明があったに違いない。
だが、長年使ってくると、オープンソースのBTSやITSの方が普及してかつ高機能になって、逆に足枷になっている場合が見られる。
システムを長く使うのか、それとも新しいシステムにリプレースして移行するのか、判断が難しい。
(引用終了)

すなわち、組織変革の障害になりうる。
結局、変革に対抗する力となり、組織慣性として惰性のまま現状維持が続く。

埋没コストとは・意味|MBAのグロービス経営大学院

サンクコスト(埋没費用)とは | カイロスのマーケティングブログ

【2-4】開発環境は衛生要因であり、動機づけにつながらないから

開発環境が導入済みだとしても、動機づけにつながるとは限らない。
環境がなくても、従来通りやり続けてきた。

一方、優秀なチームでは、開発環境が導入されていないと、モチベーションを落とす。
むしろ、開発環境は導入されていて当たり前。
つまり、開発環境の導入は衛生要因であり、動機づけ要因にならない。

ハーズバーグの動機づけ・衛生理論 |モチベーション向上の法則

ハーズバーグの二要因理論 ? リーダーシップインサイト

【2-5】チームの成熟度が低く、Redmineを使いこなせないから

開発環境が既に用意されているとしても、上手く使いこなすか否かは、チームの成熟度に依存する。

ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか: プログラマの思索

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

チームの成熟度に対するPMOの支援度合いは、リーダーシップの状況適合理論(SL理論)で説明できるのではないか。

2/4 リーダーシップは部下の成熟度で変化させる [リーダーシップ] All About

SL理論 ? リーダーシップインサイト

SL理論(状況対応型リーダーシップ) | マネジメントオンライン

たとえば、チームの成熟度が指示待ち人間のレベルである場合、Redmine導入と運用は、RedmineエバンジェリストやRedmine警察の役割の人達が、逐一メンバーにコマンドコントロールする必要がある。
つまり、PMOは指示型リーダーシップを発揮して、チームに相当介入せざるを得ない。

一方、チームの潜在能力は高く、Redmineのような新規ツールを欲しているならば、RedmineエバンジェリストやRedmine警察の役割の人達は、コーチングや運用支援のようなスタッフ的な立ち位置で支援すればいい。
つまり、PMOは、コーチングのような説得的リーダーシップ、参加的リーダーシップを発揮して、チームを支援すればいい。

最終的には、チームの成熟度が自律的になっていれば、PMOは委任的リーダーシップ、つまり、サーバントリーダーシップに似たリーダーシップを発揮して、チームにRedmine運用そのものを委任すればいい。

そうなると、各チームは自チームに特化したRedmineが欲しくなるので、チームごとに複数のRedmineインスタンスを提供する方式になるのではないか。
つまり、野良Redmineが普通の状況になるかもしれない。

個人的には、現代において、PMOが教示的リーダーシップ、指示的リーダーシップを発揮してチームをコマンドコントロールしなくてはならない状況は相当減っているはず、と思う。
ネット上に情報もたくさん流れているので時代の方向性は理解できるし、若い人ほど潜在能力が高いように感じるから。

【3】他にも色々考えてみる。

【追記】
akipiiさんのツイート: "個人的には、@MadoWindahead さんがPMOでチームに関わる立場はSL理論でどのポジションにいるのか、知りたいかな。指示的リーダーシップはさすがにないと思うし、委任型リーダーシップであれば、そもそもPMOがチームに関わらなくてもいいので、説得的または参加的リーダーシップかなと推測。… https://t.co/lg3gcKgLZ7"

門屋 浩文さんのツイート: "指示型は敢えてやらず 説得と参加、不安の軽減、やってみせて、効果を感じてもらうことかなあ サーバントリーダーシップはどこまでできてるかの評価は分かれるところかも… "

| | コメント (0)

2018/02/28

2018年初頭におけるRedmineの動向に関するメモ

Redmineに関するアイデアを書こうとしていたら、アイデアをまとめきれず、どうしても筆が進まないので、思っていることを箇条書きでラフに書く。

【1】Ver4.0のリリースに向けて、リリースの足音が聞こえてくる

最近のRedmine本家では、 @g_maeda さんが積極的にコミットされている。
今まで3ヶ月おきにリリースされた運用を振り返ると、次回リリースでVer4.0がリリースされるのが望ましい。
Rails5に対応できれば、新しい機能追加の提案がより活発になるだろうからだ。

/ - リポジトリ - Redmine

たとえば、Ver4.0では、数多くのガントチャート改善の機能がすでに盛り込まれている。
日本のRedmineユーザはガントチャートが大好きなので(笑)、Ver4.0が早くリリースされるメリットはすごく大きいはずだ。

Redmineのガントチャート改善パッチに注目している: プログラマの思索

【2】Ver4.1の目玉機能は、添付ファイルの全文検索の機能追加

Redmineの次々期メジャーバージョン4.1で、一番の目玉は添付ファイルや文書機能にある文書を全文検索できる機能追加パッチだろう。

Feature #306: Full Text Search of files - Redmine

この機能が実現されれば、Excel設計書やパワポの提案書をRedmineに全て集約することで、Redmineをナレッジシステムにできる。
つまり、Redmineにあるチケットデータ(過去の障害、課題、レビュー記録等)、Redmineにある添付ファイル(障害のエビデンス、レビュー記録、設計書、システム提案書など)がRedmineサーバーに全て集約されたら、過去の障害履歴や仕様変更の履歴は、いつでも検索すれば見つかるようになる。

よって、チケットに詳細に内容を書いたり、ファイルを添付するというインセンティブがRedmine利用者により働くようになるだろう。
なぜなら、Redmineはナレッジシステムとして便利になる動機づけになるからだ。

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

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

さらに@clearcode さんの全文検索プラグインを追加すれば、Redmineで全文検索するメリットがより際立つはず。
なぜなら、この機能が実現されると、大量のExcelファイルがRedmineサーバー上にアップロードされるため、Redmine標準の全文検索機能では処理性能に不安が出てくるだろうが、@clearcode さんの全文検索プラグインによって、検索の処理性能の問題は解決できるし、PageRankのように有用な検索結果を優先表示してくれるので便利になるからだ。

Full text search - Plugins - Redmine

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

Redmine大阪 第17回勉強会 - 全文検索でRedmineをさらに活用! #RedmineOsaka - ククログ(2017-08-27)

但し、この機能が実現された時の課題として、機能改善が遅々として進まないRedmineの文書管理機能があがってくるだろう。
Alefrescoみたいに、Excelファイルを文書画面上でD&Dでアップロードできたり、簡単にフォルダ分けやカテゴリ分け、ランク付けできるような機能が欲しくなってくる。
たぶん、DMSFプラグインみたいな文書管理機能を実現したくなるだろう。

DMSF - Plugins - Redmine

他にも、ファイル機能(ファイルをダウンロードできる機能)をもっと使いやすくすべき、という方へ影響を受けると思う。

【3】RedmineもJenkinsやiPhoneアプリみたいに自動アップデート可能にできるか?

【3-1】@acha_821 さんが以前、RedmineもJenkinsみたいに自動アップデートする仕組みが欲しいと言ってた。
理由は、RedmineのバージョンアップやRedmineのプラグインのインストールにつまずく人達が多いから。

あさこさんのツイート: "redmineにも、アップデートセンター入れてほしい。… "

あさこさんのツイート: "あわわわわわ… 川口さんが、jenkinsはアップデートセンター入れてから爆発的に広がったと言っていたので、同じような経路をたどるかもしれませんね。。 そうすると、redmineバージョンアップの毒沼地はいい感じで消えていってくれる…かもしれませんね(・_・;)… https://t.co/tSddJPec3O"

akipiiさんのツイート: "似た話として、Gitlabにはrakeコマンドで自動バックアップするコマンドがあった気がする。Redmine と同じRailsアプリならば、他ツールの機能をパクるやり方もありですね。… "

実際、Twitterでも、Redmineのインストールは難しい、というツイートがすごく多い。
個人的には、BitnamiやDockerでインストールするのが一番簡単と思うが、バージョンアップは結局手作業になる。

Install Redmine, Download Redmine

Docker for Windowsでredmineを動かす - Qiita

また、Rubyに慣れていないために、環境構築という最初の設定手順でつまずいている人が多い。
だから、Redmineの普及のためには、iPhoneアプリみたいにRedmine本体を自動アップデートできる機能が課題になるだろう。

ここで、JenkinsはWarという単一のコンポーネントで配布されていて、DBを持たない仕組みなので、インストール自動化やバージョンアップ作業を自動アップデートする仕組みに実現するのは簡単だ。
一方、RedmineはRuby本体をインストールする必要があるし、Redmine本体はWarのようなコンポーネントで配布されていないし、約50個ほどのテーブルももつので、自動アップデートする機能を実現するのはそう簡単ではないだろう。

【3-2】但し、Redmine本家では、プラグインをGem化し、Gemfile.localにプラグインのバージョンも指定する方法のパッチが提供されているので、改善できるかもしれない。

Feature #27705: Gemify redmine plugins - Redmine

【3-3】また、EasyRedmineという海外の会社が、Redmine本体やRedmineプラグインを画面上から自動アップデートできるような仕組みを実現するプラグインを公開している。
まだ試してないので詳細は分からないが、このプラグインで本当にRedmine本体やRedmineプラグインの自動アップデートが実現できるならば、ぜひ、Redmine本家でも取り入れて欲しい、と思う。

Redmine Installer - Plugins - Redmine

Redmine Plugin Generator - Plugins - Redmine

Entity Generator - Plugins - Redmine

easyredmine/redmine-installer: Easy way how to install/upgrade Redmine or plugin.

easyredmine/redmine_entity_generator

easyredmine/plugin-installer: Plugin into Redmine to easily handle installing and upgrading Redmine

Rake tasks - GitLab Documentation

【3-4】なお、同じRailsアプリGitlabには、バックアップやリストアなどはrakeコマンドで自動化出来る仕組みがある。
DBバックアップなどは日次バッチ化しておきたいから、Cronで設定しておけばいい。

同様の機能をRedmineにも実装できないか?
さらに、プラグイン更新やバージョンアップのような機能もrakeタスクでバッチ化できないか??

Rake tasks - GitLab Documentation

GitLabのバックアップとリストア - Qiita

【3-5】個人的には、Railsフレームワーク本体が、Warのようなコンポーネントで配布できるような機能を実現すべきではないか、と思う。
つまり、Redmineの自動アップデート機能が欲しいという要望は、Redmineの問題ではなく、Railsフレームワークという下層のレイヤの問題であると思うからだ。
なぜなら、他のRailsアプリでも、同様の課題を持つはずと思うからだ。

この辺りも色々考えてみたい。

| | コメント (0)

2018/02/21

Redmineのアンチパターンは2種類に区別できるのではないか

以前、Twitterで、日付カスタムフィールドに関するRedmineのアンチパターンが議論されていた。
その議論を読みながら、Redmineのアンチパターンには、プロジェクト管理の要件のブレかフィットギャップ分析の甘さの2種類に区別されるのではないか、と考えた。
ラフなメモ書き。

【問題の発端】
nekosanzさんのツイート: "難問。1つのプロジェクトではなく、1つのチケットにマイルストーンがほしい。こんなこと言われたの初めてだ"

門屋 浩文さんのツイート: "チケット割るか説明に書く!… "

nekosanzさんのツイート: "結論が日付カスタムフィールドを10個ぐらい追加してほしいという炎上物件… "

【問題の真因を突いている議論】
neta@筋肉 筋肉???さんのツイート: "Redmine の日付カスタムフィールドはあかん。ウチも『期日』という名称が気に入らなかったらしく、『希望納期』という残念なカスタムフィールドを作ってしまった。ガントには出ねーわ、リマインダーは効かないはマイッタマイッタ。今は反省している… https://t.co/MSqH2RmwwQ"

門屋 浩文さんのツイート: "日付のカスタムフィールドはあまり良くない 標準のガント使わなくなったのが実績日が出てこないからという理由なので… "

【アンチパターンに関する感想】
akipiiさんのツイート: "久しぶりにRedmine のアンチパターンを集めたいですなぁ笑… "

nekosanzさんのツイート: "みなさんおっしゃる通り。コミュニケーションツール不在の会社にRedmine 導入するとアンチパターンの温床になりえますね。… "

akipiiさんのツイート: "アンチパターンの種類にも、プロジェクト管理の要件を詰めきれてないことと、Redmine の機能を理解しておらずフィットギャップ分析が甘いこと、があるから区別したいな。… "

【1】チケットにマイルストーンが欲しい、という要望を元に、Redmineに日付カスタムフィールドを10個も追加してしまった、という事例。

おそらく、障害管理票、課題管理票のような類の帳票をチケット化した時、数多くの異なる日付を入力する必要になったのでは、と勝手に推測する。

しかし、上記の指摘の通り、Redmineチケットの「期日」を使わなくなると、ガントチャートに表示されないし、リマインダーのメール通知機能も使えなくなる。
よって、本来は、チームの要望にある「日付」の概念をRedmineの「期日」に合うように修正すべきだったのだろう。
あるいは、ja.ymlにある「期日」の文言をチームの組織文化に合った文言、たとえば「納期日」などへ修正しても良かっただろう。

【2】そういう話をふりかえると、Redmineのアンチパターンには、2つの観点で綺麗に分類できるのではないか、と思う。

【2-1】一つは、プロジェクト管理や開発プロセスの本来の設計思想に関する理解が浅いために、プロジェクト管理の要件を詰め切れていないこと。

よくある例は、WBSは工程単位に作るべきなのか、機能単位に作るべきなのか、どちらがいいのですか、という質問が相当するだろう。
この質問に関しては、下記の記事で明確に回答が述べられている。

WBSはプロジェクト組織を規定する : タイム・コンサルタントの日誌から

WBSはコスト見積の基準を規定する : タイム・コンサルタントの日誌から

WBSの作り方はプロジェクト型組織の構造を決めるという考え方はRedmineチケット管理にも通じる: プログラマの思索

また、「チケット無しの作業不可」の運用ルールの理解が浅いために、作業履歴やレビュー履歴をチケットに残してナレッジを蓄積し、最終的にはプロセス資産になる、という思想まで考えが及ばない、という話もあるだろう。
その他にも、チケットの棚卸し、トレーサビリティなどの話も同じ論点ではないか、と思う。

つまり、Redmineのようなチケット管理ツールとは無関係な観点で、プロジェクト管理や開発プロセスの理解が甘いために、RedmineやJiraであろうが、どのチケット管理ツールも使いこなせていない、という結果になるのだろう。

すなわち、この観点のアンチパターンは、ツールとは無関係な一般論に近いレベルまで昇華できるだろう、と思う。

【2-2】もう一つは、チームの開発プロセスの要件とRedmineの機能について、フィットギャップ分析が甘いこと。
これは、今回の日付カスタムフィールドの話に相当するだろう。

他に、親子チケットの作り方、ロードマップの使い方などもあげられるのではないか。

【事前公開】【第16回Redmine大阪】RedmineのFAQとアンチパターン~親子チケットの功罪: プログラマの思索

Redmineの親子チケットの功罪: プログラマの思索

最近よく聞くRedmineのFAQ~Excel添付のチケットから野良Redmineまで: プログラマの思索

最近なら、デブサミ2018のRedmine利用事例の講演でも、アンチパターンに関する話があった。
その中で、@g_maedaさんの下記の話は、Redmineにおけるトラッカーを使いこなせていないアンチパターンがある事実を示唆している。

MAEDA, Goさんのツイート: "最近は、トラッカーの追加とは入力フォームを設計して追加することだと説明するようにしています。… "

つまり、Redmineに埋め込まれた本来のチケット管理の機能要件を理解できていないために、Redmineの優れた機能を発揮できない結果に陥る、という結果があるだろう。

すなわち、この観点のアンチパターンは、Redmineの設計思想とユーザが利用したい要件に関して、Redmineのフィットギャップ分析が甘い点に原因があるだろう、と思う。

【3】では、Redmineのアンチパターンを「プロジェクト管理や開発プロセスの一般論」と「Redmineのフィットギャップ分析」で分類したら、どんな面白い内容が出てくるだろうか?

【3-1】まず、僕は、「プロジェクト管理や開発プロセスの一般論」のアンチパターンは、Redmineが機能豊富になるにつれて、最終的にはどんどん難易度が高くなるのではないか、と思う。
一般論の話は、実際にチケット管理して経験して、失敗したり、成功してみたら、すぐに理解できて解決できる。

よって、Redmineに上手く当てはまれば解決できるアンチパターンは、Redmineが誕生して10年経った今、知見やノウハウとして、普通の経験者は理解できているだろう。
そして、じきに、本来のユーザ利用要件をRedmineに当てはめられなくなった、というレベルまでたどり着いて、改めて考えなくてはならない、という方向に落ち着くだろう。

つまり、一般論の話で解決できないアンチパターンは、ソフトウェア開発やソフトウェア工学に関する本質的な問題まで辿り着くのではないか、と思う。

たとえば、チケットの粒度に関する議論は、ソフトウェア工学における「ソフトウェアの本質的な複雑性」に由来するがゆえに、そう簡単に解決できる話ではない、と思っている。

チケット駆動の罠~複雑さはチケットの粒度に関連している: プログラマの思索

【3-2】一方、「Redmineのフィットギャップ分析」のアンチパターンでは、Redmineの標準機能で解決できる事例はどんどん公開されてしまい、最終的には、Redmineをカスタマイズすることでしか解決できないアンチパターンが多数出てくるだろう、と思う。

たとえば、最近よく聞くRedmineのFAQ~Excel添付のチケットから野良Redmineまで: プログラマの思索でもあげたが、ロードマップ画面におけるチケットの並び順をドラッグ・アンド・ドロップで制御する機能パッチは、アジャイル開発におけるプロダクトバックログ管理に相当する機能なのに、未だに実現されていない。
つまり、先進的なアジャイル開発のプラクティスをRedmineで運用したい、と思っても、Redmineの標準機能では不足しているのだ。

他に、MSProjectみたいにRedmineのガントチャートを使いたい、とか、色んな要望が出てくるだろう。

つまり、「Redmineのフィットギャップ分析」のアンチパターンを完全に解決するには、Redmineにプラグインを導入したり、Redmineそのものをカスタマイズする、という方向性が必要になる事例が数多く残ってくるのではないか、と思う。

【4】個人的には、Redmineのアンチパターンを上記の2種類の観点で区別した時に、下記のテーマがあると思う。

(1)既によく知られているアンチパターンは、上記2種類のどちらに分類されるか?

(2)未解決のアンチパターンの原因は、上記の考え方で合っているか?
そして、解決の方向性も、上記の考え方で進められるか?

この辺りも色々考えてみたい。

| | コメント (0)

2018/02/04

第18回Redmine大阪の感想 #RedmineOsaka

第18回Redmine大阪の感想をメモ。
疲れているので、ラフなメモ書き。
書きかけなので、また後で書く。

【参考】
第66回 SEA関西プロセス分科会&第18回 Redmine大阪 - connpass

2018/2/3 第66回 SEA関西プロセス分科会&第18回 Redmine大阪 - Togetter

第18回Redmine大阪のまとめ | MadosanPlace 新しい風をプラス!

【1】気象庁のRedmine利用事例の話は、本当に面白かった。
JAXAのRedmine運用とは、また別の観点の思想を持って運用されている。

第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」の感想: プログラマの思索

第13回東京Redmine勉強会の感想~『Redmineの今と未来』 #redmineT: プログラマの思索

気象庁内のシステムには、天気の予測シミュレーション、PM2.5やら色んな気象データのデータ収集と分析、シミュレーションなどがある。
それらのシステムは、全て内製化されている。
つまり、気象庁の研究者がプログラマとなり、実際に開発している。
この点は、JAXAなど他の官公庁とは全く違う。

だから、気象庁では、数値予報官という役職だけでなく、「プログラマ」という名前の役職も公式に存在する。
この点も他と大きく異なるのだろう。

【1-1】気象庁内では、Fortran、シェル、Rubyが一般的なプログラミング言語。
数値予測などの科学計算は過去の開発資産があるので、Fortranが使われている。
一方、仮想サーバー構築、バッチ処理、インフラ構築などは、シェルとRubyがよく使われている。

【1-2】気象庁では、部署もあるが、開発はシステムごとに、各部署を横断してプログラマや研究者が集まって担当する。
そのシステムに携わる集団を開発コミュニティと呼ぶらしい。
僕の理解では、マトリクス型組織のように思えた。
つまり、研究者やプログラマは部署に所属するが、天気予報、シミュレーション、共通基盤などの各システムの開発に携わるので、クロスファンクショナルなチーム構成になる。

但し、プログラマはどこか一つのコミュニティに属する運用になっているので、複数のコミュニティに所属することはほとんどない。
つまり、各開発コミュニティは縦割り組織に似たような雰囲気になっているみたい。

【1-3】最近は、欧米の気象庁ではPythonを使って数値予測プログラムを書く事例が多くなってきたので、彼らから、なぜまだFortranを使っているの、Pythonなら他言語のライブラリや資産も簡単に呼び出して使えるので、Pythonがいいよ、と言われているため、Pythonをこっそり試し始めている、とのこと。

この辺りの話を聞くと、海外の研究動向にも追随しながら、最先端の技術を導入しようという雰囲気が既にあるのだろう。

【2】気象庁では、各開発コミュニティごとに「あえて」Redmineインスタンスを複数個立ち上げた意図

バージョン管理は、2000年代からCVS、Subversion、Gitへ移行してきた。
2008年頃から、各コミュニティが独自にTracやRedmineを使い始めた。
原さんが海外の動向を踏まえて、各開発コミュニティがバラバラな開発基盤を持つのではなく、共通の開発基盤で運用すべきだ、と提案して、2014年頃から、RedmineとSubversion、Gitを共通の開発基盤として各コミュニティに提供する運用になったらしい。

その時、1台の物理サーバーに1個のRedmineインスタンスで運用する案も考えられたが、一つのRedmineの運用ルールに縛ることを目的とすると、各開発コミュニティから反発が起きるかもしれないことと、各開発コミュニティの組織文化を尊重することも考慮して、複数個のRedmineインスタンスを各開発コミュニティごとに立ち上げることになったらしい。

【3】2段階コードレビューの意図

【3-0】Redmineを導入した動機

そもそも、RedmineやSVNを開発基盤として導入しようという契機になったのは、コードレビューをしっかりやるべきだ、という考え方が、原さんだけでなく、各開発コミュニティでもそのような気運が盛り上がっていたから。

たとえば、天気予報の数値予測シミュレーションのようなプログラム開発では、理論物理や流体力学など科学理論から導かれる機能要件から、それに基づくプログラム実装が行われる。
しかし、かつてはバージョン管理すらなかった時代では、なぜそのような機能が実装されたのか、なぜそんなソースコードになったのか、記録が残っていない。
しかも、科学理論の発展やソフト・ハードの進化に伴うプログラム修正の履歴やその変更理由も残されていない。
だから、システムのリリース後に障害が発生して、トラブルが起きることがあったから。

【3-1】2段階コードレビューの意図

Redmineではコードレビューのプロセスはワークフローの一部として運用されている。

興味深い点は、気象庁のコードレビューでは、2段階レビューが踏まれていること。
まず、サイエンティフィック・レビューでは、科学者の観点で、数値シミュレーションが物理法則や物理の理論に基いた要件でコードが実装されているか、レビューされる。
おそらく、研究者同士の議論に近い雰囲気なのかもしれない。

次に、ソースコードがプログラミングの観点できちんと書かれているか、という立場でコードレビューされる。
Fortranのコーディング規則に従っているか、エラー処理、とか、この部分は我々のコードレビューと同じだろう。
また、物理法則の要件に従って実装されたプログラムを、実際に膨大な気象データに基いてシミュレーションするテストも行う。
このテストには、半日で終わることもあれば、数週間かかることもあるらしい。

たとえば、そこで性能が出なかったりすることが分かれば、その要件の実装はソフトウェア的に実現可能性が低いので、別の代替案を考える、などのフィードバックがコードレビューで行われる。

つまり、単なるコーディング規約のチェックだけでなく、たとえば性能要件を満たすかテストしてみた結果をフィードバックする、などの作業も行われている。

この辺りは、アーキテクチャのフィージビリティ・スタディ、つまり、アーキテクチャ実装のコスト・品質・納期のトレードオフを評価しているのと同じように思える。

これら2段階レビューは、既に欧米の気象庁では行われているので、日本でもやるべきだ、という提案があり、徐々に浸透しているらしい。
そういう内容を聞くと、Redmineチケットにコードレビューの結果を記録し蓄積していくことは非常に有意義な作業であることが理解できる。

【3-2】そして、git-flowによる並行開発とコードレビューが組み合わされて、上手く運用されるようになっているらしい。
つまり、ある要件を開発する場合、trunkからブランチを派生し、そのブランチ上で修正して、コードレビューが完了になれば、trunkにマージされる。
そのブランチはRedmineチケットと対応付けられて、Redmineチケットに要件や仕様、コードレビューの結果などが全て記録される。

【3-3】気象庁のRedmineでは、チケットのカスタムフィールドは使わないし、複雑なワークフローも設定されていないし、プラグインもほぼない。
Redmineのチケットに、コードレビューの指摘、結果、対応の記録を残すことに注力している。
そのおかげで、海外派遣で2年間、気象庁から離れた研究者も、帰国した後、Redmineのチケットを検索するだけで、すぐにプログラム開発の仕事に復帰できた、と言っていたらしい。

つまり、気象庁のRedmineは、進捗管理用のRedmineではなく、ナレッジ資産の為のRedmineなのだ。

【4】複数個のRedmineインスタンスで運用されるデメリットは、原さんによれば特に感じていない、と言われていた。
もし、他コミュニティのRedmineを参照したい場合、RedmineにはRSS機能があるので、RSSをフィードすれば、リアルタイムにチケット更新の状況を把握できる。

【4-1】また、Redmineという開発基盤が普及した後、Redmineの副次効果がいくつかあったらしい。
たとえば、あるコミュニティで、コードレビューはプログラム実装後に行うのではなく、プログラム実装前に関係者が集まって事前に内容を協議する運用を始めた所、他コミュニティでも、その運用はもっともだ、という意見があり、他コミュニティにも徐々に反映されたらしい。

つまり、あるコミュニティのRedmineのベストプラクティスが他コミュニティにも自然に横展開された、という事実を示唆している。

また、気象庁がいくら先進的な官公庁であっても、やはり役所なので縦割り組織の雰囲気がある部分はある。
しかし、Redmineを利用することで、コミュニティ内では、チケット経由のやり取りによって、研究者の知見やソース修正の履歴が記録されて、メンバー間の情報共有がスムーズになったらしい。

【4-2】さらに、データ処理など共通の処理を行う基盤担当のコミュニティがあり、そのコミュニティは気象庁の各コミュニティと関係するが、そのコミュニティのメンバーは、各コミュニティのRedmineにログインできる。
すると、各コミュニティでRedmineやコードレビューの運用ルールが微妙に違うので、同じように運用したい、という声が上がっているらしい。

つまり、現状はあえてコミュニティ単位の複数Redmineインスタンスで運用しているけれど、現場から、ボトムアップでRedmineの標準化を図るべきだ、という声が上がっているわけだ。
将来は分からないけれど、いつか、単一の標準Redmineにサーバー統合される可能性があるかもしれない。

【4-3】この点に関して、参加者からは、Redmineではトラッカーやカスタムフィールドがグローバル変数のような性質のために、使いづらくなっている。
Redmineにも、サイトのような機能を持たせて、各プロジェクトごとのトラッカーやワークフローを定義できるようにすれば、一つのRedmineインスタンスで、各プロジェクトごとにトラッカーやワークフローの自由裁量の権限を与えて運用できるのではないか、という指摘があった。
この意見は全くその通り。

以前も、東京Redmineでも似たような議論があった。

Redmineのワークフロー設定を拡張する機能提案~Redmineは汎用的なBPMツールになりうるか: プログラマの思索

【4】個人的には、Redmineは単一インスタンスの運用だけでなく、複数インスタンスの運用もベストプラクティスの一つになりうる、という発見があって、改めて深く考えさせられた。
この点はまたまとめる。

akipiiさんのツイート: "#RedmineOsaka #seakansai 気象庁の事例ではRedmineをナレッジ基盤として使う運用を目的としたら、色んな副次的効果も出てきた。単一の標準Redmineがベストの先入観があったけど、Redmine の複数インスタンスでも成功事例があるのは改めて衝撃を受けた。奥が深いね。"

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

【追記】
今回のRedmine大阪で、気象庁における開発管理の取り組みの公開資料に基いて、Redmineのチケット管理やGitによるブランチ管理やコードレビューについて数多く質問したのだが、「テストハーネスを用いたテスト自動化」の内容は聞き漏らしてしまった。
おそらく、Fortranプログラムをシェルからバッチで起動して、入力データと出力データを差分比較するようなテストを自動化する仕組みを取り入れていると思われる。
この部分のノウハウも聞きたかった。

気象庁における開発管理の取り組みの公開資料のP.52で下記の引用がある。

(引用開始)
asuca については、トランクへの変更がなかった場合も含めて、テストハーネスと呼ばれる仕組みを毎日自動で実行している。
これは
・ 理想実験
・ 石田ほか (2014) で述べられている、2 次元定常山岳波、周期境界条件における重力波、暖気塊のテスト、重力流、St-MIP
・ 静止大気実験
・ 2 次元スカラー移流
・ 3 次元モデル 3 による狭領域実データ実験
・ 局地解析
・ 接線形モデルチェック
・ 随伴モデルチェック
・ 局地予報
・ メソ予報
といった様々なケースについての実験 4 が、最新のトランクを用いて行われる。
入力データは毎日同じものを用いるため、入出力システムの変更等、予報結果を本質的に変える変更でない場合には、結果はビットレベルで一致する。
自動実行されたテストハーネスの結果は毎日メールで報告され、結果が前日とビットレベルで合わない場合にはそのようなメッセージが付加され、開発者が覚知することができる。
このため、トランクへのマージを行う改変については、テストの段階で開発者が自らテストハーネスを実行し、その結果についてもチケットに記録する。
また、変更の前後で結果が一致しない場合には、その理由や差の妥当性(分布図で見た場合の評価等)も含めて、記録を行う。
(引用終了)

| | コメント (0)

より以前の記事一覧