概要
訓練不要で誰でも速読ができるアプリ「瞬間速読」を作った物語です。
「瞬間速読」はおかげさまで25万ダウンロード以上(☆4.7)。
今でこそ日本一の速読アプリと言っても過言ではないものの、
そのアイデアから実装、リリース、ブラッシュアップの道は長いものでした。
どんなアイデアを、
どのように創造し練りあげ、
どのような技術で実装に落として、
どのように更新、機能追加していったのか、
個人開発の一つの歴史を、物語として振り返ります。
個人開発 Advent Calendar 2018 の四日目の記事です。
アプリ/アイデアの面白さでも、使用した技術のTipsでも、
試行錯誤の経験談としての参考でも、
何かを楽しんで読んでいただければ幸いです。
TL;DR ＝ "Too long; Didn't read" の略。
「長すぎて読まなかったよ」
Qiitaでは「要約」の意になっていますね。
ここでは本当に「TL;DR」なので、興味のある方だけご覧ください。
「瞬間速読」の紹介
まずは無料で入手！
まず、何を作ったのか、改めて紹介します。
百聞は一見にしかず。
無料なので、とりあえずダウンロードして見ていただきたいです。
（または、GooglePlayの概要だけでもご覧ください）
訓練しなくても「速読」できてしまう魔法のような体験と、
大量の人気古典小説が、完全無料＆広告も通信も無しで楽しめます。
しかも継続すれば脳力が向上し、普通の本も早く読めるようになります。
2018年12月時点で、日本一の速読アプリだと思われます。
日本語の速読アプリの中では、DL数最多＆高評価。
「速読」でそれぞれのストアを検索しても、
多くの場合一番最初に表示されると思われます。
25万程度で日本一とは・・・と思うかもしれないですが、
ニッチなジャンルとしてはかなり大きな数なのです。
この記事の直前に５回目のメジャーバージョンアップをしました。
Advent Calendar を書くことにして、それに間に合わせるぞ、
という締め切り駆動開発がCalendar参戦理由。
※Android版は、2016年5月より公開。
iOS版は、2017年7月より公開。
2018年12月時点では、Android版ユーザが大多数です。
従来の速読方法との違い
従来の速読手法の課題
従来の速読手法は「視線/視野の訓練」や、
実質的には「飛ばし読み」、がほとんどでした。
「高い金払って修行すれば速読できるよ」です。
「瞬間速読」の利点
**訓練をせずに初見から「速読」**ができます。
実際に３０名ほどにアンケートをした結果、
約８８％の人が、初見で３倍速で読むことができました。
平均の４倍速以上を速読と呼ぶそうです。
初見で３倍であるので、慣れればすぐに４倍になるでしょう。
また、とても多数の人から、普段自分で読むよりも、
無理なく早く読むことができるようになった、
という声を頂いております。
「修行」が不要で、最初から多数の小説を速読できる点と、
それで脳力が鍛えられる点が高評価につながっているようです！
なぜ誰でも速読できるの？（２点の原理）
①「眼の動き」のロスの解消
従来の読書は、「文字を眼で捉えること」に
大きな労力を使っています。
読書の８０％は眼球移動に費やされている、
という話もあります。
「眼が認識できる量」＜「脳が理解できる量」
であるのに、「眼」がボトルネックになり、
「脳」を最大限活かせていない、
これが通常の読書の問題でした。
（その意味では、視野トレーニングから開始する、
従来の速読手法も理にかなったものではあります）
瞬間速読が採用している高速逐次視覚提示（RSVP）では、
同じ場所に文字をフラッシュ表示することで、
「眼」の動きを無くすことができるため、
「脳」を限界まで活用することができます。
そのため訓練不要なのに最初から読書スピードが向上するのです！
（一度お試しいただくと効果が分かりやすいと思います）
②単語単位の脳内補完で超高速認識
この ぶんょしう は いりぎす の
ケブンッリジ だがいく の
けゅきんう の けっか
にんんげ は もじ を にしんき する とき
その さしいょ と さいご の もさじえ
あいてっれば じばんゅん は
めくちちゃゃ でも ちんゃと よめる という
けゅきんう に もづいとて わざと
もじの じんばゅん を いかれえて あまりす。
どでうす？ ちんゃと よゃちめう でしょ？
上記は、Typoglycemia などと呼ばれる現象の引用です。
実は人間は、全ての文字を読んではいません。
この文章が認識できるということは、
単語単位で認識すれば、１文字ずつ見なくても頭に入る
ということを意味しています。
すなわち、適切な単語単位に区切って表示することで、
文字数以上の超高速読書を可能にするわけです。
これは、「絵」的に認識しやすい、
日本語について最も効果を発揮します。
脳力の向上効果（普通の本も早く読めるように）
- ①「眼の動き」のロスの解消
- ②単語単位の脳内補完で超高速認識
「瞬間速読」では、この２つを同時に提供しているため、
通常の読書よりも「原理的に」早く読め、修行が不要なのです。
では、この読書方法を継続すると何が起きるのでしょうか？
「眼」ではなく「脳」側がボトルネックになるため、
通常の読書では「脳」を鍛えることが出来なかったのに対して、
「脳」の限界までINPUTするため、効果的に「脳力」が鍛えられます。
（従来の腹筋運動では腹筋への負荷よりも背中や腰を痛めてしまうが、
○○○ならば、直接腹筋にアプローチ、効率的に腹筋を・・ry
という腹筋トレーニンググッズに似ています）
この効果により、しばらく続けると、「脳力」が上昇し、
普通の本についても認識力（読書速度）の向上が見れます。
従来のように「訓練」⇒「速読」ではなく、
最初から速読を実現し、多数の小説を楽しめ、
それが自然と脳力向上の訓練にもなっているのですね！
最大の問題＝日本語は区切りが無い
リリース当時、英語圏では既に「spritz」などのサービスがあり、
高速逐次視覚提示（RSVP）によるニュース表示や、
企業・学校への研修などを提供しているようでした。
しかし、日本語にRSVPを適用したのは見当たりませんでした。
日本語版が難しい理由は、英語と違って、
「どこで区切って表示するの？」という問題でしょう。
この問題を形態素解析を応用して解決した点が
特許にもなりえるアイデアです！
速読の原理と課題をお話したところで、
どう取り組んで、どんな技術で解決したのか、
物語は続きます。
※特許が絡むので、アイデア自体の流用はご遠慮ください。
技術的には大したことはないです。
「コロンブスの卵」的な意義です。
「枯れた技術の水平思考」です。
瞬間速読の誕生秘話①：生誕
英語版RSVPとの出会い
英語版のRSVPである、spritzというサービスを耳にします。
Gigazineのspritz紹介記事①(2014/02)
Gigazineのspritz紹介記事②(2016/02)
「日本語でも出来ないの？」とまず思います。
まず、日本語での効果を確認
まず単純に日本語でも「速読」可能か、効果を確認しました。
Electronというフレームワークを使えば、
JavaScriptだけで容易にWindowsのソフトを作ることができます。
手作業で、任意の短文を区切って、JavaScriptの配列に入れます。
document.innerText= を一定間隔で連続実行して
その配列を連続で表示する単純なプログラムです。
結果、３点の分かったことがありました。
①通常より早く読める実感があった（最重要）
②英語(spritz)の場合、「着眼点」を赤くしていたが、
日本語の場合は、半自動的に、「漢字」に目がいくため、
そうした着眼誘導は逆効果になる
③英語(spritz)の場合と違い、１行表示ではなく、
前後の行の表示があったほうが読みやすい。
（文章の切り方が、複数あり得るため）
効果があったことと、英語との差別化要素を確認できたので、
文章を手作業で区切る部分をなんとか自動化して、
日本語向けにアレンジしたRSVPを
世に出してみようと決心したのでした。
形態素解析との試行錯誤
区切りの自動化については、
形態素解析で区切った状態が比較的近いように思われます。
しかし、形態素解析の結果は、RSVPにそのまま表示するには
「細かすぎる」状態でした。
例えば代表的なところでは
「が」「の」「と」「を」「で」「は」「に」
などなど、一文字で大きな意味のある語句が
大量に分かれて出てきます。
また、単語の長さも、長いものから短いものまで、
かなり異なるため、読みやすい粒感に揃えることは困難でした。
そこで、基本的な考え方としては、
「名詞・動詞・形容詞などの主幹語句」＋「サポート」
で一区切りとするようなロジックと、
文字数調整の融合を考えました。
日本語は / 基本的には / このように / 区切ると / 読みやすい。
という仮説です。
概ねでは上手くいくももの、全てが上手くいくわけではなく、
また、カッコなどの記号や数字の扱い方も追加が必要でした。
作成 ⇒ サンプル文章を通す ⇒ おかしな部分を調整
というサイクルを数えきれないくらい繰り返します。
「調整」とは、大抵は、
複雑な条件分岐を追加していくことになります。
以下の記事で実施していたような活動がとても近いです。
「赤の他人」の対義語は「白い恋人」 これを自動生成したい物語
１００％ではなくても、リリースしよう！
しかし、いろいろ調整しても、100%の納得は得られませんでした。
かなり想定に近いように区切ってくれるのですが、
区切った文章を見直すと、どうしても直したい箇所が出てくるのです。
パレートの法則（2：8の法則）のように、
「２」の労力で「８」の精度までは作れます。
しかし、最後の「２」の精度を埋めるには、
「８」の労力が必要になります。
そこで、最初にリリースする際は、
自動区切りツールで切ったあとで、
簡単に人力でチェックをするようにしました。
どうせ最初の段階では、文章の数も
そこまで多くは無かったのです。
区切りツールの完璧化よりもチェックの方が容易でした。
AI的な要素のあるプロジェクトのあるあるですね。
※公開１年後、2017年07月にバージョンアップをして、
現在では人力チェックは基本不要になりました。
瞬間速読の誕生秘話②：方向転換
最も面白い部分だけをユーザに使ってもらおう！
当初は、自動区切りツール＋速読表示、によって、
「任意の文章を早く読めるツールですよ～」
として、PCソフトをリリースしようとしていました。
UXを考慮しないエンジニアが考えそうな発想です。
しかし、任意の文章を読める、として公開しても、
多くの人はまず「走れメロス」で試してみるのではないか？
と思い、公開方法は大幅にピボットすることにしました。
みんなが「走れメロス」に対して
自動区切りツールをかけるのは無駄な作業です。
作者側で区切り済みのデータを生成しておき、
それを配布すれば良さそうです！
各ユーザが、それぞれでお試し文章を用意する手間や、
ツールの使い方を覚える必要もなくなります。
スマホゲームでは、最初の５分、チュートリアルで
「その気」にさせないと、すぐにユーザは離脱します。
見た瞬間から使い方が分かることはとても重要です。
何でもできるツールは、何にも使われない
もちろん、ニュースやブログの最新記事を読みたい、とか、
自分が所持する文章データを読みたい、とか、
青空文庫の小説以外の、発展的な速読ニーズは確実に存在し、
現在でも良くある要望の一つではあります。
（どうしようかは現在も悩み中です）
しかし、「何でも速読できるツール」は
**「何も速読されることはない」**と考え、
初回ターゲットを絞ることにしました。
では、人はなぜ青空文庫の小説を速読するのか？
名作を読むという以外にも「脳トレ」（速読訓練）
という動機が大きいと考えました。
日本人は「脳トレ」好きが多いですよね。
自分も、テスト版で読書速度が向上した実感がありました。
こうして、「瞬間速読」は、「spritz」とは
違った方向性を目指すことになりました。
配布形態の変更：PC⇒スマホ（技術話）
区切った後の文章データだけを同梱することで、
以下の２点の技術課題も解決できました。
自動区切りツールがまだ不完全であること、
形態素解析ツールまで含めた配布は重くなってしまうこと、です。
文章データだけの同梱ならば、これらの課題は発生しません。
配布形態にも自由が生まれました。
形態素解析をしない「読むだけ」なら、
スマートフォンのアプリがビューアとしては最適です。
Electron から Monaca へ載せかえることにしました。
Monaca は、
Cordova（旧PhoneGap）のクラウド型統合開発環境サービスです。
AndroidとiOSの両方に対応したアプリが
HTML5+JavaScriptのWeb技術で簡単に作れます。
JavaScriptベースのエンジンで作成していたため、
このような載せ替えが可能なのです。
詳細は下記の記事をご参照ください。
Android＆iOS＆Win＆Macが同じコードで動く！超マルチアプリを作ろう[Monaca × Electron]
RhinoとKuromojiからの脱却（技術話）
ところで、当初のPCソフト路線で行く場合、
どうやってJavaScriptから形態素解析を呼び出そうと
していたかというと、結構変わった構成にしていました。
「Kuromoji」というJava用の形態素解析ライブラリを、
JavaScriptから叩く構成です。
「Rhino（ライノー）」というJavaScriptのコードを
Javaのクラスへと変換するツールを経由しており、
ソフトスタック的にかなり複雑で、
自分が使う分には良いのですが、
配布用にパッケージングするのがかなり複雑になってしまいます。
形態素解析部分はサーバでAPI化する案もありつつも、
それは運用が手間になる＆クラウド費用が発生するため、
ローカルで全てが完結するようにしたいと考えていました。
後日、その構成は捨て、Python + mecab に完全移行しました。
Python + mecab の方がいろいろ作りやすかったです。
自動区切りツールを更新して、手動チェック不要の
完全自動化を目指す際に、全コードを移植することになりました。
現在では、自然言語処理系はやはりPythonが強いかな～、
という、移植後の恩恵を感じています。
青空文庫のデータもそのままでは平文になっていないため、
かなりの加工を要するのですが、そうした加工処理も
Pythonならば先人たちの叡智を取り入れることが可能です。
瞬間速読の誕生秘話③：アプリ作成は大変？
Monacaは個人開発（スマホアプリ）に最適
Monacaはスマホアプリの個人開発に最適なツールだと思います。
クラウドでも開発でき、開発環境の準備が要りません。
また、面倒な「配布用パッケージの作成」についても、
かなり分かりやすく、環境が整っていると思います。
個人で、Android/iOS両方に対応することが容易にできます。
しかも、基本無料でもアプリリリースまでできます。
また、UI部品を作る際に、
CSSなどのWeb系の技術をそのまま流用できるため、
世の中に多数ある情報を用いることができる点も強みです。
個人開発の場合、最小の手間で、
最も公開したい箇所をMVPとして出したいですよね。
一方で世の中はAndroidとiOSで二分割されており、
ユーザテスト段階にしても両方への対応を見込みたいところです。
この両立が可能なMonacaは偉大だと思います！
温泉UIにハマる（技術話）
「瞬間速読」では、Onsen UIを採用しています。
Monacaでのスタンダード的な存在です。
ページ遷移等が綺麗にできて便利です。
当時、OnsenUI2.X系が既に出ていました。
しかし、１点だけどうしても受け入れられない仕様があり、
その点だけで、全てOnsenUI1.X系で開発することにしました。
それは、公式ページにもある以下の部分です。
すべてのコンポーネントでiOSとAndroidマテリアルデザインに対応し、
実行する端末にあわせて自動的にスタイルを切り替えます。
Onsen UIを使うことで、AndroidとiOS向けアプリの
ソースコードが遂に共通化されます。
iOSでもAndroidでも同じコードにしても、
自動的にiOS向けボタン、Android向けボタン、のように
UIコンポーネントを切り替えてくれるということで、
ご丁寧に、色も異なります。
（デフォではAndroidは青っぽく、iOSは緑っぽい）
iOS向け、Android向けごとにきちんと、
プラットフォームごとのデザインルールに合わせたい、
という人には良い話かもしれませんが、
たいした工数もない個人開発者にとっては最悪です。
見た目や、コンポーネントのサイズも異なるため、
コードが同じだとしても、
テスト/確認の時間が２倍になってしまうのです！
デザインを全て一本に寄せる設定等を探したものの、
当時の時点では見つからなかったために、
その機能の無いOnsenUI1.X系に戻す、
という禁断の大技を使うことになってしまいました。
こだわった点 ＝ 簡単＆安心
アプリ開発においてこだわった点は、
簡単＆安心でした。
まず、簡単に使えること。
アプリの説明自体を「速読」できるようにしました。
最初に「スタート」を押すだけで使い方が分かります。
UIも凝ったものではなく、スタンダード的なものの集合です。
次に、安心して使えること。
アプリの権限や課金、通信の問題です。
Androidアプリで、よく分からないのに写真やストレージへの
アクセス権限を求めてくるアプリ、不安になりますよね。
余計な権限利用は一切排除し、
課金への誘導も皆無、何かのアカウント連携も不要、
広告や通信も不要（URLリンクすら無し）で、
誰にでも安心に使ってもらえる設計にこだわりました。
これは、配られたカードで勝負するしかない （スヌーピー）
の方針でもあります。配られたカードで最大効果を工夫します。
技術力が低く複雑なことはできない、
デザインセンスもなく、開発時間も無い、
これらの制約も、言い方を変えれば強みになるかもしれません。
リリース後のエピソード
リリース当初の反応について
まずAndroid版のみをリリースしました。
最初の数ヶ月は実は、反応は非常に少なかったです。
ダウンロード数も伸びません。
しかし、ポツポツと良いコメント等は頂いていました。
まずは自分の想いを形にできたということと、
一部の賛同者が得られたことに満足でした。
アプリのでき自体は全期間で一番低い状態でありながらも、
この時期のレビューコメント/メールは全期間を通じて、
最も好意的なものだったと思います。感謝。
急激な増加！！
５ヶ月がたったころ、半分忘れていたような時期です。
急激にダウンロード数もコメントも伸び始めました。
１日２０以下のダウンロードだったのが、
１日１０００を超えることもありました。
そして、すぐに累計十万以上のダウンロードになりました。
急激に増えた理由は未だよく分かっていません。
GooglePlayの仕様で、良い評価/継続率のアプリが
検索上位に表示されるようになったことが、
最初のトリガーのように見えます。
その後、いくつかのサイト等で紹介されるようになり、
雪だるま式に増えたようです。
良い反応が得られたので、アプリを更新することを決意します。
本当は宣伝をするべき？
宣伝行為は一切無し。
アプリの紹介サイト等への登録も無し。
アプリ内からレビューへの誘導もしていない。
レビューへもコメントしていない。
アプリ内の操作ログなどをとって分析もしていない。
TwitterなどのSNS連携機能なども一切無し。
通常アプリをリリースしたらやるべきとされていることの
真逆を行くような状態でした。
「いいモノなら、いつか理解者が現れる」
と言いたいところですが、今回は運が良かっただけでしょう。
本当は手間を惜しまず各種アピールをしたほうが良いです。
たまたま、ライバルアプリが少ないジャンルで、
GooglePlayの検索が優秀だったから浮上したのであり、
それでも半年かかっています。
未だ「知る人ぞ知る隠れた名作」的な表現がよく付与されます。
通常、多くの人に使って欲しいならば、
セオリー通りに地道に対応を行った方が良いでしょう。
しかし逆に言えば、リリース直後に反応が伸びなくても、
後日急浮上する可能性も大いにあります！
本当はマネタイズをするべき？
宣伝をやっていない理由は、
そこにモチベーションが湧かなかった、からでしょうか。
趣味として作っていたため、
ユーザ数やマネタイズなどはあまり気にせずに、
「（独創的な）アイデアを形にしてみたい」が
主要なモチベーションだった気がします。
ほぼ同様の理由で、マネタイズについても「面倒」に感じていました。
「瞬間速読」以外にも、数万単位のDL数のソフトならば
過去に何本か出していました。「瞬間速読」についても、
ある程度DL数が伸びると、売れば儲かるじゃん、的な話や、
マネタイズしてナンボみたいな説を唱える人が、気になりだします。
毎回、自身の気持ちを言語化出来なかったのですが、
最近では「アンダーマイニング効果」を嫌ったのかな、と思っています。
報酬がQiitaを阻害する「アンダーマイニング効果」（人間とは、かくもヘンテコな生きものなり）
上手な課金システムを考えるよりも、
やりたかったことに注力できるように、という感じでしょうか。
チャンスがあれば、マネタイズはしてみたいですし、
全否定するわけでもありません。
なお、10万DLを超えると、
様々な広告プラットフォームからの広告掲載のお誘いが増え、
特にGoogle様からも、Google謹製アプリ内広告のお誘いも来ました。
モチベーションの変化
モチベーションへの反映以外に開発対価が無い状態のため、
☆４以下はどんな理由であれ更新したくなくなります。
☆５＆コメントやメールは、かなりモチベ上昇します！
特に評価を大きく気にしているわけではないのですが、
「気持ちが通じた」ような感じがあるかどうかでしょうか。
素っ気の無いシンプルな見た目なのに
過分なお言葉をいただくことも多く、いつもとても喜んでいます。
リリース前とリリース後では、
ユーザのみなさまの反応が生じるため、
モチベーションの内容が少し異なっている実感があります。
作りたいところを作っている点では同様ですが、
たとえただの作業であっても、☆５コメントの要望や、
お手間にも応援メールをいただく要望には、
積極的に応えるようにしています。
このへんの心境の変化は個人開発ならではでしょうか。
アプリの更新時もいろいろ
思い出深い/興味深い機能追加は？
公開以来既に５回の大更新を行い、
様々な要望への対応や、新機能追加をしてきました。
特に思い出深い/興味深いものを挙げてみます。
- iPhoneへの対応（iOS版の公開）
- 自動区切りツールの変更 ⇒ 文章の大量追加
- 速読中はスリープしないように改善
- 文章一覧の選択機能（アコーディオン型メニュー）
iOSのアプリ公開作業は控えめに言って最悪
開発作業中で最も苦痛が生じるのは、iOS版の公開作業です。
１年後くらいにiOS版も公開することにした際の話です。
Androidのアプリ公開はかなり楽です。
一方で、iOSのアプリ公開は、
最初の公開から、毎回の更新時も、常に悩まされ続けました。
鍵生成～署名～リリースの工程が多く、説明も英語で、
作業のたびにとてもストレスを感じます。
クラウド開発できるMonacaを使っていても、Macでの作業も強要されます。
アプリリリース後の状況確認サイトも超使いにくいです。
分析系のサイトと開発系のサイトが分かれているのも意味不明。
ちょくちょくApple都合の余計な追加も発生し
（プライバシーポリシーのURLをつくれ、だの、
○○サイズの画像を用意しろ、だの）
さらに、毎年一万円以上ずつAppleにお布施を支払う必要があります。
Googleは初回登録の3000円程だけで、あとはずっと無料です。
笑えたのは、最初の公開時、アプリをAppleが審査する際です。
英語でやりとりしなければいけないのですが、
スクリーンショットにある日本語の文言を変えろ、
という指摘を受けました。
中の人（多分日本人？）は画像内の日本語を読んで指摘しているのです。
わざわざ英語に言い直しての指摘だったので、
どの箇所を言っているのか分からず聞き返してしまいました。
開発者側のユーザビリティや、やりとりの効率性よりも、
Apple内の規則や統一性を優先しているのですね。
なお、Googleは（審査はありませんが）日本語でのQAが可能です。
ついでにXcodeも大嫌いで、今回Swiftは１行も書いていません。
それでもiPhoneアプリを出すことが出来ます。そうMonacaならね。
AppleはDeveloperに対するUXは最低なものを用意していると感じます。
iPadやMacはUXに優れた端末で私も好きですが、この点は大変残念です。
文章（コンテンツ）の大量追加は最も大変！
当初リリース時は、手作業で文章の区切り結果のチェックをしていました。
一方、もっと様々な種類の小説を読みたい、という声はとても多かったです。
多少の誤りは含んだとしても、完全自動で区切ること、は
リリース当初からの一つの目標でした。
それができれば、文章の大量追加も容易になります。
（最終的には、「三国志」全巻なども追加しました）
また、もう一つ大きな問題は、青空文庫のデータの加工でした。
青空文庫のデータは、shift-jisに存在しない文字を
特殊な注釈表記で示していることを始めとして、
そのままでは微妙に扱いにくい場合があります。
これだけでとても長くなる話なので、ここでは
いろいろやって大変だったなぁ、という感想だけで省略します。
スリープ＝ネイティブの機能をイジる（技術話）
速読中はスリープしないように改善、は、
一見たいしたことの無い話なのですが、
実は Monaca の弱点の話です。
HTML5による開発の弱点は、Android/iOSのネイティブの機能を
触りにくいということです。
スリープについては「プラグイン」があり、
それを利用することで実現できました。
カスタムプラグイン利用は、Monacaに有料課金（年二万円前後）
をした場合に使える機能です。逆に言えば、コレを導入するころまで、
Monacaも無料ユーザのまま利用させていただいていたのですね。
技術的なポイントとして、プラグインを入れてしまうと、
そのスリープ関連機能は実機でしか動かなくなるため、
デバッグ環境での動作時にエラーになってしまいます。
しかし、エラーが発生しても無視するtry-catchによって、
強制的に握りつぶすことで、デバッグ環境との両立が出来ました。
他にも、ネイティブ機能にアクセスする手段はいろいろありますので、
たとえばカメラやGPSを使うアプリの開発も可能です。
アコーディオン型で文章を一覧化、予想外のこと
大量に文章を追加すると、
だんだんプルダウンでは選択が厳しくなってきました。
そこで、作家ごとに閲覧できる、
アコーディオン型のメニューを実装することにしました。
JavaScriptとCSSだけでも、アコーディオンメニューが作れるのですね。
しかし、最大の問題は、既に文章が100を超え、
作者自身が、どの文章を入れたか
把握しきれなくなってきていることかもしれません。
そして、「DB」無しで、ソースコードに直接100個以上の
選択肢を書いて実装してきた限界を感じています。
同じ文章名がコード上の複数の箇所に登場しています。
逆に考えれば、「DB」などの構造化をしなくても、
ソースコードへの直書きでも、なんと20万ユーザ以上行けるのです！
最初から綺麗に、保守性高く作らなくても十分です！（違
めんてなんす、するかどうかもわかぬまに、
くもがくれにし、りりーす計画現代語訳：
将来更新するかどうかも分からない段階から、
メンテナンスのことを考えて、綺麗なコード化や
汎用化を繰り返していると、時が経つのは早いもので、
まるで雲間に隠れてしまう夜半の月のように、
いつのまにかリリース計画も消えてしまうよ。
なにごとも優先度とバランスが重要という歌。
～～民明書房刊「百ＭＭ一集」より～～
～ To be continued ～
個人開発 is 何？
もう「TL;DR」なので終わりにします。
まだまだ、瞬間速読の個人開発を通じて
得た知見や経験の半分も書けていません。
時系列的にもほとんどが、iOS版をリリースした、
2017年7月あたりまでの話でした。
- 「アイデア」の話
- 「UX」の話
- 「試行錯誤」の話
- 「設計」の話
- 「開発技術」の話
- 「モチベーション」の話
などなど、様々な種類の話が相互に関係した、
私にとっての一つの大きな「物語」を綴ってきました。
個人開発とは、ただそのモノを作るのではなく、
自分にとっての「物語」を作ること、
「物語」になる行為、だと思っています。
そして、物語はまだ終わりではありません。
これからの物語を作るのは、そう、
「瞬間速読」をダウンロードしていただいた
「あなた」です。
私も今後の展望等、常に現在進行系で考え続けています！
この物語が、あなたの物語になにか影響を与えるかもしれません。
そしてあなたの物語がまた私の物語に影響を与えるかもしれません！！
以上です。
もしこの長文にお付き合いいただいた方がいらっしゃれば、
大変ありがとうございました。
※この物語は、個人の「感想」を綴ったものです。
この物語の中の、考え方や感想については、
おそらく否定的な人、別の考えを持つ人もいると思います。
それはそれで、ぜひ別の物語を奏でてほしいと思います。
たとえばAppleの素晴らしさについてや、
速読の様々な方法についての「異論」があることは
百も承知なので、その種の宗教論争はコメントをお控えください。
私の感想であり、当時このように考えた、という話であって、
意見を主張したい性質のものではありません。
考え方が別であっても、それを押し付けるようなものでなければ、
その別の考え方の人の物語はとても参考になり、私は好きです。