tuneの日記

アジャイル開発、組織変革、マネージメント、ファシリテーションについて学んだことの記録

スクラムフェス三河 2021でスクラムマスター育成の話をしてきました #scrummikawa

カンファレンス アジャイル スクラムマスター スクラム Scrum Fest Mikawa

はじめに

スクラムフェス三河でスクラムマスターの育成について話してきました。今年は会社からも5名の登壇者が出ており、普段の業務を通じた学びをコミュニティに少しは還元できたかなと思っております。

https://confengine.com/conferences/scrum-fest-mikawa-2021/proposal/15593

資料をSpeaker Deckに公開していますが、はてなブックマークのホットエントリ入りした効果か、スクラムフェス三河の参加者以外にも読まれているようですので、当日の発表・スクラムフェス三河のDiscordで捕捉した事項も本記事で紹介しておきます。

発表の捕捉

なんでこんな話したの?

アジャイル・スクラム系の情報発信、勉強会・カンファレンスで多く登壇機会をいただいているおかげか、「うちも(大規模)スクラムやろうと思っているのですが、少し話を伺えませんか?」というお話をいただく機会が少なからずあります。数社お話して毎回質問されるのが「チームが増えたときにスクラムマスターの成り手がいないのですがどう対処したのですか?」というものです。最初はその会社固有の課題なのかと思いましたが、話を伺った会社全てに聞かれた気がしたのでこれはひょっとして普遍的な悩みなのかと考えるようになりました。あまりにたくさん聞かれたので、このブログでも5月に一度記事を書いています。

tune.hatenadiary.jp

あらためて読み直すとスクフェス三河発表スライドよりも情報量多いですね💦

リーダー・管理職は、どうしてスクラムマスター不向きなの?

「権力勾配を使って自分の意見を押し通しやすい」ため、"名前を付け替えただけで何も変わってない"状態に陥りやすいと思っています。

※リーダー=会社・組織で定義されているチームリーダーのような役職を指してます

「スクラムがやりたい人」は、どうしてスクラムマスター不向きなの?

熱意があるのは素晴らしいのですが「本に書いてあるからこのやり方が正しい！あの人はスクラムの勉強が足りてない！！異論は認めない！！！」という対立構造を引き起こしがちな気がしています。私たちは価値提供・課題解決をしたいのであって、スクラムをやりたいわけではないはずです。

悩み続ける人はスクラムマスターに向いているの?

メンバーからの「どうしてスクラムだとこういうやり方をするんですか?」という質問に対し、自分たちの言葉で答えを考え続ける方が、その組織にあった良いやり方に辿り着ける確率が高いと思います。

スクラムマスターは役割なの?

スクラムガイドを参照したところ「責任」と言う表現を使っていました。

スクラムチーム全体が、スプリントごとに価値のある有⽤なインクリメントを作成する責任を持つ。 スクラムはスクラムチームにおいて、開発者、プロダクトオーナー、スクラムマスターという 3 つの明確な責任を定義する。

スクラムガイド 2020版

いずれにせよ、「スクラムチーム全体が、スプリントごとに価値のある有⽤なインクリメントを作成する責任を持つ。」なので、スクラムマスター一人が勉強して、スクラムの全てに責任を負わせているような体制は良くないと思います。

開発者兼任のスクラムマスターってどうなの?

「専任はダメ」としているのではなく「専任でも兼任でもいいよ。結果的に全員兼任を選んでいるよ」という状態です。 スクラムマスターに話を聞くとームの状況に応じ、開発に割く時間は増やしたり減らしたりしているそうです。 「他の開発者と同じぐらいコード書いてね」という前提がなければ良いと私は思うのですが、専任にすべき派の意見も聞いてみたいところです。

スクラムを好きになってくれるかもわからないのに「あなたはスクラムマスターになったのだから真のリーダーとしてサーバントリーダーシップを発揮し、スクラムチームとその外の組織に奉仕する必要がある」と言われても困ってしまうと思うのです。

教科書通りやることが何より難しいんだけど

「教科書通りやることだけ」を注文すると案外できますよ。 最初からいろいろスクラムマスターに色々求めすぎているのでは?

「スクラムマスターじゃなかったら」という前提条件の外し方はどういうこと?

スクラムでの正解が欲しいのか、問題に対しての打ち手が欲しいのかでいうと、ほとんどのケースは後者だと思うのです。

スクラムマスターとしてはお給料上がらないということ?

スライドの表現が紛らわしかったなと思っています。

  • エンジニア共通のグレード定義がされており、社員はいずれかのグレードに分けられる (よくあるグレード制度・役割等級制度)
  • 「スクラムマスターは役割」であり、どのグレードに所属していもスクラムマスターになれる
  • グレードで定義された役割・成果が果たせていれば昇格する。

スライドで伝えたかったことは下記です。 - エンジニアのグレード定義とは別にスクラムマスターのグレード定義を用意しているわけではない。 - スクラムマスターの次に、シニアスクラムマスターとかアジャイルコーチのようなキャリアパスを社内で整備しているわけではない

エンジニアリングマネージャーとしてどんなことをしているのか？

開発プロセス 育成 組織 採用 マネジメント

はじめに

今流行りの Meetyを使って社外の方とお話しする機会を作っているのですが、「エンジニアリングマネージャーとしてどんなことをしているのですか?」という質問を何度かいただいたので、自分の整理のためにも日々の具体的な行動・活動をまとめてみます。

私はRetty株式会社でtoC Web開発/toB Web開発 両方をみているエンジニアリングマネージャーであり、この記事を書いた2021年9月時点では20名弱のマネジメントを務めています。エンジニアリングマネージャーとなってからは2年が経ちました。

エンジニアリングマネージャーとは?

いろんな議論・定義がありますが、Engineering Managerは何をする人なのかが網羅されていると思います。個人的には「エンジニアリングのマネジメント」であり、開発で生じる様々な問題を監督し、組織が期待する開発力を用意することが一番の役割だと考えています。開発力は分解すると"プロダクトを生み出す力"、"デリバリーのスピード"、"プロダクト品質"など様々な側面があると思いますが、その時々で組織の弱いところを補うように動かざるをえないことが多い結果、各社・各自でエンジニアリングマネージャーの役割の差が生じているのかと考えます。

いくつかの軸でまとめるにあたりラクスルVPoEの高橋さんがまとめた下記資料を思い出しました。この中でも"やってるもの"と、"やってないもの"と、"書かれてないけどやっているもの"があり、本当に領域が広いのだなと改めて感じました。

メンバーのサポート・育成・評価

メンバーの状態観察

週1回〜隔週1回のペースで1on1を1回30分行っています。社内の他部門や他社の話を伺うに、開催頻度は多いようです。 結構な時間が1on1で割かれてしまいますが、問題の芽が小さいうちに拾えることが多く、実施は大変ですがこのペースでやっています。

1on1は相手のための時間とし、何を話すかは基本相手に委ねています。 入社以来使っている1on1テンプレートには先頭に目的が記載してあり、短くまとまっていてとても気に入っています。

[1on1について]
- 1on1される側のための時間であって、進捗確認や伝達命令のためのものではない
- 問題解決ではなく、課題発見をするためのもの
    - 解決は自分で考えて自主的に行っていってほしいです
    - 解決のための相談、アドバイス等の協力は積極的に行います
- お互いの期待値のすり合わせとFBの場

[Topics テンプレート]
- 目標達成の上でもやもやしていること、困っていること
- 業務上での気付き(前回から今回までで学んだこと、うまくいったこと、いかなかったこと)
- チームがもっと良くなるためのアイデア、改善点
- MGR/EM/ボードメンバーへのリクエスト
- プライベートについて(家族や自分の病気、イベントなど仕事に影響があることがあれば。結婚、出産、介護等)
- 将来のキャリアについて(変更や悩みがあれば)

目標設定・人事評価

会社の仕組みとして「3ヶ月単位で目標を建て、評価を行うMBO(Management By Objectives)」を採用しているため、それを実施しています。

プロダクト開発はスクラムで進めていますが、"チームで開発する"・"優先順位に従って開発する”・"やることは適宜見直す"というスクラムの性質から、やりきり目標や個人ごとの開発項目を建てると都度見直しが発生して運用が大変です。そこで組織目標・個人目標・個人課題に分けて設定しています。

  1. 組織目標(部門目標)
    • 複数チームで共通
    • 3ヶ月毎に見直す、大きくは変わらない
  2. 個人目標
    • 全員ほぼ共通、公開する
    • 3ヶ月毎に見直す、あまり変わらない
  3. 個人課題
    • 個人ごとに固有、非公開
    • 業務グレードが変わらない限り変わらない

目標の難易度設定が難しかったり、評価の時期と成果が出る時期がずれたり、評価の時期は毎回悩み事が発生しますが、マネージャーとして重要な職務だと考えて丁寧に説明することを心がけています。

評価の話は2020年のスクラムフェス大阪でも話をしました。

dev.classmethod.jp

後進の育成

新卒1〜3年目くらいのジュニアエンジニアは1on1を通じて成長を阻害している要因を突き止め、アドバイスをしています。 成長曲線や壁を乗り越えるタイミングは人によって異なるため、取り組み姿勢が間違っていなければ焦らず目の前のタスクに取り組むよう話すことが多いです。

中堅・シニアエンジニアになると、複数の人を巻き込んで大きい成果を出してもらいたいことが増えるため、大きな開発の取りまとめや推進役をお願いしたり、ジュニアエンジニアのメンターを依頼したりします。役割の数がどうしても少ないため、機会提供が偏ることが無いよう、乗り換えられそうなちょうど良い難易度になるよう、3ヶ月〜半年ぐらい前から考えることが多いです。

マネージャーの育成は最も時間がかかります。開発とマネジメントは求められるスキルや振る舞いが異なるため、開発タスクを減らし、マネージャーとしての振る舞いを考え・学ぶための余裕を意図的に作ってあげる必要があります。 自分が抱えている問題を移譲して代わりに解決に取り組んでもらったり、実際に起きてしまった問題を題材として「今から戻ってやり直せるならどうしたら良いか」を議論するなど、時間をかけて考え方やアプローチを伝えています。

日常の労務管理

いわゆる勤怠管理ですが、忙しさの山や谷を作らず、一定のペースで働けるように業務量を気をつけて見ています。 より具体的には残業が常態化していないか、残業が一時的に増えた場合はそれが開発の山場として妥当なものかをチェックしています。

開発

プロダクトマネジメント

企画に責任を持つプロダクト部門が別途あり、施策や方針決めは基本委ねています。 アイデアや機能提案をすることはありますが、それよりも技術負債やセキュリティ問題などエンジニアでないと判断がつかないものについて開発優先順位の強めの提言をすることが多いです。

開発タスクを分解したり、メンバーにアサインすることは基本していません。 プロダクトオーナーにより優先順位で並べられたプロダクトバックログを、開発チームが毎週開発できると考える分だけとっていきます。 自分は四半期・半年・2〜3年といったスパンで、"何をやっていきたいか"を社内のいろいろな立場の人から聞き、どう実現していくのが良さそうかを考えることが多いです。

エンジニアリングのリーダーシップ

機能追加や不具合修正関して、プロダクトコードを直接書くことはしていません。 技術採用や開発方針の決定、細かな設計も開発チームに委ねています。

開発への関与としては、チームが将来取り組むであろうふわっとした課題を先に調査しておくことを手が空いた時にしています。 また現場では決められないような「決めの問題」が生じた時に、開発責任者として意思決定したりしますが極めて稀です。 障害・インシデントが発生したときはその影響範囲の大きさによって、対応の陣頭指揮をとったりします。

開発を広く見てはいますが、自身の役割は技術でプロダクトを引っ張ることを期待されるテックリードとは異なるもので、エンジニアリングマネージャーのキャリアの先にCTOがあるとも考えていません。

採用・採用広報・アドバイザーの招聘

上位の目的としては「今の開発体制で足りない人を連れてくる」だと考えています。

採用

採用チームと定例を持ちながら、採用活動に広く協力をしています。 スカウトのフィルタリング、スカウト文面の送信、カジュアル面談の実施、コーディング試験の評価、技術面接など。

またインターンコンテンツを考えたり、採用イベントを準備したりします。 ここ半年だと下記のイベントに携わりました。

採用広報

勉強会の開催、カンファレンス登壇、テックブログ執筆などの活動です。 自分自身の知名度を上げキャリア形成をやりやすくする目的もありますが、組織としても採用活動に遅れて効果が出てくると考えています。 直近だとスクラムフェス三河に会社から5件のプロポーザルをだし全て通過、Go Conference Autumnに会社から7件のプロポーザルを出すことができました。 ノルマや金銭的なメリットを設定しているわけではないため、普段の業務で学んだことを対外的にアウトプットし、学びにつなげるメリットを広く組織に浸透できているのだと思っています。

また定期的に対外アウトプットをしておくと、一定期間の自分の活動をまとめるきっかけになるだけでなく、「口だけにならない」と言う自分への戒めにもなるなと感じています。

アドバイザーの招聘

自分が詳しくなく組織としても弱い領域、自分ができるけど手が回らない領域で外部の識者の方にアドバイザー・相談役をお願いしています。 どの方にも豊富な経験に基づいた適切なアドバイスをいただけており、組織として悩む時間を減らせたり、自信を持って取り組む後押しになっています。

社内勉強会での講演や、単発のワークショップももっとやっていけたらなと思っているのですが、開発の状況・予算・開催タイミングなどあり、声はかけながらも開催にいたってないものがいくつもあります。これは私の力不足が大きく、ただ申し訳ないです。

他社との情報交換

エンジニアリングマネージャーとしての打ち手は組織や置かれた状況のコンテキストによって効果があるものもないものもあり、引き出しを増やすことが大事だと考えています。 なので他社の方から相談をいただいた場合は基本的に引き受け、積極的に自分たちの経験を共有しています。 相談を持ち込んだ側は同じ問題で時間を取られることなく、壁を乗り越えた先にあった新しい問題も次回に共有してくれるためどの会社とも学びのある情報交換をさせていただいております。

他にも「自社で起きている問題が一般的なのか、自社固有の問題なのかを切り分ける判断材料になる」「他社の相談を先に受けておくことで、自社で別の相談が出てきた時に相談しやすい」というメリットもあります。

終わりに

会社から与えられた仕事や目標はあるようであまりありません。会社やプロダクトの様子を見ながら社内を広く見渡し、自分で考えて作っています。 直接的な仕事はなく、自分が居なくても開発業務は回ると考えています。 1週間居なくても全く問題ないでしょう。事前に準備しておけば1ヶ月居なくても多分大丈夫だと思います。 ただし3ヶ月居なくなると開発でうまくいかないことが増えてきたとメンバーが感じることが増えるのではないかなと思っています。 エンジニアリングマネージャーとしての貢献はこれぐらい長期で効いてくると考えています。

大変なことが多い、直接的な達成感も得にくいエンジニアリングマネージャーですが、下記が面白さかと考えています。

  • プロダクトの成長 : なんだかんだ方向性に関与できる裁量が大きい。
  • 組織の成長 : 同じメンバーでも雰囲気や成果は異なる。
  • メンバーの成長 : 突然殻を破るような成長を身近で見れるのは嬉しい。

この記事を読んでもっと聞いてみたいと思った方、ディスカッションしたいと思った方、Rettyのエンジニアリングマネージャー職に興味が沸いた方は是非Meetyでお話ししましょう。

meety.net

2021年7〜8月に社内で共有したアジャイル開発関連の記事

LeSS アジャイル スクラム コミュニケーション プラクティス プロダクトマネジメント スクラムマスター スプリントレビュー ファシリテーション

社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。この記事は第6弾でトータルで1年間まとめを続けることができました。

ノウハウ・知見

チームで品質を考えるレビュー

speakerdeck.com

プロダクトオーナーとしての成長

わかりやすい。

takaokimura.medium.com

エンジニアが自走する組織の作り方

medium.com

個人が持つタスクに期限を設けてみる

スケジュールにバッファを設けるのは悪か？

不確実性コーンの実例として分かりやすい。

tech.unifa-e.com

体験のデザイン・リーン・アジャイル開発の関係

何が欠けるとどうなるのか説明がわかりやすい。

note.com

アジャイル関連本の年表

app.mural.co

アジリティを支える品質特性

speakerdeck.com

リモートアジャイル開発のノウハウ集

www.agile-studio.jp

片思いマッピング

service.plan-b.co.jp

他社事例

LINE NEWS

エンジニア40人、企画60人でLeSSっぽく作るLINE NEWS

engineering.linecorp.com

HERPのLeSS事例

note.com

LeSSをやめたRepro

octopass.jp

ラクスのLeSS事例

speakerdeck.com

アカツキのLeSS事例@CEDEC

speakerdeck.com

Twitter

PdMは映画監督説

ツールが問題を解決してくれるのは幻想

ふりかえりでファシリテーターが全ての発言にコメントしてしまうあるある

最初にWhyを明確化しろ

プロダクトバックログの優先順位が守られない困りごとの比喩

スプリントレビューは料理の試食会

スクラムマスターは先頭に立つな

その他

Rettyメンバーからのカンファレンスプロポーザルです。話が聞きたいなと思ったらConfengineにログインして「いいね」をお願いします。 採択されなくても、勉強会に声かけいただければ皆喜んで参加すると思われます。

※8/29時点

[スクラムフェス三河]

[スクラムフェス札幌]

[Regional Scrum Gathering Tokyo 2022]

2021年5〜6月に社内で共有したアジャイル開発関連の記事

LeSS アジャイル スクラム Scrum Fest Osaka コミュニケーション トヨタ生産方式 プラクティス プロダクトマネジメント

社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。この記事は第5弾、次回で祝1周年となります。

ノウハウ・知見

リモートのスプリントレビューを盛り上げるコツ

弊社でもレビュー後のZoomブレイクアウトルームを使った議論タイム設けました。簡単で効果高いのでおすすめ。

medium.com

スクラムマスターの資格まとめ

当方無免許です。

yattom.hatenablog.com

初めて入るチームでの立ち回り例

ikikko.hatenablog.com

内製化に取り組む方へのアドバイス

blog.kengo-toda.jp

スクラムとSECIモデルの関係

iucstscui.hatenablog.com

開発スピードを上げたいなら開発スコープを小さくしよう

はい。

medium.com

ロードマップに機能を書くべきではない

note.com

ブロッコリーさんがよくシェアする記事、シチュエーションも添えて

良記事集です。

nihonbuson.hatenadiary.jp

素早く頻繁に失敗しよう

ゾンビスクラムサバイバルガイド

面白そう。

agnozingdays.hatenablog.com

リチーミングモデル

固定的なチームが成熟しすぎると、サイロ化が生じて学習や改善がチーム内に閉じ、組織学習を阻害するという考え方。下記のどれもやった記憶あり。

  1. 社会化(Socialization) — 新たなチームメンバを参加させるためにチームが継続的な努力を払う。そのような継続的プラクティスを通じて、新たなチームメンバの受け入れ能力が向上する。
  2. 有糸分裂(Mitosis) — 分裂可能な大きなさまで、チームが成長する。新たに生まれたチームは、すでにその時点から、業務に精通している。
  3. ボランティア消防団(Volunteer Fire Department)チームモデル — 有志メンバが一時的なタスクチームを結成して、主要な問題を解決した後に、元のチームに戻る。
  4. 交換所(Trading Places) — チームが他のチームとの間でメンバを一時的に交換することで、組織全体で学習成果を共有する。

www.infoq.com

仕事中は理想のプログラマーを演じ切るといい振る舞いができると言う話

druby.hatenablog.com

他社事例

ヤフー

デイリースクラム(朝会)でチームが見つけたチーム内の課題を話すのよさそうです。

techblog.yahoo.co.jp

SMS

リリース出来たらご褒美にレゴを組み立てる文化

tech.bm-sms.co.jp

LINE

LINE TODAYでのLeSS事例、LeSS成分は少なめ

www.youtube.com

Chatwork

モブレビューのおすすめ

creators-note.chatwork.com

Scrum@Scaleの取り組み

SmartHR

デザイナーのスクラムへの関わり方で「スプリントレビューでステークホルダーを観察する」というのがあって面白い、確かに。

creatorzine.jp

LeSS開発の話がチラッと。4〜5人/チーム * 5チーム = 20名弱っぽい。

tech.smarthr.jp

スプリントレビューにユーザーを招待した話、すごい！

tech.smarthr.jp

ユーザー要望から機能を開発した場合、要望をくれたユーザーに報告して開発完了となるらしい。素晴らしい。

Mixi / みてね

LeSSをやめた話

[https://atsushisakai.medium.com/%E3%81%BF%E3%81%A6%E3%81%AD%E3%81%AE%E9%96%8B%E7%99%BA%E3%82%B9%E3%82%BF%E3%82%A4%E3% 83%AB%E3%82%92%E5%A4%A7%E3%81%8D%E3%81%8F%E5%A4%89%E3%81%88%E3%81%9F%E8%A9%B1-6e1a206922a6:embed:cite]

Timers

LeSS事例

techblog.timers-inc.com

勉強会・カンファレンス

iCare Dev Meetup

キヤノンメディカルの「あのチーム」の話

www.youtube.com

スクラムフェス大阪

基調講演

qiita.com

サイボウズ天野さんの社会人の基礎としてのアジャイルの背景知識まとめ

家事の話だけど、開発部門が取り組むカイゼンがどういうものかわかりやすいと思い会社の子育てチャンネルに投げた。

世の中いろんなスクラムマスターがいます。

アカツキさんのLeSS事例

ラクスさんのアウトカム指向への転換取り組み。課題感がうちとちょうど同じくらい。

テストを書く前に考えるテストの話

トヨタ主査制度の最初の1人の話

スクラムフェス札幌

残念ながらオンライン開催のようですが、今年も盛り上がって参りましょう。

www.scrumfestsapporo.org

その他

Google Relay

まだ読めてない><

スクラムマスターになると張り切っちゃう問題

スプリントレビューの工夫

ユーザーに近しい方に来てもらい、シナリオを渡して観察する。どんな感じか見学に行ってみたい。

ベロシティを目標においてしまうアンチパターン

社内で何人かにマサカリささってました。

Miroにホワイトボードを置くとトピックが散らからない説

プロダクトチームのあり方

右側を志向していかないといけない。

TRYを翌週振り返るときのよい意思表明のやり方

「直接話した」スタンプ

弊社にもできたんだけど、「話した内容をSlackに書くべきだ！」という主張の方がそれなりにいるみたい。 主張はわかるけど、スタンプもないと話しがあったのかも、誰が話したのかもわからないし、ないよりは全然マシだと思うんだけど。 内容を残しておいて欲しいほどのやつなら「口頭で話したことをメモで残して下さい」と言いやすくなるので。

PBIの打率測ってますか?

スクラムフェス大阪 2021でシステム思考の話をしてきました #scrumosaka

カンファレンス Scrum Fest Osaka アジャイル システム思考

はじめに

今年もスクラムフェス大阪でプロポーザルを採択いただき、話してきました。

confengine.com

社内で向き合う課題が段々と複雑に・難しくなってきているため「システム思考」を布教することが増えてきています。 ただ「これ読んでおいてー」ですむような、最初のとっかかりに適した資料がなかなかなく、「ないなら自分で作るか！」と追い込むためのプロポーザルでした。 他の方の登壇を聞いていてもシステム思考に言及することが最近増えてきたのでニーズはそれなりにあるのではないかと思っています。

登壇準備をしている時は20分枠だといろいろ盛り込むのが難しいなと感じていましたが、使い始めるにあたって必要最小限のことを盛り込むようにまとめられたかと思います。

過去のシステム思考に関連しそうな記事

参考資料

なぜあの人の解決策はいつもうまくいくのか？―小さな力で大きく動かす！システム思考の上手な使い方

世界はシステムで動く ― いま起きていることの本質をつかむ考え方

学習する組織 ― システム思考で未来を創造する

#JBUG 広島 #8 でRettyでの改善取り組みを話してきました

勉強会 アジャイル 組織

2021年6月13日に行われたJBUG 広島 #8でRettyでの改善取り組みを話してきました。以前 LeSS Studyで紹介した内容 をベースにした再演です。

jbug.connpass.com

4月に刊行されたユニコーン企業のひみつと絡めて話して欲しいという話があり、アジャイル/スクラム/LeSSではなく、何を課題と考えて、どう変えていったかを中心とした話としました。

反応など

Twitter

カジュアル面談で話すとよさそうなこと

採用

f:id:tune:20210605151926j:plain
Photo by Christina @ wocintechchat.com on Unsplash

はじめに

先日heyさんの採用イベントで公開カジュアル面談をさせていただきました。

hey.connpass.com

「できるだけ本当のカジュアル面談に近づくようにやりたい」というhey 勝亦さんの希望もあり、事前に打ち合わせは特にせず、「こいつらヤラセっぽいな」と思われないように深く切り込むような質問もときおり混ぜ込みました。もちろん事前にheyさんの公開資料を読み込んで考えてきたものです。

せっかくなので「自分がカジュアル面談を受けるならこういうことを聞くだろうな」と考えたこと、逆に普段実施する側で「これは必ず説明するように心がけていること」をまとめてみました。 Googleで「カジュアル面談 質問」と検索すると例がいくつも出てきますが、大抵は公開されている会社情報を調べるとわかることばかりなので、直接聞かないとわからないことを聞いた方が良いですよね。

自分ならこんなことを聞いてみたい

事業構造、何でお金を稼いでいるか。

創業時の事業や広く認知されているサービスと、実際にお金を稼いでいる事業・サービスが異なる会社がよくあるなと思っています。 会社における売り上げ比率から社内のパワーバランスや、今後力を入れていく開発領域も推測できると思います。

何で収益を上げられているのかわからないけど積極的に採用を行なっている場合、調達した資金を燃やしながら人員を拡大している可能性があります。 広告事業ができる前のGoogleも採っていた戦略ではありますが、Googleになれなかった会社の方が圧倒的多数ですので、目処・戦略はついているのか、いつまで挑戦できる余力が残っているのか、リスクとリターンを確認しておくと良いと思います。

募集の背景

「〇〇で有名なあの人と一緒に働けるチャンスかもしれない」と思わせる募集要項がはっきりした求人をたまに見かけることがありますが、憧れのその人が退職するために代わりの人材を募集していることがあります。「これからXX人材を集めて業界内を引っ張っていくんだ！」とピュアに想像せずに、きちんと確認した方が良いと思います。

募集の背景をはっきり答えられない場合は採用の頭数を追っている可能性が高いと思います。あなたの経歴やスキルはそこまで重要ではなく、他の誰かでも代替はきくでしょう。

競合との差異

競合が全くない会社・事業領域はまずないと思います。 競合を意識し過ぎているのもユーザーを見ておらずよくない兆候ですが、意識しなすぎなのも自分たちのやりたいことをやっているだけでまずいサインかもしれません。

業界の2番手企業が1番を追い抜かすことはほぼなく、逆転にはなんらかの競争軸の変化が必要なので、何を差別化ポイントと考えているのか説明してもらうと良いと思います。営業力や気合いが答えとして出てくる場合は多分逆転は望めないでしょう。

今の会社の課題

「人が足りない」みたいな話しか出ないと、見えにくい・隠れてしまっている本当の問題に向き合えてないのではないかと思います。 ここをはっきりと答えてもらえると、自分が入ることでどう貢献できるか、過去の経験がどう生かせるかといった話で盛り上がれるはずです。

事業成長の先に何が起きるか

今伸びている事業があってもいつか成長の終わりを迎えます。その時に会社はどう動くのでしょうか? 国外を目指す、新規事業を立ち上げる、M&Aを実施するなど考えられますが、会社の打ち手は自分の考え方とあっていますでしょうか?

その会社で働くことで何が得られるか

せっかくなので他の会社では得られない貴重な経験があると良いですよね。 すぐに答えるのが難しい質問かと思いますが、すぐに答えてくれるようだと普段から自社の強み・差別化を意識している証拠かと思います。

説明するように心がけていること

会社でできること、できないこと

事業構造や経緯に起因する正解があるわけではない事項は、最初に確認しておいた方が双方時間を無駄にしなくて良いと思います。

  • 会社が一番重視していること。ユーザー、売り上げ、事業成長など。
  • 開発スタイル。個人で行うのか、チームで行うのか。
  • 開発領域。フロントエンドからインフラまで広く触れるのか、職能・特定の機能に限定されるのか
  • 新規技術の採用。取り入れやすいか、しにくいか
  • 新規事業の立ち上げ。携われる機会は多いか、少ないか。

働き方、会社の制度

自社が裁量労働制なのでフレックスとの差異を必ず説明しています。 また裁量労働だと勤務時間の懸念を持たれるため開発のサイクル、1日の流れを紹介しています。

コロナ禍になってからはリモート勤務の割合、緊急事態宣言中の勤務、コロナが落ち着いた後はどうなりそうかを話すことが増えました。

面談相手の質問に時間が許す限り全て答える

「会社にいい印象を持ってもらう、願わくば選考に進んでもらう、すぐに選考に進まなくても転職の機会にまたコンタクトを取って欲しい！」が面談する側の気持ちなので、どんな些細なことでも相手が知りたいことは答えるようにしています。

おわりに

上記の話、カジュアル面談を面接の1歩目として考えている会社だとウケは悪そうですが、「カジュアル面談」だしこれくらいは答えてくれる会社が多いといいなと思っています。