アーカイブ動画

ピクシブうさみけんた氏が語る、技術発信の信頼性を高めるポイント

ピクシブ株式会社　うさみけんた氏

最初に登壇したうさみ氏は「ピクシブ百科事典」をはじめ、ピクシブのPHPで書かれているWebサービスを開発するエンジニアだ。Emacs LisperやPHPerとして、個人的にEmacs PHP Modeを開発している。PHPerKaigiコアスタッフとしても活動しており、昨年はPHPカンファレンス実行委員も務めた。

うさみ氏は技術記事を書き始めて10年経つが、最初の頃は環境構築やカスタマイズ、自分で工夫した点、教えてもらった技術知識をブログにまとめたていた。原動力となったのは、Webで調べても断片的な情報しか出てこない技術を、体系的にまとめたいという思いである。しかし、Web上の情報には誤情報や中途半端な情報も少なくない。

「誤った情報の伝播は、より適切な発信をすることでしか止められない。自分でやるしかないと思いました」（うさみ氏）

技術発信の信頼性を高めるには誤情報をできる限りなくすこと。うさみ氏は、間違った技術発信をしないためのポイントとその対処法について解説した。

Point１：情報をインプットしているときに誤情報を見つけたら

誤情報には単純な誤字やタイプミス、リンクミスなど、誰でも気づけるものと、著書と同党の知識がないと指摘できないものがある。また、時間的な変化によって事情が変わってしまうこともある。

「例えば、Qiitaで見つけた誤情報であれば、編集リクエストを送って指摘します。著者の事実誤認に基づいた記述については、コメント欄やSNSに書き込むことで知らせてあげましょう」（うさみ氏）

Point２：単純な誤記・タイプミス・リンクミスを減らす工夫

記事公開前に自身できちんとチェックすることはもちろんだが、第三者（友人・知人・職場の同僚など）にチェックしてもらうと安心だ。さらにうさみ氏は、友人が開発しているというAI校正ツール『Shodo』も紹介した。

Point３：著者の事実誤認に基づいた記述を防ぐ方法

「対象の知識についてマスターする」は完全な対策にはならない。その分野の専門家であっても、間違った内容が入ってしまうこともあるからだ。そこでうさみ氏は、普遍的な正しさを語るのではなく、「このコードは私の環境のPHP5.4ではこう動く」というように局所的に行うことが一つの手だとアドバイスしている。

Point４：信頼できる情報源を活用する

技術情報を書くときは、公式マニュアルや標準仕様などを活用するなど、信頼性のあるソースをベースにすることが大事である。例えば、Mozillaの公式サイト「MDN Web Docs」では、HTML/JavaScript/CSSなどに関して、網羅的な情報が提供されている。

PHPマニュアル、Pythonドキュメント、Rubyリファレンスマニュアルなどもお勧めだ。また、GitHubでそのソースコードを直接参照することも手だという。

Point５：固有名詞や専門用語、言葉の使い方に気を配る

例えばテクノロジー用語であれば、PHPやRuby、JavaScriptというように、「大文字小文字を正しく使うこと」が重要だ。そして、記事の文体にも気を配ること。「です・ます調」「だ・である調」「カジュアルなくだけた感じの文体」など、自分の書きやすい文体で記事全体を統一して書くことも大事なことである。

Point６：コードが動くかどうかを確かめる

コードが動くか確かめるために、全てのOSや複数の言語処理系をインストールするのは現実的に難しい。そこでうさみ氏がお勧めするのが、オンラインのサンドボックスやDockerでの環境構築を活用することだ。

Point７：初心者におすすめしたい発信のコツ

初心者が何から発信を始めればよいのか。うさみ氏は改めて「そもそも正しい・間違いという枠に収まらない発信から始めること」と語る。例えば、インストールや作業ログ、勉強会・イベント、カンファレンスに参加した感想、自分なりのこだわりについてまとめることである。

だが、書きたいネタについてすでに他の人が記事にしているケースもあるだろう。その場合は、自分なりのこだわりなどを付け加えて書くことで、オリジナルな価値を提供できる。

「個人的には大事なことは誰が何回書いてもいいと思っているので、どんどんチャレンジしてください」（うさみ氏）

LINEのuhyo氏が語る、技術記事を好き勝手に書く流儀とは

LINE株式会社 uhyo氏

LINEでフロントエンジニアとして活躍するuhyo氏。TypeScriptとReactを専門としている。TypeScript好きが高じて『プロを目指す人のためのTypeScript入門』を執筆。現在、好評発売中である。

uhyo氏が技術記事を書き始めたのは、2018年頃。当時はタイトルで煽る記事が流行っており、「タイトルで煽っているのに内容が有益だとウケるのでは？」と記事を書き始め、今まで記事を書き続けている。

uhyo氏の記事の中で最もウケた記事が「Typescriptの型入門」。2019年にQiitaで書かれた記事である。ウケポイントは入門なのにあらゆる型を網羅していること。uhyo氏の中でベストヒットだったのだそう。

技術記事を書くと何がいいのかについて、uhyo氏は2つの側面があると語る。

「一つは仕様書やドキュメントを見直しながら、読みやすいように整理することで、書く力の向上に繋がります。もう一つは記事を通してコミュニティに価値を提供できること。コミュニティでの知名度、信頼を得ることもできます」（uhyo氏）

とはいえ、間違った内容を書いてしまうと叩かれるのでは…という怖さが頭をよぎる。間違った内容の記事は、コミュニティに負の価値を与えてしまうからだ。だから批判が来ることは避けられない。間違った記事を出した場合は、その記事を訂正することが重要だ。

「コミュニティへの価値提供の観点では、良い記事を書くのと同じぐらい、間違った記事の訂正は重要です」（uhyo氏）

だが初心者の場合、コミュニティに正の価値を与える記事を書くのはハードルが高い。uhyo氏は「コミュニティに正の価値を与える記事ではなく、記事を書くことで自分自身が価値を得ることに集中した方が良い」とアドバイスする。

「最初は±ゼロを目指して、自分の成長やフィードバックを狙う記事を書く。そして成長したら得意分野で価値の創出を試みましょう」（uhyo氏）

間違いを書くことを恐れる初心者に向けて、uhyo氏がアドバイスするのは正しさを前提とする「防御呪文」の活用だ。その一つが記事の冒頭に「以下の内容には誤りが含まれる可能性があります」という一文を記載することである。

文末に「と思います」を使うのも一つの手だ。記述内容が書き手の推測や意見であることを示すことができるからだ。しかも「Xと思われたようですが、Yではないでしょうか」というように、非攻撃的なアドバイスやフィードバックを受けられるようになるという。

uhyo氏自身も記事執筆時に気をつけているのは、とにかく「正しさ」だという。この正しさには情報の正しさだけではなく、「論理的推論の正しさ」も含まれる。逆に言えば、「正しささえ担保すれば、技術記事は好き勝手に書いていい」と、uhyo氏は言い切る。

もう一つは、記事の前提を書くことである。論理展開が正しくても、前提が異なると読み手は納得しないからだ。

最後にuhyo氏は、技術記事を書くための３つのステップアップシナリオを紹介した。

1. 練習期
2. 信頼向上期
3. 思想発信期

練習期では、無理に「正の価値」を提供しようとせずに、記事執筆の練習と自身の技術力向上に努める。防御呪文を駆使しながら、記事を書くことがお勧めだ。そして慣れてきたら、記事の新規性を導入して、正の価値をコミュニティに提供していくのである。

信頼向上期では、新規性を追求する。新規性にはいろいろ種類がある。例えば、「わかりやすさを追求する」「将来役立つ最新情報を提供する」「マニアックな情報を提供する」「まだ日本語になっていない情報を翻訳する」などである。だが、上級者はすでに情報を持っていることが多く、知識だけ提供しても響かないこともある。

「上級者を感心させるには知見・考察・思想など、事実を超える内容が必要となります」（uhyo氏）

思想発信期においては、自分の思想を広めることが重要となる。信頼向上期で信頼を溜めておくことをベースに、人を納得させられる内容を発信することも必要になる。記事の前提となる事実を定め、これまでの経験を活かして、正しい論理展開で結論を導いていくことだ。

思想を発信して認められるようになると、かなり好き勝手に書けるようになると、uhyo氏は太鼓判を押し、セッションをまとめた。

ゆめみ 無職やめ太郎氏が語る「技術記事を書くメリットって？」

株式会社ゆめみ 無職やめ太郎（本名）氏

無職やめ太郎（本名）（以下、無職やめ太郎）氏はゆめみのフロントエンドエンジニアとして活躍しつつ、関西型言語を用いた技術記事をQiitaにて執筆している。セッションの導入は、無職やめ太郎氏の人気コラム「パパと娘の会話」スタイルで進められた。

今回の登場人物は娘ではなく、21年新卒でフルサイクルエンジニアとしてゆめみに入社した後輩エンジニアのふわせぐ氏。ふわせぐ氏は。組織の問題を技術で解決するコーポレートエンジニアとして活躍している。せっかくなので、無職やめ太郎氏のひとり芝居で語られた会話を再現してみよう。

ワイ「技術記事を書くことって、とっても意味のあることやと思わへん？」

ふわせぐ「そんなに意味あるんすか」

ワイ「いやあるがな。プログラミングについて自分が学んだことを、人に読んでもらうための文章としてまとめ上げることになるやん。その過程で自分の知識の曖昧な部分が浮き彫りになってきて、もう1回調べ直したりすることになるんや。そして自分自身が学び直す機会になり、より理解が深まる。ワイはそう思う」

ふわせぐ「それって、あなたの感想ですよね」

ワイ「いやワイだけの感想とちゃうで。Twitterでも記事を書くことで理解が深まるっていうてる人見たことあるで」

ふわせぐ「技術記事を書くことで理解が深まるっていう意見と、技術記事を書かなくても理解を深められるっていう意見は、Twitterでは何対何くらいの割合なんすか」

ワイ「そういうデータはないけど、考えたらわかるやろ。人に説明しようとすることで理解が深まるに決まってんねん」

ふわせぐ「嘘つくのやめてもらっていいすか。だってやめ太郎さんの記事、たまに内容が間違っていることありますよね。あと僕の周りにもエンジニアってたくさんいるんですけど、技術記事を書いてなくても、強強（ツヨツヨ）のエンジニアってたくさんいるんですよ。

記事を書かない分、その時間を使って新しい技術を学んだり、実際に手を動かしてコードを書いてみたり、そうやって理解を深めていくこともできると思うんですよ。

なので、技術記事を書くことこそ正義、みたいな言い方をする人っていうのは、もともと技術記事を書くのが好きだったり、得意だったりして、そういうポジショントークをしたいとか、もしくは頭が悪い人か、そのどちらかだと思います」

ワイ「ぐぬぬ…」

完全に論破されたやめ太郎氏。果たして技術記事を書くことに意味はないのだろうか。

その晩、やめ太郎はこんなひとりごとをつぶやき続ける。

ワイ「ふわせぐ君に完全に論破されてもーた。でも、技術記事を書くことに意味はあるはず。いろいろなメリットがあるはずなんや。だって、ワイは技術記事を書いたことがきっかけで今の会社の同僚と知り合い、面接を受けて、転職することができた。

せやから、ワイの就活には役立ったし、逆にワイがエンジニア面接官をやっているときにも、技術記事のメリットをすごく感じるんや。弊社に応募してくれたエンジニアさんの履歴書を見たときに、その人の書いた技術記事のURLがあると、すごく助かる。

その技術記事を読むことで、この人はこんな技術に興味があるんやな、プログラミングについてこんな考え方をしている人なんやな、技術についての説明がうまい人やな、そういうエンジニアとしての人となりがバシバシ伝わってくるんよ」

ワイ「逆に記事がなかった場合は、一時間の面接でその人のことを知ろうとする。面接なんて、応募者さんもむっちゃ緊張してはるんやろうから、応募企業に対して自分の魅力を伝えるなんてかなり難しいことやと思う。せやから技術記事は、応募者さんの最高のポートフォリオになる」

ワイ「やっぱり技術記事を書くことには意味がある！」

といったかんじで、「技術記事は別に書かなくてもいいけど、就職活動や転職活動をする時のポートフォリオとして使える」と、確信したやめ太郎氏。では、継続して技術記事を書くにはどうすればよいのだろうか。

実はやめ太郎氏自身、プログラミングを始めた頃は「技術記事なんて書けるわけがないと思っていた」と、振り返る。なぜなら、そういうものはツヨツヨなエンジニアが書くものだと思っていたから。

しかも「幼い頃から本を読むのが苦手で、文章力もないし、小学校の頃の作文はおかんに書いてもらっていた」という。だから、プログラミングという難しいテーマで記事を書くことは絶対に無理だと思っていたのだ。

そんなやめ太郎氏に転機が訪れる。35歳の時に無職となり、次の仕事を探そうとしたものの、自分の経歴が貧弱だと気づく。そこで、自身の強みを伝えるポートフォリオを作るべく、技術記事を書くことにチャレンジすることにしたのだ。

だが、技術記事を継続して書くことは難しい。そこで思いついたのが、プログラミングについて勉強したときの話を、ひとりごと形式で書くやり方だったという。それが、先ほども紹介した会話スタイルの文章に、挿絵も入れたコラム形式である。

まず、ワイ「○○って技術の勉強をしてみよっか」という文言から始まり、「わからんなあ」「わかりそうや」「わかった！」という流れで、起こったことをそのまま書いていく。登場人物を増やして掛け合いをさせることもある。

このスタイルは書きやすいだけではなく、主人公の気持ちになって読み進められる。没入感の高さだけではない。ワイが経験したプロセスをもとに、理解にたどり着くこともできる。

「継続して技術発信するコツは、できるだけ自分にとって書きやすい書き方とやり方を見つけること。もしみつからなければ、ワイ記法を真似していただいても全然OKです」（やめ太郎氏）

最後にやめ太郎氏は、「日々学んだことをTwitterに書き、溜まってきたら記事としてまとめることも継続的に技術発信する方法の一つ」と紹介し、セッションを締めた。

盛り上がったパネルディスカッション。技術記事で独自性はどう築く？

続いては、Q&Aを含めたパネルディスカッション。やめ太郎氏のひとり芝居にも登場したふわせぐ氏がファシリテーターを務めた。ちなみに、ふわせぐ氏は今回が人生初のファシリテーターだという。

株式会社ゆめみ　コーポレートエンジニア　ふわせぐ氏

Q．技術記事で独自性をどう築いたらいい？

ふわせぐ：今回の事前アンケートで多く寄せられたのは、「技術記事で独自性をどう築くか」というお悩みです。

やめ太郎：uhyoさんのように、新しい技術について早いタイミングで正確な記事を書くこと。技術力の高さを独自性にすることが正統派であり、それを目指していました。

キャラ芸人みたいなのはかっこ悪いと思っていたが、今はその筆頭になっている。会話調で書くのも独自性になる。人とネタが多少被っていても、会話調で順を追って説明することで、読み方が変わるのでいいと思っています。

ふわせぐ：切り口を変えて書くのはいいですよね。

うさみ：自分が曖昧だと思っていることを、まとめて発表するのも良いと思います。

Q．記事ネタはどうやって選んでるの？

ふわせぐ：皆さんは、記事にしようと思うネタをどうやって選んでいるのでしょうか。

uhyo：一時期、JavaScript関連で将来仕様になりそうな機能を追っていたので、それを新しい記事を書くネタにしていました。まだ確定した情報ではなく、使いものにならない情報もたくさんありました(笑)。こういう場面で役立つなど、具体的な使いかたまで書くとよりよい記事になると思います。

うさみ：PHPでいうと、RFCなどのプロポーザルを追っていくと面白いかもしれません。

uhyo：私もTypeScriptの最新情報を発信するときは、オープンになっている情報を直接拾っています。

やめ太郎：レベルが高いですね。僕はSlackで流れてくるのをひたすら待っています(笑)。

uhyo：僕は、GitHubによく調べにいってます。ChromeにGitHubアカウントでログインすると、自動的にTypeScriptのページが保管されるんですよ。

うさみ：Gmailに翻訳機能も組み込まれているので、さくっと内容の理解はできると思います。

やめ太郎：僕はMDNのサイトなどで、初心者にはちょっと分かりにくい情報を見つけてます。記事のように娘は教えてはくれないんだけど、それを会話調で記事にしています。

Q．発信媒体の棲み分けはどうしてる？

ふわせぐ：発信媒体はどんな使い分けをしていますか。

やめ太郎：基本的にQiitaで書いています。初心者でも書いて良い空気感があると思います。Zennは中級者が集まっている感じなので、まだ踏み出してはいません。

uhyo：Zennも何でも書いていいと思いますよ。短歌を乗せている人もいるので、娘ちゃんが出てきてもウケると思います。

ふわせぐ：自分のブログとの使い分けはどうしていますか。

uhyo：Qiitaは時事ネタや一発ギャグみたいなネタを書くことが多いですね。Zennは単純な知識など。自分のブログでは思想を発信しています。

うさみ：ネタ記事や多くの人に見てもらいたい記事は、Qiitaに投稿しています。技術を求めている人に当てた記事はZennやブログ、Scrapboxを使っています。

Q．技術記事を書く時間をどう確保しているか

やめ太郎：ゆめみでは、月に10％の時間を自分の好きな研究に使っていいというルールがあります。そのルールを使って記事を書いています。

うさみ：そういう明確なルールはないけど、業務時間内に記事を書いても大丈夫です。

uhyo：LINEも技術ブログには力を入れているので、業務時間内で書けます。

Q．技術記事を書く時間はどのくらい？

やめ太郎：構想を練ってから書いて、見直して、サンプルコードを書いて動かしてとなると、8時間ぐらいはかかります。

うさみ：内容によりますが、Scrapboxだと10分。普通の記事は2～3時間ぐらいですね。

uhyo：型入門などは1週間かけて書きます。普段の記事だと2～3時間ぐらいです。

株式会社ゆめみ
https://www.yumemi.co.jp/

株式会社ゆめみの採用情報
https://yumeminonaka.yumemi.co.jp/