今回は業務都合で残念ながら午前の部は参加できなかったのでセッションは午後から。結局今回はずっと B ルームにいたので主なテーマはアジャイルと DevOps でした。
というわけで最初のセッションは こちら です。
「KDDIのAgile&DevOpsへの挑戦と戦果」 川上 誠司 氏〔KDDI〕
- アーサー・C・クラークの三法則
- 「高名だが年配の科学者が可能であると言った場合、その主張はほぼ間違いない。また不可能であると言った場合には、その主張はまず間違っている。」 => 年配の開発者(=上司)とも読み替えられる
- WF 開発の限界を感じていた
- Ray L. Birdwhistell によれば言語コミュニケーションで伝わるのはせいぜい35%程度の情報（３回ホップすればおよそ5%まで減衰してしまう）。
- ５年で 10 億かけたシステムをハードウェア EOSL 起因で移行(Linux のポーティング)するのにまた数億かけている現実など
- これまで納期遅れなどはなかったが、良いシステムを作っても売れるわけではないという事実
- WF では要件定義からリリースまでの時間（リードタイム）がかかりすぎる
- WF は作って終わりだが、アジャイルは継続して価値を高めていく
- 契約の縛りが強すぎて新しいこと・新しい技術を取り入れられないという裏の事情もあった
- Google から新部長が来てプロジェクト (KDDI Business ID) を引き継いだ
- 最終的には16名ほどの開発体制、プロパー社員にはほぼ開発未経験の人員もいるような状況
- スタートの条件
- 権限を持つ人を味方につける。ただし権限持っている人は技術者上がりではない可能性もあるのでちゃんと数字をもとにした根拠・論拠を持って行く。
- 黒歴史（例: WFで失敗したばかりのプロジェクト）を悪者にする
- ハードルは高い
- 社内処理は WF 前提、納品しないとお金が発生しない。なのでトライアルという形で導入するところから始めた。アジャイルに適した社内処理フローはまだ整備されていない。
- 出来なければ出来るように勉強する、出来る人に来てもらう（JJUG などのコミュニティやカンファレンスに来ている意識高めのエンジニア）
- アジャイルに対する偏見ももちろんあった
- スコープの変化ややり始めでうまく回らなかった等の理由で一回納期をずらしてもらったとき、ほらやっぱり駄目だったねと役員に言われた。何となくだらだら開発しているというイメージ（偏見）は覆せなかった。
- 費用・コスト内で価値のある機能をできるだけやるという考え方はなかなか理解されない
- 優先度を決めてやるという一文はすぐ消されてしまう
- 全部やるわけじゃない、というコミットをうまくやる方法はまだ決めてがない
- もっとできるだろうという過度な期待
- 無駄な機能を作っても意味がない、という認識・合意がないともっとやれになる
- グループ2万人を超える企業で関係者を巻き込むことの難しさ
- DevOps の Ops がくせ者
- Dev: 開発・企画
- Ops: 運用・"営業・業務・CS" <= ここまで巻き込まないといけない
- 最初のタイミングで見積もりなんて取りようがない、最低限の機能分 + バッファで。経営層などとの十分な議論が必要。
- DevOps の Ops がくせ者
- やってよかった取り組み
- プロトタイプ構築（３、４ヶ月間）
- 本開発スタート前にアーキテクチャ検証、製品評価を実施した（スパイクに近い）
- 初心者向け Java 研修などを行ってスキル補填・準備
- チームビルディングとして飲み会は絶対やった方が良い、しかも立食で全員と話せるようにする
- KPT だけでは不十分なので気軽に喋れる場を用意する
- ペアプロ
- 特定のペアしか知らない情報が出来てしまうのを防ぐためにスプリントごとにペアを入れ替えた
- 企業間の関係も一緒、１企業だけに委託するとリスクが大きくなる
- 特定のペアしか知らない情報が出来てしまうのを防ぐためにスプリントごとにペアを入れ替えた
- できるだけ速く失敗する、最初に一ヶ月は失敗しまくっていた
- スプリントを１週間に区切って改善を続けるといつの間にかできるようになる
- 傷が小さいうちに検出することが重要
- アナログわかりやすい
- JIRA + 紙のカンバンで回している
- 部長は電子化して web に上げろというが、そもそもアカウント作っても全く見てくれなかった => 紙だと何となく目につくので見てくれる
- TDD
- UI での優先度はもともと低かったこともあるが、最初の社内お披露目会でさんざんな文句を言われた
- そこで１ヶ月でフロントを作り替えたときにサーバー側の動作はテストで保証されていたので UI の開発に集中することができた。
- Chef の serverspec が高威力、仮想サーバ50台のチェックが６分で終わる
- 業者に頼んでも人力のパラメーターチェックは１週間かかっても終わらない
- CI
- Confluence（仕様）→JIRA（ステータス管理）→ stash（ソース管理）→bamboo（ビルド/デプロイ自動化）
- Redmine でチケット管理していたが一連のプロセスがつながってリリースできるというフローを意識できるようになった
- デイリースクラム・KPT
- P は３つか４つ、改善できていったら増やしていく
- 22回 x 7 x 0.8 = 123 回の改善を半年で達成
- 全部のスプリントバックログを紙に残してはれるスペースがある（写真用に貼り出しただけかも）
- 負荷の集中しているコアメンバーを休ませよう！というトライなんかもあった
- 出来ないことは出来る人・優秀な先生に助けてもらう
- サポート体制 / システムアーキテクト / アジャイルコーチ / CI / TDD
- レポート
- 成果物の定期報告
- 動くものができあがっているか？ユーザーの評価はどうなのか？全体のどこまでが終わっているのか？
- マネージメント層の興味は、当初の計画のコストとスケジュールで進んでいるのか？という点のみ
- いけてるアーキテクチャの話とかは上層部的にはどうでもよい
- 成果物の定期報告
- チームの中心、PM にはベテラン（エース）の投入が必要
- プロトタイプ構築（３、４ヶ月間）
- 半年やってみて
- （古い体質の）KDDI にもアジャイルは導入できる（た）
- KDDI はユーザ企業である
故にユーザ企業にアジャイルは導入できる
横展開、オフショア（ベトナム）に応用することを考えている
KDDI さんのような老舗大手企業でのアジャイル導入体験談、特にやってみてよかったことは今後の取り組みでも早速取り込んでいきたいポイントがいろいろありました。例えばペアシャッフルも意識しないと、単にペアプロ始めただけで知識の共有とするのは確かに危険。あとは導入時の問題点、特に社内処理が人月ベースの受託形態だったりするのはみんな頭を抱えていて、いくら現場がアジャイルに動いていてもひずみが生じるというのはその通りでそもそもの仕組みを変えていく必要があるというのは倉貫さんのお話にもつながるものを感じました。
DevOps の Ops がくせ者で営業部隊なども巻き込んでいかないといけないというのは意識するようにしようと。あとプロトタイプ開発や検証を前半に持ってきてしまって、その後にスクラムなりというのはありだと思う一方で、作る機能や機能・性能要件が定まっていない状態でプロトタイプってどうやっていくのが良いのかもう少し突っ込んでお話を聞きたかったです。
