Blenderチュートリアルをnoteで書きたいときにはここを見よう（？）

えーっとnoteっていう記事かけるところがありますね。ここのサイトのことなんですけど、ここでBlenderチュートリアル書こうって思ったときに特に自身が気をつけたいことをつらつら書き留めていこうっていうページです。

これから時間見つけて加筆する予定のページなので内容の大幅な変更とかも有るかもしれません。

TL;DR

「不完全なBlenderチュートリアル」を書くんだったら「メモ」として公開してしまおう。

…そもそも書くハードル上げてどうすんのさ？

動画チュートリアル全盛の時に「記事を書く」？

Youtubeなどにアップロードされた動画チュートリアル、確かに「百聞は一見に如かず」というところはあると思いますが、検索性だとかそういうところについては記事としてテキストで書かれているものの方が優れています。

また、ビデオチュートリアルだと、間違いの修正が結構な手間となりますが、テキストで書かれている記事だと、問題の場所を差し替える事も比較的容易にできますね。

ちなみに note だけでなく、記事として書けるサイトであればそういう特性は持っています。それぞれいいところをとっていけば良いですね。

なお、google検索等に引っかかりやすいかどうか、という指標の一つとして「サイトそのものの評価」というものがあるので、その辺のレンサバ借りて一から、というのは割と大変かなと思います。その辺は好みで。

Twitter長文/スレッドでは?

Twitterも元々「マイクロブログ」と呼ばれるものでしたし、Twitterに課金したユーザーは140文字制限も取っ払われたのでまあチュートリアルというかTips垂れ流すのも一興、というか。140字制限あっても「スレッド続けて行きますんで」とか書いて複数ツイートする猛者も偶に見かけますね。

ただ、元々の性質からして「ストリーム」というか「旅の恥はかき捨て」のような雰囲気があって、「多少正確じゃなくても押し通してしまえ」がまかり通ってしまいがち(だと自分は思っている)ので、これを一番興味を持っている「Twitterで情報を探している初心者層(=noob?)」には酷なんじゃないかな、という風に感じます。

また、Twitterだと「インスタント知識」的な、「何か役に立ちそうに感じる」というだけの、技術的観点が抜け落ちたモノが生み出され、そしてそれはチュートリアルとしては間違っているものの雰囲気で評価をされがちなので、そういうのにまどわされずに「しっかり書ける技量を持っているなら記事としてちゃんと書きたい」部分ではあります。(とはいえある程度の露出は必要なのでやらない、というところまではいかないでしょう、適材適所というヤツで。)

noteでできることを把握しよう

割と書くプラットフォームって大事ですね。何が出来て何が出来ないのかを把握しておくと「文章をどのような構成で書くか」という対策ができますね。まあなんというか最近の、特にBlogとして使われるようなCMSはそこまで差はないですけどね、って感じ。

まあ、この記事の要旨となる「チュートリアル記事」書くことが前提なわけなんで、そういう用途では多少構造化できたりその辺があると嬉しいのですよね。

• 見出しは 大見出し、小見出し。

• パラグラフ単位でブロックとして管理可能。

• ブロック：箇条書き(ブレット、数字)、1段階のみ

• ブロック：引用(引用文＋引用元表示)

• ブロック：プログラムコード。

• ブロック：Youtube等の埋め込みが可能

• 目次

• インライン： ボールド取り消し線 リンク

• ブロック : 添付ファイル

まあ、箇条書きは2段とかあると本当はやりやすいんだけど、個人的に。まあ文書構造考えなきゃ、とか .md .rst で描きたいとかそういう人は別サービス選択、ですね。

「エディタ（記事編集画面）でできること」参照のこと。

"information:"/"note:"/"warning:" 等のブロックはnoteには存在しないので、引用ブロックを使う感じ。

書いた日付

noteには書いた日付がちゃんと出ますので気にしないで良いです。強いていうなら記事に追記した時に追記した日付についても記載があるといいですね。

リンクを貼った時（埋め込みオブジェクト他）

"https://~"なんかのリンクを貼って[Enter]キーをターンッ、ってやった時にnoteでは自動的に埋め込みブロックとして作られることがあります。OGT画像とかサイトが条件を満たしていればうまい具合にブロックとして表示されますね(たまに通信に失敗してURLのみになった時は再度URL貼り付けてみると良いです)。

また、Youtubeだとプレビューになりますね。割と表示サイズ大きい。

https://www.youtube.com/watch?v=3QAGpxV36wM

これを「さらっとリンクのみ紹介する体」の通常のページリンクと同様な表示のように「タイトル/概要の冒頭＋画像」という形にするにはURLのオプションとして"app=desktop"とか挟んでおくと良いですね。

https://www.youtube.com/watch?app=desktop&v=3QAGpxV36wM

Vimeoもプレビュー対応。

Slide Shareもプレビュー対応。

Twitter上のツイートも。

他に「埋め込み」が可能なサービスについては「テキスト記事に埋め込みできるサービス一覧」という記事があるのでこちら参照いただければ良いと思います。

添付ファイル(.blend)

note記事に直接ファイルの添付ができます。勿論、外部ストレージサービスのリンクでも良いわけですけど。 .blend　ファイルも置けます。他にストレージサービス使っていないとかそういう時に使えそうです。

• ファイルアップロード機能について(note help)

記事に直接添付する場合、1つのファイルでもzip等のアーカイブファイルにしてから添付した方が若干安心感あります。

なお、.blend ファイル、テクスチャ画像等を自身のファイルにembedした形(=ファイルのパック)で配布できるワケなんですが、例えば「textures.comからダウンロードした画像をパックした状態の .blend ファイルの配布はtextures.comの規約違反となる」という事もあるので、ファイルに内包されているファイルも含め、リソースファイルについてはなるべく権利的にクリアになるようアップロード前にチェックしておくことが望ましいと思います。「リソースファイルの入手元サイトの規約はちゃんと読もう」、ですね。

なお、ファイルをダウンロードできるようにした時には、許諾やライセンスについても考慮が必要ですね。

記事の構成・記載すること

記事の構成や記載することとかで気をつけたいことをメモっておきます。

リード

冒頭2~3行分くらいで「この記事の目的は〇〇です。」的な記事の概要などを記載しておきます。

他で(URL埋め込みとして)記事のプレビュー表示として記事冒頭の文が出てくることがあります。ブック一覧のリストでも、ですね。

思ったより意識していない人が多いので、差を付けられるところではあるかなと思います。

Blenderのバージョン・OS

「Blenderのチュートリアル記事を」っていうことでは、割と大事なところ。Blenderってバージョン上がるごとに機能が追加されたり操作が変わったり結構するので。

記事中のスクリーンショット等でバージョンがちゃんとわかるのであれば省略しても良いですけどね。

あとOSで制限がある場合にはそれを記載。これは割と大事。

バニラ or not

Blenderをダウンロードしてすぐの状態を「一つの基準」として、なんの設定が必要か、ということを(別記事としてでもいいので)説明として書いておくと良いですね。

ここでいう「バニラ」は、メニューから Defaults > Load Factory Settings した時と同じ状態、と思ってもらったら良いです。

Blenderだと「バニラ」って実はあまり言わないですね、「デフォルト」の方が多分多数派でしょう。

記事への画像貼り付け

まあ、説明のために画像をペタペタ貼り付けると思いますが、一つのページで大きなファイルをたくさん抱えてしまうことになるので、読み込み時間が大変なことになります。あまりに多いようだったら記事を2つ3つに分割するとかも検討しないとですね。

なお、長くなりそうなチュートリアル記事について、制作の工程として区切りの部分では「画面全体のスクリーンショット」を取得して表示することをおすすめします。どのWorkspace、レイアウトで作業をしているかはできる限り把握しておく必要がありますので。

チュートリアルの粒度

どのくらいのボリュームを想定していて、どの粒度まで説明を加えていくのかを考えて記事を書くと割と「収まりが良い」感じになると思います。

ただ、「ここは重点的に説明しておかないと」っていう部分もあると思うので、バランス考えないとですね。

Add-on 等

Add-on使用が前提となる場合は使用するAdd-onの入手先もリンク貼っておくと良いんじゃないでしょうか。

「パッケージとして同梱で有効になっていないアドオン」とかその辺も記載を割と忘れがちなので気をつけたいですね。自分の場合以下の2つを有効にしていることが多いですね。

• Node Wranglar

• Loop Tools

なお、「パッケージ同梱で有効になっていないアドオン」を「標準アドオン」と呼んでいる方をたまに見かけますが、「標準」というキーワードで端的に説明できていないので使わない方が良いですね。

本文(用語・用法)

割とそこにある違和感を払拭するために気をつけておきたいこと。

マニュアル参照しよう問題

正しい説明かどうか、マニュアルあるので参照して確かめながら記事書いていきたいですね。

「Mayaでいう△△」という言換え的なものはやっていただいても構わないのですが、「ここをキャンプ地とする」的なMayaの用語でBlenderの説明を続ける方は文末で「何と何が対応している」とか、別記事でそういう一覧を書いておいて「言い換えとかはそこ見てね」っていう感じにしておくとビュー数も稼げて、かつわかりやすくなって良いんじゃないでしょうか？使用感とか別ものだとは思いますけどね👻

歴史捏造問題

ものを書く人の中で割と頭の中にストーリーがあって、それを当てはめていく、そういう書き方に慣れている方がやりがちな、文章の中で「辻褄合わせ」をしたり、「自分の都合で」というのが見えてしまうそういうやつ。

「どうせやるなら勝手な解釈をせず、ちゃんと辻褄が合うよう練り上げて出してください」という感じなんですけど、スタミナ不足なのか、割と辻褄を合わせるところまで行ってなくて「これ破綻してんじゃね？」みたいなのを見かけることがあります。そういうのがあると「単に完遂できないチュートリアル」、すなわちゴミ記事として判定される可能性が高くなります。

チュートリアル記事の中で出てくるわかりやすいパターンだと、機能紹介とかその歴史的な部分についての説明をしているときに「明らかな嘘」、または「客観的に見ると嘘になる言葉」がポロッと出て来がちで、結果として歴史捏造的なものを作り上げてしまう。特に時系列の事柄は前後したり、ある物ないものごちゃ混ぜにしやすい、そしてそれはバレやすいので気を付けましょう。

しっかりリサーチしてから、というのが大前提ではあると思うんですけど、気をつけたいところではあります。

変に格式張った(?)用語を使う

単純にちょっとググってみた、とか並べてみたあたりを「研究」とか、一通り動かしてみましたを「検証」とか、ちょっと良く見せよう的な感じで割とカジュアルに使いがちですけども、使う場面選べよ、っていうケースをよく見かけるので気を付けたいところ。

何かしらの権威性を持たせたいとかその辺とリンクするのかもしれないですけど、チュートリアル記事としてはそのあたり必要ないと思いますね。

用語のアップデート

Blenderのコマンド名等、用語はバージョンアップのタイミングで変わることがあります。合わせて自身の知識もアップデートしましょう。

ちなみに最近のチュートリアル記事や動画でも 2.79以前の用語で説明されているものが出てきたりしています。ちなみに2.80のリリース日は2019/7/30。お前いつ時代の化石やねん？って言われちゃいますね。

• [旧](画面上部)Infoウィンドウ -> [新]トップバー (infoエディタは別の場所に存在します)

• [旧]プロパティパネル -> [新]サイドバー

記事を見るのはそういうことを知らない人かもしれないので、「説明している用語が画面と異なるだけで大混乱」というのは覚えておきましょう。

新しい言葉は作らない

割と書いているうちに「〇〇を△△することを『⬜︎⬜︎』って書いちゃえ」とか「普段自分は『⬜︎⬜︎』って呼んでいるので、それで」みたいなことはあると思います。ちょい、と調べると全然別の語でした、っていうパターン。

先にマニュアルとか色々あたってからそう考える、という方が「文章を作る誠実さ」として読者が受ける印象が大きい気がします。

「記事中では便宜的にそう呼ぶことにします」っていうのできちんと説明されているのであれば話は変わってくると思いますけどね。

それでも足りなきゃ作ればいいよ、知らんけど。

「分かりやすい」を考える

例えば「法線方向が正」と「面が表を向いている」どちらが「分かりやすい」ですか？という問い。

そういう問いに対していずれかの選択肢を回答する前に、「基準は？」とかコンテキストを考えたら変わるかもよっていうのは頭の中に入れておきたいですね。

その他

なんか全部「講座」とか「チュートリアル」とか言ってる

「Blenderについて説明しますね」がひとまとめで「〜講座」とか「〜チュートリアル」とかそういうタイトルになっているとかよく見かけます。

使い方が乱暴すぎる感じがしますね。

「〇〇てみた」は「チュートリアル」にはなりません。

機能だとかその機能のオプションの説明だとかを並べているものは「チュートリアル」とは別、と考えたほうが良いです。

「初心者向け」

あーこれ完全に悪口になっちゃってますけど、Blenderで、かつ日本語の「初心者向け」として説明する場合、行う操作を単純に「AをBするとCになります」の説明しかしないものが大多数になっています(チュートリアル動画含め)。分量的にこれからやることのいちいちの操作を説明するだけに終始せざるを得ないとかそういうこともあるかもしれません。

「AをBするとCになります」の説明で終始するチュートリアルについて、読んで(見て)いくと、「えっそれ何のためにやるの？」っていう疑問が割と湧いてきます。しかし、実のところチュートリアルを作った、説明している当人もわからなかったりすることがあります。「いつもそういう風にやっているから」…信じられないと思いますけど。

実際の制作だと試行錯誤しているはずで、「AをCにするためにBします」「Cにする方法ってBだけ？他には？」とか割と色々考えているはずなんですけど、「初心者向けだし」っていうことで色々端折られてしまうのは想像できます。

なんかのパクり

しれっとパクるようなことはせずに、オリジナルをURLなど付けて紹介するのは最低限のマナー、ではないかなと言っておきます。インスピレーションを得た、とかそういうのでもやっぱりソース元の紹介はしておきたいですね。まあ「昔見たけどどこで見たかはっきりしない」っていうケースもあると思うのでなんとも言えないですけど。

まあ、「記事を書くカロリーを節約するために」海外のチュートリアルを劣化パクリ的な感じで記事にしているのを見ると頭痛くなってきます。自分がやらないか、というとそうでもありませんけど、常習的にやるのはちょっと…ね。

動画でもそうですね…たまたま一致したのかもしれないですけど、「ああ、この人は黙ってパクる人なんだ」って以降見られちゃうんですね…。

なお、「素晴らしいチュートリアルを見つけたので解説させてください」という記事は、その記事自身はチュートリアルとはならないですね。

「英語チュートリアルをを日本語にしてみました」だとかは「翻訳記事」の位置付けになりますね。ただし、割と厳格に元記事に従った内容であることを求められます（し、原作者から掲載の許諾は得ておくべきです)。

「二次創作」なのか「フェアユースの拡大解釈なのか」

「有名なキャラを自分でも作りたい」かつ「それをチュートリアルとして見てもらいたい」という結果出来上がったチュートリアルの場合に、これらは大体の場合「二次創作」にあたります。

あれですね、アレ。「著作権」とかいうやつ。元々そのキャラ作った人や権利を管理している団体、企業が「それはダメー！」って言った場合に色々削除したり対応に追われる感じのやつですね。作った瞬間からそれを意識しないといかんやつ。

無料のチュートリアルだろうが、有料のチュートリアルだろうが、Youtubeで収益化されていようがいまいがそこは何の判断基準にもなりはしません。権利者がOKと言うかですね。消されてないのはたまたま怒られていないから、ですね。

二次創作のガイドラインが提示されていてそれに従っていれば…とか、そういうケースはあるにはあるのですが、割と厳密に従う必要があって。

例えば「ゲームプレイ等の画像の投稿はガイドラインに従う場合にのみ許諾される」ケースはあっても、二次創作についてはその限りではない、というFrom Softwareなど、個々に条件が違ったりするので、ライセンス関連についてはそれぞれ確認が必要になりますね。

そういえばこれなんかどうなんだろう？個人的には「出る」って聞いたときに変にドキドキした記憶があります。

そして、国が違うとその辺の話も変わって来て、「フェアユース」というものがあって、ざっくり言うと「用途によっては原作者に断りなくコンテンツを利用できる」という。そしてこれを独自に「ダメって書いてなかったから使って良いものなんですよね」くらいにガバガバかつ自分の都合の良い解釈(or反論)している人もいて、一部ではなかなかに香ばしい感じに仕上がっている(?)様子。ここは日本ですよー、って気づいておけばそんな「フェアユースの独自解釈」みたいなものはされないですね。

「チュートリアル作ってみよっかな」っていう人で「どこかのIP勝手に使う」とか意識しないかもしれませんね、「とにかくネズミーに手を出すとやべえ」くらいしか情報仕入れてないとか「明らかに認識が足りない」ケースもね。

なお、「お国が違う」と企業でもこんな感じ。割とこれらのチュートリアルコースに手を出した人たちはそれが「許諾をすでに得ているもの」または「そのキャラは自由に使っていい」という風な間違った認識をされる可能性があると思います。仮に国内の同種のサイトだとこれらのコースNG判定受けるはず。

チュートリアル作る側の人少しは気を付けましょうよ？っていう勢いなので、そこに引っ張られないようにしないと、ですね。

プラットフォームのルール

noteというプラットフォーム使っているので、ルールに従って記事を書きましょう、でなければBANされても知りませんよ？っていうトコロ。「チュートリアルがエロい必然性」は多分無い、と思う。

あと決済がらみでクレジットカード会社とかの意向をもとにした「規制」みたいなものもあるので。

動画のスクショ並べました系

動画のスクショ並べる系も避けたいですね。悪い例のURLを直接貼り付けたりすると角が立ちまくって仕方がないので、「動画のスクショを貼り付けた記事」の例として以下を。

この記事では「動画にまつわるエピソード」が伝えたい内容で、そこへの導入として動画のダイジェストとして画像が出てくる感じですね。まあ、さっと消費する分にはこう言ったスタイルも許容できますね、って感じです。

ただこれをチュートリアルの紹介記事でやろうとするとなかなか構成が難しいのではないかと思います。だってチュートリアル動画そのものが「伝えたい内容」ですからね。どうやって書いても記事自体が大きく価値を付加できるとは思えないですね。だったら一文「動画見て！！」で良いじゃないですか？

まあ、こんな感じのスタイルで紹介されたチュートリアル(?)記事もあって、そこに書く側のエゴが乗った勘違いな文章が追加で載っかったのを見せられたりするとそれはもう…。

一通り動かしてみる

自身がこれまでやってきたことをベースにチュートリアル記事書いていくことになるとは思うんですけど、やりがちなのが「手順として省略された記事を書いてしまう」ということ。

まあ「省略するよ」って一言書いとけば問題ありませんね(キリッ

必要な次の手順が出てこなくて次に進めないとか、そういうのは避けたいですね。

実際に自分が書いた手順で再現できるか、公開前に記事の手順の通りなぞってみるだけでもしておいた方が良いですね。

"Blender"のロゴマーク

3DCGソフトウェアである"Blender"はヨーロッパおよびアメリカで商標登録されていて、以下のページとか確認できるところがありますね。

そして、blender.org には以下のような記載があり、ロゴ使用ガイドラインが存在します。

®︎がちゃんとついてますね、よく見ると。

また、ユーザーがチュートリアル等で「Blender使ってますよ」という際に利用できる「コミュニティバッヂ」というものが別途用意されているのでこれを使いましょうね、っていうことになっています。その辺は以前書いた記事もありますのでそちら参照ください。

Blender Foundation として非営利団体として登記もされていますね。 「どこぞの馬の骨」じゃないので使う側もきちんとしておくのが望ましいですね。

「スキ」もらうとかバズるとか

まあ書いた労力が何かしらの形で報われるとか、後につながるとかあれば良いかな、とは思うわけですよ。わかりやすい形で、というと「スキ」もらうとかバズるとか。

割とその辺は、「この人はこう言う方面についての記事書かれてますね」っていう認知がされていることと記事の有用さの相乗効果、という気がしないでもないです。

例えば記事書いたら他のSNSに「書きました」くらいの体でURL貼り付けておくとか多少の宣伝はすれば効果あると思いますけど、体感上バズるとか割と運任せな感じがするので「よくわかんない」というのが今のところ自身がわかっていることになります。

(間違ってたら)適度に更新

公開した後に更新できるメディアでもあるので、間違った記載があった場合にはしれっと修正しておけば良いですね。

「記事を正しく維持し続けること」か、「その当時のことをコンテンツとして保持」か、ここではチュートリアル記事について書いているので当然前者に重きを置くべきですね。

Blenderの場合、バージョンが違うと操作がちがう、ということは割とあるので、柔軟に記事の修正をしていけば良いと思います。

「更新した後で見つけた」という場合には"[追記]"と行頭に入れておいたり、追記日付記載したりとかしておくとポイント高そうですね。