エンジニア達の「完全に理解した」Talk #79

2026年7月28日にオンライン開催した、完全に理解したTalkのスライド資料と概要まとめです。

完全に理解した、それはまさに「分かった気になったくらい」の理解できたくらいのもの！「覚えたての知識」や「この知識なら自信出てきた！」みたいなものから「あれ、ちょっと怪しいかも？」となり始めた知識まで自分が話したい知識をなんでもゆるーく話をする会です！

みんなにOUTPUTして、是非自分の実力を高めちゃいましょう！

完全に理解したTalk #79 - Easy Easy

LT1: 技術書典の出典を完全に理解した（@ic_lifewood）

• エンジニアが自身の知見を「本」という形にして頒布する、技術書・技術同人誌の オンリー即売会「技術書典」 への出展（サークル参加）方法を解説した発表
• 出展までの流れは ①ユーザー登録と申込 → ②サークル情報・審査説明文・銀行口座の登録 → ③運営による審査 → ④頒布物登録と見本誌提出 → ⑤オフライン／オンライン併用での頒布 という5ステップで整理された
• 執筆環境は ReVIEW-Template・Vivliostyle・Typst・Word など、表紙まわりのデザインは Adobe 製品や Sketch・GIMP を使うかデザイナーへ依頼、入稿先は 日光企画・ねこのしっぽ といった、タスクごとの具体的な選択肢 が提示された
• 失敗談からの教訓として、「推敲を怠らない」（印刷後に誤字を見つけたときの悔しさ）「印刷料を侮らない」（見積もりの誤算） のほか、共著時の連絡不備によるリスクや、見本誌にはカバーを付けておくべきといった実地のノウハウも共有
• 発表者自身も 今回が初出展 で、npm ライブラリ本や MDN 翻訳活動の紹介本など 3冊の新刊を出す予定 であることが予告された発表だった

技術書典（公式サイト）

https://techbookfest.org/

LT2: サビ始まりのエンジニアリング（@paseri_kurosawa）

• サブスク普及の影響で音楽に「サビ始まり」の曲が増えた一方、曲そのものの構造（Aメロ・Bメロ・サビ）は変わっていない、という導入から始まった発表。副題は 「サビだけを聴いて、プロダクト全体を判断してはいけない」
• AI によって UI や API、MVP（Minimum Viable Product：仮説検証のために必要最小限の機能へ絞ったプロダクト）といった 「動くもの」＝サビの部分が高速に作れるようになった 現代を踏まえ、その成果物は本当に完成品なのかと問題提起
• ここで MVP は「完成品を小さくしたもの」ではなく、「検証のために意図的に作っていない部分がある状態」 だと再定義。前提の取り違えが後続の議論を狂わせると指摘した
• しかし動くデモは説得力が強いため、人は 「すでに使えるもの」と誤認しやすく、その結果として設計や運用が軽視され、開発文化が劣化していく悪循環に陥ると警鐘を鳴らす
• 「作ること」自体の価値が下がっていく中で、エンジニアに求められるのは 完成をマネジメントする力。「何がまだ作られていないのか」「なぜ作っていないのか」をステークホルダーへ説明できること が価値になると主張
• 結論は 「MVP を MVP として扱わせること」。完成の定義を関係者と共有し、サビだけで全体を判断させない 認識の設計 こそがエンジニアリングの本質である、と締めくくられた発表だった（※詳細はZenn記事に記載）

https://zenn.dev/paseri_kurosawa/articles/6b25e9cf02e5e6

動画アーカイブ

各セクション開始タイムスタンプ:

• 29:57 LT1: 技術書典の出典を完全に理解した
• 1:03:13 LT2: サビ始まりのエンジニアリング

関連リンク

🌐ポータルサイト

https://easy2.jp/

🙌connpassコミュニティページ

https://easy2.connpass.com/

📺️『Easy Easy』YouTubeチャンネル

https://www.youtube.com/@talk9929

📝コミュニティ運営紹介記事

https://zenn.dev/easy_easy/articles/3534caabc4f028

https://zenn.dev/easy_easy/articles/89318e4d0acb4f