FlowlogFlowlog
未ログイン

コンセプト

Flowlog の仕様の元になる「内側の言語」を、いつでも読み返せるようにする。

更新: 1/24/2026, 2:27:52 PM
← Flow
正本: docs/concept/vision.md（このページはファイルをそのまま表示します。推敲はここを編集してください）

Flowlog ビジョン / 原則

定義（1文）

Flowlog は、仕事の流れをそのまま記録し、あとで勝手に効率化されるためのログ基盤です。

原則

  1. 提出ではなく、記録: 「書いたら終わり」ではなく、「書いたものが後で役に立つ」ことを優先する
  2. 評価・監視から切り離す: ログの入力率を下げる導線（承認、点数化、査定直結）を最初から持ち込まない
  3. 任意入力がデフォルト: 空でも許される/雑でも許される UI と運用を前提にする
  4. 不完全を前提にする: 人間はパーフェクトじゃないし、真実は一つじゃない。だからこそ、心理的安全度の高い状態で“ゆるい改善”を継続できる設計にする
  5. 疎結合で連携する: ShiftPay 等の他プロダクトとは、最小限のキー（例: 日付・プロジェクトID）でつなぐ
  6. 後で勝手に効く: 要約、次タスク提案、重複作業検出などの“効率化”はログを素材に後追いで実装する
  7. テナント境界を持つ: 社外展開を見据え、データはテナント ID で分離できる前提にする
  8. 招待は“昇格（Opt-in）”: Flowlog の原文ログは自動共有しない。チーム価値が必要なときだけ、Flowalign（合意）/Caseflow（証跡）へ“招待＝昇格”で繋ぐ（モノレポ直下 flow-common/docs/invitation-as-experience.md）

レイヤー構成（単一プロダクト）

  • Flow（個人ログ） → もやっと（候補） → Decision（決めたこと） → Execution（やること）
  • サービス分割はしない。UIは1つ、概念は分離する。
  • Issue Tracker は Flowlog の外部表現であり、内側では ExecutionItem を正とする。
  • Flow 画面は個人用。チームのやること/Issue 詳細は表示しない。
  • もやっとは 未確定の“前駆体”。放置して良いし、いつでも捨てて良い。必要なものだけ Execution に昇格する。

用語（仮）

  • Flow Item: 1件のログ（日時・本文・任意のプロジェクト/タグ）
  • もやっと（候補）: ログから浮かび上がった「やったほうがよいかも」/「やることかも」
  • 低コミットが前提（未処理=悪ではない）
  • 人が書いても良いし、システムが拾っても良い（将来は Flow Assistant が補助）
  • “採用（やることにする）”で Execution Item（やること）になる
  • “やらない”も意思決定として残す（理由があると後で効く）
  • Decision: 決めたこと（理由・オーナー・期限）
  • Execution Item: やること（Issue化は任意、内部では Execution を正とする）
  • pending（ひとやすみ）: 「やること」を一旦休んで置いておく状態。Flowlogでは管理しない（溜まってOK）。必要なときだけ意味を回収する。
  • 詳細: [concept/pending.md](pending.md)
  • Candy（飴ちゃん）: 感謝の通貨。タスク貢献に対して渡す記録
  • Flow Digest: 期間ログの要約（週次など）
  • Flow Assistant: ログを元に提案する補助機能（将来）
  • Tenant: 会社/組織単位の区切り（v0 は固定値で運用）

UI/文言の方針

「日報」「報告」「提出」「承認」「評価」を前面に出さない。

画面やボタンは「ログ」「メモ」「記録」「ふりかえり」など、心理コストの低い語彙を優先する。

Issue/Execution は UI 上は 「やること」 に統一し、「課題」「問題」など評価臭のある語彙は避ける。

「いいね」「金銭」ではなく、「飴ちゃん（感謝の通貨）」として扱う。

“もやっと（候補）”は 押し付けない（未処理を責めるUIにしない、件数で煽らない、期限を強制しない）。

「正解/唯一の真実」に寄せすぎず、揺れや変更を許容する（あとから直せる、後悔しにくい、説明責任で疲れない）。

参照

  • 全体の棲み分け/疎結合連携: flow-common/docs/ecosystem.md