「フルスクラッチ」を含む日記 RSS

はてなキーワード: フルスクラッチとは

2018-08-26

モバイルアプリエンジニア最強説

理由

 

 

フルスクラッチに限る

 

最近全然単価落ちないな

AIとかデータサイエンティストとか音声アシスタントとかブロックチェーンとかVRみたいなのが流行ってきて助かる

 

2018-07-11

必要車輪を適切な所に当てはめるのを効率化すべき

既にある車輪フルスクラッチして作る仕事を無くしたい

2018-07-05

保守速報管理人さん

事の始まりは6/11消印もなければ料金後納でもない封書が自宅マンションポストに入っていた。

曰く、「貴殿ヘイトスピーチサイトを即座に停止し最寄りの警察署に出頭せよ」とのこと。

示されたサイトURLは、あの悪名高い保守速報だった。

一目見て変だなと思うと同時に、厄介なことに巻き込まれていることを自覚した。

心当たりはある。

私は、自分で言うのも説得力がないが、至って清貧Web屋だった。

全ては独学で、どこの会社に勤めるでもなく、デザイナーコーダープログラマエンジニア出世魚のごとくキャリアを積んできた。

無料ブログサービス使用するブログパーツやテンプレート制作手打ちされたHTMLが無数に存在するサイトCMS移行。フルスクラッチで何万行というコードで書かれた複雑怪奇商品比較サイトブラウザベース動作する業務システム他諸々。

フルスタックという名の器用貧乏で、Webに関連することなら一通りのことはやったと思う。

ペアプログラミングのペの字も知らず一人で突き進み、次第に大量のサイト群をメンテしきれなくなり、新規開発との並行によるデスマーチ日常となった。

下手な自営業典型だったことも災いし、往々にして工数賃金釣りわず相見積もりからの値切りは日常茶飯事だった)、プライベート犠牲にしてまで働く虚しさに日々磨り減っていった。

やがて完全に心を病み後遺症は残らなかったが脳の病気(おそらくは過労が原因だろう)で倒れたことを機に一線から引退した。

鬱の治療をしつつ、近頃はコンサル的な業務か、リアルで付き合いのあるごく一部のクライアントからの受注に絞った。

数年前、インフラエンジニアの知人経由でサーバ関係相談を受けたことがあった。

その際、「一日〇〇万PV級の某有名CMSで動くサイトの負荷対策」として諸々をレクチャーした。無論、例のサイトとは知らずだ。

依頼についての請求書を出した時、こちらの住所を記載していた。(向こうは個人名ではなく見知らぬ会社名だった)

継続して相談を受けるうち、サーバ上で運用されているサイト名を知って手を引いた。

個人情報が漏れたのであればそこからしか考えられず、しかし何故今なのか不思議だった。

例のサイトについて調べるうち、#ネトウヨサイト裸祭りを知った。

最初投函されたその『警告』にも、アフィ広告剥がし運動が行われていることは記載されていた。

さすがに張本人からの物とは思えないが、共感を覚えた誰かしらのうち私の住所を知っている者が(あるいは請求書で住所を知った管理人インフラエンジニアの知人など、私に極めて近い何者かが)リークしたのだろうと思った。

しか相手が何者かも分からなければ、私にはサーバサイトを停止する権限もなく、仮に出頭したところで頭の病気を疑われるだろう。

そのため、内心怯えつつも無視し続けるしかなかった。(後ろめたいところはないが)個人的に警察沙汰は嫌だという気持ちもあり、被害届も出さなかった。

そのうち例のサイトの広告が全滅したというBuzzFeedのニュースを目にして、ようやく安心した。

「ああこれで顔も知らない手紙相手も溜飲を下げることが出来ただろう」「皆も例のサイトへの関心が薄れるだろう」

「ほぼ無関係な私も標的からは外れるだろう」、そんなふうに楽観していた。

そして昨朝になって、前回と同じような差出人不明封書が届いた。

曰く、「サーバ管理人である貴殿らを近々メディア(文春やハフポ、BuzzFeed等)に告発する。個人情報を匿名掲示板及びWiki上で公開する。

サイト管理人〇〇〇(調べれば出てくるが一応個人名なので伏せる)共々罪を償わせる手筈は整った。これは最後通牒である」とのこと。

嫌な予感が当たった。

例のサイトさくらインターネットとバリュードメインの利用規約に違反しているという記事をつい先日読んでいた。

はてブでもそれなりに話題になっていたので、他人事ではなくなっていた私は正直戦々恐々としていた。

ただし、「さくらインターネットや(バリュードメイン親会社の)GMOが今回の件で一方的契約解除などの対処果たして行うだろうか?」という感覚でいた。

広告の件はまだしも、ホスティングサーバ提供するさくら社が動いたとしても、ドメインもといレジストラであるGMOが「(主に第三者による)クレーム」で動くというのは少し考えづらかった。

例のサイトが最高裁に上告したことも知っていたため、仮に契約が停止されるとしてもその段階ではないかという気がしていた。

一方で、私に手紙を送ってきた者は「最初からサイトの停止を目的としていたのではないか?」と思えてきた。

漫画村問題以降、悪質サイト広告剥がしによる兵糧攻め効果的という話が周知の事実となっていたこともあり、広告剥がし運動はその延長にある気がしていた。

けれど、根本的にサイトを潰したいのであれば、捨て身覚悟サイトのもの当事者攻撃を行うのが最も有効だろう。

ちょうど今朝だったかグリーンピースがフランスの原発にドローンをぶつけたというニュースを読んで、なんとなく悟った。

これは「保守速報サーバ管理人である(と誤解されてしまった)私へのテロルである、と。

しかしたら、「本当のサーバ管理人」も同じような手紙を受け取っているかもしれない。

なぜなら手紙には「貴殿ら」と複数形で書かれていたためだ。それに関してはお気の毒だなと感じる一方で、ざまあないねという気分だ。

あくま私見を述べると、現在裁判所係争中のヘイトスピーチに係る問題について、私は例のサイト管理人の肩を持つつもりは一切ないし、法のもとで公平に裁かれることを期待している。

ただ、この一ヶ月弱、ある種の当事者として騒動を見守っていて、やはり「行き過ぎではないか」と感じた。

ネット上で起きた問題であっても、司法のもとで裁かれるべきであって、私刑によって晴らされるべきではないという気持ちがある。

さくらインターネットGMOへの申告は「被害を受けた当事者たち」が行えばよいのであって、それを承知の上で「押すなよ、絶対押すなよ」と言わんばかりの記事拡散して「第三者であり不特定多数善意」を期待するやり方は正直に言って寒気がした。

例のサイトの肩を持つつもりはないと言いつつも、実害を受けている立場上どうしても公平性を欠く見方をしている自覚はある。

元々オタクであり、事ある毎に表現規制絡みのセンシティブ話題を目にしてきたことで、常日頃から肩身の狭さを感じる身ゆえに中立とは呼べない「寛容さ」を持ってしまった可能性もあるだろう。

それでも、第三者を巻き込んだ運動や行動(手紙の件は私には脅迫しか思えなかったが)によって社会が良くなるのならば、という思想は反面で危険はらんでいるように感じる。

他人から何かを剥奪する時、それがたとえ社会的に真っ当な仕打ちと思える処分でも、本来その権限を持たぬ者たちによって軽重が左右されることには本能的な恐怖がある。

なんの利害関係もない、「純粋義憤による裁き」は、その正当性担保されなくなった瞬間に理不尽いじめの構図と変わらなくなる。

ならば「誤っていたと認めなければよい」という方向に流れて、一度始めると引っ込みが付かなくなり、時に際限なく激化する辺りもよく似ている。

いじめられる方にも責任がある」という言い分も心情としては理解できる。かと言って、少なくとも私が受けたそれらは、あくま私自身の範疇で「当然の報い」として飲み込める程度のものではなかった。

第一、私を告発しても(例のサイトへの攻撃としては)まったく意味がないのだから尚更だ。多少の犠牲もやむを得ないということならもう知らないが。

私が今後どのような処遇を受けるか考えたくもないが、社会的な死に陥る可能性は五分五分だろうと思う。

「少しでも関わった時点で同罪」「被害者面すんな氏ね」「増田の住所を特定して晒し上げにしろ」とブクマ罵詈雑言を浴びる可能性を覚悟した上で、それでも今回は書くことにした。

なぜなら、私は手紙に対して直接返事を書くことが出来ないからだ。

せめて差出人がこのエントリを読んで、もしも人違いであると気付いたのならば、文字通り命乞いで情けないが思い留まってほしい。

断っておくが、お先が真っ暗だからと言って、私は低能先生のように自棄になって破滅的な行動を起こす気力がない。

それ以前に、今回のことがなくとも、もうボロボロに病んでいる。義憤に駆られたり誰かに恨みを持つのはそれだけで体力を使う。そういう持ち合わせはもうない。

から、ある日朝起きて、ネットの海に漂う自分の住所を目にした時には、全てを諦めようと思う。

それは明日かもしれないし、幸運にも一生やって来ないのかもしれない。

何事もなかったところで、怯えて日々を暮らすうち、悲観に飲まれて気の迷いを起こすのも人間だと知っている。

たとえ私がいなくなったところで、この国ではよくある、珍しくもなんともない瑣末事として処理されるだろう。

これが遺書にならず、怪文書ポエムの類いとして笑い話になれば幸いだが、念には念をというやつだ。最後はこの言葉で〆ようと思う。

グッド・バイ

2018-07-03

ROBOT魂の方がガンプラより可動範囲も広くアニメイメージがキチンとトレースされてる問題

なんでガンプラではプロポーションアレンジをいつもしちゃうのか理解できない。

頭小さく足が長く、どんなキャラクターガンプラでもバカの一つ覚えのようにこれやってくる。

あげく表面を細かく凸凹させてアニメイメージはまるっきりどこにもなくなってしまう。

ROBOT魂はまずそのキャラクター代表する場面をちゃん再現することをスタートとしているような気がする。

ちゃん再現できるとプロポーションが良い!って思えるしそうそうこれが欲しかったんだよ!って気になる。

そのあとこんなとこが動きますよ、とかシーンを再現するのにこういう可動をしますよってのを見てなるほどな!とまた欲しくなる。

俺は自分で作って出来る範囲で改造して塗装して楽しみたい派なのでなるべくならプラモデルという形で欲しい。

ROBOT魂は完成品だからパーティングラインとかふちの厚みとか塗装とかディテールの入り方などの細部がやはりちょっと厳しい。

買ってきたものに手を入れるのも材質的ちょっと困難だし。

ROBOT魂レベル素体があればいいなっていつも思ってるけど、どうもプラモデル部門は別の爪痕を残したいようだ。

近年の製品でいうとドライセンとバーザムとハンマハンマはアニメイメージで作り直してほしい。とくにハンマハンマは完璧な別物だからアニメ風にするのはフルスクラッチレベルだ。

最新作のガルバルディはわりとちゃん映像イメージが反映されてると思う。

なんとか頑張ってほしいと思う。

2018-01-19

事業会社データサイエンティスト 会社退職しました

元々コンサル会社から事業会社のほうでデータサイエンティストをやるようになって1年経つが辞める。そのきつかったことを匿名という場所卑怯ながらも話したいと思う。

元々私は大学院でそこそこ統計をやってきてからコンサル会社に行きデータサイエンティストとして事業会社へ移った口だ。

根本的にデータサイエンティストとしての資質としてざっくりいうと以下の3つが必要だと思われる。

1. 統計能力関係及びそのプログラミング可視化能力

2. KPI設計及び事業からKPIへの落とし込みからそのKPIからどう事業繋がるかというビジネス設計能力

3. 上を基にしたコンサル能力

能力的には1がやや強く、その次に2がまぁまぁそして3はまだまだといった所で事業会社データサイエンティストとして孤軍奮闘をすることになった。

 入社理由

データはあるが、なかなか活用できていないこともあり、分析から企画から関われるという事で入社しようと思った。

後そこそこ大きな会社で働くのも良い経験と思い入社を決意した。ニッチな分野ではあるが、この分野ではTopカンパニーである

 実際の業務

最初の4日ぐらいは会社研修とかで潰れるのは仕方ないもので、それが終わり早速の業務を行う事になった。

まずはデータ各部門に依頼してから頂くのだが・・・

貰えない。

許可申請関係で3週間程かかってからまず最初データを頂けるようになった。この時点でやる気を削がれた。

更にデータ確認という事で事業へのヒアリングを進めるだけで・・・6週間程かかった。更にやる気を削がれた。

この辺りで気付いた事だが、コンサル会社でいたときは、データ確認がスピィーディーだったのに何故こんな遅い作業なったかというと

日本企業部署跨ぐというのはとても大変で、コンサルとしてやっていたときは単価も高いし、期間内でやらないといけないという事で

いろいろと調整がスムーズに進んでいたという事がこの時に分かった。コンサルとして外から見ているとやはり分からない事は多い物である

分析ツールエクセルだけ

データ確認も終わり、分析をし、改善を行うテーマを決めて進める事になった。この時点で2カ月ぐらい過ぎていた気がする。R/Python自分パソコンへの許可申請を出すが、降りない・・・会社的にはCならばOKだと言われる。でもCの追加ライブラリー関係ダメらしく・・・悩んだ結果エクセルを基に分析をする事になった。現状把握のために基礎集計をするが、エクセルSQLで言うGroup_byやら違うデータ同士をくっつけるためのJoinを32 bit エクセル関数ベースでやると何度も落ちる・・・。この時点でやる気は地の底へと落ちていた。

この辺りでCベースでもう書き直そうかと悩むが、流石にCのライブラリーがない所でフルスクラッチ調に書くのは工数的にかかると考えたのでvbaを用いていた。

エクセルベースでの可視化から上司関係者にデータ分析の結果を見せていく。この辺りでデータ分析から改善策はまとまっていた。しかしこの辺りでやる気をマイナスにして頂ける言葉を伺う。

私がVBAを書いているのをちらっと見て

プログラミング何かやっていても仕方ないし、プログラマーではねぇ・・・。今後会社ではプログラマーなんていらないか企画できるようにならないと」

勿論これは直属の上司からのお言葉ではないが・・・正確には同期である・・・もはや殺意すら覚える。因みにこの人の既存サービスの改良プロジェクトが回った時のデータ収集したら分析する事になっていたが、プロジェクトスケジュール感を見ると

要件定義 2週間

画面設計及び機能設計 3カ月

開発 4カ月

単体テスト・移行テスト 5カ月

運用以降

みたいな形でうん?何か少なくないか?と思ったら既存サービスに関してのギャップ分析無しに既存サービスの改良を進めているらしい

・・・その上取れるデータは〇〇〇で〇〇〇は無いらしい。あっそんなん改善出来んやん・・・。一応私はアリバイ工作のためにメール会議にて発言する

・・・空気を読めないと言われ会議呼ばれなくなってしまう(因みにこのプロジェクト要件定義から運用以降まで外注である)。

最早これは逃亡しかないだろうと心に固く決めてしまう。

私のコンサル的な能力がなかったと言えば確かにその通りである。でもいやうん日本企業の中で、分析をやっていくのは本当に難しいというのがよくわかる。

一人だったというのもある・・・でも殆ど基礎集計レベルで難しい用語を使わず改善を行おうとしたいやでもこの日本企業では無理だった。そしてやりたいと思わなかった。

たまに日本企業でのエンジニアの不遇差を嘆く記事を見かけるが、割と同じようなパターン臭いがする。

追記

新規リニューアルは当然のごとくつぶれ、また私がよくわからない事にawsへの移行だけは上手くいき(?)

200万pvの会員サイトAmazon aws料金を月々リザーブインスタンスで80万ぐらい払っていてクラウド安くないと社内的に炎上しているらしい。どんな設計したのかは

もはや手をつっこみたくないレベル

2017-12-21

バグばっかりだったあのゲームの思い出

きららファンタジアというスマホゲーで何か大きな問題が起こって大騒ぎになっているというのは 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周年

そんなスキマではあったが、何故かサービスは終了せず、サービス1周年の時を迎えた。この時、スキマの開発体制についての発表もあった。現在のスキマのクライアントプログラムは改修を重ねていくが、それと平行して開発ミドルウェアを変更してフルスクラッチクライアントを作り直している、という発表であった。2chスレッドではフルスクラッチクライアントを書き直すということで、バグの根治は当然として、目的の事を行うのに3〜4タップ必要であったりするというUI周りまで手がつけられるのではないか、という事を期待する声が上がったりもした。

また、この1周年挨拶の3ヶ月後には新クライアントの開発状況は70%と発表された。

この頃からであろうか、僕が遊んでいる環境のみなのか、又は他の人ではあまり現れない問題であったのか、とにかく僕が遊んでいる環境では冒険からの帰還を行おうとすると変に時間がかかるようになった。この問題は何らかの原因で帰還操作完了するまでの時間が少しづつ伸びていくという問題であった。この問題は後で僕には大きな問題として認識されるようになる。

この頃からは新クライアントを開発しているためなのか、旧クライアント修正はあまり行われなくなり、定期的なイベントが行われるのみであった。思えばこの頃はスキマの遊び方(このようにするとバグを踏むのでこれはしない、であるかいった遊ぶための作法)がわかっている人間しかスキマを遊んでおらず、運営側積極的には宣伝もしていないため新しいユーザも増えなかったため、比較的安定した運営が行われていたのではないかと思われる。

また、恐らくこの頃であると思われるが、2chスレッドで「スキマは冒険者が冒険をしてきたログを眺めることでそのダンジョン攻略法を考えたりするゲームなんだけど、あまりにもバグが多すぎるから2chというログを読む事でスキマというゲーム攻略しているよね」といった書き込みが行われるなど、スキマをダンジョン攻略ゲーとして捉えるのではなく、バグ攻略ゲーとして捉えるというユーザが現れていた。

期待はずれの新クライアント

さて、一周年の時に発表された新クライアント開発は、その後3ヶ月程で70%まで出来ていると発表されたが、結局その新クライアントがお目見えしたのは2周年を目前に控えた頃であった。新クライアントのお披露目はAndroidβテストという形で行われた。言い忘れていたがスキマはiOSしかサービスされておらず、それまでAndroid版は存在しなかった。僕はAndroidiOSも持っていたため、βテストに応募し、当選したので遊んでみたのである

まず、フルスクラッチ制作されると言われていたので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、つまり平文で行われており簡単通信内容をみることができた。タイトル画面から通信エラーが出るまでの通信内容はだいたい以下のような感じであった。

1. クライアントからユーザ情報送信

2. サーバからセッションキーが送られてくる

3. クライアントから並列で何らかの情報を取得するためのGETリクエスト送信

4. 並列で送られたリクエストへの返信をサーバが返すが、その全てに更新された(別の)セッションキーが入っている

5. ログイン完了してゲーム画面が表示される

6. クライアントで何らかの操作を行おうとしてサーバリクエスト送信

7. 6.のリクエストへの返事が4**でエラー

まり、3. のリクエストが並列で行われ、サーバ更新したセッションキーが 4. でクライアントに届けられるのであるが、恐らくは届いたセッションキー前後してしまうことで壊れてしまったと考えられる。

これが、何故「お知らせ」をタップすると解消するのかであるが、実は「お知らせ」を取得するためのURLhttp://…../login2 というURLへのGETリクエストであり、かつセッションキー必要としておらず、このURLからリクエストの返事にはセッションキーが含まれるという特殊URLであったのだ。つまり本来であれば 5. の状態の時には壊れたセッションキーを保持していたはずが、そこで「お知らせ」をタップすることで新しい(正しい)セッションキーを手にすることができるようになり、その後の通信はちゃんと行えるようになったのである(その後の通信では並列にリクエストを投げるパスは僕の観測した範囲では存在しないように見えた)。

この事に気づいたTwitterの人はどうやって気づいたのかはわからないが、よく見つけてくれたものである。ともかく、僕はこの情報に助けられ、スキマを再開することができた。

長くなったので https://anond.hatelabo.jp/20171221020636 へ続く

2017-10-12

京都市が今回失敗したような、自治体システム更新について

http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/

Q1.役所仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの?

A1.地方自治体事務財務について法律で決まっているのは大枠だけだよ。

  それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセス全然役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。


Q2.なんで新規で作らないの?

A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市更新しようとしてるような、メインフレーム上のシステムだよ。


Q3.メインフレーム汎用機)って何?

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汎用機付属品みたいについてって、困ったらオペレーターとして介入して動かしていたみたいだよ。

そうやって現場感覚バリバリでやっているので、オペレーターしか知らないプロセスがあったりするよ。

マイグレーション開発では総合テスト中にそういう隠しプロセスが「発見」されたりするよ。こわいね


Q6.役所が現行システム資料を出すべきだろうが!

A6.もっともだけど、できないから無理だよ。

上記の通り仕様書がないことも多いうえ、システム課に限らず市役所人員は基本ローテーションするよ。

導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機ことなんてここ10年に入った職員にはわからないよ。



Q7.なんで入札にしたの? 現行ベンダ指名してやらせたほうが良くない?

A7.金額がでかいから、たぶんどこの市役所でも入札案件だよ。

随意契約(随契)は無理だし、入札業者発注者指定する指名競争入札談合の温床になってたか最近あんまりやらないよ。


裏技としてRFP指名したいベンダーに書かせて公募指名入札にしたり、RFPの段階でハードを全部特定ベンダで型番まで指定するというのがあるけど、公になると多分問題になるよ。こわいね



Q8.じゃあ役所は悪くないの?

Q8.悪いよ。

入札案件RFPで書かれた各項目をどれだけ満たすかの技術点と、価格点で決まるよ。点が高ければだいたい自動的にそのベンダーに決まるよ。

なので、技術点の項目に現行システム調査にかかる項目を入れるとかして、現行機の開発・保守ベンダ高得点を取れるようにしておけば価格勝負してくるベンダーをはじけた可能性はあるよ。

もちろん現行の会社に嫌われて逃げられたとか、役所が現行の会社めっちゃ嫌いになって声をかけなかったとかもあるかもしれないけれど、可能性は低いと思うよ。



Q9.じゃあベンダーは悪くないのか?

A9.ここまで述べたようにこの手のマイグレーション火薬庫だよ。火を噴いても爆発しなければラッキーぐらいなので、強いて言うなら入札したことが悪いよ。

安すぎる見積もりを出したSEだか営業だかは死んでね。



Q10.お前(増田)は何者?

A10.前にマイグレーションをやったことがあるSEだよ。もうやりたくないよ。今は転職してSIerじゃなくなったからやらなくてよくなったよ。うれしいね

  しょぼいSEからここに書いたことは個人体験に基づく参照情報だよ。一般的じゃないことを言ってたり、間違ってたら教えてもらえると助かるよ。





(2017.10.13 追記)

Q3がかぶっていたよ。恥ずかしくてなきそうだけどブコメに番号で言及してくれている人がいるから忍んでそのままにするよ。


あと、「オープン化」の定義が違くない?という指摘があったよ。確かに増田が間違っていたので、記事の主旨から外れるけど補記するよ。

メインフレームは本文で述べたようにOSからハードまでメーカー謹製なので独自仕様のカタマリだよ。

これに対しPCサーバ標準規格で作られているよ。こういう標準規格に基づくサーバオープン系と呼ぶよ。

独自規格クローズしたコンピュータから、そうでないオープン系に移行するからオープン化なのであって、専用線とかは関係なかったよ。半可通な知識で語ってしまったよ、ごめんね。

京都市で火中にいるシステムズさんのサイト解説がこの増田よりも分かりやすくて正確だから気になる人は見てほしいよ

http://www.migration.jp/column/column01.html

完全に余談だけどオープン系のx86サーバに移行しても、システムはそんなにオープンにならなかったりするよ。

H系に頼むとDBが拝承DBになったり、Fに頼むとシステム管理が全部SystemWalkerになったり、要するにベンダ独自のミドルに入ってがっつりロックインされたりするよ。

オープン化(オープンではない)みたいなことになって面白いよ(面白くない)

2017-10-11

クラウドワークスの安案件の謎 CMS

クラウドワークスランサーズ

フルスクラッチだと数百万くらいの案件を30万以下で受けてる人が居て疑問だったんだけど

CMS横流ししてる説は割と有力なのではないか

 

でもそうなると、例えば30万円のうちCMS代金が20万とかになって、本人の取り分が超圧縮されてしま

どちらにせよ地獄なんだよね

 

まだ妄想が足りないか

2017-08-28

すべてのソーシャルゲームは、消えていく

日本ソーシャルゲームがヒットして、およそ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万が最低の運営費用だ。盛り下がってきたゲームARPU10円程度になるとして、元を取るためのユーザ数は約63,000人である。もちろんキャンペーンなどで一時的に売り上げが増えるので、もう少し少なくても良いかもしれない。いずれにせよ、今人気のあるタイトルもそうでないタイトルも、徐々にユーザが減ることで売り上げは減り、投入した資金から得られるリターンが減り、人件費サーバ代だけが重くのしかかる。

この時、開発の現場はというと、案外淡々仕事が進められている。慌てふためくのは上位陣のみで、末端作業者は細かな作業改善をしたり、次の異動先に思いを馳せたり、技術向上に努めたりする。また、会社に愛想をつかして退職するのも大抵このタイミングだろう。

その後徐々に、開発の人員が減らされていき、改善のサイクルが長くなり、キャンペーンの頻度も下がる。作業者のやる気はこの辺りで地に落ち、惰性での仕事が続く。当然ユーザからメッセージには平謝りの状況が続く。何度か、大きめのリリース広告を放つこともあるが、一度沈み始めた船はなかなか浮上することはない。そして、ある程度の利益を食い潰した(もしくは赤字に耐えられなくなる)ところで、いよいよ赤信号が現示される。

サービスを終了せよ」

この時、開発チームに余力など残っていない。決められた期日までにきちんとたたみ終わることが目標である開発者はこのプロジェクトを終わらせることができホッとすると同時に、できればなんらかの形で残したいと思うかもしれない。しかし、それは叶わないことが目に見えているのだ。昨今のアプリローカル側、つまりスマホにあるゲーム部分は結果を受け取る・ゲームプレイする、素材を指定するといった入出力の機能しかなく、主なシステムロジック、つまり実際にガチャを引いたり、素材を手に入れたり、結果を処理したりするのはサーバ側に実装されている。このため、ローカル側に全てを実装するのはサーバ側の機能フルスクラッチをするのと変わらず、とてもこんなことをする暇はない。また、昨今クラウドの様々なプロダクトを組み合わせて実装しているものも多く、素直にソースコードを書き直せば実装できるといった類いのものでもない。

そうして、ユーザ開発者それぞれが複雑な気持ちを抱いたままソーシャルゲーム消失する。

稀にあまりあるほどの利益を稼ぎ出したアプリであれば、ストーリーイラストアーカイブ配信される幸運な例もある。これは開発者経営側のプライド感謝人件費の消化であり、非常にラッキーなケースだ。

しかし、いずれにしてもゲーム自体が残ることはないのだ。

開発者でさえゲームを起動することはおよそ叶わない。なぜなら、複雑なサーバ構成再現せねばならないからだ。せいぜいデバッグ機能でバトルやUIをちょこっと動かすぐらいしか出来ない。

これがソシャゲのあらましである。いま流行りのあのゲームもこのゲームも、いずれは幕が降りるのであるソーシャルゲーム時代とともに人の心の中へと消えていくのだ。

2017-05-19

二年前に受けた某企業技術研修について

ふと思い立ったので書いてみる。二年前、新卒として某企業技術研修を受けた。Javaを用いて、自分たちで一つのプロダクトを作るという研修である技術を推している会社なので研修内容にはかなり期待していた。Spring等のフレームワークの話、JavaフロントエンドのAngularやReactをどう連携させるか、もしかして自作フレームワークを作る研修も受けられるかも、などなどの話を入社前にはしていた。実際そうではなかったわけだが。

詳らかに書くことは出来ないが、当時最も憤ったのは研修の成績をどうやって決めるかに関する講師の考え方。中間発表で企画発表を行い、最終発表でプロダクトとしてのレビューを受けて、プレゼン大会を行って成績が決まった。自分はどちらも中くらいの成績だったらしい。

ここで驚いたのが、コード量が成績評価に結び付くということだ。コード量の最適化という意味ではない。フレームワークなどを使ってコード量を減らしてはいけない、フルスクラッチプロダクトを作れということだった。意味が分からなかった。

評価するためには十分量のコード必要ということは理解していた。過去研修で何人かがフレームワークを用いて適当に作ったプロダクトで済ませようとしたエピソードなどを聞かされた。それはわかる。わかるが、そうした怠慢に基づくモチベーションではなくよりよいプロダクトを作るために先人の肩に乗るのは許されるべきではないのか?

Javaによるプロダクトを理解するため、フレームワークを使うとフレームワークが廃れたときに何にもできなくなる、という言葉を何度も聞かされたが、Javaプロダクトを理解するのならそれこそフルスクラッチ要求するのではなく歴史があるSpringで十分だし、フレームワークを使ったからといって魔法のように自分の望むプロダクトが出来上がるわけもなく、自分で考える部分が大部分を占めることは自明ではないか。むしろ、その考える時間という本質的な部分を確保するためにフレームワークなどの技術を用いるべきではないのか。

Reactを学びたいモチベーションがあり、Java側でなければ、というかReactはフレームワークじゃないし大丈夫だろうと思って実装を進めていた時に講師の方からフレームワークは認められない」と言われ、食い下がったもののまるで話が通じなかった。結局自分はそこから大きく計画修正し、適当プロダクトを作った。モチベーションは地の底に落ちた。そもそもプログラム研修なのに渡されたPCWindowsで、エクセル地獄だった時点でモチベーションはまるで高くなかったがReactをやるというのがモチベーションになっていた。それも無駄だった。

今年の新人も同様のカリキュラムだという。しかもまだWindowsフレームワークは一切使えない。エクセルワイヤーフレームを書けという。SIじゃないか大丈夫だろうと思っていたのに、という新人はたくさんいるだろう。配属後もコードを書く時間はどんどん減っていく。自分自身勉強し、論文技術書を読み、週末に自分プロダクトを作る習慣をつけておかないといけない。自衛しないといけない。

そんな不幸な人たちがいればいいのにと思った。

2017-05-18

いい加減受託システム開発なんてやめたら?

もうシステム開発なんてするべきじゃない

有りものパッケージWebサービスで十分便利だよ

フルスクラッチやらカスタマイズバグバグ製品を作るなってはなしよ

多少のアラやらミスマッチ業務パッケージ側の想定するフローに合わせた方が99%幸せになれる

いや、もちろんパッケージ作ったりWebサービス作るのは良いんだけど

ITにも疎くて自社業務についてもよくわかってない輩の御用聞きは止めるべきだ

こんなの作ったところで、プログラマー疲弊するし、実際には使われないしで誰も報われない

産業廃棄物ができるだけだ

いい加減他のことしようや

2017-05-03

そこにノイエスはあるのか?

フルスクラッチで作り直したとして、これまでに達成できなかった何か

が実現されるのか?

ただ「今風になった」「流行に乗ってる」というだけのために工数をかけて

作り直す価値のあるウェブアプリなのだろうか?

http://anond.hatelabo.jp/20170503205540

フロントエンド保守メンテを考えないで開発するのが良い

フロントエンド開発はころころフレームワークが変わっている。

90年代からソフトウェア開発をしている人間には信じられないのだが

これはもう、保守とかメンテナンスとか考えて実装して行くよりも、

新しいフレームワークを選定して、さっさとフルスクラッチで作り直すのが一番早い。

フロントエンドは2年たつともう古臭くなってしまうので、

2年に一回、1~2カ月だけ使って新しくしてしまうのが良い。

2年もたつと、古臭いのはもとより、同じ開発者である可能性も低く、

昔の人の謎仕様修正できない、なんてこともよくあることなのだ。

しかも昔は必要だったけど、今はいらなくなった仕様なんて腐るほどある。

仕様追加の繰り返しで、結局最初機能いらないじゃん、なんてこともあるので、

作り変えてしまって捨ててしまうのがよい。

さすがに似たようなフレームワークであれば、変える必要がないのであるが、

新しいフレームワーク採用する決断をしたら、もうさっさ古いのは捨てて、

作り直してしまおう。

2017-04-21

プログラム日本語で書けばいい気がするけど(追記した)

定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。

実践はしていない)

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

日本語でいいと思う理由は主に2つ

○画面に表示する時

フレームワーク言語にもよるけど表示するとき英語名前から日本語名前に変換して表示って手間があるものがある。

最近見かけた例だと.NETプロパティ属性に表示名書いて表示するときに取り出していた。

最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける

英語がわけわからん

まず自分英語化するとき

いい単語が出てこないとか、しょっちゅう

慣れが必要だし慣れてもなんかコレジャナイ感とかで苦戦する。

次に他の人の英語化したのを見る時。

その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもchildsみたいな謎の語があったり。

そこそこできる人同士でも、「私はニュアンス的にこっちの単語」「僕はこの単語のほうがいいと思う」とかある。

相手の書いたところがわかりづらいのはもちろんだけど、プログラム的に同じ意味なのにクラス関数によって呼び方違うと辛い。

かといって全員に日本語英語対応を先に渡しておいて統一しようというのは大変すぎる。

日本語だと仕様の時点で日本語で書いてるからまぁおかしなことにはそうならないはず)

そういうわけで日本語で書けば色々解決するのにって思う。

----

次にデメリット

軽く調べた感じ主にこの2つな感じ。

IME」「英語圏のものへの対応

IME

半角全角を打つのってめんどい

と思うけど、実際チャットやこういう文章書いてて英語が出るときに割りと頻繁に押してる。

ほぼ無意識でやってて意外と苦じゃない。

短いとF10変換で半角にすることもあるけど、キーボードタイプカウンタとか入れてみると半角全角キーはけっこう上位にいた。

それに、なんだかんだコメント日本語で書くことが多くて、他の人と作るのならこまめにコメント書いてる。

そうなると全角半角の切り替えは普段からあるもので、あんまり気にするほどじゃない気がした。

最近じゃIDEエディタの補完が優秀だし、日本語にするにしても「最初はjから始める」とかルール入れておけば「j」って打ってあとはスコープにあるいくつかの候補から選ぶだけで全角にしなくていいかもしれない。

英語圏への対応

githubで公開したりとかライブラリ再利用してもらうとき日本語じゃ使ってもらえない。ってことみたい。

私が日本語にすればいいじゃないって思ってるのは、ビジネスロジックというかそのアプリケーション固有名詞みたいなところ。

「足し算」って関数名は 「add」 でいいと思うし、配列のそれぞれは element とか item とかそういう一般的英単語でいいと思う。

具体例がいいづらいけど、業務システムで表示する金額名前とか、日本語独特なものとか、一般的単語じゃなさそうなの。

こういうのを日本語にしたいってわけなので、ライブラリ的な共通なところは英語で良いかgithubで公開する範囲英語のものでいいと思う。

ただ、最近はやってるマストドンとか、ライブラリ的なものじゃなくアプリケーション自体githubで公開する場合はできない気がする。

でも、海外対象にしてるものだと日本語特有なせいでわかりづらい英語になる苦労とか少なそうだしそういうのだと英語いいんじゃないかな。

----

長くなったけど、まとめると、

業務システム固有名詞とか日本語特有ものとか無理に英語化してよくわからないことになってり、見づらくなるくらいなら日本語使えばいいんじゃないかな

ということ。

まあ思ってる割には実践してないので、やってる人がいたら良かった・悪かったとか聞きたいなと思ったのが書いた理由

追記


帰ってきたらすごいブクマついてた。

色々意見あってとりあえず感謝

絶対自分でやってから言えよ」みたいな意見来るだろうと思って今日の空き時間日本語行ける言語調べたり軽く日本語使ってコード書いてみたので、そのあたりと目についたコメに答えてみる。

まず、思いの外日本プログラミング言語上げてる人がいたので、うまく伝わってなかったぽい。

具体例上げずにサッと書いたらからかな。

あと自分もわりとするけどタイトルだけ見て中身見ずにコメントしてた人もいるだろうなー。

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

これが、などしこやひまわりや、BF系のmisaやら北斗のあれやらうにゃーとか色々な「構文など最初から日本語を前提とした言語」ではないってこと言ってた。

---

日本語かえる言語

最近の主要な言語ならだいたい Unicode 対応でしょと思って環境があった言語を試した結果はこうだった。

JavaScript/Python/PHP/Scala/Kotlin/C#/Go/Swift

これらは日本語変数作れた。

rust と Lua は無理だった。

rust は確か前に、変数名が ascii 文字だけなことに日本以外のどこかの国からUnicode対応にしてって多くの要望あったみたいな記事があったし将来的に対応するんじゃないかなって思ってる。

実際に今どんな状態かは知らない。

その記事コメントとかでみたけど、日本語以外は割りと自国言葉を使ってたりするっぽいね

(正確なデータはないか信憑性はあるとはいえないけど)

VBA を上げてる人がいたけど、私はそこまでのはみたことない。(幸せ者っぽいな)

稀にエクセルマクロいじるときに使い方ググってて出て来る、解説してるページで関数名が日本語なのをたまに見るくらい。

パット見なんか気持ち悪い感はあるけど、読んだときのわかりやすさはけっこう大きい。

---

○使ってみて

大規模案件に使ってみてこその問題もあるだろうけど、簡単スクリプト程度のを日本語にしてみて気づいたこと。

割といける。

全角半角キーPHP の $ より楽。

PHP言語変数は全部$からはじめないといけない欠陥言語

まあ変数のみのgrepのしやすさや予約語キーワード変数名に使えるからメリットもある。

だが、$って打ちづらい。

Shift+4ってすごいつらい。

に比べて全角半角キーってちょい遠いけどそこまで苦痛じゃない。

ふだんから多用してるキーなわけだし。

ただPHP日本語の組み合わせは相性悪い。

$は半角でその後に日本語から手間が多すぎる。

それ以外の言語だと、IMEのおかげでかなり楽。

GoogleIMEだけど、多少のタイプミスは補完で修正してくれるし、予測変換が優秀だし。

IDEいから補完機能のない軽いエディタで書くようなときなら、IMEのおかげで英語変数名で書くより速度は早いと思う。

---

少し前に知人から言われた日本語デメリットを思い出したのでそれも触れとく。

仕様変更言葉変わったとき日本語だと全部書き換えないといけないよ。英語だと別にそのままでいいし。」

英語からない人が、英語言葉とみなさずただの記号として考えてるから、っていうような発言

仕様変わって変数名まで変えるのは面倒なのはわかるけど、あとからコード読む人が英語で見て意味不明になる。

英語日本語対応コメントに書いたとしても、全然意味の違う英語があるのは混乱でしかない。

こういう考えの人がいたら本当にやめてほしい。

---

あとは気になったコメントについて書いてく。

表記ゆれとか方言とか言い回しなどについては、全部日本語にするとあるだろうけど、私が想定してるのは直感的に英語にならないような固有名詞とか。

DBの項目名日本語っていうのは私の思ってるのと近い。

年金の例も○○年金というのがいろいろあって、全部英語だと嫌になってくるしよくわかる。

こういうのを日本語にしたい。

なので年金額を取得する関数で「年金額を取得する」「年金額を取得」「年金額を取り出す」とかの表記を迷うんじゃなくて「get年金額」でいいと思う。

こういう単語だけだと表記はそれなりに揃うと思う。

特にDBにある項目だと仕様とかで先に言葉が決まってることが多いだろうし。

---

見た目について。

見た目が残念とか見づらいというのは同意

ただそれ以上に読んだときのわかりやすさが大きいと思う。

見た目が悪いというのも全部英語っていう前提があるからで1ヶ月も日本語コード見ればなれるんじゃない?って思う。

---

へとヘ

これはありそうな問題

ただ、IDEを使う前提なら未使用変数エラーとか、選択したときに色が変わってないとか、割と気づけると思う。

lとIとかアルファベットでもあるけど、IDEや高機能エディタ使うと困ることはほぼなくなった。

---

ローマ字

私が日本語にしたいような固有名詞ローマ字化してるプロジェクトにであったことはある。

やすい語は見やすいけど、見づらい語は圧倒的に見づらい。

それにローマ字のほうが「ん」でnは1つか2つかや、ヘボンorローマ?という日本語より表記が揃わない問題ある。

特にローマ字場合自分キーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。

---

ラバゴス化・日本が遅れる

海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。

そういうのは対象外

今回いいたいのは、元から日本しか対応してないような業務システムなど。

そういったところの固有名詞日本語になったからって、困ることはないはず。

もともとガラバゴスなわけだし。

日本しか使われないもの海外向けにするにしてもフルスクラッチで作り直すことになるようなもの

こういうのは日本語化いいんじゃないかと思う。

---

テスト

テストだと日本語が使ってる人多いのかな?ブコメスタートップだし。

とりあえずはテストから使い始めてみようと思う。

---

長くなったけど参考になる意見もいろいろあって助かった。

2016-11-28

金融SIer仕事について書きたい

今日SIerについての話題が目について、実情について書いてみたくなったので書いてみる。初めて増田投稿するので少し緊張している。

自分は誰かというと、金融ユーザー子会社に勤めているSEだ。いわゆる1次受け。社員は数千人おり、2chのユー子ランキングではやや上の方に属している。

SIerとひとくくりにして主語を広げたくないので、あくまで私の目で見える範囲の話で、サンプルの1つにすぎないものとして読んでほしいと思う。

【私の仕事について】

まず初めに、自分仕事はなんだと言われると、それは「システムに関わるプロジェクトマネジメントをする人」ということしか出来ない。エンジニアとしてプログラミングをしたり、ハードの専門的な知識を持っているわけでもない。一日出社から退社まで何をしているかというと、

1.ユーザーベンダー宛てにひたすらメールを返信する

2.エクセルで作ったスケジュールWBS(タスクリストみたいなもの)を広げて眺めている

3.問題が発生したら関係者を集めて対策を話し合う。あるいは進捗会議を開く

4.上司ユーザー宛へ説明する資料作成する。そして実際に説明する

これくらいだ。コーディングという作業が入る余地は一切ない。ひたすら溜まっていくユーザーからの問い合わせや開発側からの問い合わせへのメールを返信する作業を続けている。この仕事専門性をつけることができるとすれば、プロジェクトマネジメントしかない。プロジェクトマネジメントに関する体系的な考え方、大小に合わせたルール作成ユーザーと開発側の折衝ごと。これを突き詰めていくしかない。

エンジニアとしての知識について】

同期や周りの先輩、後輩を見る限り、新卒で入ってきたうちの3割が情報系、3割が情報系以外の理系、残りが文系といった印象を受ける。

はてなを見ていてWeb業界アプリ業界さらーっとIT系用語を知ることができたが、おそらく同期の半分以上の人はWordpressという存在を知らないだろう。

会社の中のほとんどの人がGitGitHubを知らないだろうし、DockerJavaScript系のライブラリ名を知っている人など皆無だと思う。それだけ、技術貪欲でないし、それを使える環境はないし、ユーザー投資しない。

新しい技術基本的に入れることができない。ユーザー側の経営層がまず理解していないというのと、もしも万一障害が起きたら?という問いに回答できないケースばかりだからだ。だから、今動いているシステムスパゲッティーをどばどば追加して、秘伝のソースで味付けし、もはや誰にも全容はわかりませーんと言ったことを10年、20年というスパンで行う。

誰も、どうしていいかからない、どこから手をつけたらいいかからないのだ。

要件定義について】

じゃあ、1次請けだし、ユーザー要件定義が出来るかというとそうでもない。ユーザー業務精通できないで、ユーザーテスト工程で決めきれていなかったものがバラバラ出てくるなんてザラだ。

ユーザーユーザーで融通がきかない。個人的に、パッケージシステムを使うと決めたのであれば、どうやってもユーザー業務を変えていく必要があって、それができないのであればフルスクラッチもっと金かけてやれよと思うのだが、ユーザーパッケージ入れて安くしたい(金融系のパッケージなんてどれもべらぼうに高価だが)、かつ、業務は変えたくないのでがっつりカスタマイズしてと言ってくる。

また、業務内容によってはミスった時のリスクがでかい特に法律に絡む案件は、ミスったら数百億の罰金をくらう可能性が常につきまとう。失敗が許されない。金融系のシステムはそういったリスクと常に向き合っていくので、楽しむことは難しい。うまくいくのが当たり前でなければならない。


やりがいについて】

毎日メールエクセルパワポとにらめっこして、ユーザーベンダーとおしゃべりして、何かやりがいはありますか?と問われると、少しだけあるにはある。

案件規模が億越え、10億とか普通な世界なので、官公庁連携したりと大きな仕事が多い。勝手ゼネコンの人も同じ気分を味わっているんじゃないのかなーという気になっている(ごめんなさい)のだけど、

例えば「スカイツリー建設プロジェクトマネジメントをしてました」と言えたら、自分少しは世のためになったかな?と思えると思う。そんな気分に少しだけなれる。自分が作ったわけじゃないけど、大きな仕事に少しだけ関わっているから。


からエンジニアとして技術で飯を食べていこうとしてSIerに入ってしまった人には酷な会社である。そうやって間違えた同期は早々に転職していった。FBで多くの同期とつながっているが、技術よりのカンファレンスに行きましたとか、勉強会に行きましたといった話は、転職していった人からしか聞かない。会社に残っている同期から流れてくるのはリア充っぽい、旅行飲み会写真ばかりだ。

一方で、プロジェクトマネジメントに楽しみや喜びを得られる人には向いていると思う。多くの案件を見てきて、プロジェクトマネージャーが変わった瞬間に物事がうまく行きだしたとか、逆にうまくいかなくなったといった状況をたくさん見てきたので、スキル必要仕事であることは間違い無いと思う。それはエンジニアが求めるスキルと異なるだけで、割と専門性を突き詰めることが出来る職業だと思う。その会社特有のやり方に慣れずに、案件をこなしていく中で普遍的スキルを身に付けることができれば、どこでも通用する可能性もある。(多くの人は会社特有スキルを身につけてしまって、他社に転職できない状態になるのだが。)

私のやっているSE業と、世間のいわゆるエンジニア業というのは、かけ離れた職業であって、それぞれやりたい方をやればいいと思う。

ただ、私にはミスの許されない超絶大規模プロジェクト精神をヒリヒリさせながら、数百人月プロジェクトマネジメントを楽しむなんてことは全く出来ないので、どこか遠くに消え去りたいと日々思っている。

2016-06-14

多様性なんていらねえ

フルスクラッチシステム作るのやめろ。ほぼ全部パッケージでいい。

地域に密着した飲食店とかやめろ。全部マニュアル化されたチェーン店しろ

きめ細かいサービスやめろ。一般的用途に従わないユーザーは客として扱わなくていい。

多様性を持たせるな。なにもかも共通化して省エネにして労働を減らせ。

2016-05-29

富士通退職した話」に言及とついでに自分の話でも。

自分も前に富士通に居て既に退職してます。後で詳しく書くけど、ソフトウェア開発職に居たです。

富士通を退職した話

彼のへの感想

富士通はクソでっかい会社なんだし、サイト見ればメインフレームやってるのだって判るんだから、開発職を希望したらメインフレーム関連の開発やる可能性あるのは当然予見出来るだろうし、それを想像してなかったのなら情弱とかブコメで言われてしまうよね。あと何も記述が無いか想像だけど、「それほど有能ではない」と判断された可能性もある。と言っても学生が思う「開発者として有能かどうか」ってのと会社でのそれってのは別物で、要するに学生自身自分が実績もあって優秀だと思っても、会社的にはそうでないのよね。そうなると(後述の富士通入社して10年が経った人の話にもあるのだけど)新人能力客観的判断材料って大学資格応用情報レベル以上)程度なのよね。資格に関しても基本情報なんてMARCHクラス以上の人間なら受けたら取れて当然だから、「有能かどうか」の判断材料にならない。就活の際に本気でIT業界に入りたいかどうかの判断材料にはなる程度。自分の同世代富士通本体に入ってソフトウェア開発関連に配属された人のプロフィールを見たけど、確か偏差値的には少なくとも神戸大学とか千葉大学あたりの修士しか居なかった覚えがある。あと確か2~3人がソフ開持ってた気がする。だから、この増田がどの程度だったのかなと。

ただ、20人月案件が具体的に何かは判らないのだけど、自分の在籍していた当時でも炎上巨大案件というのはあって、(自分が知ってるのは確かデジタルテレビがどうのこうのとか言ってた)、そういうのに入社して間もなく入ってしまうと自身勉強等が出来なかったり潰されたり最悪死んだりするんで、そういう意味でも逃げるのは正解の一つ。(自分炎上案件に放り込まれ新人が寮で死んでたとか話を聞いたことある

上司対応はまあこれだけ見ればクソだわな。

富士通を退職して思うこと

はあ、としか。この人がこう判断した際の判断材料にするであろう自己体験を具体的に書いてないので、意識高い系がフカしてるようにしか見えない。あと、たった3年しか居なくてあの巨大企業経営とか体制とか理解出来るんかね?と思わないでもない。自分とは部署が違うだろうから当然かもしれないけど、自分体験とは違うなーって感じ。自分は、外から見たら馬鹿みたいな事やってるように見えるかもしれないけど、経緯や目的巨大企業特有問題があってそうなってるんだなって思う事が多々あった。

富士通に入社して10年が経った - blog

近い時期に入社したと思われる。具体的な話が自分経験と一致してる。特に富士通ソフトウェア開発と言えばミドルウェアの開発が主だというのは、富士通内部じゃないとなかなか(特に学生なんかじゃ)判らないかなと。

それでこれらの話を見てどんな人が富士通(というか大企業)に向くのかなと考えたんだけど、「やりたいこと」そこまで明確じゃないけどコンピュータは嫌いじゃないって感じで、地頭がまあまあ良くて勉強に関しても要領よくやれる(要するにそこそこの大学に行って卒業した人)、それでそこそこ安定した職・収入目当てな人かなと。ってコレ書いててふわふわしてる人みたいであまり良い印象の人物像じゃないな。マッチングミスはどうしても起きると思うし、学生の頃に思う「やりたい事」って往々にして変わったり間違いだったりするし、そもそも学生の頃に明確な「やりたい事」がある人の方が少数派でしょ。だからこういうそこそこ優秀だけどふわふわしてる人の方が良いんじゃないかなとか。逆に、ちゃんと「やりたい事」が明確にあるけどまあ安定はしたいって人はどうしたらいいのかって言うと、自分みたく大企業の子会社を狙うと良いんじゃないかなと。子会社ならその会社がやってる事が理解やすいし、入った後の配属の希望も大きく違ったものにはなりにくいし。まあ子会社子会社で色々アルかもしれないけど。

で、自分入社から退社までの話。

入社10年ぐらい前。入ったのは富士通の子会社で主にミドルウェアの開発をやっている所でした。入社して1~2年したら子会社の統廃合とのことで富士通本体連携してる部署自分がそうだった)は富士通本体になりますとのことで富士通本体の方に移ったという経緯ですね。別に待遇とか元々本体と同じだったから変わらず、事務関連が小回りきかなくなったぐらい。入社してから退職までは5年ぐらいでした。辞めた理由実家事業を継ぐ事にしたため。

入社して数ヶ月の時にある温泉地にある某所でその手の開発をやってる子会社沢山と

富士通本体ソフト開発配属の人達研修をやったのだけど、その際に富士通本体人達と知り合った。(この際に全員のプロフィール冊子が配られた)そのときは流石子会社に入る人達本体とじゃレベルが違うな~と思いましたね。(ちなみに自分MARCHより下の院卒。)

自分が配属されたのは某製品部署API部分チーム。その製品C言語Java言語からも使えるように出入り口を用意する部分。中でやってる事は指定されたIPポートプロトコルに沿ってデータ投げるだけなんだけどね。ちなみに配属希望の際は「そこそこの忙しさの所がイイ」と言っていました。「バリバリに働きたい」と言ってた同期は多忙ヤバい所に配属されてました。他にもチームがいくつかあったけど、それらのうちの一つは例の「山奥の工場」でしたね。自分が配属された当時はC言語APIリニューアルするって開発してたのだけど、設計担当Javaしかやったことない人で色々とC言語流儀に反してて後々のメンテが大変でした。まあそれでもリニューアル前よりは遙かに良くて、以前はユーザに見せてる関数名が ○○search1 ○○search2 ○○search3 とかでしたね(ちなみに機能はそれサーチか?思うのもあった)。もっと酷かったのが初期製品Javaの公開メソッドで、マニュアルには「このメソッド引数○○を□□を指定した場合戻り値Objectを△△にキャストしてください。××を指定場合は…」という「これ製品にして売ってたんだ…」と思うレベル。もちろんコレがダメだったってのは開発側も認識していて当時は既にリニューアル済みだったけど。リニューアル済みでも少し微妙だったけどね。

これは、ミドルウェアの開発をやってる人達って基本的C言語が主でJavaとかをやってる人がほぼ居なかったからだと思う。上司もそういうのは良くないってのは認識してた。対象OSWindowsLinuxSolarisだったけど、そんなにたいした事やってなかったからほぼ同じコードだったような。ソケットの一部だけ違ってたっけかな。

それでそのバージョンの開発が終わったあたりで、.NET Frameworkが出始めてきたので次バージョンでは.NET FrameworkAPIを作る事になりまして、自分が少し勉強していたのでそれの設計から担当する事に。当時は.NET Framework 1.1で今思えば少し時期が早かったと思う。2.0Genericが出てからやった方が良かったと思うんだけど、そういうの政治的判断だし結果論だしなー。それまでにRubyとかオブジェクト指向言語に触れてその辺の勉強もしていたので、.NET用のAPIに関しては設計実装結構良い感じに出来たと思う。ああ、そういえばRuby用のAPI効率化の開発ツールとかの名目仕事中に勝手に作ってたなあ。他にもC言語APIも内部実装がクソすぎ!とキレてユーザ公開関数インターフェースだけ同じで中身をフルスクラッチした事も。もちろん絶対LDしてるんで完全に趣味なんだけどな。これでAPIC言語Java.NETになった訳だけど、現場案件で使われたのってほぼ全てJavaだったと思う。(開発中のサーバテストアプリC言語だけど)。要するに自分が数年関わったコードが世の中ではほぼ使われてない訳でして、取りそろえとして必要だったとはいえ世の中の役に立ってないってのは嬉しくは無かったですね。まあ、大企業仕事なんてそういうもんです。.NETに関してはそのバージョンが出る頃はその製品があまり売れてなかったんだか使われたって話は聞かなかったですね。ほほほ。大企業に勤めるのならこういう覚悟必要かもね。

で、.NETAPIが出来たあたりに開発ネタがなくなって保守気味になってきたので、人員整理作業整理との事でインストーラと切りたいけど一度やったからには切れない補助製品担当が増える事に。インストーラWindowsがInstallShieldというクソみたいな言語上で作られたものLinuxSolarisシェルスクリプトのもので、InsallShieldの方のコードはあまりにクソなのでリファクタリングさせてもらった。この辺の開発は少なかったのだけど新OS対応(Vistaとか)とか保守作業が大変だった覚えある。

んで、これらの作業が終わったあたりでこの製品でやることが無くなってきたのと同時に、この製品派生製品の話が出てきてて、それは1機能1exeで提供されてて、それらを纏めるバッチ処理機能部分を担当することに。バッチ処理の内容・順番を記述するのにXMLを使う事になったのでXMLのパーサが必要なのだけど、色々調べたら富士通内部でパーサ作ってたのでそれをもらって使う事に。そのパーサはC++からじゃないと使えなかったのだけど、趣味C++勉強してたので何とかなった。あと、結構OSの知識(プロセスとか)が必要WindowsLinuxSolarisで動くコードを書く必要があってまあまあ大変でした(と言ってもifdefで切り分けるだけなんだけど)。けど、これらの開発は自分が一から設計してコードを書いていたので楽しかったですね。それでこれが完成するかしないかあたりで、このバッチ処理機能が他の開発中の製品バッチ処理に使えないかとか話が出てきたあたりで自分退職する事に。(退職の話は1年ぐらい前に話し合って決定済み)引き継ぎをして退職ということになりました。最後は溜まった有給を使う予定でまだ在籍中だけど部屋を引き払って実家に帰ってたのだけど、打ち合わせに来て欲しいって言われてしま実家から何日か通ったのは良い想い出。というかまさか実家から朝8時に間に合うとは思って無かった。

振り返ってみて残業時間は月40~60時間が多かったかな。100時間超えた時は上司に怒られた。あと退職前の1年ぐらいはうちの事業本部(だったかな?)単位残業禁止になってホント残業0時間になった時期があった。他の部署の人の話で、どう考えても狂ってる上司の話とかを聞いてると上司とかの運は良かったと思う。あと、やっぱり仕事でみっちりプログラミングが出来たのは運が良かったと思う。富士通ソフト開発で C C++ C# Java シェルスクリプト InstallShieldとか(そんなに深くはないけど)色々やれた人間はそうそう居ないんじゃないかな。同期とかの仕事は年上の人の派遣の人に指示出したり取り仕切ったりする仕事とか、保守サポートみたいな開発じゃない仕事の話も良く聞いていたので、ソフト開発のキモ体験出来たのは良かったです(こなみ)。

2015-12-11

http://anond.hatelabo.jp/20151211012227

880 名前番組の途中ですが名無しです[] 投稿日:2006/06/07(水) 23:45:37 ID:RnF+q3dVO~

 ウィンドウズ、ワードエクセルIE

 こんなのはツギハギだらけで奇形化した過去遺物

 PS3が出たら過去遺物になるよ。

 SCECell向けにプログラム最適化して、

 さら3D-GUI(XMB進化系)を前提にしてフルスクラッチ作成したプログラムを使えば、

 過去遺物と糞遅いレガシーデバイスを前提とした

 糞プログラムでは、考えられないほどの

 快適性と効率が得られるようになるよ。

 お前らもなんだかんだ言って、今使ってるパソコンを捨てて

 PS3仕事ネットするようになるだろうね。

 まあ見てなって。

2015-07-04

まれて初めて二次元キャラクターオカズにして一ヶ月

増田感情的記事を書いて約一ヶ月が経ったけど、だいぶ落ち着いた。

二次元に冷めたわけじゃない。愛情も性欲も余裕で継続してる。

http://anond.hatelabo.jp/20150608210855

 

二次元欲情した程度で傷つくとは、自分をどれだけ高尚な存在だと思ってたんだ」系のコメントをもらって、

まあ、そうだよなと思った。別に人々の手本になるべき立場でもないし、迷惑をかけない限り好きに生きればいいのだよな。

 

もう好きなキャラクターpixiv作品は見尽くしてしまったので、好きな同人作家さんの他の作品も見るようになった。

弱虫ペダル刀剣乱舞などの人気ジャンルでも創作していることがあって、原作を知らなくても楽しめた。

腐女子世界では「ジャンル友達より、性癖友達の方が長持ちする」と言われているらしい。

わかるかもしれないと思った。だって趣味が同じ人の作品なら、原作を知らなくても良かったわけだから

 

あと、長らく腐女子少年マンガばかり好むことを謎に思ってたけど、それも解決した気がする。

少女マンガだと、このキャラとこのキャラはこういう恋愛しますよ、と作者に決定されてしまう。

言い方が変かもしれないけど、同人作家創作プラットフォームとして世界観キャラクターを用意して欲しいんだね。

そして恋愛セックスなどの要素はサードパーティーである私たちに投げてくれという感じ。

これ、刀剣乱舞でめちゃくちゃ顕著じゃないですか?狙ってやってませんか?

 

好きな作家一次創作もやっていたことで、オリキャラ界隈も覗くことになった。

ここまで来ると男性作家が多くなってくる。人外・ケモショタなど、現実で叶えられそうもない嗜好の数々。

それに萌えるかというと別の話だけど、世界の広さが新鮮でツイッターなどを読み漁った。

オリキャラ界隈、嫁をフルスクラッチビルドしてんのね。光源氏の比じゃないね

二次創作だと嫁を共有しているから嫁話コミュニティも盛り上がるけど、オリキャラ勢は壁打ちも多い。

なんだか妙にストイックに感じた。描いているのはエロ絵なのにな。(しかしめちゃくちゃ上手い)

 

ある男性同人作家ツイートに、「生きた人間欲情するとか正気か。人権侵害にも程があるだろ」といったものがあって、

そういやはてブ見ててもそういう考え方って見かけたなと思って、でも改めて目から鱗だった。

私にとって、学生時代なんかは特に、生身の異性と付き合うのって「推奨される行為」だったんですよ。

そうではないクラスタがあるっていうのは、非常にいいことだと思う。価値観は多様だった方がいい。逃げ場になるから

 

もらったトラバに「自分の中で好き勝手理想化できるフィクションキャラクターを好き勝手してしまっている背徳感」

というのがあって、それな、ほんとそれな!と思った。

それも一般男性が読むような作品ノンケキャラクターゲイの受けになっているような作品萌えたりするから

「このキャラ普通に好きな人からすると腹が立つだろうな」とも思うんだよ。

そして「そんなにホモが好きなら最初から一次創作商業BLに行けや!」となる気持ちもわかる。

でも、二次創作が無かったら私は私の欲望を発見出来てなかった。

18禁作品なんて手に取ることも無かったし、一般向けの、男女共に楽しめる作品に、そのキャラが居たか出会えたんだよ。

そのキャラ名でツイッター検索するだけで二次創作が溢れていたから、この世界を知れたんだよ。

公開アカウントエロツイート問題とか、住み分け問題とか、色々荒れる話題らしい。

でも私にとっては良かった。私にとっては。それしか言えないな…。

2015-03-09

http://anond.hatelabo.jp/20150309140548

そんなインサイダー情報じゃなくても

はてな社員が上げてる勉強会資料から察するに相当レガシーシステムだろうしそりゃ辞めたいだろ

 

はてブレガシーっぽいけどこっちはフルスクラッチ予定って言ってるし。

 

Perl人類には早すぎた感ある。

2014-12-04

人類の終わりの可能性」の人類範囲

2014-11-10

http://anond.hatelabo.jp/20141109223835

今30代中盤で社内SEとして事業会社に勤務しており、転職は考えてませんが、

Web系の企業ネイティブアプリの開発をやるか、元請けSIerで業務系SEをやるか、迷ってみました。

迷っている理由はこうです。


Web

プロダクトマネージャーとして面白いB2Cサービスを開発できるという点は魅力的です。

自分の才覚次第で大金を手にすることが可能な点も魅かれるものがあります

ただし、40代、50代になって体力や成長速度が落ちたときに、エンジニアを続けられるか、という不安が拭えません。

一生、最新技術学習アウトプットを続けていく覚悟必要ですが、正直言って

10年後も続けられる自信はありません。

市場の変化が激しく、数年後に会社の業績が悪化し、職を失うリスクもあります


ユーザ企業SE

一方のユーザ企業社内SE場合は、手堅い選択になります

自社の深い業務知識を身につけて、社内コンサルを目指すことになります

ゼロベースシステムの構想を練ることが出来るのは最高にエキサイティングで、

社内SEしか出来ない特権ですが、社内の調整仕事は面倒ですし、

自分でモノを作るというエンジニアの喜びや誇りが失われます


・業務系SE

20代の頃はSIerで働いていたので、モノつくりへのこだわりや誇りがあり、

ベンダーが質の低いコードシステムを作ると、自分で作り直したくなります

また、30代になってくると、元請けSIer給料の良さを感じます

ただし、今あるフルスクラッチorアドオン必須SIer世界は確実に崩壊し、

クラウドの向こう側にある半製品を業務にどうフィットさせるか、という

コンサル的なニーズがより一層強くなっていくと思います

正直、モノつくり出来ないなら社内SEやってた方が楽しいだろうなと思います


エンジニアのみなさんは将来のキャリアや、企業の選択をどのように考えていますか?

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん