CodeZine(コードジン)

特集ページ一覧

エンジニアのビジネス視点が、プロダクト開発を加速させる――有効な3つの実践とは

アライドアーキテクツに学ぶ、プロダクト中心の組織構築への実践 第3回

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加
2020/11/05 11:00

 SNSを軸に企業のマーケティングを支援するテクノロジー企業、アライドアーキテクツ。「One Team, One Goal」を掲げたプロダクト中心の組織体制で、一度は落ち込んだプロダクトのV字回復を成し遂げました。ここまでの連載ではその過程を、ベトナム拠点、日本の開発組織の改善ポイントを踏まえて紹介してきましたが、第3回となる今回のテーマは、ビジネスを加速するための“開発効率”。エンジニアが積極的にビジネス視点でプロダクトを捉える必要性とその視点を身につけるために実践した3つのアクションについて、プロダクト開発リーダーの石川裕弥氏が解説します。

目次

はじめに

 弊社をはじめ自社開発のプロダクト事業において最も大きな関心ごとのひとつに「プロダクトの売上を上げる」ということがあります。しかしながら、エンジニア界隈では技術情報については大変活発に意見交換がされる一方で、「どうプロダクトビジネスを成功させるか?」といったトピックについて話されることが少ないように感じます。

 筆者はこれまでいくつかのプロダクトの立ち上げや運用を経験する中で、エンジニアがビジネスについての理解を深めることは、特にBtoBのプロダクト開発において多くの好影響を与える、ということを強く感じています。

 そこで今回は「ビジネス」を軸にBtoBプロダクトの自社開発に焦点をあてて、開発をする際の心構えや他職種のメンバーとの関わり方、具体的に開発を進めていく上で留意すべき点についてお伝えしていきます。

その開発はするべきか? しないべきか?

 少しネガティブな話になりますが、筆者は実際に一緒に働いていたエンジニアから「ビジネスチームからの要求はまず否定する」といった言葉を聞いたことがあります。

 理由を聞くと「作ってほしいと言われて作ったものの、結局全然使われることがないことが頻発した。われわれはこの先ずっとメンテナンスしていかなければならないのだから、安易な理由で開発をするべきではない」からだといいます。極端な例ではありますが、似たようなケースを体験された方は少なくないのではないでしょうか。

 しかし、この状況ではエンジニアチームとビジネスチームの溝は深まるばかりで、とても健康とはいえません。変化の激しい時代に適合するには、プロダクトはイノベーティブな進化を続ける必要がありますし、それ以前に売上を上げなければなりません。一方、無茶な開発を続けていけば良いのかというと、そうでもありません。技術的負債は雪だるま式に蓄積し、開発効率や開発者のモチベーションの低下など、別の問題を引き起こすことになるでしょう。

エンジニア自身がコアな意思決定をする

 これに対しては、ビジネスチームの責任者に技術的負債のリスクを説明するなどして開発のバランスをとる、といったアプローチをインターネット上の記事などで見かけることがあります。受発注の関係にある開発の場合はおそらくそうした手段が一般的だと思うのですが、自社開発をするプロダクトの場合にはこれとは異なる有効なアプローチがあります。

 それは、エンジニア自身が開発のコアな意思決定をすることです。そもそも、エンジニアでない人には技術的負債のデメリットは理解はできても、ビジネスに与える影響まで見積もることは非常に困難です。そうであれば、それができるエンジニアが開発の意思決定を行えば良い、という発想です。

 しかし、現時点で開発の意思決定権がエンジニアにない場合はどうすれば良いでしょうか。


  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • 石川 裕弥(イシカワ ユウヤ)

     アライドアーキテクツ株式会社 プロダクトカンパニー プロダクト開発リーダー。SIerでプログラマー、複数のプロジェクトマネージャーを経験したのち、2013年よりアライドアーキテクツ社に入社。プロダクトマネージャーとして数々のプロダクトの立ち上げから運用に携わる。ビジネス部門の戦略遂行や営業組織のマ...

バックナンバー

連載:アライドアーキテクツに学ぶ、プロダクト中心の組織構築への実践
All contents copyright © 2005-2020 Shoeisha Co., Ltd. All rights reserved. ver.1.5