「非エンジニアにこそオススメしたいプロジェクト管理ツールRedmineの導入から運用まで 」の記事が素晴らしい

「非エンジニアにこそオススメしたいプロジェクト管理ツールRedmineの導入から運用まで 」の記事が素晴らしいのでメモ。
Webサービス業界でRedmineをプロジェクト管理に使った場合の事例や注意点が記載されていて、とても参考になる。

【参考】
非エンジニアにこそオススメしたいプロジェクト管理ツールRedmineの導入から運用まで - coach4pmの中の人

akipiiさんのツイート: "これは良い記事。編集部の原稿管理の事例、チケットの粒度はすごく参考になる。RT @chitoseweb: 非エンジニアにこそオススメしたいプロジェクト管理ツールRedmineの導入から運用までのポイントについて書きました。https://t.co/zQJ5LF2qd0"

岡崎 良徳 @中野のSEOコンサルタントさんのツイート: "記事の入稿管理とかにも使えるかな…／非エンジニアにこそオススメしたいプロジェクト管理ツールRedmineの導入から運用まで - coach4pmの中の人 https://t.co/sKm4bZfcq6"

akipiiさんのツイート: "名前がカッコイイのか。 @okachan_man: 関係ないけど「Redmine」って名前がかっこいい。 / “非エンジニアにこそオススメしたいプロジェクト管理ツールRedmineの導入から運用まで - coach4pmの中の人” https://t.co/3xHeixlFLE"

akipiiさんのツイート: "@chitoseweb 非エンジニアのRedmine 運用事例はすごく参考になります。1チームと1プロジェクトの対応は、プロジェクト型組織は当たり前なのですか、最近はサポートデスクや製造業のような機能別組織でも有効と思います。"

【1】たとえば、「Redmineの設定の柔軟さが、非開発部門の業務に適用できる最大の理由」として、下記が挙げられている。

(引用開始)
(1)現状と予定が可視化される
(2)業務プロセスが体系化される（ワークフローが設計できる）
(3)作業履歴が残るため、担当者が変わった際のタスク移行や、あとからの振り返りがしやすい

これは開発部門に限らず、どんな組織にも求められるものではないでしょうか。
Redmineは設定が非常に柔軟にできて、また様々な拡張機能も提供されているため色々な状況に対応できます。
僕が知っている限りでも、Webサービスのカスタマーサポートや、編集部の原稿管理などで活用している例があります。
裏を返せば、自由にできる設定をうまく活かしきれないと無用の産物になってしまうということです。
(引用終了)

換言すれば、下記に相当するだろう。

(1)作業の予実管理、そこからボトルネックや進捗状況をリアルタイムに把握できる(見える化)
(2)業務プロセスが状態遷移図として可視化される(いわゆるビジネス・プロセス・リエンジニアリング(BPR))
(3)チケットやWikiに履歴が残るので、担当者がいなくなっても、作業の発生理由や仕様変更の経緯などを追跡できる(トレーサビリティ)

つまり、RedmineをSI業界における受託開発案件の進捗管理だけでなく、非IT業界におけるデザイナー・事務担当者・サポートデスクのオペレーターなど、一般ユーザのタスク管理にも上記の利点を実現できるのだ。

【2】「Redmineを適切に設定するために、まずは構造を理解しよう」では、Redmineの機能と運用プロセスの対応について説明がある。

(引用開始)
・作業はとにかくチケットに起票。起票されていないものはやらない
・必ず、ボールを持っている人を担当者に設定する
・完了基準を決める
・その他細かい設定は最初からしない
(引用終了)

いずれもチケット駆動開発のプラクティスである「No Ticket, No Work」「Doneの基準」「ペア作業」に相当するだろう。

特に参考になる点は、「プロジェクトの粒度、チケットの粒度はどうする？」の部分だ。
記事では、「プロジェクト＝チーム」「タスク＝確認者が確認する単位」を推奨している。

【2-1】前者のメリットは、「現実世界とRedmineの世界がおおよそ一致することになり、適切なプロジェクト粒度で運用しやくなることが多いです」。
つまり、Redmineプロジェクトが一つのチームのタスク管理に対応付ければ、一つのチームの世界は一つのRedmineプロジェクト内に閉じているので、そのプロジェクトだけ見ればいい。

個人的に最近思うのは、非IT業界では、機能別組織になっている組織が多く、ソフトウェア開発チームのようなプロジェクト型チームではない場合が多い。
例えば、受注する担当者は営業部、資材や原材料を効率的に発注する購買部門、ユーザからの問合せに対応するサポートデスク、などのように、一つの役割だけを担当している組織に属する人は、自分の組織以外で流れている業務の流れまで意識していない。
すると、組織をまたがる作業や情報連携は、自分の責任でないから知らない、責任は取れない、と言うディフェンシブな姿勢になりがちで、業務の流れが凄く悪くなる。

しかし、Redmineでチケット管理するようになると、チケットを通じて、他部署の依頼を受け付けたり、他部署に対応を依頼するエスカレーションの業務フローが明確になるメリットがある。
つまり、チケットの背後にあるワークフローによって、誰がその作業を承認して責任を取っているのか、が明確になるし、情報連携も自然に行えるようになる。

SI業界はプロジェクト型チームや事業部制が多く、一つの案件は期間限定で、案件が終われば解散してしまう場合が多い。
そんな場合にRedmineは履歴が残るので有効なのだが、機能別組織のように、組織が分断されているために担当者の意識もタコツボになっている状態であっても、Redmineがその雰囲気を打ち破り、情報連携しやすくなるような仕掛けを用意している事例を見かけるようになってきた。

【2-2】「タスク＝確認者が確認する単位」は、Doneの基準を「完了ステータスに決断できる範囲にとどめる」ということだろう。
特に、作業者の観点ではなく「確認者」の観点にすべき、という点はとても参考になる。

(引用開始)
この考え方はあまり言及している人がいないようなのですが、作業者の視点ではなく確認者の視点でチケットの粒度を考えると、自然に適切なチケット粒度になると考えています。
完了条件を明確にしようという内容を先ほど書きましたが、多くの場合は誰かが最終確認をすることでチケットが完了します。
確認者の確認単位でチケットを起票しておけば、完了条件とチケットの粒度が合致して上手に運用できます。
(引用終了)

チケットの粒度は、僕もいつも判断に迷うテーマだ。
どの会社でも、どの部署でも、どのチームでも、チケットの粒度は個性豊かで、一つの基準には定まらない。
たとえば、僕がアジャイル開発をやっていた時は、タスクカード単位だった。
一方、ソフトウェア保守の時は顧客の要望や障害などのストーリーカードの単位、事務処理のワークフローでは1個の申請書の単位だった。
つまり、それぞれの業務、開発の状況に応じて、チケットの粒度は観点が全く異なる。

但し、チケットの粒度は完了基準と大きく連動する。
チケットを完了する人が誰であるか、完了にする基準は何か、という点を明確にする必要がある。
それは作業者の観点ではなく、その作業を承認する人の立場で決めるべきなのだろう。

【3】最近は、RedmineがIoT企業に異常にマッチしてしまった話 - 僕のYak Shavingは終わらないの記事や今回の記事のように、Redmineのチケット管理の運用事例で、他の業界でも参考になる話が多い。
次回の東京Redmine勉強会は既に満員御礼なのだが、次々回で話してくれないかな、とか思ったりする。