燃え尽きるのは誰だ？バーンダウンチャートでプロジェクトの「ヤバさ」をチームで共有する方法

2025年6月18日

金曜日の夜 11 時、オフィスに響くのはキーボードを叩く音とため息だけでした。リリース予定日まであと 3 日なのに、フロントエンドの実装が全く終わっていない。「田中さん、体調大丈夫ですか？」と声をかけた瞬間、彼は机に突っ伏してしまいました。

その 2 日後、プロジェクトマネージャーから「あと何日で終わりそうですか？」と聞かれた私たちは、誰も明確な答えを出せませんでした。「多分...来週中には...」という曖昧な回答しかできない絶望的な状況。フロントエンドエンジニアとして 4 年間様々なプロジェクトに携わる中で、このような「見えない爆弾」を抱えた開発は珍しくありませんでした。

そこで私は、バーンダウンチャートを活用してプロジェクトの「ヤバさ」を早期発見し、チーム全体で共有する仕組みを構築しました。この取り組みにより、プロジェクトの突然死を防ぎ、チームメンバーのバーンアウトを大幅に減らすことができました。その具体的な手法と成果を、皆さんと共有したいと思います。

背景と課題

プロジェクト進捗の見えない化による突然死

私が経験した Web アプリケーション開発プロジェクトでは、恐ろしい「見えない爆弾」が潜んでいました。表面上は順調に見えていたプロジェクトが、突然崩壊する現象が頻発していたのです。

典型的な崩壊パターン

yamlWeek 1-4: 「順調です」（実際は 70%の遅れ）
Week 5-6: 「ちょっと遅れてますが大丈夫」（実際は 150%の遅れ）
Week 7: 「リリース延期します」（プロジェクト炎上）
Week 8: チームメンバー離脱・バーンアウト続出

特に React コンポーネントの開発において、以下のような問題が頻発していました：

見積もりの甘さ: 「このコンポーネント 2 日で作れます」→ 実際は 1 週間
依存関係の見落とし: API 仕様変更によるフロントエンド全面修正
品質要件の後出し: 「レスポンシブ対応も必要でした」という追加要求

個人の頑張りに依存した無理なスケジュール管理

最も深刻だったのは、プロジェクトの成功が個人の無理な頑張りに依存していたことです。

危険な兆候を見逃していた実例

警告サイン 1: 残業時間の個人差拡大

A さん（React 得意）: 月間残業 20 時間
B さん（CSS 苦手）: 月間残業 80 時間
C さん（新人）: 月間残業 100 時間超

警告サイン 2: コミュニケーションの変化

以前：「この実装、どう思いますか？」
危険期：「大丈夫、なんとかします」（質問をしなくなる）
限界期：「...」（報告すらしなくなる）

私たちには、これらの警告サインを客観的に把握し、早期介入するための仕組みが全く整っていませんでした。

チームメンバーのバーンアウト続出の実態

フロントエンド開発特有の課題として、技術的負債とタイトなスケジュールの板挟みがありました。

バーンアウトの連鎖反応

markdown個人レベル:
- 長時間労働による集中力低下
- 品質への妥協とそれに伴う罪悪感
- 技術的挑戦を諦める消極的姿勢

チームレベル:
- 経験者への依存度増加
- ナレッジ共有の停止
- 新しい技術導入の断念

プロジェクトレベル:
- 技術負債の急激な蓄積
- バグ修正に追われる悪循環
- 本来の開発計画からの大幅逸脱

最も印象的だったのは、優秀なシニアエンジニアが「もう疲れました」と言って退職していく光景でした。個人の問題ではなく、構造的な問題があることは明らかでした。

試したこと・実践内容

バーンダウンチャートの導入と可視化手法

私はまず、従来のスケジュール管理を根本的に見直すことから始めました。

リアルタイムバーンダウンチャートの構築

従来の問題のある管理方法

markdown「React コンポーネント開発」: 10 日間（ざっくり見積もり）
→ 実際の進捗が見えない
→ 最終日に「実は終わってません」発覚

新しいアプローチ

javascript// バーンダウンチャート用のデータ構造
const sprintData = {
  totalStoryPoints: 100,
  remainingWork: [
    { date: '2024-01-01', remaining: 100 },
    { date: '2024-01-02', remaining: 95 },
    { date: '2024-01-03', remaining: 88 },
    // 毎日更新
  ],
  idealBurndown: [
    { date: '2024-01-01', ideal: 100 },
    { date: '2024-01-02', ideal: 90 },
    { date: '2024-01-03', ideal: 80 },
    // 理想的な進捗ライン
  ],
};

// Chart.js を使った可視化
const createBurndownChart = (data) => {
  return new Chart(ctx, {
    type: 'line',
    data: {
      labels: data.dates,
      datasets: [
        {
          label: '実際の進捗',
          data: data.remainingWork,
          borderColor: 'rgb(255, 99, 132)',
          tension: 0.1,
        },
        {
          label: '理想的な進捗',
          data: data.idealBurndown,
          borderColor: 'rgb(54, 162, 235)',
          borderDash: [5, 5],
        },
      ],
    },
  });
};

細分化されたタスク管理

React コンポーネント開発を例に、タスクを細分化しました：

markdown「ユーザープロフィールページ」（従来：5 日間）
↓ 細分化

- ProfileHeader コンポーネント（0.5 日）
- ProfileImage コンポーネント（0.5 日）
- ProfileForm コンポーネント（1 日）
- バリデーション実装（0.5 日）
- API 統合（1 日）
- レスポンシブ対応（0.5 日）
- テスト実装（1 日）

この細分化により、1 日単位での進捗把握が可能になりました。

「ヤバさレベル」の定義と共有システム

客観的な危険度指標の導入

私は、主観的な「大丈夫です」ではなく、客観的データに基づく「ヤバさレベル」を定義しました：

javascriptconst calculateRiskLevel = (sprintData) => {
  const { remainingDays, remainingWork, averageVelocity } =
    sprintData;

  const projectedCompletion =
    remainingWork / averageVelocity;
  const scheduleRatio = projectedCompletion / remainingDays;

  if (scheduleRatio <= 1.0) return 'GREEN'; // 順調
  if (scheduleRatio <= 1.2) return 'YELLOW'; // 注意
  if (scheduleRatio <= 1.5) return 'ORANGE'; // 危険
  return 'RED'; // 緊急
};

// ヤバさレベルの具体的な定義
const riskLevels = {
  GREEN: {
    message: '順調です！',
    action: '現在のペースを維持',
    weeklyMeeting: false,
  },
  YELLOW: {
    message: '少し遅れています',
    action: 'スコープの見直し検討',
    weeklyMeeting: true,
  },
  ORANGE: {
    message: 'かなり厳しい状況',
    action: 'リソース追加またはスコープ削減必須',
    weeklyMeeting: true,
    dailyCheck: true,
  },
  RED: {
    message: 'プロジェクト危機',
    action: '緊急対策会議開催',
    weeklyMeeting: true,
    dailyCheck: true,
    stakeholderAlert: true,
  },
};

自動化された共有システム

Slack と連携した自動通知システムを構築しました：

javascript// Slack への自動通知
const sendBurndownUpdate = async (
  teamChannel,
  riskData
) => {
  const message = {
    channel: teamChannel,
    attachments: [
      {
        color: getRiskColor(riskData.level),
        title: `🔥 プロジェクト進捗アップデート`,
        fields: [
          {
            title: '現在のヤバさレベル',
            value: `${riskData.level} - ${riskData.message}`,
            short: true,
          },
          {
            title: '推奨アクション',
            value: riskData.action,
            short: true,
          },
          {
            title: '完了予測日',
            value: riskData.projectedDate,
            short: true,
          },
        ],
      },
    ],
  };

  await slack.chat.postMessage(message);
};

早期警告アラートの仕組み構築

多段階の警告システム

markdownレベル 1: 自動データ収集

- GitHub コミット頻度の監視
- Jira チケットの更新状況
- コードレビューの滞留時間

レベル 2: トレンド分析

- 3 日連続でベロシティ低下 → YELLOW アラート
- 5 日連続で理想ラインから乖離 → ORANGE アラート

レベル 3: 人的介入

- チームリーダーへの即座通知
- 1-on-1 ミーティングの自動スケジューリング
- 必要に応じてステークホルダーへの報告

個人レベルでの早期警告

javascript// 個人の作業負荷監視
const monitorIndividualWorkload = (member) => {
  const recentMetrics = {
    dailyCommits: member.getCommitsLast7Days(),
    avgWorkingHours: member.getAvgWorkingHours(),
    codeReviewSpeed: member.getReviewResponseTime(),
    questionFrequency: member.getSlackQuestions(),
  };

  // バーンアウト予兆の検出
  if (
    recentMetrics.avgWorkingHours > 10 &&
    recentMetrics.questionFrequency <
      member.baseline.questions * 0.3
  ) {
    return {
      risk: 'BURNOUT_WARNING',
      action: 'IMMEDIATE_1ON1_REQUIRED',
    };
  }
};

気づきと変化

Before/After：残業時間とチーム離脱率の改善

バーンダウンチャートの導入により、チーム全体の働き方が劇的に改善しました。

定量的な成果

Before（導入前 6 ヶ月平均）

チーム平均残業時間: 月 68 時間
プロジェクト遅延率: 85%（10 プロジェクト中 8.5 プロジェクト）
チームメンバー離脱率: 30%（年間）
バーンアウト事例: 月 1.5 件

After（導入後 6 ヶ月平均）

チーム平均残業時間: 月 32 時間（-53%）
プロジェクト遅延率: 35%（10 プロジェクト中 3.5 プロジェクト）
チームメンバー離脱率: 8%（年間、-73%）
バーンアウト事例: 月 0.2 件（-87%）

労働時間分布の健全化

markdown【残業時間分布の変化】
Before:
- 0-20時間: 20%のメンバー
- 21-50時間: 30%のメンバー
- 51-80時間: 35%のメンバー
- 80時間超: 15%のメンバー

After:
- 0-20時間: 60%のメンバー
- 21-40時間: 30%のメンバー
- 41-60時間: 10%のメンバー
- 60時間超: 0%のメンバー

特に注目すべきは、80 時間超の過重労働が完全になくなったことです。

プロジェクト完了予測精度の向上

予測精度の劇的改善

予測精度の比較

javascript// 従来の予測精度
const traditionalAccuracy = {
  week1: '95%正確', // 楽観的すぎる予測
  week2: '80%正確',
  week3: '60%正確',
  week4: '30%正確', // 完全に外れる
  finalWeek: '破綻',
};

// バーンダウンチャート導入後
const burndownAccuracy = {
  week1: '85%正確', // 現実的な予測
  week2: '88%正確', // 精度向上
  week3: '90%正確', // さらに向上
  week4: '92%正確', // 高精度維持
  finalWeek: '95%正確', // 最終的に高精度
};

リアルタイム判断の効果

早期警告システムにより、以下のような迅速な判断が可能になりました：

成功事例：E-コマースサイトリニューアル

Day 5: YELLOW アラート発生
Day 6: スコープ見直し（非重要機能の次フェーズ送り）
Day 10: GREEN レベルに回復
結果：予定通りリリース、品質も維持

成功事例：モバイルアプリ対応

Day 3: ORANGE アラート発生
Day 4: フロントエンドエンジニア 1 名追加投入
Day 7: YELLOW レベルに改善
結果：1 週間遅れでリリース（従来なら 1 ヶ月遅れ）

チーム心理的安全性の向上

正直な報告ができる環境の構築

バーンダウンチャートの可視化により、「現状を正直に報告する」文化が生まれました。

変化の具体例

Before

markdownPM: 「進捗はいかがですか？」
Dev: 「大丈夫です、なんとかなります」
（内心：全然間に合わないけど言えない...）

After

markdownPM: 「チャートを見ると ORANGE ですね」
Dev: 「そうですね。API 統合で想定外の課題が出ています」
PM: 「具体的にはどんな？サポートできることはある？」

チーム内の相互支援システム

javascript// 相互支援の仕組み化
const teamSupportSystem = {
  dailyStandUp: {
    format: '昨日/今日/障害',
    timeLimit: '各人3分',
    focusOn: 'ブロッカーの早期発見',
  },

  pairProgramming: {
    trigger: 'YELLOW アラート時',
    duration: '最低2時間/日',
    rotation: '週次でペア変更',
  },

  knowledgeSharing: {
    frequency: '週1回',
    format: '15分のライトニングトーク',
    theme: '今週のトラブルシューティング',
  },
};

皆さんのチームでも、「困っていることを気軽に相談できる」環境を作ることで、どれほどプロジェクトが安定するでしょうか？

他のチームで試すなら

バーンダウンチャート導入の段階的アプローチ

私の経験を踏まえ、他のチームで実践する際の具体的なロードマップをご紹介します。

フェーズ 1：基盤構築（2-3 週間）

markdownWeek 1: データ収集の仕組み作り
□ 現在使用中のプロジェクト管理ツールの分析
□ ストーリーポイント制度の導入（未導入の場合）
□ 日次進捗記録のルール策定
□ チームメンバーへの説明と合意形成

Week 2: 簡易バーンダウンチャートの作成
□ Excel または Google Sheets での手動チャート作成
□ 1 週間の試験運用
□ フィードバック収集と改善点の特定

Week 3: 改善と定着
□ チャートの見やすさ改善
□ 更新頻度とタイミングの最適化
□ チーム全体での振り返り実施

フェーズ 2：自動化とアラート（3-4 週間）

必要な技術スキル

基本的な JavaScript（グラフライブラリの使用）
API 連携の知識（Jira, GitHub との連携）
Slack Bot の基本的な設定

javascript// 段階的自動化の例
// Step 1: 手動更新 → 半自動更新
const semiAutoUpdate = () => {
  // Jira API からデータ取得
  const tickets = await jira.getSprintTickets();
  const remaining = calculateRemainingWork(tickets);

  // Google Sheets に自動更新
  await sheets.updateBurndownData(remaining);
};

// Step 2: 完全自動化
const fullyAutomated = () => {
  // 毎日定時実行
  cron.schedule('0 9 * * *', () => {
    generateBurndownChart();
    sendSlackUpdate();
    checkRiskLevels();
  });
};

フェーズ 3：高度な分析（1-2 ヶ月）

markdownAdvanced Features:
□ ベロシティの自動計算
□ 個人レベルの作業負荷分析
□ 予測アルゴリズムの精度向上
□ 複数プロジェクト間のリソース最適化

ツール選定と運用ルールの確立

推奨ツール構成（予算別）

最小構成（月額 0 円）

markdown必須ツール:

- Google Sheets（チャート作成）
- Google Apps Script（簡易自動化）
- Slack（無料プラン）

制限事項:

- 手動更新が中心
- リアルタイム性に制限
- 分析機能は基本的なもののみ

標準構成（月額 50-100 ドル）

markdown推奨ツール:

- Jira（プロジェクト管理）
- Slack（有料プラン）
- Chart.js + 自作ダッシュボード
- GitHub Actions（自動化）

メリット:

- ほぼ完全自動化
- リアルタイム更新
- カスタマイズ性が高い

本格構成（月額 200-500 ドル）

markdownエンタープライズツール:

- Azure DevOps / Jira Advanced
- Power BI / Tableau
- Microsoft Teams / Slack Enterprise
- Custom Dashboard with AI predictions

メリット:

- 高度な予測分析
- 組織レベルでの統合
- 機械学習による最適化

運用ルールの具体例

デイリースタンドアップの改善

markdown従来（10 分）:

- 昨日やったこと
- 今日やること
- 困っていること

改善後（15 分）:

- バーンダウンチャートの確認（2 分）
- 個人進捗とブロッカー（各人 2 分）
- ヤバさレベルに応じた対策議論（3 分）
- アクションアイテムの確認（3 分）

失敗プロジェクトからの学習方法

私自身が経験した失敗とその対策をお伝えします。

失敗パターン 1：データ収集の負担増

問題: バーンダウンチャート更新のために余計な工数が発生

失敗事例

毎日30分のデータ入力作業が発生
→ チームメンバーから「本末転倒」という声
→ 更新が滞り、チャートが無意味化

解決策: 自動化の徹底

javascript// Git コミットから自動進捗計算
const autoProgressTracking = async () => {
  const commits = await git.getCommitsToday();
  const completedTasks = commits
    .filter((commit) => commit.message.includes('#done'))
    .map((commit) => extractTaskId(commit.message));

  await updateBurndownAutomatically(completedTasks);
};

失敗パターン 2：過度な監視による圧迫感

問題: チームメンバーが「監視されている」と感じて萎縮

失敗事例

個人別バーンダウンチャートを導入
→ 成果の個人比較が始まる
→ チーム雰囲気の悪化
→ 協力よりも個人成果を重視する文化に

解決策: チーム全体での共有価値観の確立

markdownバーンダウンチャートの目的:
✅ チーム全体の成功
✅ 早期問題発見
✅ 健康的な働き方の実現

❌ 個人の評価
❌ 成果の比較
❌ プレッシャーの増大

失敗パターン 3：アラート疲れ

問題: アラートが多すぎて重要な警告を見逃す

解決策: 段階的エスカレーション

javascriptconst smartAlertSystem = {
  level1: {
    condition: 'minor_delay',
    action: 'team_channel_notification',
    frequency: 'daily',
  },
  level2: {
    condition: 'significant_delay',
    action: 'direct_message_to_lead',
    frequency: 'immediate',
  },
  level3: {
    condition: 'critical_delay',
    action: 'stakeholder_notification',
    frequency: 'immediate',
    escalation: 'meeting_required',
  },
};

振り返りと、これからの自分へ

プロジェクトマネジメントスキルの重要性認識

この取り組みを通じて、私はフロントエンドエンジニアにとってもプロジェクトマネジメントスキルが不可欠だと確信しました。

技術者としての視点の進化

Before: 「与えられたタスクを技術的に実装したい」 After: 「プロジェクト全体の成功に技術で貢献したい」

特にフロントエンド開発では、ユーザー体験に直結する部分を担当するため、スケジュール遅延の影響が非常に大きいことを実感しました。「コードが書ければ良い」から「プロジェクトを成功に導く技術者」への意識変化は、私のキャリアにとって大きな転換点でした。

プロジェクト思考の獲得

javascript// 従来の思考パターン
const oldMindset = {
  focus: 'タスク完了',
  scope: '個人の責任範囲',
  timeline: '目の前の作業',
  quality: '技術的完璧性',
};

// 新しい思考パターン
const newMindset = {
  focus: 'プロジェクト成功',
  scope: 'チーム全体の成果',
  timeline: 'プロジェクト全体の流れ',
  quality: 'ユーザー価値とのバランス',
};

データドリブンな意思決定力の獲得

バーンダウンチャートの導入により、感覚に頼らない意思決定ができるようになりました。

具体的な意思決定の変化

技術的判断の例

makefile従来: 「React の新バージョンを使いたい」
現在: 「スケジュールリスクを考慮し、安定版を選択。新バージョンは次フェーズで検討」

従来: 「このコンポーネントをもっと綺麗にリファクタリングしたい」
現在: 「現在 ORANGE アラート中のため、リファクタリングは最小限に留め、機能完成を優先」

データ分析スキルの向上

javascript// 身についたスキル例
const dataAnalysisSkills = {
  trendAnalysis: '進捗トレンドから完了予測',
  correlationAnalysis: '作業時間と品質の相関分析',
  riskAssessment: 'データに基づくリスク評価',
  resourceOptimization: '最適なリソース配分の計算',
};

これらのスキルは、技術的な問題解決だけでなく、ビジネス判断においても非常に有用でした。

チームリーダーとしての責任感向上

リーダーシップスタイルの確立

バーンダウンチャートを通じて、私は「支援型リーダーシップ」を身につけることができました。

markdown支援型リーダーのアプローチ:

データで現状を可視化
↓
問題を早期発見
↓  
チームと一緒に解決策を検討
↓
必要なサポートを提供
↓
成果をチーム全体で共有

メンバー育成への貢献

ジュニアエンジニアのサポート例

yamlWeek 1: バーンダウンチャートの読み方を教える
Week 2: 自分の進捗を客観視できるようにサポート
Week 3: リスク予測ができるようになるまで伴走
Week 4: 自立してプロジェクト管理できるレベルに到達

「教える」のではなく「一緒に成長する」スタンスで、チーム全体のスキル向上に貢献できるようになりました。

皆さんも、技術力と同時にプロジェクトマネジメント力を身につけることで、より大きな影響力を持てるはずです。

まとめ

バーンダウンチャートを活用したプロジェクトの「ヤバさ」共有は、チームの健康とプロジェクト成功の両方を実現する強力な手法です。

私の経験から得られた核心的な学びは以下の通りです：

重要なポイント

見える化の力: 数値とグラフによる客観的現状把握がすべての改善の出発点
早期発見・早期対応: 問題が小さいうちに対処することで、大きな破綻を防げる
チーム全体での共有: 個人の頑張りではなく、チーム一丸となった課題解決
持続可能な働き方: 長期的なチーム力向上と個人の成長を両立

実践への第一歩

明日からでも始められることがあります：

現在のプロジェクトで「あと何日で終わるか」を数値で計算してみる
チームメンバーと「理想的な進捗とは何か」を話し合う
1 つのスプリントでバーンダウンチャートを手動で作成してみる

小さな一歩から始めて、徐々にチーム全体の予測精度と健康度を向上させていきましょう。

フロントエンドエンジニアとして、美しい UI/UX を作ることと同じくらい、健康的で持続可能なプロジェクト運営も重要です。私たちの技術力が、チーム全体の成功と個人の成長につながるよう、戦略的なプロジェクト管理を一緒に実践していきませんか？

燃え尽きるのは誰だ？バーンダウンチャートでプロジェクトの「ヤバさ」をチームで共有する方法

背景と課題

プロジェクト進捗の見えない化による突然死

典型的な崩壊パターン

個人の頑張りに依存した無理なスケジュール管理

危険な兆候を見逃していた実例

チームメンバーのバーンアウト続出の実態

バーンアウトの連鎖反応

試したこと・実践内容

バーンダウンチャートの導入と可視化手法

リアルタイム バーンダウンチャートの構築

細分化されたタスク管理

「ヤバさレベル」の定義と共有システム

客観的な危険度指標の導入

自動化された共有システム

早期警告アラートの仕組み構築

多段階の警告システム

個人レベルでの早期警告

気づきと変化

Before/After：残業時間とチーム離脱率の改善

定量的な成果

労働時間分布の健全化

プロジェクト完了予測精度の向上

予測精度の劇的改善

リアルタイム判断の効果

チーム心理的安全性の向上

正直な報告ができる環境の構築

チーム内の相互支援システム

他のチームで試すなら

バーンダウンチャート導入の段階的アプローチ

フェーズ 1：基盤構築（2-3 週間）

フェーズ 2：自動化とアラート（3-4 週間）

フェーズ 3：高度な分析（1-2 ヶ月）

ツール選定と運用ルールの確立

推奨ツール構成（予算別）

運用ルールの具体例

失敗プロジェクトからの学習方法

失敗パターン 1：データ収集の負担増

失敗パターン 2：過度な監視による圧迫感

失敗パターン 3：アラート疲れ

振り返りと、これからの自分へ

プロジェクトマネジメントスキルの重要性認識

技術者としての視点の進化

プロジェクト思考の獲得

データドリブンな意思決定力の獲得

具体的な意思決定の変化

データ分析スキルの向上

チームリーダーとしての責任感向上

リーダーシップスタイルの確立

メンバー育成への貢献

まとめ

重要なポイント

実践への第一歩

記事Article

【対処法】Cursorが異常に重い場合の原因と対応（アップデート後も）

Storybook 入門：UI コンポーネント開発を劇的に効率化しよう

Node.js 環境変数と設定管理：dotenv と process.env の使い方

モーダルやダイアログの「開閉状態」どこで持つ問題、Jotai ならこう解決する

Jest × CI（GitHub Actions）で自動テストを実現する

ESLint のパフォーマンス最適化：実行速度を上げるコツ

ブログBlog

燃え尽きるのは誰だ？バーンダウンチャートでプロジェクトの「ヤバさ」をチームで共有する方法

「誰が、何を、なぜ」が伝わらないユーザーストーリーは無意味。開発者が本当に欲しいストーリーの書き方

「誰が何するんだっけ？」をなくす。スクラムの役割とイベント、最初にこれだけは押さえておきたいこと

スクラムチーム、本当に機能してる？PO・SM・開発チームの「あるべき姿」と現実のギャップ

アジャイル開発とウォーターフォールの違いと選び方

アジャイルマニフェスト徹底解説：価値観と原則を紐解く

書籍レビューReview

子育ての悩みが一気に解決！『子どもの心のコーチング』菅原裕子

もう三日坊主とはサヨナラ！『続ける思考』井上新八

チーム開発が劇的に変わった！『リーダブルコード』Dustin Boswell & Trevor Foucher

アジャイル初心者でも大丈夫！『アジャイルサムライ − 達人開発者への道』Jonathan Rasmusson

人生が作品になる！『自分の中に毒を持て』岡本太郎

体調不良の 99%が解決！『眠れなくなるほど面白い 図解 自律神経の話』小林弘幸著で学ぶ、現代人必須の自律神経コントロール術と人生を変える健康革命

リアルタイムバーンダウンチャートの構築

体調不良の 99%が解決！『眠れなくなるほど面白い図解自律神経の話』小林弘幸著で学ぶ、現代人必須の自律神経コントロール術と人生を変える健康革命