2020-11-12

Rails link_to の使い方

Rails

Rails はいろいろといい感じにやってくれるので便利だけど、理解しないままなんとなく使ってしまっているところが多いので整理した。

link_to

link_to は、リンク先を指示するヘルパーメソッド。

書き方

ERB

<%= link_to リンクテキスト, パス[, オプション] %>

slim

= link_to リンクテキスト, パス[, オプション]

以下のような<a>タグが生成される。

<a href="パス">リンクテキスト</a>

パスの書き方

例

 <%= link_to "Profile", profile_path(@profile) %>
 # => <a href="/profiles/1">Profile</a>

show/update/destroyアクションの場合は、パスをオブジェクト名だけで指定することができる。profile_path(@profile)と書かずに@profileだけで OK。

上の例（show）だと、次のように書ける。

 <%= link_to "Profile", @profile %>
 # => <a href="/profiles/1">Profile</a>

edit などの場合は省略できないので、次のようになる。

 <%= link_to "Edit Profile", edit_profile_path(@profile) %>

（参考）link_toメソッドを使ったリンクの作成 - Ruby on Rails入門

ブロックを渡す書き方

link_toには、ブロックを渡すこともできる。

ERB

<%= link_to パス[, オプション] do %>
  リンクテキストや画像など
<% end %>

slim

 = link_to パス[, オプション] do
   = リンクテキストや画像など

画像にリンクを張る例。

slim

 = link_to image_tag(company.logo_url, alt: company.name, class: "company-icon"), company
 
 / こう書ける  
 = link_to company do
   = image_tag company.logo_url, alt: company.name, class: "company-icon"

ActionView::Helpers::UrlHelper

2020-11-11

チーム開発でのGitHubの流れ

Git GitHub

先月から、フィヨルドブートキャンプでチーム開発に入らせてもらった。

これまでの課題も GitHub 上の自分のリポジトリに PR を作ってレビューしてもらっていたので、GitHub には慣れているつもりだったが、最初は戸惑うところがあったのでメモしておく。

チームによって方針が異なるので、ここに書くのは一例でしかなく、こうしなければいけないというものではない。

流れ

最初だけ必要な作業

自分の GitHub アカウントをコラボレーターに追加してもらう
リモートリポジトリをローカル（自分のマシン）に clone する
README を見てセットアップする

Issue ごとに繰り返す作業の流れ

かんばんで、自分が作業する Issue を「作業中」に移動させる
ローカルリポジトリのmasterブランチから開発用のブランチ（例: some-feature）を切る
- $ git checkout -b some-feature
some-featureブランチで作業してコミット
作業終了
プル
- $ git pull origin master
- masterブランチを最新状態に
リベース
- some-featureブランチで、$ git rebase master
- some-featureブランチの根元が、最新のmasterの先端になる
リモートリポジトリにプッシュ
- $ git push origin some-feature
PR（プルリクエスト）作成
- 作業前に Draft として PR を作成してもいい
CI が通ったことを確認してから、レビュー依頼
（修正作業など）
動作確認後、Issue を close する

備考

レビューやデザインを依頼するなどして「待ち」になるまで、他の Issue の作業を始めてはいけない
今開発しているリポジトリはまだmainではなくmasterブランチを使っているのでそのまま書いている
5〜6はpull --rebaseでまとめられる（プル・リベースについてはこちらの記事）

フォースプッシュは結構使う

Git を1からやり直す（リベース編）で、「一度プッシュしたコミットはリベースしない！」と書いたが、実際の開発ではしょっちゅうリベースしている。

作業途中でコードを見てもらいたいときや特に理由がなくても、作業完了前にプッシュすることはよくある。レビューを依頼するときには最新のmasterブランチを取り込んでおく必要があるため、上の手順の5以降をやることになる。

最初のプッシュをした後にmasterブランチが更新されていると、リベースかマージをする必要がある（どちらをやるかはチームにより異なる）。今のチームではリベースすることになっているため、同じコミットでもコミットのハッシュが変わり、プッシュできなくなる。

そこで、以下のコマンドでフォースプッシュ（強制プッシュ）する。

$ git push -f origin some-feature

フィヨルドブートキャンプの開発では、一つのブランチを複数人で触ることはないので特に問題は起こらない。

自分が作業するブランチを他の人も触る可能性がある場合は、--force-with-lease オプションを使うと、誰かがプッシュしている場合に強制プッシュできなくなるので安心。--force-with-leaseを-fのエイリアスにしてもよさそう。

（参考）現場で使える Ruby on Rails 5速習実践ガイド（9-1）

2020-11-09

『Team Geek』を読んだ

読書

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

作者:Brian W. Fitzpatrick,Ben Collins-Sussman
発売日: 2013/07/20
メディア: 単行本（ソフトカバー）

どんな本か

複数のプログラマが関わる場合、優れたコードを書くだけではプロジェクトは成功しません。
全員が最終目標に向かって協力することが重要であり、チームの協力関係はプロジェクト成功のカギとなります。
本書は、Subversionをはじめ、たくさんのフリーソフトウェア開発に関わり、その後Googleでプログラマを経てリーダーを務めるようになった著者が、「エンジニアが他人とうまくやる」コツを紹介。
「チームを作る三本柱」や「チーム文化のつくり方」から「有害な人への対処法」まで、エンジニアに求められる社会性について楽しい逸話とともに解説します。
Amazon.co.jp より

なぜ読んだのか

「角谷トーク」で知って、「ほしい物リスト」に入れていた本。

Kindle 版がないため購入を躊躇していたが、先日LT会で紹介されているのを見て、さらに読みたくなったので買うことに。

フィヨルドブートキャンプでもチーム開発の課題に入ったので、タイミング的にも今読もうと思った。

この本を読む目的・この本から得たいこと

チームの協力関係の築き方を知る
「エンジニアが他人とうまくやる」コツを知る
チーム内の一人のエンジニアとして、どういうことを考え、どう動けばいいかのヒントを得る

大事だと思ったことをメモ

「早い段階で、高速に、何度も失敗せよ」
ソフトウェア開発はチームスポーツである
- ビジョンを共有しよう
- 仕事を分担しよう
- 他人から学ぼう
- 素晴らしいチームを作る
チームで働くときのポイント
- HRT（ハート）
- 謙虚（Humility）
  - 世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善していこう。
- 尊敬（Respect）
  - 一緒に働く人のことを心から思いやろう。相手を1人の人間として扱い、その能力や功績を高く評価しよう。
- 信頼（Trust）
  - 自分以外の人は有能であり、正しいことをすると信じよう。そうすれば、仕事を任せることができる。
あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるもの
コードを批判されても、自分の性格や人間としての価値が攻撃されたと思わないこと
- プログラミングスキルは練習すれば向上する
相手に伝えるときは、自分の疑問として謙虚に聞く
議論しているのはコードのことであり、誰かの価値やコーディングスキルのことではない
チームの文化
- エンジニアリングチームが共有する経験・価値・目標のこと
強い文化は改善に対してオープンだが、害を与える急激な変化に対しては防御的
許可を求めるより寛容を求めるほうが簡単
「運」は鍛えることができる
- 運のいい人は「チャンスに気がつく」
他人がそのソフトウェアを使って幸せにならなければいけない
- ソフトウェアを使ってもらい、そのフィードバックを受けてプロダクトを改良していくフィードバックループを回さなければ、ソフトウェアは死んでしまう
ユーザーに集中すれば、他のことはすべてついてくる
- ハードルを下げる
- プロダクトは、最初の体験が超重要
- ユーザー数ではなく利用（アクティブ数）を計測する
- 速度重要
- Less is more（少ないことはよいこと）
- 怠けない
  - フォームの入力値は寛容に
- 複雑さを隠す
- ユーザーの意見を直接聞く
- 見下さない
  - ユーザーには常に敬意を払う
- 我慢する
  - 多くのユーザーは問題をうまく表現できない
  - 何を意図しているかを理解することが重要なスキル
- 信頼は最も大切なリソース
ユーザーのことを忘れない
- ソフトウェアを書く理由
  - 自分、チーム、会社のためではない
  - ユーザーの生活を豊かにするため

所感

そろそろ就職活動をしなければいけないということもあり、一緒に働くことになる人たちの考え方やビジネスなどについて学びたいと思い、最近いろいろな本を読んでいる。

プログラミングに直接関係ない本も多いが、だんだん共通点が見えるようになってきた！面白い。

『Team Geek』のHRTは、チームで働く上で大事なことだ。確かに、今までの自分を振り返ってみても、謙虚（Humility）・尊敬（Respect）・信頼（Trust）の3つを忘れずに行動すれば、人間関係についての多くの問題は起こらなかった気がする。

コードを批判されても、自分の性格や人間としての価値が攻撃されたと思わないこと

少し前に教えてもらった「認知行動療法」っぽい考え方かなと思った。認知行動療法についてはまだよく知らないので、今度そういう本を読んでみたいと思っている。

“ユーザーに集中すれば、他のことはすべてついてくる” というのは覚えやすくてうれしい。

ソフトウェアを使ってもらい、そのフィードバックを受けてプロダクトを改良していくフィードバックループを回さなければ、“ソフトウェアは死んでしまう”。「死んでしまう」とまで強い言い方になっていたのが印象的だった。

『アジャイルサムライ』にも書いてあったが、ユーザーの声に真摯に耳を傾け、改良していくループを回し続けることが大事で、それがユーザーの幸せにつながる。

自分の仕事が誰かの幸せにつながるなんて素晴らしい。

仕事を始めたら読み直したい本。就活しなきゃ…

2020-11-02

『やり抜く力』を読んだ

読書

やり抜く力 GRIT(グリット)――人生のあらゆる成功を決める「究極の能力」を身につける

作者:アンジェラ・ダックワース,神崎朗子
発売日: 2019/09/06
メディア: Audible版

どんな本か

ＩＱでも才能でもない、成功に必要な第３の要素とは？　全米社会に絶大な影響を与えた成功と目標達成の画期的な理論！　人生の成否を決定づける「やり抜く力」について、自分での身につけ方から、子どもなど他人の「やり抜く力」を伸ばす方法まで徹底的に明らかにする。これまでのあらゆる常識がくつがえる衝撃の一冊！
Amazon.co.jp より

なぜ読んだのか

先日のLT会で紹介されていて、そのLTに感動したので、読んでみた。

大事だと思ったことをメモ

「やり抜く力」とは、「情熱」と「粘り強さ」
- 「情熱」とは、ひとつのことに専念すること
偉大な人とふつうの人の決定的なちがいは「動機の持続性」
- 「情熱」と「粘り強さ」と似ている
「やり抜く力」を強くする4ステップ
- 興味
- 練習
- 目的
- 希望
エキスパートになるためには、「意図的な練習」が必要
1. ある1点に的を絞って、ストレッチ目標（高めの目標）を設定する
2. しっかりと集中して、努力を惜しまずに、ストレッチ目標の達成を目指す
3. 改善すべき点がわかったあとは、うまくできるまで何度でも繰り返し練習する
  - 時間の長さより「どう練習するか」がカギ -「目標設定 → クリア」を繰り返し続ける
  - 「ラクな練習」はいくら続けても意味がない
  - 「優秀な人」の姿勢を知る
  - 「習慣（ルーティーン）」をつくる
「情熱」の源は「興味」と「目的」
- 「これは人の役に立っている」と考える
- 幸福になる方法は「快楽を追うこと」と「目的」を追うこと
レンガ職人の話
- 「なにをしているんですか？」
  1. 「レンガを積んでるんだよ」 → 仕事
  2. 「教会をつくっているんだ」 → キャリア
  3. 「歴史に残る大聖堂を造っているんだ」 → 天職
- 職種による違いはない
- 自分がどうとらえるか
「大きな目的」のためなら、人は粘り強く頑張れる
「楽観主義者」は無力感を乗り越えられる
「やり抜く力」は伸ばせる

所感

レンガ職人の話が印象的で、でもどっかで聞いたことあるような…と考えていたら、思い出した。

「角谷トーク」で何度も出てきた文。

単に石を切り出す場合でも、常に心に聖堂を思い描かねばならない。
-- 採石場作業者の心得
『達人プログラマー』より

よく似た話だ。『達人プログラマー』も読みたい。

自分が何のためにそれをやるのか、常に目的や問題の全体像を考える、または意識することが大切だということだと思う。

“「才能」は、努力によってスキルが上達する速さのこと” と書かれていたが、結局は努力しなければ才能は花開かないということで、努力を続けられることが一番大事。

努力を続けるためには、興味と目的を持って取り組むこと。

好きなものがあるというのは、それだけで強みになるのかもしれない。

あと自分は元々楽観的なタイプなので、そこはよかった。

好きなことを仕事にできるように、頑張ろう。

2020-10-24

初めてのLT会 Vol.5 に参加

勉強会など Fjord Boot Camp

10月24日、オンラインで開催されたフィヨルドブートキャンプの「初めてのLT会 Vol.5」に参加。今回は聞く側での参加。ツールは Remo で、参加者は約35人。

「フィヨルドブートキャンプの歩み方」をテーマに、7人の受講生が発表。刺さる発表ばかりで感動。こんな素晴らしいイベントをありがとうございました。

「バグ報告テンプレートの活用」
- 感想
「心が完全に折れた僕がモチベーションを取り戻した方法」
- 感想
「早起きは三文の徳！」
- 感想
「Rubyのエラーをちょっと整理」
- 感想
「How to question on Fjord bootcamp」
- 感想
「初心者こそ！RubyMineで始めよう！」
- 感想
「A way of walking "fjordbootcamp" as RPG」
- 感想

「バグ報告テンプレートの活用」

@mh さんの発表。

speakerdeck.com

感想

普段はモバイルエンジニアをされている mh さん。フィヨルドブートキャンプに参加してちょうど1年。毎日生やした日報の草が満開になったそうでおめでたい！

バグ報告テンプレート、初めて知った。Rails の issue 提出時に使うバグ再現用のスクリプトファイルだが、ポリモーフィック関連などの学習で検証ツールとして使えるとのこと。使いこなしたらかなり便利そう。「問題を小さく切り分ける」の、大事〜

「心が完全に折れた僕がモチベーションを取り戻した方法」

@R-Tsukada さんの発表。

speakerdeck.com

感想

この発表を聞いて、…泣いた。あまりにも共感ポイントが多すぎて…！（元々涙もろい）

私は自分のことをポジティブだと思っているが、「他人と比較して自信がなくなっていった」のは全く同じ。「証明マインドセット」、まさに自分のことを言われているよう。

「人と比べないようにしよう」というのは少し前から心がけているが、簡単ではない。それから、なぜ気軽に質問できないのか、なかなか言語化できなかった部分がわかった。

助けを求めることができない
→ ミスすることを恐れ、自分にはできないということが他人にも伝わってしまうことが怖い

プログラミングに関しては完全に初心者なのでプライドなんてないつもりだが、書かれていた通りだった。できない自分を見せるのが恥ずかしいという思いがどこかにあるのだろう。紹介されていた本はその場でポチり。

やり抜く力

作者:アンジェラ・ダックワース
発売日: 2016/09/12
メディア: Kindle版

自分と同じことで同じように苦しんだ人の話だから刺さりすぎた。この間卒業生の方もおっしゃっていたが、「できない」ことを「自分には能力・センスがない」とアイデンティティと結びつけないことが大事。「客観的視点」を持っていきたい。意識するだけじゃなくて、まずはきちんと「分析」しないと。

「早起きは三文の徳！」

@Ago さんの発表。

speakerdeck.com

感想

早起きは自分の苦手分野。最近特に生活が不規則になりがちだったので興味深いテーマだった。

機能が少なめのスマートウォッチ、よさそう。とりあえずほしい物リストに入れたので、いろいろ見てみよう。

起床後のルーティン、今の自分には「読書」がよさそう。読みたい本いっぱいあるし、朝はインプットに最適とのこと。とりあえず今までより1時間ぐらい早起き、やってみようかな。

「Rubyのエラーをちょっと整理」

@universato さんの発表。

speakerdeck.com

感想

エラー文、最初の頃全然意味がわからず怖かったのでありがたい内容。よく出るエラーには慣れてきたけど、きちんと読んでいない部分もあったので勉強になった。

ハッシュをブロックと勘違いされるやつ（p { }）、この前ハマりかけた。

coerce 初めて聞いた。面白い。

Numeric#coerce (Ruby 2.7.0 リファレンスマニュアル)

「How to question on Fjord bootcamp」

@ksmxxxxxx さんの発表。

speakerdeck.com

感想

フィヨルドブートキャンプでは、質問する手段として、Webアプリ上の Q&A、Slack、質問・雑談タイム（毎日1時間、出入り自由のビデオチャット）がある。その使い分け方やテキスト・非同期コミュニケーションで気をつけることについて。

ksmxxxxxx さんはデザイナーとして経験が長いためか Web でのコミュニケーション能力が高いなぁと思って見ていたので、知見を共有してもらえてありがたい！すぐに生かせることばかり。

『Team Geek』は前からほしい物リストに入れているけど、kindle 版がないため購入を躊躇していた。とりあえず買おう。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

作者:Brian W. Fitzpatrick,Ben Collins-Sussman
発売日: 2013/07/20
メディア: 単行本（ソフトカバー）

「初心者こそ！RubyMineで始めよう！」

@ikumatdkr さんの発表。

speakerdeck.com

感想

特にコードジャンプが便利そうということで気にはなっていた RubyMine。前検討したとき、年2万円以上もすると思って諦めたのだが、勘違いだった。個人利用なら 1年目 10,300円、2年目 8,200円、3年目 6,200円。前見たのは法人利用の料金だった。

発表を聞いていたら、コードジャンプ以外にもいろいろと便利そう。リファクタリングができる!?

ということで、買った！！

料金以外にも、RubyMine より VSCode のデザインが全体的に好みだったこともあったのだが、プラグインでテーマを変えてフォントも調整していったらそこそこいい感じになった。

コードジャンプを軽く試してみたら、やっぱり便利すぎる…！VSCode では飛べないところにも飛べた。早く使いこなしたい。

「A way of walking "fjordbootcamp" as RPG」

@mkmy1123 さんの発表。

speakerdeck.com

感想

フィヨルドブートキャンプを RPG にたとえて、攻略ポイントを紹介。ドラクエ好きからするとたとえがぴったりはまっていてわかりやすく、共感ポイントもたくさん。

最後のページで本日二度目の涙…。今スライドを見返しても涙は出ないのだけど、それだけ発表が素晴らしかったんだと思う。

一人じゃボスは倒せない。@R-Tsukada さんのテーマとも重なるが、「本当の敵は自分のみ、周りと比べなくていい」、「客観視する」など、この攻略本、ゲーム序盤の頃の自分に見せたい！

2020-10-22

『イシューからはじめよ』を読んだ

読書読書術

イシューからはじめよ ― 知的生産の「シンプルな本質」

作者:安宅和人
発売日: 2014/09/01
メディア: Kindle版

どんな本か

★ロジカルシンキング・問題解決の決定版！
★AI×データ時代の必携書。支持され続けて20万部突破！

やるべきことは、100分の1になる！

コンサルタント、研究者、マーケター、プランナー……
生み出す変化で稼ぐ、プロフェッショナルのための思考術
「脳科学×マッキンゼー×ヤフー」
トリプルキャリアが生み出した究極の問題設定＆解決法

〈圧倒的に生産性の高い人〉に共通する問題設定＆解決法
「イシュー」とは、「2つ以上の集団の間で決着のついていない問題」であり「根本に関わる、もしくは白黒がはっきりしていない問題」の両方の条件を満たすもの。
あなたが「問題だ」と思っていることは、そのほとんどが、「いま、この局面でケリをつけるべき問題=イシュー」ではない。
本当に価値のある仕事をしたいなら、本当に世の中に変化を興したいなら、この「イシュー」を見極めることが最初のステップになる。
（Amazon.co.jp より）

なぜ読んだのか

以前からほしいものリストに入れていたこの本。Amazon で kindle 版半額セール（10月29日まで）をやっていたので購入した。ほしいものリストに入れたのは、「圧倒的生産性の高い人」になりたいと思ったからだ。

昨日読んだ『王様の速読術』に書いてあった以下を踏まえ、読む前に自分なりの目的を設定した。

大事なのは「速く読む」ことではなく、「短時間で必要な情報を獲得する」こと
目的意識を持って主体的に読書することが何より大事

自分がこの本を読む目的・この本から得たいこと

イシューとは何か知る
イシューの見極め方を知る
イシューの解き方のヒントを得る
生産性を高める方法を知る

大事だと思ったことをメモ

悩まず、考える

悩む = 答えが出ない
考える = 答えが出る
- 仕事で悩むことは時間の無駄
- パーソナルな問題を除いて、悩むことには一切意味がない
常識を捨てる
- 「問題を解く」より「問題を見極める」
- 「解の質を上げる」より「イシューの質を上げる」
- 「知れば知るほど知恵が湧く」より「知り過ぎるとバカになる」
- 「1つひとつを速くやる」より「やることを削る」
- 「数字のケタ数にこだわる」より「答えが出せるかにこだわる」

イシューとは何か

イシュー（issue）の定義（以下の2つの条件を満たすもの）
- 2つ以上の集団の間で決着のついていない問題
- 根本に関わる、もしくは白黒がはっきりしていない問題
イシュー度
- 自分にとってこの問題に答えを出す必要性の高さ
解の質
- そのイシューに対してどこまで明確に答えを出せているかの度合い
「イシュー度」の低い仕事の価値はゼロに等しい

イシューの見極め方

イシュー度が高いか
- 自分にとってこの問題に答えを出す必要性の高さ
答えが出せるもの、白黒はっきりつけられるものか
明確な仮説を立てられるか
イシューと仮説を「言葉」として表現することにこだわる
問題と言われることが100あるうち、今答えを出すべき問題は2つか3つ
- そのうち答えが出せるものは半分。つまりイシューは1％しかない

イシューの解き方のヒント

大きなイシューは「答えを出せるサイズ」に分解する
- ダブりもモレもなく
- 本質的に意味のあるかたまりで

生産性を高める方法

「生産性」の定義
- どれだけのインプット（投下した労力と時間）で、どれだけのアウトプット（成果）を生み出せたか
バリュー（価値）のある仕事とは、「イシュー度」と「解の質」がいずれも高いもの
いくつもの手法をもつ
- 一つの方法がうまくいかなければ、さっと他の方法に切り替える
- 一つに固執しないこと
回転率とスピードを重視する
- 丁寧にやり過ぎると、スピードだけでなく完成度まで落ちる
- 60%の完成度の分析を70%にするためにはそれまでの倍の時間がかかる
- 60%の完成度の状態で再度はじめから見直し、もう一度検証のサイクルを回すことで、80%の完成度にする半分の時間で80%を超える完成度に到達できる

所感

この本から自分が受け取った一番強いメッセージは、「悩むな、考えろ」。

プログラミングの課題でも、一人で悩んで一歩も進めなくなることが何度かあったので、ハッとした。悩むことと考えることの違いは、答えが出るのか出ないのか。答えが出ないことをいくら悩んでも意味がない。

まず、イシューを見極め、答えが出せるサイズまで分解し、イシュー度の高いものから取り組んでいく。

こう書くと簡単そうだが、多分最初は難しい。1年ぐらいかかると書かれていた。「イシュー」が何かを考えるだけでも意味はあると思うので、実践できるところからやっていきたい。

速読の話

30分と時間を決めて読み始めたのだが、気になったところを精読したりメモしたりしていたら結局1時間半くらいかかった。でも、1冊に何日もかけるのが普通で、そのうち他の本に手を出してしまい読み終わっていない本が積み重なっていた今までの自分と比べたら、1日で1冊読めただけで奇跡！

この本から学べる内容はもっとたくさんあると思うが、今回の自分なりの目的以外の部分は必要になったとき読み返せるようインデックス読みをした。この本にも、“脳は脳自身が「意味がある」と思うことしか認知できない。” とあり、今自分が興味のあることや理解できるレベル以上の部分は、読んでも時間がかかるばかりでほとんど頭に残らないと思う。

インデックス読みは『王様の速読術』に掲載されているものではないが、“自分に合う方法を探すことが大事” ということで、取り入れている。

（参考：学習を加速させるインデックス読書術 - Qiita）

『イシューからはじめよ』の中でも、“丁寧にやり過ぎると、スピードだけでなく完成度まで落ちる” と書かれていたので、短時間で3回読む（見る）「王様の速読術」は的を射ていると思った。

自分が読んだのは電子版だったので、最初に「表紙や帯を見る」というのができない。代わりに Amazon の商品説明を読んでみたのだが、要点がズバリ書かれていて驚いた。これまで全然気にしていなかった。それを踏まえた上で読んでいくと、本の全体像もわかりやすく理解が進んだ。

王様の速読術、使える。

masuyama13.hatenablog.com