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)

2017/03/14

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

Redmine本家のチケットを見ていたら、Redmineのワークフロー設定を拡張する機能提案のパッチが起票されていて、Planioの Jan とやり取りしていた内容が興味深かった。
ラフなメモ書き。

【参考】
Patch #20384: Proposal: Workflow enhancement - Redmine

【1】Frederico Camaraさんの発言

(Google翻訳による引用開始)
私はブラジルの大規模なICT公開会社に勤務しています。
ここではRedmineを使用しています。

最初は、Redmineのワークフローツールが何らかの制限を加えることは明らかになりませんでした。
しかし、より複雑なワークフローを構築し、さまざまなプロジェクトやチームのロールとトラッカー名を再利用するようになると、特定のロールやトラッカーに固有のワークフローによって、ロールやトラッカーと同様の名前と同義語が使用されるようになりました。
当社のさまざまな分野の新しいワークフローを開発することができます。
これには、名前の大文字と小文字の使用、数字の追加、両方の性別の単語の使用(ポルトガル語の実体は性転換を持つ)などがあります。
同様のエントリがRedmineのさまざまなメニューに表示されるため、最終的には迷惑になりました。

また、クローズステータスは発行ステータスに固有であり、ワークフローでは重複してエントリを複製するため、一部のステータスでは問題が終了しますが、別のワークフローでは同じステータスにはなりません。
ワークフローは依然として役割とトラッカーに固有のものであるべきだと思いますが、プロジェクトには異なるワークフローセットが用意されているため、同じワークフローを使用して異なるプロジェクトを作成し、同時に異なるワークフローを使用する異なるプロジェクトを作成できます。

また、クローズされたステータスは、使用されているワークフローに固有のものでなければなりません。

最初の提案では、管理画面にワークスペース、ワークフローセット、ワークフロースペースなどの項目が表示されます。
そこから、ワークフローはワークスペースの一部になり、各プロジェクトでは使用するワークスペースを選択します。
移行の目的で、既存および新規のワークフローおよびプロジェクトはすべて、デフォルトのワークスペースに割り当てられます。
新しいサブプロジェクトは、作成時に親と同じワークスペースを選択する必要があります。
プロジェクト間にワークスペースの継承はありません。

主な利点は以下のとおりです。

・作成される発行ステータスの数が少なくなります。
・ワークフロー間の簡単な移行
・複雑なインフラストラクチャに対するより多くの制御。
・より単純なインフラストラクチャへの影響は非常に小さい。
(引用終了)

(Google翻訳による引用開始)
私は、コミットをチェリーピックし、Redmine3.3安定に対して必要な調整を行った。
ここにパッチがあります。

「管理」メニューに「ワークスペース」が追加され、既存のすべてのワークフローが「デフォルト」のワークスペースに移行されます。
プロジェクトごとに、使用するワークスペースを選択できます。
ワークスペースは、ワークフロー(遷移とアクセス許可)を互いに分離して、異なるプロジェクトが異なるワークフローを持つことができるようにします。
また、管理を手助けしようとします。
このパッチはLinux上で作成されました。
Windowsでは改行文字を修正する必要があります。

変更点:管理では、「ワークスペース」にワークスペースを追加できます。
管理>ワークフローには、新しいフィルタ「ワークスペース」があります。
ワークスペースを変更すると、異なるワークフローセットが切り替わります。
これは、フィールド許可タブの場合にも機能します。

[管理]> [ワークフロー]> [概要]には、異なるワークスペースからのビューを切り替えるためのドロップダウンメニューがあります。
管理>プロジェクトは、各プロジェクトが使用しているワークスペースを示します。
各プロジェクト>設定で、プロジェクトが使用しているワークスペースを変更することができます。

「すべて」をクリックすると、ロールがフィルタリングされたトラッカーを表示/非表示できます。
ロールは、ワークスペース上でワークフローを持つロールと、割り当てられていないロールによってフィルタリングされます。
(管理>ロール)フィルタリングされたロールの表示/非表示を「すべて」をクリックするデフォルトのワークスペースを削除することはできません(また、移行する場合は、これまでのワークフローをすべて削除します)。
(引用終了)

【2】Jan from Planio www.plan.io さんの発言:

(Google翻訳による引用開始)
これは面白い(広範囲で複雑なパッチだが)、それを提案してくれてありがとう。
この大きさのパッチが考慮されるためには、完全なテストカバレッジが必要であり、既存のテストを破ってはいけません。
可能であれば、一連のパッチに分解して、各パッチがすべてのテストをパスしたRedmineの実用バージョンになりますが、作業を別々のチャンクに分割することをお勧めします。

Planioの非常に大規模な組織のRedmineとの共同作業の主な要件は、プロジェクトチームが管理者を必要とせずに他のプロジェクトに干渉することなく独自のトラッカー、ステータス、ワークフローを作成することでした。
あなたのパッチは後者の課題を解決するようだが、前者の問題は解決していないようだ。
あなたのソリューションでは、異なるワークフローを必要とするプロジェクトチームは、依然としてRedmine管理者にそれらを作成するよう依頼する必要があります。

特に大規模な組織では、管理者が多くの帽子をかぶり、さまざまなシステムを管理するため、これは大きな課題となります。
彼らは、Redmineの管理領域の設定インタフェースや、特定のワークフロー変更を要求するプロジェクトマネージャのビジネスニーズにどのように対応しているのかを100%理解しているわけではありません。
これは、プロジェクトマネージャが電子メールまたは電話で異なるワークフローのセットを要求しているときに誤解を招く可能性があります。
管理者と一緒にプロジェクトを作成することはしばしば実現するのが難しく、プロジェクトで必要なワークフローを実装するには数週間かかることがあります。

私は、特定の役割がプロジェクトのトラッカー、ステータス、ワークフローを個別に管理できるソリューションが、多くの大企業で見られた課題に適したソリューションであると考えています。
(引用終了)

【3】Redmineを大規模な組織に適用して運用していくと、ユーザグループやカスタムフィールド、ワークフローなどの「設定だけ」をシステム管理者ではなく、一部のPJ管理者に権限委譲したくなってくる。
そのPJだけに必要なマスタ保守は、そのPJ管理者だけが更新する方が早いし、逐一、システム管理者に連絡する必要もないはず。

Janの意見の通り、非常に大規模な組織において、プロジェクトチームがシステム管理者を必要とせず、他のプロジェクトに干渉することなく、独自のトラッカー、ステータス、ワークフローを更新できるようにしたい。

システム管理者はRedmineの全機能にアクセスできるが、PJ管理者にはそこまでの権限を緩めたくはない。
PJ管理者は、Redmineの全機能、Redmineに付与されたマスタ設定の意味まで100%知っているわけではないからだ。

つまり、PJ間同士でマスタ不整合が起きない限り、PJに関するマスタ保守は、PJ管理者に権限委譲して、システム管理者の作業負荷を下げたい。
すなわち、システム管理者無しで、Redmineのあらゆる機能の権限制御をもっと細かく設定したい。

上記のチケットの意図は、おそらくそんな所にあるのだろうと思う。

まだ、上記のチケットに添付されたパッチを適用していないので分からないが、上記のパッチは、以下のような機能を持つらしい。

・「管理」メニューに「ワークスペース」が追加され、プロジェクトごとに、使用するワークスペースを選択できる
・ワークスペースは、ワークフロー(遷移とアクセス許可)を互いに分離して、異なるプロジェクトが異なるワークフローを持つことができる
・ワークスペースにあるワークフローには、ロールやカスタムフィールドなどがあり、PJごとに、ロール単位で制御できる

しかし、Janの意見では、上記のパッチでは、「プロジェクトチームが他のプロジェクトに干渉することなく独自のトラッカー、ステータス、ワークフローを更新できる」機能を提供するが、システム管理者なしでPJ管理者だけでコントロールするには不十分らしい。

【4】では、このパッチが提供する機能の本来の課題は何なのか?
それは、Redmineを汎用的なBPMツールへ機能拡張する方向性を示したい、ということだろうと思う。
そのアイデアについては、以前書いた。

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

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

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

上記のパッチが提供するイメージとしては、最終的には、Redmineのマスタ保守をPJごとに保存でき、PJ単位で保守できるようにすることだ。
つまり、PJ単位でワークフロー設定情報をXML出力してバックアップでき、そのXMLをインポートすれば即座にRedmineのPJごとにマスタを復元できるイメージ。

管理画面から、PJごとにワークフロー情報を画面から更新できるならば、その情報を出力したり、一括インポートできる機能があって然るべきだろう。
実際のRedmineではそんな機能はないが、そこまで実現できれば、RedmineはOSSのBPMツールとして、十分に通用するだろう。

そもそも、RedmineにBPMツールのような機能が必要なのか、と言われると、正直分からない。
でも、Redmineの管理画面の権限制御の課題は、東京RedmineでもRedmine大阪でも、一部のユーザからは似たような問題意識が提起されていた。
つまり、彼らも、Redmineを運用している組織が大規模になってくると、管理画面の権限制御をシステム管理者なしで、PJ管理者がPJ単位で制御できるようにしたくなってくるわけだ。

QA #263: カスタムフィールドの選択項目定義(KVS)を、admin以外にも可能としたい。 - Unofficial Redmine Cooking - redmine.tokyo

QA #265: カスタムフィールド(list)の選択肢定義をadmin以外編集可能にしたい(KeyValueList以外で) - Unofficial Redmine Cooking - redmine.tokyo

QA #266: ユーザグループの定義内容変更をadmin以外も可能にしたい - Unofficial Redmine Cooking - redmine.tokyo

上記チケットのやり取りを見ていると、今後のRedmineの発展の方向性は、そこにあるのかもしれない。

| | コメント (0)

2017/03/11

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

残業申請ワークフローやITIL運用プロセスをRedmineで実現した事例の記事が面白かったので、リンクしておく。

【参考1】
Redmineで残業申請ワークフロー - My Tracking

(引用開始)
勤務管理の厳正化が叫ばれる昨今、所属する会社でも残業申請が行わている。 概ね、以下のような残業申請の形態(一応システム会社)。

基本Excelでの申請台帳形式
申請者が事前にExcelに以下の内容を入力する。
①申請日・②時間・③残業予定時間・④概要・⑤内容。
申請者が上司にメールする。
上司が内容を確認し、承認/却下とその理由も添えてExcelに記載し、回答する。
事後申請の場合は、申請者がその旨記載し、入力する。

いろいろな問題をはらんでいるものの最大の問題が、

「Excelの台帳を誰かが開きっぱなしにすると、申請自体ができない」

という最も単純かつ根本的な問題に行きつき、そのわずらわしさから、申請自体がおざなりになるという事態が頻発。
(引用終了)

システム会社であっても、残業申請はExcel管理台帳に書いて、それを印刷して、警備員に渡す運用フローが回っている所は多い。
Excel管理台帳や印刷した紙は便利だが、大人数の運用には向いていない。
こういう現場はまだまだたくさんあるのではないだろうか?

上記の記事では、そんな問題意識からRedmineを導入したらしい。
興味深い点は二つある。

一つは、最初にBPMN 製品を検討したがRedmineに乗り換えた点。

僕も一時期、汎用ワークフロー基盤を持つパッケージ製品を調べていたので、事情は何となく分かる。
確かに、事務処理のような汎用ワークフローの機能は豊富だが、複雑すぎて使いこなせない。
汎用ワークフロー基盤のメリットは、組織情報を持っているので、組織や役職に応じた複雑な条件をワークフローに入れ込むことができること。
しかし、もっと簡易なワークフロー機能だけで、十分に使える利用シーンは多いから。

Redmineは帳票ワークフローシステムであるというアイデア: プログラマの思索

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

Redmineを勤怠管理システムで運用するアイデア: プログラマの思索

オープンソースのBPMツールBonitaのメモ: プログラマの思索

オープンソースのワークフローエンジンActivitiの感想: プログラマの思索

BonitaBPMを動かしてみた感想~BPMツールに必要な必須機能: プログラマの思索

もう一つは、「事前申請」「事後申請」の二つのトラッカーを使っている点。
普通は、事前申請トラッカーだけだろうが、たとえば、本番障害の緊急対応で急遽、休日夜間に出勤して対応した、という事態もあるだろう。
つまり、例外的な残業申請に対して「事後申請」というトラッカーを設けている、と思われる。

この辺りは、現場に応じていろんな状況があるはずなので、例外的な運用をどこまでシステム化するのか、あるいは、手運用でフォローするのか、という天秤をかけることになるのだろう。

個人的には、残業申請のように、特に細かな観点の集計が必要でないワークフローは、IssueTempateプラグインで、説明欄に申請テンプレートを作っておく運用がとてもマッチしていると思う。

Issue Template - Plugins - Redmine

理由は、申請テンプレートを用意しておけば、申請者は空欄に情報を埋めるだけでよく、申請内容を考える労力が減るし、申請内容の記載漏れも減るからだ。
わざわざ、たくさんのカスタムフィールドを設けて、入力が面倒になるようなUIにする必要はない。

事務処理ワークフローでは、IssueTempateプラグインのようなチケットテンプレートを事前準備する機能が重要になってくるだろうと思う。

【参考2】
Redmineを使ったITIL的な運用プロセス管理 - My Tracking

(引用開始)
所属する会社(一応システム会社の情シス)では、 日々ヘルプデスク業務や問合せ業務が頻繁に発生するが、 概ね、どこにでもあるような以下の課題が発生している。

当事者同士の口頭・メールベースでやり取りが可視化・蓄積化されずらい。 (しかも、個人に割り当てされるメール容量が少ないため、メールを最終的には削除せざるを得ない。)

問い合わせに端を発し、課題管理・ 変更管理といった形でプロセス遷移していった場合、その遷移が事後的に追いづらい。 (あの件どうだったっけ?が頻発する。)

以下の参考書籍には、顧客サポート業務をRedmineを使用して行っている好例があっため、先述の課題をRedmineで改善できないかと考えたのがそもそもの発端。
(引用終了)

システム会社であれ、製造業であれ、小売業であれ、ヘルプデスクや問合せ、カスタマーサポートのような業務は必ずある。
それら業務は普通は、メールや電話などでやり取りされているだろう。
しかし、個人ベースで情報蓄積されてしまいがちで、応援したくても刻一刻と状況が変わるような状況では情報共有しにくく、引き継ぎしにくい。
特に、顧客からの問合せには、即座に対応する緊急性の高いものから、優先度が低いものまで多様なので、それら切り分けも大変。

上記の記事で興味深い点は、「ITILのプロセスを「トラッカー」で表現し、それぞれステータス更新させる」している点。
つまり、インシデント管理、問題管理、変更管理、リリース管理などのプロセスごとにトラッカーを作り、運用方針を定めている。
このやり方の方が上手く回るだろうと思う。

僕も、9年前に、ITILをRedmineのワークフローで回そうと色々試していた時期があった。
当初は、一つのトラッカーで、インシデント管理、問題管理、変更管理、リリース管理のプロセスにステータスを割り当てて運用しようとしていた。
すると、ステータスが10個近くにもなり、チケットは更新されているのに、外部から見るとチケットが滞留しているように見えて、あまり上手く運用できなかった経験がある。

ステータスの多いトラッカーでよく見られるアンチパターン「スタンプラリー」に陥っていたのだと思う。

個人的には、こういうタスクは、親子チケットにすれば良いと思う。
親チケットが進捗報告用、子チケットがそれぞれのプロセスのチケットにすれば、親チケットで進捗率や状況が一目で分かる。
また、各プロセスの子チケットでは普通は担当者がそれぞれ異なるので、担当者も自分のチケットだけに専念しやすい。
こういうたくさんの担当者が関わるチケットは、親子チケットで分割した方が作業しやすいし、プロマネも管理しやすい。

できれば、Redmineで親子チケットのテンプレートを設定できる機能があれば、もっと良いのだが。

最後のコメントもとてもいい。

(引用開始)
以上の感じで、問合せに端を発した1つのチケットが様々なプロセス(ここではトラッカー)遷移を経ながら、 最終的には、クローズされ、その経緯もバッチリ履歴化されるため、 内容をよりシャープにさせていけば、より高精度な業務が実現できそう。

※こんな高機能のソフトウェアを無償で利用できるようにしてくれた開発者・コミュティの人たちに唯々感謝するばかり。
(引用終了)

Redmineの最大の特徴は、チケットの柔軟な機能だ。
そのおかげで、ソフトウェア開発のタスク管理以外の用途にも適用でき、色んな使い方、色んな利用シーンが生まれている。
Redmineは、先進的なプロジェクト管理の実験ツールなので、今後も改良される余地がたくさんあるだろう。
その可能性を色々調べてみたい。

| | コメント (0)

2017/03/05

最近よく聞くRedmineのFAQ~Excel添付のチケットから野良Redmineまで

3/25土開催予定のRedmine大阪のパネルディスカッション「RedmineのFAQとアンチパターン」について、資料を集めている。
たくさん集まりすぎて、話せそうにないので、たぶん話せないことをメモ書きしておく。
以下は、未整理のメモ。
たぶん、どこかで講演として話したい。

【1】Excel添付のチケット

チケット説明欄がほとんど無くて、Excel添付だけ。
Excelを開かないと内容が分からない。
添付Excelの内容が最新でないので、話がつながらない。

障害管理、事務処理ワークフローで発生しやすい。

解決策は、いくつかある。
基本は、Excel添付は極力止めて、チケット説明欄に書く。

2つ目は、障害の画面キャプチャは、clipboard_image_pasteプラグインで、コピーした画像を貼り付ける。

peclik/clipboard_image_paste: Redmine plugin for pasting cropped image from clipboard as an attachment.

3つ目は、どうしてもExcelファイルが必要ならば、wiki_uncプラグインで、共有ファイルサーバーのExcelにへリンクさせる。
その方がExcelファイルが大容量でも良いし、Excelファイルがどんどん更新されても最新版は共有フィアルサーバーにあるから。

Redmineで共有ファイルサーバーへリンクするプラグインredmine_wiki_unc: プログラマの思索

追記:
GDriveプラグインがある。
このGDriveプラグインを使えば、添付ファイルや文書はGDriveに配置して、チケットにリンクすればいい。

Gdrive Document library - Plugins - Redmine

neta@とんこつしかたべないさんのツイート: "G Suite を検討中。Redmineの添付を Google ドライブ にできると捗る気がしたけども、そもそもリンク書けばいいんだよな。プラグイン Gdrive Document library - https://t.co/F1q9aOhRln"

他に、FTP File Server Pluginを使う方法もある。
FTP File Server Pluginをを使って、FTPファイルサーバーを別途用意して、そこに添付ファイルや文書を配置する運用もありうる。

RedmineへのファイルアップロードをFTPファイルサーバーに置き換えるプラグインFTP File Server Plugin: プログラマの思索

FTP File Server - Plugins - Redmine

【2】チケットがポエム

チケット説明欄が散文形式。
誰も分からない。
何をしたら完了になるのか、意見が割れる。

チケット管理のアンチパターンとベストプラクティス - Javaプログラマのはしくれダイアリー

Redmineのチケット管理のアンチパターン事例: プログラマの思索

基本の対策は、チケット起票の運用ルールを策定する。
チケットUIの改善策として、Issue_templateプラグインを使う。
つまり、何を書いたら作業指示書となるのか、テンプレートを事前に用意して、強制的に書かせるようにしたらいい。

Issue Template - Plugins - Redmine

【3】議事録はチケット? Wiki?

議事録をチケットで回す事例を見かける。

議事録チケットのメリットはいくつかある。
一つは、回覧のチェックができる。
チェックリスト形式で、全員がきちんと読むように義務付けられる。

もう一つは、議事録の書記を担当者でアサインできる。
議事録の責任者を明確にできる。

しかし、議事録チケットのデメリットもあると思う。
議事録がチケットに埋もれてしまうのが嫌。
議事録は日付順に、1箇所にまとめられた方が、変更内容を追跡しやすい。
たとえば、顧客との要件定義の議事録とか。

Wikiの方が共有しやすいと思う。
個人的には、議事録はWikiの方が好き。(この辺りは色々意見があると思う)

対策としては、Wikiに議事録チケットのリンクを張り、日付順に探せるようにしておく。

【4】Redmineでナレッジはどう蓄積する?

業務や技術ノウハウを蓄積したい。
その場合、Redmineをポータルサイトのように使いたい。
PJ横断のグローバルWikiのような機能がRedmineに欲しい。

このアイデアは以前書いた。

redmineでナレッジを蓄積していく方法: プログラマの思索

ナレッジ蓄積用のプラグインはいくつかある。
WikiExtensionsプラグイン。

Wiki Extensions - Plugins - Redmine

用語集プラグインは、業務分析工程での専門用語の管理、社内辞書として使える。
但し、Ver3.xに未対応なので、有志がカスタマイズしている。

redmine_glossary(用語集)プラグインのRedmine 3.0(3.1)対応 - torutkの日記

knowledgebaseプラグインは、タグ付けやカテゴリ分類ができて、情報の役立ち度をランク付け、記事にコメント可、管理メニューから即アクセス可能。
たぶん、グローバルWikiとして使いたいなら、knowledgebaseプラグインがお勧めかな。
Ver3.3.xでも使えた。

Knowledgebase - Plugins - Redmine

alexbevi/redmine_knowledgebase: A knowledgebase plugin for Redmine

個人的に、Redmineでいつも残念な機能は、コードシンタックスの言語が少なすぎること。
C#がない。
.NET開発者から、いつも問い合わせが来る。

2016年12月のRedmine開発状況 | Redmine.JP Blog(Feature #24681: シンタックスハイライトの対応言語を100以上に増やす)

【5】チケット完了時に項目が未入力

チケットの期日、進捗率が未入力で放置されやすい。
CFが空欄だとチケット集計時に困る。

対策は、完了時に自動補完させる。
issue_completionを入れる。

Redmineチケットの完了時に進捗率と期日を自動更新するプラグインredmine_issue_completion: プログラマの思索

カスタムフィールドの自動補完は、ViewCustomizeプラグインで実装できるだろう。

Redmineの画面レイアウトの微修正にこだわる改善要望はViewCustomizeプラグインを使え!: プログラマの思索

【6】チケットのCFが多すぎる

CFが誰も使わない項目になっている。
Excel管理台帳の項目がそのままチケット化された場合に多い。
特に、障害管理台帳とか。

CFのメリットは集計しやすいこと。
一方、入力コストが大きい。
CFはコピーしにくい。
タブキーが使えないので、入力が面倒。
CFが多くなるほど、チケットがサクサク流れない。

解決策は、基本はCFは必要最小限にする方が良いと思う。

チケットのUI改善策として、説明欄にテンプレートを準備し、CFを極力使わない方法もある。
Issue_templateプラグインを使う。
チケット入力を楽にするための方法はもっとあるだろう。

Issue Template - Plugins - Redmine

【7】庶務チケットをテンプレート化したい

利用シーンとして、庶務・事務の業務は定型作業。
内容も単純。
集計不要のタスクだから。

定形作業のテンプレートがないと、一貫性がなくなり属人的になりやすい。
CFでたくさん細かく項目を作る程でもない作業が多い。

解決策はいくつかある。
一つは、チケット説明欄をテンプレート化する。
Issue_templateプラグインを使う。

Issue Template - Plugins - Redmine

Issue_templateプラグインは、トラッカー単位、PJ単位にテンプレートを用意できるので、庶務業務のためだけのトラッカーを増殖させる必要がなくなるメリットが良い。

一方、Issue_templateプラグインでは、担当者は空欄になってしまうので、デフォルトの担当者を設定できない。
ここの運用が結構困る。
ViewCustomizeプラグインでデフォルト担当者を自動補完させるように設定する?

ViewCustomizeプラグインでRedmineをマイクロコア化できるか: プログラマの思索

もう一つは、テンプレートチケットを作っておき、チケットのcopy機能を使う。
説明欄をテンプレートにしておき、担当者を初期設定しておけばいい。
開始日を空欄にしておけば、新規でコピーした時、現在日が自動設定される。

【8】毎月の定型作業のチケット登録を簡単にしたい

利用シーンは、月末の作業実績報告書の作成、とか、定期的なログ集計、とか、年1回のシステム保守作業。

akipiiさんのツイート: "手伝ってもらってる感触がいいね!RT @netazone: Redmine に仕込んだ定期チケット作成バッチが、忘れがちな月次タスクのチケット作ってくれるのでとても捗る。 システムに手伝ってもらってる感あって、なんかいい。オススメ。"

チケットを定期的に登録する解決策はどんなものがあるか?

一つは、Cron+REST APIでチケット自動登録。
他には、定型タスクをチケットするプラグインがいくつかある。

定期的なタスクをチケット登録するRedmineプラグイン: プログラマの思索

【9】チケットがメール化している

チケットがなかなか終了しない。
コメントがスレッド化している。
チケットのコメント数が多い。
チケットのコメントで別の問題解決が進行している場合は、危険なサイン?

個人的には、スレッドが長いチケットは気にならない。
メールのやり取りがチケット化されたと理解できるから。

チケットは細かすぎても逆に使い勝手が悪く、検索しにくくて、困る場合もある。

【10】ソース管理よりも文書管理をチケットで追跡したい

たとえば、ISO9001の規定文書をポータルサイトに配置して共有したい。
文書テンプレートは、ポータルサイトからダウンロードさせて、使わせたい。
ISO9001の規定文書の履歴管理もしたいし、参照や更新権限を制御したい。

現状では、共有ファイルサーバーに文書を置くと、チケットと関連付けれない。
共有ファイルサーバーのファイル管理は煩雑になりがち。

解決策としてはいくつかある。
暫定策としては、ファイル容量が大きすぎな場合は、redmine_wiki_uncプラグインを使う。
共有ファイルサーバーへUNCパスでリンクさせるだけ。

Redmineを文書管理ツールとして使うならば、DMSFプラグインを使う。
RxTStudy勉強会のJAXA講演でも、JAXAではDMSFプラグインを導入していたらしい。
Ver3.3.xにも対応している。

DMSF - Plugins - Redmine

Redmineの文書ファイルを全文検索するプラグインのリンク: プログラマの思索

DMSFプラグインなら、文書を階層で管理できる。
文書ファイルの履歴管理、文書ファイルの簡易ワークフロー制御も可能。
但し、文書ファイルのワークフローはトラッカーと異なる管理画面で設定する。

文書更新時にメール送信、Office文書を全文検索もある。
但し、全文検索は日本語はパッチ必要みたい。

第2回品川Redmine勉強会(日本語全文検索)

Redmine3.2でバージョン管理もできるドキュメント管理プラグイン「DMSF」 | 俺的備忘録 〜なんかいろいろ〜

【11】利用者全員に手軽にアナウンスしたい

利用シーンは、RedmineのVerUpアナウンス、定期メンテナンスなど利用者全員への事前通知。

いくつかプラグインがある。
bannerプラグインなら、バナー表示できる。
このプラグインが一番使い勝手が良い。

Banner - Plugins - Redmine

redmine_maintenanceプラグインでは、メンテナンスモードになると、管理者以外は操作できなくなる機能を提供する。
VerUp時は、そもそもRedmineを再起動するので、使えない?

ameya86/redmine_maintenance: メンテナンスモードを提供するプラグインです

【12】チケット集計機能が弱い

蓄積されたチケットを色んな観点で集計したい。
Redmineの基本機能では集計機能が不足している。
でも自作すればいい。
自分たちで改善していく。

対策は、やり方は色々ある。

CSV出力してExcelマクロ集計。

各種の集計プラグインを使う。
たとえば、RedminePivottableプラグインでピボット集計とか。

Redmine Pivot tableプラグインのリンク: プログラマの思索

他にも色々。
RESTAPI経由でBIツールに集計させれば、もっと多機能にできる。

RedmineのチケットデータをRedmine外部のBIツールで表現するアイデア: プログラマの思索

Elastic Search+Logstash+Kibana+TimelionでRedmineのBIを実現する記事のリンク: プログラマの思索

【13】野良Redmineが社内に溢れる

症状として、会社標準のRedmineは使いにくい。
別チームのRedmineは特定PJに特化されている。
運用が拡大すると、運用ルール策定が追いつかない。
オフショアや外部ベンダーのやり取りは、セキュリティ上別サーバーにすべきだから。

結局、社内に非公式のRedmineインスタンスがあふれる。
別名は「闇Redmine」。

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

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

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

第11回東京Redmine勉強会の感想~Redmineエバンジェリストが日本各地で出現しているらしい #redmineT: プログラマの思索

akipiiさんのツイート: "あるある笑。RT @ryouma_nagare: 久々に他人が構築したRedmineを使い始めたが、自分がシステム管理者じゃないRedmineはなんとなく居心地が悪い。"

根本問題は、大規模な組織で多様な業務を、一つのRedmineインスタンスで対応できるか?
組織ごとにRedmineを作りたい意図もある。
セキュリティ上の理由で複数のRedmineインスタンスはありうる。

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

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

第13回RxTStudy勉強会の感想 #RxTStudy: プログラマの思索

他の課題として、複数のRedmineインスタンスを統合できるか?
組織の統廃合、ナレッジ蓄積の引継ぎなど、いろんな事情があるだろう。

QA #247: 複数のRedmineサーバを統合したい - Unofficial Redmine Cooking - redmine.tokyo

Redmine同士でチケットを関連付けたい。
リンク型CFを使う。

Redmineのリンク型カスタムフィールドの使い方: プログラマの思索

【14】他にも「ウォッチャー機能を強化したい」とかある。
後でまとめる。

| | コメント (0)

2017/02/27

Redmineの親子チケットの功罪

RedmineのFAQとアンチパターンを整理していると、最近は、親子チケットに絡む内容が多いような気がした。
Redmineは先進的なプロジェクト管理を行う実験場であり、まだまだ改善の余地はたくさんあると思う。
考えたことをラフなメモ書き。

【1】最近、ソフトウェア開発者以外の人達から、Redmineを業務に使えないか、質問を受ける場合が多い。
彼らの目的は、タスク管理や、昔のNotesの代わりの事務処理ワークフローに使いたいみたいだ。
Excel帳票やExcel管理台帳が溢れていて、それを何とかしたい、という動機みたい。

そういう場面に、Redmineは導入しやすいし、運用して効果も期待できる。
OSSで無料だし、小さく運用を始めて様子見した後、大人数へ横展開することもできる。

特に、大規模に使っていく場合、Redmineのメリットがとても良く出てくる。
つまり、Redmineのメリットである「親子プロジェクトの階層は無限」「親子チケットの階層は無限」を上手く適用できれば、多数の組織も管理できるし、多数の作業もまとめて管理できる。

換言すれば、Redmineの「プロジェクトやチケットの階層が無限に作れる」特徴は、とても柔軟な機能なので、いろんな業務に適用しやすい。
だから、色んな人達が色んな業務にRedmineを適用しようと試している。

しかし、話を聞くと、業務がRedmineに完全にフィットしない場面もあるらしい。
どうやら、特に親子チケットの作り方に問題があるような気がしている。

【2】では、Redmineを実際に運用した場面で、親子チケットを使った時にどんな問題が噴出しているのか?
色々集めてみた。

【2-1】親子チケットにし過ぎる

個人のToDoを子チケットで登録して、親チケットにぶら下げる人がいる。
他の人には不要なチケットだ。
チケットが乱発されて、登録した本人ですら、チケットの棚卸しができなくなる。

根本問題は、チケットの粒度があまりにも細かすぎる点だと思う。
解決策としては、他人と共有すべき作業内容に限定する運用ルールを作る。

僕が最も推奨するのは、TODOレベルは、チケットにチェックリストを追記する運用に変更することだ。
なぜなら、個人のToDOレベルのタスクが全て終わったことが、その人のチケットの完了条件とみなせば、他人と進捗状況を共有しやすくなるからだ。
つまり、個人のToDOはチェックリストにすべきだ。

たとえば、Checklistsプラグインを入れてもいいかもしれない。

Checklists - Plugins - Redmine

但し、チェックリストを作ったとしても、チケットに未チェックが残っても、チケットが完了できてしまうリスクもある。
その場合は、下記のように、完了できなくなるパッチを当てればいい。

Redmine Checklists pluginで未チェックの検証を雑に行う - Qiita

あるいは、プライベートチケットを使う方法もあるだろう。
プライベート機能を使えば、他人には見えないから、ToDOチケットは邪魔にならない。
しかし、共有すべきチケットが存在すれば、埋もれてしまうリスクもある。

【2-2】親子チケットで、開始日・期日・予定工数のロールアップを止めたい

よくある例は、WF型開発の案件で、親チケットにSEが開始予定日・終了予定日・予定工数を入力した後、子チケットにPGが実績の開始日・終了日・自分で見積もった予定工数を入力すると、親チケットの開始日・期日・予定工数が消えてしまう問題だ。

Redmineの本来の仕様は、「WBS 100%ルール」であり、WBSに漏れがあってはいけないから、親チケットは子チケットの情報をロールアップする。
しかし、WBS 100%ルールは、実運用に合わないケースが多い。
結局、WF型開発も綺麗に運用できるわけではない。

SQIP2015の講演後の質問でも、この質問が最も多かった。

【公開】SQIP2015講演資料「チケット駆動開発の運用パターン集~問題はチケットに分割して統治せよ」 #Redmine: プログラマの思索

実は、対処としては、RedmineのVer3から、Redmineの設定画面で「子チケットから独立」を選択することで解決できる。
また、親チケットの予定工数と、子チケットの予定工数の合計は別カラムとして表示されるので、問題なくなった。

しかし、この運用が本当に良いかどうかは分からない。
WBS 100%ルールを止めるということは、WBS作成の基本ルールを破棄していることだから。

【2-3】未完了のチケットが残っているのに、親チケットが完了できてしまう

これは、WBS 100%ルールではありえない問題だが、Redmineの機能には実装されていない。
実は、RedmineのVer3.4で対応済みだ。

2016年11月のRedmine開発状況 | Redmine.JP Blog(Feature #10989: 未完了の子チケットを持つ親チケットのクローズを禁止)

Redmineの次期バージョン3.4の見所: プログラマの思索

Feature #10989: Prevent parent issue from being closed if a child issue is open - Redmine

「Feature #10989: 未完了の子チケットを持つ親チケットのクローズを禁止」のパッチによって、WBS 100%ルールが実現できるおかげで、親チケットのステータスを明確に判別できる。

【2-4】親子チケットでどこまで深く階層化するか?

Redmineの実運用では、ExcelのWBSのように5~10階層までブレイクダウンしたい目的が多い。
つまり、ExcelやMSProjectみたいに、WBSの深い階層をRedmineチケットで表現したい。

しかし、WBS 100%ルールを厳格に運用するとデメリットが大きくなると感じている。

普通、タスクは階層化しやすい。
しかし、障害やQAは階層化に合わない。

そして、深い階層のチケットは、チケット一覧画面では見通しが悪い。
むしろ、ガントチャートが向く。
ガントチャートならば、階層構造が綺麗に表現されるからだ。
だが、Redmineのガントチャートで編集できない弱点がある。

また、深い階層のチケットのデメリットはいくつかある。
一つは、 性能が悪くなること。
浅い階層では問題ないが、かなり深い階層とか、数千件の子チケットを持つチケットの操作のパフォーマンスが悪くなるらしい。
そのパフォーマンス改善のパッチがRedmine本家に提供されたが、Ver3.4ではリジェクトされている。

2016年12月のRedmine開発状況 | Redmine.JP Blog (Defect #23318: 大量の子チケットを持つチケットで #lock_nested_set メソッドが遅い問題の改善)

実際、Redmineの実ソースでは、子チケットを表示する時に、select ~ for updateを使っているみたいだ。
つまり、ロックを故意にかけているので、性能が悪くなる可能性はある。

もう一つは、親子チケットを一括登録しようとすると一手間かかることだ。
実際、親チケットを採番しないと子チケットを一括インポートできない。
なぜなら、親チケットNoを採番しなければ、子チケットの親チケットNoを指定できないからだ。
すると、階層の数だけ、一括登録のインポート処理を繰り返し、その都度、親チケットNoを取得してはセットする手間が必要。
手作業で親子チケットは簡単に作れるが、MSProjectで作った5階層のWBSを一括インポートしたい需要はあるだろう。
どこかのツールで手軽に実行できないかな?

さらに、深い階層の親子チケットは、チケット保守が大変になる。
親子構造を変えにくかったりする。

また、バージョンが古いRedmineでは、WBS 100%ルールが実運用に合わないことは前に触れた。

そして、深い階層の親子チケットでは、WBS漏れを検知できるか?
要件チケットから成果物までのトレーサビリティをRedmineは実現できるのが、もう一つのRedmineのメリットだが、階層の深いチケットを作ると、WBSがどこかで漏れていたとしても、Redmine上ではすぐには分からない。
結局、CSV出力して、Excel上でWBS漏れを探した方が早いだろう。

あるいは、Lychee LACという有償プラグインを使って、Redmineの階層構造とトレーサビリティをツリー構造で図で表示する方法があるかもしれない。

プロセスフロー図をRedmineチケットで表現するアイデア~Lychee Association Chartで実現できるか: プログラマの思索

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

【2-5】チケットの棚卸しがやりにくい

親子チケットにすると、チケットの棚卸しがやりにくそうに感じる。
最下層の子チケットを棚卸ししなければ意味がないが、どうしてもチケットが多すぎるからだ。
駄目なプロマネはRedmineのチケット一覧で頑張ろうとして、溢れたチケットに溺れてしまう。

チケット一覧で棚卸ししようとして詰まるみたい。
すると「放置されたチケット」「停滞したチケット」「乱発されたチケット」のようなアンチパターンが生まれてしまう。

個人的には、親子チケットを使わすぎず、ロードマップを使う方が良いと思う。
つまり、バージョン=納品日、締切日として運用して、ロードマップ画面でチケットを取捨選択する運用に切り替えるわけだ。
僕がRedmineを運用して、これがアジャイル開発の本来のマネジメントなのだ、と気づいた機能の一つ。

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

Redmineのロードマップ画面では、右クリックでチケット編集コンテキストメニューを出せるので、ロードマップ画面上で優先度を考えながら、チケットの属性を編集できる。

しかし、Redmineのロードマップ画面も機能不足と感じる。
ロードマップ画面で、チケットの優先順位を付ける機能がないからだ。

現状では、下記の3つしかやり方がない。
しかし、チケット枚数が増えるとロードマップ画面でも厳しくなる。

1・チケットの優先度を設定する
→なる早が増える

2・先行・後続の関連を付ける
→チケット操作が複雑。ガントチャート画面で編集できない。

3・バージョンを設定する
→チケット枚数が増えるとチケットが溢れる。本来は、チケットの並び順で優先度を付けたい。

本来は、ロードマップ画面で、チケットをD&Dして並び替えて、チケットの並び順で優先度を付けたいのだ。
このパッチは、実はRedmine本家で既に提供されている。

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

2016年9月のRedmine開発状況 | Redmine.JP Blog(Feature #22802: バージョン内のチケットをドラッグ&ドロップで並べ替え)

ここで、Scrumのプロダクトバックログでは、タスクカードの並び順が作業順序である。
つまり、開発者は、バックログの一番上からタスクカードを取り出して、作業をこなしていけばいい。
開発者は優先順位について考える必要はない。

一方、プロジェクトオーナーやプロダクトオーナーは、プロダクトバックログを常に精査して、どのフィーチャの実現を優先すべきか、取捨選択して、並び順を優先順位として考えればいい。

つまり、Redmineのロードマップ画面はもっと改良できる余地がある。
Feature #22802: Add the posibility to set/change the position of an issue in a version - Redmineでは、ロードマップ画面の並び順だけでなく、チケット一覧画面の並び順も考慮すべきでは?という議論があるが、それはナンセンスだ。

チケット一覧画面は、クエリによってある特定の検索条件でチケットのリストを抽出だけの機能だ。
しかも、ソート順も検索条件の一つになっている。
そもそも、D&Dでチケットの並び順を変更する必要もない。

一方、ロードマップ画面はリリース計画で使うべき機能だ。
この画面こそが、チケットの取捨選択を行うべきRedmineの中核機能だ。
だからこそ、Redmineにもっとアジャイル開発の特徴を取り込みたいのだ。

個人的には、Feature #22802: Add the posibility to set/change the position of an issue in a version - Redmineに数多くの人が「+1」のコメントを付けて、Redmineの機能の一つとして実現して欲しいと思う。

【3】こう考えてみると、Redmineは先進的なプロジェクト管理を行う実験場であり、機能面でも運用面でもまだまだ改善の余地はたくさんあると思う。
チケット管理には、プロジェクト管理を効率化させる可能性がまだまだ秘められていると思う。

【追記】
皆さんのツイートがとても興味深いので、メモしておく。
もっと、皆さんの経験に基づいた奥深い議論がしたい。

門屋 浩文さんのツイート: "@akipii WBS関連で親子関係についてはいつも議論になりますがプロジェクトのベースを合わせることを意識した説明、意識づけをしてます ロードマップは合わないかなと思い説明はしてません"

akipiiさんのツイート: "@MadoWindahead 個人的には、ロードマップ画面こそがRedmineの中核機能と思います。でも機能が足りない。チケット一覧画面で皆頑張ろうとしすぎ。親子チケット、親子PJの運用方法はまだまだ改善の余地がある。"

ニートン 岩崎さんのツイート: "親子チケットは罪しかないので、親子チケット作らないようにして、それに該当するのはカテゴリやマイルストーンで代用してる https://t.co/vx7eXRiBPZ"

akipiiさんのツイート: "@neeton_iwasaki Redmineの親子チケットや親子PJは、メーカーのような機能別組織にとてもマッチしてます。親チケットは設計部門が作り、製造部門が子チケットにタスクをぶら下げて、進捗管理するとか。多分、日本のSIやメーカーは親子チケットが好きなのでしょう笑"

| | コメント (0)

2017/02/23

データフローダイアグラムではプロセスは一番最後に書く

データフローダイアグラムの書き方について、良い記事があったのでリンクしておく。
記事を読んで、まだ修行が足りないと感じたので、自分用のメモ。

【参考1】
データフローダイアグラムの書き方

(引用開始)
プロセス,データの発生源・行き先,データの保管元・保管先全てに名前がついているにもかかわらず,データの流れにだけ名前がついていないDFDを見かけることがあります.
これらはDFDの役割を果たしていません.
DFDが表現しなければならないのは,プロセス,データの発生源・行き先,データの保管元・保管先を行き来するデータなのです.
データの流れに名前をつけないのは,DFDが最も表現しなければならないものを表現していないということです.

図6.プロセス名は最後につける
(引用終了)

(引用開始)
入出力するデータからプロセスの内容の推測が困難な場合,原因はプロセスの機能分割が適切ではないことが多々あります.
プロセスは,例え名前がなくても,入出力データからその内容を容易に推測できるものでなくてはなりません.

データの流れに名前をつける際には,「~情報」や「~データ」と言う名前をつけてはいけません.
抽象的すぎ何を表わしているのかわかりません.
図6の営業所からのデータの流れの名前が「販売実績」ではなく「営業所情報」や「販売情報」だったら,何を表わしているのかわかるでしょうか.
もし,データの流れに具体的な名前がつけられないのなら,DFDの作り方に間違いがあります.再検討しましょう.
(引用終了)

【参考2】
DFD(データフローダイヤグラム)の描き方(1) | ステキな一日

(引用開始)
仕事でDFDを書く機会が多いのだが、DFDの書き方を知らない人が多いのでここにメモしておく。
自分自身が100%完璧に使いこなしているわけではないので、自分の理解している範囲での内容となる。

データフローダイヤグラム(DFD)は単独で成り立つものではありません。
データディクショナリーとミニ仕様書という三点セットで業務分析を行う際に使用します。
システムの概念だけを伝えるのであれば、DFD単体でも良いのかも知れませんが・・・。
(引用終了)

DFD(データフローダイヤグラム)の描き方(2) | ステキな一日

(引用開始)
さて、DFDの描き方です。一番初めに何を描きますか?

(1)今回の対象外となるものをすべて描き出します。
これは外部要素となるものです。それは取引先だったり、外部システムだったりします。

(2)そして外部要素への入出力を描きます。(これは対象外への最終的な入出力となります。)

(3)データフロー名は必ず書くようにしてください。
プロセス名を入れたいかも知れませんがプロセス名は無くても大丈夫です。(後で入れられるし、変わるかもしれないので)

(4)今度はデータフローをよく見ていきます。
足りないデータフローがたくさんあるはずですから、図にどんどんデータフローを足していきます。
また、データフローが変換されるところや複数に分岐するところにはプロセスも足していきます。
そうやってどんどん書き足していくと、データを保管する所も見えてきますのでデータストアも書き足していきます。
そうやって、描き替えながらユーザとどんどん対話してください。
(引用終了)

DFD(データフローダイヤグラム)の描き方(3) | ステキな一日

(引用開始)
DFDを書くうえで一番重要なのがデータフローの名前の付け方です。
データフロー名の付け方によってDFDの分かりやすさはかなり違ってきます。
ここが一番肝心かなめのところですから手を抜かないようにしてください。

プロセスに名前を付ける段階ではデータフローのすべてに名前が付いてなければいけません。
はじめにプロセスに名前を付けたいかもしれませんが、ぐっと我慢をしてください。
プロセスに最後に名前を付けるのは、データフローを正しく書くために必要です。
(中略)
プロセスに先に名前を付けてしまうと、DFDを書けてしまった気になって肝心のデータフローがおろそかになったり、分析が足らなかったりしますので、注意してください。
(中略)
エクセルの図形で描いてもいいのですが、それでは書き直しが面倒になってきて、かなり出来の悪いDFDしか書けないと思いますのであまりおすすめできません。
それよりは手書きの方がマシだし、それともVISIOでも良いです。 
個人的にいちばんおすすめなのが astah* professional というソフトウェアです。
(引用終了)

DFD(データフローダイヤグラム)の描き方(4) | ステキな一日

(引用開始)
DFDにセットで必要になるものがあります。それがデータディクショナリーとミニ仕様書です。

データディクショナリーには、データフローの内訳を記述します。
そして、ミニ仕様書にはプロセスの内容を記述します。DFD、データディクショナリー、ミニ仕様書が揃ってひと塊となります。
どれが欠けても中途半端です。
(中略)
しかしながら、これもまた、DFD、データディクショナリー、ミニ仕様書を行ったり来たりしながら、ブラッシュアップさせていくものです。
(引用終了)

DFD(データフローダイヤグラム)は業務システム設計でよく使うけれど、何故か描きにくい、と思う時が多かった。
缶アイコンのデータストアは書けるのだが、プロセスがイマイチしっくりこない時が多い。
上記の記事を読んで、プロセスを最初に書いてしまうので、それに引きずられて、本来のモデルが描けなくなっているのではないか、と気づいた。

「プロセスの名前は一番最後に書く」。
つまり、外部要素やデータフローをじっくり書き込んで、漏れを無くし、整合性を取った後で、最後にプロセスの名前を書けばよい。
DOAでは、データが主であり、プロセスは従の立場だから。
プロセスは最後に名前付けすることで、データの入出力やタイミングに集中して分析できるようになる。

これから気をつけようと思う。

| | コメント (0)

«Redmineの次期バージョン3.4の見所