2024年5月28日
Javaスペシャリスト
九州芸術工科大学 芸術工学部 音響設計学科を8年で退学後、フリーランスでの活動を経て、現在はLINEヤフー株式会社に勤務。著書に、『プロになるJava 』(共著、技術評論社)、『みんなのJava OpenJDKから始まる大変革期! 』(共著、技術評論社)、『創るJava』(マイナビ)など。
X(@kis)
ブログ きしだのHatena
前回の記事ではアウトプットについて考えました。今回はインプットについて考えてみます。
インプットというのは、自分をつくる材料になります。身体は食事というインプットで得た栄養を材料につくられていますね。同様に、情報というインプットを材料にして、考え方が創られていくのです。
そこで今回は、自分を創るインプットをするときに筆者が考えることをまとめてみます。
インプットは「傾向をつかむためのもの」と「力をつけるためのもの」という2つにわけることができます。簡単にいうと、勉強するときには薄くてすぐ読める本と厚くて詳しく書いてある本の2段階にわけて読みましょう、ということです。
それぞれの段階は次のようになります。
傾向をつかむ場合は、「広く浅く手早く」を意識してインプットすることになります。ニュースのチェックはこちらに入りますね。
ニュースのチェックであれば、興味のある事柄について周辺情報もカバーできるように広く、話題になっているものがつかめる程度に浅く情報を集めます。そして手早くというのは、情報が出てからチェックするまでの時間が短いことと情報を読む時間が短いことを表します。
新しい技術を勉強する場合であれば、必要な範囲をカバーする程度に広く、あまり詳細にならないように浅く、そして勉強したいと思ってインプットを終えるまでの時間が短いことを表します。最近のプログラミング言語やライブラリでは、公式ドキュメントにチュートリアルが用意されていることが多くなっていますが、そういったチュートリアルを試してみるようなインプットです。
傾向をつかんだあと、実際に実務に活かすことを考えて、具体的な情報を掘り下げるためのインプットです。
最初に傾向をつかんでおけば、勉強することが絞れるので必要な範囲を深く時間をかけて取り組むことができます。
ニュースチェックをしているときであれば、気になった背景情報を詳しく調べることもあります。また、新しい技術を勉強する場合は、個別の機能を詳しく見ていくことになりますね。
トレンドを追うときには、いかに効率よくトレンドを追えるかというのが大事になります。
SNSや情報サイトはたくさんありますが、技術的なトレンドを追うときには今でもX(旧Twitter)にかなうものはないように思います。知りたいトピックについて投稿している人を50~100人程度フォローするかリストに入れてチェックするといいでしょう。フォローするアカウントを探す際に技術名で検索してもうまくみつからないので、技術関連イベントや公式アカウントに「いいね」などの反応をしている人をフォローしていくといいでしょう。
筆者の場合、大規模言語モデルについて興味が出たときに、関連する投稿をしていた人を50人くらいリストに入れて追いかけていました。おかげで、新しいLLMやその使い方などをいち早く追うことができました。
ただ、新しいトピック以外では関連情報の投稿頻度は低くなるので、SNSで情報を追うのが難しくなっていきます。日々のニュースというよりは、興味のある技術がバージョンアップしたなど、変化があったときに早く気付くことができるものだと考えるといいでしょう。
SNSでは日々のニュースのチェックは難しいとなると、やはりニュースを知るにはニュースサイトをチェックするのがいいでしょう。技術ニュースのサイトもいろいろありますが、筆者は「PC Watch」や「Publickey」などをチェックしています。
ただ、そうはいっても一日のニュースは結構な量があるので、「Feedly」や「InoReader」のようなRSSリーダーを使うことがオススメです。タイトルだけ確認できればいいものもたくさんありますから。
Xでニュースサイトのアカウントをフォローしてもいいのですが、サムネイルが入ってかさばるので一覧性が悪く、チェックの効率が良くないように思います。
トレンドを追うときに考えたいのは、技術情報だけではなく普通のニュースも追ったほうがいいということです。
技術は社会に接することで意味を持ちます。そのため、エンジニアの開発するものは、社会的な動向にも影響されます。そもそも、エンジニアとはいえ日常生活があるので、社会的な情勢は知っておいたほうがいいでしょう。
このとき、Xに流れてくるトレンドやキュレーションアプリに頼りすぎないほうがいいと思っています。というのも、トレンドになるのは事件や事故、政治でも政争となってるようなものが多く、重要だけど地味なものは流れてきません。また、ネガティブなニュースが流れやすいので、楽しくない気分になってしまいます。特に大きな事件や災害が起きたあとはトレンドが関連ニュースばかりになりがちです。また、Xではニュースのタイトルだけ見て中身を読んでないのではないかと思われる反応も多く、そういった反応ほど拡散しやすいので、あまり依存しないほうがいいように思います。
なるべくニュースサイトを直接確認するようにしましょう。ただ、新聞社などのサイトは一日に流れる分量も多くタイトルだけのチェックでも時間がかかってしまいます。「NHKニュース」が分量的にはいいのではないかと思います。それでも60件くらい流れてきますが。
これも、XのアカウントではなくRSSで確認するほうがいいでしょう。
もし新しく出てきた分野やソフトウェアに興味が出たときは、早いうちに追いかけていくと楽です。
「どうせすぐ仕様変更があるし環境も整っていくから必要になったときに手を出そう」と思いがちです。ほとんどの場合はそれでいいのですが、興味を持ったときには追いかけることも考えましょう。
新しい分野のソフトウェアは、出始めのときには機能も絞られ、試しやすくなっています。中心的な機能しかないので、ソースコードもそこまで大きくなく、追いやすくなっています。新しい機能が入る頻度やそのインパクトも大きいので、追うことの楽しさもあります。初期には周辺技術の解説も増えるので、深く勉強しやすくもなります。
また、品質がそれほど高くなく、バグを見つけやすかったり、実装が簡単なのにみんな求めてるような機能が足りなかったりと、プルリクを送ってオープンソースプロダクトに貢献しやすくもなっています。
最初のほうから追いかけていると「詳しい人」になれるチャンスも増えます。なにか新しいものに興味を持ったら、追いかけてみることをお勧めします。
メタ情報というのは、情報の情報ということです。日付やサイズ、著者、URLなどがメタ情報になります。
インプットするときに、書かれている内容だけではなく、そういった、その文書がどういうものかというメタ情報も大切になります。
その文章がいつ書かれたものかは重要です。検索で見つかったりSNSで流れてきた文書については日付を確認するようにしましょう。
バージョンアップで仕様が変わっていることや、サービスの変更で書いてあることが成り立たなくなっている可能性があります。
また、バージョンアップで仕様が変わったあとに出された文書であるのにかかわらず、古い仕様にしたがった内容になっているものは、調査力に疑問がわくのでアテにしないほうがいいです。
いろいろ追いかけようとすると、全部の記事を読むというのは難しくなります。興味が薄い分野であればタイトルだけチェックするとか、そもそもチェック対象から外すということでもいいのですが、興味がある分野だけど追いかけるのが厳しいということもあります。もちろん、あまり興味がないけど完全に無視もできないということもありますね。
そういう場合は、「量」だけ確認するということも大切です。
例えは筆者の場合、フロントエンドについては興味が薄いので積極的に記事をチェックしていないのですが、それでも「最近はDenoという何かの記事が増えてきたな」だとか「Vueというのを見かけなくなってきたな」のような、記事の量に基づく印象は持っています。
個別の記事でも「興味あるけど記事を読む時間はないな」というときは、リンクを開いて記事が何ページあるか、どこまでスクロールできるかだけ確認して「こういう話題にはこのくらいの分量の記事が出るのだな」ということだけチェックすることがあります。
オープンソースのプロダクトでも、ドキュメントをみて「このくらいの量のAPIがあるな」だとか、GitHubをみて「このくらいの数のソースコードがあるな」「ソースコードの長さがこのくらいだな」という風に、量をチェックするだけでもプロダクトの雰囲気がつかめます。GitHubでいえば、Pull RequestやIssueがどのくらいあるか、どの頻度でコミットされているのかというのも参考になりますね。
誰が書いたかというのはもちろん重要です。
偏りのない視点というのは持ちようがないので、必ずなんらかの偏りがあります。その偏りを判断するために誰が書いたかというのは大切な情報になります。例えば筆者であれば、Javaでサーバーサイドを主に扱うため、動的型付言語やフロントエンドを主に扱うエンジニアとは考え方が違う部分があります。
しかし、大切なのは何が書いてあるかです。まずは文章を読んで、書かれていることが妥当かどうかを読むようにしましょう。視点によって意見が変わりそうな部分だけ、だれが書いたかを確認するのがいいでしょう。
要するに手を動かせということです。
“記号接地” という言葉は、ChatGPTの登場でAIに「本当の理解」が可能かという議論が盛んになったときに注目された考え方です。
つまり、ChatGPTなどのAIは多量の文章を学習しているだけで、言葉と結びつくような現実の体験がないので理解をしているとはいえないのではないかという話です。
個人的には「現実の体験」を人間の脳も直接行っているわけではなく、電気信号に変換された感覚器からの情報を処理しているだけなので、そういった感覚情報と言葉の組み合わせを学習させれば可能ではないか、感覚情報も多くは言葉で代替可能ではないかと思っていますが。
ともあれ、言葉と現実の体験が結びつくことを記号接地と呼びます。
そして、AIが記号接地がないので理解をしていないと言われるということは、私たち人間も理解のためには記号接地の意識が必要ということになります。
例えば次のようなJavaの導入の解説があるとします。
https://adoptium.net/ から「Latest LTS Release」をダウンロード、インストールしたあと、次のコードを「hello.java」というファイル名で保存、コマンドプロンプトやターミナルで`java –enable-preview –source 21 hello.java`を実行。
void main() { System.out.println("Hello"); }
この文章を何度も読んで意味を理解したとしても、Javaのプログラムを動かすことの理解にはなかなかつながりにくいと思います。
けれども、adoptium.netにアクセスする、JDKをダウンロードする、ダウンロードしたインストーラを起動する、コードを実際に打ち込んで保存する、実行する、といったことを実際にやっていくと、それぞれのステップで納得感のようなものが出てくるのではないでしょうか。
これは、実際に作業を行うと、文章では触れられていない情報にも接するからではないかと思います。例えば実際にadoptium.netにアクセスすればサイトの構成を目にします。URLの入力中に補完でいろいろ表示されて関連する単語を知ることもあります。インストーラを実行すると、進行のためにいくつかボタンを押す必要があります。ファイルを作る場合にはエディタを立ち上げ、ファイルを保存する場所を気にします。コマンドプロンプトで実行するためには、保存した場所に移動する必要もあります。実行するときにどのようなタイムラグがあるかというのも重要な情報です。また、それぞれの作業についてなんらか自分で考えることにもなります。脳の仕組みとして自分で考えたことも実際にはインプットになります。特に、なにか入力ミスをしたときには、いろいろなことを考えると思います。
こういった、実際に体験するときに得られる付随情報や考えが、「記号接地」の正体ではないかと考えています。このときの付随的な情報は、人によって少しずつ違うはずです。それが個人的な体験ということになって、個性につながっていきます。実務のためのインプットではこういった記号接地も意識して、なるべく手を動かすようにしましょう。
先ほど少し、自分で考えたこともインプットになるという話をしました。
例えば、アメリカに数日滞在したときに、ほとんど英語を聞いたり話してなかったりしても、日本にいるときよりも英語がうまくなるということがあります。これは、買い物に行くときや食事をするときにいろいろな会話のシミュレーションをして、そのシミュレーションでも実際に会話をしたのと同じような学習効果があるからだと言われています。
ということは、文章などを読む場合に少し疑問に思ったことをちょっと考えてみるということも、それ自体がインプットになるともいえます。ただ、このときに気をつけないといけないのは、その考えが間違っていたとしても、それをそのままインプットしてしまうことになるというところです。間違った考え方を何度も繰り返すと、それを正しい情報だとして学習してしまうことになります。
いろいろと考えたときには、アウトプットして周りの反応を確かめるということも大切です。これは前回記事のアウトプットすることがよい勉強になることにもつながります。
プログラミング言語について、最初は入門書や解説サイトなどで勉強する人がほとんどだと思います。また、作業中にわからないことがあったとき、検索をして最初に出てきた情報で済ませてしまうことも多くあります。ニュースも、SNSに流れてくるものだけで把握してしまいがちです。最近だとChatGPTに聞いて終わりということも多くなっているのではないでしょうか。GitHub Copilotが生成したコードをよくわからないけどそのまま使うということもあるかもしれません。
けれども、その情報の出処を確認するというのは大切です。検索で見つかったものは問題の解決法に絞ったものになりがちです。生成されたコードだけでは実際のコードの意味をわからないままにしてしまうこともありますね。
公式ドキュメントを見れば、コードの意味やその周辺情報も同時に目に入ります。ドキュメント上でどのような位置に書かれているかというのも大事なメタ情報です。
ニュースであれば、実際にそのニュースの全文を確認すると背景情報もわかることがあります。ニュースは記事を書く記者とは別の人がタイトルをつけることがあり、実際に記事を読んでみるとタイトルや概要の印象と違うこともあります。
こういった周辺情報が、先ほどの記号接地を生むこともあるので、できるだけ情報の元ネタを見るようにしましょう。
自分のまわりには自分に似た人が集まるため、自分のやっていることが主流だと思いがちです。そのため、アンケートなどの統計情報を確認して全体的な傾向を確認することも大事です。
例えば、JetBrainsが毎年出している『2023 年開発者エコシステムの現状』という調査報告があります。読んでみると、自分の実感とは異なるデータが出ていることも珍しくありません。
ただ、JetBrainsというIDE企業での調査であることやグローバルな調査であることに注意が必要です。グローバルと日本での傾向の違いというのは当然にあります。代表的なところだと、日本では他の国に比べてRubyの採用率が高いです。
プログラミング技術のところでは、総務省の情報通信白書があります。
また、IPA(独立行政法人情報処理推進機構)が出しているDX白書もあります。
DX白書はIT人材白書とAI白書が統合したものです。そのため、IT人材の傾向や企業の取り組みについて多くまとめられています。
レバレジーズも「レバテック人材白書」を公開していますね。
こういった統計を見るときのコツとしては、数値はアテにしないということです。調査方法による偏りが必ずあるので、数値自体にはあまり頼りすぎず、数値の変化や比較を見るようにしましょう。代表的な数字に視聴率があります。視聴率15%という数字だけ見てもあまり意味がないですが、「去年は10%だった」ということであれば去年よりは見られてると言えそうですし、「他の番組は10%だった」ということであれば、その番組よりは見られてると言えそうです。
公式ドキュメントは、必要になったときに必要になった部分を見るということが多いと思います。基本的にそれで構わないのですが、自分の強みにしたいような技術に関しては「全部読む」をやってみるのもオススメです。
公式ドキュメントは広い範囲にわたって詳細に書かれているので、馴染みのない部分では全く理解できないということも多いと思います。それでも、わからないなりに読むことで「何やらよくわからない技術に対応しているらしい」ということがわかったりします。
技術を習得するときに、頭のなかにその技術に関する地図を描くことが大切ですが、実務で使うことだけを調べていると、その範囲だけの地図になってしまいます。わからないものも含めて全部を読むと、地図の範囲としてはその技術の全域になり、そのなかに黒塗りのよくわからない部分が残るというようになります。「自分にわからないことがある」というのも大事な情報なので、一度何かを「全部読む」をやってみるのもいいのではないでしょうか。
もちろん、大量のドキュメントを全部読むというのは大変なので、範囲を絞ってもいいと思います。
情報のインプットは自分の考え方をつくります。
仕事が忙しかったりすると、目の前の仕事をこなすことや周りに追いつくことを中心にインプットを考えざるをえないこともありますが、インプットによって自分の考え方の個性も作られていきます。
どのような個性をつくるかということを少し頭に置いておくといいでしょう。
関連記事
人気記事