勉強会に誘っても行かない部下や後輩エンジニアをそれでも勉強会に行かせたいなら

組織の外の勉強会で得るものがあり、それが仕事で生きた体験につながっていると同じことを勧めたくなる。口コミといえば口コミであるが、他人の人生に余計なものを差し込むのだから、十分お節介である。

勧める方は意図がある。純粋に勧めるよりは、自宅と仕事場の往復をしているだけにしか見えない部下や後輩に能力を向上するような機会を作って自らのエンジニアとしてのレベルをあげて欲しいと言うピュアなものだ。

実際は、それをしなければ仕事が進まないなど困ったことになっていないから、実行されることはない。

無理やり、一緒に申し込みをさせられて、同行させるようなケースでもなければ。

ヒントはここにある。

仕事にすればいい。

勧める側に成功体験があればコネクションとして何人か交友を持っているコミュニティ的なつながりを持っているだろう。

部下や後輩エンジニアに学ぶ機会を作って欲しくても行かないのであれば、組織の、業務の中にそれを作り、スケジュールを確保し、業務として指示すればいい。

声がけするつながりのエンジニアの仕事場が近ければ、ソーシャルネットワークでDMかメッセージを送り『こんなことをやりたい』と伝えればいい。

そのとき、こちらは業務としてやりたいので業務時間内でと伝えると良い。どこの組織でもフィードバックできる程度のアウトプットがあれば業務扱いにしやすいだろう。

声がけするつながりのエンジニア達は全員つながっている必要はない。その場で新しいつながりを作れることは、声がけされたエンジニアにとっても今までなかった体験であるから価値はある。

  • 距離的に近いエンジニアと事前にこんなことをやりたいと伝えておく
  • 賛同してくれたエンジニアに主旨(事例による技術交流など)を伝える
  • 場を設定しinvして日程調整を始める
  • 部下や後輩エンジニアのスケジュールの空きを押さえる
  • キックオフでは最低限のルールを決める(自由参加、持ち回りなど)
  • 関係者外秘とするか、公開前提とするか(関係者外秘、クレンジング)
  • ゴールは決めておく(やめるタイミング)

コミュニティの立ち上げ、ファシリテーション、運営、運用、セキュリティなど、テーマ以外まで、目の前でやれば学べることもあるだろう。

水を飲ませたくても引っ張って行くのも大変である。であれば、水を目の前に持ってくればいいのである。

 

 

 

リングフィット アドベンチャー -Switch

リングフィット アドベンチャー -Switch

 

 

 

 

エンジニア、上に進むか、前に進むか

エンジニアも人の子だから、同じ仕事をするなら給料が高い方がいい。残業はそこそこあるし、残業代も出るからなんとかやっていけるくらいに手元に残るが、扶養家族が増え行く先々の出て行くものを考えると、今のままでいいとは思えないし、なんとかしなければと思い、ガムシャラに働こうと思ったりもする。

それでいいのか、である。

何がそれでいいのか、であるが、それは『今のままでガムシャラに働けばいいのか』である。

役職の呼び名は組織ごとだろうが、平社員のままで、主任で、係長で。

ガムシャラに働いたとしても、結局評価されないと給与は上がらない。給与をあげたければ上がる仕組みを理解しなければならない。

2つのアプローチ

1つは、組織にしばらくい続けるのであれば、組織の仕組みを知らなければならない。体制、評価、キャリア。従業員、つまり平社員までであれば給与テーブルを公開している組織もあるだろう。

これまでの自分自身の昇給、昇格のペースから5年後、10年後の想像してみよう。

割とゾッとするのではないか。

そのとき、一緒に考えて欲しいのは、5年後の自分の年齢、10年後の自分の年齢だ。継続して知識を得続けて行かなければならない一方、体力は加速して落ちて行く。

組織はえてして、ヒラエルキーの構造をとるから、1つポジションを上がるということは、結果を出して経営に貢献し、そのポジションに相応の力量を持っていると評価されたということである。

であるから、経営に貢献できる仕事の役割を自ら選択して、やらなければならない。

2つは、前に進むことを選ぶ。他のエンジニアより先に目利きをして技術を押さえる。他のエンジニアが作った後の道を歩んではいけない。少なくとも所属する組織内では。

他のエンジニアのあとを歩くのはとても楽である。ある意味、安定している。安定しているからこそ、前に歩いたエンジニアのおこぼれをあずかる。全くもって受け身である。

先に進むことは、とても不安定だし、不確実性の塊である。原生林の中を自分で下草を刈りながら進まなければならない。

ルートは自分で見定めなければならないし、何度となく間違える。

でもそれは進んだから間違えたとわかることで、後から付いてくるエンジニアには経験のできないことである。

これはエンジニアで言うところの専門技術を持つと言うことである。

どちらを目指すか

2つのアプローチをどちらを選ぶかと問われたらどう選択するか。

 

 

 

 

自分の場合は、両方を選んだのである。プロマネで専門性を高めつつ、ビジネスに貢献する。そこを足掛かりに上に上がるキャリアを作る。

管理職も組織によってはローテーションはするだろうし、現場で有識者を必要とすることもあるだろう。

別の角度からいえば、管理職で滞留していると、エンジニアとしての専門性が古くなり、使い物にならなくなってしまう。

実行能力を伴わない管理職ほど売れないリソースはない。

 

 

 

 

 

 

 

 

パフォーマンスを発揮できていないエンジニアへの対処

チームメンバがパフォーマンスを出せていないなと感じたとき、どう対処(改善)するのが良いのだろうか。多くのパターンは、渡すタスクの進捗の予実をまさに監視して、終わったかだけを聞き、遅れればどうして遅れたかを聞いているのではないだろうか。

パフォーマンスが出ていないと感じているのは、仕事を出している側の感覚である。当事者のエンジニアもある程度の技術力を持っている場合は、遅れていることを自覚している。ただ、何かしらの理由で持っている能力を発揮できないでいる。

エンジニアとしての能力がこれからの場合、つまり若手で経験も少なく、育てる必要があれば、手順なり、手法なりを学ばせながら小さな成功体験を積ませるアプローチを取るのも1つの選択である。技術力を持っているエンジニアとペア作業をさせて、OJTで仕事を学ぶのは、作業の主体となりつつ手と頭を使うので効果を期待できる。

中堅エンジニアでもパフォーマンスを発揮できていないケースもある。これはそのチームで必要とする前提の技術の相違で起きる。アサイメントなり、業務委託を受ける際に聞いていればそのようなケースを避けられそうでもあるが、違う道具でもやることが同じであれば、エンジニアならいけるだろうと双方で判断しがちである。

問題になるのは中堅エンジニアであることの期待の大きさである。技術的な知識の相違は割と棚に上げられ、中堅だからとパフォーマンスだけで成果を見てしまう。

結論的には、技術的なギャップは同じスタートラインになれるようにヘルプを出して、成果を出せる環境を一刻も構築することである。これをしないと変な空気が漂い始める。

その上で、パフォーマンスを計測する期間を合意し、成果を検証した方が良い。エンジニアなら誰しも専門性を持っている。ビックマウスなエンジニアでなければ、相応のパフォーマンスを発揮し始める。

これも、中堅エンジニアだからと言ってたち上がりの環境構築を放置しておくと発見が遅れ、結果的にチームにインパクトをじわじわと与える(中堅だから期待も大きいので取り返しも負担が大きい)から、チームとしてはアンチパターンである。

 

運用☆ちゃんと学ぶ システム運用の基本

運用☆ちゃんと学ぶ システム運用の基本

 

 

行動力「やる気スイッチがやられたようだな…」やり抜く力「フフフ…奴は四天王の中でも最弱…」

 

やる気スイッチ「グアアアア」(死亡)
(部屋の中)
行動力「やる気スイッチがやられたようだな…」
やり抜く力「フフフ…奴は四天王の中でも最弱…」
締め切り「エンジニア如きにやられるとは納期のツラ汚しよ…」

 

世の中には2種類のエンジニアに分けられる。納期を自分で設定して終わらせるエンジニアか、他人に納期を設定されて締め切りに終われるエンジニアかだ。

ただ、前者のエンジニアも納期が2ヶ月も先になったら一向に手をつけることはない。全て劣後にし、納期が心理的圧迫を掛けてくるまで、全ての時間を別のこと、多くは生産的でないことに使い続ける。

結果、にっちもさっちも行かなくなったどんずまりのスケジュールになって、初めて何をしなければならないかを考え、考える時間だけでも足らないことに気づく。

多くのエンジニアはやらなければいけないことはわかっている。その意味ではやる気スイッチは最初から入っている。一旦始まれば行動力も備わっている。もちろん、過去の実績からもやり抜く力は備えている。

持ちあわせていないのは、自分で納期を設定し、自覚し、自分に始めなければこれからやらなければならない仕事のボリュームと残された時間を客観的に把握する能力である。

エンジニアは他人のスケジュールのやばさ加減は理解する。そのアプローチでは終わらないだろうと思うことはしばしばある。

パターン的に多いのは、納期に対する作業のディテールを具体化していないからどれだけ時間が少ないことになるかを実感していないことである。

着手を覚悟するデッドラインは、このくらいで終わるだろうと思った期間の1.5倍は確保して納期から逆に開始日を設定しなければならない。

他人を巻き込みなら殊更である。

時間がなければ考える時間も碌に確保できず、将来の自分のメンテのための時間を多く取ってしまう。こんなやり方をしておいて、技術的負債と呼ぶのはおこがましいし、技術的負債に申し訳ない。

技術のリボ払いのようなものである。

 

 

 

 

 

マネージャがエンジニアの邪魔をするかを見分けるなら

ピーターの法則というのがある。名前を知らなくても聞いたことが記憶の隅に残っているかもしれない。説明を引用すると、あなたのマネージャはもしかするとすでに能力の極限にまで出世していて、今のポジションで必要とされる能力を持ち合わせていないのかもしれない。

能力主義の階層社会では、人間は能力の極限まで出世する。したがって、有能な平(ひら)構成員は、無能な中間管理職になる。

ピーターの法則 - Wikipedia

少しわかりにくいので別の説明を引用すると理解しやすいかもしれない。

必ずしも高い地位がより難しい仕事であるという意味ではない。単純に、以前優秀であった仕事と仕事内容が異なるだけである。要求される技術をその人材が持ちあわせていないだけである。

ピーターの法則 - Wikipedia

一つ下のポジションでは能力を発揮できていて、それを認められてポジションを上げられたが、上った先で必要としてた能力は持ち合わせていなかった、ということである

リトマス試験紙

課長職(もしくはチームリーダなどのポジション)で部下を持っている管理監督職のマネージャがハウツー本や自己啓発本でも読んでいたらまだマシかもしれないが本を読んでていないとしたら、まず間違いない。そのマネージャは遠くない将来においてエンジニアの邪魔をするようになる。

どうして邪魔になるかというと、自分の経験でしか評価する軸を持っていないからである。他からのメジャーを取り入れないということは、情報が古く、経験した事象だけが根拠で、未経験の事案が起きると実際に経験した記憶やそうした事象の共通項から得た個人的な暗黙知で評価せざるを得ない。

エンジニアが新しいことをやりたいといっても評価する軸がないから、なんだかんだいってハードルを設ける。

わからないことは先送りするか、条件をつけて諦めさせる。これはマネージャが判断して負えるリスクの裁量が小さいことに起因する。

マネージャが自分自身をアップデートできていれば、リスクを把握でき裁量の範囲でリスクをテイクできる。

マネージャが知識を得ようとする背景

マネージャ業をしていると、実践知を身につけられるようになるが、その知識を体系的に知りたくなったり、他者のプラクティスと比較して、自分の能力を高めたいと考える。

人は知らないことは思いつかないし、必要な場面で思いつかなければそれを実践投入する判断も行えない。ましてや自分をモルモットに試行することもできない。

知識を得ておくことは少ない情報で意思決定の根拠の幅を広げておくという意味がある。

これは前述したリスクをどこまで取れるかという意味でもある。マネージャに実践知か形式知があれば、部下のエンジニアが外で勉強してきて、あれこれやりたいと言ったとき、リスクをコントロールできると判断すれば、許可を出したり、見て見ぬ振りをして遠くから見守ることもできるだろう。

得る知識は他者の事例より、体系的な形式知を好むはずである。事例はあくまでも事例であり、その事例が成功、失敗にかかわらず多種多様な条件下での例であって、それはマネージャの現場では参考にならない。

参考にするのであれば、事例からプラクティスを形式化しなければ意味がないからである。

 

 

 

 

 

 

 

週末なのでポエム的なものを。

調理する、つまり料理を作ることをシステム開発のプロセスやプロジェクトマネジメントに例えて解説するケースをよく見かけるし、もしかしたら以前に書いていたかもしれない。検索するとどちらかと言えば懐疑的に書いているかもしれない。

少し前に研修を設計していると書いた。講座の狙いを考えると受講目的を実現する方法の実現が難しい。難しいというのは思いつくやり方では、前提知識のハードルを無意識に置いていることを気づいているからだ。

それで料理とシステム開発とプロジェクトマネジメントであるが、もし具体的な事例として取り込むなら、例と関連づけはこんな感じだろう。

料理とプロダクトマネジメント

レシピどおりに作る場合と創作とは同じものではない。

手順、分量、道具、調理時間を厳密に決め、それ以外認めない場合はエンジニアリングであり、ルーチンワークである。

創作するとは別物。

創作は既存の手法、確立された手順、分量、道具のパラメータを変える。継続的イノベーションである。

創作から手順、分量、道具、調理時間を試行錯誤した後、パラメータを確定したらルーチンワークになる。

言われて作る、指示されて作るときはイライラしやすい。特に『なんでもいい』というケースは、プロダクトの選定から始まり、作って見ないと要求と答え合わせできないのでフラストが起きやすい。

料理は小さく(少量)作ることはできても、時間の短縮はできない。これを忘れてはいけない。

逆に大きく作るも道具のキャパシティの上限から制約される。型のサイズ、数量を揃えることは先行投資と維持保管するコストを増やす。オーブンをいくつも揃えることも現実的ではない。オーブンの内側のサイズを超えるサイズの料理はできない。

制約を知ること。

料理とプロジェクトマネジメント

  1. 何を作るか(プロジェクトの目的)
  2. いつまでに作るか(納期)
  3. 材料、道具は何か(リソース)
  4. 食材や道具にかけられる費用はいくらか(C)
  5. 作る料理の味(Q)、出来上がりの時間(D)、材料や人件費の費用(C)、スケジュール(S)の目標は何か
  6. QCDSが守れないとどうなるか(リスク)
  7. スケジュール(工程)を作成したか(計画)
  8. スケジュールどおりに作成しているか(予実)
  9. 出来上がった料理の味、分量は計画どおりか(評価)
  10. 得られた経験は何か(プラクティス)

調理とシステム開発手法

料理ではなく、調理。

  1. 何を作るか(仕様)
  2. 料理の味は設定できているか(完了基準)
  3. 盛り付けの要求はあるか(定性的品質)
  4. どのように作れば良いか手順を知っているか(手順の確立)
  5. どのような道具で作れば良いか(生産性向上ツールの選定) 
  6. 料理を分解できるか(WBSの作成)
  7. 手順ごとの部品の作成(プログラムモジュールの作成)
  8. 全ての部品の統合(ビルド)
  9. 味見の結果はどうか(機能テスト)
  10. 盛り付けはイメージどおりか(非機能テスト)
  11. 食べた人の評価はどうか(UAT)

調理とツール&テクニック

例えば時間短縮、品質の確保の観点で道具を使うことは生産性向上、歩留まりに貢献する。

  1. 泡立て器とハンドミキサー
  2. スリコギとフードプロセッサー
  3. 温度計と低温調理器

調理とマインドセット

料理を調理した後のレスポンスは『美味しい』か『無言』である。調理をすることにおいて、そのマインドを外に置くことは調理人のマインドを揺さぶり、料理のできかがりに影響する。

 

 

 

 

 

誰でも1回で味が決まるロジカル調理

誰でも1回で味が決まるロジカル調理

 

 

 

 

議事録作成を技術で解決してほしい

日頃からの素振りの大切さは自分自身が一番わかっているつもりだが、機会を失うとそれこそ自然消滅してしまう。機会がなくなればそれまで使っていた振る舞いも、マインドの感覚を失ってしまう。しばらくしてそれをする機会を察すると、妙な緊張感を感じる。

例えば自分くらいの年齢や担当のしごとをしていると、議事録を取る機会はめっきりと減っている。

自分の中では、もしくは自分の主催する会議体であれば、次の項目を残せば良い。

  • 議案
  • 結果
  • 課題・宿題
  • 担当
  • 期限

逆に言えば、主催者が変わると運営や議事録の残し方も変わる。出席する目的により、議事録の作成を輪番制にしたり、議論を思いのほか記すことを求められることもある。議事録の取り方の流儀に違いがあると、落とし所を見つけるか(実際には受け入れるか)、議論することのコストを鑑みそれに従うかのどちらかであるから、面倒くさい。

議事録を残すことは、出席者に業務委託のいない組織内の会議だとしても必要である。それがフォーマルな会議体であれば殊更だ。

業務委託のいる場で、委託内容を議論するのであれば必要性は言うまでもない。

であったとしても、議事録を作成するのは面倒である。記録を残すと言う時点で、何を書き残すかセンスを覗かれるし、取り交わされた会話を事実を曲げない程度で表現しなければならない。

 通常、議事録は議事録用にメモを取り、議事録用の様式に清書する段取りを取るだろう。この手続きが非常に面倒くさいのは、清書の段階で記憶のリロードと会話の咀嚼と再言語化を伴うからである。

面倒なところは技術で解決することを発想するのがエンジニアである。実現したいのは、手をかけず、時間をかけず、議事録を生成するか、ネタとなる会議の会話の文字起こしである。

思い当たるのはUDトークであるが、数回試したところでは、会話の被らない会議であっても修正の手間は多い。

もう一つプロトタイプのサービスがあり試したところ、先のアプリより漢字変換は優秀であるが、少しマシな程度であった。

後者は、講演のようなスピーカーが1人のケースでは漢字変換も文字起こしも良好で実用に耐えられると判断している。

ところでそもそも議事録を書き起こすことを止めればそうしたことを評価すること自体をなくすことができるので、それを選択する方が良い。

議事録様式と記載の運用に従い、ライブコーディングのように書き切れれば8割がた終わったようなものである。

ただし、ライブコーディングを取り入れると、議論に参加することは難しい。

プロマネやコンサルのときは、実は割とやっていたが、現在は機会を失うとめっきりライブで理解をしながら残すことに抵抗を感じるのは年齢的な能力低下なのか、自分に課しているハードルが高いのだろう。

議事録作成の問題点は、次の2点だろう。

  • 時間がかかること
  • 言語化するときに誤りを混入すること

今風で体裁を気にしないなら、ボイスメモとホワイトボードへのグラフィックレコーディングが良いだろう。

 

 

 

鬼滅の刃 1 (ジャンプコミックスDIGITAL)