エンジニアリング組織論への招待を読んで考えていること(第2章)

はじめに

ちまたで話題のエンジニアリング組織論への招待を読んで、感じたこと、考えたことをまとめていきたい。
何度も読み直すし、それに対する自分のactionも都度updateされていくものだと思う。
にしても、ここまで体型的にまとめられているのは本当にすごい。
これを書けるようになるような人になる方法も知りたい笑


わたしは

とある企業のマネージャー
UIエンジニア
メンバーは20人弱

ここ最近は

システムのリニューアルに従事。
このリニューアルは、アーキテクチャ、仕様含めてのフルリニューアルであった為、非常に不確実性の高いプロジェクトでした。

Chapter2 : メンタリングの技術を読んで考えていること(WIP)

障害時ハンドリング
  • 今のグループが新規のアプリをscratchで作るために作ったグループで、

結成時にいた3人を除いてまだ本番にデプロイされたプロダクトの本格的な監視を行っていないので、
どうなっていくか気になっている

チームマネジメント
  • いかにメンバーにOwnershipを感じてもらえるか、というのは個人的な最近のテーマ
  • みんながこれは俺のプロダクトだ!って思って思ってもらえることがproductivityとresopnsibilityに直結する
効果的なメンター/メンティの関係性
  • ここは比較的自信がある
  • 強いて言えば、自分が相手に敬意を持たれるような存在でいつづけたい
他者説得から自己説得に
  • 指摘だけではなく、ルールやプロセスを策定したりするときにも意識するべき
  • どうやったらそのルールやプロセスが必要か感じてもらえるかを感がえる
  • メンバーに自分が提案するときに、相手が腑に落ちていなさそうだったら、

どうやって自己説得してもらえるか考えてもらうということも必要

エンジニアリング組織論への招待を読んで考えていること(第1章)

はじめに

ちまたで話題のエンジニアリング組織論への招待を読んで、感じたこと、考えたことをまとめていきたい。
何度も読み直すし、それに対する自分のactionも都度updateされていくものだと思う。
にしても、ここまで体型的にまとめられているのは本当にすごい。
これを書けるようになるような人になる方法も知りたい笑


わたしは

とある企業のマネージャー
UIエンジニア
メンバーは20人弱

ここ最近は

システムのリニューアルに従事。
このリニューアルは、アーキテクチャ、仕様含めてのフルリニューアルであった為、非常に不確実性の高いプロジェクトでした。

Chapter1 : 思考のリファクタリングを読んで考えていること(WIP)

三次元の「U」(2018/12/05)

これを読んで、思い浮かぶのは、PDM, DEV, QAの関わり方。

  • 参考

www.atmarkit.co.jp
https://image.slidesharecdn.com/jasstver31-170216061948/95/-20-638.jpg?cb=1487226789


会社では、よくこの3つの立場でバランスをとることを意識しようとしていた。
(実際には、特にPDMはビジネス側との関わりも強いので、4つで考えないといけない場面も多かったとは思うが)

例えばQAとは、QAに出すタイミングでqualityの共通認識がとれだけとれるかが大切。

  • スピードを重視したい時
  • 品質を重視したい時

でQAに渡すプロダクトの品質に多かれ少なかればらつきは発生すると思っている。
その時に、その目的を共有できていないと、お互いが問題を感じることが多い。
特に、スピードを重視する時。

極端に書くならば、
DEV - この期間でこれだけの機能を実装したから、このくらいのバグは出る
QA - なんでこんなに品質が悪いのか
みたいな感じ。

いいプロダクトを出来るだけ早く良い品質で世の中に出したい

というのが全体像かつ共通の目標で、そこに対して、どのタイミングでの品質を大事にしたりとか、
どこにテストの負担をかけるとか、そういうことが事前に共通認識がとれていれば、
そこまで問題にはならない。

マネージャとして、メンバーが全体像を見えていないと感じたら、三次元の「U」を描いて見せてあげることが大切

情報の非対称性(2018/12/05)

ハンロンの剃刀 - Wikipedia

カレー作りの寓話(2018/12/03)

組織が大きくなるにつれて、役割は分担されていきます。
役割を分担すると、まずはその役割の責任範囲を明確にしようとしていました。
明確にすることは大切でしたが、それだけだと、役割分担的に宙に浮く仕事や、
その役割の人がすぐに作業できる状態に無いと

f:id:takahiro-f:20181203191636p:plain
※実際にはそこまで食い合ってないです

  • 宙に浮いた仕事の反応が悪くなってしまうことがある
  • (特に)Leaderの仕事が不在時にボトルネックになりがち(自分かなw)
    • MgrやMemberのこともある

今までは、個人個人の判断で巻き取ってくれたりくれなかったりという状況でした。
※くれないことが悪いと思っているという意図はありません

そもそも、宙に浮いてしまう仕事があることは、そもそもの役割分担がいけてないこともあります。
ただ、それも踏まえた上で、今はこういう状況で、ここはいけてないしベストではないと思うんだけど、
必要に応じて、こういう部分の仕事を巻き取ってほしい
ということを明文化することにしました。
なるべく良くない所は良くないと明記することを意識しました。
※良く無い所をどういう風に無くしていきたいか、というのも別途用意しています

e.g)

  • 問い合わせの対応
  • 緊急対応
  • 複数チームのドメインを跨ぐタスクのハンドリング
  • 必要な承認など

(を具体的に書いた感じです)

create-react-appからstorybook4動かす

まえがき

怒涛の忙しい日々から少しだけ時間ができたので、ちょっとずつ再開します。

まずはここみて

とりあえずここみたら10分でできる(こういうときnpx楽
Adding Storybook Style Guide to a Create React App · Manorisms

nodeがあまりにも古い場合はまずupdateする必要があります。
create-react-appのreadmeを確認してください。
npxもなければ、入れた方が少し楽です。
(つまるところnpmが古かったらupdateしてください、ということです。)
github.com

0からstorybook入れ直す方が基本的に楽です。
MIGRATION.mdにreact-create-appからstorybookを動かす際の注意などが書いてあるので、そちらを参考にすると良いです。
色々breaking changeあるので、ちょっとだけ、いじくらないといけないです。

github.com

やったこと(MIGRATION.mdをみて、そこに書いてあることをやるのが良い)

yarn remove babel-core babel-runtime
yarn add @babel/core babel-loader@next --dev

うごいたもの

f:id:takahiro-f:20181119201834p:plain

あとがき

ブログにするような量ではないのですが、何かやったことを書きたかったので。
無駄な文章にならないように極力廃れる内容自体はここには書きませんでした。
再始動やー

第3回 -ドメイン駆動設計のための オブジェクト指向プログラミング ハンズオン"に参加してきた!

今回はasoviewさんが主催された
"ドメイン駆動設計のための オブジェクト指向プログラミング ハンズオン"勉強会に参加してきました。

asoview!(アソビュー)|日本最大の遊びのマーケットプレイス

まえがき

最近になって、また日に日にDDDの話題を見る機会が多くなってきていますね。そんな中、今回はasoviewさんが主催された勉強会に参加してきました。

本勉強会は1回2時間の勉強会を計3回実施するという、なかなか骨太な勉強会です。
(諸事情により、2回目は参加することが出来ませんでしたが…)

これくらい時間をかけて行う勉強会はそう多くありませんが、
DDDを扱うにはこれくらい時間をかけて勉強会をするべきだとも思いました。
短い勉強会・発表だと、DDDの中で自分が気になっている箇所が取り扱われないこともよくありますし。

また、社内向けの勉強会を今回このように一般公開するという取り組みも、大変良い取り組みだと思いました。
(うちの部署でももっとこういうことを活発にやっていきたいな)

講演者

今回は、DDDに大変知見のあるシステム設計の増田 亨さんによる講演でした。
増田さんがasoviewで技術顧問を務めていらっしゃることもあり、勉強会開催の搬びとなったようです。
こちらの記事も大変面白かったです!

CTO江部・技術顧問増田 対談① ~アソビューの挑戦と魅力~
www.asoview.co.jp

各勉強会のテーマ

第1回 10月11日(水)19:30~21:30
テーマ:基本部品を作ってみる
・数値を扱うオブジェクトの設計と実装
・日付と年令を扱うオブジェクトの設計と実装
・集合を扱うオブジェクトの設計と実装

第2回 10月18日(水)19:30~21:30
テーマ:モデルと実装を一致させる
・モデルの表現方法:図、言葉、コード
モデリングと実装の演習:顧客の購入単価の平均

第3回 10月25日(水)19:30~21:30
テーマ:三層+ドメインモデルでWeb アプリケーションを実装してみる
・顧客の購入情報を記録
・購入単価の平均の表示

第1回,第2回勉強会の様子

嬉しいことに、本勉強会の様子は動画が上げられています!
また、後述しますが、本勉強会と同じ流れで会社のチームで同じ勉強会をしてみることも大変有効だと思います。特にJavaで開発を進められている所は、動画を観ながら、全く同じ流れで勉強会を進めることもできるので、やってみてはいかがでしょうか。

・第1回
youtu.be

・第2回
youtu.be

第3回で利用したリポジトリ

GitHub - system-sekkei/isolating-the-domain: Spring Boot : gradle, Spring MVC, Thymeleaf, MyBatis and Spring Security sample

きちんと事前に勉強会で利用するリポジトリが準備・共有されていて、
勉強会でもすぐにコードを書いて議論する、ということができたのが良かったです。

こちらのリポジトリに関しては、
issueの起票やpull request歓迎とおっしゃっていたので、
勉強会を再現する中で、実際にpull requestを送ってみるのも良いと思います。

例えば、僕はIDがメールアドレスで管理されている所が気になったので、それを変えようとしたり、、、
といって感じです。

勉強会の内容

内容自体は、connpassにも記載されていますが、
3回目はサンプルアプリケーションを元に、自分でissueを見つけて、直して、周りの人と話すっていうスタイルのハンズオンでした。

この勉強会はハンズオンと呼ぶにふさわしく(?)勉強会が始まって10数分で「今から10分でコード書いて周りの人と話し合って」となった時は
変な緊張感ありましたが、手を動かしながら勉強するにこしたことはないので、結果的には良かったなと思いました。笑

第3回

第3回目は、手を動かすことに終始した回でした。

github.com

こちらは(有)システム設計さんで用意されているサンプルリポジトリで、
主にSpring Boot, Thymeleaf, Mybatisを利用して作られた、会員情報の管理システムです。

H2を利用しているので、

www.h2database.com

spring.io


チェックアウトして立ち上げてすぐに、会員一覧表示、登録、更新、削除、を確認、試すことができます。

一覧表示
f:id:takahiro-f:20171029165557p:plain

会員登録
f:id:takahiro-f:20171029165553p:plain

更新
f:id:takahiro-f:20171029165545p:plain

削除
f:id:takahiro-f:20171029165541p:plain

環境設定の一切の手間なく、コードを改修できるので、今回のハンズオンに向いていたと思います。

また、自分はあまりMybatisの経験が多くないですが、こちらの構成は日本でSpring使っている人たちにとっては
一般的な構成だとも思いますので、そういった点でも、とっつきやすいのではないでしょうか。

ドメインモデルを意識して作られたサンプルアプリケーションを使って、Issueを見つけたり、
自分が改善できる点を改善したりして、Pull Requestを送ったり、
同じテーブルのメンバーと相談したり話したりしました。

2時間というと長いような気がしていたんですが、こういった形式のハンズオンだと時間はあっという間でした。

最後に

今回の勉強会は、
DDDの勉強そのものにもオススメですが、よりおすすめなのは、
DDDの導入を検討していたり、DDDをやってみたいけどやれてない
DDDとまではいかないまでも、ドメインに対する議論をもっとしたい
など、実際にドメインについて考える機会をどうチームに与えていくか、という観点で非常に良い勉強会だったように感じます。

また、今回の勉強会は以前職場でお世話になった方にお会いできたのも嬉しかったです!

次に

今回の記事投稿ではDDDそのものについては書く余裕がなかったので、
次の記事で勉強会を受けて、DDDについての自分の考えやなどをまとめて書こうと思います。

Microservice Meetup #5 参加ブログ2(Webサービスの初期開発とマイクロサービス・BFF)

前回の記事に引き続き、Microservice meetupの参加ブログになります。
microservices-meetup.connpass.com


前回の記事はこちらです
takahiro-fujii.hatenablog.com

発表項目

APIのことはすべてシーマンが教えてくれた。」 by @charlier_shoe さん

www.slideshare.net


「step by step BFF」 by @yosuke_furukawa さん
speakerdeck.com


Webサービスの初期開発とマイクロサービス・BFF」 by @shimpeiws さん
speakerdeck.com


Railsで作るBFFの功罪」 by @shotat_jp さん
engineer.recruit-lifestyle.co.jp

をベースにした話

Webサービスの初期開発とマイクロサービス・BFF

今回は、
株式会社アカツキ(Akatsuki Inc.) の@shimpeiws さんによる発表についてのまとめになります。

こちらも、"step by step BFF"と同じくSPA,BFFに関連するプレゼンテーションですが、

新規のアプリーケーション開発を通じて発生した課題と解決法、
これからのアクションを通じて、どのようにBFFを使おうと考えているかということが、
非常に分かりやすく説明されていました。
特に、これからSPA+Microserviceな構成で新規でアプリを作ることを検討されている方は見ておくと良いスライドだと思います。

発表は、大きく分けて、
1 - 要件とアーキテクチャ
2 - 開発初期での選択と集中と課題
3 - BFFのプロトタイプの実装
という三部構成でした。特に2を経て、どういう経緯でBFFを導入しようと思ったかという点が勉強になります。

1 - 要件とアーキテクチャ

要件
  • 今回はWEBからスタートするアプリだったそうです。(なんのアプリなんだろう、、)

後からネイティブアプリが出る可能性が高いとのこと

  • インタラクションが多いUI(ほんとにこれとSPAは相性いい)
  • 長期的な運用になる見込み(保守性とスケーラビリティ)
アーキテクチャ

Front-End

  • SPA(Single Page Application)

Server Side

Infrastructure

  • GCP
  • Kubernates

実際の構成も紹介されていました。(8~9スライド目)
一般的なSPA + API構成といった感じです。

2 - 開発初期での選択と集中と課題

まだまだ絶賛開発中な感じなのかもしれない。と話を聞いて思った。
短期間で結構色々変わっているな、という印象も。
このような組織のサイズと期間で、開発を進めているらしい。

立ち上げ期(2Month) 開発初期(4Month) 開発中期(これから)
チーム 1チーム(4名) 1チーム(5名) 4チーム
開発内容 - 開発フロー整備
- QA/Production環境構築
- 基本機能一通り
- アイテムタイプの追加
- 口コミの実装
- 全文検索
- バグ・負債を若干返済
- グロースハック施策
- 基盤となる機能の開発
- インフラ・ミドルウェア・デプロイの整備
ハイライト - アーキテクチャ・設計指針決定
- 開発ボリュームを抑えきれず混乱
- アーキテクチャに大きく手は入れてない
- スクラム開発の運用を手探り
- チームの分割
- マイクロサービス化の推進
- 中長期的な運用の開始
  • 開発中期に入っていきなり4チームになるとか結構ドラスティック。
  • 開発初期と呼んでいるフェーズで、ある程度なのかもしれないですが、きちんとバグ・負債を返している
  • 組織が別れたタイミングと、マイクロサービス化のタイミングが重なる

そして、この後のスライドが結構衝撃的だったんですが、

- Ruby(15,000行)
- React(60,000行!!!)
- JavaScript(25,000行)

上のスライドの期間をみても半年弱なので、期間に対してかなりのコード量だな、とは思いました。
とにかくガンガンコード書いた感じが伝わって来ますね。

初期の設計思想としては、

  • SPA + SSRすること
  • シンプルなAPIな設計

の2点に重きをおいているようでした。
ブレイクダウンしています。

SPA + SSRすること

なぜやったか?

  • 複雑なインタラクションとイニシャルビューの表示を早くしたい
  • -> SPA + SSR
  • -> React + Redux構成にした

Pros

  • ダイナミックなWebフロントエンドを作りやすい
  • SPAできる(ルーティング、State管理)

Cons

  • 開発工数が一時的にあがる
  • Node.js分が入って、開発全体でのデプロイ、管理コストが増えた
シンプルなAPI設計にすること

開発の初期段階では、API設計はとにかくシンプルにすることを意識、優先したということです。

具体的には、APIはRESTにしたそう。

  • ドメイン設計にかける時間を十分にとれないから一旦ある程度諦めたという話が考えさせられました。ドメイン設計は諦めたけど、RESTFulにはする、という点が特に。どれ位RESTなのか、という点が気になります。
  • 画面にべったりそったAPIで保守性をさげたくない(特定のアプリ用のAPIたくさん作りたくない)

ドメインは考えないものの、APIはRESTで作るから、ある程度リソースの粒度や認識が定義されていたということでしょうか。
いずれにしても、初期のレビューでチーム内の意識統一を進めて行ったという点が非常に共感できました。これがしっかり出来ないと、スケールしたりチーム分けた瞬間に崩れ去ります。。

Pros

  • SpecificなAPIは作られなかった(特定のプロダクト、機能に用途に限定されたような)
  • 設計・実装が楽でバグも少なかった(いいね)

Cons

  • フロントエンドが辛くなった(!!!)

"何が辛い?"
1.APIを呼ぶ回数が増える
オーケストレーション層がない状態でREST APIが増えると(設計次第な所はあると思いますが)ある操作をするのに、たくさんAPIを呼ばないといけないケースがあります。

2.APIを呼ぶのに、順番の依存が発生することがある
※これは、一概にRESTでAPIを作ったことだけが原因ではないと思いますが

APIを呼ぶのに依存が増えると、そのAPIの使い方が分かりにくくなるし、
リリースに結構厳しい依存ができて、結果的にRESTであるにも関わらず修正しにくくなる(フロントとの依存が結構強かったりして)とかもあります。

スライドでも

  • 6並列でAPIを呼んだ後で直接でAPIを2つ呼ぶ

という例が紹介されていました。(きっと実際にあるんだろうな、、)

これらの問題を"アーキテクチャ的な観点"で解決する為に、BFFを導入する流れになっているようです。

開発初期振り返り

3 - BFFのプロトタイプの実装

これからBFFを実装していく、というフェーズのよう。

  • I/Fは画面に必要なものをまとめて返す
  • レスポンス遅いのはダメ
  • フロントエンドと密結合するので、更新頻度は高い
    • フロントエンド側の人間が気軽に触れる方が良い
プロトタイプ
  • 一覧に商品と商品についたコメントを表示する
  • ログイン済のユーザのみ見れる(認証)

という例でBFFのプロトタイプの実装が紹介されていました。
基本的には、開発初期にシンプルなAPIを設計したことでフロントエンドが辛くなっていた部分を、BFFが引き受けているという印象です。

所感

  • SPAとしては割とベーシックで、SPAじゃないアプリでBFFやMicroserviceとやりとりする場合でも、共通して話せる話題が多かった気しました。
  • 新規でアプリケーションを作る際の流れにそって話が進んで行ったので、

直面されていた課題がイメージしやすく、自分だったらどうするのかな
ということを考えながら話を聞くことができました。

  • BFFをリアーキテクトとして使っている点は、前回のブログとも同じなのかなと。

ProxyとしてBFFを差し込む、という感じは、たとえ最初からSPA+Microserviceの構成で作ったとしても同じ、という印象を受けました
最初に裏をRestで作るところがうまく行ってるのか気になる、バックエンド側のリファクタリングとか今今発生しているのかとか

Microservice Meetup #5 参加ブログ1(step by step BFF)

Inside FrontEndに引き続き、ブログ書く枠で参加させて頂きました。
今回で5回目となるMicroservice meetupですが、中々都合がつかず、
個人としては今回が初めての参加になります。

microservices-meetup.connpass.com

発表項目

APIのことはすべてシーマンが教えてくれた。」 by @charlier_shoe さん

www.slideshare.net


「step by step BFF」 by @yosuke_furukawa さん
speakerdeck.com


Webサービスの初期開発とマイクロサービス・BFF」 by @shimpeiws さん
speakerdeck.com


Railsで作るBFFの功罪」 by @shotat_jp さん
engineer.recruit-lifestyle.co.jp

をベースにした話

step by step BFF

個人的には一番今構成について議論している環境に近く、参考になるセッションでした。
まずはこちらのセッションについてまとめます。

日本Node.jsユーザグループ代表,RecruitTechのFurukawaさんのお話

1 BFFとは

  • フロントエンドとバックエンドを明確に分ける、マイクロサービスを意識するためのもの
  • 皆さんがよく引用する、SamNewmanの記事も紹介

Sam Newman - Backends For Frontends

  • ドメインに特化したサービスとリッチなクライアントを繋ぐ調停役
    • 画面を作るための補佐
    • API Aggregation

2 BFFが担う役割

このパートが聞けたのよかった。

1 API Aggregation

Aggregation : 集約する、集合体、集合させる

ここは特に異論ないところだと思います。
非同期で複数のMicroserviceをCallし、フロントエンドが必要な形に整えて返す
という役割です。

2 Session Management

API Gatewayの観点からすれば、これも自然な役割だと思います。
セッションを元にtokenを取得して、tokenを利用して各APIにアクセスする部分をBFFでやります。

3 (Server Side) Rendering

これは、SPA(Single Page Application)が関連してきますね。
これをはっきりBFFの役割に入れてるのは面白かったです。

4 File Upload

これまた面白い話。
ファイルアップロードする機能そのものは、BFFに実装したという話。
これは同じような悩みをした経験が・・・。

・ファイルをアップロードする行為そのものはRestと相性が悪い
・BFFでAWSのS3みたいな所にファイルアップロードは済ませて、
そのfilepathをrequestに入れてファイルを管理するrestful apiにリクエストする
みたいなことをおっしゃっていたと思います。

5 WebSocket / LongPolling / SSE(Server Sent Events)

WebSocket / Long Polling / SSEも、BFF経由で行う。
Message QueとのやりとりもBFFが直接行う。

Cache

具体例の紹介があったわけではないですが、スライドには
CacheもBFFでやるとbackend-friendlyという話がありました。
色々な場所でキャッシュし始めるとヤバいので、同意

3 BFFが生まれた背景

Previous BFF pattern

  • 1990 ~ : 3tier Client-Server System
  • 1990 - 2000 : Monolitic Architecture
  • 2010 : Single Page Application
  • 2013 - ? : Single Page Application with Microservices
  • クライアント側にロジックがよりがち
  • フロントエンドはUIに集中したい
  • ということを考えるとBFFが必要

という流れだった。

  • BFFをNode.jsにするとFrontEnd(SPA)と作業を共通化できる

という話があったので、こんな疑問を思いました。


で、ここら辺で発言したことをパネルディスカッションの時に(恐らく)拾って頂いて、
確認したところ、やっぱりBFFはフロントエンド側で管理しているらしい。

4 BFFの利用事例(Twitter,Netflix,RecruitTech)

1 Twitter

何かと話題になったこの件笑


Mobile TwitterがNodeでアクセスを受け始めた。ということです。

29スライド目にあるような構成だと、まさにSPA+BFF(Node,Express,React)で構成されている感じみたいです。
Mobile Twitterというのはこっちのことですね。

https://mobile.twitter.com/home

2 Netflix

Microserviceの話になると大抵Netflixの話が上がります。ブログを読むと僕らが今直面してる課題が、
数年前のブログのっていたりして辛くなることがありうます笑

3 RecruitTech
  • BFFをNode.jsで構築
  • 上にあるような使い方をしている

例としてブッキングテーブルというサービスの構成が紹介されていました。
ブッキングテーブルではネイティブアプリとWEBでBFFを分けているみたいです。

bookingtable.jp


あとは、raicoというサービスも紹介されていました。(見つけられなかった

5 どのようなタイミングでBFFを導入する/しないのか

するとき
  • フロントエンドとバックエンドで開発者を分業して、疎結合にしたいとき
  • レガシーなシステムがすでに存在しており、段階的にリアーキテクトしたい
  • ユースケース上必要になる場合
しないとき
  • フルスタックエンジニアが多いとき
  • Monolithcに開発して最速でサービス出したい時
  • ユースケース上必要ない場合

6 どのように段階的にBFFを導入するか(Step by step BFF)

  • BFFをProxyとして構築する
  • 最初はレンダリングするところだけ
  • だんだんと内部の処理を置き換えていく

所感

  • まず、しっかりと実例が聞けたとき点において大変参考になった
  • Backend側の話はそんなに無かったが、綺麗なRestfulにする為にBFFが色々やってる(ファイルアップロードとか、websocketとか)というのもありそう。(フロントの為だけじゃなくて
  • そこが調停するっていう表現なのかな
  • エラーメッセージのハンドリングとか、聞けばよかった
  • このセッションに限ったことではないけど、BFFがAPI Gatwayを包含している感じだった

多国籍で多趣向なみんなと楽しく飲み会をするために

f:id:takahiro-f:20170303204152j:plain

まとめ

  • レンタルスペース×ケータリングを利用してコストを抑えた
  • レンタルスペース×ケータリングだと、直前に人数が変わっても割りと大丈夫!
  • 池尻セレクトハウスオシャレ!みどりえ、ドミノピザ、カクヤス最高!

難しさ

まず、多国籍、他趣向なみんなと飲み会をするのは、
何が難しいのか?という点について、僕なりに感じていることを。

食べられるものが違う

これは想像がつくと思いますが、
いろんな国の方と働いて改めて感じるのは、
日本の人は本当に割となんでも食べるな、ということです。
なんでも食べられるが故に、僕らはあまり困らないです。
それが故に、割と軽視しがちな所もあります。

どんなものが食べられない?

まずは、宗教的な理由で一部ないし、全てのお肉が食べられない人は割といます。

ベジタリアンの人もいます。また、ベジタリアンの中でもさらにビーガンの方や、
もう少し厳しい制約がある方もいます。

http://veganic.co.jp/veganism/

  • 牛肉×
  • 豚肉×
  • 肉全般×
  • 生肉×
  • 乳製品(チーズとか)×
  • etc..

あとは、宗教上の理由ではないけども、もともとの食生活で食べて来なかったものは、
あまり好きではない割合が多いと思います。

例えば、生肉を食べる習慣が無い所では生肉/ホルモンを敬遠する人はそれなりにいますし、
生魚を食べる習慣が無かった人の中では刺身/寿司があまり好きで無い人もいます。
卵がダメな人とかもいます。

食べられるものと食べたいものは違う!

さらに気をつけなければならないのは、食べられるものと食べたいものは違う、ということです。
最大公約数でみんなが食べられるものを選んでいると、必然的に行くタイプのお店が限定されます。

  • 牛肉、豚肉×の場合 -> 鶏肉系(焼き鳥など)
  • 肉全般× -> インド系料理屋(カレーなど),オーガニックレストラン等

東京は肉がダメな場合の対応パターンが相当限られる、、というのはあると思います。
そうすると、やっぱり飽きて来たりするんですよね。
「食べられるんだけど、それが食べたいわけじゃない!」
ってなると、段々と飲み会の参加者が減って行くこともあります。
あとは、日本人の感覚だとカレーとお酒とかあんまりイメージないかも。

また、本人の趣向として野菜があまり好きでは無い(野菜より肉!)、という人は結構いるので、
ベジタリアン向けのレストランもそういう点において大人数の飲み会には合わないことがあります。
オーガニックのレストランは、ややコストが高くなることが多いとも思います。(仕方ないのですが)
普段使いができる、安価なベジタリアン、ビーガン対応のレストランが増えるといいなって思います。
(現状はそういう趣向の割合が多いお店がそうなのかな(インド料理屋、メキシコ料理屋とか))

飲み会にかかるお金

飲み会にかけるお金の感覚も国によって違います。
これを気にしすぎるのは正直厳しいかなと思う(国には国の物価がある)ので、
必要以上に考慮する必要はないと思っていますが、

  • コストが原因で飲み会に参加しないという選択をする人がいる

ということを知っておいてもいいと思います。
「あの子、あんまり飲み会こないな」という人の中には、
そういう場が嫌いなだけではなく、
コストの面が原因となっていることもあるということです。

コース料理、飲み放題、予約の難しさ、飲み会の位置付け

飲み会に対する考え方の差、も色々とあるように思います。
幹事をやっている当初は、かなりこれに悩まされました笑

例えば、飲み会をコースで予約します。
とすると、大抵の場合、みんなに
「キャンセルの場合は開催2日前までに連絡をお願いします」
的な連絡をすることになります。

僕の感覚では、日本人だけで飲み会をするよりも直前キャンセル率があがります。
体調不良などであれば、まぁあることではありますが、
例えば、

  • 受け取りたい宅配物が今日来ることになった
  • 他に予定ができた
  • とにかく行けなくなった(!)

とか、一見そこらへん上手くやってよ!笑と思うような理由もあったります。
でも、そういうもんなのかもな、と思うところもあります。

コース料理でガチガチにキャンセルポリシーが確定するようなパターンは、
カジュアルなお店だと海外ではあまりないのかもしれません。
どっちかっていうと、飲める時に行ける人でみんなで飲みに行こうよ!
みたいな感じの方がしっくりくるんだろうなー

  • じゃあ、コース料理にしなければいいじゃん

は一理あります。が、少し注意することもあります。

コース料理と飲み放題
  • それは、飲み放題にするのにコース料理が必須となる

場合です。
お酒を飲む飲まないも、かなり個人差があります。
日本よりよく飲む人が多いようなイメージがある、欧米や、韓国の方とか
逆にインドや中国は比較的少ないイメージがあります。(あくまで平均として)
で、日本のお店の場合、飲み放題にしないと予算が見えなくなる怖さがあります。
飲み放題にしないほうが安くなるケースも多々あるのですが、そうでは無いケースもありますし、

  • 気づかずにいいお酒とか頼んでて会計の値段あがっちゃう

みたいなパターンもあります。
そういった理由から、飲み放題にしたいなーって思うことはあります。
そうすると、コース料理が必須です、というお店はわりとあります。
結果、キャンセルのコントロールが難しくなります。
(結果としてキャンセル料が発生したら、直前にキャンセルした方からキャンセル料は頂いてもちろんいいとは思うのですが)

多少融通を利かすケースとしては、事前に、直前キャンセルが発生した場合、

  • 飲み放題の料金だけ減らしてもらえるか

を確認しておくといいです。大抵の場合、キャンセル料が発生するのは食材の準備に影響される所が大きいので、料理は当初予定していた人数のままでも、飲み放題の人数だけ調整してくれる、というお店はあります。それで、1人あたりの料金を若干あげれば調整できるので、そういった方法もあります。
(限界ありますが)

予約の難しさ、飲み会の位置付け(人数の変動)

料理のメニューに関わらず、直前の人数の変動は難しいです。
直前で減るケースもありますが、直前で増えるケースもあったりします。
(やっぱり今日行きたい的な)

お店のタイプによりますが、ある程度の規模になってくると、
直前の人数の変更が、お店にとって迷惑になったり、そもそも不可の場合もあります。
全然仕方が無いことなんですが、比較的直前で参加人数が変動しがちなので、
難しいなと思うことがあります。

とまぁ、こんな感じで結構悩みはつきないわけです。笑

そこで今回の飲み会どうしたか

本題です笑

そこで、今回の飲み会をどうやってみたかということです。

  • 1.レストランを予約せずにレンタルスペースを借りた
  • 2.ケータリングでベジタリアン対応のメニューを頼んだ
  • 3.ドミノピザでピザいっぱい頼んだ!
  • 4.カクヤスでお酒,ソフトドリンク(+お菓子)も持って来てもらった(Webで注文)

です。割と普通ですかね笑

レンタルスペース×ケータリング

難しさの一部を解決するべく、レストランの予約ではなくレンタルスペースにしました。
レンタルスペースはスペースマーケット | 会議室から球場までレンタルスペースを簡単予約で予約しました!
今までも小規模のイベントなどで利用したことはありましたが、20,30人規模の飲み会で使うのは初めてでした。

今回は、池尻セレクトハウスさんを利用させていただきました!めちゃおしゃれ!

池尻セレクトハウス
spacemarket.com

f:id:takahiro-f:20170303181109j:plain

f:id:takahiro-f:20170303181120j:plain

f:id:takahiro-f:20170303181541j:plain

自分なりに感じたレンタルスペースの良い点、考慮点は下記です。

  • 良い点
    • 会場の規模の範囲内での人数の変動の影響が少ない
    • 1人1人の参加、不参加のキャンポリない
    • 立食パーティに近い感じで、気軽に席を変えたり、移動したりできる

f:id:takahiro-f:20170303185756j:plain

  • 良い点(池尻セレクトハウス)
    • アットホームで、落ち着ける
    • 許容できる人数の幅が広い
    • 立地、値段
    • オプションでゴミの廃棄をお願いできる
    • 人数に応じたレイアウトをしてくれる
    • 花見できる
  • 考慮点
    • あんまりどんちゃん騒ぎはできない
    • あまり遅い時間まではできない(今回借りた場所は21:00まで)

ケータリングでベジタリアン用のメニューとピザ頼んだ

今回は、参加するメンバーの中にビーガンの方が何人かいる予定でしたので、
この方法を選びました。
ビーガンの方でも食べられるものを頼みつつ、その他の人も満足できるものを用意したい。
という思いがあって、今回レンタルスペース×ケータリング形式にしました。

ただ、ベジタリアン・ビーガン対応のものを探すのにはちょっと苦労しました。
特に、値段の面が難しいです。東京にあるビーガン対応のお店は、
素材にこだわっているお店が多く、素敵なお店はあるのですが、反面価格も高く、
こういった飲み会で利用するにはやや敷居が高いという印象です。
人数が増えればもう少し選択肢が増えるかな、、というところです。
(ただ、僕の調べが足りない所も多々あるので、もしおすすめのお店があれば是非教えて頂きたいです)

今回は、みどりえ(Midorie)さんのベジタブルメニューからいくつかオーダーさせて頂きました!

オーガニックレストランみどりえの無添加宅配弁当・ケータリング|東京
ベジタリアン/マクロビオティック/ヴィーガンメニュー/宅配弁当・ケータリング 東京

  • 今回開催する場所(池尻セレクトハウス)から比較的近く、配送料無料の敷居が低かった
  • 最低発注金額の敷居が低かった(10,000円以上)
  • 美味しそう笑
  • 量がしっかりめ

最低発注金額は今回肝でした。
最低発注金額が50,000円とすると、20人の参加で1人あたり2,500円が抑えられてしまいます。
そうすると、今回の人数だとどうしても他のメニューを他のお店で頼む、ということがやりづらくなります。(予算を出来るだけ抑えたい、というのもあったので)
また、料理が足りないっていうことにならないようにするのが本当に毎回苦心する所なので、この点も嬉しい所です。

さらに、ドミノピザでピザを頼みました。
ピザは具材でいろんな人の要望を割と柔軟に対応できると思います。
今回は金曜日開催だったのですが、奇跡的にミステリーディールで

  • MYSTERY DEAL ピザ2枚で50%OFF

f:id:takahiro-f:20170305210603p:plain
一番欲しいやつを引き当てました笑
これはちょっと運要素が強すぎますが、使えない場合は直接受け取りにいくか、他のクーポンを探したりで、ある程度は安くできると思います。
今回はピザ7枚頼んで、-12,663円。アツすぎる・・・

プレーンピザからチーズを抜く + ウルトラクリスピー

あと、今回は頼んだピザも一工夫しました。

  • プレーンピザからチーズを抜いてウルトラクリスピーにして、原材料から乳製品を抜く

というテクニック。
プレーンピザはトマトソースとチーズだけの状態なんですが、
さらにそこからチーズを抜くことができます。

f:id:takahiro-f:20170305210537p:plain

f:id:takahiro-f:20170305210549p:plain

f:id:takahiro-f:20170305210528p:plain

これではれて乳製品をカットできた、、、と思って原材料を見たのですが、
まだ乳製品が入っています。

f:id:takahiro-f:20170305210519p:plain

確認したところ、生地に入ってるとのこと。確かにそうか、、
ただ、"ウルトラクリスピー"には使ってないとのこと。

ということで、ウルトラクリスピーを抜くことで、原材料から乳製品も抜くことができました!
あとは野菜をトッピングすることで、ベジ対応出来ました!

f:id:takahiro-f:20170305210509p:plain
f:id:takahiro-f:20170305210503p:plain

f:id:takahiro-f:20170305214224p:plain

※ただ、注意点なんですが、厳密に制作過程において混入しないことを保証しているわけではないようです。ここでいう▽に該当するものだと思います。(但し、このページにはプレーンピザからチーズを抜いた場合のものは書いてないですが)
www.dominos.jp


ビーガンの方でも、こういったことにどれほど神経質かは差があると思います。
ので、事前に説明して大丈夫かどうか聞いておくのがいいです。

追伸
そもそも美味しいのか?それ。って声を結構頂いて不安だったんですが、
食べてみてびっくり。
美味しい・・・!!
チーズ入ってない分、さっぱり食べられるし。
全然ありってことがわかりました。
これは大きな収穫…!!

飲み物はカクヤスで

お酒はカクヤスで頼みました。
当日発注でも配達してくれるフットワークの軽さが最高です。
ケータリングだと、飲み物代はかなり安く抑えられます。
どれくらい飲むかにもよりますが、今回は一人平均600~700円くらいですみました。
www.kakuyasu.co.jp


今回気をつけたこと

  • レンタルルームなので、部屋汚したくない
  • 赤ワインはこぼされるの怖いので、コスパ悪いけど200m位の小さい瓶のやつを少しだけ頼んで、瓶もってもらう形式に。(出来るだけグラスとか紙コップに注がない)
  • ソフトドリンクも出来るだけ500mlのペットボトルにして、2Lは水とお茶だけにしました

やってみて

今回かかったお金

  • レンタルスペース代 : 約18,000円
  • 食事代(ピザ) : 約13,000円
  • 食事代(ベジ) : 約17,000円
  • 飲み物代 : 約14,000円

合計、約62000円
参加者、約20名なので、だいたい一人あたり"3000円弱"の計算になります。
安い…!!

詳細

ピザ
みどりえ

商品名:天然酵母・フムスのベジタリアンサンド(10人分)

  • 数量:4個

商品名:テンペときのこのステーキ マスタード醤油ソース(10人分)

  • 数量:1個

商品名:ジェノベーゼ有機ポテト豆乳マヨサラダ(10人分)

  • 数量:1個
カクヤス

ビールはもうちょっと多めにすべきでした…

  • 商品名:ニッカ シードル・スイート 200ML
    • 数量:2本
  • 商品名:カルピス ウォーター 500ML
    • 数量:3本
  • 商品名:キリン 氷結グリーンアップル 350ml缶 350ML
    • 数量:3缶
  • 商品名:割り箸元禄 20膳 20ゼン
    • 数量:2個
  • 商品名:サンライズ カベルネS / コンチャ・イ・トロ (ベビー)スクリューキャップ 187ML
    • 数量:2本
  • 商品名:サントリー オールフリー 350ML缶 (ノンアルコール) 350ML
    • 数量:1缶
  • 商品名:綾鷹 上煎茶 2L 2L
    • 数量:1本
  • 商品名:サンナップ ホワイトプレート (20cm紙皿×10枚入り) 20cm*10マイ
    • 数量:4袋
  • 商品名:サンナップ プラストカップ (215ml×10個入り) 215ML*10コ
    • 数量:6袋
  • 商品名:グリコ ポッキー チョコレート 9袋 9フクロ
    • 数量:2個
  • 商品名:K-Price クリーン・アイス (ロックアイス・氷) 1.1KG
    • 数量:2個
  • 商品名:ゴミ袋 【45L用×10枚】 45L*10マイイリ
    • 数量:1個
  • 商品名:サントリー ほろよい 白ぶどう 350ml缶 350ML
    • 数量:2缶
  • 商品名:サントリー ブラッドオランジーナ PREMIUM 420ML
    • 数量:3本

合計:14,440円

良かったこと

  • 直前で結構な人数の変動があったが、基本的に1人あたりの料金が変動するだけで、かなり気軽に直前キャンセルを受け入れられる、平和な心でいられる笑
  • お酒とピザは当日発注が出来るので、ギリギリまで量の調整ができる
  • レンタルスペースが21:00までだったので、割り切って、かなり早めに開始して、かなり早めに終わった(18:45 - 21:00)のが良かったかも
  • こういう飲み会では、めちゃくちゃ美味しいものを頼むよりも、ある程度の価格で、みんなが満足できる方がいいかと(1次会として)
  • ベジタリアン、ビーガンの方でも食べられるものが全体的に多かったので、彼らには好評。
  • レンタルスペースがオシャレで、和室もあって、外国勢の皆さんは楽しんで頂けたようです。
  • 実は、1次会のあとでたまたま残ってた人たちと2次会に行きました。たまたま日本人だけだったので、ローストビーフ食べました笑。1次会はみんなでやって、少し早めに終わって、趣向の合う人たちで食べたいもの食べる、はいいかもしれません。
  • 普段のコース料理系の飲み会よりは安くなった!

課題

  • コスパの面で、ドミノピザに助けられた感すごい。毎回だと飽きるかも
  • スペースマーケットで予約して管理者の人とやりとりすることとか考えると、まだちょっと海外の人自身が同じような予約をして企画するのは難しい
  • 幹事の負担がまだ普通の飲み会よりちょっと多いかな(慣れればもうちょい楽かな
  • かならず会社の近くに、都合のいいスペースがあるわけではないの、、かも。(結構あるけど)
  • 早く始めて早く終わるという飲み会スタイルが必ずしもできるとは限らない。

せっかくの飲み会、みんなが気持ち良くコミュニケーションできる場になりますように。