システムを刷新するならば「開発体制も共に変えるべきだ」
データベースを改善した後、彼らが次に手をつけたのはアプリケーション側のアーキテクチャ変更だった。データベースがどれほどスケールアウトできたとしても、アプリケーションが処理のボトルネックとなっては全体のパフォーマンスが向上しないためだ。では、こちらはどんな基準で新しいツールを選定していったのだろうか。
基準となったのは、まず開発・運用やスケールアウトが容易であること。同社のアプリケーションは複数のサブシステムに分かれており、以前はインスタンスグループの管理や内部接続用のロードバランサの管理などが煩雑となっていた。そのデメリットを解消したかったという。
次に、クラウド環境でなくても動くツールであること。ブロードリーフでは自社内開発だけではなく協力会社への業務委託も行っている。他社に対し、クラウド環境を使用することを強要すべきではないと考えたからだ。これらの条件を満たすものとして、Kubernetesを採用した。
「これで、データベースもアプリケーションもスケールアウトするようになりました。何事も問題なく進んだかといえば、そうではありません。次は人がスケールしないのです」
理想はサービスごとにチームを作っていくこと、つまり各チームがオーナーシップを持ち、スピード感を持ってリリースできる開発スタイルを採用する方式だ。しかし、現実はそうならなかった。自動車アフターマーケットを構成している業者ごとに管理体制が構築されていた。つまり、同一サービスのなかでもチームが細分化されていたということだ。
その結果、コミュニケーションや成果物の管理が非常に煩雑になっていった。しかも、その全ての仲介をしているブロードリーフがボトルネックとなってなかなか開発速度が上がらなかった。
さらに、他にも課題があった。必ずしも最新技術に詳しい協力会社だけではないため、新しく導入したツールについての説明が必要だったのだ。「この体制をより良いものにしていく必要がありました」と松本氏は続ける。
システムアーキテクチャだけを改善しても、開発は円滑に進まない。開発プロセスやチームの体制なども含めて変えていかなければ、生産性の高い組織は実現しないのだ。ブロードリーフのエンジニアたちは、コミュニケーションのあり方を変えていったという。
最初のうちは、JIRAによるチケット管理でコミュニケーションを行っていたが、より気軽にコミュニケーションを取れるようにSlackを導入した。また、社内で使用していたConfluenceページを全ての協力会社と共有した。そうすることで、よりスピーディーなコミュニケーションと情報の蓄積を行っていったそうだ。
「最初はデータの基盤を変えていこうとプロジェクトを推進したのですが、その過程でアプリケーションやインフラのあり方、コミュニケーションのあり方すらも変えていきました。それらを改善しなければ、新しいサービスをうまく開発することはできません。このプロジェクトではデータを中心に物事を考えていきましたが、理想のアーキテクチャを実現するにはデータ以外にも数多くの知識が必要になりました。この経験から、システムや組織が成長し続けていくには、それを支えるエンジニアが変化を受け入れ、新技術を積極的に学んでいくことが重要だと実感しました」
では、その姿勢を持つエンジニアになるためには何が必要なのか。それは、「変化を楽しく受け入れる」ことであると松本氏は結んだ。
「技術の進化スピードは本当に速いです。新しいことを学ぶのは嫌だ、ついていけないから仕事がつらいと思えば、負のスパイラルに陥ってしまいます。だからこそ、新しい技術に対してポジティブな気持ちで向き合えることが何よりも大事なのだと考えています」
お問い合わせ
株式会社ブロードリーフ
