はじめに

多くのブログ記事やチュートリアルは、機械学習や深層学習モデルのトレーニングに焦点を当てています。しかし、これらのモデルを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ディレクター、その他多数募集中!

“企業文化を何より大切にした組織を創り、お客さまを支援したい”という想いから誕生した「SENZOKU LAB.」にて、導入いただいている企業さまの事例記事を公開いたしました。

今回の導入事例では、株式会社ユーザベース様をご紹介しております。


リソースの不安定さに課題を抱えていた、イレギュラー要素を抱えたオペレーションが複数存在していた、とおっしゃるユーザベース様に、導入後の良かった点や決め手、“人が辞めてしまう”悩みから解放されたと言っていただいた導入後の変化などインタビューにお答えいただきました。
ぜひご覧ください。

SENZOKU LAB.


SENZOKU LAB.


「SENZOKU LAB.」は単なるリソース提供ではなく、お客さまの目指すビジョン、大切にされている価値観(フィロソフィ)を理解したカルチャーフィットする組織をお客さまと一緒に創りあげ、成長させていきます。

「SENZOKU LAB.」サービス紹介ページはこちら
オンライン相談予約を随時受付中です。


こんにちは。編集部の福田です。

突然ですが皆さん、1日に何回くらいネット検索しますか?

私は20~30回くらいでしょうか。

よく「ググる」なんて言ったりしますが、世界中で38億人のネットユーザーが存在する中で、1日に平均32億回ネット検索がされているようです。
※2012年にGoogle Zeitgeistが言及。それ以降は公表していない

少し古い情報ではありますが、1日の検索回数が30億超えには驚きですよね?

その検索行為そのものがエコに繋がるとしたらどうでしょう?

今回は、ある検索エンジンを使うことで誰でも手軽に環境保全活動へ貢献できるアプリをご紹介します!

検索エンジン『Ecosia』

Ecosiaはドイツ生まれの検索エンジン。

検索で発生した広告費用の利益を一部、植林・森林再生活動を行う非営利団体に寄付しています。

ご存じの通り、ドイツは世界の国のなかでも環境活動への意識が高い国として有名。

学校の教育方針に「自然と環境に対する責任感を身につける」という指針が追加されているほどなんですね!

例えば、

・屋上緑化⇒緑地に家を建てるなら屋上を花壇にするなどして埋め合わせをする

・市内駐車料金を高く設定⇒マイカー利用を減らすことで渋滞とCO2の削減

・「プファンド」というデジポットの制度⇒ペットボトルや缶・ビンなどの飲料を買うと、先に保証金を払うシステム(飲んだ後に容器を返せばお金は戻る)

などなど、かなり本気で取り組んでいるんです!

そんなドイツ生まれのEcosiaの仕組みはどういうものなんでしょう???

『Ecosia』の仕組み

Ecosiaで検索した結果は、Microsoftの検索エンジン『Bing』から提供されていて、Bingの検査結果プラス、Ecosiaのアルゴリズムを採用しているそう。

で、ここからが本記事のメイン部分。

Ecosiaで検索をすると、およそ0.5ユーロセント(0.005 EUR)の利益が発生。1本の植樹に必要な金額がおよそ22ユーロセント掛かるので、

22÷0.5=45

つまり、45回の検索で1本の木を植えることが出来るんです!!

検索での利益は広告費から発生するので、Ecosiaはその広告からの利益8割を植樹・植林活動に使用しているんですね。

実績として

「Ecosia」の公式Twitterでは2021年4月実績として、およそ700万本の樹木が植樹されたという財務報告を公表しています。

以下、Ecosiaのブログでは国ごとの活動実績が掲載されています。

植樹の本数、規模、植えた場所などが明記されています。非常に分かりやすい


日常的に使うために

さて、私たちが普段使っている検索エンジンをEcosiaに変えるだけで、世界中に木を植えることが可能になります。

今日から取り入れられる、日常的にEcosiaを使う方法をご紹介します。

■PCの場合

EcosiaへアクセスしてGoogleの拡張機能へ追加する方法。

普段使っている検索窓に「Ecosia」と検索。cheromeの拡張機能を使います。

自身のブラウザへ簡単に拡張できる


■スマホの場合

スマホでEcosiaを使う場合は、アプリをインストールする必要があります。もちろん無料^^

使いやすいように、スマホのドックへ追加。


「せっかく追加したんだから使ってみないとな!」

ってことで検索しまくる。

検索結果の右上ツリーのアイコンの下に、累計検索数が表示される。

たしか45回の検索で木を1本植えることになるから、あと28回ってことですね♪

つかってみての感想

環境保全活動と聞くと一見ハードルが高そうなイメージですが、検索なら一日に何回もするのでそこまで難しいことはありません。

45回の検索につき1本の植樹を行うので、私は既に1回植樹をしたことになりますね!!


さいごに

いかがでしたか?

普段行っている“検索”という行動を変えるだけで、自然と環境保全活動に協力していることになるので、カンタンに出来るエコですよね!

近年では、環境問題について日本でも関心が高まってきています。

エコバッグ、マイボトル、マイストローなど私たち個人で出来る環境保全もありますが、企業による経済活動のなかでも、CO2排出を削減し、それでも排出されるCO2の数値を知り、その分の埋め合わせをするという『カーボンオフセット』という考え方が誕生しています。

Ecosiaの植樹5,000万本によって、およそ250万トンものCO2が除去されるそうですので、これも『カーボンオフセット』の例ですよね。

日常で取り組める環境保全活動は他にもたくさんあります。

環境問題と真摯に向き合いながら、私たちの住む地球を守っていきたいですね^^

icon_福田

icon_福田

この記事を書いたひと:福田 聡樹(ふくだ さとき)

株式会社プロトソリューション Webマーケティング部所属。自社ホームページ編集長。ブログ/インタビュー/動画などのコンテンツを使って、プロトソリューションのサービスやタレント情報を発信しています。
好きなもの:爬虫類全般、本のにおい。


“企業文化を何より大切にした組織を創り、お客さまを支援したい”という想いから誕生した「SENZOKU LAB.」にて、導入いただいている企業さまの事例記事を公開いたしました。

今回の導入事例では、ヤフー株式会社様をご紹介しております。
外部のパートナーと一緒にビジネスをつくっていく形を模索していたとおっしゃるヤフー様に、導入後の良かった点や決め手などのインタビューにお答えいただきました。
ぜひご覧ください。

SENZOKU LAB.


SENZOKU LAB.


「SENZOKU LAB.」は単なるリソース提供ではなく、お客さまの目指すビジョン、大切にされている価値観(フィロソフィ)を理解したカルチャーフィットする組織をお客さまと一緒に創りあげ、成長させていきます。

「SENZOKU LAB.」サービス紹介ページはこちら
オンライン相談予約を随時受付中です。


はじめに

みなさん、はじめまして。
プロトソリューション仙台本社の進藤です。

今回は、私の仕事に対するマインド・スタンスを、当社人事の西野にインタビューしてもらいましたので、ほんの少しご紹介させていただきます。
最後までご覧いただけましたら幸いでございます。

私のプロフィール

2005年04月 – 2016年09月
株式会社アイソリューションズ入社
Webエンジニアとして、プログラマー、システムエンジニア、プロジェクトリーダー、プロジェクトマネージャーを順に経験。宮城県地場企業様から、首都圏大手企業様まで、大小多種多様な企業様のソリューション開発・ニアショア開発に従事。

2016年10月 – 現在
株式会社プロトデータセンターと合併し、株式会社プロトソリューションへ商号変更
仙台開発事業部の責任者として事業を統括、事業部戦略立案を中心に、ブランディング、リクルーティングなど、仙台本社に関わる取り組みを推進。現在は、AIテクノロジー推進室仙台を設立し、前述に加えて、システム開発(Web系)は勿論のこと、プロダクト開発(新規事業企画・SaaS製品開発)、R&D(AI研究開発・高度IT人材育成)、HRBP(人事戦略考案)、この4セクションの統括マネージャーに従事。

レビューは戦争だ!って、バッチバチしていた頃(笑

Q.今はマネージャーをされていますが、当時はどんなITエンジニアだったんですか?

特別なことはなくて普通だったと思うけど(笑)ただ、とにかくこだわってモノづくりをしていたのと、自分なりのポリシーは色々あったと思う。ITに興味がない、、、それだと語弊があるね(笑)ITに興味がないというよりは、IT以外のコトにも興味を持つようにしていたかな。そこは単純で多種多様なお客様(業界・業務)がいらっしゃるので、必然的にIT以外のコトも、お客様程とはいかないまでも知って、しがみついていかないといけないし、ITに没頭していれば、良いモノを作れる!っていうのはまかり通らないよね。だけどITは、世の中で最も夢のある、そして素晴らしい、最高の手段だとずっと思ってる。

Q.特にこだわっていたことを挙げるとしたら何ですか?

それは今も変わらなくてデータだね。お客様からオーダーをいただくシステム開発は、データをインプットして、アウトプットすること。一般的なWebサイトは、データを出し入れするためのいわばツールみたいなもの。データはお客様にとって貴重な資産で、データがあれば何かを創造できるかもしれないし、何かの方法が見つかるかもしれない、お客様の未来に繋がるはずだから、データだけは絶対に守らなきゃいけない!勝手にデータドリブンみたいな感じで必死だった(笑)だから、テーブル設計や、ER図のレビューなんかは、もう戦争(笑)これ!っていう答えがある訳じゃないから、エンジニア同士の意地と意地のぶつかり合い、バッチバチ(笑)

あとデータで言えば、後輩エンジニアにも、SQLから先に作ろう!って教えてた、逆に画面、Web、SQLの順で作ってしまうと、早く画面の動きが見たくて、SQLをおろそかにしちゃう、、、複雑になりがちで、カスタマイズ性を左右するのもSQL。それから、開発コストや、ランニングコストを下げたり、不具合解消のスピードと質を上げるのも、テーブル構造のデキが大きい。例えばデザインはお客様と密に詰めてアウトプットするけど、データはお客様が介入されない我々エンジニアが単独で完全に責任を追う唯一の領域だから、こだわりを持って当たり前。

当たり前と言えば、どこまでいっても、自分なりのポリシーの軸は「ABC(当たり前の事をバカになってちゃんとやる)」かな。デスクを綺麗にしてっ!・・・なんてこと、よく言ってるでしょ(笑)

明日もまた会社に来たい!って、心躍る、そんなチームがいい

Q.今、一番楽しい時って、どんな時ですか?

チームメンバーが何かを成し遂げてレベルアップをした時。初めて後輩が出来た頃から、自分よりも、後輩にベクトルが向いていたかな。それは、当時の先輩が仰っていた言葉がきっかけで「後輩は先輩を超えるもの、先輩の教えプラス自分があるから超えて当然」って言われたのを今でも覚えていて、それが大きな影響だね。

Q.楽しいとは反対に、不安になる時はありますか?

チームメンバーが笑っていない時は、すごく不安になる(笑)仕事でも何でも、ポジティブに楽しんで取り組んだ方がいい。その方がジブンゴトとして考えることもできるし、やり甲斐も、余裕も生まれる。なんなら失敗だって成長の糧なんだって思えるよね。当然、仕事上は、お客様がいらっしゃってローンチまでのプレッシャーもあるし、自分が成長できないストレスだってある、大変な事も多いかもしれないけど、朝起きた時、今日も頑張るぜ!って心躍る、そんなポジティブフルなチームがいい。

Q.チームメンバーに対して、普段から意識して取り組んでいることはありますか?

フロア散歩。普段、彼らから私に用事がある時って、決裁やら報告、もしくはネガティブな相談事・・・マネージャーって孤独なのよ(笑)だから、この時間って決めて散歩してる。

Q.散歩ですか?(笑)どんな会話をするんですか?

「ウィ!調子どう?」だけ(笑)特に自分が見させてもらってる部署は若手が多くて、何気ないコミュニケーションでも成長を感じられて、素直にすごいじゃん!って感心するし、同時にチームが上手く機能している安心感も得られる。特にスペシャリストの連中なんかは動きも考えも面白いよ。フロアにはポジティブなニュースがたくさん落ちてるから、それを拾い集めてる感じだね。

Q.他にも色々なコミュニケーション手段があると思いますが、なぜ散歩なんですか?

すごくシンプルで、課長、部長、役員みたいな現場からは少し離れていて、ブラックボックスな会議に参加するような人達に声を掛けられると、嬉しかったし、頑張ろう!ってモチベーションになったり、良い刺激をもらえていたから、そうしてる。

Q.印象に残っている散歩ってありますか?

・・・(笑)
当社のサービス < ラクネコ > の担当者に「ウィ!調子どう?」って言ったら「只今、リリース中です!」って即答されて「あ、ごめん」って言ったよね(笑)それから彼には「今、リリース中?」って声を掛けるようにしてるよ(笑)

Q.組織を運営している中で、大事にしていることはありますか?

組織を運営する中で意識しているのは、何よりもメンバーの成長が一番。ヒトがモノを創って、モノがコトを生むんだから。更に欲を言えば、テクノロジーとアイデアの中に自分達が居るような環境とか風土も創っていきたいね。あと、普段の振る舞い的なことでいうと3つあって、①自分という存在が常に適度なプレッシャーであること、②自分が一番のアイデアマンであること、③メンバーへの感謝を常に持ち続けること、この3つだね。

Q.組織の次世代を担うリーダー陣に、普段からメッセージングしていることはありますか?

特にない(笑)トップダウンで、あーして、こーして、っていうのは響かないから、自分らしく彼らは彼らなりのマネージメントをしていけばいいと思う。

強いて言えば「自分以外はお客様」精神かな。チームや、部署を率いるということは、カタチ上は自分が一番上に立っているようで、実は一番下。メンバーありきで自分がいて、メンバーに助けられていることを常に忘れてはいけないからね。

何にこだわり、何を夢見るか?って、本当に大事なコト

Q.夢はなんですか?

世界平和。すごくスケールの大きい話かもしれないけど、世界には困っている子供達がたくさんいるから、ちょっとでもチカラになれればいいと思っている。未来は子供達が創っていくんだから、子供達の夢が広がる各々の社会を創造する義務が現社会人にはあるよね。

世の中には数年後の将来を描き、それをカタチにして社会を変えている企業や、経営者の方々がいらっしゃって、生活を支える重要なインフラになっていたり、人々をアッと驚かせるアイデアで時代を牽引したりと、それだけで十分な社会貢献なのに、営利だけではなく、サステナブルな視点も含まれている、本当に凄いこと。このような大きな影響力を持つ企業や、経営者の方々が、世の中の10%だとしたら90%の人々は、小さなことでも何か一つ!後世に残していくことが重要だと思う。そこに、エンジニアとか、プロフェッショナルとしての社会貢献ということにこだわりはなくていい。

いつの日かくる社会人の終わりに、心の底から満足できていればいいんじゃないかな。

Q.そのための「Re:Jomonプロジェクト」ですか?

「Re:Jomonプロジェクト」は、東日本大震災から十年の節目を迎えて、地域の皆様に際して、何か貢献したいという想いで発足したプロジェクトだから、やるべきミッションは違うけど、ビジョンは同じだね。このプロジェクト通じて地域が活性化していって、東北から世界にちょっとずつでも波及できれば、もしかしたら届くかもしれないね。

このプロジェクトは、まだまだ道半ばだけど、本当にありがたい機会をもらえたと思ってる。ぼんやりとしていた夢がチャンスというカタチになって、目の前に来るとは思ってもなかったし、それほど、当社にはチャレンジしようとするマインドやカルチャーがあるってということだよね。

本当に器の広い、そして恵まれた会社で働けているって本気で思うよ。

さいごに

Q.最後にご覧いただいた方に、一言、お願いします

私達、プロトソリューションは、これからもバッチバチと成長して参りますので、もし、この記事を見て、ITへ挑戦してみたい!当社で働いてみたい!と感じていただけたら幸いでございます。

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

ITエンジニア

ITエンジニア

仙台本社では、一緒に働くITエンジニアを募集しています

自社プロダクト(SaaS)開発エンジニア、社内インフラ、その他多数募集中!

自己紹介

ソリューション開発部仙台に所属している内藤と申します。現在はグループ会社の基幹システム開発を行っております。
もともとはECシステム関連を得意としておりましたが、ECシステムにかかわらず、システム構築全般をこなしてきました。

現在の業務

自己紹介でも書きましたが、グループ会社の基幹システム構築に携わっております。もともとはその会社で行っているEC販売に関連するシステム構築のお話を頂き、そこから拡大して会社全体を担う基幹システムを構築したいとのことで、毎年少しずつ機能を追加して現在は会社のほとんどの部署をまかなうシステムの構築をすることができました。

作成したもの

システムを構築する手順としては、相手先の担当者との要件定義(どんな物を作成するかを決める)から始まり、基本設計、詳細設計、実装、単体テスト、結合テスト、システムテストと各工程を経て最終的に完成に至ります。
そのような手順を踏まえて作成された基幹システムですが、基幹システムと一言でいってもどのような物か想像しづらいのかと思いますので、少しご紹介します。
会社内の各部署によりさまざまな機能が存在します。
社内だけではなく、外部のシステムとの連携も行い、業務にかかるコスト削減を目的としています。

・販売系部署
 - 受注データの作成
  - 各種外部ECサイトへ接続し受注データの連携(楽天、Yahoo!、Amazon、他ECサイト)
  - 手動での受注データ作成
 - 仕入担当部署への発注データの作成
 - レジシステムとの連携
 - タブレットを利用しお客様に記載頂く為の入力フォーム
 - お客様のシステムとのデータ連携
・管理系部署
 - 発注データの作成
 - 仕入データの作成
 - 商品データの管理
・物流系部署
 - 配送商品の物流会社との連携
 - ハンディターミナルを利用した商品のチェック処理
・経理系部署
 - 販売、仕入にかかる入金の管理


まだまだ他にも機能があり、また今後も拡張して行く予定となっています。

ハンディターミナル

利用言語と環境

システムのベースはJava言語を利用したWebシステムとなっていますが、外部との連携、実現したい内容、プラットフォームにより、利用言語を変更しています。

プラットフォーム 利用言語
Web Java
Android Java
ハンディターミナル VisualBasic.NET


また、これらのシステムを作ったとしても動かすためのサーバーが必要となります。
サーバーを動かすということは、セキュリティやネットワークなどのインフラ関連も重要になってきますので、システム構築には様々な知識が必要となります。

インフラにかかわる知識
OS Linux、Windows
Webサーバー Apache、nginx
FTPサーバー vsftpd、IIS
データベース Oracle、PostgreSQL、MySQL
ネットワーク ネットワークセグメントの設計、LB、IPS/IDS
クラウド AWS


このように、一つのシステムを作ることで新しい知識が増える喜び、成長を実感することができ、
またお客様によろこんで頂けると言葉では言い表せないほどの感動を得ることができます。

最後に

システムを構築する上で大事なことは、お客様の要件を聞き(要件定義)、実際には何を実現したいのかを把握し、無駄をそぎ落としつつシステムに落としこんで行くこと(設計)だと思っています。
言われたままシステム化を行うと、完成後に「こういうのではなかった。。」ということが起きてしまいます。(私も若いころにそういうことも経験しました。。)
技術を追い求める事も大事ですが、システムエンジニアとしては、ヒアリング力、提案力も大事な要素となります。
これらは、一人の力で解決できるものではなく、人それぞれ長所、短所があるように得意不得意のあるメンバーが集まって、チームで解決していくことでより良いシステムの構築ができるものだと思っています。

技術が好きな方、話すのが好きな方、考えるのが好きな方、それぞれで活躍の場がありますので、
一緒にシステム構築をやってみたいと思って頂ける方がいらっしゃいましたら、是非ご応募頂きたいです。

ITエンジニア

ITエンジニア

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

AIエンジニア、システムエンジニア、その他多数募集中!

ITエンジニア

ITエンジニア

仙台本社では、一緒に働くITエンジニアを募集しています

自社プロダクト(SaaS)開発エンジニア、社内インフラ、その他多数募集中!

ITエンジニア

ITエンジニア

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

データサイエンティスト、データベースエンジニア募集中!

ページトップへ戻る