はじめに
新卒エンジニアとして新規の自社サービスを開発している際、関連する既存の自社サービスが大幅に高速化できることに気づき、改善を提案して採用されるまで至りました。
その過程で自分が工夫したところ、またその経験を通して得た自分の気づきについてご紹介できればと思います。
準備 ~サービス視点~
1. サービスの全体像の理解
まず、アサインされた時点では開発するサービスへの理解が浅かったので、開発する機能に関連する過去の資料を全て読んで理解を深めました。それぞれの機能を作った背景や意図について理解を進め、わからない場合は上長に聞くようにしました。
また、サービスに関連する任意の更新された資料に目を通すことにも取り組んでいます。サービスは日々変化するため、今のサービスの全体像を正しく把握するために取り組んでいます。これにより、エンジニア側だけでなく、ビジネス側の状況も含めた包括的な提案をすることができます。
自分の会社では、資料の管理にGoogleドライブを使用しているため、サービス名で検索して資料を更新日時の降順で並べることを定期的に行い、更新された資料に目を通しています。
2. 様々な方法でのコミュニケーション
サービスへの理解があっても周りとの関係性が構築されていなければ、建設的な提案をすることが難しいです。ただ、自分の会社では基本的にはフルリモートのため、コミュニケーションを取るのが難しいという問題もあります。そこで、2つのコミュニケーションの手法を実行しています。
1つ目は、上長と積極的に交流することです。一般的に、上長の方がより多くの情報にアクセスすることができ、より広範な視野でサービスを捉えられます。したがって、サービスをより解像度高く理解するには、上長との関係性を構築することが重要です。そのため、DMや1 on 1の機会をできるだけ確保し、サービスについて考えていることを共有するようにしています。
2つ目は、サービスに関わる人の行動を注視することです。前節では、「サービスに関連する任意の更新された資料に目を通す」と書きましたが、資料には意思決定の結果しか残らず過程が表現されていない場合が多いです。自分の会社では、予定の管理にGoogleカレンダー、コミュニケーションツールとしてSlackを用いているため、いずれものサービスで該当者を検索することで、この意思決定の過程を把握できるように工夫をしています。
計画 ~ビジネス視点~
1. 提案のロジックのビジネス側への説明
上記のような準備で「サービスへの理解」を進めている際、関連する既存の自社サービスを改善できることに気づきました。そこで、改善提案のためのロジックに過不足がないかを確認する必要があります。今回は、上長に相談して確認作業を進めました。
また、今回の改善は、サービスに実質的には必要のないデータを保存しているテーブルや特定のデータを削除することでSQLの処理を高速化するというものです。ただ、エンジニア的には十分に合理性があるものの、特定のテーブルやデータを消すことが今回は機能を削ることを意味します。
そのため、その機能がなぜ必要がないのか、変更によりどの程度高速化されるのか、影響範囲と工数がどの程度なのかを踏まえてビジネス側へロジックを説明する必要がありました。
2. 適切なタイミングでの改善提案
「改善提案のロジックがエンジニア側とビジネス側の双方にとって合理的である必要性」について前節では書きましたが、合理的であってもプロジェクトの進捗によってはタイミングが悪く良い提案でも採用できない場合があります。
ただ、自分の場合、サービスに関わる人の行動を注視していたため、ちょうどそのタイミングでそのサービスの該当箇所の改修が求められていることを知っていました。さらに、その時点では新しいアルゴリズムやDBなどを採用して解決するような提案しかなく、時間的なコストが懸念点となっていたため、自分の機能を削る改善提案の方が格段に工数が少ないことも踏まえて提案し、採用されるに至りました。
発見 ~より深淵へ~
1. トップダウン的な解決方法の学習
今回の改善提案は採用されたものの、場当たり的に問題を解決していたため、任意の場合へ適用するのが難しいです。したがって、事業戦略や組織論などのビジネス知識のインプットを行い、トップダウン的な解決方法も学んでいく必要があります。
まずはイベント等へ参加したりブログや本を読んだりといった一般的なインプットをし、それに並行して開発しているサービスのプロダクトオーナーを含むビジネス側と関わりを持って自分の会社に固有のインプットを進める必要があると自分は考えます。
2. 組織内での地位の上昇
一般的には、事業戦略や組織形態からトップダウン的にサービスの方向性が決まります。つまり、本質的な改善提案をするためには、サービスの方向性を決められる程度まで組織内での地位を上昇させる必要があります1。
また、サービスにおける問題解決の前にエンジニアドリブンな組織に変えていくなどの組織的な課題を解決を要する場合が多々あるので、この部分も踏まえると、組織内での地位の上昇がより重要であると考えられます。
最後に
本記事では、自分が改善提案をするという経験により得た6つの教訓について紹介しました。
自分と同様にサービスの改善提案をしたい方の参考となれば幸いです。
-
自分の会社は一般的な階層構造を組織構造として採用しているため。 ↩