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
BEYOND THE RELEASE(K-Ruby Edition)
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
ikuma-t
May 19, 2022
Programming
400
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
BEYOND THE RELEASE(K-Ruby Edition)
K-Ruby#30の登壇資料です。
https://k-ruby.connpass.com/event/242766/
ikuma-t
May 19, 2022
More Decks by ikuma-t
See All by ikuma-t
Querying Design System デザインシステムの意思決定を支える構造検索
ikumatadokoro
1
1.5k
Make Impossible States Impossibleを 意識してReactのPropsを設計しよう
ikumatadokoro
0
1.2k
いまさらのStorybook
ikumatadokoro
0
1k
これで最後にしたい! Astroと立ち向かう 6度目の個人ブログ再開発
ikumatadokoro
6
2.6k
Panda CSS と Ark UI ではじめる個人開発
ikumatadokoro
4
3k
見た目から始める生産性向上
ikumatadokoro
12
6.2k
ぼくが 美容師さんに伝えたかった バンドの話
ikumatadokoro
0
350
Railsアプリをコスパよく読むための環境整備
ikumatadokoro
2
1.4k
HTTPを手で書いて学ぶ ファイルアップロードの仕組み
ikumatadokoro
82
34k
Other Decks in Programming
See All in Programming
『寄り添うラジオ』をAIで作る 体験価値から逆算した、会話しないUXと品質設計
theoriatec2024
2
110
[KotlinConf Extended South Korea 2026] KotlinConf 2026 발표자 후기
wisemuji
0
100
ソフトウェアエンジニアにとっての生成AI - 特性を知って使い倒す / generative ai for software enginner
kishida
7
2.3k
高専、大学編入、そして未踏へ〜プロダクト開発とキャリアの歩み - Technical College, University Transfer, and On to “Mitou” / My Journey in Product Development and Career
pkmiya
0
140
Deep dive into the select statement (GopherCon UK)
jespino
0
170
20260828_品質と開発生産性を両立させる、AI時代のE2Eテストの考え方
magicpod
0
150
Can LLMs Replicate 4 Years of Compose Migration? Exploring the boundaries of automation with 279 XML files from a real product
makun
0
130
AIに既存システムを理解させる技術 ~レガシーを見捨てないハーネスエンジニアリング入門~
ochtum
0
210
Vibes Containers 〜AIで変わるコンテナ設計と運用〜
tkikuc
1
480
Hono + Inertia + React で LP を構築した話
oukayuka
2
210
30年振りにコンパイラの定数整数除算を改善した
herumi
9
4.4k
Hello, Hiroshima Geospatial Data! — Exploring DoboX with Python
ra0kley
0
170
Featured
See All Featured
Amusing Abliteration
ianozsvald
1
290
The Hidden Cost of Media on the Web [PixelPalooza 2025]
tammyeverts
2
490
State of Search Keynote: SEO is Dead Long Live SEO
ryanjones
0
260
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
690
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.5k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
230
23k
Navigating Weather and Climate Data
rabernat
0
510
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
49
10k
Tips & Tricks on How to Get Your First Job In Tech
honzajavorek
1
720
Become a Pro
speakerdeck
PRO
31
6.2k
WENDY [Excerpt]
tessaabrams
12
39k
Being A Developer After 40
akosma
91
590k
Transcript
BEYOND THE RELEASE ikuma-t
ikuma-t ・FJORD BOOT CAMP卒業しました ・趣味:ドット絵、作曲家巡り、ツール探し ・最近は3Dのドット絵を書くのにハマっています ・住んでいるところ:千葉県 K-Ruby 2回目です SUZURIで
販売中 @ikuma-t ikuma-t セットプチフォッカ ikuma-t IkumaTadokoro 自己紹介
「無職になったらいくらかかる?」をいますぐ計算
そこそこバズりました
はじめてWebサービスを リリースして感じたこと 今回話すこと
リリースして感じたこと サービスが提供する価値をあらかじめ定義しておくべき Webサービスをリリースするということは不特定多数の人がアクセスできる状態になること 自分の全力で挑んだ結果、何が評価されたか?技術だけが評価されたか? さまざまな専門要素の総合で評価されることを知り、他者・自分への見方が変わる 作っているのは「アート」ではなく、「サービス」。利用されて、価値を生み出して初めて意味をなす。 Webサービスにはバグがつきもので、だからこそ正常系だけではなく、異常系のUI・UXもちゃんと考える必要がある どういった価値を大事にしているのかを定義しておかないと、批判的な声に対して感情でしか向き合えなくて、サービスに活かせない Webサービスは総合芸術 サービスはリリースしてからがサービス
サービスの価値を定義する サービスの価値はあらゆる面での判断基準 はっきりしていないと、感情が判断基準となり辛い サービス固有の価値と一般的な価値 とはいえ人間なので、自分の心理ケアも大事ではある(紫式部とカービィに助けられた) (負に覆われて見えていない) 「自分達が実現したい価値の一部は届けられた」 「そんな言うならもういいよぉ」的な自暴自棄に 「確かにこっちの方がよりサービスをよくできる」 出典:トム・デマルコ「Slack
ゆとりの法則」 不特定多数からの評価 自分にもサービスにとってもマイナスになってしまい辛い (少なくとも)サービスにとってはプラスな受け止め方 本当の品質を決めるには、欠陥がまったくないかどうかより、 ユーザーのために何をするか、ユーザーをどのように変えるか という問題の方がはるかに重要である。 感情が基準 価値が基準
今回のサービスはめちゃくちゃすごい技術を 使っているかと言われると、正直全然... ではなぜそこそこバズったのか?
Webサービスは総合芸術 Webサービスは色々な専門職との協力で成立している ドメインエキスパート マーケティング プロダクトオーナー エンジニア デザイナー ...and more ・エレベーターピッチの策定
・想定外の制度への仕様策定 ・実装機能の絞り込み ...etc ・各料金の計算方法の調査 ・地方税法のチェック ・制度の歴史チェック ...etc ・告知動画の作成 ・リリースノートの作成 ・サービス名が読めるか ...etc ・バックエンドの実装 ・フロントエンドの実装 ・デプロイ、環境改善 ...etc ・ロゴ・OGPなどの作成 ・全体コンセプト作成 ・レイアウト修正 ...etc quitcost
例:API(バックエンド側)で何かしらエラーが発生した場合の表示 それっぽいではダメ! ・フォーマットがないので、エラーを調査できるだけの情報量が保証できない ・Twitterの文字数では十分な情報をもらえるかわからない ・そもそもみんなTwitterやっているのか? サービスはリリースしてからがサービス
例:API(バックエンド側)で何かしらエラーが発生した場合の表示 それっぽいではダメ! ・フォーマットがないので、エラーを調査できるだけの情報量が保証できない ・Twitterの文字数では十分な情報をもらえるかわからない ・そもそもみんなTwitterやっているのか? 「Twitterから連絡」はそれっぽいけど... サービスはリリースしてからがサービス Webサービスは「アート」ではない。 「リリースの瞬間にそれっぽいポーズが
取れていれば良い」というものではない。
おわりに
リリースの向こう側 リリースする前後ではサービスに対する視点が大きく広がった 未経験者の1ポートフォリオが色々言われたことは、辛かったけどとても幸運だった Before After Webサービス Webサービス START START リリースしてからがサービス
Webサービスは総合芸術 サービスが提供する価値 開発者軸 組織軸 ユーザー軸 RELEASE
Practice、Practice、Practice Again BEYOND THE RELEASE
ありがとうございました