こんにちは、AI Shiftの青野(brn)です。
この記事はAI Shift Advent Calendar 2023の23日目の記事です。
株式会社AI Shiftという会社で開発責任者というロールで働いています。
こんな人間です。
株式会社AI ShiftのAdvent Calender 23日目です。
前回はbunの中身を覗いてみようという内容を書きました。
今回も何かテックな記事書こうかと考えていたんですが、1年間ほとんどAI Shift内でコードを書いていないので、今回は少し別の視点、自分が今考えている事をアウトプットしようかと思います。
さて、自分は今はEngineering Manager + Product Manager + CTOのごちゃ混ぜのようなロールをしているので、それぞれを深掘りしている方とはちょっと違う視点からプロダクト・開発・組織について書けるのでは無いかと思っています。
ただ非常に申し訳ないのですが、今回のブログは自分の感じていることを主観で書く記事になっており、あまり具体的に何をやっているかは書いていないです。
あくまでポエムの一環としてお楽しみください。
AI Shiftでは以下のプロダクトを提供しています。
まず弊社では以下の4プロダクト提供しています。
AI Workerに関してはまだロゴが未確定ですが、このようなプロダクトです
AI Shiftでのプロダクト開発フェーズと意識していること
まずAI Shiftでのプロダクト開発ですが、新規で開発する場合は大きく以下のような流れになっています。
立ち上げ
経営ボード内でプロダクト案のブレストや実現可能性のブレストを実施。
-
ブレスト
まずは基本ですが、どんな突飛なアイディアでも出してみることが大事だと思っています。変なアイディアでもどんどん出すことで、重要な事や、違和感に気づいたりすることが多いです。
これを実現するために重要だと考えているのが、組織内の心理的安全性です。
突飛なアイディアでも否定ではなく受け入れをする下地ができていないとうまくやるのは難しいですし、アイディアの良し悪しよりも全員で思考のプロセスを共有することが重要なので、とにかく意見を口に出してみる、思考を口に出してみるのが重要だと思っています。 -
収束
ブレストから収束に向かわせる必要があるので、実現可能性・市場でのわかりやすさ、組織との親和性を考えてアイディアをまとめていきます。
特に自分たちの組織が持つ特性(ビジネスの方向性、顧客、メンバーの能力)と事業がちゃんとマッチして加速できる事業なのか、またメンバーに対しても説明できるわかりやすい形にできるか、といったことを考えています。
プロジェクト化
プロジェクトメンバーと事業責任者、ボードメンバーでブレスト、PEST分析やSWOT分析など、主にWhatの部分を考えるフェーズとなります。
ここからは実際にプロダクトマネージャーの仕事のような内容になっていきます
- ヒアリング
弊社の既存のお客様に新しいアイディアについてヒアリングしますが、やはりモノがない状態でワイヤーフレームやデザインだけをお見せしての説明になるので、お客様の意見の確信度も低くなってしまう可能性が高いです。
特にポジティブな意見は危険です。が、ネガティブな意見は結構参考にしたほうが良いかなと感じています。
また、SWOTやPESTに関しては情報の整理としての意味合いが強く、実際にそこで新しいことに気づくということは少ないと思っています。
どちらかというと経営陣の考えとプロジェクトメンバーの考え、思考プロセスを整理することに使っています。
開発メンバーでの実現方法検討
主にhowの部分や懸念の調査等を実施するフェーズです。
実現にあたってDesignDocs等を起こしていきますが、個人的には以下の形で進めています。
- DesignDocsで記述するGoalの整理
- 経緯の記述
- 概要的な実現方法の記載
- 使う技術の詳細までは踏み込まないものの、ロジック・データの流れ等はある程度記述する
- 問題点の提起
- 実装フェーズにならないと解決方法を考えるのが難しいような内容・考えきれていない箇所を記載する
DesignDocsで重要なのは、DesignDocs自体を進化させていくことと、何を考えて・何を考えていないのかを記載することだと考えています。
開発開始
開発チームで開発を開始します。
弊社はスクラムでの開発を行っていますが、きっちりスプリント単位で成果を届けるという形にはなっていないことが多いです。
ここは課題かもしれないですが、そもそもスクラムを続けるかということも検討すべきかなと考えていますが、ここは今回の記事では触れません。
事業展開の上での開発責任者の動き
AI Shiftでは個人的に以下の動きを意識しています。
プロダクト開発開始
自分が設計の叩きをつくって、メンバーに共有しそこから色々詳細に考えてもらっています。
基本的には大枠を示したDesignDocsを作りますが、細かいところは変更してもらう前提で考えています。
ただし、技術的に困難なポイントや他のサービスの知識が必要なポイントは自分で実際にプロトタイプを作成して確かめます。
走り出し
開発開始時点では結構要件で色々考える必要があるポイントや、矛盾点の解消に時間を使う必要があるため、主にそこに時間を割きます。
開発チームがある程度安定して走るまでの補助輪みたいな役割ですかね。
中盤
この辺では自分は次の仕込みや、別のプロジェクトに時間を使うことが多いです。たまに軌道修正することはあるものの、優秀なテックリードと優秀なメンバーがいるので、安心して任せています。
リリース前
このタイミングでまた中身を見に来ます。
個人的にはUXの辺りを部外者の目線でもう一度確認して、自分が設計した場所も他人事のように指摘します(本当は謝りながらですが..)。
バグもそうなんですが、開発の過程でどうしても開発チームの都合でUXが落ちる箇所が発生してしまうのでそこを解決する方法を一緒に模索します。
で、QAが済めばめでたくリリースとなります。
結構重要だと考えているのが、できるだけ自分の手が空いている状態を作ることです。
経験上忙しくプロダクトのアレコレをやっている状態というのは実はあまり健全ではない状態が多く、責任者は手が空いていて次の次くらいを考える余裕がある状態が望ましいと考えていますが、現実なかなか時間は取れません..
プロダクト作る上で意識していること
自分がプロダクトを作る上で意識していることです。
作らないこと
基本的にプロダクトというものはどんなものでもリリースされた時点から負債の蓄積が始まります。
そのため本当に何かを解決する・価値を届けられるものが提供できない限り機能を追加したり、プロダクトを開発すべきではないと考えています。
何も作らなくても課題を解決できればそれが一番いいとすら思います。
要望の裏を考える
これはまあ基本的なことなのですが、お客様の要望はとてもストレートに必要なものを実現する手段なので、我々プロダクトサイドでは常にその要望が実際には何を実現したいのかを意識する必要があります。
額面通り受け取らずに、もっと深掘りして本当に必要なものをちゃんと探る必要がある
ということですね。
とりあえず提供する
この辺は賛否両論あると思います。
色々分析やらなんやら考えるんですが、結局のところ早く動くものをなんでもいいから作って触ってもらうのがPMFを達成する一番の近道だと考えるようになりました。
もちろん何も考えないのは駄目なんですが、思いついたものをすぐ形にして自分たちで触ったりお客さまに提供してフィードバックを得るのがやはり重要だなと実感しており、リーンスタートアップがいかに重要か最近は身に染みています。
そのため今後の組織構造として組織に遊びを作ることが結構重要だなと考え始めています。
この遊びの部分がないとアイディアを試すのが難しい組織になりがちなので、メンバーの目標や組織構造として、どう実現するか考えています。
プロダクトと組織
ここからは青野が思う、BtoBにおけるプロダクトとビジネスの関係についてです。
数年前までは、本当にいいものを作れれば市場は受け入れてくれて営業力が弱くても売れると考えていました。
しかし実際には、プロダクトを強くすること自体が非常に難しいです。
構想通りキレイに進むことも殆ど無いですし、カオスの中を手探りで進むことばかりです。
特に生成AIの時代はそれが顕著で、時代の進み方がかつて無いほどに加速しており、変化と曖昧さが続く中で組織を構成し開発を進めなければなりません。
そのため重要なのはプロダクトと組織の繋がり、捉え方だと感じています。
組織自体を差別化要因にする
よくプロダクトを考える際に差別化という言葉を聞きますし、自分でもよく言いますが、本質的にはプロダクト単体で差別化というのは相当に難しいか領域によってはほぼ不可能でしょう。
特にAIの領域はすでにLLMを活用することでプロダクトのコア部分に大きな差がなくなりつつあります。
そのため、本当に重要なのはプロダクトと組織、人のつながりであり
- カオスを受け入れ、変化する組織であること
- 自分たちが戦う市場を理解し、その一員となること
- お客様の成功を第一に考える組織であること
この3つを組織として考え続け、その中心にプロダクトを据えることで、プロダクト単体ではなし得ない組織としての差別化が達成されうると考えています。
一番言いたいこと
色々組織について書きましたが、個人として今自分が最も大切だと感じているのは
曖昧でカオスな環境でもとにかく進む力 です。
それは
- プロダクトの1 ~ 10のうち1 ~ 3までしか決まっていなくても、3 ~ 10を予想して進みつつ、方向転換が必要であればすぐにPivotする柔軟性
- 柔軟性がありながらも自分たちが成し遂げるべき舞台から逃げない信念
であり、AI Shiftはこれを実現しつつある組織であると思っています。
そして我々AI ShiftはLLM時代のど真ん中を貫く会社として、プロダクト + 組織で市場で唯一無二の存在を目指して日々頑張っています！
AI Shiftではエンジニアの採用に力を入れています！
少しでも興味を持っていただけましたら、カジュアル面談でお話しませんか？
（オンライン・19時以降の面談も可能です！）
【面談フォームはこちら】
