前回、自動文字起こしについて書きましたが、
今回は、文字起こしをせずにインタビュー記事を書く方法について書いてみます。
事例
これについてはすでに適用事例がありまして、もう1ヶ月以上前になりますが、以下の記事をこの方式で書きました。
普段引きこもりがちなぼくにしては珍しく、このときは山口まで出張して、YCAM（ワイカム）というアートセンターで同館のスタッフとしてあらゆるドキュメンテーション業務、また広報その他の分野において、ITを駆使しながら活躍されている渡邉朋也さんにインタビューしてきました。
＊同記事については、以下のブログでも簡単に紹介しました。
渡邉さんはとにかくすごいバイタリティの方で、どれだけ面白い話をしても尽きないし、ぼくもけっこうお付き合いが長いのでずーっと話していたらトータルで7時間弱、ICレコーダーが回っていまして。そうなると、もうこれ文字起こしなんかしてたら一生原稿できないな〜・・ということで、今回の方法を開発することになったのでした。
ちなみに、じゃあ普段はどうしているのかというと、たとえばぼくがこれまで手がけてきた以下のCDブックの場合、
このブックレットでは、毎回大体3万字弱ぐらいになる座談会を掲載しているのですが、これは平均で4時間ちょいぐらい、ずっと参加者の皆さんがおしゃべりをして、その録音をもとに8万字ぐらいの文字起こしテキストを作って*1、それを見ながら構成（文章全体の構造や流れなど）を立てて、その後はどんどん不要な部分をカットしながら原稿を作っていきます。
しかしながら、今回の7時間録音はさすがに文字起こしはしたくないというか、やってはいけないというか、文字起こし自体が目的（提出原稿）ならそれでもいいんですが、目的はその先にあるまとまった原稿であり、また現実的に締切りなどもあるので、「いかに効率よく、時間をかけずに、良質な記事を作れるか」という目的のもと、工程自体を新たに考えた次第でした。
作業の流れ
さて、その具体的な工程ですが、大まかに記すと以下の2つの流れに分かれます。
原稿編
キーワード起こし／キーワードマップ
ということで、そのキーワード起こしについてもう少し解説します。解説用のサンプルとして、いつものように今年3月に沖縄で登壇したときの再現動画を使います。*2
これに対して何をやるのかというと、まずは録音全体を任意の間隔で区切り、それぞれの時点でどんな話をしているのか、スプレッドシートにメモしていきます。
この発表は全長85分ということで、それほどの長尺でもないので、5分間隔で区切りたいと思います。もしこれが7時間とかだったら、とりあえず15分おきぐらいまででいいと思います。あまり細かく区切るとやる気が続かないので・・。
とはいえ、85分でも初めから5分おきに聴いていくのは大変なので、まずは半分に分割してみましょう。大雑把に80分と考えて、半分の40分時点ではどんな話をしているでしょうか？
＊視聴中・・
はい、発表全体の内容を知らないとちょっとわかりづらいかもですが、「再帰的にどうしたこうした」と言っています（40:20頃）。ここでは「シェル（ターミナル）」を使った作業に関して話していて、具体的には自作の「f」というコマンドを使って、任意のディレクトリ内で再帰的にファイルを検索する方法について喋っています。
それを把握できたら、以下のような感じでGoogleスプレッドシートに記入します。
A列の10行目、「40」とある行に、
シェルのパートでfコマンドについて。再帰的にどうしたこうした
と書きました。
では、もう少し分割して、今度は20分時点と60分時点を埋めてみます。
20分時点では、「どんどんカットしていける。後で戻せる」と言ってますね。この部分は先ほどのシェルの話の前のパートで、Vimに関する話をしているようです。
60分時点では、「ついでというか。こんなのもやってますよ、というのをここに書いてますけど」と言ってます。こちらはシェルの話のひとつ後のパートで、Perlに関する話をしています。
ということで、これらを先ほどと同様に記入すると、こんな感じ。
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番の質問事項について、これはインタビューの現場で「とりあえずこれについては聴いておきたい」という内容を事前に書き出しておいたもので、ぼくの場合はルーズリーフ2〜3枚に手書きでリスト化して、色ペンでさらにマーキングやメモなどを付して用意していました。
このときの質問は全部で23個でしたが、質問にはある程度共通する傾向というか、カテゴリが存在するので、そのカテゴリごとにまとめておきます。
冒頭の記事で言うと、最終的には以下5本の見出しが立っていますが、
元々の質問はプラス2〜3本（計7〜8本）のカテゴリに分かれていました。
で、この段階では実際のインタビュー内容については一旦忘れて、その質問カテゴリを「小見出し」として、またそれぞれにぶら下がっている質問事項を各見出し内のコンテンツとして列記していきます。それだけ、といえばそれだけですが、これがこの後の作業の大元というか、叩き台になります。
2. 質問の内容やカテゴリ（小見出し）を実態に即して調整
1の状態はあくまで事前に作った資料を元にしたもの（叩き台）なので、今度はこれを現場で行われたインタビュー内容に合わせて調整していきます。
ただし、ここでは次の工程3と同様、当日の流れを厳密に再現する必要はありません。事前に予定していた質問のうち、カットしたものを外したり、追加したものを適宜加えておく程度で充分です。
3. 想像力で回答を埋めていく
次に、上記2で作った質問に対する相手の回答を、自分の記憶や想像でどんどん埋めながら全体の流れを作っていきます。このとき、相手が実際にそう言っていたかどうか、という確認はひとまず後回しで大丈夫です。
なぜなら、第一に大半の内容はその後に修正することになるからで、第二に、この段階でそういった確認をちまちまやっていると全体の流れを作りづらくなるからです。通常、読者は記事を最初から最後まで1本の線を辿るように読んでいきますが、現場ではあちこちに話が飛びながら進んでいますから、現場の実態を重視していたらいつまでも読者に読みやすいものは作れません。
よって、ここではあたかも自分が最初の読者であるかのように、「こういう流れでこの記事を読みたい」と思う文章を作っていきます。上記1と2の工程はその準備であり、この3はそれを踏まえた通し稽古のようなものです。実際の進行順と異なるからといって、「事実と違うぞ！」などと指摘してくる人はいませんし、そもそも執筆者は現場で話した内容を誰よりも把握しているはずなので、「事実と異なるかも」などということは心配せず、まずは自分の想像の世界で1本の物語を作ってしまいましょう。
4. 記憶が曖昧な箇所をキーワードマップで確認する
ある程度、質問と回答のやり取りを埋めて全体の流れができたら（あるいはその途中でどうしても現場の発言を確認したくなったら）、ここでキーワードマップの登場です。おもむろにGoogleスプレッドシートの検索機能を使って、検索したい箇所で話しているはずのキーワードを入力し、音声ファイルの中のどこでそれを話していたのか、突き止めましょう。
不思議なことに（あるいは当然のことかもしれませんが）、現場で話したことや、相手から聞いた言葉というのはけっこう頭の中に具体的に残っているもので、それを検索クエリとして使うと、大抵の発言は見つけ出すことができます。
たとえば、山口の記事で使ったキーワードマップで「パブリシスト」を検索すると、こんな感じになります。（一部伏字の上抜粋）
はい。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:オカルトっぽい説明ですが、きちんと説明しはじめるとそれだけでまた長文になるので割愛。
