Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
こんな案件は嫌だ(※個人の感想です)
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
あけの
June 04, 2022
Programming
260
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
こんな案件は嫌だ(※個人の感想です)
あけの
June 04, 2022
More Decks by あけの
See All by あけの
Reactハンズオンラーニングを読んだので感想を語る
akeno
1
740
TypeScriptのエラー処理(ES2022の新機能を添えて)
akeno
3
3.1k
oapi-codegenを使ってみた
akeno
0
3k
SQLアンチパターンから学ぶテーブル設計
akeno
0
800
VSCode Remote Containers のすすめ
akeno
0
380
設計とテストの必要性について考える
akeno
1
330
Other Decks in Programming
See All in Programming
AI駆動開発4年目の現在地(『あなたはFDEになるべきか?』イベント資料)
kumaiu
0
510
[DroidKnights 2026] Workflow AX: From Auto-Documented Policies to E2E Testing
raeminkang
0
540
Seven New Principles of Software Engineering
yegor256
0
470
Goコンパイラを作ってGoをもっと理解する / Build a Go compiler to better understand Go
ikura_hamu
0
130
小さなアプリを作って公開するまで
onozaty
0
150
Coding with AI: How to trust the storyteller (AWS Community Day Adria, Ljubljana 2026)
slobodan
0
140
Getting Started with Vibe Coding
miccheng
0
190
Railsのためのパスキー実践入門 〜マルチテナントSaaSでの意思決定〜
utakaha
4
3.7k
AI時代のFlutter品質設計 — アプリ品質を守るQuality Layers
omatty198
0
360
AI Augmentation Techniques with Liberty
ivargrimstad
1
420
[JA] Domain Modeling with Vanilla Rails: 「操作」から再考するRailsの設計論
yasaichi
4
1.8k
Snowflake Openflow Connector利用の勘所 / 20261024developersio2026tokyo-snowflake-openflow
kasacchiful
PRO
0
320
Featured
See All Featured
Paper Plane
katiecoart
PRO
5
55k
The Cost Of JavaScript in 2023
addyosmani
56
10k
Writing Fast Ruby
sferik
630
63k
Agile Leadership in an Agile Organization
kimpetersen
PRO
0
310
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.6k
The AI Revolution Will Not Be Monopolized: How open-source beats economies of scale, even for LLMs
inesmontani
PRO
3
3.8k
Designing for humans not robots
tammielis
254
26k
Utilizing Notion as your number one productivity tool
mfonobong
4
640
Statistics for Hackers
jakevdp
799
230k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
12
1.4k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Exploring the relationship between traditional SERPs and Gen AI search
raygrieselhuber
PRO
4
4.4k
Transcript
@akeno_0810 2022.06.04 こんな案件は嫌だ Web Creator Meetup in KANSAI #1 (※個人の感想です)
自己紹介 About me akeno (@akeno_0810) Webエンジニア歴2年くらい Rust, API/コード設計, DevOps/開発の効率化 触っている技術
最近興味のある分野
嫌な案件・仕事
嫌な案件・仕事 仕事をしていく上で出会うことはあるはず3 @ エンジニアの立場から見た「こんな案件は嫌だ」を挙げV @ 何が嫌だったかのポイントを語V @ どうすれば良かったか、改善案を出す をやっていく。 ※Webシステムの受託開発メイン・自社開発も一部含みます。
※エンジニア視点です。立場によって見解は異なります。 ※個人の感想です。
仕様が決まっていないが、 実装が始まる
仕様が決まっていないが、実装が始まる 柔軟性をもって開発することは多大なコストが発生する。 ただ、時間やお金は柔軟性ではなく成果物に支払われる… 皺寄せはエンジニアに行く。 ポイント よくあx { 納期は決まっているので今すぐスタートしたいとの要 { 作りたいものはふんわりしていx
{ 予想で作らざるを得ない(ある意味エンジニアの腕の見せ所)
仕様が決まっていないが、実装が始まる ` ちゃんと決める 大抵決まらない or 仮決定とかいう意味のないものになるのでボツt ` 課題感も含めた共有 作りたい理由が存在するはず。(これがない場合多分動けば何作ってもOKでは…?) 共有しておけばあからさまに方向性が逸れることはない。
開発途中に成果物への疑問も湧きやすくなるt ` 時間とお金の制限をなくす 物量で殴る。お金だけだと辛いので時間も必要。 改善案
デザインが Excel・PowerPointや画像
デザインがExcel・PowerPointや画像 仕様書がExcel→代わりがないのでまだ許せる タスク管理がExcel→RedmineとかJiraとかあるだろと思いつつ破綻はしない デザインがExcel→無理、何も伝わってこない 仕様の把握が難しくなり、作業が止まったり手戻りが多発する ポイント よくあ ワイヤフレームがパワポで誰も実装のイメージが湧かな
figmaが図形を並べるツールと化してい 共通部が共通じゃない
デザインがExcel・PowerPointや画像 figmaやXDを使う 一番シンプル。 問題は最低限使えるスキルが様々な関係者に求められること。 使えない人は画像で欲しいとか言ってそれに添削してくるのでq デザインは気にしない toBだとあり。 BootstrapやMaterialUI等の便利なものがあるので、後は実装でよしなにやる。
事前に合意をとっておければスムーズだが、微調整は効かない。 デザインは実質的に仕様書なので時間と労力を割くべき! 改善案
後から仕様が変わる、増える
後から仕様が変わる、増える 既存の機能の再設計と新規機能の追加が発生する。 最初から言ってくれれば…というものだが、最初に金と時間のために削った機能がやっぱり 要るというパターンもある。 「これ追加するだけじゃん・変更するだけじゃん」は開発途中だと「だけ」では済まない。 変更が遅いほど被害も大きい。 ポイント よくあ ¨ 仕様が決まっていないパターンと併発す
¨ ある程度まで開発が進んだが、見せたらやっぱ違ったわとな ¨ 毎日MTGが行われるようになり、炎上案件となってい ¨ 期間と成果物が決まっているアジャイルという謎の存在が生まれる
後から仕様が変わる、増える ちゃんと決める→無理w 短いスパンで成果物を確認する 方向性が合っているかを短いスパンで確認していく。 納期直前に見て「違う」となるよりは未完成前提ですり合わせを行った方が良い。 進捗に合わせて方向転換も出来る。 問題は未完成のものを見せたくない人々をどうするかと、未完成のものを見ても意味がな いと思う人々をどうするかw
出来たものを受け入れる アジャイルでいこう。 改善案
その他、嫌なポイント
その他、嫌なポイント 全てが古い 技術やツールは新しい方がテンション上がる。 ある程度の自由度があると更に良し。 案件で縛りがあるので余り期待はしていない# 何も決まらないMTG 時間の無駄なので#
発注者と開発者が互いのことを知らない 間に数社挟まる場合は今まで説明した問題が降りかかるパターンが多い… 各レイヤーで都合の良いことを言いつつ大事なことは抜け落ちる# 意図が読めない丸投げをされると辛い
まとめ
Thank you! どんな仕事でもコミュニケーションは大切。 エンジニアも(基本的には) より良いものを作りたいと思っている。 お互いの関係性・立場によっa G コミュニケーションが阻害されY G 快適な方法・ツールが異なる
(立場の強い方から)歩み寄れるとスムーズ。 それでもWeb開発は楽しいし、良いもの。 気をつけていきましょう。