A社における改善活動履歴(#5、コンサルによる改善活動)

事業計画立案と実践する為の研修(2004年4月~2005年11月)

開発、営業、SEの分野から有志の社員を募り、

問題点調査、課題の洗い出しを行った改善活動は終わり、

いよいよ3社のコンサルに下記テーマでそれぞれ改善を

依頼することになりました。

 

バランススコアカード導入と実践研修

バランススコアカードの手順に沿って、ビジョンと戦略の立案、

アクションプランの策定を行います。

 

■実践的人材育成

その企業文化、組織に求められる管理職のコンピテンシーを作り、

定期的に上司とヒアリングしながら望まれるマネージャーを育成。

 

■プロジェクトマネージメントプロセス改善(導入分析と改善策検討)

プロジェクト支援tool導入を前提で、現状の開発プロセスを分析調査し、

改善策を検討。

 

経営会議での発表と役員からの評価

2004年は約50人のメンバーで事業計画作成や

アクションプランの策定に費やし、

成果を確認できたのは2005年夏を過ぎていました。

プロジェクトマネージメントによる開発プロセス

改善策説明と以降の計画の許可を含めた

結果報告を2005年11月に経営会議で発表。

 

事業部長(兼役員)はプレゼンで正直に

下記の感想を述べました。

「今まで事業部長一人で考えていた事業計画を、

キーマン50人近くと共同で作成できた。」

 

「今までバラバラに行動していた開発と営業が

連携してアクションプランを作成できた。」

 

「具体的成果が、一部製品で出始めている。

地味ではあるがリスクの先取りをコツコツ

実践しており、今後相乗効果が出ていく。」

 

「何よりもメンバーの連携が強まり視野が広まった。」

 

しかし、役員会の総合評価はあまり良いものではなく、

以降のコンサルへの予算の承認されませんでした。具体的には、

「1年かけて練った事業戦略の内容の完成度が低すぎる。」、

「一部のメンバーだけで作成し、社員全員の参加まで出来てない。」、

「toolを導入することありきで説明されていて、

コンサルの商法に騙されている。金をかけずにやれることはもっとある。」

と言ったものでした。

 

「1年かけて練った事業戦略の内容の完成度が低すぎる。」

については、

いろいろと現状調査をし、様々な要素を考慮した上で、

今までにない抽象度の高い表現をしたのが裏目に出た感じです。

 

今まで製品企画は開発者個人が非常に詳細な数値まで

決め打ちで作成し良いことばかり想像で書いていたので、

経営会議では詳細な説明が出来たのです。

事実、開発が進むにつれて、

製品企画の内容は(常識とは逆に)粗くなっていきます。

 

「一部のメンバーだけで作成し、社員全員の参加まで出来てない。」

については、

今まで開発者1人だけの頭の中で開発が進み、

その他のメンバーは指示されたことを行うだけでした。

それを各分野のキーマンの参加から徐々にメンバーを

増やしていた過程で評価されたので説明不足、

理解不足としか言いようがなありません。

 

「toolを導入することありきで説明されていて、

コンサルの商法に騙されている。

金をかけずにやれることはもっとある。」については、

 

どうしてもtoolを導入せざるを得ない状況だと

理解してもらう必要がありました。

開発ノウハウの蓄積や共有をしないと、

開発期間短縮や分業化が出来ない状況なのは

分かっていましたが、具体的解決策は個人に任されていました。

 

個人でバラバラに工夫するとさらに大変なことになります。

社内で安価に作るtoolだけを導入するのが目的ではなく、

全体をみた改善策を検討したかったのです。

 

一度役員だけで山籠もりしてじっくり腹を割って

話す場を設けよう、ということになり、

リーダーの事業部長が社長に相談に行きましたが、

その場が実現することはありませんでした。

 

事業部長の異動と保守への揺り戻し(2006年4月)

大幅な組織変更が行われ、純粋に、ストレートに

問題定義をしてくれていた事業部長(兼役員)

別事業部に異動となりました。


代わりに、開発リーダー個人の資質に頼るスタイルを

復活させようと提唱していた役員が事業部長となりました。

 

私が所属していた商品企画部も解散となりました。

商品企画も各開発リーダーが個別で行うことになりました。

プロジェクトマネージメントについては継続ということで、

全社対象ではなく、所属事業部内の改善作業を

継続することになりました。


2年間の活動の反省

経営会議での評価はおおむね正しいものでした。

現在進行中の業務と並行して改善業務を指揮することは

リーダーの事業部長には大きな負担であり、

やればやるほど社員の実力不足が分かってきて、

どう理想と現実の折り合いをつければいいのか迷って

いました。


もっと早くに経営陣の山籠もりを勧めたのですが、

もう少し成果を出してからにしたい、早く相談すると

中止されてしまう懸念もあるからと、

ずるずると引き延ばしたことも結果的にマイナスに

働いてしまいました。


途中経過でまだ成果が出ていなくても、

仲間内の感覚で「これから必ず見える成果が出てくる。」

と、確信が持てる場合と、

「本当にこれでいいんだろうか?」

と常に迷いながら進めていく場合があります。

実際はどちらの場合でも、失敗することもあるし、

成功する場合もあるのですが・・・


どちらにしても、周囲とのコミュニケーションを良くして

おくことが大切で、途中経過での誤解(一部のメンバーで

勝手なことをやっている等)を防ぐことができます。


今回もリーダーである事業部長が、純粋なエンジニア志向の

リーダーだったために、改革を推進する社内戦略に失敗した

ケースです。


今回の活動で洗い出した問題点については認識されたようで、

新しい事業部長が独自に施策を考えて継続されたことで

分かるだけに残念です。


この経験を元に、

その後転職した外資系では、プロセスで評価はされないので

基本的に成果が100%出る範囲に留めて(このことを特に

周囲に説明しない)改善してきました。