1. これはなに こんにちは、リファクタリング大好きなミノ駆動です。2023年7月より株式会社スタメンにジョインしました。 この記事は、今後スタメンにおいてサービスの技術的負債を解消する設計戦略についてまとめたものです。 2. 背景、課題 株式会社スタメンは2016年創業。主要サービスであるTUNAG（ツナグ）は、企業のエンゲージメントの構築、つまりお互いを知って理解し、信頼し合う組織を作るための社内コミュニケーションを活性化させるプロダクトです。TUNAGのバックエンドはRuby on Railsで開発され、ローンチから7年をむかえつつあります。 これまでTUNAGは、プロダクトをいかに伸ばすかに注力してきた一方、内部品質や開発効率など「開発者体験」に関する課題が後手に回っていました。本来プロダクトチームはユーザーにとっての本質的な価値にのみフォーカスできる状況が理想ですし、開発者体験が
技術的負債の中身｜wadap
これはエンジニアにとっては比較的当たり前の内容について書いている。そのためどちらかというと非エンジニア向けの内容として書こうと思う。 エンジニアが開発しづらいと感じたり開発速度を妨げる要因としてあげられるのが技術的負債だ。この単語自体はエンジニア意外にも知られる言葉となりつつあるため、わりと幅広い層の人たちが認識している単語だとは思う。実施に私自身が外部から関わっている会社でもよく聞かれる言葉ではあるが、単純に負債としてまとめていること自体が問題なケースも多く見かることが多い。その分類自体が問題の本質になっていることもあるため、自分の観測可能な範囲の情報をもとに書いてみようと思う。 技術的負債とは何か？wikipediaには以下のように書かれている。 技術的負債（英: Technical debt）とは、行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こ
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
クラウドネイティブ技術を日本にも浸透させることを目的に開催された「CLOUDNATIVE DAYS Spring 2021 ONLINE」。ここで原氏が「技術的負債とステークホルダーと説明責任と」をテーマに登壇。まずは、技術的負債とは何か、組織における技術的負債返済までの構図について紹介します。 組織と個人それぞれの技術的負債の解消方法 原トリ氏（以下、原）：こんにちは！ 今日はこんな話をします。（スライドを見て）なんだか面倒くさそうなキーワードばかり並んでいますね。どれも避けて通りたくなるものばかりです。 はじめまして。こんにちは。Tori、あるいは原トリと言います。ふだんはAWSという会社で、AWSのコンテナサービスをよりよいものにするために、いろいろな仕事をしています。 今日はタイトルのとおり、こんな話をしていきます。まずは「技術的負債って何でしたっけ？」という話を軽く整理していこう
20%ルールに頼らない: 技術的負債を解消する 組織的な取り組み / Developers Summit 2023 Summer
2023.07.27に開催されたDevelopers Summit 2023夏の登壇資料です 登壇者：湯前 慶大(VP of Engineering)
以前から「スタートアップのなかで『技術的負債』というものをどう扱うべきなのか」というテーマに対して関心が高かったのだが、今年の6月から「0→1」の新規事業に関わるようになって、自分の中でなんとなく考えがまとまりそうなので、雑に吐き出してみる。最近、社内でも「技術的負債」が話題にあがることが多く、その中で同僚のエンジニアからあがった意見も参考にしている。 そもそも技術的負債とは @t_wada さんの次の記事に答えが書いてある。 【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wada のブログ 個人的には次のように解釈した。 「手を抜いた雑なコード」は技術的負債とは呼ばない。それはただの低品質なコードである 仮説検証や経験からさまざまな学びを得ることは正義 そこで得た「学び」と「現状のソフトウェア」とのギャップを「技術的負債」と呼ぶ このよう
リファクタリングを文化にする 〜組織が技術的負債と向き合うワークショップ〜 - MonotaRO Tech Blog
皆さんこんにちは。 CTO-Office の香川とEC開発-Bグループの竹原です。 11/28に 和田卓人氏(id:t-wada)を講師としてお招きしてテストとリファクタリングのためのワークショップを開催いたしました。 技術者正社員のうちプログラミングをすることの多いメンバー全体の約1/3にあたる総勢53名が参加しての開催となりました。 本記事ではまず第一弾としてワークショップの概要や目的、全体の流れについて簡単にご紹介いたします。 また第二弾(2024年1月公開予定)では、運営とワークショップの問題の作問に関わったメンバーにそこでの学びや実践について紹介いただきます。 開催に至った経緯とMonotaRO DOJO MonotaRO DOJO とは 社内の課題とワークショップの目的 開催経緯 ワークショップの全体像と開催までの段取り ワークショップの全体像 概要 タイムテーブル 開催までの
Javaを富山でやってたはずがSwiftのためにMacBook買ったらRubyでリモートワーカーになってJSの本を出版するまでを思い返す
UIT meetup vol.12『リニューアル戦略発表会(一部から全部まで)』 - connpass https://uit.connpass.com/event/201312/
2019年6月20日、TECH PLAY SHIBUYAにて「CTOが考える、チームで向き合う技術的負債との付き合い方」が開催されました。メドピア・SansanのCTOが、自社における技術的負債といかにして向き合ってきたか、その経緯と取り組みを語りました。（※当初登壇予定だったアイスタイルCTO竹澤氏は体調不良により欠席）。公開Q&Aには、メドピア株式会社執行役員のCTO福村彰展氏と、Sansan株式会社CTOの藤倉成太氏が登場。会場からの質問に回答します。 技術的負債を返す重要性をどう説明するか 司会者：お待たせしました。Q＆Aなんですけど、最初に、みなさん申し込みいただいたときに質問をいくつかいただいていたと思うので、そのなかで質問が多かったものを私のほうで5つぐらい取り上げさせていただいております。そのあと、会場のみなさんから質問を募集して、ディスカッションのようなかたちで進められれ
【後編】開発内製化の5年の軌跡。「消耗戦の悪魔のループ」をどう乗り越えたのか - エス・エム・エス エンジニア テックブログ
エンジニア組織の内製化を進めるには、事業構造、事業戦略、企業文化、人材などの所与の条件を踏まえて、最適な方法を実践することが求められる非常に難易度の高い取り組みです。エス・エム・エスは2015年よりエンジニア組織の内製化に取り組んできました。そのプロセスとそこで得られた反省や学びを技術責任者の田辺に聞いたインタビューの後編です。 tech.bm-sms.co.jp 前編では、2015年の入社から1年半くらいの間にやったことを話しました。リサーチから始めて会社の特性を理解しにいくということと、小さく始めて検証をするというスタートをきり、小さな新規サービスの立ち上げに上流からかかわって、アジャイルな開発がうまくいったということでした。 エス・エム・エスは当時40近い数のサービスを展開していたのですが、最初の1年半で内製化を進める主要なサービスと注力をせず終了するサービスや CMS 化で開発能力
🐳この記事は「ログラスサマーアドベントカレンダー2023」の28日目の記事です。 次はデザイナーチームの高瀬さんです。 こんにちは、ログラスの松岡です。 ログラスのプロダクトチームでは、ドメイン駆動設計とアジャイルプラクティス（スクラム、エクストリームプログラミング等）を併用していました。 その中で、「アジャイル・フルーエンシーモデル」(以下、省略時には「フルーエンシーモデル」と表記)という概念が多くのプラクティスを取りまとめ、全体感を把握してチームの成長余地を考えるのに役立つものなので、この記事で紹介したいと思います。 アジャイル・フルーエンシーモデルの面白いポイント 面白いポイントはいくつもあるのですが、この記事で紹介するポイントは二つあります。 ポイント①: 技術的負債への対策が組み込まれている 一つは、「技術的卓越性によってアジャイルの持続可能性(サステナビリティ)を高めるという
はじめに ソフトウェアと組織経営をめぐる問題で避けては通れないのが、「技術的負債」と言う言葉です。一般には、「早さ」を求めて構築されたシステムの構造的な課題が、徐々に蓄積し、債務であるように徐々に開発速度そのものを遅くして行くと言う現象のことを意味しているように捉えられます。 これは、技術組織を持つ経営者や、ソフトウェアエンジニアではない発注者にとっては理解しにくいものです。またソフトウェアエンジニアであっても「古くなってしまったコード」や「わかりにくコード」全般のことを技術的負債と呼び、それをもって何かを説明したかのように考えてしまうことはままあります。 これらに起因して、双方のコミュニケーションが破綻してしまうこともよく見られる景色です。 技術的負債の経済効果は毎年マイナス12兆円 このような構造的な問題をはらむ技術的負債は、老朽化したレガシーなシステムとして、事業の組織改革を遅らせて
マネージャーが把握しておくべき技術的負債を招く5つの論点
Nicolas Carlo ソフトウェアクラフトマンシップに情熱を捧げ、アジャイルプロジェクト管理、フロント/バックエンドの知見もあわせ持つWeb開発者。 この記事は、著者の許可を得て配信しています。 https://understandlegacycode.com/blog/5-arguments-to-make-managers-care-about-technical-debt/ 経営陣はレガシーコードをリファクタリングさせません！ あなたは自分の現在の状況を把握できていますか？すごくイライラする状況にいるのではないでしょうか。 開発者として、すでに問題が出ている点を修正することに興味がないマネージャーはたくさんいます。 新機能、緊急リリース、バグの修正…そのめちゃくちゃになっているコードベースのリファクタリングを先延ばしに言い訳はいくらでもあります 😭 正しいコードのメリットを説
Battle Conference Under30 の資料です。 https://bcu30.jp/2019/talk/tomatsu-toshihisa/
技術的負債はどこにでもある タイトルにあるように、 いくつかの開発チームと一緒に技術的負債を改善する開発や、それらに関する活動を行うことが多く いろんな取り組みをしていく中で、よかったことがいくつかありました。 もちろん技術的負債を返すのは数ヶ月で終わるレベルのモノは多くなく、 何年から十数年もかかるものの方が多いはずですので、 すべて完了しているわけではないですが、その活動の中であくまで「今のところよさそう」というレベルのものです。 何番煎じかわからないくらいのものですが、 これを読んだ方が取り組んでいくにあたってヒントになればと思います。 普通の話しかありません。 会社全体で合意とSRE これは当たり前ですが、念の為・・ 以前もイベントでお話しさせてもらったりしましたが、 技術的負債は開発体験が悪くなり、モチベーションが上がらなくなるものでもあり、 そこから招く生産性の低下や色々なネガ
技術的負債と向き合う取り組みでよかったもの / positive_efforts_to_tackle_technical_debt
こんなことをやって改善していっているよ、という話
「ITエンジニア本大賞 2021」技術書部門大賞を受賞した『Engineers in VOYAGEー事業をエンジニアリングする技術者たち』。この書籍で紹介された技術的負債を返済するアプローチ手法であるリファクタリング、リアーキテクティング、リプレイスを、VOYAGE GROUPではどう実践してきたのか。そして、各システムの技術的負債に対し、どのように立ち向かってきたのか。同社のエンジニアが挑んできた課題や解決策を、実例を交えながら紹介する。 タワーズ・クエスト株式会社 プログラマ・テスト駆動開発者 和田卓人氏（左上）、株式会社fluct プログラマ 須藤洋一氏（右上）、株式会社VOYAGE MARKETING 福田剛広氏（左下）、元株式会社サポーターズ ねこや氏（右下） 技術的負債を返済するための3つのアプローチ まず和田卓人氏は、事業とシステムとの間の乖離から生まれる技術的負債を返済する
こんにちは。フロントエンドエキスパートチームの@nakajmgです。 私が所属しているフロントエンドエキスパートチームは、プロダクトのフロントエンドを横断的に支援するチームです。今回はフロントエンドエキスパートチームが行っている、プロダクトへの支援活動について紹介します。 フロントエンドエキスパートチームがどういったチームかに関しては、次の記事をご覧ください。 サイボウズのフロントエンドエキスパートチームの紹介 フロントエンドエキスパートチームの活動 サイボウズは主力プロダクトとしてGaroonとkintoneを提供しています。この 2 つのプロダクトはそれぞれ提供開始の時期が 2002 年と 2011 年となっており、浅くない歴史を持っています。 サイボウズの Web フロントエンドは、フロントエンド専任ではないエンジニアがバックエンドと合わせて担当しています。そうした背景もあり、フロン
2019年7月6日、株式会社サイバーエージェントが主催するイベント「Battle Conference U30」が開催されました。30歳以下のエンジニアによる30歳以下のエンジニアのための技術カンファレンスである本イベントには、さまざまな領域で活躍する若手が登壇。企業の枠を超えて、自身の技術・事業・キャリアに関する知見を発表しました。「大規模フロントエンドの技術的負債と向き合う。」に登壇したのは、サイボウズ株式会社・外松俊尚氏。登壇資料はこちら 「技術的負債」といかに向き合うか 外松俊尚氏：はい。それでは「大規模フロントエンドの技術的負債と向き合う」というタイトルで、サイボウズ株式会社の外松が発表いたします。よろしくお願いします。 (会場拍手） 私は今、新卒3年目になるエンジニアです。今はkintoneというプロダクトの開発をしています。最近だとフロントエンドエキスパートチームという横断的
【PR】 2019.10.25 働き方 デジタル化が進んだ今日、経営とITはもはや切り離せない関係にある。となれば、エンジニアが経営戦略や事業戦略にもっとコミットしていてもおかしくないはずだが、大半の日本人エンジニアは、「エンジニアリング」という小さなテリトリーに留まってしまっているのが現実だ。 その一方で、自ら経営を学びキャリアを充実させているエンジニアも存在する。29歳で社会人大学院に進学し、経営を学んだSansanのCTO藤倉成太さんがその一人だ。 ■シリコンバレーで働いて気付いた「技術力向上」だけに固執するエンジニアのダメさ【Sansan CTO 藤倉成太】 ■現場or管理、受託or自社開発、技術or事業貢献？「二者択一の考え方はエンジニアのキャリアを先細りさせるだけ」【Sansan 藤倉成太×エムスリー 山崎聡】 上記記事など、エンジニアtypeでもすでにおなじみの藤倉さんだが、
■イベント 技術的負債に向き合う Online Conference https://findy.connpass.com/event/297813/ ■登壇概要 タイトル：3つの⽴場で考える技術的負債への組織的アプローチ 登壇者：VPoE / VPoP 西場 正浩 ■Sansan技術本部 採用情報 https://media.sansan-engineering.com/
はじめに hey のネットショップ開設サービス「STORES」 の開発フロントエンド組織で EMをしています、 daitasu と申します。 2022年の上半期、私たちのフロントエンドチームで「除雪部」という技術負債解消ワーキンググループ(以下、WGとします)を立ち上げました。 この記事では、「除雪部」とは何なのか、なぜ設立したのか、何をしているのか、半年間の振り返りをご紹介します。 「除雪部」とは 除雪部は、フロントエンド内で、通常のプロジェクト(以下、PJTとします) と並行して、有志数名で集まり、技術負債の解消をハンドリングするWGです。 フロントエンド関連で負債に感じている課題を集約し、優先度付け、必要な各所への連携やタスクの分解をして、「負債を各メンバーが対応可能な状態まで落とし込むこと」、「負債の解消を一歩でも前に進めること」を役割として動いています。 なぜ設立したのか STO
何が技術的負債に変わるのか
Profile id: Songmu (ソンムー) Masayuki Matsuki / 松木雅幸 株式会社ヘンリー VP of Engineering おそらくはそれさえも平凡な日々 http://www.songmu.jp/riji/ https://metacpan.org/author/SONGMU 好きな言語は、PerlとGoと中国語 3 Times ISUCON Winner Using Perl 入門監視 付録C 執筆 「みんなのGo言語」共著者
Oracle Database で機械学習を始めよう! Oracle Machine Learning
Mirrativ Androidエンジニアのmorizoooです。 Mirrativのエンジニアは週4日をプロダクト開発に、週1日を開発体験の向上に時間を割いおり、CTOによる旗振りのもと、エンジニア主導で技術的負債の返済に取り組んでます。 今回は、Androidチームで取り組んだ技術的負債の返済のために行った取り組みについて紹介します。 背景 以前、2019/04に 突撃!!隣のアーキテクチャ - connpass でもお話したのですが、Androidアプリが主に以下の理由でつらい状態なっておりました。 ロジックが散在 今ではあまり使われないライブラリへの依存 JavaとKotlinの共存 speakerdeck.com これに対してAndroidチームで以下の取組みを行いました。 ActivityとCustomViewの再設計 ライブラリの最新化 Kotlin化の推進 それぞれのトピッ
株式会社ラクスが開催するエンジニア向けのイベント「RAKUS Meetup」。今回は「開発戦略・マネジメント・設計」というテーマで、「配配メール」の開発を担当している西原優人氏が、リリースサイクルに影響を与えず円滑にリファクタリングを進めるために実施した工夫について共有しました。 14年目のサービスが経験したリファクタリングの課題 西原優人氏（以下、西原）：「14年目のサービスと今後も歩むためのリファクタリング戦略」と題しまして、株式会社ラクスの西原が発表させていただきます。よろしくお願いします。 まず自己紹介です。西原優人と申します。Twitterをやっているので、よかったらフォローしてください。あまりつぶやいてはないですが（笑）。 経歴ですが、2015年に新卒でラクスに入社しまして、「メールディーラー」や「チャットディーラー」といったサービスの開発を経験し、現在は「配配メール」の開発を
DDDでレガシーコードに立ち向かうリアル / Reality of confronting legacy code with DDD
DDDでレガシーコードに立ち向かうリアル / Reality of confronting legacy code with DDD
ARR20億円を3年で達成したエンジニア組織が実現したDeveloper eXperience～3つの訪れる壁と突破方法～
デブサミ2021登壇資料 #devsumi #devsumiB #devsumi2021
負債と言わないことが負債と向き合うこと
技術的負債に向き合う Online Conference - connpassでの発表資料です。
今月の一日でメドピアに入社してちょうど1年になったCTO室の内藤(@naitoh) です。 主にやっていることはAPI認証基盤の改善です。 この1年でやってきた事を技術ブログで紹介させて頂きます。 背景 メドピア で採用されているバックエンドの言語（フレームワーク）は本 blog のタイトルにもあるように PHP から Rails に移行が行われているのですが、 実は上記以外に Golang(以下 Go) も使用しています。 このあたりの当時の開発背景は下記の記事に書かれておりますのでご参考にして頂ければと思います。 tech.medpeer.co.jp 私が昨年入社した時点でこのAPI認証基盤(API ゲートウェイ)の保守が難しく、Go のわかる開発者がほぼいなかったため機能追加が行えない状態になっていました。 このAPI認証基盤へのユーザーログイン処理時のアクセス負荷が朝方に集中し、メ
はじめに 今年度、新卒で入社した suke です。インターネットではよく omuomugin というアカウントを使っています。現在はゼクシィアプリの内製開発チームでソフトウェアエンジニアとスクラムマスターをしています。 ゼクシィのiOSアプリは2011年から開発されており、レガシーになっている部分も多くありました。本記事では、去年の5月に立ち上がったゼクシィアプリの内製開発チームで取り組んできたレガシーなソフトウェアに向き合うためにやってきたことを書いていきます。レガシーなソフトウェアの定義は様々ですが、レガシーソフトウェア改善ガイドによれば、優れたテストコードがなかったり、ソースコードが変更に対して柔軟でなかったり、いわゆる技術負債が溜まってしまっているソフトウェアのことを指します。 僕らのチームでは、改善の最初のステップとして大きく以下の3つのことをしてきました。 「レガシーソフトウェ
2022年4月新設されたカオナビのCTO室について座談会形式で話す「kaonavi Tech Talk #8 ～部門横断で技術的課題に向き合う！CTO室メンバー座談会～」。ここでCTOの松下氏が登壇。座談会前の発表として、カオナビのCTO室について紹介します。 松下氏の自己紹介 松下雅和氏：カオナビでCTOをしている松下と申します。よろしくお願いします。本日は「部門横断で技術的課題に向き合う！CTO室メンバー座談会」という内容でお送りしたいと思います。 （スライドを示して）まず簡単に自己紹介させてください。私、松下雅和は、@matsukazという（IDで）Twitterなどのアカウントをやっているので、よければフォローなどお願いします。AWS、Node.jsといった技術がけっこう好きです。あと、娘が2人いる2児の父ということで、日々子育てでけっこう苦労して、バタバタしながら仕事をしています
Photo by gdsteam 高村です。開発チームのエンジニアリーダーをしています。 以前、このブログでも前職の大手SIerに入社してからpaizaに転職するまでの話を書きました。 paiza.hatenablog.com 今回は、その転職後に私が何をやっているのか、エンジニアのチームづくり・組織づくりに関してやっていること・考えていることについて書きます。 私が誰でどんな仕事をしているのか paizaの開発チーム全体のリーダーとして、自分で手を動かして開発もするし、メンバーのマネジメント、チームづくり・組織づくり（組織＝チームの集合体）、採用などに関する業務もしています。 paizaはスタートアップ企業で、まだまだ成長しながらいろいろな壁を超えていかないといけないフェーズにあります。そのため、業務的にはリーダーとしてのチームづくり・組織づくりの比重も結構大きい感じです。 ただ、私自身
Evernote（エバーノート） がメジャーアップデートを発表 - iOSに続き for Windows・Mac・Android もまもなく公開予定
Evernote（エバーノート） がメジャーアップデートを発表 - iOSに続き for Windows・Mac・Android もまもなく公開予定 2020 年 9 月 16 日 米国カリフォルニア州レッドウッドシティ – 「すべてを記録し、多くのことを成し遂げる」ための生産性アプリ Evernote ( https://evernote.com/intl/jp/ ) が、新しく生まれ変わりました。新しいアプリでは機能性が改善されています。基盤からのアプリケーションの再設計により、スピード、安定性、拡張性が向上され、迅速な開発が今後可能になりました。長らく待ち望まれていた今回のメジャーアップデートが最初に提供されるのは Evernote for iOS です。今後、同じく再設計された Evernote for Windows・Mac・Android が続く予定です。 本日の Everno
「価値提供スピードを上げるための技術的負債への向き合い方」は、DMMオンラインサロン事業部がこれまで向き合ってきた技術的負債とその解決策について、深く掘り下げるイベントです。ここでプロダクト開発チームの鳥嶋氏が登壇。オンラインサロンアプリにおける技術的負債の取り組みについて話します。 鳥嶋氏の自己紹介 鳥嶋晃次氏：それでは始めます。（タイトルは）「サロンアプリの技術的負債解消への取り組み」です。 （まずは）自己紹介から。鳥嶋晃次と申します。DMM.com イノベーション本部オンラインサロン事業部プロダクト開発チームに所属しています。2022年にDMMに中途入社して、半年経ちました。よろしくお願いします。 （スライドを示して）本日のアジェンダはこちらです。オンラインサロンアプリにおける技術的負債、これまでの取り組み、負債と向き合うための取り組み、現在の取り組みと未来の話、まとめとなっています
プログラミングにおいては、品質の良く無いコードが負債のように積み上がるさまをイメージさせる「技術的負債」という語句が広く用いられているが、これは実際には発案者の意図を外れて意味が独り歩きしているのではないかという話が上がっている（【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 t-wadaのブログ、Ward Explains Debt Metaphor、Ward氏本人による説明動画）。 この話題は、テスト駆動開発で知られるt-wada氏が、発案者のWard Cunningham氏の発言を翻訳したブログが発端となったようだ。Ward Cunningham氏が「負債」という表現を用いたのは1992年の事であるが、当時氏は金融系ソフトウェアの開発に関わっており、そのため問題を上司と共有するために「負債」という用語を用いたのだという。ただし、氏の発言では「負
こんにちは、karahiyo(@karahiyo_n)です。 今回はZucksアドプロダクト事業本部における技術的負債返済との付き合い方とその変化の話になります。 事業としては10年目となり、今回取り上げる技術的負債を抱えているシステムというのはだいたい8年ものになります。8年間は今までのやり方でいい感じにやってこれたのですがシステムも人も事業も業界も変化し今までのやり方だけでは不十分ということで、今後も事業を支えられるシステムであり続けるためにもあらためて技術的負債について向き合いました。 tl;dr 技術的負債への対応観点で今うまくやれてること、自分たちの苦手なことを確認したら対策が見えてきた 必要だったのはチームで技術的負債についてコミュニケーションできるようになることと、負債の把握と管理 チームの在籍年数が長い人から短い若手や内定者アルバイトまで全員が技術的負債の存在を認知し、特定
2019年6月20日、TECH PLAY SHIBUYAにて「CTOが考える、チームで向き合う技術的負債との付き合い方」が開催されました。メドピア・SansanのCTOが、自社における技術的負債といかにして向き合ってきたか、その経緯と取り組みを語りました。（※当初登壇予定だったアイスタイルCTO竹澤氏は体調不良により欠席）。プレゼンテーション「技術で創る事業成長」に登壇したのは、Sansan株式会社CTOの藤倉成太氏。 Sansanのミッションとプロダクト 藤倉成太氏：よろしくお願いいたします。Sansan株式会社でCTOをしています、藤倉と申します。 自己紹介ですけど、別にあまり深く読んでいただく必要はないかなと思いますので、適当に流してください。 これもちょっと会社のミッションに触れておこうかなと思って用意しただけなんですけど、ちなみにSansanという会社を知っている方ってどれくらい
こんにちは。食べログでAndroidアプリ開発をしている @sada と申します。 この記事は 食べログ Advent Calendar 2021 22日目の記事です。 はじめに 先月、TECH HILLS #1 というイベントで登壇させていただきました。 その時の資料はこちらです。 今回は上記資料でも触れている「レガシーコードと向き合う辛さ」についてお話できればと思います。 イベントにご参加いただけた方は発表やその後のパネルディスカッションなどでお話ししたような内容も含まれるかと思います。その点はご了承ください。 簡単にチーム紹介 私は食べログシステム本部アプリ開発部基盤チームに所属しています。 アプリ基盤チームはリファクタリングや環境改善を専門にしたチームで、以下のような業務を行っています。 OSバージョンアップ対応 ライブラリ、ツールの継続的なバージョンアップ・差し替え アーキテクチ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スタメンの技術的負債解消戦略 - stmn tech blog
技術的負債が生まれる背景を理解して，アーリーからレイター向けの根本的なアプローチを考える
組織の技術的負債の返済はなぜ進まないのか？ “工数確保の合意”に関わる意思決定層と現場視点の違い
「0→1」フェーズにおける技術的負債との向き合い方 - jmblog.jp
脱レガシーフロントエンドのために知っておいたほうがいいこと
サイボウズWebフロントエンド脱レガシーの今までとこれから
技術的負債の上手な積み上げ方・返し方
アジャイル・フルーエンシーモデルでアジャイルに技術的負債対策を組み込む
"技術的負債"論の道案内 - アーキテクチャの資本コストと情報の非対称性 - Qiita
大規模フロントエンドの技術的負債と向き合う。
技術的負債と向き合うための取り組みでよかったもの例 - ytake blog
技術的負債を返済するためのエンジニアリングとは？ VOYAGE GROUPの実践に学ぶ【デブサミ2021】
フロントエンドの開発体験向上と脱レガシー - Cybozu Inside Out | サイボウズエンジニアのブログ
大規模フロントエンドの技術的負債と向き合うためにやったこと
「経営会議でメモを取るだけの自分が嫌だった」Sansan CTOが“ただの技術屋”を卒業できた理由 - エンジニアtype | 転職type
3つの⽴場で考える技術的負債への組織的アプローチ
フロントエンド技術負債解消WG「除雪部」を立ち上げた話 - STORES Product Blog
大規模なアジャイル開発の現場と技術負債 / Technical Debt
Androidアプリの技術的負債を返済する - Mirrativ Tech Blog
“14年もの”の技術的負債をどうやって解消した？ ラクスがリファクタリングで取り組んだこと
API認証基盤の改善について - メドピア開発者ブログ
レガシーソフトウェアをチームで改善するためにまずしたこと | PSYENCE:MEDIA
「機能開発優先で技術負債解消が進まない」を変えるために 横断的に動き、採用広報活動も進めるカオナビのCTO室
よいエンジニアチームを作るためにリーダーがやっている6つのこと - paiza開発日誌
iOSエンジニア本領発揮のために、ReactNativeからSwiftへ 技術的負債解消への取り組みで意識した“共通認識を持つこと”
「技術的負債」の概念は間違って広がっている？ | スラド デベロッパー
技術的負債との付き合い方とその変化 - CARTA TECH BLOG
SansanCTOが語る、事業成長と共に考える技術的負債の“返済計画”
食べログアプリでの技術的負債との向き合い方 - Qiita