よくわからん謎の技術のキャッチアップ方法と調べ方についてのまとめ
はじめに
「ベテランになるほどブログを書かなくなってくる」という記事を読みました。ぼくはそんなにベテランではないですが、最近書いてなかったので、「自分のあまり知らない技術」についてをキャッチアップしたりするときに考えていることを、ちょっと書こうと思います。
ChatGPTに概要をおしえてもらう
ぼくはChatGPTの推論能力と知識保有量をだいぶ買っているので、基本的にChatGPTに概要を聞きます。
そして、ChatGPTに概要をザックリ教えてもらって、その骨子をつかむのは非常に有用だと感じています。
ぼくは↓のような形で教えてもらったりします。これが信頼できる情報かどうかはともかく、何も知らない状態よりかは相当大きく進みます。これを元にここから出発しています。
マニュアルをしっかりと読む
RTFM(Read The Fucking Manual)という言葉がありますが、マニュアルを読むことは非常に重要だと思います。
とくに、マニュアルをしっかりと読み飛ばすことなく読むということがとても重要だと思っています。
マニュアルをしっかりと理解しながら読むのは非常にめんどくさいことで「めんどくさいな。今そんなことやっている場合じゃないんだ。こっちをやらないといけないんだ。自分は早くこれを達成したいんだ」という気持ちにおされて、ついつい読み飛ばしたくなります。
しかしそうやって読み飛ばすと罠にハマることが多かったり、誤った理解のまま突き進んだりします（した）。
そうすると余計に時間がかかったりして、かえってめんどくさいことが多くなったりします（した）。
しかも理解していないので、また似たような問題のときに同じようにハマります（ハマった）。
マニュアルを読んでくれていることを前提にいろんなものが構築されていることが非常に多いです。作る側からすれば「こんなにわかりやすく書いたんだし、マニュアルぐらい読んでくれるでしょ」というような気持ちがあります。世の中大体そうです。
それにマニュアルをしっかり読むというのは結構難しいです。「他人の書いた文を読む」とか「他人の話していることをしっかりと聞く」とか、その人自身に興味がないとなかなか厳しいものがあります。みんな他人なんかに興味なんてないので、そこが一番むずかしいなと思っています。
しかも、もちろんマニュアルにすべての情報が載っているわけではないです。
そういう場合はソースコードを読むとわかりやすくなる気がします。究極的に、ソースコードが一番正しいです。
侮らない。リスペクトの気持ちを持つ
ほとんどのソフトウェアエンジニアは頭が良いです。とくに、フレームワークをわざわざ作ろうとか、ライブラリをわざわざ作ろうとか、そういうことをしたい人間は情熱度が高いし、頭がキレッキレのことが多いです。コストもたくさん支払っています。
そういうものを「どうせ大したことねーだろ」と思いながら読むと、自分の想定しているレベル感と合わないので、理解に100ぐらいのコストが必要なものに対して、10とか20ぐらいのコストで理解しようとしていることになり、全然理解できないことが多いです。
また、世の中には偏差値80とか偏差値90とかの人がものすごくたくさんいて、そういう人が力を入れて作っているものが多くあります。そういうものをチラシを読むようなノリで理解しようとするとよくわからなくなることが多いです。言われてみれば当たり前なのですが、言われるまでは当たり前だと気付きにくい情報だと思います。
とくに、英語圏のソフトウェアエンジニアの人は、哲学やらシェイクスピアなどを読んでいたりしますし、SFを履修していたり、中国史とか、アニメを知っていたり、山下達郎だって知っていたりしますし、化学や物理だって学校で習ったので知っているし、トンカツだって食いますし、干支のことを知っている人もまあまあいます。別にこれは特段異常なことではなく、普通のことです。そういうことを意に介さずに、書き手を侮っていると理解が非常に難しくなると思います。
急にtroposphere（対流圏）とかいう語をアナロジーに使ってこられても別に不思議ではありません。書かれている英語を侮っていると簡単にわからなくなります。ぼくらはtroposphereを非常に高難易度の語だと認識します。英検1級以上のレベルの語です。しかし、英語圏の人にとっては小5ぐらいで習う平易な語のように見えるという異常なギャップがあります。
ギャップを埋めようとするべきというよりかは、「どういう知識が背景にあるのかわからないが、もしかすると何らかの大きなギャップがあるかもしれない」と認識するだけでもだいぶいい感じです。
逆にダメダメなところがあることもわきまえる（結局人間なので）
逆に、あるドキュメントなりの作成者を、まるで神のように崇めていたり、すべてを盲信するとうまくいかないことも多いです。そもそもそれはなんのために用意されたものなのか、というところを外すと全然うまくいきません。
「そもそも作ってない」「作ろうと思ってるけど今はやってない」「ネガティブ情報だから敢えて書いてない」「そもそも関係ない」「そんなこと考えたこともなかった」などがあります。
とりわけ、ベンダーが提供する情報はネガティブ情報が極端にふせられていると思います。
「◯◯はできません」というのは、当たり前ですけどあまり言われないです。「◯◯ができる」「◯◯もできる」「こんなに優れている」という情報が多く氾濫しています。そういうマーケティング用・広告的な情報はちょっと割引して認識するといいのかなと思います。
とくに、自分の都合で考えるとうまくいきません。『なんでも自分の夢をかなえてくれるドラえもん』みたいなもたれかかりをするとうまくいかないことが多いと思います。世の中というのは自分中心で動いているわけではなく、誰かが作ったものは、その誰かがその人自身の人生における利益を得るために作ったものです。自分の都合などというものは露ほども考えられていません。
天動説的（自分の周りを天の方が動いているのだ）な考え方をしていると、世界というものがものすごく意味不明な状態になっているように見えるはずで、全然自分の思い通りにいかなくなりがちな気がしています。
また、当時の情報によるものなので、現在の自分にはあてにならない情報も多いということに留意が必要です。「差分は自分で埋めなければならない」という現実を突きつけられることも多いです。
「そもそもこれは何？」「何のために作られているのか」というところをおさえておくと良さそうです。
仮説を立てて、事実が仮説に反していれば仮説は即棄却する
調査の段階で、いろいろな仮説を立てると思います。
「もしかしてこれはこうなっているのかな？」というふうに最初は思うと思います。
でも、いつしか「これはこうなっているかもしれない」から「こうなっていなければならない」になり、「こうなっていなければならない」から「こうなっている」に変化してしまってることがあると思います。
そして「こうなっているのに、どうしてうまくいかないんだ？！」という勝手な結論に到達することが多いです。そしてそのあたりをぐるぐる回るのですが、かなり前の段階から間違っていることが多く、そこでぐるぐる回ったぐらいでは解決しないことが多いなと思っています。
これはぼくは山登りなどでいう「道迷い遭難」の状態だと捉えています。ちょっとよくわからないからこっちに行ってみようと外れていき、だんだん迷子になって混乱したりします。酷いときは1週間遭難したりするのではないでしょうか。
そういうとき、ちゃんと自分が何がわかっていて何がわからないかを紙に書くとかスプレッドシートを使うとか、まあなんでもよいのですが言語化して、迷う前まで引き返すと良さそうです。
混乱しているときというのは自分の頭の中だけで考えていることが多く、人間の頭なんて所詮5桁の掛け算ですら簡単にパンクするような能力しかないので、ちゃんと外部媒体を使った方がいいと考えています。
そこで仮説を組み立てて、仮説に合わない結論が出たら容赦なく切り捨てることが重要だと思っています。こういうのは科学的思考というんですかね？ しらんけど。
焦りからか「この仮説さえうまくいけば、都合がいいのに！！！」という思考がわきあがることもありますが、それは自分の勝手な都合であって、自然界はそうなっていないことが多いです。
人に聞く
人に聞く技術は非常に重要であり、れっきとしたスキルだと思います。
一方で、人に聞くためには、日頃から人間関係・信頼関係をメンテナンスできていないと難しい気がします。
どうしてもその人しか知らない情報というのが世の中にあります。
ただしどうしても人間なので「この野郎に頭を下げるのはシャクだな」とか「こんなことで借りを作っていいのか」とか、そういうことを回避したくなるのが人情だと思います。
だからこそ、日頃の感謝や雑談や手助けなどが重要になってきそうです。「いつも助けてくれる◯◯さんが聞いてくれた。よろこんで手を貸しちゃおう」などという心の動きが出ると思います。やはり義務的にやるのと、本心からやるのでは違う気がします。
人に聞くと、声のトーンなどでどの技術がどの程度の位置づけなのかだったり、どういう気持ちでその技術に接しているかだったり、なんとも言いようのないコツがつかめることが多いと思います。
たとえばWebアプリケーションの初歩的なところでいうとMVCモデルですが、MVCモデルなどというものは、ベテランの人に聞いたらすぐにMVCモデルのコードを書いてくれて、「リクエストがこう来るじゃん？」「それでこれがコントローラー」みたいな感じで、かなり正確なレベルでの説明とメンタルモデルを得られ、即座に把握できると思います。その時点では難しくても、頭に刻み込まれた流れをもとにのちのちモデルを再構築できるため、これだけでガチ初心者は1ヶ月分ぐらいショートカットして学習できるのではないでしょうか。安心感も違うと思います。
コンピュータは英語が中心の世界
これは英語がある程度わかるようになると体感することだと思うのですが、コンピュータ関連の話はほとんど英語圏のオチャメな命名のものが多いと思います。
ぼくの感覚によるものですが、日本語に翻訳されたものは、どこか気取っています。「しっかり正統なものを作らねばならぬ」「こんな言葉を知っているのはスゴイ」みたいなカッコつけを感じます。
たとえば「圏論」の「圏」なんて怖いですけど、英語でいうとカテゴリーセオリーです。カテゴリーだと怖くないです。第一級関数も怖いですけど、英語だとFirst-class functionsで、要は「市民権を持っている（「ふつうの市民ならばふつうにできること」ができる）関数」みたいなノリです。
日本語に訳された時点で、オチャメさや中二病っぽさが消えて、ちゃんとした学術用語とか賢そうな名前に変換されていることが多いのですが、英語のちょっとギャグみたいな部分を楽しもうという遊びの心までが消えてしまっているようで少し悲しいです。そういう心があると、ちょっとだけわかりやすくなる気がします。
あとは、なまじカタカナとしてよく知られている英語があると、「それぐらいなら自分は知っている」と考えてしまい、サボって英単語の意味を調べないケースがあるような気がします（ぼく調べ）。たとえばサブネットマスクのマスクですが、「マスク」の「覆い隠すもの」という意味を知らないとただの意味不明な「マ」「ス」「ク」という音にしか聞こえないし、意味わからんと思います。逆に「ネットワークを分けたいんだな〜」と「サブネットを知るために1111って感じでマスキングしてるんだな〜」と思えれば、なんかもうあとは適当でよくて、勘でだいたい合ってます。（※ 「したがってマニュアルを読まなくてもいい」という話ではありません）
理想と現実は違う
結果を得るために最高効率でも100のコストが必要なタスクは、100のコストを最低でも支払わければいけません。それが現実で、これが自分にとってはすごく面倒くさいです。
コスパに目を向けすぎると、最低100必要なタスクだったとしても、30とか20とか小さなコストで結果を得ようとしがちですが、最低100のコストが必要なタスクは、最低100のコストが必要になります。
理想主義に陥ると、ここで「コスト30で結果が得られたらいいのに」と考えて、コスト30付近で永久にぐるぐる回り続けている印象があります。
これは「東京から大阪に行こう」というときに「静岡あたりに『大阪』が来るにはどうすればよいか？」と考えるようなものだと思っています。
つまり「東京や大阪とは何か」「東京から大阪とはどういうルートがあるのか」とかそういったものを全部すっ飛ばしてとにかく大阪を東京に持ってこようとして、ロープを買ったり、逆立ちしたり、地図を買ってきて大阪の場所を切り取ったりする、というようなことをしているような感じなのかなと思います。
だから「大阪に行くには新幹線使うとかどうかな」とか「まずは地図を見てみるとか」とか「ここは仙台じゃないですか？」とか、そういう助言をないがしろにしがちなのかなと思います。
抽象的なものなのでそういう間違いをすることは多いのですが、「なにかおかしい」という勘とか、「本当に自分の理解って合ってる？」「こういうことをするのって人類で自分が初めてなのかな？」というような、いったん自分を疑ってみる心が重要なんかなと思っています。
大胆な発想はおもしろいのですが、全然うまくいかないことも多い気がしています。
おわりに
当たり前のことしか言っていないような気がしますが、この当たり前のことを徹底することがすごく難しいと思っています。
また、あくまで自分の経験からくる話なので、別にこれが正解というわけではありません。
抽象的な話に終始して、「なぜこれが良いのか」という部分の説明についても足りてない気がします。
でもともかく抽象的なぶん、プログラミングなどにとどまらず、色んな場所で応用できる考え方だと思います。
ただこういう情報って、わかる人には『そうそうそれな。結局それ』みたいに同意されがちだけど、そうでない人にとってはただ抽象的なだけで『そういうのはわかったし、今もやってる。それで、結局何すればいいの』という話に見えるような気もします。
大した情報ではないかもしれませんが、ぼくが結構だいじだなあと思っていることたちでした。
Discussion