気象庁の数値予報課における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: プログラマの思索