Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AIで選択肢が広がった組織設計の理想と現実

Avatar for konifar konifar
October 28, 2026

 AIで選択肢が広がった組織設計の理想と現実

Qiita Conference 2026 Autumn
https://qiita.com/conference/2026-autumn

Avatar for konifar

konifar

October 28, 2026

More Decks by konifar

Other Decks in Technology

Transcript

  1. よろしくお願いします 小西 裕介 (こにふぁー / @konifar) タノシ イ! • 株式会社

    Kyash で 8年11ヶ月くらい Fintech のプロダクトを作っています • 2026年7月から CTO になり、 より長い目線でいろいろ取り組んでいく役割になりました • AI で選択肢が広がってむずかしいなと思いながらも楽しくがんばってます ©2024 Kyash Inc. 2
  2. 選択肢が広がった デキ ル! “時間とニンゲンが必要" という前提が変わってきた • • アレもコレも “やろうと思えばできる" と思える状態に

    ◦ 「あの構成の見直しも今ならできるかも」 ◦ 「そこまで詳しくないけどキャッチアップしながらできなくはないか」 ◦ 「時間あったら作ろうと思っていたツールできたわ」 逆に “できない" と “やらない" の見極めががむずかしくなった ◦ 「今なら AI でもっと工夫すればこの期間でもできちゃうんじゃないか」 ◦ 「作ってみて試したほうが早いんじゃないか」 ©2024 Kyash Inc. 4
  3. 理想らしきもの 生産力の飛躍的向上と超少人数体制 • ハーネスを整備し AI が仕様策定から実装、テスト を全て担う • ニンゲンは 「なぜ作るか」、

    「何を作るか」 を決め、 AI の作業に対する評価と意思決定に集中 • エンジニアは職能の垣根を超え、いわゆるプロダクトマネジメント領域を担っていく形に スゴ イネ! 生産力は飛躍的に向上し、トークンコストマネジメントしながらニンゲン組織は超少人数でも高速に大き な成果が上げられるようになっていく。 企業もユーザーもハッピー。 ©2024 Kyash Inc. 5
  4. 現実はどうか キビ シイ! 組織化も AI で簡単に実現 ということにはならない • • ニンゲンのアンラーンに依存

    ◦ AI を中心とした考え方、動き方に皆がすぐに適応できるわけではない ◦ AI の進化が早くキャッチアップし変化し続ける必要がある ◦ 未経験の領域に染み出していくのもそんなに簡単にはできないし意思決定が雑になる AI 云々関係なく、 前提の整備の不足が露呈 ◦ プロダクト開発プロセス ◦ デザイン/コーディング/テストのルール ◦ ドキュメント管理 ©2024 Kyash Inc. 6
  5. 1. AI 地盤推進チームの組成 小手先の改善で止まらないように地盤を整える • 個人の工夫ではなく業務を変える AI の活用を進めるには、活用地盤が必要 • 地盤がなくてもシュッと改善はできてしまうがゆえに、小手先の改善が溢れかえりそうなのでフォ

    ローアップするチームを組成して整えていくことにした • AI をよく使い、持論を持って意見を出せるメンバーを集めてチームアップ ©2024 Kyash Inc. 社内 Slack より抜粋 9
  6. 小手先の改善とは たとえば CS チームの警察照会業務 の改善 • 警察から取引の照会依頼が来ることがあり、 管理画面から取れない情報取得や回答作成は CS チームからエンジニアに依頼がくる

    • 「エンジニアの作業を誰でもできるように、かつ楽にするためにスキル化しよう」 といった改善はす ぐにできてしまうので飛びつきがちだが、 「CS のみで業務が完結できるようにする」 ところまで 考えてやりきりたい • 警察からの照会依頼を受け取って回答文を出すエージェントを作れるとよさそうだが... ◦ bot、 API トークン管理、 データ取得権限、 機微情報の取り扱い など考えることが多くて止まってしまう ◦ こういうあるべき改善案を実行するのに必要な地盤を整えていくためのチーム組成 ©2024 Kyash Inc. 10
  7. 2. 事業部ごとのプロダクトチームからプロジェクトチーム制へ CTOが優先順位を決め、 流動的に動けるプロジェクト制 • もともとウォレット/クレジット/法人送金の3事業部ごとに Mobile/Backend のエンジニアが 4〜5人ずつ所属し、 プロダクトチームとして開発を進めていた

    • 事業部を超えて注力するべき開発が色々出てきそうだったことに加え、 サイバーセキュリティ対策 などの緊急度の高い “守り" も柔軟に機動力高く取り組めるよう、 プロジェクトごとにチームを組 成するプロジェクトチーム体制へ移行 • 各事業部と開発目線でのプロジェクトを俯瞰し、 CTO が優先順位を見直し続ける形へ ©2024 Kyash Inc. 12
  8. プロジェクトごとのチーム組成はアンチパターンでは? AI で前提が変わり、 軌道修正しながら試してみている • チームビルド、 ドメイン理解、 認知負荷、 アウトカムへの関与といった観点で、 セオリーとしては

    プロダクトチームを作れと言われている • AI の進化によってキャッチアップ方法も劇的に変わってきたこと、 まだエンジニアの人数が20人 程度と少ないこと、 プロダクトも toC と toB のみであることから決断 • まだ開始3ヶ月程度で、軌道修正しながら進めている ◦ 当然ながらチームビルド、 認知負荷 の課題の声は上がってきていて、 振り返って軌道修正し続けている ◦ AI を活用する前提での動きは、先に組織体制や業務フローを変えないと変わらない。 組織体制を変える意 思決定はマネジメントにしかできない ©2024 Kyash Inc. 13
  9. 3. プロダクトマネジメントの機能整理 プロダクトマネージャーは置かない • プロダクトマネジメントの “機能" は必要だが、 特定のメンバーがすべてオーナーシップを持つ形 をやめていこうとしている •

    ①プロダクトマネジメントとは何か、 ②どのチーム/誰 が担うべきか、 ③その状態に向けてどう取 り組んでいくか のステップで整理 • プロジェクトごとの仕様の策定、進行からリリース、振り返りは エンジニア が責務を持っていく形 に変化していく ◦ 当然、 誰でもすぐに担っていけるわけではない。目指す形をすり合わせたのみ。 次にそこに向けてどうして いくかを考えて進めていく ©2024 Kyash Inc. 15
  10. 採用の要件も変化 採用では 自走して領域を広げられる人かどうか を見る • 今の組織のケイパビリティを考えると、 AI 慣れしている上で、 ある程度自走してプロジェクトを任 せられる人、

    かつ領域を広げていくことに抵抗はないという人 を採用する ◦ • 特に後者が重要で、 スタンスはなかなか変わりにくいので2次面接でよく見極めていく 本当はもっと広く受け入れる組織にしていきたいが、 今はこういう方針 ©2024 Kyash Inc. ガン バロ ウ 17
  11. 4. マネージャーも手を動かし続ける CTO/EM も何かしら開発する • • AI に直接触れていかないとわからない ◦ 現時点では、

    直接触って開発することが意思決定の正しさを上げていける唯一の方法 ◦ 今の開発の不便に鈍感にならないようにする 組織のマネジメントのみという状態にはしない ◦ • プレイングマネージャーを維持。 プレイング割合を調整するのはマネージャーの仕事 両方やらないといけない状態で、 マネージャー自身も生産力を上げる実験をし続ける ©2024 Kyash Inc. 19
  12. 試してわかったことを組織の改善に活かす 手を動かしながら実験し、 何がどこまでできるかを把握する • • Web サイトの基盤リプレイス ◦ e2eテストの整備と自動マージ ◦

    AI を前提としたデザイナーの開発プロセスの構築 ◦ 脆弱性パッチの評価と自動適用 データ基盤刷新 ◦ 詳しくない領域でのレビュープロセスの工夫 ◦ 現状の開発プロセスをひととおり経験した上で改善 ©2024 Kyash Inc. 20