Q&A

ことせかい に寄せられたご意見ご要望について、何らかの理由で実装されなかったご提案について記述しておきます。

目次

はじめに (2019/01)

ことせかい への新機能のご提案、ありがとうございます。 ことせかい は個人が趣味で開発しているアプリとなっております。また、開発者はアイディアをあまり思いつかないような人間ですので、新機能についてはユーザ様からのご提案に頼っている所もございます。いつもありがとうございます。
ただ、このことせかい は「個人が趣味で開発している無料アプリ」であるということを今一度よく考えて頂ければと思います。下記のご意見ご要望への回答を読んで頂けるとわかるかと思いますが、個人制作であり、お金をいただいていないという事が原因で採用できないという問題が多くございます。新機能を思いついてご提案を書くということまでして頂ける方にはお手数までおかけした上で誠に申し訳ないのですが、「ことせかい の開発者は、ことせかい が使いやすくなってユーザが増えたりしても、1ユーザとして使いやすくなるという恩恵以外には恩恵はなく、逆にできることが増える事は不都合の可能性やメンテナンスコストが増えるという問題を生じさせる原因となり、さらにその新機能が評価された結果ユーザが増えることがあったとしてもそれはユーザサポートの手間が増えるだけであり、デメリットの方が大きい」という事をご理解ください。
例えば、開発者 は ことせかい を目で読むためには使っておりませんので、目で読むための機能を積極的にサポートする気はありません。目で読むために ことせかい をお使い頂きたい方には誠に申し訳ないのですが、ことせかい があまり目で読むための仕組みを持っていないのはそういう理由があります。まぁ、ご提案された機能で、簡単に実装できるものについては実装しておりますけれども。
そんな背景があります事をご理解の上、新機能のご提案をしていただければと思います。 また、ことせかい の開発者は褒められるととても喜びます。礼儀正しくお願いなどされても嬉しいと感じます。逆に、「〜はおかしい、〜となるのが当然であるので直すように」といったような思いやりのないお問い合わせを受けると傷つきます。 開発者としましては、それらのご意見ご要望はできるかぎり分け隔てなく評価し、実装するかしないかを決定しようと思っていますが、所詮は人の子ですので褒められたり礼儀正しいご提案の方が採用されやすくなると思います。どうぞお手柔らかにお願いいたします。

読み替え辞書をユーザ間で共有したい (2018/05)

読み替え辞書をクラウド的なものでユーザ間で共有して編集できないかというご提案について。
これは実現したらとても良いものになるとは思うのですが、そのクラウド的な物を維持するのにはお金がかかるので、ことせかい の開発者側としては対応できない案件となります。ことせかい が何らかの形で定常的にお金を生むような形にしていればよかったのかもしれませんがそうはなっていませんし、今から何らかのお金を生む要素を入れるのは多くの人が望まない事ですよね。なので、やる気はありません。ただ、数年間分のサーバ費用にオマケもつけるからやってくれという人が現れたり、自分がサーバ側を管理運営するのでアプリ側はなんとかしてくれという人が現れたり、この無料のサービスをこうやって使うと実現できるんじゃね?というウルトラCを考えついたりしたらあるいは、という気もしなくもありません。(もちろん、その費用が尽きたりサーバ運営をしてくれている人が諦めたりその無料サービスから想定外の使い方しちゃ駄目と怒られたらそこでそのクラウド読み替え辞書共有サービスは終了になりますので、不安定なサービスであるといえます)

何らかの問題で期待しないデータがダウンロードされてしまった章について (2018/05)

これは、例えば小説ではなく、「アクセス数が多いのでエラー」といったものがダウンロードされてしまった、というような場合の事です。 現状では、既にダウンロードして登録されてしまった部分(章)を再ダウンロードする方法はありません。
内部的には HTTP のステータスコードでエラーを返してくれている(200 OK ではない場合、例えば 429 Too many requests を返している)場合であれば、ダウンロードが失敗したとみなして保存せずにダウンロードを終了しています(していない例がありましたら不都合になりますのでお問い合わせフォーム等から教えてください)。逆に、HTTPのステータスコードによるエラー以外で「アクセス数が多いのでエラー」という文字列が取得できてしまう場合(200 OK で取得したデータの場合)には、ダウンロードが失敗したかどうかを判定するのは難しいため、そのままの文字列が保存されてしまいます。これをユーザ様の側で「この章だけ再ダウンロードせよ」という指示を出せるようにしたらよいか、とも思ったのですが、現在の内部データベース仕様ですと「その章」がどんなURLであったのかの情報が不足しており、再ダウンロードすることができないために実現できませんでした(現状では最初にダウンロードしようとした章のURLと、最後にダウンロードしようとした章のURLしか保存されていませんので、10章分読み込んでいた場合には2章から9章までは再ダウンロードすることができない、という状態です)。
なので、「アクセス数が多いのでエラー」といったようなエラーメッセージそのものが保存されてしまっている場合は一旦小説を本棚から削除して、通信環境の良い所で再度ダウンロードしていただく必要があります。
この問題については将来的には対応しようとは思っているのですが、現在の内部データベース形式では上記の理由で無理となります。また、将来的に対応できたとしても、現在既にダウンロード済みのものについて(上記の例だと2章から9章について)はURLを推測できない関係上、対応が不可能な問題となります。予めご了承ください。

縦書き表示について (2018/05)

まず、ことせかい は「読み上げ」アプリですので「目で読む」ための機能については真面目にサポートするつもりはありません。
また、縦書き表示についてのお問い合わせは何度か受けておりますので少し調査してみたことがあるのですが、残念なことに簡単には縦書き表示はできそうにありませんでした。
グダグタと調査したものを書き下しますと、NSAttributedString に NSVerticalGlyphFormAttributeName 辺りを設定すると縦書き表示ができそうなのですが、1行分しか縦書き表示してくれないようであったり、TTTAttributedLabel というライブラリを公開してくれている人が居てそれを使うと良さそうだと思ったら、Label であって TextView ではないのでスクロールできなかったり、UIWebView に CSS で writing-mode: vertical-rl; 辺りを含ませた物を表示させれば綺麗な縦書き表示ができるかと思ったけれど、現在の読み上げ位置をハイライトする方法が一筋縄ではいかなくて断念したり、といった感じです。最後の UIWebView 辺りの仕組みがうまく動くのであれば表示している WebPage をそのまま読み上げさせる事や、挿絵を表示しながらの閲覧もできるようになりそうでいいかなぁとも思ったんですけれども、読み上げアプリとしては読み上げ位置が見えないのはなぁということでお蔵入りになりました。なお、これらは 2,3年前 に調査したものになりますので、今ではもっと良い方法があるかもしれません(その辺りの知識のある方がおられましたら教えていただければ嬉しいです)。
2019/02 追記: 少し調査を進めてみた所、WKWebView を使ってこのくらいまでならできてしまいました。ただ reply の Tweet にもありますようにまだ解決できていない問題がありますのですぐには採用できません。 どこからか対策等を教えて頂ける方が現れないかなぁ(期待のこもった目で)。

スライダーについて (2018/05)

ことせかい の中の色んな所にあるスライダー(左右にスライドして値を入力する奴)なんですけれど、これ、微妙な値を指示したい場合にはちょっと面倒ですよね。そんな時は、スライダーのつまむ所(丸い奴)をタップしたまま(つまむ所が見える状態になるまで)指を下にずらして、そこで指を左右に傾けるような形で位置を調整すると微妙な値もなんとなく入力できます。まぁ正確に0.1づつ動かしたい、みたいなのには使えないのですけれど、覚えておくとちょっと便利な感じです。あ、これは左右への0.1づつとかのボタンを配置するのが面倒だから言っているのではなくてですね、ボタンを配置てしまうとiPhone SEとかの幅の狭い端末だとレイアウトが崩れちゃってちゃんと操作できなくなっちゃうのでボタンを配置できない所があったりするのです。

ルビ表示の改善について (2018/05)

まず、ことせかい は「読み上げ」アプリですので「目で読む」ための機能については真面目にサポートするつもりはありません。
なのですが、簡単に実現できるのに実装しないのだとすると悪い気もしますので、調査してみました。しかし、残念なことにルビの表示を簡単に実現するのは難しいという結論に達しましたため、この機能については見送りました。
ことせかい で小説を表示している画面では、UITextView というコンポーネントを利用しています。このコンポーネントは NSAttributedString という、属性つきの文字を表示する機能があります。この NSAttributedString には CTRubyAnnotation というルビをふるためのそのものの属性があります。なのですが、どうも UITextView はこの CTRubyAnnotation には対応していないようです(設定してみても何も起こりませんでした)。UILabel という別のコンポーネントでは同様にCTRubyAnnotation属性を設定した文字列にルビが振られましたので、多分使い方が間違えているとは思えませんでした。では UILabel を使えばいいではないかと思った人は鋭いかもしれませんが、UILabel ですとスクロールができませんし、範囲選択という概念もありませんので小説の本文を表示するためには使えません。 ではどうするのが良いのかというと恐らくは WKWebView といったような HTML のレンダラを使っての表示にしてしまうのが良いと考えられますが、縦書き表示についての所でも書きましたように、それはそれで解かねばならない問題が解けませんでしたので採用できないという判断になりました。
以上の理由から、ルビの表示の改善については見送らせて頂いています。

読み上げ時の話者について (2018/05)

ことせかい は読み上げアプリですので、読み上げの話者に関して、他の話者を選択できないか、というお問い合わせを受けることがあります。

ことせかい では、iOS の AVSpeechSynthesizer という、Siriさん も使っている音声合成エンジンを利用させて頂いています。これは Appleさん が無償で提供してくれているものになりますので、できるだけお金をかけず運用されている ことせかい としましてはとても使いやすいものとなっています。

同様な無償で利用可能な音声合成エンジンもいくつかあります。例えばAQUEST AquesTalk(一部の方には「ゆっくりの音声」というと馴染みがあるかもしれません)などがあります。 これらの音声合成エンジンは、(人によって評価は別れるのかもしれませんが) AVSpeechSynthesizer と比べてとりたてて良い品質の読み上げを行うようなものはなさそうでした。 また、現在の内部データベース情報では音声合成エンジンを変更するためのデータがなく、別の音声合成エンジンを指定することができません。従って、AquesTalk のような別の音声合成エンジンも利用可能とするためには内部データベースの更新が必要となりますが、これは最悪ダウンロードした小説が消えてしまうというような修正が伴う事になるため、慎重に行う必要があります。 そのため、現在のところはこれら AVSpeechSynthesizer 以外の無償で利用可能な音声合成エンジンを利用できるようにする予定はございません。

さて、ことせかい の開発を開始した頃(多分2014年頃)と比べて、最近は音声合成の技術もかなり進歩してきました。 中でも最近流行りのDeep Learningの技術を利用した音声合成には目を見張る物があります。 例えば Google CLOUD TEXT-TO-SPEECH や、Amazon PollyMicrosoft Bing Speechといったものです。 ただ、これらのサービスは所謂クラウドによるサービス提供を行うもので、利用にはわずかながらとはいえお金がかかります。 ご承知の通り、ことせかい にはお金を生み出す導線がありません。そのため、これらのお金のかかるサービスを利用しようとすると開発者側の持ち出しとなるため、そのままでは利用することは出来ません。

では、クラウドの利用料金をユーザ様から払って頂くような形式にするとどうだろうという考えも思いつきます。 ただ、これは以下に述べますようないくつかの点で問題があり、やりたくありません。

  1. クラウド側の利用料金はとても細かい単位での従量課金制であることがほとんどなのですが、iOS における課金体系にはそのような細かい単位での従量課金というものはございません。 従って、アプリ側での課金は例えば一度に120円分頂いておき、クラウド側の利用料金が120円を超えた辺りでもう一度120円を課金で頂く、というような動作が必要になります。ただ、クラウド側の利用料金はアプリのユーザ単位ではなくアプリ単位で課金されると考えられるため、一人のユーザの利用した利用料金を正確に算出するのは難しいと考えられます。そのため、恐らくは「だいたいこの位使ったのだからこの位のお金がかかっただろう」というざっくりとした推測を働かせる事になると考えられます。また、その推測はどちらかというとユーザ様側の支払う金額の方が多くなるように設定しておかないと、ことせかい の開発者側で赤字になってしまい、サービスが継続できなくなると思われます。
  2. これらのクラウドで提供される音声合成サービスを利用する場合、利用料金の問題が解決したとしても、ネットワークアクセスという問題がつきまといます。ネットワークへのアクセスは常に失敗する可能性があり、失敗からの回復のための実装が必要となり、実験などの検証は恐らく終わりがありません。
  3. ご存知の通り、現在の ことせかい には課金の仕組みはありませんので、新しく課金の仕組みを組み込む必要があります。課金の仕組みはお金に関する事ですので、慎重に組み込む必要があります。ことせかい の開発者は課金の仕組みをアプリに組み込んだ事は一度もなくその辺りの経験が少ないため、この作業にはかなりのコストを見込む必要があります。
  4. クラウド側の従量課金分をアプリ側の課金で補おうとした場合、アプリ側の課金成立時に Apple側 に支払われる 30%分 のアプリ内課金利用料が問題になります。というのは、例えばクラウド側の従量課金で120円分の音声合成を行ったとします。その場合、ことせかい のユーザとしては 120円 だけを払えばいいような気がしますが、これをアプリ内課金で120円を払って支払おうとすると、お金が足りなくて支払うことができません。これは Apple側 で120円の30%の36円が引かれて、84円しか開発者側には手に入らないため、クラウド側でかかった120円に満たないことになります。従って、アプリ内課金でクラウド側の従量課金分を補うためには、その30%分を多く頂く必要が出てきます。恐らくこれは期待されていない動作となるでしょう。

ことせかいの開発者としましては上記のような複雑な仕組みを構築しなければならない上に、さらにお金の問題(多分何かよくない間違え方をすると烈火の如く怒られたり最悪裁判とか警察沙汰になったりする可能性が高い)を抱え込むというコストもリスクも高い案件になります。正直な所、そこまで苦労してこれらの問題を抱え込むだけの利点がありません。

以上の事から、現在のところは問題が多いという理由でこれらの別の音声合成エンジンを利用するというのは難しいと考えています。


小説のお気に入りや本棚のフォルダ分けなど、本棚に関する拡張について (2018/05)

小説をお気に入りに登録したり、フォルダ分けするなどで小説を探しやすくするための機能についてなのですが、これは、現在の内部データベースに保存されている情報だけですと対応が不可能なものが多く、内部データベースの定義を変更して対応しようと思っています。 ただ、その場合は本棚だけではなく他の部分にも影響が及ぶ上に、場合によってはダウンロード済みの小説が見えなくなったりといった問題が発生する可能性があります。そのため、リリース用の枝(branch)ではなく、別の枝で作業しています。 この作業はかなり前から行っているのですが、まだまだ先は長い感じですぐにリリースできるとは思えません。

つまり、本棚に大量の小説を登録していると本棚から小説を探しにくくなっているというのは認識しているのですが、すぐに対応できる状態ではないということになります。 お手数をおかけしますがのんびりお待ち下さい。


pixiv小説のシリーズへの対応について(2018/08)

結論から言うとこれは現在の仕組みでは無理そうです。 ことせかい では Web取込時に HTTP GET request の一回で取得できるHTMLから小説の本文や次の章へのリンクを取得しているのですが、このQ&Aを書いている時点では取得されたHTMLにはそのシリーズ小説の別の章へのリンクが含まれていません。 そこまで深く追いかけてはいないのですが、恐らくはページが表示された後に JavaScript による読み込みによってシリーズ小説の別の章へのリンクが生成されているのではないかと思います。ことせかい側 では JavaScript は動作しませんので、そのような仕組みのWebPageの場合は対応できません。 以上の原因により、原理的に対応が不可能な案件と判断されました。


読み上げ時の音量(ボリューム)について(2018/10)

読み上げ時の音量が小さいのでもっと大きくできないか、というお問い合わせを何回か受けました。 なのですが、これ以上の音量は出せません。

ことせかい は iOS の提供しております AVSpeechSynthesizer というものを使って読み上げを行っています。 この AVSpeechSynthesizer では AVSpeechUtterance というものの volume プロパティで音量の指定ができるのですが、ことせかいではこの volume プロパティを標準値の 1.0 で利用しています。 という状態なのですが、この volume プロパティで指定できる値の範囲は 0.0 から 1.0 なのです。 つまり、現状で最大音量で発話させています。 ということなのでこれ以上の大きい音量では発話できないのです。 どうしても音量を大きくする必要がある方は外部のスピーカーなどの導入をお考えください。


アルファポリス様について(2018/10)

Web取込 機能で対応していました アルファポリス様 なのですが、先日よりダウンロード時に本文の内容が取得できない状態が発生しております。詳細な確認は行っておりませんので正確な事は言えませんが、今現在確認できている所では本文を JavaScript により遅延読み込みしているために、本文情報がカラの物が取得される、という状態のようでした。 このような遅延読み込みを行うWebサイトについては ことせかい の側では対応が難しいため、アルファポリス様 については ことせかい ではダウンロードができないとお考え頂けますと有り難いです。


iOSの音声合成エンジン側の問題について(末尾がリフレインする、一部の文字を読み上げない等)(2018/10)

ことせかい は iOS の提供しております音声合成エンジンを利用して読み上げを行っています。この音声合成エンジンは Siriさん の発話にも使われているような汎用性のあるものなのですが、一部の文字列について不思議な動作をすることがあります。これらの iOS の音声合成エンジン側の問題からくる不思議な動作については、ことせかい の側からは干渉しづらい問題となりますので対応が難しいです。

今現在確認されている問題は例えば以下のようなものです。

  • 末尾がリフレインする文字列がある。例:「/17歳」
  • 読み上げがされない文字列がある。例:「人の噂も75日」の75
  • 途中で謎の言語話者が憑依したようになる文字列がある。例:「軌跡を描くが、それは全く同じ軌道で描かれた白い軌跡」の「描くが」や「描かれた」の辺り
  • 「あ」の後ろに「、」があると「あ」ではなく「ええあいえむ」と読み上げる事がある。例:「あ、ああ」

上記の問題と似たような問題が起きた時に、ことせかい の側で起きている問題なのか、iOS の音声合成エンジンの側で起きている問題なのかを簡易に判定する方法があります。 設定アプリ → 一般 → アクセシビリティ → スピーチ にて、「選択項目の読み上げ」をONにした上で、該当の文字列を範囲選択して出てくる「コピー」といった項目の中にある「読み上げ」を用いて読み上げさせた時は iOS の音声合成エンジンのみの発話になりますので、その読み上げでも同じような問題が起きる場合は iOS の音声合成エンジン側の問題であると考えて頂けると幸いです。

一応、これらの問題は ことせかい の側の 設定 → 読みの修正 にて問題の起こる文字列を別の文字列に置き換える事で問題が回避できる事があります。ただ、これらの問題は iOS のアップデートの時に今まで問題が起きていた文字列が問題なくなったり、問題がなかった文字列で問題が起きたりという現象も確認されており、その全てを読み替え辞書に登録するような事は現実的ではなさそうです。ですので、何度も同じ文が出てきて同じように読み上げがおかしくなる、という問題を抱えている時などはこの方法も考慮すると良い位に考えて、当面は「あぁ、何かおかしな読み上げをしているな」とスルーするのが良さそうな気がしなくもありません。


読み上げ時の話者データのダウンロードについて(2018/11)

ことせかい は iOS の提供している音声合成エンジンを使って読み上げを行っています。この音声合成エンジンでは、予め用意されたいくつかの話者を選択して読み上げさせることができます。話者は 設定アプリ → 一般 → アクセシビリティ → スピーチ → 声 → 日本語 で出てくる話者を利用することになります。このとき、これらの話者のデータを追加でダウンロードすることもでき、そのダウンロードを行った後に ことせかい を起動すればそれらダウンロードされた話者が使えるようになります。

……というのが通常の使い方なのですが、たまに、この話者の一部または全てが選択できなくなるという症状を訴える方がおられます。そのような状態は開発者の所では再現したことがございませんのであまりよくはわかっていないのですが、どうやら「iOS をアップデートした時」や「設定アプリ でダウンロードされた話者データを削除して再度ダウンロードさせた前後」に ことせかい の側で話者の一部または全てが選択できなくなるという状態になることがあるようです。 この問題は iOS の OS 側の問題になりますので ことせかい の側ではどうしようもありません。

この問題が改善したという情報としましては、iTunes を使って復元を行ったであるとか、iOS のアップデートをしたであるとか、設定アプリでダウンロードされている話者データを一旦削除してもう一回ダウンロードしたといった事で改善したという話も聞いています。

なのですが、この症状に陥った後、設定アプリ側ではダウンロードされた話者データを削除するためのボタンが出てこないといった症状になってしまって、どうにもできなくなってしまった、という報告も受けています。 さらに酷いことに、そのようなどうにもできなくなってしまった方で、端末を工場出荷状態にまで(完全にリセットして)戻せば、再度話者データがダウンロードできるだろうとしようとしてみた方もおられるのですが、その場合でも削除のボタンもなく、ダウンロードのボタンも無いという状態になったという報告も受けています。 ここまで来ると端末自体を交換する位しかこの症状を直す方法が見当たらないような気もするのですが、さすがにそこまでするのは難しいかと思われます。

ただ、そのようなどうにもならない症状になってしまった方で、ごく少数の方で改善したという報告を受けた方法があります。 それは、ことせかい 側では話者として選択できなくなった(選択肢に出てこなくなった)が、設定アプリ側では話者データがダウンロードされている、という方で、以下の ことせかい のバックアップデータを使って読み上げに使う話者を強制的に目的の話者に上書きするという方法をとることです。 ただ、上記のような設定アプリ側では全てダウンロードされている(またはダウンロードボタンが無い)状態の方でこのバックアップデータで上書きしても改善しなかった方もおられますので確実な方法ではございません事はご了承ください。

以下に、それぞれの話者を読み上げ時の話者に強制的に上書きするための ことせかい のバックアップデータを置いておきます。 (恐らくは Safari で読み込まないと ことせかい に取り込めません。ことせかい に内蔵の Web取込 タブからだと失敗するかと思われます)


読み上げ時の速度上限(下限)について(2018/12)

読み上げ時の速度について、今以上の速度で読み上げをしたいというお問い合わせを何件か頂きました。 ことせかい の読み上げ時の速度は 設定 → 声質の設定 にある 速度 で調節できるのですが、ここで指定できる値の範囲がシステム側の上限と下限そのものになりますのでこれ以上の値の設定はできません。

わかる方にわかりやすく書きますと、AVSpeechUtterance の rate プロパティ に設定できます値の 下限(AVSpeechUtteranceMinimumSpeechRate) と 上限(AVSpeechUtteranceMaximumSpeechRate) を指定できるようにしてありますのでこれ以上の範囲を指定してもこの範囲内に丸められてしまいます。

この制限を外そうとしますと、ことせかい が利用している音声合成エンジンを iOS の提供している AVSpeechSynthesizer ではない別のもので、合成された音声をPCM的な物で取り出せるもの(例えばAquesTalk等)に変えて、音声をPCM的に取り出してそこからさらに再生速度を早めるような処理を入れる、などの対策が必要となると考えられます。 ただこの場合は、ことせかい の音声合成エンジン周りが AVSpeechSynthesizer に依存した書き方がされているものを別の音声合成エンジンを使うように書き換えないといけなくなりますし、さらに再生速度を変えるとなると恐らくは読み上げ位置の管理にあたる部分にかなり手を入れないといけなくなりそうです。これらの修正は非常に大変なことが予想されます。 以上の理由により、現状ではそのような再生速度の限界を超える目的の変更を行う予定はありません。


小説読み込み時の内容について、又は小説本文とされる部分の選定基準について(2019/01)

先日、小説家になろう様からの本文読み込みにつきまして、「前書きや後書きが読み込まれなくなったので読み込むようにして欲しい」というお問い合わせを受けました。このお問い合わせについて、以前はその前書きや後書きは読み込まれていたという点と、それらの情報は確かに小説の本文とは違うけれど、完全に違う内容のものとは言えず、小説を掲載しているサイト側の用意した文言というよりは小説に関連している文言であるという点から、含まれていないよりは含まれていた方が良いであろうという事でそれら前書きや後書きについても読み込まれるようにデータベースを書き換えました。 具体的にはhttp://wedata.net/items/816192019-01-21T20:19:34+09:00の変更がそれに当たります。

これに関連して、今度は「先日までは前書きや後書きが含まれなくなったので便利に使っていたが、最近また含まれるようになった」というお問い合わせを受けました。これは前に受けましたお問い合わせと真逆の要求となりますね。 このお問い合わせはそれはそれで確かにその通りという気もするわけなのですが、かといってその要求を飲んで元に戻したとして、また今度は「前書きや後書きが読み込まれなくなったので読み込むようにして欲しい」というお問い合わせが来るようになることは考えられます。

ところで、この問題は前書きや後書きの話にはとどまりません。例えばこのNHK のニュース記事のようなものについて考えてみましょう。この例の場合、執筆時点では本文以外にもタイトルや前書きといった物が取り込まれるようになっています。 しかしよくよく記事をみてみると、個々の写真にはキャプション(例えば最初のキャプションは「自宅でくつろぐニローズさん(中央)」)がついています。これは取り込むべきでしょうか。 また、記事のタイトルの直後にある日付(「2019年1月23日 13時08分」となっているもの)は取り込まれていますが、これは取り込まれるべきでしょうか。 ことせかい はWeb小説の読み上げアプリですのでこのようなWeb上のニュース記事についてまで考慮する必要はないのかもしれませんが、仕組み上利用できるものは利用する人が必ず現れてしまいますので考慮しないわけにはいきません。

上記のような例もありますので、一概に「前書きや後書きを読み込んだり読み込まなかったりするためのON/OFF設定を追加する」というような二択の選択肢を用意してしまうと、前書きや後書きではない日付やキャプションはどう扱えば良いのだろう、という事になってしまいます。 その他に、データベース上で本文部分を示すカラムは一つ(PageElement)しかありませんので前書きや後書きといったカラムを増やすのか、そうだとすると日付やキャプションといったカラムまで将来的に増やさねばならないのかといった事を考えると、簡単には「前書きや後書きを読み込んだり読み込まなかったりするためのON/OFF設定を追加する」という施策は取れないことがわかります。 もちろん、何かステキな方法が見つかってこれらの問題が全て解決できればあるいはなんとかなるかもしれませんけれども。

従いまして、当面の間は本文部分というものはWebサイト様毎に固定の読み込み方をするという運用にしようと思います。という事は、このコラムを書き始めたきっかけである所の「前書きや後書きは含まれる方が良い」のか「前書きや後書きは含まれない方が良い」のかといった事については、どちらか一方を選択した状態にせざるを得ないという事になります。

というわけなので、とりあえずはこのWebPageを書いている ことせかい の開発者である「私」はどのような基準でどの文章を含めたり含めなかったりするのかということの基準を考えてみましたので現時点で考えているそれを以下に表明しておきます。

ことせかいWebページ読み込み用情報における本文部分の設定基準(2019/01)
  • 本文であるのに含まれない、という事が無いように努力する
  • 本文ではないとしても、そのWebページが半機械的に追加したような情報ではなく、書き手がわざわざ追加したものについては含まれるように努力する(前書きや後書きについては含まれるように努力する)
  • 読み上げられる物である事を考慮して、前後の文脈で破綻が少なくなるように努力する(キャプション等は含まれなくするように努力する)
  • 上記の指針にもかかわらず、ユーザより「これは外して欲しい」や「ここは含めて欲しい」という要求が多数(どの程度を多数とするかは「私」の主観によります)寄せられた場合、その項目については個別に対応するように努力する

「〜努力する」と書いてありますのは本文部分を示すために用いている xpath を生成する技術者(つまり私)のスキルと実際のWebページの仕様によっては目的の結果を得られない場合も往々にしてありますので完全を保証はできないという意味で濁した書き方になっています。

ところで、その本文部分がどこである、といった情報を書き込んであるデータベース ことせかいWebページ読み込み用情報wedata様 の成果を利用させていただいておりまして、そこに登録されたデータはパブリックドメインとして公開され、かつどなたでも書き換えが可能なデータベースとなっておりますので、上記の基準では納得行かないという方や、その書き方はよろしくないので俺が美しく書き直してやろうという方や、ここは努力してもできなかったんだなわかるよでもこう書き直せばいいんだよ直しておいてやるから今度から気をつけるんだぜという方などは是非ご自身で書き換えておいていただけますととても助かりますのでよろしくお願いいたします。


なろう検索 タブ等の削除方針について(2019/02)

最近ずっと、ユーザ様からのお問い合わせ対応について、これをできるだけ減らしたいと考えています。 今現在のユーザ様からのお問い合わせへの対応にかかる時間や労力は無償でできる範囲を遥かに超えていると考えており、正直な所「見返りもなしで何故こんな事をやっているのか全然わかりません」。

私個人としましては、プログラムを書く事自体が楽しいというのと、自分が作ったものを喜んで使ってくれている方がいるというのはとても喜ばしいのですが、お問い合わせの対応がしたくてプログラムを書いているわけではないため、お問い合わせ対応自体は苦痛な部分が大きいです。

もちろん、お問い合わせへの対応時に「便利に使ってもらえてるんだなぁ」と感じたりするといった事での元気を頂いている部分があるのは間違いなく、また、お問い合わせによってアプリの改善のアイディアも頂戴できる事もあり、お問い合わせ対応が全て苦痛だというわけではありません。

しかしながら、お問い合わせというものはユーザ様側が何か不満を持っていて、それについてなんとかして欲しいというのでわざわざ送ってくるものですので、ほぼ例外なく負の感情が含まれています。

お問い合わせ対応というものは、お問い合わせへの対応をするという事が主目的のため、「なるほどここが問題なのですね」という事を理解しなければならないため、必ず負の感情の根本原因を理解する必要があります。つまりどのような書き方をされていても、それがお問い合わせであるならば、そこに負の感情を読み取ってしまうわけです。

そういうわけなのでお問い合わせから負の感情を受け取ってしまう事自体はしかたがないという理解はしていると思うのですが、これを少しずつでも毎日のように受け取っていますと、精神が疲弊してくるようです。恐らく個人差があるのでしょうけれど、私個人としてはこのような業務は向いていないようで、精神的負担が大きいように思います。

そのような理由から、ずっと「お問い合わせを減らすにはどうすればよいのか」という事を考えているわけです。

さて、ことせかい におけるお問い合わせ対応で多いお問い合わせに小説の取り込みに関する事があります。この小説の取り込み時に発生する問題の原因は、小説の取り込まれ方が大きく関係します。この時、「なろう検索 経由での取り込み」なのか「Web取込 経由での取り込み」なのかを確認できないと、問題の特定が難しい場合が多くなります。なのですが、ユーザ様から寄せられるお問い合わせの第一報にはこのどちらからの取り込みであったのかという事を示す情報が書かれていない事が多く、その場合はお問い合わせに対して返信として、「なろう検索 経由での取り込み」と「Web取込 経由での取り込み」のどちらなのかを問い合わせ返すという事が発生します。 この問題は、同じ小説を別の経路で取り込む事ができる事から発生している問題と言えます。 (「なろう検索」経由で取り込まれる小説は、小説家になろう様 で掲載されている小説になりますので、Web取込 機能でも取り込むことが可能です。Web取込 機能の使い方につきましてはWeb取込機能についてを参照してください)

つまり、なろう検索 経由での取り込みと Web取込 経由での取り込みでは多少の取扱の違いがあり、 これが違うために、どちらの形式で取り込んだのかを明らかにしていただかないと問題の解析ができないという事になっているわけです。

これは、なろう検索タブの存在はメンテナンスコストが上がるだけでなく、ユーザサポートのコストも上げているという事を示しています。

従いまして、今後、なろう検索 タブを削除することを真剣に考えています。

もちろん、なろう検索 経由でのダウンロードをされた小説については、小説の詳細を参照することで Web取込 で取り込んだ小説以上の情報が得られたり、なろう小説API を利用することで複数の小説について一括して更新確認が行えるために更新チェック時に更新の「ない」小説を迅速に排除できるといったような複数の利点がある事は理解しています。それがあるためにメンテナンスコストを払ってでも なろう検索 タブは維持しておいた方がいいのだろう、と考え、今まで手を出さないでおきました。

そうではあるのですが、上記のようにお問い合わせ対応に対してのコスト増がかなりあるという事実と、お問い合わせ対応自体が ことせかい を開発する元気をかなり失わせている元凶である事を加味しますと、なろう検索 タブの存在をこのままにしておくのは容認できないと考えるようになり始めたという事になります。

従いまして、今後のアップデートにて なろう検索 タブの存在を排除していこうと考えています。 なお、なろう検索 タブの排除だけでなく、ダウンロードされた小説を全て Web取込 で取り込んだものと同様な扱いにすることで上記の なろう検索 経由でのダウンロードによる恩恵自体も排除しませんと、ユーザサポート時の「なろう検索 経由での取り込み」と「Web取込 経由での取り込み」のどちらなのかを問い合わせ返す手順はなくなりませんのでこちらも実行する予定となります。

今まで なろう検索 を便利に使っていただいていた方々には辛い変更になるかとは思いますが、上記のような理由がありますため、ご理解頂ければと思います。

なお、この修正自体はまだ何も作業を行っておりませんので、いつ頃にその修正が行われたバージョンがリリースされるかはわかりません。 場合によってはこの告知への反応によっては時期が前後する可能性もあるかもしれません。

ところで、アプリレビュー欄にレビューと称して不満を書かれる方々は恐らくこの告知文を読んでいない方と同じかそれに近い集合だと思われますので、アプリレビュー欄はかなり酷いことになるのではないかと思うのですが、その書かれるであろう不満に私が耐えられなくなる可能性は否定できないように思っています。その場合は暫く ことせかい から完全に離れて何もみないようにするような対応をすることで精神の安定などを取ろうかとは思いますが、書かれる非難轟々の度合いによっては何もかも嫌になってアプリ自体を終了させる可能性も多少はありそうな気もします。どうしたものですかね。


お問い合わせ対応の縮小やBBS等の設置について(2019/02)

なろう検索 タブ等の削除方針についてに対して、お問い合わせ対応が問題なのであればお問い合わせ対応自体を縮小するであるとか、BBSやユーザフォーラムといったような別の形式での対応を考えてはどうか、というご意見を受けましたので、現時点ではなぜそれらを行っていないのかを表明しておきます。

まず、お問い合わせ対応自体を縮小するという対策ですが、これを行いますと恐らくは AppStore側 のアプリレビューに不満や改善点が書かれるようになると考えています。そうした場合、アプリレビューにデベロッパからの返答という形での「お問い合わせ対応」が発生するわけなのですが、このAppStoreのアプリレビュー上でのお問い合わせ対応は、デベロッパ側からの返答を書き込んでから半日から1日程度の保留期間が設けられており迅速な対応ができませんし、ユーザレビューは本来ユーザサポートの場では無いために色々とユーザサポートには使いにくい面があり、不満を書かれたとしてもそのアプリレビュー上で対応する事はあまり筋がよろしくありません。 それであれば、ご意見ご要望フォームを設置し、そちらに誘導したほうがマシだと考えている、という事になります。

それではそのアプリレビュー側での対応もやめてしまえば良いではないかという話になるのかもしれませんが、これは私がそのような対応を取られたら寂しくなるだろうと考えるため、避けたいです。なお、少し勘違いされていると怖いので一応書いておくのですが、お問い合わせ対応時に寄せられる心無い書き方や一部の攻撃的な書き方、有り体に言うと無礼な書き方でのお問い合わせが問題なのではなく、全てのお問い合わせに対応するために使われる私の時間や労力がその見返り(無償なので実質的な物はなく、元気やアイディアをを頂くといった見返り)に見合わないと考えており、その無礼な書き方の物だけを無視すれば解消するのかというとそういうわけではないという事を改めて表明しておきます。そのような事情から、それらへの対応を縮小するというのはせっかくお寄せ頂いているご意見ご要望を無碍にする事になりますので、何か他にできることがあるのならそちらを優先して実行し、お問い合わせ自体への対応を減らすというのは最終手段にしたいなぁと考えているわけです。(そのような意味では月額制に移行することでユーザ自体の数を減らしてお問い合わせの件数を減らすというのは有効だとも考えてはいます。恐らく誰もそれを望んでいないでしょうから、今の所はやる気はありませんが) また、個々の対応において今の所は実装を見送られる、というような事象について、何度も同様の問い合わせが来る場合にはこのQ&Aに追記していく形でその問い合わせの可能性を減らす努力はしています。当然それを読まずにお問い合わせをしてくる方がおられますが、その場合は「〜は実装を見送っています。詳しくはQ&Aのここを読んで下さい」と返信するだけでよくなります。お問い合わせ対応への返信を書いている時はそのような省力化の元の文を生成するような作業と捉えており、結局はどこかで払う必要のあるコストだと考えているわけです。確かにお問い合わせ対応自体を止めた事は無いわけですのでこの仮説がただしいかどうかは判断できませんが、Q&Aとして公開しました事象に関するお問い合わせの数は減る事がわかっておりますので効果が無いわけではないと考えています。

次に、BBSやユーザフォーラム等を設置することでの省力化について。 こちらは得られる効果がコストに見合わないのではないかと考えています。以下に自分の考えている懸念点をざっと列挙します。

  • 恐らくWebサービスという形になるが、管理運営コストが発生する(無料の範囲で実現不可能であるかもしれないし、無料の範囲にしてもユーザが書き込む情報に対する個人情報の保護周りの遵守に対するコストなど無視できないコストがかかると考えられる)
  • 公の場である事が良いことではあると思われるのだが、公の場であるが故に問い合わせを躊躇する案件があり得る。 例えば何らかの問題が起こる小説があったが、その小説名を公の場では明かしたくないなどといった可能性が考えられる。
  • スクリーンショット等のメディアファイルの投稿が許されるような物でないと問題の特定などに不便が生じる可能性がある。
  • 匿名での参加ができる場合、誹謗中傷対策などのコストが跳ね上がる事が考えられる。
  • 意見や要望などを書き込んだ人はそれに対する反応を確認する事になるが、これに対する通知などを行う事のできるWebサービスはあまりない。
  • BBSやユーザフォーラムにした所で、問い合わせの殆どは開発者側で対応する必要が生じると考えられる。これは、開発者でなければ対応できないような複雑な問い合わせの事ももちろんだが、善意の第三者によるサポートが期待できないという事も含まれる。善意の第三者によるサポートは初めの数ヶ月程度であれば効果があるだろうが、それ以降も継続してサポートされるとは信じられない。給料の出る業務であればまだしも、毎日固定した時間をその対応に割くような人物が居るだろうか。よしんば居たとして私と同じように悩むだけなのではなかろうか。無給でそれを行うのは不健全であると考える。
  • それではBBSやユーザフォーラムを設置する利点とは何だろうか。過去に同じような書き込みがなされている場合にそれを検索して出てきた場合の参照性だろうか。それであれば現状のQ&Aで事が足りるのではなかろうか。ただ、Q&Aを読まないユーザも中には居る。そのようなユーザには善意の第三者による過去ログの提示は効果があるかもしれない。
上記の問題をかなり解決している物として、GitHub の issue があります。GitHub の issue は今回の話題に対する点としては以下のような特徴を持っています。
  • 管理運営コストがほぼかからない。ことせかい は既に GitHub上 のオープンソースソフトウェアプロジェクトであり、issue は既に可動しているし、public repository であるので issue の利用も無料の範囲で可能である。また、ユーザの個人情報の保護周りの事については GitHub側 が担保してくれているため開発者側で考える事は恐らく無い。
  • 新しい issue を作成する時には、過去の issue に似た文字列がある場合に「この issue が関連していそうである」という例示が出る。このため、過去の類似事例を検索や参照せずに問い合わせが行われる可能性をシステム上で減らす事が可能である。
  • メディアファイルの添付をすることができる。
  • 善意の第三者によるフォローも可能である。
  • issue に書き込むためにはユーザ登録が必須であるので、誹謗中傷等への心理的抵抗は大きくなる。
  • 個々のスレッドに対してNotification(通知)のsubscribe(購読登録)ができるので、定期的に新しい反応を確認しにいく必要から開放される手段も提供されている。
ただ、GitHub の issue は以下の問題があります。
  • 基本的に英語で提供されるサービスである。
  • ユーザ登録が必須である。
これらの問題はカジュアルなユーザを退散させるには十二分な問題点であると考えられます。 そもそも、GitHub の issue は可動しており、これに対して issue を立てるような事をしているのは今の所外国のユーザ一人だけです。大多数のユーザである日本人からの投稿は一つもない事が、上記の問題が原因であるにしろ、そうでないにしろ GitHub の issue を設置することにはあまり効果が無い事を示しています。

それでは、GitHub の issue のような機能を持ち、日本語で提供され、ユーザ登録が不要なWebサービスがあれば良いのでしょうか。ただそのようなサービスは私は知りません。とはいえなければ作ることもできるとは思います。ざっとどのような物かを妄想してみましょう。

  • 概ね GitHub の issue のような機能を持つ。つまり、個別の内容毎にissue(スレッド)が立てられ、その中で情報交換が行われ、場合によっては担当者が配置されたりbugやenhancementといったタグがついたりする。もちろん、issueを立てようとした時に、似たような issue があるのでそちらを参照してみるのは如何か?と問われたりする。
  • 明示的なユーザ登録がなくても書き込みを可能にする。これはアプリ内で生成する一意のIDを使うなどで対応できそうな気がする。アプリ外(例えばSafariやPCから使う場合)は別途ユーザ登録をしてもらうなどの対応が必要だと考えられる。
  • 明示的なユーザ登録が無いにしても、アプリ側から使う場合に一意のIDを利用できるとすれば、「問い合わせようと思ったけれど既にissueがあったので問い合わせ自体はしなくてよくなったのだが、issue自体はcloseしていなかったので対応を早めて欲しい」という気持ちを表明するための「そうだね」ボタンのような物があると良いかもしれない。開発者側は「そうだね」が集まっているissueを優先的に対処すれば良くなるかもしれない。
例えばこのような物ができると良いとは思うのですが、何分Webサービスは一つ二つしか作った事がないもので、あんまり得意ではなく、開発自体にはかなり時間を要すると考えられます。それで、出来上がる物が GitHub の issue に毛が生えた位の物だとすると、本当に必要だったものはそれだったのか、GitHub の issue をそのまま使えばよかったのではないか、そもそもWebサービスを管理運営するコストはどうするのか、サーバの運用費用もさることながら、ユーザが書き込みを行う事から個人情報の保護であったり忘れられる権利であったりといった事象への対応のコストも馬鹿にならない、といった事が考えられます。そのため、あまりこのようなWebサービスを作ろうという気分になれていません。

以上のように、お問い合わせの省力化やBBS又はユーザフォーラムの設置といったご提案はありがたいのですが、現時点ではあまり有効だとは考えられておらず、実行はされないものとお考えいただければ幸いです。ただ、もちろん、これらの懸念点を払拭するような何かステキな方法があるのであれば教えて頂けますとありがたいです。