はじめまして、nwiizoです。

数年前、Rustを3カ月で習得すると決めた。毎日1時間、公式ドキュメントを読む。完璧な計画だと思っていた。計画を立てた自分を褒めてあげたい。

……が、実行した自分は、2週間で途切れた。仕事が忙しくなり、「今日だけは」が「今週だけは」になり、気付けば1カ月が過ぎていた。また自分を責めた。意志が弱いのだと思った。

ただ最近になって、少しだけ違う考え方ができるようになった。続かなかったのは、意志が弱いからではなかったのかもしれない。仮説が間違っていただけなのかもしれない、と。

そこでこの記事では、継続について考えてみたい。4冊の本から学んだことと、僕自身の経験を交えながら。

正直なところ、答えはまだ模索中だ。でも、問いの立て方が変わった。それだけでも、前より少し楽になった気がする。

株式会社スリーシェイク
ソフトウェアエンジニア
nwiizo（@nwiizo）

インフラエンジニアとしてホスティングサービスの開発、運用を経て、現在は株式会社スリーシェイクにてソフトウェアエンジニアとして勤務。Webシステムの歴史、運用、開発について興味があり、SREのような信頼性の観点からのプラクティスや運用技術をプロダクトに落とし込めるように日夜開発を行っている

「どれだけやったか」より「やったかどうか」

まず、厳しい現実を見てみよう。

『200万人の「挫折」と「成功」のデータからわかった 継続する技術』（Discover 21）という本がある。著者の戸田大介さんは、200万ダウンロードを超える習慣化アプリ『継続する技術』の開発者だ。彼自身も「筋金入りの三日坊主」だったという。

本書で紹介されているデータは衝撃的だ。習慣化アプリのユーザーデータを分析した結果、1日で約50%が挫折、2週間後には約90%が挫折、30日後には93.9%が挫折していたそうだ。ほとんどの人が続かない。これが現実だ。

『継続する技術』（Discover 21）　著：戸田大介 d21.co.jp

では、続けられる人は何が違うのか。書籍『継続する技術』では、継続の3原則として以下が挙げられている。

データによると、この3原則を守った人は継続成功率が8.23倍になる。

中でも「すごく目標を下げる」は、特に効果が大きいそうだ。60分以上の目標では94.3%が失敗したが、5分の短いセッションなら続くといったデータが示されている。また、1日でもサボると92.5%が挫折するというデータもあり、「例外を設けない」ことの根拠になっている。

僕自身の経験を振り返ると、3原則の中で最も効いたのは「例外を設けない」だった。「毎日30分」に目標を下げても、「今日だけは」を許した瞬間に崩れたからだ。

逆に、どれだけ疲れていても5分だけ手を動かすと、翌日も続いた。「やったかどうか」のバイナリが、僕には合っていた。

目標ではなく、仮説として未来を設計する

「継続の3原則」の重要性は分かった。しかし、これだけでは目標を立てて満足してしまう。

「今年こそ●●する」と決めた元日の夜、もう達成した気分になっている。目標を立てることが目標だったのかもしれない。だとしたら、毎年達成している。

これを防ぐために、僕は目標を「仮説」として扱っている。この考え方は、失敗学の創始者・畑村 洋太郎さん（東京大学名誉教授）の書籍『新 失敗学 正解をつくる技術』（講談社）から学んだ。

『新 失敗学 正解をつくる技術』（講談社）　著：畑村 洋太郎 kodansha.co.jp

同書で畑村さんは「正解がない時代」の思考法を説いている。といっても厳密には「正解がない」ではなく、「正解がいくつもある時代」だ。決められた正解を素早く出すことが優秀とされた時代は終わった。自分たちで正解をつくっていく必要がある。

では、どうやって正解をつくるのか。畑村さんの答えはシンプル。「仮説⇒実行⇒検証⇒仮説（修正版）」のサイクルを回すことだ。

このサイクルの中では失敗がつきものだが、失敗学の本質は「失敗に学び同じ失敗を繰り返さないこと、そして失敗を創造につなげること」にある。失敗は避けるべきものではなく、正解創出プロセスの必須要素なのだ。

仮説を立てる際には「手法」も含めることがポイントになる。「毎日1時間勉強する」は目標だが、「毎日1時間公式ドキュメントを読んで手を動かせば、3カ月で●●ができるようになる」は仮説だ。

この考え方を取り入れてから、「続かなかった」という自己嫌悪が減った。

達成できなくとも、仮説が間違っていたという情報が得られる。続かなかったのは意志が弱いからではなく、仮説が間違っていただけだ。時間が足りなかったのか、手法が合わなかったのか。情報が得られたら、仮説を修正すればいい。

もちろん、言葉を変えただけで現実は変わらない。続かないものは続かない。

でも、続かなかった自分への態度は変わる。「失敗した」と「仮説が間違っていた」では、次の一歩の踏み出しやすさが違う。少なくとも、僕はそうだった。

仮説を検証可能にするための三つの条件

仮説を立てるだけでは意味がない。検証できなければ、修正もできない。仮説を検証可能にするには、三つのポイントがある。

【1】測れる形にする

測れるかどうか。これが最も重要だ。「Rustを習得する」では検証ができない。習得とは何か？ どのレベルまでか？ 曖昧すぎる。

「Rustで簡単なCLIツールを1つ作って、GitHubに公開する」という形なら、検証できる。作れたか、作れなかったか。公開したか、しなかったか。明確だ。

ただし、何も「全てを測れ」という意味ではない。後述する「創発」のように、測れないが価値のあるものもある。大事なのは、測れるマイルストーンを積み重ねながら、数字では測れない成長を待つことだ。

【2】期限を決める

期限を決めることで、「このペースで間に合うか？」という問いが生まれる。間に合わないと分かったら、方法を変える。期限がなければ、方法を変える動機がない。

当たり前のことかもしれないが、「いつかできるようになりたい」は仮説ではない。「3カ月後に●●ができるようになる」であれば、仮説だ。3カ月後に検証できる。

【3】小さなマイルストーンに分解する

大きな目標は、小さなマイルストーンに分解した方がいい。「Rustを習得する」という目標を例に考えてみると、以下のような形になる。

大きな目標は、小さなマイルストーンの積み重ねでしか達成できない。なぜなら、マイルストーンが小さいほど検証の頻度が上がるからだ。

検証の頻度が上がると、軌道修正が早くなる。1年後に「ダメだった」と気づくより、1週間後に「この方法は合わない」と気づく方が、ダメージが小さい。

仮説検証を止めないための3ステップ

仮説を立て、検証可能な形にした。次は、実際に検証するための仕組みを作る。

【1】記録する

何をやったか、どれくらいやったか、毎日記録する。Notionでもスプレッドシートでも、手書きのノートでもいい。

記録しないと、「なんとなく続けている気がする」で終わる。「気がする」は検証できない。人間の記憶は、都合の良い方向に編集される。過去の自分は、現在の自分が思うより怠惰だった。

ちなみに僕の場合、ブログは記事数が全てではないと思っている。2023年に37本、2024年に60本、2025年には130本以上と伸ばしてきた。たしかに数字も追ってはいるが、指標の軸足は「言いたいことが丁寧に伝わっているか」という点だ。

これは数字では測れない。しかし、読者からの反応や自分で読み返したときの手応えで、なんとなく分かる。数値目標と質的な手応え、両方を記録することで、継続の実感が得られる。

【2】振り返る

週に一度、月に一度、記録を振り返る。

「目標に対して、進捗はどうか？」
「続かなかった日は、何が原因だったか？」
「このペースで、期限までに達成できそうか？」

振り返らないと、「なんとなく続かなかった」で終わる。原因が分からなければ、同じ失敗を繰り返す。

【3】仮説を修正する

振り返りの結果、仮説が間違っていたと分かったら、修正する。「毎日1時間」が無理だったら「週3日、30分」に変える、朝が無理だったら夜に変える。仮説を変えることは、負けではない。学習だ。

ただし「目的」と「手段」を混同すると、学習ではなく逃避になる。「Rustを習得する」が目的なら、「毎日1時間→週3日30分」は手段の修正だ。しかし、「Rustは難しいからGoにしよう」は目的の放棄であり、別の判断になる。

仮説を変えるとき、自分に問う。「目的は変わっていないか？」この問いに答えられないなら、たぶん逃げている。

検証できても、理解はまだ生まれていない

ここまで、仮説検証のサイクルと、それを支える仕組みについて説明してきた。しかし、継続にはもう一つ大事な視点がある。

マイルストーンを達成しても、「まだ本当に分かっていない気がする」と感じたことはないだろうか。実は、この「分からなさ」には理由がある。

青山学院大学教授で認知科学者の鈴木宏昭さんは、著書『私たちはどう学んでいるのか ー 創発から見る認知の変化』（筑摩書房）において、学習のメカニズムを「創発」という切り口で論じている。

『私たちはどう学んでいるのか — 創発から見る認知の変化』（筑摩書房）　著：鈴木宏昭 chikumashobo.co.jp

長年、教育文脈での認知変化を研究してきた鈴木さんがたどり着いた結論は、「ほとんどの認知的変化は創発である」というものだった。ここで言う「創発」とは、個々の要素が組み合わさることで、単純な足し算では説明できない新しい性質が生まれる現象を指す。

鈴木さん曰く「知識とは他者から情報として与えられるものではなく、学習者が自身の経験や手持ちの知識と結びつけて内側から構成するもの」とのことだ。

Rustを例に説明しよう。

所有権、ライフタイム、トレイト、Result型ーーこれらを個別に学んでも、最初は単なる知識の「点」でしかない。それぞれの概念は理解できる。でも、それだけでは「Rustが書ける」とは言えない。

ところが、ある時点で突然、これらがつながる瞬間が訪れる。

「所有権があるからこそ、このエラーハンドリングが安全にできるのか」
「トレイトとライフタイムを組み合わせると、こういう抽象化ができるのか」

個別の知識が結びついて、新しい理解が生まれる。鈴木さんが言う「創発」とは、まさにこの瞬間のことだ。

マイルストーンを積みながら、地道に創発の時を待つ

「3カ月後にRustの所有権を理解する」というマイルストーンは設定できる。でも「いつ創発が起きるか」は予測できない。人によって違うし、同じ人でも分野によって違う。

鈴木さんの言葉を借りれば、試行錯誤による不安定な学習プロセス（揺らぎ）が、実は長期的な定着につながる。突然の「ひらめき」も、無意識の長期的活動が意識化されたものに過ぎない。

だから、マイルストーンを達成しても「まだ分からない」と感じることがある。それは失敗ではない。創発が起こる前の、正常な状態だ。

僕の場合、Rustの所有権が「腑に落ちた」のは、学び始めて1カ月ほど経った頃だった。

エラーメッセージを読んでいるとき、突然「あ、だからmoveが必要なのか」と気がついた。それまでの数週間は、「分かった気がする」と「やっぱり分からない」を繰り返していた。

あの期間が無駄だったとは思わない。点を打ち続けたから、線になった。鈴木さんの研究によれば、「分からない」と感じている時間こそが創発への準備期間だという。

もちろん、創発が起こる保証はどこにもない。起きなかったらどうするか、正直に言うと僕にも分からない。

ただ、少なくとも「マイルストーンを達成した」という事実は残る。点が線にならなくても、点は増えている。それ自体に価値がないとは、僕には思えない。

では、創発を待つ間、何をすればいいか。答えは単純、小さなマイルストーンを積み重ねることだ。

創発は狙って起こせないが、材料がなければ起きない。所有権を学び、ライフタイムを学び、トレイトを学ぶ。一つ一つは「点」でしかなくても、その点がなければ線は生まれない。

「分からない」と感じながらも手を動かし続けることが、創発への最短ルートだ。

継続の先に創発があり、やがて熟達に変わる

創発は、継続の先にある「熟達」への入り口でもある。

元陸上選手の為末 大さんは著書『熟達論ー人はいつまでも学び、成長できるー』（新潮社）で、熟達への道のりを5つの段階で描いている。為末さんは男子400メートルハードルで世界陸上2度の銅メダルを獲得し、自身の持つ日本記録は今なお破られていない。引退後10年をかけて、自らの経験と各界の達人たちとの対話から、この熟達論を紡ぎ出した。

『熟達論ー人はいつまでも学び、成長できるー』（新潮社）　著：為末 大 shinchosha.co.jp

為末さんが示す熟達の5段階は以下の通りだ。

「質が大事」と「量が大事」
「考えろ」と「考えるな、感じろ」

矛盾するように思える教えが両立するのは、段階によって必要なことが変わるからだという。

「型」の段階では、仮説を立てて検証し、基本を身につけることが重要だ。「仮説⇒実行⇒検証⇒仮説（修正版）」のサイクルは、まさにこの段階で力を発揮する。

しかし「観」から「心」への移行には、分析だけでは足りない。為末さんは「観すぎて、考えすぎちゃう」危険性を指摘している。ある時点で分析を手放し、直感を信じる必要がある。

これは鈴木さんの「創発」と重なる。点が線になる瞬間は、論理ではなく直感でやってくる。

また、為末さんは「型」から始めた選手は伸び止まることが多いとも述べている。最初から正解を求めすぎると、好奇心にまかせた試行錯誤を失ってしまう。行き詰まったとき「遊」に戻れるかどうかが、その先に進めるかの分かれ目になる。

継続の先には、創発があり、熟達がある。マイルストーンを積み重ねて創発を経験し、やがて「心」や「空」の境地に至る。そこに到達したとき、継続は努力ではなくなる。「遊」に帰るのだ。

三日坊主に終わった時は、小さく・形を変えて再開する

どれだけ仕組みを作っても、続かない時はある。

風邪を引く、仕事が忙しくなる、気分が乗らない、Netflixが面白い……。理由は何でもいい。人間は、やらない理由を見つける天才だ。とにかく、途切れる。

冒頭で触れたRust学習も、2週間で途切れた。しかし、あのとき僕は失敗したのではなく「仮説が間違っていた」ことを学んだ。

毎日1時間は無理だった。でも、週3回30分ならどうか。仮説を変えて再開した。今度は続いた。途切れたことは、次の仮説を立てるための情報になった。

続かなかったときに、どう立て直すかも肝心だ。

【1】失敗をデータとして扱う

「また続かなかった、自分はダメだ」と思った瞬間、次の挑戦が遠のく。自己嫌悪は継続の敵だ。でも、「自己嫌悪するな」と言われてもできない。感情は制御できないからだ。

そこで僕は、自己嫌悪に期限を設けている。「今日だけ落ち込む権利」を自分に与えるのだ。

思う存分落ち込む。翌日になったら、「で、次どうする？」と問いかける。感情を否定するのではなく、感情に期限を設ける。これが僕なりの折り合いの付け方だ。

畑村さんの「失敗学」を思い出してほしい。失敗を創造につなげることが、失敗学の本質だ。失敗は避けるべきものではなく、次の仮説を立てるための情報源だと心得よう。

【2】小さく再開する

途切れた後に、いきなり元のペースに戻そうとすると失敗する。

「毎日1時間」が途切れたなら、「今日は5分だけ」から再開する。5分でも「再開した」という事実が残る。その事実が、次の日のモチベーションにつながるはずだ。

【3】形が変わっても継続

毎日やると決めたことを週3にしても、1時間やると決めたことが15分になっても、続けている限りは「継続」だ。

完璧に続けることが目的ではない。ただし「形が変わっても継続」には限度がある。僕の基準は「月に1回以上、その目的について手を動かしているか」だ。

週1が月1になっても、その1回で実際にコードを書いているなら継続。だが、月1が「いつかやる」になったら、それは中断だ。この線引きがないと、「続けているつもり」という自己欺瞞に陥る。

重要なのは、目的地を見失わないことだ。 「毎日1時間やる」というのは、目的地にたどり着くための「仮説（手段）」にすぎない。対して「Rustを習得する」というのは、動かしてはならない「目的」だ。

その目的さえ見失わなければ、「毎日1時間」が「週3回30分」に変わっても、前に進んでいる。

終わりに

この記事を書き終えて、ノートを開いてみた。先週のページには、相変わらず途中で止まった項目が並んでいる。「継続について書く」だけは、完了にチェックを入れられそうだ。

正直に言うと、この記事を書いている間も、「本当にこれで合っているのか」という気持ちは消えなかった。「仮説を変えればいい、仕組みの問題だ」と書きながら、どこかで「でも結局、続かない時は続かないのではないか」と思っていた。

きっと、明日も同じことで悩む。来週も、来月も。仕組みを作っても途切れる時は途切れるし、仮説を変えても上手くいかないことはある。

この記事を書いたからといって、急に継続できる人間になるわけではない。もちろん、読んでも継続できる人間にはならない。それは不可能だ。継続について書くことと、継続できることは、まったく別の能力だ。読むことも同様である。

ただ、少しだけ違うことがある。

「続かなかった」と思った時に、「意志が弱いから」ではなく「仮説が間違っていただけかもしれない」と思えるようになった。それだけでも、前よりマシなのかもしれない。

冒頭で触れたRust学習は、結局、毎日1時間は無理だった。でも、週3回30分なら続いた。

仮説を変えた。それを「負け」だと思っていた頃もあったけれど、今は「学習だ」と思えるようになった。思えるようになった、気がする。

仮説を変え続けている限り、多分、継続している。そういうことにしておこうと思う。

文／nwiizo　編集／今中康達（編集部）

●書籍紹介　『アーキテクチャモダナイゼーション 組織とビジネスの未来を設計する』

何度書き直しても、また遅くなる。
Manning刊『Architecture Modernization』の邦訳版。

本書は、技術・組織・戦略を統合し、システムの価値を最大化する実践ガイドです。
長年運用され中身がブラックボックス化したシステムや、ドキュメントが機能せず改修のたびにリスクが伴う設計。こうした技術的負債は、現代のビジネスにおいて成長を阻む大きな壁となっています。
本書は単なるコードのリファクタリング手法ではなく、ドメイン駆動設計（DDD）やチームトポロジー、ワードレイマッピングといった定評ある手法を組み合わせ、技術・組織・戦略という3つの視点からシステムを現代的な姿へと刷新するための包括的なアプローチを解説します。

■本書の特徴
・技術、組織、戦略の社会技術的整合を追求
アーキテクチャを単なる技術パターンとしてではなく、組織構造やビジネス目標と密接に関連したものとして捉えます。
現代化がもたらす多面的な価値を評価するためのフレームワーク（BVSSH）についても解説します。

●実践で検証された高度な手法の統合
DDD、イベントストーミング、ワードレイマッピング、チームトポロジーなど、個別に語られがちな手法をモダナイゼーションという一つの目的のためにどう組み合わせ、運用すべきかを体系的に学べます。

■読者対象
・現場で深刻な技術的課題やレガシーシステムに直面しているエンジニア
・システム設計や改善の意思決定に関わる開発リーダー、アーキテクト
・ビジネス価値と技術的判断を結びつけて考えたいマネージャー、経営層