仕事は正常な判断ができるまでしかやらなくていい

on

まなめはうすのニュースサイト亡き後、ニュースサイトなどに取り上げられることはないのかなーと思っていたら、さまざまなめりっとに例のツイッターが入るなんて考えてもみなかったなー、というこでリンクを貼っておきます。最後のほうね。

人気ツイートデイリーランキング（2016-10-07） - さまざまなめりっと


一昨々日くらいはツイッターの通知がひっきりなしだったけれど、RTやいいねが倍以上のツイートが多くあって、それ通知をオフにておかないとスマホ触っていても落ち着かないよなーと思うなど。


ところで、昨日、こんなことをツイッターでつぶやいたんですが。



会社入った頃の職場は、みんなで残業をするような職場でしたが独身ばかりでゆったりと仕事をしている感じでしたね。当時は今ほどビジネスのスピードが速くなかったですし、世の中的にもゆったりしていたんですね。担当していた仕事では自分ができなさすぎて週末にでてきても終わらなくて迷惑をかけた（これは今思えば完全に自分のやり方がよくなかった）、なんてこともあったけれど。


なので、月に８０時間くらいの残業をすることは最初から慣れてしまった自分がいたわけですが、プロジェクトによってはたまに「残業するな」というのもあってそんなときは今みたいに何か技術書を読もうなんて微塵も思わなかったし、何かを作ろうなんて思いもしなかったのは今思えばもったいない時間の使い方をしていなあと。


で、この流れは電通の事件を踏まえてシステムエンジニアがそうしたデスマになったときにどう切り抜ければいいか、ワタシの経験から何かを伝えられればいいかと。



このまとめの日付だけだと、１０月から１２月の３ヶ月のことですが、つぶやいていないことでもいろいろあったのかと思います。コンプライアンス、秘守義務的な面もあるから大人になると仕事自体のことは公けにか機記すことはできないという事情もありますし。


さまざまな案件、プロジェクトから離脱することができたからこそ言えるのが「あのプロジェクトはひどかった」というおじさんシステムエンジニアの飲み屋での自慢話でそんな話には耳を貸す価値はありません。あえて一つあげるなら、そうした人と一緒に仕事をしないほうが良いのかもしれません。書き込まれないために。


以前ブログに書きましたが、プロジェクトの要件を満たすためのQCD（品質・コスト・納期）と時間のどれか一つが満たしていないとデスマになる可能性が高まります。だって、QCDと時間が揃ってはじめてプロジェクトの要件が達成されるのですから。当たり前なことですよね。


これも以前に書きましたが、デスマなプロジェクトがあってそのプロジェクトのサブプロジェクトを立て直す案件がありました。偉い人が直々に席まで来て、頼み込むわけです。名指しで名前が挙がっているけれど「やるか」と。当時、別のプロジェクトを持っていましたがそれを引き継ぐならと引き受けたわけです。はい。担当していたプロジェクトとご指名いただいたプロジェクトを持っている情報から判断したら、そうなるかと。断り方もいろいろあったんですが。


簡単に言えば、サブプロジェクトが滅茶滅茶なので立て直してほしい、あれは誰それがすると条件を向こうから出してきたんですね。条件が先方から出てくるほどの地雷臭濃い案件です。とにかく、酷いんだな、としか思わなかったですね。


ミッションを自分で設定する
条件が出てきたからということもあったのですが、役割を明確にしておくことは仕事をやる上で、とても大切なことです。これはデスマでなくてもとても大事なこと。自分が担う仕事は何を終わらせれば完了と言えるのか、責任を果たしたと言えるのかの基準になりますから。


対外的な役割のバウンダリ、内向きのバウンダリをはっきりしておくこと。これはチームメンバの役割を決めることにもつながるので曖昧にしておいてはいけないのです。


これは、プロジェクトマネージャをする際にも、社内的には誰に報告をすれば良いか、プロジェクトマネージャの責務を超えた課題の判断が必要な場合、誰の判断を仰げば良いかを明示的にしておかないと、プロジェクトで起きたことを全部自分で背負わないといけなくなってしまうんです。こういった状況自体が間違っています。


なぜなら、組織の中で案件の影響度合いにより判断するポジションが違うからです。役割に応じた役職が付いているのですから、責務としての正しい人に判断を仰げるようにこちらから働きかけることが必要なんです。できる上司なら向こうから配慮してくれますけどね。


どこまで頑張るかを決めておく
実際にサブプロジェクトに参加してみたら、それは言葉で表すことを憚れるくらい酷い状況でした。日中も夜もいろいろありました。あるとき、

「自分の限界はどこまでかな」


と思ったくらいです。そのときに心に決めたことは、ワタシが


「正常な判断ができるまでしかやらない」


ことにしよう、とワタシ自身に誓ったことです。だから日々、自分に問いかけます。自分の過去の経験から今の負荷はどの程度までか、と。それは気力もありますが、一番に気にしていたのは体力です。体力がなければ続かないのですよ。長時間労働になっていましたし。チームメンバの誰より早く来て、終電ギリギリにプロジェクトルームからメンバを追い出して帰るのが日課になったり、週末は土曜も平日と同じように働いたり。


でも、ワタシがしんどいならメンバだってもっとしんどいはずです。だから連勤をさせてアウトプットの不良を自ら作らせてはいけないという考えもあって、必ず休日は作りました。ワタシ自身、その休みにはジムに行って運動をすることで体力を維持することを続けていたのです。思うように体を動かしておくことがどこまで続くかわからないプロジェクトのデスマを乗り越えるためにも必要ですから。


システムエンジニアには体力が必要だと体育会系のように揶揄されることがありますが、運動をしている間に自分の体調と精神面をリフレッシュしておかないと正常な判断ができなくなるかもしれない（幸いにワタシは切り抜けた）ので、体力は必要なんですよ。


デスマを変えるもの自分
昨日のブログ「2016-10-08 - 室長のひとりごち」に書いたようにこうしたデスマのプロジェクトでは受け身では何も良くならないです。ぜんぶ、自分で変えていく。連日終電でも状況が把握できれば仕事の仕方、チーム内のコミュニティーを変えていく。変えていかないと「君たちを守らない」とまで言い切ってまで変えていく。それを毎日変わるまでやっていく。


先に手を打つんですね。近い将来を見据えたアクションと先々を見据えたアクションの２つの手立てを打っておく。どう変えていかは、やはり経験が生きたわけですが、経験だけじゃなくて、それまでに読んだ本や会話して覚えていたことと自分の中で混ぜ合わせて作り上げたアイデアを駆使してやってもらったんです。


まあ、「失敗してもそれ以上に悪くなることはないよ」と思ってやれば気楽に、何度でも挑戦できますから。


あとは周りを巻き込みことです。最初に自分のミッションを明確にすると述べましたが、チームや周りに対してワタシができること、やって欲しいことを遠慮なくリクエストしてしまうんです。だって、サブプロジェクトを成功させることについて誰も異論を挟む余地はないわけです。


あとは思っていなくてもとにかくワタシの代替をしてくれた人には感謝を、変えたいと思っていたことをやってくれたメンバにも感謝を「言葉で」つたえることです。


変えるのは自分です。夜のうちに妖精さんがプロジェクトをデスマから救ってくれることはありません。


でも、自分の限界を超えそうになる、つまり、自分が正常に判断できなくなるとわかったらとっとと退散することです。それはしていいんです。仕事だから。もっと適任者はたくさんいますから。それを対応するのがマネージャですからマネージャに仕事をしてもらいましょう。