PHPコードを消すライブラリを作った

f:id:kubotak:20211207104943p:plain この記事はQiita AdventCalendar 2021 PHPの8日目の記事です。

こんにちは、こんばんわ、kubotak(@kubotak_public)です。
早速ですがタイトルの通り「PHPコードを消すライブラリ」を作りました。

packagist.org

まずはこのライブラリの生まれた背景と用途について説明します。もしよければstarつけてください。

これはなに?

以下のようにコメントでコードを挟み、composerで導入したコマンドを実行することで対象のコードを削除します。

before

public function code() {
    /** php-del start flag-a */
    $something = 1;
    /** php-del end flag-a */
}

run command

vendor/bin/php-del flag-a

after

public function code() {
}

なぜ作ったのか?

使い方は簡単ですね。しかしこんな仕組み、いつ使うんでしょうか?
話が変わってしまうんですが、弊社ではスクラム開発を行っており、Feature Flag(Toggle)を利用してデプロイとリリースを分離しています。
変更影響があるコードはFeature Flagによって管理され、それがONになることで有効化するようになっています。

(イメージ)

if ($featureFlag) {
  // 新しい処理
  return;
}
// 既存の処理

※弊社のFeature Flagについては過去記事を参照ください
Feature toggles を複数の環境へ即時反映する仕組みを開発しました - M&Aクラウド開発者ブログ

察しの良い方はすでにお気づきかと思います。
このコード、Feature FlagをONにした後はif文及び既存の処理は不要になります。
今まではこれを消すタスクを積んで消す必要がありました。
また、このコードを追加していない開発者が見た場合、どのコードを消すべきかちゃんとコードを読み解く必要もあります。

ほしいもの

つまり、Feature Flagを使うコードを実装する時点で、消すことも想定してコードを書いておいて、後から自動で消えてしまえば負担が少ないのではないか・・・
という思いから出来上がったのがこのphp-delです。

先程のコードに適応すると次のようになります。

/** php-del start flag */
if ($featureFlag) {
/** php-del ignore start */
  // 新しい処理
/** php-del ignore end */
  return;
}
/** php-del end flag */
// 既存の処理

※ignoreコメントで挟んだ箇所は削除対象から除外されるので残ります。

弊社以外にも需要があれば是非どうぞ、ということでOSSとして公開しています。

さいごに

今回OSSとしてComposerで配信するコマンドを作ってみて、次のようなことを感じました。

需要は自分たちだけのものでも良い

誰もが喜ぶライブラリじゃなくても、自分たちのニーズに答えられるものなら開発意欲も湧いて良いなと思いました。

他のOSSコードを読むようになる

他のOSSはこの処理どうやって実装してるんだろう?という疑問からPHPUnitやPHPStanなどの実装をチラ見したりしました。
普段あんまり見に行かないコードなのでそういうものに触れる機会にもなって良いと思います。
composer.jsonのbinに追加するだけでvendor/binに配置される仕組みめっちゃ良いです。

少しでもいいな、と思ったらぜひstarつけてください。

【離職率0%】弊社エンジニアが辞めない理由とは【スタートアップ】

f:id:yamotuki:20211129183843p:plain

(これはM&Aクラウド Advent Calendar 2021の12/3の記事です)

こんにちは。M&Aクラウドのエンジニアの鈴木です。ネット上では@yamotukiという名前で活動しています。

「エンジニアといえば転職してキャリアアップ」「キャリアアップといえばエンジニア」(要出典)などと言われる昨今ではありますが、弊社は7期目にして奇跡的にもまだエンジニアが離職していません。

その奇跡はどこから来るのか?
同僚のエンジニア達にヒアリングをして、起源を突き止めたいと思います。

【仮説】エンジニアはいつ離職を考えるのだろう?

エンジニアが離職を考える時期として、以下のような年次と理由があるかなと思っています。これは完全に主観です。以下のようなものに当てはまらなければ、特段辞める理由は無いのではと仮説を立てました。

  • 1年
    • そもそも職場にマッチしてなかった。「思っていたんと違う」
    • 労働条件が言われたのと違う。「ブラックじゃん?」
  • 2年
    • ジョブホッパー的な気質の場合には2年もやると転職を考える頃。「経験を積んだので昇給すると思っていたのにしなかった。」
    • 苦手なタイプの同僚が増えた。「あいつ嫌い」
  • 3年
    • 仕事に飽きてきた。「チャレンジさせてもらえない」
    • 技術スタックの固定化。「いつもおんなじ技術使ってるわ」(2年目でも言えるかも。まあ理由は二つずつくらいが収まりがいいのでこちらへ)
  • 4年
    • 求められる役割が増えた。「マネージメントなんてやりたくないよ」
    • 色々できるが故に仕事がたくさん降って来すぎる。「マジで忙しい」

さて、実際に聞いてみたらどんな感じでしょう?

ヒアリングしてみた

同僚たちをそれぞれ slack の huddle で突然呼び出して、ざっくばらんに理由を聞いてみました。
弊社には1年目から4年目のエンジニア社員が居るので、年次が浅い方から聞いていきましょう。(※CTOは現在は入社5年目かと思いますが、エンジニア職から離れておりPdMとして活躍しているので今回スコープから外しました。またサービスが2018年5月に開始してからまだ3年半ほどしか経っていないので、実質4年目が最長です。)

1年目

國村さん(入社2ヶ月と10日)

――「入ったばかりではありますが、辞めないで続けている理由ってどんなのがありますか? まずは雑な質問から。」

國村「入ってみて、みんないい意味で真面目だな、と思いました。タスクを終わらせることに真面目に取り組んでいて、課題を解決しようという姿勢が整っている。それがいいなと思ってます。特にみんなチーム一体になってタスクを終わらせようという姿勢が良い。」
國村「あとは事業として可能性がある未開拓領域を掘り進めて開拓しているところですかね。」

――「なるほど。入社直後に辞めたくなる理由があるとしたらミスマッチだと思いますが、それはどうですか?」

國村「特になかったです。」

――「それはなんでだと思います?」

國村「面接で色々聞けたから。逆に、荒井さん(※CTO)に結構きっちり聞かれたと感じました。だからミスマッチしないのかなと。」
國村「あとは内定が決まった後のアトラクト会でチームの空気感を掴みました。それが入社の決め手でした。そこで感じたチームの雰囲気と、入ってみたあとで変わらなかったです。」

仮説にあった「思っていたんと違う」はなかったようです。

塚原さん(入社8ヶ月)

――「とりあえず大きな質問からするのですが、続けている理由ってどんなのがありますか?」

塚原「メンバーに受け入れてもらって、ここでも仕事できるという手応えを感じています。」
塚原「転職の目的だったスキルアップとしては、最初に比べて結構できるようになったので目的は達成しているかなと。高いレベルを求められるし、社内のエンジニアのレベルが高いので刺激的です。」

――「入社前と後でミスマッチとかありました?」

塚原「スキル面で言うと、入社前に荒井さんからは『入ってから頑張ってキャッチアップしてほしい。今の実力のままだと大変なので頑張れ』と言われていました。そう言う意味ではギャップはないです。」
塚原「あと、人間関係の面で言うと、雰囲気良く受け入れてもらったと思ってます。この前エンジニア飲み会(※塚原さん主催による塚原さん&國村さん歓迎会)も開けたので、楽しくやってます。ただ、私は気にしいなので、自分はミスマッチを感じていないが、周りがどう思っているかは心配ではありますね。」

――「なるほど。私はミスマッチなかったと思いますよ。人間関係面で言うと完全に馴染んでいると思います。スキル面で言うと、今は開発総合窓口対応やアラート一時受けなどやってもらってますよね。最初は結構頻度高く私も見に行かないといけない感覚だったけど、今は見る頻度減ってきてます。それはちゃんとやってもらっているという安心感を感じているからだと思います。」

塚原「逆質問なのですが、タスク振っている側(鈴木側)として何か考えていることってあったりします?」

――「明示的にそこまで考えているわけではないけど、特定分野の仕事でめっちゃ詰まっていて、終わった後にメンタル落ちているかなーと思ったりすると、同種の仕事を一時的に振らないでコンフォートゾーンの活躍してもらえる仕事を振っているかもしれないです。」

塚原「なるほど。そういうのも離職率減っている理由かもしれないですね。実はインフラ系タスクとか、フロントエンドのタスクとか難しくて辛い時期があったので。その時は、自分が活躍できず、進んでいる感がなかったです。」

塚原さんについても、仮説にあった「思っていたんと違う」はなかったようです。
逆に求められる水準が高すぎても辛くなってしまうので、塩梅は大事だなと感じました。  

2年目

濱田さん(入社1年と9ヶ月)

――「辞めないで続けている理由って何がありますかね? 最初に思いつくもので。」

濱田「飽きてないから。ですかね。直近だとスクラムマスターやるという話とか。単にコード書くだけで既存の保守だけだと成長が止まってしまう。今の環境だと課題が新たに見つかって改善していこうというサイクルがあるので飽きないですね。転職して改めて成長機会を探す必要がないです。」

――「課題がでてくる、というのはやはりスタートアップだから、とか会社が成長しているからというのはありますかね?」

濱田「そうですね。前職の大手プロバイダだと、事業内容の関心ごとがほとんど変わらないというのがありました。大きく成長していないので目指すべき目標がそんなに変わらないというか。」
濱田「新しい役割で言うと、他にはサブチームリーダーとかファシリテーターとか役割を新たに任せてもらってますね。成長環境として、役割を通してや生産性向上委員会(※実質的なリーダー会)の中で自分にフィードバックがあり『自分の中でどういう課題があるか』というのを意識する機会になってます。」

仮説にあった3年目の「チャレンジさせてもらえない」がないというのが良さそうです。濱田さんはまだ2年目ですが、3年目を超える古参の風格を漂わせています。

3年目

久保田さん(入社2年0ヶ月)

――「ざっくりとした質問なのですが、辞めないで続けている理由って何がありますか?」

久保田「僕は多分特殊ですね。いつ辞めるか入る時に考えてます。前職もそうでした。」

――「時期で決めているってことですか?」

久保田「IPOしてから転職は考えたいんです。IPO無理だとなったら考えるかもしれないけど。IPOに至るまでのチームの変わっていく姿とか技術スタックが変わっていく姿とか、それに技術的適材適所を見極める経験をしたい。そうすると次に行っても再現性のあるスキルが手に入るかなと。」

――「IPOしたらすぐなのか、ベスティング(※ストックオプションから生株変換までの期間)の間は残るのか。」

久保田「その後の世界が重要かどうか、は自分は知らない。その時のことがわかっていないのでまだ分からないです。経営は多角化していくとかしていけば、そのフェーズで僕が必要なのかわからないですね。」
久保田「SOがどれくらいとかあんまり気にしていないですね。あったらあったで嬉しい。それは居る居ないに関わっていないです。一応期待していない。上場後に(株転換で)毎年1000万入ってくるとかだったらちょっと居てみるかーとはなるかも。」

――「経験したいと言うのが強そう?」

久保田「そうですね。僕自身の成長としては、自分は努力していない気がしてます。人の成長は環境次第だと思っていて、僕自身が努力家ではない。やらなきゃいけない環境とか、やらなければいけない環境で成長を促そうというところです。前職にずっといたらダメ人間になっていた。」  

――「楽すぎて?」

久保田「ずっと変わらない繰り返しに入ったというのと、周りに学ぶ人が減った。僕よりできる人というのが周りを見渡すとあんまりいなくなってしまった。」
久保田「今は会社自体が足掻いている。それに合わせて自分も足掻いていく。それで成長していく。今スクラムを真面目に取り入れようとしているのもいい流れ。」

――「スクラムのいいところが自然に身についていく?」

久保田「スクラムに悪いところがあるかはまだわからないですが。上手くいくように濱田さん主体でやっているが、我々も働きかけていく。それが学びになると思いますね。」  

――「周りが求めてくれることをやれば良い?」

久保田「不得意分野はあるし、やりたくないところはある。そういうものを無理矢理やることになれば話が違うよってなる。例えば荒井さんのCTOの立ち振る舞いとか、それは自分には難しい。」

「いつもおんなじ技術使ってるわ」はなさそうでした。久保田さんは、大きな流れに身を任せて自分も成長しよう、というタイプですが、そういう人はスタートアップにマッチしてそうです。

津崎さん(入社2年6ヶ月)

――「辞めないで続けている理由ってなんでしょう? あえてざっくりした質問なのですが。」

津崎「ひとつじゃなくていいですか?」

――「もちろん」

津崎「まだ上場に向かってやっているので、その上場した時の景色をみたいです。」
津崎「あとは、学ぶこともまだあります。データ分析とか大臣制度でチャレンジできる余地が残されているので。」
津崎「停滞感が長く続くと辞めたくなると思います。今は事業も爆発的な成長はないけど、堅実に成長はしている。エンジニアチームの仲間が1人辞めます、2人辞めますというのが増えたら『ぐぬぬ』ってなると思います。むしろ人が減ってやること増えるので辞めてる場合じゃないんでしょうけど。」

――「停滞感を感じている時期はありましたよね?」  

津崎「入社してからはあんまり感じてないです。けど、SKE2(※募集と検索周りのリニューアルプロジェクト。4ヶ月。)の長いトンネルの中にいる時には思ってました。憂鬱に思ってましたね。」

――「今の定常保守だと思っていない?」

津崎「普通ですね。来期が始まるし、スクラムも始まるしという期待感があります。」

――「変わらないというのが辛い?」

津崎「そうかもしれないですね。個人的にはすごく飽き性なので。入社したばかりだと、『新しい新しい』ってなるけど、時間が経つと慣れてしまって刺激が減ったように感じます」

以降、停滞感を感じないために”自分の中のあるべき姿”に向かってどうやったら進んでいけるのだろう?とお悩み相談になりました。
任された仕事を着実に自分のものにして、また次の新しい仕事を任せてもらうループを作ると、停滞感を感じている暇などないのでは無いか、という仮説を鈴木は持ちました。
津崎さんは”あるべき姿”に向かうために自分に定期リマインダをかけたり、付箋を貼ったり工夫はしているけど、「すぐ脳内から消去されてしまう」というのを悩んでいました。機械がやる自動リマインダは無視されがちですね。
津崎さんから"鈴木へ対して"自動定期リマインダをかけることで鈴木が人力チェックと人力リマインダをすることになりました。

こういう話をする機会大事ですね。

4年目

鈴木(入社3年3ヶ月)

セルフインタビューです。私が続けている理由ってなんでしょう?

  • スキル面ではまだやれることがあると思っている
    • リーダー業務やPM業務をやってみているが、まだ完全にうまくできるようになったとは思っていない。また別の会社に行って0からドメイン知識を得て学んでいくのだと効率が悪い
    • 設計のスキルは、自分が考えた設計が長期保守に耐えられるかという視点で同じコードを保守し続けた方がスキルが上がると思っている。時間によるフィードバックを受け取りたい
    • 弊社で身につけられないスキルは、数百万単位のアクセスあるような高トラフィック環境における実務だと思っているが、それは今は自分が必要としていない。また、インフラについては既に前職である程度やったので必要ない。 
  • 金銭面では、SOを持っていて、給料の高い他社に転職するよりまだ残ったほうが期待値が高いと思っている

仮説との対応でいうと、求められる役割が増えた。「マネージメントなんてやりたくないよ」が別に問題になっていないパターンですね。

終わりに

なかなか面白いヒアリング結果でした。

入社から間も無いエンジニアに対しては、入社でのフィルタや期待値調整がうまくいっており、ミスマッチが少ないのが良いポイントかと思いました。面接した人のうち内定までの倍率が10倍を超える(※ぼかします。許可が取れたら書き換えます。)と言われている弊社エンジニア採用はうまくいっているようです。

入社年度にかかわらず、弊社のエンジニアは変化に強いというより「変化が無いと死んじゃう」泳ぎ続けるタイプが多いかもしれないなと感じました。
それぞれが活躍できるタスクを割り振りつつ、一段難しいタスクも捌けるように成長してもらう。そういう職場作りが肝要ですね。

インタビュー見て「同じような志向を持っているなあ」と思ったそこのあなた。多分弊社とマッチしていると思うのでぜひカジュアル面談からいかがでしょうか。CTOでもいいですし、他のメンバーとカジュアル面談したいと指名してもらっても良いかと思います。

www.wantedly.com

おまけ: 入社理由については以下の記事にまとまっています。ぜひ合わせてご覧ください。

update.macloud.jp

アドベントカレンダーを成功させるためのDX

f:id:kubotak:20211203133527p:plain この記事はM&Aクラウドアドベントカレンダー2021の記念すべき1日目の記事です。

みなさんこんにちはこんばんは、M&AクラウドでWebエンジニアをしている久保田(@kubotak_public)です。

M&Aクラウドとしての初めてのアドベントカレンダーです。
詳しくは以下の記事を見ていただけると嬉しいです。

update.macloud.jp

さて、今回弊社のアドベントカレンダーを行うにあたって私が実行委員として旗振り役となりました。
今年のアドベントカレンダーの目標はズバリ、「だれも記事を落とさずに公開すること」です。
簡単かな?とも思われる目標ですが、今回のアドベントカレンダーを担当するメンバーはWebエンジニアだけではありません。
つまり「アドベントカレンダー?なにそれ?」と馴染みのない方も多いと思われます。

Webエンジニアであれば12月には「記事書かなきゃ」とソワソワすることが多いのではないでしょうか。
ということで、実行委員としてみんなに”ソワソワ”してもらうためのリマインダーを作りました。

f:id:kubotak:20211128230650p:plain

このような形で公開の3営業日前にSlackで担当者あてに通知が行われます。 今流行のNoCode、と言いたいところですが一部JavaScriptを利用しています。

アーキテクチャは次のようになっています。

f:id:kubotak:20211128232644p:plain
アーキテクチャ

①zapier

タスク自動化ツールであるzapierを利用して定期実行を作成します。
zapierではあらゆるサービスの連携だけでなく、プログラミングコード(Python, JavaScript)を実行させることができます。

Googleスプレッドシート

Googleスプレッドシートにはアドベントカレンダーの記事を書く担当者名やSlackメンション用のユーザーID、担当日などを管理します。
f:id:kubotak:20211128233245p:plain

zapierではまずこのスプレッドシートのデータを読み出します。

JavaScript

続いてCode by Zapierを利用してJavaScriptを実行します。
先程のスプレッドシートのデータを加工しつつ、実行したタイミングから3営業日後の担当者を抽出する処理を作ります。
ここで気をつけなければならないのは休日の扱いです。
アドベントカレンダーには休日も関係なく記事を公開する必要があります。ですが、例えば休日に3日後の通知を送るというのは些か会社としてよろしくないですよね?
ということで通知が行われるのは平日のみに限定し、3営業日前通知ということに設定したいので土日を挟むことを考慮した通知設計が必要です。
幸い(?)にも12月は祝日がありません。祝日を考慮する必要がないので簡単に次のようなルールで通知を設計しました。

const scheduleList = [
    [], // 日曜日 -> 通知なし
    [3], // 月曜日 -> 木曜日
    [3], // 火曜日 -> 金曜日
    [3, 4, 5], // 水曜日 -> 土・日・月曜日
    [5], // 木曜日 -> 火曜日
    [5], // 金曜日 -> 水曜日
    [], // 土曜日 -> 通知なし
];

scheduleListの配列内の数値は、実行した日付に加算する日付を表しています。ですので、コメントに付いているように月曜に実行された場合は3日後の木曜の担当に通知、水曜に実行された場合は3日後、4日後、5日後のそれぞれ土、日、月曜の担当に通知を送る設計です。

スプレッドシートとCode by Zapierの落とし穴

この実装を作っているときにちょっとした落とし穴がありました。
zapierで取得したスプレッドシートの行は、JavaScriptで配列として受け取れると思ってましたが文字列で取得されました。
カンマ区切りの文字列なのでCSVとしてパースできるのかな?と思ったんですが改行コードがなかったので仕方なく列のサイズで別配列になるようにパースしました。

const { rows } = inputData;
const rowsToArray = rows.split(',');
const rowsFormatted = [];
let i = 0;
let row = [];
rowsToArray.forEach((item) => {
    ++i;
    row.push(item)
    if (i > 8) {
        rowsFormatted.push(row);
        row = [];
        i = 0;
        return;
    }
}); 

④Slack

JavaScriptの処理が実行されると次のようなデータが生成されます。

output = [{ result: true, message }]

通知する内容がある場合はresultがtrueとなり、ない場合(土日や開始日前や終了後)はfalseとなります。
Filter by Zapierを利用して後続のタスクを実行するかどうかを分岐させます。

最後にSlackへの通知を実行することで一連の処理が完了します。

さいごに

今年のM&Aクラウドアドベントカレンダーのテーマは「テック」です。
実行委員として「テックを利用してアドベントカレンダーの旗振りを行う」を実践できたのではないかと思います。
本日を皮切りに25日まで、弊社エンジニアのみならずあらゆる業種の面々が記事を投稿します!ぜひご期待ください。

PHPerKaigi 2022のプラチナスポンサーになりました

f:id:kazuhei0108:20211119105044p:plain

こんにちは、M&AクラウドCTOのかずへいです。 この度、弊社ではPHPerKaigi 2022のプラチナスポンサーをさせていただくことになりました。

毎年弊社のメンバーの多くが参加しているPHPerKaigiさんのスポンサーをさせていただけること、ありがたいです。

前回のPHPerKaigi 2021では弊社から5名登壇させていただきました。

去年の弊社メンバーの登壇内容についてはこちらをご覧ください。 tech.macloud.jp

今回は、弊社でスポンサーさせていただくとともに、また、メンバーみんなでプロポーザルを出していく所存ですので、 何卒宜しくお願いいたします。

また、登壇スケジュール等決まりましたら、こちらのブログでお伝えさせていただければと思います。

ファシリテーター & 議事録係の型

f:id:hamakou108:20211105144923j:plain

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

弊社の開発チームでは特定の役割をうまく果たすための知見を「型」として文書化し、チーム内で共有しています。

tech.macloud.jp

tech.macloud.jp

今回はその一つである「ファシリテーター & 議事録係の型」を紹介します。

弊社の開発チームでは週に1回、加えて隔週に1回のタイミングで定例ミーティングが開催され、ファシリテーターはエンジニアが担当しています。 ファシリテーターを担当したことがある方であれば、会議の中で様々な問題に直面することは想像に難くないと思います。 議論するのに十分な情報が事前に収集されていない、議論が発散し続けて結論が得られない、会議後に誰がいつまでに何をすべきなのか記録されていない、などなど。

弊社の開発チームではこういった問題に対する解決策の一つとして、ファシリテーターが議事録係を兼ねるという取り組みを実践しています。 その戦略の意図と狙っている効果、またファシリテーターと議事録係のそれぞれの役割において望まれる振る舞いについて「型」を通して紹介できればと思います。


これは何

開発チームにおいて会議を回すファシリテーターと主書記は同じ人がセットでやることになっている。 会議をスムーズに進行し、有用なものとするために何をしたら良いかの型を模索するための資料。

前提説明: ファシリテーターと主書記について

主書記とサブの役割について

議事録係には主書記と、サポートするサブがいる。 それぞれの役割は以下の通り。

  • 主書記
  • サブ
    • 主書記が書かなかった(書けなかった)議論や情報の細部を書いていく人

議事録係を分割した理由

議事録係(ファシリテーターと分離されている「全ての記録を残す」役割)は難しい。 何が難しいか。

  • 議事録のリアルタイム性が重視されているので、会議の議論に遅れずについていかなければいけない
  • 全ての発言を書くのは現実的ではないので、話していることを正しく要約する必要がある
  • 上記のため、議事録係は積極的に議論を止め、話している方向を確認し、要約や結論を促す必要がある

この役割を果たすにあたって、ファシリテーターと議事録係が別だと以下のような不都合が起こる。

  • ファシリテーターが話していることと議事録係が書いていることの間でニュアンスがズレることがあるので、補正が必要
  • ファシリテーターと会議全体が暴走すると議事録係がついていけない

議事録係を専任でやるのは、会議をファシリテーター同様にコントロールすることと、記録を残すことの両方をやる必要があり、高いスキルが要求される

ファシリテーターと主書記を同じ人がやるメリット・デメリット

  • メリット
    • 会議の骨格を作っている人と、骨格を書いている人が一緒なのでニュアンスがずれない
    • 議論の内容を要約しながら進めるので、ファシリテーター自身が会議の方向性を自覚しやすい
    • 言葉で説明され、要約を文字で読めるのでメンバーが話について行きやすい
    • 上記のことから、会議が暴走しずらいことを期待する
  • デメリット

将来的な話

将来的には、ファシリーテータ & 議事録係のセットで経験を積んだら、議事録係単体でも上記の難しさを乗り越えるスキルが付くはずなので分離しても良い。

一番重要なこと

参加者の時間を使っていることを意識する

会議の参加者が多ければ多いほど、その出席者の時間を有効に使うことが求められる。

その会議をやることで、やらないよりチームにリターンがある場合に開催すること。 リターンがなければ解体する。

会議の目的をはっきりさせる

会議が何を目的にしているかはっきりさせる。 複数の目的が含まれている場合、必要に応じて会議を分離する。

誰を呼ぶか

会議の目的に合わせて過不足ない人を呼ぶ。

事前準備

誰も何も考えていない、または決めていない時間は無駄な時間となってしまうので、事前準備が大事。 誰の持ち込みの議題で、何を相談したいかはっきりさせてから会議に臨むのが望ましい。

ファシリテーターの仕事は参加者にこれを促し、やってもらうこと。 必要に応じてチャットツール上であらかじめ議事録を共有し、必要な内容を書いてもらえるようにメンバーに促す。

議題が用意されたら、会議内で議論する必要があるポイントを整理し、それ以外を会議の外に持っていく。

  • 議題の起案者に論点を明確にしてもらう
    • 場合によってはたたき台を用意してもらう
  • 一部の関係者のみでチャットや会話で議論し、結論だけ持ってきてもらう

議論する内容が定まったら、優先度に応じて議題の順序と目標時間を整理し、会議のゴールを設定しておく。

進行

会議のゴールを共有する

会議のゴールを参加者全員がわかるように共有する。 定例などでも、たまに忘れ去られてそうだったら改めて共有する。

また議題の順序と目標時間を共有し、参加者に議論を時間内に収めてもらうよう促す。

まず情報を集める

情報を持っている人を明確にして、ヒアリングをする。 会議の参加者が同じ前提の情報を持って話せるように議事録に落とし込む。

意見を募る

たたき台があればそれを使う。 なければ雑でもいいので自分で捻り出す。たたき台もないとみんなが発言しづらいので、自分の案が 💩 だと思っても何か出す。

情報を持ってそう or ちゃんと考えてそうなのに話していない人がいたら話をふる。 うまく参加できていない人がいたら、突然のボールでもあえて振ってみるのもいいかもしれない。 その後会議に積極的になってくれたらもうけもの。

今は何の時間か?

ファシリテーターは今何の時間なのか明確に発言し、遊びの時間を減らす。 察してもらえるだろう、というレベルのものも明確にする方が良い。

たとえば

  • 「画面共有しますね」みたいな数秒で終わる発言
  • 「この資料を見て〇〇をする時間です。✖️✖️分までです」
  • 「〜〜の立場として△△さんの意見を聞いてもいいですか?」

着地点を探す

情報や意見が集まったら着地点を探す。 結論は明記しておく。

結論の書き方はフォーマットは自由だが、チームとして共通認識のある表現にする。 「誰が、何を、いつまでに」の3点が要素として含まれていると望ましい。

  • 結論: 〜〜 みたいな書き方で明記しておく
  • (これは弊社の開発チームのみで定着している)議論の過程でこれが結論になったというところを太文字にしておく

時間内に収まらないような長い議論の場合でも、中間地点として方向性が決まることもあるので「中間結論」を明記できると良い。 次の会議に議題を持ち越す場合は、以下の点を明確にしておく

  • 今回は何が決定されたか(中間結論)
  • 次回は何を決定するか
  • 次回までに何をする必要があるか(宿題)

会議の結論と宿題を共有する

会議の終わりに、出た結論を振り返り、本当にその結論でよかったのか確認する。

次に「誰が、何を、いつまでに」する必要があるかを共有する。 次のアクションが決まっていないものをはっきりさせる。

議論が白熱すると共有のための時間がなくなる可能性があるので、ファシリテーターは余裕を持って時間管理をしておく。

議事録

意識

ミスタイプを恐れない。 会議を進めることを重視する。 サブがサポートする。 

役割

ファシリテーターが議論の骨格を書く。 得たい結論の方向性から逆算して、大まかな話を誘導し、議事録係としてリアルタイムに反映させる。 他のメンバーが同時編集できる一つの議事録を見て現在地点がわかるのが理想。 例えば esa であれば編集モードでカーソル位置がわかるので、より明確にどこを見ているかわかる。編集モードでみんなが編集、閲覧するのを促す。

議論が明後日の方向に行ってしまったり、ファシリテーターを置き去りにして進んでしまう場合には、一旦止めて「こういう話ですよね?」がはっきりするまでメンバーを待たせる。

発言者について

同じ職種や近い情報を持っている人のみの会や、意思決定者で無い人の発言は匿名発言として名前を書くことは強制されない。

全て書いてもいいが、慣れていないと大変なので必要なポイントに絞るのも良い。 以下のパターンで名前を明記しておくと良い。

  • それぞれの意見を順番に聞いたパターン
  • 役職として決定権がある人の結論
    • 最終的に議論が割れたケースで、決定者がえいやと決めた場合に、後から振り返ってなぜそうなったか分からないケースがあるため
      • ただし、決定権がある人が決めたとしても、理由も無しに決めたわけでは無いはずなのでちゃんと理由を明記しておく。理由がなかったらメンバーは納得できていないことが常なので、それを積極的に聞いて議事録に残す。

終わった後の処理

会議の後に議事録は必要に応じて整形する。 次のアクションとして振り分けたタスクが進むように改めて通知したり、自分で作業したりする。

  • Try ボード 1 に積む
  • issue を作る
  • 調査する
  • 次週までに決めておく

伝える

議事録を整形し終わったら、宿題をまとめてそれぞれの担当者に通知する。

次の会議でやること

前回の会議で決まったもので、置き去りになっているアクションをはっきりさせて、アクションを促す。


おわりに

エンジニア、デザイナー積極募集中です! ぜひカジュアルにご応募ください!

www.wantedly.com

www.wantedly.com

www.wantedly.com


  1. 弊社の開発チームでは KPT で言うところの TRY をかんばんボードで管理しており、それを Try ボードと呼んでいます。

第三回Nuxt道場のお知らせ

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

以前よりご愛顧いただいてますNuxt道場の第三回の開催のお知らせです。

macloud.connpass.com

2021/11/25(木)19:30 〜 Youtube Liveで配信予定です。
Nuxt 3 betaが発表されましたので今後のNuxtについて触れていきたいと思います。
第三回改、第参面では株式会社ROXXのCTO松本宏太さん(kotamat | ROXX CTO (@kotamats) | Twitter)が師範(スピーカー)として登壇予定です。
ぜひconnpassのページよりご参加ください。

疑問質問感想はSlackに!

そして今回よりSlackを用意したので疑問質問感想等、コミュケーションツールとして活用したいと思います。
以下のURLよりご参加ください!
https://join.slack.com/t/web--dojo/shared_invite/zt-xpkiborm-MsP~7B46ztcDnS~lhw24vA


また、登壇や道場破りのご参加も随時受け付けています!
登壇は@kubotak_publicまでご連絡いただければと思います!

Nuxt.jsアドベントカレンダー

お知らせ続きとなりますがNuxt関連といたしまして、Nuxt.jsのアドベントカレンダーも作成しましたのでそちらもぜひご参加ください!

qiita.com

アドベントカレンダーの季節になると、今年もあと僅かという感じがしてきましたがNuxtをまだまだ盛り上げていきましょう!

DXつらみ報告と生産性向上の取り組み

f:id:zacky2:20211027175401j:plain
もつ鍋

こんにちは、エンジニアの津崎です。

お鍋が恋しい季節がやってまいりました。 鍋料理は基本的に切って煮るだけなので、作る手間がかからなくて最高ですよね。 作る手間がかからないということはいいことです。 そういうわけで今回は、システムの作る手間を減らす、生産性向上についてのお話になります。 ちなみに僕は、もつ鍋が好きです。

M&Aクラウドでの生産性向上の取り組み

チームとしての生産性向上

M&Aクラウドのエンジニアチームでは、チームとしてタスクの消費スピードを上げることを目指しています。 タスクの消費スピードを上げる方法として、エンジニア採用とチームの生産性向上に取り組んでいます。 消費スピードは、タスクにストーリーポイントという作業の重さを数値化した値を割り当て、スプリントの内で消費したストーリーポイントを計測しています。

仕組みチームと技術チーム

生産性向上の試みは二つのチームに分かれて進めています。

一つ目は仕組みチームです。仕組みチームでは、開発の進め方やチーム分割といった仕事のやりかたを変更することで生産性向上を図っています。 これまでに、「プルリク400行ルール」や「タスクの一個流し方式」といった試みを行い、実際に効果が現れ始めています。

以下も、仕組みチームの取り組みの一つです。 tech.macloud.jp

二つ目は技術チームです。技術チームでは、新しい技術や試していない技術を導入したり、開発に関わる技術(リリーススクリプトやローカル開発環境など)の改善を行うことで生産性の向上を図っています。

技術チームネタ切れ問題

チーム発足当初は、今までに溜まっていた不満やアイデアなどから、いくつか生産性向上のための施策を提案することができました。 これまでに、コードレビュー自動化ツール「Sider」の導入や「CIでのテスト並列化」などを試してきました。 しかし、アイデアの多くは、対応コストとリターンが見合わず、エンジニア組織で掲げているレバレッジ指向に合わないために対応を見送られました。 次第に生産性向上のためのアイデア出しに苦しむようになりました。 そこで、実際に他のエンジニアにも開発上のストレスポイントを意見してもらうことで生産性向上のアイデア出しに活かす方法を試すことにしました。

DXつらみ報告

「DXつらみ報告」は、日々の業務の中で開発体験に関わるつらいところを都度書き込んでもらうための仕組みです。 DXはデジタルトランスフォーメーションじゃなくて開発体験(Developer eXperience)を意味しています。 DXつらみ報告はSlackワークフローで作ってます。フォームに「つらみ」を入力するとGoogleスプレッドシートに自動で追記されます。

f:id:zacky2:20211027174350p:plain
Slackワークフロー

f:id:zacky2:20211028115702p:plain
DXつらみ収集スプレッドシート

つらみ報告の具体例を挙げます。

  • frontのgit commit時にlintが重いので完了が遅い
  • フラグ(※フィーチャートグルのこと)を消すのがつらい。自動で消して欲しい。
  • spec テストが POST フィールドを見てくれていない。POSTでも response は見ている。POSTフィールドはミスっても気が付きにくい状態になっている。

生産性向上の技術チームはこれらの「つらみ」をみて、「費用対効果がよいもの」や「すぐ直せるもの」を見つけて改善に取り組んでいます。 まだ始めたばかりの施策ですが、これから成果が出るものと期待しております。

まとめ

M&Aクラウドではチーム一丸となって生産性向上に取り組んでいます。 気持ち良い開発体験でプロダクトを開発したいエンジニアの方、WANTED!

www.wantedly.com

www.wantedly.com

絶対にモテる(チームから)コードレビュー実践編

f:id:tsukahara1991:20211018140302j:plain

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

今回は弊社の内部資料として使っている「コードレビューの型」を紹介します。

個人的にエンジニアにとって、コードレビューは福利厚生だと思っています。快適な開発現場を共有できるようにコードレビューについて考えていきましょう!

PHPカンファレンス2021で発表させていただいた「【IMO】コードレビューって難しいよね」の内容とほぼ同じものになっております。スライド資料で確認したい方はこちらをご覧ください。

これはなに

M&Aクラウドにおけるコードレビューの型です。 新しく入社されたメンバーに「コードレビューで何をするのか、どのようにしたら良いのか」という共通認識を持ってもらうための資料です。

コードレビューの目的

  • ソフトウェア品質の向上
    • 技術的負債となり得るコードがないかを確認する
      • 技術的負債とは、今後の機能拡張の障壁になりうるもの。いますぐに負債として発現するものでなくても、将来の拡張により負債となることもある
    • そのコードでユーザに今届けるべき価値が実現できているか確認
  • スキルの向上及びナレッジの共有(属人性の排除)
    • 他人のコードを読むことによって学びや発見を得る
    • 開発者同士のコミュニケーションの活発化
    • 担当者の実装レベルの把握と向上(教育的観点)

コードレビューの心構え

  • レビューしたコードを自分事として捉えること
    • チームのコードを育ている意識を忘れない
    • 人のコードもバグったら自分の責任
  • 最初から完璧なコードレビューができなくても大丈夫
    • まずは理解できないコードを無くしていくことを目指す
      • 分からないところは質問してみよう!

コードレビューの手順

f:id:tsukahara1991:20211018125015p:plain
PR→コードレビューのフェーズ

PR→コードレビューのフェーズ

  • 仕様を把握する
  • コードを見て、動きを想像する(想像できない時は先に動かしてみる)
  • 設計に違和感がないか、考慮漏れがないか確認する
  • 実際に動かしてみる
  • エッジケースを洗う
    • 例)登録ステータス、会員ステータスによって動作に不具合が発生しないか
  • セキュリティの問題がないか確認する
  • コードの影響範囲を洗う

コードレビュー→マージのフェーズ

  • 他のレビュアーのサポートをする
  • マージされるように実装や仕様を固めるのをサポートする
  • 本番に入れるまでと入れた後に必要なことを確認する

コードレビューで心掛けること

  • 自分がアプルーブしたコードに責任を持ちましょう。誰かが書いたコードという認識ではなく、チームのコード(資産)として、自分事として認識すること

個人で取り組む工夫

  • システム障害が発生した事象とコードを把握する

    • 実際に不具合が発生してしまったコードからなぜ発生したのか、なぜレビューから漏れてしまったのか振り返りを行って、改善に努めましょう
  • 誰よりも先にコードレビューをする

    • 慣れないうちは後からレビューすると「もう1人が見ているから大丈夫だろう」と意識が働きやすいです。できるだけ先にレビューしましょう
    • 先のレビューで見つけられなかった指摘箇所や考慮漏れがないか確認してみましょう
  • 自分が見ていないPRもチェックする

    • 別チームのPRや過去のPRをチェックしてレビュー経験値を積んでいきましょう
      • レビューコメントにある指摘理由は他の場面でも利用できることがたくさんあります。
      • プロダクトのコードを理解する上で過去のPRを見ておくことはおすすめです

チームで取り組む工夫

チームで効率良く運用できるように蓄積されてきたノウハウです。 下記以外にも効率良くできそうだなと感じることがあれば、メンバーに提案していきましょう。

  • PRテンプレートを利用する
    • GitHubでPRを作成する際に入力項目が自動生成されます。
    • PR前にチェック項目がクリアしていることを確認しましょう
  • 一回のPRサイズは400行を目安に
    • コード量が400行を超えていくと不具合を見つける精度が下がっていきます。大きなPRになる場合は、実装のキリの良いところでPRを分割しましょう。
  • ペアプロでコードレビュー
    • コードレビューをしていると細かい修正のラリーが何度も続いてしまうことがあります。
    • ペアプロで細かい修正はその場で解決してしまいましょう

コードレビューのコツ

  • 400行程度のPRは30 ~ 60分くらいでレビューを済ませよう
    • 1ptタスクで ~30分、3ptタスクで ~60分の目安
  • コード修正をコメントする時は根拠も一緒に記載しましょう
    • 根拠があればレビュイーも修正すべきか判断しやすくなります
    • 後からそのPRを見た人もなぜ修正されたのか経緯を知ることができます
    • レビュイーももらった修正案をそのまま鵜呑みにするのでは無くて、それが適切な形なのか考えながら判断しましょう。もし腑に落ちなければ、相談してみましょう
      • 即修正ではなくて、もらったアイデアを取り込む位のスタンスで
  • LGTMには素敵な画像を贈りましょう

PRを出す時のコツ

  • レビュアーがレビューしやすい様にサポート
    • コードの中で実装の肝となる部分にGitHub上でコメントを追加する
    • 実装で最適解なのか不安な部分はコメントでわかる様にする
    • 事前知識を必要とする実装の場合は、レビュー前に解説する
      • 例)口頭で実装の全体像を説明する→その後にレビューもらう

採用やってます

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

www.wantedly.com

画像引用元: Unsplash

プロジェクトマネージャーの型

こんにちは。エンジニアの鈴木(@yamotuki)です。
今回は、弊社の内部資料として使っている「プロジェクトマネージャーの型」を紹介します。

この資料は、今までの1~3ヶ月程度のプロジェクトを進める過程で得た知見を、個人の暗黙知ではなくチームとしてPMの役割を担える人を増やそうという目的で作りました。
PMができる状態のエンジニアであればメンバーとしても効率よく仕事を回せるのではないかという仮説のもと、PMの役割をやってもらう人以外にも展開しています。

以下はほぼ原文ままです。

これは何

プロジェクトマネージャ(PM)・リーダ業務の型をできるだけ明文化して、新しいPMやリーダ業務の助けになることを期待した資料。

PMがやること

目的を把握する

  • プロジェクトの目的を把握する
  • 目的に対してやりたいことが一致しているか確認し、一致していなかったらPdMやデザイナとすり合わせる

プロジェクトを小さくする

多くの目的を一度に達成する巨大プロジェクトになるのを防ぐ。 プロジェクトが大きくなると、以下の問題が発生する

  • 不確実性コーンは指数的に大きくなり、リリース日が読めなくなる
  • 長いプロジェクトになると開発者の脳内から初期の情報が揮発し、コードを読み直したり、リリースの手順を整えるのに苦労したりして生産性が低下する

検証したい目的に対して可能な限りリーンなプロジェクトとして小さくできないか検討する。 目安としては1~2スプリント以内(※弊社の場合は1スプリント2週間)に収めたい。

ref: 不安とストレスから解放される見積りとスケジュール方法 - Qiita

成果物をイメージする

  • PdMとデザイナが作ってくれたデザイン(またはそのカンプ)と暫定仕様書を元に、成果物のイメージをする
  • 上記の目的と、仕様・デザインが一致しているか確認し、問題提起する
  • やりたいことが技術的に無理があるところがないか、目的に対して不当に工数がかかることがないか確認する
  • デザインに無いけど既存で存在する or 重要なパーツが書かれていないみたいなことはあるので、あるべき情報は何か?をベースに考えるのが良い
成果物のイメージをするためのステップ
  • デザインや仕様書(項目整理やER図など含む)を見て、脳内で動かしてみる
    • これは慣れが必要なようだ。普段の業務から以下のステップで意識することでスキルとして鍛えられるかもしれない
      1. 小さなタスクで自分で模索しながら動くコードを書けるようにする
      2. 大きなタスクを分割してもらったり、指導をもらいながら完走できる
      3. 大きなタスクも自分でタスクをやる前に分割したり、全体設計をしたり、実装イメージをつけることができる
      4. コードと動作の関係を掴む
        1. PR や dev 環境などで、動作からコードがどう動いているかイメージする。「こういう動きをするなら、こういうケースだとバグりそうだな」が指摘できる
        2. コードから動作をイメージする。PRで、「このコードだとこんな変な動きになりません?」の指摘ができる
      5. デザインや仕様書とコードの関係を掴む
        1. まだ動作がない環境でも PR や dev 環境と同様にイメージする
          1. 「このデザインだとこの情報が足りない」
          2. 「この動きをするには情報がこのレイヤまで来ていないといけない」
          3. 「現在のコード設計だと実現が困難」「このような設計にすると楽に実現できる」

タスクを洗う

  • 上記の "デザインや仕様書とコードの関係を掴む" で掴んだ既存のコードとイメージしたコードのずれを探してリスト化する
    • 既存のコードにないものは全てタスクになる
    • 既存の設計で実現困難なものもリファクタのタスクになる

タスクを分解する

最初の分解
  • 洗ってリスト化したタスクを、可能な限り分担可能な形かつ小さなバッチに分解する
  • プロジェクトスケジュールを考えて、何人体制で対応しなければいけないか検討し、それに合わせて並列作業できるようにする
    • ある程度小さなバッチに分解した後に、クリティカルパスを特定する
    • クリティカルパスが大きすぎる場合には、そこをさらに分解してクリティカルじゃなくするためにはどうしたらいいか考える
    • 分解できない or スケジュールがきつい場合には、どうしたらクリティカルパスが最速で終わるか考える & チームを巻き込む
情報が増えたら再分解する

デザインがより詳細に固まったり、作業が途中まで進むとタスクに対しての詳細度が上がる。 その情報をもとに大きなタスクを細かく分解したり、足りないタスクを作成する。

順序を決める

優先度で組み替える

(間接的にでも)ユーザに価値を届けられる機能が優先。やってもユーザに価値が増えない機能は後回し。

不確実性の高いものから終わらせる

プロジェクト後半に不確実性の高いタスクが存在すると、いつ終わるか判断できず社内外のユーザに迷惑をかけてしまう。 できるだけ不確実性が高いタスクは早めに終わらせる。例えば以下のようなもの。

使ったことのないミドルウェアの使用
うまくいくかわからないアルゴリズムの使用
外部との連携
詳細仕様が未決定

ref: 不安とストレスから解放される見積りとスケジュール方法 - Qiita(再掲)

機能ごと完成させる
  • 原則として、1つの機能がユーザに届けられる状態まで一気にやった方が良い
    • 例えば プロジェクト全部のAPI -> プロジェクト全部のマークアップ -> プロジェクト全部の組み込み とやるより、一つの機能のAPI -> 一つの機能のマークアップ -> 一つの機能の組み込み をして都度完成させていく方が良い
    • 完成系に対してより早いフィードバックを得られ、その知見を次の機能を作るのに活かせるため

テストデータを整備する

local でテストデータが偏っていると確認が甘くなり、プロジェクト後半で問題が起こりやすくなる。 local の seeder に起こり得るパターンをあらかじめ作っておく、もしくはそれを作るタスクを作る。

割り振る

  • 可能であればメンバーの得意不得意・やりたいことを考えて割り振る
  • 途中で一人程度抜けてもプロジェクトが長く停滞しないように、情報を誰がどれくらい持っているべきか考えて進める

リリースまでにやらなくていいものを特定する

  • リリース後のインクリメンタルな改善で良いもの
  • ユーザ影響のないもの
  • コアの価値を提供するのに支障がないもの
    • できれば、コアの機能を提供するために「あれもこれも」とならないように仕様作成の段階から分離可能にするのをサポートするのが望ましい(理想)

ボールが落ちていないかチェックする

  • 落ちそうなボールは、積極的に拾う
    • 落ちていて後から出現したボールで問題になりそうなものは、軽微なものは自分で巻き取ってさっさと終わらせる or 大きそうなものであればメンバを巻き込んで分担を改めて考える
    • 後で忘れずに拾えるところに明記する
  • メンバーが落ちていたボールに気が付いてくれたり、拾ってくれたら感謝し、そういった行動を推奨する。PMにとって落ちていたボールはプロジェクト終盤の痛手になるため、拾ってくれる人は多ければ多いほど良い。

小さいイテレーションでやること

小さい目標を作る

目標は分かりやすければ分かりやすい方が良い。

  • 特定の見える成果物を作る
  • 何ポイント消化するか決める

その目標を達成するためにそれぞれのメンバーが何を頑張ればいいかブレークダウンして、担当を割り振る。 いつ、どれくらい頑張れば達成できるのか可能な限り明確化する。

成果物確認会を開催する

PdM, デザイナ, エンジニアと必要に応じてさらに上長を呼んで成果物の確認会を開催する。
開催タイミングは、機能が大体できたという状態で開催する。完全に完成してから開催するのではなく、ある程度機能ができた段階などにも開催し、プロジェクトの大きさに合わせて複数回開催しても良い。
議事録テンプレートには以下の要素を含める。

  1. 確認シナリオ
  2. エッジケース確認項目
  3. 「気になること」を書いて管理する場所

目的は早い段階でフィードバックを受け取り、改善をする。フィードバックは次の機能を作る時にも活用する。 具体的には以下のようなフィードバックを積極的に受ける。

  • やりたいことに対する成果物の方向があっているか
  • 仕様に対して実装もれがないか
  • バグがないか発見

おまけ

人数が少なければPMはストロングスタイルが通じることもある「みんな勝手にやってくれ。遅れたところや漏れたボールは俺が全部やるから。」
四人以上の場合は通用しないことが多い(体感)。三人くらいまでなら技術的に優秀なリーダがこの形でPM業務をやっているケースもある。

採用やってます

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

www.wantedly.com

画像引用元: Event illustrations by Storyset

Nuxt道場 弐面を開催しました🎉

f:id:kubotak:20210910162946p:plain

こんにちは久保田(@kubotak_public)です

2021/09/08 19:30よりNuxt道場 弐面を開催いたしました。
弐面は第二回という意味です。

記念すべき第一回の様子は以下です。

tech.macloud.jp

今回は弊社の津崎が登壇しました。
弊社のエンジニアはもともとフロントエンドを書いて来たエンジニアではなく、どちらかというとインフラやバックエンドがキャリアとしては多いです。
そんな我々も今ではNuxt.jsをTypeScriptを用いて開発しています。
今ではゴリゴリにTypeScriptを書いている津崎の発表を是非御覧ください。

以下イベント配信のアーカイブ動画です。 youtu.be

Nuxt.js x Composition API x TypeScript - Speaker Deck

また、弐面ではベースフード株式会社よりVPoE 煙草森直也さんが師範として登壇いただきました。
Shopifyとの連携した決済システムなど、なかなか聞くことのできない貴重な発表でした。
現在エンジニア募集中とのことです。気になる方はぜひチェックください)

その他、弊社プラットフォームM&Aクラウドを利用して資金調達をされた株式会社Re:Build 代表 鈴木孝之さんのMiddrewareの権限周りの大変だった話や、イベント初の道場破りtyamahoriさんのDocker Desktop on MacによるNuxtの開発Tipsの話など盛り上がりました。
配信は全てアーカイブとして残っていますので今からでも閲覧できます。ぜひご視聴ください。

Nuxt.jsのmiddlewareを使って権限チェックしたらスパゲティになってしまった話 - Speaker Deck

qiita.com

謝辞

配信をご覧くださった視聴者の皆様、また登壇をしていただいた皆様には感謝いたします。
今回の配信では私の配信環境によるトラブルで二度ほど配信が途切れることがあり大変申し訳ありませんでした。
(リモートワークのため自宅から配信してますが機材の見直しなど必要かもしれません・・・)

最後に

二度あることは三度あるということで、登壇したいという方がいらっしゃいましたらぜひ久保田までお声がけください。