DevelopersIO 2023 Day1 備忘録

概要

クラスメソッドさん主催の技術カンファレンスのDay1で参加させていただいたセッションの備忘録となっています。
初めて勉強会の備忘録をブログに投稿してみました。ブログの最後に参加した所感を記載しています。
DevelopersIO 2023 〜GETだけじゃもったいない、PUTしてPOSTする2日間〜

事業会社に送る、エンジニア採用始めるその前に

チョークトーク

トピック

• クラスメソッドにおける採用プロセス
• 採用プロセスにおける母集団形成の重要性
• 人事も含めた役割形成
• 現場が採用に絡む重要性

クラスメソッドにおける採用プロセス

1. 母集団形成
2. 応募
3. 書類審査
4. 面接
5. オファー
6. 入社（オンボーディング）

応募の前に母集団形成が必要になる。

クラスメソッドではDevelopersIOが貢献している。
月に2~30件の直接応募が有り、割と通している

面接

クラスメソッド社での採用面接 - 1次面接で人となりをみる - 2次面接で実技面接 - 参加者は多いときは20人のエンジニアが参加 - 社内のエンジニア同士のスキルトランスファーにも繋がる - 一回の面接で2時間ほど - 帰りの電車でオファーを出すレベルに速度感がある - 決済できる人が面接に参加していることが必須 - 事例として採用率は30%ほど。 - ブログを読んでから応募する人が多いためマッチしている事が多い。 - 会社説明会に参加していると50%ほどに - 100人ほどオファーを出して、1人ほどしか辞退されていない。 - DevelopersIOの読者ではない層は難しい - マネージャーやモバイルなどは採用が難しい

チョークトーク - エンジニアが面接しない - エンジニア3人の組織 - スキルセットの見極めができない。 - 現在は無理を言って出席させてもらっている。 - オンライン面接とオフライン面接どちらが良いか - クラスメソッド社ではどちらでも変わらなく、慣れてしまったところがある。 - 今までの知識の蓄積から受け答えを行っている。 - 基本的にオンラインの仕事であればオンライン面接で問題ないが、オフラインで仕事をする場合はオフラインでの面接は必要そう - 実技試験を行うことはオススメ - 普段どのように仕事をしていることがわかる - 実技試験を1,2週間前に伝え、どのようにキャッチアップをして寄せて来るのか、伸びてくるのかを測ることができる - その期間の間にキャッチアップをしてきたことがわかる - 逆にベテランだがキャッチアップができない場合、今後伸びない可能性がある - 社員同士のスキルトランスファーにも繋がる - 多くの人が採用に関わるメリット - テクニカルな部分や人間性以外にも、言語化できない部分がある - それをチームですり合わせていくことでチーム全体で採用したい理想像ができあがる

母集団形成から応募までの難しさ

• まず、単純に募集要項を出していないと人は来ない

• Developers IO で1年ほどブログを書いていて、バズる記事が出てから母集団形成に繋がっていった

  • 記事の本数と応募は比例する
  • サーバーサイドの記事を書くとサーバーサイドの方が応募をしてくれる
  • 検索に発信しているブログがヒットすることが多くなると、自然と携わっている技術がわかり応募に繋がる

• 採用の圧が高い発信だと引いてしまう

  • 会社のブログが「BBQに行きました」のようなものなど
  • ちょっと狙ってバズらせたい様な記事は読者に受け入れない

• 「エンジニアの組織がある」「募集をしている」ということを表に出していくことが大事

  • お客さんの情報は出さずに、普段使っている技術を発信していくこと

• 会社説明会は参加人数が少なくても、やった方が費用対効果が高くなる

  • 参加してくれた方と話すことで、どのようなことを求めているのかがわかってくる

• 事業会社だと会社の事業と技術が結びつきを説明するところから始まり、採用が難しい

  • AWSのコミュニティなどで発信を行うことで、どういった技術を使用しているかを公開することが大事
  • エンジニアの確固たる立ち位置を説明できないと難しく、説明できないと外注で良いという話になってしまう
    • キャリアパスや位置づけやどんなコアなことをやっているかを説明する

• 採用もセールスやマーケティングと似たようなことをしている

  • 最低限の福利厚生があることをアピールできればMVPとして成り立つ
  • 応募者にとって魅力的に見えるような必要な発信を行う
  • この会社でどんな成長ができるのかなどを更に追加してMMVPに進化させる

• Developers ioは母集団形成に1~2年で効果が現れた

  • さらに数年立つとDevelopers io経由での応募が増えてきた
  • ブログは採用のためにやっていたわけではなかった

• 面接の時に会社説明だけでなく福利厚生の話ばかりだと、誤解されてしまいミスマッチが起きてしまう

  • 事業やドメインの話をすることは大事

今こそ考える、本当に「AWSを使いこなす」とは？

AWSの歴史

• 2004年のSQSが最初のリリース
  • まもなく20周年
• 現在は200を超えるサービスを提供している
• 2020年から2,000を超えるアップデートが出ている
• 第三者機関のGartnerの調査ではAWSはクラウドを牽引するポジションになっている
• 政府のクラウドファーストの動き
  • 2018年にクラウドバイデフォルト原則に指定
  • 2021年にガバメントクラウドの対象クラウドに。

クラウド利用目的

• デジタルトランスフォーメーション
• TCO削減
• 運用負荷軽減
• BCP対策
• SLAの改善
• 開発の生産性工場
• グローバル展開
• サステナビリティ

AWSを使いこなせていますか？

「使いこなしている」とは？

• AWSののサービスを理解している
• AWSに構築したシステムを管理・運用できている
• 最新情報をキャッチアップできている
• 最新の機能・サービスを導入できている

大量のサービス/アップデートに振り回されていないか？

• 陥ってしまいがちな症状
  • 最新情報をキャッチアップしているが、なかなか導入が進まない
  • 最新機能を導入したが、
    • 運用が楽にならない
    • システムが複雑化している
    • サービスレベルが向上しない
• なぜなのか振り返ってみる
  • Non-Techが置き去りになっていないか
    • テクニカル以外の部分
  • 正解を求め過剰に時間をかけていないか
  • 目標が不明瞭なママ新機能・新サービスを導入していないか

Non-Techが置き去りになっていないか？

• マインド
  • 「正解」があるものと思い込み、失敗を避ける
  • 完璧を目指す、過剰な非機能要件
• プロセス
  • 机上での検討/設計を尽くしてから実行
  • 初期の計画に縛られる
• 体制
  • 責任ごと丸投げ

「正解」を求め過剰に時間をかけてしまう

• 唯一の「正解があると思いこむ
• 間違いを踏みたくない
• オンプレミス時代と同じ、リスクの捉え方になってしまう

目的が不明瞭なままトレンド技術を採用

• なんとなくトレンド技術の採用
  • 学習コストが増え、扱える人が限定され属人化
  • 担当者が抜けてブラックボックス化
    • 自動化はできている、なんとなく動いている、しかしブラックボックス
• 新機能が出ると「やらなくては」と思ってしまう
  • 新機能は無条件にいいものと思い込んでしまう
  • 技術トレンドから取り残される恐怖感

全てのAWSだけでやろうとする

• AWS以外の選択肢を排除してしまう
  • サードパティー製品、SaaS、他社クラウド、オンプレミスなども検討する
  • AWSだけで完結させることに固執しない
• AWSは幅広い機能を安価に提供してくれる
• ただし、サービス間の連携にインテグレーションが必要なことも

なぜこうなった？

• AWSを導入した目的を思い出すことが重要

• 重要なのはビジネスへの貢献

  • 新サービス/付加価値の提供
  • 業務の効率化、コスト削減
  • サービスレベル向上
• これらに繋がっているかを常に意識し、見えるようにする
• ビジネス貢献に即したメトリクス/指標が必要
  • システムの稼働率、SLA/SLO、リリース速度/頻度
• 稼働率、SLA/SLO、リリース速度/頻度、など

どのように向き合うか

• 現実を受け入れる
• 割り切るところは割り切る
• 全部やろうとしない
• 学びながら進める

AWSは難しくなっている

どう難しくなっているか - EC2 - 数クリックで開始可能 - しかし、EC2の立ち上げには30以上の設定項目が存在する - データベースサービス - DBと呼ばれるサービスをとっても10以上のサービスがある - どのサービスが適切かはワークロード次第

• AWSの多種多様なアップデート

  • 広くメリットを提供するアップデート
    • 新しいインスタンスタイプが登場することなど
  • 「選択肢の提供」であるアップデート
    • 例えばEC2への接続方法の選択肢が新しく増える。e.g. EC2 Instance Connect
    • それぞれメリット/デメリットがあり、どれが最適なのかは要件次第

• あるユーザーの話

  • 「我社ではサーバーレス（Lambda）は導入しない」
    • 「委託先、エンジニアの採用、育成を考慮するとLambdaなどのサービスを使い続けることは最適解ではない」
    • 一般的にLambdaはコストが下がるが、人的コスト（採用・育成・教育）が上回るという判断

• スモールスタート

  • 小さく始める
  • 導入コストが下げられる
  • 技術的ハードルが下げられる
  • 廃棄が容易になる
    • 辞めることができるというのは大きな選択肢
  • 意思決定プロセスの改善に繋がる

• 組織・システムによって最適解が変わってくる

• 同時に、今日の最適解が明日もそうとは限らない

指針がほしい

• ジェフ・ベゾス「今後10年の変化について頻繁に聞かれることになるでしょう。しかし逆に「今後十年間に何が変わらないか」という問いが正しい」
• 10年前から変わっていないものとは
  • 固定資産からの置き換え
  • TCOの削減
  • サイジングからの開放
  • アジリティ・スピード・イノベーション
  • 差別化すべきことに注力できる
  • グローバル展開
• 蓄積されてきた知見「AWS Well-Architected Framework」
  • システム設計・運用の"大局的な"考え方とベストプラクティス
  • 6つの設計原則から成り立つ
• 特に注目したい項目
  • 運用上の優秀性
    • 小さく始める
    • 最初から完璧はない
    • 障害が起こる前提
  • 信頼性
    • 実体験に基づく
  • パフォーマンス効率
    • 価値創造に注力
    • 検討より実践
  • コスト
    • 顧客に集中

10年後も変わらず求められるスキルを優先して学ぶ

• AWSのサービス仕様 < 普遍的な技術
  • AWSのサービス仕様
    • 調べたい時に見れば分かるようになっている
    • 頻繁なアップデートで常に変化（10年後はどうなっているかわからない）
  • 普遍的な技術
    • サービスの根底にある思想・原則
    • 基礎となるIT知識（TCP/IP、HTTP、SQLなど）

サービスも外部もうまく使う

• ユーザー
  • 事業戦略/目標の策定
  • 素早い意思決定と実行新たな事業価値の送出
• クラウドサービス
  • 多種多様なサービス

まとめ

• AWSは長い歴史の中で継続的に新機能/新サービスを提供してきた

• その多くは「選択肢の提供」

• アップデートに振り回されはならない

• ビジネスの目的・目標を明確にし、多様な選択肢から使いこなす

40分1本勝負、VPoEハマコーvs20人の悩めるエンジニアリングマネージャー

チョークトーク

• ハマコーさんのマネジメント経歴

  • クラスメソッド入社後1年毎にマネジメント領域/業務を遷移している

• 皆さん今日は何を期待してここに来ていますか？

  • 想像「悩めるエンジニアリングマネージャ vs ハマコーさん」
  • 今回は登壇者・参加者それぞれの経験を共有し、気づきを得る場にしたい

• エンジニアリングとマネジメントの根本的な違い

  • マネジメント（人）に関わる課題解決は組織コンテキストに依存する部分が多い

• 一口にマネジメントと言っても色々ある

• 今回のチョークトークのネタ候補
  1. チームのコミュニケーション改善
  2. フィードバックと評価制度
  3. チームのオーナーシップを高める方法
  4. 技術的な決断とリーダーシップ
  5. リモートワークとエンジニアリングマネージメント
• 会場で投票
  • 4と3について話すことに

技術的な決断とオーナーシップ

エンジニアリングマネージャーは技術的な決断をしなければならないことも多く、その決断はチームのパフォーマンスに大きな影響を与えます。
どのようにして最適な技術的な決断を下すべきでしょうか？
また、技術的な決断を通じてどのようにリーダーシップを発揮できるでしょうか？

体験談 - SIerはお客さんの希望を聞くが、何でも良いと言われたら適切な選定を行う - 技術選定をしてもお客さんが認めず、ひっくり返されることがあった - チームのメンバーにはお客さんの意見を受け入れてもらうよう、中長期的な視点でお客さんとの関係性の維持を務める - エンジニアが決めたものを、EMとして認める/ケツを持つ

マネージャーがエンジニアリングの最前線に立っていないこともあり、どうやってマネージャーとして責任を持つか - リバートできるかどうかを考える - とりあえずやってみようでいいならイケイケでいいが、負債が残るようであれば考える - k8sを導入する理由がカッコイイからなことがある - 最終的に負債になっていく - ケツを拭くのはマネージャーしか居ない - 決める時にマネージャーの心理的安全性やついてきてくれるのかの信頼性が心配になる

チームのオーナーシップを高める方法

「メンバーにはオーナーシップを持ってもらいたいけど、なにか企画しても全く手が上がらない…」という問題は、チームのエンゲージメントやオーナーシップについての問題です。
エンジニアリングマネージャーはどのようにチームのオーナーシップを高めることができるでしょうか？

• 個人のやりたいことと組織のやりたいことが当てはまっているかを意識している
  • オーナーシップは内発的動機から生まれるもので、組織との相違がストレスになってしまう
  • 組織で施策をうってはいるが、モチベーションが上がってくれない
• オーナーシップは自分のチームでの役割でどうやって成果を上げれるか
  • SIerなどだと技術的成長が見込めないこともあるが、再生産に向いているという面がある
  • 個々人によってポートフォリオを作れるようにする
• 人が育たないとよく言うが、育たない環境になっていることがある
  • 勝手に育つ人を勝手にオーナーシップを持てるような環境作りから広げる
• オーナーシップを持つのが苦手なので、得意そうな人へオーナーシップを移乗した
  • 自身の声が大きすぎたためうまく行かなかった
• モチベーションを持たない人にモチベーションをもたせることができればノーベル賞
  • 全体のモチベーションを上げる施策として、オーナーシップだけでなくフォロワーシップを育てる
  • フォロワーシップが育った人にオーナーシップをもたせる
  • オーナーをいじめないことが大事で、オーナーの心理的安全性が失われ辞めてしまう

# 防衛への一歩！AWSアカウントを不正利用から守るための必須防止対策ナビ

セッションのテーマ 「自分の身は（アカウント）は自分で守ろう」

AWSアカウントの不正利用とは？

• 第三者がAWSアカウントの認証情報を盗んだり、セキュリティの脆弱性を付いてAWSリソースに不正アクセスされること

• 悪影響

  • 多額のコストが要求される
  • サービスの品質が悪化する
  • 法的・規制上の問題が生じることがある

• ステークホルダー全体に悪影響

  • AWS利用者：多額のコスト請求
  • AWS：無駄なリソース消費
  • エンドユーザー：サービス利用不可

事例

1. アクセスキー漏洩
   • ビットコイン採掘用のEC2を大量に起動
   • 多額のAWS支払いになってしまう
2. IAMユーザーのパスワード流出
   • MFAが設定されていない場合、総当たり攻撃などでマネージドコンソールにアクセスされてしまう
   • S3のデータ漏洩やRDSやEBSのスナップショットから復元されてしまい情報漏洩

3. アプリケーションの脆弱性をついた攻撃

   • S3バケットの誤った公開設定
     • データ漏洩
   • SSHポート開放
     • EC2インスタンスへの不正アクセス
   • WAFの設定ミス
     • 個人情報漏洩
     • WAFを利用していても設定が誤っていると攻撃されてしまう

4. 攻撃の加害者になってしまう

   • AWSアカウントを不正利用され、他のAWSに大量アクセスの攻撃に使用されてしまう
   • 結果、アカウントの停止や他のアカウント所有者から訴えられることも

AWS不正利用対策の進め方

• AWSからの通知が受け取れるように設定されていますか？
  • 通知を受け取れるようにしていないと、不正利用の通知（メール）を受け取れない。
  • 不正利用された場合、AWSから通知が送られてくるため対応する必要がある。
  • 通知は2箇所設定でき、プライマリだけでなく、セカンダリにメーリングリストを追加しておくと良い
    • メールを確実に受け取れるよう、フィルタなどで確実に受け取れるようにすると良い

不正利用が発生した場合の対応

1. 臨時対応
   • すぐにアクセスキーを無効化・削除する
   • 通知を受け取ってから素早く調査を行い、対象のアクセスキーを無効化する
   • 調査観点
     • IAM認証情報レポート
     • CloudTrail
     • Trusted Advisor
2. 必須防止対策
   • セキュリティサービスの有効化
     • CloudTrailの有効化
       • ログの保管期間を延長することがオススメ
     • Configの有効化
       • リソースの変更が多い場合はコストが高くなってしまうため注意
       • リソースの記録対象を指定することが可能
     • Security Hubの有効化
       • アカウントがセキュリティ基準に則っているかの確認が可能
     • GuardDutyの有効化
       • サマリーダッシュボードがリリースされ
   • IAMの棚卸し・アクセスキー漏洩防止のソリューション
     • IAMの概念を知ることがセキュリティ対策には必須
     • 不要なIAMユーザー・アクセスキーの削除
       • 削除基準
         • 90日以上ログインされていない
         • 退職者のIAM
     • IAMユーザーのパスワードを強固にする
       • NISCに準拠する場合、パスワードは大文字小文字10文字以上
     • IAMユーザーのMFAを必ず有効にする
       • MFA認証が設定されていない場合、AWSリソースを操作させないという設定も可能
     • 不要なIAMロールを削除
       • 90日以上利用されていない
       • 一時的に作成したものが残っている等
   • git-secretsの導入
     • AWSアクセスキーをGitリポジトリに混入させないためのツール
   • IAMユーザー・ロールに強力な権限を与えない
3. Security HubによるAWS環境のスコアリング
   • スコアは100%にしましょう
     • 修復手順に沿って対応を行う

4. GuardDutyによる脅威検知の暫定対象作り

   • GuardDutyは有効化しただけだと通知を受け取ることができないため、通知を有効化する
     • Slack連携もおすすめ
   • 脅威を検知した際の対応方法
     • 基本的には検知したイベントは全て対応する
     • 通知が多すぎる場合
       • 抑制ルールを作成することも可能

5. 恒久対応

   • セキュリティ管理体制の確立
   • アカウント発行フローの整備
   • アプリレイヤーのセキュリティ管理

具体的な対策方法

ZennとDevelopersIO 運営者が語る技術記事執筆の魅力とその裏側

本日クラスメソッド創業20周年

DevelopersIOとは - 「すべての人々の創造活動に貢献し続ける」をアウトプットで体現 - 執筆者が良い執筆体験と価値を見出すプラットフォーム - 入社から卒業まで執筆可能 - 歴史 - 2011年7月、ローンチ - 2013年6月、iOS 7リリース記事で70本記事掲載 - 2017年7月、掲載記事1万本突破 - 2018年3月、AWS Partner Network Special Award of the Year 2017受賞 - 2023年4月、掲載記事4万本突破 - AWSの技術記事が約半分、アクティブな投稿アカウント数は800

Zenn - 「知見を共有するエンジニアに対価を」をコンセプトとした技術情報共有コミュニティ - 3つの投稿形式 - scrap - articles - book - 歴史 - 2020年9月、catnoseさんの個人開発サービスとしてZennがリリース - 2021年2月、catnoseさんとZennがクラスメソッドにJOIN - 2021年7月、チームを組んで開発・運用 - 数字で見るZenn - 月間PV、900万 - 合計公開記事、8万 - 合計登録Publication、380 - Zenn Bookがきっかけで集英社から商業出版の事例も

技術記事執筆の魅力とは

• 技術記事執筆の先にあるもの
• 知見・試行錯誤の整理
  • うまくいったこともうまくいかなかったことも知見になる

• 学習の高速化、仕事の精度向上

  • ゼロからよりもスナップショットとの差分を取るほうがはやい
  • 記事を書くことで新しい仕事を早くできるようになる

• オウンドメディアの効果とは

  • スキルアップと社内外の認知を後押し
  • 書き手の成長
  • コンテンツマーケティング
    • 良い記事・新しい記事をいち早く多くの人へ届けるマインド
    • コンテンツの注目度に応じてイベントへつながるなど
  • 顧客サポート、技術支援の一環
    • 「お客様にURLをご案内」というオペレーションは日常的にある
    • 記事を書いた上で提案をすることもある
  • 社内外の名刺に
    • 自己紹介から「この人といえばこの記事」の認知まで
    • DevelopersIOではペンネームを許容しているので、Slackで検索できない問題も...

アウトプットの価値

記事を書き続けてもらうために

• DevelopersIOでは「あまり決めない」ということが決め事
  • 決めていないもの
    • 必要以上の機能制限・書くべきテーマ・厳格なノルマ・ペナルティ
  • 周知・提供しているもの
    • Disをしないという思い
    • 執筆Q&A、修正依頼用Slackチャンネル
    • 社内デザインチームとの連携
    • など

• Zennの場合は個人に委ねている

  • 執筆者体験の向上に努めている
  • 3種類の投稿形式でアウトプットをサポート
  • 2種類の執筆方法を用意
    • Webエディター・ローカル（GitHub連携）
  • 統計機能（β）で執筆状況を可視化
  • Publicationでチームメディアの執筆をサポート

• 個々人のモチベーションの持ち方はまだまだ未知数

新鋭トピック・キーワード振り返り

• Zenn
  • ChatGPTの関連のキーワードでの検索が多い
  • 「使い方」系が盛り上がって読まれる傾向
    • Twitchで有名人が記事を共有したことがきっかけで、DDoSかと思うレベルにバズった。
• DevelopersIOの"ChatGOT現象"
  • ChatGPTブームと同じ期間（今年の2~4月）に月間PV2割増
  • 今年の2月週礼で社長から「(ChatGPTの)アウトプットしよう」の呼びかけ
  • 移行加速度的に増えてAPI活用、言葉遊び、社内ルールｓ
  • OpenAI/ChatGPTConsulting提供中

新鋭トピック・新しい波がくるときは

• メディアとしてどう受け止めるか
• DevelopersIOは「波を作る」「波に乗せる」の2択
  • 見返りを度外視してまずはやってみる＆続けていく
    • AWS技術記事にベットしたのは社長と社員1名
    • メインの事業はべつにあった中黙々とアウトプットした
  • アウトプットの選択と集中
    • 組織で色んな角度から網羅的に取り組む
    • 後発だったiOSアプリ事業のブーストにと部が一丸となった
    • 新iOS発表に合わせ200本を一挙っ公開
  • 組織としてバックアップする
    • ChatGPTの波には有償アカウント・APIを会社がサポート
• Zennは波を作れないため、結果的に波が来る
  • 「やってみた」が広範囲に波及するとき
    • 先駆者が「はじめかた」系の記事を書く
    • 多くの人が「やってみた」結果を共有する
    • 有名人がこのトピックについて言及する
    • おおきなうねりになる
  • 運営としては波に敏感になり、インフラの増強などを行う必要が出てくる

今後

• DevelopersIOの今後
  • 12年の蓄積と付き合いながらグロース
    • 改善欲求と「800アカウント4万本が乗るWordPress」の壁
  • 組織の成長に合わせた多様なメディア化
    • 現在5カ国、エンジニア以外の記事掲載
  • 良い記事を書き続ける働きかけ
• Zenn
  • クラスメソッドにJOINしてから安定稼働を取り組んできていた
  • 今後はZenn内の回遊を増やし、コミュニケーションを促進したい
  • ベテランエンジニアにも記事を書き続けてほしい
    • 記事を書かなくても仕事ができてしまうような層
  • マネタイズ
    • 場を提供し続けるために自分たちで稼ぐ仕組みが必要

まとめ

• 発信は成長の最短ルート
• プラットフォーム側で機能や精度的な支援はできる
• 執筆者個人のモチベーションｘサポートが継続のカギ
  • アウトプットを続ける本人のモチベーションをブーストさせることに苦心
• メディアを続けるのは大変
  • エントリーお待ちしています

所感

1社のオフラインイベントとしてここまで大規模なものを開けることに対して、実際に会場に行きクラスメソッドの技術力と発信力を改めて痛感しました。
どのセッションでも"現実的な問題"に対してどう向き合うのかについて明日から実践で使えるプラクティスばかりで、普通のカンファレンスとの良い意味での違いを感じました。
また、オフ会的な一面も楽しませていただきました（業界が狭い！）