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
あけの
June 04, 2022
Programming
1
180
こんな案件は嫌だ(※個人の感想です)
あけの
June 04, 2022
Tweet
Share
More Decks by あけの
See All by あけの
Reactハンズオンラーニングを読んだので感想を語る
akeno
1
560
TypeScriptのエラー処理(ES2022の新機能を添えて)
akeno
3
2.4k
oapi-codegenを使ってみた
akeno
0
2.2k
SQLアンチパターンから学ぶテーブル設計
akeno
0
450
VSCode Remote Containers のすすめ
akeno
0
240
設計とテストの必要性について考える
akeno
1
260
Other Decks in Programming
See All in Programming
混沌とした例外処理とエラー監視に秩序をもたらす
morihirok
13
2.3k
DMMオンラインサロンアプリのSwift化
hayatan
0
190
rails newと同時に型を書く
aki19035vc
5
710
LLM Supervised Fine-tuningの理論と実践
datanalyticslabo
8
1.9k
ゼロからの、レトロゲームエンジンの作り方
tokujiros
3
1k
Androidアプリの One Experience リリース
nein37
0
1.2k
Fibonacci Function Gallery - Part 2
philipschwarz
PRO
0
210
watsonx.ai Dojo #6 継続的なAIアプリ開発と展開
oniak3ibm
PRO
0
170
Alba: Why, How and What's So Interesting
okuramasafumi
0
210
Lookerは可視化だけじゃない。UIコンポーネントもあるんだ!
ymd65536
1
130
ドメインイベント増えすぎ問題
h0r15h0
2
560
Androidアプリのモジュール分割における:x:commonを考える
okuzawats
1
280
Featured
See All Featured
Designing Experiences People Love
moore
139
23k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2k
How to Think Like a Performance Engineer
csswizardry
22
1.3k
Building Applications with DynamoDB
mza
93
6.2k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.8k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
3
360
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
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開発は楽しいし、良いもの。 気をつけていきましょう。