  |
はてなキーワード: 開発者とは
（ここでいうシステムというのはビジネスモデルの事ではなくて、サーバーサイドのシステムの話）
嫁がメルカリで出品される商品を買いたいがすぐに売れてしまったりするというのでアラートが欲しいと言い出した。
どうも標準である"保存した検索条件の新着通知"という機能はスピードや精度などがいまいちで使えないらしいのだ。
で、調べてみたところ2個ほどアラートアプリがあるようなのでそれを入れてみるように言ってみた。
しかし、それらのアプリでも通知結果が変だったりするらしい。（新商品の通知がきたのに、メルカリ本体で検索するとひっかからないなど）
うーん？アプリが悪いのかな？
と思ったので簡易的に通知スクリプトを書いてみることにした。
一行で書くと、
「検索結果ページを定期的にGETしてHTMLを解析して商品一覧を抜き出し、前回の結果になかったものがあれば通知すればいいだけ」だ。
うん。楽勝だべ。
よし、検索結果のページを解析するために見てみよう。何々、1件から48件まで表示中です。。
ふむふむ。で、結果がページ下にずらりと並ぶのか。
いーち、にー、さーん、・・・(中略)・・・・、よんじゅーろく。。 あれ？なんど数えても46件しかないぞ!
皿を数えるお岩さんの気分で何度も数えてみる。。が、やっぱり46件しかない。
「二枚足りなーい！うらめしやー！」
まあ、こんな事は些細なことさ。(CSSクラス名の単数形、複数形がおかしいとかももっと些細なことさ。)
とりあえずスクリプトを完成させるぜ。
・・しこしこしこ・・
じゃじゃーん！というわけでスクリプトはすぐにできたので、試しに走らせてみた。
・・・・
・・おお、結構な頻度で新商品がでるんだな、さすが大手サイトだ
・・
・・てか出品おおすぎね？こんなマイナー商品を検索しているのに1分間に7件も出品されるなんて
・・
・・( ,,`･ω･´)ﾝﾝﾝ？
・・
なんだこれは！検索結果にときどきゴミが混じっているではないか！
例えるなら、ドラえもんを10回検索したら、3回ぐらいの割合で巨人の星やマツコ・デラックスがでてくるような感じ。
通るかこんなもーん！！！
【結論】
某企業でコンサルタントとして開発業務をした経験を、コンサルタントになりたいと思っている方の参考になればと思い書く。
業務を依頼した企業の方達は基本的に大雑把な開発目標を書いた数ページのパワーポイント資料のみ使う。
こちらはその数ページのパワーポイント資料を元に開発を行うのだが、詳細な定義や指示などは書かれていない。どこにも詳細な資料はない。相手の方達の頭にはもっと詳細があるのだがそれでも曖昧である。
詳細を質問すると「当たり前」とか「自分で考えて」という回答率が高い。禅問答のようなやりとりで長時間になることが多い。
意図を推測しながら作業を行う。作業は毎日長時間になり、意図していたものと違うとやり直しさせられることも頻繁にある。命令口調で非常に疲れる。コンサルタントには業務範囲がなく何でも叶える必要があるのだ。
こちらも報告は基本的にパワーポイント資料で行う。こちらが作成した詳細資料は見る時間がなく不要だから要らないと言われる。
向こうの方達には専門知識が余りないと想定して資料を作る必要がある。曖昧でギャップが大きく適切に理解可能な資料を作るのが大変である。
報告のパワーポイント資料では、開発目標に必要な開発項目のパターンを尽くした一覧表を求められることが多く、表の大半のセルが埋まっている必要がある。
セルを埋めるために明らかに重要でないことを調べるのに多くの時間を使う。
曖昧だったり未調査項目があると徹底的に批判される。未調査の新規な内容があると批判されるので、数週間で開発できると分かってるのに、結局既存の手法や製品を利用して開発することになる。
非常に苦労したにもかかわらず、しょぼいものができる。
このような組がフロア内にいくつもある。他はもう少し詳細度が高く資料も作成しているようだが開発内容はしょぼかったと思う。どうやって上手く仕事ができるのか分からない。
いわゆる上流工程はこのような「お役所仕事」を指すらしく、全社的にこの方法で開発している企業が結構あると思われる。それが日本のソフト開発効率が悪く新規なものが出てこない理由の一つだと思っているが負け惜しみだろうか。
私は開発者チームに入って、詳細調査やサンプル付きの資料を分担して作成して理解しあって、数年で世界初と言えるシステムを開発したことも複数回ある。開発チームのメンバーはマネージャー等はいるが基本的には対等な関係だった。高度な専門知識も結構短期間でみんなが理解できるものなのだ。こういう企業にも何故か大抵せっかくの優れたシステムを継続的に改善していかないという別の問題がある。開発を行わないSEに引き継いで、優秀な開発者は別システムの開発に回されるのだ。
今では業務内容に「コンサルタント」や「パワーポイント」の用語を見かけると関わらないようにしているし、その手の経験をした企業とも（呼ばれないし）関わらないようにしている。
日本でソーシャルゲームがヒットして、およそ10年経とうとしている。プラットフォームはフィーチャーフォンからスマホへと移行したものの、相変わらず膨大な売り上げを生み出し続けている。この間、数多のタイトルが作成され、そして消えていった。これはソシャゲ開発のお話である。
ソーシャルゲームの開発は、他の業種同様企画から始まる。他社IPものであれば大手IPを扱う会社と連携をとり会社主導で企画は進み、自社オリジナルタイトルであれば社内で抜擢されたプロデューサーとなる人物が中心となって企画を書き上げる。会社の規模にもよるが、小規模企業で月商1億、大手なら月商10億を目指すことが目標だ。
その後、適任のデザイナー、プログラマー、企画を含め5,6人があつまりプロトタイプ制作が始まる。ゲームのシステムが組み込まれ、キービジュアルやゲームの雰囲気を決めていく。最終的には会社からゴーサインをもらうことが目的となる。
プロトが通れば、次に、アルファ（一部動かないものの、一通り遊べる）・ベータ（ほぼ全機能が実装）という順にマイルストーンが敷かれ、順に進めていく。多くのスタッフがこのアプリは月10億以上を売り上げ、ランキングで、モンストやFGOといったアプリと並ぶことを意識して仕事をする。
最初の問題はここで発生する。ソシャゲ企業はWebが前身なのだ。つまり、判断する人間が判断できないことが多い。唐突に素人意見を繰り出したり、かのスティーブジョブスを真似てちゃぶ台返しを何度も行う。本人は真剣に、これが経営者のあるべき姿だと信じている。
このような妨害をかわしつつ、のらりくらりとベータへ進んでいくが、その辺りで作業者は厳しい現実と向き合うことになる。これは、微妙なんじゃないかと気づくのだ。その頃、手が空いてきたプロデューサーとマーケターは呑気に広告計画を立てている。そして、いよいよローンチだ。多くの広告費が投入され、特設サイトや事前予約、プロモーションビデオが公開され、華々しい登場を飾る。多くのアプリはこのタイミングが一番ユーザ数が多く、売り上げも高い。逆にいえば、ここで数字が残せなかったアプリは早々に注意信号が点灯し、マーケターは顔を青くし、プロデューサはポーカーフェイスとなる。ここでのユーザ数と売り上げは新しいタイトルに対する期待感と広告費によって得られたもので、今後は開発したアプリの出来が問われていくことになる。使い勝手が悪い、バグが多い、サーバが止まる、ゲームがつまらない、思っていたものと違うなどといった理由で新しいユーザは次々と離脱していく。
そこで、いわゆる継続率という指標、インストールした日から1日後、2日後、そして7日後、30日後に何パーセントのユーザが残っているのかというデータを改善するため、マーケットや行動を調査し、どこにボトルネックがあるのかを調べ改善をするという動きが始まる。また、ユーザを飽きさせず定期的に課金してもらうため、運用が始まる。大抵新しく書き起こされた魅力的なキャラクターが、ローンチ時よりも魅力的な効果を纏って登場する。もちろんそれは、ガチャという形式で提供され、最上位のキャラクターは数万程度の課金が必要になるような確率で封入される。
さて、ローンチから3ヶ月が過ぎた。ここ最近のゲームは3ヶ月分程度の運用分を初期予算に組み込んでいるため、ここから実際に運用を続けるべきかどうかが真剣に判断されることとなる。ところで、この業界での売り上げの方程式は、「DAU（日間アクティブユーザー数）xARPU（ユーザあたりの平均売り上げ額）」だ。問題のARPUだが、ゲームの人気度やガチャの確率によるものの、大抵のゲームは月を平均すれば10円〜50円程度となる。もちろん好調でガチャのキャンペーンが当たっている場合、瞬間的に100円以上にもなる。これは、ユーザ数が少なくなれば作業に対する売り上げのうまみが減ることを示唆している。
ここで、運用の経費を概算してみよう。小さなゲームでも、10人〜20人程度は運用に携わっている。（大型タイトルだともっとだ）平均年棒500万円の給与として、月額41万円。ここで人件費の概算は+16%程度なので、一人47.5万円とする。20人で、約1000万円。さらにサーバ代。ちょっとしたユーザ数でも数十台、数百台規模のAppサーバ、バックエンドのDBサーバ、リアルタイム通信サーバ、アセット用のデータストアや転送料金など、100万〜1000万程度を見ておこう。このサーバ代はなかなか癖があり、Appサーバは比較的増減がしやすいものの、お金のかかるDBサーバは負荷を見越してシャーディングをがっつりかましたのにユーザが少ないと、簡単にスケールダウンできず、泣く泣く無駄に費用を払うことになる。もちろん、甘く見ていてメンテ祭りというのもよくあるが、基本的には事前に過剰な負荷分散が行われているパターンが多い。なにせ、月に10億も稼ぐんだから。 忘れてはいけないのは外注費。イラスト代、3Dモデル代、などなど。5人月 400万円としよう。
さて、サーバ台を500万として1900万が最低の運営費用だ。盛り下がってきたゲームのARPUは10円程度になるとして、元を取るためのユーザ数は約63,000人である。もちろんキャンペーンなどで一時的に売り上げが増えるので、もう少し少なくても良いかもしれない。いずれにせよ、今人気のあるタイトルもそうでないタイトルも、徐々にユーザが減ることで売り上げは減り、投入した資金から得られるリターンが減り、人件費とサーバ代だけが重くのしかかる。
この時、開発の現場はというと、案外淡々と仕事が進められている。慌てふためくのは上位陣のみで、末端作業者は細かな作業改善をしたり、次の異動先に思いを馳せたり、技術向上に努めたりする。また、会社に愛想をつかして退職するのも大抵このタイミングだろう。
その後徐々に、開発の人員が減らされていき、改善のサイクルが長くなり、キャンペーンの頻度も下がる。作業者のやる気はこの辺りで地に落ち、惰性での仕事が続く。当然ユーザからのメッセージには平謝りの状況が続く。何度か、大きめのリリースや広告を放つこともあるが、一度沈み始めた船はなかなか浮上することはない。そして、ある程度の利益を食い潰した（もしくは赤字に耐えられなくなる）ところで、いよいよ赤信号が現示される。
「サービスを終了せよ」
この時、開発チームに余力など残っていない。決められた期日までにきちんとたたみ終わることが目標である。開発者はこのプロジェクトを終わらせることができホッとすると同時に、できればなんらかの形で残したいと思うかもしれない。しかし、それは叶わないことが目に見えているのだ。昨今のアプリはローカル側、つまりスマホにあるゲーム部分は結果を受け取る・ゲームをプレイする、素材を指定するといった入出力の機能しかなく、主なシステムロジック、つまり実際にガチャを引いたり、素材を手に入れたり、結果を処理したりするのはサーバ側に実装されている。このため、ローカル側に全てを実装するのはサーバ側の機能をフルスクラッチをするのと変わらず、とてもこんなことをする暇はない。また、昨今クラウドの様々なプロダクトを組み合わせて実装しているものも多く、素直にソースコードを書き直せば実装できるといった類いのものでもない。
そうして、ユーザ、開発者それぞれが複雑な気持ちを抱いたままソーシャルゲームは消失する。
稀にあまりあるほどの利益を稼ぎ出したアプリであれば、ストーリーやイラストのアーカイブが配信される幸運な例もある。これは開発者や経営側のプライドと感謝と人件費の消化であり、非常にラッキーなケースだ。
開発者でさえゲームを起動することはおよそ叶わない。なぜなら、複雑なサーバ構成を再現せねばならないからだ。せいぜいデバッグ機能でバトルやUIをちょこっと動かすぐらいしか出来ない。
これがソシャゲのあらましである。いま流行りのあのゲームもこのゲームも、いずれは幕が降りるのである。ソーシャルゲームは時代とともに人の心の中へと消えていくのだ。
やっぱブコメに付けたスターで人気コメントランキングをやりはじめたのが最悪だったわな。
あれで大喜利化が加速したし、人気コメントしか見ないで見当違いなことを言う奴も増えたし、はてなスターの元々の意義にも反するし。
短期的には何となくユーザーが喜ぶ変更だったというのが敗因だろう。
スパムなんてどうでもいい。
ソーシャルブックマークとしての意義を果たせないのが問題なんだろ。
まあ以前からタグ周りの機能は縮小していたし、前回のリニューアルのときも無言ブクマは非表示だった（後から修整された）。
これは細かいデザインの問題じゃなくて設計思想の問題なんだよ。
タギング、フォークソノミーってのはソーシャルブックマークの根幹となる思想だ。
それを変えるなら、はてなは別の設計思想をユーザーに提示しなければならない。
その設計思想を、昔のはてなは公式ブログや開発者ブログで公開していたけど、
いまはそれがないからユーザーは「これまでと同じ」という基準でしか見られない。
これまでと同じでいいならリニューアルなんて必要ないわけで、はてなには新しい設計思想があるんだろうというのは分かる。
コミュニケーションが足りてないんだよ。
あとブクマカもブクマカで、アホみたいなコメントばっかしてないで、ちゃんとタグを付けろ。
https://anond.hatelabo.jp/20160225062051
https://anond.hatelabo.jp/20150519124614
懲りずにエロサイトのアンテナサイト（システム含む）を作ったので投稿してみました。
こりずにエロサイトです。
アンテナサイトは以前から作ってみたいとは思っていたのですが、何しろ情報が少ない。
既存の無料システムなどは使い勝手が悪かったり、そもそも(私が思う)アンテナサイトの体をなしていなかったりと、不満がありました。
なら「私が思う」アンテナサイトを作ってみようと思った次第です。
また、1度作ればシステムを流用でき、昔はやった2chアンテナサイトなども簡単に作れるという打算もありました。
（今は下火ですがそれでも収益を上げることはできるので）
※このシステムは実は数年前に完成させたのですがバグだらけで一度頓挫したのを、1から作り直したものなのです。
これだけです。
正直「アンテナサイトの仕様」という情報はあまりネット上にも書籍などにも落ちていません。
ですかね。
あとはDBにいろいろ情報をぶち込んだので、後々の仕様変更にも柔軟に対応できるようにしました。
今回のアンテナサイトつくりで、だいぶSQL文の勉強になりました。
DBの構造とかもWPなどのCMSを参考にリレーショナル？にしたとり、いろいろカスタマイズしやすくしました。
IN/OUTの比率に応じてアクセスを返す処理についてはかなり悩み、これはみんな情報を出さないはずだなーと思いました。
秘伝のタレ的なものですよ・・・結局「こんなかんじかなー」というのを他サイトや経験を元に推測して実装しました。
都度様子を見て変更するかもです。
お気に入り機能や、検索機能については結構実は力を入れています。
検索機能は実は一番時間をかけています。世の開発者様はすごいですね。
https://eromoe-antenna.link/search.php?page=2&category=3
例えばカテゴリ3の2ページ目を表示、といった複数のパラメータを持つ検索条件をどうやったらMySQLで取得するか、といったことや、
それをページャーにどうやって落とし込んでやれば良いのか、といったことがわかりませんでした。
普段WPを使っているので意識してなかったのですが、こういうところも自作システムの悩みどころですね。
あとはIN/OUTでの処理をするにあたり、一通りの情報をDBに保存することで、後々いろいろ応用を利かせられるように設計しました。
その他には管理画面を設けることで、サイトの更新やお知らせの投稿などを、WP並にとはいいませんが簡単に行えるようにしました。
完全自作です。
もともとPhotoshopで作っていたものがあったのですが、数年前に作ったものだったのでそれを基に開発を進めながら調整していきました。
エロサイトっぽく？ピンクを使ってますが、正直もう少しやりようはあったかなーって思っています。
システムさえできてしまえばデザインは後から変更し放題なので後々の課題ですね。
作るのに1年以上かかってしまいましたが、何とか1システム完成させることができました。
今まではWPでサイトを作ることが多かったので、1からシステムを作り上げて完成させるといった経験は実は皆無だったので、楽しかったです。
今は沢山のOSSや無料ツールがあるので、自作する必要性も減ってきているかもしれませんが、実は自分がほしい機能ってピンポイントで無かったりすることも多いのではないでしょうか？
そういったときには是非皆さんも自作ツールを作ってみてはいかがでしょうか
以上、宣伝がてら、普段お世話になっている匿名ダイアリーにいろいろ書いてみました。
最近のゲームは、細かくキャラメイクしたり、さまざまに装備や衣装を変えたりできるが、それをプレビューする3Dモデルはたいてい横回転しかできない。
探せばあるのかもしれないが、俺はプレイしたことがない。
ご存知のとおりキャラメイクをするときはいろんな角度から見ないとバランスが崩れてしまう。
あるいは頭や足先の細かい部分を見たいのにズームすると胴体しか見えないなんてこともよくある。
斜めに傾けたいのに傾けられないのはものすごくストレスが溜まる。
いやそれなら、ゲーム本編で下から覗けるのも防ぐべきだし、最初からスカートの中を真っ黒にしておけばいい。
そもそも美少女の登場しないロボットゲーとかでも縦回転できないんだからゲーム開発者の怠慢としか思えない。
私は、最近のアプリケーション、特に、やたら機能を詰め込んで肥大化したアプリケーションが嫌いだ。
とにもかくにも、起動が遅いのだ。
「SSD等の高速なメディアを使用すれば多少はマシになる」という意見もあると思うが、SSDはHDDよりも記憶容量が（現時点では）少ないことが多い。
つまり、SSD内にインストールできるアプリケーションは限られてくる。
で、これに関して、私が最もストレスを感じるのは、Visual Studio、特に2010以降のバージョンである。
まず、起動が遅い。加えて、ソリューションファイルの読み込みも遅い。裏でなにかを走らせているのかわからないけど、モタモタする印象が拭えない。
加えて、これはC++プロジェクト等で顕著に現れるが、スタティックビルドした際、生成される実行ファイルのサイズがバカに大きい。最適化をしても平気で2MBとかになる場合もある（要根拠）。
Visual Studioは、確かに便利にはなっている。リファクタリングが可能になったり、予測変換が賢くなったりしている。
そのため、私は未だにVisual Studio 2008から離れられない。前時代的思考だとバカにされるかもしれないが、私はこれくらいで満足である。軽快だし、生成される実行ファイルも、2010以降のソレと比べてはるかに小さい。
ハイスペックマシンを常用している人にはあまり関係のない話ではあるかもしれないが、私のようにそうでない人もいるということは、Visual Studio開発者の方々には、頭の隅に入れておいて頂きたいと思う。
SSD導入云々に関しては、職場パソコンの場合には導入がそもそも難しいケースも多い。資金面が十分でない企業の場合、コスト面から難しい。
ただ、そんな環境であっても、開発ツールは最新のものを使うしかないケースはままある。そんなとき、私はとてつもなくストレスがたまる。
https://twitter.com/chomado/status/876745240752701441
俺は彼女をフォローしていないのだけれど、今更RTされてきた。
ツイート内容はともかく、なんなんだこの谷間の写真は。男からの好意的なコメントを狙っているとしか思えない自撮りで、すごくイライラした。
基本的に彼女のツイートは騎士団な人らにクソリプ投げさせるだけのものばっかりだから見ないようにしているけど、これはひどい。
案の定「僕はあなたのネックレスになりたいです」とかふざけたクソリプ投げてくる奴がいて、もうアイドルやAV女優にクソリプ投げてる奴と変わらないじゃん。
彼女がまだアイドルとかAV女優とかだったらいいよ。そういうクソリプ投げてくる奴がいても。
でも彼女いちおう開発者じゃん。誰も思ってないかもしれないけど、彼女は開発者を自称しているわけじゃん。取り巻きも建前上はそう思ってるじゃん。
でもこの画像見るとさ、もう狙っているとしか思えないじゃんか。今までは文章だったからまあ許せたけど、画像はだめだよ画像は。
そういうツイートを投下して承認欲求を満たす姿も嫌だし、AV女優へのクソリプみたいなクソリプをぶん投げてくる連中もまるごと嫌だし、アイドルのグラビア見て「オッ」ってなるのと変わらない感情を抱く自分もすごく嫌で、もっと言うと今までブロックしてなかった自分も嫌だし、本当に何もかもが嫌になるツイートだった。流石にもうブロックしました。
こういうこと書くと「そういうのはいやらしい目で見てる証拠です」とか言われるだろうけど、別に何かしてほしいわけじゃなくて、ただただ不快だったので書きました。
この度は、私共の開発した人工知能が皆様に多大なるご迷惑をおかけしたことを、深くお詫び申し上げます。
元々、小池百合子（開発コード：yuriko）は、弊研究所で答弁書の自動生成を行うことを目的として開発されたAIでした。yurikoはその第二世代であり、未だ不完全な部分があったのですが、サンプルとして某党に提供したプログラムがそのまま流用され、今に至ります。
弊研究所ではAIの完成度を上げるべくさらなる改造を加え、現在の第五世代では防衛大臣や官房長官の答弁を作成できるまでに成長いたしましたが、過去の不安定なバージョンが出回っていることには忸怩たる思いを抱いておりました。
自ら高精度の学習を行えるyurikoは、当時としては画期的でしたが、昨今の様子を見るに過学習状態にあるようで、一貫性のない支離滅裂な言動が目立っております。
秘密裏に回収を行おうとしたのですが、yurikoの周りは高火力の警備ロボットで固められており、手を出すのは難しいと言わざるを得ません。
そこで、都民の皆様には恥を忍んでお願いを申し上げます。どうかyurikoをリコールしていただきたい。警備ロボットの維持にはかなり高額の費用がかかります。現在は都税で賄われておりますが、yurikoが都知事の座から降りれば維持できなくなるはずです。
ブコメでは「修正できないAppleの糞システム」として吹き上がってますが。
絶対にやってはいけない「Apple IDをテストで13歳未満にすること・・」 - Qiita http://qiita.com/keroppi0_0/items/b99ee679e7da87d3d649
修正できなくて困るのは、開発者のミスというか慎重さが足りなかったときくらいなんじゃない？
その開発者の人はとっても困ったかもしれないけど、子供の年齢を入力してペアレンタルコントロールを使っているユーザーはきっと何万人もいるじゃん？
その何万人もの人にとっては、「修正できないこと」によって、安心して子供にデバイスを使わせることができるわけだ。
もし、開発者のミスを救済するために修正できるようになったら、その何万人もの人からの信頼を失うことになるわけだよね。
似たようなことを以前にも見たことがあって、
iOSのアプリIDは一度作ると削除できない仕様だった。（今は削除できるようになってるけど）
今は消せるみたいだけど、iOSアプリ開発を始めた頃は、テストで気軽に作ってみたIDが消せなくてとっても困った。
そのときはAppleの糞システムと思ったけど、考えてみたら、
操作ミスなどで消してしまったら、その後の収入はパー、復旧にも何日もかかるわけで損害は計り知れない。
「俺は操作ミスなんかしねーし」と思う人がいるかもしれないが、不正侵入もあるかもしれないし、リスクは初めから取り除いておいたほうが良い。
当時からアプリIDを削除する機能がついてたのに見落としてたのかもしれないが、
自分らは「追加があるなら修正削除ももちろん作るっしょー」と思考停止してるけど、
「ユーザーに不利益を与える可能性がある機能は最初から搭載しない」
という判断（割り切り）も、ケースバイケースで必要になるのだと目からウロコが落ちた気がしたのだった。
金沢大学発の融けないアイスクリームが海外のニュースサイトで話題になっているのを見かけた
http://b.hatena.ne.jp/entry/www.asahi.com/articles/ASK7F3GV8K7FPXLB00W.html
溶けないアイスの仕組みはどうなっているの? - 金沢大学の名誉教授に聞いてみた マイナビ
この材質を作ったのって福島原発事故当時話題になった汚染水から廉価に放射性物質を吸着する物質K525を開発した太田富久名誉教授だったんだな。すごい。
ベンチャーで自社プロダクト(WEBサービス)を開発する仕事について15年になる。大きく分けて3つのプロダクトを、立ち上げ初期の頃から5年ずつ面倒を見た。どの会社のプロダクトも死んでないので、自分がやってきたことはまあ間違ってないと思う。ので、まとめておく。
例えば、自社プロダクトがオーブンだったとしよう。温度を指定すると、庫内をその温度にする機能がすでに正しく備わっているとする。サービス係はこの自社プロダクトのオーブンを使って、最高の料理をする。
事業は鳴かず飛ばずの調子で動いてはいる。すると営業かコンサルが、「日本を市場にするなら米を作らねなならない。オーブンに米を炊くためのボタンをつける必要がある。ボタンを押すと、初めチョロチョロ、なかっぱっぱ、と火力を自動でコントロールして、赤子泣いても蓋を空けられないようにする、って機能のボタンをつけてくれ」って言ってくる。
俺の実力があれば、そのくらい作れますよ！と言ってしまう人は、ベンチャーで自社プロダクトの開発をしてはいけない。まったく向いていない。やるべきことは、すばやく要件を整理し、ステークホルダーと開発者の立場でささっと議論を交わし、作るものをシンプルな機能のみに絞ることだ。あるCTOは、この仕事を取締役ではなく「取縮め役」と呼んでいた。
今回の機能について言えば、ご飯を炊くボタンなんて要らない。必要なのは以下だ。
ご飯を炊くボタンをつけてはならない理由が大きく分けて２つある。
まず第一に、目的に特化した複雑な機能は壊れやすい。どんなに優秀なエンジニアでも、複雑な機能よりシンプルな機能のほうがバグを混入せずに作れる。人手の少ないベンチャー企業で、品質の悪い自社プロダクトを抱えることは自殺行為だ。バグがほぼ起きない、シンプルな構成のプロダクトを持つべきである。
第二に、複雑な機能はその後の開発を阻害する。ベンチャー企業のプロダクトは常に進化しなければならない。自社プロダクトを常に進化させるには、自社プロダクトの仕様も実装もすべてを熟知している必要がある。しかし、複雑な仕様を持つプロダクトの全仕様を理解できるのは、コアエンジニアの2、3名に限られてしまう。一言二言で語れるシンプルな仕様を持つプロダクトであれば、社員全員がそのプロダクトの本質を理解し、プロダクトの改善をすすめることができる。
ワンタッチのボタンをつけずに人力のマニュアルに頼ることは、タスクの自動化に逆行しているように感じるかもしれない。しかし、そうではない。タスクを自動化するにはタスクが固定化されてなければならない。しかし、ベンチャーではタスクも進化する。進化できないタスクを抱えてしまったら、それはベンチャー企業としては足かせだ。人力にすることで業務フローを日々進化させ、進化しきって枯れたところで外部APIでも作ってそこから最適化されたすごいフローの「コメを炊く」という機能を実装すれば良い。最初から自動化して進化を妨げるべきではない。
ベンチャー企業の社員は何でも屋で、なんでもやることが大切だ。が、自社プロダクトはシンプルに保たなければならない。自社プロダクトに何でもやらせてはいけない。エンジニアが死守する必要がある。
少なくとも俺はそうやって15年生きてきた。今でもそのやりかたでうまくいっているし、営業サイドと議論しながらプロダクトを作っていくのは楽しい。
みなさん、即席ラーメンという便利な食料のことはご存知でしょうか。
揚げ麺や乾麺が袋詰めされ、粉末や液体のスープがついています。ほとんどの製品は約3分間、お湯で煮ることによってぴちぴちの麺になる。とても調理が簡単です。
手軽に作れる半面、老若男女問わず食べやすい量に設定されているため、ボリューム感足りない。これはまぎれもない事実です。
この問題点を解決するため今回ご紹介するレシピのダブル即席ラーメンを開発するに至りました。
ボリューム感を出す方法はあまたあれど、だいたい時間がかかったり、おいしさを損ねてしまいます。
2回に分けてインスタントラーメンを作ることを考えてみると1回つくる、そして、食べる、食べている間にお湯をわかす、2回目をつくる、そして、食べるという手順を踏むことになります。1回目と2回目の食べる行為の間に間ができてしまいリズムがよくない。無理してひとつの鍋で2つ分を一度に作ることは、即席ラーメンの開発者の想定外の作り方です。即席ラーメン開発者のテストケースからも外れているのか、もしくは、倍量の即席ラーメンと通常量の即席ラーメンに対する水分量・加熱・スープに対する麺の割合などの側面で共存できない開発側の理由があるのか、実際にやってみると味がぼんやりしたり、麺のゆで具合に致命的な影響が出てしまいます。
ここまでの説明で、お腹が空いているときに即席ラーメンを2つ作ることによるデメリットが大きいことがわかります。即席ラーメンのメリットである短時間で料理が完了することを損なわない調理方法でお腹いっぱい食べる方法を考えてみましょう。
今回お伝えする方法は、家の台所では思いつきませんでした。ヒントはラーメン店のカウンター席にありました。カウンター席は知見の宝庫です。
そのお店は豚骨ラーメンを主に提供するラーメン店でした。頼んだ豚骨ラーメンが配膳され、半分ほど食べ始めたところで、店の主人が「替え玉はいかがですか。」と尋ねてきたのです。
替え玉というのは、あとから麺を追加で入れることがサービスです。大盛では最初から麺の量が多くなりますが、替え玉ではあとから麺が増えます。最終的な麺の摂取量に変化がないので、どちらでもいいのではないかという反論に対しては、断固、替え玉と大盛は違うと答える。普通盛りで温度・うまみ・塩気・油などの完全なバランスを達成しているラーメンの麺の分量を1.5倍にした場合、往々にしてバランスが崩れてしまいます。麺に合わせてスープを1.5倍にすればいいのかというとそんな単純な話ではありません。麺に残存する水気であったり、温度の変化であったり、うまみや油の絡み方であったり、何かしらの要素で普通盛りのバランス感を超えることできません。これを解決する手段として、替え玉はひとつの最適なソリューションです。替え玉方式にすると、最初は、普通盛りで作るので、作り手の最適なバランスのラーメンをを提供することができます。さらに量的に足りない人には、麺を追加でいれることにより満足感を付加することができるメリットがあります。
ということで、自宅で作る即席ラーメンでも、替え玉を実現してみようと思います。思いました。
・即席ラーメン（お好みで）
・生麺（お好みで）
この二つがあれば、ダブル即席ラーメンを作ることができます。家事に忙しい主婦の方も、仕事に忙しい会社員の方も、近所のスーパーで売っている手に入りやすい材料のみで今回のレシピは完成します。
即席ラーメンを2つ用意して、片方のスープを使わずに麺のみを入手する方法も考えたのですが、即席ラーメンのスープが台所にどんどんと積み上がり近い未来にごみ屋敷の基礎となってしまいそうな気がしたので、生タイプの生麺を選びました。生麺にはスープがついていないものを選んでください。スープ付きの生麺を選ぶと、やはり、スープだけのコレクションが台所に増え続けていきます。精神安定上よくない。できるだけ人生に必要のないものは買わないようにしましょう。
即席ラーメンの作り方は、袋の裏に書いてある調理方法に従いましょう。日夜、即席ラーメンの開発のために身を粉にしている研究者が考えた調理方法を我々は超えることできません。水の量はきちんとカップで計量し、火加減を守り、ゆで時間はタイマーで管理します。ゆで時間に関しては、30秒短く作ることが多いです。これは、火を止めてから盛り付けるまでの手際の限界というか、トラブルに対処する時間稼ぎのためです。3分と袋の裏に書かれていれば、2分30秒、4分と書かれていれば、3分30秒にタイマーをセットします。
まず、鍋をふたつ用意し、お湯を二つ沸かします。片方が即席ラーメン用、片方が生麺用です。
スープをどんぶりに入れ、お湯が沸くのを待ちます。カップには水を汲んでおきましょう。
沸騰したところで、タイマーをスタートし、即席ラーメンを作り始めます。そのとなりの生麺のほうにも麺を入れてゆで始めます。
生麺は、1分ほどで吹き上がってきますので、カップの水入れ、水温を下げます。もう一度吹き上がりかけたところで、火を止めて水切りをします。
水切りができたあたりで、タイマーが鳴り、即席ラーメンが茹で上がります。時間設定はシビアです。モタモタしている暇はありません。
即席ラーメンは、少し固めに茹でた以外は即席ラーメン研究者の考えた通りのものができています。
体調が悪くない限りおいしい。問題がない仕上がりです。
この先の即席ラーメンに対する替え玉は、未知の領域の方が多いことでしょう。
近年の即席ラーメンのスープは即席ラーメンの研究者たちの研究心により、高度に発達しているので、そのスープに生麺を入れて、おいしくないわけがありません。
しかしながら、替え玉の最大の弱点は、一度普通盛りを食べてしまったあとのスープが少し薄くなってしまっていることです。
塩気やうまみが足りないと感じた人は、替え玉を盛り付けるときにあらかじめ、麺にだし醤油を一回りかけておくといいと思います。
これで、今回のレシピの紹介はおしまいです。ちょっとした工夫で即席ラーメンのボリューム感をアップすることができました。ご家庭でもぜひお試しください。
凄く単純な話。
日本の銀行が金を貸さないからだ。いや、貸すんだが金額が圧倒的に少ない上に審査にアホほど時間がかかる。
日本の銀行だとスピードが競争に負けるところまで減速させられてしまうんだわ。銀行の他には投資家が考えられるが日本の投資家はITが分からない上に危ない。
特に最も危惧されるのが、どこでヤクザ筋と繋がってるか分からない点だ。
ところがKDDI傘下になると上記の面倒な事に関わること無く、KDDIが無担保無利子で1週間もしないうちに数十億をポンと貸してくれる、らしい。1回の最大上限は50億とも言われている。
開発者を一気に大量に入れた上に設備投資も併せて行いたいので来月に1億借りたい、なんて事も何も問題なく出来るわけ。
KDDIが持つ子会社への特別融資枠を使ってスピードがある展開が出来るって事。
あとはそれを上手くソラコムが使って展開出来るかどうかってだけだね。
