学習サイクルについての自分の仮説立てと実践結果

何かを実現していく際、人はどうやって実現するための知識をつけるのか?再現性のない問題についてどう取り組むべきかについて、最近読んだ本や自分の考えを元にまとめていく。

学習サイクルとは

自分の考えていた学習サイクルについて、ちょうど直近読んだ継続デリバリーのソフトウェア工学に良いものが書かれていた。

私たちの大半が学校で習った科学的手法は、Wikipedia(英語版)では次のように説明されています。
●特徴づけ:現在の状態を観察する
●仮説の定立:観察したものごとを説明する理論、記述を生み出す
●予測:仮説に基づいて起きることを予測する
●実験:予測を検証する

David Farley. 継続的デリバリーのソフトウェア工学 もっと早く、もっと良いソフトウェアを作るための秘訣 (Japanese Edition) (p.25). Kindle 版.

具体例として本書ではTDDを例に以下のように示していた。

●問題について考え、その特徴を明らかにする:「自分のシステムに望むふるまいを考え、それをテストケースという形にまとめる」
●仮説を立てる:「私のテストは失敗するはずだ」
●予測を立てる:「テストが失敗したら、このようなエラーメッセージが表示される」
●実験を遂行する:「テストを実行する」

David Farley. 継続的デリバリーのソフトウェア工学 もっと早く、もっと良いソフトウェアを作るための秘訣 (Japanese Edition) (p.189). Kindle 版.

これを踏まえて自分が考えていることをまとめると、

  1. 取り組むべき問題を決める

  2. 特徴づける

  3. 仮説/予測を立てる

  4. 実験を遂行する

  5. 振り返り

  6. サイクルの見直し

よくあるPDCAサイクルと同じようなことを考えているが、若干拡張されていることに注意が必要。

関係性を図にすると以下のようになる

一応ここで断っておくと、実験を遂行するの部分に関して、結果次第にリスクがあり不可逆なもの(人が死ぬ・財産を失う)で扱うことは想定していない。

この説明のために、自分が取り組んだ中で一番よくあるであろう問題のダイエットという問題を踏まえて説明する。

取り組むべき問題を切り分ける

まずこれについてだが、最初は問題の解像度も荒い。
何らか決めて取り組む。例えば「体重を減らす」という部分に絞る。
ここでは、計測可能な問題に絞ることで振り返りの精度が上がるので何らか数字目標にするのが良い。

このステップは最初のサイクルでは圧倒的勘だけでやるのがおすすめ。最初はドメイン知識がないため、あまり情報収集しても迷子になってしまうため、まずは圧倒的勘だけでやるのを勧める。

2週目以降はここと後述の特徴づけは他人の知識を使っていくのを勧める。

特徴づける

自身の体重は、自分の体の入出力だけで捉えられるはず。

  • In: 食べ物、飲み物、…

  • Out: 消費カロリー、汗、…

ここでは、自分が痩せるためには、消費カロリーを増やせば良いと捉える。

仮説を立てる

ある程度下調べをして、少なくとも過去の実験から絶対に間違っているとは言えないもので仮説を立てる。例えば「痩せるためにはラーメンを毎日3食食べれば良い」など過去の例からわかるようなものはここで棄却する。
調べても分からなければ実験してみる(実験コストと天秤にかける必要があるが)。

ダイエットについては、ランニングをすることで痩せるだろうと仮説を立てる。

実験を遂行する

仮説に合わせて実験をする。まずはやると決めたらやるのが必要。

ダイエットについては、2,3日おきに8-10km走るようにした。これを1ヶ月程度続ける。Apple Watch曰く、1回のランニングで500kcal程度消費していたので、消費カロリーを増やすは実践できている。

振り返り

ここでは次の仮説に向けて結果の分析と、期待する結果が出なければ、その原因を探る。うまくいったらより効果を高めるように原因を探る。
また予想外の結果が出れば、それに注視する(ここが実験の意義だと思っている)。

そして、なんらか言葉にすることで、事象がより正確に見えてくるので意図的に言葉にし、不必要なものを忘れる。後日その言葉を見て、余計なものを落としていく。
(このあたりの考え方は思考の生理学を参考にしている)

倉庫型の頭をつくるのならともかく、ものを考える頭を育てようとするならば、忘れることも勉強のうちだ。

外山滋比古. 思考の整理学 (Japanese Edition) (p.119). Kindle 版.

また、実験の最中はどうしても深く考えることがし辛いため、ゆっくり落ち着く時間を設けるか、実験後にこれを行うと良いと思っている。
このあたりはこの本に書いてある。

実際、ランニングの結果に関しては

  1. 足を痛めた

  2. 安静時心拍数が下がった

  3. 体重は下がらなかった

予想外だったこと

  • 鏡を見た時の自分はランニング前より良いように見える

  • 運動することで安静時心拍数が下がり(おそらく)基礎代謝が落ちた

  • 体重は下がらなかった

  • 足を痛めた

体重が減らなかった原因の可能性が高いものは

  • 落ちた脂肪と付いた筋肉の重さが一定だった

  • 1日の消費カロリーが一定になるようにできている

落ちた脂肪と付いた筋肉の重さが一定だった。これはあり得そう。ランニングするたびに筋肉痛にもなっていたので。
1日の消費カロリーは一定になるようにできている。これは 現代ならともかく、昔の人にとってはエネルギーは貴重なはず。そういう仕組になっていても不思議ではない。

摂取カロリーを減らす・体脂肪率を追うほうが筋が良いかもしれないと仮説を立てる。

サイクルの見直し

まず、実験した事実を整理し、以下の点を着目する

  • 実験のための指標は十分か

  • 見えていない変数があるとするとどこか

    • 直接管理できる変数

      • 例: 食事量

    • 直接管理できない変数

      • 例: 季節

  • 問題のスコープが広すぎないか・狭すぎないか

    • 広すぎる例: 企業価値を最大化させるために株価のみに注目する

    • 狭すぎる例: 締まった体を実現するために消費カロリーのみに注目する

ダイエットについては

  • 実験のための指標は十分か: 体重のみを追っており体脂肪率などは追っていなかった

  • 見えていない変数があるとするとどこか: 基礎代謝、怪我

  • 問題のスコープが広すぎないか・狭すぎないか: 狭かった。目的は締まった体なので、体脂肪率を追うべきだった

自分の要求は「締まった体」だったため、取り組む問題をそちらに置き換え、追うべき指標を体脂肪率に、手法を摂取カロリーに再設定し再度サイクルを回す。

学習サイクルの評価

学習サイクル自体の改善も学習サイクルで回すべきで、この手法をいくつか横展開して試してみるべきである。なのでダイエット以外にも、プライベートや仕事でこの半年くらいいくつかのことを行った。以下はこの事例を紹介する。

結論を書くと思ったよりもうまく行った。しかし1サイクルを回すに当たってのコストが高いものに関しては当てはまらない。

  1. ダイエット

  2. 禁煙

  3. テトリス

  4. フロントエンド入門

  5. プロダクト開発

ダイエット

学習サイクルの評価: うまく行った

摂取カロリーを減らす & 運動をするを持続することで達成。体重計でいろんな情報が取れるものを買うことで結果へのセンサーがうまく働くようになった。
また、習慣づけて動くためにゴールを適切に設定することが重要。今回だと高校時代の写真を目標にすることでうまく働いた。

ちなみに、オムロンの体重計はCSVでもデータが落とせるので、分析にはもってこい。

禁煙

学習サイクルの評価: うまくハマらなかった

僕は喫煙者であるが、3ヶ月の禁煙に成功したが、再度復活してしまった。
原因ニコチンの依存性が高いため、挑戦すると仕事や生活に影響が出たため学習サイクルを回すコストが高かった。

また、禁煙の結果体重の増加が発生し、ダイエットとコンフリクトしたため中断。
他にはメンタル的な強さや、他人の力を借りるなどの必要がある。

テトリス

学習サイクルの評価: うまく行った

目標として、ぷよテト2(Switch)で勝つことだったが、テトリスを改善するために最初、「手を早く動かせるようにする」という問題に落としていた(=> テトリスの40ラインにずっと取り組んでいた)が、今の自分に必要なのは「どう組むか」が重要だったことに気づき、YouTube動画を見つつ

  • 他人の組み方を予想する -> はずしたらなぜかを考える(あめみやたいようさんは、よく考えていることを話してくれるので参考になる)

  • 他人の組み方を実践する

あたりをやることである程度テトリスの順位は上がった。
また、リプレイ機能を使うことで、ゆっくりと自分や他人のプレイをみることができる。

自分が直接管理できない変数として、オンラインにいる人の能力の分布がある。GW中は相手も強く勝ちずらかったがGW後は勝てるようになる、など。

また、CPUとの対戦を繰り返すことで順位を下げず試すということで1サイクルを回すコストを減らすことができた(かわりにCPU相手にオーバーフィーっとしてしまうこともあるが)

フロントエンド入門

学習サイクルの評価: うまく行った

これはやりたいとかではなく、ChatGPTを利用することで学習の初期コストを減らすことができるのでは?という仮説を実験するために行った。
結論、今まで僕の感じていたググりづらいモノ(例: デバックでReactでstateが変化するたびconsole.log("OK")を吐きたい、吹き出しの尖った部分をCSSでどう表現するか)がChatGPTに聞けるようになり、学習速度が上がった。

あと、別の気づきとしては、フロントエンドは状態を変えうる操作が多く、その点に関して認知コストが高い(バックエンドであればエンドポイントにリクエストが来る・バッチジョブが走る、以上)と感じた。例えばユーザーがホバーした時、このページから遷移してきた時、など。
ほかはほとんどバックエンドの考え方が使えるのでは?と現状は思っている。

プロダクト改善施策の振り返り

学習サイクルの評価: うまく行った

どういった施策がユーザーにどういう影響を及ぼすかを見るために、そのために施策の記録を管理するようにしてみた。結果期待していたより深い洞察が得られ、施策効果が上がっている。

しかし、変数が多いため、そこを一つずつ理解していく必要がある。 

まとめ

結局のところサイクル自体を見直し続けることは重要で、なぜその問題に取り組むか、どう問題を絞るかは適宜改善することで重要なものになっていく。
適切に絞った問題を解くことでサイクルは小さく回しやすくなる(例: 体重を測る、テトリスのCPU、コンパイル時のチェック、TDD)、それにより学習速度は大きく上がる。逆に適切でないサイクルを導入してしまう(例: テトリス40ラインの速度)と、目標にたどり着くまでに時間がかかってしまう。

もちろん世の中に情報がたくさんあるので、それを収集することも必要だが、それを実践することで、自分の知らない部分を見つけていく姿勢が必要だと思っている。

この記事が気に入ったらサポートをしてみませんか?