シェア
はてブ
2024年6月28日、29日の二日間にわたって、ファインディ株式会社が主催するイベント「開発生産性Conference」が、開催されました。本カンファレンスは、虎ノ門ヒルズフォーラム（東京）にて実施され、一部のセッションはオンライン配信も行われました。
本記事では、オンラインでも配信されたセッションのうち、Qiita株式会社でプロダクトマネージャーを務める清野隼史さんによるセッション「開発組織の生産性を加速させる: 継続的価値提供を実現する文化と仕組み」の内容をお届けします。
日本最大級のエンジニアコミュニティ「Qiita」の開発組織では、エンジニアとデザイナー各5名ずつ、SRE3名の計13名で開発を進めています。少人数ながら、2023年度は98個ものユーザー機能をリリースしたのだとか。本セッションでは、Qiitaの開発組織が「高い開発生産性」を実現するために行っている取り組みについてお話しいただきました。
※注釈：「最大級」は、エンジニアが集うオンラインコミュニティを市場として、IT人材白書（2020年版）と当社登録会員数・UU数の比較をもとに表現しています
■プロフィール
清野 隼史（きよの としふみ）/ @getty104
Qiita株式会社 プロダクト開発部 Qiita開発グループ マネージャー
2018年、大学在学中にIncrements株式会社（現・Qiita株式会社）へアルバイトとして入社。入社以来QiitaやQiita Jobsの開発に携わる。2020年2月よりQiitaプロダクトマネージャーに就任。
日本最大級のエンジニアコミュニティを開発する組織とは
清野：Qiita株式会社のQiita開発グループでマネージャーをしている清野隼史と申します。普段はQiitaのプロダクトマネジメントや開発組織のマネジメントを行っております。
本日のアジェンダはこちらです。
清野：Qiita株式会社はミッションの「エンジニアを最高に幸せにする」を実現するべく、エンジニアに関する知識を記録・共有するサービス「Qiita」と社内向け情報共有サービス「Qiita Team」を開発・提供しています。
私が担当している「Qiita」は、2024年5月末時点で会員数が120万、記事数が92万を突破するなど、日本最大級のエンジニアコミュニティとしてご利用いただくサービスに成長しました。
清野：ちなみに、2023年度は98個のユーザー機能をリリースしています。リリース頻度は年々向上しており、KPIについても改善してきています。直近4年間のリリース数を見てみても、2020年と2023年ではリリース数が大きく伸びています。
開発に関わっているのは、エンジニアとデザイナーがそれぞれ5名、SRE組織のエンジニアが3名の計13名です。本日は、この少人数で年間98個のリリースを達成している背景についてお話しします。
Qiita開発グループが取り組む「仮説検証型アジャイル開発」
清野：開発生産性とは「『価値ある開発』と『開発の効率性』の掛け算」だと考えています。
前者は、ユーザーの価値となる機能のリリースやプロダクトを運用する際のコストの削減、プロモーションやブランディングの最適化を意味しています。後者は、開発にかけた時間とお金、開発者の体力といった“開発のコストパフォーマンス”ですね。高い開発生産性の実現とは、その両方が掛け合わさった結果として表れるものなのではないでしょうか。
ただ、リリース後にユーザーの声を聞くまでは価値あるものができたかどうかは判断できないため、“価値あるものだけ”を作るのは、現実的に考えて難しいことでもあります。
しかし、価値あるものに費やす時間を増やすことはできるはず。Qiitaで実践している方法をお話しする前に、株式会社レッドジャーニーの代表である市谷聡啓さんの著書『正しいものを正しくつくる（ビー・エヌ・エヌ）』から引用した言葉をご紹介します。
清野：これは、価値あるものに対してかける時間を増やしていくためには、とても重要な言葉だと思っています。この言葉を念頭におきながら、Qiita開発グループでは「仮説検証型アジャイル開発」に取り組んでいます。
仮説検証型アジャイル開発とは何か？市谷聡啓さんの著書『正しいものを正しくつくる』から再び引用すると「わからないことをわかるようにしていく仮説検証という探索と、わかったことに基づいてプロダクトをアジャイルに作る開発、二つの局面が存在することになる。この全体像を指して、本書では『仮説検証型アジャイル開発』と呼ぶ」と書かれています。
清野：つまり、仮説検証とアジャイルに作っていくところ、その両方を開発組織で進めていくアプローチだと私は解釈しています。
仮説検証を開発組織で回すために、私たちは下記のようなことを行っています。
清野：Qiita開発グループにはコミュニティマネージャーも所属しており、ユーザーインタビューやSNSなどを通したユーザーとのコミュニケーションの場にも、エンジニアが参加するようにしています。また、スクラムを導入してスプリントプランニングとスプリントレビューを実施することで、自分たちで仮説検証を回すようにしています。
ただ、これらの取り組みだけで開発生産性を上げられるのかと聞かれると、答えは「No」です。仮説検証を通して進む先を繰り返し修正できるようになったあとは、修正する頻度を増やしていかなくてはいけません。
そこでQiita開発グループでは「小さい開発」を意識して、1～2スプリント程度／2週間～1ヶ月ほどで開発ができる規模に抑えるようにしています。それ以上にかかりそうな場合は、簡単なプロトタイプを作るところからスタートして「本当にこの機能に価値があるのか？」を検証したあとで開発に取り掛かるようにしています。
清野：ここでポイントとなるのは「雑に作る」のではなく「小さく作る」ことです。
スピード優先で検証を進める場合、雑に作ってみることもあると思うのですが、技術的負債や未熟な設計は全体のパフォーマンスを下げてしまいます。そのため、雑に作るのであれば、雑に捨てられるように作る。私たちの場合は、プロトタイプのような本物のプロダクトとは違うところで作って検証を行うようにしています。
「仮説：AIによる内容修正が記事執筆体験向上につながる」の検証実例
清野：ここからは、具体的な取り組みとして「AIによる内容修正が記事執筆体験向上につながる」という仮説を検証した際のスクリーンショットをご紹介していきます。
清野：この仮説を持ってきてくれたのは、Qiita開発グループのメンバーであるohakutsu君でした。
仮説をもとに「AIによる内容修正が提供できる価値」について定義し、検証するべき問いを設定してくれています。
清野：検証するべき問いを設定し、この事例ではプロトタイプを使って「確認作業が億劫」という仮説が正しいかどうかを検証しました。
清野：プロトタイプでは、上図の左部分に記事のタイトルと文章を入力して、それに対してレビューした結果が右側に出るようにしてくれています。
しかし、プロトタイプを作って社内のメンバーにヒアリングしたところ、仮説通りの価値は提供できないという結果が出ました。
清野：なぜなら、一字一句確認して推敲する人もいれば、あまり確認をせずに投稿する人もいるからです。後者にとっては価値のあるサービスだと言えるかもしれません。しかし、前者には「AIが修正してくれた文章の確認」といった作業が追加される可能性があります。作業が増えてしまうとなると、価値のあるサービスとは言えませんよね。
清野：結果として、この事例では検証前に考えていたAIによる内容修正の機能は開発しないことが決定しました。
しかし、検証を通して「文法などのルールをベースとした修正の提案」なら価値を提供できそうだとわかったため、それまではβ版として公開していた文章修正提案機能の正式版を2024年1月30日にリリースすることになりました。
清野：ここまでのまとめとして、仮説検証を通して価値あるものを提供できる頻度が向上していますし、プロダクトの事業的な成長にも寄与していると実感できています。
ただ、仮説検証型アジャイル開発には「単純な開発時間の減少」「仮説検証サイクルが形骸化すると、開発時間がただ減っている状態になり得る」といったリスクがある点も否定できません。それらはパフォーマンスにも大きく関わってくる部分であるため、仮説検証の質を担保することが重要だと考えています。
手触り感を持てるよう「自分たち」で取り組むことが大切
清野：ここからは後半として「高い開発生産性をみんなで目指せる状態にするためにやっていること」についてお話をしていきます。
仮説検証型アジャイル開発は、一人でできるものではなく、何らかの手法を導入すれば上手くいくものでもありません。最も大切なのは、取り組む意思です。
そこでQiita開発グループでは、高い開発生産性をみんなで目指せる状態にするために、全員が手触り感を持てるものを作っていくことを大切にしています。
清野：具体的な取り組みとしては、フレームワークなどを活用して、自分たちの成果を言語化するようにしています。
言語化するにあたって、成果の内容は定性的なものでもいいと思います。それよりも大切なのは、自分たちが成果だと思うものを言語化して、自分たちが手触り感を持てるようにすることです。言語化したものがどのように事業成長につながっていくかどうかの指標は、あとで紐付けしていけば良いので。
清野：なお、Qiita開発グループで設定している成果は「『Qiitaが今後もユーザー・コミュニティに価値を提供し続けてる状態』を実現する」です。そのために、私たちはエンジニアとして開発業務にあたっているという認識ですね。
また、その成果をベースに自分たちの行動指針や価値基準も定義しています。
清野：具体的には「開発できる人がいる・増えている」「より良い体験を提供できている」「稼げている状態」「Qiitaが正常稼働し続けている」といった項目を行動指針・価値基準としています。
行動指針・価値基準を決めたあとは、半期ごとのチーム目標についてもメンバー全員で考えるようにしています。その際のポイントは、みんなが覚えられるようなキャッチーな内容にすることですね。例えば、Qiita開発グループでは過去に「熱を帯びる」といった行動目標を掲げていたことがあります。この言葉には「環境や状況、メンバーが入れ替わったとしても、その組織の中で熱源になれるぐらい熱を持って行動しよう」といった思いが込められていました。
「振り返り」と「むきなおり」で熱量を維持する
清野：ここからは「高い開発生産性を維持するためにやっていること」についてお話させてください。
メンバー全員で成果や行動指針・価値基準を定義することで、スタート地点に立つことができた段階だと言えます。しかし、そのあとになんの対策もせずに仮説検証型アジャイル開発に取り組んでしまうと、熱量が下がってしまい途中で目標を見失う可能性があります。最初に持っていた熱量を維持するためには、いくつかの工夫が必要です。
最初の熱量を維持するために、Qiita開発グループでは「振り返りでのやったことの可視化と労い」と「むきなおり」を実施しています。
熱量を維持するために最も重要なのは「やれている感」があるかどうか、です。これは「自分たちの開発を通して起こった変化が感じられる」「その変化に対してみんなで喜びを分かち合うことができる」といった状態ですね。個人のモチベーションの問題だと捉えることもできるかもしれませんが、私は組織として「やれている感が自然と湧いてくるような空気感」を作ることが大切だと考えています。
実際の取り組みとして「Qiita」のスプリントレビューでは、実際に作ったものの振り返りを行なっています。具体的には、各メンバーにどういうものを作ったのかデモも含めて話してもらい、それによって得た数字の変化や開発時の知見についても言語化して共有しあう時間を設けています。
また、スプリントレトロスペクティブでは、労いから始めることを大切にしています。そこで大切にしているのは、それを“お互いに行う”ということ。それぞれが各メンバーに対して労いの言葉をかけた後に、改善点について話し合うようにしています。
清野：上図の右下にある画像は、あるメンバーの労いのスクリーンショットです。このように、一人ひとりが各メンバーに対してコメントをしています。このような取り組みを通して、熱量を維持できるようにしています。
ただ、これだけで熱量を100%維持するのは難しいため、「むきなおり」というプロセスを通して再加熱する取り組みも行なっています。
清野：「むきなおり」は、市谷聡啓さんの著書『組織を芯からアジャイルにする（ビー・エヌ・エヌ）』のなかで紹介されているプロセスで、一言で表すと「数スプリントごとに行うチームの意思決定の掘り返し」です。
清野：Qiita開発グループでは、むきなおりを四半期に一度のペースで実施して「設定した目標に対して、四半期で取り組んできたことで起こった変化」「取り組んできたことでわかった課題」「これからどうするか？」といった点について全員で話し合うようにしています。
むきなおりを行うことで、取り組んできたことと意図の繋がりを再認識し、アクションの形骸化を防ぐことができています。また、次にどうするかをみんなで考えることで、価値あるもの・価値ある行動をアップデートし続けられていると実感しています。
複数の取り組みを通して、高い開発生産性を実現
清野：本日のまとめです。
高い開発生産性を実現できているという状態とは、「価値あるものが開発できている」「開発の効率性を高められている」の掛け合わせだと考えています。
前者で必要なのは、仮説検証を開発組織で回し切って、手戻りを最小限に抑えるために小さく開発すること。後者では、全員が手触り感を持てる「成果」「行動指針・価値基準」「目標」を設定し、振り返りとむきなおりで熱量を維持・再加熱することがポイントです。
最後に、Qiitaでは「Qiita Engineer Festa 2024」を開催しています。本日お話しした内容なども含めて、ぜひご投稿いただけますと幸いです。（※2024年7月25日で同イベントは終了しています）
またSpotifyやApplePodcast、Amazon Musicなどで「Qiita FM」も配信していて、日本で活躍するエンジニアの方をゲストに迎えて配信しているので、こちらもご興味があればぜひチェックしてみてください。
本日は、ご清聴ありがとうございました。
Slidoに寄せられた質問まとめ
イベント当日は、Q＆A投票を行えるプラットフォーム「Slido」を活用した質問タイムも設けられていました。ここでは当日の質問と回答をまとめています。※当日のSlidoに寄せられた質問はこちら
Q：「リファクタリングやテスト自動化など直接的には価値提供しないものの扱いがどのようになっているのか知りたいです」
清野：本日は「価値あるものを開発する」という観点でお話ししていましたが、リファクタリングやテスト自動化はパフォーマンスを上げるためのものだと考えています。そのため、その部分については別で判断軸を設けています。
Q：「Qiitaでは価値をどのように測定していますか？参考にしている指標などありますか？」
清野：「Qiita」はプラットフォームサービスであり、ユーザーヒアリングを通して、閲覧者と記事投稿者それぞれに提供する価値を定義しています。参考にしている考え方は、ダブルハーベストループです。
Q：「ユーザーインタビューの頻度、規模、エンジニアの関わり方について詳しくお伺いしたいです」
清野：これはタイミングによっても変わってきます。例えば、新機能に関するユーザーヒアリングをしたい時は、その都度ユーザーインタビューするようにしています。それ以外に定常的なユーザーインタビューも行なっていて、アドベントカレンダーのようなイベントに毎年参加してくださる方にお話を聞くこともあります。
規模でいうと、コミュニティマネージャーとエンジニアの2名体制ですね。インタビューする側の人間が多いと、お話ししてくださる方にプレッシャーを与えてしまいますから。そのため、基本は質問をする人と議事録を取る人の2名体制にしつつ、オブザーバーとして他のエンジニアメンバーがユーザーインタビューを確認できる場を用意しています。
Q：「雑に作るという部分で正直どこまで雑に作るかをいつも悩みます。 Qiitaでは雑に作ったものをユーザに触ってもらうことはありますか？ もしあるなら、ユーザに触ってもらう前提で雑に作るときの取り決めなどを教えて欲しいです」
清野：プロトタイプのようなものを作って、ユーザーに使ってもらうことはあります。シンプルなプロトタイプを本番環境に反映して、特定のユーザーに使っていただくといった取り組みもありますね。その際は、使っていただく前に「これはとてもシンプルに作った機能です。使用していただいた後にヒアリングさせてください」と伝えるようにしています。
Q：「コミニュケーションが発生するのは普段どの場面ですか？朝会や定例？出社してのオフラインのコミュニケーションでしょうか？5名くらいのチームであれば、密にコミュニケーションが取れそうだなと思いました」
清野：デイリースクラムのような形で朝会を行っているため、そこでコミュニケーションを取るようにしていて、スプリントレビュー（振り返り）は2週間ごとくらいで実施しています。また、Qiita開発グループは基本的にZoomを常駐して繋げているため、そこでシームレスにコミュニケーションを取れるようにしています。
Q：「仮説は開発チーム以外からも出てきますか？その場合も同様の進め方なのでしょうか？」
清野：答えは「Yes」です。本日はお話できなかったのですが、デザイナー組織やマーケティング、セールス組織のメンバー、代表も巻き込んで、振り返りや仮説検証を進めています。
アーカイブ動画も公開しております。こちらも併せてご覧ください。
