はてなで働くエンジニアにアンケートシリーズ第17回は、マンガアプリチームのiOS/Androidアプリエンジニア、id:ikesyoに話を聞きました。
本名から読みやすさ重視ではてなid化
── Q. はてなidとその由来を教えてください
本名が池田 翔(いけだ しょう)で、呼びやすく「だ」だけを抜いた「いけしょう」をあだ名化・id化しました。
ローマ字表記では「しょう」はSho
になるので、本来ならikesho
にするところですが、h
の字面がなんとなくしっくりこなかったのでそこだけy
に変更して、ikesyo
になりました。h
だとのっぺりした印象なのが、y
だと少しシュッとした感じになるので気に入っています。日本語で呼ぶ時は「いけしょー」と長音符で呼ばれることを想定しています。
フリーランス時代に勉強会で声を掛けられたのが入社のきっかけ
── Q. いつどんなきっかけで入社されましたか?
はてなには2016年1月に中途採用で入社しました。なので、もうすぐ入社から5年半になりますね。
入社以前は新卒採用から2社を経験した後に、4年半ほどフリーランスのiOSアプリ開発者をしていました。そのフリーランス時代の2014年中頃から「Cocoa勉強会関西」や「ReactiveCocoa勉強会関西」、「関西モバイルアプリ研究会」などの勉強会に参加したり発表したりするようになりました。それらのコミュニティに参加する中で、はてな社員のid:cockscombさんやid:yashigani_wさんらと交流するようになり、声を掛けてもらったのが入社のきっかけです。
はてなには以前から興味がありましたし、京都でiOSアプリの開発ができるということ、勉強会で楽しく有意義な議論ができるこの人たちと一緒に働けるのはきっと楽しいだろうと思い、採用選考を受けることを決め、無事入社に至りました。
iOSもAndroidも担当するが、専門性としては「iOSアプリ」「Swiftが得意な人」
── Q. 現在の仕事を教えてください
マンガアプリチームでスマートフォンアプリケーションエンジニアをしています。業務ではiOSアプリとAndroidアプリのどちらの開発も担当することがありますが、個人の専門性としては「iOSアプリ」「Swiftが得意な人」になります。
直近で担当しているアプリでは、SwiftUIを本格採用した開発に取り組んでいるところです。別タスクを担当しているチームメンバーのコードレビューや、シニアエンジニアとしてメンティーとの1on1などもしています。
チーム異動経験を生かして「架け橋的な役割」を意識
── Q. チーム内の立ち位置を教えてください
2018年11月のチーム発足からテックリードを任せてもらっていましたが、2020年8月にid:kouki_danさんへテックリードを交代しました。いろいろなメンバーにテックリード経験を積んでもらいたいのと、2020年8月〜2021年1月までレンタル移籍のような形で一時的に別チームに異動することになったためです。
2021年2月にマンガアプリチームに復帰してからは、iOSアプリもAndroidアプリもどちらもそつなくこなせる1エンジニアとして、テックリードを支えながらチーム全体の様子を気に掛けるようにしています。
シニアエンジニアとしての立場やこれまでのチーム異動経験から、他のチームの様子や技術的なトピックを紹介したり輸入したりと、架け橋的な役割も意識していますね。
── Q. 1日の仕事の流れを教えてください
午前中はミーティングが入ることが少ないので、コードレビューをしたり、前日のタスクの続きをしたりしながらエンジンを掛けていきます。
はてなでは昼休みの標準的な時間は13時〜14時なんですが、コロナ禍で自宅勤務をするようになってからは、お昼ご飯は家族とタイミングを合わせて12時過ぎには食べるようにしています。13時過ぎからチームの昼会が始まる14時半までの1時間ちょっとが、割り込みの少ない集中できる時間になっています。
昼会を含めて、なるべくお昼過ぎから夕方にミーティングを固めるようにしているので、その時間帯はコードを書くことよりも会話をしたり、調査や検討をしたりすることが多いでしょうか。そこから終業までの残りの時間はSlackの様子を伺いつつタスクを進めて1日が終わる、という感じです。
Renovate、GitHub Actionsの導入を推進し、チームに根付いてきた
── Q. 最近うまくいったことは何ですか?
うまくいったというか、うれしかった話としては、先述の一時的なチーム異動の際に開発に参加していた新サービスの『マンガノ』が無事にリリースを迎えたことです。この時はこれまでのスマートフォンアプリ開発から離れて、半年間だけWebアプリケーションの開発にチャレンジさせてもらいました。
実際のサービスリリースを迎える前に異動期間が終了してしまい、リリースまで見届けることができなかったのが心残りではあったんですが、リリース当日にはGoogle Meetでビデオ会議をしながらのリリース作業に少し顔を出させてもらい、みんなでワイワイしながら一体感を感じられたのが良かったですね。
また、最近というには少し期間が広いのですが、ここ1~2年でRenovateという依存性アップデートの自動化ツールや、GitHubが提供するCI/CD環境であるGitHub Actionsの導入を推進し、それが社内の各チームに根付いてきました。
── Q. RenovateとGitHub Actionsの話について教えてください
まずRenovateについてです。Renovateによって、使用している依存性の更新の検知・アップデートするプルリクエストの作成・プルリクエストへの変更内容の記載(CHANGELOGやリリースノートの転記)といった作業が自動化できるようになりました。
もちろん動作確認や、ビルド・テストが通らなくなった時の修正などは必要なので、手間が0になるわけではありませんし、社内で使用している言語ではPerlなど未対応のものもあります。ですがワークフロー全体としては作業がかなり簡略化され、また自動的にアップデートがやってくるようになったことで意識も高まり、チームやプロジェクトによっては滞りがちだった依存性のアップデート状況が改善されてきています。
同種のツール・サービスにはGitHubに統合されているDependabotもありますが、複数のライブラリ更新を1つのプルリクエストにまとめるグルーピング機能や、柔軟な設定項目、設定ファイルの共通化・共有などが便利なので、Renovateをメインで使用しています。設定ファイルの共有については はてなで使用しているRenovateの設定プリセットを公開しました – Hatena Developer Blog もぜひご覧ください。
次はGitHub Actionsです。以前まではリポジトリにGitHub Enterprise Server(GHES)を使っていたこともあり、CI/CDにはJenkinsを使っているチームが多かったのですが、最近はGitHub Enterprise Cloud(GHEC)への移行が進んだこともあって、GitHub Actionsを使うことが増えてきました。むしろGitHub ActionsやRenovateを簡単に使えることがGHECに移行する理由の1つにもなっているのではないでしょうか。
GitHub ActionsはCI/CDに使うだけでなく、例えば古くなったIssueを自動的に閉じたり、プルリクエストの変更内容に応じて自動的にラベルを付けたり、各種ワークフローの自動化にも利用できます。実際に自分のチームでは、サーバーサイドでGraphQL APIのスキーマが更新されたら、その変更をアプリのリポジトリに反映するプルリクエストを作成するというワークフローを定期的に実行するようにしています。
またGitHub EnterpriseのBilling APIを定期的に実行し、その結果をMackerelに投稿してGitHub ActionsやGitHub Packagesの利用状況の推移を確認できるようにするという使い方もしています。このようにMackerelと組み合わせたり、簡易的なcronやタスクランナーとして使うのも面白いと思います。
これらの導入に当たっては、
- まずは自分のチームで使ってみる
- 次は同じフロアの隣のチームや自分が過去に所属したチームなどご近所さんに声を掛け、導入役を買って出て事例を増やす
#renovate
や#github-actions
のSlackチャンネルを用意して、有志で情報共有やトラブルシューティングを行う
などのアクションを行い、積極的にサポートするようにしました。採用事例や経験者が増えたことで自発的に導入してくれるケースも増え、今ではどちらもなくてはならない存在になっています。この活動が社内のDX(Developer Experience)の向上に一役買ったのではないかなと思います。
── Q. 最近うまくいっていないことは何ですか?
「うまくいっていない」とは少し違うかもしれませんが、現在担当しているアプリで新しい設計に取り組んでおり、いろいろと試行錯誤しながら進めているところなので、目に見える成果や手応えがまだまだ少ないことでしょうか。「産みの苦しみ」を味わっている最中です。
大切にしているのは、意思決定の過程において納得感を醸成すること
── Q. 普段大切にしていることは何ですか?
プロダクト開発や技術選定に関する意思決定の過程において、できる限りメンバー間の目線を合わせて納得感を醸成すること、でしょうか。
多様なメンバーが集まる中でも、どうしても社歴やチーム歴が長い人、声が大きい人の意見が権威的になってしまうことがあります。逆にミーティングが静かで、参加者からあまり意見が出てこないこともあります。
こういった場で、あえて真逆の意見を出してみたり、脇が甘くてもツッコミ上等で口火を切って発言してみたり、まだしゃべっていない人にボールを渡してみたりすることで、議論を活性化させること・テーブルに材料を集めること・そこから落としどころを探ること、というアクションを取ることが多いです。
自分自身ももちろんですが、チームメンバーにも納得感を持って仕事に取り組んでもらえる環境づくりをしたいですね。
「早く小さく失敗する」ことも意識していきたい
── Q. はてなはどんな会社ですか?
これまでのアンケート記事でも同じような感想が多かったと思いますが、人が善く、誠実である・あろうとしている会社という印象が強いです。各専門職同士で誰が偉いということはなく、お互いにリスペクトし合いながら働ける環境だと感じています。ビジネス的にも「売上・利益が上がるなら手段は選ばない」というのを良しとせず、「三方よし」が大事にされているのではないかと思います。
裏を返すと、正しくあろうとし過ぎることでスピード感が損なわれている面がある気もしています。自分自身も考え込み過ぎて腰が重くなることがあるので、自戒を込めて「早く小さく失敗する」ことも意識していきたいですね。
はてなのスマートフォンアプリ開発は挑戦の連続です。誰にとっても身近なスマートフォンですが、開発環境も利用者にとっての位置付けも日々変容しています。より良いアプリの提供を目指し、今ある技術だけでなく、これから先の技術に積極的な仲間を募集しています。ご連絡をお待ちしております!
▼ iOS、Androidアプリエンジニア職 転職・中途採用 – 採用情報
▼ iOS、Androidアプリエンジニア職の新卒採用 – 採用情報