いま私は、数十名規模・数億円規模の事業本部の責任者を務めながら、並行して自分の手でシステム開発のデリバリーもこなしている。管理職としては明らかに「兼務しすぎ」の状態だが、破綻せずに回っている。
理由ははっきりしていて、事業本部長としての業務の大半を、自作の自動化ハーネス群に移したからだ。Python製のスクリプト群で、合計約1万行・約30本。業務の合間に、約2ヶ月で作った。
「管理職の仕事はAIに奪われるか」という抽象論はよく見かける。この記事はその逆で、管理職本人が自分の仕事を1本ずつAIに移してみた結果、何が移り、何が最後まで残ったかという一次記録である。
実際に自動化した業務
事業本部の運営業務は、よく見ると1本のパイプラインになっている。私の場合、上流から順にこうなった。
- 勤怠・稼働の収集 — メンバーの勤怠データを自動収集し、案件別の工数へ集計する
- 請求・稟議まわり — 工数集計から請求処理へつなぎ、定型の稟議・事務処理を整形する
- 管理システムへの投入 — 集計結果をPMOの管理システムへ自動投入する
- 報告資料の生成 — 週報、そして経営会議・営業会議向けの資料(PPTX/Word)を、集計データから自動生成する
- 監視 — 数値の異常や滞留をSlackに通知するwatchdogを常駐させる
- 人事評価の投入 — 評価者として書いた数十名分の評価を、人事システムへ自動投入する
こうして並べると身も蓋もないが、事業運営の「作業」部分は、ほぼ全部が「収集→集計→整形→転記→報告」の変奏だった。人間がやっていたのは、フォーマットの決まった情報を、決まった頻度で、決まった場所へ運ぶことだ。これはハーネスが最も得意とする仕事である。
どう作ったか — 完璧なシステムではなく「ハーネス」
ポイントは、立派な社内システムを作ろうとしなかったことだ。
1本ごとの実体は、Claude Code に書かせた素朴なPythonスクリプトである。壊れたら直す。業務が変われば書き換える。要件定義書もない。その代わり、業務がひとつ発生するたびに「これは来月も発生するか?」と自問し、発生するなら即スクリプト化するというルールだけを守った。
約2ヶ月でスクリプトは約30本になり、気づけば定例業務のほうが例外になっていた。AI駆動開発の速度があるからこそ成立するやり方で、従来の感覚で「社内ツール開発」として見積もっていたら、どれも着手すらしなかったと思う。
もうひとつの実感として、自動化には副作用としての検証効果があった。集計をコードに落とす過程で、これまで手作業の集計に埋もれていた数値定義の曖昧さや構造的な誤りが、何度か表面化した。この話は根が深いので、別の記事で書くつもりだ。
移せなかった仕事 — 判断・責任・対人
では何が残ったか。きれいに3種類に分かれた。
判断。 評価の投入は自動化できるが、評価そのものは私が書く。価格を決める、案件を断る、人を配置する — 選択肢を並べるところまではAIが手伝えるが、選ぶのは私の仕事として残った。
責任。 経営会議の資料は自動生成できるが、その数字を経営会議で説明し、達成にコミットするのは私だ。承認行為も同じで、ハーネスは稟議を「整形」はするが「承認」はしない。ここを移すと、それはもう管理職ではない。
対人。 交渉、評価面談、メンバーの様子がおかしいときの会話。ここはそもそも移そうと思わなかった。むしろ作業が消えた分、使える時間は増えた。
つまり残ったのは、昔から「管理職の本来の仕事」と言われてきたものそのものだ。逆に言えば、管理職の実働時間の大半は、本来の仕事ではない「運搬作業」に食われていたということでもある。私の場合、その運搬作業が消えたことで、本部長業務と開発デリバリーが両立するようになった。
組織への示唆
この経験を一般化するなら、こうなる。
管理職の業務は「判断・責任・対人」と「収集・集計・整形・転記・報告」の混合物であり、後者はAIハーネスでほぼ消せる。そして多くの組織で、管理職の時間の過半は後者に費やされている。
ここから導かれるのは「管理職の削減」ではない。運搬作業を土台に管理職の頭数を積み上げてきた組織では、ハーネスを持った管理職1人が、これまでの数人分の管掌範囲を持てるようになる、という管理スパンの再設計の話だ。プレイングマネージャという言葉は長らく「無理をしている状態」を指してきたが、作業がハーネス側に移ると、プレイしながら管理することは普通に成立する。
条件はひとつだけある。管理職本人か、そのすぐ隣に、業務をスクリプトに落とせる人間がいることだ。ここが、AI駆動開発の導入が開発部門だけの話ではない理由だと考えている。
具体的な構成や、どの業務から手を付けるべきかといった各論は、ご相談の場で話せる範囲でお伝えできる。