メンタルダウンの部下を持ったら

なんとなくタブーな気がしないこともないけれど。でも現場にはメンタルダウンしてから復帰しようとしているエンジニアもいれば、まさにメンタルをダウン仕掛けているエンジニアもいると思うのです。でも現場のエンジニアもマネージャもメンタルダウンの専門知識はないからどうしていいのかわからない、とも思うのです。

突然複数のメンタルダウンの部下が

ある組織のマネージャになったんですね。そこそこの規模の組織だったのですが、着任後、人事関連の方から呼び出しがありまして。

「あの方とその方とあと…はメンタルダウンなんですよ。それで…」

 まあ、そうなんだ、としか言いようがないですよね。病気ですから病気と付き合って仕事をしてもらうんだな、他の疾病もそうだし、みたいな感じしかリアクションは取れないんですよ。

マネージャは病気の専門家ではない

 人事関連の方の説明を聞いて自分に言い含めたのは、自分は専門家ではないということでしょうか。

素人考えで病気の部下に対して業務以外のことをあれこれ指示なんてできません。ただ、できることは予備知識として人事関連の方から教えてもらうことや書籍から知識として知っておくことは出来ますね。そのくらいの情報は持っていないといざというときに間違ったアクションを取ってしまうかもしれませんから。

リソースとしてカウントしない

 マネージャとしては辛いところですが、リソースとしてカウントしない方が良いでしょう。あくまでもリソースとしては。組織の一員ですから病状が良くなれば、産業医と復帰プログラムを開始することになります。立場的には現場に復帰して貢献してもらえると嬉しいです。ただそれだけ。

焦らせない

他の長期疾病も同じですが勤務実績がなければ給与は出ません。勤務期間に応じて保険などから7割給付されるのですが、とにかく収入がないので本人は焦ります。

自分で負荷を掛けてしまうのです。

前のめりにさせない

長期療養していると、他のメンバに申し訳ない、迷惑をかけていると思いがちです。だから早く復帰して仕事で貢献したいと思っていることが多いです。

これもまた自分に負荷を掛けてしまいます。

納期のないチームのタスクなどプレッシャの少ないタスクから徐々に。

距離感

 メンタルダウンしているから特別に扱うことはなかったです。基本は他のメンバと同じ距離感の関係性を保つ方が良いでしょう。あまり深い意味はなく普段から希薄なので。

これはメンタルダウンだからということに限らないですが、個人の日常にどこまで踏み込むか、という関係性の考え方に依存するところだと思います。

自分から相手の領域に入るならある程度の覚悟が必要だと思います。関わるなら後始末を考えてからでも遅くはありません。 

メンタルダウンは多い

 仕事に対するプレッシャが高まり続けるとメンタルダウンで療養するメンバがじわじわと増えていきます。これは気づくと周りのかなりの数のメンバが程度の違いはあっても経験者だったり、療養中だったりしているということです。

幸いにも復帰できればいいのですが、メンタルは再発しやすいようです（人事関係談）。

メンバとしてなら普段どおりに接する他なく、マネージャなら急がさせず一つひとつステップを踏ませて現場復帰出来るようにアサイメントをする以外は出来ることが限られると思います。

くれぐれもメンタルダウンの専門家でないことを忘れないように。

もし部下がうつになったら

クラッシャー上司 平気で部下を追い詰める人たち (PHP新書)

調達 薬用石鹸

薬用石鹸、いつも使いがいつの間にかディスコンになってた…

【純日本製】最高峰シルク“生糸”の５本指靴下-紳士用２足組『くつしたの下』生成り/蒸れ・水虫にも

透明レスタミン石鹸

薬用アルボース

エンジニアのキャリアデザイン・アンチパターン

タイトルにつられたんだね。実はアンチパターンというほどのものではないんだ。なぜなら、パターンになっていないからね。まぁまぁ、折角寄ってもらったのだし、もう少し話を聞いていっても良いじゃないか。

キャリアデザイン

エンジニアの仕事に就いてそのままエンジニアでいたいと思ってもエンジニアになってみると実は色々な専門職で構成されていることを知るわけですが。

希望する専門があって、それで応募して採用されて、実務も希望する専門でやっていければそれはそれでよかったね、なのですが、多くのパターンはSEとかザクッとした採用で採用されてその組織の事業に割り振られて…がほとんどですよね。

仕事なんてマネージャのアサイメントに全くもって依存しています…と思ったら多分、今後やりたいことが出てきたときにチャンスを掴めないかもね。 

アンチなキャリアデザインは、流されて使われて中程度の待遇で終わってしまうパターンだと思います。同じ仕事をするならやりたい仕事をしたいでしょうし、待遇だってやった分だけはもらいたいですよね。

キャリアのロードマップ

 専門性をもつエンジニアの仕事は細かすぎるし組織に依存するところが大きいので一歩ひいて眺めることにするとエンジニアの仕事は3つに分けられます。

エンジニア→プロのエンジニア
　　　　　＋プロマネ
　　　　　＋マネージャ

エンジニアもずっと今のポジションで良いのかと問われたら評価されてレベリングしたいと思うでしょう。給与に連動したりするので。

そこは組織でキャリアコースがあるならそれを知らないとアプローチがあべこべになってしまうので、お作法はお作法として理解しておきましょう。 

ロードマップのアンチは、組織の育成ロードマップに自分が希望するロードマップをマッピングせずに他人任せにしてしまうことです。マネージャは将来の事業を担うエンジニアかどうかをこの瞬間もしています。

アサイメント

 いくらキャリアデザインを考えても、実践がなければ実績にならずキャリアを積み上げることはできません。

アサイメントするマネージャは、実務経験あり＞なしで確実な方を選びます。育成目的があれば別でしょうけれど。

誰でも最初は未経験ですが事前に予備知識を得ることは誰にでもできることです。でもやらない人の方が多いのはキャリアデザインを具体的に考えていないからいつ、どんな準備をしておこうと考えないのでしょう。

 じゃあ、これを読んでやりたい仕事、実現したいキャリアがあるなら準備をしておきましょう。あとは、目標設定のときにどういったエンジニアになりたいか将来像を伝えてマネージャにすりこむことも忘れずに。

アンチは…キャリアデザインのロードマップを作ってもマネージャに伝えないで自分の中だけで持っていることです。伝えなければ優先してアサイメントされません。

転職

 今の仕事が向かない、組織の事業ではやりたい仕事がない。だから転職する。そういうケースは少なからずあると思います。

転職するなら準備と調査はしっかりやってくださいね。人の意見をそのまま鵜呑みにしないことです。自分で判断するように。

でも、転職する前に組織の中で組織内転職、つまり、異動でやりたいことを実現できないかを考えてみることをお勧めします。何より、社内なので給与体系は同じ（そこに不満を持っていなければ）だし、知った同僚との仕事の方が多いでしょう。

社外への転職はコミュニケーションコストと転職後の貢献プレッシャが半端なく高いです。それを踏まえた上で、社外への転職の方がメリットがあるかどうかを一度は検討してください。

ブラックやハラスメントが蔓延しているような組織なら即刻転職ですが。

エンジニアとして世界の最前線で働く選択肢 ~渡米・面接・転職・キャリアアップ・レイオフ対策までの実践ガイド

「３びきのかわいいオオカミ」とは

セブンネットなら在庫があるらしい。 

３びきのかわいいオオカミ（セブンネット）

３びきのかわいいオオカミ

3びきのかわいいオオカミ (大型しかけえほん)

環境に流されると技術的成長が止まってしまう

もう20年くらい前のプロジェクトでのこと。ふと「このまま今の仕事をしていると二度とコードを書く機会はないのでは」と焦燥感を感じたときがあったんですね。

いえ、前に書いているとおりコードを書く技術レベルが低いのは自分がよく知っていることですけれど。それでもアサイメントされて期待されている仕事はそれなりに出来ていると思うと「今はこのままでいいかな」と心の隙を自分で作ってしまうんですよね。

そうした心の隙は自分の選択の積み重ね、自分の判断のつながりだから誰にも責任を転嫁することは無意味なのです。コードの技術レベルが低いなら自分でOSSのコードを読んだり、アルゴリズムをトレースしてみたり手を動かせばいいだけでそういうことは誰も何も言ってくれないんですよ。だって、何を感じ、何を考えているかは誰も知りようがないのですから。

プロジェクトにアサイメントされるということはそのプロジェクトやプロジェクトの中で担う役割があって何かしらエンジニアとして働く環境が構成され、その構成された環境にひどく引っ張られてエンジニアは仕事をすることになるのですが、そうした外的要因が良い面にも働くし悪い面にも作用することを経験値的に気づけることができるエンジニアもいれば、置かれた環境に順応してそのまま埋もれてしまうエンジニアも出てきます。

ここ最近、切り口を変えてTLを賑わすエンジニアの勉強のあり方は、前述したプロジェクトの環境に依存するのではないかと思うのです。何が依存するかといえば、アサイメントされて置かれる環境に馴染むことを優先し、実際慣れてしまうとその環境の居心地がそこそこであれば大方のエンジニアは環境に流されてしまうということです。

環境が新しい技術の更新を必要としなければ、エンジニアは業務上必要とされない技術は必要に迫られたときまで関心を示さないでしょうし、それは、新しい技術を必要に狭された当事者になっていないからです。

新しい開発手法に関心を示さないのは、プロジェクトの環境が開発手法を変える必要がないからです。まず最初に導入された開発手法は、外的要因、それも変えなければその存在を失ってしまうほどのインパクトがなければ変更されることはありません。製品サポートの打ち切り、ビジネスの転換などを目の前に突きつけられなければ。

結局のところ、エンジニアも一度にひとつのことしか出来ませんから、何かしらを選択しているわけですが、この環境に要求されず時間だけが過ぎていくということは、エンジニアの技術的な成長を促すにはエンジニア自身の身の上に起きるであろう災いが降りかかってくることを想像できるか否かにかかっているのだろうと思い至るのは自分の経験値的から言えることかと思うのです。

 まあ、だからいくら勉強しないとと言っても困っていないのでそれで技術的な取り組みを始めるエンジニアが少ないわけで。

そういうことがひとつの答えだとすると、ローテーションで強制的にプロジェクトを変えてしまうのは技術習得を強制するのでエンジニアの技術的成長の観点では良策なのかもしれません。

マッピングエクスペリエンス ―カスタマージャーニー、サービスブループリント、その他ダイアグラムから価値を創る

プロジェクトにおける技術的課題の進め方

こちらの記事を読みながら技術の実現性検証ってモノ作りの頭かその外でやっておかないと技術的リスクがコントロールできないんだよなと思い浮かべたり。実際、ウォーターフォールでも技術課題は（リスクコントロールするつもりなら）やるし、事業企画でも正にフィージビリティスタディするしなぁ、と。

www.ryuzee.com

なぜ技術的検証をするの

技術的検証をする理由を挙げると…

• 顧客要求が想定している適用技術で実現できるか不確か
• 論理的には実現できるが顧客環境で実現できるか不確か

などなどいくつか出てくると思います。 

 技術的検証をするのは、それをやっておかないとあとあとできませんでした、となる可能性がプロジェクトとして認識しているからです。言い換えれば、今やばそうだとわかっているのに出来るかどうかを今確かめないということは将来のプロジェクトがトラブルかもよ、ということです。

技術的検証をやらないとどうなるの

 ある技術的を適用することを想定していたとします。もし、何かの理由でその技術が適用できなくなったとしたらどうするかを考えてみましょう。

• プロジェクトを中止する
• 技術が適用できるようになるまで待つ
• 別の解決方法を検討する

プロジェクトの中止をする方が一番コストインパクトが少ないですが中止をすることで業務課題の解決を先送りするのでビジネスインパクトはホールドしたまま、となります。

技術のアップーデートを待つのは待っている間コストか掛かりますし、いつまで待てばいいのか問題も出てくるので今ひとつです。

別の解決方法を検討するのが一番世の中で取られている選択肢ではないかと思うのですが。ただ、これも想定していた適用技術と比較してコストが掛かったり、業務課題の解決に制限を設けたりする副次作用が出てくる可能性があります。検討しないとわかりませんが。

どこまで技術的検証をすればいいの

 本番環境が用意できるのであれば想定する環境を全て用意して検証すればいいです。リソースが確保できるなら検証したい項目を全部検証しましょう。

でも、現実的にはどちらもできないことの方が多いです。NWを使用した負荷テストはNWの仕様により対象にできる機器が限定されるでしょうし、当てられるバジェットも限られるでしょうから、検証項目は厳選されるでしょう。

物理的な制限とリソース的な制限下で、論理構成上の要素を確保しつつ項目を優先順位づけします。

他に気をつけることは

 技術的検証をする際に外部からの制約となる制約条件やそれに引っ張られて実施できる技術検証のスコープとゴール設定をステークホルダと合意してください。

特に、技術的検証では時間も限られるのでどこまでの検証項目を必須とするか、線引きを始める前にしておくことあとあと揉めなくて良いです。

もう一つ、技術検証自体でトラブった場合、どこまで突き詰めるかも方針としては決めておいた方が良いです。そうしないと本体のプロジェクトが引っ張られますから。

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

デスマの成分が少ないです

お勉強が好きな人が多いかどうかは別にして必要に迫られてという人は少なくないと思うんですよね。御多分に漏れず規格の本を読んだりしましたし。

でも、ですね。どちらかいうと必要に迫られて読む本より読んでおこうかなという感じで書籍で勉強をしたり、会合で人と会話をすることでぼんやりと考えていたことや方向づけの裏付けとして他者の意見や経験談を教えていただいたりすることもままあります。

やはり、必要に迫られての方が切迫した締め切りなり準備期間満了だったりがあるから実戦で使う確率は多くなるのですがたまに方針転換やアプローチ変更で空振りとなったりすることもあるのですけれど。けれども、まあそれは勉強をして使うときの話なので使いかけた、手をつけた、使い損なった、と繋がっているので良いとは思うわけです。それで、勉強したけれどしただけのはどうなんだ、と。

書籍も相当売れ行きが悪いので価格が上がっていますからね、特に技術書は。

とは言え、使わないなら勉強するのは無駄だ、というつもりはないんですよ。例えばこんなノベルがあって今期アニメでやっているところもあって（まだ未視聴ですが）原作を読んでみようか、と。

デスマーチからはじまる異世界狂想曲 (単行本)

これもコミュニティのTLの中でアニメ化された「デスマから」がタイトル詐欺だ（デスマ成分が少ないという意味合いで）というコメントを見かけたら読もうと思ったんですね。

勉強というよりはどんなデスマかいなという興味とデスマ成分の割合を知りたくて読んだんです。デスマを実務では経験したくはないですし、できれば関わりたくないですし。第三者としてどんなものかと覗くくらいにしないとSAN値が削られるので。

それで読了したわけですが、292ページもあるのにデスマは5−10ページの６ページ相当です。それだけ。ガッカリです（何が）。独特の描写になれず、半ばまで読んでようやくリズムになれましたが、この異世界俺つえー系ってどうなんでしょうね。経験するたびにスキルを獲得していくあたりの構成が続巻で回収していくのでしょうけれど。

ところで、デスマの成分って何もシステム開発の専売特許ではありません。システム開発の上流であるコンサルだってありますし、スポンサーサイドの顧客側だってあります。というか、発注者側の方がデスマですね、常態的に。失敗るとキャリアが傷つきますからね。そりゃ必死です。兼務多いし。１人月を超えているのは顧客サイドなんですよね。だから、いくらシステム開発のプロジェクトで顧客レビューしたくて召喚してもキーパーソンはレアキャラだったりSSRだったりするわけです。

で、ひっくり返すんですが。

コンサルは顧客にバカですね、できていませんねというお仕事ですが、アウトプット（成果物と書かないのは準委任契約、つまり請け負える成果物を決めて見積りできるような調達仕様を顧客が書けないほどぼんやりした要件だからだけど）は契約時と変わっていることの方が多いのは顧客の中のドキュメントの書きっぷりや構成やカウンタの担当者のマネージャの趣味などで切り口を変えられるからなんですけれど。単価高いし、次もご指名いただきたいし、スポンサーの意向に合わせるのもコンサル業の仕事のうちですし。このご意向が強すぎたり後半に近づけば近づくほどデスマ成分が増えていきますね。これまでのセッションで積み上げてきたマテリアルがパーにならないようにしないといけませんし。ダメならスパッと…。

顧客サイドの企画業も企画したらそれを実現するフェーズに入りますから、ケツ持たないといけません。それをマイクロマネジメントされるわけです。企画だからなんちゃらPとかみたいなチャラい感じでやっていられるのはある意味で才能があるのだと思います。真面目なのはエンジニアの特許ではないですし、企画の人は高学歴が多いので頭切れますからね。別世界の話ですが、やっぱりそこにもデスマはあるのは前述したとおりで。とにかくやることが多いですね。見ていると不憫です…。

とここまで書いて本より現実の世界の方にデスマ要素が多いんだと気づくなど。 

デスマとオフィスラブって…。

デスマーチと銀の弾丸 (メリッサ)

デスマーチに追われるIT技術者が勉強せずに英語力を身につけてキャリアアップした方法

プロマネ現場読本 デスマーチを乗り切るために持っておくべき知識のすべて