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

中島聡著『なぜ、あなたの仕事は終わらないのか』感想: 最大のパフォーマンスを引き出すために

book

Kindle Unlimitedで読めると知って、本書を読むためにKindle Unlimitedに登録した*1

著者は有名な方なので、名前や活動歴はざっくり知っていたが、少し前にハフポストに載った以下の記事を読んで、同書に興味を持った。

www.huffingtonpost.jp

おおよその雰囲気はその記事からもつかめると思うが、個人的に「これは新鮮だな」と思ったところをいくつか書いておきたい。

1. 脱ラストスパート志向

とりあえず、本書の一番のテーマはこれだと思う。

仕事が終わらない人は最終盤の逆転を狙ってしまう。ギリギリまで行動を起こさず、締切り&徹夜パワーで乗り切るぜ、みたいな夢を見ては失敗する。学びがない。

著者はそうじゃなくて、与えられた時間の最初の2割でまず作業全体の8割を終わらせろ、という。
もしその時点でそこまで終わらなかったら、残り8割の時間で全体を終わらせることはできないから、と。

この2割・8割の法則じたいはどうしても直感に反するというか、さすがに極端ではと思わなくもないが、それでも深く共感するのは、そういったラストスパートのパワーに幻想を持つな、みたいなことで、その点は非常に参考になると思った。

その流れで著者は朝型生活を勧めるのだけど、ぼく自身は40を過ぎて自分が今のところ非・朝型だとつくづく感じるので、そのまま生かすことはできないものの、「1日の前半にコアタイムを持ってきて後半は流せ」という思想じたいは活用できそうだと感じた。

2. 脱マルチタスク主義

本書には「なるほど〜」「ですよね〜」と感心・納得するポイントが満載なのだけど、中でも膝を打ってしてしまったのはこれで、仕事に集中したかったら作業中は一つのことだけをやれ、という。

1日を複数の時間帯に区切り、それぞれの時間内で別の作業をするのはOKだが、一つの作業中は別のことを考えるな、と。

これはぼくの感覚にも非常にフィットする考え方で、まったく同感だが、とはいえ現実の世界ではどうしても割り込みタスクや、その他集中を拡散してしまうあれこれというのはあるもので、やはり初めからこれを意識するのとしないのとでは大きな違いが出るだろう。

また、ぼくには一方でマルチタスク主義というのか、様々な異なる作業を並行して処理する良さ、みたいなことを考えてしまうときもあって、そういうブレというかゆらぎの余地を少なくする意味でも良い指針になった。

もう一つ、これに近い発想というか考え方として、「スラック(心の余裕)を持つ」ということについても触れられていて、それも大変面白く、役立つと思った。

心の余裕を持つことで作業に集中しやすくなる、と言葉で言うのは簡単だが、実行するのはそう簡単でもない。
しかしこうして、他人がバシッと言ってくれるとそれが後押しになって今まで以上に実現しやすくなりそうだと感じる。

3. 責任感とは

本書では著者がかつて勤めたマイクロソフトや、同社のトップだったビル・ゲイツに関するエピソードもいろいろと語られるのだけど、その中でもひときわ印象的だったのが、「パーティー会場に花束を届けるようビル・ゲイツから指示された人*2」の話だった。

これについては著者による以下のブログ記事でも引用されているので、興味があればそちらを読んでほしいが、

Life is beautiful: デカルトは「困難を分割せよ」と言い、ビル・ゲイツは「問題を切り分けろ」と言った

ここで問題となっている人は、指示された通りに花が会場に届くようオーダーするのだけど、花屋の都合で届かない。

そしてこのとき、その人は自分が「花を注文しろ」と指示されたのだと解釈しているから、自分の仕事はすでに完了していて、花が会場に届かないのは「花屋の責任」だと思っている。

しかしビル・ゲイツはその人に「花を届けろ」と指示したのであって、届かなければそれは指示された人間の責任なのだという話。

この、「花を注文するまで」が仕事なのか、それとも「花を届けるまで」が仕事なのかという認識のズレというのは、本当にリアルで生々しく起こりがちな状況なので「うわ〜」と思った。
本書ではいくつもそういう「うわ〜」を感じたけど、中でも「うわ〜」度が高い話だった。

しかしまあ、「え、俺はちゃんと注文しましたけど? 悪いのは花屋ですよね」と言う人にこんな話をしたところで、それが通じるとも思えない。
この話を生かせるとすれば、自分が「自分の仕事はどこまでなのか」を考えるときだろう。

4. モックを作る

自分は締切りを守って仕事をしていても、協業者の仕事が遅れたらその影響で自分の作業も遅れてしまう。そういうときにどうするか? という話。

これまた上記の花屋の話に匹敵する「あるある」話で、読みながら「いやまじで、そういう場合ってどうしたらいいの? 教えてください!」という感じで読み進んだが、書中の回答は「モックを作る」。

言い換えると、待っている間にとりあえず自分で大ざっぱな代替物を作ってしまって、それをもとにその続きにある自分の作業を進めておく、ということ。

これまた「なるほどね〜」という感じだった。

ちなみに、本書ではこれとは別に、「物事を進めたかったら書類をまとめるとかじゃなくてとりあえず目に見える成果物、プロトタイプを作れ」みたいなことが何度も言われるのだけど、ここで言うモックはそれに似ていながらけっこう本質的に違う。

プロトタイプの話も大変有用ではあるのだけど、それ以上にぼくがこのモックの話を「すごい」「こりゃ役立つな」と思うのは、結局それも花屋の責任の話と同じで、今までぼくは他人が遅れたせいで仕事が遅れたら、「俺のせいじゃないもん。あの人が遅れたせいだもんね」と、自分の責任ではないものとして済ませようとしていたと思われ、それは感じ方としては自然だが、現実的にはそうじゃない、ちゃんとやりようがあるのだ、と気付かされたという点で大きな話だった。

5. 認知資源

ふたたびビル・ゲイツの話。ビル・ゲイツは社員から何か専門的な話を聞くときに、対象の一人ひとりから直接話を聞くのではなく、それらの話を解釈してビル・ゲイツにわかりやすく説明する「専門の説明係」を雇って、その人からだけ話を聞いていたという。

そうやってつねに同じ人の解釈や説明能力といった「一定のフィルター」を通して話を聞くことで、個々の社員の多様さに左右されない、安定した低コストで情報を収集していたということ。

非常に徹底しているし、合理的だと感じる。
そのまま自分に応用することはできないとしても、何かしらの似たような工夫で、普段感じている負荷を下げることはできるかもしれない、と感じた。

なお、この際、そのように物事を考えたり判断したりするリソースを「認知資源」と呼ぶこと、たとえばそれは朝、その日に着る服を選ぶときにも消費される資源であること、といった話も紹介されており、この「認知資源を無駄遣いしない」という考え方にも非常に共感を覚えた。

5. 英語・資格の勉強法

英語や資格の勉強をやろう、というときに、明確な目的がなければ達成は困難だという話。

むしろ、そうした勉強が長続きしなかったり、集中できなかったりするのは「勉強自体が目的になってるからでしょ」ということ。

もしちゃんと目的があって、勉強があくまでその「手段・経過」でしかないなら、そもそも集中できないとかあり得ないじゃん、みたいな。

これもまたわかりやすい。なるほど、目的がない(または弱い)から勉強が長続きしないのか、と。説得力がある。

と同時に、ぼくがたとえば英語や資格、あるいはプログラミングの勉強を中途半端にしかできないのは、それをチャラチャラしたファッションというか、アクセサリーのように身にまといたいからなのだ、とこの話を読んでほとんど初めて気がついた。

そして、それならぼくは今後もチャラチャラとした、目的にもなっていないような弱い目的をもってそれらに取り組もう、とも思った。

本書の主張に基づくなら、「英語ペラペラになりたい」などという願望は英語を勉強する目的になっていない。そこには曖昧なイメージ(雰囲気)があるだけで、具体的な「英語を使ってこれをしたい」という対象がないからだ。
しかし「ファッション(=自分を飾る道具)として英語を身につけたい」と考えるなら、それは充分に「目的」と言えるし、そこにはひとまず「こんなふうになりたい」というイメージがあればよい。

そして結局のところ、ある種の取り組みの成果を左右するのは、それを「続けるかどうか」に尽きる。

これまでぼくは、ただなんとなくそれらの勉強をしていたが、なるほど飾りとしてそれを身につけたいのか、と目的を意識化できた気がするので、今後はその目的に沿ってトライを続けてみたい。

7. 好きを仕事に

終盤で語られる、ある意味で身も蓋もない話。

ひと言で言うと、「集中できないとか悩む以前に、そもそも自然に集中できない仕事なんかするな」ということ。

それが本当に好きなことだったら、「どうしたら集中できるんだろう」なんて考えるまでもなく、あるいは誰かから言われるまでもなくそれに没頭してるだろ? という。

たしかにそうだ。返す言葉もない。そして著者は重ねて言う。
「自分が本当にやりたいことを見つけろ」

この辺りの話が猛然と語られる第6章は、他のどの章とも違う独特の面白さがある。

あまりに本質的で、それゆえ抽象的で、読みながらぼんやりしてしまう部分もあるのだけど、そのままふと立ち止まって、「好きなことか……ていうか、俺って何が好きだったんだっけ?」と胸のあたりを覗き込む、その感覚はけっこう久しぶりだと感じる。

そのまますべてを真に受けて、そうだそうだ! という感じでもないのだけど、それでも時々読み返したくなる話だと思う。

本書には他にもいくつもの「なるほど〜」があって、なかなか飽きない。
実践的だったり、抽象的だったり、マイクロソフト時代のような具体的な話もあれば、いきなり「界王拳」が飛び出したりもする。

個々のトピックが印象的なせいか、全体を通しての軸というか、大きな構造というのはちょっと見えづらいのだけど*3、上でぼくが自分なりの7点をピックアップしたように、読者それぞれが自分に必要な部分、役立つ知見を再構成しながら活かしていくことはできるだろう。

ちなみに、上で触れられなかった次点的なトピックを備忘録がてら書いておくと、「昼寝の有効性」「もしも編集者がこのメソッドを使うなら」「まず調べる」「予習勉強法」といったところか。

昼寝はぼくもよくやるし、本の編集は(曲がりなりにも)自分の仕事なのでそれもびっくりした。
「調べる」ことの意義、効果の高さについてはけっこうサラッと書いてあるのだけど、ちょっとすごみを感じる重要さだと思った。

という具合にネタは尽きないが、ひとまずここまで。

*1:いろいろな評判が出ているが、個人的にはKindle Unlimitedとてもよい。サンプル(試し読み)の拡大版として考えれば充分値段に見合う内容だと思える。

*2:このエピソード自体は実話ではなく、ビル・ゲイツが嫌う「仕事や時間に遅れる人の言い訳」と、それを嫌う理由をわかりやすく説明するための喩え話だと思われる。

*3:章の構成は第1章〜3章、第4章〜5章、第6章、と大きく3部に分かれていてきちんと練られていると思うが。

『スクラム実践入門』感想: チーム開発の参考書

book

発売後けっこうすぐに買ってはいたのだけど、少し目を通してそのままにしていたのを2週間ぐらい前から少しずつ読み直して、けっこうみっちり最後まで読んでみた。

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

ひと言で感想を言うと、本としてよく出来ていて、道具のようにひき続き使っていけそう、という感じ。

「本としてよく出来ている」というのはどういうことかと言うと、たとえば構成がシンプルでよい。

第1章 ソフトウェア開発の困難にスクラムで立ち向かう
第2章 スクラムチーム
第3章 スクラムイベント
第4章 スクラムの作成物
第5章 スクラムを支えるプラクティス
第6章 GMOペパボの事例 ── どのように導入したか
第7章 mixiの事例 ── 導入失敗からの立てなおし
第8章 DeNAの事例 ── 大規模開発,業務委託への適用
第9章 スクラム導入時によくある問題と解決策
第10章 スクラムチームでよくある問題と解決策
第11章 スクラムイベントでよくある問題と解決策
第12章 スクラムの作成物によくある問題と解決策
http://gihyo.jp/book/2015/978-4-7741-7236-1#toc から章題のみ抜粋)

概説的な第1章を除くと、複数の章が一連のパターンを持つひとかたまりのブロックのように構成されていて、それが各章内でも同様に(入れ子のように)繰り返されていく。
たとえば上記の12章は、大きく第2章〜5章でひとかたまり。第6章〜8章が同じくひとかたまりの2周めで、第9章から12章が3周め、というふうに分けられる。

一度このパターンが体に馴染むとあとはそのリズムに乗って読んでいくだけというか、「次はこんな感じの話が来るだろう」と予測しながら読んでいけるので本質的な差分に集中しやすく、とくに後半は楽しく読めた。

「とくに後半は〜」と書いたが、それは本の後半という意味ではなく、読書体験の後半である。
というのも、ぼくの場合は第1章から順番に読んだのではなく、まず第5章、その次に2章を読んで、そこから3、4……と終盤に向けて読み進め、最後に第1章を読んだから。

なぜそんな変則的な順番で読んだのかと言うと、第1章は抽象的・俯瞰的な話であり、しかし読み手の自分としては何よりもまず具体的な話、つまりこれを導入したチームではどんなことをやるのか、それによってチーム開発を襲うどんな問題にどう対処できるのか、みたいな「結局、スクラムってなんなん?!」ということを知りたかったので、最初に我慢して抽象的な説明を読んでいるとすぐに飽きてしまいそう、という懸念があった。

それでパラパラとめくった中でもとりわけ「具体的に何をやるのか」について書いてありそうな第5章から読んだのだけど、これは半分正しく半分失敗で、何しろスクラムというのは「スプリントレトロスペクティブ」とか「プロダクトバックログ」とかいった専門的な用語を多用する方法論で、しかし第5章では「もうそういう説明は今までの章で存分にしたよね」という前提で、そういう用語の再説明などはしないので、いきなり途中から読んでもそうした用語が出てくるたびに「ぐぬぬ……意味わからん……日本語で喋れや……」みたいになってしまってつらかった。(これは読者が悪い)

と同時にしかし、これも冒頭に書いた「本としてよく出来ている」の一面なのだけど、同書は巻末の索引が非常によく出来ていて、そのような不良読者であっても、ちょっとつまづいた用語に出会うたび、索引をちょっと引いて、その初出で説明されている部分をちらっと読めば大抵「はあ、そういうことね」と、おぼろげであれ把握できる。

もちろん実際にその章や前後をみっちり読まないことには、深く理解することはできないわけだが、少しでも早く「ようするにどんなことをやるの?!」を知りたかった自分にとってはとりあえずそんな感じで充分だった。

索引を多用しながら第5章を読み終えて、さあ次はどれがいいかな、と考えたとき、先に挙げた目的からすると、

これを導入したチームではどんなことをやるのか、それによってチーム開発を襲うどんな問題にどう対処できるのか

第6章以降の導入事例に進めばよいところなのだけど、第5章の「前提にしてる用語がわからん問題」を身をもって体験した後ではあまりそういう冒険的な気持ちにもなれず、素直に最初から読み進めようということで、具体的な説明の最初となる第2章から順に読むことにした。

ちなみに、これも「本のつくり」で感心した部分なのだけど、同書では巻頭に各章の執筆分担がけっこう細かく明記されていてよかった。
共著の本だと時々、どの章を誰が書いているのか明示されていないことがあるのだけど、実際には複数人がドロドロ溶け合いながら執筆しているわけではなく、仮に編集段階で溶けているとしても中心的な担当者というのはいるはずで、ぼくの興味としては「どこの誰が責任をもってこれを書いたのか」を非常に知りたいので、どのページを読んでいても「なるほど、あの人がこういうことを考えた&書いたのか」と想像しながら読むことができてよかった。

スクラムとは何か? という、スクラムの詳しい内容については第2章から第5章までの4章でだいたい説明される。

第2章は「チーム内の役割分担」について。
第3章は「スクラムで何をやるのか」について。
第4章は「スクラムで何を作るのか」について。
そして第5章は、その過程で用いられる様々な技というか方法を具体的に紹介している。

これらをロールプレイング・ゲーム*1に言い換えると、
第2章は「キャラクターの職業」を紹介するような章なので、「戦士・魔法使い・僧侶」がいるよ、みたいな感じ。
第3章は、それらのキャラクターを使って何をやるのか。という意味では、「たたかう・まほうをかける・にげる」があるよ、みたいな感じか。
第4章は旅の目的を示すようなものなので、「レベルを上げる・コインをためる・敵を倒す」とか。
そして第5章はその道中で使用する技や道具の博覧会。魔法の種類(ギラ・ベホマパルプンテ)とか、武器や道具(薬草・鋼のつるぎ)にはこんなのがあるよ、みたいな感じ。

これらを最初の方にも書いたとおり、一定のテンプレートというか書法にそってぐるぐる反復するように説明していくので、読んでいて小気味よい。

そしてしみじみ思ったのだけど、いきなり第5章を読んだときに感じた「専門用語、多すぎだろ!」という感覚は徐々に薄れ、いやこれ、どっちかというとかなり極限までシンプル化されてるかも? みたいな感じになってくる。

たとえば第2章で紹介されるロール(各役割)なんて基本3種類だけである。
それは第3章も4章も同じで、どうもこのスクラムというのは、必要以上に選択肢を増やさないよう意識して作られているのではないかと感じられる。

原理・原則を最小限にすることによって、なるべく多様な現象に適応できるようにしている、といったところだろうか。

第6章から8章までの導入事例では、とくにDeNAのそれが面白いと感じた。

第9章から第11章までの「問題と対策」的なブロックでは第11章がとくに面白かった。あるあるの連続。

ぼくの仕事はソフトウェア開発ではなく、おもにCDブックの制作を編集者およびチームリーダー的な立場でやっているのだけど、それでも「うわー、これなあ……」みたいな「よくわかる!あるよねえ〜それ……」みたいに思えるエピソードが多く、その共感でき具合が楽しかった。

やっぱり人間同士、やっぱりコミュニケーション、難しいし面白い。だいたい似たようなところでつまづいて、それぞれそれなりの解決策なり、解決できなさなりがある。
いろんな人がいろんなことを考えていろんなものを作っているから、ひと筋縄ではいかない。そしてそういうのって、業種や場所が違ってもやっぱり似たり寄ったりなんだなあ、とじんわり実感した。

さてそのように、「具体的に何をやるのか」をざっくり把握した上でようやく第1章に戻り、ひとまず全体を読み終えて思ったのは、これだけバラエティにとんだ、かつ豊富な情報を詰め込んでいるにもかかわらず、本自体は非常にコンパクトというか、ページ数も少なくてそれがすごい、とまた本のつくりに関する感想になってしまう。

ページ数が少ない=軽いので、持ち運びもラクだし、一家に一台ならぬチームに1冊、いやチームメンバー1人につき1冊、共通の参考書として配ってもいいんじゃないかと思うほどのポータビリティ&内容の過不足のなさである。

また、ぼくのチームでスクラムを導入する予定は今のところないけれど、部分的に取り入れられる部分は少なくないと感じた。
たとえばぼくはプロジェクトの開始から完了に至るまでのタスクの洗い出しや、それぞれにかかる時間の見積りなどをけっこう細かく設定しているので、「バーンダウンチャート」なんて案外取り入れやすいかもしれない。

最後に、本書を読んでぼくが得た一番大きなものは何かと考えてみると、以前はこうした「スクラム」とか「アジャイル」みたいなものに対して、ある種の胡散臭さというか、「造語ばかり使いおって……」みたいな不信感・偏見を抱いていたのだけど、それが一気に払拭されたということではないか、と思っている。

実際にはこのスクラムでは、上記のように、そういった専門的な概念は必要最小限に絞られていて、もしそれでも残った専門用語を別の汎用的な一般名詞などに置き換えてしまったら、無用な誤解や混乱を招いてしまう可能性が出てくる。

スクラムはメンバー間のコミュニケーションを最適化するための取り組みでもあるから、使う言葉も最大限誤解の余地がないものでなければならず、その点からもある程度特殊な用語が必要とされるということについては理解できたと感じる。

一方で、ではそうしたスクラムに対するストレスというか、偏見みたいなものがなぜ発生してしまうのか? という点が新たな興味の対象にもなりつつあるのだが、これについてはまた機会をあらためて考えてみたい。

*1:単にドラクエだった。

最近のcarvo: pecoとchoをくっつけた

ブログで紹介するのはもう1年ぶりぐらいになるかな、と思ったけど直近だと去年の11月に書いていた。

note103.hateblo.jp

とはいえ、リポジトリのほうを更新するのは久しぶり。

このリポジトリ、README.mdもChangelogも前バージョンから書き換えておらず、純粋にlib以下のコードを「こんなに頑張りました!」と公開することだけが目的のような状況なので、リンクを張るかけっこう迷ったものの、まあ失うものもないし・・ということで。

一番大きな変更としては、記事タイトルでも示したように、pecoとchoという二つの優れたコマンドライツールを組み合わせて、選択系の作業をより直感的にできるようにしてみた。

手法としては、少し前に紹介したこちらとほぼ同じ。
note103.hateblo.jp

前回紹介したときのデモはこんな感じだったが、

https://dl.dropboxusercontent.com/u/7779513/carvo/2015-11-27_carvo.gif

その後こんな感じになり、

https://dl.dropboxusercontent.com/u/7779513/carvo/2016-05-27_carvo.gif

最近はこんなふう。(これでも最新ではないが)

https://dl.dropboxusercontent.com/u/7779513/carvo/2016-07-22.gif

ひとつ前のバージョンでは、出てくる選択肢の頭にアルファベット(f,g,h,k,l)を置いておいて、それをタイプして回答を選択する方式を取っていたけど、今回からはpecoやchoで直接それらを選択する。

最後のデモにあるように、簿記の勘定科目もコンテンツとして取り入れている。(ただし、上記リポジトリにはそのカードは入れてない。入れ忘れた)

なお、最初のデモにある「英単語の頭数文字をヒントとして出し、それを見て回答(英単語)を入力する」という回答方式もやはり面白いので、最新版ではその方式も選択できるようにしている。これについては後日また紹介したい。

英語や簿記の勉強じたいは進んでやろうというものでもないのだけど、こうしてプログラミングの素材として取り入れると、その動作テストの流れで必然的にそれらを目にすることになるので、まったくやらないよりはマシという感じになる。

ひとまずそのようにだましだまし、プログラミング&英語&簿記の勉強をしつつ、いずれ何かのはずみで集中できそうになったら流れに乗ってきちんと勉強したいものだと考えている。

21世紀の文字起こし

editing

気づき

少し前にこのようなことに気がついた。

「いずれそうなるだろう」とは思っていたが「まだしばらく先のことだろう」とも思っていた現実が、想像していたよりずっと間近に迫っていた、ということに驚いた。

さらに言えば、このときはiPhoneに向かって喋ったらみるみるテキスト化されていくので「なんだこれ……!」と衝撃を受けたのだったが、実際にはその後に起こったことのほうがすごくて、Googleドキュメントの音声入力機能と、SoundflowerというMacのアプリケーションを組み合わせたところ、もはやわざわざ喋らなくてもMacで再生した音声ファイルがそのままGoogleドキュメント上でテキスト化されてしまい、ひっくり返った。

https://dl.dropboxusercontent.com/u/7779513/transcript/talk3.gif

これは今年の初めに吉祥寺.pmで発表したときの録音を、後述の方法で読み込ませているところ。

日本語だとちょっともっさりした感じだが、英語だとこうなる。

https://dl.dropboxusercontent.com/u/7779513/transcript/reading.gif

むちゃくちゃ速い。よく見ると、ところどころで誤認識をしているのだけど、手で打ちこんだ場合との違いを考えれば充分許容ではないかと感じる。

また日本語にしても、丁寧かつ明瞭に発声した音声ファイルであれば、上に示した日本語版の動画より速く、よどみなくテキスト化されていく。

そもそも文字起こしとは

さてしかし、ではそれがどれだけ実用的なのかというと、まだ業務の現場を劇的に変革するほどではないとも感じる。

冒頭のツイートをしたときには「未来はすでに来ていた! 今この瞬間から、文字起こしのやり方を変えなければ!」ぐらいに思ったが、それは半分正しく半分期待しすぎだった。

どういうことかと言うと、まずそもそも文字起こしという作業は、以下のような工程で構成されている。(あくまでぼく個人の場合)

  1. 音声を聴きながら、抜け漏れやタイプミス込みでよいので、一旦最後まで音を止めずに起こしていく。
  2. 2周め以降は一時停止や巻き戻しの回数を増やしながら、ひとまずすべての音声をテキスト化する。
  3. 2の仕上がりには不要な語句や倒置が多いので、文章として読みやすくなるよう修正していく。

文章を仕上げるためには、さらに

4. 全体の構成を工夫して読み物として仕上げる。

という工程が必須になるが、それはもう「文字起こし」ではなく「編集」である。*1
よって、ぼくの考える「文字起こし」は上記の3まで。

※ちなみに、3と4の違いがわかりづらいかもしれないが、3の目的は「人間が読みやすい状態にすること」で、4の目的はそれを「良いもの」にすることである。

その1〜3のうち、機械が担当できる作業は人間の判断が不要な1と2までだが、今回話題にしている音声入力技術にできることは、「1の精度をちょっと良くしたもの」であり、2はできない。

なぜ2が「できない」のかというと、2をやるためにはすでにテキスト化された部分のうちどこが抜け漏れなのか、あるいは間違っているのか、という判定や検討が必要で、しかしここで対象としている機械にはその機能がないからである。

好意的に、期待を込めて言い換えれば、「1」の精度が高くなれば「2」は不要になる。つまり現状の先にあるのは「1+2」を機械が終わらせてくれることだが、現時点ではせいぜい「1プラスアルファ」しかできない、ということ。

加えて、その「1プラスアルファ」を機械にさせるために必要な準備もけっして少なくはない。
よって、その導入コストを許容範囲内の投資と捉えるか、「そこまで面倒なら今は手を出さないよ」と捉えるかによって対応は異なるだろう。

ではその「「1プラスアルファ」をさせるために必要なこと」とは何かというと、以下のようなことである。

  1. 素材の音声を聞きながら、明瞭な調子で新たな録音を行う。
  2. それをGoogleドキュメントに読ませる間、読み込みが途中で止まってしまったら(数秒〜数十秒に一度止まる)すぐに再起動させられるよう、つきっきりで世話をする。

これをやれば、通常の文字起こしによる上記工程の1と同等か、それよりちょっとマシ、というぐらいのものができる。

また、導入を検討する際の主な要素には、そうした「精度」の他に、「かかる時間」や「労力」もある。

かかる時間に関しては、たとえば60分の音声ファイルを扱う場合、通常の工程であれば60分強で済むことになるが(あくまで1の作業のみ)、音声入力の工程だと「再録音」と「音声を読み込ませる」工程が必要なため、少なくとも素材音声の倍、あるいは2.5倍〜3倍程度の時間がかかるかもしれない。

一方、「労力」に関して言うと、音声入力の工程における「再録音」は「音を聴きながら音を発声する」という音声同士の変換行為であり、これはその次の「つきっきりで再読み込みさせる」という作業にも言えることだが、頭や体への負荷が少ない単純作業である。

これが通常の文字起こしだと、「音を聞きながら文字を書いていく」という「音(聴覚)→文字(視覚)」の変換作業を行うため、そうした「異なる次元の感覚を駆動する」ことが独特の疲労につながる。

たとえてみると、音声入力における各工程は「一つのことを上手くやる」というUNIX的な行為であり、通常の文字起こしはオーケストラの指揮者がやるような、様々な種類の異なる作業を並行して進めるマルチタスク的行為である。

さらに言えば、音声入力ではタイピングが不要である。よって、体への負担という意味では比較の余地もなく音声入力のほうがラクである。

そもそも文字起こしとは(2)

ではそのようなメリット・デメリットを踏まえ、現時点でぼくはどう結論を出しているかというと、可能なかぎり機械の力を借りるべきだと考えている。

もしかすると、トータルのスピードはまだ、すべて人力でやったほうが速いかもしれない。しかし、上述のとおり人力による文字起こしは非常に疲れるため、それをやれば他のことができなくなるか、同等のなんらかの影響が生じることになる。

そしてそもそも、というかこれが一番大事なことなのだが、文字起こしは人間がやるような仕事ではない。
人間がやるべきことはその後の文章構成、つまり元々の話された内容を、テキスト上でどのように再構成するか検討・判断する作業であって、その前の段階まではさほど重要なものではない。*2 *3

そしてそのように、「さほど重要ではない」にもかかわらず、現在通常の工程として行われる文字起こしという作業はなかなか過酷で、見返りも少ない。

朝9時からスタートして、その日の18時までやればそれなりの進捗は出る。2時間程度の素材なら、その調子で3日もやれば充分終わるだろう。
しかし、その代償は大きい。やったことのある人にはわかるだろうが、非常に多くのものを捧げて、それはようやく仕上がる。

だからぼくとしては、もうそういうことはなるべく人間がせずに済むようになってほしいと考えている。
現時点では、音声入力のメリットはまだわずかなもので、むしろ後述するような導入コストを考慮すれば、人によってはデメリットのほうが大きくすらあるかもしれないが、いずれは比べるまでもないほどメリットのほうが大きくなるだろう。

音声入力による文字起こしの実践法(Mac

以下、今回試みた具体的な音声入力の作業工程を示しておく。

先に概要を示すと、次のような工程をたどる。

  • 1. 素材音声の再録音
    • 大元の音声ファイルを読み込ませても精度が低いため、読み取り用に同じ内容を自分で喋り、それを録音する。
  • 2. Soundflowerの準備
    • Soundflowerというソフトウェアを使うと、事前に録音しておいた音声ファイルをテキスト化させることができる。その導入手順。
  • 3. Mac内部で再生+聞き取り
    • 音声入力をするまで。
  • 4. 音声ファイルが終わるまで再読み込みなどのケア
    • 数秒〜数十秒ごとに音声入力が止まってしまうので、その対応について。

なお、この手順はすべてぼく個人の環境に依存しているので、同様のことができない人はそれぞれの環境に置き換え・読み替えてほしい。

1. 素材音声の再録音

まずはGoogleドキュメントに読み込ませるための音声ファイルを作成(再録音)する。

「機械の力を借りるべき」などと言うわりにずいぶんアナログな工程だと自分でも思うが、食洗機に入れる前に軽く油汚れなどを落としておくようなものだと思えばよい。
マシンをより効率的に活用するためのハックとも言える。

後述のように、とくに専用ソフトなどは使わずに行うことも可能だが、ぼくの場合はMacのExpress Scribeという文字起こし用のソフトで、通常の80%程度に遅く設定した上で元の音声ファイルを再生し、それをイヤホンで聴きながら、手に持ったICレコーダーへ発声して録音していく。

通常の再生速度であればこの作業自体が早く終わるという利点があるが、聞き取れずに後戻りしなければならなくなる可能性も高まること、また逆に、遅くしすぎると作業自体がなかなか終わらなくなるので、総合的に見て80%程度が最適かと思っている。

と同時に、環境によってはわざわざ再生速度を調整しなくてもよいとは思う。
たとえば、iPhoneからイヤホンで対象の音源を聴きながら、手元のICレコーダーに喋って録音していくような方法であれば、コンピューターに縛られず作業できるのでそれなりのメリットもあるし、実際そのように試したがけっこう快適だった。

聞き落としによる後戻りの可能性などを考慮しない場合には、それもありだと思う。

2. Soundflowerの準備

Googleドキュメントに音声ファイルを読み込ませるために、Soundflower というソフトウェアを使う。

このソフトは本来、Macから流れる音声をそのまま(スピーカーを通さずにマシン内で)録音するためのものだが、今回の用途にも適している。

導入方法を検索すると、新旧様々な紹介記事が出てくるのでかえってわかりづらいのだけど、最近のヴァージョンを扱った記事としては以下のまとめが詳しかった。多謝。

インストールが完了したら、Macの環境設定/サウンドか、Optionを押しながらメニューバーのスピーカーマークを押して、以下のように設定する。

f:id:note103:20160710040842p:plain

入出力ともにSoundflowerにするのがポイント。なお、2chと64chの違いは理解していないが、2chでとくに問題ないのでそのようにしている。

3. Mac内部で再生+聞き取り

Googleドキュメントで、記録するための新規ファイルを作成する。

※この際、ブラウザはGoogle Chromeを使用する。Firefoxでも試したのだけど、下記の「ツール/音声入力」という項目名が、確認はできるものの選択できない状態になっていた。その他のブラウザは未確認。

f:id:note103:20160710125926p:plain

ドキュメントを作成したら、ファイル内のメニューバーから、ツール/音声入力の順で選択。

f:id:note103:20160710125940p:plain

マイクのボタンが出てくる。

f:id:note103:20160710125948p:plain

ボタンをクリックすると、赤くなって入力待機状態になる。

f:id:note103:20160710125958p:plain

このとき、すでに音声が流れていれば、自動的に入力が始まる。

f:id:note103:20160710130014p:plain

同じボタンを押すか、一定時間無音が続くと、自動的に録音は止まる。

なお、録音中に別のアプリケーションへ移っても、録音は止まってしまう。
よって、録音を開始してから音声を再生したい場合は、アプリケーションを切り替えなくてもキーボードから再生できるように準備しておくとよい。

また、上記2の設定が済んでいれば、再生しても音が外には出てこない。

音が聞こえないので、再生されているのか少し不安になるが、プレイヤーの表示を見れば秒数が増えていくのを認識できるので、それも目に入るようウィンドウを並べておくとよいだろう。(というか、ぼくはそうしているということ)

4. 音声ファイルが終わるまで再読み込みなどのケア

前述のように、入力は音声ファイルが止まるまで続くわけではなく、途中で止まる。いわばフリーズしたような状態になる。
調子が良ければ1分以上入力され続けることもあるが、平均的には40秒程度かもしれない。

困るのは、入力がフリーズしてもそれが視覚的にわからないことだ。
マイクは赤く待機状態を示したままなので、しばらくすれば入力が再開されるのかな、と思うが、止まったままのこともあればやっぱり動き出す、ということもある。

よって2秒程度入力が止まったら、もうフリーズしたとみなして再起動する。
具体的には、マイクボタンを押して一度入力機能をストップし、もう一度押して再開させる。すると、また入力が始まる。

※上のスクリーンショットでも確認できるが、再読み込みは「コマンド+シフト+S」のショートカットキーでも可能である。というかぼくはそれを使っている。

そしてこの再読み込み作業をファイルが終わるまでくり返す。

ちなみに、音声ファイルの音質が粗かったり、喋るスピードが速かったりすると頻繁にフリーズするという印象がある。

その意味でも、音質を最大限改善するために録音し直しておくことは有効だと考えているし、逆に言うと、この聞き取り能力が向上すれば、再録音の必要はなくなるかもしれない。

また、同じくフリーズの頻度を下げる目的で、再録音の際に使用したExpress Scribeをここでも使い、再生速度を少し遅くした上で読み込ませている。

まとめ 〜そしてtextlint編へ〜

音声入力による文字起こしの工程は以上。

ちなみに、ここまでの話ではとくに触れなかったが、冒頭の動画で示したように英語の音声は再録音をしなくても*4かなりのスピードでテキスト化されていくので、音質さえよければその工程は省略できるだろう。

しかし日本語で語られた音声ファイルの場合は、その再録音や最後の再読み込み作業は避けがたい工程かなと思っている。(いずれは機能の向上にしたがって不要になるかもしれないし、それを期待するけれど)

ところで、じつはこの話題はここで終わりではなくて、前半で挙げた文字起こしの3工程のうち、

  1. 音声を聴きながら、抜け漏れやタイプミス込みでよいので、一旦最後まで音を止めずに起こしていく。
  2. 2周め以降は一時停止や巻き戻しの回数を増やしながら、ひとまずすべての音声をテキスト化する。
  3. 2の仕上がりには不要な語句や倒置が多いので、文章として読みやすくなるよう修正していく。

ここまでに紹介した音声入力が担うのは1だが、続く2と3の作業を軽減・サポートする技術として、このブログでも何度か取り上げた「textlint」がある。

ぼくにとっての未来の文字起こしは、そのtextlintを音声入力と組み合わせることによって成立するのだけど、すでにだいぶ長くなったので、この記事では音声入力についてまでとする。

textlintを効率的な文字起こしに際してどう使うか、という話はまた機会ができたときに。

*1:あくまで便宜的な腑分けだが。

*2:と言いつつ、実際にはそうした構成作業にしてもいずれは機械がやってくれるかもしれないとは思っているのだけど。人間に残されるのは、そうして出来たものをユーザーとして「楽しむ」ことだけになるかもしれないし、それならそれで、まあ構わない。

*3:さらに注釈を重ねると、じつはぼくとしても重要な原稿は文字起こしから自分で担当してしまったほうがいいと考えている。作業としてはヘビーだが、それによって元の内容を理解しやすくなるし、何より結局その後の編集作業を自分でやるのであれば、初めから自分の方針に沿って作られた文字起こしを元にしたほうが余計な修正が生じずラクだからである。

*4:むしろ自分で再録音したら発音が不正確で精度が落ちそうだ。というか落ちるだろう。

Vim の地味だけどよく使う設定

vim mark tips

普段 Vim を使っていて、つくづく「このマッピング便利だな〜」と思うものをご紹介します。

空行・スペース処理

1行ごとに空行を入れる

このような設定で。
※以下、「<Leader>al」などのマッピングは説明用の一例です。

nnoremap <Leader>al  :%s/$/\r/gc<CR>
vnoremap <Leader>al  :s/$/\r/gc<CR>

f:id:note103:20160706002100g:plain

選択するとその範囲だけ、選択しなければバッファ全体を対象として、1行おきに空行を入れていきます。

空行をカットする

上記の逆。

nnoremap <Leader>dl  :%s/^$\n//gc<CR>
vnoremap <Leader>dl  :s/^$\n//gc<CR>

f:id:note103:20160706010907g:plain

複数行でも一気に詰めてくれます。

行内のスペースをカットする

nnoremap <Leader>db  :%s/\s\+//gc<CR>
vnoremap <Leader>db  :s/\s\+//gc<CR>

f:id:note103:20160706002336g:plain

まれに使います。

全角英数字を半角にする

普段はあまり遭遇しないものの、それだけにたまにぶつかると対応コスト・負担が大きい案件。

マッピングを設定しておいて数秒で解決するとストレスが最小限で収まります。

nnoremap <Leader>zh :HzjaConvert han_eisu
vnoremap <Leader>zh :HzjaConvert han_eisu

f:id:note103:20160706002409g:plain

これは選択範囲のみ有効なので(選択しなければカーソル行のみ)、バッファ全体に適用したい場合は全体を選択してから実行します。

f:id:note103:20160706002424g:plain

ちなみに、ほとんどやりませんが逆(半角→全角)も一応設定しています。

nnoremap <Leader>hz :HzjaConvert zen_eisu
vnoremap <Leader>hz :HzjaConvert zen_eisu

全角<=>半角の変換については以下が大変詳しい&わかりやすいです。
nanasi.jp

Markdown記法のリスト化

メモや議事録、週報など、Markdown記法でドキュメントを作成する機会が多いので、もしかすると現在一番使っているかもしれない地味設定。

直下の行頭にハイフン+半角スペースを入れる。

nnoremap <Leader>rh o<ESC>I- 

リスト行の直下に同じくハイフン+半角スペースを入れる。

nnoremap <Leader>ri A<CR>

1段深くインデントしてからハイフン+半角スペースを入れる。

nnoremap <Leader>rt A<CR><ESC>I<TAB><ESC>A 

f:id:note103:20160706002545g:plain

なお、Markdown まわりのサポート・プラグインとして以下を利用しているので、

上記はそれを前提としたマッピングです。

プラグインに関しては以下でも少し触れました。
note103.hateblo.jp

また、ぼくが主に使うファイル形式はじつは Markdown ファイル(.mdなど)よりもテキストファイル(.txt)なので、テキストファイルでも Markdown として振る舞うよう、「~/.vim/filetype.vim」の中に以下のような記述を入れています。

if exists("did_load_filetypes")
  finish
endif

augroup filetypedetect
  au BufRead,BufNewFile *.{md,mdown,mkd,mkdn,markdown,mdwn,txt,text,html}   set filetype=markdown
augroup END

この辺の設定については vimdoc の以下あたりが詳しそうです。

日時をすぐに出す

これも日報、週報的な記録を取る際に重宝しています。ほぼ毎日叩いているかも。

inoremap <expr> ,df strftime('%Y-%m-%d %H:%M')
inoremap <expr> ,dd strftime('%Y-%m-%d')
inoremap <expr> ,dt strftime('%H:%M')

曜日もすぐに出す

let weeks = [ "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" ]
let wday = strftime("%w")
inoremap <expr> ,ds strftime('%Y-%m-%d ').weeks[wday]

f:id:note103:20160706002749g:plain

便利。曜日の部分以外は、以下のムックから学びました。

開発ツール徹底攻略 (WEB+DB PRESS plus)

開発ツール徹底攻略 (WEB+DB PRESS plus)

曜日の部分はいろいろ検索して作りました。先人に多謝。

.vimrc をすぐ操作する

上記のムックにも近いことが書かれていましたが、まず簡単に vimrc を操作できるよう、現在使っているウィンドウに vimrc を出すマッピング

nnoremap <silent> <Leader>. :<C-u>sp ~/.vimrc<CR>
nnoremap <silent> <Leader><Leader>. :<C-u>edit ~/.vimrc<CR>

Leader を1回叩いたら下方に画面分割で、2回叩いたらウィンドウ全体が vimrc ファイルになります。

そうしてチャチャッと書き換えたら、すぐに再読み込みできるように以下も設定。

nnoremap <Leader><C-e> :source ~/.vimrc<CR>

一時的なゴミ箱ファイルをすぐに出す

画面分割ワザの応用ですが、普段テキストの編集作業をしていると、「ん〜、この辺りの説明、冗長だからバッサリカットしてもいいんじゃないかな……でももしかしたらやっぱり必要かもしれないから、一旦別の場所に避難させておきたいな……」と思うことが少なくありません。

そのようなときに、一時的に不要な文章を保管しておけるファイルを作っておいて、それをいつでも呼び出せるようにする設定。

nnoremap <Leader><C-t> :<C-u>sp /path/to/trash.txt<CR>

ここでは「trash.txt」というファイル名にしていますが、それがウィンドウ下方にパッと出てくるので、その中に不要な文章をカット&ペーストで移動。(大抵は最下行)

f:id:note103:20160706183848g:plain

一方、こうした部分的な保存ではなく、バッファ全体をとりあえず保存しておきたい、という場合もあります。
そのようなときは、以下の方法を使います。

今見ているバッファを現在時刻のファイル名で保存する

:w 版

function! s:wsave()
  execute ":w /path/to/".strftime('%Y-%m-%d-%H-%M-%S').".txt"
endfunction
nnoremap <silent> <Leader><Leader>w :<C-u>call <SID>wsave()<CR>

:f 版

function! s:fsave()
  execute ":f /path/to/".strftime('%Y-%m-%d-%H-%M-%S').".txt"
endfunction
nnoremap <silent> <Leader><Leader>f :<C-u>call <SID>fsave()<CR>

あちこち調べて、関数で設定してみました。

なお、最近の Vim では undo オプションが大変強力で、ぼくも以下のように設定していますが、

if v:version >= 703
  set undofile
  set undodir=~/.vim/undo
endif

そして実際、これによってかなり以前の状態までさかのぼれますが、それでも時々期待の動作をしないこともあるので、「今見ているバッファ、万一のために別名で保存しておきたい……!」というときには上の保存コマンドをパパッと叩いておきます。

実際にはそのように保存したファイルを使うことはほぼありませんが、無用な心配事が減るので、実用上のメリットというより精神的なメリットがある設定です。

簡単に連番を振る

最後に、これは vimrc の設定ではありませんが、よく使うのでシェアさせて頂きます。
何気に使う場面が多い&むちゃくちゃ便利。

f:id:note103:20160706003059g:plain

情報源は以下の @thinca さんの回答より。
ja.stackoverflow.com

Vim 7.4.765 以降であれば、対象をビジュアルモードで選択して g<C-a> をすると連番が生成されます。

知らなかった〜……。

まだ他にもいろいろありそうな気はしますが、ひとまず以上です。

OCamlのインタプリタで日本語の文字を扱う

ocaml

あれはおそらく2013年、Perl入学式に初めて参加する直前頃だったと思うのだけど、以下の本を購入し、

プログラミングの基礎 (Computer Science Library)

プログラミングの基礎 (Computer Science Library)

そこに示されるまま、OCamlインタプリタで日本語を出力するためにターミナルの文字コードEUCに設定したら、その後に行ったPerl入学式で出力が文字化けしてしまい、「どうしてですかね……?」と聞いたら「端末の設定が問題なんじゃないかな!?」とサポーターさんから指摘され*1、「ああ、あのOCamlの設定でやったやつか……」と、おかげで少なからぬ時間を費やしてしまったことがあまりよくない印象として残ってしまい、その後同書を開くことはほとんどなかった。

しかし最近、以下の記事を読んで、

これといった目的もなくプログラミングを始めたいなら、静的型付き言語で始めるほうがいろいろ実りがあると思います。

とのこと。

なるほど、そういえばOCamlの本、以前買ったのがあったな、ちょっと読み直してみよう。と思って、その後なんだかんだで3年間趣味プログラミングを続けてきた今の目で読んでみると、読みやすいし、面白そうだし、期待できそう。
さすが様々な機会で良書として推薦されるだけのことはある。

……しかし、件の文字コード問題がなあ、と思ってその部分をやってみると、やはり普段使っているUTF-8の設定だと文字化けする。指示のとおり端末の方でEUCに設定してしまうことも可能だけど、他のコードを扱うときのことを考えると受け入れがたい。

インタプリタにこだわらず、ファイルにコードを保存して実行すれば問題ないのだけど、同書の構成としては前半しばらくの間はインタプリタ操作を前提に進んでいくので、できればそれに沿って読み進めたい……などとジレンマ的な状況に陥りつつ、しかしこんなメジャーな(と言っていいだろう)言語でこんなしょうもないことが放置されているはずがない、と思っていろいろ検索してみたら、ようやくわかった。端末を直接設定する以外の方法で、比較的手軽に文字化けを回避する方法が。

Toplevel (REPL) での文字化けを防ぐ

内部的には壊れているわけではない EUCUTF-8 の文字列ですが、出力が狂ってしまうのは不便です。 これは OCaml の string プリンタを変更することで回避することができます:

EUC もしくは UTF-8 環境:
# let print_non_escaped_string ppf = Format.fprintf ppf "\"%s\"";;
val print_non_escaped_string : Format.formatter -> string -> unit = <fun>
# #install_printer print_non_escaped_string;;
# "こんにちは";;
- : string = "こんにちは"

ここでは 文字列をエスケープせずに標準出力に出力する関数、 print_non_escaped_string を定義し、 それを #install_printer ディレクティヴによって string 型のプリンタに指定しています。 これにより文字列を ISO-8859-1 とみなしたエスケープが行なわれなくなります。

Toplevel で日本語を含んだ文字列などを多用する場合は、毎回この内容を打ち込むのをさけるために、 次の内容を OCaml toplevel が起動時に実行するファイルである .ocamlinit に 書き込んでおくとよいでしょう:

let print_non_escaped_string ppf = Format.fprintf ppf "\"%s\"";;
#install_printer print_non_escaped_string;;

ということで、最後に示されている2行を .vimrcや.bashrc と同様に、.ocamlinitとしてホームディレクトリに置いたら、インタプリタでも日本語が普通に出力されるようになった。

OCamlに関する日本語で書かれた情報じたいはけっして少なくないのだけど、本件についてはけっこう限られていて、なかなか大変だった。
そのような中、上記のリポジトリのほか、以下でも同様の言及があり、参考になりました。ありがとうございます。

*1:おぼろげな記憶だけど、それはたしかYAPC::Asiaのイベント内で開催されたPerl入学式で、このときに相手をしてくれたのはウズラさんだった気がする。

C言語の航海日誌(5)〜文字列をポインタで渡す〜

clang

前回の知見と繋がりながらもちょっとズレる発見があったのでメモします。

note103.hateblo.jp

まず前回の復習をしておくと、int型の数値をこんなふうにポインタで渡す、ということをやった場合。

#include <stdio.h>

void foo(int *c, int *d)
{
    printf("*c: %d\n", *c);
    printf(" c: %p\n",  c);
    printf("*d: %d\n", *d);
    printf(" d: %p\n",  d);
}
int main(void)
{
    int a = 33;
    int b = 55;
    printf(" a: %d\n",  a);
    printf("&a: %p\n", &a);
    printf(" b: %d\n",  b);
    printf("&b: %p\n", &b);

    printf("\n");

    foo(&a, &b);

    return 0;
}

実行。

 a: 33
&a: 0x7fff5377a60c
 b: 55
&b: 0x7fff5377a608

*c: 33
 c: 0x7fff5377a60c
*d: 55
 d: 0x7fff5377a608

こんな感じで、メイン関数からはアドレス(&a, &b)を投げているのに、受け取る側のfoo関数では数値(*c, *d)で受け取っているので、直感的じゃないなあ・・という結論だったのですが。

同様の感覚で文字列を渡そうとしたらハマりました。
文字列で同様のことをしようと思ったら、こうなるようです。

#include <stdio.h>

void foo(char *c, char *d)
{
    printf(" c: %s\n", c);
    printf(" c: %p\n", c);
    printf(" d: %s\n", d);
    printf(" d: %p\n", d);
}
int main(void)
{
    char a[] = "apple";
    char b[] = "orange";
    printf(" a: %s\n",  a);
    printf("&a: %p\n", &a);
    printf(" b: %s\n",  b);
    printf("&b: %p\n", &b);

    printf("\n");

    foo(a, b);

    return 0;
}

実行

 a: apple
&a: 0x7fff59a3360a
 b: orange
&b: 0x7fff59a33603

 c: apple
 c: 0x7fff59a3360a
 d: orange
 d: 0x7fff59a33603

ということで、数値の場合は「*c」で受け取ったものが値(「33」)で、「c」はアドレス(「0x7fff5377a60c」)でしたが、今回は値(「apple」)もアドレス(「0x7fff59a3360a」)も「c」でした。

じゃあ、文字列を渡したときの「*c」には何が入ってるの? と思って見てみると、

#include <stdio.h>

void foo(char *c)
{
    printf("*c: %c\n", *c);
}
int main(void)
{
    char a[] = "apple";

    foo(a);

    return 0;
}

実行

*c: a

ということで、「apple」の最初の1文字が入っていました。

これはCにおける文字列がじつはchar型の配列で、その先頭要素が出てきているということだと思いますが、ともあれ問題は、「文字列を参照渡しした場合には、数値のように * が付いた変数に値が入っているわけではなく、* を取ったほうの変数に入っている」ということで、まあそういうものだと覚えればいい気もしますが、あとで回収すべき宿題が増えた感じでもあります。