トーク

概要

チームに必要十分なドキュメントを準備するのは非常に難易度が高いタスクです。

メンバーが個々に知見を残していくボトムアップのアプローチには、必要な情報が網羅されていることを保証できないという欠点があります。一方でトップダウンのアプローチを取ると、メンバーの工数を確保し参加を促すのが難しいという課題があります。

さらに、ドキュメントの質の担保や作成したドキュメントの陳腐化などはいずれのアプローチを取っても避けられない問題です。

しかし、我々のチームは一定の質を担保しながら必要十分な情報が揃ったドキュメントを企画から1年近くかけて作り上げ、その後も継続的にメンテナンスを行っています。

本セッションでは、ドキュメント構築の過程を追いながら以下の内容について説明していきます：

• ドキュメントの全体構成・文書作成ガイドライン・テンプレートの策定
• ドキュメント作成およびレビューのパイプライン
• 文書の陳腐化を防ぐためのしくみと活動

Learning Outcome

対象

チームにドキュメントの必要性を感じているが、どのように進めればよいか悩んでいる方

得られるもの

組織的なドキュメント作成に関する以下のノウハウ：

• ドキュメントの全体構成をどのような観点から考えるか
• 読まれることを前提にテンプレートをどのように設計するか
• 記事の作成とレビューを行うためのガイドラインをどのように決めるか
• 記事の作成をどのように手分けして進めるか
• 記事の陳腐化をどのように防ぐか

概要

令和トラベルは、2022年に「NEWT（ニュート）」をコアローンチして以来、順調にグロースし、前年比300%超えの成長率を超えるプロダクトに成長しました。
一方で、さらなる進化を遂げるため、プロダクト開発組織を1年間で約2倍に急拡大させる必要が出てきました。
こうした背景をふまえ、組織基盤をあたらしく構築するため、プロダクト開発組織のスクラップアンドビルドに挑みました。

多くのスタートアップでも同様に、非連続な成長や現在の成果を超える大変革を求められると思います。
このセッションでは、組織のスケールをみすえたプロダクト開発進化のために行ったスクラップアンドビルドをエンジニアリングマネージャーとして振り返り、具体的な取り組みや、変化の過程で学んだことをお話しします。また組織再編や変化を起こして、どのような効果が得られたのかについて振り返ります。

主に以下のようなテーマを軸に紹介します。

• 自己組織化を目指す上で考えたこと
• スケールアウトを目指すために設計した目標設定のポイント
  • 目標・指標の力学
  • 期待値調整
  • モニタリングと振り返り
• 権限委譲と組織分割の工夫

Learning Outcome

非連続な成長のための意思決定を求められる方のヒントになるようなセッションにしたいと考えています。

• スケールアウトを目指す上でEMとして意識すべきこと、気をつけるべき観点
• 組織基盤やプロセスを見直す際のポイントや直面した障害から得た教訓
• 目標設定やモニタリング方法のポイント

概要

EMとIC(Individual Contributor)を行き来した経験から、あえて他責思考で問題を捉えることで自責思考では至りにくい、双方に寄り添ったアプローチを考えてみました。
異なる役割を通じて得た新たなリーダーシップの観点や、効果的なチームビルディングの手法、さらに短期間での信頼構築のための具体的なプロセスを具体例を交えながら紹介します。
この変遷を通じて得た成功と失敗の教訓を詳しく解説し、キャリア再設計の理由とその意義について深く掘り下げます。
目次

• ICとしてEMに求めるもの
• EMとしてICに求めるもの
• 詳細をどこまで把握する必要があるか
• キャッチアップの手法
  • 勉強会開催
  • モブプロ
  • 輪読会

Learning Outcome

• エンジニアリングマネージャー（EM）やEMを目指す方は、異なる役割を経験することによって得られる新たなリーダーシップの視点を理解し、それをどのように実践に活かすかを学ぶことができます。
• ICに戻ることを検討しているEMや、新たにEM職を目指す方は、再びEMの役割に戻る際の具体的な課題（例：チームメンバーとの関係構築やリーダーシップスタイルの調整）に対する事例を通じて、どのように克服すればよいかを学ぶことができます。
• 現役のエンジニアリングマネージャーや新たな役割への移行を考えている方は、短期間で信頼を築くための具体的なアプローチを学び、それを実践に結びつける方法を探ります。

概要

本セッションは、組織文化が曖昧な言葉になってしまっているとメンバーに思われていないか懸念しているマネージャーに向けて、組織の質を明確に制御可能にする方法を解説します。

観察や実行、評価することが困難な「文化」に介入するのではなく、観察/実行/評価が明確な行動(プラクティス)の集合を対象にすることで、ふるまいをエンジニアリングを可能にし、結果として上質な組織文化を構築します。

様々なメンバーがよりよく働ける状況を整え、顧客に優れたプロダクトを提供するために、組織文化というコンセプトがよく使われます。しかし、この組織文化は観察が難しく、よくするための方法や、評価も簡単ではありません。

下記に答えることは容易ではありません。
・何が組織文化で、何が組織文化ではないのか(観察)
・どのように質を上げるのか(文化としての実行方法)
・その質の良し悪しをどのように評価するのか(評価)

プラクティスというコンセプトがあります。望ましい状態を引き起こす繰り返される行動といえるものです。

たとえば、挨拶は、会社の出退勤や、他部署の人達とのミーティングで行われます。人が境界を通る際に行われるもので、一日当たり少なくとも2回、実施時間としては数秒ほどで行われる行為です。1on1は会社によっても実施は異なりますが、メンターとメンティーの関係にある二人が毎週30分から1時間行われる行為です。

こういった活動の集合が組織のふるまいになります。あいさつといった些細な行為も、人によって気持ちよいものもあれば、そうでないものもあるでしょう。質があるということです。質の良し悪しを理解するとうまくできるようになります。

このように、社内で行われるより良い状況を生み出すために行われる活動を、質的に制御可能なエンジニアリング対象として捉え、その行動の観察/代替策の実行/評価を通すことで、組織集団としてのふるまいを短期間で改善する方法を解説します。

Learning Outcome

　・好ましい状況を引き起こす活動の観察できるようになる
　・さまざまな活動を組織の全体性の観点から整理できる
　・些細な行為を含めて評価できる
　・行為の改善を実行できる

概要

我々のチームでは前期、OKR（Objectives and Key Results）のフレームワークを使って目標設定を行いました。

なぜOKRを始めたのか？　それはOKRの導入によって、開発部が抱えていた下記の課題に対処できると考えたためです。

• 開発部目標が事業部目標とリンクしておらず、事業部としての貢献度が見えにくい
• 開発部目標が単なる開発チームのToDoになっており、全くワクワクしない

しかし、会社としてOKRは導入されておらず、導入される予定もありませんでした。
そこで我々は開発部のみで、まずは「小さく」OKR導入に踏み切ることにしました。
初めてのOKRということもあり導入ハードルは高かったものの、結果的にはOKRは機能し、最後はメンバーから「やってよかった」との声も貰うことができました。

そう、小さく始めたOKRは成功したのです。

本発表では我々がどのようにチームにOKRを導入し、どう成功に導くことができたかをご紹介いたします。
この発表を通して、EMのみなさんの目標設定の一助になればと存じます。

コンテンツ

• なぜOKRなのか？
  • OKR導入前の課題
• ゼロからどのようにOKR導入したか
  • OKR研修・マネージャー陣のOKRディスカッション
• やってみてどうだった？　OKR振り返り
  • 良かったこと・課題に感じたこと・改善したいこと
• OKR運営のコツ
• OKRを成功させるためのポイント

Learning Outcome

対象者

• 目標設定が苦手なマネージャー
• 目標設定がマンネリ化しているマネージャー
• 目標にワクワクを感じられず、目標が退屈だと思っている方
• MBOによる目標設定に限界を感じているマネージャー

Outcome

• OKRを小さくスタートできるようになること
• OKRを上手に運用できるようになること
• 目標および目標設定プロセスを、ワクワクする楽しいものにすること
• 目標設定を活性化し、チームのモチベーションを高めること

概要

長年テスターやQAエンジニアとして従事してきた私が、初めてエンジニアリングマネージャーとなった経験を振り返ります。この新しい役割でどのような変化や挑戦があったのかを探ります。

Learning Outcome

期待する参加者

• QAエンジニアおよびQAマネージャー
• QAエンジニアをチームに迎えるエンジニアリングマネージャー
• マネージャーになることに躊躇している方、あるいはそれをサポートしたい方
• マネージャーとしてのキャリアに興味がある方

Outline

1. 経歴

   • プログラマー5年、テスター10年、QAエンジニア6年（時折スクラムマスターも担当）、エンジニアマネージャー半年
   • 基本的にリモートでの業務

2. なぜエンジニアリングマネージャーになったのか

   • テストマネジメント全般を担当していたため、メンバー評価が加わる程度と考えていた
   • 今規模の会社でマネージャー経験を積んでみたかった
   • 新しい視点を求めて見えない世界（視座）を探索したいという探究心

3. ピープルマネジメントに関する考えと課題

   • メンバーを最大限に活躍させたい
   • 自分が今より多くのメンバーを管理するには限界を感じている
   • ジュニアメンバーを迎えるための自分のキャパシティに不安がある

4. QAエンジニアとエンジニアリングマネージャーの違い

   • 評価をすること
   • プライベートチャンネルでのコミュニケーション
   • 変わらない点: テストマネジメント全般

5. QAマネージャーとエンジニアリングマネージャーの違い

   • QAエンジニア以外のエンジニアを見る可能性もあると考えている
   • 組織内に閉じた話はせず、エンジニアリング全般の中でQAに関わる
   • Automation、 CI/CD、インシデント などに関することをエンジニアと進めることができる
   • 他職種とのグレードや評価比較が可能

6. エンジニアリングマネージャーとしての気づきと課題

   • 褒める機会や意識が増えた
     　 自分のメンバーに対して
     　 他カンパニーや他職種のメンバーに対して
     　* 専門外の領域の学習が必要

7.QAマネージャーとしての課題

• 手を付けられていない領域への取り組み

概要

delyは創業以来、「国内No.1レシピ動画プラットフォーム：クラシル」や「国内No.1お買い物サポートアプリ：クラシルリワード」といった、日々の生活を支えるインターネットサービスを次々と立ち上げ、急速に成長を遂げてきました。しかし、その成長の裏には、開発組織として乗り越えるべき多くの挑戦と学びがありました。

本セッションでは、delyの開発組織がどのように変化し、急成長によって生じた課題とどう向き合ってきたかについて共有します。サービス拡大が開発チームに与えた影響、失敗からの学び、現在取り組んでいる課題とその解決策を掘り下げ、聴衆が自組織の成長に活かせる具体的な知見を提供します。

Learning Outcome

対象の聴衆:

• 開発組織マネジメントに関わる方

得られるもの:

• サービスの急成長が開発組織に与える影響を理解する
• 失敗から学んだ組織改善の方法を知る

概要

開発組織に生じる組織課題に向き合うEMは、事業や開発組織のグロースになくてはならない存在です。
日々組織と向き合い、抽象度の高い課題を解きほぐすことが求められるEMですが、殆どのEMが「コードを書くこと」で事業に貢献するプレイヤーとして、キャリアをスタートさせていることでしょう。

ではプレイヤーは、いかにしてEMへとステップアップするのでしょう？

本セッションでは、私が開発組織専門の人事・DevHRとして、EMの方々と協力しながらエンジニアの採用・育成に取り組む中で見えた、「プレイヤーからEMへのステップアップ条件」についてお話をします。
私自身も、いち開発者からEMと同じマネージャー職であるDevHRへとキャリアチェンジする過程で数多くの失敗をしてきましたが、その経験談も交えながら「(EMを含む)マネージャー職が獲得すべきマインドセットと、それらの獲得過程」を3つ紹介し、EMを目指すプレイヤーのみなさんへステップアップの足がかりとなる知見を共有します。また、EMのみなさんにはマインドセットの獲得過程から「マネージャー層育成の再現性を上げる」ためのヒントを持ち帰っていただければと思います。

マネージャー職が獲得すべきマインドセットと、関連する失敗談

1. 仕事を委譲し、チームを育てる
   → プレイヤー時代に「背中で見せればOK」と1人で突っ走り、メンバーが去ってしまった失敗
2. 役割と想いを言語化して価値を見出し、伝える
   → JD・スカウトメールを曖昧な文言で書いてしまい、面談・選考応募が獲得できない失敗
   → 内定を出した候補者へのアトラクトが上手くいかず、内定承諾が取れなかった失敗
3. なすべきことを自ら定義し、向き合い続ける
   → 採用と組織開発の業務を周囲に頼ることなく抱えすぎてしまい、パンクしかける失敗

Learning Outcome

想定する聴者

• EMへとステップアップしていきたい、プレイヤーやプレイングマネージャーの方
• マネージャー層の育成に苦労している、EMの方

得られる学び

• プレイヤーやプレイングマネージャーからEMへとステップアップする上で、どのようなマインドセットや経験が必要となるか
• マネージャー層の育成の再現性を上げるためのヒント

概要

こんにちは、椎葉です。僕は現在、EM(Engineering Manager)ではなく、IC(Individual Contributor)として仕事をしています。このセッションでは、EMではないメンバーの視点で「こういうふるまいをしてくれるEMだと仕事がしやすいな」と思うことを紹介します。

みなさんは、もともとプレイヤーとして動いていて、そのスキルの高さや責任感の強さ、落ちそうになったボールを積極的に拾う姿勢などが周囲から認められてEMになったのではないでしょうか。そして、EMになったとたんに周囲からの期待があがってプレッシャーを感じていたり、これまでのプレイヤーとしての自分とマネージャとしてチームを育てることのバランスをどこに定めたらいいかを悩んでいたりしないでしょうか。

僕はこれまでたくさんのEMと、いろいろな関わり方で仕事をしてきました。その様々な関わり方の中で、自分の中に「EMがこんなふるまいを見せてくれるとメンバーとしては働きやすいな」ということや、「EMになりたてだとこういうことに悩むんだな。その場合はこういうサポートが役に立つんだな」ということが経験や知識として溜まってきています。

このセッションでは、その経験や知識をみなさんにお伝えします。

EMになってメンバーとどのように接していけばいいか戸惑っている方、ついプレイヤーとして動いてしまってメンバーの育成をどうしたらいいか悩んでいる方、EMとしての経験を積んで当初の悩みは減ってきたけどこれからもう一歩成長するにはどうしようかと考えている方、そんなみなさんに聞いてもらいたいなと思っています。

Learning Outcome

このセッションを聞いてくれたみなさんが、ポジティブな気持ちになって、何か少しでもヒントを得て、明日から前向きに新たな一歩を踏み出す背中を押せるようなセッションにしたいと考えています。

• EMがどんなふるまいをしてくれるとメンバーは動きやすいか
• エンジニアとしてスキルが高く責任感が強い人がEMになったときに何に悩むか
• その悩みをどのように解決していけばいいか、など

概要

筆者は現職に1人目EMとして転職し、入社3ヶ月後にDesign Managerを兼務することになりました。
それまでエンジニア組織以外のマネジメントをしたことがなくデザインに関する専門性もなかったため、Design Managerとして何をすればわからない状態でのスタートでした。

手探りの状態から試行錯誤を繰り返しながら1年が経過し、それまで行ってきた組織マネジメントの成果やEMとDesign Managerを兼務することのメリット・デメリットが言語化できる状態になりました。

小さな組織ではマネージャーの数が少ないためタイミングによってはEMがエンジニア以外のマネジメントを兼務することも十分にありえますが、そうなった場合にどのようにEMとしてのスキルを活かせるのか、自身の経験を踏まえてお話しします。

トーク全体を通して、EMのスキルを抽象化して考えることであらためて自身のスキルを認識・言語化する機会を提供します。
「EMとして自分が成長しているかわからない」「自分のスキルが別の環境でも通用するかわからない」といった悩みを持つEMが、トークの後には自身のスキルに自信を持ち、スッキリとした気持ちで明日からの業務に取り組めるような内容にします。

Learning Outcome

• EMのスキルを抽象化して考えることができるようになる
  • 日頃のマネジメント業務で発揮しているスキルの棚卸しをする機会を得る
  • EMで培ったスキルをエンジニア以外の職種のマネジメントで発揮する方法がわかる
  • EMのマネジメントスキルを「プロダクト開発組織のマネジメント」と1段階抽象化して考えることで、より広く組織に影響力を発揮する方法がわかる
• 規模の小さな開発組織でEMとDesign Managerを兼務することのメリット・デメリットがわかる
• ある日突然エンジニア以外のマネジメントを任されたときの心構えができる

概要

急成長する組織が抱える課題の一つに、"マネージャー不足"があります。

新たにチームを組成しなければならないのにマネジメントロールのアサインができない、チームのマネージャーのサクセッション対象がいないなど、時としてマネジメントロールのスケールは組織の成長のボトルネックになります。
マネージャーが不足すると、「複数のチームを兼務」や「条件を満たさない人物がアサインされる」ことになり、中長期的に見ると生産性が落ち、競合優位性に影響します。

特にプレイングマネージャーは、業務負荷や認知負荷が高く、誰もやりたがらない仕事になっていないでしょうか。
どうしてマネージャーは増えないのでしょうか。
組織に何が起きているのでしょうか。

本セッションでは、マクロ環境から私の所属する企業の事例まで含め、組織のスケールに合わせてマネジメントロールをどうスケールさせていくかの考えをお話します。

Learning Outcome

想定聴者

• 経営層、成長期にある組織の人事部門担当者、及びマネージャー層

アウトカム

• マネジメントの業務負荷の解像度を上げる
• 成長期の組織におけるマネジメントの負荷軽減対策

概要

組織形成において、最も重要なこととして採用活動が挙げられます。EMの仕事の1つとして日々採用活動を行っている方も多いのではないでしょうか。
私自身2回の起業経験の中でエンジニアが自分1人の所から、数十人規模の組織に至るまで組織を拡大させ、その中で母集団の形成や、選考フローの構築、面接など幅広く採用業務を行ってきました。

多くの企業が採用活動を行う中で、エンジニアの採用市場は苛烈し、難易度があがってきていると感じます。
そんな中で、皆さんの会社はどんなエンジニアに入社して欲しいか、採用に関わる全員が正しく把握できていますでしょうか。
また、選考フローではどんな採用基準を用いて選考を実施し、候補者の評価を行なっているでしょうか。

私は採用を進める上で、EMの方々が組織の現状や開発文化、求める技術水準をしっかりと把握し、採用フローや選考内容、評価基準を設定するべきだと思っています。
本発表では、組織をグロースさせていくために、自社に合った人材を見極め、どのようなアプローチで採用していくか、各選考ステップでの考えや、それに基づいた採用の実践・改善方法を、私が所属するスマートバンク社の事例をもとにお話しします。

CTO / VPoEの方がどんな方針で採用フローを組み上げ、メンバーを巻き込みながら実践していくのがいいか？既に採用プロセスに関わるEMが、どう面接をブラッシュアップしていけばいいか？そういった部分で示唆のある内容を提供します。

具体的な発表トピック
・会社の文化や行動基盤、コアバリューに即した面接方法の構築方法
・構造化面接の導入による、ブレのない一貫した基準での面接評価の方法
・選考フローや面接内容のブラッシュアップなど、採用自体のPDCAサイクルを上手く回す方法

Learning Outcome

対象聴者

• エンジニア組織拡大を行う上で、採用戦略や選考フロー / 基準の策定に関わっている方
• 既にエンジニア採用に関わり、面接等を実践している方

得られる学び

• エンジニア採用や選考ステップを作る上での考え方
• 選考フローや面接内容の構築方法、その具体事例
• 選考基準を設定し、計測、フィードバックループを回していく方法

概要

近年さまざまな組織で採用されている 1on1。
そのスタイルはさまざまで、組織の数だけベストプラクティスと悩みがあると思います。
このトークでは、1on1の目的を「組織にとって好ましい、良い習慣をメンバーに根付かせること」と定義します。
キーワードは「行動変容」。
保険医療の「動機づけ面接」などで実際に使われる、生活習慣改善の手法をヒントにして、
「良い習慣をメンバーに根付かせる」ために必要な考え方や、アンチパターンについて掘り下げていきます。

Learning Outcome

• 行動変容についての基礎的な考え方を知ることができる
  • そもそも人間の思考意思決定はどのように行われるのか
  • 自動的で処理が速いがバイアスの強い「システム 1」と、意識的で処理の遅い「システム 2」について
  • 習慣とはなにかと、それを改善するインパクトについて
  • 行動変容を促すために見極める 5 つのステージについて
• 保健医療の「動機づけ面接」から、 1on1 のベストプラクティスとアンチパターンについて知ることができる
  • 傾聴するときに相手を見るポイント
  • なぜ人はネガティブフィードバックを無視するのか
  • 自分を「1 人の人間」として認識させ、相手のシステム 1 に訴えかける方法
• 1on1 を実施する上で、その設計の指針やヒントになる切り口を知ることができる
  • 1on1 が「動機づけ面接」に似ている箇所と、そのまま利用できない箇所について
  • 心理学のあやふやさと、それでもEMが心理学を知っておくといい理由
  • 人間の「リファレンスガイド」としての心理学活用方法

概要

昨今のエンジニア組織論の盛り上がりで、リーダーシップ論、マネジメント技術、採用戦略、評価制度など、組織マネジメントにまつわる話が多く語られるようになりました。
一方で、あまりまだ語られていない分野があります。労務です。

私はEMになった頃、知識もなく労働管理、休職、福利厚生の設計などの人事労務オペレーションに関わったり実現する立場になり、戸惑いを覚えました。
労務部門の助けを借りながら経験を積む中で、従業員エンゲージメントを向上させ、組織のパフォーマンスを最大化しするためには、労務の知識と労務部門との協力が必要不可欠であると強く実感しました。

また、Web業界ではここ数年、さまざまな企業が柔軟な働き方や魅力的な福利厚生を打ち出す企業が増えてきました。コロナ禍以降はリモートワークも当たり前になっています。
そういった柔軟な働き方を設計・運用し、実現しているのは企業の労務部門です。
我々ソフトウェアエンジニアが現在、柔軟な労働条件のもとで働けているのは、たくさんの事例を世に送り続けてきてくれた、さまざまな企業の労務部門のおかげなのです。

本トークでは、これまでEMの分野においてあまり語られてこなかった、労務についての基礎知識と私が経験した事例をお話しします。
突然労務オペレーションに関わるようになったEMへの手助けや、我々がより働きやすい社会を実現していくアクションの一つになれば幸いです。

※ 具体的な事例は、内容についてスライドの撮影やSNSでの言及をお断りする可能性があります。ご了承ください。

トピック

• 労務オペレーション
• 制度設計
• 労働時間管理
• 休職
• その他トラブル事例

Learning Outcome

• 基礎的な労務の知識とオペレーションの理解
• 突然労務オペレーションに関わるようになったEMへの手引き
• 柔軟な働き方を実現していくための基礎知識の習得

概要

エンジニアリングマネージャー（以下、EM）が役割をまっとうするために重要なのが、周囲からの信頼貯金です。

メンバーから見た場合。
　この人なら、技術的な意思決定について任せることができる。
　厳しいスケジュールだけれども、この人が大切な案件だというなら、それを信じてコミットメントできる。

チーム外から見た場合。
　この人なら、チームが今やるべきことを期待通りに遂行してくれる。
　開発者体験というものはよくわからないけれども、このEMが大切だというなら今やっておいたほうがいいんだろう。

初めてEMになるタイミングでは、知らず知らずこの信頼貯金をもっているものです。（少なくとも、エンジニアが自分の所属しているチームのEMを任される場合。）
なぜなら、その組織で一定の成果を上げたからこそEMに任命されているはずです。
チームの技術スタックはよくわかっているし、チームに求められていること、そしてチームメンバーの特性だってよくわかっています。少なくとも、周囲はあなたがそういった状況にあると信頼しています。

EMがキャリアを積み重ねる中で、そういった信頼貯金がない状態に身を置くタイミングがやってきます。
組織内の他のチームに異動することになったり、新しいチャレンジを求めて転職したりーー。
特に後者の場合は、基本的に社内に自分のことを知っている人があまりいない状態からスタートするわけですから大変です。
そういった、積み上げでの信頼貯金がない状態でEMはどうやって信頼を獲得していけばよいのでしょうか。

10年以上マネジメント業を経験していく中で、私は何度か「信頼貯金がない状態でEMになる」という経験をし、信頼を勝ち得るために有効なパターンがある程度見えてきました。

• チームメンバーの人となりを知る
• 仕事「ではない」メンバーのパーソナリティに興味を持つ
• チームのミッションを知る
• チームの技術を知る
• チームと過ごす時間をたくさんとる
• 成果を出す

上記のパターンについて、実例を交えながらご紹介できればと存じます。

Learning Outcome

• EMにとってなぜ信頼を勝ち得ることが大切か知る
• ゼロベースで信頼を獲得する方法を学ぶ

概要

複雑化する業務システム開発において、如何にチームの知識を効果的に共有・創造していくかが、プロジェクトの成否を分ける重要な要素となっています。
当チームは、障害福祉という高度に専門的なドメインに対し、モブワークを軸とした知識創造の仕組みを5年間にわたって実践してきました。

本セッションでは、2020年からのモブワーク導入・発展の過程で得られた具体的な知見を、実践的なプラクティスとともにご紹介します。

紹介するモブワークの遍歴としては以下の様になります。

• リアル期
• フルリモート期
• 安定期
• プロジェクト立上げ期（暗黙知を人に）
• チームビルディング期
• シン共同開発期
• 知識創造型へ

遍歴にあるプロジェクトの状況やチーム構成に応じて、モブワークの取り組みも変化させてきました。
モブワークには多くのメリットがありますが、プロジェクトの状態やチームの熟練度によって、目的や効果的な方法が異なると感じています。
ナレッジの共有が重要ですが、チーム内にナレッジがない場合でも機能します。
その際、知識創造のサイクルを意識したモブワークが鍵となります。

モブワークと個人ワークを組み合わせ、多様性を活かして知識創造を行う組織を実現します。

複雑なドメインに対応するために、以下の点を中心にお話しします。

• モブワーク実施の具体的なプラクティス
• チーム内での知識共有を促進するファシリテーション手法
• 予想される課題と対応策

Learning Outcome

1. 実践的スキル
   • モブワークに適したタスクの選定方法
   • 効果的なファシリテーション手法
2. マネジメントスキル
   • チームの練度に応じたスタイルの見直し
   • 必要なツールと環境の整備
3. 組織変革の視点
   • 学習する組織への転換方法
   • 持続的な知識創造の仕組み作り

概要

スクラム、アジャイル、XP、etc…それらに関わっている皆さんであれば、人と関わるということが開発においてどれほど重要でどれほどの部分を占めているかおわかりでしょう。

今回の発表では「なぜ私がやさしさが大切であると思っているか」から始まり、今まで個人的に集めた文献の中から仏教・哲学・学術などの観点から『やさしさ』とはなにか？どのようなものなのか？どうしたら身につくのか？に近づいていきたいと思います。

このトークは『Scrum Fest Mikawa 2024』にて【『人にやさしく』するということ】として発表したものの、改訂・増補版になります。
聴講者の方々からは「考えたことなかった」「普段の自分からは触れない領域の話が聞けるのはフェスの醍醐味」「今回聞いた中で一番不思議だった」とのお言葉を頂きました！
今回は前回の発表で分かりにくかったかなと反省した部分を修正し、語れなかったものに関しても増強しています。

そしてEMConfにアジャストして、『やさしさ』をマネージャーとしてどう役立てるかについても話したいと思います。

Learning Outcome

• 明日から人にやさしくしようと思える
• 『やさしさ』とは後天的に身につけることができる技術であると理解できる
  • そして『やさしさ』を身につける努力をしたいと思える
• EMとして『やさしさ』をどう活用するのか一例を知ることができる

概要

自身が2つの会社にて合計で約10年経験したEM役割における
失敗と学びを赤裸々にお話します。

主に以下のような領域について
・ピープルマネジメント
・コンフリクトマネジメント
・採用
・持続可能な学び

Learning Outcome

・事前に知っていれば回避できるアンチパターンが分かる
・同様の経験をした時の立ち直り方の1例を知れる
・EMを未経験の人には、EMに挑戦することのハードルが下がる

概要

エンジニア組織を拡大することは難しいです。ここで指す拡大とは以下の2つを意味します。

• メンバーを増やすこと
• メンバーが成長すること

メンバーが増えるだけでなく個々のメンバーが成長しなければ、組織としての拡大にはつながりません。

メンバーを増やすためには採用をしなければなりません。しかし、中途採用で優秀なエンジニアを採用することは難しいです。

そこで弊社が注力しているのは、新卒採用です。

弊社はスタートアップですが、通常スタートアップでは新卒採用に注力しません。しかし、会社を飛躍させるのは、凡庸な中途人材よりトップレベルの新卒です。聡明で深い思考力があり、学習意欲が高く、あらゆる領域にチャレンジできる新卒を取るべきです。

そして、組織の拡大のためには、採用だけでなく入社後の成長にもフォーカスする必要があります。

例えば、成長のためには、オンボーディングを侮ってはいけません。新しいメンバーがすぐに作業に入れるように開発環境のセットアップを一緒にやってあげていますか？自社のすべてのプロダクトを新しいメンバーに触ってもらっていますか？新しいメンバーをあらゆる部署のメンバーにつないであげていますか？オンボーディングでは、新しいメンバーが走り出すための必要なすべてをするべきです。

弊社では新卒のエンジニアが成長できるためのさまざまな施策を実行してきました。それによって新卒エンジニアが主力メンバーとして成長し、エンジニア組織が拡大してきました。

本トークでは、エンジニア組織拡大のための採用戦略から育成までを紹介します。

目次

• 採用編
  • トップレベルの新卒を取れ
  • 新卒採用もリファラルで取れ
  • 破格のサマーインターンを用意する
• 育成編
  • オンボーディングをなめるな
  • 正社員全員がメンター
  • あらゆる部署に直接つなぐ
  • CEOと議論させる
  • 肩書きを付けない
  • 新卒メンバーに教えを請う
  • 外部メンターの有効性
  • 報酬を惜しまない

Learning Outcome

• エンジニア採用における新しい考え方や戦略
• エンジニアの育成・メンタリング方法

概要

皆さんは間接部門のエンジニアリングマネジメントをどのように行っているでしょうか？
本セッションは間接部門の1つであるQA（品質保証）チームのEMについてのお話です。

間接部門の難しさ

QAは間接部門と言われます。間接部門とは直接売上を生み出すことのない業務を担っている部門であり、評価をしづらい部署といえます。

例えば、開発であれば「機能Xの開発によって、A社の受注に繋がった」といった話ができるでしょう。

一方でQAの場合、「遅延なくリリースできた」と言っても、それが

• QAメンバーが工夫できた
• 開発メンバーが優秀で不具合がほとんど出なかった

のどちらなのか判断が付きづらいです。

評価のしづらさによる悩み

評価のしづらさは以下のような悩みに繋がります。

• 評価面での悩み
  • 自己評価を書けない
  • 評価者が評価を付けづらい
  • 他チームのマネージャーにメンバーのアピールがしづらく、評価のキャリブレーションが難しい
• 日々の業務での悩み
  • 評価軸を作りづらいため、メンバー本人が自信を持って行動できない
  • どのように進めれば良いのか判断がつきづらく、成長を実感しづらい

QAチームのEMになって気付いたこと

そんな中、私はQAチームのEMとして働くようになりました。
EMになって、QAメンバーは成果を出していないのではなく、自分の成果をアピールするのが上手でないことに気付きました。例えば、成果として「機能Aと機能Bと機能Cのテスト設計とテスト実施を行っていました。」としか書かなかったりするのです。

EMとして行動したこと

私は1on1などを通じて、QAメンバーが日々行っている工夫をできるだけ言語化しました。本人は「些細なことなんだけど」と前置きしていても、私からはすごく魅力的に見え、かつ上に書いた悩みを打破する宝の山でした。

本セッションでは、宝の山となる些細な工夫を見つけ出して、メンバーの成長に繋げるためのコツを、具体例を交えてお伝えします。

Learning Outcome

• 間接部門のEMになった際に、成長を促すコツを知れる
• 間接部門かどうか関係なく、1on1で聞き出した些細な工夫をピックアップして成長に繋げる方法を知れる