今こそメテオフォールが必要なのかもしれない

Transcript

1. 今こそメテオフォールが必要なのかもしれない トップダウンvsボトムアップ？ 組織のAI推進知見を持ち寄るmeet up 株式会社ビットエー ourlyカンパニー 相澤 宏亮 (@tigers_loveng)
2. 自己紹介 相澤 宏亮 (あいざわ こうすけ) 役割 執行役員CTO 兼 CTO(Chief T-Shirt Officer) 経歴 2016年：京都大学大学院理学研究科中退 2017年：株式会社PLAN-Bに新卒入社 2020年：株式会社ビットエーに転職 & ourly事業立ち上げ 2023年：ourly株式会社に転籍 2024年：執行役員CTOを拝命 (7月〜) # Ruby # PHP # Java # 新卒/中途採用 # 社内ハッカソン その他 # キングダム # ジョジョ # HUNTER×HUNTER # 刃牙 # 新規事業立ち上げ # 野球観戦 # 阪神タイガース好きと繋がりたい 01 / 19
3. 会社概要 株式会社ビットエー ourlyカンパニー 東京都品川区西五反田一丁目5番1号 A-PLACE五反田駅前ビル５階 2011年7月 カンパニーCEO　 坂本 良介 カンパニーCOO 髙橋 新平 執行役員CTO 相澤 宏亮 執行役員 乗松 諒 執行役員 河野 芳紀 正社員15名、業務委託5名 インナーコミュニケーションプラットフォーム「ourly」の企画・開発・販売 「ourly」を用いた組織開発支援 社名 所在地 設立年月 役員構成 従業員数 事業内容 02 / 19
4. 4 ・設立5年目、HR領域のBtoB SaaS ・組織文化を変えることで、組織 /経営課題を解決 ・プロダクト × コンサルティングの両輪で支援
5. 本日伝えたいこと ▪ ① ボトムアップ（「使ってね」）だと、改善は身近な業務効率化に限定される ▪ ② 「業務改善」ではなく「業務改革」を起こすには、トップダウンが有効 ▪ ③ ただし、トップダウンは現場への"下ろし方"が9割 　　– 腹落ちを作る ＝ マネジメントは「翻訳業」 　　– 成果責任はマネジメントが持ち、メンバーはプロセスで評価する ▪ AI推進はツール導入ではなく、マネジメント設計である 04 / 19
6. 1｜ボトムアップだと、改善が限定的 導入：AIは広がる一方で、組織内の「差」が広がっている ▪ 個人レベルのAI活用は普及する一方で、組織内のAI リテラシーの差は広がっている ▪ ハーネスやプラグインまで整備できていなくても、 AIを利用できる環境はある 　　– その環境の中で「使う人／使わない人」の差が大きくなっ ていく ▪ 結果、組織全体を「AIネイティブな組織」に変えら れていない ▪ 問い：何から着手し、何が効いて、何が効かなかっ たのか AI活用度 時間 → 使う人 使わない人 差 05 / 19
7. 1｜ボトムアップだと、改善が限定的 最初の取り組み：努力目標では進まなかった ▪ 全社定例の前に1時間を確保し、業務棚卸し→AI化できそうな業務を探す→30分試す→共有 （1〜2Q実施） ▪ 起きたこと 　　– AI化できる業務を「見つけられる／られない」の個人差 　　– AI習熟度・ITリテラシーの差 　　– 「楽になるが成果に直結しない」改善に偏る（例：朝のニュース確認の自動化） ▪ ボトムアップ的アプローチは、いまいち機能しなかった 06 / 19
8. 1｜ボトムアップだと、改善が限定的 なぜ努力目標・ボトムアップは効きにくいのか ▪ 「10%の時間で」「隙間時間で」＝明確なミッショ ンにならず、優先度が下がる ▪ ベンチャー／スタートアップは常に忙しい → リリー ス前は容易に後回し ▪ 業務外で触っても「お試し利用」にとどまりがち ▪ 効果がないわけではない：意識づけ・習慣化・tips共 有による業務効率化には有効 ▪ ただし、期待値とのギャップが生じる 　　– 経営・マネジメントが求めるのは、細かい改善ではなく 『AIネイティブ化による業務改革』 経営・マネジメントの期待 AIネイティブ化による『業務改革』 ボトムアップで届く範囲 意識づけ・習慣化・業務効率化 ギャップ 07 / 19
9. 2｜業務改革には、トップダウンが有効 ここからが本題：「業務改善」ではなく「業務改革」を ▪ 目指すのは細かい業務改善ではなく、AIネイティブ化による業務改革 ▪ 例：「1日1PR」をどう増やすか 　　– 業務改善：レビューを早く回して2PRに増やす（今の延長線上） 　　– 業務改革：AI前提に開発フローを再設計して20PRを狙う（前提から変える） ▪ その業務改革を起こすために得た学びを、ここから共有します 　　– 学び1：トップダウンで業務に組み込む／学び2：目標設定と業務分解／学び3：メテオフォール型の目標 08 / 19
10. 2｜業務改革には、トップダウンが有効 学び1：AI活用はトップダウンで業務に組み込む ▪ メンバーは「見えている景色」の範囲でしかAI化できない（良し悪しではない） 　　– 視座・視野はマネージャー／部長レイヤーと異なる ▪ 結果、目の前・身近な業務へのAI化に留まりやすい ▪ 成果に結びつけるには、トップダウンで業務に組み込む必要がある 09 / 19
11. 2｜業務改革には、トップダウンが有効 学び2：マネジメントが「目標設定」と「業務分解」を担う ▪ AI活用で大事なのは「目標の立て方」と「業務分 解」 ▪ マネジメントは業務分解力が高い＝本質的な課題 （ボトルネック）を見極められる ▪ よくある失敗：処理の「最初と最後」だけ改善しよ うとする 　　– 実際のボトルネックは中間の特定の処理にあることが多い ▪ マネージャーが作業分解・目的整理・期待値設計を 担うべき 目標：開発サイクルを縮める 企画・要件 実装・レビュー ＝ボトルネック テスト・リリース 「最初と最後」だけ改善しても効かない ↑ 中間の特定処理に 効かせる 10 / 19
12. 2｜業務改革には、トップダウンが有効 学び3：ブレイクスルーには「メテオフォール型」の目標 ▪ 「2倍」：努力の延長線上で届く（PR分割・レビュー サイクル短縮など） ▪ 「20倍」：今の延長線上では『無理』→ だからこそ 前提を疑うきっかけになる ▪ 狙いは「無茶して24時間働け」ではない 　　– 定数として置いてしまっている前提そのものを疑わせるこ と ▪ メンバーからは突拍子もない目標は出てこない → トップから落とす 2倍：努力の延長線上 20倍：前提を疑う 11 / 19
13. 2｜業務改革には、トップダウンが有効 具体例：PR実装「3時間」を疑う（24倍への分解） ▪ 前提：1PRの実装に3時間 → 20倍＝60時間／日では 物理的に無理 ▪ 「人間の手で書く」前提を疑う 　　– AIエージェントなら数分〜15分で実装 → 約12倍 ▪ 「要件を手で打つ」前提も疑う 　　– 音声→その場で文字起こし→指示 で約7.5分 → 約24倍 ▪ 「2PR出そう」という発想からは、絶対に生まれない アイデア 3時間 15分 ×12 7.5分 ×24 ①「手で書く」前提を疑う ②「要件入力」も疑う ※ 棒の高さはイメージ 12 / 19
14. 3｜トップダウンを現場に浸透させるテクニック 「メテオフォールって、メンバーに嫌がられそう…」 ▪ 大事なのは、その目標を達成できるかどうかではない ▪ そこに向かっていくための「腹落ち感」をどう作るか ▪ なぜその数値か／なぜそのスピードか／なぜ今やるのか を、丁寧に何度も伝える ▪ ＝マネジメントは「翻訳業」 13 / 19
15. 3｜トップダウンを現場に浸透させるテクニック 翻訳の例：「PRを20倍」を現場にどう下ろすか ▪ PRが20倍作れるようになれば（＝正しい方向を向い ていれば） 　　– プロダクトの進化速度も20倍になる可能性を作れる ▪ 20倍速い＝仮説検証スピードが20倍 → 素早く答え にたどり着ける ▪ 「自分たちが20倍速くものを作れている」という指 標になる ▪ 伝え方はメンバーの価値観・組織文化によって翻訳 が変わる 　　– ourlyの場合は「プロダクト起点」で語るのが効く PRを20倍出せるようになる プロダクトの進化速度が20倍に 仮説検証20倍 → 素早く答えにたどり着く ※ 翻訳はメンバーの価値観・組織文化に合わせる（ourly＝プロダクト 起点） 14 / 19
16. 3｜トップダウンを現場に浸透させるテクニック 成果責任はマネジメントが持つ ▪ メテオ目標は、未達でも評価を下げない（絶対にし てはいけない） ▪ 成果に結びつけるのはマネジメントの責任 ▪ メンバーが評価されるのは 　　– ミッションに取り組む姿勢 　　– どれだけ試行錯誤を繰り返し、近づけたか（プロセス） マネジメント 成果責任 （成果に結びつける） メンバー プロセスを評価 （姿勢・試行錯誤） 未達でも評価は下げない 15 / 19
17. 3｜トップダウンを現場に浸透させるテクニック 評価設計：数値目標を安易に評価へ入れるとハックされる ▪ グッドハートの法則：ある指標が目標にされた途端、その指標は良い指標ではなくなる ▪ 例：PR作成数を評価に組み込む → 10行の変更を1行×10PRに分割するハック ▪ 数値は評価から切り離し、「ミッション」として持ってもらう ▪ 評価対象はプロセス（姿勢・試行錯誤） 16 / 19
18. 4｜現在地とこれから 現在地：何を「成果」として見ているか ▪ デプロイサイクル：1日1〜2回まで到達済み ▪ リリースサイクル（顧客が価値を感じる単位）：従 来 2週間〜1週間に1回 　　– 四半期で6〜10機能ほど ▪ 目標：四半期30本（3倍以上） 　　– 設計〜テスト〜リリースを1週間で回す 　　– 5人日規模の機能 → コーディング／レビュー／テストの自 動化が必須 ▪ あくまで仮説ベース：意味がなければ緩める 6〜10本 / 四半期 30本 / 四半期 ×3以上 設計〜テスト〜リリースを1週間で回す 17 / 19
19. 4｜現在地とこれから 今取り組んでいること：AI活用を「個人技」から「組織能力」へ ▪ AI活用を個人技から組織能力にしていく ▪ 経営陣（CEO／COO等）が率先して活用 　　– 自分の仕事のやり方を分解 → AIの指示に落とし込む → ス キル化 　　– スキルをメンバーに配布 → 使ってもらい → 報告・フィー ドバックで改善 業務を分解 スキル化 メンバーに配布 報告・改善 個人技 → 組織能力 18 / 19
20. まとめ：明日から試せること ▪ まず問う：延長線上の改善か、AI前提への「再設計」か ▪ AI前提に変えるなら、トップが「エイヤ」で突拍子もない目標を出す ▪ 現場に下ろし、方向性を示し、前提を疑い、業務を「再設計」する ▪ AI推進はツール導入ではなく、マネジメント設計である 19 / 19