Photoruction工事中!

Photoructionの開発ブログです!

AWS Chatbotで予算アラートするSlack通知をTerraformで実装する

はじめに

株式会社フォトラクションのSREをしている河野です。 フォトラクションのSREグループではAWS管理を任されているので、コスト監視を導入してみました。

やりたいこと

AWSの利用料金のしきい値を超えたらSlackに通知する。

やること

  1. AWSのマネコンでChatbotを開きSlackにアクセス権限をリクエストして承認する(この記事では省略します。マネコンからChatbotのページを開けばわかると思います)
  2. terraform apply
  3. SlackからAWSリソースを参照してみる
  4. 利用料金が超えるまで待つ

terraformのawsccというproviderを使用します。 terraformの内容と手順はこちらの記事を参考に、弊社の状況に合わせて修正を加えています。 AWS Budget notifications with AWS Chatbot, Slack and Terraform

Terraform

provider.tf

providerはawsに加えてAWS Cloud Control APIを使用するためのproviderであるawsccも追加します。chatbotのリソースはこちらのproviderを使用して作成します。

provider "aws" {
  region = var.region
}

provider "awscc" {
  region = var.region
}

resources.tf

locals {
  account_alias = data.aws_iam_account_alias.current.account_alias
}

resource "aws_sns_topic" "aws_budget_alerts" {
  name = "${local.account_alias}-aws-budget-alerts"
}

resource "aws_sns_topic_policy" "default" {
  arn    = aws_sns_topic.aws_budget_alerts.arn
  policy = data.aws_iam_policy_document.sns_topic_policy.json
}

# AWS Budgetsで予算とSNSへの通知設定
resource "aws_budgets_budget" "monthly" {
  name         = "budget-monthly"
  budget_type  = "COST"
  limit_amount = var.limit_amount
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  notification {
    comparison_operator       = "GREATER_THAN"
    threshold                 = var.threshold
    threshold_type            = "PERCENTAGE"
    notification_type         = "ACTUAL"
    subscriber_sns_topic_arns = [aws_sns_topic.aws_budget_alerts.arn]
  }
}

resource "aws_iam_policy" "chatbot_role_policy" {
  name   = "chatbot-policy"
  policy = data.aws_iam_policy_document.chatbot_policy.json
}

resource "aws_iam_role" "chatbot_role" {
  name               = "chatbot-role"
  assume_role_policy = data.aws_iam_policy_document.chatbot_assume_role.json
}

resource "aws_iam_role_policy_attachment" "chatbot_policy_attach" {
  role       = aws_iam_role.chatbot_role.name
  policy_arn = aws_iam_policy.chatbot_role_policy.arn
}

resource "aws_iam_role_policy_attachment" "chatbot_policy_attach_read_only" {
  role       = aws_iam_role.chatbot_role.name
  policy_arn = data.aws_iam_policy.read_only_access.arn
}

# chatbotとSlackの連携の設定とSNSのサブスクライブ設定
resource "awscc_chatbot_slack_channel_configuration" "aws_budget_alerts_slack" {
  configuration_name = "slack_aws_budget_alerts"
  iam_role_arn       = aws_iam_role.chatbot_role.arn
  slack_channel_id   = var.slack_channel_id
  slack_workspace_id = var.slack_workspace_id
  sns_topic_arns     = [aws_sns_topic.aws_budget_alerts.arn]
  logging_level      = "ERROR"
}

awscc_chatbot_slack_channel_configurationでいろいろしてますので、やっぱり公式を参照するといいと思います。 awscc_chatbot_slack_channel_configuration

こちらのterraformでは、chatbot-roleに対して後述するdata.tfで取得したReadOnlyAccessのポリシーを付与しています。 slackからChatOpsするために権限を広く付与しているため、実際には適切な権限を付与するようにご注意ください。 (参考)SlackとAWS ChatbotでChatOpsをやってみよう

data.tf

data "aws_iam_account_alias" "current" {}

data "aws_iam_policy" "read_only_access" {
  name = "ReadOnlyAccess"
}

data "aws_iam_policy_document" "chatbot_assume_role" {
  statement {
    actions = ["sts:AssumeRole"]

    principals {
      type        = "Service"
      identifiers = ["chatbot.amazonaws.com"]
    }
  }
}

data "aws_iam_policy_document" "chatbot_policy" {
  statement {
    actions = [
      "sns:Subscribe"
    ]
    resources = [
      "*"
    ]
  }
}

data "aws_iam_policy_document" "sns_topic_policy" {
  statement {
    actions = [
      "sns:Publish"
    ]

    principals {
      type        = "Service"
      identifiers = ["budgets.amazonaws.com"]
    }

    resources = [
      aws_sns_topic.aws_budget_alerts.arn
    ]

  }
}

複数のAWSアカウントからの通知を想定してアカウントのエイリアスを取得しています。

variables.tf

variable "region" {
  type = string
}

variable "slack_channel_id" {
  type = string
}

variable "slack_workspace_id" {
  type = string
}

variable "threshold" {
  description = "予算に対して何%で通知するか"
  type        = number
}

variable "limit_amount" {
  description = "利用料金($)の予算、なぜかstringらしい"
  type = string
}

SlackからAWSリソースを参照してみる

awsをChannelに追加してから@awsawsに話しかけるとコマンドが実行できます。

# 例
@aws sns list-topics

取れました。ARNにAWSが主張しているのはご愛嬌。(:aws:でEmojiが登録されているためです)

予算アラート通知

少ない予算ですぐに通知が来るようにして通知結果を確認しました。

結局アカウントIDしかAWSアカウントを特定するものがなかったので、Budget nameあたりにアカウント特定のエイリアスを入れると良さそうです。

まとめ

terraformで予算アラートを設定してみました。マネコンからの操作があるのはどうしようもなかったですが、割と簡単に予算通知を入れることができました。 AWSアカウントが増えすぎると結局管理が大変になるのでAWS Organizationsなどのサービスも検討していこうと思います。

株式会社フォトラクションでは一緒に働く仲間を募集しています

目標設定の改善をおこなってみる

CREチームリーダー田中です。突然ですが、目標設定って難しいですよね。

一メンバーとしてもそうですが、リーダーとして、メンバーの目標設定をフォローする立場になり、より難しいな〜と感じています。

今回、記事を書くにあたり、より良い目標設定や、フォローアップができるよう、勉強して、改善に繋げてみようと思います!

目次

実際にCREチーム内で立てたやり方

実際立てていたのは以下のような目標です。

  • 調査タスク○件
  • 調査対応○件(PR数)

前提として、

目標設定は、評価制度に紐づいています。

CREチームメンバーは、未経験エンジニアを採用し構成されています。

不具合の調査や改修チケットをこなしていくことで、スキルアップしてもらい、開発チームに巣立って行ってもらうことを目標に置いています。

なので、ある程度数をこなして成長してもらえるような指標を置いています。

尚且つ、評価者、被評価者が評価しやすい(されやすい)且つ、評価に納得しやすくなるよう、できる限り定量的な値を置くことを意識しました。

なぜ、目標設定するんだっけ?

目標設定の概要は、Wikipediaではこうなっているらしい。

目標設定には、個人またはグループを動機づけ、目標に向かって導くために設計された行動計画の作成が含まれます。目標は、願望や瞬間的な意図よりも計画的なものです。したがって、目標を設定するということは、人が目標を達成するために思考、感情、行動をコミットさせることを意味します。

つまるところ、目標設定とは、以下に言い換えられます。

  • 目標を達成するために立てるもの
  • 突発的な願望ではなく、プランニングが必要
  • 「目標を達成するぞ!」と気持ちを固めること(=コミットする)

1点目、2点目は、まぁそうだよなと思いましたが、3点目は個人的には意外でした。

字面の通り、「目標」を「設定」するというアクションの意味だけではなく、

そのアクションに「達成するぞ!」という感情が乗ってくるのが非常に面白いなと。

上記は英語のWikiを和訳したので、英語圏の方々の目標設定の価値観なのかもしれないですね。

当たり前ではありますが、達成するために、目標を立てる精神は大事!

目標設定のフレームワークを見てみる

次に、目標設定の文脈でよく使われるフレームワークを紹介します。

フレームワーク

  • MBO
    • 目標管理制度(MBO:Management By Objectives)
    • ピーター・ドラッカーが提唱したプログラムで、担当者が主体的に業務目標を設定し、その進捗を自ら管理する手法
    • メンバーが自分で目標を決めるため、主体性を伸ばし、パフォーマンスやモチベーションを高めたり、人材育成、人事評価の効率化したりと、様々な効果が期待できる
    • 人事評価に紐づいた、個人目標
  • OKR
    • 目標と成果指標(Objectives and Key Result)
    • MBOから派生した、目標管理の一種
      • MBOとの共通点
        • 組織と個人の目標を共通化すること
      • MBOとの差別点
        • 組織の評価制度と紐付けない
        • 難易度の高い目標に挑戦させることにより、飛躍的なパフォーマンス向上を狙う
    • 人事評価に紐づかない、個人目標
  • KPI
    • 重要業績評価指標(Key Performance Indicator)
    • KGI (Key Performance Indicator。重要目標達成指標)を達成するにあたって、その過程で、どれくらいの状態をクリアしていればいいのかを可視化して、計測するための指標
    • 個人目標ではなく、あくまで業務目標

参考:https://www.staffservice.co.jp/client/contents/management/column031.html

SMARTの法則

また、「目標設定 やり方」とかで検索するとSMARTの法則というワードが上位に出てきます。目標設定の定め方としてよく使われる考え方で、以下の頭文字の単語を総称しています。

  • Specific(具体的に)
  • Measurable(測定可能な)
  • Achievable(達成可能な)
  • Relevant(経営目標に関連した)
  • Time-bound(時間制約がある)

こちらは、Relevant(経営目標に関連した)とあるので、人事評価に紐づいた、個人目標の文脈のようですね。MBOの目標設定の方針と合致するので、こちらを基に改善してみようと思います!

参考:https://globis.jp/article/659

改善に繋げよう

今回立てた目標と改善点

実際立てていたのは以下のような目標です。

  • 調査タスク○件
  • 調査対応○件(PR数)
  • Specific(具体的に)

    →チケット単位なので、何にコミットするか具体的である

  • Measurable(測定可能な)

    →チケットの件数は定量的である

  • Achievable(達成可能な)

    →ストレッチ目標で立てていますが、達成不可ではない(と思っています)

    • ただメンバー本人が達成できると信じられているかは不明(擦り合わせられていないかも)
  • Relevant(経営目標に関連した)

    →CREチームの業務内容に合致。スキルアップをチーム目標に置いているのでそちらにも合致します

    - こちらも、明示して、目線合わせできてるわけではない

  • Time-bound(時間制約がある)

    →半期内の区切りはしているが、中間目標としては置けていなかったので、改善!

改善後イメージ

  • Achievable(達成可能な)
  • Relevant(経営目標に関連した)

の目線合わせを行った上で、例えば、

○/○~△/△までに、調査対応○件(PR数)対応する!

みたいな文言で目標を定めようと思います。

今回定めた目標設定をフォローする

上記は、来期の目標設定の時に活かすとして、

今回不十分だった点は、コミュニケーションでカバーしようと思います。

具体的には、以下の2点。

  • Achievable(達成できる)
  • Time-bound(期限が明確な)

隔週で1on1を実施しているので、その際にこの観点を確認し、意識づけてもらおうと思います!

まとめ

意外と体系的に学ぶことのない、目標設定。

もちろん、目標達成することが第一ですが、達成できた/できないに囚われすぎるのはそれはそれでよくないなと思っています。

その過程で、どれだけできることが増えたかなど、成長率にも重きを置いていくことを忘れず、目標達成のフォローをしていこうと思います!

株式会社フォトラクションでは一緒に働く仲間を募集しています

目標設定と1on1での成果確認の重要性を実感

QAチームリーダー塩谷です。

今年は目標設定の重要性と1オン1での成果確認の重要性を改めて感じる機会がありましたので、振り返りを含めて記事にしたいと思います。

目標設定について

皆さんは自己成長のために、自身の上司とスキルアップや業務における成果目標などの設定を行い、その内容を共有しているでしょうか?

時間は否が応でも流れていき、時代は移り変わっていきます。

会社は時代に合わせて成長していかなければ廃れてしまい、会社を成長させていくためには社員それぞれが成長していかなければなりません。

そして成長に欠かせないのが目標設定とその成果確認になります。

設定した目標を上司と(会社と)コミットし、その成果を確認することで、各自の成長度合いを把握することができ、会社は適切に各自の評価をすることが出来ます。

また管理側では、各自の目標を管理することでその人がどういう方向性に進んでいきたいのか、目標に対して順調に進んでいるか・問題は発生していないか、モチベーションを維持できているかなどの把握がしやすくなります。

1オン1について

多くの会社で1オン1を実施していると思います。

1オン1では、メンバーの成長を促す目的や何か問題を抱えている・会社に対して不満が溜まっているのを取り除き従業員満足度を高める目的などがあります。

普段コミュニケーションを取っている関係でも改めて時間を確保することで

雑談などでは話せない問題を話したり、1オン1だからこそ意味のある会話が生まれたりします。

私はメンバーと月に一度1オン1を設定しており、その中でメンバーの目標設定に対する進捗を確認しています。

目標設定に対する進捗を確認することで、ちゃんとアクションできているか・問題が発生していないかを確認でき、問題がある場合には1オン1の中でメンバーと対話して解決していきます。

またアクションを起こした結果、元々の目標設定が良くなかった場合は、目標自体を変更していくこともあります。

目標設定の大切さ

今年はある事情によって目標設定をしなかったケースがありました。

結論から申し上げると該当のメンバーは退職という形になりました。

退職の理由は様々ありますが、振り返ってみると会社からの期待値と本人の方向性と現状が一致していなかったことが原因の1つにあったと思います。

1オン1を実施する時に「何か問題はない?」という曖昧な質問をしてしまい、

問題を的確に捉えることが出来ずに、1オン1を重ねることで根本的な問題があると考え、

しっかりと目標設定を行なって、1つずつステップアップしていこうとしていた矢先に退職という結果になりました。

もっと早く目標設定を一緒に実施していれば、本人の将来の意向と現在地を精度を高めて把握できたと思います。

さいごに

目標設定や1オン1は多くの会社で取り入れていると思いますが、形式的に実施しているだけになっていないでしょうか。

特に管理者は優秀な人材を流出させてしまわないように、1オン1などで小さな問題をしっかりとキャッチアップできるように心がける必要があります。

会社として実施している様々なイベントは、決して形式的なものと考えずにそれぞれが意義のあるものとして捉え、取り組んでいきたいと思います。

株式会社フォトラクションでは一緒に働く仲間を募集しています

1on1から得た学び

はじめまして、CREチームのトヨカズです!

今回のテーマは定期的に行われるけどルーティン化されがちな1on1について、自分のアクションや意識をどう変えたかについて執筆しました!

自分の経験が、誰かの役に立つかはわかりませんが、きっかけ作りの一端を担えればと思いますので、興味がある方はぜひご一読お願いします🙇‍♀️

以前の記事はこちら↓↓↓

kojichu.photoruction.com

1on1について今までどのように考えていたか


皆さんは1on1を上司とするにあたり、どんなことを意識してますか?

僕は、今まで1on1を以下のような場だと思い、望んできました。

  • 分かんないこと/困っていることを相談する場

普段のデイリーは、全体会議のため時間の都合上細かすぎる内容については聞くことができないため、1on1という場で詳細なことを聞くことで情報の補完を行うものだと思っていました。

また、自分がその際困ったことなどを共有することで、上長はそれに対して何かしらのアドバイスをくれるという認識で、受け身の姿勢であったと思います。

これは1on1に限った話ではなく通常の会議にも言えることですが、ファシリがいるとどうしてもその人任せで主導してもらうことが多くなり、受け身でいる事が多い気がします…(もしかすると、日本人特有のものかも?)

招待された参加者気分であったのが今までの僕です。

1on1を意識するようになったきっかけ


1on1を4~5回こなしたくらいから、ふと振り返ったときあることに気づきました。それは相手に題材を用意してもらってそれをもとに、質問をされることで回答をしていくという一方通行のコミュニケーションがなされているという事。つまり、受け身の姿勢であるという事実をここで初めて理解しました。

きっかけは些細な事で、過去の1on1の内容をまとめた議事録を読み返したから得られた気づきでした。内容を見ていると、質問された内容についてただ回答しているだけで、学校の授業となんら変わらない受動的なスタイルが1on1では起きていました。

このままの状態では、自己成長できるはずがないと思い、改めて1on1について考える事にしました。

そもそも1on1って


自分にとっての1on1とは何かを考えた時、「成長機会を得る場であると同時に自分にない視野・視点・視座からの気づきを得る場」であると思いました。

上長だからこそ見える視点、自分だからこそ見える視点、それぞれの視点を共有する事で、自分にはない視点に気づく事ができる。その視点を得ることで、別のアプローチを試せるようになったり、問題解決への糸口を掴む事ができるのかなと思います。

また、成長機会を得る場であるという意識は結果として、自発性を促進する効果もあると考え、これらの気づきを得る事が自分にとっての1on1の定義かなと思いました。

これらを念頭に、具体的に1on1をする際にどんなことを意識するようになったのかについてお話ししていきます。

1on1で意識するようになったこと


1on1の意義を再確認し、以下のようなアクションを試すようになりました。

1.自分が気付かない視点からのアドバイスをもらう

自分からの視点だと、物事の一部しか見る事ができず、その部分以外を見る事ができません。

そのため、1on1では2週間の振り返りとして以下のような形でフィードバックを取りに行くようにしています。

下記は実際に使っているテンプレートです。

💡 <先週の振り返り>

- 先週、先々週で、行動で何かまずいところや要改善ポイントはあった(見つかった)か

[自分視点]

- 〇〇について、〇〇のようなアクションをとれば、工数を削減できた。

[リーダー視点]

- 〇〇のタスクについては、こういうアクションをとることもできたのではないか。

2.成長機会の場という意識

認識を改めたことで、1on1は自己の成長機会の場であると考えられるようになりました。事前にアジェンダをまとめて情報を提供することで、今の自分に必要なアドバイスを得る事ができ、30分という短い時間でも濃密な時間を過ごす事ができています。また、それを元に質問を受ける事で、自分の思考の癖なども知る事ができ、自分を知る機会にもなっていたりします。

3.「1on1という場」を一緒に作っていく意識

2と関連してるのですが、自己の成長の場であるという意識を持つことは受身の姿勢がなくなり、自然と前のめりになるため、「1on1という場をどういう場にしたいか?」を考えるようになりました。会議などでもそうですが、自発性がないとどうしても聞き手に回りがちだと思うので、「成長機会を得る」という意識は副作用として、色々な面で役に立つなと改めて思いました。

意識したことで、どのような効果があったか


効果としては、主に2つあります。

  • 自分の行動を省みるきっかけを作ることができた
  • 他の人の経験や知識から、自分の視野を広げる事ができた

自分の行動を省みるきっかけを作ることができた

業務をこなしていると自分の行動を省みるタイミングって中々作りづらかったのですが、1on1のタイミングで、その機会を作る事ができたので、結果として業務中でも「これは1on1で相談したい案件だな〜」みたいな成長機会を得るための意識が以前よりも働くようになりました。

他の人の経験や知識から、自分の視野を広げる事ができ、複数の視点も持てるようになった

他の人の視点から得た学びを自分の視点に活かす事ができ、結果として視野を広げて物事を判断できるようになっていると思います。例えば、今までは自分の視点頼りの発想も別のアプローチを試みることもできるようになり、幅が広がった気がします。

1on1を通して感じた大事なこと


これは個人の主観になりますが、やはり自発性が大事だなと思いました。ただ、今回のようにそもそも自分が受け身であるということに気づけないと、自発的に何かをやるといった行為は難しいと思うので、自発性と同じくらい自分の行動を省みる事が大事であるなとも思いました。

株式会社フォトラクションでは一緒に働く仲間を募集しています

Vimの繰り返し操作まとめ

こんにちは。CREの田島です。

少し前からAI活用エディターのCursorが話題ですよね。

ただし、本記事は生まれたてエディターCursorについてではなく、リリース32周年を迎えたVimについての記事になっていますので注意です。

「AIを活用した」なんて甘美な響きではありませんが、Vimにも魅力的な個性が多いですよね。

キーバインドがその代表かと思いますが、「繰り返し操作のやりやすさ」もそのひとつかなと思ったので、Vimの繰り返し操作についてまとめました。

直前の変更を繰り返す

.(ドット)を使います。

例えば、ddで一行削除した後に、.を押すと一行削除が繰り返されます。

直前のExコマンドを繰り返す

@:を使います。

例えば、:vsでウィンドウを分割した後に、@:とするとさらにウィンドウを分割します。(この場合、:vsをもう一度入力する方が楽かもですが、例として)

履歴からExコマンドを繰り返す

q:を使います。

Exコマンドの履歴と一緒にコマンドラインウィンドウを表示します。

履歴を編集してExコマンドを実行することも可能です。

履歴から検索を繰り返す

q/,q?を使います。

検索履歴と一緒にコマンドラインウィンドウを表示します。

履歴を編集して検索をすることも可能です。

(検索には正規表現を使用できますが、クセがあります)

直前の置換を繰り返す

:&&を使います。(:&&の場合、現在行のみに作用します。)

以下のテキストを編集するとします。

Photoructionは建設業の生産性向上を目的としたクラウドサービスです。
テクノロジーとオペレーションの力で10倍を超える業務効率化を実現します。
大手ゼネコンをはじめ、100,000を超える建設プロジェクトで導入されている国内最大規模のサービスです。

私たちが考えるのは常に建設業で働く皆様のことです。
主力サービスである建設生産支援クラウドPhotoructionは、
リリースして3年半ほどで100,000を超える建設プロジェクトで使われるようになりました。

3行目の100,000を200,000へ置換した後、7行目も同様に置換したい場合は、:&&とすればOKです。

↓入力キーの例

3G
V:s/100,000/200,000/g
7G
:&&

ひとまとまりの操作を繰り返す

1~10の連番生成を例にします。

レジスタaに記録し、それを繰り返します。

↓入力キーの例

i1<Esc>
qa
yyp<C-a>
q
8@a

(単純な連番生成ならマクロ使わない方が楽です)

↓入力キーの例

yy9P
VG
g<C-a>

直前に実行したマクロを繰り返す

@@を使います。

直前に記録したマクロを実行したい場合は、Qです。

まとめ

これらの繰り返し操作がコーディングの中で使われることは稀だと思います。

ただ、エディターとしてではなく、テキスト整形ツールとして見たとき、これらの操作が輝ける瞬間があるかもしれません。

株式会社フォトラクションでは一緒に働く仲間を募集しています

AI開発の特徴とチーム雰囲気のご紹介!

こんにちは!

株式会社フォトラクション デジタルOpsグループでプロダクトマネージャーをしている若井です。

私の所属するデジタルOpsグループは、AI技術であるかどうかに関わらず、様々な技術を駆使して、建設BPOメニューにおけるオペレーターの作業自動化・効率化のためのシステム開発や研究開発などを担っています。

今回は、AI技術を用いた開発について、これまで経験してきた観点から、どんな特徴があるのか、チームの雰囲気を交えて紹介します。

AI開発の特徴

1.不確実性

  • モデル精度の不確実性

    AIプロジェクトは、開発するAIモデルの精度が読めず、それによってどのように学習するか、他の工夫を施して着地させに行くかなどと、次の工程の選択肢が状況に応じて変わります。

    また、100%完璧なAIを作ることは技術的に困難であり、最終的なAIモデルの精度によって、利用方法に対して柔軟に最終的な仕様を変える必要があります。

  • 開発工数の不確実性

    上記によって工程が変わるということは、進捗も大きく変動するため、予め定めるスケールジュール通り進めることはとても難易度が高く、常に開発スケジュール調整しつつ今やるべきことそうでないことの見極めがとても重要になります。

2.必然ゆるアジャ (ゆるいアジャイルの略)

  • 週1~2回の定例

    開発したAIモデルの精度は、定例の中でチームで共有し、エンジニアをはじめチーム全体で、精度改善のための仮説や意見を出し合い、次の学習や前処理、後処理などへの施策を決定したりします。

    AIモデルの学習時間は長く、開発期間はもちろん、コストやGPUなど使えるリソースにも限りがあり、その中で何を試し実行するか、試す価値の高い(優先度の高い、費用対効果の高そうな)施策から試行していく必要があります。

    そのため必然的にゆるアジャになります。(※去年のアドカレで田中さんが提唱したゆるラム(=ゆるいスクラム)なるもの)

  • 開発精度によって変わる施策

    まず前提として、開発前に目的とする機能に応じて期待する精度の水準は異なります。例えば、概算見積に利用するAIであれば8,9割程度の精度で良いかもしれませんが、正式見積の場合は完璧である必要があるなど、同じ90%の成果でも用途に応じて許容できる範囲は異なります。また、一度やってみないとどの程度の精度がでるのかどうかは未知に近いため、想定と異なった場合の切り替えや事前にあらゆる予想をしておきプロジェクトの方向性をコントロールすることはAI系のプロジェクトマネジメントにおいてとても重視すべき点だと感じています。

    また、開発したモデル精度に応じて、追加学習するのか、別のアプローチで補填しにいくのか判断する施策も異なってきます。

3.必要なスキルセット

  • ハードスキル

    • AI・コンピュータービジョンなどの技術知識

      AIエンジニアといってもDeepLearingや機械学習についての理解があればいいというわけではなく、目的を果たすにはどのような技術を選定するか(AIを使わなくても十分かどうか)という視点が必要です。

      AI(教師あり)であればどのようなモデルを採用し、どのようにチューニングして学習させていくか(データ処理や損失関数、最適化関数など)を判断していく能力が必要です。

    • ドメイン知識

      特に弊社のような建設に特化したAIやその他自動化のための機能開発を行うチームでは、当たり前のことですがドメインの知識は必要不可欠です。

      例えば、医療や金融、製造業などにおけるAIまたは機械学習エンジニアには高精度かつ汎用性の高い効果的な機能開発にはドメインの知識は非常に重要です。

      その点において、弊社のAIを開発するチーム(デジタルOpsグループ)は建設業出身者または大学で建築を専攻していメンバーが大半で、図面の解読や建設プロセス全体の理解などに通常AIエンジニアに比べて長けているのが特徴的です。

  • ソフトスキル

    • 問題解決力
      • 常に課題や問題を見つける姿勢で物事を見て、その課題を一つ一つ解決していくためにPDCAサイクルを進めていくことは、DeepLearnigなどの場合技術的限度はあるにしても、例えば不得意データを集中的に学習データとして利用するなどで高精度で汎用的な機能の実現に向かいます。
    • 柔軟性
      • 開発進捗と状況に応じた施策の決定が必要です。
      • 特定の技術などの手段にとらわれずにあらゆる手法の中から最適な手法を導き出すことはとても重要で、それらを事前に調査する能力も必要です。

デジタルOpsチーム紹介

AI開発において、上記のような力が求められますが、幸いにも私は恵まれた環境でPMをしており、対処や方向性についてリードしてくれる心強いメンバーに囲まれています。

  • リーダー:要件定義も開発も方向性を支えてくれ、最終的に泣きついたら絶対大丈夫な解決策をもらえて心強いです。
  • PM:普段の仕事はBPOメニューの要件定義、プロジェクトの進捗管理をしています。
  • エンジニア:技術面はもちろん、PMの視点(建設の理解や運用後を考慮した仕様)も意識して、解決策やアイデアを出してくれて心強いです。
  • QA:AIワークの品質を保つためデータ作成やテストケース、テスト自体に注力してくれて、いつも助けられてます。

こんな感じで色んな人に支えられながら、密接にコミュニケーションを交わしながら、開発していく雰囲気です。(というより、一方的に恵んでもらっているPMの構図でしたwww)

実際は、AIを使わない開発も多い

AIを使わなくても、画像処理技術で十分な精度が出る場合や、そもそもとして精度が伴わないシステムを作るときはAIを使わないプロジェクトも多々あります。

AIが適切かどうかは、許容される精度や、学習できるデータ量、開発工数、コストなど、あらゆる判断材料から決めます。

大事なのはAI(DeepLearnigや機械学習など)という技術は、建設業をスマートにする上であくまで手段に過ぎないということです。

なんでもかんでもAIを使おうとすることは、芝刈り機があるのにわざわざチェンソーを使って芝を刈っているようなものですね。


以上、デジタルOpsの開発雰囲気とAI開発の特徴について、お伝えできましたでしょうか?


まとめ

AI開発の特徴

デジタルOpsチーム雰囲気

  • 心理的安全性が高く、互いに尊重
  • OpsとデジタルOpsで部署を超えたコミュニケーション
  • PMは恵まれている
株式会社フォトラクションでは一緒に働く仲間を募集しています

デジタルOpsチームへインタビューしてみた。

皆さんこんにちは、CREチームのとよかずです!

今回は、前回の続きとなるインタビュー形式での記事となっております👏

インタビューに協力いただいたのは…

デジタルOpsチームです!!!

普段、デジ推とは関わる事がないので、実際どういう業務をしているのか僕自身あまり知りませんでした💦

しかし、インタビューをしていく中で、チームカラーだったり、チームリーダーの菊池さんの素顔だったり、メンバーとの関係性だったり、他部署にいては決して見られないであろう部分をたくさん見させてもらいました🥺

チームの方々の人柄もわかる内容となっておりますので、ぜひ見ていってください✨

前回のインタビューが気になる方はこちら↓↓↓

kojichu.photoruction.com

✨デジタルOpsへのインタビュー✨

とよかず:それではさっそく始めていきたいと思います!まず始めに、御三方の簡単な自己紹介をお願いします🙇‍♀️

菊池:デジタルOpsグループのチームリーダーの菊池です。

大学では建築を専攻していました。在学中に独学で機械学習・DeepLearningを学び、その後インターンとしてフォトラクション(当時concore's)にジョインしました。大学卒業後にそのまま社員として入社し、建築におけるAIの研究と開発を行うこのグループを一から築き、グループリーダーとして活動しています。

志賀:デジタルOpsグループのAIエンジニア志賀です。

大学卒業後に大手IT企業に入社し、約1年半ほどSalesforceの導入支援業務に務めていました。その最中に、AIにとても興味を持つようになり、前職を退職し、AI開発について学べるスクールに通いました。そこから、4年ほど前にフォトラクションに入社し、いまでは建築を専門とするAIの設計から開発を一通り担当しています。

若井:同じくデジタルOpsグループのPdM若井です。

大学で建築を先行しており、前職では約3年ほど建築積算を行なっていました。AIにとても興味があり、AIについて学べるスクールに通い論文実装などを経験しました。そこから、前職退職し約︎4年ほど前にフォトラクションへ入社し、今は建築とAIのプロダクトにおけるPdMを主として企画、要件定義を担当しています。

Q.デジタルOpsチームでの業務について教えて下さい!

菊池:主な業務としては、建設業界のBPOサービスを提供しています。大まかにいうと、お客様から依頼された業務についてオペレーションを通して作業実行していきますが、これを担当するのがオペレーターです。そして、デジタルOpsチームでは、機械学習やDeepLearningなどの技術も駆使してそのオペレーターの業務を自動化可能にするシステムの構築を担っています。機械学習ディープラーニングに限らず画像処理やその他プログラミング技術などを含み、様々な手段で業務の自動化を進めるためのプロダクトを開発しているのが、我々の主な業務になります。

Q.そもそもなぜ、業務効率化をする必要があるのでしょう?

菊池:日本全体の社会問題として少子高齢化という問題があり、この問題が建設業界でも深刻化しています。そこに加え、”3K”といわれるイメージもあり、人が集まりにくく、人材の確保が難しい業界となっています。建設業界の現状の課題に対して、我々はBPO事業を通じてアウトソーシングの形でサービスを提供します。お客様のお仕事を代行させていただくことにより、その時間を他の業務に充ててもらうことで、一人当たりの生産性を高めてもらえるように努めています。

ただ、我々がお客様のお仕事を担わせていただく上で、人海戦術的にリソースを割くわけにもいかず、より効率的に少ない人数で、多くの生産性を出すことが事業として求められます。そこで、AIなどのプログラミング技術を活用して業務の自動化をはかるAI BPOが必要となっています。

とよかず:少子高齢化の問題は、建設業界では喫緊の課題の一つであり、それを解消するための先駆けとしてまずはAIを導入して、生産性向上を目指していこうってことなんですね〜

わかりやすい説明ありがとうございます🙇‍♀️

次に、チームについての質問に移りたいと思います!

TSイベントの時の菊池さん

Q.メンバーから見た普段の菊池さんは、どんな人ですか??

志賀:自分は菊池さんと同年代になるのですが、同年代にはなかなかいないタイプだなと思っています。親しみやすいだけでなく、組織の中でのBPO事業のあり方を常に考えていて、優秀!の一言に尽きます。

例えば、我々エンジニアが組織に貢献しようとするとできることとしては、BPO事業の作業効率を如何にして上げるかを考える事になります。作業効率だけに留まらず、事業全体を通して重要な売り上げを増やす戦略やオペレーション全体の作業効率を上げる戦略の両方などを包括的に管理できる人材の一人ではないかなと私は考えています。

若井:志賀さんの言う通り、菊池さんは役割を超えて色々なことをやっていますね。デジタルopsやオペレーションなど、役職を超えてあらゆる範囲を管轄しています。メニュー企画チームの部分をカバーしたり、配筋検査メニューの売り上げを上げるための施策を考えたり、様々な人を支えてるので、私からしたらチームリーダー以上の存在に思えます。

志賀:それは確かにありますね!

まだBPO事業が始まったばかりの頃は、開発側とオペレーションのコミュニケーションが上手くいってない部分があったのですが、そういった点も菊池さんがお互いのチームのシナジーを生み出せるように動いていたのが印象的でした。

とよかず:菊池さんの人柄から、仕事の姿勢まで幅広く教えてくれてありがとうございます!

社内でも、菊池さんは何をやっている人なのか分かりづらい部分があったので(色々やりすぎて)そういった意味で、だいぶ解像度が上がってきました!

菊池:実際、BPO事業って一つの事業部みたいな感じになっているので、SaaSチームとは別にデジタルOps専任のテスターの方もいたりします。TS部として一つの括りになっていますが、別のサービスを提供してるようなものなので、普段関わりがないとどんな事をやっているのか分かりづらい部分はあると思いますね〜

とよかず:僕は普段、他の部署の方と絡む機会が多いのですが、中々AIチームの方達と絡む機会はなかったので、組織内でのAIチームの位置付けを知ることができよりクリアになりました!

逆に、お伺いしたいのが…

Q.菊池さんから見たメンバーの印象はどうですか?

菊池:デジタルOpsのメンバーは、チーム愛がすごく高く、和気あいあいとしています。ちゃんと業務の中でコミュニケーションも取り合えるし、たまに誰かと誰かがぶつかちゃったりもしてますが(翌日何事もなかったように仲直りしてる笑)、何より同じ方向を見れているなと感じます。自分としては非常にやりやすいです(笑)

みんな協力的ですし、自分の仕事さえ良ければいいやみたいな考え方を持ってる人が一人もいなくて、誰かが苦しんでたり、辛そうにしていたら助けたり、一緒に解決するにはどうすればいいかを考えられたり、フォロワーシップの精神をみんなが持っている印象です。

とよかず:いいですね〜

僕は今回質問をしてるだけですけど、お互い信頼してる感じを間近で見れるのもこのポジションならではなので、この企画様様って感じです(笑)

菊池:普段こういう事をチーム内で話さないんですけど、言わずもがなで信頼しあっている感じはあると思います!

志賀:コロナになる前は、出社だったのでそういった部分も大きいかもですね。

菊池:確かにそれはあるね〜

オフラインだからこそ、そういった関係を作れた部分はあるかなと思います。今の人たちは、オンライン上でやり取りしないといけないと思うので、オンライン前提でチーム構成組み立てるのは結構大変そう…

とよかず:テレワークだと、どうしてもマンパワー的な部分は必要になってきますよね。リーダーのみならず、メンバー側も協力しないとチームを作っていくって難しい部分あると思います。

志賀:あと、うちは結構飲み会も多いかもですね!

とよかず:(最高です🥹)

Q.組織に対して、デジタルOpsとしてはこれからどう貢献していきたいですか?

菊池:今後のデジタルOpsチームの組織的な立ち位置とか、どういう構成にしていくべきかなどBPO事業はまだ始まったばかりというのもあり、よめない部分もありますが、少し脱線した話をすると…

例えば、ChatGPTのようなチャットツールはUI部分こそシンプルな作りでありながら、その背後にある技術力によって、非常に高度な機能を提供できるようになっています。これをphotoructionに置き換えると、極端な話しボタン一つで建物が立つようになることがサービスとして目指すべき場所になるのかなと考えています。今のレベルだとできないことが、1年後、2年後と進むにつれて、もっとレベルは高くなり、さらに学習ができ、より高度な事を行えるようになる。これを建設業界に用いることで、提供するサービスをよりシンプルにし、『建設の世界を限りなくスマート』にするというビジョンをより具体化できると思います。

つまり、デジタルOpsでは今までの技術力を活かして、今よりも高度で汎用的に課題を解決できるようにすることが組織と建設業そのものに対しての貢献であり、目指すべき方向だと考えています。

とよかず:まだフォトラクションのことを全て知ってるわけじゃないですが、色々お話を聞いてちょっと未来のフォトラクションを見た気がします。とても勉強になりました、ありがとうございます!

おわりに

今回は、デジタルOpsのインタビューをさせてもらいましたが、チームリーダーとメンバー間の信頼の深さを知ることができ、様々な質問をする中で、とても素晴らしいチームコミュニケーションを見せていただきました!笑

インタビュー形式だと、普段の雰囲気がモロにでると思うので、そういうチーム形成ができている事が本当にすごい事だなと感じましたし、一人一人のメンバーがチームを作っていこうとしてるからこそのチームカラーだったと思います!

ぜひまたインタビューさせてください!ありがとうございました✨

株式会社フォトラクションでは一緒に働く仲間を募集しています