有志・リモートLLM開発チーム：情報共有・意思決定の課題と教訓
東大松尾研 LLM開発プロジェクト2025、 チームCogitoに参加したkevin28gouです。
本記事は、予選（Phase1）を終えた時点での、チーム開発における情報共有と意思決定に関する考察を発信します。
リモート・非同期でLLM開発を推進するチームは、固有の「壁」に直面します。本稿が、同様なプロジェクト開発における教訓となれば幸いです。
【注意】 本記事は、コンペ参加者個人としての振り返りであり、所属機関・主催者を代表するものではありません。あくまで、私の経験や、一般的に抽象化した非同期開発の教訓として記載します。
※ あくまで、Cogitoチームとしての決定方針ではなく、私の考えた結論となります。
活動リソースの構造的課題と「成果に繋がる三要素」
私について
私は、早朝ランニング・早出出勤・騒音やストレスでの睡眠障害トラブルなどもあり、超朝型生活でした。
また、参加前は開発時期の月残業時間が60~100hour見込まれていたため、あまり活動できないかと予測しておりました。しかし、いざその日になってみると、予定変更などで急に作業時間が減ったり、逆に時間が空くと思っていた日に忙しくなるなど、本業以外の時間を使おうとする場合、予測していた稼働時間に大幅に変更になるような事が頻出しておりました。
私が考える、一人あたりの成果は下記のようになります。
各人の成果 = 能力 × 可処分時間 (活動時間) x モチベーション
１．能力
※ 能力に関しては、各タスクに応じたものとなるため、必ずしもLLMの開発知識・経験だけの事を指すわけではありません。
マルチノードでのLLM開発経験の他、Githubやその他ツールの使用、データ加工やそれぞれのモデルの性能。その他、開発に必要な能力が要求されてきます。
また、今回は主にSFTやGRPOでの実施を考えてた方が多かったと思いますが、LoRAも動かしたり、運営から提示されたコードをベースに改修して学習するなどの作業も求められました。
なお、チームCogitoでは、ms-swiftを使用し学習を開始しました。
２．可処分時間
チーム活動時間
私達は、多様な経験を持つ学生や社会人が混載したチームであり、主に下記のような活動時間となりました。
- 社会人: 平日の夜間や土日祝日が主。（日本ベース）
- 学 生: 上記に加え、平日昼間にも活動可能な時間が増える。
活動時間が被った場合、情報共有ミーティングには向く一方で、計算リソースなどの作業時間の集中には課題がありました。作業時間が被ると、リソースを使用可能な人が限られてくるため、作業したくてもできない。という状況が出てくると予想しておりました。
また、全員が同時に稼働できる時間は限られ、私のように、本業の残業時間増減や私生活のトラブルなどにより、予測していた稼働時間に大幅な変更が生じることも珍しくありません。
※ 私自身、本選に至ってはコロナにかかってしまい、土日祝日が丸々無駄になるような状況にもなりました。その後も、しばらく咳が続いてマイクが不可になるなどに陥りました（悲
特定の人に負荷がかかってしまうのは個人的に嫌いだったため、なるべくサポートできないかと考えておりましたが、結果的には各サブチームリーダーへの負荷が高くなってしまい、それらの方々が情報整理と各チーム内容の作業を同時並行で実施しなければいけなく、負荷が高かった感は否めませんでした。
2-1. ツールの慣れと検索性の壁による作業時間の変化
今回、チーム開発として使用したツールは、
- Cosense ( 情報ハブ、アイデア交換 )
- Slack
- Github
- HugginFace
- wandb
となります。
初めて使用するメンバーもいたり、普段メインで使用しているツールも各自で違うため、ツールの使い方に慣れるための初期コストが発生しました。
弊チームでは、Cosenseをメインにアイデアや情報交換の場として使用する方針でいっておりました。Cosenseでは、微妙にMarkdownが使えなかったり、一覧ページで最新のページからソートできなかったりなど、使い方自体に慣れるための工数がありました。
- 課題: ページが増えるにつれて、最新のページからソートできないなどの問題から、最新の情報取得が難しくなった。
ページが少ない初期は良かったのですが、ページが増えてくるにつれて、最新の情報取得が難しくなりました。そのため、作業しようと思った人が何をすればいいか分からない状態。という状況が発生してしまいました。
常に情報を収集し各サブメンバーへ情報が伝わるよう、他のサブチームの情報なども見ながら共有を心掛けておりましたが、時間が経過し、情報が増えるにつれ、情報収集や整理だけで１日の作業可能時間を消費しきるようになってしまい、作業自体へのモチベーションが下がるという事態になりました。
- 結果: 「情報収集や整理だけで１日の作業可能時間を消費しきる」という情報処理負荷が発生し、自身の作業へのモチベーションが下がる状態に陥った。
ここではCosenseを例にあげましたが、ツール自体がうんぬんではなく、ツールの使用方針が重要になると思います。
例えば、下記のようなケースで作業が進まない事が考えられます。
- ① ツールを知らない
- ② ツールは知っているが、使い方が分からない
- ③ 使い方は分かったが、実際にやっていいかが分からない
このうち、②、③については短時間でもいいので、使い方、使用方針など、数分でもいいので簡単なチュートリアル動画でも実施するのも有りかと思いました。
また、アイデア出しという事でCosenseにページを作成しすぎたせいで、私自身が情報を混雑させてしまった感が否めませんでした。
ツールの使用方法、使用方針などを早い段階で簡単でいいので共有する。
2-2. 作業要件の粒度と認識のズレ
メンバーごとに「何を重視するか」が異なり、必要な情報粒度が合致しませんでした。例えば、下記のような例が挙げられます。
- Aさん: 後戻りを防ぐため、最初に要件をきちんと決めて欲しい。
- Bさん: スピードを重視するため、後で何とかするから（重要ではないから）進めて欲しい。
具体例：データクリーニングの要件定義
- どの程度の量が欲しいのか
- 何文字まで用意するのか
- どこまでクリーニングするのか
- どのようなフォーマットにするのか
- すでにHFにあるデータセットのURLを教えるだけではだめなのか？
- thinkタグの有無に対し、どこの段階で誰が担当するのか
軽く思いつくだけでも、上記のような内容があります。これらに加え、作業者ごとに加工対象のデータセットが分かれた場合、データセットごとに内容が違うので、クリーニング処理の指示が何を指しているのかが分からない。という状態が発生しました。
また、各人これまでの経験やスキルや方針なども違うため、一番やりやすいやり方がそれぞれ違っていることによるズレなどにより、作業手順の統一感が薄れる事になります。
これらは、実際に作業が進むにつれて、なにを重視する人かによって作業前に必要な情報が異なり、欲しい要件などが異なってくることが分かってきました。
さらには、
- 何が分からないかが分からない状態（重要にすべき部分など
- 相手の確認・返答待ちだと思っている
などのような事が発生すると、簡単な事でも質問をすることが憚られたり、そのための確認作業などでも時間がとられてしまいます。
これらを防ぐためには、
①作業内容の趣旨
②Must（決定事項・要件）
③Don't Must（非要件）
を迅速に伝える事で、自分で行動できる人は動けるようになるため、各自で確認待ちにならない状態を防ぐことが出来たと考えております。
**意思決定は「非同期前提」になる事を意識し、「趣旨」「Must（決定事項/要件）」「Don't Must（非要件）」を含めて明記する。情報ハブと最新の決定事項を分かりやすくまとめる。
2-3. 確認待ちによる日・週跨ぎの発生
これまでのような意思決定を確認するために、時間が合わなかった場合に日を跨いでしまうと、次の時間が合わなくなって数日経過してしまう。などが発生してしまい、土日しか作業できない人は、次の週まで待ちの状態などになってしまいます。
- 課題: 意思決定を確認するために、時間が合わなかった場合に日を跨いでしまう。結果、土日しか作業できない人が、次の活動可能な週末まで待ちの状態になってしまう。
- 結果: 作業可能になった人が「現時点で何をすればいいのかが分からない」状態が頻発し、稼働時間が無駄になる。
上記を踏まえ、全メンバーが、「作業したい時に、すぐに、正しい方向で開始・再開できる状態」 を保つことが、可処分時間を有効活用できる事に繋がると感じました。
また、これらが全て次の【３．モチベーション】へと繋がっていきます。
３．モチベーション
3-1. やれない事に対するモチベーション低下
「何ができるかではなく、何をやりたいかがモチベーション維持には大事」 だと私は考えております。
各自の「やりたい事」について、実施できている他のメンバーが情報を公開する事で、作業はできなくても勉強になるためモチベーションが維持できる。という事が考えられます。
実際に作業している人の情報が行き渡ることによって、別作業をしている（やりたかった人）各人のモチベーション向上が期待できると考えております。
ここでは、「Slack内の全チャンネルを確認し、他サブチームの進行状態などを他のチャンネルなどにも共有する。」として、上手くいった事などを逐一報告する。という情報伝達を心掛けました。今回のように、人員に対するリソース量が少ないような場合は、モチベーション低下を防ぐため、特に意識すべき事だと思いました。
これは、昨年参加したコンペでの、Slackの使い方が分かっていなかったため情報取得が上手く行ってなかった事も踏まえております。コメントから派生した返信で会話が続けられた場合、そこにメンションされない人は情報に気づけないまま終わってしまう。という事を防ぐことができます。
例：内容に更新（意思決定）があったが、そこでの決定事項を把握できなかったため無意味な事をやっていた。
これらも、情報伝達が上手くいっていれば、防ぐことが可能だと思っています。
進行状況の情報共有によって、疎外感などによるモチベーションの低下を減らす。
3-2．潜在リソースの活用と技術的教訓
提供GPUリソース
今回は、さくらインターネットのサーバーが提供されました。H100が8台(1ノード)が3ノード分割り当てられ、3つのサブチームに分かれていたのでデータセット班、モデリング班、評価班と各1ノードずつ使用という事になりました。（これも、情報伝達が遅れていた気がします。）
ログインノードで作業を実施すると全体に負荷がかかってしまう。などの注意点もあり、私は手を出さない方がいいかと、当初は使用する予定がありませんでしたが、データセットクリーニング処理でも計算資源を使わないと時間がかかるという事が後で分かってきたため、GPUを使用しない状態で使用する。という事で大幅に時間を短縮できるという事に気づきました。
容量が1GBを超えるデータセットになると、トークナイズ処理してトークン数を計算する処理だけでもかなりの時間がかかるようになってしまいます。特に今回はthinkモデル用という事で、特に長いテキスト物を多く扱うようになりました。
ここでも、個人PCより提供リソースで加工処理をした方が早いという事に気付いたため、データセットチームに情報が行き渡るように作業内容をまとめてやり方などをCosenseに残す。などを心掛けるようにしました。
使えるリソースは最大限活用する。
１GBを超えるデータ処理は、個人PCでは数時間かかるが、提供リソースだと１時間もかからないなどがあるなど。
3-3. 再スタート時の情報取得におけるモチベーション
これまでに挙げたような、再開時に情報取得のための工数が多いと、モチベーションが下がってしまいます。
また、
- しばらく参加できずに時間が経過した時、重荷を感じずに再開できる雰囲気作り
- その時に、各自が自分で考えて動くことが出来る程度の
１．趣旨
２．Must
３．Don't Must
といった、行動指針の情報伝達
などなど、これらが上手くできていれば、再開時のモチベーションの低下も防げたのではないかと考えております。
各自のモチベーションを上げるためには、情報取得の負担を減らし、復帰時の心理的ハードルを下げる。
4. まとめ：リモート・非同期開発を成功させるために
これまでの経験から、有志によるリモート開発チームの成果は、技術力以上に 「情報共有と意思決定の仕組み」 に大きく左右されると感じました。
私たちが直面した壁と、そこから得た教訓は以下の通りです。
- 情報の迷子を防ぐ: ツールの利用方針を初期に定めて、共有する。
- 認識のズレを防ぐ: タスク要件は「趣旨・Must・Don't Must」を明確にする。
- 時間の浪費を防ぐ: 非同期を前提とし、「待ち」を生まない情報伝達を設計する。
- 意欲の低下を防ぐ: 進捗をオープンに共有し、チームの一体感を醸成する。
突き詰めると、 「誰もが、いつでも、迷わずに、貢献できる状態」 をいかに作るか。
この仕組みづくりこそが、メンバー一人ひとりの貴重な時間を最大限に活かし、モチベーションを高く保ち、最終的な大きな成果へと繋がるのだと考えています。
(再掲) ※ あくまで、Cogitoチームとしての決定方針ではなく、私の考えた結論となります。
これまでの内容は、今回Cogitoチーム内だけで発生したものではなく、これまでの経験や、他のチームで発生してそうな事なども踏まえて記載しております。
これは、一見、他の方からみると上手くいってそうでも、声が上がってなかっただけだったり。全て上手くいったから問題にはならなかったりなど、結果論で上手くいくと、問題になりそうなものが隠れたままになるケースも多数あるかと思われます。（生存者バイアス）
記載しているような内容が、少しでもお役に立つことがあれば幸いです。
プロジェクトのクレジット
本プロジェクトは、国立研究開発法人新エネルギー・産業技術総合開発機構(以下「NEDO」)の「日本語版医療特化型LLMの社会実装に向けた安全性検証・実証」における基盤モデルの開発プロジェクトの一環として行われます。