ホーム ブログ ページ 13

Ruby on RailsエンジニアがGraphQLを使うと簡単に最強のWebAPIを作れる話。(デモもあるよ!)

0

API、好きですか?!

データイノベーション部 AI-labo所属の吉岡です。
私は今入社3年目で、入社当初からRuby on Railsを使っていました。
入社2年目から配属してるプロジェクトでは、Rails + GraphQLでバックエンド開発をしております。
過去に自分は趣味で色んなWebAPIを触ってきましたが、GraphQLはすごく画期的です。
Railsに慣れたエンジニアがWebAPIを開発しようと思ったとき、GraphQLを使うとこういう利点があるよ!というのを伝えたいと思います。

こういう人に読んでもらいたい!

主に以下に当てはまる人は、より楽しめる記事になっているかと思います!

  • Ruby on Railsのフロント・バックエンドの開発をした経験があり、controllerやmodelの概念がある程度わかっている人
  • Web APIやREST APIについてある程度どんなものかわかっている人
  • バックエンドをAPIにして、フロントエンドをReactやVueなどを使ってスマホアプリを作ってみたい人

GraphQLについて

GraphQLとは、Facebook社が開発したAPI向けのクエリ言語です。
……といっても私自身が言葉的にそんなに深く理解しているわけではないので、実際何ができるかを中心に説明して行きたいと思います。

例えばこういうことができる

以下のようなカラム構成のテーブルがあると想定します。
users テーブル

  • id
  • name
  • created_at
  • updated_at

articles テーブル

  • id
  • user_id
  • body
  • created_at
  • updated_at

comments テーブル

  • id
  • article_id
  • user_id
  • text
  • created_at
  • updated_at

もし、あるページであるuserのname、そのユーザに紐づいたarticlesのbodyとcreated_at、さらにそのarcitlesに紐づいたcommentsのtextを取るページがあったとき、どのようにAPIを実装・取得しますか?

この条件で取得できるようなAPIを、例えばRESTで実装するとき、いくつか懸念点が出てくると思います。

  • users、articles、commentsを取る時にそれぞれリクエストを投げるか?
  • 1回のリクエストをするとして、そのためのエンドポイントを新たに作らなければいけないのか?
  • articlesやcommentsの全カラムを取得するAPIはあるが、使わないカラムのデータも受け取らなければいけないのか?
  • もしこのページで他のデータが必要になったときに、どう対応するか?

Railsでフロント込みの開発に慣れていると「N+1にならないようにしなきゃ……」くらいの懸念点になるかと思います。
しかしフロントエンドを別物として開発する場合、フロント側にはmodelという概念はないため、APIにする場合は上記のようなことも重要になってきます。

そんなとき、GraphQLは以下のようなqueryを書けば1発で解決できちゃうんです。

query {
  user(id: 1){
    articles{
      body
      createdAt
      comments{
        text
      }
    }
  }
}

「えっそんな簡単にできるの?」「実際どう投げるのか教えてもらわないとよくわかんない」「queryって何?」っていう人の為に、もう少し詳細に説明したいと思います!

どう使うの?

APIを使う上で最初に知りたいのってやはりエンドポイントですよね。
GraphQLのエンドポイントは、以下のようになります。

〇〇.com/graphql

「え?これだけ?これで情報どうやって取るの?」って思うかもしれません。
実は、やってる内容的にはGETなのですが、GraphQLの場合は全部POST形式で投げています。
1つのエンドポイントは固定で、リクエストbodyに上記のqueryを入れてPOSTで投げます。
リクエストに含まれるqueryをrails側で解釈し、queryに指定されている内容をレスポンスするという形です。

メリット

ここまで軽くGraphQLについて説明してきましたが、上のことを踏まえると以下のようなメリットが見えてきます。

  • エンドポイントが1つで済む。
  • 欲しい情報だけを取得することができる。
  • テーブル構成が複雑な場合でも1回のリクエストで様々な情報を取りきることができる。

中でもエンドポイントが1つで済むのは一番の利点だと思っていて、バックエンド側から返す情報が変更もしくは新しく増えたときでも、フロントエンドではGraphQLのqueryの記述を変更すれば良いだけになります。

ローカル環境・本番環境での確認に役立つツールがあって便利!

GraphQLには、ローカル環境での確認に便利な GraphiQL という機能があります。
これはローカルでサーバを立ち上げ、 localhost:3000/graphiql/ にアクセスすると、queryを試せるという機能になっています。(urlは初期設定で、変更もできます。)

また、chromeの拡張機能に Altair GraphQL Client というものがあります。
こちらはGraphiQLと同じ機能を本番環境等で実際に試すことができます。
また、Altairではリクエストヘッダの設定もできますので、ヘッダの情報が必要な場合にも対応できます!

RailsでGraphQLを動かしてみる!!

GraphQLが便利なことはわかった……けど、実装が難しかったら使いたくないですよね。
Railsに触れてたユーザがGraphQLを使用するのに必要なことは以下の4つです。

  • gemが追加できること
  • controllerを作成して、ルーティングできること
  • modelが作れること
  • hashが書けること

はい、これだけでできます。
Rails チュートリアルで学習する内容さえあれば完ペキにAPIを作ることができます。

1. まずは環境構築する

どのような形でも良いので、まずはRailsのアプリケーションを立ち上げます。
gemさえ入れれば既存のRailsプロジェクトでも動きますので、とりあえず立ち上げについては省略します。
rails s が動作する状態にしてから以下の手順を実行してみてください。

Railsのアプリケーションのディレクトリに入り、Gemfileに以下を追加します。

gem 'graphql'          # <- 追加
group :development do
  gem 'graphiql-rails'  # <- developmentのgroup内に追加
end

インストールを実行します。

bundle install
bundle exec rails g graphql:install

そうすると以下が追加されているかと思います

app/graphql
├── {アプリケーション名}_schema.rb
├── mutations
└── types
    ├── mutation_type.rb
    └── query_type.rb

また、config/rountes.rb に以下のような記述が追加されているかと思います

  if Rails.env.development?
    mount GraphiQL::Rails::Engine, at: "/graphiql", graphql_path: "/graphql"
  end
  post "/graphql", to: "graphql#execute"

これでGraphQLを使う準備が出来ました!
試しにrails sを立ち上げ、 http://localhost:3000/graphiql を立ち上げると先ほどのGraphiQLの画面が出てくるかと思いますので、以下のqueryを記述して実行してみてください。

{
  testField
}

以下のようなレスポンスが返ってきたら成功です!

{
  "data": {
    "testField": "Hello World!"
  }
}

エラー注意!

rails・graphqlのバージョンによっては app/assets/config/manifest.js を以下のように修正する必要があります。
もし Sprockets::Rails::Helper::AssetNotPrecompiled in GraphiQL::Rails::Editors#show のようなエラーが出たら修正してみてください。

//= link graphiql/rails/application.css
//= link graphiql/rails/application.js

2. queryの構造についての説明

早速queryを書いていきますが、先にqueryについての説明をします。
queryは基本以下の構造になります。

query queryの名前 {
  fieldName1
  fieldName2(arg: argument)
  fieldName3 {
    fieldName3-1
    fieldName3-2
  }
}
  • query: queryかmutationを指定します。
  • query: 情報を取得するためのもの
  • mutation: 情報を更新するためのもの(本稿では説明しません)
  • queryの名前: queryを書く人(フロント開発者など)が分かりやすくするためにつけるもの
  • fieldName: 何の情報を取るかを指定する(階層構造にできる)
  • arg: 引数指定ができます。

注意!

以下でrailsから定義していきますが、rubyファイルでの定義はスネークケース、queryの記述ではローワーキャメルケース(先頭だけ小文字のキャメルケース)で書きます!
ごっちゃにならないように注意してください!

筆者もよくqueryをスネークケースで書いてエラーに苦しんだりしてます。
エラーが出たら、まずは書き方を疑ってみてください。

3. とりあえず何かを返すqueryを作る

とりあえずGraphQLを導入したので、まずは簡単なqueryを作成してみたいと思います。
以下のような情報を返したいとします。

query todayInfo {
  currentDate       # 今日の日付
  todayWeather {    # 今日の天気
    weather            # 天気
    temperature        # 温度
  }
}

先ほど作成された app/graphql/types/query_type.rb に以下の行を追加します。

module Types
  class QueryType < Types::BaseObject
    ### (省略) ###

    ##### ここから追加
    field :current_date, String, null: false, description: '今日の日付'
    def current_date
      Date.today.strftime("%Y年 %m月 %d日")
    end

    field :today_weather, WeatherType, null: false, description: '今日の天気'
    def today_weather
      { weather: '晴れ', temperature: 60 }
    end
    ##### ここまで追加
  end
end

そして、 app/graphql/types/weather_type.rb を作成し、以下のコードを書いてください(丸コピで大丈夫です!)

module Types
  class WeatherType < Types::BaseObject
    field :weather, String, null: false, description: '天気'
    def weather
      object[:weather]
    end

    field :temperature, Int, null: false, description: '温度'
    def temperature
      object[:temperature]
    end
  end
end

上記のコードの解説です!
まず以下の1行でfieldの定義をします。

field :query名, 型, null: nullを許可するか, description: 'クエリの説明'

そして、query名と同じ名前で定義されたメソッドを リゾルバ(resolver) といい、このメソッド内の内容を実際にqueryで返します。

def query名
  返す値を記述
end

つまり、current_dateは以下のように解釈されます

  • field名はcurrent_date(GraphQL上では currentDate )
  • String型
  • nullは許可していない
  • 返ってくる値は Date.today.strftime("%Y年 %m月 %d日") になる

続いて、todayWeatherの解説です。
最初の方でも述べましたが、GraphQLは階層構造で返すことができます。
これを実現するためには、fieldの中にfieldがあって……という構造にする必要があります。
先ほど、型はStringで指定していましたが、自分で作った型を指定することもできます。
以下の1行ではWeatherTypeを指定しています。

field :today_weather, WeatherType, null: false, description: '今日の天気'

WeatherTypeは weather, temperature という2つのfieldがありますので、 todayWeather のfieldでは weather, temperature という情報を取ることができます。

また、作った型を指定したときは、リゾルバの内容が型に渡されます

field :today_weather, WeatherType, null: false, description: '今日の天気'
def today_weather
  { weather: '晴れ', temperature: 60 } # <- この値がWeatherTypeに渡される
end

渡されたリゾルバの内容は、 object という変数に入っています。

field :weather, String, null: false, description: '天気'
def weather
  object[:weather] # <- objectの中身は { weather: '晴れ', temperature: 60 }
end

この状態でrails sでサーバを立ち上げてGraphiQL( http://localhost:3000/graphiql )にアクセスします。
左側に以下の記述をして、画面上部の実行ボタン(右向き三角のボタン)を押してください。

query todayInfo {
  currentDate       # 今日の日付
  todayWeather {    # 今日の天気
    weather            # 天気
    temperature        # 温度
  }
}

そうすると以下のようなレスポンスが返ってきます。

{
  "data": {
    "currentDate": "2020年 09月 30日",
    "todayWeather": {
      "weather": "晴れ",
      "temperature": 60
    }
  }
}

これがGraphQLの基礎になります。

余裕があったら!

today_weatherのリゾルバ内の記述を変えてみてください!

def today_weather
  { weather: '雨', temperature: 10 } # <- この値がWeatherTypeに渡される
end

レスポンスが以下のように変わるはずです!

{
  "data": {
    "currentDate": "2020年 09月 30日",
    "todayWeather": {
      "weather": "雨",
      "temperature": 10
    }
  }
}

4. 引数と複数件の情報

情報を取るのに配列や引数が必要になってきます。
以下のようなqueryを想定しましょう

query monthInfo{
  month(monthNum: 1) { # 月の情報(月指定で1件)
    name                  # 英名
    days                  # 日数
  }
  months {             # 月の情報(全件)
    name                  # 英名
    days                  # 日数
  }
}

こちらのqueryは、現在日と月の英名およびその月の日数を返す想定です。

先ほど作成された app/graphql/types/query_type.rb に以下の行を追加します。

module Types
  class QueryType < Types::BaseObject
    ### (省略) ###

    ##### ここから追加
    field :month, MonthType, null: false, description: '月の情報(月を指定して1件)' do
      argument :month_num, Int, '月の数字', required: true
    end
    def month(month_num:)
      month_hash_array[month_num - 1]
    end

    field :months, [MonthType], null: :false, description: '月の情報(全件)'
    def months
      month_hash_array
    end

    # 返すためのデータ
    def month_hash_array
      [
        { name: 'January',   days: 31 },
        { name: 'February',  days: 28 },
        { name: 'March',     days: 31 },
        { name: 'April',     days: 30 },
        { name: 'May',       days: 31 },
        { name: 'June',      days: 30 },
        { name: 'July',      days: 31 },
        { name: 'August',    days: 31 },
        { name: 'September', days: 30 },
        { name: 'October',   days: 31 },
        { name: 'November',  days: 30 },
        { name: 'December',  days: 31 }
      ]
    end
    ##### ここまで追加
  end
end

そして、 app/graphql/types/month_type.rb を作成し、以下のコードを書いてください(こちらも丸コピで大丈夫です!)

module Types
  class MonthType < Types::BaseObject
    field :name, String, null: false, description: '英名'
    def name
      object[:name]
    end

    field :days, Int, null: false, description: '日数'
    def days
      object[:days]
    end
  end
end

引数の付け方

まずは引数の付け方の解説です。
fieldに augument を定義します。(ブロック内で指定しています。)

field :month, MonthType, null: false, description: '月の情報(月を指定して1件)' do
  argument :month_num, Int, '月の数字', required: false
end

引数の指定については以下のようになっています。
Stringを指定すれば文字列にできますし、引数用の型を定義すれば複雑な引数指定もできます。(本稿では省略します。)

argument :引数名, 型, '説明', required: 必須にするか

続いてリゾルバについてです。
引数を指定したfieldについてはキーワード引数としてリゾルバを定義すれば、引数の内容が取得できます。
(※ 1月と指定した場合、1月の情報はmonth_hash_array[0]にあるので、 month_num - 1 になっています。)

def month(month_num:)
  month_hash_array[month_num - 1]
end

配列を返す

続いて配列の返し方です。
複数件のレスポンスになるfieldは、以下のように型指定時に [] で囲むだけで、配列として返すことができます。

field :months, [MonthType], null: :false, description: '月の情報(全件)'
def months
  month_hash_array
end

上記の例だと、 { name: '月名', days:日数} の塊が、いくつもある形のレスポンスができます。
また、全ての型を配列化ができます
例 )

  • [‘いぬ’, ‘ねこ’, ‘アルパカ’] -> 型を [String] で指定する。
  • [10, 23, 37] -> 型を [Int] で指定
  • [{ weather: ‘晴れ’, temperature: 40 }, { weather: ‘雨’, temperature: 10 }] -> 型を [WeatherType] で指定( WeatherTypeについては前項を参照 )

実行してみる!

先ほどと同様にrails sでサーバを立ち上げてGraphiQL( http://localhost:3000/graphiql )にアクセスします。
左側に以下の記述をして、画面上部の実行ボタン(右向き三角のボタン)を押してください。

query monthInfo{
  month(monthNum: 1) { # 月の情報(月指定で1件)
    name                  # 英名
    days                  # 日数
  }
  months {             # 月の情報(全件)
    name                  # 英名
    days                  # 日数
  }
}

以下のようなレスポンスが返ってくると思います。

{
  "data": {
    "month": {
      "name": "January",
      "days": 31
    },
    "months": [
      {
        "name": "January",
        "days": 31
      },
      {
        "name": "February",
        "days": 28
      },
      {
        "name": "March",
        "days": 31
      },
      {
        "name": "April",
        "days": 30
      },
      {
        "name": "May",
        "days": 31
      },
      {
        "name": "June",
        "days": 30
      },
      {
        "name": "July",
        "days": 31
      },
      {
        "name": "August",
        "days": 31
      },
      {
        "name": "September",
        "days": 30
      },
      {
        "name": "October",
        "days": 31
      },
      {
        "name": "November",
        "days": 30
      },
      {
        "name": "December",
        "days": 31
      }
    ]
  }
}

これでqueryはバッチリですね!

余裕があったら

引数を変えてみてください!
情報が変わります!

query monthInfo{
  month(monthNum: 5) { # <- 変えてみる
    name
    days
  }
  months {
    name
    days
  }
}

6. モデルの内容を返すqueryを書く

※ 本稿ではモデルについての詳細な説明は省略します。modelやデータは自分で作ってみてください!

例えば、以下のようなモデルがあったとします。
Userモデル(id以外はstring)

  • id
  • last_name
  • first_name
  • profile
  • created_at
  • updated_at

そして以下のようなqueryを作りたいとします。

query {
  user(id: 1) { # Userモデルのデータ1件取得
    full_name     # last_name と first_nameを半角スペースで繋げたもの
    profile       # profileのデータをそのまま
    created_at    # created_atの年月日までの情報
  }
  users {       # Userモデルのデータを全部取得
    full_name     # last_name と first_nameを半角スペースで繋げたもの
    profile       # profileのデータをそのまま
    created_at    # created_atの年月日までの情報
  }
}

その場合、以下のようにTypeを定義します。
app/graphql/types/query_type.rb に以下を記述します。

module Types
  class QueryType
    ### (省略) ###

    ##### ここから追加
    field :user, UserType, null: false, description: 'ユーザ情報(id指定で1件)' do
      argument :id, Int, 'ユーザid', required: true
    end
    def user(id:)
      User.find_by(id: id)
    end

    field :users, [UserType], null: false, description: 'ユーザ情報(全件)'
    def users
      User.all
    end
    ##### ここまで追加
  end
end

app/graphql/types/user_type.rb に以下を記述します。

module Types
  class UserType
    field :full_name, String, null: false, description: '姓名'
    def full_name
      object.last_name + ' ' + object.first_name
    end

    field :created_at, String, null: false, description: '作成日時'
    def created_at
      object.created_at.strftime("%Y年 %m月 %d日")
    end

    field :profile, String, null: false, description: 'プロフィール'
    def profile
      object.profile
    end
  end
end

解説!

先ほどはhashで指定しましたが、リゾルバから型に送るもの(object)はhashでもインスタンスでもActiveRecord::Relationでもいけます!
以下の2つのリゾルバを見てください。
このように指定すれば、1件の方には User.find_by(id: id) したレコードを、全件の方には User.all のRelationを入れることができます。

field :user, UserType    ### 省略 ###
def user(id:)
  User.find_by(id: id)
end

field :users, [UserType] ### 省略 ###
def users
  User.all
end

Userインスタンスについても、objectに入ります。
なので以下のリゾルバではobjectの中にはUserのインスタンスが入っています。

field :full_name, String, null: false, description: '姓名'
def full_name
  object.last_name + ' ' + object.first_name
end

実行してみよう!

以下のqueryを実行してみましょう!
成功したら、成功です!(細かいレスポンスは省略します)

query {
  user(id: 1) { # Userモデルのデータ1件取得
    full_name     # last_name と first_nameを半角スペースで繋げたもの
    profile       # profileのデータをそのまま
    created_at    # created_atの年月日までの情報
  }
  users {       # Userモデルのデータを全部取得
    full_name     # last_name と first_nameを半角スペースで繋げたもの
    profile       # profileのデータをそのまま
    created_at    # created_atの年月日までの情報
  }
}

7. 便利な術!

GraphQLの記述を書くのに当たって便利な技を紹介します。

処理しなくて良いものはリゾルバが不要!

例えば先ほどのWeatherTypeをご覧ください。

module Types
  class WeatherType < Types::BaseObject
    field :weather, String, null: false, description: '天気'
    def weather
      object[:weather]
    end

    field :temperature, Int, null: false, description: '温度'
    def temperature
      object[:temperature]
    end
  end
end

weatherのfieldでは object[:weather] を返していますが、hashまたはインスタンスで何も成形が不要なときはリゾルバの定義が不要になります。

なので、WeatherTypeは以下のように書き換えることができます。

module Types
  class WeatherType < Types::BaseObject
    field :weather, String, null: false, description: '天気'
    field :temperature, Int, null: false, description: '温度'
  end
end

スッキリしていいですね!

UserTypeいついても同様です!

module Types
  class UserType
    field :full_name, String, null: false, description: '姓名'
    ## 成形しているため、省略不可能
    def full_name
      object.last_name + ' ' + object.first_name
    end

    field :profile, String, null: false, description: 'プロフィール'
    ## 成形していないため、省略可能
    def profile
      object.profile
    end
  end
end

profileは何も成形していないので、以下のように書き換えることができます。

module Types
  class UserType
    field :full_name, String, null: false, description: '姓名'
    ## 成形しているため、省略不可能
    def full_name
      object.last_name + ' ' + object.first_name
    end

    field :profile, String, null: false, description: 'プロフィール'
  end
end

ちなみに、 full_name をUserモデルのインスタンスメソッドにした場合は object.full_name という形にできるので、 full_name のリゾルバも省略することができます!

module Types
  class UserType
    field :full_name, String, null: false, description: '姓名'
    ## full_nameをUserのインスタンスメソッドにした場合は、full_nameも省略可能
    # def full_name
    #   object.fullname
    # end

    field :profile, String, null: false, description: 'プロフィール'
  end
end

いいですね!!

Loaderを使って、N+1問題を解決!

最初に挙げたこのテーブル構造を思い出してください。

users テーブル
- id
- name
- created_at
- updated_at

articles テーブル
- id
- user_id
- body
- created_at
- updated_at

comments テーブル
- id
- article_id
- user_id
- text
- created_at
- updated_at

これを実装する場合、 user.articles の中で article.comments を普通に呼んでしまうと、N+1問題が発生します。
いくら1回のqueryで呼べたとしても、N+1が発生しては意味ないですよね?

そんなときにはLoaderを指定します。
loaderには association_loader.rb というhas_manyの子レコードに対するloaderと record_loader というbelongs_toの親レコードに対するloaderの2つが存在します。

本稿では詳しく説明しませんが、 graphql-batch というgemを入れ、 graphql/loader/ 配下にそれぞれのファイルを入れれば使えます。
複雑なテーブル構造で、データを呼びたいときは試してみてください。

これでもう最強ですね!

最後に

Railsを使ってきた人ならきっとgraphql-rubyを使いこなせると思います。
GraphQLは「AWS AppSync」というAWSのサービスでも採用されていて、主流なクエリ言語になりつつあると考えています!
RailsエンジニアでWebAPIやスマホやタブレットなどのアプリケーションを作りたいと考えている方、その知識を使って便利なAPIを作ってみませんか?

PlantUMLを活用しよう

0

紹介

みなさんも業務上作図する機会が大小あるとおもいますが、下記の問題からなるべく避けたい事象ではないでしょうか。

  • 本質的でないレイアウト作業に手間どるのが嫌、更新も手間
  • 図の差分管理が困難で品質が保ちにくい。

そこでオススメなのがPlantUMLというシステムです。

  • ルールに沿ってテキストを書くだけなので任意のテキストエディタで作図できる。
  • 図の要素とつながりや順序を定義するだけでレイアウトは自動で行ってくれる。(レイアウトを指定することも可)
  • テキスト表現なので差分も明確なため、プログラムコードと同様のバージョン管理を適用できる。
  • とっかかりの学習コストが低い。デモサーバもある。
  • オープンソース(GPL)なので周辺システムが充実している。
  • 名称にUMLとあるがその用途を超越してるので気にする必要はない。
  • デメリット: ローカルでJava実行環境かどこかにJava処理サーバを設ける必要がある。(デモサーバでもええけど)

つらつら書きましたが正確なところは公式サイト他をご覧ください。

とりあえずデモ

  1. ローカル環境の構築
    • Java実行環境
      • 明示されてないが無難に8以上で
    • Graphviz
      • バージョンで相性があるので最新でダメなら適宜下げる。(公式forum)
    • VSCode
      • PlantUML拡張
      • 設定でPlantuml: Export Formatsvgにする。
  2. vscode上で下記のテキストファイル(*.plantuml)を作成
    • 編集中にPlantUML: Preview Current Diagramの実行でプレビュー表示できます。
  3. vscodeから書き出し
    • PlantUML: Export Current Diagramの実行で画像を出力します。
# *.plantuml
@startuml spirits
title PlantUMLを活用しよう

actor Me
participant OS
participant VSCode
participant "任意のVCS" as VCS

== 初期設定 ==
Me -> OS: Javaの導入
Me -> OS: Graphvizの導入
Me -> VSCode: PlantUML拡張の導入
|||
== 作図 ==
loop
  Me -> VSCode: テキスト編集
  Me -> VSCode: 画像プレビュー(自動)
end
Me <- VSCode: 画像で書き出し
|||
== バージョン管理 ==
VSCode -> VCS: テキスト表現のままコミット

@enduml
画像出力結果

おまけ

周辺ツールの紹介

雑感

  • 過去には同種のツールblockdiagを使用していましたが、表現能力がだんちに高いので乗り換えました。SphinxやJupyter用にも拡張があるためほぼ困らないはず。(Python可Java不可な環境以外)
  • 作図に特化したdraw.ioなどは自動配置の仕組みやテキスト書き出しもありますが、ピクセルで調整できる反面テキスト書き出し結果がどうしても煩雑になってしまう。
  • 実際のところ要素が増えてくるとグループ化や個々の配置の調整を行わないと意図したレイアウトにならないのですが、同等のことをGUIで行うよりかは明確で楽です。

その人の「熱量」に「伸びしろ」を感じる。リードエンジニア 高倉利明 インタビュー

0

コンテンツデザイン部のリードエンジニア 高倉さんに「若手に伝えたいことは?」と尋ねると「いきなりスーパーエンジニアになるわけじゃないんですよね」という答えが返ってきました。ベテランのエンジニアになって感じていることを語っていただきました。(2020年 9月 取材)

コンテンツデザイン部 高倉 利明(たかくら としあき)
2007年 3月 アピリッツ入社
趣味はゲーム全般(PS5&RTX3080予約済)、サッカー観戦(天皇杯決勝15年連続。ジダン在籍時のクラシコ現地で見たのがちょっと自慢)

アピリッツ最古参エンジニア

―― 高倉さんがアピリッツに入社された経緯を教えて下さい。2007年にご入社されたのですよね?

そうです。2007年の3月に中途採用で入りました。アピリッツに今いる人で自分より古いメンバーは10人いないんじゃないですかね。入社のきっかけは「技術者が大事にされている会社だ」と感じたからです。あとは良い椅子を全員使っていたことですね。腰痛はプログラマの職業病なので(笑)

もはやすっごく昔の話ですけど、もとは金融系システムを開発する会社にいたんです。で、そういうところになると「プログラムを書くのは若手だけ。さっさと卒業して技術者ではなく管理職になれ」って文化で。自分はエンジニアとして成長したかったし、ここにいたらコードが書けなくなっちゃうぞと思ったんです。

アピリッツに入ったあとは、5年ほどWebサイトの開発や業務系サービスを開発する仕事をしていました。6年目からはブラウザゲーム開発のチームに呼ばれて、今に至ります。

―― ゲーム部門に移ったきっかけは何でしょうか?

声がかかったってのもありますが、自分はちょっとずつ改善することが性に合っているんですよ。たとえばWebSI開発で一括請負契約で開発した場合、保守フェーズに入ると機能改善の機会は少なくなります。

でも自分は改善したくてウズウズするわけです。保守契約にないからやっちゃダメなんですけど「なんなら俺がサービスで修正するよ!? 」って思ってました。

これがゲーム開発だと、運営と改善がより密接に結びついています。ずーっと作って、育てて、改善が続く。だからこっちのほうが自分に合ってるだろうなと考えました。

もちろん子供の頃からずっとゲームは大好きでドラゴンクエスト&ファイナルファンタジーで育ち、大人になってからもオープンワールド、MMO、DTCGなどいろんなジャンルをずっと遊んでますね。最近だとゴースト・オブ・ツシマが面白くてチーム内外で布教してました(笑)

―― Web開発とゲーム開発で思考や仕事のスタイルはちがいますか?

ゲーム系って、アクセスする人数が尋常じゃなく多いんですよ。一般的なWebサイトと比べてアクセスが3桁も4桁も違うことも普通にありえます。これは実際に携わって度肝をぬかれましたね。ですから、大規模アクセスに耐えられる設計が非常に重要になります。

自分の場合は専門性を高めるために、クライアント側よりもバックエンドシステムに特化していきました。もちろんAWSやGCPといったクラウド技術の知識も重要ですので日々勉強しています。

継続的な改善と開発を主導する

―― ゲームの“リードエンジニア”の役目は何だと思いますか?

まず「いきなりマジックが起こってリードエンジニアになる」とか「最初からスーパーエンジニア」なんてミラクルは起きません。どんなエンジニアも積み重ねで徐々に強くなっていく。それは、若手や、なりたてのリードエンジニアにも伝えています。

そして「リードエンジニアに必須のスキルはこれ!」というのはないと考えていますが、求められる役目は「継続的な改善と開発を主導する」ですね。

プロジェクトの問題や、クライアントエンジニアやプランナーが困っていることは何なのか? そういったことを常に把握して、PDCAを回し続けます。それでいて、新しい技術を取り入れていく。

でも、サービスが始まってから新しい技術を入れるのはリスクが高い場合もあります。だから新しいことがやりたいなら検証を重ねないといけない。地道なんですよ。その検証をへて「これは次のプロジェクトで入れよう」と判断することもあります。

「次のプロジェクトでリベンジしてやる!」って気持ちを燃やすエンジニアは多いんじゃないですかね。たとえば今同じチームにいるクライアントのリードエンジニアも改善を重ねる執念がすごいです。だからほんと、すべて積み重ねなんですよ。いきなりスーパーでスペシャルなことができるわけじゃないと思う。

―― 開発中はいろんな職種のメンバーと関わりますよね。どんなふうに仕事をすすめていますか?

自分が今やっているのは大規模プロジェクトです。そしてサーバーサイドエンジニアは、とりわけテストチームとの関わりが多いです。

テストチームは様々なクオリティを保つ大切な存在ですが、テストは開発フェーズの最後にある関係でスケジュール遅延の割を食うこともあります。しかもサービスが始まってからバグが見つかると一番責められることも多い。

個人的にテストチームには本当に感謝していますし、チームメンバーにも常にその気持ちを持つことを心がけてもらってます。だから、テストチームの仕事が円滑に進むように、常にヒアリングしてデバッグ機能やツールを作ったり、事前にテストの手順をまとめたりしています。

君の「熱量」が聞きたいんだ!

―― エンジニアのお話にもどります。「この人、いいなあ」と思う後輩はどんな人ですか?

まず自分の嫌いな言葉に「最近の若いやつは」というものがあります。デジタルネイティブの若い世代は、自分たちの若い頃と比較するとみんな本当に優秀ですよ。自分が30代中盤にヒーヒー苦労してたことを彼らはアッサリ乗り越えてます。

そして自分が最重要だと思うのは、現在の実力よりも情熱がある人。新卒でも中途でも「熱量」が気になるんです。「会社に入って何がしたい?」と質問されて受け身の答えの人より貪欲な人のほうが伸びますし。あと、ゲーム開発者の熱量って意外とユーザーに伝わるんですよね。

―― なるほど。これから一緒に働きたい人も、そういう人たちですか?

はい。あと「いいなあ」と思うのは、自分のビジョンを持ってる人です。伸びる人は上からの指導は関係なく勝手に伸びてくものですよね。そして、そういう人はビジョンが明確。たとえば「リリース前でも定時帰り」を目標に掲げて、日中帯に人一倍集中して仕事をする若手がいます。自分は「リリース前なら終電帰りや休日出勤も辞さない」みたいな古い感覚が抜けないので、そういった発言は刺激になりますね。

人間関係の貯金でチームの強度を上げていく

最近はプロジェクトが大きくて50名近くのメンバーで開発することもあるのですが、大事なのはお互いリスペクトを忘れないことです。人間関係は貯金みたいなものだと思ってます。これも日々の積み重ねです。そしてトラブルがおきたときのチーム強度に関わってきます。持ちつ持たれつの関係って重要です。

チームで働くにあたって、趣味や好きなものは「積極的かつ具体的に」アピールすることも重要だと感じます。人間は他者への共感を持つことで仲間意識が芽生えるので、チームでの仕事がしやすくなる。

最近のエピソードで言うと、「趣味はサッカー鑑賞です」って大まかな回答をするメンバーがいたので「どこの試合行くの?」って聞いてみたわけです。そしたら「鹿島アントラーズです。地元なので」って。「そういうのが会話のタネになる。アピールしなきゃイカン!」って熱く伝えました。

また「どういうタスクをふれば、このひとは燃えるかな?」って采配は本当に大事です。チーム全体が最適化されるようにタスクをアサインするマネジメント領域です。人はそれぞれ得意なことが違う、という意識を持つことも大切ですね。

「メンバー全員が積極的でリーダーシップを持つチーム」って、理想的ではあるが現実的じゃないと言うか。例えば「自分の意見を出すのは苦手だが振られたタスクは必ずこなす」ってメンバーに対して「積極的にやらないから悪だ!」って空気になったら不健全ですし、チームのパフォーマンスは落ちるので。

マンネリズムを防ぐことも重要で、大規模プロジェクトになると1年以上の長期間に渡り開発することもあります。そうなるとどうしてもパフォーマンス落ちることもあるはずです。自分にもそういう時期はありましたし。

「好きなこと」と「得意なこと」を見極めよう

―― 高倉さんにも停滞する時期があったんですね。どう克服したのですか?

違うプロジェクトや環境に飛び込むことがいいキッカケになりましたね。新しい環境で尊敬できるエンジニアに出会えて、触発されて成長できたんです。

停滞していたのは「場」を変えなかった自分の責任だと思ってます。

だから「場が人を作る」って考えに自分は賛成します。自分の得意なことを「場」で見つけられたら、人って生き生きするんですよね。アピリッツに転職する前に、勉強会で知り合ったエンジニアに当時の環境を愚痴ったら「転職しなさい」ってアッサリ言われて「ああそっか」って思いましたもん。自分が輝ける職場って絶対にある。

あと自分が「好きなこと」と「得意なこと」と「苦手なこと」を見極めるのも大事です。「好きで得意な」仕事があれば良いですが、そうでない場合は「あまり好きではないが得意な」仕事をやると、周りも喜ぶし比較的うまくいくなーと思っています。

逆に「好きだけど苦手なこと」ってのもあって。その方向を選んでしまうと、うまく行かずに周りから評価もされづらくしんどくなるかと。

―― 高倉さんにとってアピリッツってどういう場だと感じますか?

エンジニアの裁量権が広い会社だと思いますね。たとえば「AWSのこのツールを使ってみたい!」っていうエンジニアの熱意と好奇心から始まって「じゃあこれ使ってなんかゲームシステムを考えよう」ってこともあります。

だから目的意識がクリアな人こそ楽しめる環境でしょうね。

定年までずっと現役エンジニア

―― いま心がけていることを教えて下さい

「俺が教えてやる」って上から目線な態度を取らないように心がけてます。その態度が出て勉強することを怠ったらエンジニアとして現役でいられないかなと。

勉強会をやるとしても、初回は自分がやるけど、二回目は他のメンバーにもやってもらいたい。自分も教わりたいです。自分は定年までずっとエンジニアリングの前線に立ちつづけたいと思っているので、勉強はずっと続けます。

とはいえ、個人的には体力が衰えてきて集中力は落ちたなと自覚してます。だから体を鍛えるって超大事で、筋トレやロードバイクなどで少しでもパフォーマンスが落ちないように気をつけてます。流行のエンタメに触れるのはゲームを作る側として重要なので、可能な限り流行っているゲームや漫画などは抑えるようにしていますね。

――  アスリートと同じ感覚ですよね。最後に、高倉さんがコードを書く際に集中力を上げる方法を教えて下さい!

とあるシューティングゲームのサントラを聴くことです。ちょうど再生時間が30分なので、聴きながらウワーっと集中力を上げて全力でやって、5分休憩を入れて、また30分聴きながら全力でやる。自分の仕事のテーマソングですね。

――  つまり、仕事中以外はその音楽を聴かない?

聴けないですね、だって仕事モードになっちゃうから(笑)

――  「場が人を作る」「チームの強度を上げる」という言葉が印象的でした。高倉さん、ありがとうございました!

CEH認定ホワイトハッカーの紹介

0
CEH

エンパワーメントサービス部所属セキュリティエンジニアの綾城です。
CEH(Certified Ethical Hacker)に合格したので、CEH v10の紹介と受験体験記を書きます。

はじめに

CEHは、EC-Council社が実施しているグローバルなセキュリティ専門家の認定試験です。日本の代理店はGSX社です。Certified Ethical Hackerを認定ホワイトハッカーとしています。(ホワイトハットとか、そのままエシカルハッカーとかの方が、個人的には好みです)特に攻撃側に特化した内容になっており、攻撃者の視点でシステムを検査することなどができるようになったりします。5日間の講習の後、試験を受けることで合格となります。

経産省の情報セキュリティサービス審査登録制度、情報セキュリティサービス基準で、脆弱性診断サービスの提供に必要な専門性を満たすとみなすことができる資格としてCEHが例示されています。

しかし日本ではあまり知名度がないのか、名指しでの求人情報は少なさそうでした。試しにindeedで検索したところ、年収350~2500万円のものがヒットしました。グローバルナレッジが毎年出してる資格の年収ランキング15で、2019年まで掲載されていました。(2019年は、11位で、年収11万6306ドルでした。日本円で年収1200万円ぐらいでしょうか)

あとアメリカ合衆国国防総省のなんかです。各種セキュリティの資格の説明によく出てくるのですが、私はよくわかってません。日本でいう情報処理安全確保支援士のような感じでしょうか?調達要件みたいなものでしょうか?

セキュリティの資格試験は、一般的にマネジメントかテクニカル寄りか、攻撃側か防御側かの性質の違いがあったりするのですが、CEHの位置づけは、攻撃側のテクニカル寄りの資格になります。CISSPのようにマネジメント寄りではないですが、OSCPみたいな実技試験でもないので、物凄くテクニカル寄りでもないです。
同じ攻撃側の試験ですと、ConpTIA PenTest+がありますが、CEHには契約や報告書を書くなどといった要素はありません。EC-Councilでは、SOCやCSIRTなどの防御側の資格として、CND(認定ネットワークディフェンダー)があります。CompTIAの資格ですと、Cysa+がそれに相当します。

講座を受けすに独学で試験を受けることをできますが、問題文が英語の試験を受けることになります。私は詳しくは知りませんが、学歴や経歴の提出が必要かもしれません。

EC-Councilセキュリティエンジニア養成講座
https://www.gsx.co.jp/academy/ceh.html

情報セキュリティサービス審査登録制度
https://www.meti.go.jp/policy/netsecurity/shinsatouroku/touroku.html

稼げるIT資格はどれ?―米グローバルナレッジが2019年版のトップ15を発表
https://hrzine.jp/article/detail/1553

アメリカ合衆国国防総省(DoD)のなんか
https://public.cyber.mil/cw/cwmp/dod-approved-8570-baseline-certifications/

CEH受講概要

公式ウェブサイトには、下記のように記載されています。

■下記の内容が理解できれば問題ありません(予習推奨)
 1)CCNAレベルのネットワークに関する内容
 2)LPIC Level1程度のLinuxに関する内容
 3)企業で導入されているFirewallなどネットワーク・セキュリティ機器の構成に関する内容
 4)下記ツールの使い方
   ・Wireshark や tcpdump
   ・nmap
   ・ローカルプロキシ(Burp Suite、Owasp Zed Attack Proxy、Fiddler)

■下記の実務経験があると講座内容がより理解しやすい
 ・プログラミング(C/Perl/Java/PHP)
 ・ネットワーク構築
 ・ネットワークトラブルシュート
 ・パケット解析
 ・ペネトレーションテスト

個人的に受けてみての感想だが、ネットワークの知識は必要だがCCNA程度に達してなくても問題ない。同様に、Linuxの基本的なコマンドを知ってる必要があるが、LPIC Level1程度に達していなくても問題ない。プログラミングとの表記に恐れをなしている方が割といるが、簡単なシェルスクリプトを理解する程度で大丈夫だと思う。

速いテンポで講習は進みますが、かなり基本的なことから教えてもらえるので、そんなに心配しなくてもいいと思いました。
あと特にウェブサイトには書いていませんが、受講者契約をよく見ると、18歳未満の方は受けられないかもしれない。

CEH講習

5日間みっちり講習を受けます。下記の20モジュールに分けられてます。
v9で、モバイル・プラットフォームのハッキング、クラウド・コンピューティングの追加。
v10で、脆弱性解析、IoTハッキングが追加されています。全体的にリファインもされているようです。

ホワイトハッキングのご紹介システムハッキングセッション・ハイジャックワイヤレスネットワークのハッキング
フットプリンティングマルウェアの脅威IDS、ファイアウォール、ハニーポットの回避モバイル・プラットフォームのハッキング
ネットワークの診断スニッフィングWebサーバのハッキングIoTハッキング
列挙ソーシャル・エンジニアリングWebアプリケーションのハッキングクラウド・コンピューティング
脆弱性解析サービス拒否(DoS攻撃)SQLインジェクション暗号技術

受講前の契約書ぐらいで、倫理面の内容があまりなく、攻撃側にかなり偏ってるので、新人教育などに使う場合は注意が必要かもしれません。全体的に各種ツールの紹介が多めでした。

脆弱性診断を行っている身としては、脆弱性解析の追加は嬉しいですね。自分の講習を担当した講師1人が、現役で脆弱性診断をやってる方で、少し脱線気味の話も割と有益でした。

脆弱性としてSQLインジェクションが1つのモジュールとして独立してて、少し踏み込んだ内容でした。IDSやファイアウォールの回避方法など普段あまり考えたこともなかったので新鮮でした。モバイルはAndroid、iOSもありましたが、なんだか一昔前のBlackBerryを意識した感じでした。

CEH講習教材

物理テキストを希望すると日本語のスライド資料の印刷版が2冊、英語のiLabsのマニュアル1冊の計3冊を入手することができます。厚さだけでいうと、CISSP(スライドではなく文章)より厚く、SANSの5日間のものより薄いぐらいです。

電子版は、かなり強力なプロテクトがかけられていて、印刷はできないどころか、ビューアーも特殊なものが要求されています。(PDCViewerというもので、なんかチラチラして、スクロールするとラグがある。書き込みがしにくい)2つのデバイスまでで1年間閲覧することができます。1台は、大きめのスマホか、タブレット端末で閲覧できるようにした方が便利だと思います。

CEHラボ実習

iLabsと呼ばれるラボ実習は、下記のようなことを行いました。
環境は、Windows Server 2006,2008,Windows 8,10,Kali Linux,Android,Ubuntuの仮想マシンが動作してます。

ラボ環境は、日本語化されていませんが、解説部分がブラウザの為、chromeの翻訳機能やコピーアンドペーストで翻訳にかけることができます。
SANSの講習と違って環境がオンライン上にあるので、ローカルマシンが多少プアでもネットさえ繋げれば、半年間いつでも実習することができます。

Firebug を利用したターゲットウェブサイトに関する情報の収集
HTTrackWeb Site Copier を使用したウェブサイトのミラーリング
hping3 を利用した UDP パケットと TCP パケットの作成手法
Nmap を使用したネットワークスキャンについて
さまざまなネットワークスキャン手法について
SuperScan を使用したネットワーク列挙の実行
Hyena を使用したローカルマシンでのリソースの列挙
ターゲットマシン上のサービスの列挙
Nessus を使用した Web サーバの脆弱性確認
Nikto を使用した Web サーバの脆弱性確認
クライアント側脆弱性を利用して権限を昇格させる
Spytech SpyAgent を用いてユーザーシステムを監視し、サーベライスする
OpenStego を用いた画像ステガノグラフィ
HTTP Trojan を構築し、HTTPRAT を使用してターゲットマシンを遠隔操作する
njRAT を使用して標的マシンの制御を獲得する
Wireshark を使用したパスワードのスニッフィング
Cain & Abel を使用した中間者攻撃の実行
SET を利用した Facebook の証明書情報のスニッフィング
hping3 を使用したターゲットホストの SYN フラッド
HOIC を利用した分散型サービス拒否攻撃の実行
Zed Attack Proxy (ZAP) を使用したセッションハイジャック
Snort を利用した侵入検知
HTTP/FTP トンネリングを利用してファイアーウォールをバイパスする
Metasploit を利用して ファイアーウォールをバイパスする
httprecon を使用した Web サーバのフットプリンティング
辞書攻撃を行い、 FTP 認証情報をクラックする
Web アプリケーションに存在するパラメータ改ざん及び XSS 脆弱性の利用
WPScan と Metasploit を使用した Web アプリケーションの列挙とハッキング
さまざまなセキュリティレベルでファイルアップロードの脆弱性を悪用する
MySQL への SQL インジェクション攻撃
Aircrack-ng を利用した WEP ネットワークのクラッキング
Aircrack-ng を利用した WPA ネットワークのクラッキング
Kali Linux を使用して Android をハッキングするバイナリペイロードを作成する
ownCloud でのユーザーアカウントの作成とユーザー権限の割り当て
ClamAV を使用した悪質なファイルアップロードからの ownCloud の保護
Kali Linux を使用して ownCloud AV をバイパスしてホストをハッキングする
HashCalc による一方向性ハッシュの計算
VeraCrypt を使ったディスク暗号化

CEH試験概要

私は難易度はそれほど高くないと感じましたが、落ちると受験料8万円で再試験となります。試験会場は、浜松町のGSXで受けました。

問題の中には、シチュエーション問題のような体裁で、ただの知識問題もあるので、恐れないでよく読みましょう。おそらく時間は余るので、選択肢から読むとかいう時短テクニックは必要ないと思いました。SANSのGIACと違い日本語で試験を受けられるのは嬉しいですね。あまり変な日本語はありませんでした。

CBT選択式125 問
制限時間 4 時間
70%以上合格

CEH試験勉強

試験対策で、iLabsの演習をやり込むのはあまりおススメできません。私は当初スライドをすべて見直そうとして、講習中に講師がここは後で読んでおいてとか言っていた場所などもじっくり読みながら進めていたらとても時間がかかってしまい挫折しました。5日間みっちりやったものプラスアルファを再度やるのにかかる時間をあまり考えていませんでした。

アプリPocket Prepに課金してやってみましたが、問題が簡単な気がして、やるのをやめてしまいました。その後、勉強会に参加して教えてもらった下記の無料の問題集サイトをやりながら、Udemyを見て復習、書籍を買うとアクセスできる問題サイトをこなしてから試験に挑みました。

CHE向け解説動画

【情報セキュリティ】Ethical Hacking:ホワイトハッカー入門
https://www.udemy.com/course/ethical-hacking-jpn1/
実際CEHの講師をやってる方が作成した、Udemyの動画。予習にも復習にもいいと思います。
普段は高いので、キャンペーンのときに買いましょう。

CEH問題集サイト

Certified Ethical Hacker – Online Practice Exam
https://ceh.cagy.org/
おすすめの無料サイト、chromeの翻訳機能を使って隙間時間に解いてました。
解説があまりないのと、たまに解答が間違っている感じがするのが少しイケてない。

CEH試験対策書籍

私は勉強会に出るまで、何から手を付けていいかわからなかったので、新旧やみくもに書籍を購入しまくりました。実際有用だったものを紹介します。


こちらは、参考書なので問題が275問と少なめですが、解説もしっかりあって、難易度もいい感じに高めなので、一通りやりました。購入すると、問題集のサイトにアクセスできるようになるので、chromeの翻訳機能を使って日本語にして問題を解きました。


上記の問題集版、現在まだv10が発売されていないので、脆弱性解析、IoTハッキングの問題がないですが、625問と量があるのでやり込みたい人にはおススメ。私はSybexの本が好きみたいです。


こちらは、v10に対応した問題集です。こちらもウェブで問題が解けるのですが、chromeで翻訳できなかったので、私はやらなくなってしまいました。

CEHアプリ

CEH Pocket Prep
https://play.google.com/store/apps/details?id=com.pocketprep.ceh&hl=ja
こちらスマホのアプリです。課金するとウェブで問題が解けるようになります。chrome翻訳もできます。
Android、iOS版で価格が違ったり、課金方法が複数あるみたいでした。私は、一番安そうだったAndroid版のプランに入りました。問題数もたくさんあり解説はあるものの、なんだか問題が簡単な感じがして違和感を覚えたのでやらなくなってしまいました。
基礎からやりたい人や時間がある人にはいいかもしれません。

CEH勉強会

CEH StudyGroup
https://ceh-studygroup.connpass.com/
以前は、GSXに場所をお借りして行っていたようです。現在は、不定期でTeamsを使ってオンラインでやってます。私はここで、いろいろと情報交換して試験に挑みました。CEHに限らずセキュリティのことを気軽に聞けてよかったです。

合格しましたが、私は今後も何かお手伝いできればなと思っているので、参加は続けようと思ってます。また合格したらSlackもありますので、参加していただけると嬉しいです。何かありましたら、勉強会やSlcak、下記のメールアドレスへお願いします。

CEH合格後

グローバルな資格にありがちな継続教育ポイントを貯めないと資格を維持できないシステムです。私はまだ受かったばかりなので未知の部分が多いです。
紙の認定証は有償です。PDFは無償でもらえるので、自分で印刷すればよいと思います。

さいごに

弊社では、セキュリティエンジニアを募集しています。Webセキュリティについて学んだことを活かしたい、セキュリティの資格にチャレンジしてみたい方など歓迎します。興味ある方は、下記の採用情報からセキュリティエンジニアの職務内容・応募資格を確認してみてください。もちろん、Webエンジニアも募集中です。下記ボタンからぜひ確認ください。

【成果発表会】「読みやすいコードのために、すぐに伝わる命名を」以心伝心

今回は社内の成果発表会「P-Review ’19」にて発表した、エンジニア H.Fさんの資料を紹介します。
※この記事は個人の研究発表で、会社としての見解ではございません。
こちらに載せられているプログラムは、すべて資料のために作成されたものであり、実際のプログラムとは異なります。

P-Review19hf

H.Fさん
2018年7月アピゲー部エンジニアとして入社。
入社後は主に自社開発ゲームのゲームエンジニアを担当。

早速ですが皆様にお聞きしたいことがあります。この2人は誰でしょう?

「すずきさん」と「たなかさん」かな……?

正解は……

右側にいる鈴木という表記の人は「テリー大隅さん」。田中Tシャツを着ている人の名前は「牛山牛子」さんという名前だそうです。

!?!?

意味わからないですよね……?
それでは、「以心伝心」発表を始めたいと思います!

以心伝心とは

• いしん-でんしん【以⼼伝⼼】
ー⽂字や⾔葉を使わなくても、お互いの⼼と⼼で通じ合うこと。
▽もとは禅宗の語で、⾔葉や⽂字で表されない仏法の神髄を、師
から弟⼦の⼼に伝えることを意味した。「⼼こころを以もって⼼
こころに伝つたう」と訓読する。(参考:google辞書)

まず以心伝心とは、文字や言葉を使わなくても……などと意味は色々と書いてありますが、つまりお互いがわかりあっている状態のことだと自分は解釈しています。

目的

コーディングでの機能拡張や改良や諸々の対応をしている時に、そのコードが自分が対応したものとは限りません。書いてあるコードが読みやすいと、実装が早くなって作業効率が上がったり、その日は途中で終わっちゃった場合であっても、次の日すぐに把握しやすくなります!

こういう経験ありませんか?

そもそも、コードを読む際に一瞬でも思考が止まるようなコードは好まれないと思います。

では、一瞬でも思考が止まるようなコードとはなんなのか。
エンジニアの方、こういう経験はありませんか?

①名前と内容が一致しない

※こちらに載せられているプログラムは、資料のために作成されたものであり、実際のプログラムとは異なります。

メソッドや変数の名前が一致しない
例えば、「A」のコードだったとして、メソッド名はなぜか「B」だったとか……謎ですよね。

②全てが繋がっている

コードの流れがすべて繋がっている状態
改行とかがなく、コードの処理がすべて繋がっていて読みにくい状態ですね。

③処理に行くまでが長い

次に、ネストが深すぎて処理に行くまでが長いという状態。

④肯定された後に否定をされる

次にif文の条件とかで肯定されている文の後に、否定をされている状態が連続されているという状態です。

コードを読むのが嫌になってきます……。
なので、今すぐできる相手への伝え方についてのポイントをまとめてみました。

● 名前
名前の命名をちゃんとすることにより、処理の把握自体がすぐにできると思います。

● 美しさ
先ほど言った処理の流れが繋がっている状態ですと、どこに何の処理があるのかわからなかったり、一度思考が止まった時にどこから見直せばいいのかいまいちわからなくなってしまうことがあります。

● ネストの深度
処理に行くまでが長い状態、if文がたくさん並んでいる状態ですと、見直す時に最初から見直さないとちゃんとした見直しにならないというところですね。

● 肯定文と否定文の混在
今すぐにでも相手に伝えられるような効率になるかと思います。

それでは、ひとつずつ説明していきたいと思います。

名前

• な‐まえ【名前】
• ① ある⼈や事物を他の⼈や事物と区別して表すために付けた呼び⽅。名。
• ② ⽒名。またその名字を除いた部分。「ここに−を書いて下さい」
( 参考:⼤辞林第三版)

僕が検索した中だと、2種類の意味がありました。
今回に適する意味は「①ある⼈や事物を他の⼈や事物と区別して表すために付けた呼び⽅。名。」です。
つまり伝わらない名前は、名前としての役割を果たしていないということになります。

なので最初に、名前に必要な情報を詰めます。
アバウトすぎるので、少し分解して説明していきます。

明確な単語を選択

まず明確な単語を選択します。
広義的には間違っていないけれども細部を表せていない単語を選択することを、今回問題に取り上げています。
改善点としては、広義に間違っていない単語の解釈を一つ掘ることで、明確にできるのではないかと思います。

例えば「stop」という名前を付けている場合、取り消しが不可能な処理であれば「kill」をつけたり、取り消しや「stop」を解除できるようなものであれば「pause」にするとかですね。

抽象的ではなく具体的な単語を選択する

2つ目、抽象的ではなく具体的な単語を選択する。
名前に属性の情報を付け⾜すと、「何をしたいのか」などを瞬時に明確に理解できるようになります。

こちらに関しては、日にちが経った後でも変数名を見るだけで、どんな値が格納されているのかをすぐに確認ができるようになると思います。例えば「delay」っていう変数があったとしてその「delay」に入っているのは何か↓

• delay -> delay_msec, delay_min
• size -> size_mb
• limit -> max_kbps, min_num

このように置いてみましょう!

誤解が⽣まれない単語を選択

3つ目、最善な単語というのは誤解が⽣まれない単語のことです。
逆に⾔えば、誤解が⽣まれない単語は最善な単語になる。

例えば、 エンジニアですと名前の頭に「is」や「has」を付けると、「bool」を返すメソッドだったり変数だと思います。なので、「bool」の値を返すようなメソッドじゃないのに、「is」や「has」を付けると誤解が生まれるということです。

省略から始まるミステリー

4つ目、できる限り省略をしない
ポピュラーな単語のポピュラーな省略の仕⽅であれば問題ないと思いますが、これがプロジェクト単位での固有名詞や、あまりポピュラーではない単語の省略になると、急に翻訳も利かなければ検索しても出てこないようなミレニアム懸賞問題レベルの難問になってしまいます。なので基本は省略をしないのをオススメします。

でも、エディターの横幅の関係上で省略をしたい場合は、コメントなどでメモを残しておいた⽅がいいでしょう。

否定の副詞が⼊ると頭は⼀旦停⽌する

5つ目、否定をしないこと。こちらは英語の⽂法にすると分かり易いと思います。

a.「 This is the pen I used」
b.「 This is the pen I didnʼt used」

a.とは違って、b.⽂では「didnʼt 」の部分で、一瞬だけ処理を把握するためのプロセスに「”usedを否定して~” 」というプロセスが追加されませんでしたか?

⼀単語が増えることによって考えることが増えて、そこで⼀瞬思考が⽌まることが多くなるのであまりオススメしません。

名前が⻑過ぎると読む気が失せる

6つ目、名前の長さです。名前が長すぎると、とても読む気が失せます。

一番最初にある変数の宣言は、この長さが続くと、この後の変数を使う部分のように、とてもとても読みにくくなると思います。

おまけ~メソッドの命名について~

名前の命名について、先ほど6つくらいのポイントを上げました。処理の内容を具体的に表せていると良いと提⽰しましたが、メソッドの命名が処理の内容を具体的に表せていると、名前と処理の⽐較をしたときに逸脱した処理を⾏っていた場合は、そのメソッドは機能を持ち過ぎという⼀つの判断にもなると思います。

美しさ

コーディングによる美しさとは、見た目の問題としてコードが整理整頓されていること、コードの縦線が揃えられていること、エディターの横幅を越えないようにされていることがあげられます。

こちらのモデルを例にして説明していきたいと思います。

コードを整理整頓する

先ほど全部羅列されていたコードを処理ごとに分けてみました。この4つを分けることによって、どの処理がどこで何をしているのかわかりやすくなっていると思います。

コードの縦線を揃える

コードの縦線を揃えられてることによって、変数だったりメソッドがどこでどんな値を入れているのかが見やすくなると思います。

エディターの横幅を越えない

先ほど見せたコードですが、エディターの横幅を超えたことにより、改行されている部分があります。

こちらの部分をメソッドの引数に合わせて改行するのと一緒に、引数の縦線を合わせるのを加えることによって、こちらのメソッドの処理が何を引数にして何を返しているのかが分かりやすくできたと思います。

ついでに、個⼈的な趣向も追加

最初の羅列されているコードのをさっきのポイントを含めて、なおかつ個人的な趣向を含めて直しますと……

このようになります。

コメントを足しただけなのですが、これをすることによってどういう処理なのかをレイヤーで把握するのが早くなります。

ネストの深度

始めに、ネストについて説明していきます。

ネスト【nest 】⼊れ⼦/ ネスティング/ nesting
ネストとは、あるものの中に、それと同じ形や種類の(⼀回り
⼩さい)ものが⼊っている状態や構造のこと。ITの分野では、
コンピュータプログラムやデータ構造において、ある構造の内部に同じ構造が含まれている状態のことを指す。

調べたら難しいことばかり書いていますが、つまりこういうことです!

ひとつのスコープの中に、また処理が入っている状態のことです。

ネストの深さは闇の深さ

条件が複数になったことによって、これが続いていきますとどんどん深くなっていきます。ネストの深さは闇の深さとも言われているほどです。

これもそうですが、コードから不吉な匂いがしてきます……。

こちらのコードの問題点は、ネストの深さによりメンテナンス性が落ちていること。というのも、条件が複数になることによって、一つ処理を戻ってこれがどうだったのかを把握するときに、またその条件に対して思考をしなくてはいけなくなるので、把握の時間が伸びることでメンテナンス性が落ちてしまうんです。

そして、何よりも読みたくなくなる。こちらの改善⽅法は2つあります。

①例外処理はreturnする( ガード節)

「return」をすることによって1つネストを浅くしております。
ここでは「next」にしているんですけども、実際やっていることは「return」とほぼ一緒なので同じです。

②メソッド化して、処理を細分化する

同じような処理がたくさんあったりするとメソッド化をしますが、ネストの深い部分を一つ一つ分解してメソッド化をするというのも一つの対処だと思っております。

おまけ

• 現状ボス判定のないエネミーの、「kind」が1で「attack_pattern」が1のものだけのユニークな処理になっている。

• ここから何かを拡張しようと思うとif⽂の分岐を⽣やしたりとどんどん汚くなるのが⽬に⾒えているため、個⼈的には
– ボス⽤の「update」メソッド
– 親メソッドにも少し⼿を加えて、「kind」と「attack_pattern」の種別とそれに合わせて係数が変更されるようなメソッドを作成しておくと、プランナーのマスター操作だけでコード側の変更がなしでできるようになるから良いです。

肯定⽂と否定⽂

if文のところ見ていただきますと、最初の「master.i==1」の部分が肯定文です。

次に「!」がついているところが否定文になります。

また次の肯定文がきて、否定文となっています。

このように否定と肯定文が混在することによって思考のプロセスが止まることになると思います。

問題点

● 肯定⽂と否定⽂を混在させると、知りたい処理にたどり着くまでが遠くなり思考が止まる要因になったり、誤認をさせる可能性が⾼くなります。

• if文の条件式に肯定⽂と否定⽂を混在させてネストを深くされると、読む側は戻った時に同じところをまた考えなくてはいけなくなるので脳内メモリをガリガリ消費されていくような気がします。

改善⽅法

これらの改善方法については先ほど説明しました「例外処理は早い段階でreturnする。(ガード節) 」「メソッド化をして処理を細分化する。」に加えて、「⾔語によっては勝⼿に⽤意してくれてたりする。」ということもあるのでそちらについて説明していきます。

Ruby の場合

Rubyの場合ですと、「nil?メソッド」だったり、「empty?メソッド」というものがあります。
先ほど言った「true」を返すメソッドです。

Ruby on Rails の場合

「blank?メソッド」、「present?メソッド」の2つがあります!

C# の場合

調べたところ、「null合体演算子」というものがあるそうです。
例文を書きましたが、「hoge ?? ”Null”」「hoge 」が「null」 なら、「”Null”」 が返されるものだったりとか、「HasValue」というメソッドがあったりするそうです。

まとめ

名前
⼀⽬で⼊ってる値や処理が推測できる命名をする。

美しさ
処理毎に⼀⾏空けたり縦線を揃えたりして、綺麗に魅せる努⼒をする。

ネストの深度
例外処理は早い段階でreturnして弾いたり、メソッド化をする。

肯定⽂と否定⽂の混在
肯定⽂と否定⽂の混在は混乱の元。
できるだけ否定形は使わないようにして、混在しそうになったら⼯夫する。

こちらのポイントを押さえることより、他のエンジニアが見てもわかりやすいコードが書けるようになると思います!

最後に

この4つの中で今すぐにでも変えられることは「名前」だと思います。

皆さんも以心伝心のようにすぐに伝わる命名を意識して、一緒に効率化を目指しましょう!

名前って大事ですよね~!アイコもほかの人が見ることも考えて、ファイル名などを気を付けることから始めてみようと思います!

雲の呼吸 壱ノ型~AWS設計の勘所:コスト編~

0

はじめに

データイノベーション部浅田です。

人気漫画「鬼滅の刃」に仮託して、「雲(クラウド)の呼吸」と題しまして、AWS(Amazon Web Services)を用いたアーキテクチャ設計の勘所を数回にわけて書いていきたいと思います。

なお、AWSに関するサービス名に関しては、この記事内で初出時は正式名称をつけ、以降は明確な場合は省略系を用いる方針で記述しています。

第一回目は「コスト」です。

コストは設計の考慮事項でも最重要事項

今から遡ること2000年以上前、紀元前3世紀のギリシアにあったエピロス国のピュロス王は戦術の天才と呼ばれ、イタリア半島を統一しようとしていた古代ローマと戦い二度勝利を収めました。ただ自軍の損害も大きく、三度目の戦いでローマに敗れました。この故事から「割に合わない勝利」のことを「ピュロスの勝利」と言ったりします。

営利企業であれ、非営利法人であれ、組織が事業を展開するにあたってコストの問題は常に付きまといます。どんなに優れた設計であっても、コストがかかってサービスの継続が難しくなってしまうとするなら本末転倒になります。ピュロスの勝利になってしまっては元も子もないわけです。

クラウドの利用が加速しているのは、コスト面でもメリットがあるからですが、漫然と利用していては、そのメリットを最大限に生かすことはできません。

コストを削減するための設計心得

では、コストを抑える設計のポイントはどういったものがあるでしょうか。私が思うに、以下のような点がポイントになるかと思います。

  • Amazon EC2 Auto Scalingで必要な時に必要な分だけ起動する
  • 安価なストレージを利用する
  • 割引オプションを利用する
  • 要求される可用性を見極める
  • サーバレスを積極的に利用する

Auto Scalingで必要な時に必要な分だけ起動

クラウドを使うメリットの一つは仮想化されたCPUやメモリを自由に追加、削除できることです。代表例はAmazon EC2のAutoScaling設定です。Auto ScalingはAmazon CloudWatchの任意のメトリクス(例えばCPU使用率)の指標をもとに、EC2インスタンスの台数を増減させる機能です。

多くのワークロードにおいて、長期間に渡って常に一定のリソースが必要ということはあまりないでしょう。Webサービスであれば、利用者の増減がありバッチ処理であれば、データの増減があります。なので、Auto Scalingによって負荷の増減に対応して、EC2インスタンスの台数を増減させることは有力な基本方針の一つです。

基本と書いたのは、Auto Scalingはサーバの起動時間が数分かかるのでスパイクアクセスには有力な選択肢とならないことや、Auto Scalingを運用するには、サーバ自身には重要なデータを置かない(ステートレスにする)必要があるなど、注意点もあるからです。

安価なストレージを利用する

基本的にはAmazon S3にデータを保持するようにした方が良い場合が多いです。

S3

保存コストが安いということもありますが、耐久性もすぐれています。S3にデータを保存することで、EC2をステートレスにしてAuto Scalingの適用を可能にする利点もあります。

データの耐久性を少し落とした低冗長化ストレージのオプションも存在するので、ワークロードに合わせて、検討すると良いと思います。

ただし、ブロックストレージを代替するものではないので、読み書きを頻繁に行うファイルの保存先には向いてません。また、キャッシュなどの低いレイテンシを求められる用途にも向いてません。

Amazon S3 & Amazon S3 Glacier Deep Archive

S3よりさらに安価な保存携帯がGlacier、およびその派生のGlacier Deep Archiveです。

アクセス頻度が稀で、長期的に保存しておきたいデータの保存先として候補になります。例えばログデータであったり、監査用のデータなどです。

ただし安価である代わりに、取り出しに時間がかかります(標準で3〜5 時間、Deep Archiveであれば12時間以内)。

Amazon EBS

EC2やAmazon RDSにはEBSというブロックストレージを必ず使用します。アプリケーションでデータを保持する上で、一番シンプルに利用できるますし、レイテンシも低く利用できます。ですが、コスト観点で見ると必ずしも最適な選択肢とは言えません。また、複数のEC2サーバから読み書きするような用途には向きません。基本的にEBSには必要最小限のデータだけを持つのが良いでしょう。

Amazon EFS

NFSサーバのようにファイルを共有できるEFSというサービスがあります。単純なストレージコストとしてはEBSより高くなってしまいますが、複数のサーバからファイルを共有したい場合には候補となります。

どれを使えばいいの?

基本的にはデータの格納先としては

  • S3を第一候補とする
  • アクセスが稀であればGlacierおよびGlacier Deep Archiveを検討
  • ファイルシステム上で共有したい場合はEFSを使用
  • それ以外はEBS

という選択が良いでしょう。

割引オプションを利用する

AWSには、起動しているEC2などの料金を節約するためのオプションがいくつか存在します。

Amazon EC2 リザーブドインスタンス & Savings Plans

ある程度長期間サーバを起動することが見込まれる場合には、リザーブドインスタンスを検討すべきです。ある程度予測がきくワークロードであれば、最初から検討しても良いでしょうし、ある程度サービスを運用してみて、あたりが付いた時点で導入しても良いかと思います。

長期間利用することを約束する代わりに、割引を受けられるというのがリザーブドインスタンスのメリットではありますが、Availavility Zone(以下、AZ)を指定したリザーブドインスタンスは、インスタンスを起動する権利(キャパシティ)を確保することができるのもメリットの一つです。

というのも、通常の起動(オンデマンドインスタンス)や、後述するAmazon EC2 スポットインスタンスの場合、AWS上に対象の余剰リソースがない場合には起動できない可能性があります。そのため、確実に指定した台数のインスタンスを起動したい場合はキャパシティ予約を行う必要がありますが、AZのリザーブドインスタンスを購入すると同時にキャパシティの予約ができます。

※なお、キャパシティ予約はリザーブドインスタンスなしでも可能ですが、リザーブドインスタンスと組み合わせたほうが安くなります。

リザーブドインスタンスに加えて、最近追加されたオプションがSavings Plans です。リザーブドインスタンスは、インスタンスサイズやリージョンやAZなどを指定して割引を受けますが、Savings Plansはその制限がなくコンピュータ処理能力に対する課金額を対象とするので、
EC2だけでなく、AWS FargateやAWS Lambdaにも適用できるなど、より柔軟な割引を受けることができます。

スポットインスタンス

AWS上の余剰リソースを格安で利用できるオプションがスポットインスタンスです。

利用期間や利用額を前提とすることなく、通常よりもかなり安くインスタンスを利用できるオプションですが、注意点があります。

まず、余剰リソースを利用できるオプションなので、対象のインスタンスタイプに空きリソースがない状態では起動することができません。

加えて、サーバが勝手に停止されてしまう可能性があります。そのため、途中で停止してしまっても、リカバリが可能なワークロードでのみ使用するほうが良いでしょう。例えば、Amazon EMRに代表される分散処理基盤上のタスクノードとしての利用は最も適した利用法です。Hadoopのような分散処理基盤のフレームワークには、ノード故障などに対してリカバリーをする仕組みが備わっているので、意図しないタイミングでいくつかのノードが停止されても処理をリカバリーすることができるようにデザインされています。

また、停止される場合に、通知を受けられるので、通知を受けたらELBから切り離すなどの仕組みを作ることで、APIのバックエンドサーバとしても利用することも可能です。

ただし、全てをスポットインスタンスのみでアーキテクチャを組んでしまうと、余剰リソースがない時にすべての処理が停止してしまうことになってしまうので、最低限欲しいリソースについてはリザーブドインスタンスを組み合わせて利用するなどしたほうが賢明です。

要求される可用性を見極める

PoC(概念実証)用の環境など、高い可用性を要求されないケースはあると思いますが、本番用の環境であっても可用性を多少犠牲にして、コストを抑えることも戦略の一つとしては考えられます。

例えば、大規模災害を想定して、BCP(事業継続計画)のためのDR(ディザスタリカバリ)として、
別リージョンにデータなどを配置することはよく行われますが、その際にも、いくつかの戦略が考えられます。

  • 別リージョンに同様の可用性をもった環境を起動しておき、常に冗長構成(Active/Active)で稼働させるマルチサイト
  • 別リージョンに最低限稼働する環境を起動しておき、障害が発生したタイミングで切り替えるウォームスタンバイ
  • 別リージョンにデータベースのレプリカを起動しておき、障害時に他の環境を構築してサービスを継続させるパイロットライト
  • 別リージョンにデータベースのスナップショットを定期的に送っておき、障害時に他の環境を構築してサービスを継続させるバックアップ/リストア

などです。

上から順番に可用性は低下しますが、かかるコストは低くなっていきます。

ただし、
ベストプラクティスとしてはサーバなどのリソースを冗長化させることで可用性を確保するのが推奨されます。「障害の可能性が低いから大丈夫だろう」という希望的観測で可用性を犠牲にするのはやめたほうが良いでしょう。「発生する可能性があるものは将来必ず発生する」という前提のもと、対処策を考えた上で、可用性とコストを天秤にかけるべきです。

サーバレスを積極的に利用する

クラウドならではのコスト削減策の極意はサーバレスです。

AWSに限らず、クラウドベンダーは従量課金をメリットにあげていますが、EC2/RDSなどのサーバを起動している場合、サーバを起動しておくだけで処理を行っていなくても料金がかかってしまいます。もちろん、それを100パーセント常に使っているのであれば良いでしょうが、常時余分にリソースを確保するケースが大半でしょう。サーバレスなサービスを利用することで、その余分なコストを最適化できます。

サーバレスの明確な定義は難しいですが、特徴としては、

  • 実行基盤としてのインフラ管理を意識しない(サーバがないわけではなくサーバを意識しない)
  • 使用料に応じた柔軟な課金体系

が挙げられると思います。

その典型がLambdaです。Lambdaはイベントドリブンな関数実行サービスなので、実行に応じて課金されます。なので、リソースを余分に確保するためのコストを削減できます。

Amazon API Gatewayを利用すれば、RESTなAPIのバックエンド処理としても実行できます。EC2をAPIのバックエンド処理として利用する際には、冗長性を考慮するとELBも基本セットになりますが、
API GatewayとLambdaとを利用して構築することで、EC2のコストだけでなく、Elastic Load Balancing(ELB)のコストも削減することができます。

Lambdaと組み合わせて使うのに最適なサーバレスなNoSQLデータベースがAmazon DynamoDBです。DynamoDBは、RDSやAmazon ElastiCacheと違って、インスタンスという概念がありません。キャパシティユニットという性能を決めるための設定値とデータの保存量に応じて課金されます。キャパシティユニットやテーブルのキー構成などをワークロードに合わせて適切に検討すれば、コストメリットを享受できます。

また、オンデマンドキャパシティという事前にキャパシティユニットを指定する必要がないオプションやリザーブドキャパシティという最低限の使用量を約束する代わりに安くなる割引サービスもあるので、合わせて検討すればよりコストメリットを高めることができます。

もちろん、なんでもかんでもサーバレスがいいかというと、決してそうではありません。

Lmabdaは実行時間などいくつかの制約もあるので、ワークロードでLambdaの利用が適切かよく検討する必要があります。DynamoDBもRDBMSや他のNoSQLを代替するものではないので、用途の向き不向きがあります。

とはいえ、基本的な考え方としては、
「サーバレスな構成にできないか」をまずは検討することで、コストの削減をできる可能性は高いと思います。

最後に

以上、AWS上でコストを考慮した設計を行う際の勘所でした。もちろん、この他にもAWSにはコストを削減するための便利なサービスや設定がたくさんあります。それらを有効に活用することで、多くのコストメリットを得られることでしょう。

連載第二回はこちら:雲の呼吸 弐ノ型~AWS設計の勘所:マネージドサービス・前編~

浅田さんのご紹介: AppiritsのAI研究者が『2020 APN AWS Top Engineers』に選出!資格取得に対する取り組みを紹介!

【お前ならできる!】人生を自分の思うがままにする方法

0

株式会社アピリッツ データイノベーション部の佐藤と申します。

今回私からは技術系の話ではなく、

人生を自分の思うがままにする方法

についてお話しさせていただこうと思います。

※決して怪しい情報商材の類ではありませんので、どうぞ暖かい目でご覧ください。

関連:「チャレンジし続けてさえいればきっと成功する。私が証明します」TECH CAMP(テックキャンプ)出身、佐藤さんの場合


 

はじめに…

私は、アピリッツに2020年5月18日に入社した新人エンジニア(30才)です。

前職では某パン屋で店長として勤めており、
当初はプログラミングの"プ"の字も知らない程の人間でした。

そんな私はどうしてプログラミングを1から勉強してまでエンジニアを目指そうと思ったのか、
また転職をするまでの学びから、
“人生を自分の思うがままにする方法”についてお話ししていきたいと思います!


 

飲食での働き方が私をエンジニアの道へと導いた!

前項でも記しましたが、私は前職パン職人をしておりました。

みなさんはパン屋さんにどんなイメージを持たれているでしょうか?

  • 「毎日美味しいパンの香りを嗅げて幸せ」
  • 「人に幸せを届ける仕事」
  • 「制服が可愛い」

などなどキラキラしたイメージがあると思います。

確かにこれら全て間違っていることはありませんが、
業界の裏は結構泥臭いものです。。。

毎朝4時に出社して、生地仕込みから始めて、7時には開店。
営業中はひたすら製パンと接客に追われ、
手が空けば新商品の考案や、材料発注などの事務業務。
それに加え店長は店舗と従業員のマネジメントも行って気付けば帰宅は21時近く。。。
もちろん休日も気が休まることなどなく…と、
別にパン屋のネガティブな一面をつらつらと言いたい訳ではないので割愛。

私はそんな激務であってもパン業界が好きでした!
製パンは楽しいですし、
自分の作ったパンでお客さんが喜んでくれた時の喜びは一入です!

しかし、そんな想いも日々蓄積された疲労やストレスには抗えませんでした。
私を含む従業員は華やかなパン屋のイメージからどんどんかけ離れていきました。。。

パンを通じてお客さんに幸せを届けるはずの我々が幸せでなくてどうする!?
このままではいけないと、

“この働き方を変えたい”

そう思いました。

 

じゃあ働き方を変えるにはどうするか?と普段の業務を振り返った時に、
もっと人が考えることや、動くことを減らせれば良いのでは?と考えました。
人生初私がITソリューションを考えた瞬間です。

「世間は様々な分野で自動化が進んでいるのに、
うちのパン屋めっちゃ人力じゃん!?」と気付いたのです。

今考えるとその時の私は時代に取り残された猿だったのだと思います。。。

 

「あいてぃー化、これで勝つる!!」

と思ったのも束の間、

「でもあいてぃー化ってそもそもどういうもので、どこから始めれば良いんだ??」

という疑問で頭がいっぱいになりました。

 

手立てが見つかっても、それを駆使できなければ意味がない。

ショックでした。。。

「こうしたい!」という想いを、自分のチカラではどうすることもできない事実に。

 

そんな時ふと人生の師である上司の言葉が頭を過ぎりました。

「お前ならできる!」

その方は私が仕事で失敗して挫けそうになった時や、
新たなことに挑戦する時に、いつもそう言い続けてくれました。

私は単純なので、そう言われる度に挫けそうな心を再起させては

「自分ならできる!」

と更に自分に言い聞かせて苦難を乗り越えてきました!

 

そしてその時も違わず私はこう考えました。

「今回だってできるのでは?自分がITを操作することも!」

不思議と根拠なくそう思って、気付けばパン屋を退職し、
プログラミングスクールに入校手続きを踏んでいた自分がいました。

 

「おいおい!そんな急展開ありかよ!?」って声が聞こえてきそうです。
自分でもそう思います。

何も当てがある訳でもありませんでした。
それなのに急に退職を申し出て、身内にはかなり心配をかけたし、
同僚にもかなり迷惑をかけてしまいました。。。

でもこの行動こそが、今回の話のきっかけに繋がるのです!


 

他責思考は想像以上に人生を生きづらくする

前置きが長くなってしまい、すみません。
ここからが本題です。

この記事の主題である

“人生を自分の思うがままにする方法”についてですが、それはズバリ…

“自責思考を持つこと”です!

自分で決めたことによる結果、その責任を全て自分が持つ。
ただそれだけ。でもこれって意外と難しいです。

人は結構無意識に他責思考になってしまっていること多いです。

では、他責思考とはどういうことでしょうか?

(また私の過去話になってしまいますが、、、)

パン屋に就職したばかりの頃の私は、製パン学校に通っていた訳ではないので、
先輩にパンの作り方を1から教わり、私はそれを忠実に守っていました。

だけど焼けて出てくるパンはどれも失敗ばかり。。。

何度やっても何度やっても同じ結果でした。

その度に私は店長に怒られていて、正直不服でした。

「こっちは言われた通りにやったのに!教え方が悪いんだろ!」って思ってました。

そんなこと考えながら仕事していた中で、
店長にある時こう言われました。

「こうしなさいと先輩に言われたかもしれない。
だけど、それを”その通りにやる”と決めたのは佐藤くんだよね?
だからその結果の責任はあなたにあるんだよ。」

この言葉を聞いて、最初は理解ができず少しモヤッとしました。

でも、次第にこの言葉の意味に気付いてきたんです。

 

私はパンの作り方を教わる時に見ているはずなんです。
先輩がパンを作る一通りの動作を。
それなら素人なりにも考えることができたはずなんですよね。

どうすればもっとうまくできるのかを。
ただ教わった通りにやるのか、
失敗する度により良い方法を考えて行うのかは私が選択してきたことなんですよね。

だから「言われた通りにやったから責任問われないよね」なんていうのは、
子供の言い訳に過ぎなかった訳ですね。

 

誰かにこうしなさいと言われたから。

これが良いとみんながそう言っていたからやった。

だからその結果は私の責任ではない。

これが他責思考です。

 

他責思考であるということは、

他人に決められた人生を歩むということ

他人の「こうしなさい」「これが良いよ」という言葉に反射的に反応して、
結果失敗すると「〇〇さんがこう言ってたから」と着地する。

これでは人生を思うがままになんてできません。

 

誰かに言われたから” やった”。

しかし、それを”やる”という選択は自分で決めたものであること。

その結果、責任は全て自分で負う気持ちで在る。

これこそが“自責思考”です。

 

この思考があってこそ、

自分がやりたいことを選択し、自分で考えて行動する。

結果“人生を自分の思うがままにできる”に繋がるのです!

 

私がエンジニアを目指した時もそうでした。

周りからどんなに反対されようと、
私は自分の進みたい道を自分で選択して、全て自責思考で行動してきました。

技術的にはまだまだな面が多くありましたが、
その中でも私の熱意を真摯に受け止めてくれたのがアピリッツでした。

結果今アピリッツでWebエンジニアとして仕事しながら、
自分の目標に向かって走っています!

 

これは結果上手くいっただけのほんの一例に過ぎないかもしれません。

時には自責思考でも失敗を招くことは大いにあると思います。

でも、

自分で決めて、考えて行動した結果なら
きっと失敗であっても納得のいくものになると思います

 

大体の大人が仰います。

「人生なんてそう上手くいかない…」

確かにその通りです!!

 

でも、

“上手くいくこと”=”人生を思うがままにする”のではありません。

失敗も含めて全部、自分が招いたことと納得できることこそが
人生を自分の思うがままにする“ということです!!

 

先にも話しましたが、
自責思考はそう簡単なことではありません。
責任を負うことは正直恐いです。

だからこそ自責思考を持ち続けようとする人を私は心から応援したい!

自分の人生を生きようと奮起する、

そんな輝く読者に私はこの言葉を贈りたい。

お前ならできる!

過去のキャリアを全部活かす!WEB業界を新たなジョブで走り始めた女性コンサルのチャレンジとは

0

「この先ずっとWeb業界で活躍したいから」そんな意志を持ってアピリッツに転職したDB部 嶋廻さんは、それまでの仕事とはちがった領域に挑戦中です。転職のいきさつや今の仕事について教えてもらいました。(2020年9月 取材)

デジタルビジネス部 嶋廻 愛子(しままわり あいこ)
2020年3月 アピリッツ入社
サッカー観戦とビールが大好き

過去のキャリアを活かし、未来のスキルを会社と一緒に考える

―― 嶋廻さんはもともとは営業職だったのですよね。アピリッツに興味をもったきっかけは何だったのでしょうか?

前職ではWeb広告の営業をやっていました。そこでの私の仕事は、売り切りのセールスや新規開拓が中心でしたので、次のキャリアではお客様とじっくり長期的にお付き合いをしてビジネスをサポートしたいなと考えていました。つまり、営業に加えてコンサルタントの仕事もできるようになりたいなと……。

ちょうどその頃に、知人の紹介でアピリッツのことを知りました。私が転職を考えていることを少し話すと「嶋廻さんはどんなキャリアをお持ちですか?」「うち(=アピリッツ)でコンサルタントやマーケティングの仕事をやってみませんか!?」と熱烈なプレゼンが始まって(笑)

人生設計や仕事のことをたくさん教えていただきました。※ 写真撮影のために一時的にマスクをはずしていただきました

コンサルタントはまさに私が希望するポジションだったので、話を聞いてみることにしました。それに、中にいる人がこれだけ熱心に自分の仕事や会社をすすめられるって、良いことだなと思ったんです。

―― たしかに、自信を持って「おいでよ!」と言えるっていいですよね。面接はどんな雰囲気で進みましたか?

いかにも「採用面接!」というような形式張った雰囲気ではありませんでした。そして私のキャリアについて真剣に考えてくれる面接でした。アピリッツの今後のビジョンや事業展望を共有していただき、そのなかで私は何ができるか、どう成長していけるかを明確にイメージすることができたんです。

たとえば「こういう事業をアピリッツでは考えているから、嶋廻さんのこのキャリアが活かせますね。そして身につけるべきスキルはこれがいいかもですね」と逆算から組み立てる感じです。私のキャリアプランを一緒に考えてくれているなと感じました。

―― 面接を経て、アピリッツに転職を決めた一番の理由は何だったのでしょうか?

チャレンジできる環境がある、これが最大の理由です。コンサルタントやマーケティングにとどまらず、自分のスキルをいろんな場面で活かせるなと思いました。私の場合、特化型というよりは幅広く色んな仕事ができるようになりたかったんです。アピリッツならディレクターにもマネージャーにもなれるなと考えました。

キャリアに向かって突き進みたい人を応援し、サポートしてくれる良い環境だなと感じました。

Web業界で生き残るキャリアデザイン

―― 嶋廻さんは「営業もコンサルタントもできるように」と仕事の幅を広げていますよね。このキャリア志向の理由をお聞かせいただけますか?

まず、私はこの先ずっと働きたいなと考えています。つまり、ライフステージに関わらずキャリアを積んでいきたい。そしてWeb業界自体が肌に合いますし、とても好きなんです。

そうなると、私の「営業」というスキルだけでは、この先キャリアの道が細くなるだろうと考えたんです。いま私は20代です。これから先、30代から40代になって、育休を取ることもあるかもしれません。そのときに営業一本だけで自分がWeb業界で働ける気がしなかったんです。

ですから、今のうちに仕事の幅をひろげ、あらゆる形で自分が活躍できるキャリアデザインが必要だとここ数年意識するようになりました。

こちらの写真は嶋廻さんと同じチームに所属する新卒の小泉さんが撮ってくれました。

―― まさに「目的から逆算して」いまのキャリアを選んでいるのですね。

そうですね、逆算してプランを練る行為は、ちょうど今私が新しく挑戦している「アートディレクター」の職務と似ている部分があります。スケジュールや目的を常に念頭に置いて、ゴールを逆算しながらタイムラインを組み立て、仕事をすすめる感覚を磨いている最中です。

そして、仕事の流れの中では、マーケティングの仕事で数字の分析を一日中おこなう日もあるんです。なので分析能力についても今後さらに伸ばしていきます。「いつか身につく」なんて悠長なことは言っていられないので毎日緊張感がありますね。

―― 充実していますね。入社して半年経ちましたが、アピリッツのチームメンバーはどんな印象ですか?

「引き継ぎ」がとても丁寧なので驚きました。だから新しい仕事にもチャレンジしやすかったです。新卒の子も案件に加わりはじめていますが、コミュニケーションを丁寧とって進めている印象です。「いっぱいいっぱい」になる前に周囲が声をかけています。

こちらも小泉さん撮影です。たのしそう。

仕事の幅が広がればずっと働ける

―― これからどんな仲間と一緒に働きたいですか?

「素直」な人がいいなと思います。これは自分自身への戒めもこめて……のイメージですね。「やってみない?」とチャンスが目の前にあらわれたときに、「やってみよう!」と思える人と働きたいです。苦手意識のあることを一度だけでもいいからチャレンジする人がいいなと思います。

私の場合、ディレクションには最初から抵抗がありませんでしたが、ずっと数字をみて分析をおこなうことには苦手意識が少しありました。

―― 苦手意識のあることに実際に挑戦して、いかがでしたか……?

幸い、前よりは苦手じゃないです! 仕事の幅が広がったなと感じています。やっぱり仕事の幅を広げるって、男女問わず、キャリアを考える上でとても大切なことです。もともとの営業のスキルや経験の貯蓄だけでは、数十年先まで自分が第一線で働ける気がしなくて。だからアピリッツへの転職はよいタイミングだったと思います。それに、今のコンサルとマネージメントの仕事はとてもおもしろいんです。

――「Web業界で私がずっと働くためには?」を冷静に自問自答してキャリアを築いていく嶋廻さんの笑顔がとても素敵でした。アピリッツは挑戦したい人を応援します!

AWS主催イベント“ANGEL Dojo Season2” 最終成果発表会 レポート

0

AWS主催のエンジニア向けイベント”ANGEL Dojo Season2″の最終成果発表会が先日おこなわれました。アピリッツからは新卒を含む若手エンジニア5人が参加し、3ヶ月間、疑似プロジェクトの立ち上げから開発までを体験しました。最終発表の様子と、3ヶ月の振り返りをお伝えします。(2020年9月 取材)

あらためて”ANGEL Dojo Season2″とは?

AWSが主催する若手エンジニアを対象とした開発イベントです。クラウドを活用したモダンなシステム開発手法やAmazonの文化を実体験できます。企画の立案から開発、そしてプレゼンまでを参加者のみで行います。

アピリッツが今回”ANGEL Dojo Season2″へ参加した経緯やメンバーの選出基準については、西脇執行役員の記事を御覧ください。

関連:出てこい!AWSネイティブ世代 ~若手エンジニアがAmazon Web Services 主催 ANGEL Dojoに参戦!~

参加者は、通常の業務を進めつつ、AWSによる週2回の講義を受け、毎週金曜の10時から18時をワークDayとし、疑似プロジェクトに取り組みました。

関連:新卒も参加中! AWS主催 “ANGEL Dojo Season2” 若手エンジニアインタビュー

こちらの最終成果発表会が9月4日に実施されました。今回の発表会はオンライン開催。カメラに向かってメンバー全員が「どんなものを作ったのか?」「なぜ作ったのか?」「どう作ったのか?」を、スライドとデモを交えつつ伝えました。

発表当日のアピリッツはこんな感じでした

アピリッツのチームは参加メンバーの5人全員でパートをわけて、それぞれが発表しました。

最初に「ばばーん」と盛り上げたほうがよくない? もう一回練習する? デモ画面の大きさはこれで伝わる? わかりやすいプレゼンにむけて、本番までにブラッシュアップを重ねました。

AWSのメンターの方からもアドバイスをいただきつつ、プレゼンに臨みました。

アピリッツの5人が作ったサービスは “こまっち”

アピリッツはトップバッターとして発表しました。

5人が企画・開発したのは“こまっち”というマッチング質問サービスです。サーバレスで動作するシステムで、「誰に質問したらいいんだろう?」と困っているシャイな人を助け、業務とコミュニケーションをより良くします。

開発の経緯については、彼らの実体験も込められています。参加メンバーで新卒入社の小林さんが「入社後すぐにリモートワークになり、先輩や仲間の顔もまだ知らない状況だった。だから、こんな質問していいんだろうか? と、どこか遠慮してしまっていた」と説明していたのが印象的でした。誰かの遠慮する気持ちを後押ししたい! というメンバーの思いが伝わるプレゼンでした。

開発者ではない人にもわかりやすい、とてもフレンドリーで、優しい内容でした

AWSの方からは「こまっち良い! 名前も良い! プレゼンもGoodでしたね!」という感想をいただきました。

質疑応答タイムでも「質問のデータ蓄積」や「相談相手が見つかるまで探し続ける機能」について質問をいただきました

こまっちの開発にまつわるトピックスは、今後アピスピで “ANGEL Dojo Season2” の開発者自らがご紹介する予定です。お楽しみに!

開発者の渡邊さんのレポートはこちら!
関連:ANGEL Dojo Season2 アピリッツチーム 成果発表

「自分たちがやりたいことは、課題を解決すること」

今回、惜しくも受賞は逃しましたが、この3ヶ月で得られたものはたくさんありました。ずっとプロジェクトを見守ってきた西脇執行役員と、アドバイザーとして参加したAI Laboのエンジニア 浅田さん、そして参加メンバーの五人に話をききました。

―― アピリッツにとっての “ANGEL Dojo ” 、いかがでしたか?

西脇:まず、限られたスケジュールとリソースの中で、きちんと着地しきっているので良かったなと思います。

浅田:そうですね。限られた時間の中でうまく折り合いをつけて「ユーザが持つ課題を解決する」という実現すべき価値に取り組めたのではないかと思います。

最初はWebアプリケーション想定だったのを、途中からSlackのBotに切り替えたというのも、ユーザが使いやすいインターフェースで、課題を解決するために最適な手段は何かを考えた結果だったと思います。

つまり、みなさん「自分たちがやりたいことはアプリケーションを作ることではなくて、課題を解決することなんだ」という思いを持って取り組めたんですよね。

そういう意味では、AWS(Amazon) が大事にしているWorking Backwordsという考え方をうまく吸収できているんじゃないかな、と思いました。

DI部 吉岡:今回、Amazonが提唱する価値観のうち、 ”Ownership”、”Learn and Be Curious”、”Deliver Results”を大切にしてほしいと教わりました。この3つは、開発の経験を積むうちに重要性がわかります。まだ経験の浅い若手が、ごく早いタイミングでプロジェクトを通して実感できるのはよかったと思います。

―― アドバイザーから見て、ANGELsのみなさんは開発中どのような印象でしたか?

浅田:一人ずつ言っていきますね。まず柴田さんは技術センスが素晴らしいと思いました。本人は謙遜してますが、StepFunctionsをさくっと組めたのは素晴らしいと思います。

渡邊さんはリーダーシップが素晴らしかったです。ふだん持っている業務がバラバラのチームメンバーをうまくまとめあげていたと思います。

そして吉岡さん。プレゼンの資料作成や、プレゼンの仕方が素晴らしかったです。

小林さんは、(大久保さんもそうですが)新卒でほとんど開発経験もない中で、うまく開発に協力できていたと思います。本番発表で「ばばーん!」と一発かませる胆力がすごいです。

そして大久保さん。「EC2で構築する」という流れができつつあったなか、「本当にそれが最適な構成なのか?」と疑問をもって、切り込んでいった姿勢が素晴らしかったです。あれがなければ、いまの”こまっち”は別の姿になっていたと思います。

「次もあるならアドバイザーなど何かしらの形で関わりたい」

発表後すぐに「このあと、どうしたい?」という話になりました

西脇:このプロジェクトが終わって、みなさんがこれから先の仕事でどう関わっていくかが聞きたいですね。個人的には、社内外のエンジニアとつながれる人となってほしいです。

DB部 渡邊:5人全員が「実際に使える、売れるプロダクトを完成させたい」と思っています。

MS部 大久保:自分たちでゼロから作った企画なので親心のような気持ちが芽生えました。私ももっと開発に携わりたいですし、今後もしSeason3があるなら、アドバイザーや何かしらの形で参加したいです。

DI部 小林:AIの力を借りてマッチングを最適化できれば、“こまっち“はもっと魅力的なアプリケーションになると思いますし、そこを考えるのが面白い。そして、先輩3人がやってくれていたところを、大久保さんとキャッチアップしたい。

西脇:みんなをまとめる仕事とかもね、はやいうちに経験するといいですよ。

DI部 吉岡:このサービスをいつか使ってもらいたい、とにかく、その気持ちが本当に強いです。

DI部 柴田:もし続けられるなら、ゆくゆくはいろんな人に参加してもらって社内の技術向上にもつながるプロジェクトにしていきたいです。

西脇:実現できるといいですよね。全力で応援しますよ!

……ということで、”ANGEL Dojo Season2″は無事閉幕しましたが、いつか続報をお伝えします! 参加者のみなさん、本当におつかれさまでした。

「組織もスキルも自分自身の壁をも超える。求ム、突破型DX人材」 執行役員 兼 DB部部長 長谷亘インタビュー

0

アピリッツの執行役員 兼 デジタルビジネス部・部長の長谷さんに、これまでの自身のキャリアと、これからアピリッツをどう成長させていきたいかを語っていただきました。どちらにも通じるキーワードは「垣根をこえようとする意志」です。(2020年 9月 取材)

エンジニアの会社にアナリストとして2008年新卒入社。0からのスタート

―― 長谷さんは新卒でアピリッツに入られたのですよね?

はい、2008年にアピリッツ(当時の会社名はKBMJ)に新卒で入社しました。当時は「Web2.0」といった言葉が流行った時代でした。懐かしいですね。SNSやブログ、ロボット型の検索エンジンなどのサービスが生まれては消えていく……慌ただしい時代だったなと思います。

私のキャリアですが、1~2年目は「アナリスト」です。アクセス解析ツールの環境を整備し、Webサイトの分析レポートを作成する職種です。その頃はアクセス解析ツール自体が有料で高価だったので、会社に導入するハードルが高く、珍しい職種でした。

さらに、当時の弊社はエンジニアによる開発業務がメインでして、アナリストは社内で私1人。つまり、サービスも、育成も、キャリアデザインも、何をするにも自分で考える必要がありました。

―― 会社初のアナリストとして、キャリアパスをゼロから考える必要があったのですね

そうですね。お客様のニーズに応え続けるために、周辺スキルの何を学び、実践し、ノウハウとしていくか。これを繰り返し考えるわけです。

で、次は「マーケター」を目指します。データを駆使することはアナリストと同じですが、お客様の課題や市場を理解し、Webマーケティング全般の知識と技術を活用してお客様のビジネス価値を上げるのがミッションです。

当時の時代背景を考えると必要な職種でした。ちょうどリーマンショック後で、IT・システム開発への投資に対して慎重な風潮だったのです。ですから、マーケティングの視点で費用対効果を示し、継続的に使えるシステムとして柔軟性や拡張性が問われていました。

そのため、理想論を提言して終わりではなく、お客様のニーズに合わせ、自社のリソースを使って実現可能かつスピード重視の提案を心がけていました。その流れで次の工程であるWebデザインの設計、進行管理・品質管理・制作などの「ディレクター」としての業務も担うことになります。

入社2~4年目の間は「マーケター」と「アートディレクター」を主な職能としていましたね。

マーケティングからデザインまでを繋ぐ一連のサービス提供が十八番

プロフェッショナルとゼネラリストの2つの道が交錯するキャリア

―― そこからは、現場の中心をはなれてマネージャーになったのでしょうか?

いえ、そうでもなくて。これが私のキャリアの少し複雑なところなんです。いわゆる職能(プロフェッショナル)といわれるスキルを積むことと、組織を作る(ゼネラリスト)としての経験が並行で進んでいました。

これは1年目のアナリスト時代から始まっていまして、同期2名を自分のチームに加え、サービスメニューを作り、営業を行い、同時にチームメンバーへの教育も行いました。事業の苗を育てていたのです。

―― あらゆる方面を同時進行で進めていたと?

そうですね。私のキャリアの強みはそこだと考えています。「縦と横の動きが激しい」。つまり、プレイヤー、ゼネラリストという「縦軸」。そして営業、マーケター、ディレクター、デザイナーという「横軸」。このすべてと関わってきました。

マーケターとしての仕事ではデザインの制作と設計が施策として一番実行しやすい。そうなると「デザインの仕事もアピリッツに発注したい」と言ってくださるお客様も増えてきて、デザインの仕事も増えます。

当時のアピリッツでは、デザイナーは、あくまでプロジェクトに点在しており明確なチームはありませんでした。そこでマーケティングの観点をデザインに込めることを強みとしたデザインチームを作り、そこの営業とディレクターを担当、入社4年目に部長代行、5年目からは部長、といった感じで動いています。

当時はがむしゃらで、とにかくお客様のニーズにお応えするために、そしてIT業界で自分がやりたいことを実現するために、気が付いたらチームメンバーが増えていきました。そして、多くの方にご協力頂きました。縦軸と横軸を行き来していたからこそ得られたチャンスだったと思います。

マーケティング・デザイン・エンジニアを繋げることが自社の強さを引き出す

―― 縦と横に広がるので、仕事の幅がどんどん大きくなるのですね

そうですね。今も昔も共通する私のスタイルは、お客様のニーズに応えるために必要なスキルを学び、サービス化し、チームを作り、営業をすることです。お客様のミッションをまっとうするために必要なプロフェッショナル集団を作ることでもあります。

例えば、お客様がWebで作りたいビジネスを実現するためには、「抽象的な要望」を「具体的な要件と仕様」に翻訳していくことが大切です。ここが難しく、ゆえに市場価値の高い工程です。

この翻訳ハードルが下がれはプロジェクトは効率化し、ミッション達成率も高くなりますよね。では、どうすればいいのでしょう?

答えはシンプルで、①ビジネス要件はマーケターが支援、②それをサービスとして目に見えるデザインにして翻訳、③システム側が読み取り、本来の力を十分に発揮してもらう

とてもシンプルです。ただ、これが簡単にできない。プロジェクトマネジャーの経験値や業務スキルも重要ですが、一番必要なのは「垣根を越えようとする意志」です。マーケティング・デザイン・エンジニアを繋げるパーソナリティが大切だと私は考えます。

長谷さんのキャリアパスをご自身で図解してもらいました

自分の役割を限定せず、別の職種のこだわりに興味を持つ

―― そういった素養はどうすれば身につくのでしょう?

とにかく「自分の役割を限定しない」ことが大切です。また、その職種や個人が持つ「こだわり」を理解し、コミュニケーションを行う能力も必要です。

極端な例を出しますと、「営業だから受注したら役目は終わり」、「デザイナー(エンジニア)だから、お客様のビジネス要件にはタッチしない」、「自分の考えたマーケティング施策が最上。あとは実現せよ」という姿勢では、お互いがけん制したり、言わなくてもわかっていると思っていた等、プロジェクトがミスコミュニケーションの巣窟になります。

そういうときは、自分も成長しづらく、プロジェクト内の課題も霧がかかったように見えづらい。一方で、そういう時ほど他人のミスは目につく……よくある負のスパイラルですよね。

―― 長谷さんご自身もそういった課題をもっていたのでしょうか

はい、もちろんです。私自身も垣根を突破しきれていません。

部長になった後(5年目~9年目)、次第に案件が増え、規模が大きくなり、コンサルタントとして提案できる幅が増えました。ただ、デザインまでの提案が多かったんです。開発の提案を加えることが少なかった。

これは意図的ではないですが、プロジェクトの中で、自分が把握できない業務が存在することに慎重になっていたのだと思います。つまり、自分のチームしか考えていなかった。会社に所属しているようで、会社の長年の実績や強さに背を向けていたのですね。

しかし、この課題は解消しつつあります。社内には多様な経験を持つ経営陣やプロジェクトマネージャー、ビジネスプロデューサーがいます。見本となる方々の思考と仕事に触れることで視野を広げることが出来ました。

もともと、会社の特性上エンジニアと一緒に仕事をする機会は多く環境はそろっていました。あとは自分自身の悪癖を理解し、突破するだけでした。

過去の自分らしさを捨てていける勇気が、DX時代では求められる

―― 自問自答の結果が現在のデジタルビジネス部でしょうか?

はい、まさに。開発チームをデジタルビジネス部に加え、お客様のミッションを共に達成するパートナーとしてのあり方を1つ実現できたと思っています。

ただ、まだまだ組織づくりの半ばではあります。2020年から担当している自社プロダクトであるSaaS事業の加速はこれからです。

10年目の2018年からは執行役員として職種の垣根を超えて、開発との融合といったミッションも担っています。自部署内での経験が、社内のマーケティング、デザイン、システム開発を一体化させたプロジェクト推進の架け橋となるべく動いています。

―― 他のメンバーにも長谷さんと同じような「縦と横を行き来する人」となってほしいですか?

はい、急募してます。正直、Web業界では様々なスタイルで働くことができるとは思いますが、会社のスローガンでもある「セカイに愛されるインターネットサービスをつくり続ける」を実現するために必要です。

もちろん、ひとつを深めていくことが自分らしさという人もいます。良いと思います。ただ、「過去の自分らしさを捨てていける勇気を持ったヒト」と働くとワクワクしますね。

なぜか。自分の仕事だけじゃなく、隣の仕事に興味をもって、色んな人と話せるようになると、プロジェクトの霧を晴らすことができるんです。自己成長のチャンスも訪れるはず。結果、それが自分らしさを更に引き立てることになる。素敵だなと。

私たちの会社を求職者の方に説明する際は「垣根をこえてチャレンジできる環境です」と言います。それは、自分自身が体現出来ているため自信をもって話せますし、社内で活躍する方もこの特徴を備えていますので事実です。

ですが、環境だけでどうにかなる話でもないんです。環境に加え、自分自身のパーソナリティと向き合い、それをどう克服するのかを自問自答することが大事かなと。

―― 長谷さんの「未来に向けた自分らしさ」はどのようなところだと思いますか?

悩みますね(笑)…そうですね、「この変化の激しいIT業界の荒波を悠々自適に乗りこなして楽しむ!」ってのができたら自分らしいかもですね。

業界として一般的になって長い「UX=ユーザーエクスペリエンス」という言葉があります。この魔法ワード、実は必要なスキルは明確なのです。それは、ビジネスとデザインとテクノロジーが重なり合ったところにあると言われています。

ですから、ビジネスに限らずデザインにも興味を持つ、テクノロジーでビジネス要件をどのように解決するかを考える、デザイナーがフロントエンドエンジニアの技術領域もできるようになる……。

こんなふうに垣根をこえて、2つ以上の専門ジョブを持つことができる方は、Web業界で需要が高い。と、同時に近年ではDX推進(デジタルトランスフォーメーション)を行う人材に求められていることでもあります。バイタリティをもってこの業界を渡り歩く武器となりえます。

どの時代においてもそんな人物像であることを確信しながら日々を楽しめると「自分らしい」と言えるかもしれません。

ビジネスとテクノロジーとデザインの重なる領域について触れたダイアグラム
引用:Oliver Reichenstein | flickr

社内のあらゆる壁を突破し、アピリッツのビジネスをデザインしたい

―― 執行役員として今後どのようなビジネスを形にしたいですか?

前提として、アピリッツにしかできない強みを社内に作り、世の中に向けて表現・提供することで企業価値を高めていくというのがあります。それを実現するために、業務の垣根を超え、組織のセクショナリズムを突破することでしかできないビジネスをデザインしたいですね。

いくつかある1つに、ゲームデザインの要素をWeb業界のビジネスに転用することを経営陣で考えています。「ゲーミフィケーション」といった概念の活用です。オンラインゲーム内でユーザーのモチベーションを向上させるといったゲームデザインのノウハウをサービス展開するのも良いですね。

社内外、事業、職種といった垣根を超えた先でしか表現できないサービスやプロダクトのアイデアは、周りに転がっている。こういったビジネスの種を仲間たちと一緒に企画・設計して、サービスページや営業媒体を作って、ビジネスに関わるデザイン全般を支援していきたい。

―― 最後に、長谷さんの思い描くビジネスを、どんな仲間と達成したいですか?

時代の変化も加速してきており、DX推進(デジタルトランスフォーメーション)がより一層求められてきています。そのため、スピード感をもって世の中の変化に追いつけるようなマインドを持った方と歩みたいですね。周りがガンガン動いているときって自分もやらなきゃって思いますよね。そういった相乗効果のあるチームを作っていきたいです。

また、チームリーダーの方には、自分でサービスを作る面白さを知ってほしいですね。アピリッツの職位にあるグループマネージャは中間管理職なんですが、弊社の環境も相まってとても面白い仕事です。自分が先頭に立って、やりたいビジネスを実現できて、現場で体験できるんです。そういうチャンスを一緒に掴む人を求めます。

社内アイデアをビジネスとしてデザインし、世の中に広げていければ、もっとアピリッツは成長しますし、意欲のあるメンバーのキャリアも築いてゆけます。組織、スキル、そして自分自身の壁をも突破して、横断的な動きでアピリッツの強みをつくり、発信していきたいですね。

―― 「自分らしさを捨てていける勇気」という言葉が印象的でした。アピリッツにはチャンスがたくさん待っていることを考えると、大切な姿勢ですね。またお話を聞かせてください。今日はありがとうございました!

長谷 亘(Wataru Hase) 
執行役員 兼 デジタルビジネス部部長
2008年にアピリッツに新卒入社。アナリスト、マーケッター、アートディレクター、営業、セミナー講師を経てマーケティング・デザイン事業を立ち上げる。300サイトを超えるデータドリブンに尽力し、ビジネスデザイナー、マーケティングコンサルタントとしてお客様のビジネス拡大に従事。 趣味はロードバイク(東京湾一周、琵琶湖一周など)と、エンタメ料理(キャンプ場でラーメンの麺からこねて、ガラと背油でスープをつくる)。

関連記事:アピリッツのその他の役員インタビュー

Unity作業が捗る便利設定3選 ~ちりつも作業をなくしたい~

0


はじめに

初めまして。コンテンツデザイン部の松村と申します。
現在は新規プロジェクトの開発に携わっています。

〜この記事を書こうと思った理由〜
現在のプロジェクトに移動してから、コードを書くことよりもオブジェクトを操作してUnity上で画面を作っていく作業が多くなり
知っているのと知らないのとでは作業効率に影響しそうなUnityの設定」を先輩エンジニアから色々と伝授していただいたのがきっかけなのですが・・

この記事を読んで下さっている方の中で、Unity作業中、気付けば何度も何度も同じ作業をしているということはありませんか?
・・・恥ずかしいことに私はたくさんありました。


その作業自体は1分で終わるような簡単な作業でも、「塵も積もれば山となる」というように
毎日していれば月単位で数十分、年単位では数時間、またはプロジェクト単位で考えると数日分
時間を取られてしまっている、なんていう可能性もなくはないと思います。

  ちりつも作業をなくしたい(願望)。

個人的には時間だけでなく、「なんか仕組み化できそうなことを、何回も一から繰り返しながら作業する」という事実にモチベーションまで削られていました。
実際に使ってみて作業効率が体感倍くらいに上がったのはよいのですが、
効率が上がれば上がるほど、「もっと早く知ってたらな、気付けてたらな」という気持ちが大きくなっている気もするので
この先、自分のように「もっと早く知ってたら」と思ってしまう人を出来るだけ増やさない為にもここにまとめていくことにしました。

中にはもう知ってた、使ってる、そんな方もいらっしゃると思いますが
興味のある方いらっしゃいましたら、今後の業務にきっと役立てることができると思うので是非軽く目を通してみてください。

どういう時に使えるかという説明 & 簡単な図解を添えて「参考にした・または参考にできそうな記事」をシェアしていきたいと思います。

〜こんな方を対象に書きました〜

どちらかというとVisualStudioCodeなどのコードエディタよりもUnityEditorとにらめっこしている時間が多い初心者〜中級者の方
× どちらかというとUnityEditorよりもVisualStudioCodeなどのコードエディタと向き合っている時間が多い方
なんとなく分けてみましたが、Unity使う人だったら対象です。

1.プリセット作成

使用シーン:コンポーネント追加時、オブジェクト作成時
参考記事 :【Unity】uGUI のオブジェクト作成時に Raycast Target をデフォルトでオフにする方法
対象バージョン :2018.4, 2019.4, 2020.1, 2020.2
公式ドキュメントhttps://docs.unity3d.com/ja/2018.4/Manual/Presets.html

Unityで作業する際に使われないことはないであろう「Add Component」(もしくはオブジェクト作成)。
例えばTextコンポーネントを新しく追加した時に、Unityがデフォルトで色々と値を入れてくれたりチェックしてくれてたりしますよね。

UI>TextでTextオブジェクトを生成した際に、デフォルト値が入っている。

この時

「フォントサイズがよく使うサイズにデフォルトで変わってたらいいなー」

「フォントスタイルが勝手にBoldになってたらいいなー」

と思ったことはありませんか?

その思い、プリセットを作成することで実現できます。

図解:プリセットの作り方。簡単に作れます。

プロジェクトでの作業は特に、デザイン規則に則って画面デザインが出来上がっていくと思うので
毎度毎度違うフォントサイズになることの方がめずらしく、よく使うフォントサイズがあるはずです。

そのよく使うフォントサイズが、Textコンポーネントを使用する時、既に設定されてたらいちいちフォントサイズを変更する手間が省けます。
もちろんフォントサイズだけでなく、フォント、フォントスタイルなどなど、今までいちいち変更しないといけなかった分だけ省けるわけです。

一回の作業量はわずかな時間でも、積み重ねると結構な時間の削減になりそうではないですか?

特に、今のプロジェクトでやってよかったなと思ったのはImageコンポーネントのRaycastTargetのチェックをデフォルトで外したことでした。

RaycastTargetのチェックを外しておく。

Imageコンポーネントを追加した時、デフォルトではRaycastTargetにチェックが入っていますが
このチェックは必要なImageだけにあればいいコンポーネントのはず。
少なくとも今のプロジェクトではRaycastTargetが必要なImageは限られていて、不要になる(=デフォルトでついたままにしていると無駄な負荷がかかってしまう状態になる)ことがほとんどでした。

メンバー各々が「不要なImageにRaycastTargetはつけないようにしよう」と意識することももちろん大事ですが、
最初から外しておく→必要な時はつける、というにシステムにしておけば「忘れてた」ということが防ぎやすくなると思います。

2.カラーパレット(スワッチライブラリ)作成

使用シーン:Imageカラー、Textカラーなどのカラーを変更したい時
参考記事 :Unityでカラーパレットを使う

対象バージョン :2018.4, 2019.4
公式ドキュメントhttps://docs.unity3d.com/ja/2018.4/Manual/PresetLibraries.html

1で触れたことに近いのですが、プロジェクトで使うカラーバリエーションもデザイン規則に則って限定されていませんか?
その為何回も同じカラーを使うことってよくあると思います。
(少なくともその時のノリでイメージカラーがコロコロ変わるということは稀なはず・・。)

フォントやイメージのカラーを変える際に、デザイナーさんから指定していただいたカラーコードが書いてあるメモを探して、そのコードをコピペして・・・という時間、ちりつもです!

ちりつも警察

カラーパレットを作成して、必要なカラーを選択するだけの状態にしてしまいましょう。

図解:カラーパレットの作り方

ついでについてくるいいこと:カラーコードを微妙に打ち間違える、という事態も回避できる。

3.リファレンス検索設定

画像は参考記事から引用しております。

使用シーン:アセット削除する時、どのアセットがどこで使われているかを知りたい時
参考記事 :Unityでアセットの参照を高速に調べるツール【ReferenceViewer】
対象バージョン:ツールによって異なる


「このPrefab(またはTexture)使ってなさそうだから消しちゃおう」


そうやって気軽に消したものの
実は知らないところで使われていてエラーが出る、ゲームが動かなくなるなんていう経験ありませんか?

私はあります。

そんな時に使えるのがリファレンス検索機能なのですが、現プロジェクトで使われている機能は独自に開発されているものだった為、図解等の詳細は大人の事情でこちらで公開するのを控えさせていただきます。
検索してみると色々あるみたいなのでプロジェクトに合ったものを是非探してみてください。

ただ、どの拡張ツールを使うとしても目指しているものは同じ。
「安全に作業を進める」ということです。


プロジェクトに開発初期から携わっているとか、途中から参加したとか関わらず
何のアセットがどこで使われているのか、全てを把握出来ている人ってほとんどいないと思います(多分)。記憶力があるないとかの問題ではないと思うからです。

プロジェクトが進んでいく中で
「デザインが変わってこの素材は使わなくなった」「prefabを作り直した」
→削除
そういうことってよくあると思うのですが
何かを削除する際に最も大事なことは、消した影響がどこに及ぶのかを把握することだと思います(私調べ)。ですので、一発でリファレンスがわかるようにPluginを入れて拡張してしまいましょう。

少なくとも、「消しちゃったけど本当に大丈夫だっただろうか・・」「ゲーム止まらないだろうか・・・」
そんな不安が無くなります(大事)。

まとめ

先輩から伝授した知識を我が物顔でまとめてみましたが、
きっとこの仕組みを知っているだけで
何回も同じ作業をする手間が省け、無駄な時間を削減できるはずです。
浮いた時間でブラッシュアップするもよし、みんなでご飯に行くもよし、早く帰るのもよしだと思います。

もし気になった方いらっしゃいましたら是非活用してみてください。
ご一読いただきありがとうございました。

ソーシャルゲームにおけるミッション機能のサーバーサイド実装の考察:実践編

0

アピリッツ コンテンツデザイン部の金井と申します。前回前々回に引き続き、ソーシャルゲームにおけるミッション機能の話をしていきます。

関連:ソーシャルゲームにおけるミッション機能のサーバーサイド実装の考察:問題編
関連:ソーシャルゲームにおけるミッション機能のサーバーサイド実装の考察:思考編

前回までのあらすじ

 ソーシャルゲームにおけるミッション機能とは

  • 構造的に改修し辛い
  • 処理の時間が掛かり易い
  • 問題が発生した場合それが大事になり易い

 加えて実装面でもミッション機能を構成する要素が複雑に絡み合う事が多々あり、クソコードになり易い。

 それらの問題を解消する為の自分の結論としては、API単位でミッションの処理を纏めるしかない。

とうとう修正をデプロイするエンジニア

実際にやってみた

 ええ、やりました。詳しくは言いませんが、出来る環境になった事があるので。
 そして目の前には、そこそこの期間付き合ってきた、さながら油でべたつく茶色にコーティングされた換気扇を思わせるようなコードがあったので。

 さて。綺麗に出来るタイミングにせよ、やるべき事は大量にありました。上記の仕組み以外にも、

  • マスタ、ユーザーデータの構成が冗長である
  • 過去のユーザー単位で1回しか通らないバッチ処理がそのまま残っている

 等々。
 それらも綺麗に出来るのならば、一気に綺麗にしてしまいます。どうせ、全体的にコードの差分が莫大になるのは明らかなのですから。
 ただ、しかし。マスタ、ユーザーデータの構成を変えてしまえば、もうそこから先に碌な休憩地点はありません。プロジェクトを健全に保つテストコードの文句を黙らせるまでは(え、テストコードが無い? ……ご愁傷様です)。

どの程度の時間的コストになったのか

 まあ、これの為には自分の経歴も多少書いておいた方が良いと思いますので。

  • ソーシャルゲームサーバーエンジニア歴新卒4年目
  • ソーシャルゲームの開発、リリース、運営を2度経験

 端的に書くとこんな感じです。まあ、入社して3年間でソーシャルゲームの全般を2度程経験した形ですね。
 そしてこの位の経験がある自分が、使い込まれたミッション機能を根本から作り直す事には、それだけに注力した状態で1~2ヶ月は掛かりました。

 また、実際のコードの差分は3500行、80ファイル以上でした。
 馬鹿でかいプルリクですが、基本的にここまででかいプルリクというのはマスタの構造の変更等で流し読み出来る部分が多かったりするものだと思います。
 しかし、このプルリクの中身は基本的にロジックの変更になります。要するに、大半が流し読み出来ないものです。
 更に言うならば、これだけ差分が大きくなる事が予見出来ようとも、自分の場合は途中でプルリクを出す事を出来ませんでした。自分が携わっていたそのコードを改善する為には、全体の挙動そのものの改善が必要だという事が途中で判明し、1APIだけを新挙動に書き換えて一旦プルリクを出す、というようなコンパクトな事もできなくなった為です。
 まあ、はい。コードレビュー等も必要に応じて行うべきかと思いますが、これだけのプルリクを見る事が出来る人が必要ですね!

全てを終えて深い眠りに就くエンジニア

精神的疲弊

 何日も何週間も同じ事柄へのリファクタリングを続けていると、流石に疲弊してきます。

 プランナーと掛け合い、無駄や冗長を削ぎ落としたミッションの仕様を新たに殆ど一から構築し直す。
 その為に既存のコード……仕様が追加、変更された事により、まるで後先考えずに違法増築を繰り返されて巨大地震でも来れば粉々に瓦解してしまいそうなそれを必死こいて読み直し、それらを綺麗に纏め上げる。
 纏め上げる最中に不必要になった変数や新たに必要となるユーザーデータなどが発生して来れば、それらの一つ一つが本当に不必要か、必要かを吟味した上で削除、追加をしていく。
 テストコードもそのままでは失敗を叫び続けるだけであり、その新たな規範に沿って作り直すところから始めなければいけない。

 ……そんな作業の一つ一つを地道に、丹念に続けるにはかなりの労力が必要になります。更に続けていると、

 途中でどうしてこんな事に手を出してしまったのかという後悔が湧いてきたり。
 業務中に暫くぼーっとしたくなったり。
 業務終了後も帰りの電車の中でぼけーっとミッションの事を考えたり。
 夢の中でミッションのコードを弄っていたり。
 誰かのプルリクが飛んでくるとミッション以外のコードを見られる事に喜んですぐにレビューを飛ばし、そして同時にマージする時のコンフリクトの量がまた増えた事に辟易とし。

 ただ、それでも自分は精神的支柱があったからこそ出来たと思います。
 それは何かと言われると、まあ、はい。クソコードに対する憎悪、それに尽きます。

 以前はこのクソコードを根本的にどうにも出来る余裕がなかったから、余計にクソコードを追加して負荷や計算量を減らすしかなかった。
 このクソコードが分かりづらいから本番でエンバグを何度も引き起こした。
 このクソコードのせいで休日に出社する羽目になった。
 このクソコードを新しいプロジェクトでも残し続けていたらまた同じ目に遭う。
 クソコード……駆逐してやる! このプロジェクトから……一行残らず!

 そんな意志が私の最大の精神的支柱でした。
 流石にソースの全体に及ぶ程に大きい改修するのは初めてでもあったりして、挑戦するような気持ちもあったのですが、そんなものは二の次で。
 お前は存在してはいけない生き物だ、と某生き恥ポップコーンさんに告げるような絶対なる意志を用いて滅しました。

改修は本当に価値があったか?

 はい。それは断言出来ます。
 少なくとも、

  • 各所に散乱していた似たようなロジックや冗長な処理
  • 殆ど実際に動く事は無いのに常に通ってクエリだけを投げていく処理

 は巻物を投げつけられたドラゴンの如くジェノサイドされ、

  • 現状の仕様を満たす処理はそれぞれ端的に纏まった形で集約されている
  • 仕様変更に対してもそれらのみを改修する事によって対応可能

 という状態にする事が出来ました。
 デイビークロケット並の予想だにしない仕様改修依頼が無い限りは、ミッションの処理はここに集約されたままに出来ると思える位には。
 勿論、まだ怪しい部分もあります。しっかりと負荷試験をして性能を数値として出してはいませんし、改修した中でも時間の掛かる冗長な処理がまだ残っているかもしれません。
 もしかしたらそんなデイビークロケットをパンジャンドラムに乗ったプランナーから渡される可能性もあります。
 しかし、まあ、そんな仕様は来ない事を信じたいなあ……。

最後に

 この巨大プルリクを半日掛けて見て下さった先輩に感謝します。

翌週に有給を取り平日の空いている江ノ島に行き、その頂上にあると言うフレンチトースト専門店を訪れようとしたその朝に鳴る会社からの電話

Google サービスの便利機能6選 ~デスクトップアプリ、Gmail、Calendar、 検索、Google Alerts 、マイプレイス ~

0

G suitsが登場してから、公私ともにGoogleにお世話になっている方も多いのではないでしょうか。

かくいう私もGoogle沼にどっぷりハマっております。職場ではもちろんのこと、プライベートでの情報管理のメインはGoogleのサービスを利用しています。(calendar、keep、tasks、gmail…)Googleがなくなったら私の生活の情報管理は崩壊してしまうと言っても過言ではありません。考えただけでゾッとします。
以前は必要に応じて多種多様なアプリをつかったりしていた時期もありましたが、急にサービスが停止してしまったり、機種変更のために使用できなくなってしまったり。
情報管理をGoogleサービスで統一することで感じているメリットは、

①デバイスに依存しない

スマホや、PC、タブレットでもインターネット環境さえあれば誰にでも共有可能ですし、どこからでもアクセスができます。スマホの機種変更のたびにアプリの互換性を気にする必要もありませんし、夫婦でwindows派とapple派で対立しても特に問題ありません。

②サービスが停止する恐れが限りなく低い

以前使用していたタスク管理アプリがサービス終了したときは本当にショックでした。メモ代わりとしても使っていたので、過去のメモが見れなくなってしまうのを防ぐのにバックアップをとったりと、サービス終了の恐怖…。

③ユーザー数が多い

利用者も多いので、わからないことがあればググってすぐに解決できます。
今回は公私ともにGoogleサービスにお世話になっている私がよく使う便利機能を紹介したいと思います。

①デスクトップアプリっぽく使う

Googleには多彩なサービスが展開されていますが、みなさんPCで使用する際どのように立ち上げていますか?
ブラウザからGmailやCalendarを立ち上げて常にブラウザを開いている状態にしている方、いますよね?
そうすると、だんだんタブが増えていき、あれよあれよ、メール画面どこいった?カレンダーどこいった?ブックマークから新規タブで立ち上げてってやってませんか?(そしてタブは大変なことに…)
ここではGoogleサービスをデスクトップアプリっぽく使用する方法をお伝えします。

操作手順

  1. Chromeから指定アプリ(今回の場合はCalendar)を起動する
  2. ︙をクリック
  3. 「その他のツール」を選択
  4. ショートカットを作成
  5. 「ウィンドウとして開く」に✓
  6. OKを選択

デスクトップに、アイコンが表示されたら完了です。以降、ここからアクセスすることでアプリっぽくつかうことができますよ。ちなみに、インターネット環境がない状態では何も表示されません。アプリではないので。

Macの方はもちろん、dockへの配置も可能です。

② Gmail – 別名アドレスの取得

Gmailで取得したアドレス以外にも、そこから派生したアドレスも同時に使用することができます。
@以前が[ appiritsspirits ]というアドレスを例にご紹介していきます。

取得できるアドレスパターン

  • .(ドット)の有無
    例:appirits.spirits / appirits.spirit.s / api.rits.spi.rits …
  • +〇〇(〇〇以降は自由に設定可能)
    例:appiritsspirits+ad / appiritsspirits+ec …
  • もちろん上記2つをあわせたパターンも可能
    例:appirits.spirits+ad / appi.rits.spi.rits+ec …

アドレスを複数もつことで、メールの振り分けが楽になったりします。
そもそもの相手が送る宛先(アドレス)から振り分けできるので、メルマガなど思わぬアドレスから送られてきて、そのたびにフィルタ設定をするという手間から開放されます。

しかし会員登録の際に +(プラス)記号入力が不可設定になっているフォームも時々あるので、そういった場合には使えないですね。(個別にフィルタリングしてください)

③Calendar – 便利なショートカットキー

カレンダーをデスクトップで使用してる場合におすすめな、表示方法を変更するショートカットキーです。これは本当によく使います。

表示形式変更ショートカットキー

  • M:月表示
  • W:週表示
  • D:日表示

④検索 – フィルタをかけてほしい情報を取得する

これはもう超基礎的な部分ですが…。検索にはフィルタリング機能がありますので、ほしい期間の情報でフィルタリングが可能です。鮮度の高い記事をカンタンに入手できます。

操作手順

  1. ツールをクリック
  2. 期間指定なし▼ から希望の期間を選択する

⑤Google Alerts – 最新情報をゲット

メールで登録キーワードの最新情報がインターネットにでてくると、通知してくれる機能です。自分の職種に必要なキーワードだったり、私生活だと、好きなキャラクターのコラボに関する情報なんかを登録しておくといち早く情報をキャッチできますよ〜!

Google Alerts

⑥Map – マイプレイス

Google Mapを経路検索に使っている方はかなり多いのではと思いますが、場所を登録してリスト作成するという便利機能もあるんです。
参考までに…コレが私のリストです(ほとんど食べ物関連…笑)

空いた時間に調べた美味しそうなお店や、雑誌にでていた気になるお店なんかを保存することができるんです。以前はメモ帳などで管理していたのですが、google mapだと、地図情報とリンクしているので、現在地の近くの気になるカフェを探すことが可能なんです!画期的!便利!

リストの共有機能もあるので、家族間や友達同士でおすすめスポットを共有することにもつかえます。

会社のおすすめランチリストなんかつくって社内で共有したりしてもいいかもしれないですね。

番外編:お小遣い管理もGoogleで

これは使える機能というか、Googleサービスの使用用途の紹介になります。表題の通りです笑。

家計簿だったり、お小遣いってアプリも結構でてますが、シンプルに複数人のお小遣い管理となると丁度いいものが見つからず、Google先生にお願いすることにしました。

使用するサービスは以下の2つ。

  • Google スプレッドシート
  • Google フォーム

当初はスプレッドシートでちまちま入力していたのですが、スマホでの入力がスプレッドシートは使いにくいんですよね。(まあ表計算ソフトですから)

そこでいろいろ試行錯誤して(ググりまくって)、Googleフォームで入力して、それをスプレッドシートの任意のフォーマットに反映させることでスムーズな入出金管理シートを完成させました!作成したシートを夫にも共有して(編集権限はありません)、随時確認できるようにしています。

(欲を言えば、日付指定で自動入力してくれたり、スマホでの表示が別で指定できたりがあれば嬉しいですが、表計算ソフトにそれは少々求め過ぎですね…。わかってます…。)

これを転用して、我が家では旅行の入出金だったり、イレギュラーなライフイベントの支出管理にもつかっています。

個人的にGoogleフォームとスプレッドシートのタッグはかなり汎用性がたかいのではと感じたので、今後家のストック管理とか、献立管理とかそういうことにうまく使えないかなーと思案中です。いいアイディアがありましたら、ぜひ教えてほしいです!

以上、なにか1つでもお役に立てたことがあれば嬉しいです。今後も進化するGoogleサービスに期待しつつ、より便利な使い方を模索していこうと思います。

【開催中】P-Review ’20(成果発表会)記念すべき第1回に密着!

0

今年も社内イベント「P-Review(プレビュー)」を開催する季節がやってまいりました!!

今回は記念すべき第1回に密着して当日の様子をご紹介します!

P-Reviewとは

P-Review(Performance reviewの略です。プレビューと読みます)は、社員それぞれの成果発表を資料作成とプレゼンテーションで行うアピリッツの全社活動です。2019年から社歴の浅い人や新人を中心に始まりました。→ 去年の発表はこちら

関連:今年も開催!P-Review ’20(成果発表会)とは??

今年度は新型コロナウイルス感染症(COVID-19)の感染予防対策のため、Zoomによるリモート配信で開催されました。

トップバッターはアピゲー部、部長吉田さん

続々と社員のみなさんが視聴しにきてくれました。

テーマは『アプリの事前登録の傾向と対策』について。

社外秘の情報についても発表していました!アピリッツの社員のみなさん必見です。

続いてメディアサービス部杉本さん

「ハルヒが復活したから高橋メソッドも復活」とか言えばよかった、と発表後に一言。

テーマは『高橋メソッド』について。高橋メソッド……!?

とてもシンプルな資料で分かりやすかったです。さすが高橋メソッド!

最後に、20新卒の中では初めての発表となるメディアサービス部伊藤さんの発表!

画面に映らないハプニングも。

テーマは『自動と表現で快適なテストを』

チャットでの様々な質問にもしっかり応答していました!

今後社外秘以外の内容についてはアピスピ(アピリッツスピリッツ)でも紹介していきたいと思います。また、業務中にZoom配信を見れなかった方向けに、録画したZoom配信をアーカイブで見られるように調整中とのこと。

第1回発表の方々お疲れ様でした!

IT企業に内定・入社した時に見てほしい【『git入門』の入門】のお話

0

みなさんはじめまして。アピリッツ、コンテンツデザイン部に所属しております敷田と申します。
今回は新卒やIT企業で初めて働く人が最初にブチ当たる壁『 git 』の事を記事にしてみました。

はじめに

IT企業で働くことになると避けては通れない存在として『 git 』と呼ばれる謎の便利な存在があります。

エンジニアだけでなくデザイナーやプランナーなど、「ソースコードを書かない職種」の人も向き合う必要があり、今はIT企業で働くうえで必須の知識と言っても過言ではありません。

しかし、エンジニアの専門学校でも扱っているところは少なく、入社した時に先輩からは「ググったらgitについて書かれているサイト沢山あるから」と言われてしまい、ネットを探すと色々なgitについて書かれた入門ページはあるけど、いきなり実践向けだったり専門用語だらけだったりで、
自力で何とか学んで、なんとなく身に着けて、数をこなしてようやく習得する。
そんな、本当の意味で入門といえる情報は意外と少ないのが現実です。

そんな『 git 』という単語を初めて聞いた人が、『git入門』を読み始める前に【『git入門』の入門】として聞いてほしい内容をまとめました。

そもそも『 git 』って何?

まずはこちらの画像を見てみてください。

gitを使わないと最新ファイルが特定できない?

社会人になってくるとチームで1つのモノを作る機会が多くなります。そのため、個人の時は起こりえなかった1つのファイルを複数人で編集することも頻繁に発生してきます。もちろん、すべての修正を1人の人がやればこんなトラブルは起きませんが、これがとても行数の多いテキストファイルだったら、当然ながらみんなで分担してやらないといけませんよね?

そんな時に登場するのが『 git 』です!コイツを使うと上記の作業がこんな風に変わります!

gitを使うと最新ファイルが一目瞭然!

『git』という魔法の管理システムを使う事で、各自がバラバラにやっていた作業が全て綺麗に集約させてることが出来、しかも「更新に対してのコメント、差分(編集前後でどんな差があったか)、誰が編集したか」などの履歴も残ります。

そんなIT企業で開発を行う上で必須と言っても過言ではないのが『git』という【分散型バージョン管理システム】なのです。

代表的な単語を覚えていこう

多くの人が『git入門』で一番最初にぶち当たる壁は『git用語』です。どんなに便利な管理システムと分かっていても、初めて英語を勉強するのと同じで、何を言っているのか全く分からないところからスタートになって、人によっては挫折してしまうかも知れません。

そこで、『git入門』を安心して読み解けるようになれるよう、『 git 』を使う上でよく使われる代表的な単語が何者なのかを紹介していきます。

[ リポジトリ ]ってなぁに?

まず最初に覚えて欲しいのは[ リポジトリ ]です。リポジトリには[ リモートリポジトリ ][ ローカルリポジトリ ]の2種類があります。

[ リモートリポジトリ ]はgitでデータを管理している全員がアクセスする先で、ココを参照して最新のファイルを持ってきたり変更した内容をアップロードしたりする、「みんながアクセスする共有パソコンのフォルダ」のようなものです。
[ ローカルリポジトリ ][ リモートリポジトリ ]から取得したデータを保存する場所で、保存したファイルを編集して最新のデータに更新したりする、「自分のパソコンのフォルダ」のようなものです。

[ リモートリポジトリ ]はみんなが情報を共有するためのハブ(中継装置)にあたる存在なので、直接ファイルを編集したりすることはできません。ファイルを編集する場合はかならず[ ローカルリポジトリ ]を編集することになります。

[ ブランチ ]ってなぁに?

次に覚えておいてほしいのは[ ブランチ ]です。

「ブランチ」については「バージョン」とか「種類」を意味する単語だと覚えておきましょう。
例えば「最新バージョン / 機能追加バージョン / バグ修正バージョン」など、その時々で使い分けるものという事だけ覚えていれば大丈夫です。

この[ ブランチ ]なのですが『git入門』を読む段階ではあまり深く考えなくて大丈夫です。
ブランチの扱い方は開発環境やプロジェクトごとそれぞれ最適な運用方法があり、統一された運用方法が存在しません。つまり携わるプロジェクトによって使い方も変わるし、プロジェクトによってはその扱い方についてのルールなどが定義されていることも多いからです。

とはいえ、『 git 』の機能をフルに引き出すためには[ ブランチ ]の扱い方を完全に理解する必要があるとても重要な項目であることも事実です。
ある程度『 git 』の事を理解できてから、ブランチの運用方法についての知識を深めるために「git-flow」や「GitHub Flow」なんて単語を検索してみるといいかもしれません。

[ フェッチ ]ってなぁに?

前の2つとは異なりここから先の単語は操作名称になります。

まず最初に知っておくべきなのは[ フェッチ ]です。フェッチとは[ リモートリポジトリ ]の最新の状態を取得する操作です。

ここで注意すべきなのは「最新状態を取得」であって「最新状態を適用」ではないことです。あくまで、[ リモートリポジトリ ]内の最新の履歴情報やファイルを取得(ダウンロード)しているだけで、実際にダウンロードしたファイルを適用はしていないということに注意してください。

この[ フェッチ ]は『 git 』にとって非常に重要な処理で、これ以降に説明する操作いずれを実行する時にも必ず直前に実行が必要となります(一部例外あり)。なぜなら、[ リモートリポジトリ ]からデータを取得する時やデータを書き込む時に、最新の情報を取得している状態で処理を行わないと、データがぐちゃぐちゃになってしまうからです。

とりあえず初めて『 git 』に触れる方は、「何を実行する時にも最初に必ず実行しないといけないおまじない」と覚えておくといいでしょう。

[ コミット, プッシュ ]ってなぁに?

[ コミット ]とは、自分のパソコンにあるファイルデータを更新して保存する事です。
ただし普通のファイル保存だけではなく、ファイル保存をした後に[ ローカルリポジトリ ]に対してファイルを更新した記録を登録するという事をしなければならなく、その処理の事を[ コミット ]と言います。

[ プッシュ ]とは、その[ コミット ]した記録を[ リモートリポジトリ ]に登録する操作のことです。
この操作をすることで全員が参照しているリポジトリに記録が残るので、アクセスしている全員が見れる状態になります。

[ マージ, プル ]ってなぁに?

[ マージ ]とは2つの異なる[ ブランチ ]を1つに統合する事です。

マージについては、[ ローカルリポジトリのブランチA ][ ローカルリポジトリのブランチB ]をマージするパターンと[ ローカルリポジトリのブランチA ][ リモートリポジトリのブランチA ]をマージするパターンの2種類があります。

前者はローカル環境にある2つのブランチの内容を1つに統合する処理です。

後者は既に所持していたローカルのデータに対して、リモートにある最新の情報適用して更新する処理です。
この後者のリモートリポジトリのデータを取得する一連の流れの[ フェッチ => マージ ]の処理のことを[ プル ]と言い、リモートにある最新データをローカルに適用する処理としてよく使われます。

避けては通れない[ コンフリクト ]

色々な単語を紹介してきましたが、最後に最も重要な単語を紹介します。それが[ コンフリクト ]です。
同じファイルを同時に操作しているメンバーがいて、編集した箇所が被っていた時には以下のような現象が起きる事があります。

[ マージ ]をしたときにこのような現象が起きる事を[ コンフリクト ]と言います。これが起きた時には、残念ながら機械的にマージ処理は行われません。こうなった時には、人の手で正しい形に修正して、改めて[ コミット => プッシュ ]する必要があります。

このコンフリクトですが、対応方法を間違えると大事な修正した内容が消えてしまうなどの大事件になってしまう場合もあります。
なので、『 git 』に慣れるまでの間は、コンフリクトという単語を目撃した時は“必ず、先輩など詳しい人に質問する”ようにし、詳しい人に対応してもらうようにしましょう。

おわりに

今まで書いた内容はあくまで【『git入門』の入門】です。
最初は覚えなくていい要素([ リモート追跡ブランチ ]とか[ マージリクエスト ]とか)は省略してますし、説明もイメージしやすいようにシンプルに書いています。

これらは『git入門』を理解しやすくする目的で書いているからで、ちょっとおかしな説明になっているところもあるかもしれません。
しかし、この内容を読んでから『git入門』を読んでいただければ、きっと『 git 』のことを少しは理解しやすくなっているかと思います。

最初にも書きましたが『 git 』はIT企業で働く時には避けて通れない知識になってきています。初めて向き合う時はとても難しく見えますが、接していくうちに段々と大活躍する一生モノのツールになってくれるはずです。そんな便利なツールと仲良くなるキッカケになって頂ければ幸いです。

【祝20周年!】記念樹に込められた思いとは?

0

2020年7月18日(土)アピリッツは20歳を迎えました……!そこで和田社長から(前回の創立記念日の記事はコチラ)

なんかせっかくだし記念の木とか欲しいなあ……。

と緑化委員に依頼が来ました。そしてその後、3本の素敵な木が届きました!

緑化委員とは……

各フロアの観葉植物の水やりなどのお世話をしています。また、植物が育って大きくなったら、剪定(せんてい)をしたり、鉢の植え替えなどもします。メンバーは、植物が好きな方や新卒を中心として構成されており、やりがいは「植物に関して知識がなくても詳しくなれたりする!」だそうです!

オフィスの植物は緑化委員のみなさんがお世話をしていたのですね……!いつもありがとうございます!

そこで緑化委員に所属している、アピゲー部の20新卒石田さんに届いた記念樹について教えてもらいました!

――選定の過程について教えてください!

石田:基本的には、20卒の緑化委員会が主体で動きました。最初に緑化委員会(19、20卒)と植物に詳しい先輩方なども含めて候補を出し、最終的には20卒間で話し合い決定いたしました。

記念樹に込められた思い

トックリヤシ

2階オフィスの長谷部さん(GD部部長)のそばに置いてあります。南国が味わえます。

石田:現在ある植木に被らないシルエットと、根本から徐々に太くなりゆっくりと成長していくので、堅実に成長できる会社を目指すというイメージです。
余談ですが、昨年の夏頃に和田さんがアロハシャツを着ているのをお見受けいたしましたので、南国っぽい感じも気に入って下さるかなと思って選びました。

ベンジャミン

3階オフィスに置いてあります。くるくるの葉っぱが可愛い。

石田:「幸福をもたらす木」の通り、今後もアピリッツの成長が良いものになりますようにというコンセプトです。ベンジャミンの中でも葉っぱがカールしているバロックいう品種で、見た目が他の植木と被らないところも高ポイントです。

コーヒーの木

5階受付に置いてあります。綺麗な緑で圧倒的存在感!

石田:変わり種として入れてみました。1~1.5mほど育てると実がなるそうなので、20周年アピリッツコーヒが飲める日がいずれ来るということで、育てる楽しみは一番高いと思います!花言葉は「一緒に休みましょう」という意味です。

どの木もとっても素敵な選定理由ですね!私もコーヒー飲めるのを楽しみにしています♪

緑化委員のみなさんありがとうございました!

【成果発表会】「読もうと思えるコードを目指す」コード解析で見やすくするための「using」手法

今回は、社内の成果発表会「P-Review ’19」にて発表したエンジニア 須合 雅之さんの資料を紹介します。
※こちらの記事は個人の研究発表で、会社としての見解ではございません。

須合 雅之
2019年4月ゲームサービス部(現:コンテンツデザイン部)にエンジニアとして入社。
入社後は主に受託ゲームのエンジニア業務を担当。仏のように優しい。

p-review19_sugo.pdf1

(※挨拶省略)

このテーマを選んだ理由

僕は入社前にもプログラミングをしていたんですが、仕事で初めて触れたC++コードがとても見やすくて感動し、後世のエンジニアにもコードを見やすくする「using」での手法を知ってもらいたくて、このテーマを選びました!

既存のコードの解析をする時に「using」で悩むことが減り、コードの見やすさについて考えてくれる人が増えると嬉しいです。

仕事で触れたコード

usingの説明前に、仕事で触れたコードの見やすかったポイントをまとめました。

• 関数名、型名がわかりやすい

• 一つ一つの処理が簡潔

• 一行が長すぎない

なぜ見やすさが大事か

私がなぜ見やすさを重要視しているかですが、コードが見づらいとそのコードは読みたくなくなるんです。

例えば、このようなコードがあったとします。

ぱっと見てどう感じますか?

見づらくないですか!?

コメントがない、引数の型がわかりにくいなどあると思います。
しかし、それよりも画面に収まっていないんです。

こんな読みたくないコードを「解析しろ」と言われても、モチベーションが上がらない!
複数人で開発する場合や、見返す時も解析に時間がかかり、開発効率が悪くなってしまうと思います。

では次に、このコードはどうでしょうか。

先ほどの見づらいコードと違って、画面内に収まっています。
引数の型もそこまで複雑そうに見えないし、これはまだ読めそうです。

ですが…
実はこの読めそうなコードは、読みたくないコードを見やすくした同じコードなんです!!

同じコードだけど、ぱっと見で「読みたくない!」と思わせない。
そのためにも見やすさは大事なんです。

見やすくするために使ったのが赤で囲ってある部分にあるusingです。

では、usingでできることを今回は2つを説明します。

usingでできること~別名を付ける~

例①

例としてこのようなコードがあったとします。

今回は画面内に収まっていますが、「unsigned int 」って少しわかりにくいですね。

普通の「int」型を使うことになった場合、混じってしまうかもしれません。
それに引数に指定している部分は、「const」や「&」など、修飾が増えると混乱するかもしれないです。

コードを書く側としても、毎回「unsigned」を打つのは面倒ですし、読む側もうざったいと思います。
「unsigned int 」を一つにまとめることができれば、これらの点を改善して見やすくできそうです。

usingを使って解決します。

これがusingを使ったコードです。
修飾が外れて、ぱっと見簡単なコードに見えます。

何をしたかと言うと、usingを使って「unsigned int 」に「uint」という別名をつけて置き換えました。

赤枠で囲ってある部分で別名を宣言しています。
これが、別名に置き換える時のusingの使い方です。

例②

次は、ネット上によくあるコードの説明です。

何ビットかを明記しておくことで、メモリ配置やフラグに使うときなどにわかりやすくなりそうですね。
そして書くときも楽です!

最初にあげたこの読みたくないコードも…

usingを使って別名をつけることで、読めそうなコードにしました。

「std::function」という複雑な型を切り出すことで、実際に使っている部分がかなりわかりやすくできました。
文字数を短いものに置き換えたことで一行を短くし、画面内に収まっています。

C#の場合ですが、namespaceに対しても別名をつけることができます。スコープを明示的に付けたい時に役立つかもしれません。

次にnamespaceを省略することについて説明します

usingでできること~namespaceを省略~

例①

このプログラムでは「std」から様々な要素を使っています。
矢印で示す通り、様々なところで「std」のスコープが見られます。
特に「std::vector<std::string>」は、ぱっと見でわかりづらいかなと思ってしまいますよね。

このような問題はusingディレクティブで解決できます。

usingでnamespaceを指定すると、そのnamespace内の要素を使うときに、スコープが不要になります。
これならあとで、「std」から必要なものが増えた場合でも、「std」のスコープを付けないで使うことができます。

C#の場合(おまけ)

C#の場合でもusingを使って省略できます!

まとめ

見づらいコードは読みたくないし、開発効率が悪くなってしまいます。
usingを使えば、型に別名をつけてわかりやすい名前にしたり、namespaceを省略することができます!

usingを使って読もうと思えるコードを目指しましょう!

自分の書いたコードが分かりやすくなっているか同期と確認しあう須合氏

他の人が読むことを考えて、見やすいコードを書くのはとっても良いことですね!
これがエンジニアの思いやり……
アイコも思いやりを持ってお仕事頑張ります!

ソーシャルゲームにおけるミッション機能のサーバーサイド実装の考察:思考編

0

アピリッツ コンテンツデザイン部の金井と申します。前回に引き続き、ソーシャルゲームにおけるミッション機能に対する考察をしていきます。

関連:ソーシャルゲームにおけるミッション機能のサーバーサイド実装の考察:問題編

前回のあらすじ

 ミッション機能というものは構造的に、

  • 全てのAPIに影響が及ぶが故に改修へのQAコストが非常に高く
  • 処理に時間が掛かりやすく
  • ユーザーデータが膨大になるが故にそれらの問題が更に面倒な事になりやすい

 ものである。
 また、実際に実装/改修するとしても、仕様面の都合で

  • ミッション受注処理
  • ミッション進捗処理
  • ミッション報酬受け取り処理

 の3つが複雑に絡み合う事が多く、所謂スパゲッティコードというものに、しかも見るからに不味いそれになりやすい。

平和だった日常回を思い出しながら仕事に手を付ける覚悟をしたエンジニア

どのように実装/改修すべきか

注:

 ここから記述する内容は、”これから実装する“もしくは”既存のソースを流用して新しいゲームを開発する“と言った、運用中ではない事を前提としたものとなります。
 既存のミッション機能が如何にクソコード汚いものでも改修する事によって得られるメリットは、精々、

  • レスポンスが早くなる
  • コードが見やすくなる
  • 改修等に伴うバグの発生率を減らす事が出来る

等と言ったユーザーからは見えないものが多く、更に

  • 影響が膨大な以上、QAを入念に介してもバグを除き切れずに本番障害を引き起こす可能性が高い
  • バグを引き起こした場合の長時間メンテ、修正、補填などで大きな損害も被る
  • マスタの改修なども必要となった場合、マスタデータを作るExcel…これまで使用していたマクロなども改修しなければいけない事となり、プランナー側、そしてクライアント側にも大きな負担が掛かる

 と言ったそれ以上のデメリットが膨大です。
 如何にエンジンが錆び付いてガションガションうるさい音を立てていようとも、熱効率が悪かろうとも、動いている状態のまま幾つかの部品を取り替える事なんて早々出来ないですからね。
 それでもやらなければいけないとなる場合は、レスポンスの重さでユーザー離脱が激しいとか、原因不明のバグが頻発して、更に手をつけようにも秘伝のソース過ぎて壊さないとどうしようも出来ないとかそんな、それを使い続ける事で極度の不利益が出る場合に限るでしょう。
 そうでない場合は、その汚いコードと付き合っていくのがベストです。
 ベストです。
 ベストなんですよ。悲しい事に。とても、とても悲しい事に。

出社直後、イベントにて大量の期間限定ミッションが追加された事により、特定のAPIの平均レスポンスが5秒以上掛かっている事を発見したエンジニア

普遍的に良く見られるであろう悪くなっていくコード

 まず前回でも書いたような、カードの強化で例えてみましょう。
 カードを強化させた回数のミッション指定アイテムを手に入れた回数のミッションが存在するとします。
 そして、カードを最大レベルまで強化するとカードマスタに指定されたアイテムが貰えるとします。
 すると、さっくり疑似コードとして書いてみると以下のようになるでしょう。

class User < ActiveRecord::Base
  def カード強化(カードID, 使用素材群, 時刻)
    カードが存在するか確認
    カードが既に最大レベルでないか確認
    使用素材群それぞれに対し do
     消費数分持っているか、またそれらがレベルアップ用アイテムか確認
    消費数分の減算、獲得経験値を計算
    end

    カードをレベルアップ(獲得経験値)
    カードを強化したミッションを進捗させる

    if カードが最大レベルならば
     アイテム付与(カードマスタに定義されている報酬アイテムマスタコード, カードマスタに定義されている報酬アイテム量, 時刻)
    end
  end

  def アイテム付与(アイテムマスタコード, 付与量, 時刻)
    指定されたアイテムマスタが存在するか、また受け取れる時間であるか確認
    ユーザーにアイテムを付与
    アイテムを獲得したミッションを進捗させる
  end
end

 こんな感じですね。
 確かにミッションがシンプルな仕様ならば、そんなに時間も掛からないでしょう。
 しかし例えばカードの強化を促進させる施策の一環で、カードを指定レベルまで成長させたカードのレベルを最大まで上げたというミッションが追加されたとすると、最大、合計で4つのミッションの進捗確認を1個1個する事になります。
 段々雲行きが怪しくなってきましたね!

 そして今度はミッションを進捗させる方を詳しく見ていきましょう。分かりやすさの為に、ミッション進捗は別のクラスに纏めましょうか。

class ミッション進捗
  def 進捗させる(ユーザー, 進捗させるミッション種, 進捗させるミッションカウント, ...)
    進捗させるミッション種に属する、現在有効なミッション群を確認する
    そのミッション群に対して do
      ユーザーの進捗を加算する
    end
  end
end

 簡単に書くとこうなりますね。
 さて。ここで例えば前回でも書いたような、ミッションの仕様に良くある、ミッションをクリアしたら次のミッションが解放されるという仕様が入ってくるとこうなりますね。

class ミッション進捗
  class << self
    def 進捗させる(ユーザー, 進捗させるミッション種, 進捗させるミッションカウント, ...)
      進捗させるミッション種に属する、現在有効なミッション群を確認する
      そのミッション群に対して do
        ユーザーの進捗を加算する
        if クリアしたならば
          それのクリアを前提条件とするミッション群を解放させる
        end
      end
    end
  end
end

 シンプルにこのような感じになるでしょうね。
 さて。ミッション進捗そのものも重くなりましたね。それがカードを強化するだけで最大4回走りますね。
 雨が降ってきたようです。
 そしてトドメに、ある特定のミッション種別だったらクリアまでではなく、報酬付与までするとの仕様が入ってきたとしましょうか。

class ミッション進捗
  class << self
    def 進捗させる(ユーザー, 進捗させるミッション種, 進捗させるミッションカウント, ...)
      進捗させるミッション種に属する、現在有効なミッション群を確認する
      そのミッション群に対して do
        ユーザーの進捗を加算する
        if クリアしたならば
          それのクリアを前提条件とするミッション群を解放させる
          そのミッションが特定の種別だった場合、報酬付与まで行う
        end
      end
    end
  end
end

 はい。報酬付与の中ではこのミッション進捗が呼ばれていますね。雷まで落ちてきたようです。

イベント中にバグが発生し、しかもそれが実装した人ももう居ない、誰も見たがらない秘伝のソースの中にあると分かった時のサーバーエンジニア達

こうならない為にはどうするべきか

 自分なりの考えとなりますが、結論としては単純です。

 同じようなコードを何度も通さない仕組みにすれば良い。

 ただ、それだけです。
 上のコードを書き換えるとこんな感じでしょうか。

class User < ActiveRecord::Base
  def カード強化(カードID, 使用素材群, 時刻)
    カードが存在するか確認
    カードが既に最大レベルでないか確認
    使用素材群それぞれに対し do
     消費数分持っているか、またそれらがレベルアップ用アイテムか確認
    消費数分の減算、獲得経験値を計算
    end

    カードをレベルアップ(獲得経験値)
    ミッション用にカードを強化したというデータを保持

    if カードが最大レベルならば
     アイテム付与(カードマスタに定義されている報酬アイテムマスタコード, カードマスタに定義されている報酬アイテム量, 時刻)
    end
  end

  def アイテム付与(アイテムマスタコード, 付与量, 時刻)
    指定されたアイテムマスタが存在するか、また受け取れる時間であるか確認
    ユーザーにアイテムを付与
    ミッション用にアイテム付与したというデータを保持
  end
end

 そしてカード強化の後、他に何もやらなくなったタイミングで保持したデータに対して一括でミッションを進捗させる。

class ミッション進捗
  class << self
    # 進捗させるミッションデータ群 = {ミッション種別: 進捗カウント}
    def 進捗させる(ユーザー, 進捗させるミッションデータ群, ...)
      進捗させるミッション種別群に属する、現在有効なミッション群を確認する
      そのミッション群に対して do
        ユーザーの進捗を加算する
      end
      クリアしたミッション群それぞれに対して do
        それのクリアを前提条件とするミッション群を解放させる
        そのミッションが特定の種別だった場合、報酬付与まで行う
      end

      if 報酬付与まで行なった場合
        ミッション進捗をまた呼ぶ
      end
    end
  end
end

 ざっくりこのような形ですね。
 工夫が足りず、このミッション進捗はこれでも複数回呼ばれる可能性はありますが、少なくとも元々の形よりは呼ばれる頻度は落ちるでしょう。
 カードを強化させた回数のミッション指定アイテムを手に入れた回数のミッションに加えてカードを指定レベルまで成長させたカードのレベルを最大まで上げたというミッションがあったとしても、このミッション進捗を通る回数は1回で変わらないのですから。

結論

 自分ではそれしか思いつきませんでした。
 ミッションという機能は性質上、1APIで様々なミッションの進捗が進むという事が絶対にあります。
 幾らそのミッションの進捗1回分を軽量化しようとしても、無理な軽量化はどこかに歪みを生みます。コードがより複雑になったり、新たな仕様によって軽量化の前提が上等な料理にハチミツをぶちまけるが如くに崩れる事があったり。
 1個1個に対して愚直に進捗を進ませるという事柄自体をやめなければ、ミッションという機能は健全に運営に組み込めないという結論です。
 しかし、それはやはり運営フェーズに入ってからは絶対に出来ない事です。
 全てのAPIに浸透し、隆盛しているようなそんな文化を一気にひっくり返すなど、濃口のラーメンが流行りの極みの時に薄口のラーメンのみを売り出して儲けを出そうとするようなものでしょう。

 次回は、そんなコードを実際に改修した時に起きた事などを書こうと思います。

原因が見つからないエンジニア

第三回はこちら:ソーシャルゲームにおけるミッション機能のサーバーサイド実装の考察:実践編

社内で生まれたゲームエンジンの活用で優良なコンテンツを提供!

0

今回はゲームデザイン部の部長・長谷部さんに、入社して感じたことや現在のお仕事、そしてゲームエンジン活用のメリットついてインタビューしました。(2020年2月取材)

――まずは、長谷部さんの自己紹介と現在のお仕事について教えてください!

ゲームデザイン部の部長をしております、長谷部と申します。業務内容は、社内で開発したゲームエンジン(技術)を活用し受託でゲームを開発したり、セカンダリ案件の運営を行っています。セカンダリ案件とは、他社さまが運営していたタイトルを買い取り、引き継いでお客様に提供することです。現在は、自社のスマートフォン向けゲーム「ゴエティアクロス」をベースとしたゲームエンジンを用いて、他社さまのIPを用いたゲームを受託で2本開発しております。セカンダリ案件としては「演義シリーズ」という3本のタイトルを運営しています。

――ゲームエンジンの活用……??

社内でゲームを開発した際にうまれた技術やシステムを使って、受託開発に結びつけるというコンセプトです。まず、どんなゲームでも似たような機能はありますよね。そういう機能を、ゲームを作るたびに毎回ゼロから開発せずに活用しています。通常はゼロから開発して毎回新しいシステムを開発していく例が多いのですが、それだと無駄が多いので、通り一辺倒の当たり前に存在するような機能はなるべく活用してゆき「使えるものは使いましょう!」という発想です。そうするとより安価に作れますし、不具合も出づらいです。

――アピリッツに入社するまでの経歴や経緯について教えてください!

元々オンラインゲームが好きで遊んでいたのですが、その頃にMMORPGを開発していた株式会社ハドソンと縁がうまれて入社しました。そこから、MMORPGの運営や、いくつかのオンラインゲーム開発、ガラケー向けのコンテンツ運営などを行い、いくつかの会社を渡り歩いてオンラインゲーム、ソーシャルゲームの開発を続けていました。数年前にハドソン時代の友達が紹介してくれた会社「風姿華傳」に入社し、その「風姿華傳」と一緒にアピリッツに合流しました。

個人の「やりたい!」が実現できる会社

――アピリッツに参加して、どのような印象を受けましたか?

ホワイトな点ですね。この業界、勤務時間が長く帰れないといったいわゆる「ブラック」な状態での会社運営がされていることがどうしても多いのです。私も過去に勤めていた会社では何件もそういった状態である会社を見てきたのですが、それがほとんど感じられないことに入社当初は驚きました。人事の方がしっかり気を配って勤怠管理制度が整っているため、従業員に優しい印象を持ちました。

また、入社間もない頃から他部署の方たちとコミュニケーションが取りやすく感じました。ちゃんと会話をするってことは仕事をする上で必要だと思っているため、コミュニケーションに対してみんな積極的であるのも良いですね。

―― 今後、アピリッツにどんな仲間が来てほしいですか?

アピリッツは、個人がやりたい!ってことに対してNGをかけたりしない傾向がありますので、自分の中で作りたいものを持っている人や、実現したい明確な目標がある人が増えるとより面白くなっていくのではないかと感じています。私自身もそういう人と一緒に働きたいですね。

こちらは2019年の様子です。コロナが収束して、またこういう日がきますように……!

――長谷部さんが仕事で感じるやりがいについて教えて下さい

ゲーム開発におけるやりがいは、やはりリリースした後のお客様(ユーザー)の反応にあると思います。それはもちろん売れれば数値的な面でもありますが、近年発達してきたSNSなどでも様々な感想が流れており、そういったものもやりがいにつながっていると感じます。

コミュニケーションを大切に、楽しく働ける環境作り

――仕事をする上で意識していることはなにでしょうか?

お客さまとコミュニケーションをたくさんとって、作りたいものをしっかり認識し、実現するってことを心がけています。ゲーム開発では、開発期間が約1年間くらいあるので、開発期間中にトレンドが変わったり作りたいもの自体も変化してきたり……と一定ではないため、最後の方に修正することも多いからです。

マネージメント的な部分ですと、従業員の人達がストレスをなるべく溜めないようにメンタル的なコントロールをする必要があると考えています。話しかけたり、話しかけられた時に笑顔で迎える、とかそういうのは結構大事かなと思って意識しています。やっぱり嫌な環境で働くのって辛いと思うので、なるべく楽しく働ける環境が作れたら良いなと思っています。

――今後の目標についてお聞かせください

まずは今期”部”が分かれた直後なので部長としてその”別れた部”っていうのを安定に稼働させて、現在開発しているコンテンツの成功も目指します。

その後も、社内で生まれた新たな技術を活用し、優良なコンテンツを提供していき、しっかりとした収益基盤を形成し、会社に貢献していきたいと考えています。

――長谷部さんありがとうございました!

関連:演義シリーズ(疾風幕末演義・関ヶ原演義・繚乱三国演義)公式サイト

関連:アピリッツのその他の役員インタビュー

【デモECサイトで学ぶ】Googleアナリティクスの基本操作と使い方

0

現在、コロナウイルスやリモートワークの影響によって、消費者が自宅で買い物をする「巣ごもり消費」が活発になり、EC サイトの需要が大きく伸びています。
その中で、Google アナリティクスを活用すれば、EC サイトにおける購入動向を分析し、さらなる改善に役立てられます。
しかし、Google アナリティクスの必要性はわかっていても、多機能でカスタマイズ性も高いゆえに、操作方法などもよくわからないまま使用している方が多くいらっしゃいます。
そんな方のために、Google がデモアカウントを用意しており、デモアカウントのデータは、Google の公式グッズを販売している EC サイト「Google Merchandise Store」から取得しています。
本記事では、デモアカウントの画面を見ながら、Google アナリティクスの基本操作や使い方について解説します。

Google アナリティクスの基本操作

1.アカウント、プロパティ、ビューの変更

こちらの画面では、デモアカウントの他に当社アピリッツの2アカウントが存在しています。
そしてデモアカウントという 1 つのアカウントに対して、1 つのプロパティがあります。さらにそのプロパティの下にビューが設定されている仕組みです。

アカウント、プロパティ、ビューを変更するにはメニューから[管理]をクリックします。
そうすると管理画面が表示され、3 つの階層を確認できます。
それぞれ上部のプルダウンから選択し、変更することができます。

2.レポートメニューの切換え

Google アナリティクスでは大きく5つのレポートがデフォルトで搭載されており、各種レポート内容を解説します。

リアルタイムレポート

「現在」と書かれている部分の数値が Web サイトを「今現在閲覧しているユーザーの数」が表示されます。
右上にあるグラフは、時間遷移に伴い、閲覧されているページの数がどのように変化しているかを表示されます。
右下の表は、今ユーザーがどのページを見ているかを表しています。

ユーザーレポート

この画面では、以下7つの指標について調べることができます。

セッション何人のユーザーが Web サイトに訪れたかという回数。
初めてのアクセス、複数回のアクセスなどは関係せず、単純に「何回訪問されているか」を調べる指標。
ユーザー特定の期間内にサイトを訪れたユーザーの数。
複数回訪れた人の計測は「1 回」とカウントされるため「何人が訪問をしているか」を知りたい際に見るべき指標。
ページビュー数Web サイト内のページが表示された回数。
Web サイト内での回遊なども含めて、「Web サイトのページが何回見られているか」を調べる際に見る指標。
ページセッションページビュー数÷セッション数1回の訪問で何ページ見られているのかを調べるのに使う指標。
高ければ高いほど回遊率が高いということがわかる。
平均セッション時間1 セッションにあたる平均時間を示したもの。
ユーザーが訪問してから離脱するまで、どれだけの時間サイトを閲覧したかわかる。
直帰率Web サイトを訪れ 1 ページしか見ずにそのままサイトを離脱したユーザーの割合。
新規セッション率Web サイトを訪問したユーザーのうち、はじめて訪問したユーザーのセッションの割合。

集客レポート

ページの下部にある表は、どのような流入元からきたユーザーがどのような動きをしているかを表しています。
左側にある、「Organic Search」や「Display」といった流入元の種類が分類されています。

行動レポート

Web サイトに訪問したユーザーが Web サイトでどのような動きをしているかを知ることができます。
具体的に、Web サイトのどのページをどのように回遊しているのかを調べられます。

コンバージョンレポート

何件のコンバージョンが発生したかを確認できます。
ページ上部のグラフでは、目標を達成したセッション数の推移などを確認することができます。

どのレポートを表示する場合にも、左側のメニューから見たいレポートを選択します。

レポートをクリックすると、レポートのリストが表示され、さらに該当のカテゴリを選択することでレポート画面が切り替わります。

3.設定内容の確認

ビューの設定

デモアカウントのビューでは、「1 Master View」、「2 Test View」、「3 RAW Data View」、「Testing 」が用意されています。

これは最低でも「マスタービュー」「テストビュー」「ローデータ」の3つを解析前に作っておく必要があり、それぞれ理由は以下の通りです。

・マスタービュー
普段の解析で使用する本番用のビューです。
関係者(自分を含む)のアクセスを IP アドレスで除外したり、リファラースパムを排除するフィルタ設定などを行います。

・テストビュー
設定を変更・追加するときなど、正しく計測できているかを確認するために使用します。
イベント計測の失敗が後になり判明するといったことはよくあるため、事前に計測テストをしておくことが大切です。

・ローデータ
フィルタをかけないなど、あらゆる設定を一切しないオリジナルのビューのことです。
他のビューの設定ミスで消去されてしまったり、なにか問題が起こったときのためのバックアップとして必要です。

eコマースの設定

デモアカウントでは EC サイトのアクセス解析において重要な「購入された商品と数量」「収益」「どの商品が売れているのか」など、実際に売上に直結している指標を確認、分析できる e コマーストラッキング機能が設定されています。

基本的なレポートの見方

1.計測期間の変更

計測期間を変更するにはレポート画面右上の日付から行います。

デフォルトでは直近1週間、表示単位は1日と設定されています。
クリックするとカレンダーが表示され、こちらから期間を設定します。

1クリックで月単位表示する

カレンダー上部の月表記を、をクリックすると、その月が期間として選択されます。

スタンダードな期間を1クリックで表示する

「期間」のとなりにある「カスタム」をクリックするとプルダウンが表示され、よく使用する「今日」「昨日」「前週」「先月」「過去7日間」「過去 30 日間」をそれぞれ選択できます。
選択したら、「適用」をクリックすると期間が切り替わります。

任意の期間を指定する

カレンダーで期間の開始日をクリックした後、終了日をクリックします。
そうすると選択した期間がレポートの期間として表示されます。
また[期間] 欄に開始日と終了日を入力する変更方法もありますので、ぜひ試してみてください。

2.レポートタブの切換え

各レポートメニューの画面表示は、基本的にタブ形式になっています。

多くのレポート画面では[エクスプローラ]タブのみですが、レポートメニューによっては複数のタブで画面表示を切り替えることができます。

各レポート画面はディメンションに対する指標ごとの計測数値を表示するもので、多くの場合は表とグラフで構成されたレイアウト(エクスプローラ)で、わかりやすく表示されています。
しかし、次のようなレポートメニューについては、個別のレポート画面レイアウトで表示します。

  • 表やグラフでなく”図”を使って表示する場合
  • 特定のディメンションのみの計測数値を独自に表示する必要がある場合


このように表示形式が異なる内容は、すべてのタブの中にレイアウトされ、タブを選択することで画面表示が切り替わるようになります。

3.グラフ、表の表示変更

グラフに表示する指標を変更する

グラフに別のデータ数値を表示させる場合は、グラフ左上のプルダウンを選択し、表示させたい指標を選択することでグラフに反映されます。

また、となりにある[指標を選択]から別の指標を選択すると、グラフに 2 つ目のデータを表示され比較することができます。

データ表のディメンションを変更する

表テーブルに表示されている項目を変えたり、複数組み合わせて表示するには、ディメンションを変更します。
ディメンションを変更するには、[プライマリディメンション]のとなりから表示させたいディメンションを選択すると反映されます。

また、データをより詳細に表示させたい場合には、セカンダリディメンションを設定します。
セカンダリディメンションを設定することで 2 つのディメンションを組み合わせたデータを表にすることができます。
設定方法は、[セカンダリディメンション]というプルダウンからディメンションを選択するだけで反映されます。

脱初心者 便利なレポートの使い方

1.正規表現を使った絞り込み検索

正規表現はカスタムフィルタの「フィルタフィールド」や「フィルタパターン」での URL や IP アドレスなど、文字列を絞り込むときに役立ちます。
実際にデモアカウントのデータを活用し、値を先頭一致で絞り込む場合の正規表現を解説します。
まず、メニューから「行動>サイトコンテンツ>すべてのページ」から、エクスプローラーを開きます。
表テーブル右上にある、[アドバンス]をクリックし、アドバンス機能を表示したら設定作業を行います。
ページ URL には「/google」から始まっているものがいくつもあります。
そこで「/google で始まるページ」に絞り込まれたレポートを表示します。

リストボックスを操作して「含む」→「正規表現一致」に変更します。
入力フィールドに、「/google で始まるページ」を意味する正規表現「^/google」と入力し、[適用]をクリックしたら完了です。

このように正規表現を用いれば、パターン数が多い高基数ディメンションをまとめて抽出することができます。
上記はほんの一例で、その他にも”OR 条件を指定する「│」”など様々な正規表現がありますので、ぜひお試しください。

2.エクセル形式でダウンロード

Google アナリティクスのレポートメニューのデータは、ファイルに出力(エクスポート)できます。
エクスポートできるファイル形式は、以下の4種類です。

  • PDF
  • Google スプレッドシート
  • Excel
  • CSV


Excel 形式でダウンロードする方法は、画面右上の「エクスポート」クリックします。

次にプルダウンが表示されますので「Excel」を選択すると、ダウンロードが開始されます。

3.よく使うレポートを保存

よく使用するレポートには、すばやくアクセスできる[保存済みレポート]の機能があります。
毎回レポートで開き、セグメントで条件を絞ったり、アドバンスフィルタをかけたり、など同じ設定をやり直す必要がなく
レポート対象期間を除く適用した設定は、手動で変更しない限り、ログアウト後も保存されます。
設定方法はシンプルで、自分の目的の合うよう設定を行い、その状態で右上にある[保存]をクリックします。

すると、「保存するレポートの名前を入力する画面」が表示されますので、任意の名前を入力し[OK]をクリックします。
その後、保存したレポートを見たい場合は、メニューの「カスタム>保存済みレポート]から、保存済みレポート一覧が表示されるので、見たいレポートをクリックします。

[保存済みレポート]の機能を使って、作業効率をアップさせてみましょう。

さいごに

今回は、Google アナリティクスの基本操作や使い方について解説しました。
実際にデモアカウントを使って操作に慣れてみると、より内容を理解することができます。
また、アピリッツでは Google アナリティクスの設定や使い方にとどまらず関連する WEB マーケティング施策を絡めた効果測定方法・活用方法をサポートしています。
自社サイトに Google アナリティクスの導入・活用をご検討されている方は、ぜひお問い合わせください!

→アピリッツへのお問い合わせはこちらから

Kali Linux 2020.3 導入と日本語化

0
kali linux 日本語

エンパワーメントサービス部所属セキュリティエンジニアの綾城です。
Kali Linux 2020.3 を VirtualBox にインストールしてメニューの日本語表示化と日本語入力を可能にしてみました。Kali Linuxは、セキュリティ診断用ツールが標準で用意されている、Linuxディストリビューションです。今回からは、このサイトに掲載していきます。以前のバージョンや内容については、こちらを参考にしてください。

はじめに

Kali Linuxは、セキュリティ診断ツールを含むLinuxディストリビューションです。利用の仕方により不正アクセス行為と判断される可能性があります。またサービス停止やデータの破損が起こる場合もありますので事前にバックアップを行うなどしてください。そして必要に応じて必ず管理者の許可を得て利用してください。また例えば、Webアプリケーションの診断等始める場合は、徳丸本など参考にして、十分理解してから行ってくださいね。

徳丸試験の紹介と合格する方法
https://spirits.appirits.com/role/engineer/security-engineer/5418/

Kali Linuxの特徴などについて

デジタルフォレンジックや、特にペネトレーションテスト(侵入テスト)用などのツールが用意されている、Debian派生のLinuxディストリビューションです。ハッカードラマなどにもたびたび登場するほどこの分野に関してはメジャーなディストリビューションです。最近では、Windows10のWSL(Windows Subsystem for Linux)で、使用できたりします。

Kali Linux 公式サイト
https://www.kali.org/

脆弱性診断とペネトレーションテストの違い

主な収録ツール

Kali Linuxには多数のツールが導入されています。収録ツールについては下記のリンクから確認ください。Nmap、Aircrack-ng、Wireshark、Metasploit Framework、Armitage、Burp Suite、OWASP ZAP、BeEF、sqlmap、wpscan など

Kali Linux Tools Listing
https://tools.kali.org/tools-listing

日本語化について

海外の資料などを参照しながら、日本語化したKali Linuxを使うとUIの文字列が違い分かりにくいと意見もありますが、自分はわかりやすさ優先でUIも日本語化して使うことが多いです。また、日本語入力もCherryTreeなど便利なドキュメントツールもあるので、Kali Linux内で完結できるようにしています。

VirtualBox上にインストールする

仮想化ソフトウェア、VirtualBoxをインストールし、Kali Linuxのイメージを導入、起動させます。

VirtualBoxをインストールする

あらかじめ下記サイトからダウンロードを行いVirtualBoxをインストールしてください。
今回は、バージョン6.1.12に、Extension Packを導入してますが最新版で問題ないと思います。

VirtualBox 公式サイト
https://www.virtualbox.org/

Kali Linux イメージファイルのダウンロード

Kali Linux Downloads – VirtualBox Images イメージファイルのダウンロード先
https://www.offensive-security.com/kali-linux-vm-vmware-virtualbox-image-download/#1572305786534-030ce714-cc3b
(名前の方をクリックしましょう。Torrentって書いてある方は、イメージファイルを入手するのに別途アプリが必要です。通信状況の悪い時などに使用します。またVMWare用などもありますので間違えないようにしましょう。)

kali linux download

Kali Linux 仮想アプライアンスのインポートと設定

VirtualBoxを起動し、ファイル、仮想アプライアンスのインポートで、先ほどダウンロードしたkali-linux-2020.3-vbox-amd64.ovaを選択しGPLの使用許諾に同意し、インポートします。

kali linux import

初期設定を行う上では、デフォルトのNAT設定でも問題はないですが、ネットワークの割り当ては、診断対象環境との通信の関係上、DHCPで割り振られる環境などでは ブリッジなどにするなど、実施したいこと構築したい環境などによって変更してください。その他は、好みによって設定を変更します。私はCPUは、2コア使用でメモリを4GBぐらいにしています。

kali linux VirtualBox

Kali Linux上の設定

Kali Linuxの起動とログイン

起動ボタンを押し、しばし眺めます。
Kali Linuxの起動を行いログインします。Kali Linuxのパスワードは、kaliに設定されています。
 ユーザー名:kali
 パスワード:kali
Usernameに、「kali」と入力し、Passwordに、「kali」と入力しLog Inを押します。
※以前と違い、rootログインが廃止され、パスワードがkaliに変更されてます。

kali linux login

パッケージの更新

最初に既存のパッケージを最新に更新してしまいましょう。
画面左上の黒っぽいアイコンのターミナルを起動します。
そして下記のコマンドを入力します。しばらく時間がかかり、パスワードkaliの入力や、確認のため途中にy、ニュース閉じるのにqの入力が必要となります。
※以前と違い、ユーザー権限ですので、コマンド前にsudoが必要になってきます。

$ sudo apt-get update
$ sudo apt-get upgrade
kali linux terminal

画面がロックしてしまったら、パスワードを入力して解除しましょう。
また、エラーが出るようでしたら、右上のネットワークの接続について確認してみてください。
ホストPCでインターネットに接続できるようでしたら、一度仮想マシンのネットワーク設定をNATなどにしてみてください。

日本語関連パッケージの導入

ここで日本語関連パッケージをまとめて導入してしまいます。
そして下記のコマンドを入力します。しばらく時間がかかります。
多少、必要のなさそうなものも導入されるかもしれません。

$ sudo apt-get install -y task-japanese task-japanese-desktop
kali linux japanese package

日本語表示の設定

ここで日本語表示の設定をします。
そして下記のコマンドを入力します。

$ sudo dpkg-reconfigure locales

スクロールして、ja_JP.UTF-8 UTF-8をスペースキーで選択、TABキーでフォーカスを変更して、OKでエンターキーを押します。

kali linux locales

同じように、ja_JP.UTF-8を選択して、OKです。

kali linux ja_JP.UTF-8

また、下記のコマンドを入力します。これをやらないとなぜか再起動が複数回必要だったり、反映されなかったりします。

$ sudo update-locale LANG=ja_JP.UTF-8

設定が終わったら、restart(再起動)します。

日本語キーボードの設定

日本語キーボードを利用している人が多いと思いますので、キーボードレイアウトを変更します。
メニューから、設定、キーボードを選びます。

kali linux japanese keyboard

まず、システムデフォルトを使用するのチェックを外します。
キーボードレイアウトがUSとなってると思いますので、選択して編集、日本語のキーボードを選んでください。おそらく、日本語(OADG109A)などがほとんどでしょう。

kali linux keylayout

タイムゾーンの設定

次に時刻がずれてると思いますので、タイムゾーンの設定をします。
下記のコマンドを入力します。

$ sudo dpkg-reconfigure tzdata
kali linux timezone

日本語表示の設定の要領で、アジア、東京を選択します。

Kali Linux 2020.3 導入完了

Kali Linux 2020.3 を、VirtualBoxにインストールし日本語表示、日本語キーボードの利用、日本語変換が行えるようになりました。
バージョン2020.3で追加された機能、ツールは公式ブログの記事、Kali Linux 2020.3 Release (ZSH, Win-Kex, HiDPI & Bluetooth Arsenal)で簡単に紹介されています。
Kaliの新バージョンをベースにCTFなどに参加してみてはいかがでしょうか。

kali linux japanese

さいごに

アピリッツでは、脆弱性診断など各種セキュリティサービスを実施しています。

また、セキュリティエンジニアについても募集しています。Webセキュリティについて学んだことを活かしたい、CTFにチャレンジしてみたい方など歓迎します。興味ある方は、下記の採用情報からセキュリティエンジニアの職務内容・応募資格を確認してみてください。もちろん、Webエンジニアも募集中です。下記ボタンからぜひ確認ください。

最近人気な記事