Mermaid と PlantUML の違い徹底比較:選び方と連携テクニック

ソフトウェア開発において、システムの設計や仕様を視覚的に表現することは非常に重要です。特に複雑なアーキテクチャやビジネスロジックを説明する際、図解は言葉だけでは伝わりにくい情報を瞬時に理解させる力を持っています。
近年注目を集めているのが、コードで図を描く「Diagram as Code」という概念です。その代表的なツールである Mermaid と PlantUML は、それぞれ異なる特徴と利点を持っており、適切な選択が開発効率に大きく影響します。
本記事では、Mermaid と PlantUML の違いを徹底的に比較し、プロジェクトの特性に応じた最適な選択方法をご紹介いたします。さらに、両ツールを連携させる実践的なテクニックについても詳しく解説していきます。
背景
ダイアグラムツールの重要性
現代のソフトウェア開発では、システムの複雑化が進み、設計書や仕様書の重要性がますます高まっています。従来の文書ベースの説明だけでは、チームメンバー間での理解にズレが生じやすく、開発効率の低下を招いてしまいます。
ダイアグラムツールを活用することで、以下のような効果が期待できます。
効果 | 詳細 |
---|---|
理解の促進 | 複雑なロジックを視覚的に表現し、瞬時に全体像を把握できます |
コミュニケーション向上 | チーム間での認識共有がスムーズになり、誤解を防げます |
メンテナンス性向上 | 設計変更時に図も同時に更新でき、常に最新の状態を保てます |
品質向上 | 設計段階で問題を発見でき、バグの早期発見につながります |
特に、Diagram as Code アプローチでは、テキストベースで図を作成するため、バージョン管理が容易になり、レビューや差分確認も効率的に行えるのです。
Mermaid と PlantUML の位置づけ
Mermaid と PlantUML は、どちらも Diagram as Code ツールとして広く利用されていますが、それぞれ異なる背景と思想を持って開発されました。
以下の図は、両ツールの技術的位置づけを示しています。
mermaidflowchart LR
dev[開発者] -->|テキスト記述| tools[ダイアグラムツール]
tools --> mermaid[Mermaid<br/>JavaScript基盤]
tools --> plantuml[PlantUML<br/>Java基盤]
mermaid -->|軽量・高速| web[Web統合]
plantuml -->|高機能・安定| enterprise[エンタープライズ]
web --> github[GitHub/Notion]
enterprise --> server[サーバー環境]
Mermaid は JavaScript 環境で動作し、Web ブラウザでの描画に特化しています。一方、PlantUML は Java 環境で動作し、サーバーサイドでの高品質な画像生成を得意としています。
どちらも素晴らしいツールですが、プロジェクトの性質や開発環境によって、より適したツールが存在するのです。
課題
ダイアグラムツール選択の迷い
多くの開発チームが直面するのが、「どのダイアグラムツールを選べばよいのか」という悩みです。特に Mermaid と PlantUML は、どちらもテキストベースで図を作成できるという共通点があるため、選択が困難になります。
実際に開発現場で聞かれる声をご紹介しましょう。
フロントエンド開発者の声 「GitHub の README に図を入れたいけど、どちらが良いの?」
バックエンド開発者の声 「複雑なアーキテクチャ図を作りたいが、どちらが表現力が高い?」
プロジェクトマネージャーの声 「チーム全体で統一したツールを使いたいが、学習コストを考えると...」
これらの悩みは、単純にツールの優劣だけでは解決できません。プロジェクトの特性、チームのスキルレベル、既存環境との親和性など、様々な要因を考慮する必要があります。
使い分けの明確な基準がない問題
現在のダイアグラムツール選択には、明確な判断基準が不足しているという問題があります。多くの場合、「なんとなく使っている」「最初に覚えたものをそのまま使っている」という状況が見受けられます。
以下の図は、適切な選択基準が不明確なことで生じる問題を示しています。
mermaidstateDiagram-v2
[*] --> 選択迷い
選択迷い --> 試行錯誤: 手当たり次第
試行錯誤--> 時間浪費: 学習コスト増加
時間浪費 --> チーム分裂: 統一されない
チーム分裂 --> 品質低下: メンテナンス困難
品質低下 --> [*]
選択迷い --> 適切選択: 明確な基準
適切選択 --> 効率向上: 最適化された環境
効率向上 --> [*]
この問題を解決するためには、プロジェクトの特性に応じた体系的な選択指針が必要です。技術的な特徴だけでなく、実際の使用場面での違いを理解することが重要になります。
解決策
Mermaid の特徴と強み
記法の簡潔性
Mermaid の最大の特徴は、その記法の簡潔さです。初心者でも直感的に理解でき、短時間で図を作成できる設計になっています。
以下は、簡単なフローチャートの例です。
mermaidflowchart TD
A[開始] --> B{条件判定}
B -->|Yes| C[処理A]
B -->|No| D[処理B]
C --> E[終了]
D --> E
上記の図を作成するコードは、わずか 5 行で完成します。
markdwon```mermaid
flowchart TD
A[開始] --> B{条件判定}
B -->|Yes| C[処理A]
B -->|No| D[処理B]
C --> E[終了]
D --> E
```
Mermaidの記法は英語に近い自然な表現を採用しており、コードを読むだけで図の内容が想像できます。矢印(-->
)や括弧の使い方も直感的で、学習コストを大幅に削減できるのです。
ブラウザ対応の優位性
MermaidはJavaScript製のため、Webブラウザで直接レンダリングできます。これにより、特別なソフトウェアのインストールが不要で、どの環境でも同じように動作します。
主要なブラウザ対応状況は以下の通りです。
ブラウザ | 対応状況 | パフォーマンス |
---|---|---|
Chrome | ◎ 完全対応 | 高速 |
Firefox | ◎ 完全対応 | 高速 |
Safari | ◎ 完全対応 | 高速 |
Edge | ◎ 完全対応 | 高速 |
さらに、リアルタイムプレビュー機能により、コードを書きながら即座に結果を確認できます。これは開発効率の大幅な向上につながります。
GitHubやNotionでの標準対応
近年、多くのプラットフォームでMermaidが標準サポートされるようになりました。特にGitHubでは、README.mdファイルに直接Mermaidコードを記述するだけで、自動的に図として表示されます。
markdown// GitHub README.md での使用例
```mermaid
sequenceDiagram
participant User
participant Frontend
participant Backend
participant Database
User->>Frontend: リクエスト
Frontend->>Backend: API呼び出し
Backend->>Database: データ取得
Database-->>Backend: 結果返却
Backend-->>Frontend: JSON返却
Frontend-->>User: 画面表示
```
この標準対応により、ドキュメンテーションの作業が格段に簡素化され、チーム全体での情報共有がスムーズになります。
PlantUML の特徴と強み
豊富な図形タイプ
PlantUMLの最大の強みは、対応している図形タイプの豊富さです。システム設計で必要とされるほぼ全ての図形を作成できます。
以下が対応している主な図形タイプです。
カテゴリ | 図形タイプ | 用途 |
---|---|---|
構造図 | クラス図、オブジェクト図、コンポーネント図 | システム構造の表現 |
振る舞い図 | シーケンス図、アクティビティ図、状態図 | 動作フローの表現 |
実装図 | 配置図、パッケージ図 | 物理構成の表現 |
特殊図 | マインドマップ、ガント図、ネットワーク図 | プロジェクト管理・インフラ |
特に、エンタープライズレベルのシステム設計で重要なコンポーネント図や配置図は、Mermaidでは表現が困難な場合が多く、PlantUMLの優位性が際立ちます。
高度なカスタマイズ性
PlantUMLは、図の見た目を細かくカスタマイズできる機能が充実しています。色、フォント、レイアウト、スタイルなど、プレゼンテーション品質の高い図を作成できます。
以下は、カスタマイズの例です。
java@startuml
!theme cerulean-outline
skinparam backgroundColor #FFFFCC
skinparam classBackgroundColor #FFFFFF
skinparam classBorderColor #000000
class UserService {
-userRepository: UserRepository
+createUser(user: User): User
+getUserById(id: Long): User
+updateUser(user: User): User
+deleteUser(id: Long): void
}
class UserRepository {
+save(user: User): User
+findById(id: Long): Optional<User>
+findAll(): List<User>
+delete(id: Long): void
}
UserService --> UserRepository : uses
@enduml
このように、テーマの適用、背景色の変更、クラスのスタイリングなど、詳細な見た目の調整が可能です。プレゼンテーション資料として使用する場合、この高度なカスタマイズ性は大きなメリットとなります。
Java 環境での安定性
PlantUML は Java で実装されているため、サーバー環境での安定した動作が期待できます。大量の図を一括生成する場合や、CI/CD パイプラインに組み込んで継続的にドキュメントを生成する場合に、その安定性が威力を発揮します。
以下の図は、PlantUML の処理フローを示しています。
mermaidsequenceDiagram
participant CI as CI/CDパイプライン
participant Java as Java Runtime
participant PlantUML as PlantUML Engine
participant Output as 画像ファイル
CI->>Java: PlantUMLコマンド実行
Java->>PlantUML: テキストファイル読み込み
PlantUML->>PlantUML: パース・レンダリング
PlantUML->>Output: PNG/SVG/PDF生成
Output-->>CI: ドキュメント完成
Java 環境での動作により、メモリ管理やエラーハンドリングが優秀で、大規模プロジェクトでも安定して動作します。
具体例
同一内容での記法比較
実際に同じ内容の図を、Mermaid と PlantUML で作成して比較してみましょう。これにより、両者の記法の違いと特徴を明確に理解できます。
フローチャート作成比較
ユーザー認証のフローを例に、両ツールでの記法を比較します。
Mermaid での記述
markdown```mermaid
flowchart TD
A[ユーザー] --> B[ログイン画面]
B --> C{認証情報入力}
C -->|正常| D[認証処理]
C -->|異常| E[エラー表示]
D --> F{認証結果}
F -->|成功| G[メイン画面]
F -->|失敗| H[ログイン失敗]
E --> B
H --> B
```
PlantUMLでの記述
java```plantuml
@startuml
start
:ユーザー;
:ログイン画面;
:認証情報入力;
if (入力チェック) then (正常)
:認証処理;
if (認証結果) then (成功)
:メイン画面;
stop
else (失敗)
:ログイン失敗;
endif
else (異常)
:エラー表示;
endif
:ログイン画面;
stop
@enduml
```
比較結果
- Mermaid: 視覚的で直感的な記法。矢印で流れが明確
- PlantUML: プログラミング言語に近い構造的な記法。条件分岐が明確
シーケンス図作成比較
API通信のシーケンス図で比較してみましょう。
Mermaidでの記述
markdown```mermaid
sequenceDiagram
participant C as Client
participant A as API Gateway
participant S as Service
participant D as Database
C->>+A: HTTP Request
A->>+S: Service Call
S->>+D: SQL Query
D-->>-S: Result Set
S-->>-A: JSON Response
A-->>-C: HTTP Response
```
PlantUMLでの記述
java```plantuml
@startuml
participant Client as C
participant "API Gateway" as A
participant Service as S
participant Database as D
C -> A : HTTP Request
activate A
A -> S : Service Call
activate S
S -> D : SQL Query
activate D
D --> S : Result Set
deactivate D
S --> A : JSON Response
deactivate S
A --> C : HTTP Response
deactivate A
@enduml
```
記法の特徴
項目 | Mermaid | PlantUML |
---|---|---|
学習コスト | 低い | 中程度 |
表現力 | 標準的 | 高い |
カスタマイズ | 限定的 | 豊富 |
可読性 | 高い | 中程度 |
クラス図作成比較
オブジェクト指向設計のクラス図で最終比較を行います。
Mermaidでの記述
markdown```mermaid
classDiagram
class User {
-id: Long
-name: String
-email: String
+getId() Long
+getName() String
+setEmail(email: String) void
}
class Order {
-orderId: Long
-userId: Long
-amount: BigDecimal
+calculateTotal() BigDecimal
}
User ||--o{ Order : places
```
PlantUMLでの記述
java```plantuml
@startuml
class User {
-id: Long
-name: String
-email: String
+getId(): Long
+getName(): String
+setEmail(email: String): void
}
class Order {
-orderId: Long
-userId: Long
-amount: BigDecimal
+calculateTotal(): BigDecimal
}
User ||--o{ Order : places
@enduml
```
両ツールとも基本的なクラス図は同様に作成できますが、PlantUMLはより詳細な関係性の表現や、パッケージ構造の表現に優れています。
実際の開発現場での使い分け事例
実際のプロジェクトでは、どのように使い分けられているのかを具体的な事例でご紹介します。
スタートアップ企業A社の事例
- プロジェクト規模: 開発者5名、リリースまで3か月
- 選択ツール: Mermaid
- 理由: GitHubでの標準サポート、学習コストの低さ、迅速な開発
A社では、全ての設計書をGitHubのWikiで管理しており、Mermaidの標準サポートが決定的な要因となりました。短期間でチーム全員がツールを習得でき、開発速度を落とすことなくドキュメント化が進められました。
大手企業B社の事例
- プロジェクト規模: 開発者50名、開発期間18か月
- 選択ツール: PlantUML
- 理由: 高品質なドキュメント要求、複雑なシステム設計、長期保守性
B社では、顧客向けの設計書として高品質な図が要求され、PlantUMLの豊富なカスタマイズ機能が重要な選択要因でした。また、複雑なマイクロサービス アーキテクチャを表現するため、PlantUMLの表現力の高さが活用されています。
以下の図は、使い分けの判断フローを示しています。
mermaidflowchart TD
start[プロジェクト開始] --> team{チーム規模}
team -->|小規模 5名以下| speed[開発速度重視]
team -->|大規模 10名以上| quality[品質・表現力重視]
speed --> web{Web統合}
web -->|必要| mermaid[Mermaid選択]
web -->|不要| simple{記法の簡潔性}
simple -->|重要| mermaid
simple -->|不要| either[どちらでも可]
quality --> custom{カスタマイズ}
custom -->|必要| plantuml[PlantUML選択]
custom -->|不要| complex{複雑な図}
complex -->|必要| plantuml
complex -->|不要| either
この判断フローにより、プロジェクトの特性に応じた適切なツール選択が可能になります。
選び方の判断基準
プロジェクト規模による選択
プロジェクトの規模は、ダイアグラムツール選択における最も重要な要因の一つです。規模に応じて、求められる機能や運用方法が大きく異なるためです。
小規模プロジェクト(開発者 1-5 名)の場合
小規模プロジェクトでは、以下の特徴があります。
- 迅速な開発が要求される
- 学習コストは最小限に抑えたい
- 複雑な図よりも基本的な図で十分
- ツール導入の手間を避けたい
このような要件に対して、Mermaid が最適です。理由は以下の通りです。
要件 | Mermaid の対応 |
---|---|
迅速な開発 | 記法が簡潔で、短時間で図を作成可能 |
学習コスト | 直感的な記法で、1-2 時間で基本習得可能 |
基本的な図 | フローチャート、シーケンス図は十分な機能 |
導入の簡単さ | Web ブラウザがあれば即座に利用開始 |
大規模プロジェクト(開発者 10 名以上)の場合
大規模プロジェクトでは、異なる要件が重要になります。
- 高品質なドキュメントが必要
- 複雑なシステム構成を表現したい
- 長期間のメンテナンスを考慮
- 標準化された出力フォーマット
これらの要件には、PlantUML が適している場合が多いです。
mermaidgraph LR
subgraph 小規模プロジェクト
A[迅速性] --> M[Mermaid推奨]
B[簡単さ] --> M
C[Web統合] --> M
end
subgraph 大規模プロジェクト
D[品質] --> P[PlantUML推奨]
E[表現力] --> P
F[安定性] --> P
end
チーム環境による選択
チームの技術的背景や開発環境も、ツール選択に大きく影響します。
フロントエンド中心のチーム
JavaScript/TypeScript を主に扱うチームでは、Mermaid の親和性が高くなります。
- Node.js 環境での統合が容易
- Webpack やビルドツールとの連携
- React/Vue コンポーネントとしての活用
バックエンド・インフラ中心のチーム
Java/.NET/Python を主に扱うチームでは、PlantUML が適している場合があります。
- サーバーサイドでのバッチ処理
- CI/CD パイプラインでの自動生成
- エンタープライズ環境での安定運用
チームスキルレベルによる判断
スキルレベル | 推奨ツール | 理由 |
---|---|---|
初心者多数 | Mermaid | 学習コストが低く、迅速な習得が可能 |
中級者中心 | どちらでも | プロジェクト要件に応じて選択 |
上級者多数 | PlantUML | 高度な機能を活用し、品質の高い図を作成 |
出力形式による選択
最終的な出力形式や用途も、重要な選択基準となります。
Web 表示が中心の場合
- GitHub README
- Web 上のドキュメントサイト
- 社内 Wiki(Notion、Confluence など)
このような用途では、Mermaid が圧倒的に有利です。多くのプラットフォームで標準サポートされており、特別な変換処理が不要です。
印刷・プレゼンテーション用途
- 顧客向け設計書
- プレゼンテーション資料
- 技術仕様書(PDF)
高品質な印刷出力や、プレゼンテーションでの使用を想定している場合は、PlantUML が優秀です。
以下に出力形式別の比較を示します。
出力形式 | Mermaid | PlantUML | 推奨 |
---|---|---|---|
Web 表示 | ◎ ネイティブ対応 | ○ 画像変換必要 | Mermaid |
PNG 画像 | ○ 基本品質 | ◎ 高品質 | PlantUML |
△ 限定的 | ◎ 高品質 | PlantUML | |
SVG | ◎ 高品質 | ◎ 高品質 | 同等 |
プレゼン | ○ 基本対応 | ◎ カスタマイズ豊富 | PlantUML |
連携テクニック
Mermaid と PlantUML の併用戦略
実際の開発現場では、Mermaid と PlantUML を使い分けることで、それぞれの利点を最大限に活用できます。効果的な併用戦略をご紹介します。
用途別使い分け戦略
プロジェクト内での図の用途に応じて、以下のような使い分けが効果的です。
mermaidgraph TD
docs[ドキュメント作成] --> internal{内部・外部}
internal -->|内部| quick[迅速な共有重視]
internal -->|外部| quality[品質重視]
quick --> readme[README・Wiki]
quick --> review[レビュー資料]
readme --> mermaid[Mermaid使用]
review --> mermaid
quality --> client[顧客向け資料]
quality --> present[プレゼンテーション]
client --> plantuml[PlantUML使用]
present --> plantuml
具体的な使い分け例
用途 | ツール選択 | 理由 |
---|---|---|
設計レビュー用の簡易図 | Mermaid | 迅速な作成、修正の容易さ |
API 仕様書のシーケンス図 | Mermaid | Web ドキュメントでの表示 |
顧客向け設計書 | PlantUML | 高品質な出力、カスタマイズ性 |
アーキテクチャ概要図 | PlantUML | 複雑な関係性の表現力 |
開発チーム内の議論用 | Mermaid | リアルタイム編集、共有の容易さ |
ファイル管理とディレクトリ構成
併用する場合のファイル管理方法も重要です。以下のようなディレクトリ構成を推奨します。
perldocs/
├── diagrams/
│ ├── mermaid/ # Web表示用の図
│ │ ├── api-flow.md
│ │ ├── user-story.md
│ │ └── system-overview.md
│ ├── plantuml/ # 高品質出力用の図
│ │ ├── architecture.puml
│ │ ├── class-design.puml
│ │ └── deployment.puml
│ └── outputs/ # 生成された画像ファイル
│ ├── png/
│ ├── svg/
│ └── pdf/
├── README.md # Mermaid図を直接埋め込み
└── specs/ # PlantUMLから生成した画像を使用
└── system-design.md
変換ツールの活用
Mermaid と PlantUML の間での図の変換や、一元的な管理を支援するツールをご紹介します。
mermaid-to-plantuml 変換
基本的なフローチャートであれば、Mermaid から PlantUML への変換が可能です。
markdown// Mermaid記法
flowchart TD
A[開始] --> B{判定}
B -->|Yes| C[処理A]
B -->|No| D[処理B]
これを以下の PlantUML 記法に変換できます。
java@startuml
start
:開始;
if (判定) then (Yes)
:処理A;
else (No)
:処理B;
endif
stop
@enduml
自動変換スクリプト
Node.js を使用した変換スクリプトの例です。
javascriptconst fs = require('fs');
const path = require('path');
// Mermaidファイルを読み込み、基本的なPlantUML形式に変換
function convertMermaidToPlantUML(mermaidContent) {
let plantUMLContent = '@startuml\n';
// 簡易的な変換ロジック(実際にはより複雑な処理が必要)
const lines = mermaidContent.split('\n');
lines.forEach((line) => {
if (line.includes('-->')) {
// 矢印の変換処理
const converted = line.replace('-->', '-->');
plantUMLContent += converted + '\n';
}
// その他の変換ルール...
});
plantUMLContent += '@enduml';
return plantUMLContent;
}
一括変換ツールの作成
プロジェクト全体の図を一括で変換・更新するツールも作成できます。
bash#!/bin/bash
# diagram-converter.sh
# Mermaidファイルを検索してPNG生成
find ./docs/mermaid -name "*.md" -exec mmdc -i {} -o ./docs/outputs/png/{}.png \;
# PlantUMLファイルを検索してPNG生成
find ./docs/plantuml -name "*.puml" -exec plantuml -tpng -o ../outputs/png {} \;
echo "図の一括変換が完了しました"
CI/CD パイプラインでの統合
継続的インテグレーションパイプラインに図の自動生成を組み込むことで、常に最新のドキュメントを維持できます。
GitHub Actions での統合例
yamlname: Generate Diagrams
on:
push:
paths:
- 'docs/diagrams/**'
pull_request:
paths:
- 'docs/diagrams/**'
jobs:
generate-diagrams:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
# Mermaid図の生成
- name: Generate Mermaid Diagrams
uses: docker://ghcr.io/mermaid-js/mermaid-cli:latest
with:
args: -i docs/diagrams/mermaid/*.md -o docs/outputs/
# PlantUML図の生成
- name: Generate PlantUML Diagrams
uses: docker://plantuml/plantuml:latest
with:
args: -tpng docs/diagrams/plantuml/*.puml -o docs/outputs/
# 生成された図をコミット
- name: Commit generated diagrams
run: |
git config --local user.email "action@github.com"
git config --local user.name "GitHub Action"
git add docs/outputs/
git diff --staged --quiet || git commit -m "Auto-generated diagrams 🤖"
git push
このような自動化により、ドキュメントの更新作業を大幅に削減し、常に最新の状態を維持できます。
統合パイプラインのメリット
- ドキュメントの自動更新
- 手動作業によるミスの削減
- チーム全体での一貫性保持
- 変更履歴の追跡可能性
以下の図は、CI/CD パイプラインでの図生成フローを示しています。
mermaidsequenceDiagram
participant Dev as 開発者
participant Git as Gitリポジトリ
participant CI as CI/CDパイプライン
participant Output as 成果物
Dev->>Git: 図のソースコードpush
Git->>CI: webhook trigger
CI->>CI: Mermaid図生成
CI->>CI: PlantUML図生成
CI->>CI: 画像最適化
CI->>Git: 生成画像commit
CI->>Output: ドキュメント公開
Output-->>Dev: 更新通知
この自動化されたフローにより、開発者は図のメンテナンスに時間を取られることなく、本来の開発作業に集中できるようになります。
まとめ
Mermaid と PlantUML の徹底比較を通じて、両ツールの特徴と適用場面を詳しく解説してまいりました。
Mermaid の適用場面
- 小規模チームでの迅速な開発
- Web ベースのドキュメント作成
- GitHub/Notion での標準的な図表示
- 学習コストを抑えた導入
PlantUML の適用場面
- 大規模プロジェクトでの高品質ドキュメント
- 複雑なシステム設計の表現
- プレゼンテーション・印刷用途
- エンタープライズ環境での安定運用
重要なのは、「どちらが優秀か」ではなく、プロジェクトの特性に応じた最適な選択を行うことです。さらに、両ツールを併用することで、それぞれの利点を活かした効率的なドキュメント作成が実現できます。
CI/CD パイプラインとの統合により、図の自動生成・更新も可能になり、開発効率の大幅な向上が期待できるでしょう。
今後は、両ツールの進化とエコシステムの発展により、さらに使いやすく、高機能なダイアグラム作成環境が提供されることでしょう。ぜひ、プロジェクトの特性を見極めて、最適なツール選択を行ってください。
関連リンク
Mermaid 公式リソース
PlantUML 公式リソース
変換・統合ツール
学習リソース
- review
今の自分に満足していますか?『持たざる者の逆襲 まだ何者でもない君へ』溝口勇児
- review
ついに語られた業界の裏側!『フジテレビの正体』堀江貴文が描くテレビ局の本当の姿
- review
愛する勇気を持てば人生が変わる!『幸せになる勇気』岸見一郎・古賀史健のアドラー実践編で真の幸福を手に入れる
- review
週末を変えれば年収も変わる!『世界の一流は「休日」に何をしているのか』越川慎司の一流週末メソッド
- review
新しい自分に会いに行こう!『自分の変え方』村岡大樹の認知科学コーチングで人生リセット
- review
科学革命から AI 時代へ!『サピエンス全史 下巻』ユヴァル・ノア・ハラリが予見する人類の未来