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

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

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やってた方が楽しいだろうなと思います


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

2014-04-27

よくある話?

売り上げ3億程度のweb系の会社で働いています

たぶんよくある話なんでしょうけど、気持ちの整理のためここに書きます


入社前はプロダクトの開発を行うと聞いていましたが、実際は全案件フルスクラッチ開発。

お客さんはプロダクトがあるという前提条件に立っているため、実態納期の短い受託開発です。

開発体制は1案件(1000万~2000万ほど)1人のプログラマーで、ドキュメントテストほとんどありません。

ひどい案件ではそのシステムが何をしているかからない、サーバの台数も分からない、CVSも使用されずサーバごとにコード差分があるものさえ。


みんな自分案件で手一杯で、隣の人が何をしているのかも知りません。

技術側で仕事量の調整はできず、トップダウン案件が個人あてに振ってきます

社内の雰囲気刑務所のようで、退職した社員言葉を借りるなら北朝鮮みたいな会社だそうです。


エンジニアは社内で育てればいいという社長方針で未経験の子採用しますが、2年以内に4人中4人が退職、そのうち2人は精神科行きです。

経験1,2年のプログラマ要件定義から開発までプロジェクトのすべてを任せてつぶしてしまパターンです。


エンジニア入社しても平均すると2年程度で辞めていきます退職の発表は当日です。

なぜか事前に社員に知らせることがタブーのようになっています


そんなわけで社内には大量の技術負債まみれのプロジェクト蔓延して、保守運用が開発と技術研究時間を食いつぶしています

ツケはエンジニア個人に集中して退職技術的な蓄積が溜まらない、トラブルが減らない、人が辞めるの悪循環です。


上長にこのままでは売り上げ3億程度から伸ばせない、複数人でプロジェクトを行うようにして個人の過負荷を減らし人を定着させるべきだと相談しましたが、

自分は今ある案件を裁くので手いっぱいで何の権限もないと言われました。

その上長も一時期精神科にかかるほど心身を壊して、現在も社で一番多くの業務をこなしているので何も言えませんでした。


社長にも同じ内容を相談しましたが、組織の問題としては受け取ってもらえず個人の問題として切り捨てら取り合ってもらえませんでした。


数年前からこんな光景が続いて、まったく前に進んでいないんです。

どうやったら前に進めるんだろう。

2014-04-08

http://anond.hatelabo.jp/20140408120724

一般的かどうかは知らんが、

1度横でたまごやきを作ってお手本を見せてから

まぁ、やってみろよ。パソコンはコレ。

が今どきなんじゃないか?

 

お手本も見せずに、1度も料理したことがないやつに、たまごやき作ってみろ。手順を書き出せ。

は下手すりゃ泣くぞ。

模倣から入らず最初からフルスクラッチって超人じゃないんだから

 

普通はお手本を見せて、1回めは成功させて成功体験を与えて、自分は出来るんだ!という自信を持たせてから

じゃぁ オリジナル玉子焼きに挑戦してね。っていうのが普通だ。

だが最近は、最初から失敗させてへし折るか、 ずっと成功体験しかさせなくて冒険させないか、両極端すぎるんだよ。

 

まずはとにかく、成功体験を与えて、だめならいつでも、ここに戻ってくればいいという安全地帯を確保して。

それからオリジナル玉子焼きに挑戦して まずい料理をたくさん作りながら、上手くなっていく。というのが理想的

1度目にいきなり失敗させて、失敗することが重要とか、 うちの何とかちゃんに失敗はさせられないとか、バランスが悪すぎる

 

それこそ、増田が言ってることが手順を踏んでないよ。

成功体験とか、自信とか心のケアがない時点で、増田の言ってることも十分できるやつ専用だよ。

2014-03-08

オタ創作序列

 

絵≧音楽>立体>>>>>>>小説批評ROM

 

音楽には二次創作および歌ってみた、弾いてみたの類は含まれない。

・立体は、素材やジャンルを問わずフルスクラッチ製作での評価。

・オタの世界ではとにかく絵師が偉い。絵師という呼び方は実は似合ってる。

創作偉い!な価値観ROM差別をするのは決まって絵師

・多くの絵師アマチュア小説創作として認めていないので、pixiv小説書きは絵師との交流には慎重になるべし。

2013-09-10

http://anond.hatelabo.jp/20130910230903

IT仕事にもな、いろいろあって。

研究開発からフルスクラッチ既存資産の修正、他社のライブラリを使ってのサービス部分の開発、過去資産メンテナンス

とある

一般的に、普通エンジニアができるのは、

既存資産の修正

他社のライブラリを使ってのサービス部分の開発

の2つ。この辺なら、安全というか、出来るように成ってもらわないと困る。というレベル

実際に、開発経験が浅い人間にも扱えるように、ライブラリフレームワークを作るんだから、使えて当然というか、そういう風に作られてる。

 

他方、大規模フルスクラッチとか研究開発は適正があるやつにしか無理。この2つを経験が浅いヤツにやらせるとデスマーチ化して大赤字になる。

何事も適材適所なんだよ。

結局なWeb開発も簡単なところをやっているうちは楽しいんだよ。

 

最低なのは、他人が書いた、そもそも基礎設計から狂っているようなプロジェクトデスマーチ化していて

それを火消するとかだ。社命だからやるけど、やっても利益にならないし。出世するわけでもない。スキルが上がるわけでもない。

デスマーチの火消しは、投入されるエース立場からすれば、敗戦処理から、最低の仕事だよ。見返りも何もない。

何度か、火消しをしてきたけど、人生を潰される感覚だよ。

 

ほんと、基礎設計出来ない奴に、フルスクラッチやらせるな。愚痴ぐらい言わせてくれ。

設計舐めてんのか?っていうレベルの奴にまで大手設計仕事出していて、頭がいたいのもあった。

大手の人を見る目がなさすぎる。

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