サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

仕事のやり方 旧館より

生産性の低さを嘆くよりも…

投稿日:2009年12月8日 更新日:


プロジェクトにおいてメンバーにタスクを割り当て、その品質や進捗管理をすることがあります。それについての自戒を書いておきます。

プロジェクトにはQCDなど色々な問題がつきものです。
その1つに【(自分も含めた)メンバーの生産性が想定より低い】ことがあります。

ここでの生産性は質/量を問いません。
例えば「1日(8時間)で2画面分のコーディングができる想定だったが1画面分しかできない」「レビューで誤字・脱字レベルの指摘が大半を占める」などです。

それを嘆いて、(メンバーを)批判しても、プロジェクトにとって、なに1つプラスの効果はありません。
それよりも(メンバーを管理する立場の)自分が、メンバーの能力を100%発揮できる環境を作れているのか?を自問し、またメンバーそれぞれと話し合うなどの、アクションが必要かと思います。
#もちろんメンバー本人がベストを尽くしている前提です。

そういうアクションを取ると、「ツールが無く不便」「上流工程での成果物が分かりづらい」や「もっと任せて欲しい」「会議が多い」など色々な声が聞こえてきたり、また「そもそも想定していた生産性自体が的外れだった」などということも分かるかもしれません。
 #本来は、プロジェクトにおいて随時、そういう舵取りを行うのがPM、PLなど管理者の役目だと思います。

そのようなことをせずに嘆いて、イライラをメンバーにぶつけたところで、メンバーのモチベーションはみるみる下がり、「作業者」になってしまいます。すると、ますます(管理者から見た)生産性が低く見えるようになる…という悪循環になります。

結果、プロジェクトで解決すべき課題に管理者とメンバーが「団結して」立ち向かわないといけないのに、管理者とメンバーが「対立関係」になってしまいます。

これでは、誰も…課題解決を依頼したお客様含め…ハッピーにはなれない…という残念な結果になってしまいます。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Arshad Pooloo

-仕事のやり方, 旧館より

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

仕様変更における納得感の大事さ

システム開発プロジェクトでは、仕様変更は程度の差はあれどあるものです。 その仕様変更決定までの過程によっては、(SIerも含めた)プロジェクト関係者の納得感のある/なしが大きく変わり、それはアウトプッ …

ホワイトボードを使わない会議はあり得ない

色々な意味でカルチャーショックなプロジェクトの話です。 お客様との打合せ…議題は複雑で、図解をしたりして、何らかの「見える化」などの対策をしないとアッと言う間に「空中戦」になること必至のものでした。 …

人によって違う「ゆっくり」

お客様や同僚から言われる「この仕様をドキュメントにまとめてもらえますか?急いでいないので、”ゆっくり”で良いですよ」という言葉。 よくある会話ですが、この「ゆっくり」の捉え方に …

初めて勉強会で発表する人に伝えたいこと

同僚がチームが直面した課題、その課題へ工夫したことを事例紹介として、勉強会で発表することになりました。 この同僚は社外の勉強会では初めて発表するというこもあってか「ほとんどの聴き手が『そんなん知ってる …

問題対私達の構図

システム開発プロジェクト…特にユーザテストなど終盤…で、ユーザから届くイヤな声の1つに「○○機能が想定と違います。Aという動きではなく、Bが(想定される)正しい動きです」というのがあります。 #ここで …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。