RedmineのGit連携機能に関する議論

Redmine本家で、Git連携機能に関する議論があって、興味深いのでメモ。
結論のないラフなメモ。

【参考】
Feature #14961: Reconsider moving from svn to git &GitHub - Redmine

Feature #30069: Integrate Redmine with GitLab (or other free CI system for open source) to run tests - Redmine

Feature #8363: Git: Pull requests - Redmine

QA #910: RedmineでPullRequestを使いたい - Unofficial Redmine Cooking - redmine.tokyo

【1】RedmineのGit連携に関する問題は、実は2つの論点があると思う。
1つ目は、RedmineにGitHubやGitLabクローンの機能を入れて、Redmine上でプルリクエストを行いたい事。
2つ目は、Redmine本体の開発は、Gitのプルリクエストを使い、数多くの開発者のパッチによる貢献を取り入れやすくする事。

この2つの論点が混じっているので、議論が込み入っているのではないか、と思う。

【2】実は、Redmineのパッチ開発者の多くは、Redmine本体をGitの構成管理の配下に置き、自由に開発ブランチを派生させて実験したり、プルリクエストをコミッタに送りたい、という要望が大きいのだろう。

Feature #14961: Reconsider moving from svn to git & GitHub - Redmineで、Taiki I さんがこんなコメントをされている。

(Google翻訳の引用開始)
こんにちは恐竜、
この問題が発生してから5年が経過しました。全世界がGitに移行したかどうかはわかりませんが、OSSプロジェクトがPull RequestsとGitによる寄付を集める主流になりました。
Redmineにプルリクエストを実装するかもしれませんが、これは容易ではないでしょう。
まず最初に、RedmineのリポジトリをGitに移動し、プルリクエストを受け付けるようにします。そして、貢献のハードルを下げ、貢献の門を広く開きます。競合品を使っても。
幸いなことにGitLabには「外部課題追跡システム」があります。これで、GitLabのGit管理とプルリクエスト（マージリクエスト）を使用しながら、Redmine.orgの多くの問題をそのまま使用し続けることができます。
この問題についてもう一度話し合いますか？
(引用終了)

但し、その実現が容易ではないことは、Redmineユーザなら皆知っている。

Feature #14961: Reconsider moving from svn to git & GitHub - Redmineで、@g_maedaさんがこんなコメントをされている。

(Google翻訳の引用開始)
現在の状況が気に入らなくても、皆さん全員が紳士的であることを願っています。
何年もRedmineの開発に時間を費やしてきた人々を落胆させてRedmineを改善することはできません。
(引用終了)

【3】僕は、GitHub連携プラグインがRedmineに組み込まれれば、不満はほぼ緩和できると思う。
つまり、プルリクの機能はGitHub上で使い、Redmineのチケットにはその履歴を残す、というように、利用場面を使い分けることだ。
また、Redmineチケットにパッチを添付するのではなく、GitHubのプルリクの内容がRedmineチケットに自動複製されると、もっと良い。

これは完全な解決方法ではないが、プルリク機能の実装は非常に難しいと思う為だ。

【4】この議論のチケットを読みながら、OSSコミュニティを発展させるには、OSSコミッタのモチベーションが最重要であることを思い出した。

オープンソースソフトウェアを開発する日々をハッピーに ― あるいは、OSSコントリビュータに感謝を伝えるためにできること | POSTD

Redmineに不満が出て、数多くの不平を言ってしまうこともあるだろう。
その行為がOSSコミュニティにとって良いことなのか？

下記の文章が心に残った。

（引用開始）
オープンソースに関わる誰かに、シンプルに肯定の意を伝えることです。
メールや、あるいはIRCを通して、はたまたプロジェクトの貢献者に直接会うなど、手段を問わず文字通り誰かに「ありがとう」と伝えることは、とても大きな意味を持つのです。
これが取るに足らないことだとは承知していますが、長い時間をかけてオープンソースに貢献している人たちは、基本的にネガティブな人、あるいは誠意はあるけれども人から何かをしてもらおうとする人たちに相対してきたことを忘れてはいけません。
人にずかずかと要求せず、「ありがとう」と言ってくれる人がいることは、バグ修正などの要求に応えたからのお礼ではなく、プロジェクト全般が感謝されていることが分かるはずです。

この2つの感謝の違いは、愛する人のために何かをしてあげ、相手があなたに感謝の気持ちとしてハグをしてくれることと、同じ人がただ単にあなたが好きだからという理由で不意にハグをくれる、この2つのハグの違いと同じなのです。
前者のハグもすてきですが、後者のハグはあなたをより特別な気持ちにしてくれます。
(引用終了)

最近、Matzさんもこの論点の記事を書かれていた。
Rubyに対する不満がRubyクローンを生み出したこともあったらしい。

Rubyのまつもと氏、「気分を害することもある。だからどうか建設的であってほしい」 － Publickey

そして、Matzさんの回答の一つは、Ruby開発のITSであるRedmineに、提案して欲しい、と。

【5】OSS開発の活発さとOSSコミュニティの活発な議論には相関関係があると思う。
さらには、@t_wadaさんの指摘どおり、OSS開発の活発さと良いソフトウェア設計には密接な相関関係があると思う。
Redmineの良さの一つは、RubyとRailsという柔軟な開発基盤のおかげで、カスタマイズしやすいので、色んな議論ができることだろうと思う。
そのバランスはどこにあるのだろうか？

OSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか? - t-wadaのブログ

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

第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 その３ - #itsjp #devsumi: ソフトウェアさかば

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

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

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

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

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

チケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのか from Shunsuke (Sean) Osawa

チケット管理システム大決戦第二弾 from Ryutaro YOSHIBA

RedmineをフォークしたOpenProjectのリンク

下記の記事で、RedmineをフォークしたOpenProjectなるものを知ったので、リンクしておく。

【参考】
「近代化Redmine」ことOpenProjectでスクラム開発のプロジェクト管理 - Qiita

ExcelおじさんとGitHub若者が共存するためのタスク管理法 - Qiita

ExcelおじさんとGitHub若者が共存するためのタスク管理法 ? Be full stack?? | SI からフリーランス

【１】@g_maedaさんのツイートによれば、OpenProjectは、Redmineをフォークしたらしい。
よって、OpenProjectは、Redmineをコア基盤としている訳ではなく、Redmineとは別で発展しているみたい。

akipiiさんのツイート: "後で読む。Redmine のVerIpに追随できるのか、気になる。RT @diffshare: こういうのもあるのか https://t.co/60moUClq42 「近代化Redmine」ことOpenProjectでスクラム開発のプロジェクト管理"

akipiiさんのツイート: "詳細は知らないけど、コア基盤がRedmine なら、バージョンアップに追随できないと運用は難しいかも。Planioサービスは上手くバージョンアップに追随して、凄いと思います。… "

やっさん🍶さんのツイート: "#OpenProject のプラグインが #Redmine のがベースになってるぽいので、Redmineクローンなのかも。 openproject-local_avatars/local_avatars.rb https://t.co/htY5Qtnbda opf/openproject: OpenProject is the leading open source project management software. https://t.co/iISR8GZPy4… https://t.co/SOdVSfhRUV"

MAEDA Goさんのツイート: "2011年にRedmineをフォークしてChiliProjectができました。 https://t.co/35fGcR87fd さらに2012年にChiliProjectをフォークしてOpenProjectができました。 https://t.co/WOvyOEtHGm 現在はOpenProjectは独自に進化していて、Redmineのバージョンアップには影響されないと思います。… https://t.co/pB0P50Enmz"

【２】OpenProjectの特徴は、RedmineのVer2時代のBacklogsプラグインの拡張版として捉えられることだろう。
ScrumやかんばんをRedmine上で使いたい人には、朗報かもしれない。
今どき、Excelでプロジェクト管理するのはしんどいからね。

（引用開始）
こんな人におすすめ

今までRedmine + Backlogプラグインで頑張ってた人
・スクラム開発用に「かんばん」と「バックログ」が欲しい
・プロジェクト管理用に「ガントチャート」も欲しい
・でも、Redmineにプラグインを入れる苦行は回避したい…
・日本語化されててほしい
・簡単に環境構築したい
ExcelおじさんとGitHub若者が共存するためのタスク管理法 - Qiita みたいな環境の人
（引用終了）

Dockerで簡単にインストールできる点もいい。

詳細はまだよく分からないが、「微妙な点」の内容が面白い。
「推奨環境がメモリ4GB」となかなか豪快、とか、SPAが微妙、とか、Redmine臭がすごい、とか、まあそういう面はありそう。

RedmineをフォークしたChiliProjectは廃れてしまったが、OpenProjectの動向も追ってみたいと思う。

【追記】
Redmine BacklogsプラグインはScrumプロセスを忠実に実現しようとしている: プログラマの思索

第13回RxTStudy勉強会の感想 #RxTStudy: プログラマの思索

【第13回RxTStudy勉強会】Redmine BacklogsプラグインでScrum開発！ ～Redmineでアジャイルに開発しよう from akipii Oga

「Git と Redmine を用いた気象研究所共用海洋モデル」の論文のリンク

@g_maedaさんのツイートで、「Git と Redmine を用いた気象研究所共用海洋モデル」の論文を知ったので、リンクしておく。
引用文献に、「ファーエンドテクノロジー: redmine.jp」が掲載されているだけでなく、「Redmine によるタスクマネジメント実践技法」も掲載されているのが嬉しい。

【参考】
GitとRedmineを用いた気象研究所共用海洋モデル「MRI.COM」の開発管理

Git と Redmine を用いた気象研究所共用海洋モデル - 日本海洋学会

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

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

akipiiさんのツイート: "後で読む！RT @g_maeda: Redmineの活用に関する論文を見つけた。 GitとRedmineを用いた気象研究所共用海洋モデル「https://t.co/zwcaQuOKca」の開発管理 https://t.co/5BfubPtHsJ"

【１】論文の内容は、気象庁の研究者が、海洋大循環モデルのソフトウェア開発にRedmineとGitを適用することで、開発プロセスを標準化し、効果を上げた、という事例みたい。

海洋大循環モデルのシステム維持はとても大変、という問題意識があったらしい。

(引用開始)
（海洋大循環）モデルの維持・開発はより困難になってきているのが現状である。世界的にモデル開発者数は減少する一方で，モデルのソースコードは日毎に大規模化・複雑化している。
このため，バグの混入や意図しない影響の抑制，つまりソフトウェア品質の維持は非常に難しくなっている。
（中略）
ソースコードは全体で 10 万行を超え，100 近いコンパイルオプションと数 100 に及ぶ実行時オプションがある。
加えて，仕様を変えずにバグ修正だけが必要な現業目的と，次々に機能を追加する必要がある研究目的の両方に対応するため，安定版と開発版の2 系統を維持しなければいけない。開発が始まってからおよそ 20 年が経過し，過去の絡み合ったソースコードの整理・再構成も必要である。
これらソースコード自体の複雑さに加えて，その利用が多様化しているという問題もある。長い開発期間の結果として，MRI.COM は，日本沿岸海況監視，季節予報，将来気候予測など，気象庁と気象研究所の多様な現業と研究の基盤モデルに用いられ，それぞれの幅広い要望に対応して，同時並行的に開発が進められている。
このような複雑な状況の下で，ソフトウェア品質を維持しながら様々な機能を次々にソースコードに加えていくことが，少人数の開発チームに求められている。
(引用終了)

そこで、GitとRedmineを導入することで、下記を狙ったらしい。

・複数のブランチに対するソースコードの開発履歴を管理する
・作業過程の記録と進捗状況の把握を一元的に行う
・これらのツールを基盤に用いることで，開発者各人がそれぞれのやり方で開発する状況から脱して，システマティックな開発手順を導入する

【２】興味深い点は、Gitの運用フローが詳細なこと、Redmineの運用フローに特徴があること、だと思う。

Redmineの実際の運用フローは以下の通り。
プログラミング作業とコードレビューがチケットの主要な使い方みたいだ。

（引用開始）
1）開発者はまず Redmine チケットを作成し，Fig. 4 のように簡潔に開発内容を記す（いわゆるチケット駆動開発，小川・阪井，2010）。
2）開発者は他の開発メンバー 1 名を「レビュアー」に指名し，ソースコードを編集する前に，変更内容と実装方針について相談する（ただし，簡単なバグ修正であれば必須ではない）。
3）相談結果を踏まえ，開発者がローカルでコード変更の作業を始める。
4）ローカルでコード変更を完成させ（Fig. 2 の手順 2 に相当），レビュアーにレビューを依頼する。
5）レビュアーがコード変更のレビューとテストを行う。レビュー結果は Redmine のチケットのコメントやGit の修正コミットとして開発者にフィードバックされる（Fig. 2 の手順 3，4，5）。
6）コード変更を開発メンバー全員に公開し，チェックとテストを受ける（Fig. 2 の手順 7，8）。
7）検証が終わったコードを幹とする（Fig. 2 で Ver.1.1を確定することに相当）。
これで 1 つのチケットの開発は終了し，確定した歴史となる。
（引用終了）

Redmineの運用のメリットは以下の通り。

（引用開始）
具体的なメリットを以下に挙げる。
1）他人に見られることを前提にしてタスク内容を明文化することで，開発方針が明確になる。
2）担当者や期日が明示されることで，各タスクの優先度の誤認などを防ぐ。
3）実装方針など開発に関する議論が残されることで，他の開発者と将来の開発者はコード変更についての理解が容易になる。開発過程のデータベース化は，次世代の開発者にとって大きな財産となる。
4）開発内容とソースコードが関連付けられ，どのような目的で，どのようにコードが変更されたかを誰もが見えるようになる。これにより，モデル利用者に対して，なぜそのような変更を行ったのかを説明する責任を果たすことになる。これは，現業使用や外部提供もされる MRI.COM にとって重要である。
5）Redmine でチケットを一覧表示させることで，モデル開発の全体の進捗を共有できる。
（引用終了）

気になる点は下記がある。

（引用開始）
上記 5）で挙げた開発進捗の共有は特に重要であるので，実際の MRI.COM の開発について，チケットを一覧表示した Fig. 5 を例にして，より詳しく説明する。
MRI.COM では 1 ヶ月単位のリリース・サイクルを採用しており，例えば 2014 年 5 月末に Ver.3.3.15，2014 年 6 月末にVer.3.3.16 をリリースした。Fig. 5 に示す Redmine でのチケット表示もリリース・バージョンに紐付けられ，Ver.3.3.15 では 16 件の開発事項があったことが分かる。
MRI.COM ではこれらチケット内容をまとめることで，例えばバグ修正 4 件，機能追加 3 件，それ以外が 9 件などの「リリースノート」を，新しいバージョンのソースコードと同時に公開している。
（引用終了）

上記の内容は、ロードマップ画面をリリース計画またはリリース履歴と用いることで、「開発者は自分の作業だけでなく全体の開発の進捗状況も簡単に把握できる。」メリットが得られた、ということ。
「これはチーム開発にとって必須の機能である。」と念押ししているように、ロードマップ画面の機能を十分に理解されていると思った。

さらに読み進めると、スーパーコンピューターのリプレースに向けたモデルの移行作業など、色んなプロジェクトにもRedmineを適用して運用しているらしい。

【３】まとめとしては、下記の通り。
GitとRedmineを非常に上手く運用していることがよく分かる。

（引用開始）
まず，ソースコードの開発履歴を管理するバージョン管理システム「Git（ギット）」と，開発のタスクを管理するプロジェクト管理システム「Redmine（レッドマイン）」を導入した。
そのうえで，開発のステップを，課題の設定，他メンバーへの説明，コーディング，レビュー，テスト，リリースと区分し，そこで行うことを具体的に定める「開発手順の標準化」を行った。これらの取り組みにより，バグの混入や意図しない実験結果の改変を抑制しつつ，モデルの集団開発を効率的に進める体制が確立された。
これによるメリットは多々あるが，とりわけ，複数の開発者による並行開発の円滑化，開発過程のデータベース化，ある変更を本体に取り込む前に他の開発者がチェックする「コードレビュー」の必須化，安定版と開発版の 2 系統維持，テスト自動化は，モデル開発において有益である。
また，開発手順の標準化は，他部署や他機関の人が行ったバグ修正や開発も通常の手順で幹のソースコードに取り込む体制が確立されたことを意味する。
（引用終了）

【４】今後の課題として、下記が挙げられている。

（引用開始）
1 つ目は，開発管理を担っている開発管理サーバーに，セキュリティの制約により外部からアクセスできないことである。2013 年から実施している JAMSTEC，東京大学，九州大学とのモデル開発に関する共同研究では，JAMSTEC のサーバーで Git と Redmine が稼働している。将来的には，より広い共同開発のために，海外主要モデルで行っているように github 等のインターネットでアクセスできるシステムを利用するのが望ましいように思われる。
2 つ目は，ソースコード公開の制約と著作権である。外部ユーザー向けの貸与制度を 2012 年に開始したのに加え，上記の共同研究の参加研究機関内ではソースコードを共有している。しかし，原則として，MRI.COM のソースコードは非公開である。日本の研究コミュニティの支持を得るには，抜本的な変更が必要になると考えられる。
3 つ目は，ユーザー向けサポートである。第 4 節で述べた MXE の作成や，力学フレームワークと主要なオプションを解説したマニュアルの公開などがおこなわれているが，MRI.COM 習熟のハードルは高く，よりきめ細かいサポートが必要である。
（引用終了）

オンプレでGitとRedmineを主体とした開発管理サーバーを運用されているので、外部に公開する時の懸念点が今後の課題として挙げられている、と思った。

【５】3/2に、気象庁の方がSEA関西プロセス分科会で講演されるので、色々聞いてみようと思う。

天気予報を支える数値予報システムの技術 第71回 SEA関西プロセス分科会　- connpass

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をコーディング以外で活用する７つの方法 | 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

【告知】2019/3/2にSEA関西で「気象予報システムを支える技術」の見所 #seakansai

【見所】
今年度のSEA関西では、２月・３月に３回連続で、ビッグな講演が目白押しです。
第3弾は、3/2土に気象庁 予報部 数値予報課の技術者の方が来て下さって、「気象予報システムを支える技術」を講演される。

実は、この講演の発端は昨年のRedmine大阪で、気象庁の方が講演してくださったのがきっかけ。

第66回 SEA関西プロセス分科会＆第18回 Redmine大阪　「チケット管理システムによるソフトウェア開発支援と今後の課題」 - connpass

昨年のRedmine大阪では、気象庁の数値シミュレーションシステム開発において使われている、Redmineの複数インスタンス運用がメインテーマだった。

一方、今回の講演では、気象庁内において、スーパーコンピュータを使った天気予報の数値シミュレーション開発の話そのものがメインテーマになる。
気象予報のシステム開発に、並列計算や機械学習など数多くの技術を紹介してくれる。
この部分だけでもとても興味がある。

また、システム開発の運用基盤に関わる話の一つとして、RedmineやGitなどの話も含めてくれるらしいので、Redmineユーザも要チェックでしょう。

そう言えば、昨年のRedmine大阪の講演では興味深い内容がいくつかあった。
たとえば、気象庁では「プログラマ」という官職があり、給与人事制度があるので、プログラミングに専念する技術者という地位が認めらている。これは、官公庁という発注者の環境でも存在できる、という点で興味深い。
また、そういうプログラマがいる雰囲気のせいだろうか、気象庁内ではFortrunだけでなく、インフラ運用などでRubyが頻繁に使われている、という話もあった。
最近は、海外の技術者の影響を受けて、Pythonにも挑戦している、という話もあったな。

気象庁の技術者の講演を聞くチャンスは少ないので、興味のある方は是非お越しください。

【参考】
第70回 SEA関西プロセス分科会　気象予報システムを支える技術 - connpass

（引用開始）
気象予報システムを支える技術
講師：　
　雁津 克彦 氏（気象庁予報部数値予報課プログラム班）

概要：　
　気象庁では、風や気温などの時間変化をスーパーコンピュータで計算し、将来の大気の状態を予測する「数値予報」を用いて、日々の天気予報や防災気象情報の作成を行っています。

気象庁はTop500で28位・29位(2018/11現在)のスーパーコンピュータを整備して数値予報を行っており、運用中のスーパーコンピュータシステムについて紹介した後、C, Fortran, Ruby等で内製している数値予報のプログラムについて、並列計算やソフトウェア技術といった側面を中心に紹介します。併せて、予測結果を天気予報に利用できる形に翻訳する「ガイダンス」では各種機械学習を用いたプロダクトを作成しており、こうした機械学習の利用についても紹介します。

また、これらのソフトウェアは複数の課室で開発を分担していますが、実行プログラムや読み込む定数ファイルなど多くの部分を共有して利用しており、これらを齟齬なく維持管理する現在のルーチンシステムの管理手法や、バッチ処理のためのスケジューリングソフト(ROSE)、開発管理としてのRedmine, subversion, git 等の利用についても併せて紹介します。

主催：　 ソフトウェア技術者協会（SEA）関西支部 (http://sea.jp/)

開催日時：　 2019年3月2日（土）14:00～16:45

開催場所：　
　〒540-0031　大阪市中央区北浜東3-14
　エル・おおさか（大阪府立労働センター） 7階 701号室
　http://www.l-osaka.or.jp/index.html
（引用終了）

【告知】2019/2/16にSEA関西でIPAの方の講演「IoT時代のシステム開発アプローチ」の見所 #seakansai

【見所】
今年度のSEA関西では、２月・３月に３回連続で、ビッグな講演が目白押しです。

第１弾は、2/09(土)に、Node-REDのワークショップ。
Nodeから手が出るNode-RED - connpass

第２弾は、2/16に、IPAの方が大阪まで来て下さり、「IoT時代のシステム開発アプローチ」の講演会です。

１本目の講演は、IOTシステム構築に必要な要件であるセキュリティ要件や信頼性の観点のお話。
２本目は、IOTシステムが、組込製品からクラウドシステムまでも含むシステムズ・オブ・システムズの観点であることから、システムエンジニアリングのアプローチが有効である、というお話。

IPAの最近の活動をネットで見ると、日本の製造業の技術力強化には、組込製品のソフトウェア開発だけでなくIOTシステムも重要、という認識の元、製造業と密接に関わるソフトウェア開発の話が多いように思う。

「日本のモノづくりは高品質」という神話があったけれど、現代は、ハードウェアよりもソフトウェア開発の方がはるかに重要になってきてる。
だから、日本の製造業はもっとソフトウェア開発に目を向けるべきだ、というメッセージが込められているように思える。

IPAの方の講演は関西ではそう簡単に聞けないので、興味のある方は是非お越しください。

第3弾は次のブログで紹介予定。

【参考】
第69回 SEA関西プロセス分科会　IoT時代のシステム開発アプローチ - connpass

（引用開始）
IoT時代のシステム開発アプローチ
講師：　
　宮崎 義昭 氏（独立行政法人情報処理推進機構 社会基盤センター 産業プラットフォーム部　研究員）
　端山 毅 氏 （独立行政法人情報処理推進機構 社会基盤センター イノベーション推進部 　主任研究員）

概要：　
本セミナーでは、IoT製品の開発者が開発時に考慮すべき安全性やセキュリティ観点でのリスクや対策と、品質の確保・維持に必要な考慮ポイントを説明したうえで、多様な専門領域にわたる取組みが求められるIoTの開発に役に立つ開発アプローチである、システムズエンジニアリングについて、その基本的な考え方を解説します。

主催：　 ソフトウェア技術者協会（SEA）関西支部 (http://sea.jp/)

後援：　 独立行政法人 情報処理推進機構（IPA）

開催日時：　 2019年2月16日（土）13:30～16:45

開催場所：　
　〒530-0001
　大阪市北区梅田1-2-2-500　大阪駅前第2ビル5階
　大阪市立総合生涯学習センター　第1研修室
　http://osakademanabu.com/umeda/

講演１：　つながるシステムの安全安心に向けた課題と対策

講師：　(独)情報処理推進機構　社会基盤センター　研究員　宮崎 義昭 氏

IoTと呼ばれる製品・サービスの普及が進み、個人生活や生産現場など様々な場面での　活用事例が報告されています。一方で、IoTシステムは、セキュリティやセーフティの観点で、これまでとは異なるリスクを含んでおり、システム提供者には、開発や運用の場面において、十分なリスクの洗い出しと対策が求められます。本講演では、IoTの安全安心に対する課題と高信頼化に向けた考慮ポイントや品質確保の取り組み方について、具体的な事例を交えて解説します。

講演２：　成功事例に学ぶシステムズエンジニアリング

講師：　(独)情報処理推進機構　社会基盤センター　主任研究員　端山 毅 氏

IoT時代における製品やサービスは、利用者からの要請や期待に応えるため、製品やサービス自体が複雑化・高度化し、その実装には多様な専門領域にまたがった取組みが求められます。
このような状況には、航空宇宙分野で培われてきたシステムズエンジニアリングのアプローチが役に立つと考えられます。本講演では、特にシステムズエンジニアリングの考え方を理解する上で重要な4つのポイント（「目的指向と全体俯瞰」、「多様な専門分野を統合」、「抽象化・モデル化」、「反復による発見と進化」）や、システムライフサイクルプロセスの上流プロセスについて、実践的な解釈と事例を交えて解説します。 また、システムズエンジニアリングのアプローチが有効に機能したと評価できる日本企業の開発事例を紹介します。
（引用終了）

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のプロジェクト管理機能とモデル間のトレーサビリティ検証やバリデーションやチェック機能が欲しい、みたいな。… "