IT部門主体のプロジェクトを救済したい！
イマドキのシステム構築
ITシステムが普及する前の製造メーカーでは、図面を手書きし、その図面をコピーして製造部門へ出図し、
部品を購入するための注文書を書いてFAXや郵便で送付し、入荷された部品の在庫を手書きの台帳で管理していました。
書き間違いをしないように細心の注意を払い、配付や郵送によるタイムラグを少しでも埋めるべく担当者同士が
コミュニケーションを取り、それぞれの業務が滞らないように様々な工夫がされていたと聞きます。
今となっては想像もできないですよね。
現在は、ITが普及し始めて数十年が経ち、製造メーカーには、技術情報管理システム・生産管理システム・在庫管理システム
など多くのシステムが導入され、それらを使って日々の業務が行われています。
「システムがなくては仕事ができない」とまで言われるほど、当たり前のようにシステムと業務が一体になっていますが、
今使われているシステムは導入当初から今の形だったわけではありません。最初は作るIT部門も要件を出す業務部門も
ゼロからのスタートで、システムが稼働してから試行錯誤しながら改良を繰り返し、長い年月を経てシステムとその
周辺業務が成熟していったのです。
では、イマドキのシステム構築には何が求められるのか。
それは、「今の状態」を当たり前として、既存システムや周辺業務の成熟度を維持した上で、新しい仕組みや機能が
求められます。そしてその裏には「IT技術が向上しているから既存システム以上のものが作れるはず」という暗黙の
期待値があるのです。
でも、その期待に応える環境は整っているのでしょうか・・・？
“今”がワカラナイ
イマドキのシステム構築には、「既存のシステム・業務の成熟度を維持しつつ、新しい仕組みや機能」が求められます。
「IT技術が向上しているから既存システム以上のものが作れるはず」これは業務部門の期待値であり、IT部門の過信でも
あると思います。IT技術が進化すれば、夢のようなシステムが出来上がり、業務部門の業務が劇的に改善されるのか。
その答えは言うまでもないですよね。システムと業務は相互に試行錯誤を積み重ね、成熟していくもの。
既存を踏襲しつつ新しいシステムを構築するには、進化したIT技術の活用だけでなく、“現状のシステムと周辺業務の理解”が重要なファクターになります。
ところが、実態は「現状を理解」することが非常に困難になっていると感じます。
IT部門は、既存システムが複雑化し過ぎて要件や仕様が分からなくなっていたり、また、IT技術者として開発スキル向上に
努めてきた結果、業務の知識と興味が希薄になったりしていませんか？一方、業務部門は、組織や役割の縦割りが進み、業務が
分担された状態になっていたり、また、システムありきの仕事の仕方が定着し、その背景や理由が分からなくなったりしていませんか？
“今”のシステムと業務が、業務でやりたいことをシステムで実現したのか、システムの制約で業務のやり方が決まったのか、
この切り分けが難しくなっていると言えます。つまり、業務要件からシステムを引きはがせないから、既存システムの機能をそのまま
踏襲してしまう、ということになってしまうのです。
そしてIT部門は疲弊する
「現状のシステムや業務の理解」が難しいとなると、どうやって新しいシステム構築を進めて行ったらいいのでしょうか。
その一つの打ち手として、「IT部門が主体となりプロジェクトを牽引する」というやり方を取られているケースがあります。
IT部門の方が、業務部門から業務要件を引き出し、「どうやって業務をするのか」を一緒に考えて、システムの機能へ
落とし込んでいくという方法です。限られた時間の中で、現状の業務のやり方を教えてもらいながら、業務部門の要望を聞き、
現実的な落とし処を見極めながら、機能仕様を作り込んでいくことになるのですが、これが大変です。例えば、業務部門の方に
ヒアリングを行う時、業務部門の方は日々やっている業務なので「言わなくても当たり前」ということを省いて話をされることが
多々あります。そうすると話を聞いたIT部門の方は正しく理解できず、「IT部門の人は業務を全然わかっていない」と言われてしまったりします。
また、業務部門の方はプロジェクト経験が少なく何をしたらいいかわからないので、IT部門の方が業務部門の活動を牽引し、啓蒙をしていく必要もあります。
IT部門はシステム開発や周辺システムとの連携など、やるべきことが山積みにも関わらず、業務部門の業務を理解し、
サポートをしなければいけないという二重の役割を担うことになり、疲弊してしまうのです。
プロジェクトには両輪が必要
二重の役割を担うIT部門が疲弊し、プロジェクトが停滞する・・・これはIT部門にとっても、業務部門にとっても、その企業にとっても不幸なことです。
特にIT部門は一生懸命に取り組めば取り組むほど、疲弊してしまうという悪循環にはまってしまいます。
これを解消するためのIT部門、業務部門に次ぐ第三のスキームは、IT部門が開発の役割を持ちながら業務部門をサポートするのではなく、開発メンバーとは
別の人が業務側にサポート役として入り込み、業務部門をIT部門と横並びの位置付けに引き上げることです。
そうすれば、ITと業務の両輪となり、PMOを中心にプロジェクトを正常に前に進めることができるようになります。
業務部門のサポート役に求められる条件は５つです。
①業務部門の方と同じ目線で業務設計をすることができる。
②プロジェクトの経験がある。
③システム構築の基本的な知識がある。
④業務側の立場からプロジェクト全体へのアクションができる。
そして一番重要なのは、
⑤開発業務とサポート役を兼務しない。
という事です。
私たちはこのスキームでIT部門主体のプロジェクトを救済し正常化することに寄与したいと考えています。
