Redmine

2018/12/10

チケット駆動開発のアイデアがRedmineへ与えた影響は何か

この記事は Redmine Advent Calendar 2018 の12月25日分です。

Redmine Advent Calendar 2018 - Adventar

チケット駆動開発というアイデアがRedmineに与えた影響を改めて考察してみる。
以下はラフなメモ書き。

【1】チケット駆動開発の発端とは?

Redmineを導入運用する時、「チケット駆動開発」という言葉を使う場面がある。
既に、さかばさんがチケット駆動開発の由来と経緯について書かれている。

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

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

チケット駆動開発の概念は、2007年にTracのチケット管理から生まれた。
その素朴なアイデアは、「チケット無しのソースコミット不可」「No Ticket, No Commit」。

2008年頃、そんなチケット駆動開発のアイデアをRedmineで試してみたら、XPに基づいたアジャイル開発に適用できることに気づいた。
そんな僕の経験を熱く語っていたら、さかばさんが「チケットはXPのタスクカードと同じ」と上手くまとめてくれた。
この言葉がヒントになって、Redmineによるチケット駆動開発を運用した時のPJ管理の技法、チームビルディングの技法に対し、既存の専門知識を片っ端から適用してみた。
たとえば、アジャイル開発、ソフトウェア工学、PMBOK、ITIL、品質管理、など。
そういうアイデアを専門知識で補強することで、より理解が深まる一方、理論はそのまま適用できず、効果を出すには前提条件や制約条件が色々あることにも気づいた。

【2】チケット駆動開発はどのように定義されているのか?

【2-1】Redmineでチケット駆動開発を実践した時のプロセスをフレームワーク化する試みは、下記から始まった。

脱Excel! Redmineでアジャイル開発を楽々管理 (1/5):エンジニアがお薦めする 現場で使えるツール10選(3) - @IT

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

【2-2】チケット駆動開発をアジャイル開発プロセスとみなした時の運用サイクルは以下になる。

1・プロジェクトで発生するタスク、課題、障害は、「XPのタスクカード」とみなし、全てチケット化する(Ticket First)。
チケットは作業指示書であり、課題管理票、障害管理票でもある。

2・それらチケットは、リリースするタイミングで、Redmineのバージョン単位にグループ化する。
Redmineのバージョンは、XPのイテレーション、Scrumのスプリントに相当する(Iteration is a version)。

3・リリースまでのPJ管理は、Redmineの優れたチケット集計機能、構成管理ツール連携機能でリアルタイムにモニタリングすることで実現する。
「No Ticket, No Commit」で、ソース修正履歴は全て、チケットで把握できる。

4・Redmineのバージョンの進捗が100%になったらリリースする。

5・リリース後、チームはふりかえりを行うし、顧客からの改善要望を収集して、次のイテレーション計画へフィードバックして再修正する。

【2-3】上記によって、チケット駆動開発によって明確になったプロジェクト運営のやり方は2つある。

一つは、プロジェクト内で発生するあらゆる作業や課題などをチケットに記録することで、プロジェクト運営はチケットのライフサイクルに置き換えられること。
もう一つは、RedmineバージョンをXPのイテレーション、Scrumのスプリントと同一視することで、Redmineのロードマップ機能は、長期のリリース計画と短期のイテレーション計画に置き換えられること。

つまり、プロジェクト運営の日々の作業は全てチケットでリアルタイムに追跡できるし、それらチケットはRedmineのロードマップ機能など数多くの優れた機能で、プロジェクトの長期の計画づくりにも使えるようになった。
すなわち、チケット駆動開発の概念をRedmineに導入することで、プロジェクト運営の全ての管理プロセスをコントロールできるようになるメリットがある。

【2-4】では、このメリットによって、PJ管理技法がどのように変化するのか。
僕がチケット駆動開発で運用した時に、プロジェクトリーダーとして一番意識したことは「チケットの取捨選択」だった。

プロジェクト運営では、日々数多くのチケットが発生し、計画当初のタスク以外に、納期までに収まらないタスクが発生する。
それらチケットを1つずつ精査し、対策を打ち、1つずつ潰していかなければならない。
見て見ぬふりして放置しても、悪い状況は何も変わらないから。

すると、ガントチャート保守という面倒な作業が必ず発生し、その作業に多大な管理工数を取られて、悪循環に陥る。
一方、チケット駆動開発では、ガントチャートは所詮、1個のビューに過ぎない。
ロードマップ、チケット一覧、カレンダー、かんばん、EVM、リソースヒストグラムなどのビューをチケット集計機能として実現できるし、それらでモニタリングすればよい。
1個のビューにこだわらず、必要な状況で必要なビューを使い、手を打てばよいのだ。

それら機能を使っていくと、バージョン単位にグループ化したチケット群を精査して、優先度の高いチケットから一つずつ潰していくようになる。
もちろん、それらチケットは時々刻々変わるが、Redmineの優れたチケット集計機能で把握できるので、プロジェクトリーダーの意思決定を支援できる。
すると、チケットを分割して次バージョンへ延期したり、捨てる意思決定が多くなると思う。
「直近の納期までに何が必要なのか」をプロジェクトリーダーに徹底的に考えさせる基盤をチケット駆動開発は提供してくれるからだ。

つまり、PJ運営を「チケットの取捨選択」というミクロな意思決定に落とすことが、実はマクロな観点のPJ運営を実現しているわけだ。

【3】チケット駆動開発の具体的な特徴は何か?

チケット駆動開発をRedmineで実装すると、下記の3つの特徴が見えてくる。

チケット駆動開発の戦略: プログラマの思索

【3-1】Redmineの優れた構成管理連携により、要件からソースコードまでのトレーサビリティのインフラが整う。これにより、Redmineは本来の(真の)構成管理ツールとして実現される。

「チケット無しのコミット不可」の運用ルールにより、チケットとソースが密関係で相互リンクされる。
つまり、チケットが作業指示書であれば、チケットを発生させた要件や仕様書からソースやビルドモジュールまで、相互にリンクで遷移でき、追跡可能になる。
よって、要件からビルドモジュールまでのトレーサビリティを理論上は実現できる。

過去のソフトウェア工学の書籍を読むと、トレーサビリティの重要性は謳っているが、その実現方法はExcel台帳でソースやバージョンを管理するなど非常に面倒に思えた。
他方、Redmineであれば、事実上、トレーサビリティを実現できる「真の」インフラになりうる。

また、Redmineはツール連携できるI/Fを持っているので、GitやJenkinsなど数多くのツールと連携すれば、「プロジェクト管理サーバー」なるものを実現できる。
つまり、PMBOKの言う「PMIS(プロジェクト管理システム)」を初めて実現できる。
僕は、PMBOKが目指していたものは、たぶん、こういうインフラが前提であって初めて理解できるのではないか、と思った。

そして、このアイデアは、ソフトウェアプロダクトライン(SPL)にもつながっていく。

さらに、チケット管理システムはソース管理と同じように、作業のUnDo、ReDoを行う為のリポジトリとみなすこともできる。

チケット管理システムは作業の構成管理と同じ: プログラマの思索

【3-2】Redmineの優れたワークフロー管理機能により、プロジェクト管理のフレームワークへ昇華・汎用化できる。

Redmineのワークフロー設定画面が意味するものは、三位一体論だ。
つまり、業務フローというアクティビティ図、ワークフローの状態遷移図、ワークフローの状態遷移表という3つの機能は、Redmineの1つの機能として実現される。

よって、PJ運営に出てくる全ての業務フロー、開発プロセスは、事実上、Redmine上で全て実装できる。
このアイデアにより、Redmineでは、WF型開発も、Agile開発も共存して運用できるメリットが出てくる。
もちろん、PMBOK、ITIL、サポートデスク、会議体管理、PC資産管理など、ソフトウェア開発以外の業務にも適用できるようになる。
ここが、Redmineの運用で一番面白く、そしてホットな部分だろうと思う。

【3-3】チケット集計結果をソフトウェア・リポジトリ・マイニングによって、色んな角度からメトリクスを採取して、プロセス改善の材料にできる。

Redmineに蓄積された過去の大量のチケットは、データマイニングの宝庫だ。
PMOや品質保証部にとって、ソフトウェア工学のメトリクスを実際に研究できる元ネタになりうる。
信頼度成長曲線というメトリクスも、こうやって作るのか、ということも初めて体験できた。

しかし、実際は、チケットの内容が詳細に記載されていないと、なかなか理論通りのメトリクスが得られないことも分かった。
他方、PMBOKのEVMやリソースヒストグラムは、こうやって実装できるのか、ということも体験できた。

チケットと言う一つのデータが蓄積できれば、PJ管理で使われるビューのうち、既存の理論をRedmineで簡単に実装できる。
さらに、Redmineは柔軟でカスタマイズしやすい特徴を活かせば、新たな観点のPJ管理のビューを生み出す可能性があるはずだ。

【4】チケット駆動開発で最も面白い特徴は、「チケットはストックとフローの二重性を持つ」ことだ。

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索


Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索

チケットはタスクカードであるから、フローとして流れる「流通媒体」。
一方、チケットは障害管理票、課題管理票でもあるから、ストックとして蓄積される「記憶媒体」でもある。

この2つの特徴が混在しているので、チケットの粒度を標準ルールでガチガチに定めるのは難しくなる。
なぜなら、流通媒体のチケットは細かくなるし、記憶媒体のチケットはどうしても大きくなりがちだから。

また、1つのチケットという実体は、ステータスが変更されるたびに、流通媒体と記憶媒体に性質が変わる特徴も持つ。
たとえば、タスクのチケットはフローとして流れるが、途中で仕様変更やらソース修正の内容など、ストックの内容が蓄積される。
他方、障害管理票のチケットは、当初は障害内容や対策を詳細に書いてストックとして蓄積されるが、テスターと開発者の間でやり取りする時、チケットはフローとして流れる。
そのおかげで、チケットはキャッチボールのような雰囲気になる。

つまり、チケットは障害や仕様変更の内容をストックして持つ一方、チケットで進捗管理でき、ワークフロー設定に沿って変更管理が自然に行われる。
すなわち、チケットは、データマイニングの元ネタやナレッジ基盤となる「記憶媒体」の側面と、進捗管理や変更管理などを回す「流通媒体」の側面が既に埋め込まれている。
よって、チケットの粒度に悩むよりも、このチケットの二重性を意識して運用したり、その特徴を活かすように知恵を絞る方が良いと思っている。

【5】チケット駆動開発の今後の課題は何か?

課題は3つあると思う。
一つ目は、チケットの粒度、チケットの完了条件について、考え方を整理すること。
チケットの粒度は、ソフトウェアの本質的な複雑性に由来すると考えているので、それを逆手に取って、ソフトウェアの本質をチケット駆動開発で探ることもできるはず。

チケット駆動の罠~複雑さはチケットの粒度に関連している: プログラマの思索

TiDD初心者から必ず聞かれる質問~「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine: プログラマの思索

チケットの粒度と進捗ビューの関係: プログラマの思索

2つ目は、チケット駆動開発で実装できるプロセス基盤の種類を整理し、それらプロセスの特徴・メリット・デメリット・プラクティス・アンチパターンを明確にすること。
たとえば、WF型開発、Agile開発、PMBOK、ITIL、サポートデスク、PC資産管理、など。

Redmineが今後発展する方向のアイデア: プログラマの思索

Redmineが今後発展する方向のアイデアpart2: プログラマの思索

3つ目は、チケット駆動開発と組織の関係を整理し、「組織がチケット駆動開発をどのように複雑化させるのか」「チケット駆動開発は組織にどんなメリットをもたらすのか」を明確にすること。

第15回東京Redmine勉強会の感想~Redmineの2つの顔が相異なる2つのユーザ層を生み出している #redmineT: プログラマの思索

大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響: プログラマの思索

Redmineインスタンスとプロセスの関係~Redmineは組織に従うのか、Redmineに合ったチームを作るべきか: プログラマの思索

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

Redmineは戦略に従う。そして、Redmineは組織に従う~システム運用フローの背後にある組織構造の影: プログラマの思索

Redmineとチケット駆動開発は表裏一体と思っているので、Redmineを使うことで、色んな実験ができると思う。
それらアイデアを試してみたい。


| | コメント (0)

2018/12/06

Redmineの新機能開発チケットの記事のリンク


石川さんが書かれたRedmineの新機能開発チケットの記事がとても参考になるのでリンクしておく。

【参考】
いま注目しているRedmineの新機能開発チケット - ファーエンドテクノロジー株式会社

Redmine Advent Calendar 2018 - Adventar

直近のVer4.0に入っていない機能の紹介でいくつか気になるチケットはある。

【1】「プロジェクト一覧画面の改善」は実現して欲しいチケットだ。

Patch #29482: Query system for Projects page - Redmine

Redmineの運用が長くなると、プロジェクトが100個以上に増殖するので、必要なプロジェクトのみ選定して、その内容を見たい、というニーズが多くなる。
特に、現場マネージャの一つ上の経営者層がRedmine上で、複数の案件を一覧で見たい、というニーズが多い。
上記の改善ができれば、経営者層の不満となるニーズを多少緩和してくれる。

【2】「トラッカーの日本語訳変更」は、議論が活発で読んでいて面白い。

Patch #29045: Change Japanese translation for Tracker - Redmine

Redmine初心者は、トラッカーという言葉に慣れていないので、いつもトラブルの元になりやすい。
一方、「トラッカーをなくすと、Issue Trackingという概念が消えてしまう」という意見も確かに納得する。

Redmineのトラッカーは、ワークフローそのものであり、帳票そのものでもある。
トラッカーという言葉には数多くの意味が込められているので、そのニュアンスを消さずに修正するのは本当に難しい。

Redmineの「トラッカー」を「チケット種別」へ変更するチケットが提案されている: プログラマの思索

【3】「トラッカーの説明を追加する」チケットも確かにその通りだ。

Feature #442: Add a description for trackers - Redmine

Redmineを触ったことがないユーザには、トラッカーの意味を説明した後で、現場で定めたトラッカーという業務のワークフローを説明する場合が多い。
その時に、Redmine上で、このトラッカーはこういう意味で運用しているよ、という説明文があると、ユーザは勝手に参照してくれるので、システム管理者は楽になる。

【4】「プロジェクト毎にデフォルトのカスタムクエリを設定できるようにする」チケットもニーズが多い。

Feature #7360: Issue Custom Query: Default Query - Redmine

朝一番にプロジェクトを開いた時、メンバーに見て欲しいチケット一覧をデフォルトにしたい。
そうすれば、マネージャが逐一指示を出さなくても、メンバーは自身の残チケットに着目して作業し始めるはず。

【5】チケットにタグづけ機能は、ぜひ欲しい機能だ。

Feature #1448: Add tags to issues - Redmine

ハッシュタグのように、#をつけてタグ付けして、そのタイムラインを読むのは今は当たり前。
チケットのフィルタリングとして、カテゴリやバージョン等、数多くの方法はあるが、タグ付け機能があれば、より柔軟にチケットの分別ができるようになる。

【6】上記の記事には記載がなかったけれど、下記の機能改善も期待している。

・「@名前」でリンクする
・WikiからODTファイル出力
・マイページの画面改善
・添付ファイルの全文検索

新たな機能改善がマネージャの潜在ニーズを呼び起こし、新しい運用方法の提案や新たな機能改善につながる、という議論のやり取りが楽しい。
そこがRedmineの一番面白い点。


| | コメント (0)

2018/12/04

2018年もRedmine Advent Calendarをやってます

@yassanの発案で、2018年もRedmine Advent Calendarを今年もやってます。
まだ空きはあるので、ぜひご参加下さい。
@yassan、ありがとうございます。

【参考】
Redmine Advent Calendar 2018 - Adventar

【参考2】
Redmine Advent Calendar 2017 - Qiita

Redmine Advent Calendar jp 2011とRedmine1.3に向けての感想: プログラマの思索

お勧めの記事は、前田剛さんの下記の記事かな。
なぜ、Redmineでは「Issue」を「問題」「課題」と訳さず、「チケット」になったのか、その経緯が書かれている。

Redmineの「Issue」の日本語訳はいかにして「チケット」になったか | Redmine.JP Blog

他のチケット管理ツールでは、「チケット」という言葉ではなく「課題」「問題」と訳されている場合が多い。
しかし、Redmineでは、日本語訳がチケットになったおかげで、「チケット駆動開発」という概念が生まれて、日本特有の普及推進になったのだろうと思う。
僕も以前、色々考えていた。

チケット駆動開発の理想と現実: プログラマの思索

Redmineの背景にある「チケット駆動開発」という概念は結局何なのか、もっと考えてみたいと思っている。

チケット駆動開発の原点の記事のリンク: プログラマの思索

| | コメント (0)

2018/11/11

第15回東京Redmine勉強会の感想~Redmineの2つの顔が相異なる2つのユーザ層を生み出している #redmineT

第15回東京Redmine勉強会が盛況で無事に終わりました。
スタッフ、参加者の皆さん、ありがとうございました。
また、コミッタの前田さん、数多くのプラグイン開発者・パッチ開発者の方にも感謝です。
以下は、講演を聞いて、感想をラフなメモ書き。

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

2018/11/11 第15回勉強会 - redmine.tokyo - Togetter

日本のRedmineコミュニティの活動報告と今後の抱負: プログラマの思索

第15回redmine.tokyo勉強会の見所: プログラマの思索

第15回redmine.tokyo勉強会のLT資料の事前公開~今後のRedmineコミュニティの方向性について: プログラマの思索

Redmineでやってみた - うさぎまんじゅう - BOOTH

【1】参加者の方から、以前の勉強会では講演の数が少なくて、時間を持て余す時が多かったのに、今回の勉強会では講演の数が多すぎて盛りだくさんだった、という感想を聞いた。
確かに、大LT大会になったので、詰め込みすぎたかもしれない。

他方、それだけのコンテンツが集まる事実は、日本のRedmineコミュニティで数多くの事例やカスタマイズのノウハウが蓄積されていることを示しており、コミュニティとして成熟していることかな、と思った。

【2】今回の勉強会のテーマは「Redmineの次バージョン4.0に向けて、皆のノウハウを共有しよう」だったが、隠れたテーマは「日本のプラグイン開発者やコミッタ、パッチ貢献者にコミュニティから感謝の声をあげよう」だったと思う。
@g_maedaさん、@akiko_pusuさん、@tkusukawaさん、@haru_iidaさん、@two_packさん、@onozatyさん、@naitohさん、前田みのるさん他多数のプラグイン開発者に声が届けられて良かったように思う。

中村さんの講演では、現場のRedmineに15個もプラグインを入れていて、プラグイン開発者に拍手喝采を、という内容はまさにそうだった。
Discord上でRedmineコミュニティを運営しているMaxさんの講演も、Redmineのテーマ改善など機能拡張をコミュニティドリブンで開発しよう、という内容だった。

そして、僕のLTでは、Redmineコミュニティがマネージャ層とRuby開発者という二つの全く異質なターゲットから成り立っている特徴を強みとみなし、異質な特徴を持つ彼らが相互交流することで、Redmineの進化を加速させるエンジンになりうるはず、という主張を試みた。

実際、今日の参加者とグループディスカッションや懇親会で話を聞くと、マネージャ層の人達もいれば、プラグインやパッチ等の開発者も多く、多様な参加者から成り立っていた。
たぶん、こういう交差しないセグメントのターゲットが2つ以上もあるようなコミュニティは、非常に稀で、貴重な場ではないか、と思う。

普通のOSSコミュニティは、利用ユーザだけとか、実際の開発コミュニティとか、セグメントがどこかに特定されているような気がする。

【3】では、なぜ、Redmineコミュニティはそのような異質なセグメントのターゲットを2つ以上持つことができたのか?

理由は、Redmineには2つの顔があるからだ。
一つは、「ソフトウェア工学の理論を実験できるプロジェクト管理ツール」という側面で、マネージャ層に対応する。
もう一つは、「汎用的なプロジェクト管理の開発基盤」という側面で、こちらがプラグイン開発者やRuby開発者に相当する。
つまり、全く異なる出身を持つ二つの層が生まれたことで、Redmineの機能改善を相互に議論しあえる場が生まれたように思っている。

たとえば、マネージャ層は、自分達の管理作業を楽にしたいためにRedmineを使うが、Rubyの開発はおそらく殆どの人ができない。
一方、プラグイン開発者は、実際の現場のニーズを元にRedmineに不足した機能を実装し、プロセス改善に役立てる。

Ruby開発者は、マネージャを顧客に見立てて、Redmineに不足した機能を実現できる力を持つ。
一方、マネージャは、プラグインを利用することで、自分達の開発プロセスや組織文化に合わせてRedmineにカスタマイズを施し、彼らのあるべき姿にRedmineをFitさせる。
たぶん、新たなプラグインがマネージャ層の潜在ニーズを刺激し、新たな改善アイデアを生み出すだろう。

実際、今日のLTでもリソース予約プラグインを開発した話があり、タスク管理に使われるRedmineを会議予約システムとみなして使う、という事例もあった。
つまり、柔軟なRedmineのおかげで、マネージャや利用ユーザの潜在ニースが刺激され、数多くのアイデアが生まれる、という良い意味でのらせん構造が生まれている。

【4】すると、今後のRedmineコミュニティの発展に必要な要素は2つあると思う。
一つは、Ruby開発者をRedmineコミュニティにもっと巻き込みたい、ということ。

なぜなら、他の競合のチケット管理ツールに対し、Redmineが競争優位性を保つには、もっとRedmineの進化の速度を上げたいからだ。
現状のRedmineには、いくつかの課題があると思う。

僕が感じている課題については、以前書いた。

Redmineの直近の課題~競合ツールGitlabに対抗できるか: プログラマの思索

また、Maxさんも同じく、Redmineの画面UIをもっと今風に改善したい、と思われている。

換言すれば、次の3つに課題が集約されるのではないか。

1・シングルページアプリケーション化などの画面UIの改善
2・プルリク実装などのGit連携の機能強化
3・プラグインのGem化、RedmineのVerUpの自動化などの、VerUp自動更新機能

おそらくそれらの課題の解決は、そう簡単なものではない。
だが、多くのRuby開発者をRedmineコミュニティに巻き込めば、実現のハードルは下がるだろう、と思う。

Redmineのマイクロコア化は可能か~Redmineを開発基盤にして追加機能は着脱可能コンポーネントにできるか: プログラマの思索

【5】もう一つは、Redmine運用に関する数多くの知見を一つの体系にまとめ上げて、誰もが再利用できるようなプラクティスや知識を提供すること。

なぜなら、大阪や東京のRedmine勉強会で参加者から要望されるニーズは、Redmineの運用事例が知りたい、という内容が多いからだ。

実際、Redmineが生まれて10年以上経った今、障害管理だけでなく、タスク管理、会議の管理、資産管理、ヘルプデスクなど数多くの事例がRedmineで実現されている。

たとえば、今日のグループディスカッションでは、ITILのプロセスをRedmineで完全に実装した事例を持つ参加者がいた。
具体的には、Zabbixで検知したエラーメールはRedmineにチケットで自動登録され、インシデントとして認識される。それらチケットを精査して、修正対応すべきと判断されたチケットは、問題管理へエスカレーションされ、対応策の検討後、リリース管理で開発・リリースされる、という流れ。
つまり、この参加者の方は、システム保守・運用の立場の人なのだろう。

この話は僕も以前経験していて、ITILとRedmineは非常に相性が良いと思っている。
しかし、インシデント管理・問題管理・リリース管理などの各プロセスをRedmineにどのようにFitさせるか、については、運用してみると理論通りにうまく行かない部分がある、というのも経験している。

TiDDにITILの概念を持ち込む: プログラマの思索

Redmine for ITIL: プログラマの思索

残業申請ワークフローやITIL運用プロセスをRedmineで実現した事例の記事: プログラマの思索

エスカレーションをRedmineで運用する方法: プログラマの思索

そういうアンチパターンやプラクティスなどのノウハウを、利用シーンごとにまとめて、体系化してみたい。
おそらく、そういう知見を集めて体系化して、その知識を普及させる役割が、Redmineエバンジェリストであり、Redmine警察に相当する人達だろうと思う。

【6】今日の勉強会の中で、ツイートしながら生み出せた考え方は、「Redmine運用の4原則」のようなものがあるのではないか、ということ。
Redmine運用の4原則とは、Redmineがチームに馴染むには、プロセス・ツール・スキル・マインドの4つの要素がいるのではないか、ということ。

この考え方の発端は、Jiraのような多機能なチケット管理ツールの場合、プロセスを実装した経験がない管理者がJiraを使って運用させようとすると、失敗しやすいのでは、という話から生まれた。

ツールを使いこなすには、プロセスを知っておくことが大前提。
そして、ツールを使いこなしたり、プロセスをテーラリングできるスキルも重要。
また、プロセスやツールを受け入れるマインドもいるね、と話が広がった。

しかし、本当にこの4つで十分なのか、MECEに整合性が取れているのか、この4原則でアンチパターンの事象を演繹的に説明できるか、については検証が必要、と思っている。
でも、この4原則を検証してみるのは価値がある、と思う。

【7】最近の僕が個人的に持っているRedmineのテーマは「組織とRedmineは相互にどんな影響を与えているか」だ。

具体的には、組織構造がRedmineにどんな影響を与えて、Redmineをどんな方向に複雑化させるのか。
一方、Redmineを導入し運用することで、組織文化にどんな影響を与えて、組織にどんなメリットを与えてくれるのか。

例えば、縦割りのガチガチの組織構造は、単一の標準Redmineのワークフロー設定、トラッカー設定を複雑化させる。
その複雑化に現場が対応できなくなると、各事業部や各チームごとにRedmineインスタンスが乱立し、野良Redmineが生まれ、IT統制が効かない状態になりうる。
つまり、組織のやり方にRedmineをカスタマイズしてフィットさせて、プロセスをテーラリングしたいが、実際は理論通りにテーラリングはうまくいかない場合が多い。

一方、縦割りの組織にRedmineを導入すると、Redmineの機能に埋め込まれたベストプラクティスをメンバーが自然に受け入れることで、チームの作業が効率化されることもあるだろう。
また、Redmineがメンバー間のコミュニケーションを活発化させ、より良いプロセス改善がもっとできるのでは、というメンバーの貢献意欲を引き出す場面もあるだろう。
つまり、Redmineはチームの文化を変容させる力を持っている。

そんな経験を踏まえて、「Redmineは組織構造に従う」「Redmineは新たな組織文化を生み出す」という二つの双方向な事象を整理したいと思っている。
実際、Redmineを利用しているマネージャは大企業の方が多いので、組織構造や組織文化とRedmineのバランスを見出すことに苦労しているのではないか、と思うからだ。

Redmineは戦略に従う。そして、Redmineは組織に従う~システム運用フローの背後にある組織構造の影: プログラマの思索

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響: プログラマの思索

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

Redmineインスタンスとプロセスの関係~Redmineは組織に従うのか、Redmineに合ったチームを作るべきか: プログラマの思索

グループディスカッションでも、懇親会でも、参加者が持つRedmine運用の問題意識にはこれらが関係しているような気がした。

以前「Redmineによるタスクマネジメント実践技法」で当時の自分が考えていたアイデアは全て書いたけれど、上記のテーマでまた新たに書いてきたくなるなあ、と思った。

| | コメント (0)

2018/11/09

第15回redmine.tokyo勉強会のLT資料の事前公開~今後のRedmineコミュニティの方向性について

第15回redmine.tokyo勉強会のLT資料を事前公開しておく。

【参考】
日本のRedmineコミュニティの活動報告と今後の抱負: プログラマの思索

第15回redmine.tokyo勉強会の見所: プログラマの思索

第15回勉強会 - redmine.tokyo

【1】Redmineには2つの顔がある。

一つは、ソフトウェア工学の理論を実験できるメトリクス収集集計基盤/開発プロセスの運用基盤である顔。
Agile開発もWF型開発も運用可能であり、ワークフロー設定できるならば、全ての開発プロセスをRedmineで一元管理できる。
そこから、Redmineは開発プロセスの運用基盤になり、ソフトウェア工学やプロジェクト管理に関するメトリクス収集・集計基盤になりうる。
つまり、定量的なプロジェクト管理の手段をRedmineによってようやく手に入れられることになる。

もう一つは、汎用的なプロジェクト管理ツールの開発基盤である顔。
RubyとRailsの基盤のおかげで、機能のカスタマイズがやりやすい。
REST APIやrakeなどの外部接続I/Fもあるので、システム連携もやりやすい。

そのおかげで、Redmineに不足する機能をプラグインで実現できるので、プラグイン開発者が多い。
特に日本では、ガチガチの縦割りの組織や自社の開発プロセスに合うように、Redmineをカスタマイズしやすいので、ニーズが多い。

また、Redmineが柔軟な開発基盤を持つおかげで、Redmineコミュニティ自体が活発化している事象もある。
柔軟なソフトウェア設計は、OSSコミュニティを活発化させるメリットがある。
他方、OSSコミュニティの活発化は、ソフトウェアをさらに進化させる、という双方向のメリットがある。
その考察は以下に書いた。

柔軟なソフトウェア設計はOSSコミュニティを活発化させる~OSSソフトウェアとOSSコミュニティの密接な関係: プログラマの思索

【2】言いたいことは2つ。

Redmineコミュニティの参加者の多様化を図ること。
もう一つは、Redmineのエコシステムを作ること。

Redmineコミュニティの参加者層は2種類あると思う。
一つは、プロジェクトマネージャなどのマネージャ層。
もう一つは、プラグイン開発者などのRuby開発者層。

つまり、プロジェクトマネージャかつRuby開発者である層は非常に少ないだろうから、コミュニティで相互の交流を図ることで、斬新なアイデアが出てきて、Redmineを更に進化させる余地がたくさんあるだろう。

マネージャのニーズはRuby開発者にとって、新たなプログラミング体験のチャンス。
Ruby開発者が提供するRedmineの新機能やプラグインは、マネージャのニーズをさらに刺激して、より良いものへ発展させるだろう。

その場合、Redmineベンダーも実はコミュニティのステークホルダーの一人なのだ。
彼らも有償ツールではあるが、Redmineのマーケット拡大に寄与している部分がある。
最終的には、彼らも含めて、Redmineコミュニティが熱気を維持し続ける方向へ持っていきたい。

そういう活発な議論を提供する場をコミュニティで実現したいと思う。

| | コメント (0)

2018/10/30

第15回redmine.tokyo勉強会の見所

第15回redmine.tokyo勉強会の見所をラフなメモ。

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

第15回redmine.tokyo勉強会 - connpass

第15回redmine.tokyoの見所 マドびっ! Madosan's View

(引用開始)
redmine.tokyo の第15回勉強会を開催します。 今回のテーマは『出るぞ4.0!Redmineの活用ノウハウをみんなで共有しよう!』です。

昨年のメジャーバージョンのリリースから1年経ち、今年末頃にVer4.0がそろそろリリースされるようです。 そこで、次期バージョン4.0のリリース前祝いとして、Redmineの活用事例やより良い使い方のノウハウに関する勉強会を行います。

具体的には下記になります。

・次期バージョン4.0の機能紹介
・Redmineを利用する組織能力向上の事例
・RedmineとJiraの機能比較に関する事例
・LT枠を大幅増枠して、Redmine活用ノウハウに関する「大LT大会」

グループディスカッションでは、Redmineの初心者も気軽に質問できたり、Redmine経験者の経験談を共有できる場を設けます。 是非、参加者同士で、Redmineの疑問点を質問したり、運用ノウハウや技術ノウハウを共有してみて下さい。
(引用終了)

【1】勉強会の内容は、講演者5名、LT10本(増えるかも?)なので、Tipsやアンチパターン、運用事例、最新機能紹介など幅広くなった。
最近は参加者が多いので、多様なユーザのニーズに答えられるだろうと思う。

個人的に興味があるのは、いくつかある。

【2】@onozatyさんの講演「View customize 1.2.0 の紹介」では、ViewCustomizeプラグインのカスタマイズ事例が説明される。
Redmineの画面UIを即座にカスタマイズしたい時、ViewCustomizeプラグインは必須なので、いろんな利用事例がユーザ同士で共有されるといいな、と思う。
ちょっとした画面UIの改善は、特に、Redmine導入時や、運用の推進に大変役立つから。

【3】@MadoWindaheadさんの講演「redmine導入における効果的なヒント 組織の成長と難敵に対応する作戦と特技ついて」は、「Sqip2018 チームビルディングにおける心理的障壁の傾向と緩和策の提案」の改訂版と聞いている。

asakoyanukiさんはSEPGで標準化を推進する立場として、たぶんたくさんの苦労されていると想像する。

(引用開始)
Redmine.tokyo勉強会で行われるグループディスカッションでは、参加者同士が 現場での問題や悩みごとを話し合う。
⇒ Redmineの利用の仕方よりチームビルディングに問題あり
A:チームの成熟度の問題 B:上司が問題 C:ツールリテラシーの低さ など
⇒Redmineの利用の仕方よりチームビルディングに問題あり
(引用終了)

上記の資料を読むと、Redmineの利用推進よりも、チームビルディングに問題があった、という指摘が非常に面白いと思った。
組織構造や個人の能力が問題ではなく、チームの成熟度に真因があったわけだ。
おそらく、現場の問題がたくさんあって、Redmineを上手く使えば、それら問題はある程度解決できるはずなのだが、チームとして未成熟なため、なかなか運用が根付かない、という状況があるのだろうと推測する。
そういう問題を、チームの成熟度のレベルに合わせて、解決方法を変えて実施する、という話なのだろう、と思う。

そういう話を聞くと、リーダーシップのSL理論(状況対応型リーダーシップ)を連想させる。

SL理論 ? リーダーシップインサイト

リーダーシップのSL理論とは

つまり、プロジェクトリーダーはメンバーの成熟度に応じて、リーダーシップの発揮方法を変えるべきである、という古典的理論。
おそらく、Redmine運用の方法も、チームの成熟度に合わせて、指示的→コーチング→支援→権限委譲のようにかわっていく、いやむしろ、変えていくべき、という発想になると思っている。

【4】@forenoonMさんの「Redmine使いが注目したJIRAの機能」も興味がある。
「Redmine使いが業務でJIRAを使って注目した機能を紹介します。」という紹介がすごく興味がある。

世界的にはRedmineよりもJiraの方が有名だし、有償ツールのため、機能も豊富。
しかし、僕自身としては、RedmineにはOSSだからこそのメリットが多々あると思っている。
日本でRedmineが広がっている理由には、ネット上に数多くの情報があり、ユーザコミュニティが活発であることもあると思う。

その場合、他のチケット管理ツールのベストプラクティスやTipsをRedmineにも横展開できるはずだし、Redmineの使い方をより進化させてくれるはず。
そんな事例かな、と思っている。

【5】他にもたくさんのLTがあるので楽しみ。

なお、最後に僕もちょっとだけLTさせてもらう予定。
Redmineコミュニティを通じて、僕も、オープンソースとの関わり方、コミュニティを持続させていくのに必要な心構え、などをたくさん経験させてもらった。
そこで、東京と大阪のRedmineコミュニティに携わる一スタッフとして、今後のコミュニティはどうあるべきか、私見を述べてみたいと思った。

| | コメント (0)

2018/10/22

Redmineのバージョン機能に別の意味を与える改善に関するアイデア~バージョン機能はリズムという恩恵を利用者にもたらす

Redmineのバージョン機能に別の意味を与える改善チケットが起票されていた。
以下、ラフなメモ書き。

【参考】
機能#17907:バージョンに別の意味を与える - Redmine

(Google翻訳開始)
Redmineはプロジェクト管理に適しています。しかし、実際のソフトウェア開発だけでなく、だから、バージョンはソフトウェア開発プロジェクトではあまり意味がありません。

私の提案:バージョンがバージョンかマイルストーン、ターゲット、フェーズ、ステージなどであるかどうかをユーザーに選択させる。

実現は非常に簡単です。'バージョン'のタイプを指定する別のフィールドを追加するだけです。ユーザーがドロップダウンで選択する必要のあるバージョンを作成する場合は、そのタイプを選択します。理想的には、いくつかのアイコンを追加して、ロードマップなどのバージョンタイプを視覚化することができます。

さらなる開発では、バージョンタイプを構成可能にすることができます。しかし、これは私の場合はそれほど重要ではありません。私は人がバージョンを使うのが好きではないことに気付くだけです。これがちょうど別の名前を持つことができるのであれば、はるかに明確になります。
(翻訳終了)

【1】僕にとって、Trac、Mantis、Jiraなどの他のITSの運用では分からず、Redmineを運用して初めて理解できた機能が「バージョン」だった。
つまり、Redmineの「バージョン」をXPのイテレーション、Scrumのスプリントとして扱う事で、タイムボックス的なアジャイル開発プロセスを簡単にRedmine上で実装できる。

脱Excel! Redmineでアジャイル開発を楽々管理 (1/5):エンジニアがお薦めする 現場で使えるツール10選(3) - @IT

しかし、この事実に気づいて運用して以来、10年も経つと、もっと色々考えたくなる。

【2】上記の改善チケットでは、「バージョン」の名称をユーザが選択できる機能を追加することを提案している。
理由は、ソフトウェア開発以外の場面で、タイムボックス的なプロセスを実現したいからだ。

僕自身は、ソフトウェア開発では、バージョンとマイルストーンは一致させる運用で良いと思う。
開発チームは、本番リリースの運用サイクルを起点とし、本番リリースのサイクルを自分たちの開発リズムとして捉えれば良い。
なぜなら、ソフトウェアにとって本番リリースすることが、顧客にビジネス上の価値をもたらし、開発チームに売上をもたらすので、本番リリースのタイミングを「バージョン」として名付けて、その開発リズムを大切にすることが重要だからだ。

むしろそれ以外の、たとえば、上司への月次の定期報告のようなマイルストーンは不要だと思っている。
本番リリースに直結しない報告タイミングなど、タイムボックスとして無意味だからだ。

【3】一方、ソフトウェア開発以外の利用シーンでは、バージョンという言葉が適合しにくい場面があるのは確かだ。

たとえば、「入門Redmine」に掲載されている事例として、毎年の農業の作業履歴をチケットとして記録し、四季や月ごとにバージョンを設定している事例があった。
すなわち、農業の「タイムボックス」は四季や月が相当するわけだ。
同様に、その他の業務でも、「タイムボックス」を表す名称として、マイルストーン、フェーズ、ステージなどの言葉の方がしっくり来る時もあるだろう。
そうであれば、ja.ymlで「バージョン」に該当する文言は、各業務のタイムボックスを表す名称に一括置換した方が、ユーザフレンドリーになるだろう。

【4】僕は、Redmineのようなチケット管理システムでは、「バージョン」という機能は単なるチケットを分類する機能ではなく、チケットにタグ付けする機能でもない、と思う。

チケット管理システムの「バージョン」は、利用者にチケット運用の「リズム」という恩恵をもたらす。
そのリズムがあるからこそ、チケット運用はスムーズに流れるし、そのリズムが心地よいと感じる。
そのリズムが生まれる背後には、タイムボックスという概念が隠れているからだ。

チケット駆動開発のモチーフ: プログラマの思索

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

[TiDD] 出版裏話1:没になった原稿 - なぜ「チケット駆動開発」と呼ぶのか -: ソフトウェアさかば

(引用開始)
実際、あきぴーさんとSPESの論文を書く際には「チケット駆動開発」以外の名前を検討するべく提案しました。

しかし、あきぴーさんの答えは明確で「チケット駆動開発」は譲れないとのこと。当時は、しぶしぶながら承諾しましたが、この理由は、のちに私がチケット駆動開発を実践してみて、ようやく分かたのでした。それは

  チケットがプロジェクトをテンポ良く推進してくれる

ということです。本の中では「リズム」と言う表現をしていますが、チケット駆動開発を実践していると、

 朝:チケット一覧を見て、作業計画を立てる
 昼:チケットの作業を順にこなしていく
 夕:チケットの進捗を登録する(完了チケットのクローズ)

という、開発パターンに体がなじんで、プロジェクトがリズミカルに進んでいきます。これは、体験してみないと分からない感覚でした(もし、チケット駆動開発を実践しているのに感じられないなら、備忘録のような細かなチケットをもっと発行してみてください)。

この「リズム」を感じる個人のプロセスは、チケット駆動開発のアジリティとも関係する大切なものです。ぜひ、チケット駆動開発を実践して体験してみてください。
(引用終了)

一方、そういうリズムが感じられないチケット管理システムは、単なる強制ツールに過ぎない。
タイムボックスという概念のないRedmineは、運用していてもたぶん楽しくないだろう。

上記の改善チケットが生まれる背後には、Redmineの利用シーンがソフトウェア開発以外にも広がっている事実が世界中で発生していることを示唆していると思う。
ソフトウェア開発以外で、そういうリズムが感じられるRedmineの利用事例も集めてみたいと思う。

| | コメント (0)

2018/09/25

Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る

Redmineのチケット駆動開発の面白さは、最初は課題チケットでしかなかったのに、いつの間にか作業チケットに変わった、というように、チケットにストックとフローの二重性を持たせて、チケットに複数の意味を持たせている点にあると思う。
以下、ラフなメモ書き。

【参考】
Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索

チケット管理システムは作業の構成管理と同じ: プログラマの思索

【1】以前、下記のツイートがあった。
最初はRedmineでチケット管理して上手く回っていたのに、ガントチャートで厳しく管理し始めたら、内容が空っぽのチケットが大量発生して、チケット駆動でなくなった、というアンチパターン。

【1-1】
akipiiさんのツイート: "ガントチャートはもう時代遅れなのかな?RT @kabukawa: Redmineはチケットからガントチャートが自動で作られて便利なんだけど、ガントチャートを目的に導入すると、Excelより入力が面倒で使わなくなるか、設計とか実装ってタイトルの中身が空のチケットか沢山できて、時々脱力する。"

門屋浩文@redmineeva☀️さんのツイート: "個人的には品質状態(中身)が見えないガントチャートは時代遅れだと思いますよ ごまかせるもの… "

あさこ@センチちうさんのツイート: "ガントはあくまでも、参照かなー。 誰がなんのために見るか、使うかを区別しないと手段が目的になってしまう。 時代遅れとかではなく、手段の違いだと思います。 ガントで見ることができるものをちゃんと区別していないと、ごまかしとかが生まれてくる。見るべきものを適切なもので。… https://t.co/aw4zR2QAQw"

門屋浩文@redmineeva☀️さんのツイート: "目的を理解して使ってる人 ほとんど見たことないよ(疲れていてネガティブです) うーん、見たことあるかなあ? 俺はWBS辞書 つまりチケット一覧をソートして見る派なので 期間にかかる工数も成果物の精度も見ないで何がわかるのかわからないから パッとみで安心したって意味ないもの… https://t.co/AAWOZvyaXo"

昌。さんのツイート: "まどさんがネガティブ!いかんですな。確かにぱっと見安心する使い方してる人たちいますけども。 私は最アジャイルさんのLycheeのおかげでRedmaineにおけるスケジュール見える化はプロセスわからない派にも使えるかもと思うことができましたさ。… https://t.co/4uE4LNBrDL"

門屋浩文@redmineeva☀️さんのツイート: "ネガティブ続きですが、、、ガントチャートが問題の早期発見や解決につながってないんじゃないかなと感じてるから時代遅れと言った 把握してる人に責任押し付けたって誰も幸せにならんから ガントチャートのみ見て改善につなげられる凄腕なら別だが 時系列で5つ並べてみたら気が付けるかなあ俺… https://t.co/fPxjDRBRLu"

あさこ@センチちうさんのツイート: "ガントだけだと、早期発見なんてほぼできないよね。その目的で使うならば間違いなく、「それじゃないっすよ」と答えるかなー。 ガントの強みってなんだろうねー。 タスク同士の流れとか、いつまでに何が終わるのか、どのくらい終わってるのかを見るだけのツールとして今は使っているかも。… https://t.co/xSecapQWwY"

昌。さんのツイート: "ガントに限ったことではありませんが、ツールに対してこれダメ!ってなる人は弊社の場合は大体が目的見失ってるかツールに夢見てるひとですかね。あなたが使ったようにしか使えませんよー、ってなる。… "

やっさん🍶さんのツイート: "管理者より担当者視点だと (関連あれば)チケットを前後で関連付けちゃうので、前後の関係とか、並列度とかを見るくらいですね。ガントチャートの利用って。… "

akipiiさんのツイート: "ガントチャートはメーカーの製造工程や発注作業の管理に向いていて、ソフトウェア開発のように、作業が不明確で、担当者がコロコロ変わり、管理単位が1日未満で粒度が小さい場合は向いてない。所詮、ガントチャートはマネージャがプロジェクト管理で使うビューの一つに過ぎないと思う。… https://t.co/wc6TLz0MKc"

【1-2】akipiiさんのツイート: "知りたい。RT @g_maeda: Redmineのガントチャート、実は社内では全く使ってない。ガントチャート機能を使ってる組織ってどのくらいの割合なんだろう。"

あさこ@センチちうさんのツイート: "うちは、お偉いさんたちが、プロジェクトのMilestoneとガントチャート、リスク管理表と合わせて見るということをしてくれています。 Milestoneに対してどうか、間に合うか、作業的にリスクがあるかという観点で使ってますね。 ガントチャート一本で何かを見るということは難しい…… https://t.co/uuNqP8gYWb"

あさこ@センチちうさんのツイート: "多分、そのリソースやスケジュール確認するのも、目的が合って、そこにたどり着くまでの一つのプロセスになってますよね、ガントチャート。 なので、みたい観点もある、って感じですかね?… "

昌。さんのツイート: "です。>みたい観点 個人的にしっかりプロセスてか目的に沿ってチケット運用してる限りタブ切り替えるだけで自分やメンバーのタスクが見える化されてるから便利〜なので、とりあえず朝イチとか進捗確認時に眺めたり確認したりな感じです。… https://t.co/pcMefEEx29"

【1-3】akipiiさんのツイート: "第3回 Lychee Redmineユーザ会 - connpass https://t.co/5O2rOzCMxx 「Redmine + Lychee導入のアンチパターン」の講演は、チケット管理が回っていたのに、Lycheeガントチャートを使いだしたら、空っぽのチケットが増えてチケット駆動でなくなった、というアンチパターンだろうか?笑"

【1-4】akipiiさんのツイート: "読み返したら、当初の目的が忘れられて、手段が目的化してしまった、という症状に思えてきました。チケット管理がうまく回っていたのに、ガントチャートの監視を厳しくしたら、チケットの中身よりチケットの進捗率が重要になって、チケットが忘れ去られた、みたいなイメージ。… https://t.co/u1P1tcsDZB"

りょうまさんのツイート: "そうですね。私はガントチャートは進捗の俯瞰とインデックスだと捉えてるので、その奥に詳細があるのが当たり前だと思い込んでいました。… "

昌。さんのツイート: "ひとは簡単に目的と手段が逆転しがちなので気をつけねばいけませんね。いつも、目的はなんだ?と自分にも問いかけるようにしてます。… "

【1-5】その真因は、本来のチケットは、プロジェクトで発生する変更要求、課題、作業、障害など、プロジェクトで管理すべき対象全てが起票されるはずなのに、進捗管理だけの側面だけ重視されてしまい、チケットの2重性がなくなって、スカスカの空っぽのチケットになってしまった、ということだと思う。

つまり、本来のチケットは、課題の検討履歴、変更要求の作業履歴というストックの側面を持ち、かつ、チケットの納期や作業進捗も合わせて管理できると言うフローの側面も持ち、2重性があったのに、担当者の作業進捗だけ気にするようになってしまい、フローの側面だけ残り、ストックの側面がなくなってしまった、というアンチパターンが発生したわけだ。

【2】以前、ISO9001のQMSの運用の現場を見た時、変更要求や変更管理に関するExcelの作業依頼書と、設計書やリリース手順書などのExcelドキュメントの2種類のExcel帳票が管理されていた。
その運用は非常に煩雑で、最新版のドキュメントが連携されなかったり、リリース漏れが発生したり、非常に手間がかかっていた。
今どき、Excel帳票で管理する現場はありえないと思うが、古い製造業ほど、Excel帳票がはびこっている。

チケット管理システムは作業の構成管理と同じ: プログラマの思索

その原因も上記と同じ。
つまり、ISO9001で実現する時、Redmineでチケット管理せず、Excel帳票で管理する場合、作業依頼書という変更管理に関するフローの側面と、設計書やリリース手順書などの構成管理対象になるストックの側面は、2つのExcel帳票に必ず分かれる。
そして、その2種類のExcel帳票を常に最新化しながら、申請承認フローに沿って厳密に管理せねばならない。

【3】では、なぜ、Excel帳票の運用は必ず失敗するのか?

【3-1】なぜなら、昨今のように経営環境がすぐに大きく変化する場合、Excel帳票で逐一管理する運用は、その変化についていけないからだ。
変更管理の運用と構成管理の運用はシステム開発ではとても重要だが、2種類のExcel帳票で管理するのは煩雑すぎて、現実として運用できないだろう。

結局、Redmineのようなチケット管理ツールで、フローの側面であるワークフロー管理と、構成管理の側面であるソース管理連携機能の双方を実現しなければ、経営環境の変化のスピードにシステム開発そのものが付いていけいないだろう。

例えば、最初は課題チケットで起票したが、課題に対して複数の代替案を出して検討し、一つの解決案を決定した履歴を残す。
さらに、その対策の作業状況も履歴として残し、課題が解決されるまで、チケットに全ての情報が残す。
すると、そのチケットのステータスが変わるたびに、裏では、その時々の意思決定の状況が管理され、マネージャによる承認プロセスを経て、システムに反映されてリリースされていく。

例えば、最初は顧客からの変更要求の仕様変更チケットで起票したが、その変更要求の発端を記録しておく。
また、チームでそのアーキテクチャや実現方法を検討した経緯を記録しておく。
すると、そのチケットのステータスが変わるたびに、裏では、担当者の作業状態が管理され、マネージャや利害関係者の承認プロセスを経て、システムに反映されてリリースされていく。

つまり、当初は課題チケットや変更要求チケットだったのに、チケットが更新されるたびに、作業チケットの意味合いに変わり、チケットが進捗管理対象になる。
さらに、チケットが更新されるたびに、変更管理の承認プロセスの意味も込められて、チケットが変更管理対象にもなる。

すなわち、チケットはストックとフローという2重性の性質が一つの実体として実現されている。
チケット管理では、ストックとフローという2重性の性質を、マネージャやメンバーが深く意識しなくても運用できるような仕組みを提供しているわけだ。

【3-2】本来あるべき姿のチケット管理では、チケットに変更管理や進捗管理というフローの側面と、成果物の構成管理や課題や作業の履歴管理というストックの側面を故意に持たせることで、スムーズに運用させる。

一方、Excel帳票でそれらを管理しようとすると、フローの側面のExcel帳票と、ストックの側面のExcel帳票の2種類に必ず分かれてしまう。
なぜなら、ステータスだけ管理したいExcel帳票と、リリース対象の成果物として厳格に構成管理したいExcel帳票は、管理方法が大きく異なるので、具体的な実体として分けざるを得ないからだ。

すなわち、Redmineのチケット駆動開発は、2種類のExcel帳票の具体的な実体が1つのチケットに合体されている。
そういう背景を、チケット駆動で運用している人は、意識しているだろうか?

【3-3】Redmineでのチケット駆動開発では、メンバーはストックの側面のチケット管理を意識しているが、その背後では、変更に関する申請承認という変更管理、そして、進捗の作業状況の把握という進捗管理、というフローの側面も裏で持たせている。

2種類のExcel帳票で分けて二重管理している運用が、チケット管理では、チケットという1つの実体で管理できるので、非常に運用しやすくなる。

よって、Redmineのチケット駆動開発ではチケットに複数の意味を持たせて運用した方が上手く回る、と僕は思う。

【4】僕の経験上、メンバーはストックの面だけ意識してもらえばよく、フローの側面はそんなに気にしない方が、チケット管理は上手く回ると思う。
もちろん、変更管理や進捗管理は重要だが、その意識が強すぎると、チケットのライフサイクルが長くなり、チケット駆動のメリットが薄れるから。

チケットに対するフローの側面を意識し始めると、ストックの側面を忘れてしまう。
チケットのストックの側面こそが重要なのに、その部分が軽視された運用になってしまうのだ。
ガントチャート重視のチケット駆動開発が、空っぽのチケットを大量発生させるアンチパターンはまさにそれだ。

一方、ストックの側面ばかり強調すると、チケット入力の運用のコストが上がってしまう。
チケットは手軽に起票して、記録して欲しいのに。
誰も更新しなくなるRedmineは、ゴミ箱と同じ。

だから、チケット管理の運用では、フローの側面を強調しすぎると空っぽのチケットが増えて破綻するし、ストックの側面を強調しすぎると、誰もチケットに起票しなくなって破綻する。

チケットの2重性という奇妙な性質を活かすには、そのバランスが重要だ。
フローの側面だけ、ストックの側面だけ、という運用では、チケット駆動のあるべき姿を実現できないし、チケット駆動の効果が得られない。

そのバランスを維持するための運用ノウハウは、実は数多くの現場で暗黙知となっていると思うので、収集してみたいと思っている。

| | コメント (0)

2018/08/28

Redmineにタグ機能を追加するパッチが投稿された

昨日、Marius BALTEANUさんがRedmine本家にタグ機能のパッチを投稿された。
次期Ver4.0で実現できたら、Redmineをより使いやすくしてくれるだろう、と期待している。
ラフなメモ書き。

【参考】
Feature #1448: Add tags to issues - Redmine

【1】なぜ、タグ機能が重要なのか?
それは、GitHub、Gitlab、Jiraなどの他のツールを見ればよく分かる。
Twitterのハッシュタグのように、「#○○○」を書けば、勝手にリンクできて、カテゴライズ化できる。
しかも、情報を探したい時に、タグで探しやすくなる。

(自動翻訳の引用開始)
私たちの問題の多くは複数のカテゴリにまたがっています。具体的には、単にカテゴリ以外のものよりも柔軟性のあるものを検索して管理したいと考えています。

問題にタグを追加する方法があれば素晴らしいだろう。
(自動翻訳の引用終了)

Redmineにタグ機能が欲しい、という要望は10年以上前からずっと言われていた。
そのため、熱心なユーザがタグ機能を実現するプラグインを開発してくれていた。
しかし、RedmineやRailsの度重なるバージョンアップに追随できなかった経緯もあった。

【2】ついに、Marius BALTEANUさんがパッチを投稿された。
そのコメントを読むと、Redmineユーザのニーズをすごく考えていることがよく分かる。

(自動翻訳の引用開始)
私は、プラグインhttps://github.com/ixti/redmine_tagsに基づいてRedmineにタグ機能を追加する作業を始めました(これまでの2年間で寄稿しました)。
私の計画は、第1段階で問題に簡単なタグ付け機能を追加し、機能がコアに承認/追加された後、他のエンティティ(ウィキ、プロジェクトなど)に拡張し、他のすべての機能を提案することです(バルク編集タグ、着色されたタグ)などがあります。

1.第1フェーズは、以下の2つのパッチで構成されています。

タグの追加/削除
タグの追加/削除タグの表示
タグの後にチケットをフィルター
チケット一覧の項目としてのタグ
タグ書き出し(pdf、csv)

添付されたパッチを使用してテストすることができます。
私はタグを管理する権限を持っているべきかどうか(私の見地からは、編集の権限は十分です)、何か他のものがなくなっていて、それがこの第1段階にあるはずなのかどうか疑問に思っています。

2. JSライブラリを追加してUIのタグを処理する(オートコンプリートを含む)添付のパッチでは、Jean-Philippe LangがSelect2をコアに追加したくないことを知っているのでSelectize.jsを提案します。
プラグインによって使用されることはもはや維持されません。
パッチは準備ができていませんが、私はこのライブラリを使用できることを最初に確認したいと思います(他の提案は歓迎です)。
また、プロジェクトからオートコンプリートでタグを提案する必要があるかどうか確認する必要があります。
プロジェクト階層、サブプロジェクトから)。

この機能は、Redmine.orgのチケット投票数のリストで1位にランクされ、120人以上のウォッチャー(この問題で80件、#2897で45件)、複数のコメントと関連する問題があります。
また、プラグインは、タグ付け機能がコアの一部である場合に役立ちます。
Redmine 4.0.0の後の次のバージョン(これはほとんど準備が整っています)でこれを行い、それを提供したいと思います。
(自動翻訳の引用終了)

【3】要約すれば、タグ機能が重要な理由は、2つある。
一つは、Redmine.orgのチケット投票数のリストで1位にランクされ、10年以上前からユーザの要望がチケットに記録され続けてきたこと。
もう一つは、タグ機能がRedmineチケットのカテゴリの代わりの機能になり、検索する時にも役立つこと。

Twitterのハッシュタグに慣れている人は多いだろうから、この機能が追加されることで、より多くのユーザがRedmineにチケットやWikiに情報を書き込むメリットを感じやすくなるだろう。
それら情報は、タグでカテゴライズでき、検索しやすくなるからだ。

このタグ機能も、Ver4.0またはVer4.1で取り込まれるといいなと思う。

また、Redmineの添付ファイルを全文検索できるパッチもVer4.1にセットされており、trunkにマージされることをユーザは待ち望んでいる。

Redmineの添付ファイルを全文検索するパッチの可能性~Redmineをナレッジシステムにするための要件とは何か?: プログラマの思索

タグ機能と合わせてリリースされたら、Redmineユーザにとっても待ち遠しいと思う。
今後も、Redmine本家の動向はチェックしておく。

| | コメント (0)

2018/07/04

Redmineでスケジュール調整や投票ができる「Scheduling Poll」プラグイン

Redmineでスケジュール調整や投票ができる「Scheduling Poll」プラグインを見つけたのでメモ。

【参考】
【担当者さん必見】メンバーみんなで日程調整ができる「Scheduling Poll」プラグイン登場!

cat-in-136/redmine_scheduling_poll: a plugin to provide the simple way to schedule appointments on Redmine

QA #824: チケットやニュース、フォーラム、Wikiなどで選択式のアンケートを実施したい - Unofficial Redmine Cooking - redmine.tokyo

画面を見てみると、調整さんのように複数のチェックリストに○△Xを記入した後、入力結果を自動集計してくれるみたい。

選択できるチェックリストには、日付以外にテキストが入力できるので、他のアンケート項目にも流用できるだろう。

時々、アンケート機能がRedmineにも欲しい、という声があがる時があるので、このプラグインを使えばいいかもしれない。

下記のLineの機能にインスパイアされて、Redmineプラグインを作成された、とのこと。

【幹事さん必見】友だちみんなで日程調整ができる「LINE スケジュール」機能登場! : LINE公式ブログ

こういう投票機能は、Redmineを単なるタスク管理、課題管理、障害管理だけでなく、チーム内のコミュニケーションを活性化させるためのツールへ進化させる為の機能と言い換えられる。

Rails開発の技術力があれば、自分のアイデアやプロジェクトリーダーの提案を元に、Redmineをカスタマイズすることにより、チームの一体感を生み出す機能をいくらでも作り出せる。

そういうアイデアを実現する機能とチーム内のコミュニケーションとの相関関係や影響度合いを実際に分析してみたいものだ。

| | コメント (0)

より以前の記事一覧