  |
はてなキーワード: フルスクラッチとは
元々コンサル会社から事業会社のほうでデータサイエンティストをやるようになって１年経つが辞める。そのきつかったことを匿名という場所で卑怯ながらも話したいと思う。
元々私は大学院でそこそこ統計をやってきてから、コンサル会社に行きデータサイエンティストとして事業会社へ移った口だ。
根本的にデータサイエンティストとしての資質としてざっくりいうと以下の３つが必要だと思われる。
2. KPI設計及び事業からのKPIへの落とし込みからそのKPIからどう事業繋がるかというビジネス設計能力
私能力的には１がやや強く、その次に２がまぁまぁそして３はまだまだといった所で事業会社でデータサイエンティストとして孤軍奮闘をすることになった。
データはあるが、なかなか活用できていないこともあり、分析から企画から関われるという事で入社しようと思った。
後そこそこ大きな会社で働くのも良い経験と思い入社を決意した。ニッチな分野ではあるが、この分野ではTopカンパニーである。
最初の４日ぐらいは会社の研修とかで潰れるのは仕方ないもので、それが終わり早速の業務を行う事になった。
貰えない。
許可申請の関係で３週間程かかってからまず最初にデータを頂けるようになった。この時点でやる気を削がれた。
更にデータの確認という事で事業へのヒアリングを進めるだけで・・・６週間程かかった。更にやる気を削がれた。
この辺りで気付いた事だが、コンサル会社でいたときは、データの確認がスピィーディーだったのに何故こんな遅い作業なったかというと
日本の企業は部署跨ぐというのはとても大変で、コンサルとしてやっていたときは単価も高いし、期間内でやらないといけないという事で
いろいろと調整がスムーズに進んでいたという事がこの時に分かった。コンサルとして外から見ているとやはり分からない事は多い物である。
データの確認も終わり、分析をし、改善を行うテーマを決めて進める事になった。この時点で２カ月ぐらい過ぎていた気がする。R/Pythonの自分のパソコンへの許可申請を出すが、降りない・・・。会社的にはCならばOKだと言われる。でもCの追加ライブラリーの関係はダメらしく・・・悩んだ結果エクセルを基に分析をする事になった。現状把握のために基礎集計をするが、エクセルでSQLで言うGroup_byやら違うデータ同士をくっつけるためのJoinを32 bit エクセルで関数ベースでやると何度も落ちる・・・。この時点でやる気は地の底へと落ちていた。
この辺りでCベースでもう書き直そうかと悩むが、流石にCのライブラリーがない所でフルスクラッチ調に書くのは工数的にかかると考えたのでvbaを用いていた。
エクセルベースでの可視化から上司や関係者にデータの分析の結果を見せていく。この辺りでデータ分析から改善策はまとまっていた。しかしこの辺りでやる気をマイナスにして頂ける言葉を伺う。
私がVBAを書いているのをちらっと見て
「プログラミング何かやっていても仕方ないし、プログラマーではねぇ・・・。今後会社ではプログラマーなんていらないから企画できるようにならないと」
勿論これは直属の上司からのお言葉ではないが・・・正確には同期であるが・・・もはや殺意すら覚える。因みにこの人の既存サービスの改良プロジェクトが回った時のデータを収集したら分析する事になっていたが、プロジェクトのスケジュール感を見ると
開発 4カ月
運用以降
みたいな形でうん？何か少なくないか？と思ったら既存のサービスに関してのギャップ分析無しに既存サービスの改良を進めているらしい
・・・その上取れるデータは〇〇〇で〇〇〇は無いらしい。あっそんなん改善出来んやん・・・。一応私はアリバイ工作のためにメールや会議にて発言する
が・・・空気を読めないと言われ会議呼ばれなくなってしまう（因みにこのプロジェクトは要件定義から運用以降まで外注である）。
私のコンサル的な能力がなかったと言えば確かにその通りである。でもいやうん日本の企業の中で、分析をやっていくのは本当に難しいというのがよくわかる。
一人だったというのもある・・・でも殆ど基礎集計レベルで難しい用語を使わずに改善を行おうとしたいやでもこの日本の企業では無理だった。そしてやりたいと思わなかった。
きららファンタジアというスマホゲーで何か大きな問題が起こって大騒ぎになっているというのは 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業と、世間のいわゆるエンジニア業というのは、かけ離れた職業であって、それぞれやりたい方をやればいいと思う。
ただ、私にはミスの許されない超絶大規模プロジェクトに精神をヒリヒリさせながら、数百人月のプロジェクトマネジメントを楽しむなんてことは全く出来ないので、どこか遠くに消え去りたいと日々思っている。
自分も前に富士通に居て既に退職してます。後で詳しく書くけど、ソフトウェア開発職に居たです。
彼のへの感想。
富士通はクソでっかい会社なんだし、サイト見ればメインフレームやってるのだって判るんだから、開発職を希望したらメインフレーム関連の開発やる可能性あるのは当然予見出来るだろうし、それを想像してなかったのなら情弱とかブコメで言われてしまうよね。あと何も記述が無いから想像だけど、「それほど有能ではない」と判断された可能性もある。と言っても学生が思う「開発者として有能かどうか」ってのと会社でのそれってのは別物で、要するに学生自身が自分が実績もあって優秀だと思っても、会社的にはそうでないのよね。そうなると（後述の富士通に入社して10年が経った人の話にもあるのだけど）新人の能力の客観的な判断材料って大学と資格（応用情報レベル以上）程度なのよね。資格に関しても基本情報なんてMARCHクラス以上の人間なら受けたら取れて当然だから、「有能かどうか」の判断材料にならない。就活の際に本気でIT業界に入りたいかどうかの判断材料にはなる程度。自分の同世代で富士通本体に入ってソフトウェア開発関連に配属された人のプロフィールを見たけど、確か偏差値的には少なくとも神戸大学とか千葉大学あたりの修士卒しか居なかった覚えがある。あと確か2～3人がソフ開持ってた気がする。だから、この増田がどの程度だったのかなと。
ただ、20万人月案件が具体的に何かは判らないのだけど、自分の在籍していた当時でも炎上巨大案件というのはあって、（自分が知ってるのは確かデジタルテレビがどうのこうのとか言ってた）、そういうのに入社して間もなく入ってしまうと自身の勉強等が出来なかったり潰されたり最悪死んだりするんで、そういう意味でも逃げるのは正解の一つ。（自分は炎上案件に放り込まれた新人が寮で死んでたとか話を聞いたことある）
はあ、としか。この人がこう判断した際の判断材料にするであろう自己の体験を具体的に書いてないので、意識高い系がフカしてるようにしか見えない。あと、たった3年しか居なくてあの巨大企業の経営とか体制とか理解出来るんかね？と思わないでもない。自分とは部署が違うだろうから当然かもしれないけど、自分の体験とは違うなーって感じ。自分は、外から見たら馬鹿みたいな事やってるように見えるかもしれないけど、経緯や目的や巨大企業特有の問題があってそうなってるんだなって思う事が多々あった。
近い時期に入社したと思われる。具体的な話が自分の経験と一致してる。特に、富士通のソフトウェア開発と言えばミドルウェアの開発が主だというのは、富士通内部じゃないとなかなか（特に学生なんかじゃ）判らないかなと。
それでこれらの話を見てどんな人が富士通（というか大企業）に向くのかなと考えたんだけど、「やりたいこと」そこまで明確じゃないけどコンピュータは嫌いじゃないって感じで、地頭がまあまあ良くて勉強に関しても要領よくやれる（要するにそこそこの大学に行って卒業した人）、それでそこそこ安定した職・収入目当てな人かなと。ってコレ書いててふわふわしてる人みたいであんまり良い印象の人物像じゃないな。マッチングミスはどうしても起きると思うし、学生の頃に思う「やりたい事」って往々にして変わったり間違いだったりするし、そもそも学生の頃に明確な「やりたい事」がある人の方が少数派でしょ。だからこういうそこそこ優秀だけどふわふわしてる人の方が良いんじゃないかなとか。逆に、ちゃんと「やりたい事」が明確にあるけどまあ安定はしたいって人はどうしたらいいのかって言うと、自分みたく大企業の子会社を狙うと良いんじゃないかなと。子会社ならその会社がやってる事が理解しやすいし、入った後の配属の希望も大きく違ったものにはなりにくいし。まあ子会社は子会社で色々アルかもしれないけど。
入社は10年ぐらい前。入ったのは富士通の子会社で主にミドルウェアの開発をやっている所でした。入社して1～2年したら子会社の統廃合とのことで富士通本体と連携してる部署（自分がそうだった）は富士通本体になりますとのことで富士通本体の方に移ったという経緯ですね。別に待遇とか元々本体と同じだったから変わらず、事務関連が小回りきかなくなったぐらい。入社してから退職までは5年ぐらいでした。辞めた理由は実家の事業を継ぐ事にしたため。
入社して数ヶ月の時にある温泉地にある某所でその手の開発をやってる子会社沢山と
富士通本体のソフト開発配属の人達で研修をやったのだけど、その際に富士通本体の人達と知り合った。（この際に全員のプロフィール冊子が配られた）そのときは流石子会社に入る人達と本体とじゃレベルが違うな～と思いましたね。（ちなみに自分はMARCHより下の院卒。）
自分が配属されたのは某製品部署のAPI部分チーム。その製品がC言語やJava言語からも使えるように出入り口を用意する部分。中でやってる事は指定されたIPのポートにプロトコルに沿ってデータ投げるだけなんだけどね。ちなみに配属希望の際は「そこそこの忙しさの所がイイ」と言っていました。「バリバリに働きたい」と言ってた同期は多忙でヤバい所に配属されてました。他にもチームがいくつかあったけど、それらのうちの一つは例の「山奥の工場」でしたね。自分が配属された当時はC言語のAPIをリニューアルするって開発してたのだけど、設計担当がJavaしかやったことない人で色々とC言語の流儀に反してて後々のメンテが大変でした。まあそれでもリニューアル前よりは遙かに良くて、以前はユーザに見せてる関数名が ○○search1 ○○search2 ○○search3 とかでしたね（ちなみに機能はそれサーチか？思うのもあった）。もっと酷かったのが初期製品のJavaの公開メソッドで、マニュアルには「このメソッドの引数○○を□□を指定した場合は戻り値のObjectを△△にキャストしてください。××を指定場合は…」という「これ製品にして売ってたんだ…」と思うレベル。もちろんコレがダメだったってのは開発側も認識していて当時は既にリニューアル済みだったけど。リニューアル済みでも少し微妙だったけどね。
これは、ミドルウェアの開発をやってる人達って基本的にC言語が主でJavaとかをやってる人がほぼ居なかったからだと思う。上司もそういうのは良くないってのは認識してた。対象OSはWindowsとLinuxとSolarisだったけど、そんなにたいした事やってなかったからほぼ同じコードだったような。ソケットの一部だけ違ってたっけかな。
それでそのバージョンの開発が終わったあたりで、.NET Frameworkが出始めてきたので次バージョンでは.NET FrameworkのAPIを作る事になりまして、自分が少し勉強していたのでそれの設計から担当する事に。当時は.NET Framework 1.1で今思えば少し時期が早かったと思う。2.0でGenericが出てからやった方が良かったと思うんだけど、そういうの政治的判断だし結果論だしなー。それまでにRubyとかオブジェクト指向言語に触れてその辺の勉強もしていたので、.NET用のAPIに関しては設計も実装も結構良い感じに出来たと思う。ああ、そういえばRuby用のAPIも効率化の開発ツールとかの名目で仕事中に勝手に作ってたなあ。他にもC言語のAPIも内部実装がクソすぎ！とキレてユーザ公開関数インターフェースだけ同じで中身をフルスクラッチした事も。もちろん絶対にLDしてるんで完全に趣味なんだけどな。これでAPIはC言語とJavaと.NETになった訳だけど、現場の案件で使われたのってほぼ全てJavaだったと思う。（開発中のサーバのテスト用アプリはC言語だけど）。要するに自分が数年関わったコードが世の中ではほぼ使われてない訳でして、取りそろえとして必要だったとはいえ世の中の役に立ってないってのは嬉しくは無かったですね。まあ、大企業の仕事なんてそういうもんです。.NETに関してはそのバージョンが出る頃はその製品があまり売れてなかったんだか使われたって話は聞かなかったですね。ほほほ。大企業に勤めるのならこういう覚悟は必要かもね。
で、.NETのAPIが出来たあたりに開発ネタがなくなって保守気味になってきたので、人員整理と作業整理との事でインストーラと切りたいけど一度やったからには切れない補助製品の担当が増える事に。インストーラはWindowsがInstallShieldというクソみたいな言語上で作られたもの。LinuxとSolarisがシェルスクリプトでのもので、InsallShieldの方のコードはあまりにクソなのでリファクタリングさせてもらった。この辺の開発は少なかったのだけど新OS対応(Vistaとか）とか保守作業が大変だった覚えある。
んで、これらの作業が終わったあたりでこの製品でやることが無くなってきたのと同時に、この製品の派生製品の話が出てきてて、それは1機能1exeで提供されてて、それらを纏めるバッチ処理機能部分を担当することに。バッチ処理の内容・順番を記述するのにXMLを使う事になったのでXMLのパーサが必要なのだけど、色々調べたら富士通内部でパーサ作ってたのでそれをもらって使う事に。そのパーサはC++からじゃないと使えなかったのだけど、趣味でC++で勉強してたので何とかなった。あと、結構OSの知識（プロセスとか）が必要でWindowsとLinuxとSolarisで動くコードを書く必要があってまあまあ大変でした（と言ってもifdefで切り分けるだけなんだけど）。けど、これらの開発は自分が一から設計してコードを書いていたので楽しかったですね。それでこれが完成するかしないかあたりで、このバッチ処理機能が他の開発中の製品のバッチ処理に使えないかとか話が出てきたあたりで自分が退職する事に。（退職の話は1年ぐらい前に話し合って決定済み）引き継ぎをして退職ということになりました。最後は溜まった有給を使う予定でまだ在籍中だけど部屋を引き払って実家に帰ってたのだけど、打ち合わせに来て欲しいって言われてしまい実家から何日か通ったのは良い想い出。というかまさか実家から朝8時に間に合うとは思って無かった。
振り返ってみて残業時間は月40～60時間が多かったかな。100時間超えた時は上司に怒られた。あと退職前の1年ぐらいはうちの事業本部（だったかな？）単位で残業禁止になってホントに残業0時間になった時期があった。他の部署の人の話で、どう考えても狂ってる上司の話とかを聞いてると上司とかの運は良かったと思う。あと、やっぱり仕事でみっちりプログラミングが出来たのは運が良かったと思う。富士通のソフト開発で C C++ C# Java シェルスクリプト InstallShieldとか（そんなに深くはないけど）色々やれた人間はそうそう居ないんじゃないかな。同期とかの仕事は年上の人の派遣の人に指示出したり取り仕切ったりする仕事とか、保守サポートみたいな開発じゃない仕事の話も良く聞いていたので、ソフト開発のキモを体験出来たのは良かったです（こなみ）。
増田に感情的な記事を書いて約一ヶ月が経ったけど、だいぶ落ち着いた。
http://anond.hatelabo.jp/20150608210855
「二次元に欲情した程度で傷つくとは、自分をどれだけ高尚な存在だと思ってたんだ」系のコメントをもらって、
まあ、そうだよなと思った。別に人々の手本になるべき立場でもないし、迷惑をかけない限り好きに生きればいいのだよな。
もう好きなキャラクターのpixiv作品は見尽くしてしまったので、好きな同人作家さんの他の作品も見るようになった。
弱虫ペダルや刀剣乱舞などの人気ジャンルでも創作していることがあって、原作を知らなくても楽しめた。
腐女子の世界では「ジャンル友達より、性癖友達の方が長持ちする」と言われているらしい。
わかるかもしれないと思った。だって趣味が同じ人の作品なら、原作を知らなくても良かったわけだから。
あと、長らく腐女子が少年マンガばかり好むことを謎に思ってたけど、それも解決した気がする。
少女マンガだと、このキャラとこのキャラはこういう恋愛をしますよ、と作者に決定されてしまう。
言い方が変かもしれないけど、同人作家は創作プラットフォームとして世界観とキャラクターを用意して欲しいんだね。
そして恋愛・セックスなどの要素はサードパーティーである私たちに投げてくれという感じ。
これ、刀剣乱舞でめちゃくちゃ顕著じゃないですか？狙ってやってませんか？
好きな作家が一次創作もやっていたことで、オリキャラ界隈も覗くことになった。
ここまで来ると男性の作家が多くなってくる。人外・ケモショタなど、現実で叶えられそうもない嗜好の数々。
それに萌えるかというと別の話だけど、世界の広さが新鮮でツイッターなどを読み漁った。
オリキャラ界隈、嫁をフルスクラッチビルドしてんのね。光源氏の比じゃないね。
二次創作だと嫁を共有しているから嫁話コミュニティも盛り上がるけど、オリキャラ勢は壁打ちも多い。
なんだか妙にストイックに感じた。描いているのはエロ絵なのにな。（しかしめちゃくちゃ上手い）
ある男性同人作家のツイートに、「生きた人間に欲情するとか正気か。人権侵害にも程があるだろ」といったものがあって、
そういやはてブ見ててもそういう考え方って見かけたなと思って、でも改めて目から鱗だった。
私にとって、学生時代なんかは特に、生身の異性と付き合うのって「推奨される行為」だったんですよ。
そうではないクラスタがあるっていうのは、非常にいいことだと思う。価値観は多様だった方がいい。逃げ場になるから。
もらったトラバに「自分の中で好き勝手に理想化できるフィクションのキャラクターを好き勝手してしまっている背徳感」
というのがあって、それな、ほんとそれな！と思った。
それも一般男性が読むような作品のノンケのキャラクターがゲイの受けになっているような作品に萌えたりするから、
「このキャラを普通に好きな人からすると腹が立つだろうな」とも思うんだよ。
そして「そんなにホモが好きなら最初から一次創作の商業BLに行けや！」となる気持ちもわかる。
でも、二次創作が無かったら私は私の欲望を発見出来てなかった。
18禁作品なんて手に取ることも無かったし、一般向けの、男女共に楽しめる作品に、そのキャラが居たから出会えたんだよ。
そのキャラ名でツイッター検索するだけで二次創作が溢れていたから、この世界を知れたんだよ。
公開アカウントでエロツイート問題とか、住み分け問題とか、色々荒れる話題らしい。
でも私にとっては良かった。私にとっては。それしか言えないな…。
今30代中盤で社内SEとして事業会社に勤務しており、転職は考えてませんが、
Web系の企業でネイティブアプリの開発をやるか、元請けSIerで業務系SEをやるか、迷ってみました。
迷っている理由はこうです。
・Web系
プロダクトマネージャーとして面白いB2Cサービスを開発できるという点は魅力的です。
自分の才覚次第で大金を手にすることが可能な点も魅かれるものがあります。
ただし、40代、50代になって体力や成長速度が落ちたときに、エンジニアを続けられるか、という不安が拭えません。
一生、最新技術の学習とアウトプットを続けていく覚悟が必要ですが、正直言って
10年後も続けられる自信はありません。
市場の変化が激しく、数年後に会社の業績が悪化し、職を失うリスクもあります。
自社の深い業務知識を身につけて、社内コンサルを目指すことになります。
ゼロベースでシステムの構想を練ることが出来るのは最高にエキサイティングで、
社内SEにしか出来ない特権ですが、社内の調整仕事は面倒ですし、
・業務系SE
20代の頃はSIerで働いていたので、モノつくりへのこだわりや誇りがあり、
ベンダーが質の低いコードでシステムを作ると、自分で作り直したくなります。
また、30代になってくると、元請けSIerの給料の良さを感じます。
ただし、今あるフルスクラッチorアドオン必須のSIerの世界は確実に崩壊し、
クラウドの向こう側にある半製品を業務にどうフィットさせるか、という
正直、モノつくり出来ないなら社内SEやってた方が楽しいだろうなと思います。
たぶんよくある話なんでしょうけど、気持ちの整理のためここに書きます。
入社前はプロダクトの開発を行うと聞いていましたが、実際は全案件フルスクラッチ開発。
お客さんはプロダクトがあるという前提条件に立っているため、実態は納期の短い受託開発です。
開発体制は1案件（1000万～2000万ほど）1人のプログラマーで、ドキュメントもテストもほとんどありません。
ひどい案件ではそのシステムが何をしているか分からない、サーバの台数も分からない、CVSも使用されずサーバごとにコードの差分があるものさえ。
みんな自分の案件で手一杯で、隣の人が何をしているのかも知りません。
技術側で仕事量の調整はできず、トップダウンで案件が個人あてに振ってきます。
社内の雰囲気は刑務所のようで、退職した社員の言葉を借りるなら北朝鮮みたいな会社だそうです。
エンジニアは社内で育てればいいという社長の方針で未経験の子を採用しますが、２年以内に４人中４人が退職、そのうち２人は精神科行きです。
経験1,2年のプログラマに要件定義から開発までプロジェクトのすべてを任せてつぶしてしまうパターンです。
エンジニアは入社しても平均すると２年程度で辞めていきます、退職の発表は当日です。
なぜか事前に社員に知らせることがタブーのようになっています。
そんなわけで社内には大量の技術的負債まみれのプロジェクトが蔓延して、保守運用が開発と技術研究の時間を食いつぶしています。
ツケはエンジニア個人に集中して退職、技術的な蓄積が溜まらない、トラブルが減らない、人が辞めるの悪循環です。
上長にこのままでは売り上げ３億程度から伸ばせない、複数人でプロジェクトを行うようにして個人の過負荷を減らし人を定着させるべきだと相談しましたが、
自分は今ある案件を裁くので手いっぱいで何の権限もないと言われました。
その上長も一時期精神科にかかるほど心身を壊して、現在も社で一番多くの業務をこなしているので何も言えませんでした。
社長にも同じ内容を相談しましたが、組織の問題としては受け取ってもらえず個人の問題として切り捨てら取り合ってもらえませんでした。
数年前からこんな光景が続いて、まったく前に進んでいないんです。
どうやったら前に進めるんだろう。
一般的かどうかは知らんが、
まぁ、やってみろよ。パソコンはコレ。
が今どきなんじゃないか？
お手本も見せずに、１度も料理したことがないやつに、たまごやき作ってみろ。手順を書き出せ。
は下手すりゃ泣くぞ。
模倣から入らず最初からフルスクラッチって超人じゃないんだから。
普通はお手本を見せて、１回めは成功させて成功体験を与えて、自分は出来るんだ！という自信を持たせてから。
じゃぁ オリジナル玉子焼きに挑戦してね。っていうのが普通だ。
だが最近は、最初から失敗させてへし折るか、 ずっと成功体験しかさせなくて冒険させないか、両極端すぎるんだよ。
まずはとにかく、成功体験を与えて、だめならいつでも、ここに戻ってくればいいという安全地帯を確保して。
それから、オリジナル玉子焼きに挑戦して まずい料理をたくさん作りながら、上手くなっていく。というのが理想的。
１度目にいきなり失敗させて、失敗することが重要とか、 うちの何とかちゃんに失敗はさせられないとか、バランスが悪すぎる
それこそ、増田が言ってることが手順を踏んでないよ。
