1. これはなに こんにちは、リファクタリング大好きなミノ駆動です。2023年7月より株式会社スタメンにジョインしました。 この記事は、今後スタメンにおいてサービスの技術的負債を解消する設計戦略についてまとめたものです。 2. 背景、課題 株式会社スタメンは2016年創業。主要サービスであるTUNAG（ツナグ）は、企業のエンゲージメントの構築、つまりお互いを知って理解し、信頼し合う組織を作るための社内コミュニケーションを活性化させるプロダクトです。TUNAGのバックエンドはRuby on Railsで開発され、ローンチから7年をむかえつつあります。 これまでTUNAGは、プロダクトをいかに伸ばすかに注力してきた一方、内部品質や開発効率など「開発者体験」に関する課題が後手に回っていました。本来プロダクトチームはユーザーにとっての本質的な価値にのみフォーカスできる状況が理想ですし、開発者体験が
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（後編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 この記事ではそのダイジェストを紹介します。記事は前編と後編の2つに分かれています。今お読みの記事は後編です。 森崎氏による補足説明 前編では、グループA（命名的問題）より、グループB（構造的問題）の方が正答率が大きいということ。一方でグループA（命名的問題）よりグループB（構造的問題）の方が読みにくさを感じた、という点に統計的に有意な差があったことが発表されました。 発表の後、オンラインイベントの参加者からの質問について森崎氏と和田氏
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
クラウドネイティブ技術を日本にも浸透させることを目的に開催された「CLOUDNATIVE DAYS Spring 2021 ONLINE」。ここで原氏が「技術的負債とステークホルダーと説明責任と」をテーマに登壇。まずは、技術的負債とは何か、組織における技術的負債返済までの構図について紹介します。 組織と個人それぞれの技術的負債の解消方法 原トリ氏（以下、原）：こんにちは！ 今日はこんな話をします。（スライドを見て）なんだか面倒くさそうなキーワードばかり並んでいますね。どれも避けて通りたくなるものばかりです。 はじめまして。こんにちは。Tori、あるいは原トリと言います。ふだんはAWSという会社で、AWSのコンテナサービスをよりよいものにするために、いろいろな仕事をしています。 今日はタイトルのとおり、こんな話をしていきます。まずは「技術的負債って何でしたっけ？」という話を軽く整理していこう
2023.07.27に開催されたDevelopers Summit 2023夏の登壇資料です 登壇者：湯前 慶大(VP of Engineering)
以前から「スタートアップのなかで『技術的負債』というものをどう扱うべきなのか」というテーマに対して関心が高かったのだが、今年の6月から「0→1」の新規事業に関わるようになって、自分の中でなんとなく考えがまとまりそうなので、雑に吐き出してみる。最近、社内でも「技術的負債」が話題にあがることが多く、その中で同僚のエンジニアからあがった意見も参考にしている。 そもそも技術的負債とは @t_wada さんの次の記事に答えが書いてある。 【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wada のブログ 個人的には次のように解釈した。 「手を抜いた雑なコード」は技術的負債とは呼ばない。それはただの低品質なコードである 仮説検証や経験からさまざまな学びを得ることは正義 そこで得た「学び」と「現状のソフトウェア」とのギャップを「技術的負債」と呼ぶ このよう
皆さんこんにちは。 CTO-Office の香川とEC開発-Bグループの竹原です。 11/28に 和田卓人氏(id:t-wada)を講師としてお招きしてテストとリファクタリングのためのワークショップを開催いたしました。 技術者正社員のうちプログラミングをすることの多いメンバー全体の約1/3にあたる総勢53名が参加しての開催となりました。 本記事ではまず第一弾としてワークショップの概要や目的、全体の流れについて簡単にご紹介いたします。 また第二弾(2024年1月公開予定)では、運営とワークショップの問題の作問に関わったメンバーにそこでの学びや実践について紹介いただきます。 開催に至った経緯とMonotaRO DOJO MonotaRO DOJO とは 社内の課題とワークショップの目的 開催経緯 ワークショップの全体像と開催までの段取り ワークショップの全体像 概要 タイムテーブル 開催までの
2020/1/19 Kanazawa.js meetup#01
UIT meetup vol.12『リニューアル戦略発表会(一部から全部まで)』 - connpass https://uit.connpass.com/event/201312/
はじめに ソフトウェアと組織経営をめぐる問題で避けては通れないのが、「技術的負債」と言う言葉です。一般には、「早さ」を求めて構築されたシステムの構造的な課題が、徐々に蓄積し、債務であるように徐々に開発速度そのものを遅くして行くと言う現象のことを意味しているように捉えられます。 これは、技術組織を持つ経営者や、ソフトウェアエンジニアではない発注者にとっては理解しにくいものです。またソフトウェアエンジニアであっても「古くなってしまったコード」や「わかりにくコード」全般のことを技術的負債と呼び、それをもって何かを説明したかのように考えてしまうことはままあります。 これらに起因して、双方のコミュニケーションが破綻してしまうこともよく見られる景色です。 技術的負債の経済効果は毎年マイナス12兆円 このような構造的な問題をはらむ技術的負債は、老朽化したレガシーなシステムとして、事業の組織改革を遅らせて
エンジニア組織の内製化を進めるには、事業構造、事業戦略、企業文化、人材などの所与の条件を踏まえて、最適な方法を実践することが求められる非常に難易度の高い取り組みです。エス・エム・エスは2015年よりエンジニア組織の内製化に取り組んできました。そのプロセスとそこで得られた反省や学びを技術責任者の田辺に聞いたインタビューの後編です。 tech.bm-sms.co.jp 前編では、2015年の入社から1年半くらいの間にやったことを話しました。リサーチから始めて会社の特性を理解しにいくということと、小さく始めて検証をするというスタートをきり、小さな新規サービスの立ち上げに上流からかかわって、アジャイルな開発がうまくいったということでした。 エス・エム・エスは当時40近い数のサービスを展開していたのですが、最初の1年半で内製化を進める主要なサービスと注力をせず終了するサービスや CMS 化で開発能力
🐳この記事は「ログラスサマーアドベントカレンダー2023」の28日目の記事です。 次はデザイナーチームの高瀬さんです。 こんにちは、ログラスの松岡です。 ログラスのプロダクトチームでは、ドメイン駆動設計とアジャイルプラクティス（スクラム、エクストリームプログラミング等）を併用していました。 その中で、「アジャイル・フルーエンシーモデル」(以下、省略時には「フルーエンシーモデル」と表記)という概念が多くのプラクティスを取りまとめ、全体感を把握してチームの成長余地を考えるのに役立つものなので、この記事で紹介したいと思います。 アジャイル・フルーエンシーモデルの面白いポイント 面白いポイントはいくつもあるのですが、この記事で紹介するポイントは二つあります。 ポイント①: 技術的負債への対策が組み込まれている 一つは、「技術的卓越性によってアジャイルの持続可能性(サステナビリティ)を高めるという
技術負債は「価値の創出」を妨げる 「技術負債が事業に与える影響はさまざまな領域に波及するが、ソフトウェアに限れば、"価値あるものを作れなかった"という点に集約される」と語り始めた石垣氏。ここでの「価値」とは、売上の創出やユーザー数の増加、リテンション向上につながる機能を指す。すなわち、「価値が作れなかった」とは「事業責任者が立てた、機能やキャンペーンなどの目標を達成できなかったという状況」を意味する。 ではなぜ、多くの費用をかけても価値を創出できない事態に陥るのか。石垣氏は「期限に間に合わなかった」ケースと「作るべきでないものを作ってしまった」ケースに大別し、今回は前者に焦点を当てると示した。 数億円規模の損失をもたらし、事業へのリスクもある技術負債 価値の創出と技術負債にはさまざまな要素が関わるが、とくにソフトウェア事業における事業計画では、予算計画と開発計画が主なカギになることが多い。
Nicolas Carlo ソフトウェアクラフトマンシップに情熱を捧げ、アジャイルプロジェクト管理、フロント/バックエンドの知見もあわせ持つWeb開発者。 この記事は、著者の許可を得て配信しています。 https://understandlegacycode.com/blog/5-arguments-to-make-managers-care-about-technical-debt/ 経営陣はレガシーコードをリファクタリングさせません！ あなたは自分の現在の状況を把握できていますか？すごくイライラする状況にいるのではないでしょうか。 開発者として、すでに問題が出ている点を修正することに興味がないマネージャーはたくさんいます。 新機能、緊急リリース、バグの修正…そのめちゃくちゃになっているコードベースのリファクタリングを先延ばしに言い訳はいくらでもあります 😭 正しいコードのメリットを説
技術的負債はどこにでもある タイトルにあるように、 いくつかの開発チームと一緒に技術的負債を改善する開発や、それらに関する活動を行うことが多く いろんな取り組みをしていく中で、よかったことがいくつかありました。 もちろん技術的負債を返すのは数ヶ月で終わるレベルのモノは多くなく、 何年から十数年もかかるものの方が多いはずですので、 すべて完了しているわけではないですが、その活動の中であくまで「今のところよさそう」というレベルのものです。 何番煎じかわからないくらいのものですが、 これを読んだ方が取り組んでいくにあたってヒントになればと思います。 普通の話しかありません。 会社全体で合意とSRE これは当たり前ですが、念の為・・ 以前もイベントでお話しさせてもらったりしましたが、 技術的負債は開発体験が悪くなり、モチベーションが上がらなくなるものでもあり、 そこから招く生産性の低下や色々なネガ
技術負債が溜まっている勘所について。現場のエンジニアは実際のシステムを触っているので変更や追加をする過程で当事者になるのでおおよそ異変に気づく。 一方、実際にそのシステムに対となるプロダクトに関わっているのはエンジニアだけではない。PdMやEM、事業責任者がいる中でこのメンバーにどう常に変化し続けるシステムアーキテクチャの異変に気づいてもらうのか、自ら気づかせるのかは至難の業である。 とはいえ、つばり一番わかり易いのは工数の予測精度の幅がある。 以下の3つのフェーズがあったときにそれぞれのズレが大きい場合は負債が溜まっていることが多い。（特に、1.と3.） 一般的な視点と現場システムへの理解度のズレ詳細から開発手前での予測のズレ予測工数と実績工数のズレここでいう工数予測がズレるのはエンジニアリングスキルの問題ではなく、システムに関する理解度の認知問題によってズレるケースが該当する 1.一般
こんなことをやって改善していっているよ、という話
「ITエンジニア本大賞 2021」技術書部門大賞を受賞した『Engineers in VOYAGEー事業をエンジニアリングする技術者たち』。この書籍で紹介された技術的負債を返済するアプローチ手法であるリファクタリング、リアーキテクティング、リプレイスを、VOYAGE GROUPではどう実践してきたのか。そして、各システムの技術的負債に対し、どのように立ち向かってきたのか。同社のエンジニアが挑んできた課題や解決策を、実例を交えながら紹介する。 タワーズ・クエスト株式会社 プログラマ・テスト駆動開発者 和田卓人氏（左上）、株式会社fluct プログラマ 須藤洋一氏（右上）、株式会社VOYAGE MARKETING 福田剛広氏（左下）、元株式会社サポーターズ ねこや氏（右下） 技術的負債を返済するための3つのアプローチ まず和田卓人氏は、事業とシステムとの間の乖離から生まれる技術的負債を返済する
こんにちは。フロントエンドエキスパートチームの@nakajmgです。 私が所属しているフロントエンドエキスパートチームは、プロダクトのフロントエンドを横断的に支援するチームです。今回はフロントエンドエキスパートチームが行っている、プロダクトへの支援活動について紹介します。 フロントエンドエキスパートチームがどういったチームかに関しては、次の記事をご覧ください。 サイボウズのフロントエンドエキスパートチームの紹介 フロントエンドエキスパートチームの活動 サイボウズは主力プロダクトとしてGaroonとkintoneを提供しています。この 2 つのプロダクトはそれぞれ提供開始の時期が 2002 年と 2011 年となっており、浅くない歴史を持っています。 サイボウズの Web フロントエンドは、フロントエンド専任ではないエンジニアがバックエンドと合わせて担当しています。そうした背景もあり、フロン
■イベント 技術的負債に向き合う 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言語」共著者
生成AI利用プログラミング：誰でもプログラムが書けると 世の中どうなる？/open-campus202408
株式会社ラクスが開催するエンジニア向けのイベント「RAKUS Meetup」。今回は「開発戦略・マネジメント・設計」というテーマで、「配配メール」の開発を担当している西原優人氏が、リリースサイクルに影響を与えず円滑にリファクタリングを進めるために実施した工夫について共有しました。 14年目のサービスが経験したリファクタリングの課題 西原優人氏（以下、西原）：「14年目のサービスと今後も歩むためのリファクタリング戦略」と題しまして、株式会社ラクスの西原が発表させていただきます。よろしくお願いします。 まず自己紹介です。西原優人と申します。Twitterをやっているので、よかったらフォローしてください。あまりつぶやいてはないですが（笑）。 経歴ですが、2015年に新卒でラクスに入社しまして、「メールディーラー」や「チャットディーラー」といったサービスの開発を経験し、現在は「配配メール」の開発を
Mirrativ Androidエンジニアのmorizoooです。 Mirrativのエンジニアは週4日をプロダクト開発に、週1日を開発体験の向上に時間を割いおり、CTOによる旗振りのもと、エンジニア主導で技術的負債の返済に取り組んでます。 今回は、Androidチームで取り組んだ技術的負債の返済のために行った取り組みについて紹介します。 背景 以前、2019/04に 突撃!!隣のアーキテクチャ - connpass でもお話したのですが、Androidアプリが主に以下の理由でつらい状態なっておりました。 ロジックが散在 今ではあまり使われないライブラリへの依存 JavaとKotlinの共存 speakerdeck.com これに対してAndroidチームで以下の取組みを行いました。 ActivityとCustomViewの再設計 ライブラリの最新化 Kotlin化の推進 それぞれのトピッ
デブサミ2021登壇資料 #devsumi #devsumiB #devsumi2021
DDDでレガシーコードに立ち向かうリアル / Reality of confronting legacy code with DDD
技術的負債に向き合う Online Conference - connpassでの発表資料です。
2024/7/24 Developers Summit Summer 2024の登壇資料です。 https://event.shoeisha.jp/devsumi/20240723
今月の一日でメドピアに入社してちょうど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児の父ということで、日々子育てでけっこう苦労して、バタバタしながら仕事をしています
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年の事であるが、当時氏は金融系ソフトウェアの開発に関わっており、そのため問題を上司と共有するために「負債」という用語を用いたのだという。ただし、氏の発言では「負
自己紹介 - お仕事 2 時期 2008~2012 2013~ 2015~ 2020~ 会社 いろいろ Quipper マチマチ STORES バックエンド Rails Rails Rails Rails, etc. フロントエンド jQuery, Backbone.js etc. Backbone.js etc. React.js React.js, Vue.js 立場 ほぼメンバー いわゆるEM CTO CTO 藤村大介 twitter.com/ffu_ github.com/fujimura note.com/fujimuradaisuke
こんにちは、karahiyo(@karahiyo_n)です。 今回はZucksアドプロダクト事業本部における技術的負債返済との付き合い方とその変化の話になります。 事業としては10年目となり、今回取り上げる技術的負債を抱えているシステムというのはだいたい8年ものになります。8年間は今までのやり方でいい感じにやってこれたのですがシステムも人も事業も業界も変化し今までのやり方だけでは不十分ということで、今後も事業を支えられるシステムであり続けるためにもあらためて技術的負債について向き合いました。 tl;dr 技術的負債への対応観点で今うまくやれてること、自分たちの苦手なことを確認したら対策が見えてきた 必要だったのはチームで技術的負債についてコミュニケーションできるようになることと、負債の把握と管理 チームの在籍年数が長い人から短い若手や内定者アルバイトまで全員が技術的負債の存在を認知し、特定
こんにちは。食べログでAndroidアプリ開発をしている @sada と申します。 この記事は 食べログ Advent Calendar 2021 22日目の記事です。 はじめに 先月、TECH HILLS #1 というイベントで登壇させていただきました。 その時の資料はこちらです。 今回は上記資料でも触れている「レガシーコードと向き合う辛さ」についてお話できればと思います。 イベントにご参加いただけた方は発表やその後のパネルディスカッションなどでお話ししたような内容も含まれるかと思います。その点はご了承ください。 簡単にチーム紹介 私は食べログシステム本部アプリ開発部基盤チームに所属しています。 アプリ基盤チームはリファクタリングや環境改善を専門にしたチームで、以下のような業務を行っています。 OSバージョンアップ対応 ライブラリ、ツールの継続的なバージョンアップ・差し替え アーキテクチ
2つの不確実性とリファクタリング プロダクションコードを書いていると、リファクタリングをしなければならないコードにぶち当たります。 正直なところリファクタリングは時間がかかるので避けたいものですが、必要になるようです。 必要な理由は大きく分けて2つあります。 1つ目は市場など外部の不確実性に対抗し、既存実装では不要だった抽象化を機能のために追加するためです。 これは因果的に回避できませんが、プロダクトの改善に直結するという意味でポジティブなものです。 2つ目は内部不確実性に対抗し、既存コードの意図の明瞭化や、必要以上の抽象化で身動きが取れない状況を改善するためです。 これは注意深くコードを構成することで回避可能なものです。 今回の記事では後者のリファクタリングを回避するためにどのようにコードを構成すべきかについて、筆者の判断基準を明確化することと、Railsでの適用例を示します。 (事例は
クラウドネイティブ技術を日本にも浸透させることを目的に開催された「CLOUDNATIVE DAYS Spring 2021 ONLINE」。ここで原氏が「技術的負債とステークホルダーと説明責任と」をテーマに登壇。続いては、組織における技術的負債の返済のための現場と意思決定層のアクションについて。前回の記事はこちらから。 技術的負債の現場視点のアクション 原トリ氏（以下、原）：では、ここからは技術的負債の返済inアクションという感じで、まずは現場視点での返済の進め方について、ちょっと見ていきましょう。現場視点の整理が済んだら、次は意思決定層の視点です。 まず一般的に、技術的負債の返済の提案や実行は、現場の立場から行われることが多いです。いわゆるボトムアップと呼ばれるものです。日々開発をして、運用している人たちです。理由は明確で、その技術的負債によって生産性低下の悪影響を直接的にモロに受ける立
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
amazonforum.my.site.com