開発チームにおけるバックエンドテストのガイドライン策定の軌跡をふりかえる
はじめに 株式会社マイベストでバックエンドエンジニアをしています、井上周（@isaka1022）です。 マイベストの開発組織において、2023年度の後半にかけて、バックエンドのテストの書き方の方針、ガイドラインの策定のプロジェクトを担当しました。 そもそもどのようにテストの書き方を決めるのか、また、ガイドラインとして機能させるためにエンジニア全員で共通認識を持てるものに仕上げるか、など考えることが多かったのですが、なんとか形にすることができたので今回はどのようにガイドラインを策定したか、その背景や経緯をお伝えできればと思います。 ガイドライン策定の背景 mybestのアーキテクチャには近年、Ruby on Railsに加えてNext.jsが導入されました。 それに伴い、バックエンドのテスト環境に大きな変化がありました。 それまでもテストの書き方のルールが決まっていなかったこともそうですが、
2021年が濃すぎて振り返りきれない｜松岡玲音
昨年初めてnoteで一年の振り返り記事を書いてみて、なんか良かったので今年も振り返りを書こう！と思ったのだが、2021年があまりに充実しすぎていて、振り返りきれない😇 ので、2021年に立てたOKRだけでもまずは振り返り、2022年の目標を立てることでお茶を濁していくことにする。 2021年の目標（OKR）の振り返りObjective 1: エンジニアとして継続的に成長し、事業に貢献する2020年は、メルカリUSという新たな環境で結果を出すためにがむしゃらに仕事をした年だった。数字に出るような成果を残すことはできたが、エンジニアとしてちゃんと成長できているのか？という課題感があったため、1つ目のObjectiveに、「継続的な成長」を盛り込んだ。 KR1: バックエンド、データエンジニアリング、情報検索についてそれぞれ課題図書を数冊決め、読み切る - 達成度: 60%「Webを支える技術
Google 、SalesforceのPMは、どう開発の難題に立ち向かう？ 強いプロダクト組織の考え方 | キャリアハック（CAREER HACK）
Google にてGroup Product Managerを務める徳生裕人氏、日本CPO協会・代表理事を務めるKen Wakamatsu氏が登壇。それぞれ複数の組織を見てきた観点から考える「強いプロダクト組織」の作り方とはーー。及川卓也氏によるモデレーションで行われたセミナーをレポートする。 ※2022年4月に開催されたクライス＆カンパニー主催「クライス汐留アカデミー」より『「強いプロダクト組織の作り方」～プロダクト組織作りの要諦となる採用と育成～』セミナーのレポート記事をお届けします。PM＝プロダクトマネージャーとして記載しています。 前半パートはこちら 後半パートはこちら Moderator クライス＆カンパニー 顧問 及川 卓也 MicrosoftにてWindowsおよびその関連製品の開発を担当した後、Googleに転職し、ウェブ検索やGoogleニュースのプロダクトマネジメントや
超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話（1） Regional Scrum Gathering Tokyo 2022
超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話（1） Regional Scrum Gathering Tokyo 2022 代表的なアジャイル開発手法であるスクラムをテーマにしたイベント「Regional Scrum Gathering Tokyo 2022」が、1月5日から7日までの3日間、都内およびオンラインのハイブリッドで開催されました。 そのクロージングセッションとして行われたのが、現在シアトル在住でMicrosoft Azureの開発を担当している牛尾剛氏による「アメリカの超巨大クラウドの中の人に転生したガチ三流プログラマが米国システム開発の現実をリークする話」です。 本記事ではほぼ90分におよぶセッションの内容を、前編、後編（1）、後編（2）の3本に分けて紹介します（この記事は後編（1）です）。 前編では、子供の頃からプロ
20年間ソフトウェアエンジニアとして働いて学んだ20個のことまとめ
By Sergey Galyonkin ソフトウェア開発企業・Simple Threadの創設者であるジャスティン・エセリッジ氏が、ソフトウェアエンジニアとして20年活動した経験を基に、学習において重要なポイントやコーディングにおいて意識するべきポイントなどを20個にまとめて公開しています。 20 Things I've Learned in my 20 Years as a Software Engineer - Simple Thread https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/ ◆1：自分がまだ多くを知らないことを自覚する エセリッジ氏は、たとえ何十年間ソフトウェアエンジニアとして働いたとしても、それぞれのエンジニアが持つ知識には違いがあり、他のソ
ITエンジニアの働き方を尊重し、技術的な成長を促進する開発組織に求められるものとは？ ──ユーザベースの取り組みに見る - はてなニュース
ITエンジニアが働く環境を選ぶ際に「技術的な成長が期待できるかどうか？」はとても重要な指標です。技術的な裁量が大きいことや学習機会が用意されていることだけでなく、チーム編成や評価といった仕組みの部分にまでエンジニアを尊重した文化が浸透していれば、その企業は極めて働きやすいと言えるでしょう。 エンジニアが尊重される文化を醸成する仕組み作りの事例として、ペアプログラミングによる知見の共有を推し進め、プロダクトに導入する技術選択にもかなりの自由を持たせているユーザベースに、エンジニアを支える開発組織と企業文化について聞きました。 今回は、スペシャリストとしてFellowの肩書きを持つ矢野勉さん（上記画像左下）と、入社2年目の廣岡佑哉さん（左上）にそれぞれの働き方を語ってもらい、CTOの林尚之さん（右上）には組織としての考え方をうかがいました（※取材はWeb会議ツールでリモート実施しました）。 ※
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。｜Fritz | Lead Product Manager @ Mercari
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・ 良い仕様書がもたらす 5 つの効果 ・ 仕様書の重要性が増していく 2 つの理由 ・ 仕様書に含めたい 14 の項目・実戦編 ・ 仕様書作成時に心に留めたい 3 つのこと ・ 具体的な仕様書サンプル（
2年半のエンジニアリングマネジャー経験から学んだこと - valid,invalid
2017年6月〜2020年3月まで、Quipperという会社でEngineering Managerをやってみての振り返りです。 ここ数日こつこつと退職エントリを執筆していたのですがこのセクションが長くなりそうだったのと、単体で読まれても良さそうなので1エントリとして切り出しました。*1 マネジャーになった背景から失敗から学んだことから思いついたことをぐだぐだ書いていきますがはっきり言って個人の日記レベルなので野暮なツッコミはなしでお願いします。*2 というかこれは個人の日記ですよ〜。（ここまで防衛線） マネジャーになった背景 / 当初の役割 記憶が確かであれば2016年頃にQuipperにも評価制度が導入されたのですが、当時すでに世界に数拠点あったためCTO@Londonが全員を評価するのは難しくなっていました。可能な限り現地オフィスで現地メンバーを評価したほうが納得感も高い、ということ
エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita
本記事は、Engineering Manager Advent Calenderの１日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ
エンジニアと立ち話。Vol.25 @hamakn（メルペイBackendエンジニア）ちょっとお話いいですか？ | mercan (メルカン)
エンジニアと立ち話。Vol.25 @hamakn（メルペイBackendエンジニア）ちょっとお話いいですか？ メルカリで働くソフトウェアエンジニアにちょこっとお話を聞いていく本シリーズ。第25回では、メルペイのバックエンドエンジニアでテックリード（以下、TL）の@hamaknにちょこっと話を聞きました。聞き手はメルペイのVP of Engineeringである@hidekです。 メルペイのダッシュボードチームで、銀行接続・NFC・コード払い・クーポンなどの各機能を加盟店さまに提供するAPI開発をTLとして担当する@hamakn。そんな@hamaknを、@hidekは「TLとして期待される役割を体現しているメンバーの一人」と話します。その理由は？ お客さまが最も触れるメルペイ管理画面の開発を担当 @hidek：（@hamaknさん、まだかな……？） @hamakn：hidekさーん！ 「エン
エンジニア組織がない会社でエンジニア組織を立ち上げるためにやった3つのこと - Qiita
LITALICO CTOの岸田崇志(@takish)です。 2017年のアドベントカレンダーもついに最終日となりました。 入社して2年経ち、エンジニアも順調に人数が増え、新卒採用からの育成、そして新規事業ラインへのエンジニアラインがスケールアウトできるようになってきました。 特に前職ではインターネット事業の急激な成長を経験したので、エンジニア育成サイクルの礎を築いて置くことの重要性は身にしみて感じていたので、最初からそれを念頭に組織を組み立てています。 はじめに 筆者はエンジニア組織の立ち上げは3回目なので「デジャヴ？！」と感じる事も多々あり（笑）、既視感ありまくりの2年でした。 一方で既視感があるということは、どこも成長のフェーズにおいて同じ課題に直面するということでもあるという事でもあります。 そのため、そのような経験を基に過去失敗した轍をもう一度踏まないことを心がけました。 成長フェ
メルカリは開発組織を拡大するためにマイクロサービスアーキテクチャを採用した（前編）。Mercari Tech Conf 2018
2013年から2017年のあいだ、スタートアップを含む2000以上の組織に対して、いかに組織のパフォーマンスを加速するかという聞き取り調査を行い、その調査結果をまとめたものです。 その調査結果のひとつにこのグラフがあります。 これは組織のエンジニアの人数とそのパフォーマンスを、組織の違いによって示したものです。 横軸がエンジニアの人数、縦軸はエンジニアあたりの1日のデプロイ数を指標としたパフォーマンスです。 これによると、パフォーマンスの低い組織はエンジニアが増えるとデプロイ数も減少しています。普通のパフォーマンスの組織はエンジニアが増えてもデプロイ数に変化はありません。 一方でパフォーマンスの高い組織はエンジニアが増えるほど指数関数的にデプロイ数が増えていきます。メルカリが目指しているのはここです。 これは単純にアーキテクチャをモノリシックからマイクロサービスへ移行するだけでは実現できま
GitHubでコードを「公開しない」リスク？サイバーエージェント流、OSS時代の開発哲学 | SELECK
今回のソリューション：【GitHub（ギットハブ）】 〜「GitHub」でソースコードを社内・社外に公開し、オープンなコラボレーションを実現した事例〜 数々のサービスを生み出し続けるエンジニアリング集団、株式会社サイバーエージェント。そのエンジニアリング文化の中心には、「GitHub」を活用したオープンなコラボレーションがある。 同社ではプロダクトのソースコードは可能な限り全社公開すると同時に、 「スターインセンティブ制度」というリポジトリのスター数に応じたインセンティブを与える制度により、自身の書いたコードを社外へ公開することを推奨している。 ▼そもそもGitHubって何？という方はこちらの記事もどうぞ！ チーム開発を変える「GitHub」とは？導入方法・使い方を徹底解説！【第1回】【導入編】 ソースコードを可能な限り公開していくという流れは、ITベンチャーのみならず世界的大企業にも派生
エンジニアマネージャー論と学びを抽出する努力を続けること - ワザノバ | wazanova
https://news.ycombinator.com/item?id=8406507 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約1時間前 真剣にものごとに取組むと、やらなくてはいけないことはそのうち次から次へと気づく and/or 嫌でも湧き出てくるもの。なので、アドバイスを求められれば、やるべきことは最小限、できれば三つ以内に絞って、何をやめることができるかを探す手伝いをするようにしています。やるべきことを毎日洗い直して、絞り込むことが大切。 情報の収集は自動化されてきますが、自分にとって何がポイントなのか、どう活かすべきかという抽出作業は、自らを鍛え続けなくてはいけない人力作業ですね。 RethinkDBのFounderであるSalva Akhmechetが、エンジニア組織のマネージャーのあるべき姿
チームを良くする話 - 良いあそなすちゃん
今いる会社でプロジェクトはいくつかあって、それぞれのチームにエンジニアが居るんだけど、僕のチームでは厳密にはエンジニア1人でやっている。 最近、ただ単にぼっちなのが寂しいのかこの半年で急激にエンジニアの数が増えてきてコミュニケーションの機会が減ったのか僕が昼すぎから出社するからなのか、理由はよくわからないけど、会社の日報に日々思ってることを長文にして投げたりとか、Wikiにポエム書いてたりしてたら、なんとなく他のチームにも伝搬していってて日報にポエムが溢れかえるようになった。お前ら女子か。 ポエムというのは言い過ぎかもだけど、日々思っていることをチームの中に共有するのはすごいいいものだなぁと感じる。日報、ありがちなのはその日にやったことを書いたりするけど、僕はあんまりそういうの気にして無くて、「君がいるチームのリポジトリでgit logすればわかることやん？」ってなる。いや、もちろんそうい
チーム開発とクソコード - tototoshi の日記
今までパッケージソフトとかWebサービスの開発をしてきた中で、ビジネス上の納期や要求を満たすためにひどいコードを書くっていうのは自分の経験ではあまりなかった気がします。なにかひどいバグがあって、とりあえずのパッチを当てて間に合わす、ということはたまにあるけれど。SIの世界は知りませんよ。 そもそもコードを汚くかけば納期に間に合うということもないし、ビジネス上の近道になるということもない。コードをきれいに書こうが汚く書こうが無理なものは無理。第一汚いコードを意図的に書くというのも意外に難しいということは、普段まあまあきれいなコードを書いている人ならわかってくれるんじゃないかと思います。 仕様変更に設計がついていけてなくておかしいとかならともかく、関数が1000行あるとか、newした瞬間全てが終わるとか、変数のスコープがびっくりするくらい広い、みたいなコードについてははビジネス上の要求ではなく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Tumblr