結城浩の「コミュニケーションの心がけ」2019年2月12日 Vol.359

目次

• 共同執筆を支える技術 - 文章を書く心がけ
• 気になる異性の注目を集めたい
• 教える側が最初に伝えるべきこと - 教えるときの心がけ
• 専門書の読み方 - 学ぶときの心がけ
• 職場を選ぶとき、就職や転職を決断するときには何が重要か - 仕事の心がけ

はじめに

結城浩です。

いつも結城メルマガをご愛読ありがとうございます。

寒いです。

このあいだまで「確かに暖冬だなあ」や「あまり冬という感じがしない」と思っていたのがウソのようです。

寒いです。

気温の変化、気候の変化、気圧の変化は、心と身体に負担になるので注意しつつ進みたい今日このごろです。

あなたも、どうぞお身体を大事にしてくださいね。

ファンタジーの効用の話。

先日私は、とあるお店で「○○味噌」を探していました。愛用している特定の銘柄のお味噌です。いつもはこのお店にあるのですが、今日は見つかりません。

そこで店長さんに尋ねました。以下、私と店長さんとの会話。

　私「〇〇味噌が棚にないんですが、在庫もないんですか」
　店長「ないですねえ」
　私「いつ入荷しますか」
　店長「すみません」
　私「いつ入荷しますか」
　店長「今週は入りませんねえ」
　私「来週は入りますか」
　店長「ご迷惑おかけします」
　私「来週は入りますか」
　店長「売り切れておりますので…」

私は○○味噌の入荷時期を知りたかったのですが、店長さんはかたくなに入荷時期を言いません。もしも来週に入荷するなら待つけれど、入荷しないなら別の味噌を購入したい。ところが、入荷時期がわからなければ判断できません。

どうしてこの店長さんは入荷時期を言わないのだろう！と解せない気持ちになりました。

それと同時に、こんなふうに思いました。

もしかしたら、この店長さんは幼少期に「お味噌の入荷時期を言ってはいけない魔法」を悪い魔女からかけられてしまったのかもしれない！　だとしたら、入荷時期を言わないのも納得だなあ……

「お味噌の入荷時期を言ってはいけない魔法」というのは、グリム童話の「いばら姫」（眠れる森の美女）の物語に似ていますね。お城の地下室にはお味噌が醸してある。そこに入った幼少期の店長はついうっかり蓋を開けてしまう……などと空想が広がりました。悪い魔女の造形は実写版のディズニー映画『マレフィセント』で行きましょう。

そのようにファンタジー風味で考えると、コミュニケーションのイライラが緩和されるのでお勧めです。

不思議なことに、この店長さんとの会話を続けているうちに、店長さんの様子から「入荷時期は来週になることがほぼ確実だけど、もしかしたら再来週になってしまう可能性もある。どちらになるか確実なことはいえない」という気配を感じ取ることができました。人間のテレパシー能力ってすごいです。

ところで内緒の話ですが、私も編集者さんからの問いに対して、この店長さんと同じような返答をする場合があることに気付きました。

　編集者「いつ脱稿になりますか」
　私「だいぶコアになる部分はつかめてきました」
　編集者「いつ脱稿になりますか」
　私「あとはこの章を突破すれば」
　編集者「いつ脱稿になりますか」
　私「えーと……」

私は幼少期に「脱稿時期を言ってはいけない魔法」を悪い魔女から（以下略）。

真面目な話をすると、入荷時期を聞かれた店長さんと、脱稿時期を聞かれた私とは同じ誤りに陥っています。それは自分を守る方に意識が向かい、質問者のことを考えられなくなっているという誤りです。質問者は状況を知りたいと思っている。もちろん早いに越したことはないけれど、状況がわからないことには判断を下すことができない。でも回答者は質問者の意図にまで気を回すことができず、口ごもってしまう。そういう誤りですね。

結論？　○○味噌は、次の週に無事入荷しましたよ！

めでたし、めでたし。

では、今回の結城メルマガを始めましょう。

どうぞごゆっくりお読みください。

共同執筆を支える技術 - 文章を書く心がけ

ブログ記事の紹介です。

『ゼロからわかるRuby超入門』（五十嵐邦明＋松岡浩平）という書籍の著者の一人、松岡さんが、Qiitaで「執筆活動を支える技術」という記事を公開しています。

◆執筆活動を支える技術
https://qiita.com/machu/items/4a133e83f58f82459e56

◆『ゼロからわかるRuby超入門』
https://www.amazon.co.jp/exec/obidos/ASIN/B07KQXFF6D/hyuki-22/

この記事では「複数人が共同して作業をするためにどのような技術を使ったか」が以下の四ステップに分けられて具体的に書かれています。

• 原稿を書く (Asciidoc, Atom, Visual Studio Code)
• 共有する (GitHub, Slack)
• HTML/PDF形式に変換する (Rakefile, CircleCI)
• 限定公開する (docker, nginx)

この記事は、書籍執筆者、編集者、技術文書の関係者は必見でしょう。簡潔ではありますが、どんな道具をなぜ使ったかという知見が書かれています。たとえここに書かれていることが自分の環境では実現できなくても、その精神や考え方を自分の執筆・編集作業に取り入れることは有益でしょう。

この記事を見ていると、技術の力は個人のパワーを増幅させて、さらに技術を使える人が複数人集まるとそのパワーがさらに何倍にもなるということがよくわかります。

この記事を読みながら、大事なのは「Slackを使ったからうまくいく」や「GitHubを使ったからうまくいく」という話ではないのだろうと思いました。「執筆者たちが自分たちのワークフローを考え、適切なツールを選んだからうまくいく」ということではないでしょうか。

この記事のあちこちに「この技術を選んだ」や「こういうやり方もできるが、それは選ばなかった」ということが書かれています。そのような選択ができること自体が技術力の一つでもあるなと思いました。技術力があるというのは、自分たちには何が適切なツールなのかを判断できるということでもあるのです。

また、執筆者たち・イラストレータ・編集者との間に信頼関係があるから、この記事に書かれているようなコミュニケーションがうまくいくのだろうとも思いました。それは、記事中に示されたやり取りの例を読みながら感じたことです。ある程度以上の信頼関係がなければ、いくらツールを揃えてもこうはいかないでしょう。

そもそも「今回私たちはこういうやり方で執筆を進めました」という記事を書けること自体がすごいことです。なぜなら、執筆の内容を意識するだけではなく、執筆の進め方も意識している証拠ですから。プログラミングが得意な人は、そのようなメタな発想が得意な人が多いと私は感じています。

◆執筆活動を支える技術
https://qiita.com/machu/items/4a133e83f58f82459e56

なお、以下はイラスト担当のべこさん（@becolomochi）視点からの別記事です。

◆Ruby超入門のかわいいキャラクターたちが生まれるまで
https://note.mu/becolomochi/n/nbfac9ad3a8d0