「継続性アーキテクト」という生き方 - エス・エム・エス エンジニア テックブログ
介護や医療、ヘルスケア、シニアライフなどの4つの領域で高齢社会の情報インフラを構築している株式会社エス・エム・エスで技術責任者をしている @sunaot です。2015年2月に入社して以来、技術責任者として開発組織づくりやサービスの内製化を進めてきました。 「『継続性アーキテクト』という生き方」というタイトルをつけていますが、タイトルで名詞化しているのは釣りで、アーキテクトの仕事について書いています。これは私がアーキテクトという仕事の可能性について考える中で、「継続性」に注目するとその仕事の価値がより発揮されていくのではないかと考えた内容をまとめたものです。 アーキテクトが抱える葛藤 私は役割柄、採用などでソフトウェアエンジニア（以下、エンジニア）と面談をする機会が多く、年に約200人くらいの方と話をしており、キャリアについて話を聞く機会も多くあります。その中で多くの方のキャリアのゴールと
チームをつくるモブプログラミング / Mob Programming to build teams
デブサミ2020[13-E-8]でのセッションスライドです。
プロダクトを10年運用する チームをつくる / DevSumi2020
この半年で変わったものと変わらないもの - SaaS開発の現場より / Developers Summit 2020 Summer
質とスピード（2020秋100分拡大版） / Quality and Speed 2020 Autumn Edition
質とスピード（2020秋100分拡大版） 2020/11/20 @ JaSST'20 Kyushu
ローンチから10年を経たSaaSシステム開発が抱える問題にどう取り組んだのか | TECHSCORE BLOG | TECHSCORE BLOG
SaaS システムを開発しているみなさま、お元気でしょうか。松本です。 当社プロダクトの Synergy! は 2005 年にローンチした、数千テナントを抱える SaaS 型 CRM システムです。 Synergy! のような SaaS システムはローンチしたらそれで完成ではなく、継続的に機能追加や機能改善を繰り返していくことがユーザーにとっての魅力のひとつです。Synergy! 開発ではこのサイクルスピードが年々落ちており、開発パフォーマンスの維持、向上が大きな課題になりつつありました。 また、ローンチから 10 年を経たプロダクトを、今の時代を反映したプロダクトとしてリニューアルしたいという強い要望も社内から出ていました。これまでも機能強化は続けてきましたが、抜本的なユーザーエクスペリエンスの変革を実現するには、機能を新しくデザインし直さなければなりません。大規模な機能追加や機能改善が
食べログの大規模なレガシーシステムを段階的に改善していく取り組み - Qiita
こんにちは、食べログシステム本部長の京和です。 今年の4月から本部長になりました。さらに4月に娘が生まれました 本エントリでは食べログで1年を通じて取り組んだ、大規模なレガシーシステムの段階的な改善について紹介します。[翻訳] Shopifyにおけるモジュラモノリスへの移行 に続いて2記事目のアドベントカレンダーになります。 どのように段階的に進めるか 食べログは今年で15年目のサービスで、Railsになってからは13年が経過しています。これだけ歴史があればあちこちにガタが来ているのは当然で、無数にある課題に対してどこからどのように取り組んでいくかを最初に決める必要がありました。 まず最初の前提として以下のように考えました。 既存のビジネスや開発を止めるような悪影響を与えない。むしろなるべく早くポジティブな影響を与えていきたい。 これだけ歴史のあるシステムを改善していくのは長い時間がかかる
マイクロサービスでチームを分離したくないマン - まっちゅーのチラ裏
コンウェイの法則とかで、マイクロサービス=組織 という話になることが多いなと感じる。 正解の場合もあるし、不正解の場合もあると思っていて、個人的には小さいチームでもマイクロサービスをやるメリットは技術的にも組織的にもあると思う。 そのメリットを無視してすぐ組織の話に持っていきたくないので、基本分離したくないマンとしての主張を書いておく 技術観点でのメリット いまさら語るまでもないけど、 ドメイン境界の分離 デプロイ独立性 リソースの最適配分 障害の局所化(サーキットブレーカー等) このうち、ドメイン境界の分離だけはモジュラモノリスで対応可能だが、あとの3つにはマイクロサービスが必須。(もっとあるかも) この3つが必要なのにモノリス or モジュラモノリス で進める判断をするということはシステムの表現力を落とすことに直結する。 もちろん、複雑度は増すし難易度も増す。熟練のサーバーサイドエンジ
マイクロサービスチーム編成のベストプラクティスとメルカリでの構想 - Mercari Engineering Blog
今年もMercari Advent Calendar 2018 が始まりました。初日は @stanaka がお送りします。 メルカリでは創業以来開発してきたPHPのアプリケーションから(主に)Goで実装されたマイクロサービスアーキテクチャへの移行を進めています。これまでにMercari Tech Conferenceやその他のカンファレンスでMicroservice化の意義、移行の方法、基盤となるMicroservice Platformの概要などについて様々な発表をしてきました。 現在、来年からの本格的なマイクロサービスアーキテクチャでの開発に向けて、これまでのサービスの施策ドリブンのチーム編成から、マイクロサービスを軸としたチーム編成に移行しようとしています。 しかし、マイクロサービスアーキテクチャを成功させるためには、各種プラットフォームの機能を揃え、それらを利用したマイクロサービス
一休.comでの開発組織改善の取り組みとこれから /improve-ikyu-devlove-x
2019.6.22 DevLOVE Xで登壇したときの資料です。
グローバル展開を支える量子的なサービス設計 #mercariday // Speaker Deck
Mercari DAY 2017の登壇資料です。
Qiita:Teamの開発を通して見つけてきた、Incrementsの文化を作る方法
dotsカンファレンス2016で発表した資料です。
開発の見積もりとスケジュール管理 - クックパッド開発者ブログ
こんにちは。会員事業部の丸山です。 エンジニアが開発を開始する時にはタスクの見積もりとスケジュールを作成行って、実装を進めていくと思います。 しかし1ヶ月を超えるような規模の開発をする場合、なかなか予定通りの期日に終わらなかったりすると思います。 そして大抵の場合、増える方向になりますよね。 今回はそういうことにならないために、私が気をつけていること・実践していることをいくつか紹介したいと思います。 見積もりとは まずは「見積もり」とは何なのかを正しく理解したいと思います。 一般的には「見積もり」＝「全タスクとその工数を洗い出す」というものだと思います。 しかしここで以下のことに気をつける必要があります。 見積もりとスケジュールとコミットメントは違う 見積もりとはあるタスクがどれだけの工数(規模)なのかを算出することです。 対して、スケジュールとはあるタスクがどれだけの工期(期間)なのかを
チャット経由でデプロイする - Qiita
最近開発で利用している、デプロイをチャット経由で行うフローについて説明します。 要点 開発者はmasterブランチで開発する 開発者はデプロイしたいときにBotにお願いする Botはmasterブランチからproductionブランチに対してPull Requestをつくる 開発者はPull Requestを確認してmergeする CIはproductionブランチが変更されるとサーバにデプロイする ChatOps masterブランチからproductionブランチにPull Requestを出す作業は面倒なので、チャット経由で行っています。Heroku上で動かしたRubotyにruboty-githubとruboty-aliasというプラグインを入れて、「デプロイしたい」と発言するとPull Requestを作成するように設定しています。チャット経由で物事を行うようにすると、周知や教育
WebAPIでエラーをどう表現すべき？15のサービスを調査してみた - Qiita
2017-01-05 追記 2016年3月にエラーの標準形式RFC7807「Problem Details for HTTP APIs」が提案され、今日現在proposed standard(標準化への提唱)となっています。こちらも是非ご覧ください。 RFC 7807 - Problem Details for HTTP APIs HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様 最近はREST APIを提供しているサービスが増えてきていますね！また公開されるAPIだけでなく、Microservicesなアーキテクチャを採用して、バックエンドがWeb APIで通信するケースも増えてきているように思います。 APIを使うときはあまり気にしたこともなかったですが、いざAPIを設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「問題から目を背けず取り組む」 �一休の開発チームが6年間で学んだこと
チームでプロダクト開発するための取り組み/cookpadtechconf2017
デザイナーとエンジニアの境界線
AbemaTVの開発スタイル
Service Development at Cookpad 2015 summer internship
CSSを書く、設計する時に参考にしておきたいCSSのガイドライン・スタイルガイドのまとめ
