ブログトップ 記事一覧 ログイン 無料ブログ開設

Strategic Choice

2015-04-30

[]唯我独尊

対象

加害者被害者
プログラマ=>チーム

どういうこと?

非協力的なメンバがいます。

味方であるはずのチームメンバなのに、同じ目的を共有しているチームメンバなのに、なぜか、協力的でないメンバがいます。同僚のプログラマを困らせる、チームを困らせるプログラマがいるのです。

例えば、敵意があるのかと思わせるくらい気難しい人がいます。不機嫌な時は、何の相談もできません。これでは、効果的なコミュニケーションが取れません。

また、自分の役割を自分で区切る人もいます。勝手に線引きして、それ以上の仕事は絶対にやりません。そういう人は、コードベースやプロジェクト全体に対しても無関心です。

どうして?

能力は申し分なくても、非協力的なメンバがいると、チームやメンバのアウトプットは最大化されません。

不機嫌がな人がいると、全体の雰囲気も悪くなります。不機嫌は、伝染します。日々のコミュニケーションが阻害され、より良い仕様やアーキテクチャを議論することができません。

自分のことしか考えない人がいると、チームとして〆切や品質を守っていくことはできません。最低限のルールを守ったり、プロジェクトの日程を意識したり、「つなぎ」「のりしろ」の部分を気にしないと、チームとしてスムースに仕事を進めることができないからです。

どうすれば?

メンバは、チームのアウトプットに最大の価値を置くようにします。

マネジャーは、チームが有機的に動くよう、目標を定めるようにします。チームが自律的になり、勝手にコミュニケーションして動き出すのが理想です。

コミュニケーションの時の態度として、上機嫌であるのは、絶対的な、普遍的なルールです。普通の大人のマナーです。

いくら言っても協力的でない人は、能力があったとしても、チームに必要ありません。別のところで一人で作業してもらうのも、選択肢の一つです。

出処

2015-04-28

[]学習能力不足

対象

加害者被害者
会社=>チーム

どういうこと?

組織における学習能力の有無は、死活問題です。学習とは、極めて重要な改善メカニズムで、学習しない者に将来の繁栄はありません。

組織の学習能力は、単に経験を積み重ねるだけでは不十分です。IT企業は驚異的な速度で経験を積み上げていますが、経験したことを実践で生かしきれていません。

それは、組織の学習能力は、組織が「どの程度人を引きとめておけるか」で決まるにもかからわず、その活動をないがしろにしているからです。

どうして?

企業の姿勢が、経験から学ぶ姿勢に変化したとき、経験は学習となり、定着します。この変化には、以下の2つの形態があります。

  • 組織内に新しい技術を徐々に浸透させ、組織内の人を訓練する。
  • 現行業務を別の方式で処理するため、組織自体を再編成する。

1番目の方法では、社員に、新たに能力や技術を学習させます。すると再教育を受けた技術者が会社を辞めれば、投資は失われ、学習効果は消えてしまいます。

2番目の方法では、変化や改善は、再編成を実施する人の頭の中で一時的に起きるにすぎません。将来的に、再編成した部分は、組織にしっかり根付きますが、過渡期では、改善は関係者の頭の中にしかありません。この場合、新体制へ移行中に、中心人物が辞めると学習能力は消え失せます。

よって、どちらの場合も、組織の学習能力は、「組織がどの程度人を引きとめておけるか」に左右されるといえます。

退職率が高いと、組織の学習能力を向上させる計画は頓挫し、何の効果も生まれません。そんな組織では、技術力を向上させたり生産方式を再編成することは、実りのない試みです。それどころか、退職率をさらに引き下げる要因になりかねません。

どうすれば?

社員の離職率を下げるようにします。

ソフトウェアは人が作るものです。チームや人を大切に育て、それを維持していくことが、良いソフトウェアを作るために必要なことです。そこに学習能力が備わり、経験が蓄積されていくはずです。

プロセスや規則ではなく、そこにいる人が働きやすい環境を作ることに力を注ぎます。

人が辞めることのオーバーヘッドは恐ろしく大きなものです。優秀な人が辞めた場合、その穴埋めにかかるコストや、将来その人が産み出したであろう価値は、計り知れないものです。何より、蓄積された経験を無に帰すことになります。

また、組織が学習能力を持てるかどうかのカギは、「どのようにするか」ではなく、「どこでやるか」です。

企業を大きく変える場合、組織内では、小規模ながら活発に活動している「学習センター」があります。そのセンターが「変化」を認識し、計画して、実行していくのです。

意欲的な変革は、各部署の代表が集まる委員会や会社全体では成し得ません。初期における改善運動(すなわち、学習)の拠点は、企業の組織表に載せておくようにします。

組織の最上層に「学習センター」を持ってくるのは、うまくいきません。企業のトップの目が、日常の作業に向いているわけがありません。

組織の最下層に「学習センター」を持ってくるのも、うまくいきません。最下部で実務を担当する人は、部署の縄張りにガチガチに縛られ、企業学習に必要なことを見逃してしまいます。また、最下層ゆえ、変革を実施する権限もありません。

よって、中間管理部門で学習センターを担当するのがもっとも自然です。中間管理部層の強力なリーダーシップがあって、はじめて学習センターは成功します。

それにもかかわらず、会社組織の軽量化は、中間管理層がターゲットになることが多くなっています。言い換えると、「組織のスリム化」は、組織学習を犠牲にしています。スリム化により、学習センターも消滅することになるのです。これは避けなければなりません。

さらに、組織が学習能力を獲得するには、もう一つの要素が必要となります。それは、中間管理層の協調性です。活動的な学習センターを作るには、中間管理者が互いに密なコミュニケーションを保ち、効率的に協調する必要があります。

学習センターは、組織表で中間管理層の間に広がる余白のようなものです。この余白が有効なコミュニケーション手段になれば、また、中間管理者が協調して組織の再編成を実施できるなら、目標に対し共通の意識を持つことができ、学習による改善効果は現実のものとなります。

反対に、余白が意思疎通や共通の目的意識の欠如を象徴するなら、学習は行き詰まります。中間管理者が孤立したり、争ったり、互いに牽制している組織では、学習センターができることはありません。

出処

2015-04-27

[]人材軽視

対象

加害者被害者
マネジャー=>チーム

どういうこと?

プロジェクトの成功は、チームに入れるメンバである程度決まってしまいます。

「最初に人材を揃えること」が最も重要です。人を採用したり、社内から新しいチームメンバーを選ぶ際に、優れた人材を選べれば、プロジェクトの成功は約束されたようなものです。結局、人なのです。人材はプロセスではカバーできません。

にも拘わらず、その人選は杜撰に行われています。

どうして?

最初のメンバ選定で決まってしまうのは、メンバの本質が、プロジェクトの最初と最後で大きくは変わらないからです。

確かに、マネジャーは、メンバの潜在能力を発揮させるよう、指導しなければなりません。こうした人間形成、人間育成も管理の本質です。しかし、この成長幅を計画に折り込むのは、現実的ではありません。

両親であれば、何年もかかって子供の人間形成につとめます。しかし、メンバがメンバとしてとどまる期間はそれほど長くありません。マネジャーが、メンバの人格を変化させるほどの影響力を持てないのが普通です。メンバが最初からその仕事に適していなければ、劇的な良化は起こりえません。

チーム編成を間違ってしまうのは、チームに入れるメンバを選ぶ際に、間違ったフィルタを使用しているからです。

まずは、見かけで判断してしまう、ということです。

「人を見かけで選んではいけない」といったことは、だれでも知っています。しかし、奇妙なことに、採用の際の失敗のほとんどが、能力でなく外見に捕らわれた結果です。

生物の進化プロセスは、基準から大きく外れた人々に対する、ある種の不安感を頭に植えつけました。普通の人は、おそらく無意識に外見的に「魅力的」「標準的」な人を選んでしまっています。潜在意識下であるため、この傾向に抵抗も感じなければ、認識すらありません。

次に、潜在的に組織としての「標準」を押し付けてしまう、ということです。

「標準的」という見方に縛られるのは、個人的な傾向だけでなく、組織的な傾向としても見られます。

プロジェクトのメンバは、プロジェクトマネジャーの小さな帝国の一部となり、その上のマネジャーの帝国の一部となり、さらにその上のマネジャー、というように職制をさかのぼります。あるマネジャーが適用した「標準」は、単にその人だけのものではありません。そのマネジャーは、その上に存在する会社の全組織階層を代表して、人を選んでいます。

何か新しい提案をしようと考えるたびに、上のマネジャーの「標準」を感知します。この無意識のうちの圧力が、会社の平均像に近づけるように働き、誰もが好みそうな「見かけ」「しゃべり方」「考え方」を持った人の採用を助長します。

社風が健全な企業では、この影響は無視できるほど小さいものです。しかし、不健全な社風の下では、そうはいきません。

たとえば、企業で、服装規定を強制することがあります。制服着用を強制するほど極端でないにしても、個人から自由裁量の余地をかなり奪います。こうしたことが起こりはじめると、その影響は深刻です。同じようなことしか、話したり考えたりしなくなります。本当に役に立つ、オリジナルな仕事はパッタリと止まります。

優秀メンバほど、自分たちが仕事上「本当の価値」で評価されているのではないことに気づきます。つまり、プログラミングのよる貢献が、髪型やネクタイほどには重要でないことに気づきます。そして、遂には、会社を辞めてしまいます。

最後に、能力テストの限界です。

その人の能力をテストすることは、有効な手段です。そもそも、能力を見ないで採用するということは、たとえば、曲芸師が必要なとき、お手玉などその曲芸を見ないで、採用するのに等しい行為だからです。

ただ、能力テストは、採用された直後に担当する作業のみを対象としています。その後、その人がチームの中で行うであろう、開発に関わるその他の多くの作業について、適性があるかどうかまでは判定できません。さらに、そのチームのメンバとうまくやっていけるかどうかも不明です。

どうすれば?

採用の際、固定観念や先入観を持たないようにします。

人間は、経験を積むにつれて、友達を選んだり、友達と親しい関係を結んだりする際に、基準からずれたものを恐れるという固定観念を克服することを学びます。採用のやり方について、この学びを生かすようにします。

チームのメンバの服装が乱れようが、ネクタイをしめないでいようが、気にしないようすることです。

「標準」という画一性への要求は、管理の側面における不安定性の兆候です。しかし、スーツを着て、ネクタイをしながらプログラムしても、効率が下がることはあっても、上がることはありません。チームの誇りの対象は、チームメンバが成し遂げた成果だけです。

チームにフィットするかどうかを確かめるために、「オーディション」を開催します。

ソフトウェア開発は、技術的というより社会学的なので、機械とコミュニケートする能力よりも、作業者が互いにコミュニケートする能力によって成果が左右されます。採用にあたっては、少なくとも社会性や、人とのコミュニケーションのやり方の特徴に注目する必要があります。

応募者に、過去にやった仕事の一部について、10分から15分の発表をするように依頼します。たとえば、「新技術を初めて試みたときの経験」「管理が困難なものと思い知らされたときに得た教訓」「特に印象のあるプロジェクト」といったものです。開催日を決め、新採用者の同僚となる予定の人たちで聴衆を編成します。

応募者には、これを開催する理由、つまり「候補者のコミュニケーション能力を見るため」「採用されたら同僚となるはずの人たちを採用面接に参加させるため」ということをよく説明しておきます。

オーディションが終わり、応募者が帰ったら、講評会を開催します。各人が、その人物の作業への適応性や、チームにうまく適応できるかどうかについて、コメントします。

採用の可否を最終的に決めるのはマネジャーの責任ですが、将来の同僚、つまりプロジェクトメンバーからのフィードバックには計り知れない価値があります。新たに採用された人が、チームにスムースに受け入れられる可能性が高くなります。

オーディションについて、ひとつ注意があります。

業務と密接に関係のあることを話すように、候補者に念を押すことです。たとえば「正しい男女関係」といった、業務と直接関係のない話は、興味深い分野なので、うまくだまされやすくなります。話し手の情熱を垣間見て、それにひっかかるのですが、その情熱は、仕事上では見ることができません。

出処

2015-04-24

[]プロセス改善プログラム

対象

加害者被害者
会社=>チーム

どういうこと?

現場レベルのプロセス改善はいいことですが、標準のプロセス改善プログラムに良いことはありません。

これはチームの仕事の邪魔をします。

どうして?

有能なプログラマが、プロセス改善活動に巻き込まれてしまいます。

プロセス改善の制度化に取り組み、プロセスレベルを上げようとしている間、プロジェクトそのものから目を離し、やったことのない、得意でもないことに力を集中させなければならないのです。

そもそも、標準のプロセス改善プログラムには、無理があります。

プロセス改善プログラムは、「一つのサイズですべてに合う」究極のモノです。それは単に会社全体で「一つのサイズですべてに合う」のではなく、全世界で「一つのサイズですべてに合う」と言っているのです。さすがに、改善プログラムがフリーサイズがあるというのは言いすぎです。

標準のプロセス改善プログラムは、矛盾を含んでいます。

プロセス改善プログラムの標準は、組織の開発能力を、固定したモデルで測ります。モデルにぴったり合えば合うほど、より高い評点が得られ、レベルが上がります。評点が最も高ければベストです。ただ、すべての組織が最高の評点を取ったとしたら、すべてがベストなので、当然、全く同じやり方で仕事をすることになるはずです。しかし、現実にそんなことはあり得ません。

「プロセスそのもの」の価値にも、過大評価があります。

ユーザにとって最も価値がある製品を作る組織が競争に勝つはずです。退屈な製品を作る組織は、これらを効率良く作ったとしても、競争に負けてしまいます。つまずきながら開発しても、高い価値がある製品を作った組織が、退屈なものを効率よく作る組織に勝つのです。プロセスは、それがやる価値があるプロジェクトでないかぎり、なんの価値もありません。

真の利益をもたらすプロジェクトは、真のリスクを伴うものです。

ユーザの想像力をかき立て、財布をはたかせるものは、「新しさ」「革新性」「発明性」を持つプロジェクトです。それさえ満たせば、日程が1年遅れ、コストが3.5倍かかり、システムテスト中に山のように問題が発生し、会社で最も有名な混乱プロジェクトであっても、ベストプロジェクトになりうるのです。リスクを排除することが目的化してしまっているプロセス改善プログラムは、こういったプロジェクトにフィットしません。

どうすれば?

プロセスに重きを置くことをやめにします。

プロセスは、そこで働く人の邪魔をしなければ良いのです。そこで働く人の補助になればよい程度のものです。

組織として重きを置くべきは、「人」とその「役割」の方です。ソフトウェアは人や人のつながり(コミュニケーション、チーム)で創造されるものです。

出処

2015-04-23

[]チーム内競争

対象

加害者被害者
マネジャー=>チーム

どういうこと?

チーム内の競争を促すことは、意味がないどころか、弊害しか生みません。マネジャーの以下のような行為は、チームを破壊へと導きます。

  • 年次の給与または功績の見直し
  • 目標管理
  • 大きな功績を成し遂げた特定の従業員の表彰
  • 功績と結びついた表彰やボーナス制度
  • あらゆる形態の成果の評価

どうして?

競争で犠牲になるのは、健全なチームでは広く行われている、気楽で効果的な仲間同士の「コーチング」です。

固く結束したチームを観察すると、仲間同士のコーチングを、ごく当たり前に行っています。チームメンバーは、互いに知識を伝えあっています。コーチングがうまくいっていると、やっている人はほとんど意識していません。それをコーチングだとも思っていません。それは自然な行為だと思っています。

コーチングは、チーム内が相互にうまく作用するための重要な要素です。

個人の成長ばかりでなく、チームの協調作業の土台でもあります。コーチングは、互いによい気分をもたらします。過去に自分をコーチしてくれた人たちに、大きな借りがあると感じ、他の人にコーチをすることによって、気持ちよく借りを返しているのです。

しかし、相互のコーチングは、自分たちが安全であると感じなければ、起こりえません。

まさに競争という雰囲気の中で、コーチを乞うたら、狂気の沙汰だと思われます。お互いに助け合うはずがありません。競争の中では、むしろ、足の引っ張り合いが始まってしまいます。

どうすれば?

チームメンバーに格差をつけて報いる行為を、やめるようにします。

目標管理は、管理上の責任逃れの口実です。仕事に追い立てるための、単純で外因的な動機づけ手法です。マネジャーが、「投資」「直接的な個人への動機づけ」「配慮の行き届いたチーム形成」「スタッフが辞めないようにすること」「実行中の作業手順の分析と再設計」といった、困難な問題に取り組まないことの言い訳にしているのです。

チームのメンバーに敬意を持って接するようにします。

子育ての場合、兄弟姉妹同士の競争心を育んでしまうのは、両親が子供達に情緒的に愛情深く接していないときです。それと同じように、チーム内の競争心は、マネジャーの、メンバに対する「尊敬」や「愛情」の欠如によって育まれます。チームのメンバを尊敬して、気にかけていれば、そのようなムードにはならないはずです。

出処