« 小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart2 | トップページ | カンバンはステータス名が大事 »

2021/01/02

RedmineをPJ管理ツールと呼ぶのは嫌いだ、Redmineはチケット管理ツールと呼ぶべきだ

RedmineをPJ管理ツールと呼ぶのは嫌い。
「Redmineはチケット管理ツール」と呼びたい。

【1】PJ管理ツールと呼びたい場面では、プロジェクトマネージャーやPMO、経理部門、経営層が各PJの進捗・課題・コスト・品質管理を常に監視したい欲求がある。
彼らは、ソフトウェア開発の案件は常に赤字のリスクにさらされているのを身を持って知っているので、プロジェクトリーダーの定性的なPJ報告を信用していない。

プロジェクトリーダーは、PJ途中まで、進捗も問題ありません、と言いながら、リリース間近になって、品質が悪くて進捗が大幅に遅延しました、というPJ報告が多すぎるから。
プロジェクトリーダーも、90%症候群に慣れている。

よって、PJ管理ツールを全社に導入して、各PJのQCDを可視化し、常時監視できる状態にしたい。
すると、PJメンバーは毎日、PJ管理ツール上で、詳細化されたWBSに進捗率と実績工数を入力するように躾けられる。

一般に、高価な有償パッケージ製品のPJ管理ツールを導入して、社員だけでなく、内製開発にいる準委任契約の協力会社メンバー(BP)にもその運用を強制させる。
それにより、毎週・毎日のPJ報告では、進捗や原価は自動計算できるから、理論上は、毎日、PJ報告を提出させることで、PJのEVM、原価と粗利、営業利益を出力させることはできる。

でも、実際にそんな運用をしたら、メンバーの進捗・工数入力の作業負荷が大きくなり、肝心のPJ作業時間が削られるので、そこまではやらないのが普通。

【2】しかし、PJ管理ツールの真の問題点は、PJメンバーのやる気を下げる点だ。
PJ管理ツールの目的は、PJのQCDの可視化であり、経営層や経理部門、間接部門にメリットがあるだけ。
大多数のPJメンバーの気持ちは全く考慮していない。

大多数のPJメンバーは、PJ管理ツールにデータを入力するだけの役割であって、PJ管理ツールやその運用を改善しようというインセンティブは働かない。
一般に、PJ管理ツールではユーザの権限制御が厳しく、一般のPJメンバーには、PJの採算情報はもちろん、メンバーの月額単価のようなマスタ情報にアクセスできないようにしているので、彼らが触るメニュー画面は、制限された機能が少しだけ載せられているだけであり、非常に貧弱な機能に過ぎない。

つまり、PJメンバーから見れば、PJ管理ツールは単なるデータ入力基盤に過ぎず、面倒なシステム以上のものではない。
ゆえに、PJメンバーにとって、PJ管理ツールを使いこなす動機やインセンティブがない。

【3】一方、Redmineのような自由なチケット管理ツールであれば、PJ管理ツールのデータを自分たちで分析しよう、そこからプロセス改善していこう、という仕組みを作れる。
「チケット駆動開発は、メンバー全員でチケットを消化していくゲーム」という雰囲気を醸し出せるからだ。

PJの外側にいる利害関係者たちのRedmineではなく、PJに実際に関わっている開発者のためのRedmineであれば、自分たちのPJをより良くしていくための仕組みとしてRedmineの豊富な機能を有効活用できる。

【4】僕もRedmineやプロセス改善に長年関わってきて、Redmineの優れた機能やUIを、PJのQCDを把握できるPJ管理ツールに発展させていく方向性を考えてきたし、Redmineの最終形は案件のQCDを管理するためのERPへ発展していくだろう、と考えていたこともあった。
しかし、ERPのような機能を盛り込んでしまうと、Redmineの良さがどんどん失われて、せっかく自分たちで作り上げた開発プロセスが、他人が押し付ける開発プロセスに変化してしまい、PJメンバーのモチベーションが落ちていく現象も何度も見てきた。

だから、RedmineをPJ管理ツールと扱うのは嫌いだ。
Redmineはチケット管理ツールとして扱うべきだ。

【5】そういう経験を振り返ると、Redmineは、外部のステークホルダーの為のPJ管理ツールというERPの側面と、PJ関係者の為のチケット管理ツールの側面の2つがあり、それらを同時に実現するのは難しいと考える。
現実としては、それぞれの役割を3層構造のシステム・オブ・システムにシステム分割する方向性ではないか、と考える。

たとえば、
View=チケット管理で進捗・課題・障害管理(QD)=Redmine、
Model第1層=コスト管理(C)=原価管理システム、
Model第2層=社内の会計システム
みたいな3層構造にする。

理由は、PJ関係者、PMOやSEPGや品質保証部門、経理部門や経営層の3つの役割ごとに、PJ管理ツールを使う目的が異なるからだ。
チケット管理に特化したUI層と、PJのQCDを見たい層、PJの原価や採算を管理したい層、の3つに分けて、Redmineで入力されたデータが裏では自動連携される仕組みになるべきだ。
そうすれば、PJメンバーのモチベーションやインセンティブが損なわれず、活発にプロセスを改善していく雰囲気を維持できるだろう。

そんなことを考えると、PJ管理ツールは最終的には、SAPのような会計システムと連動すべきERPの機能の一部と見なせる一方、RedmineはそういうERPに統合させるべきではない、とも考えている。

|

« 小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart2 | トップページ | カンバンはステータス名が大事 »

Redmine」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« 小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart2 | トップページ | カンバンはステータス名が大事 »