プロジェクトメンバーの特性を解析する
ＩＴ企業においてソフトウェア開発を行うメンバーとしてプロジェクトに参画すると、たいていの場合このようなユースケースが備わっているかと思います。
設計から取り掛かる人をエンジニア、プログラミングだけ実施する人をプログラマーと呼ぶことも多いかも知れませんが、プログラミングをまったくしないエンジニアや設計をしないプログラマーというのも通常考えにくいためあまり切り分けなくてもいいでしょう。
プログラミングだけをアウトソースするような特殊なケースもありますが、その場合はコードを書く人のことをプログラマーではなくコーダーと呼ぶのが自然かもしれません。
「エンジニア」と「プログラマー」をわざわざ区別することは、両者の間にヒエラルキーがあるかのような認識につながりやすくなってしまいます。事実、この２つを明確に切り分けているＩＴ企業ではおおよそ単価を
エンジニア ＞ プログラマー
としているところが多いのではないでしょうか。しかしこれは欧米的な考え方が理解できる人にとっては非常にナンセンスであることがわかります。
なぜなら、プログラマーのプログラミングスキルがエンジニアのプログラミングスキルよりも優れていて、エンジニアもプログラマーもそれぞれがそれぞれの領域においてプロジェクトにとっては不可欠な存在であるならば、それは同じ価値を有しているということになるからです。
本来「エンジニア ＞ プログラマー」となりえるのは、エンジニアのプログラミングスキルがプログラマーのそれと同等レベルでありながら、かつ設計スキル等プログラマーにはないスキルを有しているからこそ成り立つものです。しかし、プログラマーにエンジニアにはもちえない高いスキルがあるのであればエンジニアとプログラマーはそれぞれの領域において全く同じかそれ以上の価値があるということになります。
単純な肩書きといった表層部分のみで判断してしまうことほど愚かしいことはありません。
…さて少し脱線してしまいましたが、「エンジニア」と「プログラマー」をわざわざ区別することでヒエラルキーがあるものと誤解を与えてしまううえに、プログラミングが設計やテストと比べて相対的にレベルの低い作業であるかのように思われるのは本意ではありません。
ゆえに、ここではエンジニアもプログラマーも一律「プロジェクトメンバー｣という言葉を用います。そのうえでユースケースを少しひも解いてみましょう。
仮眠する
プロジェクトメンバーは30Hz程度の超低クロック数（人間の脳波は最も周波数の高いβ波でも20Hz程度）で動作していますが、超並列処理（脳細胞は140億個程度あると言われており、同時に活性化（興奮）しているのはわずかであっても、万単位のオーダー並列処理が行われている。たかが十数個のCPUしか持たない現在のコンピューターとは比較にならない並列度になる）を行っているため、驚くべき処理能力を発揮します。
コンピューターで人間とまったく同じ思考パターンを実現することが難しい理由の１つでもありますよね。
"設計する"、"プログラムを書く"といったユースケースは、プロジェクトメンバーの体力や精神力を徐々に消耗させるので、ユースケース"休息する"は大変重要で業務上はずせないものとなります。
ブラックな企業体質を擁護するわけではありませんが、プロジェクトメンバーが一時的に徹夜をしている…といったプロジェクトは見ようによってはまだ楽な方かもしれません。なぜなら、短期的な頑張りで挽回できる程度の遅れや状況で済んでいるということだからです。
慢性的に残業が多くなり、終電でも帰れない日が続くようになるとプロジェクトメンバーには
「日中の生産性が落ちると、残業する意味がなくなる」
という判断ロジックが働き、ユースケース"仮眠する"が起動されるようになります。
そんな仮眠の際によく使われるツールは「椅子」です。
このユースケースにおいても経験を多く積むことによって、ユースケース"仮眠する"に対応した処理は最適化されていきます。私も20～30代は頻繁に実施したおかげ（せい？）で、椅子を３つ並べれば熟睡することができるようになりました。あと、電車の中で吊革さえ持てれば立ったまま熟睡するスキルも身につけました。
進捗を報告する
一般的に周知されていることですが、何を評価するにしても基準を持たない評価ほどあてにならないものはありません。
これは進捗管理においても同様のことが言えます。
毎週おこなわれるプロジェクトメンバーからの進捗報告で、ある機能の「実装／単体テスト」が30%→60%→80%と順調に推移してきたのに、ある時から
85％→90%→92%→92.5%…
などと足踏み状態になることは日常茶飯事です。ときには90％だった進捗が80％に戻ったりします。これを、『90%シンドローム』と言います。
プロジェクトメンバーが、報告時の進捗率をどのようなアルゴリズムで計算しているのかをあるところでリバース・エンジニアリングで調査したところ、実際の進捗(x)と報告上の進捗(y)との間には以下の関係が成り立つことがわかっているようです。
ｙ＝21.7logex
逆に、進捗報告を受けた側が実際の進捗を知りたい場合は①の逆関数である以下の式を使えばよいことになります。
y=ex/21.7
この関係をグラフに整理すると､次の図のようになります。
つまり、プロジェクトメンバが「70％です」と報告したとしたら②の式によって実際には25％程度しか終わっていないことがわかります。
X理論、Y理論
米国の産業心理学者、ダグラス･マクレガー氏が提唱した｢X理論、Y理論｣というものがあります。MBAで有名なグロービスのなかでも取り上げられているお話なので、比較的有名かもしれません。
平たく言えば、
Ｘ理論
労働者は放っておくとサボるので、仕事をするように仕向けなければならないという｢性悪説｣に立つ考え方。
Ｙ理論
やりがいのある仕事が与えられれば、労働者は喜んで働くという｢性善説｣に立つ考え方
です。
どちらが良いとか悪いとかって話ではなくて、これらは人によって有効性が異なるものです。組織の中で一律どちらかを選択する…というものでもありませんが、Y理論を前提としたマネジメントを行うマネージャーのほうがよりよい成果を収めるというのがマクレガー氏の見解です。
そしてこの理論は、プロジェクトメンバーとプロジェクトマネージャーの関係にも当てはまります。
しかし、プロジェクトメンバーを含む開発者たちはそれほど単純ではなく、Ｘ理論で説明される側面とＹ理論で説明される側面とを常に両方あわせ持っているのが実状です。
Ｘ理論に従う状態（以下「Ｘ状態」）と、Ｙ理論に従う状態（以下「Ｙ状態」）の２つのモードを持ち、何らかのきっかけ（トリガー）でモードを切り替えるのです。
当然ですがＹ状態にあるほうが生産性は高いし、プロジェクト内でのコミュニケーションもうまくいきやすいのは言うまでもありません。
Ｘ状態のプロジェクトメンバーは与えられた仕事しかこなそうとしませんし、結果として勢いや口数も少なくなる傾向にあります。うまくいっていないプロジェクトほど「しーん」と静まり返っており、初見では全員が非常に集中しているかのように見えることが多いため誤解されやすいので第三者としてチェックする際には注意が必要です。
Ｘ状態とＹ状態の状態遷移
プロジェクトメンバーがＸ状態とＹ状態をどのように遷移するのかを示したものが、次のステートマシン図です。
知る範囲では、ほぼ100％のプロジェクトメンバーがプロジェクトに参画した時点ではＹ状態にあります。世間で言うグータラ社員のように「あいつはちょっと目を離すとすぐにサボる」といったプロジェクトメンバーは、ゼロではないのかもしれませんがまず滅多に見る機会がありません（存在していたとしたら、採用なにやってたの？という話になってしまいます）。
進捗が順調でプロジェクト内の人間関係に問題がなければ、多くのプロジェクトメンバはＹ状態を維持します。仮にプロジェクトマネージャーやリーダーとケンカしたりして一時的に「仕事したくないな」という状態になることはあっても、その程度であればおいしいランチを食べるといった気分転換や愚痴を聞いてあげる同僚の存在などで大抵はＹ状態に復帰できます。
プロジェクトメンバーがＹ状態からＸ状態に切り替わるときは、必ずと言っていいほど継続的なストレスかモチベーションの低下がトリガーとなります。
「開発用ＰＣが貧弱でイライラする」
「休日出勤を何週間も強いられている」
「お客さまやプロジェクトマネージャーの発言が朝令暮改だ」
など理由はさまざまですが、Ｙ状態からＸ状態に切り替わる際にプロジェクトメンバー自身が原因となるケースはほとんどなく、たいていの場合は
「プロジェクトマネージャーの仕切りが悪い｣
「環境が悪くなっていても上長がフォローしない」
等といった事例が大半となっていると言うデータが出ています。
ウォーターフォール型の開発モデルと同じで、一度Ｘ状態に落ちてしまうとプロジェクトメンバーはなかなか自力でＹ状態に復帰できません。これはメンタルな病気等にかかってしまった場合も同じです。
基本的にはＸ状態に落ちるトリガーとなった要因そのものが改善されない限り絶対に復帰できないのです。
（環境が悪ければ）「環境を改善する｣
（過重労働を強いた場合は）「休暇をとってリフレッシュする｣
（人間関係に問題がある場合は）「プロジェクトマネージャを交代する」
など、プロジェクトメンバーが気分をリセットしてやる気を出すようにする手立てが必要となってしまいます。この場合、スケジュールやコスト的に大きなしわ寄せが発生することは絶対に避けられません。それが嫌なら、日ごろからＸ状態にさせないよう配慮するマネジメントが求められるわけです。
にもかかわらず、このとき実に多くのプロジェクトマネージャーや上司は間違った対応をしてしまいます。
「頑張れ」と口先だけで励ます
「遅れを取り戻すようにちゃんとやれ」とハッパをかける
「これじゃ、評価に響くぞ」とおどす
と言った対策がまさにそれです。何一つリスクや負担を負わずにプロジェクトメンバー個人の努力で改善を促そうとします。刺激を与えてやる気を出させようという作戦なのかも知れませんが、そのような行為はさらにＸ状態に深く沈みこませることにしかなりません。
いわゆる休職や離職というのは、そうした果てに起きていることなのです。
いいなと思ったら応援しよう！
