ピクシブには数多くのRails製プロダクトがあり、それらを各チームで開発しています。
各チームでの知見や悩み事を共有するRails系サービス互助会というものもありますが、今回はRailsアプリケーションを健康に保つための取り組みであるRailsプロダクト健康診断について、対談形式でご紹介します。
- トーカー紹介
- なぜRailsプロダクト健康診断をやることになったのか
- "健康診断"で行っていること
- igaigaさんからみた効果や所感
- 弊社プロダクトメンバーからみた効果や所感
- 「お客様の声」
- この先の発展の展望
- 最後に
トーカー紹介
nino マンガプロダクト領域のテックリードをしているninoです。
技術的には主にバックエンドを担当しています。Palcyの立ち上げやpixivコミックの開発に関わり、現在はpixivのマンガで面白いことをやっています。最近POからこういう記事がでましたが、他にも様々仕込んでいます。
この対談のいいだしっぺで、"主治医"の igaigaさん(@igaiga)と"患者"の1人でありこの取り組みの立ち上げに関わっています。igaigaさんは弊社ではBOOTHの業務委託として関わりを持ち、今では弊社のRailsプロダクト全体を見てくれている頼り甲斐のある主治医です。
igaiga フリーランスRailsエンジニアのigaigaです、Railsに関する著書を多数出版しています。著書はBOOTHでも頒布しているのでぜひご覧ください。
bash この対談では聞き手として参戦していますbashと言います。
ピクシブ勤務歴は2022年で10年目に入ります。「まじめなSE」をキャッチフレーズに、開発部門マネージャ、関連会社CTO、VP of Engineering、社内IT責任者など様々な立ち位置を歴任し、事業・技術・組織・文化・イベントなど、様々な取り組みの裏方を長くやってきました。
RubyまわりではRubyKaigiのスタッフやパネル登壇、地域Ruby会議の開催、RubyConfのLT参戦など色々やっておりました。
igaigaさんとは永和システムマネジメントさんが開かれていたオブラブのイベントが確かはじめての出会いで、その後様々なミートアップや、RWC2014での登壇連番など、公私ともにお世話になってます。
なぜRailsプロダクト健康診断をやることになったのか
bash 早速話を聞いて行きたいんですけども、そもそもなぜ"健康診断"をやることになったんでしょうか？
igaiga もともとピクシブさんとはBOOTH/pixivPAYの業務委託として参加していたんですが、担当範囲を広げてRailsプロダクト全ての相談役というポジションを任せてもらうことになったんですね。
ピクシブさんにはRailsプロダクトを横断して知見の共有や悩み事の相談をする仕組みがすでにあったので、そこに参加させてもらいつつ別の時間でRailsの更新情報やトピックなどを共有していました。
その取り組みを半年ほど続けていたんですが、ぶっちゃけ話すこと無くなったんですよねw
nino まぁそうですよねw
igaiga そこでよりよい形がないかをCTOのharukasan*1やテックリード数名と模索した結果、毎月プロダクトごとに診断してまわるのはどうか？ということになりましたね。
nino そうですね。igaigaさんには以前からBOOTHでお世話になっていたので、割と開発メンバーは十分自走できるレベルになっていたので、開発はなんとかなるなと思っていました。ただ、Railsのバージョンアップなどは大変で、なかなか時間取れない上に忘れがちになっていまうし、影響範囲が大きい分1人でやるのも不安があるんですよね。そういう課題感もあって、定期的にそこについて指摘してくれる人・アドバイスをくれる人がいるといいよね〜と。
そうして健康診断という形に落とし込まれて行きました。
"健康診断"で行っていること
bash 続いて、"健康診断"としてやっていることを伺っていきたいんですが、どういったことをやっていく感じでしょうか？
igaiga 事前にプロダクトを1つ決めてもらっているので、私の方でそのプロダクトのソースコードを一通り見て"カルテ"にまとめています。
時間が限られているので、Gemfile, configフォルダ以下など重要なところから読んでそれらの内容をコメントしていったりしながらカルテを書いていきます。
2回目以降の場合は前回のカルテの課題点を確認するのですが、課題を解決していることもよくあります。そんなときは「すごいですね！偉業ですね！」と正直に伝えています。
もしもできてなかったら、それは優先順位を考えれば普通であることも多いので、経過観察していく。そういうサイクルを回しています。
nino 実際の健康診断と同じだなと感じることも多くて、改善するのは本人とそのチームであって、主治医はアドバイスや現状を伝えてくれる人なんですよね。
意識高いメンバーや余力があるところだと爆速で解決してたりしますが、どうしても状況によってはpendingすることもある。
まさに健康診断。1プロダクトはだいたい半年に1回の頻度で健康診断が来るのですが、その間隔もちょうど良いなと思っています。1年だとRailsやRubyのバージョンアップに追いつきづらいと感じてます。
igaiga そうですね〜。ピクシブさんのRailsプロダクトが結構あるので、結果的にだいたい半年に1回になっていて、回していたらいい感じになってましたね。
あとは、問診というものをやっていて、"患者"から気になっていることや相談したいことを聞いて回答しています。過去には設計の話だったり、gemの選定などを相談してもらいました。
他の現場で得た知識を相互に共有したり、逆にピクシブさんの事例で学ぶこともあります。
nino 第三者から意見をもらえるのでとても助かっていますね。
自分で調べたことや方針があっているのかどうかを客観的に見れますし、後押ししてくれたり間違っていた場合は修正できるのがいいですね。
カウンセリングの効果もありそうだなと感じてます。
igaiga "患者"とはもちろん話すんですが、"保護者の方"のCTO harukasanとも3ヶ月に1回話しています。
話す内容としては、カルテと現状の報告、現場の困りごと、現場からCTOへの要望、Ruby業界動向などですね。「現場からCTOへの要望」はCTOへ直接話すのとも違って、現場の人たちも社外の人間であるigaigaへは話しやすいといった効果もありそうです。
現場をサポートするかたちでigaigaがいるので、更にお互いの納得度もってやりとりを補強できているんじゃないかなと思っています。
igaigaさんからみた効果や所感
bash この取組のきっかけってどういう流れから生えてきたんでしょうか？
igaiga 確かスタートしたのは2020年晩秋で、対象プロダクト数が7個。1つのプロダクトはおおよそ半年に1回の健康診断をやっていて、今日ちょうど3周したところで次回から4周目に入ります。思った以上にうまく回っているなという印象です。
はじめる前の私の悩みとして「自分の知識をプロダクトメンバーに伝え続けると知識が枯渇していく」という問題があって「2回くらいやったら何も貢献できることがなくなるのでは」と危惧していました。
実際には半年程間隔が空くとRailsやRubyの新バージョン情報やGemのobsolute情報など世の中が動いていくので、その時の最新状況を伝えて現場の問題の相談に乗るだけでもメリットがあるなと感じています。また、半年の間に新たに出てくる問題もいろいろありますし、解決する問題もあるので、解決が難しい問題はどうやって解決したのかを私も勉強させてもらっています。
nino そう思うと、プロダクト開発は生き物で、いつもみてると違いがみえないし、離れすぎると動いてないように見えるのかもしれません。その点で半年というのはまさに「健康診断」としてちょうどいいペースなのかも。
igaiga 現場のみなさんにとっては私以上にプロダクトコードについて詳しいですから、人間の健康診断で先生から「体重増えてますね」って言われて「それはわかってるんです！」という時と同じ気持ちになることもあると思います。それでも指摘点の改善を進めてくれたり、毎回いろんな話をしてくれて嬉しいです。
弊社プロダクトメンバーからみた効果や所感
nino igaigaさんから話していただいたとおりですね。加えて言うと、定期的に説得力ある方から発破かけてもらえるのがありがたいです。意図せず開発計画にメンテナンス系のことを入れそびれることがあったんですが、おかげで盛り込むことができました。
また、ホットなgemの情報など、コミュニティという生き物の状況をおしえてもらえるので、日々の開発でも助かっています。
例えば、rails6.2が出ずに7.0がでるよという、プロダクトを作っている者からみると地殻変動とも言える動きがあって、それにあわせた取り組みのアドバイスをいただきました。大きく開発計画にも影響がある大事なもので、現場、テックリード、CTOともに情報が伝わって、広く対応をスムーズに行うことができたということもありました。
igaiga 僭越ながら、効果としてはボトムアップでもトップダウンでもない、第三のムーブを社内に起こせているんじゃないかなと思ってます。
また、RubyやRailsのバージョンアップの全社的な目標を形成していけたんじゃないかなと思います。長生きなプロダクトが多くバージョンアップ時に必要な対応も多いこともあるので、事前に計画を立てて「EOLの時期から逆算すると最低限ここまでは進めたい」という計画案を私の方からも現場の方やCTOのharukasanにもお伝えしています。harukasanとこれは今年中にここまでやった方が良いよねという話をできていたので、現場のみなさんへお願いしやすかったですし、逆に現場のみなさんから人が足りない、大きな問題がわかった、といった話が出れば増員のお願いをはるかさんへもお伝えしていました。
bash コミュニティというと、わたし、harukasan、igaigaさんもコミュニティのご縁でしたよね。そういうつながりのがこのようなかたちで広がっていくこともまたコミュニティの広がりを感じますね。
「お客様の声」
nino 最前線のプロダクト開発メンバーから代表して2名から話を聞いてきたんですよ。
bash いい話ですね。
igaiga メンバーたちと話してて思うんですが、みんなプロダクト愛が強いですね。それはよいことで、だからこそメンテナンス可能な状態にいかしていくという両立は大事と考えてるし、悩みもしている。その点、igaigaはメンテナンス面から両立をお手伝いしてると思ってます。
nino igaigaさんの貢献価値は本当に高いと思っていて、とくに立ち位置からの客観性や様々なコンテキストをご存知な知見の広さが効いていると思っています。
この先の発展の展望
nino たいへん捗る取り組みでしたので、社内の様々な分野にも応用して広げていきたいと思ってます。社内では各事業や主要分野にテックリードが配置されているので、その集まりを通じて広げようと思います。
すでにiOSアプリ開発では健康診断が進んでいるので、その分野ともタッグ組んでやっていきたいですね。
igaiga 会社の垣根を超えてコミュニティはつながっているので、もっと会社間の垣根は低くできる可能性があると思っています。私はそこでお役に立てる立場にあることを気づいたので、もっと多くの情報や技術を流通させたいですし、また、そういう仕事がフリーランスの方々の仕事の種になっていけば、フリーランスの人たちも会社さんたちにもメリットがあるのではと思ってます。
最後に
実は、このインタビュー記事には書ききれなかったエピソードがたくさんあります。
Wantedlyからカジュアル面談エントリーができますので、興味がある方はぜひコンタクトいただければと思います
また、RubyアソシエーションスポンサーやRubyKaigi2022スポンサーなどのアクションも行っております。
カンファレンスやミートアップなどでピクシブメンバーと話す機会もあると思いますので、その際はこの記事を読んだよとお声がけくださいませ。
*1:igaigaさんとは高専カンファレンスなどで旧知の仲。
