{民主主義}{一日一文}{お目汚し}{世にも珍しい}{人気サービス}{有名サービス}{デライト収益目標達成}{デライトの現状}{安定拡大戦略}{超低経費}...=}(147)

{ネットサービスにおける「成功」とは何か K#F85E/A-E74C-A43E}

ネットサービスで「成功」と聞くと,有名で,人気があって,という感じにイメージする人が多いだろう。ただ,サービス開発現実はそこまで単純ではない。企業は,顧客投資家の手前,明るい側面ばかり見せようとするものだ。世の大抵のサービスは,何らかの意味で「火の車」だと思って間違いない。

デライトも一応ネットサービスに含まれるし,今は収益目標達成に向けて邁進しているところだ。利用者の方から色々な助言を頂くこともある。その中で,外から見た「成功」と内から見た「成功」の違いについて考えさせられることが多い。


デライトは,「安定拡大戦略」と呼ぶ戦略を取っている。その名の通り,急拡大を避け,制御可能な範囲で安定的拡大を続けていく,という戦略だ。つまり,世間でイメージされるような,バズって有名になって上場するなり売却するなりして大儲け,というような「成功」は,元よりデライトの目指すところではない。それどころか,避けたいとすら思っている。

これは,デライトが希哲館事業一環として開発されているからだ。希哲館事業は,知能増幅(IA)技術による民主主義資本主義革新目的とした事業であり,その性質上,独立性生命線にも等しい。

ソクラテスが何と闘い,何に殺されたのかを引き合いに出すまでもなく,権力権威大衆は,どれもが従ってはならないものだ。出資に頼ることも寄付に頼ることも出来ない。となれば,自分で稼げる範囲で運営していくしかないわけだ。

投稿で賑わっているのが成功しているサービスかというと,それも難しいところがある。閑古鳥が鳴くような状態も困りものだが,低質悪質な投稿であふれ返っているような状態がデライトにとって望ましいとも言えない。特に恐れているのは,よくいう「コミュニティ空洞化」だ。悪貨が良貨を駆逐するような状況に陥いることは何としても避けたい。

個人開発サービスによくあるのが,何かの拍子に爆発的人気を得たものの,運営費などが捻出出来ず,どこかの企業売却あるいは譲渡せざるを得なくなった,という例だ。それなりの金額で売却出来れば成功と見る人もいるが,デライトでは最悪の失敗として想定している。

デライトは,希哲館事業心臓のようなものであり,万が一にも手放すことはない。手放すくらいなら心中するという覚悟開発している。


デライトは,今のところ,有名サービスでもなければ人気サービスでもない。では上手く行っていないのかというと,面白いことに,世にも珍しいほど上手く行っているサービスなのだ。

世界初の実用的な知能増幅技術を実現した輪郭法という基礎理論は,私が17歳の頃に考案したものであり,デライト実装も全て私の手によるものだ。周辺技術もオープンソース基礎として独自開発最適化したものを応司(OS)から論組プログラミング言語範枠フレームワークにいたるまで整備している。

例えば,用合い(UI)設計語体ロゴタイプアイコン制作といったことから,論組プログラミングサーバー管理広報経営まで,とにかく何でも一人でやっている。デライト上にある中核的献典コンテンツも私が書いている。

別に自慢話をしているわけではない。これが意味することは,デライト驚異的高効率開発運営されているということだ。普通の開発現場というものを知らなければなかなか想像出来ないことかもしれないが,サービス開発者にとっては喉から手が出るほど欲しいような環境を,すでに手にしているのだ。こればかりは,GAFA のような超大企業が金を積んで手に入れられるものでもない。

人件費がかからないのは言うまでもないが,中核となる全ての権利権限開発者が保有しているので,組織ならどんなに早くても3日かかるような意思決定が,目を瞑って3分で出来たりする。

サービスそのものも,利用者の方々のおかげで,開発快調治安良好トラフィックは安定的に成長しているという理想に近い状態にある。

収益目標達成というのは,まともに稼げていないという点以外はほぼ完璧デライト完全無欠にするための挑戦だ。それも,決して非現実的目標ではなく,見通しは明るく,時間は十分にある。しかも,超低経費のおかげで,仮にずっと稼げないままでも開発者が生きている限り潰れる心配は無い,ときている。

華々しく成功しているように見えるサービスのほとんどは,人間的金銭的技術的な何らかの問題を抱えながら運営されている。それを考えれば,まだ成功と言うには早いが,「デライトが目指す成功に最も近付いているのはデライトである」とは言える。


……昨日,早くも3日目にしてサボってしまった一日一文だが,今日は取り返そうと少し長めに書いた。

気合い空回り疲労のせいか,思っていたよりくどく,何が書きたかったのか分からない文章になってしまった。お目汚しだが,開発者デライト現状をどう見ているかの参考までに残しておく。

{希哲15年3月24日の開発}{公開範囲設定機能}{公開範囲}{非公開機能}{希哲15年3月24日の進捗時限}{希哲15年3月24日の進捗}{希哲15年3月24日}{描き直し}{検討}{中景部}...=}(23)

{希哲15年3月24日7歩 K#F85E/A-E74C-F654}

非公開機能一般化した「公開範囲設定機能」を検討して終了。

中景部左上に公開範囲を表すアイコンを表示し,描き直し時に押すと選択肢が出る。無制限,登録利用者のみ,指定利用者のみ,自分のみ,を想定しておけば十分だろう。

新規描出フォームでは最後に選択したものを記憶させ出放りとして機能させる。

=}
{希哲15年3月24日の開発}{盛り込める}{譜類選択ボタン}{追加要素}{思い付いた}{自動挿入}{希哲15年3月24日の進捗時限}{希哲15年3月24日の進捗}{希哲15年3月24日}{希哲15年3月11日11歩}...=}(38)

{希哲15年3月24日5歩 K#F85E/A-E74C-035F}

譜類添付機能について検討して終了。

11日11歩である程度の方針は出来たが,用合いをどうするかが解決していなかった。

添付譜類が存在することを示すアイコンを置くにしても,現状の吹き描き見苦しくない領当てをするのは難しい。どうしてもごちゃごちゃしたものになってしまう。

そこで,渡括記法を使い,+[拡張子] の形式で描写自動挿入してしまうことを思い付いた描き直し時,描写に含まれていない譜類削除するようにしておく。この参照形式は元々考えていたことだが,こういう活用法があることは発見だった。

これなら用合い上の追加要素譜類選択ボタンのみで良く,実装半日もあれば十分だ。

これで新生デライト盛り込める

=}
{デラング}{希哲15年3月23日の開発}{ややこしい}{見え方ボタン}{閉じるボタン}{最有力候補}{難しかった}{ボタンラベル}{大きな理由}{多機能化}...=}(72)

{希哲15年3月23日7歩 K#F85E/A-E74C-66D7}

デラング整備,「描き方ボタン」について仕様をまとめて終了。

デラング多機能化に伴い,学習宣伝等の観点から,他輪郭描写素文をもっと閲覧しやすくする必要が出てきた。

現状,Ctrl + ダブルクリックで閲覧することは出来るものの,ボタン自輪郭描き直しボタンのみ表示しているため,説明されなければどのように素文を見るのか初心者には分からない。

描き直しボタン追加時からしばらく全ての輪郭でそのまま表示していたが,紛らわしく,用合いもずっとごちゃごちゃしている時期だったため他輪郭では非表示にするようになった。

調整して復活させることは度々考えてきた。そのたび見送っていた大きな理由に,良い表現が見つからないということがあった。特にボタンラベル等に使う文言難しかった

簡潔かつ直感的ということで最有力候補は「覗く」だったが,漢字を使うと少し印象が硬い,平仮名で「のぞく」では「除く」と紛らわしい,語感もあまり良くない,そもそも何を覗くのか初見分かりやすいとも言えない,と一番マシな案が難点だらけだった。

今回の再考で,「描き方」が使えることに気付いた

描き直しボタンアイコン領当てはそのままに,ボタンラベルは「描き方」に変える。機能描写部Ctrl + ダブルクリックした時同様,描写欄のみ開く。

知名欄でも一部デラング記法を使えるようにする予定はあるが,利用頻度を考えると余計に感じることが多いだろう。従って,描写部が無い他輪郭では引き続き非表示とする。見る手段がないわけではないので困ることは少ないはずだ。

描き方ボタンで開いた場合,完了ボタンはもう少し自然に閉じるボタンにする。「見え方ボタン」にするのも面白いかと思ったが,かえってややこしいかもしれない。

「〜で描き直す」「〜で完了」から変えていなかった通注も「〜で描き方を見る」「〜で閉じる」とする。

=}
{希哲15年3月16日の開発}{共有アイコン}{くの字形}{試作共有アイコン}{アイコン制作}{希哲15年3月16日の進捗時限}{希哲15年3月16日の進捗}{希哲15年3月16日}{フィードボタン}{共有ボタン}...=}(37)

{希哲15年3月16日5歩 K#F85E/A-E74C-38AF}

アイコン制作続き。

共有ボタンフィードボタン用のアイコンを作っていったん終了。

フィードボタン用のアイコンはごく一般的なものだが,一応自作しておいた。

共有ボタンの方は少し悩んだが,三点をくの字形に結ぶアイコンを少し修正し,矢印が伸びるようにした。より拡散イメージが掴みやすい。

一点から二本の矢印が伸びるという共有アイコンの形は初期 Android採用されていたが,なぜか現在の形に修正された。

拡散というよりはネットワーク結合というイメージ強調したかったのかもしれないが,直感的とは言えない。

iOS では基本的に四角から矢印が飛び出すような徹案になっているが,正直これは更に色々な意味で分かりにくいと感じる。

デライト試作共有アイコンは,結果的に両者の折衷案になった。


主力機記憶器をしっかり使ったまま24時間安帯を越え,きびきびよく動いている。

=}
{開発初期}{Schema.org}{デライト文書構造最適化}{共有ボタン}{Web Share API}{希哲15年2月16日}{ページ構成}{輪郭ページ}{領当て}{最善の時期}...=}(34)

{希哲15年2月16日の開発 K#F85E/A-E74C-9903}

デライト文書構造最適化」に着手

デライト文書構造は,試行錯誤が多かったこと,開発初期 HTML5 要素採用消極的だったこともあり汎用要素,特に div 要素多用目立つ

整理するならページ構成領当ても固まった今が最善の時期だろう。HTML5 要素だけでなく,Schema.org 等の周辺規格も取り入れていく。

これまで導入を避けてきた共有ボタンについても進展

Web Share API利用し,輪郭ページに汎用の共有ボタンを一つ置くというのは悪くない,と考え始めた。API 非対応であれば非表示にすればいいかと思ったが,よく考えると,ずらずら SNSアイコンが並べられるのが嫌だったわけで,共有ボタンを押して選択肢として表示される分には問題ない。

ボタン見た目は,よくある1点から2点にが伸びるものの1点部分を輪郭記号にする形を考えた。

{アイコン}
{}