Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
エンジニアのための消す技術〜何かを生み出すエンジニアが消すことに向き合ってみよう〜
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
kawahara kenta
October 15, 2024
Programming
59
0
Share
エンジニアのための消す技術〜何かを生み出すエンジニアが消すことに向き合ってみよう〜
kawahara kenta
October 15, 2024
More Decks by kawahara kenta
See All by kawahara kenta
無理しない、着実にやりきるCDK移行術
kenpi13
5
810
AWS CDKを始める際に コミュニティの知見が大いに役立った話
kenpi13
1
92
Amazon Bedrock Flows使ってみた ローコードでお手軽生成AIフロー作成!
kenpi13
0
120
Step Functions冬休み復習! 直近アップデートと生成AIとの組み合わせ検証
kenpi13
1
88
AWS認定試験12種取得して感じたこと
kenpi13
0
420
Other Decks in Programming
See All in Programming
RSAが破られる前に知っておきたい 耐量子計算機暗号(PQC)入門 / Intro to PQC: Preparing for the Post-RSA Era
mackey0225
3
130
3分でわかるatama plusのQA/about atama plus QA
atamaplus
0
150
YJITとZJITにはイカなる違いがあるのか?
nakiym
0
200
CursorとClaudeCodeとCodexとOpenCodeを実際に比較してみた
terisuke
1
430
「速くなった気がする」をデータで疑う
senleaf24
0
170
10年分の技術的負債、完済へ ― Claude Code主導のAI駆動開発でスポーツブルを丸ごとリプレイスした話
takuya_houshima
0
2.5k
Coding at the Speed of Thought: The New Era of Symfony Docker
dunglas
0
4.8k
Running Swift without an OS
kishikawakatsumi
0
780
PHP 7.4でもOpenTelemetryゼロコード計装がしたい! / PHPerKaigi 2026
arthur1
1
570
Radical Imagining - LIFT 2025-2027 Policy Agenda
lift1998
0
280
KagglerがMixSeekを触ってみた
morim
0
370
2026-03-27 #terminalnight 変数展開とコマンド展開でターミナル作業をスマートにする方法
masasuzu
0
320
Featured
See All Featured
Leo the Paperboy
mayatellez
7
1.6k
The untapped power of vector embeddings
frankvandijk
2
1.7k
Primal Persuasion: How to Engage the Brain for Learning That Lasts
tmiket
0
320
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
133
19k
Digital Projects Gone Horribly Wrong (And the UX Pros Who Still Save the Day) - Dean Schuster
uxyall
0
1.1k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
118
110k
Public Speaking Without Barfing On Your Shoes - THAT 2023
reverentgeek
1
370
What Being in a Rock Band Can Teach Us About Real World SEO
427marketing
0
210
Rebuilding a faster, lazier Slack
samanthasiow
85
9.5k
How to audit for AI Accessibility on your Front & Back End
davetheseo
0
240
Marketing to machines
jonoalderson
1
5.2k
Transcript
エンジニアのための消す技術 何かを生み出すエンジニアが消すことに向き合ってみよう
自己紹介 名前:川原 健太 kawahara kenta 所属:KDDIアジャイル開発センター(KAG) 福岡オフィス オフィス長 / ソフトウェアエンジニア
経歴:西日本鉄道 → チームラボ → KAG 資格:AWS / JSTQB etc.. 好き:写真・旅行・珈琲 X: kenpi1313
Agenda ・はじめに〜身の回りの「消す」 ・消すことを前提に作り出す ・おわりに〜Deletable
なぜ、消すことをテーマにしたのか
エンジニアの仕事は 作り出すこと(0→1 / 1→100)
それだけなのか..?
消すこと
消さないと、増え続ける ・コード ・ブランチ・Pull Request ・チケット ・ドキュメント ・提供しているサービス・機能 ・データ・ログ ・会議
消さないと、増え続ける ・コード ・ブランチ・Pull Request ・チケット ・ドキュメント ・提供しているサービス・機能 ・データ・ログ ・会議 認知負荷
ビルド・読み込み速度 量増大→料金増大 作業時間の圧迫
閑話〜プラクティス
ボーイスカウト・ルール 来たときよりも、美しく (例)コード修正の際に、触るファイルで不要なコードがないか、見回 す。もし発見したら、機能修正とともに、不要コードを削除する。 (別のPull Requestにするとレビューしやすい💡)
消すことを前提に作り出す
消すことから考えて選ぶ(実生活の例) ・大型家具(不要になったら粗大ゴミ) ・家電(業者引取 / リサイクル法) ・インターネット契約(違約金) ・サービス契約(解約導線 電話 or ネット)
消しづらい例① 〜スマホアプリ〜 person = { name: “kenta”, age: 31, nickName:
“kenpi” } person = { name: “kenta”, age: 31, nickName: “kenpi” } 不要になったので消したい 必須項目
アプリのリリース時にバック エンドもリリースするぞ!
エラー・クラッシュ
スマホアプリでは常に互換性を意識する必要がある ・リリースしたアプリがユーザー全員に自動反映されるわ けではない ・ユーザーが自分のタイミングでStoreで更新する ・バックエンドからの返却値が不要になったアプリと、必須 のままなアプリが混在している
特定のバージョン以前のアプリを使えなくし たい(消したい)
強制アップデート 強制的にストアに飛ばしてアップデートを促す 指定したバージョン以降のアプリのみ使われている状態 に”強制”できる 開発初期から、この機能を組み込んでおくことが必要
消しづらい例② 〜新機能が不安定〜 新しく作ろうとしている機能で、利用する外部APIが安定 しておらず、不安要素がある。 機能を消すには、該当コード全体をコメントアウトして再 デプロイする必要がある。
やっぱり挙動がおかしいぞ、フロ ントから消したい...
コード削除対象範囲はどこからどこまでだ・・? 箇所が多いな・・・ デプロイ時間がかかるぞ・・・
シンプルな手順で簡単に消したい
フィーチャーフラグ ``` const flag = true; if (flag === true)
// サービスをON else ``` ``` const flag = false; if (flag === true) else // サービスをOFF ``` ON/OFF
フィーチャーフラグ ・コードの中にtrue, falseのフラグを持っておいて、再デプロイ ・AWS APIGateway ステージ変数の書き換え ・AWS CloudWatch EvidentlyでON/OFFをスケジュール化 →A/Bテスト
最初にフィーチャーフラグの機構を取り入れておく
それはDeletableか? 何かを作り出すときに Deletableかどうか?を意識する
Deletableではないもの ・機能A + 機能B + 機能C が合体したPR・リリース → 機能Bだけリバートしたい・切り戻したい ・削除のための確認事項が不明瞭なもの
→ 存在意図が不明 / 作成者が不明・手順が煩雑 ・削除要件が定まっていないもの → 削除するタイミング・条件が決まっていない
Deletableなもの ・機能A + 機能B + 機能C が分離したPR・リリース → 単体で扱うことができ、単純な作業になる ・削除のための確認事項が明瞭なもの・自動化
IaaC → 消していい理由が分かる・手順が均一 ・削除要件が定まっているもの → ズルズル維持し続ける状態を避けられる
消さないと、増え続けるもの → Deletableですか? ・コード → ・ブランチ・Pull Request → ・チケット →
・ドキュメント → ・提供しているサービス・機能 → 利用率◯%・利益率◯% ・データ・ログ → ・会議 → 〇〇な状態になったら止める・抜ける
Fin