[個人開発]超簡単に目標管理ができるアプリを作ったよ 〜夫婦での個人開発ってどんな感じなのか解説してみた〜
今年の1月に個人開発したアプリをリリースしました。
今回もわたしはデザイナーとして入っており、エンジニアの旦那さんとの夫婦での共同開発です。
そして、ついに3サービス目のリリースとなりました。
▼iOSはこちら
▼Androidはこちら
1サービス目の頃から現在に至るまで、夫婦での共同開発は、本当に多くのトラブルや課題がありました。
仕事上の同僚や上司とは違い、つい遠慮なく言ってしまうので、意見の食い違いや、ちょっとした物の言い方で喧嘩をすることは日常茶飯事です。
エンジニア・デザイナーお互いの領域でプロとしてのプライドもありますし、ビジネス目線での物事の捉え方や、プロダクト愛に関しても価値観が違ったりしますしね。
そんな中、開発体制だけでなく、話し合いの時の気遣いや心構えなども少しずつ改善しながら進めていったので、夫婦の個人開発ってどんな感じなの？というものを備忘録として残しておこうと思います。
あと先にお伝えしておきますが、個人開発においては、無理せず、ゆるく長く、そして楽しく開発を続けることが大切だと思っているので、これがベストプラクティスだ！とかっていうものでは全然ありません。
私たち夫婦の性格や生活スタイルを考慮して、結果としてこれがちょうど良いルールだよね、となったものを書き連ねているだけですので、これから先にもっと良い方法が見つかればどんどん変えて行く予定です。
1.どんなサービスを作ったの？
アプリ名は「My Life Plan（マイライフプラン）」で、簡単に言うと、自分の人生において掲げている目標を見える化するツールです。
よく新年に今年の自分の抱負とか決める方多いですよね。
そんな方達に、その掲げた目標に対する道筋をロードマップとして作ったり、数値を示して見える化することで、目標の達成を、より現実的なものとして遂行できるようになる手助けができれば良いなと考え、作ったのが本サービスです。
仕事ではKPIとか決めたり、評価面談などで自分の目標を管理して振り返ったりする人も多いかと思いますが、いざそれをプライベートできちんとやってるよ、という方って少ないんじゃないかな〜と考えています。
理由としては色々あるかと思いますが、一番の理由は
これに尽きると思います。
世の中にある継続支援ツールや、目標管理ツールって、かなり細々設定があって、目標は書き留めておきたいんだけど、そこまでの熱量じゃないんだけどなぁ…という感覚が私自身にありました。
もっと無理ない範囲で管理できて、且つ、ふと思った時に自分の立てた目標を振り返ることができるようなライトな目標管理サービスがあればいいのにな、と思うことが多く、そんなニーズが世の中にあるんじゃないかなと思ったことが、今回のコンセプトの1つです。
（他にも色々ありますが、それはまた次回記事にしようと思います。）
基本的な機能は至ってシンプルで、主な機能は以下の4つです。
目標を一覧で確認できる
達成までの期日を設定し、その残日数を確認できる
達成までのロードマップ(小目標）を立てることができる
目標をカテゴライズして分けて管理することができる
例えば、TOEIC750点取る、という目標を掲げた場合、期日は試験日を設定し、ロードマップに750点取るために必要なタスクを書いていきます。
また、毎月本を10冊読む、なんていった継続目標を掲げることもできます。
期日は一年後とか(無期限とかっていう設定も今後検討中)にし、ロードマップに毎月読む本をメモしておく、なんて使い方もできます。
今現在、ドックフーディングとして、このアプリで自分の目標を掲げて管理していますが、その時に「あー、こういう使い方するよね〜」みたいなものも、すでにいくつか湧いていますので、今後のアップデートもぜひお楽しみにしててくださいね^^
1.企画段階
まず、今回はAndroidとiOS両方でリリースをしたいという意図があったので、クロスプラットフォームのFlutterで開発しています。
初めてのFlutterであることから、学習コストをできるだけ下げてリリースまで持っていきたいという思いがありました。そのため、できるだけ標準コンポーネントで作れるUIを考えました。
ちなみに、個人開発において最も重要なことは、「まずは完成させること」だと個人的に思っています。
個人開発は、仕事と違って納期やマネタイズも意識しなくて良いので、やりたいことがそのまま実現できる反面、あれもこれもやりたいと壮大なサービスを考えがちです。
結果として、志半ばで、いつ完成するのかわからないサグラダファミリア状態になってしまうケースが個人開発あるあるだと思うので、スモールスタートを意識して開発するようにしています。
企画段階では、やりたい機能をブレスト形式でどんどん出し合い、その中から、「存在しないとサービスとして成立しない機能」を抽出します。
それ以外の機能は「あったら嬉しい機能」である、と言う判断をして、優先度を下げてリリース後の改修案件に回します。
「存在しないとサービスとして成立しない機能」が抽出できたら、そこから画面設計を考えていきます。
ちなみに、我が家の基本ルールとして、発案者がPMとして全体の工数管理をする、というルールを決めています。
今回は旦那さん企画なので、各画面単位のissueを旦那さんに立ててもらい、それに沿ってワイヤーを制作していきました。
制作したワイヤーを旦那さんにチェックしてもらい、OKであればデザインに落とし込みます。
初期のワイヤーはこんな感じ↓
Flutterの標準コンポーネントで実装する予定なので、基本的にはマテリアルデザインに則ってデザイン制作していきます。
デザインが完成したら、issueで指摘事項を挙げてもらい、修正・追加対応などします。
このあたりは厳格にやり過ぎると続かないので、お互いが分かれば良いよね、という程度の粒度のコメントを残しています。
2.デザインガイドラインについて
前述の通り、今回はFlutterの標準コンポーネントを使いたいので、基本的にはコンポーネントやインタラクションなどは、マテリアルデザインに則っています。
開発メンバーが複数人関わるのであれば、もっと厳格にする必要がありますが、今後増える予定もないですし、リリース前まではスモールスタートを意識する必要があるので、あまり工数かけないで作っています。
悩んだら、マテリアルデザインを参照し、特に理由がなければマテリアルデザインのものを採用します。
なので、基本的なカラーと最低限のコンポーネントだけ定義して、あとは機能改修毎にブラッシュアップして行く予定です(悪く言えば運用でカバーってやつですねw)
3.Githubの運用
ちょっとした共有事項なんかはslackでテキストを残したりもしていますが、基本的にはGithubでタスク管理をしています。
初めのうちは、githubのコメントに気づかないor忘れてしまうことも度々あったので（slack連携していても、メール通知しても忘れるもんは忘れるんですよね…）、その場合はslackにもコメントしています。
そして、読んだらスタンプを押す、というルールにしていて、スタンプが無ければ口頭でリマインドするようにしています。
ZenHubについて
さらに、リリース後の改善ではありますが、ZenHubという拡張機能を使ってカンバンでissueを管理する運用形式にしました。
各月のカンバンを用意し、リリース月ごとにissueを管理しています。
issueについて
また、issueにはテンプレートを用意し、「やりたいこと」「デザイン」「工数」の3つを記入するようにしています。
やりたいこと：issueの詳細をここに書きます。必要であればスクショ等使って説明したりします。
デザイン：モックを制作したらここに共有URLを貼ります。XDで制作しているので、素材のダウンロードもこのURLからやってもらいます。
工数：デザインと実装それぞれにかかる工数を、各自見積もって、ここに記入します。PMはそれを見て、いつのリリースに回すかを判断して、リリース月のカンバンに移動します。
Labelについて
Labelは基本的に以下の６つで、それぞれの用途は以下のような感じです。
bug：レイアウト崩れ、動作しないなど、意図しない現象の場合。
documentation：ドキュメントの追加や変更の場合。
enhancement：新機能またはリクエストがある場合。主にエンジニアサイドのタスクに使っています。
idea：アイデアベースの段階。まだ実装検討中のもので、形になってない状態のもの。
pending：工数や技術的な問題があり、実装を保留にしている場合。
UI：デザインモックが必要な場合。主にデザイナーサイドのタスクに使っています。
4.リリース後の運用について
リリースが完了すると運用フェーズに入ります。
運用フェーズでは、お互いPMとなっているサービスを月毎に交互にリリースします。
サービスは作っただけで満足するのではなく、改修してブラッシュアップしていくことが大切だという考えがお互いの根底にあるので、何かしら改修をし、月一リリースすることを目標としています。
各月ごとに、自分の担当のサービスの対応をするための工数がもらえるので、相手の工数をどう割り振るかを検討しながらリリースに向けた改修を進めていきます。
例えば、今月が私のサービスのリリース月であれば、今月は旦那さんの工数が使えます。
前月に私が作っておいたデザインを実装・リリースしてもらいます。
その間、私は翌月の旦那さんのサービスのデザイン制作を進めたり、次リリースに向けた自分のサービスの施策検討やデザイン制作をおこなっていきます。
なんだかテキストにするとすごくややこしいですね…。
つまりこんな感じです↓
ちなみにお互いサラリーマンのフルタイマーなので、稼働日は基本は土日祝のみです。リソースは限られているので、やりたいことの実現になかなか時間がかかるのがちょっともどかしいところではあります(><)
5.振り返りと反省
こんな感じで、ゆるくまったりやっていますが、まだまだ副業と呼べるようなものではなく、ただの娯楽にしかなっていないのが現状です。
ですが、開発すること自体は本業へのスキルアップにつながるし、本業でできないようなモダンな技術やトレンドのデザインを試せるといったメリットもあるので、個人開発はやって損はないと思います。
あと、特に思うのは、
相手をリスペクトすること
これが本当に大切です。
私は中途半端にコーディングとかフロントエンドをかじってしまっていて、実装を考慮するとこうかな？と、良かれと思って書いた一言が、エンジニアにとって逆にお節介だったり、カチンとされてしまったりすることがあり、めちゃくちゃ地雷を踏んでしまった経験もありますw
CSSで考えた場合、こういう組み方すれば出来るのに、アプリだと出来ないの？本当に？ねー、なんで？
みたいな詰め方は絶対にやっちゃダメです←これわたしです、ごめんなさいw
とはいえ、「わたしはデザイナーなので実装に関してはさっぱりです！そこはよしなに何とかしてください！」
みたいなスタンスでも当然イラッとされますのでご注意を。
まずは、どこまではエンジニアの領域で、どこまではデザイナーが責任もって判断をすべきかをきちんと理解する必要があります。
そういった面で、自分の領域であるはずのUIデザインなのに至らない点が多かったなと。もっともっと勉強する必要があるなと反省した点でもありました。
何か言葉一つ取っても、むしろ気を使い過ぎてるかなくらいの気持ちでやった方がちょうどいいです。
身内でやっているからこそ、相手への甘えの気持ちから、感情や態度が出やすくなってしまうので、カッとなった時は、もし相手が会社の人だったらどうやって返すかな？みたいなことを、ふと、冷静に考える癖をつける様にすると良いかもしれませんね。
私自身もまだ出来てないことが多いです。ですが、相手の協力もあるとは言え、以前より喧嘩も減ったので、少しずつ大人になれてるんじゃないかな…と思ってます（たぶん）
いつか、ガッポガッポと稼げるサービスを作りたいですし、夢のある趣味なので、今後もどんどん作っていきたいなと思っています。
この記事が気に入ったらサポートをしてみませんか？