paiza開発日誌

IT/Webエンジニア向け総合求人・学習サービス「paiza」(https://paiza.jp ギノ株式会社)の開発者が開発の事、プログラミングネタ、ITエンジニアの転職などについて書いています。

地方の常駐・運用PGが、東京の開発エンジニアになるためにやった一つの事

f:id:paiza:20140624192624j:plain
Photo by Ryan Johnson

f:id:paiza:20140624194011j:plain今回は、paiza開発担当の佐藤がお送りします。

paizaの開発エンジニアとして働き始めたのが今年2月から。日々Railsと格闘しつつpaizaWebサービスの開発を行ってますが、それ以前は北陸のとある地方でC#メインの運用保守エンジニア(常駐型)をやってました。そんな自分が開発エンジニアになるためにやった事、また実際になってみて判った事について書いてみます

■何をやっていたか

地方の高専情報工学科→同じ地方の大学に編入→大学院→同じ地方の常駐メインのIT企業→paiza(ギノ)というのがこれまでのキャリアです。その地方のIT企業では地方自治体のサーバの運用保守のエンジニアをやってました

運用保守エンジニアの仕事は、他社が作ったシステムが納品されたところから引き継いで運用保守をしていたのですが、そのシステムは色々とバグが多かったので当初はその保守と、通常の運用を中心に行っていました。また出来上がったものを触っているだけじゃなくて、地方自治体の仕事だったので制度改正に合わせて既存のシステムに改修を加える仕事をやっていました。

15、16個ぐらいのシステムの保守をやっていたので、色んな仕事を振られてました。具体例でいうと、UIから修正できないデータの強制修正、システムの利用方法についての問い合わせ対応、改修時の見積と影響範囲調査、既存のシステムで出せないようなデータをSQL書いてエクセル化して渡すという仕事などです。

■どう感じていたか

その地方自治体の仕事をどう感じていたかというと「今やっている仕事ってITっぽくない。SEっぽくない。」という事です。職員の仕事プラスITみたいな。ITが凄く使える職員みたいな仕事だったので、開発スキルが身につけられず「将来どうするんだろう…」という思いがずっとありました。

ただその仕事の良いところもあって、それはほとんどの裁量を任せて貰えたこと。自分の判断で新しいソースコードの管理(VSS→SVN)に変更したり、タスク管理をエクセルからRedmineに切り替えたりという事を許可してもらえたりしました。逆にそれが無ければ、エンジニア的に面白味のない環境だったかもしれません。

その時に所属していた会社では、自社製品を作ろうという流れが社内にありました。入社してすぐに研修を兼ねて、回覧板機能やスケジュール管理機能などを備えた社内向けグループウェアの開発をおこないました。

それが初めてのWEBシステム開発でした。その会社はいわゆるSIだったのですが、社内向けのシステムだったのでアジャイルで開発が出来て「次はこういう仕事をやりたいな。」とおぼろげながら考えていました。また入社時から3年ぐらいで次に行こうという事も決めてました

■開発側に移るためにどういう準備をしていたか

やった事は一つ。その地方自治体の仕事で「仕事の方法を変える」という事でした。なるべく自分の仕事を開発っぽい仕事に変えられるようにしようと目論みました。何段階か追ってやっていこうと考えたのです。実際にやったのは下記のようなことです。

  1. ルーチン系の仕事は誰でも出来るように、マニュアル化できるところはマニュアル化してほかの人に振っていく
  2. 次に空いた時間で手作業系の仕事を自動化する。自分が自動化のための開発をおこなう
  3. マニュアル化、自動化した仕事の実運用は他の人に渡していく


それによって自分は自動化するためのツール、システムを開発する人、というポジションを作っていきました。自分で開発するときはテスト駆動で書くようにしたり、どうせやるならやったことない事をやろうというので毎回何か新しいチャレンジをやってました。

またこうした事で次のようなメリットもありました。

  1. 自動化する事でヒューマンエラーが減っていった
  2. ルーチン作業が減るので自分の時間に余裕が増えていく
  3. 空いた時間でさらに自動化したり、バージョン管理を入れたり、Redmineを入れたりと、モダンな開発環境を作る事ができた。
  4. プライベートの時間も増えて、次の仕事のための準備(Railsを触ったり)ができるようになった


自分のいた地方にはモダンな開発環境やDevOpsなどについて知っている人がほとんどいなかったので、ネットで調べて現場をどんどんモダンな環境にしていくという事をやっていました。これをやっていたおかげもあり、paizaの開発に携わるようになったときも、AWSGithub、JIRA、Railsというような、わりとモダンな環境に対しても抵抗なく入っていく事が出来ました。

ただ、2年ぐらいそんなことをやっていたら、一通りやる事が終わってルーチンワークだけになってしまいました。

■プライベートでなにを勉強していたか

会社での仕事がウォーターフォールだったので、プライベートではずっとアジャイルの本を読んでいました。どういう風に進めていけばプロジェクトをうまく進められるか知りたくて読んでいた感じです。具体的には下記のような本です。

アート・オブ・アジャイル・デベロップメント 〜組織を成功に導くエクストリームプログラミング

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)

アジャイルサムライ 〜達人開発者への道〜

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−


また「WEB系のシステムやるなら何がいいのかな」と思い調べていたらRailsがいいなと思い、RedmineRailsだったので週末にプラグインを作ったりして、仕事で使っていたRedmineにそのプラグインをいれたりしました。次にやりたい仕事(Web系でRails)と、今やっている仕事(Redmineを利用)でかみ合うところが、そこだったという感じでした。

技術書を読む手前の「どうやって勉強していくか」「生産性を上げていくか」についても勉強していました。

リファクタリング・ウェットウェア 〜達人プログラマーの思考法と学習法〜

リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法

リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法

プロダクティブ・プログラマプログラマのための生産性向上術〜

プロダクティブ・プログラマ -プログラマのための生産性向上術 (THEORY/IN/PRACTICE)

プロダクティブ・プログラマ -プログラマのための生産性向上術 (THEORY/IN/PRACTICE)


ウェットウェアとは「人間の脳や思考方法」を指す言葉だそうです。
学習・思考法の改善について取り上げた本で、初心者から達人に至るまでのヒントが示されています。

具体的には右脳・左脳における思考方法の違いや、人間の脳のクセ(認知バイアス)、それらを踏まえた効率的な学習方法や集中力を高めるための方法などが紹介されています。

また、プロダクティブ・プログラマでは生産性を上げるための方法論について取り上げられています。熟練のエンジニアの持つ様々なテクニック(コマンドライン正規表現、自動化)についての紹介や、テスト駆動、オブジェクト指向の正しい設計方法、メタプログラミング、といったプログラミングの少し深い領域の内容について解説されています。
これは前述の「仕事の方法を変えよう」という意識のきっかけにもなった本だと思います。

特定の技術について書かれた本はフレームワークのバージョンアップや技術的な流行の移り変わりによって価値の劣化が激しいのですが、これらの本は広い分野で長きに渡って価値を持つのでオススメです。

そのあとはRails系の本を読みました。

基礎Ruby on Rails

改訂新版 基礎Ruby on Rails (IMPRESS KISO SERIES)

改訂新版 基礎Ruby on Rails (IMPRESS KISO SERIES)

HerokuではじめるRailsプログラミング入門

HerokuではじめるRailsプログラミング入門

HerokuではじめるRailsプログラミング入門

RailsによるアジャイルWebアプリケーション開発

RailsによるアジャイルWebアプリケーション開発 第4版

RailsによるアジャイルWebアプリケーション開発 第4版

Railsはバージョンアップが早いため、現在もこれらの本の内容が有用かどうかは分かりません。あくまで参考程度と思って下さい。

それまでコンパイル系言語しかやっていなかったので、スクリプト系のRailsは当初体感的によくわらかない事が多くありました。そこで勉強会に行ってどういう風にやっているのかを体験したり、ドットインストールを使って仕組みが分からなくても動く部分までやって、それを見てから理論を学び、実際何か作ってみようという形で勉強を進めました。

また、何かプロダクトを作ろうとしても自分だと「何を作るか」というお題が出てこないので、自分の仕事とは別の部署でこういうものやりたいという人に対して「自分がやります」と言って休みの日にRailsとHerokuでプロトタイプ作ってみたりもしてました。そのプロトタイプが3日ほどで作れたのは驚きました。「綺麗なコードが書けない」と壁にあたった時には「みんなどう書いているんだろうと?」思い、Redmineソースコードを読んだりもしました。

■どういうタイミングで転職したか

そういう業務外のわずかな時間での勉強を続けているうちに、「これ以上は業務でRailsをやらないとRailsでのスキルは身につかない」と思い転職を意識するようになりました。

次を探す軸としては、受託じゃなく自社サービス。受託だと発注側と受託側ではビジネス上向いている方向が違うので、どんなに頑張っても、仕事していてむなしさが有ったり、もっと突っ込んだ提案や思い切った事が出来ないもどかしさがありました。現場の声が全然反映されてないシステムが出来てしまったり、納品してもミスマッチなものが多くなってしまいがちで、仕組みに対する疑問もありました。

それもあって次は自社サービスだと思っていました。「自社サービスでアジャイルな環境でRailsで開発ができるところ」という条件で次の仕事を探し始めました。また地方の限界も感じていたので東京に絞って探しました。

新しい環境でちゃんと出来るかどうかは、正直やってみないとわからないと思ってましたが、自動化したり環境を作り変えて仕事の在り方を随分変えた事が「次でもきっとやっていける」という自信になっていたんだと思います。

今となっては手前味噌になってしまいますが、転職は幾つか転職サイトをみていましたが、paiza経由であっという間に決まってしまいました…。自分的にはもう少し先に転職するつもりでいたんですが、最初軽い気持ちでSkype面談をしたところ「旅費をだすから週末に職場見学もかねて東京に週末インターンに来ないか」と誘われ、行ってみたら面白そうな職場で(自分のためだけに経営陣が土曜日出勤してくれた)、内定ももらえたのでそのまま転職した、という感じでした。

これはたまたま良い巡り合わせで出会ったというのも有りましたが、良い運とういのは誰にでもどこにでも流れているのではないかと思います。それを掴めるかどうか。その運をつかむ準備がこの時は出来ていた、という事なんだと思います。

自分の経歴は地方自治体の仕事は職員の仕事+ITみたいな感じだったので、職務経歴としてこういうプロジェクトやっていましたというアピールポイントに欠ける内容でした。話せばある程度自分がやってきたことは伝えられるけれど、職務経歴だとなかなか伝え辛く、また地方という事で気軽に面接をしてもらえないので書類選考では不利な状況でした。ただpaizaではランクさえ取っていれば面接に進めたというのが良かったのです。…なんかステマみたいですが、本当に助けられましたのは事実です。

■実際に開発エンジニアになって何が役立ったか

f:id:paiza:20140624193412j:plain
Photo by William Warby

地方の常駐型の運用保守エンジニアから、実際に東京の自社サービスの開発エンジニアになってみて、事前に準備していた事で役立ったことは下記です。

(1)家でRailsを書いていた事

同じIT系とはいえ全然違う分野、業務系の運用保守+情報システムみたいな立ち位置から、Webサービスの開発エンジニアへの転向だったので、家でRails触っていたのは本当に良かったです。1から全部覚えるわけではなく、ある程度書ける状態だったでのキャッチアップが非常に早くできたと思います。

(2)モダンな環境を取り入れていた事

前職では、まわりのメンバーは失敗を恐れて新しい事をやるのを嫌がっていましたが、失敗しないように家でちゃんと練習してから行ったり、開発環境の整備をしていた事が非常に役立ちました。また、モダンな開発環境を取り入れていたので、paizaの開発環境にも戸惑うことなく入っていけました。

■開発エンジニアになって戸惑った事

正確には開発エンジニアになってみて戸惑ったという訳ではありませんが、採用前のインターンの際に「paizaのバックエンドシステムについてどうやっていると思うか、考えてきてください」という事前の宿題がきた事や、インターン当日に「開発っぽい事やってみましょう」と、その場で開発環境を作るところからやる事になったのには冷や汗がでました…。

それを受けて、実際に入社するまでに家で準備をしたので、入社後あまり戸惑うことは有りませんでした。むしろ、今までできなかった事ができるようになったのが良かったです。今は自分が思ったことをどんどん提案できる環境だなと思っています。

ただいまだだに受託&常駐の癖が抜けなくて、「言われた事から逸脱出来ない」という体質が染みついているみたいです。提案を求められている時でも、動けない瞬間があったのですが、最近は少しづつ変わってきたかなと思っています。受け身から能動的になってかないといけない。そういう点が今までとは全然違います。でもそれをやりたかったので良かったと思っています。

地方から東京に出てきての戸惑いは、それなりに覚悟していたのですが、実は殆ど有りませんでした。有るとしたらドトールなどの喫茶店の店員さんの愛想などです。地方だと2〜3回通うと話しかけてきてくれたりフレンドリーですが、東京はそういうのはなく、ちょっと冷たさは感じたりしました。家賃は2.5倍ぐらいになりましたが、給与も上がったのであまり問題はなかったです。

■外からみた自社サービスと中から見た自社サービスの違い

自社サービスの会社に身を置いて感じた「違い」というか「恐ろしさ」は、自分の開発が直接収益につながってしまうところです。

請け負いは最初から「いくら貰える」と決まってて、スムーズに進めていければOKという感じで、やり方は大体見えてくると思うのです。しかし自社サービスは「まず正解は何処だ?」というところから始まるので、自分たちの判断でビジネスとしての結果が大きく変わるところは、冷静になると怖いなと思います。

開けてみるまで分からない怖さ。「これ絶対イケるでしょう」と開発を進めている機能や企画が実はイケてなかったりとか。そうなるとそれが結果的に収益に表れてくる。ただスケジュール通りに開発すればいい訳じゃないのには怖さがあります。

■まとめ

前の職場で、次の職場に行けるように日々の仕事の中で小さなチャレンジをし続けていたことがとても役に立ったと思います。愚痴を言うのではなく、今の仕事でチャレンジできるところを見つけ、それを続けていれば道は開ける、という事なのだと思います。

Webサービスに関わりたいとか、Railsアジャイル開発をしたいとか、目標をある程度定めていたのも良かったと思います。目標があったので毎日の仕事でチャレンジしようという感じになったのです。

色々とラッキーだった面もあるのですが、もし同じような境遇で悩んでいる方が居たら参考になればと思い書いてみました。




paizaではシステム開発の基礎力や、テストケースを想定できるかの力(テストコードを書く力)などが問われる問題を出題しています。テストの結果によりS,A,B,C,D,Eの6段階でランクが分かります。自分のプログラミングスキルを客観的に知りたいという方は是非チャレンジしてみてください。

http://paiza.jp