1. 目的
   1. 過去のタスクを分かりやすくする
      1. これから何年も開発し続けていくのであれば、過去のことを知りたくなることがある
   2. 第三者がどんなタスクをやっているか分かりやすくなる
      1. デジタル化
         1. 付箋以上のことが書ける
         2. いつでもどこでも確認できる
            1. アネックスができても、本社でいつでも確認できる
      2. Web
         1. URLを教えればすむ
      3. レビューする人もし易いはず
         1. 確認すべきことを書いておけば
   3. 1つのタスクにどんな変更がされたがわかる
      1. チケットにコミットログを紐付けることができるので
         1. 現状、コミットログだけでは何のタスクのコミットなのかわからない
   4. デメリット
      1. チケットに登録する手間が増える
2. 方法
   1. GitHubのissue
      1. メリット
         1. コミットに自動で紐づく
         2. issue同士の紐付けも自動
      2. デリット
         1. 俯瞰しにくい
            1. ラベルでしか分類できない
            2. 誰がどんなタスクをしていてどんな状態なのかが把握しにくい
            3. 複数のリポジトリにまたがったissueを作ることができない
            4. web,ios,androidすべてのタスクをまとめて見れない
      3. 運用案
         1. どんな小さなタスクにもissueをつくる
         2. コミットコメント
            1. 一行目
            2. issue名 ＃issue番号
            3. これで自動にissueにコミットが紐づく
            4. issue名を入れるのはtigやgit logで見た時に分かりやすくするため
            5. 三行目
            6. やったこと
         3. マージしたらClose
            1. マージするときに「fixed #xxx」でクローズする
         4. 大きいタスクはマイルストーンを作って複数のissueに分ける
            1. マイルストーンをストーリーみたいな使い方するかんじ
            2. マイルストーンには日付が設定できる
            3. 計画に対しての進捗が分かりやすくなる
            4. 新機能だからコードレビューはちゃんとやったほうがよい
            5. 細かいタスクに分けてそれぞれレビューするかんじにしたい
            6. 案
            7. マイルストーン用のブランチを作成
            8. タスクは↑のブランチからさらにブランチを切って作業
            9. 終わったらマイルストーンのブランチにプルリクエスト
            10. この時にコードレビュを行う
      4. 考えないといけないこと
         1. ラベル
            1. 案
            2. 新機能
            3. バグ
            4. リファクタリング
            5. 着手中
            6. レビュー中
            7. 緊急
            8. 優先度低
         2. issueにどんなことを書くべきか
            1. 案
            2. タスク
            3. 概要
            4. 詳細
            5. 第三者がみてわかるように(こういう操作をしたらこうなる的な)
            6. 必要に応じて画像があると分かりやすいかも
            7. (あれば)関連するissue
            8. バグ
            9. 概要
            10. 再現手順
            11. ログ
            12. 修正方法
            13. (あれば)関連するissue
         3. プルリク
            1. 基本、最初のマージは1issueに1プルリクになるはず
            2. プルリクエストのタイトルどうする？
            3. 「#xxxのプルリク」とかでよい？
            4. issue名とまったく同じだと紛らわしい
            5. issueをプルリクエストにすることができるけど、この機能は今後廃止するかもなんで使わない方がいいと思ってます
         4. デザインもタスクをissueにしてもらう？
            1. 開発のissueに紐付けることができる
            2. issueにするメリットがあんまりない？
            3. このデザインにした理由とか経緯とかあるとあとで役立つ気もする
         5. 他のツールを使う？
            1. 俯瞰できないというデメリットを解消するため
            2. タスク看板あるから大丈夫かも？
            3. 有料
            4. Zenhub
            5. https://www.zenhub.io/
            6. コスト
            7. 30日間無料
            8. 5人まで
            9. ＄25/月
            10. 6人以上
            11. ＄5/人/月
            12. 26人以上
            13. ＄3.75/人/月
            14. メリット
            15. タスク看板的なものをGithubに直接増やせる
            16. Chromeの拡張をいれて、Githubのホームページを拡張してくれる
            17. サイトを行き来する必要がない
            18. ステータスを追加できる
            19. デメリット
            20. Githubの変更に弱そう
            21. GithubをChrome拡張でむりやり変えているので
            22. リポジトリごとになってしまう
            23. Web、iOS全体の俯瞰ができない
            24. HuBoard
            25. https://huboard.com/
            26. コスト
            27. 14日間無料
            28. Organisation課金
            29. $24/月
            30. ユーザ(チームメンバなら)もプロジェクトも制限なし
            31. ユーザ課金
            32. $7/月
            33. メリット
            34. ステータスをラベルで管理
            35. Github上でもステータスが分かる
            36. Slack連携
            37. 表示するissueにフィルターがかけられる
            38. 別のリポジトリも追加できる
            39. デメリット
            40. ステータスを足せない
            41. カードになるのはコメントのみ
            42. コミットログがみれない
            43. waffle.io
            44. https://waffle.io/
            45. コスト
            46. $7/１User
            47. ただし、現在無料
            48. メリット
            49. タスクの粒度を設定できる
            50. ステータスをラベルで管理
            51. Github上でもステータスが分かる
            52. デメリット
            53. リポジトリごとになってしまう
            54. けど、ボードの切り替えは簡単なのでそこまで気にならないかも
            55. カードになるのはコメントのみ
            56. コミットログがみれない
            57. ステータスを足せない
            58. 無料(すでに使っている)
            59. Trello
            60. メリット
            61. issueをカードにできる
            62. デジタルなタスク看板が作れる
            63. Markdownに対応
            64. 詳細が見やすい
            65. デメリット
            66. 手動でステータスを変更する必要がある
            67. issue作成時にカード作るだけ
            68. 更新はしない
            69. Pivotal tracker
            70. issueを自動で登録できない
            71. コミットのみ
            72. 参考
            73. http://qiita.com/androhi/items/4badefa6e6867a853791
         6. ユーザからのフィードバックはissueにしてもらう？
            1. 現在はpivotal
            2. エンジニアがissueに登録しなおすのは二度手間
            3. でもどのリポジトリのissueに登録すればいいのかとか、 フィードバックの内容によってはエンジニアが判断したほうがいいこともあるはず
   2. Pivotal tracker
      1. メリット
         1. タスクの粒度が分かりやすい
            1. pointがつけられる
         2. StoryTypeとLabelで分類できる
         3. コミニティチームが登録しているタスクを流用できる
         4. 俯瞰できる
      2. デメリット
         1. GitHubとの連携がコミットログのみ
            1. 自動で状態が変わらない
         2. ツールが分散
            1. GitHubとこれになる
            2. プルリクはissueになってしまう
      3. 運用案
         1. どんな小さなタスクでも必ずpipotalに登録する
         2. タスクをはじめたら「Points」を設定する
            1. マージされたら「Deliver」する
            2. 本番環境で確認したら「Accept」にする
         3. コミットログにタイトルとIDを入れる
            1. [#88666894] xxxx
         4. プルリクエストにはpipotalのURLをはりつける
         5. 大きいタスクは複数にわける
            1. それらをまとめるタスクをつくる
            2. tasksにIDを書けば紐付けられる
      4. 考える事
         1. デザインのタスクも登録してもらう？
            1. issueの時とおなじ