20269月〜継続中・長期インターン

要件定義から運用手順まで、ひとつの業務システムを通しで

クライアント企業の社内フロー（依頼書の回覧から担当者への通知まで）を自動化するシステムです。コードを書いただけではなく、要件定義書と基本設計書を書き、テスト仕様書と運用手順書まで作るところまでを担当しました。自分が目指しているエンジニア像に、いまのところいちばん近い仕事です。

どんな業務を自動化したのか

クライアント企業では、店舗から上がってくる依頼書が本部で承認され、そのあと「誰に割り振るか」を人が判断し、関係者に連絡するという流れがありました。承認までは既存の仕組みがありますが、そこから先が手作業で残っていた部分です。

この「承認されたあと」を自動化しました。

最後まで行くと、担当者はチャットの通知を受け取った時点で、必要な書類と文脈が揃った状態になります。人が間に立って転記する作業がなくなる、という設計です。

このプロジェクトで書いたドキュメントは、要件定義書・基本設計書・詳細設計書・開発タスク一覧・テスト仕様書・セットアップ手順書・運用手順書の7種類です。要件定義書は第5版、基本設計書は第10版まで重ねました。版が増えているのは、作りながら決めたのではなく、作る前に詰めたからです。

いちばん大事だったのはスコープを先に決めきることでした。業務フロー全体のうち、自動化する工程としない工程を記号で区切って表にし、クライアントと合意してから実装に入っています。ここが曖昧なまま作り始めると、シフト管理アプリのときに経験したような「あとから修正範囲が広がる」状態になります。

Google Chat に通知を送るには、本来なら Admin SDK で利用者を検索するのが素直です。ただしそれにはシステムユーザーに管理者ロールを渡してもらう必要があります。クライアントの情報システム部門にとっては、外部に強い権限を預けることになります。

そこで Admin SDK を使わない設計にしました。チャットのユーザーIDはマスタに登録してもらう運用に切り替え、管理者ロールの付与を不要にしています。運用側の手間は少し増えますが、「権限を渡さなくても導入できる」ほうが通りやすいと判断しました。

週次のバッチを動かす日を決めるとき、最初は単純に曜日で指定するつもりでした。ところが休業日が絡むと、前日が休みだと処理対象のデータが揃っていないことがわかりました。

そこで起動日を「前日が営業日である最初の平日」と定義し直しました。通常は火曜ですが、月曜が休業日なら水曜、月〜水が休業日なら金曜になります。条件を満たす日が週内になければ、その週は動かさず翌週に送ります。カレンダー通りに動かすのではなく、業務の実態に合わせて動かすという決め方です。

Google Apps Script で動かす必要がありましたが、GASのエディタで直接書くのではなく、TypeScript で書いて esbuild でバンドルし、clasp で反映する構成にしました。型チェックが効き、テストも書けて、変更履歴がGitに残ります。

TypeScript ＋ esbuild ─ 単一ファイルにまとめて GAS へ反映。型チェックは tsc --noEmit を独立したゲートとして通す
Jest によるテスト ─ GAS固有のAPIが必要な箇所だけフェイクを用意し、それ以外は依存を注入してGASに依存しない純粋な関数としてテストできる形にした
standalone 構成 ─ スプレッドシートに紐づけず、対象のIDはスクリプトプロパティで持たせて、環境ごとに差し替えられるようにした

「GASだから仕方ない」で済ませずに、普通のアプリケーションと同じように型とテストを効かせられる形に寄せたところは、自分なりに工夫した部分です。

クライアント向けのシステムのため、コードと画面は掲載していません。
設計の考え方についてはお話しできますので、必要であればお問い合わせください。

自分はもともと「顧客の課題を理解して、要件を定義して、提案して、自分で作れるエンジニア」になりたいと言ってきました。この案件は、その流れをはじめて通しで経験したものです。

やってみてわかったのは、実装で苦労する量は、その前にどれだけ決めたかで決まるということでした。要件定義書を5版、基本設計書を10版まで重ねたのは遠回りに見えますが、おかげで実装中に「そもそもこれはどっちだったか」で止まることがほとんどありませんでした。

そして、技術的に正しい設計がそのまま通るとは限らないことも学びました。管理者権限の件のように、相手の組織が受け入れられるかどうかまで含めて設計しないと、動くものを作っても導入されません。