「書き出す」ことによる制作効率化
序
本記事は、ノリで参加を決めたツクールアドベントカレンダー2023用の5,000字弱ほどの記事です。私の担当は12/14。
ツクールのACということでヘッダにはそれらしい画像を置きましたが、本記事の本論ではツールがどうこうというよりは、個人プロジェクトの管理手法としてわたしが普段やっていることを例として書きます。それが「正しい」かどうかよりも、部分的にでも自分に適用して使えるところがないか、あるいは自分用にアレンジして役立てることはできないか、という角度からお読みいただくと、お互いにとって有意義であろうと思います。なお、これは「管理手法」です。「おれぁいつもそのときそのときのバイブスでゲームをつくるんだ、何事も一期一会、それがいちばんさ！そうだろう？ (CV: 大塚明夫)」というタイプの方には向かないと思いますので、この時点で回れ右、帰ッパしていただくのが妥当であろうと考えます。
自己紹介
本論に入る前に、簡単にわたしの自己紹介をさせてください。
ノロワレ(cursed_steven)といいます。DQとFFで育った典型的な40代男性であり、若い頃になんとなく目にしたツクール2003以降、なんとなく「なんか自分でつくれたら面白いだろうなぁ」と思い続け、最近になってようやくやりたいことがまとまって(=自分なりにまとめる能力と方法を確立できて)MZでそれを進めています。
いまつくっているものの体験版は一応公開はしており、完成版の開発を別途進めていますが、体験版の頃とはいい意味ですでにベツモノになっています。いつ完成するかはわかりません。特に期限は決めていないので。
管理に期待する効果
ある日公式フォーラムを眺めていたときに「出先でいいことを思いついたので帰って自作に反映したかったのだけど帰ってきたら忘れてしまっていた」という趣旨の投稿を見かけました。あぁこれだなと思いました。
忘れていた内容をより早くより確実により正確に復元できるようになっていると、制作の効率化が見込めます。そして、もやもやしたものがあたまのなかに残りにくくなってすっきりします。それがこの管理に期待する短期的な効果です。実はこのもやもやこそ、制作物が完成しない原因としてかなり大きいと思っています。なんかめんどくさくなっちゃうんですよね。もやもやしてると。そのもやもやを発生しにくくすることで個人プロジェクトがぽしゃる確率を下げるのが、この管理手法に期待する中長期的な効果です。
管理できなくなる原因と対策
その管理手法ですが、勘のいい方はお気づきのとおりで、ものすごーく簡単にいうと「思いついたことは全部書き出す」ことです。以前試したことがあるという方もいるかもしれません。それがうまくいかなかった原因はなんでしょうか。おそらく、
どう書いていいのかわからない
時間がかかる
正確さを保つのが難しい
これらのうちのいくつかが該当しているだろうと思います。そうすると、この3点をつぶせればうまくいくかもしれませんよね。それぞれに対策を示したうえで、少しルールを加えます。
多少不正確でもいいから撤回上等で思いついたことを書く
飽きたらそこで書き出すのをやめてよい
思いついた内容に具体的な項目があればなるべく書き留める
毎回、あとで内容を思い出せるようなタイトルをつける
解決したら、解決したことが一見してわかるようにする
これならできそうな気がしてきましたか?
これを積み上げていくだけでも、そこそこちゃんと機能する制作ノート的なものになるのではないかと思います。ぱらぱらめくるだけでも案外楽しかったりして。紙のノートでもいいですし、スマホのメモアプリとか、PCのメモ帳、Excel、いろいろやりかたはあると思います。
ちなみに、さきほどあげた「出先で思いついたけど帰ってきたら忘れた」を予防したい場合は、スマホのスケジュール管理アプリ(ex. TimeTree)が有効です。思いついた内容で予定を登録して、帰宅後にアラームが鳴るようにしておけば、思いついた内容を思い出せる確率を高められますし、ご自宅の作業環境にも反映できそうです。あるいは、スケジュール管理アプリにそのまま思いついたことをどんどん予定登録していくのも良さそうですね。ちょうどタイトルと内容も書けますし。
さて、本論というか、いちばん書きたい内容は実はここまでです。「あれを使ってやってみよう！」というのが思い浮かんだ方はぜひそれを試してみてください。うまくいって、それが習慣化すれば、制作が効率的になって、もやもやしたものがあたまのなかに残りにくくなってすっきりし、ぽしゃる(=いわゆるエターなる)確率を下げられるでしょう。
ちなみに、こういったタスク管理用のツールやサービスといえば Trello とか最近だと Notion とかいいらしいですね。あるいはこういう小さなタスク管理の手法を総称して GTD と言ったりもするので、そういうキーワードでツールや手法を探してみるのもいいかもしれません。
ノロワレがやっている手法
参考までに、わたしが日々実践している手法をご紹介します。
ずばり GitHub です。非エンジニアの方は「何それ?」となったでしょうし、エンジニアの方には「あーでもめんどくさいなぁ」とか「すでにやっとるわい」となった方もいそうですね。しかしここではバージョン管理の話はあまりしません(わたしはやってますが)。
Issues
ここでは、 Issues をご紹介します。
ほかのタスク管理ツールと比べて機能がとてもシンプルなんですよね。基本的な使い方としてはこれだけです。
ほんとうにこれだけ。工数管理まではしていないので(趣味だから)、これだけで基本はほんとうに十分です。わたしの場合、さきほどの条件に加えて、少し追加ルールを設けています。
エラーに遭遇した場合はどこで何をしたときに起こったか内容に書く
可能ならスクリーンショットも添付
ストーリーや新機能についての思いつきの場合はタイトルだけでも可
エラーが解消した/思いつきを実現できたとき、何をしたのかできるかぎり具体的に書いてからクローズする
解決前でも小さなことでも不確実でもその Issue について何か思いついた/わかったらコメントに書く
こうすることで、いま何をすべきか、何で困っているのか、何をやりたかったのか Issues を見るだけで思い出すことができますし、「前に似たようなことやったから参考にできそうだな」みたいなことは Issue を検索して中身を確認すれば、そこに過去の自分がどうやったのか書いてます。単独制作ではなくてチーム制作だとより威力を発揮するかもしれませんね。あるいは、たとえぱ外部に何か依頼する場合はどういうことを依頼したいか Issue を立てておいて、依頼完了したら誰に何を依頼したか書いてクローズするとか。依頼したことを忘れそうならクローズしないで、依頼したものが届いて内容が確認できてからクローズでもいいですね。
下図のような感じで運用しています。いまはクローズ済が220件ほどですが、立ててすぐクローズになる Issue もありますし、何ヶ月も居残ってしまってどうしようかなとなったり、開発終了までやってるだろうなこれ、みたいなのもあったりしますが、とにかく忘れないためなのでそれでいいです。いつかやるでしょうから。いいんです、趣味だし。
あるいは、ちょっと触ってみてこれムリだな、となった場合は「ムリだとして代わりにどうするかな」というのを考えてその Issue を立てて、無理なほうはかわりにそっちを立てましたと書いてクローズしたり。#{Issue番号} と書くだけでほかの Issue にリンクを貼れるのでこれまた便利です。#209 と書けば、Issue 209 へのリンクが自動生成される、という感じですね。
ちなみに画像に出てるIssueはもう全部クローズ済。
Markdown
わたしもけっこう最近まであまり使っていませんでしたが、いざ使い始めるととても便利なのでご紹介します。少しだけエンジニア寄りの内容にはなりますが、これはプログラムを書かない方にも便利だと思います。
日本語だけでわーっと書いてももちろんいいんですが、Markdown を使うと書く内容を見やすく整理することができます。ちなみにわたしはこれでマルチエンディングのプロットを書きました。上記に加えてチェックボックスも使うと、子タスクの管理も楽になります。
いかがでしたでしょうか。プログラミングをしない方、バージョン管理をしない方向けの内容はここまでです。なんかあたまのなかのもやもやが消えてすっきりしそう、効率化できそうと思っていただければ幸いです。興味が出てきた方は GitHub のアカウントをつくってリポジトリを作成し、Issues を始めてみましょう。おつかれさまでした。
cf. GitHubのアカウントを作成する方法
cf. 【GitHub】無料でプライベートリポジトリを作成する方法
Issues とバージョン管理を連携させる
さて、ご存知の方も多いかもしれませんが、バージョン管理をしてる方には、この Issues とのひもづけかたもご紹介しておきます。
これによって Issues にコミットコメントが自動的にのることになります。前述の「前に似たようなことやったんだけどどうやったんだっけ」という状況になった場合、 Issues を検索してそのときの Issues を見つければ、そのときにどういう内容を commit したのかすぐに diff を確認できます。コミットコメントに Issue の番号をつけるだけでできてすごく楽です。コミットコメントにつけるのを忘れた場合は、commit の hash をコピーしてIssues のコメントにはっておけば、それで追跡可能になります。
ちなみに、私の場合さらにコミットコメントにはヘッダ(?)もつけています。
[WIP] : 何か途中だけどキリがいいので commit しちゃいたい場合
[Fix] : 何かの修正が完了した場合や何かの課題が解決した場合
[Add] : 何か新しいものを追加した場合
ex. [Fix] #999
(Issue #999 が解決したときのコミットコメント)
これが何かすごく役に立つということは正直そんなにありませんが、「あれ直したときどこ変えたんだっけ」とかは見つけやすくなるかもしれません。
前段ではこうして書き出すことによって全部覚えておかなくてもよくなりすっきりして効率も上がるというふうに書いたんですが、わたしの場合はそれに加えて「まぁ致命的な問題じゃないしいいか」と思って問題をスルーしてしまうことも劇的に減りました。これはクオリティを上げることにもつながっている実感があります。とりあえず書いておいて、気が向いたら検証して、問題があれば解決し、問題なければそのままクローズしてさらにすっきりするというよいサイクルができていますね。
さて、いかがでしたでしょうか。
気がついたら結構書いてますが、とにかく「あたまのなかをクリアにする」ことがぽしゃる可能性を下げることにつながると信じているので、わたしは今後もこれを実践していきます。よさそうだなと思った方は参考にしていただければ。
いじょうです。