アーカイブ動画
Part1:若手エンジニアが活躍、実績も出すPAYCIERGE SoEチームとは?
TIS株式会社
デジタルイノベーション事業本部
サービスプラットフォーム事業部
サービスプラットフォーム第一部
エキスパート 二出川 弘氏
最初に登壇したのは2008年にTISに入社して以降、長年にわたり大手クレジットカード会社のシステム基盤業務に携わった後、2019年からはTIS独自の決済ブランドである「PAYCIERGE(ペイシェルジュ)」のAWS領域を担当。現在は技術統括を務める二出川弘氏だ。
二出川氏は2021年から4年連続でJapan AWS Top Engineersを受賞するなど、Japan AWS Engineers アワードの多くを継続して受賞しており、2024年9月にはAWSの認定資格すべてを保有する者に贈られる、AWS Ambassador - Certification All Stars 2024も受賞。AWS関連の各種イベントでの対外活動も務める。
TISはグループ従業員約2万2000名、グループ会社約60社という規模を誇り、金融業界を筆頭に製造や流通といったさまざまな業界に約1万5000の顧客を持つ、国内トップクラスのSIerである。
特に、クレジットカードやデビットカードのシステム開発ではシェア率も含め、名実共に存在感を発揮。これまでの経験と先進技術が詰まった独自の決済ソリューションサービスPAYCIERGEを提供している。
PAYCIERGEは多くのシステムから構成されており、「その多くのシステムでAWSを活用しています」と、二出川氏は語る。中でも大きな役割を担っているのが、PAYCIERGEの基盤環境。もう一つが、基盤自体をPaaSとして顧客に提供するものだ。
PAYCIERGEをベースとしながらも、ニーズやシステムの最適稼働など、顧客の仕様に合ったシステムやインフラ、各種ITサービスを顧客ごとに提供する、いわゆるオファリングサービスを提供しているのもTISの特徴だ。
AWSの活用においても同様で、「お客さまが容易に利用でき、ビジネス価値を発揮できるように、インフラ基盤の提供からサービス企画、さらにはコンサルティングまで、トータルに支援しています」と、二出川氏は述べた。
こうしたサービス提供を実現しているのが、SoE基盤領域、特にAWSの活用に特化した、PAYCIERGE SoEチームである。チームが発足したのはAWSの利用が始まった翌年の2020年度であり、担当案件の増加に伴いチームの規模も拡大していく。
2021年度にJapan AWS Top Engineersに選出されるメンバーを輩出したのを皮切りに、以降はJapan AWS Engineersの各種アワードにおいて、多くのメンバーが受賞している。2024年度には4部門で受賞するまでに至る。
短期間でなぜここまで、優秀なAWSエンジニアを輩出しているのか。二出川氏は顧客への継続的な価値提供を踏まえた上で、「チャレンジ要素を活動の中に加えています」と語った。
若手メンバーが主導で企画を推進できることや、有用だと感じた技術を積極導入できる環境や体制などである。
現在、チームのメンバー数は約20名だが、AWSの経験年数は約2.5年しかない。それでも多くのアワードを受賞している実績を示し、「詳細はメンバーに発表してもらいます」と述べ、二出川氏はファーストセッションを締めた。
Part2:アマゾンの行動規範「Bias for Action」の実践で、短期間の急成長を実現
アマゾンウェブサービスジャパン 合同会社
パートナー技術統括本部 第三技術部
パートナー ソリューション アーキテクト 石倉 徹氏
続いては、パートナーのAWSビジネスを技術面からサポートしている、アマゾンウェブサービスジャパンの石倉徹氏が登壇した。
今では当たり前のように使われるようになったAWSをはじめとするクラウドサービスだが、中には現在も導入をためらうケースもあり、各種課題があると石倉氏は指摘する。
「詳しい技術者不足のため、利用が限定的になる」「サーバレスは難しいのでEC2に頼る」など、具体的な理由についても述べた。
一方で、このような課題の本質を深堀っていくと、新しいことを始める際に組織の調整が必要であり、個人の問題というよりも組織に課題があることが見えてきた。「組織を変えていくことで、クラウドの活用が今以上に進む」と、石倉氏は言う。
そして、組織変化を起こすために取り入れられることとして、アマゾンで根付いている二つの文化が参考になるという。「オーナーシップと自主性」「失敗を許容する文化」だ。
アマゾンではOur Leadership Principles(OLP)という行動規範ならびに信条を掲げている。言葉通り、社員一人ひとりがリーダーであるとの考えに基づき、日々の業務はもちろん、サービス開発や採用といったシーンで、OLPが重要視されている。
OLPは16項目からなるが、石倉氏はその中の一つ「Bias for Action」を取り上げた。こちらも言葉通り、「まずは行動する」「スピード重視である」という規範である。
だが一方で、単にスピード重視で行動しては、リスクが生じる場合もある。
そこで参考になるのが、こちらもアマゾンにおける意思決定手法のひとつである「2- Way Door 」という考えだ。
一度決定したら後戻りすることができない「1- Way Door 」とは異なり、決定した後も修正が可能なケースを示す言葉であり、石倉氏はこの考えをシステム導入で説明した。
「オンプレは1- Wayになりがちですが、クラウドであれば2- Wayの考え方を踏襲しやすいですし、このような考え方を持っていることが、クラウドを使う上で重要です」(石倉氏)
失敗を許容する文化については、発売翌年に販売を中止したアマゾンが開発したスマートフォン「Fire Phone」を挙げ、「事業は失敗でしたが、悪く言う人はいませんし、成功するためには失敗も重要です」と、述べた。
ここからはTISとの協業について紹介した。先に二出川氏が説明したように、2019年にAWSの利用を開始するタイミングで、二出川氏から構成レビューを依頼されたのがきっかけだった。
当時は今のようにAWSが普及していなかったこともあり、「EC2を利用しているのだと思っていました」と石倉氏。ところが、構成を見て驚く。既にサーバレスサービスを利用していたからだ。
新しい技術ということもあり、当時はまだサーバレスサービスは不安定であった。そのため利用においては、リスクもあった。しかし、コストやスピードといった利点を評価していた二出川氏は、リスクを踏まえた上で利用するというチャレンジに踏み切ったのである。
「まさしくBias for Action的な取り組みだと言えるでしょう」(石倉氏)
石倉氏は、二出川氏やPAYCIERGE SoEチームの決断を評価するとともに、新たなサービスを提案するとすぐに利用する体制作りを行ったという。「まさに、アグレッシブでしたね」と、振り返った。
一方で課題も生じた。「アカウント増加によるセキュリティ状況を可視化したい」というニーズだ。
そこで、ここでも二出川氏は石倉氏が提案したSIEM(Security Information and Event Management)に必要な機能を、Amazon OpenSearch Service環境に実装したSIEM on Amazon OpenSearch Serviceを採用する。
このような取り組みもチャレンジだったと、改めて石倉氏は語る。活用状況を会社の公式ページに、ブログとしてアウトプットしていることも含めて、PAYCIERGE SoEチームの取り組みを評価した。
PAYCIERGE SoEチームのこのチャレンジングな取り組みは、結果としてエンジニアが成長し、その先にビジネスを牽引するという成果をもたらす。さらには先述したAWSの各種アワードを受賞するなどの成果が出ることで、エンジニアのモチベーションも向上する。
モチベーションが向上したエンジニアは、さらなるチャレンジに臨む。このようなポジティブなループが回っていることこそ、PAYCIERGE SoEチームならびにTISの強みというわけだ。「いいループが回っていると思います」と述べ、石倉氏はセッションを締めた。
Part3:若手メンバーが未経験から3年でAWS Top Engineersを受賞できた理由
TIS株式会社
デジタルイノベーション事業本部
サービスプラットフォーム事業部
サービスプラットフォーム第一部
チーフ 野澤 祐介氏
続いて登壇したのは、2021年に入社して以降、PAYCIERGEのAWS領域の開発チームに所属。金融系ソリューション開発案件に数多く携わってきた、TISの野澤祐介氏だ。
セキュリティの強化や生成AIの活用検討といった、サービス強化活動にも携わる野澤氏は、二出川氏と同じく2024年のJapan AWS Top Engineers、Japan AWS All Certifications Engineersをダブル受賞している。
最初のセッションで二出川氏が紹介したように、なぜTISでは野澤氏のような数年の経験でAWSのトップエンジニアに成長しているのか。野澤氏は理由を大きく三つの観点から語った。
まずは入社1~2年目の社員に対し行われる、基礎力向上のための各種教育カリキュラムである。注目すべきは、AWS上に典型的なWebシステムを疑似的に構築し、実際に動かしてみるというカリキュラムだ。座学でAWSに関する基礎を学んだ後に行われる。
「理論を実践に結びつけることができるカリキュラムであり、私自身、このカリキュラムを通してAWSに関する基礎スキルを習得できたと思っています」(野澤氏)
疑似環境でのトレーニングが済んだ後は、実案件などでの実装を任される。そして、ここからがポイントだ。単に歯車的な役割としてのアサインではなく、業務改善の仕組みをイチから一人で構築するような業務も任されるのだ。TISならではの育成手法と言えるだろう。
さらには要件定義といった上流工程だけでなく、実際にLambdaにアップロードするコードのプログラミングといった領域や工程まで、業務全体のフローを一貫して担当する。そのため、業務やサービスの仕組み全体を把握でき、構築できるスキルが自然と身についていく。
野澤氏は自身が構築した遅延発生時の運用を自動化するアーキテクチャを紹介。「このような業務体験をしたことが、現在携わっているサービス強化活動の土台にもなっています」と、語った。
2年目以降はさらに、開発案件の主担当として全工程に携わっていく。そのため技術力以外にも、コミュニケーションスキルやプロジェクト推進能力など、いわゆるソフトスキルも磨かれていく。
野澤氏は、自身が一人で構築したアーキテクチャを紹介した。スライドを見ると分かるように、セキュリティやWeb技術なども関連している。同領域に詳しいエンジニアと協力することで、さらなる専門知識をスピーディーに身につけていったという。
3年目以降になると、リーダーとして案件を主担当するケースは、より増えていった。当然、これまでにも増して関わる領域は増えるために、多様な技術ならびにソフトスキルがさらに醸成されていく。
一方で、なぜここまで若いエンジニアが案件を主担当できているのか。そのような疑問にも、野澤氏は回答した。理由はシンプルで、チャレンジも含め、若手エンジニアの育成に係るコストよりも、得るリターンの方が大きいからだ。
野澤氏が紹介してきた内容に重なるが、実践も含めた充実した教育プログラムが整備されているからに他ならない。特筆すべきは、エンジニアであれば誰でも興味を持つ、先端技術も若手エンジニアの意向で、積極的に取り入れることができる点だろう。
実際に野澤氏も、以下スライドのような生成AIを活用したサービスをリーダーとして開発している。エンジニアにとって働きやすい、やる気やモチベーションが常に醸成される環境であることが伝わってくる。
さらには石倉氏が紹介したように、ブログの記事を執筆したり、講演に登壇したりするなどの機会も増えている。その結果、ライティングやプレゼンテーションといった、通常の業務では培うことができないさらなるスキルが身についているという。
「論理的思考力なども深まったと感じています」(野澤氏)
最後に野澤氏は、困ったときに気軽に相談できる同僚や上司がそばにいること、相互サポートの文化もあると語り、以下のように述べ、セッションを締めた。
「このように大きく三つの組織文化により、私自身も含めて未経験でも短期間で活躍・成長できる環境が整っていると思います」(野澤氏)
Part4:AWS環境自動構築システムを若手3名で構築──失敗をすることで「顧客志向性」スキルを向上
TIS株式会社
デジタルイノベーション事業本部
サービスプラットフォーム事業部
サービスプラットフォーム第一部
シニアアソシエイト 安冨 良映氏
続いては、TISの若手エンジニアで、PAYCIERGEのAWS領域における保守や開発を担当する安冨良映氏が登壇した。2022年にIT未経験、文系新卒で入社した安冨氏だが、二出川氏や野澤氏に続き、2024年のJapan AWS Jr. Champions、Japan AWS All Certifications Engineersをダブル受賞している。
PAYCIERGE SoEチームでは、2019年にチームが発足して以来、常に自動化を意識してきた。サービスの順調な浸透と拡大に伴い、工数やコストの削減、より信頼性の高いシステムを構築する、人為的ミスを防ぐなど、今まで以上のサービス品質の向上が求められるようになったからだ。
具体的には以下スライドで示したように、2019年度にIaC(CloudFormation)を導入したのを皮切りに、翌2020年度にはIaCの汎用化に成功。2022年度にはService Catalogを用いた自動構築を実現した。PoC環境の構築工数を半分以下に削減するといった実績を挙げた。
さらに2023年度には、本番商用環境の自動構築も実現させる。そして、同プロジェクトを実現させたのが、安冨氏ら若手メンバー主導によるものであった。
安冨氏は実際に構築した自動化システムの概要ならびに、フローを紹介した。まずは以下スライド左側に位置する基盤サービスチームの担当者が、専用のWebサイトに案件情報を登録する。
すると、システム構築に必要なIaCコードや設計情報が、Excelデータとして自動で抽出される。このExcelデータに先の担当者が再び、設計検討情報ならびに結果を記入する。その結果、IaC化された設計情報が自動でクラウドテンプレートとして出力されるという流れだ。
そして、このIaCコードを自動で実行すれば、CloudFormationがスタック作成を開始するため、AWSの各リソースの構築が自動で行われる。
安冨氏は各領域において、どのようなAWSリソースを用いたのかを紹介。スライドで示した4つの領域(機能)は、自分も含めた若手メンバー3名によるチームで開発したと語り、それぞれの領域を解説した。
まずシステム情報入力機能ではAmplifyを活用して、Webサイトの構築を行った。ただし、Webアプリ領域の知見が乏しかったため、同領域に強いメンバーと連携しながら構築を進めた。
その他三つの領域では、Step Functionsを中心としたワークフロー制御とし、Step Functionsで補えない機能についてはLambdaを組み合わせることで、コーディング量の削減と機能の分散化を実現した。
「Step Functionsによるワークフロー管理により、機能ごとの独立性が高まり、チームでの並行開発や機能拡張が容易なシステムとなっています」(安冨氏)
開発スケジュールも紹介された。2023年4月に自動化の対象を整理することから始まり、半年後には最初のシステムが完成。その後はフィードバックを重ね、現在も改善を続けている。
開発においては当然、多くの課題が生じた。安冨氏はその中から二つ紹介した。一つは、最初のシステムを構築した際に生じた、「ユーザー視点の欠如」によるものだ。
CloudFormationテンプレートの出力がバラバラになっていたため、複数のCloudFormationテンプレートを出力したい場合、ステートマシンの処理を繰り返す必要があった。コミュニケーション不足など、原因も合わせて紹介した。
安冨氏はさらに、同課題や解決から学んだことも語った。システム全体のアーキテクチャをメンバー全員が考え、共有することだ。さらに、チームで積極的に意見交換を行うようにした。
「当時は保守業務の経験しかしていなかったので、 開発プロセスの流れで必要な作業も、この構築を通して学ぶことができました」と、安冨氏は成長の成果を述べた。
二つ目の課題は、フィードバック時に生じた、AWSリソース単位で要求通りの柔軟な設定にできなかったことだ。
二つ目の課題においては、最終的に何ができればよいのかを明確にし、そこから逆算して細かいタスクに分け、一つずつ着実に対応していくことで解決していった。
安冨氏は、先の課題と同じく、得た学びも紹介した。
最後に、安冨氏は同プロジェクトを通じて、三つの能力「顧客志向性」「クラウドネイティブなアーキテクチャ検討能力」「課題対応におけるアジリティ」が大きく向上したと語った。
また、これらの能力の向上は、失敗を恐れずにチャレンジしたからこそ得たものであり、「インフラの自動構築によるサービス品質の向上という目標を達成できた」と、成果を述べ、セッションを締めた。
【Q&A】参加者から寄せられた質問に登壇者が回答
すべてのセッション終了後、Q&Aタイムが設けられた。抜粋して紹介する。
Q.AWSから表彰されても会社が評価してくれないが、どうすればよいか?
二出川:まずはチーム内だけでもよいので、表彰されたことを褒め合うと良いのではないでしょうか。ちなみにTISではCCoEの方々が、表彰制度やAWS認定の取得を奨励しているため、全社として取得者に敬意があると思っています。
AWSさんからの表彰に限らず、マネジメント層がチャレンジしたことに対して一緒に喜んでくれるので、次に向けてがんばろうという気持ちになることが多いと思います。
Q.失敗を恐れない組織とは、具体的にどのような組織で、何をすればよいのか?
野澤:継続的にチャレンジができている組織だと考えています。例えば今年の4~5月にかけて、生成AIを活用して業務改善しようとのチャレンジに取り組みました。出したアイデアは10個あり、採用されたのは4つです。
うまくいった取り組みはどんどん進める一方、うまくいかなかったケースは他で活かせるかもしれない。このように考える組織風土も大きいと思います。前提として、二出川さんが若手メンバーのアイデアを許容してくれるのも、大きいと思います。
Q.印象的な失敗とそこから得た教訓とは?
安冨:失敗をすることが当たり前ではありませんが、挑戦を繰り返す文化があることだと思います。失敗をあまり引きずっておらず、失敗と捉えていません。
野澤:私も失敗を失敗と捉えていないので、ぱっと思いつきませんが、挙げるとすれば入社2年目に初めて主担当で取り組んだ案件です。
自分はできると思ってがんがん進めてしまい、リリース直前に本番環境のIP設定を自分の判断で変えてしまいました。結果として二出川さんに助けてもらいましたが、勝手に突っ走るのはよくないと学びました。
Q.入社当初から描いていたキャリアビジョンや将来の計画は?
野澤:新卒当初から、5年先ぐらいまでのキャリアビジョンは描いていました。AWS領域でまずは突き抜けることです。3年目でAll Certifications Engineersを、5年目でTop Engineersになることを目標に掲げていました。
安冨:あまり考えていませんでした(笑)。ただ、一つ上の野澤さんがAWSの資格を取得していたこと、同じく他のメンバーも資格を取得していたので、自分はその背中を追う感じでした。
Q.AWSの知識が乏しい状況で、AWS関連の開発案件を進める場合に意識すべきことは?
石倉:勉強から入るのはよくないと思います。まずはメンバーで話し合い、どのようなシステムを作りたいのかを考える。動機や夢を語りながら、手を動かしながら必要な技術を学び、身につけていくのがいいと思います。
二出川:私も手を動かすことが大事だと思います。実際、2020年に私たちのチームが発足したとき、AWSを知っているのはかろうじて私だけでした。そこで5人のメンバーがまずは手を動かしてみて、私が確認する。まずは無茶をしてでもやってみる。その覚悟が必要だと思います。