どうも。ケニー(tsujikenzo)です。このシリーズでは「[Asana API]スプレッドシート連携でタスク登録をしよう」をお届けしています。
今日は6回目です。
前回のおさらい
前回は、「特定のプロジェクトやセクションにタスクを登録」をお届けしました。
プログラミングでタスクを登録するイメージが、具体的になってきたと思います。
今回は、「スプレッドシートとAsana準備編」です。
今日のアジェンダ
- Asanaと同期しないスプレッドシート
- Asanaと同期するスプレッドシート
- 要件定義ポイント
Asanaと同期しないスプレッドシート
Asanaとスプレッドシート連携するとなると、以下のように、IDを確認するようなスプレッドシートが、あると便利そうです。
シート名 | GIDの指定要素(親) | (子) |
---|---|---|
Workspaces | ワークスペースGID | – |
Projects | プロジェクトGID | – |
Sections | プロジェクトGID | セクションGID |
Memberships | ユーザーGID | – |
CustomFields | カスタムフィールドGID | – |
しかしながら、これらは、そう頻繁に変わるものではありません(よね?)。
ワークスペースやプロジェクトなどは、一度取得して、メモさえ残せれば、よくないでしょうか?
また、これら(プロジェクトやセクション)は「GASを使って登録しない」「手動で登録するで十分」と、言えないでしょうか。
なので、これらのGID取得や確認のために、わざわざGASを書いて、Asanaとスプレッドシート連携しない、というのも1つのテクニックです。
このように、エディタの情報ログに出力されたテキストを、スプレッドシートにコピペするだけでも十分です。
各IDを取得するコードは、この連載の最後にGitHubにアップロードします。
Asanaと同期するスプレッドシート
さて、「タスク」は、取得したものをスプレッドシートに保存したいですし、スプレッドシートで作成したタスクを、Asanaにガンガンアップロードしたいです。
タスクの更新も、しかりです。
しかしながら、どのようにタスクをデータとしてスプレッドシートにもたせるとよいでしょうか。
【方法1】スプレッドシートごとにプロジェクトをわける
まず、スプレッドシート1枚につき1プロジェクト、とする方法があると思います。
構造的には、このようになります。
実際のスプレッドシートでは、こんな感じです。
メリット
- プロジェクトごと、セクションごとに分かれているので、見やすい
- 作成、運用、保守がラク
- 小規模なワークスペースに向いている
- 初級者向け
デメリット
- プロジェクトが増えると、管理が大変
- プロジェクトを横断するタスクなどは、管理ができない
- セクション名やフィールドの数や種類に変更があると、変更に弱い
- 中規模、大規模なワークスペースには不向き
【方法2】構造化データ(テーブル)
タスクを、構造化データ(テーブル)として管理する方法があると思います。
本来であれば、正規化を行い、このようなリレーショナルデータベースを組むことになります。
しかしながら、リレーショナルデータベースを構築するのは大変(クエリが複雑になるというのが最大の難点かと)なので、今回は、単一のテーブルとして処理します。
実際のスプレッドシートでは、こんな感じです。
メリット
- タスク管理を一元化できる
- フィールドが増えたり、変化への対応がラク
- さまざまなデータに変換がしやすい
- 大規模から小規模まで対応可能
- データへのアクセスがラク(プログラミングがラクで処理速度が早い)
デメリット
- データベースの知識が必要
- 要件定義がむずかしい
- 想定外の要素発生や、例外に弱い
- 同時多発的な大量のアクセスに弱い
- 正規化しないということはデータが重複する運命にある(いつか解説します)
どちらのメリットが上回るのか、またはデメリットの方が上回るのかは、状況により変化するので、とても判断がむずかしいです。
最後に、データの持たせ方を決めるポイントを整理してみます。
要件定義ポイント
以下の要件定義に答えると、データの持たせ方の答えも出やすくなると思います。
ワークスペース編
- Asanaは個人用か、組織用か
- 組織は、5人未満か、それ以上か
- メンバーは頻繁に入れ替わるか、固定か
プロジェクト編
- プロジェクトは個人用か、組織用か
- プロジェクトは5つ以上あるか
- プロジェクトの作成、クローズの頻度は激しいか
- プロジェクト内のセクションやフィールドやメンバーは、頻繁に作成・更新されるか
タスク編
- 管理したいタスクは10件以上あるか
- タスクのカスタムフィールドは、5件以上あるか
- 定期的に自動作成(または更新)したいタスクがあるか
今回は、弊社では、構造化データ(テーブル)で運用しようと思います。
理由は、以下です。
- 社内のデータベースリテラシーが割と高い
- 管理したいプロジェクトが5つ以上あり、出入りが激しい
- プロジェクトごとにセクションが異なり、更新頻度も激しい
- データベース運用者が恐らく1人(Kenny)だけである(スプレッドシートを大量に作りたくない)
- データへのアクセスが早い
次回以降、実際にスプレッドシートとGASを作成していきます。
まとめ
以上で、「スプレッドシートとAsana準備編」をお送りしました。
データの持たせ方に、正解はありません。使う人が使いやすいのがいちばんです。
しかしながら、要件定義がむずかしいのも、ノンプログラマーとしての悩みです。
次回は、「スプレッドシート設計とGASの下準備」をお届けします。お楽しみに。