この記事について

この記事は、FUN Advent Calendar 2024の23日目の記事です。

昨日はえつさん「はこだて未来大学のキャンパスと私の知られざる関係」でした。少し前に山本理顕さんが未来大で講演をしていたのを思い出しました、その建築の思想もしかり、未来大の創設経緯は興味深いですよね。ミュージアムITの展示も見てみたかったです。

次の日はパン屋さんの記事です。「ライフワークとは、遊んでてもいいじゃん。」いやそうなんだよね、記事見てないけど。先日、彼らチームの未踏の開発物の実証実験に参加しました。とてもおもしろい経験だったので、これも別の記事にまとめたいところです。

はじめに

今年のp2hacksは、チーム"SHINYAttention Is All You Need"として、謎の男jigsaw-glitchと、moqumo君(吉野君)とともに3人チームで挑みました。

FlushTune

作成したプロダクトは「FlushTune」(GitHub)です。機能としては

• フラッシュバック(突発的に思い出した好ましくない出来事や妄想)を記録してもらう
• 入力に合わせてLLMが感情を分析
• 分析結果に合わせ、リラックスのための楽曲と助言を提示し、気分を和らげてもらう
• 記録をもとに、フラッシュバックのセルフコントロールに活用してもらう

というものです。さらに感情分析の精度の保証とプライバシー保護の観点から、ローカルLLMを採用しています。

実際の画面

結果はPost-PBL最優秀賞でした！本当に良いチームで、2人には大変感謝しています。

PostPBL部門最優秀賞を受賞したのは「SHINYAttention Is All You Need」の皆さんです！！🎊🎉🎉#p2hacks pic.twitter.com/z64oTR9dzV
— P2HACKS 2024 (@p2hacks) December 15, 2024

実践したこと

今回は初のマネジメント側でした (フロントエンド開発も行いました)。

成果物の目玉として、数理方面に専門性の高い2人の技能をどう生かすかが課題でした。

特にチームの発起人であるjigsaw-glitch君からLLM開発の希望があり、自分としてもこの専門性を最大限に活かしたいと考えていました。

部品と入出力を最優先に定義する

重要な実践として、ソフトウェアの部品とその入出力を早期に明確化することを意識しました。

ここでの「部品」は、いわゆるソフトウェアコンポーネントにあたるものになります。その入出力としては、例えばHTTPのリクエスト・レスポンスや、関数の引数と返り値といったものにあたります。

意図としては

• 部品のモックを組んで早い段階で全体を組み上げてもらう
• 部品単位でタスクを振り、メンバーを常に稼働できる状態にする
• 部品ごとに要求が明確であることで、目先のすべきことがすぐにわかり、集中できる状態にする
• 技術や設計に関する技量や信条に差があっても、入出力部分を固定することで、齟齬なく連携できる
• 各部品を、専門知識がなくとも、誰でもブラックボックス的に扱えるようにする

基本的には、全体を組み上げる早さや稼働率の高さを重視した、ハッカソンなりの開発戦略の方向性の一つとして導入しています。

またチームの特性から、各メンバーがそれぞれの部品の具体的な実装を気にかけることなく、各自の専門性を持ち込んだり、自分なりのコードを書いてもらうことも必要でした。

解くべき問題の明確化

部品の入出力を明確にするためには、開発物の全体構成を定める必要があり、さらにそれには全体として解くべき問題(=何を作るのか)を明確にする必要があります。逆に解くべき問題が明確にわかっていれば、ベストとなる開発物の全体構成や技術選定は自然と定まるはずです。このあたりは、プロジェクト学習を経て会得しました。

そのため、1日目はブレインストーミングを経て、jigsaw-glitch君を責任者としてプロダクトのコンセプトの明確化に集中し、その解釈として次のような画面遷移を提示しました。

想定された画面遷移

この画面遷移に基づいて、実装の要件や部品の構造を固めていきました。

一方で、楽曲提案に使うSpotify APIで実際何ができるのか、またそれに合わせどのようにLLMのプロンプトや出力を設計するのかを定めるには、もう少し技術調査が必要でした。

調査を進めるうちに、使用予定のAPIが数日前に廃止されている、予定されていた機能がAPIの利用規約違反になる可能性がある、などの事実が明るみに出てきました。それゆえ、プロダクトの核心となる楽曲の提案機能を担う部品の仕様がうまく定まらず、最終的に全体の部品と入出力が確定したのは5日目あたりでした。

このリスクは把握できておらず、タスク振りで戸惑ってしまいました。ここは、入出力が不明瞭となる事実を許容して、個人に調査を任せつつ別の機能を集中して固めるなど、もう少し上手い立ち回りを考えておく必要があったと感じています (実際は必要な調査をjigsaw-glitch君が進めてくれていたので、それを信頼して2人が別のフローで動いたことで、幸い作業はうまく進んでいました)。

オニオンアーキテクチャの自然発生

部品の入出力を明確化する方針は、ソフトウェア設計の観点で上手くいったと感じています。中でも開発初期段階となる3日目で、思わぬ副次効果が得られました。

当該PR

記録の分析機能・楽曲の提案機能に関わる大雑把な入出力のみ定まっている状態で

• ハンドラ部分となる/server
• 各機能のロジックとなる/analysisおよび/suggester
• 全体に共通で用いられるデータモデルの/model
• データの永続化に関する機能を提供する/storage

これらのモジュールが独立して整備されていました。さらにデータ永続化の機能は、JSONへの書き込みとして実装されつつ、DBMSへの移行を踏まえ(結果的に期間中に達成した)抽象クラスとして上層に渡される形で実装されていました。

このときの構成は、いわゆるオニオンアーキテクチャに近いものに収まっています (ただし実装上厳密には、一般的なオニオンアーキテクチャよりフラットな構造に収まっています)。この事実自体についてなんら意味はないものの

• アーキテクチャが先行せず、設計が要求に対して簡潔であること
• 与えられた入出力に対する担当者の合理的な設計の結果として、既知のパターンに収まったこと
• 実際に部品の仕様変更を、他の部品に一切影響を与えず達成したこと

については、部品による境界づけがもたらした結果として、重要な体験と感じています。なお当然ながら、これはあくまで2人による合理的な設計の結果であり、これをエンジニア的な観点での一般論を持ち込んで俯瞰するのも失礼な話かもしれません。

ともかく、このPRを経て、部品とその入出力、そしてそれに合わせたスケジュール感を次のように整理しました。ここで、既存の構造の簡潔さを失わない形で典型のアーキテクチャに明確に帰着させました。

全体構成

この構造は最後まで変わりませんでした。

一貫性・安全性は自動化できるもののみ保つ

もう一つの実践として、コードの書き方の一貫性を、自動化して保つという戦略を取りました。

具体的な実践としては、次のようなことを行いました。

• PEP8 (Pythonのコーディング規約) に準拠したリンタ・フォーマッタの導入
• 型チェッカの導入による実行安全性の確保

これらはVSCodeの拡張機能で、各自の環境で適用してもらう方針をとりました (その代わりCI/CDはいらないだろうという判断をしました)。ここで、設定の差異によりmerge後に齟齬が出ることがないよう、設定内容(.vscode/settings.json)は事前に決めて全員で共有しました。

逆に、自動化できないものは基本的に((入出力さえ守っていれば))受容する、という方向性をとりました。例えば

• 変数や関数の命名・gitのブランチの切り方は (PEP8やGitHub Flowを提示しつつ) 制限しない
• 関数やファイルの切り方も、部品の内部では自由
• コメントやテストは便利な範囲で書いてもらい、強制はしない

各人の担当箇所は部品ごとに分離しているため、入出力さえ守っていれば、これでも十分齟齬なく連携できました (逆に言えば、一つの部品で複数人が関わる可能性のある長期開発では、もう少し厳密に管理する必要がるのだと思います)。

この方針がどこまでうまく開発効率に作用したかは不明瞭ですが、開発に直接関わらない細かなコミュニケーションをかなり取り除けたのではないかと感じてます (これは、LLMの普及により各人の相談相手が増えた側面もあるので、明確にはなんとも言えません)。

ただし、テストに関しては落ちている状態でmergeしてしまうなど、管理の甘すぎる部分がありました。VSCodeの設定共通化に合わせ、このドキュメントのようにGUIでテストの状況を確認するTDD風味の環境も導入していると良かったのではないかと感じます。

また、CI/CDでもリンタ・型チェック・テストを行う環境を作っていれば、ほとんどのレビューが不要になり、使える時間が増えたのではないかと感じます。今回は導入を見送りましたが、ハッカソンでも導入する価値はあると感じました。

技術選定

(詳細な技術選定はアピールシートを参照してください。「静的型付け言語」は、許してほしい)

バックエンド

LangChainしかり、機械学習に関するフレームワークの使用がほぼ必須となってくるため、メンバー全員の技術スタックも相まってPython一択でした。

個人的にPythonにはトラウマがあり、実行時エラーやパッケージの問題で取り乱さないよう仕組み作りが必要でした。そのため、開発ツールやライブラリの選定や調査は入念に行いました。

特に、過去に現地で視聴していたOpen Source Conference 2024 Hokkaidoでのtakanory氏のトーク「Python開発の変遷をPythonプロフェッショナルプログラミングの改訂の歴史から知る」を見直しました。またGIS業界ではPythonがスタンダードのひとつであり、そこに接点のある業務経験も相まって、幸いある程度Pythonのトレンドを把握している状況でした。

結果、特にめぼしいものとして

• パッケージ・仮想環境管理のツールとしてrye
• 静的型チェッカーとしてpyright

を導入しました。

これらのツールを使った開発は、大学でのPythonの使い方と相当かけ離れています。そのため、これらに関する勉強会を事前に開催し (Notion資料)、知っておくべき語彙を共有しました (Gitを用いたバージョン管理についても同様に行いました)。

勉強会の資料

その他、ハッカソン期間前から直後にかけて、調査がてらプロダクトとは別に開発も行いました。

• 開発環境に慣れるための実践開発「perungo」(GitHub)
• 初めて触る技術の小刻みな試用 (Embedded DB、FastAPI)

かなり準備が重厚になりましたが、サードパーティ製ツールでPythonをここまで手懐けることができるのかという驚きも相まって、結構楽しんでいました。PEPを通してPythonの思想に触れたこともあり、Pythonに対する印象が変わるきっかけにもなりました。

フロントエンド

フロントエンドについては、動きのあるUIや描画APIを活用したいという考えと、個人的な慣れから Svelte+UnoCSS+Three.js という構成にしました。

この選定については、複雑な思いで振り返っています。というのも、フロントエンドは全部自分で書くという前提で組んだものでしたが、結局は労力が大きく、全部自分で書いていたら明らかに間に合いませんでした。そのため、後半でフロントエンドに回ったmoqumo君にマイナーな技術選定を押し付けてしまう形となってしまいました。最終的にうまく形になったのは、記録の可視化機能をSvelte+UnoCSSを1-2日間でマスターして実装したmoqumo君の順応力によるものが大きいです。

全体の反省点

上記から見えてくる反省点としては

• 部品の入出力をとにかく早く決めようとしたことで、入出力が定まりきらない場面で上手く動けなかった
• テストを可視化するツールを導入すべきだった
• コードの解析を行うCI/CDは、少々荷が重くても導入すべきだったかもしれない
• 一部の技術選定が (現実的でない想定の下) 独り善がりになってしまった

他にも反省点があります。

ユーザー視点の見落とし

最初の段階で自分がまとめた開発物の全体像について、使用したい技術に寄っているというmoqumo君からの指摘を受けました。この根拠についてはmoqumo君自身が、参加記にとても詳しく述べています。

moqumo君の参加記

想定された画面遷移

例えば、図の"PROMPTING"部分。「LLMがより良いプレイリストを作る」ということをチームとしての第一の目標とした場合、「精度を高めために感情を詳細に入力できるようにしよう」という意思決定をチーム全体で選んでしまう可能性があります。この選択は単調作業をユーザーに強いることへ繋がり、まるでロボットの支配で人間が労働させられるディストピア作品と化してしまいます。本来あったはずのプロダクトの価値が失われてしまうなんてことがあっては、元も子もありません。

こういった望ましくない方向への開発を防ぐために、「このプロダクトをなぜ作るのか」「この機能は何のためなのか」といったストーリーを明確にし、その認識をチーム全体で共有している必要があります。

指摘の通り、本来のユーザー視点の問題解決の観点を考慮できておらず、使いたい技術を使う前提で設計しています。

というのも、自分としてはjigsaw-glitch君だけでなく、数理に強みのあるmoqumo君にも専門性を生かしてもらいたい (彼もそれを望んでいるだろうという思い込みも踏まえて) という思いがあり、それにこだわりすぎてしまったところは良くなかったです。これは事前に、各人がハッカソンに何を(専門性の発揮？技術的挑戦？)求めているのか、相互で明確に共有できていれば避けられた議論だと考えています。こういうミスマッチは実務でも往々にしてあるのではないかと感じます。

提示されたストーリー

moqumo君はこれをうまく整理し、図とスライドに落とし込みました。全体構成において残された不完全な点が埋まったことから、プロダクトの説得力が大幅に増し、最終発表が大いに充実しました。むしろ、このような提案は期間中あまり気に掛けられず、もっと聞き出して議論を深め、発表時の質問に備えておくべきだったと反省しています。

スライドより

終わりに

偏見的であまり良い言い方ではありませんが、デザインコース生の関わるプロダクトが強い(実際、デザインはものづくりの上でとても重要だと思う)ハッカソンという舞台で、純粋に複雑系コースのメンバーで、かつ学科の知見を生かしたプロダクトで、最優秀賞を獲得できたことを誇りに思っています。

もっともこの成果物の完成度は、jigsaw-glitch君のアイデアを発端としつつ、moqumo君が持ち込んだ、ユーザー視点でのプロダクトの再認識も大きな要因です。このようなデザイン思考に通じる感覚は、自分に足りないものと感じます。

過去のハッカソンでは、技術的に長けた同級生と協働することが多く、技術的な知見を得られとても刺激的でした。一方で、マネジメントの方針やプロダクトに対する考え方で他のメンバーと異なることが多く、毎回何となく不完全燃焼に終わっていました。

今回は新しいチームとして再出発したわけですが、こうして今振り返ると、思うことが様々あります (ここは自分の心の中にしまっておきます)。

とにかく、今回は本当に価値のある体験でした。スケジュール・精神ともにあまり余裕のない期間が続いており、他の用事を優先し断念することも考えましたが、今はとても満足しています。

謝辞

ここまで自分の言いたいことをそれらしく並べましたが、そもそもこの成果は到底自分一人では成し遂げられるものではないです。二人の活躍について説明します。

jigsaw-glitch

本ハッカソンチームの発起人です。プロダクトの初期のコンセプトも彼が考えたものです。ハッカソンではLLMに関する開発を全面的に担っていたほか、楽曲の提案機能に関するバックエンドも書いています。自分も研究で使うかもしれない機械学習・LLMの手法に関して色々と話も聞けてとてもためになりました。研究室が同じなので、これからもお世話になります。

moqumo