1. DevRel/Radio
  2. DevRel/Radio #155 〜私の学習..
2024-03-15 1:04:01

DevRel/Radio #155 〜私の学習法〜

エピソードをシェアする

Share on X Share on Facebook Share on Threads

DevRel/Radioは耳だけで楽しめるDevRelコンテンツです。リスナーの方々からの投稿を大募集しています

155回目となる今回のテーマは「私の学習法」です。新しい技術について学ぶとき、あなたはどんな方法で学んでいますか?ブログ記事、学習サービス、書籍、コミュニティなどなど…あなたが普段行っている学習方法について教えてください。


紹介したニュース

00:04
はい、みなさんお疲れ様です。夕方5時半になりました。DevRel Radioのですね、今日は155回目をお届けしていこうと思います。
まず最初にですね、DevRel Radioの紹介です。DevRel Radioはですね、DevRel Tokyoというコミュニティでやっているネットラジオになります。
毎週火曜日夕方5時半からですね、1時間ぐらいお届けしているというものになります。
DevRelっていうのはですね、Developer Relationsの略で、自社とか自社製品と外部の開発者との間に良好な関係性を築くためのマーケティング処方となっております。
DevRel Tokyoではですね、そうしたDevRelに関わるとか、興味がある方々が集まって情報交換したりしているコミュニティとなっております。
公式サイトがありまして、そちらからスラックに参加することができます。公式サイトのURLはDevRel.Tokyoとなっております。
あとはそこまでDevRelに関わってないよという方はですね、公式のXアカウントがあります。
普段はハッシュタグ、シャープDevRelJPっていうのをつけてですね、ツイートじゃない、投稿していたりしますので、ぜひそちらの方もウォッチいただけるとありがたいですというところですね。
何回かですね、スポーカーしてたんですけれども、このDevRelラジオですね、3周年を迎えたの。
あれ?そうですね。3周年を迎えたんですよ。
このラジオが始まったのがですね、3年前ってことかな?
全然自分でもあんまり覚えてないんですけど、この間ふと見たときにそうかもと思ったんですよね。
1回目をやったのが2021年の3月3日ですね。
なので本当は前回が3周年を迎えたっていう話だったと思うんですけれども、
いつも通りスポーカーしつつですね、3年前2021年の3月3日に始まったこのDevRelラジオですね。
ほぼほぼ年末年始ぐらいですかね、やってないので。
それ以外は毎週、昔は時間が違ったのかな?水曜日の5時とかにやってたようですね。
途中からこの火曜日の夕方5時半に変わってですね、
なんだかんだ3年、丸3年やっているというところですね。
まだ4年目もですね、相も変わらず単調にやっていければなと思っているんで、
03:04
引き続きよろしくお願いいたしますというところですね。
今日はですね、メインテーマが私の学習法となっております。
皆さんがですね、新しい技術を学んだりとか、新しい仕事上で役立つものとか、
学校生活で役立つものとかですね、そういったものを学ぶ際に、
どういう風な工夫をしているかというのをですね、ぜひ聞ければなと思っております。
一時期、2000年ぐらいの時とかですかね、
基本的に新しいものを学ぼうと思ったら、書籍で学ぶのが当たり前だったと思うんですよね。
たぶん95年とか、そこから99年ぐらいまでって、
あんまりマニアックな書籍って日本語で出てなくて、
大抵用書とかで買って読んでたのかなっていう気がするんですよね。
それこそAmazon.comとかで買えるようになって、
それでも英語の書籍買って技術の仕様とか調べてたと思うんですけど、
そこから2000年になったぐらいから、
その頃オライリーの日本語版とかすごく出始めて、
日本語の書籍、技術上とかすごく増えたイメージがあるんですよね。
書籍で技術学ぶのが当たり前だったような気がするんですけど、
ブログとかが出始めてインターネット上にすごくコンテンツが増えていったらっていうのと、
あとなんとなく技術のキャッチアップが早くなって、
書籍だと待ってらんないとか、書籍が出る頃にはもうちょっと古くなってるみたいな感じがあったりして、
書籍から学ぶっていうよりは、
Webのコンテンツ読んだりとか、学習サービス使ったりみたいな、
そういう流れになったのかなっていう気がするんですけど、
ここに来てまた書籍が、技術書店とか技書博とかの影響もあって、
商業出版もありますけど、
同人誌的な書籍とかで学ぶようになっている人も多いんじゃないかなっていう気がするんですよね。
そこまでじゃなくてもe-pubとかで学べたりもするんで、
今いろんな学習方法ってあったりすると思うので、
ぜひ皆さんが使っているとか利用している学習方法があれば、
教えていただきたいなというところになります。
もうすでに何件かいただいているかな。
06:02
すでに何件かいただいているんですけれども、
ぜひ皆さん、今のうちに学習方法を工夫していることであったりとか、
利用しているものとかあれば、教えていただければと思っております。
多分まだ30分ぐらいありますんで、ゆっくり考えながら投稿いただきたいなと思います。
ということで、まず最初にですね、
最近のDevRel界隈のニュースを取り上げられればなと思っているんですけれども、
まず最初が、
こないだJaws Daysがあったと思うんですけれども、
その時に出ていたAWSのデッキ構築カードゲーム、
AWS Builder Cardsが日本語かという記事がこちらが、
ITメディアさんかな、記事になっております。
いいですよね。
カードゲームとか、ゲームを通じてテクノロジーを学んだりとか、
深く学ぶっていうよりは、まず入り口としてですね、
技術めんどくさいみたいな感じのイメージを持たれないように、
カードゲームを通じて学ぶって結構いいと思うんですよね。
でもこれ確か販売はしていないんですよね。
多分特別版だったのかなという気がするんですけれども、
このゲームは、もう公式なんですね。
AWSがカードやルールを作成し提供している、
遊びと教育を目的としたデッキ構築ゲームですと。
AWSマーケットプレイスに見立てたシャッフルしたカードの山から
カードを引くなどして集めた手元のカードで、
コストが小さくメリットの大きいような
ウェルアーキテクティックなシステム構築を競うということですね。
これはいいですよね。
カードの例では、左上の黒い丸の中に
取得にかかるコストの値。
上部の中央にサービスの名称とカテゴリー。
あとはカードの中央にアイコン。
アイコンの右下には黒い丸の中にTCO、
トータルコストオーナーシップを示す数字。
最後にオレンジの丸の中に
AWSカムクレジットと呼ばれる数値を示す数字などが、
その他には他のサービスと組み合わせたときの
効果などが記されているということですね。
09:04
結構、どうなんでしょうね。
覚えるのが大変そうなんですかね。
こういうのを通じてAWSの基本みたいなところとか、
使いこなしみたいなのが学べるといいですよね。
ここまでAWSだけでサービスの数がめちゃくちゃ多いので、
だからこういうカードゲームが成り立つという気はするんですけれども、
同じような感じでできるといいですよね。
なかなかこちらもDevRel東京でゲーム作りたいとか考えているにも関わらず、
なかなかできてないんですよね。
しかも前回もあれがありましたよね。
テーブルトークRPGの話。
なんだっけ。
具体的にどういう話をしていたかっていうのをすっかり忘れてるんですけど、
なんだっけ。
確かPHPカンファレンスの話からでしたっけね。
PHPカンファレンスの参加者に、
ビックリマン風のキラキラのシールが配られたっていう話から来てたんだったかな。
それでサービスのポケモンカードみたいな話をしてたような気はしますね。
そういうのもただ作るだけではなく、
ゲームとして遊べる工夫とかがあるといいなと思うんですよね。
同じようなただのカードっていう意味では、
CMXサミットでコモンルームが配っていたカード。
確かDevRelConでも配ってたかな。
そういうカードですね。
そこにキャラのイラストがあって、
あれはあれで集めてる人がいましたけど、
どうせ集めるんだったらゲームとして遊べると楽しいのかなっていう気がしますよね。
それはコミュニティとかそういう企業のそれごとに違っていて、
集めるとコレクターにもなれるし、遊べるしみたいな感じになっているといいかなとは思いますね。
難しいんですけどね。
アイディアがある方がいらっしゃったらぜひ教えていただけると嬉しいですね。
ということで続いてなんですけれども、
こちらもJaws Daysからですね。
Jaws Daysの1個セッションで、
技術書を書く技術という記事ですね。
12:02
これを書いているのが佐々木卓郎さんですね。
NRIネットコムの方になります。
執筆した書籍が本当に多いですね。
Amazonウェブサービス関連がほとんどで認定に関わる本とかですかね。
すごくたくさん書籍を書かれている方になります。
我々はなぜ本を書くのかというところで、
執筆に本を書くとですね、印税の話が必ず出るかなという気がするんですけれども、
だいたい時給換算でいくと600円から800円ぐらいみたいな感じらしいです。
実際日本には専業の技術書の著者はほとんどいないと。
そうですね、昔テクニカルライターみたいな職業ってあったんですよね。
でもこれ結局メディアの方とかとも話したことあるんですけど、
もう今ほとんど成り立たないですね。
テクニカルライターで成り立つのって、
イベントとかで書いている方ぐらいですかね。
それでもイベントについて書くぐらいで、
多分技術的なところっていうのが本当にキャッチアップが早いというか、
深い洞察書くにはなかなか難しい領域だったりするんで、
現場で働いているエンジニアの方とかに書いてもらって、
品質は当然テクニカルライターの方に比べると劣るんですけれども、
それを編集の力でコンテンツとして仕上げるみたいな方がいいっていうのは聞いたことがありますね。
なので専業の技術者の著者っていうのは今ほとんどいないというのも書いてあります。
それでも時給換算で相当低いというところはあるんですけれども、
それでもなぜ書くのかということですね。
ペイトファードということで、自分の知識を誰かにつなぐためなのかとか、
あとはその分野の有名人になりたいからとか、
あとは復習に追えたいのかとか、
あとは自分の名前を冠した本を書きたいとか、挑戦してみたいとかですね。
理由があろうがあるまいが世の中に本を書いてみたいという人は尽きないと書いてありますね。
これは確かにそうだと思いますね。
まず大事なのが本の企画を作る部分ですね。
潜在読者市場を考えると一番いいのはまず初心者が多いことと、
15:01
あとはカテゴリー内に日地市場が存在するかどうかというところを挙げてますね。
そうですね、初心者の方が当然市場のパイは大きいですし、
あとは例えばAWSだけで考えたとしても、
構築とか運用はそれなりのパイがある中でIAMとかは、
あとはここで上がっているのはオーガニゼーションとかですかね、
そういうのはすごく日地で攻めるべき価値があるということですね。
市場の大きさを取るかシェアを取るかというところで、
日地な市場でオンリーワンと大きな市場で競争と、
どちらも戦略としては成り立つんじゃないかというふうに書いてありますね。
ちゃんと商業出版に載せる上では市場がちゃんとペイできるかどうかというのも
考えていく必要があるよということを書いてあります。
例えばここでは実際の企画書の例も上がってますね。
Amazon Web Serviceパターン別構築運用ガイドという書籍のときには、
潜在読者、目標部数、対象の想定、対象レベルというのを
きちんと編集者と共有するというところが書いてありますね。
それが企画の概要が整ったら、次は目次に落とし込んでいくと。
タイトルを置いて、章、節、構と詳細化していくと。
簡単な説明を付け加えて、あとはページ数の想定を入れていくと、
ここまでいってようやく企画が完了するということですね。
執筆のフェーズなんですけれども、
ツールについては特にこだわっていないというところもあるんですけれども、
商業紙であればマークダウン、技術同人誌であればレビューがおすすめというふうに書いてありますね。
白紙のファイルから1行目を書くのが一番難しいと。
その心理的な負荷を下げたりとか、
あとは最近だったらChatGPTに相談しちゃうということですね。
前提条件を書くとそれっぽい文章が返ってくるんで、
そうじゃないんだよと考えながら直していくことで原稿は進んでいくということですね。
これなんかわかる気がしますね。
原稿が書けたら構成をかけていくと。
例えばテキストリントであったりとか、あとChatGPTでやるという方法も書いてありますね。
出版社のビジネスモデルを考えると、
書籍の制作費っていうのは初版の部数と販売価格をかけたものだと。
18:01
増刷しないと出版社の利益はほとんどないということですね。
これはライター側としては、執筆者側としてはなかなか考えづらい部分かもしれないですけれども、
ちゃんと考えないといけないと思いますね。
初版数はどんどん少なくなってきていて、ビジネスモデルが変わってきている可能性もあるということですね。
著者としても初版を売り切ることが何よりも大事であるというふうに書いてあります。
宣伝するときには、それに関してですね、著書に関してブログを書いたり、
SNSで宣伝したり、あとは書店でポップを書いたりということですね。
そういった執筆にかける労力の10分の1は費やすくらいの覚悟でやるべきというふうに書いてありますね。
企画なんですけれども、2つの方法がありますと、
出版社主導でやる場合と著者主導でやる場合の2種類がありますということですね。
その意味でもブログであったりとか、技術常人誌で実績を積んでいることが重要であるというふうに書いてあります。
Intelさんの技術の泉シリーズって今もうなくなっちゃったのかな、すみません、ちょっと覚えてないんですけれども、
DevRel Tokyoで書いて、技術書店で出している本とかでAmazonのところに載っている本とかは、
その技術の泉シリーズっていうので出してもらっているケースがほとんどなんですけれども、
この場合は中の方々がですね、技術書店であったりとか技術書博とかに足を運んで、
そこで面白そうな本とか売れてそうな本があったら、
その著者の方にコンタクトしてですね、商業出版にしませんかっていうのをご連絡しているというふうに聞いてますね。
実際我々もそうやって声をかけてもらったりしてますね。
なのでその意味で技術同人誌とかですね、そういう実績が目に見える形で出ているとですね、
お声掛けしてもらいやすいのかなという気はしますね。
あとは技術同人誌に関してですね、印刷どうすんのとか販売どうすんのみたいなことも書いてあったりします。
Jaws Daysということもあるんで、AWS本を書くとしたらというところが書いてあります。
まず市場の特性、AWSというところを見るとですね、マーケットはとても大きいと、
ただ技術の変化のスピードがとても早く、書籍の寿命は短くなりがちであると。
これは考えないといけないポイントですよね。
再分化したターゲットであったとしても市場としては十分成り立つと。
21:01
なので技術同人誌の人気の分野だということも書いてあります。
チャンスは大きいので、再分化してあったとしても、ニッチを狙ったとしても十分に大きな市場があるので、
そんなに大きい市場、大きいパイを取らないようなテーマでもいいよということですね。
あとは陳腐化が早いので、同一テーマであったとしても後発の参入余地がそれなりにあるということですね。
本を書くには普段からの素振りが必要だと。
これはブログであったりとか、そういう同人誌を書くとかですね。
そういったアウトプットを心がけておく必要があるのかなと思いますね。
チャンスがあれば躊躇なく打席に立とうというふうにも書いてあります。
アウトプットという意味でもそうですし、書籍をそれなりに書いていくという意味でもですね。
キャリア上もかなり大事なポイントかなという気がするので、なかなか知見にあふれたスライドかなと思いますね。
技術書を書く技術というお話になります。
コメント来てますね。ジャニーマンさんから。
さっきのスライドの佐々木さんですね。執行役員になられましたということですね。
書籍を書くことだけがそれにつながったとは全然思わないんですけれども、
それなりに知見がある方じゃないと書けないと思いますので、
それが回り回って執行役員になられたとしたらとても素晴らしいことですよね。
では続いてですね。こちらは禅の記事なんですけれども。
タイダな人向け技術ブログの続け方ガイドというのが書いてあります。
いいですよね。プログラマーはタイダじゃないとダメだと思うんで。
技術ブログの続け方ガイドとしてですね。
これはドラゴンTAさんですね。
ITベンチャー企業で半年間働いている駆け出しエンジニアですということで、
エンジニアで働く上でテックブログを続けるためのモチベーションの保ち方を記事にしてみましたということですね。
ここにGoogleのサジェストが書いてあるんですけど、
技術ブログの後ろにスペース入れると一番上に出てくるのは技術ブログめんどくさいらしいですね。
本当かな。みんなめんどくさがってるんですね。
そこでめんどくさがりな僕たち向けにテックブログの続け方をノウハウとしてまとめてみましたというふうに書いてあります。
24:02
まず一つ目のポイントとしてですね。
書学的なところも書いてみると。こんなの書いても誰のためにもならないんじゃないのということも書いてみるのが大事ですということですね。
思い出してほしい。勉強を始めたとき、記事を読み漁って分かんないな、これじゃないなといろいろ見てきたと思うと。
その中で分かんない記事に対して、何なのこの記事、もっと優しく書けよなこの野郎と思うこともあっただろうかと。
おそらくないはずである。大抵まだ自分にはレベルが足りてないなと思うだけであると。
だから安心して書学的な内容であっても記事に書いてほしいと。
その記事はきっと誰かの役に立っているし、何なら自分のためになっているからと書いてあります。
続いて二つ目ですね。自分のためになることを意識すると。
これやっぱ大事ですよね。どこでアウトプットの大切さみたいなものを書いてる記事とかでも、やっぱり基本的に自分のためですよね。
未来の自分のために書いているところはかなりあるかなと思いますね。
同じところでつまずいてるっていう意味ではあんまり成長してないのかもしれないですけど、半年ぐらい経ったりすると忘れちゃいますもんね。
そのときにググったときに自分の記事が一番上に出てきて、これ役に立つなと思ったら自分のだったみたいなのは誰しも経験するのかなと思いますね。
そして三番目、ご褒美を用意すると。ご褒美とは何なのか。そう、寿司であるということですね。
毎月○○本技術記事を投稿したらみんなでうまいもん食いに行きませんか。これがモチベーションに火がつくきっかけとなると。
もちろん慈悲では意味がないと。それは浪費である。あくまでも組織としてご褒美を用意することに意味があると。
ここでそんな無駄な経費の使い方できないよという組織も出ると思う。
だが考えてみてほしい。記事を書くということはそれだけ意識的に社員がノウハウや技術を学習していくことになると。
それらのことに慣れ、学習とアウトプットの癖がつき、社員に技術共有を行えるのは会社としても十分利益なのではないだろうかと。
技術が身につけば通常業務のアウトプットの質も大きく変わるはずと。
実際にアウトプットの癖がついているエンジニアの市場価値は高いということで、
技術ブログがちゃんと書いている会社は寿司を社員におごるべきだということですね。
小田翔さんからコメント来ていますね。
ご褒美、新品のキーボードかなと。
27:01
そういう壊れないものはプレゼントしちゃダメですよね。
それ1回もらったらもう数年間ブログ記事書かなくてもいいじゃんってなっちゃうんでね。
すぐその場で消費できるものがいいですよね。
寿司はいいのかどうかというのはわからないですけど、
でも寿司嫌いな人いないですよね、きっとね。
具材はそれぞれ好みがあるかもしれないですけど。
4つ目ですね。質を重視しすぎない。
ノート代わりにしちゃえと。
もはや記事を書く意識ではなくノートとして使ってみると。
自分のためのノートを書いてみて公開しちゃえくらいの気持ちでいいと思うと書いてありますね。
確かにね。その意味ではバイネームで公開する意味ってそれほどないのかもしれないですね。
バイネームじゃなかったらもっとアウトプットの敷居が下がる人もいるのかなという気はしますかね。
バイネームでやりたい人は当然バイネームで問題はないと思いますし、
いざとなったらシステムの内部的には誰が書いたかっていうのはわかっていても、
それをアウトプットするときには名前を消すとかいうのは全然いいのかなと思いますね。
どうなんでしょうね。私とか別にそんなに記事書く承認欲求とかないんで、
名前出てなくても別にどうでもいいかなっていう気はしますかね。
続いて5つ目ですね。アイデア記事のほうが書きやすかったら書いてみて、まず投稿になれるということですね。
技術記事難しいよっていう人もいると思うと、そういう方は全能アイデア記事から始めてほしいと。
アイデア記事はこのブログの記事のように働く上でのノウハウや考え方なども記事として成立すると。
アイデア記事でアウトプット経験を積めばアウトプットに慣れてくるでしょうと。
いずれ記事や気が向いたら技術記事にチャレンジしてみるといいと思うと。
形はともあれまずアウトプットするということが大事だというふうに書いてあります。
そして最後は楽しむことを忘れないということですね。
アウトプットが苦痛に感じてしまったとしたら、当然アウトプットする意欲はないのかなという気はしますよね。
ということですね。
この方もまだ癖がついてない段階なので、アイデア記事を中心にノウハウや技術記事を書いていこうと思うと。
30:04
いずれ呼吸のように技術記事を書いているはず。
まずは苦手意識がなくなるまで書いてみるぞというふうに書いてあります。
何でしょうね。永遠のテーマ感がありますね。
こんだけアウトプット大事とかアウトプットはいいぞって言っている人がいる中で、
常に一定のアウトプットしない苦手っていう方もずっと存在するわけで、
これは当然いるのは全然アリだと当然だと思うんですけれども、ずっと言い続けてますよね。
何なんでしょうね。不毛な戦いのような気もするし、ずっと言い続けられるものなんですかね、今後も。
どっちかに決着してもいいような気がするんですけどね。
小田翔さんからコメント来てますね。
今日寿司頼んだら頼んでもない寿司が来たと。
どういうこと?2人前来たと。1人前頼んだら2人前来たんですかね。
それは向こうが気遣ったんですかね。
ジャニーマンさんからは消え物をおすすめと。
そうですよね。やっぱり食べ物であったりとか。ピザは見た目に安っぽいかなっていう気がするんで。
焼肉か寿司かな。それ以外何かあるかな、ご褒美として。
甘いものとかも好きな人もいますけど、逆に苦手な方もいらっしゃるんで、難しいかなっていう気がするんで。
個人的にはやっぱり寿司ですかね。
じゅんさんからコメント来てますね。
雇用が永久とかの場合、外にアウトプットしなくてもいいんでしょうなって書いてありますけど、
まず雇用が永久っていうのはあり得ない、ほぼほぼ現代では難しいのかなっていうところと、
逆に研究職の方とかでずっとある意味アンパイになっている方とかも、
研究でアウトプットするっていうのはもう習慣づいていたりするんで、
雇用が永久だからアウトプットしないっていうものでもないのかなっていう気はするんですよね。
それこそ超昔のギリシャ時代とかって、
普通に奴隷の人たちが働いて、ギリシャ人とかは非がな哲学について考えたりとか、数学について考えたりとかして、
33:01
それはそれでアウトプットしていたりするんで、
自分の置かれている状況とは違うような気がするんですよね。
クビになりそうだからアウトプットするっていうのも結構やばいですよね、考え方としてはね。
何でしょうね、アウトプット論争ずっと続いてるなっていう気がしますね。
今後も続くんですかね。
しょうがないですけどね。
では続いて、あと1件ぐらいいけるかな。
あれ、記事がなくなってしまった。
今日はAWSついてるな。
これもAWSの話だな。
全の話でUdonにAWS、お前にAWSは必要ないという記事が出ていますね。
実際そうですよね。これなんかちょっとわかる気がするんですよね。
何でもかんでもAWSっていうのも良くないというか、
盲目的にやる必要はないのかなっていう気がしますし、
別にそれはAWSじゃなくてGCP選べとかそういう話ではなく、
必要なシステム、要件に合わせてアーキテクチャを正しく選んでいくべきなのかなっていう気がしますよね。
フロントエンドとして、代替として書いてあるのは、
例えばバーセルであったりとか、
あとはクラウドフレアとかネドリファイとかも上がっていたりとか、
あとバックエンドに関して言うと結構ありますね。
RenderFly.io、Railway、これちょっと読まないな。
こえびなのかなとか、サイクリックとかディータとかですね。
そういったものが上がってますね。
データベース系は最近だとプラネットスケールありますけど、
プラネットスケール無料枠なくなったみたいな話がどっかで記事で見たような気がしますね。
あとこれ知らないな。
Torsoなのかな。
SQLiteベースのクラウドデータベースサービスらしいですね。
これ面白いですね。
SQLiteベースなんだ。
SQLiteだとあれもそうですよね。
クラウドフレアのD1でしたっけ。
あれもクラウドで使えるSQLiteデータベースだったりしますよね。
あとはコクローチDBとかTIDBとかも書いてありますね。
36:07
AWSを使ったほうがいいよというケースはVPCが必要なときとか、
マイクロサービスとかモジュラーモノリスとか、
インフラのアーキテクチャがサービスにとって重要とかよく変化する場合、
このよく変化する場合っていうのが結構大きなポイントかなという気はしますね。
あとはGPUサーバーが必要な場合って書いてあるんですけど、
このkoyebみたいな、そんなやつなんですけど、
これがサーバーレスGPUを発表してるらしいと。
これなんか面白いですね。
サーバーレスでGPU使えるとしたら、
本当に必要なときだけ課金するっていう感じにできますもんね。
一度作ったインフラ構成を総編簡単に変更しないんだったら、
お前にAWSは必要ないとか、
あとは開発人数が少なく、
今はユーザー機能を作っていくことが重要だみたいな感じであれば、
お前にAWSは必要ないというふうに書いてありますね。
最近私もAWS選択するよりはバーセルとか、
クラウドフレアページとか選んじゃってたりとかしますね。
いくつかコメントきてますね。
さっきのアウトプットの話ですかね。
小田翔さんから安定しすぎてて、
あえてチャレンジする必要ないって考える人はいそうな気がすると。
そうですね。
本当に安定してるのかどうかっていうのは、
ちょっと考える余地があると思うんですけれども、
そうなんですよね。
職業エンジニアとかで言われるような方々とかだと、
あえてアウトプットする必要がないとか、
あえてアウトプットする必要がないというケースはあるのかなと思いますね。
今ゲスト来られたんでお呼びしますね。
小田翔さんお疲れ様です。
お疲れ様です。
どうでしょうね。
SIとかにはこういう安定しすぎてる方。
ちょっと口が悪いって申し訳ないんですけど、
なんかいそうな気がするんですけど、
実際小田翔さんSIにいらっしゃった方ですけど、
どうでしょう、この辺りって感じますか。
そうですね。
もちろん取り扱ってる技術の内容によりけりかなと思いながらも、
少なくとも自分がいた時はそういったのは別に、
勝手にやってるもので何か会社が特段配慮をしなきゃいけないみたいな、
っていうのはあんまりなかったような気がするんですよね。
39:00
なんかそれが例えば、別に評価のために書くわけじゃないんだけど、
評価にも別につながらないし、本当に自己満足で書いてて、
うちなるモチベーションに対してレバレッジをかけるみたいなことを会社がやってるみたいなところは、
実際はあんまり多くないんじゃないかなと思って、
ちゃんとこういったところに参加してる、コミュニティでは参加されてる会社さんで、
ある程度役職ついてる方とかも含めて参加してる会社さんはその辺理解あるんでしょうけど、
おそらくまだまだ全然市民権得てないというか、
勝手にやってるだけだから別にモチベーションもないし、
別に雇われの身分でよっぽどやらかさない限りはクビにならないし、
土日は疲れたから休みたいし、みたいな感じで書く動機づけがないっていう人は結構いるような気がするんですよね。
そういう方で、そういう方がいらっしゃる会社でアウトプットするときって、
それこそ個人で勝手に聞いたとか前とかでやったほうがいいような気がするんですよね。
会社の技術ブログに書く必要ってあんまない気がするんですよね。
うんうん、まあそうでしょうね。なんかやろうやろうっていう話だけが盛り上がって、
形だけあるけど使われてないからちょっとやっちゃうぐらいな感じで書く人はきっといるんでしょうけど、
実際そういった生きてるのか死んでるのかよくわかんないような会社の技術ブログとかもいくつか散見されるので、
そういったのは勝手にやっちゃえばいいと思うんですけど、
揚げ足取りとかがいたりして、そういったことやってて業務に一生来たしないの?みたいなこと言い始めるような人とかね。
たまにいたりするんで、めんどくせえなっていう方が、めんどくさいんだったらやらないほうがいいかとかね。
でもきっと上のCTOとかそういう人たちからすると、会社のプレゼンスをあげるために技術ブログをやろうみたいな、
そこの温度感、今小田翔さんが言ってた足を引っ張るぜと勝手に書こうぜと、めんどくさいから書かないぜとか、
上の方はただ言ってるだけで頑張れ頑張れって言ってるだけみたいな、
みんな別の方向見すぎやろって思いますね。
やばい、心当たりあれすぎて苦しがってきたな。
でもそうなんですよ、みんな結構見てる方向がちぐはぐで、
書いてほしいと会社のプレゼントあげてほしいと思ってる経営総勢と、
いやいやそんなの何のめしのためにもならんやろ、短期的にはって思ってるぜと、
板挟みに合うのはよくあると思いますよね。
苦しくなるんだったらやらないほうがいいに決まってるじゃないですか。
そうですね。
そうそう、モチベーションが醸成されないみたいなね。
42:02
あるある、あるあるすぎて。
そっかー、あるあるなんだなー。
そっかー、いやーなかなか世知辛いですね、ほんとに。
いやそうなんですよ、なかなか技術者に対して、
ちょっと前まで技術者ファーストを辞めるみたいな方向があって、
あれいつ技術者ファーストだったっけっていう人が結構いらっしゃって、
ほんとそれと思ったんですけどね、
技術者ファーストだったことってあったっけかなと思って、
ないような気がするけどみたいな。
とかでありましたね。
面白い。
あれちなみに今日の寿司は2人前来たんですか?
1人前頼んだら2人前来たんですか?
そうなんですよ。
1人前にプラスオプションみたいなの頼んだんですけど、
そしたら見慣れない大きさで来たんですよね。
なんだこれと思って。
開けたら明らかに2人前で、しかも商品が違ってて、
なんやねんと思って出前かに即連絡したら、
送り返すマッキングで無料でみたいなこと言われてあそこです。
じゃあラッキーですかね。
ラッキー。
頼んだよりも高い寿司がしかもただで食えたので、
ラッキーではあるんだけど、
中トロもうちょっと食べたかったなっていう。
中トロせっかくオプションで追加で発注したのに
それ来なかったんです。悲しい。
そうなんだ。
何もあってないですね。
注文と。
そうなんですよ。しかもね、
ほら緑色じゃないですか。わさびって。
知ってるんですよ。わさび。
緑色で体に悪いって知ってるんですけど。
サビ抜きだから当然頼むんですよね。舌がおごちゃまなので。
ガッツキサビ乗っててびっくりしましたよね。
これが大人かと思いながら。
本当に1から10まで何もあってないですね。注文。
いや本当になんだこれみたいな。
全然頼んでもきっかけしてないみたいな。
面白いね。
そうなんですよね。だからご褒美でね。
すしの発注間違えたりとかすると僕みたいなね。
こうな人間も生まれたりとかするので。
本当に慎重にって感じですね。
分かりました。
じゃあですね。
和田翔さんにはプライベートチャットのほうでURLを送ってあります。
ありがとうございます。
今日のメインテーマですね。
私の学習法というところに入っていきたいと思います。
はい。
和田翔さん見れてますかね。
はい。見れてます。大丈夫です。
じゃあ1件目、和田翔さん読んでもらってもいいですか。
はい。分かりました。
あれなんか101になったな。
OK。大丈夫。
はい。デビュレルネームですね。
西から来た馬面の男さんですね。
いつもありがとうございます。
今週のテーマは私の学習法とのことでお便りを続けてみたいと思います。
学習する対象の分野についてですね。
これを綴ってみたいと思います。
学習する対象の分野によって方法は多少違うかもしれませんが、いくつか列挙します。
IT関連の学習であればコミュニティの勉強会を探して参加します。
45:03
その界隈で専門の方の発表を聞きます。
発表の冒頭は全体の潮流や概要が含まれているので、
特に冒頭は注意して聞くようにしています。
発表者も引き付けるために前半に力を入れていると思います。
次に関連する書籍、中でも初学者向けのものをいくつか買って読みます。
全体を掴むため簡単なものが良いでしょう。
また全部読まなくていいでしょう。
気になる点をざっと目を閉じます。
オンラインの勉強会やオンラインの教材もたくさん転がっているので、
そういうのを見て理解を深めていく。
オンラインセミナーも探せばいっぱいあります。
という感じでいろんな媒体方法を使って頭に入れていく感じです。
ある程度理解ができてきたらコミュニティに行って人と話すことでアウトプットし、
それが循環して自分のインプットになるでしょう。
アウトプットファーストとは素晴らしい言葉で、
アウトプットするためにインプットするというのが最大のメソッドだと思います。
書籍コミュニティ、VoicyやAudibleなど音声オンライン教材、これらを組み合わせつつ、
自分が好きな方法に注力しながら学ぶのが良いのではと思います。
以上ですと、いうことです。ありがとうございます。
この、私このね、書籍をかいつまんで読むっていうのができないんですよね。なかなか。
なかなか難しいですよね。
どこがポイントかって、太字だったら色ついてたりとかして、
ポイントっていうのはある程度抑えられてると思うんですけど、
なんでしょうね、ふわっとした理解だとムズが良くなるというか、
っていう感覚は確かにちょっとありますね。
最初読んで、合わなかったら諦めちゃうんですよ。
飛ばせないんですよね。
もうダメだったらもうやめちゃうんですけど、
なかなか買いつまんで必要なとこだけを読むっていうのができないんだよな。
難しいですね。
例えばiOSアプリ開発の本だと、
自分が学びたいところ、要は1は簡潔系のやつですよね。
そこだったらギリいけるんだけどって感じですね。
そうですね。
昔あった逆引きとか、
そういう自分がやりたいことが列挙されてて、
逆引きで学ぶみたいな感じだったりするといけるんですけど、
なかなかそれができると色んな本読めるんだろうなって思うんですけど、
買いつまみ読みっていうのは私できないんだよな。
なるほど。
気持ちはわかると思います。
わかりますね。
技術書はまず無理かな。
さっきの単元に分かれてるとかだったらいけるけど。
自分の中でストンと落とすまでは何回も読んじゃうみたいな感じはありますね。
エモい本だったら別にあれかもしれないけど、難しいですね、その辺ね。
48:02
確かに。
オーリブルさんも使ってましたね、昔。
どうぞ。
じゅんさんからコメントが来てますね。
単語を拾い読みってミッション決めて1ページ5秒くらいで読むのが昔得意でした。
今できないと。
決めちゃうってことですね、ミッションとして。
なるほど、なるほど、なるほど。
何だろう、速読的な?違うのか。
そうですね、もうこういうふうに読むって決めてパッパッパッってやっていくって感じですかね。
これが面白いかもしれないな。
セルタイプ感を優先する感じ?
そうですね。
まず理解するんじゃなく全体を把握するのを優先するみたいな、そういう決めの問題かもしれないですね。
うん、確かに。
今日は珍しく知らんけどっていうコメントがなかったんで、相当お詳しいのかもしれないですね。
そうですね、知ってたのかもしれないですね。
確かにね、いつも最後に知らんけどって終わってましたもんね。
ね、書いてあるんですけど、今日は書いてなかったんで。
知ってるのかもしれないですね。
何書いてるのかもしれないですね。
ではですね、続いて2人目ですね。
デブレルネームジャニーマンさんですね。
いつもありがとうございます。
興味深いテーマです。
コミュニティーです。とてもおすすめです。
ブログ記事や公式ドキュメント、無料で試せるハンズオンもいいですが、
つながりから良質なインプットが得られるためです。
つながったインプットが得られるためです。
ブログ記事や公式ドキュメント、無料で試せるハンズオンもいいですが、
つながりから良質なインプットが得られるためです。
つながった方と交流があれば、アドバイスをもらったりできる点も大きいです。
また、学習行為そのもの以外にも、学んでいる姿に触れることで、
学ぶきっかけをつかみやすい点は、侮れない効果だと思います。
認定資格などを取るときは、有償の学習サービスなどで追い込んだりもします。
ご参考になれば幸いです。
学んでいる姿は良いですね。
そうですね。種に交われば赤くなるというか、
そういう環境に身を置いて、自分にプレッシャーだったり
発泡をかけるというのができる人は、強くなりますよね。
そうですね。
自分を変えたいとは言わないですけど、
自分に刺激を与えるという意味で、コミュニティに行こうという人もいるってことですかね。
だと思いますね。
某SI時代とかは、そういうモチベーションになれるよみたいなのを
どこかにアウトプットした記憶がありますね。
うーん。
土日何もしないとか、平日より何もしないとか。
51:04
エンジニアはね、人によりけりだと思いますけど、
一生勉強ぐらいのことを言われている中で、勉強しない人っていっぱいいるので、
勉強するだけですぐ、上位とは言わないですけど、
ある程度レベルを上げられるのになんでみんなやらんのみたいな。
ただ、やる環境がないだけなんじゃないかなと思って。
実際にコミュニティに入るまでは、自分もそんなに、
忙しすぎたので土日も働いてたから、
時間があれば寝たきりみたいな感じだったので、
あんまり自分の勉強ってできてなかったんですけど、
コミュニティに入るようになってからは、そういった時間を割くようになりましたね。
うーん。
何が違ったんですかね。
コミュニティに入ってなんか刺激があるってことですかね。
やっぱり自分と似たような年齢とか、似たような業種とか、
似たような趣味思考の人たちがこんなに頑張っているのに、
何してんだみたいなね。
あははは。
へらへらしやがって。
へらへら今もしてるんだけど。
あははは。
とかとか。
せっかく機械が目の前に転がってるのに、
なんでそれ掴みに行かないんだろうっていう、
自分へのプレッシャーをかけられるのはすごくいいですね。
で、ある程度自分がそれで勉強してアウトプットしたときに、
リアクションとかあったりすると、
結局自分のためにはあるんですけど、
やってよかったなって感じになりますよね。
うーん、確かに。
そうですね。
自分との距離感が近いと感じるような人が頑張ってるとか、
やってる感を見せてくれると引っ張られるかもしれないですね。
そうですね。
相互にモチベーション高め合える関係って、
恋愛の話してるみたいですけど、いいですよね。
お互いを高め合える関係みたいな。
恋愛ってお互い高め合うんだっけ?
いやいや、人によるんだけど。
あははは。
人によるんだけど。
どちらかというと、支え支え合い。
お互いに支え合って、
できることを少しでも増やしていけるのはいいですよね。
そんなストイックな関係だったんだ。
うーん、どうだろうなーって。
書いたローカル聞いてみます。
俺ってストイックかな?
どうしたの?って。
来週はねむんだけどどうしたの?って言われちゃう。
ほんとに。
高め合うのは飛行機ぐらいにしてください。
いや、ほんとですよね。
やばいな、絶対肌乾燥する。
ではですね、3件目、小田翔さん読んでいただいてもいいですか?
はい、3件目ですね。
デブレルネーム、札幌のじゅんさんですね。
いつもありがとうございます。
広く浅くしておく必要が今はあるので、
技術者コミュニティの勉強会に出て登壇資料や
54:01
その時の参考ブログの存在を押さえておくようにしています。
押さえておくだけで、ちゃんと読むのは
必要になった時だけになりがちです。
コンパスのページに資料が上がっていると
後でイベントを参照するだけで
内容にアクセスすることもできます。
便利なので使っています。
そういった事情から、自分が運営するイベントでも
極力資料をイベントに紐づける作業をやっています。
そして、誰が何について言ったを
自分の中でインデックス化しているのが
私のツイート実況の正体です。
一方で、昔は深く深く知っておく必要があったので、
新聞やに取り掛かる時には
書籍を3冊読むルーティンでした。
速読用の薄くて簡単な内容の本と
速読用の難しくて重厚な本と
真面目に読む用の標準的なテキストを揃えて
概要と細かい応用先、基礎的な理論展開を
それぞれから拾うようにして
分野を大雑把に把握するようにしていました。
立ち位置によって必要な情報の質が違うので
勉強法も変わるという感じです。
ということで、ありがとうございます。
なるほど。
この書籍3冊読むルーティンって面白いですね。
またちょっとやってみると面白いですね。
うんうんうん。
あれ、音聞こえなくなった?
これだけかな?
あ、ごめんなさい。聞こえなかった。
大丈夫ですかね?
あ、本当ですか?
読んだところで聞こえてました?
大丈夫でした?
あ、聞こえてましたよ。大丈夫でしたよ。
あ、よかったよかった。全然大丈夫です。
これいいですね。新しい視点ですね。
その人の立場によって勉強法が変わるっていう。
うんうんうん。
そうですね。
で、このちゃんと読むのは必要になったときだけになりがちっていうのは
元MSの中島さん?
Life is Beautifulって書いてるか。
中島さとるさんとかも必要になったときに学ぶっていうところで
勉強は好きじゃないけど学ぶのは好きみたいなことを書いていたりしましたね。
なるほど。
なんかそうですよね、確かにね。
ちょっと我々とか登山ドリブンで勉強するとかいうのに慣れすぎちゃってて
ちょっと感覚、あんまり標準的じゃないような気がするんですけど。
うんうん。
確かにそうなんだよな。
必要になったら、なんか人間ってそうなのかもしれないですよね。
必要性を感じないとやらないんでしょうね。ある意味。
そうですね。プログラマーは特に怠惰な人が多いですからね。
そうそうそうそう。なるべく、なるべくそうですよね。
やらずに退勤をつかみたいみたいな。そこまでじゃないかもしれないけど。
うんうん。
って考えたときに、やっぱそうだよなー。
そう、立場によって学ぶ。
進度を変える、だったりとか。
うんうん。
登山ドリブンとかずれてるかも、ジャニーマンさんが。
57:01
そうですね。
登山ドリブンででも、情報収集して学び直しみたいなところはあるかもしれないですね。
そうですね。
だいたいブログとか動画とか何かしらのアウトプットかけてると、
だいたい人間って忘れるので、調べたときに自分のがヒットするっていうパターンとかもあったりとかして、
それで学び直しみたいなのもよくありますし。
うんうんうん。
そうね。
みんな書籍とかって読んだときってメモってたりするんですか?
自分はあんまりメモったりはしてないかな。
メモったりというか、手元で試すじゃないですか。
それがメモだとするんだったらメモなんだけどっていう。
うんうんうん。
って感じですかね。
そう。
例えば、大治さんと大学で教えたりとかするときって、
自分の言葉で説明できるところまでいかなきゃいけないじゃないですか。
知ってる、分かる、できる、教えられるみたいな、学習の何段階みたいなのがあると思うんですけど、
その教えられるレベルまで到達しなきゃいけないので、何週もやりますよね。
同じアプリで何回もやってるし、
一行一行行動の意味とかをかなり深掘りして学習したりとかするので、
その時にやっぱり書籍とかってめちゃくちゃ参考になるなーって感じですね。
はいはいはい。
教えられるって、教団取り分は面白いかもしれないですね。
まあ、登壇もそうですけどね。
そうそうそう。なんかその辺をやっぱりやりたいんですよね、きっとね、自分がね。
その辺まで理解を深めたいから、
教団に立つ取り分で学習するみたいなのもあるかなと思いますね。
きっかけがどっちにしろって感じです。
ジャーニーマンさんからコメント来てますけど、
アウトプットありきってこと自体が希少というかずれているかっていうね。
まあ確かにね、確かに講談取り分な人は全体から見るとあれかもしれないですね。
確かにね。ずれてる気がしますよね。
アウトプットはでもどんどんやるに越したことないと思うんだけどな、
名刺代わりになるっていうか、別にそういった何か目的なくても
その人がその人をたらしめる何かっていうのを形に残すってめちゃくちゃいいと思うんですよね。
今日は学習法っていうところなんで、むしろインプットの話かなっていう気がするんですけど、
アウトプットを意識したインプットをするかどうかですよね。
仕事で役立つんだったら多分仕事がアウトプットになると思いますし、
インプットのためのインプットは確かに難しいかもしれない。
そうそう。インプットって何のためにやるのかっていうような話になるような、
でもこれも多分きっといろんな方が何回もこすってきた話だと思うんですけど、
1:00:01
何かしらアウトプットするためにインプットするんでしょっていう。
目的なく勉強するのを激だるいじゃないですか。
そうですね。
そうそうそうそう。なのでそういった話は表裏一体というか、
二項一致なのかななんて思いますね。
うん、確かに。
なんかすげえ今日真面目なこと言ってる気がするな。
寿司のくだり以外なんか真面目な話しかしてない気がする。
いや大丈夫ですよ。いつも通りでしょ。
大丈夫ですか。
はい。ではですね、最後ちょっとイベントのご案内になります。
再来週ですね。再来週DevRel東京の90回目とCMC Meetup東京の
ジョイントイベントを開催いたします。
あれ来週じゃなかったでしょ。
来週ですね。来週の土曜日ですね。
はい。来週土曜日です。
ちょっとそろそろ本気で宣伝していこうかなと思うんで、
コミュニティ周りとかですね、DevRelに興味がある方はぜひぜひご参加いただければと思っております。
はい。
はい。というところで、小田翔さんはあれですね、来週ついにハワイですね。
そうですね。初ハワイなので、
若干緊張のおももちなんですけど、
さっきようやくスーツケースも出してですね、
ちょっと荷造りしていこうかなという感じで、
それ終わったらまた通常業務というか、
なんか日本帰ってきたくなくなるかもなと思いながらやっているところですね。
まあまあ。
ずらしずらしみたいな。
日本でしか次のAppleのVR発売しないですから。
アメリカも発売済みですからね。
そうなんですよね。
Apple Storeには到着したその足ですぐさま向かおうかなと思ってますけど。
やっぱ買うんだ。
いや、まだ悩んでますね。
やっぱなんか並んで買わないといけないっていう同調圧力をまた感じているので。
誰?
誰も別に同調してないと思うんですけどね。
そうですよね。なんだろうな、変なプレッシャー感じるんだよな。
当然だよねみたいな感じの。
なんかアメリカで買って日本でも買えばいいじゃんって誰か言ってたんだよな。
誰かって結構な人が言ってるんだよな。
それはね、だってアメリカで買っても日本で売れないですからね。
技的な問題あるから。
そうなんですよね。
いやそうなんですよ。
なんかみんな不思議なこと言ってるけど、なんか筋が通ってるからなんか狼狽してますよね。
こっちの避ける予算感だけ無視するっていうね。
そうね、それは別に気にしてない誰も。
そうですよね、そうですよねっていうぐらいかな。
あとは本当は今週末にJustっていうカンファレンスで登壇して、
ようやく昨日の夜というか今朝資料できたんで、
それやって気持ちよくハワイ行って帰ってきたらまたウェビナーだったりとかもろもろやっていくって感じで、
なるべくお仕事しない1週間にしようかなと。
1:03:00
いいですね。
時にはね、リラックス必要なんで。
じゃあパソコン置いてったらいいじゃないですか。
いやーパソコンは一応持ってった方かなみたいな感じですよね。
なんかね、手持ちブタとなりそうな感じ。
手持ちブタ。
お手手が寂しい。
そうそうそう。
お手手寂しいよみたいなことになりそうなので。
パソコンは一応持っていこうかなと思いますけど、
極力開かないというかね。
ちょこっとだけぐらいやって、
ちょこっとだけみたいな感じにしようかなと思います。
分かりました。
ぜひ楽しんできてください。
はい、頑張ります。
はい、ではですね、
今日Wラジオ155回目ですね、
こちらで終了していこうと思います。
小田尚さん、いつもありがとうございます。
はい、ありがとうございます。
ではまた次回お会いしましょう。
ありがとうございました。
ありがとうございます。
ではまた皆さん来週お会いしましょう。
さよなら。
さよなら。
01:04:01

コメント

スクロール