お問い合わせ

ソフト開発会社T社の物語 ~中堅・中小企業の改革物語~

  • 中堅・中小企業改革

塚松 一也

chusyo_t_top.jpg


※本コラムは、今から20~25年前(1997~2002年頃)の実例をもとにした物語です。
今ではイントラネット・グループウェアを活用することが当たり前になっていますが、当時はそれらのツールを導入してもうまく活用されないという組織が多々あった頃です。 当時の時代背景は違いますし、導入すべきツール・システムは今とは異なりますが、今でも参考になる部分はあると思い、今回リライトして掲載をいたしました。

グループウェアを活用して会議の時間短縮を目指したT社

 今回紹介する企業は、システム受託開発会社T社でのグループウェアの活用事例である。
T社は親会社(機器メーカ兼システム販売会社)を主たる顧客とし、ソフト・システムの開発を行っている会社である。親会社から仕事がくるため、仕事上の競合はほとんどないが、厳しい納期・厳しい価格要求があっても断りにくいという親会社・子会社関係にありがちな悩みがある。

 親会社(顧客)から、「開発の進捗状況を知りたい」と聞かれるたびに、リーダーは資料を準備して報告していた。加えて。リーダーが開発の状況を把握するために、それぞれのプロジェクトで週例会が開催されていた。そのため、複数プロジェクトを掛け持ちしている人は、週に何時間もミーティングに時間がとられていた。「事前に情報共有をしておけば済むような内容の報告は勘弁して欲しい」というのが多くのメンバーの本音だった。

 そんな状況を改善するべく、ループウェアを導入した。「会議で、進捗状況をひとりひとり説明するのはやめよう。日々、各自がグループウェアに開発状況をアップして、リーダーはそれをいつも見るようなワークスタイルになれば、情報報告の会議の時間は大幅に短くできる。フェイスtoフェイスの場は、技術的な悩みの解決策の検討に使おう。」と、グループウェア活用の取り組みが始まった。

システム活用普及 成功のポイント

 グループウェアを活用しようという趣旨には反対する人はいなかったが、実際に導入がスタートしてお、なかなかシステムが使われない。多くの人は、「本当にみんなやるのかな?」というような様子見の姿勢のままだった。一部には、「うちの会社、こういうの定着したためしがないから、今回も失敗するよ、きっと。」という人もいた。

 そんな中、活動をひっぱる部長、課長らは、地道な啓発に努めた。ミーティングの度に、「その情報、事前にグループウェアにアップしておいてくれたら、ここで話をしなくてもいいんだよ。会議の場で初めてそれを聞いても、すぐに判断できないこともあるから、事前に情報共有しようよ。」というような丁寧な投げかけを毎回続けた。

 それらは、上司から部下への"命令"ではなく、新しいワークスタイルにしようという"呼びかけ"だった。グループウェアに限らず、新しく導入したものについては、その人が必要性を実感しない限り継続して使わないものである。命令では一時的に人を動かすことができるが、上司が代わったらすぐに使われなくなってしまう。部長・課長らは、都度都度望ましいワークスタイルを具体論(具体例)で話して、時間をかけて活用する仲間を増やしていった。部門のメンバー全員があたりまえに使うようになるまで半年ぐらいかかった。

 グループウェアへの情報(スケジュール、開発資料、打合せ議事録等)登録のしかたのルールは、あらかじめ作ったものではなく、使っていく中で自然発生的かつ自律的に決まっていった。現場実態をよく理解していない人がルールを作ったのではなく、毎日使う本人たちでルールが作られ、改良が加えられていった。

 おおむね普及した翌年度、その会社にも十数名新入社員が入ってきました。その新人もOJTを通じて少しずつ仕事を覚えていったが、OJTの現場には例年とは違う光景があった。先輩社員が新人に対して、「君が作ったドキュメントは必ずここにアップすること。他の人が作った資料は必ずここに登録されているからすべて目を通すこと。仕様変更やスケジュール変更は必ずここに表示されているので、見落としをしないこと。情報は間違いなく最新のものになっているから、知らないというのは許されないからね。アップしない奴が悪い、毎日見ない奴が悪い というのがうちの常識だから。・・・」と教育していた。(筆者は偶然この現場を目撃したのだが、それはもう絶対のルールだという感じで教えていた)

 自然発生的につくられたルールが、あるタイミングからは組織の公式ルールとして運用されはじめたのである。以後、新人が入るたびに、このようなルールの躾が行われたこともあり、運用開始から2年も経ったときには、グループウェアで開発状況などを共有化することは完全にワークスタイルとして定着した。ある人は、「グループウェアがなかった頃にどのように情報をやりとりしていたのかをもう思い出せない。昔はどんな方法で情報をやりとりしていたんだっけ?」と真顔で言っている。まさにそれを使うのがあたりまえになった、活用が定着した状態になった。

効率化の測定方法

 ここまで紹介したように、T社でのグループウェアの活用の取り組みは成功に終わったが、いくつか面白い後日談がある。

 数年後に親会社から移ってきた取締役(管理部門管掌役員)が、グループウェアなどのIT投資の額は小さなものではないので、これらの投資は本当に効果を生んでいるのかと疑問を投げかけた。各人のパソコン等ハード費用も含めればもちろん安くない額の費用発生しているわけで、会社に来て間もない取締役にしてみれば当然の疑問だった。そこで、部門長に「IT投資がどれだけ成果を生んでいるのかを各部門でとりまとめ報告せよ」という指示が下りた。

 困ったのは現場である。すでにグループウェアは日常業務にはなくてはならないものになっていて、稀にサーバーの調子が悪くなると「仕事にならない」といったクレームが情報システム部門に押し寄せるぐらい当たり前のインフラになっていた。今さらグループウェアの投資対効果を示せと言われても、どう測っていいものか現場は悩んだ。

 「グループウェア導入前の業務と比較して、それぞれの業務が○○%程度効率化できた。」と言っても、どこか嘘っぽく、「その根拠は?」と問われても感覚的なものとしか返事ができない。感覚的な数字を積み上げて報告することにどれほどの意味があるのかと頭を抱えた。「昔にくらべて、格段に便利になったし、情報の意思疎通のミスによるトラブルもほとんどなくなった。成果は実感できているのに、どう成果を算出すればいいかわからない。帰る時間が早くなったわけでもないし、暇になったわけでもなく、自分たちは昔も今も忙しいんだけどね。間違いなく昔よりもいっぱい仕事をしているよ。」というのが現場の実感だった。

 そんな議論を重ねる中で「そうか、昔に比べてどれくらい時間が短縮できたかで計るのではなく、昔やっていなかった仕事を今はこんなにもやっているというような測り方をしてはどうだろうか。」という着眼に至りました。そこで、各人に、同じようなプロジェクトを思い浮かべて、昔はやっていなかったけど今はやっている業務内容を書き上げてもらうことにした。

 実は、ISO関係の業務、バグ管理の業務、新技術の勉強時間、顧客先に出向いての打合せなど、冷静にあげると、昔に比べて多くの仕事をプロジェクト業務の中で行っていることがわかった。「減った仕事時間を測定するのは難しいが、増やすことができた仕事量を明らかにすることならできる。」という発想で、各人に増やすことができた仕事を挙げてもらうようにした。その積上げ(時間値)は相当なもので、大げさでなく20%以上の仕事量の増加にもかかわらず、業務時間は昔とそんなに変わっていないことがわかったのである。

さらに、もう一つ成果の測り方も見つけた。それは、「もし、このグループウェア(の各機能)が使えなかったら、どのくらいの時間が余計にかかるのだろうか?」という測り方である。T社ではグループウェアは可動率(availability)が極めて高い"インフラ"だった。
それがもし止まって使えなくなったら、どのくらい困るのかという観点で皆にアンケートを取った。その結果は火を見るより明らかだった。問題提起した取締役の人も納得(安心レベルではなく、感心レベル)して、以降この会社ではこの類の話題は上がらなくなった。

 もうひとつの後日談だが、この取り組みの成功後数年して、このT社は、親会社のソフト開発部門の一部および関連企業と合併し新会社になった(500人規模)。合併した際に、もともとT社でなかった人たちから、「こんな便利にグループウェアを使っていたんだ!」と驚かれたそうだ。決定的に何が違ったかというと、T社出身者とそれ以外会社の出身者の、日々の情報共有の基本動作の徹底度合だった。入社以来、グループウェアで情報共有するのがあたりまえと教え込まれてきた経験数年の若手のワークスタイルが大きく違っていたのである。

システム活用の学習能力という組織能力

 T社はグループウェア導入で開発現場の仕事は改善した。この取り組みを推進した部長は、「グループウェアの導入経験は、その後の各種ツールの導入において大変役にたった。丁寧に必要性と操作方法を説明し、よい活用を褒め、使う人間を地道に増やしていけば、システム活用は定着することを、組織として学習できた。」と言っている。

 T社(合併後は会社名が変わったが)では、その後、バグトラッキングシステム、リスク管理システム、・・・など、いくつかの新しいシステムの導入をしてきましたが、いずれも導入に頓挫することはなかった。部長は、「中小企業だから、こういうアプローチがとれるのかもしれない。親会社だったら、こんな方法はとれないね。」と笑って話している。

オピニオンから探す

研究開発現場マネジメントの羅針盤 〜忘れがちな正論を語ってみる〜

  • 第24回 ワクワクするプロジェクトの目標を掲げているか?

イノベーション人材開発のススメ

  • 第5回 イノベーションの前に「ビジネスの基本」を

失敗しない組織改革のススメ―問題意識を起点に対策を立てる―

  • 第7回 なぜ「業務改善」は形骸化するのか?

国内の成熟市場で成長するために

  • 【最終回】第10回 働き方改革におけるマネジメント・イノベーション(後編)

本気のSDGs

  • 第7回 脱!手あたり次第のSDGs
  • コロナ禍のマーケティング 3つの成功例 未知・未体験のことは顧客に聞かない!

第一線の組織マネジメントを考察する

  • 【最終回】第15回 やりくりのマネジメントの意味合い

新価値創造マネジメントの新潮流

  • 第8回(最終回) 事業戦略での製品群の全体最適化
  • 「職場力」を再生する 〜リモートワーク時代の「場」のマネジメント〜

ものづくりマネジメント最前線

  • 第2回 これからのものづくりは戦略と実行力!

オムニチャネル成功の鍵

  • 第6回 オムニバイシクルモデルの実際 ①Omni‐CRM(顧客起点のCRM) 推進ポイント

オピニオン一覧

コラムトップ