give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

人に物を教えるときに安易に「簡単ですよ」「誰でもできます」と言わない

「技術記事を書く技術」にこれを書いておけばよかったなー、という話をふと思い出したので、ここに書いておきます。

「簡単です」と言わない方がいい理由

人に何か物を教える際は、「とっても簡単です」とか「これは誰でもできます」みたいな枕詞は付けない方がいいと僕は思っています。

というのも過去の経験上、「簡単ですよ!」と言われても、話を聞いたら「うーん、そうか??」と思うことも結構多かったからです。

それに、「簡単です」「誰でもできます」と言われたにもかかわらず、もし自分ができなかったら、

「自分はそんな簡単なこともできないんだ」
「誰でもできるのに私だけダメなんだ」

と、自尊心が傷つく原因にもなります。

簡単なのは「あなただから」かも?

教える側が「簡単ですよ」と話す場合、「自分が経験豊富な専門家だから」というケースもよくあります。
自分では「こんなの簡単、誰でもできる!」と思っていても、実際は「あなただから簡単に思えるだけ」という事実に気づいていないことも多いのではないでしょうか。

教える側が教えられる側のプレッシャーを下げてあげよう

教える人と教えを乞う人の間には、多少なりとも権力勾配のようなものが存在しています。
もちろん、教える側が上で、教えを乞う側が下です。

教える側は無自覚でも、教えを乞う側は「できないことや、わからないことに対する劣等感」を抱えていることもあるはずです。
そういう状況下での「簡単ですよ」「誰でもできますよ」というセリフは、(教える側の意図に反して)教えを乞う側のプレッシャーを増大させる原因になるのではないかと僕は考えています。

教える側はむしろ、「これ、難しいですよね」「最初からできる人はいないと思いますよ」というように、「わからなくても大丈夫👌」という方向性の言葉をかけてあげる方が、教えを乞う側にとって救いになるのではないでしょうか(少なくとも僕はその方がありがたいです)。

技術記事を書くときも考え方は同じ

この考え方は僕が技術記事を書くときも同じです。
「難しい技術を優しく教える」系の技術記事では、「読者は⚪︎⚪︎のことをとても難しいと考えているはず」という前提で記事を書くようにしています。

もちろん、拙著「技術記事を書く技術」の説明も同様です。
記事執筆に関するノウハウやテクニックについて、15年選手の僕が「こんなの簡単」と思っていても、これから技術記事の執筆にチャレンジしようとしている人が同じように簡単と思えるはずがありません。

ですので、本の中では「とっても簡単です」とか「これは誰でもできます」といった言葉は極力使わないように意識しました*1
むしろ「最初はなかなかできないはず」「全部できなくても大丈夫」というスタンスで記事執筆のノウハウを伝えるようにしています。

記事のテーマは自由です。なんでもいいから書いてみてください!……と言われても、多くの人は「ええっ」と困ってしまうと思います。アウトプットをしたくてもできないから本書を手に取ったのに、最初のアドバイスが「なんでもいいから書いてみて」ではあまりにも乱暴すぎますよね。

引用 「技術記事を書く技術」p24

コラム:「〜ってありますよね?」という言い方も避けたい

他にもよく似た説明パターンとして、「〜ってありますよね?」というセリフもなるべく避けた方がいいと思っています。
たとえば、「"OSI参照モデル"ってありますよね?あれでいうと〜」みたいな説明です。

この場合、「"OSI参照モデル"は当然あなたもご存知だと思いますが」という前提が暗に含まれています。
もし自分が「OSI参照モデル」をよく知らなかった場合、相手の説明をさえぎって「あの、すいません、"OSI参照モデル"って何ですか?」と追加で質問しないといけなくなります。

こうなると、説明を受けているだけでも「何も知らなくて申し訳ない」と思っているのに、さらに輪をかけて「"OSI参照モデル"すら知らなくて本当に申し訳ない」と萎縮してしまう原因になります。

また、その場で相手が「"OSI参照モデル"って何ですか?」で聞いてこなかった場合、

  • 知っているから聞いてこなかった
  • 知らないが恥ずかしくて聞けなかった

の2パターンが考えられます。
前者であれば問題ありませんが、後者の場合、頑張って説明しても自分の説明が相手にうまく伝わっていない恐れが出てきます。

ですので、「"OSI参照モデル"ってありますよね?(=当然あなたも知ってますよね)」ではなく、「"OSI参照モデル"ってご存知ですか?」というように、まずは相手の知識の有無を確認してから説明を進めるようにしましょう*2

まとめ:簡単かどうかの判断は受け手に委ねよう

簡単かどうかは説明する側ではなく、説明を受けた側が判断することです。

説明する側は最初から「こんなの簡単」と断定せず、むしろその逆で「自分にとっては簡単でも、相手は難しいと感じるかもしれない」という前提で説明するようにしましょう。

*1:使っていないつもりですが、もしかしたらどこかで知らずに使っているかも?もしあったらすいません🙏

*2:「〜ってご存知ですか?」は文字にすると相手を煽っているように見えますが、適切なコンテキストをもった会話の中ではそんなニュアンスには聞こえないはずです

「技術記事を書く技術」の著者直筆ポップを書く技術

はじめに

先日、大阪〜神戸の書店を回って「技術記事を書く技術」の直筆ポップを置かせてもらいました。

東京の書店にも直筆ポップを置かせてもらっています。

直筆ポップを置いている書店は以下の通りです。

<東京>

  • ジュンク堂書店 池袋本店
  • 三省堂書店 有楽町店
  • ブックファースト新宿店
  • 丸善 丸の内本店
  • 書泉ブックタワー
  • 紀伊國屋書店 新宿本店

<大阪・神戸>

  • MARUZEN&ジュンク堂書店 梅田店
  • 紀伊國屋書店 梅田本店
  • ジュンク堂書店 大阪本店
  • ジュンク堂書店 難波店
  • ジュンク堂書店 三宮店

上記の書店にお立ち寄りの際は、ぜひ僕の直筆ポップをチェックしてみてください!

「技術記事を書く技術」を見つける技術?

ちなみに、実際に書店を回って思ったのですが、「技術記事を書く技術」は、

  • これまでにないジャンルの本なので、どの棚にあるか予想しづらい
  • 表紙がシンプル(悪くいえば地味)なので、他の書籍と並んだときに埋もれやすい

という問題(?)があり、自力で見つけるのにちょっと苦労しました。

この直筆ポップが置いてあるお店は、多少「技術記事を書く技術」を見つけやすくなるかもしれません。

直筆ポップがあるとき〜(左)ないとき〜(右)

もし自力で見つけられなかった場合は、書店員さんをつかまえて「すいません、『技術記事を書く技術』はどこにありますか?」と大きな声で聞いてください!!

直筆ポップの作り方

ところで、本を書いた人なら一度は作ってみたい(?)著者直筆の書店用ポップですが、いざ作ろうとすると「どうやって作ればいいの!?」と困ってしまうかもしれません。

そこで今回のエントリでは、僕がどんな流れで直筆ポップの作ったのかを説明しておきます。

1. 準備

まず、編集者の人に「直筆ポップを作ってみたいんですけど」と相談しましょう。
ほとんどの場合、「いいですね、やりましょう!」と乗ってきてくれるはずです。
直筆ポップを書く厚手の台紙は、編集者の人が自宅まで送ってきてくれると思います。

台紙が届いたら、多めにカラーコピーしておきましょう。
これは何度もデザイン案を下書きできるようにするためです。

次に、ポップを書くための色ペンを用意しましょう。
今回は100均で太めと細め、2種類の色ペンを買ってきました。


2. 情報収集する

「書籍 直筆ポップ」「技術書 著者直筆POP」のようなキーワードでネットを画像検索してみましょう。
また、「ジュンク堂書店池袋本店 PC書担当」さんは、直筆ポップの写真をXにたくさん載せてくれているので、過去事例を探すのに大変役立ちます。

"from:junkudo_ike_pc 直筆POP"のXの検索結果

これらの事例を見ながら、なんとなく自分の中のイメージを膨らませます。

3. 生成AIに叩き台を考えてもらう(?)

上のような情報収集だけで、すぐに「よし、こんなポップを作ろう!」とアイデアが出てきた場合はいいですが、僕のようなデザイン素人にはそんな芸当はできません。
というわけで、とりあえず生成AIに叩き台を作ってもらうことにします。

今回はこんなプロンプトをGeminiに打ち込んでみました。

以下の本を執筆した。書店に置いてもらう著者直筆POPの叩き台画像を考えてほしい。

https://www.shoeisha.co.jp/book/detail/9784798177045

Geminiが提案してきた直筆ポップのデザイン案はこんな感じでした。

……うーん、なんかイマイチですね😅
やっぱり自分でじっくり考えることにします。

4. 下書きを(山ほど)書いてみる

直筆ポップを作るためのインプットはこれぐらいにして、ここからは実際にデザインを考えましょう。
まずはポップを見た人に何を伝えたいかを考えて、ポップに載せるキーワードを検討します。

そして、事前に用意しておいた台紙のコピーに、あれこれ文字を書いていきましょう。
文字を書くのは台紙のコピーなので、いくら失敗しても大丈夫です。
コピーがなくなったら、さらに追加で台紙のコピーを取ってください。

こんなふうにあれやこれやと下書きをいくつも作り、最終的に以下の2案に絞りました。

案1:メッセージを大きく打ち出すパターン

案2:「あるある」なお悩みに訴えかけるパターン

5. 編集者の人と相談してデザインを選ぶ

どっちがいいのかは編集者の人の意見も参考にした方がいいと思ったので、編集の大嶋さんにどっちがいいですか?と尋ねてみました。

大嶋さんからは次のような返事が返ってきました。

下書きありがとうございます。
2つのパターン、どちらも内容がしっかり伝わってきて、とてもよいと思いました。

個人的には、メッセージを大きく打ち出している1つ目のパターンが、今回のPOPにはより合っているように感じました。
POPは、書店の店頭でひと目でメッセージが伝わることや、今の時流に合った言葉を載せやすいことが強みだと思うので、今回であれば 「AI時代だからこそ、人が書く技術記事に価値がある」 という点を前面に出せるとよさそうです。

なるほどなるほど。
僕もそれでいいかな、と思ったので、今回は「案1:メッセージを大きく打ち出すパターン」を採用することにしました!

6. パソコン上で文字の大きさや配置を検討する

次は文字の大きさや配置を検討します。
これもコピーした台紙の上で考えてもいいのですが、より細かい試行錯誤がしやすいように、パソコンの画面上で検討することにしました。

具体的には台紙をスキャンして画像化し、それをスライド作成ツールのKeynoteに取り込んで、その上に文字を書き込んでいきました。


7. 配色を検討する

このままだと白黒の味気ないポップになってしまうので、これまたGeminiに配色の叩き台を考えてもらうことにしました。

添付画像のような書店用直筆POPを作成した。色ペンで魅力的な彩色を入れたい。

Geminiが提案してきた配色案はこんな感じでした。

うーん、いいような、そうでもないような……。
いや、やっぱり微妙ですね。

というわけで、配色に関しても実際に色ペンを使い、コピーした台紙上に何度も下書きを繰り返しました。

8. 直筆ポップのデザインが完成!

あーでもない、こーでもない、と言いながら下書きを繰り返した結果、直筆ポップのデザインは以下のようになりました。

個人的なこだわりポイントを以下にまとめます。


  1. 「あなたの言葉で 技術記事を書こう!」これが一番伝えたいメッセージなので、黒ペンで目立つように書いています。さらに目立つよう、アクセントカラーの赤で下線も入れています。ちなみに「あなたの言葉で」は細ペンで、「技術記事を書こう!」は太ペンで書いているのですが、ここはそこまで違いがわからないですね。
  2. 「15年分の知見とノウハウをすべて詰め込みました。」はサブメッセージです。「(私が)詰め込みました」は著者にしか書けないメッセージなので、これがあることで著者の直筆ポップだと伝わりやすくなるはずです。黒ペンで書くとごちゃごちゃしたので、黒ほど前に出てこない青文字で書いています。また、「15年分」の下には強調と彩りの目的で黄色で下線を入れました。
  3. 文字で書籍名を入れるとそれもごちゃごちゃしたので、代わりに表紙の縮小コピーを貼り付けました。また最悪、何かの事故で直筆ポップと書籍が離ればなれになったとしても、表紙画像があれば、これは「技術記事を書く技術」の直筆ポップであることがすぐにわかるはずです。
  4. メインメッセージ=黒、サブメッセージ=青、なので、区別しやすくするように著者名はまた黒に戻しました。「伊藤淳一」だけでも良かったのですが、それだと空白ができてしまうので、あたかもその日に著者がやってきたかのように見える日付を入れることにしました。(関西の書店には実際に行ってますけどね)
  5. 「AI時代だからこそ」は、実はオマケワードです。「右上に空白ができるので何か埋めたいな」と思い、編集の大嶋さんのフィードバックにあった 「AI時代だからこそ、人が書く技術記事に価値がある」というコメントから「AI時代だからこそ」を拝借しました。表紙のアクセントカラーに合わせて文字色は緑にし、吹き出しは台紙の縁(ふち)の色に合わせて水色にしました。
  6. 一枚一枚手書きで書いてますよ、ということを証明するために、各ポップには書店名を入れています。ただし、書店名が目立つとやはり全体がごちゃごちゃするので、あえて(一番目立ちにくい)ボールペンで書店名を書きました。

9. がんばって量産する

デザインが完成したら、あとは同じポップを量産していきます。
といってもこれは「著者の手書き」であることがポップの価値になるので、機械を使ったコピーではなく、がんばって自分の手で書き書きします。

東京の書店用に6枚、大阪・神戸の書店用に5枚作ったので、結構大変でした!!💦

東京用のポップ 6枚
大阪・神戸用のポップ 5枚

ちなみに台紙に貼り付けている表紙画像は、東京用は翔泳社さんに用意してもらい、大阪・神戸用は僕が自分で作りました。
表紙画像を印刷する→カッターで切り取る→糊で貼り付ける、という作業も地味に大変でしたね😅

10. 書店に配布する

最後に、直筆ポップを各書店に配布したら、ミッションコンプリートです。
東京方面は、兵庫県民である僕はぱっと行けないので、翔泳社さんに郵送して書店に配布してもらいました。
大阪・神戸の書店は、事前に翔泳社さんから各書店に連絡を入れてもらった上で、僕が書店に足を運んでポップを置いてもらう、という手順で配布しました。

紀伊國屋書店 梅田本店にて

ちなみにポップを置いてもらう際に、書店員さんから「これ、たくさん売れてるので、追加発注かけてるんですよ〜」みたいな話を聞いたときは、とても嬉しかったです!

まとめ

というわけで、このエントリでは拙著「技術記事を書く技術」の書店用直筆ポップの作り方を解説してみました。
我流なのでもっとスマートなやり方もあるかもしれませんが、こういう泥臭いやり方のほうが、より「著者のぬくもり」を感じやすいんじゃないでしょうか?(と、勝手に思っています)
もし「著者の直筆ポップ」を作ろうとしている人がいたら、今回のエントリをぜひ参考にしてみてください。

そして、直筆ポップを作る予定はなくとも、「技術記事を書いてみたいな」「もっと上手に書きたいな」と思っている人は、ぜひぜひ、「技術記事を書く技術」を手に取ってみてください。
きっとみなさんの悩みを解決するヒントがたくさん詰まっているはずです!よろしくお願いします!!

唯一の正解なんてない。「技術記事を書く技術」が「私見強め」になった理由(アウトプットに関するリンク集もあるよ)

はじめに

このブログでも何度か紹介してきたとおり、本日2026年4月27日に、僕が執筆した新刊「技術記事を書く技術 ITエンジニアの価値を高めるアウトプットのすべて」が発売されました!🎉


この書籍はタイトルの通り、アウトプットに興味があるITエンジニアに向けて、技術記事を書く方法を指南する本です。
また、「書き方」のみならず、ネタの見つけ方や、記事を公開したあとの反応との向き合い方なども説明しています。
さらに、最後の第3部には、他のエンジニアが書いた実際の技術記事を僕が添削するパートもあります。

「技術記事を書く技術」の概要を知る

本書の目次は以下の通りです。

【第1部 最初の一歩を踏み出す】

  • 第1章 技術記事を書く目的とメリット ⭐️試し読み可
  • 第2章 まず1本記事を書いてみる

【第2部 質を高める】

  • 第3章 ネタを見つける技術
  • 第4章 事前準備の技術
  • 第5章 見出し・タイトルの技術 ⭐️試し読み可
  • 第6章 構成・見せ方の技術
  • 第7章 正しい情報を正しく伝える技術 ⭐️試し読み可
  • 第8章 文章を読みやすくする技術
  • 第9章 よいサンプルコードを書く技術
  • 第10章 公開・シェアする技術
  • 第11章 反応と向き合う技術
  • 第12章 アウトプットを継続する技術
  • 第13章 アウトプットの幅を広げる技術

【第3部 実例添削で学ぶテクニック~達人による 38 のフィードバック~】

  • Case 1:「技術を自分なりの言葉で説明する」記事
  • Case 2:「エラーの解決方法を解説する」記事
  • Case 3:「新しい技術を触ってみた」記事

このうち、第1章、第5章、第7章は翔泳社の書籍紹介ページにある特別抜粋版PDFで試し読みができます。

技術記事を書く技術 ITエンジニアの価値を高めるアウトプットのすべて(伊藤 淳一)|翔泳社の本

また、書籍冒頭の「はじめに」は、僕のXのポストにアクセスすれば読むことができます。

購入を迷っている方は、「試し読み」をうまく活用して、自分のニーズに合う本かどうかを判断してみてください。

ここからが本題:アウトプットに唯一の正解なんてないんだよ

さて、ITエンジニアのアウトプットに関する本を書いておきながら、こんなことを言うのもなんですが、アウトプットに唯一の正解はありません。

僕が本の中で書いていることも「数ある正解のひとつ」です。

「そんなの当たり前じゃないか」と言われそうですが、この本の執筆に取りかかる前は「自分ならアウトプットのバイブルになるような本が書けるんじゃないか」と考えていました。

僕自身「技術記事を書くならこうした方がいい」という考えがいくつかありましたし、ネットを見ていてもいろんなエンジニアが「アウトプット論」を語っています。
そこで「僕自身のアウトプット論」と「世間でよく言われるアウトプット論」をくまなくカバーするような本を書けば、「完全無欠のアウトプット論」ができあがるはずだ、と考えました。

が、言ってることはみんなバラバラだった

ですが、このアプローチは秒で頓挫しました。
というのも、みんな言っていることがバラバラだからです。

ある人は「読み手のことを考えて記事を書け」と言い、またある人は「技術記事なんて自分のために書くものだ」と言う。

ある人は「同じような記事がすでにあるなら、自分が記事を書く意味はない」と言い、またある人は「同じ記事であっても、気にせず書けばいい」と言う。

と、こんな調子でみんな正反対のことを言うので、とても「これが正解」なんて言えるようなものは導き出せなさそうでした。

僕「唯一の正解なんてない!僕は僕の考えていることだけを書く!!」

というわけで、方針変更です。
誰もが納得する「完全無欠のアウトプット論」なんてものは書けそうにないので、「僕の本なんだから、僕の好きなように書かせてもらいます」というポリシーに変更しました。

原稿を書きながら「これ、正反対のことを考える人も絶対いるだろうな〜」と思うような場面もたびたびありました。
ですが、そういうときは毎回「いや、唯一の正解はないんだ。だから、ここは僕の考えを書く!」と強い気持ちで、僕自身のアウトプット論を書いていきました。

なので、「技術記事を書く技術」はとっても「私見強め」です。
本書を読みながら「ちょっと私見が強すぎるんじゃない?」と思うような箇所があったら、それは意図的にそうしていると考えてください。

私見強めですが、そのぶん、この本には僕自身の個性やオリジナリティが詰め込まれています。
それがかえって本書の面白さを引き立てているはず、と僕自身は信じています。

とはいえ、他の人のアウトプット論もチェックしていた

上で述べたように、「技術記事を書く技術」は、僕「伊藤淳一」が考えるアウトプット論を書く、というポリシーで執筆していました。
ですが、その一方で参考情報として他の人のアウトプット論もたまにチェックしていました。
具体的には、はてなブックマークやQiitaの週間ランキングでアウトプット論っぽい話題が出ていたら、ざっと目を通してネタ帳にURLを保存していました。

本の執筆には4年かかったので、その間にいろんな記事のリンクが集まりました。

他の人のアウトプット論もぜひ参考にしてほしい

繰り返し述べている通り、アウトプットに唯一の正解はありません。
よって僕以外の人が語るアウトプット論もまた「数ある正解のひとつ」です。

世の中には僕と同じ意見、ちょっと違う意見、まったく違う意見など、さまざまな意見があります。
ここから下ではカテゴリ別に、他の人が書いたアウトプット論のリンクを集めました。
タイトルを見て興味を持った記事があれば、ぜひチェックしてみてください。

アウトプットに関するリンク集

まとめ:AI時代だからこそ、あなたの言葉で技術記事を書こう

というわけで、このエントリでは本日発売の新刊「技術記事を書く技術 ITエンジニアの価値を高めるアウトプットのすべて」の紹介と、僕以外の人が書いたアウトプット論のリンク集を作ってみました。

リンク先の記事を読むと、僕と同じことを言っている人もいれば、僕と違うことを言う人もいます。
でも、それは唯一の正解がないのだから当然です。
また、「技術記事を書く技術」の中には、他の人が書いていない、僕だけのアウトプット論や、アウトプットに関する知見も載っています。

繰り返しになりますが、「技術記事を書く技術」は「私見強め」です。
言い方を変えれば「個性が強め」です。

しかし、本の執筆も、技術記事の執筆も「個性強め」でいいんじゃないでしょうか。
みんな同じことばかり書いてもつまらないですし、AIに聞けば同じようなことを答えてくれるような記事も「それじゃあAIに聞きますわ」ってなりません?

先日開催されたRubyKaigiでは、先行販売用にこんなポップを作りました。

AI時代だからこそ、あなたの言葉で技術記事を書こう。

AIにお願いすればそれっぽい記事を書いてくれますが、「あなた」という人間の個性が一番発揮できるのは、あなた自身が書いた記事です。
「技術記事を書く技術」を読んで、あなた自身の言葉で書かれた技術記事を書いてみましょう!