for Startups Tech blog

このブログのデザインを刷新しました。(2023/12/26)

LINEで朝活!技術トレンドを1日1分でキャッチするツールを作ってみた

こんにちは、フォースタートアップス株式会社の李です!

今回は、毎日の技術トレンドを簡単にキャッチアップできるツールを開発したので、紹介させていただきます。

目次

はじめに

皆さん、技術トレンドを毎日追えていますか?

僕は全くと言っていいほどできていません。技術記事を読むよりもゲームを遊んだり漫画やアニメを見たりしたい派です。でも、エンジニアとして成長するためには日々の情報収集が重要ですよね。今回はそんな課題を解決するファーストステップなるものを作ってみました。

作ったもの

その名も『Daily Tech Digest』です!

毎朝9時にQiitaの人気記事を1件、LINEに送信するシンプルなツールです。

特徴

  • 簡単に始められる
    • LINE Botを使用しているので、QRコードをスキャンして友達追加するだけで利用できます。
  • 送るのは1件だけ
    • 最初は「記事を読む時間を1日の中に取り入れること」を習慣化することを目標としているので、ハードルを下げるために1件だけにしています。
  • 毎朝9時に配信
    • 習慣化に大事なのは、「毎日すること」「同じ時間帯にすること」だと考えています。通勤中や朝のコーヒータイムに読むことを想定して朝9時に配信しています。

使用技術

『Daily Tech Digest』の開発では、以下の技術を採用しました。それぞれの選定理由と技術的な特徴を詳しく紹介します。

  • LINE Messaging API
  • Cloudflare Workers
  • Hono

1. LINE Messaging API

LINE Botを構築するために使用したAPIです。ユーザーとLINE上でメッセージをやり取りする仕組みを提供してくれます。

特徴

  • 送信できるメッセージの種類が豊富。
  • 日本語の公式ドキュメントが充実しており、開発がスムーズに行える。
  • 普段から使うアプリなので記事配信の通知が目に入りやすい
  • 将来的には社外の方にもお届けしたい!

2. Cloudflare Workers

サーバーレスプラットフォームとしてCloudflare Workersを採用しました。JavaScriptの実行環境をクラウド上で提供し、リクエストごとに軽量な環境を生成します。

特徴

  • 応答が早い
    • 将来的にはユーザーからのメッセージに対して何かしら返答する機能も作りたいと考えていました。
  • デプロイが簡単
    • プロジェクト下で以下のコマンドを実行するだけです。
    • wrangler deploy
  • 無料(一番重要)
    • とは言っても厳密には以下の制限があります
      • 10万リクエスト/日
      • リクエストあたりのCPU処理時間:10ミリ秒以内
      • デプロイサイズは1MBまで

技術的ポイント

  • 0msコールドスタート

    • 一般的なサーバーレス環境(AWS Lambdaなど)では、一定時間アクセスがないとその度に起動時のオーバーヘッドによる遅延が発生してしまいます。(これをコールドスタートと呼びます)

    • それに対してCloudflare Workersはisolateと呼ばれる機能を使うことで、オーバーヘッドを大幅に削減しています。

    • isolateとはJavaScriptエンジンV8が持つ機能で、軽量かつ迅速に多数の分離された実行環境を用意することができます。下記画像右側のように、実行環境を多数の空間に分離することで実行環境起動時のオーバーヘッドを削減しているようです。

      引用:How Workers works

  • コード実行までが早い

    • 通常クライアントからサーバーにHTTPリクエストするまでに、以下のようにTLSハンドシェイクが行われます(証明書を送り合ってサーバーとの接続を保護する処理)
      引用:Eliminating cold starts with Cloudflare Workers
    • Cloudflare Workersは2020年にさらに最適化され、HTTPリクエスト完了前に処理を始められるようになりました。TLSハンドシェイクにおける最初の手順の「Client Hello」が送られてきた時に実行環境が読み込まれてコードをコンパイルし始めるみたいです。すごい!
      引用:Eliminating cold starts with Cloudflare Workers

3. Hono

Webページ、Web APIを作るのに便利なフレームワークです。

Cloudflare/Deno/Bun/Node.jsなど様々な環境に対応しています。

特徴

  • ルートハンドラーが非常に簡単です

    ⬇︎たったこれだけでルートにリクエストが来たら”hello”を返す処理が書けます!

      import { Hono } from "hono";
    
      const app = new Hono();
    
      app.get("/", async (c) => {
        return c.text("hello");
      });
    
      app.fire();
    
  • まだ複雑なロジックは作成していないので、また新たな発見があれば別の記事で紹介できたらなと思います!


開発で意識したこと

個人開発では、最小限の機能でリリースすることが重要です。大きなスコープを設定すると挫折しやすいため、シンプルで続けられる範囲に収めました。

使ってみた感想

1週間使ってみたところ、以下の点に気付きました。

  • 習慣化の効果

    • 自分で作ったツールを使う楽しさもあり、毎日送られてくる記事を読む習慣がつきました。
  • 課題

    • 同じ記事が送られてくる
      • 単純にQiitaのランキング一位の記事を取得しているので、連日同じ記事が送られてきてしまうケースがたまに発生します。
    • 送られてくる記事が個人の関心ごとにあまり一致しない
      • 1週間ほど読み続けましたが、Qiitaのトレンド1位になる記事は基本的に初学者向けの内容が多かったです。「AI関連ツールまとめ」「windowsの便利ツールまとめ」など
      • 「TypeScriptの〇〇というフレームワークで〇〇作ってみた」系の記事が送られてくることを期待していたので変更が必要そうです。

社内勉強会での反響

社内勉強会で発表した際、以下のような意見をいただきました。

  • 「1記事だけ送るのがちょうどいい!」
  • 「調べたい情報に応じてカスタマイズできると面白いね。」
  • 「Cloudflare Workersは常駐が必要?」

これらのフィードバックは今後の改善に活かしていきたいと思います。

発表に使った資料です!よければ合わせてご覧ください。

今後の展望

  • トレンドの再定義
    • 「どのジャンルをトレンドとして捉えるべきか?」や、「どの情報がトレンド理解に繋がるのか?」といった視点で、配信内容の見直しを行いたいと考えています。
  • データベースの導入
    • 記事の配信履歴やユーザー登録タグなどの機能を追加したいのでCloudflare D1(サーバーレスなSQLデータベースサービス)を導入してみたいです。

現状はユーザー全員に同じ内容を一斉配信していだけなので、今後はパーソナライズされた情報提供が可能になることを目指していきたいです!

まとめ

自分で試行錯誤しながら作り上げたツールには愛着が湧きます。そして、「もっと良くしたい!」という気持ちが、自然と技術キャッチアップのモチベーションに繋がっていることに気づきました。

今回の開発で使用したCloudflare Workersは、無料で始められる手軽さと高性能が魅力で、個人開発に非常に適していると感じました。ぜひ試してみてください!

ドリアとドドリアの違いは何ですか(真面目な話)その2

こんにちは、STARTUP DBのPdM 兼子(@S_Kaneko22)です! STARTUP DBは、国内最大級のスタートアップ情報を集約したプラットフォームで、25,000社以上のスタートアップ企業情報を提供しています。

さて最近、米OpenAIがChatGPT Proという新プランを発表しました。従来最高性能と評価されていたモデルをさらに上回る高度な思考モードを搭載し、難問への対応力が一段と高まったとされています。さらに、月額200ドル(約3万円)という強気の価格設定も話題となり、「約3万円も出せば、どれほど質の高い回答が得られるのか?」と、仕事で使うなら相当頼れるアシスタントになるのではと期待が膨らみます。

前回の記事では、ChatEGUことエンジニアの江種(@toshiya_egusa)さんが、ChatGPTやClaude、Perplexityといった複数の生成AIに同じ質問を投げ、回答を比較する手法を紹介しました。今回はその続編として私がバトンを受け、「GPT-4o mini(無料版)」と「ChatGPT o1 pro mode(約3万円)」を用いて、前回と同じ質問で再度検証を行います。UIや有料特典などはひとまず脇に置き、回答内容そのものに焦点を当てることで、価格やモデル特性の違いが回答品質にどう影響するのか、改めて確かめてみましょう。

価格以上の価値を生み出せるか、PdMとしてはROIが気になりますね。

注意
なお、本記事の内容は2024年12月19日時点の情報に基づいています。価格やサービス内容が今後変更される可能性もあるため、最新情報をご確認ください。

目次

はじめに

前回は合計5つの質問を投げて回答の精度を比べましたが、今回はそのうち特に反響の大きかった3つ(問題1〜3)にフォーカスしています。 問題4(gRPCサンプル)や問題5(ミラー対称性とCalabi-Yau多様体など高度な話題)については、また別の機会に改めてご紹介する予定です。

比較条件

  • GPT-4o mini(無料版):軽量で無料利用可能な対照モデル
  • ChatGPT o1 pro mode(約3万円):より高度な思考力が期待される高額プラン
  • 同じ3つの質問を投げ、回答の正確性・情報量・表現力を比較
  • UIや速度、有料プラン独自機能は考慮せず、回答内容のみ評価

問題1

Q: ドリアとドドリアの違いは何ですか?

GPT-4o mini(無料版)

「ドリア」と「ドドリア」は全く異なるものです。それぞれの詳細は以下の通りです。

1. ドリア (Doria):
   - 説明: ドリアは洋食の一種で、グラタンの一種として知られています。ご飯の上にホワイトソースやベシャメルソース、そしてチーズをかけてオーブンで焼き上げた料理です。エビや鶏肉、マッシュルームなどが具材として使われることが多いです。
   - 起源: 日本で考案された洋風料理で、フランス料理やイタリア料理の影響を受けています。
   - 提供される場所: レストランやカフェ、自宅などで広く食べられています。

2. ドドリア (Dodoria):
   - 説明: ドドリアは、鳥山明による漫画『ドラゴンボール』に登場するキャラクターです。彼はフリーザ軍の幹部で、強力な戦士として描かれています。
   - 外見: ピンク色の肌を持ち、筋骨隆々の体格で、顔にはいくつかの突起があります。
   - 性格: 残忍で冷酷な性格として描かれており、主人公たちと敵対する存在です。

以上のように、「ドリア」は食べ物であり、「ドドリア」はフィクションのキャラクターです。それぞれ全く異なる文脈で使われます。

ChatGPT o1 pro mode(約3万円)

概要:
「ドリア」は日本で生まれた洋食風のオーブン料理で、ホワイトソースをかけたバターライスの上にチーズをのせてオーブンで焼いたものが一般的です。一方、「ドドリア」は『ドラゴンボール』シリーズに登場するフリーザ配下の戦闘員で、ピンク色の肌を持つ屈強なエイリアンの戦士として描かれています。

詳細な違い:
呼称・由来:
ドリア:
「ドリア」は元々スイスの都市「ドリア」に由来するとの説や、日本のホテルニューグランドでシェフが考案した際の由来が様々語られていますが、現在の日本では「グラタン風のライス料理」のイメージが定着しています。
ドドリア (Dodoria):
「ドドリア」は鳥山明の漫画『ドラゴンボール』に登場するキャラクター名で、食べ物由来のネーミングが多い同作品において、「ドドリア」の元ネタは果物「ドリアン」からきていると考えられています。

分類・性質:
ドリア:
洋食・イタリアン風の料理ジャンルに属します。米料理の一種で、ホワイトソース、チーズ、様々な具材(エビ、ホタテ、鶏肉、ほうれん草など)が用いられ、オーブンで焼き上げることでこんがりとした表面とクリーミーな中身が特徴となります。
ドドリア:
漫画・アニメ作品『ドラゴンボール』のキャラクターで、作品中では悪役サイドの戦士として登場します。戦闘力は高いものの、冷酷非道かつ粗暴な性格が特徴的であり、主人公サイドの敵役として描かれます。

文化的影響:
ドリア:
日本で独自に発展した洋食メニューの一つとして、家庭料理やレストランメニューとして広く普及し、そのクリーミーな味わいと食べ応えから日本人に愛されています。
ドドリア:
世界的に人気を博した『ドラゴンボール』シリーズに登場するキャラクターであり、多くの読者・視聴者には「フリーザ軍の一員」として認知されています。食文化とは無関係ですが、作品自体が世界中で親しまれているため、それなりの知名度を持っています。

まとめ:
「ドリア」は食べ物、「ドドリア」はフィクション作品のキャラクターというように、まったく異なるジャンルで用いられる言葉です。前者は美味しい洋風オーブン料理、後者は人気漫画・アニメに登場する戦闘員として、その性質やイメージも大きく異なっています。

比較

情報の深さや説明の丁寧さに違いが見られました。無料版はシンプルで分かりやすく、気軽な疑問に答えるのに便利です。一方、有料版は背景知識や詳細な情報がしっかり補足されており、より深い理解を求める場面で役立っていますね。この違いを踏まえて、次の質問でさらに具体的な比較を見ていきましょう。

問題2

Q: ナシゴレンキマグレンの違いはなんですか?

GPT-4o mini(無料版)

ナシゴレン(Nasi Goreng)は、インドネシアを代表する炒めご飯料理です。主な材料はご飯、鶏肉やエビなどのたんぱく質、野菜、卵、そして特有のソース(ケチャップマニスやサンバルなど)です。これらの材料を一緒に炒めて、独特の風味と味わいを持つ料理です。

キマグレン(Kimaguren)は、日本の音楽デュオです。メンバーはISEKI(伊勢木卓己)とKUREI(栗原暁)で、2005年に結成されました。彼らはポップス、レゲエ、ヒップホップなど多様な音楽スタイルを取り入れた楽曲を制作し、特に「LIFE」という曲が広く知られています。

簡単にまとめると、ナシゴレンはインドネシア料理の一種であり、キマグレンは日本の音楽デュオです。それぞれ全く異なる分野のものです。

ChatGPT o1 pro mode(約3万円)

違いの概要
「ナシゴレン」と「キマグレン」は全く異なるカテゴリーに属します。
ナシゴレン(Nasi Goreng):インドネシア発祥の炒めご飯料理
キマグレン(Kimaguren):日本の音楽ユニット(男性デュオ)

詳細
語源と由来:
ナシゴレン:インドネシア語で「ナシ(Nasi)」は「ご飯」、「ゴレン(Goreng)」は「揚げる・炒める」を意味し、その名の通り「炒めご飯」を表します。
キマグレン:グループ名としての「キマグレン」は、彼らが自身を「気まぐれ」なスタイルと音楽性で表現することから来ており、英語ではないものの「気まぐれ(kimagure)」という日本語の感覚を反映しています。
ジャンル・カテゴリー:
ナシゴレン:料理・食文化。インドネシアやマレーシアなど東南アジアを中心にポピュラーなメニューで、日本国内でもエスニック料理店やカフェなどで提供されることがあります。
キマグレン:音楽ユニット。2000年代後半〜2010年代にかけて活動が目立ち、「LIFE」などのヒット曲で知られています。

本質的な違い:
ナシゴレンは「食べ物」であり、主に味覚や食文化の領域に属する存在。
キマグレンは「人間(アーティスト)」から成る音楽的表現者で、聴覚的な楽しみやエンターテインメント性が重視される存在。

まとめると、「ナシゴレン」は国際的に愛されるインドネシア料理であり、「キマグレン」は日本で活動していた音楽デュオであるため、両者は食べ物と音楽アーティストという全く異なる分野に位置しています。

比較

問2でも、無料版はシンプルに要点をまとめ、有料版は語源や背景まで詳しく解説するなど、スタイルの違いが際立ちました。無料版は手軽さが魅力で、有料版は深い理解を求めるときに最適です。次の質問でも違いがどう現れるのか楽しみですね。

問題3

Q: JavaJavaScriptの違いについて、よくエンジニアが「インドとインドネシアぐらい違うよ〜」と言うことがありますが、これはセンスの良い答えなんでしょうか?

GPT-4o mini(無料版)

「JavaとJavaScriptの違いを説明するのに『インドとインドネシアぐらい違う』という表現」は、センスの良い答えとされています。なぜなら、これらの言語は名前が似ているものの、技術的には非常に異なっているからです。この比喩は、名前が似ているだけで内容が全く異なるという点を強調しています。

### JavaとJavaScriptの主な違い:

1. 起源と開発者:
   - Java:サン・マイクロシステムズ(現在はオラクル)によって開発されました。
   - JavaScript:ネスケープによって開発され、現在はECMAインターナショナルによって標準化されています。

2. 用途:
   - Java:主にサーバーサイドのアプリケーション、Androidアプリの開発、デスクトップアプリケーション、組み込みシステムなどで使用されます。
   - JavaScript:主にウェブブラウザ内で動作し、クライアントサイドのインタラクティブな機能を実現するために使用されます。また、Node.jsを使ってサーバーサイドでも使用されます。

3. 実行環境:
   - Java:JVM(Java Virtual Machine)上で動作し、プラットフォームに依存せずに動作します。
   - JavaScript:ウェブブラウザ上で動作しますが、Node.jsを使うことでサーバーサイドでも動作します。

4. 構文と特性:
   - Java:クラスベースのオブジェクト指向プログラミング言語です。静的型付けが特徴です。
   - JavaScript:プロトタイプベースのオブジェクト指向プログラミング言語で、動的型付けが特徴です。

このように、JavaとJavaScriptは名前こそ似ているものの、技術的には大きく異なるため、比喩的な表現である「インドとインドネシアぐらい違う」という説明は非常に適切でわかりやすいものです。

ChatGPT o1 pro mode(約3万円)

エンジニア界隈で、「JavaとJavaScriptはインドとインドネシアくらい違う」という表現は、しばしば冗談めかして使われます。

このたとえは「名前が似ているが、実態は全く別物」という点を強調するためのものです。
JavaとJavaScriptは両方とも「Java」という単語が含まれているため、初心者には関連があるように思えますが、実際には用途、設計思想、言語仕様、実行環境など、ほぼすべてが異なります。
同様に、「インド(India)」と「インドネシア(Indonesia)」は名前こそ似ていますが、地理・文化・民族・歴史など多くの点で異なる独立した国です。

このたとえが「センスが良い」かどうかは文脈や受け手にもよります。
技術者同士の軽いジョークとしては、十分にウィットに富んでおり、「似た名称だからといって近しい存在とは限らない」ことを瞬時にわかりやすく表現しています。

一方で、あまりにも短絡的な比較であり、文化的背景や国際関係といった現実世界の複雑さを考慮せずに用いる場合、安易すぎる印象を与える可能性もあります。

総じて、この表現はエンジニア同士のカジュアルな会話の中では、それなりに「センスがある」と見なされることが多いでしょう。
ただし、公式の場や、国の比較がデリケートな問題になるような文脈では避けたほうがよいかもしれません。

比較

問3では、無料版と有料版の回答の焦点に違いが見られました。無料版は主に技術的な違いを詳しく説明し、JavaJavaScriptの用途や構造の違いを明確に伝える内容でした。
一方、有料版は「インドとインドネシアぐらい違う」という表現そのものに注目し、そのセンスや使われる文脈に焦点を当てています。技術的な比較というより、言葉の持つ意味や適切な使い方を深掘りしており、視点の広がりが特徴的でした。それぞれのモデルが異なるアプローチで問いに答えているのが興味深いですね。

追加機能まとめ

o1 pro modeとadvanced Voiceモード無制限アクセス

さて、上記の3つの比較で、有料版の回答がいかに専門的・包括的かを感じていただけたと思います。ここで最後に、公式サイトから得たChatGPT Proの追加機能を簡単にまとめましょう。 ChatGPT Proで追加された機能は「o1 pro mode」「advanced voiceモード(無制限アクセス)」の2つです。

o1 pro mode

公式サイトによれば、ChatGPT Pro(o1 pro mode)は、「最も信頼性の高い応答をより長く考える、最もインテリジェントなモデル」へのアクセスを提供するとされています。
特にデータサイエンス、プログラミング、判例分析などの高度専門領域で、より正確で包括的な回答が得られるという外部専門家テスターの評価結果もあります。 さらに、数学や科学、コーディングにまたがる困難なMLベンチマークでも、o1 / o1-preview と比較して優れたパフォーマンスを発揮すると公式にアピールされています。

出典:Introducing ChatGPT Pro

advanced voiceモード(無制限アクセス)

advanced voiceモードは、音声入力や音声操作を通じて手を動かさずにGPT-4oへ質問できる機能です。バリエーション豊富な声のトーンを選べるため、雑談モードから落ち着いたアシスタント風まで、状況や目的に合わせて使い分けが可能です。雑談感覚で話しながら頭の中を整理できるのは大きな魅力だと感じます。

実際に音声でPdMの悩みを相談してみた

ここでは、「プロダクトを世界レベルで成長させるプロダクトマネージャーは何を学ぶべき?」というテーマを、音声でGPT-4oに相談している場面のスクリーンショットを掲載しています。 デフォルトでは音声の履歴が残らなかったため、あとで見返せるように、同じく音声で「内容を残しておいて」と設定しました。

実際に音声で会話してみた感想

実際に音声モードを利用してみると、手を動かさずに雑談感覚で質問ができるため、まだ思考がまとまっていない段階でも気軽に相談しやすい印象です。
さらに、声のキャラクターを切り替えられる機能が予想以上に面白く、同じ内容の回答でもイントネーションやアクセントが変わることで、不思議と受け取る印象が違って聞こえます。
そしてもう一つ驚いたのは、スクリーンショットをご覧いただくとわかるように、文字起こしされた回答がかなり“話し言葉”に近い口調になっている点です。
これまでのAIに比べ、会話の自然さが格段に向上していると感じました。正直、うちのAlexaとは比較にならないくらい快適ですね。

まとめ

本記事では、「GPT-4o mini(無料版)」と「ChatGPT o1 pro mode(約3万円)」の回答を比較し、その違いや特徴を検証しました。

前半では「ドリアとドドリア」「ナシゴレンキマグレン」「Java vs JavaScript」の3つの質問を通じて、無料版がシンプルでライトな回答を得意とする一方、有料版は由来や背景、コミュニケーション面の工夫など、より深い解説を行ってくれることがわかりました。

後半では、ChatGPT Proの「advanced voiceモード」を取り上げ、音声による質問が手軽にできるうえ、声のキャラクターを切り替えられる点がユニークだと感じました。
実際に使ってみると、考えがまとまっていない段階でも雑談感覚で問い合わせられるうえ、同じ内容の回答でもイントネーションやアクセントの違いから受け取る印象が変わるという、新しい体験が得られました。

ただし、月額約3万円という費用は決して安くありません。日常的な質問や問い合わせにはやや過剰かもしれませんが、専門的な問い合わせや高度なリサーチが頻発する現場であれば、十分に元が取れる可能性があります。

最後にChatGPT Pro(o1 pro mode)は、思考力と音声操作の快適さが融合した、頼れるアシスタントのような印象を受けました。どのプランを選ぶにしても、自分の利用シーンやROIをしっかり見極めることが、AIツールを賢く使いこなす近道だと感じます。

参考文献・リンク

半年間アジャイル開発に参画してみて学んだこと

こんにちは、フォースタートアップス株式会社のエンジニアの李です! 今年の4月に新卒で入社後、STARTUP DB(スタートアップデータベース)(以降SDB)の開発チームに参画し、半年経ちました。早いものですね。

(入社直後にこんな記事を書いています!もしよろしければ合わせてご覧ください!)

tech.forstartups.com

今回のテックブログでは、入社してからの半年間で体験したSDBチームのアジャイル開発についてまとめていきます。

  • SDBチームの雰囲気はどんな感じ?

  • アジャイル開発をどのように進めている?

本稿を通じて、これらの疑問が少しでも解消されれば幸いです!

目次

1. SDBチームのアジャイル開発の進め方

2. 行われる改善プロセス

3. チームポリシーの構築

4. まとめ

1. SDBチームのアジャイル開発の進め方

私たちSDBチームは1週間ごとにスプリントを設定し、かなり早いサイクルで開発を進めています。スケジュールは以下のようになっています。

1日目:スプリント開始とプランニング

リファインメント:大まかなタスクを分割、やることの詳細を決定。工数の見積もりに必要な調査を実施。

スプリントプランニング:各タスクにかかる工数を見積もり、1週間で達成するタスクを決定。

2〜3日目:開発とレビュー

各自担当するタスクを進め、随時レビューを行います。

4日目:リリース

基本的にコードレビューを終え、承認がついたタスクは即リリースし、リスクを小さく抑えています。

5日目(スプリント最終日):振り返り

スプリントで起きたことを振り返り、新しい課題とそれに対するTRYをチームで考えます。

技術的な振り返り:主にFindy Team+というツールを活用しています。中でも、サイクルタイム分析といってプロセス別の開発リードタイムを時系列で可視化しできる便利な機能があります。それらを用いてボトルネックを洗い出したり、タスクの進め方を見直します。

レトロスペクティブ(振り返り):スプリントの進め方の改善点やチームポリシーを見直します。振り返りの手法は「スピードカー」「闇鍋」「KPT」などを取り入れ、楽しみながら進行しています。(参考

チームポリシーと入っても必ず守らねばいけない、堅いようなものではありません。 もちろん特別に理由なければチームでルールを守りますが、変更が必要ならばその都度変更するといった非常に柔軟性あるチームの取り決めです。

2. 行われる改善プロセス

SDBチームでは、どのようなアジャイル開発の改善プロセスが行われるのか、私が経験した失敗と合わせて紹介していきます。

出来事

実務に参画してからおよそ4か月が経った頃、私が原因でスプリントゴールが未達成になってしまったことがありました。

SDBはElasticsearchという全文検索エンジンを使用していますが、当初私はキャッチアップの難しさから関連タスクを敬遠していました。 あるスプリントプランニングで、Elasticsearchの検索ロジックを作成するタスクがゴールに設定され、私は「挑戦してみよう」と意気込んでこのタスクを取りました。

実際に取り組んでみると、予想以上に難しく、参考コードがあるとはいえ、理解するのに丸二日を費やしてしまいました。それでも「急げばまだ間に合うかも」と考え、チームメンバーと相談せずそのまま進めてしまいました。結果、プルリクエストを出せたのはスプリント最終日の終業時刻3時間前でした。

その後チームメンバーが集まってその場でレビューをしていただけましたが、タスクの要件を満たせていないことと、大量の修正箇所が見つかりました。間に合わないことを上長に報告し、スプリント未達成となりました。

個人の振り返り

振り返ると、早い段階で「間に合わない」と共有できなかった原因は以下のような理由からです。

  • 足を引っ張りたくない:スプリントゴールはチームで決めた「約束」です。それを守れないと、エンジニアチームだけでなく他の部署にも迷惑がかかると感じました。

  • もしかしたら間に合うかも:経験がない領域にも関わらず、「希望的観測」に頼ってしまいました。これは心理的な現象で「楽観バイアス」と呼ばれています。心理的な負荷がかかった際に、安定のため自分に都合の良い結果を無意識に期待してしまう傾向があるそうです。

チームメンバーからのフィードバックと改善策

振り返りでは以下のアドバイスをいただきました。

  • スプリントゴールはチームで決めた約束だが、早い段階で『間に合わない』と共有できればヘルプに入れるし、ゴール達成が可能になる。

  • タスクをやりきる責任も重要だが、「間に合わない」ことを担当者個人だけの失敗として抱え込まないでほしい。

  • 私たちは開発チームだけでなく、営業チームやデータベース運営チームと一体となってユーザーに価値を届けている。そのため、チーム全体の成功を目指して行動してほしい。

この振り返りを受けて、以下のようなTRYが挙げられました。

  • 1日目にPR(プルリクエスト)を出す見通しを立てる

  • 2日目にPRが出ていなければヘルプを要請する

  • PRが出ていない場合はチームメンバーが声をかける

  • 進捗状況をSlackの専用チャンネルにて共有する

チームは「誰がやっても同じ結果が出せる安定した仕組み」を目指し、改善策の議論を進めてくれたのです。このTRYを意識することで、今ではスプリントを安定して達成できるようになりました。

このように、課題があってもチーム全体で解決に取り組み、成果を出せる環境が整っています。失敗を次の改善につなげる仕組みが定着したことで、個人の成長だけでなく、チーム全体の信頼感も高まっています。

3. チームポリシーの構築

「1. SDBチームのアジャイル開発の進め方」にて紹介した5日目(スプリント最終日):振り返りについて紹介しようと思います。 SDBチームでは、振り返りを行うたびに、チームポリシーを更新しています。実際に使われている下記の例をご覧ください。

Problem1: レビューと修正の往復でApproveまでが長い

背景:担当者やレビュワーがそれぞれのタイミングで作業を進める運用をしていました。そのため、コード修正や修正点の確認が迅速に行えず、作業が翌日に持ち越されることが頻発していました。

Action:スプリント2日目にレビュー会を開催

Findyのサイクルタイム分析を元にした技術的な振り返りを経て、チームポリシーとしてスプリント2日目に1時間のレビュー会を設けました。レビュー会では、レビュワーがチケット担当に対し口頭で修正箇所を伝え、チケット担当者はその場で修正を行います。

結果:レビュー+修正の往復が短縮されただけでなく、進捗が遅れているタスクも早期に発見できるようになりました。

Problem2: 進捗共有が不足

背景:タスクの進捗状況をその日の終わりに専用チャンネルにて共有する習慣はありました。しかし、内容が確認されず放置されがちでした。

Action:朝会で進捗確認の時間を設ける

結果:メンバー全員がどのタスクで詰まっているか、誰が手が空いているかを把握しやすくなり、助け合いが促進されました。

非常にシンプルですが、problemが書いてあることによって、なぜこのチームポリシーを守った方がいいのかが明確なため、実行に移しやすいです。

チームポリシーが形骸化しないために

毎週新しいルールを追加し続けると、それを守ること自体が負担となり、ポリシーが形骸化する恐れがあります。そのため、チームでは各ポリシーに対して「継続」「定着」「廃止」のstatusを設け、ルールの実効性を確認しながら運用しています。

  • 継続:Actionに記載された取り組みを試行している段階

  • 定着:ルールがチーム文化として定着し、意識せずとも守られる段階

  • 廃止:他に良い方法が見つかった、または試行したものの課題解決に至らなかった場合

振り返りでは現行の各ポリシーのステータスが適切かを定期的に話し合う時間を設け、必要に応じて見直しています。この仕組みにより、ポリシーが形式的なものに留まらず、チームの実状に応じた内容へと最適化し続けることができます。

また、ポリシーごとの現状を把握し、チームで定期的に話し合う場を設けることで、各自の意見や提案も取り入れやすくなります。これにより、メンバー一人ひとりが主体的にポリシー運用に関わる意識が育ち、形骸化することなく、実際に機能するポリシーとして活かされています。

4. まとめ

SDBチームのアジャイル開発には、単に効率的な進行だけでなく、メンバー個々の成長やチーム全体の連携を促すための多くの工夫が盛り込まれています。

高速なトライ&エラー

1週間という短いスプリントサイクルでの開発は、成功と失敗のフィードバックが速く、次に繋げやすい環境です。失敗から学び、それをすぐに改善に結びつける姿勢が、私たちのチーム文化に根付いています。これによって、個々のエンジニアが日々成長できる場が提供されていると感じています。

助け合いとチームワーク

アジャイル開発では、メンバー全員が目標に向かって協力する姿勢が求められます。日々の進捗共有や振り返りを通じて一体感が生まれ、各自が互いに支え合う信頼関係が築かれています。

成長しやすい環境

振り返りやポリシーの見直しは、チームの成長を促す上で重要な役割を果たしています。改善プロセスを実践し続けることで、個人のスキルアップだけでなく、チームのパフォーマンス全体も向上しています。形骸化せずに柔軟に変化を続けるポリシー運用のおかげで、アジャイル開発が実際の業務に密着したものとして機能している点も特徴です。

このように、SDBチームは一人ひとりが挑戦と成長を続けられる環境です。半年間で培った経験を活かし、さらなる高みを目指して、日々の取り組みを積み重ねていきます。

当社では、エンジニアを募集しています。アジャイル開発に興味がある方、成長意欲のある方、ぜひ私たちと一緒に挑戦してみませんか?

herp.careers

P.S

最近オフィスが麻布台ヒルズ 森JPタワー 31Fに移転しました!

www.forstartups.com

窓から見える景色がものすごく綺麗です!

開発に行き詰まった時なんかは、窓側の席に移ってリフレッシュしています!

alt属性” class=

(夕方に撮った写真)

業務の困りごとを自作のChrome拡張機能で解決しました!

目次

はじめに

こんにちは!フォースタートアップス株式会社のエンジニアの山﨑(@flashlight999)です。 皆さん、日々の業務で「この作業、なんとかならないの?」と感じることはありませんか? 私もそんな悩みを抱えながら、ある日ふと思いつきました。

「それなら、自分でツールを作ればいいんじゃない?」

そこで挑戦したのが、Chrome拡張機能の開発です。 この記事では、私が開発した拡張機能を使ってどのように課題を解決したのか、そしてその成果についてご紹介します。 興味のある方はぜひ以下のリンクから使ってみてください👇

chromewebstore.google.com

解決したい課題

私の所属するチームでは、PRレビューの際にSlackのチャンネルでPRのURLとPR元のチケットURLを開発者に共有する運用をしています。具体的なフローは以下の通りです。

  1. GitHubでメンションをつけてレビュー依頼を出す。
  2. SlackのチャンネルでPRのURLとPR元のチケットURLを共有する。

このプロセス自体は明確なのですが、SlackでPRレビューを依頼する際にリンクを作成する手間が悩みの種でした。

具体的には、次のような問題がありました。

  • 画面切り替えの多さ

    チケット情報を確認しながら、Slackのリンク作成画面に「タイトル」と「URL」を手動で入力する必要があり、その際にブラウザとSlackを何度も行き来しなければなりませんでした。

  • 手動入力の煩雑さ

    チームでは、リンク先をわかりやすく表現するために、テキストリンクを作る文化があります。そのため、リンク作成ボタンを使って1つ1つ手動で設定するのが非常に面倒でした。

「この手間を何とか削減できないだろうか?」 そう考え、課題を解決するための方法を模索し始めました。

解決策の検討と具体化

課題を解決するために選んだのが、Chrome拡張機能の開発です。

Chrome拡張機能を選んだ理由

  • 技術的に簡単

HTML、CSSJavaScriptだけで作れるので、特別なスキルは不要。

  • ブラウザ内で完結

作業がすべてブラウザ上で行えるため、相性が良い。

目指したのは、チケット情報(タイトルとURL)の自動取得と、Slack用のハイパーリンク生成を組み合わせたシンプルで便利なツールです。

開発プロセス

準備と学習

Chrome拡張機能の開発は初めてだったため、以下のように準備を進めました。

 参考にした記事はこちら👇

 Chrome拡張機能の実装(入門から公開まで) #JavaScript - Qiita

 実際に手を動かして、基本的な動作を理解しました。

実装の概要

実装の詳細はこちらのリポジトリから確認できます。

以下の機能を実装しました。

開発のフォルダ構成はシンプルです。

├── README.md
├── content-script.js
├── icons
│   ├── icon-128.png
│   ├── icon-16.png
│   └── icon-48.png
├── manifest.json
├── popup.css
├── popup.html
└── service-worker.js

主なファイルの役割は以下の通りです。

  • manifest.json

拡張機能の権限や機能の定義を行う設定ファイル。

  • content-script.js

ハイパーリンククリップボードにコピーする。

  • service-worker.js

コンテキストメニューを作成し、選択テキストを元にハイパーリンクを生成。

作った拡張機能の使い方を紹介

  1. Chromeウェブストアから拡張機能をダウンロードする。

  2. テキストを選択してリンクを生成。以下のいずれかの方法を選べます。

    • 方法1: コンテキストメニューを使用
      テキストを選択した状態で右クリックし、コンテキストメニューから「Create Hyperlink」を選択。

    • 方法2: ショートカットキーを使用
      デフォルトのショートカットキーを使ってリンクを生成

      • Windows/Linux: Ctrl+Shift+K
      • Mac: Command+Shift+K
        ショートカットキーはchrome://extensions/shortcutsから自由にカスタマイズできます。
  3. 生成されたリンクをSlackにペーストするだけで完了!

開発の成果

このChrome拡張機能によって、次の成果が得られました。

  1. 画面切り替えの削減

    ブラウザとSlackを行き来する必要がなくなりました。

  2. 操作手順の簡素化

    リンク作成が「選択→クリック→ペースト」の3ステップで完了。

  3. ストレス軽減

    「また手動で入力するのか…」という憂鬱が完全に消えました!

公開の手順

Chromeウェブストアに公開する際は、次の3ステップを踏みました。

  1. アカウント登録

    デベロッパーアカウントを作成($5の登録料が必要)。

  2. 情報入力

    公開予定の拡張機能の紹介文やスクリーンショット、アイコンを登録。

  3. 審査プロセス

    審査は約1週間。もし不合格でも、修正ポイントが明確に伝えられるので安心です。

おわりに

今回のChrome拡張機能の開発は、技術を使って業務を効率化する楽しさを改めて実感する機会となりました。 みなさんも、日々の小さな困りごとに目を向けて、改善のきっかけを作ってみてはいかがでしょうか?この記事が、その一助になれば幸いです。

もしこの記事が参考になったり、試してみたいと思った方は、ぜひダウンロードして使ってみてください👇

chromewebstore.google.com