esaの記事をステータスバーから見れるMacアプリを作った話と、個人開発で心がけたい4つの事

この記事はトレタ Advent Calendar 2016 5日目の記事になります。昨日はサーバサイドエンジニアの@seri_k自分が2016年に作ったrails拡張系gemとその解説 - seri::diaryでした。

この記事に影響され「ワイも1日目に書いた記事の内容をgem化するぞ!」と息巻くもiPhoneの画面をバキバキに割って具合が悪くなり、未達のまま週末を終えました🌚


EsaMenuというアプリを作っていた

f:id:horimislime:20161205120756p:plain

ここ2ヶ月ほどちまちまとMacアプリを書いていて、ようやく普通に動く状態になってきたので公開しました。名前のまんまで、Macのステータスバーに常駐しesa.ioの新着記事を表示してくれるというものです。残念ながらMac AppStoreはまだ申請中で間に合わなかったんですが、以下からアプリケーションのzipを落とせます。

Release Release 0.1.0 · horimislime/EsaMenu

iOS開発をしているとMacアプリも簡単に作れそうに見えるんですが、AppKitは結構クセモノでなかなかツラい事もありました。またGUIアプリをストア配布まで持っていくには割とやることが多く骨が折れます。今回はそんなMacアプリを挫折せずリリースまで持っていくため心がけてよかった事について書きます。

手に馴染んでいる技術しか使わない

これを作り始めたのが9月末で、もうじきXcode8がリリースされSwift3が使えるタイミングでしたが、あえて使わずXcode7.3.1・Swift2.1構成で開発を始めました。言語仕様の変更以上に、多くのライブラリがSwift3対応と同時にメジャーアップデートを実施し、API仕様が変わっているケースが多かったからです(Alamofire4などまさにそれ)。AppKitを使う時点で慣れてないことをやっているのもあり、せめてここらへんは慣れたものを使わないと結構時間を使いそうだなと思い我慢しました。

自分の好きな技術や新しいもので開発できるのが個人開発の楽しいところです。けれど「アプリを作りたい」という願望と「新しい技術を試したい」という2つの願望を同時並行させると失敗しがちです。

なので使ったことのないライブラリはもちろん、小規模プロダクトで大げさなライブラリを入れるのもアレだと思い、GUI周りも素のAppKitで組み立てています(Rx系がないとツラいな・・という気持ちは正直あった。)

書いてるコードは面白みに欠けても、一度出してから何度でも作り直すチャンスはあります。最初はミニマムでスピードを優先する我慢も必要かなと思います。

デザインなど、できない事は「やらない」

gnu-and-penguin-color-300x276.jpg (300×276)

ソフトウェア - GNUプロジェクト - フリーソフトウェアファウンデーション

せっかく作ったものが誰かに使いたいと思ってもらえるよう、ついアイコンやUIもカッコ良くしたいと欲が出てしまうものです。しかし、デザイン知識に乏しいエンジニアがこだわったUIやアイコンを作ろうとすると地獄っぽいものができてしまいがちです(GNUロゴ、本職のデザイナーが作ったものか知らないんだけどもしそうだったら例に出してすいません)。

アプリアイコンがカッコいいと使ってみようかな!と思ってしまう事は確かにあります。けど逆に無理してヒドいアイコンだとパッと見でこのアプリなんかダメそう・・・と感じてしまい、内容も見ずに試す気が失せることがあります。素人が無理して作った感のあるデザインは、プラスどころかマイナス印象にしかならないと思ってます。

なのでデザインに関しては「何もしない」というスタンスを取ることにしました。UIに関してはSDK標準で用意されているものを使い、アイコンに関してはすごくシンプルかつ無難で、フリーでそのまま使えるものを利用するといった感じです。

幸いAppKitではUIKit以上に標準的なUIパーツが最初から揃っているので、アプリを作る上で凝ったカスタムViewを作る場面は少ないと思います。

f:id:horimislime:20161204191141p:plain

デザインにこだわっても使ってもらえるとは限りません。そんな部分に執着してプロダクトがリリースできなくなるくらいなら、そもそも凝らないと割り切る方がよっぽどマシに思えます。昔Yo.が一躍話題になりましたが、これなんて未だにアイコンが紫一色です。だけどダサいとかアイコンを見た瞬間に「このアプリはダメそう・・」なんて全く思わないし、むしろYoのシンプルさをよく表したアイコンとも思えます。こういう事例もあるし、無理ならデザインは無に近いものでも問題ないと思っています。 

必ず3ヶ月以内にリリースする

開発期間が長くなるほどプロダクトへの熱量は減り、モチベーション維持が難しくなります。個人的な感覚だと3ヶ月を超えるとやる気が無くなったり、似たものを他の誰かが出してきたり様々な理由でリリースを諦める確率が高くなる気がしています。

今回作ったEsaMenuは当初考えていた機能の半分も実装できません。そもそも最初はesaの新着記事を通知センターで受け取りたいというのがスタート地点だったので、主目的が果たせてません。しかしもうじき3ヶ月になってしまうこと、年をまたぐと大きくモチベーションが低下する危険性があるので機能をそぎ落として年内に出すことにしました。

機能がショボすぎると出す意味あるのか・・とも考えてしまいます。しかし一度使える状態にして出すとモチベーション再燃につながると思います。自分でドッグフーディングすれば気づくこともあるだろうし、ブログなどでアウトプットすれば何かしらフィードバックが得られるかもしれません。

毎日最低1分プロジェクトの事を考える

仕事が忙しかったりして、どうしても個人プロジェクトに手がつけられない時期があります。今回まさにそうだったんですが、この期間が長くなるにつれて空き時間ができた時に「よし、プロジェクトの続きやるぞ!」という気持ちが湧きづらくなってきます。

そこで毎日無理のない範囲でプロダクトのことを考えるようにしました。今年のApple Design Awardsを受賞したSTREAKSというiPhoneアプリを気に入って使っているんですが、これに毎日「プロダクトの事を最低1分考える」というタスクを作って消化するようにしていました。

習慣づけを手助けしてくれるタスクアプリStreaks | AppBase

どんなに忙しい日でも1分くらいは好きな事を考える時間は作れます。そして「1分だけ・・」と思って考え始めると、意外と10分、30分とのめり込んで考え続けられたりします。「今日は忙しすぎるから考える時間がない...」なんてのが単なる言い訳だということがよくわかります。

毎日たったの数分だけ○○をする、みたいな目標は馬鹿げているように見えるんですが、意識すると意外と一定の成果が出せる気がしていてオススメです。

まとめ

最近作っていたMacアプリを通して感じた、個人開発をする際心がけておきたい点について書きました。

技術にこだわりすぎたり挑戦的な事をやりすぎない事、ファーストリリースまでは短期勝負…って読み返してみると仕事でのセオリーと同じですね。また「短期間で動くものを作る」という事と「良いコードを書く」という二つの事を両立させることの難しさを改めて感じます。GitHubのコードを見返して、ホンマはこんなはずちゃうんや!と思う箇所が多々。

個人開発でイチからリリースまでのプロセスをやってみると、仕事での開発とも照らし合わせられる部分が多くて面白いです。


明日は@m_nakamura145で「herokuでデプロイと同時にrake db:migrateを実行する」です🙋