今年も無事、Microsoft MVP を受賞することができました。ぱちぱちぱち。
ひとまず、Microsoft系の書籍を書いている限りは、申請を出すつもりなので、引き続きよろしくお願い致します。
「Azure OpenAI Service 入門」のほうも合わせて。
さて学習効果の話
ツイートを失念してしまったのですが、学習効果が複利的に逓増するか？というのが再び流行りました。もともとの図自体はかなり前に流行ったものなので、目新しいことではないのですが、賛同だけではなく、疑問符な方たちが結構いたようなので、学習効果についてちょっと記述しておきます。
誰が云ったか忘れてしまったのですが、「1.01の法則と0.99の法則」というものです。
1.01を365日続けると37倍になり、0.99で努力が減ると0.03になるという話で、最初でてきた当時も「1年間続けたとしても、さすがに37倍にはならんやろ」という結論がでています。まあ、1.01の努力ってのもたとえ話なので、実際に37倍になるかどうかは不明です。
さて、これを数式で表すと、次のように複利的にΠで計算するか、加算ということでΣで表すかという違いになります。
果たして、微々たる努力（1.00のところを1%だけ上げるので、勤務時間8時間であれば、8x60x0.01 = 4.8分/日ということになる）で、じゃあ、1年後に37倍になるか？という話になり、まあそうなんらんやろという結論で、Bの加算程度じゃないだろうか？というツイートが今回散見しました。努力が加算されるという意味ですね。
なにかの作業的なものであれば、たかだか1日のうち5分間というのは大した効果ではありません。単純に自給換算にで言えば、8時間勤務が8時間5分勤務になったというだけなのです。
が、Aのような複利効果を考えるとき、実はベースとなる実力そのものが増大するため、その効果はその時々において確かに複利的になる（常に元金が増えるような状態なので）ものです。たとえ話のように、356日連続で向上するとなるとなにやらうさん臭くなってしまいますが、これが「1か月単位で、ある程度実力が向上する」となると少し話が違ってきます。
たとえば、プログラムのコードを書く作業を生産性とみなし（詳細設計や単体試験まどを含めた、バグのないコードをどのくらいのペースで書けるか？ということを考えてみましょう）たときに、1か月のうちで、1.00の時間ところを0.99の時間で書けるようになったとしましょう。たかだか1か月のうちで1%しかスピードアップはしませんが、これが12か月になると、0.99^12 = 0.886 となり、おおよそ 90%程度になります。つまり、1割位の短縮ができるわけです。
プログラムを書くスピードはそのプロログラム言語の習得率や設計のうまさ、テスト環境の整え方など各人の経験で向上できるところの多い分野です。この「経験」は、Σのように加算ではなく、Πのように累積されることは、いわゆるプログラマ力の個人差が大きいところを見ると明らかでしょう。スタート時点での経験の差（あるいは習得率の差）は、その差のまま続くのではなく、1年間のうちに「経験」として向上するものです。さらに、1か月ごとの累積で考えるならば、1か月単位のスタートで「経験」に対して累積していくと言えるでしょう。スタートとなる土台は、次のスタートの時には土台が上がっていると考えられます。
このあたりは町工場などの職人も同じですね。学習前の土台を常々上げることによって、次のステップが楽になります（段差が小さくなる状態にしておきます）。
ここでは仮に1か月につき1%の向上にしましたが、5%と仮定したときは、当初1.0だった見積もりが0.54程度に住むことになります（0.95^12 = 0.54）。つまり1年たてば、最初の見積もり期間よりも半分の工数でコードができあがる、という予定になります。
実際、プログラミング言語の習得だけではこの向上は見込めませんが、
- フレームワークの使い方の習得
- サンプルコードやテストコードを作ることで、落とし穴を回避する
- あるいは、あらかじめ落とし穴に落ちておく（踏み抜いておく）
- テストコードや不具合対処の勘がさえてくる（経験上）
- プログラミング言語自体の習熟度が上がっている
などの要因もあり、単純な加算ではなく複利的に実力が向上することが見込まれます。
実は、似たところはプロジェクトのスケジューリングにも言えるのです。プロジェクトの当初では未知の部分も多く、プロジェクトで利用するライブラリや環境にも不慣れな状態からスタートします。しかし、プロジェクトが終盤になれば、プロジェクトのメンバーはライブラリや環境にも習熟して、数々の不具合を素早く対処できるようになってきています。
終盤で下手に炎上しているプロジェクトではなければ（実は炎上しているプロジェクトであったとしても、プロジェクトメンバー自身は成長しているのですが）、プロジェクトの最初の力量よりもプロジェクト終了時の力量のほうが上であると考えられます。
つまり、この習熟度の高い状態を疑似的に作り出せば、プロジェクトはより安全に安定期（予測可能という意味で）に入ることができます。
- プロジェクトで使うフレームワークを事前にサンプル等を作って試しておく
- 運用直前でトラブルになりそうなリスク要件をあらかじめ確認しておく
- もともと、習熟度の高いメンバーを入れる（可能であれば）
- プロジェクト途中で「学習」を重視する
という様々な方法が考えられます。
そんな訳で、私的には学習による複利的効果（基礎力をアップするという意味で）を期待して、基礎力のアップに努めたほうがプロジェクトも安定しやすいだろう、ということです。
加筆
これは正しいｗｗｗ
