[Asana API]スプレッドシートとAsana準備編

AsanaAPIでスプレッドシート連携とタスク登録Asana API

どうも。ケニー(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の下準備」をお届けします。お楽しみに。

このシリーズの目次

  1. [Asana API]Asana APIを利用する下準備
  2. [Asana API]単体タスクの取得と更新
  3. [Asana API]単体のタスクの絞り込み取得
  4. [Asana API]複数タスクの取得とフィルター掛け
  5. [Asana API]特定のプロジェクトやセクションにタスクを登録
  6. [Asana API]スプレッドシートとAsana準備編
  7. [Asana API]スプレッドシート設計とGASの下準備
  8. [Asana API]スプレッドシートクラス
  9. [Asana API]カスタムAsanaクラス
  10. [Asana API]グローバルとカスタムメニューとmain
タイトルとURLをコピーしました