キャリアについて考える
仕事でキャリアパスについて尋ねられたので考える時間をとってみた。
調べてみてわかったのが、他人のキャリアパスはほとんど参考にならない。
ネットではほとんどサクセスストーリーみたいな感じで紹介されているものが多いし、私がやりたいものと合致していなかった。
これまで
ざっくりとキャリア年表みたいなものを作った。
新卒時代の記憶とかはほとんど残っていない。
転換期となったのは3年目あたりだろうか。
多くの人が3年で辞めていく中、とてもいいプロジェクトにアサインされたのでそのまま5年目エンジニアとして前職でお世話になっていた。
プロダクト的にはとてもレガシーなもので同僚は私に同情していたが住めば都というかいざ働いてみると多くのことを学べた。
初めてリーダー経験を詰めたというのも大きいかもしれない。
結局前職で学べたいいことって?
藪蛇なタスクが大量にあった。
日々多くのタスクをこなしていくわけだが、「これは間違いなく地雷だろう」というタスクがいくつもあった。
考慮すべきことが多い、そもそもどうやってそのプロダクトが動いているのかわからない、テストコードはない。といった具合である。
ひたすらsshでサーバに入ってpsコマンドを叩く...みたいなこともやっていた。
リバースエンジニアリングという言葉を用いていいのかわからないが、まぁそんな感じ。
突けば間違いなく厄介なことになるのだが、職務上やらなければならない。
最初はいやいやな感じだったのが、以外と楽しい。
誰もやりたくないのは、Toilなものを除いて「誰もやれないことが多い」。
誰もやれないタスクをやることで、課題へのアプローチ方法や技術力が向上していったのだと思う。
技術力が高い人に囲まれていた
お客様のエンジニアがかなりレベルが高く学びが多かった。
エンジニアも細分化され、専門領域を持つ人が多く在籍していて日々成長ができた。
勿論、自社のメンバーやパートナーで構成されるチームメンバーも技術力が高い人が多く、ハードだけど学べることが多い、楽しい日々だった。
ビジネスサイドとの関係性
リーダーなのでお客様の企画の方とお話をする機会が多かった。
こういう機能を作りたい、ユーザーの回遊率を上げるためには、という施策にガンガン首を突っ込んでいけた。
GoogleAnalyticsを見てこういった改善方法はどうか、と提案したり初めての体験をできた。
成功したときは感謝され、失敗したときは一緒に悩む。
ビジネスサイドに関われるというおもしろさを感じることができた貴重な経験だった。
その反面で、リーダーという職務上で工数管理をしなきゃいけないのが苦痛だった。
でこれからは?
前職でアサインされていたプロジェクトにおける問題を解決する手段を求めていたらSREに行き着いた。
- 環境構築
- CI/CDパイプラインの構築
- アラートの設定
- 脆弱性対応
- Toilの削減
などなど列挙したらキリがないが、DevOpsやSREに行き着くのは理解できる。
これらを踏まえると、私がやりたいのは「プロダクトを開発する」ことではなく、「安全・健全にプロダクトを開発できる仕組みづくり」がしたいんじゃないかなぁ。
ここに前職でおもしろさを感じていたビジネスサイドとの関係性やマネタイズも加えてみよう。
「安全・健全にプロダクトを開発できる仕組みづくり」を行って「素早くユーザーに価値を届けプロダクトを成長させたい」
プロダクトは使われなければなくなる。必死になってコードを書いたとしても価値を創出できなければ事業としてはクローズせざるを得ない。
だからビジネスは無視できない。事業あってのプロダクト、プロダクトあってのインフラ。
詰めが甘いが私はSREとしてのキャリアパス、というかビジョンが少しまとまったような気がする。
読書のススメ方
Notionを使って読書メモを残しておくようにした。
というのも転職をしてからというものインプットが多く、技術書も大量に読むことになったので読書メモをどう管理するか確立させたかった。
前はMacのNoteだったり、Typoraだったり、Dynalistだったり、Atomだったり...とうろうろとしていたけど、Notionでやっと落ち着きそう。
メリットととしては
みたいな感じ。
まずはNotion Web Clipperを使って読みたい本をAmazonで見つけたらギャラリーにためておく。
読み始めたらプロパティをいじって進捗管理をする。
プロパティを選択しているとフィルターをかけられるので読了したものや、優先度の高いものを表示できるようになるので良い
あとは章ごと読書メモを追記していくだけ。
読書会の準備も同じくNotionに移行していく予定
Firefoxのシェア低下について
TwitterのトレンドにFirefoxがあがっていたのでちょこっと調べてみたメモ。
Firefoxの現状
Firefoxのシェアが6%まで低下していて、続々とWebサービスがFirefoxのサポート打ち切りを発表しているらしい。
以下は、statcounter社による2022年2月時点の全世界的なブラウザのシェア。
Firefoxは4.21%まで下がり対するChromeは62.78%のシェアを擁する。
過去3年間ほど振り返っても同じ傾向であった。
公式統計によると、2018年末のアクティブな(月間)ユーザーの報告数は約2億4400万人でした。
そして、2021年第2四半期末には1億9,800万に減少したようです。
つまり、ユーザーベースはなんと4600万人も減少します。
Chrome1強時代に考えること
「Internet for people, not profit」を目指す非営利団体のMozillaがシェアを落としてしまうというざっくりとした悲しみがある。
Microsoft EgdeもChromiumベースなので他の対抗馬はSafariぐらいになるのだろうか。
実際にはMozilla Corporationは課税対象で親会社のMozilla Foundationが非営利団体だったりするんけど、全ての利益はMozillaプロジェクトに還元されているのでこの認識であっているはず。
非営利団体としてGoogleとは違った目線・立場で仕様を策定していたり、セキュアなブラウザとしてかなり頑張っていたイメージがある。
たまにMozilla's Positionsを見てTC39のプロポーザルに対してMozillaはどんな意見を持っているのか見るのが好きだった。
特に「harmful」のラベルがついたものはよく読んでいる。
といっても個人的にはChromeを使っているし「何を言っているんだお前は」状態。
でも選択肢があり続けるのはよいことで、Webはもっとカオスであってほしいという個人的な願いを持っているのでこれから一所不住に色んなブラウザを使ってみようかと思う。
前述したTC39の件もあるのでこれからもMozillaには頑張ってほしいと思ってます。
https://donate.mozilla.org/ja/
少額ですが寄付してみました。
Terraform Cloud使ってみた
Terraform cloudを利用する機会がでてきたので調べる。
今回は簡単な使い方だけ。
初回実行用に公式がsampleを用意しています。
適当に使ってみるだけであれば↓でOrganizationとWorkspaceの作成をして動きをみることができるようになっています。
$ terraform login $ git clone https://github.com/hashicorp/tfc-getting-started.git $ cd tfc-getting-started && ./scripts/setup.sh
事前準備
今回はS3 bucketを作成するだけにしました。
terraform { required_providers { aws = "~> 3.74" } }
でversionを指定しているのは、S3 bucket resourceが大幅に変更が入ったためです。
うーん、個人で運用しているレベルなのでそこまで問題ないんですが、業務レベルで使用していると結構たいへんそうな
— mutao (@mutao_net) February 13, 2022
Workspaceの作成
3つの選択肢がありますが、今回はGitと連携して作成します。
「Version controle workflow」を選択。
対象のRepositoryを選択。これだけで完了です。
AWSのtokenを設定
variableで参照できるようにするため環境変数を設定します。
このとき「SENSITIVE」にしておくと設定したTokenが参照できなくなるため設定しておきました。
main(master)ブランチにmergeされると terraform plan が実行されます。
実行計画を確認したら「Confirm Plan」で terraform apply が実行されて完了。
実際にS3 bucketが作成されていることが確認できたら完了です
「Setting」から自動でapplyまでしてくれるようにも設定可能です。
退職エントリ
本日をもって2017年に新卒入社し、約5年ほど勤務した都内の某SIerを退職しました。
振り返り
入社の経緯
とある文系大学で全くプログラミングと関わりのない大学生活を送りながら就職活動をして突如エンジニアになることに決めました。
- エンジニアってかっこいい!
- 自分でなんでも作れる人間になりたい!
- スーツ着なくてもいい!
最初はこんなレベルでした。反省しかないです。
今になると私にとってエンジニアは天職だなと思います。
新卒入社からずっといたので比較対象はないですが。
日々見についていく技術、達成感、どこに手を出しても新しい世界が見えてくるワクワク感。
形容し難いほど魅力的な仕事です。
入社後
3ヶ月の研修期間に入ります。もちろんプログラミングとは縁がなかった私は酷いありさまでした。
研修時代のどうしようもない私をなんとかしようとあくせくしていた講師陣の方々には感謝の念しかありません。
入社後Javaの研修を受けてからPHPメインのプロジェクトにアサインされました。
「Javaじゃないじゃん。。。」と肩を落としていた講師の方々が今でも目に浮かびます。
案の定どうしようもない結果しか残せない私は社内の先輩エンジニアの方に相談し技術書を大量に購入して勉強してました。
勉強が嫌で仕事を辞めようと思うことはなかったです。むしろ成果を残せない現状をどうにかしたい一心でした。
ちょっとマシなエンジニアへ
亀の歩みで新卒時代とは違って「ちょっとマシ」なエンジニアへとなります。
それから案件をいくつかの案件を周り、某Web企業のエンジニアとして今まで3年近くお世話になってました。
リーダーをやったり、インフラエンジニアっぽいことをしたり。はたまたSEOについて勉強してみたり。
マネジメントの経験は初めてでこれもいい経験になりました。
- チームメンバーがパフォーマンスを発揮するためには
- 心理的安全性
- HRT
- メンバーのスキルセットを加味した上でのタスク割り振り
- シンプルな進捗報告の行い方
- 顧客折衝
- 仕事を得る(生み出す)ということ
当時同じチームだった@ryuichi_1208 さんが退職されてからはもろにインフラエンジニアでした。
@ryuichi_1208 さんは勉強熱心な方で、転職してからもどんどんとつよつよエンジニアになっている模様です。
お客様にもプロジェクトメンバーにもレベルが高い方が多く、モチベーションに一気に火が付きました。
反面、「こんなすごい人たちがたくさんいるんだ」という焦りにもつながりました。
そうして日々を過ごしていくうちに、使いたい技術が増え、やりたいことも明確になっていって転職に至りました。
ざっくり言えばインフラ領域を極めていきたいという感じです。
退職
有給消化
してないです。重要なのはできないのではなく望んでいないだけです。
仕事は好きですし、まとまった休みがあっても結局技術書を読むか、コード書いているだけです。
それなら土日と祝日、定時後でなんとかなりますし、退職で迷惑をかけたくなかっただけです。
立つ鳥後を濁さず。でできることは全てやろうと思いました。あと中途半端が嫌いです。
挨拶
退職が決まってからお世話になった色んな方に挨拶まわりやメールをしました。
色んな人から返信をいただきました。
飲み会での失敗談から仕事でのお礼まで。全て嬉しかったです。
お客様とコーヒーを飲みながらちょっとお話したりしたのでおセンチな気分です。
会社のGoogleアカウントからログアウトできずにチャットを読んで思い出にふけっています。
今後
次はSREとして働きます。
退職エントリを書いている今でも「次の会社で足手まといにならないだろうか」という不安でいっぱいです。
継続は力なりを胸に頑張り少しでも早くパフォーマンスを発揮できるようになりたいです。
願わくば自分の優位性みたいなのを持てるといいかなと思ってます。
〜〜ならmutaoだよね。みたいな人間として認知されたいです。
Dynalist駆動開発
Dynalist
MarkdownエディタのTyporaの代わりに出会ったアウトライナー
Githubっぽい見た目だったりで凄い重宝していたんですが、有料化してしまったので乗り換えました。
読書メモだったり、開発前のちょっとしたメモ書きをするのに使ってます。
ショートカットに慣れるまではちょっと時間がかかりそう。
あとは無料化のままだとそのまま画像をコピペすることはできないのでGyazoとかを使用してリンクを作らなきゃいけないのがちょっと残念。
このまま使うならProにします。
Dynalistでざっくり書いたものです。
自分専用の新聞的なもの作れたらいいなぁと思ったりしてました。
慣れるためなのでちょっとしたものをまずは書いてみて、コーディング中に気づいたメモをどういったフォーマットで書くか試行錯誤してみます。
完成したもの。
無理にAWS要素を入れてみたけど、これくらいだったら自宅サーバで動かす感じで良かったなぁと思った。
API Gatewayを使う必要は流石になかったので、Lambdaの定期実行にしました。
個人開発ならAPI Gatewayの出番はあんまりないかもしれない。もっと練って見よう。
今度はもっとAWSの要素を絡めたもの作りたいです。
使ってみた感想
勉強になったOSS
ただGitHubでスターをつけているだけだとなんとも実りがない気がしたので、メモかつ何がどう参考になったかというのをまとめておく。
全部に言えることは「実装がきれい」。
Go
fast-service
エキスパートたちのGo言語の「1.3 インターネット回線のスピードテスト」で知った。
- sync/atomiパッケージを使用した非同期処理の実装
- Goroutine/Channel型の実装
を学ぶには実践的でとてもよかった。
Goを学びたての時に読むと理解が深まると思う。
action-slack-notify
GitHubActionでslackに通知したいなと思ったときに使ったもの。
usesで定義する中身を知りたいなと思って見た。
中身はすごくシンプルかつやっぱり読みやすい。
Goの標準パッケージしか使ってないところを見ると流石と思う。
os.Getenvで各パラメータを参照しているところを見ると、実際どうなっているのかわかりやすいと思う。
こっちで指定したSlackのWebhookURLはコンテナの中で環境変数として設定されてるんだな。とか。
公式documentをななめ読みしたり、英語全然できないタイプにはもってこいのサンプル。
slackbot作りたい人も読むと参考になると思う。
私の中ではプログラミング言語はユニバーサル言語。
go-setlock
cronの多重起動を防ぎたいけど、CentOS7/8だしなぁと思っていたときに勧めてもらった。
daemontools-encore の setlock.c を見比べたりしてみると面白いと思う。
Go言語を読んでいたと思ったらいつのまにかC言語を読んでいたという出会いに感謝。
Perl
MySQLのスロークエリを解析したいときに使う mysqldumpslow。
「お世話になってます。あなたPerlだったのね。」と感慨深く?なった。
Perlで何かしら実装したことがある人は読めると思う。
MySQLに興味を持ち始めているお年頃なのでPerlを触る機会があってよかったと再認識できる。
Perlアレルギーの人もぜひ一度触ってもらいたい。何にしろ食わず嫌いはよくない。