スプーキーズのちょっとTech。

SPOOKIES社内のより技工的な、専門的なブログページです。

【開発合宿in那須塩原】成果物発表~~~!!後編

こんにちは!アルバイトのガマ🐸です!!
開発合宿 in 那須高原(2泊3日) の後編をお届けします!

前回のブログでは、Aチーム・Bチームの成果をご紹介しましたが、 今回はいよいよ Cチーム・Dチーム・Eチーム の成果物をご紹介します!!

どのチームも、テーマである

「定量化が難しいものを、定量化・可視化する」

に真正面から挑んだ力作ぞろいです💪


 

各チームの成果物紹介(後編)

ここからは、Cチーム・Dチーム・Eチームの成果物をご紹介します!

Cチーム

日報作成ツール「にぽ」

「にぽ」は全く新しい形での日報作成を提案するアプリケーションです。一見すると怪しげな名前ですが、これはチームメンバーが毎回の日報入力時に「にぽ」と times に呟くところから命名されたものです(「日報を書く」->「日報」->「にっぽう」->「にぽ」)。

さて、日報の入力はただただ面倒くさいという潜在的な問題を抱えていました。そしてその割には、社内であまり活用されておりません。長期的に見れば、形骸化した日報は意味のないルーティンだけを残し、日々の積み重ねによって決して小さくない損失を生み出していました。

我々のチームはこれらを同時に解決すべく、全く新しい入力インタフェースを供えた日報作成ツールを開発しました。

詳細

今回の合宿のテーマは「定量化しにくいものを定量化し、可視化する」でした。定量化しにくいものには、例えば感情や文章があります。我々はここに着目し、そして前から社内で指摘されていた日報の問題を組み合わせてプロダクトを開発することにしました。

我々はまず日報が抱えている問題を整理し、次のような問題が挙がりました。

  • 入力が面倒くさい
  • 日報が社内ナレッジベースである esa に統合されてしまっているためノイズが大きい
    • 意味のない(中身の薄い)日報がナレッジを汚染し、検索性の低下やデータの無為な肥大化を起こしている
  • 日報が活用されていない
    • 本来であれば、週次報告や四半期に一度開催される 1on1 に生かされているべきである

これらの問題から、我々は日報の入力を極限まで簡単にし、さらに日々の感情を数値化した上でトラッキングを行い、メンバー及びマネージャ双方がグラフィカルに閲覧できるツールにしていくことを決定しました。

最終的には、本ツールの 1on1でのフィードバックや自己マネジメント能力の養成への活用を目指していきます。

使用技術

フロントエンド

  • React + React Router DOM の SPA
    • Web 上で快適なページ操作性を実現するには SPA が最適との判断から
    • ページ遷移にかかるストレス、遷移の瞬停を避けたい意図
    • メンバーが React に慣れている
  • SCSS によるスタイリング
    • ロードの遮蔽や心地よい遷移を実現するため、アニメーションを多用している
    • アニメーションと tailwind などのユーティリティ志向 CSS フレームワークとの相性はあまり良くない

バックエンド

  • Bun + ElysiaJS でのRestAPI
    • APiを作成するうえで、一番簡潔に書きやすく開発しやすいTypeScript(JavaScript)を使用した
      • その中でも、Bunを使用したのは特にHttpサーバーとしてのパフォーマンスが良いため
      • ElysiaJSを使用したのはBunのAPIフレームワークの中でも有名で、情報が得られやすいため
  • OpenAPIによるAPI仕様の策定
    • 事前にOpenAPIで定義しておくことで、フロントエンドとバックエンドとのクリティカルパスを極力抑えれる
    • フロントエンドはOpenAPI-typescriptなどで簡単にAPI部分を作成できる
    • バックエンドはAPI仕様に合わせて処理を作成すればよい
      • win-winである

まとめ

他のチームはプロダクト志向が強かったものの、我々の成果物はツール志向だったため成果発表時にはやらかした...と思いました。しかし、成果物のコンセプトとデザイン、チームメンバーの見事なプレゼンによって見事投票によって優勝をいただくことができ、チーム一同大変嬉しく思います。

今後とも社内運用に向けて引き続き開発を進めてまいります!


Dチーム

まず、何を作ったの?

声のdBをスコアにするChrome拡張機能を作りました。 そのスコアを閲覧するためのウェブサイト、保存するためのBackendも作成しています。 実はサイト自体は見れます。

emolyze.nanasi-apps.xyz

作ったもの

  • Google Chrome 拡張機能
  • Website
  • Backend

もっと詳しく

アイデア

30分くらいでまっちゃんとまるさんとWeb3の方で構想を練りました。 最初に出たアイデアが声をスコアにするという物でした。 しかし実装の難易度的に終わる気がしなかったので、3案用意しました。 実装難易度順で - 声をスコアに (1番難しい) - Slack のリアクションからスコア算出 - SlackやChatwork のチャットからスコア算出 の3つが出ました。 しかし、3社合同ということでもし使うなら全社で使いたいという話になり、声をスコアにすることに決まりました。

Chrome 拡張機能

ほぼ本体です。

機能

  • 音声の録音機能
  • 音声をdBにする
  • しゃべってるユーザーを紐付け

などの機能があります。 ChromeのTabCaptureという機能を使用して録音しています。 また、Gather完全対応という話をしたように、Gather上の通信を引き抜いて、playerActivelySpeaksイベントを拾い、話している人を抜き出しています。 地味に一番頑張った部分です。 その機構を地道に実装して、Google Meet等対応させていこうという計画です。

まっちゃん
  • 全てを実装。
  • Cursorくんありがとう。

反省点

  • めちゃくちゃコードが汚い。
  • 読めない。
  • AIを使うのが下手で、最低限動くものしかできなかった。
    • 上手く使えていればブラッシュアップできたのに...
  • 全ての責務がこの拡張機能にある。
    • 音声の処理がCloudflareではできないので、拡張機能にやらせていた。
    • 最悪ではある。
    • しかし最善ではあった。
    • ただし判断が遅かった。

Frontend

Cloudflare Pagesを使用しています。 まるさんに作ってもらいました。 BackendからAPIを適当に繋いで、適当に繋ぎ込みをしました。 デザインの案を適当に紙に書いて、これがいい!と言っただけで完成していて本当にびっくりしました。

まるさん
  • モックデータを表示する、ベースとなるフロントエンド
まっちゃん
  • ベースを使用して
    • 残りのAPIの繋ぎ込み
    • デザインの微調整

反省点

  • データが1つしかなくて映えなかった。
    • モックデータを突っ込むべきだった。

Backend

Cloudflare Workers と Cloudflare D1を使用して、いい感じにスコアを保存するBackendを作成しました。 無料です。 まじでただ保存するだけなので、特筆すべき点は特にありません。

まっちゃん
  • 全て。
  • Cursorくんに感謝

反省点

  • PrismaなどのORMを使用していません!
  • SQL直書き!!!!!!!
    • これが良くなかった.....

プレゼン資料

Web3の方とまるさんがめちゃくちゃ良い感じに作ってくれました。

まっちゃん
  • 実際のところ、私はほぼやっていないので特にないですが、作ってくれたものがとても良かったです

何を意識したの?

まっちゃん

特に時間は意識しました。(まっちゃん比) アイデアは比較的にすぐ出ましたし、実装もすぐ始めましたが、見積もった8時間を超えないように、色々なペース配分を頑張りました。 また、実現可能かを入念に調べることで、時間を有効的に使うことができました。

反省

  • 上で時間を意識したと書いたものの、実際は見積もった時間をオーバーしてしまった
    • その分、別のところで巻き返したりできたから良かったですが、できていなかったら危なかった。
  • 細かいことが気になりすぎて、大変でした
    • 大変でした。
    • 多少目を瞑るということが大切なことを知りました。
    • 大半これで時間を潰してしまいました。

まとめ

上の反省で時間がどうのと書いたものの、実際のところ全ての工程を含め、8.5時間で品質はどうであれ、難易度が高い課題をこなすことができたと思っています。 しかし、細かいことに目を瞑ることも大切ということがわかりました。


Eチーム

私たちのチームは「会議の無駄を可視化するシステム」の開発に取り組みました。

背景

普段の会議で以下のような問題を感じることがありました。

  • 会議の目的から逸れた話をずっとしている
  • 自分に関係のない会議に参加させられる

そこで、会議内容を分析し「有意義」と「無駄」をグラフ化したり、誰がどのくらい話しているかを可視化するシステムを開発することで、効率的な会議や参加者適正化を実現することを目指しました。

使用技術

  • バックエンド:PHP
  • UI:Tailwind CSS
  • 字幕抽出:FFmpeg
  • AI分析:OpenAI API
  • データ可視化:Chart.js
  • 開発支援:Cursor

仕組み

開発したシステムは以下の流れで動作します。

  1. データ入力:議題や参加者情報(名前、関係する議題)の入力、Google Meetの録画ファイルのような、発言者情報付きの字幕が含まれた動画のアップロード
  2. 字幕抽出:FFmpegを用いて動画から字幕を抽出し、「いつ、誰が、何と発言したか」というデータのリストを生成
  3. AI分析:抽出した発言データと議題や参加者情報をOpenAI APIに送信し、会議内容を分析
  4. データ可視化:分析結果から以下の内容を表示
    • Chart.jsによる各人の発言割合を表す円グラフ
    • Chart.jsによる有意義な発言と無駄な発言の割合を表す円グラフ
    • 会議の要約と改善提案

今後実装したい機能

今回は基本的な機能の実装に留まりましたが、今後以下の機能を実装したいと考えています。

  • 同じことを何度も言っていないかの検出
  • 無言が続いている時間の算出
  • 無駄と判定した箇所の表示
  • 参加者が会議と関係あるかの判定
  • ブラウザ上での字幕抽出と発言データ生成(動画アップロードの代替)
  • OpenAI APIを利用した、動画からの発言データ生成(発言者情報付きの字幕が含まれない動画のサポート)

直面した課題

開発中に最も時間を要したのは、OpenAI APIとの連携でした。チームメンバー全員がOpenAI APIを利用した経験がなく、正常なレスポンスが得られるようになるまでかなりの時間がかかってしまいました。

具体的には、429 - You exceeded your current quota, please check your plan and billing detailsというエラーが発生し続けていました。この課題に対して、チーム全員で協力して調査し、試行錯誤を重ねることで解決にたどり着きました。

解決のきっかけは、あるメンバーが貼ってくれた、正常なレスポンスが得られるcurlのログでした。curlとプログラムのリクエストボディを見比べたところ、モデルになぜかgpt-3.5-turboが指定されていることが判明。これをgpt-4o-miniに修正することで問題が解決しました。

感想

今回の開発合宿を通じて、多くの学びを得られました。

技術面では、Cursorによる開発効率向上の効果を体験することができました。

プロジェクト管理面では、時間制約の中での優先順位付けや軌道修正の重要性と、進捗共有の大切さを学びました。特に、行き詰まった時こそ積極的に状況報告を行い、チーム全体で解決策を探ることの価値を実感しました。

最も印象深かったのは、オフィスや勤務形態の違いで普段顔を合わせることのないメンバーと、協力して開発に取り組めたことでした。この過程で、技術的な学びと同じくらい貴重な交流を深めることができました。


 

最後に

「定量化が難しいものを、定量化・可視化するサービスを考え、制作する」という
難易度の高いテーマでしたが、 各チーム面白いアイディアが沢山出てきましたね!!

今回の開発合宿を通じて得た学びや経験は、今後のプロジェクトにも活かしていきたいと思います!

また次回、さらに面白いテーマで合宿ができることを楽しみにしています!

参加メンバーの皆さん、本当にお疲れさまでした!
そして、ここまで読んでいただきありがとうございました!