あおぞらAndroid教室でツアーとかGetting Startedとかリファレンスを読んでいけるようにする為に、 技術文書の読み方、というのを考えてみたい。
自分はあまり技術文書を何らかの手法に従って読んでいる訳で無く、またそうすべきともあまり思っていない。 好きに読んだらいいと思うし、自分の方法が何か特別優れていて人に伝えるべきだという気もしない。
一方で、大学とかに行ってないプログラム素人に技術文書を読ませると、 速度にも内容の消化具合にも大きく問題があり、そこには読み方の問題があるように見える。 だからプログラムを教える事の一貫として、技術文書の読み方を教える必要はあるようにも見える。
現実問題として明らかに遅さに問題があるので、なんとか出来るならしたい。 ライブラリやフレームワークや言語を学ぶのに技術文書を読む機会は多く、それら特有の特徴もいろいろあるので、 一般的な本の読み方とは違うんじゃないか、とも思う。
論文の読み方とかは良く見る話題だし、本の読み方もいろいろハウツーがあるが、技術文書はそれらと違う所もある（同じ所もある）。 なので技術文書用にハウツーがある方がいいかもしれない。 少なくとも今教えている相手は論文とかを読んだ事は無いし読む事も無い人たちが含まれるが、 別に論文なんて読めなくても技術文書は読めるという事もあるんじゃないか。
何を教えたらいいかが良く分からないので、 とりあえず思う事を適当に書き出して言って、あとで系統だってまとめる事を考える。
文章の一番大きな単位が章で、その下が節、その下に項がある。この辺の用語は見たこと無い人もいるかもしれないので最初に解説しておく。 節はだいたいあるが項は無い本などもある。
webのページなどではページが章で、その中のサブタイトルが節、くらいのパターンが多いかもしれない。
文書の目的が分かっている方がいい。そして自分が読む目的も分かっている方がいい。 ただ教えていて「Kotlinのツアーを読んでください」と言われた時などに、目的が分かるのか？というのはちょっとむずかしい気もする。
自分らが技術文書を見てすぐに目的が分かるのは、技術文書はパターンがあるからだ。 だいたい、以下のようなものはどこにでもある。
プログラマはこれらがどういう物かを知っているので、 初めて見る文書でもそれがこれらのどれで、それはどういう目的はを知っている。
逆に言うとこうした文書がどういうものかをあらかじめ知っておいて、しかもそれらの目的を理解しておくのが必要なのかもしれない。 とりあえずどこかに自分の考えなどを書いておく方がいいのかもしれない。
これらの文書が与えられて、その技術を学ぶ、というのは良くあるプログラマの活動と言える。 だから学ぶパターンを確立しておく方がいいかもしれないし、意識はしてないけれど自分にもある気がする。
読む目的は文書の目的と近い事が多い、というよりもなるべく近いものを読むのだろうけれど、 違う場合もある。 何のために読むのかを意識して、その目的にあった読み方をする方が良い。
この読む目的もある程度は学ぶパターンから来ているので、プログラマは既に知っているから知っているだけで、 新しくプログラマになる人は学ぶなり練習するなりする必要がある事かもしれない。
技術文書は、良く書かれていないものがそれなりにある。 世の中の本などに比べて片手間に書かれている事も多く、 読ませようという情熱を持っていない事も多い。 何を言っているか分からない文書も良くあるし、 価値の無い文書も結構ある。
技術文書は「真面目な文章」の中でトップクラスに出来が悪いと思う。 出来が悪いのは不幸で稀な出来事という訳では無く、 日常的なよくある事として動く必要がある。 感覚的には雨の日よりも日常に近い、信号が赤だったくらいのアンラッキーさ。
出来が悪い文書は、読んでも分からない事があるし、目的を達成出来ない事もある。 出来が悪いせいで良く分からないものは、頑張って理解しようとしても無駄である。 別の手段を考える方がいいかもしれない。 目的を達成出来ない文書は他を当たる必要がある。 他が無い事もあるけれど。 そういう時は困る。けれど良くある。
読んでいて「分からない」という時に、「分からない」にも種類がある。 例えばツアーやGetting Startedなどで、言葉だけ出てくるが説明が無いようなものは、その時点では「分かるはずが無い」ものだ。 こういう分からなさを分かるために頑張るのは無駄だ。
一方でジェネリクスとかsuspend関数などの込み入った話題などは、解説が良く書かれていて、「文書としては分かるはずだが自分は分かっていない」という分からなさもある。 こういう「分からない」は、頑張って分かる必要がある。
つまり「分からない」は気にしなくていい分からない、と、なんとかしないといけない分からない、がある。
「前提知識が足りなくて分からない」、という「分からない」もある。 その文書を読む前提知識を持っている人なら分かるように書かれているが、自分には分からない。 前提知識が足りない場合は、そこで頑張っても意味が無い事が多く、 前提知識を仕入れる必要がある。つまり別の文書なりなんなりに当たる必要がある。
他にも、「その文書の前の方に書いてあった所を忘れているため分からない」とか、「ぼーっと読み進めてしまったので分からない」とか、そういうのもあるだろう。
分からないの種類によって対応は変わる。 分からないの種類から、例えば以下のような事は考えられると思う。
それぞれ対応は変えた方が良い。
技術文書は、同じ内容が出てくる事が良くある。 例えばツアーとユーザーガイドでは、かなりの部分内容が重複する。 当然書籍とツアーは内容がかなり重複する、というかツアーに書いてある事くらいはだいたい書籍に全部書いてある。
そういう訳で、最初に読むもの以外はだいたいある程度は自分が知っている内容を含む事になる。
また、他の言語などで学んだ事が出てくる事もある。制御構造などはどの言語でも一緒だ、とか、継承とかもどの言語でも一緒だ、とか。 これもやはり、知っている事が書いてある事は多い。
むしろ、技術文書を読む順番としては、ある程度知っている事をかぶらせていく方が良い。 だいたいツアーとユーザーガイドはそういう風にできていて、そうやってある程度重なる部分を作ってからリファレンスとかに進むようになっている。
既に知っている事が多いと、読むのが楽になるというメリットがある。 一方で既に知っているので学ぶ量が減る。 この辺は能力に応じてかぶらせ度合いを調整していくのがいいかもしれない。
また、基礎となる重要な少しのことを学んで、その周りに枝葉をはやしていくように雪だるま式に知っている事を増やしていくように構成されているのが普通だ。 そうやってコアになる所はしっかりと定着していき、枝葉の部分は習得度合いが甘くなるように作られている。
だから知っている事が混ざっているというのは当然の事で、それを踏まえた読み方をする方がいい。
文章を読むのは疲れるし、集中力も要求する。だからなるべく読まない方がいい。 しかもぼーっと読んでもあまり頭にも残らない。 しかも知っている所で文章読むゲージを使ってしまっては目も当てられない。
だから文章は、なるべく読まない方がいいし、先頭から順番に読んでいくのも良くない。 これは一般の読書術でも言われる事だけれど、内容に既に知っている事が多く混ざっていて、 なおかつサンプルコードという答え合わせがしやすい情報密度の多いものがある技術文書ではより一層重要度が増すと思う。
まず章立てで書いてある事を予想する。どういう構成になっているかを考える。 そしてそれを踏まえて、節や項のタイトルを見て言って、どういう構成になるかを考える。 そして項の中で各段落に書いてある事をちらっと見て予想したり、タイトルから予想して進む。 そして予想が出来ない何かが出てきたり、予想が外れていると分かったりしたら、どこの予想が外れているかを探してそこを読む。 また予想が当たっている事が確認出来る何かを見つけたら、予想は正解として先に進む。
また、サンプルコードが出てきたら、それで何を言いたいかを読み取れないか考える。 それが何を言いたいかがコードから分かれば、そのコードについての解説のパラグラフの内容はだいたい予想出来るので、 そのパラグラフは読まなくていい。
この内容を予想して答え合わせをする、という読み方をすると、行ったり来たりすることになる。 サンプルコードなどがあったらそこから前に戻る事が多いし、 予想が当たっていなかったりなんだか分からない事が出てきたら、なんで分からないのかを考えて戻る必要も出てくる。 でもこっちの方が集中が続きやすいし、内容も頭に残りやすい。 また、知っている事を飛ばせるので、知っている事が多い場合に早く読める（読んでないが）。
また、読んでないので読む集中力を消費しないで済む。 だから長時間本が読めるようになる（読んでないので）。
内容の予測の所でも書いた所だが、文章の構成を意識するのは、 本を長時間読むためにも、内容を理解する為にも、飛ばす量を増やすためにも重要だ。
具体的には何度も目次を見る。その章の節タイトルを何度もペラペラめくって見ていく。
少し疲れたらとりあえず前後のページをペラペラして先に何が書いてありそうかを見ていく。 こういう読む以外の時間で読む回路を休ませる事で、また少し読めるようになる。
また、タイトルの他にもパラグラフごとの意味を考える。 ここでこういう問題を提起していて、ここでサンプルコードを出しているのでその問題の具体例を出していて、 その後にはたぶん解決策の話が来て、そのあとのこの辺では解決策の実際のコードの説明をしていて〜、 みたいな風に、それぞれのパラグラフで何をやっているかを考える。
また、それが項の中でどういう意味を持つのか、その項が節の中でどういう意味を持つのかを考える。 この章はコレクションの章で最初がスタックだったので、次はリスト、その次はキューとかで同じような話が続くのかな〜、 とかそういう構造を意識する。
フラットな構造で順番に読んでいくとあまり頭に入らないので、 木構造を頭の中に作り上げるように読む方がいい。
その文書を読む目的を達成したら、それ以上読まなくて良い事もある。 例えばツアーやGetting Startedなどは、その次に進むという目標を達成したらそれ以上読む必要は無い。
また、文書の出来が悪くて目的を達成出来ない時も、読むのをやめた方がいい事はある。 この文書を読んでも無駄だな、と判断して、読むのをやめる。
自分には分からないので読んでも無駄な時も止めた方がいい事はある。 この場合は頑張るべきか止めるべきかの判断は難しい事もあるが。
別の文書の方がいい、という場合も読むのを止める事になる。 リファレンスでわからんので書籍を探す、というのは良くある。 なんかお気持ち表明ばかりで具体例が全然出てこない文書に見切りを付けて、違う文書やソースに進むのも良くある。
技術文書は読むのを止める判断をする機会がそれ以外の文書に比べて多い気がする。 これは出来の悪さとも関わりのある事かもしれない。
技術文書は何かを作る為に読んでいる事も多い。 そういう場合には、構造を把握したら、それを使った何かを作ってみるのはとても有効だ。 技術文書を「使う」のは最強の読み方である事も多い。
作ってみる過程で分からない事などをその記事の該当箇所で調べながらコードを書く。 この方が理解も深まるし読むモチベーションも保ちやすいし、 その文書を使う練習にもなる。
理想的には構造が分かる程度まで軽く見た後に、それを使えそうな何かを勉強用に作ってみて、それを作る過程で必要な所をしっかり読む、みたいな読み方が良い。
いくつかの技術文書は「使う」事が目的な事がある。例えばリファレンスなどは必要になった時にそこを見るのが目的で、 そういう場合に大切なのは必要な時に必要な場所を見て、それが理解出来る事だ。 それが出来れば読む必要は無いし、それが出来なければ読んでも無駄な事もある。
また、その技術文書の内容が使われているコードを読みながら該当する文書を読むのも「使う」方法としては良い。 自分で書くのに比べると劣るけれど、コードを読むのに使うのもただ先頭から読むよりもずっと良い方法だ。
使う場合は勉強目的と割り切って、内容に近いものを作ったり読むのが良い事もある。 あんまり関係ないものを作ろうとして本題と関係ない所に時間を使って挫折してしまう場合などは、 やる事を小さく無意味なものにして学習目的で作るのが良い。
チュートリアルなどのように使う手順を示してくれているものやツアーなどで課題などがあるもので使うのは何も考えなくても出来るが、 そういうものじゃない説明を見た時にも、使い方を考えて使ってみる方法は無いか？ と考えるのは重要だ。
kotlinの勉強をしている時に、とりあえずそれをAndroidのアプリで使う方法を考えて何か作ってみる、とか。 文書に指示が無くても実際に何かを作って、それを作る時にその文書を参照する方が、ずっと理解も深まるしモチベーションも保ちやすいし記憶にも残りやすい。
ノートは自分も取らない事は結構あるので、とれという気はあまり起こらないが、とった方がいいとは思う。 マインドマップとかを真面目に書くのが一番良いとは思うし、たまーに自分もやる。
ノートは書いたりタイプしたりする時間が多すぎるのは良くない。 多くてもせいぜい項の単位で数行、 少なければ章ごとに数行でもいいと思う。
一方で何も書かないのは良く無い。章ごとに数行は書いた方がいい。 また、全部読み終わってから書くのも良くない。 章ごとに書く方がいい。
例えば短いものだと、自分の場合【書籍】CppConcurrencyInActionくらいだが、 この位で十分な事も多い。
ざっと見直せる程度の量で書く方がいいと思う。 ノートだけで何かを思い出すというよりは、文書の該当する場所にすぐにいけるような内容の方がいい。 本体は文書の方であってノートの方では無い。 技術文書は使う前提のものが多いので、使う時には文書を読むべきで、 文書の代わりにするのは良くない。
ノートと同じような話ではあるが、何か試したコードなどをいい感じに残すのは良い事も多い。
試したコードがばっと見直せると、 書き方を忘れた時に見直す事も出来る。
何か実際に作る時も何も見ずに書くのは最初のうちは難しいので、 文書を読みながら試したコードなどが残っていると、それを見ながら書くと良い事も多い。
コードは残しておく方が良いし、いい感じにまとめられるならまとめて残しておく方がいい。
でもコードを書くのは手間も掛かるしいい感じに残すのも結構難しいので、 これは出来たらいいな、という類のことでもあるし、文書の性質にも寄る。
読むのにやる気はかなり重要である。という事でやる気についていろいろ考えてみる。
やる気は人それぞれだが、目安として、このくらい出来たら上出来、くらいの期待値を挙げておく。 もっと読めたら読んだらいいし、もっと少なくてもいいんだけど、あんまりにも少ないなら何か対策を考える必要がありそうう。
ここに掲げた量はこれだけ出来れば上出来、という感じで、もうちょっと少なくてもいいと思う。 2週間で一冊くらいでも十分やっていける。 たぶん3週間で一冊でもやれん事はない。 それ以上なら何かを改善して読む量を増やした方がいい気がする。
１日1時間しか読めなくてもまぁやっていけるとは思う。30分が限界なら何か改善が要る気がする。
Kotlinのツアーだったら、分からない事がそれなりにある人なら２日くらいで読めたら上出来じゃないか。 ３日くらいでもいいと思う。2週間掛かっても読み終わらないなら何らかの改善が要る気がする。
Kotlinのリファレンスは主要な所を読むのが2週間くらいなら上出来に思う。 3週間くらいでもいいと思う。二ヶ月で終わらないなら何らかの改善が要る気がする。
もちろん読む気が無い時には読まなくていい。読もうと思った時にこのくらいで読めると良い、という話。
文章は読む気にならないとなかなか読めない。 文章を読むのに、読む気になっているかどうかというのはすごく重要だ。
やる気を起こすのも大切だし、起きたやる気をなるべく無駄遣いしないのも重要だ。
特に読んだ方がいい重要度の高いものがたくさんあって、自分の読む量が足りていないなら、 やる気を起こす工夫や、やる気を無駄遣いしない工夫はいろいろ必要になる。 ほっといても必要なだけのやる気が自然と出る、という事はあまり無い。
やる気は不足しがちだ。
時間管理としてはポモドーロテクニックで良いとは思う。 ただポモドーロはストイック過ぎて遊びが足りないとも思うので、 たくさん文書を読まないといけないと追い詰められていない時は使わなくてもいい気はする。 以下、使う時の話をする。
なお、30分を1ポモと呼ぶ事にする。
専用のアプリは使おう。割と評判のいいものならどれでもいいと思う。 タイマー機能だけでいい。
技術文書を読む時は、一回のカフェとかで4ポモ読めたら十分すぎる。2ポモ読めたら合格。 逆に読む時は1ポモより短くはしない方がいい。 読むなら1ポモは読む。1ポモ無理なら読まない。
あとでも述べるが、個人的にたくさん読まなくてはいけない時は１日に二回くらい読む時間を設けるようにする。 間をあけるとやる気が回復する事があるので、何回かに分けた方がいい気がする。
二回に分けて、一回あたり2ポモ読むのが理想だが、二回目は自分でもなかなか2ポモ読めない。 逆に一回目に2ポモ読むのは結構出来るんじゃないか。
ポモの間の休憩は厳密にやらなくても良いとは思うが、2ポモ読もうという時は間の休憩はルール通り5分でいいと思う。 逆に2ポモ以降は好きに休憩してもいいと思うが、あんまり長い休憩が必要なくらいなら2ポモで終わりにして違う事をやる方がいいとも思う。
先程も言ったが、一回で4ポモ読むのは結構きつい。だから１日を二回に分ける方がいい。二回じゃなくて三回とか四回とかでもいいけれど、自分はせいぜい二回かなぁ。 という事で二回に分ける前提で以下話す。
一回に1ポモ以上は必ず読む。これくらいはまぁ頑張れる。 でも2ポモは読めない事も多い。2ポモ読む気でいたけれど1ポモしか出来ませんでした。これは仕方ない。そんな日もある。
二回に分ける場合、この間はかなり長い必要がある。 例えば空いているファミレスに11時ころ入って、一回目の読書をして、昼飯を食べたとする。 昼飯を食べたあとに二回目、はだいたい出来ない。そんなに早くやる気は回復しない。
昼に読んで、夕方から夜に掛けて二回目として読む、はまぁまぁ上手く行く。行かない事もある。 なかなかやる気は回復してくれない事もある。
二回目に1ポモ読むはまぁまぁ出来る。2ポモ読める日は少ない。
二回に分ける場合、リセット感が重要でもある。 プールに行って泳いだりとか、なんか全然違う事で一回脳を埋めると、二回目が出来る事も多い。 なんか頭の中がリセットされないままだと時間をあけても二回目が出来ない事はある。
やるだけでは無く、場所を変えるのも良い。 同じ場所では二回目は出来ないので、移動する。 カフェに行ったりが自分は多い。 場所については重要なので後に述べる。
ノートPCというのは姿勢とか目線が同じ感じになるので、長時間読みにくい。 一方で試しながら進む系の文書の場合はPCであるメリットも大きい。kotlinのツアーなどは試しながらやりたい部分も多い。
何かリセットして二回目感を出したい場合、PC以外で読む、というのは有効な事も多い。 タブレットは自由に動かせるというメリットがあるので、PCでもう無理ってなった後もタブレットでは意外と読めたりする。 この辺はガジェットで乗り越えるというのも有効な手段だ。
プリントアウトした紙も文書によっては悪くない。うまくプリントアウト出来ない文書も良くあるが。 寝っ転がって読む時に、紙は腕が疲れないというメリットもある。 読む所だけなら軽いというメリットもある。 初期費用が少ないというメリットもある。 自分は以前はセブンのネットプリントを良く使っていた。 最近はタブレットで読むようになったので紙はあまり使ってない。 ただ紙でも良いとは思っている。
自分は液晶よりはe-inkの方が読みやすいと思っているので、現在はBOOXのNote3を使っている。
何にせよ、姿勢と首の角度を変えるのは結構重要と思っている。
この辺は工夫の余地がいろいろある所なので、ノートPCの限界が来た後の選択肢はいろいろ探求する価値があると思う。
本を読むやる気が出ない時には、場所を変えるというのは良くやる。 カフェで読書するのは良くやる。 モーニング食べつつ読書する、というのはなかなか良い。 出勤する仕事している時は出来ないが。
モーニング食べつつ技術文書を読む、をやると、午後の前半は読む気が回復しない事が多いので、昼食後はなるべく違う事をやるようにしている。 一回目を午前中にやったら、次は夕食後が多い。
スーパー銭湯なども読書に使う事はあるが、なんか期待したほどは進まない事が多い。 でもたまに進む事もあるので使っている。
本当にたくさん読まなくてはいけない時は公園とかいろいろ場所を変えたりする。 季節によっては外はいまいちな事もあるけれど。 外は風が吹いていたりしていまいちな事も多いけれど、良い読書場所がある場合は有効だったりもする。 みなとみらいのあたりとかは読書に良い。
図書館は大学図書館は良く使っていたが、いまいち進みが悪い図書館も多い。 東大だと本郷とか駒場の図書館はなかなか良い。 市営だと都立中央図書館とか横浜の県立中央図書館は結構進む。横浜の市立中央図書館はなんかあんまり進まない。 地元の図書館などは進みが悪いので読書には使っていない。
海のビーチとかはまぁまぁ進む。ただ準備が面倒くさくて最近はやってない。
自分の部屋の机はPC作業では良く使っているが、文書読みでは進みはいまいち。 PCで読む時でも文書を読みたい時は床に座って背もたれクッションによっかかりながら読んでいる事が多い（低温やけどに注意）。 部屋の中でもBOOXで読む事は多い。でも仕事机ではやはり進みはいまいち。
場所を変える効果は大きいので、いろいろな場所を試してみるのが良いと思う。 この辺はその人のライフスタイルに合わせて良い場所を探すのが良かろう。
リファレンスとかを、何か作ろうとしてみて分からない所を調べるように読むと、読む気力ゲージ的なものを全然消費しない。 何か作ろうとするには違う気力を消費しはするけれど、 基本的には文書を「使う」方が気力の問題は少ない。
だからやる気が無い時には使う方法を模索してみるのはとても有効。
少人数でそれを勉強するような勉強会は、本や文書を読むのに有効だ。 自分が発表者になればしっかり読むし、発表者じゃなくても予習をするのは何も無く文書を読むよりもモチベーションを保ちやすい。
読むのが大変そうだなぁ、という時にその勉強会を主催したり、やっているのを探して参加するのは良くやられる。
やる気を保つ方法としては、読んだ内容をプログラム友達に話すのは有効だし、楽しい。 話すネタとして読むというのもやる気を起こす方法としてはなかなか有効だ。
会った時に何を話すかを考えて読むと、理解が深まるという副産物もある。
前にも言った、内容を予想して答え合わせをする、という読み方は、やる気の消費という点でも優れている。
最初から一行ずつ読むよりも、内容を予想して合ってるかどうかを確認する方が、文章を読む前に多くの時間を使う。 でもこの消費している時間では、あまりやる気が消費されない。 この読むやる気を消費しない時間をなるべく増やす事で、 読む時間を短くするのは、同じやる気で読める量を増やすのに有効と思う。
だからやる気が足りていない時ほど、読む以外のこれらの事に時間を使う方がいい。 もうやる気ねーなぁ、となってあと少しでポモドーロが終わる時には、 目次とか眺めたり前後の節や項タイトルを眺めたりして終わらせるとかでも良い。
一番効率的なやり方は、結構やる気を消費する。 例えばポモドーロを使う方が読む量は増えると思うけれど、ポモドーロを使って始めるくらいのやる気を要求する。
座ってノートを取りながら読む方が内容の理解は進むが、ノートを取れる状況を用意してノートを取りながら読むのもやる気を要求する。
効率が多少悪くても、やる気の消費を優先してゴロゴロと寝っ転がりなたら読んでノートを取らなかったり、 ポモドーロ使わずになんとなく読み始めたりする、という選択肢もある。 効率の良いやり方を知っておくのは大切だけれど、 知った上で効率の悪いやり方を選んでも良い。
あんまりにも進みが悪すぎる時には効率を上げる必要はあるけれど、必要な程度の量が読めているのなら、 効率が悪いやり方でも構わないし、 実際自分も効率の悪いやり方をやっている事は多い。
文章を読むにはある程度集中する必要がある。集中に入るのに慣れている人は自分流のやり方でいいです。 全然集中出来ない人向けのコツのようなものを。
まず、ポモドーロタイマーを使う。これは一番簡単な方法で一番効果があると思う。
ポモドーロタイマーを使うコツとしては、始める前に始める、と決意して、始めたら終わりまでやる事。 逆に終わりまでやれない時は始めない。
ポモドーロを使うかどうかはおいといて、やる気を出すコツとしては、最初に終わりを決める事。 やるぞ、では無く、いつに終わるぞ！と決める。 やる気が出ない時は終わる時期を早くする。始めるのを遅くするのでは無く終わる時期を早める、というのがやる気を出すコツ。 休憩してやる気を出すとかはあまり有効では無い。 待っててもあんまりやる気は出ないから。
それよりは始める方がいい。始める為には、始める対象をなるべくちょろくするのが大切。大きなものを始めるのは大変なので、 これ以上ちょろくは出来ない！という位小さくする。 小さくするのは終わりを近づける事でやる。
また、十分に小さい単位にする事で、割り込みをしない事を納得する。 スマホの通知が来てもその期間は見ない。 その他何かの割り込みが来ても、その時間くらいは後回しに出来る、くらいの単位にする。 ポモドーロの25分は割と良いと思うけれど、これが厳しいならもっと短くしても良い。
また、やらないとちゃんと決めるのも大切。どこまで短くしてもやることが出来ないのなら、もうその時はやらない、と決めて違う事をする。 やらなきゃな〜といいつつ時間をダラダラ消費しない。 やらない、と明確に決意する事で、次の機会のやる気がちょっと増す。
以上を簡単にまとめる。
たぶんここまで書いてきたような事は、どこかで練習した結果出来るようになっているのだと思う。 なので、出来ていないなら練習が必要だと思う。 どういう練習をすれば良いだろうか？
制御フロー（ツアー） - Kotlin 日本語リファレンスあたりを対象に練習問題とかを作って練習させるとかどうだろう？
パラグラフリーディングのページに試行錯誤をまとめてみる。
技術文書の読み方みたいな内容で検索してみて、参考になりそうなのを見かけたらここに貼っていく。