こんにちは。MGKです。
開発者の立場からみると技術は大事ですね。有名なサイトを見ながらこの裏は何で作られてるんだろう。。
Rubyか～～！なるほどね。。とか。もう病気ですね。みんな技術大好きだから。
こういう、みんなが大好きな技術が今はAIという新技術に侵害され始めてるのではないかと最近思っています。
例えば、Googleでは自前で開発したGeminiというAIがあります。そのGeminiの公開発表の数日前に多くの開発者がリストラされました。
新しいAIが発表されると同時に今まで問題なく働いてた開発者の仕事が奪われてしまうことになります。
我々の大好きなプログラミングを我々が作った技術に奪われてるように見えますが、どうでしょうか。
今は様々なAIをどう使うかが、新しい技術を学ぶことになってると思います。それって本当ですかね。次はそれすら不要になるかもしれません。
2035年にはプログラミングという言葉がなくなるという笑い話もありますが、我々は開発者のまま定年退職を迎えることはできるのでしょうか。
1980年までエリート職業だった電話交換手のように、技術進化とともに一瞬で消されてしまうかもしれません。
リバークレインに入社するまでは私は技術第一主義！、開発者であれば何よりも技術が最重要だと思ってました。そのため、古い技術を使うプロジェクトは避けていました。
開発者なら誰でも、最新で高い技術力をもつエンジニアが憧れの存在ですよね。
私もその一人でした。しかし、リバークレインに入社してからその考えは少しずつ変わってきました。
毎日、社内システムの利用者と密に話しながら、使いやすくて分かりやすい社内システムを作るにはどうしたらいいのか重要になり、新しい技術を学ぶ時間より既存システムの改善方法を悩む時間が長くなりました。
より利用者の立場に立って開発するには技術書よりCRMとはどんなものなのか、CRMシステムはどう構築するべきか。WMSとは？SupplyChainをよくするためにシステム役割はなんなのかを調べて覚えるようになりました。
今は後輩達にこう言います。技術の勉強ももちろん重要だよ。でもそれより重要なのは業務内容を勉強しておいて。業務がわからないとつまらなくなる。
今の業務システムをどうしていくか？と言うことについては、それを実現するための開発言語は正直なんでもいいと思ってます。
もちろん最新の技術を使って効率よく高速で綺麗なシステムを開発することも大事ですが、Mainは業務やシステムの内容であってSubはそれを実現するための技術にあることです。
技術を使うためにシステムを作るのではなく利用者や課題の解決のためにシステムが存在するからです。
利用者からはそのシステムが何で作られてるかどうでもいいですね。利用者として求めてるのは使いやすくて早くて安定しているシステムだけですから。
何年か前に部署の名称がプロダクツ(Products)本部に変わりました。また、我々はシステムエンジニア(System Engineer)ではくプロダクツエンジニア(Products Engineer)と命名されました。
最初は何が違うんだろうと思いましたが、調べたところプロダクトエンジニアとは今まで私が主張してきた開発者の生き方の名前だったことがわかりました。
私が業務内容を覚えるのが重要だと言ってきたのがプロダクト(Product)でした。プロダクトがFirst！それを支えるのが技術ということです。
韓国のITコミュニティサイトですごくいい記事があったので、みんなに読んで貰いたくて翻訳して掲載しました。
AI時代にIT開発者が生き残るためにProduct思考というのはなぜ必要なのか一緒に考えたいと思います。
本記事は発行権、著作権を独占しているヨズムIT(요즘IT)の許可の上、韓国語の原文を日本語に翻訳して掲載しています。
ヨズムIT(요즘IT)：https://yozm.wishket.com/magazine/
記事原文：https://yozm.wishket.com/magazine/detail/2485/
------------------------------- 以下、引用記事となります。(韓国語の記事を日本語に翻訳)-------------------------------
※一部の内容・表現は読者の理解のために日本にあわせて少し変えていますが、基本的な全体の内容は原文をそのままにしました
※例文の求人情報は原文に説明された韓国の採用情報となります
AI時代に必要な開発者、プロダクトエンジニア(Product Engineer)
生成型AIの登場は既存開発業務を高速に変化させています。いつの間にかCopilotと一緒にコーディングして、問題が発生したらStackOverflowではなくChatGPTに聞いています。
楽ですが使うたびに危機感を感じます。望んでることを正確に伝えれば筋を把握して正確なビジネスロジックを数分で作ってくれます。このようにAIがバグも直してくれてコードも作ってくれる。世の中で我々ITエンジニア達はどうやって生き残るのでしょう。
私はプロダクト(Product)中心で思考して開発する開発者が最後まで生き残ると考えています。このポストではプロダクトエンジニア(Product Engineer)がどんなもので、なぜプロダクトエンジニアが生き残れるのかその理由について調べてみます。
変わっていく採用トレンド
AIの発展と共に、ある程度のビジネスロジックは要件さえ明確であればすぐコードを生成することができます。
コードだけではなく開発過程で遭遇するいろいろなエラー処理のほとんどを解決してくれます。ビジネス・インサイダー(businessinsider.com)によりますと、GPT-4が公開された以降Stackoverflowのトラフィックが約13％減少したようです。多くの開発者がAIを活用して問題解決している証拠だと言えるでしょう。
働き方でも大きな変化がありましたが、この変化の流れには採用市場にも影響を及ぼしているように見えます。一つのサービスを作って運用するには開発職群でも多様なポジションが必要ですね。大きくフロントエンド(fron-end)とバックエンド(back-end)で分かれますが、サービス規模や特徴によってはもっと細分化されます。このような理由で採用もポジション別で進行されます。
最近の求人掲載には少しずつ特異な内容があります。たまにソフトウェアエンジニア(Software Engineer)またはプロダクトエンジニア(Product Engineer)と言うポジションが募集されています。役割を見ますとサービスの集客から購買まですべての工程にインパクトを与える様々な機能を作成して主導すると言ってますね。
QUAT,WIPPYはスマホアプリの名称
単純に「特定プログラミング言語とフレームワークであるサービスの維持補修または機能を開発する」という既存の採用内容とは意味が違います。もっとも大きな違いはビジネス全工程に参加することですね。この部分をもっと深く考えてみると開発者を単純にコードを生産する人ではなくビジネス側面の成果を出して問題を解決してくれる観点で見ていることがわかります。
次の求人情報を見ましょう。ポジションはソフトウェアエンジニアです。フロントエンドかバックエンドかは言及されていません。内容を詳しく見るとその理由がわかります。
技術要素で注目すべきところはNext.jsとSupabaseです。Next.jsは最近話題のフロントエンドフレームワークです。簡単なサービスの場合はフロントエンドとバックエンドの両方を対応できるFullStack Frameworkです。Supabaseもバックエンドの開発生産性を圧倒的に高めてくれるSaaSサービスです。Supabaseを活用すればDB設計とREST APIの開発生産性を圧倒的に向上させることができます。
この2つの組み合わせであれば、ある程度の規模をもつサービスは一人の開発者で構築することが可能です。インフラ管理やAPI開発のような部分をSaaSがすべてサポートしてくれるため、開発者がプロダクトに集中することが可能です。
AI技術と共にもっと発展していくSaaSサービスにより企業の立場からは各分野別に特化した開発者を雇用する理由がどんどん減っていくと思います。これからはプロダクトの利便性や安定性はAIやSaaSに任して、プロダクトの市場性をいかに早く実験して改善していくかが成功の鍵となるためです。
上記の求人情報はその幕開けとなる兆候だと思います。
プロダクトエンジニア(Product Engineer)とは？
このような流れの中で生き残る開発者はどんな開発者でしょうか？私はこの答えのヒントが求人情報の中にあると思います。詳しく中身を覗いてみると高速に進化し続けている企業達は何を求めているかが見えてきます。
プロダクトが作れる開発者。単純にコードを生産するコーダー(Coder)ではなく集客からマーケティングを通して収益を生み出すまでの全過程において問題を解決してくれる人が時代の流れの主人公になると思います。
Shopifyの元CTOミセール・リュミュー(Jean-Michel Lemieux)はプロダクトエンジニアを下記のように定義しました。
製品の基盤が固まった以降からは技術を使って利用者の問題を突破できるエンジニアが必要になります。マジックのような経験を求める熱望があるエンジニアです。これが私の本で説明したプロダクトエンジニアの定義です。多くのエンジニアは技術に集中しすぎる傾向があります。これはいいことではありません。より高度なプロダクトエンジニア達は利用者から愛されるプロダクトを作るために製品開発過程でトレードオフ(trade-off)を考慮して適切な深さで開発すべき点をわかっています。
私も彼の意見に全面的に同意します。ChatGPT、copilot、数多いSaaSサービスは開発生産性側面では圧倒的な成果を見せてくれます。しかし、まだこの道具だけでは顧客が求めている正確な要求を把握するのは難しいでしょう。数多い仮説を検証してプロダクトそのものを魅力的に開発していく過程には、まだ開発者の手を直接通さなければなりません。
結局プロダクトエンジニアは技術に没れることなく、顧客の問題を定義し技術で問題を解決する人です。見方を変えれば創業者と似てるかもですね。
このようなプロダクト中心的な思考が可能な開発者がこれからもずっと生き残れると思います。
なぜ、プロダクトエンジニア(Product Engineer)でしょうか？
プロダクトエンジニアとはどんな思考をする開発者なのかを調べてみました。ではなぜプロダクト中心で思考しなければならないでしょうか？その理由を開発者と企業面でそれぞれ見てみましょう。
PMまたはC-Levelへグレードアップに有利です
開発者なら誰でも経歴を溜めていくうちに悩みがありますね。キャリアパスの分かれ目についてです。実務を継続してプロジェクト経験が溜まっていくと、ある時から会社からチームを任されるようになります。これは単純にプログラムがうまいからできる領域ではありません。開発者を含め、企画者、デザイナー、データサイエンティストなど様々な役割のチームメンバーを一つにして、目標を達成できるように繰り返しコミュニケーションを取りながら調整しなければなりません。
それではこのチームをどうすれば一つなりますか？その中心にはプロダクトがあります。プロダクト中心で思考することで企画者の言葉がより理解できるし、デザイナーがなぜこのようなデザインにしたかが理解できます。データサイエンティストの分析を聞いて、これからの選択と集中の方向性を決めることができます。
つまり、コードレベルではなく全体を見る目を持つことが必要になります。プロダクト中心で思考することになると木ではなく森を見る人になることです。これは完全にアナザーレベル(another level)です。単純にプログラミングで動くソフトウェアを作るだけではなく、利用者から本当に愛されるプロダクトを作れる視野を持つことになります。もちろんこういう人は滅多にないですね。会社ではこういう人にチームを任します。このようなエンジニアのポジションが主にPMまたはPO(Product Owner)になります。ここでもっと成果を出してもっと大きい組織を任されるとC-Levelへ上がることになります。
※C-Levelとは？
CEOはChief Executive Officerの略で、日本では一般的に会長の役職です。 COO（Chief Operating Officer）といえば、通常は社長のことを指します
総じて肩書きがチーフ（Chief：長）からの始まるため、経営層のことを「Cレベル」と表現します
企業が求める人は結局、問題を解決してくれる人
企業の目的はなんでしょうか。利益の追求です。顧客の問題をプロダクトを通して解決してその代わりに対価をもらうことです。そうしたら企業が求めてる人材は利益に直接、間接的に大きな影響を与える人だと思われます。
簡単に言うと、顧客の数を増やしてくれて、プロダクトの価値を高めてもっと合理的に高い費用で提供できれば企業の利益は増えます。この過程にたどり着くまでいろいろな問題点が存在します。この問題点は大体複雑で複合的です。単純に開発ができるだけで解決できるものではありません。広い視野とオープンな問題解決能力でこれらを解決できるとしたら、この人の価値は会社の立場では値をつけられないくらい大事なことですね。
反面、企画書の内容をコードに移すだけの人、管理業務の単純繰り返し作業のみの開発者はどうでしょうか？今すぐはサービス運営に必要なので仕事があるかもしれません。しかし、恐ろしいスピードで進化するAIとSaaSサービスにいつ交代されるかわかりません。企業の立場では同じ結果物をもっと安い費用で解決できるならこれよりいいことはないですから。
プロダクトエンジニアになるための3原則
これからプロダクトエンジニアになるための３つの原則について話します。プロダクトエンジニアになるために特定の技術を勉強したり、ライセンスを取ったりすることはありません。それでできるものでもありません。
大事なのは、仕事中の思考の流れを変えることです。もっと広く見て、もっと多い分野に関心を持つことです。実務に適用できるか必ず試してみる必要もあります。もっとも基本になる３つの原則を覚えて一つずつ実践していくうちに必ず大きな成長のチャンスを掴むことができると思います。
1) プロダクト全過程に関心を持つこと
企画からデザイン、そして開発に至るまで、プロダクトの全過程にWhy?という質問をしながら積極的に探求する姿勢を持つことです。誰よりもプロダクトの熱誠利用者になるべきです。単純に開発レベルのインパクトだけではなく、このプロダクトを実際に使う顧客の観点から考えられることが必要です。
したがって、顧客が最初にプロダクトに接続する時点から、使って慣れて離れるまでの全過程を追いつく心構えが持つべきです。この過程で顧客を理解するために必要な知識はいつでも学んで習得できなければなりません。
私の場合でもサイドプロジェクト(Side Project)を通してプロダクトの企画からデザイン、開発そしてマーケティングまで全領域を経験してみました。その過程で本当にいろいろなことを学ぶことができました。マーケティングをどうしたらいいかわからず、SNSマーケティング講座を聞いたり、直接SNSをいじりながら出品したアプリの1万ダウンロード達成も経験しました。デザインの品質は粗悪だけど、Adobe XDとZeplinの使い方も覚えました。サービスをローンチする前に改めてマーケティングプランを作っておくことも経験から学びました。
このような経験は実務にも確実に大きな影響を与えます。新規機能を開発するとしたら、どう開発するかではなく顧客にどんなインパクトを与えられるかを先に考えることになりました。企画とデザインの過程にも積極的に意見を出せるようになりました。また、集客についてもコピーライティングをチームと一緒に悩んだりしてました。
すべての領域で専門家になることはできません。自分の専門性を失うことを恐れるかもしれません。しかし、全過程に参加して、各分野の専門家達とコミュニケーションをしながらプロダクトを引っ張ることも専門領域だと思います。
2) Over Engineering(過剰性能)は禁物
今まで多くの開発者達とプロジェクトを進行してる中で一番困ることがOrver Engineering(過剰性能)をしてるように判断される時です。今すぐ早く仮説と実験を通して市場性を検証しなければいけない状況なのにコードレベルの設計や維持・補修を高める方向性だけ考える場合、どう説明すればいいか困ります。
もちろんコードの安定性や維持・補修を高めることは大事なことです。しかし、開発速度や維持・補修性はトレードオフ関係になります。二羽のうさぎを同時に捕まることはできないですね。もし、チームのリソースをいっぱい入れて維持・補修性が高い設計とデザインパターンを適用したコードを作ったとしましょう。この機能をリリースして顧客の反応が思ったのと異なったことでこの機能を廃止することになったらどうでしょうか？チームの立場では大きな損害となります。そのリソースを他の仮説の検証に使うこともできたかもしれません。
プロダクトエンジニアならこの2つの要素について最善の選択ができるように努力しなければなりません。早く市場性を検証する状況なのか、逆にもっと遠く見てコードの安定性や維持・補修性を高めるかどうかとなります。Over Engineering(過剰性能)に対しての基準はとっても難しいです。企業の状況によって何を優先に考えた方が効果があるかは総合的に判断できなければなりません。開発をしながらこれからは今自分の判断がOver Engineering(過剰性能)かどうかを繰り返し検討し続けてみてください。そして、悩んだ内容をチームと共有してみてください。その結果、より状況にあったいい判断ができるようになると思います。
3)Hard SkillとSoft Skillのバランス
一般的にハードスキルは業務と直接関連する能力、ソフトスキルはその他チームとして働くために必要な能力を言います。プロダクトエンジニアならこの二つのバランスがとっても重要になります。特にチームプロジェクトをためのコミュニケーション能力は高く求められますが、その理由は各パートの担当者達と意見交換を通して学びながら自分の意見を提示しなければならないためです。
プログラミングの能力が圧倒的に高くてもプロダクトを構成する他のパートの担当者達と意見交換ができず、ひとりで働く人なら絶対プロダクトエンジニアになることはできません。当然チームをリードすることもできないですね。プログラミング能力を高めることも重要ですが、もっと分かりやすく相手に説明する方法、自分が望んでること、意味することをもっと明確に簡潔した表現で伝える能力を向上させるのがもっとも重要だと思います。
コミュニケーション能力を高めるいい方法はやっぱり記事を書くことだと思います。ブログ、SNSなどを書き続けてみると確実に変化を感じられます。私の場合はブログをずっと運用していて、最近にはSNSにも記事を書いてますが、記事を書き続けていくと関連内容が頭の中で整理できることがわかります。こういった活動が蓄積していくと段々コミュニケーション能力が進んでいくと思います。
最後に
ここまでプロダクトエンジニアとはどんな物なのか、なぜこれから生き残れるかを説明しました。プロダクトエンジニアとして守るべき3原則も説明しましたが、開発者は単純にコードを生産する人ではないと思います。開発者の本質は問題を解決する人だと思います。その意味でコードレベルだけで自分の技術力を高めるのではなく、もっと領域を広げてプロダクトそのものをもっと発展できることが本当の開発者だと思います。
技術のものすごい発展の中でもまだ人間しかで解決できない領域があると思います。プロダクトエンジニになることがその領域への第一歩だと思います。
------------------------------- 引用記事はここまでです-------------------------------
開発者の本質は問題を解決する人
皆さん、いかがでしたか？AIがいくら進化し続けたとしても人間を超えることは決してできないと思います。しかし、AIはますます進化を続けていますが、我々でしかできないことはどこにあるでしょうか。最新のAIを使いこなせるよう日々学ぶこともありですが、それよりAIでは絶対できないスキルを身に付けることが一番いいですね。
リバークレインでは最新技術を追求するのはもちろん、全プロジェクトにおいて企画者と直接意見交換しながら全工程に参加しプロダクトを作っています。
顧客からのご意見を分析して活かしたり、メーカーからの要望をシステムに反映するなどより利用者目線での開発に挑んでいます。
リバークレインでプロダクトエンジニア(Product Engineer)になってみませんか？
