Claude Code / Codex ユーザーのための誰でもわかるHarness Engineeringベストプラクティス
カスタムリンター戦略: エージェント向けルールの設計 Factory.aiの4カテゴリ Factory.aiがオープンソースで公開したeslint-pluginは、エージェント向けリントルールを4カテゴリに分類しています。 Grep-ability(検索容易性): デフォルトエクスポートよりnamed exportを強制。一貫したエラー型と明示的なDTO。エージェントがコードベースをgrepで走査する際の命中精度を高める Glob-ability(配置予測可能性): ファイル構造を予測可能に保つ。エージェントがファイルを確実に配置・発見・リファクタリングできるようにする アーキテクチャ境界: クロスレイヤーのインポートをブロック。ドメイン固有のallowlist/denylistで依存方向を強制 セキュリティ/プライバシー: 平文シークレットのブロック、入力スキーマのバリデーション強制、e
大規模クラウドインフラ設計・構築案件の歩き方(AWS-28)がインフラエンジニアに刺さりまくりな内容だった | iret.media
AWS Summit Japan 2024 Day1の「大規模クラウドインフラ設計・構築案件の歩き方」のセッションについてレポートです。 控えめに言っても満足度の高いセッションでした。 大規模なクラウドインフラの設計構築運用に関わる方なら首がもげるくらい頷きが多い内容であり、アーカイブが公開された際はもう一度見たいと思うほど…。 セッションの内容には「設計書の一覧サンプル」や、「アプリ/インフラチームの責任分界」といった界隈でも関心が高い内容に触れられています。 考え方のひとつとして参考にしていきたい内容がモリモリでしたので、シェアさせていただきます。 セッション概要大規模クラウドインフラ設計・構築案件の歩き方 Level 300: 中級者向け スピーカー: アマゾン ウェブ サービス ジャパン合同会社 仲谷 岳志 様 クラウド技術のコモディティ化により、エンタープライズ分野では近年、AW
こんにちは！逆瀬川ちゃん (@gyakuse) です！ 今日はCoding Agent時代のドキュメントについて、最近考えていることを書いていきたいと思います。悩み中なので、荒れた内容になっていますが、ご容赦を。コード規模、チーム規模などなどによって、正解は異なるものだと思います。あくまで私の実践の一例として読んでくれれば幸いです。 以前書いたCoding Agent時代の開発ワークフローやClaude Codeのシステムプロンプト解説記事でCLAUDE.mdやAGENTS.md、ADRの運用について少し触れましたが、そもそもドキュメントって何のために書くんだっけ、Agentが読むドキュメントはどうあるべきなんだっけ、というところをもう少し掘り下げて考えたいなと思っていました。まだ結論が固まっているわけではないのですが、最近の実践から見えてきたことをまとめてみます。 そもそもドキュメントの
アーキテクチャ設計の民主化とADR(Architectural Decision Records)による意思決定の未来 - Facilitating Software Architecture の読書感想文 - じゃあ、おうちで学べる
年末年始の慌ただしい時期に、数ある選択肢の中からこちらの記事をお読みいただき、誠にありがとうございます。 人生を定期的に振り返ることには、本書で取り上げられているADR（Architecture Decision Records）に通じる素晴らしさがあります。過去の決定とその背景を記録し、将来の自分や他者が参照できる形で残すことは、個人の成長にとって貴重な資産となります。そんな観点から今年を振り返ってみると、2024年は私自身にとって大きな試練と変化の年でした。 印象的だったのは、ある時期に突然、技術に対する興味や情熱が完全に失われてしまったことです。それは技術分野に限らず、仕事全般や私生活にも波及し、何をするにも意欲が湧かない、深い無気力状態に陥ってしまいました。 しかし、この困難な時期を経て、いくつかの意味のある変化が生まれました。私は以前から技術書の書評を書いていましたが、これは主に
組織が記憶喪失になるのをどうすれば ～ ryuzee技術顧問にきいてみた - NTT docomo Business Engineers' Blog
何か決定した事実は実装や規則の形で残っているものの、決定までの経緯をチームメンバーが覚えていない――。 この記事では、そうした組織が記憶喪失になることにどう対処していけばよいか、NTT Comの技術顧問である吉羽龍太郎 (@ryuzee) さんにふらっと相談してみたら一瞬で突破口が見つかった＆話に奥行きが出た話を共有します。 目次 目次 軽く自己紹介 事の発端 ryuzeeさんの油セール 実際に聞いてみた 新たなる概念：ADR ADRの実践：その1 何を書くか ADRの実践：その2 どこに書くか ADRの実践：その3 どう書くか 相談を受けて試しに書いてみたADR まとめ 軽く自己紹介 イノベーションセンターの小林 (@ppyv) です。 開発・検証用PCの開発に一段落つけた後、社会人学生としてたっぷり2年間学習を積んでいました。 いまはイノベーションセンターで働く社員のみなさんに、よりよ
宿泊開発チームでエンジニアをしている @kosuke1012 です。チームで ADR を書き始めて1年くらい経ったので、その感想を書いてみたいと思います。 この記事は 一休.comのカレンダー | Advent Calendar 2023 - Qiita の13日目の記事です。 ADRとは アーキテクチャ・ディシジョン・レコードの略で、アーキテクチャに関する意思決定を軽量なテキストドキュメントで記録していくものです。 出典はこちらで、 Documenting Architecture Decisions わかりやすい和訳は以下の記事が、 アーキテクチャ決定レコードの概要 | Cloud アーキテクチャ センター | Google Cloud アーキテクチャ・デシジョン・レコードの勧め | 豆蔵デベロッパーサイト アーキテクチャの「なぜ？」を記録する！ADRってなんぞや？ #設計 -
起業なのか請負開発か趣味のプロジェクト（ペットプロジェクト）かによって状況は異なりますが「私のチームの開発者は私１人だけです」という個人開発においても、ADRは有効なツールとなりえます。 ADRとは何か？ ADR（アーキテクチャデシジョンレコード）は、ソフトウェアアーキテクチャにおける重要な設計判断とその根拠、影響、関係する検討事項などを記録した文書です。 一見、現代的な響きですが、その実態はシステム設計ドキュメントの一部です。 "ADR"で検索すると真っ先にヒットするアーキテクチャの入門書『Design It! ―プログラマーのためのアーキテクティング入門』では、ADRは「アーキテクチャ手法に対する開発者寄りのアプローチ」と説明されており、アーキテクトと開発者自身がアーキテクチャに関する意思決定を記録し、共有するための手法として位置づけられています。 アーキテクチャデシジョンレコード（A
日々の意思決定の積み重ねを記録するアーキテクチャ・デシジョン・レコード / Architectural Decision Records
2023年7月27日「Developers Summit 2023 Summer」にて 「日々の意思決定の積み重ねを記録するアーキテクチャ・デシジョン・レコード」というタイトルで「ADR」について発表した資料です
継続的ドキュメンテーション: Github DiscussionsとADRのすすめ - LIFULL Creators Blog
こんにちは。テクノロジー本部のyoshikawaです。好きなW3C Recommendation は RDF 1.1 Concepts and Abstract Syntax です。 会議やチャットでのやり取りの決定事項・議事録、アプリケーションや機能の設計書・仕様書、READMEなどなど... LIFULLの開発現場においては、ソースコード以外にもこのように様々な文書の管理・蓄積(=ドキュメンテーション)を実施しています。 多くの開発者・メンバーがドキュメンテーションの重要性やその恩恵は理解はしているものの、なかなかうまく情報の蓄積・管理ができない、 その結果、本質的ではない調査に時間を取られてしまいDeveloper Experienceが下落してしまう。 このような課題を抱えているプロジェクトやチームは世の開発現場において少なからず存在すると思います。 LIFULLの開発現場にもこの
新しい時代の開発と組織について
こんにちは！逆瀬川ちゃん (@gyakuse) です！ 今日はCoding Agentと一緒に開発する時代の「開発の進め方」と「組織のあり方」について、自分の実体験ベースで考えていきたいと思います。 いま何が起きているか Anthropicの2026 Agentic Coding Trends Reportによると、GitHubのパブリックコミットの4%がすでにClaude Codeによるものです。年末には20%を超えるペースだそうです。Anthropic社内ではエンジニアあたりのマージPR数が67%増加しているとのことです。 自分の環境ではChatGPT Pro ($200/月) とClaude Code Max x20 ($200/月) を併用していて、複数の離れたプロジェクトを回して現在daily 90 commit / 30,000行くらいです。負荷最小になりつつあり、最高速のマイ
ADRを運用して3年経った僕らの現在地
2024-10-05 YAPC::Hakodate 2024 https://yapcjapan.org/2024hakodate/
優れたアイデアやデザインがあっても、それだけではソフトウェアプロジェクトを成功させることはできません。プロジェクトを円滑に進めるためには、ステークホルダーの理解と支持を得て、チームが協力できる環境を作ることが重要です。本書では、そのために不可欠で効果的なコミュニケーションの方法を解説します。具体的な例やパターンを通じて、適切にメッセージを伝えるためのドキュメントや図の作成方法を紹介します。 まず、ソフトウェアアーキテクチャの視覚表現を活用し、受け手にわかりやすくメッセージを伝える方法を解説します。次に、書面・口頭・非言語コミュニケーションの技法を用いて、相手に意図が正しく伝わるように工夫する方法を紹介します。また、ナレッジマネジメントを強化し、チームや組織の集合的な知識を最適化することで、生産性と革新性を向上させる手法についても解説します。さらに、アーキテクチャに関する重要な意思決定を的確
本書はドキュメントについてはもちろんのこと、たとえば人に伝える際にどうすればよいかやリモートワークで働く際に何を気をつけたらよいかといった、開発現場で遭遇する「コミュニケーション」つまり情報伝達の方法論をいろいろと教えてくれる一冊です。今回は私が印象に残った内容を思考の整理がてら紹介したいと思います。 なんとなくタイトルが気になって買ったのが最初でしたが、思ったより自分の知らない話題が多くて得るものは多かったです。また、なんとなく意識していたものに対して名前がついていたことを知れたのもまた収穫だったと思いました。 開発者とアーキテクトのためのコミュニケーションガイド ―パターンで学ぶ情報伝達術 作者:Jacqui Readオーム社Amazon どんな本か 開発時に出会う情報伝達術についていろいろと体系的に指南してくれる一冊と思って良いでしょう。 まず最初は視覚的なコミュニケーション、つまり
アーキテクチャデシジョンレコード（Architecture Decision Record: ADR）とは、プロダクトやエコシステムに関する重要なひとつの決定を記録および説明する簡潔な文書である。文書は短く、数ページ程度に収め、内容には決定事項、決定の背景、重要な影響を含めなければならない。決定を変更した場合は、文書を修正するのではなく、置き換えた決定にリンクしておく。 ほとんどの文書がそうであるように、ADRの作成にも2つの目的がある。まず、決定の記録である。数か月後あるいは数年後でもシステムが現在のように構築された理由を理解できる。だが、それよりも重要なのが、文書を書くことで考えが明確になる点である。グループの場合は特にそうだ。重要な文書を書くことで、異なる見解が浮かび上がってくる。こうした意見の違いについて議論し、できれば解消することが望ましい。 一般的なルールとして「逆ピラミッド」
アーキテクチャ決定レコードの概要 | Cloud Architecture Center | Google Cloud
GKE Gateway と Cloud Service Mesh を使用してグローバルに分散されたアプリケーションを構築する
kintone フロントエンドリアーキテクチャプロジェクトで大切にしていること - Cybozu Inside Out | サイボウズエンジニアのブログ
kintone フロントエンドリアーキテクチャプロジェクトリーダーの @koba04です。 昨年末から、kintone フロントエンドリアーキテクチャをプロジェクト（フロリア）として再構成してスタートさせました。フロリアという名前は社内での公募により決定しました。 今回はプロジェクトで目指していることについて紹介します。本プロジェクトの開始前に Cybozu Meetup で話したスライドや動画も公開されているのでよければ見てください。 speakerdeck.com www.youtube.com これまでの取り組みについては下記の記事にて紹介しています。 blog.cybozu.io 3 行まとめ フロリアのゴール 全てのページが React によって表示されている 現状 今後 フロントエンドが技術的にもチーム的にも分割されている モノリスな構成からの脱却 アーキテクチャとチーム（
この記事は、株式会社カオナビ Advent Calendar 2023の２日目です。 カオナビでは2022年9月からArchitectural Decision Record（以下ADR）を導入開始しました。本記事ではADRを導入し実際に一年間運用して見た経過をご報告しつつ、導入のポイントや注意点について紹介します。 ADRをなぜ導入したのか？ まずADRについて簡単に説明すると、「アーキテクチャー設計の記録をドキュメントとして残すこと」 です。Michael Nygardのブログ記事が初出のようです。 ソフトウェア開発を行っていく間には、途中で様々な設計決定をする必要があります。例えばウェブアプリケーションであれば、データベースはMySQLにしようとか、キャッシュはRedisを使おうとかという実行環境の決定の話から、実際のプログラムの基本構造といったところまで様々です。 この設計決定は、
ROUTE06 でソフトウェアエンジニアをしている @MH4GF です。 ROUTE06 ではエンタープライズ向けビジネスプラットフォーム「Plain」を開発しています。この記事では 2023 年 8 月に Plain クラウド EDI の Web フロントエンドで採用している技術について、その選定理由をまとめました。 現代の Web フロントエンド技術は領域ごとに選択肢が多く、プロダクトに最適な技術選定をする上で検討事項が多いと感じます。この記事がフロントエンド技術選定において参考になれば幸いです。 前提 プロダクトの特徴 技術選定に影響するプロダクトの特徴を箇条書きでまとめます。 エンタープライズ向け SaaS 現在開発中のプロダクトは商取引におけるクラウド EDI のドメインにフォーカス Plain が解決する課題は、元々フルスクラッチで開発すると 1 年かかるプロダクトの開発期間を
インクリメンタルに新しい技術を取り入れる方法では、VueからReactへ段階的に移行していったという話を紹介していました。 このReactの採用を決定してから大きな論点となったのは、ReactでCSS(スタイル)をどのように書くかについてです。 Reactのスタイリング方法には、デファクトと言えるものはありません。 Styling and CSS – React CSSファイルとclassNameを使う方法、CSSファイルをimportするCSS Modules、JavaScriptでCSSを書くCSS in JSなどさまざまな方法があります。 スタイリングライブラリの選定は、表現力はそこまで大きく変わりませんが選択肢が多過ぎます。 そのため、VueやReactを選ぶといった技術選定よりも難しい部分があります。 KARTE Blocks(以下、Blocks)では、最終的にReactのスタイ
意思決定を記録するArchitecture Decision Record (ADR)の話 - NIFTY engineering
この記事は、ニフティグループ Advent Calendar 2023 1日目の記事です。 前段の話 私が所属するプロジェクトでは、Design Docsでソフトウェアの設計や、目的、背景などを記述しており、継続的に更新しています。 Design Docsには、細かな設計方針や、その意図は明確に記述されていますが、読みやすさの観点から結論や重要なポイントのみを載せるようにしています。なので、粒度の細かい情報が失われてしまうということが起こってしまいます。 これでは新規参入者になぜ他の選択肢を選ばなかったか、なぜこの選択肢を選んだのかについて伝授されません。 未来の運用者は数ある選択肢からの導入理由や、決定の過程や議論した内容がわからないまま機能の追加や改修を行わなければなりません。 これが積み重なっていくと日々の運用のコストが膨らんでいき、運用したくないシステムになってしまい、技術的負債と
こんにちは、虎の穴ラボのKanonです。 今回は僕が所属するチームで新たに始めたADRを書く取り組みについてです。 実際にADRを始める準備から、実際に3ヶ月ほど運用してみてどうだったかをお話します。 「ADRってなに？」っていう方や、同じくADRの導入を検討されている方の参考になれば幸いです。 導入のきっかけ ある日。これまで動いていたCIがとあるライブラリのバージョンが古いことによりビルドに失敗するようなりました。 原因を調べていくと、どうやらそのライブラリのバージョンは以前から上げずに固定されているようでした。 けど、「これまでどうしてバージョンを上げていなかったのか？」「そもそもなぜそのライブラリを導入したのか？」という理由がわからない状況でした。*1 結局バージョンを上げる方向で対応したのですが、この「どうして？」という経緯は結局わからないまま。 この「"どうして？"がわからない
こんにちは、ヘンリーの Lead Architect の @kohii です。 弊社ではレセコン一体型クラウド電子カルテの Henry を開発・提供しています。 最近 Henry のバックエンドをモノレポ化したので、その戦略やプロセスについて書きたいと思います。 こちらは前編となっており、モノレポ移行の手法やテクニックの話は後編で説明します。 dev.henry.jp Why モノレポ？ ざっくり説明すると、既存のマイクロサービス/チームの分界点を抜本的に見直し、ドメイン（業務の領域）による分割を目指すため、一旦モノレポにまとめて、理想的な構造の切り出しをやりやすくするという目的です。 モノレポ化前のシステム/チームアーキテクチャ バックエンド Henryのバックエンドはマイクロサービスになっていますが、以下の2つのサービスが大部分を占めています。 henry-general-api …
はじめに レバテック開発部、SREチームに所属している金澤です。 弊社開発部では、Datadogで行っていた監視からNewrelicを用いたオブザーバビリティへの移行を行う決定をしました。 そして、なぜオブザーバビリティを採用したのか、DatadogからNewrelicへ移行したのかといった意思決定をADRとして記録し、社内に展開しています。 今回はこのADRの内容を公開します！ ※本記事はNewrelic、Datadogを肯定、否定するものではございません。 ADR コンテキスト 事業軸 レバテックの事業戦略は事業ポートフォリオ構想に従っている 既存の事業を拡大させながら新規サービスを生み出し続ける 事業ポートフォリオ構想 開発軸 事業領域の大きさ、深さが拡大し必要なドメイン知識が肥大化 スケーラビリティとアジリティの担保が困難になってきた バグ、障害の発生 レビュー工数の増加 新規参画
ADRは書く機会より読む機会のほうが多いのだけど、読んでいて、冗長だったり、長いと感じると、もっと小さくならないの？って聞きたくなる。 それと同時に、失礼なことをしてないかハラハラする。 これがコードだったら、文のレベルと振る舞いのレベルは切り離されているので、振る舞いを変えずにリファクタリングして小さくできることは明らか。 文章の場合は、削ると、文章が働く役割は自明でないことから、せっかく書いたんですけど、みたいな気分になるような気がする。 文章を扱うときには、問題vs私達になりにくくて、容易に人vs人になってしまう。 普段、編集提案機能のないツールでADRを書いていて、議論のコーナーを作って自然文でやり取りしているのだけど、これではツールの支援が足りなくて、めんどくさい。 レビュワーという立場でファシリテーションしに行くか、意見だけ書いて著者にファシリテーションしてもらうかなど、どの強
【新人エンジニア】MVCモデルの進化版！？ ADRが使いやすかったお話 - Hajimari Tech Blog| 株式会社Hajimari
こんにちは！ 7月からインターン生として株式会社Hajimariに入社した、難波 慧人です。 現在は、TUKURÜS事業部で受託開発の業務を行っています！ 今行っている案件では、サブスクリプション型動画配信サイトの、新規機能開発・運用保守を担当しています！ 開発言語に関しては、 バックエンドはPHP（laravelフレームワーク）を用いており、アーキテクチャはADR（Action Domain Responder）を採用しています。 案件にジョインした当初、MVCアーキテクチャしか知らない私でしたが、ADRの有用性が少しずつ理解できてきました！ そこで今回は、MVCアーキテクチャと、ADRアーキテクチャの違いについてご紹介したいと思います！！ また、各項目にサンプルコード（ユーザーの一覧、詳細機能）を示していきます！！ ■MVC（Model View Controller）とは？？ 引用元
ADR実践で目指す技術的卓越：『要はバランス』を見極める力を鍛える - Cybozu Inside Out | サイボウズエンジニアのブログ
この記事は、CYBOZU SUMMER BLOG FES '25の記事です。 本記事の狙い こんにちは、iOSエンジニアの内田です。 みなさんは自信を持って意思決定を行えていますか？ 「なぜこの決定をしたのか、あとからわからない」 「チームメンバーに意思決定を説明しても、うまく伝わらない」 このような悩みを抱えている方は少なくないのではないでしょうか。 そんな方にお勧めしたいのがADR（Architectural Decision Record）です。 社内にADRを運用しているチームがあります。僕はそこに加わり、「良いADRとは何なのか」がわからない状態から始まりましたが、試行錯誤を重ね、今では自分でも実践し運用できるようになりました。 その過程で思ったよりもハマりがちなアンチパターンがあることに気づいたり、質の高いADRを書く技術を身につけることで意思決定の質を向上させるだけでなく、技
はじめに こんにちは。計測プラットフォーム開発本部バックエンドチームの佐次田です。普段はZOZOMATやZOZOGLASSなどの計測技術に関わるシステムの開発、運用に携わっています。去年の夏に、ZOZOFITというサービスを北米向けにローンチしました。 本記事では、ZOZOFITのローンチまでに遭遇した意思決定における課題と、ADRというドキュメンテーション手法を用いた解決までの取り組みについて紹介します。 目次 はじめに 目次 計測プラットフォーム開発本部 バックエンドチームとは ZOZOFITとは 開発中に直面した課題 過去の背景が分からず決断しにくい 意思決定の結論が追いにくい 意思決定の認識合わせに時間がかかる ADRの導入 ADRとは 展開 ADRのフォーマット 使用ツール チームへの展開 ADRの一例 振り返り 課題はどう解決されたのか メリット デメリット 最後に 計測プラッ
Developers Summit 2023 SummerでADRについて発表しました & ベストスピーカー賞を受賞しました🎉 - スタディサプリ Product Team Blog
こんにちは。スタディサプリでプロダクトプラットフォームの開発を行っている @highwide です。 少し前の話になってしまいますが、2023-07-27に行われた「Developers Summit 2023 Summer」(以下、「デブサミ」と書きます)にて「アーキテクチャデシジョンレコード」(ADR)についての発表をしましたので、その報告をさせていただきます。 「日々の意思決定の積み重ねを記録するアーキテクチャ・デシジョン・レコード」というタイトルで発表しました。 発表資料はこちらです。 また、デブサミのサイトでは、発表の当日の録画が見られるようです。 途中、自分の声に反応してしまったApple Watchに焦る様子なども見られるかと思います...(恥ずかしい...) codezine.jp ベストスピーカー賞受賞 🎉 また、この度、本カンファレンスにおけるベストスピーカー賞(1位
私のプロジェクトでは Architecture Decision Record (以降 ADR と記載) を導入しています。プロジェクトで ADR を使い始めてから 1 年以上が経過したので、実際に使ってみての感想と今現在の捉え方についてここに残します。 ADR とはなにかという説明や具体的な運用方法については検索したら十分に発見できると思うので、ここでは割愛し、私たちのチームでの経験にフォーカスします。 私たちのチームの状況 私たちのチームは、新しいプロジェクトの開始にあわせて 1 年ほど前に結成したチームです。 現在は 4 人くらいのチームですが、開発スピードを上げるためにフロントエンドとサーバーサイドでほぼチームが独立して動いているような時期もありました。 そのときは最大で 10 人以上が同じプロジェクトに関わっているような状態でした。 私たちのチームでの使い方 ADR の導入はチー
ADRで意思決定し、そのADRを破棄して新しくADRを作成する実例を紹介します - GraphQLクライアントのキャッシュアルゴリズム変更編 - ROUTE06 Tech Blog
ROUTE06 でソフトウェアエンジニアをしている @MH4GF です。2025/03/26 に、Findy Tools さん主催の「実例！フロントエンドの技術選定とその後を ADR から振り返る」というイベントで登壇します。 発表タイトルは「チームの性質によって変わる ADR との向き合い方と、生成 AI 時代のこれから」の予定です。サイボウズ株式会社の @sakito さん、ファインディ株式会社の @puku0x さんとパネルディスカッションも行います。オンラインのイベントなので、ぜひお気軽にご参加ください！ findy-tools.connpass.com 発表に先立ち、私が関わったプロジェクトで運用していた Architecture Decision Record(ADR) のマークダウンファイルをできるだけそのままの形で公開します。 私は ADR を「意思決定をアップデートするた
ADR – アーキテクチャ上の設計判断を記録しよう｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
ADR – アーキテクチャ上の設計判断を記録しよう はじめに 昨年、2022 年に「ソフトウェアアーキテクチャの基礎」[1] という書籍が出版されました。 これは今年、2023 年の 1 月 16 日に発表された「IT エンジニア本大賞2023」技術書部門ベスト10 に選ばれるなど、ソフトウェアエンジニアからの注目が多かった書籍であると言えるでしょう。 そこで紹介された アーキテクチャディシジョンレコード (Architectural Decision Records; ADR) という方法は、この書籍の評判が浸透するにつれ、目に耳にすることが多くなった印象があります。 本記事では、この ADR とはどのような方法であるのか、またそれに対する個人的な考察や雑感について、記述しています。 なお本記事における「判断」「決定」いずれの用語も、Decision の訳語であると解釈していただいて差し
はじめに こんにちは! ソウゾウのSoftware engineerの@gotomoです。「メルカリShops [フライング] アドベントカレンダー2022」の16日目を担当します。本記事ではメルカリShopsの商品画像一括アップロード機能を作ったときの話をします。 商品画像一括アップロード機能とは？ 商品画像一括アップロード機能とは、CSV商品一括登録のために作られた機能で、複数の商品画像を一括でアップロードすることができます。CSV商品一括登録機能ではCSVファイルを用いて商品を複数個一括で登録することができます。その際、CSVファイルと商品画像は別々にアップロードする仕様になっており、事前にアップロードした商品画像の名前をCSVファイル中で指定するようになっています。CSV商品一括登録機能に関する詳しい説明はこちらの機能紹介ページにあります。 CSVファイルよりも画像の方がファイルサ
In a recent podcast about Rust leadership, the BDFL question came up again and Jeremy Soller said (in the understatement of the century) that "I believe Graydon would have said no to some things we all like now". And this echoes a different conversation on reddit where I was reminded that I meant to write down at some point how "I would have done it all differently" (and that this would probably h
https://offers.connpass.com/event/310086/ そのまま口伝で続ける？メルカリ、カオナビ、estieの試行錯誤から学ぶ設計ドキュメントの活用方法 の登壇資料です。 https://qiita.com/hanhan1978/items/067abd…
こんにちは！夏ですね。@kimukei です。 今回は、弊プロジェクトのカイポケリニューアルで ADR を導入しましたというお話です。 ADRとは、「Architecture Decision Record」または、「Architectural Decision Records」の略でアーキテクチャ上で重要な決定を記録するドキュメントです。 詳しくは「DOCUMENTING ARCHITECTURE DECISIONS」 や「Architectural Decision Records」をご覧ください。 また ADR については、以前弊社の酒井が登壇したイベントでも触れられておりますので、こちらの記事もあわせて読んでみてください。 tech.bm-sms.co.jp ADR を導入しましたってエントリは巷には溢れかえっているので、今回はちょっと趣向を変えて実際に私たちが運用している ADR
AWSがアーキテクチャ決定レコードのガイドを公開
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
庄司です。 Michael Nygard 氏は「DOCUMENTING ARCHITECTURE DECISIONS」で、特にアジャイル開発では最初の時点でアーキテクチャが決まることはなく、また包括的なドキュメンテーションには価値がなく、小さなピースのドキュメントが全てのステークホルダーに必要となるため「アーキテクチャ・デシジョン・レコード (ADR: architecture decision record)」と呼ばれるドキュメントを提案しています。 その後、ADR は 2022年の InfoQ のトレンドレポートで「アーリーアダプタ」の位置を獲得し、さらに「Fundamentals of Software Architecture (邦題: ソフトウェアアーキテクチャの基礎)」の中にも解説されています。 この記事では、「ソフトウェアアーキテクチャの基礎」に書かれていることをベースに、A
GitHub DiscussionsでADR（Architecture Decision Record）を管理する - 電通総研 テックブログ
こんにちは、クロスイノベーション本部エンジニアリングテクノロジーセンターの小澤英泰です。 本記事ではGitHub DiscussionsでADRを管理する方法を紹介します。 はじめに ADRとは 筆者チームのGitHubとの関わり方 ADR導入の目的 ADRに備えたい性質 記載内容 運用 ADRの構成 全体構成 個別の説明 タイトル ステータス コンテキスト 決定 影響 コンプライアンス 参考情報 備考 ADRのステータス管理 ステータスの遷移図 個別のステータス Draft（ドラフト） Proposed（提案中） Review Rejected（却下） Accepted（承認済み） Deprecated（非推奨） Superseded（置き換え） 他のドキュメントとの違い ADRの管理にGitHub Discussionsを採用した理由 比較観点 比較検討 結果 Discussions
An Architecture Decision Record (ADR) is a short document that captures and explains a single decision relevant to a product or ecosystem. Documents should be short, just a couple of pages, and contain the decision, the context for making it, and significant ramifications. They should not be modified if the decision is changed, but linked to a superseding decision. As with most written documents,
※ 正確には「知った」のは恐らく半年以上前なんだけど、ちょっと触ったりドキュメントを読んだりした。 設計の基準を明確にして残しておきたい自分の問題意識としては「設計の決定のための検討、比較などの記録が issue や pull-req に埋れがち」というものがある。またこれらは実はそれほど検索しやすくないし、記録を遡ることもやりやすくない。 この問題は実はかなり長いこと意識としては持っていて、何かみんな困っているはずなんだけどなーと思いつつ、全然情報が見つからずに思い出しては放置、思い出しては放置していたのだが、今回の直接のきっかけは以下のツイート。 考えつつ手を動かす方が問題とちゃんと向き合えてて良いでしょって思ったらちゃんと「問題の分解の仕方を考える」って出てきた。教えるときに参照しやすくてめっちゃ良い！ https://t.co/kjkawSiNJM — Takafumi ONAKA
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Coding Agent時代のドキュメントについて考えていること
ADR を1年間書いてみた感想 - 一休.com Developers Blog
個人開発でもADR （アーキテクチャデシジョンレコード）を書くことの利点 - laiso
開発者とアーキテクトのためのコミュニケーションガイド
『開発者とアーキテクトのためのコミュニケーションガイド』 - Don't Repeat Yourself
アーキテクチャデシジョンレコード - Martin Fowler's Bliki (ja)
Architectural Decision Record を一年運用してみた - Qiita
Plainのフロントエンドにおける技術選定(2023年8月版) - ROUTE06 Tech Blog
CSS in JSとしてVanilla-Extractを選んだ話と技術選定の記録の残し方
ちいさくはじめるADR - 虎の穴ラボ技術ブログ
医療スタートアップのバックエンドをモノレポ化した話 〜戦略・プロセス編〜 - 株式会社ヘンリー エンジニアブログ
Datadog→New Relicの移行を決めた際のADRを公開します！
ADRのレビューのスタンスはあまり研究されていない気がする - hitode909の日記
ZOZOFITにおけるADRを利用した意思決定を残す文化作り - ZOZO TECH BLOG
チームにおける ADR 導入から 1 年経った振り返りと感想 - ROUTE06 Tech Blog
Cloud Run上で動く商品画像一括アップロード機能を作った話 | メルカリエンジニアリング
graydon2 | The Rust I Wanted Had No Future
ADRを一年運用してみた/our_story_about_adr
ADRはじめました - エス・エム・エス エンジニア テックブログ
アーキテクチャ・デシジョン・レコードの勧め | 豆蔵デベロッパーサイト
bliki: Architecture Decision Record
Architectural Decision Records を知った
bijutsutecho.com
zenn.dev/kazh
note.com/aerotanz
yan-flash.com
ibarakinews.jp
www.tokyoartbeat.com