外資就活でエンジニアリングマネージャーをしている根本です。
8月よりこれまで約1年取り組んでいたリプレイスから新規開発に役割を変え、ここ数ヶ月での取り組みや変化を紹介します。
この記事は、HowTelevision Advent Calendar 2024 1日目の記事です。
ユーザー理解を深めるインタビューの実施
事業はユーザーへの価値提供によって成り立っているため、どのような施策を打つべきか意思決定するためにはまず最初にユーザーへの解像度をできる限り高めることが重要だと個人的に思います。定性的観点では、すでに就活を終えた外資就活ユーザー100人に全社施策としてインタビューを行いました。事業に関わる全ての職種の人が参加することで、ユーザー像への一定の共通認識を持つことができました。 詳しくは、こちらの記事をご覧ください。 blog.howtelevision.co.jp
企画への浸透
新卒エンジニア領域への事業展開には、当事者目線で企画に関わることが不可欠
外資就活は、エンジニア志望ユーザーの就活支援に今後力を入れていく方針です。 これまでは外資系企業やコンサル志望ユーザーへの価値提供が主軸だったため、エンジニア特有の選考への対策ができるように、機能やコンテンツを拡充させていく必要があります。 そこで、エンジニアのことを最も理解しているエンジニア自身が企画アイデアを出していくことで初期から課題への解像度が高く施策を打つことができます。 これまでは施策自体もPdMが考えることが多かったのですが、特にエンジニア領域に関しては企画を立てるところからエンジニアで議論を行うことを推進しています。 これにより、エンジニアが開発するだけに留まらない付加価値を発揮でき、全体として事業貢献に繋がります。
以下がエンジニアユーザー向けに直近リリースしたものです。
開発ドリル - Software Engineer 就活 by 外資就活ドットコム
機能のリリースに終わらない目標と達成評価
ユーザーへの提供価値をスプリントゴールを設定する
現在のチームでは、同じ目標に向かって柔軟に意思決定するためにスクラムを採用しています。スクラムにおいて、計画時に決めた内容をリリースすることだけをスプリントゴールとして設定することは、施策の目的を見失ってしまう可能性があると思います。 施策の目的はリリースすること自体ではなく、ユーザーへの提供価値を向上させることです。 そこで、今回の施策でユーザーへ提供したい価値をゴールとして設定することで、それを最大限に実現するためにはどのような優先順位で開発を進めるべきかをチームで議論できると思います。
ゴールの達成は効果測定をして初めて評価できる
施策の結果としてユーザーに期待した価値提供ができたかどうか検証することも必要です。施策の区切りとスプリントの区切りは必ずしも一致しないため、スプリントイベントとしてのレトロスペクティブとは別に行う必要があります。定量的には、計測すべき指標を事前に設定・ロギングし、Google AnalyticsやRedashというBIツールに集約したログを集約して分析を行っています。 プロダクトオーナーの役割にあるPdMが行うこともありますが、主にエンジニアが分析タスクをチケットとして切り、施策のリリース後に分析結果が共有されてから、施策を完了とします。 施策の効果検証までエンジニアが実施することで、優先順位を考える上で自然とリソース対効果を考える癖がつく上、設計段階でどのようにロギングすれば分析がしやすいかを早い段階で考えておくことができます。
早期にスプリントの不確実性を減らす
不確実性の高いタスクを優先的に取り組む
計画したことをやり切る、スプリントゴールの達成を阻むことの一つは、タスクの不確実性です。バグの調査タスクや技術的負債が絡む部分においては作業時間の不確実性が高いです。スプリントの最後に不確実性の高いタスクを残しておくと、終わってみないとゴールの達成できたかわからない状態になってしまい、スプリントの途中で軌道修正や優先順位の変更をすることができません。不確実性の高いタスクが見積もり通りか長引きそうかだけでも早期に把握しておくことで、見積もり通りならば計画の達成の確実性が上がり、長引く場合には時間をかけてでも解決するべきかどうか軌道修正や期待調整ができます。
短い間隔でチーム内動作レビューを実施し、柔軟に軌道修正する
リリースまでの区切りの大きいプロジェクトやマイルストーンほど、想定とズレてから方向性を起動修正するコストが高くなってしまいます。スプリントレビューを定期実施していたとしても、スプリント内で複数人で協力しているマイルストーンであればボタンの掛け違いは起こりやすいと感じます。その上、タスクの正確な見積もりは難しく、着手してみて問題が発覚することもありました。そこで、チーム外の方が参加するスプリントレビューとは別に、ある程度形になったらテスト環境にデプロイしておき、PdM・デザイナーの方の含めチーム内で動作レビューを行っています。これにより、 取り組む優先順位など柔軟に軌道修正していくことができていると感じます。
デリバリ指標のヘルスチェックの仕組み化
Datadogなどソフトウエアの作動をモニタリングするサービスや仕組みを導入していても、それらの出力を確認する文化がなかったため、部分的なエラーや停止を遅れて気付くという課題がありました。そこで、各サービスの特に重要な部分をエンジニアのみのデイリーの場で毎日確認するようにしています。Slackにアラートを通知するように設定することはできますが、Datadogだけではなく、Search Consoleやメール送信、FIrebaseなど集約が難しい多数のサービスを利用しており、すぐに仕組みを構築するのは時間がかかるため、完璧でなくてもすぐにできることから試しています。デイリーでの確認も限界はあるため、今後は通知の仕組みの構築を検討していきます。
まとめ
自分たちが使った時間が最終的にユーザーへの価値提供に最大限変換されるために必要なことはなにかを考え、議論と試行錯誤に取り組んでいます。まだまだ仕組みとしては改善の余地があるので、今後も継続しながら強固なものにしていきたいと考えています。