はじめに
この記事は、Qiita Rails Advent Calendar 20日目の記事です。
2017年にRails チュートリアルを学んでから、約3年経過しました。35歳で初めて Rails を学んでからプロダクトリーダーになるまでの私のキャリアを振り返りたいと思います。
自己紹介
SIer企業で14年ほど働いています。現在はRailsで構築したサービスのプロダクトリーダーをしています。35歳になる年に初めて Rails チュートリアルと出会い、人生が良い方向に変わりました。RubyとRailsにはとても感謝しています。
35歳 Rails 1年目
私はもともと 受託開発の部署を7年ほど経験し、Java のプロダクトのリーダーをしていました。進捗管理と課題管理だけを行うリーダーで、プログラムは書けませんでした。自分で実装できないというコンプレックスもあり、35歳になる年に独学で、業務に全く関係のない Rails チュートリアルを学びました。その後、突然自分のプロダクトチームが解散になり、 Rails でプロダクトを作るチームに異動になりました。
この辺の話は、2018年のアドベントカレンダーに投稿させていただきました。 よろしかったらこちらの記事もご覧ください。
私が Rails チュートリアルを学習して身につけた習慣は、自分の学びをアウトプットするということです。
2017年に自分が学んだことをQiitaや本ブログに投稿していたのですが、2020年の現在でも LGTM して頂く方がおり、大変ありがたく感じています。一時期、Railsチュートリアルのタグで1位にもなりました。
アウトプットする理由は主に自分のためなのですが、自分のために書いた記事が、他の誰かの役に立つということはとても嬉しく思います。広いインターネットにおいて誰か一人でも役に立つことができたのなら本望です。これからも世の中の一隅を照らせたら嬉しいです。
36歳 Rails 2年目
Rails プロダクト開発チームに異動してから2年くらいは、 Rails のコードを書いたり、 AWS の設計や実装をメインで行いました。一昔前はプログラマ35歳定年説という言葉を聞くこともありましたが、自社プロダクト開発においては全く関係ないと感じます。
プログラマとしてプロダクト開発に参加できたのはとても楽しかったです。時間が経つにつれて関わるプロダクトも増え、2つのRailsプロダクト開発に携わりました。1つはゼロベースでの新規プロダクト立ち上げだったため、非常に良い経験をさせていただきました。
Rails は作りながら考える試行錯誤が行いやすいフレームワークだと感じています。特に、新規のプロダクト開発は、実装面でもビジネス面でも試行錯誤が多いため、Railsが向いていると感じています。
その後、新規プロダクト開発は、試行錯誤を繰り返した結果、色々あってチームが解散になりました。そして、開発チーム内の編成がガラッと変わりました。
37歳 Rails 3年目
Rails プロダクトのチームに異動した時もそうでしたが、キャリアの変化の時期は急に訪れました。開発チームのプロダクトリーダーが変わることになり、私がプロダクトリーダーを引き継ぐことになりました。おそらく、私がリーダーの経験があったためだと思われます。
プロダクトリーダーの話を受けた時は、最初は複雑な気持ちでした。コードを書く時間が減ることが予想されたためです。上司と面談した際に、私の目指すキャリアはどちらなのかと聞かれました。
- エンジニアリングチーム内で技術をリードしていきたいのか？
- エンジニアリングチームと営業チームをまとめてプロダクトをリードしていきたいのか？
少し迷いましたが、私は後者を選びました。昔のように進捗管理と課題管理だけを行うリーダーではなく、今の自分なら、エンジニアリングチームが動きやすくするために、技術的に支援することができるのではないかと考えたからです。 そして、プロダクト開発はあくまでも世の中の課題を解決する手段であり、自らビジネスの方向性を考えたいと思うようになりました。
ここからビジネスと技術の両方をリードできるプロダクトリーダー（マネージャ）を目指すことになりました。
プロダクトリーダーになってから最初に着手したことは、ロードマップの作成です。これまでは数ヶ月単位で開発プロジェクトを立てており、リリースも数ヶ月単位という運用でした。SaaSとしてはリリース頻度が少なかったです。
お客様の要望や、自分たちが作りたい機能をできる限り素早くリリースできるようにするために、2週間単位でデプロイしていく方針を決めました。理想は毎週リリースしていくことだったのですが、チームメンバーが最小限の人数になってしまったため、できることには限りがありました。
それでも残ったメンバーと協力して、Production 環境に継続的にデプロイしていくことを続けてきました。
38歳 Rails 4年目(現在)
プロダクトリーダーという仕事は面白いです。 事業作り、チーム作り、技術のすべてに関わることができます。ユーザーの皆さんに愛されるプロダクトにしていくためにはどうしたらよいかをチームで考え、その結果、事業として利益が出るのかを追求していくという、とてもやりがいがある仕事です。
エンジニアリングチーム作り
it 業界は転職もしやすく、様々な事情で人が入れ替わることはよくあります。去年のデベロッパーズサミットではてなのだいくしーさんから、10年続くプロダクトチームを運営していくという話に感銘を受けました。
この話を聞いて以来、 チーム内のスキルマップを作成するようになりました。リリース日当日に、KPTの振り返りを行い、チームメンバー全員でスキルマップを更新することを続けています。
私はリーダーの役目は3つあると考えています。プロジェクトの方向づけ、 資源の最適配分、人を動かすこと、です。
プロジェクトの方向づけ
前述した通り Rails は試行錯誤を行うことがやりやすいフレームワークです。要件さえあればプログラムを書くことが可能です。私のチームでは今後の大まかなロードマップを作成した後は、最大1ヶ月単位でプロジェクトを管理するようにしています。アジャイル開発手法であるスクラムでも、スプリント期間は最大1ヶ月まで、という話を聞いたので妥当な期間だと考えています。
1ヶ月の間で何をやるかは、 Github project で管理しています。やるべきタスクや要件を Github issue に登録してメンバーをアサインしていきます。
開発期間の1ヶ月が終了したタイミングで、上司や関係者各位にデモを行い、フィードバックを受けるようにしています。新製品を開発する場合はこのサイクルは非常に有効だと感じています。
すでに Production 環境にデプロイしているプロダクトについては、 数週間以内にリリースできるように調整を行います。
資源の最適配分
リーダーとしてヒト、モノ、カネ、情報をコントロールするようにしています。
ヒトの管理
Railsはフルスタックフレームワークであるため、開発メンバーは少人数で開発することができます。自分で Ruby と Rails ができる人材を育成して、私よりプログラムが書ける人にどんどん任せるようにしています。最近の若い子は本当に優秀なので助かっています。
人材育成には自ら経験した Rails チュートリアルを採用しています。法人プランを導入させていただいた所、ありがたいことに開発元のYasslabさんからインタビューを受けました。
プロダクトリーダーを引き受ける前に懸念していた通り、自分がプログラムを書く時間は減りました。しかし、今の自分に求められている役割は、プロダクトリーダーであり、プログラマではありません。プログラマとして実装だけ行っている間はとても楽しかったですが、言われたことだけを実装するのはリーダーではないと考えています。
現在では、プロダクトの機能開発はメンバーに任せ、自分は仕様の策定とプルリクエストレビューに専念するようにしています。ただ全てをメンバーに任せているわけでもなく、 リファクタリングの相談を受けるようにしています。
モノの管理
モノの管理については、開発メンバーの生産性が上がるように努めています。具体的には、 有償の開発ツールを購入する調整をしたり、 git Branch作成のルールや、pull request のマージ基準を定めたり、リンターの導入、Circle CI のビルド時間短縮、 AWS の開発基盤を整えたりしています。
カネの管理
カネの管理は、プロジェクトの開発原価と実行予算を作成し、会社が定めた予算内に収まるよう メンバーの稼働状況をコントロールしたりしています。お金の管理に厳密さを求められるのは SIer 企業ならではかもしれません。
情報の管理
4つ目の情報の管理は一番大事だと考えています。私の勤務先は Ruby の技術者が少ないため、 社内だけで得られる情報には限りがあります。開発中に技術的に行き詰まった場合、自ら Ruby や Rails の社外コミュニティに赴き、参加者の方々と技術的な相談をさせていただきました。新型コロナウイルスの影響により、今年はオフラインでのコミュニティに行けなくなってしまいましたが、コミュニティ Slack などを使って相談させていただくこともあります。いつも本当にありがとうございます。
コミュニティへの恩返しとして、 自分がRubyやRails を使ったプロダクト開発で経験したことや学んだことを発表しようと考えるようになり、Ruby Business Users Conference 2019で 登壇させていただきました。
コミュニティへの参加を通して、Rubyのパパである Matzさんや、Rails チュートリアルを提供されている安川さんに直接お会いすることができたのもとても嬉しかったです。
人を動かす
リーダーとして一番気をつけていることは、リーダーは役割であり、立場ではないということです。つまり、メンバーとの関係性はフラットです。 私はメンバーの上司ではありません。私のチームのメンバーは若い子が多いため、私のことを上司と勘違いすることがあるのですが、 たとえ新人であっても、関係性はフラットであるということを最初に伝えています。そして私がメンバーに期待していることを、出来る限り言葉で伝えるようにしています。
上記の内容を強く意識しているため、 メンバーは年齢関係なく、敬意を込めて「さん」付けで呼びます。 Rails プロダクトは少人数で開発することが多いですが、全員がそれぞれの役割を意識して、最軽量のマネジメントで主体的に動けるチームを作っていきたいと考えています。
今後やりたいこと
お客様の要望を素早く開発して、デプロイしていきたいと考えています。また、今のプロダクトの構造がモノリシックであるため、今後はマイクロサービス化していきたいと考えています。
最近参加した Ruby World Conference 2020で DHH 氏が Ruby と出会ったことで、自分のやりたいことに全力で打ち込めるようになった、という話をされていました。
Ruby も Rails も触れていてとても楽しい技術です。毎年この時期になると、なぜかRubyやRailsは死んだと言われますが、Web サービスを素早く開発してリリースして改善していくというサイクルを回すためには、まだまだ Rails が必要だと感じています。
現在携わっているプロダクト以外にも、自分で考えた新製品の構想があるため、自分の手で実現していきたいです。これからもプロダクトリーダーとして Ruby や Rails を使って世の中を便利にする良いプロダクトを作り続けていきたいと思います。
まとめ
今回は2年前に投稿したアドベントカレンダーの記事の続編というイメージで、自分のキャリアの棚卸しをしてみました。 長文のポエムを最後まで読んでいただきありがとうございました。私の体験談が誰かのお役に立てれば幸いです。
明日のアドベントカレンダーは、 Teruhisa Fukumoto さんです。
