Codexで社内ツールを作る前に決める。チーム利用と人の確認を分ける手順
公開日 ・更新日
Codexを社内ツールづくりへ使うなら、最初に決めるのは機能ではなく確認の境界です。Cult.fitの事例は、Codexを使ってチーム横断でツールを作り、仕事の進め方を変えていると紹介されています。自社へ置き換えるときは、速く作れることと、誰が使うかを分けて設計します。
作る課題を一つに絞る
最初から全社の業務を自動化しません。問い合わせの分類、日報の集計、見積前の情報整理など、入力と出力を説明できる小さな作業を一つ選びます。完成の条件を「何がそろえば使えるか」で書き、便利そうという理由だけで範囲を広げないことが大事です。
候補を選ぶときは、失敗しても人が元の手順へ戻れるかを見ます。顧客への送信、金額の確定、契約の更新のように取り消しにくい処理は、最初の対象から外します。まずは社内だけで完結し、結果を人が確認できる仕事から始めます。
担当とレビューの境界を置く
Codexを操作する担当、業務の正しさを確認する担当、公開を決める担当を分けます。コードが動いても、顧客情報の扱い、権限、例外時の手作業が決まっていなければ社内ツールにはしません。レビューでは、通常の入力だけでなく、空欄、誤入力、権限のない人が触った場合も確認します。
レビュー項目を毎回変えないために、確認表を残します。使うデータの範囲、変更したファイル、失敗時の戻し方、公開前の承認者を一枚にまとめる。作る担当と使う担当が違っても、判断が抜けません。
小さく使い、変更を残す
一つの部署や一つのデータセットで試し、使った入力、出力、差し戻し、修正内容を残します。作業が速くなったかだけでなく、人の確認が減りすぎていないかを見る。公開範囲を広げるときは、変更点と戻し方を先に共有します。
週単位で、処理件数、差し戻し数、確認にかかった時間を並べます。数字が良くても、担当者が内容を説明できなければ広げない。便利さではなく、確認可能な運用になっているかで次の段階を決めます。
まず一つの社内作業で、担当、レビュー、停止条件を決める。Codexを社内ツールへ導入する範囲と確認手順は、COZITOへご相談ください。
関連記事
著者: 松井 勇樹