15
12

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

こんにちは!
ourly株式会社という3期目のスタートアップでEM兼BEとして働いている相澤と申します。

ourlyはインターナルコミュニケーション(社内コミュニケーション)活性化を通した従業員エンゲージメントの向上を目的とするWeb社内報やプロフィール機能を提供しているSaaSです。

この記事では、Qiita×Findy記事投稿キャンペーン「今の開発組織でトライしたこと・トライしていること・トライしようとしていること」開催を受けて、3期目のスタートアップがこれからトライしようとしていることを紹介させていただきます。

我々は、前期から開発生産性に関して明確にKPIを設けて改善をスタートし、約1年間改善を続けてきました。どんなKPIを設定したのか、取り組んだ内容などは以下の記事にまとめております。

また、僕自身の経歴は以下の記事にまとめておりますので、もし興味があればこちらも合わせてご覧いただけると幸いです

これまでの話

前期の振り返り

これからの話をする前に、まずは我々のチームの現在地をお話ししたいと思います。

前期は最初に記載した通り、開発生産性に向き合い始めて数値の改善を続けた1年でした。
結果として、KPI設定したデプロイ頻度やリードタイム、それに関連するメトリクスも軒並み良化し、チームとしての成長をひしひしと感じております。

デプロイ頻度推移.png

リードタイム推移.png

1期と2期の数値比較.png

また、プロダクトとして開発規模が大きめの機能を2つリリースしつつ、並行で中小規模の機能改善や新機能追加などを月1単位でできたことで、スループット改善だけでなくアウトプットの量を増やすこともできました

前期開始時のチームは、僕とテックリードを除いてはほぼ全員Web開発経験1年以内のメンバーで、唯一1人だけ1年以上経験のあるメンバーがいましたがまだ入社して間もないという状態でした。
当時は設計やPRレビュー、プロジェクト管理などを僕かテックリードだけで行っていたのですが、新規開発だけでなく不具合調査や運用対応、採用業務などのタスクに忙殺されてしまい、ボトルネック化してしまうことがしばしばありました。

そういった状態から開発生産性に向き合い始め、結果として上記で紹介したような成果を出せるチームに成長することができました。ここまで成長できたのは、定量的な目標を決めたことが良かったというのはあるのですが、目標達成に向けてチームメンバーが、施策をやり切ってくれたことがとても大きいです。本当にありがたい...!

今のチームの現在地を一言で表すと「決まったものを効率よくスピーディに実装できるチーム」です。

これからの話

3段階の開発生産性

さて、チームの現在地が分かったところで、その先には何があるのでしょうか?
開発生産性には3段階のレベルがあるということを、エンジニアリング組織論への招待の著者である広木さんが仰っています。

  • レベル1生産性:仕事量の生産性
    • 決まった時間でどの量の仕事を終えることができたか
  • レベル2生産性:期待付加価値の生産性
    • 決まった時間で、どのくらいの価値が期待される仕事ができたか
  • レベル3生産性:実現付加価値の生産性
    • 決まった時間で、どのくらいの価値が実現できたか

引用元は以下の記事ですが、めちゃくちゃタメになるのでまだ読んだことがない方はぜひご一読ください!

我々が前期向き合っていたベロシティ/走攻守割合/デプロイ頻度/リードタイムの4項目は全て、レベル1生産性を向上させるための目標設定と取り組みでした。

先ほど紹介した通り、前期開始当初はまだ伸び代しかないチームだったこともあり、まずは基本となるレベル1生産性を向上させないことには強いチームとはなり得ないと考えていました。
1年間徹底的に向き合ったことで、レベル1生産性に関しては他社比較しても遜色ない数値を出せるチームにはなったのではないかなと感じています。(元々CI/CD環境をある程度整備していたり、テストを割と書いていたり、レベル1生産性向上の基盤があったので1年でここまでこれたというのももちろんあります。)

次はレベル2を目指す...?

この流れからすると、じゃあ次はレベル2生産性向上を目指すんだな、と思われるかもしれません。もちろん間違ってはいないのですが、少しだけ違うところがあります。

我々が提供しているourlyはB2Bプロダクトになります。B2CとB2Bのプロダクトマネージャーの違いを調べた時に、以下のような違いがあることが分かりました。

スクリーンショット 2024-04-22 0.15.58.png
引用元:SaaSプロダクト組織を作るなら知っておきたい、「B2BとB2Cのプロダクトマネージャー」6つの違い

B2Cでは仮説検証のFBサイクルを高速に回して打席数を増やすことでヒット数を増やしていく一方で、B2Bではプロダクトビジョン(=顧客の本質課題を解決できる世界観)と顧客FBが基本の軸となるので1打席1打席の質を高めることでヒットを狙っていきます(と理解しています)。つまり、B2Bプロダクトにおいては、顧客から直接FBをもらえたり、作る前に仮説検証ができたりするため、期待付加価値 ≒ 実現付加価値となるであろうと考えました。

B2Bプロダクトであるourlyも生産性のレベル2と3はほぼ等価であると考え、2つを合わせて「付加価値生産性の高い」チームを目指すことにしました。

別の言い方にすると単に実装(+テスト、リリース)という意味での「開発」に向き合うチームから、「プロダクト」そのものに向き合って改善していくチームへとシンカしていくことを目指します。

ちなみに敢えて「シンカ」とカタカタ表記したのは「シンカ」という言葉に3つの意味を持たせたかったからです。

  • 進化:今までできていなかったことができるようになるという意味でのシンカ
  • 新化:今までと同じ方法では達成できない目標に対して、適切にアンラーンして新しいやり方を模索していくという意味でのシンカ
  • 深化:今までできていたこともより良い形でできるように深めていくという意味でのシンカ

「付加価値生産性の高い」チームとは

プロダクトの付加価値向上には大きく2つのアプローチ方法があります。

  • 顕在化していない課題の解決/新しい価値の提供(プロダクトアウト的アプローチ)
  • 顕在化している課題の解決/新しい価値の提供(マーケットイン的アプローチ)

プロダクトにおいては上記2つのどちらも必要ではありますが、プロダクトチームがパワーを発揮しやすいのはプロダクトアウト的アプローチの方だと考えています。

役割上、クライアントや市場に対する解像度は頻繁に接する機会があるセールスやOD(弊社ではカスタマーサクセスのことを、組織開発という意味でOrganization Developmentを略したODといっています)の方が高くなりやすいため、クライアントの温度感や今求められているもの、これから求められそうなものに関してのキャッチアップはセールスやODの方が得意な領域です。

一方、エンジニアは利用データやエラー内容を元に、クライアントの担当者やourlyのセールス、ODが気づいていない改善点に気づくことができます。例えば、URLパラメータからどのような検索をされているかを知ることでどのような使い方を想定しているか分かったり、頻繁に400系のエラーが起きている箇所は、操作が分かりづらいのかもしれないという仮説が立てられたりします。そういったデータと仮説を元にクライアントヒアリングを行うことで、精度高い改善や新機能開発ができるのはエンジニアの強みだと考えています。

決してどちらが偉いとかどちらが価値貢献しているということはなく、お互いに情報を補完しあい、得意な領域で付加価値向上を目指していくことが重要です。

「付加価値生産性の高い」チームとはつまり「プロダクトの価値向上のために職域を超えた巻き込み力を発揮しつつ、スピーディに開発ができる」チームだと考えています。

今期チャレンジすること

最後に付加価値生産性が高いチームを目指すためにこれからチャレンジしようとしていることを軽く紹介して終わりにします。

主に以下の3つのカテゴリで、4つの施策に注力していくことを考えています。
今期チャレンジすること.png

まずカテゴリについてですが、理想の状態から逆算して考えました。

  • 開発サイクルの中でセールスやODと、プロダクトに関する意見交換やFB共有/議論をする機会があること
    • これは単純にクライアントからのFB共有だけでなく、エンジニアから顕在化していない課題/価値に関するFBを共有することも含みます
  • 効率的にFB対応/課題発見と提案をできる体制ができていること
  • 上記を実現するにあたってプロダクトのクオリティを落とさないのはもちろんのこと、より強いチームになるために一人一人に確かなスキルが備わっていること

これらの理想に対して必要なことが以下4つの施策だと考えています。

  • 開発フロー全体の見直しと改善
    • 現状の開発フローはPOとエンジニアに閉じたものになっており、またプロダクトチームが関わる範囲も狭かったのでそれを広げる動きが必要になります(※1参照)
  • 責務の明確化と権限移譲
    • より効率的かつスピーディに改善サイクルを回すために、誰がどこに責任を持つのかを明確化し、適切に権限移譲する必要があります
  • フィーチャーフラグの導入
    • フィーチャーフラグを導入することでクライアントFBをもらうスピードを早めることができ、機能のブラッシュアップがしやすくなり、結果として付加価値の生産性をあげられると考えています
  • ハード/ソフトスキルのボトムアップ & トップラインを伸ばす
    • 前期大きく成長したチームですが、さらに高みを目指すためにはマネージャー陣も含めてスキルアップが不可欠です
    • 闇雲に施策を走らせるのではなく、中長期の目標から逆算して必要な能力/スキルを(採用も含めて)どう獲得するか、から落とし込む予定です

※1
開発フロー.png


以上、3期目のスタートアップのこれまでとこれからの話をさせていただきました。
最後までお付き合いいただきありがとうございました!!

まだまだ僕自身未熟な部分や考えが甘い部分も多いですが、適宜FBを色々な方にいただきながら修正していきたいと考えています。
そんな僕たちのチームで一緒に働いてみたい!と思っていただけたら、ぜひ一度カジュアル面談でお話ししましょう!
もっと思いの部分やメンバーのこと、プロダクトのことなどを詳細に紹介したいです!

15
12
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
15
12

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?