一人開発にも「レビュー」と「チェックリスト」を入れたら事故が減った話
個人開発にはレビュアーがいません。コードレビューも、リリース判定会もない。全部ひとりで書いて、ひとりで公開ボタンを押します。それで何が起きるかというと、「直したのに別の場所の直し忘れ」と「動くけど言っていることが違う」が、静かに積もっていきます。このサイトでは、その対策としてチェックリストとセルフレビューを運用に組み込んでいます。飾りではなく、実際に事故を捕まえた実例ごと書きます。
チェックリストは失敗のたびに1行増える
最初のきっかけは、ささいな更新漏れでした。新しいゲームを公開したのに、運営者情報ページの作品リストが古いまま。それ自体は5分で直る話ですが、「同じ種類の漏れは今後も必ず起きる」と考えて、更新チェックリストというファイルを作りました。「ゲームを追加したとき」「ページを追加したとき」のように変更の種類ごとに、更新すべき箇所を列挙したものです。
大事なのは、このリストを失敗のたびに育てることです。つい先日も、5作目の公開でトップページ・紹介ページ・FAQ・サイトマップまで更新して満足していたら、リポジトリの顔であるREADMEだけが3週間前のままでした。指摘されて修正し、その足でチェックリストに「ルートREADMEも更新（忘れやすい）」の1行を、発覚の経緯つきで追加しました。チェックリストとは、過去の自分の失敗の目録です。だから他人のテンプレートを借りてもあまり効きません。
リリース前に「自分にレビューを依頼する」
大きめのリリースの前には、観点リストを使ったセルフレビューをします。観点は過去の障害から抽出したもので、たとえば「進行詰み: 一度きりのイベントのフラグを表示時に立てていないか（選択時に立てないと、中断→再開でイベントが消滅する）」「セーブ互換: 新しく足したフィールドが、旧セーブに存在しなくても安全か」「localStorage の書き込みが try/catch されているか（プライベートモードで例外になる）」。
直近のリリースでこのレビューが実際に捕まえたのは、①終盤の固定イベントが中断→再開で二度と出なくなる進行バグ、②ミュートボタンの保存が保護されておらず特定環境でボタンが死ぬ問題、③本文の「全15種」表記が実装では17種になっていたズレ、の3つでした。どれもテストプレイでは気づきにくいものです。とくに①は、レビュー観点として言語化してあったからこそ「この形のコードは怪しい」と機械的に疑えました。
「数字はgrepで突合する」という観点
③の表記ズレから、新しい観点がひとつ生まれました。本文に書いた数字は、リリース前に実装から数え直して突合する。「全N種」「N枚」「勝率N%」のような数字は、機能を追加するたびに古くなりますが、文章は勝手に更新されません。対策は単純で、その数字でリポジトリ全体を検索することです。「15種」で検索したら、紹介ページ・ブログ記事・開発メモの5箇所が古いまま見つかりました。数字を書くときは「あとで検索で洗える形で書く」と意識するようになりました。
指摘は必ず記録に残す
レビューで見つけた指摘は、直して終わりにせずレビューログという記録に残します。何を見つけて、どう直して、どんな教訓を一般化したか。さらに教訓は観点リストにも反映するので、次のレビューは前回より賢い状態から始まります。一人開発では「言った・聞いた」が存在しないぶん、書いていないことは全部消えます。逆に言えば、書きさえすれば、過去の自分が未来の自分のレビュアーになってくれます。
続けるコツは「置き場所」と「タイミング」
この手の仕組みは、作るより続けるほうが難しい。続いている理由は2つあると思っています。ひとつは置き場所で、チェックリストもレビューログも、Wikiやメモアプリではなくゲームのコードと同じリポジトリに置いています。コードを触るとき必ず視界に入るし、コミット履歴にも一緒に残ります。もうひとつはタイミングで、「あとでまとめて書く」を禁止して、リファレンスの更新は開発と同じコミットでやると決めています。あとでは、来ないからです。これは自作ゲームに出てくる「あとで直す」カードが毎回教えてくれます。
ひとりのチームをつくる
結局のところやっているのは、チーム開発が自然にやっていること——レビュー、チェックリスト、ふりかえり、ドキュメント——を、時間差の自分たちで分担することです。今日の自分が書き、明日の自分が査読する。コストはかかりますが、「公開ボタンを押す手が軽くなる」というリターンは想像以上でした。個人開発こそ、仕組みで自分を守る価値があると思います。