はじめに
コロナ禍で急加速したデジタル時代の現在においては、ITがビジネスそのものとなりつつあります。
経済産業省によるDXレポートにおいても、IT技術の活用により「顧客・社会の課題を解決するための仮説となるプロダクトやサービスを繰り返し市場に提示し、データに基づいて顧客・社会の反応を把握しながら、迅速にプロダクトやサービス、あるいはその提供体制にフィードバックし続ける」必要性が強調されています。
強い不確実性のもとで高アジリティが求められるシステム開発現場では、小規模に始めて徐々に育てる「リーン開発」が必然的に多く採用され、その実現手段として内製化やアジャイル開発に取り組んでいる企業も多くなっています。
上記のような背景のもと行われるシステム開発では、直接的な顧客体験に繋がる機能・サービスの実装が重要視される傾向があります。小規模なシステムでは問題となることは少ないですが、ビジネスの拡大によりシステム規模が一定以上に大きくなると話は変わります。
大規模システムでは、システムを支える非機能と呼ばれる性能やセキュリティなどの要素の重要性が急激に増し、品質を担保するための作業は膨大になり、これまでの簡素な開発ルールでは開発現場が容易く無政府状態になってしまいます。
つまり、システム規模に応じて最適なプロセス、ルール、システムアーキテクチャは変えなければならず、これには横断的な視点を持ったアーキテクトによるトップダウン的な構造改革が必要となります。
これを行えないでいると、リーン開発の現場ではどのようなことが起きてしまうでしょうか？
それが、本稿で述べる「悪魔のスパイラル」なのです。
リーン開発現場を襲う「悪魔のスパイラル」
実際に現場がスパイラルに陥ってしまう過程を紹介しましょう。
前述の通り大規模化したシステムでは考慮すべき要素が非常に多く、何らかのインシデントが発生する可能性も高くなります。インシデントがユーザのクレームに繋がる場合もあり、現場は原因究明だけでなくユーザのデータ修復などのフォローが必要となるかもしれません。
一方で、新しいサービスを展開し続けることはビジネス面で重要ですから、開発活動は継続することが求められます。すると新しい開発とインシデント対応の両面を求められた現場はどんどん高負荷となっていき、品質を担保するような重要な作業に手が回らなくなっていきます。それが新たなインシデントを生み出すのです。
お気づきの通り、このスパイラルは一度陥ると抜け出すのが非常に困難であり悪魔的なものだと言えます。
最終的には、度重なるインシデントによるユーザの信頼失墜による競合他社サービスへの乗り換え、また現場の負荷が高まることで離職リスクの増大を招き、ひいてはビジネスそのものに重大な影響を及ぼす可能性があります。
私自身は問題解決のスペシャリストチームに所属しており、数多くの開発現場を目にしてきました。その中で実際に直面した事例を紹介します。
例えばある企業では、システムスローダウンが大きなビジネスインパクトの引き金となりました。恒常的に高負荷状態の続いていた現場では新規サービスのリリースを優先するあまり問題発生を事前に防げませんでした。さらに発生した事態の対応に時間を要したために長時間ユーザが利用しづらい状態となってしまい、その期間の売上額が予定の半分以下となってしまう事態が発生しました。
また別の企業では、ユーザからの大量のクレームと経営層からの機能拡充要求との板挟みが原因となり開発チームの主要メンバが全員退職する事態に発展し、現場が立ち直るのに年単位の時間がかかってしまうということも起きています。
スパイラルから脱出するためのアプローチ
開発現場が、自然にスパイラルから脱出することは容易ではありません。なぜならば、このような現場では抜け出すための改善を行う余力が無いことがほとんどだからです。
「悪魔のスパイラル」から抜け出すためには、横断的・抜本的な改善活動を現場とは別の第三者視点により実施していくことが極めて重要になります。
そして、このような活動では特に次の2つの要素が必要となります。
- システムそのものや開発現場を俯瞰し本質的な課題のありかを特定する
- 問題解決に向けた改善活動の道筋をつけ強力に推進する
大規模化したシステムにおいて、発生する問題の原因が特定のチームやシステムの特定箇所のみに存在するということはほぼあり得ません。
目に見える問題のモグラたたきだけではいつまでたっても状況は良くなりません。「木を見て森を見ず」とならないようにシステムや現場全体を俯瞰し本質的な課題に迫るというアクションが重要です。
たとえ本質的な課題にたどり着けたとしても、改善の実施を現場に全面移譲してしまうと上手くいかない可能性が高まります。
改善活動はチームやシステムを跨った対応が必要となりますが、ただでさえ忙しい現場のメンバだけで推進していくことは難しい場合がほとんどです。
「笛吹けど踊らず」とならないように、現場のトップ層や場合によっては経営層レベルの協力を取り付け、権限と推進力を持って解決にもっていくことが重要となります。
このような活動を行うことで、現場に余裕を生み出すことができます。それこそが「悪魔のスパイラル」から抜け出すことに繋がるのです。
私が経験した事例について紹介します。
スパイラルに陥って高負荷状態となっている複数の開発現場を見渡すと、たいていが似通った問題に悩まされているのが現状です。しかしながら、実際に話を聞いてみるとその真因は多岐にわたります。
ある例では、システムの高負荷が原因で問題が発生していました。そのため高負荷状態でも問題なくユーザがサービスを利用できるような耐久性の高いアーキテクチャに改良することで、問題発生を防止し現場の余力を作り出すことができました。
また別の例では、そもそも人為的なミスにより本来あり得ないアプリケーションや設定が商用環境に反映されてしまうという事態が頻発することが問題の本質でした。
そのためデプロイプロセスを見直し、人為的ミスが発生しづらい仕組みを取り入れ、開発現場全体に浸透させることで事態を好転させることができました。
おわりに
システム開発においては、システム規模の拡大に応じて開発プロセス、ルール、アーキテクチャを変化させていくことが必要です。
これには横断的な視点を持ったアーキテクトによるトップダウン的な構造改革が不可欠ですが、残念ながら多くのリーン開発現場では、直接的な顧客体験に繋がる機能・サービスの実装を優先せざるを得ない傾向が強く、システム・開発規模の拡大とともに様々な問題に悩まされることがあります。
そして開発の現場は「悪魔のスパイラル」から抜け出せなくなってしまい、ユーザへのサービス提供品質の低下を引き起こし、最終的にはビジネスの業績にも影響を及ぼすことさえあります。
この「悪魔のスパイラル」を脱するためには、現場とは別の第三者視点による横断的・抜本的な改善活動により現場の余裕を作り出し、スパイラルを逆転させることこそが有効な一手となるのです。