Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例
Redmineのようなチケット管理ツールがとても威力があっても、上司や経営者が見なければExcelがはびこってしまう事例を見かけたのでメモ。
チケット管理ツールに限らず、営業支援システム、日報システム、経営状況の見える化の為の情報系システムでも同様の症状がよく発生する。
【参考】
golangでRedmineの情報をExcelにするコマンドラインクライアントを作った - write ahead log
Big Sky :: コマンドラインからredmineを扱える「godmine」作った。
【1】(引用開始)
SIerに所属している方ならわかると思いますが(あんまりわかって欲しくもないですが),体質の古い会社だとRedmineを使っていても「Excel表がない」と文句を言われたりします.
面倒なのが「プロジェクト一覧表がない」とか「課題管理表がない」とか「バグ一覧表がない」とか....etcです.
実装担当者はRedmineを使う運用で問題なかったりするのですが,役職持ちの方から「Redmineはわからないから」とか「移動中にExcelで見たいから」などと言われると断れないのがサラリーマンの辛いところです.
あとは受託だとユーザとか元請にRedmineを強要できないので結局Excelになったりします.(しません?)
(引用終了)
【2】Redmineのようなチケット管理ツールを、開発チームがボトムアップで使っているのではなく、上司や経営者が上から目線で導入させたとしよう。
すると、Redmineは確かに現場に導入されるが、現場ではRedmineが必要で導入したわけではないから、なかなか根付かない。
一方、Redmineが普及して、会社の上司や経営者もPJ状況を見て欲しい、と思ったとしよう。
しかし、部課長や社長クラスの人は、管理作業や営業などで忙しすぎるので、Redmineをわざわざ触って、見る暇もない。
むしろ、メールで報告させたり、Excelを送ってもらって、印刷したプリントで見た方が楽だったりする。
すると、上司や経営者から、Redmineを見るのは面倒なので、メールで報告してくれ、とか、ExcelでPJ状況を出してくれ、と言われたりする。
そのための進捗報告書を作成するのに、プロジェクトリーダーは無駄な工数がかかったりする。
せっかくのRedmineが、上司や経営者の目には届かないのだ。
【3】その状況は、営業支援システムの事例でも聞いたことがある。
営業マンが顧客にアポを取ったり、契約状況を記録するために、営業支援システムを作り、営業担当者に日報を書かせて、上長がその日報を読んで管理できるような素敵なシステムを開発した。
しかし、営業部の課長クラスは、自身も営業しているし、打合せも多いので、営業支援システムにわざわざログインして、大人数の営業担当者の日報を毎日読む暇もない。
すると、営業担当者にとっては、日報入力という無駄な作業が増えているのに、その日報を上司が少しも読まないし、反応もない、と分かると、誰も営業支援システムを使わなくなった、と。
結局、メールやExcelベースの情報連携に戻ってしまった、という事例。
他にも、ERPに蓄積された財務情報やPJ情報を経営者向けに見える化したい、という情報系システムを多額の資金を投資しして開発したものの、経営者はそんなにシステムに明るくないし、システムの操作も最初から覚えるのは面倒なので、結局使われない。
すると、大金をはたいた、経営情報の見える化システムも使われなくなってしまう、という話もよく聞く。
【4】結局、会社の上司や経営者が、情報系システムを使いこなさなければ、現場に定着しない、という身も蓋もない話。
経営者向けの情報系システムは、大金をはたいた割りには、使用頻度が低く、誰も使わないシステムになりやすい。
いくらBIツールでビジュアルに見える化したとしても、彼らはそもそも情報系システムを使いこなそうという動機はさらさらないのだ。
個人的には、古い頭の日本の大企業に多い症状のような気がする。
そんなことをふりかえると、「見える化」という言葉は経営者は大好きだが、実際に使いこなせていない場合がすごく多い。
むしろ、現場主導で、自分たちの現場がやりやすいように、使いこなした方が賢明だ。
無駄なメトリクスの抽出、見える化プログラムの実装は、不要だと思う。
【追記】
言いたかったのは下記のコメントの通りかな。
はてなブックマーク - 岡崎良徳 のブックマーク - 2016年7月23日
(引用開始)
見ないものを見える化するのは無駄だよね、というお話。
(引用終了)
【追記2】
アカベコマイリさんが詳しい運用ルールを説明されている。参考になる。
| 固定リンク
« 有効な併買ルールを見つけ出すバスケット分析のアルゴリズムのリンク | トップページ | 第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」の感想 »
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「Redmine」カテゴリの記事
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
「ソフトウェア工学」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
「チケット駆動開発」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
コメント