こんにちは、DevBrandingのellyです。11月19日に配信した「マネーフォワード vs freee、もし名古屋で開発するなら？」の様子をご紹介します。 これから名古屋に開発拠点を立ち上げるマネーフォワードと 2020年に拠点を構えたfreee。 なぜ名古屋に開発拠点が必要なのか、作っているプロダクト、本社との関わり方、 両社のエンジニア組織の違い等を対比しながら1時間たっぷり赤裸々に語ってもらいました。 とても爽やかな両社の自慢対決となりました 長島圭祐 (Kei) さん: マネーフォワード 名古屋開発拠点 拠点長兼サーバーサイドエンジニア。 福岡でマネーフォワードクラウド債務支払の開発を担当しつつ、名古屋に新設される開発拠点の立ち上げを進めている。最近はサーバーサイドKotlinに夢中。 moai: freee 中部開発組織長。中部開発組織を2020/7に立ち上げた。地域技術イ
ジョブキューイングシステムをどうするかでチームのリーダーとやりあって考えたことがあるのでまとめておく。 Rails で使うジョブキューイングシステムの技術選定で、リーダーは Amazon SQS 推し（レガシーシステムで SQS を使っている）、自分は Sidekiq 推しだった。前職時代に Sidekiq を使ってトラブルに遭遇したことはなかったし、とても簡単に使えるので Sidekiq で十分だと思っていた。 Sidekiq は GitHub でのスター数は 9000 オーバーで、 Rails の ActiveJob バックエンドとしては事実上のデファクトスタンダードだといえると思う。ググれば情報がいっぱい出てくるし、チームメンバーもリーダー以外は全員 Sidekiq の使用経験があった。 GitHub - sidekiq/sidekiq: Simple, efficient back
こんにちは、アプリケーションエンジニアのid:shiba_yu36です。今日は社内で数年ほど取り組んでいる障害情報の社内共有についてご紹介したいと思います。 障害情報を社内共有する理由 サービスを運営しているなら、出来る限りサービスが一時的に止まってしまうなどの障害を起こさないように事前に対策を取るなど気をつけるべきです。しかし、どれだけ事前に対策をとっても、急激なアクセスの増加や、意図しないバグの混入、オペレーションのミスなどを理由として、障害を起こしてしまうことがあります。 障害が起きた時、それに暫定的に対応して終わりとしてしまうことも多いです。しかし、復旧した後大事なのは、障害に対して適切に振り返りをし、同じサービスで同様の理由で障害を起こさない、また社内で同様の理由の障害を未然に防ぐことです。 そこで、はてなでは障害の暫定対応をした後は、障害の振り返りや他チームへの知識共有のために
内容がネガティブに取られそうで、公式なところに書くべきではないので個人ブログで書きます。 この記事は、公式なブログで僕が書いた「社内横断の技術組織をはじめました」という記事へのアンサーブログになります。 ※元の記事は探せば出てきそうだし、個人的なブログと紐付けるべきではないのであえて出しません。 特定の誰かを陥れる目的ではなく、完全に個人の責任として、始めたものを終わらせてしまったことへの事の顛末を記録する目的で書きます。 はじめに 始めた理由 CTOの不在 品質面に対するレビュー不足 技術広報の不足 それぞれの施策の結果 時間がかかってみんなストレスが溜まる新規レビュー 当たり障りの無いことしか表現できない運用レビュー 兼任状態が続き、進まない新規技術検証 やる必要の薄い「全社」広報 終わった理由 成果が出せなくて、そもそも証明出来ないかもしれない 問題解決は組織じゃなくても出来ると気が
社内で不定期の勉強会があり、入社初日か2日目あたりにたまたまその勉強会が行われておりました。おーこれはいい雰囲気だ、というわけで次回はお話させてもらおうと早速手を上げました。MF Geeks Nightというエンジニア主導の会です。 てなわけで自己紹介がてら、個人でのWebサービスの開発〜運用をどうやっているかというお話をさせて頂きました。YAPC::Asia Tokyo 2014 前夜祭での発表資料を加筆修正した版です。 MF GeeksNight pplogの話 from Naoto Koshikawa MF GeeksNight pplogの話 新たな場では、まずは自分からオープンにしていくことを心がけています。こうしたとき、pplogにまつわる何かは良い自己紹介となりますねえ。ありがとう。 そしてエンジニアそういう、自分の興味のあることをシェア出来るエンジニア主導の勉強会の場を提供
先週、新卒技術研修の一環として @t_wadaさん にご講演を頂きました。 題して「この先生きのこるためには」*1。 第一線のエンジニアとして素晴らしい薫陶の数々を授けて下さいましたので、渋谷や六本木の会社さんもオファーしてみたほうがいいですよ。ホント。 エンジニアはアーティストとしての側面も持つので、ファーストクラスの方の考え方に早いうちから触れておくことは、数年先の彼らの在り方に少なからず良い影響を与えるはずだ、という考え*2に基づくおふたりめの社外講師です。おひとりめは当時非公開でしたが、時効になってましたら教えてください。 新卒研修とはいうものの、社食のカフェテリアを全開放した形で既存社員にも受講してもらいました。正直、私も含めた既存社員のほうがよっぽど直接の教育効果は高かったんじゃないかと思いましたが、それはそれとして。ご講演の中でのいくつかの気づきを共有します。 技術の進歩は「
日々の出来事、メンバーの働く様子や声、未来への想いなど、Supershipの“BE SUPER”なストーリーをシェアしています。
1.全体スケジュールにコミットできない アジャイルはタイムボックス型（一定期間で棚卸しをして、それを繰り返す）のマネジメントをする。だから、全体としての計画は立てられない。「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。 てか「やってみなきゃ分からない」なんてことは誰でも知っているんだよ。でもさ、それを言わぬが花。大人なんだからコミットメントをしないといけないんだよ。そして、その達成ためには、あらゆる手段を尽くすのです。 2.アーキテクチャ上の無駄が生じる ソフトウェアの構造や構成は工程が進むほどに修正しにくくなり、ずっと残る。だから、アーキテクチャ設計は慎重に全体を考えながらやらなきゃいけない。でも、アジャ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く