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

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

仕事のやり方 旧館より

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

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


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

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

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

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

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

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

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

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

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

Arshad Pooloo

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

執筆者:


comment

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

関連記事

会社を移ることになりました

2012年6月末で会社を移ることになりました。 (何度か転職をしているのですが)今のところ、社会人経験の中で一番長く所属していた会社になっていました。 思い出1:Rubyとの出会い 入社後しばらくして …

徹底することの難しさ

やり方の改善や新手法を取り入れることがあります。 例えば今までの設計手法を「品質の向上を目的として、今度はこういう手法、方法をやってみよう…」等という時です。 顕在/潜在的問題点に対し解決方法を考え、 …

えらくなっていきたいか?

ずいぶん前に書いたまま放置していたのを(ちょっと書き足して)アップします。 組織において「えらくなっていきたいか?」という話です。 えらくなりたいか?の問いに対して 一時期「昇格/昇級したいか?」とい …

自分が議事録を書く際に気をつけていること

「議事録」は社内外の会議、打合せ、レビュー等のアウトプットです。 良い議事録を書く留意点、テクニックは色々あり、例えば… 1営業日以内に書く 記憶は曖昧で、かつ、あっという間に別のタスクが入ってくるの …

白魔導師はファイアを使えません

最近、久しぶり…半年ぶり…にお客様常駐から社内に戻ってきました。 それで、あるプロジェクトのお手伝い…調査、プログラミングなどを少ししたのですが、その時のお話です。 プログラミングですが、当初はVB6 …

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