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
86
GraphQLを導入してよかったこと大変だったこと
yasudatoshiyuki
0
99
Other Decks in Business
See All in Business
これを使用
ehealthcare2004
0
360
インキュデータ会社紹介資料
okitsu
3
32k
株式会社BFT 会社紹介資料|エンジニア&セールス職向け
bft_recruit
2
11k
サバノミソニLT‐AWS認定資格合格への道のり
utosun
0
360
VISASQ: ABOUT US
eikohashiba
15
460k
STRACT, Inc. Company Deck
stract
0
1.4k
エンジニア向けオープンワーク会社紹介資料 / company profile
openwork
1
17k
Theoria technologies:About Us
theoriatec2024
1
2.1k
kubell COMPASS Ver 1.0.0
kubell_hr
0
3.7k
merpay-overview_en
mercari_inc
1
17k
Nstock 採用資料 / We are hiring
nstock
26
250k
サーキュレーション会社説明資料
circulation
2
18k
Featured
See All Featured
Measuring & Analyzing Core Web Vitals
bluesmoon
4
130
The Art of Programming - Codeland 2020
erikaheidi
52
13k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Visualization
eitanlees
145
15k
The Cult of Friendly URLs
andyhume
78
6k
Building Adaptive Systems
keathley
38
2.3k
Fireside Chat
paigeccino
34
3k
Optimizing for Happiness
mojombo
376
70k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
0
100
Designing for humans not robots
tammielis
250
25k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
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 ここに本文が入ります ここに本文が入ります
ここに本文が入ります ご清聴ありがとうございました