合同会社モリカワのブログ

森川敬一。CTOとして30年やってきました。集大成としてCTOを増やすという事を目標にやってます。

若手エンジニア向け:小さな目標設定

ここでの目標設定は、評価制度としてのMBO(Management by Objectives : 目標管理制度)等の評価のための目標設定ではありません。評価に関係なく、自分自身で設定する目標設定の話です。

とにかく目標設定しよう

仕事をして行く上で、やはり自分自身で目標設定するのは、非常に大事です。そして、個人として将来の目標に向けて目標設定する場合、高い目標設定を行わないと面白くありません。容易すぎて、簡単に実現できてしまっても良いですが、難しい方が達成感が大きいので気持ち良いです。
ミスチルの歌で

高ければ高い壁の方が登った時気持ち良いもんな
まだ限界だってみとめちゃいないさ
copy

って歌詞が好きです。
諦めずに高い壁にチャレンジしたいです。

ただ、ここの目標設定が高すぎて、目標を見失ってる人が結構います。大事な事は、小さな目標設定をして、一歩ずつクリアして行く事です。千里の道も一歩から。先ずは、そこから始めてみましょう。

小学生の時の出来事

僕の小学校の頃の水泳話

小学校3年生の出来事です。
喘息持ちの僕は、体育とか水泳とかの授業の時、皆がやってる風景を眺めている傍らの人間。
激しい運動をすると喘息の発作がおこるので、調子の良い日以外は、見学者って奴です。
当然、水泳では、5メートルさえも泳げた事もなく、苦手。苦手。
苦手と思うと、更に精神的に泳げるはずもない状態。
そんな日々をすごす中、水泳の記録会がありました。
当然、憂鬱な気持ちで水に使って、スタートの笛が鳴るのを待っている僕。
「ピーッ」と笛が鳴り、プールの壁を蹴り付けた時、プールの底の5メートルの線が目に入る。
「よっしゃ、あの5メートルの線まで泳いだらやめよう。」
自分にとっては、好きで無い水泳なので、早くあの5メートルを超えたい気持ちで一杯です。
一生懸命に腕を動かしてました。すると思ったよりも、簡単に5メートルを超えました。
昔から欲張りな人間だったんですね(笑
「じゃー10メートルまで頑張ってみよう。」
10メートルの次は、15メートル。20メートル。
20メートルを超えると、プールの壁が見えてくる。もう限界だと思う気持ちと、後少しと思う気持ちが入り乱れながらも、死ぬ気で腕を動かし続けました。
正に一心不乱。
気が付いたらゴールの壁に手が付いてました。
初めて25メートルを泳いんだんです。しかも、一心不乱に泳いだお陰もあり、クラス中の高タイムを出せました。
copy

所詮、小学生のプールの出来事。しかも、たったの25メートル泳いだだけの出来事ですが、この出来事は今でも鮮明に覚えてます。

まとめ

この出来事は僕に2つの教訓を与えてくれました。
1.人間やれば出来る。不可能なんて無い。
2.高い目標もプールの白線の様に少しづつ目標を置いて、少しづつクリアしていけば良い。
高い目標も出来ると信じて、小さな事からコツコツと頑張る事。やれば出来るさ。

今後も続けていきますので、フォロー、イイね、シェアお願いします。
下記、説明会もご参加下さい。
エンジニア年収アップ講習(転職サポート付き!) 無料説開会 12月6日 19時開催

エンジニアのコピペだめなの??嘘でしょ?

エンジニアのコピペが駄目だという記事を見かけました。
あえてリンクは張りませんが、僕には全く賛同できませんが、イイねもついてます。
皆さんはどうお考えですか?少し不思議に感じましたので誤解が広がりたくないと思って記事を書きました。

コピペでスキルは向上しなくない

コピペして出来た気になってしまい理解しないので、0から書いた方が良いと記述がありましたが、今どき、0からコーディングするのって何時代って感じです。昭和の根性にしか思えません。0からタイピングするのと理解するのは全くの別軸の話です。
そもそもコピペするという事は、そのコードを修正するからです。修正しないのであれば、ライブラリとして利用すれば良いです。修正するという事は理解した上で修正します。逆に理解しないと修正出来ないのです。
更にキレイなソースコードをコピペする事でキレイなソースコードの書き方を覚えれるし、保守性があがって生産性が上がります。コピペするべきだと思います。

コピペは考える足かせにはならない

先述の通り、修正する上では考えます。冗長なソースコードから必要な部分のみ抜き出したり、こんなエラー配慮が必要なのかと勉強になったり、パズルを埋めるためには色々と考えます。コピペは考えるためにも必要な行為です。

コピペで現場で痛い目に遭うわけない。。。

ネットにアクセス出来ない現場の時に困るという話なのですが。。。これもいつの時代だろうという話です。もちろん現場でネットにアクセス出来ない方はいるかも知れません。でも何パーセントの人でしょうか?大多数のエンジニアには関係ない話だと思います。

ラリー・ウォールが提唱したプログラマの三大美徳

  • 怠惰 (Laziness)

全体の労力を減らすために手間を惜しまない気質。
この気質の持ち主は、役立つプログラムを書いてみんなの苦労を減らしたり、
同じ質問に何度も答えなくてもいいように文書を書いたりする。
よって、プログラマーの第一の美徳である。
copy

怠惰なエンジニアは、同じコードを二度と書きたくありません。是非コピペしていきましょう!

  • 短気 (Impatience)

コンピューターが怠慢な時に感じる怒り。
この怒りの持ち主は、今ある問題に対応するプログラムにとどまらず、
今後起こりうる問題を想定したプログラムを書く。
少なくともそうしようとする。
よって、プログラマーの第二の美徳である。
copy

短気なエンジニアがやるべきは、既に実装された部分ではなく未来を見据えたコードを書くことです。
コピペした上で該当システムに最適なコードに成長させましょう。

  • 傲慢 (Hubris)

神罰が下るほどの過剰な自尊心。
または人様に対して恥ずかしくないプログラムを書き、
また保守しようとする気質。
よって、プログラマーの第三の美徳である。
copy

恥ずかしくないソースコードを書くために、キレイなコードをコピーして修正していきましょう。ソースコードのキレイさは、見た目のキレイさもあります。目で覚える事もキレイなソースコードを書くには重要です。

以上、ガンガン、コピペしていきましょう!

  •  

マネジメントtips:期待値の調整を恋愛に例えてみた

人間関係の中で注意しておく必要があるのが、期待値です。相手との会話、やり取りで期待値がどこにあるのかを注視しておく必要があります。
期待値が高ければ高い程、結果も高く求められます。逆に、期待値が低い状態の場合、結果が少しでも良いと、評価が上がります。

期待値を恋愛に例えてみた

恋愛で考えると非常に分かりやすいのです。
最初、情熱的に盛り上がると相手に対して、沢山の期待をしてしまい。ちょっと期待と外れてしまうと、とても残念な気持ちになる。逆に最初から想っても無い状態から始まると、ちょっとした出来事で感動したり、喜んだりという事になる。第一印象が悪いと、加点ばかりでドンドン良くなる奴です。

彼氏:これプレゼント!
彼女:嬉しい!これ欲しかったの!
彼氏:それは良かった。
彼女:でも今日は、誕生日でも何でもないのに、どうしたの?
彼氏:君の笑顔がみたいからだよ
彼女:こんな事してくれと思ってなかったから余計に嬉しい!
copy

これは期待値が低かったので、効果が高かったパターン。いわゆるGAP(ジーエーピー)です。

彼氏:明日レストラン予約した!
彼女:私の誕生日!ありがとう!
レストランにて
彼女:美味しかった!ありがとう!
彼氏:良かった、じゃー帰ろうか。
彼女:あれ?プレゼントは?
copy

これは、期待値が高くなってしまってる、駄目なパターン。

期待値の調整を常に意識しよう

マネージメントにおいて、この期待値の調整は、重要なメソッドとなります。
メンバーの中で育って欲しいメンバーや、成功して欲しいプロジェクトを担当しているメンバーには、沢山の期待している事を話してあげましょう。そうすると、メンバーは、その期待を感じて、成功に向かって頑張ってくれます。
逆にメンバーへの期待が過度に高い状態だと、期待値とのギャップから良く無い所が気になって仕方ありません。従って、メンバーに対しては期待値が高いと伝えながら、自分の中の期待値はある程度抑えておく必要があります。
評価にも期待値を下げた状態で好評価するとGAPで喜ばれますが、期待値を上げすぎると、評価が足りてないと残念な状態にさせてしまいます。
上手に期待値をコントロールしましょう。

マネジメントtips:プレッシャーと生産性

仕事でプレッシャーは付き物です。納期あれば、納期のプレッシャーがあるでしょうし、成果物があると成果物としての品質のプレッシャーがあるでしょう。

もちろん、エンジニアという職種の人達には、プレッシャーの中で仕事をしている事が多いと思います。

プレッシャーと生産性

トム・デマルコの著書『デッドライン』によると、プレッシャーを掛ける事によって、生産性が向上しない。
*結構古い本ですが、読みやすくて良い本です。
理由は、「思考は速くならない」からだと記されている。

プロジェクトには、様々なプレッシャーが存在する。
そして、人間は、プレッシャーを与えられるとそれに対応して、生産性があがると思われている。
しかし、人間は、プレッシャーを与えられても、思考が早くなる事は無い。
頭の回転は、速くならないので決して、生産性があがる事は無い。
copy

という物です。

画像
プレッシャーと生産性

確かに、その通りだと思います。加えて、高プレッシャーは思考が遅くなります。ハードルが高すぎると諦めて思考停止したり、目標を見失ったりするためです。ムチでしばいて、24時間、365日働かしても生産性は向上しません。むしろ、残業時間が少ない方がTotalの生産性は高い。総労働時間とプロジェクトの成果物は、単純比例しません。

やる気と生産性

どうすれば、生産性は向上するのか、それは、「やる気」である。
プロジェクトメンバーの内面の「やる気」があがれば、生産性は、向上する。それには、適切な労働時間、適切な環境、適切な賃金、適切なコミュニケーション、適切なチャンス等が必要となる。

画像
やる気と生産性

そして、これらは、人によって適切な労働時間違うし、適切な環境も違う。もちろん、人によっては、適切なプレッシャーが必要な人間もいる。
最終的には、生産性をあげるためには、個別の人にフォーカスをあてて、個別に程度なプレッシャーを与えるマネージメントが必要である。

実体験:アウトプットは大事は、本当か??

CTO歴20年以上、エンジニアとしても30年やってるとインプットする事が少なくなってきます。いや、実際はインプットする事が少なく感じてきます。

インプットが少なく感じる理由

喜怒哀楽が無くなったのが理由。 若い頃は、知らない事だらけなので色んな事が新鮮で、関心したり難しく感じたりします。難しい問題に直面すると少し恐怖を感じたり、不安になったりしますが、それが解決すると喜びを感じます。時にミスをすると自分に怒りがこみ上げたり、悲しみ暮れるときもあります。
こういう時ってインプットしてるなぁと感じます。新しい事がなくなってくるとインプットがなくなると感じる一番の理由です。
旅行に行く時、行く時は知らない道で分からない事ばかりなので、長く感じますが、帰り道は、結構短く感じる。
あの現状、ジャネーの法則というみたいです。

ジャネーの法則

人は経験したことがないことをやっているときは、それが強く意識に残り時間が長く感じます。反対に、慣れてしまうと時間の長さが気にならなくなり、あっという間に時が過ぎたように感じます。

2022年11月からは沢山記事書いてます。

現在、エンジニア顧問等をやってますが、今後の人生、エンジニアを育てたいと思うようになりました。
その手始めとして、記事を沢山書いていこうと思いました。先ずは年内に100記事を目標にしてます。
昔、IMJに居た頃はブログを書いてましたが、最近、アウトプットをしてませんでした。ジャネーの法則の通り、新しい事が無く、書くネタが思いつかなかったからです。
かなりハードルが高いと思いますが、やった事のない事にチャレンジしてみて何かが見えるかと思って始めてます。

アウトプットは大事は本当だと思う

年内に記事100なので月に50記事を書く必要があります。このためにはインプットが必要です。決めたからには、がむしゃらにインプットするしかありません。
これを機会にKindle Unlimitedの読み放題に登録しました。このサービスは過去に何度か登録した事はあるのですが、月に100冊とか本が読めます。今月も100冊くらい読みました。
真剣に読んでるわけではなく、流し読みです。基本、本の内容も新鮮味を感じる事がなかったのですが、今回の読み方は、キーワードを見つけて、そこからネットで調べて知識を深めていく。そんな感じでドンドンと勉強のスパイラルに回してます。そして、勉強した内容と自分の知識がくっつくと良い感じのアウトプットが出来上がります。
更に本からは、考え方も学んでます。一つの物事の説明でも人によって言葉が違います。これは色んな人と会話してるのと一緒で非常に参考になります。

最後に

アウトプットに向かうためには色んなインプット、勉強が必要となります。
あらためて無理やりでもアウトプットしていくのは大事だと感じました。
今後も続けていきますので、フォロー、イイね、シェアお願いします。
下記、説明会もご参加下さい。
エンジニア年収アップ講習(転職サポート付き!) 無料説開会 12月6日 19時開催

マネジメント保存版:若手エンジニアの成長促進の3つのメソッド

CTO/VPoEのマネジメント職にとって若手のエンジニアの育成は重要課題です。
今回は、成長促進の3つのメソッドをお教えします。

1.競わせる

単純ですが、競わせる事で自主的に勉強し努力し成長していきます。この自主的が重要で、他人からの指示では工夫、努力をしないし、達成感が薄いです。
そして、重要なのが個人でなく集団で競わせるのがポイントです。日本人は、ワールドカップの盛り上がりが示す様に集団vs集団に対して異様に盛り上がる部分があります。単体ではサボる事もグループだと最後まで頑張るし勝つ意欲が継続します。グループを作って、グループ同士で競わせましょう。
具体的には、

  • コスト削減タスクフォース
    クラウドサービスのコストダウンのためのタスクフォースを作って、コストの削幅を競わせる

  • ラボ
    研究テーマを自分達で決めてもらって発表してもらう

  • 業務改善コンテスト
    業務改善に繋がるアイデアを具体的に実装してもらう

他にもグループで競わせる案を考えてみてください

2.キャスティング

ポジションが人を育てます。環境が人を育てます。

  • サポーターにする
    リーダーになってもらう手前に、特定メンバーのフォロー役として担当してもらいます。教えたり、相談に乗ったりする事で目線が変わってきます。

  • リーダーにする
    リーダーというポジションを与える事で、リーダーとしての勉強をしたり振る舞いが変わってきます。

  • メンバーを変える
    担当メンバーを増やしたり減らしたりすると仕事のバランスが変わるので、どの様に役割分担するのか考えたり試行錯誤するきっかけになります。

  • ポジションを変更する
    担当部署や担当PJを変える事で新規一点、やる気を与えたり、メンバーが新たになることでマネジメントの経験が広がります。マンネリ化脱却としても有効です。

  • 同じランクに優秀な人財をアサインする。
    現状からの脱却に悩んでいるフェーズに同じリーダー格で自分とやり方の違う優秀なリーダーが入ってくると参考にして動きが変わってきます

3.アウトプットしてもらう

アウトプットするためには、勉強が必要です。アウトプットで恥をかきたくないので、必死で勉強します。勉強した内容をアウトプットするので質問に対処できる様に自分なりに整理して理解します。勉強して整理して理解して初めてアウトプットができる状態になります。
加えて、当然ですが、アウトプットの仕方の練習にもなるし、1:Nのコミュニケーションの練習になる。ポジションが上がっていくと、1:1のコミュニケーションだけでなく、1:Nのコミュニケーションが徐々に増えてくる。これはこれで特別なノウハウが必要で工夫も必要です。
いかがでしたか、若手エンジニアの成長促進の3つのメソッドをご紹介しましたが、エンジニアとしてのスキルアップ等にはふれてません。スキル外の成長要件についての3つのメソッドです。是非、チャレンジしてみてください。

若手エンジニア向け:ストックとフローの使い分け

コロナになって3年目、リモートワークもなれてきた頃です。皆さん、会社単位で、プロジェクト単位で、部署単位で、色々と工夫されてると思います。
リモートワークで最も重要なのが、コミュニケーションツールです。
このコミュニケーションツールの使い方で、特に若手エンジニアに向けたアドバイスです。

ストック型のコミュニケーションツール

ストック型というのは、stock溜まっていく形のコミュニケーションツールを指します。
例えば、メール等、相手から送信の都度メールボックスにメールが届きます。これはメールという単位でメールボックスに溜まっていく方式になってるので、3日前のメールと今日のメールは、別々にメールボックスに存在します。つまり、ドンドンと溜まっていくコミュニケーションツールです。
メール以外にもチケット管理のツール、JIRA、redmineとかのツールもチケット単位になってるのと、チケットの更新の都度メールが送信されていて、ドンドンと溜まっていくコミュニケーションツールと言えます。

画像

フロー型のコミュニケーションツール

フロー型というのは、flow流れていく形のコミュニケーションツールを指します。
例えば、slack,チャットワーク、メッセンジャー、line等です。メッセージがドンドンと流れていく形になってるので、スピード感あるし、軽いメッセージのやり取りには、最適です。複数人でのメッセージも最適で、他の人のやり取りを眺めながら自分の意見を差し込んだり、やり取りの状況を確認したり出来ます。

画像

フロー型コミュニケーションツールの間違った使い方

昨今の仕事の殆どが、フロー型のツールに以降してきてます。社内だけでなく、社外とのやり取りもフロー型のツールに移行してきています。プロジェクトの中の特定の連続性のあるトピックについてのやり取りであれば、フロー型は過去の履歴を遡る事で、意図や経緯を理解出来るので便利です。
しかし、連続性のあるトピックの中に急に非連続性のタスクを依頼する人がいます。
これってむちゃくちゃで、受け取った相手は、気づかない場合が多いし、気付いたとしても、一瞬見ても、フローで流れて別のトピックになってると、自分で遡ってタスクを探さす必要があります。
一方、ストック型のコミュニケーションツールであれば、急に非連続性のタスクを依頼しても別メールとして残ってます。1通づつ確認する事が出来ます。
もちろん、slackなら自分へのメンションだけ見れる様になってますが、メッセンジャーやlineとかだと自分で一生懸命探さないとだめ、これはもう最悪です。slackは、スレッド化も出来るので更に便利ですね。
ただslackも既読つけると探す必要が出てくる点ではやはりフロー型のコミュニケーションツールです。

困ったストック型とフロー型の使い方

上司:来週から目標設定面談を開始するので、皆さん面談シートの記入を今週中にお願いします
あなた:わかりました。
同僚A:面談シートは、2022版の奴が最新版でしたよね?
上司:そうだね。2022版で。
先輩A:わかりました。
---1時間後
あなた:ところでプロジェクトの見積もりチェックお願いします
客先の上司:チラ見。
---1時間後
同僚A:面談シートは、メールで送りました。
上司:了解。
先輩A:面談シートは、メールで送りました。
---3日後
あなた:見積もりチェックいかがでしょうか?
上司:おっと、見落としてた。。。
見積もり間に合わずに失注できました。

正しいストック型とフロー型の使い方

上司:来週から目標設定面談を開始するので、皆さん面談シートの記入を今週中にお願いします
あなた:わかりました。
同僚A:面談シートは、2022版の奴が最新版でしたよね?
上司:そうだね。2022版で。
先輩A:わかりました。
---1時間後
あなた:ところでプロジェクトの見積もりをメールで送っておきました。チェックお願いします
客先の上司:チラ見。
---1時間後
同僚A:面談シートは、メールで送りました。
上司:了解。
先輩A:面談シートは、メールで送りました。
上司:メールで見積もりみたいよ。納期が入ってないので納期入れたらOKです。
無事に受注できました。

ストック型とフロー型の特性を理解して利用しましょう

ストック型には、ストック型の良さ、フロー型には、フロー型の良さがあります。各々の特性を理解せずに自分勝手なコミュニケーションを取っていると相手が困るし、仕事が滞るばかりです。社内の人間であれば、それだと気づかないのでチケット切ってくれと言われるかもしれませんが、外部の方だと言いづらい可能性もあります。
ツール一つとっても常にメリット・デメリット等の特性を理解しながら使う様に気をつけるとビジネスレベルが1段アップすると思います。