1 業務のトイルをバスターせよ 〜AI時代の生存戦略〜 CoLab Conf U35限定テックカンファレンス 2025年12月13日 株式会社TOKIUM VPoE 橘高 俊 

どんなことを話すの？ 2 今回のテーマ「AIとキャリア」 U35世代が10年後も求められる存在であり続けるには、今何を選び、どう備えるべきか ● 活躍するために獲得すべき「スキル」は何か ● どのような「考え方」であれば生き残ることができるのだろうか ● 「再現性のある戦略」とはなんだろうか ● 今手を付けた方が良い「技術」はなんだろうか ● 分野に固執せず、どんどんと「越境」すべきなんだろうか etc… これまでのキャリア戦略は「具体的にどんなもの」だったのか？ なぜそれが「AI時代でも通用する」と考えているのか？ むしろ「AIが戦略実行の強い味方となる」と考える理由は何か？ 

Contents 1. 自己紹介 & 会社紹介 2. キャリアとケーススタディ 2.1. ケース１）共通基盤チームの誕生 2.2. ケース２）CREチームの誕生 3. 「業務のトイルを削減する」ということ 4. AIの「強み」を活かす 5. 明日から何ができるか　 3 

自己紹介 4 自己紹介 & 会社紹介 経歴 in TOKIUM 2017年　WebエンジニアとしてTOKIUM に入社（社員14人） 2019年　データ連携基盤チームをリーダーとして立ち上げ 2020年　改善チーム（SRE + CRE）へ異動 2021年　CREチームをリーダーとして立ち上げ 2023年　TOKIUM 初のEMとして複数チームのマネジメントを経験 2024年　開発部長としてエンジニアリング組織の成長を牽引 2025年　VPoE として全社におけるエンジニア採用、育成をリード @xi_kax | いかねこ 橘高　俊 Kittaka　Shun 

会社紹介 5 自己紹介 & 会社紹介 会社名 設立日 所在地 従業員数 代表取締役 株式会社TOKIUM 2012年 6月 26日 東京都中央区銀座6-18-2 野村不動産銀座ビル 12F 約240名 (2025年11月、正社員のみ) 黒﨑 賢一 TOKIUMの志 未来へつながる時を生む 

サービス紹介（SaaS） 6 自己紹介 & 会社紹介 創業以来、10年以上一貫して支出にまつわるサービスを提供。 TOKIUMシリーズは直近5年間で導入社数が6倍以上増加し、2025年11月末には3,000社を超える。 2012年6月 創業 2016年2月 「TOKIUM経費精算」リリース 2020年9月 「TOKIUMインボイス」リリース 2022年1月 「TOKIUM電子帳簿保存」リリース 2024年6月 「TOKIUM契約管理」リリース 2025年1月 「TOKIUM請求書発行」リリース 累計導入社数 3,000社を突破 ※25/11末時点 

サービス紹介（経理AIエージェント） 7 自己紹介 & 会社紹介 2025年7月より「経理AIエージェント」サービス提供を開始。 AIとプロスタッフが連携し、経理業務の自動化を推進するサービスとして拡大中。 2025年7月 「TOKIUM AI出張手配」リリース 「TOKIUM AI経費承認」リリース 「TOKIUM AI規程管理」リリース 「TOKIUM AI経費監査」リリース 「TOKIUM AI新リース判定」リリース 2025年8月 「TOKIUM AI請求照合」リリース 2025年9月 「TOKIUM AI明細入力」リリース 

さっそく本題へ 8 これまでのキャリア戦略は 「具体的にどんなもの」だったんでしょうか？ 自己紹介 & 会社紹介 

2.キャリアとケーススタディ 9 

これまでのキャリア 10 キャリアとケーススタディ 2015 - SIer期 新卒で Sler に入社。数百台のサーバたちと過ごす。 2017 - 10名期 TOKIUM (当時 BearTail) へ転職。Web開発初心者。 2019 - チーム起ち上げ期 共通基盤チーム、CREチームの２つを立ち上げて運用。 2023 - EM期 ４チームを同時にマネジメント。マネージャしてる。 2024 - 部長期 AI Agent 開発が始まる。手も動かしてガシガシ開発。 2025 - VPoE期 2025年12月から新設。採用・キャリアの責任も負う。 

これまでのキャリア 11 キャリアとケーススタディ 2015 - SIer期 新卒で Sler に入社。数百台のサーバたちと過ごす。 2017 - 10名期 TOKIUM (当時 BearTail) へ転職。Web開発初心者。 事例として 話すところ チーム起ち上げ期 共通基盤チーム、CREチームの２つを立ち上げて運用。 2023 - EM期 ４チームを同時にマネジメント。マネージャしてる。 2024 - 部長期 AI Agent 開発が始まる。手も動かしてガシガシ開発。 2025 - VPoE期 2025年12月から新設。採用・キャリアの責任も負う。 

12 ケース１）共通基盤チームの誕生 

とある一幕 13 ケース１）共通基盤チームの誕生 外部システムとの疎通がうまくいってないっぽいんですけど このシステム周りのことって分かります？ クライアント 外部サービス 外部サービス 暗黙知 暗黙知 暗黙知 あー、それね。創業メンバーの作ったコードだな。 触らないほうがいいと思うよ。結構、樹海だから。 あー。。。「樹海」ね、理解 🤔 

クライアント どういった課題に取り組まなければならなかったか 14 ケース１）共通基盤チームの誕生 外部サービス 中継サービス クライアント 家計簿アプリ 背景 元々は家計簿アプリ用に開発されたが、 TOKIUMに流用している共通の連携機能である 課題 家計簿アプリについても知る必要があり、 レガシーかつ属人的な機能になっていた 重要課題 技術力のある創業メンバーが 管理や調査業務 に追われてしまい、 重要人物のリソースが圧迫される 

課題を分解して「強み」をぶつけて解決する 15 ケース１）共通基盤チームの誕生 重要課題 技術力のある創業メンバーが 管理や調査業務 に追われてしまい、 重要人物のリソースが圧迫される 難解なのはコードの複雑性に起因 技術的には決して高度ではない ドキュメントがないため手探り状態 暗黙知を整理するかが重要 ある程度固まった時間が必要 かつ継続的な運用を整える CSとWeb開発の基礎 一通り開発をやってる 言語化経験 当時、資料作りを最もしていた 集中する 小回りの効く立場（メンバー） 持っている「強み」を活かして どう課題にコミットメントするか 

16 課題解決のために：観察し、記録し、確認する ケース１）共通基盤チームの誕生 自ら調べ、整理し、 そのレビューをお願いして 正しい情報を積み上げる 不明瞭だった仕様が 明らかになったことで 人もアサインできるように！ 

解決したことで得られた成果 17 ケース１）共通基盤チームの誕生 元々やってた創業メンバーは担当から完全に外れ、 新しいポジション（このときは情シス）に着任した 容易に引き継ぎ可能であったため、 正社員なしでも回るような組織となった 責務が分解され、問題発生時の責任や 問い合わせ先が明確になった 創業メンバーが運用作業から解放された！ 誰でもできる業務になったことで引き継ぎもスムーズに！ 特別な引き継ぎ不要で 運用に必要な資料が揃った 開発に必要な技術レベルが 明瞭になった 問題発生時の影響範囲と 対応するチームが一致した 

18 ケース２）CREチームの誕生 

とある一幕 19 ケース２）CREチームの誕生 カスタマーサクセスのチームから問い合わせ来てますね。 「お手すきの際に」ってありますけど、、？ とりあえず、今ある課題が終わったら対応しようかな。 手が離せなくって、コンテキストスイッチも気になるし。。 分かりみが深い。 であれば、代わりに調べて回答しときますね 🤝 お疲れ様です！ お手すきの際に 確認お願いします！ ... まずい、締切が...!! 返信は早いほど良い 

どういった課題に取り組まなければならなかったか 20 ケース２）CREチームの誕生 新規開発チーム 改善チーム 開発部 開発改善 問い合わせ対応 背景 新規開発に集中しつつ改善も推進するために 「改善」「問い合わせ」業務を切り出した 課題 専門性の高いメンバーが多かったこともあり、 「問い合わせ」の優先度が上がりにくかった 重要課題 問い合わせ対応には 類似した対応 が多く かつ 割り込み的な対応が頻発 したため、 専門性が活かしにくい状態となっていた 専門性の高いメンバーが所属 

課題を分解して「強み」をぶつけて解決する 21 ケース２）CREチームの誕生 重要課題 問い合わせ対応には 類似した対応 が多く かつ 割り込み的な対応が頻発 したため、 専門性が活かしにくい状態となっていた 問い合わせ対応において重要なのは 専門性でなくホスピタリティ 質問の多くは「技術」ではなく 「プロダクト仕様」を問うものである その多くは繰り返しであり 似た質問や作業が多い状態だった SIer での経験 専門用語は直訳せず、翻訳する 新規開発チームの経験 そいつの開発者、俺だもん 重要な観点の理解 文書化に必要な観点を知っている 持っている「強み」を活かして どう課題にコミットメントするか 

課題解決のために (1/2)：とにかく文書を残していく 22 ケース２）CREチームの誕生 手順置き場を作り 複数回発生する手順は とにかく記録する 誰でもすぐに同じ品質で 「作業」または「問い合わせ」の 対応ができるように！ 

課題解決のために (2/2)：CREとしてのキャリアを描く 23 ケース２）CREチームの誕生 ※2022年頃に作成したCREチームのスキルマップ 問い合わせ業務をスキルごとに 分解し、専門性のある分野として スキルマップを作成 「問い合わせ」に含まれる スキルが示され、 CREの専門性が明らかに！ 

課題を解決したことで得られた成果 24 ケース２）CREチームの誕生 問い合わせ対応におけるエンジニアの役割が明瞭になり 期待する役割として伝えやすくなった 専門性の高いメンバーは急な差し込みを気にせず より複雑な業務に集中することができるようになった 質問や作業依頼が一箇所にまとまるようになり 「何に重点的に対応するとよいか」判断しやすくなった 問い合わせ対応は専門的なスキルとして整理され TOKIUMにおいて新しく「CRE」というロールが定義された！ 問い合わせ対応を 専門性のある業務として定義 問い合わせ対応の 責任が明らかになった 何の業務を改善すべきか 分析してながら進められた 

次なる疑問 25 キャリアとケーススタディ 個々の戦略や背景について分かりました。 しかし、それらは再現性がある話になり得るんでしょうか？ 「共通していた戦略（考え方）」は何なんですか？ 

3.「業務のトイルを削減する」ということ 26 

そもそも「トイル」とは何か 27 「業務のトイルを削減する」ということ SREにおけるトイルの定義 Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows. Not every task deemed toil has all these attributes, but the more closely work matches one or more of the following descriptions, the more likely it is to be toil: Ref: https://sre.google/sre-book/eliminating-toil/ 手作業 (manual) 反復的 (repetitive) 自動化可能 (automatable) 戦術的 (tactical) 永続的な価値がない (devoid of enduring value) スケールする (scales linearly as a service grows) 

そもそも「トイル」とは何か 28 「業務のトイルを削減する」ということ SREにおけるトイルの定義 Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows. Not every task deemed toil has all these attributes, but the more closely work matches one or more of the following descriptions, the more likely it is to be toil: Ref: https://sre.google/sre-book/eliminating-toil/ 手作業 (manual) 反復的 (repetitive) 自動化可能 (automatable) 戦術的 (tactical) 永続的な価値がない (devoid of enduring value) スケールする (scales linearly as a service grows) \ 今回、例として取り上げるところ / 

あれ？この流れ、既視感あるな？ 対応方法、毎回同じじゃない？ この手の業務、終わりなくない？ 反復的(repetitive) 29 「業務のトイルを削減する」ということ 共通基盤チームの誕生 ● 管理業務は 定期的 にやってくる ● やってた 管理業務 は毎回同じ ● システム廃止までこの 業務は続く CREチームの誕生 ● 問い合わせ対応には 定期的 に発生 ● 類似した対応 が多い ● 明確な 終わり はない 共通するポイント この業務は 反復的(repetitive)な要素を持つ これまでのケース 

戦術的(tactical) 30 「業務のトイルを削減する」ということ 共通するポイント この業務は 戦術的(tactical)な要素を持つ これまでのケース 共通基盤チームの誕生 ● 忘れた頃 に期限付きでやってくる ● 毎日ではないので 現状維持 ● 管理業務 がなくなることはない CREチームの誕生 ● お客様からの問い合わせは 予測不能 ● 問い合わせごと に対応をしていく ● 質問事項が なくなるわけではない 手動での突発的な対応だな 根本解決ではなく、その場しのぎだな 今の問題は解決するが再発は防げないな 

スケールする(scales linearly as a service grows) 31 「業務のトイルを削減する」ということ 共通するポイント この業務はスケールする (scales linearly as a service grows) 要素を持つ これまでのケース 共通基盤チームの誕生 ● 参照するサービスが 今後増える かも ● 業務の 発生頻度が増える と回らない ● 少なくとも 楽になることはない CREチームの誕生 ● サービス成長に伴い量も増える ● 場当たり的な対応 が増えてしまう ● 人を増やす しか対応策が取れない サービス成長に伴って作業量も増えるな 運用作業に忙殺されそうだな コストが膨らみ続けるな 

業務のトイルをバスターせよ 32 「業務のトイルを削減する」ということ 共通基盤チームの誕生 CREチームの誕生 手作業 (manual) レガシーなコードを読む SQLやパッチを自分で打つ 反復的 (repetitive) 似たような運用対応が多い 似た質問や作業が何度も来る 自動化可能 (automatable) - エンジニアでなくとも対応可能 戦術的 (tactical) エッジケースが多い 問い合わせごとの短絡的な問題解決 永続的な価値がない (devoid of enduring value) システムの改善ではない 将来の顧客体験は変わらない スケールする (scales linearly as a service grows) 利用者が増えるほど増加する 利用者が増えるほど増加する トイルと似た性質を持つ業務は確かに存在しており、 これらの業務が減ることは「価値の高い業務に集中できること」に繋がる 

次なる疑問 33 「業務のトイルを削減する」ということ 業務のトイルがどのようなものか、 また、業務において重要であることは分かりました。 しかし、それは「生存」するための「戦略」なのでしょうか？ 

5.「業務のトイルをバスターすること」は 生存戦略なりえるのか？ 34 

「それぞれ」の視点に立って考える 35 「業務のトイルをバスターすること」は生存戦略なりえるのか？ 「事業的な視点」としてみたとき、 「業務のトイルをバスターすること」のメリットは？ 「マネージャ的な視点」としてみたとき、 「業務のトイルをバスターすること」のメリットは？ 上司 会社 個人 「キャリア的な視点」としてみたとき、 「業務のトイルをバスターすること」のメリットは？ 

「個人」の視点に立ってみる 36 「業務のトイルをバスターすること」は生存戦略なりえるのか？ 高い視座を持たなければ 効果的に解決すべき課題発見は難しい 解決のためにはコミュニケーションのみならず 幅広い技術的知見が必要になる 組織的な持続可能性を生み出すためには 複数人を巻き込まなければならない 「業務のトイルをバスターすること」は容易ではない。様々な能力を総動員させて問題解決にあたる必要が あるため、幅のある多様な経験と知識の組み合わせによる複雑な問題解決を強みとして獲得できる。 何を解決すべきなのか どう解決すべきなのか 誰と解決すべきなのか 「業務のトイルをバスターすること」は 「幅(RANGE)のあるキャリア(※2) 」に繋がる 

「上司」の視点に立ってみる 37 「業務のトイルをバスターすること」は生存戦略なりえるのか？ ハイパフォーマーが自動化可能な作業や誰でもできる業務に多くの時間を取られている状況は、組織の生産性 と個人の成長の両面で機会損失である。こうした課題を特定し、組織的に解決する仕組みを持つことが、持続 可能な事業成長につながる。（※ただし、チーム特性が類似している場合に限る） 新しい組織 以前の組織 Aチーム Cチーム Bチーム Aチーム Cチーム Bチーム 「業務のトイルをバスターすること」は 「より強みを活かせる組織になること」に繋がる 

「会社」の視点に立ってみる 38 「業務のトイルをバスターすること」は生存戦略なりえるのか？ 🔼 売上 外部支出 粗利 給与 税金 純利益 🔽 🔼 🔼 🔼 🔼 お客様に価値提供して、十分な売上・粗利を上げ、給与・純利益で従業員・株主に還元し、それにより更に お客様への提供価値を高めるサイクル（＝バランス）をつくり、急速かつ持続可能な事業成長を実現する。 「業務のトイルをバスターすること」は 「外部支出を恒久的に下げること」に繋がる 

「業務のトイルをバスターすること」がもたらすメリット 39 「業務のトイルをバスターすること」は生存戦略なりえるのか？ 「業務のトイルをバスターすること」は 「持続可能な成長の基盤」に繋がる 「業務のトイルをバスターすること」は 「組織全体の生産性向上」に繋がる 上司 会社 トイルをバスターすることは 会社・チーム・個人 の 「三方良し」を実現できる戦略である 個人 「業務のトイルをバスターすること」は 「幅広い業務経験でキャリアの選択肢を広げること」に繋がる 

次なる疑問 40 「業務のトイルをバスターすること」は生存戦略なりえるのか？ 「業務のトイルをバスターすること」は 各視点において効果的な戦略であることが分かりました。 それはAI時代においても有力な「生存戦略」なのでしょうか？ 

4.AIの「強み」を活かす 41 

AIの「強み」が発揮される条件を知る 42 AIの「強み」を活かす 現実世界の例 ポーカー 不完全情報ゲームにおいても DeepStackがプロプレイヤーに勝利 囲碁 囲碁というルール下において Alpha Goが世界ランク１位に勝利 『制約と誓約』 「閉じられた秩序（コンテキスト）」にて、AIの「強み」は活かされる エンジニアリングの例 静的解析 Go や Ts などの型システムにより エラーの少ないコードが実装される 規約・設計 AGENTS.md や ADR によって 精度の高いコードを生成可能 

業務のトイルをバスターするために重要なこと 43 AIの「強み」を活かす 仲間を集め、課題を整理し課題解決にどんどん取り組む 「閉じられた秩序（コンテキスト）」において 課題解決のアプローチを決める 方針を決める 行動する 観察する 業務を観察し、取り組むべき課題を見極める （取り組むべき範囲を制限する） 業務のトイルをバスターするために重要なこと 

業務のトイルをバスターするために「観察する」 44 AIの「強み」を活かす 方針を決める 行動する 観察する 事例を調査する 大量データを分析する 社内を見渡す 調査範囲を「人」が定め、 過去の記事やデータの取得に「AI」を用いる 誰が何をやるか 分析対象を「人」が決め、 大量のデータ分析に「AI」を用いる 業務のトイルを「人」が見出し、 解決すべき課題の分解に「AI」を用いる 

業務のトイルをバスターするために「方針を決める」 45 AIの「強み」を活かす 方針を決める 行動する 観察する 影響を考える 仮説を立てる アプローチを探る 変更対象を「人」が定め、 変更による影響の調査に「AI」を用いる 誰が何をやるか どういう成果を狙うのかを「人」が定め、 似た仮説の探索に「AI」を用いる 解決すべき課題を「人」が定め、 取りうるアプローチの探索に「AI」を用いる 

業務のトイルをバスターするために「行動する」 46 AIの「強み」を活かす 方針を決める 行動する 観察する 実行順序を決める 方針を設計する 小さく始める 優先度の測り方を「人」が定め、 優先度に沿った並び替えに「AI」を用いる 誰が何をやるか 成功と失敗の条件を「人」が定め、 得られた結果の分析に「AI」を用いる 検証する仮説を「人」が定め、 小さく試す（検証する）ことに「AI」を用いる 

「業務のトイルをバスターするために重要なこと」と「AI」 47 AIの「強み」を活かす 仲間を集め、課題を整理し 課題解決にどんどん取り組む 「閉じられた秩序（コンテキスト）」において 課題解決のアプローチを決める 方針を決める 行動する 観察する 業務を観察し、取り組むべき課題を見極める （取り組むべき範囲を制限する） 人 × AI 🚀 複数のコンテキストから 情報を取り出して整理する！ 人 × AI 🚀 AIを味方につけて 共に適切なアプローチを探る！ 重要なこと 誰がやるか 人 × AI 🚀 AIを味方につけて 「あとはやるだけ」はAIに投げる！ 

次なる疑問 48 AIの「強み」を活かす 明日から何をすればいいんでしょう？ 

5.明日から何ができるか 49 

観察し、方針を決め、小さく始めて、学び続ける！ フィードバックループを、AIと協調し、高速に回した分だけ強くなる！ 業務を観察し、アプローチを考え、素早く実行する 50 明日から何ができるか 一貫性のある一連の行動によって、課題解決に取り組む 組織において、スケーラビリティのある解決策を考える 方針を決める 行動する 観察する 業務を観察し、取り組むべき課題（トイル）を見極める 

We are hiring !!!! 51 絶賛、ブース出展中！ 🎉 来場者イベントも実施中 🎉 AI時代の エンジニアキャリアについて お話しましょう！ ※当日の配置と異なる可能性があります 

【こんな方におすすめ】 ✓ 経営層・役員の方 ✓ バックオフィス部門の責任者・担当者様 ✓ 経営企画・ DX推進部門の方 TOKIUM AI VISION 〜AIとともに企業の未来を創る〜 「AIをパートナーに、バックオフィスから企業の未来を創る」 その第一歩となる、日本最大級のオンラインカンファレンス 【当日コンテンツ】 元OpenAI 市場戦略責任者 Zack Kass氏 チームみらい党首 安野 貴博氏 早稲田大学 ビジネススクール教授 入山 章栄氏 【特別講演】元OpenAI Zack Kass氏 AIは社会とビジネスをどう変えるのか 【基調講演①】安野 貴博氏×黒崎氏×田岡氏 AI時代における企業の生存戦略 【ゲスト講演①】豊田 健一氏×西山氏 AI時代におけるバックオフィスのあるべき姿 【ゲスト講演②】磯和 啓雄氏×松原氏 AI改革の出発点～企業文化を変えるためのマインドセットと実践論 【事例講演①】クライアント企業様×TOKIUM 経理AIエージェント浸透までの道のり 【事例講演②】クライアント様×TOKIUM 上場企業CFOが語る、AIエージェント導入のプロセス 【基調講演②】金 剛洙氏×入山 章栄氏×松原氏 AI時代の勝ち筋のつくりかた 開催概 要 日時　：2026年1月20日（火）1230‐ 形式　：オンライン配信 主催　：株式会社TOKIUM 参加費：無料 お申込みはこちら（無料） ▼下記URLよりお申込みください https://www.keihi.com/seminars/202601_tokiumaivision/ 

53 🤝 SNS はこちら！ 参加してるイベントの実況だったり、登壇するイベントだったり、 その準備（ギリギリ） の様子だったりを雑多につぶやく Twitter アカウント。 長文はほぼ書かずに短文中心で、古のつぶやきスタイルを貫く。 

54 Appendix 

55 Appendix 1. 良い戦略、悪い戦略 / ISBN: 9784532318093 原書: Good Strategy / Bad Strategy The difference and why it matters / ISBN: 9781846684807 （※戦略を語るうえで、どのように組み立てて伝えるか？というワイヤフレームとして参照） 2. RANGE（レンジ）知識の「幅」が最強の武器になる / ISBN: 9784822288778 原書: Range: Why Generalists Triumph in a Specialized World / ISBN: 9781509843497 （※幅のあるキャリアの有効性について考えるうえで参照） 3. Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html (参照日: 2025.12.08) （※AIによる今後の開発プロセスを考えるうえでSDDを参考までに参照） 4. Accenture Technology Vision 2025から見る自律型AIエージェントとの付き合い方 https://www.accenture.com/jp-ja/blogs/technology/technology-vision-2025 (参照日: 2025.12.08) （※新たな学習サイクルについて類似する思考プロセスとして参照）