Redmine

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)

2017/05/14

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

第12回東京Redmine勉強会では、講演者、参加者、スタッフの皆さん、お疲れ様でした。
大雨の土曜日のために、突然キャンセル40人以上発生したにもかかわらず、参加率90%という驚異的な勉強会。
感想をラフなメモ書き。
間違っていたら後で直す。

【参考】
第12回勉強会 - redmine.tokyo

第12回東京Redmine勉強会 - Togetterまとめ

第12回東京Redmine勉強会の見所: プログラマの思索

akipiiさんのツイート: "#redmineT 東京Redmine 勉強会から離脱しました。今日は参加率90%で驚異的でした。ディスカッションでは土木建築、デザイナー、ゲーム、メーカーなど多様な業界でRedmine が使われてた。レベル別、セグメント別で議論して、Redmine の運用方法を洗い出してみたい"

【1】@g_maedaさんの発表は、3月のRedmine大阪の発表の改良版。
気になる点は、最後の「Redmine3.4.0になれなかったパッチたち」。

サイドバー折り畳みは、欲しい。
PCの画面が小さいと、フル画面でチケット一覧を見たくなる。
チケット一覧の表示項目が増えると、横スクロールが必要になって、うっとうしい。
また、スマホ、タブレットなど数多くの閲覧媒体が増えてきているので、レスポンシブ対応だけでなく幅広く対応してほしい。

コードハイライト言語を増やす機能追加も早くやってほしい。
特に、VB、C#のコードハイライトがない、という要望は従来からすごく多い。

バージョン内のチケットのD&D機能も早く追加してほしい。
アジャイル開発におけるプロダクトバックログの精査の作業に直結する作業だからだ。
つまり、チケットのリリースの優先順位づけを並び順で表現することは、リリース計画をプロダクトオーナーと開発者が共有しやすくなる点にも直結する。
アジャイル開発の観点では、チケット一覧画面よりも、ロードマップ画面の改良にもっと力を入れて欲しい。

【2】@Madowindaheadさんの講演では、チームの変化やチームの成長を活動画面から事前調査して、支援しているとのこと。
この部分はRedmineの優れた機能そのものだし、チームの成長がRedmineに記録されていく点はチームのモチベーションにもつながるだろう。

あさこさんのツイート: "「決定に関する内容も分かります」 活動内容をどういう粒度で記入するかをしっかり決められているいい事例ですね!! #redmineT"

akipiiさんのツイート: "#redmineT 成長していることを、変化していることで捉える。まさにRedmine の得意なところ"

また、PMxTMのポジショニングマップが重要だと思う。
縦軸=PM技術力、横軸=ツール利用度で、開発チームや開発メンバーをプロットして、どこのセグメントが問題なのか、あるべき姿へどうやってマネジメント力を向上させていくべきか、という観点で分析するのに使える。

特に、Redmineを導入したけど、社内でなかなか広まらない、という時に、どこのセグメントに問題があるのか、という分析のヒントになるだろうと思う。

スライドで面白い点は、社内でRedmine利用度を上げることでマネジメント力を向上させるパターンを経験上3種類あげている点だ。

一つ目は、PM力が大変低く、ツール利用経験も大変低い層。
このセグメントは、「目標になるメンバーと一緒に成長ラインに乗せる」。
つまり、新入社員のように、まだ技術もPMの経験が浅い人は、OJTのような仕組みが有効なのだろう。

二つ目は、PM力は中間くらいだが、ツール利用の経験が浅い層。
このセグメントは、「この位置のメンバーは成長ラインに乗せやすい」。

その理由は、既にマネジメントの経験があり、PMにひつようなスキルや概念はある程度分かっている人たちなので、そのスキルを生かしやすい環境としてRedmineを提供すれば、自分たちで問題解決していけるようになるはず、ということだろうと思う。

三つ目は、PM力は高いが、ツール利用度が大変少ない層。
まさにExcelおじさん。
このセグメントは、「メンバーの成長を意識させることで、成長ラインに乗せる」。
この点は、なるほど、と思う。

このセグメントは、自分たちのやり方を持っている人が多いので、なかなか新しいツールを使ってくれない。
でも、自分の立ち位置やメンバーへの影響力は、自分でも分かっている人が多い。
すると、自分がRedmineを使わなくても、メンバーがRedmineを使って自然に成長していけば、自分もちょっとはやってみようか、という気になるのだろう。
つまり、いきなりツールを使いこなせ、とトップダウンでやるのではなく、ボトムアップで攻めていくわけだ。

このパターン集で面白いのは、4象限のうちの右下の部分「ツール利用は多いがPM経験が少ない」セグメントのパターンがないこと。

講演でちょっと触れていたが、このセグメントはヒントを与えたり、支援すれば、自力で解決していってくれる。
個人的には「プログラマ上がりのプロジェクトリーダー」が多いのではないか、と想像する。
そういう人たちには、得意とする技術力をベースとして、Redmineでマネジメント経験を増やしていけば、自然に力が付くのではないか、と想像する。
僕自身もそういう経験があった。

【3】@ktohさんのRedmine全文検索プラグインの話も興味深かった。

たとえば、チケットが数十万枚、数百万枚に増えた場合、それらチケットやWikiなどの情報を、欲しい時に即座に検索できる機能は、Redmineをナレッジシステムとして使うために重要な機能と考える。
Ver3.3では、右上の検索ボックスは表示中のPJだけにデフォルトで絞り込み検索するので早くなっているが、全PJ横断の検索はまだ遅い。
そのような問題を解決するプラグインなので、Redmineをナレッジシステムとして価値を向上させるために有用な機能だと思う。

Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索

Redmineの全文検索を高速化するプラグインfull_text_searchのリンク: プログラマの思索

全文検索プラグインで興味を惹く点はいくつかある。

一つは、検索ノイズがなく、ランク別・更新時刻順に表示される点。
Groongaという拡張DBエンジンを使うので、スコアを調整して、有用な検索結果を上位N件に表示してくれる。
注目すべき点は、デフォルトの全文検索結果と全文検索プラグインの検索結果は、件数は同じでもソート順が違う点。
つまり、Google検索みたいに、役立ちそうな情報が上位に表示されるので便利。

また、Google検索のように、AND・OR・NOT検索ができるのも便利。
たとえば、「(Groonga OR Mroonga) -PostgresSQL」みたいに、GroongaまたはMroongaを含むがPostgresSQLを含まないように検索できるらしい。
この機能が検索で使えるならば、過去の障害や仕様変更の履歴を探したい時に、より詳しい検索条件で書けば、より早く到達できるようになるだろう。

さらに、更新時刻順にソートできるのもうれしい機能だ。
検索したい状況をふりかえると、直近で自分や他の担当者が書いた内容を検索したい時が多いからだ。
直近の障害情報、直近の課題やQAを見つけたい時が多いから。

二つ目は、高速である点。
この内容は、既に@akahane92さんがツイートされている。

Kuniharu AKAHANEさんのツイート: "200万チケット@MySQLでやってみたよ。検索時間は約380ms。 #Redmine の未来が広がって嬉しいな。ありがたいな。/Redmineで高速に全文検索する方法 - ククログ(2016-04-11) https://t.co/s7FA4gSThu @_clear_code"

neta@世界は私のオイスターさんのツイート: "@akahane92 さん! 今クリアコードの人が 赤羽根さんの全文検索380ms のツイート紹介してました。プラグイン適用前の処理時間を知りたいらしいですよ! #redmineT"

Kuniharu AKAHANEさんのツイート: "@netazone (ご参考まで) Redmineチューニングの実際と限界 / https://t.co/fRU2MvH4my の114ページです。"

三つ目は、まだ未実装だが、類似チケットの検索。
これは、Amazonのお勧め商品表示と同じく、協調フィルタリングとか機械学習みたいな機能を使って、この障害チケットに似た過去のチケットはこれこれです、みたいに表示する。
たとえば、障害チケット起票時に、過去の類似バグを表示してくれると嬉しいだろう。

四つ目は、まだ未実装だが、検索ボックスやチケットのタイトル欄などで、入力補完する機能強化。
これは、PJプルダウンのインクリメントサーチのように、検索ボックスで1文字入れたらGoogle検索みたいにコードアシストしてくれる機能みたいなイメージ。
この機能があれば、チケット内容の入力間違いを減らせるし、途中までの文字入力で自動補完してくれるので、チケット入力コストをかなり減らせるはず。

つまり、ただでさえチケット入力は鬱陶しい、と言われがちな弱点に対し、検索エンジンの強化によって入力補完をサポートすることで、チケット入力者の作業コストを減らし、チケットの内容の精度向上に役立てることができるわけだ。

この辺りの機能を欲しいと思う日本人ユーザ、Redmine利用企業は意外に多いのではないだろうか。
なぜなら、Redmineを利用している現場は増えているし、すでに数年以上運用してかなりの枚数のチケットを蓄積している日本企業も多いと思うからだ。
@ktohさんが支援を要請しているので、興味のある人は声掛けしてはどうだろうか。

すさんのツイート: "第12回https://t.co/YxfaKONoze勉強会の「GroongaでRedmineを高速全文検索」の資料です!今後の野望を一緒に実現したい人はぜひ連絡をください! https://t.co/FEBfQvAVk4 #redmineT"

今後の野望については、下記の記事でアップされている。

redmine.tokyo第12回勉強会:GroongaでRedmineを高速全文検索 #redmineT - ククログ(2017-05-15)

なお、AWSへのセットアップでは、下記のツイートがあるので注意。

Kawabata Mitsuyoshiさんのツイート: "AWSだとmroonga入れられないという質問があったが、最近だとRDSから、MySQL on EC2にmaster-slaveでレプリケーションして、MySQL on EC2側で検索処理するが定石っぽい #redmineT https://t.co/SwD3IFyeVt"

MAEDA, Goさんのツイート: "Redmine本体は現状PostgreSQL推奨です。MySQL 5.6以降だとデッドロックが発生するケースがあります。 #redmineT https://t.co/zRSmVfGY8T https://t.co/y9KtUtJ8SG https://t.co/AS0A6KDeaZ"

【4】宮本さんの「チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験」も興味深かった。

ストーリーとしては、既にRedmine+GitLab+Jenkins+Maven+Artifactoryという開発環境がそろっていて、その上にプロダクトラインのプロセスを実装しようとするお話だった。
お話としては大変興味深いのだが、肝心のRedmineの機能にどのようにマッピングさせたのか、という点はぼかされていて、分からないところが残念笑。

但し、講演中の一言「Redmine が要件、タスクなどエントリーポイント。MavenやArtifactoryがプロダクトラインでは肝となる所」という話から想像すると、こんな感じかな。

akipiiさんのツイート: "#redmineT Redmine が要件、タスクなどエントリーポイント。MavenやArtifactoryがプロダクトラインでは肝となる所。プロダクトそのものの構成管理がやりたいからだろう"

Redmineには、要件や仕様、それに基づくタスク・課題・障害の情報は一元管理されていて、そのチケットから作業は駆動される。
そして、ソースや設計書などの成果物はGitLabで構成管理されていて、複数の製品ファミリーはGitのブランチで管理されている。

その時、それぞれの製品ファミリーのリリースされたソフトウェア製品は、バージョンでタグ付けされて、それらはArtifactoryでビルドモジュール単位のバージョン管理がなされている。
つまり、各製品は、共通ライブラリやコア基盤となるようなビルドモジュール(たぶんJarやWar)とアプリケーション資産(これもJarやWar)がパッケージングされていて、各製品がリリースされたタイミングで、共通ライブラリのどのバージョンに依存しているか、はMaven+Artifactoryで構成管理されているのだろう。

つまり、ソフトウェア製品とソフトウェアモジュール(汎用ライブラリ)は、ビルドモジュール単位で構成管理されていて、その構成管理が重要、ということなのではないだろうか。
この考え方はちょうど、業務システムがOracleやApache、.NET Frameworkの特定のバージョンに依存して作られていて、それらも含めて構成管理されている、みたいな考え方と同じではないだろうか。

すると、Redmineにある発端となった要件や仕様から、それに紐づくソース、そこからビルドされてリリースされたソフトウェア製品へトレースできる(後方への追跡性)し、逆に、あるバージョンのソフトウェア製品から要件までトレースできる(前方への追跡性)。

そのような開発プロセスを作りたい、という動機も別途あるのだろうと推測する。
そして、その仕組みは、Redmineのチケット管理や構成管理ツール連携という機能を使えば、チケット駆動のトレーサビリティ機能が導出されて実現できる、みたいなストーリーではないだろうか。

チケット駆動開発を要求工学の品質特性の観点から考える~チケット駆動開発がAgile開発を必要とする理由: プログラマの思索

【5】講演資料はコチラ。

| | コメント (3)

2017/05/05

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない

「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」を気軽に読んでいたら、ブルックスの人月の神話の一節が書かれていて、今頃になって、すごく腑に落ちたのでメモ。
ブルックスの人月の神話の文章のうち、自分が理解できたことを、ラフなメモ書き。
以下は書きかけ。

【参考】
第0回:人月の神話とはなんなのか?(解説編)|本気で読み解く”人月の神話” | GiXo Ltd.

第2回:銀の弾は無いけど、”銃”はあるよね|本気で読み解く”人月の神話”(第16章) | GiXo Ltd.

ソフトウェア開発とは、現実世界の複雑さをプログラムコードの難しさに置き換える作業だ - セカイノカタチ

ソフトウェア開発でよく言われる「銀の弾丸など無い」とはどういう意味なのか本を読んでみた。 - 感謝のプログラミング 10000時間

【1】ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。

「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」の内容自体は10年以上前のWebやIT業界の話が多く、内容も古くなっているので、新たな知見が得られるという感覚はしない。
しかし、「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」の中に、「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」という言葉があって、すごくしびれた。

(引用開始)
ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。
したがって、複雑性を取り去ったソフトウェアの実体の記述は、しばしばその本質も取り去ることになる。
数学や物理学は、複雑な現象を単純化したモデルを構成し、そのモデルからある性質を引き出し、実験的にその性質を証明することで、3世紀にわたって偉大な進歩を遂げた。
この方法でうまくいったのは、モデルで無視された複雑性が現象の本質的な性質ではなかったからだ。
複雑性が本質である場合には、この方法は使えない。
(引用終了)

上記の内容は、ブルックスの「人月の神話」の一節そのまま。
なぜ自分がすごく衝撃を受けたのか、考えてみると、ソフトウェア開発の本質に触れているものだから。
たぶん、僕の心のなかにある、ソフトウェアに対する楽しさだけでなく、ソフトウェアへの憎しみというか、なぜこう思い通りにソフトウェア開発をコントロール出来ないのか、という腹立たしさに触れている気がしたから。

「偶有的」という言葉も引っかかる。
この言葉は、古代ギリシャのアリストテレスの哲学から引用したものらしい。

(引用開始)
アリストテレスに従って、難しさを本質的なものと偶有的なものに分けて考えてみよう。
ここで、本質的な複雑さとは、ソフトウェアの性質に固有な困難のことであり、偶有的難しさとは、目下の生産にはつきまとうが本来備わっているものではない困難のことである。
(引用終了)

自然科学、特に数学や物理学では、できるだけ単純なモデルを作り、そこから演繹される性質や定理を証明することで、自然現象を多面的に分析しようとする。
複雑なものを複雑なまま捉えるのではなく、理想的な単純なモデルに純粋化して、人間の思考に耐えられるレベルにして、数多くの観点で徹底的に分析するのが自然科学のやり方。
シンプルなモデルを「徹底的に」分析し尽くして、全ての特徴を洗い出し、全てを因果関係や演繹でまとめ上げて一つの理論体系にするのが自然科学のやり方。

すると、シンプルなモデルをどのように事前設定するか、どのパラメータを重視して選択しておくか、というのが重要になる。
その部分が、科学者の腕の見せ所。

たとえば、物理学では、理想気体みたいに、現実から離れるけれど、シンプルなモデルを設定することで、計算や実験を扱いやすくするモデル作りは一般的だ。
熱力学、相対性理論、量子力学など、色んな分野の物理学でもその手法を用いている。

物理学は一つの認識論: プログラマの思索

数学でも、一流の数学者は、自分で理論を打ち立てたい時、最も組合せの少ない公理や公準を直感的に選んで、そこから矛盾が生じないように設定しておく。
そこから、「誰々の定理」のような重要な結果を導き出す。
一流の数学者がすごいのは、最も組合せの少ない公理を直感的に把握できること、そして、重要な定理を導く時に、ロジックの穴になりそうな難しい場所を事前に察知して、それをくぐり抜けるために、あらかじめ「誰々の補題」みたいな補助的な公式を用意しておくのが上手い点。

技術の背後に数学の理論があると廃れない: プログラマの思索

数学や物理は背景にある思想を知らなければ理解できない: プログラマの思索

このやり方がすごく成果を上げているので、人文科学や社会科学でもそのやり方を真似ているように思える。
特に、経済学は典型的だろう。
マクロ経済学やミクロ経済学みたいに、人間は合理的に行動する、とか、市場の価格は恣意的な手段で決めても長続きせず、神の手(つまりは市場原理)で決まる、みたいに、現実とかけ離れた仮定をおいて、数多くの経済モデルを作り、そこから重要な経済学の定理を導き出す。
単純な経済モデルから得られた経済学の定理で現実に通用する場面が過去にあったから、経済のグローバル化が世間に言われ始めてから、世の中の経済事象は、市場原理で決まる、いや決めるべきだ、みたいな論調が多い気がする。

経済数学の直観的方法の感想: プログラマの思索

「推計学のすすめ」「経済数学の直観的方法~確率統計編」の感想: プログラマの思索

しかし、ブルックスの「人月の神話」では、ソフトウェアにはそのやり方が通用しない、という指摘をしている。
「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」からだ。
つまり、複雑性を排除したソフトウェアは、ソフトウェアの本質を意味しないからだ。

【2】ソフトウェアの本質的な複雑さと、偶有的な複雑さの違いは何か?
ソフトウェアの本質的な複雑さは、リーマンの法則そのものを指すと思う。

リーマンの法則~ソフトウェアもエントロピー増大の法則を避けられない: プログラマの思索

リーマンの第1法則
 使われるシステムは変化する。
リーマンの第2法則
 進化するシステムは複雑性を減らす取り組みをしない限り、システムの複雑性が増す。
リーマンの第3法則
 システムの進化はフィードバックプロセスによって決まる。

(引用開始)
レーマンとベラディは、大規模なオペレーティングシステムのリリースについて、継続してその変遷を研究してきた。
そこで分かったことは、モジュールの総数はリリース番号とともに線形に増加するのに対し、影響を受けるモジュールの数はリリース番号に対し指数的に増加するということだ。
(中略)
システムプログラムの作成は、エントロピーを減らす仮定だから、本来は準安定なものである。
他方、プログラムメンテナンスはエントロピーが増加する過程であり、どんなに器用に行なっても、できるのはシステムが修正不能な陳腐化へと沈んでいくのを遅らせることだけである。
(引用終了)

(引用開始)
ソフトウェア製品開発に関する古典的問題の多くは、その本質的な複雑性と、ソフトウェアの大きさに従ってその複雑性が非線形に増大することに由来している。
(引用終了)

この文章を読んで思い出すのは、ケント・ベックがXPを生み出した経緯のことだ。
ケント・ベックは、ソフトウェア工学の授業で習った、リリース総数が増大するにつれてソフトウェアの複雑度や変更コストが増大していく経験則に対して、異議を唱えた。
時間が進むに連れて、この曲線を頭打ちにできるような開発プロセスはないのか、と。

- eXtreme Programmingの魅力を探る オブジェクト倶楽部

(引用開始)
「変化ヲ抱擁セヨ」
この呪文めいた言葉は,Kent Beck による本の副題として掲げられている. 時間を横軸に,ソフトウェアの変更にかかるコストを縦軸にプロットする.
この「時間-変更コスト」曲線は極端な右上がりになると信じられて来た(図左).
すなわち,要求分析,設計,実装,テスト,保守,と時間が進むにつれ, 変更にかかるコストが増大するというのだ.
現在までのソフトウェア開発プロセスは,この仮定上の議論が多数 だったのである.
XP はこの曲線を平坦にできるのではないか, また,そうできたとしたら,全く違った方針でプロジェクトに立ち 向かえるのではないか,という挑戦をしている(図右)
(引用終了)

こういう素朴な問題意識はすごく重要だと思う。
XPがその理想を本当に実現したのかどうか、は検証がいると思うが、そういう背景を元にアジャイル開発のプラクティスが生まれたことは、アジャイル開発が従来のソフトウェア工学と対立しがちに見える傾向を示唆しているように思える。

ちなみに、上記の第1版の「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法」に、上記の「従来のソフトウェア工学が提唱しているソフトウェア複雑性へのXPの果敢な挑戦」の文章と図はあるのに、第2版の「エクストリームプログラミング」から削られていることだ。
とても残念。
この部分がXPにとって一番重要な主張なのに。

【3】コードクローンと再利用性。

(引用開始)
ソフトウェア実体の本質とは、データセットやデータ項目間の関係、アルゴリズムや機能呼び出しなどが組み合わさったコンセプトで構成されたものである。
この本質は、同じ概念構造体が多くの異なる表現で表されるという点で抽象的である。
それにもかかわらず、非常に正確で十分に詳細なものである。
(引用終了)

コードクローンとは、同一アルゴリズムを各プログラマが別々の実装したプログラムのことだ。
上記は、ソフトウェアの複雑性が増大しがちな理由の一つは、コードクローンが大量に発生しがちである、と言う点を示唆していると思う。

ソフトウェア工学の論文を見ていると、コードクローンのメトリクス採取の記事が割と多い。
その理由は、コードクローンを減らす方がソフトウェアの複雑性が減るので、良い、という主張が隠れているのではないか。

では、なぜコードクローンは良くないのか?

(引用開始)
ソフトウェア実体は、どの2つの部分をとっても似ることがないので、大きさの割にはおそらく他のどの人工構造物よりも複雑なものだ。
似通っている部分があれば、2つの類似部分を1つにする。
この点において、ソフトウェアシステムは、重複要素(部品)が豊富なコンピュータやビルあるいは自動車などとは全く異なっている。
(引用終了)

その理由は、ソフトウェアの再利用が進まないからだ。
たとえば、自動車やパソコン、スマートフォンのような工業製品は、再利用可能な汎用部品を組み立てる手法と大量生産することを組合せることで、規模の経済を生かし、経験曲線効果を生かして、1個当りの製造コストを劇的に減らす。
しかし、この「規模の経済」「経験曲線効果」というコストメリットを享受しうる生産手法がソフトウェア開発には全くといっていいほど通用しない。

ソフトウェアを部品化して、スマートフォンみたいに部品を組み立てるように製造したい、と考えて、CORBAとかEJBのようなコンポーネント駆動開発、製品ファミリー群の製品開発手法であるソフトウェアプロダクトラインとか色々考えられたけれど、どれも実用的ではない。

ソフトウェア部品化の幻想: プログラマの思索

ソフトウェアプロダクトラインが解決しようとするもの~品質と再利用: プログラマの思索

だから、多額の資金を設備投資に投入して、最新の機械で汎用部品を組合せて大量生産する生産手法がソフトウェア開発には馴染まない。
ソフトウェア開発は徹頭徹尾、経験曲線効果すらも有効でない労働集約的な生産手法に似ているように思える。

【4】ソフトウェアの本質的な複雑性とは、同調性、可変性、不可視性。

【4-1】同調性は、リーマンの言う組み込まれた(Embeded)プログラム、を連想する。

「ソフトウェア・グラフィティ」の感想: プログラマの思索

(引用開始)
支配しなければならない複雑性の多くは気まぐれによるものだ。
インターフェイスを人間の社会制度やシステムに適合させるべく、いわば是非もなくそれらによって強制されているからである。
(引用終了)

最近、業務システムとかERPに僕自身が少し興味をなくしているのは、システム化したい業務そのものが元々複雑過ぎて、それを整理しようと言うよりも、現実の業務をいかに忠実にシステム化するかに注力する案件の方が多いからだ。
元々の業務が、日本的な複雑な組織体制を元に作られていれば、複雑なのは当たり前であり、それを忠実にシステム化するなら、複雑怪奇なままだ。
日本では、ERPをBPRとして捉えるよりも、自分達の業務中心に考えすぎているために、システムも複雑怪奇になりやすいような気がしている。

【4-2】可変性は、ソフトウェア品質の移植性や保守性を連想する。

アジャイル開発が重視する品質特性~保守性と移植性: プログラマの思索

(引用開始)
ソフトウェア実体は、つねに変更という圧力にさらされている。
(引用終了)

XPの言う「変化を抱擁せよ」と同じ。
ソフトウェアにとって、VerUpは宿命であり、常に変化が内在している。
ソフトウェアは変化しない固体として存在し得ない。

(引用開始)
純粋な思考の産物であってきわめて融通性に富んでいるので、ソフトウェアがより簡単に変更できるということもある。
ビルも現実には変更されるものだが、だれもが了解しているように、変更コストの高さが思いつきで変更しようとする者の気をくじく働きをしている。
(引用終了)

ソフトウェアに、仕様変更という名の保守はつきものだ。
それは簡単にできるように思えるから、簡単にソフトウェアに手を入れて、潜在バクを埋め込んでしまう。
ソフトウェア品質特性のうちの保守性を連想させる。

(引用開始)
大当たりしたソフトウェアはまずたいてい、すべて変更される。
あるソフトウェア製品が役立つと分かると、人々はもともと処理対象としていた領域ぎりぎりもしくはその領域を越えるような新しい使い方を試してみようとする。
主として、拡張機能のために変更して欲しいという圧力は、基本機能が気に入っていて新しい使い方を考えだす利用者から出される。
(引用終了)

これは、たとえば、Redmineが当初のバグ管理の使い方から、タスク管理、そして、アジャイル開発やWF型開発、さらには、事務処理ワークフロー、ハードウェア資産管理システムへ使い道がどんどん広がっていった事例を連想させる。
本来想定しなかった使い方が一般的になってしまい、その使い方をさらに使いやすくしたり、機能改善することで、ソフトウェアの複雑性がどんどん膨張する。
あらゆるソフトウェアは機能追加という変化にさらされている。

(引用開始)
大当たりしたソフトウェアは最初に書かれた対象である機械機器の通常の寿命よりも長く使用され続ける。
要するに、ソフトウェア製品はアプリケーションや利用者、慣習および機械機器といった文化的マトリックスにすっかりはめこまれているのだ。
そしてそれらは絶えず変化し続けるものであり、その経kながソフトウェア製品に容赦なく変更を強制するのである。
(引用終了)

たとえば、OSやDBやミドルウェアのバージョンアップとか。
あるいは、サーバー本体のリプレースとか。
たとえば、WindowsXP廃棄対応、WindowsServerのリプレース、OracleのVerUp、RailsのVerUpとか、iOSやAndroidOSのVerUpとか、色々思い出す。
つまり、ソフトウェア品質特性の移植性を連想させる。

こういうミドルウェアやOSのVerUpに伴うプログラム変更作業は、とてもしんどいものだ、と開発者なら誰でも知っている。
こういうつまらない開発基盤のVerUp作業は、ソフトウェアの外にある外部環境の変化によって生じるものであり、避けることは出来ない。

【4-3】不可視性は、ソフトウェア設計の難しさを連想する。

(引用開始)
ソフトウェアの構造を制限したり単純化したりすることは進歩したにもかかわらず、その構造は本質的に視覚化できないままになっている。
そのため強力な概念上のツールを作る意欲を阻害している。
その欠落は1人の人間の頭の中のデザインプロセスを妨げるばかりでなく、複数の人間の間でのコミュニケーションもひどく妨害する。
(引用終了)

UMLやDOAは、ソフトウェア構造を視覚化する問題を解決しようと試みていた。
SySMLもその流れだろう。

複雑性をコントロールするための設計技法は、歴史上いくつか考えれてきた。

たとえば、Nティア設計。
つまり、レイヤ化。

another level of indirection
「もう一段の間接参照」を導入すると、コンピュータのほとんどの問題は解決できる。

NFuji's Café: 「Beautiful Code」を読む(中)

ポインタを制する者はプログラミングを制する: プログラマの思索

MVCモデル、通信プロトコルの7層モデルもそういう考え方だろう。

他に、渡部幸三さんの観点でのDOAでは、業務・機能・データの3層構造の業務システムにおいて、業務レイヤとデータモデルのレイヤに複雑性を押しこんで、機能レイヤは複雑性をできるだけ減らす設計が良い、と提唱していた。
すなわち、機能レイヤはまさにプログラミングレベルなので、その部分の複雑性はできるだけ減らして保守性を高めようとする考え方。
つまり、複雑性というエントロピーは一定で変わらないと仮定した場合、人が携わる業務レイヤと、データモデルのレイヤに複雑性を落としこんで、複雑性をコントロールしようとするわけだ。

だが、これらの手法で、ソフトウェア本来の複雑性が本質的に解決されたのか、と問うてみると、正直分からない。

【5】一方、ソフトウェアの偶有的な複雑さは個別撃破している。

「高水準言語」は、たとえば、VBよりもRuby。
たとえば、VBはListやHashなどの基本ライブラリのAPIが非常に不足していて使いにくい。
たとえば、Rubyなら、そういう低レベルなライブラリは非常にAPIが揃っていて、VBよりも1行で書ける。
つまり、複雑性を軽減している。

「タイムシェアリング」は、たとえば、コンパイラ言語よりもインタプリタ言語、継続的ビルド管理、構成管理を指すのかな。

(引用開始)
考えていた内容をすっかりというわけではないが些細な点でどうしても忘れてしまう。
(引用終了)

この部分は、まさにソース管理、構成管理を連想させる。
たとえば、CVS、Subversion、Gitに至るまでの構成管理ツールの歴史を振り返れば、ソフトウェア開発プロセスにおけるブランチ管理、マージなどの作業の複雑性は軽減されている。

「統一されたプログラミング環境」はたとえば、VisualStudioやEclipse、IntelliJとか。

つまり、ソフトウェアを開発する作業そのものが生じる複雑性は、今までの歴史で生み出された技術によって、多少は軽減されてきた。
しかし、だからと言って、ソフトウェアの本質的な複雑性を攻略できたわけではない。
あくまでも、以前よりも大きい複雑なソフトウェアをコントロールできるようになった、というだけだ。

| | コメント (0)

2017/04/28

第12回東京Redmine勉強会の見所

来たる5月の第12回東京Redmine勉強会の見所をメモ。

【参考】
第12回勉強会 - redmine.tokyo

redmine.tokyo 第12回勉強会 - connpass

【1】今回のテーマは『みんなでRedmineプラクティスをシェアしよう』。

最近、IT業界にかぎらず、メーカーなどの他の業界でも、Redmineという言葉を聞く機会が多くなってきた。
チケット管理の適用シーンが増えていて、そのメリットを感じられる利用シーンも増えているのだろう。

そこで、Redmineの導入や運用の観点と、Redmineを支える技術面の観点の二つから、Redmineの利用事例を紹介できることになった。

【2】Redmineの導入や運用の観点では、まず、@Madowindaheadさんの「Redmineを活用したプロジェクトマネジメント技術向上について」がある。
@Madowindaheadさんは、PMOの立場として、プロジェクト管理の標準化や運用推進を担当されているとのことで、Redmineをベースにしたプロジェクト管理の社内説明会を過去2年以上実施されている、とのこと。
社内でRedmineの利用を推進して展開していくためのノウハウや、落とし穴に関するお話が聞けることを楽しみにしている。

過去のRedmine勉強会の参加者からも、社内でRedmineを使ってもらうにはどうすればいいか、という初歩的な質問も多い。
だから、Redmineを実際に導入したものの、全社的に展開していくためにはどんな手順やノウハウが必要なのか、という観点で聞けば、参考になるものが多いのではないか、と期待している。
3月のRedmine大阪のLT資料がダイジェスト版らしいので、参考にしたらと思う。

Redmineを活用したプロジェクトマネジメント教育について(ダイジェスト版)

【3】次に、宮本 陽一さん の「チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験」の講演がある。

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

日本の大企業におけるRedmineの利用事例の資料のリンク: プログラマの思索

JDMF2016講演『チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験』が気になる: プログラマの思索

ソフトウェア開発における派生開発やプロダクトライン開発にRedmineが有効に使えるのではないか、というアイデアについては、僕も過去に色々考えてきた。
たぶん、同じように感じている人達も多いと思う。

派生開発やプロダクトライン開発については、昔から沢山の人が開発プロセスは考えられてきたけれど、そのプロセスの実装が非常に煩雑、という問題があると思う。
その問題点は、複数の開発ブランチを並行開発できる構成管理と、要件からソース修正に至るまでのトレーサビリティの2点をいかにプロセスとして実装するか、という点で置き換えられると思う。

つまり、その2つの問題点は、Redmineの構成管理ツール連携と、チケット管理のトレーサビリティというRedmineの特徴を活かせば、たぶん解決できるはず、と直感している。

また、派生開発やプロダクトライン開発の別の観点では、複数の組織をまたがったプロジェクト管理をどのようにプロセスとして実装すべきか、という問題もある。
たとえば、複数の製品開発チームとコア基盤の開発チームがいかにスムーズに連携しながら、並行開発しながら、順次リリースしていくべきか。
たぶん、たとえアジャイル開発であったとしても、そのプロセスの実装はそう簡単ではないはずだ。

なぜなら、派生開発やプロダクトライン開発では、マトリクス型組織になりやすいため、ワンマンツーボスシステムの組織になりがちで、メンバーの観点では二人のボスの指揮命令系統に従わざるを得ず、混乱しがちだから。

この問題点に対しても、Redmineの複数プロジェクト機能を組織構造と上手く対応付ければ、運用するプロセスの実装はかなり楽になるはずだ、と直感する。

Redmineに向いている組織はPJ型組織やマトリクス型組織ではないかという仮説: プログラマの思索

すなわち、Redmineの柔軟な機能を上手くプロセスと組み合わせれば、プロセスの運用ルールをガチガチに固めなくても、自然に運用できるような雰囲気を作れるだろう、と直感している。
そういうことを考えながら、講演を聞いてみたいと思う。

【3】次に、須藤功平(@ktou)さんの「GroongaでRedmineを高速全文検索」の講演がある。
Redmineの全部検索を高速化するプラグインを実装公開されているので、利用者の観点でお話して頂く予定。

Redmineで高速に全文検索する方法 - ククログ(2016-04-11)

下記でも書いたけれど、Redmineのようなナレッジを蓄積するシステムでは、全文検索機能は他のシステム以上に重要な機能であると考える。
なぜなら、チケットやWikiにどんどん過去の作業の経緯や技術情報が記録されて蓄積されたとしても、その内容を即座に検索できなければ、過去の知見を有効活用できないからだ。
たとえば、3年前の障害に関連する情報を全文検索しようとして、3分以上も待たされたら、正直使いものにならない。

Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索

よって、このRedmineの全部検索プラグインは、Redmineをナレッジシステムとして有効活用するために、またそう感じることで利用ユーザのモチベーションを高めるためにも重要な機能であると思う。

また、@ktouさんは、Rubyコミッタの方でもある。
そして、Ruby本家もバグ管理をRedmineで運用されている。
色々お話が聞けるのでは、と楽しみにしている。

kou (Kouhei Sutou) - Ruby Issue Tracking System

OOエンジニアの輪! ~ 第 39 回 須藤 功平さんの巻 ~ | オブジェクトの広場

Rubyist Magazine - Rubyist Hotlinks 【第 36 回】 須藤功平さん

【4】その他にも、@g_maedaさんの講演やLT7本もあるので、盛りだくさん過ぎるほどだ。
参加者も既に定員オーバーで、静かに盛り上がっている。
当日の勉強会が盛り上がるのを楽しみにしている。

【追記】@ktouさん、@Madowindaheadさんの資料が既に公開されている。

| | コメント (0)

2017/04/13

Redmineを帳票ワークフローツールとして強化するstatus_buttonプラグインが面白い

Redmineでステータスに応じた担当者を自動設定するstatus_buttonプラグインなるものがあると知ったので、メモ。
稟議書申請・承認のような事務処理ワークフローで役立ちそうで面白い。

【参考】
QA #312: Redmineの画面上で、編集操作を行わずにステータスを変更+ステータスに応じた担当者自動設定 - Unofficial Redmine Cooking - redmine.tokyo

Status Button - Plugins - Redmine

fanzai0403/status_button: redmine plugin status_button

(引用開始)
Status Button プラグインで対応可能です。

・ステータス変更はボタン押すだけ(特に承認者)
・権限外のステータス変更は実行不可(標準のWF操作と同じ)
・次の担当者は最初にまとめて設定できる。(起票者が設定しておく)
(引用終了)

以前、Redmineを稟議書申請・承認のような事務処理ワークフローとして使いたい場合、どんな機能が必要なのか、を考察した時があった。

RedmineをBPMツールとして使うアイデア: プログラマの思索

Redmineは事務処理の申請承認ワークフローに使えるか?: プログラマの思索

Redmineにワークフローエンジンとして必要な機能~ワークフローに組織マスタの情報を持たせる: プログラマの思索

Redmineのワークフロー管理機能に分岐やロジックを追加するプラグインredmine_custom_workflows: プログラマの思索

Redmineのワークフロー設定を拡張する機能提案~Redmineは汎用的なBPMツールになりうるか: プログラマの思索

Redmineの現状の機能でも、簡易な帳票ワークフローツールとして十分に使える。
しかし、細かな操作性が不足しているので、そこが気になる場合がある。

僕が一番気になる点は、ステータスごとに担当者を絞り込んで表示して欲しい機能が不足している点だ。
課長承認、部長承認、経理承認のようなステータスでは、役職や権限を持つ人は限定されているので、その人達だけが担当者に表示されて欲しいのだ。

この問題は、上記のプラグインで解決できるみたい。
status_buttonプラグインで面白い点は、管理画面であらかじめ、ステータスごとにロールを設定する点だ。

つまり、課長・部長・経理のようなロールをあらかじめ作っておき、status_buttonプラグインの管理画面で、課長承認、部長承認、経理承認のようなステータスに各ロールを割り当てておく。
そうすれば、各PJでロールを人別に設定できるので、ステータス遷移できるロールの人だけ、承認操作ができる。
次のステータスは誰か、逐一考えながら設定する必要はない。

また、status_buttonプラグインでは、完了までの全ステータスが表示されているので、今後、どのようなワークフローを経由するのか一覧できて便利だ。

このような機能がRedmineに取り込まれたら、事務処理ワークフローとしてRedmineはほぼ使えるレベルになるだろうと思う。

Redmineが面白いのは、Redmineのデフォルト機能で、タスク管理以外のありとあらゆる雑務をWeb化して一括管理できる可能性を秘めている点だ。
業務改善というBPRの観点で、Redmine導入や運用を考えてみると、さらに面白いかもしれない。

| | コメント (0)

2017/04/03

チケット管理システムは作業の構成管理と同じ

Redmineのようなチケット管理システムは「作業の構成管理」という機能を提供しているのではないか、というアイデアをメモ。
ラフなメモ書き。

【1】2000年頃に「達人プログラマー」という黒本を買った。
当時は一流のプログラマになるためのバイブル本だった。

その中の一節に「ソースコード管理システムは、ソースのUnDo機能を提供するシステムである」という文言があり、すごく印象に残った時があった。

実際のプログラミングでは、自分の思考内容をソースコードに表すが、最初から一番良いソースが書けるわけではない。
試行錯誤しながら、ロジックを切り貼りしたり、分割したり、いじくったりする。
すると、その履歴を残したくなる。
途中で、テキストエディタでUndoやRedoするように、ソースコードも過去に遡ったり、途中のソースに戻りたくなるからだ。

つまり、ソースコード管理システムは「プロジェクトレベルでのタイムマシンというべき一つの巨大なUnDoキー」なのだ。

特に、昨今は、GitHubやGitを使っていると、masterとは別に、ブランチ上で新しい機能を実験しやすくなった。
また、たくさんのブランチを派生させても、あるタイミングでマージするためにプルリクエストを送ればいい。

【2】チケット管理システムがないプロジェクトで、作業管理を見ていると、作業の履歴やUnDo、ReDoが欲しくなる時がある。
ISO9001のQMSの運用を行なっている現場で、そんな状況を見た時がある。

ISO9001の品質管理マネジメントシステムでは、全ての作業は記録として残さなければならない。
普通は、作業依頼書のようなExcel帳票に、作業発生から作業終了までの履歴を記録する。

しかし、普通は作業依頼書だけでは話は終わらない。
Excel帳票としては、作業依頼書と、仕様変更の設計書やリリース手順書のような作業手順書とペアが必要になる。
実際の細かな仕様、詳細なリリース手順は、作業依頼書には書ききれないからだ。

それら2個のExcel帳票を、作業状況ごとに管理する必要があるが、これが結構面倒だ。
普通は、作業中のステータスで滞留しがちで、なかなか終了しにくい。
依頼する人と作業する人は別々なので、作業連携がすごく悪いからだ。
今、どの作業ステータスにあるのか、最新状態が反映できていない。

この問題の原因は、作業のステータス管理ができていない点にある。
それは、Excelの作業依頼書には判子欄があるが、それはRedmineのチケットのステータスと同じだ。
Redmineでやれば、すぐに解決できる。

また、Excel帳票の版管理で、依頼する人と作業する人が混乱する場合もある。

依頼する人は設計書を用意するが、割り込みの要望や考慮漏れで設計書を書き直したりする。
すると、どの設計書が最新版なのか、作業する人は混乱しがち。

この問題の原因は、設計書の版管理、つまり設計書のバージョン管理ができていない点にある。
結局、Excelの設計書もSVNやGitでバージョン管理すべき対象なのだ。

Excel帳票で作業依頼書と設計書をやり取りしているISO9001の運用では、プロジェクト数が増えるほど、混乱しがちになる。

【3】そんな状況を見ると、Redmineのようなチケット管理システムは、設計書のバージョン管理と同じように、作業のバージョン管理を提供しているように思える。

設計書のバージョン管理が必要な理由は、設計書の最新版がどれなのか、を明確にする必要があるからだ。
リポジトリを見れば、タグ付けされた設計書が作業対象だ。
設計書の履歴は、リポジトリのリビジョン履歴を見ればいい。

同様に、作業依頼がチケットとして発行されれば、チケットのログに全ての作業履歴が記録される。
作業中に課題が発生したり、設計者と実装手段を議論したり、間違った実装を障害として把握して直したり、色々あるだろう。
そういう履歴があるからこそ、作業依頼書の内容に記載された「作業」は、過去にいつでもさかのぼれる。

つまり、チケットは「作業内容のタイムマシン」だ。
「昔にさかのぼって、どんな作業が行われたのか、を追跡できる」点がチケット管理システムの最大のメリットだ。
これは「トレーサビリティ」という機能を提供している。

チケット管理システムが持つトレーサビリティは、本番稼動後の派生開発や障害修正で、大きな威力を発揮する。
本番稼動中の汚いソースコードには、過去の障害修正によるパッチの意図がある。
その変更の意図を無視して、ソースを勝手に弄ってはいけない。

また、プログラマは派遣契約で出入りが激しい。
3年前に書いたプログラマがいなくなれば、そのソースコードは、どんな意図で書かれたのか、その仕様はどういう経緯で決まったのか、誰も分からなくなる。
しかし、チケットにその作業履歴が残っていれば、その作業履歴に紐付くソースの変更履歴を辿ることで、パッチの意図を把握することができる。

ソフトウェア構成管理は、ソースコードのバージョン管理だけでは足りない。
作業の構成管理というべきチケット管理システムも必要だ。

IT化されていないISO9001のQMSで、作業依頼書と設計書という2種類のExcel帳票が運用上必要であるという事実は、ISO9001の背後にある構成管理には、成果物のバージョン管理と作業の履歴管理(トレーサビリティ)という2種類の構成管理が必要なのだ、という思想が背後にあるように思う。

【追記】以前、岡本さんから、「Gitポケットリファレンス新版」を頂きました。
構成管理の仕組みを理解する上で、Gitが分かれば、過去のバージョン管理ツールも分かるだろうし、チケット管理システムの必要性も見えてくるのではないか。
Gitポケットリファレンス新版」は、Gitを知る上でとても読みやすい本でお勧めです。

| | コメント (0)

2017/03/30

Redmineで日本語ファイル名の画像がPDF内で正常表示されるようになった

ver3.3.2のRedmineで日本語ファイル名の画像がPDF内で正常表示されるようになったのでメモ。
@naitohさん、ありがとうございました。

【参考】
Defect #22335: Images with non-ASCII file names are not shown in PDF - Redmine

akipiiさんのツイート: "Redmine3.3.2 で、PDF出力時に、日本語ファイル名の画像ファイルが埋め込まれない 。画像ファイル名がURLエンコードされた文字列がPDF出力される 。画像ファイル名が英数字ならば、PDFに画像が埋め込まれるのでOK。"

akipiiさんのツイート: "Redmine 利用の日本人にはありがたいです。RT @g_maeda: @naitoh @akahane92 Defect #24271 の件とともに修正ありがとうございます! PDF内で画像が正常に表示されることを確認しました。 喜ばれる方が多いのではないかと思います。"

akipiiさんのツイート: "ありがとうございます!@naitoh: @akahane92 @g_maeda Redmine 3.x で、日本語ファイル名の添付画像がpdf出力されない件、対応が遅くなり申し訳ありません。先程リリースした rbpdf 1.19.1にて修正しましたので、ご確認頂ければと思います。"

Kuniharu AKAHANEさんのツイート: "@naitoh @g_maeda 内藤さん、対応してくださったのですね。本当ありがとうございます。確認しますね。/ A good news for #Redmine CJK users! Thx a lot @naitoh san! https://t.co/HK2o7DnQwT"

Kuniharu AKAHANEさんのツイート: "@naitoh @g_maeda 当方の全環境にて、問題の解消を確認できました。とても助かります。ありがとうございました!/ Images with non-ASCII file names are not shown in PDF https://t.co/zITGox6odB"

Redmine 2.6のCHANGELOGのメモ: プログラマの思索

10年前のRedmineでは、PDF出力した時、日本語が文字化けする問題があったが、今はもう無い。
しかし、ついきさっきまで、Wikiに日本語ファイル名で画像ファイルをアップした後でPDF出力すると、PDF内に日本語ファイル名がURLエンコードされて表示されてしまい、画像が埋め込まれないバグがあった。

@naitohさんが、PDF出力Gemを更新してくれて解決した。
「bundle update」を実行すればOK。

(引用開始)
bundle update results:

Using rbpdf-font 1.19.1 (was 1.19.0)
Using rbpdf 1.19.1 (was 1.19.0)
(引用終了)

RedmineのPDF出力機能が活躍する場面は、Wikiに記載したマニュアルをPDFで出力したい時だろう。
たとえば、Redmineの運用マニュアル、業務システム開発PJの技術情報や用語集などは、Wikiに書いている場合が多い。

Wikiに書いておけば、メールにリンクさえ貼れば誰でも見れる。
Excelドキュメントに運用マニュアルや技術情報を書いても、すぐに内容が古くなるし、Excelファイルはすぐに散在してしまうから。

運用マニュアルや技術情報のように、版管理しなくてよいドキュメントは、Wikiにピッタリだ。
最新版のマニュアルさえ取得できればいいから。

Wikiに編集履歴が残るので、最新版さえ保守すればいいから。

マニュアル納品の時は、PDFで納品すればいい。
しかも、RedmineからWiki全てを一括PDF出力できるし、しおり機能も付いてくるので便利。

Redmine 1.4新機能紹介: Wikiの全ページを一括してPDFに出力 | Redmine.JP Blog

しかし、PDFではなく、Wikiの内容をOffice文書で出したい時もある。
Redmine本家には既に、ODT形式で出力するパッチがアップされている。

2016年5月のRedmine開発状況 | Redmine.JP Blog(WikiページをODT形式でエクスポート)

Feature #22923: Export Wiki to ODT - Redmine

WikiからOffice文書が出せるのはすごくいい。
ユーザマニュアルを納品した時に、ユーザが自分で加工できるから。
後はご自由に、みたいな感じで。

この機能も早くリリースできるようになればいいと思う。

【追記】
Windows上で、Ruby1.9、Ruby2.0では、rbpdf 1.19.1でエンコーディングエラーが発生する、として、JPLがチケットをRejectした。
それを受けて、まるやまさんが、Ver3.4で、Ruby1.9、Ruby2.0は廃止することを提案している。
実際、Ruby2.0以前は既に保守されていないからだ。
但し、RedmineがRuby2.0以前は対応しない、という意思決定がなされると、利用ユーザに大きな影響を与えるだろうと思う。

Defect #24271: htmlentities warning - Redmine

Feature #25538: Drop support Ruby 1.9.3 and 2.0 - Redmine

なお、その後、@naitohさんがRbpdfの修正バージョンをリリースしたので、Redmine本家に取り込まれた。

リビジョン 16520 - Use rbpdf 1.19.2 (#22335, #24271). - Redmine

JPLがこのように、細部までテストしてバグ出ししていること、それを受けて、レガシーなRubyを廃止することを検討していること、それらの動きをWeb上で全世界で参照できることにすごく敬服している。
Redmineの進化の方向性は、間違っていないように思う。

【追記】
RubyのPDFライブラリRbpdfに関して、@naitohさんの移植作業は下記で公開されている。

| | コメント (0)

2017/03/27

第16回Redmine大阪の感想 #RedmineOsaka

第16回Redmine大阪が盛況で終わりました。
講演者、参加者、スタッフの皆さん、ありがとうございました。
以下は感想をラフなメモ書き。
力尽きたので書きかけ。

【参考】
Redmine大阪 第16回勉強会 - connpass

【事前公開】【第16回Redmine大阪】RedmineのFAQとアンチパターン~親子チケットの功罪: プログラマの思索

【1】参加者は約70人近く。
関西以外に、東京、名古屋、福岡、岡山など遠方から参加された人も多かった。
LTの5人のうち4人は、関西以外のエリアの人達。
それだけRedmineが注目されているのだろうか。

(引用開始)
東京から参加しました。機械メーカーの調達マネージャーでITには詳しくないため、ついて行けない場面も多々ありましたが、雰囲気も良く時間が短く感じられました。
東京でも参加したいと思います。おせわになりました。
(引用終了)

発表内容も、組込みソフトウェア開発プロセスや運用面から3.4の新機能、アンチパターンまで幅広く、色々議論できたと思う。

【2】「高信頼性ソフトウェア開発へのチケット駆動開発の適用事例」 宿口雅弘さん

組込みソフトウェア開発プロセスの機能安全という特性にRedmineを導入した事例のお話。
実際は、Redmineベースのパッケージ製品eWeaverをベースに、開発プロセスを構築したみたい。
但し、コミュニティ講演なので、製品紹介よりも、機能安全をベースにしたプロセスのお話がメイン。

Redmineベースの組込みソフト開発向けプロセス支援ツールeWeaverのリンク: プログラマの思索

イーソルトリニティ株式会社 eWeaver

昨今、IOT、インダストリー4.0、自動運転、人工知能のように、メーカーを巡る動きは激しい。
その中で、ソフトウェア品質特性の中で特に、機能安全をどのように保証するか?
もちろん、そのプロセス実装は、Excel帳票や人手でやるのは、大規模開発になるほど非常に難しくなる。

機能安全をプロセスで保証するメリットは、PL法への対処にもなる、という指摘は参考になる。
製品出荷後のクレームによる損害は、今の時代は非常に大きくなっていて、リスクも大きい。
だから、プロセスで十分に保証されているけれど、その損害は予知できないものだ、と主張できれば、損害賠償責任を免れるわけだ。

お話はソフトウェア工学がメインテーマなので面白いけれど、Redmineウォッチャーの観点では、そのプロセスをRedmineの機能にどのようにマッピングして、どのように運用したのか、という点が非常に気になる。
肝心のお話はサラリと流されてしまったので、ちょっと肩透かしかも笑

質疑応答で聞いてみると、プロセスの保証は、チケット駆動のトレーサビリティという性質を使う。
つまり、機能要件やセキュリティ要件などの要件は親チケットとし、そこから派生したタスクは子チケットへブレイクダウンする。
成果物はSVNの配下に置き、必ずチケットにSVNリビジョンとして変更履歴が残る。
話を聞くと、Officeファイルも全てSVNで構成管理する、とのこと。
確かに、この運用なら、トレーサビリティは確保できるだろう。

チケット駆動の弱点は、時系列の表現が弱い点だ、という指摘は、そういう見方もあるのか、と参考になった。
だから、eWeaverでは、タスク管理のビューとして、かんばんを採用しているわけだ。

面白いと思った点は、Wordの要件定義書にある各要件の番号から、Redmineのチケットを新規登録したり、リンクを張れること。
つまり、Redmineチケットに散らばった要件やタスクは、Wordの要件定義書に基づいて作成されて更新される。
すなわち、要件定義書がしっかり保守されていれば、Redmineと相互連携もできるし、Redmineのチケット一覧をわざわざ見なくてもいい。

【3】「乱立してるRedmineを一つにまとめる話」 堂端 翔さん

東京Redmine勉強会の再演。
今後、さらに大きいRedmine移行作業を控えている、とのこと。

【4】 @pinzoloさん、@g_maedaさんの「Redmine 3.4.0にアップグレードしよう! お気に入り改善点一挙紹介」

@pinzoloさんの資料の「おまけ」の部分が面白い。
レスポンシブテーマに対応したことが、逆に、プラグイン作者やテーマ作者は大変になった。

Ver3から、10年以上前のチケットの実装など、古いチケットが対応されてきた。
@g_maedaさんによれば、積極的に、新しいパッチはどんどん最新のターゲットバージョンに設定しているから、とのこと。

パッチ数が順調に増えている。
つまり、Redmineを機能改善したいと貢献する開発者が増えている。

マイナーバージョンアップの期間が長くなる傾向にある。

Redmineの機能改善はとても保守的。
それが逆にすごく有効に作用している。
品質が安定している。

RedmineがRails4.2に対応してから、Redmineの機能拡張がやりやすくなったみたい。
RailsのVerUpに追随している。
Rails4.2に対応するRubyのバージョンに対応しているので、1.9にも対応している。

Rails5は、Ruby2.2.2以上しか対応しないので、VerUpしたら影響が大きくなる。

【5】LT

「Location-Based Task Management with Redmine」の発表が面白い。
Danielさんは地図関係の事業をしている。
担当者が現地に行って作業するが、その作業をRedmineで管理している。

その時に、国土地理院から取得した地図と、GPSで把握した担当者の位置状況をチケット画面や担当者画面に表示して、このチケットはどこで作業しているのか、担当者は今どこにいるのか、をRedmineから把握できるようにプラグイン化したらしい。

【6】パネルディスカッション「RedmineのFAQとアンチパターン」

親子チケットのアンチパターンについて、パネラーや参加者と意見交換。
時間がなくてあまり深掘りできなかった。

WBSの最下層はタスクにする。
だから、親子チケットの最下層のチケットは必ずタスクになる。

eWeaverでも、Redmineで運用する前に、ユーザにヒヤリングしてプロセスを確定してからRedmineの親子チケットの運用を決めている。

他の資料はこちら。

| | コメント (0)

2017/03/22

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

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

【例1】JAXA(宇宙航空研究開発機構)によるスパコン運用部門でのRedmine利用事例。
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さんが中心で行われた大規模組織の内部統制の利用事例。
何度も内容は聞いているけれど、個人的にいつも気になる点がいくつかある。

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

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

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

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

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

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

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

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

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

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

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

| | コメント (0)

2017/03/17

【事前公開】【第16回Redmine大阪】RedmineのFAQとアンチパターン~親子チケットの功罪

次回のRedmine大阪のパネルディスカッションの資料を事前に公開しておきます。
パネルのテーマ「RedmineのFAQとアンチパターン」に関する資料を書いていたら、ページ数が増えてしまったので、事前に公開しておく。

【参考】
Redmine大阪 第16回勉強会 - connpass

Redmineの親子チケットの功罪: プログラマの思索

最近よく聞くRedmineのFAQ~Excel添付のチケットから野良Redmineまで: プログラマの思索

親子チケットを使う上での用途や問題とかを洗い出してくれている。Redmineの現機能上の制約なども書いてあり、参考になる。 - prisira のコメント / はてなブックマーク

【1】Redmineが他のPJ管理ツールと違う点は、OSSでありながら、チケットやPJの階層が無限に作れること、があると思う。
その特徴があるがゆえに、多様な業務でもPJごとに切り替えたり、WBSの粒度に合わせて親子チケットで表現できる。
つまり、多様な業務、大規模な組織でも、Redmineの利用範囲が広がっている。

しかし、特に、親子チケットは落とし穴が多い。
そのアンチパターンや、よく聞かれるFAQを資料にまとめてみた。

【2】Blogでアイデアを書き散らした後で、もう一度見直した点は、「WBSはプロジェクト組織を規定する」という意見だ。
作業や業務内容を親子チケットで表現したものの、何故かしっくりこない原因には、「WBSはプロジェクト組織を規定する」という事実が背景にあるような気がする。

WBSはプロジェクト組織を規定する : タイム・コンサルタントの日誌から

WBSの作り方はプロジェクト型組織の構造を決めるという考え方はRedmineチケット管理にも通じる: プログラマの思索

実際、Redmineでプロジェクト管理を始めると、WBSはチケットでどのように書けばいいか、という質問がよく来る。
他にも、チケットの粒度やチケットの完了条件、ワークフローの質問もある。
つまり、WBSは工程単位に作るべきなのか、機能単位に作るべきなのか、という質問が根本的と思う。

彼らは、情報処理試験で習った教科書通りに、工程単位にタスク分割して階層化して、WBSをチケット化しようとする。
しかし、実際は、そんなきれいな開発はほとんどない。

経験上、工程単位のタスク分割でチケット駆動を始めると、たいてい上手くいかない。
溢れたタスク、割り込みタスク、仕様確認のQA、突然発生した障害など、WBSでは表現しきれない作業がどんどん現れるからだ。
それらのタスクは、どの工程に入れるべきなのか?
いつも判断に迷う。

たとえば、バージョン=工程に紐付けても、障害が出るたびにバージョンはReOpenされ、いつになってもCloseできない。
工程単位にPJを作るチームもあって、工程ごとにタスクを分割したい発想が根源にあるけれど、工程単位に作ったPJのチケットは統一的に管理しにくい。
その結果、チケットは乱発され、放置されて、Redmineはゴミ箱になる。

つまり、彼らは「WBSは工程単位に作るべき」という思い込みに囚われすぎていると思う。
もっと柔軟に考えて、実際の現場の運用に合わせて、もっと軽量なプロセスにすべきだと思う。

WBSはプロジェクト組織を規定する : タイム・コンサルタントの日誌からで指摘していることは、WBSの構造、つまりチケット化されたタスクの構造は、そのチームの組織構造を体現することだ。
機能別組織ならば、工程単位のWBSが向いているだろう。
つまり、縦割り組織だったり、開発工程をベンダーに一括請負契約で丸投げ発注している場合には、向いているかもしれない。
しかし、その後の受入テスト、部門間の調整事項などのタスクや課題が発生したら、その運用では耐えきれないだろう。

また、親チケットの開始日・期日・進捗率・予定工数は子チケットをロールアップさせるべきなのに、親チケットにせっかく入力した予定情報は消して欲しくない、という要望がすごく多い。
結局、親チケットと子チケットはバラバラに運用したい、という現場が多い。
つまり、彼らも綺麗なWF型開発を運用するのは難しい、と知っているのだ。

【3】上記の資料を書きながら思ったことは、あるべきチケット駆動開発をRedmineが完全に実現しきれていないことだ。
Redmineの機能制約があるために、チケット駆動開発のあるべき姿に制限がかけられて、未実現に終わっている。

例えば、ロードマップ画面で、スクラムのバックログのようにチケットの優先順位をドラッグ&ドロップするパッチが提供されているのに、まだ実現されていないゆえに、Redmineはアジャイル開発のツールとしてまだ不十分だ。
そのパッチの提供者のMarius BALTEANUさんは以下のように書いている。

Feature #22802: Add the posibility to set/change the position of an issue in a version - Redmine

(Google翻訳による引用開始)
ロードマップタブでは、トラッカータイプ(アルファベット順)と作成日付(古いもの)の後に、バージョンで自動的にソート(配置)されます。
あるバージョンの問題の位置を手動で設定したり変更したりすることは可能でしょう。
このようにして、ユーザーはバージョン内の作業の優先順位をつける方法が増えます。
ユースケース:私たちはバージョンをスプリント(時間ベース)として使用し、各バージョンについて、チームが次の期間に実装すべきいくつかの問題を計画します。
この機能を利用できるようにすることで、機能の実装順序も設定できるようになります(バージョンの上位にある問題が最も重要です)。
このメカニズムは、現代のソフトウェア開発(スクラム、かんばんなど)に非常に使用されており、チームで使用するのは簡単ではありませんが、古典的な計画(開始日、期日、後続/先行関係あり)定期的に問題を発行し、優先順位が頻繁に変更されます。
(引用開始)

彼の意見に僕は同意見で、ロードマップ画面はアジャイル開発のバックログ、かんばんのように使うべき画面へ改良すべきと思う。

他に、ロードマップ・カレンダー・文書・ファイル画面のように、Redmineで置き去りにされた機能は、もっと改善すべき余地がたくさんある。

しかし、逆に言えば、Redmineで色々試すうちに、チケット駆動開発のあるべき姿が見えてきた、という経緯もある。
こんなやり方もあるよね、とたくさんの人々が試して、初めて分かったアイデアもある。

つまり、RedmineはWebのプロジェクト管理ツールとして、先進的な人々が試す実験ツールなのだ。
だから、Redmineが機能改善されて、チケット駆動開発のあるべき機能が実現できれば、今まで思いもつかなかった運用方法や効果が出てくるだろう。
すなわち、Redmineにはたくさんの可能性が秘められている。

幸いなことに、Redmineはオープンソースなので、自由にカスタマイズできる。
Redmine本家でも活発に機能改善パッチが提供されて、どんどん改良されている。
今後のRedmineにすごく期待している。

| | コメント (1)

より以前の記事一覧