「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