はじめに
この記事は、Ruby on Rails Advent Calendar 2018の12日目の記事です。
SIerで働く35歳のエンジニアが、Railsと出会って変わったことについて書きます。
私のこれまでの経歴
- 文系新卒でパッケージベンダっぽいSIerに入社
- 現在14年目ぐらいです
- 入社1年目から3年目ぐらいまでは、プログラマとしてVisual Basic 6.0や Java 1.4を書いていました
- 入社4年目からは、プロジェクトリーダーとして、自分の案件を回すようになりました
- 入社9年目くらいからは、製品開発部門へ異動し、プロダクトリーダーとして製品開発を行ってきました
- 昨年からWEBサービスの開発チームに異動しました
- 現在はRailsプログラマとして自社Webサービスの開発に携わっています
- AWSの設計実装、DB設計、CI構築などもします
- データベースに関する本を2冊書きました。10冊本を出すことが夢です。
- 作者: 石橋潤一,横山弘典
- 出版社/メーカー: 翔泳社
- 発売日: 2008/07/04
- メディア: 単行本
- クリック: 19回
- この商品を含むブログ (1件) を見る
- 作者: 高山昌悟,横山弘典
- 出版社/メーカー: シーアンドアール研究所
- 発売日: 2015/01/24
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
ずっと感じていた漠然とした不安
前述の通り、私の勤務先はSIer です。自社パッケージ製品を持っており、パッケージのカスタマイズを受託開発で行うことがメインの事業です。Railsと出会うまで、私は自社パッケージのプロダクトリーダーを数年やっていました。
主な業務内容としては、以下でした。
- プロダクトの改修計画の立案
- 見積
- 開発原価作成
- 実行予算作成
- リソースヒスト作成
- 人の調達（社内、社外）
- ガントチャート作成/進捗管理
- 課題管理
- 社長や関係部署との交渉や根回し
- チームの開発環境改善
- Selenium導入
- AWS導入・設計・構築
- Jenkins導入
- Chef導入
インフラに関する作業もあわせて行っていましたが、コードは書いていない状況が数年続いていました。 私のチーム内には、私以外に年上で経験も豊富な 製造リーダーと設計リーダー がおり、正直、彼ら二人がいれば製品開発の実務には問題ないのでは、、、という体制でした。
私の上司は、設計者とプログラマだけでは製品開発はできない という事をよく仰っており、ビジネスレイヤを考えるのが私の役目なのだろう と思いましたが、そこを考えるのは プロダクトオーナーである社長 だったり、パッケージ導入部門の強い要求 だったりで、私一人の意見でプロダクト開発を推進することはなかなか難しい状況でした。
・・・。
なんと言うか、自分の仕事は隙間を埋める仕事というか、チーム全体が円滑に動くための裏方、みたいな立ち回りで、自分の仕事は一言でこれである！！と言えず、モヤモヤしながら仕事をしていました。モノを作っているという実感が得られず、このままずっと社内の調整役なのだろうかと、漠然とした不安がありました。
今にして思えば、それがリーダーの仕事なのだと思います。ただ、当時の私は、「私、チームに不要では？」 という悶々とした思いを抱えていました。
コードが書けない奴が美しい設計書なんて書けるわけない
そんなある日、AWSのユーザーグループであるJAWS UGが主催する大規模イベント AWS DAYS 2016 で、ハンズラボの長谷川さんのイベントに参加して 衝撃を受けました。
セゾンの小野さんが 「SIerでは、3年ぐらいしかプログラムを書いていないのに、すぐに進捗管理や課題管理に進むエンジニアがいる」 という話をされていて、「ああー！！これ自分のことだわ！！！」 と、非常に耳が痛かった記憶があります。
特に、中嶋聡さんの「ソフトウェアの仕様書は料理のレシピに似ている」というブログ に感銘を受けたというお話をされていたのが、とても心に刺さりました。
自信を持って言えるのだが、「どんなに優秀なエンジニアでも、決してプログラムを自分自身で書かずに良い詳細仕様を作ることは出来ない」という絶対的な法則があるのだ。
プログラムの仕様書は料理のレシピに似ている。ソフトウェアのアーキテクトが自らプログラムを書いたり、下っ端のエンジニアの書いたコードをレビューするのは、レストランのシェフが自ら料理をしたり、下っ端の料理人の作ったスープの味見をするとの同じである。
シェフがレシピだけ書いてキッチンにも立たないレストランには行きたくないし、ましてや自分で料理したこともないシェフが書いたレシピを元に作った料理がおいしいわけがない。
自分で鍋をふったことがない人はレシピを作ることはできない。ソフトウェアも同じで、コードが書けない奴が美しい設計書なんて書けるわけ無いだろ！！ というお話でした。
このお話はずっと気になっていて、やはり自分も立場はどうあれ、コードを書かないとダメだな と手帳に書き留めていました。
オーケストラの指揮者のようなリーダーになろうと思っていたこの頃
コードを書かない自分がどのようにチームを束ねていくべきか。自分なりに悩んで考えて出した答えは、オーケストラの指揮者 でした。
たまたま妻と二人でオーケストラの生演奏を聴く機会があり、オーケストラの指揮者とプロジェクトのリーダーって似てるのでは？ と仮設を立てました。
オーケストラの指揮者は全ての楽器が演奏できるわけでは無いと思います。それでも楽譜を読みこんで、表現したい演奏のイメージを作り上げてメンバーを引っ張っていく姿に、プロジェクトのリーダーみたいだなと、ふと思ったのです。
Amazonで探してみると、こういう本もありました。
成功するチームの作り方 オーケストラに学ぶプロジェクトマネジメント
- 作者: 増田智明
- 出版社/メーカー: 秀和システム
- 発売日: 2017/04/21
- メディア: 単行本
- この商品を含むブログを見る
私はリーダーの仕事は主に3つであると考えています。一つは、プロジェクトの方向づけを行うこと、二つ目はリソースの最適配分、そして三つ目は人を動かすことです。
自分のプロダクトチームを1つのオーケストラとして考えてみました。私はコードを書きませんが、プロダクトの進むべき方向を決めて、プロの演奏家である設計者やプログラマを束ねて、チームでプロダクトを良くしていく。
リーダーは私の役割であり、目標を定め、優先順位を決め、基準を定めるのは私です。時には妥協することも必要で、その判断を現場で下します。それが自分の仕事であると定義付けしました。
レベルが高いオーケストラのメンバーは指揮者がいなくても、演奏ができる という話を聞いて、モヤモヤした思いは消えませんでした。
それでも、プロダクトをより良いものにするために、コードや設計のレビューにももう一歩踏み込んで関わりたい、現場のメンバーと深く議論したい と思い、プログラムを学び直すことにしました。
業務で全く使わないRailsを学んでみようと思ったきっかけ
当時、たまたま自分が担当しているパッケージが Java で作られていたため、Java8を学び直しているところでした。そのため、Javaに関するタグをフォローして、Qiitaをよく見ていました。
ある日、Qiitaでエンジニアではない人たちが、次々とRailsでWebサービスを開発している という記事を見て非常に焦りました。
特に、@tabbyzさんの記事に衝撃を受けました。正直、悔しかったです。
個人は個人。自分はJavaの学習をがんばろう、と思い直してみましたが、ノンプログラマーであると自称している人達がWebサービスを作っているという Railsが頭から離れませんでした。 こんなに気になるのなら、一回やってみようということで、Java8の学習は資格取得程度に留め、Railsチュートリアルを学び始めることにしました。
残業時間が60時間だろうが、リリース前だろうが、ひたすら毎日60分コードを書きました。土日は図書館で3~5時間くらいやっていました。 学びについては、ブログで発信したり、Qiitaに記事を投稿したりしました。
Railsチュートリアルを完走。~そして異動へ~
半年ほどかけて、Railsチュートリアルを完走したある日のことです。
なんと、自分のチームが会社の方針により、消滅することになりました。
正確には、パッケージ開発部隊(私のチーム)と、導入部隊が統合されることになりました。導入部隊への異動という選択肢も考えましたが、もともと10年ぐらい所属した部署であるため、いまいちモチベーションが上がりませんでした。また、転職という可能性 も頭をよぎりましたが、最愛の息子が産まれた直後であったため、仕事よりも育児に比重を置きたい という個人的事情から、今の職場に踏みとどまることにしました。
そんな中、Railsで新しい自社サービスを開発しているチーム があり、私がRailsチュートリアルを完走したと言う話をした結果、なんとそちらのチームに異動することになりました。
たまたまそのチームがRailsとAWS両方ができるエンジニアを探していたということで、私に白羽の矢が立ったようです。
人生、何があるかわかりません。
自己変革が必要な時は突然やってきます。だからこそ日頃の勉強は大事なのだなと実感しました。
Railsと出会って変わった10のこと
新しい働き方になった
新しいプロダクトチームでは、働き方が全く異なっていました。SIerではなく、いわゆる WEBサービス系の企業に近い働き方 になりました。まず、チームメンバが片手で数えるほどしかいません。全員が正社員であり、ほぼ全員がプログラムを書き、GitHubにプルリクを上げて、お互いがソースレビューをします。
ローカルの開発環境も、VagrantとAnsibleでほぼ自動化されており、手作業は皆無です。私が担当していたJavaのプロダクトでは、セットアップに2～5日かかっていたため、衝撃を受けました。
またステージング環境やプロダクション環境のAWSは、私がほぼ一人で設計構築をしており、いい意味でやりたい放題できるという素晴らしい環境 になりました。
コード中心の業務内容
私も作れるという自信と、安心感を手にすることができました。
これまでの業務内容は、管理業務が9割、AWSのインフラ構築が1割ぐらいの比率でしたが、今では プログラミングの比率が7割、 AWSインフラの割合が3割 というように変わりました。
私の場合、転職ではなく、同じ会社内で異動しただけなのですが、普段から使う技術が変わるだけでこんなにも働き方が違う のだなと驚きました。
帰宅時間
納期という概念がなく、リリースは自分達次第です。AWSのフルマネージドサービスをフルに使って、単一点障害を潰すことで穏やかな日常になりました。帰宅時間も自分でコントロールできるため、22時から18時になり、人生が変わりました。
直近3年の残業時間を見ても、劇的に減っています。
SIerから見ると異常に高い生産性
Railsを使うようになってから、開発の生産性が大きく上がりました。 例えば、以下を組み合わせれば、レスポンシブデザインでそれなりの見栄えがする、単純なモデルの検索画面であれば、1日かからずに作ることができます。
- Rails
- ActiveRecord
- Slim
- Bootstrap
- Ransack
Java でプロダクトを作っていた時は、検索系の機能が5日から10日、更新系の機能が20日ぐらいという見積 でしたので、この生産性の高さには衝撃を受けました。
RailsはWEBサービスを開発するにはとてもよいフレームワークです。一方で、SIerの受託開発の現場では、採用されると工数が稼げなくなる ためきっと採用されないだろうなと感じました。（見積工数が大幅に削減できてしまう＝人数を抱えられなくなる）
設計に関する考え方が変わった
Railsでプロダクトを作るようになってから、設計に関する考え方が変わりました。 要件さえあればプロダクトが作れてしまう柔軟性があるからです。今のチームでは、プロダクトの要件は、Markdownで GitHub Issue に書くことが多いです。その後は、エクセル方眼紙を使った基本設計や詳細設計という、SIerならではの設計作業は行いません。受託開発では設計工程の成果物(納品物)として、お客様に検収を頂くためにきれいな設計書を作りますが、自社サービスの場合は不要です。
そもそも、私のチームには設計者はおらず、プログラマしかいません。 仕様は書いたコードを読めばわかるようにするために、リーダブルコードを意識してコードを書きます。
設計するよりも、要件を満たすためにいきなりプログラムを書き始めます。 要件を満たすために書いたプログラムはだいたい汚いので、その後リファクタリングを行います。その過程で、「ここはもっとこうした方がいいんじゃないか？」という議論があり、DB定義から丸ごと変えたりすることを繰り返していきます。上流・下流という考え方はなく、フラットな感じ です。
ウォーターフォールで外注を使って開発を進める受託開発では、このような進め方は無理です。これは、ジャバ・ザ・ハットリさんが書かれている考え方に近いと感じました。
ほとんどは全体的な方針とAPIを決定して、まずコードを書く。書き始めると仕様を変更した方がいい箇所が出てくる。で、エンジニアが独自の判断で変更をかけていく、という流れだ。カンタンに言うと「作りながら変更しながら完成させる」という感じだ。
上流様から「テメー、ぷろぐらまーのクセに上流様が書いたキレいな仕様書を変更すんじゃねー」なんて絶対に言われない。 むしろそうしてコードを書く人が考えて、よい設計に改良していくのが本来の仕事だからだ。
1人のプログラマが担う領域が増えた
コードを書くだけがRailsエンジニアではありません。Railsを起点として、新しい技術に触れる機会が多くなりました。 Railsでプロダクトを開発する場合、ソース管理はGitであることがほとんどだと思います。VSS や SVN で管理するということはあまりないでしょう。 また、Windows 端末で Railsを開発する場合、そのままWindows上で開発を行うのではなく、VagrantでUbuntuを入れたりすることが多いと思います。(そもそもMacで開発する企業が多いと思いますが)
また、Circle CI などで継続的インテグレーションの環境を整えたり、デプロイの方法も考える必要があります。クラウド上にStaging環境やProduction環境を整えたり、NginxやUnicornの設定も避けられません。できる限り楽をするために、ChefやAnsibleなどを使って環境毎にプロビジョニングしていきます。
単純にRubyのコードを書くだけではなく、管理以外は全部やるようになりました。
人が書いたコードを読むという習慣
言わずもがなですが、RailsはGemを使って簡単に機能が拡張することができます。ログイン関係であればDeviceが鉄板でしょう。 ただその一方で、Gemの中身がどういうことをしているのか、深く理解しないまま使うと痛い目を見ることがあります。そういう時は、公開されているソースを熟読することで理解を深めることができます。
結果、Gemを使う時はGitHub上のソースを見るようになりました。 また、チーム内のプルリクのソースレビューを繰り返すことで、人が書いたコードを読むという習慣 が身につきました。非常に勉強になります。
人間力だけのリーダーでは厳しいと思うようになった
実体験も踏まえて、実装経験が3年程度しかない状況でリーダーになるというのは、もったいないと感じています。私が考えるリーダー像は、指揮官先頭で、口だけではなく、いざという時に自分の手を動かせるリーダーです。役職はどうあれ、 プロとしてプログラムに関する仕事をするのであれば、10年単位で実装した経験が必要なのではないか と考えています。
今後、私もまたリーダーのポジションになる機会があるかもしれませんが、まずは実装の経験を10年積みたいと思います。
Railsを学んだことで見えてきたフルスタックエンジニアというキャリア
私は、AWSも大好きです。それと同じぐらいRailsも大好きです。この二つを組み合わせて、Rubyでコードが書けるフルスタックエンジニア というキャリアが見えてきました。45歳くらいまではこの方針で行きたいと思っています。
アウトプット量が増え、反応をいただくようになった
Railsチュートリアルの学習をきっかけに、Markdownで文章を書く機会が格段に増えました。結果、ブログやQiitaへの投稿も増えてきました。外部でライトニングトークをする機会もありました。
www.slideshare.net
アウトプットを続けた結果、Railsチュートリアルのトップページにユーザーの声として掲載 されたりしました。本当に有り難いです。
35歳前後の人にこそRailsの学習はおすすめ！
35歳前後のエンジニアの方は、私のようにプロジェクト管理が主たる業務である人が少なくないと思います。また、エンジニアは35歳限界説 という言葉があり、技術よりも管理の方が重視されるという会社もあると聞きます。
ただこの2年でRailsに触れて思うことは、プログラムが書ける方が業務により深みが増す ということです。コードを書くということは、エンジニアとしての キャリアを積んでいく上での土台になる と考えています。私はこの土台が十分ないままにリーダーになってしまったため、漠然とした不安をずっと抱えていたのだと思っています。
社会人になり、10年以上が経過している方にとって、新しい技術を学び直すきっかけとして、Railsはオススメです。
思い出した自分の夢
最後に、この記事を書いていて、小学校の頃の夢 を思い出しました。私は小学校5年の頃に、「大人になったら何になりたいか」 という文集にゲームプログラマーになってドラゴンクエスト10を作りたいと書きました。(当時はスーパーファミコンでドラクエ5が大流行していました)
残念ながら、ドラクエ10はもう世の中に出てしまったわけですが、その時の思いがどこかに残っていて、結果的にプログラムを書く仕事をしています。
自分の夢をシンプルに言うと、プログラムで何かを作る人になりたいです。
Rails(というよりRuby)は、ワクワクしながらコードを書くことができる素晴らしいフレームワークです。Railsとクラウドを組み合わせれば、自分が良いと思う冬サービスを比較的簡単に世の中に出すことができるでしょう。私も世の中の一隅を照らすような、世の中を少しでも便利にできるウェブサービスをリリースしたいと考えています。
Railsと出会うことで、再びプログラムを書く楽しさを思い出しました。
本当にありがとうRuby on Rails！
おわりに
ということで今回は、35歳のエンジニアがRailsと出会って人生が変わった話について書きました。長文のポエムを最後まで読んでいただきありがとうございました。私と歳が近いエンジニアの方の参考になれば幸いです。
明日のアドベントカレンダーは、@iwtnさんです！
