オーケストラの指揮者は全ての楽器が演奏できるわけでは無いと思います。それでも楽譜を読みこんで、表現したい演奏のイメージを作り上げてメンバーを引っ張っていく姿に、プロジェクトのリーダーみたいだなと、ふと思ったのです。Amazonで探してみると、こういう本もありました。単行本この商品を含むブログを見る私はリーダーの仕事は主に3つであると考えています。一つは、プロジェクトの方向づけを行うこと、二つ目はリソースの最適配分、そして三つ目は人を動かすことです。自分のプロダクトチームを1つのオーケストラとして考えてみました。私はコードを書きませんが、プロダクトの進むべき方向を決めて、プロの演奏家である設計者やプログラマを束ねて、チームでプロダクトを良くしていく。リーダーは私の役割であり、目標を定め、優先順位を決め、基準を定めるのは私です。時には妥協することも必要で、その判断を現場で下します。それが自分の仕事であると定義付けしました。いう話を聞いて、モヤモヤした思いは消えませんでした。思い、プログラムを学び直すことにしました。作られていたため、Java8を学び直しているところでした。そのため、Javaに関するタグをフォローして、Qiitaをよく見ていました。いう記事を見て非常に焦りました。@tabbyzさんの記事に衝撃を受けました。qiita.com個人は個人。Railsが頭から離れませんでした。こんなに気になるのなら、一回やってみようということで、Java8の学習は資格取得程度に留め、Railsチュートリアルを学び始めることにしました。残業時間が60時間だろうが、リリース前だろうが、ひたすら毎日60分コードを書きました。土日は図書館で3~5時間くらいやっていました。学びについては、ブログで発信したり、Qiitaに記事を投稿したりしました。www.yokoyan.netqiita.comRailsチュートリアルを完走。~そして異動へ~半年ほどかけて、Railsチュートリアルを完走したある日のことです。なんと、自分のチームが会社の方針により、消滅することになりました。正確には、パッケージ開発部隊(私のチーム)と、導入部隊が統合されることになりました。導入部隊への異動という選択肢も考えましたが、もともと10年ぐらい所属した部署であるため、いまいちモチベーションが上がりませんでした。いう個人的事情から、今の職場に踏みとどまることにしました。あり、私がRailsチュートリアルを完走したと言う話をした結果、なんとそちらのチームに異動することになりました。そのチームがRailsとAWS両方ができるエンジニアを探していたということで、私に白羽の矢が立ったようです。人生、何があるかわかりません。自己変革が必要な時は突然やってきます。日頃の勉強は大事なのだなと実感しました。Railsと出会って変わった10のこと新しい働き方になった新しいプロダクトチームでは、働き方が全く異なっていました。チームメンバが片手で数えるほどしかいません。全員が正社員であり、ほぼ全員がプログラムを書き、GitHubにプルリクを上げて、お互いがソースレビューをします。ローカルの開発環境も、VagrantとAnsibleでほぼ自動化されており、手作業は皆無です。私が担当していたJavaのプロダクトでは、セットアップに2~5日かかっていたため、衝撃を受けました。私も作れるという自信と、安心感を手にすることができました。いうように変わりました。納期という概念がなく、リリースは自分達次第です。AWSのフルマネージドサービスをフルに使って、単一点障害を潰すことで穏やかな日常になりました。帰宅時間も自分でコントロールできるため、22時から18時になり、人生が変わりました。直近3年の残業時間を見ても、劇的に減っています。www.yokoyan.netSIerから見ると異常に高い生産性Railsを使うようになってから、開発の生産性が大きく上がりました。以下を組み合わせれば、レスポンシブデザインでそれなりの見栄えがする、単純なモデルの検索画面であれば、1日かからずに作ることができます。したので、この生産性の高さには衝撃を受けました。RailsはWEBサービスを開発するにはとてもよいフレームワークです。ためきっと採用されないだろうなと感じました。(見積工数が大幅に削減できてしまう=人数を抱えられなくなる)設計に関する考え方が変わったRailsでプロダクトを作るようになってから、設計に関する考え方が変わりました。要件さえあればプロダクトが作れてしまう柔軟性があるからです。その後は、エクセル方眼紙を使った基本設計や詳細設計という、SIerならではの設計作業は行いません。受託開発では設計工程の成果物(納品物)として、お客様に検収を頂くためにきれいな設計書を作りますが、自社サービスの場合は不要です。そもそも、私のチームには設計者はおらず、プログラマしかいません。仕様は書いたコードを読めばわかるようにするために、リーダブルコードを意識してコードを書きます。設計するよりも、要件を満たすためにいきなりプログラムを書き始めます。要件を満たすために書いたプログラムはだいたい汚いので、その後リファクタリングを行います。その過程で、「ここはもっとこうした方がいいんじゃないか?」という議論があり、DB定義から丸ごと変えたりすることを繰り返していきます。ウォーターフォールで外注を使って開発を進める受託開発では、このような進め方は無理です。これは、ジャバ・ザ・ハットリさんが書かれている考え方に近いと感じました。tango-ruby.hatenablog.comほとんどは全体的な方針とAPIを決定して、まずコードを書く。書き始めると仕様を変更した方がいい箇所が出てくる。エンジニアが独自の判断で変更をかけていく、という流れだ。カンタンに言うと「作りながら変更しながら完成させる」という感じだ。上流様から「テメー、ぷろぐらまーのクセに上流様が書いたキレいな仕様書を変更すんじゃねー」なんて絶対に言われない。してコードを書く人が考えて、よい設計に改良していくのが本来の仕事だからだ。1人のプログラマが担う領域が増えたコードを書くだけがRailsエンジニアではありません。Railsを起点として、新しい技術に触れる機会が多くなりました。Railsでプロダクトを開発する場合、ソース管理はGitであることがほとんどだと思います。管理するということはあまりないでしょう。Railsを開発する場合、そのままWindows上で開発を行うのではなく、VagrantでUbuntuを入れたりすることが多いと思います。継続的インテグレーションの環境を整えたり、デプロイの方法も考える必要があります。クラウド上にStaging環境やProduction環境を整えたり、NginxやUnicornの設定も避けられません。できる限り楽をするために、ChefやAnsibleなどを使って環境毎にプロビジョニングしていきます。単純にRubyのコードを書くだけではなく、管理以外は全部やるようになりました。言わずもがなですが、RailsはGemを使って簡単に機能が拡張することができます。ログイン関係であればDeviceが鉄板でしょう。その一方で、Gemの中身がどういうことをしているのか、深く理解しないまま使うと痛い目を見ることがあります。いう時は、公開されているソースを熟読することで理解を深めることができます。結果、Gemを使う時はGitHub上のソースを見るようになりました。非常に勉強になります。人間力だけのリーダーでは厳しいと思うようになった実体験も踏まえて、実装経験が3年程度しかない状況でリーダーになるというのは、もったいないと感じています。私が考えるリーダー像は、指揮官先頭で、口だけではなく、いざという時に自分の手を動かせるリーダーです。今後、私もまたリーダーのポジションになる機会があるかもしれませんが、まずは実装の経験を10年積みたいと思います。Railsを学んだことで見えてきたフルスタックエンジニアというキャリア私は、AWSも大好きです。それと同じぐらいRailsも大好きです。いうキャリアが見えてきました。45歳くらいまではこの方針で行きたいと思っています。アウトプット量が増え、反応をいただくようになったRailsチュートリアルの学習をきっかけに、Markdownで文章を書く機会が格段に増えました。結果、ブログやQiitaへの投稿も増えてきました。外部でライトニングトークをする機会もありました。