Developers Summit 2020 Day1(02/13 Thu)参加メモ

Developers Summit 2020 Day1(02/13 Thu)

Developers Summitとは

• 翔泳社さんのイベントです。HPはこちら
• #devsumiでTwitterのハッシュタグを追ったりすると会場の雰囲気が分かったりします
• 参加したセッションのメモについて
  • スライドが発表されたら、タイトルの部分から飛べるようにリンクを貼っています。スライドではなくtogetterを貼っている場合もあります。
  • 事前情報は、タイムテーブルのリンクから取得しました
• 小ネタ
  • 会場は目黒の雅叙園です
  • コートはクロークに預けることができるため、移動時の荷物を減らすために会場に早めに行って預けるのがオススメです
  • 2日目の記事はこちら

①最新のブラウザで変わるCookieの取扱いやプライバシーの考え方

事前情報

10:00～10:45 13-C-1
古川 陽介[リクルートテクノロジーズ]

ブラウザのプライバシーに関する考え方は強化されています。 SafariのITPをはじめとして、 Chromeでは3rd Party Cookieを廃止する方向でプライバシーに配慮したウェブの考えを表明しています。
プライバシーへの配慮がどうなっており、今後どうなるかについてブラウザの技術的な観点から話をします。
この講演では下記の内容について解説します。

- Cookieについてのおさらい
- 今3rd party cookieが非推奨になっている理由
- ITP
- Privacy Sandbox

参加時メモ

• セキュリティ、プライバシー周りのブラウザの変更の傾向についての話

• 3rd Party Cookieは廃止していく方向で動いている

  • フラッシュなどと同じ感じ
  • 各ブラウザによって細かい部分は異なるが、基本的に3rd Party Cookie自体は使い物にならなくなる。
  • Cookieに変わるTrackingの方法が考えられている

• そもそものCookieの仕組みの話

• プライバシーの動き

  • 短期的なものでなく、中長期的な話
    • ブラウザ業界、ウェブ業界全体の話になっている
  • 実は、どのブラウザもTrackingのすべてがダメだと言っているわけではない
    • Cookieという便利な箱になんでもかんでも頼るのではなく、新しい仕組みでプライバシーにも配慮しつつ、利便性も考慮した新しいモデルにしようという取り組みが今起きている
    • Private Click Measurement
      • 広告がクリックされてからコンバージョンされたかどうかを、Cookieに頼らずに追える

• 我々はどうするべきか

  • サービスで使う場合はセッションとしての扱いにとどめる
  • 扱う場合はsecure属性とHttpOnly属性の両方をきちんとつけて、サーバーでセッションクッキーを発行して使う
  • JavaScriptで書き込みしているところは極力減らす

感想

• 業界全体の流れを追おう。
• 「そういう流れが『ある』」ということを知るために、こうしたセッションはありがたい。調べれば出てくる話も、知らなければ調べることができない。
  • 3rd party cookieが非推奨になっているという話は聞いたことあるような無いような、というレベル感だったため、全体感を掴めて良かった。
• スライドの最後に参考資料が載っており、しっかり作り込まれていた。

②アプリケーションやシステムが悪い奴らに攻撃されたらどうなる？

事前情報

11:05～11:50 13-F-2
松岡 正人[日本シノプシス]

2019年は日本ではＸＸペイの、はたまた〇〇県からの個人情報流失のニュースが騒がれた一年でした。
これらのような事故や事件は防ぐことができたかもしれませんが、そのためにはシステムやアプリケーションの開発者や運用者がサイバーセキュリティについて適切な知識とノウハウがなければ難しいでしょう。でも、そんなみなさんを手助けできる製品やサービスがあります。
システム開発のどの段階で何をすればいいのか、実際の事故や事件の事象と照らし合わせて、取りうる解決策を提示します。

参加時メモ

• サイバーインシデント
  • Allianzビジネスリスクバロメーター2019で、サイバーインシデントはトップ要員
  • 要因
    • ①悪い連中がやらかす(事件)
    • ②事故でやらかす
  • サイバーインシデントの技術的なキッカケになるものは脆弱性
    • コード量が増えればリスクも増える。
    • リコールが増えている。制御プログラムの不具合が影響大
    • 生命の危機、社会インフラの停止、情報漏洩
    • コードのセキュリティがサイバーセキュリティには非常に重要
    • 現代のソフトウェア開発の「課題」が増え続けている
      • いかに短い期間で
        • 開発できるか
        • ビジネスにミートするか
        • 品質を上げるか
        • セキュリティに配慮できるか
      • ソフトウェアの脆弱性は急速に増加している
        • コード量が増え、保守できる時間は短くなっている
        • 人も足りない
• 開発に関わる話
  • よりセキュアなアプリケーション開発
    • まず考えるべきは「解決すべき課題はどこにあり、それをどう解決できるか」を明確にすること
      • 自分たちのプロダクトの脆弱性の種別を把握しないことには具体的な対策を考える段に行けない
    • NISTのセキュリティガイドをベースにしたフローチャート
  • 脆弱性は増え続けている
    • CWE Common Weakness Enumeration：弱点
    • CVE Common Vulnerabilities and Exposures：脆弱性
  • リスクと脅威
    • 脅威モデル
      • 内側からの脅威と外側からの脅威
        • 中に悪い人がいる可能性
        • リモートでの侵入
      • どこにどのようなアセット、資産があるのかを把握する
        • それらの間の相互作用を可視化する
      • セキュリティ管理策を構成する
        • どういうことをやられるから、どういう対策をしよう
      • 管理策を回避しうる脆弱性を見つける
      • Credential Dumping
      • ツール
        • Microsoft STRIDE
        • QWASPのチートシート
        • Openid Foundation RFC6819
  • まとめ
    • 解決すべき課題を明確にしよう
    • モデル描いてみよう
    • 脆弱性を把握しよう
    • 把握した脆弱性の解決策を探そう
    • 必要に応じてツールを使おう
    • CoverityでCWEを検知
    • シフトレフト。それぞれのフェーズでセキュリティチェック

感想

• Allianzビジネスリスクバロメーターというものの存在を初めて知った
• 「自分たちのプロダクトはどのようなもので、どのようなセキュリティ的な課題があり、どう解決できるか」ということを考えていきたい。そのためには自社のプロダクトのことを知ること、セキュリティについての適切な知識をつけていくことをやっていこう。

③noteの決して止まらないカイゼンを支える、エンジニアリングへの挑戦

事前情報

12:10～12:40 13-C-3
今 雄一[ピースオブケイク]

noteは“だれもが創作をはじめ、続けられるようにする。”をミッションとし、毎週の小さくても大事なカイゼンからサークル機能やnote.comへのドメイン移行のような大きなカイゼンまで、あらゆるサービスのカイゼンを行ってきました。
これまでのカイゼンを実現するにあたり直面したサービス設計・実装の問題をどう技術で解決したか、継続的に価値を届けるための意思決定と組織づくり等に触れつつ、これからも決して止まらないカイゼンを支える、エンジニアリングへの挑戦として、今後どのようなことをやっていくのかをお話します。

参加時メモ

①noteのグロースモデル

• コンテンツ増える、読者が集まる、、、などのモデル。スライド9ページ参照。
• 単一のKPIに絞らない
• バランス良く成長させた

②noteのチーム

• グロースモデルを支えるチーム
  • 基盤、機能開発、カイゼンの3チームに分けた。長期中期短期
    • 基盤：グロースモデル全体を活性化して加速させる。下支えと会計処理
      • データ基盤、スパム対策、SEO対策、課金機能の拡張・メンテナンスなど
    • 機能開発：各ラインを太くしてポテンシャルをあげる。主軸となる機能を作る
      • サークル、Nuxt.js移行、エディタの開発など
    • カイゼン：線が途切れていないかチェックしたり、線のバランスをとったりする
      • 年間100以上の施策をリリース
  • バランスがとても大事で、それをチーム構成で実現した。結果的に、後回しにしがちな施策も動かせるようになった

③noteのデータ

• グロースモデルのデータが把握しにくくなっていた？
• どこが穴抜けなのか、チェックする必要が出てきた
• データ活用始めました
  • 定性と定量
  • データ収集のための分析基盤の構築
  • 創作継続率→定義づけ→仮説検証→調査→反応が大事
  • グロースモデル×データで施策意思決定精度を上げる

④何をやっていくのか

• グロースモデルの発展は継続してやっていくのは大前提として
• パフォーマンス課題の解消
  • フロントNuxt.js
  • サーバーサイドRails
  • インフラAWS
• レコメンドの向上
  • 適切なチャネルは
  • セグメントの定義は
  • 使用するMLの定義は

⑤まとめ

• グロースモデルとても大事
• チームとデータでグロースモデルを支える
• エンジニアリングの挑戦…たくさんある！

感想

• データからの客観指標の学びをチームに活かそう

④質とスピード

事前情報

13:05～13:50 13-B-4
和田 卓人[タワーズ・クエスト]

プロジェクトマネジメントにおいて、QCD（Quality, Cost, Delivery）という概念があります。
何かを重視すると、別の項目が犠牲になるという考え方ですが、ソフトウェア開発の文脈において、質（Quality）とスピード（Delivery）には本概念は当てはまりません。
質と開発スピードがトレードオフの関係であるというのは典型的な誤解です。
本講演では、どのように質とスピードを考えればよいかについて述べます。

参加時メモ

• twadaさんの色々なスライド
• 荒ぶる四天王の話。『アジャイルサムライ』p86
• 品質を犠牲にすればスピードは得られる？
  • 短期的には得られる
  • 中期的には逆効果
  • 長期的には致命的
• そもそもここでいう「品質」とは
  • 「品質とは誰かにとっての価値である」G.M.Weinberg
  • ilities
    • 〜〜性
  • 狩野モデル
    • 顧客の満足度と充足度
      • 当たり前品質と魅力品質
      • 一元的品質
  • 見える品質と見えない品質
    • 外部品質と内部品質
    • 利用時の品質と製品品質
    • 機能要件と非機能要件
      • 今回は外部品質と内部品質
        • 私たちが「犠牲にしよう」と言っているのは内部品質
        • 外部品質Exと内部品質In
        • どのような内部品質を犠牲に捧げようと言っているのか
          • Cavano and McCalls Quality Factors
            • 内部品質の中の保守性 Maintainability
          • Quality Characteristics
            • Maintainability 保守性
              • Testability
              • Understandability
              • Modifability
          • 後でクリーンにすれば良いよ
            • そして崩壊が始まる『Clean Architecture』
            • 変更しにくい、呪いの言葉「動くコードに触れるな」
            • 爆弾処理のようなリリース
          • 保守性の低さがもたらすもの
            • 徐々にガンになる
            • 一つ一つの変更に余計な時間がかかる
• 保守性を犠牲にすればスピードは得られる？
  • 短期的には得られる
  • 中期的には逆効果
  • 長期的には致命的
• では、スピードを落とせば保守性は上がる？
  • ゆっくり作ってもいいものができるわけではない
• クイック＆ダーティーの神話
  • 「与えられた開発機関から柔軟に汚さと速さを選択するというような器用な芸当はほとんど不可能」『エンジニアリング組織論への招待』
• つまり、トレードオフではない
  • 「要はバランス」という言葉が出てくるということは、思考を掘り下げられていない
• 品質アップはコストアップかダウンか
  • 品質のコストには2つの考え方がある Quality is Free
    • コストアップ説
    • コストダウン説
    • どちらが正しいかは議論されてきた
    • 品質「実質無料」
      • 手戻り減る
      • やり直しが減る
      • 品質向上のためのコストが品質向上の結果減るやり直しにかかるコストを上回ることにより、結果的に品質が「実質無料」
      • 『エクストリームプログラミング』からの引用
      • 『Clean Architecture』からの引用
        • 短期的にも長期的にも、崩壊したコードを書くよりも（後で書く
      • 『レガシーコードからの脱却』からの引用
      • 質からスピードへの影響
        • コードの品質を犠牲にしたから速いのではなく、コードの品質を高く保っていた「からこそ」速い
      • スピードから質への影響
        • QCDのトレードオフなんて本当はなかったんだ
        • 4つのキーメトリクス
          • リードタイム
          • デプロイ頻度
          • MTTR(平均修復時間)
          • 変更失敗率
      • 「質vsスピード」という概念は根本的に間違っている
      • 一番重要で一番やっかいなスキルはシステムを設計するための判断力だ
      • 判断力をつける一番の方法は、自分で設計したシステムを長い間メンテすること
      • 損益分岐点はいつくるのか
        • テスト自動化の損益分岐点は4回
        • A Philosophy of Software Design 思ったより早く来る
        • 内部品質への投資の損益分岐点は3年後とかではなく1ヶ月以内に現れる
          • 自分たちが受益者であるということ
          • 道徳や意識でなく、自分たちの損得の話
          • 内部品質への顧客は1ヶ月後の自分たち。
• 保守性を犠牲にすればスピードは得られる？
  • 短期的には得られる
  • 1ヶ月後には逆効果
  • 長期的には致命的
• 与えられた時間に対してやるべきことが多すぎる場合、どうするか
  • スコープを削る
• どうやって個人の質を上げるのか
  • スピードと質は何とトレードオフなのか
    • 次世代への教育、新技術の調査など
    • メンバーの成長、その成長のために必要なフィードバックや学習の時間

感想

• 1年以上ずっとずっと聴きたいと思っていた和田さんの講演。時間があっという間だった。
• 直感的になんとなくそうかなと思うことを、色々な文献や資料を参照しながら明らかにしている
• 先月のスライドをパワーアップさせてる
• 「判断力をつける一番の方法は、自分で設計したシステムを長い間メンテすること」なのだとしたら、QAとしての判断力をつける方法は自分でテスト設計やテスト自動化に関わったプロダクトに長期的に関わっていくことなのかもと思った。
• 成長している実感があるときは、誰かに質やスピードを犠牲にしてもらっているのかもしれないということを頭の片隅に入れておいてみる。

⑤Salesforceで変わるこれからのアプリケーション開発と開発者の働き方

事前情報

14:10～14:55 13-F-5
田中 宏樹[セールスフォース・ドットコム]

世界中で急速に広まるデジタルトランスフォーメーション(DX)に適応するため、近年多くの企業でシステムの内製化を推進する動きがみられるようになりました。
また、さらなるイノベーションを促進するため、政府は小学校でのプログラミング教育の必修化を施行し、プラットーフォーマー達はより多くの人材がアプリケーション開発に参加できる環境の整備を進めています。
今後も広がり続けるデジタルトランスフォーメーション(DX)に対し、アプリケーション開発の現場はどのように変化し、技術者はどのようなスキルとマインドセットを身につけていく必要があるのか、そのような世界でSalesforceプラットフォームはどのように活用できるのかをご紹介します。

参加時メモ

• SFはみなさんの支えがあっての製品。来てくださり、ありがとうございます。
• 自己紹介
• 内容
  • システムの内製化
  • プログラミング教育
  • 誰でも開発に参加

システムの内製化

• 進化するテクノロジーとその影響
  • ユーザー企業は内製化、開発者は移動を始めている
    • ユーザー企業の25％は社内システムを内製化
    • 開発者の興味は最新技術・やりがい
    • IT人材市場+8.1％はIT企業からユーザー企業へ転職している

プログラミング教育

• 小学校でのプログラミング教育の必修化
  • 「プログラミング的思考」などを育むことが目的
  • コーディングを覚えることが目的ではない
• ビジネス的に見たら、イノベーションを起こすには不十分
  • コーディングができなくてもイノベーションを起こせるもの、誰もが開発に参加できるプラットフォーム

誰でも開発に参加

• ローコード開発環境が2024年までに65％を占めるようになる
• シティズンデベロッパー。これにより、IT人勢不足に立ち向かう
• ローコード開発
  • クリック操作とキーボード入力でアプリを構築
  • 実現のために制限がある
    • 複雑な条件を作るには、開発者には敬遠されている
    • モバイルアプリでのローコード開発は下火になった
  • ユーザー企業が業務アプリケーションを作成する際にローコード開発がフィットした
    • 教育コストが低く導入できる
  • ローコード開発のメリット
    • 開発速度の高速化
    • 学習コスト低い
    • 開発者の負担が減り、システムの品質が向上
  • ローコード開発のデメリット
    • 複雑な要件へは対応できない
    • シティズンデベロッパーにとって複雑すぎる
  • 開発言語の進化から見るローコードの位置付け
    • 低級言語
    • 高級言語
    • 軽量言語
    • ローコード
    • 開発言語は機能とユースケースを絞ることによって生き残ってきた
    • ローコード開発は、利用シーンを業務アプリケーションに絞る＆初心者の参入障壁を下げている
• SF
  • CRM
    • 一貫した顧客体験の提供
    • すぐにビジネスに適用できるようなかたちで提供
  • Customer 360 Apps
    • 信頼性の高いアプリを開発できるプラットフォーム
    • Customer 360 Appsの基本的な考え方
      • ノーコードで開発
      • ローコードで拡張
      • プロコードで対応
        • プロコード：コーディングで開発すること
      • 出来るだけ、コーディングを減らしていくのがCustomer 360 Appsの特徴
    • デモンストレーションタイム
  • これからの開発者に求められる働き方とマインドセット
• より高速なアプリ開発
• シティズンデベロッパーとの協業
• コーディングをやめない

感想

• シチズンデベロッパー（市民開発者）として事業会社やユーザー企業の色々な部署の社員がローコード開発に携わる状況は、確かにすでにきているのかも！

⑥テストエンジニアが教える　テストコードを書き始める前に考えるべきテスト

事前情報

15:15～16:00 13-D-6
風間 裕也[ビズリーチ]

システム開発において、テストは切っても切り離せない存在です。
しかし、「カバレッジを満たすために書いている」「テストコードは書いたが、本番でトラブルが多発している」となっていませんか？
実は、テストコードを書き始める前に既に勝負は決まっています。
本セッションでは、実際に例題を使って皆さんにも考えてもらいます。そして、作業ではないテストについて“体験”し“実感”してもらいます。
本セッションの体験を通じて、「開発エンジニア」「テストエンジニア」がともに考えて作り出す、一歩先行くテストの世界をご紹介します。

事前に読むと良い記事

参加時メモ

• 事前に隣のかたとのペアワークがあった
• はじめに
  • この発表の注意事項
  • 本来話したい内容の1/15くらい
  • テストコードの書き方話さない
  • 「QAチームはどういう動きをするか」ではなく、「開発者はどんなことをすべきか」の話をする
• テストの目的とは何か
  • 欠陥の検出
  • 対象ソフトウェアの品質レベルが十分であることの確認
  • 意思決定のための情報の提示
  • 欠陥の作り込みの防止
    • 実装前に行うこともある
  • テストの7原則①テストは「欠陥がある」ことしか示せない
  • 仕様誤りの修正コストは、要求仕様が1倍としたらリリース後は200倍
• 何をテストするか
  • 問題
    • 隣のかたと、ログイン画面のテストケースの考察
      • 「許容する」の話
    • 隣のかたは、あなたが気づかなかったことを知っていませんでしたか？
      • お互いにテスト内容についても議論しましょう
    • この例では1文字もプログラムを書いていません！
      • これこそが実装前にテストすることができる例
      • 総コスト削減
      • 「許容する」の話
• どのようにテストをするか
  • テストケース作成の心得
    • 「〇〇のテストをします」「ほぉ〜、それはどうしてだい？」「【理由を一言】」
    • 境界値で考える
    • 欠陥は局所的に発生する
• どうやって「ともにつくる」のか
  • QAチームは何をするの
    • システムテストレベルを見たい
      • 単体、結合、システム
      • 単体と結合は開発者でやりきってほしい
    • CheckingではなくTestingを見たい
      • Checking意図通り動くか
      • Testing何とかして製品を破壊する
    • QAチームはテスト以外も行いたい！
      • 『Agile Testing Condensed』
      • 『グーグルのソフトウェア開発』
        • 話をする、質問をする、最も強力な問いは「なぜ」
      • 開発者に一番多く投げかける質問
        • 「で、これで何をしたいんだっけ？」HowからWhatに立ち返る
        • 「ごめん、ちゃんと理解ができてないかもしれないから、この部分もう一度説明してもらってもいい？」
        • 数年後、テストの意図がわかるのは
        • そのテストを行う理由をテストケース名にする
        • ハイレベルテストケースを記載することでメンテナンス性が高い状態を保つ
    • テストの勉強方法
      • 「何をテストすべきか」『マインドマップから始めるソフトウェアテスト』
      • 「どうやってテストケースを作るのか」『ソフトウェアテスト 技法ドリル』『ソフトウェアテスト 技法練習帳』
      • 「どうやって『ともにつくる』のか」『Agile Testing Condensed』
      • 最新のテスト情報収集ならJaSSTがオススメ！
      • テストを実践して学ぶならWACATEがオススメ！

感想

• menti面白い！
• JSTQB FLをもう一度復習しよう
• 隣のかたとログイン画面のテストケースの考察をしたのが楽しかった。開発者目線が勉強になった。
• 「数年後、テストの意図がわかるのは」はQAとしてはテスト設計時に意識していこう
• 理由の言語化をする

⑦のセッションは参加せずにブースを回りました

感想

• 色々な企業のQAチームが立ち上げフェーズだったりするらしいことがわかった

⑧エンジニアと人事がともに考えるエンジニア採用

事前情報

17:25～18:45 13-D-8
【モデレーター】金山 貴泰[うるる]/てぃーびー（田部井 勝彦）[スタディスト]/伊藤 哲弥[LAPRAS]/安立 沙耶佳[ヌーラボ]/梶原 成親[ヤプリ]

競争が加熱するエンジニア採用。エンジニアと人事が今まで以上に協力しなくては、その成功は難しくなってきているのではないでしょうか。私たち転職透明化らぼは、採用担当者と求職者の間にある採用に関する情報格差を減らし、相互にとってよりよいマッチングを生むべく活動を続けているコミュニティです。
今回は採用担当者と求職者ではなく、エンジニアと人事の採用に関する情報格差をなくすことによって、組織内の採用活動をよりよくすることにつながる情報提供をさせていただきます。
採用活動の全体像をお伝えし、エンジニア採用市場の現状をお伝えし、そのうえで個別のトピックとしてカジュアル面談・ジョブ・ディスクリプションの作成に関してお伝えします。個別トピックにてパネルディスカッションを用意してあります。
ここで得た知識はあくまでエンジニア・人事の協業の一部です。ここで協業強化の必要性を感じとっていただき、持ち帰り、所属企業の人事との連携強化の取り組みにつなげていただければ、このセッションは成功です。素晴らしい同僚と仕事をできることはエンジニア個人にとって大きな喜びで、その採用に自ら関わることは組織のためだけではない得るものがあるでしょう。

参加時メモ

はじめに

• ？採用がうまくいくと、個人のどんないいことがある？
  • 給料
  • 職場体験の向上
  • キャリアアップ
• お伝えするコンテンツ
  • 求人要件定義
  • 潜在層対策
  • 選考
  • 前提理解
• 今回は語っていただくのは3つ
  • ①市場背景
  • ②ジョブディスクリプション
  • ③カジュアル面談

①市場背景：伊藤 哲弥[LAPRAS]

• エンジニアと企業、それぞれの立場から見た採用市場の実情
  • そもそも、なぜこの話をするのか
    • 求職者側から、キャリア形成の参考に
    • 企業側から、なぜ採用に参加するかの動機付けに
  • エンジニア側から
    • 超売り手市場
      • 求人倍率11倍
    • 求められるエンジニア像の変化
      • WF寄りからアジャイル寄りへ
    • 食いっぱぐれることはないが、実はそれって限定的
      • ある程度の人に集中している
        • どういう人に集中しているのか
          • 1to1は20%
          • 1to複数がかなり多い
          • 特定のスキルに集中して需要が生み出されている
          • LAPRASの53万人のDBの中で、スカウト受け取っているのは約1%
          • 企業の採用要件も特定の技術領域に集中している
  • 企業側から
    • エンジニアが採用に関わるべき背景
      • 企業は「選ばれる立場」
        • エンジニアが「選びたくなる」には
        • 社会認知学「ディスコース」言説
          • 我々の認知は、階層化されたディスコースが相互に影響を及ぼしながら作っている。
          • 自社の採用ターゲットから良いイメージを持ってもらう
    • エンジニアが採用に関わるべきメリット
      • EMやCTOを目指すなら採用スキルとして避けては通れない

②ジョブディスクリプション：梶原 成親[ヤプリ]

• ジョブディスクリプション(JD)は、チーム作りの第一歩
• ジョブディスクリプション
  • 細分化してきている
  • 「こういう人が欲しいです」
  • 欧米では社員の評価にも求められる
  • ポイント6つ
    • やっていただきたい職務
    • 言語技術、関連ツールなどのJDによく書いてあるもの
  • ジョブディスクリプションは、企業側の情報開示の一つ
    • 業務の内容や進め方について、イメージできたら最高
      • 仕事の進め方
      • 仕事で関わる人
      • 働き方と環境
      • 現在、直面している課題
      • 採用している背景など
  • 書き始めこうすると良いかも
    • 他社企業のディスクリプションをチェック
      • 言葉の使い方、何を書けば良いのかなどわかってくる
    • 採用職種のリーダーと会話する
      • どういうチームにしたいのかのすり合わせ
      • これからチャレンジしたいことや課題を書き出す
        • JDを作りつつ、チームビルディング
  • 他社のJDをチェックしてみましょう
    • Nulab
      • 今の課題と解決したいことが書いてあり、入った後のイメージがつくし求職者側から話を広げやすい
    • Studist
      • バリューと求める人物像が一致してて良いな
    • うるる
      • Howの裏側にある考え方までしっかり書いてある
  • お互いの期待値調整
  • JDを整理する過程で
    • チームの状態と理想の状態を定義することができる
    • 作ったら終わりではない。ベストは常に変わるので、都度見直すのが重要

③カジュアル面談「認識ギャップが不幸の始まり…不思議な造語「カジュアル面談」を考える」：安立 沙耶佳[ヌーラボ]

• 内定決定率100%
• カジュアル面談を効果的に行うために
  • 面談の定義を決めて候補者に伝える
  • 自社内の共通認識を作る
• 安立さん自身の経歴
  • エンジニア超足りない、エンジニア超超足りない、エンジニア超超超足りない
• 待てど暮らせど、自社への応募が来ない→カジュアル面談が始まった
• 「カジュアル面談」ってなんぞや
  • 認識がまちまち
  • 最初はWantedly？
  • ブームによる弊害
    • 興味ありますか？興味あります！志望動機は？
    • なんで僕を採用しようと思ったのですか？いやそこまでではない
• ヌーラボ
  • 8割以上のカジュアル面談が面接の前
  • 自社なりの面談の定義を決めて候補者に伝える
  • 選考フローを設計し、車内に共有する場を設ける
    • 誰でも参加可能な採用ミーティングを実施している

パネルディスカッション

• 【モデレーター】金山 貴泰[うるる]転職透明化らぼコアスタッフ
• 【パネラー】伊藤 哲弥[LAPRAS]/安立 沙耶佳[ヌーラボ]/梶原 成親[ヤプリ]
• 採用って、なぜ重要なのですか？
  • 「採用＝経営を左右するもの」
  • メンバーとして、自分たちの仲間を作る活動
• エンジニアが採用に関わったことによる効果を教えて欲しい
  • どんな人と自分が一緒に働くのか、というのを疑似体験
  • 採用されて配属される先のチームのメンバーが採用に携わることは重要
  • 採用担当自体が駆け出しという状況の企業も多い
    • 現場のエンジニアにJDのレビューをしてもらうのは大切。そうすることで実は初めて採用のスタートラインに立てるという場合もある
  • JDのレビュー、スカウトメールにエンジニアが関わっていくことで、肌感覚が合っていくかも
• 入社後にどうフォローすべきか
  • 採用時に関わっていると人間関係ができた状態でJoinできる
  • 可能ならプロジェクト1本とか、ペアプロモブプロ一緒にやったりとか
  • ふりかえりをする
  • 採用からオンボーディングまでを一気通貫でやっている
• 120分面接は、それを伝えた時点で辞退されませんか
  • 事前課題があり、辞退する人はそのタイミングでする
  • むしろ良い効果の方が多い
    • エンジニア側から「これくらいやらないと安心できない」という声があった
  • 「時間を使う」ということに関しては、現場のエンジニアのモチベーションは
    • 全員で採用するという風土がもともと当たり前だった
    • 同じマインドのメンバー
• 求職者側のスキルを確認するために有効だと感じた手段
  • 弊社の課題についての解決策を話してもらう、短期インターン
  • ハードスキル、ソフトスキル、カルチャー
  • 「構造化面接」誰がやっても同じようになる面接を取り入れているが、なかなか難しい
  • 基準を決めていて、それを超えていればその人を取ると決めている
• 内定出したい候補者の給与で希望と自社内の相場でアンマッチがあったとき
  • 候補者に合わせて変動は、基本的にはしていない
  • それよりも、弊社の相場を上げていっている

感想

• 卒論のテーマがディスコース分析だったので、懐かしかった。今まで学んだ知識がいつどう活きるか分からないのは面白いなと思った。
• 「誰でも参加可能な採用ミーティングを実施している」は面白そう！
• 給料の話、「先ず隗より始めよ」感が面白い。