読者です 読者をやめる 読者になる 読者になる

基本情報技術者試験を受けてきた

結果

先週日曜(2017/04/16)、基本情報技術者試験というのを初めて受けてきた。

同日中に解答が公式に配布されて、翌日さっそく自己採点したところ、たぶん今回は駄目だった。
(正式な合格発表は5/17)

同試験は午前と午後の部があって、それぞれ60点以上とれば合格なのだけど、午前は77点ちょいでパスしたものの、午後がたぶん53点ぐらい。
だから午後の方でアウトになってる。

ちなみに、午前は厳密に配点が公開されてるのだけど(1問につき1.25点)、午後は大問ごとの配点のみ明示されていて、その中の小問というか、枝問の配点まではわからないので、上記は大体の目安。
とはいえ、少し厳し目に算出したものの、さすがに7点ずれてるということはないだろうから、駄目なものは駄目だと思う。

今年の1月末にITパスポートという、やはり国家試験ながらコレ系では一番カンタン(というか一般人向け)、みたいのを受けて(それは受かった)、そのための勉強を始めたのが昨年末ぐらいだったので、それも含めると約3ヶ月、とはいえ2月は別件であまり時間が取れなかったので正味1〜2ヶ月程度の学習期間だったのだけど、それにしてはまあ、頑張った方だと思う。

というか、元々今回は記念受験というか、とりあえず受けるだけ受ければそのために否が応でも勉強するだろうし、それを土台にして秋の合格を目標に据えて頑張ろう、とか思っていたのだけど、だんだん過去問の結果がいい感じになってきて、「あれ、これもしかして結構ギリギリのところまで行けるのでは……」みたいに思ってたら本当にギリギリ(アウト)だったという感じ。

当初の目標は低めに設定していたとしても、当然のことながら合格できるならしてしまいたかったわけで、やっぱり無念ではある。

と同時に、しかし実際には、午前はともかく午後の方はだいぶお手上げな感じで、午後試験が始まってから1時間ぐらいで、「うわー、今回は駄目だ、まったく駄目! 過去問はそこそこできてたのに、全然歯が立たないじゃん。秋までサヨウナラ〜だな!」と、会場で完全パニック&気持ちが180度折れるぐらいわからなかったので、それにしては拮抗したじゃん、というか当てずっぽうの回答が当たりすぎただけでは、という気すらする。

まあ、60点という基準点がそれだけ低めの設定なのかな……とも思うのだけど。
簿記は70点が基準点で、前回2級に落ちたときは60点で落ちたので、まあ60点が基準点というのはけっこう懐が深い感じなのかもしれない。

上では記念受験と書いたけど、それに近い感じで今回の最大の目標というのは、何しろこの基本情報技術者試験、午前が9時半からのスタートで、かつぼくの家から会場までが1時間ぐらいの距離だったので、とにかく「時間に間に合う」というのが最大の目標になっていた。

ようは試験の開始時刻にちゃんと間に合って、かつベストの体調で最後まで受けきり、持ってる実力を発揮する、ということ。

実力を発揮した上で落ちるなら、まあしょうがないのだけど、体調不良とか寝不足とか、あるいは準備するもの(受験票とか)の不備とか、寝坊とか無自覚な違反行為とか、そういうのが理由で落ちたら悔やんでも悔やみきれないので、そういうことを最大限避けて受験する、というのが目標だった。

で、それは達成できて、しかしその結果としては上記のように、問題が自分には難しかったり、(おそらくはその影響もあって)とにかく時間が全然足りなかったので、次に受けるときはもうちょっと余裕を持って、少なくとも問題の内容を理解しながら最後まで答えきる、というのを新たな目標として設定したい。

とくに、必須問題である第8問のアルゴリズム問題。これは擬似言語というのを使って、プログラムの中身をトレースしていくような問題なんだけど、これが本当に最後の最後まで苦手で、結局まともな得点を取れないまま本番が終わってしまった。
次回はとくにこの問題で、ちゃんと自信を持って回答できるようにしたいという気持ちが強い。

今回はこれだけの短期間で、仕事もしながら(他にもいろいろ忙しかったのだけど)、ここまで来たのだから、その調子でいけばもう少し向上できるはず。たぶん。

参考書

学習経緯としては、以下に簡単なログというかメモを残してある。中途半端だけど。
基本情報技術者試験の勉強 - note103 - Scrapbox

進捗記録の最初(一番下に記載)が3/18だけど、手元のログを見ても過去問に着手したのが3/11とかなので、本格的な問題練習はその頃から、という感じか。

そのリンク先には参考にした本なども記載しているけど、その後に購入したものを含めて、とくに参考になったものを列記&簡単にコメントも付しておく。

(PDF・スマホ単語帳付) かんたん合格 基本情報技術者 過去問題集 平成28年度(2016年度)秋期

(PDF・スマホ単語帳付) かんたん合格 基本情報技術者 過去問題集 平成28年度(2016年度)秋期

  • たぶん一番読み返した&使った。単なる過去問集ではなく、解説も丁寧で充実していた。多謝。

平成29年度 ITパスポート合格教本 (情報処理技術者試験)

平成29年度 ITパスポート合格教本 (情報処理技術者試験)

  • 後述。

ゼロからはじめる基本情報技術者の教科書

ゼロからはじめる基本情報技術者の教科書

改訂第3版 すらすらと手が動くようになる SQL書き方ドリル (WEB+DB PRESS plus)

改訂第3版 すらすらと手が動くようになる SQL書き方ドリル (WEB+DB PRESS plus)

  • すでに古典(?)な本書。受験用ではなく少し前に買ったのだけど、データベース問題対策として非常に有用だった。挿絵(イラスト)も最高。

(全文PDF・単語帳アプリ付) 徹底攻略 応用情報技術者教科書 平成29年度(2017年度)

(全文PDF・単語帳アプリ付) 徹底攻略 応用情報技術者教科書 平成29年度(2017年度)

  • 今回の受験とは対象が違うけど、念のためと思って買っておいたらビンゴ。「基本」用の教科書では省略されてしまった重要トピックについても図入りで詳細に解説されているケースが結構あって、助かった。平明な動画講義も何度も見返した。瀬戸先生の教え方は単に詳しいだけでなく、どのポイントが重要なのかという見極め、それから知識のための知識ではなく、その技術が実社会でどう活用されているのか、みたいなことに意識を繋げながら教えてくれる、という印象があった。

  • 勝手に馴染みを覚えている矢沢久雄さんによるアルゴリズム本。アルゴリズム問題に絞って書かれているというだけでもツボだったけど、基本から応用まで幅広く解説されていて良かった。結果的には成果は出なかったけど、取っ掛かりとしては有効だったと思う。

改訂3版 基本情報技術者試験 C言語の切り札 (情報処理技術者試験)

改訂3版 基本情報技術者試験 C言語の切り札 (情報処理技術者試験)

  • 過去問のプログラムが1行ずつ丁寧にトレース&解説されていてとても参考になった。終盤ではアルゴリズム問題も扱ってくれていて、上記の問題集や矢沢さんの本と突き合わせながら読むことで奥深いところまで検証できた。多謝。

そして2番目に挙げた岡嶋裕史さんの本、ITパスポート用と銘打たれているのだけど、内容的にはすごく詳しく幅広く、どう考えてもこれ、ITパスポート試験でここまでの知識いらないだろ(笑)というぐらいの充実度で、会場まで持っていく厳選参考書の中にこれも含めたぐらい良かった。

電子版も出ていて、紙版と合わせて買ったけど、すごく面白かったし今後も折々読むと思う。

岡嶋裕史さんは元々、「スラスラわかるC言語 (Beginner’s Best Guide to Programmin)」という本を読んで「面白い著者だなあ」と思っていたので、岡嶋さんが書いた基本情報技術者の本がないかなあ、とわざわざ探していたら、それに一番近いのがこれだったので&サンプルを読んで良さそうだったので買った、という感じだった。

とにかくサービス精神が半端ない人で、時々自虐ネタをやりすぎる感じはあるんだけど、トータル的には得るものしかない感じで楽しんだ。

そう言えば、今書きながら思い出したけど、岡嶋さんの以下も電子版で買って読んだのだった。

擬人化でまなぼ! ネットワークのしくみ

擬人化でまなぼ! ネットワークのしくみ

擬人化でまなぼ!  ITインフラのしくみ

擬人化でまなぼ! ITインフラのしくみ

これもいずれもすごく面白い(とくにネットワークの方)のだけど、どちらもちょっと二次元系エロ要素とも言えるものが少なくなくて、あんまり大きな声でこれを「読みました!」とか「オススメです!」とかは言いづらいのがなんというか……。
内容的には本当に丁寧&幅広い解説で良いんだけど、そういうある種の趣味的要素にウッとなってしまう向きにはあまり勧められないというか。
(実際、ここで紹介するかも一瞬迷ったけど、やっぱりすごく参考にはなったので紹介した)

ちなみに、インフラ編の方は前著(ネットワーク編)が好評で作られたのかな、と思ったけど、ネットワーク編に比べるとちょっとキャラクター同士の会話が冗長な感じで、もう少し時間をかけて作ってほしかったかなあ……と、もはや誰目線なのかわからないが思ったので合わせて記しておく。

経緯

さて、そもそもなんで基本情報技術者試験? という話なんだけど、資格試験としては上にもちらっと書いたように、以前に日商簿記を受けたことがあって、ある意味ではその延長というか、ヴァリエーションみたいなものとして、「そういう資格があれば今後の人生、多少なり生きやすくなるのでは」みたいなこともあったのだけど、とはいえ、その選択肢にどうして基本情報技術者試験が入ったのか? ということで言うと、直接的にはまず以下の @songmu さんのツイートを見たということがあって。


へえ、面白いな、いずれやってみたいな。とか思って、でもしばらく忘れていたんだけど、その後にちょまどさんの以下のインタビューを読んだら、

codeiq.jp

 どれもこれも、最初は、何が書いてあるのかサッパリわからない。そしてその先には途方もなく広い、全くの未知の世界がある。その不思議な魅力にどんどん引き込まれました。右も左も分からない当時の私には、体系立った教材が必要で、その教材として、基本情報技術者試験を選びました。書店で教科書が買えるので。
 そして本当にたくさん勉強して、合格しました。理系の情報系の人たちにちょっとだけ追いつけたみたいで、とても嬉しかったです。その次は、応用情報技術者試験も合格することができました。
(※太字引用者)

ひえ〜、すげえ。応用も受かっちゃったのかよ。と、ここでかなり刺激を受けたのが大きかったと思う。

と言っても、前者の @songmu さんのツイートは2014年で、ちょまどさんのインタビューも去年の3月とかなので、その後もすぐには行動に移したりしていなかったのだけど、去年はなんというか、だんだん自分の今やっている仕事について、「いつまでもこの心地よいルーティンを繰り返していていいのかな……良くないよな……むしろ不安……」みたいな思いが徐々に強まってきて、それで大きめの作業が収まった年末から一念発起的にとりあえずITパスポートの勉強から始めた、という次第だった。

勉強した感想

勉強の結果としては冒頭に書いたとおりなんだけど、短期間ながらいろいろ勉強してとくに実感したのは、以下の2点。

  • ぼくは算数ができない
  • ぼくは長文が読めない

ぼくは算数ができない

まず算数について。ぼくは5才から13才ぐらいまで公文式に通っていて、13才のときにたしか高1ぐらいの数学をやっていたので、そこまでの学力は結構あったのだけど、そこで公文式をやめてしまって、かつ高校の数学の先生が非常に自分と合わない人だったのもあって、高校からの数学っていうのがまったくわからないまま年をとってしまった。

でも、「子供の頃は算数ができた」という妙な成功体験だけは残っていたから、今までずっと意識していなかったんだけど、今回つくづく思ったのは、もう数学以前の算数的なことから苦手になってるな……ということで。

とくに割り算。割り算が必要な場面になるたびに結構混乱して、もしかしたらこれ、子供のときからちゃんとわかってなかったんじゃないか? 「雰囲気でやってた」んじゃないか? みたいなぐらい、「え、なんでそれでそれを割ると答えが出るの?」みたいなことだらけで本当に落ち込んだ……。

割り算にかぎらず、情報技術者試験ってとにかく計算が必須になる問題が多くて、単純計算でも何度も計算を重ねないと答えが出ないやつとかがあって、その繰り返しをしているうちにどんどんエネルギーを消費してしまうというか。

もしある程度計算や算数に耐性というか、体力があれば、もう少しスイスイできるんじゃないか、という場面でもぼくはその計算作業で非効率に体力を使ってしまって、リソースを適切に配分できてないなあ……ということを身にしみて思った。

つまり、とにかく算数。計算。その辺の基礎体力をつけて、苦手意識を直さないと、このままこの勉強を続けること自体つらそう……みたいに思ってる。

ぼくは長文が読めない

もう一つ、長文の件。長文なんて、むしろ本職じゃん、いくらでも読んでるし、まさにこのブログがそうであるように自分でも書いてるじゃん、そしてそれを何度も読み返しては何度も直してるじゃん、みたいな感じなんだけど、そういうことではなくて、問題文の長文って、実際には出題者の頭の中にあるイメージというか、「こういう状況をまず前提として設定しておきますね」みたいな話を受験者の頭の中で再現する必要があって、その「出題者の頭の中にあるイメージを自分の頭で再現する」という行為が、非常に自分には難しかったということ。

これがたとえば、村上春樹の小説を読むとかだったら、読者が一人ひとり好きなようにその文章から情景を想像すればいいことなんだけど、問題文の文章っていうのは、受け手によって想像するものが「みんな違って、みんないい」みたいなものじゃ駄目なわけで、一意の像を頭の中で結ぶ必要がある。にもかかわらず、どうもぼくの能力として、その出題者のイメージというか、意図を自分の頭で再現する能力というのが非常に少ないな……と痛感する場面が多かった。

で、その原因はある程度想像できて、それは共通のコンテキストを持ってないというか、前提にしている文脈を共有できてない、というのが主要因だろうと思ってる。
より簡単に言うと、ぼくの持っている知識が少ない。

実際には、まあ出題者の日本語がもう少し上手なら……とかも思わなくもなかったのだけど、結局問題文が同じである以上、他の受験生とも条件は同じなのだから、それはそれとして受け入れるべきだと思ってる。

その上で言うと、「わかりづらい文章」っていうのは、結局「省略しちゃいけないところを省略してる」からわかりづらい。執筆者としては「当然、これはわかってるよね。だから省略しとくよ」みたいに、それはもう無意識レベルも含めて省略してるところであって、でもそれを読んでわからない人っていうのは、その省略されたところが本来それを理解するために必要な要素なのに省略されてしまっているからわからない、ということがままあると思う。

ぼくは職業病なのか、そういう長文の問題文を読んでいても、全体の整合性とかを気にして、「なんでこの部分の説明がないんだろう……隠された意図とかあるのか……?」とか悩んで、すごい時間をかけてその不明部分を妄想で埋めながら問題を解いて、解答と突き合わせると、あたかもそんなことはまったく問題でなかったかのように「当然ここはこうだよね」みたいな、暗黙の了解的にさらっとスルーされていた、みたいなことが多々あって、だから試験の少し前ぐらいになってようやく、「長文問題、そんな厳密に読んじゃ駄目だ。もっと雑に読まなきゃいけない。だって、誰もそんな細かいこと気にしてないんだから」と、方針を立て直したりもした。

その「雑に読む」というのは、単に斜め読みするとかではなくて、あくまで出題者の意図を踏まえながら、ということ。出題者の頭の中には明確なイメージがあって、でも出題者は日本語の文章を通してしかそれをぼくら受験生に対して伝えることができないので、ぼくらもその文章を通じて彼ら出題者が言いたいこと、そのイメージを受け取らなきゃいけない。

おそらくは出題者的にも、「あまり長すぎてもいけない。最小限の文章量で表現しなくては」みたいになってるはずで、だから図や表と組み合わせながらそういう問題ができていると思うのだけど、とにかく今回の学習過程においては長文の問題を読むってこと自体がつらく、「ああ、俺これ、全然向いてないかも……問題がなに言ってるのか、全然わからないもの……」と、何度も絶望したものだった。

C言語から表計算

すでにだいぶ長くなってしまったけど、もうひとネタ。

午後試験のクライマックスとも言えるプログラミングの問題で、基本情報技術者試験の場合はJavaC言語COBOLアセンブラ表計算、の中からひとつ選んで回答する、という問題があるのだけど、これをぼくは最初は「C言語」で受けようと思ってた。

というのも、元々C言語は今後プログラミングの勉強をしていく上で、それ自体を書かないとしても新たな言語習得に際してきっと助けになるだろうと思っていて、この機会にC言語学習の必要性というか口実を得られれば、より一生懸命勉強せざるを得ないというか、必然的に知識も経験も積んでいけるだろう、という目論見があったから。

なのだけど、これが何度過去問を解いてもまったく点数を取れない。基礎構文はそこそこ理解というか、把握できているはずなのだけど、問題になるとまったく結果が出ないというか。

今思えば、それは単純に問題練習の数が足りなすぎるというか、その20倍ぐらいやって初めて、玉ねぎの薄皮が剥がれていくように結果が表れたのかも、とも思うのだけど、そのときはすでに試験が近づいていて、そこで比較的簡単と言われている「表計算」の方にシフトするかすごく悩んで、結局方針転換することにした。

表計算、というのはようはExcelで、「いやあExcel、今から勉強したくない……いや、むしろその方が社会的・業務的には役立つだろうってわかるけど、でもなんかそれはそれでExcelの軍門にくだるようでちょっと悔しい……」みたいな心境ではあったのだけど。

でもこのまま、勝負にならない勝負をして悔しい思いをするよりは、と意を決したのが、今手元の記録を見ると3/29。試験のほぼ2週間前だった。

で、結果的にはこれは良い判断で、過去問レベルだったら試験前の段階で基準を超える正解率を出すことも増えてきて、これがC言語のままだったら他をいくら頑張ってもカバーしきれなかったと想像してる。

それにしても、このプログラミング問題、JavaC言語表計算まではわかるけど、COBOLアセンブラが選択肢って……とくにアセンブラ。本当にそれ「基本」なのか? いいのか、それで……? という感じがする。どうなんだろ……。

ぼくがそこそこ馴染んでるPerlとまではいかなくても、Rubyとか、PHPとか、なんかそういう、それこそすぐに仕事で役立つかもしれないものにもう少し寄せられないのか……という気もするんですがどうなんでしょうね……。
それとも結構、使われてるんだろうかアセンブラ……。

謝辞

そろそろ締め。ここまでにとくに触れていなかったんだけど、そして上では「短期間のわりによく頑張った」みたいなことを書いたのだけど、実際にはこの学習期間に得た知識だけではこれだけの得点はできなかったと思っていて、やっぱり2013年から参加しているPerl入学式の経験は非常に大きなアドバンテージになってたよなあ、とすごく思ってる。

もちろん、そこで知ったことがすべてなわけではなくて、それを起点に自分で勝手に調べたり作ったりしてきたいろんなことが全部、これまた玉ねぎの薄皮のように積もり積もって身になってた、ということだと思うけど、それでも最初にあのプログラミング講座がなかったら、自分の努力だけでここまで続けてくることはできなかったと思うので、Perl入学式の運営各位には本当に心から感謝しています。

今後

ということで、結果としては駄目だったもののそれなりに成果は上がってきているので、なんとかこのまま勉強は続けて次はパスしたいなあ、と思ってる。

実際には、次の情報技術者試験はおそらく10月半ば、これって自分の業務が一年を通して最大ピークの時期と思われるので、その頃に本当に学習&受験できるのか、ということはまったく不明なのだけど……。

ともあれ、ひとまず今回の一連のトライのまとめは以上。
俺、おつかれ!

最近よく使っている自作ツール(3) select.pl

TL;DR

www.youtube.com

ちょうどひと月ぐらい空いてしまいましたが、以下のシリーズの続きです。

note103.hateblo.jp

note103.hateblo.jp

今回は、複数のファイルを直感的に選択して、それらに同じコマンドを渡すためのツールです。

リポジトリは以下。

GitHub - note103/select

で、いつものようにLICEcapを使ったGIF動画と、文章による説明とを組み合わせつつ記事を作ろうかと思っていましたが、けっこうそれも大変なんだよなあと思い直し、それでこのところ「音声入力による文字起こし」の実験をする過程で泥縄的に身に付けたスクリーンキャスト的手法で紹介してみようか、と思って作ったのが冒頭の動画(YouTube)です。

説明としてわかりやすいかどうかは不明ですが、文章で全部書くよりはずっとラクでした。

で、とはいえ、それだけではいろいろ情報が不足するだろうと思って、その補足ぐらいは文章で補おう・・と思っていましたが、やっぱりそれもまた面倒というか、いや面倒ならやらなければいいのですが、いや説明はしたい、そもそも自作ツールを紹介したいからわざわざこんな記事を書いているのだ、ということで、それならいっそその動画で喋った音声もそのままGoogleドキュメントの音声入力機能でテキスト化しちゃえばいいのでは、と思ってそうしてみました。

で、さらにその際、なんだかメタっぽいですが、せっかくなのでその音声入力による文字起こしの模様も動画に撮ってみたので、記事の最後に貼り付けておきます。興味のある人はご高覧のほど。

ということで、上の動画で喋った内容をGoogleドキュメントの音声入力でテキスト化した上で、簡単に手直ししたもの(それでも40分ぐらいかかったけど)を以下に掲示して本記事を終わりたいと思います。

このシリーズ自体はまだ続きがあるので、また時間ができたら更新したいと思っています。

Transcript

[00:00]

  • ええ、はい。今日はですね。これ、プログラミングの、いつも練習をですね、記録しているブログに、動画でですね、ちょっとのせてみようかと思っておりまして。
  • `test`っていうディレクトリで、ちょっとやってみようかなという感じですけど。
  • 今日紹介したいコードはですね、`select.pl`ってやつで。詳しくはですね、GitHubとかにも上げてるはずなので、ブログの方で紹介したいと思いますけども。
  • 私は今この`e`っていう名前のエイリアスを入れてるんですけども。
  • こんな感じですね。複数のファイルをこんなふうに選択して、選択するとこういう`+`マークがつくんですね。
  • で、デフォルトでただ`e`って入れるだけだと、echoするよって、選択したファイルを全部echoするよ、みたいな感じになるんですね。
  • で、そのままやっていいかなってなった場合は……(実行)はい、ちょっとわかりづらいですけど、フルパスで全部出るんですね。3つファイルがあってですね、全部echoされたと。

[02:00]

  • で、それの何が嬉しいのって感じなんですけど、eあるいはそのselect.pl をこれPerlで書いてるんですけど、実行するときの引数にですね、コマンドを何か入れると。たとえば、こんな感じでcatするよと。`e cat`って入れて、 `yes` ってやるとですね。
  • この`project1.txt`ってやつの中身がcatされて、`project3.txt`の中身もcatされて、みたいな感じでですね。ようするに、複数のファイルを選択して、それに同じコマンドを渡すみたいなことをやりたいと。
  • んで、そんなのべつに普通にやればいいんじゃないの、みたいな感じもするんですけど、なんでこんな、ハッシュ値が入っているような長いファイル名にしているのかっていうことが、これを作った理由を示しているんですけど。
  • これをですね、たとえばcatしようって言ってですね。project2なんかを選ぼうと思ってもですね、めちゃくちゃ長いファイル名だと、めんどくさいわけですね。
  • たとえばproject2と、なんかを選びたいなと。projecct2とproject4を選びたいなってときにですね、2015……とか書いても、これでタブを押しても駄目なんですね。2016の……05の……とかやってるとですね、いつまでも選択が終わらないぞ、みたいな。
  • 2017のこれを選びたいので‥‥とかやってもですね、めんどくさくてしょうがないですね。
  • まあ、できますけど、それもこれでやれば、これで選ぶと、楽ですよね。
  • ちなみにもう1回選択すると、消えたりとかするんですけど。
  • まあ、それだけっちゃそれだけですけど(笑)。

[04:40]

  • あとついでにっていうか、`de`っていうエイリアスを仕込んでるんですけど、これ消したいなという時ですね。複数のファイルを消したいと。
  • そういう時は、これ私は`trash`っていうコマンドが入ってるんですけど、ない場合は、まあ`rm`とかでもいいんでしょうかね。
  • 私はこれを仮のゴミ箱がこういう場所にあるんですが、ここにtrashしたいと。(実行)で、どうなったかっていうとですね。1,2,4のファイルしか、もう残ってないと。
  • 複数のファイルをどっかに飛ばしちゃいたいという時にこれはよく使いますね。
  • あとまあ、ちなみに、不可視ファイルをですね。捨てたいなっていう時も時々あるんですね。
  • そういう場合は、`de.`っていうのでやると、ちゃんとそれも飛んでってくれると。
  • 逆にっていうか、そのまま`de`だけだと不可視ファイルは出ないようになってるので、こういうコマンドならこれも消せるよと。
  • そういう感じにしてたりします。

[06:30]

  • あとは複数じゃなくて、1個だけファイルを選んで何かやりたいっていう時は、また別にこれだけで済ませるコマンドを作ってるんですが、またそれは必要があれば紹介するかもしれないですけども。
  • まあどんどん消しちゃって。無くなっちゃいますけど。
  • という感じで、そういうselectコマンドを紹介してみました。

余録

www.youtube.com

※音声入力による文字起こしについては以下をご参照。
21世紀の文字起こし - the code to rock
21世紀の文字起こし(2) - the code to rock

補足

動画の中で、エイリアスのことをちらちら言っていました。補足的に以下に示しておきます。

alias e="perl /path/to/select.pl"
alias de="perl /path/to/select.pl 'trash -r'"
alias de.="perl /path/to/select.pl -a 'trash -r'"

alias d="sh /path/to/delete.sh"
alias d.="sh /path/to/delete.sh -a"

最後にオマケ的に紹介していた`d`, `d.`などは、すでに前回紹介していたdelete.shのエイリアスでした。
最近よく使っている自作ツール(2) delete.sh - the code to rock

プログラミングを学ぶ理由

ひさしぶりに彼女とお茶を飲んで、まったり雑談していたら、不意に

あなたがそんなに好きなプログラミングっていうの、私に教えてみてよ

と煽ってきたので、彼女のMacBook AirのシステムPerlで、ターミナルから「Hello」が出力されるだけのコードを目の前で書いてみた。

print 'Hello';

これをhello.plで保存する。
shebangさえ付けない。改行も入れない。ほんとに最小限。

実行。

$ perl hello.pl
Hello

この「Hello」って書いてある部分を書き換えると、出力される内容もどんどん変わっていくんだよ、と言ってそこをいろんな数字や言葉に置き換えていく。

print 'Hi';

実行。

Hi
print 1234;

実行。

1234

ほらね、という感じで様子を見ると、「これの何が面白いのか、まったくわからない」と言う。

なんで「Hello」って出さなきゃいけないの? 「1234」ってなに? 何か意味あるの? と言う。

あなたもPerl入学式で、人に教えたりするの? それはすごいね。私みたいな人だったら大変じゃない? だって本当に、何もわからないんだから。と言う。

いや、そうじゃない。とぼくは言う。

問題は、プログラミングをやりたいと思っているかどうかなんだよ。「わからない」なんて当たり前なんだよ。だって、最初は誰だって何も知らないんだから。

でも、「プログラミングをやりたい」って思う人は、わからなくてもわからないままやるんだよ。わからなくても、わかるまでやる人が「プログラミングをやりたい人」なんだ。

だから、そういう人に教えるのは何も難しくない。その人がわかるまで付き合ってあげればいい。「わからない」なんて前提なんだ。わからなくても、それはつまずきでもなければ間違いでもない。息を吸ったり水を飲んだりするのと同じだ。それは必要なことですらある。だから困ったりしない。

難しいのは、「プログラミングをやりたくない」という人に教える場合だと思う。そういう人にとっては、「わからない」ということが致命的な問題になる。「何のためにやるのか」ということが問題になる人に教えることは、だから難しい。

「プログラミングをやりたい」という人は、すでに「何のために」がはっきりしているか、そんな目的すらなくてただ何となく「やりたい」という人だから、ぼくらがわざわざ「プログラミングが何の役に立つのか」とか、「どこが面白いのか」なんて教えてあげる必要はない。その人たちはすでに学ぶこと自体を楽しんでいるし、「わからないから」という理由でやめたりはしない。

でも自分以外の意志によってやらされている人は、何かそれを「やる理由」がほしいと思うだろうね。「楽しみ」や「目的」を外部から提供してもらう必要がある。それが悪いってことじゃない。自然なことだ。ぼくだってプログラミング以外の何かに関してはそうだと思う。

そのうち小学校とかでもプログラミング教育をやるらしいけど、それはまた別の話で、基礎的な教養として教えるものだろうから、算数や漢字や英語に馴染ませるようにプログラミングに馴染ませるのはいいことだと思うけど、そういうことじゃないなら、まあ、やりたい人がやればいいことで、ということは「プログラミングの何が面白いのか」を他人が教えてあげたり、他人から教えてもらったりする必要はどこにもないってことになるだろうね。

MacVimで簡単にウィンドウを切り替える

なぜ今まで気づかなかったのか……? たまたまキーを打ち間違えたら実現した。

f:id:note103:20170225164346g:plain

コマンドを押しつつ「 [ 」か「 ] 」を押すとどんどんウィンドウが切り替わる。
これ、今まで一番欲しかったやつや!!

Excelで複数のファイルを開いているとき、コントロール+TABを押すとどんどんウィンドウが切り替わるので、それのMacVim版が欲しい〜……でもそういう機能はなさそう〜って、ずっと思っていた。

で、今あらためてメニューを見直したら……

f:id:note103:20170225165029p:plain:w350

ちゃんと書いてありましたね……こういうの、結構チェックしている自覚だったけど全然見てなかった。

最近よく使っている自作ツール(2) delete.sh

前回に続き、掲題の件。
前回の内容は、以下。

note103.hateblo.jp

今回紹介するのは、以下。

github.com

と言っても、シェルスクリプト1本ですが。

このツールには前段があって、以前にこのブログでも紹介した「trash」というソフトウェアがあるのだけど、

note103.hateblo.jp

github.com

今回のツールはそれを自分なりにアレンジしたもの。

DEMO trash

先に、その元ネタになったtrashの方を簡単に紹介すると、使い方としてはこんな感じ。

f:id:note103:20170218145111g:plain

trashというコマンドの引数にファイル名を入れると、そのファイルを任意のフォルダへ移動してくれる。
ディレクトリを扱う場合はオプション「-r」を付ける)

その移動先が「仮のゴミ箱」みたいな役割を果たすので、いきなりrm -rfとかするより安全でいいよね、しかもコマンドラインからの簡単な操作で不要なデータを捨てられるのでいい感じだよね、みたいな話。

ただこれの場合、ちょっと面倒なのは、いちいち対象のファイル名を自分の手で打ち込まなければいけないところ。

上のデモのようなシンプルなファイル名なら指定しやすいけど、たとえばこんなファイル名がうごめくカレントディレクトリだったりすると、

2016-04-22-project1.txt
2016-05-14-project1.pdf
2016-05-24-project2.txt
2016-05-25-project3.md
2017-05-26-project4.txt
2017-06-26-project5.md

何回タブで補完しても他のファイル名と共通する文字列でいちいち詰まってしまって、目当てのファイルを指定しきるまでになかなか厳しい思いをすることになる。

そこで、こういうファイル群からプルダウン的に(ファイル名を打ち込まなくても)対象を選択できるようにしたいなあ、と思って、例のごとくpecoとchoをこれに結びつけたのが今回のスクリプト

DEMO delete.sh

f:id:note103:20170218145211g:plain

「d」を叩くとカレントディレクトリ内のファイルやディレクトリがバラララッと出てくるので、あとは画面を見ながら対象を選択。すると、それが任意のゴミ箱へ飛んでいく。

(「d.」を叩くと不可視ファイルも候補に含まれる。いずれも後述のエイリアスで設定する)

移動先のゴミ箱は初期設定だと「$HOME/.Trash」(Macのゴミ箱)になっているけど、.bash_profileからTMPTRASH変数に設定すれば自由に置き換えられる。

# ホームディレクトリ直下の tmp_trash/ をゴミ箱にする場合
export TMPTRASH=$HOME/tmp_trash

なお、前述のとおりchoとpecoを使っているので、それらも要インストール

前回紹介したchoco同様、オプションで-aを指定すると不可視ファイルも扱えるようになり、-pを指定すると選択ツールがchoからpecoになる。

よって、それらを組み合わせたエイリアスを設定するならこんな感じ。

alias d="sh /path/to/delete.sh"
alias d.="sh /path/to/delete.sh -a"
alias dj="sh /path/to/delete.sh -p"
alias dj.="sh /path/to/delete.sh -ap"

ちなみに、このエイリアス例にある「d」はdeleteのdだけど、「j」にはとくにそういう意味はない。

jは単に打ちやすいから使っているのと、僕の場合は「pecoを使う時のエイリアスはjにする」という暗黙のルールみたいのがあるのでそうしている。

なんにせよ、これらのツール&設定により、「このファイルちょっと作業の邪魔だな〜。ゴミ箱に移動しとこ」と思ったらポンと「d」を叩くだけでサクサク選択&ポイできる。

一方、このツールだと1回のアクションで捨てられるデータが1個だけなので、複数の対象を選択してポイできるようにしたいなあ、と思って作ったツールもあって、次回はそれを紹介したい。

最近よく使っている自作ツール(1) choco

プログラミングの学習にともない作った自分用のコマンドラインツールというものがあって、折りに触れこのブログでも記録&紹介しているのだけど、それでも以前に紹介した後に手元でどんどんアップデートしつつも外には出せていないものや、新たに作ったけど自分しか知らないツールというのもあって、少しずつでもそういうのをあらためて紹介していきたいと思ったのでそうする。

リストアップしてみたら結構な数になったので、何回かに分けるかもしれない。(いま書きながらどうするか考えている。書き終える頃にはどうなるか決まっているはず)

choco

まずはこれまでも何度か紹介している以下の最新版。

github.com

mattnさんによるchoと、lestrratさんによるpecoを使って、ディレクトリをスイスイ移動したり、移動した先で選択したファイルをオープンしたりする。

choで移動しているところ

f:id:note103:20170217202617g:plain

pecoで移動して最後に選択したファイルを開いているところ

f:id:note103:20170217202639g:plain

オープンするやつはmacOSのopenコマンドを使用しているので、他の環境でどうなるかはわからない。

たぶんコンピュータを開いて作業している日のうち、これを使わない日はないと思う。
我ながらすごく便利だし、俺グッジョブという感じ。

(いやもちろん、mattnさんやlestrratさんのおかげなわけですが)

名前

以前はこのツール、 "dirmove" という名前にしていたけど、それだとファイルやディレクトリ自体を移動させる意味が含まれてしまいそうなのと、移動先のファイルを開く、という目的も大きくなってきたので名前を変えたいと思い、choとpecoを使っているので合わせて "choco" にした。

これ自体は作業のメインに使うものではなく、単にちょこちょこ動きたいだけ、というグルー(のり)的な道具なので、意味を限定しすぎず、なおかつちょっと可愛い感じで良いネーミングではないかと自分では思っている。

懸案

メインのコードはPerlで書いているが、コマンドラインから居場所をどんどん移動して、なおかつ移動先に着地しなければならない都合上、bashrcにも少なからず記述が必要になる。

詳しくはREADME.mdを参照してほしいが、現時点ではこんな感じ。

# .bashrc

function dirmove {
    local result="$1"
    local basename=""
    local dirname=""

    if [ -e "$result" ]; then
        basename=${result##*/}
        if [ -f "$result" ]; then
            dirname="${result%%$basename}"
        elif [ -d "$result" ]; then
            dirname="$result"
        fi
    fi
    cd "$dirname"
}

function choco {
    local command="${@:$#}"
    local result=$(perl ~/path/to/choco/choco.pl "$@")

    if  [ $# = 0 ] ; then
        command=echo
    elif [[ "$command" =~ - ]] ; then
        if [[ "$command" =~ p ]] || [[ "$command" =~ a ]]; then
            command=echo
        fi
    fi

    if  [ -e "$result" ]; then
        dirmove "$result"
    fi
    $command $result
}

alias s=choco
alias s.="choco -a"  # 不可視ファイルを対象に含める
alias j="choco -p open"  # pecoを使う
alias j.="choco -ap open"  # pecoを使って不可視ファイルも対象に含める

zshだとどうなるか、とかはわからない。

上では関数を二つ書いていて、chocoというメインの関数の他にdirmoveという関数を分けて作っているのだけど、これは後日紹介予定の別ツールでもそのdirmove関数を使うから。
逆に言うと、chocoしか使わないならこれらを一つの関数に合わせてしまってもよい。

いずれにせよ、けっこう行数があるので、シェルスクリプトのファイルに切り出した方が良いのではないかと思って何度か試したのだけど、前述のとおりディレクトリを移動するためにはbashrcへの記述が必須のようで*1、仕方なくbashrcにいろいろ書くことになってしまっている。

最後にエイリアスをいくつか設定しているが、ようはデフォルトだとchoを使うようになっていて、オプションとして -p を指定するとpecoを使うようになり、また -a を指定すると不可視ファイルが対象に含まれ、さらに引数の最後にopenコマンドを入れると最終的に選択したファイルがオープンされる、という感じ。

次回予告

似たようなツールを少なくとももう一つ紹介するつもりだったが、結構長くなったのでここまで。

ブログ記事1本あたりの負担を軽減してコンスタントにパブリッシュできるようにしたいところだけど、どうなるか……。

*1:たとえば「start/path/to/end」というディレクトリ構造で、「startから移動してendのディレクトリに出たい」というときに、それらの関数をbashrcではなくシェルスクリプトなどに書くと、操作中はあちこちに移動できるのだけど、操作を終えるとstartに戻ってしまう。

21世紀の文字起こし(2)

以前に書いた記事からだいぶ間が空いてしまったけど、
note103.hateblo.jp

今回はその続編というか、スピンオフ的な経過報告。

ちなみに、一つ前の記事でも本件の環境設定に関することを書いているので、よろしければどうぞ。
note103.hateblo.jp

今回の課題

前回の記事の主眼というのは、

  1. 録音した音声ファイルを聴きながら、Googleドキュメントの音声入力にシャドウイング*1で言葉を吹き込んでいくと、普通に文字起こしをするよりずっとラクにテキスト化できるじゃん!
  2. ……とか思ってたら、さらにSoundflowerというのを使えば自分でしゃべらなくても音声ファイルからダイレクトで文字起こしできるじゃん!!

みたいな話だったと思うのだけど*2、その後にいろいろな音声データでトライしてみたところ、綺麗に拾える場合と、誤認識が多くてカオスな状態になる場合とでバラバラというか、綺麗に拾える条件・法則がちょっとわかりづらかったので、今回は以下の観点から、その辺を整理してみたい。

  1. 再録音の有効性
    1. 再録音(元音声を聴きながらシャドウイングで新たな録音すること)は必要か?
    2. もし元の録音データのままでも使えるとすれば、どの程度の録音状態なら許容範囲か?
    3. 悪音質のデータを再録音したら、どの程度仕上がりが改善されるのか?
    4. 再録音した音声ファイルから音声入力をするのと、直接マイクに向かってしゃべりながら音声入力をするのとでは、どちらの方が精度が高いか?
  2. 音声入力時の再生速度の最適化
    1. 音声ファイルをGoogleドキュメントで音声入力させる際、再生速度は仕上がりテキストに影響を与えるか? もし与えるなら、最も綺麗にテキスト化されるスピードは?
    2. Googleドキュメントは最大で何分程度読み込み続けるのか?

1. 再録音の有効性

1-1. 再録音(元音声を聴きながらシャドウイングで新たな録音すること)は必要か?

結論から言うと、そこそこ綺麗に録音されているデータなら、再録音せずともある程度は正確に拾えるし、環境が整っているところで録音された音声ならば、なお良好な結果を得られると思う。

また、前回の記事でも示したように、英語の音声であれば日本語以上に綺麗にテキスト化されやすいようなので、たとえば英語のPodcastをテキスト化したい、といった場合にも再録音は不要かもしれない。

逆に、講演や会議、あるいは周りの音が一緒に入ってしまう場所でのインタビューなど、録音以外のことがメインになっている環境で録った音の場合、そのまま使うことはあまりお勧めできない。

実際には、そういったデータからでもテキスト化は成されるが、本来の内容との乖離が激しくなる可能性が高く、最初のテキスト化のコストを軽減できたとしても、そこから修正するコストが通常以上に高くなってしまい、かえって非効率になりかねない。

よって、そういった悪コンディションのデータを使う場合には、再録音、または後に示すように、直接しゃべり直しながら音声入力してしまった方が、トータルのコストを下げられるとは思う。

1-2. もし元の録音データのままでも使えるとすれば、どの程度の録音状態なら許容範囲か?

2種類のサンプルを用意してみた。

一つは、昨年のちょうど今頃にプログラミングの勉強会で発表をしたときの録音*3から、1分間だけ切り取ったもの。
2016-01-15_kichijojipm_sample by note103 | Free Listening on SoundCloud

もう一つは、自分のメインブログで時々公開している日記調のモノローグというか、Podcast風に淡々としゃべっている音声から、同じく1分間切り取ったもの。
2016-12-29_sample by note103 | Free Listening on SoundCloud

前者は広めの会議室のようなところで、自分の発表時にスライドを操作するPCの脇にICレコーダーを置いて録音している。
聴講席から他人の発表を録音するよりはクリアだが、それでもあまり良い音質とは言えない。

後者はAudacityというフリーのソフトウェアを使用して、ヘッドセットマイクから直接録音している。

Audacity®

よって、文字起こしを行うための録音としては良質な部類に入ると思う。

そして今回は、それぞれの音声を用いて音声入力をさせているところを、リアルタイムで動画に撮ってみた。
元の音声と仕上がりのテキストだけを提示するより、直感的に違いがわかるかもしれないと思ったので。

ちなみに、この動画撮影に際しては、音声ファイルの再生にExpressScribe*4、その音声を機械に聴かせるためにSoundflower、音声入力にはGoogleドキュメント(ブラウザはGoogle Chrome)、動画の録画にはQuickTime Playerを使用している。

以下では、まず動画だけ2パターン並べて示し、その後に仕上がりテキストを掲示する。
動画内で流れている音声は、そのときにGoogleドキュメントが聴いているのと同じものである。

動画比較
  • 勉強会発表(会議室・ICレコーダーで)
    • 20秒を過ぎてからは変化しなくなるのでそっ閉じ推奨。

youtu.be

  • モノローグ(ヘッドセットマイクで)
    • 上より少し音量が大きいので注意。

youtu.be

テキスト比較
  • 勉強会発表(会議室・ICレコーダーで)

ちょっと待って勇気出してんですけどそれはただ死んだけど
(27文字)

  • モノローグ(ヘッドセットマイクで)

後ね今回でスト掲示板に二つにページしかないんですがさっき言った400局から31局を経て最後の22曲になったって話があるんですけど31よりもちょっと多い70曲ぐらいですかねちょっと今正確に合わせていましたけど迷わ準決勝戦ぐらいの決勝戦が31から22に搾られる家庭だとした場合70キロから30局になる31分解中途半端ですけどね言いながら思いましたけどまたまた勝ったんですけどその70から31になるまでは準決勝みたいな感じが自分では下手ですねそのね70ぐらいまでをあの掲載してますので今回は
(242文字)

ということで、比べるまでもないほど前者はまったく拾えていない。
「メッセージはここで途切れている」みたいになっている。

後者の方はそれに比べるとだいぶ良い。というか、かなり違う。
それでふと気になったので、音声の波形も見てみた。

波形比較

上述のAudacityで、双方前半30秒分を切り出してみる。

なお、勉強会発表の方はICレコーダーのステレオ録音、モノローグはヘッドセットの1マイクなので、見比べやすいように前者はLだけを切り取った。

もしかすると音質以前の問題として、「ステレオはテキスト化されづらい。モノラルだとテキスト化されやすい」などの違いがあるのかな? とも思ったので、別途でICレコーダーのステレオ録音でモノローグを録ってみたが(マイクの近くで発声する)、これは綺麗にテキスト化されたので、ステレオとモノラルの違いはこの際とくに考慮しなくて良いと思う。

ではあらためて、波形の比較。

  • 勉強会発表(会議室・ICレコーダーで)

f:id:note103:20170104105409p:plain

  • モノローグ(ヘッドセットマイクで)

f:id:note103:20170104105425p:plain

別の話をしているので、山の場所が異なるのは当然のこととしても、それ以上に何より起伏の差がかなり違う。
だからどう、ということまでは言えないのだけど、まあ、「起伏の差が激しいとテキスト化されづらく、おとなしいとされやすい」ということなのかな、ぐらいの印象は持った。

で、このような結果を見ると、今度は以下のようなことが気になってくる。

1-3. 悪音質のデータを再録音したら、どの程度仕上がりが改善されるのか?

ということで、次はそれについて検証したい。

まずは先ほど惨憺たる結果をはじき出した、勉強会での発表内容を再録音する。

方法としては、ヘッドセットのヘッドホンからスロー再生で発表を聴きながら、同じヘッドセットのマイクからその内容を吹き込み直す。

ツールとしては、上記同様にヘッドホンへの出力にはExpressScribeを使用し、マイクからの録音にはAudacityを使う。

これが上でも何度か言っている「シャドウイング」というもので、とはいえ今回は元音声でぼくがかなり早口でしゃべってしまっているので、スロー再生を前提にセッティングしているが、シャドウイング自体は「音を聴きながら同じ言葉を発声する」ことができればよいので、このような環境がなければ「iPhoneからイヤホンで音を聴きながら口元で別のレコーダーに録音する」とかでも実現自体は可能である。

で、そのように再録音したものをGoogleドキュメントに読み込ませると、このようになる。

  • 勉強会発表音声(再録音版)

youtu.be

  • 仕上がりテキスト(再録音版)

でもう1個はまあよくあるこれもちょっとミスマッチがちかなっていう気がしているんですけどまあとりあえず4エラーお嫁様と出てるじゃんみたいなそれは正しいんだけどで後はまぁ確かにね英語はちょっとなじまないだろうけどとか言うんだけど英語が問題じゃないたぶんそれは多分エラーを読む人はそもそも何を読んでいるのかって言うと自分の頭で仮設がある程度できていてここでこけるって言うことはこれかこれかこれかそれかそれ以外かっていうのがあるわけですよねですそれと出てきたエラーをその前提と比べていると思うんですよだけど初心者っていうのはそれがもとの仮説がないから出てきたやつをもう最初から読んでいくしかないとだからたぶん日本語で出ても初心者にはわからないと思う日本語で言われても引数がどうだとかサブルーチンが不正な呼び出しをされていますとかしかもそれはちょっと違ったりとかするんで
(380文字)

ということで、元音声では30文字にも満たなかったのが嘘のように、大量かつ高い精度でテキスト化されている。*5

これだけ違いが出ると、ここでもまた波形を見たくなってくる。
で、取ってみた。

波形比較

まずは先ほどの、全然拾えなかったやつ。

  • 勉強会発表(会議室・ICレコーダーで)

f:id:note103:20170104105409p:plain

次に、再録音したらだいぶ拾えるようになったやつ。

  • 勉強会発表(再録音版)

f:id:note103:20170104105955p:plain

だいぶスリムになっている。
ついでに、先ほど綺麗に拾えたモノローグ音声も並べてみよう。

  • モノローグ(ヘッドセットマイクで)

f:id:note103:20170104105425p:plain

はい。まあ、とくにこれを分析できる知識はないのだけど、とはいえやはり、波形が激しいやつだと拾いづらいのかな、という感じはする。

ところで、先ほどの元音声と、再録音版とを聴き比べると、そのスピードが違うことが気になってくる。

どういうことかと言うと、再録音版がゆっくりしているのは、上記のようにシャドウイングする際の都合によるわけだけど、もしかすると元音声の方も再生速度を落としたらけっこう拾えるのでは? みたいな疑問が湧いたということ。

なので、念のために元音声の速度を落とした場合も試してみた。

  • 勉強会発表音声(元音声・再生速度70%)

youtu.be

まったく反応ナシ……(なので途中で止めた)。

1-4. 再録音した音声ファイルから音声入力をするのと、直接マイクに向かってしゃべりながら音声入力をするのとでは、どちらの方が精度が高いか?

上記の検証により、音質の悪い音声ファイルでも、シャドウイングで再録音すれば音声入力によるテキスト化が可能になることがわかった。

しかしここで新たに気になるのが、一度別ファイルに再録音するのではなく、直接シャドウイングしながら音声入力ツールに吹き込んだらどうなるのか? ということだ。

というのも、別ファイルに再録音した場合、その後にGoogleドキュメントに読み込ませるときにもほぼ同じ時間をかけて読み込ませなければならないので、少なくとも元データの2回分(スロー再生で再録音するならばそれ以上)の時間がかかる。

翻って、再録音の工程を省いて直接音声入力してしまえば、その時間が半分で済む。

ということで、同じ勉強会の元音声を聴きながら、直接音声入力してみたのが以下。

  • 勉強会発表音声(直接音声入力版)*6

youtu.be

  • 仕上がりテキスト(直接音声入力版)

もう1個はまあよくあるこれもちょっとミスマッチがちかなっていう気がしているんですけどまあとりあえずエラー読めよと出てるじゃんみたいなそれは正しいんだけどで後はまぁ確かにね英語はちょっとなじまないだろうけどとか言うんだけど英語は問題じゃないたぶんそれは多分エラーを読む人がじゃあそもそも何を読んでいるのかって言うと自分の頭でも仮説がある程度できていてここでこけるって言うことはこれかこれかこれかそれかそれ以外かっていうのがあるわけですよねでそれと出てきたエラーをその前提と比べていると思うんですよねだけど初心者っていうのはそれがもとの仮説がないから出てきたやつをもう最初から読んでいくしかないとだからたぶん日本語で出ても初心者は分からない日本語で言われても引数がどうだとかサブルーチンが不正な呼び出しをされてますとかでしかもそれがちょっと違ったりとかまーするんで
(380文字)

ふむ。若干ながら、上の再録音版より精度が上がっているように見える。
拾った語数もほぼ同じ。

つまり、少なくともこの直接入力の方法が再録音版より劣るということはなさそうなので、もし最初からこの方法を採れるなら、その方が効率は良いかもしれない。

また、先に再録音だけを行う場合というのは、地味に「この発声でちゃんとテキスト化されるのか?」という不安が生じたり、かつ実際にその再録音したものを読み込ませてみたら上手くテキスト化されなかった、なんていうことも何度かあったりしたので、そのように結果が出るまで不安を抱えてしまうぐらいなら、最初から直接入力でフィードバックを確認しながらやったほうが精神的にラク、というメリットもあるかもしれない。

一方、これはあくまで個人的な実感だけど、この直接入力というのはなかなか疲れる。
上記のように、基本的には目の前で起こされていく状況を確認しながら進めることになるので、そうなると「音を聴きながら発声する」という作業に加え、「目視で仕上がりを確認する」という作業をマルチタスク的に抱えることになり、そのぶん肉体的な負担が増すのかもしれない。

また、直接音声入力をする際には、Googleドキュメントで文書を作成しながら録音を行える環境を整えなければならないので(マイクのセッティングなどはもちろん、他人の迷惑にならない場所へ移動するなど)、そうした「ちょうどよい環境」を作るコストが低くない。

その点、先に再録音を行ってから、別の機会に音声入力をするのであれば、トータルの作業時間は多くなるとしても、それぞれの特化的な作業に集中できるので、並行して一気にすべてを進めることに比べて負荷が低く、継続的な作業を見込める面もあると思う。

よって、この「再録音」と「直接入力」の選択に関しては、上記のようなメリット/デメリットを踏まえつつ、作業者それぞれの目的や、環境に応じて適した方法を選ぶのが良いように思える。

2. 音声入力時の再生速度の最適化

2-1. 音声ファイルをGoogleドキュメントで音声入力させる際、再生速度は仕上がりテキストに影響を与えるか? もし与えるなら、最も綺麗にテキスト化されるスピードは?

これについては、上記の再録音版データを「150%(速い)」「標準速度」「50%(遅い)」の3種類で読み込ませてみた。
(「標準速度」は前出のもの)

先に動画を3点並べ、その後に仕上がりテキストを並べて掲示する。

動画比較
  • 再生速度150%

youtu.be

  • 再生速度100%(再掲)

youtu.be

  • 再生速度50%

youtu.be

テキスト比較
  • 再生速度150%

もう1個はまあよくあるこれもちょっとミスマッチがちかなっていう気がしているんですけどまあとりあえず予定はお嫁様と寝てるじゃんみたいなそれは正しいんだけどで後はまぁ確かにね英語はちょっとなじまないだろうけどとか言うんだけど英語が問題じゃないもんたぶんそれは多分エラーを読む人がそもそも何を読んでいるのかって言うと自分の頭で稼ぐがある程度できていてここでこけるって言うことがこれかこれかこれかこれかそれ以外かっていうのがあるわけですよねでそれと出てきたエラーをその前提と比べていると思うんですよだけど初心者っていうのはそれがもとの仮説がないから出てきたやつをもう退職から読んでいくしかないとだからたぶん日本語でても初心者にはわからないと思う日本語で言われても引数がどうだとかサブルーチン学生の呼び出しをされていますがしかもそれはちょっと違ったりとかするんで
(376文字)

  • 再生速度100%(再掲)

でもう1個はまあよくあるこれもちょっとミスマッチがちかなっていう気がしているんですけどまあとりあえず4エラーお嫁様と出てるじゃんみたいなそれは正しいんだけどで後はまぁ確かにね英語はちょっとなじまないだろうけどとか言うんだけど英語が問題じゃないたぶんそれは多分エラーを読む人はそもそも何を読んでいるのかって言うと自分の頭で仮設がある程度できていてここでこけるって言うことはこれかこれかこれかそれかそれ以外かっていうのがあるわけですよねですそれと出てきたエラーをその前提と比べていると思うんですよだけど初心者っていうのはそれがもとの仮説がないから出てきたやつをもう最初から読んでいくしかないとだからたぶん日本語で出ても初心者にはわからないと思う日本語で言われても引数がどうだとかサブルーチンが不正な呼び出しをされていますとかしかもそれはちょっと違ったりとかするんで
(380文字)

  • 再生速度50%

でもう1個はまあよくあるこれもちょっとミスマッチがちかなっていう気がしているんですけどまあとりあえずよヘラを読めよと出てるじゃんみたいなそれは正しいんだけどで後はまぁ確かにね英語はちょっと馴染まないだろうけどとか言うんだけど英語が問題じゃないたぶんそれは多分エラーを読む人はそもそも何を読んでいるのかって言うと自分の頭でか説がある程度できていてここでこけるっていうことはこれかこれかこれかそれかそれ以外かっていうのがあるわけですよねですそれと出てきたエラーをその前提と比べていると思うんですよだけど初心者っていうのはそれがもとの仮説がないから出てきたやつをもう最初から読んでいくしかないとだからたぶん日本語で出ても送信者には分からないと思う日本語で言われても引数がどうだとかサブルーチンが不正な呼び出しをされていますとかしかもそれはちょっと違ったりとかするんで
(380文字)

ということで、目視でこれらの違いを判別するのはけっこう大変なのだけど、ざっと読み取れるのは以下のようなこと。

  • 拾える文字数はほぼ変わらない。
  • 再生速度が速くても遅くても、それぞれ100%の場合に比べて誤認識が増えている。
    • 150%: 「仮説」→「稼ぐ」、「最初」→「退職」
    • 50%: 「エラー」→「ヘラ」、「初心者」→「送信者」

じつは事前の仮説としては、「スピードが遅いほど綺麗に起こされるのでは」と思っていたのだけど、実際には遅くすれば綺麗になるということはなく、むしろ読み込ませるのに余計時間がかかる分、デメリットの方が多いと思えた。

逆に、再生速度を速くしてもこのぐらいの誤認識で済むのであれば、それによって読み込む時間を短縮できるメリットを取った方が良いと考えることもできるが、とはいえこの段階でミスが多くなると、その後に行うテキスト編集(修正)の段階で手間や集中力といった負荷が増えるので、やはり誤認識は少なければ少ないほどよいとも思える。

よって、その辺りも含めて総合的に考えれば、標準速度(再生速度100%)にするのが無難かなと思うが、よくよく考えてみれば、再生速度が速すぎても遅すぎても、本来の人間がしゃべる言葉から離れていくことになるわけで、ようは「最も一般的な人間のしゃべり方に近い速度」を設定するのが良いということかもしれない。

また、そもそも人がしゃべる速度というのも人によって様々なわけで、ゆっくりしゃべっている音声ならやや速めに、逆に早口な人なら速度を落とすように、といった調整を行った方が綺麗に検知することもあるかもしれない。

2-2. Googleドキュメントは最大で何分程度読み込み続けるのか?

ところで、上記の動画群を見て気づいた人もいるかもしれないのだけど、前回の記事でぼくはこのようなことを書いていて、

4. 音声ファイルが終わるまで再読み込みなどのケア
前述のように、入力は音声ファイルが止まるまで続くわけではなく、途中で止まる。いわばフリーズしたような状態になる。
調子が良ければ1分以上入力され続けることもあるが、平均的には40秒程度かもしれない。
(略)
よって2秒程度入力が止まったら、もうフリーズしたとみなして再起動する。
具体的には、マイクボタンを押して一度入力機能をストップし、もう一度押して再開させる。すると、また入力が始まる。

しかし上の動画においては、そのような再起動は不要だった。

もしかすると、Googleの音声入力機能が向上したということだろうか?
よくわからないが、とりあえず現時点ではどの程度、再起動せずに動き続けるのか気になったので、これも試してみた。

といっても、そのためにわざわざ長尺の再録音をするのも面倒なので、上で元音声のままでもそこそこの精度でテキスト化された、モノローグ音声のフル尺版(約11分半)を読み込ませてみた。

結果はこのような感じ。*7

youtu.be

なんと音声ファイルが終わるまでの11分半、すべて再起動なしで読み込んでしまった。

じつはブラウザの拡張機能iMacrosというツールを使うと、一定時間ごとに任意の処理をさせることができて、それを設定すれば数分ごとに音声の読み込みを再起動させることができるので、いずれその方法も紹介しようと思っていたのだけど、これならもはや不要かもしれない。

経験上、この音声入力機能は音を読み込めない時間がしばらく続くとストップしてしまうようなので、切れ目なく読み込める程度に音質が良いファイルなら、再起動の必要性が低くなったということなのかもしれないが。

まとめ

例によって長くなってしまったけど、最初に掲げた課題については触れ終えたので、ひとまずここまでのまとめ。

  1. 再録音の有効性
    1. Q1: 再録音(元音声を聴きながらシャドウイングで新たな録音すること)は必要か?
      • A1: 録音状態が良ければ不要な場合もある。ただし誤認識が多ければそのぶん後の作業に負債を抱え込むことになるので、後のことまで考えて判断すべし。録音状態が悪ければ再録音一択。
    2. Q2: もし元の録音データのままでも使えるとすれば、どの程度の録音状態なら許容範囲か?
      • A2: 講演会場や会議室など広い空間におけるICレコーダー等での録音は、そのままでは使えない可能性が高い。一方、マイクと発声源が近い録音ならば良好な結果を得られる可能性が高い。
    3. Q3: 悪音質のデータを再録音したら、どの程度仕上がりが改善されるのか?
      • A3: まったくテキスト化されなかったものが、かなりテキスト化されるようになる。
    4. Q4: 再録音した音声ファイルから音声入力をするのと、直接マイクに向かってしゃべりながら音声入力をするのとでは、どちらの方が精度が高いか?
      • A4: 直接しゃべりながら音声入力を行った方が、精度が高くなると思われる。この場合、再録音の工程をスキップできるので、作業時間の短縮というメリットもある。ただし、工程を分ければ環境を準備しやすくなったり、作業負荷を軽減できたりするメリットもあるので、状況に応じて判断すべし。
  2. 音声入力時の再生速度の最適化
    1. Q5: 音声ファイルをGoogleドキュメントで音声入力させる際、再生速度は仕上がりテキストに影響を与えるか? もし与えるなら、最も綺麗にテキスト化されるスピードは?
      • A5: 1分のサンプルデータで確認したかぎり、再生速度による大きな違いはないが、その中では標準速度の仕上がりが一番良いように見える。ただし、元音声の発話速度によって、チューニングの余地があるかもしれない。要検証。
    2. Q6: Googleドキュメントは最大で何分程度読み込み続けるのか?
      • A6: 以前に試した際は40秒〜1分程度ごとの再起動が必要だと感じたが、今回試したところでは10分以上にわたるノンストップの入力が実現した。ただし、音質が良好であるという条件が必要かもしれず、その他にも長時間入力を実現させるための条件があるかもしれない。要検証。

免責事項

今回行った各種の実験は、限られたサンプルと機会を通じて、それぞれ1〜2度ずつ試してみたものに過ぎないので、普遍的な正解ではまったくない。

再現性の高い結論を出すためには、より厳密に条件を揃えた上で、同じ実験をくり返し行うべきだが、さすがにそこまではできないし、そもそもこのツール自体どんどんアップデートされていくだろうし、あるいは突然使えなくなってしまう可能性だってある。

あくまで一人のユーザーが、個人的・自主的にいろいろ遊んでみた結果として見てもらえたらありがたい。

次回予告

前回の最後で、textlintの導入について予告したのだけど、それ以前の音声入力関連の情報をまとめるだけで力尽きてしまった。
textlintの使用を含む、「テキスト整形」に関わる作業については、次回以降にあらためてまとめてみたい。
(いつになるかは無保証だが……)

*1:耳から入った音声を追いかけるように発声すること。語学の学習などでよく行われるらしい。

*2:もう半年前の記事で自分でも忘れかけていたので、この部分を書きながら少しずつ思い出した。

*3:元資料などはここで読める。→ 吉祥寺.pm6に参加しました(トーク音声公開&スライド作成方法) - the code to rock

*4:音声の再生はiTunesなど他の汎用音楽ソフトでも可能だが、ここでは細かいショートカットキーの設定が便利なのでExpressScribeを使った。

*5:不思議なことに、というか、皮肉なことに、というか、この再録音版は、人間の耳で聞くと、元の音声よりぎこちない調子で、けっして聞き心地が良いとは言えないのだけど、機械にとってはこちらの方が聞きやすいようである。これが人間にとって聞きづらく感じられる理由は、この音声がシャドウイングという、「発声し直すこと」を目的に録音されているからであって、言い換えれば、「人間に話の内容を理解してもらうこと」を目的にはしていないからだと考えられる。つまり、想定リスナーは「人間ではない何か」である。そのような音声が人間からは親しみを持たれづらく、しかし機械からは理解(というか解釈)されやすい、という状況が面白い。

*6:メインの発話の後ろで薄く聞こえている声があるが、これはヘッドホンから漏れている元音声。シャドウイングは耳から入る音に集中して、自分の発声はあまり聞こえないようにした方がやりやすい、という話を時々聞くけど、まさにそんな感じがしたのでヘッドホンの音量を大きめにしていた。

*7:実験の目的上、仕上がりテキストは不要なので動画のみ掲示するが、通読できる程度まで整形したテキストはここで読める。→ 音声入力を用いた文字起こしでブログ(3) 〜schola16巻のつくり方〜 - 103