伊藤直也さんの一人CTO Nightに一人で行ってきた
巷で話題？のnaoya さんの一人CTO Nightに行ってきましたので、超雑ですがメモを公開しておきます。
イベント詳細： https://doda.jp/event/seminar/20160830.html
オレオレメモなので多少ニュアンス違うところあるかもです。特に二部のパネルディスカッションの部分はかなり文脈を端折っているので雰囲気知るくらいに読んでもらえれば。
もし大きく間違っていることあったらご指摘くださいm(__)m ちなみにアニメの話はあんまりなかったよ。
では、早速。
第一部【プレゼンテーション】最速で最高のアウトプットを生み出すチーム作りとは？
【プレゼンテーション内容】 CTO・技術顧問を複数社経験した伊藤直也氏が、過去の実際の事例をもとに、最高のアウトプットを生み出すチーム作りを解説します。
- 前提として、、、
- 50〜300人くらいの規模の組織が対象
- CTOのマネジメントというよりはVP of Engineering寄りのマネジメントの話
- マネジメントもいろいろあるけど組織マネジメントとヒューマンマネジメントの話が主
開発組織マネジメントのコツ
- 『イシューからはじめよ』って本がいいよ
- エンジニアはプロセス中心というか手段を提供する仕事
- なので、問題設定とどうやって解くかがごっちゃになりがち
- マネージャーは問題解決ではなく問題発見にフォーカスすべき
- 正しい課題にフォーカスすれば自然と問題は解決するはず
- 開発組織のマネジメントはスポーツチームのマネジメントに近い
- 組織（構造）があるから
- 作者: 安宅和人
- 出版社/メーカー: 英治出版
- 発売日: 2010/11/24
- メディア: 単行本（ソフトカバー）
- 購入: 48人 クリック: 660回
- この商品を含むブログ (142件) を見る
内製開発チーム
- 横串の構造が多い（セールス、プロダクト、エンジニア）
- エンジニアとセールスが直でやりとりする
- 次第にリソースコントロールできなくなる
- そのために間にプロダクトチームをいれる
- セールスの要望が直接届かなくなりエンジニアからエンドユーザーがみえなくなる
- マトリクス型組織にする（チームをつくる）
- ラーニング（知識）が蓄積されるような構造が望ましい
日経新聞での事例
- 外注時代にひとりの人が複数のプロジェクトを兼務
- 個人にラーニング結果がたまっていく
- よかれと思って内製開発をはじめたが状況好転せず
- なぜならチームという枠組みが存在しないから
- どうしたかと言うと、、、
- 兼務を解消
- 1チームに1ミッション
日経電子版 開発内製化の取り組み / nikkei web development 2015 https://speakerdeck.com/yosukesuzuki/nikkei-web-development-2015
Kaizen Platformでの事例
- 枠組みがあるのに実質チームとして機能していない
- 1on1してもミッションは同じなのにひとりでやっているという回答
- 原因はPMとエンジニアが1対1で仕事している
- PMが空いた人からアサイン
- コンテキストスイッチが発生
- 隣の人がきついときヘルプできない
- どうしたかと言うと、、、
- PMが直接アサインするのではなくエンジニアのリーダーに
- チームとして会話する
偶然に期待しない
優先度が上がらないことを進ませたいとき
- リファクタリングを推進したときなど
- そういうときも組織（チーム）構造で変化を起こす
- 一休では技術基盤チームをつくった（直接的な売上にはつながらない）
- 決済プラットフォームとかをつくるのもあり
- ただしころころ構造を変えるとラーニング結果が蓄積されないので注意されたし
組織構造は時間的断片
- フェーズにあわせて横と縦のバランスを組み替える
デザイナー横断組織の変遷 http://techlife.cookpad.com/entry/2016/07/15/092518
組織課題の発見とアプローチ
- 『チームが機能するとはどういうことか』という本からの紹介
- この本、読んだことあって内容知っているのでメモが更に雑ですm(__)m
- 心理的安全性と責任
- 両者が高いと学習するのでその状態に持っていこう
- チームが置かれている状況がどこかによって対応方法が変わる
チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ
- 作者: エイミー・C・エドモンドソン,Amy C. Edmondson,野津智子
- 出版社/メーカー: 英治出版
- 発売日: 2014/05/24
- メディア: 単行本
- この商品を含むブログ (3件) を見る
一休での事例
- レストラン事業部：（乱暴に言うと）ぬるま湯だった
- チームごとのミッションの明確化
- ロードマップの精度を向上させる
- 宿泊事業部：（乱暴に言うと）プロダクトはつくれてるけどちょっと疲弊してた
- チームビルディング
- 技術基盤部の確立
ここまで組織レベルの話
ヒューマンマネジメント
- 『ピープルウェア』の有名なお言葉
- 作者: トムデマルコ；ティモシーリスター
- 出版社/メーカー: 日経BP社
- 発売日: 2014/02/05
- メディア: Kindle版
- この商品を含むブログ (32件) を見る
フレーミングをちゃんとやる
- 認知フレーム（思い込みや信念のこと）
- リフレーミング≒期待値調整
フレーミングのコツ
- ちゃんと説明する
- 「やっておいて！」だけではなく「こういう理由で◯◯にやって欲しいからお願い！」
- 最初にがんばる
- 直接対話する
1on1
- 任天堂の岩田社長が1on1やってた
- 組織の課題発見に繋がる
- リフレーミングできる
- お願いごとは相手のバケツが空になってから
- 事前アンケートを採ってそれを題材に話す
- バウンダリーオブジェクト（間にものをおく）
任天堂の岩田社長が遊びに来たので https://www.1101.com/iwata/
（注意）人の話題は強く意識を持っていかれる
- 誰それさんが辞めたがっているなど
- 人の話題に意識をとられすぎないように
信頼を勝ち取る
リファクタリングのために時間が必要です
- なんで？→まぁいいよと言われるようにする
ビジネスvsエンジニアリングの対立構造に持ち込まない
- これを普段やっているとあとでこまる
アンチパターン
文化改革症候群
- 文化とかビジョンみたな言葉が出てきたら危険
変化にあたって現状否定
- 必要以上に現状を否定しない
- 未来思考で説く
サーヴァント型リーダーシップの罠
- 雑用をいっぱいしてくれる
- でも大きな方向性を示してくれない
- いざというときの意志決定ができない
- Fate/Zero観ろ
123: The Grail Dialogue (Naoya Ito) - Rebuild http://rebuild.fm/123/
エンジニア幸せ向上委員会
https://twitter.com/naoya_ito/status/770537380906274817
力を集約する != みんなが同じことを考える
- みんながみんな同じことを考える組織…宗教？
- 価値観の異なるメンバーを同じゴールに向かわせる
即効性のあるHOW TO
- 壁打ち相手を見つけよう
- 技術プロセスの課題解消（即効性がほしいときに）
第二部【パネルディスカッション】伊藤直也氏のマネジメントお悩み相談室 withソラコム 玉川憲氏
【パネルディスカッション内容】 事前にマネジメントに関して寄せられた「お悩み」に対して、伊藤直也氏がアドバイスを行います。エンジニアの皆さまから寄せられた「お悩み」を伊藤直也氏にぶつけてくれるのは、自身もマネジメントや技術統括の経験を豊富に持つソラコムの玉川憲氏。
メンバーが守備範囲外のことをしてくれない
- 日本っぽい（守備範囲外のことをやると怒られるじゃん）
- 指示待ち人間がいるのは待っているほうが得をするから
- 守備範囲を変えないといけないのでは？
プランナーとうまくいかない
- インフラエンジニアとアプリケーションエンジニア仲悪い問題と似ている
- 昔インフラエンジニアがSLAを守るために重いバッチ処理をkillしたことがあった
- AWSが生まれたのはインフラエンジニアとアプリケーションエンジニアの会話をなくすため（技術で解決パターン）
デザイナーやエンジニアのことを理解してもらうには？
- まずは信頼してもらうこと
- でも難しいかも
- JapanTaxiの川鍋さんみたいに技術のことわからないけどエンジニアリングを大事って言ってくれる人がいると楽
会社（組織）の思考をきりかえるには
- 一休の営業はIT企業だと思っている人が多くない
- 最初はもどかしかった（こんなことも知らないのか！
- でもそういう多様性を受け入れていくことが大切では？
経営陣が人件費を払っているんだからエンジニアは売上が上がる機能開発をしろ！と言ってくる
- CGMの会社だと難しい（ソシャゲなら話は別）
- お前が言うな！と思うけど言っちゃダメ
- 難しい
マネジメント職につく覚悟がつかない
- 調整ばっかりしているのは確かに辛い
- 1on1症候群にならないよう
キャリアを含めた技術力が上の人との1on1
- そもそも技術力がある人が人として上ではない
- 1on1で技術の話はあまりしない
- 道を指し示す必要はない
- 壁打ちでいい
- ソラコムではスタンドアップミーティングを事前にbotでやる
- シェアしたいこと
- 改善したいこと
- 改善してほしいこと
ROIで優先順位をつけられるとリファクタリングとかできない
- 同列に並べちゃいけない
- ロジックで攻めると数字で負けるからよくない
- 信頼感とか寝技に持ち込む（そしてチームつくっちゃう）
採用についての質問
- コンテンツをひっぱって採用できる会社は限られている
- ブログとかメディアやってるのは既に大きなサービスがある企業の付加価値
- Job Descriptionを外資はちゃんと書く
- 日本は3行とか
- 一休でもブログやるとかnaoyaさんを全面に押し出したけどあまりうまくいかず
- 転職エージェントに出しているJob Descriptionを見直した
- 面接官が上から目線はNG（エンジニアに多い）
- 悪い噂はすぐに広まるのでちゃんと説明する
- AWSの社長？はずっと握手してきたw
開発の速度を定量化したい
- 相対的にしかみれない
会社全体の技術力をあげていきたい
- 技術力をあげていきたいというエンジニアは実は少ない
- ドメイン知識が豊富な人もいる
- 新しいことは知らないけどコンピューターサイエンスやアルゴリズムの詳しい人もいる
- ワークライフバランスを大事にしている人もいる
- いろんな人がいるから多様性を大事に
- いまあるカードをどう組み合わせるか
- みんなが勉強マンになる必要はない
- みんながそうなるとモダンだけどやたらと複雑になること多い
- 勉強マンとかは技術基盤にいれたり
- リーダーシップとってる人が勉強してれば勝手に真似してくる（コントロールはできないけど）
1on1の頻度
- 1週間に1回やると話すことがなくなることがあった
- フェーズによる
- 本末転倒にならない頻度でやる
信頼を得るには
- 一休の場合は元々技術顧問だったので。
- 地道に積み重ねるしかない。
ひとこと
Rebuildで聴いたことがある話も多かったけど、今まで細切れで聴いていたこともひとつのプレゼンテーションとして綺麗に整理されていたし、とても参考になりました。 僕は今の会社ではマネージャー職ではないけど、マネジメントという仕事も組織としてよいサービスやプロダクトを人々に提供するための手段の一つだと思うので、どんどん取り入れられるところは取り入れていくぞ！
にしても、やっぱりnaoyaさんの話は分かりやすいなぁ〜。
