「SQL」を含む日記 RSS

はてなキーワード: SQLとは

2017-05-12

製造業新卒で入って数年経過したけどもうダメかもしれない

新卒製造業に入った。

大学では工学部ではない理系だったので右も左も分からないなりにがんばってみようと思っていた。

悪く言えば自分能力絶望して夢を諦めることになり都落ちした気分での就職だったのでやぶれかぶれだったというほうが近いかもしれない。

相性というか、背景の差とか常識の差みたいなものがあって、自分から見ると無駄の多い職場だなあと感じて研修期間が終わり本配属された。

無駄が多いという感想は本配属後も変わらなかった。

本来業務はいわゆる故障解析で、歩留まりを上げていくのが使命だった。

せっかくだから色んな所に首を突っ込み改善できそうなところは提案をしたり、自動化したり、それらのドキュメンテーションを書いてみたりした。

プログラミング経験は皆無だったが、理論系卒が工学部に負けられんという謎のプライドVBAから、Rやら自社製品の解析用環境の割と珍しいタイプスクリプト言語など(特定されそうだからぼかすけど。)

とりあえず手が出せそうなものは何でも調べてみてありものを改造してみたり勝手作ってみたりして提案していた。

物怖じしない新人がぎゃーぎゃー騒いでいるぐらいのものだったと思うが、何にせよいくつかの改善が上手く実務にハマって成果として認められたりしだしたのが1年目。

この辺で気付いたことだが、製造業ITリテラシーは驚くほど低い。製造業一般化するのはフェアじゃないかもしれないから厳密に言えば弊社の、という意味だが。

なんせまともにプログラムを書いたことが無い新人半年で身に着けた程度のスキルで書いたプログラムで、1日かかってた仕事が1時間で終わったりするのだ。

ようするにMS officeの達人みたいなのがいっぱいいて、Ctrl+CとCtrl+Vが機能のすべてだと思っているということだ。

(そして彼らの口癖は「忙しい」だ、会議中も左手はCtrl+CとCtrl+Vを叩き続けている。)

2年目に気付いたのは、弊社エンジニアITリテラシーが低くとどまっている要員のひとつに、実はITインフラチームがことのほかマトモだということがある、ということだ。

製造中のセンサーデータやらテストデータやらETL的にはおそらくえげつない部分で、かなり優秀な人間が居て上手くぶん回し切っている様子だった。

無骨だが使いやすイントラ上のwebページが用意されて、グロテスクな部分を気にせずクリックだけで上述のデータを整ったものとして引っ張ることができた。

から逆に言えば下々の人間コピペでなんとか恰好を整えられるのだった。

彼らはモダンな発想があって、あるいはお偉いさんが「ビッグデータ」とか言い出したのかもしれないが、ともかく、HadoopやらAWSやらそういったものを導入しようと試みているらしかった。

私はそれに感動した。なんせWebスクレイピングみたいな方法他人が社内プラットフォーム社内WIKIに上げた報告をまとめたり、製造データと紐づけたり、それからグラフ描いたりみたいな業務が増えていたからだ。

それっぽく表現すればデータ分析屋さんということになるのだろうが、どぶをさらっているという表現のほうが近かったかもしれない。

何にせよそういったもの一気通貫自動化できるポテンシャルがあると感じられた。

SQLjavaも書いたことなんて無かったが、1年前やっていたことを考えれば同じことだ。何にせよ歓迎だった。しか管理IT持ちだ。餅は餅屋に頼むべきだ。それもできれば美味い餅屋に。

ところがその「ビッグデータプロジェクト人手不足か、資金不足か、あるいは生みの苦しみか、ことのほか時間がかかっていた。(あとで聞いた話、外部コンサルで外れを引いたらしい)

自分ドメイン知識からの助言とか想定される使い方についての意見を伝えていったし(有難迷惑だった可能性は否定できないが)、もう少し待てばモノになると信じていたし、実際そうなった。

具体的な話ができないのだが、客先で起こった不良の原因をつきとめ、その改善効果確認の為に数十億行のデータ活用された。彼らの力が無ければ常識的時間では終わらなかった仕事だった。

残念だったのは彼らの優秀さの割に一般エンジニアスキルがあまりに低かったということだ。つまりそのプラットフォームを使いこなせる人間が著しく少なかったのだ。

そして上述の足踏みをしていた期間に心象を悪くしていたという問題もあった。とっかかりが難しい割に不安定だというレッテルを張られてしまっていた。

このころ私は入社3年目に突入していたが、

もうすこし悪いことに、同時期に企業買収が起こった。我々は黒字を出していたが同業他社(厳密にはその親会社に)に買われることになった。

そういう時に起ることは不要冗長性の削減だ。子会社として存続する場合は知らないが、競合他社に吸収合併ということは、多くの部署にとってそのカウンターとなる部署相手側にも存在するということだ。

まりどちらにもある部署統合するか一方を無くすかという戦争が始まるのだ。IT例外ではない。(ITインフラ部署の無い会社はさすがに無いはずだ)

一方で製造業の本懐である製品を作り、売る」という部分は比較的守られる。それこそが根源的な資源であり、利益を生む仕組みであり、既存顧客への説明必要からだ。

そして私の仕事は歩留まり改善であり、故障解析であり、データ分析だ。何が起こったか

(ここで簡単のために旧弊社を(旧)A社、買収した側の競合他社を(旧)B社と呼ぶことにする。)

今の旧A社から引き続いている業務をB社のプラットフォームで行えるように転換せよという下命である

旧B社の製造データに対するアプローチはA社とまったく異なっていた。Web UIは美しく整っており、それっぽいグラフ簡単に表示され、A社側のお偉いさんからも好評を得ていた。

だがそのバックエンドは控えめに言って酷いモノだった。いくつもの情報を正常に保存できておらず、「それっぽい何か」を素早く返答することを第一義としているように見えた。

そして上述のように器用貧乏街道を歩んできた私に投げられたのは次の言葉

増田くん、B社のプラットフォーム使うことは決定事項だから、君が自動化してたやつ全部そっちで動くようにしといて。よくわかんないけどプログラムとかてきとうにできるでしょ?」

もちろんhtmljavascriptphpRoRも一行も書いたことが無いのが当時の私である

果たして旧A社のプラットフォームはB社のプラットフォームデータソースのような扱いを受ける羽目になり、私はjavascript本格入門を片手にB社の事業所に出向くことになった。

そこで散々「旧A社のプラットフォームは遅い・使いづらい・不安定」と貶されながらチマチマとグラフを表示するページを書いている。

クオリティの低いバックエンドを作る集団が書いているサーバーサイドphpの酷さは素人目にも分かるレベル筆舌に尽くしがたいものがあるが、

反面教師だと思って耐える日々だ。

最近分かったことは旧B社のバックエンドスクリプトデータを引っ張るついでに意図的に旧A社のプラットフォーム攻撃しているということだ。DDoSとまでは言わないが、悪意100%である

いわく旧A社のプラットフォームを畳むためには旧B社のプラットフォームが優秀であることを示す必要があるとのことである。(つまり旧A社プラットフォーム不安定かつ重くなることを意図しているらしい)

旧A社から継続されてる業務はまだそこ使ってるんですけど・・・

それはもちろん旧A社の上司に報告したが「見て見ぬふりをしろ」とのことだった。旧A社のITで何度もお世話になったひとに伝えると「知ってるけどね・・・」と悲しい目をして苦笑いしていた。

旧A社ITはその優秀さでそれらの攻撃をいなしつつあるようにも見える(私も素人に毛が生えたレベルだが、ソフトウェアエンジニアリングレベルが二回りぐらい違うように見える)

この不毛な戦いはいつ終わるのだろう・・・つらい・・・

そして私はいつまでソフトウェアエンジニアの真似事を続けてキャリアを消費していけばいいのか、もうダメかもしれない。

そもそも私はエンジニアなのだろうか・・・少なくとも職位にはそう書いてあるけど・・・

2017-05-08

勘違いしてる同僚プログラマ

29の時にプログラムを始めて今年で3年目。

最初派遣会社にいたけど4月から転職

今の同僚は専門卒業してから10年以上やってる人。

彼の方がひとつ上だけどまあまあ同い年みたいなかんじ。

最初10年以上やってるんだからできる人なんだろうと思って接してたけど

この1か月一緒に仕事した結果すべてが適当レベルが低いというのがわかった。

でも彼はそうだと思ってないようで何かと上から教えたがる。

入ったばっかだし試用期間だから素直に聞いてるふりをしてる。

それでも適当なことばかり言ってくるからいい加減限界が近づいてる。

リレーション使うとSQLが重くなるからなるべく使わないようになど)

つらいのがレビューとき

彼の適当仕事に対して本当は言いたいんだけど

立場は後輩なわけで実際指摘した方がいいのはわかるけど

それでも先輩の仕事ケチつけるわけにもいかないじゃないですか

からないふりして質問して遠回しに指摘しても全く気付かないし

これはおれのやり方が悪いのは重々承知だがそれでも

彼よりおれの方がまともに仕事してるっていうのは1か月仕事したらわかると思うんだよ。

明日からまた彼と仕事するって思うと憂鬱しょうがない。

さすがに1年やったら彼も理解するからそれまで我慢するしかない。

2017-05-05

http://anond.hatelabo.jp/20170503151008

マジレスします。

MicrosoftExcel親和性の高い、Power BIというビッグデータ分析ツール無料で出しています

https://powerbi.microsoft.com/ja-jp/

あなたは、これかこれに類する分析ツールを使って、自社データ分析ができるようお膳立てをし、できるならいくつかの分析サンプルとともに部長さんに提案すればよかったと思います

この手のツールは、データ分析SQL専門家じゃなくても使えるようになってるので、部長さんも十分使いこなせる可能性がある。

知らないことはできないわけで、できるようにお膳立てするほうが、あなたにとっても部長さんにとっても会社にとっても利益になるのではないかと思います

からでも遅くありませんよ。

2017-05-04

http://anond.hatelabo.jp/20170504171337

あんまり詳しくない事務系の人間が言うんだが、

増田用途だとAccess使っても結局フロントエンドExcel使わんといかんような気がするので、おすすめしない。

といってExcelだと無用に重くなるというのはよくわかる。

ソートに関してはマクロとかで改良できると思うが、重くなる問題はどうしようもなかろう。

ハードウェアアップグレード対応するという姑息手段もあるが、Excelファイル肥大化していくだろうから問題を先送りにするだけという気もする。

きちんとしたデータベースSQL)の知識があれば解決できるのだと思うが、かなり敷居が高い

似たようなことでずい分昔に悩んだことがあるので、思ったことだけ書いた。参考にはならんな。

しかあのときは、中途半端マクロ書いてごまかして、そのあとで会社辞めたんだったわ。

2017-05-03

DBSQL理解できない文系上司

ECサイト運営を任されて4年。これまで蓄積された販売データは50万件以上に上る。

もと営業マン上司部長)がこの販売データに目をつけ、分析したいと言い出した。

どういったデータが欲しいのか要件定義をしてもらえればいくらでもデータ提供するのだが、この上司は「自分分析をしたい」という欲求が非常に強い。

そして具体的な分析イメージが持てていないので、要件定義が全く出来ない。

「色々といじってみないとわからない」の一点張りだ。

それじゃ、って事でECサイト管理者権限を与え、管理ソフト上での閲覧もcsv吐き出しの方法も教えたのに、今度はそれが使いこなせない。

毎日ギャーギャー騒いだあげく、ついには「全部のデータExcelで見れるようにしろ!」と言い出した。

「ビックデータ解析に一番有効ツールExcelです。」だそうだ。

部長の後ろの本棚最近そういう本が並んでいるのは知ってた。知ってたけど関わりたくなかったので無視していた。

それがついに正式業務命令として振ってきてしまった。もう避けることは出来ない。

祝日出勤のイライラMAXだったので、昼休み明けに1.5GBのcsvデータ作って部長PCに放り込んであげた。

部長は大層喜んだ。「やっと分析に着手出来るな!」って他部署に聞こえるくらい大きな声で宣言してた。

で、さっきからファイルを開こうとする毎に画面真っ白になる”っていうのを延々繰り返して「なんだよこれー!!」ってキレててウケる

2017-04-26

SQLってさ、新しい書き方覚えてなんか「おっ!使い方わかったわ!」とか思って

練習問題みたいなのやるじゃん?

わかんないじゃん?

不思議だよなあ

2017-04-24

業務命令でなく業務外に業務させたい

新人SQL業務外で勉強させたいと思っている。

もし、勉強しなかったらちょっと単価の高い別のメンバーにやってもらう方が安上がりなので、業務内で勉強させるつもりは無い。

SQLを使った業務をして貰う予定だから勉強してこい

NGで、

SQLできるメンバーにこの業務やってもらおうと思っているよ。

大丈夫だろうけど、

・もしSQL勉強してきたら、次この業務やってもらうよ。勉強しなくても別のメンバーに頼むから大丈夫だよ。

・もしSQL勉強してきたら、次この業務やってもらうよ。勉強しなくても別のメンバーに頼むから大丈夫だよ。ただ、君の評価に与える影響は大きいよ。

真実だとしてもダメかな~?

どこまでだったら、良いかな?

あとはSQLじゃなくて、英語だったらとか、汎用性のない業務パッケージだったらどうなんだろ。

2017-04-22

http://anond.hatelabo.jp/20170421230333

今、仕事をしてるシステムは、DBテーブルカラム漢字になっていてすごくわかりやすい。

SQLとか、

SELECT 
  商品名, 
  商品略称, 
  仕入値, 
  売価 
FROM 
  商品マスタ 
WHERE 
  仕入日 >= '2017-04-01' 

みたいな感じ。

DBからとってきた値をいれる変数も同じように日本語にしたらめちゃくちゃよくなりそうだけど、残念ながら既存ソースがそうなってないから俺もソースのほうはローマ字で書いてる。

2017-03-15

毎朝ぎりぎり出社の運用エンジニアです

今日会社障害対応

最近やっているプロジェクトはつまらない。

今やっている仕事の50%は運用プロジェクト関係

運用なので実装や開発ということもなく、何かシステム修正があればテスト、というような感じ。

障害も頻発するわけではないがそれでもつらい。

先輩はいい人で色々教えてくれるので、勉強になるからその点はうれしいのだけれど、

やっぱり運用プロジェクトというせいかモチベーションが上がらない。

最近は毎朝起きるのも遅い。

乗る電車もいつもぎりぎり間に合う電車

以前は出勤時間の3〜4時間前に起床して、好きなプログラミングをしたり

本を読んだり、ランニングをしたり自由に過ごしていた。

会社にはみんなよりも1時間早く来ていた。

きっとその頃は仕事が楽しかったのだろう。

会社に入ったばかりでやることはどれも新鮮。

少し難しい仕事も任されるようになってきてモチベーションもあったと思う。

仕事楽しいだけでなく充実感があった。

それが今では不思議と朝起きたくないのだ。

起きるのがつらいというか億劫

別に疲れが溜まっているわけではない。

目覚めは悪いどころかいつも目はぱっちりしている。

でも起きれない。ぎりぎりまで布団の中。

そして時間ぎりぎりになると焦燥感を感じつつのっそり布団から起き上がる。

まり憂鬱なのだ会社に行くのが。

この状況を打破するにはたぶん運用プロジェクトをやめるしかないのだろう。

今ではどうせ朝早く起きれないなら深夜までずっと起きていようか、なんて考えている。

会社をやめていく同僚にも言われたが、運用やってるとだれてくるらしい、私生活が。

そういって同僚はフリーランス転職した。

今では職場でも私生活でもいきいきしている。うらやましい限りだ。

自分フリーランスにはなろうとは思わないけども、少なくとも今のプロジェクト半年が限度かなーとは思ってる。

同じ環境にずっと居ても成長できるか不安だし。

それに自分市場価値はどんどん上げたいと思っているし、会社だけでなく会社の外でも評価される人間になりたい。

そういう意味でも今の運用プロジェクトに長く関わるのは、正しい選択ではないように思う。

運用プロジェクトの残念なところは、仕事の大半が顧客対応コミュニケーションコストでつぶれること。

特にお硬いお客さんだと本番作業をする度に、申請書類を書いて作業日の何日か前に提出しなければならないだとか。

障害対応であれば書類に発生日時や発生事象、発生原因、顧客影響、業務影響、対応策、横展開対応、再発防止策、etc..

なんてことをつらつら書かなければいけなかったり。

なにより障害が発生したらものによっては休日にも出勤しなければならないこと。

まぁ自分はその経験はまだ一度もないけども。ただ障害が起きて帰りが遅くなった時は本当に疲れる。

体力には自身があるけども精神的にはわりときます。人によるのかな?

つらつらと運用プロジェクトについてネガティブな事を書いたけども、悪いことばかりではない。

運用プロジェクトでは顧客対応必須だ。なので顧客との話し合いは上手くなる。

あと、運用エンジニアには広範な知識が求められる。

例えばフレームワーク脆弱性が発表されれば、どの程度影響があるのか、どのような対策を取れば十分か、そもそもどんな対策がとれるのか、とか。

ハードウェアミドルウェア障害が起きればそれに対する知識を駆使して対応を行う必要があるし、

ドメインが変わった、IPアドレスが変わった、となればシステム運用保守作業で影響がないか調査する必要がある。

なのでそのような対応を考える機会があるので勉強にはなる。

他にも必要知識として、プログラミング言語SQLはそこそこかけて、DBクライアントLinux操作、その他ミドルウェア知識必要になる。

なので現時点では自分スキルはそこそこ伸びてはいるのかなーとは感じている。

そんなこんなで運用プロジェクトは色々大変だよってことです。

理想運用プロジェクトで吸収できるものは吸収していって、早めに別プロジェクトに移っていきたいですね。

めんどくさいことが多いけどもつまらなすぎて潰れないようにとりあえずがんばります

明日仕事ですね。みなさん一緒にがんばりましょう。

2017-02-19

SIerの書くSQL

http://uxlayman.hatenablog.com/entry/2017/02/12/low

SQLしかできないマン」の章。これなー。ISAMデータベースなごりじゃないかな。DBの変更を高度に隠蔽化するとかなんとか。

2017-01-07

Qiita3大キチガイ

転職Adventerはまあキチガイキチガイなんだろうけど、最初投稿にキテる感が無かったので、3人の中ではまともか

毛の壁とSQLおじさんはどっちがヤバいのだろう

実はSQLおじさんは早々にNG登録してしまったので、どう燃えたのか知らないのである

2016-12-07

コミュ力0のエンジニア介護し続けてきたツケが回ってきた気がする

11月12月炎上、というより「コミュ力の圧倒的足りなさ」から揉め事騒動を起こしている人たちが軒並み40代だった。

SQLおじさんこと生島勘富は40代クラウドワークスのページより)



ちょまどの例のスライドを作ったおっさんこと山本康彦は1957年まれの59歳。



フリーランスの人こと酒巻裕一は職務経歴書によると40歳



その酒巻裕一を擁護しつつ自身アドベントカレンダー特定人物攻撃記事を上げているRichMikanことシェルショッカーこと松浦智之は1975年まれの41歳。



職人エンジニアみたいな言葉を使ってエンジニアコミュ力求めない風潮を是とする記事を読んだことがあったけど、こんな若気の至りでやるような揉め事をいい年したオッサンたちがやっているのを見ると、コミュ力0のまま一定の年齢を超えたエンジニアは、社会と完全隔離させないと誰かを不幸にするだけの存在になるんじゃないかって気がしてならない。これは社会人全体にも言えるが。

ゲーム現場は平均年齢が30くらいなので、フリーランスで40越えたときには周りがみんな年下で、そこに同対応してゆくかというのはある。というか、対応できずに昔のままの感覚で腫れ物扱いや疎まれていく(もちろん、本人には言われない)というのを最近たくさん見てつらい。

https://twitter.com/obenkyounuma/status/806253887036366849

あとドラえもんの「大人ってかわいそうだね。自分より大きなものがいないもの。よりかかって甘えたり叱ってくれる人がいないんだもの。」っていう台詞を思い出した。もうこんなおっさん達を正しく叱ってくれる人間はいないだろうから、やはりただちに現実からネットから隔離するしかないんじゃないか

2016-11-24

プログラマーの思うこと

プログラマーから製造業社内SE転職した。

VBAわかりますけど(キリッ)みたいな人が作ったマクロを直すのが苦痛すぎる。

なんでもエクセルでやろうとすんな。

マスタのデータエクセルに貼り付けたものをつかってVBA組むな。

変数はご丁寧に一番先頭で宣言祭りコントロール名前が連番、無意味な処理、データ件数を取得するためだけに同じSQLをCOUNTにして実行、無意味ループに、ifの4段ネストメソッド名が不適切(checkXXX)、スコープは全部Public、定数の概念無し(マジックナンバー多すぎ問題)、型変換の概念無し(文字列数字にぶっこむ)、例外処理なし、その他突っ込みどころ多数

オブジェクト指向なにそれおいしいの状態コードがどんどん増えていく。

てめぇのエクセルスキルはよーーーーくわかったから、これ以上クソコード増やさないでくれ

2016-11-14

エンジニア副業を始めるのに勇気が持てない話

新卒5年目エンジニアにはよくある話だが、何人かの大学の同期がフリーランスとしてガツガツ稼いでいるらしい。

それに触発されて、自分も何かエンジニア系の副業ができないかフリーランス求人サイトをみてみた。

なんか出来そうで出来なさそうな案件ばっかりだ。

いや、それなりに調べれば作れそうだが、はじめましての私にできるだろうか。

一応CもRubyRailsPHPSQLサーバサイド系もそれなりに業務趣味経験しているが、募集されている具体的な案件をみるととたんに不安になる。

そう不安なのだ

こういう自分スキルセットだけど、どうやってフリーランス案件を受け始めたか的なエントリがなかなか無い気がする。

平凡なエンジニアだけど、こういう状態から勇気を持って副業始めました的な。

情報に対しても受動的じゃだめなのかな、とりあえず挑戦してみるべきなのか。

2016-11-06

http://anond.hatelabo.jp/20161106094548

LaravelのCRUD程度ができる、CakePHPはやったことないけど同じPHPフレームワークだし覚える気はある。

jqueryアコーディオンとかは何も見ないでも作れるが他はネットで調べつつ。

PostgreSQLをよく使ってたけどMySQLはしたことない。

でもフレームワーク使うならSQL文ほぼ使わないだろうから追々覚えたら行けるだろ

って考えの大阪プログラマーだけど雇ってもらえます

2016-10-02

うおおおおお結婚してええええええ

でも無理だ自分の中にあるロールモデル少女漫画並みで全然現実味がねえええええ

今どきどこを探したら「彼女からバレンタインチョコもらったんだけど嬉しすぎて食べられなくて最終的にはカビさせた」なんてウブな男がいんだよおおおお

お約束の「そんな彼女現在ヨメです、子どもにも恵まれ庭付き一戸建てに犬も飼ったりして現在幸せです」オチとかもはや創作でも絶滅危惧種だろおおおおおお

そうだよ我が両親の話だよどんだけ善行積んだらそんな展開経験するレベルに生まれ変われるんだよおおおおお

ちげーよとりあえずカネはいーんだよ庭付き一戸建ての犬はともかく子ども持っても良いと思えるような相手のゲットの仕方だよおおおおおお

なんなのみんなどうやって恋とかしてんの恋じゃないにしても愛とか情とかなんかこうそういうヤツどうやって発生させてんのよおおおおお

職場出会いなんかねえよ独身自分だけであと既婚と同性だよ!!!事務職で外の人間と接する機会とかねえし今一番興味あるのはVBAとかSQLとかそういうのだよ!!!毎月同じ資料計算で作るのが嫌すぎるんじゃ!!!でもマクロだのでオート化するのがときどきイマイチ上手くいかない!!!どっかに習いに行きたい!!!!金は無い!!!出せても月1万台で2万は絶対無理!!!!!!

ついでにこないだついに30なったわドチクショー!!誕生日過ぎた途端に婚活会社からショートメールが来まくりだよ興味本位登録したけど結局一回も利用せず放置になって2、3年は経つってのによ!!完全にカモられてっだろこれ!!!金は無いってんだよ!!!

あああああもおおおおおお

結婚してええええええええ!!!!!!

こういう暇で天気の芳しくない日にダラダラ過ごす相手を持ちてええええええ!!!!!!

2016-09-19

http://anond.hatelabo.jp/20160919121645

学者→初級者 あるある

ネスト深くなってもいいから&&と||を別にして正しく分岐させるべき。

こんなん設計が悪いってのが前提だけど。

SQLも実運用でサブクエリ使わないと抽出できないとかゼーンブ設計が腐ってんねん。

2016-09-08

http://anond.hatelabo.jp/20160908160737

「小さなショップ」と書くぐらいだからECサイトスクラッチから作る規模だとコストがあわないだろうし、WordpressEC-CUBEベースじゃない?

中規模以下でECサイトを自社スクラッチって聞いたことないし。

だとするとパスワード書いたファイル場所攻撃する側は知ってると思うよ。

それがわからなかったらSQLなげるPHPおけばいい、と思うけどな。

2016-08-16

SQLが書けないマーケターなんてマーケターじゃない

データを出してくださいと、自分が調べたいことに対して逐一依頼を出してくるマーケター

僕がせこせこSQLを書いている間に、情報収集という名のネットサーフィン

もちろん僕もSQLを書くのが専門じゃないので、自分業務優先順位によって対応前後することだってある

その間マーケターWEBの波に飲まれているのだ

お前が波に溺れていた一日は、昨日死んでいったエンジニアが生きたかった一日なのだ

2016-08-13

bash高収入カラクリ

アメリカでもどこでも、俗に言うプログラミング言語であるCやJavaRubyなんかを扱う人間っていうのは

職能としては「コーダー」扱いであり、日本以外ですら下流工程専門の十把一絡げな作業員しか扱われない、ということ。

ITエンジニアリング本質製造工程ではなく運用保守に重きが置かれるものであるから

アプリケーションのものよりも寿命が長く、製造工程では用いることの無いbashSQL高収入なのはしろ必然

はてなーにも数多いるだろうエンジニアの皆様も、多分理解できてるところなんじゃないでしょうか。

プログラム書けるだけとか今時スキル扱いすらされねえよ」って事実に。

2016-07-18

IT業界認定試験もっと重要視すべき

IPAのやってるやつだけじゃなくて、ベンダーのやってる言語とかDBとかああいうのも。

PHPプロジェクトPHP認定試験に受かってる奴しか使わないとか、MySQL資格もってないとテーブル設計やらせないしSQLも書かせないみたいな。

認定試験なんて実力とは関係ないって言う人いるけど、SIerではびこってる「経験年数=技術力」って基準より数段マシになると思うわ。

Java入門書も読んだこと無いレベルの人が、コードを書くどころかレビュワーをやっていて、しかも「経験年数=技術力」って世界観から自分は実力あるとナチュラルに信じこんでるし。

VBから来たベテランが「エラーハンドラを全サブルーチンで書くべし」みたいなルールJavaに持ち込んで「全メソッドcatch(Exception e)するべきだろ」とか自信たっぷりに言ってる世界

ダメ技術者が、年をとってるってだけで評価されて上にたってダメ技術者を育成するって負のループに入り込んでるから一定客観的基準評価する仕組みをもちこんで負のループを断ち切るべき。

2016-07-16

WebデザインWebシステムは、相手企業事業が失敗しないように話を進めるべき

雑談

最近LINE株式上場(証券コード:3938)したようだ。一時は高値で5,000円まで上がったが、安値4,310円(2016年7月16日 17:44現在)まで下がり、なんと690円も下がっている。一瞬の差し足で儲ける連中は賢い。

流行統計的手法deep learning(機械学習人工知能)を駆使し、株価が3,000円台まで下がるタイミングは何月何日か?を探り空売りできないかを考える今日この頃

さてここからが本題。金融に関する仕事コンサルタントなどはできないと思い、とりあえずWebシステムもどき、あるいはWebサイトらしきものを作る仕事を始めた人の愚痴である

商品販売広告戦略立案Webサイト制作までの流れ

まずA社が商品販売するところから、B社がWebサイト制作をするまでの流れを簡単にまとめた。

[Step1]:商品を売ろうと企てる

[Step2]:商品の開発期間・開発コスト広告集客を考える(Plan)

[Step3]:2におけるチラシ・ホームページ外注に投げる

[Step4]:外注先がそれらを一件○万円で引き受け、広告完成(Do)

[Step5]:広告効果がどれだけであったか?を調べ、問題点について調べる(Check)

[Step6]:商品販売を取りやめるべきか?広告の打ち方を変えるかの改善を図る

[Step7]:改善された広告販売戦略を基に動き直す(Action)

さて、かの有名な電通鬼十則( こちら参照)にも「「大きい仕事」と取り組め。小さい仕事は己を小さくする」と言う言葉がある。

先日その大きい仕事のお膝元というべき会社で、Step4を担当している人と話した。それが意外に俺と同じ事を考えててビビった。って事は日本広告業界すべてが、派手な物を作って...って発想なのかと思った。

さて案件の規模が小さい程[Step1〜7]全体の大部分に関与でき、大きい程[Step1〜7]全体が見渡しにくく、関与もしにくい場合もある。そして自分アクションを起こしたが、結局[Step1〜7](PDCA)全体が回ってない事もあるのは何処も一緒なようだ。

もちろん自分は[Step4]の工程の1部品として動いていて、基本1〜7の大枠の中の1部品として動いているに過ぎない。ここでStep4の仕事をしていて愚痴りたい事の1つに、「[Step4]の人たちって、どうして[Step4]の事しか考えないのだろうね?」と言う事だ。以下その愚痴を書きたい。

愚痴:デザイナーに居る「俺が作ったデザインすばらしい」な意識高い系

どうも俺は「俺が作ったデザインすばらしい」「よそがやらないようなデザイン」をひけらかす為に話を進めている場合程、やる気なく仕事している。

過去の嫌な事例

過去酷いと思ったのは、[Step1〜3]側のクライアント会議で決まった内容を、[Step4]のこちら側で無理矢理ひっくり返した物を作った事だ。無論自分らの意見を押し通すのも商談の上で必要な事もあるが、必要ないならやらなくて良いと思う。

上は上で「クライアントでなくウチがやりたいんだ」と一点張り。それに対し、実際に手を下す俺は「既に決まった物なのに、そもそも全体の進捗を狂わす事はないんじゃない?ただただ作業日数も増え、俺のやることも増えるだけだし、俺そこまで能力ないし」と思っていた。

その結果中間会議クライアントに「やらない方がいいんじゃないですか?」と言われ、ざまーみろと思った事もあったっけ(笑)。こうなると「俺はこんなに素晴らしいと思っているのに、お前はそう思わないのか」と言う流れになり、相手からすげえ嫌がられることも少なくない。

確かに「とりあえず始めて見て反響を見る」と言う事も重要だ。しかしながらStep4の自分らが、デザインをひけらかすが目的ならこれは論外だ。以上。こうして俺はデザイン仕事ではやりたくないなあと思うようになった。

商品広告をお客さんに見てもらい、売上を上げる事がそもそものやる事

この時自分がやっていた仕事は、「商品Pの広告ターゲットとする客層のx%に見てもらい、商品Pにおける売上高をy%向上させる」事の一部ではなかろうか?ならば見た目自慢よりも、サイトに依ってお客さんにどれだけ反応が呼べたか?という事を調べ、クライアントと一緒に[Step5〜7]に活かす事も重要だと思う。

サイトの見た目、機能SEO(検索エンジンソーシャル対策)などがそれぞれバラバラなのもいけない。そしてそもそものところで「どのようなお客さんに見てもらったり使ってもらったか?」「そもそもの事業戦略」が無視されている。

そんなに見た目や機能重要か?必要最小限で良いか会社事業が回るようなものにする事こそ、自分ら[Step4]の人間のやる事だと思う。

クライアント、各Step毎の人と連携する姿勢を忘れない

そのためにクライアント、各Step毎の人と連携する姿勢を忘れてはいけない。先ほどの愚痴みたいに各Step毎にバラバラに行動するようなやり方は、今後世界的にも流行らないと予想する。又、システムホームページが内製化されるのも、Step毎の連携を良くする為である

ツールを作る事に頼らず、他のみんなができるように

さて、商売柄わからないことがあると、はてなブログQiita、StackOverflowなどのレシピサイトを見る事が多い。ここで最近Qiitaを読んでいて、「マーケティング担当者にSQLを完全マスターさせた話:Qiita」と言ういい記事があったので紹介したい。以下デザインの話から離れるが、是非聞いて欲しい。

みなさんこの試みをどう思うだろうか?俺はこの動きに賛成だ。俺の推測を書くが、恐らくこの会社社員数は多くて100人前後まで位で、上記の[Step1〜7]までの多くの部分を1社で担当していると思う。

無論顧客情報や売上情報に関するデーターベース(SQL)にアクセスし、それを分かりやすく画面に表示してくれるアプリはあるはずだ。これをみて経営商品を売るのをどうしていくか?を考えて行く訳だ。

例えば、1ヶ月に100回以上データベースに対し特定の処理がなされるのなら、アプリにした方が良い。しかし「この時だけ単発にデータベースに○○な処理をさせて、△△な事を調べたい」と場合もあるはずだ。こうなってくると、「マーケッターの人に単発のSelect案件を片付けてもらおう♪」という流れになる。

以下何故この作戦必要かを熱く語る。例えばファミコンボタンは「Aボタン、Bボタン、STARTキーSELECTキー十字キーしかなく、それ以外の事は一切できない。これはアプリケーションも同じで、アプリケーション化する事でユーザーの動きを制限することにつながる。

必要最小限に仕事をまとめたい場合は別だ。しかし今回の場合「火属性の敵に対し、どう対処するか?」「そもそも相手属性E_1,E_2,…,E_nに切り分け、それぞれに対しどう対処するか?」の場合ならば敵の弱点も変わってくる。そのため制限ありだと対処できないケースも出て来る。

こうなれば「賢者すっぴんすっぴんすっぴん」では某エ△スデスに勝てないだろう。それに賢者戦闘不能の時はもう冷あせもんだ。レイズアレイズ、フェニックスの尾がないときは、誰がケアルエスナしてくれよう。そこで全員が「賢者、赤魔導士、赤魔導士、赤魔導士」位ならば、賢者が忙しい時にケアルが使えてラクだし、全体を有利に進める事が可能になる。

[Step4]の会社にいる立場としてこんな選択が出来るのが羨ましい。なので新しくツールを作るだけが選択肢ではなく、みんながある程度できるようにしておきたい。

その為に自分は何ができ、どうしていきたいか

以下その為に自分は何ができ、どうしていきたいか?について話す。まず自分学生時代、どちらかと言えばxとyが嫌いだった人が絵や音楽をやる事もあるようだ。俺はその逆で、絵を描くのをサボってでもxとyをやり続けていたい人だった。なためどうも絵が好きな人音楽好きな人の話が抽象的に感じる事がある。(俺、Webシステムの方がリクツが分かるほうだから得意かも...)

起業は無いものとして考えた時、どの道Step1〜7のPDCAサイクルなど早々回りゃしない。ならば、少しでも自分の出来そうな方で仕事したいと思っている。わがままを言えば[Step1〜3]寄りの仕事がしたいと薄々思っている。

このまま堅い商売を続けるなら、それこそ物理学者みたいに世の中の物事を数値やy=f(x)化し、扱いやすくしてやりたいとも思う事もある。例えば商売なら、未来予測しきる無敵の関数y=f(x)を編み出してもうけるとか。

又は経営層やマーケッターがxとyを見やすく、確認やすくするデーターベースツールの開発が出来て、売っぱらう事ができれば…(用語言うなら、Microsoft PowerBIと言ったツールかな?)

xとyをフル活用することで、できる限り失敗しない線を探して勝ちを拾う。又はマーケッターなどの人と協力し、無難商品Pを売る上での最強の市場(=有利な戦場)を見つけて行ければとも思う。

最後に「無理に成功を夢見る」ではなく、「出来る限り失敗しないように無難にやる」「無難にやる策を模索する」で行きたい今日この頃。まあ、難しいんだけどな。

2016-07-10

memo

書籍より

Web + DB vol.92

データ分析の基本アーキテクチャ
フレームワーク比較評価

10年戦えるデータ分析入門

SQL中心アーキテクチャの3つの
SQL中心アーキテクチャの3つの条件
tips
  • DWH層を標準ライブラリのように考えて構築するとよい.
    • 「購入の可能性があるユーザ一覧を表すビュー」をDWH層に持たせるなど.

2016-07-08

増田ってSQL使ってるんじゃね?

投稿された日記投稿日時で降順で表示してるから新しい日記が一番上に来るんじゃね?

これ気づいた俺は天才かよ

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