記事を読んでもらえるような工夫が必要
Qiitaで記事を書くからには、読まれるということを意識した方がいいように思う。
今回初回の記事を書くにあたって、
「どのくらいの文字数なら読まれるのだろうか」
ということを疑問に思ったので、人気な記事の文章量を調べてみることにした。
とはいえ、まだ知識も技術力も乏しいのでQiitaAPIを使用してみることにする。
読ませる文章力や内容、写真の数。それは今度考えることにする。
使ったものとか
いずれも初めて触れるものたちである。
人気記事の定義
先に人気記事の定義をしようと思う。
みなさんご存じかもしれないが、
QiitaAPIにはトレンドを取得する方法がない。
人気記事=LGTM数が多い記事としてLGTMを対象にしようとしたが、Qiita TeamのLGTMAPIは2020年11月4日より廃止となっていた。
ここで改めて方針転換して、「ストック数が多い記事」を対象にしようと思う。
先行きが不安である。
なお、古い記事を情報取得しても参考にならない可能性もあるため、(元々トレンド記事を取得したいという想いもあったため)「最近投稿された記事」を対象にすることとする。
情報の整理
やりたいことを順を追って書き連ねる。
- 最近投稿された記事の取得
- ストック数の多い記事の取得
- 文字数のカウント
- 傾向調査
実践
1.最近投稿された記事情報の取得
「最近投稿された記事」は、1週間トレンドのようなイメージを持っているため1週間以内に投稿されるものとした。
もっとデータ数を増やす必要がある場合には、期間を延ばせばよいと思う。
複合条件を含めて、以下記事を参考にした。
★参考★
Qiita APIで投稿一覧を取得するときに、検索クエリをORでつなぐ時の注意点
ここのhttp requestノードに情報を書き込む。
検索クエリの指定方法について検討したが、全記事取得の指定方法が分からなかった。ひとまずQiitaの人気タグで1位であるPythonが記事数も多いと考え、指定することとした。
たとえば以下であれば、2022/4/10時点での直近1週間以内に投稿されたPythonの記事の情報を取得出来る。
https://qiita.com/api/v2/items?page=1&per_page=10&query=tag%3APython+created%3A%3E2022-04-03
フローをJSON形式で出力したものはこちら。
[{"id":"dd33d7f1.25bcc8","type":"debug","z":"3a7b76a0.51c01a","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":590,"y":40,"wires":[]},{"id":"7a405693.39dfd8","type":"http request","z":"3a7b76a0.51c01a","name":"","method":"GET","ret":"obj","paytoqs":"ignore","url":"https://qiita.com/api/v2/items?page=1&per_page=10&query=tag%3APython+created%3A%3E2022-04-03","tls":"","persist":false,"proxy":"","authType":"","x":370,"y":40,"wires":[["dd33d7f1.25bcc8"]]},{"id":"10e78170.17bfcf","type":"inject","z":"3a7b76a0.51c01a","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":140,"y":40,"wires":[["7a405693.39dfd8"]]}]
2.ストック数の多い記事情報の取得
先ほどのhttp requestノードに、ストック数の条件を加える。
以下により、上述の取得した記事の中でも、ストック数が5以上の記事を取得できる。(日付順)
https://qiita.com/api/v2/items?page=1&per_page=10&query=tag%3APython+created%3A%3E2022-04-03+stocks%3A%3E5
フローをJSON形式で出力したものはこちら。
[{"id":"6ba2e057.704d3","type":"debug","z":"3a7b76a0.51c01a","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":610,"y":1600,"wires":[]},{"id":"ca217ef7.b1d76","type":"http request","z":"3a7b76a0.51c01a","name":"","method":"GET","ret":"obj","paytoqs":"ignore","url":"https://qiita.com/api/v2/items?page=1&per_page=10&query=tag%3APython+created%3A%3E2022-04-03+stocks%3A%3E5","tls":"","persist":false,"proxy":"","authType":"","x":390,"y":1600,"wires":[["6ba2e057.704d3"]]},{"id":"1a47141.4dd9aec","type":"inject","z":"3a7b76a0.51c01a","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":160,"y":1600,"wires":[["ca217ef7.b1d76"]]}]
これで、1週間以内に投稿されたストック数の多い記事、つまり多くの人が参考にしたいと思った記事を絞り込むことが出来た。
たとえば取得した記事のうち、以下の前者の記事は2022/4/11時点でストック数11で、後者の記事はストック数378の記事である。
AutoTrainでテキスト分類
機械学習が独学できる日本語Youtube難易度別まとめ
下表の通り、投稿日が直近1週間以内で、ストック数が5以上の記事を取得できている。
3.文字数のカウント
ここで、問題発生。
Herokuがやられた。(やったのは自分だ)
未熟者故に解消方法が分からない。
翌日にあらためて開いてみたら直っていた。直し方はわからない。
文字数をカウントするにあたって、参考になりそうな記事を見つけているため、ここに備忘録として残しておくこととする。
結局Qiita記事ってどれぐらい書けばいいのさ
ひとまず獲得したJSONがあればどうにかなると思いきや、単純に文字数のカウントは出来ない。
中身にはhtmlタグが多量に含まれているため、除外しなくてはならない。
前述の検索クエリも、Pythonに絞った後でエラーで触れなくなってしまったため、2点は自身の課題にしようと思う。
課題1・・・検索クエリで全記事対象となる指定とする
課題2・・・JSON形式のデータに対し、htmlタグを除外し成形する
なお、JSONをCSVに変換する方法はいくつかあるが、Webサービスを利用する方が賢いと思う。
JSONをCSVに変換する方法
今回は、タイトルや本文中の情報はわかっているため、それぞれの記事を検索してエクセル機能で文字数をカウントすることにした。
ヒットした記事数が少ないから出来ることである。
4.傾向調査
平均3671文字、中央値2769文字であった。
ただし、他の要素としてタイトル、画像、コードなどが含まれているため、本来であればこれらの要素を個別にカウントするべきであると考えられる。
最もストック数の多い機械学習が独学できる日本語Youtube難易度別まとめは、多くの人の参考となるような動画情報をまとめたものであった。
読みやすい記事量ということも大切ではあるが、多くの人が参考にしたい、また読みたいと思ってもらえるような情報がストックに影響を与えるのだと思う。
たとえば、今回のような参考動画をまとめたものなど、キュレーション記事はストック数が多くなるのかもしれない。
この点においては、タグや文字数だけではなく、本文中の文言から傾向が見つかるのではないだろうか。
「まとめ」という言葉や「初心者」というタグが付くと、初心者にとって有益な情報がまとめられている記事であるかもしれない。
しかし、最後の見出しに「まとめ」と記載する人も多いため、単純にこの用語だけでは見分けられない。難解である。
キュレーション記事だけを選定して、共通項を見つける作業が必要であろう。
技術に触れてみて
APIにあまり触れてこなかった身としては、非常に便利なものであることを再認識した。
と同時に、当然ながらAPI先の仕様に左右されるため、トレンド記事やLGTM数の獲得は出来ないことで方針転換せざるを得なかった。
Webスクレイピングなどで獲得する方法もあることを知ったため、将来的に取り組んでも面白いかもしれない。
おわりに
なお、ここまでで約2200文字である。文字量としては、中央値に近づくことが出来た。
今後は、記事は最大でも3000文字程度を意識するとよいはずだ。
課題2点は今後取り組んで解消してみたい。