プロジェクトの「銀の弾」はあった
ワタシがある部署のマネージャになった頃、見渡す限りオジサン、おにいちゃんと紅一点の女性というむさ苦しい男女比率だったのですよ。男性が多くなると部活のように言葉遣いは乱暴になるし、コミュニケーションも粗雑になるんです。なぜなら、見ている異性がいないから。同性だと自分と同じだからいいだろうと甘えるんですね。
あと、その部署の前のプロジェクトでは女性のリーダ比率がとても高くて、過去経験してきたプロジェクトより生産性が高かった印象を持っていたんですね。その代わり、男性よりズバズバとコメントをいただいたりして「容赦ないなぁ」と思ったこともありましたけど。まあ、そのあとフォローしてもらえるところが女性の優しさというか。
それとそのプロジェクトのリーダを見ていると男性より女性の方が優秀に見えていました。というよりは、リーダやサブリーダなのに「この人大丈夫かな」という人が少なくなかったんですよ。そうした経験を持っているので女性のリーダは男性より優秀という印象が残っているんですね。
だから、男女比率を恣意的に変えようと思ったんです。あと、ただ女性を増やすのではなくて、子供を持っているママさんシステムエンジニアを上手に活用するといいだろうと。
働いているママさんは保育園に送り迎えしていることが多くて時短をしているし、子どもが熱を出すと迎えにいかないといけないから仕事も職場ででしかできないとみんなに迷惑をかけていると思ってしまうと面談で聞いたこともあってリモートでできるように色々裁量の中で手を打ったんですね。
＃そう思い返すと、セキュアなリモートワークって随分前からやっていたことに気づいた
もちろん、新人も女性を喜んで引き受けたし、中途も女性で。偶然といえば偶然ですが。
いつの間にか、男女比率がだいぶ変わりました。そうすると何が起きるかというと、コミュニケーションが変わるんですね。挨拶はするようになるし。
あとですね、同性だと違いがはっきりしないのですが、とはいえ、一人ひとりの違いはありますが、性が違うと違いが特徴的に違います。雑談をしていても関心を持っている領域が違います。
既存のメンバにとってはデカルチャーですよ。見ていて面白かったです。こちらは意識的に変化をさせていましたから。ネタを仕組んだ方なので完全に上から目線でニヤニヤしてたんですよ。
そういった変化はプロジェクトにも影響を与えます。天然ボケだったのに重大な見落としを見つける契機になったり、きめ細かいフォローで作業の進捗を管理したり。
あと、「責任持ってやりなさい」と突き放すというか、責任を意識させるのは女性のリーダの方が多いと思います。言った後にフォローしていましたが。
これ、銀の弾なんじゃないですかね。ただ、この銀の弾を活かすためにはプロジェクトチームとかの纏まりにしておかないと効果が発揮できません。個人ごとの活動だけだとコミュニケーションが淡くなってしまうんです。なので、プロジェクトごとに組み替えてもいいですがチームにしてあげることが銀の弾として使うコツです。
経験が少ないプロマネはリスクが読み取れないから条件闘争に持ち込めない
システムエンジニアも経験を積んでもらって数人をまとめるリーダができるようになって欲しいし、さらに少人数のプロジェクトマネージャ（と言ってもプレイングマネージャだけど）をできるようになって欲しいし、できればビジネス的に大きいプロジェクトマネージャができるようになって欲しい。
マネージャになれば、そう言うことを常々思っているのです。
でも、現実はそうはいかなくて。さまざまな理由があるのだけれど、欲しいときに欲しい人材、つまり、プロジェクトをキャリーできる人材がいない事態に直面するのです。
こうした悩みはウォーターフォールやアジャイルなどのシステム開発手法に関係なく生じます。システム開発手法は手段ですからね。どちらかといえば、プロジェクトマネジメントの管理手法に関連することです。なぜなら、人材に対する要求は事業目標の実現が起因であるし、それを実行する過程で案件が取れると人材の不足が露呈するからです。
たまに見かけるのは、実際に案件が取れて、いざプロジェクトマネージャをと探してみたけれど、（探す前からわかっていたはずですが）適任者がおらず、経験不足のメンバをアサインしていたり、業務ドメインが違うメンバをアサインしていたり、アサインされるメンバが扱える人のキャパシティを超えたプロジェクトにアサインしていたりとプロジェクトの立ち上げる条件からリスクをマネージャ自ら抱えてスタートさせてしまっているプロジェクトです。
足らない部分を他のメンバとの組み合わせでチームとして補完関係が取れる構成になっていればまだしも、そうしたことの手当てもせずに始めて最初から自爆炎上となっているような場合はもう、目も当てられません。
大概、こうしたアサインをするマネージャは押し付けますね。できるよね、とか言って。それできませんと言えるのはベテランで自分の力量がわかっているシステムエンジニアだけですって。経験の少ないシステムエンジニアは、自分の経験が少なかったり、形式知が少なかったりするから案件の情報からリスクが読み取れないんですよ。だから、できないとも言えないし、やってもいいけれどと条件闘争に持ち込めないんです。
まあ、後に起きるのは悲劇というか喜劇というか。
そうなることは誰の目にも分かりそうなのだから喜劇でしょうけれど。そうなることを読み取れない取り巻きも同じ類いですけどねぇ。もし、そういった状況に立ちあわせたら、条件闘争になるようにアドバイスをしてあげないと共犯ですからねぇ。後々面倒に巻き込まれますって。いうことは言っておきましょうね。
この世界の片隅に
気になっている。観に行きたいがスケジュールが調整できるか…レイトショーになっているかどうか…
中華の調味料とか補充せねば
ほんとは中華街にでも行って、ご飯食べながら買い物したいけど。
チームが成立する基準を評価しないとプロジェクトは失敗する
チームが機能していないプロジェクトを立て直すとき、チームの状況は様々だけれど、同じような特徴を持っていることが多いのです。
- 機能不全になっているリーダに判断を仰いでいる
- チームとして必要なスキルセットが不足している
- チームに必要なリソースが提供されていない
- プロジェクトの情報が個々人に分散している
これらの４つの事象はいくつかの問題を孕んでいるのです。
プロジェクトチームというよりはプロジェクトを始める前提から満たしておらず、プロジェクトチーム（チームが成立していないのにチームと呼んでいいのか）としては機能不全であり、qualifyできない状態であるから始めてはいけない。これは、項番２と項番３が該当します。
プロジェクトを計画するにあたり、チームに必要なリソースは人的、物理的、情報的に充足されていることが「プロジェクトの遂行を計画的に行う上で最低ラインですから何か欠けてもプランBを検討せざるを得なくなります。最低のラインを満たしていないのであれば、プランBとしてのリスク再評価が必要になるし、そうした元々必要とするリソースを削っていくことはプロジェクトを自ら難しくしてリスクを増やしていることを理解しなければなりません。これは項番２と項番３が該当します。
更に言えば、プロジェクトを遂行する上で計画に基づく役割、これも人的なものもあるし、物理的なものもありますが、それらが機能しなければ、計画時との差異を明らかにし、対策を立てなければチームは機能を欠如したまま失速することになります。人的にはロールが機能していなければその役割がボトルネックになるため不全な状態になりますし、リソースを流れる情報が偏ったり、隠蔽化されればオーバヘッドが生じ、計画していない事態が起きることになります。これは項番１と項番４が該当します。
たった４項目の事象のうちのひとつでもプロジェクトチームに存在するのであれば、チームは持っているポテンシャルを発揮することは無くなります。チームが抱える課題をカバーするように可視化されないまま運用で成果をアウトプットしない作業として続けられるのです。
チームが成立する基準に達しているか。それを評価し、不足しているところをメンバの良心に期待せずに対策することがチームを機能させるために必要です。
ハーバードで学ぶ「デキるチーム」5つの条件―チームリーダーの「常識」
- 作者: J.リチャードハックマン,J.Richard Hackman,田中滋
- 出版社/メーカー: 生産性出版
- 発売日: 2005/10
- メディア: 単行本
- クリック: 1回
- この商品を含むブログ (2件) を見る
あなたの、細くてその好きさが伝わりにくいけれど好きなSEの仕事は何ですか
システムエンジニアの仕事にも様々が仕事がありますよね。その様々な、を分ける切り口を変えたり細分化するとそれこそ細かすぎて伝わりにくいために変に性癖を晒すことになるかもしれないけれど。
パッと思いつのくはプロジェクトマネージャやアーキテクトや営業という職種で分けるわけかたですね。これはシステムエンジニアなら自分の専門技術とかの肩書きが名刺に入っていますよね。
その職種の分類でいえばワタシはプロマネが好きな仕事です。あっちの端からこっちの端までのプロマネの仕事全部が好き。面倒臭い作業もあるけれど嫌いな作業はない（ハズ）ですね。
別の切り口でというか、スペシフィックにというかピンポイントでこれが出来たとき、多分、アドレナリンがドバドバ出ているというかにんまりしている顔をしていて傍目から見てキモいおじさんになっているかもしれないお仕事もあります。
そのお仕事はプロマネならプロジェクトでのチームの作業の骨格になるもの。でも、プロマネだけの仕事じゃないですね。業務ドメインを持っている、言い換えれば専門の業務知識が必要な業務システムを作るシステムエンジニアでも上流工程でやっていることです。
何かと言うと、業務プロセスの設計を真っ新から作って運用し始めるところが好き。
・前提条件や制約条件をヒヤリングしたり
・登場人物を整理したり
・一番手間のかかりそうにない手続きを考えたり
・見易いデザインで表現したり
こんな面倒臭そうなところをパパッとイメージ化して、業務オーナーや現場で回す人たちやプロジェクトならチームのメンバと話すのが好き。
それで、「これいいね」と言ってもらえたときが嬉しい。
そう言えばどうして業務プロセスの設計が好きになったんだろう、なんて思ったんだけれど、多分、そうしたプロジェクトの業務プロセスの標準化をしていた時期に「仕事を一人前にできるようになったかも」と自分に自信を持てるような結果を出せるようになってきたからかもしれない、と思ったりするのですよねぇ。
実際、それで数百人のプロジェクトが動いていたのも事実なので。担当をふってきた当時のリーダからは相応にプレッシャはありましたけれど。
「業務プロセスに１日の無駄があると１日で数十人月予算が無駄になるからね」
当時は、そうならないようにチェックするのがあなたの仕事でしょ、なんて思っていましたが。まぁ、でもそういうプレッシャがないと業務プロセスを考えるときに仕事としての動線を感が尽くすようにはならなかったかもしれませんね。
何が幸いするかなんてわかりません。
結局、自信を持てるようになった仕事、職種じゃなくて、スペシフィックな細くてその好きさが伝わりにくい作業が好きな仕事なのかも。
あなたの、細くてその好きさが伝わりにくいけれど好きなSEの仕事は何ですか
