はじめに
個人開発とノリと勢い
個人開発においてはノリと勢いが大事みたいなところがあると思う。リリースまでなるべくスピーディーに、モチベーションが潰える前に持っていきたい。儲かるわけでもないなら、なおさらだ。
個人開発は企画も実装も一人でやる。すべて個人のアタマで完結するなら、ひたすら実装するのが最速、という考え方もあるかもしれない。
しかし個人のアタマで完結する開発だからこそ、個人としてのミクロな視座に縛られやすくなる部分もあるのではないか。マクロな視座を失うと、作業戻りが発生しやすくなる。余計な時間がかかる。現在地が分からない不安は、モチベーションの維持を難しくする。
逃げ切るためのプロジェクト管理
ミクロな視座に囚われやすい個人開発にこそ、客観的にプロジェクトを把握しながら進行させる、(チームでの)プロジェクト管理のアプローチが有用かもしれない。本稿では、これまでチームでの開発に従事してきた筆者が、プロジェクト管理の手法をゆるふわに個人開発で運用した事例を紹介する。
事例について
先日、個人で開発したアプリをリリースした。このアプリ開発を立ち上げ、開発を軌道にのせるまでに、どういったプロジェクト運営がなされていたかを記述していく。
あえて方式に名前をつけるなら「脱力系アジャイル」だろうか。チームで開発したことのある人なら新規性のある内容は少ないと思うが、どのくらい「脱力」しても破綻しないのかという事例として読んでいただけると嬉しい。1
プロジェクトの進行
おおむね以下のステップを踏んだ。
- 開発意義の確認
- プロトタイピングとバックログの整備
- 優先度と期日の設定
- 実装
開発意義の確認
なによりまず、開発する意義(作った場合の自分にとってのメリット)を、自分なりに言語化した。2
挫折するのは嫌だったので、なるべく自分の逃げ道を潰すように、やることに必然性すら感じるように、なんとか説得した。
うろ覚え
以下の様な説を自分に説いた気がする(明文化した記録が無かった)- スマホアプリ開発の経験が無いのはよくない(かもしれない)：
アプリを公開するインターフェースは個人に対してもオープンなのに、仕事・会社経由でしかそれを利用しないのは損失がデカい説(やろうとしたことすらないので、損失の大きさが測れないのがマズい) - 経済的安全保障：
今はスマートフォンの保有者はPCの保有者よりも母数が多いはず。既にあるWebアプリの経験はPC/スマホ問わないにしろ、アプリ開発実績があった方が先々食いはぐれにくい説 - 社会的意義：
アプリは昔の自分が欲しかった機能を備えたもの。自分は一般人である以上、同じニーズを持った他の人間が少なからず存在するはず。同じ切り口のアプリは存在しなそうなので、提供すれば少なからず誰かが喜ぶ説
プロトタイピングとバックログの整備
ここでいうプロトタイピングとは、アプリのサンプル画面を作ることである。
バックログは、必要な機能とか、不具合とかをテキストで積んでおく場所のことだ。
プロジェクト立ち上げ～実装初期には、プロトタイピング/バックログと実装の間を、頻繁に行き来することになった。それぞれ詳しく見てみる。
プロトタイピング
アプリのサンプル画面を作る。完成形に具体性を持たせることで、アイデアが妄想止まりでないことを自分に問う意味もあった。
ツール
業務ではFigmaが使われることが多い。デファクトスタンダードだと思う。先日のアプリ開発においてもFigmaを利用した。
プログラムで実装してスクショを撮ってもいいが、立ち上げ段階では画像(Figma)だけで作った方が効率がよかった。
Figmaを使うと、サンプルをコピペして一部を変更し、複数案を横並びに比較するのが楽なので好きだ。
パクり元探し
サンプルを作るときは、世に出ているアプリのなかに、自分のやりたいことにマッチしたUIを提供している例がないか探した。
相手のデザインがどんな目的や操作に最適化されているのかを考えて、自分の実現したいことに転用可能かも検討した。
ただしリリースを急いだので、これらの実施は時間内にできるだけ、という程度にとどめた。
UI図鑑
いいな、とおもったUIがあればスクショを撮ってどこかにまとめると便利だ。
先日のアプリ開発では、当初のモチベーションがGxxgle Calenderの「たられば」を作りたいというところにあったので、忘れないようにGoogxx CalenderのスクショをFigmaに貼った。UIはそっくりになった。許してほしい。
バックログの整備
必要な機能とか、直すべき不具合とかをテキストで積む。
プロジェクト立ち上げ段階では、完成形のアプリが備えているであろう機能を、思いつく限り書いた。実装に着手したあとは、発見した不具合や思いついた新仕様をもれなく書いた。
開発迷子にならないのが目的なので、迷子にならない程度の最低限の情報しか書かなかった。タイトル、備忘のための詳細(あれば)、優先度、タスクの状態くらいだろうか。
ツール
タスクの全量と完了状況を一目で見れる状態にしたかった。逆に言えば、見れるものなら何でもよかった。
先日のアプリ開発では、Azure DevOpsというプロジェクト管理ツールをつかった。たんに好奇心のためで、業務で使う機会がないからだ。類似のサービスの有名どころには、JiraやClickUpがある。
もっとシンプルに、GSSやExcelでも十分だったとは思う。
タマゴ・ニワトリ・プロブレム
先日のアプリ開発では、プロトタイピングから着手した。どちらから入ってもよかったが、そういう気分だった。
プロジェクトの立ち上げにおいては、プロトタイピングとバックログの整備は、どちらから着手してもいいと思う。言語化してはじめてUIが決まるパターンもあれば、逆に画面のイメージが既にあって、そこから言語に落とし込むパターンもある。
より手が止まらない方法をとるよう、適宜切り替えるのが正解なのだと思う。
優先度と期日の設定
優先度設定
優先度は明文化された基準を持たず、かなり感覚的に付与した。
後付けで明文化した
- 優先度高：無いとアプリの存在意義がなくなる機能や、その機能が利用不能になる不具合
- 優先度中：優先度高ではないが、存在意義を損なうもの(ex. 機能を利用するのに手数が多い、機能を正常に利用できる確率が低い など)の改善
- 優先度低：優先度高でも中でもない - 利用に差支えない不具合(ex. 見た目が悪い)。アプリの存在意義は脅かさないが、あった方がうれしい機能
あたりが意識されていた。
期日設定
タイトな期日は引かなかった。優先度順に並べたものを、(確保できた時間内に)ただ上から倒せばいい状態を目指した。
頼まれたわけでもない開発だし、生きるために必要な仕事、の余り時間での作業が前提だったからだ。
…とはいえ無限に先延ばしになるのはおそろしいので、
- 先1-2週間に確保できる時間の見積もり
- 1週間を1イテレーションとしたときの、1イテレーション内にこなせるはずのタスク
は定期的に設定と見直しの時間をとった。3
振り返りはマジメに
期日設定と見直しの時間は、だいたい週に1度くらいの頻度でとった。
当初想定した期日内に終わらないとか、新しい要件や不具合が発生したときは、期日とあわせて優先度を見直した。
計画が破綻した状態を放置すると経験上100%グダる。破綻すること自体は許すとして、現実との整合を取り直すことだけは必ずやった。
実装
実装フェーズはあんまり迷う部分がなかった。これまでのプロセスで整頓されたタスクを、上から潰していくだけだったからだ。
実装すると、新しい機能のアイデアや不具合がボロボロ湧いてくる。こういった要件は確実にバックログに積む。UI上どこに置くべきか定まらないときは、プロトタイプを何案か書き起こす。
こうすると自然に 実装 -> プロトタイピング/バックログ整理 -> 計画 -> 実装 -> ... というサイクルが回ることになった。脱力系アジャイルの所以である。
サイクルを何周目かした頃、アプリが最低限の存在意義を果たせる程度になった。当初予定していたリリース期日は過ぎていたので、堪忍してリリース作業に移った。
おわりに
今回の事例で運用されていたのは、チームでアジャイル開発している人にとっては極めてアタリマエな方法論だと思う。
ただ世の中のすべての開発者がその経験者というわけでは無いはずで、仮にチームでのアジャイル開発経験者でも、すべての人があらゆる役割を横断的に経験したわけでは無いはず。
個人開発にはチーム開発のノウハウを活用できる一方で、個人開発ならではの横断的な刺激があるように思う。
ある種の刺激の片鱗を感じて、踏みあぐねていた一歩踏み出すこと、自分の創作をやり遂げること、そういった助けになれば、本望である。