エンジニア、上に進むか、前に進むか
エンジニアも人の子だから、同じ仕事をするなら給料が高い方がいい。残業はそこそこあるし、残業代も出るからなんとかやっていけるくらいに手元に残るが、扶養家族が増え行く先々の出て行くものを考えると、今のままでいいとは思えないし、なんとかしなければと思い、ガムシャラに働こうと思ったりもする。
それでいいのか、である。
何がそれでいいのか、であるが、それは『今のままでガムシャラに働けばいいのか』である。
役職の呼び名は組織ごとだろうが、平社員のままで、主任で、係長で。
ガムシャラに働いたとしても、結局評価されないと給与は上がらない。給与をあげたければ上がる仕組みを理解しなければならない。
2つのアプローチ
1つは、組織にしばらくい続けるのであれば、組織の仕組みを知らなければならない。体制、評価、キャリア。従業員、つまり平社員までであれば給与テーブルを公開している組織もあるだろう。
これまでの自分自身の昇給、昇格のペースから5年後、10年後の想像してみよう。
割とゾッとするのではないか。
そのとき、一緒に考えて欲しいのは、5年後の自分の年齢、10年後の自分の年齢だ。継続して知識を得続けて行かなければならない一方、体力は加速して落ちて行く。
組織はえてして、ヒラエルキーの構造をとるから、1つポジションを上がるということは、結果を出して経営に貢献し、そのポジションに相応の力量を持っていると評価されたということである。
であるから、経営に貢献できる仕事の役割を自ら選択して、やらなければならない。
2つは、前に進むことを選ぶ。他のエンジニアより先に目利きをして技術を押さえる。他のエンジニアが作った後の道を歩んではいけない。少なくとも所属する組織内では。
他のエンジニアのあとを歩くのはとても楽である。ある意味、安定している。安定しているからこそ、前に歩いたエンジニアのおこぼれをあずかる。全くもって受け身である。
先に進むことは、とても不安定だし、不確実性の塊である。原生林の中を自分で下草を刈りながら進まなければならない。
ルートは自分で見定めなければならないし、何度となく間違える。
でもそれは進んだから間違えたとわかることで、後から付いてくるエンジニアには経験のできないことである。
これはエンジニアで言うところの専門技術を持つと言うことである。
どちらを目指すか
2つのアプローチをどちらを選ぶかと問われたらどう選択するか。
自分の場合は、両方を選んだのである。プロマネで専門性を高めつつ、ビジネスに貢献する。そこを足掛かりに上に上がるキャリアを作る。
管理職も組織によってはローテーションはするだろうし、現場で有識者を必要とすることもあるだろう。
別の角度からいえば、管理職で滞留していると、エンジニアとしての専門性が古くなり、使い物にならなくなってしまう。
実行能力を伴わない管理職ほど売れないリソースはない。
パフォーマンスを発揮できていないエンジニアへの対処
チームメンバがパフォーマンスを出せていないなと感じたとき、どう対処（改善）するのが良いのだろうか。多くのパターンは、渡すタスクの進捗の予実をまさに監視して、終わったかだけを聞き、遅れればどうして遅れたかを聞いているのではないだろうか。
パフォーマンスが出ていないと感じているのは、仕事を出している側の感覚である。当事者のエンジニアもある程度の技術力を持っている場合は、遅れていることを自覚している。ただ、何かしらの理由で持っている能力を発揮できないでいる。
エンジニアとしての能力がこれからの場合、つまり若手で経験も少なく、育てる必要があれば、手順なり、手法なりを学ばせながら小さな成功体験を積ませるアプローチを取るのも1つの選択である。技術力を持っているエンジニアとペア作業をさせて、OJTで仕事を学ぶのは、作業の主体となりつつ手と頭を使うので効果を期待できる。
中堅エンジニアでもパフォーマンスを発揮できていないケースもある。これはそのチームで必要とする前提の技術の相違で起きる。アサイメントなり、業務委託を受ける際に聞いていればそのようなケースを避けられそうでもあるが、違う道具でもやることが同じであれば、エンジニアならいけるだろうと双方で判断しがちである。
問題になるのは中堅エンジニアであることの期待の大きさである。技術的な知識の相違は割と棚に上げられ、中堅だからとパフォーマンスだけで成果を見てしまう。
結論的には、技術的なギャップは同じスタートラインになれるようにヘルプを出して、成果を出せる環境を一刻も構築することである。これをしないと変な空気が漂い始める。
その上で、パフォーマンスを計測する期間を合意し、成果を検証した方が良い。エンジニアなら誰しも専門性を持っている。ビックマウスなエンジニアでなければ、相応のパフォーマンスを発揮し始める。
これも、中堅エンジニアだからと言ってたち上がりの環境構築を放置しておくと発見が遅れ、結果的にチームにインパクトをじわじわと与える（中堅だから期待も大きいので取り返しも負担が大きい）から、チームとしてはアンチパターンである。
行動力「やる気スイッチがやられたようだな…」やり抜く力「フフフ…奴は四天王の中でも最弱…」
やる気スイッチ「グアアアア」（死亡）
（部屋の中）
行動力「やる気スイッチがやられたようだな…」
やり抜く力「フフフ…奴は四天王の中でも最弱…」
締め切り「エンジニア如きにやられるとは納期のツラ汚しよ…」
世の中には2種類のエンジニアに分けられる。納期を自分で設定して終わらせるエンジニアか、他人に納期を設定されて締め切りに終われるエンジニアかだ。
ただ、前者のエンジニアも納期が2ヶ月も先になったら一向に手をつけることはない。全て劣後にし、納期が心理的圧迫を掛けてくるまで、全ての時間を別のこと、多くは生産的でないことに使い続ける。
結果、にっちもさっちも行かなくなったどんずまりのスケジュールになって、初めて何をしなければならないかを考え、考える時間だけでも足らないことに気づく。
多くのエンジニアはやらなければいけないことはわかっている。その意味ではやる気スイッチは最初から入っている。一旦始まれば行動力も備わっている。もちろん、過去の実績からもやり抜く力は備えている。
持ちあわせていないのは、自分で納期を設定し、自覚し、自分に始めなければこれからやらなければならない仕事のボリュームと残された時間を客観的に把握する能力である。
エンジニアは他人のスケジュールのやばさ加減は理解する。そのアプローチでは終わらないだろうと思うことはしばしばある。
パターン的に多いのは、納期に対する作業のディテールを具体化していないからどれだけ時間が少ないことになるかを実感していないことである。
着手を覚悟するデッドラインは、このくらいで終わるだろうと思った期間の1.5倍は確保して納期から逆に開始日を設定しなければならない。
他人を巻き込みなら殊更である。
時間がなければ考える時間も碌に確保できず、将来の自分のメンテのための時間を多く取ってしまう。こんなやり方をしておいて、技術的負債と呼ぶのはおこがましいし、技術的負債に申し訳ない。
技術のリボ払いのようなものである。
大阪王将チャーハン四天王セット 炒飯が8袋(炒めチャーハン2袋・キムチチャーハン2袋・高菜チャーハン2袋・ガーリックチャーハン2袋)
- 出版社/メーカー: 大阪王将
- メディア: その他
- この商品を含むブログを見る
マネージャがエンジニアの邪魔をするかを見分けるなら
ピーターの法則というのがある。名前を知らなくても聞いたことが記憶の隅に残っているかもしれない。説明を引用すると、あなたのマネージャはもしかするとすでに能力の極限にまで出世していて、今のポジションで必要とされる能力を持ち合わせていないのかもしれない。
能力主義の階層社会では、人間は能力の極限まで出世する。したがって、有能な平（ひら）構成員は、無能な中間管理職になる。
少しわかりにくいので別の説明を引用すると理解しやすいかもしれない。
必ずしも高い地位がより難しい仕事であるという意味ではない。単純に、以前優秀であった仕事と仕事内容が異なるだけである。要求される技術をその人材が持ちあわせていないだけである。
一つ下のポジションでは能力を発揮できていて、それを認められてポジションを上げられたが、上った先で必要としてた能力は持ち合わせていなかった、ということである
リトマス試験紙
課長職（もしくはチームリーダなどのポジション）で部下を持っている管理監督職のマネージャがハウツー本や自己啓発本でも読んでいたらまだマシかもしれないが本を読んでていないとしたら、まず間違いない。そのマネージャは遠くない将来においてエンジニアの邪魔をするようになる。
どうして邪魔になるかというと、自分の経験でしか評価する軸を持っていないからである。他からのメジャーを取り入れないということは、情報が古く、経験した事象だけが根拠で、未経験の事案が起きると実際に経験した記憶やそうした事象の共通項から得た個人的な暗黙知で評価せざるを得ない。
エンジニアが新しいことをやりたいといっても評価する軸がないから、なんだかんだいってハードルを設ける。
わからないことは先送りするか、条件をつけて諦めさせる。これはマネージャが判断して負えるリスクの裁量が小さいことに起因する。
マネージャが自分自身をアップデートできていれば、リスクを把握でき裁量の範囲でリスクをテイクできる。
マネージャが知識を得ようとする背景
マネージャ業をしていると、実践知を身につけられるようになるが、その知識を体系的に知りたくなったり、他者のプラクティスと比較して、自分の能力を高めたいと考える。
人は知らないことは思いつかないし、必要な場面で思いつかなければそれを実践投入する判断も行えない。ましてや自分をモルモットに試行することもできない。
知識を得ておくことは少ない情報で意思決定の根拠の幅を広げておくという意味がある。
これは前述したリスクをどこまで取れるかという意味でもある。マネージャに実践知か形式知があれば、部下のエンジニアが外で勉強してきて、あれこれやりたいと言ったとき、リスクをコントロールできると判断すれば、許可を出したり、見て見ぬ振りをして遠くから見守ることもできるだろう。
得る知識は他者の事例より、体系的な形式知を好むはずである。事例はあくまでも事例であり、その事例が成功、失敗にかかわらず多種多様な条件下での例であって、それはマネージャの現場では参考にならない。
参考にするのであれば、事例からプラクティスを形式化しなければ意味がないからである。
読書は「アウトプット」が99%: その1冊にもっと「付加価値」をつける読み方 (単行本)
- 作者: 藤井孝一
- 出版社/メーカー: 三笠書房
- 発売日: 2019/10/04
- メディア: 単行本
- この商品を含むブログを見る
■
週末なのでポエム的なものを。
調理する、つまり料理を作ることをシステム開発のプロセスやプロジェクトマネジメントに例えて解説するケースをよく見かけるし、もしかしたら以前に書いていたかもしれない。検索するとどちらかと言えば懐疑的に書いているかもしれない。
少し前に研修を設計していると書いた。講座の狙いを考えると受講目的を実現する方法の実現が難しい。難しいというのは思いつくやり方では、前提知識のハードルを無意識に置いていることを気づいているからだ。
それで料理とシステム開発とプロジェクトマネジメントであるが、もし具体的な事例として取り込むなら、例と関連づけはこんな感じだろう。
料理とプロダクトマネジメント
レシピどおりに作る場合と創作とは同じものではない。
手順、分量、道具、調理時間を厳密に決め、それ以外認めない場合はエンジニアリングであり、ルーチンワークである。
創作するとは別物。
創作は既存の手法、確立された手順、分量、道具のパラメータを変える。継続的イノベーションである。
創作から手順、分量、道具、調理時間を試行錯誤した後、パラメータを確定したらルーチンワークになる。
言われて作る、指示されて作るときはイライラしやすい。特に『なんでもいい』というケースは、プロダクトの選定から始まり、作って見ないと要求と答え合わせできないのでフラストが起きやすい。
料理は小さく（少量）作ることはできても、時間の短縮はできない。これを忘れてはいけない。
逆に大きく作るも道具のキャパシティの上限から制約される。型のサイズ、数量を揃えることは先行投資と維持保管するコストを増やす。オーブンをいくつも揃えることも現実的ではない。オーブンの内側のサイズを超えるサイズの料理はできない。
制約を知ること。
料理とプロジェクトマネジメント
- 何を作るか（プロジェクトの目的）
- いつまでに作るか（納期）
- 材料、道具は何か（リソース）
- 食材や道具にかけられる費用はいくらか（C）
- 作る料理の味（Q）、出来上がりの時間（D）、材料や人件費の費用（C）、スケジュール（S）の目標は何か
- QCDSが守れないとどうなるか（リスク）
- スケジュール（工程）を作成したか（計画）
- スケジュールどおりに作成しているか（予実）
- 出来上がった料理の味、分量は計画どおりか（評価）
- 得られた経験は何か（プラクティス）
調理とシステム開発手法
料理ではなく、調理。
- 何を作るか（仕様）
- 料理の味は設定できているか（完了基準）
- 盛り付けの要求はあるか（定性的品質）
- どのように作れば良いか手順を知っているか（手順の確立）
- どのような道具で作れば良いか（生産性向上ツールの選定）
- 料理を分解できるか（WBSの作成）
- 手順ごとの部品の作成（プログラムモジュールの作成）
- 全ての部品の統合（ビルド）
- 味見の結果はどうか（機能テスト）
- 盛り付けはイメージどおりか（非機能テスト）
- 食べた人の評価はどうか（UAT）
調理とツール＆テクニック
例えば時間短縮、品質の確保の観点で道具を使うことは生産性向上、歩留まりに貢献する。
調理とマインドセット
料理を調理した後のレスポンスは『美味しい』か『無言』である。調理をすることにおいて、そのマインドを外に置くことは調理人のマインドを揺さぶり、料理のできかがりに影響する。
議事録作成を技術で解決してほしい
日頃からの素振りの大切さは自分自身が一番わかっているつもりだが、機会を失うとそれこそ自然消滅してしまう。機会がなくなればそれまで使っていた振る舞いも、マインドの感覚を失ってしまう。しばらくしてそれをする機会を察すると、妙な緊張感を感じる。
例えば自分くらいの年齢や担当のしごとをしていると、議事録を取る機会はめっきりと減っている。
自分の中では、もしくは自分の主催する会議体であれば、次の項目を残せば良い。
- 議案
- 結果
- 課題・宿題
- 担当
- 期限
逆に言えば、主催者が変わると運営や議事録の残し方も変わる。出席する目的により、議事録の作成を輪番制にしたり、議論を思いのほか記すことを求められることもある。議事録の取り方の流儀に違いがあると、落とし所を見つけるか（実際には受け入れるか）、議論することのコストを鑑みそれに従うかのどちらかであるから、面倒くさい。
議事録を残すことは、出席者に業務委託のいない組織内の会議だとしても必要である。それがフォーマルな会議体であれば殊更だ。
業務委託のいる場で、委託内容を議論するのであれば必要性は言うまでもない。
であったとしても、議事録を作成するのは面倒である。記録を残すと言う時点で、何を書き残すかセンスを覗かれるし、取り交わされた会話を事実を曲げない程度で表現しなければならない。
通常、議事録は議事録用にメモを取り、議事録用の様式に清書する段取りを取るだろう。この手続きが非常に面倒くさいのは、清書の段階で記憶のリロードと会話の咀嚼と再言語化を伴うからである。
面倒なところは技術で解決することを発想するのがエンジニアである。実現したいのは、手をかけず、時間をかけず、議事録を生成するか、ネタとなる会議の会話の文字起こしである。
思い当たるのはUDトークであるが、数回試したところでは、会話の被らない会議であっても修正の手間は多い。
もう一つプロトタイプのサービスがあり試したところ、先のアプリより漢字変換は優秀であるが、少しマシな程度であった。
後者は、講演のようなスピーカーが1人のケースでは漢字変換も文字起こしも良好で実用に耐えられると判断している。
ところでそもそも議事録を書き起こすことを止めればそうしたことを評価すること自体をなくすことができるので、それを選択する方が良い。
議事録様式と記載の運用に従い、ライブコーディングのように書き切れれば8割がた終わったようなものである。
ただし、ライブコーディングを取り入れると、議論に参加することは難しい。
プロマネやコンサルのときは、実は割とやっていたが、現在は機会を失うとめっきりライブで理解をしながら残すことに抵抗を感じるのは年齢的な能力低下なのか、自分に課しているハードルが高いのだろう。
議事録作成の問題点は、次の2点だろう。
- 時間がかかること
- 再言語化するときに誤りを混入すること
今風で体裁を気にしないなら、ボイスメモとホワイトボードへのグラフィックレコーディングが良いだろう。
意味のない手続きを省く技術
職務柄、多（他）部署から相談を受ける。クライアントからの問い合わせへの回答をどうしたら良いか、的なものが多い。
問い合わせのシートを眺めると、こんなことを問い合わせてなんの役に立つのかさっぱり理解できないが、問い合わせている内容＝問い合わせ元の組織のルールやシステムの仕組みであることを察することができる。こうした問い合わせは、ある意味、手の内を明かしているようなものだ。
問い合わせ元の組織のルールも容易に想像がつく。多分に2000年前後から秘伝のタレのようになったルールにつぎはぎを重ね、さらに関連するルールが法規制の追加により横並びといくつもの関連文書として作られてきているのだろう。
たとえ1つのルールの文書であっても、その文書を根拠として働く社員以外には読まれることはない。過去の自分も同様に自分ごとになるまでは読む必要性はなかったから、よくわかる。
問い合わせ内容を眺めていると本来、その問い合わせを考えた狙いとは違い、形だけのアンケートになっているのではないかと疑わざるを得ない。
- それを聞いてどうするのか
- わざわざ書かせて、それを見てどうするのか
- 項目が埋められていることに満足するくらいなのではないか
もし問い合わせ内容を本当に聞きたければ、質問の回答の裏付けになるアーキテクチャを見なければ、その質問で回答させていることが機能しているか判別つかない。
考え方をガラリと変える必要がある。
- 運用の手続きを減らす
- つかないデータは持たない
この2点だけの視点で、いけていない現行の管理データを見直せば結果的に運用はシンプルになるはずである。
エンジニアならリファクタリングで鍛えられているからできるのではないか。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
- 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/06/23
- メディア: 単行本（ソフトカバー）
- 購入: 68人 クリック: 1,802回
- この商品を含むブログ (140件) を見る
