Stories 1話：転職直後
このブログでは私の今までの経験をまとめて、参考になりそうなことを記載していますが、このカテゴリはちょっと毛色を変えて、私が今実際に直面している課題をどうやって解決していくか。
について、書き連ねていこうと思います。
その方が、ケーススタディとして使えるかもしれませんし、
生々しい話や「そうそう」と感じる話も、随所に出てくると思いますので
そちらも併せて参考にしてもらえればと思います。
さて、早速ですが
私は少し前に、3年ほど勤めた会社を退職し、
今は新しい会社で社内SEとして仕事をしています。
規模としてはいわゆる大企業と言われる会社ですが、
ITについては新しいソリューションや考え方に積極的で
そういうところは大企業っぽくない会社です。
入社時期は年末で、いわゆる管理職という立場で入社しました。
会社は大規模プロジェクトのカットオーバーを4月に控えており、
みんな目まぐるしい勢いで働いています。
また、周りのメンバーはこのプロジェクトに長いこと関わってきた人たちばかりで
私は唯一、右も左もわからないという状況です。
そして、問題のプロジェクトの状況はあまり芳しくなく
と思っている古参メンバーも、チラホラいるというような結構切迫した状況でした。
実際、私の経験上でも4月に無事にカットオーバーを迎えようとしているプロジェクトにおいて、1月段階で不具合をバンバン出しているものは見たことがなかったので
入社して早々ですが、
このプロジェクトはヤバいかもな
と感じましたし
過去にコンサルとして携わった炎上プロジェクトにかなり近い匂いが漂っていました。
そんな中、私は
リーダー1名
メンバー5名
という構成の、あるチームに参加することになりました。
仮にAチームとします。
4月カットオーバーに向けてのタスクにおいて即戦力として活躍するということは、さすがに期待されていなかったはずですが、時を経るごとにプロジェクトの状況は一進一退の様相を見せるようになり、いよいよ猫の手も借りねばカットオーバーできない
という状況になっていきました(笑)
こういった状況の中、入社したてである私がすべきことは
プロジェクト全体の中でAチームが関わっているタスクは何で
そのタスクについて、Aチームの誰がどう動いているのか
という事を把握したうえで
今時点で自分の価値を発揮できる場所を探す
という事になります。
入社したばかりとはいえ、
炎上プロジェクトをただ横で眺めているだけ
とか
何の役にも立たず、ただアタフタしているだけ
では、燃え盛る炎の中、一生懸命鎮火しようと死に物狂いで働いている既存メンバーの心中は穏やかではありませんし、無事にカットオーバーをした場合の4月以降のチーム体制に深刻な影響を及ぼしてしまいます。
炎上プロジェクトにおいて
まぁ、入ったばっかりだし、こっちも相手できてないからしょうがないね
なんて思ってもらえる事を期待するのは、あまりにも楽観的にすぎると言えると思います。
しかしながら、このプロジェクト自体とても息の長いプロジェクトで
紆余曲折を繰り返して、ようやくカットオーバーにたどり着いたという状況なので
プロジェクト全体の中でAチームが関わっているタスクは何？
という事を把握するだけでも、相当ややこしいことがすぐにわかりました。
プロジェクトが紆余曲折してきたせいで、システム配置がかなり複雑怪奇になっており
各システムが何をやっているかも正確に把握するのが難しいという状況です。
更にそれをややこしくさせているのが
会社全体として属人化が相当進んでいるという事でした。
ただでもシステム配置や機能がややこしくなっている所に
それを説明できるのは
ナントカさんならわかるかもしれないです。多分。
という有様です。
知る人ぞ知るというシステムが乱立しているような状況でした。
この深刻な属人化は配属されたチームでも同様で
リーダーのみが全てを把握しており、メンバーは理解が進んでいないので
勿論、これはリーダーのやり方に問題があるのですが
だからといって、リーダーを一方的に責める訳にもいかない理由もありました。
このプロジェクトはその規模感に見合わず、
元々はとても少ない人数でプロジェクトをこなしていた為
彼自身がリーダーでもあり、手を動かすメンバーでもあり、
すべて一人でやっていたという状況でした。
スケジュール的にまずいと感じたプロジェクトマネージャ陣が
五月雨式に人を追加していった為、
リーダーは
従来のタスクもこなさないといけない
人にタスクも振らないといけない
といったことを並行で行わなくてはいけなくなり、
結果、彼がとった行動は
という経緯がありました。
また、リーダー自身も若く、チームマネジメントについて誰からも教えてもらっていないという状況でしたので、この事態を招いたのはリーダーだけの責任ではなく
明らかにプロジェクトマネージャにも落ち度がある感じました。
実際、プロジェクトマネージャも
THE・属人化
THE・マイクロマネジメント
といった感じの人で、とても優秀な人なのですが
どうしてもタスクを手離れできない人で
私的には「個人としては優秀だけどマネージャ向きではない人」の典型でした。
こんな感じで
システム自体も相当ややこしい上に、プロジェクトメンバーの属人化も極まっていたので
プロジェクト全体の中でAチームが関わっているタスクはなにで
そのタスクについて、Aチームの誰がどう動いているのか
という事を把握すること自体が容易ではないことはわかりました。
そこで、最終的に私が最初にとることにしたアクションは
メンバーのやっている作業（手を動かしている）を一緒にやる
でした。
目的は
私がメンバーがやっている作業を理解することで、彼らの作業の目的を私が解明して、彼らに作業の目的を理解させる。
という事と
末端の作業を理解することからさかのぼって、システムの全容をつかむ
という事でした。
前者は先に述べた通り、リーダー以外は自分が何をやっているのかわかっていないという状況だったので、それを解消して、各人が自走できるようにする為でした。
後者はシステムの全容をつかむという意味では、遠回りのようなイメージを抱くと思いますが、今までの経験上、大枠から抑えようとすると、そのシステムの歴史の話や、政治の話とかが混ざってきて逆に理解がしにくくなることが多かったので、
「今」を知る為には、結局のところ「今、みんなは何をやってるの？それはどうしてやってるの？」を把握する方が早かったりする。という経験からこの判断をしました。
もちろん、ひっ迫した問題として前者の問題も合わせて解決できるというメリットもありましたし、作業目的を理解していなかったことによる、メンバーのミスも頻発していた為、これはこれで急務ではありました。
単純に
入ってきたばかりで役に立てるとしたらメンバーの負荷低減ぐらい
というのも、勿論あります。
正直、自分としては
プロジェクト最終盤で参画しているので、やれる事というのはさほど多くないと思っていましたし、貢献できるのはせめて目の前でタスクに押しつぶされそうになっている人たちに手を差し伸べることぐらいかもしれない。
と思っていましたが、結果的にはこのアクションは自分が思っていたよりも意味のあるアクションになりました。
コメント
コメントを投稿