あおぞらAndroid教室でプログラムをした事無い人にプログラムを教えていると、 教えた事の理解度はまぁだいたい想定通りなのだけれど、 解説を書いて読ませるとこの読解が予想よりもだいぶ下手に思う。
これはプログラムの技術とは違うし、実際理系の他の専門を持つ人に教える場合には特に説明がいる項目とも思えないのだけれど、 そもそも大学行ってない、とか、理系の文章を読んだ事が無い、 という人に教える場合は、技術文書の読み方を教える必要があるんじゃなか、という気がし始めている。
技術文書の読み方にはいろいろ書いてみたし、いろいろな事を教えていく必要があるけれど、 パラグラフリーディングを練習して出来るようになるのは悪くないんじゃないか、という気がしている。 という事でまずはパラグラフリーディングを教えてみよう。
ただし技術文書に特化した内容として、しかも日本語の文書を前提に考える。
まず技術文書は、文書の種類によって書かれ方が結構異なっていて、自分が読む時にもだいぶ毎回違う読み方をしている。 だから特定の手順に則ったハウツー的な読み方というのは、あまり実像に合ってない気がしている。
文書ごとに全然違う読み方をするけれど、ある種の原則みたいなのはあって、むしろその原則に従って読み方を毎回編み出しているような所がある。 この自由度の高さみたいなのが、最初に教える時に実態のあやふやな感じを与えてしまう気がしている。
また、パラグラフリーディングは方法や理屈よりも、反復練習が大切と思っていて、 説明よりも練習とアドバイスによるフィードバックみたいな形がいい気はしている。
パラグラフリーディングでは構造を短時間で把握するのが重要で、 構造を把握するには良くあるパターンを知っておく方が良い。
技術文書には特有のパラグラフ構造があると思うのだけれど、 自分は普段、無意識に適当にそうした前提を使ってしまっていて、具体的にどういう種類があるのか？と聞かれると把握していないので答えられない。
そこでここでは思いついたものをリストアップしていって蓄積してみる。
技術文書にはサンプルコードがあり、これが特徴的なパラグラフ構造を産んでいる。
サンプルコードの前後は、
という順番に構成されている事が多いので、 まずサンプルコードを探して前後のパラグラフの役割を調べる、と進める事でパラグラフの役割をすぐに割り出せる事が多い。
また、この3つで意味的にはひとまとまりで、それが節（または項）においてどういう役割を持っているか、と考えると構造がわかりやすい事が多い。
また、サンプルコードは情報量が多いので、サンプルコードを読解する事で説明の内容もだいたい予想出来る事がある。
リファレンスなどに良くある形式で、あるクラスについてそれのAPIを説明する系統。
とりあえずList入門 - karino2のあおぞらAndroid開発教室などを例に考える。
ページの構造としては、
となる事が多い。 また、オブジェクトの作り方はメソッド呼び出しとは違うので、少し形が異なる。 基本的には、
の２つに分かれた構造になっている事が多い。2に関しては並列になっている事が多いので、いくつかを把握すれば他の内容はかなり予想が効く。
そして個々のAPIの説明は、文章でちゃんと説明があるタイプのもの（例えばkotlinのリファレンスなど）では、
という構成になっていて、2と3が1を補強する形になっている。
プログラムなどでは、新しい概念として、その概念を使わなくても書けるけれど使うと便利になるもの、 というのがいくつかある。
そういうものの説明の形式としては、
的に構成されている事が多い。3の位置は違う場合もあるが、「使わない例ー＞使った例」の流れは比較的多い。
これは便利機能でなくても、「問題のある例ー＞改善の例」という流れが続くのは技術文書では多い。 こういう時は改善の内容を理解出来ていれば間の内容を予想するのは割と簡単。
関数とかクラスの継承などについて、概念を説明する文書に関しては、単なるAPIの説明よりは少し構造を持つ事が多い。 例えば関数入門 - karino2のあおぞらAndroid開発教室を考える。
良くあるのは、以下のような流れ。
関数の場合はまず引数もreturnも無い例が最初にあって、その後引数の説明やreturnのような追加の要素についての説明が続く。
継承 - Kotlin 日本語リファレンスの例だと、 まず一番単純な継承の説明があり、 その後にオーバーライドなどの追加の機能の説明がある。
ただし概念の説明の場合はそれ以外に、
というパターンもある。 これは概念が最初に説明するのが難しい時に良く取られるパターンで、 説明の前にしばらく良く分からない例などが続く。あとの説明を読んで初めて理解出来るたぐいのもので、 前半は説明を読むのに必要な何かを提供するのが目的となる。
例えば クラス - Kotlin 日本語リファレンス などは、 「クラスメンバ」より後は、関連するトピックへのリンク集のような役割を果たしている。 この場合は、クラスというものをマスターするには何を知る必要があるのか？という事をここにまとめておくのがページの目的と思う。
また、それらのリンク先がどういうものかを軽く示す、予告編のような役割も持っている場合がある。 例えば上記ページのコンパニオンオブジェクトについて簡単な解説があった後にリンクがあったりする。
これはKotlinツアーなどはそもそも全体がそういうもの、 という役割がある。 それぞれの機能の予告編とリンクを提供するのが目的で、この手の「予告編的な説明」は、基本的には不十分なものになっている事が多い（十分ならリンク先で説明する必要は無い）。
パラグラフ構造としては、「予告のような説明のパラグラフー＞リンク」となる。
とりあえず以下の文書を題材にやってみた所、全然上手く行かなかった。＞ List入門 - karino2のあおぞらAndroid開発教室
とりあえずパラグラフリーディングとは何かとかご利益とかを概念的な事だけ説明をした。
そして実際にやってみつつ詳細を説明しようと、とりあえず文書の目的から節の目的に進むような予想をさせて行こうとしたが、 節の目的の所で節の内容を予想させる所で詰まった。 節タイトルを抜き出して内容を予想させようとしたけれど、どうやったらいいか分からない、から進まなかった。
自転車に乗るようなものなのでやり方を頭で理解するよりも何回かやらせる方がいいとは思うのだが、 自分がやるのを見せてやらせようとしても全く進まない。
パラグラフを読む所まで行かなかったので、説明も途中で終わっている。
うまく行かなかったのはいくつか理由があると思う。
正直大した内容では無いので読めば一通り知っている事だとは思うのだけれど、最近読んだ訳では無いので内容を覚えている訳では無い。 この位の方が練習としてはいいんじゃないかと思ったのだけれど、 これは最初にやるものとしては難しすぎたのかもしれない。
反省としては、まず中身を読んで内容を良く理解した文書で最初に練習する方が良いと思った。
とりあえず私が予想してみて、それを参考にどうやるかわかった上で自分でもやってみる、みたいなのをやろうとしたのだけれど、 私の予想の精度が高すぎて参考にするのにあまり良くなかった。
この文書を書いたのは自分だし、この分野の知識も十分にあるし、この手の文書を読んだ経験も豊富にあるし、この手の予想をした事もすごくたくさんあるので、 そんな自分が初めて読む前提でこんな予想をまずする、と提示しても、あまりにも実際に初心者がやる予想とかけ離れ過ぎていて、 参考にならない。
今回は最初に最終形を教えて、それをやってみようという形で始めたのだけれど、 その結果として一つ一つ教えている事の重要性が伝わらなかった。
今教えている事はそこでは無い、という事ばかりを気にして、今教えている事のうち覚えておいて欲しい重要なメッセージに意識が向かせられなかった。
最終形を最初に教えるのは無理なので、 パラグラフリーディングに必要な個々の構成要素をもうちょっと個別に教えて練習させた方が良かった気がする。
今回は自分がやっている方法をそのまま教えようとして、 特にあまり学習可能性とかを考えずに伝えてしまったので、 もうちょっと個別の訓練項目に分解して順番に練習させた方が良さそうだ。
今回、自転車に乗れる自分がとりあえず自転車に乗って、さぁ乗ってみて、とやっているような感じと思う。
でもやる側としては「は？そんなのコケちゃうじゃん？どうやったら倒れないの？」という気がして、倒れない方法を知りたがる。 実際乗ったら最初はコケちゃうし、コケたら痛いし。だから「コケちゃうじゃん」という本人の認識は誤解では無く正しい。 そして手本としては倒れる手本は出来ないので、参考にならない。
けれど自転車は倒れないためにどうしたらいいかを理解して練習を始めるものじゃなくて、 とりあえずこいでみてコケて覚えるものなので、 「は？コケたくないんだけど？」と思いながらも諦めてやるしか無いんじゃないか。
前回はどうやったらコケないのか、という質問に答えすぎた気がする。どうせコケるので、いいから乗ってみろ、というのが正しい態度だったんじゃないか。
今回良く無かったのは、反復練習を全然出来なかった事だ。 質問に答えてもキリが無いので、まずは答えを自然言語で述べて、それをひたすら暗唱させる、とかから始めた方が現実的だったと思う。 予想の精度が高すぎるという問題はあるけれど、 最初は仕方ないのでそれを覚えてしまう事から始めるのがいい気がした。
次回は、何か一つ節を読んだ上で、その節の内容を（読んだ後に）予想させる、というのを繰り返しやってみようと思う。 まず読んだ後にやる、という事で、 予想の疑似体験のような事をやらせる。
しかも同じ文章に対する予想を反復練習させることで、 予想するという行為に慣れさせる。
同じ節の予想を繰り返しやってちゃんと覚えるくらい予想の言葉を言えるようになったら、次の節に進んで同じ事をやる、 という感じで、節の予想を反復練習していこう。
以上の失敗の例を元に、最初に訓練すべきは、節の内容の予想、という事にした。 そして文書ごとに良さそうな方法でやる、というような曖昧な形では無くて、 最初には最終形態とは違うけれど練習のためにやる方法、みたいなのを提示してやる方が良いと思う。
という事で、まずはList入門でやり方を固めて、 その後にそれを関数入門に適用してみる、と進めよう。
こんな感じでやってみよう。
自分は適当にやっているので適当にやるのが良かろう、と思ったが、これは学ぶのが難しくなってしまっている。 自分がやってないフォーマルなやり方を作るのは嫌だなぁ、と思っていたが、 初期の頃にやる補助輪のようなものとしての立ち位置として、もうちょっと真面目にどうやって読むべきかを自分なりに考えてみてまとめてみる必要があるかもしれない。
3時間かけて、List入門のパラグラフ構造を推測して確認する、 というのを何周もやって、最後に文書全体の構成をホワイトボードで説明させる、というのをやってみた。
かなり大変だったが、もう何回か同じ事をやれば出来るようになりそうな気はする。
推測は
という構造にほぼ決め打ちして、パラグラフの役割はサンプルコードが連続した時に間のパラグラフがどちらに掛かっているかを確認する、 というだけに絞って、ほぼそれだけを繰り返しやらせた。
この構造で無い物の扱いはまだまだ練習出来てないが、この構造に関してはまぁまぁ練習が積めている。もう少しやればこの構造を見抜く事は出来るようにはなりそう。
これは技術文書の読み方としてはかなり良い始め方なんじゃないか。教えていて手応えは感じた。
そのサンプルコードが、節の中でどういう目的を持って提示されているかを説明させる、というのを繰り返し行った。 最初の一回はほぼ自分が答えを言ってしまっていてそれを繰り返しているだけ、という感じではあるが、 少なくとも上記文書に関してはすべて言えるようにはなった。
新しい文書で同じ事が出来るまではまだもうしばらくかかりそうだが、感覚的には3回くらい別の文書で同じ事をやればかなりいい所までは行くんじゃないか。 これが出来ればかなりゴールは近い。
疑問を持つのにいちいち答えるよりも、まずは何度もやるのが大切だ、と説明した上で、何度か練習させる事は出来た。 全然分かってない状態から練習させる事が出来る何かを用意は出来たと思う。 そしてやはり繰り返しやらせる方が圧倒的に進みが良い。
このやり方なら出来るよになりそうな気はしている。
ホワイトボードの前で説明させるのはかなり覚える必要があって、これは不要かもしれない。 ただ前でやらせる、と言わないと覚えようとしなくて、そうすると画面から意識を離せず視野狭窄を起こしてパラグラフの構造になかなか着目出来ないようなので、 これは練習の段階としては必要なのかもなぁ、と思った。
この辺はもっと良いやり方があるのか、最初の段階では必要な事なのかはまだ良く分からない。 ただ説明させると、説明するには何を覚えないといけないかを真剣に考えるようになるので、より能動的には考えてくれる。
今教えている内容の延長で、他人に教えられてしかも必要な事が身につくような気はしている。 所要時間はやはり10時間程度のトレーニングは必要そう。
自分が10時間教えるのはまぁまぁ大変だなぁ、という思いもあるが、一方でOSPとかでパラグラフリーディング出来るようになるまでにもそのくらい掛かっていた気がするし、そういうものな気はした。
今の所自習出来るような所までは内容が煮詰まってはいないので、今の所は自分が直接教えるしかなさそうだが、 もうちょっと自習出来る形に整備出来たらいいなぁ。
実際にこれまで読んだ文書やこれから読む文書でやれるのは非常に良いと思った。これはあおぞらAndroid教室のメリットだよなぁ。
一応やった事をメモしておこう。
三回目は、前回の内容を復習する、という事から始めてみた。
という事をやってみた所、20分程度で復習出来ていた。 前回3時間くらい掛けて何度も読み直した内容なので思い出すのにそんなに苦労は無いはずだが、やり方としてはかなり良い練習になっているように思う。
復習の内容を元にマインドマップを書いてもらってみた。 割と自分がイメージしていたものと同じような内容になっていて、かなり文章の理解度は上がっているように見える。
初めてこの文章を見た時にこんな感じで読んでこんな感じでマインドマップが書ければかなりレベルが高いと思うが、 現在は同じ文章を何度も自分の解説つきで読んだから出来る感じかな、という気がする。 これを初めての文章で自分の知らない内容に関して出来るか、というのが問われる所だな。
そのあと日付を扱う、Date入門で同じ事をやってもらってみた。 こちらも割とちゃんと読めているように見える。 ただこの文書もすでに以前読んでいる内容で、しかもそんなに難しい事は無いので、 簡単なもので出来てもな〜という感じのように本人は思ってそう。 だけれど練習は出来ているのでいいんじゃないか、と思った。
意外な副作用として、文章の内容について、コミュニケーション出来るようになった。これは嬉しい誤算。 以前は内容を説明してくれ、と言っても、先頭から同じ内容を読み上げるような事しか出来ない感じだった。
だが今は節にある内容の塊について話し合う事が出来て、 何が書いてあるのか、という事を自分が教わる事が出来た。 自分が書いた文章ではあるが随分前に書いたきりでそんなに覚えている訳でも無いけれど、 話し合いだけで内容のほぼ全容を理解出来たので、かなりうまくコミュニケーション出来るようになっている気がする。
まだ自分でまとめていい感じに話すというのは出来ていないが、 こちらから質問して必要なことを聞き出す事は出来るようになったので、 これはかなり良いんじゃないか、と思う。
そうか、こういうのはパラグラフリーディングの練習をすると出来るようになる能力だったのか。 しかも4〜5時間の訓練で出来るようになる事なのね。
そういうのを意図して教えていた訳では無いが嬉しい誤算だ。
もう一人は体調不良で前回休みだったので、前回やった事を少しアレンジしてやってもらっていた。
こちらは記憶力が良すぎて一発で覚えてしまうため、反復練習がやりにくかったが、 それはそれで良いか、と思い進めてみている。 やはり相手によって結構やり方は変わりそうだなぁ、これ。
サンプルコードのうちどこが重要な所なのか？というのを説明させる、というのを追加してみた。 サンプルコードの意図を考える、というのはやらせてみると３つ目くらいからは割と出来るようになってきた。
こちらはもう一回くらいやってみないとどこまで行けそうかは分からない感じだが、やってみよう。
繰り返して練習してもらう、というのは出来るようになった気がする。そして練習を繰り返すと上達もしているように見える。
なんかこの最初のこういう奴ってOSPでも最初の4課くらいはこういう内容だったよなぁ、と思い出す。 練習しづらいが基礎になるんだよな。同じ感じになっているという事は習得出来るって事なのかなぁ、と思う。
現状はサンプルコードを中心としているため、サンプルコード中心じゃない奴はまだ出来ていない。 ただサンプルコードの流れを意識するのは結構出来るようになってきているんじゃないか。
パラグラフの言いたい事の言い換えとかが出来ていないで、本文を丸写しになりがち。 言い換えとかの練習は必要そうだなぁ。大意要約とかだよな。 なんかプログラム全然関係ないんだけど、こういうのは読解力には大きく影響しているように見えるので、 やっぱ練習する必要があるのか。
逆に言えば、
の３つが出来れば、とりあえず使い物にはなるんじゃないか。 あと2〜3回で終わりの予定だが、なんとか終わりまで出来る気がする。