チャットのコマンドだけで、一日を締める

日報の転記と月末の報告書づくりを、誰の手も動かさずに終わらせたい。そのために組んだ社内の仕組みと、何を作らないと決めたかの話です。

開発チームの一日は、たいてい同じ手間で終わります。今日やったことをどこかに書く。作業時間を管理表に入れる。月末が来たら、それを集めて報告書の形に整える。

一つひとつは数分です。ただ、十数人が毎日やって、月末にもう一度まとめ直すとなると、それなりの時間になります。しかも転記なので、間違えても誰も得をしない種類の作業です。

これを、チャットで二回コマンドを打つだけの形にしました。

使う側から見た形

朝、/start と打つ。今日触る予定の仕事を選ぶ画面が出るので、選んで閉じる。

夕方、/end と打つ。今日やったことを書く欄が出る。「案件番号やったこと（完了）」のような書き方で並べて送る。

これだけです。送った瞬間に、次の四つが同時に書かれます。

月が変わると、前月分の報告書が自動でまとめられ、保管先に置かれます。誰も何もしません。

作りとしては、チャットからのコマンドを受けて、いくつかの外部サービスに書きに行くだけです。

人・入力ルールで決まる処理出てくるもの

本体は、常駐するサーバーを持たない形にしました。処理が呼ばれたときだけ動いて、終われば消える。そういう小さな実行環境に置いています。

この選択には理由があります。社内ツールは、作った人がいなくなった瞬間に止まるのがいちばん困る。サーバーがあると、OSの更新も、証明書の更新も、容量の監視も誰かが見続けることになります。誰のパソコンも起動している必要がなく、放っておいても動き続けることを最優先にしました。

月額は数ドルです。十数人が一日二回使う程度の負荷では、料金が問題になりません。

作るにあたって、意識的に諦めたことがあります。

画面を作らない。 管理画面もダッシュボードも作っていません。入力はチャット、出力は表計算。どちらも全員がすでに毎日開いているものです。新しく覚えることを増やさないほうが、定着します。

利用者ごとの設定をなくす。 チャットと案件管理はメールアドレスで自動的に紐づくので、メンバーごとの初期設定はゼロです。人が入れ替わっても、管理者が名簿を書き換える作業が発生しません。

汎用化しない。 他社でも使える形にはしていません。自分たちの運用に合わせて決め打ちにしたぶん、条件分岐が減り、壊れにくくなりました。社内ツールでは、これはだいたい正しい判断だと思っています。

作っていていちばん効いたのは、機能ではなく構造でした。

一日を締める経路は、実は一つではありません。本人が /end する場合。打刻を忘れて翌日に転記する場合。本人が操作できず管理者が代わりに入れる場合。時刻を打ち間違えて直す場合。

最初はそれぞれ別に書いていました。すると、経路ごとに書き漏れが出ます。この経路では報告書に書かれるが、あの経路では書かれない。使う側から見れば同じ「一日を締める」なのに、結果が揃わない。

共通化した中身

四つの書き先へ書く処理を一本にまとめ、どの経路も必ずそこを通るようにしました。

経路ごとに違うのは「どの情報が確定しているか」だけです。たとえば打刻もれの転記では退社時刻が分からないので、その欄は空けたまま他を書く。代理入力では全部が揃っているので全部書く。

この「何が確定しているか」を引数として渡し、書き込み側は渡されたものだけを書く。そう整理すると、経路が増えても共通部分を触らずに済みます。

機能を足すときより、入口を増やすときのほうが共通化の価値が出るというのは、しばらく忘れていた感覚でした。

この仕組みは、一度で動いたわけではありません。引き継いだコードが一度も実行されていなかったこと、外部サービスの応答制限に何度もぶつかったこと、本番初日に三人が締められなかったこと。

次回からはその中身を、順に書いていきます。外部サービスと連携する仕組みなら、業種を問わず出てくる問題ばかりです。

本記事の利用について。 出典（合同会社クオーレ・ラボ／記事タイトル／URL）を明記いただければ、引用は自由に行っていただけます。全文または大部分の転載、図版の再配布、内容を書き換えたうえでの再公開はご遠慮ください。社内資料や研修での利用をご希望の場合は、お問い合わせよりご連絡ください。

この記事で触れた設計や実装について、もう少し具体的に聞きたいという方は、お問い合わせからご連絡ください。案件の内容に応じて、お話しできる範囲でお答えします。