はじめに
どうも、鳩胸になりたい文鳥です。
AIがコーディング補助としてはだいぶ定着しつつある開発現場ですが、
後発のSaaS(2020年以降)でパフォーマンスを出している開発組織について調べてみた。
エンジニアが事業戦略を知っている必要がある・小さいチームは強いと思いましたので記事を残しておくことにしました。
ここでのコンテキスト、成功している開発組織とは、
- ローンチ数年以内にサービスが爆発的に使われるようになった事業会社の開発組織
であり状態であり、いわゆる受託開発での、高速にプロジェクトを推進したとか、短期間に多くの機能を作ったか！？というところは指標にしていません。
ポエムです。
悪しからず。
Cursor
エンジニアなら馴染みが深い人も多いであろうCursor
創業3年目にしてARRは脅威の150億円越え直近で20000%の成長率だそう。
これは歴史上のSaaS市場で最もクイックに成長した記録だそうでOpenAIよりも早いそうです。
どんなプロダクトなのかはこちらに記載しました
Cursorは12人のエンジニアと研究者しかいない
いきなり衝撃的だが、Cursorには12人の社員しかいないそうです。（半年前の話なので今はもう少し多いみたいですが）
Cursorは2022年にMITの学生起業で始まっているという点についても驚きがあったポイントであります。
なんでそんなに人が少なくて事業を回せるの？
中の人が優秀だからに決まってんだろ
という声が聞こえてきますが、それだと学びがないので少し考えてみました。
ドメインエキスパートとユーザーと開発者が全部一緒
Cursorは、統合開発環境であり、メインユーザーは開発エンジニアです。
おそらく12人全員が同じコンテキストを共有できているため意思決定がスムーズでしょう。
- ユーザーインタビューをしなくてもある程度
ツールの問題点を開発者自身が即座に認識できる - 「自分が使いたいツール」という視点で機能を追加・改善できる
という点が高速にサイクルを回すことを可能にしていると思われます。
いわゆるwrapper Appである
Cursorはモデルを独自実装せずに、OpenAIやClaudeのモデルを利用していることで実装コストを格段に減らしています。
加えてCursorは現時点でのデファクトスタンダードであるVisual Studio Codeをフォークして作られたアプリケーションです。これはユーザーが慣れ親しんだUIを支えるだけでなくMicrosoftの協力なエコシステムを使いまわせることで実装コストは格段に減っているでしょう。
細かい点ていうと、クラウドインフラ、支払い処理、顧客サポートなどは全て外注して自分たちで機能を持っていないようです。
つまり、Cursorの創業メンバーはAI時代のつるはし売り戦略を最も成功させた起業家であると言えるでしょう。
ChatGPTが登場した頃に、これを使って自分のビジネスに活かすことができないか？と考えた人も多いと思いますがCursorのCEOもそのうちの1人だったというわけです。
Cursorは本家OpenAIを超える？
$100Mの到達が市場最速ということで、さらなる成長が見込まれますが、OpenAIやビッグテックの規模まで成長する可能性は少ないと思います。
今の事業内容だと、用途がエンジニアのみに限られており最大数が限定的です。
エンジニアもそのうち駆逐されるかも...
で初速を出すには？
結構用途が限定的なSaaSとして史上最速の成長を遂げたのは
- コアな提供価値部分は持たない作らない
- 巨大な投資を受けている既存の物を組み合わせてビッグウェーブに乗るが自分たちでは作らない
という部分が大きいです。
が他にもそのような戦略をとった企業がある中でCursorが突き抜けているのはやはり、
作り手自身がユーザーでありドメインエキスパートである
という点がいかに起業後数年単位での初速を生むかということを証明している気がしました。
Bill One
by Sansan
Bill OneはSaaSサービスの中で国内最速の成長を遂げているそうです。
受領した請求書PDFを取り込むと勝手に仕分けが終わってる！！みたいなサービス（のはず）
たまに導入してい会社の人の話を聞きますが、管理会計や支払い業務がとても楽になったと聞きます。
Bill One の開発組織
初期開発時
- 4人
ピボット→ローンチ→ローンチ半年後でMRR500万円
- 発起人の会計担当（ドメインエキスパート？）
- 営業担当
- 開発責任者
- エンジニア2名
エンジニアは開発責任者含め3人体制というミニマム構成。
Cursorでも思いましたが人が少ない!
記事の中で印象に残るのはところが色々あります。
チーム体制は、発案者である経理出身の事業責任者と、最初からいた業務委託のエンジニア、そして私と、同時期に加わった営業メンバーの4人
社長と、ビジネスサイドの責任者と、エンジニアの責任者である私の3名で、週に1回ミーティングをしていたのです。
少なさ以外に目につくのが初回のチーム体制についてエンジニア２名という点だけでなく事業責任者・営業を含めているという点です。
一般的な組織では開発組織・プロダクト組織・営業組織・マーケティング組織のように分けてチームの外の人として意識することがあると思います。が、BillOne組織では、事業に関わる人全員をチームメイトとして認識しています。
「売れないプロダクトをつくるのは、もう絶対に嫌だ」と全員が固く決心していたのです。この思いが、エンジニアの責任者である私にとっては、機を逃さず大胆な意思決定をする勇気につながったし、メンバーにとっては、売れるプロダクトをつくるために職域を超えて必死にコミットするエンジンになっていました。
エンジニアが売れるかどうか？使われるかどうか？を重要なミッションとして開発していることがわかります。
依頼された開発タスクを捌くのがエンジニア！という雰囲気を全く感じません。
全員が「このコンセプトでいく、機を逃さなければ絶対に売れる」と合意しました。そして「ゴールデンウィーク明けには絶対にローンチする」と決め、開発を始めました。
ピボット後ということで、かなり心理的にも肉体的にも負荷のかかる業務だったのではと推察されますが、開発前に「これを出せば売れる！」というコンセプトレベルでエンジニアも合意していたことがわかります。
世界一の初速・日本一位の結果を出す組織とは
- 作り手に親和性の高い事業だとめちゃくちゃ早い
- 自分たちの付加価値の部分以外は作らず巨大エコシステムを利用する
- 人数が少ないとコミュニケーションコストがない
- コンセプト的に売れることをチーム全員が確信してからスタートする開発組織は強い
ということがわかりました。
自分なりに咀嚼するポエムタイム
なぜ人数が少ないのに早いの？という疑問
色々考えた末に、人数が少ないからこそ早いのだと言う結論に至りました。
そして小さいチームを成立させるには事業戦略をエンジニアが上手く理解できていないといけない。
中締め
- AIが作業を高速化した結果ひとりでできる作業量が増えている一方、人間 vs 人間の情報の受け渡し、認知負荷が相対的に上がりボトルネックに
- 大人数の人間がやり取りすればするほど遅い
- お互いのコンテキストが遠ければ遠いほど意思決定にかかるコストが大きい
- AIが旧来の職能の境界を破壊しているので、スキル別部門のミッションを持つ意味が薄れている
- むしろコンテキストの違いを産んで意思決定を遅らせる要因になりうる説
- プロダクトコンセプトにエンジニアが関与して腕利のエンジニアと少人数のチームを編成すると数ヶ月でMRR500万のサービスが完成する
書いてる途中にこれって
に書いてたことじゃね？ってなったのでここまでで記事の内容について面白いと感じた人は読んでみるといいかもしれないです。
これ以降は、0→1ではないプロダクト組織にどう適用するべきか？
やAI時代のボトルネックについて考えてみました。
が、まとまりがなくなってしまったので読んでもあまり有益なことは書いていません。
まとめきれず何度も同じような話が出てくるので誰か短くまとめてくれ
AI時代のボトルネック
AIを使うことによってコーディング作業効率が上がっていますが、万事解決！
というわけではありません。
競合他社のエンジニアも平等にAIを手にするのでAIが使いこなせるという点において優位性はありません。
ただAIが使いこなせない企業は淘汰されていくかもしれないです
ソフトウェアエンジニアリングにおいてgitやGithubの登場によって並列作業がし易くなり、作業効率が上がったことで、プロジェクトリードできるエンジニアにレビュー負荷が集中して、最もコーディングパフォーマンスが出せる人間がレビューに追われてしまうというボトルネックについて過去に記事を書いたことがありますが、
github時代の新たなボトルネック--プルリクエストのレビュー
個人的にはgitの登場以上にパラダイムシフトとしてのインパクトが大きいと考えています。
これからのプロダクト開発におけるボトルネックについて考えてみました。
AIを用いた業務で何が変わった
私は大きく2点であると考えています。
専門知識が民主化された
各個人単位の作業スピードが向上した
その結果、ある分野において一般論を知りたい場合に、それを専門とするチームの意見を聞くことなくクイックに情報を得ることができるようになっています。
作業が高速されたことによって、相対的にプロダクト固有の知識やアクシデントに対する対応について考える比率が相対的に長くなっています。
ここで
- 事業に関するコンテキストを持っているか？
- 自分で決められるか？（意思決定する権限・能力）
かどうかによって決定のプロセスが変わります。
他人と意思決定について協議を行う場合、決定できるまでのランタイムはコンテキストがどれぐらい離れているかに依存します
AIの補助によって実装がサクサク進むため、エンジニア自身が決められる範疇が多ければい多いほどタスクがどんどん進みます。
逆に合意すべきステークホルダーが多い場合はこの調整コストが大きいです。
作業部分のスループットが早くなった結果人間 vs 人間のコンテキスト理解がボトルネックなのではという話をします。
モノリスな組織構造
L 営業本部
L プロダクトA
L プロダクトB
L マーケティング本部
L プロダクトA
L プロダクトB
L CS本部
L プロダクトA
L プロダクトB
L プロダクト本部
L プロダクトA
L プロダクトB
L 開発本部
L プロダクトA
L プロダクトB
のように組織体制を組んでいるとします。
この事業本部レベルでそれぞれ違うコンテキストを持っていて、ミッションを持っているとします。
営業本部 > 成約率を上げたい！
マーケティング本部 > 広めたい！
CS本部 > チャーン抑止！
プロダクト本部 > 売れる機能を増やしたい！
開発本部 > インシデントを減らしシステムパフォーマンス改善したい！
全社ミッションなどは共有されていても、この事業部レベルでの目標意識が強すぎると
何か物事を決めるときにズレます。
そのズレが大きすぎると
「うちの営業はシステムのことをわかってない」
「エンジニアは機能を作りたがらない」
「不要な機能ばかり作っている」
「既存顧客が困っているのに新規プロダクトにリソースを割くなんて！」
みたいなハレーションが起きるんですね。
バルス
また、このような組織で働いている時、職能で別れた部門の意見として他部署と調整する必要があり
ビジネスサイド ↔︎ PdM ↔︎ director ↔︎ EM ↔︎ 作業を行なっているエンジニア
のような情報経路を持っている場合があります。
意思決定できない人たちでのコミュニケーションがある
エンジニア「ここの仕様について〜だと思うのですがいかがでしょうか？」
エンジニアリングマネージャー「デザイナーに相談しましょう」
デザイナー「（ビジネスサイド or POに）ちょっとチームに持ち帰って返答します」
みたいな会話の頻度が多い組織はかなり黄色信号が灯っています。
こんなやりとりをしているうちに
プロダクト視点を持ったエンジニア組織（CursorやBillone）がガンガン開発を進めています。
どちらがアジャイルかは明白でしょう。
スクラムのつもりが短期スパンウォーターフォールの社内受託みたいなやつ
ここ５年ぐらいでPdMという職種で働いている人が増えた気がしますが背景としては、WebシステムやSaaSを取り巻く環境の変化にあると思っています。
『アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明』は不明瞭 ~書籍「Impact Engineering」を読んでみた感想 ~
こちらの記事に書いたのですが2010年代中頃ごろまで各業務分野・事業ドメインで早いもの合戦が繰り広げられました。この時期は市場で求められてるものが不明瞭で、とにかく早く世に出して、素早いフィードバック↔︎改善のサイクルを回すことが求められました。
それ以降は上記のように様々なサービスが登場して
システム開発は性質上不確実性の高い活動で有ることに変わりはない一方で、適切に聞き取りすれば、昔に比べればより解像度高く自分達の課題を表現できるようになっているでしょう。
Webシステムに期待する水準が昔よりも高い。
顧客の要望は複雑化している。
なぜなら、シンプルで費用対効果の高い分野・領域からシステム化されて行っているので、後発のプロジェクトは、大企業の隙間を縫いつつ、既存のシステムに勝る付加価値・品質の高いものを提供しないと市場から見向きもされないようになっているでしょう。
早い者勝ちであるには変わりないものの、20年前に比べると、競合分析に時間をかけて、最初から顧客の心を掴むシステムを作る必要があるでしょう。
こうした時代背景からか、エンジニアとビジネスサイドの間に入って
プロダクトの価値を定義しニーズの要求に答えるために優先度をつけて意思決定する人的な位置付けでプロダクトマネージャーという職種のニーズが高まったのだと思います。
Figmaの功罪
プロダクトへの期待値が高まりニーズが複雑化したことにより、PdMやデザイナーの意図を正確に伝えるためのソリューションとしてFigmaがとても人気になってきています。
「作業者」としてのエンジニアにWhatをグラフィカルに伝えやすくなった一方で以前に比べて、開発エンジニアが「顧客課題に対してどうソリューションを提供するか？」を考える機会は減っている気がします。
なぜ、この機能を作るのか？をすっ飛ばして
「figmaの通りに実装すればいい」という意識なってしまい
この機能はどのように拡張していくのかが考慮されづらくなっている側面があるのではないかと思います。
- プロダクト視点を持つエンジニア
「ユーザーの快適な移動手段を支援するため実装していて日々変化するニーズに応えよう。今は自転車」 - 社内受託エンジニア
「Figma通りに自転車を作っている」
このような意識がある時、内部の部品として再利用し易くなってるかどうかに差が出ると私は思っています。
上記は強引な比喩ですが、エンジニアが事業戦略を理解している場合、内部設計がより未来の事業展開を円滑するような設計になります。
短期的なアウトプットを意識するがあまりディレクターがツッコミどころがないFigmaを用意し、
コミュニケーション頻度を減らして実装時間を増やすという戦略は短期的には有効だと思います。
しかし、そのスムーズさは将来の変更容易性を犠牲にしているかもしれない。ということに注意する必要があると思いました。
次の展開が読めていない状況で書かれたコードは拡張性に問題を抱えて負債化する。
「いきなりそんな方針転換されても」
「無茶振りだ」
と言ってるエンジニアくんですが実は自分が実装に終始するあまり、機能開発の中長期的なスコープを含められていなかっただけかもしれません。
そもそもプロダクトマネージャーやデザイナーの仕事はそんなものではいという怒号が聞こえてきておりますが、うまく行ってないチームのポジションと役割はズレているものです。
このような状況でやれスクラムだアジャイルメソッドだ！などと言っても無意味
戦略レベルの意識付けがうまく行ってないところにFWを用いても空回りするだけでは？と最近思うようになりました。
アジャイルメソッドの運用がうまくいってないという話は深ぼっていくと戦略レベルで上手くいってないということも多いです。
戦略レベルの失敗を、戦術レベルで補うことはできない
という状況かと思います。
エンジニアに事業戦略が浸透していないまま、戦術であるFWを用いたところでカバーできない。
よってエンジニアが事業戦略を知っているかどうかは、変更容易性に寄与し将来の負債になるかどうかに関わる。
これは迅速に変化要求に答え続けるために重要なファクトであると考えるようになりました。
コードの負債を過去プロジェクトに関わったエンジニアのスキル不足帰結するのは簡単で全員が納得しやすいが実は生んでいるコードも将来見たら負債かもしれないです。コンテキストが違うから。
技術的負債という強者
短期スパンウォーターフォールに現実を突きつけるのが技術的負債です。
まず技術的負債はスプリントの進行中に判明することが多いです。
そのスプリントを失敗に終わらせるだけでなく、技術的負債には次の特徴があります。
- 将来のタスク見積もりを困難にする
- 深刻度がエンジニアにしか判別できずエンジニアですら解消にかかるコストが読めない
- 代替案の正当性検証に時間がかかる
- エンジニアに事業戦略が浸透していない場合は誰もトレードオフを図ることができない
- 代替案の正当性に関わる裏どりをするため何度もコミュニケーションの行き来が発生する
PdMやPOにとっては、優先度順にタスク着手する阻害要因になりチームにとって計画進行だけでなく時に計画自体を作成困難にします。
また、根本的には技術的負債が理由でコンテキストにギャップが生まれハレーションを起こし実際に退職にまで至る
例を何度もみてきました。
技術的負債を訴えるも全て後回しにされるがために諦めて退職に至るエンジニアの図
Billoneの例では
その結果、それまでに積み重ねた負債を返済する必要もなくなりましたし、新しいコンセプトに合わせて高速に開発を進められました。
とあります。
それだけプロジェクト進行に技術的負債が与える影響は大きいのだなと改めて思いました。
技術的負債
↓
仕様変更
↓
フィグマ修正
を繰り返すよりもメンバーが新しくなってコンセプトレベルでの変更が行われた時には、l新しく作った方が早い場合もある。というは先人の知恵だと思いました。
正しく現状を理解しないままのリプレイスは負債Ver2になるという地獄もあるわけですが
リファクタリングするにしてもどこの部分のリファクタリングに時間を割くかというのは将来の変更頻度に依存して重要度が変わるのでやはり事業戦略を知ることが大切だと思いました。
極論、永遠に一切仕様変更の見込みがない機能の場合はクソコードのまま置いておくのが最適解になり得るからです。
意識ズレてるならみんなで話あって情報を共有しよ！という悪魔の言葉
人数が増えるとコミュニケーションのパスが増えるためよりアジリティが低くなります。
人間は複合的な因子を組み合わせてトレードオフを判断して意思決定
ということが苦手なので自分たちのミッションに直接関係ない情報が増えると意思決定の鋭さが著しく無くなるということです。
そもそも組織設計の本質は最短でミッションを達成するために知らなくていい領域・階層の情報を遮断するということなので、みんなで共有！は基本的に悪手です。
みんなで共有が最適解であるならば部署を設けず唯一のスラックチャンネルでやり取りするのが良いということになりえます。
(そんなはずはない)
問題はAIが業務パラダイムを起こし業務と組織設計が合わなくなっていることであり、闇雲にごちゃ混ぜに共有すれば全知全能のスーパーマンが現れて全て解決してくれるということではない
これからの開発で新規事業以外でどうすれば早くなりそう？
専門性で分けたチームを組み疎結合に機能を提供する価値が薄れている場合があります。なぜならAIを用いることで他部署の専門分野をそこそこ知っている助手が無限にいるような状態になっているからです。
よって、AI登場以前に比べて、いわゆる本部レベルの分割の意義が薄れています。
AIによって専門性の民主化が起きているため境界が曖昧になっているからでもあります。
個別事象の意思決定のために人間が人間にSyncするコストは相対的に上がってます。
同じコンテキストを持てる粒度にチームを小さくすることが必要ではないかと思いました。
つまりマルチプロダクトのプロダクトベース、もしくはメイン機能群でモジュールとし大きく切ってから中に多職能のチームを編成するということです。
L プロダクトA（モジュール）
L ビジネスサイド
L プロダクトサイド
L PdM
L デザイナー
L エンジニア
L プロダクトB（モジュール）
L ビジネスサイド
L プロダクトサイド
L PdM
L デザイナー
L エンジニア
正直このモジュールの単位はプロダクトのフェーズによって異なると思うのと、BillOneの例はローンチ前だからできたという側面が大きいと思うので、営業とエンジニアをごちゃ混ぜに考えるというは現実的ではないかなと思いました。
画一的にこう分ければコミュニケーションがうまくいく！みたいのはなくて
ここの仕様どうしましょう？
「チームで相談します！ちょっと確認して返信します」
みたいな会話が頻繁にチームを跨いでいる時、チームの境界線を見直す必要があるということなのかもしれないです。プロダクトの大きさや組織の大きさ、事業特性を踏まえて深く観察し続ける必要があるのだと思います。
マルチプロダクト戦略のど真ん中を担う。SmartHRカスタマーサクセスの新しい挑戦
SmartHRがBiz/Tech問わず組織再編系の情報発信をしているのを目にしますが、急激に成長する組織を絶えず観察し、人間が認知・コントロールできる粒度に切り出していくみたいな作用がうまく働いているのだなと思いました。
前提として、「基本機能」はかなり大きなプロダクトで、提供している機能も「申請機能」「給与明細」「従業員情報管理」「履歴管理」など多岐にわたり、すべてを詳細に把握することは認知負荷が非常に高いです。
開発チームの担当領域を狭めることでビジョンや目標を定めやすくすることと、担当領域の解像度をあげて顧客価値を最大化することを目的
かなり昔の記事のようなので今の組織図とは違うと思いますが、
認知負荷がボトルネックの原因になる
そのために、チームを切りだす
ということを前から行っていたことが伺えます。
これはプロダクトが肥大化してきて、モジュラモノリスに切り出す行為に似ているなと思いました。
人間の知識優位な時代に人間が得意分野で専門職となり
横長d疎結合さを持って専門機能としての本部を構えていたが
今後はより小さい事業に分けて事業ごとに独立したモジュールの中でコンテキストを合わせてミッションを遂行する組織がサイクルの速さ優位に立てるのかなと思いました。
仕事の進め方も変わるかもしれない
AIがさらに発達していくと
職能の境界がどんどん薄れて、特に新規開発のフェーズでは
そのうちfigma書けばコード生成できるようになるはずだし
業務の範疇が変わって受け渡しする位置が変わっていくだろうなと思います。
コードレビューひとつとってもコーディングを統一するためのツールが発達して、AIがコーディング自体を支援してくれるようになった今、10年前よりも各PR単位でのコードのユレは少なくなってるでしょう。
当たり前のように
「PRの説明欄は誰がみてもわかり易く構造化して書きましょう。」
みたいな文化を是として見ていましたが、
チケットを読んで意味がわからないレベルに業務が遠い人が他のエンジニアのタスクのコンテキストを正確に伝え、それを把握してレビューするという行為で得られる恩恵が昔より少なくなっているのではと思うようになりました。
業務の近い人間がチームとなりレビューもチーム内で行う方がいいのかもしれないです。
一人にレビュー負荷が偏らないと品質を保てないとすれば、負債が大きすぎるか採用活動の敗北を意味するのかもしれないとも思います。
これまでよしとされていた仕事のやり方が悪手になる日が来るのかもしれないです。
それぐらいAIが作業を高速化した影響が大きいとも言えるでしょう。
こんなところでも人の認知負荷の相対的増加の影響が見られます。
基本的にボトルネックを解消すると別のところに皺寄せがくるので、業務の移り変わりを深く観察して、より良いやり方に変えていく必要があるのだなと思いました。
チーム編成のまとめ
- プロダクト別や機能群での縦軸組織からモジュラモノリス的な組織へ
- チームに複数職能（スキル）の人を置く
- チーム内のミッションは同じ
- 戦略を共有して、各個人が裁量を持つ
組織をモジュラモノリス化した方が力が出やすそう。
チームが1番ということですね。これをチームトポロジーでは非常に重視しています。先程の例のような職能別、スキルで分業するようなチーム構成だと引き継ぎや受け渡しが多くなってボトルネックが生まれやすいのでデリバリーが速くなりません。
先程もお話したように素早く安定的に価値が届けられるアーキテクチャを実現するには、それにあったチーム構造にする必要性があります。この帰結として、価値をデリバリーする上ではチームが一番大事という話になります。個人よりもチームの方が大事である、ということですね。
権限やスキルを持ったチームは受け渡しや引き継ぎを必要とせず、自分で判断をして進められるようになるので、いわゆるアジリティが上がります。これはアジャイル開発でも良く言われることで、そのチームがエンドツーエンドでデリバリー出来るようになるとフローは非常に速くなります。
今の複雑で変化の速い世の中では、コマンドコントロールで誰かの指示を待っていても正しい答えは得られない上に時間が掛かります。重要なことはチームが自律的に仕事することです。ということで個人ではなくチームを基本的な構成要素として扱います。個人の成果達成ではなく、チームの成果達成、ビジネスとしての成功が大事、ということです。
結局チームトポロジーみたいな話になってきた。
はじめにチームトポロジー読んだ時は解像度が低かったなぁ
AIが出てきて1エンジニアでもわかるほどに問題が顕在化してきたということなのかもしれない。
無理やりまとめに入る
Billoneの例に学ぶと
- チーム内でタスクが完結できる状態を作る
- 職能別のチームから脱却？
- 運命共同体：プロダクトの成功がみんなの成果
- コンテキストを一致させる
- エンジニアが事業に深い理解を持つ
- 自分で決める覚悟
- 勇気ある撤退
というのがハイパフォーマンスのチームの形の一つなんだなということに落ち着きました。
積まれているバックログを消化すれば絶対に勝てる
というレベル戦略が練られていなければ、なかなか勝てないのかもしれないとも思いました。
最近では、AIをいかに自分のプロダクトに組み込むか？というのがトレンド化していますが、こう言った開発においては日々AIを使って業務をしているエンジニアの目線をプロダクトに組み込みやすい状況にあると思います。
こんなこと言うと元も子もないですが、優秀な人たちだからこそ成せる技なので
強い意思決定ができる判断材料や思考プロセスは個人として磨く必要があるし、
なんだかんだ「今チームにどんな人が必要か？」を言語化して実際に口説き落とせる採用力もかなりプロジェクトをうまく推進するための重要な要素だなと思いました。
Bill Oneの元記事はチームの編成にも触れてるのでぜひ読んでみてください。
あと、この記事のここまで辿り着いた人はチームトポロジーも呼んでください。
自分のなりふりを考えるマン
知識を大量に保有して一般的なこと言うポジションはAIに代替される。
小手先の知識を並べられても事業を成功させるための意思決定できないなら自分に価値がないのと同じ
ということを心に刻んでおこうと思いました。
タイトル決めてから書き始めると中身が全然あわんなるでぃ