はじめに
僕は「プロを目指す人のためのRuby入門」（通称チェリー本）というRubyの入門書の著者です。
本書は発売以来、非常に多くのみなさんに読んでいただき、筆者として大変喜んでいます。
しかし、その一方でQiitaを見ていると、「これ、明らかにチェリー本の説明文やサンプルコードを参考にして書いてますよね？」という記事をよく見かけます。
中にはきちんとマナーを守って記事を公開されている方もおられますが、残念なことに僕から見て「悪意がないのはわかるけど、そのスタイルで公開されるのはちょっと困る」と感じるケースがかなり多いです。
この記事では、書籍やネット上の情報を参考にしてQiitaに記事を公開する際の最低限のマナーについて説明します。
また、この記事の内容はQiitaのみならず、自分のブログに記事を書くときにも意識すべき内容になります。
備考：「そもそもこの記事ってガイドライン違反じゃないの？」
今回の記事はQiitaのガイドラインに適合しないことは十分承知しています。
同じような話は以前自分のブログに書いており（参考）、今までは問題のある投稿に対してはそのブログのリンクを紹介していました。
しかし、何度繰り返しても効果がなかったため、今回はQiitaユーザーに直接周知する目的でQiitaに書くことにしました。
運営の方からガイドライン違反の指摘が入った場合は速やかに記事を削除します。
それでは以下が本編です。
「ちょっと困る記事」って、たとえばどんな記事？
僕にとっての「ちょっと困る記事」というのは、たとえばこんな記事（僕が作った架空の投稿）です。
タイトル「備忘録 Ruby基礎」
最近Rubyの勉強を始めたので、備忘録としてメモを書いていきます。
Rubyは基本的に改行が文の区切りになります。セミコロン（
;）等の記号を使って明示的に区切りを示す必要はありません。# 改行ごとにメソッドが実行される 1.to_s #=> "1" nil.to_s #=> "" 10.to_s(16) #=> "a"一方、セミコロンで明示的に文の区切りを指定することもできます。使用頻度は高くありませんが、1行に複数の文を入れたい場合に使われることがあります。
# セミコロンを使って、3つの文を1行に押し込める 1.to_s; nil.to_s; 10.to_s(16)文が続くことが明らかな場合は、文の途中で改行することができます。
# ( で改行しているので、カッコが閉じられるまで改行してもエラーにならない 10.to_s( 16 ) #=> "a" # ( がない場合は10.to_sと16という2つの文だと見なされる 10.to_s #=> "10" 16 #=> 16バックスラッシュ（
\）を使うと、文がまだ続くことを明示的に示すことができます。ただし、使用頻度は高くありません。# バックスラッシュを使って10.to_s 16を改行して書く 10.to_s \ 16 #=> "a"何かあればまた追記します。
間違っているところがあれば教えてください！
「プロを目指す人のためのRuby入門」を持っている方はわかると思いますが、出だしと締めくくりの文以外は完全に本の丸写しです。
ここまで極端ではなくても、これに近い感じのQiita記事やブログ記事を今までたくさん見てきました。
こういった記事がなぜマナー違反になるのか、どうすればマナー違反にならないのか、といった話を以下に述べます。
執筆時に参考にした情報がある場合は、必ず参考文献を明記する
執筆時に参考にした情報がある場合は、必ず参考文献を明記してください。
おそらく、技術記事を書く場合は何らかの形でネット上の情報や書籍を参考にすることがほとんどで、「これは最初から最後まで自分がゼロから考えたオリジナルの説明とサンプルコードです！！」と胸を張って言える記事はそんなに多くないのではないでしょうか。
たとえば、以下のような情報源が参考文献としてあがってくることが多いと思います。
- 公式APIドキュメントや、ライブラリのREADME
- GitHubのissue
- 他の人が書いたQiita記事やブログ記事
- Stack Overflowのベストアンサー
- 書籍
参考文献がある場合は文末にリンクや書籍名を載せておきましょう。
以下は参考文献を載せる際の記述例です。
## まとめ
（まとめを書く）
## 参考文献
この記事は以下の情報を参考にして執筆しました。
- [参考文献1のタイトル](http://example.com/1)
- [参考文献2のタイトル](http://example.com/2)
文末でなく、該当トピックのすぐ近くに書くのもOKです。
## ○○について
（説明を書く）
参考: [参考文献1のタイトル](http://example.com/1)
## △△について
（説明を書く）
参考: [参考文献2のタイトル](http://example.com/2)
2019.4.25 追記
「執筆時に参考にした情報がある場合は、必ず参考文献を明記してください」と書きましたが、「1ミリでも参考にした内容があるなら、すべての情報源をもれなく列挙せよ」と極端なことを言うつもりはありません。
そもそもそんなことをするのは不可能です。
あくまで「参考にした記事は何か？」と自問自答したときに、ぱっと思い浮かんだ情報源をいくつか列挙すれば十分です。
ここで問題にしているのは、そういう情報源（＝すぐに思い浮かぶ情報源）があるにもかかわらず、 まったく何も参考文献を書かないこと です。
全く同じ文章をそのままコピペするときは引用を使う
他のサイトや書籍で書かれている文章を全く変えずに使い回したいと思ったときは、引用（>）を使います。
以下は引用を使う例です。
この内容については、[参考文献のタイトル](http://example.com/1)で以下のように説明されています。
> 引用文です。引用文です。引用文です。引用文です。
他の情報源で書かれている内容を、引用を使わずにしれっと自分が考えた文章であるかのように本文に紛れ込ませるのはNGです🙅🏻♀️
無断転載になっていないか客観的にチェックする、または著者に許可を求める
参考文献を明記していたり、引用を使っていたりしても、その記事にオリジナルの要素がほとんどなく、他の情報源を拝借してきただけの記事になっている場合は無断転載と見なされることがあります。
自分の書いた記事にはどれくらいオリジナルの要素（＝あなた独自の経験、感想、知見等）が含まれていますか？
他の情報源で書かれている内容を少し言い換えただけの「劣化コピー」になっていませんか？
「オリジナルの要素が記事の何割であればセーフ」と、定量的な基準を示すことはできませんが、「自分がその情報を参考にされた側に立ったときにどう感じるか？（パクリだ！と思われるか、思われないか）」を想像してみると良いかもしれません。
無断転載かどうか判断に迷うときは、コメント欄やTwitterのメンションなどを通じてオリジナルの情報源の著者や作者に許可を求める方が良いと思います。
自分で見ても明らかにオリジナルの要素がない、著者への連絡手段が見つからない、許可を求めたが返信がない、といった場合は「非公開の自分用メモ」として「下書き」のまま置いておきましょう。
詳しすぎる要約も無断転載と見なされるので注意する
書籍の内容を「自分なりに要約してみました」といって公開する場合も注意が必要です。
要約があまりにも書籍の内容を詳しく説明しすぎている場合は、これも無断転載と見なされる場合があります。
「ありがとう！あなたが記事を書いてくれたおかげで、本を買わずに済みました！」というような感想が返ってきそうな要約記事であれば、内容を見直したり、公開を控えたりする方が良いです。
まとめ
というわけで、この記事ではQiitaに記事を公開する際に気を付けたい、参考文献と引用と無断転載について説明してみました。
ざっくりまとめると、以下のようになります。
- 参考にした情報源がある場合は参考文献を明記する
- 他の人が書いた説明文をまるまる拝借する場合は引用を使う
- 他の情報源を丸写ししただけの無断転載記事になっていないか、客観的に自分の記事を見直す
Qiitaやブログに自分が学んだことをアウトプットするのは大変良い習慣です。
しかし、オリジナルの情報源を書いた人に「あ、勝手にパクられた！」と思われないように、マナーを守ってQiitaやブログに記事を書きましょう。
参考文献
この記事は昔自分で書いたブログの内容と、そのブログを執筆する際に参考にした参考文献がベースになっています。
- ブログに技術書の内容を丸写しする問題点と、オリジナルなコンテンツを書くためのアイデア - give IT a try
- 無断引用はＯＫだけど無断転載はＮＧ？～３分で分かる引用と転載の違い～ | ビジネス著作権検定の情報なら塩島武徳先生の「みんなの著検」
- ブログで「本の要約」は著作権法上ダメなのか？記事を書くときに気を付けること。 | 冷静と情熱のアイダ
ただし、引用や転載の基準や判断については法律が関わる部分であり、僕自身は法律の専門家ではありません。
この記事の内容はあくまで、あくまで僕個人が考える基準を述べたものになります。
😢 蛇足、というか無断で自分の本の内容を丸写しされる人の気持ち（もしくは愚痴）
さて、ここから下は僕自身の気持ちを吐露するオマケコーナーです。
人によっては「まあ、そんな細かい話、別にどうでもええやん」と考える人もいるかもしれません。
ですが、僕の場合は「どうでもええやん」で終わらせることはできません。
その理由と僕の正直な気持ちを以下に述べます。
Qiitaを見ていると、ひと月に数回は「あ、これは僕の本を読んで書いたな」とわかる記事（かつ、参考文献を書いていない記事）を見かけます。
どの記事も、書いた本人に悪意がないのはわかります。
記事を書かれたみなさんの中にあるのはきっと「自分が勉強した内容をアウトプットしたい」という純粋な思いだけですよね。
それに、「明らかに僕の本を読んで書いた記事」が頻繁に出てくるということは、それだけ自分の本が売れている、という証明にもなります。
なので、読者の方がたくさんいること自体は大変嬉しいです。
が、その一方で、そういった記事を見かけると、僕個人の感情としては同時にとても切ない気持ちになります。
というのも、「プロを目指す人のためのRuby入門」の説明文やサンプルコードは、僕自身が本当に時間をかけて、丁寧に丁寧に、隅から隅まで、心血を注いで磨き上げた説明文やサンプルコードだからです。
どれくらい時間をかけて執筆したのかについては、以下のブログ記事に詳しく書いています。
技術書を書きたいITエンジニア必見！？「プロを目指す人のためのRuby入門」の舞台裏をお見せします - give IT a try
上のブログ記事にも書いていますが、期間で言うと、執筆の声がかかってから発売まで1年半ぐらいかかっています。
2016年6月：執筆の声がかかる
2016年8月：とりあえず執筆開始
2016年11月：企画が通る
2017年2月：いったん執筆完了、しかし…
2017年3月：分量の削減
2017年4月：構成上の大手術
2017年5月：原稿の清書完了
2017年6月～7月：DTP作業
2017年8月：1回目の校正
2017年9月：まえがきとか、表紙デザインとか
2017年10月上旬：2回目の校正
2017年10月下旬：3回目の校正（最終）
2017年11月：ついに発売！！
それだけ時間をかけて書いた文章が、参考文献の記載なしに公開されているというのは、まるで僕がその人から「この文章を考えたのは僕ですよー。えっへん！」と言われていることと同じように思えて非常に悲しいです。
だって、参考文献の記載がなければ、「プロを目指す人のためのRuby入門」を読んだことがない第三者からすると、「あ、この記事はこの人が自分で考えて書いたんだな」と思うほかにないですから。
しかも、さらに輪をかけて悔しい、というかめちゃくちゃモヤモヤするのが、その記事の内容に対してツッコミが入っているときです。
たとえば、こんな感じです。
（コメントした人）
そこの説明はちょっとおかしいですね。正しくは○○です。（記事を書いた人）
ありがとうございます！勉強になります！すぐに修正します！
はい、このパターンも非常に多いです。
見かけたのは一度や二度ではありません。
こんなやりとりを見たときの僕の気持ちを正直に言うなら、こうです。
「おーい、待て待て！！何が『勉強になります』やねん！！その説明文を考えたのは俺やぞー！？それを『修正します』っていったいどういうことや！！お前の文章やない、俺の文章や！お、れ、の！！断りもなく勝手にフォークすんなーーーー！！！！」
僕はコメント欄を見ながら、心の中で毎回こんなことを絶叫しています。
（すいません、僕は大阪生まれ大阪育ちの関西人なので、普段は関西弁なんです……）
「修正します！」とか言われるぐらいなら、まだこんなふうにコメントを返してくれた方が100倍マシです。
あー、すいません。これね、僕が考えた説明じゃないんですよ。「プロを目指す人のためのRuby入門」っていう本がありましてね、そこに載ってる説明を写してきただけなんです。なので、説明で気になるところがあれば著者の伊藤淳一っていう人に直接言ってもらえませんか？
なんでこの方がマシなのかというと、文責が僕にあること、つまり説明文の持ち主が僕であることが明確だからです。
僕が考えた文章なんだから、何かおかしなところがあれば僕に直接言ってきてほしい。
僕がいないところで「ご指摘ありがとうございます！勉強になります！修正しておきまーす（てへぺろ）」なんて言ってほしくありません。
そのセリフを言ってもいい人がいるとすれば、それはあなたではなく、僕です。
・・・という思いをこれまで何度となく繰り返してきました。
まあ、この記事を書いたところで、新しくプログラミングを始めた新人さんはこの記事の存在に気づかず、やはり同じようにチェリー本の内容をQiitaやブログに悪気なく書き写してしまうでしょう。
この先もおそらく、同じようないたちごっこが続いていくことは僕自身もわかっています。
ですが、僕が匙を投げて「もういいや」と諦めることはありません。
僕は自分が書いた文章の責任はすべて自分の元に集めたいです。
そのために、参考文献を明記していない無断転載記事に対しては、今後も内容の修正を指摘し続けていきます。