こんにちは、鵜野（うの）です。
現場での自身の経験を初めてストーリーを書きます。
普段は、Web・コンテンツ制作のディレクションと、Notion・GAS・API連携を使った業務設計や自動化に取り組んでいます。
情報を転記する、予定を更新する、担当者に連絡する。
制作の現場には、一つひとつは小さくても、繰り返すうちに負担になる作業がたくさんあります。
私はそうした作業を整理し、ツール同士をつないで仕組みにする仕事をしています。
ただ、構築と改善を重ねるうちに、情報が自動で反映された時点ではまだ考えることが残っていると感じるようになりました。
この記事では、実務を通じて大切にするようになった設計の考え方を4つ紹介します。
なお、業務上の非公開情報を含むため、個別案件の画面やコード、詳細な仕様は載せず、考え方を一般化して書いています。
1. 自動で更新する情報と、人が判断する情報を分ける
ツール同士を連携するとき、最初に決めておきたいのは、どちらのデータを正とするかです。
元のデータベースが更新されたら、連携先も更新する。
一見それで十分に思えますが、実際の運用では連携先で人が手を加える場面があります。
現場の事情に合わせて予定を調整したり、一部の情報を変更したりといった修正です。
次の同期でその修正を元に戻してしまうと、確認と修正の手間がかえって増えます。
そこで私は、項目ごとに、自動で上書きする範囲と手動の修正を優先する範囲を決めています。
たとえばカレンダー連携では、自動で招待した人が手動で外された場合にその操作を記録し、次の同期で再招待しないようにしました。
2つの予定が同じ枠を指しているなど、どちらが正しいかを仕組みだけでは決められない場合は、カレンダーには手を加えず、担当者に確認を依頼する通知を送ります。
人が判断すべき場面を、自動処理が勝手に埋めないための設計です。
同じ「データが食い違っている」状態でも、更新漏れなのか意図した変更なのかで、必要な対応は変わります。
その区別まで含めて連携の設計だと考えています。
2. 使う人の操作に合わせて、仕組みを見直す
作る側が想定する操作と、日々使う人の操作は、必ずしも一致しません。
スプレッドシートでは、一つのセルを編集することもあれば、複数のセルをまとめて貼り付けたり、テンプレートをコピーして中身を入れ替えたりすることもあります。
一つずつ編集したときには正しく動く仕組みでも、まとめて操作すると変更を拾えない場合があります。
実際に、空の列を貼り付けて内容を消したはずの列に、数分後の定期処理で同じ情報が再び転記されてしまったことがありました。
処理が一つのセルの編集だけを前提にしていたため、まとめて消した操作を削除として認識できていなかったのが原因です。
使う人から見ると、自分の操作が間違っていたように感じてしまう不具合でもありました。
こうした問題に出会ったときは、操作手順だけでなく、処理側の前提も見直します。
変更された範囲全体を確認する。
書き込む直前に、対象が今も同じ状態か確かめる。
古い処理情報が残っていても、誤った更新につながらないようにする。
使う人にとって自然な操作を知ることが、実装を改善する手がかりになると感じています。
3. 原因の仮説と、確認できた事実を分ける
連携がうまく動かないとき、最初に思いついた原因が正しいとは限りません。
取得件数の問題なのか、取得方法や権限の問題なのか、そもそも期待した情報が返ってきているのか。
可能性はいくつもあります。
以前、スプレッドシートの一部のセルに、隣の列にある別の情報が入り込む不具合がありました。
調べてみると原因は一つではなく、変更の有無を判定する処理と、古い処理待ちの情報が残り続ける処理の2つが重なって起きていました。
最初の仮説だけで修正していたら、もう一方の原因は残ったままだったと思います。
そのため、ログや確認用の処理を使い、実際に取得できた内容と想定を照らし合わせることを大切にしています。
作業ログには、症状、考えた原因、確認した結果、変更した内容を残します。
仮説が外れていた場合も、そのことを記録します。
あとから読み返したときに今の仕様になった理由が分かり、次に問題が起きたときも同じところから調べ直さずに済むからです。
この差がその後の業務効率に大きく響くと分かってから、判断の過程まで残すようにしています。
4. 通知とドキュメントも運用の一部として考える
自動化が増えるほど、使う人からは処理の中身が見えにくくなります。
だからこそ通知では、何が変わったのか、何を確認すればよいのかが、フローに関わる全員に伝わるようにしています。
処理を試みたことと、実際に変更できたことを分けて伝えるのもその一つです。
変更がなかったときは通知を送らず、届いた通知には必ず確認すべき内容がある状態を目指しています。
設定漏れのチェックでは、予定日の3日前から1日2回確認し、問題が残っている間だけ通知が届くようにしました。
修正されれば通知は自動で止まります。
知らせ続けることと、必要がなくなったら止めることの両方を、通知の設計に含めています。
仕様を変えたときは、コードとあわせて操作ガイドや確認項目も見直します。
何が自動で行われ、何が人の作業として残るのか。
動かないときはどこを確認すればよいのか。
構築した本人でなくても分かる状態にしておきたいと考えています。
業務の理解から、実装後の改善まで
私が取り組みたいのは、現場の人が安心して使い続けられる仕組みづくりです。
そのためには、APIやツールの知識に加えて、情報がいつ更新されるのか、誰が判断するのか、日常的にどんな変更が起きるのかを知る必要があります。
制作ディレクションで現場の流れに関わってきた経験は、こうした設計を考えるときにも活きています。
現在は、Notionの情報設計や運用の整理、GAS・API連携による自動化、Cloudflare Workersを使った連携処理の構築、Notion・Googleカレンダー・Discordなど複数のツールをまたぐ仕組みづくり、マニュアルの整備まで取り組んでいます。
「同じ情報を何度も入力している」「担当者や予定が変わるたびに確認が必要になる」。
そんな業務を整理するところから実装、その後の改善まで一緒に考えていくことに、やりがいを感じています。
