2017/06/20

JAXAのRedmine利用事例の講演資料がWeb公開されました

昨年7月に開催された第65回 SEA関西プロセス分科会 & RxTStudy #15における、JAXAのRedmine利用事例の講演資料が公開されていたので、メモ。

【参考】
“CODA” チケット管理システム | JSS2@JAXA:「JAXAスパコン”JSS2″の運用を支えるチケット管理システム”CODA”」, 2016/7/30, イベント: 第65回 SEA関西プロセス分科会 & RxTStudy #15

JAXAの数値シミュレーションとスパコンの歴史 (2016年版) - YouTube

第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」の感想: プログラマの思索

JAXAのスーパーコンピュータ活用課でRedmineを使ったチケット管理システムの経験論文: プログラマの思索

JAXAのRedmineモデル~Redmineはレイヤ構造になっている: プログラマの思索

JAXAのRedmine運用に隠れている運用ルール: プログラマの思索

講演資料を読み直すと、昨年7月の講演会の熱い雰囲気が思い出されて懐かしい。
JAXAがなぜRedmineを導入しようとしたのか、その理由も詳しく書かれている。

個人的に興味を惹いた部分は、資料の後半にあるRedmineの管理画面の設定情報だ。

ロールは、レギュラー、文書係など7種類。
トラッカーは、全般、QA、会議開催など9種類。
チケットのステータスは、修正待、再現待、返却・抹消など13種類。
カスタムフィールドは、すごくたくさん。

文書カテゴリは、11個。
たぶん、DMSFプラグインを入れたためだろう。

IssueTemplateプラグインのチケットテンプレートは、5種類。
報告書や会議資料で使われているみたい。

プラグインは、DMSF、IssueTemplate、LocalAvatar、SidebarHideなど7個。
EnterCancelプラグインも入っている。

「プロジェクト分割の目安」も参考になる。
「Redmine活用の大きな要素」であり、「業務範囲の広がり時の分割判断」になる。
PJ分割の指針は下記らしい。

(引用開始)
a. セキュリティ等の属性で参加メンバーが異なる →親子プロジェクトの利用
b. 同一参加メンバー(ユーザ)のロール変更が必要な場合
c. 業務範囲に依存するフィールドの要・不要、更新頻度の多寡
d. Redmine保守は独立プロジェクト
e. プロジェクト毎に選択肢を設定できる、”強力な”標準フィールド「カテゴリ」の活用
(引用終了)

興味を惹くのは、セキュリティなどのユーザ属性でメンバーのロールが変わる場合に親子PJを使う点。
確かに、社外のベンダー開発者と社内メンバーでは、情報アクセス権限が異なるので、分けた方が良い場合はある。

また、「カテゴリ」機能を頻繁に有効活用している点も面白い。
カテゴリはPJ独自に設定できるので、PJの独自性を出したい検索キー項目があれば、カテゴリを使うといいかもしれない。

「フィールドの要・不要、更新頻度の多寡」は、CFのAND条件の運用ルールに相当するだろう。
この運用方法については下記でも書いた。

JAXAのRedmine運用事例の分析~「ロール設定のORルール」と「カスタムフィールド設定のANDルール」: プログラマの思索

最後に、「Redmineへの期待」の部分がすごく参考になる。

(引用開始)
1. 高い汎用性を持つチケット管理システム
2. 全体としては非常に満足
3. 活発な開発の継続とコミュニティや情報発信の充実
4. プラグインによる機能面・操作性の充実
5. ASP型エコシステムの確立によるOSSの普及・定着
(引用終了)

Redmineの利用が広まった理由には、コミッタによる定期的なVerUpと頻繁な改善、ユーザコミュニティが活発で書籍やWebの情報が多いことがあるだろう。
つまり、RedmineというOSSのエコシステムが自然に生まれて、成長のらせん構造になっている点があると思う。

コミュニティの一スタッフとしては、OSS活動を通じて、コミッタとユーザの交流と活発な議論によるコミュニティの場が重要であると肌身を持って感じた。
そういう活動を今後もやっていきたいと思う。

| | コメント (0)

2017/06/18

Redmine v3.3.3のER図をastahでリバースしてみた

Redmine v3.3.3のER図をastahでリバースしてみた。
自分のためにリンクを貼っておく。

【参考】
MAEDA, Goさんのツイート: "@flower_norn データベース設計のドキュメントは残念ながら見たことなくて、db/schema.rb でテーブルレイアウトが確認できるくらいです。 rails-erdというgemを使ってER図を作ってみました。 https://t.co/X7Ztl2AHos"

さやか/Sayakaさんのツイート: "@g_maeda Redmineのデータベース設計について記載されたドキュメントなどもしご存知であればご紹介いただきたいです。ブログやmastdonなどで紹介すると、意外と知りたい人がいるかもしれないです。私もDBを触ったことがあって、なぜインクリメントするのか不思議でした。"

RedmineのER図: プログラマの思索

【1】Redmineに蓄積されたチケット情報に対し、障害・課題・進捗・工数などの情報をある特定目的で集計したい場合に、ER図やDB設計書があると便利だ。
直接SQLを発行して、データを抽出した方が早いから。

そういう意図でRedmineのER図を見ると、どのテーブルもサロゲートキーなので、SQLは書きやすい気がする。

【2】なお、渡辺さんの記事では、Railsのようなサロゲートキーが強制されたデータモデリングに関する意見があり、参考になる。

「強制されたサロゲートキー」の事例を眺める: 設計者の発言

【3】astahのDBリバースプラグインはすごく優秀。
稼働中のDBに対し、JDBCがサポートされていれば、ほとんどすべてのスキーマ構造をリバースしてくれる。

DB リバースプラグイン | Astah

また、DB定義書もExcel出力してくれるので便利。
「Excel設計書を直す→DDL作成→DDLを環境へ反映」流れではなく、「DDLを作成→DDLを環境へ反映→astahでDBリバース→Excel設計書を出力」の流れの方がスムーズと思う。
Officeファイルの保守ほど面倒な作業はないから。

一方、ExcelのDB定義書からastahのER図をリバースするプラグインもあるので、astahは正直手放せない。

Excel-ERモデルインポートプラグイン | Astah

[pro] エンティティ定義書エクスポート

| | コメント (0)

2017/06/16

Salesforceのデータモデリング手法の記事のリンク

@hatsanhatさんの記事「データモデリングしてますか?」がとても参考になるのでメモ。
詳しくは下記の記事を参照。

【参考1】
データモデリングしてますか? - TECH BLOG | 株式会社テラスカイ

参考になった箇所は下記の通り。
サロゲートキーだけの開発環境の場合、「複合キーの制約をNotNull制約と更新不可制約で実現する」点が参考になる。

(引用開始)
スキーマビルダーで描画すればそのまま実装も出来るところは大変便利ですが、データモデル構造だけをシンプルに見たいという用途には向きません。
そこで筆者はオープンソースのモデリングツール「X-TEA(エクスティ) Modeler」を使用しています。
モデリングツールは何種類か試しましたが、1:Nの関係を親子関係と参照関係で明示的に表現出来る事と、項目に「更新不可属性」を設定出来る(何故必要かは後述)ためこのツールを重宝しています(作者に感謝)。
(中略)

顧客・顧客担当者・商談だけを関係付けたデータモデルです。
「顧客」と「顧客担当者」の間は鳥の足のような特徴的な線で結ばれています。
これが親子関係を表します。

「顧客担当者」と「商談」の間は先が点々になっています。
これは同じ1:NでもN側にNullを許す参照関係を表しています。

この2つの書き分けが出来るツールは珍しいのでSalesforceに向いています。
(引用終了)

(引用開始)
本当に複雑なデータモデルの時に主キーも正確に表したい時は、外部キー(foreign key)を使います。
複合主キーと外部キーの違いはNotNull制約と更新不可制約だけです。

・主キーはSalesfordeIdの単独主キーとする
・複合主キーとしたい他の項目はNotNULL制約+更新不可制約を付ける
(このためにX-TEA Modelerの「更新不可属性」が必要になります)
(引用終了)

(引用開始)
顧客オブジェクトの先頭の項目「011-id」は顧客オブジェクト(011)のSalesforceIdを示しています。
SalesforceIdとはオブジェクトの各レコードに一意に付けられる番号です。
この値を見れば、会社の中でレコードを1つに特定出来ます。
一般に言う「オブジェクトキー」とほぼ同じです。
Salesforceはこの値をURLに指定するとレコードを検索出来るという奇跡のようなURI設計(笑)になっています。
(引用終了)

【参考2】
あわせて、渡辺さんのBlogとさかばさんのBlogも参考になるのでメモ。
特に、さかばさんの指摘「RDBだから複合キーを使わずに実装できてしまう。モデリングの問題(注:実装と対比して、設計の問題という意味と推測)ではなく実装の問題です」も参考になる。

単独主キーでもDB設計は楽にならない: 設計者の発言

「単独主キー専用環境」と賢くつきあうために: 設計者の発言

複合主キーの扱い方: ソフトウェアさかば

(引用開始)
RDBなのに複合主キーを使わないのではなく、RDBだからサロゲートキーを作りやすいので、複合キーを使わない開発が簡単にできてしまうのだと思います。

つまり、単独主キーで開発を安易に行うことが問題です。

本来、複合主キーで表現されるデータをどう扱うかは、モデリングの問題ではなく実装の問題です。

複合主キーを使わないのは実装の都合なので、そこにある危険性を周知することが重要だと思います。
(引用終了)

| | コメント (0)

2017/06/15

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

astahの事例を探していた時に、設計書とモデル、プロセスをつなぐ為のアイデアが書かれた資料を見つけたのでメモ。
以下はラフなメモ書き。
間違っていたら後で直す。

【参考】
モデルへの参照を含む多様な設計情報の継続的統合ドキュメント化に向けて

【1】以前、Redmine大阪で宿口さんの講演を聞いた時、機能安全規格を満たすプロセスをRedmineで実現する話があった。
その実装方法を聞くと、Wordの要件定義書ドキュメントの目次の各タイトルに、チケット番号のリンクが貼られていて、そのリンクからRedmineチケットとWordドキュメントの整合性を取るような仕組みを実装されている、とのことだった。

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

その時は、なぜそんなやり方が必要なのだろうか?と不思議に思った。
確かに、WordドキュメントにRedmineのチケット構造が同期されるので、見通しは良くなるが、それはRedmineのプラグインのような一機能で実現した方が良いのではないか?と思ったからだ。

WordやExcelとRedmineを連携しようとすると、結局、VBAマクロを駆使することになり、VBAを扱うのが苦痛だから(笑)

一方、上記の資料を読むと、Wordの要件定義書やアーキテクチャ設計書でモデルや作業構造をまとめるのががなぜ必要なのか、その理由が書かれている気がした。

【2】Word文書で組込みソフトウェアのモデルの絵や説明文をまとめたとする。
しかし、モデルは改変されるので、Word文書に書いた内容やモデルの絵はどんどん古くなる。
改変のたびに、逐一、モデリングツールで描いた絵をコピペしなくてはならない。

一方、要件管理ツールにあるソフトウェアの要件もどんどん変わる。
要件、モデル、そしてそれらの正しさを保証するプロセスも影響を受けて、要件の変更のたびに、派生的に編集作業が発生してしまう。
ドキュメントの保守作業ほど、無駄なコストの発生源であるものはないだろう。

つまり、要件とモデル、設計ドキュメントのトレーサビリティと変更の同期が課題になってくる。
また、標準プロセスで必要とされる成果物やドキュメントが揃っているか、という成果物の保証も関わってくる。

これらの課題はどうやって解決すべきなのか?

【3】上記の資料のストーリーは以下のようなイメージ。

①astah製品でUMLやSysMLなどのモデルを描く

→astahのOfficeプラグインによって、astahで描かれたモデルは、ExcelやWordに埋め込まれる。
 Officeプラグインのお陰で、astah上のモデルの変更は、ExcelやWordに同期される。

Office連携 プラグイン | Astah

②astahのGSN製品で事前に、標準プロセスを描いておき、必要なドキュメントを洗い出しておく

→astahのGSN製品から、要件定義書や設計ドキュメントの雛形を出力する
 標準プロセスに必要なドキュメントは、それぞれのWordやExeclにマッピングされ、astahのGSN製品のD-caseに対応付けられている。

→WordやExcelのドキュメントに、ソフトウェアの要件や仕様を記述していく。
 ドキュメントの中のモデルは、astahのUMLやSysMLに連動されている。

すなわち、astahのGSN製品で機能安全規格が保証された標準プロセスを構築し、その標準プロセスに対応付けられたOfficeドキュメントは、astahGSNで同期されている。
さらに、Officeドキュメントに貼られたモデルの絵は、astahファイルから参照されており、astahのモデルが変更されたら自動的に同期される仕掛けになる。

以前、astahのOffice連携プラグインを使ってみた時、このプラグインのメリットがあまり感じられなかった。
しかし、上記のような使い方をするならば、Office連携プラグインはとても重要な一機能になる。

Office連携 プラグイン | Astah

Astahプラグインの資料のリンク: プログラマの思索

【4】理論的には、上記のようなやり方で、Officeファイルの設計書・UMLやSysMLやER図やDFDなどのモデル・機能安全規格を満たす標準プロセスの3つは、全てastah製品で連携・同期・統一されることになる。

平鍋さんは、たぶんそのようなイメージでastah製品シリーズを作られたのではないか。
そう考えると、非常に上手く考えられているなあ、と感じる。

但し、上記のやり方はあくまでも理想論であり、本当にうまくいくのかは分からない。
実際のソフトウェア開発の現場における要件定義、設計の作業はもっと泥臭いし、労働集約的な作業ばかりだからだ。

たとえば、プログラム開発はGitという非常に強力な構成管理ツールがあるので、大人数の共同開発がやりやすい。
そして、Jenkinsのような強力なビルド管理ツール、Redmineのような強力なチケット管理ツールを組合せた作業環境が既に一般的だ。

一方、要件定義や設計では、astahのモデルやOffice文書は、Gitのような構成管理を行う環境があまり整っていないために、差分やマージ作業、プルリクエストのような共同作業がやりにくい。
また、モデリング作業で発生するQAや課題が発生して、それを解決して、その内容をモデルに反映していく、という一連の流れとチケット管理が、まだ上手く連動できていない。

個人的には、astahのモデル自身も、SubversionだけでなくGitで構成管理できるようにするのが1つの課題ではないか、と思う。

Subversionプラグイン | Astah

astahの品質スイートプラグインとSVNプラグインが凄い: プログラマの思索

TortoiseSVNでastahファイルのリビジョン間の差分を表示する方法: プログラマの思索

また、astahのモデルに要望や課題、仕様追加を反映していく作業と、astahのモデルの変更箇所をRedmineチケットを経由してリンクさせるような仕組みも必要ではないか、と思う。

Enterprise Architectでは、RedmineやTestLinkと連携するプラグインがあるので、astahでも実現してもいいはずだ。

Enterprise ArchitectとRedmineを連携するアドオン: プログラマの思索

TestLinkとEnterprise Architectを連携する: プログラマの思索

【5】astahには、たくさんの可能性があると思っている。
astahを使ったモデル、そのモデルを保証するプロセスの連携方法は、もっといろんなアイデアがあるはずだし、色んな実装方法があるはずだ。

近々、astahの勉強会を開くので、色々議論してみたい。

astah関西 第1回勉強会 - connpass

【追記】
似たようなことは既に他の人も考えている。

Astah*GSNより、ASCEのほうが、ビジネス的には、大きく出来る・・・ - ウィリアムのいたずらの開発日記

Astah GSNが、UML、SysMLと連携してほしい人! - いっぱい!! - ウィリアムのいたずらの開発日記

| | コメント (0)

2017/06/11

【告知】astah関西 第1回勉強会を7/14金に開催します #astahkansai

astah関西 第1回勉強会を7/14金に開催します。

【参加申込み】
astah関西 第1回勉強会 - connpass

astah*Professionalファーストインプレッション: プログラマの思索

Enterprise Architectの使い方のリンクとメモ: プログラマの思索

astahによるモデリングのメモ: プログラマの思索

(引用開始)
関西圏でモデリングツールastahを使ったモデリング技法と実践事例に関する勉強会を開催します。

astahを使っている人、モデリング大好きな人が集まって、より良いモデリング技法や実践事例を共有する場として設けます。

モデリングの対象は、astah製品を使った設計技法が中心なので、UMLに限らず、ER図やDFDなどのデータモデリング、SysMLなどの組込ソフトウェア設計なども含む予定です。

興味のある方は、ふるってご参加ください。

<テーマ>
キックオフを兼ねた第1回勉強会を開催します。

チェンジビジョン(株)の方にも来阪して頂いて、astah製品の紹介と実際のモデリング技法について講演して頂きます。

次回の参加希望者が多ければ、勉強会スタッフを募集して継続します。
(引用終了)

【開催の発端】
僕自身は、Judeの頃から使い始めて、astah Professionalを2009年から使い続けています。
主な使い道は、UMLのお勉強が発端で、その後は、システム提案や要件定義の時のラフスケッチ、開発プロセスの運用ルール策定やプロセス分析です。

過去に、RationalRoseやEnterprise Architectを開発案件で使用した経験はありますが、正直使いづらかった。
2000年代中頃は、UMLがブームで、設計フェーズをUMLのダイヤグラムで代用する思想が多かったけれど、たくさんの修正が発生したら、ダイヤグラムのマージが面倒で、複数人でダイヤグラムを共有して作業するのも難しい。
結局、astahでも、個人で使用する場面が多いです。

astah Professionalの良い所は、頭の中にあるモヤモヤした内容をUMLの各種ダイアグラムでラフスケッチを即座に描ける点。
1つの問題や事象を、複数の観点の動的・静的ダイヤグラムで描いて、整合性や詳細を詰めていくことが自然にできる点が良かったと思います。
絵で描くと、このI/Fの仕様が甘い、とか、このプロセスは意外に複雑だな、とか、色々気づきが得られやすい。

また、Redmineの運用ルールを説明する時、運用フローをアクティビティ図やステートマシン図で描くと、他人に説明しやすい。
誰とキャッチボールするのか、何がトリガーになるのか、が明確になる点が良いです。

さらに、過去にアジャイル開発やRedmineコミュニティで数多くの発表を行った時、astahで事前に書き溜めたラフスケッチがとても役立ちました。
そういう経験をしてきて、astahによるモデリング技法を周囲の人達と共有したいという気持ちが以前からあって、周囲の後押しを元に、ようやく実現する運びになりました。

僕の周囲ではそもそも、astahを使っている人がいないので、この勉強会が継続できるか分かりません。
関西で、astahを使っている人、astahに興味がある人、UMLやDOAや組込ソフトウェアのモデリング技法に興味がある人が集まるといいな、と思います。


| | コメント (0)

2017/06/01

TestLinkにExcelのテスト項目書をインポートする方法

TestLinkにExcelのテスト項目書をインポートする方法の記事があったのでメモ。

【参考】
【TestLinkでナレッジ蓄積】Excelからテスト項目書をインポートする方法 | Ques

MrBricodage/TestLink--ExcelMacros: Excel files containing Macros that handle XML files compatibles with TestLink

TestLinkのインポート用ExcelマクロImportExcelMacroのリンク: プログラマの思索

TestLink

(引用開始)
TestLinkはExcelから直接インポートできない

TestLinkのインストール作業手順は、インストール方法の記事や書き込みが多いため、
ここでは省略させて頂きます。

TestLinkを使う上で苦労した点はテスト項目書からのインポート作業になります。

TestLinkへインポートするにはXML形式に変換する必要があります。
弊社のテスト項目書(ナレッジ)の多くはExcelで作成されており、
Excelの内容は直接TestLinkへインポートすることができません。
TestLinkへインポートするには、一度、Excel形式からXML形式に変換する必要があります。
TestLink上にて、テストケースを手入力で入力することは可能ですが、
数あるテスト項目書を手入力で行うと時間がかかるため、
短時間で行うには補助ツールが必要になります。

テスト項目書のインポート/エクスポートを補助する便利ツール

ExcelからXMLに変換し、XMLからTestLinkへインポートするには、
Excel→XML変換ツールが必要になります。
また、TestLink上のテスト項目書を編集する場合、
TestLink上よりもExcel上で編集できた方が楽です。
TestLinkにはエクスポート機能があり、実行するとXML形式で保存できます。
エクスポートデータをExcelで編集するにはXML→Excel変換ツールが必要になります。

そこで、下記の両方を行うことができる補助ツールを探してみました。

Excel→XML変換
XML→Excel変換

昔は「TestLinkCnvMacro」という補助ツールがありましたが、今はありません。
今回は「TestLinkCnvMacro」の代わりに、
海外のツールですが、「02-ImportTestCasesIntoTestLink.xls」を使います。
(引用終了)

02-ImportTestCasesIntoTestLink.xlsの使い方は、上記の記事にある。

TestLink上からXML出力
→encoding=”UTF-8″を”Shift-jis”に変更して保存
→文字コードを「Shift-jis」にして保存
→02-ImportTestCasesIntoTestLink.xlsへインポート

02-ImportTestCasesIntoTestLink.xlsからXML出力
→encoding=”ISO-8859-1″を”UTF-8″に変更して保存
→文字コードを「UTF-8」にして保存
→TestLink上でXMLインポート

| | コメント (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勉強会で講演してくれないかな?

| | コメント (0)

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