色々な事業フェーズに関わる中で、アプリエンジニアが関係者から何を求められていて、何をアウトプットすべきなのかが見えてきたのでまとめておきます。
前段
事業状況は0→1、1→10、10→100などの局面によって変化していくものです。
その事業の局面ごとに、アプリエンジニアが為すべきことや求められることというのは変化していくのではないかと私は思います。
もちろん、事業の形態や人員体制などによっても求められることやアウトプットは変わるものですが、そこはサブ要因として今回は踏み込まずに思うところを記載していこうと思います。
ちなみにこの記事は
https://qiita.com/yuukiw00w/items/1191c5afde8d3c9e4440
を書く中で、本人が何を気をつけたらいいかという観点だけじゃなく、周りが何を求めて何をアウトプットすべきかという部分も記載したほうがいいかなと思ったので書きました。
こちらの文章はどちらかといえば組織的にアサインする上で気をつけるべきことや、何を期待値とするべきかという部分に関わる話なので、人員体制を決定するような人が読むと参考になるかもしれません。
一方で前の記事はどちらかといえば本人や開発チームが読むことを想定しています。
0→1フェーズ
0→1フェーズは仮説検証を繰り返し行い、ビジネスが成立するコアサイクルを見つけ出すフェーズです。
この局面ではアプリに必要とされる機能やUXもどんどん変化するため、そもそもネイティブアプリとして作るべきかどうかも含めて検討すべきフェーズです。
可能であれば、NoCodeによるアプリ開発で簡素な仮説検証を繰り返して一定の方向性を見つけてからアプリ開発を開始すべきでしょう。
この段階で実際にアプリを開発する場合、仕様変更が頻発するとともに0→1に興味を持つ少数のエンジニアでどんどん開発を進めていく形になると思われます。
この局面では、アプリエンジニアは以下のようなスキル・動き・アウトプットを求められます。
0→1で求められるスキル・動き
- 専門外の調整・選定・サポートを行うジェネラリスト的な振る舞い
- 品質を妥協してでもスピード感のある開発
- 自身の知見に固辞せず情報収集と検証を元にした技術選定
0→1で求められるアウトプット
- PoCを通しての技術検証（実現可能性の調査とそのレポート）
- MVPに適した技術選定（市場調査の結果と選定の理由・結果のレポート）
- 最小限での品質での最速でのプロトタイプ提供
- 仮説検証作業のバックアップ（定性・定量調査とその可視化の実施）
0→1で求められることのまとめ
基本的には0→1フェーズでは人手が足りないことが多いため、場合によってはマーケティングツールの選定・開発やPoC/MVPによるコアバリュー形成までの開発プロセスの整備、要求を明確化してプロトタイプに落とし込む作業など専門とする開発以外の調整・選定やサポートを行う必要が出ることも多いでしょう。
ジェネラリスト的な振る舞いをしつつも、エンジニアとしてしっかりと技術面でバックアップすることが求められるフェーズだと思います。
1→10フェーズ
1→10フェーズはビジネスのコアバリューが形成され、売り上げを拡大していくフェーズです。
この局面ではコアの機能しかないアプリに色々な機能追加やUX改善が求められます。
また、0→1にこだわるエンジニアが抜けたりすることで人の入れ替えが激しくなってくる時期でもあります。
この局面では、アプリエンジニアは以下のようなスキル・動き・アウトプットを求められます。
1→10で求められるスキル・動き
- アプリエンジニアとしての専門性の発揮
1→10で求められるアウトプット
- HIG、Material Design、他アプリの知見を元にしたUXやアクセシビリティ観点での提言と実装
- 技術負債の解消計画策定と実施
- 開発目線で必要なドキュメンテーションの実施
1→10で求められることのまとめ
基本的にこのフェーズはKPIを追いかけてアプリの品質やUXを改善していくフェーズなので、アプリに詳しい人間としてUXの提言やテスト設計をするような形で専門性の発揮が求められることになるでしょう。
継続率やCVR向上のためレビュー対応などを行ったり、AppStoreでfeatureされるためにOS機能を使った開発をすることもあり、アプリエンジニアとしての知見を活かす機会が多いと思われます。
10→100フェーズ
10→100フェーズは事業が安定した状態に入り、運用に重きを置くフェーズです。
この局面ではユーザ数が一定存在することもあり、細かいUI/UXの改善や不具合修正、外部（他アプリや他企業のAPIなど）との連携といった開発がメインとなってきます。
この時期には人員が十分な数配置され、技術主導の開発が進んでいる組織も存在するでしょう。
この局面では、アプリエンジニアは以下のようなスキル・動き・アウトプットを求められます。
10→100で求められるスキル・動き
- 事業構造や組織体制に合わせた動き
- 高品質で障害を起こさないようにするための運用や安定的な開発体制の構築
10→100で求められるアウトプット
- 組織体制に応じた設計ルールの制定
- 運用自動化（特に配信やテスト、QA周りでの自動化）
- 安定的な開発の実施
10→100で求められることのまとめ
このフェーズは組織ごとに特徴が出てきて状況がバラバラになりがちなため、組織体制が安定していない場合には視座を高くして事業オーナーや開発組織全体のことを考える必要性が出てくることも多いでしょう。
組織がしっかりと体制作られていれば、決まった体制の中で専門性を発揮するだけの場合もあると思われます。
どちらの場合でも、ユーザ数が多くなってきたプロダクトでは障害・バグに対しての反応が強くなってくることもあり、開発スピードを保ったまま品質や安定性を高めていく動きが求められると思われます。
雑感
実際に新しくプロダクトを作る0→1フェーズでは、組織やビジネスの都合上から高品質を求められることなどもあります。
しかしそういった場合でも、可能な限り小さいものを素早く提供する形でスケジュールを組むなど、プロダクト開発全体に関わってサポートしたり調整したりという業務が必ず必要になると思います。
フェーズと事業上の制約を見ながら、期待値を制御し、より良いアウトプットができるように調整する業務は面倒なもので、不得意な人も多いかと思います。
しかし、そこを誰もやらないと苦労するのは開発メンバーになるため、誰かがやる必要はあると組織内で認識してもらうことが重要だと思います。
雑なまとめ
0→1だとジェネラリストでなんでも触ってみる・首突っ込んでみるタイプの人が向いてそう
1→10だとアプリエンジニアとして専門性発揮したい人が向いてそう
10→100だと体制考えたりみたいなマネージャー向きの人と作るものも体制も決まった中で開発したい人が向いてそう