💌
Open Job Letter v2
検索
Notionを使ってみる
💌💌

Open Job Letter v2

オーナー
azu
有効期限
2024年1月17日まで有効
タグ
Hiring
さらに1件のプロパティ
これは求職記事(Hire Meな記事)です。 無関係な方はスルーしてください。
azu(アイコン)
公開者: azu
GitHub: @azu
X(Twitter): @azu_re
公開日: 2023-12-19
アーカイブ予定日: 2024-01-18

Open Job Letterの目的

5年前にOpen Job Letterという求職記事を公開しました。 前回書いたOpen Job Letterは、当時の状況や転職の目的を振り返るのに役立ちました。
今回、転職活動するにあたり、Open Job Letter v2を書くことにしました。 Publicに公開しているのは、公開を前提に書くことで公平性を持って書きやすいためです。 また、公開することに意義を感じたからです。
このOpen Job Letter v2では、次のことを目的にしています。
前回のOpen Job Letter(2018)の振り返りをする
今回の転職活動をする理由を整理する
提供できる価値を整理する

プロフィール

ウェブ上ではazuという名前で活動しています。

仕事的な活動

仕事では、プロダクトを開発しているチームに入り、ウェブサービスのフロントエンドからバックエンドまでの開発をしています。プロダクトは使われてこそ意味があると思っているので、プロダクトの開発のあらゆることに関わる形になります。今でいうProduct Engineersというのが近い形だと思います。
プロダクトのコードそのものだけではなく、CI/CD、開発環境にも常に興味を持って改善すること多いです。これは、開発体験の改善が最終的にはプロダクトの改善につながると信じているからです。
普段は特定のチームに入りプロダクトの開発をしていますが、セキュリティチームにもずっと関わっています。最初はプロダクトのセキュリティをメインに扱うチームがなかったため、セキュリティチームの立ち上げから参加し、プロダクトに関するセキュリティのことを一通りやっています。
セキュリティチームを立ち上げた時はセキュリティを仕事としてやったことはなかったですが、勉強しながら、カルチャーに合わせてボトムアップでセキュリティ組織を立ち上げました。セキュリティの啓蒙活動、社内での脆弱性診断、脆弱性の修正やレビュー、機密情報の漏洩や不正アクセスのモニタリングの設定などセキュリティの底上げに繋がることをしていました。
もっと詳しくは、フォーム から希望すれば、具体的にどういうことをやっていたかの資料をまとめたNotionページへのアクセス権を付与できるので、お知らせください。
次のようなプロジェクト単位でやっていたことをまとめてあります、
Flash to HTML5
SC22 ECMAScript Adhoc委員会
リアルタイム性が必要なサービスのパフォーマンス改善と安定性向上
セキュリティチームの立ち上げ
社内業務フローのセルフサーブ化
インシデントとジョブの安定化、冪等性、モニタリング

個人的な活動

個人では、JavaScript PrimerJavaScript Promiseの本というJavaScriptの入門書を書いたりしています。また、JSer.infoというJavaScriptの情報サイトの運用、textlintという自然言語の校正補助ツールや機密情報を検出できるSecretlint などの開発をしています。
それぞれどういう目的や理由でやっているのかは次の記事を参照して見てください。
セキュリティチームをやっているときに機密情報を検知と管理ができるちょうどいいものがなかったので作りました
オープンソースは幅広くやっているのでActivityを見るのがわかりやすいです。他の個人的な活動は、次を参照してください。
ブログ: Web Scratch

前回のOpen Job Letterの振り返り

前回のOpen Job Letter(2018)は直接転職につながったわけではありませんが、スナップショットとして当時の考えをまとめておくのは、振り返るのに便利だと思いました。 Open Job LetterとしてPublicに公開しているのは、公開することを前提にした場合、公平性を持って書きやすいからです。
前回のOpen Job Letter(2018)では、次のような点に興味を持って転職活動していました。 実際にB2B SaaSをしている企業で働いて、転職前後の興味の結果をまとめています。
B2B
拡大期の企業
良いデザイン
課題があるか
裁量
プライバシー
リモートワーク
転職前
B2Bは未経験
シリーズAやIPO後は経験あったけど、その間は未経験
B2BのUI/UXがよくないことが多いのはなぜ?という疑問があった
課題に対してどのようなテクノロジーで解決しようとしているか
裁量の仕組み化されているか
プライバシー大事
リモートワークは未経験
転職後(今)
B2B SaaSにおけるプロダクトを開発を経験。 SaaSにおけるメトリクスなどもなんとなくはわかる
人もプロダクトも増えていくのを経験
B2BにおいてもB2Cと同じようにデザインが重要になっていると実感した
これは今も同じことに興味を持ってる
これは、他の人が裁量がなくて動けない状況が嫌なことがわかった
プライバシー大事
リモートワークなしでは働けなくなった
B2B
それまではB2Cばかりだったので、B2BとB2Cとの開発の違いなども体感できた
たとえば、B2Bはクライアント企業との距離が近いので、クライアントにヒアリングしながらプロダクトを改善していくというのがかなりしやすいという特徴があった
また、サービスだけではなく市場や他の会社の状況なども意識的にみるようになった
良いデザイン
転職前は、ある課題を解決するためには機能だけではなくデザイン(UI、行動、プライバシー、セキュリティなどいろいろ意味のデザイン)も大切と考えていて、B2Bサービスだと何で体験が悪いものが多いんだろという疑問があった
これは、現代的なB2Bサービスだと良いデザインがないと競争力が保てなくなるというのが実感できた
機能的な比較で選ぶクライアントもいるが、ある程度機能が揃ってくるとそこでの差別化が難しくなる
SaaSでは今ある機能で比較してもしょうがない部分があり、将来的に増える可能性もある
そうなってくると、機能的なものじゃない部分での差別化が必要になってくる
この場合には、機能そのものには強みが相対的に弱くなってきて、デザインの強みが出てくる
また、B2Bだと難しい業務フローをUIに落とす必要があり、そのままUIが複雑だったらおかしいので、それをどう落とし込むかというデザインも重要であるということが理解できた
裁量
転職前は、裁量をどのように仕組み化しているかというところに興味があった
自由な取り組み、発言などを安全に行える環境をどのように作っているかという点に興味があった
これは、自分自身に裁量が欲しいとかそういうわけではなく、自分以外の人が自由に動けてるかどうかを気にしていることがわかった
自分は勝手に動き回るタイプなので、あまり気にしていないが、周りが動きにくそうだと問題に感じてしまう
プライバシー
セキュリティチームでLegalの人とよく話すようになって、法律を専門にしてる人でも完全な状態というわけでもないというのが感覚的にわかってきた
法律に全ての答えが書かれてるわけではないということ
プライバシーは、結構世の中の動きと連動する場面があり、今後も大事にしていきたいと思った
リモートワーク
コロナで強制的にリモートが通常の状態になった
けど、もうリモートなしでは働くの難しい
オフィスに行くのはコミュニケーションをしに行くときぐらいで、他はリモートの方が個人的には相性がよかった
簡単に振り返ると、興味を持っていた点は体験として理解できて、考えがよりまとまった感じがします。この考えがまとまったと感じた点も今回の転職活動を開始した理由となっています。

転職活動の目的

今回の転職活動を開始した理由は、前回の転職活動で興味を持った点の目標が達成し、ひと段落したことがきっかけです。 また、市場の変化が起きていることも考えるきっかけとなっています。
次のOpenCloud 2023のレポートがわかりやすいですが、上場企業も非上場企業どちらも、High-Burn / High-Growth から Low-Burn / High-Growth への転換を図っているところが増えていて、今までとは戦い方が変わってきているという感覚があります。(赤字でも成長率が良ければOKから、効率よく運営されていて成長率も良いところが良いという変化)
戦い方が変わると、今まで見たことないやり方をする企業なども出てくるということなので、そのプロセスに興味があります。
Forecasting & Scenario Planning | Sequoia Capitalでも同じような話として、マーケットがリスクを許容できない状態へと変化しているという話が紹介されています。
リスクが許容できる時は夢のある話を信じるが、リスクが許容できないときは財務情報を見るようになるという現実的な話が紹介されています。
● When risk is on, people are willing to believe in a story or in a dream. ● When risk is off, people want to see financials
この変化の背景は、次の記事なども参考になると思います。
また、日本では政府の規制緩和やスタートアップ支援の動きも見られてきて、それに合わせて新しいスタートアップができたり、テクノロジーを使う企業なども変化してきています。(変化自体は常にしているけど、変化が目に見えるようになったというのが感覚に近い)
変化することが大事だと思っているので、このタイミングで転職活動をしてみようと思ってこのOpen Job Letterを書いています。どうしても目にみえる変化は徐々に起きることが多いので、環境をガラッと変えてみる方が面白いかなと思って転職することにしました。
辞めてから転職活動をしているのは、働きながら転職活動するのは大変だと思ったためです。

やりたいこと

やりたいことの明確な軸はありません。 ベースとしてソフトウェアなどの技術的なことに興味がありますが、色々なことに興味を持って調べてやるタイプです。
以前のOpen Job Letterでも書いていましたが、明確な目標やなりたい状態というような一本線の軸となるものはありません。(強いてあげるなら「便利にする、便利になる」)
一方で、興味があることはいろいろ点として存在し、その点をつなげて面として捉えていくと大まかな方向性が見えるようなものだと思います。
軸と点: Source、考え方の元ネタはリサーチのはじめかた
自分の場合は、この点(興味)が色々なところにあるのでかなり捉えにくいとは思います(自分でもわかりにくいです)。この点を結んだ面の内側や新しい点には興味があるのでトライしてみるといった動き方をします。そのため、点(興味)が増えれば、面が勝手に広がったりします。
前置きが長くなりましたが、興味の範囲は広くなりがちで、きっかけがあればやってみようとなるタイプです。しかし、それだと困るので、いくつかパターンを書いてみました。
色々な人と話していて、自分が価値を提供できそうだったり興味がありそうなパターンがあるような気がしたので書いています。 ここに載っていないケースは、おそらく自分が気づいてないだけだったり、書いてないだけなので、向いていそうなことがあったら フォーム からお知らせください。
ターゲット: 想定している企業
ターゲットの需要: 想定している企業が求めているニーズ(想像です)
私が提供できる価値: @azu が企業へ提供できそうな価値、強み
私が期待すること(見返り): @azu が企業に期待する見返り
詳細は、ターゲット をクリックしてページを開くと書いてあります。
テーブルビュー
フィルター
並べ替え
ターゲット
ターゲットの需要
私が提供できる価値
私が期待すること(見返り)
- 使われるプロダクトを作ること - 成長段階で成長を妨げるものが少ない状況になっていること
- プロダクトがなぜ必要とされているかを理解して行動すること - プロダクトの成長タイミングで成長できるようにすること
- プロダクトを通しての規制改革のアプローチや実際の手法を学べること - やり通した時の達成感があること - リスクに見合うSO
- プロダクトの成長を妨げないような環境を作ること - プロダクトが抱える負債を解消すること - プロダクトの難しい課題解決すること
- 技術的/セキュリティなどのベースラインを上げていくこと - 段階的に負債を解消しながら、新しい技術を取り込めるようにすること - 各自が行動できるように、真似しやすいアプローチで課題を解決すること
- プロダクトの面白さ - 正当な報酬
- プロダクトチーム間でサイロ化した問題が発生しないようにしたい - プロダクトを開発する際の認知負荷を下げたい - プロダクト間で依存関係が発生していて、それが開発をブロックする状態を無くしたい
- 特定のチームに入り問題を解決しながら、他のチームでも利用できるように展開すること - 共通で無駄に手続き的になっている部分を見つけ、自動化や仕組み化すること
- 課題の多様性 - 正当な報酬
カウント3
💡
この書き方の元ネタは、ストラテジック・キャリアです。 PVP(Personal Value Proposition)をベースにして、自分が提供できそうな価値を並べています。

企業を見ているポイント

基本的には、以前のOpen Job Letter(2018)と変わってはいない気はします。
事業
TAMなどの市場規模だったり、どういうプロダクトをやっているか
B2Bならどういうクライアント(SMBやエンタープライズなのかとか)が中心に利用しているかをロゴや事例を見たりしながらどういう戦略をとっていそうなのを見たりします
市場の競合的にはどういう企業がいるのかや、意識してる競合については面談とかで聞くことが多いです
チーム
これはエンジニアのチームだけではなく、ビジネスのチームとの関係性も見ています
組織図だけ見てもよくわからないので、どういう風な関わり方をしてるかを聞いたりしています
フェーズによって組織構造は異なるのが正しいので、どちらかという気にしているのは組織構造を超えたダイナミックさがあるかどうか
あとはデザイナーとの関わり方をどうしているかなど
課題
面白そうな課題があるかどうか、面白そうな課題が増えそうな場所かどうか
プロダクト的な課題、技術的な課題、組織的な課題
課題を解くことに積極的な姿勢を持っているか、どういうプロセスを取れるか
プロセスは、特定のフレームワーク(スクラムとか)を導入してるという話ではなく、なぜそこにその課題があって、なぜその解決方法で解決できるのかというのを考えて実行するのが好き
同じように見える課題も、実際にはコンテキストなどが異なれば違う原因だったりする。そのため、課題をカテゴライズするんじゃなくて、課題にも多様な状態があることを認識できるかで解き方も変わってくるはず
複数のプロダクトを持つ企業 などでも挙げていますが、色々な課題があってそれに対してどうアプローチするかを考えて行動するのが好きです
事業や会社的に新しいタイプの課題に遭遇できそうか、そのような課題に対してどういう姿勢を持っているかを気にしています
技術に関してだと、利用してる技術自体は、外から調べると大体わかることは多いので、どういう技術的な課題があるかを聞くことが多いです
文化
文化そのものは、現在の行動によって変化していくものなので、直接的にはそこまでカルチャーマッチしてるかは見ていません(短期間だとわからないのもある)
一方で、評価制度や権限移譲の仕組み、横断的な関心ごとの解き方などに文化が出ることが多いので、ここを聞いています
カルチャーマッチではなくバリューマッチという話もあったりする
ただ、バリューは明文化されてることが多いため、書かれている言葉をそのまま使うケースが多いです
そのため、その言葉が言葉通り実践されてるかを知るのが難しいなーと思ってます

スキルマップ

大まかなスキルマップです。思いついたものを書いてるだけなので、抜け漏れはあると思います。 できない ↔できる 、嫌い ↔ 好きの4象限でまとめています。それぞれの値は主観的な相対値です。
細かく見たい場合は、スキルマップのギャラリービュー(クリックで開く) を参照してください
Mermaid
プレビュー
コピー
Ⅰ:好きかつ得意Ⅲ:好きではないが得意Ⅳ:好きでも得意でもないⅡ:好きだができないFinanceLegalマネージメントUIデザインZigRustGolangTerraformiOSアプリ開発AWSKubernetesBigQueryGCPDDDOkta脆弱性診断CSSドキュメントライティングBuild Tool/BundlerDatadogReactVueライブラリの作成/利用CDセキュリティBrowserCIHTMLTypeScriptGitHubmonorepoECMAScriptNode.jsJavaScriptオープンソース嫌い好きできないできるスキルマトリクス
スキルマップのギャラリービュー(クリックで開く)
スキルマップのテーブルビュー

⬆️ やっていて苦ではないこと

しらべること
何に対してもちゃんと調べるようにしています
偏りがないかなども意識するため、本を読む時も類似する書籍を同時に読み比べたりします
未知のことに対しても、調べながら進めることでモチベーションを作りながら進めることが多いと感じます
具体例
セキュリティチームの立ち上げ時にボトムアップでのセキュリティ組織の参考事例が見つからないことが多く、Learning O’Reillyで色々な本を調べながら進めていました
コードを読むこと
現代の開発では何かしらのライブラリやフレームワークを利用しているため、ライブラリ側の問題があった場合に、そのライブラリの実装まで調べて修正に取り組む際に役立ます
具体例
GCPのSpannerを使ったサービスで、SpannerのSession作成に失敗した場合にSession Poolからの破棄と再接続が自動的にリトライされるのかをnodejs-spannerのコードを調査して対応した
Chromeの特定のバージョンでUIを操作するフリーズする現象が発生するようになり、原因を調べると を使ったプロダクトで、このUIライブラリでは特定のWAI-ARIAの使い方が間違っていた。Firefoxなどでも昔同様のフリーズする事象があるのを見つけて、ライブラリのコードを読んで無理やりパッチを当てることで問題を回避した
レビューをすること
仕事でもオープンソースでかなりの量のコードレビューをしている気がします
レビュー待ちはブロッカーになりやすいので、できるだけ早く対応することを意識しています
これは すばやく反応すること と同じ理由もあります
オープンソースだと時差の関係で間が長くなりやすいので、完璧を求めすぎない、スタイルの問題はツールに任せる、重要ではないことは重要ではないということをコメントに入れるなどを意識しています
レビューの原則としてはGoogle Engineering Practices Documentationで公開されている次の原則が好きです
In general, reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn’t perfect. — https://google.github.io/eng-practices/review/reviewer/standard.html
プロダクトの改善
途中から開発チームに入ることが多いので、すでにあるプロダクトの改善や安定化には慣れています
基本的に全く同じ問題はない(チームが違う)ので、そのチームではどういうアプローチが上手く動くかを考えます
仕組みをつくること
仕組みを作るときには既存の動き方にあってるかどうかを意識して作ります
仕組みだけ持ってきても、うまく回らない場合があるので、実際に使う人がどう思うかを聞きながら作ることが多いです
再現性を作ること
ドキュメント/メモは意識して書くようにして、他の人が真似できるようにしています
複雑な組み合わせの問題が起きた時は、それを整理するドキュメントやどういう目的で書いているかを残しています
これによって他の人が同じような問題にぶつかったときに、真似しやすいやり方として参照されることが多いです
社内のドキュメントだけではなく、社外にもブログやスライドとして公開することが多い
所属企業は基本的に公開しないタイプなので、名前を出さないでブログを書いたりする
すばやく反応すること
仕事、オープンソースどちらにおいても意見や質問に対してすばやく反応するようにしています
これは短時間で動くものもらった場合は、その後の流れがスムーズ(より具体的)になるという経験的な結果があるからきています
短時間で話を返すだけだったり、時間が経ってから動くものを返した場合は、結果的に無駄になる時間が増えるという印象からきている行動です
似たようなテーマで書いたスライドです
ざっくりとまとめると、開発と支援を行ったり来たりしながら動くことが得意だと思います。
Enabling と Develop を行き来する図: Source

⬇️ 苦手なこと

停滞すること
変化することは重要だと思っているので、停滞しているという感覚が苦手です
コンフォートゾーンに長期間いるとこの感覚が強くなってしまうので、ある種強制的に環境を変えることもこのOpen Job Letterの目的の一つです
実際に停滞してるかはその時点でわかることの方が少ないので、ある種の見切り発車は必要ですが、見積もってみて「今ではない」という明確な理由がなければトライしてみることにしています
プライバシーやセキュリティを尊重しない行動
利用規約やプライバシーポリシーはちゃんと読んでから同意するタイプです
完璧なルールはないので、納得できるかが重要だと考えています
ヒューマンマネージメント
マネージメント でも書いていますが、人をマネージメントするスキルがないです
コミュニケーションをとって進めることはかなり重要だと考えています。コミュニケーションをとりタスクを任せるとか方針を一緒に考えるとかはよくあることですが、それをマネージャーというロールでやろうと思ったことがないです
どちらかというとやってることはIndividual Contributorです

Vision/Mission

よくみるビジョン、ミッション的に書いたもの
便利にする/便利になる: Source
Vision
便利にする/便利になる
便利なものが好きなので、自分がより便利と感じものを作ったり、他の人が便利と思えるものを作りたいです
便利を追求するには試行錯誤が大事なので、そのときには砂場(sandbox)をつかって遊ぶことを意識してます
Mission
自分や他の人が上手くいくように便利な方法を使って助ける
興味があることを追求して、より便利にできる方法を見つける

希望する雇用形態

正社員

希望する業種・職種

業種: 特になし
職種: プログラマ/Individual Contributor
自社開発、自社サービス

希望しない業種

業種: ゲーム、広告、アダルト
受託開発

希望する勤務地

東京周辺 または リモート

希望する年収

1500万円 〜
目安としての値です
現実的には会社によって異なると思うので、@azuが提供できる価値 も参照してください

FAQ

Q. 希望する年収の下限が前回から見てかなり上がっていますが、それにはなにか根拠があるのでしょうか?

フォーム

興味がありましたら、次のフォームから送ってみてください!
推薦: こういう会社あるよー というのを気軽に送れます
Open Job Letterは、知らなかった会社に気付くタイミングでもあるので気軽にどうぞ
応募: 応募できます
かなり考え込んでしまうので、できるだけ情報があると嬉しいです
急いでないので、ゆっくりで問題ないです
色々調べてから、入力されたメールアドレス(会社のメアド) OR X(Twitter)のDMなどへ返事をします
メールは [azu] Open Job Letterについて という感じのタイトルで返事をすると思います
ただし、全員に返事を返せるかはわかりません(1-2週間ぐらいを目安にしてください)
特に進展がなさそうなものに対しては、返事は出せないのでご了承ください
メールアドレスは、返事やNotionのレジュメページをお知らせするのに利用します
メール以外で連絡を取ったほうがいい場合は、コメントに書いておいてください
コメントだけ: コメントのみを送れます
Open Job Letterへの感想や意見などコメント待ってます!
このフォーム以外からやりたい場合は、転職ドラフトにも登録してあるので探してみてください!(わからなかったら聞いてください)
読み込み中...
応募フォーム
フォームが表示されない場合は https://tally.so/r/3X4kaO を開いてください。
テーブルビュー