サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
はじめに こんにちは。食べログ飲食店システム開発部でエンジニアリングマネージャーをしている井本です。 今回は私の所属している予約サービスチームをサンプルにし、以下のような内容を紹介します。食べログのエンジニア組織、所属チームで起きていた課題食べログエンジニア組織と予約サービスチームについて 予約サービスチームの組織編成の工夫について チームで行なっている情報共有の工夫 この記事が組織編成や仕組みを考えるヒントになれば幸いです。食べログのエンジニア組織、所属チームで起きていた課題 複数の開発チームにまたがる開発の課題について 我々が所属している食べログは、年々ネット予約の利用人数が増加しております。 大変喜ばしい状況ですが、ビジネスの拡大に追いつくため、組織も対応していく必要が出てきています。 特に近年ではエンジニア組織も拡大し、複数の開発チームにまたがり開発する機会が増えました。 複
2023-03-24追記 気がつけばこのポストも7年の月日が経過しました。 くっそしょうもない話でしかないのに、妙に人気のある本記事です。 実のところあの頃のスクリプトを秘伝のタレのように微妙に変えながら使い続けて、と来たわけですが、 そうこうしている間に、時は流れ、Appleはx86を捨て、そしていつの間にか人類は自分の母語でやりたいこと書けば大体よしななコードが書かれる時代が到来しました。文字通りの未来です。 そして、Macをセットアップする最初に数時間を節約するために、わざわざスクリプトを親切に書き直すというモチベーションはそうそう湧くわけもなかった私に、7年前にやるべきだったことを変わりに、私でも、ましては人類でもなく、コンピュータ自身がその仕事をやってくれる時代が訪れました。 ありがとう、ChatGPT。彼（彼女？ああ、non-binary?コレも違うな）がやってくれました。 （
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
