「Railsの学び⽅、あるいは本の書き⽅、そして教え⽅」 銀座Rails #27 2020/11/27 https://ginza-rails.connpass.com/event/193008/ 五⼗嵐邦明/igaiga twitter: igaiga555 ガーネットテック373株式会社

⾃⼰紹介 五⼗嵐邦明/igaiga twitter: igaiga555 フリーランスRailsエンジニア ガーネットテック373株式会社 著書:『ゼロからわかるRuby超⼊⾨』、『Railsの教科書』、『パーフェクトRails［増補 改訂版］』、『RubyとRailsの学習ガイド』 銀座RailsはVol.03 2018.11.21 LT以来、ちょうど2年ぶり リンクアンドモチベーション、forkwell、SONY各社さんの継続⽀援に感謝 河野君とは群⾺⾼専時代の同級⽣

ゼロからわかるRuby超⼊⾨ 発売2周年 イラスト描いてくれたべこさんは群⾺⾼専の後輩 https://twitter.com/becolomochi プログラミングが初めての⼈向け 現存するRuby本の中で「最も易しく、分かりやすく、かわいい」を⽬指した本 Railsで使う知識は⼀通りカバー Sinatraを使ったWebアプリの説明

【提供】 RMHさん RMHさん TokyuRubyKaigi でもお世話になったVoyageGroup傘下の会社 私もお⼿伝いしています 今回の私の発表に対してスポンサーになっていただきました 業務時間中に今回の資料作成時間をいただきました(-⼈-) 1⼈⽬のエンジニア社員を募集しています くわしくはまた後で

えこひいきが発⽣します スポンサー: RMH(TokyuRubyKaigi でもお世話になったVoyageGroup傘下の会社) 新⼈研修業務: Classi 各スクール: フィヨルドブートキャンプ、DAIMYOエンジニアカレッジ、Dive Into Code 販売: BOOTH Railsチュートリアル、Railsガイド運営: YassLab 「プロダクト開発が学べるRailsチュートリアル、RubyとRailsの学習ガイドなどを 執筆する『五⼗嵐邦明』⽒と連携し、コンテンツ拡充へ」 https://prtimes.jp/main/html/rd/p/000000002.000038934.html 書籍群:『ゼロからわかるRuby超⼊⾨』、『Railsの教科書』、『パーフェクトRails』、 『RubyとRailsの学習ガイド』

今⽇の流れ 第1部 学習編 第2部 執筆編 第3部 教育編 限られた時間なので全体的に概論になっています もっと聞きたい箇所があれば次回登壇の参考にしますのでリクエストください 今回のTryとして「 ⽴場を替えて⾒る」を書いています 「学ぶ側からはこうで、教える側からはこう」といったもの 裏側から⾒ることで得られる知⾒がないかという試み マークが出てきたら、この視点の内容だと思ってください なので、教育編に学習の話が出ることもあります

第1部 学習編 主な内容 Railsの学び⽅の基本的な流れ わからないことをわかる技術 抽象と具象の旅 ⼼を⽀える技術

Railsの学び⽅の基本的な流れ 書籍・資料をつかった学習

No content

Railsの書籍・資料をつかった学習 Rails編 難易度やさしい順に並べてます Railsの教科書: https://tatsu-zine.com/books/rails-textbook 【この間の本がもっと欲しいです】 Railsガイド: https://railsguides.jp/ 独習Ruby on Rails(著: ⼩餅良介): https://www.shoeisha.co.jp/book/detail/9784798160689 現場Rails(著: 万葉衆): https://book.mynavi.jp/ec/products/detail/id=93905 Ruby on Rails 6 実践ガイド(著: ⿊⽥努): https://book.impress.co.jp/books/1118101134 Railsチュートリアル: https://railstutorial.jp/ パーフェクトRails: https://gihyo.jp/book/2020/978-4-297-11462-6 【この先の本ももっと欲しいです】

Railsの書籍・資料をつかった学習 周辺技術編 Git: わかばちゃんと学ぶ Git使い⽅⼊⾨ https://www.c-r.com/book/detail/1108 コマンド版 https://www.r-staffing.co.jp/engineer/entry/20190621_1 HTTP, REST: Webを⽀える技術 https://gihyo.jp/magazine/wdpress/plus/978-4-7741- 4204-3 DB設計: 楽々ERDレッスン https://www.shoeisha.co.jp/book/detail/9784798110660 SQL: SQL書き⽅ドリル https://gihyo.jp/book/2016/978-4-7741-8066-3 RSpec: Everyday Rails https://leanpub.com/everydayrailsrspec-jp 監視: わかばちゃんと学ぶサーバー監視 https://twitter.com/llminatoll/status/1322805164126789637 AWS: AWSをはじめよう https://booth.pm/ja/items/1032590 暗号技術: SSLをはじめよう https://booth.pm/ja/items/1834443 暗号技術: 暗号技術⼊⾨ https://www.hyuki.com/cr/ 達⼈プログラマー https://tatsu-zine.com/books/the-pragmatic-programmer-2ed

地図をつくる 「RubyとRailsの学習ガイド2019」より: https://igaigarb.booth.pm/items/1312664 追記したい項⽬: CI, Redis, Load Blancer, CDN

書籍の先の世界 本は0から100くらいまでの知識を学ぶ道具 そこから実務で使う1億くらいまでの知識をどうやって増やすか 100くらいまでは⽇々つかう技術 その先、1万、1億と知識を増やしていくと使う頻度はどんどんまばらになる これはよく使う、これはほぼ使わない、これは1年に1回くらい使う、といった感じ そもそも本にまとまっていない技術もたくさんある 「執筆編」でこの分野の本が欲しいを話します

わからないことをわかる技術 最初のうちは本や資料などで⾃習して、「わかることを増やす」作業をしていく まばらになり始めた当たりからは同じ⽅法では効率が悪くなっていく そこからは並⾏して「わからないことをみつけてわかるようにする」作業をやると良い 「わからないことをみつける」ことは⾃分1⼈では難しい作業 なので、先輩からのコードレビューや質問、会話を通じて「わからないこと」を探 していくのがお勧め 特に、問題を解くためのコードを書き、それに対してコードレビューを受けることはと ても良い練習になる 実践的によくつかう技術の中で「まだ知らないこと」を学ぶことができる

わからないものに遭遇したときの対応⽅法例 3回とりあえず読んでみる 短いサンプルコードを探す 別の説明を読んでみる ⼈に聞いてみる（次のページから掘り下げます） 半年寝かしてまた読んでみる 参考: Web系上場企業CTOが考えるプログラミング初学者の学習について https://note.com/yoshikouki/n/n270610a5d4c6

質問できる場所を探す プログラミングを続ける限り、質問や議論をしつづけるのでその練習でもある 質問できる場所の例 ruby-jp Slack newbieチャンネル https://ruby-jp.github.io/ 回答されてる⽅々のオールスター感がすごい プログラミングスクール 私もフィヨルドブートキャンプやDAIMYOエンジニアカレッジで回答してます プログラミングスクールは次の2つを提供できると良いと考えている 「質問できる場所」、「分からないところを⾒つけてもらえる場所」 これをやるには現場⼒のあるエンジニアが必要なので⾼コストになるのが難しい 加えて、将来を⾒越して「コミュニティとつながれる場所」であるとより良い

質問する技術を⾝につける 質問スキルを上げる⽅法 いろいろ質問してみて、どんな答えが返ってくるのかふりかえりしてみる 「⾃分が望む問いが返ってくる確率が⾼いのが良い質問」 最初はこんな⾵に考えるとフィードバックサイクルを回せるかも いろんな⼈に聞いてみる 違う答えが返ってくるので多⾓的に学べる publicな場所での質問は、⾃分だけでなくみんなの役に⽴つ 折れない⼼

具体的な質問で考えてみる 例: Q.「オブジェクト指向がわかりません」 A.「わからないわかる」 「オブジェクト指向」が指すものが多すぎて何を知りたいのかが分からない もう少し分からない部分の情報を増やしてみる

オブジェクト指向がわからないがわからない問題 クラス、メソッドの⽂法と動作イメージがわからない Ruby超⼊⾨で練習 どんなクラスを作ればいいかが分からない Railsでは規約にのると楽できる Railsでどんなクラスを作るかはまずはモデルの設計から モデル設計はテーブル設計をするとついてくる テーブル設計は「楽々ERDレッスン(ISBN: 9784798110660)」で練習 URL設計がわからない RESTを「Webを⽀える技術(ISBN: 9784774142043)」で練習 良い名付けが分からない WEB+DB PRESS vol.110 「名前付け⼤全」 藤村さんの記事で練習 電⼦版買えます: https://gihyo.jp/magazine/wdpress/archive/2019/vol110

質問の答えがバラバラで困る問題 たくさんの⼈に聞くと正反対の回答を得たりもする 先⼈の回答は先⼈のコンテキストでの回答であることに注意 ⾃分にとってはあてはまらないことも多い 話半分に聞くべき 聞いて情報を集めたあとは⾃分で判断する必要がある 信頼のおける「よりどころ」から論理を組み⽴てて判断する

よりどころの育て⽅ 最初は先⼈の意⾒をよりどころにする 信頼のおける先⼈をどうやって探すか問題は難問 だんだんと以下の技術を判断のよりどころとして増やしていく 規格（RFCなど） 動いているソースコード 公式ドキュメント(次ページから解説) 作者の思想

Railsでわからないことがあったときの調べ⽅ Railsガイド https://railsguides.jp Rails公式ドキュメント。機能単位の解説。 調査にも便利ですが、全体⼀読しておくとRails⼒が上がります api.rubyonrails.org https://api.rubyonrails.org Rails公式リファレンスマニュアル。メソッド名から機能を検索。 Railsのコードに書かれた説明コメントがブラウザ上で読めるようになっています 慣れてきたらソースコードをgrepで探してから、Webへ⾏くと読みやすい ソースコードから読んでると関連コードも読めて便利です また、このページに載っていないメソッド群はRailsのプライベートAPIです プライベートAPIなメソッドは利⽤を控えるのがお勧めです

Rubyでわからないことがあったときの調べ⽅ るりま(Rubyリファレンスマニュアル) https://docs.ruby-lang.org/ja/ Ruby公式リファレンスマニュアル 辞書的な使い⽅のほかに、全体⼀読するのもお勧めです Array, Hash, String, Enumerableだけでも読んでおくと効果的 【宣伝】リファレンスマニュアルの使い⽅をRuby超⼊⾨ 5章に詳しく書きました るりまサーチ https://docs.ruby-lang.org/ja/search/ メソッド名などの⽂字列をるりまから検索できます Rubyソースコード doc/standard_library.rdoc に添付されているライブラリ⼀覧があります https://github.com/ruby/ruby/blob/master/doc/standard_library.rdoc

抽象と具象の旅 ある解決⽅法を持っていたとします それを完全⼀致でない別の問題を解くときに利⽤したりしますよね？ これは勘でやってるけど、なぜそんなことができるのかはそれほど簡単ではない 実はここで私たちは「抽象の世界」と「具象の世界」を⾼速に往来している 例: 「あ」という⽂字を認識するとき、明朝体とゴシック体で同じ「あ」だと認識できる ドット単位で完全⼀致しているわけではない 「あ」とは「この辺から線が始まってｽｯｽｯといってｼｬｯとしてる⽂字」 みたいな抽象化した理解をしている 新しいドットパターン（具象の世界）が出てきたときも、「あ」として認識できる 抽象の世界へ⾏くと適⽤範囲が広がる その代わりに、理解が難しく、適⽤⽅法と適⽤可能範囲を考えないといけなくなる

抽象と具象の旅 つづき 抽象と具象の旅はプログラマが毎⽇使う技術 その割に学び⽅が確⽴されていない どうすればいいのか？私も答えは持っていない ⽅法案: 具体例をいくつか集めて、当てはまるか当てはまらないかを分類する その境界線をみつけて⾔語化できるとかなり本質に迫れているのではないか 抽象 具象 抽象を往来して理解を深めている例 オブジェクト指向のカプセル化(抽象) attr_accessorを書いて公開してる(具象) カプセル化していない attr_accessorを書いてない(具象) カプセル化している 不要な公開をしていない(抽象)

⼼を⽀える技術 こんな悩みも出てくるかもしれません ⼀緒に学習していた⼈が優秀で同じペースで学習できない 若者が優秀でｽｯと追い抜かれる ⻑くプログラミングを学びつづけるコツは「⼈と⽐べない」、⽐べるのは昨⽇の⾃分 「アドラー⼼理学⼊⾨」 岸⾒⼀郎 ISBN: 9784584103128 1⽇1⽇⼩さい新しくできるようになったことを感じる技術を⾝につける こんなにもたくさん成⻑を感じるポイントがある仕事は希有かもしれません

⼼を⽀える技術 書籍 アドラー⼼理学 「アドラー⼼理学⼊⾨」 岸⾒⼀郎 978-4584103128 悩みの解決⽅法のレシピブック 「道は開ける」 デール・カーネギー 978-4422100524 原始仏教 瞑想 「反応しない練習」 草薙⿓瞬 978-4041030400 メンタルタフネス ストレスのない世界では⼈間は⽣きられない ストレスをうまく利⽤する⽅法 「メンタルタフネス」 ジム・レーヤー 978-4584391778

雇⽤形態の考察 就職前にアルバイトが活⽤できたらしていくべき 稼ぐことで持続可能になる 会社をよく⾒ることもできる 社員(正規雇⽤)かアルバイト(有期業務委託)かの違い プログラマはアルバイトでもそれほどデメリットがない（と思う） 転職先となる企業が多いため 「⼦供を保育園にいれたい」のようなケースでは関連してくるかも？ もしも1年以上同じ会社でアルバイトしていたら良い待遇（賃⾦or雇⽤形態）を求めよう

就職選考時に企業側が考えること 前提: 採⽤基準は会社によって全然違う なので落選したら「相性が悪かった」で かたよってるかもですが私が選考側で、対象者がビギナーレベルであればこう考えます どれだけの技術知識を持っているか（考えないわけではないが、⽀配的ではない） この⼈に対して既存メンバーがどのくらいの時間、どのくらいの割合で⼿助けするか 基本線（相性やお互いの⽬指す先の摺り合わせ）は確認済みの前提

就職時の⼒量の考察 どのくらいの⼒量を⽬標にするのか？ ⽬安: PRコメント3往復程でマージできるくらいの⼒量を⽬標に（厳しめ⽬標） 「この⼈に対して既存メンバーがどのくらいの時間どのくらいの割合で⼿助けするか」 PRやSlackでのやりとりがスムースにできるまで成⻑する⾒込みがあれば採⽤しやすい 参考: 「Railsエンジニアとして就職できるレベルとは」 https://docs.komagata.org/5494 多少の教育コストはかかるけど、トータルで⾒れば助かる なので、知識よりも実践的なやりとりの練習をした⽅が早くゴールできる仮説はある わからないところをわかるようにしていくプロセスの学びとその練習

第2部 執筆編 この分野を書くと良いのでは 既にある本は前述 収⼊と⽣態系 本の作り⽅ 書き⽅のコツ 今⽇は主に書籍の話をしますが、書く媒体としていろんな表現⽅法があります 書籍 Web 動画 それぞれ補完的

この分野の書籍・資料が欲しい2020秋 オブジェクト指向: 前述 デバッグ⼊⾨ ⾮同期実⾏⼊⾨ GraphQLをRailsで使う体系的な資料 push通知、メール送信基礎 Excelファイル読み書き （「退屈なことはパイソンにやらせよう」的な⽇常業務応援本） Web操作⾃動化、情報取得 (ferrum gemつかってみたい) 趣味全開本 本にも多様性が必要 同じ分野に本が何冊かあった⽅がいい

⾜りないものを埋めるか、売れるものを書くか ⾜りないものを埋めたいときに、売上と両⽴できれば最⾼ 「⾜りない分野だが、売れなそうなもの」を書くモチベーションを作れないのか たとえばそれを仕事とすることはできないのか エンジニアに執筆を仕事で頼むと書籍相場に対してすごく⾼額 だけどそのお⾦をなんとか⼯⾯できないのかと思う 答えはまだない 以前やった執筆スポンサー制度で⼀定の成果はあったので別案を考えていきたい 採⽤の道筋を⽴ててスポンサーを募る？（カンファレンススポンサーのような） 「御社課題の資料を作成して勉強会開催」を業務にして、その資料の権利をもらう？

私の書籍での印税⽐較 RubyとRailsの学習ガイド 個⼈(BOOTH) 500円 電⼦版 BOOTH⼿数料 5.6％+22円 #=> 印税約90% Railsの教科書 商業(達⼈出版会) 1100円 電⼦版 #=> 印税約50% Ruby超⼊⾨ 商業(技術評論社) 2728円 紙版 商業誌紙版の印税は⼀般的に5〜10%を全著者で分配。電⼦版印税は把握難。 パーフェクトRails 商業(技術評論社) 3828円 紙版 印税⾦額(1冊当たり): Railsの教科書 ≅ 学習ガイド >> Ruby超⼊⾨ > パーフェクトRails 販売数: Ruby超⼊⾨ > パーフェクトRails >> Railsの教科書 ≅ 学習ガイド 総利益⾦額: だいたい同じ。期間の短いパRailsを除くと2倍程度の差に収まる。 参考: チェリー本筆者 伊藤さん記事 https://blog.jnito.com/entry/2020/11/25/074822

商業出版と個⼈出版 商業出版 利益: ⼀般的に販売売上の5〜10%を全著者で分配 たくさん売れる、印刷技術が⾼くきれい 要求品質が⾼いため執筆時間かかる、出版後の修正がしづらいなどの制約 個⼈出版 利益: ⼿数料を差し引いた残り(電⼦版なら売価の90%程を得られる) 修正や改定をコントロールできる、販売広報は難しい ⾃分で権利を持って活⽤できる Railsチュートリアルと提携(今⽉) https://codezine.jp/article/detail/13209 DAIMYOエンジニアカレッジ Rails基礎コースで「Railsの教科書」読書会開催(今) https://daimyo-college.pepabo.com/

個⼈で書籍を書きたいとき 販売⽅法編 BOOTH(個⼈出版): ⼿数料 5.6％+22円 #=> 印税: 約90% 電⼦版（フォーマットはPDFほか⾃由）で売るのはすごくかんたん 紙版は⾃宅から発送 or ⽉1100円で倉庫発送（発送まで全⾃動で便利） Zenn(個⼈出版): ⼿数料 約10%+3.6% #=> 印税: 約87% markdownで書けば公開、販売できてすごくかんたん 短く書いて、売れるかどうかの調査もできる 技術書典はめちゃめちゃ売れる 物理開催の⽅が売れるが、オンライン開催でもそれなりに売れる 特に紙版がすごく売れる（オンライン開催でも同じ傾向） 紙版をコストをかけて刷るか刷らないかの判断 技術書典、すごく良い場所だと思うので技術季報を⾼く買って応援してます 次回 技術書典10 年末年始開催 申込〆切11⽉末 https://techbookfest.org/

個⼈で書籍を書きたいとき 製作編 markdownで原稿を書く ReVIEWでPDFを作る 例(私の利⽤ツール): Re:VIEW Starter https://kauplan.org/reviewstarter/ VivliostyleでPDFを作る メリット: CSSを使って組版できる デメリット: ブラウザがバージョンアップすると⾒た⽬が変わる Dockerでブラウザのバージョンを固定した環境をつくるなどしておく 物理本を印刷所で刷るときもPDFベースでいける 調整は隠しノンブル(⾒えない所へページ番号出⼒)付与くらい(印刷所の技術に感謝) 私は技術書典に持ち込みやすい⽇光企画さんを利⽤してます pixivFACTORYさんだと印刷所横断検索ができます 組版のノウハウがなければ、達⼈出版会に持ち込むのも⼀⼿ 組版は技術書典コミュニティへ⾏くと詳しい⽅がたくさんいます

商業誌で書きたい⽅へ 機会を得るためのポートフォリオ替わりに個⼈で何か書いておくとよい 商業誌の著者は燃え尽きがち 次の執筆を誰かに任せられないか⻁視眈々と狙っている 既に何か書いている⼈だと執筆の話があるときに推し易い 儲けが少ないので、ほかのメリットと組み合わせてなんとかモチベーションをつくる ⾃分ブランド向上など

書き⽅のコツ 以降で説明していきます 紙⾯の都合で今⽇説明しきれないことをここに書き残しておきます 書き⽅のコツ 話さないこと 読み続けてもらうためのモチベーションを意識する スタート地点を決める: どの層の⼈をターゲット読者にするか スタート地点によって想定前提知識が決まってくる ゴール地点を決める: この本を読み終わったら何ができるようになるか ゴール地点を決める⽅がスタート地点よりも難しいと思う

わかりやすい説明は分解と順番が⼤切 ⽂章⼒、国語⼒は⼀定レベルで成果物への分かりやすさ寄与が飽和する感じがする 順番の⽅が分かりやすさ寄与が⼤きいのでは仮説 詳しくは以下で話しました とちぎRuby会議09「考えるのはたのしい」 資料: https://speakerdeck.com/igaiga/tork09igaiga

本はDRYに書いてはいけない ⼀度⾔って伝わるのは30% ⼤事なことは繰り返し⾔う必要がある とはいえ紙⾯に限りもあるし、伝わった⼈には邪魔にもなる ばれないようにいかに繰り返すか 逆の⽴場で、読む時に「なんかこれよく出るな」と思ったらそれはたぶん⼤事

本に書かないことを決める 「書かないことを決める」のはとても価値がある⾏為 書くことを増やすのはかんたんだが、減らすのは難しい 読み⼿が費やす時間を減らし、得る内容を集中させることで理解を深めることができる 「書かれていないこと」の理解処理を読み⼿の未来へ遅延⾮同期実⾏させるイメージ 「説明する」「外部資料引⽤して⾔葉だけ説明」「触れない」と段階を追って落とす 書かれてないことは「必要ない」ではない 「この本に書かれたことよりも現在は重要度が低い」なことに注意 詳しくは以下で話しました おつかれシャワー(june29 Vlog) #095 さまざまな学習スタイル https://youtu.be/vIwyyqb1WOU

⼈間は全て別の処理系 ⾃分処理系で動いても、他の処理系では動かないことがある コードは多処理系対応するのに、⽂章は多処理系対応しないんですか？(煽り) 教えること、本を書くことの上達にはたくさんの処理系の情報収集をすると良い 質問するときにも、回答が⼈によって違う前提を利⽤しよう 複数処理系の結果によって複数の知⾒を得られる

多くの処理系を知る良い⽅法 ruby-jp Slackで質問に答える フィヨルドでメンターやる ときどき募集してます フィヨルドはコミュニティ 受講⽣、メンター、野良メンター（関わりある企業の⼈たち）らが集まる場所 受講⽣を含むメンバーたちによる継続的なカリキュラム改善 Rubyコミュニティの「⾨」の1つに育ちつつある(個⼈の感想です) ⾓⾕さんの講演動画: https://fjord.jp/articles/2020-09-14.html

第3部 教育編 説明のコツ 次の3つを話します 相⼿が前提で持っている知識を確認する 「型」と「実践」に分解して理解して説明しよう 受信バッファに収まるように全体イメージを活⽤する 達⼈プログラマー 第2版 「7.伝達しよう」に良いことがたくさん書かれています https://tatsu-zine.com/books/the-pragmatic-programmer-2ed 企業での教育について 私が技術顧問業をこんな感じでやってますの経験談【宣伝】

相⼿が前提で持っている知識を確認する 答えを理解するのに必要な、質問者が事前に必要とする知識を考える 必要ならいくつか質問をして、質問者がそれらを持っているかを確認する 説明のスタートラインを決めていくイメージ 本ではできないが、1:1なら処理系ごとの動的な分岐ができる ⼈間は全て別の処理系であることを忘れない

「型」と「実践」に分解して理解して説明しよう 学ぶ⼈、教える⼈へ向けた、説明のコツの話 「型」と「実践」に分解して理解して説明しよう 型: 抽象化されている有⽤なパターン 実践: (複数の)型による⾏動と判断の過程 (例)テニス 「型: ラケットの持ち⽅、振り⽅」「実践: 実際に振ってボールを打つ」 RailsDM講演 2018/03/25「知性の習得」で詳しく話しました 資料: https://esa- pages.io/p/sharing/4060/posts/696/32c79c339c3a2e476ceb.html 動画: https://youtu.be/GqiIF_3RyU8

型と実践の例 if wallet.overflow! do_something end 使った型: 「重要なコードを先に書く」 使わなかった型: 「コードは短い⽅が全体を読みやすい」 実践: 型「重要なコードを先に書く」を優先して、型「コードの短さ」よりも先に書いた 財布があふれる喜びを表現していると解釈できる wallet.overflow! でnilが返ってきたらすごく悲しいですねこれは・・・ もし喜びが強調不要なら、天秤が逆になり、コードの短さ優先で後置ifで書くだろう

「型」と「実践」に分解して理解して説明しよう ⽇々の型と実践の「結果」は観察できる ある実践には、複数の型がそれぞれ違う重みで⽤いられる たいていの場合、重みづけは⾒えづらい つかわれなかった型も⾒えづらい 重みによる判断の結果、ある特定の型と反することをしているようにも⾒える メンターは、⾃分が、またはメンティーが使った型と重み付けを説明していこう メンティーはPRコメントの指摘をこれで分解してみよう 型はわかりづらいこともある そのときは聞いてみよう

受信バッファに収まるように全体イメージを活⽤する 例: 「AとBを⽐較して、結論はAが良いなんだけど、理由が3つあるので順に話すね」 最初に全体を⾒通せるように話すと聞く側が受け取りやすい 受信側は脳内にゼロから展開するので、受信バッファの利⽤メモリ量が多くなる 全体図があると、使⽤する脳内メモリ量を減らせる（気がする） 受信メモリ量は有限 直接関係ない話は結論後に様⼦を⾒ながら話したり、後⽇にするのが理想 博物館の順路を⾒せるようなイメージ 送信側はアドリブで説明全体のイメージを設計する必要があるので、がんばる このページもこの技を使ってみましたが、理解しやすかったでしょうか？ 受信側も整理しながら聞いたり、紙に書き出しながら聞くとたくさん受け取れるかも

説明のコツをいくつか紹介しました 前提で持っている知識を確認する 「型」と「実践」に分解して理解して説明しよう 受信バッファに収まるように全体イメージを活⽤する 学ぶときはこれらの裏返しを考えてみる 前提で持っている知識を提⽰する ここまで調べてこう考えている 「型」と「実践」に分解 判断結果に対する根拠と重み付けを聞く 受信バッファに収まるように全体イメージを活⽤ 全体を整理しながら聞く

企業での教育について 他の⽅法と⽐較して「社内で活躍している状態」から逆算で設計できるメリットがある ⾃社で有⽤な技術を優先して学習できる ⾃社で使わない技術を省略したり後回ししたりできる 現実的なコストでどうやって成⻑環境を作っていくか 研修設計者の腕の⾒せどころ 【宣伝】私を呼んでください 成⻑環境がないと採⽤活動でも不利になっていく 企業の魅⼒を上げられない

企業での研修設計 受講⼈数が少ないうちは、教材づくりよりも練習や議論に時間を使う⽅が得な気がする 教材づくりコストは受講⽣が多ければスケールする 教材づくりは更新コストも考慮する必要がある 書籍や外部の資料を利⽤すれば更新コストを節約できる コストを考えると外部講師に有料講義を頼む⽅が安いこともある 【宣伝】フィヨルドブートキャンプでも企業向け新⼈研修やってます 得意な分野は⾃社で教えて、苦⼿な分野は外部にまかせるのもコスパ良い Classiさんで新⼈教育設計をやっている経験から 外部講師を利⽤しつつ、コツコツ社内で教育できることを増やす 研修をやってくれる仲間を社内に増やす 4期やったら随分充実してきました

採⽤、教育、評価はつながっている 社内評価で会社の求める技術をメンバーへ伝える メンバーと会社のインセンティブをすり合わせていく 教育と評価の結果を採⽤にフィードバックする 採⽤基準へのフィードバック 採⽤後のn年でこういう仕事をされていますの実績を求⼈ページに書ける 採⽤可能範囲を広げるために、教育可能スキル範囲を広げていく ⼊社前にアルバイトで働いてもらう作戦も⼀⼿ 企業は採⽤候補者のことを良く知り、教育のお試しもできる 採⽤候補者はスキルを磨いて給与を得られ、企業のことを良く知れる 第1部学習編ゴール「アルバイトや就職でRailsの職を得る」の先の世界を作る仕事 採⽤基準ラインを下げていって、今よりなめらかな世界をつくりたい そんな開発組織を作りたい会社さんとぜひお仕事⼀緒にやりたいです

【提供】 RMHさん 【宣伝】そんな感じでエンジニア組織を⼀緒につくっていきませんか？！ 1⼈⽬の社員エンジニア(テックリード候補、CTO候補)募集中 CTO⼒補佐 Voyage Group CTO ⼩賀さん、私 Railsテックリード⼒補佐 フリーランス松尾さん、私 私はここで数年かけてRailsエンジニア組織をつくっていきたい 新しい場所に0からRailsエンジニア組織を⼀緒に作ってくれる⼈を募集中 「RMH」と書いてカジュアル⾯談を希望してもらうか、または私まで連絡ください https://hrmos.co/pages/voyagegroup/jobs/0000044

No content