21世紀の文字起こし(3) 〜 Cloud Speech-to-Text 編 〜

ここまでのあらすじ

少なからぬ人々が直面する文字起こし(音声を文字に変換する作業)について、手動でパチパチやっていくのはけっこうつらいものがあるので、なんとか自動化できないか? というこのシリーズ。

気がつけば最初の記事はちょうど2年前の今頃に書いていて、続編はその半年後。で、それからさらに1年半ぐらい経ったわけですが。

note103.hateblo.jp
note103.hateblo.jp

最初の記事は、たしかiPhoneの音声入力機能を使って、耳から当該音声ファイルを聴きながら自分でそれを追いかけて喋るという、いわばシャドウイング方式でやったらこれ文字起こしになるじゃん! という素朴な発見から始まって。

そのまま連想的に「でも自分で喋らなくても、SoundflowerとGoogleドキュメントの音声入力を組み合わせればなんか自動でできそうじゃね?」と思ってやってみたら「うわ、できるじゃん(笑)」みたいな流れだったかなと。

続編の方は、その最初の記事では憶測で書いていたような各種の条件的な部分をもう少し厳密に検証して、「何ができて、何ができないのか」を自分なりにまとめたものでした。

で、それから2年が経って今はどうかというと、Googleさんの技術の進歩は目覚ましく、最初の記事では「1分もしないうちに止まってしまう」とか言っていたのがほとんど永遠に起こし続けるようになり、内容の精度もだいぶ上がっているように感じられます。

しかしその一方で、じつはGoogleさんはそれとは別の音声認識サービス「Cloud Speech-to-Text(旧称・Cloud Speech API)」も開発・提供していて、とくにここ半年ぐらいはそれを使ったり試したりする人を目にする機会が増えました。

cloud.google.com
cloudplatform-jp.googleblog.com

そして、これは同じGoogleさんのサービスでありながら、上記のGoogleドキュメントを使った音声入力(を使ったハック)と異なる点が少なくありません。

ということで、今回はそのCloud Speech-to-Textを使って文字起こしをする方法と、それを通して出力された結果がどんな感じなのか、記していきたいと思います。

免責事項

本題に入る前に明記しておきますと、ぼくは普段プログラミングやITに関わる仕事をしているわけではなく、以下の内容はどれも100%趣味のレベルで調べたり試したりしたことですので、間違いを含んでいる可能性もありますし、下記の情報を元にトライした誰かがそれによってなんらかの損害を被ったとしても、ぼくがその責任を負うことはできません。その前提でご参照ください。

Cloud Speech-to-Text の使い方

参考資料

通常、参考資料というのはこういった記事の最後に列記するのが大半だと思いますが、この後に紹介する文字起こしの方法は、そのほとんどがこれら参考資料の刷り直しみたいなものにすぎないので、各記事への敬意と感謝を込めて最初に示しておきます。

投稿された時系列に示しますと、以下の記事群がとても参考になりました。

  1. Google Cloud Speech APIで音声の自動文字起こし
  2. Google Cloud Speech API を使った音声の文字起こし手順
  3. 超初心者でもgoogle-cloud-speechを使えるが、つまずいた所はある。
  4. 【GCP】超超初心者がGoogle speech api を使うところ。(wav形式)

最初の記事では、この手法全体の流れやエッセンスがコンパクトにまとまっています。特徴的なのは、最後に「どういう音声が認識されやすいのか」をまとめてくれているところで、なるほど感がありました。(これについては終盤であらためて言及します)

2番めの記事は手順が非常に詳しく書かれていて、個人的に一番参考になったのはこれだと思います。とくに、認証まわりはけっこうコケやすいというか、めげやすい部分だったのですが、同記事を何度も読み返しながらなんとかクリアできました。

また、最初の記事と2番めの記事には、この後に出てくるPythonのコード例が示されていてとても助かりました。両者のコードは1〜2行を除いてほとんど同じなので、後者が前者を参考にしたのか、あるいは両者が同じ元ネタを参考にしたのかわからないですが、いずれにしてもやりたいことはできたので感謝しています。

※そのコードの元ネタについて、検索し回ったかぎりでは公式ドキュメントのサンプル群から辿りついた以下が一番近そうとは思いましたが、ちゃんとは検証していません。
python-docs-samples/transcribe_async.py at master · GoogleCloudPlatform/python-docs-samples · GitHub

話を戻して、上記3番目の記事はエラー集。じつはこのサービス、一度うまく行った後にもいくつかハマりどころが待っているのですが、そういう「理解したと思ってたのになぜかコケてる・・」みたいなときにこの記事がとても役立ちました。

最後の記事では、WAV形式の音声ファイルを使う場合の方法が説明されています。ネット上の解説記事ではFLACというファイル形式を前提にしたものが大半なので、どうしてもWAVを使いたいという場合にはそちらを参考にするとよいと思います。

音声ファイルを作る

では、ここから具体的な作業について記していきます。

最初に作るのは、今回文字起こしをする音声ファイルです。すぐ上にも書いたとおり、このサービスではmp3やm4aなどではなく、FLACという形式の音声ファイルを使いたいのですが、一般的には、音源をFLAC形式で管理したりはしてないですよね・・少なくともぼくはしてないです。

ということで、ここではmp3などのFLAC以外のファイル形式からFLACに変換し、またその他のいくつか必要な変換操作も一緒にやっておきます。

まず変換前の音声ファイルですが、今回は今年の3月にYAPC::Okinawaで登壇したときの内容の再現動画(Link)から、終盤の数分だけをmp3形式で抜き出しておきました。

soundcloud.com

次に、このファイルを変換するために、無料の音声編集ソフトウェアであるAudacityを立ち上げます。

Audacityについては以下の記事で利用方法等を解説していますので、よろしければどうぞ。

note103.hateblo.jp

Audacityを使った操作は、以下の3つです。

  1. サンプリングレートを44,100から16,000にする。
  2. ステレオならモノラルにする。
  3. FLACファイルとして書き出す。
サンプリングレートの変更

まず、サンプリングレートを変えます。と言ってもこれは一瞬で、左下のプルダウンで切り替えるだけです。

ここから・・
f:id:note103:20180722123132p:plain

こんな感じで。
f:id:note103:20180722123143p:plain

ステレオをモノラルに

次に、ステレオをモノラルにします。上記の画像を見ると、ひとつのウィンドウに2本の波が並行して走っていますが、これがステレオであることを示しています。

逆に言うと、最初からこれが1本だけならこの作業は不要(すでにモノラル)です。

ではやってみましょう。ステレオ音声をモノラルにするには、まず当該音声の枠内を適当にクリックして、
f:id:note103:20180722124546p:plain

そうすると上部メニューバーの「トラック」にある「ステレオからモノラルへ」という選択肢がアクティブになるので、そいつをクリック。
f:id:note103:20180722124557p:plain

すると・・モノラルになります。
f:id:note103:20180722124427p:plain

FLAC形式に変換

最後にFLAC化。これはメニューバーの「ファイル」から「オーディオの書き出し」を選択して、*1

f:id:note103:20180722131327p:plain

「ファイルタイプ」をプルダウンからFLACにして・・

f:id:note103:20180722130603p:plain

右下のボタンで保存。ちなみに、自分ではとくに触っていませんが、フォーマットオプション欄の「量子化ビット数」が16bitになってますね。上記のQiita記事(2番め)によると、これも要件のひとつのようです。

f:id:note103:20180723193626p:plain

すかさずメタデータを記入する画面が出てきますが、ここでは気にせずOK。

f:id:note103:20180722130633p:plain

すると、FLACファイルの出来上がり。

f:id:note103:20180722130651p:plain

Google Cloud Platformにアカウント登録

音源ができたので、次はテキストへの変換作業をするための作業場を用意します。

舞台となるのは、Google Cloud Platform(以下「GCP」)というGoogleさんのサービスです。その中に、今回使用するCloud Speech APIという道具が置いてあり、これを有料で使うことができます。

有料と言っても、GCPに登録した段階で3万円分のクレジット(クーポンみたいなもの)をもらえるので、それを使い切るまでは無料です。(ただし、たしか使い切る前に1年過ぎたら無効になったと思います。記憶だけで書いていますが)

GCPの利用を開始するには、Googleアカウントとクレジットカードの情報が必要です。これは主に身元確認のために必要だそうで、その辺も含めて、登録まわりの方法については、ぼくはすべて以下の書籍を見ながらクリアしていきました。

同書はプログラミングの初心者・・よりはちょっと知識のある、しかしおそらくIT企業の新入社員(または学生)ぐらいの技術レベルに合わせて書かれたような感じで、ちょうどぼくのレベルにフィットするわかりやすい本でした。

今回の記事ではそこまで踏み込んで解説しないので(それもやったら1ヶ月ぐらいの連載になりそう)、詳しいアカウント作成方法については同書やネット検索で解消してください。

新規プロジェクトを作成

アカウントを作ったら、新規のプロジェクトを作ります。

ちなみに、ぼくも普段使っているプロジェクトをここでそのまま紹介するのはちょっと気をつかうので、この記事のために新たなプロジェクトを作ります。

まずはダッシュボードに行って、検索窓で「リソースの管理」を探します。*2

f:id:note103:20180722135005p:plain

「リソースの管理」ページに行ったら、「+プロジェクトを作成」をクリック。

f:id:note103:20180722134206p:plain

プロジェクト名を入れます。

f:id:note103:20180723112830p:plain

ここで一点注意ですが、「プロジェクト名」を入力すると、それに応じた「プロジェクトID」も生成されます。しかし、その「プロジェクトID」は世界で1つだけの(一意の)文字列である必要があり、つまり「MyProject」みたいなコテコテのIDは今さら取れるはずもなく、そのようにすでにIDとして取得されている文字列を「プロジェクト名」として入力した場合には、自動的に「MyProject-192876」みたいなID候補が生成されて、「プロジェクトIDはこれでいいよな? 」みたいに言われます。

「プロジェクト名」の方は一意である必要はなく、なんでも好きなもので良いので、もしIDが「MyProject-192876」とかでも良ければ、気にせずプロジェクト名を「MyProject」にしておけばいいのですが、個人的にはこの「プロジェクト名」と「プロジェクトID」がズレると結構混乱するので(とくに使い始めの頃は)、ぼくの場合はプロジェクト名を付ける段階でグローバルに一意の文字列になるようにしています。

ということで、今回は「note103-speech-sample」としました。左下の作成ボタンを押すと・・

f:id:note103:20180722134236p:plain

はい、できました。当該プロジェクトをクリックして、その中に入りましょう。

(ちなみに、ひとつ上にあるプロジェクト「note103-speech」は普段使っているものなので無視してください)

音声ファイルをアップロードする

では次。先ほど作ったFLACファイルをGCPにアップします。具体的には、GCPクラウドストレージに専用バケットを作って、その中にアップロードしていきます。

まずは検索窓に「storage」と入れて・・Cloud Storageが見つかるので、そこに飛びます。

f:id:note103:20180722182745p:plain

バケットを作成」をクリック。

f:id:note103:20180722182811p:plain

バケット名を登録します。これも先ほどのプロジェクトIDと同様、一意にする必要があるようです。(今のところカブる名前を試してないので、憶測ですが)

ここではバケット名を「note103-bucket-sample」として、ストレージクラスは「Multi-Regional」、場所は「アジア」にします。(ストレージクラスと場所の設定は上記のGCP本で使用していた設定に合わせています)

f:id:note103:20180722182837p:plain

作成と同時にバケットの中に移動するので、アップロードボタンから先ほどのFLACファイルをアップします。

f:id:note103:20180722182912p:plain

速攻で完了しました。バケット内に対象のファイルが入っています。

f:id:note103:20180722182943p:plain

APIの有効化 & サービスアカウントキーの作成

次に、本サービスで利用するCloud Speech APIの有効化と、サービスアカウントキーの作成という作業を行います。が、これについては前掲のQiita記事に詳しい説明があるので、そちらをご参照ください。

qiita.com

ぼくもそれを見てやったのと、それ以上にうまく説明できるわけでもなさそうなのと、なにより同じことをここでくり返しても人類の損失なので・・。*3

なお、サービスアカウントキーを作る際の「役割」という項目について、そちらの記事ではとくに言及されていませんが、未設定のままだと怒られたので、ぼくの方では「Project/オーナー」としました。

Cloud Shell にJSONファイルをアップロード

上記の手続きどおりにサービスアカウントキーを作成すると、自動的にJSONファイルがローカルにダウンロードされます。

今度は、そのJSONファイルをCloud ShellというGCP上の作業環境にアップロードします。面倒な作業が続いていますが、そろそろ佳境というか、案外ゴールはもうすぐです。

Cloud Shellは、GCPの画面のどこにいても大抵開けるようです。たとえば、ダッシュボードからだとこの辺にボタンがあるので・・

f:id:note103:20180722183035p:plain

クリックすると、以下のように画面の下半分にシェル(ターミナル)が出てきます。で、このままここで作業してもいいのですが、個人的にはちょっと画面が狭くて、見通しの悪さが疲れを誘発するので、別画面に展開してしまいます。その場合は、右上のポップアップボタンをクリックします。

f:id:note103:20180722183058p:plain

展開できました。広々〜。

f:id:note103:20180722183208p:plain

ちなみに、このシェル環境はプロジェクトごとではなく、アカウントごとに割り当てられているようです。つまり、複数プロジェクトをまたいで、同じシェル(というかOSというか)を使えるわけですね。

これは非常にありがたいことで、たとえば、今回は踏み込まないですが、.bashrcや.vimrcのような設定環境を複数プロジェクトで共通して使えるということです。

そういう環境の違いというのはじわじわと作業効率に影響を及ぼすもので、たとえば素のVimを使わざるをえなかったり、それがイヤで毎回プロジェクトを作るたびに.vimrcをアップしたりといった手間がなくなるだけでもとても助かります。

話を戻して、次は先ほどのJSONファイルをアップロードします。といってもこれはポチポチクリックしていくだけで、とくにコマンドを打ち込んだりする必要はありません。

まずシェルの右上にあるプルダウンボタンから、「ファイルをアップロード」を選択。

f:id:note103:20180722183240p:plain

先ほどダウンロードしたJSONファイルを選択。「開く」で、アップされます。

f:id:note103:20180722183348p:plain

そのまま、環境変数GOOGLE_APPLICATION_CREDENTIALS」にJSONファイルのデータを設定します。

$ export GOOGLE_APPLICATION_CREDENTIALS=[ダウンロードしたJSONファイル].json

認証まわりについては以上です。

Pythonファイルの準備

では、いよいよ準備の大詰め、命令を実行するためのPythonのコード&環境を用意します。

まず、今回使用するPythonのコードですが、冒頭で紹介したQiita記事に掲載されていたものをほぼそのまま使います。ぼくは出力用のファイル名に関するところだけ微調整して、具体的には以下のようにしています。(ファイル名は「transcribe.py」)

gist.github.com

これを先ほどのJSONと同様の方法でアップロードしてもいいですし、あるいはShell上でVimなどを開いて直接コピペしてもよいと思います。

ちなみに、19行目にコメントアウト行が入っていますが、その行末にある「LINEAR16」というのがWAVファイルを使うときの記述です。もし対象の音声ファイルをWAVにしたい場合には、FLACを指定した18行目をコメントアウトして、19行目の方を使います。

さて、このPythonコードをホームディレクトリに置いて ls を叩くと、こんな感じになります。

f:id:note103:20180722183405p:plain

先ほどのJSONファイル(左端)と、今アップしたPythonコード(右端)がどちらも入っています。

(ちなみに、ここに見えるtmpというディレクトリは普段ぼくがCloud Shell上で使っているデータ類をこの解説のために一旦仮置きしている場所です。今回の作業とは関係ありませんので見なかったことにしてください)

最後に、Pythonを実行するためのライブラリをインストールします。

$ sudo pip install google-cloud-speech

はい。ということで、長い道のりでしたが、これでひとわたりの準備は完了です。いよいよ実行に移ります。

実行

実行の際には、以下のコマンドをCloud Shellに打ち込みます。

$ python transcribe.py gs://note103-bucket-sample/Sample-for-transcript-Cloud-Speech-API.flac

「gs://」以右の部分は、先ほどFLACファイルをアップしたバケット内の場所を示しています。

ちなみに、今回はわかりやすさを優先して音声ファイルの名前を長〜くしていますが、普段はもっと短いファイル名にして、このコマンドも短く済むようにしています。(「sample-01.flac」とか)

では、動かしてみましょう。処理時間がわかりやすいように、動画で撮っておきました。(大半は止まったままですが)

www.youtube.com

はい。大体50秒弱ぐらいで終わってますね。元の音声が2分45秒ですから、3分の1ぐらいの時間で完了していることになります。ちなみに、これは元の音声ファイルが長くなってもほぼ同じぐらいの割合で、60分ぐらいの音声なら20分程度で処理が終わります。(2018年7月時点)

では、仕上がったテキストファイルをダウンロードしましょう。今回のPythonコードでは、書き出したファイル名の頭に「output」というキーワードが付くようにしてあります。(上記のGistで30行目)

また、Cloud Shellからファイルをダウンロードするにはdlコマンドを使用するので、以下のようにすれば必要なファイルをローカルに落とすことができます。*4

$ dl output*

すると、このようなダイアログが出てくるので、「ダウンロード」をクリック。

f:id:note103:20180722203002p:plain

これで、ファイルが手元にダウンロードされます。

結果と講評

では、お待ちかねの出力結果です。この処理はぼくも今回のために初めて動かしたので、どうなっているのかまったく想像がついていません。ドキドキ・・

以下、出力結果をそのままコピペします。改行位置などもそのままです。

ということで前最後のスライドはんですけどもも簡単にまとめますとですねもう色んな活用例をですねご紹介してきたんですけどもないことがあったのかなということちょっと最後にお出しします一つはですねそのまま年表音かあるいはそのエクセルのね作業力で6列いつもより下の階2列ですお金はそういう風に単純作業は行ったとも自分がやんなくてもいいよねっていうことはその機会に行ってもらうみたいな音ことでしょうから単純作業は減るってのはそうとよく言われることだと思うんですけど個人的にはの本質的だなと思っての実はこの2番手ですね自分専用の仕事道具を作る仕事の道具ってのはその専門的になればなるほどそうな自分だけのローカルな道具みたいのが必要になったりあるいはそれがあることによって効率が合体すると思うんですけど
そういうのですねあのプログラミングをすることによってその自分でこうカスタマイズして行けるって言うかその汎用品じゃない山用品誰でも使えるものっていうのはちょっと薄く広くと言うかスネ浅く広くと言うかは誰でも使えるだけに今そこそこしか便利じゃないんだけど自分だけに便利でも他の人は何か便利かどうかも分からんみたいなやつはめちゃくちゃ高効率が上がるみたいなことがあるんでその自分に合わせた道具を作っていくってことがですねできる仲間さっきのとこそそそねえっと IDE の環境そうですけど今ちょっと一瞬またでもに戻りますけどこれとかね
こういうのはその僕が濃いの欲しいなと思って作ってるわけでも誰かが作ってくれたってよりは誰かが作ったのかを組み合わせて声のやってるわけですね
だから他の人にこれが便利かわかんないしもっと便利なのがあるかもしんないですけども僕だけに便利ぐらいのものが作ることによっては非常に効率が上がってるということでその自分のための道具を自分で作るっていうことができるのがま相当いいところなんじゃないかなということですね今これを踏む発表できたのは良かったんじゃないかなと思ってますけど最後にですねまあその楽しみが増えたら楽しくなりたくてもやったことなんでまぁ結果的にそれも多少は多少と言うかかなりという花ですね実現できたかなと思っております

はい。どうでしょうか。マルやテンがないので読みづらいですが、それでも所々に改行が入っているので、一切改行がなかったGoogleドキュメントのときよりは読みやすくなっています。

ちなみに、この改行はどういう法則で生じているのかというと、2分45秒の音声ファイルのうち、ちょうど1分と2分あたり、なおかつ話がふっと途切れたところでちゃんと改行されてるんですね〜。いや、これはすごい。

Googleドキュメントの場合は、ただひたすら1文になってダラダラ起こされていくだけなので、これだけでもかなり使いやすい(編集しやすい)テキストになっていると思います。

それから、上でも少し書いたとおり、この処理にかかった時間は元の音声ファイルの時間の約3分の1です。これについても、Googleドキュメントの音声入力を使った場合はまったく同時間が必要ですから(といってもリアルタイムに入力する前提の機能なので当たり前&そもそも比べる性質のことではないかもしれないですが)、その意味でもより便利になっていると感じます。

さらに、これも非常に重要な点ですが、Googleドキュメントで音声ファイルから文字起こしをする場合は、稼働中に別のアプリケーションを使おうとすると入力が止まってしまいます。

しかし、このCloud Speech-to-Textでは、処理が終わるのを待っている間に別のアプリケーションでどんな作業をしていてもまったく問題ありません。この「別の作業をしながら並行して自動文字起こしができる(勝手にやってくれる)」というのは、考えてみるとぼくが最初にGoogleドキュメントとSoundflowerを組み合わせたときからずっと夢見ていた状況で、もしかするとその夢、ほとんどかなってるのでは・・? と思うほど素晴らしい状況です。

テキストの精度に関しては、こちらをお読みの方それぞれの評価があると思いますが、個人的には「ふえー、ここまで出来るようになったのか、すごいな・・」というのが素朴な感想です。

もちろん、このままではまったく仕上がりとは言えませんし、ここから直していくのもそれなりに大変だとは思いますが、とはいえ、2年前に初めてGoogleドキュメントでこれを試したときに比べたら格段に良くなっていると思いますし、今後もここから悪くなることはないでしょうから、基本的には好印象を持っています。

ハマりどころ

本記事は一応、ある程度全体のフローを理解してからまとめたものですから、それなりにスムーズに、かつ望ましい結果が出ていますが、実際に試しているときはそれはもうエラーの連続でした。

エラーへの対処に関しては、初めの方に参考文献として挙げた記事群がほぼ網羅してくれていますが、個人的にポイントになりそうなところを簡単にまとめておきます。

といっても、大半は次の1点に集約されると思うのですが、それはCloud Shellのセッションが一度切れると、上記で設定した環境変数や、インストールしたライブラリがリセットされてしまうということです。

通常、ローカルの環境でそんなことは起きませんから、当然、一度設定した環境変数やインストールしたライブラリはそのまま維持されるという前提で作業をするわけですが、Cloud Shellはそうではないので、日をおいてログインしたときや、同日中でもしばらく時間が空いてセッションが切れた後だったりすると(たしか1時間未使用とか)、「さっき上手くいったはずのコマンド」がもう効かなくなって、エラーが出てしまいます。

よって、そういうときには落ち着いて、上記の

$ export GOOGLE_APPLICATION_CREDENTIALS=[ダウンロードしたJSONファイル].json

や、

$ sudo pip install google-cloud-speech

を再入力してあげましょう。大抵はそれで直ると思います。

料金

さて、初めの方にも書いたとおり、このツールは基本的に有料です。ただし、アカウント登録時にもらえるクレジットとはべつに、毎月1時間分までは無料です。よって、それほど大量にやるわけではない、という人は無料のままでも長期的に使えるかもしれません。

とはいえ個人的には、現時点での料金もけっして高いものとは思いません。具体的な価格については以下で説明されていますが、

https://cloud.google.com/speech-to-text/pricing

機能 0~60 分 60 分超、100 万分まで
音声認識(動画を除くすべてのモデル) 無料 $0.006 米ドル / 15 秒

前述のとおり60分までは無料で、そこから先は最大100万分まで「$0.006 米ドル / 15 秒」とのこと。1ドル112円として、1分単位で換算すると、「0.024米ドル*112円=2.688円」ということで、1分につき2.688円、1時間なら162円、2時間で323円ほどです。

これがしかも、60分のファイルなら20分の処理時間でこのレベルまで起こされるわけですから、手動で膨大な時間と体力を注ぎながら必死に起こしていくことに比べれば、やはりお手頃かな〜・・と。

録音時の注意点(より正確に起こすために)

一連の手順についてはひとまず以上ですが、ここで一点、大事な知見を共有したいと思います。

上記のサンプルはそこそこ綺麗に起こすことができましたが(と個人的には思っていますが)、音声ファイルによっては、まったく駄目な場合もあります。

そして、その違いが生じる一番の原因は、おそらく録音時に吹き込み用のマイクを使っているかどうかだと思っています。

ここで言う「吹き込み用のマイク」とは、べつに何万円もするような本格的なものである必要はなく、たとえばぼくは3千円ぐらいのヘッドセット(ヘッドホンにマイクが付いてるやつ)を使って録音していますが、そういうのでも充分です。(上のサンプル音声もそれで録りました)

もちろん、仕事で使うようなスタンド付きのマイクでも良いでしょうし、ハンドマイクやピンマイクから採った音でも大丈夫だと思います。

これらに共通するのは、「マイクが口元から音を拾う」ということで、逆に言うと、たとえばICレコーダーをテーブルに置きっぱなしにして録音したインタビューとか、ビデオカメラに付属しているマイクで録った音声とか、そういう「周りの音ごと全部拾った音声」だと、綺麗にテキスト化されないケースが多いと感じます。

この音質については、冒頭に挙げた参考記事のうち、以下でも言及がありました。

qiita.com

曰く、

精度に関係しないもの

  • マイクの感度
  • 話すスピード
  • ノイズ

精度に関係するもの

  • 話者の話し方(明瞭かどうか)
  • 部屋の反響

とのこと。興味深いですね。ICレコーダーやビデオカメラのマイクが駄目なのは、「部屋の反響」と関係しているのでしょうか。

一応、公式ページにも音質に関する言及があります。

cloud.google.com

曰く、

ノイズ低減

  • 雑音の多い音声も正常に処理できます。ノイズ除去の必要はありません。

とのこと。ただ、これはちょっとわかりづらいですね。「雑音」や「ノイズ」の定義が今ひとつ・・。

いずれにせよ、経験的には、ヘッドセットなどの吹き込み用マイクで録音した音声ファイルであれば、そうではないボワーッとした音声に比べてずっと綺麗にテキスト化されます。

ちなみに、ぼくが使っているヘッドセットは以下です。

この商品を選んだのは、日本のTech系ポッドキャストの草分けとも言える*5 Rebuild の@miyagawa さんのブログで紹介されていたからで、

weblog.bulknews.net

(今見たら2017年版は日本語だったのでそちらも・・)

weblog.bulknews.net

それからまる2年使っていますが、今もバリバリ現役で使えていて大変助かっています。

まとめ

ということで、例のごとく長文になりましたが、いかがでしたでしょうか。

Cloud Speech-to-Text、正直、多少のプログラミング知識なりターミナル操作の経験なりがないと実践するのは大変かなとも思いますが、大体こんな感じなのね、という全体像が伝わればひとまずよいかなと思っています。

あらためて要点だけ再掲すると、以前に紹介した、Googleドキュメントを使った場合に比べて挙げられるメリットは以下のような感じだと思います。

  1. 処理が走っている間に他の仕事をできる。
  2. 元の音声ファイルより短時間で処理が終わる。(現時点では3分の1ほど)
  3. 適宜改行が入る。(1分ごとに入る場合が多いが例外もありそう)

デメリットとしては、有料であること、それからくり返しになりますが、ある程度のプログラミングの素養が求められること、といったところでしょうか。

しかしそもそも、以前のGoogleドキュメント&Soundflowerによる文字起こしというのは、本来そのツールが想定している使い方からは少しズレたものだと思いますし*6、それに対してこのCloud Speech-to-Textの方はまさに文字起こしのために開発されているものですから、文字起こしをする用途であれば、こちらを利用する方が自然なのかなとも思います。

また、すでにこの音声認識エンジンを用いたWebサービスなどもあるようですから*7、プログラミングに馴染みがない人はそういったサービスを通してこの機能を利用するのもひとつの方法だと思いますし、逆にプログラマーの人であれば、ぼく以上にこの便利さを実感できるかもしれません。


(了)

*1:ファイルの一部だけを書き出したい場合は、その部分をAudacity内で範囲指定した上で「選択したオーディオの書き出し」にする。

*2:プロジェクトの作成方法はいろいろあると思いますが、ここではその一例を示します。

*3:しかしこういう分担をできるのがWeb記事のいいところですね。書籍でやったら各所から怒られる気がします。

*4:もちろん直接対象のファイル名を指定しても同じですが、手間が減るので自分ではこのようにしています。

*5:実際には「モダシンラジオ」やdrikinさんの一連の番組や長谷川恭久さんの「Automagic Podcast」などの先例もありますが、その後のフォロワーが続発したきっかけは「Rebuild」かな、という意味で。

*6:おそらくGoogleドキュメントの方はリアルタイム入力を前提にデザインされてるので。

*7:自分では試したことがないのでとくに紹介しませんが。

応用情報技術者試験にうかった

びっくり。

gyazo.com

受験前後のことについては以下に書きましたが、

note103.hateblo.jp

並行して簿記の勉強をしていたことなどもあり、今回は記念受験にならざるを得ない・・と諦めていたので、今日の発表を見て一瞬頭がポーッとなりましたね。

上の記事の段階では自己採点できていなかった午後試験についても、その後に資格予備校のTACさんが出してくれた模範解答(予想解答)や、つい数日前にIPAが公開していた公式な解答などとそのつど突き合わせていて、どちらも自己採点では52〜54点ぐらいで、実際にはそこから数点落ちて50点ちょいぐらいかな・・と思っていたので、その意味でも驚きでした。

午前問題は予想どおりの62.5点でしたから、おそらく午後もマークシートの選択式問題は再現答案どおりだったのではないかと思います。

となると、自己採点と実得点の差である8点程度は、ほとんど記述式の見方の違いなのでしょう。

自分では厳しめに「ん〜、近いこと言ってるけど、バツだな」と思っていたところが、おそらく部分点でももらえたのかもしれません。

上の記事にも書いたとおり、今回、午後問題で選択したのは以下でした。

  • 問1 情報セキュリティ
  • 問2 経営戦略
  • 問9 プロジェクトマネジメント
  • 問10 サービスマネジメント
  • 問11 システム監査

自己採点では、これらが上から順に、9-11-11-8-15点で(それぞれ20点満点)、セキュリティとサービスマネジメントが足を引っ張っていました。

経営戦略とプロジェクトマネジメントはけっこう時間を費やしたので、記述式で加点してもらったとしたら、その辺りの可能性が高いでしょうか。(まったくの想像ですが)

これは受かったから言えることですが、今回は午後問題の選択がほとんどすべてだったように思います。

ネットワークやデータベース、組み込み等の技術系をごっそり避けて、経営戦略やシステム監査などのいわば文系的問題に絞ったことで、「その場での計算」ではなく、「文章読解&作問者は何を求めているのか」という想像力や感情移入のセンスで乗り切れたのではないか、と。

自分自身のことを振り返ると、何が苦手といって割り算や小数点を含む計算などではまったく頭が動かない一方、根拠不要な飛躍的な想像とか、相手が今どんな気持ちか? みたいな共感能力みたいなのはけっこう高いようで、今回選択した問題ではそういった部分を発揮しやすかったのかなと思います。

もちろん実際には、今回の問題でも論理的な思考や最低限の前提知識などは必須だったと思いますが、それでも50点を過ぎてからのあと10点(いや8点)を埋めてくれたのはそういう部分だったのかな・・と。

さて、今後ですが、この情報系で何か続きを目指すとしたら、興味の対象としてはネットワーク、素養としてはストラテジ、プロジェクトマネジメント、システム監査あたりかな・・と思っているところです。

とはいえ、それが本当に自分のやりたいことなのか? と言ったらまだちょっとわかりませんね・・。

仕事の合間に使える時間も限られていますから、少し時間をかけて幅広く考えてみたいと思っています。

最後になりますが、これまでITパスポート、基本情報技術者試験を含めて様々な知識を様々な機会を通して教えてくださった先生方に感謝します。

今までどんな勉強をしてきたか? ということはそれぞれの記事に記していますので、ご興味おありの方はぜひどうぞ。

※以下、時系列に記載。
scrapbox.io
scrapbox.io
note103.hateblo.jp
note103.hateblo.jp
note103.hateblo.jp
note103.hateblo.jp
note103.hateblo.jp

Markdownの文章をHTML化して同ネットワーク内の別デバイスから見られるようにするまで

普段、日本語文章による原稿はMacVimで書いてるのだけど(といっても日本語以外の文章は書いてないので「すべての原稿」と言うべきかもしれないが)、最近めずらしく原稿をMarkdown形式で納品する機会があったので、それに関連するハック。

前提

第一に、ぼくが普段Markdownで文章を書く場合、HTMLにレンダリングするということはほとんどない。

というのも、ぼくがMarkdownを使うとしたらそれは文章の「構造化」のためであって、「見栄え」のためではないから。

もう少し具体的に言うと、これは3月のYAPC::Okinawaの発表でもけっこう説明したのだけど、

(この動画の21分9秒ぐらいから。一応そこから始まるはず)

www.youtube.com

画像にするとこんな感じで、

gyazo.com

これはこれでちょっとわかりづらいんだけど、ようは左カラムにあるMarkdown形式の文章のうち、「#」や「##」で始まる見出し部分だけが右のサイドバーに列記されている。

で、これはVimプラグインのtagbarとか、ctagsの設定などを組み合わせて実現しているんだけど、この辺の作り方については上記の動画でも紹介したとおり、以下のSoftware Design誌で @mattn さんが詳しく説明していたのを参考にしてる。

これの何がいいかっていうと、左の文章全体の構造が、右の見出し一覧を見るだけで大体つかめるということ。

右の方をちょっと眺めれば、わざわざ文章全体を上に下にとスクロールしなくても、どの見出しの前後にどんな見出しがあるか、みたいな大まかな流れがわかる。

ちなみに、この画像にあるのはscholaという音楽全集の企画で「ロマン派音楽」を扱ったときのテキストだけど、クラシック音楽のビッグネームであるところのワーグナーやリストやブルックナーといった人たちの当時のリアルな関係、とくには時系列的なつながりが、素人にはなかなか把握できない入り組み方をしていて、作業の終盤に入っても「あの話題はあの話題より先だっけ、後だっけ・・」みたいな整理がつきづらかったので、この見出し一覧機能は本当に重宝した。

話を戻すと、こういうことが出来る、というのがぼくにとってのMarkdownの一番の利点であって、だからわざわざHTMLに変換して眺めることはほとんどない。

なんだけど、じゃあこのMarkdownファイルを他人に見せよう、あるいは仕上がりとして納品しよう、となったらまた事情が変わってくるわけで、とくに仕上がりデータとして渡すということは、渡された相手は当然、HTML変換後の姿を見るわけで、それなら僕もブラウザでの見え方を確認しながら文章を仕上げていかなくてはならない。

ということで、そういうときに役立つのがprevimというウルトラ神プラグインで、

github.com

これについては多分、このブログでも幾度となく紹介しているので多くは語らないけれど、ざっくり動画化してみるとこんな感じで。

gyazo.com

右側のVimに書いた内容が、左側のブラウザの方にリアルタイムに反映されていく。(このときはややもっさりしてるけど・・作業中はそんなに気にならず快適)

ただ、これも一人の作業だったらこれだけで十分なんだけど、他人との協業ということを考えると、「あ〜、今このブラウザで自分が見てる最新データ、そのまま他人にもリアルタイムで見れるようにしたいな〜!」なんて思ってしまう。

先回りして言っておくと、これ、べつにVimにこだわらなくていいなら、ScrapboxとかGoogleドキュメントを使えばそれで解決する。

とくにScrapboxは軽くて快適で、目的さえ一致すれば非エンジニアも含めて誰でも入りやすいツールなので良いと思う。

しかし問題はVimにあるというか、ぼくはあくまでMacVimという自分の執筆環境を維持しながら、また自分ではこのprevimを使いたいという前提があるので、それらを使わない選択肢はここでは外れる。

で、どうしたらいいのか・・といろいろ考えたり試したりしたのだけど、結論的には、

1. VagrantLinuxを立ち上げる。
2. その中でnginxを立ち上げる。
3. Rijiを使ってMarkdownファイルをブログ(HTML)化する。
4. 2のサーバーとVagrantの共有フォルダ機能を組み合わせて、3のHTMLページを同ネットワークから誰でも見られるようにする。

という方法が一番イメージに近いかなと思っている。

手順

ということで、以下はそれを実現する手順。

まず、Vagrantでnginxを立ち上げるところまでは、以前に書いたこの記事でほとんど行ける。

note103.hateblo.jp

ただし、その記事を書いたときからけっこう時間も経っていて、実際に今回やったこととは多少なりズレがあるので、この機会に少しアップデートしておく。

Vagrantの準備

初めにVirtualBoxVagrantをダウンロード&インストールしておく必要があるけど、その辺りの基本的な部分についてはドットインストールさんにお任せ。
(2013年のレッスンだけど、概念的なことは変わらないと思う)

https://dotinstall.com/lessons/basic_vagrant

その上で、以前の解説記事では ubuntu/trusty64 というVagrant boxを使っていたのだけど、今回は公式サイトのクイックスタートガイドで紹介されていたhashicorp/precise64というboxを使ってみる。*1

www.vagrantup.com

ではさっそく、今回作業するディレクトリを作って&入って、上述のboxを指定してvagrant init.

$ vagrant init hashicorp/precise64

このとき、もしまだこのVagrant boxを入れていなかったら、インストールにはけっこう時間がかかる。どのぐらいか? boxにもよるけど、5〜10分ぐらいは見ておいた方がいいかも。

Vagrant boxのインストール&initが完了すると、ディレクトリ内にVagrantfileができる。これはなんだろう、設計書みたいなもの? かどうかはわからないけど、ともかくそれをエディタで開いて、30〜35行目ぐらいに以下を挿入。

config.vm.network "public_network", ip: "10.0.1.100", bridge: "en0: Wi-Fi (AirPort)"

IPアドレスは経験的にその辺が間違いないので使っているけど、なぜそれを使っているかは自分でもわかってない。とりあえず雰囲気でそのアドレスにしている。

またその挿入箇所、実際には1行目でも100行目でもいいと思うのだけど、その近辺にこれがあるので、

  # config.vm.network "private_network", ip: "192.168.33.10"

自分の場合はその下にそれを並べている。

なお、今回共有したいページを他人のマシンや自分の他デバイスから見る必要がなければ、上記のpublic_networkは使わずに、そのprivate_networkのコメントアウトを外すだけでもOK。
ただし、それなら別にVagrant使わなくても、後述のRiji や、あるいは@mattnさんが作ったmemoアプリのサーバー機能を使って閲覧するだけでもいい気はする。

mattn.kaoriya.net

Vagrantfileの編集が終わったら、保存してからおもむろにvagrant up & ssh

$ vagrant up
$ vagrant ssh

これで、Ubuntuの中に入った状態。

nginxを動かす

次、nginxのインストールと起動。これはまったく以前の記事に書いたまま。

$ sudo apt-get update
$ sudo apt-get install nginx -y
$ sudo service nginx start

ステータスを確認。

$ service nginx status
 * nginx is running

で、先ほど設定した http://10.0.1.100/ を見にいくと・・

f:id:note103:20180613131605p:plain

OK。

共有フォルダの設定

次に、ローカルなHTMLファイルを今立ち上げたサーバー経由でブラウザから見られるようにする。

この手順も以前の記事とほぼ同じなんだけど、前に使ったubuntu/trusty64だと/usr/share/nginx/htmlというディレクトリにアクセスしていたのが、今回の場合は最後がhtmlではなくwwwなので、そこがちょっと違う。

具体的には、こんな感じで操作した。

$ cd /usr/share/nginx/
$ sudo cp -r www www_orig
$ ls
www www_orig
$ sudo rm -rf www
$ ls
www_orig
$ sudo ln -s /vagrant www
$ ls -F
www@ www_orig/
$ ls www
Vagrantfile

これで、ローカルの作業ディレクトリとサーバーがつながった状態。

では試しに、そこにhello.htmlなど作ってみる。(最小限で・・)

<!DOCTYPE html>
<body>
  <h1>Hello World!</h1>
</body>
</html>

で、アクセス。

f:id:note103:20180613135700p:plain

OK。(でかい)

ちなみに、この一連の環境構築作業、Vagrantfileにシェルスクリプトで設定してやると、最初の vagrant up コマンドだけで一気に終わる。かなり便利。

具体的には、こんな感じのコードを入れる。(ファイルの終盤にシェルスクリプト用のひな形が用意されていたので、一瞬で出来た)

  config.vm.provision "shell", inline: <<-SHELL
    sudo apt-get update
    sudo apt-get install -y nginx
    sudo service nginx start
    sudo cp -r /usr/share/nginx/www /usr/share/nginx/www_orig
    sudo rm -rf /usr/share/nginx/www
    sudo ln -s /vagrant /usr/share/nginx/www
  SHELL

たしかVagrantの理念というか思想として、「vagrant up 一発で全部終わるってふうにしたかった」的なことを何かの本で読んだけど、たしかにこれで事前にやりたいことはほぼ終わってるのでスゴイ。

Rijiとつなげる

さて、元はと言えば、手元のMarkdownファイルを簡便な方法で他者・他デバイスからも見られるようにしたい、という話だった。

で、ここまでの作業によって、ひとまず「HTMLページさえできていればどこからでも閲覧できる」という状況になっている。

よってここからは、「手元のMarkdownファイルをササッとHTML化する」方法に入るわけだけど、そのためにここで使うのが、Perl製のシンプルなMarkdown用ブログツール、Riji。

github.com

ぼくはPerlに馴染みがあるのでこれを使っているけど、JekyllやHugoでも似た感じにできる気はする。

Rijiの使い方については、作者の@songmuさんによるチュートリアルがわかりやすい。

Riji tutorial

もしまだモジュールが入ってなかったら、とりあえずcpanmでインストールしてから、今回のブログ環境をサクッとセットアップ。

$ cpanm Riji
$ riji setup --force

2行目でforceというオプションを入れているけど、これはデフォルトのsetupコマンドが空ディレクトリでの操作を前提にしているからで、すでにディレクトリ内に他のファイルが入っている場合は、このforceを付ける。

今回は作業ディレクトリにVagrantfileなどが入っているので、このオプションを入れている。

この時点でtreeを見ると、こんな感じ。

.
├── README.md
├── Vagrantfile
├── article
│   ├── archives.md
│   ├── entry
│   │   └── sample.md
│   └── index.md
├── cpanfile
├── hello.html
├── riji.yml
└── share
    └── tmpl
        ├── base.tx
        ├── default.tx
        ├── entry.tx
        ├── index.tx
        └── tag.tx

4 directories, 13 files

このうち、今回の主役であるMarkdownファイルをどこに収納すればいいかと言ったら、上から5番目のarticle/entryディレクトリに入れる。

また、RijiはMarkdownファイルをGit管理しながらブログ化していくので、新たなファイルを作ったり、更新したりした場合には、HTML化する前にコミットしておく。

その後、後述のブログ生成コマンド(riji publish)を叩くと、Vagrantfileやarticleディレクトリなどと同階層にblogというディレクトリができて、その中にHTMLファイルがダダダッと入ってくる。

今回は、すでにarticle/entryディレクトリの中にサンプルのMarkdownファイルが入っているので、それを表示してみる。

riji publish

RijiでMarkdownファイルからブログページ(HTML)を生成するには、本来であれば、以下のコマンドを使う。

$ riji publish

しかし、ここでひとつ注意点。いま「本来であれば」と書いたとおり、この機会ではそのコマンドだけでは足りない。

というのも、なぜかこのコマンドを打つと、HTMLファイルが生成されるblogディレクトリのパーミッションがそのつど700になってしまって、肝心のブログページがブラウザから見えなくなってしまうから。

よって、このコマンドにパーミッション処理も加えて、こんな感じにする。

$ riji publish && chmod 755 blog

と同時に、これを毎回打つのは苦しいので、.bashrcにこんなエイリアスを入れておく。

# .bashrc
alias rjp="riji publish && chmod 755 blog"

これでぼくの場合は、rjpと打てばそのつどMarkdownファイルがHTMLページに変換されることになる。

最後にもう一つ、ブログのルートディレクトリにriji.ymlという設定ファイルがあるのだけど、この中のsite_urlという項目にブログのトップページを仕込んでおくと大変便利になる。今回の場合は、こんな感じ。

site_url: 'http://10.0.1.100/blog/'

これで、ブログ内をリンクでスイスイ動けるようになる。

結果

ページ生成後のブログトップはこんな感じ。(MacBookGoogle Chromeから見たところ)

f:id:note103:20180614000901p:plain:w300

iPhoneSafariから見ると、こんな感じ。

f:id:note103:20180614112109p:plain:w300

そのままトップページからSampleページ(sample.mdで作ったもの)に移動すると、こんな感じ。

f:id:note103:20180614112124p:plain:w300

グレイト。

まとめ

一連の流れをまとめると、VagrantとRijiの設定をした上で、

  1. Markdownで記事を書く。
  2. 作業リポジトリの article/entry にファイルを置く。
  3. git add && commit
  4. riji publish (&& chmod 755 blog)

とすれば、上の例なら http://10.0.1.100/blog に行けばHTML化された同記事を見ることができる。

デザイン

以下はオマケ。ここまで来ると、もうひと押し、デザインにも少し手を入れたいと思えてくる。

デザインについては、チュートリアルのこの辺りでテンプレートの編集方法が解説されているので、参考になる。

http://songmu.github.io/p5-Riji/blog/entry/005_template.html

ぼくがどうしているかと言うと、まずshare/tmpl ディレクトリにあるbase.txを開いて、上の方にあるBootstrap CDNのリンクを別の好きなものに入れ替えている。

Bootstrap CDNについては、こちらがわかりやすかった。(サワリしか読んでいないけど)

codezine.jp

デザインはいろいろググった結果、ここから選ぶのが良さそうだった。

www.bootstrapcdn.com

今回はその中から、Unitedというのを試してみる。

Bootswatch: United

変更前のこれを・・

  <link href="//netdna.bootstrapcdn.com/bootstrap/3.0.0-rc1/css/bootstrap.min.css" rel="stylesheet">

これにする。

  <link href="https://stackpath.bootstrapcdn.com/bootswatch/4.1.1/united/bootstrap.min.css" rel="stylesheet">

またついでに、現状だと全体に左上の方に寄っているので、少し右下に動かしたい。
さらについでに、フォントを少し大きくしたい。
ということで、諸々雑にこんな感じで追記。

<div style="margin-top : 30px">
<div style="margin-left : 5%">
<div style="margin-right : 5%">
<font size="+1">

変更前。

f:id:note103:20180614133053p:plain:w300

変更後。

f:id:note103:20180614133111p:plain:w300

iPhoneから見たところ。

f:id:note103:20180614151100p:plain:w300

オッケー。

感想

長文を書いていると、避けがたく誤字脱字や壊れた言い回しなどが生じてくるが、これに自分で気づくのはなかなか難しい。

その理由としては、書いている人間が「そこに何が書いてあるのか」を誰よりも知っているがゆえに、「あまりきちんと読み直さないから」ということがあるだろう。

言い換えれば、「飽きるから」。

しかしこのような、個人の日記レベルの文章ならばともかく、他人に見せる、それも仕事として渡す前提の文章だったら、「飽きるから」なんて理由で不備だらけの文章を作ることもできない。

そのようなとき、その「飽き」を解消する方法として有効なのは「他人になること」で、一番簡単なのは時間を空けてまた読むことだろう。

しかしそれだけの余裕もないのなら、読む環境を変えるのがいい。ここで言う「環境」とは、場所もそうだけど、おもにはデバイス
ついでに、ページの背景やフォントなどの見栄えが変わればなお新鮮に読めるかもしれない。

文章(ページ)の見え方が変わると、自分の中に擬似的な時間移動が生じて、まるで他人の書いた文章のようにそれを読むことができる。

同ネットワークにいる他人に読ませる方法としても、他人のような自分に読ませる方法としても、本記事の手法は地味に役立つように思う。

*1:以前はドットインストールさんの何かの解説動画でtrusty64を使っていたからそれに準拠したのだけど、今回念のため探したらその動画が見つからなかったのと、とりあえず公式のスタートガイドにあるものを使った方がより安心かと思ったので。

JupyterにPerlを入れてMacで使うまで

Jupyterという、ブラウザで動くエディタ兼ターミナルみたいなものがあるらしく、基本的にPythonで使われているようなのだけど、Perlも動くっぽい、と何かで見たのでやってみました。

jupyter.org

Jupyterとは

概要的には、ググって最初に出てきたこちらの冒頭の説明がわかりやすかったです。

Jupyter Notebook を使ってみよう – Python でデータサイエンス

Jupyter Notebook (読み方は「ジュパイター・ノートブック」または「ジュピター・ノートブック」) とは、ノートブックと呼ばれる形式で作成したプログラムを実行し、実行結果を記録しながら、データの分析作業を進めるためのツールです。
プログラムとその実行結果やその際のメモを簡単に作成、確認することができるため、自分自身の過去の作業内容の振り返りや、チームメンバーへ作業結果を共有する際に便利なほか、スクール形式での授業や研修などでの利用にも向いています。

経緯

事の発端というか、そもそもなんでそんな事しようと思ったかというと、仕事の合間にふと息抜きでこちらを見ていたら、

www.youtube.com

プログラミング入門者にanacondaのインストール一発でPythonとJupyterの環境を同時に作る手順を丁寧に解説してるんだけど、それを見て「うわ、こんなに簡単にスタートできるのか」と驚きながらとりあえずJupyterの環境まで作って、そこでふと「これでPerlも動かないかなあ」と思ったのでした。

IPerl

Perlを使えるようにする手順としては、Qiitaに書かれたこちらがわかりやすかったのですが、

qiita.com

あいにくここで紹介されているのはCentOSへのインストール方法だったので、ぼくが使っているMacへの導入となると、部分的に読み替えが必要になります。

ということで、大枠は上記Qiita記事で把握しつつ、主要モジュールと思われるDevel::IPerlのリポジトリへ。

github.com

READMEをしばし熟読。なるほど・・ということで、すでに上記動画をもとにPython3とJupyterは入っているので、そのREADMEにあるZeroMQ(zmq)と、PerlモジュールのDevel::IPerlを入れてあげれば良さそうです。

前者については、macOS版なのでこちら。

https://github.com/EntropyOrg/p5-Devel-IPerl#macos

で、Jupyterのところは飛ばして、モジュールインストールのこれ。(といっても1行だけど)

https://github.com/EntropyOrg/p5-Devel-IPerl#install-from-cpan

で、めでたく完了!

と思いきや、動かない・・。

それからしばらく、何が足りないのかとあちこちいじったりググったりしていましたが、結果的にはこれで。


ぼくはPerlのヴァージョン管理でplenvを使っているのですが、こういうときは大抵plenv rehashが必要なのですね。

今回もそれをやらずに「動かない・・」とかやっていました。

$ plenv rehash

で、動くようになりました。

実行

具体的には、ターミナルでどこか作業したい場所に入ってから、

$ iperl notebook

または

$ jupyter notebook

でブラウザがブワッと開いてくれます。

https://i.gyazo.com/5a5a41df4516fec292fc17486e430cd7.gif

いい感じです。

ちなみに、サブコマンドのnotebookをconsoleにすると、ターミナル上で同じことができるようです。

$ iperl console

gyazo.com

ということで、これで「ぼくも流行りのJupyterでPerlを動かしたい!」という目標を達成できました。

用途的には、普段から小さなPerlのサンプルコードを手元で一瞬動作確認したい、みたいなことがよくあるので、そういう時に使いやすいかなと思っています。

ローカルのファイルからデータを入出力したり、標準以外のモジュールを使ったりすることもできるようです。

https://i.gyazo.com/f8a9e1aa7e978c4e48ae456101ffa43e.gif

素晴らしい!

応用情報技術者試験を受けてきた

昨日2018/4/15、応用情報の試験を受けてきました。場所は東京情報大学というところです。

昨年10月に基本の方になんとか受かって、

note103.hateblo.jp

さて、これからどうしよう、応用も行くかどうか・・と悩んでいました。

悩んだ理由は、単純に「難しいかも」というのもありましたが、それとは別に、最近簿記2級の勉強を復活しているので、仕事に加えて異なる種類の勉強を2本同時にやるというのは、どっちつかずになって効率悪いかもな・・というのが大きかったです。

ただ、それでも今は基本情報技術者試験のための知識が一番残っているときでもありますし、今のうちにその辺をもう少し頭や体に定着させておきたい、という貧乏性的な気持ちがあったのと、あとはやっぱり、これは以下にも書きましたが、元々のこうした情報系資格試験を受けようと思ったきっかけとして、ちょまどさんが「基本も応用も合格した」という話が根っこにあったので、

note103.hateblo.jp
(例によって長い記事ですが、真ん中ぐらいで言及してます)

ひとつのキリとして応用まで行けたら綺麗だよなあ、という気持ちが根強くあって、結局申し込んだのでした。

しかしその後、やはりというか、けっこう頭の使い方が異なる2つの試験勉強を並行するのはきついというか、片方がわかりかけたときにもう片方をやらなきゃいけない、という感じでロスが大きいように思ったので、ちょうど4月に入ったぐらいから、思いきってより優先的な簿記の方に舵を切ることにして、応用の勉強はストップしていました。

そしてそのまま2週間ぐらい、時間ができるたびに簿記の勉強にすべてを費やしていたので、「もうこれじゃ応用、受けに行っても時間のムダだなあ〜・・。行けば丸一日つぶれるし、受験料はもったいないけど、休むか」と思っていたのですが、試験の前々日ぐらいになって、彼女から「応用はどうするのか」と聞かれて、「いや〜、迷ってるんだけどね〜・・」と、本当はもう行かないつもり95%ぐらいでしたが、ちょっと体裁が悪かったのであたかも迷っている風にぼんやり答えたところ、「行った方がいいんじゃないの」と言われたので「あ、はい」という感じで行くことに方針転換し、当日は朝からすさまじい暴風雨でしたが、もろともせずに(というか諦念と共に)行ってきた次第でした。

前回と前々回に基本情報を受験した会場は、たしか新習志野の千葉工業大学で、行く道すがら応用の教科書を読んでいる受験生もいたようだったので、当然今回もそこだと思っていましたが、結局そのように受験前日になって慌てて受験票に写真を貼り付けたり、会場の場所を確認したりしていたところ、今回は千葉の千城台というところにある東京情報大学で、初めて行く場所というだけでなく、アクセス的にもだいぶ時間や労力を費やしそうだとわかって暗澹たる気持ちになりましたが、実際にはJR千葉駅から大学前まで1本で行けるバスがそれなりの頻度で(日曜でも)走ってくれていたので、それほどの苦労はありませんでした。

とはいえ、当日は上記のとおり暴風雨で、基本的に皆同じバスで向かうだろうと思えたので、試験開始の1時間前には着くよう早めに出発したのも良かったのだと思います。

会場に着くと、基本情報のときとちょっと違うなと思ったのは、おじさんの割合が少し多かったことでした。

基本情報のときは、周りは若者ばかりで、高校生ぐらいに見える人も少なくなく、「うーん、やはりIT系の資格で、自分のように40代に入ってからわざわざ受けにくる酔狂な人はいないんかな」と感じ、「おじさんもどんどんこういう勉強したらいいのに、いろいろ役立つのに」などと偉そうに思ったりしていましたが、応用の会場には自分と同世代か、もしかしたらちょっと上かも、ぐらいの人もいて、ただこれは後から思いましたが、応用の場合は、これはこれでべつにぼくのような勉強とか趣味とかいう理由ではなく、仕事に関わるというか、この資格があれば昇進とか昇給とか転職とかに有利とか、そういった理由によるものかな・・とも思ったりはしましたが。

女性の割合は、あくまで感覚的なものですが、基本情報のときの方が多かったかな・・という気はしました。
やっぱり受ける世代が若くなるほど、女性の割合が多くなるのかな・・と、狭い観測範囲からざっくり感じているところです。

会場に到着後、ひとしきり筆記用具などの準備を終えた段階で、まだ試験開始まで45分ぐらいあったので、とりあえず何か飲み物でも買おうと思って構内を探しましたが、自動販売機がありません。

あれ、と思って入り口で案内をしていた職員の人に聞いてみたところ、今いる棟を一旦出て、向こうの何号館だかのそばにある、と教えてもらいましたが、その職員さんが指差す先、自動販売機のあるらしい場所と現在地との間には風雨が荒れ狂っており、今ここでそんなエネルギーを使ったら試験にもろ影響しそう・・と思って諦めました。

代わりに、昼ごはんのためにサンドイッチとおにぎりを買っておいたのですが、これは自分にはちょっと多くて、どちらかを残すことになるだろうと思っていたので、このうちおにぎりの方を食べてしまうことにしました。

以前からのささやかな知見として、のどが渇いたときには何かを食べると解消する、ということがわかっていたからです。
(食べ物にもよると思いますが)

思ったとおり、おにぎりを食べ終わる頃には水を飲みたい気持ちも消えていて、安心して試験開始を迎えられることになりました。

ちなみに、なぜそれらの弁当を用意した段階でお茶も買っておかなかったのかというと、それらはすでに前日のうちに買ってあって、家から持参したので、そのときに飲み物まで持っていくと荷物が重くなると思ったからでした。

もちろん、そうした前提には、会場である大学構内に自動販売機があるだろうという考えがあったわけですが、それがなかったので問題になったわけでした。

教訓としては、小さいお茶でもいいので、昼休憩までもつ程度の飲み物は持参しておいた方が安全だなということがわかりました。

午前の試験が始まって、すぐに思ったのは「イスが硬い・・」ということでした。

以前の会場ではとくに感じなかった気がしますが、今回はけっこう顕著な感覚で、途中で何度も座り直すなど、これをやり過ごすのには苦労しました。

資格試験に関わるセオリーみたいなもので、会場に座布団を持っていきましょう、みたいな話を聞いたことはありましたが、これまでの経験ではそういった必要性を感じたことがなかったので、自分には関係ないと思っていました。
しかし今回の経験で、今後はちょっとそれ、本格的に考えた方がいいなと思いました。

なお、一応フォローしておくと、今回の大学が他に比べてとりわけイスが硬いのかどうかはわかりません。
今回は「どうせ無理」という前提もあり、そこそこリラックスしていたので(緊張感が薄いというか)、その辺まで感覚が行き渡ってしまったのかも、とも思います。

その午前の試験、自分は計算の必要な問題が苦手だとわかっていたので、知識や記憶ですぐに答えられるものをまずどんどん回答(マークシートにマーキング)していきました。

具体的には、回答したものには問題用紙の問題番号の部分に◯とか◎とか△を付けて、すぐに回答できなかったものについては、「↓」とか「?」を付けていきました。

これらのマークは、以下のような意味です。

自信アリ
多分大丈夫
合ってるかもしれないけど間違ってるかもしれない
時間をかけて考えればわかる可能性があるけど、とりあえず後回し
皆目わからん。問題が何を言ってるのか意味不明

これで一度最後まで行ったら、そのまま逆方向にページをめくりながら(第80問から第1問に向けて)、マークミスがないかをチェックしていきました。

この際、「↓(後回し)」マークのうち、「ちょっと考えればできそう」みたいなものがあれば取り組んでしまい、回答が出たらそのままマークします。

これでまた第1問まで戻った頃には、全体の7割強ぐらいは埋まっている状態で、感触としては、「そこそこ出来てるじゃん」みたいな感じでした。

まあ、「自信があるもの」から順に埋めているので、当然といえば当然ですが、とはいえ、自信があるもの&そこそこ出来そうなものだけで7割以上埋まっているということは、この時点で合格基準点の60点を超えている可能性もけっこうあるわけで、にわかに「午前は行けるかも」と思えたのも自然なことだとは思います。

(ただし実際には、この時点ではまだ全然基準点を超えておらず、それどころかだいぶ厳しい状態に置かれていたことが帰宅後、自己採点をしてみてわかったのですが)

そこまで来たら、今度はまた第1問から、上記で「↓」や「?」を付けた問題のうち取り組みやすそうなものを選んで回答していきます。

ただし、ここであまりレイヤーを分けると後がつらくなりそうだったので、この段階ではもう「超絶難しい、当てずっぽうでやるしかない」か、「時間をかければできるかも」の2段階程度までに分けることにして、後者だったらその場で解く、という感じにしました。

これで最後まで行ったら、最後に残った「超絶難しい」グループに答えていきます。というか、当てずっぽうタイムなわけですが。

といっても、ここまで来るともう残り10問もなかったと思います。
それらについて、一応問題も読んでから、「それらしいやつ」を選んでマークしていきます。

後から自己採点をしてわかったことですが、この当てずっぽうグループが3〜4割程度当たっていたようです。

そしてこれも多分あとで書きますが、自己採点の結果は、80問中50問正解、基準点60点に対して62.5点だったので、これらの「まぐれ当たり」がなければ余裕で午前で落ちていたと思います。

さて、そんな状況とはつゆ知らず、「けっこう出来てんじゃん」とほくほくしていたこともあり、一旦すべての問題に回答し終えた頃から、基本情報の時にさえやらなかった「途中退室」を考えはじめました。

というのも、午前をフルで受け切ると、試験が終わるのが12時ちょうどで、午後試験は13時スタート、しかしその事前の説明は15分前ぐらいから始まってしまうので、昼食の時間はもちろんのこと、午後のための最後の詰め込みや、休憩を取る時間すら実質的にはほとんど取れないことになります。

今回はまともな試験勉強をしていない前提ではあったものの、やるからにはギリギリまで情報を頭に詰め込んでおきたいと思っていたので、そのまま「午前の回答を見返す時間」と、「午後のための勉強に使う時間(および休息)」とを天秤にかけて、より得点効率の高そうな後者を選びました。

といっても、その午前問題に回答しきって、マークシートの回答漏れやズレがないことを確認し終えたのは、退室可能なリミットである11時半の数分前で、まだ充分に見直しをしたわけでもなければ、これまでの試験で途中退室をした経験がなかったこともあり、やはりそこで出るのは不安が大きかったです。

実際、答案を提出してから、あれ、受験番号ちゃんと書いたっけ・・という不安に襲われましたが、上記のように、両方のメリットを取ることはできないので、それならそれで仕方ないと割り切りました。

初めての途中退室をギリギリで果たした後は、午前に確認した自動販売機の場所まで行って、お茶を買いました。

この時にはすでに雨は上がっており、風だけが勢いを増していましたが、それでも広々とした大学の敷地は懐かしいような、自由なような雰囲気があり、一瞬でけっこうリフレッシュできました。

会場近くの静かなスペースを見つけて、サンドイッチを食べながら午後対策の参考書を読みました。

午前問題に関しては以下の過去問を使いましたが(ぼくが実際に持っているのは平成29年度版ですが、ここでは新しい方を貼っておきます)、

(全文PDF・単語帳アプリ付) 徹底攻略 応用情報技術者過去問題集 平成30年度春期・秋期

(全文PDF・単語帳アプリ付) 徹底攻略 応用情報技術者過去問題集 平成30年度春期・秋期

  • 作者:五十嵐 聡
  • 出版社/メーカー: インプレス
  • 発売日: 2017/12/26
  • メディア: 単行本(ソフトカバー)

午後対策としては、以下を使いました。

平成30-01年度 応用情報技術者 試験によくでる問題集【午後】 (情報処理技術者試験)

平成30-01年度 応用情報技術者 試験によくでる問題集【午後】 (情報処理技術者試験)

  • 作者:大滝 みや子
  • 出版社/メーカー: 技術評論社
  • 発売日: 2018/03/13
  • メディア: 単行本(ソフトカバー)

後者の著者である大滝みや子さんの本には、冒頭で挙げた以下の記事にも書きましたが(再掲)、

基本情報技術者試験にうかった - the code to rock

基本情報の学習時にずいぶん助けてもらいました。

今回の本でもポイントが非常に絞られ、丁寧にまとめられ、なおかつとても親しみやすい語り口でスイスイ書かれているので、ともすれば悲壮感に包まれそうな直前の詰め込み作業にも、最小限の負担であたることができました。

そして実際、このときにパラパラとめくってはフムフムと眺めていた、「システム監査」のページに書かれていたキーワードがその後の試験にバッチリ出てくれて、かなり助かりました。
「試験によくでる」と謳われている本ですが、少なくともぼくにとってはまさにその通りでした。

ちなみに、前者の過去問集ですが、こちらは同書掲載の直近回である平成28年度秋試験、その1回分だけを80問すべて事前に解いておき、その間違えた箇所や、正解した設問でも意味のわからない選択肢やキーワードがあれば、対面ページにある解説に目を通すようにしていました。

対象を1回分だけにしたのは、単純に時間がなかったからでもありますが、それ以上に「一度間違えたところ」や「一度目を通した問題・解説」をくり返し読めるようにするためでした。

同じ時間を使って、新しい80問に取り組めばあと1回分(平成28年度春試験など)は解けたと思いますが、それよりも限られた問題をきちんと理解した方が効率がいいはずだと思いました。

あるいは、基本情報の勉強で使った過去問をもう一度確認して、苦手箇所を基礎から勉強し直すという方法も考えていましたが、これも結局は時間との兼ね合いで、応用の過去問に集中した方が手っ取り早く得点につながるはずだと思い、午前対策としては、その応用の過去問から直近の1回分に絞りました。

感触としては、その戦略は功を奏したように思われ、そこで出てきたのと同じ問題や、それに類する問題がいくつもあり、なにしろ直前に目を通していたので答えごと覚えているようなものもあり、午前をパスできたのは(あくまで自己採点ですが)そのおかげもあるかなと思っています。

昼休憩が終わり、午後に入り、イスが硬いなと思いながらもなんとか最後まで終えました。

今回の目標は、「午前合格、午後は回答欄を埋めきる」というものでしたが、残念ながら、午後に選択した問題の回答欄を埋めきることはできませんでした。

今回選択したのは、必須問題である第1問「情報セキュリティ」をはじめ、以下でした。

  • 問1 情報セキュリティ
  • 問2 経営戦略
  • 問9 プロジェクトマネジメント
  • 問10 サービスマネジメント
  • 問11 システム監査

じつは今年の3月頃、まだ日々の学習を簿記に振り切る前の段階では、第3問の「プログラミング」や、第5問の「ネットワーク」、それから第6問の「データベース」なども選択対象の候補に含めていました。

というのも、元々はその辺りの技術について詳しくなりたい、という気持ちが受験理由の一つにあったからで、逆に言うと、仮にマネジメント系の問題で合格したとしても、あまり達成感がないというか、そんなに嬉しくない・・という気がしていたからでした。
あくまで、技術的な分野で腕を磨きたいな、という。

しかし、今回の勉強時間でそれらに手を出すのは自滅と言うに等しく、おそらくトライしたとしても、わからなすぎてまったく面白くないだろうと思い、結局選択問題はすべて非技術系(ストラテジ&マネジメント系)で固めることにしました。

といっても、じつは第10問の「サービスマネジメント」というのが、基本情報のときには比較的相性が良かったカテゴリでしたが、この応用情報ではやけに難しく感じられることが多く、一方、第8問の「情報システム開発」を過去問で見たときには、存外スラスラ解けることがあったので、このどちらを取るかは当日に問題を見るまでわからないな、とも思っていました。

果たして、本試験の問題を見てみると、相性が良かったはずの「情報システム開発」の方はバリバリのプログラミング系、すなわち、オートマトン風の図や、擬似言語プログラム、あるいは聞いたことのないキーワード(サイクロマティック複雑度・・?)が踊り狂う問題になっており、ひと目で「サービスマネジメントにしよう」と決まりました。

マネジメント系をはじめとする、いわば文系的な問題では、問題文が小説のような架空の物語を舞台に作られており、これがなかなか面白く読めます。

そしてこの点は、「技術的な要素を避けられる」ということ以外の、これらの問題を選ぶ上でのメリットだと感じます。

ぼくは正直、他人が書いた長文を読むのは苦手なのですが(嫌いなのではなく、頭に入ってきづらいことが多いので)、どうしても読まなければならないのだとしたら、こういうフィクション仕立てのものの方が飽きずに読めて、楽しめます。

とはいえ、限られた試験時間を有効に使うためには、漫然と頭から読むのでは効率が悪いので、最初の1〜2段落だけ読んで概要を掴んだら(あるいは無理にでも掴んだ気になって)、先に設問の方にすべて目を通します。

そうすると大体、問題文中のどの箇所(空欄や下線など)に対して、どんな問いが投げかけられているのかがわかりますから、まずはその「問い」の方をある程度読み込んでから、そういう問いが来ることを前提に、問題文に戻って頭からスラーッと読んでいきます。

ちなみにこの際、問題文で空欄を問うものがあった場合、問題文全体を読まなくても、空欄を埋める選択肢や、その空欄前後の文脈だけで答えがわかる場合が少なくありません。
よって、それで埋められるところはこの段階で回答してしまいます。

応用情報の午後問題では、基本情報との大きな違いとして、記述式の部分が少なからずあります。

5字以内で答えよ、というものから、長いものだと45字以内、とかでしょうか。

これについては、多少は過去問や、上記の大滝さんの本などで「答え方」を練習してはいましたが、ぼくはこの「字数に収めつつ言いたいことを過不足なく言い切る」という作業で時間をかけすぎてしまったように思います。

じつのところ、この「字数に収めつつ言いたいことを過不足なく言い切る」というのは、ぼくが仕事でやっている編集作業のど真ん中で使うスキルなので、むしろ有利では? という気もしますが、ぼくの場合は、仕事であればとくに、ある程度納得行くまで直し続けたりするので、その「直しすぎる(時間をかけてしまう)」というのが足を引っ張ってしまったかなと。

もちろんというか、プロの編集者の中には、パッと見てパッと文字数に収める、みたいなスキルが高い人も多いと思うので、そういう人には有利かもしれないですが・・。

とくに今回の場合、第9問のプロジェクトマネジメントで、その文章づくりにちょっと時間をかけすぎました。

時間配分としては、本来1問につき20〜25分程度で進めて、残った30分程度を、後回しにした問題なり、見直しなりにあてようと思っていましたが、この第9問では、7〜8割ほど回答するだけでも35分ぐらいかけてしまい、時間の貯金をだいぶ使ってしまいました。

今「後回しにした問題」と書きましたが、この午後問題でも、午前と同様、時間がかかりそうな難しい設問には深入りせず、サクッと解けるものから埋めていきました。

結局は、その後回しにした問題を埋めるだけの時間を最後に確保できなかった、というのが途中答案になってしまった敗因なのだと思いますし、そのまた要因になったのが、プロジェクトマネジメントの問題だったのだと思います。

ちなみに、プロジェクトマネジメントに時間がかかったのは、上記のような文字数の調整や、言い回しを適切にすることについこだわってしまった、ということもあると思いますが、同時に、その架空の世界に入り込みすぎた、というのもあるかなと思っています。

難しい設問には深入りしないように注意していましたが、問題世界の方に深入りしてしまったというか、つい時間を忘れて、その中の登場人物たちに感情移入してしまったような、そういう感覚がありました。

架空の世界を元にした問題文には、「退屈せずに集中できる」というメリットがあると書きましたが、そういう思わぬデメリットもありそうだとうっすら感じます。

空欄のまま提出、という残念な部分はあったものの、すべて終わったときの感覚としては、「思ったより、できたな」という感じでした。

「こりゃ、受かるな」というほどではないですが、前々日まで行かないつもりだった試験とは思えないほどの成果とは言えます。

帰り道には、ちょうどバスが出てしまったばかりだったこともあり、次の次ぐらいの停留所まで、バス通りに沿った一本道を歩きながら、最近なぜかハマっているサザンオールスターズの『バラッド』を聴きました。

バラッド '77~'82

バラッド '77~'82

このアルバムは、「いとしのエリー」「Oh! クラウディア」「Ya Ya」などの有名曲が揃っているベスト盤のようなものですが、個人的には「ラチエン通りのシスター」「涙のアベニュー」「恋はお熱く」「わすれじのレイド・バック」あたりを好んで聴いています。

こういうのを聴いていると、サザンは日本のブルースであり、ソウルだなと感じます。
猥雑で、なんでも取り込みながら国民音楽的なポピュラリティを醸し、なおかつ最後にはサザンでしかない音に仕上げてくるところには生真面目さすら感じますし、それより何より、桑田佳祐の歌はすごいです。生きているうちに聴けて良かったと思います。

気がつけば、永遠に続くかと思われた暴風はすっかり収まっていて、空は不穏な灰色に覆われていたものの、わずかに湿った春風に吹かれるこの帰途は、なかなか心地よいものでした。

帰宅後、頭が覚えているうちに午後試験の再現答案を作りました。

択一式の問題に関しては、持ち帰った問題にすべて回答がマークしてあるので、その必要はありませんが、記述式の方ではメモ程度にしか書き残していないものや、答案に転記した際に少しアレンジしたものや、試験の最後の方ではメモすら取る時間がなく、直接答案に書いたものも少なくなかったため、このままだと解答が発表されても自己採点をできないと思ったからです。

といっても、じつは普段は簿記にしても、前回の基本情報にしても、自己採点なんてやっても落ち込むだけだからと進んでやることはほとんど無いのですが、今回は元々どこか吹っ切れていたせいか、できるところまでやっておこう、みたいな意識高いモードになっており、やっておくことにしました。

必ずしも厳密ではないものの、ひとまずすべての再現を終えた頃、午前問題の解答が公開されました。

IPA 独立行政法人 情報処理推進機構:問題冊子・配点割合・解答例・採点講評(2018、平成30年)

午後問題の解答が公開されるのは、合格発表の5日前である6/15とのことで、おいおい、それなら自己採点用の答案、わざわざ作る必要なかったのでは・・とそのときに思いましたが、まあ答案用紙は戻ってこないはずなので、覚えているうちに再現しておけたのはやはり良い面もあったと思います。

と同時に、ここで午前分の自己採点も一気にやってみたところ、上記のとおり、合格基準点60点に対して、62.5点でした。

調子に乗って途中退室なんてしたわりには、思ったよりギリギリで焦りましたが、その後にあらためて正答・誤答状況を確認してみたところ、自信がなかったり当てずっぽうだったりした部分がけっこう当たっていて、それがなければ落ちていたのだとわかり、さらに焦りました。

自信アリの回答については、正解のものが多かったですが、「ちょっと自信ないけどたぶん大丈夫だろう」というものが案外どれもこれも間違っていて、これが実力というものか、と痛感しました。

午後問題については、上記のとおり、終わった時点での感触は「悪くない」という感じで、とくに択一系の(記述式ではない)問題についてはそこそこ自信があるつもりでしたが、この午前の結果を見るかぎり、やはり期待はしづらいな・・と思っているところです。

最後に免責事項を。

途中でいろいろと勉強法について偉そうに書きましたが、自分では通ったと思っている午前問題すら、まだ結果は出ていませんし、ましてや全体に関して言えば、「この方法を実践すれば受かる!」みたいなことはまったく言えませんので、あくまでそのような前提として捉えてほしいと思います。

さて、合格発表は6/20ということで、なんと2ヶ月以上先ですか。

記述式の答案がある以上、仕方ないと思いますが、基本情報の方が合格発表まで1ヶ月だったにもかかわらず、かなり長く感じましたので、この応用については、一旦「忘れておく」ぐらいの方がいいのかもしれません。

考えてみれば、それ以前に6/10、ぼくが現在、勉強分野としてはメインで取り組んでいる日商簿記検定2級の試験もありますので、まずはそこに向けて集中するべきでしょう。

ともあれ、以上、応用情報技術者試験を初めて受けた感想を、記憶の鮮明なうちに記録しておきました。

ボッチでもOK

こちらは「春のPerl入学式リレーブログ」の7日目の記事です。
blog.perl-entrance.org

ひとつ前は、 id:kousy さんによる以下の記事でした。
kousy.hatenablog.com

Perl入学式での経験が仕事につながるというのは、すごすぎますね! 敬服します。
東京でのプログラマー生活、ぜひがんばってください。

今回の記事では、ぼくが初めてPerl入学式に参加したときのことを書きます。

ぼくが初めてPerl入学式に参加したのは、38才の夏でした。
これは同時に、ぼくがプログラミングの講義に参加した最初の機会であり、また初めて「プログラマー」と呼ばれる人々に対面した日でもありました。

その時のことは、以下の記事に書いています。
note103.hatenablog.com

今でもそうですが、ぼくは当時からプログラミングにまったく関係のない仕事をしていて、IT企業に勤める知り合いもいなかったので、このときには一人で参加することになり、会場には知ってる人が誰もいませんでした。

緊張していたせいか、時間よりも少し早めに会場に着くと、サポーター(スタッフにあたる人々) の id:papix さんや id:mackee_w さんたちもちょうど同じぐらいに着いていて、同じエレベーターに乗って上の階まで一緒に上がりました。

papix さんたちにはその時に少しだけ挨拶をしましたが、その後は基本的にサポーターさんはサポーター同士で楽しそうに話をしていて、今だから言えることですが、ぼくはうっすらと疎外感のような気持ちを抱いていました。

なにしろ、ぼくは年齢的に他の皆よりひと回りも(あるいはそれ以上に)離れていましたし、ITに関係ない仕事をしているのでその話題もまったく意味がわからず、周りに知り合いもおらず、Perl入学式自体も初めてで、さらにはその年の第3回の補講という、中途半端な回からの参加でもありました。

言うまでもなく、その疎外感はぼくが勝手に感じていたもので、サポーターの人たちから嫌な態度を示されたとかいうことは一切ありません。

ただ、自分以外の人は皆知り合いで、その人たちが共通の話題について楽しそうに話している、というその状況が、なんというか、チョット厳しかったわけです。

そしてぼんやりと、「ああ、自分が来るところではなかった」という気持ちになりました。

「呼ばれてもいないのに、身の程も知らずに、なぜこんな冒険をしてしまったのだろう?」と。

「あと何時間、この状況に耐えればいいんだ・・」と。

しかしながら、ボッチでも構わないから参加しよう、と思ったのは自分自身です。

とにかく時間が終わるまで頑張ろうと、そこは38才、なけなしの社会性を発揮して、こめかみには脂汗を浮かべながら、また周りの受講生の人たちともポツポツ会話を交わしながら、最後までなんとか時間を過ごしました。

それまでの人生でも、一人でイベントなどに参加することはよくありました。

知っている人が誰もいない場所に、後先考えずとりあえず飛び込んで、そのままコミュニティとの付き合いが始まったり、意図せず仕事につながったりすることもありました。

そういう経験が知らぬ間に体に染みついていたのか、初めは「すぐにでも帰りたい」と思っていたはずが、講義後の懇親会にも参加することになり、受講生やサポーターの人たちと少なからずおしゃべりをしながら、結局会場が閉まるまで残っていました。

その何日か後に、YAPC::Asia 2013が神奈川県の日吉で開催され、その中で行われたPerl入学式出張版にも参加しました。

Perl入学式 @ YAPC - YAPC::Asia Tokyo 2013
YAPC::Asiaで行われるPerl入学式のワークショップについて色々インタビューしてみました! | YAPC::Asia Tokyo 2013

なぜ一度痛い目にあったのに、懲りずにまた参加したのかというと、じつはYAPC::Asiaのチケットの方を先に買っていて、その下見のようなつもりで上記の講義(第3回補講)を受けていたからでした。

そして、このYAPC::Asiaでもまた、基本的にはずっと一人でした。

YAPCでのPerl入学式には、サポーターはもちろんのこと、先の受講生も何人か参加していたので、今度はまったくの一人ではなかったものの、YAPC全体を通してみれば、前夜祭でも、初日の懇親会でも、大半の時間は一人で過ごすことになり、それが数日間にわたり続いたため、このときには疎外感というより、もう少し重々しい、とりとめのない孤独のようなものを感じていました。

ちなみに、YAPCにおけるPerl入学式の内容は、普段とはちょっと違う番外編のようなもので、入門というにはひねりの効いた、少なくともぼくにはなかなかハードルの高いもので、何をやっているのかよくわからないうちに終わってしまった、という感じでした。

そういうこともあって、「やっぱりYAPC、俺には早すぎた・・」という後ろ向きな感想を持ちましたが、なぜかその後もPerl入学式には参加し続けることになり、翌年の4月からはサポーター側に回ることになりました。

ある種、痛切ともいえるボッチ体験に遭遇しながら、なぜその後もやめずに続けられたのかと考えると、結局のところ、その疎外感とか、孤独感とかいったツラさは最初に味わうものが一番大きくて、その後は痛みに慣れるというか、弱まるというか、軽減される一方だから、ということが言えると思います。

喩えてみると、バンソコウをはがす時に、最初にピャッとはがしてしまえばそれで終わるというか。

あるいはインフルエンザの予防接種を受けるときに、「はい、チクッとしますよ〜」とか言われて、「ひえ〜!」と思っても、その数秒後には全部終わってる、みたいな。

新しい体験がもたらす痛みは、最初の方ほど強く、しかし後は弱まる一方で、やがてそれは心地よい自分の居場所になっていきます。

この記事の前半で、エレベーターに乗ったときの話を書きましたが、今思えば、サポーターさんはサポーターさんで、普段はそれぞれ別の職場で仕事や生活をしていますから、Perl入学式という場で、気の置けない友人たちに久しぶりに会えたなら、普段はできない楽しい会話に時間を使いたくなるのはごく自然なことです。

当時のぼくからすれば、「自分と自分以外」という物の見方しかできていませんでしたが、実際には、サポーターにはサポーターの、特別な場としてのPerl入学式があったわけです。

普段の生活習慣から離れた場に、一人で飛び込むというのは、不安もあると思いますし、実際、人によってはツライ思いをすることもあるかもしれませんが、その次の瞬間から、欲しいものは確実に手に入ってきます。

ぼくの場合、それはプログラミングの技術でした。

だいぶ時間はかかりましたし、今なおかかっていますが、当初では考えられなかったほど、その技術を自分のものにし、それを楽しんでもいます。

プログラミングの勉強を始めるときに、一緒にやってくれる友達は不要です。
自分の体ひとつあればOKです。

Perl入学式では講義資料を広く公開していますし、

講義資料 - Perl入学式 | Perl Entrance

全国各地でも開催していますので、もし都合が合えば、いつでも参加してみてください。
www.perl-entrance.org

ノンプログラマーのプログラミング活用法

去る3月3日に沖縄で開催されましたYAPC::Okinawaでの発表内容をスクリーンキャスト形式で新たに収録してみました。

www.youtube.com

ただし、めっちゃ長いので(85分)各チャプターの頭出しをしたリンクも以下に並べておきます。
興味に近いところなどありそうでしたら、適当につまみ見してください。

  1. はじめに: https://youtu.be/jJZD3k6-q0c?t=0s
  2. 自己紹介: https://youtu.be/jJZD3k6-q0c?t=3m45s
  3. Vim: https://youtu.be/jJZD3k6-q0c?t=13m46s
  4. Shell: https://youtu.be/jJZD3k6-q0c?t=31m38s
  5. Perl: https://youtu.be/jJZD3k6-q0c?t=50m54s
  6. Excel: https://youtu.be/jJZD3k6-q0c?t=1h1m40s
  7. ふり返り: https://youtu.be/jJZD3k6-q0c?t=1h18m12s
  8. まとめ: https://youtu.be/jJZD3k6-q0c?t=1h22m1s

冒頭でも少し説明していますが、今回は発表の録画も録音もしてなくて、一応スライドは公開しているけどDEMOも多用しているので、スライドだけだと一部しかわからないし、まあ「そういうものだ」と割り切るのもアリなんだけど、実際はかなり準備していった話だからこのまま終わってしまうのもな〜・・と思って、このような形で再現してみました。

YAPC本番では40分以内に収めるためにいろいろトピックを削ってしまいましたが(Shell編の文字列検索とか)、今回はそれも含めて基本的には全部入りにしたので、そういう意味ではフルバージョンです。

と言いつつ、これも今聞き直してみたら「あ〜、あの話忘れた」「こう表現すればよかった」といった部分がポロポロ出てきているので、これはこれでひとつの未完成版というか、新たなライブ盤というか、YAPCとはまた別の即興的な何かかな、とも思います。

あとはYAPCの本番だとやっぱり、聞いている人たちの反応コミでの面白さみたいなのがあったので、その意味でも現場でのパフォーマンスとは別物といえば別物な気もします。

とはいえ、当日聞いてくれた人にとってはその補足というか、その日の内容を思い出したり、カットされた話を知るものとして聞けるかなと思いますし、沖縄まで行けなかった〜という人には、スライドではわからない部分を聞いてもらえる機会になると思うので、記憶がなくならないうちになんとか形にできて良かったなと。

なお、この発表に関するざっくりした話(というかスライド作成の過程など)については前回の記事に書きました。
YAPC::Okinawa 2018 ONNASONの記録 - the code to rock

発表スライドはこちら。
The Non-Programmer's Programming Techniques // Speaker Deck

その他、個別具体的なトピックについてはまだまだ語り足りない面もありますが、とはいえキリがなさそうなのでしばらくナシかな・・。

それよりはむしろ、イベント前後の前夜祭、ハッカソン、お土産屋めぐりなどについてまだ書いてないことがいろいろあるので、次に時間ができたらその辺りを書き残しておければ、という感じです。

最後になりますが、このような機会を作ってくれたYAPC::Okinawa運営スタッフおよび関係各位、参加者の皆さん、そして何より時間を割いてB会場で聞いてくれた方々、ありがとうございました!