転職で納得するための逆質問

2022/04/30にエンジニアと人生コミュニティのLT会で発表した内容です。
コミュニティの概要はこちら
https://community.camp-fire.jp/projects/view/280040

Transcript

1. 転職で納得するための逆 質問 2022/04/30 エンジニアと人生 LT会 Inomata a.k.a matty
2. 自己紹介 猪股 光 a.k.a matty (26) ポスタス株式会社 → 6月から株式会社グラファー 
 一般社団法人 Code for Japan NPTech team 
 生息地 平日：家、ANYTIME FITNESS
 土日：家、サバゲーフィールド、映画館、本屋 
 成分表 肩書き • IT系変なTシャツコレクター
 • 超特攻型サバゲーマー（すぐ死ぬ）
 • MuscleDrivenDeveloper etc...
 好きな技術 @ino_aka_matty
 @10inoino
 https://www.facebook.com/10inoino 

3. 今回の転職に至るまで • 2020年4月に一度転職を試みる
 ◦ 選考は進めたものの自分自身の転職活動に納得感が無い
 ◦ 現職に相談したら、いい感じに待遇が上がった
 
 • 2021年1月から転職活動再開
 ◦ 前回の転職活動の反省を活かそうと試行錯誤

4. コードを書く

5. レビューをもらう
 レビューｵﾈｼｬｽ なんでこういう書き方を選 んだの？
6. なんとなく答える
 レビューｵﾈｼｬｽ なんでこういう書き方を選 んだの？ なんとなくこっちのほうが好 きだったんで
7. 怒られる
 レビューｵﾈｼｬｽ なんでこういう書き方を選 んだの？ なんとなくこっちのほうが好 きだったんで Fxxk ※フィクションです

8. 指標を用いて答える
 レビューｵﾈｼｬｽ なんでこういう書き方を選 んだの？ 可読性が～ テスト容易性が～ ドメイン的に～
9. いい感じ
 レビューｵﾈｼｬｽ なんでこういう書き方を選 んだの？ 可読性が～ テスト容易性が～ ドメイン的に～ よかろう
10. レビューもいい感じ
 レビューｵﾈｼｬｽ なんでこういう書き方を選 んだの？ 可読性が～ テスト容易性が～ ドメイン的に～ 可読性を考えると こうじゃない？
11. 転職をする

12. 自問自答
 この会社にしようかな なんでそこがいいの？ もう一人のぼく

13. なんとなく答える
 この会社にしようかな なんでそこがいいの？ なんとなくいい感じなので もう一人のぼく

14. 納得いかない
 この会社にしようかな なんでそこがいいの？ なんとなくいい感じなので ダメだろ ※ノンフィクションです
 もう一人のぼく

15. 転職で納得するための逆 質問 2022/04/30 エンジニアと人生 LT会 Inomata a.k.a matty
16. 転職で(自分が)納得するための 逆質問 2022/04/30 エンジニアと人生 LT会 Inomata a.k.a matty
17. 注意点 • 猪股が「転職活動はこんな感じで考えたよ！」というログです。
 ◦ 勿論転職活動における銀の弾丸では無いので悪しからず。
 ◦ 考え方の1つとして、今後の転職活動の役に立てば幸いです。
 
 • 今回の転職活動では、自社プロダクトを持った企業に絞っていたため、今回の内容も 全て自社プロダクトを持つ会社の指標として使っていました。

18. 聞きたいこと（測りやすいもの） • 給与・待遇
 • スキルセット
 • 社員数
 • 平均年齢
 • リモートワーク比率
 • 取締役のバックグラウンド etc…

19. 聞きたいこと（測りにくいもの） • 開発組織の生産性
 • 会社全体の技術理解
 • 議論の際に健全な衝突ができるか

20. 聞きたいこと（測りにくいもの） • 開発組織の生産性
 • 会社全体の技術理解
 • 議論の際に健全な衝突ができるか

21. 開発組織の生産性 • Accelerate State of DevOps Report 2021 by Google
 (https://cloud.google.com/blog/ja/products/devops-sre/announcing-dora-2021-accelerate-state-of-devops-report )
 ◦ 分析情報では、ソフトウェアデリバリーや運用における組織的なパフォーマンス を促進する機能とプラクティスが検証されています。
 
 ◦ 今年の調査では、エリート パフォーマンスに分類されているチームがソフトウェ アデリバリーのペースを加速し続けており、変更のリードタイムを 1 日未満から 1 時間未満に改善していることが判明しました。
 
 ◦ それだけでなく、エリート パフォーマンスのチームは低パフォーマンスのチーム よりもデプロイの頻度が 973 倍高く、デプロイまでのリードタイムが 6,570 倍速 く、変更障害率が 3 倍低くなっていることが判明しました。
 
 ◦ また、障害が発生した場合のインシデントからの回復時間は 6,570 倍と、驚くほ ど加速されています。

22. 開発組織の生産性
23. 開発組織の生産性 ソフトウェアデリバリーのパ フォーマンス指標 エリート 高 中 低 デプロイメントの頻度 オンデマンド （1日に複数回） 週1回以上 月1回以上 6ヶ月に1回より少ない 変更のためのリードタイム 1時間以内 1日から1週間の間 1ヶ月から6ヶ月の間 6ヶ月以上 サービス復旧までの時間 1時間以内 1日以内 1日から1週間の間 6ヶ月以上 故障率の推移 0%~15% 16%~30% 16%~30% 16%~30%
24. 聞いたこと • デプロイ頻度
 ◦ 割と答えてくれる
 • 変更のリードタイム
 ◦ 「計測してないんですよね～」
 ◦ 「チケットの大きさとか、個人の力量で違うからなぁ」
 • サービス復旧までの時間
 ◦ 遅いところは社内稟議などがあるので、デプロイ頻度と比例しがちと仮定
 ◦ RPOやRTOで答えてくれる会社もあるが、聞きたいのは要件ではなく、開発環境 の話
 • 故障率の推移
 ◦ 計測していない、分からない等
 ◦ たまに答えてくれるところもある
 デプロイ頻度は有用な指標として使えそう

25. 聞きたいこと（測りにくいもの） • 開発組織の生産性
 • 会社全体の技術理解
 • 議論の際に健全な衝突ができるか

26. 会社全体の技術理解 • デプロイ頻度
 • サービスの売り方、対象顧客

27. なぜデプロイが遅れていくか ※ 経験談 & 考察です。他の意見もドシドシお待ちしております。
 
 • 技術的な基盤が脆弱
 ◦ 「CICD基盤」という短期的にはリターンが得られないものに対して、会社として
 工数をかけられるのか
 ◦ 「技術的な先行投資に積極的か」という指標の1つとして見る
 
 • 社内調整が多い
 ◦ CICDは各メンバーの善意によって遅れていく

28. CICDは各メンバーの善意によって遅れていく CICDの基盤ができた！ いつでもリリースできるぞ！ エンジニア

29. CICDは各メンバーの善意によって遅れていく 翌日が休日・祝日の場合は リリースやめましょう PM

30. CICDは各メンバーの善意によって遅れていく 週の始めにアップデートすると 顧客がバタバタするので避けたい 営業

31. CICDは各メンバーの善意によって遅れていく 顧客にしっかり伝えたいから 月2ぐらいでリリース説明やって 社長
 説明
 説明

32. CICDは各メンバーの善意によって遅れていく • 誰もが社員や顧客のためを思って行動する
 ◦ しかしプロダクトにとっては健全ではない
 
 • デプロイ頻度は、「いいこと」をしようとするメンバーに対して、きちんとプロダクトを中 心に考える説明ができるか、コンセンサスが取れているか、という指標になると考え た。

33. 会社全体の技術理解 • デプロイ頻度
 • サービスの売り方、対象顧客

34. 開発の立場
35. 開発の立場 顧客分析サービスWoopra（ウープラ）社のＣＥＯ、エリー・コウリー氏によると、典型的な セールス主導型ビジネス の組織構造は次図のようになっているという。
 左側にはプロフィットセンターとして、セールス・マーケティング・カスタマーサクセスチーム が置かれている。右側にはコストセンターとして、プロダクトの企画・開発するチームが置 かれている。　
 この組織構造で問題なのは、プロダクト開発がセールスよりも劣後されてしまう点だ。
 ウェス・ブッシュ;UBVentures.PLG　プロダクト・レッド・グロース「セールスがプロダクトを売る時代」から「プロダクトでプロダクトを売る時代」へ(p.33).株式会社ディスカヴァー・トゥ エンティワン より引用

36. 開発の立場 「私の一番の後悔は、最初の顧客のＡＣＶ（年間契約金額）が１００万ドルだったことです。 それ以降、我々のプロダクト、ＧＴＭ戦略、カスタマーサポート、そのすべてが１つの方向 性──高単価の大企業に引っ張られてしまいました。
 
 我々は消耗戦をたたかうことを強いられ、そこから降りられなくなってしまったのです。
 経営陣も、社員も、みな最初の顧客と同等かそれ以上の規模の企業だけにアプローチす ることを望みました。
 
 一方、後から参入した競合他社は、同じ市場でも、もっと低価格の顧客層を狙っていまし た。彼らの会社は規模こそ小さいですが、急速に事業拡大しています。我々は彼らと戦う ことができません──それだけのチーム、技術、カスタマーサポート、もっというとそういっ たマインドセットがないのです」
 
 ウェス・ブッシュ;UBVentures.PLG　プロダクト・レッド・グロース「セールスがプロダクトを売る時代」から「プロダクトでプロダクトを売る時代」へ(pp.33-34).株式会社ディスカヴァー・トゥ エンティワン. より引用 

37. 聞いたこと • サービスの売り方は？
 ◦ PLG？ SLG？
 ◦ PLGだからといって良いわけではない
 
 • BizとDevの関係
 ◦ 追加機能はどのようにして決定される？
 ◦ 最終判断は誰？
 
 • 主要な顧客は？
 ◦ 顧客の声ってプロダクトにどう反映される？
 ◦ 個社対応はある？

38. 聞きたいこと（測りにくいもの） • 開発組織の生産性
 • 会社全体の技術理解
 • 議論の際に健全な衝突ができるか

39. 健全な衝突
40. 健全な衝突 経営学の一分野である組織論では三つの「コンフリクト（衝突）」という概念を定義しています。
 
 １. 人間関係のコンフリクト
 ２. タスクのコンフリクト
 ３. プロセスのコンフリクト
 
 （中略）
 実は「心理的安全性が担保されている
 状況下では、タスクのコンフリクトだけは業績に
 プラスの影響がある」という研究結果があります。
 
 石井遼介.心理的安全性のつくりかた　「心理的柔軟性」が困難を乗り越えるチームに変える
 (Kindleの位置No.478-480).日本能率協会マネジメントセンター. より引用

41. 健全な衝突 自分自身、あるいはチーム・組織として向かいたい方向や大切にしていることに、エンゲー ジ（従事）して行動に移していることです。この要素では「大切なこと」を言葉にする、言語 化するというプロセスが重要です。
 
 組織としてのビジョンやミッション、またチームやプロジェクトレベルとしての仕事の意義・ 目標として言語化されることが大切です。
 
 そして、それらの意義・目標と、一人一人の個人の大切なこと、向かいたい方向、やり続け たい行動の繋がりが整うことで、たとえ困難があったとしても行動を促し、仕事に意味づけ することができます。
 
 石井遼介.心理的安全性のつくりかた　「心理的柔軟性」が困難を乗り越えるチームに変える(Kindleの位置No.975-981).日本能率協会マネジメントセンター より引用
 
 ビジョン・ミッション・バリューに対する納得感
 は有用な指標として使えそう

42. 聞いたこと • 会社のビジョン・ミッション・バリューをご自身でどう捉えていますか？
 ◦ 社員の方のバックグラウンドなども含めて、ミッション・バリューをどう捉えている かを聞いてみる
 
 • ビジョン・ミッション・バリューの改正はありましたか？
 ◦ あった場合はどのように行われていたか、誰が決めたのか、なぜ変わったのか など
 ◦ 無い場合は、やる予定はあるのか、現在のビジョン・ミッション・バリューに対して の納得感はどうか
 
 • チームや他メンバーでビジョン・ミッション・バリューのすり合わせをすることはありま すか？
 ◦ 会社によってはチームごとにミッションを定義していたりする
 ◦ 面接官は割とエンゲージメントが高いので、聞けるなら他メンバーの話も聞いて みる

43. まとめ
44. まとめ・注意点 • IT企業は調べきれないほどあるので、いつになっても「もっといい会社があるのでは」 という不安がつきまとう
 ◦ そんな中でも、自分自身の会社への要求に対しての指標を定めることで、納得 して転職活動を終えることができた。（まだ働いてないからどうなるか分からんけど）
 
 • 自分にとってネガティブな回答が返ってきたとしても、その裏の意思決定までしっかり ヒアリングすると、やむを得ない状況だということもある
 ◦ 自分の中でモヤモヤが晴れるまで、しっかりとヒアリング
 どこかの転職活動で、お役に立てば幸いです

45. EOF