2015年問題から見える日本のIT業界の問題点 その3

努力や学習でなく環境がエンジニアをつくる

常に人材不足だから、仕事には困らない。確かにそれは正しい。そして、散々叩かれているSI業界も今後10年は仕事に困らないのも、確実な未来だ。
人材不足ゆえ、もらえる賃金も上昇する可能性も高い。ボーナスは過去最高の数値をたたき出すかもしれない。 だが、ここで集められたエンジニアと他のプロジェクトで経験をしていくエンジニアは、能力という点で全く別の力を身につけていくことになる。

例えばあるエンジニアは、ネイティブでのアプリ開発がメインの仕事だ。vagrantとchefでサーバー環境を構築し、APIはrails&grapeで短時間で作る。 ユーザーを獲得するために機械学習の勉強もはじめている。コードだけを書いている訳ではない。毎日が新しい技術の勉強で、ユーザー獲得のためにトライアンドエラーの日々だ。悪くいえば何でも屋とも言う。

国家レベルの巨大プロジェクトで集められた人達は、毎日同じ作業だが、そのプロジェクトの中身に精通できる機会をもつことになる。巨大なシステムがどのように動いて、構成されているかを知ることはあとあと大きな財産になる。特に自社でシステムを組む時にそういった経験と知識は本当に役に立つ。漫然と開発だけして過ごすのではなく、ちょっとずつ全体を把握し、システムの規模によりどれくらいの人が動いているのかを理解するとよいだろう。

僕はどちらかが悪く、どちらかが優れているとかは思わないし、言う気もない。結局は自分がどういうキャリアを積みたいか、どういう仕事をしたいかということだ。これは人の価値観の問題である。誰もがtwitterで働くような年収10億のスーパーエンジニアを目指す必要はない。ただ、どの道を進んでも、この業界は進化していかないといずれ振り落とされてしまう。

そして、これがもっとも大切なことだが、あなたがどんなエンジニアになるかはあなたの努力や学習量よりも周りの環境が決める。
例えば僕の場合は、語学が大嫌いだったけど、今は英語と多少だけど中国語が使える。嫌々身に付けたスキルだけど、仕事以外のプライベートでも凄く役に立っている。技術も同じことである。労働時間の長い業界だから、努力や学習量よりも周りの環境で身に付くスキルが決まってしまうのだ。

自分がどんなエンジニアになりたいか、どういった人生を生きていきたいかについては、定期的に時間をとって冷静に考えてみる時間をもつと良い。 僕は三ヶ月ごとにその過去三ヶ月を振り返って、今満足しているかを確認しているが、これは役に立つ習慣だと思う。

自分の進んでいる道が間違っていると分かったら、すぐに道を変えるべきだ。新宿の歌舞伎町を目指して進んでいたら、秋葉原のメイドカフェに到着してしまいましたでは、目もあてられないだろう。幸いにもこの業界は、道を変えても、高速で新しい道を突き進める業界だ。チャンスはすぐに転がり込んでくるだろう。

• その2 人材不足が招く欠陥システムの量産
• その4 人を増やしても問題は解決しない

この記事がお役にたちましたらシェアをお願いします

Tweet

2015年問題から見える日本のIT業界の問題点 その2

人材不足が招く欠陥システムの量産

さて、2015年問題がなくとも、IT業界は常に人不足である。
人が少ないから業務時間は長くなり、仕事は過酷さを増し、人の入れ替わりが激しくなる。 人がいないのだから、人材派遣は悪だと国や国民が叫んだところで、人材派遣は必要悪で栄える。完全なる負のスパイラルだ。

僕は人買いビジネスが大嫌いだが、プロジェクトの納期がタイトで明らかに間に合わない場合は、やはり協力会社のエンジニアにヘルプを依頼することになる。納期を伸ばす交渉もするがやはり限界がある。これが、国や大企業の絡む大型案件ならなおさらだろう。彼らは優秀だが、前時代的なビジネスマインドだ。とりあえず誰でも良いから人をかき集めるようになるのは当然だ。

もちろんただでさえ人材不足な状況なのだから、ろくな人材が集まらないのは自明の理だ。さらに、どの会社もエース級は手放さない。内製のシステムを構築している会社であれば、エース級は社内にいてもらわないと困るのだ。こうして巨大プロジェクトのシステムの構築は迷走していく。

国や巨大企業が発注する巨大案件プロジェクトの開発現場の手法は、いわゆるウォーターフォールと呼ばれる手法を用いられることが多い。最初からビジネスの要件を100%満たせる仕様にまとめるあげるのは不可能なのに、この手法が採用されるプロジェクトは多い。理由はいつも同じだ。それは「(炎上した)実績があるから」である。
そして、引き継ぎに次ぐ引き継ぎと、伝言ゲームで伝わってきた不思議な設計書が実装者の手元に落ちてくるのだ。
そしてかき集められたプログラマー達は、その摩訶不思議な仕様書を眺めながら心にある疑念を抱きながらコードを書くのである。

「誰がこんなシステムを使うんだ。使いにくいにもほどがある」

仕様書に記載されているのは、一瞥しただけで使いにくいとわかるシステムだ。だが、彼らは仕事として割り切る。というか割り切る以外に方法はない。彼らは実装するのが主な仕事なのだ。悪臭のする香水を作れと言われて不思議に思ったとしても、その商品を作るのがプロだ。そしてその商品を売るのが営業で、使うのが運用だ。こうして欠陥システムが作られていくのである。

だが、さらにたちが悪いのはこの先である。前回、ダーウィンの言葉を引用させてもらった。

「唯一生き残るのは、変化できる者である」

何度もいうがこの言葉は絶対だ。きっとそれは未来でも変わらない。
集められたプログラマー達の中には辞めていく者も多いが、残る者も多いのだ。そう、彼らは「変化できる者」なのだ。
だが、その変化は悲惨な変化でもある。それは、「こういう仕様で、こういうシステムなのだ。」という変化を彼らは遂げるのだ。

彼らが環境に慣れた頃、新しい機能を実装するためにさらに多くのエンジニアが合流する。合流した彼らは開発環境を構築し、一通りの機能を触ってみる。そして眉をひそめて尋ねるのだ。

合流したエンジニア「このシステムは操作と手順を覚えるのが大変ですね(皮肉)」
変化したエンジニア「大丈夫ですよ。すぐ慣れます。慣れです、慣れ(苦笑)」
合流したエンジニア「うーん、ここの仕様がよくわからないんですけど」
変化したエンジニア「大丈夫ですよ。みんなよくわかってませんから。もちろん僕もわかりません。こういうもんなんです」

現場レベルで作業をしたことのないエンドユーザー様やコンサル様にはわからないだろう。これは経験した者にしかわからない。
だが、これは現実によくある話なのだ。というより巨大プロジェクトの5割の現場はこうである。まるで、IT業界には台本が用意されているかのように、このコントは上演される。

こういった現場で働いたことが無い人も話には聞いたことはあるかもしれないが、本来の現場レベルは話に聞く100倍ひどいと思って間違いない。

こうして欠陥システムが次々と制作されていくのだ

• その1 2015年問題
• その3 努力や学習でなく環境がエンジニアをつくる

この記事がお役にたちましたらシェアをお願いします

Tweet

2015年問題から見える日本のIT業界の問題点 その1

IT業界では、2015年問題と呼ばれる課題が顔をのぞかせはじめているらしい。

2015年問題

アベノミクスによる景気回復に伴う情報システムへの投資拡大や、大規模プロジェクトの開発ピークの重なりによって、IT企業が2015年を中心にIT人材不足に悩まされている状況のこと

引用:http://www.itmedia.co.jp/enterprise/articles/1408/06/news012.html

「SIビジネスは崩壊する」
最近は、SIビジネスの問題があらゆる角度から色々と指摘され、もうSI業界に時間は残されていないような風潮ができあがっていた。

だが、その寿命が10年くらいは伸びたように思う。少なくともこの先5-10年は、人材派遣ビジネスでがっつりと金を稼げるだろう。オリンピック次第ではもっと長く稼げるかもしれない。
政治はビジネスのあり方をも大きく変えてしまう。アベノミクスは典型的な良い例だ。

ダーウィンの
「最も強い者が生き残るのではなく、 最も賢い者が生き延びるでもない。 唯一生き残るのは、変化できる者である」
はこの世の真理をついている。

私は常駐型のエンジニアでないので、2015年問題にはあまり関心はなかった。しかし、最近は国内だけでなく中国の案件まで日本でやってくれと頼まれることが増えてきたので、そこまでエンジニアが足りてないのかと不思議に思い、ちょっと調査をしてみてこの問題を知ることになった。

そしてよい機会なので、僕なりにこの業界について考えていることや思っていることをまとめてみようと考えた。
この業界は、次から次へと新サービスが生まれてくる進化の早い業界だ。だが、実際は時代の流れに乗れて動けているのはごく一部なのだということを、IT業界以外の人も知っておこう。そして、IT業界にいるから決して時代の最先端にいるというわけではないということも。

• その2 人材不足が招く欠陥システムの量産

この記事がお役にたちましたらシェアをお願いします

Tweet

rails4 rspecリファクタリング

環境

• rails(ruby2.1.0, rails4.0.3)
• grape(API)

rails4でのrspecリファクタリングメモ。テストのコード量が増えてきたので、色々と試行錯誤してます。

リファクタリング前
FactoryGirlが重複しているコード。

      it "all request parameter is exists" do
        FactoryGirl.create(:user1)
        put "api/v1/user", {:id => user1.id}
      end
      it "xxx request parameter is exists" do
        FactoryGirl.create(:user1) 
        put "api/v1/user", {:id => user1.id, xxx => "aaaa"}
      end
      it "yyy request parameter is exists" do
        FactoryGirl.create(:user1)
        put "api/v1/user", {:id => user1.id, yyy => "aaaa"}
      end

リファクタリング後

      let(:user1) {FactoryGirl.create(:user1)}
      it "all request parameter is exists" do
        put "api/v1/user", {:id => user1.id}
      end
      it "xxx request parameter is exists" do
        put "api/v1/user", {:id => user1.id, xxx => "aaaa"}
      end
      it "yyy request parameter is exists" do
        put "api/v1/user", {:id => user1.id, yyy => "aaaa"}
      end

letを使うことで、lazy loadしてspecテストが終わるまでuser1変数をキャッシュとして使っています。
ただし、変数として必要ない場合はletでなくbeforeを使ってテストデータを挿入してます。理由は僕のプロジェクトの場合、dbcleanerでテストごとにマスタ以外のテーブルを空にしているからです。

しかし、rspecでコードをdryに保つのは本当に大変です。この辺のかける時間と必要性のバランスは本当に永遠の課題ですね。

参考サイト

• Better specs

この記事がお役にたちましたらシェアをお願いします

Tweet

rails4 定数の書き方

環境

• rails(ruby2.1.0, rails4.0.3)
• grape(API)

rails4で定数を記述していて、コード量が増えて色々と迷ったけど、以下の記載方法に落ち着いたのでメモ

リファクタリング前

  # ログイン 成功
  RESULT_CODE_IU001 = "IU001"
  # ログイン 成功2
  RESULT_CODE_IU002 = "IU002"
  # ログイン 失敗
  ERROR_CODE_IUE001 = "IUE001"

リファクタリング後

  # ログイン
  LOGIN = {R-IU001:'IU001', R-IU002:'IU002', E-IUE001:'IUE001'}.freeze

上記のように書くことでコード量が減り、なにより直感的に理解しやすくなった。
上記の定数を使う場合は以下のように記述する。

  expect(hash["resultCode"]).to eq(API::LOGIN[:R-IU001])

最近はrailsのテストコードだけでなくserverspecでもrspecでテストコードを記述する機会が増えてます。
もっとruby力をあげないといけないと痛感しています。機械学習だとpythonが必要だし、誰かrubyで機械学習のツール整えてくれないかなー(僕は無理ですw)
でわ。

この記事がお役にたちましたらシェアをお願いします

Tweet

chefを使ったインフラ構築をやって思うこと

仕事でインフラ構築全般に関わり出したので、思ったことをメモ。

一昔前なら、ネイティブアプリ開発、WEBアプリ開発、データ分析、インフラ構築を一人で全部やるとか絶対無理だったんだけど、今はなんとかなってしまうところが開発の世界の進化の速度の凄さを示している。
10年後の開発環境とか想像もできない。

今回はchefについて語ろうと思う。

このchef。
もうこのツールなしで開発はもう無理と思ってしまうくらい便利だ。
WEBアプリの開発ではもう完全に必須ツール。今話題のdockerも触ってみたけど、周辺ツールが貧弱すぎるので、しばらくはchefが中心だと思う。

ただchefは、学習の敷居が高いことでも有名だ。僕はrailsを使った開発でrspecをかなり昔からいじっているからあまり抵抗はなかったけど、確かにわかりにくい箇所は多かったように思う。

chefの勉強の仕方は色々あるが、基本は他の技術の勉強の仕方と同じでよい。

つまりはコードをとにかく書いて動かし、サンプルコード(chefの場合はopscodeがgood)を読んで真似て自分の書いたコードの質をあげていくのだ。 どうしても理解できなかったら、わからない部分の基礎まで遡って内容を理解していく。

あと大事なのは、「最初はopscodeを使わない」ことも重要。
最初は手を動かして「どうやって設定しているのか。どのように動いているのか。」を理解することが重要。何の技術でもそうだけど、根っこは押さえておく必要がある。 何かが起きた時に、全く中身はわからないは危険だ。
技術的負債を返すために、テストコードを書いてリファクタリングをするべきという意見があるがインフラも同じだ。 売掛金は資産だが、資本ではない。ここでいうopscodeは売掛金と同じだ。売掛金は回収できないことがある。opscode場合は、大きな負債になることもある。

あとはserverspecを導入することも大事。

railsで開発している人はテストを書く習慣がある人が多いけど、他の言語(特にp○p)の開発者はテストを書かない傾向がある。(僕の周りだけ？)
でも、テストって動作を確認するだけじゃなくて、コードを書く能力や設計の能力も向上させてくれるものだから、面倒くさがらずに書かないといけない。 工数は増えるけど、おつりどころか利子がついて返ってくる。長期にわたると複利効果も期待できる。 上司が認めてくれないから書かない、書けないのではなく、こっそり少しでもいいから書くべきだ。結局はみんなのためになるし、あなたのためにもなる。
テストコードを書くのは習慣だ。朝顔を洗ったり、メイクをするのと同じだ。

今後は小さなプロジェクトならネイティブアプリ、WEBアプリ(API,　管理画面), インフラ構築を一人の開発者が全部やってしまうのが普通になると思う。 実際、今の時点でもなんとかなってしまっている。もう少しデータ解析の技術が発展すれば、分析も一人の開発者でできてしまうと思う。
僕も機械学習の学習を始めたけど、まだちょっと敷居高いなあという印象。

いずれにせよ、面白い時代です。今後、どんな開発手法が発展し、サービスがうまれてくるのか楽しみです。

この記事がお役にたちましたらシェアをお願いします

Tweet

vagrant gsub!: invalid byte sequence in Windows-31J (ArgumentError)

環境

• windows7
• vagrant1.6.5

windows7でvagrantのprovision用のシェルを記述して実行したら題名のエラーが発生したので、対応のメモ。

対応方法

Vagrantfileに以下の記載を追加する

  // 下記のエンコーディンを指定
  Encoding.default_external = 'UTF-8'
  config.vm.provision :shell, :path => "bootstrap.sh"

以上。

参考

• DQNEO起業日記

この記事がお役にたちましたらシェアをお願いします

Tweet

Android CI環境構築

AndroidのCI環境を構築することになったのでメモ

目的

jenkinsでgitからcloneしてきたソースコードをgradleでビルドしてapkを出力する。

環境

• さくらVPS(cent os)
• GitLab
• android studio開発アプリ(gradle)

前提条件

以下の設定が終了している。

• apacheとjenkinsのinstallと起動
• javaのinstall環境設定
• android sdkのinstallと環境設定
• androidアプリ作成

.gitignoreファイルを作成

*.apk
*.ap_
*.dex
*.class
bin/
gen/
local.properties
.classpath
.project
proguard/
*.iml
*.ipr
*.iws
.idea/workspace.xml
.idea/tasks.xml
.idea/libraries/
.gradle
app/build/
.DS_Store

androidアプリのgitファイル作成

git init
git add .
git commit -m "first commit"

gitLabにandroidアプリのコードをpush

// remoteを追加
git remote add git@xxxxxxx---xxxxxxx

// push
git push -u origin master

• gitLabでjenkinsユーザーをプロジェクトにdeveloperとして追加する。
• jenkinsを立ち上げて接続

gradleのinstall

// 作業フォルダへ
cd

cd work/

// download
sudo wget https://services.gradle.org/distributions/gradle-2.0-all.zip

// 解凍
sudo unzip gradle-2.0-all.zip

// フォルダの移動
sudo mv gradle-2.0 /usr/local/

// 環境変数にパスを通す
echo 'export GRADLE_HOME=/usr/local/gradle-2.0' >> ~/.bash_profile
echo 'export PATH=$PATH:$GRADLE_HOME/bin' >> ~/.bash_profile

// 反映
source ~/.bash_profile

// バージョン確認
gradle -v

// OK
Gradle 2.0

jenkinsを使わないで、gradleでandroidアプリのビルド実行できることを確認

// 作業フォルダへ
cd

cd work/

git clone git@xxxxxxx---xxxxxxx


// プロジェクトフォルダの中へ
cd jenkinsandroid

// local.propertiesファイルを作成
vi local.properties

// sdk pathを設定
sdk.dir=/usr/local/android-sdk-linux

// gradlewファイルの権限を変更
chmod 777 gradlew

// gradlew tasks実行
./gradlew tasks

// 種類を確認

// gradlew 実行
./gradlew assembleDebug

:app:assembleDebug

BUILD SUCCESSFUL

Total time: 31.966 secs

// apkが作成されていることを確認する
cd /home/{user}/work/jenkinsandroid/app/build/outputs/apk

// ファイル一覧
ls -l

ビルドが成功したらもう一歩です。

jenkinsでgitからコードを取得してビルドする

// gradlewをjenkinsで実行できるようにする
sudo chown -R jenkins:jenkins gradlew

jenkinsにアクセス

• 新規jobの設定
• プロジェクト設定
• jenkinsユーザーがgitLabからsshでソースを取得可能にする
• ソースコード管理とビルドのシェルの実行を設定

ビルドのシェルの実行を設定

// 権限
sudo chmod 777 gradlew
// gradlew実行
sudo ./gradlew assembleDebug

上記のままだとjenkinsユーザーはsudoできないので、以下のように変更

visudo

jenkins ALL=(ALL)      ALL

// ttyなし&パスワードなしに設定する

# Defaults requiretty           # tty無しの場合sudoさせない
Defaults:jenkins !requiretty   # ユーザjenkinsはtty無しでsudo可能
jenkins ALL=(ALL) NOPASSWD:ALL # ユーザjenkinsはパスワード無しでsudo可能

git clone後にlocal.propertiesがない場合(初回設定)は、フォルダに配置が必要

touch local.properties

local.properties

sdk.dir=/usr/local/android-sdk-linux

ワークスペースもjenkinsユーザーが読み書き実行できるようにする

/var/lib/jenkins/workspace/jenkinsandroid/app

// build以下の権限を変更
sudo chown -R jenkins:jenkins build

ジェンキンスアプリ側でもworkspaceに出力ファイル名を記載してやる

// workspaceを設定
**

以上。全ての設定がうまくいっていればapkファイルが/var/lib/jenkins/workspace/jenkinsandroid/app/build/outputs/apkに出力されます。

あとは開発環境に応じたgradleの設定をしてやれば、様々なパターンのapkを作り放題です。これで誰にも作業を中断されない…!!!

この記事がお役にたちましたらシェアをお願いします

Tweet