Download as PDF, PPTX
More Related Content
![[デブサミ秋2015] 新卒入社エンジニアが ２年間fluentdを運用して学んだ事いろいろ](https://cdn.slidesharecdn.com/ss_thumbnails/devsumiautumn-151015035724-lva1-app6892-thumbnail.jpg?width=640&height=640&fit=bounds)
Sierのアジャイルとジレンマとパラダイムシフト
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9. こんなことをがんばってました アジャイル開発の啓蒙 – チームへ・上司へ・顧客へ アジャイル開発の下地の教育（チームへ） – Scrum・Lean・カンバン・KPT・自己組織化・チーム ビルディング –ユニットテスト・テスト駆動開発・CI・ペアプログラミ ング・意図を伝えるコード・柔軟なアーキテクチャ 営業 – 契約前に関われる案件の獲得（これが一番難しかった） – アジャイル開発をしてるぞという実績作り – 世間への露出
- 10.
- 11.
- 12. アジャイル開発はSIに必要？ 会社 – 仕事を平準化してたくさん人をいれればいい – onlyOneな会社として目指す方向は特殊な業務に強く なることだ 上司 –お客さん（商流的に上位のSIer）が求めてないんだから – お上のやり方に波風は起こさないで 同僚 – 今のままでも仕事できてて給料もらってるんだからな んでそんなことする必要があるの？
- 13. アジャイル開発はSIに必要？ 自分 – 従来の開発プロセスでは、現代のビジネスのスピードに ついていけない – 時間経過に伴う要求の変化は必ず発生するから「作っ て最後に見てもらう方式」ではムダが多い –システムがもたらす価値の議論を行わないから「現行 踏襲」に代表されるように、必要ない機能の整理がで きない – 世の中でアジャイルが当たり前になったとき、やったこ とのない自分たちはアジャイルできるのか？
- 14.
- 15.
- 16.
- 17. あれ？ • 固定の少人数でお仕事 • お客さんが優先順位を決めて随時新し い開発の依頼をする •一定期間毎の契約 • 開発の規模によってリリース日が決定 • 基本は定期リリース
- 18. これ 見たことある！ • 固定化された小さな開発チームが •価値が高いと顧客が判断した順に • 現実的なデリバリ能力の範囲で • タイムボックスを決めて • 継続的に開発・リリースしている
- 19.
- 20. 解決しちゃった • 契約 • 組織 •規模 • 顧客 • etc.
- 21.
- 22.
- 23. 現実にある問題 • 安い単価 – サービスインしてからの時間の方が開発時より圧 倒的に長い –ランニングコストを抑えたい → 単価の低下 • レガシーコード – 修正・追加が困難なソースコードの山 • 障害と責任 – 障害が起こると大変な事態になる – 積極的な攻めの開発を行いにくくなる
- 24.
- 25.
- 26.
- 27. 保守・運用をするのに知ってると いいかもしれない知識・本 • ITIL • 継続的デリバリ •派生開発（XDDP） • 「レガシーコード改善ガイド」
- 28. まとめ • 大切なのは × doAgile （アジャイル開発する） ○ be Agile （アジャイルに変えていく） • 喜びを顧客への価値提供に見出 すこと • 発想を変えてみると道が開くかも
- 29.