Zenn
🎃

【体験談】エンジニアがビジネス視点を持って変わったこと

2023/10/13に公開
ポエム
プロダクトマネジメント
キャリア
プロダクト開発
ビジネス
idea

はじめに

「エンジニアもビジネス視点を持つべきか」という議論がよく行われています。
それに対して、「エンジニアにビジネス視点を持てというのは管理職や経営者の怠慢である」とか「作ったものが売れなければ無価値なのだから全エンジニアがビジネス視点をもつべきだ」とか「ビジネス視点という言葉は定義が曖昧であるため、まずはビジネス視点とは何かを定義すべきだ」など様々な意見を見かけます。
一方で、これまでビジネス視点をあまり意識していなかったエンジニアがビジネス視点を持ってみてどうだったかというような「体験談」はあまり見たことがありません。
本記事では、自社開発企業でSaaSプロダクトを開発するソフトウェアエンジニアの私があるきっかけでビジネス視点を持つようになって変わったことを体験談として紹介します。

きっかけ

2年ほど前に新製品の初期メンバーとアサインされ、立ち上げから携わることになりました。当初はPoC用のプロトタイプを開発するエンジニアとしてアサインされたのですが、PoC活動やお客様ヒアリングをする中で、どんな商品を開発したらお客様の課題を解決できるのかや売れるのかを考えるのが楽しく、企画の仕事も担当させてもらうようになりました。そして、現在に至るまで約2年間、エンジニアをしながら企画の仕事の担当も続けています。具体的に私が行っている企画の仕事には下記のようなものがあります。

  • 新機能の要求仕様検討、開発チームとの整合
  • PoC活動
    • お客様ヒアリング
    • ペーパープロトタイプ作成
  • 商談
  • 関連部署（営業やCS）の教育
  • 各種業務フロー作成
  • 商品構成検討
  • 販売戦略検討
  • 社内答申用資料作成

ありがたいことに幅広い仕事をさせてもらう中で、お客様の課題を解決するにはどうしたらよいか？やどうやったら売れるのか？といったビジネスのこと、つまりビジネス視点を持つようになりました。

変わったこと

ビジネス視点を持つようになって変わったことを私個人として変わったこととプロダクトチームとして変わったことに分けて紹介します。

個人として変わったこと

まずは私個人として変わったことです。

  • 今までよりも幅広い選択肢の中から対応方法を決めることができるようになった

    • 以前は何かを決める際、開発チームの手の届く範囲だけで対応できることの中から最善策を探すことが多かったです。現在は開発と企画、さらには営業やCSも含めたプロダクトチーム全体での最善策を探すようになりました。これは、企画の仕事をする中で営業やCSのチームと関わりがあり、彼らの仕事内容に対する理解が深まったり、依頼ができる関係性ができたことによる変化だと思います。より幅広い選択肢の中から検討できるようになったことで、より最適な対応ができるようになったと感じています。

  • 今までよりも開発にやる気が出るようになった

    • 今までも開発は好きでやりがいをもって取り組んできたのですが、より一層開発にやる気が出るようになりました。自分が担当した企画の開発であることや商談にも出ているためお客様の顔も頭に浮かぶためです。以前は「企画が決めたものを納期までに作る」と捉えて納期に追われてしまう所がありましたが、現在は「お客様の課題を解決する機能を早く提供してあげたい」というより純粋な気持ちで開発に取り組むことができるようになりました。

  • エンジニアとしての拘りを持ちすぎないようになった

    • 以前は何かを開発するとき、エンジニアとして手抜きをせずにちゃんと作りたい欲求のようなものがありました。現在はビジネス的にあまり変わりがないのであれば拘らなくてもよいと思うようになりました。

  • 不確実性にはプロダクトチーム一体となって対処していくべきだと思うようになった

    • 以前はある方向への拡張性は考慮しなくてよいなど開発スピードを上げるための決定を企画にしてほしいと思っていましたが、企画の不確実性の多さを体験したことで、無理な決断を迫ることが不毛だと思うようになりました。現在は不確実性にはプロダクトチーム一体となって対応していくことが必要だと考えるようになりました。

  • 自分の感覚とお客様の感覚は思ったよりも違った

    • 自分としてはいまいちだと思っていた企画をお客様にヒアリングしたところ、とても反応がよいという経験をしました。以前から自分の感覚とお客様の感覚が一緒ではないとは分かっていましたが想像以上に違うと分かりました。特にエンジニアの場合、新しい技術やツールに対する感度が一般の人よりも高い傾向があるため、一般の人とは感覚がずれるのではないかと思います。

  • 売れなかったら自分のせいだと思えるし、売れたらめちゃくちゃ嬉しい

    • 自分が企画、開発したプロダクトであるため、売れなかったら自分のせいだと思えて、とても魅力的に感じました。逆に売れたらめちゃくちゃ嬉しいです。はじめて商談でお客様が購入を決めてくれた瞬間は忘れられません。

  • アウトプットではなくアウトカムを意識するようになった

    • 以前は「企画が考えた機能を納期までに作る」ことを重要視する傾向がありました。現在は「どれだけプロダクトの売り上げに貢献したか」を考えるようになりました。企画の仕事をしてプロダクトの売り上げに貢献することが大切だと実感したためです。

  • お客様にとって価値があれば売れる訳ではないと学んだ

    • 以前は開発する機能がお客様にとって価値があるかどうかが売れるかどうかのほぼすべてだと思っていました。そのため、お客様にとって価値があまりない開発（例：カタログスペックの星取表を埋めるための開発）はあまり好きではありませんでした。現在はお客様にとって価値があることが大切であるとの考えは変わっていませんが、売れるかどうかを決める要素はほかにもたくさんあると考えるようになりました。企画の仕事をする中で、営業担当が売りやすい商品になっているか？やBtoBプロダクトの場合はお客様が決裁者に提案しやすい商品になっているかといったことも重要になると体感したからです。そのためこれまではあまり好きではなかったカタログスペックの星取表を埋めるような開発も売り上げのためには必要なことなのだと思うようになりました。

  • 商談に参加すると意外と社内外から喜ばれることを知った

    • 意外だったのですが、エンジニア(私)が商談に参加するとお客様からも社内の担当者からも喜ばれました。参加する前は「普段お客様とやりとりしていないエンジニアが商談に出たら、お客様に何か失礼なことをされそうで嫌だ」などと思われてしまうのではないかと思っていたのですが、「中身のことが分かっている方が参加してくれて嬉しかった。」、「エンジニアがいると安心感が違う。」といったポジティブなフィードバックを社内外から頂けました。

  • 評価されるようになった

    • 私自身は評価されようと思って企画の仕事をしている訳ではないのですが、周りから以前よりも評価されるようになりました。ほかの人がやらないことをやったことが評価された要因だと考えています。エンジニアであるならば技術スキルで抜きんでたいと思うものですが、技術スキルで抜きんでることはなかなか難しいと感じていたので、こういう評価のされ方もあるんだなと感じました。

プロダクトチームが変わったこと

次はプロダクトチームが変わったことです。ここでいうプロダクトチームとは１つのプロダクトを企画、開発、販売するのに必要なメンバーが含まれているチームのことです。

  • 企画開始から開発完了までの期間が早くなった

    • 企画の初めからエンジニア(私)がチームにいるため、企画チームで企画を固めてから開発チームに相談した結果、企画が作り直しになるということが減りました。また、企画と開発の両方を理解している人がいることで、「後で企画(開発)チームに確認しておきます。」といったことも減りました。その結果、企画開始から開発完了までのスピードが早くなりました。

  • 企画チームがエンジニア視点を持つようになった

    • 「エンジニアもビジネス視点をもて」のアンサーとして「ビジネス職もエンジニア視点を持て」とよく言われますが、私が企画チームに入ることで企画チームにエンジニア視点を持たせることができます。これにより、私以外の開発メンバーから見れば「企画もエンジニア視点を持っている」状態になりました。また私以外の企画のメンバーも最初よりエンジニア視点で考えてくれるようになりました。

番外編：エンジニアが企画チームの一員として活動する上で大切にしていること

番外編として、私が企画チームで活動する上で大切にしていることを紹介します。

  • できるだけ早く役に立ち信頼される

    • あくまでエンジニアが本業である以上、ただ企画チームに参加するだけだとどうしてもお客様状態になってしまいます。それではいけないと思い自分ができることを見つけて積極的に取り組んで役に立つことで、企画メンバーの一員として認めてもらえるように努力しています。

  • いつもより丁寧に説明する

    • バックグランドが違う企画メンバーに普段エンジニアと話をしている感覚で話をしても伝わらないので、発言の背景や意図を丁寧に説明するように心掛けています。また、ほかの企画メンバーの案を否定するときはできるだけ明確な理由や改善案を示すことや改善案を提示できないけどどうしても納得できないときは言い方に気をつけることを心掛けています。

  • 開発チームやリーダーの理解を得る

    • 企画の仕事をする分、開発の時間は減ります。そのため、開発チームやリーダーに私が企画チームに加わる目的や意図を理解してもらうようにしています。そうしないと「あいつは何をやっているんだ？けしからん。」となってしまいます。アウトプットではなくアウトカムを重視してくれるチームやリーダーであれば、きっと理解してくれると思います。私の場合は幸運なことにとても理解のあるチームやリーダーを持っています。

  • 商談に出て一次情報をもとに企画を検討する

    • 企画の知識や経験は他の企画メンバーに劣るため、商談に出てお客様の意見を聞いて企画を検討することを意識しています。企画のメンバーには意外と商談に出ていない方もいるため、その方々より納得感のある企画を作ることができるようになります。

  • 自分がどのロールで話しているか/考えているかを明確にする

    • チームのメンバーと話すとき、私が企画と開発のどちらのロールで話しているかが不明確で、メンバーを混乱させてしまうことがありました。そのため、「今は企画のロールで話しています。」と明言するなどして明確にすることを意識しています。また、自分で思考するときも企画と開発のどちらのロールで考えているかを明確にしないと考えがまとまらないことがあり、明確にするように心掛けています。

  • ビジネス面の目標を人事考査の目標に組み込む

    • エンジニアの人事考査の目標にビジネス面の目標（例：売上、お客様件数）をたてることは少ないと思うのですが、そうすることでビジネス面の目標が自分事になります。

まとめ

エンジニアの私が企画の仕事を通してビジネス視点を持つようになり変わったことを紹介しました。エンジニアとして働く中では経験できないことが経験できて色々な変化を日々感じています。エンジニアとしても、幅広い選択肢の中から対応できるようになったりしたことは役にたっていると感じています。
一方で、「エンジニアがビジネス視点を持つべきか？」という問いに対しては、ビジネス視点は1つのスキルなので持っているに越したことはないと思いますが、必須スキルではないと思います。また、その重要度はプロダクトやチームの状況によって変わると思います。それぞれ得意分野があると思いますので、ビジネス視点を持ったメンバーや技術で突き抜けたメンバーなど得意なことを活かしていくことでよいプロダクトが作れるんだと思います。

Discussion