「図表をふんだんに使う」「酔っ払いでもわかるように」 mpyw＆無職やめ太郎が語るQiita執筆のこだわり

自己紹介

司会者：最後は株式会社ゆめみによるセッションです。タイトルは「mpyw＆無職やめ太郎が語る『Qiitaはこう書く』」です。それではお二方よろしくお願いします。

mpyw氏（以下、mpyw）：お願いします。

無職やめ太郎氏（以下、無職やめ太郎）：お願いします。

mpyw：では、自分から始めます。ゆめみ所属のmpywと書いてまっぴーこと、石橋と言います。「どれが本名なんだ」となるかもしれません（笑）。ちょっとややこしい名前になっています。少し固めの内容が続いてきたと思うので、最後は初心者向けのトークセッション、軽めの形式で締めたいと思っています。

巷でTwitter芸人とかQiita芸人とかいろいろ言われているのですが、この2人でお話していくので、何卒よろしくお願いします。内容は初心者向けになるので、Qiita熟練者は初心者の頃の気持ちを思い出しながら聞いてみてください。

私は、PHPテックリードという職域を現在担当しています。専門分野はLaravelで、関連OSSをいくつかメンテナンスしています。Laravelに関しては、Qiitaの記事でも過去にいろいろと投稿しています。自分に関してはこんな感じです。やめ太郎さんお願いします。

無職やめ太郎：はい。私も同じく株式会社ゆめみに所属の無職やめ太郎と言います。ふだんQiitaでは、主に関西型言語を用いた記事を投稿しています。本日はよろしくお願いします。

mpyw：関西型なんですね（笑）

無職やめ太郎：関西弁の漫才のような記事を書いているだけで、それをカッコよく言っただけです。

mpyw：俺も使っていこう（笑）（スライドに）関西型言語で漫才のようなイラストを貼っていますが、こんな感じで（笑）

Qiitaとの出会い

mpyw：ではメイントピックに行かせてもらいます。Qiitaとの出会いですが、自分はQiita歴がまだ10年ぐらいです。プログラミング学習において、最初は参考書ベースに進めていましたが、プログラミング言語の細かいところに興味関心が向くようになりました。

そういうことを調べていると、参考書だと絶対に教えてくれない情報ばかりで、いざインターネットの情報を見に行っても、探しても見つからないことが頻発していました。こういう不満を抱えていたところで、自分がこれをまとめないといけないという気持ちになって、ちょうどいいところで見つけたのがQiitaでした。

何か発見があるたびにひたすらQiitaに書いていくことを繰り返していたら、Qiitaというサービスを好きになっていった過去があります。やめ太郎さんお願いします。

無職やめ太郎：はい。mpywさんはQiita歴がだいぶ長いと思うのですが、僕の場合はQiita歴はまだ3年ぐらいです。僕がプログラミングを勉強している中で、検索したら「またこのサイトが出てきた」みたいな感じでQiitaが出てきて、「技術投稿サイトと言えばQiitaでしょ」という感じだったので、自然に、当たり前に出会った感じです。

mpyw：意外と自分はアーリーアダプターだったことを今知って、感慨深いところがあります。

無職やめ太郎：僕からするとそんなイメージですね。mpywさんは昔から活躍されているイメージです。

mpyw：ありがとうございます。

無職やめ太郎：では次行きますか。

思い出深い記事

mpyw：個人的に思い出深い記事ということで、懐古厨みたいになってしまいますが。こんな感じでいろいろ書いています。

思い出に残っているものを大雑把に挙げると、PHPの挙動をめちゃくちゃ細かく調べるシリーズで、ファイルアップロードとかの例外処理などのところ。公式のマニュアルだと、けっこう手抜きのところがあったりするんです。場合によっては（公式の）コードを書いてプロダクションに放ってしまうと、エラーや脆弱性が生まれてしまう懸念がありました。

自分はちょっと神経質なところがあって、網羅性が100パーセントじゃないと（気が）すまない。「こういう時はこうする」ということを、考えられるすべての場合に対応していないといけないという気持ちがありました。

今思うとちょっとやりすぎな部分がありましたが、バックエンドエンジニアが持つ適性としては間違っていなかったと思います。そんな感じのことをひたすら書いています。

無職やめ太郎：すごいですね。僕も個人的に思い出深い記事について話します。僕は初めて書いたQiita記事が思い出深いです。オブジェクト指向みたいなものがその頃のQiitaでバズっていて。

「自分が書いたらおもしろくて、わかりやすくてめちゃくちゃバズるぞ！」と根拠のない自信を持って、初投稿から会話調で「ワイ〇〇や」みたいな記事を書いたのですが、その記事にはまったくいいねがつきませんでした。

mpyw：（笑）

無職やめ太郎：ありがたいことに、5いいねぐらいはもらえたのですが。

mpyw：苦い思い出ですね。

無職やめ太郎：すごく悲しかったのが思い出深いです。

mpyw：でも迂闊にOOP（Object-Oriented Programming）についてしゃべってバズってしまうと、至るところから鉞が飛んできて痛い目を見るのは容易に想像がつくので（笑）。

無職やめ太郎：確かに（笑）

mpyw：結果的にはよかったですね（笑）

無職やめ太郎：なるほど。よかったのかもしれません。

Qiitaを書くときに意識していること：読者ターゲット

mpyw：では次に行きますか。メイントピックの「Qiitaはこう書く」というところに踏み込んでいきたいと思います。まず、読者ターゲットを設定しているかという観点で自分の記事の書き方を説明すると、中級者レベルをベースラインにおいています。あくまでそれをベースにして、いかに上下に広げられるかを最大限努力するようにしています。

ここでいうレベルは相対的なもので、自分がどの位置かはあまり気にせずに、自分よりもわかっていない人と、自分よりも知識を持っている人のどちらに対してもおもしろい情報を提供できる、という視点で考えるといいと思います。

まず、いかに初心者がついてきやすいように書くかという観点だと、当たり前のことですが、初心者は論文のようにダラダラ書かれた文章は絶対に読みたくありません。読む気が失せます。

ファーストインプレッションがそれなので、まずそこのハードルをどう超えるかという観点で言うと、一番手っ取り早いのが、図表をふんだんに使うことです。文字よりもイラストや表で、「これに対応するのはこれ」などの対応関係や箇条書きがあると、けっこうわかりやすいかなというところです。

そして、覚えるだけではなく、理解してもらうことが目的の場合は、「最低限ここまで理解してくれたら一般的には問題ないレベルだよ」という感じで、最初に全部詰め込むことを強制せずに、「このあたりまで到達したらOKだよ」と安心感も与えられることも、大事な観点になってくるかと思います。初心者目線の場合は、自分はこんな感じで考えています。

無職やめ太郎：ありがとうございます。僕は読者ターゲットはきちんとは意識していません。僕自身は文章を読むのが苦手で、アホでも読める記事があればいいのにといつも思っています。アホでもわかりやすい記事を意識しているので、そういう意味で言うと、読者ターゲットはアホな人かもしれないですね。

mpyw：アホな人（笑）

無職やめ太郎：あと、自分はQiitaの技術記事をお酒を飲みながら読んだりするので、酔っぱらっていても読めるぐらい、頭にするすると入ってくる記事を書けたらいいなというのもあります。そういう意味でいうと、読者ターゲットはアホと酔っ払いかもしれないですね。

mpyw：酔っ払いがついてくるんですね（笑）。先ほど自分は初心者について言わせてもらいましたが、上級者についても言わせてもらいたいと思います。上級者は初心者と逆で、公式マニュアルの情報を転写したりしているだけでは一歩足りない「絶対に物足りなくさせてしまうという問題点があります。

そこでどうすればいいかというと、実際にそのコードを書いた人だけが踏んでしまう、エアプしているだけではわからないような、細かすぎて伝わらないハマりポイントなどを、詳しく書きすぎない範囲でそれとなくおまけ要素としてつけておくと、記事の独自性が出て、なかなかおもしろい記事になるのではないかということです。

無職やめ太郎：確かに。

mpyw：そして、さらに意見が分かれるようなテーマの場合は、「自分は最終的にどちらの意見も支持します」ということを根拠とともに示すと、同じような記事が複数出てきたとしても、統計的に価値がある情報としてインターネットに残ると思います。

無職やめ太郎：けっこう考えて書かれているんですね。

mpyw：そんなには考えていないのですが、今回のセッションのために、「いざ自分が記事を書く時はどう書いているの？」と考えた結果、実はけっこう考えていたことがわかったという経緯です。

無職やめ太郎：なるほどです。ありがとうございます。

Qiitaを書くときに意識していること：執筆の順番・構成

mpyw：次に、記事の構成や書く順番について話していきたいと思います。大きく3つぐらいあるのですが、自分が書いている単発記事についてしゃべっていきたいと思います。よくある記事として、最初に問題で何かしらハマったことと、それに対して「こうすればいいよ」という解答です。大枠の2つを占める記事が一番書きやすいということで、多くの場合に有効だと思います。

ここにどうやって足していくかという流れですが、問題と解答があって、頭の部分に、問題に至るまでの背景をつけます。いきなり問題に遭遇したわけではなくて、何か手を動かしていたらいろいろとうまくいかなくなって、「ここがこうだったよ」という何かしらの背景があると思います。記事を読む時に（背景があることで）、唐突に問題が始まるよりはとっつきやすいメリットがあると思います。

そして後ろに解答です。単純に「こうすればいいよ」と終わりにするのではなくて、それにちょっと肉づけをするような解答の補足を入れて、4部構成。この時点でけっこう肉づけができてくるのではないかと思います。最後に、長すぎるから読まねえよみたいなTL;DR（Too Long, Didn't Read）を前に置いたまとめを書き、締めてあげる。

そうすると、ぜんぜん内容を読まないような人でも、最初のほうだけを見てその内容をだいたいわかってくれるし、長い記事をずっと読んでいて内容を忘れてしまった時に、最後にまとめを見て「こういう記事だったな」というのを頭の中で整理できるので、記事としてはけっこう完成度が高くなると思います。

無職やめ太郎：確かに。やっぱり何か背景があって、問題があって、困りごとがあってそれを解決してくれる記事は僕も好きですね。

mpyw：そうですね。これは有益というか、作るモチベーションが上がる記事だと思います。

無職やめ太郎：単発ネタ記事の場合はそんな感じの順番ですね。

mpyw：次は、単発ネタ記事の派生ではありますが、説明や整理が主体になる記事です。これは、大きい主題があるわけではないけれど、自分が遭遇したように「PHPのマニュアルを見ているけれどあまり詳しい情報がなくて、自分が調べて表にまとめるしかない」という時に、「こういう場合はこの結果になる」「こういう場合はこの結果になる」ということをひたすら苦行のように全部しらみつぶしに調べていって、それをうまくまとめる場合です。

これはケースバイケースで、すべてこのとおりにやっていい記事ができるかは難しい部分がありますが、必要性を感じたらその都度投稿していく感じでいいかなと思います。

無職やめ太郎：なるほど。ゆめみの社内のSlackでもmpywさんの記事は「この記事よかった」「この記事に助けられた」みたいなことをけっこう見かけるので、そういう意味では、先ほど言っていた読者ターゲットとなる中級者にバチバチ刺さっているなと思って見ていたりします。

mpyw：うれしい話です。ありがとうございます。最後になりますが、会話形式の記事で、これに関しては自分の専門外なので、プロフェッショナルとして無職やめ太郎さんに語ってもらいたいと思います。

無職やめ太郎：ありがとうございます。僕は最近会話形式の記事をよく書いているのですが、もともとは会話形式というよりは、“ワイ”という人が1人だけ登場する、独り言形式みたいな記事を書いていました。

なぜそれを書き始めたかと言うと、例えばプログラミングを勉強している中で、わからないことがあった時に公式ドキュメントなどを読んでみる。でもドキュメントだけを見ても「この場合はどうなんだろう」という疑問がけっこう残ったりしていました。

でも、手を動かしていくと、だんだん理解できてくるんですね。最初は「この技術は何のためにあるんだろう」と思っていたものが、「もしかしてこういう時に役に立つんだろうか」「こういう時に使えばええんや！　理解できた！」というように、だんだんステップアップして、自分が理解していったそのプロセスをワイ君に独り言で語ってもらえば、読者も僕が理解したプロセスを追体験できて、同じように理解に到達できるのではないかと考えて、独り言形式の記事を書き始めたのが最初でした。

mpyw：そこから登場人物が増えて、娘さんが出てきますよね。

無職やめ太郎：そうでしたね（笑）。娘さんが出てきたのは、下世話な話なのですが、やはりタイトルが強いとけっこう読んでもらえるかなというのがあって。タイトルを「3歳娘『パパ、関数をカリー化して？』」としてみたり。

mpyw：絶対に言わないでしょ（笑）

無職やめ太郎：そのタイトルが降りてきた時はちょっと震えましたね。

mpyw：天才ですね。文豪ですよ、これは（笑）

（次回に続く）