タグ: OSS

これまで、freeBox Loader については 4月8日の進捗報告、4月15日の活用イメージ紹介と、計画的な発信を続けてきました。

当初は、このタイミング（4月22日）で「サードパーティ向けコラボ・プラグイン参加募集」のご案内を予定していました。しかし、freeBox Loader v1 のリリースがもう少し時間を要する状況となり、その準備が整ってからご案内することとしました。

その代わりに今回は、「なぜ時間がかかっているのか」という舞台裏の話を、正直にお伝えしたいと思います。

ただ「遅れました」と報告するのではなく、その過程で見えてきた学びを共有することが、このOSSプロジェクトの価値につながると考えているからです。

特に今回は、AIと人が一緒に開発を進める中で見えてきた、これまでにない種類の気づきがありました。これは同じようにAIを活用して何かを作ろうとしている方々にとっても、参考になる内容ではないかと思います。

1. まず、率直な現状のご報告

リリース目標は「目標」であり、最優先は品質

freeBox Loader v1 のリリース見通しは、5月上旬〜中旬を射程に置いています。当初の想定からは後ろ倒しとなりましたが、ここで一つお伝えしておきたいことがあります。

このOSSプロジェクトでは、品質を最も大切にしています。

リリース時期は大切な目標ではありますが、品質を犠牲にして急ぐものではありません。むしろ、「なぜ想定通りに進まなかったのか」を丁寧に振り返り、次の開発に活かせるのであれば、時間をかけることは健全なプロセスだと考えています。

今回の記事は、その振り返りの一部を皆さんに共有するものです。

2. 何が起きていたのか — 「暗黙の境界線」という落とし穴

テストの最終段階で見つかった作業漏れ

freeBox Loader v1 は、大小合わせて複数段階のテストを積み上げる計画で進めてきました。内部状態の確認から、APIの動作確認、UIの操作確認、そして本番環境での統合テストへと、徐々に粒度を上げていく構成です。

このうち最終段階である本番統合テストに入ったところで、ある事実に気づきました。

「この次に控えているシステムテストに進むためには、サンプルモジュール（atomcam2）も準備できていないといけない。でも、atomcam2 のパッケージはまだ完成していない」

具体的には、サンプルモジュールを組み立てるのに必要なファイルの一部が未作成で、公開用のパッケージがビルドできない状態だったのです。

なぜこれが見過ごされていたのか

振り返ると、原因ははっきりしています。

テスト計画と成果物計画の間に、「暗黙の境界線」があったのです。

• 本体のテストは最初から「freeBox Loader 本体のテスト」として設計されていました
• システムテストは「Loader ＋ サンプルモジュール」で実施する前提でした
• ところが、その間にあるべき 「サンプルモジュール側のテスト」というフェーズが、スケジュールに明記されていなかったのです

「Loader 本体の実装は進んでいる → テストも進んでいる → だからシステムテストも大丈夫」という感覚のまま、サンプル側の準備が手薄になっていました。

含める範囲だけを書いて、除外される範囲を書いていなかった — これが落とし穴でした。「何を作るか」のリストは丁寧に作っていたのに、「このリストに含まれていないものは、誰がいつ作るのか」が決まっていなかったわけです。

これは開発プロジェクトでは 「あるある」の失敗パターンです。でも、あるあるだからこそ、次に活かせる学びがたくさんあります。

気づけたのは、なぜか

救いだったのは、システムテストを逆算して準備を始めたタイミングで気づけたことです。

本番統合テストに入り、「次はシステムテスト。ではサンプルモジュールのパッケージはどこだ？」と問いを立てた瞬間に、空白が見えました。

もしこの問いを立てる機会がなければ、もっと後の段階で「動くはずなのに動かない」という形で発覚していたかもしれません。早めに気づけたこと自体は、プロセスが機能した結果でもあります。

3. AIと人が一緒に開発して見えてきたもの

ここからは、この開発を通じて気づいた、AIと人が一緒に開発を進める際の独特の視点をお話しします。

freeBox Loader の開発では、AIを開発のパートナーとして活用しています。仕様書の照合、コードの修正、テストの実施、そして引き継ぎメモの作成まで、人間とAIが分担しながら進めています。

そこで浮かび上がってきたのが、「AIも人と同じ扱いで考える」という発想の大切さです。

AIにも「勤務時間」がある

人に勤務時間があるように、AIにも使用量の上限があります。わかりやすく言えば、AIにも「残業制限」があるのです。

この制限に達すると、AIの作業セッションは終了します。人間であれば「続きは明日」と言えますが、AIは「明日のAI」は今日のAIの記憶を持っていません。毎回、ゼロから始まります。

このため、セッションの終わりに「次の担当者（次のAI、あるいは次の人）が困らないように引き継ぎメモを残す」という運用を取り入れてきました。人間同士の引き継ぎと同じ考え方です。

しかし、そこに新しい落とし穴があった

運用ルールは「使用量が一定水準に達した時点で引き継ぎメモを書き始める」というものでした。一見、理にかなっています。

ところが、今回の開発の振り返りの中で、特定のセッションの引き継ぎメモが残っていない事象が見つかりました。

原因として考えられるのは、引き継ぎメモを書く前に、何らかの理由でセッションが終了してしまったケースです。そうなると、引き継ぎメモを書く間もなくセッションが終わり、そのセッションで何をしたかの記録が、次のセッションに伝わらないことになります。

幸い、実際のコードは仕様通りに実装されていることを別途確認できたため、実害はありませんでした。けれども、「作業プロセスの記録」と「作業結果の記録」を同じファイルにまとめていた運用が、記録消失のリスクを構造的に高めていたことが明らかになりました。

そこから得た学び

人間同士の開発で、長年当たり前だった「セッション終わり(引継ぎ時)にまとめて議事録(引継ぎ資料)を書く」という習慣は、AIと一緒に働く場合には、むしろリスクになることがある。

これは、とても興味深い気づきでした。

AIとの協働では、「記録を1箇所にまとめるよりも、細かく分けて、そのつど残しておく」方が、セッション制限という構造に合っているのです。

この発想の転換は、freeBox Loader に限らず、AIを開発パートナーとして活用するあらゆるプロジェクトに応用できる考え方だと思います。
※プロダクトマネージャーコメント：振り返るとこの運用は人間にも言えます。 私は、作業をDB上で行い常に記録する手順を25年まえから運用しています。これにより引継ぎの作業が殆どいりません。

4. 次に活かす改善

以上の振り返りから、以下の改善を進めています。

① 成果物の定義を、プロセスまで含めて明確化する

「作ったファイルがあればOK」ではなく、「そのファイルを生成する仕組みまで含めてゴール」と定義します。

たとえばサンプルモジュールの場合、ソースコードだけでなく、それをパッケージ化して公開する仕組みまでが揃って初めて「完成」と見なす、というふうに基準を引き上げます。

② タスクを「機能名」ではなく「ファイル名」で管理する

「機能Aは実装完了」ではなく、「ファイルXは生成完了」で追跡します。

機能の名前だけを見ていると「進んでいるように見える」けれど、実際には必要なファイルが揃っていない、という状態を構造的に防ぎます。

③ フェーズ間の「除外範囲」も明記する

「このテストに含まれるもの」だけでなく、「このテストに含まれないもの」も明記する運用に変えます。

「本体テストには含めない、サンプルモジュールは別フェーズで対応する」のような、除外を最初に書く。これだけで、暗黙の境界線が可視化されます。

④ 引き継ぎの「ゼロ知識検証」

引き継ぎメモを作った後に、「これを初めて見る人が、これだけで作業を再開できるか」を検証するステップを入れます。

「書いた本人にはわかる」資料と、「誰にでもわかる」資料は別物です。後者を目指します。

⑤ 記録の連続性を確保する（AIと人が一緒に働く開発に特化した改善）

• 引き継ぎメモは早めのタイミングで中間版を書く(ギリギリまで待たない)
• テスト結果の記録は、引き継ぎメモとは別のファイルで管理する
• 項目が1つ終わるたびに、即時に記録する(まとめて書かない)

この改善は、AIの動作特性(セッションが突然終わることがある)を前提にした運用設計です。

5. これからのこと

リリース見通し

freeBox Loader v1 のリリースは、5月上旬〜中旬を射程に置いています。サンプルモジュールの準備とシステムテストを経て、品質が確認できたタイミングで公開します。

hsBox との関係

freeBox Loader は、hsBox の次期バージョン(1.4 以降)での運用を想定して開発しています。hsBox 1.4 では、freeBox Loader を標準同梱する方向で検討中です(最終的な構成は、freeBox Loader のリリース時点で改めてご案内します)。

サードパーティ向けコラボ・プラグイン参加募集

当初このタイミングでご案内する予定だった「コラボ・プラグイン参加募集」は、freeBox Loader v1 の正式リリース後に、改めて詳しくご案内します。

モジュールの作り方、公開の手順、コラボの仕組みなど、参加していただくための情報を整えた上でお届けする予定です。

おわりに

今回は、freeBox Loader 開発の現状について、「遅れました」で終わらせずに、その背景と学びまで共有するスタイルでご報告しました。

開発プロジェクトにおいて、計画通りに進まない場面は必ず訪れます。大切なのは、なぜそうなったのかを振り返り、次に活かすことです。

そしてこれからの時代、AIと人が一緒に開発を進める場面がますます増えていきます。AIも人と同じ扱いで — 引き継ぎの大切さ、記録の取り方、勤務時間の配慮 — こうした視点が、新しい開発プロセスの基盤になっていくのではないかと感じています。

freeBox Loader の次のご報告は、リリース準備が整ったタイミング、または コラボ・プラグイン参加募集のご案内になる予定です。引き続き、ご期待ください。

freeBox Loader / hsBox に関するお問い合わせ・ご意見は お問い合わせページ からお寄せください。

過去の関連記事:freeBox Loader で、スマートホーム連携はここが変わる(4/15) ｜ freeBox Loader 開発進行状況｜現在どこまで来ているか(4/8)