Slide 1

Slide 1 text

©iCARE Co., Ltd All rights reserved 1 エンジニアリングマネジメントで いかに事業をドライブするか? 2021年5月19日 株式会社iCARE  VPoE 安田俊之

Slide 2

Slide 2 text

©iCARE Co., Ltd All rights reserved ここにタイトルが入ります 2 ここに本文が入ります ここに本文が入ります ここに本文が入ります 
 
 自己紹介

Slide 3

Slide 3 text

©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.

Slide 4

Slide 4 text

©iCARE Co., Ltd All rights reserved ここにタイトルが入ります 4 ここに本文が入ります ここに本文が入ります ここに本文が入ります 
 
 本題

Slide 5

Slide 5 text

©iCARE Co., Ltd All rights reserved 今日のテーマ 5 今日のテーマは エンジニアリングマネジメントでいかに事業をドライブ するか? です。 まずは前提となるエンジニアリングマネジメントとは 何か?というお話からしたいと思います。

Slide 6

Slide 6 text

©iCARE Co., Ltd All rights reserved エンジニアリングマネジメントとは何か? 6 多分、これについての包括的な定義はいろいろな人 がいろいろなところで書いているので、ネットででも検 索したほうがいい。 ここでは自分が最も大切だと思う要件について話して みます。

Slide 7

Slide 7 text

©iCARE Co., Ltd All rights reserved 組織による開発に落とし込む 7 一言で言うと、 事業の要求 を 組織による開発に 落とし込むこと と言えるのではないかと思います。

Slide 8

Slide 8 text

©iCARE Co., Ltd All rights reserved 個人による開発ではスケールできない 8 事業の要求 を 個人による開発に 落とし込む ではない。 なぜなら 自分の手を使っていては事業をスケールできない からです。

Slide 9

Slide 9 text

©iCARE Co., Ltd All rights reserved 好きなようにやってもらうでもない 9 組織の構成員が 好きなことを好きなように開発させること でもない。 これだとメンバーがバラバラに動き、事業を迅速に進 められなかったり、いいサービスを作れなかったりし て、競合他社に負けてしまい、組織が存在し続けるこ とができない。

Slide 10

Slide 10 text

©iCARE Co., Ltd All rights reserved 一つの方向に束ねる必要がある 10 当然ですが、事業の要求を組織による開発に落とし 込むためには、メンバーの作業を一つの方向に束ね る必要があります。それは 個人 < 少人数 < 大人数 といった感じで人数が増えていくほど、困難になって いきます。

Slide 11

Slide 11 text

©iCARE Co., Ltd All rights reserved 組織は事業とともに拡大していく 11 事業は成功していけば拡大していきます。 事業が拡大すれば、それをさばくために組織も拡大 する必要があります。

Slide 12

Slide 12 text

©iCARE Co., Ltd All rights reserved 拡大の中で生じる問題 12 組織が拡大する中で、メンバーがバラバラに開発をし ているだけだと、開発速度が上がらないだけでなく、 1. 各々の開発がうまく統合、適合しない 2. 複数人で同じ作業をするなど無駄が生じる 3. (結果)メンバー間に不満が生じる 4. (最悪)組織が立ち行かなくなる といった問題も生じます。

Slide 13

Slide 13 text

©iCARE Co., Ltd All rights reserved 困難さを解決しつつ方向づけていく 13 事業の規模の拡大とともに増していく、そうした困難 さを解決し、組織を一つの方向に束ねながら、事業を 成長させていくことがエンジニアリングマネジメントの 主要な課題だと考えています。

Slide 14

Slide 14 text

©iCARE Co., Ltd All rights reserved 次の話題 14 次に「一つの方向に束ねる」ためにはどうすればよい か?というお話したいと思います。

Slide 15

Slide 15 text

©iCARE Co., Ltd All rights reserved ここにタイトルが入ります 15 ここに本文が入ります ここに本文が入ります ここに本文が入ります 
 
 事業の方向性とあった行動を してもらうためには?

Slide 16

Slide 16 text

©iCARE Co., Ltd All rights reserved 事業の方向性に合致させる 16 開発組織は、事業を進めている以上、その事業の方 向性に合致した開発をする必要があります。

Slide 17

Slide 17 text

©iCARE Co., Ltd All rights reserved 事業の方向性が伝わっていないと 17 きちんと事業の方向性が伝わっていないと、メンバー が、悪意がないのにも関わらず事業的に優先度の低 い作業をしてしまう、という問題が起こる

Slide 18

Slide 18 text

©iCARE Co., Ltd All rights reserved 優先度の低い作業をしてしまう例1 18 不適切なタイミングでの開発者体験の向上 開発者体験の向上は生産性を向上させるので、それ 自体は非常にいいことだが、例えば多くの顧客が何 かの機能が急ぎ実装されることを待っているときに、 ここに時間・工数を費やしているとしたらそれは事業 的に適切ではない

Slide 19

Slide 19 text

©iCARE Co., Ltd All rights reserved 優先度の低い作業をしてしまう例2 19 顧客からは指摘がないがエンジニアが気づいたバグ の修正(方向性の誤った品質向上) ● サービスの現在、未来にインパクトを持たないバ グ ● エンジニアが美学的に気持ち悪いというだけのバ グ 上記のような場合、急いで修正したり、そこにむやみ に時間をかけたりすることは事業上、適切とは言えな い。

Slide 20

Slide 20 text

©iCARE Co., Ltd All rights reserved 優先度は指示やルールでは解決できない 20 こうした優先順位を誤ってしまう問題は、ルールや指 示でそれを防ぐことは難しい。 「指示」はスケールさせることが難しいですし、優先順 位の判断ができるような「ルール」は管理が恐ろしく 大変になるからです。

Slide 21

Slide 21 text

©iCARE Co., Ltd All rights reserved 自律的に判断・行動できるようにする 21 そうなるとこの問題を解決するために は、事業的な優先度や組織の価値観 をエンジニアが常に理解していて、そ こからどう行動するのが適切か自律 的に判断・行動できるようにする必要 がある。

Slide 22

Slide 22 text

©iCARE Co., Ltd All rights reserved Managing with Context, Not Control 22 これをシンプルな言葉で表現しているが Netflix Cultureで言われている Managing with Context, Not Control

Slide 23

Slide 23 text

©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

Slide 24

Slide 24 text

©iCARE Co., Ltd All rights reserved コンテキストにエンジニアをおく 24 指示・ルール(Control)でエンジニアの行動を規定せ ず、事業の ● 戦略(Strategy) ● 測定(Metrics) ● 仮説(Assumptions) ● 目的(Objectives) といったことが理解できるコンテキスト(文脈・状況)に エンジニアをおいて、エンジニアがそれに基づいて適 切に判断し、開発することができるようにする

Slide 25

Slide 25 text

©iCARE Co., Ltd All rights reserved より少ない管理コスト 25 Controlの場合、事業が拡大するとその管理も肥大化 していく一方で、Contextの場合は、判断をエンジニア の自律性に委ねることができるため、より少ない管理 コストで事業の方向性に合致した開発をすることがで きるようになる。

Slide 26

Slide 26 text

©iCARE Co., Ltd All rights reserved コンテキスト作り 26 そうしたコンテキスト作りがエンジニアリングマネージ メントの重要な仕事の一つ

Slide 27

Slide 27 text

©iCARE Co., Ltd All rights reserved ルール、指示も時には必要 27 メンバーはそれぞれ異なったスキル、異なったニーズ を持っており、コンテキストを用意するだけでうまく行 かないこともあるので、現実的には、ルールや指示で そこを補っていくことも当然必要

Slide 28

Slide 28 text

©iCARE Co., Ltd All rights reserved 次の話題 28 ここまでが「コンテキスト作り」のお話。 コンテキスト作りには、当然、コミュニケーションが必 要です。 最後にコミュニケーションについてのお話をしたいと 思います。 ここではコミュニケーションの上で大切になる 相手が知らないということを知る というお話をしたいと思います。

Slide 29

Slide 29 text

©iCARE Co., Ltd All rights reserved ここにタイトルが入ります 29 ここに本文が入ります ここに本文が入ります ここに本文が入ります 
 
 相手が知らないということを知る

Slide 30

Slide 30 text

©iCARE Co., Ltd All rights reserved 相手が知らないということを知る、とは? 30 人はどうしても自分が知っていることを、相手も知っ ているという前提に立って話をしてしまいがち。 例えば、あるファイルを探していて、それを同僚に聞 いた時に「Google Driveにあるよ」なんて答えられた体 験はありませんか?

Slide 31

Slide 31 text

©iCARE Co., Ltd All rights reserved 相手が知らないということを知る、とは? 31 Google Driveにログインして、そこからある経路をたど れば、そこにファイルは見つかる。 回答した人からすれば、その経路は自明だから、答 える必要がない、と思う(んでしょうね)。 でも、聞いた側は「Google Driveのどこにあるのかわ からんわ!(怒、もしくは困惑)」ってなる。

Slide 32

Slide 32 text

©iCARE Co., Ltd All rights reserved 立場が異なればすれ違いのリスクも高まる 32 こういうすれ違いっていうのはよくある。 同僚ではなく、立場が異なる人とコミュニケーションす る場合は、相手と共有する情報はもっと少なくなって いくので、そうしたすれ違いのリスクは高まっていきま す。

Slide 33

Slide 33 text

©iCARE Co., Ltd All rights reserved 組織規模が大きくなるとすれ違いが増えていく 33 プロジェクトや組織が大きくなればなるほど、「相手が 何を知らないか」に注意を払ってコミュニケーションを しないと、すれ違いが頻発し、非効率が生じたり、メン バーに不満が溜まっていったりする。 では、どうしたらよいか?

Slide 34

Slide 34 text

©iCARE Co., Ltd All rights reserved どうしたらよいか1 34 コミュニケーションの機会を作る 当たり前といえば当たり前ですが、相手も自分と同じ 情報を持ち、似たような価値観を持っているという前 提に立ってしまう(思い込んでしまう)と、これを怠りが ち。

Slide 35

Slide 35 text

©iCARE Co., Ltd All rights reserved どうしたらよいか2 35 相手が何を知っていて、何を知らないかを知る 当然ですが、適切にコミュニケーションするために は、まず「相手を知る」必要があります。相手の話を 聞いたり、行動を観察したりして、「相手が何を知って いて、何を知らないか」を掴む必要があります。

Slide 36

Slide 36 text

©iCARE Co., Ltd All rights reserved どうしたらよいか3 36 相手が何を知っていて、何を知らないかを知った上で 話しをする これができればコミュニケーションの基礎ができたこ とになります。 あとは「相手が何を聞きたいと思ってるか」とか「何を 望んでいるか」とかの「気持ち」面への配慮が更に必 要になってくる。

Slide 37

Slide 37 text

©iCARE Co., Ltd All rights reserved 基本的、原理的な話 37 ここまでの話は、エンジニアリングマネジメントの話と 言っておいたのに、 ● エンジニアを一つの方向に束ねていく ● エンジニアを正しいコンテキストに置く ● 相手が知らないということを知る といったようなエンジニアリング固有でない、非常に 基本的、原理的な話

Slide 38

Slide 38 text

©iCARE Co., Ltd All rights reserved 具体的な施策を底支えする 38 開発プロセスの改善とか開発者体験の向上といった 様々な技法的な話は今回ここに含めていません。 もちろん、そうしたことが大事な話ではないという意味 ではありません。むしろ、そうした諸々の具体的な施 策で事業を加速化しつつ、今回お話したような基本 的、原理的な話でもって、それを底支えすることで、 事業を飛躍的にドライブさせることができると考えて います。

Slide 39

Slide 39 text

©iCARE Co., Ltd All rights reserved エンジニアリングマネジメントの核 39 そうした意味で ● エンジニアを一つの方向に束ねていく ● エンジニアを正しいコンテキストに置く ● 相手が知らないということを知る といったことが、エンジニアリングマネジメントの核に なる、と考えています。

Slide 40

Slide 40 text

©iCARE Co., Ltd All rights reserved ここにタイトルが入ります 40 ここに本文が入ります ここに本文が入ります ここに本文が入ります 
 
 ご清聴ありがとうございました