2026年2月7日土曜日

ヤバすぎるシステム開発現場の話(#1)【システムエンジニア】 - - YouTube動画の解説

ヤバすぎるシステム開発現場の話(#1)【システムエンジニア】 https://www.youtube.com/watch?v=hIqCDy-L7O8　　　　　　　ーーーーー　　　　　この動画を要約し、それぞれについて、雑学や業界話を交えながら、解説してください。 開発に必要な、O/Rマッパーとは何ですか？　　　　　雑学や業界話を交えながら、解説してください。  

この動画は、システム開発現場でよくある「ヤバい」実態を、SE（システムエンジニア）の「ずんだもん」の視点から描いたものです。技術に疎いPM（プロジェクトマネージャー）や、現場特有の不条理なルールに振り回される様子がユーモラスかつ切実に語られています。

要約と、それぞれのポイントについて業界の裏話を交えて解説します。

1. 技術を理解していないPMと「フレームワーク」の不在

内容: ずんだもんが参加したJavaの新規プロジェクトでは、PMが「フレームワーク」や「データベース製品」などの基本的なアーキテクチャを決めておらず、さらには「フレームワークを使わなければならないものなのか」とまで言い出す始末でした [01:49]。

  • 業界話・雑学: 現代のシステム開発において、**フレームワーク（Spring Bootなど）**を使わないのは、車をエンジンから手作りするようなものです。かつては独自の「社内フレームワーク」を作る会社も多かったのですが、保守性が低いため現在はデファクトスタンダード（標準）を使うのが主流です。PMが技術に疎い場合、このように「Javaを使う」という言語レベルの決定だけで満足してしまう「技術的負債」の種が植えられることがよくあります。

2. 「有識者（イエスマン）」の召喚と無理な設計ルール

内容: ずんだもんがSpringの標準的な設計（フォームクラスやバリデーション）を提案しても、PMは「知らない単語を使うな」と拒絶。代わりに自分の意見を肯定する「自称有識者」の部下を呼び、過去の古いシステム（「円定」という謎のシステム）の設計を強要します [04:16] [05:02]。

  • 業界話・雑学: これはIT業界で**「銀の弾丸はない（特効薬はない）」と言われる一方で、「過去の成功体験（または慣習）が唯一の正解」**と思い込むベテラン層との衝突です。特に大手企業やレガシーな現場では、新しい技術よりも「前と同じやり方」が優先されることが多々あります。動画に出てくる「フロントとバックに分けて引数と返却値を定義する」という極端にシンプルな考え方は、Web以前の古いホストコンピュータ時代の設計思想に近いと言えます。

3. オフショア開発と「指示待ち」のジレンマ

内容: 実装は海外の「オフショア」に依頼されますが、彼らは「詳細設計書通り」に作ります。設計書が古い思想で書かれているため、フレームワークの便利な機能を使わず、非効率で冗長なコード（大量の引数、意味のない二重チェックなど）が出来上がってしまいました [06:21] [09:05]。

  • 業界話・雑学: **オフショア開発（ベトナムやインドなどへの外注）**はコスト削減のために行われますが、言葉の壁や文化の違いがあるため、「設計書にないことはやらない」のが基本ルールです。そのため、上流工程（設計）が「アホ」だと、実装も「アホ」になるという「GIGO（Garbage In, Garbage Out：ゴミを入れたらゴミが出てくる）」の典型例に陥ります。

4. 独自の「テーブル設計」へのこだわり

内容: 動画の最後では、PMがずんだもんのテーブル設計（データベースの設計）を「全然ダメ」と全否定し、自分流の設計に無理やり書き換えてしまいます [09:32]。

  • 業界話・雑学: データベース設計（DB設計）はシステムの心臓部です。ここを「古いシステムの真似」や「独自のこだわり」で歪めてしまうと、後にデータの整合性が取れなくなったり、検索スピードが極端に遅くなったりする致命的な問題につながります。エンジニアにとって、技術を知らない上司によるDB設計の修正は、もっとも恐ろしい「デスマーチ」への入り口と言えます。

まとめ: この動画は、**「技術的知識の欠如」と「過去の慣習への固執」**が組み合わさった時に、いかに現場が崩壊するかをリアルに描いています。視聴者（特に現役SE）にとっては「あるある」と笑えない、恐怖のドキュメンタリーに近い内容となっています。

ヤバすぎるシステム開発現場の話(#1)【システムエンジニア】
ぞーりんげんのレトロゲームゆっくり実況 · 7.4万 回の視聴
 

O/Rマッパー（Object/Relational Mapper）は、ざっくり言うと
👉 「プログラムの世界（オブジェクト）」と「データベースの世界（表・テーブル）」の通訳
みたいな存在です。

開発者が毎回 SQL をゴリゴリ書かなくても、普通のクラスやオブジェクト操作だけで DB を扱えるようにする仕組みですね。

■ まず「O/R」の意味

● Object（オブジェクト）

Java・Python・PHP・Rubyなどの世界

例：

User user = new User("Taro", 20);

これは
👉 「ユーザー」という概念をクラスとして表現しています。

● Relational（リレーショナル）

MySQL・PostgreSQL・SQLite などの
👉 表形式のデータベース

例：

id name age
1 Taro 20

● Mapper（対応付け）

つまり

プログラム DB
クラス テーブル
オブジェクト 行
フィールド カラム

この変換を自動でやるのが
👉 O/Rマッパー

■ もし O/Rマッパーが無い世界

昔の開発はこんな感じでした。

INSERT INTO users(name, age) VALUES ('Taro', 20);

さらに…

ResultSet rs = statement.executeQuery(...); String name = rs.getString("name");

つまり

👉 SQL
👉 DB接続
👉 データ変換
👉 型変換

全部自分で書く必要がありました。

■ O/Rマッパーがあると

こうなる：

userRepository.save(user);

裏では

✔ SQL生成
✔ データ変換
✔ トランザクション
✔ 型変換

を勝手にやってくれます。

■ 代表的なO/Rマッパー

あなたが触っている技術とかなり関係あります。

☕ Java / Spring系

● Hibernate

O/Rマッパー界のラスボス的存在

Spring Boot の

👉 Spring Data JPA

は内部でほぼ Hibernate を使っています。

🐍 Python

● Django ORM

あなたが触っていた djangogirls でも使われています。

Post.objects.create(title="Hello")

これでSQLを書かなくて済む。

🐘 PHP

● Eloquent（Laravel）

めちゃ人気です。

💎 Ruby

● ActiveRecord（Rails）

「ORM文化を広めた張本人」

■ なぜO/Rマッパーが生まれたのか

ここが業界的に面白い話です。

☠ 90年代の大問題

オブジェクト指向が広まったのに

👉 DBは表形式のまま

このズレを

「インピーダンスミスマッチ」

（ObjectとRDBの文化衝突）

と呼びます。

例：

オブジェクトは

  • 継承

  • カプセル化

  • ネスト構造

を持つ。

でもDBは

  • 表だけ

  • 行と列だけ

この文化差を埋めるために
ORMが登場しました。

■ ORMのメリット

✔ 開発速度が爆速

SQLを書く量が激減

✔ 型安全

IDE補完が効く

✔ 保守性

クラスを直すだけで済む

✔ DB変更に強い

MySQL → PostgreSQL 変更などが比較的楽

■ 逆にデメリット（ここはリアル業界話）

実はORMは万能じゃないです。

⚠ パフォーマンス罠

有名な

「N+1問題」

例えば：

posts.getComments()

これが裏で

投稿数分 SQL発行

とか普通に起こります。

⚠ SQLを忘れる危険

新人が

👉 DBの仕組みを理解しない

という副作用があります。

結果

「遅い理由が分からない」

エンジニアが量産されることも…。

⚠ 複雑クエリが苦手

大規模サービスでは

👉 ORM + 手書きSQL

のハイブリッドが主流です。

■ 大規模サービスの現実

例えば：

Netflix

→ ORM使うけど超カスタムSQL多用

Facebook

→ ORM嫌いで独自クエリビルダー

ゲーム業界

→ パフォーマンス命なのでSQL直書き多い

■ 思想的な対立

実はORMは宗教戦争レベルで議論があります。

ORM派

「ビジネスロジックが中心。DBは裏方」

SQL原理主義派

「データはDBが支配すべき」

この対立は20年以上続いてます。

■ 歴史雑学

Rails が2000年代に流行った理由の1つは

👉 ActiveRecordが革命的に楽だった

これで

「10倍速く開発できる」

と言われました。

スタートアップ文化を爆発させた裏功労者です。

■ 現代トレンド

最近は少し変化しています。

● 軽量ORM

Prisma、Dapper など

● クエリビルダー型

型安全 + SQLに近い

● NoSQLとの融合

ORMというより ODM（Object Document Mapper）

MongoDBなど。

■ 例え話でまとめると

ORMは

🍣 板前に「寿司ください」と言うだけ
（ORM）

vs

🐟 自分で魚をさばく
（SQL直書き）

どちらが良いかは

👉 店の規模
👉 技術力
👉 目的

で変わります。

■ エンジニアとしての本音アドバイス

プロになるなら

👉 ORMは使いこなす
👉 SQLは絶対に逃げない

この両刀が最強です。

実際トップエンジニアは
「ORMの裏で何が起きているか」
を必ず理解しています。

もし良ければ、少し踏み込んで面白い話も出来ますが、

👉 ORMが内部でSQLをどう生成するか
👉 JPA / Hibernate の仕組み
👉 なぜUUIDとORMは相性が微妙になる事があるか
👉 ORMがマイクロサービスで嫌われる理由

この辺りもかなり業界のリアルで面白いです。

どの方向、掘ってみます？

いいですね、この4つは ORMの「裏側のリアル」 で、
ここを理解すると「初心者卒業ライン」を一気に越えます。
業界でも、この辺を分かっている人は普通に一目置かれます。

雑学と現場話を交えながら、順番にいきましょう。

■ ① ORMは内部でどうやってSQLを生成しているのか

ここ、実はかなり職人芸です。

● 基本構造

ORMは内部でこういう流れになっています。

① オブジェクト状態を監視 ② 変更を検知 ③ SQLを組み立て ④ DBへ送信

● 具体例（Spring / Hibernate）

例えば：

user.setName("Taro");

これだけで DB更新される事があります。

裏では何が起きているか

Hibernateには

👉 Persistence Context（永続化コンテキスト）

というメモリ空間があります。

ここが超重要ポイント

Hibernateは

✔ DBから取得したオブジェクトを記憶
✔ 変更前と変更後を比較

しています。

これを

🧠 Dirty Checking（汚れ検知）

と呼びます。

つまり：

「オブジェクトが変わったぞ」 ↓ 「UPDATE SQLを作る」

という仕組み。

● SQL生成の仕組み（裏側）

Hibernate内部には

👉 メタデータ

が存在します。

例えば：

Userクラス → usersテーブル name → nameカラム

この対応表を見ながらSQLを作ります。

さらに内部では

SQLは文字列をベタ書きしているわけではなく、

👉 AST（抽象構文木）

という構造で組み立てます。

これはコンパイラと同じ技術です。

業界雑学

Hibernateの設計者は

👉 「SQLコンパイラ」を作っている感覚

で開発しています。

■ ② JPA / Hibernate の仕組み

ここは誤解が多いところです。

● JPAとは？

👉 仕様（ルール）

です。

● Hibernateとは？

👉 実装（エンジン）

です。

つまり

JPA = 設計図 Hibernate = 実際の機械

● JPAの役割

JavaのORMを統一するために作られました。

昔は

  • Hibernate

  • TopLink

  • EclipseLink

がバラバラで

地獄の互換性問題がありました。

そこで登場したのが

👉 JPA（Java Persistence API）

● Spring Data JPA の正体

実は三層構造です。

Spring Data JPA ↓ JPA仕様 ↓ Hibernate実装

だから

@Repository interface UserRepository extends JpaRepository<User, UUID>

これだけで動く。

裏では

✔ JPAがルール提供
✔ HibernateがSQL生成

しています。

業界裏話

Springチームは

「Hibernateを隠す」

思想があります。

理由：

👉 実装を差し替え可能にするため

（実際は9割Hibernateだけど）

■ ③ UUIDとORMの相性が微妙な理由

これはかなり実務寄りの話です。

あなたがUUID使っているので、かなり重要です。

● UUIDのメリット

✔ 分散環境で衝突しない
✔ 連番を隠せる（セキュリティ）

● しかしDB視点だと…

UUIDは

👉 ランダム値

です。

● ここで問題発生

DBのインデックスは

👉 B-tree構造

を使っています。

連番IDの場合

1 → 2 → 3 → 4

木構造が綺麗に伸びます。

UUIDの場合

A9F2... 01CD... FFE2...

ランダムなので

👉 インデックスが断片化
👉 キャッシュ効率が悪化
👉 INSERTが遅くなる

業界あるある

「UUIDにしたら急に遅くなった」

は普通に起きます。

● ORMとの相性問題

Hibernateは

👉 エンティティ生成タイミング

に依存します。

連番IDだと

INSERT → DBがID発行

UUIDだと

Java側で生成

これが

✔ 永続化タイミング
✔ equals/hashCode
✔ キャッシュ

に影響します。

最近の対策

✔ UUID v7

時間順UUID

これが次世代トレンドです。

AmazonやPostgres界隈で人気急上昇中。

■ ④ なぜマイクロサービスでORMが嫌われるのか

ここ、超リアル業界話です。

● マイクロサービスの思想

👉 各サービスが独立DBを持つ

● ORMは基本的に

👉 大きなドメインモデルを前提

つまり衝突する

ORMは

「全部の関係をクラスで表現したい」

マイクロサービスは

「サービス境界を分断したい」

● 最大の問題

🚨 Lazy Loading

例えば：

User → Orders → Items

ORMは勝手にDBを横断します。

マイクロサービスだと

それは

👉 ネットワーク越し通信

になります。

つまり

SQL一発 → HTTP数十回

地獄。

● さらに

ORMはトランザクションを前提

マイクロサービスは

👉 分散トランザクションを避けたい

結果：

ORM思想 = モノリス向け

と言われがちです。

■ 現代の落とし所（業界の実態）

実は今は極端じゃありません。

● よくある構成

✔ CRUD部分 → ORM
✔ 複雑クエリ → SQL直書き
✔ 分散部分 → DTO / API設計

NetflixもUberも
完全ORM否定ではありません。

■ 超雑学：ORM論争は哲学戦争

これは実は

🧠 データ中心設計 vs オブジェクト中心設計

という思想戦争です。

DB中心派

「データが真実」

オブジェクト派

「振る舞いが真実」

この対立は

👉 40年以上続いています。

■ さらに深いプロ視点（ちょっと格言）

熟練エンジニアはよく言います。

ORMは魔法ではない。
魔法に見えるなら、まだ理解が足りない。

■ あなたへの個人的アドバイス

（Spring Boot触っているのでかなり重要）

もしORMを武器にするなら：

✔ SQLログは必ず見る

✔ N+1を検知できるようになる

✔ インデックス設計を学ぶ

ここまで来ると
「ORMを操る側」になります。

もし興味あれば、さらにディープな世界として

👉 N+1問題を完全に理解する方法
👉 Hibernateキャッシュ地獄
👉 Entity設計アンチパターン
👉 ORMを捨てた企業の失敗例
👉 CQRSとORMの関係

この辺は、かなり実戦の核心です。

どこを掘りに行きます？

いいところをまとめて聞いてくれましたね。
この4つ、**全部「業務アプリ設計の基礎語彙」**なんですが、初心者だと微妙に混ざりやすい所でもあります。

現場感・雑学・業界の使われ方も交えて、整理しながら説明しますね。

■① バリデーションチェックとは何か

● 超シンプルに言うと

👉 「データが正しいか確認する処理」

です。

● 具体例

ユーザー登録フォームがあったとします。

入力：

  • メールアドレス

  • パスワード

  • 年齢

ここで確認する内容がバリデーションです。

例

✔ 空欄じゃないか
✔ 文字数は適切か
✔ メール形式か
✔ 数値範囲は正しいか

例えば

メール：abc

これは
👉 メール形式じゃない
→ バリデーションエラー

● なぜ必要か（超重要）

① 不正データ防止

DBにゴミが入るのを防ぐ

② セキュリティ

SQLインジェクションなどの入口を塞ぐ

③ UX改善

ユーザーに優しいエラー表示

● 業界雑学

バリデーションは

「システムの門番」

と呼ばれる事があります。

ここが甘いと
システム全体が崩れます。

■② Formクラスとは何か

これはフレームワーク文化の言葉です。

● 役割

👉 「画面入力データを受け取る専用クラス」

● イメージ

画面 → Formクラス → 業務処理 → DB

● 例（Spring系）

public class UserForm { private String email; private String password; }

なぜEntityに直接入れないの？

ここが超大事な設計思想です。

● Formクラスのメリット

✔ 入力専用

画面構造と一致する

✔ バリデーションを書く場所になる

@NotBlank @Email private String email;

✔ セキュリティ向上

DB構造を直接公開しない

● 業界裏話

昔は

👉 Entityを直接画面にバインド

して事故多発しました。

例えば：

管理者フラグが勝手に書き換わる

これが

👉 Mass Assignment脆弱性

です。

Formクラスはその対策として普及しました。

■③ 入力チェックとは何か

これ、実は

👉 バリデーションとほぼ同義

です。

● ただし現場では少しニュアンス違う

入力チェック

画面入力のチェック全般

バリデーション

プログラムや業務ルール含むチェック

● 例

入力チェック

  • 空欄

  • 桁数

  • 形式

業務バリデーション

  • 同じメールが存在しない

  • 在庫がある

  • 年齢制限

● 業界あるある

新人： 「バリデーションやりました！」

先輩： 「業務チェックは？」

ここで衝突しがちです。

■④ 設計書の「エンティ（Entity）」とは何か

これは超重要キーワードです。

● 一言で言うと

👉 システム内の「重要な情報の単位」

● 例

ECサイトなら：

  • ユーザー

  • 商品

  • 注文

これらがエンティティ。

● プログラムでは

@Entity class User { String name; String email; }

● 設計書では

「データモデル」として表現されます。

例えば：

ユーザー ├ ID ├ 名前 ├ メール

■ Entityという言葉の本来の意味

実はDDD（ドメイン駆動設計）から来ています。

● DDDでのEntity定義

👉 「識別子を持ち、同一性で管理される存在」

例

ユーザーは

名前が変わっても同一人物

だから

👉 IDで識別

● Value Objectとの違い

例えば住所

同じ内容なら同一扱い

これはVOになります。

■ FormとEntityの違い（超重要）

ここ、実務で混乱するポイント。

Form

👉 画面都合のデータ

Entity

👉 システムの本体データ

例

ユーザー登録画面

パスワード確認欄

これは

✔ Formには存在
✔ Entityには存在しない

■ 実務でのデータ流れ

画面入力 ↓ Formクラス ↓ バリデーション ↓ Entity変換 ↓ Repository ↓ DB保存

■ 現場の設計パターン

よく見る層構造です。

Controller ↓ Form / DTO ↓ Service ↓ Entity ↓ Repository

■ 超雑学：なぜ用語が増えたのか

実は昔のシステムは

👉 全部1クラス

でした。

しかし巨大化して

  • セキュリティ事故

  • 保守崩壊

  • バグ地獄

が発生。

そこで

「責務分離」

という思想が生まれました。

■ 現場の格言

昔からよく言われます。

画面は嘘をつく
DBは真実を持つ
その間を守るのがバリデーション

■ まとめ

✔ バリデーション

データ正当性チェック

✔ Formクラス

入力専用の器

✔ 入力チェック

主にUI入力の検証

✔ Entity

システムの本体データ

もし良ければ、ここから更に実務で重要な話として、

👉 DTOとFormの違い
👉 EntityをControllerに渡してはいけない理由
yの👉 バリデーションをどの層に書くべきか
👉 DDDでのEntit本当の設計思想
👉 アンチパターン（Entity肥大化問題）

この辺りもかなり「プロ設計領域」です。

どこまで踏み込みます？

いい流れです。
ここからは**「設計が出来るエンジニア」と「コードが書けるだけの人」を分ける領域**に入ります。

しかもこの話、現場では普通に
👉 アーキテクト議論
👉 コードレビュー戦争
が起きるテーマです。

雑学・業界リアル・設計思想を混ぜながらいきます。

■① DTOとFormの違い

まずここ、かなり混同されるポイントです。

● Formとは

👉 「画面入力を受け取る器」

役割

✔ UIと一致
✔ 入力チェックを書く
✔ 画面専用

例

class UserRegisterForm { String email; String password; String confirmPassword; }

confirmPassword は

👉 画面都合のデータ

● DTOとは

👉 「データを層の間で運ぶ箱」

DTO = Data Transfer Object

役割

✔ Controller ⇄ Service
✔ Service ⇄ 外部API
✔ Service ⇄ Repository

例

class UserDto { UUID id; String email; String displayName; }

● 違いを超シンプルに

Form DTO
目的 画面入力 層間データ
UI依存 強い 弱い
バリデーション 書く 基本書かない

● 業界雑学

Formは
👉 MVC文化（Rails・Spring MVC）

DTOは
👉 分散システム文化（API設計）

から発展しました。

● 最近のトレンド

REST API主体の世界では

👉 FormとDTOが融合

している事も多いです。

■② EntityをControllerに渡してはいけない理由

これは設計界の鉄板ルールです。

● 理由① セキュリティ

もしEntityを直接返すと：

UserEntity ├ passwordHash ├ adminFlag

これがそのままJSON化される危険があります。

実際に起きた事故

海外SNSで

👉 管理者権限フラグが漏洩

した事件があります。

● 理由② 仕様変更に弱くなる

DB構造を変えた瞬間：

👉 APIが壊れる

良い設計

Entity → DTO → Controller

● 理由③ Lazy Loading爆発

Entityは内部にORM機能を持ちます。

Controllerで触ると

👉 意図しないSQL発行
👉 N+1問題

が起きます。

● 業界格言

Entityは神殿の奥に置け
Controllerは入口に立て

■③ バリデーションはどの層に書くべきか

これ、宗教戦争レベルで議論あります。

● 現場の現実は「多層防御」

① UI層（Form）

👉 入力形式チェック

@NotBlank @Email

② Service層

👉 業務ルール

同じメール禁止 在庫確認

③ DB層

👉 最終防衛ライン

UNIQUE制約 NOT NULL

● なぜ分ける？

理由は「責務分離」。

UI層だけに書くと

APIから不正データが入る。

DBだけに書くと

ユーザー体験が最悪になる。

● 業界裏話

銀行システムでは

👉 3層どころか5層チェック

が普通です。

■④ DDDでのEntityの本当の思想

ここは哲学寄りですが超重要です。

● ORMのEntityとDDDのEntityは少し違う

ORM視点

👉 DBテーブルの写し

DDD視点

👉 ビジネスルールを持つ存在

● 例

悪いEntity：

class User { String email; }

ただのデータ箱。

良いDDD Entity

class User {

    void changeEmail(String newEmail){
        validateEmail(newEmail);
        this.email = newEmail;
    }
}

つまり

👉 振る舞いを持つ

● DDDの核心

データではなく「意味」を守る

● 雑学

DDDは2003年に

👉 Eric Evans

が提唱しました。

大企業の巨大システム崩壊を救うためです。

■⑤ Entity肥大化アンチパターン

これは現場でめちゃ多いです。

● 典型症状

UserEntity 2000行

中身

✔ DB項目
✔ 業務ロジック
✔ 表示ロジック
✔ APIロジック

全部混在。

● なぜ起きる？

ORMが便利すぎるから。

● 呼び名

👉 God Entity
👉 Fat Model

● 問題

✔ 修正が怖い
✔ テスト困難
✔ 依存関係地獄

● 解決策

✔ Value Objectを分離

Email Password Address

✔ Domain Serviceを作る

UserRegistrationService

✔ 集約（Aggregate）設計

DDDの重要概念です。

● 業界リアル

巨大企業では

👉 Entity分割プロジェクト

が普通に発生します。

■ 超リアル設計フロー（理想形）

Controller ↓ Form ↓ DTO ↓ Service ↓ Entity（ドメイン） ↓ Repository ↓ DB

■ 歴史雑学

90年代システム崩壊の原因トップは

👉 データとUIの密結合

でした。

今の層分離文化はその反省です。

■ 設計者の思考レベル

初心者： 「動けばOK」

中級者： 「保守しやすい」

上級者： 「変更が起きても壊れない」

■ 個人的に超大事な格言

DDD界隈では有名です。

良いモデルは未来の変更を吸収する

もし興味があれば、この先はさらに「設計コア領域」に入ります。

👉 Aggregateとは何か（DDD最大概念）
👉 Repositoryはなぜ必要なのか
👉 Clean Architectureとの関係
👉 CQRSとDTO爆増問題
👉 モノリス設計 vs マイクロサービス設計

この辺は、プロでも理解が浅い人が多いゾーンです。

どこまで潜ります？

投稿者 時刻:

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)