見出し画像

アジャイル開発組織への変革 – Vol.2 モダナイゼーション編 -

はじめに

前回の「アジャイル開発組織への変革 – Vol1. コマンドセンター編 -」に続きまして、第二弾の今回は「モダナイゼーション」を主題に、アマゾン ウェブ サービス ジャパン合同会社様(以下、AWSJ)とパイオニア株式会社(以下、パイオニア)で対談しました。

パイオニアが、Amazon Web Services(以下、AWS)を活用し、アジャイル開発に挑戦した話をご紹介いたします!

以前の記事にも記載がありますが、パイオニアはSaaSカンパニーとして変革し、“モノ × コト”へ加速をするため、昨年8月にSaaS Technology Center(以下、STC) を立ち上げました。STCのミッションの 1つが「アジャイル開発組織への変革」です。 

これからパイオニアを支える開発チームになるために、新しく標準アーキテクチャ、開発手法を確立し、組織変革、カルチャーチェンジをより進めていく必要があります。

今回AWSが提供する、体験型ワークショップ (Experience-Based Acceleration (以下、EBA) に参加し、AWSの伴走を受けながらパイロットプロジェクトを進めて、移行手法、組織変革、カルチャーチェンジを体験しました。(※対談用衝立あり、写真撮影時のみマスクを外しています)


対談者紹介

平井(パイオニア):
今日は宜しくお願いします。私の方から自己紹介させて頂きますね。

SIerを数社を経験の後、小売系事業の子会社にて、AWSのクラウドサービスに触れ始めました。その後、タクシー配車のプラットフォーム会社で、バックエンドの開発やAWSのクラウドサービスの経験を経て、2021年10月にパイオニアに入社し、SRE導入をリードしています。

パイオニア株式会社 平井俊之

倉元(AWSJ):
ありがとうございます。では、私も自己紹介させて頂きますね。

国内SIerにて様々な分野のプロジェクトに参画し、アーキテクチャ策定やフレームワークの整備に携わってきました。

その後、AWSJに入社し、マイグレーションスペシャリストSAとしてお客様のマイグレーション・ジャーニーやモダナイゼーション・ジャーニーをサポートさせて頂いています。

アマゾン ウェブ サービス ジャパン合同会社 倉元


モダンなインフラ構築にむけて

倉元(AWSJ):
 EBAでは、モダナイゼーションをテーマにプロジェクトを実施させて頂きました。モダナイゼーションというキーワードは非常にキャッチーであるとともに、様々な意味が含まれます。

平井さんが考える、モダンなインフラを検討・設計・構築を推進するにあたって目指している事や大事な事は何でしょうか?

平井(パイオニア):
技術的なお話ですが、IaCやコンテナ及びCI/CDを活用しているインフラ環境だと考えています。

IaCやコンテナを利用することで、環境の再現性の高さを担保したり、CI/CDを使ってDevOpsを支え、開発を高速に進めていくことが重要だと思っています。

倉元(AWSJ):
重要なことですよね。IaCやコンテナなどをうまく活用してスピーディな開発を実現することで、今までより早くビジネスアイディアを実現できるようになります。

この仕組みが成熟すると世の中のスピードに追い付き、追い越していけるようになるかもしれません。

平井さんのミッションはそれを推進していくことだと思っているのですが、その際に強く意識している点はありますか?

平井(パイオニア):
大きく2つあります。1点目は解決したい課題を的確に捉えて、適したアーキテクチャを検討することですね。

例えば、社内のあるPJでの話なのですが、約10年前ぐらいに、その当時に流行ったある技術を利用して、アーキテクチャ設計をしていました。ただ、現状の要件にはあまり適しておらず、技術的な負債が溜まっており、現在、なんとか継続運用をしている様な形になっています。

機能追加する場合も工数が多くかかり、インフラの運用/保守コストも多額の費用が発生し、ビジネス成長を阻害している状態が続いていますね。この現状を改善するために適切なアーキテクチャを構築することを検討し始め、リニューアルに向けて取り組み出しています。

例えばAWSのマネージドサービス等も利用させて頂き、運用コストの削減などを検討しながら進めていますね。

2点目は、技術のアップデートを定期的に追っていくという点です。
過去の経験でも、例えばAWSのアップデートによって、コストを下げることができたり、今まで課題だったものが解消できる事例もありました。そのアップデートを使わずに運用を続けてしまうと、将来的にはペインポイントになってしまいます。

こういうことを防ぐためにも、技術のアップデートに従い、適切な技術を利用していく事が重要だと考えています。

倉元(AWSJ):
おっしゃる通りですね。技術的負債を抱え込まない仕組みにするのは、とても大事です。

例えば、AWSであれば、マネージドサービスを活用して如何に効率化するかという観点は大切です。先程、古いアーキテクチャの事例をご紹介いただきましたが、例えば10年前だとSOAやESBといったキーワードがよく聞かれました。

今はマイクロサービスやコンテナ、サーバーレスなどがよく聞かれるキーワードだと思います。やはり、凄まじいスピードで技術が変化しています。

平井(パイオニア):
そうですね。繰り返しにはなりますが、やはり技術のアップデートを追いかけ、常にキャッチアップをし続け上手く適応する。このサイクルを繰り返していくことが重要かなと思っています。

倉元(AWSJ):
今まで実際に上手く取り組めた事例はありますか?

平井(パイオニア):
まさに着手中で、目下体制作りをしている状態です。従来はベンダー等を利用しながら、サービスを開発していました。今後は内製化することで技術の進歩をキャッチアップし、プロダクトへ活かしていこうとしています。

倉元(AWSJ):
一人称で責任をもって進めようとする意思が感じられますね。Amazonの信条 Our Leadership Principles にはOwnershipという項目があるのですが、それに通じるなと感じます。


EBAで得た新しい気づき

倉元(AWSJ):
EBAを通じて、新たに得た気付きや重要なポイントについて、お伺いしてもよろしいでしょうか?

平井(パイオニア):
こちらも大きく2つありました。1点目は、アーキテクチャを考えるときの広い視野を持つ重要性ですね。

今回はスペシャリストSAの方から様々な角度からreview頂いたのですが、自分達で思いつかなかった観点でご指摘を頂くことができました。やはり、多角的に考えることの重要性を感じましたね。

2点目は、技術と少し離れますが、EBA中はビデオ会議を顔出しで繋ぎっぱなしにしていました。

繋ぎっぱなしなので、相手の表情を掴みやすく、声もかけやすい等のメリットがあり、顔出しでのコミュニケーションの解決の速さを改めて認識しました。まるで、同じフロアにいるかのように接することができ、表情が分かりリアクションが掴める点が良かったです。

倉元(AWSJ):
この取り組みはその後も続いていますか?

平井(パイオニア):
要所要所で、”繋ぎっぱなしでやろう”という話が出ています。

倉元(AWSJ):
その後も続いているようで嬉しい限りです。一つ目に対してですが、AWSには Purpose-Built Databases という考えがあります。

一つの選択肢に限定せず、様々な選択肢を持ち、適材適所に使い分ける考え方です。今回、パイオニアの皆様はこの考え方をご理解いただき、「これは使っていこう」「これは合ってないので使わない」という形で組み立てられていたのが印象的でした。

こちらの考え方も継続的に活用いただけますと嬉しいです。

皆様のインフラに対する変革に向けた取り組みの中で、これは重要なポイントだと思われる点はありますか?

平井(パイオニア):
従来、開発を外部の方にお願いしてしまっており、技術のアップデートや自分達で活かす文化が正直弱かったです。

今後は内製化を推進し、技術のアップデートに追い付きながら主体的に改善に取り組む、それが当たり前とされるカルチャーの醸成が重要だと思っています。


パイオニアが目指すエンジニア組織の在り方

倉元(AWSJ):
Amazonでは、「Two-Pizza Team」、つまりピザが2枚で足りるくらいの小規模なチームを作り、「You build it, you run it.(開発する人が運用する)」という方針にもとづいて、自分たちのチームで作って運用まで行うという考え方があります。

これによって、Amazonでは大規模な開発をスピーディーに実現していますが、他のお客様でも参考にできると考えています。これを体験して持ち帰って頂き、実際に社内で実現されようとしているのはとても素晴らしいです。

組織のお話が出たので、今のチームについても伺えますでしょうか。SREチームの立ち上げ時期だと伺っております。もしよろしければ、どのような組織や体制を目指しているのかお伺いしてもよろしいでしょうか?

平井(パイオニア):
直近と未来の大きく2つに分かれています。

直近では、開発を担当しているメンバーとインフラを担当しているメンバーの距離が少し遠いので、SLOなど共通的な指標を持ってプロダクトを良くするためにディスカッションや協力できる組織にしたいと思っています。

また、パイオニアではEdgeに関わる人も多いのですが、 その方たちがインフラの領域にチャレンジし、バックアップできるような組織にしようとしています。

未来の視点では、バックエンドのエンジニアとSREのエンジニアがチームを行き来できる組織にしたいと思っていますね。

理由は立場を変えることにより、お互いの課題を肌で感じて、より良い改善ができるようになると考えているからです。

倉元(AWSJ):
一般的に、開発担当・インフラ担当と分かれがちですが、そうではないということですね。

お互いの立場を理解しあえる環境や、それぞれのチームを行き来でき、自分の実現したい姿にチャレンジできる場はとても魅力的だと思います。

平井(パイオニア):
パイオニアの環境として、インフラやバックエンドのエンジニアもエッジに触れたり、実際に車両に乗って検証ができる環境があります。また、グローバル展開をしている企業なので、海外も考慮したシステム構築に関わることができる環境も魅力ですね。

倉元(AWSJ):
実際に動いている車と自分が作ったシステムが繋がっている感覚を得られることはとても新鮮だと思いますし、実感があると思います。

またグローバルとなると、大規模な開発であったり、高いクオリティを求められるので、エンジニアとしてはやる気をかき立てられる、やりがいを感じられるのではないかと感じます。


インフラレイヤーの自動化について

倉元(AWSJ):
インフラレイヤーの自動化についてお伺いさせてください。SREの立ち上げのお話に関連しますが、今後パイオニアのSaaS基盤として横展開していくための仕組みづくりなど意識していたのでしょうか?

平井(パイオニア):
経験上、  サービスやプロダクトが異なれど、インフラは一定標準化・共通テンプレート化できることが多いと感じています。

今後、パイオニアでも新規事業を推進していく方針であり、MVP開発などが発生するので、ローンチまでのスパンを短くする必要があります。開発としては、共通テンプレートなどを利用し、早い段階でビジネスを立ち上げられるようにしていきたいと考えています。

倉元(AWSJ):
複数のプロジェクトを立ち上げ、うまく全体をスケールさせるには仕組みが必要になります。

AWSでは管理統制や標準化の仕組みについても注力しています。今回は扱わなかったですが、AWS Control Tower を利用して、複数アカウントを上手く管理していくことや、テンプレートやガードレールを敷いていくことも必要だと考えています。こういった仕組みが最初から存在すると、安心・安全な環境の中で作業を進められます。 

また、インフラに関わらずアプリケーション全体のCI/CDの部分も仕組みとして構築されようとしていますね。

今回は、GitHub/GitHub Actionsに加えて、AWSのCode シリーズを活用していました。まさに適材適所でしたが、使い分け方をお伺いしてもよろしいでしょうか?

平井(パイオニア):
GitHub Actionsは、CI/CDの部分でメインに使いつつも、AWSのサービスとして、CodeBuildを利用させて頂いています。

使い方はDBマイグレーションに利用しています。細かい話になるのですが、 GitHub ActionsはPrivate Subnetにアクセスできない一方で、CodeBuildだと ENIを割り当てられるので、Private Subnetのリソースにアクセス可能になるメリットがあり利用させて頂いています。

また、内部公開用のAPIのE2Eテストへの利用も想定しています。

倉元(AWSJ):
ある問題に対して色々な解決方法があると思いますが、特定技術を無理やり使ってしまった結果、技術的負債が生まれることもあります。挙げていただいた例は、課題をシンプルに解決できた、とても良いアプローチだったと感じています。

様々なサービスを選択しながらご利用頂いているかと思いますが、特に気に入っているサービスはありますか?

平井(パイオニア):
そうですね。前提として、AWSは多種多様なサービスがあるので、それを要件に合わせ、組み上げて、作れる点にまず面白さがあると思っています。

その中でも好きなサービスとしては、個人的にはAWS Lambdaですね。僕は元々アプリケーション側のエンジニアなので、サクッとコードをかいて、デプロイして色々なアプリケーションを作ることができる点が魅力ですね。

後は、Kinesis系と連携すれば大量データを捌くことも可能ですし、API Gatewayと連携して、webのバックエンドのAPIも開発も可能だったりしますよね。また、値段も従量課金制でコストも安価に抑えることができ、PoC等にも使いやすいのが気に入っています。

倉元(AWSJ):
ちなみに、私がAWSサービスの中で初めて触って驚いたのは、Kinesisでした。キーワードが繋がって驚いています(笑)

AWS上でIoTシステムを構築していたのですが、数千~数万TPSで飛んでくるデータの処理方法を検討した際に利用しました。最初は本当に簡単に環境を作れるのか?受けきれるのか?が懐疑的だったのですが、実際に作って動かしてみると、すんなり処理できたことに驚き、世界が変わると感じました。

サービスによっては使いこなすまでに多少の慣れや経験が必要な場合もありますが、平井さんの様な経験者が周りについていてくれるとスムーズに進むのかな、と思います。

御社が取り組まれている組織体制はエンジニアにとって心強く、素晴らしい環境だなと思っています。柔軟に変化していこうとされている活動はとても魅力的だと思います。

今回はEBAでご一緒させていただきましたが、また別の機会でもご一緒させて頂ければ嬉しいです。本日はありがとうございました。

平井(パイオニア):
ありがとうございました。

最後に

本日お話しているEBAに関しては、Amazon Web Services ブログで詳細を確認することができます。

ご興味ある方は是非ご覧ください。また、パイオニアでは変革に向けて一緒に働く仲間を募集中です!老舗メーカーの変革に少しでも共感、チャレンジしてみたいと思われた方は、こちらの採用ページをご覧ください。



みんなにも読んでほしいですか?

オススメした記事はフォロワーのタイムラインに表示されます!