自社ソフトウェアプロダクトのひとつが軽微な障害を起こした。
問題のコンポーネントを担当する開発チームによる一次対応がようやく落ち着き、一息ついたところで、チームリーダーから、障害に関する詳細な報告をZoom越しに受けていた。直前までリモート会議続きだった私は、この時点ではまだ、障害の内容を把握できてなかった。こういう時、流れ切ったSlackチャンネルを後から見て、情報を正確に追いかけるのはなかなか難しい。
バックエンドAPIが、本来であれば処理可能なリクエストに対し、特定の条件下で誤って 400 Bad Request を返していたという。リーダーは、一通りの報告が終わったところで、「何か不明点などありませんか」と私に尋ねた。
この問題の影響を受けたリクエストの件数や期間、APIの振る舞いや内部処理の問題点についてはよくわかった。しかし、その外側がわからない。ステータスコード 400 を返されたことによって、APIクライアントであるスマートフォンアプリは、どのような振る舞いをしたのだろうか。その結果、アプリを利用するユーザーには、どのような影響があったのだろうか。
「アプリ側の実装によるので、アプリチームに聞かなければわかりません」と、これが、リーダーの答えだった。
アーキテクチャの観点で言えば、その通りだろう。バックエンドAPIの仕様、それが、アプリとバックエンドの間での合意事項だ。アプリがどのようにAPIを呼び出しているのか、バックエンドがAPIをどう実装しているのか、互いにそれらに依存すべきではない。こうすることで、アプリ、バックエンドそれぞれのデプロイ容易性を上げ、デリバリパフォーマンスを高く維持しているのだ。
しかしそれは、バックエンドチームがアプリやユーザーについて知らなくて良い、ということではない。社外に公開する汎用的なAPIを提供しているわけではなく、サービスクライアントとしては専用のiOSアプリとAndroidアプリがあるだけだ。アプリのこと、その先のユーザーのことを知らなくて、良いサービスを提供できるとは思えない。そもそも、障害によってユーザーにどのような影響を与えてしまったのか、気にならないのだろうか。
――今の開発チームの目には、ソフトウェアシステムしか映っていないのかもしれない。
そのような思考を巡らす中で、私は、以前の職場でのエピソードを思い出した。
数年前、いや10年近く前だったかもしれないが――ある日の午後、企業向けSaaSプロダクト開発の責任者だった私のデスクに、紺のスーツ姿の男性が近づいてきた。当時はまだ、オフィスに集まって働くスタイルが一般的だった。私のデスクの周辺は、カジュアルな服装のエンジニアばかりが集まるエリアだ。近づいてくるのが営業部員であることはひと目でわかる。
「お疲れさまです。少し、お時間よろしいですか」と、落ち着いた口調でそう言うと、私を促すようにして、すぐ近くのミーティングルームに向かって歩き出した。
4人程度が座れる小さなミーティングルーム。テーブルを挟んで二人で向かい合って座り、彼が口を開くのをまっていた。彼と話す機会はこれまでほとんどなかったが、営業成績がナンバーワンの若手エースだったので、顔はよく知っている。
話は察しがつく。ちょうど今、開発チームが、プロダクトの障害対応にあたっている。多くのクライアントを持つプロダクトだ。彼が担当する顧客にも、おそらく影響があったに違いない。プロダクト開発の責任者である私に対し、障害対応の状況を聞きに来たのか、あるいはクレームを伝えに来たのだろう。後者だとしたら、珍しいことではあるが。
「今日開かれたA社のキャンペーンイベントは、この障害で台無しになりました」と、感情の読み取りづらい視線を私に向けた。抑制されたトーンで話してはいるが、言葉の選び方からは、怒りが滲み出ている。
障害が発生すると、営業部員は、担当する顧客からの直接の問い合わせや苦情の電話に応えたり、場合によっては、客先へ謝罪に向かうなど対応に終われる。当然ながら、本来の営業活動にあてる時間は奪われてしまう。しかし、そんな矢面に立つ中でも彼らは、私たちに文句を言うわけでもなく、むしろ「これも自分たちの仕事です。開発のみなさんは、良いプロダクトを作ることに集中してください」と言う。
しかし、ここのところ立て続けに障害を起こしてしまっている。
執務室では、声を掛け合いながら慌ただしく対応に追われるエンジニアの姿が、ここからでも壁面のガラス越しによく見える。障害を起こしたのは、企業のキャンペーンイベントでよく利用される機能だった。これまで10年以上、改修を繰り返してきた機能で、ローンチ当初から複雑だったコードは今やカオスとなり、保守が困難な状況にまで至っていた。変更を加えると多くの不具合を混入しやすい箇所であり、数日前にも軽微な問題を起こしたところだ。確かその際にも、彼が担当する別のクライアントが被害を受けていたはずだ。
「先方の担当者のBさんは、このイベントの準備に本気で取り組んでおられました」と、こちらを向いて、ゆっくり話しはじめた。「お客様の思い出になるイベントにしたい、そう、おっしゃっていて、だから、僕も、我々のプロダクトを活用したイベントが成功するよう、Bさんに全力で協力して……」
沈黙。
「くやしいです、イベントを楽しみにされていたA社のお客さまにも申し訳なくて……でも開発の人はいつも、そういったことを気にかけている様子も見えなくて、本当に、このプロダクトをお客様にすすめても良いのか、わからなく……」
そこまで話して、うつむいて泣きだした。その理由が、売り上げや成績の心配ではなく、顧客のこと、その先のエンドユーザーのことを想ってのことだと伝わってくる。彼が、ナンバーワンである理由がわかった気がした。
ソフトウェアプロダクト開発を担うエンジニアが、顧客と向き合う機会は多くない。企業向けプロダクトならまだしも、コンシューマー向けならなおさらだろう。まして、企画段階にも参画しないなら、顧客体験について思いを巡らす機会はほとんどない。エンジニアにとっての顧客とは、アプリケーションが吐き出すログや、モニタリングダッシュボード上のグラフや数字でしかないのかもしれない。これでは、エンジニアの目に、ソフトウェアシステムしか映らなくなってしまうのも当然だろう。
当時の私は、その出来事から以降、プロダクト企画部門も巻き込んで、開発プロセスもシステムも組織も大きく変えていった。顧客体験を中心に据える開発組織を作ろう、と。そして、開発チームからの障害報告にはまず、「お客さまへの影響は？」と問うことにしている。
あれから何年も経ち、いま振り返ってみて、目指す組織を作り上げられたのかと自分に問うと、自信を持って答えることはできないように思う。今はそこから離れ、こうしてまた開発チームのリーダーから障害報告を受けている。Zoom越しに映し出されたGrafanaのカラフルなグラフを眺めながら、またあそこからはじめてみようと思った。
