「自分の記事を自分で読んでムカつかないように」　うさみけんた氏が意識している、誤情報を届けないための工夫

うさみ氏の自己紹介

うさみけんた氏（以下、うさみ）：今日は「技術発信の信頼性を高める10（イチゼロ）のポイント」ということで話したいと思います。

私は「うさみ」といいます。ふだんはピクシブという会社で、ピクシブ百科事典とか、PHPで書かれているWebサービスの開発をしています。個人ではEmacsでPHP開発する環境を作っていたりとか。2022年はあまりできていませんが、イベントやカンファレンスのスタッフ、実行委員として参加することがあります。

今回のお題ですが、「技術発信の信頼性を高める10のポイント」ということで。個人的なブログとかWeb日記とか、10年くらい技術記事を書いてきて、どういうところを工夫してきたか、どういうところを気をつければ良い文章が書けるかなみたいなところを話そうと思います。

まずはじめにお断りですが、「10」という数はこの案を出した時に適当に作った数なので、任意の進数での10ということにしておいてください。今スライドはできていますが、実際に何個のトピックが書いてあるかは自分でも数えていません。ということで、よろしくお願いします。

うさみ氏のこれまでの取り組み

個人的にはどういうことをやってきたかというと、コンピューター自体は2003年頃からいろいろやってきて、Webとかもいろいろできて。プログラムやソフトウェアみたいなものにけっこう関心があって使ってきました。プログラミングを勉強したり、記事とかを読んでそれっぽいことを学んだり、簡単にちょっと動かしてみるぐらいは2003年頃からできました。

2010年より後、2012年ぐらいになるまでは、ちゃんとプログラミングでソフトウェア、アプリケーションを作るようなところ、体系的に「プログラミングができる」と言い切れるような感じにはなっていなかったです。

自分の中で10年ぐらい駆け出しをやっていて、そこでようやく仕事に就けた感じです。その間に自己研鑽という言い方をするとアレですが、プログラミングを学んだりする過程で知ったこととか、勉強になったこととかをWeb上のブログとかに書いてきました。

ということで、就職したのは2012年頃。Qiitaができたのが2011年頃です。それまではPHPにあまりのめり込んではいませんでしたが、2014年頃からPHPの詳しい記事とかを書き始めたりしました。

2016年に『WEB+DB PRESS』という、技術評論社さんが出している雑誌とかで、PHPの連載があったので、そちらに（記事を）書いたりするようなことを始めていました。あと、この頃からPHPカンファレンスみたいな、リアルのイベントでもPHPの発信をしてきています。

ということで、初めて技術記事っぽいものを書いてから雑誌に寄稿するまで8年ぐらい。けっこう長い期間をかけてやってきました。自分としては、発信するよりは、いろいろな技術をインプットしてやっていくようなことが、時間的にはかなり長かったですね。

ということで、2000年代中盤くらいから、わからないなりにプログラミングのいろいろな知見とか、複雑なコンセプトみたいなものの勉強はしてきました。その頃は使えもしなかったんですが、その後、複数のプログラミング言語とかを学んでいく上で、それが有機的につながっていって、今できる技術に直接つながっていくようなことがありました。

自分が思っていることとしては、なにかを発信する前に、乱読というか、使えるにしろ使えないにしろ、知識としてため込んで、そこから発信することはけっこう大事なポイントの1つであるかなと思っています。

初期の発信で実践してきたこと

初期にどういうことをやってきたかというと、環境構築とかカスタマイズみたいな、あまり技術的ではないこと。自分がやってきたログみたいなこととか、リアルで教えてもらったこと（をやってきました）。

昔アルバイトをしていた会社で、関数型言語をちょっと教えてもらったりするようなことがあったのですが、それを自分なりにいろいろ調べたり、教えてもらったノートとかをブログに書いてまとめたりみたいなこともしていました。

あと、ググっても中途半端にしかわからないようなこととか、ふわっとした言い回しで「なんでこれがこうなっているのかよくわかんない」みたいなことって、たまにあるじゃないですか。そういうところを、自分で「どうしてこうなるのか」というのをハッキリさせたくてまとめたりもしていました。

あとは断片的ならまだしも、明らかに間違っていたりとか、現場に即していないようなものを、端的に言うとムカついたので、自分でやるしかないと。そういうところから発信していきました。

自分の記事を自分で読んでムカつかないような文章を出していく

みなさんもそうだと思うんですが、なにか解決したい問題（があったり）、困っているのにぜんぜん関係ないようなこととかが出てきたら、ムカつきますよね。

だいたいの人はムカつくと思うので、「これから発信する」という段階では、自分の記事を自分で読んでムカつかないような文章を出していくのは、けっこう重要なポイントかなと思います。ということで、自分を客観視して見ていくというところです。

この「ムカつく」という感情はけっこう理不尽で。読者の立場は、人がまとめた情報を一方的に摂取して、それで自分の解決したい問題に合わなかったからと、書いた人が悪くなかったとしても「自分の感情としてはそうじゃないんだ」みたいに思ってしまうことがあります。（その現象に）憤りは感じつつも、自分でそれをどう解決するかを考えたりしていました。

誤情報とは何か

技術的な情報とかを見ていくと、「この記述は嘘だ」みたいなことを、僕自身ちょっと言ってしまいがちなところもあるのですが、それはさまざまな事情で現場に即さないということもあるし、単純に技術の誤認みたいなこともあったりします。

間違った情報は、自分でもっと適切なものを発信していくことでしか置き換えられない、止めることはできないのかなということで、（自分で）発信していくことをしていました。

誤情報にはどういうものがあるかということと、（それに対して）読者としてなにができるか。（例えば）単純な間違い、なにか書き間違いみたいなものとか、スペルが間違っていたり、リンク先が間違っていたりは、自分が発信する立場じゃなくても、読者の立場として例えばQiitaの編集リクエストとかを送って修正してあげるとか。小さいことですが、技術発信の最初の1歩みたいなところにできるかなと思います。

あとは、その記事を書いた人が明らかに間違ったことを書いているみたいなところは、コメント欄とかSNSとかでやんわり指摘するといいかもしれないです。

あとはドッグイヤーというか。コンピューターの分野は特に短い時間で進歩していったりするため、すぐにその内容が廃れたり、事情が変わっていったりすることがあります。昔は正しかったけれど、今は誤情報になってしまうようなこともあったりします。こういうものは、自分で新しい記事を書くことが、1個の解決策かもしれないですね。

誤情報を届けないための工夫

ということで、自分で新しく技術を発信する上で、どうやってそうならないようにするかという単純な工夫としては、これはちょっと根性論っぽいんですが、自分で気をつけるとか、あとは誰か信頼できる人にチェックしてもらう。

ちょっと宣伝ですが、友人が「Shodo」というサービスで、AI校正のツールを開発しているので、こういうサービスを利用するのもいいかもしれないですね。

明らかに技術的な対象の事実誤認みたいなところに関しては、その分野の専門家になるということでは完全に解決できなくて。偉い教授の人とかでも間違った内容を書いてしまうことはあり得なくはありません。

すべてのものを見通して書くことはできないので、「この記事の内容は普遍的に正しい内容だ」ということではなくて、「今自分が動かしているこの環境に対してはこう動く」というところを、記事の条件を絞って記述することで、間違っていないことを主張することはできるかなと思います。

あとは、情報源に関しても、Googleとかで適当に検索した記事よりも、Web上に「この記事を見ておくと間違いない」みたいなサイトがいくつかあるので、こういうのを見ておくといいでしょう。

HTMLとかCSSとかJavaScriptみたいなものに関しては（MDN Web Docs）。これはMozillaが運営しているサイトですが、かなり網羅的で正しい内容で、なおかつコミュニティで日本語に訳したような内容が見られるので。基本的には適当にキーワードで検索したものよりは、まず「MDN」とつけて検索することで、比較的信頼性の高い中立的な記述、あとは互換性とかも配慮されたような質の高い情報にアクセスできます。

あとは、PHPとかプログラミング言語の固有のマニュアルに関しては、コミュニティで訳されているドキュメントがあったりするので、こういうのにもアクセスしてみるといいでしょう。

あと、読めればの話ですが、ソースコードに当たってみることで「ここでこういう記述をされているので、確実にこう動きますよ」みたいなことを説明できるかもしれません。

繰り返しになりますが、適当にググった内容とかをソースにすると、他のブログを書いた人が自分なりにまとめたものを、さらに自分なりにまとめ直すことで、誤解が拡大されてしまうことがあるので、基本的にはなにかをやる時は信頼性のあるソースをベースに構成していくのがいいかなと思います。

基本的な標準関数とかメソッドみたいなものに関しても、メソッドの意味みたいなものが、自分が本来思っていたものとは実は別の機能があったりすることもあるので、「基本だな」と思っていることに関しても、あなどらずにきちんとマニュアルとかを見て理解していくと、質の高い情報にできるかなと思います。

あとは、固有名詞とか言葉の使い方です。大文字、小文字の使い方みたいなところや、あとスペースを入れる・入れないみたいなところ。

あと専門用語の使い方。技術分野だと、例えば関数とメソッドの違いみたいなのも言語によって使い分けとかがありますが、若干別のニュアンスがあったりするので、そういうところをきちんと意識して使えていると、質の高い情報として見られやすいかなと思います。

あとは記事の文体です。「です・ます」で書くのか「だ・である」で書くのか、カジュアルに書くのか。関西型言語とか、かなりふざけ倒した感じの文体に関しても1個の方法だと思うんですが、これはけっこう技術が要ることなのかなと思います。

あとは書いてある内容がどう正しいのかを保証する上で、簡単なサンプルコードとかでも適当に書くのではなくて、きちんと動かしてみることが大切なのかなと思っていて。

今のWeb上だと、オンラインでソースコードを貼ると（それを）実行できて、その結果を見られるサイトがいくつかあります。そういうところで実行してみてリンクを貼ることで、プログラミングの記事であれば第三者が検証できるかたちで、意図どおりに動く内容であることを共有・動作確認できるのかなと思います。

あとは、オンラインでの直接の共有はできませんが、Dockerとかを使うことで、第三者でも環境を再現しやすくなっているかなと思います。

初心者におすすめの発信内容

どういうところから発信を始めるかという話ですが、初心者が発信する上で「この内容は間違っている」とか指摘されることはけっこう怖いとは思います。でも、慣れないうちは合ってる／正しい／間違っているみたいな枠に囚われないようなところから始めていくと、ハードルとかを下げやすいのかなと思っています。

例えば、先ほど言ったようなログみたいな内容とか、カンファレンスや技術イベントのレポートだったり。あとは自分のこだわり、カスタマイズみたいなところをやったり。

書きたい内容がないような時でも、常に書きたいネタに関して、誰か偉い人が記事を書いていたとしても、自分なりの見解とか「自分ではこうした」みたいなところを付け加えて書くことで、オリジナルな価値のある情報ができるのかなと思っています。

僕も初期に書いた記事は、インストール方法だったり、printfみたいな簡単な関数の動作確認。あと端末のカスタマイズみたいなところから始めていました。

みたいな話で、発表を終わりたいと思います。

司会者：まだ時間あるので、よかったらゆっくり説明いただいてもいいかなと思います。

うさみ：大丈夫ですか（笑）。（画面を示して）画面に映っていますかね。初期の内容、2012年とかだと、ImageMagickのコマンドラインの使い方みたいなところとか、Emacsのコマンドのカスタマイズの方法みたいな。本当に単純な短い内容から始めていっています。

そういうものに関しても、「そのソースはどういうところを参照すれば正しいのかがわかる」みたいに、極力リンクとかを貼るように書いていったりしています。

司会者：ありがとうございます、うさみさん。以上で大丈夫ですか？

うさみ：大丈夫です。

司会者：発表ありがとうございました。