edited by Taiyo Kojima ( nanapi Inc., )
突然ですが、気がついたら「ただ言われたとおりにつくる」「タスクを消化するだけ」そんなエンジニアになっていませんか?
今回は、エンジニアとしてチームにJOINするとき、私が気をつけていることを中心に紹介したいと思います。「より良いプロダクト」「より良いチーム」をつくるきっかけなどになれば幸いです。
目次
1. エンジニア視点を重要視するべき?
2. PDCAサイクルのときに注意していることとは?
3. テスト・自動化を目的にしていないか?
1. エンジニア視点を重用視するべき?
・システム化することが仕事ではない
「頑張って実装したものが消される」「細かな仕様変更対応ばかりに追われる」などの経験はありませんか?
グロースハックには「オズの魔法使い」というMVPの種類があります。
(参考: グロースハックの大前提 「MVP」の種類と実例 5選 )
簡単に言えば、「全てをシステム化するのではなくある程度マニュアルで運用できるようにしておく」というものです。
これにより、「システム化」の工数がかからないうえに開発初期の「設計の変更の多さ」にもある程度柔軟に対応することができます。
特にiOSアプリになると「変更」には莫大な時間がかかってしまいますので柔軟に行きたい箇所があれば、始めはマニュアル化しておくことをオススメします。
例えば、nanapiのアンサーでは、通報による「悪質ユーザー認定」の処理を完全なマニュアルで運用していました。「どんな通報がくるのか」「どんな悪質ユーザーがいるのか」「どのように対処すべきか」などを見極めるためです。
システム化せずに柔軟に対応することで「アンサーの世界観構築」を慎重に素早く対応することができました。もちろん今ではほとんどがシステム化されています。
・パフォーマンス最大化のために
近年スマートフォンはどんどんハイスペック化していますが、そうは言っても潤沢なリソースがあるわけではありませんよね?
特に1%の改善を積み重ねていくことが重要視されるグロースハックなどでは、マシンスペックを有効活用してパフォーマンスを最大化することもエンジニアのやるべき重要なことであると言えると思います。
例えば、「カッコイイから透過画像を多用したデザイン」「画像alpha値アニメーション」などはやりがちだと思いますが、「本当にユーザーに必要なデザイン」なのかを改めてデザイナーと一緒に考える必要があるかもしれません。
機能にしてもデザインにしても「なんでもできる」という認識ではなく、「どのように表現するか」「どのように実現するか」を考えなくてはいけません。もちろん「本当に必要でないものは表現しない」という選択も時には必要になります。
・できることは沢山あるはず・・・?
エンジニア視点を貫く重要性を説明してみました。
自分が一番貢献できる部分をしっかり理解して行動することで、プロダクトやチームのパフォーマンスは最大化されると思いますし、他のメンバーにもそこを期待されるべきだと思います。
どんどん指摘して最善策を模索していきたいですね。
2. PDCAサイクルのときに注意していることとは?
・チームメンバーと一体となること
エンジニアには多い現象だと思うのですが、PDCAサイクルを継続し続けていると「機械的」になってしまうこともあるかと思います。私もつくることに夢中になりすぎると機械的になりがちなので注意している点です。
LeanUXの基本でもありますが、チームパフォーマンスの最大化も重要な要素です。エンジニアが「機械的」になってしまうと、他のメンバーにも必ず影響しますのでプロダクト開発の中心から離れないように注意しましょう。
・1%の改善に気づけるシステムづくり
素晴らしいPDCAサイクルをまわすことができても検証がおろそかになってしまっては元も子もありません。実行するまえに必ず「検証できる基板」があることを確認しましょう。もちろんそれがない場合は構築しなければなりません。
どうしても、大きな数字に目が行きがちですが、グロースさせていくためには小さな改善の積み重ねが大切です。PDCAサイクルがしっかりワークするようにエンジニアは注意すべきだと考えます。
・PDCAサイクルで重要視していることまとめ
・ ひとりではサイクルを最適化できないことを理解してチーム一体である必要がある
・ 1%の改善を見逃さないための基盤づくり。
ROIドリブンで最適なPDCAサイクルを回すためにも基盤づくりはしっかりとやっておきたいですね。
3. テスト・自動化を目的にしていないか?
・なんのためにやるのか
カバレッジ100%のテストを達成することが目的ではありませんよね?自動化も「なんでもかんでも自動化すればいい」というわけではないはずです。
そんな思考停止したような目的を持つよりも、「なんのためにテストをするのか、自動化するのか」を一度考えてみてはいかがでしょうか?
そうすると、最低限必要なテストや自動化項目が明確になってくると思います。場合によっては上位のテストだけで良い場合もあるでしょう。
※テストコード不要と言いたい訳ではありません。どのレベルのテストがあればユーザー価値を高められるのかが焦点にするべきであると考えたいだけです。
・ここもROIドリブンで考えてみる
明確になった「テスト項目」や「自動化項目」にもROIで優先度をつけましょう。PDCAサイクルの中にちゃんと取り込んで確実に最小単位でのサイクルを達成することを優先して開発していくべきだと私は考えます。
そのためには、ある程度のマニュアル化は必要だと思いますし。ときには「自動化しない」場合のほうがユーザーにとっては良い場合もあるかと思います。ここも上記で話した「システム化することが仕事ではない」にかかる部分だと思います。
・手段や目的に囚われ過ぎないで・・・!
もちろん、自身や企業のノウハウを得るために「技術的な挑戦や最適化」は必要ではありますが、一番優先すべきは「ユーザー体験を最大化してプロダクトをグロースさせること」にあります。
ワクワクしますし楽しいのはわかりますが、手段や目的にばかり囚われないように注意したいですよね。
さいごに
ユーザー体験を向上させてプロダクトをグロースさせるために、エンジニアにしかできないことは沢山ありますが、それは「実装」だけではない場合もあると私は感じています。
私はいつも独りよがりではなく、チームのパフォーマンス向上に貢献し「最高のプロダクト」をつくるためにエンジニアとしてJOINできたらと考えています。
「チーム」も「プロダクト」もエンジニアリングして「ユーザー体験を最大化」していきたいですね。