白い悪魔No.0494、
アイデアノート

何処からが過剰品質、過剰設計なんでしょうね?

多少なりとも、評価の星の数を稼いでいるも、まだまだ弱いです。

問題点というのはその場に立った時に見えてくるもので、まだまだ対応しないといけないことがあります。

単機能アプリなんですが、お客さんに設定してもらうためのチェック項目が20以上、、、

それら全てに専用のインターフェイスを用意しています。

ここら辺には、機能説明のページも含まれます。

弱小アプリ、、、そして実績の無いアプリ製作者が使えば判るだろう的な対応をすると、興味を持ってくれているお客さんをみすみす逃してしまう可能性があります。

人間、駄目だと判断する見切りは早く、30秒だと言われていますが、それは最終判断であって単に「好き」「嫌い」のレベルであれば1秒あれば十分です。

30秒というのは、その最終判断、、、自問自答を何回か繰り返した後の結論であり、少なくとも30秒の間に良いところを見つけられなかったら終わりな訳です。

これが、友人知人からの紹介とか、評価点数が高いとか付加要素があれば多少なりともアプリのライフサイクルは伸びますが、それだけです。

そういう、良い悪いの境界線にあるアプリっていうのは、評価を上げるために最大限の努力をしないといけない訳ですが、標準品質と過剰品質の違いって何処?って感じなんです。

これが二次加工品なら判ります。

原材料を仕入れて組み立てて出荷する電気製品なら、、、

でもアプリってソフトウェアって、、、その品質の違いって一言で言うと人件費だけです。

何処までが、適正で何処からが過剰なのか判らないんです。

工期と工数が決まっていても、それで完成したものが売れるものである保証はありません。

売れない=品質が悪い という図式が当てはまると考えた場合、売るためには品質を上げるしかなく、、、それは当初の見積もりを超えた作業、、、

何も知らない現場を知らない上の人間からすれば、過剰品質な訳です。

これが、会社で作っているアプリならまだ、標準品質か過剰品質か判断はし易いですが、、、個人が作成しているアプリの場合は、、、

目指すゴールを正規の品質と考えた場合、目標が高ければ高いほど、初期のアプリは低品質な訳です。

そして定期的にバージョンアップを行いゴールを目指す訳ですが、場合によっては大幅な仕様変更、、、互換性が無くなるほどの仕様変更も必要になるわけです。

そういう節目節目は大胆にそして強引にやらざるを得ず、私の場合今がその時期です。

前バージョン比で300%の性能向上、、、

まあ、はまっています。

地道に作業すれば、手戻りが無いように作業をしているので作業を進めれば必ず終わるのですが、、、まあ、何処までが適正範囲なのかなと、、、

因みに売れる売れないの判断で、同業他社と比較したって無意味です。

同一条件で陳列棚に置かれる訳ではありませんし、知名度が無ければ尚更、、、

結局はアプリ自体の魅力を高めないと話にならない訳です。

個人製作者の場合、自分との戦いです。先が長いです。

白い悪魔No.0493、
アイデアノート

アプリを改造しながら、データ整理をしています。

一人作業、、、仕様書を作らずに作っているので、時にはへんちくりんな関数が出来てしまうわけです。

それでも使っているウチは良いのですが、そういう関数に限って名前が適当過ぎて後から見たら分からないというのも有るわけです。

今、その関数が使われているか、、、

まあ、幾つか使い方はあるのでしょうが、

論理式に絡めない変数というのは、まず間違いなく要りません。

今回、var P1=255

という記述で何に使っているかすら判らない関数がありました。

それが必要か不要かを判断するためには、Swiftだと P1==

と検索を掛けて内容を確認するのが一番手っ取り早いです。

アプリ開発者なら常識かもしれませんが参考までに、、、

1個機能を付け加えたら、優先順位の低い、機能、変数を1個、2個消すぐらいの気持ちが無いと規模が大きくなってしまい管理出来なくなってしまいます。

使わない、使う予定の無い機能は早めに消しておいた方が良いですよ!

白い悪魔No.0492、
アイデアノート

No.491の続きです。

因みに私は真似をするにしても、要素分解しますので、それをミックスしますのでまず判らないでしょうね!

ひとつひとつは、その業界での至極真っ当な常識を色々な分野から引っ張ってきてリミックするので、、、