引き継ぎの際に考えていたことをポエムをまとめましたので、後日投稿します。
退職エントリーにこう書いたけど投稿してなかったので投稿します。
このポエムの背景
このポエムは、前職でiOSエンジニアとしてアプリを作る際に考えていたことをまとめたものになります。 今後は考え方が変わっていくかもしれませんし、変わらないかもしれません。
そもそもこのポエムは、退職時に引き継ぎをしていた際、上司であったbash0C7さんに、引き継ぎに関するアドバイスをいただいたことから書き上げたものです。
アドバイスの内容はだいたいこんな感じでした 「今どういうプロジェクトが動いてるとか、どういうタスクが残ってるとか、オペレーションの手順をどうやるかとか伝えられても意味がない。完璧な引き継ぎドキュメントなんて作りようがないし、君の仕事をそのまま再現できるはずがない。君が今まで何を考えて仕事をしてきたのかを教えてくれ。想いは引き継げる」
想いが課題になり、 課題がプロジェクトになり、 プロジェクトがタスクになり、 タスクがオペレーションになる。
その最上位に位置する「想い」の部分です。
「何を考えてアプリを作ってきたか」概要
- ユーザビリティ、収益、開発者のモチベーションのバランスを取る
- 可能な限り機能を削る
- 数値だけを見ない
- 良いアプリを作るために良いチームを作る
- アプリに関することは全部やる
ユーザビリティ、収益、開発者のモチベーションのバランスを取る
「良いアプリとは何か」についてのshobyなりの答え。 良いアプリは、以下の3点を備えていると考えている。
- ユーザービリティが高い
- ビジネスとしてきちんと収益が得られている
- 開発者がモチベーション高く開発している
どれが欠けても良いアプリではなくなるが、 どれかを伸ばすためにはどれかを犠牲にする必要があり、 それぞれのバランスが大事だと考えている。
前職の退職前には大きく欠けていると考えられた収益面を伸ばすために、 アプリ内課金の実装に特に力をいれてきた。 良いアプリでも儲からないと開発を続けられない。
どれか欠けるとダメな例
- ユーザビリティが低いとそもそも使ってもらえない
- 収益が得られないと開発を続けられない
- 開発者のモチベーションが低いと改善されなくなる
どれかを伸ばすとどれかが犠牲になる例
- ユーザビリティを向上させるために全機能を解放したら有料会員が減る
- 収益を向上させるために広告を増やすとユーザビリティが下がり、開発者のモチベーションも下がる
- 開発者のモチベーションを上げるために作りたい機能だけを作り続けていても、ユーザビリティが下がる
可能な限り機能を削る
厳密に言うと大抵の場合削れないので隠してきた。 iOSのヒューマンインターフェースガイドラインにある1節を固く重んじている。 https://developer.apple.com/jp/devcenter/ios/library/documentation/MobileHIG.pdf
いわゆる「80-20ルール」によると、一般に、ユーザの大部分（少なくとも80%）は、アプリケーションのごく限られた数の機能しか使用しないのに対し、アプリケーションのすべての機能を使用するのはごく少数のユーザ（20%以下）です。iOSアプリケーションは、パワーユーザだけが必要とする機能のすべてを提供する必要はありません。
数値だけを見ない
ポリシーとして、数値は過去を確認するためのもので、未来を決めるためのものではないという考え方を持っている。数値が持つ説得力やパワーはすごいので、人の判断力を奪ってしまう。
よって、以下の用途だけに使おうと心に決めていた。
- 何か問題があった時に気付くため
- 変更を行った後の変化を確認するため
逆に以下には用いなかった。
- 開発を始める際の理由付け
- 具体的な数値目標
数値を理由や目標にして開発を始めることは、開発者のモチベーションを削ぐと考えているため、数値を理由や目標にする場合でも、チームに対しては可能な限り噛み砕いて、何故その数値を目指すのかを伝えるようにした。 ※例：「有料会員登録を○○人増やそう」→「アプリを収益化して、良いアプリを作り続けられるようにしよう」
良いアプリを作るために良いチームを作る
アプリを作るのは人であるため、良いアプリを作るには良いチームが必要だと考えていた。 良いチームとはメンバー同士が信頼感を持っており、モチベーションを持って開発を行っているチームだと考えている。
私自身、信頼感を構築するのは苦手な人間であるため、モチベーションの点に関しては気をつけた。具体的には、極力それぞれのメンバーがやりたいタスクを選べるようにする、 雑タスクをお願いする時際にはそのタスクの意味と効果を伝える、などを心がけていた。
また、採用活動においても、信頼感とモチベーションという二点は必ず考慮している。 具体的には、その人に信頼して仕事を任せられるか、モチベーションを持った開発を行っているかを見ている。
アプリに関することは全部やる
アプリのエンジニアは「これだけすごくできる」より「ぜんぶできる」方が大事だと考えている。今、アプリを1つ作ろうとしたら考えなければいけないことがすごく多い。
以下やるべきことの例
- UI設計
- アプリ
- API
- 課金やプッシュ通知のバックエンド
- プロモーション
Objective-CやJavaがすごく書ければそれで良いかというと、そうではない。 「UIは○○さんにお願いして、APIは○○さんにお願いして、課金は○○さんにお願いして、プロモーションは○○さんにお願いして…」 とやってしまっていた時期があるが、待ち時間が増えてすごくつらい状態だった。 アプリのエンジニアは、やろうと思ったら自分で手を動かせるようにならないといけない。 （もちろん、基本的にはそれぞれのスペシャリストに判断を仰ぎつつ進めるべき）
まとめ
私は前職の引き継ぎ時にには、以下のことを考えてアプリの開発を行っていた。
- ユーザビリティ、収益、開発者のモチベーションのバランスを取る
- 可能な限り機能を削る
- 数値だけを見ない
- 良いアプリを作るために良いチームを作る
- アプリに関することは全部やる
私のアプリに対する想いが引き継がれて、今でも少しは残っていれば良いなと思います。
