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

JAXAのRedmine利用事例に関する講演会が無事に終了。
多数の参加者の皆さんも満足できたと思います。
スタッフとしても、講演者と参加者の方に感謝です。
ラフなメモ書き。

【JAXA様の公開資料】
下記のWebページにリンクがあります。

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

【参考】
第65回 SEA関西プロセス分科会＆RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」 - RxTStudy～Redmineとタスクマネジメントに関する勉強会 | Doorkeeper

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

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

第65回 SEA関西プロセス分科会＆RxTStudy15 「チケット管理システムによるプロセス支援と今後の課題」 #RxTStudy - 日々の御伽噺

MAEDA, Goさんのツイート: "JAXAのRedmine利用事例の論文( https://t.co/xcay83LGeB )の英語訳が公開されています。 https://t.co/3pt5OnnPXe"

【1】JAXA様のRedmine利用事例の講演では、実際の画面の一部も見せてもらうことができて、JAXAの運用ルールが非常に理解できた。
JAXAの動機としては、マネージャの観点では、経営層に、投資対効果のメリットをアピールするために、Redmineでデータを収集して、定量データを報告したい、ということがあったらしい。

だから、カスタムフィールドを増やして、カスタムフィールドで集計しやすくする運用は必須だった。
しかし、ワークフローを複雑にしたくなかったので、トラッカーとロールを増やさないようにしたかった。
そこで、ロール設定のORルールやカスタムフィールドのANDルールを生み出した、と。

僕の疑問は、カスタムフィールドを増やしたがるのはマネージャの観点であり、入力項目が多いと億劫になりがち。
そのようなデメリットはないかと思ったが、JAXAの回答としては、過去のお手製BTSでは、入力項目がテキストボックスでデータの揺らぎがあり、集計しづらかった。
だから、Redmineのカスタムフィールドで入力項目の書式を定型化して、集計しやすくするルールは必須だった。

また、カスタムフィールドのANDルールによって、各プロジェクトごとにカスタムフィールドのON/OFFを制御しているので、ユーザにとっては必要なカスタムフィールドしか表示されていないので、あまり気にならないメリットもあると理解できた。

【2】パネルディスカッションでは、ISO9001やIT内部統制をRedmineで実現して、実際にコストを削減できるか、という点も質問してみた。
ISO9001を帳票ワークフローシステムと見なしてRedmineで運用してみるアイデア: プログラマの思索にも書いたけれど、日本のメーカーではISO9001の導入は必須の会社が多い。
しかし、ISO9001のプロセスが重荷になり、逆にコスト増になっているのではないか、という現状が多いのではないか。

JAXAの回答では、ISO9001をRedmineで運用するのはうまく回っている。
ISO9001は指針をしめしているだけであり、QMSの実装は現場ごとに実現して良い。
ISO9001やQMSの目的を十分に理解できていれば、その手段をRedmineで実現してもいいし、実際にそれで運用を上手く回す事ができる、と。
逆に、そんな質問は、ISO9001の目的と手段を取り違えて運用しているのではないか、という指摘を頂いた笑。

僕の感触としては、RedmineでISO9001で運用する場合の課題は、チケットの全文検索と、証憑などのエビデンスというOfficeファイルのファイル検索にあると思っている。
監査の時に、必要な情報をRedmineの全文検索からチケットを抽出できるか、その証憑となるExcelファイルを共有ファイルサーバーから取り出せるのか。

JAXAの方や@akahane92さんの話を聞くと、Redmineチケットに情報を集約し、チケットの関連付けや構成管理ツールのリポジトリ連携によって、トレーサビリティは実現できるし、検索もできる。
また、JAXAの運用では、DMSFプラグインを入れることで、ファイル検索と必要な情報の分類もできている、とのこと。
たしかに、DMSFプラグインでその課題はクリアしているわけだ。

【3】僕の発表資料「大規模組織や多様な業務におけるRedmineの課題」では、僕が理解しているJAXAの運用ルールの紹介と、組織構造がRedmineに与える影響事例としてPJ分割ルールについて話してみた。
JAXA運用ルールの噛み砕いた紹介は、参考になったという声があって、良かった。
また、機能別組織・事業部制組織・PJ型組織・マトリクス型組織という4つの組織構造に対し、Redmineが有効に使える部分の提示、そして、Redmineプロジェクトと組織構造の関連の説明も、一部の人にとっては、すごく参考になった、という声も聞いて、作った甲斐があった。

個人的には、組織構造がプロセスやツールに影響を大きく与えているのは確かだし、日本では、自社の組織構造や組織のルールに、プロセスやツールを従わせるようにしたい欲求が強い。
そういう状況において、Redmineの機能の柔軟さ、豊富さがメリットになっている部分を感じている。

【4】他の資料はコチラ。

第15回RxTstudy『大規模組織や多様な業務におけるRedmineの課題』 from akipii Oga

RxTstudy第15回オープニング・パネルディスカッション from akipii Oga

チケットの利用による経験を活かした開発の可能性 from Makoto SAKAI

Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例

Redmineのようなチケット管理ツールがとても威力があっても、上司や経営者が見なければExcelがはびこってしまう事例を見かけたのでメモ。
チケット管理ツールに限らず、営業支援システム、日報システム、経営状況の見える化の為の情報系システムでも同様の症状がよく発生する。

【参考】
golangでRedmineの情報をExcelにするコマンドラインクライアントを作った - write ahead log

Big Sky :: コマンドラインからredmineを扱える「godmine」作った。

【1】(引用開始)
SIerに所属している方ならわかると思いますが(あんまりわかって欲しくもないですが),体質の古い会社だとRedmineを使っていても「Excel表がない」と文句を言われたりします.

面倒なのが「プロジェクト一覧表がない」とか「課題管理表がない」とか「バグ一覧表がない」とか....etcです.

実装担当者はRedmineを使う運用で問題なかったりするのですが,役職持ちの方から「Redmineはわからないから」とか「移動中にExcelで見たいから」などと言われると断れないのがサラリーマンの辛いところです.

あとは受託だとユーザとか元請にRedmineを強要できないので結局Excelになったりします.(しません?)
(引用終了)

【2】Redmineのようなチケット管理ツールを、開発チームがボトムアップで使っているのではなく、上司や経営者が上から目線で導入させたとしよう。
すると、Redmineは確かに現場に導入されるが、現場ではRedmineが必要で導入したわけではないから、なかなか根付かない。

一方、Redmineが普及して、会社の上司や経営者もPJ状況を見て欲しい、と思ったとしよう。
しかし、部課長や社長クラスの人は、管理作業や営業などで忙しすぎるので、Redmineをわざわざ触って、見る暇もない。
むしろ、メールで報告させたり、Excelを送ってもらって、印刷したプリントで見た方が楽だったりする。

すると、上司や経営者から、Redmineを見るのは面倒なので、メールで報告してくれ、とか、ExcelでPJ状況を出してくれ、と言われたりする。
そのための進捗報告書を作成するのに、プロジェクトリーダーは無駄な工数がかかったりする。
せっかくのRedmineが、上司や経営者の目には届かないのだ。

【3】その状況は、営業支援システムの事例でも聞いたことがある。

営業マンが顧客にアポを取ったり、契約状況を記録するために、営業支援システムを作り、営業担当者に日報を書かせて、上長がその日報を読んで管理できるような素敵なシステムを開発した。

しかし、営業部の課長クラスは、自身も営業しているし、打合せも多いので、営業支援システムにわざわざログインして、大人数の営業担当者の日報を毎日読む暇もない。
すると、営業担当者にとっては、日報入力という無駄な作業が増えているのに、その日報を上司が少しも読まないし、反応もない、と分かると、誰も営業支援システムを使わなくなった、と。

結局、メールやExcelベースの情報連携に戻ってしまった、という事例。

他にも、ERPに蓄積された財務情報やPJ情報を経営者向けに見える化したい、という情報系システムを多額の資金を投資しして開発したものの、経営者はそんなにシステムに明るくないし、システムの操作も最初から覚えるのは面倒なので、結局使われない。
すると、大金をはたいた、経営情報の見える化システムも使われなくなってしまう、という話もよく聞く。

【4】結局、会社の上司や経営者が、情報系システムを使いこなさなければ、現場に定着しない、という身も蓋もない話。
経営者向けの情報系システムは、大金をはたいた割りには、使用頻度が低く、誰も使わないシステムになりやすい。

いくらBIツールでビジュアルに見える化したとしても、彼らはそもそも情報系システムを使いこなそうという動機はさらさらないのだ。
個人的には、古い頭の日本の大企業に多い症状のような気がする。

そんなことをふりかえると、「見える化」という言葉は経営者は大好きだが、実際に使いこなせていない場合がすごく多い。
むしろ、現場主導で、自分たちの現場がやりやすいように、使いこなした方が賢明だ。
無駄なメトリクスの抽出、見える化プログラムの実装は、不要だと思う。

【追記】
言いたかったのは下記のコメントの通りかな。

はてなブックマーク - 岡崎良徳 のブックマーク - 2016年7月23日
(引用開始)
見ないものを見える化するのは無駄だよね、というお話。
(引用終了)

【追記２】
アカベコマイリさんが詳しい運用ルールを説明されている。参考になる。

Redmine 運用について 1/3 – はじめに – アカベコマイリ

有効な併買ルールを見つけ出すバスケット分析のアルゴリズムのリンク

有効な併買ルールを見つけ出すバスケット分析についての記事をメモ。
以下、特に主張なし。

【参考】
アップセルとクロスセルで顧客収益性を上げたい！｜活用ケース解説｜マーケターのためのデータ分析実践入門 Marketing Analyticsゼミナール

バスケット分析とは：何と何が、一緒に買われているのか？を知ろう｜データ分析用語を解説 - データビジュアライズで経営を視える化する/graffe グラーフ

リフト値とは：その事象が、どれだけ「持ち上がっているか」を考える指標｜データ分析用語を解説 - データビジュアライズで経営を視える化する/graffe グラーフ

Teradata｜マーケターのためのデータマイニング・ヒッチハイクガイド：第15回：アソシエーション分析（前編）

第1回　機械学習を実践する前の基礎知識：Mahoutで体感する機械学習の実践｜gihyo.jp … 技術評論社

第2回　「ある商品といっしょによく売れる商品は何か？」を見つけるには　～マーケット・バスケット分析の考え方：Mahoutで体感する機械学習の実践｜gihyo.jp … 技術評論社

【1】スーパーやコンビニのPOS分析で溜まったデータの分析のうち、バスケット分析が一番有名ではないか。
意外な商品を近くに配置すると、売れ行きが増大する。
有名な例は、アメリカの都市伝説にもなっている、紙おむつとビールの事例だろう。

「リテールデータ分析入門」によれば、日本では、ある食品会社が、レトルトカレーと卵がセットで売上が高いので、卵売り場でレトルトカレーを配置してPOP広告で購入を促したら、実際に売れ行きが増大したらしい。
仮説としては、低学年の子供を持つユーザ層が、レトルトカレーと卵を購入しているのではないか、と推測されたらしい。

コンビニを見れば、毎日のように、商品の置き場が変わっているのがよく分かる。
中小企業のスーパーでも、併買分析をすれば、もっと売上が増えるのではないか？
実際、ある診断士の話を聞くと、とある中小企業の小売店では、スパゲッティの麺とパスタソースをセットに配置していなかったので、セットで配置するように指導したら、売上が増えた、という話を聞いたことがある。

プログラムを書くことができるならば、バスケット分析を実際に試してみると、身近の人達にその威力を見せつけられるかもしれない。

【2】バスケット分析のアルゴリズムは、サポート、信頼度、リフトの3つで測定するのが知られている。

支持度（support）＝「XかつY」を含むトランザクション数/全トランザクション数

信頼度（confidence）＝「XかつY」を含むトランザクション数/Xを含むトランザクション数

リフト＝信頼度(X⇒Y)/支持度(Y)

(引用開始)
この式から「リフト値」は、「xが買われたときにyも買われる確率」を「全体でyが買われる確率」で割ったものである、と考えることができます。

つまり、「リフト値が高い」ということは条件Xのときに事象Yが起こりやすいということを示しています。このように一般化すると「リフト値」の考え方は「バスケット分析」以外でも活用できます。
(引用終了)

つまり、リフト値は、ある条件における条件付き確率であることを意味している。

(引用開始)
信頼度は，「条件（パンを買う）が起きた場合に，結論（ミルクを買う）が起きる割合」を表します。これにより，条件（パンを買う）と結論（ミルクを買う）のアソシエーションの強さを表します。

支持度は，条件（パンを買う）と結論（ミルクを買う）が同時に起こる場合が全トランザクションに占める割合を表します。

支持度が低い組み合わせは，あまり買う人がいない組み合わせであることを示します。そのため，たとえ信頼度が高くても，支持度が低い組み合わせは，アソシーエション分析では有用な答えではないと考えます。

次に，結論（ミルクを買う）が条件（パンを買う）と無関係に起こっていないかどうかを計算します。先ほどのコンビニエンスストアにおけるジュースのように，よく売れる商品はどの商品から見てもよくいっしょに売れる商品になってしまう可能性があるためです。

そういった現象が起こる度合いの低さを表すのが「リフト値」です。

有効なアソシエーションルールであるためには，一般的にリフト値が1より大きい必要があります。

このように，アソシエーション分析では，信頼度，支持度，リフト値の3つの値を求めます。そしてこれら3つの値でアソシエーションルールの強さと有効性を判断します。
(引用終了)

【3】実際の計算方法は、いくつかあるらしい。
一つは、「リテールデータ分析入門」に記載されていた、R言語を使う方法。
もう一つは、第2回　「ある商品といっしょによく売れる商品は何か？」を見つけるには　～マーケット・バスケット分析の考え方：Mahoutで体感する機械学習の実践｜gihyo.jp … 技術評論社のように、Mahout＋Hadoopを使う方法。

この辺りの技術は、今は戦国時代みたいで、色々あって面白い。
他にもまとめてみる。

Redmineコミュニティに関わる動きのメモ

本日、東京でRedmine生誕10周年記念パーティが開催されたらしい。
僕は参加できなかったが、謎のフランス人コミッタJPLのショートビデオメッセージもあったらしく、JPLはイケメン、という声も上がったらしい笑。
最近のRedmineコミュニティに関するリンクと考えていることをラフなメモ。

【参考】
「Redmine 10周年を祝う会」 松江・大阪・東京で企画 | Redmine.JP Blog

Redmine生誕10周年記念パーティ - redmine.tokyo

akipiiさんのツイート: "日本人が貢献できて良かった。RT @netazone: Redmine作者のJPLからのメッセージ。Toshi と Go に感謝といっている #redmineT https://t.co/meoUBSkZn0"

akipiiさんのツイート: "Redmine コミッタJPLはイケメンではないか、と女性スタッフの意見もあり笑。RT @glad2121: Redmine 10周年を祝う会＠東京。 (@ ANTHEM) https://t.co/gvQug6kyoG https://t.co/55l9NkRiQv"

akipiiさんのツイート: "@netazone JPLもRedmine の次の大きな課題はRails5対応と考えているのか。確かにテストコードの整備も、考えれば大変だろうが、今までの歴史を振り返れば必ず達成できるだろう。"

redmine.tokyoさんのツイート: "#Redmine 生誕10周年記念パーティを昨日実施いたしました。Redmine作者のJPLからのビデオメッセージをいただくことができ、参加者の皆さまには楽しんでいただけたと思います。... https://t.co/bjKA4EKKsZ"

Redmine 10周年記念 10年ふりかえり from Go Maeda

【1】Redmine作者JPLからのメッセージの本文を読むと、彼がRedmineに誇りを持っていること、Rubyを学習するためにRedmineを書き始めて10年経つが、今もWonderfulな経験をしているよ、とのこと。

また、特にRubyを生んだ日本と、日本のRedmineコミュニティからのフィードバック、前田剛さんとまるやまさんへの感謝が述べられていた。

次への課題は、まず、Rails5への対応。
そのために、2千もの更新すべきテストケースがあること。
また、RailsのTurbolinksやActionCableを当てはめることで、RedmineのUI/UXをもっと今風に改善したい、とのこと。
Ver3.2でレスポンシブデザインの機能改善が期待されなかったら、RedmineのUIはずっとそのままだっただろう、とのこと。
そこで、JPL自身もRedmineをより良くするための幾つかのアイデアを持っていて、コミュニティとシェアしていきたい、とのこと。

JPLのメッセージ、そして、RedmineがRubyやRailsのVerUPに追随しながら10年も開発が続けられてきたこと、さらに、自動テストやテストカバレッジの充実による安定した品質を考えると、本当に偉業だと思う。

【2】世界でも、最近の日本でも、Redmineを巡る状況が少しずつ変わってきているように思う。
興味を惹くのは、ベンダーの動きだ。

Redmineを作っている人々 (3.3.0編) - ファーエンドテクノロジー株式会社によれば、Ver3.3でリリースされた機能である「＋ボタン」「セキュリティ通知」はドイツの会社の開発者が提供したパッチが元になっているらしい。

(引用開始)
存在感があるのがドイツのPlanioです。
Redmineをベースにしたサービスを提供している会社です。
以下の表の通り、6人が21件のパッチを書きました。
カスタマイズしたRedmineを自社サービスとして提供しながらその一部をオープンソースコミュニティにフィードバックするというすばらしい活動をされています。
3.3.0の新機能では ＋ボタン や セキュリティ通知 もPlanioによるものです。
(引用終了)

Planioというドイツの会社の開発者は、Redmineにレスポンシブデザインのパッチを送ったことでも知られている。
つまり、直近のRedmineのUIや機能改善に重要な貢献を果たしている。

Feature #19097: Responsive layout for mobile devices - Redmine

自社のサービスのRedmineで改造した機能をオープンソースに提供し、それによって、Redmineの全てのユーザに恩恵が受けられた。
自社のRedmineサービスで実績があるのだから、ある程度品質も枯れているだろうし、Redmine本家もパッチ取込にさほどリスクも少なかっただろうと推測する。

【2－1】また、日本でも先日、日本人コミッタをRedmineベンダーが支援するというニュースが流れていた。
Redmineの開発者はボランティアベースで実質3人でしか開発されていない状況を考えると、コミッタへの支援は重要な出来事だと思う。

ホロンテクノロジーとアジャイルウェアのプレスリリースに当社代表取締役 前田のコメント掲載 - ファーエンドテクノロジー株式会社

PRESS RELEASE - アジャイルウェア５期目、Toshi MARUYAMA氏をフェローに迎える

【3】上記の状況が意味していることは、Redmineのユーザ数が増えてきていて、Redmineというマーケットが成長しているという事実だろう。
下記の記事では、日本でMyRedmineを使っているユーザが一部のイノベータやアーリーアダプターのような先端物好きのユーザだけでなく、一般のユーザ層にも使われている事実が示されている。

My Redmine業種別導入実績を公開します - ファーエンドテクノロジー株式会社

最近思うのは、Redmineがソフトウェア開発のタスク管理、つまりチケット駆動開発としての使い方よりも、昔のNotesの代わりのようなBPRツールとして使われる事例が多いように感じることだ。
僕は元々、チケット駆動開発をRedmineで実現することによって、アジャイル開発やソフトウェア工学の可能性を見出し、色んな実験ができることに興味を持っていた。

実際、Redmineを使えば、プロセスのデータは簡単に収集できるので、プロジェクト管理やソフトウェア工学で見出された過去の経験則を検証し、その正しさや限界を調べることが容易にできる。

しかし、Redmineを一般ユーザが使う状況が増えることによって、汎用的な帳票ワークフローシステムとして使われるようになってきていると思う。

実際、見積書や稟議書のような事務処理、インシデント管理やサポートデスクなどでもRedmineが使える。
オープンソースでありながら、Redmineほど、ワークフローや権限制御を細かく設定できるツールは珍しいし、使いこなせれば、かなり強力だ。

すると、一昔前にNotesで、BPRと称して社内の業務を紙の帳票からクラサバに置き換えていった動きと、今のRedmineの普及が重なるように見える。

普通の若い人にとって、ブラウザ上でチケットをやり取りする操作はそんなに難しくないし、慣れれば、使いやすいと思う。
また、Redmineでなくても、チケット管理ツールは、JiraやTrello、PivotalTracker、Backlogなどたくさんあるし、一度チケット管理に慣れれば、どのツールでも同じように使える。

つまり、チケット管理ツールをBPRとして運用するやり方は、自然な流れではないかと思う。
そんな特徴も、Redmineが日本人好みのツールである理由の一つではないかと思う。

Redmineが日本人好みのツールであるという仮説: プログラマの思索

【4】個人的には、Redmineのコミッタとユーザコミュニティが、Redmineの機能や使い方について、色んな可能性や事例や要望を議論しながら、より良いものを作っていく基盤が出来ればと思う。
つまり、Redmineのエコシステムを他の成功したオープンソースと同じように実現したいのだ。

たとえば、LinuxやRubyは、当初は開発者のおもちゃに過ぎず、エンタープライズでは使えないと言われていたが、今は十分に普及し、どこでも使われている。
そして、一部の熱いユーザだけでなく、一般ユーザもユーザコミュニティを形成し、LinuxやRubyを支援するベンダーも多数参入し、コミッタも生活の糧の支援を得て、より良い方向へ進化する基盤が整っている。

Redmineもいつかはそんな形になればいいなと思っている。

それから、いつか、JPLを日本に呼びたい。
その意見は、2011年に東京Redmineコミュニティが立ち上がった時のキックオフミーティングでも机上に上がった。
日本のユーザコミュニティの熱い気持ちを彼に伝えてみたい。

ツールの使い方に関するノウハウをデザインパターンにまとめる事例

DataSpiderというパッケージ製品の記事を見ていたら、ツールの使い方に関するノウハウをデザインパターンにまとめる事例があったのでメモ。

【参考】DataSpiderデザインパターンβ 序章 「DataSpider デザインパターンβとは」コメントを投稿する DataSpiderデザインパターンβ｜DataSpider Technical Network

RedmineのチケットをExcel形式でレポートしてみたコメントを投稿する ｜DataSpider Technical Network

あるソフトウェア製品を使いこなしていくと、それに関するノウハウが色々溜まってくる。そのノウハウは、ある利用シーンに対する効果的な使い方もあるし、製品の制約によって、こういう使い方しかできない、という場合もある。そんな時に、製品のノウハウをパターンカタログで表現する、という方法は面白い。

実際、下記のような記事で紹介されている。

(引用開始)ソフトウェア開発・設計・運用の現場でよく話題となる「デザインパターン」と呼ばれるものがあります。デザインパターンとは、過去に発生してきた多種多様な課題、およびそれに対する解決方法を分類して抽象化し、他の現場でも再利用できる形で一覧化したものです。デザインパターンを知ることにより、システム開発の担当者は、より効率的に課題に対する解決策を発見することができます。

「DataSpiderデザインパターンβ」は、このような「デザインパターン」をDataSpiderにおいても作成し、今後のDataSpiderを使用した開発・システム設計・運用に役立つものを作ろうとする試みです。

これにより、DataSpiderを用いたデータ連携システム開発の効率化に役立てていただくと共に、DataSpider技術者同士のコミュニケーションの円滑化、また既に稼働しているシステムのより良い改善等に役立つものになれば、と考えています。

DataSpiderのベンダーであるアプレッソは、2001年6月にDataSpider 1.0をリリースしてから十数年の間、DataSpider自体の開発はもちろん、多くのDataSpiderの開発・利用シーンを提案・支援してきた実績があります。そこでまずは、これまでの経験を下敷きに、叩き台として「DataSpider デザインパターン　β」を提示しようと思います。(引用終了)

(引用開始)DataSpiderを使ったデータ連携システムの開発の中でも、さまざまなフェーズで何がベストプラクティスなのか悩むことがあると思います。例えば、Mapperの効率的な使用方法といったスクリプト開発の時点や、既存システムとDataSpiderをどう連繋させるかといったアーキテクチャのレイヤー、またテスト環境から本番環境への移行をどのように行うかという運用のフェーズなど、さまざまな場面においてデザインパターンを考えることができます。(引用終了)

(引用開始)また、１つ１つのパターンの中では、以下の項目でパターンを提示していく予定です。

1 課題パターンによって解決しようとしている課題を表します。

2 解決方法解決の方法を示します。

3 説明具体的な使用方法を説明します。

4 メリットこのパターンを使うことによって享受できるメリットを説明します。

5 注意点パターンを使用するにあたってデメリットや注意することがある場合、ここに示します。

6 関連事項他のパターンと密接な関係を持っている場合や、参考ドキュメントがある場合など、関連する事項をここに記述します。(引用終了)

パターンで表現する最大のメリットは、分かりやすいことだ。

どんなシーンで、パターンが有効なのか？パターンを使うと、どんな効果が出て、その効果が得られる範囲はどこまでなのか？そういうことが一目で分かる点は良い。

逆にデメリットは、パターンカタログで全てを網羅できているか不安であること、重複したり粒度にばらつきが出たりする場合があることだろう。そして、パターンを作っていく時に迷ってしまうのは、パターンを一つのストーリーにまとめることができるかどうか、にかかっている点だろうと思う。

パターン地図、ナビゲーションマップみたいに、パターンの関係を一つのストーリーや地図にまとめて、体系づけて理解したい。そうすれば、パターンをより一層深く理解できるはず。

たとえば、上記の記事では、製品の使い方や設計のパターンを「スクリプト開発パターン」「連携システム設計パターン」「運用パターン」にまとめている。おそらく、スクリプトで開発した→システム連携のモデルに当てはめる→実際に運用してみる、みたいな流れになるのかな、と想像する。

そういう事例を見ると、Redmineでも同様のパターンカタログを作ってみたくなってくる。以前、@akahane92さんが、ITSガイドラインを作ってみたいね、とツイートされていたが、その心は、Redmineの利用に関するパターンカタログを作ってみたいことに行き着くと思う。

この辺りの発想もまとめてみたいと思う。

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

Redmineベースの組込みソフト開発向けプロセス支援ツールeWeaverを見つけたのでメモ。
最近、Redmineをベースにしたパッケージ製品が増えているような気がする。

【参考1】
イーソルトリニティ株式会社 開発プロセス支援ツールeWeaver

Shukuguchiさんのツイート: "eWeaverは OSSの Redmineをベースにしたツールで、ソフトウェア開発プロセスの運用管理にチケット（駆動開発）を用い、また、チケットをトレーサビリティ管理に応用しています。プロセスが重くなりがちな機能安全開発を少しでも手軽にできるような工夫がなされたツールです。"

【参考2】
Redmine Lychee Enterpriseシリーズの解剖part1～Redmineの本来あるべきガントチャート機能 Lychee Gantt Chart: プログラマの思索

Redmine Lychee Enterpriseシリーズの解剖part2～RedmineでEVMを実現 Lychee EVM: プログラマの思索

Redmine Lychee Enterpriseシリーズの解剖part3～Redmineのチケット関連図 Lychee Association ChartとRedmineの予実管理をサポートする Lychee Actual Date: プログラマの思索

Redmineの要員管理のプラグインLychee Resource Managementの感想: プログラマの思索

Redmineのもう一つのガントチャートプラグインEasyGanttのリンク: プログラマの思索

Redmine for ITILが解決するもの: プログラマの思索

もう一つのRedmine製パッケージ製品ANKO REDMINE: プログラマの思索

【1】】eWeaverが面白いのは、要求管理からのトレーサビリティの強化、Backlogsプラグインを組み込んだアジャイル開発のサポートが混合して実装されていることだ。

組込みシステム開発向けプロセス支援ツールであるからには、要求から設計、ソース、リリースモジュールに至るまでのトレーサビリティが重要であることは分かる。
なぜなら、出荷した製品に障害があり、それが原因で人損事故が発生したら、どこに原因があるか解明しなければならない。
組込製品なので、フェールセーフの概念も品質に入れているということが重要だから。
その点は「機能安全」という概念があるらしい。

機能安全 - Wikipedia

「eWeaverは、ソフトウェア開発手法やプロセスの正しさの証明を必要とする機能安全適合にも有用です。」とうたわれている。

【2】そのために、ドキュメントやソースはSVNのような構成管理ツールで履歴管理し、設計レビューやコードレビューはチケットに記録して、要求チケットと関連付けて、トレーサビリティを実現するわけだ。
紹介画面を見ると、トラッカーには「RequirementItem」「ArchiDesignItem」などがあり、要求管理は親子チケットで階層化されるように実現するようだ。
おそらく、要求や仕様は親子チケットで表現し、レビューや障害は子チケットまたは関連チケットで表現し、ドキュメントやソースはSVNリビジョンでリンクさせているのだろうと推測する。

(引用開始)
要求管理から出荷後のサポートまで開発プロセス全体を一元管理

各種ドキュメントとソースコードはSubversionで管理し、プロジェクトの問題点やレビューやテストなどの活動は「チケット」としてRedmineで管理します。チケットを分類してワークフローを定義するRedmineの「トラッカー」には、要求管理から出荷後のサポートまでをカバーする各開発プロセスが標準で設定されています。
(引用終了)

つまり、要求管理の仕組みをチケットの階層や関連で対応付けることで、実現しようとしている。
メリットは、要求の変更はチケットの属性の変更に置き換えられるので、変更に強いことだ。

そのおかげで、要求の変更によるインパクト分析、つまり、要求が変わることでどれだけの要求や仕様や成果物に影響が起きるのか、を自動集計できる。
作業の見積りや、設計レビューで役立つだろうと推測する。

実際、インパクト分析を可能にする独自機能を実装しているらしい。
要求の変更箇所は親子チケットで経路検索できるが、影響する成果物の範囲特定までできるのは面白い。

(引用開始)
トレーサビリティアイテムの自動抽出、リンケージ生成、インパクト分析を可能にする独自機能を実装

各種ドキュメントやソースコードに埋め込まれたトレーサビリティアイテムを抽出（オーサリング）し、そのアイテム間のリンケージ生成と管理する機能を提供します。これにより、開発途中に変更要求が発生した時は、チケットや成果物への影響範囲を自動的に抽出し、全体へのインパクト分析が可能です。これらの機能は、Redmineの独自プラグインと、それと連携するマイクロソフト社の「Microsoft Word」や「Microsoft Excel」向けアドオンとして実装されています。
(引用終了)

【3】もう一つ面白いのは、Backlogsプラグインも組み込んで、タスクかんばんの機能も付けている点だ。
プロダクトバックログの画面でストーリーカード(要求チケット)を管理し、スプリントバックログでタスクカード(作業チケット)を分けて管理できる。
Backlogsプラグインのプロダクトバックログやタスクかんばんでは、チケットをドラッグ・アンド・ドロップできるので、とても使いやすいのはメリットだ。

トレーサビリティを強化したというWF型開発ぽい機能と、プロダクトバックログやタスクかんばんを組み込んだというアジャイル開発っぽい機能が混在している点が何か面白い。
実は、組込製品開発の人達の方が、業務系システム開発の人達よりもアジャイル開発に違和感がないのかな？

但し、BacklogsプラグインはRedmine2.xしか対応していなかったが、このパッケージ製品はRedmine3.xにBacklogsプラグインを対応させているのだろうか？
気になる所。

【4】Redmineの有償プラグインやソリューション提供型パッケージ製品の情報は以前から収集していた。
いろんな特徴があることは、多様な利用シーンを持つユーザにとって、選択肢が増えることなので良いことだと思う。
今後のRedmineのエコシステムにも着目していく。