はじめに
最近、小川メソッドに触れる機会があり、その中で印象に残った考え方がありました。
まずは30%を目指す
最初は、
「30%でいいの？」
と思いました。
しかし、自分の仕事や学習を振り返ってみると、実はこれまで成果が出た場面はすべて同じパターンだったことに気付きました。
今回はその気付きをまとめたいと思います。
100%理解してから動こうとしていた
私は昔から、
「理解してから行動する」
タイプでした。
例えば、
- 新しい技術を学ぶとき
- 各種設計作成を行うとき
- CTFに取り組むとき
- バグバウンティを始めるとき
どれも、
まだ理解が足りない
と思ってしまい、なかなか最初の一歩を踏み出せませんでした。
しかし現実を振り返ると、100%理解できてから始めたものはほとんどありません。
設計作成でも同じだった
実際に設計を作っているときも
最初から、
- 現行システム
- 業務要件
- 運用要件
- 移行方針
を完全に理解することはできませんでした。
実際には、
30%理解する
↓
仮説を立てる
↓
顧客に確認する
↓
理解が深まる
↓
再度仮説を立てる
というサイクルを繰り返していました。
今思えば、
「理解したから進めた」
のではなく、
「進めたから理解できた」
のだと思います。
バグバウンティでも同じだった
バグバウンティも同様です。
対象サービスの仕様を最初から完璧に理解することはできません。
まずは触ってみる。
リクエストを見てみる。
怪しい挙動がないか確認する。
そうやって調査を進めていく中で理解が深まります。
私がGraphQL関連の脆弱性を報告した際も、
最初から全体仕様を把握していたわけではありません。
むしろ、
この情報は本当に見えてよいのだろうか？
という小さな違和感から調査が始まりました。
CTFも同じだった
CTFでも、
問題を見た瞬間に解法が分かることはほとんどありません。
まずは、
- ポートスキャン
- ディレクトリ列挙
- 情報収集
を行います。
つまり、
30%理解する
↓
手を動かす
↓
新しい情報が見つかる
↓
理解が深まる
という流れです。
完璧な理解を待っていては何も進みません。
記事執筆も同じだった
最近はセキュリティ関連の記事を書くようになりました。
しかし、
100%理解してから記事を書こう
と考えてしまうと、なかなか公開できません。
実際には、
30%理解する
↓
記事を書く
↓
不足部分を調べる
↓
理解が深まる
という流れの方が学習効果も高いと感じています。
今回のサプライチェーン攻撃「Miasma」の記事も、記事としてまとめる過程で理解が整理されました。
アウトプットは理解の結果ではなく、理解を深めるための手段でもあると感じています。
「理解してから動く」ではなく「動きながら理解する」
以前の私は、
理解
↓
行動
だと思っていました。
しかし実際は、
理解
↓
行動
↓
理解
↓
行動
↓
理解
というループで成長しているように感じます。
だからこそ、
まず30%を目指す
という考え方に共感しました。
おわりに
各種設計作成、CTF、バグバウンティ、記事執筆。
一見すると全く別の活動に見えます。
しかし振り返ってみると、どれも共通していました。
それは、
完璧な理解を待たずに、仮説を持って前へ進むこと
です。
最近は、
「まだ理解が足りない」
と思ったときほど、
「まずは30%を目指してみよう」
と考えるようになりました。
結果として、その方が早く深く理解できること感じています。