個人でミスノート というアプリを開発してみて、会社の各部署に様々なメンバーやスキルがいることがサービス開発をする上でどれだけ重要なのかを実感したので、特にこれから社会人生活が始まる方々に向け、僕が考えたことをまとめてみようと思います。
前提
- 想定読者
- 社会人1, 2年目の新入社員（エンジニア）
- 特に一緒にサービスを作る他部署、他メンバーとのやりとりがうまくいかなくて悩んでいる方
- ミスノートについて
- ミスをメモして同じミスを繰り返さないようにするアプリ
- 仕事とは関係なく作った完全な趣味アプリ
- 2011年（僕が社会人２年目のとき）に初版を開発
- しばらく放置されたあと、2016年9月に最近のAndroidのお作法に従った作りにアップデート
- 詳しくはこちら（Playストア）
先にまとめ
結構長くなるので、先に結論だけ言ってしまいます。
- 組織に様々なメンバーがいることで、一人では実現できないクオリティのサービスが生み出せる
- 他部署のメンバーへの尊敬の念を持って仕事すると、やりとりがうまくいくはず
という感じです。
なぜこんなことを考えたのかを、アプリの開発開始からリリースまでを振り返りながら説明します。
アプリがリリースされるまでに試行錯誤したこと
1. 何を作るか考える （企画）
「アプリを作る」とは言っても、いきなりコーディングを始めることはできません。当たり前ですが、どんなアプリを作るのかを決める必要があります。
どんなアプリを作るのかを決める、というとアイデアを出せばそれで良いような気がするのですが、実際に考え始めてみるとそれほど簡単ではありません。
ミスノートの場合、まず「ミスノートというアプリを作ろう！内容は僕が新入社員だったころに書いていた失敗帳のイメージで、機能としては簡単な保存と参照ができればいいかな」と考えました。お勉強のためのアプリならここからもうコーディングを始めてしまえば良いのですが、ユーザーに使ってもらうことを考えると、いろいろな疑問が出てきます。
- 簡単な保存と参照だけなら普通のメモアプリでいいのではないか。
- 「ミスを書き留める」というアプリなんて他にもあるのではないか
- アプリに頼るほどミスに悩んでいる人なんているんだろうか
などなど。ただ考えたことを考えた通りに作っても、それを使ってくれる人がいるのかどうか、という不安が膨らんできます。
会社であれば、そこで企画やディレクションといった仕事をしているメンバーが、競合アプリの調査や一般的なメモアプリとの差別化ポイント、市場規模などの調査を、彼らのノウハウや経験を元にすることができるのですが、一人で開発するのであれば全て自分で、やり方も分からない中で試行錯誤するしかありません。
今回は、試行錯誤の結果なんとかひねり出されたのが「ミス / 改善の履歴を見られるようにすることで、成長を実感できるようにしよう！」だったのですが、正直これがユーザーにとってどれだけ価値のある内容なのかは全く不明なままリリースしています。
2. 実際に作ってみる（コーディング）
これは我々エンジニアがやっている部分ですね。
なのですが、一人で開発する、ということになるとここでも会社では気にしなかった悩みが出てくるようになります。
例えば、Androidアプリの開発ひとつをとってもDBの操作や見た目の作成、通信ライブラリの選定やCI環境の整備など、様々な視点や知識が必要になります。また、サーバーを使ったサービスにするのであれば、サーバーをどう調達するのか、24時間動き続けるための監視方法をどうするのか、セキュリティは大丈夫か、といったインフラ的な知識や試行錯誤も必要になります。
このあたりは、会社では「自分はやったことないけど他の専門家がよろしくやってくれている」というところで、それがチーム全体の効率を高める工夫のひとつになっていますが、一度一人でその全てをやってみると、「よろしくやってくれる」がどれだけの試行錯誤と労力の上に成り立っているのかを実感します。
3. 実際に作ってみる（デザイン）
エンジニアが一人で何かを作ろうと思った時にまず問題になるのがデザインかと思います。
なんとなく動くものを作ることはできても、レイアウトがどうも不揃いだったり、アイコンもパワポで作るくらいしかできない、となると、アプリケーション全体の完成度も悪く見えてしまいます。
ミスノートも、最初は本当にTextViewだけでなんとか頑張る、といういかにもエンジニアが趣味で作りました、という雰囲気のアプリでした。
最近はノンデザイナーズ・デザインブックを読んでデザインの基本を知ったり、Inkscapeの使い方を少し勉強して丸や四角を組み合わせた簡単なアイコンなら作れるようになったので、今回のバージョンアップ版には少しアイコンを入れていますが、それでもやはり限界があるので、会社でデザイナーに頼めばプロの知識と技術でとても完成度の高いものを作ってくれる、という状況はとても恵まれたものだと実感しています。
また、簡単なアイコンでも実際に自分で作ってみることで、アイコン作成ひとつをとってもアプリに表示したときに見やすく、ちゃんと機能が伝わり、さらにはサービスの全体的な雰囲気と合っているもの、といったことを考えているととても試行錯誤が必要であることがなんとなく想像できてきます。
このあたりは、もし会社や身近にデザイナーの方がいるのであれば、雑談で聞いてみるとどんなことを考え、悩みながらデザインしているのかを知ることができて面白いかもしれません。
Eテレでやってる「デザインあ」という番組もオススメです。
ちなみに、結局僕が頑張ってデザインしたアプリがどんなものになったのかは、ぜひアプリをダウンロードして使ってみてください（宣伝）
4. デバッグする（検証）
作る側として、最も苦手な作業がデバッグ作業です。
そもそも一般的に、作った本人のデバッグ作業では精度に限界があるというのはよく言われているので、一人で開発してリリースしようと思った際にここが大きな壁になるのは間違いありません。
会社であれば検証専門の人たちがいて、長年のノウハウと人手、端末数で様々な観点からの検証ができるのですが、一人でやっているノウハウもなく、端末も手元の１、２台とエミュレーターくらいしかなく、人もいない、というツラい状況に陥ってしまいます。
EspressoやUI Automatorなど、UIも含めた自動テストの技術は取り入れやすくなってはきているものの、それでも人が触っての品質のテストには多くの時間や視点、人が必要になります。そのようなことを考えると、個人で開発するサービスの品質を上げることの難しさを知ったと同時に、会社の検証担当がいかに重要な立場なのかが理解できました。
5. ユーザーにサービスの魅力を伝える（広報）
さて、作ってあとはマーケットへ公開するだけだ、となったとき、次にぶつかるの課題が宣伝文言の問題です。
例えばマーケットの掲載情報にはアプリ名から始まり、100文字程度の簡単な説明、さらには詳細な説明文言を入力し、ユーザーにそのアプリを説明する必要があります。
作った本人であれば知っているアプリの使い方や魅力も、ユーザーにとってはどこの馬の骨かもウィルスかもわからない身元不明のアプリです。
そのような状態からユーザーに「ダウンロードしよう」と思ってもらうためには、「なぜそのアプリを使うと良いのか」をしっかりと伝える必要があります。しっかり伝えるのですが、文章が長いと逆に読まれないまま「よくわからないアプリ」として無視されてしまいます。
作文は完全に文系なスキルで、我々エンジニアには難しい部分だったりするのですが、会社では企画の方や広報の方がちゃんと一言一言精査した文章を作文してくれて、我々はそれをコピペでマーケットの入力欄に反映させればよいだけだったりします。
このあたりの作業をやっていると、サービス開発とは単純にシステム的な、開発的なスキルさえあればできることではないと思い知るようになります。よく「エンジニアだけでやってます」というのがいかにも楽しく、自由にやれるように響くことがありますが、実際にユーザーに使ってもらえるるサービスを作ろうと思ったらエンジニアだけではとても難しい部分がたくさんあることを考えさせられます。
6. ユーザーからの声に応える（カスタマーサポート）
アプリを公開してダウンロードがされるようになってくると、ストアのレビューが投稿されるようになり、時にはメールで問い合わせやご意見が届くことがあります。
このような声が届くことは「使ってくれているんだ」という嬉しさ反面、どう反応したら良いのか悩んでしまって次の開発の時間が減ってしまう、という悩ましさにつながります。
カスタマーサポートチームがあれば、彼らのノウハウで受け答えがスムーズにできるのかもしれませんが、こちらはやはり普段機械と対話しているエンジニア、ということで、そもそも声が届いた時点で緊張してしまい、なんと答えれば良いのかわからなくなってしまいます。もし受け答えを間違えたら怒らせてしまうのではないか、とか、アプリが嫌われてしまうのではないか、といったことを考え出すと、返答するまで１日かかってしまったりすることも珍しくありません。で、その１日があればあれが作れたのになー。。。なんてことを考え、さらにカスタマーサポートが苦手になってしまう、そんな負のスパイラルが生まれます。
エンジニアでない方々がユーザーからの声を受け、それを開発者の身内として噛み砕いて伝えてくれるという状況は、開発効率アップのためにとても重要な環境であることに気付かされます。
最後にまとめ
最初に書いたとおり、普段当たり前のように部署があって、当たり前のように作業の依頼をしたり依頼がうまくいかなかったりしていると、部署間や人と人とのコミュニケーションが開発をする上での障壁のように感じられてしまう瞬間があったりするのですが、実際に一人ですべてのことを体験してみると、それぞれの部署のメンバーがそれぞれの課題や悩みを抱えながら、それを顔に表すことなく頑張っていることに気付かされます。
そのようなメンバーに対し、頼めばやってくれるのが当たり前ではなく、いてくれて協力してくれること自体に感謝するようになると、自然と仕事でも「どうやったら気持ち良く、スムーズにプロジェクトを進められるか」という考えのもとにやりとりできるようになるのではないかと思います。
「自分の仕事だけしてれば良い」「自分はちゃんとやってるのになんであっちはやってくれないんだ」と考えてしまうようなことがあれば、一度自分で簡単なアプリでも作ってリリースしてみると、一緒に仕事をしている他のメンバーの気持ちや悩みポイントをなんとなく知ることができ、仕事上のコミュニケーションも少し楽になるかと思いますので、オススメです。