新メンバーと一緒にプロダクトを作っていくためのプロダクトの考古学

こんにちは、M&Aクラウドの塚原(@AkitoTsukahara)です。先日5月のPHP勉強会にて「オンボーディングのために私はプロダクト考古学者になりました!」というテーマでLTさせていただきました。LTという枠の都合上テンポ重視でまとめた資料になっていたため、今回は読みさやすさを意識して記事形式でリライトさせていただきました。皆さんのチームのオンボーディング活動の参考になれたら幸いです。

プロダクトの考古学とは?

「プロダクトの考古学」というキーワードはM&Aクラウドが考えた造語になります。弊社では以下の定義でこのキーワードを活用しています。

  • リリースからしばらくして安定稼働しているアプリケーションがどのように実装されてきたのか?現在の形になった経緯をまとめる取り組み
  • プロダクト・アーキテクチャの成長過程を知ることで、設計思想を知る・理解する機会を作ること

プロダクトの歴史を紐解くような取り組みは皆さんの現場でも実施されていると思います。その取り組みに近いものだと捉えていただければ、大丈夫です。

プロダクトの考古学とは

この取り組みで達成したいことは?

1番達成したいことは新しく入社してくれたメンバーのサポートいわゆるオンボーディングになります。M&Aクラウドのプロダクトはリリースから5年以上経過しています。その間にNuxt.jsの採用、新規プラットフォームの立ち上げなど上げ出したらキリがないくらいにいくつもの変遷がありました。その変化に比例するようにファイル数、コード行数はかなり膨大なものになっています。

そのため、新メンバーはチームに合流してから暫くの期間はプロダクトのコードを理解することに多くのリソースを割く必要があります。LTで以下のスライドを紹介したのですが、皆さんの現場でも似たようなシチュエーションはあるのではないでしょうか?

期待するメンターと遠慮する新メンバー

ここで「プロダクトの考古学」が役に立つのです。 なぜ現在の形のプロダクトになっているのか知らなければ、どのように実装すべきか判断するのは困難です。ましてやリファクタリングや改善提案するのはもっと難しいですよね。実装や提案できるまでのハードルを越える努力を個人に丸投げしないでチームの共通課題にして、取り組んでいくことが考古学の大事なことだと考えています。

せっかく入社してくれたメンバーにはチームのみんなが「新メンバーが存分に活躍できるようにサポートしたい」、そして「チームで協力してプロダクトを育てられる職場で働きたい」と考えています。プロダクトの考古学の取り組みはその想いを形にする取り組みとも言えます。

M&Aクラウドでの取り組み

では、具体的にM&Aクラウドではどのような取り組みが行われているのかご紹介させていただきます。

取り組みのゴールは新メンバーが「思想を理解できる」と言える状態になることを目指しています。何をもってして思想理解になるのかは明確な線引きが難しいですが、私たちのチームでは主に2つのイベント「社内LT」、「査読会」を経由して、新メンバーの理解を促しています。

毎週30分の社内LTを開催

M&Aクラウドでは毎週水曜日がオフラインでの出社日になっており、その日はエンジニアメンバーが顔を合わせて、気になった設計を共有する機会を設けています。現在は2名の推進メンバーでアーキテクチャ研究会を結成し、交代制でLTを行なっています。LT自体は5分そこそこで終わらせて、残り時間はLTのテーマやLTスピーカーの問いかけにチームで語り合う時間にしています。

古参メンバーはプロダクトの歴史を語ってもらい、新メンバーはLTのテーマについて不明点を掘り下げてもらうようにしています。LTスピーカーはその場のファシリテーションを兼ねているので、LT後のディスカッションが盛り上がるようにメンバーに問いかけていきます。

新メンバーがいきなりディスカッションに参加できるのか疑問に感じている方もいらっしゃると思いますが、冒頭のLTでディスカッションに必要な基本知識を伝えるようにしているため、話についていけない状態を無くす工夫しています。また、LTを聴いても分からなかったのであれば、後半のディスカッションでヒアリングして、新メンバーを含めたチーム全体が理解できるように深掘りし、解説を加えていきます。

社内LTの風景

いざディスカッションを始めてみると毎回時間が足りなくなる位に話題が尽きません。みんな現在の仕様や設計について語りたいことがたくさんあるようで、チームでプロダクトについて語り合う場は必要だなと感じています。 会の終わりには毎回アンケートを実施して、気になったことや話しきれなかったことをヒアリングし、次回以降の改善に繋げています。

オンボーディング資料として有用か?メンバーによる査読会

社内LTに参加できている新メンバーは会に参加するだけでプロダクトの理解が深まっていきますが、これから入社してくるメンバーはLT資料を見るだけではきっと理解できません。もちろん議事録は残していますが、その場にいるメンバーの理解度に合わせた進行なので議事録だけでは不十分です。

そのため、社内LTで取り上げたテーマは、新メンバーのオンボーディング資料として活用できるように社内記事化に取り組んでいます。LTに参加していないくても理解できるように、テーマについて解説がされており、想定Q&Aも用意しています。この資料はメンバーに読んでもらい、「オンボーディング資料で利用できる!」と評価もらうところまでが、査読会の取り組みになっています。

またこの記事は現時点のプロダクト仕様をまとめたものなので、いずれは実際の実装から乖離して陳腐化していきます。それを防ぐために一度取り上げたテーマを3ヶ月に一度ダイジェストでふりかえりLTを実施します。ふりかえりの中で資料と実装の乖離があるものは都度資料を更新していきます。

Exception設計をまとめた資料。目次はこんな感じ

これまでに取り上げた考古学を一部紹介

プロダクト考古学で取り上げるテーマは新メンバーがOJT中に疑問に感じた点や既存メンバーから見て迷いそうだなと思うところから優先して取り上げています。 では、どのようなテーマを取り上げているのか一部紹介させていただきます。

この実装なら、このテスト!

このテーマは新メンバーが機能実装に対して、どのようなテストを実装するべきか判断に迷ったり、新旧混じったテストファイルの中で何が新しくて推奨されいる実装なのか、何が古くて参考にならない実装なのか、迷わないようにするために取り上げたテーマです。

LTの冒頭では、M&Aクラウドで採用しているテストの種類を紹介し、どのような経緯で現在のテスト構成になったのか説明しています。

DbIntegrationテストが導入された経緯

ディスカッションの時間ではメンバーがテストを書くときに意識していることをホワイトボードツール(Miro)で可視化して、疑問点や考え方を掘り下げていきました。そして機能実装するときに、迷いなくテスト実装するにはどうしたらいいのか、意見を出し合いました。このテーマを深掘りしたものはいずれ別の記事で紹介できればと思います。

ホワイトボードでチームの考えを可視化

まとめ

M&Aクラウドの「プロダクトの考古学」の取り組みはいかがだったでしょうか? 新メンバーが活躍できるようにサポートすることをチームの課題として受け取り、取り組んでいく1つの仕組みとして、皆さんの現場でも「プロダクトの考古学」が役に立てたら幸いです。

絶賛採用中!

M&Aクラウドでは一緒にプロダクト開発してくれるメンバーを募集しています! 気になる方はぜひご連絡ください!Twitter DMでもOKです!

sg.wantedly.com

障害要因としてあるあるの課題を解決するためにLarastanを導入しました!

こんにちは、エンジニアの栄山 (@yamii_qq) です。 今日はLarastanをプロジェクトに導入した話を書いていこうと思います!

発端

最近こんな障害理由がありました!

本来nullで返ってくる可能性のあるメソッドを、そうとは知らずに使ってしまった。
動作確認ではnullではない返り値が返却されていたので、バグに気付けず、本番にリリースしてバグが判明した!

日々開発業務をされているエンジニアの皆さんならわかってくれると思うんですけど、結構あるあるのミスですよね。

確かに使用するメソッドを確認して使うようにすれば防げるけど、確認が漏れてしまうことだって時にはある!そう人間だもの!

そこで仕組みとして改善しようと考えたので、Larastanを導入しました。

Larastanとは?

公式リポジトリを和訳して、要約すると下記のようなことが書いてあります。

・PHPStanのLaravelラッパー
・コード内のエラーを見つけることに焦点を当てている
・コードに対するテストを書く前に、さまざまなバグのクラス全体を検出することができる

github.com

Larastanとはソースコードを静的解析して、コード内のエラーを自動で検知してくれる便利なライブラリです。

どんなものが検知できるのか?

Larastanにはレベルが設定でき、レベルごとに検知できる内容が変わってきます。

レベル 検知内容
0 基本的なチェック、未知のクラス、未知の関数、$this に対して呼び出された未知のメソッド、メソッドや関数に渡された引数の数が間違っている、常に未定義の変数
1 可能性のある未定義の変数、call や get を持つクラスでの未知のマジックメソッドやプロパティ
2 すべての式で確認される未知のメソッド($this だけでなく)、PHPDocs の検証
3 返り値の型、プロパティに割り当てられる型
4 基本的な未使用コードのチェック - 常に false の instanceof およびその他の型チェック、使用されない else ブランチ、return の後に到達不可能なコードなど
5 メソッドや関数に渡される引数の型のチェック
6 型ヒントの不足を報告
7 部分的に間違った共用型の報告 - 共用型内の一部の型のみで存在するメソッドを呼び出す場合、レベル 7 で報告が開始されます。その他の可能性のある不正確な状況も報告されます
8 null 許容型に対してメソッドの呼び出しやプロパティへのアクセスを報告
9 mixed 型について厳密にチェック - 許容される操作は、別の mixed に渡すことだけです

(上記テーブルの内容はRule Levels | PHPStanの内容を和訳したものです)

導入してみた

Larastan導入の発端となった障害理由を検知したかったので、レベル8まで検知できる設定で解析してみました!

すると,,,2271errorsという数の大量の解析エラーが!!!

既存プロジェクトにLarastanを導入した結果

そうですよね...。という話なのですが、この量は多すぎてびっくりしちゃいますね。 (特にコード品質が悪いというわけではなく、Larastanレベル8のチェックが厳しいのでこれは仕方がないものなのです。)

既存のエラーを全て修正するのは、時間もかかるしリスクもあるのでなかなか難しいです。

障害要因となった部分は検知できたのか?

障害原因のコードの検知

画像だと分かりづらいのですが、無事nullで返ってくる可能性のあるメソッドが、nullable対応なしで呼び出されている場合に検知できました。

Cannot call method id() on Domain\SellingTarget\AbstractSellingTarget|null

これで、我々エンジニアがたまにミスして頭を抱えてしまっていた障害要因を仕組みとして取り除けそうです!

新しく開発する部分のみ導入しよう

LarastanにはBaselineオプションがあり、このオプションを使用することで、新規に追加されたコードのみを解析対象とできます。

GitHub - nunomaduro/larastan: ⚗️ Adds code analysis to Laravel improving developer productivity and code quality.

オプションをつけて解析コマンドを実行すると

./vendor/bin/phpstan analyse --generate-baseline

phpstan-baseline.neonというファイルが生成されて、既存のエラーを全て無視する設定が追加されるというわけです。

parameters:
    ignoreErrors:
        -
            message: "#^Property App\\\\Aspect\\\\Interceptor\\\\AdminAdminOperationLoggingTransfer\\:\\:\\$className has no type specified\\.$#"
            count: 1
            path: app/Aspect/Interceptor/AdminAdminOperationLoggingTransfer.php

これでなんとか導入できそうです!

既存のエラーは直さなくても良い?

ここまで読んでくれた読者の皆さんは、「え!?、結局errorは残したままにするの?」のような疑問を持つかもしれません。

既存のコードはこれまで大きな障害もなく実行されてきた実績があるので、正しく動作している可能性が高いです。

無理に修正してしまうと、意図せぬ挙動の変更につながる恐れもあるのでそのままにしておくことを選択しました。

下記記事などとても参考になります。(もちろんうちのプロジェクトのコードはクソコードではないですが笑)

qiita.com

実際の運用

Larastanを実際に運用していくに当たり、下記のようなことを満たしている必要があります。

  1. プロダクトを開発するに当たって、チームメンバーがストレス少なく静的解析のチェック・修正ができること
  2. 障害原因となったnullableなメソッドの使用についての検知ができ、検知されたコードに関して本番リリースされないこと

そこで下記のような取り組みを行うことで、無理なく運用できるようにしました!

CircleCIに組み込む

弊社ではコミット時に定義されたJobがCircleCI上で自動実行する仕組みがすでに存在します。

そこでLarastanのコマンドも一緒に実行してしまうようにしました。

php ./vendor/bin/phpstan analyse --memory-limit=2G --configuration=phpstan.neon

commit時に常時上記コマンドが実行され、ソースコードの静的解析を行います。

errorがあると本番ブランチにマージされない仕組みとしたので、安全にerrorを検知でき修正することができます!

makeコマンドを作る

ローカル環境でよく使うコマンドに関しては、makeコマンド化することで開発メンバー誰でも使用できます!

makeコマンド

makeコマンドとは、例えば、make larastanというコマンドをターミナル上で実行すると、makeファイルのlarastan: と書かれている部分のコマンドを実行してくれるものです。

開発チームに共有可能なエイリアスというのが、しっくりくるような便利機能です。

結果

この仕組みを導入して3週間ほど経ったのですが、すでにDevOpsが社内に浸透していることもあり、新しくphpstanチェックが入っても特に変わらず開発が進んでいます。

まとめ

今回開発現場あるあるの課題を、仕組み化することで解消することができました!

Laravelを使用して日々業務している皆さん!ぜひLarastanを導入してより良い開発環境を作りましょう!!

【入社エントリ】M&Aクラウドに入社しました

みなさんはじめまして。
2023年3月にM&Aクラウドに中途入社しました、cacaca_cameです。
入社から間が空いてしまいましたが、私も入社エントリーを書いてみます。

自己紹介

好きなものはAWSで、 推しサービスはLambdaとVPCです。(実務はそんなにやっていないです)

SIerからの受託開発などを行う会社で約10年ほど働いていました。前半はSEを、後半は社内で事業開発をやっていました。 ITエンジニアであるものの、企業の業務システムを中心に関わっていたこともあり、Webシステム開発に関してはほぼ素人同然です。

SE時代

フィールドSEのようなことや、営業倉庫向けの社内向けシステム開発、運用保守、システムリプレース等をしていました。倉庫のピッキングのシステムや在庫管理のシステムに関わることが多かったです。

事業開発時代

社内に取り入れていない技術を自社ビジネスにするための検討や、新規部門立ち上げの企画・提案・推進の他、社内システム・ツールの作成、社内システムをオンプレからAWSに移行、AWSの自社導入・管理などをやっていました。

なぜM&Aクラウドへ?

きっかけ

前職の事業開発はやりがいがあったものの、その部署が形骸化してきたこと、業界で多いSESビジネスにおける将来性を危惧し、転職を考えていました。 友人の勤めるCler(クラウドインテグレーター)に誘われていましたが、自身のキャリアと合っていないのではと悩んでいたタイミングで、転職サイト経由でお声がけいただいたのがきっかけです。
声をかけてもらったのは広く浅く色々なことをやっていたこととAWSの資格を持っていたのが大きいのかな?と思っています。

入社の決め手

自己成長できそうな点と今後のキャリアを考える上で役に立ちそうな点が入社の決め手になりました。 参考までに私が弊社に入社を決めた要素は以下の通りです。

  • 「自社プロダクト開発」を行っている会社で働きたい
  • 「スタートアップの空気感」を感じたい
  • ビジネス視点で「すごそうな人たち」と一緒に働いてみたい
  • 会社や事業の出口の1つである「M&Aドメインの知識」を学んでみたい
  • 「全員インフルエンサー」というものに興味がある

スタートアップに飛び込むので、少なからず不安はありましたが、最終面接で社長の及川さんと話した際に、「この人は必ず成功する人だ」という直感があったので、とりあえずついて行ってみることにしてみました。

M&Aクラウドでやりたいこと

弊社のミッションである「M&A流通革命を」はもちろんのこと、サービスを通じてM&Aの大衆化の力になりたいと思っています。事業の出口の1つとしてM&Aが選ばれやすくなることで日本を元気にできたら嬉しいです。
例えば、エンジニアが作ったサービスにM&Aが選ばれやすくなることで、そのサービスを拡大させたり、また別の新しいサービスを生み出すといった好循環が生まれる世界がいいなと思っています。

個人としては、フルスタックなエンジニア、かつM&A知識を持ったビジネスマンを目指します!

弊社のエンジニア職に興味がある方に向けて

弊社はオンボーディングの体制がしっかりしていますし、CTOの荒井さんをはじめ良い人が多く、働きやすい環境だと感じています。 また、M&Aのファイナンシャル・アドバイザーの方々と交流できるのも弊社ならではです。

現役でWebシステムを開発されている方、M&Aに興味がある方、今の会社で燻ぶっていると感じている方、M&Aクラウドで一緒に働いてみませんか?
いつでも気軽にお声がけください!

かめ (@cacaca_came) / Twitter

ハッカソンでAIによる業務改善をやってみました

機械が作成したM&AクラウドとAIというワードからイメージされる絵
みなさんこんにちは。
さる4/21(金)、弊社にてハッカソンが実施され、全社をあげて生成系のAIを絡めた業務改善を実施しました。
その時の様子と、ハッカソンを通してわかったAIを取り入れることで何が変わるかについて、考察していきたいと思います。

ハッカソンのタイムテーブル

大雑把には次のようなタイムテーブルになっていました。

  • 10:00~ 開会式
  • 10:15~ AIを触ってみる1: 画像生成AIを使って美味しそうな絵を描いてみよう
  • 10:50~ AIを触ってみる2: ChatGPTを使ってAIに色々なものを依頼してみよう
  • 11:30~ AIを使った業務改善!!<< ここが実装パート >>
  • 16:30~ 成果発表
  • 17:30~ 投票、結果発表 -18:00 閉会

びっくりすることに、実際に実装する時間はタイムテーブル的には5時間しかなく、そこに昼食時間と企画を考える時間が入り、実質的に4時間弱しかありませんでした。
正直、時間通りには終わらんだろうと思ってました。
いや、終わっちゃったんですけどね。

何を作ったのか

弊社はM&Aのプラットフォームを運営しているわけですが、アドバイザー業務を行っているチームもあり、そのチームの業務改善をやてみようということになりました。
で、業務改善というと、主に次のようなパターンがあるわけです。

  • より仕事の質を高める
  • 単純作業を省く

今回は後者の単純作業を省くために何ができるかをチームで考え、実装しました。

やりたいこととその概念図

アドバイザー業務はその性質上、どのような売却案件があるかを買い手さんに社名を隠して提示することがあるのですが、その際に一定のフォーマットでその会社の事業や内容をまとめた資料を作ります。
この資料はお客様が作る場合もあるのですが、お客様が作る余裕がない場合、こちらが依頼を受けて作る形になります。
フォーマットが決まっているので、会社の情報から内容を作っていくことになるのですが、かなり地道で時間もかかる作業になります。
そこで、一定の会社情報をもとに、自動で資料を作ってしまい、チームメンバーはその資料を確認・修正する作業をすればいいという形にすれば、かなりの工数削減になるのではないかと考えました。

やりたいことのイメージ

やったこと

とりあえず、お客様の会社情報を何らかのソースから取り出し、フォーマットに従い、説明資料を作るところまでを自動化します。
もちろん時間的制約があるため、何でもかんでもというわけにはいきませんでした。
ハッカソンで作ったものの全体像を上げます。

作ったものの全体像

限られた時間での成果物となるので、自分は初めからそれなりの環境が整っているGoogle Colabolatoryを利用しました。 コードは以下のような感になっていて、書くのにほとんど時間を使いませんでした。

!pip install openai bs4 gradio

import requests, bs4
import gradio as gr 
import openai

template = """以下の内容から会社の概要を作って下さい。
フォーマットとしては、

1. やっていることの概要(200文字くらい)
2. 会社としてイケてるところ
3. 会社に合いそうな人のペルソナ

でお願いします。
記載できない項目は空白で良いです
#################

"""


openai.api_type = "azure"
openai.api_base = "https://our_resource_name.openai.azure.com/"
openai.api_version = "2023-03-15-preview"
openai.api_key = "our_api_key"

def web_processer(url):
  res = requests.get(url, headers=headers)
  res.raise_for_status()
  soup = bs4.BeautifulSoup(res.text, "lxml")
  data = '\n'.join(filter(lambda x: x.strip(), soup.text.split('\n')))

  prompt = template + data

  response = openai.ChatCompletion.create(
  messages=[{'role': 'user', 'content': prompt}],
  temperature=0.0,
  engine="our_deployed_model"
  )
  return response['choices'][0]['message']['content']

demo = gr.Interface(
    fn=web_processer,
    inputs=gr.Text(label='url'),
    outputs="text"
)

demo.launch()

こんな感じ。
私はPythonが本職ではなく、チョちょっと趣味で触るくらいですが、検索したりなんなりで、10分くらいで書き上がりました。
どちらかというと、templateのフォーマット部分をチームメンバーと弄る場面が多かったり、requestをchromiumにしたりと実験していた時間が多かったですね。
また、templateは実際に使ったやつとはちょいと違っていますが、フォーマット部分が違うくらいです。

で、これをcolabolatory上で実行すると、次のようなUIが出てきます

gradioのUI
これはgradioという、機械学習系でよく使われているライブラリを使って出力されていて、左の入力欄にURLを入れると、それを入力としてページを取得し、タグやスクリプトを取り除いた上で、テンプレートの後ろに雑にくっつけてChatGPTに問い合わせをしています。
この内容だと、例えば弊社の紹介はこんな感じになります。
問い合わせ結果

1. 株式会社M&Aクラウドは、M&Aプラットフォームを提供する会社です。テクノロジーの力を活用し、中小企業のM&Aを支援しています。売却相談やM&A資料の提供など、M&Aに関する様々なサービスを提供しています。
2. M&Aクラウドのイケてるところは、テクノロジーを活用したM&Aプラットフォームの提供にあります。中小企業のM&Aを支援することで、日本の経済発展に貢献しています。また、若手起業家を支援することで、新しいビジネスの創出にも貢献しています。
3. M&Aクラウドに合いそうな人のペルソナは、M&Aに興味を持っている人や、中小企業の経営者を支援したいと思っている人です。また、テクノロジーに興味があり、新しいビジネスモデルを創出したいと思っている人も合いそうです。

こう、なんというか、絶妙に内容が薄いようにも見えますが、これは問い合わせが単に要約を指示しているからという可能性があります。
聞き方によっては、この内容からさらにどのような発展ができるのか...なども聞くことができるかもしれません。
その辺はAIの利用方法に委ねられるかなぁって思います。

AIを利用することで何が変わるのか

それでは今回のハッカソンを通して感じ取った、AI利用によって変わることについて述べていきます。

創造的検証が圧倒的にやりやすくなる

今回、実はURLから情報を取得し、AIに食わせるところに関しては割と早く実装が終わりました。
では何に時間をかけたかというと、どのような情報が取り出せるかと言うものの検証です。
AIに頼む内容を変えることによって、取得できる情報がどのように変わるかを確かめていたのですが、これがかなり革命的に思いました。
なんといっても、メンバーから、「こんなフォーマットいける?」ってきたやつを即座に「やってみましょう!」っていって、コードに取り込むことができるわけです。
しかも、AIに指示を出すプロンプトに関しては、普通の自然言語で書かれているわけですから、我々エンジニアがある程度整備をしておけば、bizメンバーがフォーマットや聞き方を変えることでいくらでも新しい検証をすることができます。
このようなさまざまなバリエーションでの検証をすることができるというのは、 AI利用によりもたらされる大きな利点であると言えます。

プロダクトに入れやすい

私の本職がPHPerなわけですが、PHPでも使えるOpenAIクライアントがあります。

qiita.com

現在、AIを利用するためのWEB APIが存在しており、こいつを使うことでさまざまな言語で使えるわけです。
これはアイデアさえあれば、どんなプロダクトでもAIを利用する余地があるというわけです。
自然言語のAIなんて、これまでは一部の強力な資本を持った企業しか使えなかったものでしたが、特に資本も設備も持たない小さな企業であっても、手軽に使えるようになるわけです。
弊社だけでなく、多くの企業がAI利用を宣言し出すのは、このような背景があるからですね。

しかも、先に述べた検証のしやすさを利用し、ある程度プロダクトに入れられる形まで検証で揉んでから、一気にプロダクトに突っ込むなんてこともできるわけで、新しい事業検証の形が見えてきたような気さえします。

まとめ

というわけで、長々とハッカソンからAI利用にみるこれからの世界を考察しました。
やはりこういうのは触ってみないとわからないものです。
別の方が詳しく述べるので、私の方ではあまり言及してませんが、今回のハッカソンにおいては、運営が機敏に動き回り、AI利用のお膳立てをほぼ完璧な状態に仕上げてくれました。
それだけマジでAI使っていこうという心意気を感じた次第。 今回はこの辺で失礼します。

AIハッカソンを開催しました!

みなさん!GWも楽しく過ごしてますでしょうか?エンジニアの栄山 (@yamii_qq) です。 私はデスク周りの掃除をしたので、晴れやかな気持ちでこの記事を書いています!

本題に戻りますが、タイトルにある通り、今回はAIハッカソンを開催したことについて書きたいと思います。

私は運営リーダーとしてハッカソンに参加したので、運営目線で記事を書いていきます!

M&Aクラウドにおける、ハッカソンとは?

全社員が参加型の技術イベントで、ITエンジニアだけでなく、さまざまな職種の社員が一堂に会し、1日かけてチームで課題に取り組みます。

今回で4回目で、なんと過去のハッカソンで生まれたアイデアが実際のプロジェクトに活かされることもある、とても重要なイベントです。

今回ハッカソン開催するにあたってのゴール

参加者がGenerativeAIサービスを各々楽しみつつ、学んだことを今後の業務に活かしてほしいので、開催前にゴールを決めました!

ずばり!ゴールを一言で定義するとこちらです!

  • GenerativeAIサービスを身近に感じてもらい、日常的に業務活用してもらう

ゴールを達成するためには、GenerativeAIに対して以下の認識を持つことが必要と考えたので、ハッカソンではこの部分を満たせるようなコンテンツを企画することにしました。

  • 便利だとわかる 
  • 自分の業務にどう活用できそうかわかる
  • 簡単に使えると思える
  • 日常的に使うための準備ができる

GenerativeAIサービスは使用用途が大量にあるので、このゴール設定がとても大事だったりします。

企画

AIを楽しみながら学ぶ午前の部、午前の部で学んだ知識を元に業務活用につながるアプトプットを考えてもらう午後の部に分けました!

この2つのワークに全社員で取り組むことで、AI使うと色々楽しい!業務改善にも使えそうじゃん!というマインド持たせようという策略です!

午前の部

事前にハッカソン運営チームで、GenerativeAIサービスを利用して楽しめるコンテンツを用意し、当日参加者に取り組んでもらいました。

画像は、盛り上がりを見せたAI料理対決です!

AI料理対決

例えば、こんな長い料理があったり!

Create an image with DALL-E that captures the essence of a cozy Japanese izakaya, featuring a plate of delicious yakitori skewers and a small ceramic cup of fragrant Japanese sake. The yakitori should be cooked to perfection, with charred and crispy skin and tender, juicy meat. The skewers can include various types of chicken meat, such as thigh, breast, or liver, as well as vegetables like green onion or shiitake mushrooms. The sake cup should be adorned with traditional Jap

※料理名は実際に使ったプロンプト

Create an image with DALL-E that captures the essence of a cozy Japanese izakaya

料理出すつもりが、Jiroが出てきたり!!

Ramen Jiro

楽しみつつ、きちんとプロンプトを定義するとイメージしたものと近いものが生成されるという体験ができました!

午後の部

午後は、GenerativeAIサービスを利用したチームコンテンツを「業務ハック」というテーマで取り組んでもらいました。

4時間で4分間のプレゼン資料を完成させる必要があるちょっと難し目のコンテンツです!

午後の部のテーマ

エンジニアには各チームのサポートメンバーとして、ハッカソンを盛り上げてもらいました!

発表

最後は発表です!!

ここが一番盛り上がりました!!

発表ルールでベルを鳴らすと臨場感が出るのでとても良いです。

発表ルール

発表内容は、実際に業務に活かせそうなものや、ユニークなアイデアなものなど、どの発表もとても面白かったです!

エンジニアが短い時間で手を動かして作ったものが、実際に動いていてエンジニアすごい!天才!って思ってしまいました!

例えばこのような素晴らしいサービスがこの短時間でできてしまいました! 企業を2つ入力すると、なんとそれぞれの企業の特徴を要約して、シナジーを考えてくれて、さらに提案資料も作ってくれる!こんなサービスどこにもないはずです!

SynergySpark

まとめ

AIハッカソン盛り上がったので、運営としてとても達成感がありました!

AIハッカソン後、社内でAIを使って業務改善しようという動きがあちらこちらで見られるので、開催した価値をものすごく感じています。

エンジニアとしても、ビジネスに関わる方が普段どのような部分に課題を感じているのかを知ることができ、今後の業務に活かせそうです!

皆さんもぜひGenerativeAIサービスをチームで使ってみましょう。自分では考えつかないような利用法が生まれるかもしれません!

過去のハッカソンに関する記事

過去のハッカソンに関する記事もあるので、ハッカソンってどんなものなの?と気になる方は目を通してみてください。

update.macloud.jp

tech.macloud.jp

Four Keysの計測結果を活用して生産性を向上させたい!弊社の活用例を紹介します!

みなさん!おはようございます!こんにちは!こんばんは!エンジニアの栄山 (@yamii_qq) です。

先日、弊社にてFour Keysをモニタリングできるようになりました!

tech.macloud.jp

本記事では、モニタリングした結果と今後どのように活用するかをご紹介します!

Four Keysの計測方法

Google Cloud の DevOps Research and Assessment(DORA)チームが毎年発表しているレポートに記載されている計測方法を使用します cloud.google.com

4つ指標があり、それぞれHigh,Medium,Lowでレベルが分けられいます。 指標の説明についてはこちらの記事に書かれているので、ぜひ読んでください。 Highが多いほど、ソフトウェアデリバリーのパフォーマンスが良いと言えます。

パフォーマンス測定レベルデプロイの頻度変更のリードタイム変更障害率サービス復元時間
High 1日に複数回 1日から1週間 0%~15% 1日以内
Medium 1週間から1ヶ月に1回 1週間から1ヶ月 16%~30% 1日から1週間
Low 1ヶ月から6ヶ月に1回 1ヶ月から6ヶ月 46%~60% 1週間から1ヶ月

弊社の計測結果

さあ、弊社の計測結果を見てみましょう!

年月デプロイの頻度(回/日)変更のリードタイム(分/回)変更障害率サービス復元時間(分/回)
2022/123.97回1,215分1.62%29,396分
2023/013.77回1,444分0.85%81分
2023/024.50回1,386分3.96%2,197分
2023/032.48回831分1.30%200分

うーん。数字だけだといまいちわからないですね。 計測結果がどのレベル帯であるかでもう一度表を作ってみます。

年月デプロイの頻度(回/日)変更のリードタイム(分/回)変更障害率サービス復元時間(分/回)
2022/12HighHighHighLow
2023/01HighHighHighHigh
2023/02HighHighHighMedium
2023/03HighHighHighHigh

直近4ヶ月だと、サービス復元時間以外はHighレベルを維持できていることがわかりました。 計測してみると、チームで戦っている感じがして良いですね!

2022年度、Highに当てはまる開発チームは11%のようなので、維持できているのはとても素晴らしいです!

引用: https://cloud.google.com/blog/ja/products/devops-sre/dora-2022-accelerate-state-of-devops-report-now-out から

一方、サービス復元時間は月によってばらつきがあることもわかりました。 12月の数値が高いのは、エラー可視化ツールSentry等を導入していないサイトで継続的にエラーが起きており、検知できなかったためです。

このようにFour Keysを計測することで、課題を発見することができます。

今後のFourKeys利用法

定期的にモニタリングする

定期的にモニタリングすることで、下記のようなことができると考えています。

  • 問題が大きくなる前に適切な対応ができる

何かしら問題があった場合に、モニタリングしていると気づきやすくなります。

気づくことで、影響が少ないうちに改善に繋げられるので、組織の健全性や満足度の向上につながります。

  • パフォーマンス計測レベルの測定方法が変更された時に追従できる

実は、Four Keysのパフォーマンス計測レベルは毎年アップデートされています。

2021年の資料では、EliteレベルといったHighのさらに上のレベルがありました。

引用: https://cloud.google.com/blog/ja/products/devops-sre/announcing-dora-2021-accelerate-state-of-devops-report

今後、測定方法が変更される際に、定期的にモニタリングしていることで移行がスムーズになります。

ソフトウェア開発に関するベストプラクティスは日々アップデートされていくので、適切な測定指標を追うことがより良いソフトフェアを提供することにつながります。

生産性向上のための施策を実施・計測する

Four Keysの指標を良くするために、様々なできることがあります。 以下が過去に取り組んだ例です。

アプリケーションエラーを可視化しエラー検知を早める tech.macloud.jp

ライブラリアップデートを自動化する tech.macloud.jp

Feature Togglesを開発フローに導入する tech.macloud.jp

社内勉強会の技術書籍感想会をポッドキャストとして配信する

「LeanとDevOpsの科学」を読んでいるので、興味ある方ぜひご聴取ください。

open.spotify.com

このような施策の成果を可視化できるのがFour Keysの良いところです。 今後は施策を実施→計測を繰り返すことで、チームが健全性を保ちながら能力を持続的に向上させるような良い循環を生み出せればと考えています。

まとめ

まとめです!

弊社でFourKeysが計測できるようになった結果、現状我々がどの位置にいて、何をするべきかが明確化できました。

1Teamで良いユーザー体験をお客様に提供するために、生産性を高めて質の良いソフトウェアを開発できればと思います。

参考

過去のレポートを貼っておきます。 毎年少しづつ変わっています!

2022年
2021年
2019年
2017年

【Copilot はじめました】GitHub Copilot 導入におけるハードルの整理

こんにちは。M&AクラウドのEMの鈴木です。M&Aクラウドでは GitHub Copilot(以下Copilotと呼びます)を導入してみることになりました。導入にあたり一般に言われているCopilotのリスクを元に、弊社なりに整理してみました。この記事はその学びを共有するものです。最近は GPT-4をベースにした「Copilot X」も発表されて Copilot を導入しようか迷っている方も多いかと思いますが、導入の際の意思決定の参考になったら幸いです。

GitHub Copilot とは

GitHub Copilot は、開発者がコードをよりすばやく記述できるようになる、AI を活用した新しいコード補完ツールです。

GitHub Copilot for Business について - GitHub Docs

(この記事を見に来ている人はだいたい知っていると思いますし、詳細は別の詳しい記事が沢山あるので端折ります。)

Copilot 関係のリリース状況整理

GitHub Copilot for Business

2023/02/15からGA(General Availability: 一般公開)。

github.blog

Copilot for Businessの新機能(抜粋)

● より強力なAIモデル:新たなモデリングアルゴリズムにより、コード提案の品質が向上しました。
● AIベースのセキュリティ脆弱性フィルタリング:GitHub Copilot は、ハードコードされた認証情報、SQLインジェクションやパスインジェクションといった問題に焦点を当て、一般的に安全でないとされるコード提案を自動的にブロックします。

GitHub Copilot X

2023/03/23にプロダクト発表。現在はテクニカルプレビューでBeta版。

github.blog

GAについては明記されていませんでした。状況に関する参考資料としてこちらも参照しました。

現在はテクニカルプレビューのBeta版。Copilot Xの料金は未定であり、Copilot の延長線上として同料金で使えるのか、追加料金が発生するのかは不明。

現行の GitHub Copilot に登録すると Waitlist に登録できる。Waitlist はこちら

セキュリティ・ライセンス問題に関する論点

主な論点としてセキュリティ上の問題と、ライセンス侵害の問題があります。いずれも GitHub Copilot for Business(以下 for Business と呼びます) を使用すれば問題の緩和が可能そうです。

Copilot 経由で弊社コードが流出するセキュリティ上の懸念に対するチェック

for Businesssであるなら、デフォルトで自社のコードをCopilotプロダクトの学習には使われないようになっています。

GitHub Copilot for Business について - GitHub Enterprise Cloud Docs

image.png (186.3 kB)

GitHub でテレメトリデータの使用を許可または禁止するには、 [GitHub で製品向上のためにコード スニペットを使用することを許可する] をオンまたはオフにします。

テレメトリーというのがCopilot自体の改善への情報提供 = 学習に使われる、という設定。

注: Copilot for Business には、テレメトリまたはコード スニペット データは保持されません。

GitHub.com での GitHub Copilot 設定の構成 - GitHub Docs

上記のように明記されていました。

Copilot for Individualsの場合には自社のコードを Copilot の改善のための学習に使われないようにする設定(Allow GitHub to use my code snippets for product improvementsの off)が必要ですが、for Businessの場合にはデフォルトで学習に使われないようになっています。 Twitterなどでは「仕事で使用する場合には、このチェックボックスをoffにすれば学習に使われないよ」などとツイートが散見されます。for Business を使用している場合にはこの設定は存在しないので、for Individuals を使用していると思われます。

プライバシーポリシーを見てみる

docs.github.com

送信される情報について以下に抜粋。

ユーザーエンゲージメントデータ 受け入れられた完了や却下された完了などのユーザー編集アクションと、待ち時間や機能エンゲージメントなどの指標を特定するためのエラーおよび一般的な使用状況データが含まれます。

コード スニペット データ 提案を返すためにリアルタイムでのみ送信され、提案が返されると破棄されます。(中略)コード スニペット データを保持しません。

ユーザー エンゲージメント データは、サービスを提供し、改善を可能にするために、GitHubMicrosoft、および OpenAI によって使用されます。

ここに明記されているものは以外は送信されない、プロダクト自体の改善に使用されない(=弊社コードが学習に使われて他の無関係の人のサジェストに表示される事はない)。

Copilot を使用して書いたコードがセキュリティリスクを持っているケースがあることについて

人間が書いたコードも同様にリスクはあります。各エンジニアメンバーは、自身が書いたコード、Copilotに支援してもらったコードであっても、内容をよく理解してPRを出す必要がありますね。また、レビュアーもCopilotが書いたものであろうとChatGPTが書いたコードであろうと、内容を理解して人間が書いたコードと同様にレビューする必要があります。

コードライセンスに関する懸念について

弊社におけるライセンス侵害のリスク

元となったコードがほぼそのまま出力されるような Copilot のアウトプットを使用すると学習元となったOSSのライセンス侵害をしてしまうリスクがあります。一方で断片化されたスニペットの場合にはリスクは低いと考えています。強いライセンスを適用したOSSのコードをそのまま使ってしまうリスクについては、Suggestions matching public code という設定があるため、これを off にしておくことで緩和できます。サジェストされる前に、コードがOSSのコードと一致してしまっていたらサジェストされないようにする設定です。

Back in June, we introduced a feature that allows developers to block suggestions of 150+ characters matching public code)

https://github.blog/2022-11-01-preview-referencing-public-code-in-github-copilot/

どうやらスニペットの大きさでいうと150 文字が閾値とのことでした。

基本的には上記設定を off にしておけば大きなコピペは発生しないと理解すれば、問題は軽微と考えました。
Individuals ではオーガニゼーション単位での設定もできないため、このライセンスの問題についても Individuals では設定漏れなどもあり問題が発生する可能性が高くなりそうです。

弊社レポジトリは Private ですが、仮にコード流出などがあった場合に、重大な違反があった場合には咎められる可能性はあります。とはいえ、Copilotをつかってミキシングされた情報を元にしたサジェストを使用している範囲内であるなら、特定エンジニアが特定のレポジトリを参考にしてコードを書いているのと同等程度のリスクだろうとざっくり考えました。このような、他のレポジトリのコードを参考にしたりコピペしたりすることもエンジニア個人のスタンス・スキルに依存するため完全に防ぐことはできず、Copilotを入れたからといって極端にリスクが上がるものではないです。 (※咎められる、という表現で何が発生するかは元となったコードのライセンス次第。コードをOSSとしての公開を強制されるとか、使用料金が発生するとか。)

ライセンス侵害が問題になった時の防御

2022/12 にでた terms によれば、以下のように書かれており、50万米ドルまで肩代わりしてくれることになっています。

第三者からの請求の防御。
本契約の他の文言にかかわらず、GitHubは、GitHub Copilotの利用が企業秘密を不正利用した、または第三者の特許、著作権、商標、その他の知的財産権を直接侵害したという無関係の第三者からのクレームに対して、50万米ドルまたはクレームに先立つ12ヶ月間にGitHub Copilotを利用した対価のうち大きい金額を上限としてお客様を防御します。GitHubの防御義務は、(i)GitHub Copilotが提供したSuggestionと異なるコードに基づく請求、(ii)第三者の知的財産権またはその他の権利を侵害する可能性のあるコードの意図的または不注意な使用を防ぐために設計された合理的なソフトウェア開発レビュー慣行に従わない、(iii) GitHub Copilotで利用できるすべてのフィルタリング機能を有効にしなかった場合には適用しません。

すごくざっくり要約すると、1. suggestions に基づくものだけよ。 2. レビューしとけよ。 3. フィルタ設定入れておいた場合のみ、という制限はあり、上述のSuggestions matching public codeの設定が重要であることが分かります。

その他

Copilot X の Waitlistに登録する

Waitlist 再掲: https://github.com/github-copilot/chat_waitlist_signup/join

VS Code および Visual Studio とネイティブに統合するエディターにチャット インターフェイスを導入します。

現在は使えるエディタは限られているので注意。

join waitlist のページに書かれている規約はGitHub本体の規約ですが、その中にベータプレビューについての記述もありました。

以下は特に重要と思われる内容についてピックアップしておきます。

  • お客様は、これらのプログラムを通じて機密情報を受け取る場合があり、プログラムがプライベートなものである間は機密を保持する必要があります。 - 要約: ベータの内容は漏らすなよ

  • また、ベータ プレビューは、本サービスがこれまでおよび現在受けているものと同じセキュリティ対策および監査の対象にはなりません。 ベータ プレビューを使用することにより、お客様は、自己の責任において使用することになります。 - 要約: 使うのはリスクがある。個別の会社での判断になる。

弊社では、Waitlist には並んでおいて、いざ使えるとなったら、リスク許容できるかどうかはその時に考えることとしました。その時点で判断材料となる事例などの情報が増えているだろうと考えています。

特に参考にした資料

zenn.dev

ライセンスに関する論点など、こちらも参照するのがおすすめです。

あとがき

ほぼ書き上がった後に気がついたのですが、2日前にめちゃ似た記事が上がっていました! ちょっとだけ私の書いた方の記事の方が詳しいと思うので車輪の再発明はお許しください。

dev.classmethod.jp

採用もしてます

sg.wantedly.com

Copilotは「副操縦士」ですが、弊社で「パイロット」になることに興味がある方がいればお声がけください。こういったツールの意思決定や社内文化についてのカジュアルなお話も随時受け付けています(wantedlyで応募でも、@yamotukiまでメンション下さっても問題ありません)。

M&Aクラウドにおける Four Keys の意義

こんにちは。エンジニアの濱田 (@hamakou108) です。

先日、弊社主催の「PHPerKaigi2023(勝手に)リジェクトカンファレンス」というイベント1 で登壇させていただき、弊社の開発フロー改善の軌跡について Four Keys や継続的デプロイと絡めて紹介しました。元々のプロポーザルで20分想定だった内容を5分で発表したため、泣く泣く削った内容が多々ありました。今回の記事はその補完という形で、弊社における Four Keys の位置付けと取り組んでいる施策について触れたいと思います。

弊社での Four Keys の位置付け

まず弊社での Four Keys の位置付けについて紹介したいと思いますが、その前にそもそも Four Keys の定義について振り返りたいと思います。

Google Cloud による Four Keys Project の紹介では、 Four Keys はソフトウェア開発チームのパフォーマンスを示す指標であるとした上で、次のように定義しています。

  • デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
  • 変更のリードタイム - commit から本番環境稼働までの所要時間
  • 変更障害率 - デプロイが原因で本番環境で障害が発生する割合(%)
  • サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間

Google Cloud の DORA チームは Four Keys を使って計測したチームのパフォーマンスが組織のパフォーマンスの予測指標になることを突き止めており、ほぼ毎年 State of DevOps Report という形で調査結果を発表しています。

弊社では MVV を体現するための中長期的な投資として Four Keys を位置付けています。私たちの開発チームが 2021年の DORA レポート2 においてどのクラスターに分類されるか検証したところ、「デプロイ頻度」と「変更障害率」に関しては Elite に、「リードタイム」と「サービス復旧時間」に関しては High に分類されることが分かりました。2つのメトリクスが Elite に分類されていない状況には私たちのチームがM&Aクラウドの MVV を体現するためのヒントが隠れていると解釈しています。

例えば「変更のリードタイム」が Elite でない点について、長期的にはシステムの変更容易性が低下することを示唆していると仮説を立てることができます。具体的には次のようなシナリオです。

  • システム全体に自動テストが網羅されていないので修正箇所によっては障害のリスクが高い。このリスクを下げるためには念入りな手動確認を行う必要があり、変更のリードタイムが長くなる。このような箇所が広がっていくにつれてこの影響が拡大し、長期的には変更容易性が低下する
  • メンバー同士の情報のやり取りが、結果(プルリクエスト)を主として行われており、そのプロセスや思想に対して行われていない。この結果コミュニケーションコストが増大し、変更のリードタイムが長くなる。チーム数が増えるにつれてこの影響が拡大し、長期的には変更容易性が低下する

長期的な変更容易性の向上は弊社の Vision である「時代が求める課題を解決し時価総額10兆円企業へ」を実現するために必須であると考えています。また「サービス復旧時間」については直接的にユーザーが不利益を被ってしまう時間に関係しており、弊社の Value の1つである「2nd Priority 3」の体現を阻害するものと捉えています。

上述した問題に対してどのように対処すれば良いでしょうか。書籍「LeanとDevOpsの科学」では、ソフトウェアデリバリーのパフォーマンスを統計的に有意な形で改善できるケイパビリティ24個が特定されており、適切なケイパビリティに焦点を当てることで成果を上げることができると記述されています。弊社ではこれを意識した最初の取り組みとして継続的デプロイの導入を行っています。詳しくは冒頭で紹介したカンファレンスの資料をご覧ください。

このように適切なケイパビリティを獲得していくことで、開発チームは MVV の実現に近づき、定量的な結果指標として Four Keys を活用することができると考えています。

Four Keys のモニタリング基盤の構築

Four Keys の活用を進めるにあたって目下取り組んでいる課題が Four Keys のモニタリング基盤の構築です。

前述したクラスター分類に使った Four Keys の数値は、実は手作業で算出されています。手作業だとスポットの数値しか算出できず、今後取り組んでいく施策によってデリバリーのパフォーマンスに改善効果があったのか検証するのも困難です。この問題を解決するために Four Keys のモニタリング基盤の構築に取り組み始めました。昨年からM&Aクラウドではデータ基盤の構築プロジェクトが進行中で、それらのアセットが活用できることも追い風となっています。

実際に基盤構築を進めるにあたって、1点難しい課題がありました。「変更のリードタイム」の計測です。「変更のリードタイム」を算出するためには起点となる commit の時刻、そしてそのリビジョンのデプロイの完了時刻のデータを集計する必要があります。自分が調査した範囲ではこれを実現できる OSS などのツールを見つけることができませんでした。

そこで開発したのが depwatch です。

github.com

このツールによって「変更のリードタイム」の算出するために必要な時刻のデータを GitHub や CircleCI から取得することができます。開発の詳細に関しては自分の個人ブログをご覧ください。

www.hamakou108.com

このツールで収集したデータおよび障害の発生・復旧に関するデータを組み合わせ、 BigQuery 上で加工し、 Four Keys を週次や月次で表示できる基盤を着々と構築しています。今後はモニタリングされる Four Keys の数値から仮説を立て、施策を立案し、検証するサイクルを回していきたいと考えています。

まとめ

弊社での Four Keys の位置付けとモニタリング基盤の構築について紹介しました。 depwatch は OSS として公開しており、今後も機能の拡充を進めていく予定ですので、ニーズにマッチする方がいらっしゃればぜひご活用ください!


  1. PHPerKaigi 2023及び、PHPerKaigi 2023 実行委員会とは無関係のイベントです。
  2. 最新の DORA レポートは 2022年に発表されていますが、クラスターの数が4つから3つに減るなど従来のレポートと比較して大きな変化があったことから、2021年のレポートの定義を採用しています。
  3. 次のような内容のバリューです。「顧客第一になろう。それ以外の都合は2番目に置いておいて、まずはなによりユーザーを大事にすること。ユーザーが求めることの本質に応えること。長期の視点ではユーザーにもっとも価値を提供できる会社が、必ず流通革命を起こす。自分たちの作ったサービスで、ユーザーが喜ぶ瞬間は最高の時間だ。とにかく迷ったら自分達のことより、ユーザーのことを考えよう。」

M&AクラウドはPHPerKaigi2023のプラチナスポンサーです

株式会社M&AクラウドはPHPerKaigi 2023のプラチナスポンサーです。

PHPerKaigiとは

PHPerKaigi(ペチパーカイギ)は、PHPer、つまり、現在PHPを使用している方、過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、技術的なノウハウとPHP愛を共有するためのイベントです。 今年の開催はオフライン会場を軸としたオフライン・オンラインハイブリッド開催です。みなさんのご都合に合う参加方法をお選び頂けます。

2023年3月23日(木)〜 3月25日(土)はPHPerたちのお祭りです! 歴戦の勇者みたいな方はもちろん、初心者の方にも、全てのPHPerが楽しめるイベントです。スケジュール、空けておいて下さい!

※公式サイトより

phperkaigi.jp

登壇情報

弊社からは前夜祭の3/23(木)18:50〜久保田が登壇します。

fortee.jp

ノベルティ

M&Aクラウドからはドリップコーヒーとカロリーメイトを提供しています!
カンファレンスセッション中に小腹が空いたらセットでどうぞ!

ドリップコーヒーとカロリーメイト

※事前にノベルティー付きチケットをお買い元の方のみの配布となります。
カロリーメイト大塚製薬株式会社の商標登録です。

ドラッカーエクササイズでチームビルディングをしてみました

こんにちはみなさん
niisan-tokyoです

先日の3/1にドラッカーエクササイズという手法を用いてチームビルディング会を開催しました。
元々チームビルディングの需要は高まっていたのですが、EMとの 1 on 1 で話題になって、流れで、

「チームビルディングといえば、ドラッカーエクササイズっていうのがありますね」
「そうなんですね。niisan-tokyoやってみます?」
「え?いいんすか?」
「じゃあ、お願いしますね」

みたいな感じですすっと私が開催する運びで決まりました。
今回はそのエクササイズと、チームで実践してみた結果を紹介していきます。

背景

私の入社は2月だったのですが、前年の12月に組織改変があったようで、チームの成立もその時でまだまだ若いチームでした。
しかも、このチームには1月入社の方と私の2人の新顔がいるという状況でした。
そんなわけで、チームとしてはいくつか課題を抱えていたという状況です。

  • 新規メンバーの性質がよくわからない
  • 既存メンバーのことを、新規メンバーはよくわからない
  • そもそもチーム結成も新しいので、お互いの働き方を探っている

こんな感じの状況だったので、チームビルディングを実施してみようという考えがメンバーの中に醸成されていきました。
そんな中、前職でもドラッカーエクササイズをやっているチームがあったので、うちでもやってみようよっていう流れになったわけです。

ドラッカーエクササイズ

前置きはこの辺にして、早速ドラッカーエクササイズの紹介とその目的を見ていきましょう。
私の解釈が入ってしまっているので、もし本物を参照したい場合は、以下のリンクから原典に飛んでください。

The Drucker Exercise | The Agile Warrior

ドラッカーエクササイズとは、アジャイルサムライの筆者が提唱したチームビルディング手法で、以下のような質問に答えてチームメンバーに自分のことを知ってもらい、お互いの特性やロールを認識し、チームとしての成果を最大化することを目的とするものです。

  • 自分の強みは何か
    • 原典では「世界レベルのもの」とか「誰よりもイケてる」ものとして書いてねとある
  • 自分はどのように成果を出すか
    • 仕事のやり方、環境など
    • 「これはやめて」みたいなパフォーマンスを低下させるようなものも含む
  • 自分は何に価値を置いているか
  • 自分はどのような貢献を期待されるか

エクササイズの実践

それではエクササイズをどのように実践したかを述べていきましょう。
エクササイズの内容自体は簡単なので、これをMTGで決められた時間で終わらせるように設計してみました。 また、今回はmiroで実施しました。

ドラッカーエクササイズ実践後の成果物

どのようにしてこの結果が出てきたかを見ていきましょう。

タイムボックス

全体の時間を1時間で設定し、各エクササイズとその表明に各々タイムボックスを設定しました。
具体的にはチーム人数6人で、以下のような段取りを組みました。

  • ドラッカーエクササイズ
    • 説明: 5min
    • 自分の強みを書き出す: 1min(説明)+3min
    • 自分の仕事の流儀を書き出す: 1min(説明)+3min
    • 自分の価値観を書き出す: 1min(説明)+3min
    • 自分に何を期待して欲しいかを書き出す: 1min(説明)+3min
  • 結果の表明・共有・コメント
    • エクササイズの結果を見ながら、各メンバーが自己紹介: 4min
    • 自己紹介を聞きながら他のメンバーがコメントを書き出し: 4min(上と同時)
  • 振り返り: 5min

まず全体の説明を少ししてから、前半で各エクササイズごとに説明を入れつつ書き出しをします。
後半は各メンバーからエクササイズの結果をもとに自己紹介をしつつ、その話を聞きながらエクササイズの結果を見つつ、他のメンバーがコメントを書き出していきます。
最後に振り返りをして、全部で50分くらいです。
各々の実時間としてはほぼ1時間ぴったりと言ったところです。
次に、各エクササイズの中を詳しく見ていきましょう。

エクササイズ

各エクササイズに対し、まず説明と簡単な例を挙げた上で、それぞれがmiroの付箋に書き出しました。
それぞれどのように問いかけ、どのような結果が出たかを簡単に見ていきます。

自分の強みを出す

以下のような質問に対して、原典に倣い、少々大袈裟に書き出してもらいました。

「自分が世界に通づる、もしくは誰よりもできると思うことを3つ捻り出してみよう (自分の強みを表現してみよう)」

説明の時に例を出しますが、

  • 優れた聞き手
  • 混沌に秩序をもたらす
  • 自然な外交官

のような感じで、パワーを感じるものを例示しました。

結果としては

  • 向上心
  • コミュニケーション
  • 手作業を面倒くさいと感じる気持ち

などが上がってきました。
これだけでもかなり個性が出ますね。

自分の仕事の流儀

これは各メンバーが最もパフォーマンスを発揮するためにどうするのかを書き出すものですが、以下のように問いかけました。

「あなたはどんなふうに仕事をするのが好きですか?」

これも初めの説明で例を出すのですが、

  • リストを作りたい
  • ミニマリストだよ
  • マイクロマネージメントされるのは嫌だ
  • 早起き or 朝型

こんな感じです。
パフォーマンスを上げるための手順ややり方とともに、パフォーマンスを下げる要因についても挙げてもらっています。

結果としては以下のようになりました。

  • 持続可能なペースで
  • 大雑把に作ってから細かいの詰める
  • 人を巻き込む
  • 自由な時間に仕事できるのがいい

一月一緒に仕事してきたのですが、「確かに」と思えるところもあり、納得感が出ました。

自分の価値観

価値観というのが結構難しく、スクラムマスターをしている知り合いから事前にアドバイスを聞いていました。
より書き出しやすくするために以下のような表現で問いかけを作りました。

「あなたの好きな言葉・単語・ことわざ・価値観をあげてみてください」

例としては以下のものを挙げました

  • 質の高い仕事
  • 他者への敬意
  • 信頼される
  • 改善し続ける

これに対し、メンバーが挙げくれたのが以下のようなものです。

  • 多元論
  • 将来への投資
  • とりあえず寝る
  • Money Power Respect
  • 一日半歩
  • Whyからはじめよ

なかなか個性的なものが揃ったように思います。

自分に何を期待して欲しいか

これはそのままですね。ここまで強み・仕事の流儀・価値観を出してきたので、これらを参考にして書くこともできます。
問いかけは以下のようにしました。

「あなたはどうのようにチームに貢献しますか?あるいは、チームはあなたに何を期待できますか?」

例示したのは以下のようなものです。

  • 素晴らしいユーザー体験
  • 必要な時に必要な分だけ分析を行う
  • 現実的な計画

これに対して出てきた結果はこんな感じです

  • リーン思考
  • 決定打に欠くことを決める
  • センス

これに関してはかなりばらけたように思います。
チームメンバー各々が多様な方向から貢献していけることがわかります。

自己紹介とコメント

エクササイズが終わったら、その結果を参照しながら各メンバーごとに自己紹介をしてもらいます。
発表者以外のメンバーは、発表者の自己紹介を聞きつつ、エクササイズの出力を見ながらコメントを書き出します。

自己紹介に関しては、エクササイズ結果があるため、その内容を使いながら、各メンバー結構スムーズにできていたように思います。
また、コメントは各メンバーごとに一人一つずつくらいかと思っていたのですが、2つ3つ出てきたりして、用意した領域が足りなくなりました。
もしドラッカーエクササイズをこのやり方を参考にして実践する方がいれば、コメントの領域は大きめに取ったほうがいいです。
コメントの付け方にも個性があって、キャッチコピーみたいな感じでコメントを残す方もいました。

キャッチコピー

とりあえず私にこのキャッチコピーをつけた方には「キャッチコピー大臣」の称号を与えましょう。

ふりかえり

こういう会に関しては、基本的にふりかえりをするのが私の流儀です。
今回はFun-Done-Learnを使ってふりかえりを行いました。

Fun-Done-Learn
全体を出すと画像が荒くなってしまうので、中心付近を持ってきました。
価値観に関してはなかなか学びが深かった印象です。

カメレオン??なんだったかな...

振り返りとまとめ

こんな感じで、ドラッカーエクササイズを使ってチームビルディングをやってみました。
私も知識では知っていましたが、いざ実践となるとうまくできるか不安でした。
やってみれば、メンバーはみんな協力してくれましたし、楽しんでくれたようで開催した意義は十分出せたかなと思います。

改善するとしたら、以下の点は考えてもいいかなと思います。

  • 各メンバーのキャッチコピーを作るのは面白そう(時間があれば)
  • 書き出しスペースはあと1.5倍くらい広くするといい(コメントと価値観の部分がはみ出しました)

というわけで、今回はこんなところです。

宣伝

M&Aクラウドはまだまだ積極的な採用を続けています。
興味のある方は応募してみてください。

macloud.notion.site

niisan-tokyoから紹介してくれよって方は、私のtwitterにDM送ってもらってもオッケーです。

twitter.com

それではまた