"なんちゃってアジャイル" から "本質的なアジャイル" へ――ベルシステム24 はどのようにして開発体制を変えたのか?

ベルシステム24 が業界のリーディング カンパニーである理由

ベルシステム24 は、業界のリーディング カンパニーとして 30 年以上にわたりコールセンター市場を牽引してきました。同社が市場から高い評価を得ているその理由は、長年かけて培ったノウハウ、そしてここへテクノロジーを融合することにより生み出される高品質なサービスにあります。

株式会社ベルシステム24ホールディングス テクノロジー部の水谷 圭佑 氏は、「コール センター業務において IT の力は欠かせません。ただ、業界やニーズは常に変化します。いかにして顧客やコミュニケーターの要望に IT を即応させていくかが求められるのです。幸いにして当社には、事業部門と開発部門の間に強いリレーションがあります。現場のノウハウと開発部門のテクノロジーを複合させることで、先の要望に早期対応できるのです。」こう述べます。続けて、業務支援システムである WebS を挙げて、具体例を説明します。

WebS はコール履歴を集積したデータ分析基盤です。顧客の問い合わせに応じて案件進捗を出力する、アウト バウンド コールに必要なターゲット リストを抽出する――同システムが備えるこうした仕組みは、今でこそ多くのコール センター事業者が類似のものを備えています。ただ、ベルシステム24 が WebS を完成させたのは 10 年以上も前のことです。そしてその後も、3 か月という短い間隔で、現場のリクエストに応じた改修と機能拡張が続けられています。

「現場や IT 部門が主体となることで、将来必要となる IT サービスを先んじて用意できる。そして常にそれをアップデートしていける。こうした体制を持っていることは、当社の大きな強みでしょう。」こう水谷 氏は語りました。

IT の複雑化により陥った、"なんちゃってアジャイル"

ベルシステム24 の開発体制は、昨今重要性を高めている DevOps そのものだと言えるでしょう。ただ、IT の複雑化を理由に、かつては高い俊敏性を持っていた体制に、陰りが出てきたと言います。

株式会社ベルシステム24ホールディングス テクノロジー部の荒川 史絵 氏は、水谷 氏とともに次のように説明します。

「システムを構成するあらゆる要素が単一モジュール化されている、そんなモノリシックな構造であることが、開発を滞らせる大きなボトル ネックとなっていました。WebS が特に顕著な例です。ある機能のコードを 1 行変えるだけでも全網羅テストを走らせなければならず、デリバリーにあたってはシステム全体を停止させる必要がありました。引き続き 3 か月タームで改修・機能拡張を行っていましたが、開発に割り当てられるのは僅か 1 か月で殆どの期間がテストとリリースに費やされていたのが実情です。保守性や稼働率は下がる一方で、開発体制もいつの間にか "なんちゃってアジャイル" になっていました」(荒川 氏)。

「"3 か月ターム" という決め事が、却って首を絞めていたようにも感じます。これまで、当社は開発を外の企業へ外注していました。当然ながら、外注先は 3 か月という期間で成果物を納品する義務があります。開発に割ける期間は短期化の傾向にありました。義務を全うするためには外注先も保守的にならざるを得ず、1 つのタームで行う開発の範囲が縮小の一途を辿っていたのです」(水谷 氏)。

アジリティを備えた環境へとサービス基盤をマイグレーションすれば、先に挙がった課題の幾つかは解消されるでしょう。WebS では Java ベースの Struts が主に利用されていたため、サポートの終了をはじめとするソフトウェアの老朽化という面でも、マイグレーションが求められていました。

しかし、単にサービス基盤を変えるだけでは根本的な解決は見通せなかったと荒川 氏は言い、詳細を述べます。

「機能単位で開発やリリースが行えるよう、マイクロ サービスやパブリック クラウドの採用を考えていました。この過程で Azure を提供するマイクロソフトから VSM の機会を提供頂いたのですが、そこで衝撃を受けました。VSM では紙とペンで企画からリリースにいたる全作業、全プロセスを書き出していくのですが、外注先とのやり取りに想像以上の工数を割かれていることが分かったのです。マイグレーションを行ったところで、この工数に劇的な変化はありませんでした。マイクロ サービス化によって後工程 (設計からリリースに至る工程) が圧縮されても、受発注を伴う現体制では限界があると感じました」(荒川 氏)。

マイクロソフトの支援で、DevOps 体制への火が点く

ベルシステム24 が VSM を実施したのは 2016 年のことです。同社はこの年、ある決断をします。開発機能を自社グループのポッケに移管することで、IT に関わる全業務を内製化したのです。

長い年月で凝り固まった体制を変えることは、容易ではありません。ですが荒川 氏は、この決断にあたっては不安よりも期待の方が勝っていたと語り、理由を説明します。

「VSM では、マイクロソフトからマイクロ サービスやクラウドの技術動向について解説頂きました。当社で参加したのは少数のエンジニアだけでしたが、私含む全メンバーの魂に火が付いたのを覚えています。我々はエンジニアですから、新しい技術には当然胸が高まります。外注先とのやり取りや定常運用に手一杯で学習へリソースが避けない、学習した技術をサービス基盤で活かせない――こうしたかつての課題がマイグレーションと内製化でクリアになれば、最新技術にチャレンジしていける。そんな期待がありました」(荒川 氏)。

同氏の触れた期待感は、やがてマイグレーションに挑む全てのエンジニアまで広がることとなります。ベルシステム24 では、2017 年から 2018 年、数回にかけてマイクロソフトの提供する Hackfest に参加。この過程で、全メンバーの中に、"DevOps 体制が築ける" という確信が生まれたのです。

• 実際に開催された Hackfest の様子。Hackfest ではマイクロソフトとベルシステム24、ポッケ、3 社のエンジニアが参加し、サービスに求められる機能やアーキテクチャ設計の議論、Azure を利用した試作環境の開発までが進められた

Hackfest から同プロジェクトに参加した、ベルシステム24 のグループ会社である株式会社ポッケ イノベーション推進グループの小堀 祥太郎 氏と、同社 SRE (Site Reliability Engineering) 担当者は、このように当時を振り返ります。

「Hackfest ではマイクロソフト本社の最前線にいるエンジニアが、私たちと一緒になって課題解決のための新たなプロセス、実装技術を設計してくれました。ここでモチベーションが高まらなければエンジニアではない、それ程に密度が濃く充実した時間だったと感じています。マイクロソフトの支援を受けたこと、その中で私たちの脳もフルに回転したことで、ゼロ ベースでスタートしたにも関わらず Hackfest の最終日には本番開発に適用できるプロダクション レディな環境を用意することができました」(SRE 担当者)。

「ポッケでは過去、無理にアジャイル開発を行おうとして失敗した経験があります。短期開発にこだわるがあまりゴールが不明瞭となり、却ってスケジュールが延びてしまった――そんな体験から、実は DevOps やアジャイル開発に対して多少の抵抗があったのです。仮に Hackfest が単なるマイクロソフトのサービス紹介に閉じていた場合、この抵抗感は解消されなかったでしょう。ですが、同社は、DevOps のあるべき姿やどうすれば我々の中に実体として DevOps を定着させられるかを形作ってくれました。そして、そこに対して納得できる形で、技術を当て込んで頂けるのです。過去なぜ失敗したのかを理解したと同時に、同社とならば DevOps 体制を築くことができる、そう確信しました」(小堀 氏)。

Azure の PaaS を活用し、最良のサービス基盤を獲得

先述の通り、ベルシステム24 では Hackfest の段階で、プロダクション レディな環境を Azure に構築しています。Hackfest 後も同環境で開発を行う形で、マイグレーション作業が進められました。

同社が新たなサービス基盤に Azure を選んだ理由がマイクロソフトの手厚いサポートにあることは、言うまでもないでしょう。ただ、Azure の備える機能性についても、同社は高く評価しています。

水谷 氏、荒川 氏、小堀 氏は、アーキテクチャの設計ポイントに触れながらこう説明します。

「定常運用の負荷を可能な限り削減したい、開発側や新たな技術学習にリソースを割ける環境にしたい、そう考えて今回、Docker でコンテナ化した環境のオーケストレーションを可能にする Kubernetes を採用しています。Kubernetes は新しい技術であり、ベスト プラクティスがまだ確立されていません。アップデートも頻繁ですから、自力でこれを運用するのは困難です。ただ、Azure はフル マネージドで Kubernetes 環境を提供する Azure Kubernetes Services を提供しています。新しい技術であっても、積極的にこれを実装することができたのです」(水谷 氏)。

「RDB (関係データベース) をマイグレーションしたことも大きなポイントです。プロジェクトでは、これまで利用してきた Oracle Database を Azure SQL Database へ移行しました。当初はコスト削減が狙いでしたが、Azure SQL Database は旧環境と比べると学習コストが低いため、これまで属人化しまっていたデータベース管理をプロジェクトの多くのメンバーが作業できるようになったのです。いざという時に誰でも手を入れられる、こうした体制に変わることは、保守性や稼働性に良い影響を与えるでしょう」(小堀 氏)。

「新たなサービス基盤では、ほぼ PaaS のみで環境を構築するサーバー レスを採っています。必要な機能をフル マネージドで提供する PaaS では、仮想マシンと比べ、運用効率や柔軟性を飛躍的に高めることができます。Azure は 先の Azure Kubernetes Services や Azure SQL Database だけでなく、権限管理の Azure Active Directory、CI/CD (継続的インテグレート/継続的デリバリー) を支える Azure DevOps など、サービス基盤に必要なあらゆる機能を PaaS として備えています。Azure はクラウド ネイティブな設計を採りやすいため、リリース段階として最良の設計が採れたと考えています」(荒川 氏)。

• 新たなサービス基盤のアーキテクチャ画。西日本リージョンに本番環境を構えており、東日本リージョンに同じ環境を用意することで物理冗長化も図られている

一体感を持った DevOps 体制を築く

ベルシステム24 では、2019 年 3 月にサービス基盤のマイグレーションを完了させ、同月より新たなサービス「Sien」としてこれをリリースしています。

水谷 氏は、マイグレーションの効果について、「2016 年に VSM を行った段階では、開発に割り当てられる期間は全体のおよそ 30% で後の 70% がテストやリリースが占めていました。今ではこれが逆転し、全体の 90% が開発側に割り当てられるようになっています。マイクロ サービス化やクラウド化による明らかな成果です。」と述べ、笑顔を見せます。

続けて荒川 氏は、こうした成果は社内の開発体制が変わったことにも起因していると述べ、SRE 担当者とともにこのように説明します。

「必要ならばすぐに開発してリリースする、些細なバグがあれば即日で対応する、こうした体制がチームに根付きました。Hackfest でメンバーの中にあるエンジニアリング魂に火が点いたことが大きな理由でしょう。また、Sien のサービス基盤ではチームにまだ実績のない Go 言語を利用して認証機能を構築しています。新しいスキル セットであっても積極的に学習できる、そんな時間的余裕が生まれたことも、DevOps 体制が進んだ要因だと思います」(荒川 氏)。

「Azure DevOps の備えるボード機能は、CI/CD を進める上で非常に有用です。周りの作業工程が瞬時にわかりますから、チームに一体感が生まれたり作業プロセス上で足りないリソースを誰かが補ったりといったことが自発的に生まれるのです。DevOps 体制が確立したこともあって、社内では頻繁にミニ Hackfest が開催されています。私自身も一エンジニアとして感じますが、全員でサービスをより良いものにしていく、新しい技術にチャレンジしていくといった環境は、それだけで日々のモチベーションになっています」(SRE 担当者)。

WebS から Sien へのマイグレーションは、ベルシステム24 において、内製化の初期実績となりました。荒川 氏は取材の終わり、「初期実績を成功に収めることができたのは、今後他のシステムを DevOps 化していく上で大きな足掛かりになると思います。Sien を含むあらゆるシステムの適応性を高めることで、お客様のニーズに応え続けられると考えています。」と語ってくれました。

過去の経験とマイクロソフトの支援をもって DevOps 体制を築いたベルシステム24。モデル ケースとも言えるこの取り組みが、今後、同社のみならず様々な企業の DevOps 化を成功に導いていくことが期待されます。

[PR]提供：日本マイクロソフト