04/【前篇】作家必見!岡田斗司夫流『アイデアの作り方!』 – YouTube
話の中で「デスノート」を無理やり、少女漫画にすると、、
というお題がありました。
アイデアの出し方の、講義、、
この考え方は、自分も使っていて、自分は「要素分解」と呼んでいます。
さて、デスノート、、
「ノートに書かれた人は死ぬ、、」という話、、
そして、悪魔がその様子を傍観して面白がっている話です。
そして、犯人を探している人がいる話、、
「夜神月」を心棒する人がいる世界、、
今はアプリの開発、思ったこと、気付いたことを書いています。
04/【前篇】作家必見!岡田斗司夫流『アイデアの作り方!』 – YouTube
話の中で「デスノート」を無理やり、少女漫画にすると、、
というお題がありました。
アイデアの出し方の、講義、、
この考え方は、自分も使っていて、自分は「要素分解」と呼んでいます。
さて、デスノート、、
「ノートに書かれた人は死ぬ、、」という話、、
そして、悪魔がその様子を傍観して面白がっている話です。
そして、犯人を探している人がいる話、、
「夜神月」を心棒する人がいる世界、、
アプリ、、
1本、売れちゃいました。
売れていないから、売れていないからこそ、、
自由に、、大胆に、、
互換性なんて無視して、、
アプリを改修している最中に、、
精一杯の力で、、アプリを作ってっいっても、、
今月末、、
それまで売る気なんて、無かったんですが、、
旧バージョンからのバージョンアップで、
クラッシュしないくらいの互換性はありますが、、
データの互換性が一切なくなります。
まあ、結構な金額のアプリ、、
ヨーロッパで1本売れたところで、、
大勢に影響はないと思いますが、、誤算でした。
不具合を見つけたら、、
色関係のシステムを変更したので、
そこら辺は未完成ですが、
それ以外は、今日1日で一通りの対応が出来そうです。
そして、内部で泥臭いことをやっていても、
目に見える結果が良ければ良いのです。
作りの悪いシステムは、後から作り直せば良いんです。
アイデア先行で作成した部分は、、後先考えず非効率の方法で機能を実装していたりします。
悩んで先に進めない事態に陥ることがありますが、
やり直し前提で実際にやってみると
案が簡単に出来たりします。
まあ、自分、、無理無理に完成させれば週末に行けそうな気がしますが、
まだまだ、変な思い込み、こだわりがシステムに残っている可能性があります。
功を焦っても、、
ロングラン商品を目座sなら、大ヒットを目指すなら、、作り込まないと、、
現実、、コストを掛けずによいものを作れ、、というのは無理なことです。
売れるには理由があり、
その価値が、販売価格より上回っているから、その商品を買うんです。
低品質な、無責任な商品は、、自分のブランドを下げるだけです。
力足らずはしょうがないですが、最良な状態でリリースしたいと思っています。
トイレの修理に、、
そして、教えてもらいました。
ここが欠陥住宅であることを、、
衝撃の告白です。
ここに住んで7年、、
トイレ、、シャワーが壊れても
おかしくない時期なのは、
電気回路に少しでも知識がある人なら分かるはずです。
電気回路では、まず、先に電解コンデンサが死にます。
この部品が厄介で、、
電解液に確か、希塩酸を使っているので、、
破裂すると、、電気回路のパターンを溶かします。
それじゃなくても、、この部品、、
言わば、ウエットティッシュみたいなものです。
電解液が、、文字通り液体なので、、自然に蒸発します。
確か、寿命が6、7年じゃないかな?
そして、厄介なのが周辺温度に関係すること、、
高温な場所で使うと、、通常より早く壊れてしまうという代物です。
死ぬリスクが高いので、
短い間隔でのバックアップが欠かせません。
お出掛けの際のメモを見て、、
アプリを修正し始めました。
そして、ノウハウが盗まれたって構わないという考え方になっています。
アプリ内で、記号として付けている変数を、
内容が予想できる名前に書き換えています。
売れた時のことを考えるより、
現実を見ろ、、目の前の自分の作業を簡単にしろ、、ってことです。
売れたら、売れた時に、そのことを考えれば良いんです。
今、考えてもしょうがありません。
それに以前、書きましたが、
言語化出来ないセンスをどうやってコピーするの?って話です。
出来上がった成果物を見て、その先にあるもの思想は読み取れません。
どうせ、わかる人には分かってしまうんです。
それに、それをノウハウとして文章化しようとしても、
それらを示す基準も言葉も無いんです。
一目見てばれるノウハウなんて、、気にしていても仕方がないんです。
今、アプリの変数関係の名前を、構造を変更しています。
いつ、ハングアップしてもおかしく無い状況、、
そして、いまだに販売数が0、、
それをプラスに捉ええ、初版と互換性のない、
今の自分の理想系に仕上げています。
自分が思い描く、お客さんのためのアプリに、、
流石に、自分も、、昔に比べて、、より客観的に自分のアプリを見れるようになりました、、
そこで、出てくる何故は、、
お客さんも聞いてくる何故です。
その何故を可能な限り減らすことが、、お客さんのため、自分のためです。
将来の自分のため、将来、自分が楽をするために、、
今、地獄を見ようとも、、やらないと、、
お金儲けは大変です。
でも、頑張れば、不労所得が手に入ります。
まrっきり労働が0になるとは思いませんが、
労働と、手に入る収入がまったく比例しない所得、、
それが、自分は不労所得と考えています。
うまくやれば、寝ている間に、、アメリカとかでアプリが売れる訳です。
逆に昼間、、日本ではまったく売れなかったり、、
その間、アプリのメンテナンスを行っているのに、、
けっこう、根本的なところで間違いに気付いたんです。
ゲームで例えると、、
致命的な間違いで、、
そんなシステムを採用するゲームはクソゲーと言われてもおかしくない
という致命的なシステム的な不具合です。
初めて遊ぶゲームで、、
全てのステージを選択できたら、、
これがまだしも、クリアしたステージまで選択できるシステムなら、、
それはユーザーにやさしいシステムと評価されるでしょうが、、
それと、ゲーム内で保存したアイテム、、
みな、同じような形をしていて、違いがわからないんです。
まあ、自分のアプリは写真加工アプリですが、、
ゲームで言うところの上のようなミスをしてしまったんです。
初めてアプリを触るユーザーには選択肢を与えてはいけません。
こだわったゲームで、、
武器を左手で持つか、右手でも持つか、、
そんなことをユーザーに聞いては駄目です。
早くゲームを始めたい人間に対して、
カスタムでこういうことも出来ますという選択肢を出しちゃあ駄目なんです。
毎日、やっていることが違います。
そして、先のことを見据えてても、
時間を掛けて検証していないことを、そういう機能を実装するのはリスクが大きいので
今回、それを盛り込むことをやめようと思っています。
それで、1行メッセージの説明文を作成しているんですが、
これが難しくて、、
前提条件が必要な機能の場合、、説明を書くのが面倒なんです。
そして、ついさっき、無難な書き方に気付きました。
さて、自動販売機で考えてみましょう、、
ジュースのサンプルの下に、、ボタンが配置されている訳です。
このボタンの説明を、、どう描くか、、
ジュースを購入しました。 と書くと、それはおかしいわけです。
お金を入れていないのに、、
ジュースを購入します。 と書くのも、
お金を入れて購入したのに、、
つまり、
購入金額が入れらrた、入れられていないで条件分岐して、
メッセージを切り替えないといけないんです。
ここで求められるメッセージは、
・そのボタンを押すとどうなるかの機能説明
・条件がクリアされた状態でそのボタンを押した時の結果、、