AWS CDK v2 の変更点5選!

f:id:fyui001:20220401112414p:plain

みなさんどうもこんにちは。 エンジニアのゆい(@fyui_001)です。

🌊乗るしかないこのビックウェーブに🌊

皆さんはAWS CDKはご存知でしょうか? 一言で言えば使い慣れたプログラミング言語AWSリソースをプロビジョニングできるツールキットです。

前回の記事に引き続き、サービスをEBからECSに移行したプロジェクトの取り組みを紹介します。 このプロジェクトで新たに導入したAWS CDKでv2がリリースされていたので、今回はAWS CDKのv1とv2の差分について書いていこうと思います。

第一弾の記事はこちら!

背景

今までM&AクラウドではAWS CDK含めTerraformなどのIaCツールを導入しておらず、AWSリソースの操作は基本的にAWSコンソール上で行っていました。

ではなぜサービスのECS移行に伴いAWS CDKを導入したかと言うと、AWSリソース変更をする際に証跡作り・確認用のためにAWSコンソールのキャプチャを撮りslackやesaなどに添付する非常に面倒な作業があったり、手順書があちこちにあり煩雑で手間がかかるなどの課題がありました。

IaCを導入することでインフラの設定がコードベースで定義できるので、GitHubのPRがそのまま証跡になりレビュー・確認等もGitHub上で行えるため一々スクリーンショットを撮りesaやslackに貼り付ける作業を省くことができるようになりました。

今回サービスのECSでは完全移行で新規リソースを構築する必要があり、IaCの構築の自動化やバージョン管理などの恩恵が受けられるタイミングだったので、最初はECS移行分のリソースのみ部分導入に至りました。

AWSに対応してるIaCツールはTerraformやAnsibleなど複数ありますが、今回AWS CDKを選択した理由は大体以下の通りです。

  • TypeScriptやPythonJava・.NET等の言ったプログラミング言語で記述できる
  • コード記述量が少なく書ける
  • AWS公式ツールでサポートが受けられる
  • 本体の安定性はさておき終了したとしてもCloudFormation管理に戻すことができる
  • 私がAWS CDKの実務経験があった
  • 個人的に開発したECS環境を構築するAWS CDKのプログラムがあり、開発コストを抑えることが可能だった

個人的に開発していたAWS CDKの資産ですが、1年ほど前に開発したもので、その時はまだv1でしか開発しておらず、今回久々にAWS CDKの情報を調べていたら昨年12月にv2がリリースされていたので、ついでにv2のマイグレーションも行いました。 今回はv1とv2で何が変わったのかを大まかにお話しようと思います。

AWS CDKって何?

What is the AWS CDK?

従来から提供されているCloudFormationは、JSONYAMLと言った構造化ファイルでリソースを定義しますが、CDKでは前述した通りプログラミング言語で利用できるのが大きな違いと言えます。

v1とv2の差分

Release v2.0.0 · aws/aws-cdk

alpha版が出てから1年がかりでつい最近の2021年12月にv2.0.0がリリースされました。

主な差分を簡単に列挙すると以下の通りで、v2になってCDKの各リソースに破壊的な変更が入ったとかではありません。

AWS Construct Libraryが1つのパッケージになった

v1では各サービス毎にパッケージが分割されていて、使いたいサービスのパッケージを都度都度ダウンロードしないといけなくて、新しいサービスを追加するときに一々npm installとかpip installしないと行けなかったのが、aws-cdk-libと言う一つのパッケージにまとめられ、これ1つですべてのAWS Construct Libraryにアクセスできるようになったので少し扱いやすくなりました。

個人的にこれは結構うれしい変更です。 @aws-cdk/aws-ec2'@aws-cdk/core' といったパッケージを必要に応じて個別にインストール必要がなくなりaws-cdk-libを入れれば解決です。

DeprecatedなAPIが削除された

v1で非推奨になっていた多くのプロパティやメソッドが完全に削除されました。 v1で非推奨なAPIを使用している場合、v2にマイグレーションするにはアプリケーションとライブラリを更新して、代替のAPIに切り替える必要があります。

Feature flagsの新しい動作がデフォルトに

v1で導入されていたFeature flagsですが、v2ではすべてのFeature flagsが有効になりました。 AWS CDKアプリケーションをv1からv2に移行する場合は、cdk diffコマンドを実行して、アプリケーションへの影響を確認することをお勧めされてます。

ExperimentalなAPIのライフサイクルが新しくなった

v2から新しいライフサイクルを導入され、新しい実験的なConstructライブラリは、メインのaws-cdk-libライブラリから完全に独立した@aws-cdk-experiments配下に移動され、@aws-cdk-experiments/aws-xxxのように実験的ながわかる名前で配布され、0.x系のバージョン番号がつけられます。 APIがstableになった際にaws-cdk-libに移動されるようになりました。

新しいブートストラップリソースがデフォルトになった

CDKを初めて使う時はcdk bootstrap を実行してデプロイ用のS3バケットを作成する必要がありますが、cdk bootstrap で生成されるリソースが変更されました。 前述のFeature Flagsを使って手動で新しいブートストラップリソースにオプトインしてない場合、AWSアカウントとリージョン毎にAWS CDK CLIcdk bootstrapを実行し再度ブートストラップする必要があります。

さいごに

色々とCDKのことを書きたかったですが、長くなるので今回はAWS CDKのv1とv2の差分を紹介させていただきました。

最後に... M&Aクラウドでは現在エンジニアやPdMなど幅広く募集中です!!もし興味を持ってくださった方はお気軽にお声がけください!

www.wantedly.com

www.wantedly.com

www.wantedly.com

M&Aクラウドを丸ごとAmazon Elastic Container Service(ECS)に移行しました!〜コンテナイメージ作り編〜

f:id:kazuki09:20220324123449p:plain

おはようこんにちはこんばんは!エンジニアの大石です。

弊社のサービスを丸ごとAmazon Elastic Container Service(ECS)に移行したので、何回かに分けてその取り組みを紹介したいと思います!

今回は第一回、コンテナイメージ作りについてお話したいと思います。

はじめに

ECSへの移行に至ったきっかけ

弊社のサービスは元々AWS Elastic Beanstalkというサービスの上にLaravelのアプリケーションを載せて動かしていました。Elastic Beanstalkとは簡単に言うとEC2インスタンス上に一通り揃ったアプリケーションの実行環境を作れてデプロイが簡単に出来るサービスのことですね。

一見簡単に運用できるように見えるElastic Beanstalkですが、初回の導入は簡単な反面、どうしてもEC2なのであとあとPHPのバージョンアップなどのミドルウェアの更新があると環境を作り直すのが大変だったりします。

そこで、環境をコードで構築してイメージにアプリケーションと実行環境をひとくくりにしてデプロイ出来るコンテナベースの環境(ECS、Lambda、EKSなどなど)は環境の変化に柔軟に対応出来るため、レガシーからの脱却と将来的な投資を込めて今回ECSに移行するに至りました。

コンテナって?コンテナイメージって?

簡単に説明しますと、コンテナイメージはコンテナを立ち上げるためにテンプレートのようなもので、コンテナはイメージから起動した実体... といった形です。

aws.amazon.com

AWSの公式の記事にとても分かりやすい解説があるので、今回は細かい話は置いておいてイメージ作りにフォーカスしてお話したいと思います。

コンテナイメージに入れるものを整理する

Laravelを動かすぞ!!といっても大元にphp-fpmが必要だったり、アプリケーションから依存するpeclモジュールが必要だったり... などなどアプリケーションの構成によって必要なものが変わってきます。

そこで、まずアプリケーションを動かすのに何が必要かを洗い出していきましょう。

弊社のアプリケーションを例に挙げると、以下のものが必要であることが分かりました。

  • アプリケーションのLaravelのコードそのもの
  • php-fpm
  • nginx
  • composer
  • aptで導入できる各種ライブラリ(libpng, libjpegなど)
  • PHPの各種extension(pdo_mysql, opcacheなど)
  • AWS CloudWatch Agent(アプリケーションのログの転送に使用)

必要なものが分かってきたので、実際に必要なコンテナを配置していきます。

そして、弊社のアプリケーションの場合、最終的なコンテナやECSのサービスの構成としてはこのような形になりました。

f:id:kazuki09:20220324144444p:plain
構成図

コンテナイメージに関してはアプリケーションが入ったイメージとリバースプロキシ(nginx)が入ったイメージの2つが必要なことが分かってきましたね!

ちなみに、運用のコストを削減するためにLaravelのアプリケーションが入ったイメージは1つの共通のイメージを使用して、コンテナ起動時に起動コマンドを書き換える形で動かしています。

余談ですが、ECSでコンテナの実行コマンドを上書きする方法、Laravelのschedule workerやqueue workerをコンテナ上でいい感じに(しっかり安全にシャットダウンするなどなど)動かす方法については別途記事にする予定なのでお楽しみに!

コンテナイメージを作る

ECSといっても通常のDocker同様で、Dockerfileを書いてDockerイメージを組み立ててそれを何らかのコンテナレポジトリ(今回の場合はECR)にpushして使う形になります。

nginxのイメージを作る

Docker Hubを見に行くとnginxのイメージ(https://hub.docker.com/_/nginx)は既に用意されているので、それを元に必要な設定ファイルをひとまとめにしたイメージを作りました。

FROM nginx:1.21.6

COPY ./docker-prod/nginx/nginx.conf /etc/nginx/
COPY ./docker-prod/nginx/default.conf /etc/nginx/conf.d/

とてもかんたんですね!

あらかじめ用意しておいた設定ファイルをコピーして起動すればすぐにnginxが使える状態にしておきました。

アプリケーションのイメージを作る

こちらも同様にPHPの実行環境が入ったイメージ(https://hub.docker.com/_/php)が公式から提供されているので、ウェブサーバを動かす前提になっているphp-fpmのイメージを使って組み上げていきます。

といってもこちらはアプリケーションコンテナのビルドになり、ブログに載せるにはあまりにも長くなってしまうので、要所のみ記載します。

ちなみに、おおまかなイメージの作り方はこちらの記事が分かりやすくておすすめです。

www.digitalocean.com

Composerをインストールする

COPY --from=composer:2.2.7 /usr/bin/composer /usr/bin/composer

実はこれもCOPYコマンドで超簡単に1行で出来ちゃったりします。公開されているイメージから特定のファイルだけを持ってくることが出来るので、curlでダウンロードしてきて...のようなことは実は要らなかったりします。

qiita.com

AWS CloudWatch Agentをコンテナに入れる

弊社のアプリケーションではファイル上に書き出したログを収集してCloudWatchに転送するといったことをElasticBeanstalkで運用していた時代は行ってましたが、これを継続して行いたいのでAgentを入れてあげて転送できるようにしました。

(CloudWatch Logsにアプリケーションから直接AWSAPIを通してログを転送する方法もありますが、ログを書き込む度に毎回通信が生じてしまいAPIのレートリミットに引っかかるといった問題が起こりがちなので、一旦ファイルに書き込んでおいて裏側でAgentから転送する方法が個人的にはおすすめです)

入れるといっても今回もCOPY技で簡単に入れてあげます。

COPY --from=amazon/cloudwatch-agent:1.247350.0b251780 /opt/aws/amazon-cloudwatch-agent /opt/aws/amazon-cloudwatch-agent
COPY docker-prod/app/amazon-cloudwatch-agent.json /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json
COPY docker-prod/app/cloudwatch-agent-common-config.toml /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml

設定ファイルの記載方法については公式ドキュメントを参照して書けば完了です!

docs.aws.amazon.com

ちなみに、CloudWatch AgentはENTRYPOINTに指定されているスクリプトを書き換えて裏側でnohupで立ち上げてあげることで、Agentのことを意識せずに動かせるようにしてあります。

#!/bin/sh
set -e

# Agentを裏側で実行する
nohup /opt/aws/amazon-cloudwatch-agent/bin/start-amazon-cloudwatch-agent > /dev/null 2> /dev/null &

# first arg is `-f` or `--some-option`
if [ "${1#-}" != "$1" ]; then
        set -- php-fpm "$@"
fi

# ユーザ切り替え後に/dev/stderrと/dev/stdoutをappユーザから触れないのでパーミッションを変えておく
chmod 777 /dev/stderr
chmod 777 /dev/stdout

# appユーザで指定されたコマンドを実行する(php-fpmなど)
sudo -u app "$@"

USER appなどでDockerfileの最後にユーザを切り替えてしまうとAgentが正常に作動しないので、rootとして最初は実行して実アプリケーションはユーザを降格して動かすという技を使って動かしています。

ENTRYPOINTのスクリプトはDockerfile内でCOPYして書き換えてあげると簡単に動かせる状態になります。

COPY --chmod=775 docker-prod/app/docker-php-entrypoint /usr/local/bin/docker-php-entrypoint

ビルドが遅い.... 遅すぎるぞ!!!!!

さて、弊社のアプリケーションのデプロイはCircleCIから行っている都合でビルドもCI上で行っていますが、どうしてもCIサーバ上だとライブラリのダウンロードが遅かったりPHPのエクステンションのビルドが重たかったりします。

レイヤーキャッシュ*1をしっかり効かせるのも大事ですが、CircleCIのビルドサーバからキャッシュが時間が経つと揮発してしまう*2ことがありデプロイの度にとても待たされることが多くありました。

そこで、レイヤーキャッシュのみならずBuildKit*3も有効化してマルチステージビルドにしている箇所についてはしっかり並列ビルドが走るようにしました。

qiita.com

composer installをマルチステージビルドに持っていってみる

今回は並列で処理できそうなcomposerのパッケージのダウンロードと展開処理を並列で実行できるようにしてみました。

FROM composer:2.2.7 AS composer-cache
WORKDIR /var/www/html

# キャッシュ作成用にcomposer.jsonとcomposer.lockだけ持ってくる
COPY composer.json composer.lock /var/www/html/

# ダウンロードと展開のみ行う
RUN composer install --no-scripts --no-autoloader --ignore-platform-reqs

FROM php:7.4-fpm
WORKDIR /var/www/html

# ここで重たいモジュールのビルド処理などを行う
# ~~各インストール、ユーザ作成処理は省略~~

# キャッシュ展開!!!
COPY --from=composer-cache --chown=app:app /var/www/html /var/www/html

# アプリケーションコードのコピーとcomposer install実行
COPY --chown=app:app . /var/www/html
RUN composer install

BuildKitが有効化された状態でこれを実行するとダウンロードは並行して裏側で行ってくれて、 composer install は実質オートローダの生成のみで爆速で終わるので依存ライブラリが多い方は試してみると良いかと思います。

f:id:kazuki09:20220323192529p:plain

高速化の結果、レイヤーキャッシュが効いた状態で2分程度(キャッシュなしで5分程度)でビルドが完了するようになりました。

何もしていないときは10分かかっていたビルドが5分、キャッシュありで2分まで縮められたので大きな進歩です!!!

僕はいつもなが〜〜いDockerイメージのビルドが走ってる間は推しのアイドル*4のことを考えながら過ごしてましたが、流石にその時間が長すぎるのも辛いので高速化して浮いた時間で仕事を早く終わらせてアイドル現場に行ったほうが良いですね!

(完全に余談ですが、最近弊社では #アイドル部 が出来ました!!好きな人が勝手に集まってやっている小さな部活動ですが、地下アイドルなど様々なアイドルが好きなひとが集まってます!)

さいごに

Dockerやコンテナの運用は非常に奥が深く語ると記事に書ききれない程ハマりポイント、気をつけなければならないポイントがあったりするので、記事では移行にあたり特筆すべきものだけ紹介させていただきました。

最後に... M&Aクラウドでは現在エンジニアやPdMなど幅広く募集中です!!もし興味を持ってくださった方はお気軽にお声がけください!

www.wantedly.com

www.wantedly.com

www.wantedly.com

*1:イメージビルドの過程で変更が無いレイヤを再利用する仕組みのこと https://circleci.com/docs/ja/2.0/docker-layer-caching/

*2:CircleCIのドキュメントによると3日で揮発するとのことです https://circleci.com/docs/ja/2.0/docker-layer-caching/#how-dlc-works

*3:並列的な依存関係の解決などを備えたビルドツールキットのこと。オプトインすることで使えるようになる。 https://docs.docker.jp/v19.03/develop/develop-images/build_enhancements.html

*4:筆者の推しはAppare!の藍井すずちゃんです

スタートアップのデザイナーに必要なマインドセット

f:id:mskikd:20220311190649p:plain

どうも。 M&Aクラウドのデザイナー、池田です。 今回初めて開発者ブログに執筆することになりました。 Tech寄りの話題を書きたかったのですが、デザイナーが書くTechな知見なんてたかが知れてる(ド偏見)ので、スタートアップを数社渡り歩いてきた僕だからこそ書けるような内容にしたいと思いました。

いろいろ悩んだのですが、やっぱりマインドかなと思ったので、今回はマインドセットについて書いていきます。

なぜマインドセットなのか?

中小規模のスタートアップにおいて、デザイナーが抱えやすい大きな悩みってなんだと思いますか?

僕が思うにそれは

孤独

だと思うのです。

スタートアップにおいてデザインの需要は高くなり続けていると感じつつも、デザイナーのリソースを確保できている企業は少ないように感じます。

どの企業もデザイナーの採用に苦戦している、もしくはデザイナー採用の優先順位が低いからか、インハウスデザイナーが1人もしくは2人、という企業が経験上多かった気がしてます。

そんな孤独と戦うデザイナーが安定したパフォーマンスを発揮するために必要だと思っているマインドセットを教えます。

完璧主義はゴミ箱へ捨てよう。スピード>>>>>こだわり

デザイナーにありがちなのですが、自分が納得いくクオリティでないとリリースはおろか、レビューにすら出さないという人、結構いるんですよね。

そもそもここで言うクオリティとはなんなのか?これをきちんと言語化できるのであればそこにこだわるのは重要だと思います。ですがここを言語化できる方は経験上そんなに多くありません。もっと言えば言語化できてもただの主観的感想である場合が多いです。

こだりが過ぎてリリースが遅れるのは本末転倒です。ましてやスタートアップであれば尚更です。

そのこだわりはユーザーと会社を幸せにするのか?というのは自問自答していきたいですね。

関心を向けて欲しいなら、まずは自分から歩み寄る。

これは人間関係全般に言えますが、相手を振り向かせたいのであれば、まずは自分から関心を向けることが非常に重要です。

むしろこれができれば孤独感とは無縁の生活を送ることができます。

しかし業務内容やスキームがまったく違うもの全てに興味関心を向けるのは、キレイごと抜きにしてまず無理だと思います。

なので、まずは人に関心を向けましょう

オススメのムーブとして推奨できるアクションは、以下の二つです。

  • デザインの手を必要としてそうな人に話しかける

  • 自分の仕事に人を巻き込む

最初はスモールアクションでいいので実践してみましょう。

思っているより人は優しい

これはまだ自分でもできていない(と思っている)のですが、社内のSlackなどで興味が働いた話題には立場役職を一旦忘れて乗っかってみることをオススメします。

多少空気を読むのは大事ですが、読み過ぎてしまうのもプレゼンス向上の妨げになると思っているので、激しく議論している場以外であれば「なんの話してるんですかー?」みたいなノリで話しかけてみるのもアリです。

自分が思っているより人は優しいと思い込めば、多少図々しくても堂々と振る舞えるはずです。

逆にここで冷たくあしらわれることが多い環境であれば、転職することを僕はオススメします。

最後に

この場でこんなことしていいのかわかんないけど、意外とアリだったりする。今までもそんなことの連続でした。

何事も自分の思い込み一つでどうにでもなっちゃうのが人生です。

デザイナーという職業に関係なく、どんな人にとっても有効なマインドセットだと思うので、一度脳内にインストールしてみることをオススメします。

最近新しい仲間が増えて、ようやくデザイナーチームが結成できました。僕より優秀で経験豊富な方がジョインしてくれたので本当に嬉しく思います。

おまけ

M&Aクラウドでは現在エンジニアやPdMなど幅広く募集中です。お気軽にお声がけください。

www.wantedly.com

www.wantedly.com

www.wantedly.com

【入社エントリ】スタートアップとM&Aと私。

f:id:mac_tokumoto:20220225001050p:plain

結論、この記事を3行で言うと。

  • 私徳本はExit戦略がないまま起業して、失敗した。
  • その後別会社でPMI、これまた失敗。
  • 「どんな終わりを迎えたいのか」は何を始めるにしても大事。

挨拶と駄文

こんにちは。M&Aクラウドでプロダクトマネージャをしております、とくちゃん(@PdMtokuchan)と申します。このブログを見てくださってる熱烈なM&Aクラウドマニアの方にとっては周知のことかと存じますが、M&Aクラウドは「テクノロジーの力でM&A流通革命を」をミッションに、M&Aのマッチングプラットフォームを運営している会社です。手前味噌ながら当サービスも順調に成長を続け、昨年には10億円の資金調達も完了し「今グイグイきてますね」「バキバキっすね」「コッカラッス」と方々からご声援を賜っておりまして、大変誇らしい気持ちと「俺まだ何もしてないんだけどな」という後ろめたさの間で日々奮闘しております。

note.com

そんなM&Aクラウドで私が普段やっていることは、非常に大雑把にいうと「解くべき課題は何かを明らかにするお仕事」でして、いわゆるユーザインタビューを実施したり、ビジネスサイドのメンバーと共にオペレーションを回したりしながら「あれからぼくたちは、何かを解決できたかなあ...」と頭を抱えながら「解くべき課題は何か」ずっと考えております。実はM&Aという世界は、レガシーかつ非常にブラックボックスな部分が多く、まだまだ課題がたくさん存在しています。そしてそれらの多くは、未だ解決の糸口が見つかっていない混沌とした世界なのです...。私も入社して半年が経ちますが、まだ結果を出せていないことに加え、事業ドメインの難解さに頭が追いつかないシーンも多々あり、悪戦苦闘の毎日で、毎晩ガチで泣いてます。

さて、この記事は入社エントリということですが、私がM&Aクラウドに入社したのは2021年8月ですから、入社エントリを書くにはあまりにも遅すぎるのではないかと、そんな声も聞こえてきます。が、私だって自分語りをさせてほしいよと。ちょっとくらい自分の話をしてもいいじゃないですかと、ワガママを許していただきまして、筆を走らせております。開発メンバーのみんな、ブログを書かせてくれてありがとうございます。

先にこの記事のキーワードをお伝えしておくと「Exit戦略の欠如」です。これが、現時点で私が強く感じている問題意識であり、私自身大切にしたいと考えているテーマでもあります。

スタートアップと私

私事ながら今年で齢30を迎えるのですが、就職をして初めて正社員として働き始めたのが28歳からでして、ここ数年で「お金もらって休めるだと!?有給やべえ!」「タイムカード切るってボタン押すことなのか」など、いわゆる会社として当たり前に存在している概念を肌で感じ、プリキュアくらい目をキラキラさせながら仕事をしておりました。それまでは何をしていたかというと、5年も通った大学を5年連続で単位を落とした化学Ⅰに心を折られ退学し、ほぼ未経験にも関わらずフリーランスWebデザイナーを名乗り「なんでも作れます」と大風呂敷を広げながらコーポレートサイトやLPをゴリゴリ作ってなんとかその日暮らしの日銭を稼ぐようなスタイルで生存していました。2015年、23歳のときです。キャッシュフローも一切安定してないので「次の入金まで残高17円、あと1週間どうする?」みたいな日々で、金ないね🤗ってことでバンド友達(当時バンドやってたので)と高円寺の高架下で明け方まで「弾き語りして投げ銭もらうまで帰れまテン」を開催し、泥酔寸前のおっちゃんから1万円投げられるという奇跡を起こすなど、もう今思い返しても大変怪しい奴だったと思います。靴工場に住んでましたし。

tokyo-style.cc

そんな怪しい私を面白がってくれていた大学時代の先輩に誘われる形で一緒に会社を作りました。2017年、25歳の時です。当時はKURASHIRUやDELISH KITCHENなど「動画メディアがやべえ」みたいな流れが出来ていた頃で、同じようなジャンルのメディア同士でもガンガン調達してて、純広告の単価も再生数あたり十数円みたいな、今考えるとかなり過大評価されてた市場だったと思うんですが、とにかく動画の波がやばいんだってことで我々も動画メディアにかけましょうとなり、漠然と市場規模もそこそこありそうなフィットネス・ダイエット市場を狙って上場目指そうぜということでダイエット動画メディアをインスタで立ち上げることになりました。これが1つ目の「Exit戦略の欠如」です。

メディアの方も運良く成長し続けることができ、国内でフォロワー数が最も多いダイエット動画メディアへと育てることができました。その影響もあって、動画メディアを立ち上げたいクライアントのご相談も増え、会社としても少しずつ成長し、ご縁があって初めての資金調達をさせていただく機会もいただき「なんかよくわからんが最近良いこと続いてるし俺たちいけるのでは?」みたいな傲慢な気持ちが生まれてしまったのもこの頃だったと思います。非常に漠然とした戦略として「集客装置が完成すれば、あとは何かを売れば良いだけじゃん」という超絶雑な考えが当時あって、そのシナリオ通りにはきていたのですが、「何かを売る」ということの難しさを全く理解できていなかったこと、そして会社としてどこに向かっていきたいのか明確にできないまま走り続けてしまったことが仇となり、結果として非常に中途半端な形で様々なサービス・商品を生み出し、そして明確な撤退基準もないまま立ち上げたサービスや商品たちはクローズさせ、メディアだけがぽつんと一人残ってしまいした。

「戦略をちゃんと描けてなかったよね」と言ってしまえばそれまでなのですが、もう少し掘り下げて考えると「会社としてどこをゴールにして向かっていくのか」≒Exit戦略を描いていく必要があったのかなと、今にして思うのです。大まかに言えば 1.経営を続ける 2.誰かに譲る 3.廃業するの3パターンがあって、その中でも上場するのか非上場のまま続けるのか、社員を後継者にするのか他社に買ってもらうのか死ぬまで経営者を続けたいのか、etc...。会社のゴールひとつとっても様々な形があるはずです。そのゴールから逆算して、どの市場に張ってどの上場企業をベンチマークし、どこを競合優位性として戦っていくのかなど、一つずつ決めていくべきでしたが、当時の私たちは漠然と「動画がキテる」とか「そこそこ市場規模が大きい」みたいなふわっとした理由で事業ドメインを決めてしまい、そこに全振りしてしまった。不幸なことにフォロワー数などメディアに係る短期的なKPIは大きく成長していていたことも、後戻りできなかった大きな要因だと感じています。Exitを考えるということは長期でものごと考えることだと言うことです。これが私にとっての初めてのスタートアップであり、大きな失敗でした。

M&Aと私

その会社では前述の通り多くの失敗を経て、私と共同創業者の方との間で「目指す方向性違ってきちゃいましたね」という話し合いをして、私は退職して一般企業に就職することにしました。今でもそうですがあらゆる部分でビジネスマンとしてのスキルや経験が乏しすぎるなという実感があったので、色々な経験してる人と働いてみたいなということで初の転職活動です。何処の馬の骨かもわからない私をご縁があって拾ってくださったゲーム開発会社がありまして、そこで1年ほどお世話になりました。

そこでは「新規事業をやるぞ!」ということでディレクター的な動きをしていたのですが、前職の共同創業者の方から「動画メディアを売りたい」という話を聞いていたのでゲーム会社の上長に「買ってみます?」とフワッと話を持っていったところ、会社としてライブ配信や動画に注力していたということも相まって事業買収へと進んでしまいました。これが2つ目の「Exit戦略の欠如」です。

当時、私の中でダイエット動画メディアが事業として成り立つ正解の一つは物販だと考えていました。これは前職でPoCとしてメディアを通してアパレルウェアなどを販売していたのですが、撤退理由が「入金サイクルが遅くて在庫積めないから」というもので、逆説的にキャッシュがあればクリアできる問題だと考えていたからです。当然それだけでうまくいく理由にはなりませんが、お金がない弱小企業にとって超絶ボトルネックであったキャッシュフローが解消される環境であれば、まだやりようがあるのではと思い企画書を持ち込み経営陣にプレゼンしました。が、結論としては「在庫ビジネスを社としては取り組まない」と跳ね返され、すでに経営陣の中で決まっていたある事業内容で進めていくぞということでPMI担当を任されることとなりました。詳細は書けないことも多いので端折りますが、いくつかの理由でプロジェクトは頓挫し、事業として再生することはないままプロジェクトは終了してしまいました。

ひとえに私の力不足に尽きるわけですが、経営陣と事業としてのゴール≒Exit戦略をうまく共有できず、プロジェクトを破綻させてしまいました。もちろん、世の中の起業家・経営者は私よりも数百倍優秀ですから、こんな話は笑われてしまうかもしれませんが、現実にPMIというものは非常に難易度が高く、どの企業も買収後どのようにして既存事業や社員とシナジーを発揮しながら成長させていくかは大きな課題と言われています。小さなプロジェクトではありますが、私自身PMIの失敗を経て、M&Aというものの難しさを強く実感した貴重な体験でした。

私はこれから

こうやって振り返ると、業界的には全くの畑違いからM&Aクラウドへやってきたわけですが、M&Aというものは私にとって大変苦い思い出であり、そして何故だかご縁を感じずにはいられないテーマなわけであります。マクロな話や業界の専門的な話は弊社が運営するメディア「Update M&Aクラウド」にお任せするとして

update.macloud.jp

note.com

update.macloud.jp

私の個人的な想いとしては、すべての起業家や経営者が正しいExit戦略を描き、彼らやステークホルダーがもっとハッピーになる世界になってほしいと強く願っています。起業をするにしても、あるいは企業を買収するにしても、何かを始めたら必ず終わりがあるはずで、きっとそれは私のような一介の社員にとっても同じくらい重要なことだと感じています。「どんな終わりを迎えたいのか」そんなふうに書くと少し大袈裟なようにも聞こえますが、私たちはみんないつか死んでしまうし、今続いてる幸せも永遠ではありません。だからこそ、目の前の小さなタスクから、家族や会社の未来、自分の人生まで「どんな終わりを迎えたいのか」ということを自問自答しながら日々生きていきたい。そんなことを考えながら、私はM&Aクラウドで出来ることを精一杯やり続け、終わりに向かって走り抜けたいと思います。なんだこの入社エントリ。よし、今日もがんばるぞ。

あと、採用も頑張ってます。(唐突)「M&Aクラウドってどんな感じ〜?😇」みたいな軽ノリで雑談するのも大歓迎ですので、wantedly経由でもTwitter経由(@PdMtokuchan)でもコンタクトとっていただければと思います。おしゃべりしましょう〜!

www.wantedly.com

www.wantedly.com

M&Aクラウドの「スクラムマスターの型」

f:id:hamakou108:20220215125436j:plain

こんにちは。 スクラムマスターの濱田( @hamakou108 )です。

弊社の開発チームでは特定の役割を遂行するための指針を「型」として文書化し、チーム内で共有しています。

tech.macloud.jp

tech.macloud.jp

tech.macloud.jp

今回はその一つである「スクラムマスターの型」を紹介します。

昨年末より弊社の開発チームではスクラムを使って開発を進めています。 自分は入社以来エンジニアとして開発に携わってきましたが、チーム内でもスクラムに関する知見がある方だったので、今は専任スクラムマスターとして役割をこなしています。 幾つかの困難はありましたが、スクラムが始まってからメンバー視点でも良い変化を感じているようです。

スクラムが何とか軌道に乗ってきたところで、次にスクラムマスターの引き継ぎという課題に取り組んでいます。 スクラム開始当初から、エンジニア内でスクラムマスターを数ヶ月スパンでローリングする計画を立てており、今月はスクラムマスターの引き継ぎを粛々と進めています。

ただ、スクラムマスターに期待される役割はエンジニアとは大きく異なります。 自分は前職でのスクラムマスターの経験から業務内容をある程度イメージできたものの、いざ進めてみるとチームの問題解決に悩む場面が多くありました。 そのような経験を顧みたとき、スクラムマスターの指針となるようなドキュメントがあると嬉しかったという思いから、「スクラムマスターの型」を作成しました。 スクラムマスターのこれまでの業務の引き継ぎに加えて、このドキュメントなどを通してスクラムマスターの責務を明確にすることで、意欲があれば誰でもスクラムマスターの役割を果たせるような体制を作りたいと考えています。

弊社に限らず、他社のチームのスクラムマスターにも参考になればと思い、このドキュメントの内容を紹介します。


はじめに

これは何?

弊社におけるスクラムマスターの役割についてまとめた資料です。 M&Aクラウドで新しくスクラムマスターを担当される方にとっての指針となることを狙いとしています。

このドキュメントで書かないこと

スクラムマスターの役割

スクラムガイドによると、スクラムマスターが責任を持つのは次の2つ。

  1. スクラムガイドで定義されたスクラムを確⽴させることの結果
  2. スクラムチームの有効性

1 の責任を果たすために、まずスクラムマスター自身がスクラムの理論、プラクティスを理解しよう。 スクラムは「経験主義」と「リーン思考」に基づいており、これらを理解しないままスクラムを実践することは難しい。 「経験主義」や「リーン思考」について理解を深めたい場合、例えば以下のような書籍を読んで理解を深めよう。

2 の責任を果たすために、スクラムマスターはスクラムチームをゴールに向けてコーチングしよう。 チームの置かれた環境は市場、組織、プロセス、プロダクト、メンバーなど様々な要素で構成され、各チームによって固有のものとなる。 したがって、同じような問題であっても有効な解決策はチームによって異なる。 スクラムマスターはチームの状況と発生した問題を観察し、スクラムが確立された状態を維持しながら、チームが自分たちに合った適応を実践できるように手引きしよう。

本やネット上のリソースをそのままチームに適用しても機能するとは限らないが、似たような問題への対処例として参考にできる側面もある。 例えば以下のような書籍を読んで参考にしよう。

判断に迷ったときは「経験主義」と「リーン思考」に立ち返ることをおすすめしたい。 その方策が「経験主義」や「リーン思考」を強めるかどうか考え、チームが正しい方向に向かっているのか判断しよう。 チームが方策を決めるまでのプロセスに関しても、上記の基準に照らして振り返ると良い。

標準的な業務およびプラクティス

M&Aクラウドスクラムマスターの標準的な業務およびプラクティスについて記す。 なおこれらの役割分担やプラクティスが有効かどうかはチーム固有のコンテキストに依存するため、スクラムマスターは臨機応変に業務の委任や排除について判断しよう。

スクラムを始める前に

チームを設計する

チームを構成するメンバーがどのような専門性、価値観、性格を備えているか理解しよう。 例えばどんなに技術的な専門性が高くても、アジャイルスクラムの価値観に共感してもらえないメンバーをスクラムチームに加えることのリスクについて考えよう。

チームのサイズについても考慮しよう。 チームメンバーの数が少なすぎるとチーミングによる相乗効果を生み出せず、多すぎるとコミュニケーションパス増大の問題が顕著となる。

また弊社にはエンジニアメンターの型として規定されるようなメンターの役割が存在する。 メンター役のメンバーと業務がコンフリクトしないように、メンターとスクラムマスターの間でどのように役割分担するのかあらかじめ調整しておこう。

スクラムを設計する

スクラムを構成する要素についてあらかじめ設計しておこう。

  • スプリントのタイムボックスを何週間にするか
  • スクラムイベントはいつ、何時間行うか、誰を招待するか、どのようなアジェンダで進行するか
  • プロダクトバックログやスプリントバックログをどのように管理するか
  • ユーザーストーリーをどのようなフォーマットで記述するか
  • DoD や READY をどのように定義するか
  • 開発やコミュニケーションにどのようなツールを利用するか
  • etc.

これらの最適解もチーム固有のコンテキストに依存する。 しかし一般的に言って、チームがアジャイルスクラムに慣れていないほど丁寧に導入した方が良い(タイムボックスを長くする、スクラムイベントの進行ルールを細かく規定しておくなど)。

スクラムについてチームに理解してもらう

チームがスクラムについてあまり理解していない場合、スクラムマスターはチームにスクラムを伝授しよう。 最初のスプリントを開始する前に、スクラムとは何か、スクラムはどのようにして問題を解決するのかをチームに説明して理解してもらおう。

チームがプロダクトの置かれている状況について理解していないようなら、 PO からプロダクトゴールについても説明してもらおう。 またインセプションデッキを作るなど、そのチームが置かれている状況について双方向的に理解を深めるのも有用だ。

スクラムを回す

スクラムのルールを守らせる

スクラムを実践する中で、スクラムから逸脱するようなチームメンバーの意見や行動があれば指摘しよう。 どうすべきか伝えるだけでなく、なぜそうすべきなのかも併せて伝えよう。

スクラムイベントのファシリテート

スクラムイベントのファシリテートはスクラムマスターが担当しよう。 各イベントをどのように進行するのか、どのような問題が生じる可能性があるのか、あらかじめシミュレーションしておこう。 必要があればチーム内外のメンバーに協力を依頼して、スクラムイベントが円滑に進行され、きちんと目的が果たされるように取り計らおう。

  • e.g. スプリントプランニングの前に PO にプロダクトバックログをリファインメントしてもらう
  • e.g. スプリントレビューの前にデモを担当する開発者を決め、リハーサルをしてもらう

ファシリテートそのものに関してはファシリテーター & 議事録係の型も参照。

障害物を排除するように促す

スクラムチームの進捗を妨げる障害物があれば、チームがそれを排除するように働きかけよう。 特にデイリースクラム、スプリントレビュー、スプリントレトロスペクティブについては、「検査」と「適応」が促されるようにイベントを設計し、ファシリテートしよう。 イベントの外でもチーム内外の状況やコミュニケーションを目ざとく観察して、障害物の予兆があればいつでも出向くことができるように備えておこう。

このときスクラムマスターは自分自身で障害を排除してしまわないように注意しよう。 スクラムマスター自身で対処してしまうと、チームメンバーの学習の機会を奪ってしまうことに繋がる。 ただしプロジェクトの存続に関わるほどの緊急事態であれば、この限りではない。

チームを成長させる

チームの成長には時間が掛かることを理解しよう。 タックマンモデルによると、チームは「形成期」、「混乱期」、「統一期」、「機能期」の順に成熟する。 チームがいかに「形成期」と「混乱期」をスピーディーに通り抜けられるかは、スクラムマスターの腕の見せ所だ。 チームメンバーが互いの価値観を理解し合えるようなレトロスペクティブの方法や協力して問題に取り組むためのプラクティスを導入するなどして、チームの結束や信頼感を醸成しよう。

またチームの成長に合わせて、チームがより中長期のゴールにフォーカスできるようにしよう。 例えば Sailboat Retrospective などを活用してチームがゴールについて振り返られる機会を設けよう。

またチームのメンバーが変更された場合、チームは「形成期」から成長のはしごを登り直さなければならない。 チームメンバーの変更を打診された場合、スクラムマスターはそれがチームにどのような影響を与えるのか説明できるようにしておこう。

スクラムを広める

ある程度スクラムマスターとしての経験を積んだ人向けの話。

スクラムマスターの育成

自チームのスクラムマスターを引き継ぐ、あるいは新しくスクラムチームが発足するとき、スクラムマスター経験者として新人スクラムマスターを育成しよう。 実際にその人がスクラムマスターとして働き出す前に、自分がスクラムマスターを経験して得た知見や資産をその人に伝授しよう。

また実際にスクラムマスターを担当すると様々な状況に直面することは実感しているはずだ。 そんなときにいつでも相談できる先駆者の存在は支えになるので、新人スクラムマスターを積極的にメンタリングしよう。 特にスクラムを初めて1ヶ月経たないうちは、少なくとも毎週 1on1 する時間を確保しよう。


おわりに

いかがでしたか? 生まれたばかりでまだまだ揉まれ足りていないドキュメントではありますが、自分と同じように悩める駆け出しスクラムマスターの助けになれば幸いです。

また弊社ではエンジニアやプロダクトマネージャーを積極募集中です。 もし興味があれば気軽に話を聞きにきてください!

www.wantedly.com

www.wantedly.com

www.wantedly.com

【これが私たちのオフィス】エンジニアチームを支えるコミュニケーションツール

f:id:zacky2:20220210154514p:plain

はじめに

こんにちは、エンジニアの津崎( @820zacky )です。 今日は、弊社で全社的に使っているSlackについて、 エンジニアチームがどのように利活用しているかについてご紹介いたします。

弊社には金融や商社といったメール文化の会社出身の方もいるのですが、入社後は全員Slackを使ってもらっています。最初はスタンプやスレッドに慣れないようですが、特に不満の声はなくみなさん使いこなしています。

Slack自体が、情報のハブになっていて、さまざまな機能を果たしているので、こちらを深堀りして紹介したいと思います。

Slackの利活用

エンジニア同士のチャットコミュニケーション

エンジニアチームがメインで使っているチャンネルでは、 雑談も混じるような形で、カジュアルにチャット感覚で利用しています。 リアルなオフィスで行われる会話に近いイメージです。

f:id:zacky2:20220210153730p:plain f:id:zacky2:20220210153151p:plain f:id:zacky2:20220210153250p:plain

業務連絡だけでなく、気軽に考えを書き込むことで、一人で困って問題を抱え込むことを防いだり、チームの一体感の醸成につながっています。

エンジニア同士の音声コミュニケーション

SlackのHuddle機能を使って、ちょっとした相談や、ペアプロ、レビューをしています。 今までに音声チャットツールとして、Slackビデオ通話や、GoogleMeet、Aroundなどを試してきましたが、ダントツで使いやすいため定着しています。

すぐ繋げられる。誰が話してるかわかる。他の人の通話に乱入できる。ラジオ感覚で聞ける。といったメリットがあります。 Huddleのおかげで、ちょっとした相談のハードルがめちゃくちゃ下がっています。

がっつりペアプロやモブプロをしたいときは、PhpStorm の Code With Me という機能で同時編集をしていますが、簡単なペアプロであれば、画面共有で済ませることもあります。

各種ツールからの通知を確認

障害アラートやGitHubのコメントなどをSlackに通知しています。 さまざまなツールと連携しているので、Slackの通知だけ見れば良いようになっています。

- Google Calendar
- Google Drive
- Jira
- AWS CloudWatch アラート
- プロダクト(バッチ処理結果やユーザー登録結果など)
- Rollbarのエラー通知
- Figma

報告や意見を受け付ける窓口

エンジニアチームではバグ報告やプロダクトへの意見を受け付ける窓口専用のチャンネルを設けています。

これを整備するまでは、個人のDMで相談があったり、メンション先のエンジニアを誰にしていいのかわからない、といった問題がありました。

f:id:zacky2:20220210142124p:plain
開発総合窓口チャンネルのワークフロー
エンジニアに依頼、相談、報告したいときは「開発総合窓口チャンネル」を開いて上記のワークフローを通してもらうようにしています。 Slackワークフローを整備することで、フォーマットの統一化を行いコミュニケーションコストの削減を行なっています。

「バグ報告」ではなく「バグかもしれない報告」にしているのは、気になることがあれば気軽に相談してほしいというニュアンスを表現するためです。

f:id:zacky2:20220210141851p:plain
サービス改善提案のワークフローによる投稿
1クリックでJiraのIssueに変換できるといった機能も実装しています。

全社的な情報共有や他部署の動向を知る

全員が参加しているチャンネルにて、経営会議の内容の共有や、健康診断のアナウンスといった全社的な情報共有を受け取っています。

営業やCS、MACAP(M&Aのアドバイザーチーム)といった他部署のコミュニケーションもそれぞれのチャンネルを覗くことで見ることができます。 M&Aに関わる秘匿情報などはprivateチャンネルで行われていますが、それ以外のコミュニケーションは基本的にオープンにするという社内文化があります。

部署を超えた雑談コミュニケーション

普段から雑談を行うことで、相談や報告の心理的ハードルが下がるという効果があると言われています。 弊社では雑談用のチャネルが複数あり、活発に雑談が行われています。

カスタム絵文字を使ったコミュニケーションも活発です。 絵文字についてはこちらの記事をご覧ください。

tech.macloud.jp

部活動コミュニケーション

弊社にはたくさんの部活があります。特に会社の制度というわけでなく、好きな人が勝手に集まってやっている活動です。 部活ごとにチャンネルがあり、それぞれでアナウンスや雑談が行われています。

私が認知している部活は以下です。

- 筋トレ部
- サウナ部
- キャンプ部
- 漫画部
- キネマ部(映画部)
- ゲーム部
- ボルダリング部
- フットサル部
- ワーケーション部

弊社最大の部活である「筋トレ部」に興味がある方はこちらをご覧ください。

update.macloud.jp

おわりに

本当はエンジニアチームで使っているツール群を紹介するつもりだったのですが、 Slackについてのボリュームがデカすぎたので、今回はSlackの利活用についてのみ紹介しました。

エンジニアチームがSlackをどのように活用しているかイメージが伝わったら幸いです。

www.wantedly.com

www.wantedly.com

これが私たちの勝ちパターン【開発メンバーの型】をご紹介

f:id:tsukahara1991:20220125001537j:plain Free Office Image on Unsplash

こんにちは。エンジニアの塚原(@AkitoTsukahara)です。

弊社の開発チームでは業務の知見を「型」として文書化し、チーム内で共有しています。これまでにもいくつか型の紹介をさせていただきました。

tech.macloud.jp

tech.macloud.jp

tech.macloud.jp

今回は型の中でも一番読み返されているであろう「開発メンバーの型」について、ご紹介させていただきます。 この型はメンバーが高い生産性を実現するためのルールでもあり、新しく入社したメンバーがチームで活躍するための道標にもなっています。 ですので以下のような方におすすめの記事になっております。

  • 開発メンバーのルールを明文化したいリーダー
  • 新しく入社したメンバーをサポートするメンター
  • チームで活躍したいメンバー

これより以下はほぼ原文ままになります。

弊社ではプロジェクト管理にJira、開発手法にスクラムを採用しています。 これらの専門的な用語には注釈を付けさせていただきました。


これはなに

M&Aクラウドにおける開発メンバーの型です。
これに沿って生産性の高い状態で作業できるようにする。

マインドセット

チームの仕事である

開発チームの仕事はチームでやることである。
成果物はチームの共有物。自分だけの仕事が進んでもユーザに大きな価値は届けられない。 そのために以下のことを前提として意識する

  • 自分の仕事を終わらせるために人のリソースを使う(無駄使いはしない)
  • 人の仕事を終わらせるために自分のリソースを使う

理解が甘いものは外に出さない

  • 仕様について
    • 自分がタスクとして取り組む作業の仕様は、自分が納得いくまで理解してから取り組む
      • 背景の理解
      • 影響範囲の理解
        • ページや機能の影響範囲
        • 社内ユーザ含むユーザへの影響範囲
  • コードに対しても納得して人に説明できる状態になること
    • 自分が書いているコード
    • 他人が書いたコードも、自分がレビューした場合、自分のものとして納得して説明できるようにする

開発メンバーがやること

タスクをやる

着手するまえに

  • 「ユーザーストーリー」*1と「AC」*2を理解する
  • 想定されていた仕様や影響範囲に誤りがないかコードや仕様を調べる
  • 小さいタスクでも情報を持っている人に仕様の認識合わせをする
    • 急ぎでなければSlackでも良いが、口頭や通話も積極的に活用する
    • 口頭で話した内容は Jira issue*3に経緯と結論を記録しておく
  • タスクをやる前にタスクが属する一連の作業の全体像を掴む
  • 具体的にコードをどのように変更すれば良いかイメージする
    • 必要に応じて書き出して抜け漏れを防止する

タスクの進め方

  • 「 READY」のタスクを受け取り「IN PROGRESS」に移す*4
  • 着手前に想定した方針にしたがって変更を行う
  • 方針を立てる前にとりあえずコードを書くはNG

f:id:tsukahara1991:20220125113204p:plain
Jiraのカンバンボードでタスクの進捗ステータスを確認する

自分の状況をオープンにする

  • 詰まった時だけではなく、できれば今何をやっていてどういう風に進めようとしているのかもオープンにする
  • ※詰まるとは?
    • 調べて突破口になる解決策が全く見えない時
    • タスク内容によるが、以下のような目安
      • 仕様や背景が分からない場合。すぐに聞く。
      • 技術的に詰まった場合(調べていて新たな検討できる情報がない時)
        • まずはググってみる、関連実装探してみる
        • 15分程度で詰まりつつあるくらいであれば Slack などに投げ込んでおく。非同期できく。
        • 1時間以上詰まる場合には積極的に指名したり口頭相談したりヘルプを求める

実装について

  • 「すでにある実装」はあくまで参考にとどめ、あるべき形考えてそれを表現するコードを書く。
    • ただし、大きく設計が変わる場合には他との整合性が取れなくなる可能性があるので、チームに提案ベースの相談をしてから進めると良い
  • 変更するコードの影響範囲を調べ、それぞれの箇所でユーザに価値が変らず届けられているか確認する
  • アーキテクチャに関わる実装変更が必要であると判断した場合は、コードを変更する前にメンバーを集めて意見を募る

ストーリーポイント*6が妥当かどうか

  • ストーリーポイントは基準となるタスクをあらかじめチームで決めておき、0.5,1,2,3,5,8,13とフィボナッチ数列の数から決める
    • 8ポイント以上の大きいタスクの場合は、1ptの調査タスクを実施してから残りの作業分を1,2,3,5に振り分ける
  • ストーリーポイントの決め方や基準となるタスクに違和感があったらそれ自体を議論する

時間の使い方について

自分のタスクをやっているときに詰まったり、トラブルがあったときの動き方。

  • 他の人の助けがあればすぐ解決するものは人の力をうまく使う
    • 誰かに聞けば分かることなのに半日や一日使うのはNG
    • 明確に、その領域に対しての学習のために幅広く何かを学ぶという目的があればある程度時間を使っても良いが、右往左往している時間は勿体無いので減らすこと。誰かと協力して短時間で解決した後に、腹落ちのためにちゃんと調べても近い学習効果は得られる
  • 時間をかけていいこと
    • 誰かに聞いても分からなかったこと
    • 他に回避の道がない場合。自分しかできない仕事の場合
      • 記録を残しつつ、進捗や学びは共有しつつ進める

我々はユーザにアウトプットを届けるために仕事をしている。また、一人の力ではなくてチームのアウトプットとして外に出しているのでその過程もチームの力をうまく使うこと。

レビューをやる

1チケット制限

M&Aクラウドの開発チームでは「1チケット制限」を導入してます。
基本的にタスクは1つだけを持つこととし、二つ以上のタスクは並行して行わないようにしています。
目的は、複数のタスクが並行で走ることによるコンテキストスイッチの増加による生産性の低下を防ぐこと。

レビューは自分の仕事と同等か、やや優先するくらいの気持ちで

1チケット制限の前提において、誰かのPRが来ているということは、その人は手が空いてしまっているということ。
合間の時間にチケットとは無関係の仕事を進めることはできますが、あまりに時間が開くと優先度の低い仕事をやってしまうことがあります。
そのため、レビュー依頼が来たら30分~1時間程度以内で最初のチェックをすると良いです。

マージされなければ1チケット制限は解除されないので、マージまで伴走する気持ちで進める。
例えば良く分からないコードがあった場合に「よくわからないから後回しにしてしまおう」ではなくて、「よくわからないので口頭で解決しよう」が推奨されます。

リリースする

他の人の仕事も含めて巻き戻しや修正の判断ができる状態になったら「リリたん」(リリース担当)の一人になります。

会議を前に進める

チームでの成果や合意の方向に向いて発言をすること。
会議目的からずれる発言は、一旦メモをしておき、後で適切な会議に持ち込んだり非同期で話すなどする。
単に自分が言いたいだけの話は、会議以外の少人数の集まりの時にする。

会議体

インフラ確認会

  • 新しいAWSコンポーネントを使ったりする時には、開発チーム全体に背景情報と知見共有のために「インフラ確認会」を開催する。
  • 既に何度も類似の設定がされている場合にはインフラの変更であっても小チーム内のみの確認でOK
    • ただし、設定する内容は開発チーム全体に影響する可能性があるのでSlackなどで全員が作業したことが分かるように連絡はしておく
  • 以下の情報を資料に含めてメンバーが設定する
    • 背景情報(解決したい問題など)
    • 設定概要(ここまでエンジニア全員が出席する会)
    • 設定詳細(興味ある人、小チームメンバーが出席する)
      • ドキュメントと見るべきところ。 ドキュメントが分かり易ければリンクだけ貼っておくでも良い

その他

人のマインドシェアを取らないように動く

前提: 仕事を任す人がリーダーであってもPdMであっても、リソースは限られているので全てのタスクについて詳細情報を持って適切なタイミングでリマインドすることは不可能。スケールするチームのためには、メンバーそれぞれが一番詳細度の高い情報を持ってタスクを進めることが肝要。

任された仕事について、責任を持って詳細まで含めて着地に持っていくこと。
仕事を任された時点でその仕事はメンバーの持ち物。
以下のように動く。

  • 最終ゴールまでにやらなければいけないことはメンバー側が情報を全て持っていること。また、そのように情報を集める
  • メインのタスク以外で任された細かいものも、いつまでに回答 or 終わらせるかなど明示的にコミュニケーションする

※「人を頼ってはいけない」とは違うので注意。前述の「時間の使い方について」の通り、チームとして成果を得るために情報が足りなければ他の人のリソースも積極的に活用する


採用やってます

弊社ではエンジニア採用を行っています。 スタートアップ企業でのWeb開発に興味のある方は、ぜひカジュアルにご応募ください🤝

www.wantedly.com

www.wantedly.com www.wantedly.com

*1:ソフトウェアの機能がユーザーにとってどのような価値をもたらすのかを示すもの

*2:受け入れ基準 (Acceptance Criteria):プロダクトオーナーの視点から何を持ってプロダクトバックログアイテムが完成したかを確認するための基準

*3:Jiraにおけるタスクの意味

*4:「 READY」、「IN PROGRESS」は Jiraのタスク進捗ステータスを表します。

*5:スクラムチームの開発者のための15分のイベントである。複雑さを低減するために、スプリント期間中は毎⽇、同じ時間・場所で開催する。

*6:ユーザーストーリーを実装するのに必要なコストを見積もるための単位

【6人採択!】 PHPerKaigi2022 に8人全員で合計12個のプロポーザルを提出しました【全員インフルエンサー】

f:id:yamotuki:20220119120026p:plain

※この記事は採択発表の前に書いております。採択発表後に一部追記しました。
結果、6人が採択され、発表することになりました!

こんにちは。エンジニアの鈴木(@yamotuki)です。
今年もPHPerKaigiの時期がやってきました!

弊社では、去年はエンジニア全員でプロポーザルを出し、全員が採択されて発表を通して盛り上げることができました。(一昨年はひっそり私だけ参加しておりました)

今年はプラチナスポンサーとしても協賛しています。

「スポンサーチケットがあるのでトーク採択されなくてもいいや」なんてのは甘い!
弊社メンバーは「全員インフルエンサー」のバリューを胸に、エンジニアであるなら発表で参加したい! そんな気持ちでプロポーザルを提出しております。

8人で出した全12個のプロポーザル、全て紹介します。
さあ、何個採択されるのか?!
採択されて欲しいものがあったら清き1票をお願いします! 盛り上げていきましょう!

※【採択】【不採択】を追記しました。
※紹介順序は順不同

【採択🎉】(LT)Predefined Interfacesを使って便利な独自クラスを作りましょう!

CTO荒井さんによるプロポーザル。「最近コード書いていないのでネタが無い」などとと言いつつしっかり出してきてます。流石。

皆さんはPHPでの開発でPredefined Interfaces(定義済みInterface)を使っていますでしょうか?PHPにはIteratorやStringableといったシンプルですが便利なInterfaceが用意されており実装することで、独自のクラスをPHPのプリミティブな型と同様に扱うことができます。どうやってPredefined Interfacesを使うのか、どんなメリットがあるのかを解説します。

https://fortee.jp/phperkaigi-2022/proposal/2c8b0e09-b321-49ba-89c7-d9b25ecc844e

【採択🎉】(LT)PHPの緩やかな比較の実態

入ったばかり20歳國村さんによる発表です。
「おいおい最近の若い人はPHPの内部実装にも詳しいのかよ...」そんな風に思ったおじさま/おばさま方、ここでしっかりPHP内部構造も学んでおきましょう。

みなさんよくご存知の通り、PHPには等価演算子が2つあります。
「==」と「===」です。
前者は緩やかな比較、後者は厳密な比較が行われます。
PHPやJavaScriptに馴染みのある方ならよくご存知だと思います。

言語問わずよく使う演算子の1つである等価演算子ですが、実際の言語仕様は知っていても
内部の実装は知らないなんてことはよくあると思います。

今回はみんな嫌いな緩やかな比較の実装がどこにあるのか、そしてどんな実装がされているのかをお話しようと思います。

https://fortee.jp/phperkaigi-2022/proposal/3f638a7b-3e63-4a34-a14e-5658011bb60c

【採択🎉】(LT)気づいた時にリファクタしよう!Laravelのデータベースクエリを最適化するTips

塚原さんによるプロポーザルです。 弊社で長年の負債だった部分をちびちび改善しようという取り組みについてですね。メンバーみんなで細かく改善すれば大きな問題も怖くありません。

みなさんはパフォーマンス改善のためにアプリケーションの最適化に取り組んだことがありますでしょうか?
何もデータベース構造を再構築したりと大規模な改修することだけが最適化ではありません。機能実装のついでに関連処理をリファクタリングしてあげるだけでも十分な最適化になります。

このトークでは気づいた時にちょっとリファクタできる程度のデータベースクエリの最適化Tipsを解説いたします。
5分間で可能な限り詰め込んでお届けします!

こんな方におすすめ

業務でLaravelを利用されている方
日頃からパフォーマンスを意識した実装をしたい人

https://fortee.jp/phperkaigi-2022/proposal/3a75fecf-0165-481f-9dfd-0f2959e699ed

【不採択🥺】(レギュラートーク)Laravelのデータベースクエリを最適化するためのヒント

塚原さんの上記LTのロングバージョンという位置付けですね。
発表が終わったらPHPer共通の悩みであるクエリ最適化について、ヒントを元に話が盛り上がりそうですね!

みなさんはデータベースクエリのパフォーマンスを意識して実装されていますでしょうか?
実装した当初は軽快に動いていたアプリケーションもサービスの成長とともに少しずつ遅くなっているかもしれません。あるタイミングで最適化プロジェクトを発足させたり、日々のコードレビューで指摘し合う際に役立つヒントをお届けできればと考えています。

このトークではデータベースクエリ最適化のヒントをサンプルコードを交えて解説いたします!

こんな方におすすめ

業務でLaravelを利用されている方
サービスが成長してきたので、クエリの最適化をしたい人
日頃からパフォーマンスを意識した実装をしたい人

https://fortee.jp/phperkaigi-2022/proposal/b17f350f-8e58-42b2-8276-1021d9769fff

【採択🎉】(LT)PHPスカラー型をクラスでラップして便利に使えるようにするライブラリ「Stannum」を作った話

弊社期待の新メンバー、大石さんによるLTです。 自然発生的に「大石大活躍」などというスタンプが発生するくらい活躍してくれてます。そのレベルの高さが垣間見えるLTですね。

PHPは言語仕様上、stringやintegerといったスカラー型にRubyやPythonのような他の言語のようにメソッドが生えておらず、手続き型のAPIを用いてそれらを操作する必要があります。
しかしながら、メソッドが生えている方が便利な場面もあり「そのように書けたらなあ...」と思う事もあると思います。
これらを達成するのにエクステンションを用いて言語仕様を拡張しスカラー型にメソッドを生やす事も出来ますが、今後の言語仕様の追加や変更に追従しなければならないなどの点を考慮して、純粋なPHPのクラスでスカラー型をラップしてそこに便利に扱う為の関数を生やしたライブラリを作った話をしたいと思います。

https://fortee.jp/phperkaigi-2022/proposal/ee394d8a-b03d-4226-aef1-f512a42ac328

【採択🎉】(LT)【Laravel】サクッとN + 1問題を見つけて倒しチャオ!

津崎さんによる”チャオ”シリーズです。 この言葉がついている時には勢いがすごいLTになるのでは、と期待できますね。楽しみです。

N + 1問題とは、ループ処理の中で都度SQLを実行してしまうことで必要以上にSQLが発行されてしまい処理が遅くなってしまう問題です。
N + 1問題が存在していても、ユーザーに影響のない程度の処理時間なら改修する必要はありません。
しかしながら、データ量が増えたりページへのアクセスが増えることで後から問題になってしまうこともあります。
今回は、そんなN + 1問題をサクッと検出して、問題が発生する前にN + 1問題を撲滅する方法をご紹介します。

https://fortee.jp/phperkaigi-2022/proposal/4307d420-7ef0-4b69-b3f7-005b72bf87b0

【不採択🥺】(レギュラートーク)保守容易性指数とコミット数でバグりやすいファイルを見つけてテストを書こう

同じく津崎さんによるレギュラートーク
めちゃめちゃ実用性高く、面白そうです。これは採択間違いないでしょう。

みなさん、あなたが保守しているコードベースで一番バグが混入しやすいファイルが何か知っていますか?

このトークでは、保守容易性指数(Maintainability Index)とGitHubのコミット数を用いて、
保守性が低くて、よく変更されているファイル(= バグが混入しやすいファイル)を見つけ出す方法についてご紹介します。

https://fortee.jp/phperkaigi-2022/proposal/f675960f-1ed9-4027-b36b-0aaa6263abf0

【不採択🥺】(レギュラートーク)PHPer がスクラムマスターに任命されたら 〜ピンチは突然訪れる〜

弊社の「真のリーダー」であるスクラムマスター濱田さんによるトークです。
皆さんもスクラムマスターに任命されることは”まれによくある”と思いますが、ここでしっかり予習しておきましょう。

先行きの不透明な開発プロジェクト。
鳴り止まない障害アラート。
挙句の果てに、リリースした機能がユーザーにあまり使われていない!
そんな課題を解決すべく、ごく普通の PHPer がある日突然スクラムマスターに任命されて...!?

エンジニアがスクラムマスターに任命される。
まれによくあるイベントです。

このセッションでは、

スクラムとは何か
冒頭で挙げた課題に対して、スクラムではどのように立ち向かうのか
エンジニアとしてどのような能力をスクラムマスターに活かせるか
逆に注意すべきポイントは何か
といった内容を、 PHPer からスクラムマスターに転身した自分の体験を踏まえて紹介します。

https://fortee.jp/phperkaigi-2022/proposal/8c1b5110-7b4c-4c97-a359-66821eb68cee

【不採択🥺】(レギュラートーク)一人のPHPerからプロジェクトマネージャーになる道筋

わたくし鈴木のレギュラートークです。
PM業務に必要なマインドセットとスキルセットについてお話しします。

プロジェクトマネージャー、なりたいですか?

いわゆる「PM」は「プロダクトマネージャー」と「プロジェクトマネージャー」の二つを内包することが多いですが、ここでは後者の「プロジェクト」をマネージする(なんとかする)人についてです。
前者の「プロダクトマネージャー」はPdMなどとも呼ばれ非エンジニアがなることも多いですが、プロジェクトマネージャー(以下PM)はエンジニアが担当することも多いのではないでしょうか。

プロジェクトには数日で終わるものも、数ヶ月かかるものもあるかと思います。最初は単に小さなタスクをこなしていたエンジニアがどうやったらPM(=プロジェクトを"なんとかできる"人)になれる能力がつくのでしょうか?

本セッションではPMの仕事内容と、それに対応するスキルセットの身につけ方についてお話しします。

【注】会社によりPMの職務範囲は変わるので、私の観測範囲内でのお話です

https://fortee.jp/phperkaigi-2022/proposal/5f36f1e1-f065-43e6-babb-3161c5acdb62

【不採択🥺】(レギュラートーク)[Github Dependabot] 「自動作成されたPRだけで脆弱性対策バッチリ」なんて思っていないですよね?

こちらも鈴木によるプローザルです。
セキュリティ領域はセンシティブな情報が多い中、ネタを捻り出しました。

みなさん、脆弱性対策してますか?

コードに潜む脆弱性対応は以下の二つに分類できるかと思います。

自分たちで書いたコードの脆弱性
依存ライブラリ・フレームワークの脆弱性
このうち後者では、Github を使っているならば Dependabot 機能による脆弱性検知が使えます。
Dependabot security updates 機能を有効にしておくと、勝手にPRを出してくれますよね。
便利です。これの内容チェックしてマージするだけ。
めでたしめでたし。

・・・とならないので注意です。
実は、検知していても自動PRになっていない脆弱性があります。
「PRになるのはcriticalレベルのもの。多分そうだろう。」などと勘違いしておりました。
危ない危ない。

本セッションでは Dependabot の説明、注意点、運用方法のケーススタディをお届けします。

https://fortee.jp/phperkaigi-2022/proposal/d922b304-beb8-46c1-8558-9952abe7cb95

【採択🎉】(レギュラートークPHPコードを消すライブラリを作った

「全員インフルエンサー」のバリューの旗振り役、久保田さんによるプロポーザルです。
ええ? PHPで feature toggle で分岐しているのに php-del を使っていない?! いますぐ使った方がいいですよ!
このセッションで予習しておきましょうね。

kubotak-is/php-delというPHPコードをComposer Bin Commandを利用して消すライブラリを作成しました。
特定の形式でコメントを書いておくと、そのコメントを基準にPHPコードを削除します。
なぜそんなライブラリを作ったのか、その実装はどのようになっているのかを紹介します。
このセッションではComposer Bin Commandの作り方や自作のComposerライブラリをpackagistで公開する手順などを学ぶことができます。

https://fortee.jp/phperkaigi-2022/proposal/0efa9d19-aa48-4a3f-898e-7d5ca9c43db6

【不採択🥺】(LT)Composer Bin Commandを作ろう!

こちらも久保田さんによるLT。上のコマンドを作成するときに得られた知見を話してくれそうです。

PHPUnitやPHPStanのようなComposerでインストールしてコマンドで呼び出すライブラリ・アプリケーションの作成方法を紹介したいと思います。

https://fortee.jp/phperkaigi-2022/proposal/f5b99ae5-a4e7-4878-9ebb-382b260a0cf0

終わりに

いかがだったでしょうか?
面白そうと思ってくれたプロポーザルがありましたら、ぜひ清き1票をお願いします。
採択・不採択決定後はぜひ当日をお楽しみに!

スクラムの取り組みをメンバー視点で見る

f:id:kubotak:20220112183348p:plain

こんにちは、こんばんは、kubotak(@kubotak_public)です。

昨年末より弊社では「真のスクラム」という名のスクラム開発を実施しています。
今までは「なんちゃってスクラム」というわけではないんですが、スクラム開発のエッセンスを多少取り入れたような今にして思えば全くスクラム開発ではないなにかをやっていました。

私はスクラムマスターではなく「真のスクラム」を熱く語れるわけではないのでメンバー視点で「真のスクラム」になった結果何が変わったのかを紹介したいと思います。

スプリントが2週間から1週間に

以前は1スプリントを2週間として実行していました。
これを1週間と短くし、月曜日にスプリント計画、金曜日にスプリントレビューとレトロスペクティブを行うように変わりました。
私個人としては短くなったことで単純に忙しないな!と思うのと、開発時間の多くは火・水・木曜日になり余計に短いと感じます。
また、短くなったことで以前に比べるとスプリント全体で完了する成果物の大きさが小さく・細かくなりました。
小さいサイクルを回してすぐに出すことでよりアジャイルな開発になったのかなと思います。

スプリント計画をメンバー全員で実施

以前はPO及び一部のメンバーでスプリント計画を実施し、タスクのポイントなどをつけていました。
これを全員で実施するように変更しました。
プランニングポーカーを用いてデザイナー含めたスクラムメンバー全員でタスクに対するポイントを出し合い、合議により見積もりを行っています。
これによりメンバー全員が個別のタスクの詳細を理解することができ、誰がタスクにアサインされても問題ない状態になりました。
もちろんタスク毎に向き不向き、得意不得意があるかもしれませんが全員で見積もり行うことで平均化されますし、そのタスクに必要な情報の詳細を持っている人が明確になるので聞きに行くということも可能になります。

今までは一部のメンバーしか情報を共有できていなかった部分も、透明性が上がったといえると思います。

タスクにユーザーストーリーとACを追加

タスクにはユーザーストーリーが追加され、なぜ、誰のためにその実装が必要なのかを明文化しました。
また、ユーザーストーリーとともにAC(acceptance criteria)も追加し、そのタスクはどういう状態であればユーザーストーリーが完了になるかも明文化されました。

この2つは作業者としては非常に重要で、「なぜわたしたちはこのプロダクトを作っているのか」が明確化されて納得感を持ってタスクに取り組めます。
また、何を持ってこれは完成と言えるのかも記載されているので品質の担保ができます。
そしてこれは自動テストのストーリーとしても役立っています。

DoD(完了の定義)はタスク毎ではなく全体の完了の定義としているため、ここではACを取り上げています。(完了と受け入れ基準の定義 Definition of Done vs Acceptance Criteria

スプリントレビューを実施

PO以外にも、タスクにおけるユーザーストーリーから影響がある人を呼んでそのスプリントで完成したプロダクトを見たり触ったりしてもらうような時間を作りました。
このとき、「顧客が本当に欲しかったもの」やその顧客に近いCSの声などをフィードバックとしてもらうことができるようになりました。

これにより、「私達が作っていたものは間違っていなかったんだ」という自信を持った上でリリースに挑むことができます。
もちろん実際にはデータを元にその追加機能の優劣は後から判明することとは思いますが、少なくとも「この機能使われないのでは?ほんとに喜ばれるのか?」という不安を払拭し、モチベーション高く開発に挑める良い施策だと思っています。

まとめ

細かい話などはおそらくスクラムマスターから今後紹介されることと思いますが、現在スクラムメンバーとしてスクラム開発を実施して良いなと思った点をあげてみました。
正直最初は新しい用語や取り組みによってやや混乱を覚え「これホントに良い開発できるのか?」と思いましたが初回のスプリントレビューで払拭された感じがします。
スクラム開発によって顧客に向き合った開発ができるようになったんだと実感しています。

さいごに

まだまだスクラム開発駆け出しの弊社ですが、もっと改善したい、一緒にスクラム開発したい、と思った方はぜひ応募ください。
ちなみに、データエンジニアや機械学習エンジニアも積極採用中ですのでお声がけください。

www.wantedly.com

2022年 新年のご挨拶

f:id:kazuhei0108:20220104091310j:plain

あけましておめでとうございます。

M&AクラウドでCTOをしている荒井です。

年末はPythonのFastAPIというフレームワークをいじっていました。APIドキュメントの自動生成機能がついていて画期的なので、どこかで使いたいなあ。

fastapi.tiangolo.com

昨年は大型の資金調達もあり、チームメンバーも増え、とてもにぎやかな1年になりました。

去年末から弊社開発チームは、スクラムの原点に立ち返り、エンジニアだけではなくPOとデザイナーも含むスクラムチームを組成して再出発しました。

せっかくですので、今年からはこのテックブログもエンジニアの枠にとらわれずに、スクラムチーム全体で記事を書いて行けたらと考えております。

それでは本年もよろしくお願いいたします。

記事をお楽しみに!