give IT a try

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

ブログに技術書の内容を丸写しする問題点と、オリジナルなコンテンツを書くためのアイデア

はじめに

プロを目指す人のためのRuby入門」を出版して以来、本で学んだ内容をブログに載せてくれている方をよく見かけます。

それ自体は著者として大変嬉しいのですが、たまに「ん?これはちょっと・・・」と思うようなブログ記事を見かけるときがあります。
具体的にいうと、本の内容を丸写ししているだけのブログ記事です。

このエントリでは本の丸写しがなぜいけないのか、かわりにどういうブログを書けばいいのか、ということについて書いていきます。

本の内容を丸写ししているブログの例

本の内容を丸写しをしているブログというのは文字通り「丸写し」しているブログです。
具体的なイメージを共有するために「こんな感じ」という例を載せておきます(特定の誰かのブログを意図しているわけではありません)。

タイトル「第2章 2.2.3 文の区切り」


「プロを目指す人のための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入門」を持っている方はわかると思いますが、最初と最後の一文以外は完全に本の丸写しです。
ここまで極端ではなくても、これに近い感じのブログ記事をいくつか見てきました。

技術書の内容を丸写しすることの問題点

技術書の内容を丸写しすることは大きく分けて2つの問題点があります。

問題点その1:引用の範囲を超えて無断転載と見なされる

ブログを書いてる本人には悪意がなく、純粋に「自分が勉強した内容をブログにメモしただけ」と考えているのはわかります。
ですが、技術書や他の人が書いたブログ記事の内容を必要以上にブログに盛り込んでしまうと引用ではなく「無断転載」と見なされる恐れがあります。

2018.01.23 16:00追記
引用や転載の基準や判断は法律が関わるところであるため、素人がうかつに発言するのは危険だと判断し、以下の記述を取り消します。

引用は無断でやっても構いませんが、転載は執筆者の許諾が必要になります。

引用と転載の境目を定量的に示すのは難しいのですが、丸写しの割合が記事全体の2割~3割までなら引用、それを超えると転載かなという気がします。

感覚的な基準で言うと、あなたのブログを読んだ人が「おっ、このブログを読んでいったら本を買わずに済むじゃん。ラッキー!」と思うような内容であれば、それは転載にあたると思います。

問題点その2:実はちゃんと理解できていない恐れがある

意図せず無断転載と見なされるのも問題ですが、ブログを書いた本人にとってそれ以上に問題なのは、こっちかもしれません。

これは僕の持論なのですが、技術をちゃんと習得したかどうかの判断基準のひとつは、「その技術を自分の言葉で説明できるかどうか」だと思っています。

逆に言うと、「自分の言葉で説明できていないなら、その技術をちゃんと習得していない恐れがある」ということです。

この話は以前発表で使ったスライドにも載せています。

わかりやすい技術記事を書くための心構えとテクニック / #railsdm 20171206 // Speaker Deck

そもそも本を丸写しするだけなら、誰でも手を動かせば書けます。
本人は勉強したつもりでも、実はちゃんと頭に入っていなかった、というのは困りますよね。
なので、丸写し以外の書き方を実践していく必要があります。

オリジナルなコンテンツを書くためのアイデア

ここまでは少し厳しい話を書きましたが、自分が学んだことをブログにアウトプットすること自体は大変良い習慣です。
ですので、このエントリを読んで「ぎくっ」とした人もブログは続けてほしいと思います😃

では、無断転載にならず、なおかつ自分のためにもなるオリジナルな技術ブログはどのように書けば良いのでしょうか?
個人的にオススメしたい執筆スタイルを以下に挙げてみます。

その1:章単位で内容を要約する

本の内容を右から左へコピーするのではなく、その内容を短くまとめてみましょう。
自分が「ここは重要」と思ったところだけを残し、それ以外の部分を切り捨てると要約が完成します。

たとえば以下のような感じです。

タイトル「プロを目指す人のためのRuby入門・第2章の重要ポイント」


「プロを目指す人のためのRuby入門」の第2章を読み終わりました。個人的に重要だと思った点をピックアップします。


メソッド呼び出しの()は省略できる

# ()を省略しない場合
1.to_s()

# ()を省略する場合
1.to_s

nilとfalseだけが偽で、それ以外は真

# nilとfalseは偽、以下の値はすべて真

# trueそのもの
true

# すべての数値
1
0
-1

# すべての文字列
'true'
'false'
''

メソッドはdefで定義する

def add(a, b)
  a + b
end
add(1, 2) #=> 3

(以下省略)

要約を作っていくときの大事なポイントは「どれだけ情報を捨てられるか」です。
「あれもこれも」と思い始めると結局丸写し(=無断転載)に近づいていってしまいます。
なので、「短くできるほど勝ち」の精神で、必要最小限の内容だけを残し、その他の情報をどんどんそぎ落としていきましょう。

その2:自分の感想を積極的に散りばめる

本を読みながら「この機能は初めて知った!」「今までに使ったプログラミング言語とはここが違う!」と思った部分があれば、その気持ちをブログに散りばめてみましょう。
もしかするとあなたのブログを読んだ他の人も「へえ、そうだったのか」と勉強になるかもしれません。

今まではJavaしか使ったことがありませんでしたが、JavaとRubyではこんなところが違うと思いました。

# 変数名やメソッド名はスネークケースを使う
hello_world = 'Hello, world!'

# メソッド呼び出しの()を省略できる、文の終わりのセミコロンもいらない
foo.bar

# メソッドの戻り値はreturnを使わずに書く
def add(a, b)
  a + b
end

# (以下省略)
その3:自分の言葉で説明してみる

少し前に「自分の言葉で説明できていないなら、その技術をちゃんと習得していない恐れがある」と書きました。
であれば、その反対で「自分が理解した内容を自分の言葉で説明するのが良い」ということになります。

「自分の頭の中ではこんなイメージで理解した」というポイントがあれば、それをブログにアウトプットしてみてください。

たとえば、以下の例ではRubyのunless文に関して、英語のunlessの意味を併記している部分が「本に載っていない独自の説明」に該当します。

Rubyではif文の反対のunless文があります。英語のunlessには「~でない限り」という意味があるので、うまく使えば自然な英文のように読める条件分岐が作れますね。

status = 'error'
# okでない限り、メッセージを表示する
unless status == 'ok'
  '何か異常があります'
end
#=> "何か異常があります"
その4:自分で実験した結果を載せる

本を読みながら「こんなことをしたらどんな動きになるんだろう?」と思った部分があれば、それを実験してみましょう。
そして、その結果をブログに載せてください。
これなら確実にオリジナルなコンテンツになりますね。

Rubyでは"!"や"?"で終わるメソッドを定義できると書いてあったんですが、二つを合わせて"!?"で終わるメソッドは定義できるのか試してみました。

irb(main):001:0* def really!?
irb(main):002:1*   "Hello"
irb(main):003:1> end
SyntaxError: (irb):3: syntax error, unexpected '?', expecting ';' or '\n'
def really!?
            ^
(irb):3: syntax error, unexpected keyword_end, expecting end-of-input
	from /Users/jit/.rbenv/versions/2.4.3/bin/irb:11:in `<main>'

やってみたら構文エラーになりました。"!?"で終わるメソッドは定義できないようです。

まとめ

というわけで、このエントリではブログに技術書の内容を丸写しする問題点と、その改善案を説明してみました。

繰り返しになりますが、ブログに学習内容をアウトプットするのは非常に良い習慣なので、ぜひ続けていってください!
そして、ブログを書く際にはここで紹介したような改善案を実践してみると、さらに本の内容が自分の頭に定着すると思います。

僕も本の筆者として、オリジナルなコンテンツをもった「プロを目指す人のためのRuby入門」に関するブログ記事がたくさん出てくることを楽しみにしています!😄