メンタルで壊れたエンジニア

ある部署のマネージャの辞令が出たので、翌月初に職場に行きます。当たり前ですね。新しい職場でのお仕事なのですから。

そのオフィスは以前のオフィスとはそれほど違いのない、その組織の社員にとっては普通のオフィスだし、そのフロア自体他のフロアとそれほど違いは感じなかったのです。

ただ、メンタルダウンのエンジニア複数人が部下になった、ということが違いでした。

人事部門から

呼び出しというよりは情報共有のための打ち合わせの場を持ちましょうとメールが届いたので、打ち合わせの日時にご指定の会議室にお伺いするわけです。人事部門には顔見知りがいるのでそれほど遠い存在の部署でなかったのは身構えるハードルがずいぶん下がりましたが。

メンタルダウンのエンジニアの状況、対応方法などの情報を聴きながら感じたことが一つあったのです。

「(メンタルになったエンジニアは大変だ…)」

人事部門から伝えられた情報共有の中で一番重要なことは、人事部もマネージャも

「専門家ではない」

ということです。これは行動指針としてとても重要なことです。

メンタルでない専門家でもない

少なくとも人事部門も当時の組織のマネージャであったワタシも当時はメンタルではない方の人である、というポジションにいることを認識しなければいけないのです。

考え方、行動、受け止め方全てが自分の状態にいるポジションで考えて判断してしまうのです。その上、人事部門やマネージャはメンタルの対処を知っている専門家ではありません。

なので、例えばメンタルのエンジニアと会うときに専門家ではないことを忘れずに、脊髄反射でそう言ったことを配慮をせずに言葉を返すことは避けなければなりません。

復帰プログラム

療養の状況が良好で且つ産業医が合意すれば現場に復帰するためのプログラムが始まるのはどの組織でも同じでしょう。

・最初は職場に通うことに慣れること。
・次は、順次就業できるように慣れること。

定期的に産業医のチェックが入り、最終的に復帰可能と認められて初めて職場に戻って来れます。

お帰り

職場に戻ってくるという意味合いでは「お帰り」ですし、一緒に働くという意味では「初めまして」ですが、その前の復帰プログラム中に会い、会話をする機会があるのでどっちも、なのですが。

目の届くところで

メンタルでない病気からの復帰であっても長期療養からの現場の復帰であれば段階的に現場に戻すように、メンタルなエンジニアも段階的に戻すのが良いだろうと思います。

ただ、SIプロジェクトのようなスケジュールのプレッシャーが高い仕事に従事させることは加減がコントロールできず、とてもリスキーです。

プロジェクトでの業務量のアサインは加減できるかもしれませんが、

・プロジェクトマネージャや周りのエンジニアが専門家でないため復帰直後では不安が多い
・スケジュールのプレッシャーが高い業務は避けたい
・何より長期に渡り療養していたエンジニアは迷惑をかけていたから貢献したいという思いがかなり強い

というマネージャではコントロールしきれないことが多いのです。

なので、マネージャの目の届くところでのんびりと復帰して欲しいのです。ただ、メンタルなエンジニアはこちらが思っている何倍もの引け目を感じて現在の状況を超えた成果を出そうとするのです。

復帰できるエンジニアもいるし、できないエンジニアもいる

経験値から言えば、復職できるエンジニアの方が少ないという現実があります。ただ、復帰できるエンジニアもいるのも事実です。様々な理由でメンタルが壊れたと判断されたエンジニアは少なくないようです。

メンタルで壊れたエンジニアを増えてしまうと

ここに怖い将来があります。それは何かというと、メンタルで壊れてしまうと長期に療養が必要となります。そして幸いにも復帰する壊れたエンジニアより復帰できないエンジニアの方の割合が多いのです。

また、メンタルで壊れてしまったエンジニアは毎年新規に増えているという事実もあります。そうです。年を経ることにメンタルで壊れ復帰できないエンジニアが積み上がるのです。

そう言った自体は避けたいです。できることは壊れるエンジニアをこれ以上作らない仕事の仕方を作ることです。それこそマネージャの仕事なのですが。

 

 

ジョイ・インク 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント

 

 

 

 

SIerでは新規事業は成功しない

とある偉い方と話をしているときに

「新規事業が一向に進まなくて」

と愚痴をこぼされていたのですが、よくよく聞くと

「(それじゃ無理じゃないかなぁ)」

と思ったのですが、その話をなぜそう思ったか過日思い直してみたらそりゃそうだと改めて気づいたのでした。

人月商売の呪い

経営者が新規事業を立ち上げたいと思う理由は、人月商売から離れたいからです。人月商売は、所属しているエンジニアを売り切ってしまったらそれ以上の売上の成長は見込めません。売る商材がエンジニアなので。

実際は、売れないエンジニアは居るものですし、売れない理由も様々です。経営者は利益を最大化したいけれど、売れないエンジニアと売上増加の限界をみてジレンマするのです。

組織のあり方について

組織の中のリソースを使うことを無意識に考えるので、新規事業を担う部署を既存の組織におきます。

この時点で新規事業は失敗しているのです。既存組織の中に置くことは、新規事業の組織管理が既存の組織管理の理論が持ち込まれます。

これでは新規事業のリソースが見えないところで既存の間接コストで目減りしてしまうのです。

権限について

新規事業に関する権限は、その組織のオーナーが全てを持っていなければ事業の判断のタイミングを逃してしまいかねません。新規事業は、半年後ではなく1ヶ月後に世の中にリリースして先行者利益を確保し、投下する資金を回収しなければならないからです。

既存の組織に組み込むと権限分掌が進んでいるので物事の判断は各部門にお伺いをたてることなるので新規事業の求めるスピードと違いすぎるのです。

資金について

新規事業に必要な資金を、多過ぎず且つ事業継続の期間に必要な分だけは確保しておかなければなりません。その資金は、新規事業を担う部署の中で決済が済む必要があります。

資金は既存組織の中で経営に権限を持つ役員がファウンダーとして担うのがベターだと思っています。

KPIについて

経営指標であるKPIは、既存の組織のものを持ち込んだ瞬間に新規事業は既存ビジネスの派生ビジネスか類似ビジネスになってしまいます。それを新規事業と呼ぶならそれも結構ですが、それなら既存組織の中で現状の延長線上でやればいいのです。

例えば、稼働率というエンジニアの稼働状況をみる指標がありますが、これは新規事業ではあてはまらない考えです。なぜなら、新規事業に関わるエンジニアは100%新規事業の開発に関わるからです。KPIを設定するなら別の指標にすることが必要です。

プロダクトマネージャについて

何よりコレを作りたいと思っているプロダクトマネージャを担う人材が必要です。得てして

「既存組織の中のリソースを割り当て、さあ、新規ビジネスを作りなさい」

と言いますがこれも間違いです。

新規事業を起こすことで人月商売を始めるなら、何も既存のリソースでやる必要性は全くありません。資金を出すオーナーの役員が社外で見つけてきてもいいのです。既存組織の中でやるという思考それ自体がすでに既存ビジネスの延長であり、新規事業を始めるスタートラインにたどり着けていないのです。

 

なので既存組織の枠組みで考えるSIerには無理なんだろうなーと思っています。

仕事で失敗すると怒られるからと始めると失敗するよ

仕事をするとき、まあエンジニアも人ですから失敗はしたくないものです。

 

怒られるから失敗したくないの?

不思議と失敗した後のことを想像するときに最初に出てくるのが「怒られるから」失敗したくないと口に出します。出しますよね、ね。

「誰それに怒られるからやめなさい」

と子供のことから言い聞かされてきたからかもしれません。それって、判断基準が自分の意志で行えない外部に依存した物言いなので自分の言葉として使いませんし、ワタシの子どもにも意識して使わないですけれど。

 

失敗したら後片付けが大変だから

仕事で失敗したら怒られる。それよりは失敗したら後始末が面倒になるから失敗しないようにしたい、と思っているなら大分マシですね。だって、失敗しても自分でかと片付けをしようとする意志が確認できるので。

 

仮に失敗したらどうなるかというと、失敗するまで進んでしまったことを取り返しができる地点まで巻き戻すことと、取り返しができる地点から達成したい目的地まで進むことの2つをやらなければなりません。

 

だから失敗すると大変なのです。でも失敗したってわかるまでに何やっているんですか。

 

失敗は実はそれほど起きない

ところで仕事で失敗ってあるのでしょうか。自分で担当した仕事の後片付けできないほどの状況になったら失敗なのかなぁと思うのですが。

 

と考えに立つと、手に追えなくなるほどにならなければ失敗ではない、ということです。ちょっとやり方を間違えた、途中で違うと言われた、くらいなら軌道修正すれば良いのです。

 

それ、失敗ですか。

 

試行錯誤なのではありませんか。いいじゃないですか。得たい結果を得るための経験です。次は同じ間違いをしなくて良いという経験知を得たのです。間違いを学習しないで同じ間違いを繰り返すのなら、それは問題がありますけど。

 

仕事が試行錯誤なら上手くできなくて当然

反対に上手くやりたいと思うことはあるでしょうか。仕事を今回も、今回は、どっちかわかりませんが上手くやりたい、と。

 

気負うのはわかりますが気負いすぎると思考を無意識に制限してしまったり、緊張して体が思うように動かなくなってしまうこともありますよね。仕事なんだから成り行きでしかなりませんから、到達したいところにいかに着地するようにできるかの調整の連続でしか対応できないと思うのですけれど。

 

なので、仕事は上手くやろうとか失敗をしなようにしようと思って始めないことです。仕事を始めるときにそんなことを考える暇があるなら、実現しようとしているやり方の検証をした方が時間の使い方に価値があります。

 

最後まで片付けるならそれは失敗じゃないです。あと、上手くやろうとも思わないことです。こんなふうに終わりたいたいな、そのためにこうしたらいいのかな、と終わるための手続きを考えましょう。

 

「君の名は。」今日からBD予約開始

どれ選ぼう… 4K版かのう。

 

Amazon限定4K UHD+BDコレクターズ・エディション Amazon限定BDスペシャル・エディション Amazon限定BDスタンダードエディション Amazon限定DVDスタンダードエディション
Amazon限定特典その1(描き下ろしA4特製フレーム) × ×
Amazon限定特典その2(特殊加工ポストカード2枚組)
早期購入特典(特製フィルムしおり)
4K UHD × × ×
本編ディスク 2枚 1枚 1枚 1枚
映像特典ディスク 3枚 2枚 × ×
封入特典 100Pブックレット、縮刷版台本、ミニキャラシール 100Pブックレット、ミニキャラシール ミニキャラシール ミニキャラシール

理解の手抜きは怖い

あるエンジニアの仕事ぶりを見ていると、ときどき

「(その対応でいいのかな)」

と思うことがあるのです。言葉にせずに内心で思っているから()書きなのですけど。例えば、打ち合わせに参加していて率先して打ち合わせで議論された内容をまとめてくれたところまでは積極的に仕事をしているね、と。

その打ち合わせには参加していなかったので、後から情報共有をしてもらったときに冒頭の印象を持ってしまったのです。

それは、まとめた資料の内容について前提や考え方についていくつかまとめた資料だけでは理解できないことがあったため、前提や議論の範囲や方向性などを尋ねたら

「それはAさんの意見なのでわかりません」

という答えが返ってきたからです。

「(いやいや、あなたはその会議に出席していたのでしょう。積極的にメモを取っていたのなら議論している内容について理解していないとおかしいでしょう。でなければ、その会議になんのために出席していたのかな)」

下線部の前後は後付けですが、下線部分が最初に脳内で浮かんだフレーズで、前後は脳内の暗黙の文脈を言語化したものです。

その場でカタをつける

前述の会議の、その場で議論されたことが理解できていないとしたら、その会議の時間は単なる議事録取りででしか得たものはないのです。

会議の性質、フォーマルなものかインフォーマルなものかによりますがエンジニアが技術に関する会議の場で特段専門性を必要とする技術がテーマである訳でもない場合にはその場で理解できていないことはその場で解決しておかないと会議が終わった後にもう一度理解し直すために時間を使うことになります。まだ、調べれば良いのですが、往往にして調べる時間も取れなく、次第に忘れてしまうことの方が多いのです。

まあ、専門性の高い議論や自分の専門外の技術の話であれば話は別ですが。

手を抜くとツケが回る

会議の場で理解をしきらないでいる習慣をつけてしまうと議論の内容が実は後で自分に降りかかってくることだってあるのです。

その場でわからないことを聞くことをしないのはその場その場でわからないことを解決していくということに対して楽な方を選択しているのですが、実は手を抜いているのです。あとあとにツケが回るのですけど。

怖いのが技術についての理解の手抜きです。普段からの習慣がエンジニアなのに技術の理解をすることに対して楽という手抜きを続けているといつの日か何もできないエンジニアになってしまうのです。

 

 

情報の精度は石橋を叩くように待っても得られない

エンジニアが作成する資料には様々な用途で作られるものです。その用途を理解し、使われる目的に応じてアウトプットしないと作った資料の価値を自ら無くしてしまったり、いつまで経っても完成できないままに時間切れとなってしまうことだってあるのです。

石橋を叩いて渡るという諺があります。意味は「石橋を叩いて渡るとは、用心の上にさらに用心を重ねて物事を行うこと」でそれから色々と派生の意味合いもあるようです。

kotowaza-allguide.com

特に注釈の用心し過ぎるの部分が作成する資料の目的により適切なケースもあるし、そうでないケースもあるのです。

【注釈】 壊れるはずのない強固な石の橋を、一応叩いて安全性を確かめて渡ることから、用心し過ぎるほど用心深くなることをいう。
慎重すぎる人や臆病すぎる人に対して皮肉をこめて使う場合もある。

引用 同上 

 それを判断する基準が資料の用途です。

用途を理解する

用途は作業したアウトプットの目的を実現して行うものです。目的が具体的に目の前に現れている状態にあるということです。

エンジニアが作成する資料のうち、石橋を叩いても確証を得ておきたいとか裏を取っておきたいようなものには設計書などの仕様書類が挙げられます。

確かにこれらの資料に曖昧さがあればその資料から作成されるコードに曖昧な処理が混入してしまったり、その前に曖昧さをコーディングできずに手戻りすることが想定されるのでそうした書きっぷりは排除したいことの一つです。

一方、要件を引き出したり、解決案を思案する際には、制約や前提を置いた上で仮説を資料上に表現し、検証を進め評価したりします。

ここでの情報は全てが確定することができないために仮説から一時的な判断を行い検証をする流れにするのですが、その際の資料は確からしさを求めるよりは、考え方を仮組みしてその考え方の正当性を確かめることに価値を置いています。

この場合は、叩いて壊れないことを確かめるよりは渡れそうだと仮説を立て、叩く範囲、叩く方法を限定して前に進むことを目的とします。

用途により価値の優先順位が違うということを理解しましょう。

情報は必要な時に揃わない

前述した後者の用途の場合、資料を作成するときに必要だと思う情報は全て集まりません。集まらないからといっていつまでも待っていたらその資料はいつまで経っても出来上がりませんから作業が完了しません。

でも作業には期限、タイムボックスがあります。どこかで手離れしないといけない。手離れするためには、どこかで決断しなければなりません。

そういうものだ、と腹を括ってください。

でも、そうはいってもと思うなら、条件をつけてください。

・5月9日時点の情報に基づく
・参考資料ABC

など調べて裏付けを確保できているところはここまで、と明記しておきましょう。

情報の精度はいくら石橋を叩いて待っていても期限までに上がりませんし得られません。情報の精度が必要な資料であれば、待つのではなく期限までに得られるように取りに行く、精度より時間を優先するのであれば、条件をつけてだす判断をする。

そうすることで用途にあった価値を持つ資料を作ることができます。

 

 

週後半に進捗で困らない作業の仕組み

どこかで読んだのだけれど勉強会は週の前半の方が後半より出席率が高い、つまりキャンセルされにくいのだそうです。当然ながら、後半の方がキャンセル率が上がるということです。これも、気軽に参加申し込みをポチったり、キャンセルをポチれる勉強会だからかもしれなくて、有償のカンファレンスが週の後半だったら支払い済みの対価があるので同じ傾向にはならないでしょう。

どうして勉強会は週の後半だとキャンセルされるのか

単純な話で、行くつもりだったけれど行けなくなったからです。病気や私的な急用はさておき、それ以外の理由は仕事での進捗が遅れるからです。遅れているのに定時になったら勉強会にいけるかといえば、行ってしまうと翌日が大変になりそうだと予測がつくから行くのをやめてしまうわけです。

逆に、前半の勉強会の出席率が高いと言われるのは週の前半であればまだ進捗のヤバさを認識していないか、どうにかなると見切ったか、終わる目処がついているからです。

まあ、単なる図太い神経をしているだけかもしれません。

予定どおりに進捗しないのは誰?

仕事をしていれば理解できると思うのですが、仕事は予定していたように進捗しません。逆に、スイスイと進捗していると何か忘れているのではないかと不安に思ってしまうこともあります。

予定どおりに進捗しないのは、

・予定を立てた前提で相違が生じている
・予定していない割り込みが入ってきた
・予定していた見積もりが甘かった

などが起きるからです。

 

ただこれ以外で一番の原因があるのです。それは、

・進捗させなかった

です。

どういうことかというと、今日はここまで終わらせないといけないはずなのに終わらせなかった、ということです。そうですね、今日終わらす予定の作業を明日に持ち越した、ということですね。そして、拙さの原因はそれを許してしまった自分の判断があった、ということです。

進捗のコツ

自分の判断の甘さが進捗を止めてしまったのであればどうしたら確実に進捗させることができるのでしょうか。

作業をする上で、確実に進捗させるには2つの観点で仕事を終わらせれば良いのです。一つ目は、仕事のやり方に必要な仕組みを揃えることです。二つ目は、単純作業にすることです。

一つ目のやり方に必要な仕組みを揃えるとは、終わらせるための仕事の仕組みを組み立てるということです。手順や必要な情報、完了させるための基準を揃えて、これでできると段取りを完成させるのです。もちろん、一度も経験していない場合は、肝心なところは検証して裏付けが必要です。

二つ目は、一つ目で確立した作業の仕組みを単純作業として終わらせることです。言い換えれば(やるのは自分一人かもしれませんが)パワープレイに持ち込むことです。単純作業化できれば、あとは時間の確保だけなのです。

1日の作業も2段階で進める

この2段階で作業を進めるやり方は、1日のうちの作業も同じようにすると良いです。作業の仕組みを考え仕組み化する時間とそれを検証したりパワープレイにするように1日を使うのです。

2段階で作業をする習慣により、週の初めから進捗するようになりますよ。