Vimと日本語編集（2）: 修正前後の原稿の差分を一瞬でチェックする

Vimと日本語編集シリーズ第2回。
前回はこちら。
note103.hateblo.jp

けっこうニッチな内容だったと思うが、今回はもう少し使用頻度＆汎用性が高いかもしれない。

前提・状況設定

複数人で利用・共有するドキュメントがあるとして、それをまず自分が書いたとしよう。

大体内容がまとまったのでデータを他のメンバーに渡し、「気になるところがあったら適当に手を入れといて」なんて言っておいたら、しばらくして修正版が届いたとしよう。

でもパッと見たところ、どこが修正されたのかわからない。

たとえば、これが修正前。*1

そして修正後。

そのようなときに、どうするか。

よくある解決策・その何が問題か

一番容易な選択肢としては、「じっくり見る」。
まあ、数百字程度ならありかもしれない。
とはいえ、人間に向いた作業かは微妙。避けられるなら、あまりやりたくない。

次に容易な選択肢としては、「どこ直したの？」と相手に聞く。
でも面倒くさい。すぐに返答があるとは限らないし、本人だからといって正確な差分を示せる保証もない。（だから最初の選択肢が「とりあえずじっくり見る」になってしまう）

これがエンジニア同士なら、最初からそのドキュメントはGit管理されていて、すべての差分を簡単にチェックできるようになっているかもしれない。
さらにそれがGitHubやBitbucketで共有されているなら、その視認性はさらに高まるだろう。

しかし仮に自分がエンジニアだったとしても、相手がGitを使えない人だったり、ドキュメントの性質としてGit管理の必要がないテンポラリなものだから、といった理由で差分管理が成されていなかったらどうだろう？

僕は普段の作業でGitを使っているけど、それでも既存のリポジトリには入っていない、突発的で一時的なちょっとしたドキュメントの差分を見たい、という状況にちょくちょく陥る。
そのようなとき、そのちょっとした差分を見るためだけにわざわざリポジトリを作るとか、GitHubなどにpushするというのも面倒である。

解決策

というわけで、やっているのは次のこと。

1. 白紙のバッファに差分を見たいドキュメントの「修正前」の文章をコピペ。

2. 新規で無名の分割バッファを出して、「修正後」の文章をコピペ。
この際、新規バッファを水平分割で出すなら

:new

タテ分割なら

:vnew

とすればよい。

3. おもむろに以下を打ち込む。

:windo diffthis

差分が出る。

左が修正前。右が修正後。
変更が生じた行だけでなく、文字単位で出てくるのがよい。

差分表示を消すには以下。

:windo diffoff

上記についてはすべてVimcastsのこちらから学んだ。
Comparing buffers with vimdiff

目的の内容以外にも、その過程で次々と小ネタが繰り出されるので目が離せない。すごいコンテンツ力……。

なお、上記のexコマンドを毎回打つのは面倒なので、このようなマッピングを入れている。

nnoremap <silent> <Leader>dt :<C-u>windo diffthis<CR>
nnoremap <silent> <Leader>do :<C-u>windo diffoff<CR>

上では二つのバッファをどちらも無名ファイルにしたが、無名である必要はとくにない。
既存のファイルを二つ並べるのでも、片方だけ無名にするのでもよい。（上述のVimcastsでは片方だけ無名だった）

別解

fugitive.vim / Gdiff

もしリポジトリ管理しているファイルで同様のことをやるなら、fugitive.vimの「:Gdiff」も便利だと思う。
GitHub - tpope/vim-fugitive: fugitive.vim: a Git wrapper so awesome, it should be illegal

というか、上で紹介した方法を知るまではずっとこれでやってた。

fugitive.vimの使い方に関しては、以下の記事がとてもわかりやすい。
blog.yuku-t.com
cohama.hateblo.jp

diffsplit, VDSplit

また、今回の記事を書くためにいろいろ確認するうちにたまたま辿りついたのだけど、以下で紹介されている「:diffsplit」や「:VDSplit」でも同様のことをできるみたい。（後者はKaoriya版限定）
nanasi.jp

用途によってどれがより適している、といったこともありそうだが、そこまでは把握できていない。

まとめ

GitHubなどで色付きの、人に優しいdiffを見慣れていると、差分を知らされず変更後のドキュメントだけを渡されたときにある種の禁断症状に陥ってしまいそうな気になる。

差分を目視で確認するのも、口頭で教えてもらうのも、メールやチャットのテキストで説明を聞くのも、すべて「異様に長い箸で数メートル先の豆をつまむ」ようなもどかしさを感じる。

パパッとコマンドを打って、どの行のどの文字が変更されたのか。そして（もしかしたら変更箇所以上に）「どこが変更されていないのか」といったことがわかると、こみ上げかかったストレスが急速に収まってよい。

*1:前回に続き夏目漱石「草枕」を使用した。 http://www.aozora.gr.jp/cards/000148/files/776_14941.html

Vimと日本語編集: 長文の中の見出しだけを抽出する

以前にすでに書いたような気がしていたが、ブログ内を検索しても出てこなかったので書いておく。
最近とくによくやる作業。

課題と前提

たとえば以下のような文書があったとする。

# 見出し1
本文
# 見出し2
本文
# 見出し3
本文
（略）
# 見出し100
本文

「本文」とあるところは何十行も続いているとして、この中から「見出し」の行だけを集めたいという場合、手動でポチポチ拾っていくのはなかなかつらいものがある。

というか、そういう手動対応はミスの介在する余地も大きいし、肉体だけでなくメンタル面でも消耗の度合いが大きいので、やらずに済めばその方がよい。

では、これをみんな大好きVimで解決するにはどうすればいいかというと、『実践Vim』の「TIP99」を使えばいい。

実践Vim 思考のスピードで編集しよう!

※同書は上記のAmazonからだと単行本またはKindleで購入できるが、達人出版会に行けばPDF+EPUBの形式でも購入できる。（たしかDRMナシ）
実践Vim【委託】 - 達人出版会
※ぼくはKoRoNさんから献本して頂いた単行本の他、なぜかKindle版も達人出版会配布のPDF+EPUB版も買ってしまった。どんだけ……。

実践: 最小限の工程

まずは、任意のレジスタをクリアする。

『実践Vim』の例ではレジスタaを使うので「qaq」と打つように言っているが、ぼくはこの用途のときは毎回何も考えずに済むよう「qqq」と打ってレジスタqを空けている。

その上で、コマンドラインモードで以下を入力。

:g /\v^# 見出し\d+/yank Q

これでレジスタqに「# 見出し（＋整数）」の行が溜まっている。

次に、溜めたそれを吐き出す。
具体的には、同バッファ内で（または分割ウィンドウで別バッファを出して）以下を打鍵する。

"qp

結果。

# 見出し1
# 見出し2
# 見出し3
# 見出し100

上のサンプルを対象に実行するとこの4行が出てくるが、ほんとに100個の見出しがあれば100行になる。

工程上のポイントとしては、exコマンドの最後で小文字の「q」ではなく大文字の「Q」を入れること。
これは大文字にすることによりマッチした行がレジスタへ追記されていくからで、小文字にするとどんどん上書きされて最後にマッチしたものしか残らない。

また、レジスタqに入れているので吐き出すときは「"qp」だが、レジスタaとかbとかならそれぞれ「"ap」とか「"bp」になる。

また、この方法を使い始めた当初はよく最初のレジスタクリアをし忘れて、以前にコピーした内容も一緒に出てきてその都度けっこう驚いた。
致命的なミスではないが、毎回クリアしてから収集するのを忘れないように。

応用: 夏目漱石「草枕」より

上ではけっこう厳密な正規表現を書いて対象を指定しているが、結局は正規表現で拾っているだけなので、指定をゆるくすればそれに応じた結果（対象語句を含む行）が入ってくる。

出典であるところの『実践Vim』では「TODOアイテムを収集する」というテーマになっていて、コード内でコメントアウトして書かれたTODOの行を集めるという前提で、以下のコマンドが示されている。

:g /TODO/yank A

よってたとえば、いつもお世話になっています夏目漱石先生の「草枕」より、

夏目漱石 草枕

1センテンス1行に分解した上で、「夢」を含む行だけを収集するならこんな感じになる。

:g /夢/yank Q

結果。

雨が動くのか、木が動くのか、夢が動くのか、何となく不思議な心持ちだ。
眠りながら、夢に隣りの臼の音に誘われるような心持ちである。
やがて長閑のどかな馬子唄まごうたが、春に更ふけた空山一路くうざんいちろの夢を破る。
夢に。
妙に雅俗混淆がぞくこんこうな夢を見たものだと思った。
昔し宋そうの大慧禅師だいえぜんじと云う人は、悟道の後のち、何事も意のごとくに出来ん事はないが、ただ夢の中では俗念が出て困ると、長い間これを苦にされたそうだが、なるほどもっともだ。
文芸を性命せいめいにするものは今少しうつくしい夢を見なければ幅はばが利きかない。
こんな夢では大部分画にも詩にもならんと思いながら、寝返りを打つと、いつの間にか障子しょうじに月がさして、木の枝が二三本斜ななめに影をひたしている。
夢のなかの歌が、この世へ抜け出したのか、あるいはこの世の声が遠き夢の国へ、うつつながらに紛まぎれ込んだのかと耳を峙そばだてる。
自然の色を夢の手前てまえまでぼかして、ありのままの宇宙を一段、霞かすみの国へ押し流す。
夢中に書き流した句を、朝見たらどんな具合だろうと手に取る。
しかし夢のように、三尺の幅を、すうと抜ける影を見るや否いなや、何だか口が聴きけなくなる。
この夢のような詩のような春の里に、啼なくは鳥、落つるは花、湧わくは温泉いでゆのみと思い詰つめていたのは間違である。
しかしてその青年は、夢みる事よりほかに、何らの価値を、人生に認め得ざる一画工の隣りに坐っている。
「あの山の向うを、あなたは越していらしった」と女が白い手を舷ふなばたから外へ出して、夢のような春の山を指さす。

全3212行のうち、上記15行にヒットした。

工夫: マッピングに仕込む

慣れるまではなかなか覚えられない技だが、最近はこんなマッピングを仕込んで、とくにコマンドを思い出さなくても使えるようにしている。

nnoremap <Leader>qy  :<C-u>g //yank Q

便利。

別解: tagbarを使う

これと近いニーズで、「見出し行を集めるのではなく、ただザラッと全見出しを閲覧したいだけ」とか、「任意の見出し行にジャンプしたい」という場合もあり、そういうときはtagbarというプラグインをMarkdown用のプラグインと組み合わせて以下のようにしているのだけど、

これについてはまた時間のあるときに。

まとめ

ということで、普段、日本語の長文テキストを編集しているときに多用している技（というか）をさらっと（でもないが）紹介してみた。

Vimで日本語のテキストを編集しているなどと言うと、時々「それはない」という反応があるが、このように非常に便利なのでそれを示したかったというのもある。

実際には、こういう便利さは対象を「日本語」に限定しなくても、英語でも中国語でも同様に享受できるわけだけど、とはいえプログラミングにおけるVimの便利さとは少し性質も違うだろうと思ったのであえて「Vimと日本語編集」というシリーズタイトル的なものにしてみた。

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

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部に分かれていてきちんと練られていると思うが。

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

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

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (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

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

• GitHub - note103/carvo

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

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

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

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

gyazo.com

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

gyazo.com

最近はこんなふう。（これでも最新ではないが）

gyazo.com

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

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

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

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

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

21世紀の文字起こし

気づき

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

ひえーすごい発見をした。音声入力で文字起こし作業をナシにできないかなあ、と思って対談の音声データをiPhoneのそばで大音量で再生したけど全然認識せず。ですよねー、と一旦諦めた後にふとイヤホンで聴きながらシャドウイング的に自分で喋ったらだいぶテキスト化された（笑）これはいいのでは

— Hiroaki Kadomatsu (@note103) 2016年7月6日

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

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

gyazo.com

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

• 吉祥寺.pm6に参加しました（トーク音声公開＆スライド作成方法） - the code to rock

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

gyazo.com

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

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

そもそも文字起こしとは

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

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

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

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レコーダーへ発声して録音していく。

• プロのタイピスト推奨。WindowsとMacで使えるテープ起こしソフトを無料ダウンロード。フットペダルやホットキーを使い素早く正確にテープ起こし。シンプルで使いやすさ抜群。

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

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

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

2. Soundflowerの準備

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

• Release Signed Version for macOS Mojave (10.14) and earlier · mattingalls/Soundflower · GitHub

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

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

• 【Soundflower】Mac OS X Yosemite〜El Capitanで使えない方へ - NAVER まとめ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ 〜そしてtextlint編へ〜

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

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

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

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

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

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

• textlint · The pluggable linting tool for text and markdown

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

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

続編

note103.hateblo.jp
note103.hateblo.jp

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

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

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

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

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

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

空行・スペース処理

1行ごとに空行を入れる

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

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

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

空行をカットする

上記の逆。

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

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

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

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

まれに使います。

全角英数字を半角にする

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

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

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

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

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

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 

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

• GitHub - rcmdnk/vim-markdown: Markdown Vim Mode

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

同プラグインに関しては以下でも少し触れました。
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 の以下あたりが詳しそうです。

• filetype - Vim日本語ドキュメント

日時をすぐに出す

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

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]

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

開発ツール徹底攻略 (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」というファイル名にしていますが、それがウィンドウ下方にパッと出てくるので、その中に不要な文章をカット＆ペーストで移動。（大抵は最下行）

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

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

: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

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

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

追記: 2016-12-30
この方法については、その後に改訂版を作成して以下で紹介しました。
Vimで今見ているバッファを「現在日時＋好きなファイル名」で保存する - the code to rock

簡単に連番を振る

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

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

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

知らなかった〜……。

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