エンジニアが辞めることでブラックな会社が反省するわけがない

日々、面倒くさいエントリを読まれている方には信じられないかもしれないが、自分がマネージャのときに部下が辞めたケースは、0件である。

精度高く言及すれば、自分はマネージャをしていたが上長が諸事情で退職を促した部下は若干いたが、それを知ったときはすでに話は決着をしていた。今更引っ繰り返すわけにもいかなかったのは、当事者も承諾していたからである。知らぬところで人事が進んでいることは組織の中ではない話ではない。

ところが、自分の手から離れて他の組織に移った途端、辞めている元部下が割といる。察しのとおり、辞めた元部下は全員優秀である。本人が辞める際にお礼と連絡をくれたときに聞いてみると、新しい職場での仕事はコンサルタントが多いのは優秀であることの証左だろう。

もちろん、そういった自分のキャリアを選ぶ元部下を祝し、移って落ち着いてからお祝いをする機会を持つようにしている。元部下にとって自分が初めてのマネージャで一人前になり、元部下が自分でキャリアを選び、満面の笑顔で会ってくれるのは嬉しいではないか。それに新しい場で活躍してくれれば、『俺が育てた』とドヤ顔する（しないけど）。

一方、組織の中の催しや何かのきっかけで飲み会に行くと年齢を問わず愚痴、不満をいう人もいる。エンジニア、マネジメント、本社管理部門スタッフと問わず一定の量でいる。はっきりいって、とてもつまらない話だし、飲んでいるサッポロビールは不味くなるし、後の会計で支払うとき何かを得たかと思い出しても何もない。だから最近は組織の中での飲み会はメンツをより選ぶようにしているし、ほとんど欠席である。組織の飲み会に喜んで行くのは自分の部下たちとの懇親会だけにしているといっていいほどである。それも機会をできる限り減らしているので、他の組織に比べたら半分もないだろう。今、自分と飲む人は自分が関心を持っている人だけであると言って良い。

Twitterを始めとしたSNSを見ていると、いつも会社の文句ばかり言っている割にはずっと同じ会社に居座っているような人が溢れかえっています。そんなに嫌なら会社辞めればいいのにといつも思います。多分多くの人が同じことを思っていると思います。

引用　会社を辞める覚悟を持つということ - 株式会社アクシア

自分の経験で愚痴を飲み会でいう社員は、愚痴を言うことで仕事上の不平不満と働き続けるバランスをとっていると思う。だから、辞めない。愚痴を聞いてもらうことでストレスを聞き手に付け回しているだけである。本当に辞める人は優秀だから口に出さないし、口に出すときは辞めることを決めた後である。

このことから言えることは、文句を言っている人は辞めない。ただ、文句や不平不満ではなく、マネージャの判断、アサイメントなどの采配でエンジニアが小さな悩みを言っているときは危険である。放置すると辞める。

自分の置かれている状況を変える以外にも会社を辞めることには意味があります。会社をやめることの最も大きな意味とは、

会社に反省する機会を与えること

引用　同上

果たして、エンジニア自身が会社を辞めることで会社に反省を促そうと思って、実際に反省をしたら誰にメリットがあるのだろうか。

少なくとも辞めたエンジニアにとってメリットはゼロである。何一つ、反省した後の教授を受けないためだ。

これが正であれば、エンジニアが辞めようとしている会社に対して反省を促すことは微塵も思うわけがないし、反省を促そうとしていると考え方は誤りである。

それは、ブラック企業自身に気づく能力がほんの少し、残っていたからだと考える方が適切でないだろうか。

以下は蛇足。

毎日終電、毎週休日出勤の超絶ブラック企業であっても、本気を出せばあっという間に残業ゼロのホワイト企業として生まれ変わることができました。そのきっかけとなったイベントは紛れもなく従業員が退職すると申し出てきたことでした。

 引用　同上

自分のことを持ち出して比較するのはどうかと思わなくもない、ーのはたった1人のマネージャのマネジメントと会社と比較するにはレベルが違い過ぎると思うからであるがー、ブラック企業がホワイト企業になったのが事実だとして、それは、不良が更生したことを自慢しているようで『何を言っているのだ』としか思えないのは少し斜に構えすぎているのだろうか。

サラリーマン金太郎 14 金太郎、辞表を出す。編 (SHUEISHA JUMP REMIX)

一生、同じ会社で働きますか？

SIerエンジニアは課題設定が出来ない

8秒くらいで違いを伝えるとするなら、

『はがない』

である。

僕は友達が少ない 16 (MFコミックス　アライブシリーズ)

それは略しすぎなので、

『課題設定ができる』

エンジニアは自社サービスを作っているエンジニアで、できないエンジニアが受託エンジニア。

タイトルにエンジニアをつけて違いをエンジニアだけに押し付けるのもアレだし、エンジニアがそう振る舞うのはリーダであるプロジェクトマネージャとプロダクトマネージャの違いが由来だといっても構わないだろう。

別の切り口だと、事業者（委託元）とSIer（受託先）でも同じ関係である。事業者は、経営上の課題から、各担当が分掌の範囲で課題設定し、課題をタスクに落とし込み、タスクによってはプロジェクト化して解決することで評価を受ける。受託先は、課題を切り出されたところだけを決められた要件で実現する。

文字で表現するとなんてことはない。そうだよね、それでどうしたの、で終わってしまう。

だが、受託先のプロジェクトマネージャもエンジニアも超えられない壁がある。

それが課題を設定できるかどうか、である。

『いや、課題なんて自分でもできるよ』と言われるSIerのエンジニアもおられるだろうし、実際課題を設定できるエンジニアの方も極めで稀にいるかもしれない。でも、圧倒的にできないエンジニアの方が多い。

経験知をエビデンスとするならば、過去のエントリでも書いたが目標管理で自分の目標を設定できるエンジニアは2割もいない。どれだけ技術レベルが優秀でも目標を組織の目標から設定できるエンジニアは少ない。

なにも課題を全く書けないわけではない。目標のようなものは埋めてきてくれる。それが、課題を設定してそれを解決する目標になっていないのである。

委託元が課題から切り出した要件を実現するのがSIerの仕事であると気づけばその理由がわかる。

切り出された要件を対価を受け取り、代行するのがSIerの事業であるから課題設定は必要とされない。必要なのは要件を実現すること、終わらせることなのである。

つまり、いくらSIerに課題設定を求めても、日頃から課題を設定する機会がないのである。SIerの中で課題設定する機会があるのはマネージャと本社部門だけである。それも、系列になるとだいぶ怪しくなるが。

プロジェクトマネージャには、プロジェクトを終わらすプレッシャだけが掛かる。もちろん、エンジニアにはWBSを終わらせるように圧が掛かる。このどこにも課題設定は微塵も出てこない。

プロダクトマネージャは、事業を支えるプロダクトの成功を考え、実現しなければならない。上手くいっていれば、さらに価値を高めることを考える。上手くいっていなければ、課題をKPIから設定するのである。でなければ、事業が失敗してしまうからである。

『課題』でそのあたりのつながり、壁がわかったのである。

ひとりでひどく感心しているのである。

ちなみに、良い悪いを言いたいわけではない。『違いがあるよ』と強く思ったのでそれを書き残しておきたいと思ったのである。

さて、課題を設定するスキルはどうやって設定すれば良いのだろうか。

東大エグゼクティブ・マネジメント 課題設定の思考力

ダイヤモンドハーバードビジネスレビュー 2018年 2 月号 [雑誌] (課題設定の力)

問題発見プロフェッショナル―「構想力と分析力」

会議で『これはすごい』と関心した経験をしたので共有させて欲しい

どうして会議は長いじかん拘束され、ひどくつまらない。その上、何が決まったわからない。こんなことならバックれて自分のタスクを進めた方が良かった。

そんな会議が多いのはどうしてなのだろうか。

その上、その会議に出席するのは、声の大きなおじさん、半分寝ているおじさん、毎回違うことを言うユーザ、PCで内職しているエンジニア、そして、なかなか出席しないキーパーソン…。

あるプロジェクトで、これはすごいと関心した経験をしたので共有したい。ツイッターで見かける『広まれー』である。

某プロジェクトの検討会のある回は、議題が目白押しだった。案の定、少しずつ、agendaの時間は遅れ始める。

冒頭から厳しいツッコミがベンダに入る。『それはRFPの提案と違うから受けれられない。まずは提案と違うことに対して説明をせよ』と複数のステークホルダからベンダにマサカリ雨あられのように投げ込まれる。なんとなくは進ませない状況を眺めているとステークホルダはステークホルダの仕事をしている。

次の議案も、ステークホルダから苦情が噴出する。ただ、これは着地点が見つかれば良さそうだ。

いくつかの議案を終えて、いよいよ自分の担当する議案になった時点で10分押しである。出席しているステークホルダの1人が次の予定があるから時間通りに終わって欲しいと釘を刺される。

その議案は、その会議に附議されるまで担当と何度も見直しを行い、なんだかんだでスライドを８枚まで絞り込んだ。

議案自体は、承認案件でも報告案件でもない。毛色が変わっている。経営課題のようなものを投げかけるものだ。故に、その投げ掛けで何を残すのか、そこがミソになる。

スライドの要点だけ書けば、現状認識と課題である。

そう。自分でこのことに気づけば８枚は多かったし、８枚のスライドを作る手間は不要だったかもしれない。

＃この辺は大企業病の現れなのかもしれない。

それは横に置いて、現状認識と課題のスライドを話し終わったタイミングで座長が割り込んできた。

その割り込み方と話の持っていき方を目の前で見ていて『これはすごい』とただただ関心するばかりだった。

複数いるステークホルダそれぞれに現状認識に対するそれそれの立場での見解と同意を取り付けるために、ラウンドロビンを２周しただけで課題に対する共有と同意を取り付けてしまったのだ。

イメージはこうだ。一人ひとりのステークホルダに共有で１周、同意で１周、都合２周。これでその場で課題に対する共通理解と課題を全体のものであると同意を取ってしまったのだ。

こちらとしては、ぽかんとするだけである。

ある意味、美味しいところを持って行かれたようなものだが、実は、考えていた進め方とは違っていたので同じ結果になったかと言えば、そう言い切れない。

そういったこともあって、『これはすごい』と関心させられたのである。

ふむ。

そして、自分の会議に対する切れ味が鈍っているのではないかと自省したのである。

会議でスマートに見せる100の方法 (早川書房)

1分で話せ 世界のトップが絶賛した大事なことだけシンプルに伝える技術

カンバンおじさんvs子どもさん

実は、一度、件のブログを読んでこれは『いかんやつだ』と思いつつも流してしまっていた。それをもう1度目にする機会があり、読み直してみたら、やはり『根本解決にはならないのではないかなー』と思った。

そんなことを感じつつ、『顧客が本当に必要だったものは』を思い出してしまった。

で、これが件のブログ。

backlog.com

可視化ツールであるバーンダウンチャートは使いたくなるんですよ。可視化したい病に罹ると。気持ちはわからなくもないし、バーンダウンチャートを選ぶこともやってみることも悪手ではない、と思う。

ところで、我が家でも子どもの夏休みの宿題だか、お受験のダイニングでカンバンを使ってみてはどうかと子どもにご提案したことがある。

我が家では皆ダイニングに集まる習性があり、ちょうど、白く広い壁があるので『カンバンにはもってこい』な環境なのである。

そこでカンバンおじさんがムクムクと登場するのである。

どうやって進めたらいいかを悩んでいる風に見えると、『可視化したらいいよ』『カンバンいいよ』と勧めずにはいられない。

それが『カンバンおじさん』である。

ねぇ、ねぇ、とマスキングテープをビシッとはり、Do、Doing、Doneのレーンを作り、カラフルな付箋紙に文字を書いて、貼ってみせる。

『どう』とドヤ顔だったかもしれない。

正直、子どもさんも困っただろう、反応に。

2、3日後にそっとマスキングテープを剥がしたときに学んだことは、

『手法を使うことに興味は持たない』

ということである。

自分で自分を褒めるとすれば（褒める必要性はないが）、意思決定を本人から奪わなかったことである。使うか使わないかは子どもさんである。なぜなら、夏休みの宿題かお受験のどちらかは忘れたけれど、終わらせるのは子どもさんなのだから。

実は、これは意識的にやっていて、道具は（知らないので）存在することを視界に入るようにみせるが、それを使うか使わないかは本人の判断に任せる、という考え方に基づいている（だから強制はしなかった）。

これは

『自分をマネジメントするのは自分』

だから、と考えてるためである。誰かが（子どもが相手であれば親が）マネジメントするとしても、大体が関心を持っている間だけである。興味を持たなくなるか、区切りが来たらそれ以降はマネジメントしない。

放り投げられるのである。

そのとき誰が困るか。

子どもさん自身である。それは大人の、エンジニアの世界も同じである。マイクロマネジメントをし続けたらどうなるか。一番知っているのはエンジニアである親である。

話を引用したブログに戻すと、何がダメというか自分との考え方の違いは何かとというと、上述したとおり、（ブログの書き方、表現上のことだけかもしれないが）意思決定が子どもにないことである。

一見、タスクの意思決定は子どもさんがお持ちになっているが、実は、大事なところでパパさんが意思決定してしまっている。

これでは、次の冬休みに同じように宿題を計画的に終わらそうと子どもさんが思ってもらえるか、と危惧してしまう（そこまで心配する必要はないと言われそうだが）。

何が言いたいかというと、大人と同じで、必要にならないと使わないし、知らないと使いようがないということである。つまり、親やマネージャであるロールの人は、

『こんなのあるよ』

と何気なく視界に入るように知る機会を作るだけしかできないのである。

kerätä マスキングテープ 30個セット 和紙テープ 15mm幅 5m巻 持ち運びに便利な巻き巻きプレート3枚 オリジナルレシピ集付き

ポストイット 付箋 強粘着 ノート 75x75mm 90枚x5個 蛍光 654-5SSAN

カンバン仕事術

ダイニングテーブルには進捗を出す何かが住み着いている

この３連休、結局、遠出もせず、庭にも出ずに締め切りが近い作業をしていた。家から出たのは、土曜日の昼食と夕飯の買い物くらいで、あとはずっと家の中暮らしであった。

まあ、なんというか、締め切りを設けている作業の進捗を出すために、自主的にカンヅメになっていただけの話である。

その３日間、やっていたのは書き物で、PCでポチポチと文字を修正し、参考資料を探し求め、ひと通り形にしようと踠いていたのである。

それで、そのPCの作業をどこでやっていたか、である。

以前であれば、リビングを陣取って外付けモニターを鎮座し、胡座をかいてみたり、正座してみたり、座り方を変えながら締め切りの対応をしていた。

ところがここのところ、どうも床に直接座るのがいけない。耐えられないというか。続かないのである。

そう言えば、地ベタリアン（死語！）の前はソファーに座って作業をしていたような気がするが、その前となると寝室の小さな机だったかもしれない。

小さな机は狭いのでダメだった。少なくとも会議用テーブルくらいの広さと目の前の開放感は必要である。小さな机は物置き場になって久しい。

ソファーはしばらく続いたが、外部モニターを使う場合はそれができないのでソファーで仕事ができないし、そうなると元のリビングテーブルで仕事をすることになるのだが、辛抱できない。腰が悪いわけでもないのに。

結局、作業のときだけ、ダイイングテーブルに外部ディスプレイを移動して締め切りの対応をすることになった。

ダイニングテーブルは、うちの勉強机でもある。うちの子どもは自室も机もあるのに、勉強するのはダイニングテーブルである。多分、ダイニングテーブルに進捗を勧めてくれる何かが住み着いているのだろう。

だから、滅多なことでもない限り、自室で勉強しない。

そのダイニングテーブルの半分を借りて（後からの新参者だし）、外部モニターを持ち込んでPCをセットする。

資料を広げ、締め切りの対応に唸りながら、締め切りのそれを行ったり来たりするので牛歩以下の進捗しかでない。

リビングの椅子は、多くが座面が皮でフレームが木製で、それでいてカチッとしている。オフィスのようなソフトな座面でも背もたれがリクライニングするわけでもない。あの椅子は、あのままでいいのだろうか。まあ、食事ではリクライニングする方が身体に食事をひっくり返しそうになって返って危ないかもしれないし、キャスターはテーブルに手をついたりすると動いてそれも危ないかもしれない。

それはさておき、３日間ダイニングテーブルでカンヅメになっていたのであるが、お陰様で予定の進捗が出たのでまずまずである。

あとは子どもの自室が未使用であるから、ダイニングテーブルで行き詰まったら、次のカンヅメ先はそこをあてにしよう。

山善(YAMAZEN) サイバーコム 会議用テーブル(幅180奥行45) ブラウン MCT-1845H

Bauhutte (バウヒュッテ) PCデスク 昇降式 (幅120cm×奥行55cm) BHD-1200M

課題設定のアプローチ（自分用のまとめ）

課題設定をする際に、どうも上手く出来ていないと感じられるのだが、これまでの経験から整理するとアプローチをパターン化できるのではないかと考え、自分用のメモとしてサマっておこう。

なぜ自分でうまくできていないと認識しているのにパターン化は出来ると思うかというと、他人には助言をできるからである。それが自分のことになるとうまく進まないのは経験が形式知になっていないからだろう、と仮説を立てたということである。

課題といっても事業企画での目線で整理するが、アプローチのモデル的には変わらないと思うので参考になれば。

現状調査を行う

在るが儘の現時点に取れる情報を収集する。

1. 収集の際には、できる限り現場に赴く。
2. 収集する情報は、収集リストを作成し、収集リストにしたがってエビデンスを確保する。
3.  収集の際には、現地の担当者と会話し、なぜ今の状況があるか、現場の声を聴き、記録する。
4. 収集中に、情報の聴き方、範囲を広げた方が良いと判断できる場合、広げて収集を行う。
5. 別に調査時点での最新の技術サービスを調べる。
6. Gartner hype cycle、Gartner Magic Quadrantでトレンドを調べておく。

これらにより、以下の観点で情報を整理する。

• 現時点での実態を把握できる。
• 現場の声（要望）を得られる。
• Gartnerなどの動向で今後選択する技術の位置付けを知っておくことができる。

あるべき姿を設定する

以下の項目から、あるべき姿を設定する。

1. 中期計画
2. 経営課題
3. 自社の規程
4. 法令
5. 業界ガイドライン

ギャップを抽出する

あるべき姿と現状調査から差異を列挙する。 

1. 計画と実績
2. 方針と実態
3. 法令と運用
4. 規程と監査結果

課題をリストする

いくつか抽出されるギャップから課題となるものをリスト化する。

1. それを解決することでギャップの較差が解消するか
2. ギャップを満たすことで解消されるリスクがある

上記の２つの観点でふるいに掛ける。

課題解決のアプローチ方法を検討する

設定した課題を解決するアプローチの道筋をつける。以下の並びは順番を表していない。適宜並べ換える。

1. ステークホルダー
2. スケジュール
3. 活動目的
4. 課題
5. 体制
6. 予算
7. 事前調整

課題の設定アプローチが出来ない場合

自分で課題のアプローチを設定できない（＝仮説を立てられない）場合は、ステークホルダに課題をシェアしてしまう。

1. ステークホルダを集め、現状の報告を行う
2. 課題アプローチのアイデアを出し合うミーティングを設定する

 ダー誕祭ですね。

figma ガールズ&パンツァー 最終章 ダージリン&オレンジペコセット ノンスケール ABS&PVC製 塗装済み可動フィギュア

AHMAD TEA (アーマッドティー) ダージリン 200g

フォートナム&メイソン ダージリンファイネスト ティップ ゴールデン ティップ オレンジ ペコ 125g リーフ 1缶［海外直送品］

エンジニアの沼落ち

エンジニアが参加する勉強会でのLTやカンファレンスでは、いわゆる常連さんを多く見かけると感じることはないだろうか。

参加者も顔なじみだったりするし、スピーカーもいつものメンバが幾らかの割合を占めている。

そういった常連さんのスライドを見ると、顔が売れているから壇上に立っているのではなく、常に何か新しいアップデートを差し込んでくる。そういったこともあるのでうかうかと気が抜けないし、差し込んでくるテーマが自分にとって興味深かったりするから困ったものである。

カンファレンスでは、そういった面白そうなネタが同じ帯の時間帯に複数設定されるため、自分の身体を仮想化して同時にいくつもの経験をしてみたいと思うことが少なくない。

カンファレンスの位置付けもあるのだろうが、実験的なワークショップやオリジナルのワークショップがあったりすると次は何時お目に掛かるか皆目見当もつかないから一期一会の世界となってしまう。

ここまでが前説であり、ネタ振りでもある。

LTでもカンファレンスでも常連さんたちがいて、そういった常連さんに限ってテーマが面白い（挟んでくる小ネタやギャグは滑りまくる方が多い）。

もし常連のスピーカーの方がこのエントリを読む機会があったら、カッコ書きのところで胸が痛むかもしれないが次は滑らないように頑張って欲しい。

さて、どうして常連さんは面白いテーマを持参してスピーカーを演じに来るのだろうか。

自分としては、そういったカンファレンスやLTの場は、アウトプットと宣伝の場であると捉えている。後者はさておき、前者のアウトプットの場としてのカンファレンス、LTというのはどう感じるだろうか。

わざわざ人前でアウトプットをしなくてもいいと思うか、それともスピーカーと同じように機会があればアウトプットしてみたいと思うだろうか。

エンジニアは、最小限のOJTであれ、OFFJTであれ、生存戦略としての自己研鑽であれ、多からず、少なからず、技術スキルと基礎スキルを体験から経験知を、書籍やマニュアルから形式知をインプットしている。

この見解については同意していただけるだろうか。

それを前提に話を進めると、そうしたインプットを続けているとエンジニアは専門性を持つようになり、特定のエリアで関心を深く持つようになる（はずだ）。

そこが、そのエンジニアにとって技術の沼になる。

関心を持って物事を眺めるようになると、関心を持っていないエンジニアと比較すれば切り口の新しい視点が生まれる。その切り口から、さらに新しい疑問を問い掛けられる。それでますます沼に沈み込んでいく。

面白いことに、その沼には先人が足の先から頭の先までスッポリと浸かって待っているのである。

先人もやはりエンジニアだし、そのエリアの名高いオジ様、オネエ様であるから、ニコニコしながら手招きをして、エンジニアを沼の奥底に誘い込む。

新しい疑問を持っているエンジニアに、オジ様、オネエ様は優しく相談事に乗る体で、その疑問に新規性を感じると、それを公募にしたらどうかとさらに沼奥底に引き摺り込みに掛かる。

公募が通ろうが落選しようがカンファレンスや勉強会に関わらせられ、また新たな世界の快楽をエンジニアの身体に覚えさせに掛かるのだ。

エンジニアは何時の間にか、壇上でスライドをめくり、滑る小ネタを挟んでいるのである。その講演が終わるとまた次のネタ探しを始める重度の症状を発するようになる。

こうして、小さなインプットが大きなアウトプットに繋がり、また次のアウトプットのためにインプットをするのである。

 気づけば、そのエンジニアも頭の先から足の先まですっかり沼に浸かりきり、新たなエンジニアを誘い込むようにあなたを待っている。

マンガ沼

ヒナまつり 15 (HARTA COMIX)

 ゲーム沼

【PS4】Marvel's Spider-Man

 自炊沼

イワタニ カセットフー 達人スリム 【うす型コンロ / 高さ74mm】 CB-AS-1

レンズ沼

Canon 単焦点レンズ EF50mm F1.8 STM フルサイズ対応 EF5018STM

 マキタ沼

マキタ USBアダプタ ADP05 バッテリー別売