プロダクト開発で「なぜ作るか」に向き合って気づいたエンジニアが開発以外で貢献できること

こんにちは。ウォンテッドリーでフロントエンドエンジニアをしている高橋です。

受託開発とプロダクト開発では様々な違いがあります。私は昨年転職をし、受託開発からウォンテッドリーでプロダクト開発に携わるようになりました。クライアントはおらず、自らプロダクトに責任を持つこと、作ることだけではなく分析をして効果を追求することなど、様々な違いがあると感じています。その中でも、私が一番大きく違うと感じたのはエンジニアができる貢献の幅です。

受託開発では開発し納品する事が貢献、ではプロダクト開発では何が貢献になるのか。受託開発とプロダクト開発とのゴールの違い、リファインメントを通して「なぜ作るか」を学ぶ中で見つけた開発以外で貢献できることについてご紹介します。

プロダクト開発におけるエンジニアの貢献とは何か？

私にとってのエンジニアの最大の貢献は「仕様通りに、バグなく、納期に間に合うように早く開発をする」ことだと思っていました。これは受託開発に5年ほど勤めた経験からきています。受託開発はクライアントの要望を具体的な仕様に落とし、期日通りにシステムを納品することで利益を得ます。つまり、仕様通り高い品質のアプリケーションを素早く開発できればエンジニアとしては十分貢献ができ、一定の評価も得ることができていました。そのため私は転職後も同じ考えで業務を行なっていました。

しかしウォンテッドリーのプロダクト開発においては納品することはゴールではなく、ユーザーにどのような価値を届けられたか、事業にインパクトを与えられるかが重要です。入社してすぐ、コードレビューの中でこの気づきを得ました。いつも通りタスクをもらい、実装し、どのように実装したかを記載してレビュー依頼を出してました。そしてコードレビューが返ってきたら修正しようと思っていた時、返ってきたのは「この機能はそもそもどういう目的で作ったのでしょうか？」というものでした。機能がどのような価値をユーザーに届けるのか、事業に対してどのようなインパクトを与えるのかを問われたのです。

ここから「どう作るか」だけではない、開発以外に目を向けるべきことがあると気づきました。今まで私が持っていた「仕様通りに、バグなく、納期に間に合うように早く開発をする」というものはあくまで納品というゴールに対してのものです。しかしプロダクト開発においては先ほど述べたようにユーザーに届けられる価値、事業に与えられるインパクトがゴールになります。そのため納品するための「どう作るか」では貢献するには不十分であると気づいたのです。

施策の優先順位づけを通して「なぜ作るか」を学ぶ

開発以外の貢献を模索する中、チームが作る機能の優先順位を決めるプロセスを通じて、「なぜ作るか」を問うことが重要であると学びました。私のチームではバックログに投入されるアイディアに対して要求定義を解決案の決定を行い、その結果を元にスコアリングをし、開発の優先順位をつけています。この中で「ターゲットは誰か」「どのような価値を届けるか」「事業に対してどのようなインパクトを与えるか」「コストはどれだけかかるか」といった問いに答えることで、アイディアの解像度を上げていきます。 つまり、「なぜ作るか」という問いに徹底的に向き合い、限られたリソースでプロダクトの価値を最大化することこそが、開発以外の大きな貢献になるのだと気づいたのです。

「なぜ作るか」に向き合うことでできるようになったこと

この「なぜ作るか」という問いに向き合うことで、ただ開発するだけではない、価値を生み出すための提案が少しずつできるようになりました。具体的には開発外の貢献として以下に挙げるような事を行いました。

目的から逆算し、機能の代替案を提案する

目的から逆算し機能の代替案を提案することで、複数の案を比較して最適なアプローチを導く手助けができるようになりました。以前は機能に対してはどう作るかのみを考えていましたが、機能が解決したい課題が何かという目的から逆算することでコスト等のより良い代替案を提案できるようになりました。例えば「登録時にユーザー同士が繋がれるようにしたい」という施策では画面を追加することで対応しようとしていましたが、メールやPush通知を活用することでコストを低めて同じように課題を解決できるのではないかと提案しました。その結果、それぞれの案を比較して最適なアプローチが何であるかを議論することができました。

違和感を論理的に言語化し、優先度を正す

違和感を論理的に言語化することで、今取り組むべき課題かを見直しやるべき課題に集中できるようになりました。以前はこの機能は今必要なのかという違和感があっても言語化できずに開発に取り掛かってしまっていましたが、本当にユーザーの課題が解決できるのか、より上流の課題を解決する必要があるのではないかを分析し、今この機能を開発するべきか、意見を言う事ができるようになりました。例えばユーザーのブログ閲覧率の向上のために検索導線を追加する機能を考えた際は、そもそも検索導線の流入が少ないという事実がありました。そこで、まずは導線を強化するべきだと提案し、施策の優先度を適切に見直すことができました。

終わりに

「なぜ作るか」に向き合うことは、開発以外でエンジニアが事業に貢献できることだとわかりました。もちろん受託開発で培った「どう作るか」と言う技術的な土台は無駄になるわけではありません。機能を形にする技術力はベースに持ちつつ、より広い範囲で貢献ができるようになったのではないかと感じています。今後も「なぜ作るか」に向き合うことでユーザーへ価値を届け、事業にもインパクトを出すことのできるエンジニアになっていきたいと思います。