hikoharu's PM blog

プロダクトマネジメントについて考えていること。twitter: @hikoharu06

10→100フェーズにおける組織におけるプロダクトマネージャーの役割とは

はじめに

10→100フェーズのプロダクトに関わる中で

  • プロダクトマネージャーの役割とは?
  • プロダクトマネージャーとして資質を伸ばす、成長するには?

というのを最近考えていて、そのまとめです。

プロダクトマネージャーの役割とは?

プロダクトマネージャーの役割とは何なのか?ネットで調べたり、色々な人がよく言うのは

  • ミニCEO
  • 売れるプロダクトを見つけ出す(考える)人
  • プロダクトの全てに責任を持つ人

とかが多いかなと思います。 いずれも プロダクトの企画〜運用、全てに責任を持つ というコンテキストが見え隠れするのですが、現場で働く中であんまりしっくりきていなくて、理由を考えてみました

その1 プロダクトの全てに責任を持てない

プロダクトの全責任を持てるというのは、結構限定された状況じゃないかなーという気がしています。その状況とは

  • プロダクトとしてテクノロジーが第一の成長ドライバーとなっている
  • 組織が十分に小規模、かつ全員と信頼関係を築けている

という場合だと思います。

まず成長ドライバーがテクノロジーではなく、コンテンツ(動画、記事など)や営業パワーだったりすると、はたしてプロダクトマネジャーがそこまで権限を持てるのかという疑問があります。

当たり前ですけど、成長ドライバーとなる要素をハンドリングする人が最も権限を持つべきで、そこがテクノロジーでない場合、全責任を持つべきではありません。

もちろん、「じゃあ、どこまでがプロダクトなのか?」という疑問ももちろんあり、例えば、下記のような要素とかはグレーゾーンですね

  • コミュニティ
  • サポート
  • セールス
  • マーケティング
  • 説明文やドキュメント
  • 調達
  • リソース
  • 広告
  • コンテンツ

組織、事業の状況と何よりプロダクトマネージャーの資質、志向性によって範囲は変わりますよね

ちなみに上記とかは全部ひっくるめてプロダクトだろ!いう論理もあると思うのですが、そういう時はプロダクトマネージャーでなくプロデューサー、事業責任者というロールの方がスッキリします。

※なおプロダクトマネージャーがアジャイルでいうプロダクトオーナーに近い(要はバックグランドがエンジニア)という前提でバックログとして開発案件の管理が主業務という前提で書いています。

その2 売れるプロダクトを見つけ出すケースはそんなにない

本当に昨今のスタートアップ企業が発信力を上げているというのもあり、基本的に全て0→1前提(0からプロダクトを開発してリリースする)で語られることが多いのですが、現実世界で圧倒的に多いのは既存の事業なりプロダクトがあって、その中の1つのモジュールを新規にリリースする場合だったりするんですよね

いわばPMFには到達していて、そこからエンハンスするケース(といっても完全に延長線なわけではなく、ターゲットは違ったりしますが)

PMFに向けてひたすら全力で仮説検証を回すというよりかは、どちらかというと持続的な成長のための仕組みづくりとかの方が優先度高かったりします。

組織もプロダクトと考える https://techblog.timers-inc.com/entry/org_as_product

プロダクトマネージャーとして、どこに責務を持つか?

基本の形は下記だと思います

f:id:hikoharu06:20190108152913p:plain

個人的にプロダクトマネジメントのバイブルだと思っているInspiredに書かれたことを参考にしており

になるのかなと

自分なりの解釈ですがプロダクトのAARRRモデルにおいて

  • Acquisition(ユーザー獲得)
  • Referral(紹介)

においてプロダクトにとっての成功を定義して、実行するのがプロダクトマーケティング

  • Activation(利用開始)
  • Retention(継続)
  • Revenue(収益の発生)

においてプロダクトにとっての成功を定義して、実行するのがプロダクトマネジメント

と考えるとイメージしやすいかと思います。

事業として実現したいことがあって、その手段がプロダクト、上記2つだけだとそこに責務を持つ人がいないので、 上位にプロデューサーがいるという構図になります。

この基本形がありつつ

  • プロダクトの性質
  • 本人の資質
  • 組織的な成熟度

によって兼務したりが発生するんだと思います。 (スタートアップとかだとほぼ例外なくプロデューサーとプロダクトマネジメントが兼務)

なので、最低限

  • プロデューサーとコミュニケーションした上で、事業を理解してプロダクトのWhy,Whatを決めることができる
  • プロダクトのWhy,Whatを伝えて、エンジニアが納得感を持って開発を進められる状態にする

がプロダクトマネージャーの役割となります。

そこから資質と志向性によって、マーケティングにも手を出したり、事業戦略にも手を出したりしていくわけですね。

そして、このWhy,Whatを決める部分で いかに引き出しをたくさん持って、インパクトの強いプロダクトのWhatを定義できるか というのが プロダクトマネージャーの腕の見せどころかと思っています。

この記事のアートとサイエンスの掛け算という表現がとても気に入っています https://questpm.hatenablog.com/entry/2018/10/08/assign_priority?utm_source=feed

プロダクトマネージャーとして資質を伸ばす、成長するには?

シンプルに 打席に立つ回数を増やす 以外にないと思います。多彩な状況に置かれて判断を下していくことで 引き出しが多くなり、判断軸も出来上がっていくのだと思っています。

ということもあり、とにかく副業でもサイドプロジェクトでも、1つでも多くのプロダクトに関わってWhatを定義するということを最近意識してやっています。

ただ、実行している中でどういう打席に立つか というのは結構重要で プロダクトとしての

  • 仮説
  • 検証
  • 検証による学び

を1周しないと打席としてはノーカウントかなと思います。

要は

  • リリース前にバックログの整理や推進だけやって、リリース後は別のプロジェクトに行く
  • リリースしてないけど、ユーザーインタビューとかして仮説検証している

とかだとノーカウントということですね。

必ずしもプロダクトの一番最初の企画から関わる必要はないと思いますが、とにかくリリースして、リリース後の反応を元に試行錯誤を繰り返さないと何の意味もないと思います。 より高次元の大きな仮説に関われるので、企画の初期段階からいるに越したことはないかと思いますが

リリースすることの重要性 http://yuzutas0.hatenablog.com/entry/2018/12/25/170000

さいごに

自分もまだまだですが、プロダクトマネージャーって組織だったり、事業だったりに応じて求められるスキル、役割が変わるので、明確な定義はないと思っています。 とはいえ皆悩んでいるのは、Google先生の結果からもある程度わかっているので、 こういう場合は〜なタイプのプロダクトマネージャーが必要 というのがある程度パターンとして定義できるといいのかなと思っていたりします。

f:id:hikoharu06:20181230163025p:plain

プロダクトマネージャー目線でAdobe Max2018参加してきた

先日ロサンゼルスで開催された2018年度のAdobe MAXに参加してきたので、その感想 自分はXDやイラレをバリバリ使ってデザイン起こすというよりは、ツールを使ってエンジニアも含めて、チーム内でどういったコラボレーションをしていくかに興味があり、 またプロダクトマネージャーとしてAdobeのプロダクト、ビジネスがどういう思想で行われているかも興味があったので、そこら辺をまとめました。

Adobe MAXとは

年に一度開催されるAdobeの新製品の発表を中心にしたカンファレンスです。

カンファレンスの特徴として基調講演以外にも

  • 映画監督、アニメーターといった著名なクリエイターの講演がある
  • ワークショップなどが豊富で、Adobeの社員と共にプロトタイプ作成、各種ツールの効果的な使い方を学べる といったコンテンツが用意されています。

キーノート 会場の様子。今年の来場者数は1万4000人らしいです。 f:id:hikoharu06:20181209235631j:plain

キーノート冒頭で

Adobeのこれからの方針として

クリエイティビティが人にも場所にも、手段にも縛られないような世界にしていきたい。

一部の専門的なクリエイティブだけが使えても意味がないし、デスクの前だけ使えるのでも不十分

インターフェイスもキーボードやマウスだけではなく、音声など多様なものを用意したい。

全人類のクリエイティビティを引き出すような製品を作っていきたい

というメッセージがありました。

それを受けて、Adobeの今後のサービスは

  • ACCELERATE
  • LIBERATE
  • DRIVE の3つをコンセプトとして強く打ち出していきたいという発表がありました

以下それぞれの詳細です。

ACCELERATE

Adobeの製品を使った場合の作業スピードの高速化

具体的にはAdobe Senseiを使ったサジェスト、作業のアシストなどです。

ここ数年で強化されている点で、単純作業をツールが代行し、クリエイターが本来やるべきクリエイティブな作業に集中できるようにするというのを

今後もさらに継続していくというメッセージがありました。

LIBERATE

クリエイティブを場所、手段の制約から開放する

マルチデバイス対応により、いつでもどこでもAdobeの製品を使えるようにすることはもちろん、複数のツールを使う作業においては

単純にツールを切り替えてやるのではなく、異なるツール同士の機能をシームレスに使うことができるというものです。(PhotoShopillustratorなど)

DRIVE

AR、音声インターフェイスといった新技術への対応

スマートスピーカーを始めとして次々と新技術が生まれていく中で、

Adobeの製品を使って作れるコンテンツも、進化していく技術に対応したものにしないといけないという方針です。

キーノートでもXDで作成したプロトタイプをスマートスピーカーインターフェイスとして操作するデモや、ARコンテンツを使ったデモが行われていました。

個人的に、今回のカンファレンスで一番強く推されていたのはLIBERATEだと思っており

2019年に向けてAero,Rush,Geminiといった新製品が発表されたのですが、それらは全てデフォルトで

iPhone,iPad,PCのマルチデバイスに最適化されてリリースされます。

それぞれのプロダクトのデモがあったのですが、どれも「アイデアが思いついたら移動中など、どこでも制作できる。制作したものはリアルタイムでCreative Cloudにアップロードされるので、続きはデスクで」という価値をアピールしていました。

さらに新規のプロダクトだけマルチデバイスかなと思っていた所に、PhotoShop CC for iPadが発表されました。

どういうことかというとこれまで、30年間積み上げてきたPhotoShopを機能はそのまま、iPadに最適化した全く新しいものとしてリリースするということです。

おそらく秘伝のタレ状態になっているレガシーなソースコードを置き換えていくのはエンジニア目線からしてもとてつもなく大変なプロジェクトではと思います。Adobeのマルチデバイスに対する本気さを感じました。。。

このプロジェクトについてはAppleとしっかり協力して進めているらしく、Appleバイスプレジデントの方がゲストとして登壇し、両者のパートナーシップを強調していました。

PhotoShopの移行する機能の洗い出しの様子。わからないが大変そう、、、

f:id:hikoharu06:20181209235705j:plain

AdobeAppleが同じ壇上に立つ様子に、会場も大盛り上がりでした

f:id:hikoharu06:20181209235801j:plain

ずっとFlash時代からAdobeAppleの間にはある種の溝があったと思っていたので、感慨深い光景だなと思いながら見ていました。

セッションやワークショップなど、もうちょっとディープな情報はこちらにまとめました

https://tech.recruit-mp.co.jp/event/post-17345/

https://tech.recruit-mp.co.jp/event/post-17379/

プロダクトマネジメントにおける事業理解について、NETFLIXの事例を考えてみた

最近0→1以降のフェーズでプロダクトマネジメントする上で最も重要なのは事業、ドメイン理解だと思っています。

PMというただでさえよくわからない業務の本質は、

事業の価値や戦略を理解した上で、全体最適を維持する。 その上で、何かしらの専門性(エンジニアリング、グロースハックなど)を発揮して事業のHOWであるプロダクトを作って事業を加速させること

だと思っています。 それをするには、結局「この事業の価値は何だっけ?」、「今ビジネス的に何が最重要なんだっけ?」という問いに常に答えれないといけない訳です。

NETFLIXの最強人事戦略~自由と責任の文化を築く~

を読んで、そこら辺が書かれていて面白かったのでまとめます。

Googleとの企業文化の違い

イメージ的にNETFLIXと近い企業としてGoogleがあるなと思っていたのですが 読んでみると両者は根底の部分が違っていて

  • Googleの事業はとても多様。そして採用ではメンバーの創造性を何より重視する。アイデアを出してもらい、それを事業にできるから
  • NETFLIXは基本プロダクトが1つ。事業上必要なことが厳格に決まっていて、メンバーに高度な事業の理解と貢献を求める

どちらが優れているという話ではないのですが、NETFLIXは事業に対して必要な業務、人材の定義が徹底していると感じました

実際のエピソードとして、事業として検索に力を入れたいが、Facebook広告に固執する超優秀なエンジニアに対して、退職を推奨するという、、、 Googleとかであれば、配置転換などでやらせてもらえそうだなと

他にも象徴的なエピソードが

  • 人事考課は時間のムダ。なぜなら事業KPIのどれにも紐付かないから
  • 人事にも事業理解を求める。人事が事業理解をし、チームに必要な人材を採用する。事業が成功した時は「私があのチームを作った」と感動して号泣する

などが興味深かったです。

自由と責任と事業理解

本のタイトルにもなっている「自由と責任の文化」というのは、

  • 組織として透明性が担保された状況(全従業員が事業の現状と今後の戦略について理解している)
  • 事業理解をもとに自分のミッションの明確化(=責任)
  • ミッションを果たすために邪魔な制約は会社として全て取り払う(=自由)

ということなのかなと解釈しました。

自分の好きな技術を何でもやっていいということでは決してなく、やるべきことは事業戦略として厳格に決まっている。 そこがスタートラインにあった上で、徹底的に情報アクセスのハードルを下げて、自由と責任を持って事業戦略に基づいたミッションにコミットできるということなのかなと

ここらへんは自分のPMとしてのバックグラウンドのバイアスが思いっきりかかっているので、あくまで1つの解釈として読んでもらえれば

従業員のモチベーションは不要なのか

後半で従業員エンゲージメントに対しても真っ向否定していて、「まるで従業員のやる気不足が原因のような言い方だ。やる気のない従業員を解雇して好業績になるなら、とっくに他のところも成功している」これは「なるほど」と思うところがある一方、かなりのパワーワードだなと 笑

この背景としては、すでに上述していますがNETFLIXはプロダクトは1つ、さらに事業としてのビジョン、やることを明確にしている さらにアメリカのジョブディスクリプション文化(総合職とかではなく、明確に職務が規定されている)とも重なって、 完璧に事業戦略〜1人1人のミッションがつながっているからで、組織マネジメントの1つの完成形だと思いました。

つまりは採用のタイミングで完全にミッションが事業戦略からの逆算で決まる&人事、現場がそれを理解しているので求職者にブレなく伝えられている。 という前提になるので、モチベーションは関係ないと

日本だとそもそもジョブディスクリプションを厳格にできない、風土の問題も大きいし、そもそも厳格にしてしまうとポジションがクローズした時に解雇が発生するが それができないという事情があります。 事業理解など参考になる部分は多かった一方で、前提が違うので日本でそのままやるのは難しいなと感じました。

https://www.amazon.co.jp/dp/B07GWJCBVP/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

エンジニアでもわかる、スタートアップの株をもらう時に注意すべきこと

これは何?

最近スタートアップの立ち上げに関わることになり、ありがたいことに株をある程度持たせてくれるということになったが いかんせんファイナンス周りが全くわからないエンジニアなので、ヤバいことにならないように最低限の知識を勉強してみた

背景

知人と3ヶ月くらい、「事業やりたいよね」と水面下で色々考えていて、運良くVCから出資をもらってGOできることになった。

登記とか大変なので、知人が元々持っていた会社(塩漬けされていて、ただの箱状態)を復活させる計画で進めました。

最初こんな感じだったのを

株主 持株比率
CEO 40%
友達A 40%
友達B 20%
  1. 全株をCEOが引き取る
  2. CTOに株を付与
  3. VCが出資
株主 持株比率
CEO 70%
CTO(僕) 10%
VC 20%

ということで、上記のような形にしようとしました。

考えたこと

ぶっちゃけ10%の株やると言われても、それが高いのか低いのか全然わからない(第一印象はCEOに比べて少なすぎだろと思いました 笑)

色々考えて、出資するかどうかを決めるための論点としては

  • 出資する金額が妥当か(株を取得する時に〜十万か払う必要がある)
  • 創業者間の株の割合は妥当か
  • 出資することによるリスクはないか

があるかなと思い、各観点で起業している知り合いとかに聞きながら、考えていきました。

出資する金額が妥当か

結論としては

いくらくらい払えば、しっかり会社にコミットしていけるか

という点で決めるべきだと思いました。

ぶっちゃけこの時点では株価なんてあってないようなもので、ステークホルダーの話し合いで決まるものなので、 1円にも100円にもすることが可能です。 なので極限まで支払う金額を少なくすることもできるのですが、その時に問題になるのは

果たして1円払った株を持っているということで、モチベーションを保てるか

という点です。 他のメンバーと取得価格がそれほど変わらず、上記が自分なりに納得いっているのであれば金額は妥当と言えると思います。

創業者間の株の割合は妥当か

現状はCEOが僕より7倍、株を持っている。仮に事業がうまく行って2年後に3億とかで買収されたとして 税金とか考えないと

  • CEO:約2億
  • CTO(僕):約3000万

が株を譲渡することで現金として入ることになります。

CEOはセミリタイアが見える金額に対して、僕はマンションも変えない金額、、、 ここはかなり議論したところなのですが、結論として最初の割合でいくことになりました。

前提として、この段階の持株比率は創業者間の話し合いで決まるもの。VC、エンジェルにアドバイスを求めることはあっても、とやかく言われることではありません。

ということで話したのですが、決め手になったのが会社の資本に関するクリティカルな意思決定には2/3の株の保有が必要だということ

あともう一度調達する可能性があり、持株比率が薄まることを考慮すると70%はギリギリのラインということでこの割合でいくことにしました。

ぶっちゃけここの割合に関して正解はないと思うので、上記みたいな制約の中で、EXITなどの出口のイメージを持って、それに納得して始められるかが全てだと思います。

出資することによるリスクはないか

  • 出資した金額以上を失うことはないか
  • ロックアップなど、自由を奪われるようなことはないか

というのが怖くて調べてみましたが、考慮するのはVCが出資する際の契約書で 「数年後に買値の〜倍で株を買い戻す」とか異常なことが書かれていなければ大丈夫とのことでした。

思わぬ落とし穴

と色々書いたのですが 結果として、このスキームは使わずに新会社を登記することにしました。 理由は贈与税、、、

どういうことかというと、

  1. CTO(僕)が出資して株を取得(1株あたり10円くらいとする)
  2. その後にVCが出資する(1株あたり100円くらい計算で出資)
  3. 出資した瞬間会社の株価が10倍、つまり時価総額が10倍になる
  4. どう考えても時価よりも安い金額で株をもらっている=>これって贈与じゃね?ということで贈与税の対象になる

ということです。もし指摘されると個人で支払わないといけないので、さすがにリスクが大きいよねということで 今回新しく登記する方向で進めました。

最後に

結局は

納得感を持って始められるか

ということが全てだと思っています。 出資という形でお金をいただく以上、中途半端に途中で投げ出すことは許されないと思っているので

事業を進める中で

モチベーションが上下するであろうことを見越して、コミットし続けられるような設計をする

ということができればいいかと思います。

これからエンジニアが創業メンバーとしてスタートアップに入るということも増えてくると思いますが、 ネットで色々と調べたところ、あまりにこういったケースの情報がなかったので 何かの役にたてばと思い、まとめさせていただきました。

中小企業のM&A、留職事情について調べてみた

最近新規事業として大企業から中小企業に留職(留学の社会人版)する事業を検討していて、周辺事情について調べてみた

背景

日本に380万社あるといわれている中小企業は後継者不足がとにかく深刻。ざっと試算ではこの中で100万社ほどが 社長が60歳以上&後継者不在だと言われている。当然この中には黒字企業も含まれている

中小企業のM&Aについて

上記のような問題があるので、ここ数年で中小企業と個人のM&Aが盛んになってきた。M&Aというと企業がやるもので 数百億のディールとかイメージしてしまうが、中小の場合は数百万レベルでM&Aできるものも多く存在する。 ただ当然だけど、購入しようと思っても個人が中小企業を探すの大変だから最近多くのプラットフォームができてきている。

https://macloud.jp/

https://www.tranbi.com/

https://fundbook.co.jp/

あとはこの辺りのテーマについてドンピシャな本がある

要約すると

  • 老後不安だろうし、頑張って資本家になろう
  • とはいえ0→1企業は難しいしリスク高い
  • 飲食店経営もレッドオーシャンでおすすめしない
  • 後継者不足の中小企業を経営するのがおすすめ
  • 中小は普段大企業で当たり前にやっているような業務効率改善(Excel使うとかのレベル)ができていないから、普通に大企業で働いて自然に身についたスキルで十分貢献できる

https://www.amazon.co.jp/dp/B07C21NBMM/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

事業検討について

事業検討していく中で、それなりのキャリアの人が中小企業で働くにしても、会計、人事とかの専門知識ないと厳しいかなーと思っていたのですが、中小の業務の実情が結構レトロそうなのでいわゆる真ん中くらいの普通の層でも大企業でしっかり業務プロセスの仕組みを学んでいれば中小企業で業務改善などで活躍できるかもというのは新鮮だった

本だと上のTRANBIとかM&A仲介サイト使って探すの進めてるものの、相当ハードル&リスク高いと思うので、実際やる前に一度体験するという留職は中小側にもニーズありそう (実際、本でもリスク把握のためのデューデリジェンスと社員との信頼関係を作るためにまず2年位は役員で働くこと勧めている)

留職だと現状は大企業とベンチャーを結ぶこういうのがある。

http://loandeal.jp/

留職考える上で難しいのは、派遣元企業、派遣先企業、社員のどこにピン留めするか。 それぞれのニーズ想定すると

  • 派遣元企業

    • 中間層派遣して、メッチャ優秀になって帰って来てほしい
    • 最悪優秀にならなくてもいいから、さっさと退職させて代謝良くしたい
  • 派遣先企業

    • 大企業のノウハウ知りたい。業務改革したい
    • 後継者欲しい
    • お金はあんまりかけたくない
  • 社員

    • 経営者やってみたい(ここは老後ゆっくりしたい層と、暇だし肩書欲しいし働きたい層で結構違う)
    • とはいえ年で老後もあるし、金銭的なリスクは最小限に押さえたい

上のローンディールとかは派遣元の「中間層派遣して、メッチャ優秀になって帰って来てほしい」にフォーカスしてる気がする(しかもメインターゲットは30代)。 中小企業の後継者不足&黒字倒産にピン留めするならどういう座組みがいいか要検討。

エンジニア組織における組織開発について

先日会社でこんな感じのイベントをやってきました

https://tech.recruit-mp.co.jp/event/post-16667/

ぶっちゃけ転職して今の会社に入るまでは組織活性、組織開発という言葉も知らずにひたすら

  • 雑談大事
  • 1on1大事
  • メンター大事

みたいな戦略なき根性論みたいなことしかやってこず(それでも一定の効果は出ていたと思う)、しっかり組織開発について自分でも学んでみました。

イベントの趣旨として、実現したいのは開発組織におけるあらゆる知見がなめらかに循環する世界で、 中でもこのイベントの中でも参加者の1人が言っていて印象に残っているのがエンジニア組織は組織開発のsandboxということ エンジニア組織は規模もそれほど大きくないことがほとんどだし、エンジニア自身が勉強熱心で流行りに敏感だし、変化の許容量が大きいので最適だと、確かにその通り

ただ現状の問題として大体会社ごとに1つしかsandboxを持ってなく、そこへのcommitログが公開されておらず他社から見れないこと それにより、ある場所で起きているrevertとか、他の場所でも全く同じこと繰り返したりしてる ここらへんを循環できるようにしていきたいなと

最終的には別に他の会社のsandboxにcommitしてもいいと思うし、お互いのログを見せ合うことでかつてないほどお互いのコアな部分を知り合うことができると思っているので その関係値を利用した、施策とかが行えれば面白いなと思っています。

アジャイルについて最初に知るべきことだけをまとめてみた

今の副業してるところが本格的にフルコミットのエンジニアと学生インターン数名で開発組織を作ろうとしていたものの アジャイル開発について開発フローも何もかも全然わからんという状態だったので、 とりあえずアジャイルサムライとかScrum Boot Campとかエンジニア組織論への招待とかは読んでもらうとして

最初に知るべきことだけをまとめてみた。

  • 歴史
  • アジャイルに対する誤解
  • 目指すべきところ、そのために明日からやること

という構成に

特にこだわったのはアジャイルに対する誤解のところ

これだけ色々なところでスタートアップやっているアントレプレナーやエンジニアがいる中で アプリの開発について色々聞いたことや、ちょっとググって色々な資料が出てきたりする。

大体開発やったことない事業サイドの人だと、それらの情報から間違った開発フローのイメージ持って 突き進んでしまうなと経験的に感じているので、歴史的経緯と誤解を解消して事業サイド、開発サイド もゼロベースでスタート地点を合わせてこれから皆でインプットして健全に議論しながら 進めていこうというところを目指してみた

https://speakerdeck.com/hikoharu06/aziyairudeiketerutimuru-men