« プロダクトマネージャに必要なスキルは何か?~「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法」の感想 | トップページ | @kawakawaさんの「C#実装から見るDDD」資料が素晴らしい #dddosaka »

2014/10/08

ワークフロー改善はBPRと同じ

官公庁の業務システム改革に関するCIOの話と、Redmineによるプロセス改善の話が妙に似ているなあ、と思ったのでメモ。

【参考】
「わからないからわかるようにしてくれ」:日経ビジネスオンライン

syotaroさんはTwitterを使っています: "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 »

Agile」カテゴリの記事

Redmine」カテゴリの記事

ソフトウェア工学」カテゴリの記事

チケット駆動開発」カテゴリの記事

プロジェクトマネジメント」カテゴリの記事

コメント

コメントを書く



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


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



« プロダクトマネージャに必要なスキルは何か?~「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法」の感想 | トップページ | @kawakawaさんの「C#実装から見るDDD」資料が素晴らしい #dddosaka »