［3］開発機能全体の目標に対する実績のチェックが行われていない、あるいは形骸化している
設定した開発生産性の目標に対して実績がどの程度であったかの確認がなかったり、目標と実績に差異がある場合に差異の原因は何かの分析がなかったりする場合である。また、その後の開発生産性向上活動において差異を生じさせないためにどのようなことを行えばよいかの検討が行われていない状況である。
これらは、「PDCA」（plan-do-check-act）で表される管理の基本であるにもかかわらず、不十分なケースが多い事項であり、特に原因分析が疎かになっている場合が多い。その理由としては、それ以降の差異防止につなげようという目的での原因分析が行われていないことが挙げられる。PDCAを回さなければ、レベルアップのスピードを上げることは難しく、業務改革は停滞しがちになる。
［4］「見える化」に無意味に工数を掛けている
システム導入を前提とした業務改革の場合に起こりがちな例である。従って、3Dプロセス改革においても特に注意が必要である。例えば、いずれシステムを導入する際に、作業手順レベルのフローが必要になるのでムダにはならないだろうという考えのもと、詳細な業務フローを網羅的に作成していく一方で、工数やリードタイム、品質などの問題把握が不十分になってしまっている状況である。
つまり、業務改革を実行するために必要な見える化において、何をどの程度まで「見える化」すればよいか、という検討が不足しているのだ。一般的に見える化は大切なことではあるが、あくまでも手段に過ぎない。上記は、目的が不明確なまま手段を追求してしまう典型的な例である。
問題の把握が不十分で、改善対象の見極めや改善策の立案が疎かになれば、工数を掛けて見える化したフローも業務改革には使用されず、システム導入のためだけに使われることになる。こうした際のTo-Be業務フローは、業務の重複や転記など、システム視点での改善しか反映されない。
なお、コンサルティング・ファームやシステムベンダーを活用する場合、この見える化の工数が支払い費用に直結する。クライアント企業の皆様には、以上のような視点で精査することお勧めする。
