エンジニアによるラノベ執筆におけるデプロイ
はじめに
この記事は、エンジニアでありながらラノベ執筆で夢を見ている人が、あまりにも投稿・編集するのが面倒くさくて絶望したため、その改善を目指した男の歴史です。
最近のラノベ執筆
最近のネット小説界隈は、様々な投稿サイトが立ち上がり、群雄割拠を繰り広げています。 言わずもがなの「小説家になろう」であったり、ライトノベルレーベルと結びついた投稿サイトであったり、各々様々な特色があり、一概にどれがいいかを選ぶのは非常に難しい状況にあります。
ラノベ執筆者にとっても、どのサイトで投稿するか、というのは頭の悩ませる問題です。一般的な解決策としては、書いている小説のジャンルと、小説投稿サイトで盛り上がっているジャンルが合致している投稿先を選ぶというのがよく選択されます。例えば、異世界転生ジャンルであれば「小説家になろう」を選ぶとか。
と言っても、ほぼ全ての投稿サイトで、別の投稿サイトへの同時投稿も許されています。なので、読まれる機会の最大化を狙おうとすると、自然とジャンルの合致している複数の小説投稿サイトを選択し、投稿するという手段を取ることになります。そこで問題になるのが、
投稿・編集の面倒臭さ です。
マルチ投稿の手間
特に連載小説などでは、連載を長く続けていくにつれて、複数の小説投稿サイトに小説を投稿 (以下、マルチ投稿) する際に、以下のような作業に時間を使うようになります。
- 各サイトへエピソード(話)を投稿する手間
- 誤字・脱字の修正や各サイトへの反映
- 設定の変更等による改稿作業の各サイトへの反映
- 各サイトにどこまで変更を適応したかどうかの管理
これは非常にネックになる問題で、本来小説家は執筆に時間をかけるべき なのですが、それが上記のような機械作業によって時間を取られてしまっているのが現状です。ですが、もちろん小説は読者に読まれてこそのものなので、マルチ投稿するために上記のような手間を小説家が払っているのが現状です。
エンジニアは怠惰な生き物
Zenn にいる方は知っての通り、エンジニアとは面倒臭い作業を機械にやらせて楽をするために頑張っている職業です。本来は手作業でもできることを、システム化して省力化することで、手作業だと膨大な手間がかかる作業を現実的な処理として落とし込み、それによって、新たなサービスや価値を生み出すのがエンジニアのお仕事です。
私はエンジニアでもあり、ラノベ小説家を目指す一人の人間として、マルチ投稿の面倒臭さは到底許容できず、ちょっと小説を書いた時点で、この作業を手作業でするのを一切合切諦めました。こんなことをするなら、先に小説家向けに CD (継続的デリバリー) 環境を整えた方が将来的にもいいのでは? と。そして、そこから小説を書くことを放棄し、IDE を開き開発を開始するのでした。
成果物
カクダケ!という小説家支援サービスを作りました。
このサービスはマルチ投稿の手間を無くすための機能を提供する(見ての通りシンプルなトップページに劣らず)ごくシンプルな機能を提供しています。特定の小説投稿サイトの小説の内容を他の小説投稿サイトの小説にコピーする、という機能を有しています。
構成
折角なので構成について話したいと思います。私のバックボーンについては、2020年の振り返りを見てもらえると、どのような技術スタックを持っていて、どんなことに興味があるのかがわかります。簡単に言えば、本業 SpringBoot エンジニア、趣味 iOS エンジニアです。
バックエンド
バックエンドは自分の技術スタックから素直に SpringBoot を選択。 API を書くことよりも、各小説サイトを抽象化していくことが非常に大変でした。小説投稿サイトを操作する Kotlin ライブラリを書いたのですが、カクダケ!についてサーバー費用が地味にかかりそうなので、OSS にするのはちょっと二の足踏んでます。(公開しても issue や PR が来ることもないだろうし。)
- Kotlin
- SpringBoot
- Google App Engine
- IntelliJ IDEA
今のバックエンドの処理を一部 Google Cloud Run に載せ替えることを検討しており、その際は SpringBoot ではなく、 Quarkus を検討中。FaaS の場合、JVM の起動時間がネックになる場合が多く、Quarkus + GraalVM によるネイティブ実行が役に立つはず。Quarkus も最近良く触っているので、そんなに難しくはなさそうな手応えがある。
地味にライブラリをバックエンドから読み込むために、GitHub Package を使ったりした。今までは、読み込むライブラリは OSS で公開とかが多かったので、JitPack とかで済ませてたんですが、今回はそうもいかないのでしっかり対応したんですが、意外と資料が少なく少し時間がかかったので、時間があったら Zenn に書こうかなと思う。
フロントエンド
本来自分は iOS エンジニアなので、iOS といきたいところ? ですが、このサービスについては、どう考えても Web が適任 なので、Web サービス開発を再入門することに決めました。
2018年にも自分は趣味で Web サービス開発を行っており、その時は Vue.js でサイトを開発しました。(参考:GCP無料枠で趣味のWebサービスを作った) 理由としては、その当時全く昨今の Web 開発を知らなかったので、React より Vue.js の方が初心者には分かりやすい? という触れ込みを真に受けた結果だったような気がします。
正直、今回も Vue.js でもいいかなと思いつつ、ネットを彷徨っていると、Next.js の記事を見つけて、色々と先進的な機能を取り揃えているんだよ!という言葉に惹かれて Next.js を採用することに決めました。要するに React 派閥に鞍替えです。
- Next.js (React)
- Chakura-UI
- TypeScript
- Vercel
- VSCode
端的にこの開発は非常に体験が良かったです!
Next.js で前回の開発で苦しめられた webpack とかいう謎のツールを触らずに済むし、TypeScript のおかげで、型のある世界でコードを書ける幸せを噛み締められるし、Vercel のデプロイ設定にかかる時間はほんの一瞬だ!し、VSCode は TypeScript のコードを深く解釈してくれて、import の設定とか、リネームとか、かなり親切で使っていて非常に楽だし。
React の FunctionComponent も個人的には非常に直感的で、ある程度理解が進めばサクサク書けて、個人的には非常に好みなスタイルです。Chakura-UI については、一通りの React コンポーネントが既に揃っていて、サクッと UI 構築できるのは楽でした。OpenChakura とかでUI構築の雰囲気を先に掴めたのも良かったです。
開発タイムライン
全て今年です。
-
着想: 2月初旬
- キツい投稿作業に、たいして小説を書いてもないのに音を上げる。
-
ライブラリ実装開始: 2月初旬
- とりあえず、CLI ツールで小説投稿サイト間の同期を取るツールを作成開始。
-
ライブラリ実装完了: 2月下旬
- 「なろう」「カクヨム」「アルファポリス」における同期ツールの実装が完了。
このタイミングで、この機能、誰得かもしれないけど公開したいな、という要望に駆られ、Twitter で聞いてみたら、案外反響があったので、Web サービス化を決意。さっさと Web サービス作らないと、自分が小説書けないので、頑張って最低限のものでリリースすることを目標に作業を開始する。
-
サーバー開発開始: 2月下旬
- この時ぐらいに気分を上げるためにドメイン (kakudake.net) を購入。
-
サーバー開発完了: 3月初旬
- サーバーは流石に本業ともあって実装は一瞬だった。
- まあ実際、ライブラリに皮 (API) を被せるだけの作業だし。
-
フロントエンド開発開始: 3月初旬
- それ以前は React の勉強とかしてたんだけど、やっぱり例以外のものを自分で実装しないと手に馴染まない。
-
フロントエンド開発完了: 4月初旬
- 簡単な Web サービスかと思いきや意外とページ数が多かった。
- 正直、みんなどう開発してるかわかんなくて、正直手探りだった。
- 毎回こういう事あると思うんだけど、出来る先輩から直接教わりたい。
-
デバッグ: 4月中旬まで
- ひたすらエラーハンドリング実装してた。
- エンジニアが使わないサービスだし、しっかりメッセージ出さないと最後に苦労するのは自分。
公開: 4/17
小説執筆のサブ垢にて投稿
まとめ
サービス開発はあくまでも自分の使いたいものを作る! という信念の元に、カクダケ!という作家支援のための Web サービスを作成しました。本業もありながら、割とスピード感のある開発ができたんじゃないかと思う。今後も色々 自分のために 機能拡張をしていく予定。
また、2021年の目標として、2020年の振り返り で上げていた、フロントエンドの知識を付けたい! について、丁度いい題材もあり、順調に第一歩を踏み出せたと思っています。
さて、小説書かなきゃ。
Discussion