開発組織マネジメントのコツ

対象 : 50 – 100人ぐらいのWeb / 受託会社
CTO or VP of Engineering
- 海外ではCTO : テックリードのイメージが強い
- マネジメントをするのはVPofEが多い
  - CTOがマネジメントしたくなければVPofEを雇うのもあり
スコープ
- チームマネジメント
- ヒューマンマネジメント

基本姿勢
- 「イシューから始めよ」
- 解の質 x イシュー度 -> バリューのある仕事
  - イシュー度 : 問題設定の正しさ
問題解決ではなく問題発見にフォーカス
- マネージャーの仕事は問題設定
  - あとはメンバーが解いてくれる

チーム構造

開発組織のマネジメントはスポーツチームのマネジメントに近い
- メンバーの潜在能力を引き出すことに注力する
- チームワークは重要
  - クソコード書くやつは隣のやつの生産性を下げる
- 4-3-3, Flat-3のような「構造」->「システム」
  - 「11人全員サッカー」からの脱却
内製開発のよくある構造
- セールス : プロダクト : エンジニア（横の構造）
  - 三層構造による混乱
- 縦と横の構造
  - 縦のチームにはそれぞれのミッション
  - 横串の構造で開発プロセスや技術の標準化など
組織構造で重要なこと
- チームでラーニングした問題が組織やチームに蓄積されるような構造が望ましい
日経の場合
- 開発は外注
  - 一人の社員が複数のプロジェクトを兼務
  - サービス / デバイスごとにチームが存在するわけではない
- 内製にしたがチーム構造はそのまま
  - 内製の経験がないからチーム構造を変えなくてはならない、ということに気づけない
  - チームの枠組みがないからラーニングが蓄積されない
- どうしたか
  - 兼務を解消、1チームに1ミッション
  - 「日経電子版開発内製化の取り組み」
Kaizen Platformの事例
- チームの枠組みがあるのに機能していない
- PMとエンジニアが1:1で仕事している
  - PMがアサイン権限を持っている状態
    - エンジニア同士がお互いの仕事を知らない->ラーニング結果が蓄積されない
    - コンテキストが分断されスイッチコストが発生する
- どうしたか
  - うまく回っていたチームと同じ構造に
    - PMとチームリーダーが話をする
      - ラーニングが蓄積できる
偶然に期待しない
- 起きることはあるがアテにしない
- コントロールできる対象をマネジメントする
  - 個々人の意識はコントロールできない
  - 組織構造はコントロールできる
    - 原因を構造に求める
    - 構造的問題を見抜く
優先度が上がらないことを進めたい時
- 組織構造で変化を起こす
- 例 : 一休の技術基盤チーム
  - 運用の自動化、レガシー基盤の刷新、マネージドサービスの導入
- 専任チームを作り100%コミットさせる
組織構造はいじりすぎない
- ラーニング結果を保存するのが主目的
組織構造は時間的断片
- 組織構造は時間的断片（グリー藤本CTO）
- フェーズに合わせて横と縦のバランスをうまく組み替えていくことで更に良いサービスづくりが行える（cookpad 池田さん）
  - デザイナー横断組織の変遷 – クックパッド開発者ブログ
- 固定的に考えないほうがいい

組織課題の発見とアプローチ

心理的安全性と責任
- 4象限
  - 快適・学習
  - 無関心・不安
- 「チームが機能するとはどういうことか」
心理的安全性か責任か
- チームが置かれている状況はどこか
- どちらの軸が課題か
  - それによってアプローチが変わる
一休での事例
- チームごとに状況が違う
  - レストラン事業部 : 快適
    - ミッションの明確化、ロードマップの精度向上
    - 責任を増やす
  - 宿泊事業部 : 不安
    - チームビルディング、技術基盤部の確立
    - 心理的安全性を高める

ヒューマンマネジメント

ピープルウェア
相談しにくる人たちの共通点
- 技術の問題だと思ったら9割がた組織の問題だった
大事な2点
- フレーミング
- 1対1の面談（1on1）
フレーミング
- 認知フレーム
  - メンタルモデル、当然と見なされる仮定
  - 対象を捉える枠
- リフレーミング
  - フレームを変えさせる
    - 学習する場？作業する場？
フレーミングをちゃんとやる（重要）
- 期待値調整
- 新しい仕事 / ポジションをお願いする時
  - お互いの期待値を対話で擦り合せる
  - なぜお願いしたいか
  - どういうチャレンジがあるか
    - 踏み込んではいけない範囲を明示しチャレンジできる範囲を明確にする
フレームの力
- 同じ変化もフレーミングの如何で印象が全く変わる
フレーミングのコツ
- 最初に頑張る
- 直接対話する
- ずれてきたら再度調整
1on1
- 30 – 1hぐらいの面談（雑談）
- ざっくばらんに「対話」
- 任天堂・岩田社長のエピソード
1on1 なぜ有効？
- 課題発見
  - 面談以外で気づくのはむづかしい
- リフレーミングの絶好の機会
1on1 コツ
- お願い事は相手のバケツが空になってから
  - 先に話させる
- 何を話していいかわからない人
  - 事前アンケート
  - バウンダリーオブジェクト
    - 異なる領域の境界をつなげる・踏み超えること・もの
一休の場合
- CTO就任時
  - 40数名、1〜2時間全員に
  - その後も不定期に – 各マネージャ
  - 自分のチームと定期的に
  - 気になることはマネージメントミーティングで
- 心理的安全性 / 責任の4象限を見せたらめっちゃ納得した
人の話題は意識を強く持って行かれる
- 「だれそれが辞めたがっている」
  - 意識をそっちに持ってかれる
- 人の話題に意識を取られすぎないように
  - プロダクト、事業、組織の話をしなくて大丈夫？
  - 時にはドライに

TIPS

信頼を勝ち取る
- トップマネジメント / ステークホルダーから信頼を勝ち取る
  - 意識決定が早くなる
  - 例 : リファクタリングのための工数が必要です
    - naoyaさんがいうならまあそうなんだろう
- ビジネス vs エンジニアリングの対立構造に持ち込まない
  - 普段からやってると信頼を失う
  - いざという時の主張を通すために重要

アンチパターン

文化改革症候群
- 「文化を変えよう」は悪手
  - 文化は日々の意思決定の積み重ね
    - つまり結果
    - 結果はコントロールできない
- 意思決定の仕方など（=要因）を地道に変える
  - 要因はコントロール可能
変化に当たって現状否定
- いまこれがダメだから変えたい
  - 今頑張ってる人を否定しちゃう / 無用な敵を作る
- 必要以上に現状を否定しない
  - 変化が必要な利用を未来思考で説く
サーヴァント型リーダーシップの罠
- 聖杯問答問題 : rebuild.fm ep.123
- みんなのために雑用を巻き取る（サーヴァント型の）リーダー
  - 大きな方向性を示してくれない
  - いざという時の意思決定ができない
- ライダー「そんな王に誰が憧れる！」
  - fate / zero
- マネジメントやりたがらない問題
  - サーヴァントにはなりたがらない
エンジニア幸せ向上委員会
- エンジニア的な幸福度がプロダクトの良さに直結するという思い込み
力を集約する != みんなが同じことを考える
- 多様性の真逆
- 価値観の異なるメンバーを同じゴールに向かわせる
  - ゴールの設定、捉え方（フレーム）はコントロールできる
  - 価値観はコントロール不能
    - 宗教になっちゃう

即効性のあるHOW TO

1 on 1
壁打ち相手を見つけよう
- 会話できる相手を見つけよう
フレーミングをきちんとやってみる
技術プロセスの問題解消
- 技術の問題は（瑣末な場合が多いが）解消しやすい
- 即効性が欲しい場合有効
  - うまくいってる感覚、空気がポジティブになる
  - 並行して組織の問題を倒す

まとめ

組織マネジメント、ヒューマンマネジメント
構造に着目
コントロール可能なものを
問題発見にフォーカス、集中できる状況を

お悩み相談室

モデレータ : 玉川憲（Soracom）
- 以下 Q : 事前もしくは会場からの質問 / N : 伊藤直也 / T : 玉川憲
Q : メンバーが守備範囲を広げようとしない
- N : 本人のマインドはコントロールできないので守備範囲のことをさせる
  - 守備範囲のことをやらせる
  - 1on1で守備範囲を設定する
- T : 守備範囲を超えると怒られるのでは？
- N : 指示待ち人間はなぜできるか？
  - 指示待ちのほうが得だから
- T : 失敗にイヤミを言わない、守備範囲外を超えることを称賛する文化
- N : 守備範囲があるということは守備範囲を囲うマネジメントをしているのでは
  - エンジニアという枠が強すぎる問題もありそう
Q : チームを1つのベクトルに向かわせるには？
- T : フレーミングがまちがっている – N : インフラ vs アプリエンジニア問題
  - インフラエンジニアのKPIはSLA / アプリエンジニアのKPIは売り上げ
  - SQLを殺すインフラエンジニアに切れた
    - どっちを優先する？臨機応変に考えるのは難しい
  - 解 : インフラのメンバーをチームにアサインした
    - ゴールを同じにした
- T : AWSが生まれた理由 : アプリエンジニアとインフラエンジニアを会話させるな（APIで会話しろ）
  - テクノロジーで / ヒューマンマネジメントで解決しよう
Q : エンジニア・デザイナーの働き方を経営陣に理解してもらうには？
- T : 信頼貯金が大事では
  - 「あいつが言ってるならそうだろう」という納得
- N : 人事制度や環境で勝負するのは悪手
  - エンジニアのボスとして信頼されるのが必要
  - 役員にならないと戦えないのでは
- T : 内製開発に切り替えるからにはそういう人が経営陣にいるのでは
  - 日本交通の川鍋さんとか
  - そういう人と信頼関係を築こう
Q : ITっぽくない会社がITを活用するには
- N : 一休の場合、自分たちをIT企業だと思ってなかった
  - ITの専門家として自分たちがやればいい
Q : CGM webサービス、売り上げを要求される環境でエンジニアをモチベートするには？
- T : そういうこと言う経営陣はイケてない
Q : CGM webサービス、セクショナリズムが発生している
- N : アプリ・インフラエンジニア問題みたい
  - 組織の形を変える、フレーミングするなどで期待値を変えていく
Q : マネジメントをやる覚悟がつかない（リーダーだけ一気に稼働が増える現状）
- N : 調整するのはリーダー・マネージャーの役割ではない（きちんとやれば）
  - そこに到達する前に調整地獄があるよね…
- T : マネジメント = 調整、という社風もありそう
  - N : いかにして調整しないか、という考え方に切り替えた
  - T : 1on1症候群、みたいな「やるべきこと」にとらわれない
- N : 仕事を切り出し時間を開ける
  - T : エンジニアみんなシニアなのでマネジメントが発生しない
Q : 1on1で自分よりデキるやつと話すには？
- N : 技術力が上のほうが人として優れている、と？
  - キャリアの話するのは難しいかも
  - 技術の話あんまりしなくない？
    - 人や組織の話が大半では
- T : いろいろ聞けるのはかえってたのしいかも
- N : 1on1は道を指し示してあげる場ではない
  - 壁打ち相手どころか壁でよい
- T : スタンドアップミーティングをbotでやってる
  - チームでシェアしたいこと？困ってること？改善したいこと？
  - N : 10人超えるとシーンとするのでは？
    - T : 書いといて読み合せすると縮む
Q : ROI重視のビジネスサイドへの説明を最小限にするには？（セキュリティや技術的負債があとまわしにされる）
- N : 同列で戦ったら絶対に負ける
  - ロジックで攻めるのは無理。普段の信頼関係が大事。
Q : メンバーの責任感、改善が見られない。
- ダメなやつは何をやってもダメ
Q : 若いエンジニアが採用できない
- N : コンテンツで引っ張って採用できる会社は限られている
  - 知名度ない会社はエージェントとうまくやるほうが有効
  - blog書く、メディア力高めるのはエンゲージがある会社が追加でやること
- T : 外資はJob Descriptionをしっかり書くが日本企業は3行
  - もっと突き詰めて書く必要がある。必須のこと / できたほうがいいこと / できなくてもいいこと
- N : 募集かけても反応がイマイチだった事案
  - 募集要項を見直したら全然古かった。書き直したら来るようになった
- T : 採用面接は企業側のアピールの場
  - N : 一休、面接官のエンジニアが上から目線だったので指導した
  - T : 採用面接で不愉快な思いをさせるのはすごいダメージ
Q : 部下が仕事を楽しめてるか不安
- N,T : 1on1しよう
- N : 楽しいだけではダメじゃん？（心理的安全性・快適では？）
  - 雰囲気がいい != いいチーム
- T : そういう兆候を見つけるのが苦手なら、得意な人を探す
Q : 開発速度を定量化するには？
- T : Velocityで可視化できるが、相対値でしかないので注意
  - 先週100が今週110になった、のなら成長
- T : スクラムがプロジェクト管理のための管理になっちゃいけない
  - 定量化したデータで定性的な判断をする
Q : 会社全体の技術力を上げるには？
- N : 技術を学びたいエンジニアは一部でしかない
  - 多様性が必要
    - 技術よりドメイン知識に長けた人
    - アルゴリズムに長けた人
    - ワークライフバランスを撮る人
  - 全員勉強マンを目指すより多様性があったほうが強い
    - 一部のやりたい人がやればいい
- T : スタートアップなので生きのこらなければならない
  - いくばくかの食料が積まれた漂流船
    - みんなが勉強マンだと死んでしまう
    - 泥臭いが大事なところをやってくれる人も大事
- N : 勉強マンには技術基盤的なのをやってもらう
  - T : エンジニアのポートフォリオの問題だよね
- N : リーダーがやってるかどうかがすべて
  - それ以外に学習意欲をコントロールできない
Q : 人の話題にアテンションが行ってしまうのだが？
- N : 人の話題は基本面白い
  - マネージャーミーティングの最後に話すとか、人事の話をしていいミーティングを絞るとか
- T : セレモニーは大事。チームやメンバーをそういう方向に持って行く。

おまけ

N : 飛び道具 : コンサルタント、トップダウン
- 会社は中の人の言うことは聞かない。外の声もときには有効
- 本質的ではないんだけどね…

私感とポエム

以下はこのイベントに参加したことと、最近の状況から考えたことをポエムとしてアウトプットしたものです。イベントそのものと直接の関係はありませんのでご注意ください。

心理的安全性
- 最近のマイブームで、いろんなところで喋ってる
- 率直な意見、批判的な意見を述べても評価が下がるおそれがないのが「心理的安全性が高い組織」
- いきなり「今日からこのチームは心理的に安全です」と言っても誰も信じない
- 各メンバーが、そしてなによりリーダーがそのようにふるまうことで醸成される文化
メンバーがマネジメント論を知る意味
- マネージャーは学ばねばならない（当然）
- マネージャーを育てるメンバーがいてもいい
- いいマネジメントとはなにか、いいマネジメントのもとで成果を出すメンバーのふるまいとはどんなものか、を意識すると、自身の成長もより大きい成果も期待できる
マネージャーなりたがらない問題
- 忙しそうとかサーヴァントに徹してるとか
  - カッコよくない
- マネージャーにも「俺のようになってみろ、俺のようになりたいだろう？」ぐらいの気構えが必要
ソフトウェア開発組織のマネジメント手法は確立していない
- そもそもソフトウェア開発という仕事自体が全然若い
  - 業界を取り巻く環境も変化が早い
- 教科書もプラクティスも決定版が存在しない
- いいと思うものを取り入れて試すしかない
  - こういう先人の話を聞くことは大事
  - One size does not fit all
    - 思考停止しないこと
マネジメントできるもの、できないもの
- マネジメント（コントロール）できるもの
  - 要因
  - 組織構造
  - 意思決定の仕方
- マネジメント（コントロール）できないもの
  - 結果
  - 個々人の意識
  - 価値観
「人」の問題は本質的に面白いのではないか
- 本質的な優先度を飛び越えて最重要項目として認識してしまいがち
  - 誰かが辞めそうだ、最近調子悪いみたい、プライベートがうまくいってない、…
- 人の意識、価値観、感情はマネジメントできない
  - マネジメントしようと無理していないか？
  - マネジメントされることを期待していないか？
「仲が悪いチームが作るとクソゲーができる」（Aiming 小林CTO）
- 週末バーベキューに行くのが「仲良し」ではない
  - 「快適ゾーン」では高い成果は出ない
- 心理的安全性をベースに、プロフェッショナルとしての信頼と敬意を相互に持ったチームを目指そう
最近の反省点
- ソフトウェア開発にまつわる話題は移り変わりが早すぎる
  - 「知っていて当然」と前提を置いて話をしていたようだ
    - 反省
- 知らないことは恥ではなく、知らないままにしておくのが恥である
  - 先輩たちにどんどん聞きましょう
  - 先輩たちは快く教えよう
    - 持ってることを出し惜しみしてもなにもいいことない
めっちゃ長くなった
- 箇条書きでポエム書くの難しい