ビジネスニーズに応える開発速度と運用安定性をどう両立？セゾンテクノロジーが挑む「自動化中心」のサービス開発

【B-4】加速するビジネスニーズに応えるデータ連携サービス開発のために〜近未来のアプリケーション提供戦略と地動説的SRE改革〜

なぜHULFT Squareは高速で機能拡張できたのか？

　このような機能を開発した背景にあったのが、「HULFTが持っている機能を使いたいというお客さまからの要望が増えてきたため」と畑氏は話す。HULFT SquareとHULFTの機能を比較すると、HULFTではできることがHULFT Squareでは制限されていることが多くあったからだ。

　だが、HULFT Square転送機能を拡張するにはいくつかの課題があった。第1は開発の難易度が高く、開発工数も膨大になること。なぜなら、転送機能はHULFT Squareとは異なる開発言語や環境で開発されていた。また30年にわたって拡張し続けた詳細機能もあり、それを一つひとつ、コードを書いて拡張していくのは膨大な時間とコストがかかる。さらにHULFTとHULFT Squareではデザインのコンセプトが異なっていた。「GUIのデザインや用語を一から定義する必要があった」と畑氏は語る。

　第2に十分なテストが必要になること。HULFTは銀行などの金融業界で使われているため、高い品質が求められる。

　求められる機能ごとにコードを追加して、拡張し続けるのは想像以上に時間がかかる。そこで「お客さまがHULFT Squareで何をしたいのか、原点を振り返ってみた」と畑氏は話す。お客さまの希望は、HULFT SquareでHULFTがそのまま使えるようになること。そこで畑氏たちはHULFTをそのままHULFT Squareで提供できるようにすればよいと考えたのである。

　検討を重ねた結果、HULFT Squareのユーザー管理やストレージとは別の場所にユーザーごとの実行環境を作成し、そこでコンテナを起動させてHULFTを動かせればうまくいくのではと考え、開発を進めていった。

　とはいえ、「ただコンテナでHULFTを動かしているだけでは、HULFT SquareでHULFTの機能を提供したとは言えず、意味がないことが分かった。そこで少し工夫をした」と畑氏。それがコンテナイメージでパッケージ化するという方法である。具体的にはコンテナイメージ内にベースイメージを設け、そこにHULFT Squareと連携する機能を改良して実装したのである。「こうすることでHULFTは一切変更を加えることなく、HULFT Squareのユーザー管理やストレージを使えるようになると考えた」（畑氏）

　この仕組みはHULFT以外にも活用できる。「サードパーティの他のプロダクトやHULFT Squareの機能を拡張するプログラムなどにも利用できる」と畑氏は言う。

　このアーキテクチャを導入したことで、HULFTの詳細な機能の開発は不要になり、HULFT Squareとの統合・結合部分のみの開発、実装だけとなった。またHULFTのコードは一切変更していないため、「HULFTの品質をそのまま担保することにもつながった」と畑氏は言う。

　結果、これまではHULFTと連携する一部の機能でさえ1年以上かかっていたのが、「約2カ月でほぼすべての主要な機能が開発できた」と畑氏は語る。

　次に考えたのは、ユーザーにタイムリーに提供する方法について。HULFT Squareにはデータ連携処理をアプリケーションとして提供している場所が既にあることを思い出したのである。「このアプリケーションの仕組みを、HULFT Squareの機能を提供するのに使えるのではと考え、アプリケーションを拡張していった」と畑氏は続ける。

　こうしてアプリケーションによってプログラムを提供できるようになったことで、複数の効果が得られた。第1に、機能ごとにリリースが可能になったこと。第2に、機能の更新タイミングを任意に選択できるようになったこと。第3に、個別のニーズに合わせて最適なソリューションを提供できるようになったことだ。

　今回のHULFT転送機能の開発を通じて、畑氏が得た学びは2つ。一つは既存コードを単に拡張していくという安易な選択肢だけではなく、視点を大きく変えて全体の効率を考えた選択肢も検討すること。もう一つが、開発スピードに応じた、提供スピードの改善も合わせるとより効果的になるということだ。