gists

q

GTDは方法論？SBOMは方法論？個人のタスク管理を実践するためにルーチンタスク（繰り返しタスク）という発想に頼るやり方があるが、これの理屈を自分なりに体系的に整理したのも方法論？

方法論という言葉の射程を知りたい。

a

はい。結論から言うと、「方法論」にはかなり広い射程があります。
ただし広いとはいえ、何でも方法論と呼べるわけではなく、だいたい次のような条件があります。

まず結論

方法論とは、

ある目的を達成するための方法を、一定の原理・手順・考え方として体系化したもの
です。

なので、

GTD → 方法論と呼んでよい
SBOM → ふつうは方法論というより「成果物・表現形式・管理の枠組み」に近い
繰り返しタスクを軸に個人タスク管理を回す自分なりの整理 → それが体系化されていれば方法論と呼べる

です。

「方法」と「方法論」の違い

ここを分けると分かりやすいです。

方法

個別のやり方です。

毎朝、今日やることを3つ書き出す
タスクを締切順に並べる
毎週金曜にレビューする

これは方法です。

方法論

複数の方法を、ある原理で束ねたものです。

なぜその手順を使うのか
どういう順番で実践するのか
どんな前提で有効なのか
例外や運用ルールをどう扱うのか

まで含めて、ひとまとまりの実践体系になっていると方法論らしくなります。

GTDは方法論か

はい、典型的に方法論です。

GTDには、

頭の中から気になることを収集する
次にとるべき行動に分解する
文脈ごとに整理する
定期的にレビューする
実行の選択基準を持つ

といった、原理・手順・運用ルールがあります。
単なるコツ集ではなく、タスク管理をどう考え、どう回すかの体系になっているので、方法論と呼べます。

SBOMは方法論か

これは少し注意が必要です。

SBOM（Software Bill of Materials）は基本的には、

ソフトウェアを構成する部品・依存関係などを一覧化したもの
です。

つまり中心は「何を記述するか」「どう表現するか」であって、GTDのように 人が何をどう進めるかの手順体系そのものではありません。

そのため、SBOM単体を指しては通常、

方法論
実践手法

というより、

成果物
文書形式
管理対象の一覧
ソフトウェアサプライチェーン管理の一要素
標準化された情報表現の枠組み

と捉えるほうが自然です。

ただし、

SBOMをどう生成するか
いつ更新するか
脆弱性管理とどう結びつけるか
調達・監査プロセスにどう組み込むか

まで含めて体系化したなら、それは
「SBOM活用の方法論」
とは言えます。

つまり、

SBOMそのもの → 方法論ではないことが多い
SBOMを用いた運用の体系 → 方法論になりうる

です。

自分なりに整理したやり方は方法論か

はい、体系性があれば方法論と呼べます。

たとえばあなたが、

個人のタスクには「単発」と「ルーチン」がある
単発タスクは見落としや優先度判断のコストが高い
ルーチンタスク化できるものはルーチン化したほうが認知負荷が下がる
ルーチンは日次・週次・月次で管理する
ルーチン化できない案件だけを都度判断する
毎週レビューして、単発タスクのうち再発するものはルーチン候補として抽出する

のように、

前提
分類
判断基準
手順
見直しルール

まで含めて整理しているなら、それは十分に方法論的です。

逆に、

「繰り返しタスクを使うと便利」
「私はこうしてる」

だけだと、まだ方法論というより経験則・ノウハウ・工夫に近いです。

方法論の射程

「方法論」という語は、日常語ではかなり広く使われます。
だいたい次のような幅があります。

1. 狭い意味

学問や研究でいう methodology に近い意味です。

研究方法論
社会調査の方法論
デザイン方法論

この場合は、

対象をどう捉えるか
どんな手続きを正当とするか
どう検証するか

のような、方法についての理論的反省まで含みます。

2. 広い意味

実務での「やり方の体系」です。

開発方法論
営業方法論
タスク管理方法論
学習方法論

この場合はもっと実践寄りで、 うまく進めるための型・原則・手順のセット くらいの意味で使われます。

どこから「方法論」になるのか

感覚的には、次の要素がそろうと「方法論」と言いやすいです。

方法論らしさのチェックポイント

目的がある
- 何を達成したいのか
原理がある
- なぜそのやり方なのか
手順がある
- どう実践するのか
判断基準がある
- どの場合にどう選ぶのか
反復可能性がある
- 他人や未来の自分でも再現できる
体系性がある
- バラバラのコツでなく、全体としてつながっている

これらが弱いと、

アイデア
テクニック
習慣
ノウハウ
作法

にとどまります。

あなたの例を整理すると

GTD

→ 方法論

SBOM

→ 単体では方法論ではないことが多い
→ むしろ記述対象／標準／成果物／管理フレーム

ルーチンタスク発想を軸にした自分のタスク管理の整理

→ 体系化されていれば方法論
→ まだ断片的なら「考え方」「運用ルール」「ノウハウ」

一言でいうと

方法論の射程は、「単なる個別の手段」より広く、「世界観や学問理論」よりは具体的な、目的達成のための体系化されたやり方全般です。

なのであなたの問いへの答えを一言で言えば、

GTDは方法論。SBOMはそれ自体は方法論というより枠組みや成果物。自分なりに整理したルーチンタスク中心の実践も、体系化されていれば方法論と呼んでよい。

必要なら次に
「方法論・フレームワーク・プロセス・作法・ノウハウ・標準」の違い
も表にして整理できます。

q

以下の DWMY Review も方法論？

DWMY Review

👉️English Version

概要

DWMY Review は個人の、個人による、個人のための振り返りシステムです。

DWMY とは Daily, Weekly, Monthly, Yearly の略です。

考え方

1: 毎日メモを取ります（デイリーノート）
2: 一日一回、デイリーノートを使って振り返りをします（日次レビュー）
3: 週に一回、デイリーノート 7 本をインプットにして振り返りをします（週次レビュー）
4: 月に一回、週次レビュー結果 4-5 本をインプットにして振り返りをします（月次レビュー）
5: 年に一回、月次レビュー結果 12 本をインプットにして振り返りをします（年次レビュー）

このように積み重ねていくことで、現実的なボリュームで振り返りを重ねていくことができます。

もし DWMY がなかったとしたら、週次レビューのときに 7 日分の詳細を思い返したり、月次レビューのときに 30 日分の詳細を調べ直したりする羽目になります。おそらく不可能でしょう。一方、DWMY を心がけていると、週次のときは日次の結果 7 本を見ればいいだけですし、月次のときも週次の結果 4-5 本を見ればいいだけです。現実的に振り返りができるのです。

====

使う手段

以下のいずれかが良いでしょう。

テキストエディタや IDE を使って、プレーンテキストで書く
Cosense、その他軽量でページを自在につくれるウィキやノートで書く
- 🐰生成AIに与えたいならプレーンテキストでコピペできるもの、あるいはエクスポートできるものが良いです。私は Cosense をおすすめしています

何を書くか

Daily

日々のタスク、アイデア、作業メモ、日記など何でも
日次レビューの内容
ファイル名の例: 2025-12-31.md

Weekly

この週が含む日のデイリーノート（へのリンク）
週次レビューの内容
ファイル名の例: 2025-12-w4.md, 2025-12-28-wr.md

Monthly

この月が含む週の、週次レビュー結果へのリンク
月次レビューの内容
ファイル名の例: 2025-12.md, 2025-12-31-mr.md

Yearly

この年が含む月の、月次レビュー結果へのリンク
年次レビューの内容
ファイル名の例: 2025.md, 2025-12-31-yr.md

レビューとして何を行うか

テンプレートをつくった上で、機械的に埋めるようにすると楽に書けます。以下例:

YWT: やったこと、わかったこと、次にやること
KPT: Keep（続けたいこと）、Problem（問題）、Try（次に試すこと）
4Y: やること、やったこと、良かったこと、良くなかったこと

また生成 AI に書いてもらう前提で整えるのもアリです。以下例:

coppai-sta
- これは🐰が使っているプロンプトです（%cb% に内容が入ります）
- 👉️週次レビュー用
- 👉️月次レビュー用

フォーマット

Markdown による例を示します。

🐰ファイルをこまめに分けるか、それとも一ファイルの中で # 見出し記法 で分けるかは好みです。

Daily

内容もリスト形式

# 2025-12-31
- ...

# 2025-12-30
- ...

# ...

内容は自由

🐰リスト形式よりも書きやすいですが、構造化されないため後で読みにくく、生成AI目線でも理解しづらいというデメリットがあります。しかし人次第ですし、プロンプトを工夫すれば吸収は可能なので、最終的には好みになるでしょう。

# 2025-12-31
...

# 2025-12-30
...

# ...

Weekly

日曜日に行う場合

# 2025-12-28
- [2025-12-21](2025-12-21.md)
- [2025-12-22](2025-12-22.md)
- [2025-12-23](2025-12-23.md)
- [2025-12-24](2025-12-24.md)
- [2025-12-25](2025-12-25.md)
- [2025-12-26](2025-12-26.md)
- [2025-12-27](2025-12-27.md)

(ここに振り返り内容を書く)

Monthly

# 2025-12
- [2025-12-07](2025-12-07-wr.md)
- [2025-12-14](2025-12-14-wr.md)
- [2025-12-21](2025-12-21-wr.md)
- [2025-12-28](2025-12-28-wr.md)

(ここに振り返り内容を書く)

Yearly

# 2025
- [2025-01](2025-01.md)
- [2025-02](2025-02.md)
- [2025-03](2025-03.md)
- [2025-04](2025-04.md)
- [2025-05](2025-05.md)
- [2025-06](2025-06.md)
- [2025-07](2025-07.md)
- [2025-08](2025-08.md)
- [2025-09](2025-09.md)
- [2025-10](2025-10.md)
- [2025-11](2025-11.md)
- [2025-12](2025-12.md)

(ここに振り返り内容を書く)

a

はい。DWMY Review は十分に「方法論」と呼べます。
しかもかなり素直な意味での、個人の振り返り方法論です。

なぜ方法論と言えるのか

方法論らしさの要素を当てはめると、かなりきれいに揃っています。

1. 目的がある

目的は明確です。

個人の振り返りを継続可能にする
長期スパンの振り返りを現実的な負荷で行えるようにする
日・週・月・年の粒度をつないで、生活や活動を把握しやすくする

これは単なる記録術ではなく、「どうすれば振り返りを実践できるか」という目的志向の設計です。

2. 原理がある

中心原理もはっきりしています。

詳細な記録は日次で保持する
上位のレビューでは下位のレビュー結果を要約入力として使う
そうすることで、情報量を圧縮しながら振り返りを積み上げる

これは重要で、DWMY Review はただ
「毎日・毎週・毎月レビューしましょう」
と言っているだけではありません。

むしろ本質は、

レビューを階層化し、下位のレビュー結果を上位レビューの材料にすることで、振り返りコストを制御する

という設計思想にあります。

この「なぜそのやり方なのか」があるので、方法論性が強いです。

3. 手順がある

実践手順も明確です。

毎日メモを取る
その日の終わりに日次レビュー
7日分の日次を材料に週次レビュー
4〜5本の週次を材料に月次レビュー
12本の月次を材料に年次レビュー

これは完全に運用手順です。

4. 判断基準・運用ルールがある

さらに、

何を入力にするか
どの単位でまとめるか
どんなテンプレートを使うか
どんな媒体で書くか
ファイル名やリンクをどうするか

まで示されています。

テンプレート部分は多少選択式ですが、それは方法論として普通です。
厳密に一通りに固定されていなくても、中核の構造が保たれているなら方法論です。

5. 再現可能性がある

他人が読んでも試せます。

何を
いつ
どうつなげて
どう蓄積するか

が明文化されているので、再現可能な実践体系になっています。

では、何の方法論なのか

一番自然なのは、

個人振り返りの方法論
個人知的生産のレビュー方法論
多層レビューによる自己記録・自己改善の方法論

あたりです。

より説明的に言うなら、

日次記録を基礎にして、週次・月次・年次へと要約を積み上げる階層型レビュー方法論

です。

これは「単なるフォーマット集」ではない

ここは大事です。

あなたの DWMY Review には、

ファイル名の例
Markdown の例
テンプレート例
ツール例

も含まれていますが、方法論の核はそこではありません。

核は、

デイリーノートを一次情報源にする
日次レビューで一段要約する
週次では日次レビューを材料にする
月次では週次レビューを材料にする
年次では月次レビューを材料にする

という情報圧縮の階層構造です。

つまりこれは単なる文書テンプレートではなく、
振り返りを成立させるための運用設計です。
この点で、かなりはっきり方法論です。

GTDとの比較で言うと

GTDが「タスクを扱う方法論」なら、
DWMY Review は「振り返りを扱う方法論」です。

GTDほど広くはなく、対象領域はより限定的ですが、方法論であること自体は同じです。

GTD: 収集・整理・実行・レビューの方法論
DWMY Review: 記録・要約・階層レビューの方法論

という感じです。

ただし、言い方を細かく分けるなら

より厳密には、次のどれも言えます。

方法論
フレームワーク
システム
運用方式
レビュー手法

この中でどれが一番しっくりくるかは文脈次第です。

方法論

「なぜそうするか」「どう回すか」まで含む言い方。
→ 今回かなり当てはまる

フレームワーク

枠組み・型に注目する言い方。
→ DWMY の D/W/M/Y の階層構造を指すならこれも合う

システム

運用全体を一つの仕組みとして見る言い方。
→ あなた自身が「振り返りシステム」と書いているので自然

手法

個別のやり方として少し軽めに言う表現。
→ これでも間違いではない

なので、

DWMY Review は、個人振り返りのための階層型レビュー方法論であり、同時にレビューシステム／フレームワークでもある

と言うのが一番しっくりきます。

逆に、方法論ではないと言われるケース

もし内容が単に

毎日書く
週末に見返す
月末にも見返す

だけで終わっていたら、まだ「習慣」や「実践アイデア」に近いです。

でも DWMY Review には、

なぜその階層が必要か
上位レビューの入力は何か
負荷をどう下げるか
どう記録を構造化するか

が書かれているので、そこを越えています。

一言で答えると

はい、DWMY Review は方法論です。
特に、

下位レビューを上位レビューの入力にすることで、振り返りを継続可能にする個人向け階層型レビュー方法論

と整理できます。

必要なら次に、
DWMY Review を「方法論」「フレームワーク」「システム」「作法」のどれとして紹介するとよいか
を、README や紹介文向けに言い換え案として出せます。

This site is open source. Improve this page.