ボクらはスキル不足ではなく、スキルの停滞なのかも知れない

50代の役員が「50代になると眠いんだよ」と言っていて、そうはなりたくないなぁと思っていたら、平日の夜などは飲む＜早く寝たいとなってきて、体力が落ちてきていることを実感する今日この頃です。それでもかなり頑張ってアウトプットしているのは、先行きが安泰ではないんだろうなと思っているからだろうし、実際、不安要素があるわけです。

不安要素といえばエンジニアのスキル不足はエンジニアが直面する喫緊の課題でしょうし、本人が認識すればするほど焦りまくりなんだろうと思うのです。だからこれまで何度かスキルについて取り上げてきたのですが。

スキル不足を実感する

エンジニアがスキル不足を実感する機会は数知れないと思うのです。現場で同年代くらいのエンジニアが自分より上のロールを担っていれば焦りは感じるでしょうし、自分より若いエンジニアだったりしたらヤバさを感じなければ別の意味でやばいわけです。

まあ、本人が成り行きで仕事ができていればいいのであればそういう人生もあるのでしょうけれど。

スキル不足はどうしよう

「 スキルが不足しています、どうしたらいいんでしょうか」と尋ねられたとして、じゃあこうすればいいよ的なアドバイスなんてないんですよ。

これまでのエンジニアのスキルに関するエントリは、自分で勉強しなさい、ですから。それもコツコツとやりなさい、ですもん。

いやー、できる人しかやっていないでしょう。コツコツとなんて。できるなら相談するようなこと自体がないですってば。

もうですね、徳を積むように日々の積み重ね、なのです。

スキル不足ではなく停滞かも知れない

 多分に、スキル不足を気づけるエンジニアは少ないんじゃないかと思うようになってきました。だって、これだけエンジニアの技術較差が現実の世界であるのに、日々の業務の中で学習できる経験知だけで過ごしているエンジニアが多いのですもの。

あっ、そういうことか。

日々の業務を持っている経験知でやる過ごせてしまう程度にスキルを持った時点で停滞してしまっていると言えるのかも知れない。

そうか、そうなんですねぇ。人は怠惰な生き物ですから楽な方を選ぶ生き物ですから。何か直面した瞬間はまずいと感じたとしても日々の業務に戻されてすっかり忘れるんだ。そしてその日々の業務ではこなせるスキルを持っているから困らない。

そんなエンジニアに日々徳を積んでみたらと言っても耳を貸してくれないでしょう。

でも、スキルは停滞し、徐々に低減していくのです。 

数学ガール/ポアンカレ予想 (「数学ガール」シリーズ6)

形骸化させない進捗会議の準備、運営、狙い

進捗会議の会議設計をどのようにしているかで、そのプロジェクトのリスクに対する考え方が垣間見ることができる。

会議設計

まず、会議を設計するという概念はほとんどないのではないかと思うのが会議の狙いを考えずにこれまで週次でやってきたから、このプロジェクトも週次の開催にした、というケースばかりだからだ。

進捗会議であれ、他の会議であれ、会議自体は情報収集を目的として行うかプロジェクトの意思決定のいづれかの目的で行う。

＃会議運営のノウハウについては過去のエントリで検索していただきたい。

こと、進捗会議は情報収集のために開催する。プロジェクトマネジメントの観点でマネジメントにレポーティングをするのが主な目的である。もちろん、予実較差の観点でのリスクマネジメントもあるが、悪魔でも較差が生じた場合である。

話を戻して、会議設計は会議の目的から設計する。プロジェクトマネジメント の観点で週次で報告する義務があれば最低限どの開催頻度は週次となるがプロジェクトマネージャの判断としてもっと短い開催サイクルで行っても良い。

つまり、プロジェクトマネージャがプロジェクトの特性、例えばリスキーなプロジェクトであると何かしらのプロジェクト計画上で識別したリスク要因から設定して良いのだ。

会議の無駄化

エンジニアの時間は、生産的な時間を如何に捻出するかで生産性が左右される。チーム全員を集めた会議に延々と費やすのは生産性を自ら下げているようなものだ。

更に言えば、その会議でさえ、正しい情報を収集することができなかったり、意思決定に至らなければ、同じように貴重な時間をドブに捨てるようなものである。

だから会議設計をして、目的どおりに開催しなければいけない。

形骸化の始まり

やらされ感や参加すること自体に抵抗を感じると途端に形骸化が始まる。進捗会議は得てして、それも第1回目から形骸化しがちになる。なぜなら、進捗会議が作業計画の矛盾を抱えたまま計画が着手され、対策も何もしないで実績報告である予実較差の可視化とアクションプランのオンパレードになるか、それをエンジニアが面倒くさがり隠蔽を始めるからだ。

形骸化させない準備

1回目の会議開催前から会議を形骸化させないための広報を行う。

1. 出席を必要とする会議出席者のみの徹底。
2. 開始時間の厳守。1人が遅れることで時間を守る他のメンバが待たされる時間を無くす。誰だって待たされるのは嫌である。
3. 報告する時間枠を決める。
4. 報告する項目をあらかじめ決めておく。予実較差、困っていること、広報したいこと。極論を言えば、予実較差が0なら報告しなくて良い。もちろん、実績は現物確認する。
5. 主催者、つまりプロマネであっても周知事項は進捗会議の場のアジェンダに入れない。それは別の手段で広報させる。
6. 報告書（様式にする必要はない。開発ツールでも良い）に書いていないことは話させない。
7. 報告中は口を挟ませない。
8. 困っていることは解決策を検討するために関連する最小限の担当者の名前を出し、検討する場だけを決める。進捗会議の中で課題を検討し始めることで会議が形骸化するためだ。

どれも当たり前だと思っても現実にこうしたルールルを守れていないなら当たり前ができていないということだ。そこからのレベルのチームであることを認識することも大事なことである。

狙い

形骸化させない狙いは、短時間で終わらせることだ。それも短時間で、会議を設計したとおり運営し、機能させることが大事な狙い。

もちろん、会議の時間枠より早く終わればさっさと散会して生産的な活動に戻るべきた。

あと、困ったことを話すと解決に協力してくれる場を得られるというメリットを享受させること。

これこそ本来の狙いであるリスク識別と予防につながる。

会議でスマートに見せる100の方法

大洗おもてなし会議(ミーティング) 四十七位の港町にて (マイナビ出版ファン文庫)

エンジニアが無駄なと思う作業をするときの心得

どこの立ち位置でと言うのがキモになるかもしれませんが、プロマネやコンサルの立場に関わらず、いちエンジニアとまるっと括った上でお話をすると、

「（これ今やるのがいいのか、必要とする数日前にやらないともう1回更新することになるから無駄だろう）」

なんて思うことがままある。今のお仕事の役割は良くある。

でも、絶対に「無駄ですからやめましょう」とかは言わない。

何故いわないか。手戻りしたらやり直しで追加の費用を貰える契約ではない。手間を掛けたら掛けた分、リソースが目減りするから依頼元から見れば損失である。エンジニアの専門家としては行う期日をスライドさせるべきだ、と言うのが正しいのかもしれない。

正しいことを言うのが専門家ではない。正しいと思うこと自体がエンジニア目線である。専門家として助言を求められているなら、例えば、どのタイミングでやるのが最適かを尋ねられているなら必要とする数日前が合理的であればそう答えればいい。

なぜ無駄と言わないか。

別に無駄ではないと思っていない訳ではない。無駄である。1回で終わる作業であれば。

ここである。

業務を委託する元が作業の結果を見てみないといいとも悪い（作り変えて欲しい）とも判断がつかないことがある。例えば、レビューのメトリクスを集計してある期間を特性ごとに分類して原因を分析して欲しいと依頼されたとする。依頼された日から、必要とする期日の数日前に作業をすれば十分間に合うオーダーがあったとする。

依頼元は必要な期日より前、必要とする期日までの中間日に見たいと言う。どうしてかを考えてから無駄だと言っても遅くはないし、多くのケースでは口は閉じておいた方が良い。

どうして委託元は、中間日に見たいと言うか、その事情、段取りを聞き出すことが先決である。

多くのケースでは、委託元が依頼した作業の内容を見極められていない、と言う理由があるからである。必要とする期日まで時間を使い切ってしまった上で、得られた結果が期待する結果にならなかった場合、分析方法を変えるとか追加でメトリクスを収集するとか対処する時間を確保できず、結果的にはその委託元は立場がなくなることを恐れているからである。

委託元の立場はどうでも良い（ビジネスになっているなら良くない）が、結果により将来が左右されるのであればそれは回避したいところである。

ここでもエンジニアは期待する結果を得られようが、得られまいがそれは委託元の先のビジネスであってエンジニアの立場では関係がないと短絡的な反応をするケースがあとをたたないが、ここで切ってはいけない。ビジネスとして。

ちょっと勘違いをされるとあとがおかしくなるので補足しておくと、無駄な作業でも言われたことをホイホイやる何も考えもせず仕事をやっておけばいいとは思っていない。

ここで押さえておきたいことは、その作業＝中間的な作業をすることに価値があるかどうかを受け止めよう、と言うことだ。

 長くなったのでおさらいをすると、委託元は分析結果を見なければそのあとのアクションを変えざるを得なくなる場合、期待する結果となるか期待する結果とならないかをリカバリできるだろうタイミングで判断したいと言う段取りと心情は理解できるものだ。

これは何かに類似しているパターンではないだろうか。

そう、アジャイル開発でのスプリントを短くして早く結果を手に入れ、ビジネスにフィードバックするのと同じである。

アジャイル開発は、短いスパンで結果を判定し、ビジネスの方向性をピボットするかどうかを判断すると言う考え方は情報施策の企画やフィージビリティスタディで使えるのである。

エンジニアの目線でだけで見ると同じ作業を2回することになり無駄に見えるかもしれないが、委託元のポジションで考えると価値がある中間作業に変わるのである。

ではエンジニアはどうしたら良いか。

基本はやりましょう、と言えばいい。つまり、yes,butと始めればいい。スケジュールが詰まっているなら中間作業をすると他の作業を後ろ倒しするスケジュールの調整はその場でコメントをすること。

もし、実作業をするのが依頼を受けた本人ではなく、別のメンバの場合、1回目の作業をする際に、手順の確立をさせておくことと2回あるよと申し送りしておくこと。

最初から2回やると言っておけば、単なる２ショットと受け止められる。先が見えないところで追加をされる方がよっぽど嫌な気持ちになるものだから。

スクラム　仕事が４倍速くなる“世界標準”のチーム戦術

調達 game storming

ゲームストーミング ―会議、チーム、プロジェクトを成功へと導く87のゲーム

マネージャ歴10数年がこっそり教えるキャリア設計のチート方法

マネージャ歴10数年…嘘じゃない。こっそり…目標設定ができないエンジニアにそっと教えている、キャリア設計…キャリアデザインの一部がその年の目標だから合ってる、チート方法…一から考えるよりは。

よし、大丈夫。

新人エンジニアはもちろん経験がない、少ないからそうだよねーとは思うけれど、異動してき中堅エンジニアでさえマネージャが指導していなかったのかと思うような目標を立ててくるケースが後を絶たない。

個別に指導するのはするけれど、こういったチートっぽいやり方があるよ、と。

そうそう、考え方だからね。具体的な目標はこれをベースに具体的に考えて。それぞれのエンジニアとしてのキャリアになるからさ。

3−5年後の自分

具体的なイメージを文字として書き起こす。自分のイラストを描いてキャプションを書いても良い。

そのときに、ロールを書くこと。ロールは役割だ。プロジェクトマネージャ、プロダクトマネージャ、マネージャ、SEリーダ、アーキテクトなどなど。

何が出来るかを書く。プロジェクトマネジメントでプロジェクトをキャリーする 、プロダクトマネジメントで製品をローンチする、マネジメントで部下を20人持つ、データサイエンスのリーダとして組織の顔になる、など。

今決められなくても、いい。仮で良い。目指してみたら思っていた仕事と違ったなんてよくあることだ。早く試してピボットすればいい。

1年後の自分

今年度の目標を設定するということは、1年後にできることを増やした後の自分を自分で作るということ。

1年後の自分は3−5年後の自分を年数で割ったステップを上がった自分とイコールである。

便宜上、3年後の自分のイメージを持っているとする。

3年後に実現したい自分があるのだから、今年度の目標を実現していたら少なくとも1/3は3年後の自分を実現できていなければいけない。

1年後の自分はあくまでも3年後の自分の途中である。それをイメージする。

今年度の目標設定

今年度の目標は、1年後の自分ができるようになっているスキルとスキルレベルを具体化する。

これを3年続けると3年後にイメージする自分が持っているスキルとスキルレベルを実現できている、そういう仕組みである。

年度の目標の項目は、1年後の自分が持っている（増えた）スキルと（上がった）スキルレベルのどれかに必ず紐づく。

目標設定時では、1年後の自分ができているスキルもスキルレベルも仮である。だからこそ計画時は必ず紐づける。

目標の内訳

年度の目標は、OJTとOFFJTに分ける。OJTとOFFJTはスキルとスキルレベルに紐づける。

OJT

業務を介してスキルやスキルレベルを得る。つまり、実践して獲得する実践知である。

実践知を得るためになんの仕事で得るかを書く。具体的で定量的で有期限で設定すること。

例「AプロジェクトでBロールを担いMMまでに999の結果を出す」

OFFJT

 業務を介して得られる実践知でエンジニアに必要なスキルとスキルレベルを全て得られることはない。実践で得られない知識は形式知で補完する。

業務でやらないからOFFである。OFFJTの主な手段を以下に示す。

• 組織内研修
• 組織外研修
• 団体、コミュニティ活動
• 自己研鑽

 エンジニアのバンド、つまりレベルが上がれば組織内研修では合わなくなる。なぜなら、アプリやインフラなどどのエンジニアにでも受けられる講座を用意するからだ。

また、エンジニアの専門性が細分化されていること、1年後の自分が得ているスキルがピンポイント過ぎるためだ。

 つまり、組織外の研修か団体などに出向き自分で取って来なければならないということ。

このロジックを身につければ目標設定は簡単だし、定量的に設定しているのでマネージャに納得感のある説明をできる。そこがチート、というわけ。 

エンジニアとリーダー論、若しくは基礎的なこと

 ここ数日、エンジニア向けのフォロワー、リーダーあとマネージャーについてのエントリを見かけて、ついついブコメを残したらIDコールされたりして、

「（何かやってしまったか）」

と焦ってみたり、

「（それどうなか）」

と思ってみたのでちょっとおさらいしてみた。

リーダー

発想できる個人の概念を得られる人である。この発想の概念化には洞察力が必要となりり、洞察力を得られる人はほんの一握りしかいない。

そうでなければ、つまり充分供給されているなら、これほど 世の中にリーダーが必要とされないはずだからだ。

リーダーは率先して進む方向を示す。

洞察で得た概念に率先して進む以上、洞察力から得た概念の一番の理解者でなければならない。

リーダーが洞察で得た概念を疑っていては誰もそのリーダーが示す思いを受け入れようとは思わない。

リーダーは、先頭に立ち、発想で得た概念を表し、将来起きる期待と最悪の結果を承知の上で人の前を歩む。

将来起きるだろうこと良い期待と最悪な結果。どちらも今知ることができない先を感じ、予見不可能なことを予見するスキルが必要だ。

リーダーに必要なことは次の資質だ。

• 他人に進む方向を示す。
• 目標を理解している。

マネージャー

マネージャーはマネジメントをする役割を担う人だ。マネジメントは組織として行うもので、組織の目標を達成するために組織のリソースを活かしそれを実現しなければならない。

そこから導き出されるのは、リソースを最大限に、つまり、有効に活用することだ。

リソースにはヒト・モノ・カネがあり、どれも采配により有効に活用できたり、効果がないどころかマイナスにだってなりかねない。

優れたマネージャーは意思を持つリソースである人を有効に活用するための環境を作る。

環境づくりには次の観点がある。

• どのように動機付けを行うか
• 確認を行う頻度はどうか
• どのように最高に褒めるか
• 最大限に貢献してもらうための良質な教育

これらの環境づくりを行うためには、一人ひとりの特色を発見することが前提である。

サーバント

さらにサーバントであるためには次の資質が必要である。

• 困難な問題を前に耳を傾けることが出来る。
• 伝えたいことを具体的に指し示す。
• どうしたら他人に貢献できるか自分の位置をずらして考える。
• 見合う価値がないと思っても存在を認める。
•  自分が何者かをわかっていて、自分自身であろうとする。
• 導く能力を持っている。

エラスティックリーダーシップ ―自己組織化チームの育て方

もし高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら

サーバント×サービス(1) (ヤングガンガンコミックス)

頭の回転の速いエンジニアと仕事のできるエンジニア

基本的に周りを見るとほぼ、いや100％学歴で言えば周囲の方の方が偏差値の高い大学や大学院を出ているエンジニアばかり。

みんな勉強したんだなーって思う。

もちろん、彼、彼女らは勉強をしてきているので頭の回転は速い。めっちゃ速いしこちらが知らないことを知っている。

専門が数学科の同僚は、頭の中がどうなっているかと不思議なくらい。頭の回転の速さに口がついていけていないくらい。

でも、頭の回転が速いエンジニアが仕事ができるかどうかというとこれまた別の次元の話になってくるところが、仕事って面白いというか、エンジニアの仕事だからこそ面白いと思う。

技術スキルと基礎スキル

エンジニアの育成の観点の話をすると、エンジニアとしてシステムを実装するための方法論や技術の領域のスキルの技術スキルとエンジニアとしての仕事を推進するために必要なスキルの基礎スキルの二つがある。

頭の回転が速いエンジニアは前者の技術スキルの習得も速いし習得レベルも高い。ところが不思議なことに仕事を推進するために必要な基礎スキルはそれほどでもない。

とても不思議。

まあ、天は二物を与えず、なのか頭の回転が速くないワタシのようなエンジニアに生き残る余地を作ってくれているのかと思うくらいに。

部下の目標設定ではそれぞれのスキルエリアのどこをフォーカスして伸ばすのかバランスを取りながら選択させるのでそのうち抜かれるんだろうな、なんて思わなくもないけれど、それはそれでステップアップした部下を見て育成方法があっていたんだと検証できたと思えばいいかと。

仕事のできるエンジニアの特徴

頭の回転は速くなくても仕事のできるエンジニアはいて、そういったエンジニアの仕事にはいくつかの特徴がある。

合格ラインを目指す

仕事に100点はない。合格ラインはある。システム開発で言えば、要求品質は合格ラインであって、必要以上の品質を実装しても価値がない。やるだけコストの無駄である。

仕事のできるエンジニアは、最初に合格ラインを確認してそこを目指す。一方、頭の回転の速いエンジニアは出来てしまうのでオーバースペックで作ることが多い。

もっと楽をしたらいいと思う。楽とはものづくりもあるが作るときの手間とか作った後に手間がかからないようにしておくとか。

いつも考えている

仕事のできるエンジニアはいつも考えている。ライフワークバランスとかオンオフ切り替えなんて言っているが、バブルの時だってプライベートとパブリックは分けるものだと言っていた。それがバブル崩壊後20年の間、オンオフなんて言ってられなくなっている。

働き方改革と言いつつ、オフィス面積削減、リモートワークと仕事と私生活の分離を曖昧化が進んでいるだけで、退化しているようなものだ。

そうした背景とは無関係に仕事ができるエンジニアは仕事をしている。仕事ができるエンジニアはオンオフなんて関係がなく、ただいつも、断片的にでも考えている。

考えているからこそ、いつでも柔軟に対処ができている。それが仕事ができるように見えているだけなのだ。

まあ、他にもあるのだろうけれど。頭の回転が速くないと自己否定する必要はないし、将来を悲観することも必要ない。ただ、続けることはしておこう。

会社というモンスターが、僕たちを不幸にしているのかもしれない。