春から新しい職場で働いているが、Web 系の仕事かつエンタープライズに近いという点は前の職場とも共通している（次を探すときも似た条件になるんだろう）。今の職場のリリースサイクルは速いので良いと思う。
働く中で「リリースしやすさ」についていろいろ思い浮かんだことがあるので、明文化して残しておこうと思う。
歓迎されないリリース
繰り返しになるが、前の職場で提供している分野の延長線上にあるとも言える、エンタープライズに近いターゲットの B2B SaaS の開発をやっている。プロダクトのユーザー層や環境がどういったものであれ、開発者という立場としては、ユーザーの問題を解決できる（価値ある）機能を可能な限り早く提供したい。
前の職場で驚いた（というより一開発者の高慢な心構えと言ったほうが正しかった）のは、機能の提供（≒リリース）が必ずしも歓迎されるわけではなかったことだ。リリースが約束より遅れで怒っているとか、（試行錯誤という文脈でなく）期待値を下回る内容で落胆しているとか、バグが多いからとかという状況下ではない。（もちろんそれもまず先に避けるべき状況だが、前の職場ではよく起きていたらしい…）
デザインの変更を止めて元に戻す決断をしたサービスのことを小耳に挟んだが、この抵抗感はそうしたデザイン起因の敬遠からくるものでもなかった。（ユーザーの IT リテラシを考えて作る必要はあるし、長い設定・操作を乗り越えないと目的を達成できないのもいけないので大変重要ではあるのだが。）
歓迎できない要因
会社で使われるという性質上、リリースを好ましく思わない状況が生まれる。これには 2 つのユーザータイプからの視点がある。
利用ユーザーにとって
まず日常業務でそのプロダクトを使うユーザーにとって、速いサイクルのリリースへの抵抗となるのは、導入者と利用者が違うことと新機能や変化のキャッチアップだ。
おそらく B2C ではツールを利用しようと思った人と使う人は同じ場合が多いため、自分の意志で利用し続ける（または解約）することになる。新機能や変化が好ましく感じれば使い続けるし、嫌な変化であれば一部のユーザーは解約して別手段を利用するだけだろう。
一方の B2B では組織として導入を決定する場合がほとんどで、（ボトムアップ的に提案された、などでなければ）自分の意志で利用しているといえない可能性もある。もしそうした状況のユーザーがリリースの多さに圧倒され新機能・変更についていけないとなると、より嫌々使うことになったり、改善前の昔のバージョンを基準にサービスを利用・評価したり、（最新バージョンに追従できてない）社内ガイドが作られたりする。この状況が放置され続けると、速いサイクルのリリースに効果がないばかりか悪い影響や評価を生み出す可能性すらある。（ユーザー側からキャッチアップしたいと連絡が来るくらいまだそのユーザーは良い）
情報システム管理ユーザーにとって
そしてユーザー社内でそれを管理したりセキュリティを考える情報システム管理ユーザーにとって、速いサイクルのリリースへの抵抗となるのは、社内利用上の制約だ。
セキュリティに気を付けるのは変わらないとしても、（ペアレンタルコントロールは該当しそうだが） B2C ではあまり別ユーザーによる管理やそれに関する問題について考えることはないだろう。レガシー環境のサポートも多少は切りやすいと思っている（Android は大変そうだが）。
一方の B2B では、まずユーザー社内のセキュリティ指針に大きく影響される。（Web 系企業にいてまだわかっていないが）ガチガチに固いポリシーやネットワーク接続制限で縛っていると聞く。Windows 7 や IE11 は当たり前で、Windows 10 であってもサポート内最古バージョンをまだ利用している場合もある（もっと大変な現場もあるだろう）。Web ブラウザを使うサービスでの IE の場合に顕著だが、こうした制約環境下では新しい機能のリリースで不具合が出やすい（開発も面倒）。情報システム管理ユーザーとしては、機能リリースによる問い合わせが（無関係な）自部門に来るのはサービス提供者へのヘイトを溜める要因になるし、上記のような社内向けガイドを書いているとしたら、その内容が古いことを社内の利用ユーザーから咎められる。
ユーザーも DevOps の範疇だ
エンジニアという立場から見ると、これらの障壁を取り除いていく仕事は CRE の責務と近いのかもしれない。「従来のよく知られた DevOps」で CI/CD を整えるのと同じように、開発チームとユーザーとの間の「何か」を整えることが「拡張した意味での DevOps」にとって重要だと思う。もちろん、これを行う専任の人を立てるというより、チーム内の人員が意識して取り組まなければならない。SRE だけがインフラ触るというチームでなく、（理想的には）全員が SRE をやるように、全員が CRE をやると良いのだろう。リリースサイクルを早める上での技術的な制約を乗り除いてきた分、こちらの問題が目立つようになったのかもしれない。
プロダクト面の利点
「従来の DevOps」によりリリースの技術的障壁を減らせたり、ビッグバン型でなく細かいリリースをしやすくなったりしたのと同じように、「拡張 DevOps」が実現できるとユーザーの受入的障壁を減らせたり、ユーザーとの（広い意味の）柔軟な対話が実現できたりするだろう。
やはり速いリリースサイクルが許容されればプロダクトの方向性や機能へのフィードバックサイクルが速くなるし、試行錯誤しつつペインやソリューションを探るのもやりやすい。何より、受け入れに積極的になっていれば、よりフィードバックにも積極性を持ってもらえるのだろう。逆に、数か月単位などでしかリリースが許容されない場合は、実装終了からリリースまでの時間差の分、プロダクトの成長面の足かせが増える。
リリースサイクルを速くできるスタンスとそうでない控えめなスタンスの間に、どういう観点があるか考えてみる[1]。この表での順番と影響の強さは特に関係がない。
| 観点 | サイクルを速くする | サイクルを遅くする |
|---|---|---|
| 基準スケール | 日 | 月～年 |
| 力関係 | 対等・提供者優位 | 利用者優位 |
| リリース合意 | 無し | 必ず前もって |
| リリースタイミング | 実装後に | 期日を決めて |
| リリース粒度 | 細かい・個別 | 大きい・まとめて |
| 運用バージョン | 単一 | 複数 |
| リリースへの反応 | 歓迎・許容 | 無関心・敬遠 |
| 利用態度 | 熱心・日常 | 無関心・嫌々 |
| 環境の管轄 | 自社 | ユーザー |
| 運用環境 | クラウド | オンプレ（機器調達の心配） |
| 利用端末 | モダン | レガシー（IE/古いOS） |
| 利用者側セキュリティ | 柔軟・バランス良し | ガチガチに固い |
| フィードバック | あり | なし・苦情 |
リリースサイクルが速い（つまりプロダクトが成長しやすい）のは、「日単位で機能開発を行っており、ユーザーストーリーは実装が終わればすぐにリリースされ、すべてのユーザーにいきわたり利用してくれる。高いレイヤーでサービスを提供しているため内部構造を変えやすく、サービスの実装を技術的問題に対処しやすく保守性が高い状態に維持できる。また、環境要因の問題が起きにくく、また、リリースへのフィードバックも得やすいので、より価値提供に集中できる。」という状況だろう。SaaS ではこちらでいたいところ。熱心なユーザーが良い噂を生み、プロダクトがより広がるきっかけになれば最高だ。
その逆の環境は、「受け入れ態勢が理由で年単位で機能開発を行っており、事前に半年ごとのリリース物が決定されるので逃すまいと期限を死守する。リリースされたものはユーザーが用意したオンプレ環境で運用されており、それぞれのユーザー環境でバージョンが異なる。その影響で、リリースを行ってもユーザーが実際にバージョンアップ作業をするまでユーザーは使えないし、使えるようになっても新しい機能を使ってくれるとも限らない。ユーザー環境が異様にセキュリティが厳しくレガシー端末ばかりなのも災いし、問題が起きた時の原因調査に多大な工数が割かれ、バージョンの違いや苦情も飛んでくることによりチームは疲弊している。しかし、そうした環境のユーザーに収益を依存しており、現状を変えようにも、そのためのお願いはユーザーとの関係を損ねそうで厳しい。」という状況だろうか。コンプリートしていると SaaS よりも SIer として挙がるイメージに近い（複数バージョンも何もない気もするが）。
おそらく多くの状況はその中間にあると思う。リリース自体は早いがレガシー環境が問題になるだとか、ユーザーの力が強いが信頼の積み重ねや連携で問題発生への対処がやりやすくなっているとか、ありがたいフィードバックもくれるし応援してくれるが予算が足りず半ば放置された性能が不足している客先オンプレ環境で運用している、など。可能な範囲で良くしていくことができるだろう。
キャリア面の利点
リリースサイクルの速さはプロダクトの価値向上につながるとともに、開発にかかわる人のスキル・キャリアにも良い影響がある。
上述したように、「拡張 DevOps」が実現されることでユーザーの受入的障壁が低くユーザーとの対話が実現できていると、（職種に関係なく）ユーザーが抱える問題の解決にフォーカスして日々仕事に臨める。何より、リリースを喜んでくれるユーザーがいてその反応を知れるとやる気もひとしおだろう。
例えば「オンプレ対応のためにクラウド含め複数環境に対応させる」など大変な状況だと、開発バリバリ系の人間にとってはつらく、伸ばしたいスキルも伸びにくいだろう。インフラ的には挑戦的で楽しいかもしれないが[2]。
起業家や VC のポジショントークはあるだろうが、徐々に SaaS ビジネスが主流になっていくらしい。SaaS ビジネスに関わる上ではプロダクトを成長させるためのスキルと経験が必要になるが、それは「拡張 DevOps」か何かにより試行錯誤がやりやすい環境・歓迎される環境で仕事をするとより獲得しやすいはずだ。
どうすればいいのか
「拡張 DevOps」を実現できると何故よいかという主張は載せたが、それを実現させるために何をすべきかはまだこれといった答えがない。もっとも、そうしたプロセスに取り組む前に、新機能が出てもバグが出ないなど、リリースの多さに耐える量の信用貯金を獲得しておくことは前提になるが。
利用ユーザーが持ちうる、嫌々使う可能性とキャッチアップの難しさへの対処法の中では、いつも製品の質を高く保ち、かつ、サポート体制をしっかりしておくのが最初に思いついた方法だった。加えて、カスタマーサクセスがユーザー社内の問題解決の文脈で活用法を提案する（ほかのチームメンバーもそれに協力する）体制ができていると盤石だろうと思う。上に載せた表で「速くする」にある内容が多ければそれがやりやすそうだ。
情報システム管理ユーザーとの間に抱える問題への対処法は、まだ悩んでいて試行錯誤をしている段階だ。情報システム管理ユーザーは問題を起こさせない・最小に抑えるのが役割で、利用ユーザーは（時にツールを駆使して）ビジネス上の成果を上げるが役割のはずで、そこに利害の対立がある。セキュリティインシデントが起きると名の知れた企業ほどダメージを受けるし、所属人数が多いと利用ユーザーを信用しきれないことから、傾向として大企業ほど環境が保守的（制約きつめ）になると思われる。その構図に B2B SaaS 企業が巻き込まれる（そして面倒なことを起こしてしまう）認識を持っているが、この状況に対し、ただ真摯に問題に接するなど以外の根本的な解決策は何があるのだろう？
この問題を避けるだけのためにユーザーを選別するのはビジネス的にかなり厳しそうだし、心情的にもあまりいい気分がしない。B2B SaaS には導入段階があるものなので、その段階で周到な用意でもって障壁をあらかじめ砕いておき、お互い対等で敬意を持った関係であるのが、急がば回れで良いかもしれない。
また、全員が今すぐできることとして、よりユーザーにフォーカスし、利用するという観点だけでなく受け入れるという観点でもユーザーのことを考えて仕事していこうと思う。
まとめ
- B2B SaaS では早いサイクルのリリースがユーザーに歓迎されない状況もある
- 開発チームとユーザーとの間の「何か」も DevOps の範疇だと主張した
- それを踏まえ何かできることがないかを今考えつく範囲で列挙した