概要
プロジェクトを進めていく上でいくつかのスキルを身につけると、成果が出しやすくなり、より自分のアイデアでプロダクトをよくしていくことができます。
想定としては、2-3人で1-2ヶ月くらいの機能の開発や、1ヶ月以上のグロースなどの改善施策を任されたときに気をつけるといいことです。
ここでは、グロースのポイントや、改善の仕方でなく、プロジェクトを回す上で注意することを書いています。
プロジェクトの目標の確認
プロジェクトの目標を確認することが重要です。その上で、計画を立てる必要があります。
プロジェクトを成功させる要素は、４つあります。
- スケジュール
- いつまでに何をリリースするか
- いつまでにプロダクトのどの数字を改善するのか
- プロダクトクオリティ
- 確認が難しいことが多い
- 中間で確認できるゴールを決める
- 1度で完成しないことを計画に織り込む
- ユーザインパクト
- 最終的には「ユーザへのインパクト」がどのくらいあるのかがゴールになる
- 登録をさせたいか、購入をさせたいか、応募をさせたいかなど、ユーザが目指すゴールに対して目標を決める
- チーム(健康/オーナーシップ/成長実感/目的)
- プロダクトを通してチームが無理してないか、面白く仕事ができているか
- 健康的に仕事ができているか
- オーナーシップを持って取り組めたか
- 成長実感を感じられているか
- プロジェクトの目的に共感して仕事ができているか
=> プロジェクトはどうなったら成功といえるのかは色々な側面で理解する
* 上長はゴールについてどう思っているか
* 失敗するとしたら、どのようなことが起きると失敗か
任される = 目標の達成が求められている
- ただ開発することをゴールにしない
- 開発することがゴールだと、リーダーは達成することをゴールとしているため齟齬が生まれる
- あとで追加の開発が発生したり、最後に機能が詰め込まれることはある
- 想定してないバグや追加の改善を想定して計画を立てる
- だいたい、経験的には、自分ができたと思う地点で、残り倍作業があるイメージです。
- 失敗したプロジェクトのケース
- プロジェクトが終わったときに、「まだ開発したいと思う」=「やりきれなかった」となる
- -> 自分目線で反省し改善する必要が必要。限られたリソースでいかに目標を最大化するか
- -> 本当に実験する上で時間が足りないなら、リリースを伸ばしてでも詰める必要がある。
- -> やりきれないまま失敗したプロジェクトは、また一から同じようなプロジェクトを試す可能性もあり、最も悪い
プロジェクト項目の詰めのポイント
- スケジュールの中に「プロダクトクオリティの確認」「ユーザインパクトのチューニング」ができる計画が入っているか
- 「機能を使う」だけでなく、「機能を知ってもらう」ことは実装されているか
- 通知、モダル、メガフォン、メールなど
- ここがないと使われないものを開発してしまう
- 関連指標のトラッキング
- プロジェクトによって影響が受ける場合、あるタブにはアクセスが集まるがあるタグはアクセスが減るなど
- PRの確認のタイミング
- 直前に伝えるとバタバタする
- 逆に開発のスケジュールが決まらない中で決めると、リスケの連絡が発生し困る
- 法務と確認するべきことはないか
- プライバシーポリシー・利用規約に沿った機能提供をしているか
- 参考文献 「良いウェブサービスを支える「利用規約」の作り方」 https://www.amazon.co.jp/%E8%89%AF%E3%81%84%E3%82%A6%E3%82%A7%E3%83%96%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%82%92%E6%94%AF%E3%81%88%E3%82%8B%E3%80%8C%E5%88%A9%E7%94%A8%E8%A6%8F%E7%B4%84%E3%80%8D%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9-%E9%9B%A8%E5%AE%AE-%E7%BE%8E%E5%AD%A3/dp/4774155942
プロジェクトの開発項目を決める方法
- 必要なものだけにフォーカスすることが重要
- やらないことを決めることで、重要な改善やグロースに費やせる
- また、プロトタイプを作ることが目標なら、本当に求められているものを最短で作ることが必要。
- デザインをする必要があるのか
- どのような体験を実現するべきか
- どのような機能のテストがしたいか
- アプリの新しいインターフェイスの実験をするときは、速度はある程度必要
- プロダクトの方向性に関係のある技術を含む場合は、プロトタイプを最短で作る
- プロトタイプ以外の開発項目は、プロトタイプができてから考える
- 技術の実装ができない場合は、そもそも開発しないということもある
- 「機能を知ってもらう」などは、初期から詰めずに、フェイズを分けて、開発項目を洗い出すのもいい
- 「機能を使う」 -> 「機能を知ってもらう」 -> 改善項目洗い出し
プロジェクトのスケジュールの決め方
- ざっくりリーダーの感覚を確認する
- リーダは次のプロジェクトや、他のプロジェクトや、チーム全体のゴール達成を考えている
- だいたいのスケジュール感はあることが多い
- 大きくずれる場合は説明が必要
- 自社開発の開発スケジュールはある程度ぎりぎりくらいがよい
- スケジュールが空けばもっと他の改善に時間が使える
- 全部できた後、改善にアプリなら2週間、ウェブなら1週間は最低盛り込む。
- 改善サイクルを2回回すなら、プラス1週間になる。
- 改善サイクルは何度か回すほうが完成度は高まる
プロジェクトの切り分け方
- 重要な機能、依存の大きい機能から開発を割り振る
- よくあるのは頼みやすいタスクを割り振ってしまう
- マネージャーが開発できる場合自分の負担が増えボトルネックになることも
- 複数人で開発する場合は、スキルによって頼むことを変える
- プレイングマネージャーの場合は、自分とチームのメンバーのスキルを考える
- スキルがある人がチームにいる場合はプロジェクトとして頑張る箇所(時間はかかるけど、よくなればなるほど、プロジェクトが成功しやすくなる)を詰める
- 経験がない人の場合は時間がかかるけどやればできる重要なところからお願いするといい
- なるべく1週間ごとに、目に見えるような開発計画を立てる
- サービス開発の場合は、ある程度動作を確認して改善することも多い
- デザイナーやリーダーと週1くらいで確認できるといい
- 大きなプロジェクトは目で確認できるタスクから終わらせる
- 8割できていると思っていたら、最後の2割だと思った開発が何週間も終わらない
- リファクタリングから始めてしまい、影響範囲が増えすぎて、バグや追加開発が増える
インターン(経験がない)・外注の人への頼み方
- なるべく考えることをなくす
- もしくは考える領域をはっきりさせる
- 作るものの仕様が分かりやすいものがよい
- 全部伝えるのでなく、必要なものだけを伝える
- 自分が実装するとしたら、どのクラスを見て、どう思って、どこのファイルを変更するかなど、イメージできるように伝えると良い
スケジュール通り進んでいないとき / 目標通り数字が推移しないとき
- すぐにリーダーに確認する
- スケジュール通りに進まなかった原因と対策を考える
- リーダーが知りたいのは プロジェクトが達成できるのかという1点
- うまくいっていないときは、どう変更したらうまくいくのかを知りたい