Peridot Engineの開発タスク管理法とか

ほぼほぼタグでネタバレ奴です。

前日は @ounziw さんの「プロダクト名が表に出ないホワイトラベリング」( https://note.com/fumitomizuno/n/ne9dcd844d2fb ) でした。
Unityなんかもアプリタイトル名、パッケージ名はもちろん、スプラッシュロゴも書き換えられる(ただし課金が必要)のと、かなり作り込めばUnityっぽさが消せるのでこういった「ベースとなるプロダクトを顧客に感じさせないようにする」ことは可能ですので、ゲーム系でも馴染みが深い話題でしたね。もちろんPeridot Engineも可能な範囲で隠せることを目指しています。
こういった「ベースプロダクトの目隠し」みたいなことを実現する仕組みを「ホワイトラベリング」というのですね、勉強になりました。

ということで、本題です。

Peridot Engineという自作ゲームエンジンをここ1年ちょっとほどずっと一人で開発しています。
個人開発Advent Calendarということで、ちょうどよいのでここ1年であらかた整備したタスク管理環境のお披露目とかしてみたいと思います。
ガッツリ技術系の話ではないんですが、何かしら参考になれば(なるのか？)幸いです。

動機

自分はあまりやることに対して脳の記憶領域を割きたくないと思う派です。というより、 たとえ記憶が消えるほど飲んだとしても 翌日にはちゃんと続きから作業できるようにしておくのが理想だと考えています(たとえ話です。ねんのため)。
そのため、BacklogやGitHub Issueなどを始めとした「何かしら書ける場所」が用意されていれば基本的には考えてること全部メモ書きしますし(もちろんある程度整理はしますが)、なくてもMac標準の「メモ」アプリやvim/vscodeで雑に新規ファイル作ってメモを書くことは比較的多くあります。
で、そうしたメモは(かなり労力を割かないと)本当に雑記以上にはできないので、散らかりがちです。「考えていること」と「やるべきこと」などとを永続的にリンクさせるために一定の「タスク管理システム」は重要と感じています。
仕事では申請類が面倒なので(案件内の小さな案件みたいなものは)スプレッドシートにやることと進捗などをあわせて書いてることが多いですが¹、今回は個人開発で(自分の財布以外に)制限はないので、複数サービスを組み合わせて管理してみることにしました。

合わせたもの

以下の4つを雑に組み合わせました。

• GitHub: Engine本体の実装状況の管理
• ZenHub: カンバン型進捗管理
• Trello: Engine本体以外(SlackのBotなど)の開発進捗管理
• Slack: 情報の集約+通知+趣味

順に解説していきます。

GitHub

Peridot EngineはコードのバージョニングにGitを使っていますので、当然のごとくホスティングサービスにGitHubを使用しています。BitBucketを始めとした他のホスティングサービスと比較した際の利点はちょっとわからないです(GitHub Actionsとかになるんですかね？PeridotだとZenHub使ってる関係で選んでる気がしますが)。
ブランチワーキングはオーソドックスなGit Flowに多少毛が生えたような感じで、develop(dev)を主軸に開発を進めています。

一人開発ではおそらく珍しいであろう、devに向けてのPull Requestを自分に向けて飛ばす開発フローを採用しています。
https://github.com/Pctg-x8/peridot/pulls
なんでそんな面倒なことしてるの？という感じなんですが、Pull Requestとして今までの作業や成果を もの として残すことで、実装状況を一覧で見たり検索したり、あと次のZenHubによる進捗管理との相性も良かったりします。
GitHubのIssue(Pull Request含む)は互いに依存関係を結ぶことも可能ですし、Pull Requestと関連するIssueをリンクする機能もありますので、動機で話していた「考えていること」と「やるべきこと」、さらには「結果としてやったこと」「何が原因で詰まっているのか」までを一つに結ぶことができ、Pull Request一つ見ただけで思考や手順の整理がしやすくなり、結果として非常にローカロリーで開発を続けていくことができています。

ZenHub

おなじみ、GitHubにカンバン型の進捗管理を導入するサポートプラグインです。GitHub単体でもProjectsを使えば似たようなことはできますが、ZenHubのほうはEstimate²をベースとしたバーンダウンチャートなどの出力も可能で、スケジュール管理もできるので進捗管理のサポートとしてはかなり強力な感じです(ただしバーンダウンチャートを使ったことはありません。マイルストーン作ってないので......)

Peridot EngineではZenHubのデフォルトで用意されるパイプラインをほぼそのまま使用しています。最初にIssue(やること)を建てた場合にNew Issueになるのはデフォルト同様で、そこから

• 「近くやること」を2～4つ「In Progress(作業中)」に
• 次のリリースに必須と思われる作業を「Essential/Emergency(高優先度)」
• それ以外を「Planned/Possible(低優先度)」

に適当なタイミングで割り振っています。本来であれば隔週でこういった作業をやると思うんですが、個人開発なのでこの辺はちょっと適当です³。

Trello

Peridot Engine本体に関しては上記リポジトリがどんとある状態なので、そこで進捗管理すればOKです。
それ以外の、Slack上で動いているBotなどの管理は、セキュリティ観点などからGitHubへの誤送信を防ぐ意味合いでGitで管理していないものも多く⁴、実は数ヶ月前までタスク管理を行っていない状態でした。まあ小さなプログラムなので行わなくてもいいっちゃいいんですが、「なに改善しようと思ってたっけ......」ってなることが増えてきて若干ストレスになっていたので、思い切って別の進捗管理システムを導入することにしました。どちらかというと 備忘録 というやつですね。

BacklogやRedmineなど様々なサービスがあるとは思いますが、今回はTrelloを採用しました。個人開発なので、Power-Up(プラグインみたいなの)一つという縛りはありますが無料の範囲で使用できます。Power-UpはSlack連携以外使用する予定は全然ないので、そのくらいの制限であれば問題ないでしょう。

Trello最大の利点としては「カードに直接コメントを残せる」というところでしょう。表示もまんま「アクティビティログ」となっており、活動記録や思考メモなどを残すのにピッタリです。それ以外にも「メンバーのアサイン」「ラベル」「チェックリスト」「期限」などといった情報をカードに付加することが可能で、いたれりつくせりです。ラベル以外は例によってPeridotでは使用していませんが......

ラベルはGitHubにもあるラベルほぼそのままの使用感です。カードに対してカテゴライズを施したり、ラベルで検索を行ったりすることができます。
ひとつ難点としては、カラーバリエーションが非常に少ないことでしょうか。カンバン全体表示の場合、ラベルのテキストは隠れてラベルカラーのみの表示になってしまうため、実際に開かないとどういったラベルなのかの区別がつけられないことがあります。

Slack

個人開発をしぶとく続ける上で一番重要なのは「楽しく開発すること」そして「楽しさがずっと続くこと」だと思っています⁵。
そのため、Peridot EngineのSlackでは前述のタスク管理システムからの通知以外に、がっつり趣味なbotを専用の部屋を切って稼働させたりしています⁶。

Slack上では、主に以下のようなチャンネルに専属botを稼働させています。

• #repo-acitivities: GitHubのIssueに関するWebhookをLambdaで受け取って、それをSlackに再フォーマットして通知してくれる「こゆきちゃんbot」
• #ci-notifications: Travis CIの結果をLambdaで受け取って、それをSlackに再フォーマットして通知してくれる「東北ずん子」
• #envtask-repo: Trelloのカードの更新などを通知してくれる「Trello」プラグイン
• #dotlive, #kemo: 特定条件に当てはまるTwitter投稿をほぼリアルタイムでリポストしてくれる「TwitterTagTracker」(趣味bot)

アーキテクチャ的には以下

4番目のみががっつり趣味なbotで、モチベーションやアノテーションの維持に一役買っていたりするんですが、他のbotのキャラ選定も割とがっつり趣味です(3番目以外。いつかWebhook導入して作り変えたい......)。
ちなみに、#generalが(動機で話していた自身の性格上)#randomに近い運用になったので⁷#randomはまっさきにArchiveされました。

上記記載チャンネル以外には、スクリプティングシステム(LLVM)の検証などをメモする「#scripting」などの部屋も作っています。こういった部屋は、いわゆる「特定のタスクに結びつかない雑多なメモ書き」を残す箇所として作っています。Peridotはリッチにも（？）Standard Planを契約していますので、Slackにメモ書きしたものは解約しない限り残ります。後に参考にしたり続きから検証を始めたりすることができるので、検証作業の効率化の役に立ちます。

おわり

最後ちょっとbotの自慢みたいになってしまったんですが、いかがでしたでしょうか？
いうて個人開発、されど個人開発という感じで、個人開発の小さなものだから、といってタスク管理を疎かにすると進捗が悪くなったり、最悪エターなったり⁸しますので、かんたんにでもタスク管理を導入しておくとスムーズに開発ができるようになると思います。

1. スプレッドシートはセルにメモ書きを入れることが可能なので、そこに前述の雑記を詰め込んでいます。 それでも散らかるときは散らかりますが、メモAppとかに脳死で書きなぐるよかマシ ↩

2. 実際の見積もり工数ではなく、ある小さな作業を「1」とした相対的なタスクの「大きさ」を振ることで、柔軟な残タスクの見積もりや優先度決定をサポートしてくれるものです。Peridot Engineでは小さな作業がどのくらいか把握ができていないので、Estimateは使っていません ↩

3. だからいつまでたっても完成しないのでは？？？？ ↩

4. 殆どは小さなプログラムなので、そもそもバージョニングは不要と考えています。良き感じにコミット切れば適当にロールバックできる利点はあるんですがあんまロールバックする機会がない...... ↩

5. ただゲームエンジン級に巨大な個人プロジェクトってそうそうない気がするので、これが当てはまるのはかなり限られそう ↩

6. 例えば、けものフレンズ公式関連のTwitterをひたすら収集するbotがありまして、そこでけものフレンズ3のGoogle Play Best of 2019ノミネートを知ったりして「大きくなったなぁ......！(エゾヒグマ)」などと思ったりしております。エゾヒグマさんそんなこと言ってなかった気がしますけど ↩

7. というより、複数人workspaceでもなければ雑談専用chを設ける理由はほぼないですね ↩

8. https://forum.tkool.jp/index.php?threads/%E3%82%A8%E3%82%BF%E3%83%BC%E3%81%AA%E3%82%8B%E3%82%92%E9%98%B2%E6%AD%A2%E3%81%97%E3%82%88%E3%81%86%E3%80%82.149/ ↩