2022年12月7日に開催された、アマゾン ウェブ サービス（AWS）のオンラインイベント「デジタル変革2022 モダンアプリケーション開発の新潮流 ～ビジネス成果を生み出すモダンアプリケーション開発の成功例～」にて、NCDCのCTO（Chief Technical Officer）十川 亮平が登壇しました。
この記事では、NCDCのセッションをテキスト化して公開しています（テキスト化にあたり内容は一部編集しています）。
目次
なぜモダンな開発手法や内製化が求められるのか？
このセッションは「AWSサービス徹底活用 ～成功するアプリケーション開発の内製化とは～」というタイトルですが、まず「モダンアプリケーション開発」や「内製化」がなぜ今多くの企業で求められているのか、その背景からご紹介します。
ひとつには、近年クラウドサービスや開発言語とその周辺のツール、ライブラリなどのエコシステムが発達してきたことにより、以前よりも容易にモダンな開発環境の構築や内製化にチャレンジできるようになったことが挙げられます。
もうひとつ、必要性という観点から考えると、昨今は「DXのモード2」に代表されるような新しいタイプのプロジェクトが増えていることも背景として挙げられます。
以前はQuality（品質）、Cost（コスト）、Delivery（納期）を意識しながら、あらかじめ要件がしっかり決められたシステムを作ることが重要項目でしたが、「DXのモード2」では、ITを使って新しいサービスやビジネスそのものを試行錯誤しながらつくっていくことが求められているのです。
こうした背景から、モダンな技術を上手く活用して、ユーザーニーズの探索や検証などのサイクルをどれだけ高速に、低コストで回せるようになるかが重視されているのではないかと考えています。
俊敏なサービス開発を行うための3つのポイント
システムの内製化体制をつくり、俊敏なサービス開発を行う（高速に、低コストで改善を繰り返す）ためには、3つのポイントがあると私達は考えています。
- マイクロサービスと小さなチームで俊敏な組織
- 短いリリースサイクルを実現するプロセス
- 1と2を実現するためのクラウドサービス
マイクロサービスと小さなチームで俊敏な組織
例えば大きな基幹システムには何百という画面や千個単位のデータベーステーブルが存在していて、システムの開発チームが百人規模で構成されていることもよくあると思います。
その規模のシステムとチームの場合、1週間に1回程度の短いサイクルで新機能のリリースを行うのはかなり難しいと思います。
ただし、全体としては大きなシステムであっても、適切な細かさでマイクロサービスに分離していき、サービスごとに独立したチームが開発を担当する場合は、各サービスはそれぞれ独立して修正やリリースを行えるようになります（お互いにAPIを呼び出すなどのデータの連携はもちろん必要になりますが）。
つまりサービス単位でライフサイクルが独立しており、短いサイクルでの新機能リリースも実現可能ということです。
俊敏なサービス開発内製化のためには「マイクロサービスと、各サービスを担当する小さなチーム」。このようなアーキテクチャと組織を保っておくことが重要なポイントになると思います。
製造業でのシステム内製化事例
次に、製造業のお客様がシステム内製化チームを立ち上げた事例（こちらの記事で紹介している本田技研工業様のケース）を交えて、具体的な体制の整え方などを説明します。
本田技研工業様は従来からあるIT部門とは別の組織として、具体的には製造部門の下に位置するところに、工場で使う業務用のアプリケーションなどを開発するチームをつくられていました。
このチームはプロダクトオーナーとフロントエンドエンジニア、バックエンドエンジニア、デザイナーなど8人程度のメンバーで構成されていて、1チームで独立してシステム開発を進められる体制をとっています。最終的にはそのようなチームが複数つくられていました。
この内製化のチームはゼロからつくられていったのですが、エンジニアとしてチームに加わった社員がみなさん十分な経験を持つ方々だったわけではありません。たとえば「Pythonを使って生産工程のデータを分析する仕事に就いていて、Webのアプリケーションやモバイルアプリケーションは未経験」という状態でスタートされたケースが多いようです。
NCDCはこの内製化プロジェクトに複数年にわたり、さまざまなかたちで関わらせていただきましたが「モダンアプリケーション開発」や「内製化」という観点に絞ると、主に次のような方法で技術移管をしていく役割を担いました。
- Webアプリケーションを作るのに必要なReact（JavaScriptフレームワーク）での開発を支援
- AWSなどのクラウドサービスを上手く使って開発するための勉強会の実施
- 内製化チームの方が書いたコードをNCDCのコンサルタントがコードレビューをして改善案を提示
開発チームの技術的なキャッチアップ
内製化にあたり、前述したような「アプリ開発の十分な経験を持たない候補者」が技術的なキャッチアップをするためのポイントは次の通りです。
実際のサービス開発で用いる言語でなくてもいいのですが、何かしらのプログラミング言語を用いてシステム開発をした経験のあるエンジニアが何人かは必要ではないかと思います。
もし社内にその経験者がいらっしゃらない場合は、一部は外部のエンジニアを入れるような体制でも問題ないです（ただし、外部の方から徐々に社員の方にスキル移管していければより良いといえます）。
外部の方がチームに参画する場合は、その方に丸投げせずプロダクトオーナーが密にコミュニケーションを取って、開発する機能をどういった場面で誰が使うのかや、なぜその機能が必要なのかといった考えを共有しながら開発に取り組む必要があると思います。
また、モバイルアプリの開発経験やAWSの使用経験がないエンジニアなら社内にいるというケースは多いと思いますが、例えばJavaや.NETを使って基幹システムなどの開発や保守を担当されている方なら、サーバーレスやコンテナに対応したモダンなアプリケーションを開発することもやりやすいはずです。
プログラミング言語を一から覚えるよりも、そういった経験のある方がAWSの技術をキャッチアップしていくのは比較的容易だからです。
自己学習と外部からのインプットをバランスよく
先述したとおり、システムを内製化しやすくなった背景のひとつに、AWSのサービスを利用してアプリケーションを担当するエンジニアが環境構築なども手軽に行えるようになったことが挙げられます。
以前のようにハードウェアに詳しい方やネットワーク機器に詳しい方など、高い専門性を持った人が複数名関わらなくても、アプリケーションのエンジニアだけでAWSを学習しながらサービス開発が進められるようになっているのです。
ただ、自分達で何もかも一から学習しながらつくるのは効率的ではない場合もあります。
- たくさんあるAWSサービスの中から何をどういう風に組み合わせて実現するのか
- サーバーレスやコンテナを使ったアプリケーションを設計する際に何に気をつけないといけないのか
- 個人情報を扱うようなシステムにおいて適切なセキュリティを担保する設定の仕方
こうした経験に基づくノウハウが必要な部分に関しては、外部の協力を得て知見をインプットする（技術移管してもらう）ことでより効率よく学習できると思います。
とくに商用利用するようなシステムの開発を内製化していく場合、外部の専門家に加わってもらいながら学んでいく方が安心感をもって進められるのではないかと思います。
短いリリースサイクルを実現するプロセス
次にアジャイルと、DevOpsやCI/CDと呼ばれる自動化について説明します。
従来の開発プロセスでは、複数の機能を並行して開発し、それらを何ヶ月分か貯めてからまとめてリリースすることが一般的だと思います。
一方で、アジャイルとDevOpsが実現した開発プロセスの場合は、一機能を開発したらすぐリリースする、次の機能も開発したらすぐにリリースするというように、短期間でのリリースを繰り返し行えるようになります。
詳しくはまた後ほど説明しますが、このプロセスで重要なのは開発と運用の受け渡しを自動化・軽量化することです。それによりこのサイクルを何回行っても負荷にならない仕組みを実現します。
そのために重要なのはCI/CD、IaC、マイクロサービスの3つです。
CI/CD（継続的インテグレーション／継続的デリバリ）
従来は手順書ベースで、手動の作業でリリースを行っていたケースが多いと思いますが、これをAWSのAWS CodePipeline やAWS CodeBuild 、AWS Amplifyなどを使ってビルド、テスト、デプロイなどを自動化します。
IaC（Infrastructure as Code）
従来は手動で環境構築を行っていたため専門知識を持つ人が必要でしたが、人に依存しないようAWS CloudFormationを使ってインフラ構築の自動化を行います。
AWS CloudFormationは構築するための定義を定義ファイル、つまりコードとして記載するので、ソースコードと同じようなバージョン管理が可能になります。変更時の差分管理や、ある時点の状態に戻すという作業が簡単にできるようになります。
マイクロサービス
マイクロサービスは先にご説明したのでここでの詳細説明は省きますが、小さなサービスを小さなチームで管理していることが重要です。例えば何かの変更を加える際の影響範囲調査などが短期間で終わる構成になっているのが望ましいです。
CI/CDについては次項でもう少し詳しく説明します。
CI/CDはDevOps実現のための自動化の仕組み
CI/CD（継続的インテグレーション／継続的デリバリ）はDevOpsを実現するためにビルド、テスト、デプロイ、リリースを自動的に行う仕組みです。
よくある既存のデプロイプロセスでは、開発者がソースコードを書いて（おそらくスクリプト化はされているケースが多いと思いますが）、手動でビルドを行い、次にテストを行います。
一通りテストが終了したら運用の担当者にリリースするモジュールと作業手順書を渡して、リリースの担当者が夜中などに一旦サービスを止めてリリース作業を行うのではないかと思います。
このプロセスは各担当者の負担が多く、かなり大変です。
たくさんの機能をまとめてリリースするので確認作業も大変ですし、手動で行うため何回も繰り返すのは非効率的で、数ヶ月に一回程度しか実施できないことが多いと思います。
一方でCI/CDが構築できて自動化されると、そのプロセスは開発者がソースコードを書いて、そのコードをリリース用のブランチにマージするだけというシンプルなものになります。
マージ依頼が出たことをきっかけにビルド、テストが自動で行われて、問題なければ自動でリリースまで行えるようになるのです。
自動化の仕組みが構築できてしまえばリリース作業の負荷がそれほどかからないので、例えばあるボタンの色を変えるだけのような軽微な変更でもすぐに公開できるようになります。リリースの頻度が高まれば、確認作業もそのときに変更した箇所だけで済むので、複数の機能をまとめてリリースするよりも効率的に進められるようになります。
CIにおけるテスト
私たちはテストの自動化がとても重要だと考えています。
テストがあることで頻繁にリリースを行ったとしても安心感があり、リリースすることに自信が持てますし、事前にテストを自動化しておけばテストを何度でも低コストで実行できるようになるからです。
とはいえ、すべての機能テストをテストコードとして書くのは時間やコストの観点で難易度が高いので、難易度が低いものから順に、サービスの特性やテスト自動化にかかる手間など考慮しつつ導入の検討をする必要があります。
テストの種類（導入の難易度が低い順）
- 静的解析
- ロジックのテスト
- UIテスト
一番簡単なのは「静的解析」で、これはプログラムを実行せずに事前に定義したコーディングルールに違反した箇所や潜在的なバグ、脆弱性の問題などを検出してくれるツールです。
静的解析に違反するものがあればそこでテストが止まってリリースはされません。
「ロジックのテスト」には従来でいう単体テストに該当するものも、結合テストに該当するものもあります。テストコードを実行してみて、期待する結果になることを確認します。
これはテスト用のコードを書く必要があるので静的解析より少し手間がかかります。
UIテストは実際に操作して、画面が正常に動いているか、体裁崩れがないかを確認したり、入力フォームにデータを入れてボタンを押したらどんな結果が返されるのかを確認したりするテストです。
UIテストを自動化するための専用ツールもありますが、いろいろな設定をする必要があるため他のテストより導入の難易度は高いといえます。また、UIが変わるとそのテスト自体も設定し直さないとならないケースもあるので、テストのメンテナンスという面でも手間がかかります。
どのくらいの頻度でテストを実行したいのか、その機能に問題があった場合にどのくらいの影響があるのかなどを考慮して、どこまでテストを自動化するのかを検討すると良いと思います。
ソースコード管理とCI/CDの関係
次にソースコード管理とCI/CDの関係について説明します。
下図はNCDCで行なっているサービス開発での例を記載しています。
NCDCでは検証環境と本番環境という二つの環境を使って開発運用しており、検証環境に対応するのがdevelopブランチ、本番環境に対応するのがreleaseブランチというかたちで使い分けています。
普段はdevelopブランチを使いますが、何か機能追加を行う場合には次の手順で進めます。
- featureブランチをつくり、featureブランチで開発
- 開発が終わったらfeatureブランチで単体テストとソースコードレビューを実施
- developブランチに対してマージ依頼を出す
- 自動テストで問題が出なければdevelopブランチに追加機能がマージされる
- マージされた時点で検証環境にリリースされる
検証環境はエンジニア以外の人、例えばプロダクトオーナーなどもその環境で動作確認できるようにしています。
このようにして一週間のうちにいくつかの開発を行い、週の最後にスプリントレビューというかたちでプロダクトオーナーも含めてその一週間分の（1スプリント分の）確認を行います。
スプリントレビューで問題がなければ、公開に向けてreleaseブランチにマージしますが、その時にも自動でテストや静的なコード解析などは行われて、問題が見つかればマージされずに止まります。テストをクリアした場合はreleaseブランチにその一週間分の変更がすべてマージされ、自動的に本番環境にデプロイされます。
NCDCでは主にこのようなかたちでソースコード管理を行なっていますが、対象のサービスやチームの方針に沿って、扱う環境の数やreleaseブランチの数などは調整可能です。
例えばdevelopブランチとstagingブランチとproductionブランチのような感じで3つのブランチを使う方法も考えられます。
モダナイズに欠かせないクラウドサービス
冒頭で挙げた3つのポイントのうち「マイクロサービスと小さなチームで俊敏な組織」「短いリリースサイクルを実現するプロセス」は紹介してきました。
最後に「これらを実現するためのクラウドサービス」の説明として、AWSのサービスを活用してモダンな開発環境を構築したライフネット生命保険様の事例をご紹介します。
システム改善に取り組まれた保険会社様の事例
ライフネット生命保険様では顧客接点となるフロントエンド（お客様が保険の申し込みや見積りをするWEB）の基板を近年刷新されました。
従来のシステムは開発後10年以上経って開発効率が落ちてしまっていたのですが、保険を申し込まれるお客様によりよい体験を提供するためには迅速な改善（開発・リリース）を可能にすべきという考えのもと、フロントエンドを基板から見直すプロジェクトに取り組まれたのです。
旧システムから、マイクロサービス化しサーバーレスで実装するモダンな構成へと刷新して、アジャイル開発を取り入れた結果、従来の開発プロセスでは数ヶ月に一度程度だったリリース頻度を2週間に1度へと大幅に短縮できるようになりました。
下図はそのAWSの構成を示すものです。
全体はAWS Lambdaを使ってマイクロサービスを実装し、AWSの各種サービスを使ってDevOpsを実現しています。
ソースコード管理にはAWS Codecommitを使っていて、開発者がAWS CodecommitのあるブランチにソースコードをプッシュするとAWS CodePipelineが動きます。
AWS CodePipeline がCI/CDのプロセスを司り、AWS CodeBuildなどを呼び出しながらテストコードの実行や静的コード解析、リリースなどを自動化しています。
フロントエンドはSPA（JavaScript）で開発されており、フロントのアプリケーションがAmazon S3にデプロイされて、AWS CodeBuildからAWS LambdaテストやAPIゲートウェイに新しいバックエンドのサービスがリリースされます。
これらの構成で2週間に1回という短期のリリースサイクルを実現されています。
サーバーレスの構成については、もともと対象となるサービスが持っていたモデルやアプリケーションのロジックなどを検討して、データベースにNoSQLであるAmazon DynamoDBを採用しています。またAmazon ECS（コンテナ）とAWS Lambda（サーバーレス）の両者を検討した上で、より運用が楽なAWS Lambdaを採用しています。
サーバーレス化により、テレビCMの影響などでトランザクションのピークが発生してもオートスケールで対応できるので、ピークに備えてあらかじめサーバーを用意しておく必要がなくなります。その結果かなり保守の負担が減ったと伺っています。
環境構築はすべてAWS CloudFormationで定義しています。
環境構築を自動化したことで人的コストの削減やミスの軽減も実現できたそうです。
システムアーキテクチャの刷新とアジャイルの導入で、ビジネス要求への迅速な対応を実現（NCDCのWEBサイト上の事例紹介記事）
AWS 導入事例：ライフネット生命保険株式会社（AWSのWEBサイト上の事例紹介記事）
アーキテクチャの検討から環境構築まで支援
最後に、このプロジェクトでNCDCが担った役割をご紹介します。
ライフネット生命保険様にはフロントエンド基板見直しの計画段階からご相談いただいたので、まずは目的を実現するための全体的なアーキテクチャを検討するフェーズからご支援に入り、アプリケーションやAWSも含めたアーキテクチャのご提案をさせていただきました。
その後も長期的にコンサルティング契約をさせていただき、アプリケーション担当・インフラ担当の両チームの皆さんに向けたDevOps勉強会の実施や、AWSの設計とAWS CloudFormationを使った環境構築の自動化、CI/CD環境の構築なども担当しています。
NCDCはAWSを活用するさまざまなプロジェクトの経験がありますし、自社サービスの開発でAWSをはじめ新しい技術をどんどん取り入れているので、そこで得たノウハウをもとに実践的な技術支援ができるのが特徴です。
また、開発工程をすべて受託するというやり方にこだわっていないので、お客様の内製化チームを立ち上げる支援や、DevOpsを推進するためのCI/CD導入支援だけを行うようなプロジェクトでも対応可能です。
NCDCの内製化支援、アーキテクチャ策定支援
下図は、NCDCが内製化の支援やアーキテクチャ策定支援に参画させていただく場合の、進め方の一つの例です。
まず「ToBe定義」を行います。
例えばAWSにシステムを移行するプロジェクトの場合、一口に「AWSへの移行」といっても、それにより何を実現したいのか目的はさまざまです。一つの企業の中でもいろいろな考えがあり、目的が明確ではないケースが多いです。
そのような段階から支援に入る場合、このプロジェクトでは何が実現できればいいのかというToBe像を、一緒にワークショップなどを行って検討し、定義させていただきます。
図ではToBe定義の次に「非機能要件検討」とありますが、ここではToBeの姿を実現するために、どんな非機能要件があるのか、例えばサービスを止めずにリリースできる必要があるのかどうか、どの程度のスケーラビリティを求めるのかといったことを検討いたします。
「リファレンスアーキテクチャ策定」では、ToBeの姿を実現するために数多くのAWSのサービスの中からどれを、どの部分に採用するのかという組み合わせをモデルのようなかたちで定義します。
例えば「このAPIの実装はAmazon ECSでもAmazon EC2でもAWS Lambdaでもできる」という場合に、どのサービスが適しているのかを比較して、選んだ理由とともにそのアーキテクチャとして定義します。
リファレンスアーキテクチャが実績のある構成なら問題はないのですが、あまり実績がない構成になるケースもあるので、その場合はリファレンスアーキテクチャに沿ってNCDC側でサンプル実装をつくってみてご提供することもあります。
これらと一部並行して、図にある通り「DevOpsの実現に向けた開発ルールやCI/CDプロセスの構築」なども行います。
また、NCDCにはUX/UIデザイナーもいるので、必要に応じてデザインガイドラインやデザインシステムをつくってUIデザインのご支援も行います。お客様側でアプリケーション開発する場合に経験不足などの不安があればサンプルを作ってご提供したり、コードレビューを行なったりするご支援も可能です。
支援の形は一定ではなく、ニーズに応じてさまざまなサポートをしています。
もちろんお客様側でアプリケーション開発が難しい場合、開発をNCDCで担当させていただくことも可能です。
大体の目安としては、この図の「ToBe定義」から「リファレンスアーキテクチャ策定」を2〜3ヶ月程度で行います。費用に関しては参考価格程度の情報に過ぎませんが、500万円くらいになることが多いです。
期間や費用はプロジェクトによって変わるので、ご興味をお持ちいただけた方はまず一度ご相談ください。
