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

転職で納得するための 逆質問 2022/04/30 エンジニアと人生 LT会 Inomata a.k.a matty

自己紹介 猪股 光 a.k.a matty (26) ポスタス株式会社 → 6月から株式会社グラファー 一般社団法人 Code for Japan NPTech team 生息地 @ino_aka_matty 平日：家、ANYTIME FITNESS 土日：家、サバゲーフィールド、映画館、本屋 成分表 @10inoino https://www.facebook.com/10inoino 肩書き ● IT系変なTシャツコレクター ● 超特攻型サバゲーマー（すぐ死ぬ） ● MuscleDrivenDeveloper 好きな技術 etc...

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

コードを書く

レビューｵﾈｼｬｽ なんでこういう書き方を選 んだの？ レビューをもらう

レビューｵﾈｼｬｽ なんでこういう書き方を選 んだの？ なんとなくこっちのほうが好 きだったんで なんとなく答える

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

レビューｵﾈｼｬｽ なんでこういう書き方を選 んだの？ 可読性が～ テスト容易性が～ ドメイン的に～ 指標を用いて答える

レビューｵﾈｼｬｽ なんでこういう書き方を選 んだの？ 可読性が～ テスト容易性が～ ドメイン的に～ よかろう いい感じ

レビューｵﾈｼｬｽ なんでこういう書き方を選 んだの？ 可読性が～ テスト容易性が～ ドメイン的に～ 可読性を考えると こうじゃない？ レビューもいい感じ

転職をする

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

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

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

転職で納得するための 逆質問 2022/04/30 エンジニアと人生 LT会 Inomata a.k.a matty

転職で(自分が)納得するための 逆質問 2022/04/30 エンジニアと人生 LT会 Inomata a.k.a matty

注意点 ● 猪股が「転職活動はこんな感じで考えたよ！」というログです。 ○ 勿論転職活動における銀の弾丸では無いので悪しからず。 ○ 考え方の1つとして、今後の転職活動の役に立てば幸いです。 ● 今回の転職活動では、自社プロダクトを持った企業に絞っていたため、今回の内容も 全て自社プロダクトを持つ会社の指標として使っていました。

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

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

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

開発組織の生産性 ● 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 倍と、驚くほ ど加速されています。

• https://cloud.google.com/blog/ja/products/devops-sre/announcing-dora-2021-accelerate-state-of-devops-report

開発組織の生産性

開発組織の生産性 ソフトウェアデリバリーのパ フォーマンス指標 エリート 高 中 低 デプロイメントの頻度 オンデマンド （1日に複数回） 週1回以上 月1回以上 6ヶ月に1回より少ない 変更のためのリードタイム 1時間以内 1日から1週間の間 1ヶ月から6ヶ月の間 6ヶ月以上 サービス復旧までの時間 1時間以内 1日以内 1日から1週間の間 6ヶ月以上 故障率の推移 0%~15% 16%~30% 16%~30% 16%~30%

聞いたこと ● ● ● ● デプロイ頻度 ○ 割と答えてくれる 変更のリードタイム ○ 「計測してないんですよね～」 ○ 「チケットの大きさとか、個人の力量で違うからなぁ」 サービス復旧までの時間 ○ 遅いところは社内稟議などがあるので、デプロイ頻度と比例しがちと仮定 ○ RPOやRTOで答えてくれる会社もあるが、聞きたいのは要件ではなく、開発環境 の話 故障率の推移 ○ 計測していない、分からない等 ○ たまに答えてくれるところもある デプロイ頻度は有用な指標として使えそう

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

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

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

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

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

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

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

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

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

開発の立場

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

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

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

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

健全な衝突

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

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

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

まとめ

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

EOF