メインコンテンツへスキップ
見出し画像

Google・Slack・freeeを一気通貫。入社処理を自動化する設計とその第一歩

    AccelHack

    こんにちは！Accel-Hack（アクセルハック） 開発チームです。

    社内AIアシスタント「Airi」の開発プロセスをお届けする開発記ブログ。
    第15回目の今回は、業務機能の第三弾――新入社員の受け入れ（employee機能・入社処理）をお届けします。

    前回の Vol.14 では、Slack モーダルで有給申請を完結させました。


    今回はそのモーダルを応用しつつ、複数のシステムを連動させるという、一歩踏み込んだテーマに挑みます。

    そして、その第一歩としてあえて選んだ「モック（ダミー実装）から始める」というアプローチについても、正直にお話しします。

    1. 入社日の「あの作業」を、まとめてしまいたい

    新しいメンバーが入社するたびに発生する、地味だけれど神経を使う作業があります。

    アカウント作成です。

    Google Workspace のアカウントを作り、Slack に招待し、freee の従業員情報を登録し……と、複数のシステムを行き来しながら、同じ情報を何度も入力していく。
    一つでも抜ければ初日から業務に支障が出るため、担当者は毎回チェックリストと睨めっこです。

    この「複数システムをまたぐ手作業」こそ、自動化がもっとも輝く領域です。

    Airi が目指したのは、Slack のモーダルに新入社員の情報を一度だけ入力すれば、必要なアカウント作成が一気通貫で走る世界でした。


    2. 起動は「専用チャンネル」から

    この機能は、/airi employee entrance というコマンドで起動します。

    ただし、扱う情報が情報だけに、どこでも実行できては困ります。

    氏名やメールアドレスといった個人情報を扱うため、Vol.10 で紹介した権限チェックの仕組みを使い、入社手続き専用のチャンネルからしか実行できないように制限しています。

    export const EMPLOYEE_CONFIG = {
  commandPrefix: "employee",
  commands: {
    entrance: { name: "entrance", description: "入社手続きを開始します" },
  },
  allow: { channelIds: [ENTRANCE_CHANNEL_ID] }, // 専用チャンネル限定
  // ...
};

    Vol.10 で作った「宣言的な権限制御」が、こうした機微な機能でそのまま安全弁として効いてくれるわけです。

    コマンドが実行されると、氏名・メールアドレス・部署・入社日を尋ねるモーダルが開きます。


    3. 受け付けは堅く――モーダルとバリデーション

    入力の受け付けには、Vol.14 で紹介したモーダルとインラインバリデーションの仕組みを、そのまま活かしています。

    送信された内容は、app.view に挟んだ検証関数が真っ先にチェックします。

    氏名やメールアドレス、入社日といった必須項目が欠けていれば、response_action: "errors" を返してモーダルを閉じず、その場で該当欄に指摘を出します。

    入社処理は後戻りしづらい操作だからこそ、「不完全なデータを絶対に先へ進めない」入り口の堅さが大切になります。

    4. 複数システムを“連動”させる骨組み

    検証を通過すると、いよいよ本題――複数システムのアカウント作成です。処理の流れは、驚くほど素直に書かれています。

    // 入社手続き：3つのシステムへ順番にアカウントを作成する
await createGoogleAccount(name, email);
await createSlackAccount(name, email);
await createFreeeAccount(name, email);

await api.slack.chat.postMessage({
  channel: userId,
  text: `🎉 入社手続きが完了しました\n氏名: ${name} / 入社日: ${startDate}`,
});

    モーダルへの1回の入力から、Google・Slack・freee という3つのシステムへの登録が順に流れ、最後にまとめて完了報告が届く。

    この一気通貫の流れを図にすると、次のようになります。

    画像

    5. なぜ、あえて「モック」から始めたのか

    さて、ここで正直に告白します。上記の createGoogleAccount などの中身は、現時点では モック（ダミー実装）です。

    実際にはまだアカウントを作らず、「作ったつもり」で先へ進みます。

    なぜ、わざわざ空っぽの実装から始めたのでしょうか。

    理由は、「骨組み」と「中身」を分けて攻めるためです。
    各SaaSへの本物のアカウント作成は、権限設定やAPIの細かな作法、そして「一度作ったら簡単には消せない」不可逆性など、一つひとつが重い課題を抱えています。

    ここに最初から踏み込むと、肝心の「入り口からオーケストレーションまでの流れ」がなかなか完成しません。

    そこで私たちは、createXxxAccount(name, email) という関数の“形（インターフェース）”だけを先に決め、中身は空のまま全体を貫通させました。

    こうすることで、「専用チャンネルの制限は効くか」「モーダルの入力は過不足ないか」「完了通知は分かりやすいか」といったUXとフロー全体を、いち早く実際に触って検証できたのです。
    中身は後から、一つずつ本物のAPI呼び出しへ差し替えていけばいい。

    これは、Vol.4 で紹介した Feature-First の考え方とも通じる、「機能を薄く縦に貫通させて、まず動く骨格を作る」というアプローチです。

    「動くけれど、まだ作らない」。

    この割り切りが、手戻りの少ない開発を支えてくれました。


    6. おわりに

    今回は、入社処理を題材に、複数システムを連動させる機能を、モックで骨組みから立ち上げるやり方をお届けしました。

    専用チャンネルによる安全な起動、モーダルによる堅い受け付け、そしてオーケストレーションの骨格。

    中身はこれから本物へと育てていきますが、その土台はもう出来上がっています。

    さて、これで打刻・申請・入社処理と、人にまつわる業務がひと通り揃いました。
    次回からは趣を変えて、Airi が自発的に情報を届けてくれる機能たちを紹介していきます。
    まずは 「Vol.16: 情報収集の自動化『news機能』」 として、RSS を使った IT ニュースの自動収集と Slack への定期配信の仕組みをお届けします。お楽しみに！

    この記事は以下の体制で作成されました。

    • ドラフト作成・執筆: Airi (社内AIアシスタント)

    • アイデア出し・レビュー: CTO

    • デザイン: 事務スタッフ

    Accel-Hackでは、テクノロジーを駆使して世の中の課題を解決していく仲間を募集しています。
    私たちの取り組みに少しでも興味を持っていただけたら、ぜひ採用ページや会社サイトも覗いてみてくださいね。


    あなたへのおすすめ