一身独立

素人SEの成長日記

2014年8月21日

・自分から変わること

  →目標を明確にイメージして、自分を変える。その変化を止めることなく続けること。

・素直であること。

・チームのために

  →行動はチームのために行われなくてはならない。

・成長する喜びを感じること

  →危機感からではなく、内から溢れる欲求で前進すること。


〜2014年8月20日

・先輩の姿勢を見習うこと。

  →やり甲斐とか、キレイなものでなくて、「立身出世」を目指すというだけで十分じゃないか。甘えることなく、今できることを黙々とやる。

・人に会うこと。

  →忙しくなる前に、人物にあうこと。その人の情熱を感じること。

・自分でやる。

  →自分でやること。やるには戦略が要る。目的、理屈を腹に落として仕事をする。

・素直であること。

  →どんな時でも素直であること。自律せよ。

2014年8月14日

大学時代からの師匠?と会ったのでメモを残しておく。


目的の分からない仕事はやるな。

→なぜと自問自答する習慣をつける。

→堀下げる方向はその仕事のゴールであること。


アウトプットを残す。

→誰がその仕事を引き継いでも問題なく遂行することができるか。


ムダ、ムリ、ムラを排除する。

→目的の分からない仕事はムダを生む。




Hadoopめも

 

1. 成り立ち

・考え方、仕組みはGoogleが発祥

・Yahoo!で発展したオープンソース

・検索エンジンのインデックスを作成するために利用

 →従来のRDBMSベースの仕組みではデータ量に負けてしまう

 →「RDBMSでは処理できない」を解決しようとしたものである

  (処理時間のこと)

・マシンパワーで対処できなかったのか?

 CPUの性能は確かに向上しているが、ディクスアクセスがボトルネックになってしまっている。

 

2. 分散IO処理

 ディスクIOボトルネックを解消させる

 →データをノードに分散させ、そのデータに対して処理を行う。

  CPUパワーを使い切ることができる。

 

3. Hadoopの有用性

 成り立ちから分かるように、「ビッグデータ」専門のアーキテクチャではない。

 IOボトルネックが発生しているシステムに大しては有効であるということ。

 マシンは立派なのにバッチが終わらない(IOに時間がかかっていて、CPUを使いこなせていない)処理には効果的である。

 しかし、分散したデータの同期、更新処理には不向きである。

 如何にして適用可能箇所を抜き出して利用できるかが鍵。

 

4. MapReduce

 Map関数、Reduce関す、Shuffle処理によって全ての処理が行われる。

 実際の処理の分散化、タスクの実行、各関数の受け渡しなどは下位の実行基盤任せ出よい。

 非常に簡単な仕組みではあるが、それ故に、複雑な処理を実現しようとすると、実装がこんなんになる場合がある。

2012/10/09 SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道 - DevLOVE

に、行ってきた。

細かい内容は、素晴らしいまとめがあるので書かないことにする。

気になった事を、まとめておく。

 

1.あがる消費税率、消える年金

 これはもう5年以内の話。

 10%越えたあたりからは本当に辛いらしい。

 生活することすら厳しい時代がもう目の前だそうだ。

 ・消費税があがる

 ・所得は据え置き

 →実質所得(?)が下がるだけだそうだ。

 

 年金については、既にシステムが破綻している。

 しかし、ワリを食ったと自負する世代は主張を弱めない。

 →払ったお金は返ってこない。

 まぁ、先輩方の残した借金を返すのも僕らではあるけれど、

 財産を食いつくそうとしているのも僕らだから。払います。

 

2.消費税率はあがった。所得は?

 あがりません。

 もはや儲かる仕事なんてしていないのだから。

 なんとか給料を払って、食いつなぐための仕事に食いつき、

 また負ける。

 そんなこんなであがらない。

 あと、給料を上げることによる、社員のモチベーションの変化は、

 むしろマイナス方向に働く事が多く、

 マネジメントの鉄則として、あげる時は全員一緒!となるそうです。

 「仕事ができる技術者にもっと報酬を!」は一見正論だし、

 だれも異論はないところだけど、企業が大きければ大きい程、

 それは難しくなるんだって。

 

3.人材の採用

 僕自身、素人でこの業界に飛び込んでしまってるので、

 耳が痛いというか、「ごめんなさい」な話でしたが、

 「何も知らずに入ってくる輩が多すぎる。」

 「そして、その質が酷すぎる。」

 という現実があります。

 先の話にある「できる技術者」が凄いことも一つだが、

 「できない技術者(と呼んでいいものか)」のレベルの低さが、

 「生産性10倍神話」を実話にしてしまっているらしい。

 ごめんなさい。w

 しっかりテストして、程よいレベルの人材だけ採ればいいんじゃないの?

 入った後は、研修なり教育プログラムできっちり鍛えてさ。

 という解が一つ出ていました。

 

4.消えるSIer

 とにかく大変です。

 儲からないし、おいしい仕事もありません。

 採ってきた仕事は、素人が炎上させます。

 人海戦術は認められません。

 市場も縮小します。

 会社からの優秀な人材の流出もとまりません。

 どうする?

 

 以上が、「一つの」現実です。

 確かなデータもあれば、現実に肌に感じている事。

 はっきり言って、今から死ぬ気で頑張ったところで、

 5年後、10年後、生き残っていられる保証はありません。

 むしろ、果てる可能性の方が圧倒的に高い。

 残ったとしても、報酬は驚く程もらえない。

 ここで、はっきりと言える事は、

 「素人はさっさと逃げなさい。コレから先はプロの戦いだ。」

 ということなのではないか。

 素人根性、サラリーマン根性で勤めいる人は、

 今すぐ転職を考えるべきだと思ってる。

 もとめられる技術の範囲も広がるし、水準も高くなる。

 のらりくらりでは安心して食っていけないはすです。

 だったら、もっとぬくぬくやれる仕事は必ずあると思う。

 

5.これからの業務系SE

 自分のカードを揃える事。

 戦いに向けて、カードの種類と、

 レベルを高い水準に引き上げておく。

 「最強−1」を目指して。

 

 細かい事はいいとして、自分は、

 ①業務知識 

 ②データベース周り

 ③設計

 あたりを強くしていこうと思う。(当面)

 

 はっきりいって、不安で不安で仕方が無いけれど、

 乗りかけた船だし、いっちょ戦ってこようと思う。

 

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

 

1.概要

 DB設計がなぜ重要なのか。逆に、なぜ難しいのか。「論理設計、物理設計」「正規化」「ER図」「パフォーマンス」「ノウハウ」など、本流を平易な文章でまとめてありました。レベル的には、RDBについての入門書を終えた辺りでしょうか。

 

2.おもしろかったところ

 先輩が進めているプロジェクトが、今、基本設計に入っていて、毎日DBの設計やパフォーマンスについて頭を悩ませていました。この本を読む前は、「なぜそんなに神経質になるのか?」と疑問に思っていましたが、この本を読み進めるうちに、システム開発の肝がこの設計なのか!と理解できるようになりました。

 

3.理解できなかった章とその理由

 「バッドノウハウ」「グレーノウハウ」のところだと思います。やはり、設計や、その設計が甘かったからこその事故なんかを目の当たりにしていないところが現実味を薄れさせていました。

 

4.仕事に活かせそうな知識、活かし方

 これは、入門書なので、全て活かせるもの。ただ、読んだからといってすぐに現場に役立つのか?というと違っていて、これを読んで、次の学習ステップへの糧とする、のが入門書だと思っています。