One For Allと「報告してくれてありがとう」文化｜AI業務管理秘書たすきばが失敗を隠さない組織を作る方法
失敗が起きたとき、何をするか
失敗が起きたときは、 チームで責任感を持ち、誠実に対応する 。 「One For All」 の気持ちで、ワンチームとして動く。
これは、たすきばが大切にする価値観の中核の 1 つです。
——と書くと当たり前に聞こえます。でも、これを 構造として実装する ためには、いくつかの細かい設計が必要だと、私は思っています。今日はその細部の話です。
責任所在は私が引き受ける
お客様への謝罪や、大きな失敗の最終的な責任所在は、 私（代表者） にあります。 個人メンバーを矢面に立たせません 。
たとえば：
- メンバーが実装ミスで、ユーザ画面に誤情報を表示してしまった
- → 顧客への謝罪は、私が前面に出る
- → メンバーは反省・改善に集中
これは、
- メンバーが心理的に潰されないため
- 顧客にとって「責任者は誰か」が明確になるため
- 個人を守ることで、チームの結束を維持するため
——という、多重の理由によります。
K-2 で書いた “対等な創業者モデル” で「最終決定は私」と書いたのと、これは表裏一体です。決める権限を持っているなら、責任も持つ。それがフェアな構造だ、と思っています。
「報告してくれてありがとう」のスタンス
メンバーから良くない報告が上がってきたとき、
「報告してくれてありがとう。」
——というスタンスで受け止め、チーム全員でフォローアップします。
これは、口先だけのフレーズではありません。 毎回、心からそう伝える ことを、私自身のルールにしています。
なぜなら、
- 報告は、 「問題が悪化する前に対処できる」 機会を生む
- 報告がなければ、隠蔽が始まる
- 隠蔽が始まると、より大きな事故になる
報告は、組織にとって最も重要な行動の 1 つです。それを賞賛することで、 報告が増える文化 を作っていきます。
“隠したら罰せられる” を消す
普通の組織では、
- 失敗を報告すると、怒られる
- 個人の評価が下がる
- 「できない人」とみなされる
——こうした構造が、隠蔽を生みます。
たすきばは、これを 「報告したら助けてもらえる」 に置き換えます。失敗を報告した人は：
- 怒られない
- 評価が下がらない
- むしろ チームに価値を提供した と評価される
これにより、心理的負担なく報告できる。
“失敗を隠したくなる心理” の構造
人はなぜ失敗を隠したくなるのか。
- 怒られたくない
- 評価が下がるのが怖い
- 周囲に「できない人」と見られたくない
- 自分自身がショックを受けたくない
——これらは、すべて 個人の自己防衛本能 です。
組織がこれらを煽る仕組みになっていると、隠蔽が起きる。組織がこれらを和らげる仕組みになっていれば、報告が起きる。たすきばは、後者を目指します。これは 失敗を学びに変える文化 を作るための、いちばん最初の設計判断です。
“失敗から学ぶ” を組織化する
失敗を報告 → 学びに変える流れを、仕組み化しています。
- 報告 — メンバーが Discord / 社内チャットで報告
- 受け止める — 「報告してくれてありがとう」と即座に伝える
- 影響範囲の確認 — 被害が広がる前に、即座に止血。ユーザに影響がある場合は、私が顧客対応
- 原因分析 — チーム全員で原因を分析。個人を責めず、 「仕組みのどこに罠があったか」 を見る
- KDD に記録 — 罠と教訓を
docs/knowledge/KDD_PATTERNS.mdに追記 - 再発防止策 — CI / テスト / レビュー観点に組み込む。個人の意思に頼らない仕組み化
このフローを、すべての失敗で実行します。
“誰の失敗か” ではなく “仕組みのどこに罠があったか”
たすきばは、 Postmortem（事後分析）を blame-less で実施します。
- 誰がやらかしたか → 議論しない
- どこに罠があったか → 徹底的に議論する
- 仕組みでどう防ぐか → 改善策を立てる
「A さんが間違えた」ではなく、 「この設計だと誰がやっても踏む罠だった」 と捉える。
これは、
- 個人を責めない文化を維持
- 構造的改善に集中
- 同じ罠を二度踏まない仕組み作り
——につながります。
“成功も賞賛する”
失敗時の文化だけではなく、 成功時の文化 も大切です。
メンバーが何かを成し遂げたとき：
- Discord で公に賞賛
- 「おめでとう / 助かった / ありがとう」を伝える
- 成果を可視化する
成功体験を増やすことで、メンバーのモチベーションが維持されます。 心理的安全性は、賞賛と謝意の積み重ねで作られる 、と私は信じています。
“個人開発の現状での運用”
現状、私 + Claude Code の体制では、上記の “チーム文化” を回す相手がいません。
ただ、私自身に対して、同じスタンスを持つようにしています。
- 自分が失敗したら、自分に「気づいてくれてありがとう」と言う
- 原因分析を冷静に行う
- KDD に記録する
- 仕組みで防ぐ
自分自身を「1 人のメンバー」として扱うことで、将来チームができたときも、同じ文化を維持できる——そう考えています。
“本業優先カルチャー”
たすきばのメンバーは、本業の傍らで参加する想定です（K-1 参照）。
そのため、 本業優先を最初から保証 します。
- 本業が忙しいときはペースを落としても OK
- 個人の体調 / 家庭事情を優先
- 「ご飯食べに行きませんか」が自然に出る関係性
これは、 「細く・長く」のスタンス と一貫しています。無理して短期で完成させるより、長期で続けることを優先する。
“信頼の積み重ね”
信頼は：
- 「報告してくれてありがとう」の積み重ね
- 失敗時の “個人を守る” 行動
- 透明な情報共有
- 約束を守る
——こうした日々の小さな積み重ねで作られる。たすきばは、これを 6 ヶ月ごとに棚卸し していく予定です。
まとめ
| 文化 | 効果 |
|---|---|
| One For All | チームで責任を引き受ける |
| 「報告してくれてありがとう」 | 報告が増える文化 |
| Blame-less Postmortem | 構造的改善に集中 |
| 成功も賞賛 | モチベーション維持 |
| 本業優先 | 長期持続可能 |
たすきばのチーム文化は、 「心理的安全性の高い組織を作る」 という個人の夢の実証実験そのものです。
次回は K 章の最終回。 2 年で収益化判定、だめでもサービスは続ける 2 つのシナリオ を書きます。
関連記事
- 「対等な創業者モデル」と三層議論プロセス — トップダウンを選ばないために — 連載第 12 回・チーム運営
- 心理的安全性は「知っている」だけでは届かない — 理解→設計→実装→再現の 4 段階 — 失敗を学びに変える文化の出発点
- 「離脱」ではなく「卒業」と呼びたい — たすきばが Discord を選んだ理由 — コミュニティ文化との接続
たすきば について
たすきば Knowledge Relay は、サービスと組織文化の両方を実証していくプロジェクトです。 プロダクトページ では、サービスの現在地と参加方法をご案内しています。
