この記事は BASE Advent Calendar 2019 の10日目の記事です。 devblog.thebase.in こんにちは、はじめまして。 SREの相原です。 BASEには2019年9月に入社し、今月で4ヶ月目に突入しました。 SREでは各々の改善業務のほか、日々の問い合わせや依頼業務、トラブル対応など、突発的に発生するタスクがあります(数はとても少ない)。 これはどのような業種、職種においても言えることかと思いますが、 突発的かつ迅速に対処しなければならないタスクは、 担当が特定の人(その問題に知見がある人や、問題解決力が高い人)に偏ってしまう傾向にあります。 幸いBASEでは、各メンバーが主体的にボールを拾っていく文化があったため、大きな問題にはなっていませんでしたが、 私が入社した時点でSREメンバーが6人と増えてきたこともあり、試しに当番botを導入することになりました。 当番botについて 当番は問い合わせなどに対して窓口としての機能を持つ(必ずしも1人で解決する必要はない) 当番にはメインとサブを設定し、メイン当番が休みの時や、手が回らないときはサブが対応する 当番は週ごとに切り替わる 当番の通知はslackでおこなう こんな感じで当番をお知らせしています。 良かったこと チームとして: 対応するタスクの偏りが少なくなった もともと自主的に拾う文化があったとはいえ、それぞれの得意領域や興味はバラバラなのでどうしても対応するタスクの種類は多少偏ります。 当番botを始めることによって、この偏りが少しなくなったと感じています。 個人として: 心理的なブレーキがなくなる これは入社したばかりの私だからこそ感じる事かもしれませんが、 問い合わせや突発的に発生するトラブルは初見のものが多く、中には解決までの糸口が見当もつかないものもあります。 そういった問題に手を挙げるのは、人によっては億劫になってしまうかと思います。 しかし、当番という役割があることによって手を挙げざるを得ない状況になるので、 「手を挙げたはいいが、解決できなかったらどうしよう」という心理的なブレーキがなくなります。 このブレーキがなくなったおかげで今では臆することなく、何か問題があればとりあえず手を挙げることができるようになったと感じています。 他メンバー、他チームとのコミュニケーション機会が増える 対応する問題の中には、1人で解決できないものももちろんあるので、他のメンバーに質問することになります。 入社初期の段階で、質問を通してメンバーとのコミュニケーションを図ることができました。 他にも、他チームの方と関わる機会が増えたりと、当番botを導入することで、結果自分のためになることが多くありました。 botの 改善 同じ組み合わせの担当だとマンネリ化してくるので、ランダムに組み合わせを変えていく仕組みを入れたいなと考えています。 また、今のbotはただ当番を報告するだけのものなので、 メッセージに遊び心を入れるなどして、見た人のモチベーションが少しでも上がるような工夫ができればと思っています。 最後に 私は主体的にボールを拾っていくBASEの文化が好きなので、当番botを導入することには少し懐疑的でした。 しかし前述した通り、結果として自分にとってためになったことが多くあったなと感じています。 BASEにはMove Fastという行動指針があります。 これは「速く動くこと。多くの挑戦から多くを学ぶために、まずはやってみよう。」という意味が込められていますが、 今回の当番botを通して、あれこれ悩む前に先に行動することで得られることは多々あるという学びになりました。 明日はプロダクトマネジメントグループの船坂さんとエンジニアの白数さんです。お楽しみに！

この記事はBASE Advent Calendar 2019の9日目の記事です。 devblog.thebase.in はじめまして。BASE株式会社のtatsuと申します。 最近、業務にて guzzle を使う機会がありました。結論から述べますと guzzle のみで実現することは出来ず Amazon sqs を併用するという形で落ち着いたのですが、いくつか知見を得ることも出来たのでその事について書きたいと思います。 主に guzzle/Pool と guzzle/RetryMiddleware の話になります。 最初の壁：ResponseがどのRequestの結果なのか分からん まず並列処理を実装しました。実際のものとは違いますが流れは一緒。 $urls = [ 'https://example_base.in/1', 'https://example_base.in/2', ]; $guzzle_client = new Client(); $requests = function ($urls) use ($guzzle_client) { foreach ($urls as $url) { yield function () use ($guzzle_client, $url) { return $guzzle_client- > postAsync($url); }; } }; (new Pool($guzzle_client, $requests($urls), [ 'concurrency' = > 10, 'fulfilled' = > function ($response, $index) { // dbに保存とか }, 'rejected' = > function ($reason, $index) { // dbに保存,ログ出力とか } ]))- > promise()- > wait(); レスポンスを受け取って保存という段階で 「どのリクエストの結果を受け取っているか分からん。」となりました。 送信は request の生成順に処理されますが、結果はもちろん順不同で返ってきます。 そりゃ並列処理ですからね… この問題の解決策は簡単で、request 生成部分を少し変えるだけ。 $urls = [ 'index1' = > 'https://example_base.in/1', 'index2' = > 'https://example_base.in/2', ]; $requests = function ($urls) use ($guzzle_client) { foreach ($urls as $index = > $url) { yield $index = > function () use ($guzzle_client, $url) { return $guzzle_client- > postAsync($url); }; } }; これで pool の成否処理の第2引数が'index1','index2'といった値になります。何もしないとrequest の生成順に整数が振られますが、上記の様に任意の値を渡すことも出来ます。 ちなみに失敗時の第1引数には基本的に exception が入ってきます。 下記を参考に処理を分けてあげると良いかもしれません。 http://docs.guzzlephp.org/en/latest/quickstart.html#exceptions 二つ目の壁：Retryの度に結果を保持したい 一応の並列処理は出来た。ということで retry についても考えてみます。 guzzle では RetryMiddleware というリトライの方法を標準で用意してくれています。 // clientに設定 $handler_stack = HandlerStack::create(new CurlHandler()); $handler_stack- > push(Middleware::retry(retryDecider(), retryDelay())); $guzzle_client = new Client(['handler' = > $handler_stack]); function retryDecider() { return function ( $retries, Request $request, Response $response = null, RequestException $ exception = null ) { // 最大5回 if ($retries > = 5) { return false; } // 4xx or 5xx はリトライ if ($response && $response- > getStatusCode() > = 400) { return true; } return false; }; } function retryDelay() { return function ($retries) { return (int) pow(2, $retries - 1) * 1000; }; } 上記の例はかなりシンプルですが、リトライの判断部分と待機時間を実装して Middleware::retry() に渡してあげれば良しなにリトライしてくれます。 注意点としては、delay は単位がミリ秒です。timeout は単位が秒なのに http://docs.guzzlephp.org/en/stable/request-options.html#delay ここでまた問題が生じました。ある理由から最終的な成否だけでなく、retry 時の結果も逐一保持したいとなりました。さて困った。 pool の成否へは request がすべき動作が終わってから到達します。つまり retry 時には実行されません。そうなると retry の中で保持を行う必要があります。 retryDecider() で行いたいところですが、どのリクエストの retry なのか判別する必要があります。上記の様に request が入ってきているので、request-header 等に識別子を設定して判別する事も出来ます。ただ、こちら側の都合を request に持たせるのはどうなのかという考えが浮かび別の方法を取ることにしました。 RetryMiddleware を自作してみました。 …こう言うと凄そうに聞こえるかもしれませんが、実際は標準のものをちょっと変えただけです。 全文は長いので変更箇所の辺りだけです。 private function onFulfilled(RequestInterface $req, array $options) { return function ($value) use ($req, $options) { if (!call_user_func( $this- > decider, //$options['retries'], $options $req, $value, null )) { return $value; } return $this- > doRetry($req, $options, $value); }; } 上記と同じ事を onRejected() にも deciderに $options['retries'] (リトライ回数)では無く $options ごと渡す様にしました。 これで request-options に識別子を持たせることでリクエストを判別する事ができる様になりました。request-ooptions は key を既存のものと被らない様にすれば影響はないですし、リクエスト先にも渡ることはありません。 $options['retries'] 自体は $options に同keyが無ければ __invoke() で追加されます。つまり RetryMiddleware の外から操作する事も出来るということでもあります。 少し長くなってしまいましたが、これで pool × retry の実装が出来た！ …と思っていました。この時は 三つ目の壁：PoolとRetryMiddlewareって併用出来ないの＆リトライ中にプロセス死んじゃう 開発の世界で三段オチを味わうことになろうとは…。 それぞれをさっくり解説しますと PoolとRetryMiddlewareって併用出来ないの リトライするテストを書いていたら何かおかしいということで検索したところ、「asyncRequest() と RetryMiddleware を併用すると同期してしまいます」といった情報を見つけました。いやいやいや、そんなはずは…と思いつつ試してみました。 方法は簡単でリクエスト毎にリトライの待機時間を変えてみます。 request1 は[２つ目の壁]にある様に回数に応じてべき秒で増えていき、request2 は2秒固定でリトライを繰り返してみます。並列処理が非同期で行われているのであれば、4回目で順番が入れ替わりrequest2が連続するはずです。結果は…？ 綺麗にrequest1とrequest2が交互に並び続けました。ﾜｰｲ さらに追い打ちをかける様にもう一つ問題が発覚します。 リトライ中にプロセス死んじゃう これは一般的ではない環境での事象ですので詳細は省きますが、あるタイミングで実行中のプロセスが強制的に終了させられてしまうという事がわかりました。終了までに多少の猶予があるのですがリトライの待機時間によっては、待機中に強制終了されてしまい終了に備える事が出来ないのです。プロセスの管理側からの操作なので内部で対策をするにも限界がりそうでした。ちなみに強制終了後すぐに再起動されます。 上記二点の問題が浮上し悩んでいた所、同僚からこんな言葉が(実際にはgitのコメント)…。 「リトライをAmazon sqsに任せちゃうのは？」 …なるほど？ 結果的にこれが自分がとった解決方法となりました。 sqs に関しての説明は長くなってしまうので「便利なメッセージキューイングサービス」とだけ言わせて頂きます。その sqs の機能の一つで遅延機能があります。 https://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-delay-queues.html これと実装してきた guzzle を組み合わせる事で上手くいきそうです。 リトライの判断と待機時間の算出はそのまま使い、失敗してリトライが必要な時に待機時間を持たせて sqs に投げる様にします。 待機自体は sqs でするので強制終了の猶予時間以上の処理は無いので、終了に備える事が出来ます。 イレギュラー中のイレギュラーとはいえ起こり得る事に対処出来て良かった。 まとめ この方法を採った大きな要因として、そもそも作っていたものが sqs からキューを受け取ってリクエストを送るというものだったという事があります。なので sqs の導入コストはほぼ0でした。 そもそも使っていたなら気づけよとも思いますが、こういう時って離れて視野を広くするのがなかなか難しかったりします。 そんな時に第三者の視点から意見を貰えるのは本当に有り難いですよね。同僚の言葉が無ければ時間を掛けて guzzle で頑張っていたと思います。それも不正解では無いと思いますが、今回は sqs との連携を選んで良かったと感じています。また guzzle で色々やったからこそ、それほど苦労せずに連携させられたという事もあるはずです。 長くなってしまいましたが、業務上の課題は積極的にオープンにすると良さそうというお話でした(guzzleどこいった)。 明日は id:beerbierbear と id:yk4o4 の記事です。お楽しみに！

この記事はBASE Advent Calendar 2019 9日目の記事です。 devblog.thebase.in こんにちは、BASE株式会社 ランニング部部長の元木です。 フルマラソンのサブスリー達成を目指して日々トレーニングに励む傍ら、Owners Marketingというチームでサーバーサイドエンジニアもやっております。 前書き 弊社が提供するネットショップ作成サービス「BASE」（以下「WEB」）とショッピングアプリ「BASE」（以下「アプリ」）では、 Amazon CloudSearch （以下「CloudSearch」）を利用して商品の検索機能を提供しております。 当記事では、 CloudSearch のインデックスを更新する処理を、どのようにバッチからワーカーに置き換えたのかをご紹介させていただきます。 この記事は、「 BASE Advent Calendar 2019 」の9日目の記事です。 バッチの何が問題だったのか 商品データは、ショップオーナーさんや購入者のアクションによって刻々と変化していきます。 BASEのシステムは、その商品データの変化を捉えて CloudSearch のインデックスを更新していくこととなります。 CloudSearch のインデックスを更新するのは比較的時間がかかる処理であることと、 CloudSearch には 「更新の頻度が10秒に1回を超えると、スロットリングが発生する場合がある」 という制限があるため、BASE ではバッチプログラムを用いて、非同期でこの処理を実行しておりました。 しかし、バッチ処理には インデクシングが必要な商品数は日々増えていくが、処理をスケールできない DBへの負荷が高い という問題がありました。 試験的に、アプリ側には Amazon SQS （以下「SQS」）をポーリングして CloudSearch のインデックスを更新するワーカーが導入されておりましたが、一部のアクション（商品の登録・更新・削除）しかカバーしておりませんでした。 以下が、切り替え前のシステム構成です。 弊社CTOの  @dmnlk と話した結果、これを以下のような構成に変更することが決まりました。 SQS の前段に Amazon SNS （以下「SNS」）を配置する。 WEB用の SQS を新たに追加する- アプリ側、WEB側ともに、バッチをワーカーに完全に置き換える 以下が、目標とするシステム構成です。 ちなみにこの時の私の Amazon SNS に対する理解度は、こんな感じでした。 次からは、どのような段取りでシステム構成を切り替えていったのかをご説明します。 バッチからワーカーへ 手順1 : Amazon SNS の配置   まず、SQS の前段に SNS を配置し、商品データが更新された際の通知先を SQS から SNS に切り替えました。 アプリケーションの変更点としては、インデックスの更新が必要になるアクションが発生した際の通知先を SQS から SNS に切り替えるだけです。 手順2 : WEB用のワーカーとSQSの配置 次に、WEB用のワーカーと SQS を配置し、ポーリングを開始しました。 まだ、一部のアクションしか SNS に通知されない状況ですので、引き続きワーカーとバッチを並行稼動させています。 WEB用のワーカーを実装する際には、バッチとワーカーが同じ動作をすることを保証するために バッチのテストコードを書く（それまでは無かった） バッチのテストコードとワーカーのテストコードとでデータプロバイダーを共通化し、入力と出力が一致することを保証する といった工夫も行ないました。 SNS と WEB用の SQS を連携させる際も、いきなり全てのイベントを通知させるのではなく、 SNS のメッセージ・フィルタ機能 を利用して通知するイベントを徐々に増やしていくようにしました。 手順3 : Amazon SNS に通知するアクションを増やしていく 次に、SNSに通知するアクションを徐々に増やしていき、最終的に CloudSearch のインデックスを更新する必要のある全てのアクションが SNS に通知されるようにしました。 ここでも、一気に全アクションを通知するよう変更するのではなく、段階的に通知するアクションを増やしていくようにしました。 実は、手順2, 3 を実施していく過程で何度かWEB用のワーカーに不具合が見つかり、改修を行なっております。 しかし、バッチとの並行稼動を続けていたことと、ワーカーの仕事量を少しずつ増やしていくようにしていたため、大きな問題に発展することはありませんでした。 手順4 : バッチの退役 全てのアクションが SNS に通知されるようになったところでバッチを退役させ、すべての作業が完了しました。 まとめ サービスが成長していくにつれて、以前は問題なかったシステムから問題が生じるようになることは往々にしてありえます。 一方で、システム構成の変更は比較的リスクが高い上に（何か新しい機能を提供するわけではないため）地味な作業であるため、ついつい、問題が大きくなるまで放置してしまいがちです。 私としては、作業の段取りを工夫することでリスクを最小限に抑えつつ、サービスの成長に応えられるシステムを構築し続けていきたいと考えております。

この記事はBASE dvent Calendar 2019 8日目の記事です。 devblog.thebase.in こんにちは、はじめまして。 2019年8月に入社したデザイナーの石井です。 入社してからEコマースプラットフォーム「BASE」のWebやアプリ、グラフィックなど、様々なデザインを制作してきました。 各プロダクトのデザイン制作時、UIを作成する際にチームのコミュニケーション、共通理解、制約条件をそろえてデザインしていくことが大変重要です。 それらをより活発に、より洗練されたものにするために最近ではデザインシステムの構築に励んでいます。 今回はショッピングアプリ「BASE」においてのデザイン言語システムの初期の段階（β Version）についてお話をさせていただければと思います。 デザイン言語システムの必要性 僕は過去数年間ほどWebとモバイルのアプリケーションの構築と設計を続けてきました。エンジニアやディレクターなど様々なメンバーと協力してプロダクトを作る経験をしてきた中で、より効率的にプロダクトを成長させるための設計システムを構築する方法を学んできました。 デザイン言語システムに求められる要素はたくさんあります。タイポグラフィ、レイアウトとグリッド、色、アイコン、コンポーネント、コーディング規約から、音声とトーン、スタイルガイド、ドキュメントなど多岐にわたります。 そして各デザイナーの考えをデザインシステム上で他のメンバーに適切に共有し、一貫性を保てるように設計する必要があります。そして、チーム全体でデザインシステムを改善していくことで、より良いプロダクト作りを支えていく基盤となります。 デザイン言語システムがあることで、個別のUIを考える時間を短縮し、どのようなユーザー体験を作るかを考えることに集中できます。また、デザイナー間の共通認識ができることで、複数のデザイナーが同じプロダクトの制作に関わる際にも一貫したユーザー体験の提供することにつながります。 ショッピングアプリ「BASE」のデザイン体制 僕が入社するまで、ショッピングアプリ「BASE」の担当デザイナーは1人でした。その時点ではデザイン言語システムはありませんでした。 入社後、僕もアプリのデザインを担当することになり、また今後新たに入社してくるデザイナーがアプリを担当する可能性も鑑み、デザイン言語システムの構築を始めました。 どうやって構築していったか デザイン言語システム構築を開始する前に、基本的なスタイルガイドを作成しました。ここで、タイポグラフィ、色、アイコン、情報アーキテクチャを大まかに定義しました。 こちらは、タイポグラフィーの定義、カラーの使用パターンと洗い出し、スペーシングの確立後のスタイルガイドです。 さらにiOSおよびAndroid共通のアイコンのガイドラインを確立したものがこちらです。 標準化されたコンポーネントの定義 従来、多くのスタイルガイドにおいて、コンポーネントをアトミックコンポーネントとして定義し、それを使用してより複雑な分子を構築されているのを見てきました。 理論的には、これは首尾一貫した柔軟なシステムを作成するためにうまく機能します。 しかし実際には、これらの再利用可能な原子がさまざまな方法で使用され、あらゆる種類の分子を作成できることがよくあります。これは一貫性のあるデザイン言語システムの維持を妨げ、一貫したユーザー体験の創出を阻害してしまう可能性があります。 これらのコンポーネントを作成する際、ライブラリと呼ばれるマスターファイルにそれらを集約しました。またマスターファイルの更新は僕自身のみで行えるようにしています。 ライブラリを構築している間に、個々のコンポーネントを類似のアイテムを含むアートボードに整理し始めました。 これらのアートボードは、一般的なカテゴリ別にナビゲーション、マーキー、コンテンツ、画像等に分類しました。 これらのコンポーネントをiOSおよびAndroid用に1セット作成しました。タブレット用のコンポーネントはモバイルのコンポーネントとほぼ同じなので、技術的なレベルでは、コードは2つの異なるスタイルがあれば済みます。 デザイナーは、共通のコンポーネントを使用して画面を設計することができ、iOSやAndroidだけでなくさまざまな画面サイズに簡単に適応させることができるようになります。 このコンポーネントスタイルガイドはまだ議論が始まったばかりでお見せできるものはありませんが、今までチーム内で共通のコンポーネントの共通理解や作業方法の一貫性がなかったのでそこをシステム化に現在取り組んでいます。 おわりに アプリのデザイン言語システムの発展はまだまだこれからです。引き続きMove Fastなプロダクト作りの基盤の整備に努めていきます。 明日はエンジニアの齋藤さんと元木さんです！

この記事はBASE Advent Calendar 2019の8日目の記事です。 devblog.thebase.in エンジニアの右京です！ みなさん！ Storybook は使っていますか？BASE では UIコンポーネントの社内展開 はもちろん、日々の業務の中でもサンプルの実装を共有したりするために Storybook が使われています。BASEではこれを「特定のリポジトリにコードをコミットすると、自動的に社内向けサーバーへデプロイされる仕組み (ようするに社内 GitHub Pages ですね)」を利用して社内共有しているのですが、毎度のセットアップが大変なので Gtihub Actions を使ってお手軽に設定できるようにしてみたよ、という内容です。 github.co.jp TL;DR 社内用向けドキュメントサーバーへのデプロイを他のリポジトリから使いやすいように Action 化して配信するようにしました プライベートリポジトリにある Action は直接参照することができないので Personal access token と npx を使います CircleCI から GitHub Actions に変更することで様々なイベントにフックすることができ、柔軟性のあるデプロイが可能になりました デプロイ(コミット)の Action 化 これまでこのサーバーを利用したい時は、利用側の CircleCI で専用のリポジトリを clone して commit を作って push して...といった処理を用意する必要がありました。利用するプロジェクトが増えていく中、この利用法のスケールのしにくさに問題を感じていたため、GitHub Actions でスパっといけないか？と思ったのが今回のスタート地点です。 このエントリでは今後はこのリポジトリのことを「static-pages-repo」と呼ぶことにします。 まず、前提として static-pages-repo は master に push されると public ディレクトリ以下が自動で社内向けのサーバーへデプロイされるようになっています。 └── public ├── webservice1/master/... ├── webservice1/hogefuga/... ├── webservice2/master/... ├── ... └── index.html // デプロイされているURLのリストが入っています 今回作る Action では、上記の構成に沿って以下のフローを実行します この配置に合わせて利用側から成果物をコピー コピーした成果物をコミット アクセスしやすいように public/index.html を更新 リモートへ push これを行うためには3つの引数が必要そうです。 public の配置を決定するためのプロジェクト名(prefix) public の配置を決定するためのブランチ名 成果物(コピー元)のパスの指定 つまり Action としてはこんな感じに利用できるのがよさそうです。 - uses : static-pages-repo with : project : webservice1 branch : feature/hogefuga source : dist 早速実装に...と行きたいところですが、気をつけるべき点が2つあります。 プライベートリポジトリのアクションは直接実行することはできない Workflow 内で他のリポジトリを扱う場合は secrets.GITHUB_TOKEN では権限不足 それぞれ見ていきます。 プライベートリポジトリのアクションは直接実行することはできない パブリックなリポジトリの場合は リポジトリ名やパスを指定することで 直接他のリポジトリから Action を参照して、利用することできます。ですが、プライベートリポジトリの場合はこの方法は使えないため、回避方法を考える必要があります。 static-pages-repo を clone...? と思いましたが、それだとあまり現状と変わらない...ので多少見栄えがよくなりそうだと npx で Action をインストールできるようにしてみることにしました。 一度 npx 経由で Action をコピーしてしまうことで、 自身のリポジトリ内の Action として実行します。 - run : npx https://github.com/baseinc/static-pages-repo install - uses : ./.github/actions/static-pages-repo Workflow 内で他のリポジトリを扱う場合は secrets.GITHUB_TOKEN では権限不足 GitHub Actions を使ったことがある人は知っているかもしれないのですが、元々 Workflow で使える変数として secrets.GITHUB_TOKEN が用意されています。通常であれば、このトークンを使えばプライベートリポジトリでも GitHub API を呼び出したり、リポジトリに Git での書き込みができるのですが、残念ながらこのトークンではリポジトリを跨いだ操作を行うことはできません。 これは代わりに Personal access token (以下PAT) を使用することで解決します。 actions/checkout にもこれに関する記述 があるので参考にしてみてください。 実際に Action を作る では、以上の2つの注意点に気をつけながら実際に Action を作っていきます。 Action の開発方法には Docker コンテナ版 と JavaScript 版 があり、今回は Git での操作がメインになりそうだなという理由でシンプルに実装できそうなDockerコンテナ版を選択しました。 公式ドキュメントにそってまず Dockerfile を作ります。alpine でもよいですが、 public/index.html を Node.js で作成しているため、 node:12 を選択しています。 ファイルの置き方ですが、これらを直接 Actions が実行するわけではないので（コピー元）、安直に action というディレクトリを作って配置することにしました。 FROM node:12 COPY entrypoint.sh /entrypoint.sh ENTRYPOINT ["/entrypoint.sh"] 次に action.yml を作ります。action.yml は引数や出力、実行方法を設定するためのファイルです。 name : 'static-pages-repo' description : 'deploy static pages' inputs : # ここに追加したキーが引数となります pat : description : 'Actionで必要になるPAT' required : true project : description : 'ディレクトリ名のprefix' required : true branch : description : 'ディレクトリ名' required : false default : 'master' source : description : '配信したいコンテンツへのパス' required : true outputs : url : description : 'デプロイ先となるURL' runs : using : 'docker' image : 'Dockerfile' args : - ${{ inputs.pat }} - ${{ inputs.project }} - ${{ inputs.branch }} - ${{ inputs.source }} 最後に entrypoint.sh を作って実際に動かすスクリプトを書いていきます。PAT を受け取って、static-pages-repoを操作していきます。 #!/bin/sh -l # 作業用のリポジトリをクローンします、PAT($1)を付加していることに気をつけてください git clone https:// $1 @github.com/baseinc/static-pages-repo.git .github/tmp/repo # project/branchなディレクトリを作って成果物をsourceからコピーしてきます mkdir -p .github/tmp/repo/public/ $2 / $3 cp -rT $4 .github/tmp/repo/public/ $2 / $3 cd .github/tmp/repo # 配置されたファイルへのリンクを含む public/index.html を生成します npm ci npm run build-index # 最終的に差分が生まれていれば git commit して push します git add . git config user.name actions git config user.email actions@binc.jp if git commit --dry-run > /dev/null ; then git commit -m " Update $2 / $3 " git push origin HEAD fi git push https:// $1 @github.com/baseinc/static-pages-repo.git master # このようにして値を出力しておくと、次の step でこれを元に検証したりすることができます echo " ::set-output name=url::https://static-pages-repo.com/ $2 / $3 / " Action を配信する npx スクリプトを作る npx にあまり馴染みのない方もいるかもしれませんが、簡単にいえば「インストールせずに一度だけ使えるパッケージ」という感じでしょうか。 package.json を作って以下のようなスクリプトで Action をローカルにコピーしています。 #!/usr/bin/env node const path = require( 'path' ) const fs = require( 'fs-extra' ) const src = path.resolve(__dirname, '../action' ) const out = path.resolve(process.cwd(), '.github/actions' ) ;(async() => { await fs.ensureDir(out) await fs.copy(src, `$ { out } / static -pages-repot`) } )() これを上のものと合わせると、最終的には他のリポジトリからこのような step で static-pages-repo デプロイすることができるようになります。 - run : npx https://${{secrets.PAT}}@github.com/baseinc/static-pages-repo install - uses : ./.github/actions/static-pages-repo with : pat : ${{ secrets.PAT }} project : webservice source : dist 便利そうに見えませんか？実際に PAT を設定するのは、利用側であることに気をつけてください。 これで static-pages-repo 側は完成です！ ここまでのディレクトリ構造はこのようになっています。 ├── action │ ├── Dockerfile │ ├── action.yml │ └── entrypoint.sh ├── bin │ └── install.js // npx で実行されるスクリプト ├── webroot │ ├── webservice1/master/... │ ├── webservice1/hogefuga/... │ ├── webservice2/master/... │ ├── ... │ └── index.html ├── README.md ├── package-lock.json └── package.json 実際に Action を使ってデプロイする これで準備が整ったので、あとは各リポジトリに導入するだけです！ 今回は、実際に BASE で運用しているパターンから3つをご紹介します。 master に push されたらデプロイ Pull Request が作られたらデプロイ Pull Request に特定のコメントがついたらデプロイ master に push されたらデプロイ 一番簡単でわかりやすい、馴染みのある感じだと思います。 ほとんどのリポジトリは、master にマージされたときに更新を実行するようにしています。 name : deploy master on : push : branches : - master jobs : build : runs-on : ubuntu-latest steps : - uses : actions/checkout@v1 - uses : actions/setup-node@v1 with : node-version : '12.x' - uses : actions/cache@v1 with : path : node_modules key : ${{ runner.os }}-node-${{ hashFiles('**/yarn.lock') }} restore-keys : | ${{ runner.os }}-node- - run : yarn install --frozen-lockfile - run : yarn storybook -o dist - run : npx https://${{secrets.PAT}}@github.com/baseinc/static-pages-repo install - uses : ./.github/actions/static-pages-repo with : pat : ${{ secrets.PAT }} project : webservice source : dist Pull Request が作られたらデプロイ UIコンポーネントのような基本的に Storyboard がセットになるものはこれを設定しています。 Pull Request が Open されると同時にデプロイされるため、レビューの際にはスムーズに Storybook を確認することができます。 name : open pull-request on : pull_request : types : [ opened, reopened ] jobs : build : runs-on : ubuntu-latest steps : - uses : actions/checkout@v1 - uses : actions/setup-node@v1 with : node-version : '12.x' - run : yarn install --frozen-lockfile - run : yarn storybook -o dist - run : npx https://${{secrets.PAT}}@github.com/baseinc/static-pages-repo install - id : deploy uses : ./.github/actions/static-pages-repo with : pat : ${{ secrets.PAT }} project : webservice branch : ${{ github.event.pull_request.head.ref }} # 実行時の event を受け取って使うことができるため、ここから branch 名を取得して決定しています source : dist - if : "steps.deploy.outputs.url" # 前の step が成功したときに発行される url があったら、PRのコメントにURLを書き込みます env : URL : ${{ steps.deploy.outputs.url }} API_ENDPOINT : ${{ github.event.pull_request.comments_url }} GITHUB_TOKEN : ${{ secrets.GITHUB_TOKEN }} # ここは同じリポジトリ内なので GITHUB_TOKEN でアクセスできます run : | curl -X POST -H "Authorization: token ${GITHUB_TOKEN}" -i ${API_ENDPOINT} -d "`printf '{ \" body \" : \" deploy to %s \" }' ${URL}`" Pull Request に特定のコメントがついたらデプロイ 必ずしも Storybook が必要ではないアプリケーションのリポジトリでは、Pull Request にコマンドコメントを書くことで任意のタイミングでデプロイが行えるようにしています。 これには issue_comment というイベントを使うのですが、これは特定ブランチには紐づかないイベントで、デフォルトブランチを起点に実行されるため少し複雑です。 name : on comment pull request on : issue_comment : types : [ created ] jobs : build : runs-on : ubuntu-latest steps : - id : check # コメントに deploy-storybook の文字列が含まれていて、pull_requrest なら実行します if : "contains(github.event.comment.body, 'deploy-storybook') && github.event.issue.pull_request" env : API_ENDPOINT : ${{ github.event.issue.pull_request.url }} GITHUB_TOKEN : ${{ secrets.GITHUB_TOKEN }} run : | # pull_request のデータを API 経由で取得して、ブランチ名を特定します branch=`curl -X GET -H "Authorization: token ${GITHUB_TOKEN}" ${API_ENDPOINT} | jq -r '.head.ref' ` echo ::set-output name=branch::$branch # このようにすることで id(=check) に紐づく outputs を step からも書き出すことができます # これ以降は branch が特定できていたら続行します - if : "steps.check.outputs.branch" uses : actions/checkout@v1 with : ref : ${{ steps.check.outputs.branch }} - if : "steps.check.outputs.branch" uses : actions/setup-node@v1 with : node-version : '12.x' - if : "steps.check.outputs.branch" run : | yarn install --frozen-lockfile yarn storybook -o dist npx https://${{secrets.PAT}}@github.com/baseinc/static-pages-repo install - id : deploy if : "steps.check.outputs.branch" uses : ./.github/actions/static-pages-repo with : pat : ${{ secrets.PAT }} project : webservice branch : ${{ steps.check.outputs.branch }} # 前の step で特定した branch 名を使用します source : dist - if : "steps.deploy.outputs.url" env : URL : ${{ steps.deploy.outputs.url }} API_ENDPOINT : ${{ github.event.issue.comments_url }} GITHUB_TOKEN : ${{ secrets.GITHUB_TOKEN }} run : | curl -X POST -H "Authorization: token ${GITHUB_TOKEN}" -i ${API_ENDPOINT} -d "`printf '{ \" body \" : \" deploy to %s \" }' ${URL}`" 一つ気をつけるべき点として、 job 自体にも if を設定でき もっと簡潔にかけそうなのですが、if が通らなかった場合に job が 0個となり Workflow 自体が失敗したことになってしまいます。 また、実際にはこれらと「 Pull Request が close された際にディレクトリを削除する Action 」をあわせて運用しています。 めでたしめでたし Storybook を Move Fast にデプロイできるようになったことで、 Speak Openlyな開発 にまた一歩近くことができたと思います。 お気づきの方もいると思いますが、単なる静的ファイルホスティングなので Storybook 以外にももちろん使うことができます！ 明日は id:kmotoki と id:tatsuta2 です！

はじめに この記事はBASE Advent Calendar 2019の7日目の記事です。 devblog.thebase.in こんにちは、BASE投資部部長の菊地です！2019年は多くのBASE社員のマネーリテラシーを高めることができて、なかなか満足のいく一年となりました！ さて、2019年業務の方がどうだったか振り返ってみると1月にエンジニアリングマネージャー(以下EM)に就任し、7月からは約20名のエンジニアが所属するService Devというセクションのマネージャーに就任しました。カレンダーを振り返ってみると今年は1on1を400回、採用面接は70回ほど行ったりとマネージャー業にどっぷりと浸かった一年となりました。 巷ではピープルマネジメントに費やす時間が増え、コードを書く時間が減ることが多いEMに対してネガティブな印象を持つエンジニアが多いようです。 しかし私はこの一年間EMとしての役割を果たすことでやりがいを感じることがたくさんありました。みなさんにEMって楽しそうだなと思って頂けたら嬉しいと思い、そのいくつかを紹介させて頂こうと筆を取りました。 BASEにおけるEMの役割 昨年、私の上司である@fshinが「 エンジニアとしてワクワクし続けるためのエンジニアリングマネージャという役割分担 」という記事を書いてEMの役割について言語化しています。 この記事にあるようにBASEのEMに求められる役割を一言で言うと 「事業、プロダクトに貢献しながら、チームのエンジニアの活躍にコミットすることで、メンバーの評価を上げること」 ということになります。 会社によってはEMが技術をリードする責任も求められる場合もあるようですが、BASEではエンジニアの上位職としてEMの他に技術でリードするテックリード(以下TL)という役職が存在するのでEMはピープルマネジメントだったりに専念することができます。(逆に言うとTLはピープルマネジメントを求められないので、技術に専念することができます) 私がやりがいを感じるとき さてここからは私がEMをやっていてやりがいを感じる瞬間を、それにまつわる取り組みなどを交えながら紹介させて頂きます。 チームメンバーを輝かせられたとき EMの仕事をマネジメントというとなんだか堅苦しい印象ですが、より強いエンジニア組織を作る、メンバーの成長を支援して市場価値を高めるという側面ではプロデューサーと呼んだ方が個人的にはしっくりきます。もっと輝けるのではと思った人をプロデュースして、それまで以上の輝きを放つようになったときに私はEMとしてのやりがいを感じます。 例えば黙々とコードを書いていてあまり目立たっていないと感じていたチームメンバーが、私が背中を押すことでグングンと成長し今では社内の誰からも信頼され頼られる存在に成長した人がいます。これぞEM冥利に尽きる瞬間です。私は彼の社内でのプレゼンスを上げるために次のような働きかけをしました。 アイコン重要 BASEではSlack, G Suite(GmailやGoogle カレンダー等), Asana, Kibelaなどなど多くのツールを使用しています。社員数が100人を超え社内の認知を得ることが難しいフェーズになっているので、アイコンにこだわりを持つことは社内で認知されるために非常に重要だと考えていました。 しかし当時彼はアイコンを何も設定していませんでした。そこで私は「アイコンは必ず設定しよう」、「各ツールでアイコンを統一しよう」、「アイコンはキャッチーなものにしよう」とアドバイスをしました。その結果今では社内のほとんどの人が彼のアイコンを見れば彼のことを想起できるようになり認知度が飛躍的に高まりました。 他部署の人との関わり重要 日常的にカスタマーサポートチーム等の他部署からお問い合わせ調査依頼がやってきます。こういう依頼があった際はなるべく拾いにいくように伝えました。理由はお問い合わせの調査をすることでBASEのサービスやシステムの理解が深まりますし、他部署のメンバーからの信頼を得ることができるからです。 最初の頃は積極的には拾いにいっていなかったので、私が拾って彼に振っていたのですが、いつしか抵抗がなくなったのか今では自ら進んで拾いに行ってくれるようになりました。自分からタスクを取りにいくような働き方になった結果、多くの人から頼られる存在になりました。 理想としているチームに近づいているのが目に見えたとき 突然ですが、 wevox というサービスをご存知でしょうか。wevoxとは「定期的なアンケートを実施することで、社員の仕事や会社とのエンゲージメントを数値化しよう」というサービスです。 BASEの場合は3ヶ月に一度全社員からアンケートをとって、「上司との関係性は10点中9点で世の平均よりも良好です」といったようにたくさんの項目が個人レベルで数値化されマネージャーに共有されます。（匿名と実名での回答が設定でき、BASEでは現在実名で回答する形式をとっています） 私は「明るく、楽しく、健康的」なチームを目指しているので、wevoxでそういった項目の数値が高かったり前回よりも改善されていると自分の日々の取り組みの成果が現れ、目指しているチームに近づいているのだなと喜びを感じます。 メンバーと頻度多くコミュニケーションを取ることでお互い何でも言い合える関係を築くことがEMにとって何よりも大事だと考えているので、そのためにいくつかの取り組みを行なっています。 1on1 もはや定番になっているかもしれませんが、1on1がEMにとって最も重要な業務であると考え、全ての業務より優先して全メンバーと毎週30分行なっています。主に1on1のバイブルとなっている『 ヤフーの1on1 』に書かれている下記のようなことを実践しています。 この本には1on1の目的は「メンバーの才能と情熱を解き放つこと」と書かれていますが、まずはシンプルに雑談でもいいからとにかく毎週30分行うということに専念しました。 定番の質問 自分が部下として1on1をしていた時を思い返しても「何かお困りごとはありますか？」といきなり聞かれてもなかなか思いつかないものでした。ですので「以下の質問を毎回聞くので何か考えてきてください」とチームメンバーに伝えるようにしています。これらの質問も『ヤフーの1on1』を参考にしたものです。 今日は何の話をしましょうか？ 何かお困りごとはありますか？ 私(EM)にできることはありますか？ 毎回聞くからねと宣言することによって、1on1の時にメンバーが議題を用意してくれるということが増え、1on1の充実度が上がったように思います。 予習 1on1を行うにあたって1人につき15分ほど予習を行なっています。チームメンバーには毎週末に週報を書いてもらっているので週報を確認して一週間にどのようなことをしていたのか把握したり、タスクの進捗は順調そうか確認したり、これまでの1on1の議事録を見返したりすることで話したい内容をある程度箇条書きして臨むようにしています。そういった準備をすることでチームメンバーが今困っていることなどに気づきやすくなるといった効果があると感じています。 議事録 毎週10人近くのメンバーと1on1を行なっていると、誰が何を言っていたのか分からなくなることがあります。また自分が誰に何を言っていたのかも分からなくなることがあります。そのようでは信頼を積み重ねることは難しいと感じ、毎回議事録をとって、終わったら議事録の内容をSlackでDMするようにしています。信頼を積み重ねるにはとても大事だと認識しているのですがけっこうサボりがちなので反省しています、2020年はサボらないで頑張りたい。 ニチレイ（日例） 毎日12時からスタンディング形式でチームメンバーが集まって今やっていることや困っていることを5分ほどの時間を使って共有しあう時間をとっています。議論したり雑談をしたりとチーム内のコミュニケーションを毎日作れるのでニチレイの重要度はとても高いと考えています。 Unipos Unipos というのは社内のメンバー間で感謝を送り合うサービスです。 感謝することも、感謝されることもやりがいを持って業務に取り組むためにはとても重要であると考えているのでチームのメンバーには感謝のハードルを極力低く設定して、たくさん感謝を送り合うように伝えています。 チームメンバーを採用できたとき BASEではスクラム採用に取り組んでいて、エンジニアの採用にはEMがフルコミット(スカウト、カジュアル面談、書類選考、面接、オファー面談、採用会食など盛り沢山)しています。BASEのスクラム採用について興味のある方は弊社採用マネージャーの 米田が登場している記事 をご参照ください。 さて、採用活動がEMにとって最重要タスクであることは言うまでもありませんが、一方でなかなか成果に結びつきにくいものです。100人カジュアル面談を実施して2,3人入社して頂ければ御の字といったところではないでしょうか。 BASEから内定をお出ししている方は他社でも複数内定が出ていることがほとんどです。複数内定が出ている中からBASEを選んで頂けるように毎度毎度全社総動員でアトラクトをしています。そうやって最終的にBASEを選んで頂けた際にはみんなで喜びます。この瞬間がEMとしてやりがいを感じる瞬間です。 採用活動に携わるようになって良かったと思う点をいくつか紹介します。 視座が上がった 自分が面接官を担当するということはBASEのサービスであったり、ビジネスモデル、社内環境のことなどを魅力的に語れる必要があります。 また候補者からは以下のような質問をはじめ、様々な質問をされます。これらに自信を持って答えられなければ候補者に不安を与えてしまうことになり、BASEを選んでもらうことは難しくなります。 BASEはどんな会社ですか なぜBASEに転職したのですか 今抱えてる組織的な課題はなんですか 評価の方法を教えてください などなど 採用活動に携わるようになってから、プレイヤーの時と比べて一段高い視座を持てるようになったと感じています。 技術力が高まった 先日 「エンジニアリングマネジャーになってから技術力が伸びるパターン」 という記事が話題になりましたが共感を持って拝見しました。 候補者と面談をするにあたって職務経歴書に書いてある知らない用語を調べたりすることで、決して深くはありませんがプレイヤーの時には得られなかった広い知識が身についたと感じています。 相場が分かった スカウト等の採用活動をWantedly, LAPRAS, 転職ドラフト, Green, Findyなどたくさんのサービスを利用して毎日のように転職顕在層/潜在層のエンジニアをチェックしています。この経験を通じてスキルだったり会社だったり年収の相関が大体分かるようになり、今後の自分のキャリア設計に参考になると感じています。 最後に この一年間EMとして様々な経験をさせて頂きました。つらいなーと思うこともたくさんあった気がしますが、一年を振り返ってみるとつらかったことは思い出せずやりがいを感じたことばかりが思い出され不思議なものです。まだまだEMとして期待に応えられず不甲斐ないことが多くありますが、優秀なチームメンバーに支えられ何とか会社の成長にコミットしてこれたと思っています。2019年はチームメンバーに感謝の毎日でした。 2020年は「BASE」をより良いサービスに成長させられるように、エンジニア組織をまだまだ成長させていきます！2020年が今からとても楽しみです！ 明日は、テックリードの右京さんとデザイナーの石井さんです！お楽しみに！

この記事は、「 BASEアドベントカレンダー2019 」7日目の記事です。 devblog.thebase.in BASE株式会社で採用をやっているaipon（ @AiYoneda ）です。 今回は、Slack Workflow Builderを使ったワークフロー自動化についてご紹介します。 プログラミング知識がなくとも、簡単に作成することができるので、まだ試したことのないという方はぜひお試しあれ！ BASEでのSlack Workflow Builderの活用方法 人事関連のワークフローについて、労務回りはSmartHR、採用はHERPを使っていますが、利用サービスで吸収できない細かなワークフローについては主にSlack Workflow BuilderもしくはGoogleフォームを利用しています。 Slack Workflow BuilderとGoogleフォームは、下記のような使い分けをしています。 回答を一覧で見る必要がない・見返す頻度が少ない（Slackで回答が流れても困らない）、回答内容をもとにシート上で計算等を行う必要がない→Slack Workflow Builder 回答を一覧で見たり、見返す頻度が多い（Slackで回答が流れると困る）、回答内容をもとにシート上で計算を行う必要がある→Googleフォーム 回答をスプレッドシートで一覧で見たいもの、計算式を組んだりVLOOKUPなどあれこれしたいものに関してはGoogleフォームで回答してもらい、回答があれば特定のチャンネルで通知を飛ばしています。（Slackへの通知の飛ばし方は こちらの記事 をご参考にされてください。） 人事関連では、主に下記でSlack Workflow Builderを利用しています。 採用会食費用の補助申請 社内懇親会費用の補助申請 オフィスアンケート（社内向けサービスについての意見収集） 相談窓口（健康相談、働き方相談など） 人事制度やリファラル採用など、全社に関わる施策を実施する際は運用方法が全社に浸透するかがポイントになりますが、Slack Workflow Builderはフォームへの回答、回答の閲覧はSlack上でシームレスに行うことができ、全社の利用の障壁が低くなるというメリットがあります。 Workflowの作り方 ここからは具体的な利用方法についてのご紹介です。 今回は、採用会食費用補助の申請ワークフローを作る例とします。 採用会食補助のワークフローは下記です。 利用者（申請者）が補助申請 採用チームが内容を確認 問題なければ採用チームが稟議申請 稟議決裁がおりれば、採用チームが稟議を利用者（申請者）に共有 利用者（申請者）が会食実施 利用者（申請者）が経費精算 1から2のワークフローをこれまでGoogleフォームで行っていたのですが、URLが見つからなくなったり、Slackから遷移するのが少し面倒ではないかと懸念していたので、Slack Workflow Builderがリリースされたのを機に移行してみました。 1から2のワークフローをSlack Workflow Builderで実現する際のワークフローを細かく分解すると下記になります。 利用者（申請者）が補助申請 利用者（申請者）のDMに回答内容が送信 上記と同タイミングで、採用チームのチャンネルに回答内容を含むカスタマイズされたメッセージが届く 採用チームの担当者が内容を確認 それでは実際に作っていきます。 ワークフロービルダーを起動 メニューの一番上のワークスペース名をクリックすると、「ワークフロービルダー」があります。 これをクリック。 これまで作成したワークフローが表示されます。 ワークフローを新規作成 先ほどの画像の、右上の「作成ボタン」をクリック。 ワークフローに名前を付けます。 今回の例では、「採用会食費用補助申請フォーム」と入力します。 ワークフローの開始を設定できます。 今回は社内の誰かが申請しようと思ったときにワークフローを開始したいので、「アクションメニュー」を選択。 ワークフローを開始するチャンネルを選択します。プライベートチャンネルにも設定できます。 今回は #general とします。 「短い名前を追加」は、ワークフローを開始する際にチャンネルで表示される名称です。 利用する人が分かりやすい名称に設定するのがよいでしょう。 アクションメニューを設定するとこのように表示されます。 ワークフローの概要を設定したら具体的なステップを設定していきます。 最下部の「ステップを追加」からステップの追加を行うことができます。 ステップには「メッセージの送信」と「フォームを作成する」の2種類を設定することができます。 今回の場合、採用会食を実施する日時や参加するメンバー等の内容を申請者に入力してほしいので、フォームの作成を行います。 質問と回答の形式を設定してみました。 回答のタイプは入力形式のものやリスト形式、Slackのユーザー名やチャンネル名を選択する形式もあります。 上記はすべて「短い回答」でフォームを作成しています。 また回答者に回答内容を送っておきたいので、「提出された回答をチャンネルまたはDMで他のメンバーに送信する」にチェックを入れ、送信先を該当のワークフローをクリックしたユーザーに設定します。 ここまでで下記が完了しました。 利用者（申請者）が補助申請 利用者（申請者）のDMに回答内容が送信 あとは下記のステップです！ 上記と同タイミングで、採用チームのチャンネルに回答内容を含むカスタマイズされたメッセージが届く 採用チームの担当者が内容を確認 特定のDMやチャンネルにメッセージを送信するステップを作成します。 冒頭と同じように、ワークフローの概要から「ステップを追加」をクリックします。 今度は「メッセージを送信」をクリックします。 回答の送信先チャンネルの指定と、メッセージを作ります。 メッセージには変数を入れられるので、それぞれの項目の回答内容や、フォームを提出したメンバーをメッセージに加えることができます。 Previewを見ながらメッセージを作成できるのもいいですね！ メッセージができたら保存します。 ワークフローの作成はここまでです。 完成したら、ワークフローの概要から「公開する」をクリックしましょう！ 稲妻アイコンをクリックしてフォームが意図した通りにできていれば完成です！ 採用チームのチャンネルにはこのように通知が飛んできます。 おわりに 今回は誰でもできるワークフロー自動化の例をご紹介しました。 バックオフィスのメンバーが新しい制度や取り組みをする際に業務フローに手間がかかることが懸念の一つとしてあがることがあるかと思います。 こういった便利なツールを使うことで、制度起案者・運用者の心理的障壁がなくなるといいなーと思っています。 明日は、デザイナーの石井さんとテックリードの右京さんです！お楽しみに！

この記事はBASE Advent Calendar 2019の6日目の記事です。 devblog.thebase.in こんにちは、Product Management Group所属の 森本です。BASEには、2019年8月に入社し、Eコマースプラットフォーム「BASE」の企画やディレクションの業務に従事しています。 入社してからは、PayPal決済の導入のディレクションと、次期のプロジェクト企画などに携わっていたり、日が浅いうちからプロジェクトを任せてもらえる環境で、個人的には想像通りでとてもありがたいなと感じています。 BASEのProduct Managemantチームは、戦略、製品、事業数値まで責任をもちます。いろんなバックグラウンドをもっている方が在籍しているので、CRMに強い、計測に強い、など各々の強みを活かしてプロジェクトを牽引していることも多々あります。 私はエンジニアあがりのディレクターではなく、新卒で広告系のプロダクションでWEBディレクターを経験し、次に主にアパレル系のECサイト構築や外部連携・運用の要件定義や進行管理を担う PM / Dを経験してきました。 なので、あまりテクニカルなお話はできないのですが、BASE入社4ヶ月のディレクターがプロジェクトを進めていて良いな（今後も続けていきたい）と思ったものごとをご紹介したいと思います。 SQLをすこしかけるようになり、ほしい情報を得ることができた BASEではエンジニアやマーケッターだけでなく、全員にRedashを解放していて、みんな平等にデータを調べられる機会が与えられています。恥ずかしながら私は今までSQLの知識がなかったのですが、すこし勉強してRedashでほしいデータを見れるようになりました。まだまだほんの少しですが、以前から習得したかったことだったのでうれしい。 ちなみに、SQLの学習は Progate で、にんじゃわんこのデータベースをなんどもSELECTし、問題を実践で解いて勉強しました。失敗と成功をくりかえしていると、いつの間にか自信もつくので、環境を構築しなくてもすぐに学習ができるProgateに感謝です。（PR記事ではないです） 何より、新たなプロダクトに携わると、どんなテーブルで構成しているのか？どれくらいこの機能は利用されているのか？などをざっくりと把握したいときに、そこでエンジニアに聞いたり、過去の設計書などから情報を得る、といったことをせず、自らの手でシュッと調べることができるのも、とても効率的で前向きな姿勢でよいなと思います。（もちろん複雑な条件でお手上げの時は、詳しい人に聞くと教えてくれる環境でありがたいです...） UI/UXのレビューミーティングによる思考共有 各プロジェクトのデザインについて、毎週2回 UI/UX MTGという会議が開催され、そこでは各プロジェクトで進めているデザインのレビューが行われます。自分の携わっているプロジェクトはもちろんのこと、他のプロジェクトで進めているデザインなどの経緯やデザイン意図を聞けるので、考え方が常にチーム内で共有され、アップデートし続けることができるのはとてもよいなと思います。 法人向けのプロダクトでは、比較的優先度が下げられがちな管理画面のUI/UXですが、「BASE」は「誰でも簡単に使える」というコンセプトがサービスの根幹になるので、このミーティングはとても大切な時間であると思うのです。 個人的には、みんなのプロダクト愛を感じることができたり、まだまだ詳細を把握できていない機能を知ることができたりするので、そういった面でもこのミーティングが好きです。 このプロジェクト・機能は何のために？をしたためる シンプルでわかりやすく、ユーザーにどんな価値を提供できるのか、をプロジェクトごとや小さな出来事でも書く習慣があること。 日常的に、Slackなどでも「これはオーナーさんのどういう課題を解決できるのか」ということをよく目にすることがあり、BASEのメンバーは常にオーナーさんのことを考えている集団だなぁと感じることが多々ありますが、とくにプロジェクトの企画をたてるときにわかりやすく明文化することで、チームメンバーへ共有するときや、プロジェクトを進める中で判断に悩んだときに読み返すことができるブランケット（安心毛布）のような存在になります。 また、他のプロジェクトの記事（Kibelaを利用しています）を見て、めっちゃいいなと感じることは自分のプロジェクトにも反映することができるので、今後もしっかりと書いて、ブレずにいいプロダクトに反映していきたいです。 まとめ 上にあげたことすべてに言えるのですが、単発的に行うのではなく、日々コツコツと積み上げていくことができているからこそ価値があるのだと思います。 ただ、努力し続けていても気持ちがネガティブだと、どんどん悪い方へいってしまいがちなので、常にポジティブに取り組むことが大事です。行動指針のひとつに、「Be Hopeful」があるように、BASEのメンバーはポジティブな思考のひとが多いように思います。私もBe Hopefulにagreeです。 すこしルー大柴風になってしまいましたが、来年もコツコツと楽しくやっていきたいと思います！ 明日のアドベントカレンダーは、Service Devマネージャーの菊地さんと人事の米田さんです！

この記事は BASE Advent Calendar 2019 の6日目の記事です devblog.thebase.in どうもこんにちは、Frontend Groupの青木です BASEではVue.js+TypeScriptを採用したフロントエンド開発を行っています 今回のブログでは、私が業務で直面したちょっとした課題を、Vue.jsのカスタムディレクティブを実装して解決し、npmのパッケージとして公開した話をします 何を作ったか vue-remove-whitespace - npm spanやaなどのinline要素内での改行による意図しないスペースを削除するVue.jsのカスタムディレクティブを作りました 挙動としては < p v-remove-whitespace> お問い合わせは < a href = "#" > こちらから </ a > お願いします </ p > というvueのtemplateが、レンダリングされる際には < p > お問い合わせは < a href = "#" > こちらから </ a > お願いします </ p > となります ディレクティブの指定がある場合と無い場合では、 お問い合わせはこちらからお願いします お問い合わせは こちらから お願いします のような見かけ上の違いが生じます この程度の文字数であれば、最初から改行を含めなければいいのでは?と思うところですが、各要素のattribute属性やイベント修飾子、propsなど入力するものが増えたりすると、改行したくなったりすることもあり、解決できるものを作ろうと思いました npmのpackageとして公開するまでにしたこと 公式のカスタムディレクティブのドキュメントを読む https://jp.vuejs.org/v2/guide/custom-directive.html 使っているライブラリのソースコードを読む https://github.com/logaretm/vee-validate/blob/v2/src/directive.js 現在公開されているnpmのカスタムディレクティブを探し、ソースコードを読む https://www.npmjs.com/search?q=keywords:vue https://www.npmjs.com/search?q=keywords:vue-directive 調べている過程で、 vue-focus というライブラリの開発構成がシンプルそうでいいなと思い、構成をforkして、機能実装を済ませ、初回のリリースを終えました テストの実装と、TypeScriptの開発環境で使いやすくする 公開して満足してしまい、追加で開発しようと思っていたことができていなかったのですが、今回のアドベントカレンダーを機会に、テストの実装とTypeScriptの開発環境で使いやすくしてみました テストを実装するまでにしたこと 公式の単体テストのドキュメントを読む https://jp.vuejs.org/v2/guide/unit-testing.html デモリポジトリをクローンし、テストを体験する https://vue-test-utils.vuejs.org/ja/ 実際にテストを書いてみる https://github.com/aokiken/vue-remove-whitespace/tree/master/ tests import { removeWhitespace } from '../index' export default { directives: { removeWhitespace } , template: ` <div v-remove-whitespace> <span>1</span> <span>2</span> <span>3</span> <span>4</span> <span>5</span> </div> `, } import { mount } from '@vue/test-utils' import InlineElementWithLineBreak from './InlineElementWithLineBreak' describe( 'InlineElementWithLineBreak' , () => { const wrapper = mount(InlineElementWithLineBreak) it( 'renders the correct markup' , () => { expect(wrapper.html()).toBe( '<div><span>1</span><span>2</span><span>3</span><span>4</span><span>5</span></div>' ) } ) } ) 簡単なテストですが、期待通りに動いていることが確認できました🎉 TypeScriptの開発環境で使いやすくするためにしたこと index.d.tsを書く https://github.com/aokiken/vue-remove-whitespace/blob/master/index.d.ts import { DirectiveOptions } from 'vue' export const version: string export const removeWhitespace: DirectiveOptions export const mixin: { directives: { [ key: string ] : DirectiveOptions , } , } package.jsonにtypesを追記する https://github.com/aokiken/vue-remove-whitespace/blob/master/package.json#L61 これらを追記したおかげで、TypeScriptのプロジェクトでも、型情報が参照できるようになりました🎉 最後に 今回のnpm公開は、実装の過程でコンパクトな機能が出来たので、これなら公開できそうと思ったことと、 まずはやってみよう という思いから挑戦してみました おまけ1: いくつか対応策はあった 閉じタグの>を改行すればスペースは入らない < div > < span > 1 </ span >< span > 2 </ span >< span > 3 </ span >< span > 4 </ span >< span > 5 </ span > </ div > 開始タグの<tag以下を改行すればスペースは入らない < div > < span > 1 </ span >< span > 2 </ span >< span > 3 </ span >< span > 4 </ span >< span > 5 </ span > </ div > コメントアウトを挟めばスペースは入らない < div > < span > 1 </ span > <!-- --> < span > 2 </ span > <!-- --> < span > 3 </ span > <!-- --> < span > 4 </ span > <!-- --> < span > 5 </ span > </ div > おまけ2: cssで工夫するとスペースや改行が入り込む https://codepen.io/aokiken/pen/vYBLMyv 気にならなければ良い気もしている おまけ3: 英語では困らない そもそも単語区切りでスペースが入るので、困らないのか、と実装してて気がつきました 逆に、日本語、中国語、タイ語などの言語では有効そう 明日はService Devマネージャーの菊地さんと人事の米田さんです！

この記事は BASE Advent Calendar 2019 の5日目の記事です。 devblog.thebase.in こんにちは、Data Strategyマネージャーの鈴木です。社内には鈴木が沢山いますので、普段は下の名前（りょう）で呼ばれています。 Data Strategyチームでは、BASEに存在するデータを活用する事によって、人手ではカバーできないようなきめ細かな価値や気付きを、データ分析や機械学習を中心とした取り組みを通じてプロダクトやサービスに提供しております。 中でも以下の課題については、Data Strategyチーム（以下DSチーム）の重要課題として取り組んでおります。 オーナーズ（ショップオーナー）の方々の成長をどのように支えていくか 購入者の方々が安心して購入できるプラットフォームをどう作るか オーナーズと購入者の接点を商品やショップを通じていかに増やすか 今回はその中から、いくつか具体的にユーザーの皆様の利便性向上のため活用している部分についてざっくりと紹介したいと思います。 （技術的側面につきましては、DSメンバーがこれからアドベントカレンダーで紹介していきますのでお楽しみに！） 1. オーナーズの方々の成長をどのように支えていくか オーナーズの成長を支えるには、様々なポイントがありますが、その中でも一番最初に行うべき事は、ショップをいかに数値で客観的に見る事が出来るようにする事と考えております。 そこで、DSチームではオーナーズの方々の様々なデータを提供するための仕組みづくりを進めてきました。 その一つが、今年の夏から進めてきているオーナーズの方々の管理画面にあるデータページ向けデータとなります。 データページの紹介はこちら: note.com 「BASE U」の記事はこちら: baseu.jp こちらはAWSのAurora/DynamoDBの他、ETLやLambda/Fargate/SQS/SNSなどを活用したプラットフォームとなっており、現在80万ショップの日次・週次・月次のデータを個別集計およびリクエストベースで表示する仕組みとなっております。 また、当日分データを表示するためのデータのリアルタイム取得に向けたプラットフォーム作りも並行して行っており、先日公開されました。 note.com 一方、データだけあってもその活用法がないと活かす事が難しいため、来年はそのデータ活用方法も含めて提案していければと思っております。 2. 購入者の方々が安心して購入できるプラットフォーム 「BASE」では販売が制限されている商品があります。 help.thebase.in 現在、各商品に対しての自動検知を行い、もし検知した場合に社内チームに連絡する仕組みがあります。 この通知には、上記の登録が制限された商品以外にも、話題になっている商品などの検知も行っており、ビジネスチームのサポートも同時に行っております。 3. ショップオーナーズと購入者の接点を商品やショップを通じていかに増やすか 「BASE」においてショップオーナーと購入者の間には、さまざまな接点が存在しますが、大きく分けて販売の場とブランディングの場に分かれます。これらは独立型ECや従来のSNSなど独立している場合もありますが、ポップアップやモール型ECなど場として混在しているケースもあります。 その中でもデータによって効率的に接点を増やす事が行える場所としてはモール型ECがあり、DSチームでは発足直後からショッピングアプリ「BASE」の機能改善を行ってきました。 ここではいくつかデータを活用した箇所を紹介したいと思います。 今日のおすすめ商品 アプリユーザーの興味の対象を推定し、 「BASE」でよく売れている商品の商品や、興味を引いている商品と、マッチングを行なっています。 買い物や参照傾向も一定の影響を及ぼしていますので、興味のある商品群を定期的に探していると、探さなくても興味がありそうな商品がよくでてくるようになります。 なお、類似商品も別軸で見ているので、あまりにも同じような商品が存在するときは、ショップの運営状態から優先的に紹介するような仕組みになっています。 おすすめショップ 「BASE」の人気ショップの中から、一定の基準を満たしたショップを紹介しています。 アプリを使い続けていくと、より好みのショップがおすすめされていくようになります。 ショップ側も、継続的に運営を続けていくと、購入者により近い存在になるような仕組みを取っています。 特集 パーソナライズされた情報と過去のトレンドを元に、購入者が興味が持ちそうなテーマを毎日作成しています。 タイトルは過去数年の間に手動で作成していたデータを元に自動生成しています。 こちらは、時代によって旬の言い回しが変わってくるため、定期的にモデルの更新を行っています。今の時期ですと、カレンダー・クリスマス・ギフト等と言った商品が紹介されています。 技術的な内容については、DSチームメンバーの齋藤( @pigooosuke )の記事に詳しく記載しております。 devblog.thebase.in まとめ いくつか取り上げてきましたが、BASEにおいては、データ活用を非常に重要視した取り組みをおこなっており、それを実現するためにメンバーも続々と加入しております。 今後とも、データ活用をさまざまな手法で行い、皆様の利便性に貢献していければと思います。 明日は、Frontendチームの青木さんとProduct Managementグループの森本さんです！お楽しみに！

この記事はBASE Advent Calendar 2019の5日目の記事です。 devblog.thebase.in こんにちは。BASE株式会社でOwners Growthチームのマネージャーをしている遠藤です。 Owners Growthチームのミッションは、「BASE」に登録しているショップの成長を支援したり、運営のサポートを行うことで「BASE」でのショップの開設・運営の体験を向上させ、ショップさんに継続的にご利用いただくことです。 今回はアドベントカレンダーということで、このミッションを遂行するために普段どんなことを行なっているのか、特にOwners Growthチームで行なっている戦略や戦術を決めるための仮説検証プロセスを簡単にご紹介したいと思います。 そもそもOwners Growthってどんなことを考えながら仕事をしているの？とか、どうやって仮説を検証しながら戦略を作るの？っていう疑問に答えられるような記事にしたいなと思いました。 ただし実際の社内データは直接お見せことができないので、身近に存在する問題を探した結果、投資というテーマを題材にしてみました。 目標から考えるKPI設計と仮説検証プロセス I君は最近、株に興味をもち投資を始めようと思い立ちましたが、どの会社の株を買えばいいのかわからず悩んでいます。 ここでのI君の目標は何をどのくらい買うのか、つまり 投資方針を決めること になります。 そこでI君はこの目標を達成するための要素として 株価が上がりやすいこと リスクが抑えられること の２つがあることに気づき、まずはこの株価の上がりやすさとリスクを定量化する必要があると考えました。 KPI設計 上がりやすさは過去の株価の変化率とし、リスクを株価の標準偏差と定義します。 つまり、過去の株価がプラスに変化してきた銘柄は今後も上がりやすく、上下の変動が大きかった銘柄はリスクが大きいと考えたのです。 そしてこの変化率(Return)が大きくてリスクが低くなるような以下のような指標を作ってKPIとし、そのKPIが最大になるようにします。 IT企業に勤めているI君は最近よく耳にするA社とB社に絞って、どちらに投資したらより大きなKPIが得られるのか調べようと思いました。 仮説1の作成 ここで、 どちらかKPIの高い銘柄に投資することが投資効率が高い という仮説を立てます。 この仮説を検証するために、それぞれの銘柄のKPI指標を計算して比較してみようと思います。 検証のための下準備 まず以下のように２社の株価の取得してcsvファイルに保存するようなスクリプトを実行しました。 getPrice.py #python from datetime import datetime from concurrent import futures import pandas as pd from pandas import DataFrame import pandas_datareader.data as web def download_stock(stock): try: print(stock) stock_df = web.DataReader(stock,"yahoo", start_time, now_time) stock_df['Name'] = stock output_name = stock + '_data.csv' stock_df.to_csv(output_name) except: bad_names.append(stock) print('bad: %s' % (stock)) if __name__ == '__main__': ticker_stocks = ["ticker_a","ticker_b"]#ticker array workers = len(ticker_stocks) with futures.ThreadPoolExecutor(workers) as executor: res=executor.map(download_stock, ticker_stocks) 仮説1の検証 上のスクリプトを実行して得られたcsvファイルを使って、それぞれの銘柄を評価していきます。 まずKPIを算出してみます。 getKpi.R #リターンを計算する a = read.csv("/Users/tsuyoshiendo/Documents/flask/stock/a_data.csv") b = read.csv("/Users/tsuyoshiendo/Documents/flask/stock/b_data.csv") colnames(a)[7] = "adjClose" colnames(b)[7] = "adjClose" a$ret = as.numeric(a$adjClose) / as.numeric(c(NA, a$adjClose[1:nrow(a)-1]))-1 b$ret = as.numeric(b$adjClose) / as.numeric(c(NA, b$adjClose[1:nrow(b)-1]))-1 #余分なデータを削除 a=a[!is.na(a$ret),c("Name", "Date", "ret")] b=b[!is.na(b$ret),c("Name", "Date", "ret")] #リターン ex_a = mean(a$ret) ex_b = mean(b$ret) #リスク sd_a = sd(a$ret) sd_b = sd(b$ret) #KPI kpi_a = ex_a/sd_ap#a社のKPI kpi_b = ex_b/sd_am#b社のKPI paste("a's KPI = ", kpi_a, ", b's KPI = ", kpi_b, sep="") 実行結果 a's KPI = 0.0549560106863018, b's KPI = 0.081528997872345 aのほうがKPIの値が高く、リスクに対して相対的にリターンが大きいといえます。 検証結果の深掘り しかし、ここで得られた結果に基づいて B社だけに投資しようと考えるのは拙速 です。 KPIを設計する際に作ったリスク指標は標準偏差、すなわち株価変動の大きさを表しているのですが、２社の株価が全く同じように連動しているとは考えづらいため、それぞれの組み合わせ方によってはリスクを抑えられる可能性があります。 そのため、２社の組み合わせパターンに応じたKPIを算出してみたのが次です。 twoAssets.R #covariance cov_a_b <- cov(a$ret, b$ret) weight_patterns <- seq(from = 0, to = 1, length.out = 1000) two_assets <- data.table(wx = weight_patterns) two_assets[, wy := 1 - wx] two_assets[, ':=' (ex_p = wx * ex_a + wy * ex_b,sd_p = sqrt(wx^2 * sd_a^2 + wy^2 * sd_b^2 + 2 * wx * wy * cov_a_b))] two_assets <- two_assets[wx >= 0 & wy >= 0] two_assets[, ir := ex_p / sd_p] ggplot() + geom_point(data = two_assets, aes(x = sd_p, y = ex_p, color = ir)) + geom_point(data = data.table(sd = c(sd_a, sd_b), mean = c(ex_a, ex_b)), aes(x = sd, y = mean), color = "red", size = 3, shape = 18) + theme_bw() + ggtitle("efficient frontier") + xlab("Standard Deviation") + ylab("Expected Returns") + scale_y_continuous(label = percent) + scale_x_continuous(label = percent) + scale_color_gradientn(colors = c("blue", "red"), name = "ir ratio", labels = percent) + theme_gray (base_family = "HiraKakuPro-W3") + expand_limits(x = 0, y = 0) two_assets[ir == max(two_assets$ir)] この結果、以下の曲線のような図が得られました。 この曲線はA社とB社の組入比率1,000通りのパターンに対して、縦軸にリターン、横軸にリスクをとってプロットしたものです。 そして曲線の両端がA社とB社の２社にそれぞれ単独に投資した場合になります。 軸の取り方から左上に行くほどKPI指標の大きな（＝最適な）組み合わせであると言えますが、これを見ると両端の点ではなく、曲線上の中間地点の方がKPIの値が大きいことがわかります。 実際に最も高いKPIとなった組み合わせはA社に24%、B社に74%投資したパターンでそのKPI指標は0.0832と、それぞれ単独で投資をした場合の0.055と0.082よりも大きいです。 これら検証の結果、仮説１は誤っていた(棄却された)、すなわちどちらかだけに投資するのではなく、リターンとリスクに応じて投資比率を変えるべきであることがわかります。 ここで次の疑問が湧きます。 複数の会社に投資をすることで KPI指標をさらに高めることができるのではないか、です。 最初の仮説検証プロセスの結果、KPIをさらに高めるための次の仮説を検証していきます。 仮説２の作成 「組み合わせ方によって最も高いKPIを予測することができる」。 仮説２の検証 I君はこの仮説２を検証するため、C社とD社にも投資してみようと思いました。 まずC社を合わせた３社のパターンで先ほどの図を描いてみます。 threeAssets.R weight_patterns <- seq(from = 0, to = 1, length.out = 1000) #expected_return ex_a = mean(a$ret) ex_b = mean(b$ret) ex_c = mean(c$ret) ex_d = mean(d$ret) sd_a = sd(a$ret) sd_b = sd(b$ret) sd_c = sd(c$ret) sd_d = sd(d$ret) cov_b_a <- cov(a$ret, b$ret) cov_a_c <- cov(b$ret, c$ret) cov_c_b <- cov(c$ret, a$ret) three_assets <- data.table(wx = rep(weight_patterns, each = length(weight_patterns)),wy = rep(weight_patterns, length(weight_patterns))) three_assets[, wz := 1 - wx - wy] three_assets[, ':=' (ex_p = wx * ex_a + wy * ex_b + wz * ex_c, sd_p = sqrt(wx^2 * sd_a^2 + wy^2 * sd_b^2 + wz^2 * sd_c^2 + 2 * wx * wy * cov_b_a + 2 * wx * wz * cov_a_c + 2 * wy * wz * cov_c_b))] #four_assets[, ':=' (ex_p = ww*ex_a + wx*ex_b + wy*ex_c + wz*ex_d, sd_p = sqrt(ww^2 * sd_a^2 + wx^2 * sd_b^2 + wy^2 * sd_c^2 + wz^2*sd_d^2 +2 * ww * wx * cov_a_b + 2 * ww * wy * cov_a_c + 2 * ww * wz * cov_a_gg + 2 * wx * wy * cov_b_c + 2 * wx * wz * cov_b_gg + 2 * wy * wz * cov_c_gg))]#4資産以上の場合 three_assets <- three_assets[wx >= 0 & wy >= 0 & wz >= 0] three_assets[, ir := ex_p / sd_p] p = ggplot() + geom_point(data = three_assets, aes(x = sd_p, y = ex_p, color = ir)) + geom_point(data = data.table(sd = c(sd_a, sd_b, sd_c), mean = c(ex_a, ex_b, ex_c)), aes(x = sd, y = mean), color = "red", size = 3, shape = 18) + theme_bw() + ggtitle("frontier") + xlab("Standard Deviation") + ylab("Expected Returns") + scale_y_continuous(label = percent) + scale_x_continuous(label = percent) + scale_color_gradientn(colors = c("blue", "red"), name = "kpi", labels = percent) + theme_gray (base_family = "HiraKakuPro-W3") three_assets[ir == max(three_assets$ir)] 結果は３社の最適な組み合わせのKPI=0.0845となり、２社だけの場合よりさらに高くなりました。 同様にD社も加味して４社で試すと、KPI=0.0850となってさらに高くなります。 その場合、当初曲線だったグラフは以下のように、取りうる選択肢が広がった分だけ多くなって線から面となります。 この作業の繰り返しによって以下の結論が得られます。 ３社の場合より４社のほうが伸び幅が逓減するため、 銘柄数が多くなるほどKPIは高くなるもののその値は一定値に収斂する という可能性を推測することができます。 したがって、仮説２は正しいと言えます。 仮説検証で得られた戦略の実行プラン 仮説１と仮説２の検証によって得られた知見から、投資対象の銘柄を増やすことによってKPI指標の最大化を図ることができ、このときの株式の保有割合は上で実施したような方法によって知ることができます。 しかしながら、実際の現場ではこうして得られた知見をそのまま使うことはしません。 最適解として得られた保有割合が何を示しているのか考え、データの裏にある真実を探る必要があるからです。 ここで得られる真実とは、株価（リターンとリスク）によって得られる最適な保有割合は一意に決まり、合理的な投資家であれば皆その比率を保有すると推測されます。 したがって、KPIの設計が正しく、市場参加者の大部分がこのKPIに対して合理的に投資するという前提に立てば、各投資家が今回得られた保有比率に応じて売買しているため、その結果として価格形成された現在の株価（正確には時価総額）はこの比率が反映されているはずです。 言い換えれば、最適な保有比率そのものが時価総額の比率によって決定されていると考えることができます。 結果的に、当初立てた目的を達成するためには、より多くの銘柄を時価総額の比率で重み付けされた指数（S&P500やTOPIXのETFなど）に投資する必要があるといえそうです。 さいごに ここまで、目標に対してKPIを設計してアクションを決定するまでのプロセスをご紹介しましたが、実際の業務ではこのように単純な前提を置くことはできないので、仮説と検証を繰り返して得られた結果の背後にある事実を正確に捉えながら戦略の精度を高めていく必要があります。 今回はアドベントカレンダーということで若干テクニカルな話をあえて盛り込んでみましたが、実際の業務ではそこまでスクリプトを書いて分析する時間は多くありません。 むしろ手元にあるデータや事象から論理的に戦略を決め、メンバーとコミュニケーションを取りながら円滑にプロジェクトのディレクションをすることも重要です。 もしこうした仕事に興味を持っていただけたら、採用窓口からのご応募をお願いいたします。 ぜひお待ちしております。

CTOの川口( @dmnlk )です。 2019/11/30に池袋で行われたDevelopers Boost 2019に主催の翔泳社様より招待頂き、基調講演として登壇させて頂きました。 Developers Boost は「U30エンジニアの登竜門」と題されており、U30エンジニアのためのカンファレンスです。 テーマが「これが私の戦い方」というものだったので、自分がどのように自分の市場価値を決め成長し生存戦略を立ててきたかを「プロダクトファーストに価値を創造するエンジニアとしての生き方」というタイトルで発表させて頂きました。 資料は下記になります。 エンジニアの市場価値をは人それぞれあると思いますし、技術をどう伸ばしていくか何のためにやっていくかも人それぞれだと思います。 自分にとってのキャリア形成の価値基準に「プロダクト」を置いたのが私の戦い方になっています。 これを見聞きして頂いた皆様のエンジニアのとしてのキャリア形成の方向性の一つの材料になってもらえれば幸いです。 他の方の発表をいくつか聞かせて頂きましたが、大変参考になるものが多くU30といえども色々な戦い方の多様性があるなと感じました。 また、懇親会でも多くの方とお話させて頂き刺激を受けさせて頂きました。 改めて、このような機会を頂いた翔泳社様にはお礼を申し上げさせていただきます。 来年はまだギリギリU30の枠なので参加したいと思います。

この記事は BASE Advent Calendar 2019 の4日目の記事です。 devblog.thebase.in こんにちは、BASE BANK株式会社 Dev Divisionに所属している東口（ @hgsgtk ）です。 普段、ブログやカンファレンスでアウトプットする内容としては、PHP・Go ・Pythonなどサーバーサイド言語を用いた話や、テストやコード設計の話が多いのですが、せっかくの年に一回のアドベントカレンダーなので、普段はあまりしないクラウドインフラのレイヤーの話をしたいと思います。 私は、「 YELL BANK（エールバンク） 」というサービスの開発・運用をしています。そのサービスの運用にあたって、Relational databaseとして、 Amazon Aurora を利用しています。　 Amazon Auroraを利用するにあたって、アプリケーションから参照系リクエストを受け付けるエンドポイントを定義するのにCustom endpointを使用しています。 このCustom endpointにおいて、フェールオーバーを想定した場合に必要な、設定のちょっとした注意点を紹介してみます。 ケーススタディ 次のように、1台の書き込みロールのインスタンスと、2台の読み込みロールのインスタンスの計3台のインスタンスがぶら下がるクラスターを想定してみます。 AWS RDSのマネジメントコンソール画面 このクラスターにおいて、アプリケーションからは test-database-1-analysis という読み込みロールのインスタンスは参照せず、分析用として使うという構成だとします。 Amazon Auroraのエンドポイント 前提知識として、Amazon Auroraには4つのエンドポイントが存在します。 docs.aws.amazon.com まず、現在のプライマリDBインスタンスに接続する クラスターエンドポイント 、DBクラスターの使用可能なAuroraレプリカのいずれかに接続する 読み取りエンドポイント 、Auroraクラスター内の特定のDBインスタンスに接続する インスタンスエンドポイント 、そして今回の記事のタイトルでもある カスタムエンドポイント です。 カスタムエンドポイントは、選択したDBインスタンスのセットを表し、選択したグループ内で負荷分散を行い接続します。 今回のケースでは、読み取りエンドポイントの一部をアプリケーションから使いたいことが要求です。その要求をカスタムエンドポイントであれば叶えられそうです。 カスタムエンドポイントタイプ 実際にカスタムエンドポイントを設定します。ただし、フェールオーバーが起きてインスタンスのロールが入れ替わった際の考慮は忘れてはいけません。そういった場合に知っておくべきは カスタムエンドポイントタイプ です。 このカスタムエンドポイントタイプによって、当該エンドポイントに関連づけることができるDBインスタンスが決まります。具体的には、 READER ・ WRITER ・ ANY の三種類があります。 READER: 読み取り専用のAuroraレプリカであるDBインスタンスのみが、これの一部になれる WRITER: マルチマスタークラスターにのみ適用される、複数の読み書きDBインスタンスを含めることができる ANY: 読み取り専用のAuroraレプリカと、読み取り/書き込みのプライマリインスタンスの両方がこれの一部になれる カスタムエンドポイントタイプは、マネジメントコンソール上で見る限りは、表示されていないので、気がつきにくいですが、マネジメントコンソールで作成した場合には、ANYになります。 カスタムエンドポイントタイプの ANY または READER を AWS マネジメントコンソール で選択することはできません。AWS マネジメントコンソール で作成するすべてのカスタムエンドポイントは ANY タイプになります。 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.Endpoints.html#Aurora.Endpoints.Custom.Properties マネジメントコンソールから作ってみると 例えば、マネジメントコンソールで作成したカスタムエンドポイントに、設定時点で読み込みロールのインスタンスを選択してみます。 マネジメントコンソール画面からカスタムエンドポイントを作成する この状態でマネジメントコンソールから フェールオーバー させてみます。すると、カスタムエンドポイントに設定したインスタンスは次のように変化します。 フェールオーバー後のエンドポイントメンバー ロールが 書き込み になってしまいました。これでは、レプリカのみを参照したいエンドポイントにしたい意図を満たすことができません。 どうすればいいか 先ほどお伝えした通り、現時点（2019年12月4日）で、マネジメントコンソールから、カスタムエンドポイントタイプを設定する方法はなく、デフォルトでANYとなります。しかし、AWS CLIからはカスタムエンドポイントタイプを指定できるので、そちらで作っていきましょう。 AWS CLIでカスタムエンドポイントを作成する場合、 create-db-cluster-endpoint を使用します。 $ aws rds create-db-cluster-endpoint --db-cluster-identifier test-database-1 \ --db-cluster-endpoint-identifier reader-2 \ --endpoint-type READER \ --static-members test-database-1-instance-1-ap-northeast-1c test-database-1-instance-1 オプション endpoint-type にて READER を指定することで、カスタムエンドポイントタイプがREADERになります。 また、この時の設定方法として、設定したい読み込み専用DBインスタンスと、現在のプライマリDBインスタンスの両方を設定しておきます。するとマネージメントコンソールからは次のように見えます。 AWS CLIから作成したカスタムエンドポイント 現在、読み込みロールとなっている test-database-1-instance-1-ap-northeast-1c のみがエンドポイントメンバーとなっており、プライマリDBインスタンスは読み込み専用ではないのでメンバーにはなっていません。 こうしておくと、フェールオーバーが起きて、書き込み・読み込みが入れ替わった場合においても、読み込み専用のインスタンスに対して解決するようになります。 フェールオーバー後のエンドポイントメンバー ちなみに、YELL BANKの運用のためのインフラ構成管理は、基本的に Terraform で行なっていますそのため、Terraformのtfファイルにて次のように設定しました。 resource "aws_rds_cluster_endpoint" "test-database-read" { cluster_identifier = aws_rds_cluster.test-database.id cluster_endpoint_identifier = "test-database-read" custom_endpoint_type = "READER" static_members = ["test-database-1", "test-database-2"] } おわりに 以上、Amazon Auroraのちょっとした小ネタの紹介でした。この他にも、サービスの新規開発時や運用していく中で、クラウドインフラのレイヤーの経験もたまっていっているものがあるので、2020年も小出しにでもみなさまにお届けできればと思います。 明日は、Data Strategyチームの鈴木さんとOwners Growthチームの遠藤さんです！お楽しみに〜！

この記事はBASE Advent Calendar 2019 4日目の記事です。 devblog.thebase.in こんにちは、島田です。 一昨年はエンジニアとして業務をおこない、昨年はエンジニアリングマネージャー(以下EM)を担い、今年はまたエンジニアとして一年を過ごしました。 エンジニアに戻って改めて感じたことは、BASEのEMはエンジニアリング～という言い回しをしていますが、エンジニアとは全く役割が違うものだと思いました。 EMをやっているときは、いかに事業を成長させるか、成長させるためにどういった組織・チームを作るか、そのためにはどういった人や文化が必要か、その人が最大限活躍するためにはどういった制度や場が必要かを考えていました。 エンジニアに戻ってからはその制度や文化の中で過ごしていたのですが自分がEMになる前(一昨年頃)のエンジニア組織より開発や成長できる環境が整ったなと感じました。 特にエンジニアの人数が増え、さらに入社された方たちもいわゆる強い人と言われるエンジニアばかりなのでSlackで流れるやり取りや、GitHubのコードを見ているだけでも相当勉強になります。 さて、エンジニアに戻ったのでEMのころに担っていた採用や組織づくりの役割はなくなりましたが、1on1は継続して行っています。ただしする側ではなく受けるとしてです。 今回は自分が1on1をする側の時に思っていたこと、受ける側になって思ったことまとめたいと思います。 1on1を「する側」としてやっていたこと 人事、社内ルールのについて共有 成長過程にあるベンチャー企業というのは入社される方も多いですし、新しく選定される制度、変更される制度も多かったのでそれの共有を行っていました。 最近では人事・労務チームが全体に共有してくれているので最近のBASEの状況なら無くてもいいかなという感じです。 1ヶ月の振り返り 僕は月1で1on1を行っていました。 メンバーのGitやSlackでのやり取り、社内ドキュメントなどを常にウォッチし、各自の成果をまとめておき1on1で成果を確認し、評価項目についてお互いの認識のすり合わせを行っていました。 エンジニアは成果物での評価も大事ですが僕は適切なレビューや顧客問い合わせなどの運用フォロー、知見を生かした教育なども評価対象として伝えていました。 やりたいことを聞く・今後期待することを伝える 組織として期待することを伝えつつ、本人がやりたいことを聞いていました。 どんなに重要な事でも本人のやる気の方向性とミスマッチがあると生産性が下がってしまうのでなるべく期待との乖離が無いうように気をつけていました。 質疑応答 会社のこと以外にも自身の体調のことや家庭などのプライベートなことや、会社に対してこうしてほしい、こうしたいなど日々思っていることの共有をしていました。 以上が僕は主に行っていた1on1の内容です。 1on1を「受ける側」になって思ったこと 「受ける側」が1on1に対して心理的負担を感じる場合がある プロジェクトの進捗が思わしくない時は、受ける側としては気が重かったです。 さらにその状況で評価シーズンになると今後のことで心理的な負担は大きかったのでこういった状況を相談できる場になると良いなと思いました。 年齢が近かったり、同じライフイベントを経験したEMは比較的話しやすい 現在のEMは年齢が近く同じようなライフイベントを経験しているので、「子供のお迎えで数日間早退します」や「子供の看護で休みます」など業務外の要件も言いやすいです。 話しやすさと気持ちのバランスは比例するところがあり心理的な安定にも繋がると思うので相性は大事だなーと思いました。 場所ややり方を変えることで1on1への心理的負担を軽減させる 1on1の時間に対してネガティブな印象ができてしまうとその時間が来るのが負担になってしまうのかなと思いました。 そういった状況では何も意見が出ず、悪い流れが続いてしまい結果的には生産性が下がってしまうことになります。 そうった場合は時間や場所を変えみる、やり方を変えてみるなど環境を変化させるのも必要かなと思いました。 最後に 1on1をする側から受ける側になって一番重要だと思ったのは、お互いに「する側」「される側」という意識は持ったほうが良いということです。 BASEは年齢や役職関係なくフラットに話せる環境ですし、行動指針に「Speak Openly」を掲げていることもあり、セクションやチーム内で上下の関係を意識することがあまりないので「1on1は上司から部下にするもの」というよりは対等な関係性を基本としてお互いに気になっていることや期待していることを伝えあったほうが認識の齟齬やコミュニケーションストレスが少なくなり長期的に見たときに生産性は上がるのではと思いました。 明日はData Strategyマネージャーの僚さんとOwners Growthマネージャーの遠藤さんです！

こんにちは！BASEのProduct Divisionでエンジニアをやっております川島（ @nazonohito51 ）と申します。 この記事はBASE Advent Calendar 2019の3日目の記事です。 devblog.thebase.in 前の日は id:ngsw の EC2における単位時間あたりの名前解決制限の対応 と id:chiiichell の エンジニア2年生がリーダブルコードを読んで今年自分が書いたコードを振り返る でした。 今回は普段は見ることのない大型技術カンファレンス運営の裏側について書かせていただこうと思います。 こちらは文字通り裏側でクロージングの準備をしている実行委員長の背中です。 PHPカンファレンスとは PHPカンファレンスとは2000年から続いている、PHPカンファレンス実行委員会によって開催しているカンファレンスです。最近は参加人数も1500人を超え、日本の他のプログラミング言語のカンファレンスと比較しても非常に人数が多く、おそらく日本でも最大級のソフトウェアエンジニアのカンファレンスなんじゃないかと思います。（ただし他のカンファレンスは複数日開催だったり、資本が大きかったりと、1日のみ参加費無料のPHPカンファレンスと単純に参加人数でイベント規模を比較することは難しいと考えています） 第20回目の開催となる今年は beyond .* というテーマを掲げて、PHPのさらなる飛躍を目指したカンファレンスでした。公式サイトのロゴは飛躍するための飛行機の滑走路をイメージしたデザインとなっています。 PHPカンファレンス実行委員会とは PHPカンファレンス実行委員会とは謎の秘密結社です。夜な夜な暗いところに集まり、フード深くかぶりながら緑色の液体を飲んで祈祷を捧げる怪しい集団です。 というのは冗談で、正体は 日本PHPユーザ会 のメンバーです。特に参加資格があるというわけではないのですが、基本的に1回は当日スタッフを経験された方がもっと深くイベントに関わりたいと思ったときになっていただいています。いわゆるコアスタッフと呼ばれる実行委員会のメンバーの他、当日と前日のみ手伝ってくださる当日スタッフや、会場のネットワーク周りを用意してくださるNOCメンバーなどがいらっしゃり、私も全貌を把握しているわけではありませんが、スタッフアサイン表を見る限りは今年は112名もの人数でPHPカンファレンスは運営されていました。 実行委員会は裏で何をやっているのか？ 前日までの準備 今年の実行委員会が使っていたタイムスケジュールは以下のようになります。 これだけを見るとスポンサー・スピーカー・プログラム関連のスケジュールが目立ちますが、実際のところそれ以外の作業がたくさんあります。 Webサイト 広報 デザイン（Tシャツ、パーカー、ネームカードetc） ゲストスピーカー招致 スタンプラリー 音響・映像配信 書籍販売、サイン会企画 懇親会 会場設計 etc... それぞれに担当を初回のキックオフMTGで決め、毎月1回のMTGを積み重ねながら準備を進めます。また今年はelePHPantや懇親会参加チケットの販売のためにネットショップ販売などもありました。（弊社のサービスを利用していただきました） タイムスケジュール上は今年の6月辺りから開始していますが、ある意味本当の開始点は去年の10~11月辺りだったりします。というのも、イベントというのはまず先に場所の確保から始まります。企画だけ進行しても実際に開催できる場所がなければ何も実現できないためです。そしてイベント会場の確保というのは大変で、大体の場合1年以上前から動き始めないと予約できません。実はPHPカンファレンス2019の会場予約作業をしたのは私なのですが、参加者・スタッフの負荷を考えてイベント翌日は休日である日を確保したかったところ、そういった日はすぐ取られてしまっていたので、泣く泣く日曜日で確保した経緯があります。 前日と当日 前日にあたる11/30(土)はいよいよそれまで準備されてきたものを実現します。会場に全ての必要な物品が集まるので、それらを元にひたすら肉体労働、肉体労働、肉体労働です。 本当にたくさんの椅子を並べるのももちろんですし、他にもスポンサーブースの設営もします。 特に大変なのが実は電源で、PiOの電源は床下に収まっているのですがこのカバーがめちゃくちゃ重たいです。2,30キログラムあると聞いています。またとても持ちづらく、指を挟んだりして怪我をしやすいです。ブースへの配線次第では何十個もこのカバー開け締めしなくてはならないので、指を挟まなくてもカバー持ち上げ作業の積み重ねで腰がやられます。 そして前日作業の最たるものがこの業界では蟹工船と表現されるトートバッグのチラシ詰め作業です。丸く配置したテーブルにスポンサー様のチラシをずらりと並べ、ひたすら1枚ずつ取っていきます。本当に何時間もこの作業を続けるので、何度もぐるぐる回りながらやがて全員がバターになっていきます。 こうすることによって当日、ようやくイベントが開催することが出来ます。 そしてイベントが終われば当然のように後片付けがあります。PiOに会場をきれいな状態をお返ししなければならないので掃除を含めてまた同じような作業をしていきます。 実行委員会での私の役割 私は会場設計という役割で携わさせていただいていました。主な作業内容は文字通り会場の設計をすることで、各担当からの依頼に合わせて備品の配置を行います。また会場である 大田区産業プラザPiO とやり取りすることも必要になります。 備品を配置するだけといえば簡単そうに聞こえるのですが、実際のところMTGを重ねるごとに各担当からの依頼や状況が変わり続け、そのたびに何度も書き直しました。特に大きかったのは途中のスポンサー枠の増加です。元々の計画でも過去最高の数のスポンサーブースを用意しなければならなかったのですが、途中から更に増えるとなって少し頭を抱えたことがあります。上記の図は最終決定の設計なのですが、ここまでに一体何回の書き直しをしてきたのか分からないくらい書き直しました。 私はこの役割を2年間携わってきたのですが、会場とはイベントにおけるあらゆる利害関係が最終的に収束する場所なのだという気づきがありました。それ故にあらゆる利害関係者の要求の変化に対応し続けることがこの役割のキモなんだと考えています。 会場設計とシステム設計は似ている もう一つの気付きとして会場設計とシステム設計って似ている、というものがありました。 会場設計はあらゆる要求に対応し続ける必要があります。しかしそこには会場の物理的な制約や、あるいは要求と要求との間で発生するコンフリクトなどから全ての要求に応えきるのは実は難しかったりします。例えばスポンサーブースを増やしたくても会場の物理的な大きさ以上に配置することは出来ません。また各ブースに電源を供給しようにも会場の電源が置かれている場所は限られているため、ブースが配置できる位置はある程度限定されます。さらにはセッション会場と音が出やすいブースを近づけることは出来ないため、サイン会を行う書籍販売所やスポンサーブースをセッション会場に近い位置に置くことは出来ません。 このように会場設計は要求と要求とのバランシングや、物理的制約とのバランシングなどを行っていきます。大量の変数があるなかで、それぞれの目的をきちんと捉え、イベント進行上ある程度満足できる質に落とし込んでいく作業であるとも言えます。 これって常に技術的な制約や、現在の実装上の制限の中から、その時々のステークホルダーからの要求に応え続けるシステム設計そのものだなと感じました。なので、というわけではないですが、システム設計に興味のある方は一度会場設計を経験してみることをおすすめします。 イベント運営の醍醐味 最後に何故自分がイベント運営をやっているのか、その醍醐味は何なのかというお話をさせていただくと、今考えてみても正直良く分かりませんでした。少なくともイベントが上手くいったとき、イベントで喜んでくれる方がいらっしゃるのはとてもやりがいを感じますが、何かしら実利的な見返りがあるかと言われるとそんなに無いなと思っています。将来の転職活動のときになにかしら効果があるかと言われれば、それもあまりないだろうなと思います。（やってないよりは遥かに良い印象なのですが、純粋に転職効果を狙うなら他にもっと良い方法があると思います） しかしイベント運営をやっていると本業における立ち回りに還元されるもの少なからずあると思っています。会社規模にもよると思いますが、会社が大きくなると自分のやっている作業が巨大なものの一部となっていきます。そのため自分で事業を直接的にハンドリングしている感覚が薄くなったりするのですが、イベント運営はそんなことはありません。ほとんど直接的にハンドリングする必要があります。 感覚的な話になってしまい申し訳ないのですが、イベント運営をやることによって普段の業務において血の通った決断を行えるようになってきた感触があります。私もご多分にもれず、言われるままに作業をしていたり、目的感があいまいなままやってきたりしている部分は多々あったのですが、どこか目的を見据えた思考や判断ができるようになってきた気がします。どういった因果関係でそうなったのか今でもはっきりと言語化出来ないのですが、先述の通りイベント運営をすることで少なからず本業に還元されるものはあると感じています。 明日はBASE BANKの id:khigashigashi さんとProduct Dev Divisionの id:smdksk です！お楽しみに！

こんにちは！2019年ももう少しで終わりですね。さて、この度は、12/1（日）に東京・蒲田で開催された PHP Conference Japan 2019 にて、3名のメンバーが登壇しました。また、プラチナスポンサーとして協賛いたしました。今回は、スピーカーとして参加しためもりー( @m3m0r7 )、金城（ @o0h_ ）、東口（ @hgsgtk ）の3名から参加レポートをお届けします！ PHP Conference Japanとは PHP Conference Japan 2019 とは、12/1（日）に開催された、プログラミング言語PHPのカンファレンスです。今年は、約1400人のPHPエンジニアが集った国内最大級のカンファレンスとなりました。 phpcon.php.gr.jp BASEは、プラチナスポンサーとして本カンファレンスに協賛いたしました。 https://phpcon.php.gr.jp/2019/ 会場は、昨年の開催に続き、大田区産業プラザ PiOでした。 BASEのブース 企業ブースでは、弊社メンバーが持っているありったけの ElePHPant でブースを彩ってみました。本当にたくさんの参加者の方とお話させていただけ、一同大変楽しい時間となりました。 また、アメリカから来日されていた Adam Culp さんにも、ブースに足を運んでいただき、写真を撮っていただく貴重な機会がありました。 Adam Culp さんは、マイアミで開催されている SunshinePHP というPHPのカンファレンスのオーガナイザーをされていたり、PHPコミュニティを世界的にリードされてる一人です。 Adam Culpさんとぱしゃり 当日の書店コーナーでは、著者によるサイン会があり、個人的に書籍「みんなのPHP」に寄稿していた、めもりー( @m3m0r7 )・東口（ @hgsgtk ）がサイン会に参加していました。 書籍「みんなのPHP」サイン会終了！しかしまだまだ買ってくれ！！！頼む！！！！ 写真は著者の集合写真です。 pic.twitter.com/2gkJWXOxWj — uzulla (@uzulla) December 1, 2019 発表内容・資料 めもりー( @m3m0r7 )、金城（ @o0h_ ）、東口（ @hgsgtk ）それぞれから、発表内容をお伝えします。 めもりー @m3m0r7 Track2 (小展示ホール)にてセッションさせていただきました。 このセッションでは PHP で並列処理、非同期処理をどう実装すればよいのか？といったお話を主軸に、そもそも並行処理や並列処理、非同期処理とは何なのか？という構成になるようにしていました。ホール自体が大きく、多くの方に起こしいただいて感謝しております。 東口さんに、「え？elePHPant 持っていかないんですか？」と言われ、大事だよな、ということで、販売が始まってすぐに購入した elePHPant を会場に持っていきました。 資料自体は、実は私一人で作り上げたものではなく、私の今までの経験を含め、 Go 言語を使用している BASE BANK の東口さんや budougumi0617 さんにも見ていただいたり発表練習に付き合っていただき、そして校正に校正を重ねてきていて、お越しいただいた皆様に楽しく理解してもらえるように尽力しておりました！ そして、懇親会 LT では、「PHP を JVM 言語にする」という内容でデモを交えてお話させていただきました。 実は吉祥寺 pm でしかお話したことのない内容で、今まで 「PHP で JVM を実装する」という話を各イベントで主軸にお話していましたが、それとはまた別で PHP そのものを JVM 言語にしてしまうといった内容になっています。 なお、今年のセッションは PHP カンファレンス 2019 で最後です。トータルの登壇回数は 15 回で、発表時間は 270 分です。 詳しくは個人の note にポエムを添えてまとめていますので、ご興味があればご覧ください。 今年の登壇実績｜めもりー @m3m0r7 金城 @o0h_ Track5(会議室AB)にて発表をさせていただきました。 まず最初に、そして最も印象に残っているのは、満員になった会議室の光景です。 登壇の機会を頂いた身としては、聴衆の多さに緊張もしつつ、「こんなに多くの人と同時に自分の好きな話を共有できるんだなぁ」と嬉しく感じました。 今年のPHP Conference Japanでは、他の多くのセッションでも満員やそれに近い状態が生まれていた印象があります 。凄いパワーを持ったイベントだと思いました。こんなに熱量の濃い空間を創り上げてくれたスタッフの皆さんに、心より感謝を申し上げます。ありがとうございました！ さて、今回の内容は、自分自身が「そういう話があれば興味を持つかもな、聴いてみたい！」とプロポーザルを提出したものです。そのため、「知見を共有する」「知ってもらいたいな」という想いも大事にしつつ、コミュニティに対して「問いを投げかける」ような気持ちで臨みました。 25分という枠の中で語りきれたのは、ごく僅かな部分に過ぎません。が、もしこのセッションをきっかけに git clone git@github.com:composer/composer.git を試みた方が出てくれたなら最高です！！ 東口 @hgsgtk プラチナスポンサーとして協賛したので、BASEのスポンサーセッションを担当いたしました。また、懇親会LTでも発表させていただきましたので、それら両方の資料を公開いたします。 知見のない技術スタックをプロダクション導入するエンジニアの導入戦略 BASEのスポンサーセッションとして発表いたしました。私は、BASE株式会社の子会社である BASE BANK株式会社 にて、 YELL BANK（エールバンク） というサービスを開発する際に、技術選定を行いました。その際に感じた、" 技術選定という意思決定における不安 に対してどう立ち向かっていけばよいか"について資料として形にしてみました。 当日は、非常に多くの方に足を運んでいただく形になりました。「技術選定の意思決定を行ったことがある方がどれくらいいるか？」と会場に問いかけた際に8割くらいが「ある」という方だったため、同じような課題感や境遇に立ったことがある方が多いようでした。 発表後は、Twitter上にて共感の声や、「参考になった」というポジティブな反応がありひとまず一安心しました。 #phpcon #Track4 運用しないとわからないことがある わかる — アッキー (@akki_megane) December 1, 2019 #phpcon #Track4 話の中で「一般化」を何度も聞いた 素晴らしい発表、と思った 目指すところの高さを感じた — 央 (@sogaoh) December 1, 2019 分かりやすかったし勇気づけられた #phpcon #track4 — えすと👀 (@shostako_Vc) December 1, 2019 また、発表後にわざわざブースにおこしいただいて質問しに来てくださる方も複数いらっしゃり、"開発現場におけるテスト"や"技術評価の前段階にどういった準備をするか"など、改めて「自分がどうしたか？」と更に振り返る機会になり、大変有意義な時間になりました。 当日、会場にて聞きに来てくださった方々にはこの場を借りて改めて御礼申し上げます。 自作してみようxUnitフレームワーク こちらは懇親会LTにて話した内容です。今年のPHP Conference Japanでは、PHPエンジニアであれば一度は必ずお世話になったことがあるだろう PHPUnit の開発者である Sebastian Bergmann さんがスピーカーとしてドイツから来日していました。 日頃のPHPUnitへの感謝と愛を伝えようと思い、xUnitフレームワークを自作してみることで、改めてPHPUnitの凄さを知ろうという発表をしてみました。 これは余談ですが、Sebastian Bergmannさんとは前日のスピーカーディナーの際に直接話させていただきました。「PHPUnitを何故つくったのか？」という背景や、今後どういう構想があるのかといった話を聞かせていただきました。英語での会話はまだまだ難がある状態の私でも優しくゆっくり話していただき本当に素晴らしい方でした。もっと英語での会話力をつけてがっつり議論できるようになりたいと強く思った時間になりました。 おわりに PHP Conference Japan 2019 の実行委員長である板谷郷司さんをはじめ、実行委員会の皆様、また弊社エンジニアのセッションをご静聴してくださった皆様に心より御礼申し上げます。PHPコミュニティに対して協賛や登壇という形で微力ながら貢献できたこと光栄に思います。 来年の開催は10月11日 の開催とのことで、心より楽しみにしております。誠にありがとうございました！

この記事は、「BASE Advent Calendar 2019」の3日目の記事です。 devblog.thebase.in 前の日は id:ngsw の EC2における単位時間あたりの名前解決制限の対応 と id:chiiichell の エンジニア2年生がリーダブルコードを読んで今年自分が書いたコードを振り返る でした。 devblog.thebase.in Product Dev Divisionの加賀谷です。内部統制の実現手段の1つである「ITへの対応」について整備改善を日々進めています。社内の内部統制事務局と監査法人に評価とアドバイスをいただきながら、IT統制のうちの全般統制への対応を実施しています。 AnyPay社さんの GitHubを組織運営に活用する事例 にあるとおり、活動の中で行う文書管理、承認、証跡管理にGitHubがとても有効だと感じることが多くありました。この記事では先の記事に学び行ってきた中で、弊社のIT統制におけるGitHubの活用事例をご紹介したいと思います。 規程類の管理 GitHubにリポジトリを作り、規程類をMarkdownで統制項目毎に.mdファイルを作っています。アドバイスいただいたことをGitHub Issueに起こして議論を進め、規程の更新はプルリクエストを経てmasterへマージしています。GitHub Flowで運用していて、masterが現在適用されている統制の整備状況としています。 規程類は一度作り終えたら終了というものではなく、会社やサービスの維持と発展のために改善を加えていくものなので、どういった経緯でこの方法になったのか、どんなIssueからどんな議論がされたのか、追跡や検索ができることが大切です。そういった面からもGitHubはとても有効です。 PDFとホスティング また、GitHubとは直接関係ありませんが、規程類をMarkdownで書いておいて良かったことを紹介します。GitHubでMarkdownが表示できるとはいえ社外の監査法人とやりとりする時があるので、リポジトリに参加してもらうことは現実的に難しかったりします。そこで、スクリプトでMarkdownをPDFに変換しています。 markdown-pdf ではCSSでフォントや紙のサイズを指定することができるので、文書のデータと体裁を分けて考えることができます。concatもできるので、1つのMarkdownファイル毎に1PDFではなく、規程類のまとまり毎に1つのPDFにconcatしています。 pdf.js #!/usr/bin/env node const fs = require( 'fs' ), path = require( 'path' ), markdownpdf = require( 'markdown-pdf' ), config = require( 'config' ); const walk = (dir, callback) => { fs.readdirSync(dir).forEach((item) => { const filePath = path.join(dir, item); const stat = fs.statSync(filePath); if (stat.isDirectory()) { walk(filePath, callback); } else if (stat.isFile()) { callback(filePath); } } ); } ; config.get( 'pdf.docs' ).map(doc => { let strings = [] ; walk(doc.dir, filePath => { if ( /.*\.md$/ .test(filePath)) { strings.push(fs.readFileSync(filePath, { encoding: 'utf-8' } ).replace( /---[\s\S]*?---/ , '---' )); } } ); markdownpdf( { paperFormat: "A4" , cssPath: "pdf.css" , remarkable: { linkify: true , } } ) .concat .from.strings(strings) .to(doc.dest, function () { console.log( "created" , doc.dest); } ); } ); pdf.css body { font-size : 0.625em ; font-family : "ヒラギノ明朝 ProN W3" , "Hiragino Mincho ProN" , "ＭＳ Ｐ明朝" , "MS PMincho" , serif ; } abbr [ title ] : after , a [ href ] : after { content : "" ; } GitHubに参加していない社内メンバーに公開するには Docusaurus が便利です。Markdown+Docusaurusの活用については BASEの開発者様向け機能のドキュメントサイトをリニューアルしたときの記事 もご覧下さい。 特権IDの管理と承認 本番データベースなどの重要なシステムにアクセスする特別な権限を持つメンバーは、業務に応じてアクセス管理権限一覧に基づき設定しています。また特権の付与や権限を変更する際には責任者の承認を必要とするワークフローにしています。今誰がアクセス権限を持っているかの一覧、どういう理由で申請したのか、誰が承認したのか。ワークフローの構築と証跡管理、モニタリングにGitHubを使っています。 アクセス管理権限一覧をYAMLで書いておき、追加及び削除の申請はYAMLファイルへプルリクエストをして、必要な承認者のレビュー（PullRequestのapproved）を受ける運用にしています。承認者は CODEOWNERS に定義することでプルリクエスト作成時に自動で固定できます。 .github/CODEOWNERS ファイル自体のコードオーナーは、モニタリングするメンバーにしています。 まだ実施していませんが、gitリポジトリ内のYAMLファイルにすることでプログラムとの親和性が上がり、TerraformやAnsibleなどインフラ構成管理の中にも組み込むこともできると思います。 CODEOWNERS # CODEOWNERSの例です。 # デフォルト * @violetyk # 本番DBへアクセスするユーザの承認 /permissions/production_db.yml @dmnlk 障害管理台帳 前提として障害は起きないように策を講じるのですが、万が一事故や障害が起きたときには解決に至るまでを記録・管理する手段を講じておくことが必要です。 障害の記録や管理にはGitHub Issueを、Issueの自動作成にGitHub Actionを使っています。弊社では障害発生時のワークフローとして、Slackで #incident_yyyymmdd のようなチャンネルを作り現況報告をするところから始まります（Slackがダウンしていたら代替のチャットで）。 GitHub Actionで定期的に障害のチャンネルが作られているかどうかを監視し、あった場合にはGitHubに障害管理Issueを作ります。障害管理Issueは自動的に incident タグをつけて責任者にアサインされます。責任者が障害報告を書いて障害対応が終わったらIssueをクローズしています。 GitHubで管理し起票を自動化することで、報告漏れをなくし、未解決の障害や根本対応を要するものの定期的な棚卸しなどが容易になりました。 GitHub Action 障害のチャンネルを監視してIssueを自動で作るGitHub Actionは次のように書いています。 .github/workflows/create_issues.yml name : Create Github issues from Slack incident channels on : schedule : - cron : '0 1 * * *' jobs : build : runs-on : ubuntu-latest steps : - uses : actions/checkout@v1 - name : Set up Python 3.7 uses : actions/setup-python@v1 with : python-version : '3.7' architecture : 'x64' - name : Install dependencies run : | pip install --upgrade pip pipenv pipenv sync - name : Create issues env : SLACK_TOKEN : ${{ secrets.SLACK_TOKEN }} run : | YYYYMMDD=`date +"%Y%m%d" --date "1 day ago" ` pipenv run create_issues --repo=baseinc/info-system --term=${YYYYMMDD} --label=incident --assignee=xxxx JasonEtco/create-an-issue GitHub Actionの JasonEtco/create-an-issue はIssueをテンプレートから作るActionです。このActionを定期的に行う必要があるSaaSのアカウントの棚卸しタスクに使っています。GitHub Issueとして作成し、各SaaS管理者にアサイン、棚卸し内容を書いて終わったらクローズするという運用で証跡管理しています。 .github/workflows/create_issues_quarterly.yml name : Create issues quarterly on : schedule : # 1Q(1/1), 2Q(4/1), 3Q(7/1), 4Q(10/1) (UTC) - cron : '0 1 1 1,4,7,10 *' jobs : build : runs-on : ubuntu-latest steps : - name : Checkout uses : actions/checkout@v1 - name : Review Slack uses : JasonEtco/create-an-issue@v1.2.0 with : args : workflow_templates/review_accounts/slack.md 内部統制の環境整備と開発者体験の両立を目指して 弊社の事例をご紹介させていただきました。まだまだ手探りでやっているところが多いので、活用事例をお持ちの方いらっしゃったらぜひお話を聞かせていただきたいです。 コーポレートエンジニアのミッションは、ショップオーナーに安心してサービスを使い続けていただくために、業務の有効性及び効率性・財務報告の信頼性・事業活動に関わる法令などの遵守並びに資産の保全といった内部統制の環境整備と開発者体験の両立を考え続け、改善し続けていくことです。必要以上のルールや運用が難しい統制を固めることでサービスの成長スピードを落とさず、逆に加速できるよう、柔軟なバランス感を持って改善を進めていきたいと思います。 明日は id:khigashigashi と id:smdksk です。お楽しみに！ 「BASE Advent Calendar」の記事一覧はこちらです。 devblog.thebase.in

この記事は BASE Advent Calendar 2019 の2日目の記事です。 devblog.thebase.in こんにちは！BASEでFrontend Groupに所属している 三佐和 です。主にネットショップ作成サービス「BASE」のフロントエンドを担当しています。 2016年に未経験からBASEでインターンを開始し、その後正社員として入社しました。当時は主にLP などのマークアップや管理画面のUI に関わる細かい修正などを担当しており、使っていた技術は主にHTML, CSS, jQuery で、LP で使うような簡単なアニメーションの実装しかしたことがなかったのでJavaScript の知識はほぼ皆無でした。 今回のブログでは、 リーダブルコード を読みながら、今年1年間書いてきた自分のコードを振り返ってみたいと思います。 今年主に取り組んできたこと 昨年、ショップオーナーさんが使う管理画面のフルリニューアルプロジェクトが本格的に始動しました。 （プロジェクトについてのお話は、昨年のアドベントカレンダーでデザイングループの早川が 「BASE」の管理画面リニューアルプロジェクトのこれまでとこれから という記事を書いています。） それと同時期にフロントエンドチームが新たに発足し、インターンの頃から「アシスタントデザイナー」だった肩書きが「フロントエンドエンジニア」になりました。 （当時の心境） 「アシスタントデザイナーといいつつもデザインはできないし、自分は一体何者なんだろうって思ってきたけど、今日から私はフロントエンドエンジニアなのかー！嬉しい！」 Vue.js + TypeSrcript の新しいアーキテクチャを採用することになり、Vue.js の勉強が必要だと気付いた私… 勉強しながら、アウトプットとしてデザイナー向けにVue.js 勉強会 Vue Boot Camp を開催したりしました。 そして今年、管理画面リニューアルプロジェクトの中のひとつである注文管理画面のフロントエンド側実装を担当することとなりました。 （当時の心境） 「Vue.js なんとなく触ったりしたけど、これがWeb アプリケーションの中でどう書かれて、どう動くのか全然予想がつかない…こんな大きなプロジェクトにアサインされて大丈夫なのか…こわい…」 でもとりあえず、やっていき 2月に爆誕させてから、模索しつつ書いてきたコードたちを振り返ってみたいと思います。 コードを振り返ってみる ガード節を使って正常系と異常系を明確にする 全体の状態を管理するために HashMap を使用していましたが、HashMap は中身の変化を Vue が監視することができないため、代わりのキーとして updated を監視対象に含めることにしました。 修正前 class extends Vue { // ... ordersAt ( page: number ) : ReadonlyArray < Order > | null { if ( this .updated ) { return this .allOrdersMap.get ( page ) || null } return null } updateOrders () { // ... this .updated = + new Date () } // ... } レビュー あとで直しにくいし、読みにくくなるので、最後のreturn が異常系になるような書き方はあまりしないほうがいいです ガード節という考え方を使って typescript if(!this.update) { return null } を先に書くといいですよ 修正後 ordersAt ( page: number ) : ReadonlyArray < Order > | null { if ( ! this .updated ) { return null } return this ._allOrdersMap.get ( page ) || null } updated は Vue の都合のためのコードなので、それが存在しないのは明確に処理の実行が不可能になります。今回の場合は監視さえできればよいので、guard の方が適切です。 条件分岐を読みやすくする 条件によって表示が切り替わる処理です。期間の指定をしているかどうかで表示を変更します。 修正前 < template > // ... < p v- if= "!condition.from && !condition.to" > {{ __ ( 'すべての期間' ) }} < /p > < div v- else> < p > {{ format ( condition. from) }} < /p > 〜 < p > {{ format ( condition.to ) }} < /p > < /div > // ... < /template > レビュー こういうケースは not and not よりも、 or のみの方が分かりやすいと思うので、実際に期間を出す方を from or to とした方が良い感じがしますね 修正後 < template > // ... < p v- if= "condition.from || condition.to" > < p > {{ format ( condition. from) }} < /p > 〜 < p > {{ format ( condition.to ) }} < /p > < /p > < div v- else> {{ __ ( 'すべての期間' ) }} < /div > // ... < /template > !A and !B は最後まで読む必要がある上に、否定なので基本的に読みづらく、とにかく期間が指定されていれば表示を変えるのだから「どちらかが指定されていたら」という条件の方が自然です。 意図を伝える key な文字列となっている prop を実際の表示のために日本語に変換する処理です。 修正前 class extends Vue { // ... get paymentInfoTitle () { if( this .isCreditCard ) { return 'クレジットカード決済' } else if ( this .isBank ) { return '銀行振込' } else if ... { // ... } return '' } // ... } レビュー switch で書いた方が意図は通じやすいかなと思った 修正後 class extends Vue { // ... get paymentInfoTitle () { switch( this .$props.payment ) { case 'credit_card' : return 'クレジットカード決済' case 'bank' : return '銀行振込' // .... } } // ... } if-else ... としていくよりも、 switch でこのうちどれかになるという網羅性がある方が可読性も高そうです。 一度に一つのタスクを行う 選択されている検索条件をstring として表示させるための処理です。 修正前 class extends Vue { // ... get searchConditionStatus () { return this .searchCondition. status .map ( x => { return orderStatuses.find (status => { return status .key == x } ) !.name } ) .join ( ', ' ) } // ... } レビュー map などの関数型インターフェイスを利用する場合は一個一個の関数の処理を小さな単位で切り出す方が読みやすいです 今この関数は「 status をオブジェクトに変換して、 name を取り出す」という処理をしていますが、それを二つに分ける感じ 修正後 class extends Vue { // ... get searchConditionStatusLabel () { return this .searchCondition. status .map ( x => { return orderStatuses.find (status => { return status .key == x } ) ! } ) .map ( x => x.name ) .join ( statusSeparater ) } // ... } 小さい単位で処理を切り出すことで、概要が把握しやすくなりコードが読みやすいものになります。 プロジェクト固有のコードから汎用コードを分離する string として変換済みのお届け時間帯を、人が読める形式に戻す処理です。このような処理は、他の箇所でも登場する BASE ではお馴染みのものです。 修正前 class extends Vue { // ... deliveryTime ( time: string ) { const startTime = time.slice ( 0 , 2 ) const endTime = time.slice ( 2 , 4 ) if( time == '0812' ) { return '午前中' } return startTime + '〜' + endTime + '時' } // ... } レビュー このあたりの変換は timeslot-to-string のような機能として切り出してもよいかも 修正後 import { timeslotToString } from '~/util/timeslot' class extends Vue { // ... get deliveryTime () { return timeslotToString ( this .orderDetailDeliveryDate.delivery_time_slot ) } // ... } // ~/util/timeslot.ts export const timeslotToString = ( time: string ) => { const startTime = time.slice ( 0 , 2 ) const endTime = time.slice ( 2 , 4 ) if( time == '0812' ) { return '午前中' } return startTime + '〜' + endTime + '時' } Vue(View) から処理を抜き出すことで、他の箇所からも参照できる関数になりました。また、Vue での関心ごとが減り、コードが少なくなりました。 子コンポーネントの中からの視点でイベント名を決める 子コンポーネント内でチェックボックスを選択し、submit ボタンで $emit し、親コンポーネント内でモーダル（ hoge-modal ）を開く処理をします。 修正前 // 子コンポーネント < template > //... < bbq-button @click = "submit" > submit < /bbq-button > //... < /template > < script > //... class extends Vue { //... submit () { this .$emit ( 'show: hoge-modal' ) } //... } < /script > // 親コンポーネント < template > //... < 子コンポーネント @show :hoge-modal = "isHogeModalVisible = true" >< /子コンポーネント > //... < hoge-modal :show = "isHogeModalVisible" @cancel = "isHogeModalVisible = false" > //... < /hoge-modal > //... < /template > レビュー コンポーネントを設計していく上で、このコンポーネントは親コンポーネントの存在を知らないと考えるのが基本です そうなると子コンポーネントが出来ることは「 submit された」というイベントを送ることだけになります 子コンポーネントはイベントを受け取った親コンポーネントが何かを show するかどうかを知りませんし、 hoge-modal というものが存在することも知りません このイベント名だと、具体的な親コンポーネントが存在する前提のイベント名になるんですが、その逆で子コンポーネントの中からの視点でイベント名を決めるとしっくり来る名前になりやすいです 修正後 // 子コンポーネント class extends Vue { //... submit () { this .$emit ( 'submit' ) } //... } // 親コンポーネント < template > //... < 子コンポーネント @submit = "isHogeModalVisible = true" >< /子コンポーネント > //... < /template > 子が意識することは「 submit すること」だけなので、それに合わせてイベント名を変更しました。 リリースを終えて 無事に開発は進み、6月に 注文一覧ページ 、11月に 注文詳細ページ をリリースすることができました。 意識していたこと プルリクを作る単位を細かくする ついつい「ついでに」これも直しておこう、あれも直しておこう、と細かい修正を含めてしまい、結果的に大きなプルリクを作ってしまっていた為、なかなか作業中のプルリクをレビューに出せずにいました。 ひとつのプルリクに含まれるファイルの差分が大きくなればなるほど、その分レビューしてもらう範囲も大きくなり、レビューコストも高くなってしまうので、なるべく小さな単位でプルリクを作り、開発速度を上げられるよう意識しました。 コミットメッセージにはそのコミットにおける修正理由を書く リーダブルコードの第5章「コメントすべきことを知る」にも書かれているように、コードを読めばすぐに分かるような内容をコメントやコミットメッセージに書くのではなく、それぞれ、コードを読む人がそのコードを理解するまでにかかる時間を短くする為のコメント、どうしてこの修正をしたのかを伝える為のコミットメッセージを書くよう意識しました。 できるようになったこと 会話ができるようになった プルリク内で、「コードを書いた意図を聞かれて、それに対して自分の見解を述べる」というのはごく当たり前な光景かもしれません。ですが、注文管理のコードを書き始めた頃の私はとにかく動くものを作る、という一心でコードを書いていたため、明確な意図などなく継ぎ足し継ぎ足しで書いていくうちにコードが出来上がっていたため、レビューでコードの意図を聞かれても、なぜそのようなコードになったのか、自分の言葉でうまく説明できずにいました。 Vue.js を書いていくうちに、コードを書き始める前に「今自分は何を（実装）したいんだっけ」と一度頭で整理してから手を動かすようになり、「これを書けば期待する動きが実装できそう」と予測しながらコードを書けるようになり、それからやっとレビューをもらったときにそのコードを書いた意図を説明できるようになった気がします。当たり前のことではありますが、うまくできなかったことができるようになったということは、私にとってとても大きな変化でした。 予測できるようになった 上記の通り、Vue.js を書くことに段々慣れてくると、一度頭の中で整理する習慣がつきました。その中で、「この書き方は冗長だな」とか「ここは共通化したほうがすっきりするな」などと思うようになり、コードを読む人にとって読みやすいコードや自分も実装するときに頭の整理がしやすいようなすっきりしたコードを書けるよう、段々意識するようになりました。 「これってどういう動きをするんだろう…？」とひとつひとつ確かめながらコードを書いていた頃に比べると、うまく動く予想も、きっとエラーが出るだろうという予想もどちらもできるようになり、開発がしやすくなったように思います。 エラーをきちんと読むようになった 予想しながら書いたコードを実行した時にエラーが出ると「うっ…」となります。ですが、エラーは焦らず落ち着いてよく読むと、解決するためのヒントが書いてあり、何もこわいものではないということを学びました。 例えば、よくあるエラーでいうと (変数名) is not defined これは「 (変数名) なんて変数、定義されてないよ！」というエラーなので、まずタイピングミスがないかを疑います。 Object is possibly null これは「 null かもしれないオブジェクトに対する操作はできない」というエラーなので、 null じゃないことを保証すればいいんだな、とコードを見直します。 JS の勉強を始めたばかりの頃は、エラーが出たときに真っ先にエラー文をコピペして検索し、同じような事象やそれに対する解決策がないかを探していましたが、どこの行で起きているエラーなのか、エラー文をよく読み、 debugger や console.log() などを使用して、処理の流れを追いながらエラーの原因を探していくことが解決するための一番の近道だと気付いたことでエラー文を見ても冷静に対処できるようになったと思います。 まとめ 注文管理画面リニューアルプロジェクトが始動してから約9ヶ月間、ひたすらにコードを書き続けてきましたが、肩書きがフロントエンドエンジニアになったばかりの頃に比べて自分は何か少しでも成長できているのだろうか、フロントエンドエンジニアとしての仕事がしっかりできているのだろうか、と不安になることも多々ありました。 しかし、フロントエンドチームが発足してから徐々に人も増え、チームのメンバーが私の拙いコードを丁寧にレビューしてくれたり、質問や悩んでいることがあればいつでも聞いてくれるおかげで自分の弱点や改善点に気付き、時間はかかっているかもしれませんが、徐々にできることも多くなったと実感しています。 また、プロジェクトメンバーであるバックエンドエンジニアやデザイナーなど、プロジェクトに関わる人と同じ目線で相談事や提案ができるようになったことも自分の中では大きな成長でした。 プロジェクトメンバーの一員として、フロントエンド担当として、実装パターンが多岐にわたる注文管理画面の実装を完遂することができ、フロントエンドエンジニアとしての自信がつきました。次回携わるプロジェクトでも今回の反省や学んだことを生かして、開発を楽しみたいと思います！ 明日はCorporate Engineeringをやっている加賀谷さんと基盤Groupの川島さんです！お楽しみに〜！

この記事は BASE Advent Calendar 2019 の2日目の記事です devblog.thebase.in SREの ngsw です。 BASEはAWSを採用しており、その中でもEC2に大きく依存する部分があります。EC2においては以下の制約があります。 DNS の制限 VPC での DNS の使用 - Amazon Virtual Private Cloud DNS の制限 各 Amazon EC2 インスタンスは Amazon が提供する DNS サーバーへ送信できるパケット数を ネットワークインターフェイスあたり最大 1024 パケット/秒に制限しています。 この制限を増やすことはできません。 AWSのマネージドサービスはエンドポイントの提供になり、そのエンドポイントへのアクセスに名前解決は必要となります。BASE全体へのアクセス数は増加傾向にありますので、名前解決試行回数も同じく増加傾向にあると考えて良いでしょう。 「考えて良いでしょう」というのは平常時にはこの制約は顕在化せず問題視されないからです。 整理するとここでの課題は 突発的なアクセス増にも耐えうる名前解決方法を持ちましょう アクセス増時のスループットが名前解決制約で頭打ちにならないようにしましょう ということになります。 AWS における名前解決制約回避のベストプラクティス EC2 Linux での DNS 解決の失敗を回避する 実際の対応方法は上記の記事がすべてといっても過言ではありません。しかしそれらがそのまま適用できたわけでもありません。その差分や行間をあわせてお伝えできたら幸いです。 そもdnsmasqってなに？ dnsmasq - ArchWiki 具体的にはEC2インスタンス内部にDNSキャッシュサーバを持つことができます。簡潔に申し上げれば dnsmasqを起動させ 127.0.0.1:53 で応答させることにより当該の名前解決制約が回避できるということです。 念の為回避できないかもしれない状況を(推測ではありますが)上げておきます。 個別のFQDN 1024個超の秒間名前解決 IPv6名前解決 も 有効な状態で個別のFQDN 512個超の秒間名前解決(都度AレコードとAAAAレコードを解決しようとする) 今回お伝えした手順では dnsmasq はIPv6に関して問い合わせしないことを確認しました。 主題は「dnsmasq がAWSリゾルバ問い合わせを秒間1024回超行ってしまう事自体は依然として制約されている」になります。ですからCNAMEレコードの都度問い合わせやTXTレコードの include 記述なども関わってくる問題と考えます。 dnsmasq 設定内容 以下にどのように設定したかを書きました。 起動プロセス名 dnsmasq 実行User dnsmasq dnsmasq UID 5353 dnsmasq GID 5353 dnsmasq設定ファイル /etc/dnsmasq.conf 最大キャッシュTTL 2 最小キャッシュTTL 1 キャッシュレコード数 500 ネガティブキャッシュTTL 60 dnsmasq用resolvファイル /etc/resolv.dnsmasq リゾルバIP 169.254.169.253 VPC での DNS の使用 - Amazon Virtual Private Cloud dhclient設定ファイル /etc/dhcp/dhclient.conf timeout 300 retry 60 dhclientが設定するリゾルバIP 127.0.0.1, 169.254.169.253 supersede domain-name-servers 以下の観点を持っています。 UID / GID はわかりやすいものを dnsmasq自身のキャッシュ時間をいたずらに長くしない dnsmasqプロセスが死んだ場合であってもAWS外部リゾルバをバックアップとして利用しない UID / GIDについて 僕自身、UID / GID は明示しておきたいと考えるので明示した次第です。が、ここで現行環境適用時に問題が置きました。 サーバ構成は chef で管理されているのですが、dnsmasq導入以前に設定された既存ユーザにおいては UID / GID が明示されていない状況でした。 dnsmasq はサーバ設定の早い段階で入れておくのがよいだろうと考えたため、いの一番にインストールして設定するようレシピを書き換えたのですが、現在使用しているOSの仕様からか「UID / GIDを明示指定すると、それ以後に作成したユーザやグループは明示指定IDからのインクリメントになる」ということが起きてしまいました。つまり hoge 5354:5354 fuga 5355:5355 のような形です。 これでは既存のEC2と新規のEC2で差分がでてしまいます。構築時期によってサーバの状況が違うことになってしまうのはあまりいい気持ちではありませんので、レシピ自体を見直してすべてのユーザにUID / GIDを明記するよう変更しました。 dnsmasq自身のキャッシュ時間について 「キャッシュ時間をいたずらに長くしない」ということについてです。今回のdnsmasq導入目的は「名前解決制限という制約の解決」でした。ですので「1秒間だけキャッシュできればよく、それ以外の副作用を極力排除する」というスタンスでいました。キャッシュ時間を長くしたとしてもおそらくはTTLなりをみてdnsmasqはよしなに動作してくれると信じてはいるのですが、検証工数を最小にするために短い値を設定しています。 懸念を具体的に申し上げると「dnsmasqのキャッシュ時間を長くすることで、AWSマネージド・サービスがオートスケールした場合のALIASレコードを無視する時間が長くなるのではないか」でした。 dnsmasqプロセスが死んだ場合について 本来であればバックアップのDNSを外部に用意したいものですが、今回はその対応を行っていません。理由は「VPCオプションによるプライベートホストゾーンに依存しているから」となります。外部のDNSはこの情報を知り得ませんので、問い合わせができたところで期待した名前解決は行われず正常に動作しません。 先にも書きましたが今回の目的は「名前解決制限という制約の解決」に絞っていますので、完璧を目指すのではなく「よりよいものをなるだけ少ない工数で」という割り切りをしています。 「うまく機能しているのか」確かめよう 少なくともAWSリゾルバへの問い合わせ回数が激減しているか確かめられればいいかと思います。僕は tcpdump で確認しました。 #!/bin/bash while : do dig +short 01endpoint.example.com > /dev/null 2 >& 1 & dig +short 02endpoint.example.com > /dev/null 2 >& 1 & dig +short 03endpoint.example.com > /dev/null 2 >& 1 & dig +short 04endpoint.example.com > /dev/null 2 >& 1 & done 上記スクリプト dig.sh 程度でも効果はみてとれました。 chmod +x dig.sh # dnsmasq導入前 ./dig.sh tcpdump -s 0 -i any port 53 -w dnsmasq_before.pcap # dnsmasq導入後 ./dig.sh tcpdump -s 0 -i any port 53 -w dnsmasq_after.pcap ここで取得できた *.pcap を wireshark や Cocoa Packet Analyzer で比較してみましょう。 dnsmasq before 172.31.0.2 がAWSリゾルバ 都度問い合わせが発生していることがわかる dnsmasq after 169.254.169.253 がAWSリゾルバ 127.0.0.1 DOMAIN が dnsmasq この画像ではAWSリゾルバが存在しない程度にdnsmasqで完結していることがわかる 対応を終えて 前職もAWSを利用していたのですが、dnsmasqではなく外部DNSをリゾルバ指定する対応でした。今思えば「dnsmasqの恩恵でもあるレイテンシ軽減」を手放していたのだなとすら感じます。今回は採用例(AWSベストプラクティスだから当然なのですが)でしたがSREという立場を考えるともっとたくさんの不採用例を持たなくてはならないなと考えます。 「手段と目的を取り違えるな」という言葉があります。その反対側には「手段の数とその質こそが、何を目的にできるかを制約している」とも個人的には考えていますので、技術職としていろいろなツール/ソフトウェアを触って手数そのものを増やしていきたい、その経験でもってプロダクトに貢献していきたいともあわせて考えた次第です。

この記事は BASE Advent Calendar 2019 の1日目の記事です。 devblog.thebase.in こんにちはえふしんです。 11/27日に、Fukuoka Growth Nextで開催されたFGN Campに登壇してきました。僕とCAMPFIREのCTOである中川さんが登壇し、FGNに入居するスタートアップである株式会社クアンド の中野さんと、株式会社トイポの小神さんのお悩みを聞くという形式のパネルディスカッションでした。 growth-next.com その中の質問で、「エンジニアの採用は人物重視？スキル重視？」という質問がありましたので、この記事で触れてみたいと思います。 そもそも人間はモチベーションで動く生き物だと思います。とりわけ頭脳労働であるプログラミングについては創造性とセットで動くことが必要です。 インターネット以前、プログラミングを仕事にする人の仕事が「情報処理」が主流だった時代におけるプログラミングの作業は、製造業のメタファで言うブルーカラー的な職種だったのではないかと思うところがあります。まだコンピュータの処理速度も遅く、メモリの量も少ないため安定稼働のためにスキルが要る時代。更にHTMLのようなエレガントな情報伝達技術はなく、コンピュータフレンドリーなエレガントなロジックとViewをプログラマが作らないといけなかったわけですが、この頃は仕様を考えると言う行為よりも、圧倒的にプログラミングの負荷が高い時代だったので、コードを書く人たちは、ちゃんと動くプログラムを作ることに集中せざるを得ない。それが製造業的なメタファで、設計工程とプログラム工程の分離が求めらていたのだと考えられます。 その後、WindowsプログラミングでRADツールが出てきてGUIプログラミングが簡単になり、その後、さらにHTML、CSSなどのWeb技術が出てきて、フロントエンドのViewとサーバサイドのロジックは、その専門職毎の職能として分離されることになりました。Webの技術は少々、コードをミスってもブラウザが落ちるなんてことはありません。トライアンドエラーのしやすさと表現力が増えたことで競争原理が働き、ユーザーにとっては表現力豊かで使いやすい機能を享受するきっかけになります。 そうなるとインターネット時代のプロダクトは、コードを通じて作り手の創造性を表現する舞台としての要素が高まります。結果、競争力の源泉として作り手のビジョンが重要、いわゆる詳細設計とコードが同時に書かれることも増え、ある種の即興劇としてのプログラミングが重要な時代になりました。特にスタートアップの初期であればあるほど、プロダクトオーナーである経営者が最初にコードを書くことが求められるなど、プロダクトマーケットフィットを実現しユーザに刺さるプロダクトが作れることの方が大切になります。 これはいわゆるユーザ体験 = ユーザエクスペリエンスが重要であるということを示しています。 そういう時代においては、ユーザのことを意識して、ユーザさんに喜んでいただけるプロダクトづくりをポジティブに進めなくてはいけません。 さて、ここまで技術力という言葉が一言もでていないことに気が付きましたか？ Webを支えるバックエンドの技術やフロントエンドの技術はとても重要です。技術の移り変わりも激しく、継続するWebサービスにとってはインターネットトレンドの変化に対して常に最前線でいるためには技術力が必要です。 ところが、その技術力で支えられるWebのプロダクトは、よりよいユーザ体験を実現してなんぼです。どんなに安定したシステムもユーザさんが使ってくださらないと存在する意味がありません。そして、そのプロダクトのユーザ体験は、その会社の文化や思想によって生み出されます。その会社のカルチャーやプロダクト思想に共感し、賛同した上で、高度な技術を使ってプロダクトを支えるわけです。 つまり、人物重視か、スキル重視か、というと生産性は掛け算になります。 アウトプットの生産性 = その人がポジティブに動けること x スキル アウトプットを実現するためのスキルレベルは専門領域によって変わるので、スキルは役割を司るパラメータだと思ってもらうのが良いと思います。それに対して、その人の脳内物質がポジティブになっていなければ、その人がどんなに高いスキルを持っていても、よいアウトプットには恵まれません。 またソースコードを生み出すための労働生産性という視点では、知識労働者という人間のスペックに対して100%までが限界です。つまり、最速の開発を実現するためには、脳内の集中力と稼働率を100%に近づけることが理想です。そのためにも、作るものに対してネガティブ物質が脳内に分泌されてしまい余計な思考に邪魔されないことが大前提になると思います。 それ故に、エンジニアリングマネージャしかり、プロダクトマネージャやディレクターは、各メンバーが楽しくポジティブに働けるような環境つくりや、プロダクトの方向性を示していく必要がありますし、そこに共感可能な人材だけが、よいアウトプットを生み出すということになります。 厳格で真面目な人は「仕事」において「モチベーション」などというパラメータを持ち出すのはけしからんという人もいらっしゃるのですが、我々のプロダクトがユーザ体験を志向する限り、ユーザさんに寄り添ってプロダクトを作れなければエラー処理一つ取ってもイケてない実装になると思いますし、やはりポジティブなモチベーションは無視できないかなと思います。 もし、そこに期待できない場合は、エラー処理一つまで設計でガチガチに固めるしかなく、いわゆるウォーターフォール形式で開発せざるを得なくなるわけですが、Webのエンジニアがそれを嫌うのは皆様、御存知の通り。アジャイルとか様々な開発手法は提案されていると思いますが、その下地に、メンバーの高いモチベーションを生み出すことが大前提であるということは、あまり語られていません。 なので、冒頭の質問の回答をすると、 「もちろんスキルは必要だが、それよりも圧倒的に人物の方が重視、何が重視かというと作るものや我々のプロダクトの考え方に対するカルチャーフィットこそが重要」 という回答になると思います。我々の中では、「インターネットが好き」というのは１つの採用基準になっています。インターネットにつながるプロダクトに対する造詣が深いからこそ、ユーザに対してもコンピュータに対してもホスピタリティの高いプロダクトを作ることができ、結果としての工数最適化、手戻りの少なさにつながるわけです。