ワークフロー改善はBPRと同じ
官公庁の業務システム改革に関するCIOの話と、Redmineによるプロセス改善の話が妙に似ているなあ、と思ったのでメモ。
【参考】
「わからないからわかるようにしてくれ」:日経ビジネスオンライン
BPRとは 〔 ビジネスプロセス・リエンジニアリング 〕 【 Business Process Re-engineering 】 - 意味/解説/説明/定義 : IT用語辞典
【1】官公庁や大企業の業務システムは、とにかく業務が複雑だ。
過去のしがらみ、法律、社内の歴史で蓄積されたノウハウや膿がたくさん積もり積もって、現在の業務が出来上がり、その業務を実現するようにIT化しただけのシステムが多い。
すると、何故こんなに複雑なワークフローや画面項目、帳票を増やしているのだろう?と思う時が多い。
業務をIT化する場合、今ある業務をそのままコンピュータに載せるわけではなく、業務フローの改善も実は含まれている。
IT化によって、無駄な作業が自動化され、必要な担当者が減るからだ。
すると、不要な担当者のいる組織の仕事がなくなり、組織構造をスリム化するような影響を与える。
最終的には、IT化は、業務の変革を通じて、組織の改革までやり通さなければ、意味が無い。
これが、BPRになる。
しかし、日本の企業も官公庁も現場が強いので、IT化で人減らしになったとしても、組織構造はそう変わらない。
看板だけ変えただけで、組織構造がスリム化しない場合が多い。
だから、IT化によって、逆に紙の帳票が増えたり、ワークフローが逆に煩雑になったり、業務システムを回すために人出が逆に増えたりすることもある。
本末転倒だ。
笑ってしまうようだが、実際の現場ではよくあることだ。
しかも、官公庁も大企業も予算で動く。
予算が確保されないと、業務システムの開発が始まらない。
普通は1~3月にかけて、来年度の予算枠が確定し、4~5月に実行稟議があって、6~7月にようやく予算を使ったシステム開発が行われる。
すると、受託システム開発を1年の枠で提案したのに、実は9ヶ月で実施しなければならない、といった本末転倒な事態になりやすい。
日本人は変な所で几帳面すぎるので、融通が利かない。
皆おかしいと思いながらも、仕方ない、と思って、従来のまま仕事している人が非常に多い。
本来は、IT化によって、業務を効率化し、抜本的に見なおし、組織構造も変えていくべきなのだ。
業務システム開発は最終的には、BPRの課題が含まれていなければ、システム化の効果が出ない。
【2】Redmineでチケット管理していると、ワークフローやカスタムフィールドがどんどん増えていく。
最初は1つのチームで運用すればよかったから、シンプルなワークフローで十分。
しかし、他チームもRedmineを使ってみたい、と言い出して、Redmineの運用が拡大していくと、他チームのやり方を反映したワークフローやカスタムフィールドが増えていく。
トラッカー名が違うだけで、ワークフローもチケット項目も一緒なのに、何故、そんなにトラッカーを増やすのか?
そんなにたくさんのステータスを増やして、ワークフローをスタンプラリーにして、本当に回るのか?
そんなにたくさんのカスタムフィールドを増やしても、どうせチケット集計しないくせに、何故増やすのか?
入力が大変になるだけなのに。
IT化は、従来のワークフロー、つまり開発プロセスの変革を伴う。
従来の開発プロセスが見える化されるのは良いが、それをそのままRedmineに実現するだけでは、BPRにはならない。
Redmineにおける開発プロセスのあるべき姿を実現しなければ、既存のAsIsの開発プロセスをそのままRedmineに乗せただけで、抜本的な改革にはならない。
本来は、思い切って、従来の開発プロセスを廃止したり、既にRedmineで定義されているワークフローに、PLもSEもPGも合わせるべきなのだ。
とは言え、そういうノウハウは、実際にRedmineで試行錯誤しなければ、実感できないだろう。
僕も、過去6年間、あちこちの現場にRedmineを作っては、運用を他の人に譲り渡し、Redmineにはまって、Redmineを使いこなすことでどんどんプロジェクト管理能力を上げていくプロジェクトリーダーを見てきた。
一方、ワークフローやカスタムフィールドが野放しに増えていき、後で収拾がつかなくなるようなRedmineも見てきた。
だからこそ、今になって思うのは、自分の中で、Redmineの運用のあるべき姿を持つことが一番大切だと思う。
そして、そのイメージを周囲の人達に問いかけて、普及すべきだと思う。
「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」にあるエヴァンジェリストのような役割で、どんどん広げていくべきだと思う。
僕の中では、Redmineによるチケット駆動開発を通じて、完全チケット方式によるアジャイル開発に移行すべきだ、と思っている。
| 固定リンク
« プロダクトマネージャに必要なスキルは何か?~「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法」の感想 | トップページ | @kawakawaさんの「C#実装から見るDDD」資料が素晴らしい #dddosaka »
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」の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)
「Agile」カテゴリの記事
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
コメント