この記事は MICIN Advent Calendar 2025 の 14日目の記事です。
前回はmasatomotyさんの、「Jetson Orin Nanoで物体×温度をRT推論」でした。
最近ジョギングにハマっているotezouです。
今回は品質管理を担当する私が、非エンジニアとエンジニアの狭間にある課題を、一つの機能を例に、コミュニケーションの複雑さとその改善方法について共有したいと思います。
🕰️ はじめに：シンプルな機能の裏側
まずは、具体例があるといいと思うので、以下のUIを例示します。
一日全体の歩数から、ジョギング中の歩数を抜き出して記録するアプリです。
万歩計と連携して選択した日の歩数が表示
ここで取り上げたいのは、画面中央の日付の入力欄です。
非常にシンプルで、日付と時刻をそれぞれ入力するだけです。
しかしここに罠があります。
画面左上の端末の表示時刻を見ると 19:00 です。
対して、画面中央の入力欄は 12月1日(月) 22:00 となっています。
これは「昨日の夜に運動した記録を、翌日の夜に入力している」というシチュエーションです。
つまり現在日時は翌日の12月2日(火) 19:00です。
できればライトナウで開始時と終了時を付けて欲しそうなUIですが、記録するのを忘れてあとからざっくりと記録を付けることもあるでしょう。
ユーザーが「昨日の運動を今日記録した」というシンプルな行為の裏側には、プロダクト開発に携わる人々の頭を悩ませる歪みが潜んでいます。
本記事では、ステークホルダー間のコミュニケーションと品質への取り組み方について、上記のアプリを例にしたいと思います。
💥 仕様について：時刻の「四重苦」
例示したアプリについて、このアプリは後から記録を編集することが可能とします。
また、フロントエンドに表示する時刻およびデータベースに保存する時刻はすべて日本標準時（JST）で統一するものとします（ここもUTCかJSTかで共通意識を持つことが重要なポイントですが、今回はJSTで固定します）。
一連の操作を具体的に見ていきましょう。
ユーザーが過去（例：昨日）の記録を今日になって入力し、さらにその後に修正を加える場合、データとして管理すべき時刻とステータスは4種類に及びます。
| 名称 | 種別 | 定義 | |
|---|---|---|---|
| ① | システム登録時刻 | 現実の時刻 | ユーザーが最初に保存したシステム上の真実の時刻。 |
| ② | 記録上の日時 | ユーザー指定 | ユーザーが入力した運動を実施した時刻。 |
| ③ | 編集実行時刻 | 現実の時刻 | ユーザーが修正内容を更新したシステム上の時刻。 |
| ④ | 編集後の記録上の日時 | ユーザー指定 | ユーザーが修正した運動を実施した最終時刻。 |
エンジニアにとってはイメージしやすいでしょうか？
🤯 課題：「コミュニケーションの断絶」と「テストの複雑性」
データベースでイメージできるエンジニアにとっては明白でも、プロダクトを開発する上で様々なステークホルダーと関わっていく中で、この複数の意味を持つ「時刻」がコミュニケーションの複雑性を生んでいく原因になりえます。
外部のステークホルダー以外にも、社内でも販売に携わる人や、社内外の折衝を行う人、開発チーム（プロダクトマネージャー、エンジニア、デザイナー、テスター、ヘルプ人員など）等々、彼ら彼女らのスキルセットは様々です。
ステークホルダー間の「時刻」定義の不一致
「時刻」という単語一つとっても、人によっては「ユーザーが入力した日時」を、別の人にとっては「実際に登録ボタンを押した時刻」を、それぞれ無意識に指していることがあります。
使いたい時刻の定義が各ステークホルダーで揃っていない、またはバイアスがかかってしまい前提がズレていることに気づけないため、議論がこんがらがってしまうのです。
人の引継ぎによる「暗黙知」の破壊
最も懸念されるのは、この議論や仕様が、特定の担当者の「暗黙知」に依存してしまうことです。
プロジェクトの引継ぎなどで担当者が変わった場合、仕様書に「記録時刻」とだけ書かれていても、それが①～④のどれを指し、他の機能（例：通知機能やレポート生成）とどのように兼ね合っているのかをすべての関係者が読み解くのは至難の業です。
テストの複雑性「組み合わせ爆発」
また、すべてを整理できたとしても、それをテストし品質を保証することは簡単ではありません。
むやみやたらに検証しようとすると、時刻の前後関係による以下のパターンが考えられます。
- ①登録時刻から見て②記録上の日時は、過去／現在／未来のどれなのか？
- 編集しているのか、していないのか？
- 編集している場合は、
- ①登録時刻から見て④編集後の記録上の日時は過去／現在／未来のどれなのか？
- ②記録上の日時から見て③編集実行時刻や④編集後の記録上の日時は過去／現在／未来のどれなのか？
- ③編集実行時刻から見て④編集後の記録上の日時は過去／現在／未来のどれなのか？
起こり得ないのは、①登録時刻の以前に③編集実行時刻が来るのみで、他の時系列は様々なパターンが考えられます。
他の機能への影響まで考慮すると、時刻の検証のみでテストが終わってしまう勢いです。
頑張って全パターンを網羅するのも手ですが、それよりも、ユーザーにとってどうあるべきか？ に立脚して考えると、もしかしたらその複雑性は脱却できるかもしれません。
✅ 改善するには？：「ユビキタス言語」と「制御」
この複雑な状況を乗り越え、また品質を担保するには、品質管理の観点をプロセス全体に活かし、今回で言うと「時刻」を徹底的に言語化し、さらに複雑性を排除する「制御」を設計することが肝要です。
ユビキタス言語の「確立と周知」
曖昧な「時刻」という言葉の使用を避け、仕様を指す言語を統一します。これは、開発チームに限らないすべてのステークホルダーが共通認識を持つためのユビキタス言語として機能します。
何のための時刻か、そしていつの時点の状態を示すのかを明確にすることで、コミュニケーションの断絶を防ぎます。
開発に寄り添うとテーブルのカラム名にするのも良いですし、非エンジニアに寄り添うなら、以下のように定義するのも良いでしょう。
| 時刻やステータス | |
|---|---|
| ① | システム登録時刻 |
| ② | 記録上の日時 |
| ③ | 編集実行時刻 |
| ④ | 編集後の記録上の日時 |
大事なのは、何にするかではなく、そのプロダクト開発においては何が適しているか？を全員ですり合わせ・共有する場を設けることです。
「複雑性」を制御する
複雑性を制御するため、プロダクト価値を損なわない範囲で制限を設けることが有効です。この「制御」の設計は、テストケースの爆発的な増加を防ぎます。
- 制限例: ユーザー指定の②記録上の日時が、①登録時刻より未来になることは禁止する。
- 制御例: 編集を歩数の内容だけに留め、時刻の変更を禁止する（記録を削除して時刻を改めて作り直してもらう）。
このように、要件定義段階で「ユーザーにとってどうあるべきか？」という品質の根本を意識しながら「制御」を明確に定義することが改善の第一歩になります。
また、品質管理も積極的に要件定義に関わり、過去の事例分析などから起きた仕様の複雑性を共有することが、「制御」を受け入れられ易い土壌へと繋がっていきます。
💡 おわりに：「過去」を味方に
「時刻」という一見シンプルに見える要素が持つ奥深さは、まさにプロダクト開発の複雑性の鏡と言えます。
これは「時刻」に関してだけの話というわけではなく、様々なプロダクト・様々な機能について同じ複雑さが潜んでいることでしょう。
今回の例を扱うことは、常に上流工程からの品質の担保を続けるという、品質管理に携わる役割のバランス感覚を培うことにも繋がります。
しかし、それは品質チームだけで閉じて改善するには難しいことです。
MICINのエンジニア組織は組織ビジョンに 「部署やチームの壁なんか気にしない、個と個が強くつながって、みんなで難しい課題を解決できる組織」 を掲げています。
これまでの「過去」を、今後のプロダクト開発へのコミュニケーションや要件定義に活かし、部署やチームの壁なんか気にしない で「ユーザーにとって良いものを作る姿勢」が共有・相談できる場を設けることができれば、その「過去」は味方になります。
🌌 おまけ：常に目にしている光景にも時差は存在している
おまけです。
こういう何でもない話が好きなので、気を抜いてお付き合いいただければ。
私たちが悩まされるのは、アプリの中の時刻だけではありません。
私たちは常に、光の時差の中で生きています。
「太陽の光が地球に届くまでに約8分19秒かかる」というのは有名な話ですが、これは宇宙レベルの話。オフィスや部屋の中でも、同様の「光の遅延」は発生しているのです。
天井の照明
例えば、2.5mの天井に設置された照明を考えてみましょう。
照明から発せられた光が、到達するまでの時間はどれくらいでしょうか？
計算してみましょう。
-
距離：
2.5\text{ m} -
光速：約
300,000,000\text{ m/s}
計算すると...
計算結果
光が天井からデスクに到達するまでの時間は、約8.3ナノ秒（
一見すると「なんだ、誤差じゃないか」と思われるかもしれません。しかし、これは光がたった2.5m進むのにかかる時間です。
まあ床に寝ていない限り天井の高さを2.5mとおいて2.5mと計算しているのはおかしいですが、普通、天井の光を直視しているわけではなく、オフィスの物に反射してその光を見ているので、直線距離ではなく経由していることも加味して2.5mのままとします。
私たちは「過去」を見ている
さらに脳の処理時間まで入れると遅延は広がります。
目に入った光が視神経を通り、脳で処理され、情報として「認識」に至るまでには、何を認識とするかなど定義によって幅がありますが、数十ミリ秒（
これはナノ秒に比べると数百万倍にもなります。
つまり、あなたがいま見ているオフィスは、光の遅延と脳の処理時間の合計としての「過去の姿」なのです。
光の時差だけ切り取って、脳の処理を無視するとしても、時差のない光を観測しようとするなら、光が移動する距離をゼロにするしかありません。それはつまり、懐中電灯を眼球に押しつけるくらいの距離でしか実現できません。
私たちは、アプリの時刻に頭を悩ませる遥か以前から、常に、光と脳の時差という物理現象の中で生きている、というわけです。
それで何というわけではありませんが、時刻の「複雑性」に頭を悩ませることへの相対的減衰を目論めれば幸いです。
そんなおまけでした。
MICINではメンバーを大募集しています。
「とりあえず話を聞いてみたい」でも大歓迎ですので、お気軽にご応募ください！
Discussion