同じ変数名でなくてもいい部分を同じ変数名にして初心者を混乱させてしまう現象

最近はProgateでRubyを中心にいろいろ未知の言語に触れている。

prog-8.com

Progate、控えめに言ってグレイトすぎるサービス。勉強法についてこれほど意識的なプログラミング学習サービスを他に知らない。「回転」や「定着」や「インセンティブ(ごほうび)」みたいなものが学習者にもたらす効果について、これ以上なくストイックに追求していると思う。リスペクト。

さてしかし、そのProgateのRuby学習コースIVの中で、ありがちな不備というか、これはまったくProgateに限ったことではないのだけど、すでにプログラミングをよく理解している人が初心者に教えたり入門書を書いたりするときにやりがちな悪例(というか推奨できない教え方)を目にしたので、記しておきたい。

具体的には、上記コースの「インスタンスメソッド」の項をやっているときに、こんなサンプルコードに出会った。(部分的に編集して抜粋)

class Menu
  attr_accessor :name
  attr_accessor :price
  
  def initialize(name:, price:)
    self.name = name
    self.price = price
  end
  
  def info
    return "#{self.name} #{self.price}"
  end
end

menu1 = Menu.new(name:"すし", price:1000)

puts menu1.info

実行すると、こんな。

すし 1000円

なんの変哲もない、シンプルなサンプルコードのように見えるけど、じつはここには初心者を混乱に陥れる問題が潜んでいる。

それはどこか? たとえば、ここ。

  def initialize(name:, price:)
    self.name = name
    self.price = price
  end

「name」と「price」という変数名が、本来必要な数に比べて多すぎる。

その言い方でわかりづらければ、以下の修正例を見てほしい。

  def initialize(name_foo:, price_bar:)
    self.name = name_foo
    self.price = price_bar
  end

先ほどはnameとpriceが3個ずつ出てきたが、ここでは1個ずつあるだけで、あとはname_fooとprice_barに置き換えられている。

さて、ここでは一体、何を直したのだろうか? それは、

  • 同じ変数名じゃなくてもいい部分にも同じ変数名を使っている

という状況を、

  • 同じ変数名じゃなきゃいけないところだけを同じ変数名にしている

という状況に変えた、ということになる。

最初のサンプルコードでは、「本来なら別の変数名でも構わないところ」が、なぜか(たぶん何となく)「同じ変数名」になっている。そして、初心者がそれを見てどう思うのかというと、それらの変数名が「同じでなければいけない」と思ってしまう。

だから教える人は、自分たち経験者にとっての「同じ変数名でなくてもいい場所」が、初心者にとっては「同じ変数名であってはいけない場所」なのだということを理解しながら教えてあげなければいけない。

もちろん、ある程度習熟してくれば、これらの箇所で同じ変数名を使いたくなるのは自然なことだと思う。

だけど、「同じ変数名にしてもいい(場合によってはその方が便利)」ということと、「同じ変数名にしなければならない」ということはやはりまったく別のことだ。

そして初心者にとっては、「なぜ同じ変数名にしたのか」を説明されなければ、それは「同じ変数名にしなければならない」という意味になる。

どうもこのたぐいのズレがプログラミングの入門書では散見される。そしてそのつど、「ああ、わかってないな・・」と思ってしまう。*1

変数名というのは、その中身がどんな値であるのか、外側から(中身を見なくても)大体判断できるように付ける目印というか、外装みたいなものだろう。

プログラミング経験者は、コード全体の文脈を踏まえて変数を見ているから、その中身をすぐに想像できるだろうけど、初心者はそうではない。初心者は同じ変数名を見たら、中身も同じなのだろうと思ってしまう。あるいは、「中身は違うかもしれない・・けど、確証はない・・」という状態。言い換えると、変数の中身を頭の中でトレースできていない。

中身も役割も異なるのに、同じ変数名が付いているというのは、人間で言ったら「別人なのに全身同じ服」みたいなもので、だからプログラミング初心者にとっての「値が異なるのに同じ変数名」という状況は、欧米人にとっての「背格好がほぼ同じでまったく同じ服を着ている日本人」みたいなもので、見た目から中身が異なることを判断するのは難しい。というか単純にまぎらわしい。

変数名は中身を想像させるために付けているのだから、経験者ほどにはその中身を想像できない初心者に対して、そういうまぎらわしいことをしてはいけないと思う。外から見ただけで、「ああ、あそこで使った変数をここでも使い回せるのか」と直感的にわかった方が、より効率的に、本質的な構文を学びやすくなるのではないだろうか。

話を戻して、上記の修正はメソッドの呼び出し部分にも影響を及ぼすから、一応全体に修正を行き渡らせたサンプルも示しておく。

class Menu
  attr_accessor :name
  attr_accessor :price
  
  def initialize(name_foo:, price_bar:)
    self.name = name_foo
    self.price = price_bar
  end
  
  def info
    return "#{self.name} #{self.price}"
  end
end

menu1 = Menu.new(name_foo:"すし", price_bar:1000)

puts menu1.info

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

しかしこの、「同じ変数名でなくてもいい部分」をつい普段のクセで「同じ変数名」にしてそのまま入門書などに書いてしまう現象、なにか名前をつけたい。そしてこうした問題がくり返されないための目印みたいなものにしたい。

*1:とはいえ、本の場合はこういうズレは編集者さんが見つけるべきだと思うけど。執筆者はプログラミングのプロではあっても、入門書のプロであるとは限らないわけだから。

文字起こししないインタビュー記事の作り方

前回、自動文字起こしについて書きましたが、

note103.hateblo.jp

今回は、文字起こしをせずにインタビュー記事を書く方法について書いてみます。

事例

これについてはすでに適用事例がありまして、もう1ヶ月以上前になりますが、以下の記事をこの方式で書きました。

geek-out.jp

普段引きこもりがちなぼくにしては珍しく、このときは山口まで出張して、YCAM(ワイカム)というアートセンターで同館のスタッフとしてあらゆるドキュメンテーション業務、また広報その他の分野において、ITを駆使しながら活躍されている渡邉朋也さんにインタビューしてきました。

*同記事については、以下のブログでも簡単に紹介しました。

note103.hatenablog.com

渡邉さんはとにかくすごいバイタリティの方で、どれだけ面白い話をしても尽きないし、ぼくもけっこうお付き合いが長いのでずーっと話していたらトータルで7時間弱、ICレコーダーが回っていまして。そうなると、もうこれ文字起こしなんかしてたら一生原稿できないな〜・・ということで、今回の方法を開発することになったのでした。

ちなみに、じゃあ普段はどうしているのかというと、たとえばぼくがこれまで手がけてきた以下のCDブックの場合、

このブックレットでは、毎回大体3万字弱ぐらいになる座談会を掲載しているのですが、これは平均で4時間ちょいぐらい、ずっと参加者の皆さんがおしゃべりをして、その録音をもとに8万字ぐらいの文字起こしテキストを作って*1、それを見ながら構成(文章全体の構造や流れなど)を立てて、その後はどんどん不要な部分をカットしながら原稿を作っていきます。

しかしながら、今回の7時間録音はさすがに文字起こしはしたくないというか、やってはいけないというか、文字起こし自体が目的(提出原稿)ならそれでもいいんですが、目的はその先にあるまとまった原稿であり、また現実的に締切りなどもあるので、「いかに効率よく、時間をかけずに、良質な記事を作れるか」という目的のもと、工程自体を新たに考えた次第でした。

作業の流れ

さて、その具体的な工程ですが、大まかに記すと以下の2つの流れに分かれます。

原稿編

  1. 事前に作った「A. 質問事項」と「B. そのカテゴリ」を原稿の「A. 文中の質問」と「B. 小見出し」に置き換えて列記する。
  2. 当日の実際の流れに応じて、原稿上の小見出しや質問を編集(追加・削除・修正)。
  3. それぞれの質問事項に対して、現場での相手のコメント(回答)をひたすら思い出しながら書いていく。
  4. 記憶に曖昧なところがあれば、キーワードマップ(後述)で該当箇所を特定し、音声を聴いて発言を厳密に把握した上で煮詰めていく。
  5. もうこれ以上できません! というぐらいまで3と4をくり返す。
  6. 文字数に合わせて分量調整。原稿を仕上げる。

キーワード起こし編

  1. とりあえず音声ファイル全体のうち、キリのいい時間で区切って(1時間ごと、または全体の2等分・4等分・8等分時点など)そのポイントだけ数秒〜数分ずつ聴いていく。
  2. 聴いた時点でどんな話をしているか、単語や短文など簡単でよいので、スプレッドシートのフォーマットに合わせてメモしていく。
  3. 1, 2の時間間隔を徐々に狭めながら、スプレッドシートを埋めて「キーワードマップ」を完成させていく。10分おきか5分おきぐらいまで詰めればひとまず充分。

後者の「キーワード起こし」というのがこの方法のキモで、これが従来の方法における「文字起こし」の代わりになります。

キーワード起こし/キーワードマップ

ということで、そのキーワード起こしについてもう少し解説します。解説用のサンプルとして、いつものように今年3月に沖縄で登壇したときの再現動画を使います。*2

www.youtube.com

これに対して何をやるのかというと、まずは録音全体を任意の間隔で区切り、それぞれの時点でどんな話をしているのか、スプレッドシートにメモしていきます。

この発表は全長85分ということで、それほどの長尺でもないので、5分間隔で区切りたいと思います。もしこれが7時間とかだったら、とりあえず15分おきぐらいまででいいと思います。あまり細かく区切るとやる気が続かないので・・。

とはいえ、85分でも初めから5分おきに聴いていくのは大変なので、まずは半分に分割してみましょう。大雑把に80分と考えて、半分の40分時点ではどんな話をしているでしょうか?

*視聴中・・

はい、発表全体の内容を知らないとちょっとわかりづらいかもですが、「再帰的にどうしたこうした」と言っています(40:20頃)。ここでは「シェル(ターミナル)」を使った作業に関して話していて、具体的には自作の「f」というコマンドを使って、任意のディレクトリ内で再帰的にファイルを検索する方法について喋っています。

それを把握できたら、以下のような感じでGoogleスプレッドシートに記入します。

f:id:note103:20180802114340p:plain

A列の10行目、「40」とある行に、

シェルのパートでfコマンドについて。再帰的にどうしたこうした

と書きました。

では、もう少し分割して、今度は20分時点と60分時点を埋めてみます。

20分時点では、「どんどんカットしていける。後で戻せる」と言ってますね。この部分は先ほどのシェルの話の前のパートで、Vimに関する話をしているようです。

60分時点では、「ついでというか。こんなのもやってますよ、というのをここに書いてますけど」と言ってます。こちらはシェルの話のひとつ後のパートで、Perlに関する話をしています。

ということで、これらを先ほどと同様に記入すると、こんな感じ。

f:id:note103:20180802114410p:plain

A列の「20」「60」と書かれた行に、それぞれ上記のメモを入れています。

こんな具合にメモを入れつつ、どんどん間隔を狭めていって、最終的にはとりあえず5分おきに「その時点でどんな話をしているのか」を記入したら作業完了です。

なお、これらの作業をするときには、上の例からもわかるように、喋ってる内容をそのまま書いてしまっても構いませんし、発言そのものには触れず、概要や感想をさらっと書くだけでもOKです。

たとえば、20分時点のメモでは、最後に「たぶんゴミ箱の話」と書いていますが、これはそのときに「Vimを使って文章を仮置きしておく場所」を「ゴミ箱」と呼んでいたことを指しています。こうしてヒントのようにキーワードをくっつけておくと、後で役立つことがあります。

ちなみに、上の方でもちらっと書きましたが、ぼくはこの作業自体を「キーワード起こし」と呼び、その結果としてできたものを「キーワードマップ」と呼んでいます。よって、この後は基本的にそのような言葉の使い分けをしながら説明していきます。

話を戻すと、このように5分単位(あるいは面倒なら10分単位でも15分単位でも)で「そのとき何を話していたか」を示すヒントというか、アンカーというか、索引を記しておくことで、後から「あの話、7時間のうちの何時間何分ぐらいの時点で喋ってたんだっけ・・」と思ったときに、効率的にその箇所を特定し、元の発言を聴き直すことができるようになります。

キーワードマップの効果と由来

ところで、上のスプレッドシートの画像を見ると、縦方向に5分おきに進む行だけでなく、横方向に0〜4まで進んでいく列も用意されています。次はこの部分について解説します。

これら横方向に伸びる列は、1分単位でメモを取りたい場合に使います。たとえば、上記シートのA3は「5」ですから、5Bには5分時点の発言にもとづく情報(メモ)が入っていますが、そのひとつ右に進んだ5Cは、5分に1分加算した6分時点の情報が入ります。同様に、5Dには7分時点の情報が入ります。

つまり、A行に記された5分おきの数字に、B〜F列の「0〜4」を足すと、そのセルの時間が算出されることになります。

「え、ということは、結局1分おきにメモを埋めなきゃいけないわけ? だったらやっぱり文字起こしぐらい大変なんじゃないの?」と思われるかもしれませんが、そうではありません。

この1分単位のマスは、あくまで「必要になったらここに書く」というために作ったものなので、必要が生じるまでは空マスのままで大丈夫です。

とはいえ、おそらく最終的には、この1分ごとのマスもけっこう活用されることになるとは思います。というのも、原稿を作成する過程においては、現場での発言内容を細かく精査していくことになるので、そうなると、次第に5分おきのメモ程度では足りなくなるんですよね。(この実例はもう少し後の方で画像で示します)

また、たとえばインタビューの中でとくに重要なキーワードが27分30秒時点で飛び出したような場合、後からそれを参照したくなることが何度もあるのですが、ここで5分おきにしか情報が入っていなかったら、対象の発言が存在している場所は「25〜30分のどこかにある」ということまでしかわからないので、それを見つけるまでに最大5分かかることになります。しかし、1分単位で記録してあれば、その後同じ情報にアクセスする際、「27〜28分のどこかにある」という風に1分以内に絞り込まれた状態で情報を取り出すことができます。

以上のように、キーワードマップとは、音声情報をテキスト情報として検索するためのツールなのだと言えます。もちろん、同様のことは文字起こしテキストでも(その方がより高い精度で)実現できるわけですが、それを作るにはあまりにも時間と体力を消費してしまうので、いわば「簡易版文字起こし」として、手っ取り早く、かつそれなりに効果を発揮するツールとして考えられたのがこの「キーワードマップ」で、それを最小限の労力で作る方法が「キーワード起こし」なのだと言えます。

ちなみに、この仕上がり状態を「マップ」と呼ぶのは、縦軸の行と横軸の列から特定のポイントを割り出していく様子が、緯度と経度から場所を特定していく「地図」のイメージに近いことによります。

時短・省力化

この手法を「労力」や「作業時間」の観点から考えてみると、最初の5分おきにメモを埋めるところまでなら1〜2時間もあれば充分でしょうし、また1分おきのメモにしても、必要に応じてそのつど数分で埋めていけるので、すべての作業時間を合わせても1日分の作業量にもならないと思います。

*ちなみに、1分ごとにセルを埋めていくときには、文字起こし的に、喋っている内容をそのまま入れてしまった方がラクだと思います。いちいちメタ的視点から感想や意見を考えていると、そのたびに頭を使って疲れてしまうので。逆に、音声をそのまま文字化していくのであれば、あまり頭を使いません。この一連の方法は、時短・省力化を目的のひとつとしていますから、無理をして疲れてしまっては意味がありません。

一方、いわゆる文字起こしというのは非常に時間がかかるもので、ぼく自身の経験で言うと、完成するまでには元音声の12倍の時間がかかるので、今回の音声なら85分*12/60で、17時間かかる計算になります。また、文字起こしは大変体力を使うので、1日4〜5時間に留めるとして*3、まる4日は使うことになります。

その上、冒頭に挙げた記事であれば音声ファイルは7時間弱という超・長尺ですから、これを文字起こしするには通常の何倍もの時間がかかる上、できあがるテキストも膨大な量になり、それに対する編集作業の労力は加速度的に膨らみ、さらには使われないテキストも多くなるため、ようは元の音声が長いほど文字起こしの非効率さは増大していきます。

ぼくの場合、普段のこういった原稿作成では、まず録音から文字起こしテキストを作成し、それを読みながら構成を練ったり、どの部分を残してどの部分をカットするかと考えたりするのですが、上記のような理由により、今回はその「文字起こしをもとに原稿を作っていく」のではなく、「まず完成像をイメージしながら構成を組み立てて、そのディティールを埋めていく際にキーワード起こしを(文字起こしの代替として)使用する」という方法をとることにしました。

木彫か粘土か

ここで一瞬、工程の説明から離れて概念的な話になりますが、上記の「文字起こしから作るのではなく、構成を立ててからキーワード起こしを使う」というイメージは、前者を木彫、後者を粘土制作に置き換えて捉えることができます。

前者の作業では、まず膨大な文字起こしテキストがあって、その中から不要な部分をカットしながら、本当に必要なところだけを残していきます(厳密には、カットした部分にも大事な要素はたくさんあって、それが残った部分に投影されるような操作をしていますが、大局的には大差ないのでここの説明では無視します)。

ぼくはこの作業をイメージするときに、丸太から仏像を彫り出す作業を思い浮かべます。仏像を彫る人は丸太を見ているようで、じつは丸太の中に初めから存在している仏様を抜き出すようにして、仏様以外の部分を削り取っていきます。*4

一方の後者、粘土制作の方は、初めに大きな粘土のカタマリがあるわけではなくて、まずは木片や針金などを使って芯棒を組み立てて、そこに徐々に粘土をくっつけていきます。*5

そして今回採用した方法は、普段やっている前者の木彫スタイルではなく、後者の粘土スタイルであったと言うことができます。

原稿作成の手順

では話を戻して、ここからは上記のキーワードマップを使って、どうやって原稿を作っていったのかを解説していきます。

1. 事前に用意した質問を並べて原稿の叩き台にする

前記の手順から「原稿編」の方を再掲すると、

  1. 事前に作った「A. 質問事項」と「B. そのカテゴリ」を原稿の「A. 文中の質問」と「B. 小見出し」に置き換えて列記する。
  2. 当日の実際の流れに応じて、原稿上の小見出しや質問を編集(追加・削除・修正)。
  3. それぞれの質問事項に対して、現場での相手のコメント(回答)をひたすら思い出しながら書いていく。
  4. 記憶に曖昧なところがあれば、キーワードマップ(後述)で該当箇所を特定し、音声を聴いて発言を厳密に把握した上で煮詰めていく。
  5. もうこれ以上できません! というぐらいまで3と4をくり返す。
  6. 文字数に合わせて分量調整。原稿を仕上げる。

ということで、まず1番の質問事項について、これはインタビューの現場で「とりあえずこれについては聴いておきたい」という内容を事前に書き出しておいたもので、ぼくの場合はルーズリーフ2〜3枚に手書きでリスト化して、色ペンでさらにマーキングやメモなどを付して用意していました。

このときの質問は全部で23個でしたが、質問にはある程度共通する傾向というか、カテゴリが存在するので、そのカテゴリごとにまとめておきます。

冒頭の記事で言うと、最終的には以下5本の見出しが立っていますが、

  • YCAMってなに?
  • YCAMインターラボの活動
  • IT技術の生かし方
  • オープン化の取り組み
  • 既存の文化事業を超えて

元々の質問はプラス2〜3本(計7〜8本)のカテゴリに分かれていました。

で、この段階では実際のインタビュー内容については一旦忘れて、その質問カテゴリを「小見出し」として、またそれぞれにぶら下がっている質問事項を各見出し内のコンテンツとして列記していきます。それだけ、といえばそれだけですが、これがこの後の作業の大元というか、叩き台になります。

2. 質問の内容やカテゴリ(小見出し)を実態に即して調整

1の状態はあくまで事前に作った資料を元にしたもの(叩き台)なので、今度はこれを現場で行われたインタビュー内容に合わせて調整していきます。

ただし、ここでは次の工程3と同様、当日の流れを厳密に再現する必要はありません。事前に予定していた質問のうち、カットしたものを外したり、追加したものを適宜加えておく程度で充分です。

3. 想像力で回答を埋めていく

次に、上記2で作った質問に対する相手の回答を、自分の記憶や想像でどんどん埋めながら全体の流れを作っていきます。このとき、相手が実際にそう言っていたかどうか、という確認はひとまず後回しで大丈夫です。

なぜなら、第一に大半の内容はその後に修正することになるからで、第二に、この段階でそういった確認をちまちまやっていると全体の流れを作りづらくなるからです。通常、読者は記事を最初から最後まで1本の線を辿るように読んでいきますが、現場ではあちこちに話が飛びながら進んでいますから、現場の実態を重視していたらいつまでも読者に読みやすいものは作れません。

よって、ここではあたかも自分が最初の読者であるかのように、「こういう流れでこの記事を読みたい」と思う文章を作っていきます。上記1と2の工程はその準備であり、この3はそれを踏まえた通し稽古のようなものです。実際の進行順と異なるからといって、「事実と違うぞ!」などと指摘してくる人はいませんし、そもそも執筆者は現場で話した内容を誰よりも把握しているはずなので、「事実と異なるかも」などということは心配せず、まずは自分の想像の世界で1本の物語を作ってしまいましょう。

4. 記憶が曖昧な箇所をキーワードマップで確認する

ある程度、質問と回答のやり取りを埋めて全体の流れができたら(あるいはその途中でどうしても現場の発言を確認したくなったら)、ここでキーワードマップの登場です。おもむろにGoogleスプレッドシートの検索機能を使って、検索したい箇所で話しているはずのキーワードを入力し、音声ファイルの中のどこでそれを話していたのか、突き止めましょう。

不思議なことに(あるいは当然のことかもしれませんが)、現場で話したことや、相手から聞いた言葉というのはけっこう頭の中に具体的に残っているもので、それを検索クエリとして使うと、大抵の発言は見つけ出すことができます。

たとえば、山口の記事で使ったキーワードマップで「パブリシスト」を検索すると、こんな感じになります。(一部伏字の上抜粋)

f:id:note103:20180802164652p:plain

はい。1時間21分の時点で話題に上がっているようです。

もし目当てのキーワードが見つからなかったら、その前後の記憶を辿って、近いところで話しているはずの別のキーワードを検索してみましょう。それでも見つからなければ、最初にマップを作った際の間隔が少し広すぎる可能性があるので(10分、15分間隔になっているなど)、一旦作業を止めて、5分おきぐらいまで詰めておくのも有効です。

大抵の場合、5分おきまで詰めておけば、ピッタリその箇所を見つけられなかったとしても、「この20〜35分の範囲で話題に挙がっていたことは間違いない」ぐらいまでは特定できるので、そこで15分間、再生速度を上げて音声を聴き通してもよいかもしれません。

5. 通して読める原稿に仕上げる(分量は調整不要)

あとはひたすら、3と4をくり返します。このとき、文字量についてはまだ考えなくて大丈夫です。まずは自分が通して読んで面白いと思えるまで原稿を仕上げてしまいましょう。

また、3の段階では記憶だけで流れや内容を作っていきましたが、この段階で、すべての発言内容に関して、「相手が本当にそのような発言をしていたかどうか」を確認します。

といっても、ここでは本人の「現場での発言」と「文中の発言」が一言一句同じである必要はありません。記憶で再現した発言と実際のそれが完全に一致するはずはありませんし、一致させなければならない理由もありません。むしろ、一言一句同じにしたところで本人の言いたいことを再現できるとは限りませんし、逆に記憶や想像をもとに再現した文章の方が、より自然に本人の言いたいことを伝えられている場合もあります。

文字起こしをもとに文章を作る際には、つい現場での実際の発言に引っ張られがちになりますが、この方法を使えば、そうした足かせにとらわれることなく、より相手の意向を汲み取りながら、臨場感のある文章を作りやすくなります。

そしてこのとき、キーワード起こしは相手が本当にそういう意味のことを言っていたことを確認するための裏付けとして、あるいは「相手が言ってもいないことを言ったことにしていないか」を確認するためのチェックシートとして機能します。

なお、今回の山口の記事では、この段階で冒頭のリード文(インタビューに入る前の簡単な解説)と、最後のプロフィールも作っておきました。

導入と締めを置くことで、よりリアリティを持って、「最初の読者」として本文を読み通しやすくなります。

6. 原稿の仕上げ。分量調整

最後に、原稿の分量を目的の文字数まで調整します。なお、これまでとくに説明していませんでしたが、この段階の原稿の文字数は、目的の文字数よりもオーバーしている前提です。もし目的よりも少ない場合には、手順2まで戻って構成を再考する必要があるかもしれません。

一方、今回の方法では上述の「木彫」方式ではなく、「粘土制作」方式ですから、目的の文字数に比べてべらぼうにオーバーしていることもないはずです。ある程度の構成・構造を立てた上で、その完成像をイメージしながら肉付けしてきたので、着地点も比較的目的に近いところにあるのではないかと思います。

その他、原稿の仕上げに際して、執筆者として気をつけることはいろいろあると思いますが(読者に対して提示すべき前提や、用語の説明に抜けはないかなど)、今回の本論とはズレるので割愛します。*6

まとめ

以上、「文字起こし」を使わずに「キーワード起こし」でインタビュー記事を作る方法をまとめてみました。

いつものように、だいぶ長くなってしまいましたが、要点は、

  • 録音した音声が長大になるほど、文字起こしを使った方法では効率が悪くなる
  • キーワード起こしを使えば、その無駄を軽減できる。(時短・省力化)
  • キーワード起こしを用いる場合には、木彫型ではなく粘土型にスタイルを切り替える

といったところでしょうか。

個人的には、この方法を使うことによって、執筆者は現場での発言に縛られすぎることなく、より自由で本質的な表現を実現しやすくなると思っています。

ただし、それは「キーワード起こしの方が文字起こしより優れている」という意味ではありません。

たとえば、1時間以内ぐらいの内容だったら、一気に文字起こしをしてしまった方が早いかもしれませんし、あるいはインタビューではなく、座談会のように複数の人が同時に喋るようなものだったら、記憶しておける現場の情報も限られてしまい、文字起こしに頼った方がよいかもしれません。また、事前の構成ができないような場合も、素直に文字起こしから入った方がよいかもしれません。

具体例としては、初めの方で触れた、坂本龍一さんの音楽全集に掲載している座談会にしても、事前にわかっているのは大まかなテーマとそれにもとづくいくつかの主要曲ぐらいで、あとはその場の流れに合わせてほとんど即興で話が進んでいきます。よって、この場合は事前に構成を組んでから肉付けしていくような作り方は不可能で、まずは文字起こしを中心にベースの原稿を作って、それを眺めながら、自分の意識は極力排して、テキストが進みたい方向へ進むようにサポートしてあげる、という感じで手をかけていきます。*7

ただいずれにしても、手法の選択肢が増えれば、それだけ作業の効率が上がり、成果物のクオリティが上がる可能性も高まるので、誰かの参考になればと思ってまとめてみました。

*1:この音楽全集の文字起こしは直近でも昨年の1〜2月頃にやったものなので、当時はまだGCPの使い方なども知らなかったし、Googleドキュメントでの文字起こしもそれほど費用対効果が高くなかったので今のところすべて人力で起こしてます。

*2:誰にも許可を取ったり気を遣ったりする必要がなく使いやすいので。

*3:実際にはそんなにやらない気もしますが・・。

*4:あくまで喩えなので、本当にそんなことを考えてやっているかはわかりません。

*5:これも喩えなので、実際のところはわかりません

*6:文字校正などについても同様の理由で割愛。

*7:オカルトっぽい説明ですが、きちんと説明しはじめるとそれだけでまた長文になるので割愛。

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年度版ですが、ここでは新しい方を貼っておきます)、

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

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

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

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

基本情報技術者試験にうかった - 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」などの有名曲が揃っているベスト盤のようなものですが、個人的には「ラチエン通りのシスター」「涙のアベニュー」「恋はお熱く」「わすれじのレイド・バック」あたりを好んで聴いています。

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

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

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

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

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

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

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

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

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

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

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

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

最後に免責事項を。

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

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

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

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

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

*1:自分が生きているうちに、という意味ですが。