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
170
こんな案件は嫌だ(※個人の感想です)
あけの
June 04, 2022
Tweet
Share
More Decks by あけの
See All by あけの
Reactハンズオンラーニングを読んだので感想を語る
akeno
1
510
TypeScriptのエラー処理(ES2022の新機能を添えて)
akeno
1
2k
oapi-codegenを使ってみた
akeno
0
1.8k
SQLアンチパターンから学ぶテーブル設計
akeno
0
380
VSCode Remote Containers のすすめ
akeno
0
230
設計とテストの必要性について考える
akeno
1
250
Other Decks in Programming
See All in Programming
Boost Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
0
170
サーバーレスで負荷試験!Step Functions + Lambdaを使ったk6の分散実行
shuntakahashi
6
1.5k
Architecture Decision Record (ADR)
nearme_tech
PRO
1
650
A New Era of Testing
mannodermaus
2
140
Go1.23で入った errorsパッケージの小さなアプデ
kuro_kurorrr
1
220
Ruby Parser progress report 2024
yui_knk
2
200
LangChainの現在とv0.3にむけて
os1ma
4
800
What is Parser
yui_knk
9
4k
今インフラ技術をイチから学び直すなら
yuhta28
1
120
Amazon Neptuneで始める初めてのグラフDB ー グラフDBを使う意味を考える ー
satoshi256kbyte
2
240
Regular Expressions, REXML, Automata Learning
makenowjust
0
190
マルチモジュールにおけるテスト最適化
fxwx23
0
190
Featured
See All Featured
Statistics for Hackers
jakevdp
793
220k
RailsConf 2023
tenderlove
27
800
Happy Clients
brianwarren
96
6.6k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3.4k
Intergalactic Javascript Robots from Outer Space
tanoku
268
26k
10 Git Anti Patterns You Should be Aware of
lemiorhan
653
58k
How To Stay Up To Date on Web Technology
chriscoyier
786
250k
How GitHub (no longer) Works
holman
310
140k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
24
600
Producing Creativity
orderedlist
PRO
340
39k
Designing the Hi-DPI Web
ddemaree
278
34k
Ruby is Unlike a Banana
tanoku
96
11k
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開発は楽しいし、良いもの。 気をつけていきましょう。