スキル不足なエンジニアはマネージャと人事部で作られる

エンジニアの技術転換は何も『スキル不足で職場に居場所がないおじさん』のスキル不足だからとは限らない。

blog.tinect.jp

Javaがでてエンプラ系でわっと広がりを見せはじめて暫くした後、当時の組織ではJavaをやっていないエンジニア全員にJava研修を強制的に受けさせていた。いわゆる技術転換というやつである。できるかりぎ近寄らないようにしていたが、全員受講したかどうかトレースされ渋々受講した。そんな気持ちで受講しているから単に受講しただけでしかない。

中途半端に体力があるSIerだと絶滅すると言われて久しいCOBOLerのおじさんが生息していた。あれほどITなんとかというメディアなどでレガシーとか叩かれていた言語でもビジネスニーズがあれば細々と生きながらえる。中堅のエンジニアも見かけたから人的には補充するほどだったのだろう。言語の栄枯盛衰で言えば、エンプラ系で使われなくなった言語はPL/1くらいではないだろうか。

COBOLからJavaの前はCOBOLからCへの技術転換もあったはずだ。いずれにしろ、ビジネス的にいよいよ先がないと経営サイドが諦めざるを得ない判断した時点（その意思決定自体どうかと思うし、とても遅い）でエンジニアの技術（言語）を転換するという発想がおかしい。

屁理屈で言えば、言語は道具でしかない。業務の課題を解決する仕組み（アーキテクチャ）を実現するために適切な開発手法と合わせて言語を設定しなければならない。

エンジニアにとって必要なのは課題解決する業務は何か、何が課題か、課題を解決する仕組みはどうするか、そのアーキテクチャの実現性はどう評価するか、などなどのスキルが必要だし、実際に課題を解決する仕組みをプログラムで実現できなければならない。

今思い出しても、現場でレガシーで技術転換を必要とする技術的に塩漬けにしておいた過去のマネージャや育成を所管していた人事部が何をという今更感があるが、そもそもSEと呼ばれているITエンジニアは工員の延長線上の教育しかされてこなかったのである。

以前の新入社員の集合研修では開発フェーズしかやらない。これで何が起きるかと言えば、業務をOAつまりプログラム言語に置き換えることしか起きない。業務のOA化である。だから、業務の課題はどのようなものか、解決方法にどのようなアプローチがあるかなどと知る必要がない。狭い範囲での業務を知っていればいいのである。10個の手続きがあれば10個の手続きをプログラムに置き換える。これがOA化である。IT化するなら1→10に飛ばしてもいいのである。

それを必要だとやってこなかっただけの話である。今後、ITエンジニアは二極化、2種類に世界線が分かれるだろう。1つはOA化しかできないエンジニア。もうひとつは業務をITで実現できるエンジニア。

OAD付き 転生したらスライムだった件(13)限定版 (講談社キャラクターズライツ)

• メディア:
• この商品を含むブログを見る

 

エンジニアの転職先に対する振る舞いの基本

前日、離れる組織向けの振る舞いを書いたので、移る先について述べる。

fumisan.hatenadiary.com

エンジニアは辞める組織にその意向を伝えるときには意思決定を済ませているからよっぽどのことがない限り元の鞘には戻らない。以前、唯一この人ならという人が辞める人は気持ちよく送り出せと言っていたことを思い出した。辞めると決めたエンジニアは意思を伝えたら後は移るだけで安寧な気持ちで居られるかと言えばそうもいかない。

• 転職理由の軸を作る
  どうして転職するのかは必ず聞かれる。理由は様々であって良いがネガティブな理由はプラスには受け取らない。場合によってはマイナスに受け取る。転職理由は活動中ずっと聞かれることであるが、それがどうしてか自分で理解しなければならない。
• 採用通知書にサインしてからもずっと笑顔で
  諸条件を合意して採用通知書（内定）にサインしてもずっと笑顔で。移る先により期間は違うが3ヶ月から6ヶ月間試用期間となる。滅多なことではないが、打ち切られることだって可能性はある。成果を出すことはもちろんであるが笑顔は万能なスキルである。
• 業務経歴書
  業務経歴書は自分の売りの技術をアピールする場である。であるから売りたい技術が光るように書かなければならない。よく見るダメな業務経歴書は参画したプロジェクトで使っていた全ての製品、適用技術を列挙しているケースである。それのどれかを指示され使っただけであることはすぐに見破られる。プロジェクトの概要はプロジェクトを知らない第三者が数行を読んで理解できるように。プロジェクトとなった業務課題、役割、対策、効果を主要テーマとし、それぞれの項目の中をアピールしたいテーマで記述すること。繰り返すが普通の履歴書やSESで出している業務経歴書でろくなものは1件もないことを覚えておくこと。
• カジュアル面談
  カジュアル面談で落ちるエンジニアも多い。落ちるのはエンジニアの方から次へ進むことを辞退する。カジュアル面談をした組織に本当に行きたいかをカジュアル面談をしてから考えるからである。これは先方にとって大変無駄なリソースを使わせる。もちろん、カジュアル面談とは言え、すでに面談に入っていることは理解すること。評価はしていないかもしれないが応募してきたエンジニアと一緒に働けるか、受け入れたとき受けれ先の組織でやっていけるか、貢献できるか、入った場合のバンドを見ている。
• 採用面談
  多くは３段階くらいではないか。誰と会うか、面談で何を聞かれるだろうかは予測をして想定問答を言語化しておくこと。採用した場合のチームや人事、CTOなどのチーフ職、担当役員かCEOとの面談になるだろう。相手が変わっても同じことを訊ねる質問もあるし、立場が変われば違う質問もする。そのロールでどのような責任を負っているかで想像はつく。回答の基本は最初に作った軸からブレないこと。
• 条件
  ベンチャーになればなるほど条件は整備されていない。上場していれば最低限は揃っているが旧態で中堅のSIerほど労務条件は整わないし、あっても違う。年収だけで評価せず、福利厚生を含め条件を見渡すこと。見えない福利厚生があることに気づく。トータルするとマイナスになっていることもある。
• わからないこと
  わからないことは全て聞くこと。ズバズバと聞いた方がいい。遠慮をしたりろくに条件を確かめないで、後になってこんなはずじゃなかったなどとなってもそれこそ自分の判断で行ったことだ。
• 掛けた労力で判断しない
  ここまでやってきたのに、転職の負担がなどと本来の転職したい軸とは違う判断基準を持ち出さないこと。sunk costで判断することは馬鹿げている。ブラックで緊急避難的なケースでなければ、見つかったらいいなくらいで。
• Agentよりリファラル
  知人に紹介してもらえるくらいに技術力を身につけ、実践すること。Agentが紹介する転職先でフィットすることは少ない。あっていると思ったらすでに自分から転職先に合わせているかもしれない。

遊び人は賢者に転職できるって知ってました? 3 ~勇者パーティを追放されたLv99道化師、【大賢者】になる~ (ダッシュエックス文庫)

仕事は楽しいかね？ (きこ書房)

エンジニアの辞める組織に対する振る舞いの基本

エンジニアが所蔵する組織を辞めるときいくつか気をつけておいた方が良いことがある。辞めようとしている組織に恨み辛みがあろうが、サラリーの問題であろうが、超過労働であろうが、上司が気に入らないだろうが、世間いや業界は狭いので立つ鳥跡を濁さずで行きたい。

• 貫徹まで笑顔で
  目的は新しい仕事場で仕事をするサインをして、新しいチャレンジを始める先にある。それを手に入れるために腹立たしいことがおきないようにしたい。
  また、離任する組織に対しても良い印象を残す振る舞いは正しい。これを実現するのは笑顔である。終始笑顔で、些細なことがあっても聞き流す。重要なのは初心を貫徹することである。
• 社内規程を確認しておく
  従業員規程、就業規則などを読み込み、社内ルールの流れを押さえておく。法的には退職は2週間前までに伝えれば良く、規則も法に沿っている（はず）。
  ただし、退社時の手続きは退社する社員にしか伝えられない。
• 辞めるスケジュールを立てる
  社内規程を踏まえ、最終退職日（退職手続きの書類にサインし、全ての備品を返却する）、最終出社日（業務上の最後の出社日で翌日から最終退社日までは年休消化）のマイルストーンを立てる。
  もちろん、現場の仕事もあるので引き継ぎで引っ張られないようにしておく。
• 情報統制を掛ける
  辞めると意思決定すると誰かに話したくなるが、特に旧態なビジネスのSIerでは情報統制を掛ける。
  家族も気をつけること。ワイフに伝えたらママさん繋がりで、などとならないように。
  辞める意思を伝える人を最小限にしておき、どこから流れていくかを観察する。
• 引き止め
  無能な上司は、バーターな案を出さず、ただただ引き止める。感傷的にショックである、もっと活躍してほしかったなどボケたことをぬかすが聞くふりをしても耳を貸してはいけない。
• 引き継ぎ
  引き継ぎをすることを考えて仕事をするようなエンジニアではいけない。普段から、自分が担当した仕事は自分のものではないから、成果物、仕掛かりの資料などをプロジェクトフォルダやgithub、bitbucketにあげておく。
  業務も冗長化、つまりエンジェルナンバを下げようと、自身でモブワークやXPを推進しておく。
  この準備をしておけば最短1−2週間で引き継ぎできる。なお、1人プロジェクトは最悪であるが、1人プロジェクトを指示しているのは上司なので上司のスケジュールを押さえて引き継ぎのセレモニを行う。
  どのケースでも1ヶ月以上やってはいけない。
• 情報の流出
  間違っても、離任する組織の内部情報をごっそり持って行こうなどと思ってはいけない。記録され、あとで面倒ごとにならないように対策する。
• リファレンスチェック
  転職先のバンド、レベル（職位）が高いとリファレンスチェックが入るケースがある。離任予定の組織に複数名、転職する会社や代行組織から直接電話が入る。その対象者は口が硬くないといけないし、あるがままの自分を話していただかなければいけない。
  つまり、なんでも言い合える知人が必要になる。日頃から腹を割って話せる交友関係の醸成が必要である。ここを悩むような採用候補者を先方が採用したいかと考えればリファレンスチェックが入るのは納得できるだろう。
  リファレンスチェックが入ることは事前に、対面か電話で伝えておくこと。
• 業界は狭い
  転職先はあなたの持っているいくつもの技術や知見の中からあるスキルを欲しがって採用しているケースがほとんである。そのスキルがジェネラリストのスキルでなければ、専門性を持っている技術となる。
  そうするとその専門性の界隈で付き合い続けることは避けられないから、そうした観点もあると覚えておく。
  これは大丈夫だろうと業界の人に転職の意向を話してしまって、実は上司や同僚と繋がっていた的なことが起きると面倒なためである。
• 最悪戻ることを想定に入れておく
  複数の転職候補を持っていればいいが、ブラックでなければ、離任する組織も候補に入れておく。組織によっては、出戻りを歓迎するところもある。

これはあくまでも離任する組織に対して、である。

世界でただ一人の魔物使い　?転職したら魔王に間違われました? 2巻 (デジタル版ガンガンコミックスＵＰ！)

世界でただ一人の魔物使い　?転職したら魔王に間違われました? 1巻 (デジタル版ガンガンコミックスＵＰ！)

『チームのルールですよね』『変えて良いよ』

これはあるプロジェクトチームを立て直したとき、朝会でカンバンを前にメンバ全員に言ったこと。

カンバンの列、基本形としては、ToDo | Doing | Done　の3つの列でタスク管理をするものをプロジェクトの成果物や段取りからカンバンを導入したタイミングで、カンバンの列をそれらに合わせて列を増やした。そのカンバンを説明しながら、カンバンの列どおりにやらないと、つまり列を飛ばしたらそのタスクは元に戻すルールにするからと伝えた。

• カンバンの列はチーム全員が守るプロセス
• プロセスを守らないと元に戻す

このプロセス（カンバンの列の順に進めること）を守っている限り、メンバのアウトプットについての失敗りは全部自分が責任を持つ。守らなかった場合、一切エンジニアを守らないよ、と。

メンバでもチームのルールを守らないメンバが出てきて、それを指導することを感けると他のメンバも悪い行いを真似をするようになる。

そうするとチームはdisciplineを失ってしまう。立て直そうとしているチームはダークサイトに落ちてしまう。

一方、ルールは机上で組み立てた仕組みである。テストをしていない。裏付けとして直前の作業を観察していてこれでいけそうだと踏んでいるが、なにぶん実践していない。

だから、チームのプロセスだと決めたルールにも間違いがあるかもしれない。もし間違いがあればそれを修正しないと無駄なことをメンバにやらせることになる。これも立て直すチームにやらせたいことではない。

であるから、チームにはこう言ったことも合わせて伝えた。

『今からこのカンバンはチーム、みんなのプロセスだ。だから、プロセスを分けたいとかいくつかの列を1つに統合するとかしたければ、チームで合意すれば変えて構わない。というか変えて欲しい』

こう伝えるとほぼ全員が驚く。

ルールは守るものだ。

ルールを守るように言ったではないか。

どうして変えて良いのか。 

実践テストをやっていないし、実務者としてルールを実行するのはメンバのエンジニアなのである。

目の前の現場でやらなければ意味がない。

カンバンのプロセスで使いにくい箇所があったらいちいちプロマネに相談をする必要があるだろうか。目的に対する成果を得られることが変わらないなら、プロセスは簡略化した方が断然マシである。

数ヶ月後、カンバンのプロセスは少し詳細に分けられていていた。

自分たちの成果を出しやすく、間違えないようにしていた。

ルールはプロマネの手から離れてチームのものになっていた。

SIMPLE RULES 「仕事が速い人」はここまでシンプルに考える (単行本)

技術書を読むことと素振りをしておくこと

メンバが組織的にはかなりチャレンジな投資になるIT企画を立ち上げて、経営陣向けにプレゼンをしていたが、会議の終わる時間になっても戻ってこない。プレゼンが長引いていて次に予定していたミーティングに遅れるとslackは入った。

様子を見に会議室を覗いたら、ミーティングは終わっていたが、助けを求めるような顔つきで自分を見る。話を聞くと、出直しするように言われたと言い続けた後、もともとミーティングの予定を入れていた時間と自分の身体を欲しいという。

どう巻き直すか、作戦会議をしたいのだという。会議室を覗いた時点ですでにどうするか事後の策を検討を始めていたが、企画提案チームだけでは打開策を見いだすことが難しと感じたらしい。

メンバや他のエンジニアから相談を受けると、まずはオーソドックスに、ありがちな対応策やアイデアを考える。ちょうど、事業企画（IT企画）の流れを個人的に整理していたこともあり、ありきたりな流れならこんな風にとホワイトボードに書いていく。そこに今回の企画テーマのエンティティを書き加えながらどう進めるかをイメージアップしていく。

ありきたりだからとても手順が多いし、一見、時間がかかるように見える。だからこれを全部やる必要があるかと問い直したり、ショートカットをした場合の揺り戻しのリスクがないかを問いかける。

時間軸的にはミーティングを始めてから、企画チームの思いのずれを感じる。自分はこれまで断片的にしか聞いていないので同じようにずれている。それを可視化しようとエレベーターピッチのテンプレを人数分コピーして配り、それぞれの目的を書いてもらう。

とにかくホワイトボードがあって、書いていたとしても同じ言葉を違い意味合いで話したり、共通概念のないところでいくら書いてもプロトコルは一致しない。

同じフレームワークで同じセンテンスの上でどう捉えているか、どうイメージしているかを言葉にしなければ何も始められない。

• 目的は
• 何を
• どんなアーキテクチャで

この3つは一番大元になるものだから、最初にそれぞれがどこに立っているかを知ってから始めないとまたプレゼンを失敗してしまいかねない。そういうときに、技術書にあるフレームワークやテンプレをさっと出して、それを使うことは効果的だ。

それと、技術書を読んだら全てはないにしろ技術書を読んだ目的のことについては実際に自分で使っておくことだ。頭の中だけではそれこそ机上でしかなく、いざという時に手が止まる。それは書いたりタイプしていないからフレームワークと脳内の言葉が紐づかないのである。なんとなく感じを掴めるまで、数回でも良いから使っておく。プログラム言語なら写経をするのと同じである。コードを打ち込んで実際に動かしてみる。エラーは取り除く。動けばわかった気になるし、フレームワークに書けばそれで良いか感覚をつかめていないか感じられる。

企画提案は、スポンサーである経営陣に騙されてもらうために行うのである。であるから、提案する側にやりきるための自信がなければならないし、そのための裏付けがなければならない。エンジニアならそれは企画でのアーキテクチャに他ならない。

第一、やったことがないITなんてやれますなってエンジニアなら言い切れるはずがないのだから。

よつばと! 2020年 カレンダー 壁掛け CL-104

「よつばと！」カレンダー 2020年 スリム

どれだけ転職サイトにエントリシートを書いてもSIerから脱出できない

本当にエントリシートをもういいかと思うほど見た。こちらもポジションを用意しているので諦めようかと頭を過るも、ここで踏ん張らないと自分たちの業務で積み上がっていることができなくなってしまうから、手を抜くことも止めてしまうこともできない。

自分のチームではやりたいことがたくさんある。でも、誰でもいいわけではない。期待している役割がある。役割といってもマネージャとかではない。ポジションごとに期待するコンピテンシーを設定している。であるから、この技術しかできないとかこの業務しかできないとかではお話にならない。

あるポジションならこのバンドのコンピテンシを持っていることを期待する。もちろん、採用候補者と見込んで会う場合は、どのポジションで何を期待しているかをお伝えする。その上で、お話を進める。

それで、エントリシートである。人材紹介のサービスは多々ある。エンジニアご自身を売り込むための業務経歴書、エントリシートはエンジニアご自身が書かれると思う。それを数えられないくらい見たが、9割いや9割5分くらい見てすぐに閉じてしまう。そのくらいキラキラ感がない。

キラキラ感と書くと業務経歴書でキラキラ感は返ってやばいのではないかと思うかもしれない。確かにチャラい感じであればそのとおりであるが、エントリされるエンジニアの異能感がキラリと光るときキラキラ感を感じるのである。

9割5分のエントリ、それもSIerに所属されているエンジニアのみなさんのエントリシートは異能感もキラリと光る尖ったものも感じられない。

なぜかと記憶で分析すると（印象論であることは重々承知）、業務経歴書に書かれていることが『やった』と列挙されているだけで、howとかroleとか何を乗り越えたとかがない。単なるレコード、記録なのである。

余計なお世話であるが、楽しく仕事をされているのか心配になる。楽しくないから転職を希望されているのかもしれないが、実際には楽しくないにしても、楽しみ方を知らなそうなエンジニアはご遠慮したい。

採用する側はどんなエンジニアが欲しいか、明快な基準を持っているものだ。誰でもいいなら、派遣さんで十分である。でも社員として欲しいのである。

転職サイトに書かれているそれこそ数多のエントリの中で、あなたの魅力を何でアピールするのかを考えて書いているのだろうか。

業務経歴書を時系列（降順、昇順どちらでも気にしない）を書いたら、

• 尖っている技術、自信を持っている実践知の切り口を探す
• その切り口にしたのはどうしてそう思ったかポイントをあげる
• ポイントと業務経歴と紐付ける
• 何をしたか切り口と紐付ける
• どうやったかを切り口と紐付ける

それをアブストにする。少なくともやった系とは印象が違う。ちょっとカジュアルにあってみたいと思う。少なくとも自分は。

まあ、あなたはそう思わないかもしれないが。

ハイキュー!! 39 (ジャンプコミックス)

• メディア:
• この商品を含むブログを見る

 

調達 今日まで50%off ピックアップ CAREER SKILLS ソフトウェア開発者の完全キャリアガイド Kindle版

CAREER SKILLS　ソフトウェア開発者の完全キャリアガイド

ピープルウエア 第3版

Hacking Growth グロースハック完全読本

おうちで学べるセキュリティのきほん

本物のデータ分析力が身に付く本 (日経BPムック)