Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
エンジニアリングマネジメントでいかに事業をドライブするか?
Search
yasudatoshiyuki
May 19, 2021
Business
0
120
エンジニアリングマネジメントでいかに事業をドライブするか?
エンジニアを一つの方向に束ねていく
エンジニアを正しいコンテキストに置く
相手が知らないということを知る
といったことについてお話します。
yasudatoshiyuki
May 19, 2021
Tweet
Share
More Decks by yasudatoshiyuki
See All by yasudatoshiyuki
襲来する課題の山に立ち向かう開発体制づくり
yasudatoshiyuki
0
180
エンジニア採用戦略で変わったこと、変わらないこと
yasudatoshiyuki
1
2k
iCAREという組織にVPoEが必要になった理由とVPoEが果たす役割
yasudatoshiyuki
0
56
Rails開発者向けGraphQL入門
yasudatoshiyuki
0
37
CarelyでBuefy使ってみてどうだった?
yasudatoshiyuki
0
72
Kubernetesでの環境構築および運用フロー構築のはなし
yasudatoshiyuki
0
84
GraphQLを導入してよかったこと大変だったこと
yasudatoshiyuki
0
99
Other Decks in Business
See All in Business
銀河エージェンシー会社概要資料.pdf
ginga2024
0
1.1k
VISASQ: ABOUT US
eikohashiba
15
460k
Aoba-BBT's Corporate Brochure
aobabbt
0
220
ブレインパッドXaaSユニット紹介資料(キャリア採用向けweb公開版 )
brainpadpr
0
14k
租税教育コンテンツの製作
tokyo_metropolitan_gov_digital_hr
0
450
enechain company deck
enechain
PRO
7
89k
We Are PdE!! 〜高価値なプロダクトを作れるようになるための勉強会〜
leveragestech
1
440
株式会社ユビレジ_採用ピッチ資料 / Ubiregi_CompanyProfile
ubiregi_saiyo
0
6.2k
サスメド株式会社 Culture Deck
susmed
0
36k
マネージャーとエンジニアが効果的に協力するために意識した方が良い事
kotominaga
2
120
コーチ・エィのご紹介2
coacha
0
190
Aayush Wellness Limited - Corporate Profile
aayushwellness
0
270
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
22k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
107
49k
The Language of Interfaces
destraynor
154
24k
Happy Clients
brianwarren
97
6.7k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
37
1.8k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
41
2.1k
Designing for Performance
lara
604
68k
RailsConf 2023
tenderlove
29
880
Producing Creativity
orderedlist
PRO
341
39k
Transcript
©iCARE Co., Ltd All rights reserved 1 エンジニアリングマネジメントで いかに事業をドライブするか? 2021年5月19日
株式会社iCARE VPoE 安田俊之
©iCARE Co., Ltd All rights reserved ここにタイトルが入ります 2 ここに本文が入ります ここに本文が入ります
ここに本文が入ります 自己紹介
©iCARE Co., Ltd All rights reserved 自己紹介 3 安田俊之 Twitter:
@TakataNoToshi iCAREにて2020年7月よりVPoE 関わってきた技術 Ruby on Rails, Vue.js, AngularJS PHP: Symfony, FuelPHP, CakePHP Java: Androidアプリ、Spring Perl: CGI DB: PostgreSQL, MySQL, Oracle, PL/SQL その他: Terraform, Ansible, Chef, Nginx, etc.
©iCARE Co., Ltd All rights reserved ここにタイトルが入ります 4 ここに本文が入ります ここに本文が入ります
ここに本文が入ります 本題
©iCARE Co., Ltd All rights reserved 今日のテーマ 5 今日のテーマは エンジニアリングマネジメントでいかに事業をドライブ
するか? です。 まずは前提となるエンジニアリングマネジメントとは 何か?というお話からしたいと思います。
©iCARE Co., Ltd All rights reserved エンジニアリングマネジメントとは何か? 6 多分、これについての包括的な定義はいろいろな人 がいろいろなところで書いているので、ネットででも検
索したほうがいい。 ここでは自分が最も大切だと思う要件について話して みます。
©iCARE Co., Ltd All rights reserved 組織による開発に落とし込む 7 一言で言うと、 事業の要求
を 組織による開発に 落とし込むこと と言えるのではないかと思います。
©iCARE Co., Ltd All rights reserved 個人による開発ではスケールできない 8 事業の要求 を
個人による開発に 落とし込む ではない。 なぜなら 自分の手を使っていては事業をスケールできない からです。
©iCARE Co., Ltd All rights reserved 好きなようにやってもらうでもない 9 組織の構成員が 好きなことを好きなように開発させること
でもない。 これだとメンバーがバラバラに動き、事業を迅速に進 められなかったり、いいサービスを作れなかったりし て、競合他社に負けてしまい、組織が存在し続けるこ とができない。
©iCARE Co., Ltd All rights reserved 一つの方向に束ねる必要がある 10 当然ですが、事業の要求を組織による開発に落とし 込むためには、メンバーの作業を一つの方向に束ね
る必要があります。それは 個人 < 少人数 < 大人数 といった感じで人数が増えていくほど、困難になって いきます。
©iCARE Co., Ltd All rights reserved 組織は事業とともに拡大していく 11 事業は成功していけば拡大していきます。 事業が拡大すれば、それをさばくために組織も拡大
する必要があります。
©iCARE Co., Ltd All rights reserved 拡大の中で生じる問題 12 組織が拡大する中で、メンバーがバラバラに開発をし ているだけだと、開発速度が上がらないだけでなく、
1. 各々の開発がうまく統合、適合しない 2. 複数人で同じ作業をするなど無駄が生じる 3. (結果)メンバー間に不満が生じる 4. (最悪)組織が立ち行かなくなる といった問題も生じます。
©iCARE Co., Ltd All rights reserved 困難さを解決しつつ方向づけていく 13 事業の規模の拡大とともに増していく、そうした困難 さを解決し、組織を一つの方向に束ねながら、事業を
成長させていくことがエンジニアリングマネジメントの 主要な課題だと考えています。
©iCARE Co., Ltd All rights reserved 次の話題 14 次に「一つの方向に束ねる」ためにはどうすればよい か?というお話したいと思います。
©iCARE Co., Ltd All rights reserved ここにタイトルが入ります 15 ここに本文が入ります ここに本文が入ります
ここに本文が入ります 事業の方向性とあった行動を してもらうためには?
©iCARE Co., Ltd All rights reserved 事業の方向性に合致させる 16 開発組織は、事業を進めている以上、その事業の方 向性に合致した開発をする必要があります。
©iCARE Co., Ltd All rights reserved 事業の方向性が伝わっていないと 17 きちんと事業の方向性が伝わっていないと、メンバー が、悪意がないのにも関わらず事業的に優先度の低
い作業をしてしまう、という問題が起こる
©iCARE Co., Ltd All rights reserved 優先度の低い作業をしてしまう例1 18 不適切なタイミングでの開発者体験の向上 開発者体験の向上は生産性を向上させるので、それ
自体は非常にいいことだが、例えば多くの顧客が何 かの機能が急ぎ実装されることを待っているときに、 ここに時間・工数を費やしているとしたらそれは事業 的に適切ではない
©iCARE Co., Ltd All rights reserved 優先度の低い作業をしてしまう例2 19 顧客からは指摘がないがエンジニアが気づいたバグ の修正(方向性の誤った品質向上)
• サービスの現在、未来にインパクトを持たないバ グ • エンジニアが美学的に気持ち悪いというだけのバ グ 上記のような場合、急いで修正したり、そこにむやみ に時間をかけたりすることは事業上、適切とは言えな い。
©iCARE Co., Ltd All rights reserved 優先度は指示やルールでは解決できない 20 こうした優先順位を誤ってしまう問題は、ルールや指 示でそれを防ぐことは難しい。
「指示」はスケールさせることが難しいですし、優先順 位の判断ができるような「ルール」は管理が恐ろしく 大変になるからです。
©iCARE Co., Ltd All rights reserved 自律的に判断・行動できるようにする 21 そうなるとこの問題を解決するために は、事業的な優先度や組織の価値観
をエンジニアが常に理解していて、そ こからどう行動するのが適切か自律 的に判断・行動できるようにする必要 がある。
©iCARE Co., Ltd All rights reserved Managing with Context, Not
Control 22 これをシンプルな言葉で表現しているが Netflix Cultureで言われている Managing with Context, Not Control
©iCARE Co., Ltd All rights reserved Managing with Context, Not
Control 23 https://www.slideshare.net/reed2001/culture-1798664/82-Context_not_ControlContext_embrace_Strategy
©iCARE Co., Ltd All rights reserved コンテキストにエンジニアをおく 24 指示・ルール(Control)でエンジニアの行動を規定せ ず、事業の
• 戦略(Strategy) • 測定(Metrics) • 仮説(Assumptions) • 目的(Objectives) といったことが理解できるコンテキスト(文脈・状況)に エンジニアをおいて、エンジニアがそれに基づいて適 切に判断し、開発することができるようにする
©iCARE Co., Ltd All rights reserved より少ない管理コスト 25 Controlの場合、事業が拡大するとその管理も肥大化 していく一方で、Contextの場合は、判断をエンジニア
の自律性に委ねることができるため、より少ない管理 コストで事業の方向性に合致した開発をすることがで きるようになる。
©iCARE Co., Ltd All rights reserved コンテキスト作り 26 そうしたコンテキスト作りがエンジニアリングマネージ メントの重要な仕事の一つ
©iCARE Co., Ltd All rights reserved ルール、指示も時には必要 27 メンバーはそれぞれ異なったスキル、異なったニーズ を持っており、コンテキストを用意するだけでうまく行
かないこともあるので、現実的には、ルールや指示で そこを補っていくことも当然必要
©iCARE Co., Ltd All rights reserved 次の話題 28 ここまでが「コンテキスト作り」のお話。 コンテキスト作りには、当然、コミュニケーションが必
要です。 最後にコミュニケーションについてのお話をしたいと 思います。 ここではコミュニケーションの上で大切になる 相手が知らないということを知る というお話をしたいと思います。
©iCARE Co., Ltd All rights reserved ここにタイトルが入ります 29 ここに本文が入ります ここに本文が入ります
ここに本文が入ります 相手が知らないということを知る
©iCARE Co., Ltd All rights reserved 相手が知らないということを知る、とは? 30 人はどうしても自分が知っていることを、相手も知っ ているという前提に立って話をしてしまいがち。
例えば、あるファイルを探していて、それを同僚に聞 いた時に「Google Driveにあるよ」なんて答えられた体 験はありませんか?
©iCARE Co., Ltd All rights reserved 相手が知らないということを知る、とは? 31 Google Driveにログインして、そこからある経路をたど
れば、そこにファイルは見つかる。 回答した人からすれば、その経路は自明だから、答 える必要がない、と思う(んでしょうね)。 でも、聞いた側は「Google Driveのどこにあるのかわ からんわ!(怒、もしくは困惑)」ってなる。
©iCARE Co., Ltd All rights reserved 立場が異なればすれ違いのリスクも高まる 32 こういうすれ違いっていうのはよくある。 同僚ではなく、立場が異なる人とコミュニケーションす
る場合は、相手と共有する情報はもっと少なくなって いくので、そうしたすれ違いのリスクは高まっていきま す。
©iCARE Co., Ltd All rights reserved 組織規模が大きくなるとすれ違いが増えていく 33 プロジェクトや組織が大きくなればなるほど、「相手が 何を知らないか」に注意を払ってコミュニケーションを
しないと、すれ違いが頻発し、非効率が生じたり、メン バーに不満が溜まっていったりする。 では、どうしたらよいか?
©iCARE Co., Ltd All rights reserved どうしたらよいか1 34 コミュニケーションの機会を作る 当たり前といえば当たり前ですが、相手も自分と同じ
情報を持ち、似たような価値観を持っているという前 提に立ってしまう(思い込んでしまう)と、これを怠りが ち。
©iCARE Co., Ltd All rights reserved どうしたらよいか2 35 相手が何を知っていて、何を知らないかを知る 当然ですが、適切にコミュニケーションするために
は、まず「相手を知る」必要があります。相手の話を 聞いたり、行動を観察したりして、「相手が何を知って いて、何を知らないか」を掴む必要があります。
©iCARE Co., Ltd All rights reserved どうしたらよいか3 36 相手が何を知っていて、何を知らないかを知った上で 話しをする
これができればコミュニケーションの基礎ができたこ とになります。 あとは「相手が何を聞きたいと思ってるか」とか「何を 望んでいるか」とかの「気持ち」面への配慮が更に必 要になってくる。
©iCARE Co., Ltd All rights reserved 基本的、原理的な話 37 ここまでの話は、エンジニアリングマネジメントの話と 言っておいたのに、
• エンジニアを一つの方向に束ねていく • エンジニアを正しいコンテキストに置く • 相手が知らないということを知る といったようなエンジニアリング固有でない、非常に 基本的、原理的な話
©iCARE Co., Ltd All rights reserved 具体的な施策を底支えする 38 開発プロセスの改善とか開発者体験の向上といった 様々な技法的な話は今回ここに含めていません。
もちろん、そうしたことが大事な話ではないという意味 ではありません。むしろ、そうした諸々の具体的な施 策で事業を加速化しつつ、今回お話したような基本 的、原理的な話でもって、それを底支えすることで、 事業を飛躍的にドライブさせることができると考えて います。
©iCARE Co., Ltd All rights reserved エンジニアリングマネジメントの核 39 そうした意味で •
エンジニアを一つの方向に束ねていく • エンジニアを正しいコンテキストに置く • 相手が知らないということを知る といったことが、エンジニアリングマネジメントの核に なる、と考えています。
©iCARE Co., Ltd All rights reserved ここにタイトルが入ります 40 ここに本文が入ります ここに本文が入ります
ここに本文が入ります ご清聴ありがとうございました