Redmine

2018/07/04

Redmineでスケジュール調整や投票ができる「Scheduling Poll」プラグイン

Redmineでスケジュール調整や投票ができる「Scheduling Poll」プラグインを見つけたのでメモ。

【参考】
【担当者さん必見】メンバーみんなで日程調整ができる「Scheduling Poll」プラグイン登場!

cat-in-136/redmine_scheduling_poll: a plugin to provide the simple way to schedule appointments on Redmine

QA #824: チケットやニュース、フォーラム、Wikiなどで選択式のアンケートを実施したい - Unofficial Redmine Cooking - redmine.tokyo

画面を見てみると、調整さんのように複数のチェックリストに○△Xを記入した後、入力結果を自動集計してくれるみたい。

選択できるチェックリストには、日付以外にテキストが入力できるので、他のアンケート項目にも流用できるだろう。

時々、アンケート機能がRedmineにも欲しい、という声があがる時があるので、このプラグインを使えばいいかもしれない。

下記のLineの機能にインスパイアされて、Redmineプラグインを作成された、とのこと。

【幹事さん必見】友だちみんなで日程調整ができる「LINE スケジュール」機能登場! : LINE公式ブログ

こういう投票機能は、Redmineを単なるタスク管理、課題管理、障害管理だけでなく、チーム内のコミュニケーションを活性化させるためのツールへ進化させる為の機能と言い換えられる。

Rails開発の技術力があれば、自分のアイデアやプロジェクトリーダーの提案を元に、Redmineをカスタマイズすることにより、チームの一体感を生み出す機能をいくらでも作り出せる。

そういうアイデアを実現する機能とチーム内のコミュニケーションとの相関関係や影響度合いを実際に分析してみたいものだ。

| | コメント (0)

2018/06/27

Redmineにも「いいね」機能が欲しい

先日の東京Redmine勉強会のLTで「気遣いが大事」という内容に関する記事があったのでメモ。

【参考】
はじめてのredmine.tokyo勉強会参加と『エモい』Redmine - ファーエンドテクノロジー株式会社

(引用開始)
『エモい』Redmine #とは
後日、マーケティンググループのメンバーと会って話した際に、私がライトニングトークのスライドで記載していた「気遣いが大事」という点が話題になりました。

遠藤「事前にライトニングトークのスライドを見て、気遣いが足りなかったと反省したんです」

財部「逆ですよ!遠藤さんの気遣いがあるコメントを頂いて、私のほうが学んだんです」

石原「前はチケットのコメントに『ありがとうございます』とか書かなかったけど遠藤さんが書くようになって書かなきゃ!と思うようになりました」

財部「これだけでも勉強会のネタになりそうですよ、『エモい』Redmine」

例えばチケットのコメントに「◯◯してくれてありがとうございます。」と書くか否か。メールじゃないんだから、と簡潔に済ませるのか。
(引用終了)

チケットに作業ログを残すだけでなく、対応してくれた人に感謝の気持ちを伝えたくなる時もある。

Facebookなら「いいね」ボタンでその機能を実現している。
Twitterならリツイートボタンでその機能を実現している。
この機能は、マズローの欲求5段解説の承認欲求、ハーズバーグの動機づけ・衛生理論を連想させる。

すると、Redmineにも同様に、「いいね」機能が欲しくなる。
コメントに「ありがとうございます」と文字で書くのが面倒でも、ワンクリックで、感謝の気持ちを表現できるなら、そちらの機能を使いたい。

Redmineにもそういうプラグインはあるみたい。
以前、GoodJobプラグインもあったな。

Redmineに「応援する」リンクをつける: プログラマの思索

Redmineに入れたプラグイン一覧part3: プログラマの思索

akipiiさんのツイート: いいねボタンが欲しい時がある RT @hito_asa: 社内Redmine、Backlogと違って味気ないというか、スターつける仕組みもないしなんだかコミットしてて寂しくなってくるのです。スター重要。

システム構築の立場から見れば、たかが「いいね」ボタンという一つの機能に過ぎないのに、たった一つの機能「いいね」ボタンが感謝の気持ちを気軽に表現してくれることで、メンバーの貢献意欲を引き出し、チーム内のコミュニケーションを促進し、チームの一体感や使命感を醸し出す。

これまた人間の心理の不思議の一つかな。

| | コメント (1)

2018/06/21

Redmineの「トラッカー」を「チケット種別」へ変更するチケットが提案されている

@g_maedaさんが、Redmineの「トラッカー」を「チケット種別」へ変更するチケットを提案されている。
些細な内容だが、Redmineの初心者向けユーザにさらに使いやすくする重要な提案と思うので、メモしておく。

【参考】
Patch #29045: Change Japanese translation for Tracker - Redmine

【1】Redmineのチケットで最も重要な概念は「トラッカー」だ。
なぜなら、トラッカーはワークフローと表裏一体であるので、業務フローと対応付けられるからだ。
よって、トラッカーによってRedmineチケットの状態遷移が制御される。

また、トラッカーはカスタムフィールドなど、チケットのテンプレートそのものでもあるからだ。
よって、トラッカーごとに、チケットのテンプレートを設定する思想にもなる。

たとえば、トラッカーは、ソフトウェア開発のプロセス、申請承認ワークフローの業務などに対応付けられる。
それらは、特有のワークフローがあり、特有のデータ項目(カスタムフィールド)が保持されている。

【2】しかし、従来から、「Redmineのトラッカーとは何ですか?」という問合せが非常に多い問題があった。
日本人には「トラッカー」を和訳せずにそのままの名前にしたので、イメージしにくいのが根本原因にあるのだろう。

よって、「チケット種別」にする提案が@g_maedaさんから起票された。
おそらくRedmineを知らない日本人にとって、「チケット種別」という概念の方が理解しやすいだろう、と個人的に思う。
このパッチが反映されれば、日本におけるRedmineの普及促進に重要な良い影響を及ぼすだろう。
よって、パッチは些細なものだが、非常に重要な内容だ。

【3】なお、コメントでは、「ワークフロー種別」の方が良いのでは、等の意見もある。

@g_maedaさんの言う通り、トラッカーはワークフローかつチケットテンプレートの2種類の設計思想を持つので、「チケット種別」の方がその2つの概念を包含しやすいだろう、と思う。

Patch #29045: Change Japanese translation for Tracker - Redmine

(Google翻訳にて引用開始)
松本Gohさんはこう書いた:

私の意見では、トラッカーはワークフローの名前またはタイプを表しています。
だから、私は "ワークフロー"または "ワークフロータイプ別"を提案します。

ご意見ありがとうございます。でも、私はまだ「ワークフロー種別」よりも「チケット種別」が好きです。その理由は次のとおりです。

トラッカーは、ワークフローだけでなく一連のフィールドも定義します。「ワークフロー種別」(ワークフロータイプ)という言葉は、そのうちの一つしか表現しておらず、ワークフローを強調しすぎています。私は "チケット種別"(問題の種類)は両方の意味を含んでいると思います。
「ワークフロー種別」(ワークフロータイプ)はかなり長いです。問題リストを表示すると、トラッカーフィールドが広くなります。
しかし、ユーザーのために「チケット種別」(問題の種類)と「カテゴリ」(カテゴリ)を区別するのは少し難しいとのご意見に同意できます。
(引用終了)

【4】また、 Masakazu IZUIさんのメモの絵が素晴らしい。
メモでは、チケット種別(トラッカー)のチケット群を「カテゴリ」に仕分けするイメージが描かれている。

Patch #29045: Change Japanese translation for Tracker - Redmine 「「仕分け」はどう?」

このメモが素晴らしいと思う理由は、トラッカーとカテゴリの設計思想が明確に区別されているからだ。
トラッカーは全てのPJで使われる汎用テンプレートかつワークフロー設定なので、各トラッカーの各種チケットは、各PJで、PJ特有のカテゴリで「仕分け」される。

RedmineのカテゴリはPJで自由に設定できる点がミソだ。
つまり、汎用設定であるトラッカーによる分類だけでなく、PJ特有の分類方法はカテゴリを使って分類すればいい。
そうすれば、チケット集計時に、色んな観点で集計しやすくなる。

つまり、「チケット群を仕分ける」作業は、プロジェクトマネージャが従来行っていた進捗報告作りの作業である。
その手作業は、Redmineのチケット集計機能で全てシステム化、自動化できることを示唆しているのだ。

【5】なお、カテゴリ機能については、親子PJでカテゴリを継承して使えるような機能改善が下記チケットで提案されている。
最近、Yuuki NARAさんがGitHubで試されている。

Patch #11898: Inheritable issue categories - Redmine

Feature #5358: Share Issues Categories for sub-projects - Redmine

実は、Redmineのカテゴリは重要な機能でありながら、その使い道の有用性を説明することが難しかった。
カテゴリを親子PJで継承できるようになれば、親PJのカテゴリを流用できるので使いやすくなる。

個人的には、カテゴリ機能はもっと改善して欲しい、と思っている。
そうすれば、チケット種別(トラッカー)でチケットを分類する方法ではなく、カテゴリで固有のPJで分類する運用がもっと馴染むようになるだろう、と思っている。

僕はRedmineをもう10年以上使っているけれど、まだまだ機能改善したい気持ちがあるし、色んな可能性を考えるのがすごく楽しい、と感じてる。

【追記】
Toru Takahashiさんから、「トラッカー」を「チケット種別」に変更する提案に反対意見が表明されている。
その反対意見の理由を読むと、確かにもっともだ。
なぜなら、「トラッカー」には「問題や課題、障害等を追跡する」意味が含まれているので、その意味が失われるリスクもあるからだ。

Patch #29045: Change Japanese translation for Tracker - Redmine

(Google翻訳による引用開始)
私はこの翻訳提案に同意しません。

「トラッカー」には、問題のステータス変更を追跡する意味が含まれます。
「種別」には含まれていません。
さらに、「タイプ」という単語は「カテゴリ」という単語に非常によく似ています。

「トラッカー」に適した日本語を見つけるのは難しいかもしれません。
翻訳に適した単語が見つかるまで、
現在の翻訳された単語「トラッカー」は、トラッカーの代名詞を表しています。
(引用終了)

高橋 徹さんのツイート: "Redmineトラッカーをチケット種別と表記する変更案がありますが、trackerの語に含まれる追跡管理の意味が失われるのはどうかなぁ?トラッカーが解りにくいのは同意、しかし元の意味が失われる訳語には賛同しかねるなぁと。 https://t.co/bsa9AJVobj"

Kuniharu AKAHANEさんのツイート: "同じ思いです。Issue Tracking Systemの根幹要素を欠くと思っています。その一方で、Redmineの利用領域は本当に幅広いのでOSSを使う皆さんがわかりやすいというならそのまま受け入れて、自分の環境では ja.ymlの15ヵ所をを書き換えようと思っています。… https://t.co/8qxMMCao8a"

やっさん🍶さんのツイート: "#redmine 私も同様に慎重派です。 そもそもなぜTrackerとしたのか?に関してJPLには考えがあるはずなので、そこを確認してからじゃないと「トラッカー」→「チケット種別」とするのはどうかなぁと考えています。 私は@akabekobekoさんの案が良いかなぁと(話大きくなるけど)。 https://t.co/oQpoUxpCji… https://t.co/s1XppYjKZr"

| | コメント (0)

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)

より以前の記事一覧