GoogleのGROW モデルを用いて、自分の中のものの棚卸をしてみた。

https://rework.withgoogle.com/jp/guides/managers-care-professionally-personally-for-team/steps/hold-effective-career-development-conversations/

Goal: 目標の明確化。チームメンバーがキャリア形成の先に見据えているものを特定します。

「1 年後、5 年後、10 年後の自分はどうなっていると思いますか?」

  • 1年後:

  • 5年後:

    • 個人の制作物で顧客に価値を提供する
    • もしくは、自社開発している製品に深くコミットし、顧客事業への貢献にやりがい
  • 10年後:

    • セミリタイアしていてほしい。
    • そろそろ結婚?

「収入や現在のスキルの制約がないとしたら、どのような仕事に就きたいと思いますか?」

  • VRChatのような、人が「現実」と切り離して楽しめる空間づくり
  • 顧客のビジネスにコミットし、本当に約に立つようなIT化、システム化の実践
  • ある分野のスペシャリストとして、プロダクトへの問い合わせに対する対応を行う役回り (Redhatみたいな)

「興味、価値を置くもの、原動力となっているものは何ですか?」

  • 仕組みを理解する
  • 頭の中で考えたものをアウトプットし、世の中のどこかの誰かに評価、反応してもらう。
  • プロセスの最適化(効率化ではない)

Reality: 現状の把握。チームメンバーの現在の役割とスキルを理解します。

「現在の業務で最もやりがいを感じること、あるいは、ストレスを感じることは何ですか?」

  • 運用

    • やりがい

      • 顧客からの問い合わせについて、的確な回答を自信をもってできたとき。
      • 発生した障害において、的確な原因特定と対策を行えたとき。
      • 「これは最適である」と自分で思えるようなシステム構成、パラメータ設定を根拠に基づいて実施できたとき
    • ストレス

      • まだ理解のないシステム、機器について、障害対応など時間的に制約があり、かつ間違いの許されないという類の作業を行うこと
      • 煩雑なフローに従い、管理画面をポチポチしていく仕事
      • 形式的に残っているが、本質的には無価値な仕事
  • 開発

    • やりがい
      • 現行動いているコードを理解すること。

「現在の業務はやりがいがありますか?能力を伸ばせていますか?どうしたらさらにやりがいを感じられますか?やりがいのない業務は何ですか?」

  • 現在の業務はやりがいがありますか? はい

  • 能力を伸ばせていますか? はい

  • どうしたらさらにやりがいを感じられますか?

    • 一刻も早く、触れる技術、システム、プロダクト自体についての理解を深める
    • Linuxについての知見を深めて、プロダクトの改修に組み込む
    • 顧客、もしくは現場に貢献出来ていて、それによって感謝されていると感じられる構造を作る
  • やりがいのない業務は何ですか?

    • 手作業のテストはやりがいを感じなさそうなので、できれば自動化する。
      • CI/CDなどを導入し、テスト作業自体は手動でも、テスト失敗による「修正→再テスト」の回数を減らすことでテストの回数を減らす。

「自分の長所と短所について、他の人からどんな指摘を受けたことがありますか?」

  • 割愛

Option: 選択肢の検討。目標と現状のギャップを埋めるための方法を複数考えます。

  • 割愛

    • 「以前話し合った目標達成のためのスキルを磨くのに、今できることは何ですか?」
    • 「自分を伸ばすために、どのような仕事やプロジェクトに挑戦したいですか?また、どのような経験をしたいですか?」
    • 「選択肢として、どのようなネットワークやメンターシップがありますか?」

Will: 意思の確認。現状から目標に向かうための実現可能なステップを特定します。

  • 割愛

    • 「何を、いつまでに行いますか?」
    • 「役に立つリソースは何ですか?目標達成のために役立つスキルは何ですか?」
    • 「どのような支援が必要ですか?自身のキャリア形成について、マネージャーやリーダーからどのようなサポートを受けたいと考えますか?」

共感は正しさの担保にはなるが、結果は担保してくれないという話

リアル、オンライン問わず、多くの人に共感をしてもらったり、理解を示してもらえたことについては、「それがやはり正しかったんだ」という気持ちになる。
肯定されたその価値観や判断基準に基づいて引き続き進んでいけば、望ましい結果にたどり着けるように思いがちだ。

でも、ここに落とし穴があるなと気付いた。
当然だが周りのみんなが同意したからと言って、その価値観・判断基準に従って選択をしていった結果が、目的に照らして望ましいものになるとは限らない。
端的に言えば、失敗するかもしれないということだ。

共感してもらうとやはり気持ちいいし、それ自体がモチベーションになる。僕の創作のモチベーションはそこにあって、それは大事にしたいなと思っている。
ただやはり、「共感してもらえた」という結果は、正しさを担保しない。なかなか厄介な感情というか、構造だなと思う。

判断において、他人に相談したりとか、自分の意見を話して情報交換・議論することは大事で、そのフィードバックは貴重なものではあるけれど、
「誰にも理解はされないが、この判断は正しい」と自分を信じて突き進むべきフェーズも必要なんだろうと思う。
他人に理解される、共感してもらえるという経験から自分の判断基準を、価値観を醸成してしまうと、それによってどこかで致命的な判断ミスを犯しそうな気がして、この記事を書いている。

何でもかんでも疑って、自分で判断しないといけないということだ。
ただ、そんなことをやり始めるといよいよ何も判断できなくなってくるなとも思った。
上の立場に立った人や、組織をまとめる立場に立った人は、ある程度の判断を自分で下さず、他人に任せたりすることが必要になる。
あと、現実問題時間は有限だから、いちいち些細な判断において時間をかけているとそれだけで1日が終わってしまうだろう。
重要度やインパクトに応じて、どこまで考えて自分で判断するかを決めるのがいいんだろうという気がする。

そこまで重要度やインパクトのない、でも下す必要のある判断については、ある程度納得できない感が残っていても決断してしまうか。
もしくは、ある程度の失敗を見込んだうえで納得して、決定を下す。

そんな感じが望ましいのかな。*1

*1:自分は、「望ましい結果にたどり着くような判断をできているか(間違っていないか)よりも、納得できる判断をしているかに重点をおいている気がする。そういう意味では、将来の自分になじられても言い返せるような意思決定をするというのがより適切かもしれない

【運用】今日上司から割と貴重なアドバイスをもらった

今日上司から割と貴重なアドバイスをもらった

  1. 自分を信じすぎている
    → 発行したコマンドが本当に自分の意図した挙動になっているか確認してほしいし、不安になってほしい。

  2. 記憶に頼りすぎて失敗している
    → サーバのパラメタ等の情報について、いつも触っているサーバでも記憶に頼らず、毎回資料を確認して、担保を取るべき。
    もしくはそこまでの手間をかけなくても、他の人に確認して、ダブルチェックで担保を取るなどしてほしい

1について具体的にいうと、sudo /usr/sbin/postmap /etc/postfix/accessで設定を反映するという作業についてだった。
このコマンドを発行すると、/etc/postfix/access.dbというインデックスファイルが更新される。1

access.dbが変更されるということは知っていたが、sudo /usr/sbin/postmap /etc/postfix/accessを発行したのち、本当にaccess.dbが更新されているのかについて、コマンド発行後エラーが出力されていなければそれは更新されたに違いないという認識だった。

設定ファイルが文法的におかしいとかがあればコマンドがそれを判定して出力でエラーを出してくれるだろうし、
そもそもsudo /usr/sbin/postmap /etc/postfix/accessを正しく発行してもaccess.dbが更新されていない場合があるかもと、コマンドそれ自体の挙動を疑うという意識は全くなかった。
コマンドやシステムについても、信用しすぎていた。2

具体的には発行の後、「access.dbのタイムスタンプを確認して、日時が反映時刻になっているかをしっかり確認しようね。」そして、「そこを確認しておかないと不安になるという認識でいてほしい」ということなんけれども、上司と僕の意識が異なる根っこにはそういう認識の違いがあった。

特に何かイベントがあったというわけではないんだけど、ふとしたきっかけから、僕の今までの行動や考え方を踏まえて指摘してもらえて、非常に貴重なアドバイスだったなと思った。

僕はちょくちょくとつまらない確認漏れから生じるミスをやらかしていて、色々考えた挙げ句わからなかったので半ばそういうタイプの人間なのだろう、自分の不得手であり、不向きな部分であり治らないものなのだろうと諦めていたんだけど、諸々のミスの根源はこの認識違いによるものかもしれないなと思った。たぶんそうなんだと思う。

現状、頭では理解したし納得したが、身体に染み込むレベルではまだ認識できていない。 これは正直、一朝一夕で身につくものではないと思う。

日々の業務において「自分を信用せず、意図した挙動になっているかを逐一確認する、担保を取る」という意識を心がけて、
少しずつ習慣に、そして常識に落とし込めていければいいなと思う。


  1. それをpostfixが読みに来ることで送信者などの条件によって、受信動作の振る舞いを変更することができる?(smtpd_client_restrictions)。ちょっとここらの認識は怪しい。 http://www.postfix-jp.info/trans-2.1/jhtml/access.5.html

  2. 経験年数の重みを感じたんだけど、上司はLinuxのバグを踏む経験とか散々しているので、コマンドそれ自体についてもあまり信用していない

僕がやってて楽しいことは

  1. 思いついたアイデアを形にすること。他人から見える形としてアウトプットすることによって、そのアイデアを知ってもらうこと。反応をもらえればなお良し。

  2. 仕組みを理解すること。

  3. 何かを最適化すること(「効率化」ではなく、「最適化」だった)。

割と自分の中で固まって、シンプルに整理できるようになったのでメモ

ブログにはもうひとつのモチベがあって。 最大効用のブログに書いてあることだけど、自分が2時間かけて見つけたものを次の人が5分で終わらせることができたら幸せだよねって。

仕事はあくまで手段であって、仕事自体を目的にしては大事なことを見失うなと思った話

タイトルで全てみたいなところはあるんですが。

僕の目的は、毎日楽しく生活すること。
→ そのためには、一定量のお金が必要となる
→ お金を稼ぐための手段として、仕事をしている

というのが、自分の中での順序。

これがたまに、仕事それ自体が目的になることがある。
その状態自体は間違っているものではないんだけど、その状態になると結果的に疲弊して摩耗する(自分は)。

仕事自体を目的にできるなら、正直それが一番良くて、
「仕事できる上になんかお金がもらえる!」みたいな状態になる。

ちょっと試してみたんだけど、自分には向いていなかった。

以上。

僕がなぜ自己啓発本を読まなくなったという話と、人生観について

大学2年の頃から書き溜めていたノートを整理していて、懐かしいものが出てきたので書き起こしてみる。
数にして86冊目。このノートを使っていたのは、2018年の11月頃のようだ。


  1. 自己啓発自体は、人間が幸せになる手段の1つとして何ら間違ったことではない。
  2. 嫌い、信用していないのは、本や公園、(特に新卒などを相手にする)アドバイザー
    → まず前提として、正確な情報を順序立てて伝えてくれるだけの本、イベント、公園は除外する
    → 強い言葉を使って、「こうすべき!」みたいなことを言う自己啓発
    → 言った本人は、それで影響された人が失敗しても責任を取らない、取ってくれない
    → の割に、「絶対」みたいなニュアンスで伝えがち

今は反対に後輩もできて、アドバイスもする側の立場にもなった。
「こうした方がいいよ」というアドバイスをした方がよい、せねばならぬ場面にも出くわすけど、そこに責任は取れないので、
色々言った最後に「でも自分で判断してね」と毎回付け加えている。正直変な人になってると思う。
でも、僕の根っこを構成するところなので、どうしても気にしてしまうなと思う。

僕が嫌いだったセミナー講師おじさん、おばさんと同じことを自分がしないよう心掛けて生きていこうとノートを開いて改めて思った。

エンジニアの学習のモチベについて

・不安駆動

・好奇心駆動

・なりたい駆動

・お金駆動

 

並べだすともっとたくさんあると思うけど、とりあえず。

 

一番身の回りで見かけるのが不安駆動。

将来不安他色んな不安に駆られて頑張ってる人。

 

次に見るのが好奇心駆動。

望ましい形だなと思ってるやつ。

 

とりあえずこの2つだけ思いついて昔記事にした(そして表現が過激になったので非公開にした)けど、他にもあるなと思って。

 

なりたい駆動というものがあった。

これは昔の自分これやったなと思う。

アニメ見て影響されるやつ。

 

同僚を見てると顧客駆動みたいなのもある気がする。

役に立つために頑張る。他人のために頑張る。

 

お金駆動は割と今腰まで俺が浸ってる気がするモチベだけど、単にお金稼ぐだけならエンジニアは効率のいいわけでもない(短期的に見ると)と思っているので、あまりエンジニアでこれをモチベにするのは微妙かと思いつつ。

 

ちなみに、成長駆動は本質的に不安駆動だと思っている。そしてエンジニアは、「手に職が付いて安心!」と思い込めやすいので、不安駆動と相性がいいなと思う。

 

最近の若い人が勉強熱心、成長熱心なのも、ひとえに将来に対する不安が大きいからじゃないかなと思ったり。

 

今日はこのへんで。