てらひで #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！