エンジニアの自分が「プロダクト志向」を持つために意識している2つのキーワード

新入社員のフレッシュ感が会社にも溢れる中、春の陽気のせいか、物憂く時を過ごすことの多いこの頃。SDGデータサイエンスDiv改めマーケティングテクノロジーDivの島です。
今回のエンジニアブログでは、エンジニア2年目に入り、自分が何を志向しているのか、何が成長に繋がったのかを書いてみました。

経緯とか

エンジニア一年目の大きな学びとして「自分が書いてるコードの1行が、事業にどういう風に繋がっているのかを意識できるようになった」ことがあります。
そして最近、マネージャーから2つのキーワードを聞いて、そのキーワードで自身の経験を説明できるんじゃないかなと思い、言語化してみるというのが今回のテーマです。
言葉の誤用などあると思いますが、優しく見守ってください。

プロダクト志向とはなんぞや

このブログを見ている方はエンジニアの方が多いと思います。みなさんはどのような方向性を志しているでしょうか？
技術を極めたい、事業価値に貢献したい、いいチームを作りたい・・・などたくさんの方向性があると思います。
業界においてもエンジニアという職業自体がフォーカスされ、（おそらく）昔に比べるとエンジニアのキャラクターは多岐に渡っていると思います。
今回ブログのテーマとした「プロダクト志向のエンジニア」は「POから降りてきたタスクをひたすらこなすのではなく、ユーザーストーリーを意識しながら自走できるエンジニア」として定義したいと思います。

大事な2つのキーワードの紹介です。

velocity（ベロシティ）

アジャイル開発とかでよくいうアレです。「決められた期間内でそのチームが届ける（デリバリーできる）要求の量のこと」です。開発速度と書いてある文献もみました。工数の見積もりとか、生産性というのはちょっと違うらしいです。

level of detail（lod）

英和辞典で調べると、「詳細度」として出てきます。texture mappingで使われるテクスチャーの詳細度だそうです。3Dゲームとかで、遠くの描画が詳細かどうか的なやつですね。
今回でいうと、「プロダクト理解の詳細度」になります。

ここで本題

では先ほどのベロシティとlodを使って、プロダクト志向というのを自分なりに説明してみます。

キーワードの定義

ベロシティは 「チームがデリバリーできる要求の量」
- ベロシティが不安定＝デリバリーできる要求の量が明確でない。
lodは 「（ユーザーストーリーやプロダクトの価値を前提とした）POの言葉の詳細度」
- 要求のlodが高い＝より具体的な言葉「○○という課題を解決したいから××という機能を△△という風に作って」

と定義します。（ツッコミどころはたくさんありますがとりあえずスルーしましょう。）
では「プロダクト志向のエンジニア」とベロシティ、lodはどう繋がっていくのかというと、

ベロシティとlod

ベロシティが不安定で要求のlodが高い
ベロシティが安定してきて要求のlodが高い
要求のlodが低くなる（より抽象的になる）ことによってベロシティが不安定になる
要求のlodが低いが、プロダクト理解が深まる・ユーザーストーリーが想像できることによりベロシティが安定する
以下ループ

といったイメージです。プロジェクトに入ったばかりの頃は、詳細な仕様と背景を聞かないと（聞いてもイメージできない）開発を進められなかったけど、時間がたつにつれ抽象度の高い注文にも応えられるようになるみたいな感じです。
自分のバージョンで書いてみました。

ベロシティとlod 島ver

（ベロシティ不安定、lod高）1ヶ月単位でたくさんCVがでた案件をまとめて見たいから、それぞれのまとめを同じページで、先月・先週比と並べて、それぞれの差も表示させて。
- 「1ヶ月単位でたくさんCVがでた案件をまとめて見たい」は意味がわかるけど、どの指標を何のために見ているかわからない。どのテーブルからデータを取得すればいいかもわからないし、どういう風に見せたいいかもわからないので、どれくらい時間がかかるかわからない。
（ベロシティ安定、lod高）広告の配信枠でちゃんと効果が出てるか見たい。ワイヤーはこんな感じ。
- ワイヤーがあるので画面のイメージはできるけど、この画面を見て誰が何をするかはイメージできない。使うテーブルとかはすぐわかる。
（ベロシティ不安定、lod低）各配信枠の異常にすぐ気づくようにしたい。
- 情報として何が必要か、アラートのイメージができる。今まで自分が触れていないシステムであり、どれくらい時間がかかるかわからない。
（ベロシティ安定、lod低）プロダクト全体の進捗、健康度をいい感じで見たい。
- 類似の機能がどう使われているか、何が足りないかを想定できるので抽象度が高い要件でも具体的なアイディアを策定できる。実際の機能を作るスピードがわかる。

下に行くにつれ「より抽象度の高い要求に対する解決策をデリバリーできるスピード」を明確にできるようになりました。

なぜできるようになったのか

上の例では、「抽象度の高い要件であっても必要なリソースをイメージできる」ようになりました。
ではなぜそれができるようになったのか、

実際にどう使われているか、何の指標を見ているのかを調査していた。
- 実際の使用例をトラッキングできるといいですね。
- 自分は同期の営業やデザイナーにヒアリングしてみたり、実際に使ってもらったりしてました。
その機能でクリアしたい課題を意識し、背景・目的を考えた上で先輩、上司に確認していた。
- わからないことはわからないままにしない。
マネージャーが「自分が書くコードの意味を人に説明することができるようにしろ」と常々いっていた。
- 始めは単にプログラム上で、どの変数がどの関数で・・・といったことだと考えていました。

「自分が開発している機能（あるいはプロダクト）における、使い手の5W1Hを常に意識する。」
言葉にしてみると非常にシンプルですが、より詳細に意識できるようになることで相手の要求と自分のリソースを把握できるようになります。

終わりに

「誰の何の課題を解決するために、どういう風にシステムで表現するのか。」を常に意識することで、「より抽象度の高い要求に対する解決策をデリバリーできるスピードを明確にできる=プロダクト理解のあるエンジニア」になれる。
「タスクの背景を鑑みながら、リソースの中で適切な解決策を考えられる＝自走できるエンジニア」になれる。

それがプロダクト志向を持つエンジニアになるステップなのではないかと思います。
この仮説を自分自身で検証して、プロダクト志向を持つために大事なことはこれだ！と胸をはって言えるようになりたいと思います！！