はじめに

こんにちは、フォースタートアップス株式会社の高場です。
2024年10月に入社しました。
テクノロジーグループで社内プロダクトのSREをやっております。

今回の記事は、最近話題のAIエージェントについてです。
中でも、2024年11月にリリースされ頻繁に更新が続けられているbrowser-useについて紹介します。

browser-useとは

browser-useはChatGPTでブラウザを操作できるPythonライブラリです。

browser-useは内部でブラウザでのテスト自動化を実現できるツールであるPlaywrightを使っています。

GitHub：https://github.com/microsoft/playwright

browser-useはPlaywrightを通じてブラウザを立ち上げることで、プロンプトに入力した操作をブラウザで実行してくれます。
Twitterへの投稿やECサイトでの商品購入なども可能です。
利用にはOpenAIAPIへの登録が必要です。

参考：https://github.com/browser-use/browser-use/tree/main/examples/use-cases

興味を持ったきっかけ

私がbrowser-useに興味を持ったのは、自動化に興味があるためです。
普段からAlexa等のホームスピーカーのように、ChatGPTにも何かタスクをやってもらいたいと考えていました。
ホームスピーカーのいいところは、家電の操作等を定型アクションで行えることです。
反面、音楽の検索などはファジーな命令を理解してくれない場合も多々あります。

そこでbrowser-useを見つけ、「あいまいな命令でAIに操作をさせることができる」点に興味を持ちました。
実際使ってみてどうだったかをまとめていきます。

注目を集めるbrowser-use

browser-useは昨年12月から急速に認知されはじめ、GitHubのスター数は2025/2/21時点で30.3kです。

AIエージェント分野自体が2023年から注目されている中で、browser-useも注目を集めており、これらを取り上げた記事も増えています。

browser-useを使ってみる

さっそく使ってみます。
ローカルへの導入方法についてはすでに詳しく解説した記事がたくさんありますので、本記事では触れません。

browser-useのフロント画面を作ってみた

ローカルで動作するフロント画面です。
ソースコード上でプロンプトを毎回書き換えるのは面倒なので、Next.jsでさくっと実装しました。

トラベルサイトでホテルを検索させてみた

簡単な操作をさせてみました。
プロンプトはトラベルサイトでホテルを検索するような内容です。

プロンプトを入力して実行すると、下記のようなログが出ています。
各ステップでHTMLの解析やブラウザへの操作を行っています。

結果

結果は下記のようなものでした。

特にフォーマット等は指定していないのですが、複数の候補を挙げてくれました。
事前にログインしておけば、予約等も可能だと思います。
（その場合、AIに持たせるログイン情報等の扱いには注意が必要です）

OpenAIAPIの料金

料金体系

browser-use自体はOSSですが、OpenAIAPIを利用しており、その分の料金がかかります。
OpenAIAPIは下記のような料金体系になっており、トークン単位で課金されます。
今回の検証に使用したgpt-4o-miniは、100万トークンあたり$0.15（22円程度）です。

参考：https://openai.com/ja-JP/api/pricing/

AI分野でのトークンについて

トークンとは、機械学習モデルに入力する文字列の量を表す最小単位です。
ざっくり、単語という理解で問題ありません。

下記の例文を見てみます。

例文: 「猫が窓の外を見ている」  トークン化: ["猫", "が", "窓", "の", "外", "を", "見ている"]

ChatGPTなどの生成AIは、トークン化された文字列を読み込んで学習を行っています。
そのため、課金もトークン単位で行われるようです。

参考：

• https://book.st-hakky.com/data-science/llm-token-article/
• https://learn.microsoft.com/ja-jp/dotnet/ai/conceptual/how-genai-and-llms-work

今回の検証での利用コスト

全体

画像はこの記事を書くための検証で使用した総トークン数です。
正確な回数は記録していないのですが、簡単な検索を数十回程度実施した結果 、5,531,506トークンとなりました。

実際に入力したプロンプトは単純なものなので、実際よりかなり多い数字になっています。
ここから、内部でブラウザを操作するためにさらに複雑なプロンプトへの変換が行われていると推測できます。

1回あたりのコスト

ざっくりですが、1回あたりのコストを出してみます。

「トラベルサイトで京都のホテルを検索する」といったプロンプトでは、下記のような結果になりました。

消費数：平均約172,611.667トークン
3回実行した場合の平均をとったところ、1回あたり¥3.89程度でした

失敗した場合

同じプロンプトでも、期待した動作とならないことがあります。
そうした場合では、下記のような結果になります。
期待した動作にならなかった場合でも、APIはコールされているので料金はかかります。

原因はわかりませんが、ChatGPTが画面上でうまく指定したワードを見つけられない時があるようです。
こうした場合には見つかるまで探索を繰り返すので、ステップ数が増えやすい傾向があります。

上記の対策として、browser-useの初期化時にmax_stepsオプションを指定することができます。

公式の使用例

asyncdefpost_tweet(agent: Agent):try:await agent.run(max_steps=100)          agent.create_history_gif()print("Tweet posted successfully!")exceptExceptionas e:print(f"Error posting tweet: {str(e)}")

https://github.com/browser-use/browser-use/blob/main/examples/use-cases/post-twitter.py

このオプションを指定することで、失敗時に不要なステップが増大するのを抑えることが可能になります。
上記の検索程度であれば10ステップ程度で十分に行程を完了することができたので、やりたいことに合わせて設定するのが良いと思います。

関連する更新まとめ

browser-use web UI

2025/1/6にbrowser-useの公式web UIがリリースされました。

この記事では自作のフロント画面を使いましたが、公式の方が便利なので今後は上記を使用することにします。

参考：https://github.com/browser-use/web-ui

OpenAI Operator

さらに、OpenAI公式のAIエージェントであるOperatorが2025/02/21に日本でも利用可能になりました。
browser-useとの比較などが気になるところです。

参考：https://openai.com/index/introducing-operator/

おわりに

browser-useでブラウザを操作することで、Web上での定型操作などを柔軟なプロンプトで自動化することができる可能性があります。
現状できることはブラウザ上での操作に限られていますが、browser-useはまだ開発が始まったばかりであり、今後更なる進化が期待できます。

当初私がやりたかったスマート家電の操作等はまだ難しそうです。
しかし、今後の可能性は広がっていると感じました。

機会があれば、音声入力を文字起こししてbrowser-useに認識させることでブラウザを操作することにもチャレンジしたいと思っています。

今後も動向を注視していきます。
ありがとうございました。

はじめに

こんにちは、エンジニアリングマネージャーの八巻（@hachimaki37）です。

今回の記事では、Slackワークフロー（以下、ワークフローと呼ぶ）を活用して開発チームにおけるオンボーディングプロセスを効率化した取り組みを紹介します。前回の記事「開発者体験サーベイで始める可視化とカイゼン（続編）」では、開発者体験の可視化について触れました。本記事では、その続編として、可視化を通じて明らかになったチームの課題を解決するための具体的な改善策に焦点を当てます。

前半では、オンボーディングプロセスに感じていた課題感と具体的な取り組み内容を紹介し、後半ではその経緯やチーム全体で得られた成果について振り返ります。

注記：

前回までの記事の内容についてはあまり触れておりません。そのため、以下をお読みいただけると内容の解像度が高くなるかと思います。

• メンバーレイヤーが考えてみた『開発生産性』と『開発者体験』（正編）
• 開発者体験サーベイで始める可視化とカイゼン（続編）

目次

• 前提
• オンボーディングにおける課題
• 解決策と期待できる効果
• 具体的な取り組み
• 実施例
• 経緯
• 導入後のフィードバック
• 具体的な変化
• あとがき

前提

当社では、新卒・中途を問わず、入社初日から研修を提供しています。この研修では、フォースタートアップスで働く上で基本的な知識を身につける内容が中心です。一方、業務に直結するオンボーディングは、各配属先で行われます。本記事では、私が所属するグループ（以下、チームと呼ぶ）におけるチームのオンボーディングに焦点を当てています。

オンボーディングにおける課題

オンボーディングのプロセスには、既存メンバーと新人メンバー双方に課題が存在すると考えています。

既存メンバーの視点

例えば、

• 教育とサポートの負担：新人メンバーのサポートに時間を割くことで、自身の業務が圧迫される。
• 情報伝達のズレ： 社内プロセスや技術的仕様の伝達が非効率。
• 進捗の不透明さ：新人メンバーの困りごとや詰まりどころがわかりづらい。

新人メンバーの視点

例えば、

• 環境やツールへの習熟：新しい開発環境やツールの理解に時間がかかる。
• コードベースの理解：複雑なコードやアーキテクチャへの適応に時間がかかる。
• サポート不足：フィードバック機会の少なさによる不安や不透明さ。
• 心理的安全性：既存メンバーへの聞きづらさ、焦りや不安。

共通の課題

例えば、

• チーム文化への適応：新人メンバーがチーム文化に馴染むプロセスのサポート不足。
• コミュニケーションの質と頻度：効率的な情報共有と疑問解消の促進。

解決策と期待できる効果

これら課題を解決するために、ワークフローを導入してオンボーディングプロセスを自動化しました。すべての課題を完全に解決できるわけではありませんが、この仕組みにより、以下のような効果が期待できます。

1. 汎用性を高め、属人化を解消

   1. チームの資産となる仕組みを構築
   2. レバレッジを効かせた効率的なオンボーディングを実現

2. 適切なタイミングでの情報提供

   1. 新人メンバーの早期戦力化を促進
   2. オンボーディングプロセスのリードタイムを効率化
   3. プロダクトや業務フローの理解を、新人メンバーのペースで進められる環境を提供
   4. ファーストリリースの早期実現

3. 既存メンバーの負担軽減

   1. 教育やサポート業務の効率化

具体的な取り組み

ワークフローを使ったオンボーディングの仕組みは至ってシンプルです。下記はイメージ図です。新人メンバーと既存メンバーとの間にワークフローが入り、橋渡しの役目を担っています。簡単に紹介いたします。

期待すること

ワークフローが完了する時点で、チームでは下記のことを期待しています。

• 開発環境構築が完了していること
• チームの開発プロセスを理解していること
• 各種ルールのインプットを終えていること

上記が達成できていれば、チームでの開発を円滑に進めるための基本的なスキルを習得していると考えられるからです。

概要

ワークフローを活用し、主要なプロセスを自動化しました。これまで、オンボーディングの各工程が完了するごとに既存メンバーがサポートを行い、次の作業を指示していました。そのため、新人メンバーが学ぶべき情報やドキュメントを適切なタイミングでワークフローが提供できるようにしました。

仕組み

• 誰かが特定のチャンネルに参加した時にワークフローを開始する
• ボタン操作を活用して、次のステップへ進行する
• よって、各ステップは新人メンバーおよび既存メンバーのボタン操作により自動通知され、進行していく

構成

ワークフローは全13ステップで構成しており、オンボーディングの目的や期待値、開発環境の構築サポートなど、インプットが必要なドキュメントに加え、3つの演習が含まれています。ステップの一部を紹介します。

• チャンネルの新メンバーの自己紹介
• オンボーディングの目的や期待値について
• おおよそのタイムラインについて
• アカウントの作成依頼
• 開発環境の構築サポートについて
• プロダクト情報について
• チームの文化について
• コーディングルールについて
• 演習
  • ブランチ戦略：GitHub Flow
  • Commitルール：Emoji Prefix
  • デプロイ手順：検証環境へのデプロイ方法

実施例

ワークフローの流れ

1. 誰かがチャンネルに参加した時に開始する

   • 新人メンバーがチームの開発チャンネルに追加されることで、ワークフローが開始。

2. 新人メンバーのアクション

   • 指示されたタスクを完了すると次のステップが進行。

3. 既存メンバーのアクション

   • レビューや指示されたタスクを完了し、ボタンをクリックすると次のステップが進行。

4. 基本この繰り返し

   • 新人メンバーのアクションに対して、必要に応じて既存メンバーがアクションすることで、段階的にオンボーディングが進行する。

詳細に説明いたします。

1. 誰かがチャンネルに参加した時に開始する

チームの開発チャンネルに追加された時に「チャンネルに参加したユーザー」にメッセージが送信されます。そこからオンボーディングのワークフローが始まります。

実際にチームの開発チャンネルに追加された時に、参加したユーザーにメッセージが送信されます。

2. 新人メンバーのアクション

次のステップでは、ステップのフォームを使い「情報をフォームで収集する」から「チャンネルに参加した新メンバーの自己紹介」を行っていただき、既存メンバーに対して周知するようにしています。

3. 既存メンバーのアクション

上記キャプチャーのように既存メンバーに対してボタンクリックを促し、「確認しました！ありがとうございます🎊」ボタンをクリックしてもらうことで、次のステップが進行します。

4. ワークフロー完了後

新人メンバーが全てのステップを完了すると、ワークフローから既存メンバーに対してその旨がお知らせされます。

このように、新人メンバーと既存メンバー間のコミュニケーションフローにワークフローを組み込むことで、適切なタイミングで情報を提供し、スムーズなオンボーディングを実現しています。

経緯

後半は、開発者体験サーベイで始める可視化とカイゼン（続編）で可視化された課題について少し振り返ります。

開発者体験におけるチームで浮き彫りになった課題は、「フロー状態」と「認知負荷」の2つでした。特に、チーム全体の最適化を図るには「認知負荷」の改善が鍵であると判断しました。

これらの中でも特に 「プロジェクトのソースコードを理解するためのドキュメントは十分である」 を最優先で改善することを決めました。その理由は、新人メンバーが複数名チームに参画する予定があったため、チーム全体の開発生産性を高めるためには、新人メンバーの早期立ち上がりが不可欠と判断したためです。

ドキュメントを充実させることは重要なのですが、ドキュメントだけがあっても上記の目的の達成には課題が残ります。そこで、ドキュメントの充実に加えて、既存メンバー、新人メンバーにとって、より良い開発者体験を構築できるようオンボーディングプロセスの効率化に取り組むことを決めました。

導入後のフィードバック

実際に5名の新人メンバーに今回紹介したワークフローを使ってオンボーディングを進めていただきました。その結果、以下のようなフィードバックが寄せられました。一部を紹介いたします。

• 新人メンバーの声

  • ワークフローがあることで、次にやることが明確になった。
  • 演習を通じて開発の進め方を学ぶことができてよかった。
  • ドキュメントに不十分な部分があり、既存メンバーに質問する場面もあった。
  • ワークフローの前段でシステム全体の概要が説明されていると、より理解しやすくなりそう。

• 既存メンバーの声

  • オンボーディングの負担が軽減された。
  • 自分の業務に集中できる時間が増えた。
  • 新人メンバーのサポートが体系化され、効率的に進められるようになった。

貴重なご意見をいただき、よかった点や改善点をしっかりと把握することができました。これを踏まえ、さらなる改善を進め、チームが継続的に成長できる仕組みを構築していきたいと思います。

その第一歩として、実際に活用いただいた方々と改善ミーティングを行い、ワークフローの構成や内容の見直し、補完作業、ドキュメントの充実化に取り組んでおります。

具体的な変化

昨年10月頃から、ワークフローを活用したオンボーディングを導入しています。従来は、入社後に最初のプルリクエストを作成するまでに約2週間かかっていましたが、Findy Team+のデータを見ると、現在では約1週間ほどに短縮されています。

チームで日々改善を重ねているため、ワークフロー導入だけがこの変化の要因とは言い切れませんが、少なからず効果はあったと考えています。

あとがき

本記事では、ワークフローを活用したオンボーディングの効率化に関する取り組みを紹介しました。この仕組みを導入することで、チーム全体の生産性向上や開発者体験、新人メンバーの早期戦力化に向けた確かな一歩を踏み出せたと感じています。

次回の記事では、開発者体験のこれまでの改善活動を振り返り、開発者体験サーベイの結果を第1回と第2回とで比較します。その数値の変化を分析し、そこから得られた学びや気づきを共有したいと思います。

目次

• はじめに
  • 記事の目的と背景
  • 対象の読者
• 「多分」を使う心理的理由
  • 自信の欠如
  • 相手への配慮
  • 柔軟性と曖昧さの許容
• 「多分」が生むリスク
  • 信頼性への影響
  • 曖昧なコミュニケーション
  • 意思決定の遅延
• 「多分」に頼らないための方法
  • 事前準備を徹底する
  • 言葉の置き換え
  • 回答を保留して精査する
  • フィードバックを活用
  • 自分に自信を持つ
• 「多分」の使いどころ
  • 活用すべき場面
  • 避けるべき場面
• まとめ
  • 「多分」の利便性とリスクを理解する
  • 適切な場面での使用を心がける
  • 改善に向けた行動を実践する
• おわりに
• 参考資料

はじめに

こんにちは！フォースタートアップス株式会社のエンジニアの山崎です。 私たちの日常会話や仕事の場面で、無意識に使っている「多分」という言葉。この言葉には曖昧さや柔軟性を含む一方で、意外なリスクも含んでいます。

記事の目的と背景

この記事では、「多分」という言葉の心理的背景、使いすぎることで生じるリスク、そして改善方法について考察します。この記事のテーマを取り上げたきっかけは、周囲の人から「多分」が口癖になっていると指摘を受けたことでした。その際、「多分」を多用することで相手を不快にさせたり、ネガティブな影響を与えていないかと気になり、自分自身の言葉遣いを振り返るきっかけになりました。そして、このプロセスの中で「多分」という言葉の利便性とリスクについて深く考える機会を得ました。「多分」を適切に使いこなすことで、コミュニケーションをより信頼性の高いものにするヒントをお届けします。

対象の読者

• コミュニケーションの改善に関心がある方
• 職場での信頼性を高めたいと考えている方
• 曖昧な表現を減らしたいと感じている方

「多分」を使う心理的理由

「多分」を使う理由には、いくつかの心理的要因が関わっています。

自信の欠如

十分な情報が揃っていない状況では、「多分」を使って正確性を保とうとする心理が働きます。また、自分の意見に自信がないため曖昧な表現を選び、批判を回避する傾向があります。

相手への配慮

会話の調和を重視し、「多分」を使うことで柔らかい印象を与えます。相手の意見を尊重し、断定を避けることで対立を防ぐ目的があります。

柔軟性と曖昧さの許容

曖昧な表現を使うことで、変化に対応しやすくなり、心理的余裕を感じることができます。グレーゾーンを維持することで、過度に限定された発言を避ける効果もあります。

「多分」が生むリスク

便利に思える「多分」ですが、使いすぎると次のようなリスクが生じます。

信頼性への影響

明確な意見や事実が求められる場面で「多分」を多用すると、発言の信頼性が低下する可能性があります。結果として、聞き手からの信頼を失うリスクがあります。

曖昧なコミュニケーション

「多分」が含む曖昧さは、聞き手に具体的なアクションを取りにくくさせ、誤解を招く恐れがあります。

意思決定の遅延

曖昧な情報が判断を先延ばしにし、チームやプロジェクトの進行に悪影響を及ぼすことがあります。

「多分」に頼らないための方法

「多分」に頼りすぎないための具体的なアプローチを以下に挙げます。

事前準備を徹底する

問題やテーマについて十分に調査し、具体的なデータや根拠を用意することで、曖昧な表現を避けられます。また、質問や議論の展開を予測してシナリオを想定することも効果的です。

言葉の置き換え

「可能性としては高いです」や「現時点では問題ありません」といった具体的な表現を使うことで、曖昧な「印象」を抑えることができます。また、「おそらく」や「推測ですが」などの丁寧な表現で誠実な印象を与える工夫も有効です。

回答を保留して精査する

即時回答を避け、正確性を重視する姿勢が重要です。「現時点では明確な情報がないため、確認してから回答します」といった言い方で、慎重な対応を選択できます。

フィードバックを活用

発言後に周囲からのフィードバックを積極的にもらい、曖昧な表現を特定します。改善のヒントを得ることで、「多分」の使い方を意識的にコントロール可能です。

自分に自信を持つ

不安な気持ちが曖昧な表現を生む原因になることがあります。そのため、自分の意見や判断を信じ、明確に表現する意識を持つことが大切です。

「多分」の使いどころ

「多分」はすべての場面で避けるべきではなく、適切に活用することが求められます。

活用すべき場面

• 初期段階のアイデア出し：不確実な状況で自由な発想を促すため
• チーム間の意見交換：対立を避けつつ柔軟なアイデアを共有したいとき

避けるべき場面

• 重要な意思決定が要求される場面：プレゼンや交渉など信頼性と具体性が必要な状況

まとめ

「多分」という言葉は、日常生活や仕事の場面で多くの人が使う便利な表現です。しかし、その利便性の裏にはリスクも存在します。「多分」の特性を理解し、適切に活用するためのポイントを振り返ります。

「多分」の利便性とリスクを理解する

心理的安全性を提供する一方で、使いすぎると信頼を損なう可能性があります。 曖昧さを許容することでその場の雰囲気を和らげることもできますが、使いすぎると発言の信頼性が低下する可能性があります。「多分」は便利な表現ですが、場面に応じた適切な使い分けが重要です。

適切な場面での使用を心がける

重要な意思決定の場面では明確さを優先し、曖昧さが効果的な場面では柔軟性を活かしましょう。

改善に向けた行動を実践する

具体的な方法を取り入れ、「多分」の使用を意識的にコントロールすることで、信頼性の高いコミュニケーションを目指せます。

おわりに

「多分」という言葉の利便性とリスクを深く理解することで、コミュニケーションの質を向上させることができます。この記事を参考に、日常や仕事の場面で「多分」と上手に向き合い、信頼性と柔軟性のバランスを取った表現を心がけてみてください。

この記事の内容をスライド資料版としてもまとめています。 気になる方はご覧ください。

参考資料

• 「たぶん」が口癖の人の心理
• 【口癖「たぶん」が描く心理風景】不確実性の言葉から読み解く内面

はじめに

こんにちは、エンジニアリングマネージャーの八巻（@hachimaki37）です。2024年10月に昇進し、試行錯誤の日々を過ごしております。

今回の記事は、メンバーレイヤーが考えてみた『開発生産性』と『開発者体験』（正編）の続編です。DevEx: What Actually Drives Productivityという論文を基に、開発者体験に関するサーベイを独自に設計し、フォースタートアップスの開発組織で「開発者体験に関するアンケート調査」を実施しました。

サーベイの目的をはじめ、サーベイの設計や設問構成、調査結果からどんなことが可視化されたのかなどについて書いていきたいと思います。

注記：

正編の内容についてはあまり触れておりません。そのため、正編からお読みいただけると内容の解像度が高くなるかと思います。また、個人的見解や解釈が含まれる点にご了承いただけますと幸いです。

目次

• フォースタートアップスの開発組織
• 開発生産性のレベル
• 開発者体験サーベイ
  • 目的と背景
  • サーベイ設計
  • 設問構成
  • 設問設計
• サーベイの実施概要
  • 調査方法
  • 回答数
• 調査結果
• あとがき

本題に入る前に、フォースタートアップスの開発組織と開発生産性のレベルについて少し触れたいと思います。

フォースタートアップスの開発組織

当社では、テクノロジーグループとSTARTUP DBグループという2つのプロダクトチームが存在し、全体でおおよそ20名ほどの開発組織です。私は、テクノロジーグループ（以下、チームと呼ぶ）に所属しております。

開発生産性のレベル

開発生産性のレベルとして3つの階層が定義されています。

※以下、開発生産性の教科書から引用。より詳しい内容を知りたい方は、開発生産性の教科書や開発生産性について議論する前に知っておきたいことをご覧いただければと思います。

レベル1：仕事量の生産性

このレベルでは、特定の作業量をどれだけ効率的にこなせたかに焦点を当てています。価値や売上への貢献は考慮せず、純粋に作業量の観点から生産性を評価します。

今回行った「開発者体験に関するアンケート調査」は、このレベル1に該当します。開発者の体験を可視化し、プロダクトチーム毎に純粋な作業量の観点で改善に生かせるようにしています。

また当社では、Findy Team+を活用しながらプロダクトチーム毎の開発生産性向上にも取り組んでおります。参考値ですが、直近6ヶ月（2024年7月1日〜2024年12月31日）のチームの推移です。チームでは、「オープンからレビューまでの平均時間」と「レビューからアプルーブまでの平均時間」の2つのスタッツを「市場全体（Findy Team+導入企業）の上位10%」に目標を置き、昨年9月ごろから改善に取り組んでおります。

レベル2：期待付加価値の生産性

このレベルでは、仕事量だけでなく、各施策がプロダクトにどれだけの価値をもたらすかを考慮します。ただし、実際の価値を評価するには時間がかかるため、「期待される価値がどの程度リリースできたか」に焦点を当てます。この観点では、プロダクト開発組織全体のアウトプットが重視されます。

現在、チームではレベル2の「各施策がプロダクトにどれだけの価値をもたらすか」を課題と捉え、各施策の効果測定方法について、リリースに合わせた最適なアプローチを模索しています。

レベル3：実現付加価値の生産性

このレベルでは、売上やKPIなど、実際のサービスに対する具体的な貢献を評価する段階です。このレベルの生産性は、開発チームだけではなく、カスタマーサクセス、セールス、マーケティングなど、組織全体で評価に取り組んでいく必要があります。このレベルでは、「そのタスクが実際にビジネスの目標に貢献できているか」という観点で評価することになります。

開発生産性の教科書によれば、規定の職務以上の役割を担うこと、越境してお互いに深く入り込んでいくことが求められるなど、職務を超えて開発生産性レベル3の向上に取り組んでいく必要があることから達成が難しいとされています。その理由については私も深く共感しています。ただし、この難しさこそが、私が今取り組んでいる課題でもあります。現在、チームとしてのアウトカムを定義し、サービスに対する具体的な貢献や価値が何であるかを試行錯誤しながら進めています。

開発者体験サーベイ

目的と背景

開発生産性レベル1の向上です。その課題発見を目的としています。実施背景は、開発者にとってより良い作業環境を整備することを目指し、開発組織およびプロダクトチーム毎の開発者体験を可視化するために実施しました。

サーベイ設計

サーベイは、DevExの3つの側面（「フロー状態」「フィードバックループ」「認知負荷」）に焦点を当てた設問を中心に構成しています。また、「雇用形態」「所属」「役職」「勤続年数」などの属性情報を加えることで、サーベイ結果を詳細に分析できる設計としました。

設問構成

サーベイは、5段階評価による26問と、自由回答形式の5問で構成し、段階評価は以下のように定義しています。

• 1ポイント: 全くあてはまらない
• 2ポイント: あまりあてはまらない
• 3ポイント: どちらともいえない
• 4ポイント: ややあてはまる
• 5ポイント: とてもあてはまる

設問設計

設問は、意図した回答が得られるように慎重に議論し設計しました。

フロー状態に関する設問

1. 途切れることなく日々継続的に開発に集中できる。
2. 会議や中断がなく、まとまった時間を開発に充てることができる。
3. 予期していないタスクや要求がほとんどない。
4. チームで協力して対処する必要があるインシデントの頻度は低い。
5. 私の仕事は魅力的である。
6. 私が行うコーディングタスクは退屈なものよりも魅力的である。
7. 自由回答
   • 「フロー状態（集中、没頭、楽しさを感じている精神状態）について、一つだけ改善できるとしたら何でしょうか？」

設問の意図

• 深い作業に費やした時間の満足度
• 中断の頻度
• 開発者の興味を引くタスクか

フィードバックループに関する設問

1. チーム内での心理的安全性は高い。
2. 技術的な質問に対し、10分以内に回答を得ることができる。
3. 開発者は、必要な情報に簡単かつ迅速にアクセスできる。
4. 開発者が繰り返し質問する内容は、十分にドキュメント化されている。
5. リクエストしたコードレビューは速やかに（数時間以内）実施される。
6. リクエストしたコードレビューは迅速に（24時間以内）完了する。
7. 開発環境にはよく整備された自動テストがあり、結果を迅速に確認できる。
8. テスト環境（CI）は十分に整備されており、テスト結果を迅速に確認できる。
9. 自由回答
   • 「質問に対する回答がすぐに得られる（頻度や速度、品質）ことについて、一つだけ改善できるとしたら何でしょうか？」

設問の意図

• 質問に対する回答が得られる頻度
• コードの変更が承認されるまでの時間

認知負荷に関する設問

1. デプロイの手順は最小限で、比較的容易である。
2. 変更したソースコードは短いリードタイムで本番環境にリリースされる。
3. プロジェクトやタスクの目標は明確で理解しやすい。
4. プロジェクトのソースコードは明確でシンプルで、理解しやすい。
5. ソースコードを理解するためのドキュメントは十分である。
6. ソースコードの品質は優れており、よくメンテナンスされている。
7. チーム内およびチーム間でコードや作業の理解を促進する取り組みが行われている。
8. 会社から提供される機材は充実しており、十分な性能を備えている。
9. 開発に必要なツールは、会社から適切に提供される。
10. 作業プロセスや開発者ツールの操作は直感的で使いやすい。
11. 開発環境の設定手順は整備されており、すぐに開発を開始できる。
12. 自由回答
    • 「認知負荷（開発者がタスクを完了するために必要な、ワーキングメモリにかかる負荷）について、一つだけ改善できるとしたら何でしょうか？」

設問の意図

• 変更のデプロイのしやすさ
• 理解のしやすさ
• プロセスや開発者ツールの操作の直感性

その他

1. チームや会社の文化は主体性を持った挑戦を支援していますか？
2. プロダクトにおいてオーナーシップや使命感を感じていますか？
3. 自由回答
   • 私たちの開発で気に入っている点は何ですか？
   • 私たちの開発で課題感を感じる点は何ですか？

設問の意図

• 改善が進みやすい環境かどうか

サーベイの実施概要

調査方法

回答形式：Googleフォームを使用

回答数

回答者数: 13名 ※フォースタートアップスに所属する開発者を対象

調査結果

実際に調査結果をまとめた報告書の一例を紹介いたします。

開発者体験に関するアンケート調査では、「フロー状態」「フィードバックループ」「認知負荷」の3つの側面に関する設問に対して、平均スコアを算出しました。その結果、以下の3つの側面において、3.5ポイント以上の評価が得られました。

これらにより、フォースタートアップスで働く開発者の開発者体験は「やや良い」状態であることがわかりました。

また、全体の大部分を占める「中途（正社員）」のフロー状態を中心に改善を行うことで、フォースタートアップスで働く開発者のパフォーマンス改善が見込めると考えます。

各スコア

フロー状態：3.5 / 5 ポイント

フィードバックループ：3.6 / 5 ポイント

認知負荷：3.6 / 5 ポイント

所属グループ別

テクノロジーグループとSTARTUP DBグループを比較した結果、大きな差異は見られませんでした。

雇用形態別

一方で、雇用形態別に見ると、「中途（正社員）」のフロー状態（3.0 ポイント）とフィードバックループ（3.3 ポイント）に改善の余地があることがわかりました。

要因分析の結果、以下のような傾向が確認されました。

テクノロジーグループ

• フロー状態において、以下の2つの設問が特に低いスコアを示しました。
  • 「途切れることなく日々継続的に開発に集中できる」: 2.6ポイント
  • 「当初予期していなかった予定外のタスクや要求はほとんど受けない」: 2.8ポイント
• 弊社では、一部のポジション（主に「中途（正社員）」が担当）で突発的な業務が発生しやすく、これが外れ値としてスコアに影響を与えている可能性があります。

STARTUP DBグループ

• フィードバックループにおいて、以下の設問が特に低いスコアを示しました。
  • 「リクエストしたコードレビューは、迅速（24時間以内）に完了（Approve）する」: 2.8ポイント
• Findy Team+で直近6ヶ月（2024年7月1日〜2024年12月31日）の推移を確認した結果、プルリクエストのコメント数が多い傾向であることが判明しました。このことから、コードレビューでの修正作業がスコアに影響を与えている可能性が考えられます。

このように要因分析をFindy Team+と組み合わせることで、課題の仮説も立てやすくなります。

その他

さらに、「チームや会社の文化は主体性を持った挑戦を支援していますか？」という質問に対する回答は4.4 ポイントと高評価であり、フォースタートアップスで働く開発者は新しい取り組みや主体性を持った挑戦を実行しやすい環境であることが示されました。

あとがき

いかがでしたでしょうか。定性的な評価とは別に定量的なデータがあることで、開発組織やプロダクトチームの開発者体験の側面をより明確に可視化することができます。本記事では、2024年6月に実施した第1回開発者体験に関するアンケート調査の結果を中心に紹介しました。あれから半年以上が経ち、プロダクトチーム毎にこのデータも活用しながら改善に取り組んでいます。

次回の記事では、ネクストアクションや改善施策、また2回目アンケート調査の結果を基に数値の変化について執筆を予定しています。

現場での開発生産性レベル1の重要性を感じる一方で、今後はレベル2〜3の達成に向けても挑戦していきたいと思います。