bitbank techblog

asanaの導入と僕と僕の周りに起きたこと

はじめまして。エンジニアのjiroと申します。

今回は、最近社内で導入したasanaというプロジェクト管理ツールを紹介できればと思います。

この記事に書いてあること

  • 開発チームの課題
  • asanaに決定した経緯
  • 導入にあたって
  • もたらされたこと
  • 今後行いたいこと

開発チームの課題

開発チームに起きていたこと

ここ数ヵ月の間、僕たち開発チームには2つの変化が起きていました。

ひとつは、メンバーが急増していること。
もうひとつは、CTOが開発に割ける工数が減ってしまったこと。
当時は、開発メンバーとCTOが口頭で同期的にコミュニケーションを取るフローで合意形成・進捗確認が行われていました。
結果として、メンバーとCTOのコミュニケーションをする時間を確保することが難しくなり、スムーズな開発が少しずつ困難になりつつありました。

次に、当時使っていたタスク管理ツールの問題を挙げてみます。

まずは、タスクを作成・更新するコストが高いこと。
全体的なレスポンスもあまり良くなく、何かをしたいときに踏むべきステップが多いものでした。
たとえばタスク編集をするには、タスクを開く>編集ボタンを押す>保存ボタンを押す>確認画面が開く>再度確認ボタンを押す といった手順が必要でした。
デザインもあまり今風でなく、これらがタスク化する際に重荷となっていました。

また、他人のタスクを一覧する機能がないという問題もありました。
いわゆるタスク検索機能によって、特定のユーザーに割り当てられているタスクを検索することはできるものの、以下の機能が貧弱でした。

  • 他人にアサインしたタスクの状況確認
  • 他人から新しくアサインされたタスクのチェック
  • タスクのコメントでのメンション

要件

さて、以上の問題から、以下の3つを要件としました。

  • 軽快な動作と直感的な画面操作
  • 非同期コミュニケーションを促すUIを備えていること
  • 他人のタスクを見渡したり、他人を巻き込みやすい機能があること

また、CTOからは管理者として以下の要望が挙がりました。

  • ガントチャートでスケジューリングを見渡せること
  • チーム単位・プロジェクト単位の権限管理の概念があること
  • Google SSOないしSAML連携が使えること

asanaに決定した経緯

候補出し

ツールの候補出しは、開発メンバーがこれまで使ったことがあるものと、stackshareを参考に行いました。

ちなみにstackshareというのは、IT企業がどんなプログラミング言語やツールを使っているのか、を公開しているものです。
たとえば今回の主役である、asanaの運営元であるAsana,Incのページでは、以下のような情報が公開されています。

stackhare

以下が候補として挙がりました。

  • asana
  • trello
  • Wrike
  • Redbooth
  • instaganntt
  • teamgantt
  • notion
  • jira
  • basecamp
  • TASKWORLD
  • Redmine
  • clickup
  • 物理ふせんでカンバン

機能チェック

次に、それぞれのサービスに対して以下の項目を確認していきました。
これは、先程の要件からブレークダウンしたものです。

  • 軽快な動作と必要最低限な画面操作
    • ページロードなどがある程度軽快であること
    • ページ遷移せずに済むものはそうなっていること
  • 非同期コミュニケーションを促すUIを備えていること
    • タスクをユーザーにアサインできること
    • タスクに対してコメントができること
  • 他人のタスクを見渡したり、他人を巻き込みやすい機能があること
    • 「誰々のタスク一覧」という画面で
    • タスクにコメントする際、メンションが可能であること
    • 新しくアサインやメンションされたら確認しやすいこと
    • Slack連携など、気付きやすいしくみがあること
  • ガントチャートでスケジューリングを見渡せること
  • チーム単位・プロジェクト単位の権限管理の概念があること
  • Google SSOないしSAML連携が使えること

これらを満たす候補はいくつか残りましたが、中でもasanaはさらに以下のような機能がありました。

  • 依存機能
  • Like
  • CustomField
  • ダッシュボードによるトラッキング
  • 権限機能
    • チームや組織、自分のタスク、そしてそれぞれに対する権限の種類

テスト運用

以上の経緯で、機能チェックで特に良さそうだったasanaのテスト運用を決定しました。

テスト運用では、実際に僕が進めているプロジェクトで運用を行ってみました。
実際に使ってみて感じたことは、

  • 「タスクとして整理してアサインする」という意識が付き、より整理されたコミュニケーションが行われるようになった。
  • 受信トレイやMyTask、セクションによって、予想以上に仕事の見通しが付けやすくなった。

結果、予想以上に業務効率化ができそうに想いました。
そのため、当初はエンジニアチームのタスク管理ツールのリプレースのみの予定でしたが、CTOとも相談し社内全体にasanaを導入することに決定しました。

導入にあたって

正式に導入するにあたって行ったことを紹介します。

チーム設計

まずは、チーム設計を行いました。
asanaは、組織 - チーム - プロジェクトという階層構造になっており、それぞれに公開範囲と権限の設定ができます。
チームの公開設定は以下の3種類です。

  • オープン
    • 組織内ユーザーが誰でも閲覧でき、参加できる。
  • 承認制
    • 組織内ユーザーであればチームがあることは確認できるが、内容の閲覧と参加は既存メンバーの承認が必要
  • 非表示
    • 招待されたメンバーのみが参加でき、それ以外のメンバーにはチームがあること自体確認できない

ビットバンクでは、インターンやアルバイトの方がいらっしゃるため、基本的にどのチームも"非表示"を選びました。
チーム≒共有範囲となるため、社内の部署の粒度に合わせた分け方としました。

  • エンジニアチーム
  • マーケティング
  • CXO
  • リクルーティング
  • カスタマーサポート
  • BTCN

チームの作成と基本設定、メンバーのアサインは僕が手動で設定を行いましたが、
このあたりは改善の余地がありそうです。
たとえばエンジニアチームはAWS環境にはいるためのSSOアカウントとその裏側のActiveDirectoryが用意されているのですが
このようなものが利用できるとより便利そうです。

ハンズオン会

今回はエンジニアチームだけでなく全社的な導入を行うので、運用の共通認識をもつためにハンズオン会を行いました。
下準備として、各チームでどのように業務を回しているのか、既存タスク管理ツールはどうしているか等をヒアリングしてから使い方を提案しました。

ハンズオンでは、今回のasana導入の効果を高めるために、特に以下の2つを"お約束"として意識するようにアナウンスしました。

1つ目は、半日〜1日で終わる程度の仕事を1タスク にするということ。たとえばタスク粒度が大きい方にぶれると、一週間ずっとdoingのままで、外から見て変化がないという自体になってしまいます。これを防ぐ目的です。

2つ目は、担当者の設定は必ず行う ということ。asanaのMyTaskというページでは、チームやプロジェクトに関係なく自分へアサインされているタスクが一覧できます。タスクに担当者が設定されていないと、誰のMyTaskにも表示されず、浮いてしまいます。

参考までに、ハンズオン会で使用したスライドをこちらに載せておきます。

朝会

そして、asanaを利用した朝会も行うようにしました。
”MyTask”で自分のタスクが一覧できるとお話いたしましたが、asanaでは他人のMyTaskも閲覧できます。
朝会は、 ひとりずつ順番にMyTaskを読み上げつつメンバーはその人のMyTaskを見ていく というもので、以下の効果がありました。

  • ほかのメンバーがasanaをどう使っているかを知れること
  • ほかのメンバーがどんなタスクを行っているか把握すること
    • 何が得意で、何に困っているのかがわかる

もたらされたこと

これを書いている時点で、asanaを使い始めてから1ヵ月ほど経過しました。
asanaの導入でもたらされたことを書き出してみます。

情報の集中

まずはasanaのチケットにして、そこに前提情報や作業ログを書いていく、という意識付けが行われました。
asanaさえ見れば状況がわかるので、相談したり共有をするときのコミュニケーションが楽になりました。

コミュニケーションの効率化

状況や情報が整理されたことで、コストのたかい口頭コミュニケーションの必要な場面が減りました。
誰かに相談したいときはasana上でメンションすれば、すべてが伝えられるわけです。

他人へのタスクの見える化

朝会でのタスクの共有とasanaでの見える化によって、ヘルプを出しやすくなりました。

アサインのしやすさ

asanaはタスクのアサインがしやすいUIになっており、何かを依頼する際はたんにチケットを切れば十分という状況が整備できました。”自分が他人アサインしたタスク”というビューもあり、アサイン後のトラッキングも容易になりました。

こまかな作業ログ

作業ログを残しやすいUIのおかげで、分報のようにちょっとした思ったことやメモを書き残しやすくなりました。このメモは同じプロジェクトのメンバーや、タスクのフォロワーにも見えるので、意外なヘルプをもらえることも多くあります。

バックログによる課題の共通認識化

どのプロジェクトにも属さないようなタスクを追加する際は、"バックログ"というプロジェクトに残しておくようにしました。今までよりも気軽に思いつきを残しておくことができるようになりました。
これにのちのち賛成のコメントがついたりして熱量が高まると、取り組むべきタスクに設定されるわけです。

タスク粒度の徹底による状況の追いやすさの向上

タスクの粒度に対する共通認識ができたことで、誰のタスクを見ても一定以上の粒度・制度で状況を追えるようになりました。また逆に、半日程度にタスクを分解するのが難しい場合は実は何をすべきかわかっていないということでもあり、あいまいタスクが防がれることにもつながったと想います。

結果

総合的に見て、3つの要件も達成できたと言えるかと想います。

  • 軽快な動作と直感的な画面操作
  • 非同期コミュニケーションを促すUIを備えていること
  • 他人のタスクを見渡したり、他人を巻き込みやすい機能があること

まとめ

今回、良かったなと思っているのは、ハンズオン会を設けて「こういう運用を行えばこういうメリットがある」という、"なぜやるのか" "どうやるのか"を共通認識化できたことです。
どんなにすばらしいツールでも、それを使う 個々のユーザーに活用のイメージがなければ、その"うまみ"も出てこない と想います。

一方、課題もまだまだあります。
たとえば、作業をしながら作業ログをとにかく書いていくという文化については、さらに徹底される余地があると思っています。
また、歴史的背景やドメイン知識を持つメンバーの偏りにより、口頭コミュニケーションを減らせていない部分もあります。
ゆくゆくは、こうした口頭・同期的コミュニケーションは極限まで減らして、無限にスケールする開発・組織文化を醸成できたらなと思っています。

QA

本筋からはそれますが、これは書いたほうが良いかもしれない、と思う分があるため以下に記します。

asana以外のツール候補は何があったか

asana以外に、notionとclickupは非常に強力な候補でした。
しかしnotionに関しては、asanaほどプロジェクト管理ツールに寄っていないこと、たとえばガントチャート機能がありませんでした。
clickupに関してはレビューを見る限りasanaの上位互換のような印象でしたが、日本から使用する場合、動作が遅く、実際の業務で使うのは難しい印象でした。

役立つ小技などあるか

asanaはメール経由でタスクを作成機能があります。
たとえばAWSメンテナンスの予告のメールをこのタスク作成用メールアドレスに転送するように設定をしておくと、
自動でメンテナンス対応がタスク化され、メールのように忘れる事もなく非常に便利かと想います。

また、すでにSlackを使っている場合は、Slack連携は必ず導入したほうがよいです。
コメントなどの通知をasanaで受けることができ、Likeや返信をSlack内で行うことができます。

何に苦労したか

これは今も試行錯誤中にはなりますが、使い方がチームによってバラけるという現象が起きました。
たとえばタスクの粒度。あるいはプロジェクトの分類。
これらがまちまちであると、タスクが行方不明になったりタスクのアップデートが見えづらいという問題が起きました。
行った対応としては、CTOをはじめとした各チームのリーダーが旗振り役となり、都度都度指摘をしてきました。
これにより、この2つの問題が解決しました。

また、kanbanタイプのプロジェクトの管理もコストが高く苦戦した部分です。

そもそも、asanaのプロジェクトにはkanbanタイプとListタイプがあります。
kanbanタイプはTrelloなどでお馴染みのようにToDo,Doing,Doneの3カラムを用意し、タスクの状況がアップデートされるたびにカラムを移動していくというものです。
Listタイプは、文字通りタスクがリスト状に並んでおり、完了したらタスクを"Mark Complete"していくものです。
当初は両方が混在していましたが、今ではほとんどListタイプです。

最大の理由は、Kanbanタイプは、ステータスが必要以上に増えて冗長になりがちだからです。
たとえば、WaitingやらPending、Laterや"誰々さん待ち"など。
こうしたステータスは一見意味があるように見えますが、各タスクがPendingである理由はまちまちであり、アクションにも結び付かないわけです。
List型であれば、"完了でないタスクが優先度順に並ぶ"というシンプルなルールで運用できます。

結果として、PendingもLaterも未完了は未完了であり、作業を妨げるものがあればそれを解決することが今行うべき仕事であるという考え方に落ち着きました。

Author image
About jiro
expand_less