Take's Software Engineer Blog

TOEIC200点&プロマネな私が社内公募を経て、ソフトエンジニア&英語部門へ異動して奮闘していく話をしていきます

炎上という名の・・・

私の仕事はプロジェクトのとりまとめ役なので、炎上案件によく遭遇します。

そんなときに何をするかという点についてようやく、1本通ったので書いておく。

私の問題解決の方法の基本は大学院時代に叩き込まれている。

流れとしては

①問題、課題を見つけ、自分なりにとく

②課題を自分なりにとく

③課題を言われたようにとく

学部卒は3でよい、修士卒業は2でよい、博士までいくなら①まで必須といわれ、
①を目指すように言われた。そのときは仕事で役に立つなんて思わなかった。

 

目の前の敵:分解できない人たち

私の職場は修士卒、学部卒がいます。ぱっとみ違いはわかりませんが、①までできる人もいれば、③しかできない人もいる。リーダーとか機能担当者とかあまり役職とは関係ありません。
その前提でどんなふうに進められているかというと以下の3点。

 ①問題をばらさずに日程だけ引いて、進捗会を頻繁に開く
 ②問題をばらして、解ける状態にして、進捗会を頻繁に開く
 ③問題をばらして、②,③の人の能力を把握したうえでタスクを割り振り、進捗会を頻繁に開く

進捗会を頻繁に開くばかりじゃないか!といわれるが、本当に会議多いのよ。
(私はそんな面倒なことをしないので基本進捗会というみんなを集めて情報を聞くという行為はしません。)

炎上案件はどんな状態かというと①ばかり。日程引けば終わると思っているので、日程がくると無理に解決したことにするんですよ。だから穴をつくとぼろぼろっとなる。

自分なりのアプローチ

 ①問題を特定する
   why:なぜそれをやらないといけないのか?
  when:いつまでにやらないといけないのか?
  how:どうやってやるのか?
 ②①を踏まえ課題を分解する
 ③メンバーに割り当て、結果をまつ
②が終わったら別の案件に行きます。②までが自分しかできない仕事ですね。

①の前に自分が良くやるのはこれは解くべき問題なのか?という確認です。
誰のために解くのか問い詰めたりすると、案外解く必要のない問題だったり、問題設定を変えればすぐ解けたりするのでお勧めです。
代償としては上司や先輩に事情聴取しないといけないので、反逆的にみえるのかもしれません。

まとめ

専門じゃないけど問題を解決しなければいけないというのが日本で働くうえで必須なスキルですよねということでまとめてみました。

似たような悩みや解決法をまとめている方もいるようなので、重要なのは自分がぶれない何かをもって解決するということじゃないかな。

vekitomo-0.hatenablog.jp

 

 

 

div #breadcrumb div{ display: inline;font-size:13px;}