$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

Asana使ってみた

最近タスク管理ツール何がいいかと思っていろいろ使ってみている。今回はAsanaのメモ。


Manage your team’s work, projects, & tasks online • Asana

良い所

  • Asanaはチーム利用としてはセクション分けしたりコミュニケーションがし易いように思えたので良さそう
  • チーム > プロジェクト > タスクといった階層でプロジェクトを作れるので、特定チームに所属し、その中でプロジェクトが複数走っていて、それらを別で管理したいというときには使えそう
  • タスクじゃなくてセクションもちゃんと区切れて、意外とそれが便利に使える
  • アサインしている人ごと、締切ごと、みたいな感じでいい感じにソートできるのは便利。どういうふうに整理されるとタスク管理しやすいかがよく考えられている
  • サクサク入力できる(イメージ)
  • iOSアプリが良く出来ているように見えた
  • Due Dateの繰り返し設定が結構細かく出来そう

悪いところ

  • 日本語利用していると結構な頻度でバグにぶつかってだいぶ辛い
  • Sunriseとのカレンダー連携が使えそうだったので連携してみたが、何故か同期されなかった -> 出来るって話もあるので、やり方ミスってるだけかも
  • 締切を決めるときに日付でしか決められず、時間の指定はできない
  • Mac用のアプリは無い

感想

自分としては個人のTODO管理に利用しようとしていたので、締切を日付でしか決められないなどといった問題点が致命的になりそうで使うのは諦めた。ちなみに最近はProducteev、Trelloといったツールも使っているが、今のところは

  • チームで利用するなら Trello = Asana > Producteev
  • 個人で利用するなら Producteev >>> Asana > Trello

という感想です。

あとは http://www.sekai-lab.com/times/?p=473が参考になるので読むと良さそう。

その後のTwitter

問題 => 原因 => 解決方法という順で物事を考える

今日LIGのブログを読んで、直近自分の中で課題に思っていることと近いことがそのまま書かれていたので、非常に参考になった。そこで自分の思考を整理するためにも、以下の記事を読んでそのあたりについて思うところを書いてみる。


プロジェクトでトラブルが発生したときにWebディレクターがとるべき3つの手順 | 株式会社LIG

自分自身の課題

最近の自分自身の課題としては、「問題が発生したときに、すぐに解決手法を考えてしまう」というものだった。それには全く自分自身では気づいてなかったのだけど、最近はあるところで

  • 問題を見つけた時、いちどその原因はなにかを考えたほうが良い
  • 問題 = 原因ではない、そこを意識した方がいい

との指摘を受けて、確かに自分は問題だと思ったときに、それが本質的な問題か別の問題なのではないかと考えてはいたと思う一方、問題の原因とは何かについては深く考えてなかったということに気づいた。

問題 => 原因 => 解決の順で考える癖をつける

その課題に気づいたときにまずどうしようかと考えた。その時同時に、「考える力が無いのではなくて、原因を考えるという部分が癖になっていない」と言われたので、ひとまず癖をつけようと考えた。そこでひとまず癖をつけるためにどうしたら良いかを考えた結果、一番シンプルに以下のような言葉を自分の仕事場のディスプレイの下に貼り付けるということをした。

問題を発見 => 原因を考える => 原因を取り除く解決策を考える

この貼りつけた言葉は正にプロジェクトでトラブルが発生したときにWebディレクターがとるべき3つの手順 | 株式会社LIGで言われていることだと思う。

ディスプレイの下にシンプルな言葉を貼っておくと大体目に入るし、何度も目に入れておけばさすがに覚えるし、それによって今の問題 => 解決方法とすぐに考えてしまう課題を、問題 => 原因 => 解決とかんがえる癖に変化させることができると考えた。まだ初めてみて2日だけど、これは現状のところ直感的にうまくいきそうという風に思った。


またこの言葉を貼り付けたときに、最近勉強したやり方を使うとうまく出来ないかと考えたら、具体的なアクションを考えることが出来た。それは以下の二つのことである。

  • 問題が、事実なのか解釈なのか、を意識する
  • 原因把握には5回のなぜ、whyツリーを使ってみる

そこでこの二つについても軽く紹介してみる。

問題が、事実なのか解釈なのか、を意識する

最近勉強した考え方の一つとして空雨傘というフレームワークがある。

これが問題を考えるときに役に立つのではと考えた。つまり問題と思っていることが、「事実」か「解釈」のどちらかの可能性があるので、まずどちらなのかを一度考えるようにする。事実であればそれは本当に起こっている問題だし、解釈なのであればもしかしたら問題の「事実」があり、それを自分の主観に直しているのかもしれない。

これを一度考えることで問題に対する自分の理解を深められると考えたので、意識することにした。

原因把握には5回のなぜ、whyツリーを使ってみる

こちらも最近5回のなぜ、whyツリーという二つの手法を勉強したので、原因把握の精度を上げるためにこれを使ってみようと考えた。

原因把握をするときに単に浅く考えてしまうと、それが根本的な原因ではないものを原因と判断してしまうことがある。そこでそれをもうちょっと深く考えるためになにかしらツールを使ってみようと思った。

使えそうなツールは

というものがありそうだったので、これを使ってみようと考えた。

まとめ

問題 => 原因 => 解決を考える癖を付けたいという話題で幾つか自分の頭を整理するためにブログを書いてみた。他にこういう考え方がある、癖を付けるならこういうことをすればよいのではないかという話があれば教えて欲しいです。