事業会社でアジャイルとDevOpsを始めて学んだこと

事業会社で内製化という号令のもとアジャイルチームを立ち上げる経験をしました。当時、経験者がいない中、未知な領域に、スクラムマスターとして手探りでベンダー、オフショアメンバと関係を築き成長することができました。備忘として、itSMF Japan EXPOで「毎月20件超のリリース！ グローバルIT運用を支えるDevOpsの推進」として発表した内容を基にサマリして公開します。特に事業会社の担当メンバが、DevOpsやアジャイルを始めるときに何を気を付けないといけないのかの参考になれば幸いです。 #DevOps #アジャイル #Agile

DevOpsってなんだろう？

DevOpsの定義を調べても、いろいろあってよくわかりませんでした。その当時は、DevOpsもアジャイルも、導入すればよい結果が待っている”銀の弾丸＊”のようなものなのだろうかと思っていました。
＊銀の弾丸とは『どんな場合でも通用する』ような『万能な解決策』の比喩で、フレデリック・ブルックスは著書”人月の神話”(1975年)で、”銀の弾丸など存在しない”と言っています。

私たちはIT運用管理のアウトソースのサービス（SaaS)をエンタープライズ向けに提供していて、私はその基盤システムの企画を担当していました。当初、基盤システムへの機能開発は都度ベンダに個別開発を委託していました。それでは、時間がかかりすぎビジネスのスピードについていけず、しょっちゅうセールスやマーケティング側から文句を言われていました。

そこで、ベンダーと共同開発できる体制を作つくることになりました。ある日、上司から「ベンダーとアジャイル開発することになったから、君、スクラムマスターやってみない？」と言われたわけです。アジャイル、聞いたことあるけど、スクラムマスターって何？？でした。所属している部署名が、”開発運用部門”になったというのにDevOpsってなんだろう？？

最初のチャレンジ

と、内製アジャイル開発とDevOpsをはじめることになったのですが、正直、何から手をつければよいものかわかりませんでした。入門書を読みながら、チーム内でPoCのミニプロジェクトをやってみたりしつつ、プロセスや環境の整備をすすめました。

・社内はビジネス側の人ばかりで、ソフトウェア人材がいない
・アジャイル開発のノウハウがない
・開発する環境、ツールがない

開発チームの立ち上げと失敗、そして改善

教科書通りのアジャイルとリリースプロセスを構築し、アジャイル（スクラム）+DevOps導入がスタートしました。今まで、何か月もかけて開発していたものがいきなり1週間や2週間でできるわけがないと考え、4週間スプリントではじめました。スプリント計画ミーティングから、品質保証（QA）も含めて行い、スプリントレビューミーティングで、どの機能までがすべてのテストも含めて完了しているかレビュー。パスした機能をリリースパッケージにして、ステージング環境、そして商用環境にリリースするものです。

当初のアジャイル開発プロセス

当初のDevOpsのイメージを描いてみました。DevとOpsという両輪がかみ合ってハッピーになるんだ。

当初のDevOpsイメージ

ですが、どうやって開発と運用をつなげばいいのか腹落ちしたイメージを持てていなかたのです。今考えると、勉強した知識だけで作ったプロセスですが、アジャイルという銀の弾丸で開発サイクルを回せばおのずとDevとOpsの働きかけが始まってなにか魔法がかかるのではないかと楽観的に思っていました。で、どうなったかというと、、、

チーム開始直後のパフォーマンス

一回目のスプリントは、開始までに間に合っていなかったプロセスやツールの整備で終わってしまい、ほとんど開発ができませんでした。これは、スプリントゼロと呼ばれるもの、想定の範囲内。開発チームの中で振り返り(レトロスペクティブ)をして、2回目のスプリントではようやく着手した開発が完了しました。＼(^o^)／
ところが、開発チームは完了したつもりでも、品質保証（QA）が終わっていなかったり、リリースパッケージに入ってもステージング環境で次々と致命的な不具合が発覚してしまったのです。

3回目のスプリントが終わったところで、大きくプロセスを見直しました。開発の完成の定義、QAの完成の定義をそれぞれ設定し、オフショアのQAチームというプロジェクトの事情に合わせて開発スプリントとQAスプリントをまわすように変えました。また、リリース管理、変更管理にITILベースのガバナンスをいれました。

QA（品質管理）にフォーカスしたアジャイルプロセス

品質の観点は意識しないとうまくいかないことがわかりました。DevからOpsの流れにどのように品質保証（QA）を埋め込むかがスムーズなフローを流すために重要になります。それは、CI/CDのツールありきのプロセス設計ではなく、効率的に素早く開発しながらも、品質は確実に担保するしくみを考えることから始まります。ちなみに、ここでいう品質には、性能、セキュリティを含んでいます。この時の、DevOpsのイメージはDevからOpsの間にQAという要素を強調しています。

このとき、当然ながら開発スプリントのなかでの品質改善プロセスもまわしていますが、QAテスト（UAT）のプロセスを試行錯誤して上記のプロセスに落ち着きました。

DevOpsでのQAの作りこみ（DevQAOps）

質の高いプロダクトバックログがないとゴミの山が開発される

開発物がスムーズに商用環境にリリースされるようになり、アジャイル開発、DevからOpsへのフローが回り始まったわけです。そうすると、今、私たちが開発しているもは、それがベストなものだったのか？と考える余裕が出てきました。この機能が無いと使えないとユーザに言われて作ったのに、使われていない疑惑がでてきたりしたわけです。

一般的に、開発された64%の機能はほとんど、もしくはまったく使われないという調査結果があります。（“ROI, it’s your job” Jim Johnson 2002）つまり、ユーザからの機能要求のうち本当に価値があるものは限られているのです。プロダクトオーナーがそれらの機能要求をどう優先度付けしてサービスのTo-Be像を描いていくかが大事であることに気づかされました。その時にユーザと対話するために大事なのは、「共感」だけでなくOps側で測定した数字であることもわかりました。開発した機能がそれだけ使われ、ビジネスに反映されているかを測定し、生々しい数字として見ることです。ROIをしっかり追うことが重要なのです。そこで重要なのがプロダクトオーナーが質の高いプロダクトバックログとリリースラインを引くことであることを痛感しました。

最終的にたどり着いたDevOpsのイメージとして、OpsからDevへのフィードバックはBusiness視点であるということです。DevからOpsのQAの視点とあわせてDevとOpsを双方向につなぐときに重要視するべきポイントを強調したイメージになります。BizDevQAOpsとまでは言いませんが、これらを中心にチーム、プロセス設計することがポイントだと思っています。

最終的なDevOpsのイメージ（BiZDevQAOps）

成功するDevOpsのポイントとは

ポイント１　素早いサイクルで継続的改善
アジャイルにより、毎月結果が出ます。”ふりかえり”により検証、反省、改善をし、次の月にはアクションをとってさらなる成長をしなければなりません。フィードバックをもとに改善をするサイクルを高速にまわす仕組みを取り入れましょう。

ポイント２　DevOpsにおける品質保証（QA）
アジャイルでは、継続的にインテグレーション、デプロイ、リリースし続けることになります。ソフトウェアが成長するに従い、レグレッションも重要です。そうすると、デプロイ後のテスト自動化が必須です。我々は4時間毎にテスト環境のデプロイ、テストを実行し続けるようにしていました。各環境でツールを使いデプロイ、テストを短期間に実行し続ける仕組みが必要です。

ポイント３　既存の文化にどうやって受け入れさせたか
特にトラディショナルな文化を持った組織では、アジャイルやDevOpsは品質が悪くチャラいものといったネガティブなイメージを持った人たちも多くいます。まずは、確実な品質の作りこみによってアジャイルやDevOpsの誤解を解き、新しい取り組みを受け入れられる土壌を作ることが第一歩になると思います。

結局、DevOpsって？？

マーケットやユーザが求めるものが、必要な時にタイムリーに、使える状態が出来ていることだと考えています。そのために、
・プロセス、ツールを整備して自動化、高速化
・企画、開発、運用やユーザーを巻き込んで、一緒に試行錯誤する
という文化をDevOpsで実現することだと思います。

最後に、あまり触れていませんが、保守的なチームやメンバをボトムアップで変えるには半端ないやる気と精神力があっても難しいことです。トップダウンであれば、それ以上にマインドセットを変えることは困難でしょう。挫折し、人知れず葬られているチャレンジも多いのではと思っています。失敗からの学び、それから、もし秘儀をお持ちの方がいらっしゃったら教えてほしいです。

知見を持ったアジャイルコーチやコンサルティングにサポートしてもらうことも近道の一つかもしれません。