Git・構成管理

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/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)

2019/01/11

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

GitHubが無料でプライベートリポジトリも使えるニュースが届いた。
とても素晴らしい。
このニュースは、小説家にもGitが必須になってきた事実を示唆していると思う。
以下、ラフなメモ書き。

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

【1】GitHubが無料でプライベートリポジトリも使える最大のメリットは、プライベートなドキュメントは全てGitHubで管理できることだ。
僕は、この恩恵は計り知れない、と思う。

たとえば、ブログの元ネタのメモ、Excelで作った家計簿、執筆原稿用のWord、プレゼン資料のパワポなど、全てGitHubに入れてしまえばいい。
そうすれば、日々更新するファイルは全てGitHubの履歴として管理でき、いつでもどこでも復元できるようになる。
よって、「yyyyMMdd_ファイル名」みたいなExcelファイルを一時的に作ったり、他の共有ファイルサーバーに逐一手動でバックアップしたりする作業は不要になる。

また、GitHubにはIssue管理(チケット管理と呼ばないんだね笑)、Wikiの機能も付いているので、日々のタスクをIssueにメモしたり、常に参照すべき共有情報はWikiにまとめることができる。

つまり、個人のドキュメント管理と情報管理は、今後、GitHub中心に回るようになるだろう、と思う。
プライベートPCを切り替えても、GitHubにドキュメントがあるなら、いつでも自分だけの環境を復元できるわけだ。

【2】最近の最先端の小説家は、どうやら、GitHubを使っているらしい、という記事を見かけるようになった。
文系の人達も、プログラミングしない人達も、Gitが必須になってきたように思える。

「Githubで小説? そんな時代なの?」そうなのだ。 - 景虎日記

GitHubをコーディング以外で活用する7つの方法 | readwrite.jp

世の中の小説作家と編集者は今すぐ Word や G Suite を窓から投げ捨てて Git と GitHub の使い方を覚えるべきだ - Qiita

Web小説のリリース自動化 - Qiita

【1】小説家がGitHubを使うメリットは2つあると思う。
一つは、小説というドキュメントがGitHubの構成管理の配下になることで、成果物の履歴管理の恩恵を受けられること。
もう一つは、GitHubのワークフローを受け入れることで、プルリク機能が使えて、ソーシャルコーディングならぬソーシャルライティングが可能になること。

【2-1】1点目の利点は言うまでもない。
出版業界でも、Word主体が多いが、たぶんもう時代遅れだと思う。
Wordの変更履歴機能もあるが、正直使いにくいと思う。

【2-2】2点目の利点は、小説の推敲作業にもプルリクを使うことで、小刻みな改善がスピーディに行えるようになることだ。
僕も4冊ぐらい出版したので経験があるが、1冊の本を書くには10万~20万文字くらいの分量がいる。
それだけの文章にチェックを入れて、フィードバックを反映する作業は正直面倒だ。
その反映作業を漏れなくスピーディに行うのは、GitHubのような構成管理とチケット管理の両方の機能がなければ難しい。

その時に、プルリクが使えると便利だ。
編集者は、修正すべき該当箇所を指摘するチケットを起票するだけでなく、修正パッチをプルリクで提供すれば、Masterを管理する小説家はそのプルリクを吟味した後、取り込むだけで済む。
つまり、編集者は小説を改善する開発者、小説家は小説を管理するコミッターの役割で置き換えられる。

【2-3】他に、世の中の小説作家と編集者は今すぐ Word や G Suite を窓から投げ捨てて Git と GitHub の使い方を覚えるべきだ - Qiitaで共感する箇所は、「過去に書いた文章を再利用しやすい」部分だ。

(引用開始)
小説書きにはあるあるだと思うんですが、あるとき「ここ全部要らない!」となってバッサリ切り捨てることがあります。
そして後になって「あ、ここはあの時の文章が使えるのでは?」という時が必ず来ます。1割くらいの確率ですが。
そんな時のために退避場所として「退避ファイル」を作るのもひとつの手ですし、片倉もそうしていますが、切り捨てる際に「退避させなかった」文章は掘り返せません。
でも Git なら大丈夫。全部記録しているからね。
(引用終了)

1冊の本を書く時、最初に当然、目次と構成をラフに決めてから、書き出す。
しかし、良い本を出版しようとする時、必ず1回は、目次や構成をビッグリファクタリングするタイミングが訪れる。

そのビッグリファクタリングでは、目次や構成が大幅に変わってしまうので、今までの文章をざっくり削ったり、大幅に入れ替えたりする必要が出てくる。
一度削った内容を参照したり、一部だけ取り出すこともあったりする。
すると、Gitのような構成管理ツールで管理していなければ、こんなビッグリファクタリングの作業は怖くてやってられない。

こんなビッグリファクタリングが発生する理由は、自分が書きたい内容を書き出していくと、想定以上の分量になってしまい、出版媒体という箱の中に入れるには、大幅に削るしかない状況に陥るからだろう。
僕の経験上、そんなタイミングを数冊の本で経験したので、たぶん、他の人もそうではないだろうか。
書きたい内容がいくらあっても、それを一連のストーリーに論理的に配置して、読みやすい分量に収納するには、ビッグリファクタリングで大幅に削ったり、構成を見直す事が必要だから。

一方、それを最初から計画するのもあまり意味がないように思う。
やはり、執筆するのはかなりのパワーを浪費するので、最初は多少論理がずれていても、とにかく書き出しておけばいい。
その後で、Gitで履歴管理しているのだから、少しずつ修正すればいいだけ。

【3】さらなる利点は、GitHubとCIツールを連携することで、小説を多種多様なフォーマットに出力して、色んな媒体で公開できることだ。
Web小説のリリース自動化 - Qiitaに、こんな一節がある。

(引用開始)
動機
なぜ小説をいくつものフォーマットで発表する必要があるのだろうか。これにはふたつの理由がある。
第一に、作品を発表する場所が増えれば増えるほど、人の目に触れる可能性が高くなる。
特に、小説投稿サイトには小説を読むことを目的とした人が集まっている。
第二に、特定のプラットフォームに依存しなくて済む。
たとえば、小説投稿サイトには、突然規約が変わったり、サービスが終了したりするリスクがある。
そうしたリスクは分散させておいたほうがよい。
しかし、作品を発表する場所が増えれば増えるほど、運用が大変になる。作品の変換やアップロードに時間を取られれば、肝心の作品を書く時間が減ってしまう。
また、運用に失敗すると、場所によって内容が違い、どれが正しいかわからないという事態にもなりかねない。
逆に、更新作業が面倒だからという理由で誤字脱字等を放置するようになれば、それこそ本末転倒だ。
運用作業を自動化してしまえば、そうしたことに頭を悩ませる必要がなくなる。

方針
自動化の理想は、原稿を書いたり修正したりするだけで、はじめに挙げたすべてのフォーマットで小説が公開・更新される状態である。
この記事では、それに限りなく近いものとして「作品をGitリポジトリとしたとき、origin/master を更新するとすべてのリリース作業が自動的に行われる」という状態を目指す。
これはソフトウェアの世界でいう「継続的デプロイ」の一形態である。
(引用終了)

Web上で自分が書いた小説を公開する時、BlogやカクヨムのようなWebサービスは確かに良いが、閉鎖されるリスクはゼロではない。
閉鎖されると、自分の作品が消えてしまうリスクがある。
だから、リスクゼロのためには、GitHubに小説本体のソースは一括管理しておき、Blogや有償サービス、AmazonのKndleに配布するような手段を確保した方が良い。

すると、その手法は、継続的ビルド、継続的デプロイのような仕組みと一致するだろう。
僕もそういう考え方は以前から持っていたし、既に多くの人も同じようなことは既に考えているわけだ。

電子書籍の作り方: プログラマの思索

電子書籍の作り方part2: プログラマの思索

epub出版システムの作り方: プログラマの思索

Pandocでテキストファイルからドキュメント生成: プログラマの思索

Web小説のリリース自動化 - Qiitaでは、Webサイトへの変換にJekyllを使う事例まで載っている。
JekyllはRuby製の静的ジェネレータなので、使い方は簡単。
また、Jekyllプラグインには、カクヨムと小説家になろうへの投稿のための「jekyll-deploy-shosetsu」、電子書籍の作成のための「jekyll-build-ebook」など色んなGemが使える。

他に、達人出版会のReVIEWも有名だろうか。

ReVIEW記法 基本文法最速マスター - 達人出版会日記

TeXとRubyだけでWindowsにRe:VIEW環境を構築した話 - Qiita

【3】以上の話は、プログラマには無関係だろうと思われるかもしれない。
しかし、プログラマは技術書同人誌を書いてみよう、という記事もあり、ネタさえあれば簡単に出版できるらしい。

技術書同人誌を書きましょう! - Qiita

いろいろ試してみる。

【追記】
@8amjpさんのRedmine小説も流行していましたね。

Redmineを主題にした小説「Redmineで始める異世界人心掌握術」が流行しているらしい: プログラマの思索

「Redmineで始める異世界人心掌握術」を連載中です。 | at 8 AM, JP.

他に、@akiko_pusuさんの本「Redmineでやってみた」もありましたね。

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

| | コメント (0)

2019/01/04

PlantUML Example for モデルベース要件定義テクニックの記事のリンク

@ogomrさんのPlantUML Example for モデルベース要件定義テクニックの記事がとても参考になるので、リンクしておく。
以下は、論理的でないラフなメモ書き。

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

akipiiさんのツイート: "この発想は面白いな。RT @ogomr: PlantUML はテキストだけど意外と表現力があって モデルベース要件定義テクニック のUMLを拡張した図も描ける。GitLab なら RDRA をブラウザで表示できて便利 https://t.co/IpCRFQ4XDu"

akipiiさんのツイート: "後で試す。RT @zenzengood: PlantUML Example for モデルベース要件定義テクニック https://t.co/IpCRFQ4XDu #Qiita テキストベースでRDRAモデルを書きたい方はとても参考になります。"

歴史の流れをPlantUMLのシーケンス図で書き起こす事例のリンク: プログラマの思索


【1】最近、PlantUMLに着目していて、色々試しているのだが、@ogomrさんのPlantUML Example for モデルベース要件定義テクニックの記事がとても参考になった。

ストーリーは、モデルベース要件定義テクニック(RDRA)で使われるUML技法を、PlantUMLを使って書いてみよう、という流れ。
モデルベース要件定義テクニックは、UMLの技法をプロファイルで拡張していて、Enterprise Architectにはそのテンプレートがあるが、astahでは使えないので、いつも残念に思っていた。
だから、PlantUMLでモデルベース要件定義テクニックの技法を使えるのは非常に嬉しい。

記事では、コンテキスト図、概念モデル、ユースケース、データモデルなどがPlantUMLで紹介されている。

【2】RDRA(モデルベース要件定義テクニック)については過去に色々試していた。
僕は、UMLを要件定義に使う場合にRDRAの技法や考え方が非常に役立つ、と思っている。

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

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

理由は、UMLを要件定義に使おうとすると、要件を複数の観点で分析したい時に、粒度やトレーサビリティがバラバラになりやすい弱点があるが、モデルベース要件定義テクニックを使えば、その弱点を克服できるから。

実際、UMLやオブジェクト指向分析の技法を使うと、中間成果物が多い割には、結局、どんな要件が決まったのか、という事が分かりにくい時がある。
一方、モデルベース要件定義テクニックでは、システム地図の一部にUMLの各種ダイアグラムが埋め込まれ、それらがどんな粒度でどのように関連しているか、システム地図を鳥瞰する観点で要件を整理できる。

僕は、下記の記事にあるシステム地図の中で、「システム外部環境」「システム境界」の部分が一番重要と思っている。

要件定義支援ツール「要件のツボ」によるRDRAの実践 (1/3):CodeZine(コードジン)

なぜなら、人とシステムが相互作用するI/Fは、それら2つの観点で整理でき、相互に関連させることで、トレーサビリティを確保できるからだ。

結局、モデリングで一番重要で、かつ、難しい部分は、各モデルの粒度を揃えてレイヤ化することと、各モデルのトレーサビリティを保証することだと思う。
だから、モデルベース要件定義テクニックのような考え方を、具体的な技法で表現できると非常に心強い。

【3】PlantUMLには非常に可能性があると思う。
システム開発がプログラミング主体であるのと同じく、設計書もテキスト化して、構成管理の配下に置きたい野望があるから。
そのイメージは1年前に書いていた。

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

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

一般ユーザやプログラマへ業務イメージや技術イメージを説明する時に、何らかの図や絵を描いた資料を作るが、それらはExcelやパワポでは作りたくない。
そこで、PlantUMLを使えば、プログラミングと同じ感覚で書けるし、Webで情報共有もしやすい。

さらに、PlantUMLで描いたモデルも、モデルベース要件定義テクニックのように、各モデルの粒度やトレーサビリティを意識した規則に当てはめれば、その精度も上がるだろう。

PlantUMLが普及すれば、UMLは中間成果物が多すぎて使いものにならない、という声よりも、プログラミングの概念設計の一部として普通に使う、という考え方に変わるだろうと期待できる。
@u6k_yu1さんと同意見だ。

akipiiさんのツイート: "すごくいいね!RT @u6k_yu1: なんかこう、PlantUMLとか、モデルベース要件定義テクニックとか、ICONIXプロセスとかが広まることで、UMLが背負ってしまったトラウマとか業とかが払拭されて、みんな気軽にUMLを使えるようになるといいと思う。"

そして、最終的には、モデリングの根本問題の一つである「モデルの粒度を揃えてレイヤ化すること」「モデルのトレーサビリティを保証すること」も、PlantUMLとモデルベース要件定義テクニックを併用することで、具体的な解決方法を持って解決できそうな気もしている。
そのアイデアも試してみる。

astahで設計書とモデル、プロセスをつなぐ為の資料のリンク: プログラマの思索

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

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

【追記】
u6k_yu1さんのツイート: "PlantUMLのパーサーが欲しい。モデリングツールとして機能させたい。"

u6k_yu1さんのツイート: "はい、そうですね。と最初は思っていたのですけど、どうも私のイメージはPlantUMLのIDEっぽいです。VSCodeにPlantUMLのプロジェクト管理機能とモデル間のトレーサビリティ検証やバリデーションやチェック機能が欲しい、みたいな。… "

| | コメント (0)

2018/12/30

歴史の流れをPlantUMLのシーケンス図で書き起こす事例のリンク

歴史の流れをplantUMLのシーケンス図で書き起こした事例がツイートされていいたのでリンクしておく。
これは分かりやすい。

【参考】
読書猿『問題解決大全』4刷、『アイデア大全』9刷さんのツイート: "右手を痛めてから手書きを減らすべくAtom+PlantUMLで図を描くようにしてる。 画像は、大化の改新の前後をシーケンス図でまとめたもの。… "

akipiiさんのツイート: "歴史はシーケンス図で書くと面白いな。RT @kurubushi_rm: 右手を痛めてから手書きを減らすべくAtom+PlantUMLで図を描くようにしてる。 画像は、大化の改新の前後をシーケンス図でまとめたもの。 https://t.co/4FBraKNyco"

読書猿『問題解決大全』4刷、『アイデア大全』9刷さんのツイート: "実は「UMLで描く日本史」という企画もあってですね。… "

apple][ (28)さんのツイート: "あーこれはわかりやすいかも。 歴史の教科書って、時系列に文字で説明されているだけだから、相互関係や因果関係がすごく分かりにくいんだよね。図があってもすごく分かりにくかった。結局単なる暗記ものの域を脱しなくて、学問として全く興味が湧かなかったのもそれが大きな要因と思う。… https://t.co/kEoyxxbWNg"

akipiiさんのツイート: "「UMLで描く日本史」だけでなく「UMLで描く世界史」も期待しております! PlantUMLでソースをGitHubで公開してくれると、日本の高校生や受験生にも役立つと思いました。… "

てるりん🍙お結び隊 No.6🎸TEAM Mさんのツイート: "納品ドキュメントにWordやExcelが求められたりした場合は仕方ないけど、納品対象にならない内部設計のドキュメントやチームメンバー間での情報共有目的なんかは、SublimeTextやVSCodeとPlantUMLで書いてMarkdownで埋め込んでPDF化とか、最近よくやる。… https://t.co/ZxsDIBnsmJ"

【1】日本史や世界史のような歴史は大嫌い、という人も多いと思う。
理由は、暗記が大嫌いだからだ。
訳の分からない人名、関連して覚えにくい年号、など、丸暗記しなければ解答できないものばかりだから。

でも、僕自身は数学と歴史は好きだった。
理由は、数学はロジカルに組み立てられているので、基本的な公式さえ理解すれば、後は、そこから演繹的に導くだけで暗記が不要だから。

また、歴史も、その時代の政治的な背景や経済的な構造という仕組みを理解すれば、歴史上の大事件をマグマの噴火の現象として捉えることで、一連の流れで捉えることができるから。

たとえば、一昔前の歴史物であれば、マルクス主義史観や民主主義史観みたいに、歴史は経済中心で発展していくべきものであり、最終的には独裁政治から資本主義を経て民主主義へ落ち着く、という流れの中で、その国の歴史をプロットする、という考え方もある。
実際、民主主義に発展した国と歴史を考えれば、英国→フランス・米国→ドイツ・日本→ロシアの順で民主主義化されてきた。
あるいは、一人あたりGDPがある一定水準を超えると、中産階級の政治的発言力が高まり、独裁政治から民主主義に政治体制が変わる、とか。
とは言え、そういう進歩主義的歴史観が中国に当てはまるのかどうか、分からないが。

【2】では、そういう考え方で、歴史を捉えたい時、どんなモデリング手法を扱えばいいだろうか?

その答えの一つは、歴史をシーケンス図で書き起こしてみる事ではないだろうか。

たとえば、上記では、大化の改新前後の歴史的事件を、シーケンス図で書き起こしている。
さらに、吹き出しに、年号と事件名を書いている。
ゆえに、シーケンス図を見ると、誰が誰に何しているか、というのが一目で読み取れるので、理解しやすい。

シーケンス図のメリットは、アクターやオブジェクトの相互作用を表現できることだ。
そこから、UMLモデリング手法の考え方も適用できるだろう。

たとえば、Fatなオブジェクトがあって、メッセージの発信源が集中しているならば、他のオブジェクトが実は他に存在しているのではないか、と疑ってみると面白いかもしれない。
実は、XX事件の黒幕とか、他の重要人物が隠れているのかもしれない。

あるいは、「責任の委譲」を使って、メッセージが階段状になるように書き起こしてみて、歴史的事件のステーク・ホルダーが誰なのか、ステーク・ホルダー同士でどんなやり取りがあったのか、を書いてみると、より詳細に理解しやすくなるのではないか。
特に、XX戦争における敵と味方の区別、とか。
たとえば、新聞の国際欄では、シリア紛争の複雑な利害関係者の敵と味方の区別をクラス図に近いモデル図で表現している。

【3】そこで、歴史をシーケンス図で書き起こす時、VSCode+PlantUML+Gitを使うと非常に書きやすくなるだろう。

なぜならば、シーケンス図をプログラミングのように書けて、即座にプレビューできるので、試行錯誤しながら考えをまとめられるから。
また、Gitで構成管理の配下に置けば、理解した内容を継ぎ足していくことで、歴史のシーケンス図を一つの絵巻物として書き上げられるから。

上記の日本史のシーケンス図を見ていると、PlantUMLと歴史は相性が良い、という気がした。
日本史や世界史の年表を全てシーケンス図で書き起こしてみたら、世の中の高校生に貢献できるのではないだろうか??

たとえUMLを知らない高校生であっても、シーケンス図のように箱と矢印だけの絵を見れば、だいたいのイメージは分かるはずだろうから。

【4】PlantUMLの可能性については、以前から考えていた。

僕は、日本のSIで広く使われているExcel設計書は、全てテキスト化してGitで構成管理させたい。
そのためには、PlantUMLのような何らかのモデルの絵が必要だろうと思う。

一昔前の詳細設計書のような自然言語のドキュメントは現代では不要だが、システムの構想やアーキテクチャのイメージは、何らかのモデルという絵で表現したいからだ。
そうすれば、アーキテクトは、顧客やプログラマに説明しやすくなるから。

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

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

ツイートを読み流していると、世界中の人達がPlantUMLを使って色んなアイデアを試そうとされているのがよく分かる。
業務フローやシステムのアーキテクチャだけでなく、ER図、ジョブフロー図、ガントチャートもPlantUMLで実現できる。
さらに、リスク関連図(?)みたいな、因果ループ図までPlantUMLで実現しようと試されている人もいるみたい。

akipiiさんのツイート: "後で読む。RT @pdl_runa: 現場で役立つシステム設計の原則にあるUMLをPlantUMLで書いてみる https://t.co/LIRmSOsBWW"

akipiiさんのツイート: "後で読む。RT @tech_advent: OPENLOGI Advent Calendar: plantUMLで業務フローを整理する https://t.co/2LWksWSyuI"

akipiiさんのツイート: "なかなか良いな。RT @abe4tawa8: PlantUMLでER図を描く! – VELTRA Engineering – Medium https://t.co/7eVRHuFjFC"

akipiiさんのツイート: "ジョブフロー図も書きたくなるな。RT @jiro_saburomaru: 定期実行のバッチとかのタイムチャートをテキストから生成できないのかな。plantuml みたいに"

akipiiさんのツイート: "I think it interesting. RT @DinisCruz: Here is the first draft and @PlantUML version of our revised @Jira schema for risk management What do you think? Does it make sense? Created by @madplatt #IN https://t.co/76Fy4FM1me"

立花優斗さんのツイート: "PlantUMLめっちゃいいな… "

【5】PlantUMLを用いて、Excel設計書をテキスト化するだけでなく、日本史や世界史もモデルで書き起こす事例のように、他の分野にも適用して試してみたくなってきた。

来年のastah関西でも、そういう話をしてみたいな。

【追記】
@kurubushi_rmさんが、「大化の改新前後.pu」「環大西洋革命.pu」をGitHubでソースを公開されている。
とても参考になる。

kurubushi--rm/history-in-UML: We will use UML to summarize Japanese history and world history

読書猿『問題解決大全』4刷、『アイデア大全』9刷さんのツイート: "@akipiiさんのご提案を受けて、このPlantUMLでソースをGitHubを公開しました。https://t.co/I8kF93dALf これだけだと日本史なので、世界史のサンプルとして「環大西洋革命」を追加しました。 何れにせようろ覚えなので、修正パッチなど遊んでいただけると幸いです。 https://t.co/aaYZyrlmSJ"

akipiiさんのツイート: "年末年始の忙しい時にありがとうございます! 歴史だけでなく、新聞の国際欄にある利害関係者の図、例えばシリア紛争、をクラス図やコラボレーション図で描く、とか、色々アイデアが膨らみます。… "

akipiiさんのツイート: "@kurubushi_rmさんが日本史と世界史のシーケンス図がPlantUMLでソースをGitHubを公開されてます。https://t.co/RzJsYwXpUj 中国の王朝変遷の歴史、歴史上の戦争とか、色々描けそう。 他に、民法や会社法、知財法などの理解の為に、UMLが使えないかな?と思ってる。"

akipiiさんのツイート: "すごくいいね!RT @u6k_yu1: なんかこう、PlantUMLとか、モデルベース要件定義テクニックとか、ICONIXプロセスとかが広まることで、UMLが背負ってしまったトラウマとか業とかが払拭されて、みんな気軽にUMLを使えるようになるといいと思う。"

【追記2】
y503Unavailable@非公式Redmine調理法unofficialcookingさんのツイート: "Redmine界隈をネタに作成してみました。(記載判断は自分の主観) 振り返り易くすることは必要ですね。… "

【追記3】
ステークホルダーの関係をPlantUMLで図式化した事例が面白い。
歴史の内容は、全てPlantUMLで置き換えた方が分かりやすいのではないだろうか。

2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない

| | コメント (0)

2018/12/10

チケット駆動開発のアイデアがRedmineへ与えた影響は何か

この記事は Redmine Advent Calendar 2018 の12月25日分です。

Redmine Advent Calendar 2018 - Adventar

チケット駆動開発というアイデアがRedmineに与えた影響を改めて考察してみる。
以下はラフなメモ書き。

【1】チケット駆動開発の発端とは?

Redmineを導入運用する時、「チケット駆動開発」という言葉を使う場面がある。
既に、さかばさんがチケット駆動開発の由来と経緯について書かれている。

TiDD:チケット駆動開発: ソフトウェアさかば

必然から生まれたチケット駆動開発 - XP祭り関西2009 その3-: ソフトウェアさかば

チケット駆動開発の概念は、2007年にTracのチケット管理から生まれた。
その素朴なアイデアは、「チケット無しのソースコミット不可」「No Ticket, No Commit」。

2008年頃、そんなチケット駆動開発のアイデアをRedmineで試してみたら、XPに基づいたアジャイル開発に適用できることに気づいた。
そんな僕の経験を熱く語っていたら、さかばさんが「チケットはXPのタスクカードと同じ」と上手くまとめてくれた。
この言葉がヒントになって、Redmineによるチケット駆動開発を運用した時のPJ管理の技法、チームビルディングの技法に対し、既存の専門知識を片っ端から適用してみた。
たとえば、アジャイル開発、ソフトウェア工学、PMBOK、ITIL、品質管理、など。
そういうアイデアを専門知識で補強することで、より理解が深まる一方、理論はそのまま適用できず、効果を出すには前提条件や制約条件が色々あることにも気づいた。

【2】チケット駆動開発はどのように定義されているのか?

【2-1】Redmineでチケット駆動開発を実践した時のプロセスをフレームワーク化する試みは、下記から始まった。

脱Excel! Redmineでアジャイル開発を楽々管理 (1/5):エンジニアがお薦めする 現場で使えるツール10選(3) - @IT

【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する~チケットに分割して統治せよ」: プログラマの思索

【2-2】チケット駆動開発をアジャイル開発プロセスとみなした時の運用サイクルは以下になる。

1・プロジェクトで発生するタスク、課題、障害は、「XPのタスクカード」とみなし、全てチケット化する(Ticket First)。
チケットは作業指示書であり、課題管理票、障害管理票でもある。

2・それらチケットは、リリースするタイミングで、Redmineのバージョン単位にグループ化する。
Redmineのバージョンは、XPのイテレーション、Scrumのスプリントに相当する(Iteration is a version)。

3・リリースまでのPJ管理は、Redmineの優れたチケット集計機能、構成管理ツール連携機能でリアルタイムにモニタリングすることで実現する。
「No Ticket, No Commit」で、ソース修正履歴は全て、チケットで把握できる。

4・Redmineのバージョンの進捗が100%になったらリリースする。

5・リリース後、チームはふりかえりを行うし、顧客からの改善要望を収集して、次のイテレーション計画へフィードバックして再修正する。

【2-3】上記によって、チケット駆動開発によって明確になったプロジェクト運営のやり方は2つある。

一つは、プロジェクト内で発生するあらゆる作業や課題などをチケットに記録することで、プロジェクト運営はチケットのライフサイクルに置き換えられること。
もう一つは、RedmineバージョンをXPのイテレーション、Scrumのスプリントと同一視することで、Redmineのロードマップ機能は、長期のリリース計画と短期のイテレーション計画に置き換えられること。

つまり、プロジェクト運営の日々の作業は全てチケットでリアルタイムに追跡できるし、それらチケットはRedmineのロードマップ機能など数多くの優れた機能で、プロジェクトの長期の計画づくりにも使えるようになった。
すなわち、チケット駆動開発の概念をRedmineに導入することで、プロジェクト運営の全ての管理プロセスをコントロールできるようになるメリットがある。

【2-4】では、このメリットによって、PJ管理技法がどのように変化するのか。
僕がチケット駆動開発で運用した時に、プロジェクトリーダーとして一番意識したことは「チケットの取捨選択」だった。

プロジェクト運営では、日々数多くのチケットが発生し、計画当初のタスク以外に、納期までに収まらないタスクが発生する。
それらチケットを1つずつ精査し、対策を打ち、1つずつ潰していかなければならない。
見て見ぬふりして放置しても、悪い状況は何も変わらないから。

すると、ガントチャート保守という面倒な作業が必ず発生し、その作業に多大な管理工数を取られて、悪循環に陥る。
一方、チケット駆動開発では、ガントチャートは所詮、1個のビューに過ぎない。
ロードマップ、チケット一覧、カレンダー、かんばん、EVM、リソースヒストグラムなどのビューをチケット集計機能として実現できるし、それらでモニタリングすればよい。
1個のビューにこだわらず、必要な状況で必要なビューを使い、手を打てばよいのだ。

それら機能を使っていくと、バージョン単位にグループ化したチケット群を精査して、優先度の高いチケットから一つずつ潰していくようになる。
もちろん、それらチケットは時々刻々変わるが、Redmineの優れたチケット集計機能で把握できるので、プロジェクトリーダーの意思決定を支援できる。
すると、チケットを分割して次バージョンへ延期したり、捨てる意思決定が多くなると思う。
「直近の納期までに何が必要なのか」をプロジェクトリーダーに徹底的に考えさせる基盤をチケット駆動開発は提供してくれるからだ。

つまり、PJ運営を「チケットの取捨選択」というミクロな意思決定に落とすことが、実はマクロな観点のPJ運営を実現しているわけだ。

【3】チケット駆動開発の具体的な特徴は何か?

チケット駆動開発をRedmineで実装すると、下記の3つの特徴が見えてくる。

チケット駆動開発の戦略: プログラマの思索

【3-1】Redmineの優れた構成管理連携により、要件からソースコードまでのトレーサビリティのインフラが整う。これにより、Redmineは本来の(真の)構成管理ツールとして実現される。

「チケット無しのコミット不可」の運用ルールにより、チケットとソースが密関係で相互リンクされる。
つまり、チケットが作業指示書であれば、チケットを発生させた要件や仕様書からソースやビルドモジュールまで、相互にリンクで遷移でき、追跡可能になる。
よって、要件からビルドモジュールまでのトレーサビリティを理論上は実現できる。

過去のソフトウェア工学の書籍を読むと、トレーサビリティの重要性は謳っているが、その実現方法はExcel台帳でソースやバージョンを管理するなど非常に面倒に思えた。
他方、Redmineであれば、事実上、トレーサビリティを実現できる「真の」インフラになりうる。

また、Redmineはツール連携できるI/Fを持っているので、GitやJenkinsなど数多くのツールと連携すれば、「プロジェクト管理サーバー」なるものを実現できる。
つまり、PMBOKの言う「PMIS(プロジェクト管理システム)」を初めて実現できる。
僕は、PMBOKが目指していたものは、たぶん、こういうインフラが前提であって初めて理解できるのではないか、と思った。

そして、このアイデアは、ソフトウェアプロダクトライン(SPL)にもつながっていく。

さらに、チケット管理システムはソース管理と同じように、作業のUnDo、ReDoを行う為のリポジトリとみなすこともできる。

チケット管理システムは作業の構成管理と同じ: プログラマの思索

【3-2】Redmineの優れたワークフロー管理機能により、プロジェクト管理のフレームワークへ昇華・汎用化できる。

Redmineのワークフロー設定画面が意味するものは、三位一体論だ。
つまり、業務フローというアクティビティ図、ワークフローの状態遷移図、ワークフローの状態遷移表という3つの機能は、Redmineの1つの機能として実現される。

よって、PJ運営に出てくる全ての業務フロー、開発プロセスは、事実上、Redmine上で全て実装できる。
このアイデアにより、Redmineでは、WF型開発も、Agile開発も共存して運用できるメリットが出てくる。
もちろん、PMBOK、ITIL、サポートデスク、会議体管理、PC資産管理など、ソフトウェア開発以外の業務にも適用できるようになる。
ここが、Redmineの運用で一番面白く、そしてホットな部分だろうと思う。

【3-3】チケット集計結果をソフトウェア・リポジトリ・マイニングによって、色んな角度からメトリクスを採取して、プロセス改善の材料にできる。

Redmineに蓄積された過去の大量のチケットは、データマイニングの宝庫だ。
PMOや品質保証部にとって、ソフトウェア工学のメトリクスを実際に研究できる元ネタになりうる。
信頼度成長曲線というメトリクスも、こうやって作るのか、ということも初めて体験できた。

しかし、実際は、チケットの内容が詳細に記載されていないと、なかなか理論通りのメトリクスが得られないことも分かった。
他方、PMBOKのEVMやリソースヒストグラムは、こうやって実装できるのか、ということも体験できた。

チケットと言う一つのデータが蓄積できれば、PJ管理で使われるビューのうち、既存の理論をRedmineで簡単に実装できる。
さらに、Redmineは柔軟でカスタマイズしやすい特徴を活かせば、新たな観点のPJ管理のビューを生み出す可能性があるはずだ。

【4】チケット駆動開発で最も面白い特徴は、「チケットはストックとフローの二重性を持つ」ことだ。

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索


Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索

チケットはタスクカードであるから、フローとして流れる「流通媒体」。
一方、チケットは障害管理票、課題管理票でもあるから、ストックとして蓄積される「記憶媒体」でもある。

この2つの特徴が混在しているので、チケットの粒度を標準ルールでガチガチに定めるのは難しくなる。
なぜなら、流通媒体のチケットは細かくなるし、記憶媒体のチケットはどうしても大きくなりがちだから。

また、1つのチケットという実体は、ステータスが変更されるたびに、流通媒体と記憶媒体に性質が変わる特徴も持つ。
たとえば、タスクのチケットはフローとして流れるが、途中で仕様変更やらソース修正の内容など、ストックの内容が蓄積される。
他方、障害管理票のチケットは、当初は障害内容や対策を詳細に書いてストックとして蓄積されるが、テスターと開発者の間でやり取りする時、チケットはフローとして流れる。
そのおかげで、チケットはキャッチボールのような雰囲気になる。

つまり、チケットは障害や仕様変更の内容をストックして持つ一方、チケットで進捗管理でき、ワークフロー設定に沿って変更管理が自然に行われる。
すなわち、チケットは、データマイニングの元ネタやナレッジ基盤となる「記憶媒体」の側面と、進捗管理や変更管理などを回す「流通媒体」の側面が既に埋め込まれている。
よって、チケットの粒度に悩むよりも、このチケットの二重性を意識して運用したり、その特徴を活かすように知恵を絞る方が良いと思っている。

【5】チケット駆動開発の今後の課題は何か?

課題は3つあると思う。
一つ目は、チケットの粒度、チケットの完了条件について、考え方を整理すること。
チケットの粒度は、ソフトウェアの本質的な複雑性に由来すると考えているので、それを逆手に取って、ソフトウェアの本質をチケット駆動開発で探ることもできるはず。

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

TiDD初心者から必ず聞かれる質問~「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine: プログラマの思索

チケットの粒度と進捗ビューの関係: プログラマの思索

2つ目は、チケット駆動開発で実装できるプロセス基盤の種類を整理し、それらプロセスの特徴・メリット・デメリット・プラクティス・アンチパターンを明確にすること。
たとえば、WF型開発、Agile開発、PMBOK、ITIL、サポートデスク、PC資産管理、など。

Redmineが今後発展する方向のアイデア: プログラマの思索

Redmineが今後発展する方向のアイデアpart2: プログラマの思索

3つ目は、チケット駆動開発と組織の関係を整理し、「組織がチケット駆動開発をどのように複雑化させるのか」「チケット駆動開発は組織にどんなメリットをもたらすのか」を明確にすること。

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

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

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

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

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

Redmineとチケット駆動開発は表裏一体と思っているので、Redmineを使うことで、色んな実験ができると思う。
それらアイデアを試してみたい。


| | コメント (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のトピックブランチとRedmineチケットは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)

2017/08/20

セマンティック・バージョニング、チームの依存関係のメモ

セマンティック バージョニングのルールについて、改めてメモ。
主張のないラフなメモ書き。

【参考】
セマンティック バージョニング 2.0.0 | Semantic Versioning

「セマンティック バージョニング」を読んだのでバージョニングについてまとめた - Qiita

t32k、怒られる!セマンティック バージョニングしてますか? | HTML5Experts.jp

Ruby 2.1.0 以降のセマンティックバージョニングについて

【1】(引用開始)
バージョンナンバーは、メジャー.マイナー.パッチとし、バージョンを上げるには、

APIの変更に互換性のない場合はメジャーバージョンを、
後方互換性があり機能性を追加した場合はマイナーバージョンを、
後方互換性を伴うバグ修正をした場合はパッチバージョンを上げます。

プレリリースやビルドナンバーなどのラベルに関しては、メジャー.マイナー.パッチの形式を拡張する形で利用することができます。
(引用終了)

(引用開始)
例えばVersion 3.2.1の場合、メジャーバージョンは3、マイナーバージョンは2、パッチバージョンは1ということになります
(引用終了)

【2】ソフトウェアはハード製品とは違って、バージョンの依存性関係の管理がすごく重要だ。
特に、OSやミドルウェア、ライブラリのバージョンが違うだけですぐに動かなくなる。
また、バージョンアップの頻度も多いのが普通なので、ライブラリのバージョンアップを追随するのにも結構労力がかかる。

一方、バージョンアップしないライブラリは、進化していないので危険。
たとえば、最新のセキュリティパッチが考慮されていない場合もあると、すごく危険。

僕は、どの開発プロジェクトであっても、そこの構成管理の運用ルールをまずは見る。
ソース管理やビルド管理だけでなく、設計書の版管理はどのようにタグ付けされて、リリースバージョンとしてリリースされるのか?

構成管理はソフトウェア開発プロセスの基本であるが、意外に運用がまちまちだったりする。
今でも、リリース管理台帳というExcelで、リリースモジュールとバージョン番号を記録して、初めてリリースできる運用を行なっている所も多いのではないか。

すると、Excelのリリース管理台帳がロックされて書き込めない、リリース管理台帳が最新化されていない、リリース管理台帳そのものの履歴管理ができてないのでデグレした、とか、諸々の問題点が色々出てくる。

【3】また、バージョンのネーミングルールも重要だ。
メジャーバージョンとマイナーバージョンの違いを認識せずに、何となくナンバリングしていないか?

t32k、怒られる!セマンティック バージョニングしてますか? | HTML5Experts.jpでも「『いっぱい変更したのでメジャーバージョン上げてみるか』、『今回の修正は軽微なものだし、マイナーバージョンを上げるか』」とバージョニングしていたら、ロシアのサンクトペテルブルク在住の青年エンジニアに怒られた、という内容があった。

(引用開始)
彼の言い分は、「APIを変更したので、この場合はSemantic Versioningのルールに従ってメジャーバージョンを上げるべきであり、そうすることでユーザーも予測・対応しやすい」とのことです。
(引用終了)

すごく参考になる。
セマンティック バージョニングによるバージョン番号によって、ユーザに影響箇所を認識させることができるメリットがあること。
数多くのOSSも、そういうバージョン番号になっている。

だが、単一のアプリではなく、数多くの共有ライブラリに依存した大規模システムになると、依存関係の管理が難しくなる。
一つの共通ライブラリのバージョンアップで、回帰テストの工数が増えるリスクもある。
Javaでは、Maven、Ivy、さらにはGradleを使っていたが、今はどうなのかな?

【4】依存関係については、ライブラリだけでなく、チーム間の依存関係の例もある。
100人月以上の大規模システムになると、複数のチームが連携するのが普通だが、他チームのライブラリや成果物に依存するために、開発が滞る時がある。
あるいは、インフラ基盤に依存する場合、アジャイルチームとWF型開発チームが混在している場合、などの例もあるだろう。

下記の記事がすごく分かりやすい。

スクラムで依存関係を取り扱う方法 | Ryuzee.com

【5】この記事を読みながら、「ドメイン駆動設計」のパターンを幾つか連想した。
普通は、依存しあう二つのチームには、権力や影響力の優劣が存在する。
では、力の優劣のあるチームの依存関係では、どんなパターンがあるのか?

「顧客・供給者の開発チーム」パターンなら、上流のチームに対し、下流のチームが顧客として振る舞う。
これが理想。
本来は、上流のチームが「公開ホストサービス」「公開された言語」パターンで、下流のチームが使えるようなAPIを準備して公開すべき。
昨今のマイクロサービスの流行は、この方向性だろう。

「順応者」パターンなら、下流のチームは上流のチームに従順に従うしか無い。
下流のチームにとっては最悪のパターンなので「腐敗防止層」パターンでガードしたり、「別々の道」パターンを採用する。
たとえば、レガシーシステムの開発チームが強い場合は、こうならざるを得ない場合が多いだろう。

セマンティックバージョン、ライブラリの依存関係、チームの依存関係については、既に数多くの知見やベストプラクティスがあるので、それをまとめると面白いかなと思う。

| | コメント (0)

2017/05/22

気象庁の数値予報課におけるRedmine利用事例

気象庁におけるRedmine利用事例のリンクがあったのでメモ。
資料を読んでみると、以前のJAXAとは違った観点でRedmineが運用されていて、とても興味深い。
以下、理解と推測によるラフなメモ書き。

【参考】
数値予報モデル開発のための 基盤整備および開発管理 - 気象庁

第2章 開発記録とバージョン管理 - 気象庁

気象庁における 数値解析予報実験システムとバージョン管理

akipiiさんのツイート: 後で読む!RT @akahane92: #Redmine を有効に活用なさっているご様子が窺えます。気象庁予報部 - 数値予報課報告・別冊第 63 号「数値予報モデル開発のための基盤整備および開発管理」/ https://t.co/BxQV6ncPi5

akipiiさんのツイート: 読んでみると面白い。1つのサーバーに複数のRedmineインスタンスが稼働していて、そのインスタンス名も公開されてる。サーバー構成図もあって興味深い。数値予報モデル開発のための 基盤整備および開発管理 - 気象庁 https://t.co/BxQV6ncPi5

akipiiさんのツイート: 各Redmineインスタンスで異なるルールで運用されてる。親子チケットで進捗管理してるPJもあれば、ラフなタスク管理もあり。これらインスタンスのバージョンは同じなのかな?数値予報モデル開発のための 基盤整備および開発管理 - 気象庁 https://t.co/BxQV6ncPi5

【1】資料を見ると、気象庁の数値予報課における数値予報システムの開発プロセスにおいて、プロジェクト管理システムとしては Redmine 、バージョン管理にはSubversionやGitを導入したらしい。
気象庁では2012年頃には既にRedmineが導入されて、Redmineチケットに気象データや実験データを記録して蓄積する運用を行っているようだ。

(引用開始)
当時は開発コミュニティによっては Trac と呼ばれる Redmineと類似したツールを使っていたが、管理コストの低減、利用方法の共有の促進の観点から、機能がより豊富で柔軟に運用しやすい Redmine に統一することとした。
(引用終了)

(引用開始)
2012 年以前はさまざまなサーバに分散して Trac やRedmine が運用されていたが、すでに述べたように、開発管理サーバを整備して、数値予報課だけに限らず、庁内の数値予報モデル開発に関するプロジェクト管理シス
テムの運用を集約した。
開発管理サーバでは Redmineを標準的なソフトウェアと定め、Trac を利用していたプロジェクトは Redmine に移行した。
(引用終了)

(引用開始)
プロジェクト管理システム同様、一つのシステムに統一したいところであったが Subversion と Git で設計思想が大きく違う中で、すでに使用を開始しているものを一方に変更させるのは負担が大きい、ということから、どちらかを選択すればよいようにした。
(引用終了)

資料を一通り読むと、Redmineのチケット管理を上手く使いこなされているし、SVNやGitのブランチとチケットを連動させて運用させているような箇所も見られるので、OSSのモダンな開発プロセスは一通り習得されて運用されているように思える。
公共機関という、ある意味お堅い所で、RedmineやGitをバリバリに運用されている点がとても面白い。

【2】気象庁のRedmineで興味深い点はいくつかある。
一つは、Redmineのサーバー構成が公開されていること。

(引用開始)
開発管理サーバの構成図。両サーバは 2 台の大容量ストレージ装置をマウントしており、それぞれに主系・副系のゲスト OS を記録したイメージファイルを格納している。

サーバ
主・副 2 台
CPU: 3 GHz (6 core) × 2
メモリ: 48 GB (8 GB × 6)
HDD: 900 GB 2.5 型 SAS × 4
RAID: RAID5 + spare

大容量ストレージ装置
2 台 + 待機 1 台(非接続)
HDD: 3 TB SAT
(引用終了)

複数個のRedmineインスタンスで運用されている理由のせいか、サーバースペックはとてもリッチ。
主系・副系サーバーを用意して、定期バックアップでマウントされているので、サーバーの信頼性は非常に高く作られているように見える。
たぶん、気象庁の数値予報システムの開発状況や、数値予報システムの実験データ自身もRedmineに格納されているようなので、ミッションクリティカルなデータという観点で堅牢にサーバーが作られているのだろうと推測する。

ただし、開発サーバーの障害管理はどのように運用されているのか?
普通は開発サーバーの管理自身もRedmineで運用すると思われるが、資料では明示されていなかったので気になる。
もう1個、別のRedmineサーバーを立ち上げて、過去のデータを移行すればいいのではないだろうか。

(引用開始)
開発管理サーバに関する開発情報は、開発管理サーバに障害が発生した際に利用できる必要があり、障害時でも参照できる場所に情報が存在しなければならない。
そのため、開発管理サーバ自体の開発に関する情報は開発管理サーバの外で独自に管理を行う必要がある。
これらの情報の多くは開発管理サーバ導入前の環境、すなわち Redmineによる開発プロセスが導入される前に整備された環境を利用して情報が集約されている。
このため、現在では当然のように利用されているチケット駆動開発やレビューを行うための枠組みが存在しない。
(引用終了)

【3】もう一つは、一つのサーバー上で複数のRedmineインスタンスが運用されているらしいこと。
「コミュニティ」とは、気象庁の内部の各開発チームまたは開発部署と推測される。

(引用開始)
開発管理サーバの特徴として、一つのサーバ上に複数の Redmine を運用している点が挙げられる。
指針が定める開発管理サーバの利用範囲は、気象庁本庁と気象研究所を含めた複数の課室を想定していることもあり、管理する開発対象が非常に多岐にわたっている。
こうした背景からサーバ上で複数の Redmine を運用し、各 Redmine の管理方法の細目は利用するコミュニティに委ねる方式を採用している。
これによって、各コミュニティの既存の開発プロセスを踏襲しつつ、第 2.2.3 項で述べた Redmine を活用した開発が随時導入できるよう配慮している。
現在、開発管理サーバでは表 2.4.2 に挙げる Redmineを運用しており、モデル技術開発部会が取り組むほとんどの開発課題は、関連する Redmine 上で開発管理が実施されている。
(引用終了)

Redmineインスタンスの一覧は下記で公開されている。

(引用開始)
全球モデル
NHM
asuca
物理過程ライブラリ
海洋気象情報
数値予報事例 DB
共通基盤
化学輸送
同化・観測・QC 関連
結合系
海洋
ガイダンスグループ
お試し Redmine
(引用終了)

興味深いのは、それぞれのRedmineインスタンスで運用ルールが異なる点だ。
そうなった経緯や背景は明示されていないけれど、その理由は、各部署、各チームの業務や組織文化が大きく異るからではないか、と思う。

資料を読むと、10個くらいのチームの開発プロセスが紹介されていて、そのシステムが実現する業務はとても専門的で奥が深い。
たとえば、気象データのシミュレーション、数値解析、データの可視化など。
つまり、業務内容がとても大きく異なるために、一つのRedmineインスタンスにプロセスを標準化してガチガチに固めるよりも、各チームごとのRedmineで運用を任せて、柔軟に対応する方があるべき効果を導ける、という思想になったのではないだろうか。

そんなことを考えると、「闇Redmine」「野良Redmine」という症状は、現場によっては悪い症状ではなく、複数のRedmineインスタンスのVerUpやマスタ保守・インフラ保守のコストをカバーできるならば、現実的な解決策の一つと見なせるのではないか。

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

第11回東京Redmine勉強会の感想~Redmineエバンジェリストが日本各地で出現しているらしい #redmineT: プログラマの思索

実際、Redmineで最も多い質問は「チケットの粒度」だが、それに関しては、一律に標準化せず、各開発チームに運用を任せているからだ。
つまり、気象庁では、Redmineの特徴をよく理解しているように思われる。

(引用開始)
Redmine の利用にあたって、チケットに登録する際のタスクの規模、すなわち、タスクをどこまで細かく分割してチケットにすべきかについて悩むユーザが庁内には多いようである。
それぞれの開発コミュニティでルールを設けることが必要であるが、タスクの分割の仕方は主観的な面もあり一律に判断するのが難しい。
そのような場合は、チケットを作成することを躊躇せずに、まずはチケットを作成してその規模について試行錯誤をしてみることをお勧めしたい。
その試行錯誤の中で、開発コミュニティの中での使い方が定まっていくことが多い。
また、チケットの統合、分割は頻繁に行われることであり、作業を進める上で統合または分割したほうがやりやすいと判断される場合は、そのときにその統合または分割を行えばよい。
ぜひ、利用しながら自分の開発コミュニティにとって便利で有効な使い方を模索していただきたい。
(引用終了)

個人的には、チケットの粒度の問題は開発者は気にしないで良いと思う。
チケットの粒度を気にする人は管理者であり、彼らは顧客へ提出するレポートでその問題が絡んでいるだけだからだ。

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

TiDD初心者から必ず聞かれる質問~「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine: プログラマの思索

チケットの粒度と進捗ビューの関係: プログラマの思索

TiDD初心者によく聞かれる質問part2~チケットの粒度はどれくらいが妥当ですか?: プログラマの思索

【4】各チームの運用ルールも興味深い。

【4-1】全球モデルPJでは、リリール予定バージョンに対し、リリース計画をRedmineのチケットで立てて運用している。
その時、Redmineプロジェクトは、共通基盤は親PJ、各モジュールまたは各サブシステムは子PJで分けているみたい。

気になるのは「カテゴリ」でリリースバージョンを分類している、とのこと。
RedmineのカテゴリはPJ固有の属性だし、リリース終了のバージョンに対応するカテゴリは非表示にできないので不便だと思う。
普通は、リリース予定バージョンはRedmineのバージョンに対応付けて運用しているのでないかと思うけれど、実際はどうなのだろうか?

【4-2】メソモデルPJでは、チケット作成後、開発ブランチを派生させて、チケットに変更履歴を残す運用を行っている。
おそらく、チケット単位にブランチ管理しているので、トピックブランチとRedmineチケットを手動で連携させているように思われる。

また、チケットには、作業の内容だけでなく、テストやレビューも記録されている。
そして、「レビューアによる承認が得られれば、管理者によるトランクへのマージが行われる」ので、その意味では、git-flowに近い。
つまり、OSSのモダンな開発プロセスを取り入れているみたい。

【4-3】気象庁における 数値解析予報実験システムとバージョン管理を読むと、実験データはシステムに蓄積されると同時に、Redmineのチケットとしても自動登録して、記録しているようだ。
たぶん、RedmineのREST APIをコールしてチケット登録しているのだろうと思う。

わざわざRedmineにもチケット登録する運用にしているのは、Redmineに実験データや作業データを集約して、チケット同士の関連やソース管理と連携させたい理由があるのだろう。
つまり、情報共有はRedmineの方がやりやすい、という考えがあるのではないか。

【4-4】共通基盤PJでは、親子チケットによる進捗管理の運用を行っている。
Redmineの親子チケットの特徴を上手く利用して運用されている。

(引用開始)
NAPEX モデルの管理では、作業全体の進捗管理を親チケットで行い、個別の作業の管理は親チケットに結びつけられる子チケットを用いて管理するという方法を用いている。
(中略)
子チケットを用いた進捗管理では、子チケットを五月雨式に作成しない点に留意すべきである。
進捗が進むたびに子チケットを追加すると、全体の進捗状況が把握できなくなる。
親チケットを作成した時点で、必要となる子チケットを予め作成しておくことが望ましい。
これには親チケットを作成した時点で必要となる作業を明らかにしておく必要があり、子チケットとして分割するべき作業の洗い出しが必要となる。
この作業によって必要な作業の見通しを作業者自身の手で自然と把握することができるようになっている。
NAPEXモデルの管理では、子チケットの内容は相互に関連しているものの独立性があり、しかも定型的な作業が多いため事前に見通しが立てやすく、子チケットによる管理に適している。
(引用終了)

各Redmineインスタンスで、親子チケットの進捗管理をしたり、トピックブランチ単位のチケット管理、リリースバージョン単位のリリース計画作りとチケット管理、など、色んな運用ルールがあって面白い。

【5】気象庁のRedmineの利用ユーザ数は約300人、約5万チケットくらい。
JAXAの事例と同じく、たぶん、QMSやISMSなどに絡んでいると思われるので、チケットのデータの精度は良いのではないか、と推測する。

こういうシステムに、Redmineの全文検索プラグインを入れて、PageRankみたいな検索ができたり、類似チケット表示、検索時の入力補完ができると、より使い勝手が上がるだろうと思う。
なぜなら、元々のチケットのデータの精度も良いだろうし、気象データの数値解析やシミュレーションという専門性のため、過去のナレッジがとても重要になると思われるからだ。

redmine.tokyo第12回勉強会:GroongaでRedmineを高速全文検索 #redmineT - ククログ(2017-05-15)

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

【6】Redmineのメリットは、気象庁の人自身も感じているようだ。

(引用開始)
Redmine はチケット駆動開発に大変適している。
チケット駆動開発ではチケットなしでコミットしてはいけないという「No Ticket, No Commit!」ルールがある (小川・阪井 2010)。
これを導入することで、課題と成果の紐付けが可能になり開発情報が整理される。
さらに、コミット前にチケットが作成されることで、作業内容が多くの関係者の目に触れることになり、作業に先駆けて問題点やアドバイスが受けられるなど開発の効率化が期待できる。
また、レビューを経てからリポジトリを更新することを追加で義務付けることで開発成果の信頼性向上にも繋げることができる。
(引用終了)

(引用開始)
もちろん、行った変更の中には、物理過程間の相互作用などにより思わぬ結果が得られたものや、不採用になった変更も多いが、そのような情報も含めてチケットに残すことも非常に重要である。
なぜなら、改善につながった変更はドキュメントや報告書という形で残りやすい一方、採用に至らなかった変更はドキュメント化されにくいが、そこで得られた知見はモデルの解釈やその後の開発の方向性を決める上で重要であるためである。
(中略)
これらの実験の中には採用に至らなかった変更が数多くあるものの、チケットに記録しを実施した。
(中略)
内容はそのまま簡易なドキュメントとして残るため、開発者の記録用としてだけでなく、他の開発者への解説資料としても役立っている。
(引用終了)

(引用開始)
担当者間でメールで行っていたことが、ウェブベースに変わっただけと思われるかもしれないが、両者には大きな違いがある。
それは、作業内容を記録としてきちんと残していくことが可能になったとともに、他の P 班員が能動的に試験内容を知る機会が生まれたことである。
これにより、試験内容がさらに多くの人の目に触れることになるだけではなく、それぞれのルーチン変更に対して、担当者の技量の差などから生まれるミスが軽減され、知見を共有することで数値予報ルーチン全体としての品質の向上につながったのである。
また、ルーチン変更に起因する障害の際には、従来はルーチン変更担当者でないと実施内容が不明なために対応が難しい面もあったが、Redmine を導入してからは、他の P 班員に情報が共有されることにより、担当者以外による対応が容易になった。
(中略)
Redmine などのツールを上手く利用することで業務の品質は向上し、良い結果をもたらしたことは明白である。
しかし、それぞれのコミュニティに合ったやり方でツールを導入しなければ、開発効率を落とすだけではなく、業務の品質も落とすことになるので、その点には注意が必要と考える。
(引用終了)

チケット管理を上手く運用できれば、情報共有がスムーズになることで、各メンバーのコミュニケーションが活性化したり、「No Ticket, No Commit」によるチケットとソースのトレーサビリティを実現することで、Redmineの過去チケットをテストやレビューのプロセスに役立てることもできるだろう。
Redmineそのものがナレッジシステムになることで、過去のデータから色んな知見を探し出すこともできる。

でも、Redmineを単純に導入したからと言って、チケット駆動のメリットがすぐに得られるわけではない。
組織の文化、業務内容、成熟レベルによって、Redmineの運用ルールを段階的に変更したり、柔軟にコントロールする必要があるだろう。
複数のRedmineインスタンスで故意に運用しているのも、そういう背景があるのではないか。

気象庁の事例も、Redmine勉強会で講演してくれないかな?

【追記】
2018/2/3のRedmine大阪にて、気象庁の方に講演していただいた。
詳細は下記の通り。

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

| | コメント (0)

2017/05/14

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

第12回東京Redmine勉強会では、講演者、参加者、スタッフの皆さん、お疲れ様でした。
大雨の土曜日のために、突然キャンセル40人以上発生したにもかかわらず、参加率90%という驚異的な勉強会。
感想をラフなメモ書き。
間違っていたら後で直す。

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

第12回東京Redmine勉強会 - Togetterまとめ

第12回東京Redmine勉強会の見所: プログラマの思索

akipiiさんのツイート: "#redmineT 東京Redmine 勉強会から離脱しました。今日は参加率90%で驚異的でした。ディスカッションでは土木建築、デザイナー、ゲーム、メーカーなど多様な業界でRedmine が使われてた。レベル別、セグメント別で議論して、Redmine の運用方法を洗い出してみたい"

【1】@g_maedaさんの発表は、3月のRedmine大阪の発表の改良版。
気になる点は、最後の「Redmine3.4.0になれなかったパッチたち」。

サイドバー折り畳みは、欲しい。
PCの画面が小さいと、フル画面でチケット一覧を見たくなる。
チケット一覧の表示項目が増えると、横スクロールが必要になって、うっとうしい。
また、スマホ、タブレットなど数多くの閲覧媒体が増えてきているので、レスポンシブ対応だけでなく幅広く対応してほしい。

コードハイライト言語を増やす機能追加も早くやってほしい。
特に、VB、C#のコードハイライトがない、という要望は従来からすごく多い。

バージョン内のチケットのD&D機能も早く追加してほしい。
アジャイル開発におけるプロダクトバックログの精査の作業に直結する作業だからだ。
つまり、チケットのリリースの優先順位づけを並び順で表現することは、リリース計画をプロダクトオーナーと開発者が共有しやすくなる点にも直結する。
アジャイル開発の観点では、チケット一覧画面よりも、ロードマップ画面の改良にもっと力を入れて欲しい。

【2】@Madowindaheadさんの講演では、チームの変化やチームの成長を活動画面から事前調査して、支援しているとのこと。
この部分はRedmineの優れた機能そのものだし、チームの成長がRedmineに記録されていく点はチームのモチベーションにもつながるだろう。

あさこさんのツイート: "「決定に関する内容も分かります」 活動内容をどういう粒度で記入するかをしっかり決められているいい事例ですね!! #redmineT"

akipiiさんのツイート: "#redmineT 成長していることを、変化していることで捉える。まさにRedmine の得意なところ"

また、PMxTMのポジショニングマップが重要だと思う。
縦軸=PM技術力、横軸=ツール利用度で、開発チームや開発メンバーをプロットして、どこのセグメントが問題なのか、あるべき姿へどうやってマネジメント力を向上させていくべきか、という観点で分析するのに使える。

特に、Redmineを導入したけど、社内でなかなか広まらない、という時に、どこのセグメントに問題があるのか、という分析のヒントになるだろうと思う。

スライドで面白い点は、社内でRedmine利用度を上げることでマネジメント力を向上させるパターンを経験上3種類あげている点だ。

一つ目は、PM力が大変低く、ツール利用経験も大変低い層。
このセグメントは、「目標になるメンバーと一緒に成長ラインに乗せる」。
つまり、新入社員のように、まだ技術もPMの経験が浅い人は、OJTのような仕組みが有効なのだろう。

二つ目は、PM力は中間くらいだが、ツール利用の経験が浅い層。
このセグメントは、「この位置のメンバーは成長ラインに乗せやすい」。

その理由は、既にマネジメントの経験があり、PMに必要なスキルや概念はある程度分かっている人たちなので、そのスキルを生かしやすい環境としてRedmineを提供すれば、自分たちで問題解決していけるようになるはず、ということだろうと思う。

三つ目は、PM力は高いが、ツール利用度が大変少ない層。
まさにExcelおじさん。
このセグメントは、「メンバーの成長を意識させることで、成長ラインに乗せる」。
この点は、なるほど、と思う。

このセグメントは、自分たちのやり方を持っている人が多いので、なかなか新しいツールを使ってくれない。
でも、自分の立ち位置やメンバーへの影響力は、自分でも分かっている人が多い。
すると、自分がRedmineを使わなくても、メンバーがRedmineを使って自然に成長していけば、自分もちょっとはやってみようか、という気になるのだろう。
つまり、いきなりツールを使いこなせ、とトップダウンでやるのではなく、ボトムアップで攻めていくわけだ。

このパターン集で面白いのは、4象限のうちの右下の部分「ツール利用は多いがPM経験が少ない」セグメントのパターンがないこと。

講演でちょっと触れていたが、このセグメントはヒントを与えたり、支援すれば、自力で解決していってくれる。
個人的には「プログラマ上がりのプロジェクトリーダー」が多いのではないか、と想像する。
そういう人たちには、得意とする技術力をベースとして、Redmineでマネジメント経験を増やしていけば、自然に力が付くのではないか、と想像する。
僕自身もそういう経験があった。

【3】@ktohさんのRedmine全文検索プラグインの話も興味深かった。

たとえば、チケットが数十万枚、数百万枚に増えた場合、それらチケットやWikiなどの情報を、欲しい時に即座に検索できる機能は、Redmineをナレッジシステムとして使うために重要な機能と考える。
Ver3.3では、右上の検索ボックスは表示中のPJだけにデフォルトで絞り込み検索するので早くなっているが、全PJ横断の検索はまだ遅い。
そのような問題を解決するプラグインなので、Redmineをナレッジシステムとして価値を向上させるために有用な機能だと思う。

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

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

全文検索プラグインで興味を惹く点はいくつかある。

一つは、検索ノイズがなく、ランク別・更新時刻順に表示される点。
Groongaという拡張DBエンジンを使うので、スコアを調整して、有用な検索結果を上位N件に表示してくれる。
注目すべき点は、デフォルトの全文検索結果と全文検索プラグインの検索結果は、件数は同じでもソート順が違う点。
つまり、Google検索みたいに、役立ちそうな情報が上位に表示されるので便利。

また、Google検索のように、AND・OR・NOT検索ができるのも便利。
たとえば、「(Groonga OR Mroonga) -PostgresSQL」みたいに、GroongaまたはMroongaを含むがPostgresSQLを含まないように検索できるらしい。
この機能が検索で使えるならば、過去の障害や仕様変更の履歴を探したい時に、より詳しい検索条件で書けば、より早く到達できるようになるだろう。

さらに、更新時刻順にソートできるのもうれしい機能だ。
検索したい状況をふりかえると、直近で自分や他の担当者が書いた内容を検索したい時が多いからだ。
直近の障害情報、直近の課題やQAを見つけたい時が多いから。

二つ目は、高速である点。
この内容は、既に@akahane92さんがツイートされている。

Kuniharu AKAHANEさんのツイート: "200万チケット@MySQLでやってみたよ。検索時間は約380ms。 #Redmine の未来が広がって嬉しいな。ありがたいな。/Redmineで高速に全文検索する方法 - ククログ(2016-04-11) https://t.co/s7FA4gSThu @_clear_code"

neta@世界は私のオイスターさんのツイート: "@akahane92 さん! 今クリアコードの人が 赤羽根さんの全文検索380ms のツイート紹介してました。プラグイン適用前の処理時間を知りたいらしいですよ! #redmineT"

Kuniharu AKAHANEさんのツイート: "@netazone (ご参考まで) Redmineチューニングの実際と限界 / https://t.co/fRU2MvH4my の114ページです。"

三つ目は、まだ未実装だが、類似チケットの検索。
これは、Amazonのお勧め商品表示と同じく、協調フィルタリングとか機械学習みたいな機能を使って、この障害チケットに似た過去のチケットはこれこれです、みたいに表示する。
たとえば、障害チケット起票時に、過去の類似バグを表示してくれると嬉しいだろう。

四つ目は、まだ未実装だが、検索ボックスやチケットのタイトル欄などで、入力補完する機能強化。
これは、PJプルダウンのインクリメントサーチのように、検索ボックスで1文字入れたらGoogle検索みたいにコードアシストしてくれる機能みたいなイメージ。
この機能があれば、チケット内容の入力間違いを減らせるし、途中までの文字入力で自動補完してくれるので、チケット入力コストをかなり減らせるはず。

つまり、ただでさえチケット入力は鬱陶しい、と言われがちな弱点に対し、検索エンジンの強化によって入力補完をサポートすることで、チケット入力者の作業コストを減らし、チケットの内容の精度向上に役立てることができるわけだ。

この辺りの機能を欲しいと思う日本人ユーザ、Redmine利用企業は意外に多いのではないだろうか。
なぜなら、Redmineを利用している現場は増えているし、すでに数年以上運用してかなりの枚数のチケットを蓄積している日本企業も多いと思うからだ。
@ktohさんが支援を要請しているので、興味のある人は声掛けしてはどうだろうか。

すさんのツイート: "第12回https://t.co/YxfaKONoze勉強会の「GroongaでRedmineを高速全文検索」の資料です!今後の野望を一緒に実現したい人はぜひ連絡をください! https://t.co/FEBfQvAVk4 #redmineT"

今後の野望については、下記の記事でアップされている。

redmine.tokyo第12回勉強会:GroongaでRedmineを高速全文検索 #redmineT - ククログ(2017-05-15)

なお、AWSへのセットアップでは、下記のツイートがあるので注意。

Kawabata Mitsuyoshiさんのツイート: "AWSだとmroonga入れられないという質問があったが、最近だとRDSから、MySQL on EC2にmaster-slaveでレプリケーションして、MySQL on EC2側で検索処理するが定石っぽい #redmineT https://t.co/SwD3IFyeVt"

MAEDA, Goさんのツイート: "Redmine本体は現状PostgreSQL推奨です。MySQL 5.6以降だとデッドロックが発生するケースがあります。 #redmineT https://t.co/zRSmVfGY8T https://t.co/y9KtUtJ8SG https://t.co/AS0A6KDeaZ"

【4】宮本さんの「チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験」も興味深かった。

ストーリーとしては、既にRedmine+GitLab+Jenkins+Maven+Artifactoryという開発環境がそろっていて、その上にプロダクトラインのプロセスを実装しようとするお話だった。
お話としては大変興味深いのだが、肝心のRedmineの機能にどのようにマッピングさせたのか、という点はぼかされていて、分からないところが残念笑。

但し、講演中の一言「Redmine が要件、タスクなどエントリーポイント。MavenやArtifactoryがプロダクトラインでは肝となる所」という話から想像すると、こんな感じかな。

akipiiさんのツイート: "#redmineT Redmine が要件、タスクなどエントリーポイント。MavenやArtifactoryがプロダクトラインでは肝となる所。プロダクトそのものの構成管理がやりたいからだろう"

Redmineには、要件や仕様、それに基づくタスク・課題・障害の情報は一元管理されていて、そのチケットから作業は駆動される。
そして、ソースや設計書などの成果物はGitLabで構成管理されていて、複数の製品ファミリーはGitのブランチで管理されている。

その時、それぞれの製品ファミリーのリリースされたソフトウェア製品は、バージョンでタグ付けされて、それらはArtifactoryでビルドモジュール単位のバージョン管理がなされている。
つまり、各製品は、共通ライブラリやコア基盤となるようなビルドモジュール(たぶんJarやWar)とアプリケーション資産(これもJarやWar)がパッケージングされていて、各製品がリリースされたタイミングで、共通ライブラリのどのバージョンに依存しているか、はMaven+Artifactoryで構成管理されているのだろう。

つまり、ソフトウェア製品とソフトウェアモジュール(汎用ライブラリ)は、ビルドモジュール単位で構成管理されていて、その構成管理が重要、ということなのではないだろうか。
この考え方はちょうど、業務システムがOracleやApache、.NET Frameworkの特定のバージョンに依存して作られていて、それらも含めて構成管理されている、みたいな考え方と同じではないだろうか。

すると、Redmineにある発端となった要件や仕様から、それに紐づくソース、そこからビルドされてリリースされたソフトウェア製品へトレースできる(後方への追跡性)し、逆に、あるバージョンのソフトウェア製品から要件までトレースできる(前方への追跡性)。

そのような開発プロセスを作りたい、という動機も別途あるのだろうと推測する。
そして、その仕組みは、Redmineのチケット管理や構成管理ツール連携という機能を使えば、チケット駆動のトレーサビリティ機能が導出されて実現できる、みたいなストーリーではないだろうか。

チケット駆動開発を要求工学の品質特性の観点から考える~チケット駆動開発がAgile開発を必要とする理由: プログラマの思索

【5】講演資料はコチラ。

| | コメント (3)

より以前の記事一覧