何かしら問題が起こって(もしくは問題が起こったのかどうか切り分ける段階で)それを解決する際に出てきてる表示が英語で読めなくてうろたえる、って経験ありますか。回りの人に聞いてるとよくある現象くさいですね。

自分は幸運にも海外育ちなので英語は全く問題ではありませんけど、同時にハッキリと言えることは仕事でプログラムを書いたり、パッケージをインストールしたり際にいちいち律儀に画面に出てくる英文を読んだりはしてない、ということです。

重要な事なのでもう一回言いますね:「いちいち律儀に画面に出てくる英文を読んだりしてない」です。

まず、大前提。その切り分けができなくてうろたえてる状態に陥ってるあなたは確実にそのソフトなり環境なりのエキスパートではないですよね?エキスパートだったら多分その状態についてすでに知っているか、調べる方法を知ってるはず。エキスパートじゃないから困ってる。ということは自分で解決するのはできるとしても多少時間がかかるでしょう。趣味のプログラミングはそれでもいいですが、仕事だったらその多少の時間がもったいないです。とっとと回りの人に聞いて、次回同じ状況に陥らないための方法とかをメモしながら作業したほうが早い。なので自分一人で困るのはやめましょう。

でも回りに聞くためにはある程度の切り分けができないとダメです。その現象がなんなのか具体的に分からなくとも、以下の2点が分かればもっと分かっている誰か(例:Google先生)に質問することが可能になるとはずです:

  1. それはそもそもエラーなのか?
  2. エラーならばどこの部分が具体的にそのエラーの状況を表しているのか?

この際、英文を読める必要はほとんどありません。エンジニアであればほぼ確実に出会ういくつかのキーワードを知っていればOKです。あくまで一例ですが、

  • "Error"
  • "Fail"
  • "Abort"
  • "Exited"
  • "Stop"
  • "Give up"
  • "Fatal"
・・・等々、この辺りのキーワードだけ覚えてください(実際にはもっと他にパターンがあるかもしれませんが、これだけでも6,7割はあたるはず)。あとはこのキーワードを使って、表示されてる文内を検索してください。その言葉の前後にエラーくさい(普通処理と異なる)出力がしてあれば、十中八九それがエラーです。

で、エラー文さえ入手できれば少なくとも「質問をする」という行為にたどり着くまでに収集可能な情報はほぼ全て揃ってます。あとはなるたけ状況を理解しやすいようにそこまえいたった背景をエラーメッセージとともに指定すればOKです。

ね、英文なんて読む必要ないでしょ?be動詞がどうたらとか、どうでもいい!エラー文の場所さえわかればいいんです。そういう勘がつけば、あとは少しずつ定型文の語彙を増やしていくだけで少なくともプログラム関連の英語に関しては結構実用的なノウハウがつくはずです。




ちなみにこれ、ちょっと前に Perl Casual で行ったライブコーディングの際にも話した内容と同じです。その際はPerlモジュールを扱う際にPODで記されたドキュメントをどうやって読むか、という話をしました。

PODも実はほとんど内容を読んでません。まずSYNOPSISでコードは読めるし、DESCRIPTIONはモジュール名を見てわからない時だけ読みます(でもそもそもモジュール名を見て内容がわからないモジュールは使えない事のほうが多いので、結局読まなくてよかった、みたいなこともあり得る)。

で、前述のごとくこういう状況でも自分はほとんどドキュメント自体は読んでません。キーワードだけ追ってます。

関数の使い方は "Returns"とか"Takes"とか "Parameter"とか"On error"とか、キーワードだけ見てます。戻り値が知りたいならReturnsの前後の文脈だけ読めばよく、引数はTakesの前後で大体事足ります。もしそれぞれの説明がわからなくても、誰かに「Takes XXX のXXXってどういう意味?」と聞けますよね。「この関数どうやって使うの〜?」という大雑把すぎて聞かれたほうにははた迷惑な質問に比べたらピンポイントで単語の意味やその部分の挙動について聞かれたほうがはるかに質問する行為のコストパフォーマンスがあがるはず。

というわけで、僕の言いたいことはまとめるとこうです:文学作品を書くわけじゃなし、技術資料を読むのに語学力なんて大していらない。まずはキーワードを覚えろ。覚えたらその回りの文章を読みほどくか、とっとと誰かに聞くべし。それを反復すべし。

読めなくても必要な情報だけ抜き出せるように練習するとぐっと楽になりますよ!