Goal

勉強の仕方が雑になってきたので、ちょっと振り返る
自分の勉強の仕方を整理・再構築する

(既にして良くない目標になっている)

Dev-Environment

紙とペン

Wait a minute

最近、勉強の仕方が雑になってきた。
方向性とかも無秩序にやりたいことをやっているし、しっかりと定まっていない。
例え趣味の領域だったとしても、ちょっとこれはいかんという状態です。

そのため、今まで学んだことを取り入れつつ自分の勉強方法を整理し再構築しようと思います。
回り道になってしまうが、このまま無軌道に進んでいくよりかはましでしょう。

皆さんやっていることを私もやっているだけですが…目標を基準としたゴール指向的な勉強に立ち返ります。

Index

Overview

最近の自分の勉強を振返ってみるとします。
自分の恥を晒している気がするが、気にしない方向で…

最近のやり方(Elixirのプログラムやるとき)

Elixirの記事やライブラリなど情報を収集する
面白そうなものをピックアップする
自分でもできそうなものを選択する
何をやるか決める
どうなっていればいいのか目標を決める
何も考えずプログラムする
振返りをするため、アウトプットするためブログ用の記事を書く
ブログにアップする
1に戻るもしくは、できなかった場合は5.に戻る

※ 但し途中で興味が移っていることがある(一度に一つが理想なのにタスク割り込みをかけている。しかも自分で…)

方向性も分析もくそもない…ただやりたいからやっただけ…
たまにはそれもいいんだが、常にこれだと成長があまりできない。

それに見積もりも抜けている…
定量的かつ分析ができるように計測、測定ができないとコントロールもハンドリングもない。

ダラダラと勉強をしているのと変わらない状況ですね。
1万時間の練習に関して以下のようなことが言われている。

なお、1万時間行う必要のある努力は「deliberate practice(真摯な練習)」と呼ばれる訓練であって、
単にダラダラとおざなりな練習ではダメということには注意が必要です。

出典: 1万時間の練習で一流になれる「1万時間ルール」は万能でないという見解が登場

練習時間と練習の質を、きちんと区別できていないのです。

出典: スキル習得には1万時間もかからない？もっと効率的に訓練する方法

漫然と好きなように学び、球を打って走り、鉛筆
を走らせ、歌い奏で、踊るような一万時間は楽しい趣味にすぎない。
方向性を持ち、自己の分析を伴う、集中した一万時間の鍛錬だけが
専門性を成立させると言われているが、誰でもやっていることだ。
さらに時代に合わなければ、才能と積み上げも
検討はずれとなる。それほど無情な世界だ。
ギギナ・ジャーディ・ドルク・メレイオス・アシュレイ・ブフ（されど罪人は龍と踊る）

出典: 自動化のその前に by hayabusa333

質が悪い練習の状態　= くそみたいな勉強法を実施している
これでは達人になるのなんて夢の又夢…
(私がそこまでなる必要があるのかはともかく、どうせやるならなりたい)

というわけで、一旦基礎的な部分に立ち返ろうかと思います。

GOAL-IP

何をどうすればいいのか、どこに行けばいいのか明確にするために書く。
ネーミングセンスについては自分でも微妙なの知っているので、突っ込まんでください…
語呂を少し合わせましたが、割と自然に出てきました。

GOALの部分は実施する・した内容。
以下の四つで構成されている。

Goal: 目的(振返りできるように定量的かつ具体的なもの。見積もりもここに入る)
Outcome: 成果(実施した結果出てきたことと達成度。事実が欲しい、自分の気持ちなど不要)
Analyze: 分析(できなかったことの原因・要員・ギャップなど。できたことはさらに改善できることなど)
Learn: 学び(実施して学んだこと、気付いたこと、自分の気持ちとかも書いていいよ？)

IPの部分は次のために行うこと。
以下の二つで構成されている。

Improve: 改善(改善するための内容、次のプランにおける具体的な行動を書く)
Prepare: 準備(改善するために必要な次の準備を書く)

全体に言えることは、分析できる内容であることと、具体的な内容を書くこと。

G: Goal

目標・目的とする具体的な内容を書く部分です。
そして、その目標・目的に到達するための計画、方針なども書いていきます。
見積もりもここに入ります。

多少長くなってしまってもいいので、
目標・目的は具体的でかつ定量的に分析できることが望ましいです。
具体的な数値を使うと分かりやすくなる。

目標・目的に関しては、今日中に実施可能、到達可能な内容を書く…これ大事。
できないこと書いても仕方がない。できないことは見通しが立てられない。

例えば、「今日中にゲーデル、エッシャー、バッハ―あるいは不思議の環を読破し理解する」…ヾﾉ・∀・｀)ﾑﾘﾑﾘ

また、他の人から見て理解され納得される内容だと、他者からのフィードバックが得やすいですね。
一つの視点として意識すると良い目標・目的が書けると思います。

悪い例)

今日中にElixirの文法を覚える
ElixirのMailmanライブラリを使ってメールを作成し送信する

最近の目標ですね(笑)
上記の悪い例を元に改善した目標。

良い例)

30mでElixirの文法の基本的な型(整数、少数、文字列)を学習する
- 10mでElixir Schoolにある基本的な型を学習し、書き方を見なくてもプログラムできるようにする
- 20mでブログの記事としてまとめアップする(振返りができる状態を作る)
4hでElixirのMailmanライブラリを使い、自分のGmailアカウントでテストメールが受信できている
- 30mでMailmanライブラリのREADMEを翻訳する
- 1hでMailmanライブラリのExampleを実行する
- 30mでテストメールを送信し、MailCatcher(Ruby)で受信を確認する
- 1hでテストメールを送信し、Gmailから受信を確認する
- 1hで実施した内容を振返り、ブログの記事としてまとめる(今後のための振り返り)

これが良い例なのかはともかくこれでかなり具体的になったかと。

といっても、ある程度メタな部分や曖昧な部分があってよいと思います。
厳格に進めることが目的ではありませんから。
重要なのは、「いつまでに誰が何をやってどうなっていればいいのか」でしょうから。
目標・目的は行動するための指針を決めるためのものです。
目標・目的はあくまで効率的に進めるためのツールにすぎません。

O: Outcome

実際に実行してみて出てきた成果に関して書く部分です。
隠し立てはいりません。出てきた事実を書けばいいのです。
(ここに気持ちなど不要！)

何をやろうとして、どうなったのかの現状、できあがった成果物、もしくは完了・未完了のタスクを書く。
達成度を書くのもこの項目でおこなう。

例)

完了したタスク、未完了のタスク

[] 4hでElixirのMailmanライブラリを使い、自分のGmailアカウントでテストメールが受信できている
- [x] 30mでMailmanライブラリのREADMEを翻訳する
- [x] hでMailmanライブラリのExampleを実行する
- [x] 30mでテストメールを送信し、MailCatcher(Ruby)で受信を確認する
- [] 1hでテストメールを送信し、Gmailから受信を確認する
- [] 1hで実施した内容を振返り、ブログの記事としてまとめる(今後のための振り返り)

現状

テストメールを送信したが、Gmailまで届いていない
WireSharkでパケットの分析を行ったが、Gmailへtls接続する部分で失敗している
振返りのブログ記事は未着手
達成度:60%

達成度が60%の理由。Goalのときに5つのタスクに分割している。
その内、3つのタスクが消化されているため。
かなりざっくりですが、詳しい内容書いていくと短くまとまらない…
そして、時間も考慮にいれていない…この人はたして何時間掛かったんでしょうね(笑)

重要なのは、何が終わって何が終わってないのか分かればいいかと。

A: Analyze

成果に対しての分析結果を書く部分。
できなかったことの原因・要員・ギャップなど。できたことはさらに改善できることなど。
(メトリクス分析なんかはここに入れる…予定)

例)

できたことについて

テストメールの送信で設定方法を調べるのに1h掛かった(見積もり+30m)
- Exampleの部分に設定の記載はあったが、詳しい内容について記載されている部分がどこにあるのか探すのに時間が掛かった
- Mailmanライブラリで利用しているライブラリのソースコードに記載があったので、次からはソースコードも意識する

できなかったことについて

tlsやsmtpについての知識が足りないため、失敗した原因が何故なのか分かっていない
- opensslを使って送信したメールは受信できていた
- telnetでは、Gmailへ送信できなかった(STARTTLSで通信が終わってしまう)

OutcomeとAnalyzeの境界に曖昧な部分があるかと思います。
そこら辺はあまり気にせず書いていきましょう。
出てきた成果の内容を何故何故と分析することと覚えておけばいいです。
先に進んで迷うくらいならもう一度サイクルを回して改善すればいいんです。

L: Learn

実際に実行してみて学んだこと、気付いたことを書く部分です。(自分の気持ちとかも書いていいよ？)
やった後とやる前での自分の中で変わったことを書くと言い換えてもいいかもしれない。
そのため、目標・目的として書いてないことでも気づいたことがあれば書いても構いません。

例)

Mailmanライブラリからテストメールを送る方法が分かった(ローカル限定)
MailCatcher(Ruby)と言うものの存在を知った。また、使い方が分かった。すごく便利！

I: Improve

分析結果から抽出できる課題をどうやったら改善できるのか、そして次のプランにおける具体的な行動を書く部分。

例)

ライブラリの仕様を調べるとき、まずソースコードのドキュメントを参照する
STARTTLSとは何なのか？インターネットを使いリサーチする。それでも分からなければチームメンバーに聞く。
STARTTLSとGmailの関係は何なのかを調査し、STARTTLSでGmailへの接続をできるようにする
過去にドキュメントがないかリサーチする

P: Prepare

改善するための行動に必要な準備を書く部分。

あらかじめ、できる準備を行い、
「～がないからできない」などの言いわけを起こさせないようにするため、
この項目に行っておくことを書いておく。

例)

今日の現状をチームへ共有する(同症例がないか聞いてみる)
TLSについて本をパソコンと一緒に置いておく

Note:

What is ティッピング・ポイント?
ティッピング・ポイントとは、行動を起こさない言いわけ、あるいはやる・やらないの分かれ目となる小さな違いのこと。

簡単に言ってしまえば、あらかじめ準備をしておいて言いわけさせないようにする。

Speaking to oneself

こんな感じに進めて使っていくもの。
毎日のことなので、ぶっちゃけ格式ばったフォーマットはいりません。
また、大きな振り返りはまた別にやりますので、
次の日まで残っていて、次の行動が取れればいいだけのものです。

後半息切れしてしまった。
まだ荒が目立ちますが、サイクルを回していく内に改善していきます。
今日の2hほどで作った内容としてはまずまずのできじゃないかと。

メトリクス分析やゲーミフィケーションと結びつけられるといいんだが…
そこら辺は学習が足りないのでまだ無理ですね。
そしたら2hで終わることはなかったですが(笑)

かなり基礎的な部分になりますので、まずここから悪習を直します。

Bibliography

1万時間の練習で一流になれる「1万時間ルール」は万能でないという見解が登場
スキル習得には1万時間もかからない？もっと効率的に訓練する方法
自動化のその前に by hayabusa333

Code of Resistance!!

ページ

2016年2月16日

学習サイクルの整理と再構築