逆コンウェイ戦略のメモ～望ましいアーキテクチャを促進するためにチームと組織構造を進化させる

平鍋さんの記事で「逆コンウェイ戦略」という概念を初めて知ったのでメモ。
まだ消化不良なので、ラフなメモ書き。

【参考】
逆コーンウェイ戦略とDevOps, Microservices, Agile | an Agile Way

ThoughtWorks Technology Radar 2014年7月版

Inverse Conway Maneuver | Technology Radar | ThoughtWorks

James Lewis/Martin Fowlerの"Microservices"日本語訳 - 自由課題

分散スクラム

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

Redmineのプロジェクト間チケットコピー機能で縦割り組織のサイロ化を打破する記事のリンク: プログラマの思索

第10回redmine.tokyoの感想～Redmineユーザはメトリクスがお好き #redmineT: プログラマの思索

Redmineチケット一覧のフィルタ「対象バージョン」のリストが大量表示されて使いにくい問題点: プログラマの思索

【1】(引用開始)
(8) Inverse Conway Maneuver (Trial) (逆コンウェイ戦略)
「望ましいアーキテクチャを促進するためにチームと組織構造を進化させること」、理想的にはテクノロジとビジネスのアーキテクチャが同じ形になることを提案する。
(引用終了)

(引用開始)
拙訳：
逆コーンウェイ戦略は、自分たちの望ましいアーキテクチャ設計を促進するように、チームと組織側を機動的に進化させることを推奨する。理想的には「技術的アーキテクチャ」が「ビジネスアーキテクチャ」の同形写像になるように。

現代流に言えば、
DevOps をやるなら、Dev と Ops を同じ組織にせよ。
Agile やるならワンチームで。
複数の Agile チーム構成にするとき、でビジネスに分かりやすい機能（フィーチャ）を重視するなら、コンポーネントチーム（ソフトウェアの部品に着目したチーム構成）でなく、フィーチャーチーム（機能縦割りのチーム構成）で。
Microservices アーキテクチャを採用するなら、小さなAgileチームをたくさん。
ということになると思います。

要するに、「人間や組織間のコミュニケーション（情報流）」というものがソフトウェア開発には決定的なインパクトを与える、ということをまず認め、それを積極的に活用するように、ということです。
「ソフトウェアは会話でできてる」(Software is made of conversations) という、このブログのテーマそのものだったので、ちょっと嬉しかったのです。
(引用終了)

【2】最近、Redmineの運用が大規模になっていくと、会社の既存の組織の枠組みが組織慣性となってしまい、軽量プロセスとして思うように運用できない場面に遭遇する時がある。
5人だけの1チームでチケット駆動でやっていても、ユーザ100人で50個以上のプロジェクトが運用されていれば、メンバー同士やチーム間だけでなく、会社としての開発業務がどのように運用されるべきか、という問題まで発展する。

そもそも、Redmineでは、Redmineプロジェクト＝ソース管理の1リポジトリ＝1システムという設計思想で作られている。
僕は、その思想を受け継いで、Redmineプロジェクトを階層化していけば何とかなると思っていた。

しかし、ソフトウェア開発のタスク管理以外に、ソフトウェア保守やサポートデスク、事務処理ワークフローまでRedmine運用を拡大すると、どうしてもRedmineの機能に不満が出てくる時もある。
そもそも会社としてどのような運用ルールが必要なのか分かっていないことが根本問題になってくる。
たぶん、RedmineやJira、Tracなどのチケット管理ツールだけの問題ではなくなってくるのだ。

つまり、組織構造に見合った運用フローをRedmineに適合させようとして、上手く適合できていない症状が現れていると思う。
その根本原因は、大規模運用に見合ったRedmineの機能不足もあるだろうが、むしろ、組織構造に見合った運用フローが組織内で明確化されてメンバー全員に共有されていない事の方にあると思う。

【3】Conwayの法則は「4チームでコンパイラを作れば4パスコンパイラとして無駄に複雑に作ってしまう」という経験則。
この経験則は、身近なソフトウェア開発組織でもよく見られる。
「鈍重な組織構造は鈍重で複雑なソフトウェアシステムを作る」とも言い換えられる。

(引用開始)
チーム メンバーが物理的に近接していない場所で作業している場合は、チーム内のコミュニケーションは確実により複雑になり、チームが作成するソフトウェアにも同じことが当てはまります。
1968 年に、Melvin Conway (メルビン コンウェイ) 氏は次のように説明しました。
システムを設計する組織には、その組織のコミュニケーション構造を反映した設計を作り出すという制約が課されます。

Conway の法則は、ただの格言ではなく、より実証的な説明です。
ソフトウェア開発チーム内では、測定可能な動的要因になる可能性もあります。
ある研究では、チーム分散という事実がシステム アーキテクチャに及ぼす影響を測定して、Conway の法則が実際に影響力を持つことが実証されました。
チーム メンバーが分散している場合は、ソフトウェア開発者が互いを分離しようとして、コード内でより多くの抽象化レイヤーを作成する傾向に陥りがちです。
(引用終了)

一方、逆コンウェイ戦略は、この経験則を逆手に取って、アーキテクチャに見合った組織構造になるように戦略的に組織構造を作り直すべきだ、と考えられる。
アジャイル開発をやりたい、マイクロサービスで開発したい、と思うならば、そのアーキテクチャに適合する組織になるように、戦略的に意図してチーム構成を考えるべきだ、とも言い換えられる。
面白い発想だと思う。

【4】この発想をRedmineによるチケット駆動開発に適用すると、どのような思想になるだろうか？

Redmineのプロジェクト、バージョン、チケット、トラッカー、ロール、カテゴリは、逆コンウェイの法則に即した組織構造とどのようにマッピングされるのか？

チケット駆動開発に逆コンウェイの法則を適用した場合、アジリティを活かした組織構造はどのようにあるべきか？

数多くの機動的なチーム(例：スクラムチーム)で運用する場合、数多くのチームがバラバラにならないように見通しが良くなるように統制する方法をRedmineの機能で提供できるのか？

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

WBSの作り方は組織構造に依存するという記事がとても参考になったのでメモ。

【参考】
ＷＢＳはプロジェクト組織を規定する : タイム・コンサルタントの日誌から

ＷＢＳはコスト見積の基準を規定する : タイム・コンサルタントの日誌から

【1】ガントチャート初心者からよく聞かれる質問は、「WBSは工程単位に作った方がいいですか？それとも機能単位に作った方がいいですか？」だ。

話を聞くと、工程単位にチケットを作ってみると、実際の開発フローに合っていない感触があり、途中で、機能単位にチケットを作り直す時が多いらしい。
WBSの作成方法は、工程単位と機能単位のどちらが正しいのだろうか？

(引用開始)
さて、３つの機能モジュール×３段階の作業プロセスだから、合計９個のアクティビティからなるプロジェクトである。
これをＷＢＳに構成するとき、二種類の表現が考えられる（ＩＴ系の仕事になじみのない人は、「システム設計」「プログラミング」「テスト」をそれぞれ、「コンセプト開発」「製品設計」「量産準備」だとか、「機械設計」「資材調達」「製造」とか、自分に理解しやすい業務におきかえてみてほしい）。

ＷＢＳ・案１
1　モジュールＡ
1.1　モジュールＡを設計する
1.2　モジュールＡをプログラミングする
1.3　モジュールＡをテストする
2　モジュールＢ
2.1　モジュールＢを設計する
2.2　モジュールＢをプログラミングする
2.3　モジュールＢをテストする
3　モジュールＣ
3.1　モジュールＣを設計する
3.2　モジュールＣをプログラミングする
3.3　モジュールＣをテストする

ＷＢＳ・案２
1　設計
1.1　モジュールＡを設計する
1.2　モジュールＢを設計する
1.3　モジュールＣを設計する
2　プログラミング
2.1　モジュールＡをプログラミングする
2.2　モジュールＢをプログラミングする
2.3　モジュールＣをプログラミングする
3　テスト
3.1　モジュールＡをテストする
3.2　モジュールＢをテストする
3.3　モジュールＣをテストする

さて、上記二つの案のうち、どちらをとるべきだろうか？　あるいは、両者は互換的(convertible)で、内容的に差はない、と考えるべきだろうか。
(中略)
ところが、両者は実務的には大違いなのだ。プロジェクトの生みだす成果物の品質や納期だって、大きな差が出るだろう。なぜだろうか？
(引用終了)

僕は今まで、案件の状況に合わせて切り替えたら、と答えていたが、上記の記事では、この質問の本質をズバリ言い当てていた。

(引用開始)
そして、プロマネであるあなたは、自分のプロジェクトをどのようにマネージしたいかによって、どちらのＷＢＳをとるか判断するべきなのである。
たとえば、モジュール間の関連性が強くて、全体が密結合のシステムを作る場合は、プロセス中心型で進めたいだろう。
逆に、たとえばすでにあるシステムに、新規機能をいくつか追加していくようなプロジェクトならば、モジュールができた順にリリースしたいから、成果物中心型を選ぶだろう。
もしもこれが逆だったら、いかに仕事がやりにくいか、想像に難くない。
(引用終了)

【2】すなわち、工程単位・機能単位のWBSをPERT図に書いてみると、PERT図の構造は全く違う。

工程単位なら、工程ごとに合流して派生するから、工程に属する全てのタスクは全て同じ終了日までに確実に終わらなければならない。
つまり、工程内部では並行開発になるので、それぞれのタスクの同期が非常に重要になる。

普通は、SEチームが設計、開発チームが開発・単体テスト、SEと開発者の両チームが結合・総合・受入テストを行うようなチーム編成になるだろう。
すると、各工程ごとに開発要員の変動が大きく起きるので、チームを去っていく作業者の引き継ぎ作業が重要になってくる。

また、工程内でクリティカルパス上のタスクが一つでも遅れると、開発案件の全体の納期がすぐに遅延してしまう。
だから、残業や休日出勤で、その遅延をリカバリーせざるを得なくなる。

一方、機能単位なら、最初と最後だけ派生・合流し、途中の進捗は各機能でばらばらになる。
実際のチーム構造は、機能単位のチームになるので、チームは自分たちだけの機能の進捗を管理すればいい。
但し、他のチームと同期が取りにくいので、CCBやスクラムオブスクラムのようなリーダー会議を設けるなどして、機能間のI/Fや共通ライブラリの開発を調整したり、共同作業する場をもうける必要があるだろう。

つまり、WBSの構造は、チーム内のメンバーの役割と開発体制に影響させるし、その影響から離れられないのだ。

【3】上記の話をRedmineに当てはめてみるとどうなるのか？

工程単位にチケット管理したい場合も、機能単位にチケット管理したい場合も、チケットに書く作業は同じ。
チケットの先行・後続の関係を付ける場合、工程単位と機能単位ではPERT図の構造が異なるので、その内容が反映されるだろう。

また、工程や機能という概念をチケットのどの属性に当てはめるか、という運用も重要だろう。
たぶん2つある。
一つは、対象バージョン、もう一つは、親子チケット。

工程をバージョンに紐付けるのは直観的で分かりやすい。
工程の終了日までに、工程内のタスクを全て終わらせないといけないから、その制約条件と対象バージョンの意味合いは合致しやすい。
しかし、レビュー漏れ、仕様変更などで手戻り作業が何度も発生すると、設計工程がリオープンされてしまい、いつまで経っても設計工程が終了できない、という状況はよくある。
工程単位のWBSはとてもきれいな構造であるが、変化の激しい開発には合わないと思う。

そのせいか、MSProjectに慣れた人ほど、親子チケットでWBSを表現しようとする人が多い。
Redmineの最新バージョンでは、WBS100％ルールの設定ON/OFFができるようになったので、故意に子チケットを親チケットへロールアップする設定を外すこともできるので、柔軟な運用は可能になった。
親子チケットで階層化すれば、ガントチャート画面の見栄えは良くなる。
但し、チケットの階層が深くなるほど、メンバー全員で運用するのは難しくなるのでトレードオフになる。

一方、機能を対象バージョンに割り当てる方法は、FDDの言うパーキングロットチャートの機能と同じだ。
過去に@daipresentsさんが試されている。
機能の粒度が小さければ、パーキングロットチャートで表現すると分かりやすい利点はあるだろう。

Redmineプラグイン開発 ? パーキングロットチャートプラグインリリース

Redmineにプラグインを入れる - ソフトウェアエンジニアリング - Torutk

同様に、機能ごとに親子チケットでWBSを表現することも可能だ。
この場合、WBS100％ルールを使って、親チケットは子チケットの進捗情報をロールアップするように設定した方が進捗が分かりやすくなる。

但し、複数の機能に関する障害とか、仕様変更が発生した場合の作業は、チケットでどのように表現すべきか？という課題は残る。
実際は、それぞれの障害や仕様変更の単位でチケットをその都度作成する運用になるから、機能単位にWBSを作るのも、そんなに綺麗なやり方にはならないだろう。

個人的には、作業ごとにチケットを起票し、リリース日ごとにチケットをグループ化して小刻みにリリースしていくアジャイルな開発スタイルがチケット管理に最も向いていると思う。
WBSを綺麗にチケットに表現して管理していこうとすると、予期しないトラブルや仕様変更に耐え切れない。

【4】「機能単位・工程単位のWBSがプロジェクトの組織構造を規定する」法則をRedmineチケット管理に当てはめると、どちらでも運用できるし、WF型でもアジャイル型でも運用できる柔軟性はある。

つまり、WBSが組織構造を決めるという流れではなく、自分たちの開発体制にRedmineを合わせるという流れに持ち込みやすい。
換言すれば、Redmineは運用を非常にカスタマイズしやすいことを示唆していると思う。

Redmineの機能と組織構造、開発体制の依存関係については、他の観点でも色々考えてみる。

Redmineのプロジェクト間チケットコピー機能で縦割り組織のサイロ化を打破する記事のリンク

「プロジェクト間チケットコピー機能の改造で縦割り組織のサイロ化打破？」の記事がすごく参考になるのでメモ。

【参考】
Redmineを1000人規模で使っていたら…: プロジェクト間チケットコピー機能の改造で縦割り組織のサイロ化打破？

(引用開始)
Redmine上のプロジェクトの粒度とも関連するが、複数のプロジェクト間で情報共有しなければならないケースで、必須となるのがチケットのコピー機能だ。

ソフトウエア開発では（いや、ソフト開発に限らないかもしれないが）、顧客への「製品・サービス」や「展開品・派生品」を管理するグループ（縦軸）と、機能・コンポーネント等の単位で開発を行うグループ（横軸）で構成される、いわゆるマトリックス体制を採ることが多いと思う。
多製品・サービスになればなるほど、開発部隊は開発対象をプラットフォーム化・共通化し、製品やサービスに展開することで開発効率を上げるためだ。このような組織で、プロジェクト管理ツールを使うとなると、ツール上の「プロジェクト」の粒度をよく考える必要が出てくる。

縦軸や横軸を形成するグループが複数存在し、各々が役割分担している場合、それぞれプロジェクトを分ける方が良いだろう。なぜなら、Redmineの場合、プロジェクトが分かれても、プロジェクト間でチケットのコピーを極簡単に行える（後には、Versionのプロジェクト間共有も可能となった）からだ。

そして、それだからこそ、プロジェクト間の依頼事項はチケットのコピーによって行うこととなる。チケットのコピーは、重複を生むと考えられがちだが、それはちょっと違う。
グループ間でコピーされたチケットは、そもそものチケットのゴール（CLOSE条件）が違うからだ。
横軸はバグ修正や機能の実装が完了すれば、そのチケットはCLOSEする。縦軸はそれらの案件を顧客にリリースすることでCLOSEすることになる。
平行開発する派生品があれば、派生品毎にそれぞれCLOSEすべきタイミングがが異なることもザラだ。
CLOSEするタイミングが異なる案件を一つのチケットで管理しようとする方が、かえって無理というものだ。
自分の組織では、各グループの独立性が高く、（というかグループ間の見えない壁みたいなモノで、）いわゆるサイロ化現象を起こしていた。
だからこそ、一つのチケットが複数のグループで各々の責任範囲を持つとき、コピーすることで案件を分割するこの考え方が、非常にしっくりきたようだ。（またこの運用が、組織的なRedmine利用の原動力ともなった。）
もっとも、複数のグループを一つの「プロジェクト」で全て包含し、その中で「Version」（マイルストーン）を複数立てて管理することも可能であろうが、これでは各々のグループの独立性が高いほど（マトリックス開発の役割分担がはっきりしていればいるほど）、運用は困難になるだろう。
(引用終了)

いわゆる製品やシステムの派生開発では、本流(trunk/master)の障害修正は、傍流(branch/顧客ごとにカスタマイズしたbranch)でも障害修正する必要がある。
たとえば、OSやApacheのセキュリティパッチ、OracleやMySQL、Rubyなどのミドルウェアのパッチなどがある。
しかし、発端となったインシデントPJの障害チケットと、それらの派生システムへ内容コピーの障害チケットは、単純なコピーではない。
傍流の派生システムのリリース日も違うし、進捗も違うから、それぞれの派生システムでチケット管理したい。

上記の記事では、プロジェクト間でチケットをコピーする機能をこのような派生開発の作業管理に適用することで、トレーサビリティや各製品ごとの進捗管理がやりやすくなる、と主張されている。
その内容はとても同意する。

また、Redmineのプロジェクト間チケットコピー機能で縦割り組織のサイロ化を打破できるのでは、という示唆も興味深い。
派生製品の開発体制は、システム・製品単位のProductのグループ、機能や顧客ごとにカスタマイズした派生製品ごとの機能グループの2つの軸になる。
つまり、マトリクス型の組織体制になる。

一般の組織論の知見では、マトリクス型組織は運用したくなる場面が多いが、運用が非常に難しい。
ツーボス制になるために指揮命令系統が複雑になりがちだし、複数の組織に属するがゆえに自由に行動できる権限の範囲があいまになりやすい。
結局、従来の縦割り組織の開発スタイルのまま、突入して、コミュニケーション不足が発生して、潜在バグが多数残ったりして、リリース後に大きな障害を招いたりする。

根本的な解決方法はないけれど、Redmineの複数プロジェクト機能を用いて、マトリクス型組織を擬似的に当てはめることで、縦割り組織に属するメンバーが一つのRedmineプロジェクトに属することになり、チームとしての一体感が湧きやすくなる利点はある。
たとえば、SEチーム、製造チーム、テストチームのような縦割り組織があったとしても、一つのRedmineプロジェクトにSE・PG・テスターが割り当てられれば、一つのチームとして、各チケットをペア作業のように連携するようになっていく。
この「チームとしての一体感」という雰囲気の醸成が重要なのだ。

但し、Redmineのコピー機能はかゆいところに手が届いていないので、改造したらしい。
詳細は、記事を読んで下さい。

(引用開始)
ただ、Redmineのコピーの機能で、上記いの運用を行おうとしたとき、何かかゆいところに手が届かない感じがした。

・チケット登録権限のないプロジェクトへもチケットをコピーできてしまう。
・プロジェクト間でチケットをコピーしたことが、その時点で判らない。
・コピーしたら、各々のチケットの進捗が判るよう、チケット関連付けをするルールにしたものの、ちょっと面倒。忘れることもしばしば。
・状況によっては、チケットに付随するウォッチャーもコピー先へ反映させたいことも多い。

これらを改善すべく、以下の改造を施した。

＜プロジェクト間チケットコピー・移動の運用ルール＞
・チケットを取りに行くPull型がお勧め。
関連するプロジェクトのチケットを参照し、他のプロジェクトで自分のプロジェクトに関するチケットが発生したら、自分のプロジェクトへコピーするという原則。
プロジェクト間の最初の伝達は定例会議や口頭（生のコミュニケーションも大事）、チケットのウォッチャー指定など様々。

・コピー・移動先のプロジェクトで、チケット登録することができ、チケットをアサインすることのできる立場の人なら、Push型でも良いが、そうでない場合無視されるチケットが出たりしかねない。
（そういう意味でチケットをPushできる人を運用上決める必要性が出たり、余計なアクションが増えてしまうので、しっくりこなかった。）
(引用終了)

上記の記事が指摘していることを考えると、機能別組織であるソフトウェア会社でマトリクス型組織を導入したい場合、Redmineが有効ではないか、という意見を示唆しているかもしれない。

但し、大規模な組織の多様な業務にRedmineのチケット管理を導入したい場合、第10回redmine.tokyo勉強会で議論されたように、たくさんの課題はある。
大規模な組織と多様な業務にRedmineが耐えるために、必要な機能と必要な運用ルールは何であるか、今一度考えてみたい。

第10回redmine.tokyoの感想～Redmineユーザはメトリクスがお好き #redmineT: プログラマの思索

Redmineが日本人好みのツールであるという仮説

第10回東京Redmine勉強会のグループディスカッションでも話題になったのが、Redmineの運用が大規模化していく上での課題だ。
@Will_meaningさんとのやり取りがとても参考になったのでメモ。
以下は私的感想。

【参考】
Redmineの運用が大規模化していく上での課題～@Will_meaningさんとのやり取り - Togetterまとめ

Redmineを運用している規模について - Google グループ

第10回東京Redmine勉強会～「メトリクスの見える化とその周辺」　#redmineT - Togetterまとめ

【1】@Will_meaningさんが持つ問題意識は「なぜ海外ではJIRAが多く普及していて、日本ではRedmineが多く浸透しているのか」。
彼の意見を読むと、「SVN中心の開発プロセスはRedmine、Git中心の開発プロセスはJiraやGitHubではないか」という意見のように思える。
理由は、「ビジネスアジリティという視点で見た時に、どのくらいのスピード感が必要かによって、開発スタイルの方向性が絞られていき、そこからSVN（集中型管理）かGit（分散型管理）かが決まり、それに見合う関連ツールとして、RedmineかJIRAかが決まっているんじゃないかなと思うんですよ。」だから。

確かに、そんな部分もあるだろう。
特にJiraは、アジャイル開発用のプラグインも揃っているし、Git連携だけでなく、ビルド管理やWikiなどの周辺ツールもパッケージ製品群として完成している。
お金があれば、SIがソフトウェア開発の基盤として持ってもいいだろうと思う。

だが、悲しいかな、日本のIT企業やソフトウェア開発の現場では、開発基盤にコストを払ってもいいという認識はない。
だからこそ、Excel管理や大量の紙による申請承認フローが、SIの現場でもいまだに残っているのだ。

【2】でも、そんな現状があったとしても、ソフトウェアの開発基盤をオープンソースのプロセス支援ツールで固めて、アジャイル開発の恩恵が受けられるように業務を改善することは意味があると思う。

個人的な思いとしては、Redmineは日本人好みのツールであるように思う。
理由はいくつかある。

【2-1】一つは、ライセンスが無料であり、導入や設置が簡単で、保守工数だけで十分であること。
Redmineはオープンソースなので、余ったサーバーに、まずは評価検証用にインストールすればいい。
Bitnamiのようなワンクリックインストーラーを使えば、導入はすごく簡単。
タスク管理・障害管理・問合せ管理に必要な設定は、全てWeb画面から操作できるので、すぐに運用を開始できる。
Redmineでお金がかかるとすれば、社内のサーバー保守くらいであり、小規模チームで運用しているなら、管理工数の一部に含めてしまえばいい。
顧客向けの進捗報告や障害報告を作成するために、元ネタとなる進捗データをExcelで収集して集計するくらいなら、Redmineでデータを蓄積して、加工集計するスクリプトを自作した方が早い。

【2-2】もう一つは、自分たちで機能拡張していく機運が生まれて、現場主導で業務を効率化していこうとする動機づけを強化してくれること。

以前、陸野さんが言われていたが、Redmineを社内に導入したら、Redmineに足りない機能は開発者が自ら作って補おうとする雰囲気が出てきて、自然にプロセス改善が進んだ、という話があった。

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

第14回RxTStudy勉強会「Redmineの未来を考える - 機能・運用・コミュニティ」の感想 #RxTStudy: プログラマの思索

SEPGとしてCMMI/PSP/TSP、アジャイルなど数多くのプロセスを導入、運用されてきた。
その過程で、現場にたくさんパッケージ製品のプロジェクト管理ツールを入れてきたが、そのたびに失敗した。
パッケージ製品のプロジェクト管理ツールは、作った会社のプロセスが織り込まれている。
だから、自社の組織文化や自社の開発プロセスにフィットしない部分が必ずあり、そこがボトルネックになって、業務の改善がなかなか進まない。

しかも、パッケージ製品はカスタマイズしようとすると費用がかかり、VerUpのたびに追加コストがどんどん膨らんでいく。
結局、パッケージ製品の外側で、他社製プロジェクト管理システムで不足した機能を手作業でカバーする運用が生まれて、無駄な管理コストが増えてしまいがち。
すると、現場の開発者も、業務をより良くしていこうと動く前に、不平不満をこぼして、何もしなくなる。
たとえば、業務システムの現場でも、ERPのようなパッケージ製品を導入した結果、システムの中身がブラックボックスのために、業務の改善をやろうとしても業務の全体を見通せる人がいなくなって、どこも苦労している。

一方、オープンソースの開発基盤やプロセス支援ツールは、自分たちのプロセスにカスタマイズが可能だ。
自分たちでソースパッチを当ててもいいし、ツールの外側で集計用Excelマクロなり、集計用スクリプトなりを作って、不足した機能を補えばいい。
そういうツールを作ることは結構楽しい。
プログラミング技術を使って、自分たちのソフトウェア開発プロセスを作り上げていくのが楽しいのだ。

その雰囲気は、バブル不況前の日本の製造業の現場にあったQCサークルと同じ雰囲気ではないか、と想像する。
現場にある目の前の道具を使って、どのようにアレンジすれば、製造工程を効率化できるか、同僚が議論しながら、試行錯誤していたはずだ。
でも、ISO9001のような舶来の品質管理手法が導入されて、日本独自の良さが失われ、ドキュメントを一生懸命作る管理作業ばかり追われるようになった、という話はよく聞く。

【2-3】たぶん、日本人はプロセスイノベーションが得意。
iPhoneのようなラディカルイノベーションを生み出せなくても、品質管理のようなプロセスイノベーションを生み出してきた歴史を振り返ると、オープンソースの開発基盤を用いて、プロセス改善していく手法は、日本人の性格に合っているのではないかと思う。

日本の歴史を見れば、中国や西洋の文化を取り入れた時、それを自分たちの体に合わせて、加工して取り入れてきた。
だから、オープンソースの開発基盤ツールの方が、自分たちの組織文化に合わせて、フィットできるようにカスタマイズするのは多分得意なのかもしれない。

【2-4】しかし、Redmineの運用が隣のチーム、隣の部署へ拡大していくと、社内の保守工数も馬鹿にならなくなっていく。
そして、オープンソースのツールを自社独自にカスタマイズするよりも、市販のパッケージ製品を入れて、保守コストを下げた方がいいのでは、という動きも出やすい。

その流れは、自社独自の業務システムを汎用ERPにリプレースして、社内の人件費のコストも下がり、見た目はスッキリしたものの、せっかく育まれた組織文化が消えてしまうのと同じ症状かなあ、と思ったりする。
ERPというブラックボックスのシステムは、現場の人の活動を統制することが主な目的なので、現場の人達の自由度が減り、自分たちでシステムを上手く使って効率化しようという動機は生まれにくいから。

【3】RedmineやJenkinsなどの開発基盤ツールが日本人好みではないか、という仮説はもう少し考えてみたい。

【追記】
RedmineとJiraの機能比較について、Jiraの立場から書かれた記事がある。
画面キャプチャの比較なので分かりやすい。

JIRA Software(+Atlassianツール) vs Redmineについて - 製品とサービスのブログ - サポートドキュメント

Redmine Pivot tableプラグインのリンク

Redmine Pivot tableプラグインのリンクをメモ。

【参考】
Redmine Pivot Table - Plugins - Redmine

deecay/redmine_pivot_table: This Redmine plugin allows you to generate pivot table for issue analysis.

第10回勉強会 - redmine.tokyo

第10回東京Redmine勉強会の松谷さんの講演で、Redmine Pivot tableプラグインを使えば、Redmine上でExcelのピボット集計と同じように実現できる、と話があった。
Excelでチケットを加工集計した時に、よく使う機能がピボット集計。
色んな観点でグロスしたいんだよね。
マネージャの人は使ってみたい機能だろうと思う。

@y503Unavailableさんが人柱(笑)になって試した所、マイグレーションもないし、良い感じみたいなので、入れてみたい。

y503Unavaiさんのツイート: "1000件limit有、大規模時は注意ですね RT @akipii: なるほど。RT @y503Unavailable: Redmine pivottableを、3.2と2.6の環境に入れました。db変更無し、入れて権限設定するだけ。cpu負荷は実際の使用時のみ。良さそうです。"

但し、Redmine上でピボット集計したとしても、設定を保存できないのでは、という話もあるので、検証してみる。
でも、Redmine上でリアルタイムにピボット集計だけでも、チケットのおかしな部分を事前チェックできるし、チケットを集計したら即座にピボット集計してみて修正されたか確認できるのはメリットだ。

仕掛けを見ると、PivotTable.jsというオープンソースのJavaScriptライブラリを使っている。
Redmine Pivot tableプラグインを使わなくても、下記の記事のように、自分でRedmineプラグインを簡単に自作できるのも利点だ。

Redmine3.2プラグイン開発入門 (1) - 新規画面を追加する - Qiita

下記の記事を読むと、PivotTable.jsでGoogle スプレッドシートのデータを集計表示させたり、Web画面上でピボット集計表示させるのは簡単みたいだ。
最近は、ブラウザ上の表示UIをリッチにするJSライブラリが揃ってきているので、RedmineにもPivotTable.js以外のJSライブラリを流用することで、レポート表示や集計処理がビジュアル化されると面白いだろうなあ、と思う。

nicolaskruchten/pivottable: Javascript Pivot Table (aka Pivot Grid, Pivot Chart, Cross-Tab) implementation with drag'n'drop.

PivotTable.jsを使ってjavascriptで集計を簡単に表示するテスト(jqueryでピボットテーブル) - tweeeetyのぶろぐ的めも

Google スプレッドシートのデータをPivotTable.jsで表示する - Qiita

第10回redmine.tokyoの感想～Redmineユーザはメトリクスがお好き #redmineT

第10回redmine.tokyoは参加者100名超の大盛況で終わりました。
参加者、スタッフの皆さん、そして、コミッタのまるやまさん、コントリビュータの前田剛さん、ありがとうございました。
UStreamでも参照できるので、私的感想をメモ。

【参考】
第10回redmine.tokyo勉強会 - dots. [ドッツ]

第10回勉強会 - redmine.tokyo

第10回東京Redmine勉強会～「メトリクスの見える化とその周辺」　#redmineT - Togetterまとめ

【1】Redmineの開発とリリース計画作りは、わずか3人の体制で支えられている。
役割分担は、JPLが機能追加やリリース作業、まるやまさんがバグ修正やテストコード整備やRails5対応、前田剛さんがチケット整理と次バージョンの対象チケットをアサイン、となっているらしい。
Redmine本家の活動ログを見る限り、3人体制で上手く回っているように見える。

でも、第三者から見れば、Redmineは日本でこれだけ普及したOSSのプロジェクト管理ツールであり、SIの事実上の基幹系業務システムになっている現状を考えると、Redmineの開発体制はもっと強化してもいいかもしれない。
今後もずっと、永久的にRedmineの開発が安定して続けて欲しいのだ。

前田剛さんから、Redmine本家に、バグ報告や機能改善の提案があれば、チケット登録して欲しいと、実際の操作方法も説明された。
また、前田剛さんによれば、Twitterで「#Redmine」のハッシュタグを付けてバグ報告してもらえるだけでも拾えるから、と言っていた。

Kawabata Mitsuyoshiさんのツイート: "Redmineのコミッターは実質2人だけ。日本人コミッターまるやまさんはバグ対応しか出来ないほど追われてるので、バグ対応のパッチを送ってくれることが今一番の貢献じゃないかなと思う #redmineT #eventdots"

akipiiさんのツイート: "あなたの秘蔵パッチも本家にあげて欲しい。一度マージされれば、その後は本家が保守してくれる。 #redmineT #eventdots"

akipiiさんのツイート: "スクリーンショットは英語モードで添付して欲しい。本家の人達は海外の人だから。 #redmineT #eventdots"

松谷　秀久さんのツイート: "英語がハードルの方はGoogle groupのRedmine users(japanese)へどうぞ https://t.co/sdeNF9xQ0T"

redmine.tokyoやRxTStudyというユーザコミュニティも、Redmineのバグ報告や機能改善の提案などのフィードバックが行えればと思う。

【2】ViewCustomizePluginはとても面白いプラグインだ。
フック処理を上手く使ってRedmineの表示処理を自由に制御できる。
Redmineコミッタから見れば、邪道なプラグインかもしれないが、Redmine運用管理者にとっては非常に、かゆい所に手が届きやすいプラグインだろうと思う。

なぜなら、ちょっとした表示処理を微修正するために、Redmine本体のソースにパッチを当てたり、プラグインを追加するとなると、RedmineのDBマイグレーションやRedmine再起動が発生したりするからだ。
@netazoneさんが講演されたように、ユーザが会社全体に広がり、海外の工場でも使われ始めると、Redmine再起動のタイミングがなくなってしまうからだ。

ViewCustomizePluginを使った事例のうち、聞いた話では、金額にカンマ表示させたり、二つのプルダウンのカスタムフィールドの値同士に関連の制御をかける事例を聞いた。
たとえば、OSと.NETバージョンの二つのプルダウンに関連がある場合などだ。

ViewCustomizePluginは他の利用シーンでも使えるので、利用シーンごとに表示処理をカスタマイズするJQueryのソースが整理されると面白いだろうなあと思う。

【3】「メトリクスの見える化」というテーマは、今回の勉強会の参加者に聞くと、食い付きが良かったらしい。
話を聞くと、Redmineに溜まったチケットデータを集計する作業を実際にExcelでやっていたり、メトリクス集計をしたいがどんな方法が効果があるのか知りたい、という人が多かったみたい。

そもそもRedmineに興味を持つユーザ層は、プロジェクトリーダーやPMOクラスの人なので、ソフトウェアメトリクスによる進捗・品質の見える化は一度はやってみたいテーマなのだろうと思う。

【3-1】GnuPlotによるメトリクスのビジュアル化スクリプトの話は興味深かった。
仕組みとしては、PerlスクリプトでREST API経由でRedmineチケットデータを全件取得してCSV形式に加工し、GnuPlotにデータを食わせて画像表示して、RedmineのWikiに「ダッシュボード」タブを作って、メトリクス専用のWikiに最新表示させておく。
ダッシュボードの新規タブを作るには、Wiki Extensionsプラグインを使っているらしい。

Wiki Extensions - r-labs

松谷さんのPerlスクリプトでは、平均完了日数、最大放置日数をRedmineプロジェクト単位にメトリクス出力して、GnuPlotでヒストグラムや折れ線グラフ、散布図などで表示させる。
さらに、WikiListプラグインを使って、GnuPlotの元ネタとなるCSVデータを表形式にWikiで表示し、さらにそこから詳細はチケット一覧のクエリへリンクさせるようにしているらしい。

Wiki Lists - Plugins - Redmine

そうしておけば、たとえば、最大放置日数が多いチケット2件はどのチケットか、そのチケットを最優先で対処すべき、という意思決定が容易に行えるようになる。
また、1週間毎に平均完了日数と更新チケット枚数を折れ線と棒グラフで表示させて、平均完了日数が週ごとに短くなっているならば、チームが学習して開発速度が上がっている、という評価もできる。

この使い方は面白い。

また、GnuPlotで、信頼度成長曲線の関数を使えば、チケットの情報を渡せば、信頼度成長曲線の定数値を自動計算してくれるらしい。
チケットの精度やデータ数が多ければ、信頼度成長曲線の精度も上がるわけだ。

さらに、そこまで難しく集計加工する必要がないならば、Redmine Pivot Tableプラグインを使えると、Redmine上でExcelのピボット集計のような機能を実現できる。
Redmine Pivot Tableプラグインは、表形式に集計表示してくれるだけでなく、様々なグラフ形式でもビジュアルに表示してくれる。
これは便利だ。

Redmine Pivot Table - Plugins - Redmine

deecay/redmine_pivot_table: This Redmine plugin allows you to generate pivot table for issue analysis.

【3-2】楠川さんの話を聞いて、WorkTimeプラグインの「工数付替機能」の意味がようやく分かった。
どうやら「顧客向け工数報告」プロジェクトと、「チーム内の作業管理」プロジェクトで分けた運用をしているらしい。
つまり、月中は「チーム内の作業管理」プロジェクトで、メンバーは日々の作業チケットに実績工数を登録している。
しかし、顧客向け報告書に、その内容をそのまま出力して報告はできない。
なぜなら、顧客の観点では、本番障害に工数がかかりすぎ、とか、単純な問合せに対してなぜこんなに工数がかかり過ぎているの、など、突っ込みが入ってしまって、顧客に実費請求できないリスクがあるからだ。

そこで、「チーム内の作業管理」プロジェクトから「顧客向け工数報告」プロジェクトのチケットへ実績工数をコピーし、プロジェクトリーダーが、報告書の体裁に合うように、各チケットの実績工数を微修正したり、配分し直したりする。
その作業が「工数付替機能」なわけだ。
確かに、複数のWebシステム保守をやっているプロジェクトリーダーは、実費請求の作業報告書を作る時に、作業内容と実績工数のつじつまを合わせるために、月末に加工する作業にかなりの時間を費やしている。
正直、工数管理の二重管理だ、という指摘もあろうが、SIの準委任契約案件では、このようなドロドロした管理作業はよくあるので、工数付替機能は良く考えられた機能だと思う。

WorkTime - Work Time - r-labs

【4】各テーブルのフリーディスカッションは好評だった。
グループディスカッションで、参加者からRedmine運用の現状や問題点を聞いた。
一部の参加者の話を聞くと、実は、Redmineはソフトウェア開発チームのタスク管理よりも、カスタマーサポートや障害管理などの方が向いている、という意見があった。

理由は、ソフトウェア技術者はGitを使っているので、プルリクエストが使えないRedmineは使いにくい。
だから、GitlabをGitリポジトリに見立てて、IssueのインターフェイスはRedmineを使うように、RedmineとGitlabを連携している。
一方、ユーザからの問合せ対応やインシデント管理、製品のバグ報告の管理は、Redmineのチケットに登録して、ワークフローにのせて担当者に回す運用が上手く回っている、と。

つまり、Gitを使っているユーザは、RedmineのGit連携機能に完全に満足できていない。
一方、カスタマーサポートの担当者は、インシデント管理やバグ管理はRedmineチケット管理だけで十分に回る。

【5】改めて、Redmineの今後の課題の一つは、多様で大規模な組織に、一つのRedmineインスタンスでどれだけ幅広く業務をカバーできるか。
そのためには、Redmineにどんな機能が必要なのか、という課題だと思う。
参加者から数多くのフィードバックを聞いた。

【5-1】たとえば、Apacheのセキュリティバグが判明し、そのバグ修正を行うチケットがあったとする。
すると、一つの製品だけではなく、他顧客の他システム、他のパッケージ製品にもセキュリティパッチを当てないといけない。
その場合、一つのバグ報告のインシデントチケットに対し、関連する複数のシステムや複数の製品に同じ内容のチケットが複製されて、それぞれで対応していく必要がある。
なぜなら、システムごとにセキュリティパッチのリリース日が違うし、進捗も違うからだ。

しかし、発端となったインシデントチケットと、それを複製した他製品のチケットは、一つのRedmineプロジェクトで管理すべきものではない。
むしろ、各Redmineプロジェクトにそれぞれ配置すべきであるが、どのシステムに影響があるのか、漏れ無くチケット登録するのはかなり大変だ。
手作業なのでどうしてもミスが発生するリスクがあるし、インシデントのチケットと派生製品のチケットを関連づけて、各チケットの進捗やリリース日も漏れなく管理したいのに、今のRedmineでは機能や運用ルールが不十分なのだ。

【5-2】たとえば、ISO9001に即した作業管理をRedmineで運用している場合、チケットの構造はISO9001の文書に即した構造になるため、カスタムフィールドがとても多い。
しかも、一度作成した作業依頼書は、内容が似ているので、他の作業でもコピーして流用したくなる。

すると、Redmineチケットのコピー機能を使って、チケットを複製した時、コピー先チケットの登録時にコピー元チケットも関連付けられて、コピー先の担当者やウォッチャーだけでなく、コピー元のチケットの担当者やウォッチャーにも更新メールが飛んでしまう。

Redmineの運用を始めると、大量にメールが流れてしまうため、「～のチケットが関連付けられました」だけのメールは正直不要なので、メール送信から外したい。
しかし、今のRedmineの管理画面では、更新メールの制御条件は「担当者」「優先度」ぐらいしか条件がないので、色んな利用シーンで更新メールを通知させない制御ができない。
本来は、「チケット関連付けを通知する」「説明の変更を通知する」「開始日・期日の変更を通知する」「カスタムフィールドの更新を通知する」などのメール送信制御も入れたいし、プロジェクトごとに更新メール通知の制御もやりたい。

また、現在のRedmineのチケットコピー機能ではなく、単純な「チケット内容の複製」機能が別途欲しい。
終了チケットの内容をそのままコピーして、カスタムフィールドの内容をちょっと微修正して流用したい場面は結構ある。
事務処理ワークフローシステムでよくある「申請書コピー」機能と同じだ。

@netazoneさんによれば、今のバージョンのRedmineチケットコピー機能を使うと、コピー先のRedmineチケットの期日に、コピー元チケットの期日が複製されてしまうため、コピー先チケットの作成日よりも期日が古いという矛盾したチケットが作られるのは困る、と言っていた。
たしかに、チケットコピー機能はもう少し改善したい機能の一つ。

【5-3】JAXAのRedmine運用事例の経験論文では、「ロールのORルール」「カスタムフィールドのANDルール」という優れた運用ルールの説明がある。
参加者からその意図を聞くと、たくさんの部署に展開した時に、各Redmineプロジェクトにロールやトラッカーやカスタムフィールドを割り当てる時、それぞれの部署の業務ごとにそれらを作ってしまいがち。
すると、ロールやトラッカーやカスタムフィールドが50個以上ぐらい発散してしまい、似たような項目が増えていき、システム運用が回らなくなる。

そこで、「ロールのORルール」「カスタムフィールドのANDルール」を導入して、Redmineのロールやカスタムフィールドをできるだけ増やさないような運用方法を編み出した、と言う。
だから、Redmineデフォルトのロール「管理者」「開発者」「報告者」は使わず、独自のロールをいちから作った、と話されていた。
確かに、「ロールのORルール」「カスタムフィールドのANDルール」を徹底できれば、共通のロールやカスタムフィールドを組合せることで、より多くの業務を一つのRedmineインスタンスでカバーすることができるだろう。

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

【5-4】しかし、別の参加者の話を聞くと、会社のRedmineが使いづらいために、各部署ごと、さらには各チームでRedmineインスタンスをこっそり作って、自分たちの課題管理・障害管理・作業管理に使う利用事例もあるらしい。
つまり、自分たちの案件で自由に使いたいために、自分たちのためだけのRedmineインスタンスを作って、自分たちの運用ルールで回している。
すると、その会社では、Redmineインスタンスが20個以上乱立した状態になっているらしい。
その状況を「闇作業」「闇チケット」ならぬ「闇Redmine」と言っていた。

この事例の話は、一つのRedmineインスタンスで数多くの業務、数多くの利用状況をカバーできない問題があることを示している。
その原因は、Redmineの機能不足もあるだろうが、むしろ、運用ルールとRedmine機能のギャップにあると思う。

前田剛さんの話を聞くと、Redmineはそもそもオープンソース開発のためのプロジェクト管理ツールなので、幅広い多様な業務の運用に耐えれるように機能が最初から作られているわけではない、と言われていた。

おそらく、Redmineが当初想定されていた利用シーンであるソフトウェア開発の作業管理から、カスタマーサポートや事務処理ワークフローなど、数多くの業務にも適用されたことで、このような問題点が具体化されてきたのだろうと思う。

つまり、大規模な組織の多様な業務に対し、一つのRedmineインスタンスの機能や運用ルールが追いついていないから、闇Redmineのように、業務ごとに多数のRedmineインスタンスが乱立するわけだ。

でも、複数のRedmineインスタンスを作らざるをえない状況もある。
たとえば、オフショアチームや顧客には社内のRedmineに入れないので別途やり取りするRedmineインスタンスを作るしかない、という状況はよくある。
社内のRedmineには、見積りや原価の情報が記載されているので、社外には見せれない、という事情もあったりする。

したがって、一つのRedmineインスタンスで、大規模な組織の多様な業務をどれだけカバーできるか、そのためには、どんな利用シーンで、Redmineにどんな機能が必要で、どんな運用ルールを整備すべきか、という課題が今後必要になるだろうと思う。

【追記】
発表資料はコチラ。

みんなでRedmineを より良くしよう —Redmineプロジェクトへの貢献の仕方— from Go Maeda

View customizepluginを使いこなす from onozaty

ソフトウェアメトリクス概要 20160514 from Yutaka Ohwada

Redmineでメトリクスを見える化する方法 from Hidehisa Matsutani

工数把握のすすめ 〜WorkTimeプラグインの使い方〜 from Tomohisa Kusukawa

ある工場のRedmine画面カスタム【View Customize Plugin 活用例】 from Kohei Nakamura

Redmineカスタムフィールド表示改善 from Yuuki Nara

チケット駆動開発の原点の記事のリンク

チケット駆動開発の原点の記事をリンクしておく。
自分が参照したいために残す。
主張はなし。

【参考1】
【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」: プログラマの思索

SQIP2009経験論文「チケット駆動開発～BTS で Extreme Programming を改善する(Ticket Driven Development - An Improvement Method for Extreme Programming using BTS - )」

【参考2】
チケット駆動開発の戦略: プログラマの思索

(引用開始)
Redmineによるチケット駆動開発の凄い所は、下記3点だと思っている。

2-1.SVNリポジトリとRedmineチケットが紐づくので、要件とソースコードのトレーサビリティのインフラが整う。つまり、BTSが構成管理ツールになる。
2-2.BTS(Bug Tracking System)のワークフローは、ITS(Issue Tracking System)のように、プロジェクト管理のフレームワークへ昇華・汎用化できる。
2-3.チケット集計結果をソフトウェア・リポジトリ・マイニングによって、色んな角度からメトリクスを採取して、プロセス改善の材料にできる。

今の僕の興味は、BTSを構成管理ツールにして、BTSの運用をプロジェクト管理の汎用化したプロセスにして、最後はソフトウェア工学の知識を流用して、プロジェクトを改善する材料にしたい。
(引用終了)

ITの地殻変動はどこで起きているのか？: プログラマの思索
(引用開始)
チケット駆動開発のルーツは、BTS(バグ管理システム)。
古くは、Bugzilla、Mantis。

BTSは本来、障害管理に昔から使われていたが、このワークフローがとてもスムーズな為、障害だけでなくSW開発の一般タスクへ汎用化しようという発想が生まれた。
TracやRedmineは、チケット管理をメインとして、ガントチャート生成やバージョン管理との連携機能によって、プロジェクト管理機能を持つBTSを課題管理システム(Issue Tracking System)へ昇華させた。

そして、まちゅさんは、Tracのチケット管理からチケット駆動開発(Ticket Driven Development：TiDD)を提唱された。
まちゅさんの本来の主張は「チケット無しのソースコミット不可」。
このチケット駆動開発のアイデアを突き進めると、イテレーティブな開発を補完するアジャイルな開発プロセスであることが分かる。

チケット駆動開発の基本アイデアは、さかばさんによると、「BTSのチケットはXPのタスクカードと同じ」。
XPでは、アナログのタスクカードでPostItなどで運用する。
チケット駆動開発では、チケットとしてタスクカードをデジタル化する。

チケットは作業指示書でもあるから、ステータスや進捗率を入力すれば、リアルタイムに作業状態を追跡できる。
更には、作業開始・終了日、予定・実績工数を入力すれば、ガントチャートを自動生成できるから、進捗管理に使える。
チケットは本来、バグ報告票でもあるから、バグ修正に関するチケットの集計結果から、信頼度成長曲線を作成して、品質管理に使うこともできる。

つまり、プロジェクト管理をチケット管理に置き換えることによって、プロジェクト内部の作業全てをリアルタイムにモニタリングできる。
チケット入力の運用さえきちんとできれば、イテレーション計画の頻繁な変更もコントロールできる。
更には、チケット集計結果やSVNリポジトリ統計のメトリクスを、プロジェクト運営の意思決定の材料として出力できる。
(引用終了)

【参考3】
必然から生まれたチケット駆動開発 - XP祭り関西2009 その３-: ソフトウェアさかば

(引用開始)
これらの一連の自動化を見ていると、新しいことなのに当たり前のような、凄く良いアイデアのようなのに「そうしなければならない」という印象を受けました。

それは、あきぴーさんの発表で意味がわかったような気がします。あきぴーさんのサブタイトルは「チケットに分割して統治せよ」で、TiDDの歴史、背景と効果、経験を語られました。この中で、「TiDDはWeb2.0のようなもの」と言われました。古い技術を使って新しいことをするという意味で言われていたのですが、これが実はTiDDをよく表していると思います。

上に書いたように、TiDDはある意味「当たり前のことをしていったら、こうなった」という印象があります。でも、何か新しく、開発の苦しみを和らげてくれそうな魅力を感じます。

その意味を考えているうちに、かつて川端さんにお願いしたソフトウェアシンポジウムのチュートリアルを思い出しました。このセミナーはXP入門ということでお願いしたのですが、実際はEclipseの実習が中心でした。これは、少人数でソフトウェア開発に向き合うと、ツールを中心に効率化を図るしかないということを意味しているのだと思います。

TiDD(チケット駆動開発)は、その背景の思想から生まれたものではなく、ツールを用いながらプロセスを改善していったら、必然的にそうなったものだと思います。かつての方法論が、背景の思想を元にツールを開発したために実践する際にやりにくい点が生じたのに対し、実践している中で生まれた方法論は、その体系をきれいにまとめられれば従来にない力を発揮できると思います。

今後、そのあたりをまとめたいと思いました。
(引用終了)

TiDD：チケット駆動開発: ソフトウェアさかば

(引用開始)
「チケット駆動開発」は、アジャイル開発(を中心とした)プロセス改善手法です。もちろんBTSがあれば便利に使えますが、ツールが無くてもプロセスを改善することができるはずです。
(中略)

チケット駆動開発もたぶんそうです。便利なタスクカードや「チケット駆動開発環境」というものがあれば、それがブームになるかもしれません。でも、それ以前に良くできたBTSがあったのです。最近のBTSは高機能化が進んでいて、チケットの状態管理、検索、グラフ化、ワークフロー管理、などなど、様々なことができます。その機能はチケット駆動開発に十分なものでした。

そんなチケット駆動開発は現場で生まれました。研究所で生まれたなら、たいそうな概念があって、見た目重視の専用ツールがあったでしょう。でもチケット駆動開発は違います。解決したい問題が先にあり、目の前にあったBTSを使ってやってみたらうまくいった。

その概念もあまり固まっていませんでした。私がここに書いていることも人によっては「ちがう！」と言われるかもしれません。でも、実践したらうまくいった。それが「チケット駆動開発」なのです。

「チケット駆動開発」を育てたのは、技術に対して貪欲で、意欲的な人たちです。いまやアジャイル開発も普通のことになりましたが、数年前までは目新しい概念でした。どの程度役に立つのか、あまりわからない状態でしたが、現場に問題を抱えていた技術者たちはアジャイラーになりました。そして進んで実践し、問題にぶつかり、チケット駆動開発を見出したのです。

私が「チケット駆動開発」に魅力を感じるのは、そんな技術を実践する人たちが育てているからかも知れません。オブジェクト指向も、アジャイル開発も、そんな人たちが育てたから、良いものになりました。きっと「チケット駆動開発」も良いものに育っていくだろうと思っています。
(引用終了)

【参考4】
「チケット駆動開発」について分かったことと、日本の開発現場での課題 - I18n and L10n in My Life

(引用開始)
チケット駆動開発って言葉は日本だけで使われている？

チケット駆動開発に対して、海外ではどのように考えられているのか興味をもったので、先ほど社内ウィキで聞いてみた。時差の関係で、ヨーロッパのエンジニア二人から回答があったが、そもそもチケット駆動開発 = ticket driven development という言葉を、アジャイルやXPというコンテキストで、聞いたことがない、と。

最初は、欧米ではチケット駆動開発が当たり前（当たり前かどうかは未確認）すぎて、そういった言葉をあえて使う必要がないのかと思った。だけど念のため、英語でググッてみた。すると、ヒットするページは日本人の作成したページばかり。どうやら和製英語である可能性が高そうだ。
さらに調査をすすめてみると一つの文献にぶちあたった。第28回 ソフトウェア品質シンポジウム2009の資料です。
「チケット駆動開発」-BTSでExtreme Programmingを改善する- (PDFファイル)
その文献の最後の方に「TiDD の名付け親のえと～さん」とあるではないですか！「えと～さん」がどなただか分かりませんが、これが本当だとしたら、やはり日本でできた言葉のようですね。
すいません、デベロッパーとしての現場経験のない中で、いろいろと考えて書いています。間違っているところ、トンチンカンなところがあったら遠慮無くご指摘ください。教えてください。特に上のパラグラフの方。
(引用終了)

Redmineカテゴリのデフォルト担当者を上手く使う運用方法

Redmineカテゴリのデフォルト担当者を上手く使う運用方法はないか、探していたら、下記の記事があったのでメモ。

【参考】
チケット作成時にカテゴリ選択で担当者を割り当てる | Redmine.JP Blog

【1】Redmineの各プロジェクトで任意に設定できるチケット属性として、カテゴリと対象バージョンがある。
Redmineを大規模運用している場合、この2つの機能を上手く使って欲しいのに、全く使わないチームが多い。
話を聞くと、カテゴリを使うメリットが分からない、とよく言われる。

カテゴリの本来の機能は、チケットを分類する、あるいは、チケット一覧の検索条件の一つとして使うべき。
よくある例は、カテゴリに、システム名・機能名・種別(画面・帳票、OL/BT)・部署名などを設定する。
チケット集計したい時にカテゴリでグルーピングすることで、プロジェクトの状況を把握できるメリットがある。

しかし、案件や業務の特徴によっては、チケットを分類・検索条件として使わない状況もある。
特に、チケットをどんどん起票して、カンバンのように流していく運用では、チケットに入力する項目を出来るだけ減らしたい。
チケット入力者は自分のチケットしか頭にないので、チケット集計をするためにわざわざカテゴリのような項目を入れる動機も少ない。

【2】Redmineカテゴリ設定画面を見ると「デフォルト担当者」というリストがある。

(引用開始)
チケットのカテゴリには担当者を設定することができます。新しいチケットの作成時に担当者の指定を省略してカテゴリを選択すると、カテゴリの担当者をチケットの担当者として自動的に設定することができます。

この機能は次のような応用が考えられます。

1)特定の担当者が決まっている業務について新たにチケットを作成する際に、カテゴリを選択することにより担当者の指定を省略できる。チケットを起票する者は誰がどの業務の担当者か把握していなくても、適切なカテゴリを選択すればチケットには適切な担当者が設定される。

2)定期的に担当者が変わる業務のカテゴリを作成しておき、カテゴリに常に最新の担当者を割り当てておく。チケットを起票する者は現在の担当者が誰かを把握していなくても、新規チケットを作成する際にカテゴリを選びさえすれば適切な担当者を設定することができる。

カテゴリ選択による担当者の設定が行われるのは、新規のチケットを担当者未設定の状態で作成したときのみです。チケット作成時に担当者を選択した場合はカテゴリの担当者よりも選択した担当者が優先されます。また、既存チケットのカテゴリを変更しても、担当者の自動設定は行われません。
(引用終了)

上記の記事のように、カテゴリ＝業務に対応付けて、業務のデフォルト担当者が決まっている場合、カテゴリのデフォルト担当者を設定しておけば、チケットの新規作成時にカテゴリを設定することで担当者がデフォルトで設定される。
これは便利だ。

カテゴリのデフォルト担当者を使いたい場面としては、申請手続きのような事務処理ワークフローが適しているだろう。
事務処理では、業務の種類は申請書という帳票ごとに決まっており、その業務も普通は担当者が固定されている。
したがって、チケット作成時にカテゴリを選択する手順を踏めば、担当者が空欄でも、自動設定される。
つまり、申請書をチケットに作成した時の担当者が不明な場合は、カテゴリだけ設定しておけば良い。

普通は担当者＝空欄のようなチケット管理の運用は少ないだろうが、Redmineカテゴリのデフォルト担当者を上手く使う運用方法は事務処理ワークフローには適しているように思える。
色々試してみる。

【追記】
MAEDA, Goさんのツイート: "@akipii Redmine公式サイトではカテゴリ「Website (https://t.co/wPJTDg14AH)」を選択してチケットを作ると担当者が「Jean-Philippe Lang」にセットされます。"

少人数のチームの方がソフトウェアの品質は高いという経験則

少人数のチームの方がソフトウェアの品質は高いという経験則の記事があったのでメモ。
この記事は非常に興味深い。

【参考】
「少人数のチームの方がソフトウェアの品質は高い」実証的ソフトウェア工学の研究会が開催 － Publickey

ソフトウェア開発の世界では、幾つかの有名な経験則がある。
例えば、Conwayの法則「ソフトウェアアーキテクチャはそれを作った組織構造をそのまま反映してしまうので、複雑な組織は複雑なソフトウェアを作る」があるし、ブルックスの法則(人月の法則)「遅れているプロジェクトにメンバーを追加すると、より一層プロジェクトは遅延する」などがある。

(引用開始)
ソフトウェア開発の世界では、次のような法則があると言われている。
コンウェイの法則： 組織の構造が、システムの設計にも大きな影響を与える。
ブルックスの人月の神話： 組織の構造がプロダクトの品質に大きな影響を与える。
しかし組織が実際にどれくらいソフトウェアの品質や構造に影響を与えるかは分かっていなかった。それを研究したものだ。
(引用開始)

マイクロソフトの事例では、少人数のチームの方がソフトウェアの品質は高いという経験則が得られたらしい。
つまり、Conwayの法則、ブルックスの法則はソフトウェア品質にも適用できるわけだ。

上記記事の下記の文章がとても分かりやすい。

(引用開始)
組織構造の縦方向が短い方がソフトウェア品質がいい。
少し分かりやすい例を示す。

1つ目はバグが発生するリスクの低い例。青い色が組織、緑の輪が1つのバイナリ、赤が新機能、星が変更を示す。
この図では、赤い丸の新機能を追加するときに3カ所の変更が行われたことを示している。これが1つの組織の中ですべて行われていれば、バグが発生するリスクは低い。

次はリスクの高いパターン。組織をまたがってバイナリが存在し、新機能も変更部分も散らばっている。これは問題が発生する典型的なパターンだ。

3つ目は、潜在的なリスクを含んでいるパターン。複数の組織によってあるバイナリに対して新機能の追加なしに変更が行われる。こういうときには、お互いの変更に気付かず、いつの間にかバグを抱えてしまうという可能性が高いのだ。
(引用終了)

例えば、4つのチームが一つのシステム(war, jar, dll, exe等)を開発しているとする。
1個のチームで閉じているバイナリモジュールの機能の修正は、バグの影響度が小さい。

4つのチームにまたがるバイナリモジュールに手を加えた場合、他チームへの影響が大きいために、バグの発生リスクが高くなる。
新規機能や機能変更などを一括リリースすれば、必ず本番障害が発生し、問題状況の収拾さえ付かなくなる場合もありうる。
デスマーチプロジェクトそのものだ。

一方、4つのチームにまたがるバイナリモジュールの一部をあるチームが修正した時、その修正が他チームへの影響の考慮が漏れてしまえば、潜在バクになる。
そのような仕様変更が積み重なっていけば、システムの技術的負債は大きくなり、リファクタリングすらできなくなるだろう。

そして、最終的には、バグ修正のコストが大きすぎると判断して、システムの外でデータパッチを当てたり、人が手運用でシステムトラブルを回避するなど、沢山の人手でカバーせざるを得なくなる。
10年以上使い続ける業務システムは、ほとんどが、定期的な手運用のシステムサポート業務でカバーされていて、システム保守費用の方が毎年高くなっている時が多いだろう。

そんな事を思うと、大規模な組織でソフトウェアを作るよりも、少人数のチームで開発するスタイル、つまり、アジャイル開発が現場に浸透しているのは、上記のような経験則を知らなくても、暗黙知として認識しているからだろう。

個人的には、今まで皆が当たり前と信じているソフトウェア開発の常識を、Redmineに蓄積されたチケットデータから分析して評価することができたら面白いだろうなあ、と思ったりする。

Redmineチケット一覧のフィルタ「対象バージョン」のリストが大量表示されて使いにくい問題点

redmine-users-jaメーリングリストで、「Redmineチケット一覧のフィルタ「対象バージョン」のリストから終了したバージョンを表示させない方法」に関するスレッドが面白かったのでメモ。

【参考】
チケット一覧のフィルタ「対象バージョン」のリストから終了したバージョンを表示させない方法 - Google グループ

【1】チケット駆動開発では、対象バージョンがマイルストーン・イテレーション・リリースバージョンに相当するように運用するために、対象バージョンは非常に重要な機能であり、対象バージョンをたくさん作る。
しかし、Redmineチケット一覧で、対象バージョンをフィルタリングする時、進行中のバージョンだけでなく、終了したバージョンも表示されるため、リストに大量表示されて選択しづらいという問題がある。
スレッドでも下記のような意見がある。

(引用開始)
よくチケット一覧を、「対象バージョン」でフィルタして使用しているのですが、
対象バージョンの選択リストに、終了したバージョンが多数表示され、
目的の現行バージョンの選択が、結構大変になってきました。
(引用終了)

(引用開始)
これ、徳永さんや本家チケットに上がってる動機も、クローズしたバージョンが多すぎて
リストの選択肢がすごいことになるんですよね。
知り合いの会社も、毎月10個ぐらいバージョン作成した運用されているので、
3年運用するとなると、300個以上リストが出てくるんだなと。。
(引用終了)

また、Closeしたバージョンは非表示にする機能も使い勝手が悪い。
なぜなら、古いバージョンのチケットを探したい利用シーンもあるからだ。

(引用開始)
ただ、終了したチケットを表示させないことについては反対意見もあります。
確かに私も古いバージョンでフィルタすることもありますので納得できる意見です。
(引用終了)

【2】上記の問題点に対し、松谷さんから、下記の運用で回避できないか、という提案がなされている。

(引用開始)
運用対処として考えらえるのは、カスタムクエリの利用です。
よく使うクエリであればカスタムクエリを登録すれば、フィルタで対象バージョンを何度も選択しなくても必要なクエリができますので、
終了したバージョンのカスタムクエリは消す、という運用にすれば、迷わないとおもうのですがいかがでしょうか。
(引用終了)

(引用開始)
もし、何百というバージョンがフィルタに出てくるのを避けたいのであれば、
ある程度まとまった単位でプロジェクトを分けるという案があるかとおもいます。
(引用終了)

綺麗な運用は、Redmineプロジェクトで最初から分割しておく、という手があるだろう。
しかし、当初はそんなに使われると思っていなかったのに、大量にチケットが発行され続けて、後からRedmineプロジェクトに分割したいが、運用が混乱するのでできない、という状況もありうる。
上記のような運用で暫定的にカバーするしか無いだろう。

また、前田剛さん、川端さんから、Redmineの機能改善として下記のような意見が出ている。

(引用開始)
賛成派・反対派の両方を満足させる解決策の一つとして提案されているのが、ドロップダウンリストボックスをバージョンのステータスごとにグループ化して表示する方法です。
(引用終了)

Feature #10412: Target version filter shoud not show closed versions - Redmine

(引用開始)
システム管理のカスタムフィールド設定画面のように「フィルタとして使用」チェックボックスをバージョンの設定画面に作るのもどうなんでしょうかね？
(引用終了)

本来は、Redmineの機能の一部として、フィルタリングする時にバージョンのリストの中身を事前にステータスごとにソートしておいたり、「フィルタとして使用」チェックボックスをバージョン設定画面に用意しておくべきなのだろうと思う。
個人的には、「フィルタとして使用」チェックボックスをバージョン設定画面に用意しておく、という案は良いアイデアだと思う。

【3】いずれの意見ももっともだと思うが、最近感じることがある。

最近、たとえば50個以上の案件で100人以上のユーザがRedmineを使っている例のように、Redmineを大規模運用している場合、Redmineプロジェクトと対象バージョンの使い分けと運用が非常に難しくなっていると感じている。
案件の特徴、チームの特徴、業務の特徴に応じて、Redmineプロジェクトや対象バージョンの意味合いが変わるので、ベストな運用ルールを現場ごとに編み出すのが難しいのだ。

たとえば、一括請負の受託案件以外にも、準委任契約のシステム保守案件もあれば、日々の事務的な処理の案件もあるし、顧客からのサポートデスクの管理もあり、メンバーも、バリバリのIT技術者もいれば、事務員やオペレータ、デザイナーの人もいる。
また、チケットが数百万件以上になったり、チケットの階層構造が深くなったり、プロジェクトの階層構造が深くなったり、対象バージョンが数百件以上になったりする。
そんな場合、小規模プロジェクトで編み出された運用ルールがそのままでは拡張できない。
僕が当初やり始めたアジャイル型チケット駆動開発の運用ルールは、大規模運用の環境ではそのままでは拡張しにくいのだ。

つまり、案件の多様性、業務の多様性をRedmineの機能で吸収する時に、大規模運用の観点からRedmineはまだまだ改良の余地があるのかもしれない。
逆に言えば、Redmineは先進的なプロジェクト管理の実験ツールであるからこそ、このような問題点が具体化されてきたのだ。
従来の古いツールでは見えてこなかった課題が、色んな業務にRedmineを適用することで、具現化されて、Redmineがより進歩するキッカケになるわけだ。

今後も、大規模運用におけるRedmineの機能拡張の課題は考えていく。

【追記】
前田剛さんから下記のフォローがあったのでメモ。

MAEDA, Goさんのツイート: "@akipii バージョンの一覧が長くなる問題はプロジェクトの設定画面のバージョンタブにもあって、この画面ではステータスごとに表示を絞り込む機能を提案中です。 https://t.co/HnA2tKR3Me"

次期バージョン3.4で解決されるらしい。
最近は、こういう細かなユーザインターフェイスの改善が次々にリリースされるので、ユーザにとってはとてもありがたい。
RedmineのVerUpに追随すれば、自然に使い勝手も上がるのだ。

2016年8月のRedmineの機能改善に期待できること: プログラマの思索

2016年7月のRedmine開発状況 | Redmine.JP Blog

2016年8月のRedmine開発状況 | Redmine.JP Blog

「技術的負債だらけのチームで技術マネージメントしてみた」資料が素晴らしい

「技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。

【参考】
akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。＞技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S"

Kichijoji pm7[talk2]技術的負債だらけのチームで技術マネージメントしてみた from Yasukazu Nagatomi

前任の仕事を引き継ぎしたら、下記の問題があったらしい。
技術的負債込みで引き継いでしまった、という例は、本当によくある。

(引用開始)
１年前の状態
・すべてがメールベース
・ドキュメントはほぼ無い
・最強の属人化。個人のパワーで乗り切る
・技術に関心が無く誰も行動しない
・暫定スクリプトが今も元気に本番稼働中
・ソースには、ほぼコメント無し
・hoge.pl.(日付) 形式のソース管理
・チーム共有ライブラリをrequireして使用
(引用終了)

そこから、インフラ担当者を巻き込んだり、開発ツール(Redmine、Git)を普及させたり、社内で勉強会を開いたり、色んな活動をして、技術的負債を少しずつ減らし、チームの雰囲気も変えていった、と。
まさにプロセス改善の活動そのもの。

この資料で共感した部分は「今後に向けて １年でガラッと変えたけど、（本当は半年でやりたかった） 本当に、メンバは幸せなのか？」「今後に向けて このまま進めていって良いのか？ 押し付けになっていないか？」と自問している所だ。

僕自身、Redmineに愛着があるし、GitやJenkins、TestLinkなどのツールを使って、開発プロセスを自分の理想に当てはめてやりたくなる。
しかし、それが本当に良いことなのか？と自問する時がある。

会社や現場の組織構造や雰囲気、チームの成熟度によっては、自分が理想とするチケット駆動開発が適用できない時があり、すごく歯がゆい気持ちになる。

現代のソフトウェア開発の潮流を見れば、Scrumなどのアジャイルな開発スタイルが当たり前なのに、官僚的組織によるプロセスの標準化に偏っている現場に不満があったりする。
今の時代は、少人数のチームでソフトウェアを開発するのが当たり前なのに、一昔前のような組織構成で工程ごとに分断されたチームでまどろっこしい開発スタイルに不満があったりする。
だからと言って、自分の思いを捨てて、現状になびくのが良いとは思わない。
おかしいものはおかしいから。

問題だらけの環境の中で、小さな糸口を見つけて、そこから少しずつ進めていく。
違和感を持ちながらも、その感触は忘れず、かと言って毎回衝突するのでもなく、ちょっとずつ変えていく。
必ず改善できるチャンスはあると思うから。

違和感はなくさず、その違和感の真因を考えて、自分なりの解決策を何度も練り直して持つ。
それが何となく大事な気がする。