「ITの開発現場によくいるやっかいな人」の対処法をタイプごとに解説したサイトが登場
ソフトウェアの開発プロジェクトにはさまざまな経歴や役職を持つ人が関与するので、我が強い人や性格に難がある人が問題になることもしばしば発生します。ソフトウェア業界のよもやま話を語るブロガーのニール・グリーン氏が、ソフトウェア開発プロジェクトの中で問題になりがちな人をタイプごとにまとめつつ、それぞれのタイプの特徴と管理職向けの解決策を解説しました。
How to Deal with Difficult People on Software Projects
上記のサイトにアクセスしたのが以下。上から「プロダクトマネージャー」「デザイナー」「プロジェクトマネージャー」「開発マネージャー」「開発者」「品質保証(QA)」の6カテゴリに分かれていて、それぞれの役職の中によくいる「問題のある人」のタイプが動物のアイコンで示されています。例えば、「プロダクトマネージャー」の欄にいるライオンのアイコンの「独裁者」をクリックしてみると……
「独裁者」の個別ページが表示されました。グリーン氏によると、「独裁者」とは「自分が出せなかったアイデアを否定するプロダクトマネージャー」のことで、明確な分業を重視するあまり役職間のコラボレーションを妨げてしまうほか、特に開発者との折り合いが悪いという点で問題になりがちとのこと。「独裁者」が開発者とのコラボレーションのメリットを理解していない場合、上層部との話し合いで比較的簡単に問題が解決しますが、多くの場合開発者との折衝にトラウマを抱えているので、開発者の代表との話し合いも効果的なのだそうです。
また、デザイナーの中には、「エンドユーザーの使い勝手より製品の見た目を優先する」という「アーティスト」がいます。
「アーティスト」は実用性より形式を重視するので、開発者のための要件定義がずさんになり、QAもUIの一体何をテストすればいいのか分からずじまいになるなど、なし崩し的に開発現場が混乱します。グリーン氏は「一般に、芸術系の学校に通っている人や芸術系の職業に就いている人は、詳細なシステムインタラクションの要件書を作るのに必要な分析力や技術力を持ち合わせていません。『アーティスト』を修正するのは、彼らの職業の重要なアイデンティティに変更を加えるということなのであまり現実的ではありませんが、アプリケーションのルック・アンド・フィールよりもユーザビリティに重点を置くデザイナーと組んでもらうことで、問題を緩和できます」と述べました。
問題のあるプロジェクトマネージャーの中で、特にプロジェクトに大きな打撃を与えかねない部類だとグリーン氏が位置づけているのが「暴君」です。
「暴君」とは、「やる気を出させるという名目でメンバーを見下したような扱いをするプロジェクトマネージャー」のこと。ソフトウェア開発プロジェクトには、よく強烈な個性を持つメンバーがいるので、時にはプロジェクトマネージャーが強権を発動することも必要ですが、「暴君」はその権限を乱用して優秀な人材の流出を招くので、プロジェクトへの危険度が高いとのこと。「暴君」の問題を修正するには、「優秀な社員が辞めた人数」「人材獲得の失敗率」「バグの数」「締め切りに間に合わなかった件数」といった定量的なデータを突きつける必要があるとグリーン氏は指摘しています。
開発マネージャーの中で最も危険度が高いのが、自分の昇進しか頭にない「ラダークライマー」です。
グリーン氏によると、「ラダークライマー」は昇進と昇給にしか興味がないので、プロジェクトの成功には関心がなく、自分がいる会社を憎んでいることすらあるとのこと。そのため、自分の昇進を決められる人に対してこびを売ったり、相手によって態度や発言が二転三転したりします。グリーン氏は、「ラダークライマー」の解決策として一言「Fire them.(クビにすべし)」とだけコメントしました。
開発者の中で最も危険な部類の1つが「無能」です。
「無能」は、ソフトウェアを書くための能力やスキルが欠けているのを、会社が提供するトレーニングの不足や、会社が使っているツールや技術が複雑すぎるせいにするという特徴があります。グリーン氏は、「仕事が難しすぎると判明した場合は、トレーニングに投資するのが普通ですが、重要なのは『もし彼らに学ぶ力があればとっくに学んでいるはず』だということです」と指摘。退職勧告をするか、それでも退職しない場合は解雇せざるを得ないと結論付けました。
製品をテストして機能を確認したり、バグを見つけたりするQAの中には、不正確なバグレポートを大量に提出して開発者を困らせる「消防ホース」の人がいます。
「消防ホース」の人はバグを詳しく調べないので、無数のバグを素早く見つけることはできるものの、報告内容をよく見ると同じ不具合が別々な形で現れただけということがよくあるとのこと。グリーン氏は「消防ホース」への対策として、「大事なのはバグをたくさん見つけることではなく、システムの品質を向上させることだと伝えることで、『消防ホース』は開発者がシステムの問題を発見するのを助ける人に変わります」と述べました。
