これ僕.com:行動分析学マニアがおくる行動戦略

意図と行動のギャップから生じる「不自由さ」への挑戦。果たして僕たちに自由はあるのか?

チームを強くする動き(面談で色々と・・・)

昨日は会社の四半期面談というやつでした。面談される側じゃなくて、面談する側だけど。で、そこで出た話をいくつか。

優秀なAさんの仕事を減らすために、あなたができること

B君が面談の中で、「誰か一人に仕事が集中しないように、手が空いたら積極的に手伝おうと思います」と言ってくれた。それはそれでOK。是非、継続して欲しい。が、しかしだ。一人に作業が集中する場合、よくあるのが、その人が優秀だからその人じゃないとやれなくて集中してしまうってパターン。まぁ、そもそもマネジメント的にどうよって話ではあるんだけど、それはB君とは直接関係ない話なので置いておく。このケースにおいてB君が短期的にやれることは、ほとんど無い。が、しかし。中長期的に見れば話は別だ。
B君がやれることは、「自分に与えられた仕事を完璧にこなしてみせること」なのだ。これが何に繋がるかというと、まずは自分の成長。そして、「ああ、こいつはこの程度の仕事はこなせるほどに成長したんだな」という周りの信頼だ。この積み重ねが、優秀なAさんに「ちょっとこの仕事を手伝ってもらおうかな」と思わせることへと繋がる。そうして「Aさんにしかできないこと」が減っていくにしたがって、そのチームは強くなっていくのだろうと思う。
#ちょっと関連した話をここで書いたことがあるなぁ。

自分の役割からハミ出せ

今度はC君の話。C君にはプロジェクトで、ある役割が与えられている。というか、通常、プロジェクトには様々な役割があって、その役割を誰かが(時には複数の役割を)担っているわけで。で、各人がそれぞれの役割をちゃんとこなせば、そのプロジェクトは上手くいく・・・というわけでは残念ながら、ない。役割と役割の間には隙間があるんですな。
ソフトウェア開発ってのは、変換作業の連続です。要件⇒外部設計⇒内部設計⇒プログラムという感じに、大元のユーザー要望を段階的に「システムという形」へと変換しているわけです。ある作業から次の作業へのアウトプットは、ドキュメントやプログラム、あるいは口頭という形をとることになります。が、悲しいかな、完全ならざる我々の作業にはミスが入り込んでしまう。自身の作業の成果を、次の作業者へ伝える段階においても、ノイズが入り込んでしまう。で、例えば要件定義書に記述ミスがあったとして、問題はそれが誤りであることに気付き、かつ正しい状態に修正できる人は、主に要件定義の作業を実施した人自身だということだ。実装する人には、何が正しいのかはもちろん、それが誤りであることにすら気付けないことが多い。これが、私の考える「役割と役割の隙間」です。
だから、プロジェクトチームは、どうにかしてこの「隙間」を埋めていかなくてはならないのであります。実装者は設計書がおかしいことに気付けるよう、要件定義や外部設計の領域に足を踏み出す。要件定義者は設計書がおかしいことに気付けるよう、内部設計や技術レベルの領域に足を踏み出す。チームの人数が多いほど、こういった動きができないと、そのチームは脆くなってしまうのではないだらうか。プロジェクトメンバーが、自分の役割に固執してしまう傾向がある時、実はちょっとヤバイ状態なのかも。

点ではなく線で考える

あとで書く。 あとで書いた