日本の大企業におけるRedmineの利用事例の資料のリンク

最近、日本の大企業におけるRedmineの利用事例がPDFでネット上にかなり公開されている。
後々の自分のために、資料のリンクを貼っておく。

【例1】JAXA(宇宙航空研究開発機構)によるスパコン運用部門でのRedmine利用事例。

“CODA” チケット管理システム | JSS2@JAXA

JAXAのRedmine利用事例の講演資料がWeb公開されました: プログラマの思索

CODA: JSS2の運用・ユーザ支援を支えるチケット管理システム: Redmineの事例と利用のヒント

主用途はソフトウェア開発ではなく、スパコンに関わるさまざまな運用業務の管理に使われており、課内のみならず関係ベンダーともRedmineで情報共有をしている、とのこと。
Redmineの機能をレイヤ構造で十分に分析した後で、業務へ適用した点が素晴らしい。

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

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

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

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

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

【例2】パナソニックにおけるソフトウェア開発のPJ管理の事例：
開発現場を救うプロセス改善の進め方 - SPIJapan2014

パナソニックの子会社におけるRedmineの利用事例が3つほど公開されている。
一つは、CMMIレベル4を目指して、Redmineを導入して課題解決を図っている。

改善前の状態の問題点として、下記が挙げられている。

・壮大な改善計画の立案のみが存在
・膨大な標準帳票が存在
・職人気質な優秀なメンバーに頼ったプロジェクト運営

この問題点の原因分析を読むと、日本のほとんどの企業に当てはまる問題ではないか、と食い入るように思えてしまう。

そういう問題点がRedmineを導入したことで解決の目処が経ったことを考えると、CMMIレベル4における定量データの収集・分析・是正のレベルは、Redmineのような定量的プロジェクト管理ツールという運用基盤が必須である事実を示唆しているように思える。

また、Redmineに不足した機能として、「親子チケットの関係を持った一括インポート」機能を別で実装した点も参考になる。
階層化されたWBSを一括インポートしたい意図は、WF型開発では十分にあるから。

【例3】パナソニックにおけるオフショア開発のPJ管理の事例：
海外開発拠点におけるソフトウェア開発プロセスの確立 - SPIJapan2015

こちらは、シンガポールのオフショア開発のPJ管理に適用した事例。
「ソフトウェア開発業界でデファクトスタンダードになっているRedmineを導入」という文章を読むと、そうなのか、と改めて気づく。
Redmineの適用方法として「No Ticket, No Commit」を徹底させた点がとても参考になる。

【例4】パナソニックにおける多部門連携のソフトウェア開発の利用事例：
複数部門にまたがったシステム・ソフトウェア開発プロセス改善の取り組み - SPIJapan2016

複数の部門と連携したソフトウェア品質改善のバックグラウンドで、Redmineを利用している事例。
資料のメインは、ツールよりも、組織面や運用面のお話。

【例5】島津製作所における大規模組織の内部統制へ適用した利用事例：
｢効率･品質･統制｣の共通課題に着目した現場主導による ITS 導入事例～OSS 運営ツールで効率的・低コストな導入を実現～　(IPA　「先進的な設計・検証技術の適用事例報告書 2016 年度版 」)

｢効率･品質･統制｣の共通課題に着目した現場主導による ITS 導入の効果検証～SQIP2014

ソフトウェアの品質向上に資する開発・運用現場の情報管理～現場主導によるITS導入～JASST関西2013

SQIP2014の論文「「効率、品質、統制」の共通課題に着目した現場主導によるITS導入の効果検証」がすごい #redmine: プログラマの思索

チケット駆動でソフトウェア開発のメトリクス分析を行うアイデア: プログラマの思索

Redmineの理想と現実～RxTStudy #12 「ITS活用最前線～現場からの実践報告」の感想: プログラマの思索

@akahane92さんが中心で行われた大規模組織の内部統制の利用事例。
何度も内容は聞いているけれど、個人的にいつも気になる点がいくつかある。

一つは、ITSMSやISO9001で要求されるOffice文書は、どのように構成管理されているのか？
普通は、共有ファイルサーバーに配置しているので、履歴管理されていない。
一方、SVNでOffice文書を管理するのは可能だが、SVNリポジトリが膨大なサイズになるし、大容量ファイルをコミットする時にSVNへ負荷がかかるデメリットがある。

もう一つは、チケットだけでなく、ソースやOffice文書も含めた全文検索のインフラはどのように構築しているのか？
ITSMSやISO9001の内部監査では、1～2日の間に、内部監査員から要求された文書を証跡として、素早く提出して確認を取る必要がある。
その証跡が提出できなければ、正しいプロセスを踏んでいない、という印象を監査員から持たれてしまう。

つまり、障害や仕様変更などの事案に対し、それと関連付けられたチケット、ソース、Office文書を即座に検索して検索結果を得る必要がある。
そのインフラは、「No Ticket, No Commit」という手動の運用ルールに紐付けられたトレーサビリティだけで十分か？

そんな疑問が思い浮かぶけれど、これだけ大規模な運用で成功している事例なので、裏では相当濃いノウハウがあるに違いないと思う。

【例5】電子楽器の商品価値を高めたモデルベース開発フレームワーク

組込みソフトウェアの派生開発、プロダクトライン型開発にRedmineを導入した事例。
プロセスよりもソフトウェア設計に力点を置いている。

「Redmineを変更管理に適用」、
「チケット駆動の大規模反復型開発」、
「コードのみならず全文書をSubversion管理とRedmine連動によるトレーサビリティ実現」
の部分がすごく気になる。

【例6】「チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験」

Redmineをソフトウェアプロダクトラインの開発基盤として構築しようとモデル化してる、とても野心的な事例。
ソフトウェアプロダクトラインは、ソフトウェアモジュールをハードウェア製品の部品のように、共通部品と可変部品に分けて、部品を組み立てるようにモジュール生産したい、という発想。

その場合の課題は、ソフトウェアアーキテクチャを共通部分と可変部分にどのように分けるか、という点だろう。
ソフトウェアをそんなに綺麗に分けられるのか？

また、コア資産とアプリケーション資産に分別した場合、それぞれのソフトウェア資産に対する開発プロセスは明確に分けて、かつ、緊密に情報連携させるにはどのような仕組みが必要なのか？
その開発プロセス基盤にRedmineを導入した場合、コア資産とアプリケーション資産をどのようにRedmineにマッピングし、どのように運用するのか？

次回5月の第12回勉強会 - redmine.tokyoで講演していただくので、内容がとても楽しみ。

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

【追記２】気象庁でもRedmineを利用している事例の資料が公開されている。
複数のRedmineインスタンスを立ち上げて、故意に複数インスタンスで利用されている点が興味深い。

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

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

「Git と Redmine を用いた気象研究所共用海洋モデル」の論文のリンク: プログラマの思索