読者です 読者をやめる 読者になる 読者になる

sakaharaのブログ

アプリ開発に関する話や日々の出来事など

6年前に個人で出した有料アプリ(売上85万)を4年ぶりにアップデートした話

iOS アプリ

マプログという地図にメモが書けるというコンセプトで個人で作ったiOSアプリです。

売上の数字自体は2011/1/7にリリースしてからこれまでの合計で約85万円(ここから30%をAppleに引かれる)となります。 リリースから2年後には本業が忙しいのとDL数の伸び悩みからアップデートをやめてしまいました。ですので直近1年間だとほとんど売上もないまま放置状態です。 開発時期は2010年の秋くらいからおそらく1.5ヶ月くらいの工数かけて本業の傍ら夜な夜な黙々と開発してました。

このアプリ、2011年頃と今を比べると全然アプリ数が少ない時代だったこともあって、AppBankをはじめとする有名なアプリレビューサイトなどにもいくつか掲載していただいたり、

www.appbank.net

Mac Fanという雑誌で紹介してもらったりしました。

www.fujisan.co.jp

さらに私が個人で作ったアプリで唯一AppStoreでフィーチャーされたアプリでもあり、突然Appleの担当者の方から連絡があって、よく分からないまま急いでバナーを作って提出したことを思い出します。 今となっては当たり前ですが、このあたりのことがダウロード数にかなり影響しています。

と前置きが長くなってますが、この塩漬けにしていたアプリをアップデートするきっかけが去年ありました。

元々このアプリのヘビーユーザーだった方が、今後もアプリがちゃんと動くようにアップデートを続けてほしいということで、わざわざ開発者である私のfacebookアカウントを発見して、直接メッセージをいただいたんです。

そのあと直接電話でお話しして、この行動力とアプリに対する情熱を感じて、そこまで言っていただけるならとアップデートをすることに決めました。

リクエストとしては「操作性は今のままでいいから、今後もずっと動くようにしてもらえれば十分です」ということだったので、ボタンの配置を含め操作性はほぼ以前のままです。 ただiOS 7からのUI周りの大掛かりな変更や5.5インチ、4.7インチのディスプレイに対応するため、アイコンやデザインを一部見直して、UI周りはかなりすっきりさせてます。 それに以前のバージョンと比べると細いところでかなり改善がしているので、以前インストールとして使ったことがある方がいらっしゃれば是非比較してもらいたいです。

去年の暮れから年始の休みにかけて数日間ひたすらコードを書きましたが、楽しくて仕方なかったですよw

サポートするiOSのバージョンが4.3からだったり、ARCではなく手動でメモリの管理をしないといけないMRCのままだったりと、自分で作ったくせに驚くことばかりでしたが、古き良きObjective-Cでコードを書きながらSwiftもいいけど、やっぱObjective-Cがよくね!?と独り言を言い始める始末でした…。 とりあえずiOS 8以降のサポートに制限して、Auto Layoutを使うことで大きいディスプレイにも対応して無事アップデートを終えました。 それに大量に出てくる警告をやっつけていくのも地味にいいもんです。

やはり好きなもの、やりたいものを作るときはモチベーションが違うよなーと思います。 仕事へのフィードバックとしてもよさそうなので、冷め切っていた個人開発へのモチベーションも今年は高めていこうと新ためて新年に誓いました。 ということで今更ですが、本年もどうぞ宜しくお願い致します。

妻が一人で開発したアプリの売上が順調に伸びていてうらやましい

iOS アプリ

半年以上前のことですが、今年の3/25にMilk TimeというiOSアプリを妻がリリースしました。

妻自身が子育て中に授乳のことなどで苦労した経験を活かし、授乳記録を簡単にできてもっとデザインのよいアプリを作りたいという思いをそのまま形にしています。

妻は元々エンジニアではありましたが、アプリを開発して自分でリリースするというのは初めてでした。 それにも関わらずアプリを作る決心をして、新品の15インチMacBook Proを購入しました。 そこから子育てをしつつ合間を見ては1人で企画、設計、デザイン、開発までを1人で行いました。 ちゃんと計算したわけではないですが、トータルでかかった工数は2,3ヶ月くらいではないかと思います。

私自身が個人でいくつかアプリを開発してリリースしてそれなりの売上を上げていたこともあり、冗談ぽくアプリ作って出したら、儲かるよなんて言ってたらホントにやっちゃったという中々の行動力ですw

妻は元々エンジニアでプログラミング経験は十分あったとはいえ、デザイン含め、アイコンまで自分で作ってやっている姿を見て、さすがに関心しました。 そしてもちろんObjective-Cに触れるのも初めてでした。

肝心のどうやって売上を得ているかという話にも少し触れておきます。 このアプリは画面は開いた状態にしたままの授乳中のタイマー機能がメインなので、広告モデルとの相性はよいだろうと考え、アプリ自体は無料にしています。 その上で実際にリリースしてみて分かったことは特に授乳中に画面を見てアプリ内の広告をクリックしてくださるユーザーの比率が想定以上の数字でした。 ダウンロード数こそ5,200程度ですが、現在では広告収入は月数万となりました。 ターゲットがほぼ20-30代で子持ち主婦の方に絞られるので、広告もピンポイントでニーズあったものが表示できる強みもあり、ダウンロード数とは関係なく、広告収入が伸びているようです。

あえていくら売上があったかは明言しませんが、開発に使った15インチMacBook Proの代金は半年待たずして回収できた上に、更に広告収入は伸びています。

主婦が初めて作ったアプリとしては出来過ぎな成果だと思いますw

現在は本格的に仕事復帰して本業のエンジニアの仕事をしながら、隙間の時間でAndroid版の開発も進めていて、来年の早い段階でリリースする予定です。 でももうこちらを本業にしてもいいタイミングかもしれませんw

今回のことは主婦の方がパートで働いたりするよりも、働く時間は自由な上、更にビジネスチャンスを含めいろんな可能性を感じさせてくれる出来事でした。 プログラミングができることでこんなにも可能性が広がるってことを自分の妻が教えてくれるとは夢にも思いませんでしたが。

もしアイデアはあるけど、自分ではできないかもという主婦が方がいらしたら、是非チャレンジしてほしいなと思います。

ということですでにリリース済みのiOS版共々よろしくお願いします! 是非ダウンロードしてみてください!

島根にIT企業が集まるたった一つの理由

島根

島根といえばRubyの開発者・まつもとゆきひろ氏が住んでいることもあり、Rubyの聖地としてエンジニアにとっては有名な場所だと思います。 また県を挙げてIT企業を誘致していることもあり、島根に事業所を開設する企業も増えてきています。

Rubyのコミュニティの活動などやその支援はもちろん企業誘致に貢献していると思いますが、実は圧倒的に貢献しているのはこちらなんです。(たぶんね)

http://www.shimane-style.com/ss_shien/yugu/

↑のリンクを見れば一目瞭然だと思いますが、かなり太っ腹な立地起業の優遇制度です。

http://www.shimane-style.com/ss_shien/simulation/

例えば上記のシミュレーションだと例えば「8年間の家賃が0円」で家賃に対する補助だけで1,920万にもなります。 従業員の雇用についても一人あたり130万の補助と相当な額です。

その他にも松江市では実用化製品化支援事業といった補助金もあり、補助対象経費の半額を最大500万円まで援助してくれるような制度もあります。

http://www1.city.matsue.shimane.jp/jigyousha/sangyou/kigyou/sin-kaihatu.html

これらの優遇制度を知ってる方ってどのくらいいるんでしょうか? 私は島根で働くようになる以前は全然知りませんでした。

もちろん優遇制度についての予算は決まっているので上限はありますが、その上限内でかつ条件を満たしている限り補助は受けれます。 ということなので起業したい方や、他地域への事業所の開設を検討しているIT企業の皆様は是非島根に来ることをオススメします。 ちなみにここで紹介したからといって私には1円も入りません・・・w

私が働いている会社もこの優遇制度の恩恵を受けている立場なので、いずれ何倍、何十倍にもして県や市に還元したいと思ってます。(じゃないと申し訳ないです)

また松江市では毎年ビジネスプランコンテストを開催しており、最優秀賞は20万の賞金がもらえます。(起業支援できるくらい賞金がよくなるともっといいな〜)

http://www.shimane-oss.org/biz-contest2016/

今回は2016年1月7日まで応募できるようなので、我こそはと思う方は応募してみましょう。 私もしれ〜っと応募しようかと企んでおりまして、年末年始はネタ探しに没頭する予定です。

では私のように応募する方もしない方も、よいお年をお迎え下さい〜。

「リモートチームでうまくいく」はリモートワークだけでなく新しい働き方を提案してくれる良本

書評

リモートチームでうまくいく マネジメントの?常識?を変える新しいワークスタイル

リモートチームでうまくいく マネジメントの?常識?を変える新しいワークスタイル

この書籍には以前ブログで書いた「リモートワークのデメリット」を埋めるための試みがたくさん盛り込まれていたので、いくつかピックアップしてみました。

sakahara.hatenablog.jp

会社や同僚の協力がないとリモートワークをしている人が孤立しやすい

  • リモートワークのメンバーを特別扱いしない
  • 最初から社内の全員がリモートワークであるという前提で仕事をする
  • 雑談を推奨する

部下が見張っていないと仕事をしないのではという考えが根本にあると成立しない

  • 採用において「セルフマネージメント」ができる人かどうかを重視する(そのためにも採用は慎重に)
  • 新人にいきなりリモートワークはさせず、まずは一緒に働いてもらって教育しながら「セルフマネージメント」をできるようになってもらう

働かなくなる人よりもむしろ働き過ぎになる人が多い

  • 上記と同様に「セルフマネージメント」をできるようになってもらう

文章力が無い人がやるのは難しい

  • これは本人の努力が必要w

同僚との会話が減る分、仕事の成果に注目が集まるので成果を出せる人でないと難しい

(仕事の成果で判断されるのはむしろよいこととも言えるのでデメリットでもなかったけど)

  • 雑談を推奨することで目の前で仕事をしているのと変わらない状態を作る
  • 存在感を出すために積極的に本人が発信しやすい環境にする

上記で何度か登場した「セルフマネージメント」の定義はこんな感じです。

自分の時間やリソースを自身で把握した上で、どんな仕事にどれだけのコストをかけるかを考えて、誰かに指示 ・管理されることなく成果を発揮することのできるスキル

リモートワークにおいて一番重要なのはやはりこのセルフマネージメントなんだと実感しました。 自分で自分を管理できない人にリモートワークはまず無理でしょうから、 極力セルフマネージメントができる人を採用するか、もしくは育てることが必要と言えます。

また社内の全員がリモートワークであるという前提で仕事をするために全員がビデオチャットで会話するなどの方針にすることは、やはり経営者がトップダウンで進めた方が効率的だったりすると思うので、このあたりは会社によってはかなり難しいかもしれません。

この本はリモートワークという仕事のやり方についてだけ書いたものではなく、マネージメントや会社の文化をいかに作っていくか?ということに関しての側面の方が強いので、そういった部分に興味がある方が読むともっと違った知見が得られると思います。

最後に本書にて特に印象に残った箇所を記載しておきます

  • リモートワークは信頼を前提とする
  • 雑談はリモートチームに助け合いの風土を作ることができるのであえて推奨する
  • オフィスにいる人とリモートにいる人との間に情報格差があるとチームの一体感はうすれてしまう
  • 社員をマネジメントするために閲覧できる情報を制限しているとしたら、社員の主体性を奪っていた原因だと考えられる
  • ガチガチに管理するよりも自由な裁量で働いてもらった方が生産性は高くなる傾向がある
  • セルフマネージメントができる人材が集まったチームは生産性が高くかり、結果としてリモートチームでもやっていける

上記のことはリモートワークに限らず仕事をしていく上で重要なことだと言えるので、常に意識していきたいことだと思いました。

「リーダブルコード」は英語で原書を読んで見る方がおもしろい

書評

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

この本、実はずっと読まずにスルーしてたんですが、 先週社内でちょっと話題になっていたので、いいかげん同僚から借りてようやく読みました。 内容はまあいろんな人が書評書いてるので、あえて言うほどでもないですが ある程度の経験、またはスキルのあるプログラマーであれば知識としてはそんなに新しい発見があるものではないかなぁという感じです。

ですが本書の本当のいいところは翻訳にも関わらず、 原書の内容を損なうことなく日本語で非常に分かりやすく、面白さを損なうこと無く反映してくれていることです。 訳書のほうは数時間で読めてしまったんですが、コメントの書き方の部分など英語で書く時はどうだろう?と 気になってしまい、結局原書をKindleで買っちゃいました。

The Art of Readable Code (Theory in Practice)

The Art of Readable Code (Theory in Practice)

原書の方を読みつつ、ここは日本語ではどう書いてあるだろうと訳書を確認しながら読み進めるとより理解が深まるし、何より楽しめました。 特に挿絵の部分は原書を読んでも、訳書を読んでも面白いので比較してみてほしいです。 このあたりは英語が苦手な人でも比較することでなるほど!とうなずける部分は多いと思います。

お金に余裕がある人は訳書だけでなく原書もセットで買うのがオススメです。 (私のように訳書は誰かに借りて原書を自分で買うのもありです)

最後にこの書籍を読んで感じたことですが、 変更しやすいコードを書くことを徹底できるかどうかというのは、自分が理解して実践できるだけでは不十分で 一緒に仕事をするメンバー、もっと大きい範囲で見ると会社全体でそういうことを大事にする文化が無いと 中々成立させにくい部分があります。 動けばいいで作りはしたが、後になって破綻するって話はいくらでもあります。 そういう部分を妥協せずにどこまで徹底できるかがやはり、こういった書籍のノウハウを生かせるかどうかだと思います。

現場によっては人が書いたコードに訂正を加えてもっといい方法を提案したり、コードレビューをしたりすること自体に違和感を感じるメンバーがいるかもしれないけど。 ただそれはよりいいものを作りたいがためにやるのであって、指摘を受けたメンバーに問題があるなどという話ではないということを、切り分けて考えてもらえるように会話していけば大丈夫なはずです…きっと。

それにしてもこれまで買っても読めてない本が溜まり続けてたけど、ここ数ヶ月本を読める時間が増えて本当ありがたいなー。 (これも島根効果だろうか???)

書籍「納品をなくせばうまくいく」を読んでより良い開発手法について考えてみた

書評

この書籍自体は昨年出版された当時に一度読んだのですが、最近は受託の仕事が多く今後に活かすために改めて読み直しました。

「納品」をなくせばうまくいく ソフトウェア業界の“常識

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

ちなみに納品のない受託開発と勘違いしそうになりますが、人材派遣とは違い、顧客企業のオフィスで働いたり、時間単価での契約ではなく、顧客の得る成果と満足度による契約をするという前提にしています。

今回この書籍を読み直すことで新たな発見があったので理解を深めるため整理してみました。

従来通りの納品する受託開発のデメリット

  • 要件定義で事前に全てを決めることは難しい(要件定義後に様々な事情で要件が変わることは多々ある)
  • 人月の問題 - 工数の精度にもよるが、下手をするとだめなエンジニアほど時間がかかって儲かるという変な仕組みがうまれる
  • 開発と運用で業者や担当者が別になることで、ドキュメントが欠かせなくなり価格がその分上がる
  • 上記のように開発と運用で別の人間が担当すると自分達が開発したわけではないため、リスク回避のため少しの修正でも高く見積もってしまう
  • 最大時を想定したハードウェアの購入になってしまい、あとからの変更が難しい

とデメリットをいくつか挙げましたが仕様変更が難しかったり、価格が高くなりがちだったりと問題は多々あります。 また構造的に発注した顧客にとってはビジネスの成功が目的だとしても、開発会社にとっては完成したソフトウェアに自体に価値があると勘違いしやすくなるため、気をつけないといけないと思います。

納品のない受託開発のメリット

  • 月額定額の料金体系にできる
  • 要件定義をしなくてよい - 最小限の機能を決めて、なるべく早い段階でユーザーへ提供できる
  • どれだけ仕様変更してもよい
  • 例えば打ち合わせは全てリモートで行うことで、無駄な経費を削減できる
  • 仕様決めから、開発、テストまで1人のエンジニアが担当することで、ドキュメント等の作成を簡略化できコスト削減につながる。

他にもメリットはありそうですが、次にデメリットをあげてみます。

納品のない受託開発のデメリット

  • エンジニアに幅広いスキルが必要
  • そもそも大規模で要件定義がしっかりできている案件には向かない
  • 顧客との信頼関係が構築できないと難しい

ここにあげたものはデメリットというより、エンジニアに交渉のスキルやフロンドエンド、バックエンド含め広い範囲の技術が必要になるということが、実現するためのハードルの高さになっているかもしれません。

まとめ

本来クリエイティブなはずのプログラミングという仕事が日本、特にSI事業に関しては最下層に位置づけられるような残念な会社がたくあります。 ですが著者が考えるコンセプトはプログラマーを非常に大事にしており、どうすればお客さんと実際に仕事するプログラマーがお互いに幸せになれるかということを突き詰めた結果がこの書籍の内容になっているのだと思います。 私もプログラミングを生業として10年以上生きてきた身としては、現状の環境を少しでも改善するためのヒントがたくさん詰まっている本で、大変参考になりました。

プログラマー以外の人がこの本を読むことで、より良い成果を上げるための議論ができるきっかけになればよいと思いました。

生活を犠牲にしてやる仕事に疲れたら書籍「ナリワイをつくる」を読んでみるとよい

書評

会社の同僚がたまたま持っているのを借りたらおもしろかったので紹介します。

ナリワイをつくる:人生を盗まれない働き方

ナリワイをつくる:人生を盗まれない働き方

ところでナリワイの定義は

個人レベルではじめられて、自分の時間と健康をマネーと交換するのではなく、やればやるほど頭が鍛えられ、技が身につく仕事を「ナリワイ」と呼ぶ。

と一番最初に定義されています。 会社に就職して毎日通勤しながら同じ仕事のするのでなく、ナリワイをいくつかすることで生計を立てること、そしてそれをどのように実現するかを提案する内容になっています。

ちなみにこのナリワイをベースとした生き方と対極にいる人の例として冒頭に

グローバル社会で全世界を相手にした殴り合いの競争をして健康が維持できるのは、かなりのバトルタイプ(戦闘型)だけだ。

とあります。 こんな生き方ができるのはどちらかというと少数の人だけだろうけど、このバトルタイプとは違う、いくつかのナリワイをもって生きるのも決して簡単ではないなぁというのが正直な印象です。 自分から自発的に動いてその行為によってお金をもらうという事を、雇用された立場で与えられた仕事をすることに慣れてしまった人にすぐにできるか?と思ってしまいます。 ただ個人的にはバトルタイプとして生きるのもいいと思いますが、「ナリワイ」を作って生きる方がより面白そうな感じがするので、すんなり読めました。

本書の中で印象に残った部分をいくつか紹介します。

クライアントワークの限界

クライアントの依頼を受けて作業をして納品して報酬をもらうだけの仕事はナリワイとは違うという話が出てきます。 仕事をしたらお金が一時的にもらえてそれで終わりってことなんですが、このやり方だと限界もあるし、今の自分の環境に踏まえて考えさせられました。

固定費を減らす

家賃などの固定費は給料の何割かを占める人が多く、結局それは1年の労働の何割かは家賃のために働く状況に陥っていることになります。 支払いのために簡単に仕事を辞めることもできないので、週末も仕事で疲れきってしまうと何かを始めようにも気軽にスタートできず悪循環です。 私も島根に引っ越してから家賃がこれまでよりも下がったことで、妙な安堵感がありました。 ですので家賃などの固定費を下げる努力は自ずと必要かと思います。

プロがやると逆につまらなくなる

ミスが許されなかったり、要望を聞きながら効率よく回していくために変化に富んだ内容にできなかったりとマイナス面もあるとのこと。 これは効率化を進めていけばいくほど、短時間により正確にアウトプットを出せるけど、それしかやらないと新しいものを生み出せなくなるジレンマみたいなものかなという印象です。 普通に仕事をしていく上でもこの視点を持つのは大事でしょう。

形式重視の価値観への疑問

実際の中身ではなく、形式だったりミスがない方が評価されるという偏った価値観が一般化してるけどそれでいいの?という部分については妙に納得できました。 これはあくまで一つの価値観に過ぎないということです。無理にそれに合わせる必要はないし、「お金をもらうからには」こうじゃないといけないとかああじゃないといけないとか考えすぎにさっさと行動してその対価をちゃんともらえるようにすればよいと思います。

本書を通じて一番大事だと思ったこと

下記の内容が自分の中では一番印象的でした。

だがそもそも仕事の起源を考えてみれば、皆がやるのが面倒なことを誰かがやってくれたら有難いな、ということをやる気がある人が担当してきた、ということだ。

結局のところこの書籍に書いてあるような生き方を実現するのに必要なのは、スキルうんぬんよりも誰かのために貢献したいという気持ちをもって率先して取り組むことがもっとも大事なのかなと思います。 この視点が抜けていると名誉だとかお金のことしか見えなくなって、やる前から失敗しそうですw

逆にこの視点をちゃんと持ってる人ならば、後は行動あるのみでこの書籍に書いてある生き方に近いことはできそうに感じました。

世界に通用する高いレベルで仕事をするとか、自分自身を宣伝して稼げる仕事をするなどそういう生き方もいいけど、もっと違う行き方もあるってことを知りたい人に是非読んでほしいです。