InfoQ

News

アジャイルチームでボーナスを分けるのはダイナマイトで遊ぶようなもの

作者 Vikas Hazrati, 翻訳者 大田 緑 - (株)チェンジビジョン 投稿日 2008年3月31日 午前6時42分

コミュニティ
Agile
トピック
ヒューマンリソース,
キャリア,
リーダーシップ
タグ
Remuneration and Incentives,
マネジメント
リーン開発グループ(サイト・英語)のSam Bayer氏が始めた興味深い議論の中で、メンバはボーナスを分配するもっともよい方法について話し合った。

Mary Poppendieck氏は、ソフトウェア開発はチームスポーツであり、個人に対してではなくチームの実績によって分配すべきであるとの見解を示した。同じような考え方で、Robin Dymond氏(source) は、チームの実績で50%、個人の実績で50%ずつ分配するのが正しいやり方であると提案した。しかしながら、ここで注意すべき点は、アジャイルチームで個人の実績を決めるということである。彼は次のように続けた。
もう1つの重要な問題は、いかにしてチームに隠れたリーダーを認めさせるかということです。例えば、テストとQAツールのクロストレーニングを強化するQA担当者もいるし、しっかりと自動化を進め、頻繁に全体の生産性を改善している開発者もいる。
Adrian Howard氏(source)は、ボーナスを分配するために個人の実績を評価することはほとんどの場合逆効果であり、避けるべきだと述べた。それはチームメンバ同士の対立の主な原因となり、順調なチームが直ちに崩壊することもあり得るからだ。彼が言うには、一度個人の実績によって分配されると、人々はチームのゴールよりも自分自身のゴールを目指すようになりがちである。

それでは、ボーナスを分配するもっともよい方法は何か?

Matt Swaffer氏(source)は次のように提案した。
ここに2つの考え方があります。1つは、全員がボーナスとして自分の給料のX%をもらう方法です。もう1つは、チーム全体で分配されるXドルを均等に分ける方法です。
しかしながら、この解決策ではグループのメンバの多くは納得しないように思われた。もしボーナスが均等に分配されたら、他の人より努力している人はやる気を失うことになる。均等に分配することによって、実績の高い人達のやる気をなくさせるわけにはいかないだろう。一方で、もし給料の何パーセントかならば、給料を多くもらっている人達はさらにもらうことになる。例えば、A氏が100,000ドルの給料で、B氏は50,000ドルの給料であるとしよう。今、ボーナスが5%だとしたら、A氏は5,000ドル、B氏は2,500ドルもらうことになる。

もう1つの画期的な提案は、どうやってボーナスを分配するかチームに決めさせることである。それに対して、Mary氏(source)は強く反対し、次のように述べた。
あるチームが巨額のボーナスをもらい、自分達で分け方を決めた時のことをMike Cohn氏が語っています。お金をどう分けるかという話し合いは、チームに和解しがたい激しい対立をもたらしました。結局、決めることができたのは均等に分けることでした。多くの人達はそれは不公平だと思いました。チームにボーナスの分け方を決めるように頼んだことで激しい対立が起こり、ほとんどのメンバは最初からボーナスがなければよかったのにと願ったほどでした。
このグループはボーナスを分配する最適な方法について同意することができなかったようである。あるチームでうまくいく分配方法であっても、他のチームではひどく混乱してしまうことがあるのだ。このグループは、しかしながら、アジャイルチームでボーナスを分けるのはダイナマイトで遊ぶように非常に危険なことだという点では同意したようであった。

原文はこちらです:http://www.infoq.com/news/2008/03/bonus-for-agile-teams
ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
Hatena

No comments

返信

特集コンテンツ一覧

トップスポーツチームの監督に教わる秘訣

この論文では、氏が発見した原則を要約し、その原則をいかにしてソフトウェア開発に応用するかを説明します。

事例研究:Dutch Railwaysのプロジェクトにおける分散拠点でのスクラム・プロジェクト

この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。

Agile2008チーム参加レポート - 帰国そして変化

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。参加者はカンファレンスで各々の発表や、各セッションへの参加、諸外国のエンジニアとの出会い、ステージ上で DearXPを熱演などの様々な思い出を抱えて、無事日本に戻ってきました。

SilverlightとJavaのインターオペラビリティ

マイクロソフトのRobert Bellが、SilverlightとJavaを使用したインターオペラビリティのシナリオを紹介し、サンプルコードを例にとってアーキテクチャの手引きを提供します。

Agile2008 チーム参加レポート - カンファレンス参加編

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。サブミッションが選択された人、そうでない人も含めて、個々の目的意識の確認、膨大なプログラムから聞きたいセッションの選択、旅行の準備、プレゼンテーションの準備の期間を終えて、無事当日を迎えました。

Agile2008 チーム参加レポート - 動機/準備編

筆者はアジャイルソフトウェア開発についての年に一度の国際会議であるAgile2008に初めて参加してきました。今年の日本からの参加者の数は14名にも及び、発表者は5名、受け持ったセッションは8つに及び、例年にない活躍を見せました。なぜ今年のAgile2008では、これほど多くの日本人が参加し発表に至ったのか? そのレポートをお届けします。

Javaトラブルシューティングメルマガ総集編 2008/08~09

エスエムジーでは、Java全般を対象にしたトラブルシューティングサービス「JaTS」を提供しています。この記事では、前回に引き続き、JaTSにて蓄積したトラブル事例とその解決ノウハウの一部をお送りしている「Javaトラブルシューティングメールマガジン」(JTSMM)の総集編として、過去2ヶ月のトラブル事例と追加情報をダイジェストとして提供いたします。

モデル駆動アプローチがうまく機能しない(しなくなる)8 つの理由

この記事では、モデル駆動アプローチがうまく機能しない、または機能しなくなることによって期待した結果が実現できなくなる 8 つの理由について書きたいと思います。