はじめに

最近、小川メソッドに触れる機会があり、その中で印象に残った考え方がありました。

まずは30%を目指す

最初は、

「30%でいいの？」

と思いました。

しかし、自分の仕事や学習を振り返ってみると、実はこれまで成果が出た場面はすべて同じパターンだったことに気付きました。

今回はその気付きをまとめたいと思います。

100%理解してから動こうとしていた

私は昔から、

「理解してから行動する」

タイプでした。

例えば、

新しい技術を学ぶとき
各種設計作成を行うとき
CTFに取り組むとき
バグバウンティを始めるとき

どれも、

まだ理解が足りない

と思ってしまい、なかなか最初の一歩を踏み出せませんでした。

しかし現実を振り返ると、100%理解できてから始めたものはほとんどありません。

設計作成でも同じだった

実際に設計を作っているときも

最初から、

現行システム
業務要件
運用要件
移行方針

を完全に理解することはできませんでした。

実際には、

30%理解する
↓
仮説を立てる
↓
顧客に確認する
↓
理解が深まる
↓
再度仮説を立てる

というサイクルを繰り返していました。

今思えば、

「理解したから進めた」

のではなく、

「進めたから理解できた」

のだと思います。

バグバウンティでも同じだった

バグバウンティも同様です。

対象サービスの仕様を最初から完璧に理解することはできません。

まずは触ってみる。

リクエストを見てみる。

怪しい挙動がないか確認する。

そうやって調査を進めていく中で理解が深まります。

私がGraphQL関連の脆弱性を報告した際も、

最初から全体仕様を把握していたわけではありません。

むしろ、

この情報は本当に見えてよいのだろうか？

という小さな違和感から調査が始まりました。

CTFも同じだった

CTFでも、

問題を見た瞬間に解法が分かることはほとんどありません。

まずは、

ポートスキャン
ディレクトリ列挙
情報収集

を行います。

つまり、

30%理解する
↓
手を動かす
↓
新しい情報が見つかる
↓
理解が深まる

という流れです。

完璧な理解を待っていては何も進みません。

記事執筆も同じだった

最近はセキュリティ関連の記事を書くようになりました。

しかし、

100%理解してから記事を書こう

と考えてしまうと、なかなか公開できません。

実際には、

30%理解する
↓
記事を書く
↓
不足部分を調べる
↓
理解が深まる

という流れの方が学習効果も高いと感じています。

今回のサプライチェーン攻撃「Miasma」の記事も、記事としてまとめる過程で理解が整理されました。

アウトプットは理解の結果ではなく、理解を深めるための手段でもあると感じています。

「理解してから動く」ではなく「動きながら理解する」

以前の私は、

理解
↓
行動

だと思っていました。

しかし実際は、

理解
↓
行動
↓
理解
↓
行動
↓
理解

というループで成長しているように感じます。

だからこそ、

まず30%を目指す

という考え方に共感しました。

おわりに

各種設計作成、CTF、バグバウンティ、記事執筆。

一見すると全く別の活動に見えます。

しかし振り返ってみると、どれも共通していました。

それは、

完璧な理解を待たずに、仮説を持って前へ進むこと

です。

最近は、

「まだ理解が足りない」

と思ったときほど、

「まずは30%を目指してみよう」

と考えるようになりました。

結果として、その方が早く深く理解できること感じています。