1年でクラウドネイティブ人材に! 〜決済プロジェクトを通じて爆速で成長した話〜

![ECE1F1CA-8C53-49B5-9ACD-24251D0BF472.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3289228/234bbfc0-ab46-e973-090f-977b3f42bafd.jpeg)
<sup>(今回記事執筆を担当したESCAPEチームメンバー５人。左から杉山、井上、松岡、門田、南條)</sup>

　こんにちは！

　NTTデータ ペイメント事業本部 カード＆ペイメント事業部デジタルペイメント開発室の、チームESCAPE<sub>*1</sub>です！

　私たちの所属するデジタルペイメント開発室（以降、デジペイ）では、大規模アジャイル開発のフレームワークであるSAFeを用いて、総勢200名以上のメンバーで様々なサービスの開発を進めています。

　私たちESCAPEは、OmniPaymentGatewayという決済プラットフォーム(後述)の開発を配属後の研修の後すぐに任せていただきました。初期のESCAPEチームは9名で構成されており、なんと開発メンバーは7人全員が２年目の新人でした。

　プログラミングの経験者は半分ほどいたものの、この状態で商用プロジェクトにアサインされることって普通の会社だと中々ないと思います。皆さんの想像通り苦難の連続でした。(笑)




　この記事ではそんな従来のNTTデータのイメージ<sub>*2</sub>とは一味違った雰囲気を持つデジペイに配属された後、幸か不幸かいきなり商用プロジェクトにいきなりアサインされた(されてしまった)ESCAPEが、決済プロジェクトを通じて爆速で成長した話を通じて、デジペイの魅力を皆さんに伝えることができればなと思います！

　若手の内から裁量を持って開発したい方、モダンな技術スタックを身につけたい方はぜひ記事を読んでいただければ嬉しいです！

<sub>(*1)ESCAPEのチーム名の由来は配属後の研修で脱出ゲームを作ったことと、NTTデータの堅いイメージからの脱却したいと言う意味が込められています。</sub>
<sub>(*2)全社的にはウォータフォール開発が主流で、新人が設計、開発、リリースなどのシステム開発のフローを一気通貫に担当する部署は他にほとんどないです。</sub>


# プロジェクト概要

![スクリーンショット 2023-04-17 16.26.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3289228/1039d8ac-ef86-8b60-ee61-ad29f6a7e51c.png)


　皆さんはキャッシュレス決済を使用していますか？日本では現在全体の30%を超える割合で現金以外での支払いが行われており、今後さらに割合が増加すると考えられています。

　NTTデータでは、小売店や個人事業主様が迅速にキャッシュレス決済を導入できるようOmniPaymentGatewayというサービスを提供しており、顧客のライフスタイルに合わせたシームレスで快適な購買体験ができることを目標に日々取り組んでいます！

　決済機能以外にも申込、契約、審査、精算、運用、売上管理などを一元管理できる点もサービスの強みとしており、今後さらにお客様を増やすために鋭意アップデートを行っています。

　そんな今熱いプロジェクトについて、簡単に説明していきたいと思います！







#### Q. OmniPaymentGatewayプロジェクト設立期間は？

    約3年です！まだ若いプロジェクトですね。

#### Q. 何人くらい参画してるの？

　協働者様含め200人以上(18チーム＋SRE, CREチーム)です！このプロジェクトは始まってから3、4年程度にもかかわらず、すごい人数ですね！
<sub>※SREチーム...Site Reliability Engineeringを主活動とするチーム。</sub>
<sub>※CREチーム...Customer Reliability Engineeringを主活動とするチーム。</sub>
#### Q. どんな開発手法を採用してるの？

　アジャイル開発を行っています。こんなに大規模なアジャイル開発をしているところはかなり珍しいですね。

　1人の開発者が1つのフェーズを担当するのではなく、設計からテストまで、全てのフェーズに参加できることも大きなポイントですね！

#### Q. 開発サイクルは？

　2週間を1サイクルとしています！

#### Q. リリースサイクルは？

　約3ヶ月です！こまめにリリースできるのが特徴です。


# リンク決済とは

　続いて、リンク決済について簡単に紹介していこうと思います！

　リンク決済は、OmniPaymentGatewayが提供しているAPIを叩くだけで簡単に決済用リンクを発行できる機能で、ご契約者様のECサイトに決済機能を簡単に追加することができるサービスです！
![screencapture-localhost-8080-item-abcd12345-2023-01-04-11_32_20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3289228/70b10964-3ef7-bf7e-1320-ef5f15c20867.png)





　実はこれ、配属されたばかりの新人社員が作ったものなんです！




#### Q. どうやって作ったの？

　クラウドを活用してのマイクロサービス化を入社1年目の新人が0から作り上げました。

　さらにはバックエンドサービスだけでなく、決済用リンク先の決済画面の設計開発も自分達で0から行っております。企画営業担当者やビジネスオーナーの方と話し合って一緒に一つのサービスを作り上げていくことは難しいこともたくさんありますが、とてもやりがいのある楽しい仕事です。

　特にリンク決済では、定期実行を行うためにバッチアプリケーションを開発したりと、クラウドをフルに活用できるのも魅力の一つだと考えています！




#### Q. 運用保守はどうしているの？

　決済に関わるアプリケーションはミッションクリティカルなため、kubernetesを活用したpod管理を行い、またログを自動で監視して問題が発生した場合、担当者に通知がくる仕組みも取り入れています。




#### Q. 非機能試験は？

　単性能試験、障害試験等は自分達で実施し、性能を担保しています！

　SLA(サービスの提供事業者とその利用者の間で結ばれる、サービスのレベル)を達成するためのインフラ構成を考えたり、データベース設計を行うなど、新人としてはなかなか経験させてもらえないようなこともできます。

# 配属後にぶつかった困難、そこから学んだ点

　私たちのチームは上記のように、従来のNTTデータではなかなか新人に任せてもらえないような商用サービスの開発を担当していますが、初めの方は特に困難の連続でした、、

　ここでは各チームメンバーにその時の心境などを聞いてみたいと思います！

　まずは配属後〜初リリースまでの期間についてチームの仕切り役の杉山君に伺ってみました！


#### Q.配属後〜初リリースまででぶつかった困難、辛かった点などはありましたか？

A. 前提として私たちのチームはある程度プログラミング経験者が多かったのですが、学生時代に実際にサービスを設計開発運用などをしたことがあるメンバはおらず、全てが初めての連続でした。

　そのため仕様がある程度決まっていても実際の開発をするとなると、APIのIF設計とは何だろう、データベース設計は何からすればいいんだろう、そもそもどの言語でどのフレームワークを使ってコードを書けばいいんだろう、マイクロサービスの責務ってどういう風に分けるといいんだろう、開発環境での動作確認はどうやってするんだろうなど枚挙に暇が無いほど分からないことだらけでした。

　また開発に関連する用語が分からない、OmniPaymentGatewayプロジェクトについての知識が浅いなど、そもそもの知識不足の問題にもぶつかっていました。(笑)

#### Q.それらの困難に対してどのようにアプローチしたのですか？

A. 例えば知識不足の問題については、色々な本を読んだりネットで調べたりして基礎知識を身につけつつ、プロジェクト内の資料をとにかく読み、チーム内外の先輩方に色々ヒアリングなどしながら対処していきました。

#### Q.そこからどのようなことを学ぶことができましたか？

A. 自走力や質問力です。分からないことがあるのは仕方がないですが、誰かに質問する際も自分なりに調べて答えの仮説を立てたり、問題点を明確化したりすることで求めている答えを効率的に得ることができますし、答える側の負担を減らすこともできます。また自分なりに問題を論理的に組み立て言語化することで自然と解決する問題も度々ありました。

　振り返ってみると、こういったどの開発現場でも汎用的に役に立つようなスキルやマインドセットを身につけることができたのがこの時期の１番の収穫だったかな、と思います。




(分からないことがわからなくて沼にハマる杉山君)
![image2022-12-27_17-19-57.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3289228/41c6fda3-63c1-ef84-9d5a-8f25b4f7ed87.jpeg)








___
　こうして最初の苦しい時期を乗り越え、いよいよ初リリースが迫ってきました！

　初リリースまでの期間についてチームメンバーの井上君に伺ってみました！

#### Q.いよいよ初リリースが迫ってきましたね！この時期でぶつかった困難や印象に残っている点などはありますか？

![D9AA9914-C9D8-4654-86AA-6B4AC0DF0B77.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3289228/e73b725c-879e-fcb2-1c4f-592a029292eb.jpeg)

A.ここでぶつかった困難は、結合試験で見つかる不具合の対処や、リリースに必要な手順が具体的にイメージできていなかったことなどですね。

　結合試験の観点などを抜け漏れなく洗い出すのが難しく、結果的にテストでは数多くの不具合が見つかり怒られたりしたのは良い思い出です。(笑)

　またリリースについても、アプリケーションのデプロイの仕方や商用環境での作業内容など、分からないことが多く非常に苦戦しました。

　商用環境での作業はものすごく緊張しますし、自分が打つコマンド一つ一つに対するプレッシャーが凄かったことがとても印象に残りました。

　当日何が起きても焦らないように、リリース手順書は細かすぎるくらい書くのがと大切だなと気付けました！
___
　無事リリースを終えて喜んでいたのも束の間、その後もたくさんの困難にぶつかりました。

　リリース後の期間についてチームメンバーの松岡君に伺ってみました！

#### Q.リリース後の時期でぶつかった困難や印象に残っている点などはありますか？

A.配属間もない時期はとにかく動くものを速く作ることを意識していたのもあり、拡張性や保守性などはあまり考えられていないコードを書いてしまっていました。

　そうすると、追加機能を実装する際に同じような処理を書いてしまったり、行数が長くなって可読性が低くなったりして開発効率が落ちてしまうんですよね、、

　また、ログが適切に出されていないことでバグの特定に時間がかかるなど運用面での負担も増していました。

　私たちはここで初めて、拡張性や保守性や可読性を十分に考慮したコード設計、実装の重要性に気づくことができました。

#### Q.そこからどのようなことを学ぶことができましたか？

A.このとき学んだことはプログラミングはただ動くものを作るのではダメで、変更に強いコード設計をしないと後に自分たちの首を絞めると言うことです。

　実際にコードに対してリファクタリングを行った結果、新機能追加が格段にしやすくなったり、解析の際に処理を追いやすくなったりなど、明らかに開発効率が上がったの実感することができました！







３人とも回答ありがとうございました。

# 成長できたと感じる点

　次は配属後にぶつかった困難、辛かった点を受けて総合的に成長できた点や開発時に印象的だった取り組みについて、門田さんに聞いてみたいと思います！

#### Q. 配属後様々な困難にぶつかってきましたが、そんな中で成長できたと感じる点は？

A. やはり技術力ですね。リンク決済の開発過程で、TypeScript、Golangなどのプログラミング言語や、GCP、Kubernetesなどインフラ技術にも携わりました。

　コード開発の観点では、初めはとにかく動くことを意識して開発していましたが、次第にどうすれば読みやすくまとまりのあるコードを書けるようになるか、どうすれば性能を担保できるかなども考慮できるようになりました。

![image2022-12-23_14-13-34.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3289228/242a35d0-56c1-dc2f-ca9d-7e6e0573fb06.png)
<sup>開発中に使用した技術</sup>

#### Q. 開発中に印象的だった取り組みは？
![1956A077-4F80-4B17-A788-8F08C40F563D.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3289228/1eb9dc21-241b-a809-9d0c-e8e3f8c9f3b8.jpeg)

三つほどあります。　

一つ目は、結合テストの自動化を実施したことです。元々はテストシナリオを考え、それを手動で実施していたのですが、機能修正の際のデグレ確認などの際に1から全て実施することに、膨大な手間がかかっていました。

　そこで、Playwrightやcypressを使用してそれらのシナリオの自動化を実施。今後の運用コストを防ぐために、仕様変更が発生した場合でも対応しやすいようなコードの書き方を心がけました。

　網羅性を考慮したテストシナリオの検討など困難なこともありましたが、その分システム全体の仕様の把握ができたり、TypeScriptの知識が増えたりなど成長も実感しました。


　二つ目は、アプリケーションのログをチャットに連携したことです。この取り組みでPrometheusやcloud logging, pagerduty, terraformなど、知識のないサービスの仕組みを理解し1から開発するのがとても大変だったことを覚えています。ただ、この機能は作成したアプリケーションの運用保守において必須の機能なので、責任感を強く持ち取り組みました。困難な取り組みではありましたが、おかげでログの重要性や監視処理の理解が深まリました。


　三つ目は、バッチを運用しやすい設計に変えたことです。リンク決済では、リンクの支払期限が切れた際のお知らせなどでバッチ機能を使用していたのですが、当初開発した時は冪等性の担保すらできていませんでした。
<sub>(※冪等性の担保とは: ある同じ操作を何度行っても、いつも同じ結果が得られる性質)</sub>

　また、もしインフラ基盤などに障害が発生したら手動で再実行しなければならなかったのです。

　そのため、それらを改善すべく、正常時に動くバッチと障害発生時に動くバッチをコマンドライン引数で管理し、正常時のバッチが失敗した時に自動で障害発生時のバッチを動かすように変更しました。

　そこではargo workflowの機能を使ったのですが、helmでのargo workflow設計は参考資料が少なく、実際のオープンソースを見ながら設計したのも開発未経験の私にとっては印象的でした。





![kennsyuuyougazou.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3289228/a1317111-486d-ebb7-c381-95f974c8f7fa.png)
<sup>normalモードが失敗した時だけonFailureが動くように改善</sup>



#### Q. 業務外でスキルアップのために取り組んだことは？

　各々が本を読んだり資格取得に勤しんだことです。AWSなど一部資格は業務内ではあまり使用していませんが、資格勉強を通じてITエンジニアとして必要最低限知っているべき知識を体型的にに学ぶことができました。

　また競技プログラミングの能力を測るPaizaやAtcoderなどにも積極的に取り組み、アルゴリズム力や論理的思考力を鍛えたりしています。会社の取り組みでUdemyの講座が受けられるので、業務に関係なくとも自分の気になる技術を積極的に学んでいるメンバーもいます。

　参考として以下にチームメンバの資格取得率を示しておきます。
![image2022-12-23_14-15-41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3289228/a6363f6f-af6c-3fe3-9705-fd4b1c35f4ca.png)







# 終わりに




　最後まで読んでいただきありがとうございます！

　このようにIT未経験の新人がすぐに商用プロジェクトの開発に配属されることに驚かれた方も多いのではないでしょうか。

　私自身最初は不安もありましたが、一生懸命やっていれば周りの人も助けてくれる懐の深さもある環境なので、一年間を振り返ってみるととても密度の濃い経験ができたと思います。

　新人チームが1年でクラウドネイティブ人材に成長していく過程が皆さんに魅力的に伝わったのならとても嬉しいです。