CircleCI から見た DevOps 3つの壁

2023/04/26 開催のイベント「DevOpsへの道！3つの壁と解決策ディスカッション」の中の発表「CircleCI から見た DevOps 3つの壁」で使用したスライドです。

https://shiftevolve.connpass.com/event/277553/

Transcript

1. 1 CircleCI から見た DevOps 3つの壁 SHIFT × CircleCI ディスカッション DevOps への道！ 舟木 将彦 (@mfunaki) Principal Developer Advocate, CircleCI
2. 2 会社紹介に代えて(ワークフロー実行回数順位) グローバル 1 米国 2 英国 3 日本 4 ドイツ 5 カナダ 6 オーストラリア 7 フランス 8 スウェーデン 9 ブラジル 10 イスラエル アジア・太平洋地域 1 日本 2 オーストラリア 3 シンガポール 4 香港 5 ニュージーランド 6 インド 7 韓国 8 マレーシア 9 タイ 10 インドネシア 2010/10~2011/09までの12か月にCircleCIクラウド版で実行されたワークフローより。 ただしサンプルやチュートリアルの実行等は除外している(カウントしていない)。
3. 3 なぜソフトウェア開発／運用に携わっているのか 第０の壁 職業選択の壁
4. 4 なんてこんな面倒くさい職業を選んだのか？ • ソフトウェア、使うのは楽しいけど、作るのは面倒くさい？ OR 誰かの貢献が、デジタルに低いコストで再利用可能(みんながうれしい) • 常に学び続けなければならない OR 自分や組織の成長を常に感じ続けられる • 自分の能力や経験が武器になる → 違うプロジェクトやチャレンジであっても、能力や経験が生かせる で、DevOps って面倒くさいですかね？
5. 5 ボトムアップなのか、トップダウンなのか 第一の壁 進め方の壁
6. 6 学びながら DevOps 実践が許されるか？ • 他社は DevOps への取り組みを始めたのが早ければ早いほど ◦ 少ない先行事例から学びながら、失敗も繰り返しながら 自社に合う形を見つけ出した ◦ その間、自社のカルチャーも、自社のメンバーも「納得しながら」 変化してきた ◦ とはいえ、実は「自社に合う形」が「普遍的な形」であることに気づく ◦ トップダウンではなくボトムアップ
7. 7 学びながら DevOps 実践が許されるか？ • 自社は DevOps への取り組みを成功させたいのであれば ◦ 試行錯誤で学びながらよりも、ベストプラクティス(普遍的な形)を どう適用していくかが重要 ◦ 現行プロジェクトで取り組みを始めるのか、新規プロジェクト？ 試作プロジェクト？ ◦ 外部のコンサルタントやアドバイザーに伴走してもらうのか、 メンバーに経験者を加え、自分たちで変わっていくのか ◦ ビジネス課題を解決するためであればトップダウン
8. 8 他社(過去事例)と弊社(これから実現)との違い 第二の壁 タイミングの壁
9. 9 他社はラッキーなタイミングでDevOpsを導入 • ラッキーなタイミングとは？ ◦ 新規プロダクトや新規サービス、あるいは試作プロジェクトを始める タイミング(過去資産の継承を考えなくてもよい) ← とりわけそのプロジェクトが現状のビジネス上の問題解決が起点と なっている場合 ◦ レガシーなシステムをモダンにするプロジェクトを始めるタイミング (今の仕組みややり方では拡張性がない、コスト高止まり) ← やるべき仕事は比較的明確(今あるものを違ったインフラやフレーム ワークで実現)、かつ新たな手法を取り込むことが必要
10. 10 弊社にとってのラッキーなタイミングをどう作るか • そもそも弊社なりあるプロジェクトに DevOps がこれまで導入されなかったのは ◦ 現行プロダクトや現行サービスが現状特段の問題を抱えていないので、 コストをかけてまでやり方を変える必要性がない(むしろ変えたくない) → 他社事例＝ボトムアップでの(DevOps でエンジニアはこんなにうれしい) アプローチは適用できない ◦ 技術的な「現状の問題」がないように見えるのは、 ビジネス的な「今後の課題」が(エンジニアサイドで)見えていないから → 会社は売り上げ／利益をどう増やしていきたいのか？ そのために ・機能を増やしたいのか(足りない機能を実装する) ・サービスメニューを増やしたいのか(プロジェクトを増やす) ・ユーザーを増やしたいのか(ユーザビリティ向上, 行動履歴の取得と提案)
11. 11 目の前のプロジェクトのその先を変えるには 第三の壁 伸びしろの壁
12. 12 伸びしろとは？ • 人や組織にまだ発揮していない能力があり、成長していく可能性がある
13. 13 DevOps の伸びしろとは？ • プロジェクトの自動化が進むこと？ ◦ リードタイム、エラー率、デプロイ頻度、平均復旧時間の向上 • お金に換算すると？ • DevOps なプロジェクトが増えること ◦ プロジェクトが増える、コードが増える、テストが増える ◦ メンバーが増える(それほど増やさなくてもよい) ◦ お客様の期待により応えられているのか？