2023-11-21 技術的負債に向き合う Online Conference https://findy.connpass.com/event/297813/
ソフトウェアの内部品質に生じる様々な問題は組織設計にその原因があることも多い / Internal Quality Issues Caused by Organizational Design
2023-11-21 技術的負債に向き合う Online Conference https://findy.connpass.com/event/297813/
リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog
どうも、レコメンド商品のシステム開発をしている野川と申します。 私は、2021年にモノタロウに新卒入社し、2022年5月からレコメンド商品の開発に関わり始めました。 モノタロウのレコメンド商品は、下の図の①～④の流れでクライアントサイドで表示しています。大部分の処理はJavaScriptで構成しており、UIもそのHTML部分をjQuery(JavaScript)で作成しています。 図：レコメンド商品表の流れ 入社当時私は、ソフトウェアエンジニアとして、「可読性の低いコードは駆逐するべきだ」「読みやすいコードだけが正義である」「理解しやすいシステムだけが皆を幸せにする」と心の底から考えていました。加えて、「なぜ先輩たちは可読性の低いコードを放置して平気なのか？」と疑問を持つこともしばしばありました。 レコメンド商品周りのコードはまさに可読性の低いコードベースとなっていたため、当事者となった私
12のソフトウェア・アーキテクチャの落とし穴とその避け方
これは、多数派が支配すべきだという意味ではない。委員会によって設計されたアーキテクチャは、肥大化し、焦点が定まらない傾向がある。私たちの経験では、理想的なバランスとは、多様な経験と視点を持つ数人の仲間が、より良い情報に基づいた決定を下すために、主張に異議を唱えることである。 再利用の目標が誤った決定を左右するようなことがあってはならない。その代わり、再利用は理にかなった場合のみ行うこと。 コード、コンポーネント、設計、あるいはコンフィギュレーションの再利用は、最初は良いアイディアのように聞こえる。経営陣は、再利用によってコストが削減され、納期が短縮され、品質が向上すると信じて、このコンセプトを推進したがる。チームは、MVPをより早く提供するために既存のアプリケーションの大部分を再利用することを決定するかもしれないし、かなり成功した製品を提供するために作成された既存のアーキテクチャを再利用す
技術選定の審美眼（2023年版） / Understanding the Spiral of Technologies 2023 edition
Tech BASE Okinawa 2023 2023/09/23(土) https://codebase.connpass.com/event/285901/ https://techbaseokinawa.com/
# ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す https://www.youtube.com/watch?v=PSCmjrrbNkg # Howだけ考えると複雑さを導入して仕事が増える https://soudai.hatenablog.com/entry/2020/08/14/101657 # 質とスピード（2020春版） / Quality and Speed 2020 Spring Edition https://speakerdeck.com/twada/quality-and-speed-2020-spring-edition # 判断と決断の違いと決断のコツ https://soudai.hatenablog.com/entry/2022/01/04/151923 # Worse Is Better -
2024.3.22（金） SRE観点での技術負債 懺悔会 2024 https://mixi.connpass.com/event/312191/
2023/10/31 @ Barフロントえんどう で発表した「リアーキテクトと開発生産性について」です。
「負債にも50パーセントの時間を使ってください」は機能しなかった 西村賢氏（以下、西村）：最初にやったことに価値がありました。そして、次は第2段。 原トリ氏（以下、原）：この説明会やった時に、6月は一回止めますと（話しました）。完全に機能開発を止めて、サポートから流れてくるチケットに関してはオンコール体制を組んできちんと対応するけれど、機能開発はしないというのを戦略として……。 西村：これ、カミナシの歴史で初めてですね。 原：たぶん、初めてだと思います。 西村：そこは「大丈夫なのかな？」とかなかったんですか？ 原：「この1年大きい機能、出てないよね？」みたいな共通認識は、全社にあったから経営の中で意思決定が早かったんです。 西村：なるほど。なにか技術的にうまくいっていないというのがあった。 原：そうです。プロダクトがうまくいっていないという認識がまず全社にあって、かつ、これがカミナシの底力
1. これはなに こんにちは、リファクタリング大好きなミノ駆動です。2023年7月より株式会社スタメンにジョインしました。 この記事は、今後スタメンにおいてサービスの技術的負債を解消する設計戦略についてまとめたものです。 2. 背景、課題 株式会社スタメンは2016年創業。主要サービスであるTUNAG（ツナグ）は、企業のエンゲージメントの構築、つまりお互いを知って理解し、信頼し合う組織を作るための社内コミュニケーションを活性化させるプロダクトです。TUNAGのバックエンドはRuby on Railsで開発され、ローンチから7年をむかえつつあります。 これまでTUNAGは、プロダクトをいかに伸ばすかに注力してきた一方、内部品質や開発効率など「開発者体験」に関する課題が後手に回っていました。本来プロダクトチームはユーザーにとっての本質的な価値にのみフォーカスできる状況が理想ですし、開発者体験が
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
20%ルールに頼らない: 技術的負債を解消する 組織的な取り組み / Developers Summit 2023 Summer
2023.07.27に開催されたDevelopers Summit 2023夏の登壇資料です 登壇者：湯前 慶大(VP of Engineering)
リファクタリングを文化にする 〜組織が技術的負債と向き合うワークショップ〜 - MonotaRO Tech Blog
皆さんこんにちは。 CTO-Office の香川とEC開発-Bグループの竹原です。 11/28に 和田卓人氏(id:t-wada)を講師としてお招きしてテストとリファクタリングのためのワークショップを開催いたしました。 技術者正社員のうちプログラミングをすることの多いメンバー全体の約1/3にあたる総勢53名が参加しての開催となりました。 本記事ではまず第一弾としてワークショップの概要や目的、全体の流れについて簡単にご紹介いたします。 また第二弾(2024年1月公開予定)では、運営とワークショップの問題の作問に関わったメンバーにそこでの学びや実践について紹介いただきます。 開催に至った経緯とMonotaRO DOJO MonotaRO DOJO とは 社内の課題とワークショップの目的 開催経緯 ワークショップの全体像と開催までの段取り ワークショップの全体像 概要 タイムテーブル 開催までの
🐳この記事は「ログラスサマーアドベントカレンダー2023」の28日目の記事です。 次はデザイナーチームの高瀬さんです。 こんにちは、ログラスの松岡です。 ログラスのプロダクトチームでは、ドメイン駆動設計とアジャイルプラクティス（スクラム、エクストリームプログラミング等）を併用していました。 その中で、「アジャイル・フルーエンシーモデル」(以下、省略時には「フルーエンシーモデル」と表記)という概念が多くのプラクティスを取りまとめ、全体感を把握してチームの成長余地を考えるのに役立つものなので、この記事で紹介したいと思います。 アジャイル・フルーエンシーモデルの面白いポイント 面白いポイントはいくつもあるのですが、この記事で紹介するポイントは二つあります。 ポイント①: 技術的負債への対策が組み込まれている 一つは、「技術的卓越性によってアジャイルの持続可能性(サステナビリティ)を高めるという
技術的負債はどこにでもある タイトルにあるように、 いくつかの開発チームと一緒に技術的負債を改善する開発や、それらに関する活動を行うことが多く いろんな取り組みをしていく中で、よかったことがいくつかありました。 もちろん技術的負債を返すのは数ヶ月で終わるレベルのモノは多くなく、 何年から十数年もかかるものの方が多いはずですので、 すべて完了しているわけではないですが、その活動の中であくまで「今のところよさそう」というレベルのものです。 何番煎じかわからないくらいのものですが、 これを読んだ方が取り組んでいくにあたってヒントになればと思います。 普通の話しかありません。 会社全体で合意とSRE これは当たり前ですが、念の為・・ 以前もイベントでお話しさせてもらったりしましたが、 技術的負債は開発体験が悪くなり、モチベーションが上がらなくなるものでもあり、 そこから招く生産性の低下や色々なネガ
技術的負債と向き合う取り組みでよかったもの / positive_efforts_to_tackle_technical_debt
こんなことをやって改善していっているよ、という話
■イベント 技術的負債に向き合う Online Conference https://findy.connpass.com/event/297813/ ■登壇概要 タイトル：3つの⽴場で考える技術的負債への組織的アプローチ 登壇者：VPoE / VPoP 西場 正浩 ■Sansan技術本部 採用情報 https://media.sansan-engineering.com/
何が技術的負債に変わるのか
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
DDDでレガシーコードに立ち向かうリアル / Reality of confronting legacy code with DDD
DDDでレガシーコードに立ち向かうリアル / Reality of confronting legacy code with DDD
負債と言わないことが負債と向き合うこと
技術的負債に向き合う Online Conference - connpassでの発表資料です。
「価値提供スピードを上げるための技術的負債への向き合い方」は、DMMオンラインサロン事業部がこれまで向き合ってきた技術的負債とその解決策について、深く掘り下げるイベントです。ここでプロダクト開発チームの鳥嶋氏が登壇。オンラインサロンアプリにおける技術的負債の取り組みについて話します。 鳥嶋氏の自己紹介 鳥嶋晃次氏：それでは始めます。（タイトルは）「サロンアプリの技術的負債解消への取り組み」です。 （まずは）自己紹介から。鳥嶋晃次と申します。DMM.com イノベーション本部オンラインサロン事業部プロダクト開発チームに所属しています。2022年にDMMに中途入社して、半年経ちました。よろしくお願いします。 （スライドを示して）本日のアジェンダはこちらです。オンラインサロンアプリにおける技術的負債、これまでの取り組み、負債と向き合うための取り組み、現在の取り組みと未来の話、まとめとなっています
2つの不確実性とリファクタリング プロダクションコードを書いていると、リファクタリングをしなければならないコードにぶち当たります。 正直なところリファクタリングは時間がかかるので避けたいものですが、必要になるようです。 必要な理由は大きく分けて2つあります。 1つ目は市場など外部の不確実性に対抗し、既存実装では不要だった抽象化を機能のために追加するためです。 これは因果的に回避できませんが、プロダクトの改善に直結するという意味でポジティブなものです。 2つ目は内部不確実性に対抗し、既存コードの意図の明瞭化や、必要以上の抽象化で身動きが取れない状況を改善するためです。 これは注意深くコードを構成することで回避可能なものです。 今回の記事では後者のリファクタリングを回避するためにどのようにコードを構成すべきかについて、筆者の判断基準を明確化することと、Railsでの適用例を示します。 (事例は
アーキテクチャ刷新にどのように立ち向かったかのお話です。 何を予測し 何を準備し 何を失敗したか そんなお話です。 【プロポーザル】 ある特定の課題を解決するために、未知の技術や方法を採用する必要に迫られる状況は、技術者のキャリアの中で度々出くわすものです。 私も最近、そのような挑戦的な状況に直面しました。 このセッションでは、新しいアーキテクチャや技術基盤を導入する過程で私が行った取り組みや準備、そしてそれらの採用によってもたらされた実際の結果や変化についてお話します。 採用の背景から選択の過程、そして実際の結果までの道のりを通して、未知の技術やアーキテクチャの採用に関する有益な知見や学びを共有いたします。 こちらはGMO Deceloper Day 2023 でお話しました。 詳細は以下をどうぞ。 https://developers.gmo.jp/developersday/?ses
事業・組織も変わらないと、システム開発は変われない 新田智啓氏：スタートアップで起こる変化というところでまず確認したいのが、スタートアップではない進め方の時には基本的に不確実性が低いというか、低くなるようになるべくアプローチする。開発物とかの目標があって、開発期間があって、「これができたら完成だ」みたいなところがわりと明確にあったりすることのほうが多いのかなと思います。 変わるとしても、無理なく緩やかに変わることが大事。なにかコンセンサスがあって、うまく変えられるみたいな。スタートアップはけっこう大きく変わることが前提なのかなと。不確実な事実が明らかになった瞬間に、大きな方向転換が起こると思っています。 なので、技術と組織と事業みたいな3つの関係があって、方向転換の中、技術の中だけで開発が進むわけではないと思っています。 ざっくりした考えですが、「技術」を使ってシステムが出来上がってくると
「Startup Day 2023」は日本中のAWSを利用するStartupが、AWSの知見を披露するHubとなる1日です。2023年はサブテーマに「スタートアップ冬の時代を共に乗り越える」を掲げて、スタートアップが面しているこの逆境をどうやって跳ね除け、成長につなげていけるかを共有します。ここで、株式会社カケハシの新田氏が登壇。まずは、「スタートアップ」「ベンチャー」「スモールビジネス」の違いについて話します。 本セッションで話すこと、話さないこと 新田智啓氏：「技術的負債を抱えながらそれでも生きていく」ということで、他のセッションの技術的な話から、エモい感じの、抽象度の高い話になるので、お願いします。 このタイトルは、『君たちはどう生きるか』と『レガシーコードとどう向き合うか』のタイトルを見て、なんとなく勢いで投稿しました。当時はまだ両方とも見ていなかったんですが、今は履修済みです。
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html ここ数ヶ月の間に、 技術的負債 に関する投稿がいくつかあった。設計上の不備の中で、技術的負債と呼ぶべきものは何か？ 逆に、そう呼ぶべきでないものは何か？といった疑問が挙げられていた。 その一例が、アンクル・ボブの投稿「a mess is not a debt（散乱は負債ではない）」だ。 彼の意見は、次のようなものである。 良い設計方法を知らない人が書いた単に汚いだけのコードを負債と呼ぶべきではない。 長期的な持続性はなくても、 リリースなどの短期的な利益を生み出す設計指針をあえて選択することがあるが、 技術的負債はそのような特別な場合に使うべきである。 要するに、負債を抱えれば早めに価値を生み出すことができるが、 負債はできるだけ早く返済する必要がある。 だが私は、 設計の不備
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
失敗から学ぶ 技術的負債との正しい歩き方 / learn from predecessors
家族アルバム みてねで直面してきた技術的負債 / MIXI KAG 2024
リアーキテクトと開発生産性について
「『50%の時間を技術的負債返済に』はぜんぜん駄目だった」 カミナシ社・原トリ氏が語る、試行錯誤の過程
スタメンの技術的負債解消戦略 - stmn tech blog
技術的負債が生まれる背景を理解して，アーリーからレイター向けの根本的なアプローチを考える
アジャイル・フルーエンシーモデルでアジャイルに技術的負債対策を組み込む
技術的負債と向き合うための取り組みでよかったもの例 - ytake blog
3つの⽴場で考える技術的負債への組織的アプローチ
大規模なアジャイル開発の現場と技術負債 / Technical Debt
iOSエンジニア本領発揮のために、ReactNativeからSwiftへ 技術的負債解消への取り組みで意識した“共通認識を持つこと”
リファクタリングを避けるコードデザイン(Railsを題材として)
アーキテクチャ刷新の現場 / Scene of architectural renewal
技術的負債と向き合う時に必要なのは「広さ・深さ・バランス」 事業やプロダクトの全体を見てこそ、納得の意思決定ができる
スモールビジネスは1次直線、スタートアップは2次曲線 「ベンチャー」に含まれる2つの言葉とそれぞれの定義
技術的負債の四象限 - Martin Fowler's Bliki (ja)