【ITニュース解説】ミニハッカソンをやってみたら有意義だった話

システムエンジニアを目指す皆さんにとって、開発現場のリアルな取り組みを知ることは非常に重要だ。今回は、株式会社Schoo（スクー）という企業が実施した「ミニハッカソン」というイベントについて詳しく解説する。ハッカソンとは、短期間で集中的にプログラムを開発し、成果を競い合うイベントのことだが、スクーでは「ミニ」という名の通り、業務の一環として小規模ながらも非常に実践的な開発体験を行った。この取り組みは、単に新しい機能を開発するだけでなく、エンジニアの技術力向上やチーム内のコミュニケーション活性化、さらにはユーザーへの価値提供といった、多岐にわたる目的を達成するために企画されたものだ。

スクーがこのミニハッカソンを実施した背景には、オンライン学習サービスとしてユーザーに「より使いやすいサービス」を提供したいという強い思いがあった。具体的には、ウェブサイトやアプリケーションが「軽快に動作し、見た目も美しく、直感的に使える」といった、ユーザーが快適にサービスを利用できる環境を追求することが第一の目的だった。これは「UI/UXの向上」と呼ばれ、ユーザーインターフェース（UI）とは見た目や操作方法、ユーザーエクスペリエンス（UX）とはそれらを通じて得られる体験全体を指す。 さらに、開発チーム内では、フロントエンドと呼ばれる、ユーザーが直接触れる部分の見た目や動きを作るエンジニアたちの技術力をさらに高め、新しい技術を学ぶ機会を提供したいという狙いもあった。エンジニアにとって、新しい技術に触れ、それを実際に動く形にする「アウトプット」の機会は成長に不可欠だ。また、開発チームだけでなく、サービスの見た目や使いやすさを専門とするデザイナーや、サービスの裏側のシステムを支えるバックエンドエンジニアといった他部署との連携を強化することも重要な目標の一つだった。異なる専門性を持つメンバーが協力することで、より良いサービスが生まれる可能性が高まるからだ。そして何より、開発者自身の「モチベーション向上」も大きな目的だった。普段の業務ではなかなか手を出せないような自由な発想で開発に取り組むことは、エンジニアの仕事への意欲を高める効果がある。

このミニハッカソンの企画は、約3週間という比較的短い期間で行われた。参加者はフロントエンドエンジニア6名で、これらを3名ずつの2チームに分け、さらにサービスデザインを担当するデザイナーが加わった。お題は「スクーのフロントエンド改善案を自由に、そして楽しく」というもので、既存サービスの問題点を洗い出し、その解決策を提案することが求められた。開発期間やチーム構成以外の具体的な技術スタック、つまりどのようなプログラミング言語やフレームワークを使うかは完全に自由とされた。最終的な成果物としては、ただアイデアを出すだけでなく、実際に動作するプロトタイプ、つまり試作品を作成することが必須とされた。このプロトタイプは、画面の遷移やデータの表示、簡単なデータ反映といった一連の動作が確認できるレベルのものが求められた。そして、最終的には経営層に対して、自分たちの提案と成果物をプレゼンテーションし、フィードバックを得ることがゴールとされた。

具体的な進め方としては、まず「キックオフ」と呼ばれる最初の会合が開催された。ここでは、ミニハッカソンの目的が改めて説明され、チーム分けが行われ、そして具体的なお題が発表された。その後、約3週間の開発期間がスタートした。開発期間の前半には、週に1回のペースでチームミーティングが設けられ、各チームの進捗状況を確認し合ったり、開発を進める上で困っていることや課題を共有し、解決策を話し合ったりした。開発期間の後半になると、デザイナーとの定例レビューが実施された。これは、開発中のプロトタイプについて、見た目の美しさや使いやすさ、ユーザー体験に関する専門的な視点からアドバイスをもらうための重要な機会だった。実際の開発作業は、それぞれのエンジニアの裁量に任され、チーム内で協力しながら進められた。 開発期間の途中には「中間発表」も行われた。これは、経営層や開発チーム全体に向けて、これまでの進捗状況や実現している機能、今後の展望などを報告する場であり、早期にフィードバックを得ることで、より良い最終成果に繋げる狙いがあった。そして、最後に「最終発表」が行われた。これは、開発チームだけでなく、経営層や全社に向けて、各チームが開発したプロトタイプと、そこに至るまでの思考プロセス、そして提案内容を詳細にプレゼンテーションする最も重要な機会だった。

このミニハッカソンを通じて、各チームはさまざまな具体的な成果を得た。まず技術的な面では、多くのエンジニアが新しい技術の習得に意欲的に取り組んだ。例えば、ウェブアプリケーション開発によく使われる「Next.js」というフレームワークや、静的な型付けを導入することで開発効率や保守性を高める「TypeScript」、そして効率的なCSS設計を可能にする「Tailwind CSS」といった技術が積極的に採用された。これらの新しい技術を使うことで、よりモダンで効率的な開発手法を学ぶ機会となった。また、ウェブサイトの部品を再利用可能なパーツとして設計する「コンポーネント指向」の考え方や、それをさらに体系化した「Atomic Design」という設計思想の導入も検討され、より整理された構造で開発を進めることの重要性を学んだ。状態管理ライブラリである「Zustand」の活用や、サービス間のデータ連携を行う「API」の利用方法についても実践的に学習できた。 ビジネスや組織への貢献という点でも大きな成果があった。ユーザー体験の向上に直結する具体的な提案が複数生まれ、サービスの改善に向けた貴重なヒントが得られた。チーム内のコミュニケーションは大幅に活性化し、普段の業務では交流が少ないメンバー同士でも、共通の目標に向かって協力し合うことで、一体感が生まれた。エンジニアのモチベーション向上や、自ら課題を見つけ解決策を考える主体性の育成にも繋がった。デザイナーとの連携も強化され、よりユーザー目線での開発の重要性を再認識する機会となった。経営層への直接的なアピールやフィードバックの機会は、開発チームの取り組みの価値を社内に示す上で非常に有益だった。さらに、既存システムの「技術的負債」、つまり古い技術や非効率な設計が残っていることへの意識が高まり、今後の改善に向けた議論が活発になった。

一方で、今回のミニハッカソンにはいくつかの反省点や改善点も見つかった。まず、約3週間という開発期間は、アイデア出しから実際の機能実装までを完璧に行うには短すぎたという声があった。特に、新しい技術を学びながら実装を進めるには、もう少し余裕が必要だったかもしれない。次に、お題の設定も難しさがあった。業務に直結しすぎると普段の仕事の延長になってしまうし、あまりに自由すぎると何から手をつけてよいか分からなくなるため、適切なバランスを見つけることが課題だった。 また、採用する技術スタックの選定について、参加者へのサポートが不足していたという反省もあった。自由度は重要だが、特定の技術に詳しくないメンバーへのガイドや、チーム間の技術格差を埋めるための支援があれば、よりスムーズに開発が進んだ可能性もある。成果物の評価基準が明確でなかった点も改善の余地がある。どのような点を評価するのかが事前に明確であれば、参加者はより目標意識を持って開発に取り組める。デザイナーの巻き込み方についても、より効果的な連携方法を模索する必要がある。さらに、技術的な専門知識を持つ「技術顧問」といった外部の専門家を巻き込むことで、より質の高いアドバイスやフィードバックが得られたかもしれない。

今回のミニハッカソンは、これらの反省点を踏まえつつも、全体としては非常に有意義な取り組みだったと評価されている。短期間で新しい技術を学びながら、実際に動くプロトタイプを作成し、それを社内外に発表する経験は、参加したエンジニア一人ひとりの成長に大きく貢献した。また、組織全体としても、ユーザー体験の向上に向けた具体的なアイデアや、部署間の連携強化、技術的な知見の共有など、多くのポジティブな影響をもたらした。スクーでは、このようなミニハッカソンを今後も定期的に開催することを検討しており、継続的にエンジニアの成長とサービス改善のサイクルを回していく意向だ。システムエンジニアを目指す皆さんにとって、このような実践的な開発イベントは、技術力だけでなく、課題解決能力やコミュニケーション能力を高める貴重な機会となるだろう。