🏃

Thinkings ハッカソン2025で"業務改善"を本気でプロトタイピングしてみた

に公開

はじめに

2025 年 6 月末、弊社 Thinkings にて社内ハッカソンが開催されました。
筆者も一エンジニアとして参加し、業務改善のツールとして日報管理ツールを開発しました。ツールの要件定義の過程や、普段業務で触ることのないプロダクトの活用など学びも多かったので、イベントの紹介と開発過程の記録として記事を執筆します。

こんな人に読んでほしい

  • 社内ハッカソンがどういうものか知りたい人
  • エンジニアが要件定義から開発までを担当したプロセスに興味がある人

Thinkings のハッカソン紹介

開発テーマは

「こんなツール、あったらいいな」をカタチにする ​ 業務改善ツールを開発せよ!

です。
副題には、「業務改善ツール」という身近なテーマを通じて、エンジニア以外の社員も含めた全社員に「開発」をより身近に体感してもらうという狙いがあります。

一般的なハッカソンは、筆者としては
「エンジニアによる、エンジニアのためのイベント」
という印象が強いですが、今回のハッカソンはエンジニア以外の社員も含めた得点投票形式で優勝チームを決定するようにしました。

これにより、以下の要素が重要になりました。

  • エンジニア以外の社員にも刺さる、価値が理解できるプロダクトであること
  • 最終発表の場で「開発物がどれだけ業務改善できるか」をアピールすること

開発方針の観点が増え、特徴のあるハッカソンになったと感じています。

開発物

開発の動機

現在、Thinkings では日報の管理を NotePM というナレッジマネジメントツールを用いて行っています。
NotePM とは Qiita のようにマークダウン形式で記事を作成できるナレッジマネジメントツールであり、弊社では日報以外にも業務にかかわる資料の保存に利用しています。

日報の場合は 1 日 1 ページでその日のタスクを記録し、月末にツールを使って作業時間を集計しています。

この方式では、以下のような課題がありました。

  • 集計のためにタスクに紐づく案件のリンクを都度調べてコピペする必要があり、リンクを探す手間が大きい
  • 過去の日報を探すとき、NotePM の記事検索の機能では簡潔に絞り込めない
  • 業務にかかわる資料を検索した時、日報も検索結果に表示されてしまい目的の資料を探しにくい

解決策

私たちのチームは、これらの課題を解決する専用の日報管理ツールを開発しました。
主な改善点:

リンク選択の簡素化:候補から選択する形式で手作業を削減
カレンダー表示:過去の日報を視覚的に一目で探せる
専用化による分離:業務資料と日報の混在を解消

最終成果物の詳細

画面は、カレンダー形式の日報一覧のほか、日報の新規作成・編集機能や月末の集計用画面などを備えています。

技術的なミソは、monday.com を DB のように運用してみた点です。(以後 monday と呼びます)

monday とはプロジェクト・タスク管理やワークフロー管理のためのプロダクトで、アイテムをリストで管理し、アイテムごとにユーザーや状況といったカラムを追加することで情報を一元管理できます。
弊社のエンジニア組織では主にエンジニアと PdM などの企画サイドとの間でタスクを管理・共有するためのツールとして用いています。

mondayは本来プロジェクト・タスク管理ツールですが、アイテムをリスト管理し、カラムで情報を一元管理できる特性を活かしました。弊社ではエンジニアと企画サイドのタスク共有に使用しているため、慣れ親しんだツールでした。
この選択は、将来的な運用開始時の移行期間も考慮したものです。既存運用との両立を図るため、やや特殊な技術選定となりましたが、実用性を重視した判断でした。

技術スタック

技術・プロダクト・言語 使用箇所など 備考
TypeScript, Next.js メインの画面作成など 基本的な画面の作成、API の呼び出しなどに使用。
弊社のプロダクトでも一般的な言語・フレームワークであり選定のハードルが低かった。
monday.com プロダクトにおいては DB のように使用、基本的な作成・削除・参照・編集などは GraphQL を用いて実現。 弊社でのタスク管理において一般的なツールであり、ツールを介さずに情報を確認しても内容が理解しやすいと考えたから
PowerAutomate 日報未記入者にその旨をメンションするために活用。 PowerAutomate とは MS のワークフロー自動化ツール。弊社でメジャーな連絡手段である Teams にて、日報未記入者にその旨をメンションするために活用。
メールと違い業務中に開いていない人は稀なので通知見逃しを防げるはず。
Vercel v0 画面を作り始めるときなど大部分のデザイン・ロジック周りを作成してもらう あるメンバーから、React と Next.js の親和性が高いとの提案を受け、実際に試用した結果、期待以上の効果が得られたため正式に採用しました。プロジェクトの終盤にかけても、Next.js の機能には多くの場面で助けられました。

なお、開発過程においてコーディングや作業効率化のために一時的に使用したものの、最終的なプロダクトには組み込まれなかった技術要素は以下の通りです。

技術・プロダクト・言語 使用箇所など 備考
Cline + OpenAI o3-mini コーディングエージェントとして一部使用 コーディングエージェントもといプロダクト内で AI を使いたい場合用に、運営から Azure OpenAI Service のエンドポイントが配布されていた。業務では扱えないしせっかくなので使ってみた感じ。v0 に比べると使用は限定的だった。
Miro 仕様検討 リームでの共同作業のためのオンラインホワイトボードツールであり、こちらも弊社で一般的なツールのため選定。ブレストっぽく意見を出す場合は使いやすいと感じている。

丁寧に各技術のリンクをつけていたらなんだか商品紹介みたいになったな...

要件定義の過程

要件定義は Miro を用いて進めました。
テーマ発表からハッカソン当日まで約 2 週間ほど時間がありましたので、その間に、大まかな実現したい内容を整理しておきました。その後、ハッカソン当日にそれぞれ意見を持ち寄ってブラッシュアップ・取捨選択・優先度付けを行いました。

みんなが考えてきた要件(黄色やオレンジ)をブラッシュアップ(緑)する図

また、メンバーの中には日報を日常的に運用しているチームとそうでないチームが混在しており、現状の日報運用に関する課題について意見交換を行う機会がありました。

弊社の日報運用では、有給休暇を取得した際にその旨を日報上で明記する運用となっていますが、今回開発するツールでは、誰がいつ有給を取得予定かを自動で取得できないかという点が議論となりました。

メンバー間で知見を持ち寄った結果、弊社では有給の予定が「monday」と「Outlook」の 2 つのツールで管理されていることが判明しました。
どちらのプロダクトから情報を取得するのが適切かについて活発な議論が交わされ、要件定義を行っているかのような密度のあるディスカッションとなりました。

有給の情報は monday でも管理している、という見落としを発掘した図

開発

先述の通り、この日報アプリは DB、データの管理を monday に一任する形で実装しています。
具体的には monday が提供している GraphQL 経由で monday のボードのアイテムを読み書きする形です。

「誰の日報なのか」を管理する必要があったためログイン機能を実装しましたが、monday のアクティブユーザー取得クエリを活用することで、ログイン可能なユーザーの管理を簡潔に実現できました。

日報管理の例、アイテムに紐づくサブアイテムを複数作れるのでその日のタスクの管理も 1 ボードで済む

monday 側には公式ドキュメントが用意されていたものの、チーム内に GraphQL の経験があるメンバーがいなかったため、仕様の理解に時間を要しハッカソン期間中もたびたび躓く場面がありました。

発表・最終形

私のチームは受賞を逃しました...
前述の通りハッカソンの最後は成果物の発表に対する得点投票で順位を決めたのですが、なんと発表中に RuntimeError が発生してアプリが落ちるという大アクシデントが...笑

このハプニングをトーク力で笑いにもっていってくれた発表担当の方には感謝してもしきれません。

最後に

以上が、Thinkings ハッカソン 2025 への参加記録となります。
今回で 5 回目の開催となった本ハッカソンには、総勢 35 名のエンジニアが参加し、期間中は業務をストップして開発に取り組んだ結果非常に印象深いイベントとなりました。

筆者自身にとっては、これまで触れる機会の少なかった GraphQL について実践的に学ぶ良い機会となりました。また、普段の業務では関与することの少ない要件定義のプロセスも経験できるなど、多方面で学びの多い有意義なイベントとなりました。

最後になりましたが、弊社 Note にも当イベントの紹介記事があります。
是非合わせてご覧ください!

https://note.com/thinkings/n/nc66a09874cd7

Thinkingsテックブログ

Discussion