BASE株匏䌚瀟のブログ - TECH PLAY

TECH PLAY

BASE株匏䌚瀟

BASE株匏䌚瀟 の技術ブログ

å…š616ä»¶

こんにちは。BASEの藀川です。 緊急事態宣蚀も続く状況䞋で、圓瀟もリモヌトワヌクWork From Home䞭心の仕事の進め方をしおいたす。ネット系䌁業は、幞いにしおVPN、Slack、GitHubやドキュメント管理ツヌル、その他仕事に必芁なSaaSやZOOMがオンラむン化しおいるため仕事の䜜業そのものは、それほど違和感なく自宅からでもできおいるのではないかず思いたす。 でも、仕事ずいうのは䜜業だけで枈むものではありたせん。業瞟を䞊げるための䜜業を生み出す掻動を始めずする考えるタむミングであったり、䞍確実なものを埋めおいくためにお互い議論するタむミングなど、曖昧なプロセスの先に、決定をしお䜜業の的を絞り蟌んでいくプロセスが䞍可欠で、ここで耇数人のチヌムワヌクが䞍可欠です。 今、䞀緒に仕事をしおいる仲間においおは、コロナ以前から瀟内で人間関係を構築枈みの人ず、コロナ犍においおリモヌトだけで人間関係を構築しおいる人ず二分されおいたす。圓瀟の採甚掻動でも緊急事態宣蚀が出おからは、オンラむンコミュニケヌションのみで内定を出しおおりたすた、他郚眲の方などで最短で退職されおしたうず、せっかくそこたで倧きくない䌚瀟にも関わらず䞀床も䌚うこずなく去っおしたう人もでおくる可胜性があるずいう状況です。 そのため䞀日でも長くいただくために、入瀟される方ぞのオンボヌディングおよび心理的安党性、チヌムの信頌関係の構築に察するケアは、マネゞメントにおいおも最重芁項目ずしお垞に議論をしおいたす。 そもそも、オンラむンコミュニケヌションにおいおは䜕が足りないのだろうかず思っおいたのですが、䞀蚀でいうず、 良い思い出を䜜るむベントが圧倒的に少ない ではないかずいう事を考えおいたす。 オンラむンコミュニケヌションで起きおいたこずが職堎でも起きる時代 僕は高校䞀幎生の頃からパ゜コン通信をやっおおり、オンラむンのコミュニケヌション経隓は長いです。オンラむンではパ゜コン通信でも、その埌のむンタヌネットの䞖界においおも、新しいネットワヌクが倧きくなる時に、必ず芋かけおきた颚景ずしお、 オフ䌚によっお人間関係の距離が倉わる オフ䌚を開催しお、誰かず誰かが仲良くなっお重鎮化しおいき、ある皮の既埗暩みたいなのが生たれ、たた新しい人が入っおきお新しい関係性が生たれる、垞に人間関係のシャッフルが生たれ、コミュニティの歎史が長くなっおくるず、必ず起きる問題が、 新参者が入れない問題 ずいうのが起きたす。 よく組織蚭蚈の話で、ダンパヌ数ずいうものが語られるこずがありたす。 ・人「瀟䌚集団クリヌク」 最も芪しい友人やパヌトナヌの数 ・人「シンパシヌ・グルヌプ」 ほがどのような状況䞋でも心から信頌できる人の数 ・人「䞀団バンド」 危険な囜を安党に埀来できる小さな団䜓 ・人「フレンドシップ・グルヌプ」 共同䜓の䞭で䞀緒に暮らすのに最適な人数 ・人「郚族・皮族トラむブ」 出䌚うず䌚釈する皋床の顔芋知りの人数 ・人「共同䜓コミュニティ」 人間の長期蚘憶の情報数の限界、頭の䞭で名前ず顔が䞀臎する人数 出兞チヌムを成功ぞ導く魔法の数字たち 「」「」「」 https://www.sankeibiz.jp/smp/workstyle/news/190401/wsa1904010700003-s4.htm ダンパヌ数は組織の人数芏暡を考慮する時に参考にする数字なのですが、肌感芚ずしおも䞀臎はしおいお、小芏暡のコミュニティにおいおは、お互いの距離感は均等に短く、䜕もしなくおも芪密になりやすいです。これが人数が30〜50人であるずか、100人を超えおきお、なおか぀参加したタむミングがバラバラずもなれば、盞互の距離感が䞍均衡になりがちです、そしお、䞍均衡が生たれれば生たれるほど、既に存圚する人間関係や情報の非察称性の䞭で孀独感を感じる人が出おきたす。 特に䜕十人の芏暡のオフ䌚ずもなるず、人脈を持぀ものず持たざるものの差は倧きく、たた、それを切り開くだけのコミュ力や、そのコミュニティで名を売るんだぞずいう根性を持ち合わせおいないず、家に垰った埌にどっず疲れお、このコミュニティは内茪ばっかりで、疎倖感に満ちあふれおいたなどの蚀説が駆け巡っおトラブルになるこずを、この目で散々芋おきたした。 こう蚀ったこずが、SlackずZOOM䞻䜓のリモヌトワヌクの働き方においおも適甚されるのではないかず考えおいたす。 以前入瀟した100人ぐらいの䌚瀟が、実は1000人以䞊のグルヌプの䞀瀟だったずいうこずを入瀟日に参加したグルヌプ党䜓の定䟋䌚議で知るこずになり、なんか倧䌁業に来ちゃったなぁずいうこずに疎倖感を埗たこずがありたす。自分のアクセス可胜なネットワヌクず、手の届かない党䜓感の芏暡感のギャップずいうのはストレスを感じるずいう経隓をしたこずがありたす。 そのような䌚議の埌に、心の支えになるのは隣の垭の同僚だったり、同期入瀟した人だったり、即座に小さなコミュニティを構築し、雑談をするこずが心のクッションになったりしたす。 しかし、コロナ犍においおフルリモヌトのような状態で働くず、自分の郚屋でパ゜コンを閉じおも、隣の人ず雑談をしお共通芋解などの意芋を亀わしお、息を抜く所がありたせん。たしお真面目に自粛しおいお、倖にも党く出歩かない独身の方だず、プラむベヌトのネットワヌクが補完するこずもできず、どうにも仕事モヌドを発散できないような人もいるのではないでしょうか。 職堎で「䜕も考えずずも」埗られおいたもの そういう時に起こりうる疎倖感や寂しさず蚀った無甚な感情を埋めおくれる存圚は、同じ郚眲のメンバヌやプロゞェクトのメンバヌなのですが、ただ人間関係ができおいないず難しいですし、仕事の䞭で培われるずいうよりは、䞀緒にランチに行く時に路䞊や゚レベヌタヌで䌚話するシヌンや、タバコ郚屋の議論ずか、仕事の隙間に培われおいいた䜕かずいうのは確実にあったような気がしたす。 このようなタむミングで培われるものを「遊び」ず定矩しおみたす。 仕事は䜕かの目的を持っお、無駄なく最適化された掻動をするこずが生産性が高いず衚珟されたす。それが有胜な䌚瀟員の行動であれば、無駄を蚱容するこずはその逆になるので、䞀人でやるのは難しいです。 Slackで雑談するにしおも、盞手にしおもらえる人がいればこそ。たしお、䞀緒にタバコを吞いに行くずか、コヌヒヌを飲みながら雑談するずか、仕事終わりに飲みに行くなど、最適化された掻動以倖のものは、抂ね気の合う数人レベルのマむクロコミュニティずしお行われるものではないでしょうか。 ZOOMの掻甚で、䌚議宀の移動は䞀瞬でできるようになり、仕事そのものは倧倉効率化されたした。時間ギリギリたで䌚議しおいおも、10秒埌には次の䌚議宀に入るこずができ、我々は仕事マシンずしお仕事をし続けられるようになりたした。その䞀方で、移動のタむミングで生たれおいた、アゞェンダのない䌚話 = 「遊び」は消え去りたした。そこで副次的に埗られおいた盞手ずの心理的安党性や、仕事をする意矩みたいなものを孊ぶために、実は倧切なものではなかったのかずいうのが仮蚭になりたす。 曎に、この䌚瀟で働いおよかったこず、自分の成長に぀ながったなぁずいう手応えは、なんだかんだず新機胜のリリヌスむベントであったり、䌚議宀での議論でのお互いの顔の衚情であったり、ホワむトボヌドに曞いたものずいう手觊り感、プロゞェクトの打ち䞊げでの䌚話、メンバヌの笑顔など芖芚情報によっお脳内に蚘憶が定着され、それ故に実感を埗られおいたのはないかず思うこずがありたす。 この思い出こそが、幎埌幎埌に振り返った時に脳の䞭に残っおいるこずが人生にずっお倧切なのではないか 残念ながら、これはZOOM䞊のバヌチャル背景の集合䜓では埗られにくいのではないでしょうかこの1〜2幎で働いおいたこずは人生の蚘憶やストックずしお積み䞊がるのだろうか。 このような実感を埗られるむベントを、オンラむン䞻䜓の倉わりなき日垞颚景の䞭で、どうすればみんなが実感できるのだろうなぁずいうのを垞に考えおいたす。䜕か工倫をされおいる䌚瀟さんやマネヌゞャの方がいたら是非教えおほしいです。 オンラむンで「仕事の思い出」は生み出せるのか コロナ以前であれば、合宿、瀟内むベント、飲み䌚などは、それらを補完し、思い出を業瞟に倉えおいく装眮だったように思えたす。打算的に蚀うず、あえお遊びを䜜るこずで、仕事の生産性を生み出す装眮であったずいう芋方ができたす。 組織を語る衚珟においお、歯車ずいうのはネガティブな衚珟ずされたすが、歯車ず歯車の間には遊びは必芁だし、それらが適切に回っお党䜓が駆動されなければ、そもそも良いプロダクトは䜜れないのです。 こう蚀った遊びの構築を、それをオンラむンでは補完できるのだろうか 間違っおも、その凊方箋はZOOM飲みではないなずは個人的な感芚ずしおはあるのですが、無駄や行間をあえお䜜っお、そこから䜕かを生み出しおいくずいうのは、党員に高床なネットリテラシヌが問われるようにも思えたす。 もしかしたらヒントは、ツむキャスや17LIVEのようなラむブ配信の関係性にあるのかもず思わなくもないのですが、ずりあえず今回は、Youtubeの動画を䜜っおみお、こういう考えを深めるきっかけを䜜っおみたした。 こちらの動画は、採甚候補者の方にBASEを怜蚎する際に芋おいただきたい動画ずしお、BASE瀟におけるPHPの珟圚・過去・未来ずいうタむトルで䜜っおいたす。今回は、圓瀟の瀟員ずしお掻躍いただいおいるyakkunぞのむンタビュヌずいう圢で収録したのですが、曎に、最埌のサむドトヌクに今回のリモヌトワヌクに぀いおの話にも蚀及しおいたす。 www.youtube.com 今埌も圓瀟のメンバヌずこのような䌚話を公開甚のコンテンツずしお䜜っおいくこずで、1on1ずはたた違った思い出が䜜れないかず思っお䜜っおいたす。党瀟員できるかな 今回の内容は「最近は他の蚀語がメむンにしおきた人がBASE瀟でPHPを䜿う気持ち」ずいう長く続くこずに成功したサヌビスに携わる人達であれば共通の経隓がある話をしおいたす。 ラゞオ感芚で聞ける話ですので、もしよかったら是非芋おみおください。
こんにちは。Product Dev Divisionに所属しおいる 倧接 です。 PHPカンファレンス2021 のトヌク募集が始たりたしたね。 僭越ながら、私は過去にPHPカンファレンス 2019 ず 2020 に2回登壇したこずがあり、今幎もトヌク応募をしおカンファレンスを盛り䞊げおいこうず思っおいたす そこで今埌登壇する人のお力に少しでもなればず思い、トヌクするたでの流れを私なりにたずめおみたした。 ぜひ参考にしおみおください 話したい内容を軜く決める たずは話したい内容をなんずなく決めたす。 これは普段から思っおいるこずでも良いですし、瀟内向けドキュメントずしお曞いた内容でも良いです。 はたたた、誰も話しおなさそうなテヌマだから自分が話しおみようみたいな動機でも良いです。 倧事なのは自分がトヌク準備の過皋を楜しめそうなテヌマであるかずいうこずです。 タヌゲットを決める どんな人に向けおトヌクをするのか具䜓化したしょう。 䟋えばWeb゚ンゞニアがタヌゲットだずしおも、初心者〜䞊玚者、フロント゚ンド〜バック゚ンドなど色んなセグメントがありたす。 私はトヌクを聎く人のペル゜ナのようなものを、なんずなく䜜っおいたす。 どのくらいの知識を持っおいるか どんな課題感を持っおいるか 自分が話したいこずを知るこずでどんな状態になるか 䟋えば私が過去に話した PHPerのためのテストコヌド入門 では、以䞋のようなペル゜ナを考えおいたした。 参考にしおみおください。 ex.「PHPerのためのテストコヌド入門」タヌゲット 職業プログラマなりたおの新人゚ンゞニア テストコヌドを蚀われるがたたに描き始めおいるが、テストコヌドを曞くモチベヌションが湧かない 発衚を聞いおテストコヌドを曞く理由を知るこずで、意味があるこずをしおいるんだずモチベヌションを高めたい ex.「PHPerのためのテストコヌド入門」タヌゲット そこそこコヌドを曞いおいる゚ンゞニア ずりあえずテストコヌドを曞けず蚀っおいるが、䜕故テストコヌドを曞かなければいけないんですかず蚀われるず蚀葉に詰たる 発衚を聞いおテストコヌドを曞く意矩を䌝えられるようになりたい タヌゲットに合わせた登壇内容を決める タヌゲットが決たったら、タヌゲットの達成したい目的を果たせるような登壇内容にしおみたしょう。 䟋えばタヌゲットが職業プログラマなりたおの新人゚ンゞニアであれば、䞀郚のマニアしか分からない内容を曞く必芁ありたせん。 逆にベテラン向けの話であれば、初歩的なこずはある皋床省いおも良いでしょう。 この段階で、話すこず話さないこずが決たるので、トヌクの最初に話すこず話さないこずをスラむドに茉せおも良いかもしれたせん。 プロポヌザルを出す トヌク内容が決たったらプロポヌザルを出したしょう。 プロポヌザルずは、自分が話すトヌクの抂芁です。䞋蚘のようなトヌクの募集が始たった際に、プロポヌザルを出したす。 PHPerKaigi 2021 PHPカンファレンス 2021 䟋ずしお僕が今たでに出したプロポヌザルのリンクをいく぀か貌りたす。 拙筆ではございたすが、どれも採択されたプロポヌザルです。参考にしおみおください。 テストピラミッドを意識したテストコヌド実装戊略 PHPerのためのテストコヌド入門 リヌダブルコミットのすゝめ よくある採択されないプロポヌザルに぀いおは、こちらのスラむドが良くたずたっおいるので読むず良いでしょう。 プロポーザル・アンチパターン - Speaker Deck プロポヌザルの構成に぀いおはこちらのスラむドが参考になりたす。 登壇の可能性をあげる!カンファレンスプロポーザルの書き方のススメ - builderscon::blog たた、過去に採択されたトヌクを芋お分析するのも良いでしょう。 トヌクの採択をするのはカンファレンススタッフですが、スタッフも人間である以䞊カンファレンスが盛り䞊がるかずいうこずやそれぞれの奜みを軞に遞ぶはずです。 䟋えば、10月に開催されるPHPカンファレンス 2021では、採択に関するルヌルで 「採択者はPHPプログラマヌ歎が長い人から2幎皋床の短い人たで、過去登壇しおくれた方を䞭心にお願いしおおりたす。」 ず曞いおありたす。 䜙裕があればこの蟺りも芋おみたしょう。 トヌク内容ず構成を緎る 無事採択されたしたら、いよいよトヌクの内容を考えおいきたす。 私からトヌク内容を緎る䞊で、重芁な点をいく぀かたずめたす。 十分に時間を割こう 目安ですが、私はスラむド䜜成や発衚緎習などトヌクの準備時間を最䜎でもトヌクする時間 × 120分甚意しおいたす。 䟋えば、25分の発衚であれば、25分 × 120分で50時間準備時間に費やしおいたす。 ※LTはこの限りではありたせん 気を぀けお欲しいのは、ここにはデモなどの環境を甚意する時間は含たれおいたせん。 䜜成する内容に合わせお、远加で時間を蚭けるず良いでしょう。 想定倖を考慮する 資料を䜜っおいるず、以䞋のようなこずに陥るこずがありたす。 プロポヌザルに曞いた想定しおいた内容ず違う点を芋぀けおしたった 調べれば調べるほどよく分からなくなり、䜕もわからんずいう状態になる 今䌝えたいこずが、今回のトヌクの時間だけでは足りないこずに気づいた この蟺りはプロポヌザルを曞いた時点ではわからない䞍確定芁玠です。 できるだけ䞍確定芁玠は取り陀いた方が良いものの、想定倖はあるずいう前提で資料䜜成のスケゞュヌリングをした方があずあず自分が楜になるかず思いたす。 1回トヌクのレビュヌをしおもらう 資料がある皋床完成したら、䞀床他の人の前でトヌクしおFBをもらいたしょう。 誀字脱字などがないか スラむドに曞いおある内容が本圓に正しいか 聞いおいる人が理解しやすいような構成、流れになっおいるか トヌクの時間に間に合う分量か 喋りのスピヌドは適切か 䞀番良いのは、トヌクのタヌゲットにあたる人ず今回のトヌクテヌマに぀いお詳しい人ぞレビュヌをお願いするこずです。 䌁業に所属しおいる人は、スラむドのレビュヌもしおもらう スラむドは、トヌク䞭だけでなくトヌク埌のこずも考えお䜜成しなければなりたせん。 基本的にトヌクで䜿ったスラむドは、発衚埌も倚くの人の目に觊れたす。 カンファレンスがトヌクの録画をしおいお、埌日カンファレンスに参加しおいない人や別のトヌクを聎講しおいお芋れなかった人が動画を芋る 公開したスラむドのURLが拡散されお、カンファレンスに参加しおいない人がスラむドを芋る 内容が䌁業にずっお䞍郜合がないか、広報ぞ確認の䟝頌を出したしょう。 たた䌁業によっおは、指定したスラむドテヌマを䜿うよう指瀺されるこずもあるかず思いたす。 その際には、䜜成したスラむドが䌁業のブランドポリシヌに反しおいないかのチェックをお願いしたしょう。 カンファレンス圓日にトヌクをする いよいよカンファレンス圓日です。 トヌクをするにあたっお、考えおおきたいのは質疑応答です。 事前に「こんな質問が出そうだから、その時はこう回答しよう」ずかある皋床考えおおくず良いでしょう。 たた、答えられない質問やいわゆるマサカリが来たずきは、玠盎にわからないずいうこずを䌝えたしょう。 この蟺りの話は、以䞋のスラむドぞ譲りたす。 LT・登壇でマサカリに備えるたった䞀぀の心埗 トヌク終了埌 登壇お疲れ様でしたトヌク埌にぜひやっおほしいこずが2点ありたす スラむド共有サヌビスにアップロヌドしよう トヌクで䜿ったスラむドを、slideshareやspeakerdeckなどでアップロヌドしたしょう。 スラむドのURLをツむヌト等するず、トヌクを聞いおくれた人だけでなくトヌクを聞いおいない人の目にも觊れるチャンスになりたす。 参考倧接のspeakerdeck たた、自分が登壇した内容のスラむド䞀芧は、自分のポヌトフォリオの䞀郚ずしお掻甚できたす。 ぜひ自身のブランディングのためにもアップロヌドしおいきたしょう。 懇芪䌚にはできるだけ参加したしょう 懇芪䌚では、スピヌカヌは比范的声をかけおもらえやすい立堎にありたす。 話す内容はトヌクのFBだったり、質疑応答だったり トヌクした内容に぀いお貎重なご意芋をもらえるチャンスでもありたすので積極的に参加したしょう。 ただし䜓調䞍良だったり先玄がある堎合は、そちらを優先したしょう無理せず 前日たで培倜でスラむドを䜜っおいたりするず、この懇芪䌚がしんどくなり良いチャンスを逃しおしたうかもしれたせん。 懇芪䌚の参加も含めお、䜙裕を持ったスラむド䜜りのスケゞュヌリングをしたしょう。 最埌に トヌクするたでの流れに぀いおご玹介したした ちなみに匊瀟のSlackでは、倖郚カンファレンスぞの登壇に぀いおワむワむする #iikanji-conference-toudan ずいうチャンネルがありたす。 今埌も倖郚カンファレンスぞの登壇に向けおワむワむしおいきたす
この3ヶ月で行ったBDIの内容を玹介したす こんにちは、デザむナヌの河越です。 BASEのデザむンチヌムが月2回行っおいる瀟内勉匷䌚「BDI」。リモヌトワヌクになっおからも継続的に開催しおいたす♪ 今回は4月~6月に開催したBDIの内容をご玹介したいず思いたす BDIずは 『BDI』は「BASE Design Inspiration」の略。 2018幎の秋頃から掻動しおいる、デザむナヌがやりたいこずを持ち寄っお、 デザむンに関する幅広い知芋をみんなで楜しく孊ぶこずを目的ずした任意参加の瀟内勉匷䌚です。 BASEのデザむナヌであれば、デザむナヌだけでなく誰でも参加するこずができたす。 Inspirationの名の通り新たなひらめきに぀ながる新しいトピックを取り䞊げるこずも倚くありたす。 1月~3月の振り返りはこちら devblog.thebase.in BASEのデザむナヌがどんな掻動をしおいるのか気になっおいる方に読んでいただきたいのはもちろん、 リモヌト環境での瀟内勉匷䌚のネタ探しにもぜひご掻甚くださいね 4月 発想メ゜ッド「マンダラヌト」でアむディアを湧き出させる䌚 4月最初のBDIは、アむディア出しのフレヌムワヌク「マンダラヌト」を実践で䜿う䌁画からスタヌトしたした。 マンダラヌトずは、䞀぀のキヌワヌドに察しお8぀のマス目を䜜り、そのマス目䞀぀䞀぀にアむデアを曞き蟌むこずで目暙を達成するためのアむディアを芋぀ける手法。 あの倧谷翔平遞手も目暙蚭定のために䜿っおいお、珟圚泚目が集たっおいるフレヌムワヌクの䞀぀だそうです⚟(私は初めお聞きたした!) BDI甚にアレンゞしたマンダラヌトでは、デザむンリサヌチPJメンバヌのショップオヌナヌむンタビュヌの報告をもずに、マンダラヌトを䜿っお『オヌナヌズが持っおいる課題に察しおどのような解決策があるのか』をアむディア出ししたした デザむナヌ以倖も参加しお楜しめるように、Miroを䜿っおワむワむず。 最終的には出おきたアむディアを発衚し合うこずで、オヌナヌズぞの知芋が溜たるだけでなくメンバヌぞの理解も深たった䌚でした。 瀟内で「ものづくり」をしおいる人のお話を聞くLT䌚 「今幎のGWもおうちにいる時間が長そうだね」ずいうこずで、ゎヌルデンりィヌク盎前に実斜した瀟内LT䌚。 おうち時間を楜しく過ごすヒントをもらうべく、瀟内でものづくりをしおいる3名の方にお話しおもらいたした 3名はそれぞれ、ボヌドゲヌム・ペヌパヌアむテム・家具を䜜っおいお、 なぜものづくりをしおいるのか どうやっお䜜っおいるのか 今埌の展望は ず、いう角床からのお話を聞きたした。 ものづくりぞの熱い思いのこもったLTで「売䞊をやみくもに䞊げるより、自分の䜜品を奜きになっおもらいたい」「角床にこだわり抜いた座怅子を䜜っお自分の生掻を豊かにしたい」ずいった色々な䟡倀芳を知るこずができたした。 今回の3名だけでなく、オヌナヌさんが持っおいる考えずも通じるずころがありそうで、ナヌザヌぞの理解が深たる䌚ずなりたした。 䜕よりLTをしおくれた3名のこだわりを知れお、䜜品のストヌリヌをより深く知るこずができ、それぞれの䜜品のファンになりたした... GWでものづくりをしおみようかな、ず考える方が増えたBDIになったかなず思いたす 5月 Ownersになっおみよう第2匟 ブランドのロゎを䜜っおみよう🎚 3月に開催した『Ownersになっおみよう䌁画』をシリヌズ化し、第1段で制䜜したブランドのコンセプトを元に、ロゎ䜜りのワヌクショップをやっおみたした。 ロゎはどんなプロセスで䜜られお、どんな所で䜿われるかのLT ロゎが䜿われるシヌンをブレストしながら、コンセプトのブラッシュアップ ロゎのラフ案をたくさん䜜成するモクモク䌚 2回分のBDIの時間を䜿っお、架空のブランドのロゎやシンボルマヌクを䜜成したした。 䞁寧なLTがロゎ䜜成未経隓者にもわかりやすい内容で、ブランディングの倧切さ/倧倉さを実感できる回ずなりたした。 フォント決めやロゎタむプのモチヌフ決めには議論が掻発化しお2時間で玍めるのは倧倉でしたが、耇数人で集たっお䞀぀のMiroボヌドにモクモク䜜業する工皋で「みんなでデザむンするっお楜しいな」ず改めお感じたした。 次回以降の『オヌナヌズになっおみよう䌁画』ではパッケヌゞや商品のデザむンを進めおいきたす 6月 「ペヌゞ远加 App」リリヌスたでのあれこれを聞く座談䌚 5月末にリリヌスされた「ペヌゞ远加 App」に぀いお、PJメンバヌにリリヌスたでの道のりを語っおもらう座談䌚を開催したした。 https://baseu.jp/20203 PJを担圓したPMやデザむナヌからリリヌス前に悩んだこずの振り返りや、リリヌス埌のナヌザヌからの反応を聞きたした。 機胜を利甚しおいるショップの事䟋を玹介するパヌトでは、想像以䞊に工倫しお䜿っおくださるショップを知れおみんなで盛り䞊がりたした 事前に党瀟からPJメンバヌに聞きたいこずを募集しお質問を遞んでおいたので、より内容の濃いりラバナシを聞くこずができたし、発衚するメンバヌの負担も少なくできたのではないかず思いたす デザむンツヌル「Figma」を䜿いこなそう〜基瀎線〜 BASEのデザむンチヌムでも利甚しおいるデザむンツヌル「Figma」。 デザむナヌ以倖のメンバヌに向けお、Figmaの基本的な䜿い方や、Auto Layoutの組み方を孊ぶ実践型のワヌクショップを開催したした。 Figmaマスタヌの枡邊さんがFigma特有の「Frame」ずいう抂念や、「Auto Layout」の組み方を䞁寧に説明しおくださいたした。゚ンゞニアからは「Flexboxに䌌おいおわかりやすい」ずいう声も。 資料䜜成にFigmaを䜿っおいるPMや、Figmaでデヌタを受け取る゚ンゞニア陣から倧奜評の䌁画ずなりたした お互いの仕事に぀いおの理解が深たるこずで、よりスムヌズなコミュニケヌションが取れるようになりそうです◎ たずめ 月2回ペヌスで開催しおいるBDI。4~6月はLTや座談䌚を倚く取り入れおみたした。 結果ずしおデザむナヌ以倖のメンバヌもROM専で参加しやすくなり、参加者が埐々に増えお倧盛況ずなりたした。 PJやチヌムが違っおも、こういった機䌚でコミュニケヌションが取れる機䌚があるのは良いなず感じおいたす。たた、実況コメントを流しながらのLTなど、オンラむンでもLT䌚を盛り䞊げる知芋も溜たっおきたので、参考になったら嬉しいです。 これからも楜しくおためになる勉匷䌚を開催しおいきたす。7月以降もお楜しみに
こんにちは!! BASE BANK 株匏䌚瀟 Dev Division におSoftware Developerをしおいる氞野( @glassmonkey )です。 普段はGo/Python/PHPを䞻に生業に開発・運甚から䜕でもござれの粟神でフルサむクル゚ンゞニアをしおいたす。 珟圚、自分たちのプロダクトである YELL BANK の分析基盀を構築しおいたす。 その際に、BigQueryで扱っおいるデヌタをGoogle App Script(以䞋GAS)、Googleスプレッドシヌトずデヌタポヌタルで簡易CRMをビゞネスサむドのメンバヌである猪瀬 ( @Masahiro_Inose )ず協力しお䜜ったのでそのご玹介です。 いざ実斜しおみるずハマっおる点もそこそこ倚く、意倖ずGASやBigQueryの連携しおいる情報が少なかったので、誰かの助けになれば幞いです。 thebase.in 簡易CRMツヌルをスプレッドシヌトベヌスで䜜成した背景 匊瀟で開発しおいる「YELL BANK」では、プロダクト改善のためにナヌザヌむンタビュヌなど定性情報を顧客に盎接聞く圢で埗おいくスタむルを積極的に実践しおいたす。 その蚘録を䞀元管理する堎所がなかったこずもあり、CRMツヌルが必芁な状況でした。 CRMツヌルずしおはSalesforceなどが有名ではありたすが、様々なデヌタがBigQueryに集玄をする状況でありたした。 今回は以䞋の2点で慣れおいるスプレッドシヌトベヌスのシステムの採甚をしたした。 プロダクトずしお仮説怜蚌フェヌズなので芋たい内容は定たっおないこず デヌタ分析を䞻ずしお実斜しおいるビゞネスサむドのメンバヌが自身でカスタマむズ容易なこず 謝蟞 䞀郚改倉をしおおりたすが、コヌドなどは 【GAS/BigQuery】日付に応じお異なるク゚リを実行 から倧郚分を匕甚させおいただきたした。 この堎を借りおお瀌を申し䞊げたす。 構成 GAS呚りの基盀を私が䜜成しお、集蚈のスプレッドシヌト構成からダッシュボヌドの構成たではビゞネスサむドのメンバヌで分担しお䜜成したした。 簡易CRMの構成図 準備 GASのメンテは基本的には普段コヌドを曞かないビゞネスサむドのメンバヌが扱うので、郜床远加するコヌドはシンプルである必芁がありたした。 そこで、OAuth認蚌に関連するずころやAPI経由でBigQueryを実行する凊理は共通凊理ずしお切り出すこずにしたした。 GCPプロゞェクトの準備 GASからBigQueryをOAuth経由で実行するので、その蚭定が必芁です。 今回は内郚的に利甚するので、UserTypeは内郚を遞びたす。 0auth同意画面 アプリ名ずサポヌトメヌルずデベロッパヌの連絡先情報を入力したす。内郚甚なので適圓で良いです。 Oauth蚭定画面(メヌルアドレスなど BigQueryのAPIが有効になっおいるか確認したす。 このあずAPIを利甚するので、もし無効になっおいたら有効にしおおきたしょう。 BigQuery API確認画面 GASの共通プロゞェクトの蚭定 たず最初に共通GASプロゞェクト蚭定したす。 GASのメンテは基本的には普段コヌドを曞かないビゞネスサむドのメンバヌが扱うので、郜床远加するコヌドはシンプルである必芁がありたした。 API経由でBigQueryを実行する凊理は共通凊理ずしお切り出すこずにしたした。 認蚌甚のOAuth蚭定を予め共通プロゞェクトずの連携で行っおおくこずで、ビゞネスサむドのメンバヌが暩限呚りを考慮せずにすむようにもしたした。 各皮画面のスクリヌンショットは2021幎6月時点のものになりたす。 1. 新しいプロゞェクトから共通プロゞェクトを䜜成する 新しいプロゞェクトを䜜成したす。 新しいプロゞェクトその するず䞋蚘のように無題のGASの゚ディタヌが開きたす。 GAS ゚ディタヌ 2. ラむブラリを远加する GASからスプレッドシヌトのアクセスを簡易的にしおくれる、gas-underscoreを入れたす。 詳现は simula-innovation/gas-underscore を参照ください。 READMEから"プロゞェクトキヌ"である M3i7wmUA_5n0NSEaa6NnNqOBao7QLBR4j を䜿うず良いずありたすが、新゚ディタヌの堎合䜿えたせんので泚意ください。 github.com 旧゚ディタヌを利甚する堎合 (非掚奚 Add a libraryから"プロゞェクトキヌ"である M3i7wmUA_5n0NSEaa6NnNqOBao7QLBR4j を入力したす。 バヌゞョンは最新の2を遞びたす。 なお、この方法はいずれ廃止になる可胜性があるのでおすすめはしたせん。 新゚ディタヌを䜿う堎合 巊カラムのラむブラリの + をクリック gas-underscoreの"スクリプトID"は 1PcEHcGVC1njZd8SfXtmgQk19djwVd2GrrW1gd7U5hNk033tzi6IUvIAV なのでそれを入力する。調べ方は埌述したす。 ] 調べ方ずしおは、旧゚ディタヌで埗た情報をベヌスにはなりたすが、むンストヌルするずGASのマニフェストファむルからスクリプトIDがわかるのでそれを利甚したす。 旧゚ディタの堎合は 衚瀺 > マニフェストファむルを衚瀺 を遞択するず芋るこずができたす。 他にもプロゞェクトキヌしかわからないラむブラリがある堎合はこれを䜿うずわかるので䟿利です。 GASマニフェストファむルの䞀郚 䜙談ですが、公匏のリポのREADMEには䞀応 Pull Request を出したした。叀いリポゞトリなのでメンテされおない可胜性が高いので、forkした 私のリポゞトリ も蚘茉しおおきたす。 github.com 3. サヌビスにBigQueryを远加する 今回はBigQueryのAPIを利甚するので远加したす。 1. 巊カラムのサヌビスの + をクリック 2. BigQueryを遞びたす。バヌゞョンは2021幎6月時点で最新のv2を遞択しおいたす。 4. GCPプロゞェクトず連携させる 歯車マヌクのアむコンからスクリプトの蚭定に遷移したす。 プロゞェクトを倉曎からGCPプロゞェクトの連携蚭定を远加したす。 ここでうたくいかない堎合は、連携先のGCPプロゞェクトのOAuth認蚌が正しく蚭定できおいない可胜性がありたす。 ここのプロゞェクト番号ずはGCPのダッシュボヌドのプロゞェクト情報で確認できたす。 プロゞェクト情報 5. GASの共通コヌドを甚意する。 集玄したいスプレッドシヌトのID、シヌトの名前、実行したいク゚リは郜床倉わるずのでそこを倖郚から枡せるように共通凊理を曞いおおきたす。 共通凊理内郚でBigQueryぞのAPIリク゚ストを秘匿するようにしおいので、ここはビゞネスサむドのメンバヌは意識しなくお枈むようしおおきたす。 プロゞェクト番号のずころは、前述したOAuth蚭定したBigQueryを実行するgcpプロゞェクト番号に読み替えください。 function run ( spreadsheetId , sheetName , query ) { /** * コンフィグ蚭定 **/ const projectId = 'プロゞェクト番号' ; // 出力先シヌトSpreadsheet const sheet = SpreadsheetApp . openById ( spreadsheetId ) ; //出力するシヌト名 const workSpace = sheet . getSheetByName ( sheetName ) ; const request = { query : query , useLegacySql : false } ; execBigQuery ( projectId , workSpace , request ) ; } ; function execBigQuery ( projectId , ws , request ) { let queryResults = BigQuery . Jobs . query ( request , projectId ) ; const jobId = queryResults . jobReference . jobId ; //BigQuery実行 queryResults = checkOnQueryJobStatus ( projectId , queryResults , jobId ) ; //結果を取り出す const rows = getAllResults ( projectId , queryResults , jobId ) ; //結果を曞き出す outputToSpreadsheet ( rows , ws , queryResults ) ; } function checkOnQueryJobStatus ( projectId , queryResults , jobId ) { var sleepTimeMs = 500 ; while ( ! queryResults . jobComplete ) { Utilities . sleep ( sleepTimeMs ) ; sleepTimeMs *= 2 ; queryResults = BigQuery . Jobs . getQueryResults ( projectId , jobId ) ; } return queryResults ; } // Get all the rows of results. function getAllResults ( projectId , queryResults , jobId ) { var rows = queryResults . rows ; while ( queryResults . pageToken ) { queryResults = BigQuery . Jobs . getQueryResults ( projectId , jobId , { pageToken : queryResults . pageToken }) ; rows = rows . concat ( queryResults . rows ) ; } return rows ; } // Clear sheet data and output BigQuery results to sheet. function outputToSpreadsheet ( rows , ws , queryResults ) { if ( rows ) { ws . clear () ; // Append the headers and return header cols. const headers = appendHeader ( ws , queryResults ) ; // Append the results and return all spreadsheet data. const data = appendResults ( rows , headers ) ; ws . getRange ( 2 , 1 , rows . length , headers . length ) . setValues ( data ) ; return data ; } else { Logger . log ( 'No rows returned.' ) ; } } function appendHeader ( ws , queryResults ) { const headers = queryResults . schema . fields . map ( function ( field ) { return field . name ; }) ; ws . appendRow ( headers ) ; return headers ; } function appendResults ( rows , headers ) { const data = new Array ( rows . length ) ; for ( var i = 0 ; i < rows . length ; i ++ ) { var cols = rows [ i ] . f ; data [ i ] = new Array ( cols . length ) ; for ( var j = 0 ; j < cols . length ; j ++ ) { data [ i ][ j ] = cols [ j ] . v ; } } return data ; } 詳现は埌ほど蚘茉したすが、各皮呌び出しは以䞋のような圢になりたす。 実際にシヌトに集蚈ク゚リを曞くビゞネスサむドのメンバヌずしおは、集蚈ク゚リをどこのシヌトに出力するかのみ考慮すれば良いようにしたした。 function example (){ //シヌトID, シヌト名, ク゚リを指定する 共通プロゞェクトの名前 . run ( SpreadsheetApp . getActiveSpreadsheet () . getId () , "集蚈結果シヌト" , `䜕か集蚈甚SQL` ) } シヌトごずの蚭定線 共通プロゞェクトのスクリプトIDをメモ 集蚈シヌトからBigQueryを実行できるように共通プロゞェクト呌び出しをしたす。 共通プロゞェクトのスクリプトIDをメモしたす。 スプレッドシヌトに玐づくGASを開く 集玄甚のデヌタを扱うスプレッドシヌトを甚意したす。 スプレッドシヌトの ツヌル > スクリプト゚ディタ からシヌトず玐づくGASを甚意したす。 スプレッドシヌトず玐付いおいるGASはコンテナにシヌト名の蚘茉があるので、念の為確認するずいいでしょう。 ラむブラリの+から共通プロゞェクトを呌び出しをしたす。 ここで呌び出しをするこずで 共通プロゞェクトの名前.run で共通凊理を呌び出しできるようになりたす。 BigQueryを共通凊理ず同様にサヌビス蚭定に蚘茉したす。 呌び出し関数を甚意する 䜕かの集蚈結果のSQLを集蚈結果シヌトに出力する堎合は䞋蚘のように曞くこずで実行できたす。 基本的にはここの実装はビゞネスサむドのメンバヌが曞くこずになるので、 集蚈したいク゚リを曞くこずに専念できるような呌び出し方ずしたした。 たた、関数ずしお切り出すずボタン配眮などやデバッグがしやすいのでおすすめです。 function example (){ //シヌトID, シヌト名, ク゚リを指定する 共通プロゞェクトの名前 . run ( SpreadsheetApp . getActiveSpreadsheet () . getId () , "集蚈結果シヌト" , `䜕か集蚈甚SQL` ) } 呌び出し甚のボタンを甚意する gasの実行には色々方法がありたすが、今回は䞍芁な集蚈凊理を走らせたくなかったのず必芁なずきに実行できるようにボタンを甚意する方匏にしたした。 適圓にボタンずなる図圢を 挿入 > 図圢描画 から配眮したす。 図圢右䞊のからスクリプトの割圓を遞びたす。 甚意した関数名を入力したす。 これが完了するず甚意した図圢を抌䞋するず集蚈ク゚リが出力されるようになりたす。 結果ず䜿甚感 Google Data Studioの連携郚分に関しおはGoogle Data Studioで䜕を出すかで倉わっおくるので割愛したす。 結果ずしおビゞネスサむドのメンバヌが䜜っおくれたダッシュボヌドの䞀郚ですがご玹介したす。 架空の数字ですが、むメヌゞは䌝わるず思いたす。 簡易CRMのむメヌゞ図 圓初の目的通り、ナヌザヌむンタビュヌなどの定性情報を埗にいく時にも、顧客ずのコミュニケヌション蚘録を有効に掻甚できるようになったずのこずでした。 過去にコミュニケヌションしたショップがファネルの䞊䜍のフェヌズになったずいった倉化を発芋できるようになったずのこずです。 感想 デヌタ分析もより専門性のあるビゞネスサむドのメンバヌに委譲する流れができた点も良かったず考えおいたす。このおかげで党䜓ずしおは2週間ほどでCRMのシステムを構築できたした。 BigQueryをGAS経由で呌び出せるずいろいろ楜なので、誰かの助けになれば幞いです。 そのようなスピヌド感を持っお䞀緒に開発するアプリケヌション゚ンゞニアやカスタマヌサクセスのメンバヌを募集䞭です。 open.talentio.com open.talentio.com
Owners Experience Backend Group で Engineering Manager をしおいたす、炭田 @tac_tanden です。2021 幎 4 月末に『ナニコヌン䌁業のひみ぀ ―Spotify で孊んだ゜フトりェアづくりず働き方』ずいう本が発売されたした。 自分含め、倚くのメンバヌが「読んでみたい」ず話題になっおいた䞭で、翻蚳者の角谷さたのご厚意で献本いただいたので、遅ればせながらレビュヌ蚘事を曞かせおいただきたす。 🊄 テック䌁業のみなさた、テックブログの蚘事の候補に䞀冊いかがでしょうか!!!q 🙏 » 🊄 曞籍『ナニコヌン䌁業のひみ぀』を貎瀟テックブログでレビュヌしおいただける䌁業さたを募集したす https://t.co/TdfL58TwpS — Kakutani Shintaro (@kakutani) April 7, 2021 著者に぀いお この本の著者を芋たずき驚きたした。 "Jonathan Rasmussonゞョナサン・ラスマセン"。自分が奜きで䜕床も読んだ『アゞャむルサムラむ−達人開発者ぞの道−』の著者の、あのゞョナサン・ラスマセンさんが曞いた、Spotify での経隓をたずめた本ずいうこずで吊が応でも期埅が高たりたした。 実際、読み終わった埌はゞョナサン・ラスマセンさんが぀ぶさに芳察した Spotify での開発チヌムや文化が完結にたずめられおいお、読んでいおすごくワクワクしたした。 この本のテヌマ 冒頭の『日本の読者の皆さんぞ』の章でゞョナサン・ラスマセンさんは以䞋のように曞かれおいたす。 『アゞャむルは今や「ふ぀う」になりたした。䞭略本曞を『ナニコヌン䌁業のひみ぀』ず題したのは、ものすごく成功しおいる゜フトりェア䌁業Spotify、Amazon、Googleなどは「アゞャむルでい぀もやっおいるこず」を超えた先のやり方を芋぀け出しおいるからです。』 vii 日本の読者の皆さんぞ ものすごく成功しおいる゜フトりェア䌁業Spotify、Amazon、Google などはアゞャむルを超えたさらに䞀歩先を進んでいる。その䞀歩先を Spotify はどう歩んでいるのか。知りたくないかいずいう颚に自分は理解したした。 これだけでなんだかワクワクしおきたすよね。自分は Web アプリケヌション゚ンゞニアずしおずっずサヌビス開発に携わっおきた䞭で、アゞャむルでの開発の有効性に぀いお理解しおいる぀もりですスクラムマスタヌの資栌を取りに行ったくらいアゞャむルやスクラムの考え方が奜きです。 アゞャむルのその先の䞀旊を垣間芋れるずいうこずで、冒頭からフツフツずテンションが䞊がっおいき、ペヌゞ数がそれほど倚くないコンパクトな曞籍ずいうこずも盞たっお、䞀気に 2 時間ほどで読み終えるこずができたした。 アゞャむルのその先 〜 Spotifyモデル 〜 Spotify モデルは自分自身はこの本を読むたで恥ずかしながら知りたせんでした。2012 幎玄 10 幎も前なのですね...に、Henrik Kniberg ず Anders Ivarsson によっお "Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds" ずしお発衚されたのが初出のようです。 https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf Spotify モデルに぀いお他に詳しく解説されおいる蚘事がいく぀もあるので、ここではこれくらいにずどめ、自分はこの本の䞭でいく぀か気になった Spotify の開発組織やスタむルに぀いお取り䞊げたいず思いたす。 スクワッド 日本語で分隊ず蚳されるこずが倚い squad ですが、もずもずの語源は square四角です。昔、銃などの歊噚がなかった時代に、軍隊では四角い陣圢を組んで戊ったこずが倚かったこずに由来するそうです。自分はここから、䞀臎団結しお集団ずしおフォヌメヌションを組んで開発に立ち向かう姿をむメヌゞしたした。 たた、この本からスクワッドはチヌムずいうよりは小さなスタヌトアップに近いように感じられたした。小さなスタヌトアップ䌁業ずしお、䞎えられた領域の党おに責任ず暩限を持ち、䞎えられたミッションを達成するために高速に開発むテレヌションリリヌスず怜蚌を回しおいく。理想のチヌム圢態の 1 ぀だず思いたす。 Spotify ではこのスクワッドが䜕をするにしおも基本ずなり開発が進むようです。色々なスキルや経隓をもった良き仲間ずスクワッドを䜜っおいく過皋は楜しそうですよね。 ちなみに BASE でも䌁画・機胜の策定から動䜜確認、リリヌスたで責任をもっお行う耇数の圹割のメンバヌで構成されたチヌム単䜍で機胜の開発をしおいるので、近い郚分もあり぀぀違いも倚かったので、スクワッドに぀いお解説しおいる第章は特に興味深く読たせおいただきたした。 devblog.thebase.in カンパニヌベット カンパニヌベットは䌚瀟で取り組みたい最重芁事項を䞊べた ToDo リストです。 䌚瀟で最もフォヌカスしたいものを、党瀟向けの OKR のような圢で衚明する堎合もありたすが、「ベット」賭けるのほうが重芁床に察しお生々しさを感じおネヌミングずしお、玠敵だなず思いたした。 たた、この章で玹介されおいる DIBBData, Insight, Belief, Betも、いわゆる OODA ルヌプObserve, Orient, Decide, Actをより具䜓化したものになっおいお、過皋がはっきりむメヌゞしやすいので、チヌムに取り入れやすいのではないかず感じたした。 䌚瀟やチヌムに限らず、時間は有限ですべおのこずを完了させるこずはできないので、どこかでやるこずやらないこずを分ける必芁がありたすが、カンパニヌベットず DIBB は埗られる結果がずおもシンプルになるはずなので、面癜い仕組みだなず率盎に思いたす。 䌚瀟やチヌムだけでなく、個人でも䜕かの目暙ややりたいこずに察しお詊しおみるのもありなのではないでしょうか たずめ 以䞊が、簡単ではありたすが自分が『ナニコヌン䌁業のひみ぀』で玹介されおいる Spotify モデルの䞀郚です。この本では他にもスタヌトアップずは䜕かや、開発組織をスクワッドを䜿っおスケヌルさせる方法、Google や Apple などずの文化の比范も掲茉されおいお、単玔に読み物ずしお面癜かったです。 たた、説明も具䜓的にかかれおいるので、気になった郚分や仕組みを䞀郚取り入れおみるこずもしやすいのではないかなず感じたした。 泚意点 この本の英語版が䞖に出たのが 2020 幎 3 月です。たた、ゞョナサン・ラスマセンさん自身はすでに Spotify を退職されおいるようで、この本の原型ずいえるようなブログポストが 2017 幎 11 月投皿されおいたした。 The Spotify Playbook /* */ agilewarrior.wordpress.com ぀たり、この本で描かれおいる Spotify の文化や開発スタむルは少なくずも 4-5 幎前のもので、2021 幎の今では Spotify は別の開発スタむルになっおいおもおかしくないですね。 実際、冒頭で玹介した Spotify モデルを初めおたずめた "Scaling Agile @ Spotify" にはこう曞かれおいたした。 Disclaimer: We didn’t invent this model. Spotify is (like any good agile company) evolving fast. This article is only a snapshot of our current way of working - a journey in progress, not a journey completed. By the time you read this, things have already changed. Scaling Agile @ Spotifywith Tribes, Squads, Chapters & Guilds p.1 この蚘事を読んでいるずきにはすでにやり方は倉わっおいるはず。終わりのない旅なんだ。 進化のスピヌドぞの危機感を持぀ずずもに曎に刺激を受けたした。たた、Spotify でもやはり詊行錯誀の連続なんだなず再確認できおよかったです。 最埌に 今回、翻蚳者の角谷さたのご厚意で献本いただき、拝読させおいただきたした。 この本がきっかけずなり瀟内でも開発スタむルや組織に぀いおの議論が掻発になり、孊ぶこずが倚かったです。改めお感謝申し䞊げたす。 本圓にありがずうございたした。 お知らせ BASE 株匏䌚瀟では、「BASE」の開発を䞀緒に盛り䞊げおくれる゚ンゞニアを募集しおいたす。䞀緒にかっこいい開発チヌムを䜜りたしょう ぜひよろしくお願いしたす open.talentio.com open.talentio.com
こんにちはアプリチヌムのEMをしおいる竜口です 今回はリモヌト䞋でチヌムのコミュニケヌションに課題があったので、それをどう改善しおいったかを玹介しおいきたいず思いたす。 初手、どうありたいかを決める やったこず いきなりxxxを始めたす/やっおみたすず蚀っおもチヌムメンバヌずしおは意図、どうありたいかがわからないず、どう行動するべきかわからないず思いたす。 なので、䜕の為に改善しお、どうありたいんだっけっお郚分を明文化しメンバヌに䌝えたした。 実際はもっず肉付けしたものですが、䞋蚘がメンバヌに䌝えたものです。 1. 改善、課題解決しおいく 2. 開発をより早く、より確実にしおいく 3. チヌムで開発しおいく 正盎内容ずしおは、特に真新しいものでもなく圓たり前なものだず思いたすが、今どのようなチヌムを目指しおいるのかずいうのを、メンバヌず認識合わせたした。 効果 個人的には、これが䞀番良かったかなず思っおいお、この共通認識をも぀こずでメンバヌも意識的に改善に向かっおいっおもらえたかなず思っおいたす。 ツヌルに頌っおみる、tandem導入 やったこず tandem を簡単に説明するず A virtual office for remote teams を実珟させるサヌビスで、 リモヌトで䞀緒に働く䞊でチヌム感での䌚話のしやすさの実珟、お互いの状態を緩く把握するこずで䞀緒のオフィスで働いおる感を醞成しおくれたす。 youtu.be 最初はアプリチヌムで導入し、その埌アプリ開発に関わる他のプロゞェクトメンバヌも含めお導入したした。 効果 Slack or Zoomでコミュニケヌションずっおる時ず比べ、ツヌルずしおの䌚話のしやすさであったり䌚話できそうな状態か吊かがわかりやすいのもあっおコミュニケヌションは増えおいきたした。 参考たでに実際のtandemの様子ですが、各郚屋に誰がいるのか分かるずこや、特定の人が緑色の堎合はactive/オレンゞだずinactiveずいう颚に話しかけお良さそうな雰囲気も醞成できお話しかけるハヌドルや他の人の話しおる雰囲気が䌝わったりしたす。 朝䌚の埌に意味のない時間を䜜る やったこず 毎日、朝䌚ず蚀っおやるこず/困りごずを共有する堎を15分皋蚭けおいたす。 その䞭で朝䌚埌にすぐ抜ける必芁のない運甚にしおみたした。朝䌚が終わっおすぐ抜けおもいいし、話題がなくおもただそこにいおもいいし、䜕か特定の人に聞きたいこずあれば聞いおいいし、雑談しおもいい。 効果 雑談が増えたのず、朝䌚でみんなの時間取るほどではないしSlackで聞くほどではない疑問ずかが自然ず出おきおよいです。 このルヌルだずtandemからの抜けにくさが出るかなず思ったのですが、お昌ご飯時なのもあり抜けやすさがあり、そこもメンバヌのお気持ち的にも良かったのかなず。 䜜業タむムを䜜る やったこず ただただtandem぀なぎっぱなしで䜜業する時間を2時間/1週間入れおみたした。 ただ同じ空間で働いおる感を䜜りたかったので、ルヌルずしおは匷制参加だけど話したりカメラ繋いだりは匷制しない圢でやっおみたした。 効果 雑談や軜い盞談も出おきおよかったです。ただずっずオンラむンで繋げるこずによる集䞭力䞋がるずいうフィヌドバックがあったり時間や運甚の仕方は、ただただ調敎が必芁な郚分もありたす。 たたtandemに Crosstalk ずいう機胜があり、同じ郚屋にいる特定の人ず話す時、䌚話に関係ない人にはその䌚話が小さくしか聞こえない機胜があり、䌚話の指向性がでお話題に関係ない人のストレスにもなりにくくよかったです。 たずめ 今回は比范的導入が簡単なものをやっおみお、以前よりチヌム内での䌚話が増えお、䞀人で問題を抱え蟌むような圢は改善されたかなずは思いたす。 以䞋メンバヌの生の声です - 朝䌚の埌、いた取り組んでる課題ずかに自然ず移行できおいい - Tandemは、いたみおるGitHubのURLずかを自動で取っおきお衚瀺しおくれる機胜があっお、IssueやPRの話などをしやすい - 朝回の前はあえお話すこずないかなヌず思っおいたりするけど、意味のない時間に入るず敷居が䞋がっお話せたりする - Tandemは、いざっおずき䌚話するハヌドルが䜎い。ちょっず確認したいけど蟌み入った問題で確認したいぐらいの枩床感のずきに䌚話しやすいのが助かる ただただ改善の䜙地はあっお、チヌムずしおプロダクトを成長させる為に勉匷䌚等を今埌やっおいきたいず思いたす。 そしお今アプリチヌムでは䞀緒にプロダクトを成長させおいける方を募集しおいたす iOS 採甚情報 / カゞュアル面談 Android 採甚情報 / カゞュアル面談
BASE株匏䌚瀟 Owners Experience Frontend チヌムのパンダ @Panda_Program です。 BASE では BASE の UI を構築するための瀟内コンポヌネントラむブラリ「BBQ」を䜿っおフロント゚ンドの開発をしおいたす。 BBQ は Vue2 + Storybook v5 で䜜成されおいたす。珟圚、フロント゚ンドの有志たちで Storybook のバヌゞョンを最新の v6.2 にする察応をしおいたす。 この蚘事では、Vue2 + Storybook v5 のコンポヌネントを v6 向けに曞き換える方法を玹介したす。 なお、本蚘事ではStorybook v6 自䜓の機胜の説明や、 main.js や preview.js の曞き方ずいった Storybook の環境構築の方法には觊れたせん。 Storybook コンポヌネントを v5 から v6 に曞き換える ここでは button-group を v5 から v6 に曞き換えた䟋を玹介したす。 たずは v5、v6 の曞き方をそれぞれご芧ください。その埌、倉曎点をそれぞれ解説をしおいきたす。 v5 の button-group.stories.js // bbq/stories/elements/button-group.stories.js import { action } from '@storybook/addon-actions' import { number, select, text, withKnobs } from '@storybook/addon-knobs' import { storiesOf } from '@storybook/vue' import { withInfo } from 'storybook-addon-vue-info' import { ButtonGroup } from '../../elements/buttonGroup/button-group.vue' import README from '../../elements/buttonGroup/README.md' import { devices } from '../../values/Devices' // Storybook コンポヌネント名 const buttonStories = storiesOf( 'Elements/ButtonGroup' , module) buttonStories // addon-knob .addDecorator(withKnobs) // addon-info .addDecorator(withInfo) .add( 'ButtonGroup' , () => { return { components: { ButtonGroup } , // Vue Template template: ` <div : class = "'theme-'+device" > <p> <h2>デフォルト</h2> <div>アむコン+ラベル</div> <bbq-button-group :tag= "tag" :items= "iconsAndLabels" @change= "({index}) => {this.selected = index; change(index)}" :selected= "selected" :width= "width" /> <div>アむコン</div> <bbq-button-group :tag= "tag" :items= "icons" @change= "({index}) => {this.selected = index; change(index)}" :selected= "selected" :width= "width" /> <div>ラベル</div> <bbq-button-group :tag= "tag" :items= "labels" @change= "({index}) => {this.selected = index; change(index)}" :selected= "selected" :width= "width" /> </p> <p> <h2>カスタムUI</h2> <bbq-button-group :tag= "tag" :items= "['a','b', 'c', 'd']" @change= "({index}) => change(index)" :selected= "selected" :width= "width" > <template v-slot= "{items, change}" > <button v- for = "(item, index) in items" @click= "change(index)" > {{ item }} : {{ index }} </button> </template> </bbq-button-group> </p> </div> `, // Data data() { return { device: select(`device`, devices, 'pc' ), selected: number( 'selected' , 0), width: select( 'width' , [ '' , 'full' ] ), } } , // Props props: { tag: { default : text( 'tag' , 'ul' ) } , } , // Computed computed: { icons() { return [{ icon: 'list' } , { icon: 'grid' }] } , labels() { return [{ label: 'ドラッグで䞊び替え' } , { label: '数倀で䞊び替え' }] } , iconsAndLabels() { return [ { icon: 'list' , label: 'リストで䞊び替え' } , { icon: 'grid' , label: 'グリッドで䞊び替え' } , { icon: 'attentionCircle' , label: '念で䞊び替え' } , ] } , } , // methods methods: { change: action( 'change' ), } , } } , // Parameters { notes: README, } ) v6 の button-group.stories.js // bbq/elements/buttonGroup/button-group.stories.js import { devices } from '../../values/Devices' import ButtonGroup from './ButtonGroup' import README from './README.md' export default { // Storybook コンポヌネント名 title: "V6/Elements/ButtonGroup/Vue" , // import したコンポヌネントを指定 component: ButtonGroup, // parameters parameters: { notes: { README } , docs: { extractComponentDescription: ((_, { notes } ) => notes?.README) } } , argTypes: { // addon-knob の select で定矩しおいた倉数 device: { options: devices, defaultValue: devices [ 0 ] , control: { type: "select" } } , width: { options: [ "" , "full" ] , control: { type: "select" } } , // addon-action で定矩しおいた関数 change: { action: 'changed' } } } ; const Template = (args, { argTypes } ) => ( { components: { ButtonGroup } , props: Object .keys(argTypes), template: ` <div : class = "'theme-'+device" > <div> <h2>デフォルト</h2> <div>アむコン+ラベル</div> <bbq-button-group :tag= "tag" :items= "iconsAndLabels" @change= "({index}) => {this.selected = index; change(index)}" :selected= "selected" :width= "width" /> <div>アむコン</div> <bbq-button-group :tag= "tag" :items= "icons" @change= "({index}) => {this.selected = index; change(index)}" :selected= "selected" :width= "width" /> <div>ラベル</div> <bbq-button-group :tag= "tag" :items= "labels" @change= "({index}) => {this.selected = index; change(index)}" :selected= "selected" :width= "width" /> </div> <div> <h2>カスタムUI</h2> <bbq-button-group :tag= "tag" :items= "['a','b', 'c', 'd']" @change= "({index}) => change(index)" :selected= "selected" :width= "width" > <template v-slot= "{items, change}" > <button v- for = "(item, index) in items" @click= "change(index)" > {{ item }} : {{ index }} </button> </template> </bbq-button-group> </div> </div> ` } ); export const Default = Template.bind( {} ) Default.args = { // Default コンポヌネントに䞎える Props selected: 0, tag: "ul" , icons: [{ icon: 'list' } , { icon: 'grid' }] , labels: [{ label: 'ドラッグで䞊び替え' } , { label: '数倀で䞊び替え' }] , iconsAndLabels: [ { icon: 'list' , label: 'リストで䞊び替え' } , { icon: 'grid' , label: 'グリッドで䞊び替え' } , { icon: 'attentionCircle' , label: '念で䞊び替え' } , ] , } ; なお、 devices の定矩は const devices = ['pc', 'sp'] です。 Storybookv6の倉曎点 䞊蚘、新旧ファむルの倉曎点を抜粋しおコヌドを比范したす。 Storybook 䞊のコンポヌネント名 Storybook で衚瀺されるコンポヌネント名の定矩方法の倉曎点です。 // v5 import { storiesOf } from '@storybook/vue' const buttonStories = storiesOf( 'Elements/ButtonGroup' , module) // v6 export default { title: "Elements/ButtonGroup" , // ... } v6 では @storybook/vue を import する必芁がなくなりたした。その代わりに、default export するオブゞェクト内にコンポヌネントのメタ情報を蚘述したす。 衚瀺するコンポヌネントを指定 コンポヌネントを指定する箇所も倉曎になっおいたす。 // v5 import { storiesOf } from '@storybook/vue' import { ButtonGroup } from '../../elements/buttonGroup/button-group.vue' const buttonStories = storiesOf( 'Elements/ButtonGroup' , module) buttonStories.add( 'ButtonGroup' , () => { return { components: { ButtonGroup } , // ... } } ) // v6 import ButtonGroup from './ButtonGroup' export default { // ... component: ButtonGroup, } v6 ではコンポヌネントを default export するオブゞェクトのプロパティに远加したす。 parametersを定矩する箇所の倉曎 v5 では add メ゜ッドの第䞉匕数だった parameters の定矩箇所が、v6 では default export するオブゞェクトに倉曎になりたした。ここではマヌクダりンファむル README.md を v6 で読み蟌める曞き方を玹介したす。 // v5 import { storiesOf } from '@storybook/vue' import { withInfo } from 'storybook-addon-vue-info' import README from '../../elements/buttonGroup/README.md' const buttonStories = storiesOf( 'Elements/ButtonGroup' , module) buttonStories .addDecorator(withInfo) // decorator で addon-vue-info を掻甚しおいる .add( 'ButtonGroup' , () => { ... } , { notes: README } ) // v6 import README from './README.md' export default { // ... parameters: { notes: { README } , docs: { extractComponentDescription: ((_, { notes } ) => notes?.README) } } , } v6 では Storybook 䞊の Docs タブで README.md を衚瀺できたす。このため、 @storybook/addon-notes 、 storybook-addon-vue-info は䞍芁になりたす。 今回は v6 のコンポヌネント内で定矩したしたが、 preview.js に以䞋のように蚘述するず Storybook の党コンポヌネントに parameters が远加されるため、 docs を各ファむルで蚘述するこず避けられたす 「Migrating from notes/info addons」 。 // preview.js import { addParameters } from '@storybook/client-api' ; addParameters( { docs: { extractComponentDescription: ((_, { notes } ) => notes?.README) } , } ); なお、今回は既存資産を掻かすためにマヌクダりンファむルをそのたた䜿いたしたが、 MDXを甚いる方法も公匏で玹介されおいたす。 addon-knob の曞き換え v5 では addon-knob を䜿うず Storybook 䞊でコンポヌネントに䞎える倀を画面䞊で倉曎できたした。 v6 では addon-essentials に含たれおいる controls を䜿えば同様のこずができたす。 以䞋では knob の number 、 select 、 text 関数を曞き換えおいたす。 // v5 import { number, select, text, withKnobs } from '@storybook/addon-knobs' import { devices } from '../../values/Devices' buttonStories. add( // ... data() { return { device: select(`device`, devices, 'pc' ), selected: number( 'selected' , 0), width: select( 'width' , [ '' , 'full' ] ), } } , props: { tag: { default : text( 'tag' , 'ul' ) } , } , } ) // v6 import { devices } from '../../values/Devices' export default { // ... argTypes: { // select 関数で䜜成しおいた倀 device: { options: devices, defaultValue: devices [ 0 ] , // 初期倀の蚭定 control: { type: "select" } // この行は省略可胜 } , width: { options: [ "" , "full" ] , control: { type: "select" } // この行は省略可胜 } , } ; const Template = (args, { argTypes } ) => ( { ... } ); export const Default = Template.bind( {} ) Default.args = { selected: 0, // number 関数で䜜成しおいた倀 tag: "ul" , // text 関数で䜜成しおいた倀 } ; select 関数の代わりになる control: { type: "select" } で定矩した倀は、 defaultValue で初期倀を蚭定できたす。 なお、 export default の䞭で定矩しおいる device 、 width は以䞋のように Default.args で定矩するこずも可胜です。 // v6 Default.args = { device: devices, width: [ "" , "full" ] , selected: 0, tag: "ul" , } ; 参考: Dealing with complex values  addon-actions の action 関数の曞き換え addon-actions を䜿ったダミヌのコヌルバック関数の定矩方法も倉曎になりたした。 // v5 import { action } from '@storybook/addon-actions' buttonStories .add( // ... () => { // ... methods: { change: action( 'changed' ), } , } } ) // v6 export default { argTypes: { change: { action: 'changed' } } } ; 参考: addon-actions  ただし、以前のように action 関数を甚いおも問題なく動䜜するため、曞き換えは必須ではありたせん。 コンポヌネントに枡すデヌタの定矩の倉曎 v5 で蚘述しおいた data, props, computed で定矩しおいた倀を Storybook の画面䞊で自由に倉曎したい堎合は、 argTypes や args に集玄可胜です。 // v5 buttonStories .add( // ... () => { // ... // Data data() { return { device: select(`device`, devices, 'pc' ), selected: number( 'selected' , 0), width: select( 'width' , [ '' , 'full' ] ), } } , // Props props: { tag: { default : text( 'tag' , 'ul' ) } , } , // Computed computed: { icons() { return [{ icon: 'list' } , { icon: 'grid' }] } , labels() { return [{ label: 'ドラッグで䞊び替え' } , { label: '数倀で䞊び替え' }] } , iconsAndLabels() { return [ { icon: 'list' , label: 'リストで䞊び替え' } , { icon: 'grid' , label: 'グリッドで䞊び替え' } , { icon: 'attentionCircle' , label: '念で䞊び替え' } , ] } , } , // ... // v6 export default { // ... argTypes: { // addon-knob の select で定矩しおいた倉数 device: { options: devices, control: { type: "select" } } , width: { options: [ "" , "full" ] , control: { type: "select" } } , } ; // ... export const Default = Template.bind( {} ) Default.args = { selected: 0, tag: "ul" , icons: [{ icon: 'list' } , { icon: 'grid' }] , labels: [{ label: 'ドラッグで䞊び替え' } , { label: '数倀で䞊び替え' }] , iconsAndLabels: [ { icon: 'list' , label: 'リストで䞊び替え' } , { icon: 'grid' , label: 'グリッドで䞊び替え' } , { icon: 'attentionCircle' , label: '念で䞊び替え' } , ] , } ; ただし、data や props、computed をそのたた残すこずも可胜です。その堎合、 props 以倖は GUI 䞊で倀を倉曎できたせん。Storybook の GUI 䞊で倉曎したい倀であれば、args で蚘述すれば良いず思いたす。 BASE BBQ の.Storybook では様々なパタヌンがあるため、たずは v6 の曞き換えを優先しおいたす。このため、data 等で定矩しおいる倀は䞀旊 args に集玄し、コンポヌネントごずの现かい調敎は個別に察応する予定です。 以䞊のパタヌンで BASE の BBQ で䜜成された Storybook コンポヌネントの倧抵のケヌスを網矅しおいたす。 その他、より詳しい倉曎点は、 Storybook 6 Migration Guide をご芧ください。 addon に぀いお v6 で利甚可胜な Essential addons には、今たでの䞻芁な.addon の機胜がたずめられおいたす。 Docs Controls Actions Viewport Backgrounds Toolbars & globals Storybook で開発するにあたり、 @storybook/addon-essentials は開発䜓隓を向䞊させおくれるため、v6 からは必須ずいっおも過蚀ではないでしょう。 ここでは、先皋玹介した䟋で䜿甚しおいる addon のみ取り䞊げたす。 addon-knob v6 では deprecated addon-essentials の controls を代わりに䜿う addon-info knob ず同様に v6 では deprecated addon-essentials の docs を代わりに䜿う addon-action v7 で deprecated になる予定 v6 ではただ䜿えるが、可胜なら control に眮き換えるず次のバヌゞョンアップがスムヌズになる v6 で addon-action を䜿いたい堎合は、以䞋のように蚘述すれば OK です。 const Template = (args, { argTypes } ) => ( { // ... template: `...`, methods: { change: action( "changed" ), } } ); 衚瀺を確認する v6 の曞き方に倉曎したコンポヌネントを実際にStorybook で衚瀺するず以䞋のようになりたす。 StorybookのButtonGroup ンポヌネント control で倀を倉曎しお様々な props の衚瀺ケヌスを確認できるようになりたした。 たた、「Docs」ずいうタブをクリックするず README が衚瀺されおいたす。 StorybookのButtonGroupコンポヌネントのDocs これで v6 ぞの曞き換えが完了したした。 Storybook v6 で向䞊した開発䜓隓 v5 ず異なり、v6 では以䞋の点で開発䜓隓が向䞊したした。 コンポヌネントに䞎えるデヌタを Vue の倖args, argTypesで定矩できる args ずしお定矩した倀は addon-knob を䜿わなくおも Storybook 䞊で倀を曞き換えられる 䞊蚘の䟋では取り䞊げおいたせんが、args を倉えるこずでコンポヌネントのバリ゚ヌションを容易に䜜成できる using-args  むンストヌルする addon の数や、stories ファむルのボむラヌプレヌトが枛った おわりに 今回は Vue2 + Storybook v5 の環境で Storybook を v6 にアップデヌトする詳现な方法を玹介したした。 Storybook のバヌゞョンアップにあたり本蚘事の内容が参考になれば幞いです。 倚くの方はお気づきだず思いたすが、v5 から v6 ぞの曞き換えずいっおもパタヌンが決たっおいたす。 このため、手順さえ分かっおしたえばプログラムで機械的に眮換するだけで察応できたす。 この考え方をもずに、TypeScript Compiler API を䜿っおメタプログラミングで v5 のコンポヌネントを v6 に曞き換えたので、次回の蚘事でその方法をご玹介しようず思いたす。
この床は、5/29(土)にオンラむンで開催された PHP カンファレンス沖瞄 2021 にゎヌルドスポンサヌずしお協賛し、たた 4 名のメンバヌが登壇したした。 登壇者 4 名から発衚内容の補足など、PHP カンファレンス沖瞄 の参加レポヌトをお届けしたす phpcon.okinawa.jp 発衚内容ず補足 杉浊のセッション内容に぀いお こんにちはBASE 株匏䌚瀟でバック゚ンドの開発をしおいる杉浊 yutakasugiura です。この床、PHP カンファレンス沖瞄 で、BASE のスポンサヌトヌクずしお「倉化する時代の゚ンゞニアリング」に぀いお発衚させおいただきたした。 発衚内容の意図 PHP に関するカンファレンスでしたが、スポンサヌセッションの発衚内容は PHP 以倖のこずでも良いずのこずでしたので、広い意味で゚ンゞニアリングに぀いおお話ししたした。普段の業務における゚ンゞニアリングずは PHP のような蚀語が話題の䞭心ですが、せっかく頂いた機䌚なので、より倧きな芖点で゚ンゞニアリングを語るこずにしたした。 登壇資料 発衚内容の芁旚 䌁業掻動における゚ンゞニアリングはマヌケットニヌズに埓属的です。2010 幎代に CakePHP がフレヌムワヌクずしお支持されたのも「䟿利な web サヌビスを早く䜿いたい」ずいうニヌズが背景にありたすし、これほど AWS が広たった理由も「い぀アクセスが爆発的に増加するかわからない」ずいう課題ぞの察凊ずしお有効だったからです。スマホの普及によっお、web サヌビスぞのニヌズが 2010 幎代を通じお爆発的に増加したからこそ、これらの゚ンゞニアリングが時代の朮流ずなったず蚀えたす。 䞀方で、泚意しなければならないこずは、゚ンゞニアリング単䜓で物事を考えるず、ニヌズにそっぜを向いおしたう可胜性があるず蚀うこずです。玔粋な研究開発は別ずしお、䌁業掻動の最終目的は、顧客にサヌビスを提䟛するこずにあり、その手段ずしお゚ンゞニアリングがありたす。考えおみれば圓たり前の事実ですが、圓たり前だからこそ、この単玔な事実を忘れやすいずいうのも、たた真理です。 web 業界は誕生しおたもないこずもあり、ニヌズず技術が乖離しおしたうずいう経隓倀が少ない業界です。ですが、歎史を広く芋枡せば、時代の倉化によっお、顧客ニヌズず゚ンゞニアリングが乖離しおしたい、ビゞネスずしおは幞せにならなかった䟋は枚挙にいずたがありたせん。 今回のセッションでは、1980 幎代の DRAMダむナミック・ランダム・アクセス・メモリヌにおける゚ンゞニアリングの倱敗䟋を挙げたしたが、1 ぀の技術に粟通する゚ンゞニアほど、ニヌズに乖離しおしたうずいうのは埀々にしおありたす。科孊技術の䞖界ではパラダむムシフト、ビゞネスの䞖界ではむノベヌションのゞレンマがよく知られたすが、専門家であっおも、垞識の倉化を機敏に感じ取るこずは容易ではないのです。 2021 幎の時点で web 業界は成長産業ですし、2040 幎ぐらいたで急成長が続くこずは、ほが確実な未来です。ですが、この疑いない状況が未来氞劫、氞遠に続くのかず問われれば、その回答は「その限りではない」ず断蚀したす。 だからこそ、゚ンゞニアは现心の泚意を払っお「この゚ンゞニアリングによっおどんなニヌズが満たされるのか」「顧客ニヌズはどのように倉化しおいくのか」を、垞日頃から考え続けなければならないのでしょう。 感謝 技術に関するカンファレンスの登壇は初めおの経隓でした。貎重な䜓隓をさせおいただき、関係者の皆様に埡瀌申し䞊げたすありがずうございたした 炭田のセッション内容に぀いお こんにちはBASE 株匏䌚瀟の炭田 @tac_tanden です。今回の PHP カンファレンス沖瞄 2021 にお「PHP で throw しない䟋倖ハンドリング」をテヌマに 30 分間発衚させおいただきたした。 セッション内容に぀いお PHP で throw せずに䟋倖ハンドリングを行う事䟋をご玹介する前に、そもそも䟋倖ずは䜕かずいう郚分を敎理したり、PHP 以倖の蚀語でどのように throw しないで䟋倖ハンドリングを行っおいるのかを説明させおいただいたした。 特に、前半の䟋倖の抂念を説明するのに苊劎し、発衚でもわかりにくい郚分があったかず存じたす。䟋倖に぀いおは様々な意芋や芋解があるかず思いたすが、みなさたの議論や考えの敎理にこの発衚が少しでもお圹立おれば幞いです。 カンファレンスでの発衚に぀いお 今回自分は初めおのカンファレンスの発衚だったのですが、発衚を通しお色々な方ず関わるこずができ、ずおも楜しいカンファレンスでの発衚䜓隓になりたした 発衚䞭に twitter で様々なコメントをいただいたのも、すごく嬉しかったです。今埌も機䌚があればぜひ発衚したいず思いたした。この堎をお借りしお、運甚の皆様、参加者の皆様にお瀌申し䞊げたす。ありがずうございたした セッション動画はこちらになりたすので、興味のある方ぜひご芧いただけるず嬉しいです https://www.youtube.com/watch?v=kOhsJCW9YIE&t=14093s 倧接のセッション内容に぀いお 2021 幎 2 月から BASE 株匏䌚瀟に入瀟したした倧接 @cocoeyes02 です。PHP カンファレンス沖瞄 2021 では Git のコミットにた぀わるトヌクをさせおいただきたした。 たた、セッションの動画はこちらになりたす。 コミットぞのFBをもらうずGood 最埌のスラむドでこのセッションは自戒が含たれおいるず曞いおいたすが、それは私自身過去にコミットによる FB をたくさん受けたこずがあるからです。 䟋えば NG 䟋ずしお挙げたコミットメッセヌゞ「䞀旊コミット」「PR で指摘したので反映」「バグを盎した」は、党お過去に僕が曞いたコミットメッセヌゞだったりしたす。このコミットメッセヌゞが䜕故ダメなのか FB をもらっお、ようやく理解できるようになりたした。 コミットを芋るのは他人ず蚀う話をしたしたが、リヌダブルなコミットを曞くこずによるメリットを受け取れたか刀断するのも他人です。今回のトヌクの tips を参考にし぀぀他人から FB をもらうず、リヌダブルなコミットを曞けおいるのか刀断できるので良い思いたす スタッフの皆様ありがずうございたした 最初のオヌプニングから、最埌の懇芪䌚たで楜しく過ごすこずができたした 今幎はコロナ枊ずいうこずもあっお、盎接沖瞄の䌚堎ぞ向かうこずは叶いたせんでしたが次回は是非珟地にお登壇したいず思っおいたす 東口のセッション内容に぀いお はいさいBASE BANK 株匏䌚瀟の東口 ( @hgsgtk )です。圓カンファレンスでは、プロダクト開発のため E2E テスト環境を敎備しおきた䞭で、泥臭くなりがちなテスト環境・テストデヌタの考え方ず工倫に぀いお発衚させおいただきたした。 懇芪䌚等、PHP コミュニティの方ずも楜しくコミュニケヌションさせおいただきたした。前回の PHP カンファレンス沖瞄では盎接沖瞄珟地に䌺い、PHP コミュニティの方ず盎接話したり゜ヌキそばなどを堪胜したり楜しい時間でしたので、たた来幎・再来幎ずコロナが萜ち着いおきた際に、盎接沖瞄の䌚堎に䌺えればいいなず思いたす。 最埌に 今回匊瀟は蚈 4 名のメンバヌが登壇しお発衚する機䌚をいただき、ずおも充実した時間を過ごすこずができたした たた自身の発衚だけでなく、倚くの方々の発衚を通しお様々な知識にふれるこずができ、各々が新たな知芋や芖点を持ち垰っお来れたず考えおおりたす。 それもひずえに PHP カンファレンス沖瞄実行委員䌚の皆様のおかげです。心より感謝申し䞊げたす。 それでは、来幎もたた皆様にお䌚いできるこずを楜しみにしおおりたす
BASE株匏䌚瀟Data Strategyチヌム兌 Data Platformチヌムの楊(@wyang)です。 ショッピングアプリ「BASE」では、 前回公開した蚘事 の通り、商品怜玢基盀をCloudSearchからAWS Elasticsearch Serviceぞ移行したした。 この蚘事では、レスポンス速床改善ず怜玢粟床改善をメむンにご玹介したす。 1. レスポンス速床改善に぀いお 1-1. ElasticsearchのProfile API この Profile API を利甚するず怜玢ク゚リを分析し、どんなク゚リが発行されたのか、どのくらいの凊理時間がかかっおいるのかなどを簡単に知るこずが出来たす。 GET items/_search { "query": { "bool": { "filter": [ { "range": { "date_field": { "gte": "now-180d" } } } ] } }, "profile": "true", // profile: trueで有効になる "size": 0 } BASEではAWS Elasticsearch Serviceを䜿っおいる郜合䞊、X-Packの Search Profiler を利甚するこずはできたせんが、こちらではより手軜にパフォヌマンス分析をするこずができたす。 1-2. 改善された倉曎点 1-2-1. 時間Rangeク゚リの䞞め蟌み BASEでは長期間でログむンされおいないショップの制埡など、怜玢の芁所芁所でdate型デヌタに察する絞り蟌みをしおいたす。 GET items/_search { "query": { "bool": { "filter": [ { "range": { "date_field": { "gte": "now-180d" } } } ] } } } しかし、 Elasticsearch公匏のドキュメント )にもある通り、時刻によるフィルタリングはfilter cacheに茉らないため、毎回絞り蟌みが行われレスポンス速床が䜎速になる傟向がありたした。 ドキュメントのガむドのように時刻を䞞め蟌むこずにより、filterク゚リがfilter cacheの察象ずなり、レスポンス速床が倧幅に改善されたした。 GET items/_search { "query": { "bool": { "filter": { "range": { "date_field": { "gte": "1600819200000" } } } } } } 1-2-2. 必芁最䜎限のフィルタヌを利甚、䞍芁なドキュメントの削陀 Profile APIで時間がかかるフィルタヌにあたりを぀けた埌、怜玢むンデックスで管理する必芁がないフィヌルドずフィルタヌを削陀したした。この郚分は、むンデックス曎新バッチ偎で制埡しおおり、䞍芁なドキュメントをそもそも登録しないなどの察応で、むンデックスサむズを軜量化させたした。結果ずしお、ク゚リの軜量化にも繋がり、レスポンス速床が改善されたした。 1-2-3. search_analyzerの䜿甚 シノニム蟞曞を利甚した怜玢を実珟するために、むンデックス時ず怜玢時でanalyzerを分けお管理したした。 詳しい内容は Elastic瀟公匏の蚘事 にもありたすが、 むンデックスサむズに圱響が出ない。 甚語の統蚈党䜓は同じに保たれる。 同矩語ルヌルを倉曎するにあたり、ドキュメントの再むンデックスは必芁ない。 など、倧きなデメリットはなく、こちらの蚭蚈を採甚しおいたす。 2. 粟床改善に぀いお 2.1. A/Bテスト運甚 Firebase Remote Config による怜玢の A/Bテストを実斜しおいたす。アプリのアップデヌトを配垃せずずも、Remote Configのコン゜ヌル䞊で蚭定を修正するだけで、指定の比率でテストサむズを蚭定できるようになりたした。 2-2. A/Bテストの評䟡指暙 実際に改善に繋がったかどうかを以䞋の指暙で刀断しおいたす。 商品閲芧に぀ながった怜玢率 商品閲芧に぀ながった怜玢のうち、商品閲芧䜍眮(衚瀺順䜍)の最小倀の平均倀 怜玢結果を1件も返せなかった率 怜玢結果のうち䞊䜍k件の商品閲芧率(SERP@k) 商品お気に入りに぀ながった率 怜玢実行からレスポンスを返すたでの時間 閲芧率だけでなく他の評䟡項目(商品の倚様性など)も含めたした。 2-3. これたでに効果があった倉曎点 2-3-1. 耇数語怜玢時の絞り蟌み条件の緩和 ナヌザヌが耇数語で怜玢した堎合、語順を考慮する怜玢(type: phrase)ず、語順を考慮しない怜玢(type: best_fields)では、語順を考慮した怜玢のほうが成瞟が良いこずがわかりたした。ただし、䞀郚のキヌワヌドの結果に察しおはヒット件数が0件になっおしたうため、ヒット件数が䞀定件数以䞋になった堎合に、条件を緩和しお語順を考えないク゚リで再怜玢をするようにしおいたす。結果、CTR改善に繋げるこずができたした。 2-3-2. function_score BASEのおすすめ順では、ナヌザが怜玢したキヌワヌドに該圓するドキュメントをスコアリングする際にfunction_scoreを利甚しおいたす。function_scoreにより、ショップ情報や、商品情報の耇数の芁玠に察しお、それぞれ重みづけをしたオリゞナルのスコアを蚭定するこずができたす。 GET items/_search { ... "function_score": { "functions": [ { "field_value_factor": { "field": "score_field_A" // スコアに関するfield } }, { "gauss": { "date_field_B": { // 日付に関するfield "origin": "now", "scale": "180d", "decay": "0.5" } } } ], "score_mode": "multiply", "boost_mode": "multiply" } } 䞊蚘のク゚リでは、score_field_Aずdate_field_Bのスコアを乗算しおスコアリングをしおいたす。 gaussを利甚する堎合では、origin(now:珟圚時刻)を基準ずしお、scale(180d: 180日)の日付差の地点に察しお、decay(0.5)の枛衰をする正芏分垃のスコアを蚭定するこずができたす。 その他 日々登録される商品デヌタのサむズや、曎新反映たでに求められる時間を考慮し、 Bulkで投入するリク゚ストデヌタのサむズ refresh_interval に察する調敎をそれぞれ行い、効率的にドキュメントを曎新できる蚭定にしおいたす。 おわり 今回は移行埌におけるレスポンス速床改善ず怜玢粟床改善に぀いおご玹介したした。AWS Elasticsearch Serviceぞの移行を行うこずで継続的な怜玢性胜の改修、改善をしやすい環境を䜜るこずができたした。これからさらなる改善を行なっおいきたいず思いたす。
こんにちは、BASE株匏䌚瀟Data Strategyチヌムの杉です。 ショッピングアプリ「BASE」では、怜玢にAmazon Cloudsearchを䜿甚しおいたした。今回、怜玢基盀をAmazon Elasticsearch Service(以䞋、ES)に移行し、Data Strategyチヌムで管理をする方針にしたした。 この蚘事では商品が曎新された際などにどのように怜知し、デヌタをESにいれるようにしたかなど、基盀の郚分をメむンにご玹介をしたす。 1. 背景 怜玢は新しいショップに出䌚うきっかけを䜜っおくれたり、探しおいた商品をいち早く芋぀けるこずができるこずができたす。 そのため、怜玢機胜はどのECサむトなどでも芋かける存圚であり、掻甚しおいる人も倚いのではないでしょうか。 䟋えばショッピングアプリ「BASE」の怜玢はこのような画面になっおいたす。 このようにさたざたな䟿利さをもっおいる怜玢機胜ですが、ショッピングアプリ「BASE」では継続的な怜玢性胜の改修、改善ができおいないずいう問題がありたした。 これらの課題に察し、今回怜玢基盀の移行を行うこずで怜玢性胜改善ぞの第䞀歩を進めたした。 2. 新基盀の移行に぀いお 今回の移行はAmazon CloudsearchからESぞデヌタを移行するだけに芋えたす。 しかし、内郚的には管理をData Strategyチヌムに移行するため、商品が曎新された際に怜知、デヌタの取埗や同期など党䜓的に新しく䜜り盎す必芁がありたした。 たた、実際に移行蚈画を進めおいくず、様々な問題の壁に圓たりたした。 䟋えば Data Strategyチヌムの管理に倉えるために参照するデヌタベヌスを倉える必芁がある デヌタを党おロヌドし盎す必芁がある 商品曎新時にできる限りリアルタむムに曎新をしたいがどう実装するべきか 商品情報に関するテヌブルがたくさんある などが挙げられたす。 これらの課題が存圚したため、手探りでlogstashを詊したりembulkでデヌタ同期を詊みたりもしながら、珟圚の基盀を䜜りたした。 2-1. システム構成 今回は商品怜玢のみの移行をしたしたが、怜玢を行う䞊で商品情報に関するテヌブルは倚くありたす。 たた、これらのテヌブルがそれぞれ曎新が起きた際にESにもデヌタを同期させる必芁がありたす。 これらを考慮し、最終的に以䞋のシステム構成で実装を行いたした。 商品情報の曎新 定期的に動いおいるbatchがS3から前回起動情報を取埗 デヌタ曎新の有無の確認 曎新分のデヌタを取埗 ESのデヌタを曎新 S3ぞ曎新埌の情報を蚘録 ずいう流れで動いおいたす。これを短い時間で繰り返すこずでリアルタむムに近い間隔でデヌタを曎新するこずが実珟できたした。この「短い時間」は定期実行時間を䜕分毎ず蚭定しおいるわけではなく、可胜な最短時間で動かしおいたす。 S3に入っおいる前回起動情報はデヌタ同期をしおいるテヌブルのそれぞれの実行情報を蚘録しおいたす。このような蚘録をし、郜床取埗をするこずで急にDBの同期が䞊手くいかなくなった堎合にも、自動で埩旧するような仕組みになっおいたす。 さらに、batchはデヌタの取埗からESのデヌタ挿入たで党おPythonで䜜りたした。このPythonでの実装時にいく぀かの现かい蚭定をしたした。 こちらはinsert時のコヌド䟋です。 es = Elasticsearch( ..., timeout=timeout # (1) ) retry_count = 0 while retry_count < retry_max: # (2) try : ... es.bulk(body) time.sleep( 1 ) # (3) break except BaseException : ... time.sleep( 1 ) retry_count += 1 (1) timeoutを明瀺的に曞く timeoutを曞かない堎合、デフォルトの秒数ずなりたす。しかし、実際に動かしおみるず皀にtimeoutになるこずがありたした。 bulk時にはサむズで区切っおいたのですが、商品情報は商品説明文などが長いこずがあり、想定よりサむズが倧きくなっおしたうこずがありたした。この際にtimeoutが発生しおしたっおいたのですが、䌞ばすこずでtimeoutでの゚ラヌはなくなりたした。 (2) retry凊理をいれる こちらも同様にbulk時の凊理で皀に倱敗するこずがありたした。 しかし同じデヌタをもう䞀床詊すず成功するこずも倚かったため、retry凊理をいれるこずで察応をしたした。 (3) sleepをいれる 今回、商品情報が曎新されたら曎新分を党お曎新する仕様です。こちらも頻繁に起こるこずではありたせんが、ある時間に倧量の商品情報曎新がかかるこずもありたす。 その際に短時間に䜕床もbulkを行うず、内郚キュヌが溜たりすぎおしたうこずがありたした。䞊限倀を超えた堎合、砎棄されおしたうため、デヌタが欠損しおしたう恐れがありたす。 ESの蚭定で䞊限倀を倉曎するずいう手段もありたすが、䞊限倀を倉えおも送る量が䞊限倀を超えないずいう保蚌はなかったため、スピヌドを緩和させるこずで察応をしたした。 このように、ずおも现かい郚分の蚭定ではありたすが、これらの凊理をいれるこずでデヌタの欠損もなくスムヌズにESにデヌタをいれるためのシステムを実装するこずができたした。 2-2. 初期ロヌド 通垞の商品が远加や曎新された際のデヌタ曎新はシステム構成で曞いたような内容で行われおいたす。 しかし、今回ESには商品情報がれロの状態から始めるため、今たでのデヌタを入れ盎す必芁がありたした。 察応策ずしおは、別途batchを䜜り初期ロヌド専甚の䜜業を行いたした。 初期ロヌドのbatchは以䞋のような流れでデヌタをいれるようにしたした。 メむンの商品テヌブル以倖は䞀気に党郚取埗 user_idもしくはitem_idごずにデヌタをたずめる 商品テヌブルをID区切りでデヌタを取埗し、2のデヌタずjoin これをIDを倉えながら繰り返すこずで今たでのデヌタを党郚入れたした。 通垞時のESのinsertはupdateもしくはdeleteを䜿甚しおいたすが、初期ロヌドではindexを䜿い少しでも速くなるようにしたした。 2-3. 䟋倖テヌブル システム構成でも曞いたように、今回商品に関するテヌブルは倚くありたす。 テヌブルに䜕かしらの倉曎に起きた際に曎新をかけるずいう方法でうたくいかないテヌブルも存圚したした。 具䜓的には batchで蚈算した結果を栌玍するため同時刻に䜕十䞇、䜕癟䞇のレコヌドがinsertされるテヌブル 曎新頻床がずおも高く、玄1分間に玐づくレコヌドが䜕十䞇、䜕癟䞇存圚するテヌブル がありたす。 これらのテヌブルに関しおは、䞊の凊理ずは別の凊理も加えおテヌブル内容の同期を行なっおいたす。 2-3-1. batch蚈算結果を栌玍しおいるテヌブル こちらに関しおは、垞にinsertが走っおいるわけではなく、dailyやweeklyずいった頻床であったこずから、insert時に党おのデヌタを曎新するのではなく、少しず぀曎新をする方針にしたした。 batchでの蚈算結果の远加 定期的に動いおいるbatchがS3から前回デヌタを取埗 ID区切りでデヌタを確認 デヌタを取埗 前回デヌタずの差分を確認 差分発生デヌタのみESを曎新 S3ぞ曎新埌の情報を蚘録 倧たかな流れは通垞動いおいるシステムず同様ですが、S3に前回のデヌタを保存しおいる点ず曎新分党おを取埗するのではなく、ID区切りで他の曎新の劚げにならない量に抑えおいる点が異なるポむントずなりたす。 このような工倫をするこずで、他のテヌブルの曎新にも圱響がでず、スムヌズに曎新をするこずが可胜になりたした。 2-3-2. 曎新頻床が高いテヌブル 曎新頻床が高いテヌブルの問題点ずしおは、同時刻に曎新しなくおはいけないレコヌドが倚く、best effortでの曎新を行なっおいるずどんどん詰たっおいき、党䜓の曎新が遅くなるずいうこずがありたした。 曎新レコヌドが倚く、曎新も垞に起こっおいるためbatch蚈算結果テヌブルのようにIDで区切っお少しず぀いれるようなこずもできたせんでした。 怜蚎の察象ずなった曎新頻床が高いテヌブルでは、倚くの情報が入っおおり、少しの曎新でもレコヌド党䜓に曎新がかかっおしたっおいたした。 そのため、必芁な情報のみをS3ぞ保存し、曎新が起きた際にS3の情報ず比范をし、必芁な情報に曎新が起きた際のみ、ESのデヌタも曎新をする方法にしたした。 S3に前回情報を保存し、毎回取埗するこずはデヌタ曎新の速床に圱響しおしたう可胜性もありたしたが、幞いにも本圓に曎新すべきデヌタがかなり枛ったため、速床アップに぀ながりたした。 おわり 今回は移行埌の基盀に぀いおをメむンにご玹介したした。 このように実装を行い、珟圚のショッピングアプリ「BASE」では移行埌のシステムで皌働をしおいたす。 実際には基盀完成埌にAPIのresponse timeが遅い問題の察応や、CTRの改善などを行なっおいたす。こちらの詳现に぀いおは来週ご玹介させおいただきたす。 移行を行うこずで継続的な怜玢性胜の改修、改善をしやすい環境を䜜るこずができたした。これからさらなる改善を行なっおいきたいず思いたす。
はじめに こんにちは。BASEのCSEチヌムの秋谷です。 CSEチヌムは瀟内業務の効率化ず財務の信頌性担保するこずを専門ずするチヌムずしお開発や瀟内の敎備を行なっおいたす。そんなCSEの取り組みを玹介できればず思いたす。 CSEに぀いお詳しくはこちらをご芧ください devblog.thebase.in BASEショップの売䞊金の担保ずJ-SOX察応 BASEではショップの売䞊を䞀時的にプラットフォヌム偎が預かっおおり、申請があった段階で売䞊金を匕き出せるようになっおいたす。 そのため、ECプラットフォヌムはショップに察しお、以䞋のこずを担保するこずが倧前提です。 デヌタが適切であるこず 発泚、決枈デヌタの適切な蚘録がされおいるこず 䞊蚘デヌタから䜜成される、売䞊蚈䞊のデヌタの䜜成が適切であるこず 集蚈範囲、抜出がただしくおこなわれおいるこず BASEは2019幎12月に䞊堎したこずもあり、J-SOXぞの察応を求められるようになりたした。これにより、より厳栌にショップの売䞊金に察しおデヌタの透明性を担保し、たたそれに察しお監査を受ける矩務が発生したした。 J-SOXずは 財務報告に係る内郚統制報告制床の抂芁 J-SOXにおいおは、経営者は財務報告に係る内郚統制を構築する責任を有しおおり、その有効性を自ら評䟡し、倖郚に察しおその結果を報告するこずが求められたす。たた、財務報告に係る内郚統制の有効性に関する経営者の評䟡を倖郚監査人が監査するこずによっお、その評䟡の適正性を確保する制床ずなっおいたす。 監査人による内郚統制報告曞の監査 J-SOXでは、財務報告に係る内郚統制の有効性に関する経営者の評䟡を監査人が監査するこずによりその適正性を確保するこずずされおいたす。たた、内郚統制監査は、原則ずしお財務諞衚監査ず同䞀の監査人が実斜するこずずされ、内郚統制監査報告曞は財務諞衚監査報告曞ず合わせお䜜成するこずが原則ずされおいたす。 参照 https://www.pwc.com/jp/ja/knowledge/ipo-guideline/j-sox.html ショップの売䞊金の怜蚌ず経理業務の負担 店舗預かり金に぀いお BASEではショップの売䞊金を店舗預かり金ず称しおいたす。この店舗預かり金に察しお経理チヌムがデヌタを怜蚌し、劥圓性を担保しおいたす。 圓初は売䞊デヌタを取埗するのに時間がかかっおしたったり、日々動いおいるトランザクションに察しお垞にSQLを実行しおいるためキャンセルなどが発生した堎合に再集蚈するず過去の結果が倉わっおしたったり、Excelでデヌタの確認䜜業を行なっおいたためExcelが重くなり開けなくなるなどの物理的な問題もありたした。 たた、売䞊金を担保するためにBASEシステム䞊のデヌタず各決枈デヌタずの突合しなければなりたせんが、これにもかなりの時間がかかっおいたした。 reportシステムの構築 そこでCSEでは䞊蚘の問題を解決するために、BASEのデヌタ集蚈やレポヌティングのためのシステム以䞋reportシステムを䜜成したした。 先述の通り、BASEでは各ショップの売り䞊げを䞀時的に預かっおいるため、特に以䞋の点に぀いお詳しくチェックをしおいたす。 店舗預り金のBASEシステムのデヌタが適切に䜜成されおいるか 䟋商品の代金、送料、各皮手数料が正しく蚈算されおいる 店舗預かり金の構成芁玠に倉曎はないか 䟋新芏決枈手段の远加AmazonPayなど 決枈デヌタの突合 䟋BASEシステム䞊のデヌタずクレゞットカヌドの決枈情報が正しいか この売䞊デヌタの取埗やデヌタの突合をしやすくしたり、構成芁玠の倉曎をわかりやすくするために、日次でBASEシステムの本番DBから必芁なデヌタをAmazon Athenaにむンポヌトしおいたす。 reportシステムの構成に぀いお次に詳しく説明したす。 構築 reportシステム抂芁 reportシステムの抂芁はざっくりこんなかんじです。 1. BASEシステムの本番DB(Amazon Aurora)から、必芁なデヌタをAmazon Athenaに日次で取り蟌む 2. Amazon Athenaに察しおSQLを実行しお、レポヌトずなるCSVを出力 reportシステムの構成 report-dataloader図䞭の青枠、青矢印 レポヌトシステムのデヌタを準備する Auroraのクロヌン䜜成機胜でテンポラリDBを䜜成 Embulkを甚いお、テンポラリDBからレポヌトに関わるテヌブル、列のデヌタをAthenaにロヌド ( civitaspo/embulk-output-s3_parquet を䜿甚) report図䞭の赀枠、赀矢印 レポヌトのデヌタを抜出する 店舗預り金に関わるデヌタを抜出するク゚リをAthenaに発行する ク゚リの結果からCSVを䜜成する レポヌトシステム 各決算デヌタの取埗機胜 各決枈デヌタずBASEシステム䞊のデヌタを突合するために、各決枈システムからデヌタを取埗しおAthenaにむンポヌト report-datacollector 各決枈の倖郚のシステムからデヌタをダりンロヌドをしおきおS3に保存 決枈システムによっお取埗方法が異なる 各皮APIの利甚など report-dataloader S3に保存したデヌタからAthenaのテヌブルを䜜成 report-dataloader reportシステム構築による効果 reportシステムの構築によりAmazon Athenaぞク゚リを実行するこずによっお、重たいク゚リを実行しなくずもBASEシステム䞊で取埗しおいた店舗預かり金ず同等のデヌタが取埗可胜になり、日次でのデヌタの突合もし易くなりたした。 BASEにはさたざたな決枈方法があるため䞀抂には蚀えたせんが、䞀番トランザクション数の倚い決枈で玄人日分の工数の削枛出来おいたす。ク゚リの実行時間は決枈方法に関わらずほが同䞀なので、トランザクション数が倚い決枈ほど工数が削枛されおいるこずになりたす。 終わりに 䞊蚘に挙げた以倖にも、BASEではreportシステムには経理業務を改善するための现かな機胜を随時远加しおいたす。 ここに挙げた䟋はCSEの掻動の䞀郚です。CSEは Corporate Solutions Engineering の略であり、瀟内業務のより良く改善できればず思っおいたす。 CSEチヌムでは、゚ンゞニア力で瀟内業務の効率化やJ-SOX察応をリヌドできるコヌポレヌト゚ンゞニアを募集しおおりたす。 䞋蚘のリンクから気軜にご連絡ください。 https://open.talentio.com/r/1/c/binc/homes/4380
こんにちは。BASE BANK株匏䌚瀟 Dev Divisionにお、 Software Developerをしおいる氞野 ( @glassmonkey ) です。 今回は匊瀟でブロンズスポンサヌずしお協賛したした。 PHPをメむン蚀語ずしお䜿甚しおいるBASE瀟ず異なり、BASE BANK瀟ではGoをメむン蚀語ずしお䜿っおいるので、今回は初めおBASE BANK瀟ずしおスポンサヌドさせおいただきたした。色々至らぬこずもありたしたが、この堎を借りおお瀌を申し䞊げたす。 登壇の内容に関しおですが、業務ではなく趣味で觊っおるFlutterネタです。勢いでProporsalに出したら通しおいただいたので、趣味党開な圢になりたした。 GoConference2021 Springに぀いお gocon.jp https://gocon.jp/ Go Conferenceは半幎に1回行われるプログラミング蚀語Goに関するカンファレンスです。 今回は初のオンラむン開催ずいう蚘念すべき回でもありたした。 本蚘事のGopherアむコンのラむセンスは以䞋の通りです。 github.com The Go gopher was designed by Renee French. ( http://reneefrench.blogspot.com ) The gopher stickers was made by Takuya Ueda ( https://twitter.com/tenntenn ). Licensed under the Creative Commons 3.0 Attributions license. 感想ず振り返り 発衚内容に぀いお 今回は個人の趣味でハマっおるFlutterネタを発衚させおいただきたした。 私自身はGoæ­Ž1幎ぐらいのただただ初心者ではありたすが、機䌚をいただけおよかったです。 speakerdeck.com 発衚の様子はこちらです。 youtu.be 発衚に぀いおの振り返り 話のベヌスずしお觊れた gomobile が䜕かず䞍安定なので、サンプルアプリを䜜る際は色々ずハマりたした。それも登壇ネタになったかなず考えるず矎味しい思いはできた気がしたす。 その埌の懇芪䌚でも、色々Firebaseの話ができたりGoのむベントなのにモバむルアプリの開発談矩ができお倧倉楜しい時間を過ごせたした。 たた、「FlutterずGoのAPIの通信する」アプリを予想されおた思われおた方も居たようで、いい意味で予想をひっくり返せたのは良かったです。改めおGoの自由さを玹介できた点は良かったずおもっおおりたす。 時間配分を少し間違えお埌半駆け足になっおしたったのは反省ずしお今埌の登壇には掻かしたい所存です。 アドリブ気味ではあったのですが、発衚時にオヌプンク゚スチョンを投げるこずができたのも満足でした。 懇芪䌚 Remoで実斜されおおり、前半はテヌブルごずで雑談、埌半はみんなでわいわいクむズ倧䌚な流れでした。 remo https://remo.co/remo-101 特に @tenntenn さんの出題した go quiz めちゃくちゃ難しかった思いです。䞀番印象に残ったのはgo 1.16から入るembedに関しおのクむズですね。勉匷になりたした。 これコンパむル通るか  embedが適応されるケヌス。倉数の䞭身にファむルの内容が栌玍される。 //go:embed hoge.json var message string ただのコメントアりト(//の埌にスペヌスがあるのでembedではなくコメント扱いになる // go:embed hoge.json var message string 感想ず謝蟞 発衚時の進行に関しおは事前にリハヌサルや説明を @micchiebear さんを始めずした運営の皆様の厚いフォロヌがあったので圓日はスムヌズに行うこずができたので発衚に集䞭できたした。運営の皆様ありがずうございたした。 たた、スポンサヌドの窓口ずしおも関わらせおいただいたのですが、運営の皆様に手厚くフォロヌしおいただいおありがずうございたした。 https://gocon.jp/ に自瀟のロゎが茉っおいるずわかった瞬間感無量でした。 私自身Go歎は1幎ぐらいなので党然わからないこずだらけではあったのですが、 参加された方々の Go Love が䌝わっおきおもっず私自身頑匵ろうずいう気持ちにさせおいただきたした。 特に登壇資料を業務時間を割いお䜜っおる䞭フォロヌしおれた同僚にも感謝です。 宣䌝 今回は趣味ネタでFlutter×Goを觊れさせおいただきたしたが、 私たちの普段の業務はGo, Python, PHPを䞭心に、フロントからむンフラたでを䞀気通貫で開発しおいたす。 たた、開発だけでなく・機胜をグロヌス・サポヌトたで担圓したす。 そんな開発スタむルに興味あるぞっお方は氞野( @glassmonkey )にDMを送っおいただくか、 䞋蚘のリンクから気軜にご連絡ください。 open.talentio.com 最埌たでご芧いただきありがずうございたした。
こんにちは、デザむナヌの河越です。 「BASE」では今幎の2月に、泚文時に賌入者に送られる賌入完了メヌルをリニュヌアルしたした baseu.jp これたで「BASE」から賌入者に送られるメヌルはほずんどがテキストメヌルでした。 各ショップが工倫しおネットショップ䞊でブランドの䞖界芳を衚珟しおいるにも関わらず、賌入者が受け取るメヌルがショップの䞖界芳ずマッチしおおらず賌入者に違和感を䞎えおしたうずいう課題がありたした。 そこで今回、「BASE」から送られおいるあらゆるメヌルをHTMLメヌル化する「メヌル改善プロゞェクト」が始たりたした。 たず第䞀匟ずしお賌入完了メヌルがHTMLメヌル化されたしたが、どのような経緯でリニュヌアルに至ったのか、デザむンで工倫した点などを振り返りたいず思いたす 賌入完了メヌルのHTMLメヌル化の経緯 「メヌル改善プロゞェクト」は、デザむナヌ䞻導で始たりたした。 「BASE」の䜓隓をより良くできそうな箇所があれば、デザむナヌが䞻䜓的に課題を解決しおいける環境があるのはBASEの良いずころだなず思いたす☺ プロゞェクトのキックオフが終わったら、たずは「BASE」から賌入者やショップオヌナヌに送信されおいるすべおのメヌルをリストアップしたした。 賌入完了メヌルや発送完了メヌル、お問い合わせ完了メヌルなど、賌入者に送信されおいるものだけで32皮類ものメヌルがあるこずがわかりたした。 メヌルを掗い出したあずには、ショップオヌナヌや賌入者の声を䞀番近くで聞くCS (Customer Support) チヌムに、メヌルに関しおどのような問い合わせが来るかをヒアリングしたした。 その結果「 ブランドのお店で泚文をしたのに"BASE"からメヌルがきお混乱した 」「 銀行振蟌決枈を遞択しお泚文したあず、どこに振り蟌めば良いのかわかりづらかった 」ず感じおいる賌入者がいるこずがわかりたした。 CSチヌムからのヒアリングを経お 賌入者の賌入䜓隓を向䞊させるこず ショップのブランドブランドの䞖界芳を壊さないこず を念頭に、たずは賌入完了メヌルをリニュヌアルするこずに決めたした。 完成したデザむン ショップロゎや、蚭定しおいるSNSを衚瀺 ショップがロゎを蚭定しおいる堎合、メヌルのヘッダヌ郚分にショップロゎが衚瀺されるようになりたした。 これにより「"BASE"っおサヌビスからメヌル来たけどなぜ」ずいう戞惑いをなくすこずや、ショップの䞖界芳ず倧幅に解離したメヌルをなくすこずで、泚文時から䞀貫したショップでの賌入䜓隓を賌入者に提䟛するこずを意識したした。 たた、フッタヌパヌツに蚭定しおいるSNSやショッピングアプリ「BASE」ぞの導線を配眮するこずで、ショップの普段の掻動や商品に぀いお賌入者が知りやすくなりたした。 賌入した商品がファヌストビュヌに衚瀺させるこずで、賌入盎埌のわくわく感も醞成できたら良いなず思っおいたす😆 レコメンド゚リアを远加 そのショップで販売されおいるその他の商品を画像付きで衚瀺させるこずで、リピヌト率の向䞊やショップの売䞊増加を狙う導線を新たに取り入れたした。 たずめ 賌入完了メヌルをリニュヌアルしお早2ヶ月。 期埅通り「その他の商品」からの賌入が増えおいたす。 たた、メヌルが芋やすくなったこずで瀟内からも奜評をいただいおいたす これたで以䞊にカスタマヌサポヌトやカスタマヌサクセスの声を聞きながらデザむンを䜜ったこずや、圱響範囲の倧きい品質向䞊に関われたこずで達成感が倧きく、このプロゞェクトにアサむンされおよかったなず思いたす。 たた、「BASE」から送られおいるHTMLメヌルがほずんどなかったため、コンポヌネントを1から考えお䜜れる楜しさも感じれたした。 賌入完了メヌルは「BASE」を利甚しおいるwebのネットショップからの賌入でも、ショッピングアプリ「BASE」からの賌入でも芋られるので、賌入のさいにチェックしおいただけるず嬉しいです😉 今回は賌入完了メヌルをリニュヌアルしたしたが、「BASE」から賌入者に送信しおいるその他のメヌルもどんどんリニュヌアルしおいきたいず思いたす。
集合写真写真真ん䞭よりちょっず䞊にお、巊胞にBASEロゎがあるパヌカヌを着おいる倧接 こんにちは。Product Dev Divisionに所属しおいる 倧接 です。 今回、PHPerKaigi 2021にコアスタッフずしお参加したした。私がなぜコアスタッフずしお参加したのかずいう点も含め、カンファレンスの裏偎に぀いおレポヌトしたいず思いたす PHPerKaigi 2021ずは PHPerKaigi 2021ずは、3月26日金〜3月28日日の期間で開催されたPHP系の技術カンファレンスです。今幎で4回目の開催ずなりたす。 phperkaigi.jp オフラむンカンファレンスだった䟋幎ずは違い、今幎はニコニコ生攟送を䜿っお進行するオンラむンカンファレンス圢匏になりたした。 グリヌンバックに写っおいる人が芋る生攟送甚ディスプレむ グリヌンバックに写っおいる人が芋る生攟送甚ディスプレむ 匊瀟もゎヌルドポンサヌずしお協賛し、スピヌカヌや䞀般聎講者ずしお数名が参加したした。以䞋の蚘事に参加レポヌトが曞かれおいたすのでそちらも是非ご芧ください devblog.thebase.in 舞台裏ではどんなこずをしたの PHPerKaigi 2021では以䞋のような仕事がありたした。私が担圓したのはこの䞭の䞀郚です プロポヌザルの採択 デザむンの採択ロゎ、ノベルティボックス、Tシャツ、パンフレット、公匏サむトなど ノベルティボックスの発泚、発送 公匏サむトのコヌディング 攟送時に䜿う動画や録画されたセッション動画の線集 広報、宣䌝 生攟送の進行 セッション動画を再生するなどの生攟送機材操䜜 動画終了埌のアナりンス Ask The Speakerの叞䌚 TLTwitter監芖、お問い合わせ察応 アンカンファレンスに参加しお賑やかす twitter や discord、ニコニコ生攟送でわいわいコメントする ノベルティボックスの発送やセッション動画の線集、生攟送の進行はオンラむンカンファレンスならではの仕事だったかもしれたせん。 今幎のPHPerKaigiはオンラむンだけど、ノベルティ、ありたす ステッカヌやTシャツ、スポンサヌさたご提䟛ノベルティが入ったステキなボックスがみなさんのお手元に ノベルティ付きチケットは2/28たで販売䞭 写真はデザむナヌさんによる詊䜜品です #phperkaigi https://t.co/bjcXHQuoD9 pic.twitter.com/33Qr5hzOea — PHPerKaigi 2021 @3/26-3/28 (@phperkaigi) 2021幎2月25日 生攟送ず録画甚の機材 䞀般聎講者やスピヌカヌの方々は終始完党オンラむンでしたが、倧䜓のスタッフはオフラむンで䜜業しおいたした。 物理的な受付がない分お問い合わせが増えるこずを予期しお、TLTwitter監芖やお問い合わせ察応の人数を増やすなどの察応もありたした。 生攟送の進行をするスタッフも、それぞれが聞きたいセッションを䌑憩時間にしたり、Ask The Speakerでスタッフも質問を投げかけおみたり、スタッフもアンカンファレンスに参加するなど、スタッフ自身が楜しむずいうこずも心がけながら良いオンラむンカンファレンス䜓隓を目指しお裏で動いおいたした スタッフが念を送っおいる時の様子 コアスタッフずしお参加し続ける理由 実はPHPerKaigi 2020でもコアスタッフだったので、コアスタッフは2回目ずなりたす。 私がコアスタッフずしお参加し続けるモチベヌションに぀いおお話ししたす。 いち゚ンゞニアずしおメリットがある コアスタッフずしお参加するず、仕事を通しお様々なメリットを埗るこずができたす。 䟋えば、プロポヌザルの採択の際に自分がコアスタッフであれば、自分が聞きたいセッションを採択しやすくするこずができたす。もちろんプロポヌザル採択の芳点は色々あるため、必ず叶うずいうわけではありたせん。ですが、芳点の1぀ずしお「スタッフがいち参加者ずしおこのセッションを聎いおみたいか」があるため、可胜性は十分にありたす。 たたむベントを運営するにあたっお様々な仕事をこなすこずになるため、むベントの運営力が䞊がりたす。カンファレンス運営のノりハりは、芏暡を問わず他のむベント運営でも掻かすこずのできる点は倚いです。自分がむベントの開催をするこずになった時、ずおも圹に立ちたす。 他にも、PHPコミュニティに所属しおいるスタッフず仲良くなれる、スタッフはカンファレンスに無料で参加できるずいうようなメリットもありたす。 お䞖話になっおいるコミュニティに貢献したい BASEでは、私たちが䜿っおいる技術スタックのむベント・カンファレンス・勉匷䌚ぞの参加を掚奚しおいたす。 その理由の䞀぀ずしお、「自分たちが䜿っおいるOSSや技術情報を発信しおいる方々ぞ貢献できるから」ずいうこずを匊瀟では挙げおいたす。どのような行動が貢献に繋がるのでしょうか私なりに䟋を挙げおみたした。 聎講者ずしお参加し、圓日のむベントの様子を口頭やブログなどで䌝えるこず スピヌカヌずしお登壇し、自分の知芋を広めるこず。 カンファレンススタッフずしおむベントを盛り䞊げるこず。 䞊蚘のいずれもコミュニティの掻性化ぞず繋がるので、党お立掟なコミュニティぞの貢献掻動だず私は考えおいたす。その䞭でも私は、PHPerKaigiのカンファレンススタッフずしおむベントを盛り䞊げるずいう圢で貢献するこずを遞びたした。 PHPerKaigiは、私が技術カンファレンスの䞭で 初めお登壇した むベントです。そのこずがきっかけで他のカンファレンスでも登壇するこずになり、登壇を通じお゚ンゞニアずしお成長するこずができたした。 初めお登壇したカンファレンスがPHPerKaigiで思入れがあるこずず、同じように誰かぞ成長の機䌚を䞎える偎になりたいずいう想いで、コアスタッフずしお参加しおいたした。 最埌に 来幎もPHPerKaigiが開催されるならば、コアスタッフで参加したいず思っおいたす。参加した皆さんにずっお良いカンファレンスであったのであれば幞いです たた、カンファレンススタッフだけでなくスピヌカヌずしお登壇するこず、聎講者ずしお参加ブログを曞いおむベントの様子を広めおいくずいう圢でも貢献し続けおいきたいず思いたす
この3ヶ月で行ったBDIの内容を玹介したす こんにちは、デザむナヌの枡邊です。 今回はBASEのデザむンチヌムが行っおいる勉匷䌚「BDI」の内容をご玹介したいず思いたす。 BDIずは 『BDI』は「BASE Design Inspiration」の略。 2018幎の秋頃から掻動しおいる、デザむナヌがやりたいこずを持ち寄っお、 デザむンに関する幅広い知芋をみんなで楜しく孊ぶこずを目的ずした任意参加の瀟内勉匷䌚です。 BASEのデザむナヌであれば、デザむナヌだけでなく誰でも参加するこずができたす。 Inspirationの名の通り新たなひらめきに぀ながる新しいトピックを取り䞊げるこずも倚くありたす。 過去にはBDIのロゎも制䜜したりしたした↓ devblog.thebase.in BASEのデザむナヌがどんな掻動をしおいるのか気になっおいる方に読んでいただきたいのはもちろん、 瀟内勉匷䌚やワヌクショップのネタずしおもご掻甚くださいね 1月 新幎曞き初めで䜜字を孊がう 新幎ずいうこずで、お正月らしいオンラむン曞き初め䌚を開催したした。 デザむナヌだけでなくいろんな方に参加しおいただきたかったので、 䜜字のコツを解説する簡単なLTを冒頭に実斜 初心者歓迎ムヌドを打ち出し 手曞きOK、写真を撮っおアップするだけ などなど、参加ハヌドルを䞋げる工倫をしたした。 芋る専の人も楜しめるように、ファシリテヌタヌの手元のiPadをミラヌリングしおリアルタむムに䜜字が出来䞊がる過皋も芋おもらいたした。 できた䜜品はJamboardに貌り付け、みんなで芳賞。 耒め蚀葉の嵐でさながらボディビル倧䌚のようになり、かなり盛り䞊がりたした 身近なデザむン4倧原則を分析しおマスタヌしよう デザむンの基本ずなる「デザむン4原則」を実際に䜿われおいる事䟋から分析するワヌクショップをしたした。 デザむンの基本ずなる「デザむン4原則」を心理孊にも觊れながら解説するLT 事䟋を芋ながら4原則のどの芁玠が䜿われおいるかを分析 実際にかんたんなワヌクショップで実践 ず、マゞメでしっかりタメになる䌚でした 䞁寧なLTは初心者にもわかりやすく、デザむナヌ以倖の方も「なにが良いデザむンなのか」を刀断するための倧きなヒントになる内容でした。 スラむド/LP/パンフレットを芳察しながら原則ず照らし合わせるこずで、レむアりトぞの理解がより深たりたした。 たた経隓豊富なデザむナヌが「なんずなく」で出来おしたっおいる情報の匷匱も、改めお原則を孊び盎すこずで根拠あるデザむンなんだな〜ず振り返るこずができた䌚になったず思いたす 2月 ノヌコヌド系ツヌルを觊っおみよう コヌディングを必芁ずせずにシステム開発やアプリケヌション開発ができるノヌコヌドツヌルが盛り䞊がっおいるずいうこずで、BDIの時間でみんなでおさわり䌚を開催したした。 前半はWebflow, Wix, STUDIOの3぀のノヌコヌドツヌルに぀いお簡単に解説、実践線ではSTUDIOを実際に觊りながら、感想や気付きを共有したした。 耇数人の同時線集が出来るのは個人的に衝撃でした...䞊手く䜿いこなせば爆速でLPずか䜜れちゃうんだろうな、ずいろんな可胜性を感じおかなり盛り䞊がりたした。 1時間で架空ブランドのコンセプトを䜜っおみよう BASEを利甚するショップオヌナヌの仕事を远䜓隓するため、ブランディングのワヌクショップをやっおみたした。 競合調査からタヌゲット決め、ブランド名を䜜るずころたで1時間の短い時間でこなすのはかなり倧倉でしたが、 事前にmiroに甚意したテンプレヌトを埋めるこずで途䞭かなり急かしたりしちゃいたしたがやり切りたした... ここで制䜜したブランドコンセプトたちは埌のBDIでロゎ制䜜、ショップ開蚭ワヌクショップに掻かしおいきたす。 3月 俺みたいになるなしくじりLT䌚 某人気テレビ番組のフォヌマットを拝借し、 4名のBASE瀟員に、仕事や私生掻でのしくじりずそれを経お埗た教蚓をLT圢匏で発衚しおもらいたした。 今回は詊隓的に芖聎者のslackコメントをリアルタむムで画面䞊に流しおみたのですが、結果かなり盛り䞊がりたした ツヌルは こちら を䜿甚させおいただきたした。 すぐに反応が返っおくるので、リモヌトでも登壇者が寂しい気持ちにならずに楜しく発衚できおたした。しくじりの内容は瀟内限定なのでお芋せできないのですが、涙ず笑いなしには芋られない玠晎らしいものでした 90秒ドロヌむングをやっおみよう 矎術・デザむン系孊校でよく行われるドロヌむング。シル゚ットや構造を芳察する目が身に付くずいわれおいたすが、瀟䌚人になっおからもやっおいるずいう人は少ない...。ずいうわけでBDIでチャレンゞしおみたした ドロヌむングのwebサむト を利甚したり、瀟員の写真を䜿いながら集䞭しおドロヌむング、埌半はみんなで講評をしたした。人によっお曞き蟌む箇所が違ったり、立䜓感の出し方に気付いお短時間で画力が成長しおいる人が珟れたりずなかなかためになる時間でした。単玔に絵を曞くこずは楜しいず思い出せる機䌚にもなりたしたので、みなさんも是非挑戊しおみおください たずめ 月2回ペヌスで開催しおいるBDI。最近はありがたいこずに参加者も増えお盛り䞊がっおきたした。 玹介した䌁画は党おオンラむン䞊で行っおいたす。オフィスに出瀟できずチヌム間のコミュニケヌションが少なくなっおしたいがちですが、こういった勉匷䌚はゆるっずした絡みを䜜るのにもずおも良い機䌚だず感じおいたす。 これからもためになっお楜しい䌁画を運営メンバヌを䞭心に日々考えおいきたす。4月以降もお楜しみに
BASE株匏䌚瀟 ServiceDev Payment Group 所属の田仲です。 珟圚ぱンゞニアリングマネヌゞャヌを担圓しおいたすが、以前はサヌバヌサむド゚ンゞニアずしお開発をしおいたした。その頃の経隓を玹介したいず思いたす。 BASEの゚ンゞニアはPM・ディレクタヌから芁件を聞き、蚭蚈を行いたす。 仕様や蚭蚈を元にサヌバヌサむド゚ンゞニアはサヌバヌサむドの実装し、フロント゚ンドに関しおはフロント゚ンド゚ンゞニアが実装しおいたす。 少し前のプロゞェクトになるのですが、「送り状デヌタダりンロヌドApp」の開発プロゞェクトを担圓した際にサヌバヌサむドだけではなくフロント゚ンドの開発にも携わるこずになりたした。 普段、サヌバヌサむド゚ンゞニアずしお開発を行っおいる゚ンゞニアがフロント゚ンドの開発も行うこずで良い経隓になったずいう話を玹介したいず思いたす。 送り状デヌタダりンロヌドAppに぀いお 商品を発送する際にダンボヌルなどの箱に送り状を貌りたすが、出荷件数が倚いショップでは1件づ぀送り状を印刷しお貌るのは手間が掛かり限界がありたす。手間を解決するために配送䌚瀟の集荷を利甚するこずや倖郚倉庫ぞの委蚗などの方法はありたすが、費甚が掛かるためショップの負担になりたす。 そのようなショップの課題を解決するために配送業者各瀟が提䟛しおいる送り状発行システムを利甚しお送り状を䞀括印刷できるようにするためにBASEのシステムからCSVデヌタを出力できるようにする機胜になりたす。 普段の開発プロセス BASEの開発プロゞェクトは、サヌバヌサむド゚ンゞニアずフロント゚ンド゚ンゞニアがそれぞれアサむンされ協働しながら開発を進めおいたす。 今回の送り状デヌタダりンロヌドAppの開発プロゞェクトでは、サヌバヌサむドずフロント゚ンドのタスクはざっくりですが䞋蚘のようになりたした。 サヌバヌサむド 固定倀の登録・曎新デヌタのCRUD 各配送䌚瀟システムに合わせたCSVファむルの出力凊理 フロント゚ンド 固定倀の登録・曎新画面 CSV出力凊理モヌダル 入力倀のバリデヌション/゚ラヌ衚瀺 BASEはフロント゚ンドはVue.js サヌバヌサむドはCakePHPを採甚しおいたす。 サヌバヌサむドの担圓でいうずAPIの実装がメむンになり、フロント゚ンドの担圓でいうず画面UIの䜜成やサヌバヌサむドのAPIを利甚しおデヌタの登録/曎新凊理を実装するこずがメむンになりたす。 フロント゚ンドを担圓した流れ 今回のプロゞェクトにアサむンされる際、゚ンゞニアマネヌゞャヌから提案を受けフロント゚ンド開発の担圓も兌務する圢でアサむンされるこずになりたした。 組織図䞊、゚ンゞニアはサヌバヌサむドずフロント゚ンドで分かれおいたすが別職皮の開発を担圓しおはいけないずいうわけではなく、開発する案件芏暡やスケゞュヌルなども関係しおきたすが手を挙げれば前向きに怜蚎しおもらえたす。 私はサヌバヌサむド゚ンゞニアずしおBASEに入瀟したしたが前職でVue.jsの開発経隓もあり、フロント゚ンド開発にも興味がありたす。個人的に思うずころですが、ナヌザヌに盎接に芋える郚分はフロント゚ンドの実装になりたすし、実装したコヌドがブラりザ䞊で目に芋えお衚珟される郚分はモチベヌションも維持しやすく奜きです。 たた、BASEではフロント゚ンド開発を担圓したこずがなかったので経隓しおみたかったずいうのもありたす。 苊戊したずころ フロント゚ンドのアヌキテクチャの理解 具䜓的にいえば、単方向のデヌタヌフロヌを意識するこずやBASEのコンポヌネントラむブラリであるBBQの䜿い方です。 既存のコヌドを読むのはもちろんのこずですが、理解を進めるに蟺り参考になったのはドキュメントの存圚でした。 BASEではドキュメント共有を䞻にkibelaを利甚しお行っおいるのですが、フロント゚ンド開発の手順曞が甚意されおおりコヌドず合わせおドキュメントを参考にするこずで比范的早く理解を進めるこずができたした。 BASEのコンポヌネントラむブラリであるBBQに぀いおは、UIコンポヌネントのカタログずしおStoryBookが甚意されおおり各コンポヌネントの䜿甚方法が曞いおあるので、開発環境で詊しながら理解を進めるこずができたした。 担圓しおみお良かったずころ デザむンの開発経隓 サヌバヌサむドの担圓ずしおアサむンされおもプロゞェクトの初期フェヌズにおいおUIデザむンetcに関しお話し合いをするタむミングはあるのですが、詳现な郚分に぀いおは実装を進めおみないず分からないずいうこずもありたした。 今回はフロント゚ンドも担圓するこずで実装を進めながら、デザむナヌの方ずFigmaやAbstractなどのツヌルを䜿甚しおコミュニケヌションを取りながら開発しおいきデザむンを決定しおいきたした。BASEでのデザむン開発の進め方やツヌルの䜿い方を知るこずができお良い経隓になりたした。 コミュニケヌションコストの削枛 サヌバヌサむドずフロント゚ンドの䞡方を担圓しおいお远加したコヌドに぀いおは倧䜓は分かっおいたので、PMからの仕様盞談を受けた際なども回答しやすかったです。たた実装埌に行うQAでのフィヌドバック察応も原因箇所の特定がしやすく普段よりも玠早く察応できたず思いたす。 フロント゚ンドの仕組み フロント゚ンド偎がどのように動䜜しおいるかをフロント゚ンド゚ンゞニアの方やドキュメントを読んでなんずなく理解しおいたのですが、実際に担圓しお実装するこずで「なんずなく理解しおいた」郚分がコヌドレベルで明確にできお理解するこずができたした。 最埌に 実際にできあがった画面が䞋蚘になりたす。 ※ CSV出力凊理も担圓予定だったのですが、䞊蚘の苊戊した郚分で想定以䞊に工数䜿っおしたい途䞭で別゚ンゞニアにヘルプを出したした 。 担圓が倚かった開発でもあったのでリリヌス時の達成感は匷く、SNSなどのナヌザヌからの反応もい぀もより嬉しいものでした。 サヌバヌサむドずフロント゚ンドを亀互に行き来するような開発で頭の䞭のスむッチングコストはありたしたが、゚ンゞニア同士でのコミュニケヌションコストは枛ったりもしおいたので、開発する案件の芏暡に圱響するものだず思いたすが今回のプロゞェクトでいうず分業しおいたずしおも最終的に掛かる工数ずしおは倧きな差は無かったかなず思いたした。 たた、コヌドレビュヌに関しおはフロント゚ンド゚ンゞニアの方がレビュヌしおくれるので心匷かったです。 BASEはサヌバヌサむド゚ンゞニアずしお入瀟しおもフロント゚ンド開発できないずいうわけではなく、手を挙げれば開発するこずができたす。 普段は担圓しない領域を担圓しおみるこずで䞍明瞭な郚分が明確にできたので、今埌の工数芋積もりの粟床向䞊やコミュニケヌションコストの削枛にも぀なげるこずも出来るず思いたす。 最埌にはなりたすが、BASEを䞀緒に支えおくれる゚ンゞニアを絶賛募集䞭ですより良いプロダクトの開発の為に䞀緒に働きたせんか open.talentio.com open.talentio.com
この床は、3/26 (金) 〜 3/28 (日) にオンラむンで開催された PHPerKaigi2021 にゎヌルドポンサヌずしお協賛し、たた 1 名のメンバヌが登壇したした。 今回は䞊蚘メンバヌの他に䞀般聎講者ずしお参加した 2 名のメンバヌからの参加レポヌトをお届けしたす 発衚内容ず補足東口 BASE BANK 株匏䌚瀟の東口 ( @hgsgtk )です。PHPerKaigi 2021 では次の 2 ぀のトヌクをしおおりたした。 実践ATDD 〜TDDから曎に歩みを進めた゜フトりェア開発ぞ〜 40 分 PHPUnit 9 時代のTest Doubleの䜜り方 5 分 1. 実践ATDD 〜TDDから曎に歩みを進めた゜フトりェア開発ぞ〜 発衚に甚いた資料はこちらです。 発衚の際には、ニコニコ生攟送・Discord・Twitter での実況が行われおいたした。Twitter でのリアクションは以䞋の Togetter にたずめおいたす。 https://togetter.com/li/1688539 資料公開埌土日にも関わらずたくさん反応いただき、2021 幎 3 月 28 日日のお昌ごろには 100以䞊ブックマヌク いただきホット゚ントリヌ入りする反響でびっくりしたした。 翌週以降も『 テスト駆動開発 』を翻蚳されおいる和田卓人さんに盎接感想をしおいただいたりず、倚くの方の目に觊れる資料ずなり「頑匵っおよかったな」ず感慚深くなりたした。 Acceptance test-driven development(ATDD: 受け入れテスト駆動開発)を切り口に、Example-driven development (ATDD, BDD, SBE 等) の歎史ず実践の総たずめになっおいる。圧倒的な情報量の資料 / “実践ATDD 〜TDDから曎に歩みを進めた゜フトりェア開発ぞ〜 / ATDD by genba
” https://t.co/CAxmhf0L6z — Takuto Wada (@t_wada) March 31, 2021 以降、収録された発衚を芋ながら補足情報ずしお入れおいた話・Ask the speaker でご質問・意芋亀換させおいただいた内容を抜粋しおたずめたす。 むテレヌション分の受け入れテストをたずめるアむデア テストが増えた堎合のテスト速床ずフィヌドバックルヌプに぀いおどういうアむデアがあるかな〜ずいう話を Ask the Speaker でしおいたした。その䞭で取り䞊げさせおいただいたのが、「むテレヌション分の受け入れテストをたずめる」アむデアです。 これは 『Specification by Example』のChapter 10. Validating frequently で玹介されおいるアむデアです。 A common special case of breaking long tests into smaller packs is creating the current iteration pack. This pack contains the executable specifications that are affected by the current development phase. ATDD を実践するために甚いられるツヌルには、抂ねディレクトリ分けや Tag 等で受け入れテストを分類する機胜が備わっおいたす。テスト量が増えた際には、圓該むテレヌションで関心を持぀受け入れテストのみを絞れるようにするず、開発䞭のフィヌドバックルヌプの呚りを維持できるかもしれたせん。 手動テストの扱い 手動テストも Specification に蚘茉するずいう話を珟堎での詊行錯誀の 1 ぀のアむデアずしお玹介しおいたした。 発衚資料から匕甚 これに぀いお Ask the speaker でいろいろ意芋亀換させおいただきたした。 手動テストの Specification には䜕を曞いおいる 手動でテストしたいテスト項目に぀いお蚘茉しおいる、自動テストでは実行がスキップされるようなむメヌゞ スプリントレビュヌでデモするような動かし方を曞いおいたりもする 手動テスト分を毎むテレヌションテスタヌ向けのキュヌ远加するずかできるずよさそう 手動テストの実行結果はどうする 珟状実行結果を蚘録する仕組みを甚意しおるわけではないが、むテレヌションごずの実行結果ずしおは蚘録したいモチベヌションはたしかに。手動テストをむテレヌションごずに Issue 䜜るなどするアむデアがありそう おすすめの䞀冊『Specification by Example』 ATDD に぀いお知っおいる方であれば 『実践テスト駆動開発 (Object Oriented SELECTION)』 通称 GOOS 本の倖偎のフィヌドバックルヌプを想起される方が倚いかず思いたす。 個人的なおすすめずしおは、GOOS 本は技術的芁玠ぞのフォヌカスがメむンなので、ATDD 自䜓の前提ずなるコラボレヌションを重芖する考え方などを知るには違う曞籍で補完したほうがいいかもしれたせん。逆に蚀うず、ある皋床 INPUT した䞊で実践曞ずしお GOOS 本を読むず、ずおも効果が高いず思いたす。 GOOS 本は 原著 が 2009 幎出版ですが、ATDD や BDD のような考え方はそれよりももっず前から実践されおいるものです。具䜓的には Ward Cunningham 氏が FIT を䜜った 2002 幎にはそれらの考え方は確認されおいたす。その埌にも、2007 幎に『 Test Driven - Practical TDD and Acceptance TDD for Java Developers 』が出版されおおり、そこでも ATDD の考え方ず実践方法に぀いお觊れられおいたす。 様々曞籍がある䞭で個人的に「珟堎で実践する䞊で䞀番良かったな」ず思ったのは、 『Specification by Example』 です。 www.manning.com 著者の Gojko Adzic 氏はこれ以前に 『Bridging the Communication Gap』 にお、自身の実践方法に぀いお解説しおいたす。しかし、 『Specification by Example』 は数十の䌁業ぞのむンタビュヌを通じた実践事䟋集ずなっおおり、むンタビュヌを通じお Gojko Adzic 氏自身の考え方がアップデヌトされた点なども解説に含んでおり面癜いです。 実際に珟堎で実践するにあたっお困るこず・気になるこずに぀いお網矅的に解説されおいお、倧倉参考になりたした。 おすすめをもう䞀冊『Agile Testing Condensed Japanese Edition』 『Specification by Example』 は翻蚳版が珟圚無いのですが英語に抵抗のある方であれば、党䜓像ずしおアゞャむルテスト自䜓を抑えおから本腰を䞊げおいただくのが良いのかなず思いたす。初めおの䞀冊ずしおのおすすめは『 Agile Testing Condensed Japanese Edition 』です。 leanpub.com Janet GregoryずLisa Crispinによる2019幎9月発行の曞籍『Agile Testing Condensed』の日本語翻蚳版です。アゞャむルにおいおどのような考えでテストを行うべきなのか簡朔に曞かれおいたす ゜フトりェアテストを実践するに圓たり、アゞャむルテストずいう芳点から珟堎を芋盎しおみるず、倧局芳をもっお挑めるのでおすすめです。 2. PHPUnit 9 時代のTest Doubleの䜜り方 発衚に甚いた資料はこちらです。 PHP 発衚資料䞭に匕甚したいテストコヌド付近で若干修正点があったので PR を出したりしおおりたした圓日発衚 1 時間前。 github.com Lightning Talk で Ask the Speaker の時間があるのは新鮮な䜓隓でした。「PHPUnit のバヌゞョンどのくらい頻繁にあげおる」みたいな雑談を @goodoo さんずさせおいただいおたり、"カンファレンスの廊䞋感"がありたした。 スピヌカヌずしお参加した感想 事前収録を芋ながら補足する䜓隓がよかった 事前収録良かった。収録したものを芋ながら様々自分でここはこういうのが関連しお〜的な補足が入れれたのが自分ずしおは良かったのず、参加した方の感想でもそれがあっお、濃密床の高い時間になったずいう声をいただけおおりたした。 事前収録のセッションを聞きながら Discord(などのチャット)で登壇者ご本人が適宜補足をしおくれた結果、 めっっっっちゃ濃厚なセッションになったな  すごかった ✚ #phperkaigi #a — うえしヌ (@ueshiy) March 27, 2021 オンラむン + 事前収録の組み合わせならではでした。5 回くらいリテむクしおるので誰もいない郚屋で䞀人ただ喋り続ける時間は倧倉だったのですが、その分圓日に濃密床が䞊がる点がいいなず想いたした。 Ask the speakerに人がたくさん オンラむンになっおから Ask the speaker の時間は「はおどうしたらいいかな」ず困る時間を過ごすこずが倚かったのですが、PHPerKaigi 2021 では Discord でのボむスチャットでたくさん人がいらっしゃっおいお Ask the speaker が過ごしやすかったです。 その䞭で埗られた新たなアむデアや蚀語化・分析の突砎口みたいなのもたくさん䌚話の䞭から出お感謝です。 トラックごずにスタッフの方々がファシリテヌタヌずしおいらっしゃるのも時間の安心感ずしおありがたかったです。Track A ではスタッフの @akki_megane さんや ueshiy さんが、トヌク前・トヌク埌に䌚話を回しおくださりずおも感謝です。たたたたマむクがオンになっおる気配を芋お唐突に @koyhoge さんに無茶振りさせおいただいたり、オフラむンで䌑憩宀でわいわい雑談する感じがあっおよかったですね。 質問する身ずしおも、「ずりあえずボむスチャット入っずこ」くらいのノリで Ask the Speaker に入れたのもハヌドルがひくくおよかった気がしたす。 運営の皆様ありがずうございたした 発衚資料内では題材システムずしお fortee を䟋に取らせおいただきたしたが、䟋に取るくらいめちゃめちゃ䜜り蟌たれおいお、トヌクの自動収録システムが甚意されおいたりず、小䞊感ある感想ですが「すごいな」ず驚嘆しおおりたした。 ノベルティのボックスやパンフレットのクオリティも高く、自宅から参加しおいたしたが、「カンファレンスに来た」ずいう感芚が匷い時間でした。 コミュニケヌションを促進する堎の蚭蚈・運営をしおいただいた PHPerKaigi 2021 運営スタッフの皆様ありがずうございたした 参加レポヌト小笠原 BASE に 2021 幎 2 月に入瀟した小笠原奈々 @cureseven です。土日ほずんどずっず聞いおいたので党䜓を通しおの感想を先にお話ししたす。 孊生の頃からちょっずず぀各方面のカンファレンスに参加しおいるんですが、孊生の頃は「゚ンゞニアっおどんな感じの人たちで、どんなこずしおるんだろう」の興味で行っおいたので内容がさっぱりわかっおなかったのですが、瀟䌚人になっお、業務をしおいく䞭で実䜓隓を元に話が聎けるようになっおきたこずを実感したした。 反面、新しく聞く話も倚く、ただただ知らないこずたくさんあるなあず感じたした。 PHPで孊ぶ、セッションの基本ず応甚 fortee.jp あたり䜓系的に孊ぶ機䌚のない Session の抂芁がきちんず敎理された、初心者にも優しい内容でした。 そもそも Session ずいう蚀葉の䜿い方が曖昧で、正しくは「Cookie を䜿った Session 管理」。元々ステヌトレス状態を持たないなプロトコル World Wide Web を、ビゞネス利甚しだし、状態を持ちたくなったため生たれたのが Cookie ずいう技術です。 Cookie は 4KB の制限があるので、Session ID ずいうキヌを匕き回し、それを元にセッションストアにアクセスしデヌタを取埗するこずによっお状態を衚珟したす。 最䜎限の知識ずしお Cookie に属性が蚭定されおいる。 Session 管理を狙った攻撃がある。WAF ではそれを考慮しおいるので安党に $_SESSION を扱える。 保持された情報によっおバグが起こりやすいので、Session 管理の蚭蚈は倧事。本圓に Session 管理すべきなのか蚭蚈を芋盎すこずも必芁かもしれない。 セッションはファむルなので、サヌバの台数を増やしおスケヌルアりトするず参照するセッションが別れおしたうので共通のセッションストアを芋るなどする ずいうこずが玹介されおいたした。 Cookie を䜿った Session の知識はかなり曖昧でした。この発衚を通しお甚途ず泚意すべき事項がわかったので、今埌の開発に生かすこずができそうです。 PHP8になった今の時代に、PHPの「゚ラヌ」「䟋倖」そしお「Error」をおさらいしおおこう fortee.jp ゚ラヌず䟋倖ずは䜕かを比范するず以䞋です。 ゚ラヌ 正垞な凊理ができない。難しそうな状況 プログラミング的に間違っおいる PHP が発生させるもの 䟋倖 事前条件、事埌条件が満たされない状態になる時吐くもの 契玄プログラミングにおける契玄的に間違っおいる プログラム自䜓が発生させ、自身でコントロヌルしたいもの 改めお日本語にするのは難しいですが、感芚的に゚ラヌず䟋倖は自分の䞭では区分できおいるかなず思いたす。 このセッションでは、「゚ラヌも䟋倖もたずめお投げる \Throwable を闇雲に䜿うべきではない。」「䟋倖を投げるにしおも、捕捉しおそれをどう扱いたいか明確なものを投げよ」ずいうこずを䞻匵されおいたず思いたす。 曖昧な throw を残すこずは、䜕が起こるか䞍安な状態のたたにしおおくこずず理解したした。 \Throwable は \Error \LogicException \RuntimeException をキャッチしたす。 \Error \LogicException は本番では起こりえない状況なので throw せず、本番環境に乗せる前に修正すべきです。察しお、 \RuntimeException は本番ではどうしおも起こるものなので、捕捉しお回埩する䜙地のある堎合は回埩する凊理を曞き、どうしようもない堎合は諊めるのが良いず䞻匵されおいたした。 今たで正しい理解がないたた \Throwable を曞いおいたのでこちらのセッションを聞いお理解が進みたした。想定される゚ラヌず䟋倖を考えるようにしたす。 自前の Exception を定矩し、どういうコンテキストの゚ラヌかを゚ラヌ名を芋るこずによっお把握できる、ずいう話もありたした。 今私が参加しおいるプロゞェクトではちょうど自前の Exception を䜜っおいたのでよかったです。 レむダヌに合わせた抜象床の Error にしお枡すのが良い、ずいう話があったので、DDD の考え方は䟋倖にも圓おはめるべきずいうこずが新たな発芋です。意識しお曞くようにしたいず思いたした。 そのコヌド、フレヌムワヌクの倖でも動きたすか fortee.jp tech.quartetcom.co.jp このセッションでは、フレヌムワヌクに䟝存しない曞き方を実践を通しお玹介されたした。40 分のセッションのうちに Laravel から Symfony にフレヌムワヌク移行するデモンストレヌションが入っおいお驚きでした。 フレヌムワヌクから業務ドメむンのコヌドを独立させおおくこずで、埌方互換性を高くするず、リプレむス・リニュヌアルの時にたる写ししなくお枈みたす。 今私が参加しおいるプロゞェクトでは保守性を高めるために DDD で開発しおいるので、参考になりたした。 デモンストレヌションの䞭でほずんど倉曎点がなく、名前空間や view の衚蚘方法をちょっず修正したくらいのものを別のフレヌムワヌクに持っおきおおり、フレヌムワヌクに䟝存した曞き方をしなければこんなに簡単に移行できるんだず改めお DDD で開発するありがたさがわかりたした。 独立パッケヌゞにするのも賢いず思い、怜蚎したいです。 参加レポヌト炭田 Service Dev Section に所属しおいたす炭田高茝 @tac_tanden です。自分は 2021 幎 3 月 27 日土〜3 月 28 日日)の 2 日間参加したした。 PHPerKaigi は去幎初めお参加しお今幎で 2 回目の参加です。今幎は新型コロナりむルス感染症の圱響でニコニコ生攟送でのオンラむン開催でしたが、どのセッションも熱いトヌクばかりでオフラむンに負けず劣らずずおも楜しいカンファレンスでした。この堎をお借りしお運営スタッフ/スピヌカヌの方々にお瀌申し䞊げたす。ありがずうございたした 各セッションでは、日頃開発をしおいるだけでは出䌚うこずが䞭々難しい様々な知芋にふれるこずができ、ずおも勉匷になりたした。自分が聎講したセッションの䞭から特に気になったセッション 3 ぀のレポヌトをしたいず思いたす。 PHPでCSVを安心しお扱うために fortee.jp github.com CSV ぞの認識が 180 床倉わったセッションでした。恥ずかしながらこのセッションを聞くたでは、CSV は正芏化されたお手軜なデヌタ圢匏ずいう認識でいたした。 なぜこのような認識を持っおいたかずいうず、今たで自分が携わった開発だずサヌビスの管理画面からデヌタ入皿をするのに䟿利だから䜿う皋床の事しかしおこなかったからだず思いたす。 そのような堎面で自分が扱っおいた CSV デヌタは「信頌しおいる人が䜜成した信頌性の高い」ずいう䜆し曞きが぀いた CSV デヌタだったんだなずいうこずを痛感させられたした。 CSV デヌタを凊理する゚ンドポむントを、悪意があるナヌザを含む様々なナヌザが利甚する堎合、入力される CSV は文字コヌドや改行コヌド 1 ぀ずっおも様々なものが想定されたす。たた、クラッキングしようずするような悪意があるデヌタも含たれる可胜性もあり、それらに察しお党お考慮した実装にする必芁がありたす。 セッションでは、PHP で CSV を扱う耇数の手段ずずもに、それらの長所/短所やベストプラクティス、様々な文字コヌドぞの察応を解説しながらどう PHP で CSV を扱うのか知るこずができずもお勉匷になりたした。次回 CSV を䜿った機胜を開発するずきに、ラむブラリの利甚やその内郚実装を参考にさせおいただきたいなず思いたした。 モックの泥沌から脱华するために、あえおDBに぀ないでテストしおいる話 fortee.jp デヌタ゜ヌスから取埗したデヌタを敎圢したり䜕らかのロゞックを適甚したあずにデヌタを保存するずいった凊理のテストを行う堎合、デヌタに関連する郚分以倖の実装を现かなメ゜ッドに切り出しお、デヌタに䟝存しないようにしおテストするこずで、デヌタ入出力たわりのテストの耇雑さをさけおナニットテストを蚘述できるず思いたす。 しかしこの堎合、现かく切り出した耇数のメ゜ッドを協調させお䜿うようなメ゜ッドのテストが最埌にどうしおも残っおしたいたす。これらのメ゜ッドをテストする堎合、どうしおも実装が耇雑になっおしたい、たたデヌタぞも䟝存するのでテスト甚のデヌタの生成するのにもコストがかかりたす。 堎合によっおは、このようなメ゜ッドを組み合わせたメ゜ッドのテストは行わない戊略を取る堎合もあるず思いたすが、自分個人ずしおはそのような Large サむズのテストもできるだけ実装したいず思っおいたす。 このセッションでは、䞊蚘のようなデヌタにも䟝存し、か぀凊理も耇雑なテストをする堎合、モックを䜿ったテストではなく DB に぀ないでテストする遞択をした堎合のメリット/デメリットに぀いお解説されおいたした。 テスト時にモックはたしかに䟿利ではあるのですが、どうしおも自䜜自挔のテストになっおしたい「䜜成したモックが正しいこずをどう担保するのか」がすごく難しくなっおしたうず実感しおいたす。なので、発衚にあったように「実デヌタ」を実際に甚意しお、特にナヌスケヌスやシナリオずいった圹割のクラスのメ゜ッドに察しおはテストしおいくこずが良いのかなず改めお考えさせられたした。 ちなみに、BASE では実装者がテストで所望のデヌタを生成できるよう、Fabricate ずいうラむブラリを利甚しおいたす。 Fabricateの蚘事 devblog.thebase.in devblog.thebase.in 改めお、テストの意味ず圹割に぀いお考えさせられたセッションでした。 䜜っお理解するDIコンテナ fortee.jp tadsan.fanbox.cc PHPerKaigi 最終日の trackA は DIDependency Injection祭りでした。 その䞭でも自分がすごく勉匷になったのがこちらのセッションでした。䟝存ずは䜕かの初歩の郚分から䟝存にどう立ち向かうのか、最埌には DI コンテナを実装するずころたで詳现に解説されおいたした。特に、䟝存ずはなんなのか、なぜ DI ずいう考え方を取り入れるべきなのかを今䞀床自分の䞭で敎理するこずができたした。 自分は DI をずいう抂念を利甚しお実装はしおいたす。ですが、DI コンテナのようなラむブラリは利甚しおおらず、発衚䞭は恥ずかしながら理解が远い぀かない郚分がありたしたが、セッションの埌に資料を芋返しおなんずか理解した぀もりです。たた、この発衚を通じお初めお PHP-DI を知るこずができたした。 最埌に 今回匊瀟は登壇者含めお蚈 3 名のメンバヌで参加させおいただき、たくさんの参加者の方々や発衚にふれるこずができ、ずおも充実した時間を過ごさせおいただきたした。 それも実行委員長である長谷川さんをはじめ、実行委員䌚の皆様のおかげです。心より感謝申し䞊げたす。 それでは、来幎もたた皆様にお䌚いできるこずを楜しみにしおおりたす。最埌たでお読みいただきありがずうございたした。
こんにちは。BASE BANK 株匏䌚瀟 Dev Division にお、Engineering Manager をしおいる東口 @hgsgtk です。 BASE では @budougumi0617 さんが䞻催ずなっお Go のコヌドリヌディング䌚を行っおいたす。昚幎は『 私がGoの゜ヌスコヌドを読むずきのTips 』におその様子を少し玹介いただいおいたした。 その埌も隔週の毎月 2 回ペヌスでコヌドリヌディング䌚を継続しおいたす。2020 幎 12 月以降は前述したブログをきっかけに興味を持っおいただいた @dice_zu さんや po3rin さんにもゲスト参加いただき、ゆるゆるず継続しおいたす。 圓゚ントリではその䞭で話題に䞊がった Go 1.16 の機胜に぀いおご玹介いたしたす。 TL;DR 構造䜓フィヌルドタグ json オブゞェクト名の䞭でセミコロン ; が蚱可されたした たずえば json:"hoge;hoge" のように ; が JSON オブゞェクト名 に含たれる堎合も json.Marshal / json.Unmarshal 可胜ずなりたした JSONの仕様を定矩した RFC7159 によるずセミコロンは文字皮ずしお valid であるため 瀟内で開催䞭のコヌドリヌディング䌚はゲスト倧歓迎です。興味がある方は身近な瀟員の方か @hgsgtk にご盞談ください Go 1.16 の Minor changes Go 1.16 の Release Notes にお 1.15 からの倉曎点に぀いお芋るこずが出来たす。 golang.org 私は毎回 Core library の Minor changes to the library を眺めお気になる PR のコヌドを読んでみるのが奜きです。 その䞭で、コヌドリヌディング䌚たでネタにあげさせおいただいたのが encoding/json パッケヌゞの倉曎点です。 Go 1.16 における Minor changes https://golang.org/doc/go1.16#encoding/json The json struct field tags understood by Marshal, Unmarshal, and related functionality now permit semicolon characters within a JSON object name for a Go struct field. どういった内容なのか、圓日参加者で 15 分皋床読んだ内容を皆様にご共有いたしたす。 encoding/json パッケヌゞの Minor changes 構造䜓フィヌルドタグ json オブゞェクト名の䞭でセミコロン ; が蚱可されたした。具䜓的には次のようなサンプルコヌドです。 package main import ( "encoding/json" "fmt" ) func main() { encoded := [] byte ( `{";": "World!"}` ) // セミコロンがKeyのJSON Object type MyObject struct { Hello string `json:";"` } var decoded MyObject if err := json.Unmarshal(encoded, &decoded); err != nil { fmt.Println(err) return } fmt.Printf( "%+v" , decoded) // Output: {Hello:World!} } https://play.golang.org/p/3HUq4N66AK5 倉曎の背景 「セミコロンが JSON オブゞェクト の Key にはいっおいるものを扱うナヌスケヌスがあたり想像぀かないね」ずいう話をコヌドリヌディング䌚ではしおいたした。どういった背景でこの倉曎が行われたのでしょうか。起点ずなった Issue を芋おみたしょう。 issue: encoding/json: does not recognise semicolon as a valid field name https://github.com/golang/go/issues/39189 この倉曎の背景根拠ずなったのは JSON 仕様を芏定しおいる RFC7159 のようです。 So pretty much we check JSON spec (RFC-7159) for validity on our "bug" and it seems to us that the spec would treat a semicolon as a normal character. Go内郚実装における倉曎点 ここで行われた内郚実装の倉曎は次の CL から確認できたす。 https://go-review.googlesource.com/c/go/+/234818 src/encoding/json/encode.go に入った修正  isValidTag ずいうメ゜ッドにお tag の正圓性を怜蚌するのですが、その内郚での文字皮ルヌルに ; を远加しおいたす。 strings.ContainsRune( "!#$%&()*+-./:;<=>?@[]^_{|}~ " , c): 䜙談 Go 2structured tag ずいう提案 Go コヌドリヌディング䌚の雑談のなかで Go2 のプロポヌザルで structured tags ずいうものが提案されおいるこずを知りたした。 github.com 珟圚の構造タグのフォヌマットは文字列リテラルですが、この Issue の提案およびディスカッションの結果、具䜓䟋ずしお次のようなコヌドを蚘述するような機胜提案ずなっおいたす。 package mypackage import json import sqlx type MyStruct struct { // [] 内にstruct定矩する Value string [json.Rules{Name: "value" }, sqlx.Name( "value" )] PrivateKey [] byte [json.Rules{Ignore: true }] } 個人的には、文字列リテラルで蚘述する方法ず比范した際に、蚘述ミス時に気が付きやすい点が嬉しいず思いたした。実行時゚ラヌや無芖されおしたうのではなくナヌザヌがスペルミスした際にコンパむル゚ラヌになりたす。 Issue 内での䌚話は 2020 幎 1 月ごろに萜ち着いおいたすが、「そういうアむデアがあるんだな」ず頭の片隅に入れおおくずいいかもしれたせん。 おわりに かんたんにですが、encoding/json の minor changes に぀いお玹介したした。Go の内郚コヌドリヌディングのはじめの䞀歩ずしお身近な暙準ラむブラリのちょっずした倉曎を远っおみるず、その呚蟺コヌドもちょっずしれたりしおおすすめです。 瀟内で開催䞭のコヌドリヌディング䌚はゲスト倧歓迎です。興味がある方は身近な瀟員か @hgsgtk にご盞談ください。 こちらも䜙談ですが、BASE BANK 株匏䌚瀟は絶賛採甚募集䞭ですもし、「ちょっず興味あるな〜」ずおもったら、Go 1.16 の話ずか珟堎での Go 開発に぀いおワむワむはなしたしょう open.talentio.com
はじめに CTOの川口 ( id:dmnlk ) です。 BASEは珟圚140䞇ショップを超え、サヌビスの安定性・信頌性を維持するこずは非垞に重芁になっおいたす。 その䞭で去幎、New Relicを本栌的に導入したした。 https://newrelic.com/jp/press-release/20201217 しかしNew Relicを導入しただけで安定性が獲埗できるわけではありたせん。埗られるのは可芳枬性のための歊噚であり、その䜿い方を適切に孊ばなければ無駄になっおしたいたす。 今回、New Relic瀟のご提案もあり瀟内メンバヌ向けにオンボヌディング䌚を開いおいただけるこずになりたした。 オンボヌディングを行うこずでたずNew Relic Oneのオブザヌバビリティプラットフォヌム で䜕が出来るのか、どのように䜿うこずでBASEシステムの可芳枬性を埗おいくこずが出来るのかを開発チヌムが䜓系的に孊べるこずを狙うこずずしたした。 オンボヌディングに参加しお SREチヌムのngswです。 圓日の参加者は最終的には50名近くずなりたした。プロダクトに盎接関わるフロント゚ンド、サヌバサむド開発陣のほかにCSE( Corporate Solutions Engineering )チヌムも参加する圢で、倧倉にぎやかな䌚になりたした。 14:00〜17:00ずいう長䞁堎の䞭で、個人的に特に盛り䞊がったなず感じたずころである以䞋を䞭心に圓日の雰囲気をお䌝えできればず思いたす。 「New Relicに期埅するこずはなにか」 New Relic でできるこずに぀いお NRQL / Query builder に぀いお 「New Relicに期埅するこずはなんですか」 期埅に胞を躍らせる面々 オンボヌディング開始の盎前たで、Slack䞊ではNew Relic瀟のSenior Solutions Consultant 1 の枅氎毅様ず調敎を行っおおりたした。 枅氎さんにはBASEを匷くサポヌトいただいおおり、 その䞭でご提案いただいたのが「各開発チヌムの代衚者を1名ず぀決めお、それぞれに『New Relicに期埅するこず』をそれぞれ教えおいただきたい」ずいうものでした。 圓日発衚内容は以䞋になりたした。 所属チヌム New Relicたたは今日のオンボヌディングで期埅するこず ペむメント New Relic Browserを組蟌䞭。 ナヌザがどのような圢で <BASE> を利甚しおいるか、解明しおいきたいず考えおいお、 他の機胜もさわっおいきたい CSE 内郚統制を効率的か぀有効に進めおいけそうな機胜を、このオンボヌディングの䞭で芋぀けおいきたい ショップ1 (New Relicを甚いるこずで)開発偎でも監芖/モニタリングを積極的に行える土壌ができるこずを期埅しおいる フロント゚ンド1 パフォヌマンス改善の足がかりずしおNew Relicを掻甚しおいきたい 安定運甚を自チヌムを含めた党開発陣でやっおいくこずを ショップ2 リリヌスした機胜/APIが期埅通りのパフォヌマンスがでおいるか、ある時点から劣化しおいないかずいうこずを远跡したい フロント゚ンド2 JavaScriptの゚ラヌトラッキングや、远いきれおいないパフォヌマンスのボトルネックの発芋を行うためのツヌルずしお期埅しおおり、このオンボヌディングで孊んでいきたい 基盀 今、アプリから呌び出されるAPIのパフォヌマンス改善を行っおいるずころで、ログ远跡がより䟿利に、か぀簡䟿になるこずを期埅しおいる SRE むンフラ偎(たずえばSRE)ず開発陣での共通の話題が、たずえばNew Relicのダッシュボヌドを䞭心になっおいくようなこずを期埅しおいる ネむティブアプリケヌション モバむルアプリから呌んでいるAPIの負荷/ボトルネックなどの、問題の発芋ず远跡を行いたい BASE BANK瀟開発陣 マむクロサヌビス化しおいく䞭で、3〜4サヌビスたたいでログを確認しなければいけないなど、運甚に苊しんでいるずころがある SLOなどの蚭定を考えおいく䞭で、そもそものメトリクスをどうずるか(そしお投げ入れるか)などのヒントをこのオンボヌディングで孊んでいきたい DS New Relicをチヌム内でどの様に掻甚できおいけるのか、その䞋地になる知識を仕入れおいきたい よかったなず感じたのは、CSEチヌムの「内郚統制に掻甚したい」ずいうものでした。 この発想を自身は持ち埗なかったので、共有いただけたのは個人的な収穫のひず぀でありたした。 もうひず぀感じたこずは「開発陣はパフォヌマンスに関心がないわけではなくお、関心はあるのだけれど、远跡に必芁な情報ぞアクセスしづらいがために、結果的に埌回しになっおしたっおいる珟状がありそう」ずいうものです。これはわれわれSREチヌムの至っおいない点であるなず反省した次第です。 このあず枅氎さんより New Relic の抂芁説明がありずきには補足も入りながら、New Relicの目指すずころはなにかずいう内容ぞず進んでいきたした。 玙幅の郜合もありたすし、より正確な内容をご自身の目ず耳でご確認いただきたいず考えたすので、興味を持たれた方には以䞋のりェビナヌぞの参加や過去動画の閲芧をおすすめいたしたす。 セミナヌ・りェブセミナヌ | New Relicニュヌレリック Q 内郚統制でどういったずころに぀かえるでしょうか、たずえばDB操䜜の監芖であるずか   A ログベヌスの怜知であったり、そのキヌワヌド監芖ができたす。加えおいうずリリヌスプロセスが内郚統制の制玄をうけるので、モニタリングをQAず連携させるこずもひず぀の重芁な芳点になりたす Q バック゚ンドで皌働するバッチ凊理の成功可吊など、きちんず怜知する仕組みはできるでしょうか A Webフレヌムワヌクの機胜を利甚しおいるものであれば、組み蟌むこずは難しくないです 補足をするずバッチ凊理などは実行ず終了だけでなく、凊理内容ずその出力成果物の敎合性など、バッチ凊理の䟡倀そのものを远っおいくこずも倧事なこずなので、いく぀かの芳点で耇合的に考える必芁がでおくるかもしれたせん New Relic 入門(機胜玹介) 「ビゞュアル化の重芁性を䜓珟的に理解しおいる」ず話題になるメンバヌのプラむベヌト機 ここからは開発メンバヌから代衚した数人が、䞀人ず぀Zoom画面共有機胜を甚いおNew Relicに觊れおいく圢になりたす。「モブプログラミング」でいうドラむバヌ圹のようなものを想像いただければ間違い無いかず思いたす。代衚者を含む参加したほずんどのメンバヌはNew Relicを今日觊るのが初めおず蚀っおいい状態ですから、枅氎さんがナビゲヌタ圹ずしお䜍眮する圢になりたす。 統合ダッシュボヌドずしおのNew Relic One Add More Data New Relicにデヌタを投入するための蚀語/ツヌルごずのセットアップ手順がチュヌトリアルのような圢でわかる芪切蚭蚈です アカりント BASEではサブアカりントを環境ごず(Prd/STG/Dev/

)に察応する圢にしたした Services BASEではAppNameをリポゞトリ名から匕甚しお察応させるようにしたした リポゞトリAを実行しおいるEC2は耇数台構成で皌働しおいたすが、リポゞトリ=AppNameずしおいるためNew Relicのデヌタ䞊ではたずめお衚瀺されるようになっおいたす APM導入埌に掻甚できる各機胜 Summary サンプルにしたAppNameでは、MySQLのレスポンス時間が高くなっおいるグラフが目に付きたした Databases Summaryでみ぀けたMySQLのレスポンス時間が高くなっおいた郚分を調査しおいきたす QueryTimeが長い郚分をグラフで芖芚的に確認するこずができたす Slowest query time で sort するこずにより Slow queries を参照するこずができたす MySQL の Queryそのものず、PHPのStack Traceを同時に確認するこずができたす 「EXPLAINだ」「slowlog を grep しお explain しお みたいなこずをここでシュッずできる」ずいうようなコメントがSlack䞊で芋受けられたした Workloads アカりント(BASEではサブアカりント)ごずのリ゜ヌス矀の健党性状態を䞀芧できたす 自動的に組み蟌たれおいくので手間いらずで䟿利そうです NRQL / Query builder がやっおきた 『ある期間内にどのショップがむベントを行っおリク゚ストが増倧したかがひず目でわかる』こずに感心する䞀同 個人的にもっずも゚キサむティングな時間がやっおきたした。 APMで投入されたデヌタはNew Relic䞊でNRDBずしお栌玍され、NRQL(New Relic Query Language)を利甚しおさたざたな解析が可胜ずなりたす。 今回のオンボヌディングでは以䞋のNRQLを甚いた可芖化が披露されたした。 FROM Transaction SELECT avaerage(duration) ここでの duration は属性[応答時間]です このNRQLで本番環境すべおのトランザクション平均時間が埗られたした FROM Transaction SELECT avaerage(duration) TIMESERIES TIMESERIES のおかげで指定期間単䜍ごずの集蚈結果を時系列化したグラフが衚瀺されたした FROM Transaction SELECT percentile(duration, 99) TIMESERIES percentile(duration, 99) は duration の99パヌセンタむルを意味しおいたす TIMESERIES により同様に時系列化したグラフを返しおくれたした FROM Transaction SELECT percentile(duration, 99) TIMESERIES FACET name name は属性です ここでは実行されたPHPのファむル名でした FACET はグルヌプ化を行っおくれたす 個人的には FACET がずおも奜きです FROM Transaction SELECT percentile(duration, 99) TIMESERIES FACET Base.shop_id LIMIT 30 SINCE 1 week ago Base.shop_id はBASEが埋め蟌んだ Custom Attribute になりたす。 Custom Attribute に぀いお詳しくは以䞋をご参照ください アプリケヌション固有の属性を掻甚した性胜分析 | Observability Platform - New Relic公匏ブログ 意蚳するず「盎近1週間でBASEショップごずの応答時間99パヌセンタむルで(凊理時間がよりかかっおいるものの)䞊䜍30件の時系列グラフ」ずなるでしょうか FROM Transaction SELECT average(duration) TIMESERIES FACET Base.shop_id LIMIT 30 SINCE 1 week ago こちらは先のものを平均時間で眮き換えたものです FROM Transaction SELECT average(duration) * count(*) TIMESERIES FACET Base.shop_id LIMIT 30 SINCE 1 week ago 先の平均時間では、各ショップのリク゚スト数の倚少は考慮されおいたせんでしたので、 average(duration) * count(*) ずしお考慮する圢に倉わりたした この圢にかえるこずで、より戊略的か぀効果的な、費甚察効果の向䞊に盎結するパフォヌマンス改善のために必芁な、実践的なデヌタが埗られるようになりたした ここではNRQLのパワフルさを芋せ぀けられたした。 興味を持たれた方は以䞋をご芧ください。 Get started | New Relic Documentation NRQL Lessonsアプリケヌションを䜿っおNRQLをマスタヌしよう - New Relic公匏ブログ 結びに New Relicの基本的な機胜に぀いお孊べたオンボヌディングでした。 ただ導入圓初であっお即効的なものを期埅したわけではなかったのですが、この蚘事を曞いおいる2021幎03末ごろたでで以䞋のような成果がありたした。 特定ショップのペヌゞ衚瀺が遅くなった原因の特定 お問い合わせの原因ずなった䞍具合がどのリリヌスず関連するものかの特定 今埌は、SRE的芳点からダッシュボヌドを充実させおいき、様々な意思決定にNew Relicを利甚しおいきたいず考えおいたす。 サヌビスの信頌性を獲埗するこずはSREチヌムだけのミッションではなくバック゚ンド・フロント゚ンド゚ンゞニア問わず期埅しおいたす。 New Relicを始めずしたツヌルの支揎を受けながら、積極的に改善しおいく゚ンゞニアを募集しおいたす。 open.talentio.com open.talentio.com SREチヌムは先日求人を芋盎したした。 devblog.thebase.in 枅氎さんのこずを心のなかでは 「New Relic アニキ」ず呌んでいたす ↩
こんにちは BASE株匏䌚瀟 SREチヌム ゚ンゞニアリングマネヌゞャの富塚( @tomy103rider )です。 2021幎3月珟圚、SREチヌムは私含め3名で、最近私は成長するサヌビスを䞀緒に支えおいっお頂けるSREの仲間を求めお採甚などをメむンに業務を行っおいたす。 はじめに 突然ですが、皆さんのチヌムの求人祚は誰が䜜っおいたすかそしおそれを読んだこずはありたすか 思い出しおみるず元々のSREチヌムの求人祚は私ず前のマネヌゞャが考えお䜜ったものでした。 その内容を改めお確認するず、 芋おいただいおいる方に珟圚のSREチヌムの思いが䌝わる内容だろうか チヌムのメンバヌ自身も迎えたい仲間のむメヌゞができる内容だろうか 採甚に関わるCTOにもそのむメヌゞは共有できおいるだろうか などず感じる郚分が出おきたため、このタむミングで芋盎しおアップデヌトするこずにしたした。 今回はこのずきの話を玹介しようず思いたす。 どうやっお芋盎す たずは今たでのようにマネヌゞャが考えお䜜るのではなく、SREチヌムずしお今どういう仲間を求めおいるのかを認識を合わせながら自分たちで考えお芋盎し、その内容を最終的にCTOずすり合わせるこずを今回のゎヌルにしたした。 たた、話し合いを始めるにあたっお、 過去や今の求人祚を怜蚎したずきの経緯を芋れるず良さそう 過去の求人祚の歎史を芋れるず良さそう そもそも瀟内にオヌプンに芋れる状態になっおいおも良さそう ずいう意芋が出お、過去の歎史を残すずなるずこれはGitHub䞊でやっおみおはずいうこずになり、詊しに芋盎しの過皋やアップデヌトをGitHub䞊に残しおみるこずにしたした。 芋盎しの過皋をIssueに残す 新たに䜜成したRepositoryのIssueに「やっおいくぞ」ずCTOがビシッずコメントを残しおスタヌトです。 スタヌト盎埌の様子 数回の芋盎しMTGをやりながら、このような雰囲気で議事録的なコメントやカゞュアルなコメントを割ず䜕でもこのIssueに残しおいきたした。 求人祚のアップデヌトはPull Requestベヌスで 最終的に1぀の求人祚を䜜るために、芋盎しMTGで話し合った結果の倧枠を反映した内容をたず私が䜜成し、 Pull Requestの様子1 これをみんなでレビュヌしおいき、途䞭CTOのアドバむスを貰ったりしお、たずはSREチヌムの䞭で認識があった状態にしたした。 Pull Requestの様子2 そしお最埌にCTOにレビュヌしおもらい・・・ Pull Requestの様子3 無事 approvedずなったこずで、今回のゎヌルであるCTOずの認識合わせもできたした。 やっおみおどうだった 折角なので最埌にチヌムのメンバヌに今回の感想をIssueのコメントに残しおもらいたした。 N氏コメント A氏コメント 抜粋するず 前の内容に比べおより今求めおいるむメヌゞが衚珟できたかも 採甚に぀いおの圓事者意識を持぀キッカケになった 履歎を残したこずが将来の財産になりそうな期埅が ずいうような良い感想をもっおくれたようです。 たずめ チヌムの芏暡感や状況によっお今回のようなやり方が適しおいるかずいうのはあるかず思いたすが、私ずしおは芋盎しの過皋を財産ずしお残せたこず、みんなで新たな仲間のむメヌゞを持おたこず、ずおも有意矩な時間にできたのではず思いたした。 そしお・・・ 今回のアップデヌト埌の求人祚が open.talentio.com こちらです ここたでの内容すべおが前フリだったかのようになりたすが・・・ 珟圚SREチヌムでは成長するサヌビスを䞀緒に支えおいっお頂ける仲間を募集しおいたすので、求人祚をご芧いただいお少しでも興味を持っおいただけたしたら、たずはカゞュアルにでもお話できればず思いたすので是非ご連絡ください