こんにちは。FiNC TechnologiesでCREバックエンドエンジニアをしている河口と申します。2020年に誕生したFiNCのCREチームについて、2020年下半期の振り返りと2021年の抱負をお伝えしたいと思います。 CREはCustomer Reliability Engineering（顧客信頼性エンジニアリング）の略で、Googleが提唱した専門職です。※Googleの記事はこちら。 FiNCのCREの業務は主にユーザー対応を行うカスタマーサービスグループ(以下、CS)と連携し、日々サービスの改善に取り組んでいます。 なぜCREチームを作ったのか、チーム結成〜2020年上半期の成果については下記のブログ記事をぜひご覧ください。 カスタマーサクセスの実現のためCustomer Reliability Engineering(CRE)チームを立ち上げました FAQ刷新による問い合

プロダクトに責務をもつ立場の人(ex.PdM, PO)は、仮説を立案するのが仕事の一つとしてあります。その仮説をもとに開発チームが実装してリリースした結果プロダクトを拡大するかどうかが決まります。 今回は、そういった『仮説』というものをどのように立案するべきかの考えを述べていきます。 ひとつ重要なことは、よく『失敗を許容する組織』であるべきといったことを言われることがあるのですが、これは『数打てば当たる』という精神ではありません。 必ず『仮説の妥当性』は担保しなければいけません。しかも、そこに付け加えるとしたら、その妥当性はデータで示されなければいけません。 仮説は、データをもとにある程度、効果予測が可能です。 データに頼らない仮説は、直感に頼るしかないと思っています。その場合開発プロセスは以下のような形になります。 つまり、直感に頼るとポンポンとアイディアがでてきます。それがそのままプロ

こちらの記事は翻訳記事となります。 原著者の許諾を得て翻訳・公開しております。 英語記事: How to Write Fast Code in Ruby on Rails原文公開日: 2019/10/08著者: Gannon McGibbonURL: https://engineering.shopify.com/blogs/engineering/write-fast-code-ruby-rails はじめにShopifyでは、ほとんどのプロジェクトの開発フレームワークにRuby on Railsを使用しています。 RailsとRubyはともにパフォーマンスに対するスティグマ（偏見）が存在します。 多くの個人や企業が、Rails以外での解決方法を探しています。 しかし一方で、私たちShopifyではRuby on Railsを採用して、毎分何百万ものリクエスト（requests per

新年あけましておめでとうございます、清水 (@takayuki_shmz) です。 年末にFiNCのエンジニアリングマネージャー陣で振り返りブログを書くこととなり、その先人を切らせてもらいます。このあと android / ios / backend / sreと続いていきます。 今回は自分はVPoEとしての振り返りということで主にエンジニア組織に関することを書こうと思います。 2019年は登壇も3度ほど機会をいただきましたが、登壇の内容につきましてはSpeaker Deckのリンクを貼っておくのでそちらからご覧ください。 Presentations by takayuki shimizu — Speaker Deck 2019年当初の目標から振り返る年はじめに組織戦略と名うって決めた重点項目は以下の3つでした。 若手・リーダー育成アウトプットFirst全員採用そもそもなんでこの3つ？とい

※こちらの記事はZeals Advent Calendarの記事となります。面白そうなので参加してみる みなさんこんにちは。 チャットボット開発のスタートアップ…から最近転職した福本です。 リアクション頂いたみなさんありがとうございました転職してからブログをサボっていたのですが（すいません）、新しい職場にも徐々に慣れてきたので、ブログに限らず今後もアウトプットを続けていればと思っております。 さて、今回はタイトルにもある通り「技術広報」についてです。 前職であるZealsではそれなりに技術広報活動に打ち込み、テックブログをほぼ毎週の頻度で更新したり、情報を発信していく文化をそれなりに作ることができたと自負しております。

以下は、Kent Beckによる「Coaching Engineers」の翻訳です。本人の許可を得て掲載します。tl;dr 有償でエンジニアのコーチをします。詳細と待ち時間についてはお問い合わせください。 物語の結末2018年2月にFacebookを退職する直前に、トップ1%のエンジニア（現在および過去にレベルE7以上だったエンジニア）のオフサイトミーティングに参加しました。海辺のリゾートでバスを降りると、私がコーチをしていた生徒が複数いることに気づきました。そのうち何人かは昇進したことを知っていましたが、その他の生徒には驚かされました。 私にとって、胸がはちきれるほどの誇り高き瞬間でした。私は、生徒たちと関係を築き、彼らの成功のために心の底から尽力してきました。多くの生徒らが成功を収めたことを目の当たりにして、私は大いに驚き、嬉しくなりました。物語はさらに続きます。 Facebookの上

こんにちは、PairsのAnalyzeチームでエンジニアをしている鉄本です。 Analyzeチームでは、施策検討時のデータ抽出やサービス上の問題検知のために、分析用途のSQLクエリ (MySQL) を作成しています。 今回は、日々の業務を通して学んだTipsやよく使うクエリの一部を、簡単な活用例と一緒に前編・後編の2回に分けてお話ししたいと思います。 前編では分析でよく使うクエリを中心にご紹介します。 この記事を参考に、分析用SQLの高度な運用に役立てていただけたら幸いです！ 本記事で紹介するTipsで用いる関数の詳細については、公式リファレンスを参考にしてください。 目次- 前編 -1. クエリ内の複数箇所で使われる固定値を「ユーザ定義変数」でまとめる 2. 誕生日(DATE)から現在の年齢を計算する 3. データのない日を補完して日別レポートを作成する 4. 7日移動平均でデータの増減

製品開発におけるマネジメントの全体感最初に結論エンジニアがマネジメント始める際には、↑のようにざっくり簡単にでいいので開発チームのマネジメントの全体像を掴んだうえで、自分がマネジメントするべき範囲を明確にして動くことをオススメしてみます。 以降、もう少し詳しく説明します。 なんで書こうと思ったかエンジニアにとってマネジメントとはなにか。突出した技術力を持った人というのがエンジニアでは花形なイメージが一般的にはあるでしょうし、マネジメントはエンジニア全員にとって必須科目ではありませんが、一定の経験、年齢、スキルになったら考えることだと思います。 しかし、エンジニアにとってマネジメントという言葉はとても曖昧。必須科目でない分、特定技術に関するものよりもずっとドキュメントや教材がすくなく、なにをやればいいかけっこうわかりにくい。 最近だとVP of Engineeringみたいなポジションがメジ

なんか、このサイトBootstrapくさい。そう感じることはありませんか? その理由はズバリ、欧文ベースでつくられたフレームワークを文字構造の違う日本語で適用した際に不都合が出てしまっているからです。 それらが醸し出す違和感を放っておくと、Bootstrapくささを生み出す大きな原因になってしまいます。 そもそもの問題として、欧文と比較して和文は文字の要素が多く、文字自体のリズムも少ないため、どうしても複雑で単調に見えてしまいます。 しかし、和文だからといってあきらめることはありません。BootstrapのCSSを少しだけ変えるだけでグッと見た目がよくなる隠し味をご紹介します。 1. line-heightで行間にゆとりを。明朝やゴシックなど、フォントの種類が言葉の印象を表すように、文字の行間は読みやすさ、文章全体の雰囲気を左右します。 欧文をベースに設計されたBootstrapをそのまま

うろ覚えの記憶だが、2013 年に Twitter でこの話題が拡散されていたと思う。Web 業界では誰もが知っていながら誰もが認識しているわけではなかった簡潔な表現に、当時の私は衝撃ではなく、うまいこと言うなと感心していた。 しかし、当時はまだまだ Web 技術は発展途上でありながら先進的なイメージがあったように思う。ソフトウェア開発の未来が Web 技術であることは多くの人は認識していたが、Web はさして大きくないリソース上の制約を設けつつ、さして多様性のないプロトコル上の制約を受けつつ、特定技術に絞れば2年ぐらいやればその分野の詳しい人になれるという、Web 業界以外のソフトウェアエンジニアからみたとき、スキルとしてどこかチャラいイメージがあった。 知人の Linux Kernel 開発者とゲームの話をしていたとき、経験や知識の積み重ねで勝てないゲームは嫌いだという話になって、その

DMMに転職して以降、キャリアについて話してほしいという登壇依頼が多く似た話をする機会が数回あったのですが、その中でもコンセプチュアルスキルというか不確実性との立ち向かい方について先日社内に投稿していた内容をベースにこちらにも記事化しておきます。（ちなみにペパボのあんちぽさんからのリクエストが記事化のきっかけです。） コンセプチュアルスキルキャリアや長期の目標を検討するとき、そこには 資産（現状自分が持っているスキル・知識・ツールなどのリソース）スコープ環境要素が制約条件として存在しています。 自分の持ち物については理解しやすいですね。今自分が置かれている状況で使えるものを考えてみると、そこにはスキルや資本、時間、知識など様々な自分の資産が存在しています。「今ここ」を検討する上で自分の資産を知るということは分かりやすい要素です。資産を無視した状態で目標を検討しても、その目標を達成することは

「VOYAGE GROUP エンジニアの公開ガチ評価会」に参加して、最近考えていた「良いエンジニア」像がかなり良い感じだと思うようになりました。 「ガチ評価会」自体の内容は他の方のブログに譲るとして、「ガチ評価会」で聞けなかった部分、つまり「普段だったら『ビジネス的側面からの技術投資判断』とかも聞くんだけど」と言っていたところが、まさに聞きたいところだったのでニヤッとしました。聞けなくて残念♪ 妥協ない挑戦元々ピクシブの技術力評価においては、「最近やった妥協ない挑戦は何ですか？」というのをキーワードにやってました。 解決すべき課題に対して、どういう背景があって、どういう事前調査をして、どういう実装をして、どう考察するか、というところまでをきちんと考えて仕事することに成長があるんだよ、というメッセージ性です。 そんなこと言っても普段は妥協ばっかりですって？いえいえ、相反する選択肢の中で、何を

この記事はEngineering Manager Advent Calendar 2018の14日目の記事です。 株式会社FiNC Technologiesにてエンジニアリングマネージャーやっております清水 @takayuki_shmz です。今は自分の担当の日が回ってしまいそうで焦っております。 今日はEngineering Managerをそこそこやってみて、特に難しかったなぁという点を書きたいと思います。TOP3とか偉そうに書いてますが気をつけてください、n=1の主観100%です。異論は余裕をもって認めます。 まぁ「この世のすべての不利益は当人の能力不足」とのことなので、以後でる話題はすべて自分がマネージャーを始める際の勉強不足が原因なのですが、Engineering Manager界隈も徐々に盛り上がっていますので、僕のただの後悔を書き綴ることで、誰かの役に立てばと思います。 では

背景CIのビルド実行時間の長さは度々社内で問題になっており、「CIに時間かかるので業務効率が下がる」といった話が現場でも増加していました。 業務時間中は複数 Pull Request のビルドが発生するので、「CI順番待ちで次の自分のビルドは1時間後」のような現象は日常茶飯事でした。 おまけに「頻度は低いがランダムで失敗するテスト」といった false positive なテストの存在も、開発現場のフラストレーションは溜まる原因になっていました。単純に CI を再ビルドすれば直るのか、自分が追加した実装/rspecに問題があるのか一件判断がつかないケースだと、開発担当者も一旦 CI 上で再ビルドを行い、同じ箇所でコケるのか確認することになるので、これがさらなる CI 渋滞を引き起こしていました。 こうした背景もあり、丁度プロジェクトの隙間で工数もあったので「CI 改善をしっかり工数確保して

In this post, I’ll share a framework we’ve developed at Coinbase that helps us make decisions more effectively. Our… この記事では、より効率的に意思決定を行うためにCoinbaseで開発されたフレームワークを紹介する。会社のコアバリューには「クリアなコミュニケーション」と「効率的な実行」というものがあり、紹介するフレームワークはこれらのコアバリューを可能にしている一例である。 以下のような意思決定の際に使用できる： 候補者を採用するかどうか商品開発のロードマップで何を優先するか他社の買収や自社の売却の是非プロダクトやチームをどう名付けるかなど。 もし困難な判断を迫られて、決定できずに延々と会議を続けていたり、気分が晴れなかったり、後悔するかもしれないと恐れている場合は、このフ