エタる、または、エタり小説のソフトウェア工学的考察 ー ベータ小説とは？

　完結するか、延々と続くか。Web小説に投稿したことがあるならば、一度は経験する葛藤じゃないでしょうか？　そんなあなたに、工学的視点の正当化を捧げましょう（笑）
　なお、ここでは「完結するか、延々と続くか」は「完結を視野に入れて書くかどうか」とも同義だと考えます。

　まず、「エタる」とは、小説の連載が途中で止まって、完結せずに放置状態になることをいいます。エターナル＝永久、の名詞が動詞化したものですね。
　通常は、何らかの理由で連載が中断してしまう場合に使われます。
　よくある理由としては、書籍化が決まって忙しい、とかですね（うらやましい）。
　人気作品でよく起こる現象です。あとは、作者が飽きたとか、書けなくなったとか、読まれないから筆を折るとか、まあ、いろいろです。

　これに近い考え方として、「完結を考えずに書く」という書き方があります。Web小説投稿サイトではよくあるパターンで、取りあえず話が始まり、話が延々と続き、一見いつ終るのかわからないみたいな連載です。この場合、途中でクライマックス的盛り上がりがある場合と無い場合があります。ラブコメ、VRMMO、異世界もので多いでしょう。
　それらの内容的に「楽しみがずっと続いて欲しい系」「ゲーム実況的内容系」だとどうしてもそうなると思います。この場合、エタった分けではないので、「エタり」とでも言いましょうか。「エタる」の動詞を再び名詞化して「エタる」的要素のある書き方、ですかね。「エタり的な」と形容詞として使ってもいいかもしれません（すみません、私の勝手な造語です）

　これらの反対の考え方として、また、”正統的”書き方として、最初から完結を視野にいれて書くというものがあります。映画や書籍化された小説だと当然そうでしょう。Web小説登場以前なら当然の考え方かも知れません。
　そういうものは、通常、起承転結や三幕構成などの「構成」があり、全体の話の流れが綿密に計算されています。また、ジャンル的に当然の場合、例えば、ミステリなどは謎解きが最後に必ずあるので完結が前提だと思います。

　この、完結するかしないかで、作者の意見がぶつかる場合があります。「完結するのが当然」派と、「延々と話がつづくのが楽しい」派、です。
　この両者の争いは実は意外と根が深いです。両者それぞれの主張があり、言い争いになる可能性大なトピックです。

　ちなみに私は「どっちでもいい」派ですが、以前はどちらかというと「完結する」派でした。実際私の長編２作は完結済み。もちろん結末まできっちり構成を考えたプロットを練り、完結させています。
　ですが、最近考え方が変わってきました。

　それ故の、このエッセイです。

　さて、少し前に「アジャイル執筆プロセス」の記事を書いた後、ふと、この「エタる」について思いついたことがありました。私はソフトウェア工学の専門家なのですが、上記の違いはソフトウェア開発プロセスの違いと同じではないかと思いついたのです。

　まずは、「ソフトウェア開発プロセス」について解説しましょう。

　ソフトウェア開発において、その開発の流れとして、大きく２種類のプロセスがあります。
「ウォーターフォール」と「アジャイル」です。

「ウォーターフォール」とは、滝。つまり、水が上から下へ流れていくように、開発の工程が進むものです。
　「要求分析→設計→実装→テスト→リリース」、という風に、上位の行程から回の行程まで順番に作業を行います。原則的に、各工程が終って次の行程に移ると後戻りはできません。（信じられないでしょうが、大規模になるほどそうなります）
　このプロセスが使われるのは、大体が大企業などの大規模開発です。もしくは、「要求」や「設計」が簡単に決められ「る」ような場合です。
（決めるのが大変な場合じゃないですよ。諸処の事情により「決定してしまえる」という意味ですｗ。トップの命令も含めて）
　
　逆に「アジャイル」とは、「敏速」「機敏」という意味で、ソフトウェア工学的には、上記の「要求分析→設計→実装→テスト→リリース」（これをスプリントと呼びます）を非常に短期間で行い、それを繰り返します。繰り返しの期間は２週間とかですね。そして取りあえず作ってみて、その後のフィードバックを元に、スプリントを繰り返します。
　このプロセスが使われるのは、「要求」や「設計」があらかじめ明確に分からないような場合です。新規サービス、斬新で時代を先取りするサービスとかですね。

　近年の野心的なシステム・サービスやアプリの開発は、殆どが「アジャイル」です。なぜかというと、先進的なものは得てして綿密な「要求分析」が不可能だからです。何が求められているのか、何が受けるのか、あらかじめ解らないのです。なので、取りあえず何らかのシステムを作り、ユーザーに使ってもらい、そのフィードバックを元に改善を続けていく、というのが主流になっています。ユーザビリティの観点からも、サービスの改善の観点からも、常に更新するというやり方は理にかなっているのです。
　（「ウォーターフォール」対「アジャイル」の話は溢れていますので、興味がある方はネットで調べてみてください。）

　では、これを小説書きに当てはめてみましょう。

　まず前提として、読者に「ウケて」読まれる小説を書きたい、とします。
　さらに、漠然とした初期のアイデア／プロットが思いついた、とします。

　この場合、次に取る行動として考えられるのは二種類です。

Ａ．ウォーターフォール式：
　引き続きプロットを詰める。構成や結末まできちっと考えて、ある程度までまとまった後、書いて、推敲して、完成を予約投稿。

Ｂ．アジャイル式：
　初期アイデアとプロットを元に勢いに任せて書き始める。ある程度まで書いたら、見直す。そして連載を開始する。反響や自身の勢いや、書く事によって湧き上がるアイデアを元に、プロットを修正したり、設定を変えたり、臨機応変に話を続けていく。

　さて、本エッセイで問題にしているのは、エタる確率が高い作品なのですが、それは、「Ｂ．アジャイル式」で連載を開始した場合だと思います。
　　アイデアを思いついた！　プロットを練ってる暇はない！　でも書きたい！　じゃあ、書き始めてしまえ！　上手くいけば続けられる！
　で、上手くいかずにエタると。

　でも待ってください！
　もし、「Ａ．ウォーターフォール式」を選んだとしましょう。何が起こるか。延々とプロットを練り、頭を悩ませたあげく、没になる。その作品は一生世に出ない。

　もったいなくないですか？

　凄いアイデアを思いついて、取りあえず出してみて、上手くいけばウケる！　もしくは、自分の中だけで世に出ずにそのまま消えていく。

　どちらを是とするかはもちろん本人次第です。

　でも、IT業界では、アイデアがあれば取りあえず作って、世に出して、フィードバックを得て、拡大して、一世を風靡して、大もうけするという事はベンチャー企業的に普通に行われています。

　何がウケるかはユーザー（＝読者）にしか解らない場合も多々あります。

　エタるのを怖がっていては何もなさない。エタってもそこから得られたものには価値があるのではないでしょうか？

　作者としても、読者からのフィードバックが。
　読者としても、例え途中までであっても、アイデアや感動は得られる。

　エタり易い作品は、実はアジャイル式にサービスを開発しているのと同じ事を行っているわけで。
　先進的な斬新なアイデア、行動力、フィードバックを受け入れるオープンマインド。頭の柔らかいこれからの手法じゃないでしょうか？

　私はこの手法で書かれた小説を「ベータ小説」と呼びましょう！

　そして、読者はそういう作者のことを応援して、製品版の小説（＝完結する）が出るまで見守ってあげて欲しいと思います。

　ということで、エタり派の皆さん、あなたのその手法は工学的時代的には先端を行っているのです（笑）