【セミナーレポート】「一気に完成形をつくろうとして、失敗した」非エンジニアが、申請業務の自動化にたどり着くまで（kubell 小幡万緒氏・西山歩伽氏）
クラウドワークフロー「kickflow」の顧客セミナーに、株式会社kubellからピープルディビジョン 新卒・第二新卒人材開発グループ グループ長の小幡万緒さんと、同グループ チームリーダーの西山歩伽さんをお迎えしました。
情報システム部門にとって、現場にAI活用を任せることには、隠れた葛藤があります。統制が効かなくなるのではないかという不安がある一方、すべての業務改善を情シスが巻き取っていては手が回らないのも事実です。
理想は、統制を保ちながら現場が自走できる状態のはずです。
本セミナーでは、その理想に自らの手で近づいた事例として、非エンジニアの新卒3年目である西山さんの自動化の経験をお話しいただきました。
30分のランチ勉強会形式で、前半は小幡さんが「kubellの土台づくり」の視点から、後半は西山さんが「現場でどう手を動かしたか」の視点からお話しされています。
本記事では、当日の内容をレポートします。セミナーの詳細は記事末尾のリンクからご確認いただけます。
序章｜「待つ」でも「勝手に作る」でもない現場をどう作るか
kubellは、「働くをもっと楽しく、創造的に」をミッションに掲げる企業です。2024年7月にChatwork株式会社から社名変更し、国内最大級のビジネスチャット「Chatwork」の運営に加えて、バックオフィス業務をアウトソースできる「タクシタ」などのBPaaSサービスを幅広く展開しています。
また、経営戦略において、AI活用による生産性向上を明確に掲げています。CTOなども歴任したエンジニア出身のCEO自らがオーナーとなり、全社でAI推進プロジェクト「kube-AI（くべあい）」を推進し、さまざまなAIツールを業務で活用できる環境を整えています。
こうした環境を土台に、ビジネス・プロダクト・バックオフィスなど職種を問わず、AI活用を前提に仕事の進め方を見直す動きが広がり、全社でAXが進んでいるのです。会社負担でツールが提供され、活用するためのガバナンスがきっちりと整備されています。
現場が自由にツールを作ることへの不安と、情報管理の必要性。この2つを解消した土台の上で、実際に自分の申請業務を分解し、AIとともに再設計してみせたのが、新卒採用チームの西山歩伽さんでした。
第1章｜危険を「注意喚起」ではなく「仕組み」で防ぐ
全社でガバナンスが整備され、技術的ガードレールはスキルで配布
セミナーの前半を担当したのは、ピープルディビジョン 新卒・第二新卒人材開発グループ グループ長の小幡万緒さんです。
kubellでは、セキュリティガイドラインや技術的ガードレールが全社で整備されており、具体的には下記のような仕組みがあります。
セキュリティガイドラインの策定：情報区分別の入力ルールやAIツール別の利用可否をリストで管理
スキル集を自動配布：ツールを作って社内限定公開できるスキル集を、全社員の環境に自動で配布
AIが先に警告：社内規則に触れる操作には警告が出る仕組みを全社に配布
窓口・知見を集約：相談とノウハウを1つに集め、良い方法は部署横断で展開する
具体的には4つ挙げておりますが、情報区分ごとにAIツールを統制し、かつ会社の公式スキル集は各社員の環境に自動配布される仕組みになっており、社内ルールに触れる操作はAIが先に警告する仕組みとなっております。つまり、危険は注意喚起ではなく仕組みで防ぐ設計です。（小幡さん）
マネジメント合宿ではCTO出身である、代表取締役CEOの山本氏自らAI研修をおこなうなど、経営陣の本気度も非常に高いのです。全社会議ではAI活用の好事例が毎月表彰され、勉強会でノウハウが横展開されています。
現場は「待つ」でも「勝手に作る」でもなく、当事者に
情シス部門の姿勢について、小幡さんは次のように紹介します。
弊社の情報システム部のスタンスとしましては、禁止で守るのではなく、設計で守り、現場に任せる。このガードレールの中で各現場の部門が業務を最適化することが前提となっております。（小幡さん）
ガードレールがあるからこそ、現場は自分の業務を安心して分解し、再設計できる。情シスの関与を待つのでも、統制の外で勝手に作るのでもない、当事者としての向き合い方です。
我々現場にとっては土台があるからこそ、安心して積極的に動けております。（小幡さん）
この土台の上で、実際に何が起きたのか。ここからは、新卒採用チームでこの自動化に取り組んだ西山歩伽さんのパートです。
第2章｜口座番号を、スクリーンショットから目で拾う仕事
交通費精算がいちばん重い理由
西山さんは2024年、新卒でkubell（当時Chatwork株式会社）に入社しました。1年目はDXアドバイザー事業でセールスを担当し、部署・本部の月間最高売上記録（当時）を樹立。その後、新卒採用領域に異動し、現在は新卒採用チームのリーダーとして採用戦略の実行とチーム運営を担っています。
私自身、いわゆる非エンジニア、非開発者というところで、プログラミングの経験などは全くない状態になります。（西山さん）
そんな西山さんが自動化に取り組んだのは、学生の交通費、会食、社員も含めたホテルや出張の申請など、採用業務に付随する各種の申請でした。採用が活発になるほど、裏側のバックオフィス業務は膨らんでいきます。
なかでも重かったのが、学生の交通費精算でした。
学生さんから届いた領収書だったり口座情報を確認して、一つ一つ乗り換え案内で運賃を再検索して、金額を照合して、申請内容を転記して。そういった手作業が非常に多く、一件ずつ人の手で行っていたのが実態です。（西山さん）
特に神経を使ったのが、振込先口座情報の入力でした。
特に神経を使うのが振込先の口座情報の入力で、いただいたスクリーンショットを見ながら手入力する部分があったので、現場の社員は非常にプレッシャーを抱えていたのかなと思います。（西山さん）
件数が増えるほど、人の注意力だけに頼ることには限界があります。西山さんが本来時間を使いたかったのは、学生一人ひとりとの対話や自社の魅力を伝えることであり、口座番号の転記作業ではありませんでした。
作ったのは、6つのステップでつながる仕組み
西山さんが構築したのは、Googleフォームを入口に、GAS（Google Apps Script）、kickflow、Chatwork、スプレッドシートを連携させた一連の自動化です。
流れは6つのステップに分かれます。
申請：学生や社員がGoogleフォームに必要事項を入力する
データ整形：GASが入力内容を検証し、データを整形する
下書き作成：申請カテゴリごとの下書きを、kickflowが自動で作成する
確認・承認：Chatworkに確認タスクが自動生成され、承認でフローが進む
申請起票：承認完了をトリガーに、kickflowが申請を自動で起票する
転記・可視化：スプレッドシートに自動で転記・集計され、ダッシュボードに反映される
交通費精算では、学生から届いた口座情報のスクリーンショットをOCRで読み取り、kickflowの申請欄に自動入力する仕組みも組み込みました。申請そのものは、kickflowの代理申請機能を使って西山さんたちが代理で起票します。
Googleフォームを入り口として、GAS、kickflow、Chatwork、スプレッドシートを連携して、申請から承認、転記、管理までを一気通貫で自動化しています。（西山さん）
機械が担うのは「作業」、人が担うのは「判断」
設計にあたって西山さんが意識したのは、機械と人の役割を分けることでした。
機械が行うのが作業で、人が行うのは判断。そこを分けながら設計をさせていただきました。（西山さん）
データの取得や整形、入力内容のチェック、下書き作成、申請の自動起票、スプレッドシートへの転記と集計。これらは機械が担う「作業」です。一方、申請内容の妥当性確認、金額や条件・目的の判断、承認や差し戻しの判断、例外対応の判断は、人が担う「判断」として残しました。
ルールが決まっている作業はシステムにお任せして、人は人にしかできない判断に集中する状態を作るというのが理想かなと思います。（西山さん）
第3章｜一気に作って、壊れた
完璧な設計図から始めた結果
この仕組みにたどり着くまでに、西山さんは一度、大きくつまずいています。
最初に選んだのは、自動化ツールの利用でした。完璧な計画を先に立て、申請から転記までを一度にまとめて自動化しようとしたのです。
結構完璧な計画を最初から立てて、一気通貫で全てを一気に自動化しようとしていた時期があったんですが、なかなかうまくいかず、結構な時間をかけたものの、アウトプットとしてはうまくいきませんでした。（西山さん）
原因を、西山さんはこう振り返ります。
最初から大きなシステムを作ろうとしてしまい、最初から最後までこういうものを作りたいというのを、ものすごい長いプロンプトで一度に詰め込んでしまった結果、Aを直したらBが動かない、Bを直したら今度はCでエラーになる、という状況を繰り返してしまって。（西山さん）
非エンジニアの西山さんには、どこが原因なのかを切り分けることさえ難しいことでした。気づけば、修正とAIとのやりとりばかりに時間を溶かしていたといいます。周囲の情報システム部門やエンジニアにフラットに相談できる環境があったことも、この経験を言語化するうえで支えになったと振り返っています。
「解像度を上げる」という学び
失敗から得た教訓は2つでした。最初から完成形を作らないこと、そして現場のオペレーションの解像度を先に上げることです。
解像度を上げるために、西山さんは次の5つを明確にすることを心がけたといいます。
ゴール（最終成果物）
Opsステップ（誰が・何を・どの順で）
インプット（どこから、何のデータを使うか）
“正しい”の定義（検証基準）
イレギュラーの時にどうするか
一気に大きな仕組みを作るというよりは、まず確実に動く小さな仕組みをしっかりと作っていって、その上で一つひとつ機能を追加していく。（西山さん）
土台を作ってから、機能を足す
実装は2段階に分けました。フェーズ1は土台作成です。エラー処理やUIは後回しにし、最もシンプルな機能だけで「動くコード」を作ることだけに集中します。フェーズ2で初めて、使いやすさや細かな条件分岐といった機能拡張に着手します。
まずは核となる最低限の機能だけで確実に動くコードを作ることに集中して、100%動く、エラーが起こらない状態を作ります。その後に初めて、少しずつ機能を追加していく。（西山さん）
最終的に、誰がどんな場面で使うのかという実運用の視点から仕上げるのが最後の段階です。この順序に変えたことで、自動化ツールのときのような「直したら別の箇所が壊れる」というデバッグの迷走はほとんどなくなりました。
今回の仕組みを作るにあたっても、何十時間もかけたわけではなく、まず核となるオペレーションや自動化の部分を作って、それを横展開させていった形なので、本当に1日くらいで作れたというのが実態です。（西山さん）
第4章｜申請1件30分から、6分へ
数字で見る変化
導入前は、入力・申請受付からチェック・検算、転記、申請・連絡、集計・レポート作成まで、5つの工程をすべて人が手作業でこなしていました。1件あたり約30分に加えて待ち時間が発生し、月間では約500時間以上に及んでいたといいます。
導入後は、フォーム入力から入力チェック、データ取得・連携、下書き生成から申請までの自動処理、異常時のみの通知、ダッシュボードへの反映までが自動で流れます。人が対応するのは、判断が必要なときだけです。1件あたりの対応時間は約6〜7分、月間では約20時間以下まで圧縮されました。
業務の申請にかかる工数が、実際に80%以上削減されました。人が月末月初で作業に追われる時間を、大幅に減らすことができています。（西山さん）
空いた時間を、何に使うか
西山さんが強調するのは、工数削減そのものより、時間の使い方が変わったことです。
工数削減そのものももちろん大きな成果だと思うのですが、人の時間を人にしかできない仕事に戻すという部分が、いちばん重要な目的だと思っています。（西山さん）
新卒・第二新卒の採用は、将来の経営幹部となる人材の採用でもあります。作業に追われるのではなく、候補者一人ひとりと向き合い、会社の未来への共感を伝えること。それこそが、AIが答えを出せる時代に人事が担うべき仕事だと西山さんは言います。
情報システム部門という土台
西山さんは、この自動化がkickflowのAPIと代理申請機能という拡張性、そして情報システム部門が整備した安全な基盤があってこそ実現したものだと振り返っています。第1章で見た「設計で守り、現場に任せる」というkube-AIの思想が、新卒3年目の非エンジニアが1日で仕組みを作り上げる土壌になっていたことがうかがえます。
おわりに｜非エンジニアが、拡張性の高い基盤の上で
セミナーの最後には、kubell社内で採用業務の工数を月200時間削減した別チームの事例や、AI推進を組織変革として設計する取り組みも紹介されました。こうした知見の共有が、kube-AIのもとで全社に広がっている様子がうかがえます。
西山さんは、今回の取り組みをこう総括しています。
生成AIを開発のパートナーとして活用しながら、kickflowのAPIや代理申請という高い拡張性、そして情報システム部門の皆さんが整備してくださった安全な基盤の下で、業務改善を進めることができたのかなと思っています。（西山さん）
自動化ツールでの失敗、5つの確認事項、土台から機能へという2段階の実装。どれも、非エンジニアが自分の業務を自分の手で自動化するための、地に足のついた方法でした。
情シスの仕事は、安全に任せられる土台を作ること。現場の仕事は、その土台の上で当事者になること。この2つがそろえば、非エンジニアの新卒3年目でも、申請業務は1日で自動化できます。小幡さんと西山さんの発表は、そのことを具体的に示してくれました。
小幡さん、西山さん、貴重なお話をありがとうございました。
セミナーの詳細
本セミナーの詳細はこちらからご確認いただけます。
▶ 【ランチ勉強会】非エンジニアが起こす、現場発のAI自動化 〜kubellに学ぶ、情シスと現場の理想的な連携〜
自分たちでも試してみる
西山さんが活用したのは、kickflowの代理申請機能とREST APIです。API・Webhookの仕様は、開発者向けに公開されています。
▶ 開発者向け仕様書
kickflowについて
kickflowは、300社以上の情報システム部門と管理部門へのヒアリングから生まれた、AI搭載のクラウドワークフローです。組織図の事前予約、承認経路のシミュレーション、100種類以上のREST API／Webhookを備え、組織変更の多い企業でも属人化しない運用を実現します。
#AI活用 #kubell #ワークフロー #導入事例 #ワークフローシステム #株式会社kubell #情報システム部門
