Redmine導入はERP導入に似ている #tidd

Redmine導入はERP導入に似ているなと思ったのでメモ書き。

【元ネタ】
Twitter / @akipii: @naitoh Redmineを導入しても、ガントチャートのPDFや課題一覧のExcelを綺麗に出したい要望はPM層に多いです。Redmine導入はERP導入に似てますね。顧客と同様、PMも帳票(紙)にこだわっている。#redmine

Twitter / @akipii: @naitoh 僕もはまりました。でもRedmine XLS Export pluginは苦労してインストールする価値があります。チケットの属性を選んでExcel出力できるので、課題一覧が欲しいPMにうってつけです。#redmine

Twitter / @akipii: Redmineを導入して使いづらいと言う人達は、アンチパターンの罠にはまっている時が多い。この辺りの事例をまとめてみたい。チケット駆動開発は最終的にはアジャイル開発をサポートするインフラになると思う。#redmine

Twitter / @akipii: @cointoss1973 運用例を知らずにアジャイル精神を伝えて分かるようなら苦労しない。逆にRedmineのバージョン単位に小規模リリースする運用が何故Agileの概念と密接に絡むのか説明しなければ、アジャイルごっこに過ぎない。理念と実装の両方が必要でしょうね。

【1】ユーザ企業がERPを導入して業務改善する事例は、90年代のBPR(Business Process Reengineering)から始まり、EA(Enterprise Architecture)やSOAなどまで、たくさんのバズワードが出ては消えていった。
実際の所、ERPを導入して確かに業務がシステム化されたとしても、それですぐに効果が出るとは限らない所が多かったのではないか？

ERP導入の前に一番最初にやる重要な作業は、Fit And Gap分析だ。
つまり、実際の業務(AsIs)をERP(ToBe)へマッピングした場合、ERPで実現できる業務と、ERPで実装されていない業務を分別して洗い出し、カスタマイズして実装すべきか、もしカスタマイズするならどれくらのコストがかかるのか、を分析する。

フィットギャップ分析 － ＠IT情報マネジメント用語事典

このFG分析は正直かなり難しい。
実際の業務は大企業になるほど膨大で、ユーザ企業の情報システム部門が全てを知っているとは限らない。
現場でヒヤリングしてみると、その現場特有の運用ルールで回していたり、特定の社員のスキルに依存していたりする。
また、ERPはパラメータで業務を浅く広く対応できるようにしているから、どのパラメータを使えば、ユーザ企業の業務を実現出来るのか、を探るために、ERPのかなり深い仕様まで知り尽くさないといけない。

そして、ERPで実現できない業務が曲者だ。
ERPは欧米生まれのソフトが多いので、日本特有の商習慣は無視されている。
ERPにない仕様で有名なのは多分締め処理で、日本企業のためにローカライズして実装している場合が多いだろう。
すると、カスタマイズの工数が膨れ上がり、現場にせっかく導入しても、使いづらいとか、帳票が対応してない、とか色々と苦情が更に出てくる。

そして、FG分析だけでなく、導入効果を測定することもERP導入では重要だ。
何故なら、高価な業務ソフトを導入して、どれだけの売上が増えたのか、どれだけコストを削減できたのか、を数値で表現できなければ、ERPを単に導入しただけで終わってしまう。
つまり、ERPで効率化していくには、当初の目標と導入後の効果を比較して、更に原因を突き詰めて、業務を改善していくPDCAサイクルが必要。
多分、普通はバランス・スコアカードのように、各種の視点で評価する指標(KGI)を定めて、測定するだろうと思う。

すなわち、ERP導入は単なるシステム化ではなく、実業務に関わる人員コストの削減と自動化を図り、更に経営に役立つデータを提供して、業務を改善していくという目的がある。

【2】Redmineを導入してみると、うまく運用できていないチームを見たり聞いたりする。
その事情を探ると、Redmine導入の失敗事例は、ERP導入の失敗事例に似ているなあと思う。

Redmineを導入して失敗する理由はいくつかある。
一つは、自分たちの開発業務とRedmineの間のフィットギャップ分析ができてないこと。

ERPですら、自社の業務を全てカバーできるはずが無い。
必ずERPのカスタマイズが必要で、コストを掛けてでも実装するのか、あるいは手作業で従来通り運用するのか、運用設計するのが大事。
つまり、ERPカスマイズのコストと従来通りの運用コストを天秤にかけている。

Redmine導入もERP導入と同様だ。
自分たちのチームの開発業務を全てRedmineへマッピングできないだろうから、どの業務がRedmineで実現できないのか、その業務はRedmineをカスタマイズしてでもIT化するのか、それとも従来通りExcelの運用でカバーするのか、という意思決定を下さねばならない。
そもそも、自分たちの開発の業務フローを分析出来ていないチームが多い。
実際、Redmineのトラッカーは業務のワークフローに相当するのですがどれだけの業務がありますか、と質問すると、答えが返ってこないチームがとても多い。

更に、業務をIT化することによって、今まで人に依存していた作業がなくなり、体制そのものも変わってしまう事実を知らない人たちも多い。

ERP導入によって、経理事務の女性の仕事は全て、単にPC上で数値を入力する派遣社員に変わり、経理事務の社員の仕事はそれら仕訳データの整合性をチェックする仕事に変わった。
同様に、Redmineを導入することによって、Excelで管理していたたくさんのドキュメントが全てWeb化され、メンバー自身で更新する運用になることによって、現場リーダーやプロマネの仕事は、メンバーの進捗管理ではなく、チームの課題や潜在リスクを解決してメンバーの開発をサポートする方向へ変わってしまう。
つまり、管理者の仕事の中身も役割も大きく変わってしまう事実に気づかない人たちが多い。

ERP導入で開発ベンダーがよくはまる罠は、ユーザ企業から帳票のレイアウトを変えて欲しい、という要望を受ける時だ。
何故か日本企業は帳票のレイアウトにとてもうるさく、その要望を受け付けると、なかなかOKの返事がもらえない。ユーザはフォントやレイアウトにとてもこだわる。
会計帳票は特にそうだ。
とはいえ、帳票のカスタマイズは普通は必須だし、そこでお金がもらえるので、ありがたく受け取るときも多いが。

Redmine導入でも、PM層から帳票やExcelに関する改善要望はとても多い。
彼らは、顧客へ提出するガントチャートのPDFや課題一覧のExcelを綺麗に一発で出して欲しいらしい。
そんな見た目の話よりも、開発業務の効率化や自動化、Agile化に注目して欲しいのに。

但し、RedmineはRailsで作られているので、プラグインやパッチによって簡単に機能改善できるのが魅力の一つ。
PM層からあげられた改善要望は、Railsで実現してしまえばいい。

【3】もう一つは、Redmineを導入して効果が上がったかどうか判定する指標がないので、Redmineを単に使うだけになってしまい、Redmineによって自分たちの開発業務を改善していくPDCAサイクルが生まれないこと。

障害管理ツール(BTS)をそもそも使っておらず、Excelで管理していたチームは、今日は何件のバグが発見されて解決されて、リリースされたのか、という報告すら、すぐに回答が来ない。
Excelの一覧は集計しづらく、そもそも最新化されていなければ、メンバーに逐一確認しなければならない。
だから、現状の指標を設定することすらできてない。

RedmineなどのITSの利点の一つは、システムの品質の指標や、予定・実績工数の集計による進捗の指標を簡単に取得出来ること。
メンバーにチケット入力の運用ルールを徹底できれば、DBに貯められた情報を色んな観点でSQLで取り出せばいい。
信頼度成長曲線(時系列のバグ累積数)やバーンダウンチャート(残のPVと残のEV)などは、ITS上で簡単に実現できる。

そして、これらの指標をメンバーと共有して、自分たちの運用ルールを改善していくのが大事。
毎日の作業履歴を色んな観点で集計して、リアルタイムに見える化すれば、どこに問題があるのか、PMだけでなくメンバーでも気づく。
ここでは、KPTによるチームでのふりかえりが効果的だ。
Problem(問題)の発掘も大事だが、Tryで是正対策や予防対策を考えることも大事だし、Keepとして、今後も続けていきたい運用ルールを確認することも大事。
ふりかえりが上手なチームは、Problem→Try→Keepの流れで問題が解決して、運用ルールというナレッジとして蓄積され、最後は暗黙知としてKeepから消える。

個人的には、Redmineをいきなりソフトウェア開発のタスク管理全般に導入するのではなく、テスト工程の障害管理から導入した方が安全だと思う。
まずは、障害管理のワークフローにメンバーが慣れてもらって、そこで進捗管理や品質管理の技術を身に付ける。
そして、チケットを障害だけでなく、改善要望やリリース作業、新規開発へ少しずつ広げていくのが無難だろうと思う。

Redmine導入に関する事例集は、ERPの失敗事例のように集めてみたい。