昨日も書いた時間の話。


この発端は、私が会社員時代にさかのぼります。

大学を卒業し、初めて入社した会社(ソフトウェア開発会社)では

毎週月曜日に先週の報告書と一緒に、作業工数を提出していました。

当時は駆け出しの新人で、目の前の開発作業に終われるまま没頭し、

指示されるがままに数字を報告しており、プロジェクトの

損益の判断に使っているんだろうな…くらいにしか考えておりませんでした。



2年半後、私はその会社を辞めて別の会社に移りました。

その会社では新しく部門(ソフトウェア開発)を立ち上げることなり、

経験不足ではあったのですが、開発メンバーを管理することになりました。



もともと、この会社にも工数管理の仕組みはありましたが、

ソフト開発に特化した作業項目分けがなかったこともあったので

前の会社での記憶を思い起こし、自分たちのチームに特化した

作業工数管理の仕組みを導入することにしました。



チームのメンバーに作業工数管理システムを作ってもらい、

毎日、帰宅前に1日の業務別の作業時間の投入を義務付けました。



この数値を眺めていると、ある開発(プロジェクト)において、

どの作業にどのくらいの時間がかかったのか、言葉は悪いですが、

プロジェクトがいつの時点から赤字になるのかがわかります。



また、各人の数値を見ると、

どの作業に時間がかかっているのかがわかり、

どういった指導をすると効率よく、よい仕事をすることができるのか、

どこにポイントを置いてアドバイスすべきかが見えてきます。



もちろん、人それぞれ得意な部分、不得意な部分、

経験年数によるスキルの差もありましたが、

チーム全体としてのの傾向、メンバー個々の傾向を見る上で非常に役立ちましたし、

私にとっても、そういった視点をもつことができたのは大変よい経験となりました。



ともすると、効率化だけを追い求めた仕組みに見えがちですが、

組織の傾向を知るということは、最優先でやらなければならないことだと

思っていますし、数値を集めることが目的ではなく、その数値から、

何を読み取り、どのように手を加えて行くかがポイントになると考えていました。



この考え方はしっかり熟成し、次の自分の公約に加えたいとも考えています。


Secret

TrackBackURL
→http://tacho.blog52.fc2.com/tb.php/1072-8dfc1d34