花を咲かせられないエンジニア
あなたは何ができるエンジニアか。
ほとんどのエンジニアは考え込む。
天を仰ぐか、下を向くか。
日頃、ロールを意識して仕事をしているエンジニアは、何かしら答えられる。
ただ、なにも答えられないエンジニアも肌感的には多い。
エンジニアの職業は分業ですすんできた。ITSSv3はその集成かもしれない。
実際、技術は複雑で難易度も高い。
アレもコレもプロフェッショナルだと自信を持っていうエンジニアは痛いエンジニアでもなければいないのではないか。
そのくらい技術は沼だ。
だからと言って、その技術を細分化しすぎると弊害にしかならない。
過ぎた専門性は無意識に、エンジニアに壁を作る。奥が深いから、それにフォーカスするからなのだが。
そのフォーカスし過ぎた技術は、深さと隣接する技術へのインタフェースだと意識できるか。
その意識を持てないエンジニアは、技術の花を広げられない。
月刊退職エントリーまとめ（2020年1月）
四半期のチャンクにまとめても、まとめる作業のバッチサイズが大きいと作業感も大きいので月刊化。
自社で育てたエンジニアがどんどん出ていってしまう問題、ほとんどの会社さんはサッカーで言うと「育成系クラブ」で、GAFAのような「ビッグクラブ」には多分永遠になれないので、そこら辺は「退職エントリで良いこと書いてくれればまた良い人が来てくれるからそれで十分」と割り切るしかないかな〜と😅
— 勝又健太@雑食系エンジニア (@poly_soft) 2020年1月23日
仕事をするときは、いつも終わらせることを考えている
自分の担当する仕事は、基本的に自分で設定した納期か、要請された納期には終わらせることができる。
どうしてできるかというと、納期のシビアな仕事なら他を劣後しても全力で片付けに行くし、裁量を持って納期を設定できる仕事なら、自分でコントロールできない分のリスクを期間に織り込む。
『それなら誰だって仕事を終わらすことができるじゃないか』と思うだろうけれど、現実はそんなことはない。誰もができるなら、どうして進捗管理をする必要があるのだと、質問に質問を返すことになる。
そしてそれは誰も答えを持っていない。
自分の仕事をするときは、いつも終わらすことを考えている。これは、プロジェクトマネージャをやるときには、いつもプロジェクトの完了の見通しにフォーカスしているからだ。
終わらせるために、どうすればいいか。それを考える。
無意識にゴール、完了の定義をする。
どうなったら完了と判断するのか。
コールを実現するアプローチはどうすればいいか。
経験のないアプローチならそれをどうすればゴールにたどり着けるようになるのか。
いつ、そのアプローチを試す機会を作ればいいか。
ゴールを逆算して再現できるか。
再現できると確信が持てるか。
ここまでやってはじめて手をつけられる。
あとは、実際にはじめて、ゴールを再現する作業を一つひとつ終わらせる。
1つ、作業を終わらせる。
終わらない理由を自分で作ってはいけない。
終わらせるために、タスクは小さくする。
大きなチャンクのまま、仕事を始めない。仕事がいつまでたっても終わらないエンジニアは、ゴールを曖昧なままに始める。曖昧なゴールは、解像度が低い。手をつけるとまるで転がる雪だるまのように大きくなってしまう。仕事のチャンクは自分に持て余すほどの大きさとなって、自分の思っていたのと違う仕事になってしまう。
仕事が終わらないから、その仕事の成果は誰にも届かない。工場で仕掛かりのまま、出荷されない未完成の製品のようなものだ。出荷されるまで、ただ、ひたすらコストだけが積み上がる。終わらないから、価値を持っている製品にならない。
仕事を終わらせるということは、結局、価値を創造しているのであり、終わらない仕事は損失を作っているだけなのである。
Slackって余裕という意味だったのに
コミュニケーションツールとして好ましい点にはこんなものがある。
・カジュアルにポンと連絡できる
・チャンネルで閉じた世界を作れる
・リアクションの言葉が面倒なとき絵スタンプ便利
メッセンジャのノリの文字で会話できるから、形式ばらない。本題から話せるなどのコミュニケーションコストは下がる。擬似的な会話に近い感覚だからだろうか。
ワークスペースやチャンネルの中に閉じれるので、都度誰とコミュニケーションを取るか意識しなくていい。セキュリティの観点で、外部とのやり取りの場合、チャンネルにinvできればメールのように誤送信が起きないので安全に使える。何より、宛先を間違えることもない。
メールだと文字に考えをまとめて起こさないといけない。でも、文章にするまでもないことや認知した程度のことやリアクションに困るときもある。そこでスタンプは当たり障りがない。
ところが自分としては、良いことばかりでもない。多分に使いこなせていないのもあると思うのだが。
・TLの流れの速さはツイッターか、というくらいなチャンネルもある
・チャンネル乱立
・mentionのないレスをチャンネルのハイライトでは見つけられない
勝手にチャンネルに召喚されて、似て非なるチャンネルがサイドバーに並ぶわ、group mentionで呼ばれすぎだし、活発なチャンネルは流れが異常に速い。なにがなんだか追ってられない。
☆マークをつけておけば良いのだがそのうち☆だらけになる。結果的に、チャンネルを巡回することになり、相応の時間が取られる。
メールはもともと非同期のコミュニケーションツールであるから、朝昼晩と時間を決めて読む運用もできたが、slackは割と即時性を求められることが多く、心理的な余裕が思ったいじょうに削がれる。
それでもメールよりはマシなのだが…。
ふと、slackって余裕という意味だったなと思い出す。
超人高校生たちは異世界でも余裕で生き抜くようです! 7巻 (デジタル版ヤングガンガンコミックス)
- 作者:海空りく（GA文庫／SBクリエイティブ刊）,山田こたろ,さくらねこ
- 出版社/メーカー: スクウェア・エニックス
- 発売日: 2019/07/25
- メディア: Kindle版
ウサギのウォーターフォール、カメのアジャイル
🐰「ウチはね、ガーっと一気に作るから早いよ」
🐢「それはすごいね。こっちはコツコツと作るかな」
🐰「やっぱりさ、やること決めて、変えずに突き進むんだ。ピョンピョンとね」
🐢「でもね、作るとき、これ必要かなって疑問に思うこともあるじゃない」
🐰「関係ないね、やると決めたんだ。だから、全部作る」
🐢「使わないことがわかったとしても」
🐰「わかってないな。使う、使わないじゃないんだ。約束したんだ。だから作るんだ」
🐢「一度に作っても使うかわからないから、使うものだけ作りたいな。一気に作るのはどうやるの」
🐰「🐰を集めてくるんだ。巣穴にいっぱいいるからさ」
🐢「🐰はいいね、優秀なエンジニアがすぐに集められて」
🐰「あちこちの巣穴に声掛けて、ヘッドカウント揃えるんだ」
🐢「へー、じゃあ知らない🐰も」
🐰「いる」
🐢「はじめて一緒にチーム組むの大変だよね。おなじバスに乗ってもらうのだって、時間がかかるよ。🐢は歩みは遅いから」
🐰「集めたら直ぐにスタートだ」
🐢「コミュニケーションとかどうするの」
🐰「前から後に伝言」
🐢「🐢は、ほら、甲羅がぶつかるから、もともと大勢は無理なんだ。ピザを分け合うくらいの亀数でコミュニケーションとるのがちょうどいいかな」
🐰「自慢の耳を使うのさ」
🐢「それで成果が出る」
🐰「みんな気になる方を見るけど」
🐢「大丈夫なの」
🐰「出来てから直せって。速いから間違ってたら直させればいい」
🐢「それも無駄だなー。どこまで進んだら使えるの」
🐰「全部できたら使えるよ」
🐢「全部出来るまで触れない」
🐰「一気にゴールまで進むからね」
🐢「欲しいものかどうかは全部揃うまで確かめられないのか。だから、途中で休んでるんだ。ゴールは違う場所なのに」
![[Sunflower] スリッパ ルームシューズ 来客用 レディース 滑り止め 可愛い ウサギ おしゃれ あったか ふわふわ 子供 プレゼント](https://images-fe.ssl-images-amazon.com/images/I/419uT8Y%2BDTL._SL160_.jpg "[Sunflower] スリッパ ルームシューズ 来客用 レディース 滑り止め 可愛い ウサギ おしゃれ あったか ふわふわ 子供 プレゼント")
![[ドラゴンボールゼット] Tシャツ 半袖 なりきり キャラクター 悟空 悟飯 ピッコロ オレンジ(亀) LL](https://images-fe.ssl-images-amazon.com/images/I/41bKNvWVx8L._SL160_.jpg "[ドラゴンボールゼット] Tシャツ 半袖 なりきり キャラクター 悟空 悟飯 ピッコロ オレンジ(亀) LL")
事業会社の立場で学べる5つのこと
ブコメしたように、ITベンダーに頼らず内製化ですよ。事業上の課題なり、業務上の問題は、その事業の、業務のオーナが自らの手で解決すればいい。
技術的に不足しているなら、エンジニアを雇用すればいい。雇用もできない甲斐性がないなら、期間を決めて採用して、技術トランスファすればいい。それもできないなら、現状にあまんじることです。
- 自分たちの「できること」でしか解決策を示そうとしない。
- 機能や性能については説明できるが経営や事業の成果にどのような貢献ができるのか説明できない。
- これからのテクノロジーやその可能性について分かりやすく説明できない。
- お客様が新しい方法論や見積を求めても旧来のやり方で提案しようとする。
- 新しい方法論やテクノロジーの適用を求めると保証できない、実績がない、時期尚早などのネガティブ・ワードで翻意を迫る。
引用 https://blogs.itmedia.co.jp/itsolutionjuku/2020/02/itsier.html
・1つ目から学べること。自分たちを、まさに自分、事業会社で考える。自分たちの出来ることはITベンダーに丸投げする解決策しか持ち合わせていないのだとしたら、思考の放棄かもしれない。
・2つ目から学べること。ITが経営や事業を一番わかるポジションにいるのはだれか。鏡を見てみよう。組織図を見てみよう。組織人事を見てみよう。IT部門のミッションは何かをもう一度読んでみよう。ここはIT企画の醍醐味ではないか。それはIT部門の手からはなしてはいけない。
・3つ目から学べること。選択しようとしているテクノロジは、経営上の、事業上の、業務上の課題を解決できると判断したIT部門が意思決定したもののはずだ。可能性で話すそうとするから話がおかしくなる。PoCをIT企画の段階でやろう。可能性などと曖昧な話はなくなるはずだ。
・4つ目から学べること。新しいしい方法論を選びたいのなら、それこそIT企画の段階でPoCをしてその方法論のポテンシャルを見極めるなければ、企画自体ポシャってしまう。見積もりだって。それも自分でやらないと予算組めないし、確保も、精査もできなくなってしまうだろう。
・5つ目から学べること。IT企画はプロジェクトだ。プロジェクトは唯一無二のものである。つまり、誰も試したものはいない。似て非なるプロジェクトが過去にあった、という事実しかない。プロジェクトのオーナが意思決定するものだ。意思決定できないなら、IT企画の段階でプロトタイプなり、プレプロジェクトをやって意思決定出来る情報を集めればいい。
失敗の仕方というアドバンテージ
若いエンジニアから「最近新しいことを始められたと聞いてすごいとおもいました。失敗は怖くないですか」と聞かれた。
以前、メンバのエンジニアにコンピテンシを広げるとき、「それ役に立ちますか」と問われたことがあった（そのエピソードについては過去に書いた）。
役に立たない、失敗はしたくないという気持ちはわかる。役に立つこと、成功につながることをしたいのはよくわかる。それは年齢に関係なく、同じことを思う。
でも、やってみることに失敗はつきものであることもわかっている。
多分に失敗をしたくないというか、失敗にデメリットか、マイナスのイメージを持っているのだろう。
でも、やったことのがないことは、例えそのやり方が手順化されていたり、明確だったとしても、自分で成功して繰り返しても成功する経験がなければ、失敗する自信はある。
ただ、その若者に引き合わせた知人もそうだが、新しいことに手を出して結果を出している人は失敗をする。
それも上手に失敗する。
別に失敗するためになんでも試すわけではない。もちろん、上手くいくといいな、くらいか、これで行けると思いながらやってみる。
それで、何が上手くいくと思いながらやっているかというと、
「もし『こう』すれば、結果は『こう』なるだろう」
とやる前に考える。
その結果はどうかと言えば、『こう』ならない。十中八九ならない。でも、「こう」すればを仮定するときに、仮定の条件を押さえているから、次の「もし『こう』すれば」につながる。
そのうち、期待していた「結果は『こう』なる」に到達して、その時点で一旦ヨシとする。
なぜ「一旦」」というと、それを評価出来る人かそれを作ったターゲットの人に見せて反応知って、フィードバックするつもり満々だからだ。それで反応が上々であればそのままGOにする。
年齢の30歳の違いは「失敗の仕方というアドバンテージ」なのだと思っている。
とはいえ、モニターの買い替えでは失敗したくないからどれがいいか迷いに迷ってなかなか決められない。
おすすめが有れば教えて欲しい。
iiyama モニター ディスプレイ X3291HS-B1 (31.5インチ/フルHD/AH-IPS/HDMI,D-sub,DVI-D/3年保証)
- 発売日: 2015/12/07
- メディア: Personal Computers
LG モニター ディスプレイ 32UK550-B 31.5インチ/4K/HDR10/VA非光沢/HDMI×2、DP/FreeSync/スピーカー/高さ調節/フリッカーセーフ、ブルーライト低減
- 発売日: 2018/10/11
- メディア: Personal Computers
