アプリを一つリリースして気づいたことをまとめます。
この記事は、20分・90分タイマーの開発振り返りとして作成しました。
tomo-mana.hatenablog.com
以下は20分・90分タイマーの開発工程をまとめたものです。
線表にするといろいろ気づくことがあります。
工程をふりかえる
各工程での遅れをガントチャート線上に載せてみました。
凡例にありますが、緑が目標工数、オレンジが遅延、灰色が並行して作業したためクリティカルパスに載らなかった作業です。
実は、最初はタイマーだったらすぐに作れると思っていました。
当初想定していた工数から、どれくらい予想と違ってたかを示したのが、以下の図です。
分析には、開発者目線と管理者目線とが必要だと感じます。
※実際は、計画したのも作ったのも自分です
遅延と計画変更の繰り返し
管理者目線では、当初の計画工数に大幅な工数見積の誤算があり、大幅な遅れがありました。また、機能要求に欠陥があり、重大な作り変え（仕様追加）がありました。
ただしこれは、ウォーターフォールの場合の視点です。
市場テストの繰り返し
リーン・スタートアップやインクリメンタル開発の視点では、違った視点に見えました。
市場ニーズがあるか分からない製品では、できるだけ早くプロトタイプを作ってフィールドテストを行うのがセオリーです。
その点で見ると、このプロジェクトは技術的に不明確な部分を残しながらも開発を進めており、２週間単位のインクリメンタルを３回行ってそれぞれ試作を作り、フィールドテストを試した、と解釈できます。
※フィールドテストの相手も自分です（ユーザー目線）
タスクを３日で片づける
開発者目線では、各タスクを３日単位で進めていました。これを管理者目線で見たら、それなりの速さでキャッチアップと取捨選択をしていた印象を受けます。
時間がかかったのはサービス実装とスリープ解除でした。
この作業は、実際は以下の３パートに分かれており、それぞれ結果ベースでの作業ボリュームは３日ほどでした。
(1) Unityにおけるgradleコンパイル環境の理解とAndroidManifest.xmlをはじめとする各ファイルの配置方法の理解（2/11～2/15）
(2) Foregroundサービスによるサービスの立ち上げとライフサイクルの理解、タイムアウトにおけるコールバックの実装（2/16～2/18）
(3) スリープの強制解除（アラート）の実現方法の模索（2/20～2/23）
開発者から見ると、見積工数に対する明らかな遅延がありましたが、管理者から見ると、見積工数から遅れているものの、開発者が知識ゼロの状態からスタートしたことを考えると、そこまで悪くない（むしろ早い）ように感じます。
※自画自賛ではなく視点の話です。実際には常に遅延している感覚で、超アセアセしながら作業していました。悪しからず…
ただし、全体としてみた場合、実装にすごく時間がかかっている（苦戦している）ように見えます。
気づいたこと
開発線表にプロットした内容から、全体と個々の要素について気づきと遅延理由を挙げると、大多数の方が個人開発で感じることと同じことが挙がりますが、
●思ってたより工数かかる
（今回はUnityの特性を理解していなかったので、想定の12倍の作業コストがかかった）
●挫折ポイントが多い
以降の目安として、技術課題を残した状態での開発は悲観的な見積で想定の10倍、技術課題が無い状態で市場性の検討に必要なのは実装工数の２倍（フィールドテスト、およびデバッグ、リリース時などにかかる工数）、これくらいを目安にしてみようと思います。（また次のアプリを作り終わったら、振り返りをしてみたいと思います）
思ったより工数がかかる
今回、最も想定より工数がかかるきっかけになったのは、Unityの特性（バックグラウンドに入ると Update() が止まる）を理解していなかった事でした。
これは、バックグラウンドでの動作を想定しないアプリでは発生しないコストかもしれませんが、今後の参考になりました。
その他工数がかかったものについては記事にしてまとめておこうと思います。
●Unity：Android環境でコンパイルが通らない
●Unity：バックグラウンド中はUpdate()が動かない
●Admob：2つのIDの使い分けが分からない
●Unity→Android：AndroidManifest.xmlの作り方が分からない
●Unity・Activity・Service間のメッセージのやり取り（Intent）
●リファクタリングの欲に打ち勝つ（１か月で組み切るならやめておく）
●スリープ解除：deprecatedの嵐
挫折ポイントが多い
ある意味で、先ほどの開発線表にあるすべての吹き出しは、挫折ポイントになり得ます。40日の開発期間内で、11回は挫折しそうになったことを意味します。
人に頼まれて作っている案件も、それはそれで苦しいものがあるのですが、一人で作っている場合、別の苦しみに悩まされることが分かってきました。
個人開発者の中に居る３つの視点があります。開発者、管理者、ユーザーの視点です。
開発者としては、めんどくさい機能は、ユーザーが我慢してくれれば作りたくない。
ユーザーは、不快な操作があれば、即離脱します。または改善を求めます。
管理者は、売りを立てたいので、できる限りユーザーの意向に沿いたいですが、作業採算性を考えると、どこまで投資し、どこで手を引くかを考えないといけません。採算性を考える限り、楽しい開発を無限に続けるわけにはいかないと感じています。
この３者は、普通３人以上いる会社ではそれぞれ部署に分かれます。
これが、一人の中に居ます。ユーザーは欲しいよなぁ（顧客視点）、でもめんどいしなぁ（開発者視点）、でも採算が取れないのは嫌、でも工数がなぁ（管理者視点）、この葛藤の中で、やるか、手を引くか、常に取捨選択を迫られます。
ただ、Unity や Android では、コードを公開して下さっている先駆者の方が居ます。また、teratailなど、質問サイトにあげられた問答なども豊富にあります。コードがオンラインにあることのありがたみをこれ以上になく感じた瞬間でした。
ほとんどの人にとって、挫折は、方法が分からないために諦めざるを得ないところから来るように思います。コードを提供したことで感謝されるか、覚えてもらえるかは分かりませんが、オンラインにコードがあることは、開発者をよく助けていると思いました。
（以上）
※Google Play および Google Play ロゴは、Google LLC の商標です。
