はじめに

多くのブログ記事やチュートリアルは、機械学習や深層学習モデルのトレーニングに焦点を当てています。しかし、これらのモデルをWebサイトや他のシステムから簡単に利用できるように作成し、デプロイする方法については、あまり多くの情報がありません。

この記事では、これらのモデルのWeb APIを作成するためのアプローチと、AWSへのデプロイメントについて説明します。

この記事ではTensorFlow 2に焦点を当てていますが、いくつかの変更を加えることで、コードはPyTorchLightGBMなどの他のフレームワークにも対応できます。

自己紹介

私はアダムと申します。PROTO SolutionのAIテクノロジー推進室で機械学習/深層学習のシステムやプロトタイプを開発しております。

主な仕事は、TensorFlowを使った深層学習モデルの開発と、それらを使ってAmazon Web Services (AWS)にデプロイできるAPIやバッチアプリケーションの開発です。

アプローチ

機械学習モデルをデプロイするためにいくつかAWSサービスが使えます。例えば、

これらのサービスはそれぞれ料金、複雑さ、機能が異なります。

この記事では、AWS LambdaAWS Elastic Beanstalkへのデプロイに焦点を当てます。理由は、この二つのサービスが一番使いやすいですし、私のプロトタイプやアプリケーションはこれらでデプロイすることが多いです。

今後のブログでは、他のサービスについても記事を書いていきたいと思います。

API

API(Application Programming Interface)とは、ユーザーや他のシステムが、アプリケーションの内部を知らなくても、そのアプリケーションと使用できる方法を示すものです。

Web APIは、HTTPやその他のプロトコルを使用して、アプリケーションの機能をインターネット上で提供し利用することを可能にします。

この記事では、FastAPI フレームワークを使用してWeb APIを作成し、DockerおよびAWSサービスを利用してデプロイします。

ImageNetというデータセットに学習されたTensorFlowのMobileNetV2 モデルを例として使用します。

FastAPI

FastAPI は、PythonでWeb APIを構築するためのフレームワークです。

Flaskとその他のフレームワークも非常に人気がありますが、FastAPIはこれらのフレームワークに比べて、いくつかの利点と特徴があると思います。例えば、

  • ・モダンで非常に高速処理
  • ・コードの重複を最小限にしていますので、APIのソースコードが短い
  • Pydanticによるデータのシリアル化と検証が組み込まれています。
  • ・自動的にOpen APIドキュメント(仕様書)生成

Docker

Dockerは、アプリケーションをデプロイするための決定的な方法となっています。

Dockerで、アプリケーションと、オペレーティングシステムを含むすべての依存関係を、Dockerイメージと呼ばれるものにパッケージ化できます。

これらのイメージは、Dockerエンジンをサポートするさまざまなプラットフォームで実行できます。

Dockerエンジンで実行されるイメージは、コンテナと言います。

Dockerには、コンテナとイメージを管理するためのさまざまなコマンドがありますが、この記事では、buildrunコマンドのみを使用します。

チュートリアル

このセクションでは、APIの各部分を紹介し、説明します。

依存関係のインストール

最初のステップは、Pythonの分離されたコピーである新しい仮想環境を作成することです。

この記事では、Condaを使って新しいPython 3.7の仮想環境を作成し、それに切り替えます。

conda create -n ApiDeployment python=3.7
conda activate ApiDeployment

次に、requirements.txtに記載されている依存関係を仮想環境にインストールします。

pip install -r requirements.txt

必要な依存関係のパッケージを少し見てみましょう。

Pillow==8.2.0
tensorflow==2.4.2
numpy==1.19.5
fastapi==0.65.2
pydantic==1.8.2
aiohttp==3.7.3
uvloop==0.14.0
uvicorn[standard]==0.14.0
gunicorn==20.1.0
aiofiles==0.7.0
mangum==0.12.2

パッケージのインポートとロギング

まずは始めに、APIが使用するライブラリのインポートです。

これらのライブラリの使い方については、コードを読み進めながら説明します。

import argparse
import base64
import io
import os
import logging
import sys

from tensorflow.keras.applications.mobilenet_v2 import MobileNetV2, preprocess_input, decode_predictions

from urllib.parse import urlparse

from aiohttp.client import ClientSession
from asyncio import wait_for, gather, Semaphore

from typing import Optional, List

from fastapi import FastAPI, Request
from fastapi.responses import JSONResponse

from pydantic import BaseModel, validator

import numpy as np

from PIL import Image

from mangum import Mangum

APIは環境変数を使って設定されますが、これらはコマンドラインで簡単にDockerに渡すことができます。

THREAD_COUNT = int(os.environ.get('THREAD_COUNT', 5))
"""The number of threads used to download and process image content."""

BATCH_SIZE = int(os.environ.get('BATCH_SIZE', 4))
"""The number of images to process in a batch."""

TIMEOUT = int(os.environ.get('TIMEOUT', 30))
"""The timeout to use when downloading files."""

また、メッセージをログに書き込むためのロギングオブジェクトも作ります。

logger = logging.getLogger(__name__)

データのモデル

次に、Pydantic というパッケージを使って、APIへのインターフェースを定義し、データ構造を作成します。

データ構造を作成するための詳しいチュートリアルはこちらをご覧ください。

class HealthCheck(BaseModel):
   """
  Represents an image to be predicted.
  """
   message: Optional[str] = 'OK'


class ImageInput(BaseModel):
   """
  Represents an image to be predicted.
  """
   url: Optional[str] = None
   data: Optional[str] = None


class ImageOutput(BaseModel):
   """
  Represents the result of a prediction
  """
   score: Optional[float] = 0.0
   category: Optional[str] = None
   name: Optional[str] = None

   @validator('score')
   def result_check(cls, v):
       return round(v, 4)


class PredictRequest(BaseModel):
   """
  Represents a request to process
  """
   images: List[ImageInput] = []


class PredictResponse(BaseModel):
   """
  Represents a request to process
  """
   images: List[ImageOutput] = []

PredictRequestオブジェクトは、APIに渡されるデータ、つまり処理したい画像を表しています。

PredictRequestオブジェクトは、予測結果がAPIの呼び出し元にどのように返されるかを定義します。

これらの構造を定義することで、画像のURLやBase64エンコードされた画像データを含むJSONリクエストを自動的にデシリアライズし、妥当性を検査することができます。

サンプルなリクエスト

{
 "images": [
  {
     "url": "https://localhost/test.jpg"
  }
]
}

また、各画像のImageNetカテゴリー予測値、信頼度スコアを含むJSONレスポンスをシリアライズすることもできます。例えば、

サンプルなレスポンス

{
   "images": [
      {
           "score": 0.508,
           "category": "n03770679",
           "name": "minivan"
      }
  ]
}

FastAPI アプリケーション

次のステップでは、FastAPIのアプリケーションのオブジェクトを作ります。これにより、次のステップでいくつかのアノテーションを使用できるようになります。

app = FastAPI()

例外処理

以下の例外ハンドラは、処理中にエラーが発生した場合に、呼び出し元に返されるエラーメッセージを生成するために使用されます。

class ImageNotDownloadedException(Exception):
   pass


@app.exception_handler(Exception)
async def unknown_exception_handler(request: Request, exc: Exception):
   """
  Catch-all for all other errors.
  """
   return JSONResponse(status_code=500, content={'message': 'Internal error.'})


@app.exception_handler(ImageNotDownloadedException)
async def client_exception_handler(request: Request, exc: ImageNotDownloadedException):
   """
  Called when the image could not be downloaded.
  """
   return JSONResponse(status_code=400, content={'message': 'One or more images could not be downloaded.'})

Image Classifier

このクラスには,学習されたMobileNetV2モデルが利用されています。

predictという関数を呼び出すことで、画像のリストに対するImageNetカテゴリを予測することができます。

画像は前処理され、モデルの入力に合わせてリサイズされます(224ピクセル×224ピクセル)。

class ImageClassifier:
   """
  Classifies images according to ImageNet categories.
  """
   def __init__(self):
       """
      Prepares the model used by the application for use.
      """
       self.model = MobileNetV2()
       _, height, width, channels = self.model.input_shape
       self.input_width = width
       self.input_height = height
       self.input_channels = channels

   def _prepare_images(self, images):
       """
      Prepares the images for prediction.

      :param images: The list of images to prepare for prediction in Pillow Image format.

      :return: A list of processed images.
      """
       batch = np.zeros((len(images), self.input_height, self.input_width, self.input_channels), dtype=np.float32)
       for i, image in enumerate(images):
           x = image.resize((self.input_width, self.input_height), Image.BILINEAR)
           batch[i, :] = np.array(x, dtype=np.float32)
       batch = preprocess_input(batch)
       return batch

   def predict(self, images, batch_size):
       """
      Predicts the category of each image.

      :param images: A list of images to classify.
      :param batch_size: The number of images to process at once.

      :return: A list containing the predicted category and confidence score for each image.
      """
       batch = self._prepare_images(images)
       scores = self.model.predict(batch, batch_size)
       results = decode_predictions(scores, top=1)
       return results

ロギングの設定

次に、アプリケーションのログを設定するための関数を作成します。

すべてのログのメッセージは stdout に出力されます。これにより、AWS LambdaやElastic Beanstalkは簡単にメッセージを記録できるようになります。

def configure_logging(logging_level=logging.INFO):
   """
  Configures logging for the application.
  """
   root = logging.getLogger()
   root.handlers.clear()
   stream_handler = logging.StreamHandler(stream=sys.stdout)
   formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s')
   stream_handler.setFormatter(formatter)
   root.setLevel(logging_level)
   root.addHandler(stream_handler)

モデルのロード

このステップでは,アプリケーションの起動時に、ImageClassifierオブジェクトを生成してロードします。

また、前のセクションで定義した関数を使って、アプリケーションのログを設定します。

@app.on_event('startup')
def load_model():
   """
  Loads the model prior to the first request.
  """
   configure_logging()
   logger.info('Loading model...')
   app.state.model = ImageClassifier()

ここでは、appstateImageClassifier オブジェクトを格納しますが,代わりにグローバル変数としてモデルを格納することも可能です。

画像処理

このセクションでは、URLから画像をダウンロードしたり、リクエストメッセージに格納されている Base64 画像データをデコードしたりするためのいくつかの関数を定義します。

ダウンロードするためにaiohttpというパッケージが使われています。画像のデータはPillowの形式に変換しています。

def get_url_scheme(url, default_scheme='unknown'):
   """
  Returns the scheme of the specified URL or 'unknown' if it could not be determined.
  """
   result = urlparse(url, scheme=default_scheme)
   return result.scheme


async def retrieve_content(entry, sess, sem):
   """
  Retrieves the image content for the specified entry.
  """
   raw_data = None
   if entry.data is not None:
       raw_data = base64.b64decode(entry.data)
   elif entry.url is not None:
       source_uri = entry.url
       scheme = get_url_scheme(source_uri)
       if scheme in ('http', 'https'):
           raw_data = await download(source_uri, sess, sem)
       else:
           raise ValueError('Invalid scheme: %s' % scheme)
   if raw_data is not None:
       image = Image.open(io.BytesIO(raw_data))
       image = image.convert('RGB')
       return image
   return None


async def retrieve_images(entries):
   """
  Retrieves the images for processing.

  :param entries: The entries to process.

  :return: The retrieved data.
  """
   tasks = list()
   sem = Semaphore(THREAD_COUNT)
   async with ClientSession() as sess:
       for entry in entries:
           tasks.append(
               wait_for(
                   retrieve_content(entry, sess, sem),
                   timeout=TIMEOUT,
              )
          )
       return await gather(*tasks)


async def download(url, sess, sem):
   """
  Downloads an image from the specified URL.

  :param url: The URL to download the image from.
  :param sess: The session to use to retrieve the data.
  :param sem: Used to limit concurrency.

  :return: The file's data.
  """
   async with sem, sess.get(url) as res:
       logger.info('Downloading %s' % url)
       content = await res.read()
       logger.info('Finished downloading %s' % url)
   if res.status != 200:
       raise ImageNotDownloadedException('Could not download image.')
   return content

画像の予測

最後の2つのメソッドは,上記のコードをすべて結びつけるものです。

predict_imagesは,Pillow形式の画像のリストに対してImageNetのカテゴリを予測し、その結果をImageOutputオブジェクトのリストとして返します。

process関数は、URLのリストから画像をダウンロードして処理し、レスポンスを返します。

app.postのアノテーションは、HTTP POSTによる関数を呼び出すことでき、関数のリクエストとレスポンスの構造がそれぞれPredictRequestPredictResponseによって定義されることを示しています。

def predict_images(images):
   """
  Predicts the image's category and transforms the results into the output format.

  :param images: The Pillow Images to predict.

  :return: The prediction results.
  """
   response = list()
   results = app.state.model.predict(images, BATCH_SIZE)
   for top_n in results:
       category, name, score = top_n[0]
       response.append(ImageOutput(category=category, name=name, score=score))
   return response


@app.post('/v1/predict', response_model=PredictResponse)
async def process(req: PredictRequest):
   """
  Predicts the category of the images contained in the request.

  :param req: The request object containing the image data to predict.

  :return: The prediction results.
  """
   logger.info('Processing request.')
   logger.debug(req.json())
   logger.info('Downloading images.')
   images = await retrieve_images(req.images)
   logger.info('Performing prediction.')
   results = predict_images(images)
   logger.info('Transaction complete.')
   return PredictResponse(images=results)

健全性のチェック

また、ロードバランサーがアプリケーションの健全性をチェックするためにHTTP GETによる呼び出すことができる関数も提供しています。

@app.get('/health')
def test():
   """
  Can be called by load balancers as a health check.
  """
   return HealthCheck()

Handler (Lambdaに必須)

LambdaFastAPIを使用するためには、FastAPIappオブジェクトをMangumでラップする必要があります。

handler = Mangum(app)

注:アプリケーションをローカルまたはAWS Elastic Beanstalkにデプロイする場合、このハンドラは使用されません。

APIサーバーの実行 (ローカル環境)

最後に、コマンドラインからAPIを実行できるように、組み込みのuvicornサーバーを追加します。

if __name__ == '__main__':

   import uvicorn

   parser = argparse.ArgumentParser(description='Runs the API locally.')
   parser.add_argument('--port',
                       help='The port to listen for requests on.',
                       type=int,
                       default=8080)
   args = parser.parse_args()
   configure_logging()
   uvicorn.run(app, host='0.0.0.0', port=args.port)

以下のコマンドを実行することで、APIをローカルに実行することができます。

python main.py

Lambdaのデプロイメント

LambdaへのAPIのデプロイはいくつかのメリットがあります。

  • サーバーやインフラの管理が不要です。
  • 一時的な大量のトラフィックを対応するために、APIインスタンスの数を容易に拡張できます。

しかし、いくつかデメリットと制限もあり、特に以下の点が挙げられます。

  • しばらくLambdaが呼ばれないときに、コンテナが起動時間が発生し、リクエスト処理の遅延が発生します。
  • パフォーマンスを向上させるために調整できるのは、メモリ(および比例するCPU量)のみです。
  • API GatewayからLambdaを呼び出す場合、タイムアウトは29秒に制限されます。
  • Dockerイメージの容量は10GBに制限されています。
  • 使用料金は、リクエスト数と処理時間の両方に基づいて設定されるため、長時間の処理を大量に実行する場合には割高になる可能性があります。
  • ローカルストレージを必要とするアプリケーションには適していません。Lambdaは/tmpディレクトリに512MBの追加ストレージしか提供しません。

Dockerイメージのビルド

AWSでは、Lambdaがサポートするプログラミング言語のベースイメージが多数用意されています。

この記事では、Python 3.7のベースイメージを使用します。

注:ハンドラの名前は、ソースコードで定義されているMangumハンドラの名前と一致していることが必要です

FROM public.ecr.aws/lambda/python:3.7

# Copy function code
COPY main.py ${LAMBDA_TASK_ROOT}/app.py

# Install the function's dependencies using file requirements.txt

COPY requirements.txt .
RUN pip3 install --no-cache-dir -r requirements.txt --target "${LAMBDA_TASK_ROOT}"

# Set the CMD to your handler (could also be done as a parameter override outside of the Dockerfile)
CMD [ "app.handler" ]

次に、docker buildコマンドを使ってLambdaイメージをビルドし、タグ付けします。

docker build -t imagenet-lambda -f Dockerfile.lambda .

コマンドが完了すると、以下のような出力が表示されます:

Step 5/5 : CMD [ "app.handler" ]
---> Running in 2257d01b05b0
Removing intermediate container 2257d01b05b0
---> 14755a1c4440
Successfully built 14755a1c4440
Successfully tagged imagenet-lambda:latest

イメージをLambdaで使用する前に、AWS Elastic Container Registry (ECR)にアップロードする必要もあります。

まず、AWS ECRコンソールに移動し、新しいリポジトリを作成します。

次に、先ほど作成したプライベートECRリポジトリにログインし、<Region Name><Account ID>のプレースホルダーをECRリポジトリのリージョンとAWSアカウントのアカウント番号に書き換え、以下のコマンドを実行します。

aws ecr get-login-password --region <Region Name> | docker login --username AWS --password-stdin <Account ID>.dkr.ecr.<Region Name>.amazonaws.com

注:上記のコマンドを実行するには、awscliパッケージがインストールされている必要があります。インストール方法はこちらをご覧ください。

最後に、イメージにタグを付けて、ECRにプッシュ(アップロード)します。

docker tag imagenet-lambda:latest <AccountID>.dkr.ecr.<Region>.amazonaws.com/<RepositoryName>:latest
docker push <AccountID>.dkr.ecr.<Region>.amazonaws.com/<RepositoryName>:latest

CloudFormation

Dockerイメージの作成が完了したら、APIをデプロイするLambda関数を作成します。このLambda関数を簡単に作成するために、CloudFormationテンプレートを用意しました。

テンプレートを実行するには、以下の手順を行います。

  1. 1. CloudFormationのコンソールを開きます 。
  2. 2. 利用したいリージョンを選択します。
  3. 3. Create Stack → With new resources (standard) 「スタックの作成 (新しいリソース)」を選択します。
  4. 4. テンプレートファイルのアップロードを選択します。
  5. 5. deploy/lambda.yamlのパスを入力します。(Next)「次へ」をクリックします。
  6. 6. テンプレートに必要なパラメータを入力します。
    •  Stack Name. 今から作成するスタックの名前です。例:「ImageNetTest」。
    •  ImageUri<Account ID>.dkr.ecr.<Region>.amazonaws.com/<Repository Name>:latestというフォーマットで、前のステップでアップロードしたDockerイメージのURI。
  7. 7. (Next) 「次へ」をクリックします。
  8. 8. 画面下部のチェックボックスをすべてチェックします。
  9. 9. (Create Stack)「スタック作成」をクリックします。

これでAPIがデプロイされ、すべてのAWSリソースが準備完了したら、API GatewayのURLを呼び出すことで、APIのLambdaを起動することができます。

Elastic Beanstalkのデプロイメント

APIは、Elastic Beanstalk上にもデプロイすることができ、Elastic Beanstalkの使用には以下いくつかメリットがあります。

  • ・より柔軟な設定が可能です。例えば、GPUインスタンスを含む様々なインスタンスタイプを選択できます。
  • ・しばらくAPIを呼び出さない場合、コンテナの起動時間は発生しません。
  • ・使用料金は、リクエストごとではなく、インスタンスが稼働している時間に応じて決まります。APIによってはこの方が安いかもしれません。

しかし、Elastic Beanstalkにはいくつかのデメリットもあります。

  • ・Lambdaに比べてインスタンスの起動とスケーリングが遅くなります。
  • ・インスタンスがアイドル状態でも料金が発生します。
  • ・Lambdaより設定に調整できる項目が増えますが、使い方も複雑になります。

Docker イメージのビルド

Lambdaと同様に、Dockerイメージを作成するためにDockerfileを作りますが、ファイルの内容は少し違います。

Mangumのハンドラを呼び出すのではなく、コンテナにあるuvicorngunicornサーバー上にAPIをデプロイします。

イメージの作成を楽にするために、uvicorn-gunicorn-docker templateを再利用します。

Elastic Beanstalk向けたDockerイメージを構築するために、以下のコマンドを実行します。

docker build -t imagenet-eb -f Dockerfile  .

ビルドが完了すると、以下のような出力が表示されます。

Removing intermediate container 91a51bb166d4
---> 0bb1a7031a5e
Successfully built 0bb1a7031a5e
Successfully tagged imagenet-eb:latest

イメージをElastic Beanstalkで使用する前に、AWS Elastic Container Registry (ECR)にアップロードする必要もあります。

まず、AWS ECRコンソールに移動し、新しいリポジトリを作成します。

次に、先ほど作成したプライベートECRリポジトリにログインし、<Region Name><Account ID>のプレースホルダーをECRリポジトリのリージョンとAWSアカウントのアカウント番号に書き換え、以下のコマンドを実行します。

docker tag imagenet-eb:latest <Account ID>.dkr.ecr.<Region>.amazonaws.com/<Repository Name>:latest
docker push <Account ID>.dkr.ecr.<Region>.amazonaws.com/<Repository Name>:latest

CloudFormation

Dockerイメージの作成が完了したら、APIをデプロイするElastic Beanstalkの環境を作成します。この環境を簡単に作成するために、CloudFormationテンプレートを用意しました。

テンプレートを実行するには、以下の手順を行います。

  1. 1. CloudFormationのコンソールを開きます 。
  2. 2. 利用したいリージョンを選択します。
  3. 3. Create Stack With new resources (standard) 「スタックの作成 (新しいリソース)」を選択します。
  4. 4. テンプレートファイルのアップロードを選択します。
  5. 5. deploy/elastic-beanstalk.yamlのパスを入力します。(Next)「次へ」をクリックします。
  6. 6. テンプレートに必要なパラメータを入力します。
    • Stack Name. 今から作成するスタックの名前です。例:「ImageNetTest」。
    • InstanceType。使用するインスタンスの種類です。
  7. 7. (Next) 「次へ」をクリックします。
  8. 8. 画面下部のチェックボックスをすべてチェックします。
  9. 9. (Create Stack)「スタック作成」をクリックします。

APIのデプロイメント

CloudFormationでElastic Beanstalkの環境の作成が完了したら、そこにAPIをデプロイします。

Elastic Beanstalkには、アプリケーションをデプロイするための2つの方法が用意されています。

  1. 1. Zipファイルをアップロードします。APIのファイルを含むZipファイルをアップロードします。デプロイに必要なDockerrun.aws.jsonというファイルにホストとDocker間のポートマッピングを定義している必要がありますが、DockerイメージのURIを指定する必要はありません。zipファイル内にDockerfileが存在する場合、APIコンテナはECRにアップロードする必要がなく、Elastic Beanstalkのインスタンスにビルドされます。
  2. 2. Dockerrun.aws.jsonのみをアップロードします。このファイルには、ホストとDocker間のDockerイメージのパスとポートのマッピングも記載されていますが、上と異なり、DockerイメージのURIを指定する必要があります。

今回は、アプローチ2番で進めます。

以下のようにDockerrun.aws.jsonという新しいファイルを作成します。

{
 "AWSEBDockerrunVersion": "1",
 "Image": {
   "Name": "<Account ID>.dkr.ecr.<Region>.amazonaws.com/<Repository Name>:latest"
},
 "Ports": [
  {
     "ContainerPort": "80"
  }
]
}

Image Nameの部分を、先にアップロードしたイメージのURIに書き換えます。

Elastic Beanstalkのコンソールに移動し、(Upload and deploy) 「アップロードとデプロイ」ボタンを使ってDockerrun.aws.jsonのファイルをアップロードします。

しばらく待つとデプロイは完了します。

最後に

この記事では、FastAPIによるTensorFlowモデルを活用するAPIを作成するアプローチを説明しました。

また、同じコードを使ってAPIを2つの異なるAWSサービスにデプロイしました。

機械学習のデプロイにどのAWSサービスを使用するかを選択するのは時に難しいことですが、まずAWS Lambdaを試してみることをお勧めします。他のサービスに比べて、Lambdaは使いやすくてスケーラビリティが高いです。

より高速な推論のためにGPUを必要とする場合や、その他の要件でAWS Lambdaが適さない場合は、代わりにAWS Elastic Beanstalkをお勧めします。

ソースファイル

ソースファイルを GitHub に公開しました。

・main.py – APIのソースコード
・Dockerfile – Elastic Beanstalkのデプロイに向けたDockerfile
・Dockerfile.lambda – Lambdaのデプロイに向けたDockerfile
・Dockerrun.aws.json – Elastic Beanstalkのデプロイに向けたコンテナ設定ファイル
・requirements.txt – APIの依存関係が書かれているファイル
・deploy/elastic-beanstalk.yaml – Elastic Beanstalkのデプロイに向けたCloudFormationのテンプレート
・deploy/lambda.yaml – Lambdaのデプロイに向けたCloudFormationのテンプレート

最後までお読みいただき、ありがとうございました。

AIエンジニア

AIエンジニア

沖縄本社では、一緒に働くAIエンジニアを募集しています

その他、システムエンジニア、iOS/Androidアプリエンジニア、多数募集中!

はじめに

はじめまして。プロトソリューション・オフショア開発の三亀です。
ベトナム・ハノイでIT開発チームの現地マネージャーとして奮闘しております。
今回は私のストーリーをご紹介いたします。

入社までの略歴

高校までは千葉にいました。その後、北海道大学に入学し、札幌で4年間を過ごしました。経済学部だったのですが、いわゆる「とりあえず文系で潰しがきく学部に入っとけ」精神だったので、卒業間際になって進路について迷走しました。

順当にいけば金融関係なんでしょうけど、「自分が何に向いてるかな」と考え直した結果、昔から物を作ったりするのが好きだったのと、当時盛り上がってきてたという理由でITを選びました。

実は大学3年から統計学のゼミにも入ってたので、そこでコンピューターに触れたというのも一つのきっかけだったと思います。

「手に職つけられて、将来性もある」と思って選んだつもりが、当時は周囲からの反対も多かったです。同期のメンバーは「東証一部の会社に総合職で入社」みたいなパターンが多かったので、完全に偏見だと思うのですが、なんでわざわざSE?みたいな雰囲気はありました。さらに、当時は「SEは3K」みたいな言われ方をしてたので仕方ないかと思いますが、この職業を選んだことに悔いはないですね。ちなみに、3Kとは「きつい、厳しい、帰れない」のことです。

その後、500名くらいの中規模SIerを2社ほど経験しました。この期間が10年くらいで、自分的には技術の下積み時代だと思ってます。そのうち自社プロダクトを開発している会社に憧れを抱くようになり、某インターネットメディア企業(以下A社)に転職しました。 A社には技術や開発に対する知見があるエンジニアが多かったので、日々刺激を受けながら仕事をすることができました。また、なにより、「ITをどうやってビジネスに結びつけるか」ということを、創業20年も続いているA社で見てきたことはキャリアの大きな糧になっています。

A社では主に開発チームのプレーイングマネージャーとして、約10年間、次のようなことをやっていました。「各種レガシーシステムの刷新」「マイクロサービス化」「不採算サービスの断捨離」「オフショア開発推進」

この中の「オフショア開発推進」が現在の仕事にもつながってきます。「IT需要に対して、年々エンジニア不足していく」という日本が抱える課題に対して取り組めば、仕事のチャンスも増えるだろうと考えています。

プロトソリューションに入社

プロトソリューション入社の経緯はちょっと変わってます。A社時代に出張で何度かハノイに来てたのですが、その際、プロトソリューションの現地駐在員の方々と仲良くなりました。その頃ちょうどその方が退職を考えていて、ハノイ拠点長の後任を探していたというのが経緯になります。

いろいろ会社の状況を聞いて、ビジネス面で伸びていて仕事量は豊富だし、やり方によってはオフショア開発を拡大して、事業に貢献する余地がまだまだあるなあ、と興味を持ちました。あと、最終的には、取締役がわざわざハノイにまで会いに来てくれて、その心意気にも決断を促されました。

入社してから約半年は東京支社に勤務していました。ハノイ駐在が入社の前提だったのですが、コロナ・パンデミックが始まりしばらく渡航できませんでした。でも、これによって、東京支社のメンバーと交流する時間も増えましたし、現場の課題を肌で感じることができたので、結果的に有意義な期間だったと思っています。

そして、昨年12月に2週間の隔離を経て、無事ハノイへ渡航しました。

今やっていること

僕はオフショア開発専任ですが、ベトナム側だけに目を向け改善していっても、それは部分最適にしかなりません。「仕事を出す日本側」と「仕事を受けるベトナム側」がいい感じに協調していかないと効果を最大化できないのは明白です。(最終的には「日本とベトナムは1チーム」という雰囲気を醸成したいのですが、それも段階的にやっていこうと思ってます)

・日本側

プロトソリューションに入ってまだ1年ちょっとですが、感想として「ビジネス、案件、仕事の量は多い」「現場のエンジニアが非常にまじめ」というのがまずありました。良い要素は揃ってるので、さらに開発フローなどの効率化を進めることでまだまだ伸び代があると考えています。例えば、Backlogなどのデファクトとなっているツールを最大限まで使い倒す、ということを現場に浸透させてきました。さらに、どの業務をオフショア開発に任せるべきか、というのを判断し、各拠点のメンバーと相談しながら徐々にベトナムへ移行しています。

・ベトナム側

前任者の時代にベトナムチームは35名に到達しましたが、品質問題が噴出し、一度そこから人数を減らしたという経緯があります。これを教訓に、規模の拡大に耐えられるよう、土台をしっかり作りながら進めています。具体的には、最終的な品質担保を行うPM(プロジェクト・マネージャー)、BSE(ブリッジSE)に優秀な人材を配置し、共通のガイドラインにそってプロジェクト運営を行ってもらっています。

その結果、徐々にプロジェクトのオフショア移管も進み、現在ベトナムチームも25名にまで回復しました。また、下記は一例ですが、扱ってるプロジェクトもユーザー影響の大きいものが増えてきて、やり甲斐を感じています。

「モバイル版 中古車・バイクのカタログサービス」「業販向けEC」「有名バイクメディア」

心がけていること

オフショア開発を行う上で主にこの三点を心がけています。

1.代理プロダクトオーナー

駐在というと、どうしても現地メンバーを「管理」するという発想になりがちです。以前、アジャイルとオフショア開発で発信力のあるエンジニアの方にアドバイスをもらったことがあって、「管理」ではなく「代理プロダクトマネージャー」として現地メンバーに接した方が良いと。

これは、日本にいるサービスの企画、運営を行っているプロダクトマネージャーの代わりに、現地でサービスの背景、狙い、収益構造などを説明することこそ大事という内容でした。ですので、何か改修を依頼するときでも、なぜその機能が必要なのか、必ず背景から説明するようにしています。この地道な積み重ねが、ベトナムエンジニアのコミットメントを引き出せると信じています。

2.ドキュメントが全て

多国籍チームになるに従い、コミュニケーションの齟齬は発生しがちです。文化や母国語が違うということを本当に慎重に扱わなくてはなりません。

対策としては、「ドキュメントが正」という文化を根付かせるしかないと考えています。チャットでも議事録でもGoogleDocsでもいいのですが、とにかく、書くことを面倒くさがらずに行うことが重要です。

例えば、開発ガイドラインに項目を常に足していって、開発の際に注意しないといけないことを言語化してみんなで守るようにしています。(英語、日本語、ベトナム語で記載) 日本人だけで仕事をすると、その場の空気感で物事が決まったり、暗黙知でお互いが仕事をしがちですが、それを排除していこうと考えています。

3.日越いいとこ取り

あと、「日本とベトナムの長所をミックスしていく」というのも意識しています。先日、あるリリースに立ち会ってた際、リリース中にそのやり方ではうまくいかないことが分かり、どうしようか?という話になりました。日本の感覚だと、一旦リリースを中止して、後日、代替案を検討&テストしてから再リリースしましょう、となりそうです。ところが、ベトナムのエンジニアは、その場で解決策を考えすぐ実装してしまうんですよね。ちょっと面食らいましたが、コードを見て問題なさそうだったのと、事業への影響度なども考慮した上で、その案を採用してリリースしました。この判断ができるかどうかが、日本とベトナムの間に立つ人間の役割だと感じています。結果的に、リリースを後日に回すことによる時間のロスを防げたので良かったです。

ベトナムエンジニアが持っているスピードを、日本のエンジニアが得意とする品質保証の仕組みでバックアップできれば、最強のチームが出来上がるはずです。

今後やりたいこと

今期50名体制を目指しています。さらに、2~3年後には最終的に100名体制まで拡大し、事業に貢献していきたいと考えています。当然、いたずらに規模拡大ではなく、品質やスピードを担保した上でのこの数字を追っていきます。

前述した通り、今はチームを盤石にするため、PM層に日本人を増やしていますが、最終的には、日本人を増やさなくてもベトナムのチームだけで拡大、自走できるというのが目標です。

さらに将来のことで、全然未計画ですが、アメリカなど日本以外の国からも開発案件を受けることができたら面白いんじゃないかと考えています。

最後に

今まで培ったIT技術やマネジメント経験を海外でも試してみたい、という方は是非プロトソリューションのオフショア開発推進に手を貸して頂ければ幸いです。

僕もそうでしたが、いきなりハノイ駐在は抵抗があるかもしれないので、まずは仙台、東京、沖縄のどこかに住みつつ、リモートでベトナムの開発チームと仕事をしてみよう、というのでも構いません。

最後までお読みいただき、ありがとうございました。

・現地の生活についてほぼ毎日ブログを書いてますので、良かったら覗いてみてください。

・いつもチーム運営をサポートして下さっているハイブリッドテクノロジーズ社にこの場を借りてお礼を申し上げます。

みなさん、はじめまして。
プロトソリューション東京支社の外間(ホカマ)です。

今回は、IT未経験で入社した私が東京拠点の責任者になるまでに見てきた景色をご紹介させていただければと思います。

プロトソリューションは「ヒト」が一番の強みであることが伝わるかと思いますので、
是非最後までご覧いただけましたら幸いでございます。

▶ 私のプロフィール

2010年  入社(SE)
株式会社プロトデータセンター(現・株式会社プロトソリューション)沖縄本社にIT未経験ながら
情報システム部に配属。主にクルマ情報メディア「グー」シリーズ誌面制作、社内システムSEを担当。

2013年4月 東京への転勤(プレイングマネージャー)
東京支社にて新規チーム立ち上げの為、転勤。
グーシリーズを中心とした大規模システムにおけるデータベース領域の開発を経験。
支社拡大の為、ITスキルだけでなく、チームビルディングも担う。

2016年 (マネージャー)
東京支社のIT部隊をWEB開発、クラウド、DBA(Database Administrator)を中心とした領域において
マネジメント。クライアントに近いロケーションで上流工程からシステム開発を支援。

2019年〜現在(マネージャー)
東京拠点におけるIT部隊の責任者となり、クライアントとの折衝をしつつ、WEB開発、クラウド、DBAといったプロトグループメディアを支えるチームを統括。
また最近では次期マネージャーの育成にも注力し、より強い組織づくりを目指している。

以下、私の経験も踏まえながらプロトソリューションの「ヒト」についてお話させていただきます。

▶ 入社まで

・社会人として生活基盤を整える
沖縄で社会人として生活するためには、移動手段として車が必要なので、
お金を貯めるため、故郷である沖縄を離れ工場に勤務しました。
貯めたお金で車を買ったのですが、その時利用したのが「グーネット」なので、何かご縁を感じました。

・IT業界へ転職するきっかけ
沖縄に帰ったら手に職をつけたいと漠然と考えていました。
工場内はシステムでライン管理がされていて、社内SEの社員が効率化を進めて改善していく姿に憧れて、
IT業界へ転職するきっかけとなりました。

▶ プロトデータセンター(現・プロトソリューション)入社

・入社時の状況
IT未経験ながら採用いただき、まだ創業期の雰囲気もわずかに残る状態で慌ただしい状況もありましたが、社員全員が1つの会社として成立をさせようと本気になり業務を推進している事を印象深く覚えています。

・ITエンジニア、SEとして大事な事を学ぶ
社内SEとしてキャリアをスタートさせましたがまずは改修の要件定義や設計を行うため、
システムを利用している部署へヒアリングし、開発部隊をコントロールする所からはじめました。
不慣れな事も多く、何度もヒアリングに時間を取らせてしまっていましたが
「また来てね」と声をかけてくれて、行くたびにお菓子をもらったり、
少し雑談を交えて会話してくれたりしてくれました。

不慣れな中でも、きっとシステムをより良くしてくれる一員として期待してくれていると感じ、
より一層システム開発に勤しみました。
このときの上司からは、

「システムを利用している人の生の声を聞きながら、背景を理解して
開発や改修を出来る事がエンジニアの成長にとって貴重な経験になる」

と私に教えてくれていました。
経験の浅かった私にとって最初の段階でこの事を教えていただいた事が
今でもお客様と寄り添う時のスタンスに現れていると思います。

・先輩からの教え
先輩方はいつも私の成長をベースに考えて面倒を見てくれていました。
始めは仕事の指示をいただいてそれ通りにこなす事を繰り返していましたが、
次第に指示ベースからどう考えているかといった意見を求めてくれる機会が多くなり、
頼られている気がして嬉しかったのを覚えています。

そういった経験から自然と物事を解決するために“考える”力をつけさせていただけたのだと思います。

・共に成長していく仲間として受け入れてくれる環境
大きな会社なので、中途の私が組織の中に入っていけるのかという自分の中の焦りもありましたが、
ある時「涼治」と下の名前で呼んでくれた事が、仲間として認めてくれたような感動を覚えました。

まだエンジニアとして至らない私の意見に、どんな時も時間をとって耳を傾けてくれたこともありましたし
プラベートでも仲良くなる方もいましたが、それに甘えず仕事上では良い緊張感をもった関係を築く事が出来ました。

沖縄:エンジニアとしての基礎を学ぶ

▶ 東京 新規チームの立ち上げ

・SEからDBAへジョブローテーション
IT経験が3年経ち、次のキャリアプランを考えていた頃、DB領域の事業を開始するので東京で挑戦しないかという話をいただきました。
自身を更に成長させるには良い環境だと思い挑戦してみようと転勤を決心しました。

・DBAならではの大型プロジェクト
大規模システムのDBを社外ベンダーから内製化をするというプロジェクトでしたが、
とにかくシステムの規模感が大きく、関係者も多かったのでやりとりが大変でした。
DBAチームのあるべき形のモデルになる情報が少ない中、手探りで進める事が多く
苦労もしましたが、そういった中で大手メーカーや開発ベンダーの方々と情報交換を行える
東京というロケーションには非常に助けられました。
そうして業務フローの整備を行い、安定した運用体制の構築を実現させていきました。

関わる「ヒト」「モノ」も多い中、一つの目的に向かう事の難易度を感じながら、どのように全体感が隅々に行き渡って完遂していくのかを学べたと思います。

システムも刷新され安定してきた頃、チーム体制を拡充するフェーズに入り、マネージャーの役割を
期待していただくようになりました。

・プレイングマネージャーとしてのキャリアをスタート
自身がプレイする場合と、リーダーとしてメンバーのパフォーマンスを最大限に引き出して物事を推進する違いにギャップを感じて苦戦をしました。

誰かに何かを伝える言葉、パフォーマンスを発揮してもらうための引き出しが全然無いという事に気づき、まずは自分自身がヒトとして成長していかなければならないと痛感しました。

そのうえでメンバーの考えや、成長して目指していきたいキャリアを知り、彼らが成長できる環境を提供する事に努めようと決心しました。

・2回目のDBリプレイスを経験
チームの形が出来て数年が経ち、次期DBシステムへのリプレイスを迎えました。
前回とは違い組織としてプロジェクトを推進し、成長したメンバーの力で無事に成功する事が出来ました。ここが私のエンジニアとしてのキャリアの節目となり、以後マネージャー業に振り切っていく事となります。

東京:リプレイス対策本部にて仙台、沖縄、名古屋とリモート中継

▶ 会社合併と組織の大幅な再編

・会社の合併
2016年に株式会社アイソリューションズと合併し、株式会社プロトソリューションへ商号変更するという大きなイベントを経て、社名もプロトソリューションとなり、文字通り心機一転の再スタートをして
最も良かった事はやはり多くの新しい仲間と仕事をさせていただいた事です。

培ってきた社風、文化、技術に対する向き合い方がこれまでとは違っていてるのが新鮮で、
IT経験が1社目だった私は、まるで2社目の会社を経験しているような気持ちで仕事に臨めました。
一人一人とのやりとりがまた私を成長させてくれていると感謝をしています。

・部署を立ち上げ組織を形にしていく
メンバーも増えた東京支社のIT部隊で独立した部署の立ち上げをすることができました。
そこで部署をとりまとめる責任者を拝命し、この部署を1つの形にする事を自身のミッションとしました。
これまで自身が経験したことのない領域も含めて組織をマネジメントしていくことになりました。

・トップダウンではなく、同じ目線で考え共に成長
トップダウンで指示をするとその瞬間の成果は大きいですが、
誰かが決めた中で物事を進めるという思考に留まってしまう可能性があります。
従って将来的に自律して自身の成長と会社の成長に貢献が出来る人材を増やしていく事にこだわってやっています。

ある程度、枠組みを用意する事は必要ですが、頭ごなしにしたり考えを無下にする事はせず、メンバーと
目線を合わせ、彼らがどのような考えをもって答えを出すかというやり取りを繰り返していきます。

もちろん方向のズレや失敗を招きそうな瞬間は発生しますが
そこで私のようなマネージャーがフォローやアドバイスをしていく形を意識しています。

これはまさに私が入社時に先輩や上司から教えていただいたやり方を踏襲しています。
メンバーがもっているポテンシャルももちろんあるかと思いますが
私の周りに信頼が出来る次世代を担うメンバーが揃っていると感じられるのは
それらがあるからだと自負しています。

昨今のIT・技術の進歩は目まぐるしいものとなっています。
エンジニアはそれらを新たに習得していく事になりますが
どの形になっても変わらない大事な事を、私と共に働く事で気づいてもらえたり
成長してもらえればと日々思いながら取り組んでいます。

東京:CODE BASE TOKYO

▶ 現在とこれから

エンジニアとして現場の経験を経て、今はマネージャーとして組織運営に携わっています。

入社前の自分がまさか東京に来てIT部隊の組織を作っていくとは想像していませんでしたがそういったことも含めて大きな変化や成長スピードの中で過ごすことが出来ています。

振り返ってみると私の周りにはいつも引き上げてくれている先輩や上司、私と一緒に働いてくれる後輩達がいました。自身もまだまだ発展途上であり、成長し続けたいと思います。

そういった姿を後進にも見せていきながら、より強い東京拠点を作り上げていければと考えています。

月並みな言葉に聞こえるかもしれませんが今の環境で働けている事に感謝し、感動し続けられています。特にメンバーが成長して評価をされる場面には目頭が熱くなります。

この充実した環境でメンバーと共にプロトソリューションという会社をこれからも
盛り上げていきたいと思います。

▶ 今後のキャリアプランを考えている方へ

楽しくやりがいをもって成長ができる仕事をしたいと多くの方が考えていると思います。

本気で働いている人の周りにはたくさんの人が集まり、
同じミッションを共有した仲間達は困った時に必ず助けてくれます。
信頼関係を築いた仲間達と共に成長する事が楽しくもあり、やりがいに繋がると考えています。

エンジニアとして技術を追求していきたい方、マネージャーとして管理職へ挑戦したい方、
今後のキャリアをどうしようかとお考えの方、ぜひお声がけください。

プロトソリューションで共に成長しながら働ける事を楽しみにしています。

今回、今までしたことの無い、自身のキャリアを振り返りながら執筆して、改めて自分の目指すところや
やりたいことが整理された気がします。

最後までお読みいただき、ありがとうございました。

ITエンジニア

ITエンジニア

東京支社では、一緒に働くITエンジニアを募集しています

Webディレクター、その他多数募集中!

ページトップへ戻る