※ I (maybe) will translate to English (maybe)
プロジェクトキックオフ（あるいは後発ジョイン）のごくごく初期に、全力で以下のことを明らかにしようと心がけてる。
- Task Base
- Document Base
- Source Base
- (optional) Communication Base
多くのプロジェクトがわりと情報を散らかしてるし、口頭のコミュニケーション（場合によっては口論）ですべて解決できると思ってて、非常にたちが悪い。
Task Base
- JIRA
- Asana
- Trello
- GitHub issues
- Mantis <- 最近知った
「何をやらなきゃいけないか」を明らかにするためにある。「やらなきゃいけない」というのは、「理想」と「現実」の「差分」。したがって、Task Baseには「（そのタスクにおける）理想の形」が明記されていなければならない。その点を理解してない人がつくったタスクは非常につらいものがある。
Document Base
- Confluence
- GitHub wiki page
- Qiita
ある種のタスクには「○○を決める」というような「具体的なもの」ではない「理想の形」を持つものがある。この「具体的でないもの」の「アウトプット」の記録媒体として、Document Baseは使われる。日報を書いたりポエムを書いたりするものではない。これを共有サーバのWebDAVとかでやるプロジェクトもあったけど、あれはクソだ。アクセス権限の管理がだるいし、URLの共有がだるいし、バージョン管理もだるい。
Source Base
- GitHub
- BitBucket
ソースコード管理が必要な理由は割愛します。
Communication Base
- Slack
- Skype
- Gitter
これはべつに明らかにしようとしなくても明らかになってる場合が多いので、頑張らなくてもいいんだけど、だいじなのはおそらく、顧客のコミュニケーションスピード？意思決定のスピードとか、バグなどの問題の透明性を知るために、顧客が使ってるcommunication baseを知り、可能な限りそこに溶け込む必要があると思っている。あるプロジェクトで、無理にSlackへの移行を進めた結果、結局顧客のコミュニケーションが二元化してしまい、問題の共有（とくにサーバサイドのバグの共有）がされず、遅延の原因やブロッカーの存在が不透明になってしまうケースがあった。
最近思うこと
- 1つのプロバイダーで統一してほしいと思う
- とくにConfluenceとJIRAの組み合わせは気持ちいいので好き
- とにかくvisibleにしてくれー口頭で言われてもわからんー
- Tasksの表示方法って個性があっておもしろいなって思う
- Trelloとかもう1depthしかなくて並列だし
- JIRAはサブタスクつくれるけど2depthまでだし
- ツリー構造で簡単に表示したいんだけどな
- GitHub issueは1depthでfiltering哲学だよな
- Asanaはお化粧だけ整えてて直感的ではない
- Taskを定義する人間にTaskに必要な情報を強いないので、Taskが意味不明になりやすい
- Taskを定義するうえでTaskに必要な情報の入力を強いるツール/フレームワークが必要
- とかつらつら考えてたら、サービスつくりたくなってくるわけで、こういうのがプロダクトのタネになるんだろうな