Google Sheets・Backlog・Gitを無理なく同期する方法

プロジェクトの情報が一か所だけにあることは、ほとんどありません。WBSはGoogle Sheets、実行タスクはBacklog、ソースコードはGitにあり、ローカルのスクリプトではYAMLのほうが扱いやすいこともあります。それぞれのツールに得意な役割があります。

困るのは、複数の場所がどちらも正しそうに見えるときです。SheetsとBacklogでステータスが違ったら、どちらを採用するのか。昨日作ったYAMLから今日のSheetを更新してよいのか。APIが成功しても日本語が文字化けしていたら、本当に完了と言えるのか。

手作業で何度も確認した経験から、同期の流れを四つに整理しました。

取得、確認、反映、再確認

最初に、正となるシステムから最新データを 取得 します。古いローカルデータで、ほかのメンバーの変更を上書きしないためです。

次に、更新内容を 確認 します。外部APIを呼ぶ前に、何を追加し、何を変更し、何を削除するのかを、読みやすい差分で見られるようにします。

内容を確認してから 反映 します。対象の特定には、行番号やタイトルではなく、安定したIDを使います。行番号は並び替えで変わり、タイトルは重複することがあります。WBS-042 のようなIDがあれば、Sheets、Backlog、ローカルデータが同じ項目を指せます。

最後に、反映先からデータを読み直して 再確認 します。HTTP 200はリクエストが受け付けられたことを示すだけで、最終結果が正しいとは限りません。読み直すことで、日本語やベトナム語の文字化けにも気づけます。

データごとに持ち主を一つ決める

すべてのシステムに同じ役割を持たせるのをやめると、運用がかなり分かりやすくなりました。

WBS、リスク、決定事項はGoogle Sheets。実行状況、コメント、添付ファイルはBacklog。ソースコードはGit。YAMLはスクリプトのための便利なスナップショットであり、二つ目のデータベースではありません。

同じ情報が複数の場所に表示されても、どこが持ち主なのかは一つに決めておきます。

接続情報もスクリプトから分離しました。プロジェクトID、シート名、リポジトリの場所は、小さなレジストリから取得し、個別の処理に直接書き込みません。

最初は、すぐAPIを呼ぶより手順が多いように感じました。しかし実際には、事前に内容を確認でき、履歴を追えて、反映後も検証できるため、安心して自動化できる範囲が広がりました。大切なのは、何でも同期することではなく、何が、どこへ、なぜ動いたのかを説明できることだと思っています。