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
Sierのアジャイルとジレンマとパラダイムシフト
Search
terahide
August 23, 2014
Technology
87
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Sierのアジャイルとジレンマとパラダイムシフト
devlove 甲子園 2014 隊トラック 2回表 の資料です
terahide
August 23, 2014
More Decks by terahide
See All by terahide
アニメに学ぶチームの多様性とコンピテンシー
terahide
0
690
テスト駆動開発でダイエットに挑戦して失敗した話
terahide
0
1.3k
コミュニケーション不全はなぜ起きるか
terahide
0
170
オレオレになりがちなテスト計画を見直した話
terahide
0
190
和服を普段着にするようになって気づいたアジャイルの心
terahide
0
49
Management3.0のワークを受けてから会社の偉い人へM3.0のワークショップをするまでにやったこと
terahide
0
170
一番アジャイルな料理人はソーマくんだと思うんだ
terahide
0
97
Att
terahide
0
44
受託開発でテストファーストしたらXXXを早期発見できてハイアジリティになったはなし
terahide
0
47
Other Decks in Technology
See All in Technology
AWS Blocks を触ってみた/first-tach-aws-blocks
fossamagna
2
140
トークン最適化のためのユーザーストーリー分析 / User Story Analysis for Token Optimization
oomatomo
0
170
4人目のSREはAgent
tanimuyk
0
380
そのハーネス、本当に境界になっていますか? AIエージェント時代の実行環境設計【MEGU-Meet #4】
cscengineer
PRO
0
110
Hatena Engineer Seminar 37 jj1uzh
jj1uzh
0
420
#エンジニアBooks 30分でわかる 「技術記事を書く技術」 / engineer-books 2026-06-30
jnchito
1
180
AIで政治は変わるのか? — 中高生と考えたAI時代の民主主義(東海高校サタデープログラム)
eitarosuda
0
380
10x Speed With QA Agent Platform - How we scaled adoption from individual effort to organizational capability
lycorptech_jp
PRO
0
130
5分でわかる Amazon Connect_20260608
hwangbyeonghun
0
180
「ちゃんとやっている」は独りよがりだった ― 不安に寄り添うインシデント対応へ / Towards incident response that addresses anxieties
chmikata
1
360
次世代ランサムウェア対策の考察 / 20260704 Mitsutoshi Matsuo
shift_evolve
PRO
5
1.7k
しぶいSRE: サーバから見えない障害にどう向き合うか。ラストワンマイルのデバッグ実践 / Shibui SRE
kanny
2
1.2k
Featured
See All Featured
What the history of the web can teach us about the future of AI
inesmontani
PRO
1
630
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
2k
Leveraging Curiosity to Care for An Aging Population
cassininazir
1
310
Highjacked: Video Game Concept Design
rkendrick25
PRO
1
400
Principles of Awesome APIs and How to Build Them.
keavy
128
18k
The Spectacular Lies of Maps
axbom
PRO
1
850
The untapped power of vector embeddings
frankvandijk
2
1.8k
Practical Orchestrator
shlominoach
191
11k
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
Product Roadmaps are Hard
iamctodd
55
12k
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
0
550
Neural Spatial Audio Processing for Sound Field Analysis and Control
skoyamalab
0
360
Transcript
てらひで #devolve #devlove隊 2014/08/23 SIerのアジャイルと ジレンマと パラダイムシフト
てらひで @terahide27 認定スクラムマスター アジャイルコーチ アーキテクト
てらひで @terahide27 http://gigazine.net/news/20140601-anime-2014summer/ 深夜アニメの カバレッジ90%以上
はじめに
buzzword このセッションにおける用語の定義 • SI 他社のソフトウェア(システム)を請負って製造す るサービスの総称 • アジャイル開発 旧来のソフトウェア開発プロセスに比べてライト ウェイトな開発プロセスの総称
e.g. scrum, XP, Lean, etc.
契約がー 会社がー 組織がー 上司がー 顧客がー 規模がー
うんうん そうだよね
パラダイムシフト 要求 リソース 日程 日程 リソース 要求 固定 調整 従来
アジャイル開発 アジャイル開発の本質とスケールアップより
こんなことをがんばってました アジャイル開発の啓蒙 – チームへ・上司へ・顧客へ アジャイル開発の下地の教育(チームへ) – Scrum・Lean・カンバン・KPT・自己組織化・チーム ビルディング – ユニットテスト・テスト駆動開発・CI・ペアプログラミ
ング・意図を伝えるコード・柔軟なアーキテクチャ 営業 – 契約前に関われる案件の獲得(これが一番難しかった) – アジャイル開発をしてるぞという実績作り – 世間への露出
ア ニ メ 面 白 い で す
どうして こうなったん だっけ?
アジャイル開発はSIに必要? 会社 – 仕事を平準化してたくさん人をいれればいい – onlyOneな会社として目指す方向は特殊な業務に強く なることだ 上司 – お客さん(商流的に上位のSIer)が求めてないんだから
– お上のやり方に波風は起こさないで 同僚 – 今のままでも仕事できてて給料もらってるんだからな んでそんなことする必要があるの?
アジャイル開発はSIに必要? 自分 – 従来の開発プロセスでは、現代のビジネスのスピードに ついていけない – 時間経過に伴う要求の変化は必ず発生するから「作っ て最後に見てもらう方式」ではムダが多い – システムがもたらす価値の議論を行わないから「現行
踏襲」に代表されるように、必要ない機能の整理がで きない – 世の中でアジャイルが当たり前になったとき、やったこ とのない自分たちはアジャイルできるのか?
ギャップとジレンマ 受託開発と人月 多重下請 サラリーマン なエンジニア エンジニアと しての危機感 VS
ア ニ メ 面 白 い で す
保守・運用のお仕事 写真提供:ペイレスイメージズ
あれ? • 固定の少人数でお仕事 • お客さんが優先順位を決めて随時新し い開発の依頼をする • 一定期間毎の契約 • 開発の規模によってリリース日が決定
• 基本は定期リリース
これ 見たことある! • 固定化された小さな開発チームが • 価値が高いと顧客が判断した順に • 現実的なデリバリ能力の範囲で • タイムボックスを決めて
• 継続的に開発・リリースしている
パラダイムシフト(再掲) 要求 リソース 日程 日程 リソース 要求 固定 調整 従来
アジャイル開発 アジャイル開発の本質とスケールアップより
解決しちゃった • 契約 • 組織 • 規模 • 顧客 •
etc.
DevOps
サラリーマンとしての考え 保守とか運用は単価が安いか ら俺の仕事じゃない 大勢の開発者を使う仕事をし た方が会社から高評価
現実にある問題 • 安い単価 – サービスインしてからの時間の方が開発時より圧 倒的に長い – ランニングコストを抑えたい → 単価の低下
• レガシーコード – 修正・追加が困難なソースコードの山 • 障害と責任 – 障害が起こると大変な事態になる – 積極的な攻めの開発を行いにくくなる
一番気に するのは 「品質」
本当に大切なのは 顧客に「価値」を 継続的に提供する こと エンジニアとしての考え
評価とアピール •高い品質を維持 •継続的にリリース •必要な時にリリース
保守・運用をするのに知ってると いいかもしれない知識・本 • ITIL • 継続的デリバリ • 派生開発(XDDP) • 「レガシーコード改善ガイド」
まとめ • 大切なのは × do Agile (アジャイル開発する) ◦ be Agile
(アジャイルに変えていく) • 喜びを顧客への価値提供に見出 すこと • 発想を変えてみると道が開くかも
be Agile!