概要

ログラスでは、2024 年初めに「Tech Value」を策定しました。しかし、バリューは単に策定するだけでは意味を成しません。真に価値を生み出すためには、組織に浸透させ、日常業務で活用されることが不可欠です。このセッションでは、バリューを組織全体に根付かせ、エンジニア組織の意思決定や行動の基盤として活用するために行った具体的な施策を共有します。

取り組みのポイント

1. 有志による推進チームの募集
   • メンバーの自主性とリーダーシップにより、バリュー推進の核となるチームを編成
2. 判断基準を整理したガイドラインの作成
   • Tech Value を実際の意思決定に活かすため、ガイドラインを整備し、全員が一貫した判断基準で行動できるようサポート
3. 理想状態を考える発散会の開催
   • メンバー自らが理想のバリュー活用シーンを描くことで、具体的な実行アイデアが生まれ、共通のビジョンを育成
4. 事例紹介
   • 組織朝会で具体的なバリュー活用事例を紹介し、成功体験を広めることでエンゲージメントを促進
5. バリュー発見ワーク
   • 組織朝会での簡単なワークを通じ、バリューを自らの言葉で捉え直し、日常業務への適用方法を考える機会を提供

Learning Outcome

1. バリュー浸透の実践的な手法の理解
   • バリューを単なる理念ではなく、日々の意思決定や行動指針として浸透させるための具体的な手法を知り、ご自身の組織での活用方法を検討するきっかけを得られます
2. エンゲージメントを高める推進施策のアイデア取得
   • メンバー参加型のワークショップなど、エンゲージメントを高める具体的な施策を理解し、他のバリュー活動や文化醸成活動にも応用できるヒントを得られます
3. Tech Value 活用の成功事例から得られるインスピレーション
   • 実際のバリュー活用事例を通じて、どのようにバリューが業務に貢献しているかを知り、ご自身のチームや組織でのバリュー活用の可能性をイメージすることができます

関連リンク

急拡大するログラスのエンジニアリング組織のTech Valueを策定しました

概要

SmartHRでは基本的に「スクラム」で開発を進めています。それは仮説検証サイクルを高速で回し、ユーザーニーズの変化に素早く適応しつつ、ユーザー価値を最大化するためです。

2,3年前は今と比べて、各チームが仮説検証サイクルをうまく回せているか、ユーザーが欲しいものをつくれているかを把握しやすい状態でしたが、組織の拡大に伴い、各チームのそれらの状態を把握することが難しくなってきました。
また、昔から実践しているアジャイルやスクラムに関して学ぶ社内施策の効果も組織拡大により薄れていき、アジャイルの本質的な目的の喪失、顧客ニーズとの乖離、フロー効率の低下など、少しずつ組織のアジリティや顧客価値の提供能力が低下していくリスクが高まっていると感じています。
もっと言えば、そもそも「仮説検証サイクル」とはどのような構造になっていて、どのようなスキルやアクションが必要なのかの具体は明文化されておらず、各々が暗黙知として持っている状態でした。
そこで我々はまず仮説検証サイクルを再定義し、サイクルを構成する各フェーズにおいて必要なスキルやアクションを整理しました。
そしてそれらを持ち合わせているか、実践できているかをチェックするための「アセスメント」を作成し、各開発チームで実施してもらうことにしました。

セッションではそれら過程と、アセスメント実施後のアクションや組織の行動変容についてお話します。

Learning Outcome

対象の聴衆
・プロダクト開発がうまくいっているのか否かを把握したい人
・仮説検証サイクルの解像度を上げたい人
・より良い開発や組織にしていくために行動変容を促したい人

得られるもの
・開発がうまくいっているのか否かを把握するための実践例
・仮説検証サイクルの考え方、捉え方
・開発チームへの行動変容を促すアプローチ

概要

EMは望むと望まざるにかかわらず、チームのムードメーカーとしての役割を担う立場です。管理職である以上、EMのキャラクターやスタンスは少なからずメンバーに影響を与え、その結果、チームの雰囲気や文化が形成されていきます。EMが、自覚を持ち、意識的にムードを作る覚悟を持つことで、チームの文化や雰囲気はコントロール可能なものになります。

そのためには、まず「自分の組織の理想の文化や雰囲気とはどんなものか」を整理することが必要です。例えば、以下のような理想が考えられます。

• 実装方針に悩んでいたらすぐに集まって議論し解決する
• お互いの意図や背景を理解したうえでリスペクトを持ったコミュニケーションを取る
• チーム内の会議では必ず笑顔が生まれる

このような理想のムードを作り出すのは、他の誰でもない、EMであるあなたです。理想の文化や雰囲気を形作るためには、まずそのキャラクターを自身でイメージし、行動で示していくことが求められます。そして、その姿を通じてチームに共感を生み、理想を共に体現する仲間を増やすことが重要です。

EMは理想の文化や雰囲気に向かって誰よりも率先して行動し、「こんな文化・雰囲気にしたい！」と明確に伝え続けることが求められます。時には理想に反した振る舞いには厳しい姿勢で臨み、共感し体現してくれるメンバーには心からの感謝を伝えることも大切です。

このセッションでは、EMがムードメーカーとして理想の文化や雰囲気を実現するために必要なキャラクター設定や振る舞いについて、具体的な事例を交えながら考えていきます。

Learning Outcome

• 理想のチーム文化・雰囲気を作るために必要なEMの振る舞いを理解する
• 意図的な雰囲気づくりを可能にし、チーム内外で、他部署やステークホルダーとの関係構築がスムーズになる

概要

会議を減らしたいと思ったことはありませんか？

エンジニアとして「なるべくコードを書く時間を確保するために会議を減らしたい」というのはEMであれば誰もがキャリアの中で一度は考えたことのある課題ではないかと思います。

一方で、そのような忌み嫌われるものとして会議も、効果的に使えばマネージャーにとって事業・技術・組織を前に進めることにつながる機会になると考えています。

このセッションでは、estieで行っている会議をどのように活用し、事業・組織・技術を支える強いEMチームを創っているかをご紹介できればと考えています。

具体的には、毎週の会議で組織の課題を共有し共に経験値を積む方法や、開発とアウトカムの接続を図る「開発ヨミ会」にを取り上げます。また、会議体を効果的に機能させるため、レポーティングラインを圧縮し、部門間の連携を促進するための工夫もお伝えします。

EM同士で共に学び強くなる組織運営に興味がある方の一助になれば幸いです。

Outline

1. 会議の再定義：単なる情報共有から、組織力向上の場へ
2. 事例紹介
   • 組織課題を共有し、経験値を蓄積する週次会議
   • 「開発ヨミ会」での開発と売上の接続
3. 会議体の設計・工夫
   • レポーティングラインの圧縮
   • 部門間の接続と連携強化
4. Q&Aとディスカッション

Learning Outcome

• 会議を強いEMチームを作る場にする方法
• 組織・事業・技術を担う強いEMへの登り方

概要

組織設計を行うにあたって、組織や組織内のメンバーが日々の活動から学びを得ながら成長できるか、というのは重要な要素と考えています。
組織の成長を促すために必要な三つの観点として、「フィードバックループ」「トレードオフ」「オーナーシップ」を挙げます。

• 「フィードバックループ」とは、構築 (Build) - 計測 (Measure) - 学習 (Learn) のフィードバックループが一つの組織/役割の中に閉じているかどうか、という観点になります。
• 「トレードオフ」は、特定のアクションによる成果と副作用が一つの組織/役割の中に閉じているかどうか、という観点になります。
• 「オーナーシップ」は、フィードバックループやトレードオフを生み出す活動を実施する組織/役割と、意思決定を行う組織/役割が一致しているかどうか、という観点になります。

これらの観点がケアされていない組織設計だとどのような問題が生じるか、"DevとOpsの分離" "設計チームと実装チーム" "職能分離チーム" などを反例として提示しながら、組織設計でケアすべきポイントについて紹介します。
また、これらの観点を踏まえ、筆者が所属するDiniiでどのように組織体制を変えようとしていっているかという事例についても紹介します。

Learning Outcome

• チームのミッションや組織設計、ロールの役割設計を行う際に、どのような点を意識すればよいかの観点を得られる
• 現在担当している役割やチームのミッション、他のチームとの関係について振り返り、より良い体制やミッションがないか考える上での契機となる

概要

「スーパースター」型人材と「ロックスター」型人材をご存知でしょうか。
これらの概念は "GREAT BOSS" という本の中で紹介されています。
常に新しい挑戦を求め、革新的なソリューションの考案と実装を担う人々が「スーパースター」、
安定性と確実性を重視し、担当領域における深い知見と経験をもつ人々が「ロックスター」と呼ばれています。

常に「次の大きな変革」を追い求めがちな技術組織において、
リスクを恐れず突き進む「スーパースター」と呼ばれるエンジニアたちは常に脚光を浴びています。
しかし、本当の組織の強さは、表舞台で輝くスーパースターだけで築けるものでしょうか？

慎重な判断力や安定性を重視する姿勢は、持続可能な技術組織には不可欠な要素にもかかわらず、
現代の技術組織では、このロックスターの価値が正当に評価されていないケースが少なくありません。
「保守的すぎる」といったラベルを貼られ、その本質的な価値が見過ごされています。

本セッションでは、エンジニアリングマネージャーとして「ロックスター」型人材の再評価に挑みます。
彼らが持つ「縁の下の力持ち」としての強みを掘り下げ、その力を最大限に引き出し、増幅させることで、いかにして強固な技術組織を築くのか。
私自身もロックスターとしてキャリアを描いた立場から、ロックスターが組織にもたらす価値を再考し、持続可能な技術組織を築く方法を探ります。

想定する参加者

• エンジニアリングマネージャーを目指すシニアエンジニア
• 多様な人材の強みを活かしたチームビルディングに興味のあるマネージャー
• 持続可能な技術組織の構築に課題を感じているリーダー

トピック

• ロックスターの再定義
  • ロックスターが組織にもたらす価値（知識の定着、品質の維持、文化の継承）
  • スーパースターとの相互補完関係
• ロックスターの力を増幅する
  • ロックスターとしての組織へのコミットメント
  • 安定性と成長のバランスを保つ環境づくり
• 組織の触媒としてのロックスター
  • 属人化からの脱却に向けて
  • チーム内での知識移転の促進

得られる知見

• ロックスターの特性を活かしたチームビルディング
• 組織文化の醸成
• 持続可能な技術組織を実現するためのマネジメント戦略

概要

約15年勤続した企業でインフラエンジニアのマネージャーとしてキャリアを積み、その後は採用や技術広報にも挑戦してきました。
その経験を武器にEMとして転職し、新たな組織で再び挑戦を始めました。
これまでの成功体験が、異なる組織でも通用すると信じていたからです。

しかし、異なる文化や新たなステークホルダーと向き合う中で、かつてのやり方が通用せず、過去の経験がかえって障害となる場面もありました。
柔軟な対応が求められる状況に直面し、「再現性」という点で大きな壁を感じています。

エンジニア一人ひとりの状況に応じた対応や、部門間での連携をスムーズに進める重要性を改めて感じながらも、前職で培ったやり方だけでは応じられない場面が続きました。
新しい環境で、過去の経験に頼らずに適応するためには「何が他でも活かせる共通項か」を見極める必要があると気付き、試行錯誤しながらも少しずつチームとの信頼を築く方法を模索しています。

このセッションでは、転職直後に直面した「EMとしての再現性の壁」、そして柔軟な進め方を学びながらもがき続けた日々のプロセスを共有します。
同じ境遇にあるEMや、新たな挑戦に向き合う方々にとって、新たな視点や実践的なヒントを提供できればと願っています。

Learning Outcome

・長期間いた会社での経験が、新しい環境でどこまで通用するかを見極める力
・過去の成功体験に固執せず、現場に適応するための柔軟で実践的な進め方
・即応性とフロー効率のバランスを取り、チーム全体のパフォーマンスを高める判断力
・個々のメンバーに対応し、組織の壁を越えて連携を深める実践

概要

EMとして転職をしたり、新しいチームに入ってEMとしてパフォーマンスを発揮するにはエンジニアの時とはまた違った動き方が必要になるケースが多いと思います。
私自身、2024年8月にEMとして転職し、今までとは異なる技術スタック、開発スタイル、カルチャーの会社にジョインしました。
そこから数ヶ月、キャッチアップから開発、マネジメント業務に至るまでチーム内で様々なアクションを起こしてきました。
その結果、チームメンバーから居心地が良くなった、動きやすくなったというフィードバックを実際にもらうことができ、一定の成果を感じています。

本セッションでは、私の実体験をもとに、転職してから新しいチームに入ってEMとしての成果を出していくまでの以下のような具体的なアクションやポイントについてお話します。

• EMとして成果を出すために、転職活動時に意識したこと
• メンバーからの信頼を獲得するためにやっていたこと
• 自分で手を動かして開発するかどうか
• チームの混乱期を抜けるためのアクション
• チームの機動力を向上させるための取り組み

Learning Outcome

• EMとして新しいチームに入ったり、新しいチャレンジをする時のヒント
• EMとして転職する際に失敗しないためのポイント
• 開発チームの文化形成や機動力向上の事例

概要

エンジニアからマネジャーへの転身は、転職に例えられるほど異なる世界への参入といわれます。
マネジメント業務に没頭する中でエンジニアリングスキルの低下を懸念する方や、その不安からEMへのキャリアを躊躇するエンジニアも少なくありません。

そんな葛藤を打ち砕くため、私はエンジニアかマネジャーかという二者択一ではなく、"二刀流"という選択肢を提案します。

本講演では、過去10年でエンジニアとEMを各2回経験した講演者の実践知を共有し、キャリア論・認知科学・マネジメント論を織り交ぜた二刀流キャリアの有効性と再現性について考察します。
実践の道半ばではありますが、同じ葛藤を持つ方の心に火を灯せる講演を目指します。

対象者

• エンジニアリングとマネジメントの両立に悩むEM
• EMをキャリアとして検討しているエンジニア

話そうと考えていること

1. 講演者が二刀流を意識して実践してきたこと
   • 横断的な組織課題の発見と解決、1on1や採用を通じた技術理解の深化、大型技術カンファレンス登壇機会の創出
   • Engineering Manager Meetupの立ち上げによるコミュニティ活用
2. 二刀流キャリアの可能性・再現性の考察とヒント
   • 柔軟なキャリア形成の可能性を提示する振り子モデル・キャリアラティス・計画的偶発性理論
   • 学習の転移、抽象と具体の行き来（意味波）によるスキルの同時向上

この講演を検討すべき理由

2019年の拙稿「EMになってから技術力が伸びるパターン」の少なからぬ反響を通じ、冒頭で述べた不安や葛藤が現実にあることだけでなく、提案するキャリア像に関する議論が不十分であることを私は感じました。

そして、その状況は2024年において依然として存在するとおり、本講演を通じてさらなる議論の土台を提供したいと考えています。

Learning Outcome

EMの役割を活かしながら技術力を伸ばすこと、あるいはエンジニアとしての経験をEMとして活かすための具体的な方法論を提供します。
また、振り子モデル等の柔軟なキャリア形成の視点を紹介しつつ、聴講者がキャリアの不安や葛藤と戦うために実践できる具体的なアドバイスを提供します。

概要

私たちPaymentPlatformチームは、組織を横断して複数のプロダクトに共通の決済機能を提供しています。各プロダクトは独立した組織によって運営され、それぞれが独自の目標に向かって進んでいます。そのため、PaymentPlatformチームには日々多くの依頼が寄せられます。本セッションでは、複数のプロダクトから利用されるPaymentPlatformチームがどのように開発をマネジメントしているかを説明します。

Learning Outcome

• 組織横断での優先度決定方法について
• 効果的なロードマップの作成方法
• ニーズ調査と共通機能として提供するかどうかを判断するプロセス

概要

私が BABY JOB に入社した 2021 年 11 月当時、私含めて 6 名程の開発組織でした。採用を頑張り、2022 年の夏頃、2 倍以上に拡大した組織内のコミュニケーション最適化のために役割を設け、「開発チームにおける役割 v1.0」というドキュメントを社内に公開しました。
そこからさらに組織が大きくなり、また、組織としての練度が上がっていくなかで、2023 年の 2 月頃、「開発チームにおける役割 v2.0」へとブラッシュアップしました。

※ちなみに、2025 年 1 月現在では、開発組織の人員は当初の 5 倍（6 名→ 29 名）になる見込みです。

本発表では、「開発チームにおける役割 v2.0」の社内ドキュメントを引用し、それぞれの役割を言語化した際の私の考えや想いを紹介します。

• メンバーの役割
• テックリード・プロジェクトリードがピープルマネジメント領域へ関心を持つことが重要だと考えている理由
• 実際に 1 年間運用してみて感じたこと・改善したいこと

Learning Outcome

• エンジニア組織内における役割定義の事例

概要

株式会社エンペイで代表取締役 副社長をしています。全社で50名ほど、エンジニア組織は15名ほどの規模感です
私は元々は共同創業をしたCTOでした。CTOといってもたった２人の会社なので、エンジニアとしてひたすらコードを書いてプロダクトを作る日々でした
そこから業務委託や、正社員のエンジニアを採用してチームのマネジメントをしている内にEMとしての振る舞いをするようになり、
さらに拡大していくといわゆるCTOとして振る舞うようになりました

私のキャリアでユニークなのは、さらにCTOから代表取締役 副社長になったというところかと思います。
今でも開発組織運営に責任を持ちつつ、ファイナンスや組織開発、アライアンスなどさらに領域を広げています。
これらは常に事業に貢献するためには？という１つの問いを立て、変化の激しいスタートアップの環境下で自分の職責を意識し、さらにそこから越境していった結果だと思っています
またこれらを経験する中でEM、CTOとして獲得したスキルはファイナンスなど他領域でも抽象化すれば意外と使えることを発見しました（逆に全く親和性のない領域も発見しました　笑）
事業貢献が第一と言いつつもEMのスコープで限界を感じる、ただそこから越境していく術やマインドが見つからないという問題は数多く聞き、１つのヒント、ユースケースとして参考になればと思い、お話できればと思います。

Learning Outcome

エンジニア、EM、CTOとして活躍のフィールドをさらに広げていきたい方に実例を踏まえて、自分の持つ専門性の事業への活かし方、今後のキャリアの参考になればと思います。

概要

エンジニアとして10年強のキャリアから、現職のスタートアップへの転職を機にマネージャーへキャリアチェンジし、3 年が経ちました。

現職へは開発部長として入社し、組織づくり（採用）や、予算計画、監査対応などに携わりながら、同時に、開発現場のプロジェクトマネジメント、技術マネジメントに対してもエンジニアリングマネージャーとしての役割を遂行しました。

スタートアップというそもそも変化が激しい環境のなかで、新規事業は複数立ち上がり、開発組織の人員は 3 年で 5 倍（6 名→ 29 名）に拡大しています。

これまでに心がけてきたことを 1 つあげるなら、それは、つねに能動的に変化に適応することです。
準備がカンペキに整うよりも先に変化に飛び込み、変化の波に揉まれながら最適化していく。

組織として変化に適応するとともに、必然的にマネージャーである私自身にも変化が生じています。

• 組織の課題の捉え方の変化
• 自身の業務内容、時間の使い方の変化
• 組織、メンバーに対する距離の取り方の変化
• 人事評価に対する取り組み方の変化

私がマネージャーとして、どのようなタイミングで・何を考え・実行してきたのかを振り返り発表することで、それぞれの現場ごとに異なるであろうマネージャーの在り方の一例として、その知見の共有に貢献したいと考えています。

Learning Outcome

• エンジニア組織のマネージャーに生じる環境、仕事、思考の変化を知る

概要

情報セキュリティは、現代のビジネス環境において不可欠な要素です。
本セッションでは、エンジニアリングマネージャー向けに、情報セキュリティアセスメントの基本概念とその実施方法を紹介します。
特に、GMOペパボ株式会社が10を超えるサービスを展開する中での実際のケーススタディを通じて、情報セキュリティアセスメントの目的、種類、プロセスを具体的に理解します。
参加者は、組織のセキュリティを向上させるための具体的な手法を学び、情報セキュリティリスクを軽減し、信頼性の高いシステムを提供するための基盤を築くための第一歩を踏み出しましょう。

Learning Outcomes

• 情報セキュリティアセスメントの基本概念とその重要性を理解する。
• GMOペパボ株式会社の10サービスを超える状況における情報セキュリティアセスメントのケーススタディを通じて、実践的な情報セキュリティアセスメントの手法を習得する。

概要

エンジニアリングマネージャーは、組織の経営資源を活用して成果を生み出す重要な役割を担っています。経営資源はヒト・モノ・カネ・情報と言わていますが、「カネ」に関する議論は他の要素と比較して少ないように感じられます。

このセッションでは、エンジニアリングマネージャーが身近に感じるお金の管理について初心者向けに基礎をお話しします。特に、IaaS（Infrastructure as a Service）のようなサービスインフラや開発・運用のためサービスの予算計画と実績管理について説明します。

私は、2024年年初より小さな部門における予実管理を始め、それと同時に弊社が提供する「カラーミーショップ」というECプラットフォームのインフラコストを管理するためのシンプルな見通し管理の仕組み作りを行ってきました。この実際の経験を通じて、エンジニアリングマネージャーとして不可欠なお金の基本的な管理スキルを身につけるための第一歩を提供します。

Learning Outcomes

1. エンジニアリングマネージャーとして知っておくべき、お金に関する基本的な知識を理解する
2. IaaSや開発ツールに関わる予算設定と実績管理の基礎的な方法論を学ぶ。
3. ECプラットフォームのケーススタディを通して、インフラコストの見通し管理の簡単な手法を学び、日々の運用に役立てる。
4. 学んだ内容を自身のプロジェクトやチームに適応させるためのきっかけをつかむ。

概要

私は2年ほど前にエンジニアリングマネージャーになって、エンジニアリングマネージャーの仕事とこれまでのエンジニアの仕事ととの違いに困惑しました。
例えば、評価制度を0から作って運用したり、マネージャーという立場で1on1を実施したり、チームや組織の設計をしたり...etc

未知の分野の知識が必要になるだけでなく、エンジニアリングマネージャーの仕事の対象が人や組織に移っていき、不確実性が大きくなり、成果が見えるまでの時間が長くなりました。そして小さく早く検証することの難しさを感じていました。

見るべき範囲が広くなり、果たすべきミッションも抽象的になり、解かなければならない課題が多くなりました。自分にとって未知の領域で、できる限り仮説や施策の良い選択をしたい...そう思っていました。

本や論文、web上に存在する記事で得た知識を持って挑むことに加えて、私はより現場に近い実践知を吸収し、エンジニアリングマネージャーの取り組みの成功確度を上げるためにも外部のVPoEの方に入ってもらっています。

しかし、そのような方に入ってもらったから安心...というわけにはいきません。

外部の専門家を招いた私たちが目的や関わり方のスタンスを蔑ろにしていると雑談で終わったりと実のあるプロセスに至らず、お互いにとって不幸な結果を生んでしまいます。

このプロポーザルでは、外部のエンジニアリングマネジメントの専門家を呼ぶことのメリットに加えて、専門家とどうやって関わっていったら成果に結びつく知見を引き出すことができるのかをお話しします。

Learning Outcome

対象とする方

• エンジニアリングマネージャーになったばかりの方
• 社内にエンジニアリングマネジメントの分野に詳しい方がいない方

得られるもの

• 外部のエンジニアリングマネジメントの専門家を呼ぶことのメリット
• 外部のエンジニアリングマネジメントから自分たちが知らない知見を引き出す技術

概要

もともと1チームのEMであった私ですが、役割が変わり複数のチームのEMを担うことになりました。
この際、自分の働き方に対して、単に見る人数が増えた以上の大きな変化があったと感じています。
これは、これまでは同じEMでもあくまで「人」をマネジメントしていた状況から、「組織」がマネジメント対象になったことによる変化ではないかと分析しています。

このセッションではどのような変化があったのか、以下に記すトピックについて触れながら、まさに今私が大事にしていること・意識をシェアし、「組織」のマネジメントについて考えるきっかけを提供できればと考えています。

• 個別領域への介入の物理的限界、「広く浅く」でも及ぼすインパクトを上げていくには
• 組織は作りたいソフトウェアに対して常に先行する
• 次世代リーダー育成のために
• 「人」でなく「組織」をマネジメントするとは

Learning Outcome

EMキャリアに関心がある方、組織づくりに興味がある方、EMとしての働きをどう事業・組織の成長に繋げていくかについて悩んでいる方に聞いていただきたいです。「人」と「組織」という軸でマネジメントを捉えた際にそれらにどのような差があるのかについて、実体験に基づいた私なりの意見を提示します。

概要

コドモンではアジャイル開発手法の１つであるXP(エクストリーム・プログラミング)を導入しており、XPのプラクティスの中でも中心的な位置付けにあるペアプロを重視しており、エンジニア約50名がペアプロに取り組んでいます。

ペアプロを導入した結果、メンバーのスキル向上や知識の循環、属人化の排除等のメリットがあり、変化の波を乗りこなせるチームに近づけている実感があります。

本セッションでは、1日中ペアプロをどのように行なっているのか、組織にどのような影響があったのかを赤裸々にお話しできればと思います。

Learning Outcome

・ 組織にペアプロを取り入れると何が起きるか
・ ペアプロの具体的な取り組み方

概要

このセッションでは、エンジニア採用ブランディングの強化戦略についてお話しします。
採用市場が年々競争激化する中、従来のやりかただけでは優秀なエンジニアを引き寄せることが難しくなってきています。エンジニアは、給与や福利厚生だけではなく、企業文化や技術力、成長機会を企業選びの非常に重要なポイントとしています。

この変化をふまえて、企業は自社の魅力をどのように伝えて、他社と差別化するのかが重要なポイントとなってきます。

また、採用ブランディングは長期的な取り組みであり、その結果がすぐに成果としてでるわけではありません。継続的な施策によって少しずつ効果を積み重ねて認知度や魅力を上げていくことが求められます。

本セッションでは、現在進行中の弊社iOSアプリ開発部における採用ブランディング施策を紹介し、実際に行ったアプローチや得られた知見を発表します。

採用ブランディングを立ち上げていく初期段階での学びや実践的な取り組みをお伝えすることで、今後の取り組みの参考にしていただければ幸いです。

Learning Outcome

【対象の聴衆】

• エンジニア採用で悩んでいる方
• 採用ブランディングに興味がある方
• 採用ブランディングをやりたいが、どこから手を付けるか悩んでいる方

【得られるもの】

• エンジニアにおける採用ブランディングの具体的な構築手法と初期の進め方
• 採用ブランディングの仮説検証と改善サイクルの実践方法
• 採用ブランディング施策を組織内で育てる文化の大切さ

概要

現職を含めて、これまで2社の開発チームでEMを務めてきました。

どちらのケースでも、開発メンバーが増え、チームを組織化していくタイミング（社員数が100人を超えた頃）でEMに就任しました。一方では社員10名程の頃から在籍する古参メンバーとして、もう一方では組織化するタイミングで入社した新しいメンバーとしてEMを引き受けました。

両方の立場からEMを経験したことを振り返り、私が大切だと考えることを共有したいと思います。具体的には、

• メンバーの気持ちを理解する
• 現状を受け入れる
• 課題を認識し、効果を実感できるスピードで変えていく

といったトピックについてお話できればと思います。チームが変化する中で、どのようなことに気をつけるべきか、参考になるようなお話ができればと思います。

また、具体的に効果があった取り組みについても少しご紹介できればと思います。

Learning Outcome

スタートアップの成長期において、

• 新しくチームを形成していくときの考え方
• チームの変化に柔軟に対応するためのヒント