ペパボさんテックブログメモ(2020-2022)
気になった記事のメモ(順番は公開日の時系列順。
2020年
①Pull Requestのレビュアーとして依頼された時
いまいち仕様を把握していないのでApproveしていいかわからない… あとでドキュメントを調べよう
全体がわかってないので自分がどこをわかってないかもわからない… どうしよう
技術的に疎いところでわからないけど、言いにくい… 時間があれば後で調べよう
こういう場合、このPull Requestは放置されて、レビュイー(依頼した側)のモチベーションは下がるし、分かる人が毎度対応することになる。= 生産性としてとても良くない。
これを改善するには、わかりません!教えていただけますか?と言うだけ
レビュイーは、あなたがわからないことを初めて認識し、フォローしてくれるでしょう。質問することで、もしかしたら、どこがわからないかをあなた自身で気づくかもしれません
Pull Requestのレビューは、実装の正しさを見る以外に、メンバー間で脳内同期を図るために仕様や技術を伝える場でもある。自信を持って、わからないと伝えましょう!
②チームメンバーが障害対応していて私はチャンネルを見ている
対応しているメンバーが何を言っているのかわからない、何語?… 自分のタスクをやろう
何をやっているかはわかるが、何のためにやっているかわからない… 邪魔したら悪いのでもう少し様子を見よう
自分ならこうするけど自信がない… 後で聞くか(そして忘れる)
→障害対応をいつも決まったメンバーがやることになる。これだとチームは大きくなっていかない。
一緒に考え、一緒に作業することで、障害時に必要な判断力が育つ。これを改善するには、わかりません!どう意味でしょう?と言うだけ。
チームメンバーは、あなたが関わってくれる意思があることを認識し、フォローしてくれるでしょう(余裕がなければ落ち着いた後に対応するでしょう)
質問することで、どこの技術スタック、どこのドメイン知識が足りていないかあなた自身で気づくかもしれません
🤔 たしかに、心の中で思ってるだけだと、障害対応に自分も加わる意志があることがチームに伝わらない。思っていることを相手に伝えることは大事!
障害対応は、対応するメンバーの心に余裕がないことが多いです。とはいえ、経験が浅い人へ試しにお願いするというのは、現実的ではありません。なので、わからないことをメンバーに伝えるアクションが、障害対応に関わる最初のステップだとして、勇気を持って、わからないと伝えましょう!
③「わからない」をたくさん言った人に「わからないMVP」として褒め合う。
「わからないを言う」を根付かせるには、結構大変。チームの中で心理的安全性が高くないと出来ないことかも。
技術を行使して、主に自動化を進めることで、本質的な採用活動にペパボの優秀な採用チームが時間を使えるようになることで、応募してくれた方に対してよりペパボのことが伝わったり、採用チームの迅速な対応ができるようになると考えています。
😍これは私が前職で感じていたこと、自作サービスFjordChoiceを作ろうと思ったきっかけと全く同じ考えなので、とても共感した。
選考結果記入のリマインド
記入してない選考担当者にリマインド&リマインドされた事実を共有チャンネルにも投稿
理由:共有チャンネルに投稿するのはなぜかというと、採用チームから見ると選考担当者に早く結果を記入してもらい、応募者に迅速に連絡したいので、ついついリマインドしたくなります。自動でリマインドしている事実が視認できないと情報の非対称性が生まれ、ついつい手動でもリマインドしてしまい、採用チームは重複リマインドの無駄が生まれ、選考担当者は度重なるリマインドをうけることになるので煽られているような印象を受けることもあるかもしれません。
🤔「度重なるリマインドを受けると煽られているような印象を受ける」→そういった感情面の所まで考えて仕事されているのとっても良いと思った。
面接の10分前にリマインド&共有チャンネルにも通知した事実を投稿
パートナー全員の評価の制度と報酬をアップデートした
エンジニア職位制度は2015年に導入した制度をベースとしながら2020 年までの 5 年間に主に以下に示すアップデートを行った
シニア(以上の)エンジニアの評価基準の細分化(例: 4.1等級-4.4等級など)
シニア以上の報酬の大幅な増額
エンジニアリングマネージャ(テクニカルリード、チーフテクニカルリード)の導入
2020/7 時点のペパボのエンジニアのキャリアラダー(人事制度や能力開発のシステム)
エンジニアの技術力の三つの評価軸
①作り上げる力
②先を見通す力
③影響を広げる力
等級ごとの達成レベルを社内全体で統一した基準として、等級ごとに求められる要件を作成
評価、というものは人の行動や組織の形成に有意に働く性質がある
評価をエンジニアリングマネージャの中でのみ完結させるのではなく、事業部門にも関わってもらう形にした。
部門に所属しながらも、専門職の中で評価の仕組みや構造を形成することで専門性についても評価を行い、各自が成長や能力に見合った報酬を得ることができる仕組み
エンジニアは様々な種類の業務がある
サービスの開発はもちろんのこと、コードレビューや運用・障害対応
問い合わせが来たら調査も行う
🤔たしかに、ユーザーから問い合わせが来て、それがエンジニアにしか分からないことだったら、こういった調査したり解決したりするお仕事は突発的に起こりそう
場合によっては社内勉強会・オンボーディング・研修・評価資料の準備・面談などの開発・運用と直接関係ない業務もある
そんな中起こっていた問題
minne の Web 開発チーム(「Webチーム」といいます)では、問い合わせに繋がる不具合の調査・修正、ライブラリアップデート、その他改善タスク等のアプリケーション運用に関するタスクが宙に浮いてしまい、開発タスクと運用タスクをバランス良く進められていませんでした。
考えられる原因
開発タスクと運用タスクに関する優先度を決める際、
どのような基準で運用タスクの優先度を判断するか、
そしてどのような時間配分で開発タスクと運用タスクに対応するかという指針が存在しない点が、
それらの取り組み方の不均衡を生む原因ではないかと考えました。
解決策
時間配分:サービス開発の時間とその他の業務の時間を 1 対 1 の割合で分担
pepabo-cocktail という新入社員が気軽に発言・質問するための専用のチャンネルがある
日報を書く際にこれを意識すると良いと先輩から助言されたこと:「大声で作業する(Working Out Loud)」
考えてから書く」ことを辞めて、「考えていることを書く」や「書いてから考える」ことにした
「行動だけでなく思考も見える化しよう」
理由①周りからの助けを得やすくなる
②フィードバックを受けやすくなる
③文字に起こすことによって、自分の思考が整理・具体化される
😍「大声で作業する」は、FBCでの学習で意識して行ってきていたので、就業後も続けていきたい。
社内のツール活用がすごい、情報量がすごい
slackのチャンネル数800
プライベートチャンネルの作成は申請が必要で個人情報を扱う場合などの一部の利用に限られていて、オープンチャンネルでのやり取りが徹底されており業務上の疑問も検索すれば情報を得られる事が何度もあり社内に資産としてノウハウが貯まっていた。
🤔たしかに、プライベートなチャンネル作成やDMが自由にできると、知っている情報が人によって偏ってしまうことが起こり得そうなので、なるほどと思った
GitHubは、デザイナー方もPRレビューを行いコードを修正などもしていたり、サービスのお問い合わせ対応などもGitHub上で行っている。ソースコードの管理だけに留まらない有効活用。組織内の人事評価資料なんかもPRレビューでフィードバックもらいながら進める。
情報のオープン化・技術スタックの蓄積・業務手続き方法の明確化がされている
2021年
2020年12月に東証一部企業になった
(コロナ禍)インターネット上でのアウトプットというのは、自己表現によるアウトプットをする人々だけが行うことではない。すなわち、より多くのひと(すべてのひとといってもいいかもしれません)が自己実現をするのに欠かせないものに本格的になってきたのではないかと思う。もちろんネットが当たり前になって久しいというのは、広く知られた事実です。しかし、コロナ禍におけるデジタル化の急速な進展は、その「当たり前」がまだまだ「本当の当たり前」になっていたわけではなかった、いまはまだその入り口であるということをあらためて知らしめたのではないでしょうか。
便利だったり効率化したりするもの→なくてはならないものになっていく
従来の情報化/ICT利活用では、既に確立された産業を前提に、あくまでもその産業の効率化や価値の向上を実現するものであったのに対し、デジタル・トランスフォーメーション(DX)においては、その産業のビジネスモデル自体を変革していくということ
そうした観点でペパボが提供してきたサービスを見返した時、人々のアウトプットを支えてきたというのは前述の通りであるとして、さらにはそれぞれの領域においてこれまでずっと、DXを支援してきたとみることもできる
それが証拠に、「ロリポップ!」を始めとするホスティング事業や、「カラーミーショップ」を始めとするEC支援事業では、この数年間、事業者による利用が増えてきています。また、minneやSUZURIにおいても、クリエイターさんの販路の多様化という意味合いからさらに進んで、そこでの活動を通じて事業の中心としてご活用いただいている事例も増えてきました。そういう意味においても、ペパボの提供するサービスがお客様の生活を支えるものとしてより重要なプラットフォームになってきており、ますます身の引き締まる思いがいたします。
😍アウトプットを支援するサービスから→生活基盤となるような、なくてはならない、ビジネスモデル自体を変えるようなサービスになってきている。
「魚の釣り方」を支援するというのが我々のサービスのあるべき姿
大事なのは、魚そのものを支援するのではなく、魚の釣り方を支援すること
どんなひとにも欲する何物か・何事か、あるいはこうありたいという理想があり、また、それぞれの理想を目指す自己実現の欲求があるのだろうと思います。我々のサービスというのは、それらの欲求そのものや欲している対象、すなわち「魚」にアプローチするのではありません。また、「魚」を釣るための道具(「釣り竿」)を売っているのでもありません。そうではなく、そうした欲求を引き出して、実現を可能にする取り組みを支援していくこと、つまり「魚の釣り方」を支援するというのが我々のサービスのあるべき姿なんだろうと思っています。
コロナ禍が明らかにしたのは、インターネットはまだまだこれからであるということです。そして、もはや「ネット」は特別なものではない遍在的な「テック」になっていく中で、人々の自己実現を支え、アウトプットを増やしていくことが、我々のやるべきことなのだろうという新たな確信を得ています。
そうした展望の中で、これからもどんどんあらわれてくるだろう新しい技術に基づく人々の表現活動を支援し、アウトプットを最大化するサービスを作っていきたい
SwiftUI, GraphQL, Combineなど、チームで多くの面白い新技術を活用して開発効率を上げている
テスト
社内ではRuby on Rails経験者が多いというのもあって、RSpecに近い、やさしい書き方ができる QuickとNimbleを使用。ただ、XCTestを使いたい人は、使って良いというスタンスで、柔軟で平和な日々です。
CI/CD
方針として、できるだけ多くのことを自動化することによって、開発とレビューに割ける時間を最大化し、アウトプットの量を増やし品質を向上できる
作ったものに対して、なぜ作ったのか、利用している技術要素についての理解、ご自身での考えなどを述べることができるということを重視
💪GitHubのAPIやGitHub Actionsについて自作サービスで学んだので、業務の効率化にも積極的にこの知識を活かしたいなと思った。
GMOペパボではGithub Enterpriseを利用してチーム開発を行っており、Github Actionsが導入されてから様々なCI/CDを始め、ワークフローが作成されていっています。 一つ一つは小さな作業ですが、自動化する事で抜け漏れの防止ができ、よりクリエイティブな時間を捻出できます。 普段何気なくやっていることが無駄ではないかな?と目を光らせてこれからも日々の作業をカイゼンしていきたい
😍minneさんの開発状況がどうなっているか詳しく知ることができた
元々Webアプリケーションエンジニアとして配属された。(そもそもフロントエンドエンジニアという職種がminne事業部になかった)
minne事業部ではWebアプリケーションエンジニアの仕事はサーバーサイド(Rails)の開発が中心
フロントエンドの開発についてはWebアプリケーションエンジニアが担当することもありますが、基本的にはコーディングができる一部のデザイナーがSlim, SCSS, JavaScriptを用いてRails上で実装しています。これは、エンジニアがフロントエンドを蔑ろにしていたというわけではなく、サービスの成長戦略として機能的な実装に優先的にリソースが割り当てられていたのでサーバーサイドの開発中心になっているという経緯があります。
minneのフロントエンド刷新計画
約10年続くサービスであり、プログラムの規模も大きい
フロントエンドの技術的負債の蓄積やUI実装のコーディングを行うデザイナーへの開発の負担が大きくなっている→Vue.jsやReactを用いてこれらを改善しようという計画
OJT期間中は、ピックアップしていただいたWebアプリケーションエンジニアの開発タスクに取り組みながらも、時間を作ってフロントエンド刷新計画の情報を収集していました。この時に、先輩エンジニアの方々が情報を集める協力をしてくださったり、フロントエンド刷新計画の話をするミーティングをセッティングしてくださったので、OJT期間中からフロントエンド刷新計画にアプローチすることができました。
minne事業部のWebアプリケーションエンジニアはチームタスクをやる時間を4時間、自分の裁量で仕事をする時間を4時間取るという仕組み→4時間はサーバーサイド実装中心のチームタスクを行いながら、残りの4時間でフロントエンド刷新計画に取り組む
新しいフロントエンドアプリケーションの構築に用いる技術選定や設計の提案は僕が行っています。
技術選定の結果、React & Next.jsを使うことになったとのこと。
率先してモダンなフロントエンド開発を学び、その知見を事業部内の開発者に共有することでモダンなフロントエンド開発に対する理解を深めてもらう取り組みを継続的に行っている
minne CREのミッション:ユーザーの抱える不安を取り除き、気持ちよくminneを使えるように問題を把握・計測し、技術の力を使って課題解決する
ペパボに何年かいるエンジニアでも学びたいものがあれば、誰でも参加できる
2021年は「minneにとって重要な3つの力を高める!」
「商品力」「集客力」「マッチング力」
minneの開発組織の全体概要
「商品力」チーム
「集客力」チーム
「マッチング力」チーム
CREチーム
基盤チーム
各チームは自律して動いており、お仕事の進め方も各チームそれぞれで考えて組み立てている。minne全体で見るとスクラムをベースとした開発の進め方が多い。
※ PBI(プロダクトバックログアイテム):プロダクトバックログというリストの中のアイテム(項目)のこと。
minneのWebアプリケーション
これまでの技術の歴史も載ってる
抱えている課題
コード量や機能が増え全てを把握するのが難しくなってきた→開発時に「このコードを弄るとどこに影響があるのかがわからない」といった不安に繋がり開発のスピードが低下する原因に。
解決策:マイクロサービス化。まだサービスの切り分けが完全に終わっているわけではない。継続的に改善を行っていく。
これからやっていきたいこと
Web APIのGraphQL移行もしている。GraphQLのクエリの継続的なパフォーマンスチューニングやRDBMSのクエリの継続的なパフォーマンスチューニングもしていきたい。
高速にユーザに価値を提供しつつ快適にminneを使用して頂く土台作りをしていきたい。
こんな人にきてほしい
minneではイケてる技術を使いイケてるサービスを提供していきたいと考えているので、基本的なWebアプリケーション開発のスキルを有していることに加えて下記のようなタイプの人を求めています。
既存の技術スタックに囚われず広い視野で技術選定ができる方
自信の好みではなく、ユーザの為の技術選定ができる方
開発が好きな方
ペパボでは情報をオープンにすることでコラボレーティブかつ生産性高く仕事をすることを目指している。情報を共有するときは「より多くの人に」「関心を持ってもらえるように」情報を発信することを心がける。
プロフ画像は顔
人となりが伝わるような画像を設定することを推奨
チャンネル
private チャンネルの利用は非推奨。秘匿性の高いプロジェクトの場合のみ使う。
DMも非推奨。
public チャンネルは誰でも作れる
メンション
日中の時間帯(9:00-19:00目安)は必要ならばいつでもしましょう
メンションを受けても反応できない場合、したくない時間帯は受ける側で "Do not disturb"(おやすみモード) 設定を行いましょう
workflow の作成も誰でもできます。生産性を上げるために積極的に作成、共有をしてください。
日々の業務から得られた知見を少し立ち止まって振り返り、より一般化して考えてみる、その結果としてアウトプットするということが、エンジニアとしての成長には必要。なので、社内外の技術イベントで発表することなどを推奨している。
エンジニア一人一人が毎日の業務の中で得られたインプットを社外に向けてアウトプットを行い、そのフィードバックをインプットとしてより良いアウトプットを生み出す循環装置
執筆担当を恒久的な交代制としたり、上司からの指示として書かせるといいうことはしてない
最低限のルール一つ:読者にとって何かしらの学びを与える記事を書く
「こんなことをテックブログに書いてもいいんだろうか」→「質より量!とにかく書いて」
社内では業務扱い。しかし記事を書くことだけが専門職としての専門性ではないので、プロダクトを開発したり、目の前の課題を解決することを前提として、業務時間中に裁量を持って執筆を行っている
シニアエンジニアリングリード、またはエンジニアリングリードがレビューを必ず行う
1次面接
面接ではペパボの評価制度で用いている「作り上げる力」「先を見通す力」「影響を広げる力」の3軸と「私たちが大切にしている3つのこと」である「なかよくすること」「ファンを増やすこと」「アウトプットすること」の3つの合計6つについて、どれくらいのレベルで実行できるかということを評価する。
この6つについて、自身の考えを述べられるようになっておく。
2次面接
評価軸については一次面接で紹介した6つと同じ
「なかよくすること」「ファンを増やすこと」「アウトプットすること」の3つに加えて、事業や技術に対する熱意、コンセプチュアルな理解力と論理的な思考力、それらにより実現される行動力を重視
役員面接
採用した方が入社してよかったと感じることができるように、候補者と採用する側であるペパボとでそれぞれの期待値と現状を開示し合うことが採用フローにおいて最も大事なことと考えている
「ペパボさんはレベルが高くて…」という声→今の時点で求められている技術レベルに足りていなくても、ペパボという会社の中ならソフトウェアをどんどん作ることができる、作っていきたいという気持ちがある方とペパボのサービスを一緒に作り上げていきたい
肝心なのは、各個人が「自分はどんなふうに過ごすとパフォーマンスを発揮できるのか」を考え、実際にパフォーマンスを発揮できるように「自分の日々の過ごし方を設計すること」
各位が自身の現状や特性を自覚し、自身のパフォーマンスをいい感じにコントロールできるようになれば、環境の変化にふりまわされずにバリューを発揮し続ける組織を体現できる
アプリケーションの構成や構成要素を新しくした = アーキテクチャの刷新
従来のWebブラウザ版minneはフロントエンドもサーバーサイドもRuby on Railsでモノリシックだった→刷新で、フロントエンドをRuby on Railsから分離してNext.jsアプリケーションとして再構築した。
刷新による効果
①ページのパフォーマンスが向上
②開発効率の向上
TypeScript
動的型付け言語であるRubyから静的型付け言語であるTypeScriptに変わったことで型チェックの恩恵が得られるように
DRYな実装
元のRailsでは、viewディレクトリにページ単位でディレクトリがあって、その中に更に部分テンプレートのファイルがあった。コードを再利用するために異なるページの部分テンプレートをレンダーしちえる実装箇所があって見通しが悪い箇所もあった
Atomic Designの手法を用いてコンポーネント単位でファイル分割しているのでDRYな実装が実現しやすい
minneでのスクラム課題感
デイリースクラム(朝会)、スプリントプランニング(計画会)、スプリントレトロスペクティヴ(振り返り会)はすでにMTGとしては存在しており、それぞれ実施が形骸化することもなく目的をもってMTGを行っていた。しかし以下のような課題が。
スクラムイベントに長時間費やすもののそれに見合った成果を感じられない
相対見積もりへの苦手意識
要件と異なる実装での再実装の発生
職種間でバックログの見通し齟齬(くいちがい)
スプリントゴールの達成率の伸び悩み
改善策
同じ認識をもって言葉を使う→コミュニケーションがスムーズに
PBI(プロダクトバックログアイテム)をちゃんと定義
バックログの(情報の)鮮度管理
バックログの内容を更新する作業(リファインメント活動)をリファ活と略し、毎朝定例で行う
🤔たしかにサービスを取り巻く社会やユーザーの状況や、サービスの仕様もどんどん変わっていくから、それにともなってバックログもこまめに更新しないと現実に即したものでないものになっていきそう
デイリースクラムは漫然とした進捗報告会であってはならない→スプリントゴールを達成するための「お困りごと」の共有を中心にMTG
とはいえ、「お困りごと」はなかなか作業者自身から報告出来ない場合もあると思います。ソフトウェア開発者なら誰でもドツボにはまってうんうんとうなったまま時間が過ぎてしまった、という経験はあるでしょう
一つの作業に大きな時間をかけてしまうと、「お困りごと」はないけれどもそのスプリントのスプリントゴールを達成出来ないということがおこり得ます。そのため、「お困りごと」がない場合などは「スプリントゴールを達成できそうですか?」という問いかけが有効で、何らかの「お困りごと」を見つけるところから議論がスタート
🤔ドツボにハマってる状態だと、困っている状態ではないと考えて調べ続けてしまうことがあるし、困ってますか?と言われると、「まだ自分の努力が足りないかも」って思っちゃうので、スプリントゴールを達成できそうですか?という問いかけは、明確な基準をもとに報告ができるのでいいなと思った。
成果
スプリントプランニングが丸一日かかっていたところを30分~1時間、長い場合でも2時間程度に納められるようになってきた
見積もりの肌感を職種間・メンバー間でそろえることが出来るようになってきた
例えば陶器のお茶碗をminneで探したい時、検索の入り口としてカテゴリが「陶器」と「食器」の2つあると、どちらから探せば良いのかユーザーは迷ってしまう
カテゴリを再編した
適切なカテゴリ分類はユーザーに適切な探索行動の道筋を提供し、結果としてプロダクトの「わかりやすさ」を生む
minneでは“自らの「生活・人生・営み」をデザインする”というブランドビジョンを掲げている。
"自らの「生活・人生・営み」をデザインする"
日々の生活の中で「好きなもの・こと」を探し、出会い、選ぶことを繰り返して自らの価値観を形作り、変化させる。このような暮らしのデザインを大切にする私たちは、ものづくりを通して他者の価値観の刺激とつながりを楽しみ、より創造的に、自分らしく生きていくことを尊重する。
2022年
Slackを活用した日常のコミュニケーションでストレスを与えやすいパターンの例とその改善手法
ペパボさんは、コロナ禍以前より、テキストでのコミュニケーションが主体
メリット:「考えていること」「思っていること」を文字として具体化できることや、 後でログから検索できること
💬 私も前職の時、大事なことやこれからよく使いそうな知識はチャットツールに積極的に流すようにしていたのでとても分かる!と思った
一方、音声でのコミュニケーションにあるような「トーン」で表現される細かな感情表現が難しい。細かな表現が欠落することや、文字にすることが難しいといった部分から、認識のズレがしばしば発生。
💬たしかに、相手の感情が読めなくて不安になった経験があるのでとても分かる🤔
受け手が緊急度や重要度が判断しやすいようにする
💬色んなパターンごとに「こういう時はこうしてみよう」という改善案とその理由がとても丁寧に書いてあった。エンジニアとして仕事することになった時にまた読み返したいと思った。
「組織文化の測定」に基づいた調査
1が「全く同意できない」から始まり、4が「どちらとも言えない」を経て、7が「強く同意できる」という尺度
情報を積極的に収集する
失敗など、良くないニュースを知らせても罰せられない
責任を共有できている
職能の垣根を超えた協働が推奨、報奨されている
失敗があると調査が行われる
新しいアイデアが歓迎される
失敗がまずシステム改善の機会と受け取られる
どの質問も5-7 の回答が多数。あくまでも「心理的安全性がありそう」「新しいチャレンジを推奨してそう」という定性的なもの
「情報を積極的に収集する」「責任を共有できている」「失敗があると調査が行われる」については他の4つの質問と比較するとペパボの組織が強く実現できてない
アウトプット大臣