  |
はてなキーワード: フルスクラッチとは
https://anond.hatelabo.jp/20180207165151 の増田だ。見覚えあるエントリがタイムラインに現れ、なんで今拡散されているんだと驚いた。
色々ブコメやらツイートやらの反応があったので興味深いと思った反応に対する意見とかを落書きがてら書こうと思う。このエントリも書ききれなかったことを何度か加筆していることは許してほしい。
ブコメよりもTwitterでの反応が多いようで、以下の内容はエゴサした中から拾ってる物が多い。(https://twitter.com/search?f=tweets&vertical=default&q=MMD%E3%81%AF%E6%97%A5%E6%9C%AC%E3%81%AE3DCG%E3%82%92%E7%A0%B4%E5%A3%8A%E3%81%97%E3%81%A6%E3%81%97%E3%81%BE%E3%81%A3%E3%81%9F&src=typd)
全体的にはTwitterにMMDerが多く、ブコメにOSS系の開発者が多いように感じた。
また、記事を読まずにタイトルだけでMMD自体への批判であると条件反射している人も多かったようだ。
明らかに煽るタイトルにしたのは増田のせいなので仕方ないのだが、MMDについて全否定しているつもりは全く無いので前のエントリを最後まで読んでほしい。いっそ記事名を「ガラパゴス化した」に書き換えるべきかもしれないがもう遅いか。
逆に、あのような煽るようなタイトルの中で冷静に読んでくれてブコメなりTwitterなりで意見を書いてくれた人には本当に感謝している。
なお、ここに書いていない反応に対しても賛否問わず理解を示したものもある。
これは申し訳ないとしか言いようがない。1年前は一過性のブームだろと思ってたがVR ChatもVTuberも一大ジャンルになった。それにも関わらず自分はVRC界隈の情報を追ってないのでその辺で認識が不足しているのは言い訳できない。
VR Chat周りのモデルに関する雰囲気は自分でも調べてみるが、気が向いた人がいたら教えてほしい。
同じような反応が多数あったが、それには同意する。そもそも先のエントリでもそれは否定はしていない。
ただし、下がった敷居から入った人がMMDから別ツールに移った瞬間に見向きもされなくなるのが3DCG動画・画像のコミュニティにとって問題だと思っている。
Blenderを使えばもっと凄い作品が作れるような動画投稿者でも、再生数を集めるには「MikuMikuDance」というタグに縋るしかない。
MMDの視聴者は「制約が多いMMDで作ることが凄い」「MMDでここまで作れて凄い」というメガデモに近い発想を持っているので、BlednerとAfterEffectsで美麗な映像を作ったところで「MMDじゃない」として一蹴されるだろう。
実際、アイマスの動画でPMXデータをBlenderか何かに読み込ませた動画において「でもこれMMDじゃないじゃん」といったコメントを何度か見かけた。もちろんそれが全てのユーザのスタンスではないのは承知しているが、一定数そういった声がある時点で投稿者の障壁になるだろうと思う。
3DCGとMMDが分断してしまっているこの状況を「MMDが3DCGを破壊した」と書いたつもりである。
これもVRCの活発化で状況が変わるといいんだが、どうなるかわからない。いや、もしかしたら既に変わっている可能性がある中、昔の認識でこのようなことを思っている可能性があるのでそうであれば申し訳ない。
まさにその通りで、ちゃんと読んでくれて嬉しい。
増田もこの人みたいに整然とした文章がきちんと書ければよかったなという反省があるし、書けていれば炎上はしなかったんだろうなと思う。
まさにそうで、MMDがマジョリティである時点で一人がどう動こうと変わらないのが現状。
同意。確かに負けは負けだしBlender等が勝っているとかは思わない。
日本企業でWindows XPやIEが使われ続けるのと似たようなもので、劣っているものでもそれじゃないと満たせないニーズがあるんだなと思う。
昔のニコ動もそうだが、最近はアマとプロの境目が曖昧じゃないか？
アマチュアが作成したデータをプロが使うこともあるし、アマチュア投稿者が商業案件を請けてプロになる機会も増えているだろう。
「文句を言うなら作れ」って子供かよ。仮にMMDがOSSになればコミットするつもりはあるが、それでは不十分か？
樋口が秘匿している仕様を解析してフルスクラッチするスキルがないとMMD界隈に疑問を呈することもできないのだろうか。
開発が4年前に停止したことを宣言されたOSSにコミットするのは難しいだろう。そもそも、サードパーティのOSS開発が停止してしまう状況自体に苦言を呈している。いや、元のエントリではそう書いてなかったから後出しするのは卑怯だな、すまない。まあとにかくそういう風に考えている。
本家がOSSに動かない限り、「MMD」のOSS化は進まないと思っている。
そんな革新的なツールがあったのは知らなかった。偉そうなエントリ書いたわりにリサーチ不足なのは申し訳なく思っている。
しかし、MMD固有のサードパーティツールを知っているかどうかとOSS分野に詳しいかは全く別ではないだろうか。議論のすり替えだろう。
増田は確かにMMDやBlender関連のOSSにコミットしたことはないが、某Web系フレームワークのコミッタである。もちろん匿名なのでこれも嘘と思われても仕方がないのだが。
そのフレームワークに限らず、Issueで提案した改善点を議論の末にwont fixにされた経験もあるので打出の小槌のようには捉えていない。特にコミッタの人数が数百に上るようなコミュニティではIssueやPull Requestの多くがwont fixになるのは知っているつもりである。
これもOSS自体に馴染みがない人には分かりづらいかもしれないので補足しておきたいが、「オープンソースにしてほしい」という話は他力本願で「アップデートしろよ」というスタンスになるのではなく、「自分も開発に関わらせてほしい」という意思である。
スキルやドメイン知識の問題でコードに落とし込めない部分があってもIssueで議論に加わることはできるし、それがオープンソースの強みである。
これは私のような文句を言いたがるタイプの人間だけでなく、純粋なMMDのファンである動画作成者たちが抱いている不満やバグ報告も反映されやすいことを意味している。
現時点でMMDerの方々もMMDが完璧なツールだとは考えていないだろうし、OSS化されるとユーザにもメリットが増えると思うのだが何故これを否定するのかがわからない。
もちろん、開発者である樋口氏が「OSSにしたくない」と意見を表明するのであれば分かるのだが、何故MMDのユーザまでOSS化を否定するのだろうか。
コミュニティのためにならないことであっても盲目的に肯定するのは敬意ではないと思う。
まず増田がMMDやPMX Editorの利用者だったことが伝わっていないせいもあるだろう。利用した上での弱点を述べているのだが、それは感謝が足りないということになるのだろうか。
「不備や弱点を指摘することはそのソフトウェアが好きだから行う」というのはOSS特有の文化なのか？よくわかっていない。
モデルのライセンスが曖昧なのはこれが一番大きい理由なんじゃないかと思っている。CCライセンスなんかで二次創作モデルを配布すれば大問題だろう。
ただ、モデルではなくMMDのソフトウェア自体はオープンにしても問題ないんじゃないかとは思う。
前の記事でも上にも書いている通り、自分が主に問題だと思っているのは「MMD」と「3DCG」が分断された点である。
これは個人的な話になるが、自分自身が動画を作ったときはモデルデータをすべて自力で作成していたので潤沢なリソースがあることに魅力は感じていなかった。
もちろんリソースを魅力に感じている人も居ると思うので「妬ましいんじゃないかな」という指摘自体は否定できないが、増田が指摘している内容とはズレているのでちゃんと読んでほしかったと思う。
記事冒頭に貼ったTwitter検索のリンクを見てもらえれば分かるが、このツイート以外でもMMDerからは「羨ましいんだろう」という反応がかなり多かった。少なくともこのエントリはそういう意図ではないのだが、どうしてそう解釈されたのかはわからない。
おそらくエントリの中身を読んでいないと思うからもう一度書くが、先のエントリではモデリングソフト〜PMX Editor〜MMDのワークフローが面倒であるということを書いている。弄ったことないのに知っていたらそれはそれですごい。
増田は数は少ないがニコニコに動画、BowlRollにPMXデータはいくつか上げたことがある。その上で思った事が先のエントリである。匿名の日記だしIDを晒すつもりはないので「嘘乙ｗ」と言われたら反論しようがないのだが。
実際、この経験からボーン入れ・リギングが大変面倒なことを痛感し、キャラクタモデリング・キャラクタアニメーションをやっている人には頭が上がらないなと思うようになった。
だからモデラーやMMD自体を貶めるつもりはないし、むしろ尊敬している。あくまで先のエントリはコミュニティの雰囲気とMMDそのものが孕む問題についての指摘である。
CGがわからないくせに文句を言うなと言いたいのかもしれないが、素晴らしい作品を出しながらコミュニティのあり方について文句を言うのは気が狂っていると思う。それただのマウンティングゴリラだろ。
BlenderやMayaで作成し、レンダリングした画像を添付しながら「MMDはオープンソース化すべき」と主張する人間が来た場合、自分だったらキレてしまうと思う。
現にこの記事でも「勝手に羨んでて良いから、こっち来んな」という反応を受けているし、以前はVR系の開発者がPMXを読めるようにしただけでMMDerがブチ切れている。(https://togetter.com/li/984614)
そんなコミュニティに対して「頑張ればいい」って無理だろう。北センチネル島の先住民に会いに行くような真似は誰もしたくないし、したところで何も変わらない。
すごく的を得ていると思う。
もちろん「趣味なんだから自転車に乗りたければ乗れば良いじゃん」「お前は車でも飛行機でも使ってりゃいいだろ」っていう話は分かるのだが、前述のVRの件のように自転車乗りが車道を塞ぐような事は避けてほしいとは思う。
増田がドヤ顔で誤用をやってしまったのかと思って焦ってググったのだが、どっちでもいいらしい。(https://twitter.com/IIMA_Hiroaki/status/412139873101807616)
彼（彼女）には申し訳ないのだが、のじゃおじ氏はむしろ好きではない方だ。彼が批判されたことに怒りを覚えてエントリを書いたわけではない。
事の始まりは6/11、消印もなければ料金後納でもない封書が自宅マンションのポストに入っていた。
曰く、「貴殿はヘイトスピーチサイトを即座に停止し最寄りの警察署に出頭せよ」とのこと。
一目見て変だなと思うと同時に、厄介なことに巻き込まれていることを自覚した。
心当たりはある。
私は、自分で言うのも説得力がないが、至って清貧なWeb屋だった。
全ては独学で、どこの会社に勤めるでもなく、デザイナー・コーダー・プログラマ・エンジニアと出世魚のごとくキャリアを積んできた。
無料ブログサービスで使用するブログパーツやテンプレートの制作。手打ちされたHTMLが無数に存在するサイトのCMS移行。フルスクラッチで何万行というコードで書かれた複雑怪奇な商品比較サイト。ブラウザベースで動作する業務システム他諸々。
フルスタックという名の器用貧乏で、Webに関連することなら一通りのことはやったと思う。
ペアプログラミングのペの字も知らず一人で突き進み、次第に大量のサイト群をメンテしきれなくなり、新規開発との並行によるデスマーチが日常となった。
下手な自営業の典型だったことも災いし、往々にして工数と賃金は釣り合わず（相見積もりからの値切りは日常茶飯事だった）、プライベートを犠牲にしてまで働く虚しさに日々磨り減っていった。
やがて完全に心を病み、後遺症は残らなかったが脳の病気（おそらくは過労が原因だろう）で倒れたことを機に一線から引退した。
鬱の治療をしつつ、近頃はコンサル的な業務か、リアルで付き合いのあるごく一部のクライアントからの受注に絞った。
数年前、インフラエンジニアの知人経由でサーバ関係の相談を受けたことがあった。
その際、「一日〇〇万PV級の某有名CMSで動くサイトの負荷対策」として諸々をレクチャーした。無論、例のサイトとは知らずだ。
依頼についての請求書を出した時、こちらの住所を記載していた。（向こうは個人名ではなく見知らぬ会社名だった）
継続して相談を受けるうち、サーバ上で運用されているサイト名を知って手を引いた。
個人情報が漏れたのであればそこからしか考えられず、しかし何故今なのか不思議だった。
例のサイトについて調べるうち、#ネトウヨサイト裸祭りを知った。
最初に投函されたその『警告』にも、アフィ広告剥がしの運動が行われていることは記載されていた。
さすがに張本人からの物とは思えないが、共感を覚えた誰かしらのうち私の住所を知っている者が（あるいは請求書で住所を知った管理人やインフラエンジニアの知人など、私に極めて近い何者かが）リークしたのだろうと思った。
しかし相手が何者かも分からなければ、私にはサーバ＝サイトを停止する権限もなく、仮に出頭したところで頭の病気を疑われるだろう。
そのため、内心怯えつつも無視し続けるしかなかった。（後ろめたいところはないが）個人的に警察沙汰は嫌だという気持ちもあり、被害届も出さなかった。
そのうち例のサイトの広告が全滅したというBuzzFeedのニュースを目にして、ようやく安心した。
「ああこれで顔も知らない手紙の相手も溜飲を下げることが出来ただろう」「皆も例のサイトへの関心が薄れるだろう」
「ほぼ無関係な私も標的からは外れるだろう」、そんなふうに楽観していた。
そして昨朝になって、前回と同じような差出人不明の封書が届いた。
曰く、「サーバ管理人である貴殿らを近々メディア（文春やハフポ、BuzzFeed等）に告発する。個人情報を匿名掲示板及びWiki上で公開する。
サイト管理人〇〇〇（調べれば出てくるが一応個人名なので伏せる）共々罪を償わせる手筈は整った。これは最後通牒である」とのこと。
嫌な予感が当たった。
例のサイトがさくらインターネットとバリュードメインの利用規約に違反しているという記事をつい先日読んでいた。
はてブでもそれなりに話題になっていたので、他人事ではなくなっていた私は正直戦々恐々としていた。
ただし、「さくらインターネットや（バリュードメイン親会社の）GMOが今回の件で一方的な契約解除などの対処を果たして行うだろうか？」という感覚でいた。
広告の件はまだしも、ホスティングサーバを提供するさくら社が動いたとしても、ドメインもといレジストラであるGMOが「（主に第三者による）クレーム」で動くというのは少し考えづらかった。
例のサイトが最高裁に上告したことも知っていたため、仮に契約が停止されるとしてもその段階ではないかという気がしていた。
一方で、私に手紙を送ってきた者は「最初からサイトの停止を目的としていたのではないか？」と思えてきた。
漫画村問題以降、悪質サイトは広告剥がしによる兵糧攻めが効果的という話が周知の事実となっていたこともあり、広告剥がしの運動はその延長にある気がしていた。
けれど、根本的にサイトを潰したいのであれば、捨て身覚悟でサイトそのものか当事者へ攻撃を行うのが最も有効だろう。
ちょうど今朝だったか、グリーンピースがフランスの原発にドローンをぶつけたというニュースを読んで、なんとなく悟った。
これは「保守速報のサーバ管理人」である（と誤解されてしまった）私へのテロルである、と。
もしかしたら、「本当のサーバ管理人」も同じような手紙を受け取っているかもしれない。
なぜなら手紙には「貴殿ら」と複数形で書かれていたためだ。それに関してはお気の毒だなと感じる一方で、ざまあないねという気分だ。
あくまで私見を述べると、現在裁判所で係争中のヘイトスピーチに係る問題について、私は例のサイトの管理人の肩を持つつもりは一切ないし、法のもとで公平に裁かれることを期待している。
ただ、この一ヶ月弱、ある種の当事者として騒動を見守っていて、やはり「行き過ぎではないか」と感じた。
ネット上で起きた問題であっても、司法のもとで裁かれるべきであって、私刑によって晴らされるべきではないという気持ちがある。
さくらインターネットやGMOへの申告は「被害を受けた当事者たち」が行えばよいのであって、それを承知の上で「押すなよ、絶対押すなよ」と言わんばかりの記事を拡散して「第三者であり不特定多数の善意」を期待するやり方は正直に言って寒気がした。
例のサイトの肩を持つつもりはないと言いつつも、実害を受けている立場上どうしても公平性を欠く見方をしている自覚はある。
元々オタクであり、事ある毎に表現規制絡みのセンシティブな話題を目にしてきたことで、常日頃から肩身の狭さを感じる身ゆえに中立とは呼べない「寛容さ」を持ってしまった可能性もあるだろう。
それでも、第三者を巻き込んだ運動や行動（手紙の件は私には脅迫としか思えなかったが）によって社会が良くなるのならば、という思想は反面で危険をはらんでいるように感じる。
他人から何かを剥奪する時、それがたとえ社会的に真っ当な仕打ちと思える処分でも、本来その権限を持たぬ者たちによって軽重が左右されることには本能的な恐怖がある。
なんの利害関係もない、「純粋な義憤による裁き」は、その正当性が担保されなくなった瞬間に理不尽ないじめの構図と変わらなくなる。
ならば「誤っていたと認めなければよい」という方向に流れて、一度始めると引っ込みが付かなくなり、時に際限なく激化する辺りもよく似ている。
「いじめられる方にも責任がある」という言い分も心情としては理解できる。かと言って、少なくとも私が受けたそれらは、あくまで私自身の範疇で「当然の報い」として飲み込める程度のものではなかった。
第一、私を告発しても（例のサイトへの攻撃としては）まったく意味がないのだから尚更だ。多少の犠牲もやむを得ないということならもう知らないが。
私が今後どのような処遇を受けるか考えたくもないが、社会的な死に陥る可能性は五分五分だろうと思う。
「少しでも関わった時点で同罪」「被害者面すんな氏ね」「増田の住所を特定して晒し上げにしろ」とブクマで罵詈雑言を浴びる可能性を覚悟した上で、それでも今回は書くことにした。
なぜなら、私は手紙に対して直接返事を書くことが出来ないからだ。
せめて差出人がこのエントリを読んで、もしも人違いであると気付いたのならば、文字通り命乞いで情けないが思い留まってほしい。
断っておくが、お先が真っ暗だからと言って、私は低能先生のように自棄になって破滅的な行動を起こす気力がない。
それ以前に、今回のことがなくとも、もうボロボロに病んでいる。義憤に駆られたり誰かに恨みを持つのはそれだけで体力を使う。そういう持ち合わせはもうない。
だから、ある日朝起きて、ネットの海に漂う自分の住所を目にした時には、全てを諦めようと思う。
それは明日かもしれないし、幸運にも一生やって来ないのかもしれない。
何事もなかったところで、怯えて日々を暮らすうち、悲観に飲まれて気の迷いを起こすのも人間だと知っている。
たとえ私がいなくなったところで、この国ではよくある、珍しくもなんともない瑣末事として処理されるだろう。
これが遺書にならず、怪文書やポエムの類いとして笑い話になれば幸いだが、念には念をというやつだ。最後はこの言葉で〆ようと思う。
グッド・バイ。
ROBOT魂の方がガンプラより可動範囲も広くアニメのイメージがキチンとトレースされてる問題。
なんでガンプラではプロポーションのアレンジをいつもしちゃうのか理解できない。
頭小さく足が長く、どんなキャラクターのガンプラでもバカの一つ覚えのようにこれやってくる。
あげく表面を細かく凸凹させてアニメのイメージはまるっきりどこにもなくなってしまう。
ROBOT魂はまずそのキャラクターを代表する場面をちゃんと再現することをスタートとしているような気がする。
ちゃんと再現できるとプロポーションが良い！って思えるしそうそうこれが欲しかったんだよ！って気になる。
そのあとこんなとこが動きますよ、とかシーンを再現するのにこういう可動をしますよってのを見てなるほどな！とまた欲しくなる。
俺は自分で作って出来る範囲で改造して塗装して楽しみたい派なのでなるべくならプラモデルという形で欲しい。
ROBOT魂は完成品だからパーティングラインとかふちの厚みとか塗装とかディテールの入り方などの細部がやはりちょっと厳しい。
ROBOT魂レベルの素体があればいいなっていつも思ってるけど、どうもプラモデル部門は別の爪痕を残したいようだ。
近年の製品でいうとドライセンとバーザムとハンマハンマはアニメイメージで作り直してほしい。とくにハンマハンマは完璧な別物だからアニメ風にするのはフルスクラッチレベルだ。
最新作のガルバルディはわりとちゃんと映像イメージが反映されてると思う。
なんとか頑張ってほしいと思う。
元々コンサル会社から事業会社のほうでデータサイエンティストをやるようになって１年経つが辞める。そのきつかったことを匿名という場所で卑怯ながらも話したいと思う。
元々私は大学院でそこそこ統計をやってきてから、コンサル会社に行きデータサイエンティストとして事業会社へ移った口だ。
根本的にデータサイエンティストとしての資質としてざっくりいうと以下の３つが必要だと思われる。
2. KPI設計及び事業からのKPIへの落とし込みからそのKPIからどう事業繋がるかというビジネス設計能力
私能力的には１がやや強く、その次に２がまぁまぁそして３はまだまだといった所で事業会社でデータサイエンティストとして孤軍奮闘をすることになった。
データはあるが、なかなか活用できていないこともあり、分析から企画から関われるという事で入社しようと思った。
後そこそこ大きな会社で働くのも良い経験と思い入社を決意した。ニッチな分野ではあるが、この分野ではTopカンパニーである。
最初の４日ぐらいは会社の研修とかで潰れるのは仕方ないもので、それが終わり早速の業務を行う事になった。
貰えない。
許可申請の関係で３週間程かかってからまず最初にデータを頂けるようになった。この時点でやる気を削がれた。
更にデータの確認という事で事業へのヒアリングを進めるだけで・・・６週間程かかった。更にやる気を削がれた。
この辺りで気付いた事だが、コンサル会社でいたときは、データの確認がスピィーディーだったのに何故こんな遅い作業なったかというと
日本の企業は部署跨ぐというのはとても大変で、コンサルとしてやっていたときは単価も高いし、期間内でやらないといけないという事で
いろいろと調整がスムーズに進んでいたという事がこの時に分かった。コンサルとして外から見ているとやはり分からない事は多い物である。
データの確認も終わり、分析をし、改善を行うテーマを決めて進める事になった。この時点で２カ月ぐらい過ぎていた気がする。R/Pythonの自分のパソコンへの許可申請を出すが、降りない・・・。会社的にはCならばOKだと言われる。でもCの追加ライブラリーの関係はダメらしく・・・悩んだ結果エクセルを基に分析をする事になった。現状把握のために基礎集計をするが、エクセルでSQLで言うGroup_byやら違うデータ同士をくっつけるためのJoinを32 bit エクセルで関数ベースでやると何度も落ちる・・・。この時点でやる気は地の底へと落ちていた。
この辺りでCベースでもう書き直そうかと悩むが、流石にCのライブラリーがない所でフルスクラッチ調に書くのは工数的にかかると考えたのでvbaを用いていた。
エクセルベースでの可視化から上司や関係者にデータの分析の結果を見せていく。この辺りでデータ分析から改善策はまとまっていた。しかしこの辺りでやる気をマイナスにして頂ける言葉を伺う。
私がVBAを書いているのをちらっと見て
「プログラミング何かやっていても仕方ないし、プログラマーではねぇ・・・。今後会社ではプログラマーなんていらないから企画できるようにならないと」
勿論これは直属の上司からのお言葉ではないが・・・正確には同期であるが・・・もはや殺意すら覚える。因みにこの人の既存サービスの改良プロジェクトが回った時のデータを収集したら分析する事になっていたが、プロジェクトのスケジュール感を見ると
開発 4カ月
運用以降
みたいな形でうん？何か少なくないか？と思ったら既存のサービスに関してのギャップ分析無しに既存サービスの改良を進めているらしい
・・・その上取れるデータは〇〇〇で〇〇〇は無いらしい。あっそんなん改善出来んやん・・・。一応私はアリバイ工作のためにメールや会議にて発言する
が・・・空気を読めないと言われ会議呼ばれなくなってしまう（因みにこのプロジェクトは要件定義から運用以降まで外注である）。
私のコンサル的な能力がなかったと言えば確かにその通りである。でもいやうん日本の企業の中で、分析をやっていくのは本当に難しいというのがよくわかる。
一人だったというのもある・・・でも殆ど基礎集計レベルで難しい用語を使わずに改善を行おうとしたいやでもこの日本の企業では無理だった。そしてやりたいと思わなかった。
たまに日本の企業でのエンジニアの不遇差を嘆く記事を見かけるが、割と同じようなパターンの臭いがする。
追記
２００万ｐｖの会員サイトでAmazon aws料金を月々リザーブドインスタンスで８０万ぐらい払っていてクラウド安くないと社内的に炎上しているらしい。どんな設計したのかは
もはや手をつっこみたくないレベル。
きららファンタジアというスマホゲーで何か大きな問題が起こって大騒ぎになっているというのは Twitter の自分のタイムラインにちらほらと出てきていたので「そうなんだー」程度の認識だったのだけれど、その炎上のまとめと考察(https://smhn.info/201712-kirara-fantasia-cheat)を読む機会があってなるほどこれは大変な問題ですね、と思った。
それで僕は、サービスインからサービス終了までをほぼ全て見守ってきたあのゲームの事を久しぶりに思い出したので懐かしい思い出としてここに書き記しておこうと思う。
そのゲーム、仮にスキマとしよう。そのスキマはスマホゲーによくある隙間の時間を埋められるようなデザインをされたゲームで、大まかにいうと冒険者を組織してダンジョンへと冒険に出かけさせ、持ち帰った財宝を使って冒険者を強化して、また冒険に出かけさせるというサイクルのゲームなのだが、冒険中はユーザは特にすることがなくただ待っているだけという、冒険者を送り出して帰ってきたのを確認するだけの作業をその隙間の時間にやってね、というゲームだった。なお、スキマは単発のゲームというよりは、はるか昔のパソコンで動いていたゲームを始祖とする名のあるタイトル(仮にウィリーとしよう)を冠したゲームで、ルネサンスと名付けられたウィリーブランドの再生プロジェクトのうちの一つであった。僕はそのウィリーが好きだったのでとりあえず遊んでみようとダウンロードしたのであった。
まず、スキマのサービスイン直後だが、オンラインゲーの例に漏れずサービスイン直後に色々な問題を起こしてメンテにつぐメンテでまともに遊べる状態ではなかった。だいたい4,5日はメンテをしたり、たまにサービスしていたり、という感じだったのではないかと思う。そのサービスインから4,5日経ったあたりで、「このままでは安定したサービスが続けられないので長期メンテナンスに入る」といった感じのアナウンスと共に、メンテナンスに入った。このメンテナンスは一ヶ月とちょっとの間続いた。僕はサービスイン初日にはプレイできず長期メンテナンスに入る前に少し遊んだ程度だったのだが、遊んでみた所では「これは酷い」としか言いようがなかった。
まず動作がもっさりとしている。何かのボタンを押すたびに CONNECTING… というダイアログが出て2秒位は待たされる。場合によってはボタンを3,4回押さないと目的の事ができないのに押すたびに CONNECTING… なのである。次にタップに反応しない。ボタンを押すと書いたが押したつもりが押されていない事がしばしばある。この場合は CONNECTING… が出ないのでわかるのかと思いきや、1秒位経ってから CONNECTING… と出てあぁ、押していたのか、とわかったりするようなもっさり具合である(もちろん押していなかった時もあるので1秒後までは押せたか押せなかったを判別できなかったりする)。
また、バグと言っていいであろう謎の動作が多い。ダンジョンに送り出したパーティのダンジョン内部での行動がダンジョンログとして閲覧できるようになっており、そのダンジョンログは直前の3回までのログが観られるようになっているのだが、そのダンジョンログの表示される内容が複数が同じものになっていて実質的には3回のログはみられないであるとか、CONNECTING… が出るタイミングで他の部分をタップしてしまうと高確率でアプリが落ちるであるとか、特定の順番で装備している武器を変更すると攻撃力が最低値に固定されるであるとか、リリース記念かなにかで貰えるキャラがなぜか毎日もらえて同じキャラが増えていくであるとか、まぁ色々な問題があって面食らったものである。
そんな感じでサービスインを迎えたスキマなのであるが、こんなに酷い状態なのではユーザはどんな事を言っているのだろうとコミュニティを探した所、2chにスレッドが立っていた。案の定スキマのバグ報告スレと化しており、「あぁ、このゲームは本当に全然駄目なんだな」とほっとしたのを覚えている。僕はその頃からその2chのスレッドを眺めるようになった。また、こんな状態ではサービスが続けられないのはわかるけれど、一ヶ月程度のメンテナンスでなんとかなるものでもないだろうとも思ったので、せっかくなのでサービス終了まで看取ると面白いのではないかとも考えた。
一ヶ月と少し経った頃、スキマのサービスが再開された。まぁ残念ながら僕の予想は外れておらず、お世辞にもちゃんと遊べるとは言えない状態であった。とはいえ、本来は一回しか貰えないはずのキャラが複数回貰えるであるとかいった所に代表されるゲームとして守られるべきルールのようなものについてのバグの多くは直っており、残っている問題の多くはクライアントアプリ側の問題とサーバ側の負荷対策ができていない問題とみられ、クライアントアプリ側の問題は特定の操作をしなければ落ちはしないしサーバ側の問題はもっさりだけれど待てば処理はしてくれるので一応遊べないことはない状態だとは言えた。それでも、クライアントアプリ側でのUIの不思議な動作(押してるつもりでも押せていない、連打するとクラッシュ)に誘発されたと考えられる進行不能バグを代表とする理不尽な問題は沢山残っており、ユーザとしては不満が渦巻いていた。
そんなスキマではあるのだが、サービス再開の後はウィリーでは有名な人の名前を冠したイベントを行ったり、定期的に期間限定のダンジョンをオープンしたりといった運営を行っていた。もちろんバグはじんわりと直ってはいくのだが、特に劇的な直り方はせず、「俺サービス開始直後からログインできなくなっててまだログインできないんだけど」みたいな事を報告するユーザ(?)も2chでは散見されるという状態で、2chのスレッドは「スキマのバグを踏まないようにプレイするにはどうすれば良いのか」という情報を交換するための機能を果たしていた。
一ヶ月メンテからのサービス再開から3,4ヶ月経った頃、運営会社から開発会社の変更が発表された。曰く、外部の開発会社に制作を依頼して制作したのだが、不都合が多すぎてどうしようもないので開発を自社に引き取るということであった。その後一ヶ月程して「不都合収束クライアント」と銘打ったクライアントが配布される。この不都合収束クライアントで確かにいくつかのバグが修正されはしたのだが、もっさりとした動作が変わるわけではなく(プロトコルもサーバ側も修正されていないようであったので当然ではある)、操作によってはクライアントが強制終了していたのが強制終了はしなくなった、程度の修正であり、これを解決するには根本的な改革が必要であるとみてとれた。
そんなスキマではあったが、何故かサービスは終了せず、サービス1周年の時を迎えた。この時、スキマの開発体制についての発表もあった。現在のスキマのクライアントプログラムは改修を重ねていくが、それと平行して開発ミドルウェアを変更してフルスクラッチでクライアントを作り直している、という発表であった。2chのスレッドではフルスクラッチでクライアントを書き直すということで、バグの根治は当然として、目的の事を行うのに3〜4タップ必要であったりするというUI周りまで手がつけられるのではないか、という事を期待する声が上がったりもした。
また、この1周年の挨拶の3ヶ月後には新クライアントの開発状況は70%と発表された。
この頃からであろうか、僕が遊んでいる環境のみなのか、又は他の人ではあまり現れない問題であったのか、とにかく僕が遊んでいる環境では冒険からの帰還を行おうとすると変に時間がかかるようになった。この問題は何らかの原因で帰還操作が完了するまでの時間が少しづつ伸びていくという問題であった。この問題は後で僕には大きな問題として認識されるようになる。
この頃からは新クライアントを開発しているためなのか、旧クライアントの修正はあまり行われなくなり、定期的なイベントが行われるのみであった。思えばこの頃はスキマの遊び方(このようにするとバグを踏むのでこれはしない、であるとかいった遊ぶための作法)がわかっている人間しかスキマを遊んでおらず、運営側も積極的には宣伝もしていないため新しいユーザも増えなかったため、比較的安定した運営が行われていたのではないかと思われる。
また、恐らくこの頃であると思われるが、2chのスレッドで「スキマは冒険者が冒険をしてきたログを眺めることでそのダンジョンの攻略法を考えたりするゲームなんだけど、あまりにもバグが多すぎるから2chというログを読む事でスキマというゲームを攻略しているよね」といった書き込みが行われるなど、スキマをダンジョン攻略ゲーとして捉えるのではなく、バグ攻略ゲーとして捉えるというユーザが現れていた。
さて、一周年の時に発表された新クライアント開発は、その後3ヶ月程で70%まで出来ていると発表されたが、結局その新クライアントがお目見えしたのは2周年を目前に控えた頃であった。新クライアントのお披露目はAndroidでβテストという形で行われた。言い忘れていたがスキマはiOSでしかサービスされておらず、それまでAndroid版は存在しなかった。僕はAndroidもiOSも持っていたため、βテストに応募し、当選したので遊んでみたのである。
まず、フルスクラッチで制作されると言われていたのでUI周りも変わるのであろうと思っていたのは完全に裏切られた。見た目はほとんど何も変わらず、もちろんUIのタップ回数まで全く同じであった。しかも使用されているフォントが違うために文字が見切れていたりといった問題が発生しており、お世辞にも前のクライアントとくらべて良くなったとは言えなかった。また、恐らくはサーバ・クライアント間のプロトコルも何も変わっていないのか、プロトコルやサーバ側に起因する問題は依然として残っていた(武器や防具を鍛錬すると+の数値が上がるという仕様があるのだが、連続して鍛錬を行うと必ず1以上は上がるはずの鍛錬値が上がらなかったり下がったりするといった問題は残っていた)。また、動作もiOS版と比べるともっさりとした感じが強く、何のために作り直したのかわからないという感想であった。2chのスレッドの中ではこの新クライアントは単に今までの旧クライアントをAndroidに移植したものであり、本物の新クライアントはまだ開発中なのだと言って聞かない人が長いこと存在した程である。
その後、βテストでお披露目された新クライアントは3ヶ月後にAndroidでリリースされ、その後さらに3ヶ月後にiOSでも新クライアントがリリースされた。
鳴り物入りで導入された新クライアントであるが、先程も書いたように、旧クライアントと比べると確かに解決された部分もあるが、サーバ側が関わる問題は全く同じ問題を抱えており、新クライアント特有の問題が多く発見され、実質的には旧クライアントの方がバグが少ないという状態であった。
僕はβテスト以降は特にAndroid版で遊ぼうとはしていなかったため、新クライアントが先行リリースされたAndroid版を遊んでいた人達を眺めていたのだが、Android版で起こっていると2chで報告されている問題がそのままiOS版でも起こるとなると大変だと思って眺めている位には、Android版は阿鼻叫喚の様を呈していた。iOS版での新クライアントのリリースは3ヶ月遅れたが、この間Android版は何度もなんどもアップデートを繰り返し、その度に少しづつバグが修正されていくのをみて戦々恐々としていた。
iOS版の新クライアントがリリースされた直後、僕はスキマを遊ぶことができなくなった。これはゲームを起動した後すぐに「通信エラー」が表示されてタイトル画面に戻されるという問題で、これを回避する方法が全然わからなかったためだ。「あぁ、ログインボーナス貰えてたのがなくなっちゃうなぁ」と思ったのを覚えている。
しかし、この問題については2ch(正確にはTwitter経由であるのでTwitterの誰か)に「お知らせ」をタップしてからだと通信エラーが起こらない、というオカルトじみた書き込みがあり、それを信じてやってみると確かに通信エラーが起こらないということが確認できた。これで僕もスキマをプレイすることができるようになったのである。この時は本当に2chというログを読んでスキマというゲームを攻略している感じがしたものだった。
この時、僕は何故通信エラーが起こるのか、何故「お知らせ」をタップすると通信エラーが起こらないのか、といった事を確認したくなってiOS版の通信を眺めてみることにした。本来であればこのような行為を行うのは自分の主義に反するため、それまでは行わなかったのであるが、突然ゲームがプレイできなくなるというのは大変衝撃であったので、つい出来心で、という感じで眺めてみたのである。
クライアントとサーバ間の通信はHTTP、つまり平文で行われており簡単に通信内容をみることができた。タイトル画面から通信エラーが出るまでの通信内容はだいたい以下のような感じであった。
3. クライアントから並列で何らかの情報を取得するためのGETリクエストを送信
4. 並列で送られたリクエストへの返信をサーバが返すが、その全てに更新された(別の)セッションキーが入っている
6. クライアントで何らかの操作を行おうとしてサーバへリクエストを送信
つまり、3. のリクエストが並列で行われ、サーバが更新したセッションキーが 4. でクライアントに届けられるのであるが、恐らくは届いたセッションキーが前後してしまうことで壊れてしまったと考えられる。
これが、何故「お知らせ」をタップすると解消するのかであるが、実は「お知らせ」を取得するためのURLは http://…../login2 というURLへのGETリクエストであり、かつセッションキーを必要としておらず、このURLからのリクエストの返事にはセッションキーが含まれるという特殊なURLであったのだ。つまり、本来であれば 5. の状態の時には壊れたセッションキーを保持していたはずが、そこで「お知らせ」をタップすることで新しい(正しい)セッションキーを手にすることができるようになり、その後の通信はちゃんと行えるようになったのである(その後の通信では並列にリクエストを投げるパスは僕の観測した範囲では存在しないように見えた)。
この事に気づいたTwitterの人はどうやって気づいたのかはわからないが、よく見つけてくれたものである。ともかく、僕はこの情報に助けられ、スキマを再開することができた。
長くなったので https://anond.hatelabo.jp/20171221020636 へ続く
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/
Q1.役所の仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの？
A1.地方自治体の事務や財務について法律で決まっているのは大枠だけだよ。
それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセスは全然各役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。
Q2.なんで新規で作らないの？
A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市が更新しようとしてるような、メインフレーム上のシステムだよ。
A3.みんなが使ってるWindowsとかLinuxとかのOSがなかった時代のコンピュータだよ。IBMとかがベンダーごとに作っていてOSもベンダー謹製だよ。性能はいいけどメチャ高いよ。
システム内でクローズして専用線以外では他とつながってなかったから、汎用機からPCサーバへの移行を「オープン化」と言うよ。
オープンソースソフトウェアとは全然関係ないよ。
Q3.使いまわしってどうやってやるの？
A3.80年代とかに作ったシステムで動いてるCOBOLとかPL/IとかをLinuxとかUnixとかWindows上で動く言語にコンバートしてリコンパイルするよ。
DBのデータも階層型データモデルからリレーショナルDB用にコンバートして移行するよ。こういう開発形態を「マイグレーション」と呼ぶよ。
あと、バッチジョブ制御もJCLという汎用機用の言語で動いているよ。これもそのままでは動かないのでコンバートするよ。
コンバート先はperlだったり、シェルスクリプトだったり、ベンダごとの独自スクリプトだったりするよ。
COBOLとかの実行プログラム移行も大変だけど、帳票の大量印刷はたいていバッチジョブでこなしてるので、JCLの移行もめちゃ厄介で大抵もめるよ。
Q4.80年代のものを使いまわすとか。新規で作ればいいじゃん
A4.お金が無限にあればできるよ。今の時代にお金があった時代のシステムをフルスクラッチで再開発するととんでもない予算になって市役所内の決裁が通らないよ。
しかも汎用機時代の納品は割といいかげんだったのか、仕様書が残ってなかったりするから、費用はさらにかさむよ。
Q5.そんなんでよく運用できてたな
A5.当時はSEが汎用機の付属品みたいについてって、困ったらオペレーターとして介入して動かしていたみたいだよ。
そうやって現場感覚バリバリでやっているので、オペレーターしか知らないプロセスがあったりするよ。
マイグレーション開発では総合テスト中にそういう隠しプロセスが「発見」されたりするよ。こわいね。
上記の通り仕様書がないことも多いうえ、システム課に限らず市役所の人員は基本ローテーションするよ。
導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機のことなんてここ10年に入った職員にはわからないよ。
Q7.なんで入札にしたの？ 現行ベンダに指名してやらせたほうが良くない？
A7.金額がでかいから、たぶんどこの市役所でも入札案件だよ。
随意契約（随契）は無理だし、入札業者を発注者が指定する指名競争入札は談合の温床になってたから最近はあんまりやらないよ。
（裏技としてRFPを指名したいベンダーに書かせて公募型指名入札にしたり、RFPの段階でハードを全部特定ベンダで型番まで指定するというのがあるけど、公になると多分問題になるよ。こわいね）
Q8.じゃあ役所は悪くないの？
Q8.悪いよ。
入札案件はRFPで書かれた各項目をどれだけ満たすかの技術点と、価格点で決まるよ。点が高ければだいたい自動的にそのベンダーに決まるよ。
なので、技術点の項目に現行システムの調査にかかる項目を入れるとかして、現行機の開発・保守ベンダが高得点を取れるようにしておけば価格勝負してくるベンダーをはじけた可能性はあるよ。
もちろん現行の会社に嫌われて逃げられたとか、役所が現行の会社をめっちゃ嫌いになって声をかけなかったとかもあるかもしれないけれど、可能性は低いと思うよ。
A9.ここまで述べたようにこの手のマイグレーションは火薬庫だよ。火を噴いても爆発しなければラッキーぐらいなので、強いて言うなら入札したことが悪いよ。
A10.前にマイグレーションをやったことがあるSEだよ。もうやりたくないよ。今は転職してSIerじゃなくなったからやらなくてよくなったよ。うれしいね。
しょぼいSEだからここに書いたことは個人の体験に基づく参照情報だよ。一般的じゃないことを言ってたり、間違ってたら教えてもらえると助かるよ。
(2017.10.13 追記）
Q3がかぶっていたよ。恥ずかしくてなきそうだけどブコメに番号で言及してくれている人がいるから忍んでそのままにするよ。
あと、「オープン化」の定義が違くない？という指摘があったよ。確かに増田が間違っていたので、記事の主旨から外れるけど補記するよ。
メインフレームは本文で述べたようにOSからハードまでメーカー謹製なので独自仕様のカタマリだよ。
これに対しPCサーバは標準規格で作られているよ。こういう標準規格に基づくサーバをオープン系と呼ぶよ。
独自規格でクローズしたコンピュータから、そうでないオープン系に移行するからオープン化なのであって、専用線とかは関係なかったよ。半可通な知識で語ってしまったよ、ごめんね。
京都市で火中にいるシステムズさんのサイトの解説がこの増田よりも分かりやすくて正確だから気になる人は見てほしいよ
http://www.migration.jp/column/column01.html
完全に余談だけどオープン系のx86サーバに移行しても、システムはそんなにオープンにならなかったりするよ。
H系に頼むとDBが拝承DBになったり、Fに頼むとシステム管理が全部SystemWalkerになったり、要するにベンダ独自のミドルに入ってがっつりロックインされたりするよ。
日本でソーシャルゲームがヒットして、およそ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をちょこっと動かすぐらいしか出来ない。
これがソシャゲのあらましである。いま流行りのあのゲームもこのゲームも、いずれは幕が降りるのである。ソーシャルゲームは時代とともに人の心の中へと消えていくのだ。
ふと思い立ったので書いてみる。二年前、新卒として某企業の技術研修を受けた。Javaを用いて、自分たちで一つのプロダクトを作るという研修である。技術を推している会社なので研修内容にはかなり期待していた。Spring等のフレームワークの話、JavaとフロントエンドのAngularやReactをどう連携させるか、もしかして自作のフレームワークを作る研修も受けられるかも、などなどの話を入社前にはしていた。実際そうではなかったわけだが。
詳らかに書くことは出来ないが、当時最も憤ったのは研修の成績をどうやって決めるかに関する講師の考え方。中間発表で企画発表を行い、最終発表でプロダクトとしてのレビューを受けて、プレゼン大会を行って成績が決まった。自分はどちらも中くらいの成績だったらしい。
ここで驚いたのが、コード量が成績評価に結び付くということだ。コード量の最適化という意味ではない。フレームワークなどを使ってコード量を減らしてはいけない、フルスクラッチでプロダクトを作れということだった。意味が分からなかった。
評価するためには十分量のコードが必要ということは理解していた。過去の研修で何人かがフレームワークを用いて適当に作ったプロダクトで済ませようとしたエピソードなどを聞かされた。それはわかる。わかるが、そうした怠慢に基づくモチベーションではなくよりよいプロダクトを作るために先人の肩に乗るのは許されるべきではないのか？
Javaによるプロダクトを理解するため、フレームワークを使うとフレームワークが廃れたときに何にもできなくなる、という言葉を何度も聞かされたが、Javaのプロダクトを理解するのならそれこそフルスクラッチを要求するのではなく歴史があるSpringで十分だし、フレームワークを使ったからといって魔法のように自分の望むプロダクトが出来上がるわけもなく、自分で考える部分が大部分を占めることは自明ではないか。むしろ、その考える時間という本質的な部分を確保するためにフレームワークなどの技術を用いるべきではないのか。
Reactを学びたいモチベーションがあり、Java側でなければ、というかReactはフレームワークじゃないし大丈夫だろうと思って実装を進めていた時に講師の方から「フレームワークは認められない」と言われ、食い下がったもののまるで話が通じなかった。結局自分はそこから大きく計画を修正し、適当なプロダクトを作った。モチベーションは地の底に落ちた。そもそもプログラム研修なのに渡されたPCがWindowsで、エクセル地獄だった時点でモチベーションはまるで高くなかったがReactをやるというのがモチベーションになっていた。それも無駄だった。
今年の新人も同様のカリキュラムだという。しかもまだWindows。フレームワークは一切使えない。エクセルでワイヤーフレームを書けという。SIじゃないから大丈夫だろうと思っていたのに、という新人はたくさんいるだろう。配属後もコードを書く時間はどんどん減っていく。自分自身で勉強し、論文や技術書を読み、週末に自分でプロダクトを作る習慣をつけておかないといけない。自衛しないといけない。
そんな不幸な人たちがいればいいのにと思った。
フルスクラッチで作り直したとして、これまでに達成できなかった何か
が実現されるのか?
ただ「今風になった」「流行に乗ってる」というだけのために工数をかけて
90年代からソフトウェア開発をしている人間には信じられないのだが
これはもう、保守とかメンテナンスとか考えて実装して行くよりも、
新しいフレームワークを選定して、さっさとフルスクラッチで作り直すのが一番早い。
２年に一回、１～２カ月だけ使って新しくしてしまうのが良い。
２年もたつと、古臭いのはもとより、同じ開発者である可能性も低く、
昔の人の謎仕様で修正できない、なんてこともよくあることなのだ。
しかも昔は必要だったけど、今はいらなくなった仕様なんて腐るほどある。
仕様追加の繰り返しで、結局最初の機能いらないじゃん、なんてこともあるので、
さすがに似たようなフレームワークであれば、変える必要がないのであるが、
新しいフレームワークを採用する決断をしたら、もうさっさ古いのは捨てて、
作り直してしまおう。
定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。
（実践はしていない）
日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応で日本語書けるもの。
○画面に表示する時
フレームワークや言語にもよるけど表示するときに英語の名前から日本語の名前に変換して表示って手間があるものがある。
最近見かけた例だと.NETでプロパティの属性に表示名書いて表示するときに取り出していた。
最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける
次に他の人の英語化したのを見る時。
その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもchildsみたいな謎の語があったり。
そこそこできる人同士でも、「私はニュアンス的にこっちの単語」「僕はこの単語のほうがいいと思う」とかある。
相手の書いたところがわかりづらいのはもちろんだけど、プログラム的に同じ意味なのにクラスや関数によって呼び方違うと辛い。
かといって全員に日本語と英語の対応を先に渡しておいて統一しようというのは大変すぎる。
（日本語だと仕様の時点で日本語で書いてるからまぁおかしなことにはそうならないはず）
----
次にデメリット
軽く調べた感じ主にこの2つな感じ。
○IME
と思うけど、実際チャットやこういう文章書いてて英語が出るときに割りと頻繁に押してる。
ほぼ無意識でやってて意外と苦じゃない。
短いとF10変換で半角にすることもあるけど、キーボードのタイプ数カウンタとか入れてみると半角全角キーはけっこう上位にいた。
それに、なんだかんだコメントは日本語で書くことが多くて、他の人と作るのならこまめにコメント書いてる。
そうなると全角半角の切り替えは普段からあるもので、あんまり気にするほどじゃない気がした。
最近じゃIDEやエディタの補完が優秀だし、日本語にするにしても「最初はjから始める」とかルール入れておけば「j」って打ってあとはスコープにあるいくつかの候補から選ぶだけで全角にしなくていいかもしれない。
githubで公開したりとかライブラリで再利用してもらうときに日本語じゃ使ってもらえない。ってことみたい。
私が日本語にすればいいじゃないって思ってるのは、ビジネスロジックというかそのアプリケーションの固有名詞みたいなところ。
「足し算」って関数名は 「add」 でいいと思うし、配列のそれぞれは element とか item とかそういう一般的な英単語でいいと思う。
具体例がいいづらいけど、業務システムで表示する金額の名前とか、日本語独特なものとか、一般的な単語じゃなさそうなの。
こういうのを日本語にしたいってわけなので、ライブラリ的な共通なところは英語で良いからgithubで公開する範囲も英語のものでいいと思う。
ただ、最近はやってるマストドンとか、ライブラリ的なものじゃなくアプリケーション自体をgithubで公開する場合はできない気がする。
でも、海外も対象にしてるものだと日本語特有なせいでわかりづらい英語になる苦労とか少なそうだしそういうのだと英語でいいんじゃないかな。
----
長くなったけど、まとめると、
業務システムの固有名詞とか日本語特有なものとか無理に英語化してよくわからないことになってり、見づらくなるくらいなら日本語使えばいいんじゃないかな
ということ。
まあ思ってる割には実践してないので、やってる人がいたら良かった・悪かったとか聞きたいなと思ったのが書いた理由。
帰ってきたらすごいブクマついてた。
絶対「自分でやってから言えよ」みたいな意見来るだろうと思って今日の空き時間に日本語行ける言語調べたり軽く日本語使ってコード書いてみたので、そのあたりと目についたコメに答えてみる。
まず、思いの外日本語プログラミング言語上げてる人がいたので、うまく伝わってなかったぽい。
具体例上げずにサッと書いたらからかな。
あと自分もわりとするけどタイトルだけ見て中身見ずにコメントしてた人もいるだろうなー。
これが、などしこやひまわりや、BF系のmisaやら北斗のあれやらうにゃーとか色々な「構文など最初から日本語を前提とした言語」ではないってこと言ってた。
---
最近の主要な言語ならだいたい Unicode 対応でしょと思って環境があった言語を試した結果はこうだった。
JavaScript/Python/PHP/Scala/Kotlin/C#/Go/Swift
rust と Lua は無理だった。
rust は確か前に、変数名が ascii 文字だけなことに日本以外のどこかの国からUnicode対応にしてって多くの要望あったみたいな記事があったし将来的に対応するんじゃないかなって思ってる。
実際に今どんな状態かは知らない。
その記事のコメントとかでみたけど、日本語以外は割りと自国の言葉を使ってたりするっぽいね。
VBA を上げてる人がいたけど、私はそこまでのはみたことない。（幸せ者っぽいな）
稀にエクセルマクロいじるときに使い方ググってて出て来る、解説してるページで関数名が日本語なのをたまに見るくらい。
パット見なんか気持ち悪い感はあるけど、読んだときのわかりやすさはけっこう大きい。
---
○使ってみて
大規模案件に使ってみてこその問題もあるだろうけど、簡単なスクリプト程度のを日本語にしてみて気づいたこと。
割といける。
PHPて言語は変数は全部$からはじめないといけない欠陥言語。
まあ変数のみのgrepのしやすさや予約語キーワードを変数名に使えるからメリットもある。
だが、$って打ちづらい。
Shift+4ってすごいつらい。
に比べて全角半角キーってちょい遠いけどそこまで苦痛じゃない。
GoogleIMEだけど、多少のタイプミスは補完で修正してくれるし、予測変換が優秀だし。
IDE重いから補完機能のない軽いエディタで書くようなときなら、IMEのおかげで英語の変数名で書くより速度は早いと思う。
---
少し前に知人から言われた日本語のデメリットを思い出したのでそれも触れとく。
「仕様変更で言葉変わったときに日本語だと全部書き換えないといけないよ。英語だと別にそのままでいいし。」
英語わからない人が、英語を言葉とみなさずただの記号として考えてるから、っていうような発言。
仕様変わって変数名まで変えるのは面倒なのはわかるけど、あとからコード読む人が英語で見て意味不明になる。
英語と日本語の対応をコメントに書いたとしても、全然意味の違う英語があるのは混乱でしかない。
こういう考えの人がいたら本当にやめてほしい。
---
あとは気になったコメントについて書いてく。
表記ゆれとか方言とか言い回しなどについては、全部日本語にするとあるだろうけど、私が想定してるのは直感的に英語にならないような固有名詞とか。
年金の例も○○年金というのがいろいろあって、全部英語だと嫌になってくるしよくわかる。
こういうのを日本語にしたい。
なので年金額を取得する関数で「年金額を取得する」「年金額を取得」「年金額を取り出す」とかの表記を迷うんじゃなくて「get年金額」でいいと思う。
特にDBにある項目だと仕様とかで先に言葉が決まってることが多いだろうし。
---
見た目について。
見た目が残念とか見づらいというのは同意。
見た目が悪いというのも全部英語っていう前提があるからで1ヶ月も日本語のコード見ればなれるんじゃない？って思う。
---
へとヘ
これはありそうな問題。
ただ、IDEを使う前提なら未使用変数のエラーとか、選択したときに色が変わってないとか、割と気づけると思う。
lとIとかアルファベットでもあるけど、IDEや高機能エディタ使うと困ることはほぼなくなった。
---
私が日本語にしたいような固有名詞をローマ字化してるプロジェクトにであったことはある。
それにローマ字のほうが「ん」でnは1つか2つかや、ヘボンorローマ？という日本語より表記が揃わない問題ある。
特にローマ字の場合自分がキーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。
---
海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。
そういうのは対象外。
今回いいたいのは、元から日本しか対応してないような業務システムなど。
そういったところの固有名詞が日本語になったからって、困ることはないはず。
日本でしか使われないもの・海外向けにするにしてもフルスクラッチで作り直すことになるようなもの、
---
テストだと日本語が使ってる人多いのかな？ブコメのスタートップだし。
---
長くなったけど参考になる意見もいろいろあって助かった。
今日SIerについての話題が目について、実情について書いてみたくなったので書いてみる。初めて増田に投稿するので少し緊張している。
自分は誰かというと、金融系ユーザー子会社に勤めているSEだ。いわゆる１次受け。社員は数千人おり、2chのユー子ランキングではやや上の方に属している。
SIerとひとくくりにして主語を広げたくないので、あくまで私の目で見える範囲の話で、サンプルの１つにすぎないものとして読んでほしいと思う。
【私の仕事について】
まず初めに、自分の仕事はなんだと言われると、それは「システムに関わるプロジェクトマネジメントをする人」ということしか出来ない。エンジニアとしてプログラミングをしたり、ハードの専門的な知識を持っているわけでもない。一日出社から退社まで何をしているかというと、
2.エクセルで作ったスケジュールやWBS(タスクリストみたいなもの)を広げて眺めている
3.問題が発生したら関係者を集めて対策を話し合う。あるいは進捗会議を開く
4.上司やユーザー宛へ説明する資料を作成する。そして実際に説明する
これくらいだ。コーディングという作業が入る余地は一切ない。ひたすら溜まっていくユーザーからの問い合わせや開発側からの問い合わせへのメールを返信する作業を続けている。この仕事で専門性をつけることができるとすれば、プロジェクトマネジメントしかない。プロジェクトマネジメントに関する体系的な考え方、大小に合わせたルールの作成、ユーザーと開発側の折衝ごと。これを突き詰めていくしかない。
同期や周りの先輩、後輩を見る限り、新卒で入ってきたうちの３割が情報系、３割が情報系以外の理系、残りが文系といった印象を受ける。
はてなを見ていてWeb業界やアプリ業界をさらーっとIT系の用語を知ることができたが、おそらく同期の半分以上の人はWordpressという存在を知らないだろう。
会社の中のほとんどの人がGit、GitHubを知らないだろうし、DockerやJavaScript系のライブラリ名を知っている人など皆無だと思う。それだけ、技術に貪欲でないし、それを使える環境はないし、ユーザーも投資しない。
新しい技術は基本的に入れることができない。ユーザー側の経営層がまず理解していないというのと、もしも万一障害が起きたら？という問いに回答できないケースばかりだからだ。だから、今動いているシステムにスパゲッティーをどばどば追加して、秘伝のソースで味付けし、もはや誰にも全容はわかりませーんと言ったことを10年、20年というスパンで行う。
誰も、どうしていいか分からない、どこから手をつけたらいいか分からないのだ。
じゃあ、1次請けだし、ユーザー要件定義が出来るかというとそうでもない。ユーザー業務に精通できないで、ユーザーテスト工程で決めきれていなかったものがバラバラ出てくるなんてザラだ。
ユーザーもユーザーで融通がきかない。個人的に、パッケージシステムを使うと決めたのであれば、どうやってもユーザー業務を変えていく必要があって、それができないのであればフルスクラッチでもっと金かけてやれよと思うのだが、ユーザーはパッケージ入れて安くしたい(金融系のパッケージなんてどれもべらぼうに高価だが)、かつ、業務は変えたくないのでがっつりカスタマイズしてと言ってくる。
また、業務内容によってはミスった時のリスクがでかい。特に法律に絡む案件は、ミスったら数百億の罰金をくらう可能性が常につきまとう。失敗が許されない。金融系のシステムはそういったリスクと常に向き合っていくので、楽しむことは難しい。うまくいくのが当たり前でなければならない。
【やりがいについて】
毎日メールとエクセルとパワポとにらめっこして、ユーザーとベンダーとおしゃべりして、何かやりがいはありますか？と問われると、少しだけあるにはある。
案件規模が億越え、10億とか普通な世界なので、官公庁と連携したりと大きな仕事が多い。勝手にゼネコンの人も同じ気分を味わっているんじゃないのかなーという気になっている(ごめんなさい)のだけど、
例えば「スカイツリー建設のプロジェクトマネジメントをしてました」と言えたら、自分少しは世のためになったかな？と思えると思う。そんな気分に少しだけなれる。自分が作ったわけじゃないけど、大きな仕事に少しだけ関わっているから。
だからエンジニアとして技術で飯を食べていこうとしてSIerに入ってしまった人には酷な会社である。そうやって間違えた同期は早々に転職していった。FBで多くの同期とつながっているが、技術よりのカンファレンスに行きましたとか、勉強会に行きましたといった話は、転職していった人からしか聞かない。会社に残っている同期から流れてくるのはリア充っぽい、旅行や飲み会の写真ばかりだ。
一方で、プロジェクトマネジメントに楽しみや喜びを得られる人には向いていると思う。多くの案件を見てきて、プロジェクトマネージャーが変わった瞬間に物事がうまく行きだしたとか、逆にうまくいかなくなったといった状況をたくさん見てきたので、スキルの必要な仕事であることは間違い無いと思う。それはエンジニアが求めるスキルと異なるだけで、割と専門性を突き詰めることが出来る職業だと思う。その会社特有のやり方に慣れずに、案件をこなしていく中で普遍的なスキルを身に付けることができれば、どこでも通用する可能性もある。(多くの人は会社特有のスキルを身につけてしまって、他社に転職できない状態になるのだが。)
私のやっているSE業と、世間のいわゆるエンジニア業というのは、かけ離れた職業であって、それぞれやりたい方をやればいいと思う。
ただ、私にはミスの許されない超絶大規模プロジェクトに精神をヒリヒリさせながら、数百人月のプロジェクトマネジメントを楽しむなんてことは全く出来ないので、どこか遠くに消え去りたいと日々思っている。
