人事評価と開発者のモチベーション/パート3:役割とポリシー(中編):The Rational Edge
前編「自己管理型チームの利点と弱点」は、自己管理型チームを推進するうえでの利点を解説すると同時に、陥りやすい問題点を指摘した。中編である今回は、人材の報酬や評価に関して解説する。
人事ポリシーとITの価値との適合
効果的なソフトウェア開発は、チーム環境における効果的な協調作業に意欲を見せる才能のある個人に依存する。これがうまくいくようにするには、社員の奨励金や報奨金、昇進、そして責務といった人事関連の問題をIT部門の価値と確実にうまく適合させる必要がある。
コラボレーションに重点を置くと、人材の報酬や評価にも変化が生じる。個人の生産性だけを評価するのではなく、各個人がチームに提供する価値も評価する必要がある。チームにとって最も有用なのは、自分の時間の大半をほかのチームメンバーの指導に充てるメンバーだ。これは、全体の評価に反映させるべき付加価値を持つ行動だ。
効果的な開発には、お互いを対等と見なす者同士の密接なコラボレーションが要求される。一部には、開発者からアーキテクトなどへの昇進により、部下の最も優秀な技術者が当座の開発から離れ、現状とあまり関係のないアーキテクチャチームに転属させられてしまう組織もある。そうなると、これらのアーキテクトが構築するアーキテクチャは現実と懸け離れたものになる可能性が高い。効率的な開発組織においては、これらの専門的で経験豊かな人々は、指導者および技術リーダーの役割も担い、後輩と一緒に仕事を進める必要が出てくる。
これら2つの例では、人事システムがITの価値を実装するに当たって適切な行動を促進し、チームメンバー間の効果的コラボレーションを保証する必要がある。
メリット
人事ポリシーとITの価値を適合させると多くのメリットが生まれる。
ソフトウェアの経済的側面の向上。良いソフトウェアは意欲的で才能のある人材によって構築される。意欲的かつ才能のある人材を確実に確保し、受け取った価値を確実に報奨金に反映させるには人事ポリシーが極めて重大になる。
意欲の向上とスタッフの増強。認められ、見返りがあり、支持されることに対しては、これを適切にやろうという意欲がわく。これは、スタッフの自然減の低下へとつながる。
トレードオフ
人事ポリシーとITの価値を適合させる場合には多数の重要なトレードオフがある。
人事ポリシーの変更意欲。人事部は、社内のさまざまな事業部の人事ポリシーに対する責任がある。人事ポリシーをある1つの部署の特定のニーズに合わせるのは難問であり、コストも掛かる。また、国によって異なり、検討の必要な法関連の影響もある。しかし、人事ポリシーの変更はIT部門が効率化することで大きな利益をもたらす。
技術系キャリアパスへの投資。大体の場合、トップレベルの優秀な技術者に対応するためには、彼らに関心のない、もしくは適性のない管理者のキャリアパスを選ばせたり、優秀な人材を停滞させるようなことのないよう、魅力的な技術キャリアパスを確実に提供する必要がある。ITエキスパートに長期的に有効なキャリアパスを提供することは重要な投資である。
優秀な人材集めに向けた積極的な行動修正。ソフトウェアエンジニアのモチベーションは、ほかの職種のそれとは異なる場合が多い。社員に対し、スキルの構築や本当にエキサイティングで革新的な製品の開発を認めるような報酬は、従来の手当以上の意味を持ってくる。優秀な人材を集めるには、集めたいソフトウェアエンジニアのタイプを考慮し、ターゲット層にとって魅力的になるよう行動を修正すると良いかもしれない。
アンチパターン
ここでは次のようなアンチパターンが関連してくる。
ほかの業務とITの同等化。人事ポリシーは、ターゲットとする社員グループのモチベーションに合わせる必要がある。ソフトウェアエンジニアのモチベーションは、ほかの開発者のそれとは異なる場合があるため、そこにあるギャップを理解し、それらのギャップに合わせて人事ポリシーを調整することが重要になる。変更可能な項目に関しては法的制限が掛かる場合があり、その制限も国によって異なる場合があることに注意したい。
個人の柔軟性の排除。IT内部でさえも、個人のモチベーションは各自異なる。これを考慮すると、チームとしての目標に合わせた各種報奨金を提供し、個人の目標や事情に適したものを社員に選ばせるべきだ。
推奨デフォルト
人事ポリシーとITの価値がよりうまく適合するよう、ITと人事のマネージャは必ず常時連絡を取り合うようにする。
著者プロフィール
Scott W. Ambler,
Practice Leader, Agile Development,
Rational Methods Group, IBM
Per Kroll
Manager of Methods, IBM Rational, IBM
- トランザクション管理の複雑性を克服する(パート1)
- アジャイルとシステムテストの新たな関係(後編)
- アジャイルとシステムテストの新たな関係(前編)
- アジャイル開発の広範な普及を目指して
- 見積もりの精度 Accuracy of Estimation
- 複雑性を理解する(後編):ソフトウェアの複雑性を手なずける
- 複雑性を理解する(前編):ソフトウェアが複雑なのは仕方がない?
- 鈍重な開発チームは鈍重なシステムを作る?/パート3:役割とポリシー(後編)
- 人事評価と開発者のモチベーション/パート3:役割とポリシー(中編)
- 自己管理型チームの利点と弱点/パート3:役割とポリシー(前編)
- プロセスはチャンスが訪れるたびに改善する/パート2:プロセスと基準(後編)
- 開発プロセス導入のアンチパターン/パート2:プロセスと基準(中編)
- 反復開発の「ここはぜひカバーしたいポイント」/パート2:プロセスと基準(前編)
- 開発プロジェクト「統治」のピンポイント解説/パート1:原則と組織(後編)
- 開発プロジェクトを「統治」するベストプラクティス/パート1:原則と組織(前編)
- 初歩の「Perl」「Python」「Ruby」
- ビルドが全滅する原因/プロジェクトの状態を評価する:パート2(後編)
- 不完全なコードは推敲フェイズで潰しておきたい/プロジェクトの状態を評価する:パート2(前編)
- UMLを使ったビジネスモデリング(後編):そうだったのか! システムユースケース
- UMLを使ったビジネスモデリング(前編):なるほど! ビジネスユースケース
- 「この開発プロジェクトは中止!」の基準/プロジェクトの状態を評価する:パート1(後編)
- プロジェクトのはじめに計画を立てるのは無謀/プロジェクトの状態を評価する:パート1(前編)
- 専門家に聞くモデル駆動開発のメカニズム
- 「設計」や「構築」よりも重宝されるスキル
- キミのコードが汚い理由
- 汎用グラフィカルモデリング言語「SysML」 パート2:グラフィカルなモデル言語で製品構造を記述
- 汎用グラフィカルモデリング言語「SysML」 パート1: 要件、ユースケース、およびテストケースのモデリング
- ウォーターフォールから反復型への移行手順
- ソフトウェアアーキテクティングのメリット
- ソフトウェアアーキテクティングのプロセス
- ソフトウェアアーキテクトの役割
- ソフトウェアアーキテクチャって何なの?(後編)
- ソフトウェアアーキテクチャって何なの?(前編)
- ITプロジェクトを見える化する
- ユーザー要件を引出すテクニック: ユースケースかストーリーボードか
- オブジェクト指向を超えて
- ルネサンスの巨匠たちに学ぶエンジニアリングの技
- ソフトウェア開発の「いま」と「近未来」の話
- 中国のソフトウェア開発現場はこんなにスゴイ
- 隣のテストチームが優秀ないくつかの理由(後編)
- 隣のテストチームが優秀ないくつかの理由(前編)
Copyright © ITmedia, Inc. All Rights Reserved.