この記事は BASE Advent Calendar 2019 の1日目の記事です。 devblog.thebase.in こんにちは。BASE BANK株式会社でプロダクトマネージャーをしている柳川（ @gimupop ）です。 直近では、即時に資金調達ができる金融サービス「 YELL BANK（エールバンク） 」というプロダクトのグロース施策に取り組んでいます。 今回はアドベントカレンダーということで、今年僕個人にとって一番大きな変化であった、サーバーサイドエンジニアからプロダクトマネージャーにジョブチェンジしたことを題材に記事を書きます。 プロダクトマネージャーになった顛末 僕はもともと新卒時から、サーバーサイドエンジニアとして働いていました。会社の雰囲気はそれぞれ違っていて、どちらかというとエンジニアの役割が限定的な会社で働いていました。BASE入社後もサーバーサイドエンジニアとして入社し働いていましたが、BASEは今までの会社とは違いました。 一人のエンジニアが見る範囲が比較的広いこと プロダクトの成長にかける情熱が強いこと 上記2点が特に感じた違いです。この違いは僕の狙い通りのことで、とても気持ちよく働けました。そのように働くうちに、より強くプロダクトの成長にコミットしたいと考えるようになりました。今も携わっているプロダクトである「YELL BANK」の新規開発では、プロダクトのビジョンの部分を持つ企画担当者とともにそれを具体化する役割をもって動いていました。仕様作成、設計、実装、QAまで特定の役割に固執せず、メンバーと協力しながら開発を進めていきました。そしてリリース後、いろいろな線が繋がり、2019年7月から、正式にプロダクトマネージャーに就任しました。 プロダクトマネージャーとして試行錯誤する中での気付き プロダクトマネージャーは、プロダクトの責任者としてまわりから見られる 役職名が明らかになったので、僕がプロダクトに責任を持つことが明確になり、他のチームから情報が集まりやすくなりました。また他のチームに協力をお願いする際も違和感がなくなり、スムーズに話が進むようになりました。肩書でまわりからの見られ方が変わるという経験でした。 プロダクトマネージャーは、チームを作る 僕がエンジニアからプロダクトマネージャーになることで、当然ながらエンジニアの数が減りました。実質2足のわらじ状態になってしまい、開発にかけられる工数は落ち、新たに期待される役割に従事するのにも時間がかかりました。 その状況を改善する手段の一つして、人の採用があります。採用活動の中で良い縁があり、現在ではエンジニアのメンバーが1名増えました。一時的に苦しい状況にはなりましたが、結果として以前よりも更に強いチームになっている実感があります。プロダクトの未来を描く上で、チームの未来を描くことも必要であると気が付きました。 プロダクトマネージャーは、プロダクトの成長段階の最先端にいる プロダクトの成長段階の変化に気がつくのに遅れて、開発に停滞感をあたえてしまいました。自分の役割が変わるのと近い時期で、プロダクトの段階にも変化がありました。新規の機能開発のフェーズから、プロダクトグロースのフェーズへの変化です。 そのフェーズでは、闇雲に機能開発をするのではなく、状況を捉えるということが必要でした。エンジニアとして関わるのであれば、プロダクト段階がどうであれ、実現したい機能が目の前に現れて、それをどのように実現するかという部分に集中すれば問題ありませんでした。しかしプロダクトマネージャーは、プロダクト状況の変化を真っ先に捉え、やり方を変化させながら施策を考えて、プロダクトの成長を引っ張っていかなくてはなりません。 自分の決断が、プロダクトの成長スピードに深く結びついていることに気が付きました。 プロダクトマネージャは、Howにより過ぎない エンジニアとして働いていたキャリアは、エンジニアメンバーとのコミュニケーションの取りやすさや、機能の取捨選択の判断や、SQLが書ける等あり、ストロングポイントです。しかし具体的にどう作るかということを考えすぎると、決断が遅れることにもなるし、実装の容易さ等を考えすぎ、機能の内容自体にも影響してきます。何がしたいかという要求を明確にして、その他は考えすぎず他のメンバーと相談しながら進めるべきということに気が付きました。 プロダクトマネージャーは、リズムを作る プロダクト開発は、ときにマンネリ化します。特にプロジェクトが長期化するほど、それこそグロースフェーズにおいてはマンネリ化しがちです。そういう場合にリズムを作り出すことも、プロダクトマネージャーの重要な仕事だと思いました。 未来の計画を立てて、現在やっていることと未来とのつながりを定期的に明確にすること 日々の目標を立てて、それを目に見える形にして小さな達成感を出していくこと 上記のようなことを気にしながらプロダクト開発を主導していくと、比較的フレッシュな気持ちでチームが課題に取り組めることに気が付きました。 プロダクトマネージャーは、プロダクトのことを考え続け未来を見る 来年度の事業計画を作る中で、プロダクトマネージャーは、より未来を見なければならないということを意識しました。その際の思考の流れの中で、未来のビジョンを作るには、過去のデータと現状をより深く知らなればいけないということに気が付きました。より深く誰よりもプロダクトのことを考えるのが、未来を作るプロダクトマネージャーの仕事であるということに気が付きました。 今後 半年間試行錯誤する中でも、これだけの気付きがありました。ただ気付きを得ることが仕事なのではなく、適切なアウトプットを出し続けることが必要です。これらの気付きを活かしつつ、常にゼロベースで引き続きプロダクトマネージャーとして、チームでプロダクトを成長させていきます。

この記事は BASE Advent Calendar 2019 の1日目の記事です。 devblog.thebase.in こんにちは。はじめまして。 Product Dev Divisionでエンジニアリングマネージャーをしている山崎と申します。 BASEに入社して1年半ほどになります。入社後はWebアプリケーションエンジニアとしてEコマースプラットフォーム「BASE（ベイス）」のバックエンド開発をする傍ら、PJの開発ディレクションやチーム作り・組織作りに取り組んできました。 私ごとですが、今年の6月に第一子が生まれました。そして子の誕生に合わせて2ヶ月半の育休を取得しました。短い期間でしたが、父親としても、エンジニア／マネージャーとしても、学びが多い期間でした。このときの体験が誰かの役に立てばと思い、育休取得について書くことにしました。 私の育休取得記 BASEにおける男性の育休取得について BASEにおいて、男性社員で初めて育休を取得したのは現在の私の上司である菊地でした。 菊地が育休を取得したときの体験はこちらにまとまっています。 「日本のパパに、育休のススメ～私の育休体験記～」 当時菊地はいちエンジニアであったため、今回、私は男性かつ管理職としては初めて育休を取得しました。 なぜ育休を取ろうと思ったか 厚生労働省の調査 によると、男性の正社員が育休を取得しなかった理由のTOP3は以下です。 職場が育児休業制度を取得しづらい雰囲気だったから 会社で育児休業制度が整備されていなかったから 残業が多い等、業務が繁忙であったため （ 平成29年版 少子化社会対策白書 第2章 第4節 より） 見ていただくとわかる通り、職場環境に関する理由が多く挙げられています。 私自身も育休取得を決意する前は 育休取得を言い出したらどういう反応が返ってくるだろう 忙しいのに数ヶ月単位で育休を取得するのは気が引ける 自分がいない間に問題が起きたらどうしよう 数ヶ月も休んだら現場感を失ってしまう チームにJOINしたばかりのメンバーにとって上司がすぐにいなくなるような環境ってどうなんだろう といったことを悩んでいました。 取得を決意したきっかけは上述した 菊地の記事 でした。 育休期間中の1.5ヶ月は娘の成長を間近で見ることができ、私の人生において生涯忘れないであろうかけがえのない日々となりました。 生まれたばかりの子の成長を間近で見ることができるのはこのタイミングしかありません。また、育児について妻任せにするのではなく、自分もフルタイムで参加したいと思いました。 上司に相談 育休取得を決意し上司に相談したのが2019年初頭でした。当時の上司であった 藤川 （当時CTO／現EVP of Development）に相談したところ「おめでとう！引き継ぎを進めていこう！」と気持ちよく言ってもらえました。不安が吹き飛び、背中を押されたような気持ちになったことを覚えています。 育休前の引き継ぎ 当時の私の仕事は以下のようなものでした。 「BASE」のバックエンド開発と開発ディレクション マネージャー業務 (採用活動／1on1／評価／メンバーの成長支援／ミーティング運用／etc) 準備期間を半年ほど取ることができましたので、結果的に、どのタスクもきちんと引き継いでいただくことができました。引き継ぎ期間を長めに取ることができたので、引き継ぎ内容の資料作成と共有に時間をかけることができたのが大きかったと思います。また、引き継ぎに関わった方々が育休取得に理解を示してくれて、かつ協力的だったのが非常にありがたかったです。 マネージャー業務については少し悩みました。 たとえば、採用活動はチームを作る上で非常に重要な業務です。私は採用フローに関わっていたため、この部分を誰かに引き継ぐことなどできるのだろうか、引き継いだとして不在の間の採用活動はうまく進むのだろうか、と頭を抱えました。しかし、採用基準については普段からマネージャー同士で認識を合わせるようにしていたので、問題なく引き継ぎできました。 結果、まわりのメンバーの協力を得ながら、すべての業務を育休前までに引き継ぎすることができました。 ※ 少し脱線しますが、エンジニアリングマネージャーについては弊社Tech Blogのこちらの記事も合わせて読んでいただければと思います！ 【EOF2019資料公開】社員100人規模のWebサービスにおけるエンジニアリングマネジメント エンジニアとしてワクワクし続けるためのエンジニアリングマネージャという役割分担 育休中 感じたことをいくつか書きます。 まず育児の忙しさについてです。よく「育児しているより仕事の方が楽」「育児以外の時間はとれない」などと言われることがあります。 育休前は、息抜きの時間が少しくらいあるかな、という軽い気持ちがありました。しかし、育休に入るとそのような時間はまったくありませんでした。昼夜問わず3時間毎の授乳・ミルク、オムツ替え、お風呂、寝かしつけ。これ以外にも家事全般など。自分のペースで生活リズムを作れないのが一番大変でした。出産直後の妻がこれらすべてを1人でこなすとなると、精神的にも体力的にも相当な困難であったと思います。 また、子を検診につれていったときのエピソードです。 お医者さん・助産師さん・保健師さんに、私が育休を2ヶ月半取得していることをお話しすると「先進的な会社ですね」「珍しいですね」「ITの会社だから家でお仕事されているんですか」といった反応をされることがありました。 厚生労働省の調査によると、男性の育休取得率が6.16%です。そのうち1ヶ月以上の期間をとっている割合が18.9%です。このことを考慮すると当然の反応かもしれません。 （ 平成30年度雇用均等基本調査 より） 平日にショッピングモールのベビー用品店に行く機会が何度もあったのですが、赤ちゃんが父親と一緒にいる姿を見かけたのは、本当に数えるくらいしかありませんでした。 男性で長期間育休を取得する人が少ないことを実感しました。 復帰 明日復帰する旨を会社のメンバーにSlackで伝えたときの様子です。 Slack以外でも、復帰初日にオフィスを歩いているときにたくさんの方々から「おかえりなさい！」と声をかけていただきました。 2ヶ月半とはいえ、会社とのコンタクトもまったくなく、業務も一切していなかったため、復帰初日は緊張して出社しました。会社のみなさんから声をかけてもらえることが本当にうれしかったです。 復帰直後は、仕事を引き継いでいた方との1on1を中心にキャッチアップを進めました。結果、1ヶ月程度でもとの業務に復帰することができました。 また、私がいない間に仕事の一部を肩代わりしてくれていたメンバーがこの短期間でものすごく成長していて、非常に頼もしかったです。仕事を思い切って割り振った結果、メンバーが責任をもって仕事を進めてくれ、またそのメンバーの成長も見ることができて、嬉しい限りでした（逆に私がいないことによって、このような成長をすることもあるのだな、と気づくことができました）。 育休取得に必要なものって 「配偶者の出産直後の休暇取得を促進するために必要なことはなにか」という問いに、多くの男性が「休暇を取りやすい職場であること」と回答したそうです。また、他にも職場に関する回答が続いています。 （ 平成29年版 少子化社会対策白書 第2章 第4節 より） たしかに、私が育休を取得できたのは、育休を取得しやすい環境が整っていたからかなと思います。とくに、当時の上司（取締役の藤川）が育休取得について理解を示してくれたり、社内に男性の育休取得者がいたりしたことが大きかったです。 余談ですが私が育休を取得したあと、管理職を含め複数名の男性社員が数ヶ月単位で育休を取得しています。私の育休取得の体験が、少しでも他の男性社員の育休取得の後押しになっていたのであれば嬉しいです。 最後に 2ヶ月半の間、父としてかけがえのない時間を過ごすことができました。生まれたばかりの子の成長を間近で見れたことは、人生の宝物です。 この体験をもとに、今後はマネージャーとして、メンバーのみなさんが育休を取得しやすい環境作りに取り組んでいきたいと思います。 以上、私の育休取得についてお話ししてみました。これから育休取得を考えている方の参考に少しでもなれば幸いです。

前書き フロントエンドエンジニアの松原( @simezi9 )です。 先日10月30日にクラウドワークスさんをお借りして実施したVue.jsの設計勉強会である、 Vue.jsアーキテクチャリング勉強会 にて、 BASEの現在のVueコンポーネントの設計に関して登壇してお話してきました。 全体の資料はこちら です もともとBASEではVue.js+TSを採用した大規模なシステムのリニューアルプロジェクトが2018年からスタートしていました。それにあたっての大まかなフロントエンドの構築方針は以前もblogや外部登壇で発表していました。 次世代の管理画面を作るフロントエンドの取り組み - BASE開発チームブログ 次の5年を支えるVue.js製UIコンポーネントライブラリを育てる これまでの発表では大枠の技術スタックやワークフローの話が多かったですが、 今回はVueコンポーネントの設計が勉強会の主眼にあったこともあり、もう少しミクロな観点からVueコンポーネントを作る上で積み上げてきた知見を発表することになりました。 BASEのコンポーネント設計 スライド内でも時間を割いて紹介していますが、BASEのVueコンポーネントは大きく4種類に分かれています。 もともとはAtomicDesignの考え方を中心にしたコンポーネント設計からスタートしましたが、 Atomic Designの考え方はWebアプリのデザインを作る上で有効ではあるものの、実装という観点でいけばそれだけではうまくいかないのでは？という疑問にぶつかり、 最終的にPresentational Component / Container Componentの考えを基準として、そこからそれぞれのコンポーネントのレイヤをAtomic Designの語彙を取り入れながら分解したことで現在のような形になっています。 今回登壇するにあたっての個人的な裏テーマとして、 「Atomic Designを採用している話はよく聞くけれど、純粋にそれだけでうまく回している現場はどれだけあるんだろうか？」 というのを聞いてみたいというものがありました。 実際の発表でもそのような内容に触れてその後の懇親会で話を聞いたところ、純粋なAtomic Designではなく何らかの手を加えた開発をしているプロジェクトのほうが多そうな印象を受けました。 Atomic DesignはモダンWebアプリデザインの設計手法として大きく普及したイメージはありますが、 実際の実装との間をつなぐプラクティスはまだ不足していて、実際にはまだ手探りな部分も多いのかな、というような部分を実感しました。 Storybookの整備 純粋な設計の話とは少しずれてしまう部分はあるのですが、現代のフロントエンド開発の標準装備になりつつあるStorybookの実装についてもお話させていただきました。 Storybookの導入話は見かけることはあっても、各プロジェクトで思い思いの使い方をされていて、プラクティスや運用を実際に言語化している話はそれほど多く見かけないような気がしていたので、自分が開発している中での思いをスライドにしました。 Storybookをデザイナーとエンジニアがコミュニケーションを取るための土台にしていきたい、という思いはプロジェクト開始当初から持っていたものの、 実際に開発していってもなかなかそれがうまくいかず、その原因はなんだろう？というのを考えたものになっています。 スライドでは「サンドボックス」性と「カタログ」性という言葉を使って自分の考えを表現してみました。 Storybookへの実装には、実際にそれを利用するユーザー（デザイナーだったりコンポーネントを組み込むエンジニアだったり）にむけた 「おもてなしの気持ち」 をプロダクトやサービスに向けるものと同様に持っていかないといけないな、というのが個人的には結論になっていたりします。 各社のstorybookチラ見せナイトとかやってみてほしい — 〆 (@simezi9) August 5, 2019 StorybookもAtomic Design同様にもっと現場でのプラクティスの話が増えてくるといいなと思っています。 実装のtips 最後に実装のtipsとしてあまりWebでは見かけないけど個人的にベタープラクティスだと思っているVue.jsの実装のトピックをいくつか小ネタとして紹介させていただきました。 一番言いたかったことは、 コンポーネントの良さは共通化ではなくて責務の分離 というポエム性が高い部分なのですが、 それだけだと抽象的すぎて面白くないかなと思ったので、Eventの名前の付け方や、payloadの渡し方、aria属性を使ったスタイリングなど実用頻度が高いけど案外解説記事が見る機会の少ない（と思っている）ものを選んで取り上げてみました。 特にVue.jsのスコープ付きスロットは解説が少なくとっつきにくい概念ではあるものの、一度扱えるようになると非常に強力な設計の武器となるのでぜひ取り上げたかったものになります。 このスライドでとりあげている実装テクニック自体は Vuex や Vuetify などのOSSライブラリの実装をかなり参考にさせてもらっているものもあり、 こうした実装tipsに興味のある方はGithubを覗いてみるのがとてもオススメです。 特にVuetifyは実装がよく練られていて質が高いのではないかと思っています。 さいごに 今回スライドとしてまとめて登壇する機会をくださった勉強会運営スタッフの皆様に改めて感謝するとともに、 まだまだ手探りを続けながら発展していくであろうBASEのフロントエンド開発に 一緒に携わっていきたいという方も募集している ので 興味のある方はぜひお声がけいただければと思っています

こんにちは、Design Groupに所属している森（ @ mrkzk ）です！ 少し前に BASEでブランドプロジェクト始めました という記事を公開したのですが、今回はその一環で行われた 名刺リニューアル にフォーカスしてお話ししたいと思います。 なぜ名刺リニューアルを行ったのか 勉強会やミートアップでたびたび「可愛い！」とお褒めいただくBASEのこの名刺 実はこの名刺、代表の鶴岡がデザインしたものなんです、BASEのマルチカラー全開で可愛いですよね。 可愛い。可愛いのですが！よくよく見ると、、現在のブランドガイドライン上だとブランドを毀損していることになります。そしてちょっと情報が多い。 今回のリニューアルではブランドプロジェクトの一環でこの背景に溶け込んでしまったティピを救いBASEのブランドを守ることをメインに、プラスでBASEのそれぞれの個性や、ニュートラルな印象を落とし込んだデザインに変更することにしました！ まずはプライオリティ高めのブランド保持とデザインの方向性 今回のメインであるブランド保持のための変更と、理想をリストアップ 現状 ブランドが守られていない（溶け込みティピ、BASEという文字単体での使用） 名刺の情報に制限がなく人それぞれで情報量が多すぎることがある トレンドからやや外れてきている 当初選んだ紙や印刷からどんどん外れていき、クオリティにムラがある SNSアカウントの記入が任意なので、人それぞれバラバラ 理想 ブランドガイドラインに沿ったもの！ フォント、ロゴを正しく使う BASEのフレンドリーさはそのままに今っぽく マルチカラーを生かしたフレンドリーな雰囲気はそのままに、個性とニュートラル感のあるもの 広い世界に向けて グローバルを意識し、英語表記も作成 紙質と色の再現 名刺交換をした相手の方が思わず触りたくなる紙質かつ、マルチカラーの淡い色をしっかり再現できる印刷 リニューアルにあたって行ったこと 名刺を配る機会が多いカスタマーサクセス、エンジニアのメンバーにヒアリング 過去に名刺で困ったエピソードやあったらいいな、という要望を聞いたり 他社さんの名刺を研究 素敵なところをリストアップしたり 業者選び 仕上がりや納期、初回150名分のデータ入稿に適しているかなど 紙選び 手触り重視！そしてロゴの発色が綺麗に表現できるかを見極めるのが難しい・・・ 個性の表現 特殊な印刷方法を採用するなど、BASEらしさの表現 運用方法 非デザイナーでも情報を修正したり追加したりできるような、誰が運用しても一定のクオリティを維持できる運用方法 など、様々な過程がありましたが。記事の中ではいくつかピックアップしつつお話します！ 名刺データ運用の懸念と解決策 懸念 デザインだけでなく名刺データを運用していく際の懸念もありました。 BASEの名刺はAiデータでテンプレート化されており、新入社員分の発注や既存の名刺の肩書き変更を行う際にもデザイナーデータを変更することがなく（とてもありがたいことに）HRのメンバーが情報を流し込み、入稿してくれています。 ですが、ここ数年で部署名が変更されたり、肩書きなども細分化されていったことでリニューアル前のテンプレートデザインでは既存の運用が担保できなくなっている箇所がいくつかあったりと、改善が必要でした。 また、SNSアカウントの数や種類にルールがなく、人によって情報がマチマチなので運用が大変、なのでSNSは廃止しよう！！とメモを公開したところ、、 このようにエンジニアさんから強い要望があったのでこちらも残しつつルールを設けてスッキリさせることにしました！ 解決策 という経緯を元に、今回テンプレートを、 テンプレート兼入稿データ にすることに。 【必須】部署名や肩書き（１行or２行）、名前 【任意】電話番号、メールアドレス、SNSアカウント（Facebook,Twitter,GitHub,Instagram） で構成し、電話番号、メールアドレス、SNSそれぞれ任意であり、SNSを載せる場合には一つだけ選ぶというルールを設けました。 また、人によって情報が１つだったり３つだったり、SNSの指定もそれぞれですが、 １つだったテンプレートを - 肩書き１行 - 肩書き２行 の２つに増やしました。 そして項目Maxの３つを電話番号から順にテキストで用意し、不要なものは消す、という少しアナログな形式ではありますが非デザイナーでも扱いやすいテンプレートにしました。 また、インプット、削除をしやすいよう、すべてをテキスト情報に変換するため、電話番号やSNSアカウントなどのアイコンは FontAwesome でテキストとして出力しています。 （さわる必要のないロゴや会社情報はズレてしまうと困るのでレイヤーでロックしています） 試作に試作を重ね完成！！ 色味や角丸の綺麗さを見るため小ロットでいくつかの業者にお願いし試作を繰り返し、 その中でもっとも紙の手触りがよく、しっかり色が出た業者さんを選びました！それがこちらです！ (諸事情により独特な配置となっておりますがご愛嬌) ５色展開 BASEのロゴであるマルチカラーから選べる５色でメンバーの個性を表現 紙質 しっとりと手に馴染み思わず撫でたくなるようなラミネート加工 デザイン 横向きでトレンドかつBASEのニュートラルな印象を表現 日英対応 表は日本語表記、裏面（カラー）は英語表記 最後に ざっくりとした流れではありますが以上がリニューアル内容です。 5月下旬から始動して手元に届いたのが8月中旬だったので時間にして2ヶ月半弱かかりましたが、発色も良く可愛くできているし、何より一番懸念していた運用も、人事からは「テンプレ分かりやすい！」とのリアクションをもらい、今のところ問題なくまわっていそうなのでやってよかったー！！！と達成感に溢れております！ BASEのメンバーと名刺交換のお相手の間に今まで以上に素敵なコミュニケーションが生まれますように！

こんにちは、はじめまして、お久しぶりです！ BASE BANK株式会社 にてソフトウェアエンジニアをしている東口（ @hgsgtk ）です。2019年11月7日（木）〜11月10日（日）にCakePHPの国際カンファレンス CakeFest 2019 が、日本で開催されました。私は、スピーカーとして参加したのですが、初めて30分強、国際カンファレンスで話す機会となったので、発表のために準備したことや反省点も踏まえて、参加レポートをお届けします。 CakeFest 2019 CakeFest 2019 とは、PHP製ウェブフレームワークの一つである CakePHP の国際カンファレンスです。年に1回開催されており、今回は初めて日本での開催となりました。 cakefest.org CakeFest 2019は、Workshop dayが2日、Conference dayが2日の合計4日間でした。WorkshopはDMM.comさんのオフィスが会場で、Conference dayはSmartNewsさんのオフィスが会場になりました。 私は、Conference dayからCakeFest 2019に参加しました。 ノベルティが豪華で、CakeFestの ElePHPant （緑色の象）と、CakePHPのノートなどをもらえました。 また、私はスピーカー参加だったのですが、スピーカーは、あまり世に出回っていないと噂のCakeDCのElePHPant（青色の象）も貰えました！ また、ネックストラップ・名札もおしゃれです。今回、BASEは、シルバースポンサー・ランヤードスポンサーとして協賛していたので、ネックストラップには BASE のサービスロゴを入れていただいています。CakePHPのFounderの Larry Masters さんなど、普段お世話になっているOSSのコアメンバーの方が、自社のロゴの入ったネックストラップをつけている光景は大変感慨深い光景でした。 basebook.binc.jp また、今回、参加したBASEのエンジニア4名で、 Larry Masters さんと記念撮影していただきました！ 最終日には、CakePHPのケーキが参加者全員に振る舞われました。 Presentation Kazuki Higashiguchi is speaking now about how to avoid the pain of test code. #CakeFest2019 #cakePHP #japan pic.twitter.com/Umo9unL7gg — CakePHP (@cakephp) November 9, 2019 私は、Conference day初日の11月9日の夕方に35分ほど、 Test-Driven Development to avoid test painful という話をしました。 「テストがつらい」という状況に対して、TDD（Test-Driven Development）がどのように使えるのかを説明する内容です。TDD自体の説明には、現在beta4がリリースされている CakePHP4.0 のサンプルコードを用いて、ライブコーディングを行いました。 資料 資料には、ライブコーディングでその場で話した部分も入れています。TDDのアプローチを行うことで、テストからコード設計に対するフィードバックを受けることができます。設計道具としてテストを使える点が伝われば幸いです。 ライブコーディング中に使用したサンプルコードは、GitHubの下記のレポジトリに公開しています。基礎となる内容は、CakePHPのチュートリアルとなっている Content Management Tutorial で、これにデモするための機能を追加したコードになっています。 github.com CakePHPは、開発中最新の 4.x-dev のbranchを利用しました。もともとは、バージョン3.5を利用していたコードだったので、4.0へのバージョンアップもこの発表機会を機に実施しました。バージョンアップしてみて気がついた点などは、別途12月の CakePHP Advent Calendar 2019 でブログを書きます。 発表後の反応 発表後、「良かった」というフィードバックをいただくことができました。また、Twitterをエゴサすると、「ライブコーディングが参考になった」・「TDDやっていくぞ」といった反応があったので、何かしら参考になってポジティブな影響を与えられたような発表になった気がします、、、！ ライブコーディング、すごく参考になった #cakefest2019 — morgan (@idubmorgan) November 9, 2019 Your speech had a positive impact on me!! Thank! — 神谷 暉士 / Gunji Kamiya (@GunjiKamiya) November 10, 2019 うちの会社でもドンドン、TDD実践していきたい！ #CakeFest2019 — カンボ🏝沖縄@Webエンジニア (@kanbo0605) November 9, 2019 準備 CakeFest 2019は、初めて英語で30分強話す機会でした。「カンファレンスで英語でトークしたい」と思っている方は潜在的に多いと思うので、今回どのように準備したか紹介したいと思います。 社内でエンジニア英語勉強会を開催した とにもかくにも、先人たちのカンファレンスでのトークを見て、英語でのフレーズとか雰囲気に慣れていきたいところがあったので、継続的かつ定期的に学ぶために、社内でエンジニア英語勉強会を始めました。6月から半年間毎週、TEDのトークやテックカンファレンスのトークを聞きました。 半年継続したおかげで、6月当初は「ほとんどわからん...!」となっていた状態だったのが、「なんとなくこういうこと言ってるよな」と分かるようになっていきました。 また、いろいろなスピーチを見つつ、スピード感・スライドの量や構成・話のはじめ方などを考えることができました。 英語の原著を参照した 普段、翻訳された日本語があれば、それを読んでいるのですが、英語で人に伝えるとなると、どのように専門用語が表現されているかを知る必要があります。そのニーズに、原著は最適でした。実際に、今回のカンファレンストークをきっかけにいろいろな書籍を購入して読んで参考にしました。自分の例では、「 Growing Object-Oriented Software, Guided by Tests 」や「 xUnit Test Patterns: Refactoring Test Code 」、「 Practical Object-Oriented Design: An Agile Primer Using Ruby 」などを参考にして、実際に発表資料内でも引用させていただきました。 逐次通訳を想定した原稿 今回のCakeFest 2019では、逐次通訳があったので、自分の話を通訳の方が日本語に翻訳していく時間があります。これは本当に初めての経験だったので、自分の発表が何分で終わるのか全く読めませんでした。結果経験してみて、逐次通訳があるとそれを前提にした話し方が必要だと感じました。 具体的には、自分で喋れる時間と量が、単純計算で半分になるので、短く簡潔にワンセンテンスで伝える必要があります。今回のトークでは、スライドに書かれた文章とは別に、スライドごとに一文で説明する原稿を用意していました。 ライブコーディング用のメモ ライブコーディングが一番頭を使いました。英語を考えつつ目の前のPHPコードを書いていくことになるので、相当パニック状態で進めることになります。 最悪困って脳が停止したときの拠り所として、コードと話す言葉を用意しておくといいです。実際に使ったのは、ちょっと長いコードのコピペにつかったくらいですが、問題発生時の準備は多いに越したことはありません。 事前練習・添削 社内発表練習を計2回行いました。実際に母国語ではない言語で話すとそれだけで普段の倍くらい時間がかかりました。泣く泣く話を削っていきながら、ちゃんと参加者の方々の期待感に応えられそうな内容を増やしていく作業となりました。また、実際に話すことで詰まってしまったり違和感を感じる表現が出てくるので、それらを原著や海外スピーカーの話を参考に修正していきました。 さらに以前、 GopherCon 2019 でLightning Talkをした際に、練習に付き合っていただいた、英語が得意な方に個人的にお願いしてスライドの英語表現を添削いただきました。 練習や添削に付き合っていただいた方々には、この場を借りて改めてお礼申し上げます、ありがとうございました！ ふっと話す用の英語用意 スライド外で喋りがちな英文を120%の準備としてあるとよいです。今回、たまたま用意していた一文が、 I'm sorry to keep you waiting （待たせてごめんね）だったんですが、後に書くのですが本当に機材トラブルで遅れて参加者の方を待たせることになるので用意しておいてよかったです。 その他にも、時間がなくてスライドをカットしないといけない時のセリフとか、例外系発生時のフレーズを用意しておくと安心できると思います。 反省・改善点 また、反省点や他の方の発表を見て気づいた改善点もあったのでまとめてみます。 手元で原稿見る用の機材準備 今回、私はライブコーディングがあったので座りっぱなしで話していたのですが、PCから離れて立って話す方がベターではあります。理想を言えば、全部暗記しているか暗記しなくても心の中から英語が出てくるのがいいのですが、なかなかそうもいきません。 同じくスピーカーだった @t_motooka さんの発表では、PCをスクリーンにつないで、スライド操作をiPadで行っていました。それであれば、立って話せるしスライドごとの原稿も見れていいなと思いました。次回は、その手法でやります。 残り時間を見失った（凡ミス） 機材トラブルで当初の時間から遅れて始まったこともあって、内心めっちゃ焦っていました。普段、 logicool にタイマーを設定しつつ、バックアップでスマホのタイマーを使って自分の持ち時間の残りを確認しています。今回非常に凡ミスをして、ライブコーディングでスライドから離れたタイミングでlogicoolのタイマーがリセットされ、さらにスマホのタイマーも動かすことも忘れていました、、、。 時間が押している上で何時までに終わればいいのか見失ってしまい、喋りながら「今何分経っているんだ」とソワソワし続ける羽目になってしまいました。これに関しては、気をつけようくらいしか教訓は無いかもしれませんね・・・。 結果、30分弱だったので最適解だったなと思いつつ、「これ話しておきたいな」と思った部分をいくつかカットしたのが心残りでした。 また、これは余談ですが、 MacBook Air が機材と相性悪くて映らないパターンが、今年24回発表していて3回確認されています。機材相性が悪いことは他のPCでもあると思うので、AirPlayでもできるように準備するなど対策をしておくといいでしょう。 Speakers 最後にケーキと一緒にスピーカーとコアスタッフのみなさんで写真を取りました。 また、CakeFest 2019参加者でカンファレンスバナーにサインしました。 ここにも、BASEのサービスロゴを大きく入れていただいていたので、BASEの近くにサインしました！ 最後に CakeFest 2019では、普段のカンファレンスではなかなか機会が少ない、CakePHP自体のノウハウやそれを題材にしたトークをがっつり聞けました。また、普段GitHubやSlack上でやり取りをさせていただいていた、CakePHPのリードエンジニアである @mark_story さんや、日本人コアコミッターの @chinpei215 さんなどと直接話せたり、とても楽しい時間を過ごさせていただきました。 このような楽しい時間を用意していただいた、CakeFest 2019の運営メンバーの方々に感謝いたします。また、参加するチャンスが有れば、次回のCakeFestにも参加したいと思います。 Thank you for holding CakeFest 2019 in Japan!

こんにちは！BASE株式会社の藤川（えふしん）です。 2019年10月31日開催された EOF2019 (Engineering Organization Festival 2019) というエンジニアのチームマネジメントに携わる人達のイベントに、スポンサーとして参加すると共に登壇してまいりました。 こちらが当日の発表資料になります。 2019/10/31 BASE社発表資料 - EOF2019 from 真一 藤川 プレゼンテーションの目的としては、エンジニアのマネジメント業務はクリエイティブな仕事であり、エンジニアリングの延長線上でしかないんだよ！ということを知って欲しい。その結果として、エンジニアリングマネージャに挑戦する人を増やしたいというものです。 なお、BASE株式会社に僕がCTOとしてジョインした時には、すでにエンジニアが何人かいる状態でした。一応、BASE創業直後から技術顧問として週一あらわれるおじさんとしてBASE社には通っていましたが、ちゃんと会社の中に入ってみると、それまで全然見えていなかったものがたくさん見えるようになり、当時は高速道路の合流車線を全力で走るような感じでどうにかCTOとして活動開始した記憶があります。 その頃の組織課題から、徐々に開発者が増えていって、今の段階にまでなる時の話をさせていただきました。おそらく同じようなフェーズから今後成長していくスタートアップのCTOやEMの人たちが少しでも参考になればと思っての情報共有です。当然、個々の事情はケースバイケースでしかありませんが、何かの参考になれば幸いです。 なお、あくまでもマネージャに興味ある人向けのプレゼンテーションなので、その役割については少し煽るような表現も入っています。マネジメント業務に興味がない方などで不快に思われる方がいらっしゃったら先んじて謝罪しておきます。 なお、当時のBASEの状況は、調べるおさんも記事にしてくれていて、当時のメンバーを知っている僕はつい泣いてしまう記事だったのでこちらもよろしかったら是非。 mochi.click

こんにちは！この度は10/12(土)に沖縄で開催された PHPカンファレンス沖縄2019 にBASEが協賛＆3名が登壇いたしました！今回はめもりー( @m3m0r7 )、川島（ @nazonohito51 ）、東口（ @hgsgtk ）の3名から参加レポートをお届けします！ イベント概要 PHPカンファレンス沖縄 は カンボ様 ( @kanbo0605 ) が実行委員長を務められ、沖縄で開催されるPHPカンファレンスとしては、今年初でした！10/12に PHPカンファレンス沖縄 が開催されたのですが、それに加えて前日（10/11）に開催された (非公式)PHPカンファレンス沖縄2019前夜祭リジェクトコン にも参加したので両方レポートいたします。 (非公式)前夜祭 10/11に (非公式)PHPカンファレンス沖縄2019前夜祭リジェクトコン が開催されました。前日から参加できるPHPerたちで、ゆるい雰囲気でお酒を飲みながらトークを聞いたり懇親したりする会でした。 会場は、那覇市内の 株式会社サイダス さんのオフィスでした。非常におしゃれで過ごしやすい会場でした。 前夜祭会場の株式会社サイダスさん 本編 10/12はいよいよ PHPカンファレンス沖縄2019 当日！会場は、宜野湾市に構える CODE BASE OKINAWA という会場でした。 PHPカンファレンス沖縄2019 入り口 海が近くてちょっと会場の裏に行けばすぐに海が見え、PHPだけでなく沖縄を感じられとても良きでした！ 会場裏をチョット歩くと見える宜野湾の海 BASEは、シルバースポンサーとして協賛していたので、オープニングでは会社紹介いただきました。 オープニング (非公式)前夜祭、本編にてめもりー( @m3m0r7 )、川島（ @nazonohito51 ）、東口（ @hgsgtk ）の3名が全員で合計7回登壇いたしました。以下登壇者各位による紹介になります！ 登壇内容&スライド めもりー( @m3m0r7 )、川島（ @nazonohito51 ）、東口（ @hgsgtk ）の3名の発表内容をお伝えします！ めもりー 沖縄では、前夜祭・本編・懇親会 LT をあわせて 3 回登壇させていただきました。 前夜祭 前夜祭は PHP で バイナリファイルを読む -JVM の ClassFile Structure を読んでみる - (English Title: How to read a binary file - Read the ClassFile Structure of JVM - )という内容で登壇 & ライブコーディングをさせていただきました。予めどういったことをするのかをスライドで作っていたのですが、ほとんどがライブコーディングだったため、資料はアップロードしていません。今回の PHP カンファレンス沖縄では台湾の方が多くいらっしゃっていることを前夜祭で知り、急いでその場で英語版の資料をつくっていまいた。そして、前夜祭でピザを食べながら、ORION を飲みつつ Drunk Driven Development で日本語と英語のスライドを交互に予め説明させていただき、ライブコーディングを 15 分程度行いました。ライブコーディングの発想は @DQNEO さんのインスパイアです。15分という限られた時間でしたので、次ライブコーディングをするときはもう少し長めの時間でやりたいなと思いました。 前夜祭での登壇様子 英語にあまり自信がなかったのですが、雰囲気で伝わっているようで良かったです。 本編 PHPer のための PHPUnit と Selenium を使ったブラウザテストのすゝめ というタイトルで発表させていただきました。こちらは PHP カンファレンス北海道にて登壇した内容と同じタイトルですが、発表の仕方を変えたり、 Twitter のフォロワーさんから「リンク切れをどう検知するのか知りたい」といった要望がありましたので、一部スライドを増やしてデモンストレーションも追加しています。 また、一参加者として Swoole のコアコミッターの Albert Chen さんの How Swoole Blows Your Mind about PHP? を拝聴し、さらに懇親会のときにお話をさせていただけてすごく有意義な時間を過ごせました。 ハムスター監視システムに Swoole を使用させていただいているので、Swoole のライフサイクルなどがとても学びになりました。 懇親会 LT 懇親会 LT があるという噂を聞いていて、何を話そうか悩んでいたんですが、周りからキーボードの話が聞こえてきて「今まで使ってきたキーボードの話してみようかな」と考えたのですが、いろんな記事になっている話題ではあり、二番煎じだしどうしようということで少し迷っていました。 そして、思いついたネタが「今までに壊したキーボードとマシンたち」で、さっそく資料をつくり壊したキーボードの思い出に浸りながら懇親会 LT で登壇させていただきました。 川島 PHPカンファレンス北海道と同じくスポンサーセッションという形で登壇させていただきました。私にしては珍しく勉強会設計の話をさせていただきましたがとても反響があり驚いています。勉強会を通じてどう成長するのか、 エンジニアの知的生産術 から学習パターンを引用しながら一般化して話させていただきました。 東口 @hgsgtk 沖縄では、非公式前夜祭・本編・懇親会の3回発表してきました デザインパターンを出自から深く理解する at 非公式前夜祭 非公式前夜祭で15分お時間を頂いて話しました。GoF（Gang of Four）のデザインパターンは、建築家クリストファー・アレグザンダーの「パタン・ランゲージ」に影響を受けたアイデアです。普段、デザインパターンを自然と口にしている私達ですが、改めてその出自からデザインパターンを見ると、その目的・課題感が見えてくるのではと考えています。今回の発表はその考えを言語化してみました。 発表後、 akki_megane さんと、発表内容に関連するクリストファー・アレグザンダーの建築理論についての書籍感想戦ができたり、 @koyhoge さんにパタン・ランゲージに関連する参考情報をいただけたり、発表したことでさらに理解が深まっていい時間になりました。 「割れ窓」を増やさないためのコード設計 at 本編 本編でのLightning Talk中の様子 本編でLTの一枠を頂いて話しました。普段、業務での開発をしていて、「元のコードが厳しいがそれを改善する時間がない、しかし機能追加のマイルストーンは迫っている」という状況下で生まれたPull Requestに対して、さっと「マシな選択肢」の資料が出せるようにしたいと思い、この資料を作成しました。 懇親会にて「参考になった」と感想を頂いたり、資料公開後、約4100View・約190はてぶ（2019年10月15日時点）いただき、多くの方にご覧いただく結果になりました。 PHPにおける独自例外設計を考える at 懇親会 当日の懇親会LTがあったので話しました。例外設計において、どのように独自例外クラスを作るかについては、エラーハンドリングについての考え方やその背後にある品質についての考え方が背景にあると思います。今回は、独自例外の特に基底クラスをどうPHPにおいて実現するかを、Symfonyの内部実装などを参考にしながら考えたものを資料にしました。 といっても、懇親会なので賑やかし要素も欲しいよなということで、台湾から来ている方々もいたので、全編英語で話すチャレンジをしました。ある程度会場の盛り上がりに貢献できたような気がするので良かったです。 おわりに PHPカンファレンス沖縄2019 の実行委員長のカンボ様（ @kanbo0605 ）をはじめ、実行委員会の皆様、また弊社エンジニアのセッションをご清聴してくださった皆様に心より御礼申し上げます。PHPコミュニティに対して協賛や登壇という形で微力ながら貢献できたこと光栄に思います。次回の開催を心より楽しみにしております。誠にありがとうございました！

2019/10/12 (土) に開催される PHP カンファレンス沖縄 2019 に BASE に所属する 3 名のエンジニアが登壇します。 BASE はこれまでにも開催されている PHP カンファレンスへの登壇並びにスポンサードをコミュニティ貢献活動として行って参りました。 PHP カンファレンス沖縄は初開催とのことで、弊社エンジニアも楽しみにしております。 セッションの内容について めもりー ( @m3m0r7 ) レギュラーセッション: 30分 所属: Product Dev Division 基盤開発 PHPer のための PHPUnit と Selenium を使ったブラウザテストのすゝめ みなさんはブラウザテストをする際に、どのようにテストされていますでしょうか？ ブラウザテストをする際に有名なソフトウェアとして Selenium があります。 また、 PHP では Selenium と繋ぐための OSS として Facebook WebDriver があります。 Selenium を使うことにより、リンク切れが発生していないかの確認をしたり、動的に生成される DOM の検証を行ったり、 フォームに自動で値を入れたりなど様々な用途でテストを行うことができます。 さらに、 Selenium は JavaScript をその場で実行できたり、 Chrome, Firefox, IE などブラウザごとのテストを行うことも可能です。 そして、実際に私が以前勤めていた会社や複業先に導入した経験をもとに Selenium と Facebook WebDriver と PHPUnit を使ったテストの方法や、 導入するにあたってどのような苦労があったのかをトークできたらと思います。 東口 和暉 ( @hgsgtk ) LT: 5 分 所属: BASE BANK, Inc. Dev Division Tech Lead 「割れ窓」を増やさないためのコード設計 長く続くシステムを運用していくと、テストが書かれていないコードや何百行・何千行に渡るメソッドが存在するコードが随所に存在するシステムに対して運用・改修をしていく必要が出てくることがあります。 それらに対して、根本治療的に構造を改善するなどが必要とわかりつつも、工数感・改善するための技量の問題などで、既存のコードベースと同様のやり方を踏襲してしまってさらに状況を悪化させてしまうという経験をしたことのある方は多いのではないでしょうか。このトークでは、レガシーコード改善の手法を一部を活用して、いかに「次の改善につなげる余地を残した状況」に保つかを話します。具体的には、「スプラウトメソッド」・「非推奨機能の回避・明示」・「仕様化テスト」などが挙げられます。このトークを通じて、「今のコードに引きずられずに思考して自分の仕事をコードに反映するか」という考え方について伝えらればとおもっています。 川島 慧 ( @nazonohito51 ) スポンサーセッション: 10分 所属: Product Dev Division 基盤開発 社内勉強会でOOPとCleanArchitectureとDDDを勉強し始めたというお話 BASEでは一部の有志でOOPとCleanArchitectureとDDDの勉強をしています。最近流行りのワードを全部詰め込みまくったボリューム満点な勉強会ではありますが「理論と実践をつなげる」という目的を掲げて、読書よりも実践とディスカッションを重視しながら前向きに取り組んでいます。Robert C. Martinの書籍で扱われていた給与システムの例を題材に、ドメインモデリング、CleanArchitecture上での実装、OOPデザインパターンの適用などをモブプログラミングを通して実践しています。まだ開催して間もないため、なかなか結果をお話することは難しいのですが、実践を通して得た感想や参加者の変化などを取り上げて、みなさんの持ち帰れる知識に変換して発表したいと思います。 最後に PHP カンファレンス沖縄 2019 の当日のチケットは下記よりお申し込みいただけます。 PHPカンファレンス沖縄2019 PHPカンファレンス沖縄2019 懇親会 それでは、みなさまにお会いできることを楽しみにしております。

おつかれさまです。UIデザイナーの野村（ @nomjic ）です。 先日お書きした Figmaのプラグイン紹介記事 でも少し述べましたが、UIデザインツールである Figma はノンデザイナーが作図や資料作りを行うにあたっても有用です。 もっとユーザが増えたら好ましい... と日頃から思っていたら、社内でノンデザイナー向けにFigma講習会を行う機会を得ましたので、その経緯や講習会の内容、所感などを書かせていただく次第です。 講習会を企画するに至る背景 ノンデザイナーが作図するの、つらそう 弊社では、ノンデザイナーの人（プロダクトマネジメントやエンジニアリングのメンバー）がちょっとした作図をしたり、UIのワイヤフレームを作る時には、Google Slidesを使用する場合が多いです。 普段デザインツールを使用している身からすると、スライド資料作成ツールを使って絵図を描くなんて 「あの人たちは何という苦役に耐えているのか...」 と思ってしまうのですが、一方でAdobeのツールやSketchが多機能すぎてハードル高い、というのも理解できます。お値段も張りますしね。 Figmaが良いのでは 図作りに大変な労力を割いていることを見かねた弊社デザイナーが、「Figmaは比較的簡単に使えるし、勧めてみようか」と考えてノンデザイナー向けのFigmaチュートリアルを作成してくれました。（チュートリアルは本記事の後半に掲載します。） そして、「講習会をしたいのだが手伝ってもらえまいか」と私にご依頼いただき、「ハイ！やります！Figma万歳！」と承った次第です。 なぜ Figma ? デザインツールが数多ある中でなぜFigmaを選んだかと言うと、理由は以下の通りです。 操作方法が（比較的）シンプル ブラウザ上で操作可能なので、OSを問わない 情報をシェアしたりコメントつけたりするのが楽 操作概念がGoogle Slidesに近い ※ 注記：Figmaのバグ Figmaをお勧めするにあたって触れざるを得ないバグが一件あります。 全角文字を入力した直後に半角入力モードに切り替えて文字を入力すると、切り替える直前に入力していた全角文字が消えます。 詳しくは こちらのnote記事 などご参照ください。 このバグさえ無ければなんの抵抗もなくFigmaお勧めできるのですが...。 Figma講習会実施 概要 時間：60分 内容：Figmaの運用ルールと基本操作の説明 & ハンズオン 講習対象：プロダクトマネジメントのメンバー（エンジニアも参加OK） 目的：①基本操作の理解 ②楽しむ 講習内容 以下のような流れで講習会を実施しました。 1. Figmaの概要紹介（5分） 講習会の導入部です。 FigmaがUIデザイン以外にも様々な用途で使えること、コラボ作業がしやすいというメリットがあること... 等を3分程度で説明しました。 2. Figmaの運用ルール説明（5分） Figmaはデータのシェアが非常に容易であるゆえに、うっかり機密情報を漏らしてしまう危険もあります。そのあたりの点を踏まえて、ライセンス管理やデータシェアに関するルールの説明を行いました。 3. 基本操作の説明（チュートリアルをなぞる）（20分） 事前に作成したチュートリアルをなぞる形でハンズオンして、基本操作を理解します。 （このチュートリアルは本記事の後半に掲載しますので、ノンデザイナーの人がFigmaの使用方法を学びたい時の参考にしていただけたら幸いです。） 4. componentの概念紹介（5分） Figmaにおけるcomponentの概念と扱いについて、簡単にですが説明します。 1つ作れば複数箇所で使いまわせる便利なやつです。 オブジェクト志向言語で言う所のClassとInstanceみたいなやつで、継承関係持ってます。 という程度のざっくりした説明をしました。 5. 課題を与えて各々トライ（25分） 最後に、「画面遷移図を作ってみよう」という課題を与えて、残りの時間でトライしてもらいます。トライする過程で質問したいことあったら随時デザイナーに聞いてもらいます。 予め用意した1つのファイル上で一斉に作業をしてもらいました。 他のUIデザインツールにはできない、Figmaならでは使い方を試してもらいたく、この形をとりました。 ここでは、使い方を覚えてもらうことよりも楽しんでもらうことを旨としました。楽しい方が記憶に定着しやすく、結果として楽手効率も高いだろうと見込んでのことです。 案の定、与えたお題を無視して自由に図（というか、シュールなアート）を画面上に展開する御仁が複数名いらっしゃいましたが、それはそれでOKです。「作りたいと思ったものをどう作るか」を各々がトライして不明点あったら質問する、という場を用意できたので、講習会を催した側としては目的を達しました。 成果 ひとまず、「①基本操作の理解 ②楽しむ」という目的は達しました。 これが業務に役立ったかについては、講習会の1週間後である現時点ではまだわかりません。 実業務に対してどんな影響があったかは、いずれまたご報告したいと思います。 [付録] 講習会のために作ったチュートリアル 以下、講習会で使用したチュートリアルを転載します。（一部省略） STEP1：ファイルの新規作成 初期画面のヘッダーの ＋ かページ内の ＋ New File をクリックするとファイルを新規作成できます。 STEP2：Frameの作成 Frameはこれから絵を書く為の用紙だと思ってください。（Sketchでいうところのアートボードです） このFrameは作らなくても作業できますが、机に直接絵や文字を書いてる状態です。 資料やワイヤーを作成するレベルだと見やすければFrameはなくても大丈夫ですが、pdf書き出しや印刷する場合はFrameを作っておいた方が良いと思います。 ツールバーから 井 みたいなアイコンのツールを選びます。 このツールを選ぶと右側のパネルにどのサイズでFrameを作成するか選択肢が出てきます。 主要なデバイスサイズが選択肢に出てくるので、好きなサイズを選択してください。 サイズを選んでクリックすると画面上にFrameが作成されます。 作成したFrameは選択状態だと四隅に小さい四角が出るので自由にサイズを変更したりD&Dで移動ができます。 細かくサイズを設定したい場合は右側のパネルにWやHを数値入力できるところがあるので、そちらで設定してください。 STEP3：テキスト入力 ツールバーの T みたいなアイコン？のツールを選択します。 ツールを選択したらFrame上の好きな位置（Frame外でも大丈夫です）をクリックしてテキストを入力します。 テキストのサイズや色などを変更したい場合は右側のパネルで変更します。 テキスト入力状態だと選択部分しかスタイルが適用されないので、テキスト全体にスタイルを適用したい場合は、一度テキストの入力の状態を終了しして、（ツールが みたいな（向き逆）アイコンのツールになっているのを確認して）もう一度テキストを選択してからスタイルの変更をしてみてください。 STEP4：図形の描画 四角や矢印を描きたい時はツールバーの □ の選択します。 □ の横の をクリックするといくつか選択肢が出てくるので好きな図形を選択してください。 描きたい図形を選択した状態でFrame上の好きな位置（Frame外もOK）にD&Dで好きなサイズの図形を描くことができます。 文字と同じように、配置した図形は右側のパネルでスタイル（塗り色や縁取り、角丸などなど...）を変更したりサイズを調整することができます。 STEP5：矢印の描画 四角や丸などの図形と同様に矢印も描くことができます。 矢印の場合はD&Dで配置した後にダブルクリックをすることで、矢印を曲げたりすることができます。 矢印をダブルクリックして、矢印の上にカーソルを乗せると両端と真ん中に○が出てくるので、真ん中の○をつまんで好きな位置に移動すれば矢印を曲げることができます。 矢印を複数の場所で曲げたい場合は、矢印線上の○と○の間にカーソルを移動すると、薄い○が出てくるので、その○をクリックすると曲げる為のポイントを増やすことができます。 矢印の編集を終了する場合は、ツールバーにある Done ボタンをクリックして終了してください。 STEP6：画像の挿入 画像を挿入する場合は、図形の描画同様に □ アイコンの横の をクリックして Place Image を選択します。 ツールを選択すると画像選択が出てくるので、挿入したい画像を選択します。 画像を選択したら、画面上にクリックで配置をするか、D&Dでサイズを指定して配置してください。 画像のトリミング 挿入した画像をFigma上でトリミングすることができます。 トリミングしたい画像を選択してヘッダーの真ん中あたりにある みたなアイコンの Crop Image を選択します。（または画像をダブルクリック） Crop Image をクリックすると画像編集用のパネルが表示され、画像側にトリムエリアが表示されます。 このトリムエリアをD&Dして好きなサイズにトリミングします。 トリミング後に画像部分をD&Dするとトリムエリア内で画像の位置を変更することもできます。 （補足：画像編集パネルのスライダーは画像のレタッチ用です） 画像の編集を終了する場合は、画像編集用パネルの をクリックするか、何もないところをダブルクリックすると編集を終了できます。 STEP7：コメントをつける Figma上で資料やワイヤーにコメントをつける場合は みたいなアイコンの Add/Show Comments を選択します。 ツールを切り替えたらコメントをつけたい場所でクリックするとコメントが入力できるフィールドが出てきます。 コメントを入力したら Post ボタンをクリックしてコメントを投稿してください。 コメントを投稿すると右側のパネルにコメントのリストが表示されます。 コメントには返信することができるので、修正指示や要望などをFigma上でやりとりができます。 これにて基本機能の紹介は終わりです。お疲れ様でした！

こんにちは！この度は9/21(土)に北海道の札幌で開催された PHPカンファレンス北海道 にBASEが協賛＆3名が登壇いたしました！今回はめもりー( @m3m0r7 )、東口（ @hgsgtk ）、川島（ @nazonohito51 ）の3名から参加レポートをお届けします！ 会場 札幌市民交流プラザ というでっっっっかい！！！ 会場をカンファレンス会場として開催されました。圧倒的開放感のある建物で、贅沢に空間を使ってます。いやー・・・さすが北海道。 弊社はゴールドプランにてスポンサーシップさせていただいているので、スポンサーブースを設営させていただきました。BASEで買えるショップオーナーさんの商品を来場者の方にお配りして、BASEというサービスを皆さんに知ってもらいました。会場で配られるコーヒーと一緒にお楽しみいただけたみたいです。 またスポンサーブースとは別に、弊社から3名が登壇しました！以下登壇者各位による紹介となります。 登壇内容・スライド by @memory Hello World, everyone! めもりー( @m3m0r7 )です。 BASE 株式会社の基盤チームでソフトウェアエンジニアをしています。 PHP カンファレンス北海道では、本編のレギュラーセッション、アンカンファレンス、懇親会 LT の 3 つにて登壇させていただきました。また、アンカンファレンスの枠自体はなかったのですが、 そーだい さんにお時間を 10 分ほどいただき、実現しました。この場を借りて御礼申し上げます。 レギュラーセッション 前日にホテルで最終確認としてデモンストレーションの確認をして問題ないと判断をし、当日を迎えたのですが、本番で見事に docker コンテナが起動できない問題で、デモンストレーションが失敗になりそうでした。 本音を言うと、頭の中が真っ白になってしまったんですが、会場の温かい声援や、失敗させたくないという気持ちが実を結んだのか、最終的にはデモンストレーションが動き、会場から大きな拍手をいただきました。 DEMO 動かなくなって泣きそうだった — めもりー🐱 (@m3m0r7) September 21, 2019 docker コンテナを直している間にフォローしてくださったスタッフのみなさま、オーディエンスのみなさま、本当にありがとうございました。 みなさまがいらっしゃらなければ、デモンストレーションは失敗に終わっていたことだと思います。 感謝してもしきれません。本当にありがとうございました。 ホテルへ戻った際に確認をした際、原因は docker のコンテナ名がかぶっているとのエラーなので ERROR: for php Cannot create container for service php: Conflict. The container name "/php" is already in use by container "6d11f8998f7f16f7715b2b2e7bf72c2cbf1d379afb84b18a8400a347c8dbcbd7". You have to remove (or rename) that container to be able to reuse that name. ERROR: Encountered errors while bringing up the project. エラー文にも書いているように下記のように docker rm をすれば、動きました。 docker rm 6d11f8998f7f16f7715b2b2e7bf72c2cbf1d379afb84b18a8400a347c8dbcbd7 当日は、コンテナ名を変えるという対策をとって無事デモンストレーションできました。 アンカンファレンス アンカンファレンスでは 「PHP で JVM を実装する」といった内容で発表させていただきました。いろんなイベントでお話させていただいている内容をギュッと凝縮させて、 PHP で JVM を実装するとは一体どういうことなのかをメインに 10 分でお話させていただうえ、デモンストレーションもさせていただきました。 懇親会 LT 懇親会 LT では 「PHP で Python を動かす」といった内容で発表させていただきました。 スライド資料を見ていただければわかりますが python をコンパイルした際に出力される pyc ファイルを PHP 上でエミュレーションしようといった内容です。 こちらの時間は 5 分だったので、ギュッと凝縮させていただいて、デモンストレーションもさせていただきました。 CakePHP2でもPhpStormがコード補完してくれるようにした話 by @nazonohito51 BASE株式会社でエンジニアをやっております川島（ @nazonohito51 ）です。 スポンサーセッション枠として10分の発表をさせていただきました。（実はBASEがスポンサーセッションをするのは今回が初となります） スポンサーセッションということで会社の紹介的な発表をしようかなと思っていましたが、3年ぶりに開催される北海道の大型カンファレンスに勇んで参加される勉強熱心なエンジニアの方々に対して会社の話をするというのも野暮かなと思い、あえてバリバリの技術トークにしました。意外とSNS等の皆さんからの反応がよく、スポンサーセッションとはいえ気負わず技術トークに寄せてしまって良かったなと思います。 自作して理解するxUnit by @hgsgtk どうも、初めまして、こんにちは、東口（ @hgsgtk ）です。BASE BANK株式会社にてソフトウェアエンジニアをしています。私は、次のスライドの内容でLightning Talkをいたしました。 xUnit とは、テスティングフレームワークの総称を表すもので、PHPerであれば息を吸うようにお世話になっている事が多いであろう、 PHPUnit もxUnitファミリーの一つです。このトークでは、そんなxUnitの特徴を自作して理解しようというものです。今回作成したものは、Github上に公開しています。 https://github.com/hgsgtk/mpunit 発表後、早速、聴講いただいていた @itosho さんにPRを頂きました！ https://github.com/hgsgtk/mpunit/pull/6 当日、スピードトークで発表スライド内をまともに読む時間なかったと思いますので、もし「私もxUnit自作するぞ！」と興味を持たれた方がいらっしゃいましたら、ぜひスライドとGithubレポジトリのコード参考にさくっとやってみてください！ おわりに PHP カンファレンス北海道の実行委員長のマキ様（ @makies ）をはじめ、実行委員会の皆様、また弊社エンジニアのセッションをご清聴してくださった皆様に心より御礼申し上げます。次回の開催を心より楽しみにしております。本当にありがとうございました。

どうも、はじめまして、東口（ @hgsgtk ）です。 BASE BANK株式会社 Dev Divisionでソフトウェアエンジニアをしています。この度、9月14日〜9月17日に開催された PyCon JP 2019 に参加し、「 Pythonを使った APIサーバー開発を始める際に 整備したCIとテスト機構 」というタイトルで発表してきました。 PyCon JP 2019とは 9月14日〜9月17日に開催されたPythonエンジニアが一同に集う国内最大級のPythonのカンファレンスです。9月16日・17日の後半2日間でセッションスピーカーによるトークが行われる2日間で、私は16日の16:00から15分間登壇してきました。 pycon.jp 発表した内容 発表した内容は、 Pythonを使った APIサーバー開発を始める際に 整備したCIとテスト機構 というタイトルです。 pycon.jp トークの概要は次のような内容です。 Pythonアプリケーションを開発し始める際のCIでのコード検査とユニットテストの整備について取り上げます。CIについては、スタイルチェックやエラー解析の自動化、ユニットテストについては、実DBを利用するケース等事前の設計・機構等の必要な工夫を紹介します。 発表資料はSpeaker Deckに公開しています。 発表動画はYouTubeにて公開いただいていました。 www.youtube.com もし、私がカンファレンスでスピーカーしているのを見かけたことがある方がいれば、PHP・Go言語のコミュニティで発表してる人というイメージをお持ちかもしれないのですが、 BASE BANK株式会社 で運営している「 YELL BANK （エールバンク）」というサービスの裏側でPythonを利用したAPIも開発しています。その際の開発知見をCI・コード検査・自動テストの3点に絞ってまとめた内容がこの資料になります。 Pythonに限らず、メインで知見のある言語以外を業務で扱う際に、CI・コード検査・自動テストは、たんにコード品質を保証するだけでなく、開発者自身の学習サイクルを促進してくれる役割を果たしてくれていると感じていました。その感覚を言語化することをこの資料では試みました。 ありがたいことに、会場は満員御礼で、別会場での中継会場も使われるなど、多くの方に来ていただきました。 TwitterのTLをエゴサすると、誰かの参考になる内容にはなったようなのでひとまず安堵しました（ほっ）。 qiita.com sayuhanten.hateblo.jp wotsushi.hatenablog.com 早速感想を共有いただいた方々誠にありがとうございます（終わった直後は期待感に応えられたか不安な気持ちが強いので感想を形にしていただけると非常に登壇者は安心するもので...）。 さいごに 個人的にPyCon JPは私がぴよぴよエンジニアをしていた際に、人生で初めて参加したカンファレンス（ PyCon JP 2015 ）でした。当時登壇されている方々に、「いつかあそこで登壇するくらいになれたら良いなぁ」とあこがれて、それが現在、技術カンファレンスで登壇するようになった最初の原体験なるものだったりします。 今回、 PyCon JP 2019 で登壇するお時間をいただけたのは、各種カンファレンスの中でも特にエモい気持ちが募る時間でした。 Python界隈デビューができた #pyconjp — Kazuki Higashiguchi (@hgsgtk) September 16, 2019 複数言語・複数レイヤの技術に触れて総合的な視点を持ちたい私にとって、Pythonという言語は、コードの可読性をいかに上げるか、データ分析の手法を理解・実践する上でこれからも付き合っていきたい技術なので、また来年2020に別の知見を持ってこれるように、日々のサービス開発に精進していきたいと思います。 では、またっ。

BASEでバックエンドエンジニアをしている翠川です。 以前、 @nazonohito51 が 資産価値の高いテストを書くためにFabricateを使い始めました という記事で、 Fabricate というライブラリを導入した話を紹介しました。 今回はサービス開発エンジニア側の視点で、Fabricateというライブラリがプロダクトに導入されるまでの流れと、実際に使ってみての感想をお話しさせていただきます。 出典： https://unsplash.com/photos/gMes5dNykus 導入されるまで まず最初に基盤グループと呼ばれる、言語やフレームワークのアップデートや今後を見据えた技術選定などを行うチームで先行採用され、その中で運用できそうと判断されたところでKibelaで使い方のドキュメント公開、同時に社内ハンズオンが開催されました。 Fabricate導入における一番のネックであろう全モデルのテンプレートもすべて基盤グループ側で用意され、テストデータもできるだけリアルに近いものにするためステージング環境のデータから作成しているなど、時間をかけて新ツール導入へのサポート体制ができあがっていました。 実際にサービスエンジニア側で使ってみた感想 実際に使い始めてみて、以下のようなメリットを感じました。 コードを書く量が減ってテストを書きやすくなった サンプルとして、CakePHP 2.X Cookbook から以下のテストを例に説明します。 https://book.cakephp.org/2.0/ja/development/testing.html#id21 <?php App :: uses ( 'Article' , 'Model' ) ; class ArticleTest extends CakeTestCase { public $ fixtures = [ 'app.article' ] ; public function setUp () { parent :: setUp () ; $ this -> Article = ClassRegistry :: init ( 'Article' ) ; } public function testPublished () { $ result = $ this -> Article -> published ([ 'id' , 'title' ]) ; $ expected = [ [ 'Article' => [ 'id' => 1 , 'title' => 'First Article' ]) , [ 'Article' => [ 'id' => 2 , 'title' => 'Second Article' ]) , [ 'Article' => [ 'id' => 3 , 'title' => 'Third Article' ]) ] ; $ this -> assertEquals ( $ expected , $ result ) ; } } ここで、 testPublished() は公開されている記事一覧を取得する Article->published() のテストになります。 Fixtureを使う場合は以下のようにテストデータを用意します。 <?php ... class ArticleFixture extends CakeTestFixture { public $ records = [ [ 'id' => 1 , 'title' => 'First Article' , 'body' => 'First Article Body' , 'published' => '1' , 'created' => '2007-03-18 10:39:23' , 'updated' => '2007-03-18 10:41:31' ) , [ 'id' => 2 , 'title' => 'Second Article' , 'body' => 'Second Article Body' , 'published' => '1' , 'created' => '2007-03-18 10:41:23' , 'updated' => '2007-03-18 10:43:31' ] , [ 'id' => 3 , 'title' => 'Third Article' , 'body' => 'Third Article Body' , 'published' => '1' , 'created' => '2007-03-18 10:43:23' , 'updated' => '2007-03-18 10:45:31' ] ] ; } 一方、Fabricateを使うとテストデータの用意はこのようになります。 <?php ... Fabricate :: create ( 'Article' , [ 'id' => 1 , 'title' => 'First Article' , 'published' => '1' ]) ; Fabricate :: create ( 'Article' , [ 'id' => 2 , 'title' => 'Second Article' , 'published' => '1' ]) ; Fabricate :: create ( 'Article' , [ 'id' => 3 , 'title' => 'Third Article' , 'published' => '1' ]) ; テストに必要なパラメータのみの指定となりコードを書く量が大幅に減るので、「ちょっと多めにテストを書いておこうかな」という気持ちになれます。 既存テストに影響しないので安心してテストを追加できるようになった これまでは、テストデータを毎回全て用意するのが大変なのでFixtureを使い回すことがありましたが、使い回せないときにFixtureの一部を修正や追加したときに他のテストが失敗して辛いことがありました。 たとえば先ほど例として出した ArticleFixture に、他のテストで必要だからとFixtureを追加したとします。 <?php ... // bodyが空の公開テストデータを追加 [ 'id' => 4 , 'title' => 'Fourth Article' , 'body' => '' , 'published' => '1' , 'created' => '2019-09-12 00:00:00' , 'updated' => '2019-09-12 00:00:00' ] そうすると先ほどの testPublished() は、何も手を加えてないにも関わらずテストが失敗してしまいます。 Fabricateを使うことで、テストデータがテスト内で完結するので他のテストを合わせて修正することが無くなります。 もちろん、Fabricateを使わずともテスト内でテストデータを用意することは可能です。しかしその場合は、スキーマに変更が入ったときに各テスト内で定義されたテストデータを全て修正して回らなければならず、大きな修正コストが発生していました。 Fabricateならば、スキーマ変更時の修正が基本的にテンプレート定義の変更だけで済むため修正コストも大幅に少なくなります。 このように既存テストへの影響が少なくなるので、「ここテストが足りていない気がするので追加しておこうかな」という気持ちになれます。 テストコードの意図が明確なのでコードレビューの負荷が減った 弊社では、リリースされるコードはテストを含めて全てコードレビューを行っています。 これまではテストデータから本当に必要な情報がどれか分からず、テストを理解しづらいことがありました。 Fabricateでは、テストデータ生成時に指定されたカラムを見ることでそのテストの意図が分かるようになります。逆に、それ以外はそのテストでは関心が無いことがわかるので、見るべき範囲も限定されるようになります。 先ほどの例を見てみると、このテストでは body や created はチェックしていない（から気にしなくていい）ことがテストデータを見るだけで分かります。 <?php ... Fabricate :: create ( 'Article' , [ 'id' => 1 , 'title' => 'First Article' , 'published' => '1' ]) ; このようにテストの意図が明確になるので、「テストコードの中身までもう少し詳しく見ておこうかな」という気持ちになれます。 最後に テストコードの書き方が変わるという比較的大きな変更のあるツール導入でしたが、 強制移行ではなく『従来のFixtureも残しつつこちらを推奨』という形での導入だったこと Kibelaで使い方ドキュメント公開・社内ハンズオン開催と、新ツール導入へのサポート体制がしっかりしていたこと から混乱はありませんでした。 その結果、新しい取り組みでしたがすでに浸透しており、みんな新しくテストを書くときはほぼ全てFabricateを使っています。 BASEではフロントエンド、バックエンドを問わず中長期的な技術基盤の改善を担っていくエンジニア、およびその中でMove Fastにプロダクトをリリースしていくエンジニアを募集しています。 open.talentio.com open.talentio.com

こんにちは。BASE株式会社 DataStrategyに所属している齋藤( @pigooosuke )です。 先日、 ショッピングアプリ「BASE」 内の主要コンテンツである商品特集を自動で運用するように切り替えました。 今までは、「ワンピース特集」「ピアス特集」など、トレンド・テーマに沿った商品選定を人手で行い、全ユーザーに対して同一の配信をしていましたが、改善後はトレンドを捉えた特集コンテンツを自動で生成し、ユーザー別に最適化された特集を配信出来るようになりました。その結果、閲覧数の向上に繋げることが出来ました。 「BASE」ではレコメンドアルゴリズムを複数運用していますが、そのうち一部のモデルの応用により実現しましたので、その開発内容をお伝えしたいと思います。 特集について 「BASE」では特定のテーマに沿ってピックアップされた商品が特集としてリストアップされています。 BASEがセレクトしている今流行りの商品に出会えるコンテンツです。 要件定義 まず開発にあたって、必要事項の洗い出し・ヒアリングをしました。 リリースに向け最低限クリアしなくてはいけない条件は以下の通りでした。 特定のテーマに沿った特集であること それぞれの特集がトレンドをキャッチしていること 掲載商品は人気が出る商品であること それぞれの特集に対して、適切なタイトル文(説明文)が設定されていること 各ユーザーに対して、最適な特集が配信されていること 適切な商品・タイトルが設定されているか確認出来ること 上記を踏まえ、このようなフローなら一連の作業を代替出来るのではないかと構想・開発を進めました。 ここからは、各ステップでどのような処理をしているのか順に解説していきたいと思います。 1.商品レコメンドモデル作成 今回のレコメンドモデル作成には、 LightFM のモデルを活用しています。 LightFMとは、ユーザー・商品の特徴（メタデータ）を取り込むことが出来る因子分解レコメンドモデルです。 ユーザー・商品のInteractionからユーザー・商品の潜在表現(Latent Representation)を学習して、潜在表現から評価値を復元(予測)出来るようにしています。 日本語圏で取り上げられている記事が少ないので、もう少しモデルの中身を紹介します。 ここでは、ユーザー・商品をそれぞれ , 、ユーザー・商品の特徴をそれぞれ , とします。 このモデルでは、ユーザー・商品が持つ特徴に対してembeddingを行います。 そして、全てのユーザー・商品の潜在表現はそれぞれに付与されている特徴の総和で表現されるとしています。 ユーザー・商品の潜在表現をそれぞれ , として、 同様に、ユーザー・商品のバイアス項をそれぞれ , として、 と定義されます。 （特徴表現・バイアス項は、それぞれが持っている特徴の総和であるというだけを意味しています。） ユーザー に対する商品 の評価値 の予測は、 の潜在表現と の潜在表現の内積とそれぞれのbias項の和で計算します。 とてもシンプルな計算です。 損失関数については、WARP Loss(Weighted Approximate-Rank Pairwise loss)がサポートされており、BPRよりもこちらを活用したモデルが最も成績が良かったです。 ちなみに、WARP Lossはランク学習するための損失関数で、 まず、特定ユーザーの特定の正例に対して、それ以外の負例をランダムサンプリングします。 そこで、 正例の予測値 に対して、 負例の予測値 が一定のマージンを含めて超えた場合に、 商品総数 に対して出現までにかかったサンプリング回数 を考慮した、実際の評価と予測値の差分で重みを更新していきます。 参考資料: Learning-to-rank using the WARP loss 上で紹介したように、それぞれが持つ特徴同士の関係を踏まえ学習を進めるため、 「User-Item, User Feature / Item Featureの因子を組み合わせるので、Factorization machinesの特殊なケースとも言える。」とも論文では述べられています。 実際にこのモデルを使うメリットとしては、 CPU環境でも高速に計算可能 メタデータの追加が容易 各Interactionに対する評価値を自由に設定可能(Negative評価含め) 因子分解するためPureなFactorization Machinesより少ない計算量 が挙げられると思います。汎用性が高く個人的に好きなライブラリだったので利用しました。 同製作者が公開しているレコメンドシステムのフレームワークである Splotlight にも BilinearNet として同様の計算がGPU環境で実行出来るようパッケージ化されていますが、実際の運用ではCPUでも高速であり、モデリング時間自体がモデル更新処理全体に占める割合のごく一部にすぎないので、結果論ですがこれで十分だったと思います。 また、本番環境で運用するモデルを日々アップデートしていく中で、 どのような評価値(Rating)を、どのように学習に加えるかがレコメンドモデルでは重要ですが、今回の記事では省略します。 さらに、上記のモデルで評価値の推論を単純に行うと計算量が膨大となるので、計算量を減らす工夫も別途必要となります。 2.特集コンテンツ作成 ここでは特集に掲載する商品を選定していきます。 特集のトレンド感を出すのに利用しているのは、アプリ内検索キーワードです。 検索で上位に出てくるキーワードを元に商品群を選定しています。 （アプリユーザーが特定の特集を意図的に（不正に）生成出来ない仕組みは用意しています） 検索キーワードを元にレコメンドモデルで学習した商品群を抽出し、その中で 注目度の高い商品 を特集に掲載することにしています。 つまり条件付きソートです。 ここで商品に対する 注目度の高さ という評価軸に活用したのがレコメンドモデルの学習結果です。 今回のレコメンドモデルでは、商品に対する評価値はユーザー・商品の潜在表現の内積にユーザー・商品のbias項を加えたもので推論されます。 ユーザーを特定しない場合は、ユーザー・商品間の内積とユーザーのbias項を無視することで、 商品単体としての評価値はbias項で近似されるとも言えます。 その評価値のrankと、いくつかの別の評価値を加え、 注目の高い商品 として抽出しています。 ただ、「BASE」の商品群には注意すべき点があり、 「ワイドパンツ」というキーワードを元に特集を作ろうにも、それはメンズ？レディース？子供用？ また、「さくらんぼ」でも、それはフルーツ？刺繍？ といった多様な商品を掲載しているがゆえに、キーワードの属性を一意に決めることが困難なものが存在します。 そのため、各カテゴリーごとに特集を用意することにしています。 加えて様々な制御機構を経由し、最終的に200-300程度の特集を日々生成しています。 長くなりましたが、特集の中身をざっくり表現すると、トレンドキーワードの検索結果を（主に）人気順にソートしたものです。 わざわざユーザー自身でキーワードを入力せずに商品を閲覧出来る導線があるのは便利ですね。 3.特集タイトル作成 ここでは各商品群に対して最適なタイトルを選定していきます。 手元の状況を確認すると、 各特集にはカテゴリーとキーワードが付与されている 過去掲載してきた特集が十分蓄積されているとは言えない アノテーション済みデータもない 単語辞書もあまりない 特定ジャンルに特化しているサービスでもない（取り扱い商材はファッションからインテリア、エンタメまで） ということで選択したのは、条件分岐生成です。 これまで過去、コンテンツ担当者が生み出してきたキャッチーなタイトルを参考に単語の置き換えでタイトルを作ることにしました。 タイトル選定する手順は以下の通りです。 モデル作成時に、各特集で使われたキーワードがTableに追加されてきます。まだカテゴリー分類されていない未知語に関しては、オリジナルのラベルを付与していきます。 特定のタグが埋め込めているテンプレートには、どのキーワードカテゴリーに対応するかが設定されており、目的のキーワードに対して最適なテンプレートが選択されます。 テンプレートに含まれているタグに対しても別途テンプレートタグ専用のアノテーションデータを用意してあり、指定のタグを埋めていきます。様々なタグを用意することで表現の幅を広げられるようにしています。 他にも出力制御機構を用意してありますが、基本的な仕組みはこの通りです。 特集タイトルのデータ管理は専用のDashboard画面(Vue.js + Django)で運用されています。 キーワード管理画面 4.配信最適化 最後に、どの特集を誰に配信するかを決めます。 ここでまたレコメンドモデルの推論に戻ります。 既に各ユーザーの各商品に対する評価値を推定する準備は出来ているので、 全ユーザーに対して各特集に含まれる全商品の評価値を計算&比較し、好まれやすい特集を上位に表示するようにしています。 レコメンドモデルのデータセットに含まれなかった（予測が出来ない）ユーザー向けの表示も別の属性を利用して計算しています。 5.運用 ここでは特集コンテンツ管理をどのように運用しているか紹介します。 （データ配信基盤の説明に関しては今回省略します。いつか誰かが投稿してくれるかもしれません。） 特集内容の詳細については、専用のDashboard画面で各種監視出来るよう整備してあります。 不適切な商品・タイトル文が生成されていた場合に、画面操作で表示条件の切り替えが可能です。 運用成績については、Redashで集計・計測しています。 具体的な数字は今回公開しませんが、リリース前後で閲覧状況の改善を達成することが出来ました。 終わり 以上の内容を踏まえて、各処理を振り返るとこのような構成になっています。 今回の実装を終えて振り返ってみると、 レコメンドモデルの改善 ユーザー別に特集構成商品の切り替え 特集テーマ・トレンド検知モデルの置き換え 各特集に掲載する商品フィルターの改善 テンプレートで使っている単語に対するカテゴリー分類の自動化 アノテーションデータを揃えて、テンプレートに対する単語の埋め込み学習 など、まだまだ各処理の最適化&統一を行う余地があるので、 今後の運用状況を観察しつつ改善をしていきたいと思います。 大層な書き方をしていますが、個々の処理で利用している要素技術は非常に単純なものです。 レコメンドモデルに関しても、今回紹介したものを活用しないと出来ないものでもありません。 必要に応じて様々なアイディアを組み合わせた機能開発が出来るのもBASEのDSチームの醍醐味だと思います。 設計レビューやリリースのサポートして頂いたエンジニアの方々ありがとうございました。 今後も精度向上や機能追加を行い、使いやすいサービスを作って行きたいと思います。楽しみにして頂ければ幸いです。 BASEでは一緒にネットショップ作成サービスを開発・改善するエンジニアを募集してます。 機械学習チームでは、様々なデータや技術を使ってECならではの開発を続けています。 ご興味のある方はぜひ遊びにきてください！！ jobs.binc.jp

みなさん、こんにちは！めもりー ( @m3m0r7 ) です。 8/29 (木) から 8/31 (土) にかけて行われた builderscon tokyo 2019 に PHP で JVM を実装して Hello World を出力するまで というセッションタイトルで登壇させていただきました。 PHP で JVM を実装するとは？ Java というファイルは class ファイル、つまり 中間コードにコンパイルされ、 それを VM, つまり Java Virtual Machine 上で理解をして動かします。 この VM の部分を PHP で実装するということです。 トーク自体は 60 分枠でしたが、内容を濃くしすぎてしまうと、60分ではおさまらない内容となってしまい、どこを削るかという葛藤の中でスライド資料を作成していました。 セッションについて 本セッションでは Hello World の出力に的を絞ってトークさせていただいておりました。 出現する命令セットも少なく、バイナリを読むということを楽しんでもらい、かつ Java Virtual Machine に興味を持ってくださる方が多くなることを祈っておりましたが、セッション終了後に「Scala で実装してみようと思いました！」でしたり、「PHP で書いてみようと思いました！」というお声がけを懇親会の場で頂いて、とても嬉しく思いました。 また、私自身も他の言語で本当にできるのか？という証明として、本イベント終了後に JavaScript で実装をしてみて、それについての解説も書かせていただきました。 セッションで使用したスライド Speaker Deck にスライドをアップロードしております。 speakerdeck.com JavaScript で実装した例 Qiita に書かせていただいています。 qiita.com さいごに 次は、 PHP カンファレンス北海道 2019 、 PHP カンファレンス沖縄 2019 で登壇させていただきます。 セッションの内容は本件のような何かを実装するわけではなく、少し話の趣旨を変えた PHPer のための PHPUnit と Selenium を使ったブラウザテストのすゝめ というタイトルで、どちらかというと実務向けの内容になるかなと思います。 それでは、今後もよろしくお願いいたします！

BASE株式会社 Product Dev Division ソフトウェアエンジニアの田中( @tenkoma )です。主にPHPアプリ開発を担当しています。 BASEでは、PHPアプリ開発で使うエディタに制限はありませんが、希望する人はPhpStormを使えます。 PhpStormは設定を全くしなくてもかなり快適に使えると思いますが、多少設定するとより快適になります。 この記事では主に、開発環境とIDEを連携させアプリケーション開発をスムーズに始めるため、以下の設定について紹介します。 Xdebugと連携してリモートデバッグを可能にする PHPUnitと連携してテストをIDEから実行可能にする PHP_CodeSnifferを使ってコーディングスタイルを適用する EditorConfigを追加してコーディングスタイルを開発者で共有可能にする Xdebugと連携してリモートデバッグを可能にする BASEでは開発環境を Docker (docker-compose) を使って構築していて、環境構築に必要な手順を極力コードにしています。 PhpStormにはDocker環境と連携してリモートデバッグしたり、テストする機能があり、日々活用しています。 今回は以下のようなDockerの設定があり、対象のアプリケーションへWebアクセスが可能になっている状態である前提のもと、ブラウザからWebアクセスしたときに自動的にデバッグモードが起動し、IDE上で設定したブレークポイントで処理を止められるようにしてみます。 (実際のプロジェクトの開発環境を簡素化しています) docker-compose.yml # docker-compose.yml version : '3' services : php-cli : build : ./docker volumes : - ./:/var/www/html - ./docker/php.ini:/usr/local/etc/php/php.ini working_dir : /var/www/html ports : - "8080:80" expose : - "8080" composer : image : composer volumes : - ./:/app - ./docker/php.ini:/usr/local/etc/php/php.ini working_dir : /app docker/php.ini ; docker/php.ini ; timezone date.timezone = Asia/Tokyo ; error reporting log_errors = On error_log = /dev/stderr ; Xdebug xdebug.remote_enable = On xdebug.remote_autostart = On xdebug.remote_connect_back = Off ; デバッグ接続先をホストOS( host.docker.internal )に向ける xdebug.remote_host = host.docker.internal docker/Dockerfile # docker/Dockerfile FROM php:7-apache # Xdebug のインストールと有効化 RUN pecl install xdebug \ && docker-php-ext-enable xdebug ENV APACHE_DOCUMENT_ROOT /var/www/html/public RUN sed -ri -e 's!/var/www/html!${APACHE_DOCUMENT_ROOT}!g' /etc/apache2/sites-available/*.conf RUN sed -ri -e 's!/var/www/!${APACHE_DOCUMENT_ROOT}!g' /etc/apache2/apache2.conf /etc/apache2/conf-available/*.conf このファイルがリポジトリに含まれているとして、PhpStormでデバッグしてみましょう。 まずコンテナ群を起動します。(PhpStormで docker-compose.yml を開き、緑矢印ボタンを押してもOK) $ docker-compose up -d デバッグするスクリプトを用意します。 <?php // public/index.php phpinfo () ; 3行目の phpinfo(); にブレークポイントを作成したらIDE右上の Start Listening for PHP Debug Connections をクリックして、 http://localhost:8080/ にアクセスします。 Start Listening for PHP Debug Connectionsボタン すると、「Incoming Connection from Xdebug」というダイアログが表示されますので、 Accept ボタンをクリックします。すると、以下のように index.php の3行目で処理がブレークします。 (ブレークしない場合、ファイアーウォールの設定を見直したり、一時的にオフにして問題の切り分けが必要になります。) index.php の3行目でブレークしているところ PHPアプリリポジトリに docker-compose.yml を用意しておけば、Preferences を開いて設定しなくても、PhpStormでデバッグできました。 PhpStorm のデバッグツールでは条件付きブレークや、ブレークする代わりにPHPコード実行結果をデバッグコンソールにログをとる機能もあるので、 デバッグ連携できると開発が非常に楽になります。 BASEのプロジェクトでは、複数のリポジトリから共通のローカル環境を使うため、Docker環境を独立したリポジトリで管理しています。そのような場合は、ホストOS-コンテナ間のPath Mapping設定を docker-compose.yml から読み取ってくれないので別途設定が必要です。 PHPUnitと連携してテストをIDEから実行可能にする IDEからテストを実行できると、ターミナルと行き来してテスト実行コマンドを入力しなくても良くなるため快適です。 前提として、以下の設定ファイルを用意します。 composer.json { " name ": " baseinc/sample-api-php ", " autoload ": { " psr-4 ": { " App\\ ": " src/ " } } , " autoload-dev ": { " psr-4 ": { " Tests\\ ": " tests/ " } } , " require-dev ": { " phpunit/phpunit ": " ^8.3 ", " squizlabs/php_codesniffer ": " 3.* " } } 保存したら、PHPUnitをインストールします。 $ docker-compose run composer composer install そして、テストファイルを追加してみます。 <?php // tests/SampleTest.php namespace Tests; class SampleTest extends \PHPUnit\Framework\TestCase { public function testSame () : void { $ this -> assertSame ( 0 , "0" ) ; } } エディタの左側に緑矢印が表示されますが、まだテストは実行できません。 PhpStormでPHPUnitを使ったテストを実行するための設定 PhpStormからDockerコンテナ上でPHPUnitを実行させるのはいきなりは出来ません。どこのPHPインタプリタを使用させるのか、どのテストフレームワークを使用させるかをPhpStormに設定しなければなりません。 CLI Interpreter とTest Frameworksの設定をします。 「Preferences」を開き、 Languages & Frameworks > PHP にアクセス 右パネルの CLI Interpreter: が <no interpreter> になっているかと思いますが、右側の ... ボタンをクリック 「CLI Interpreters」ダイアログが開いたら、左上の + ボタンから、 From Docker, Vagrant, VM, Remote... 」を選択 「Configure Remote PHP Interpreter」ダイアログが開いたら、 Docker Compose 選択し、 Service: を php-cli に変更して OK をクリックして閉じる 「CLI Interpreters」ダイアログが以下のような表示に変わったらOK 「CLI Interpreters」ダイアログ 次に Languages & Frameworks > PHP > Test Frameworks を選択 右パネルで、 + ボタンをクリックし、 PHPUnit by Remote Interpreter を選択 ポップアップダイアログでは php-cli (7.x.x) に切り替えて OK ボタンを選択 詳細な設定が入力できるようになるので、 Path to Script: に /var/www/html/vendor/autoload.php と入力し、 OK を押し、「Preferences」を閉じる Languages & Frameworks > PHP > Test Frameworks これで設定完了です。もし、 phpunit.xml.dist が用意されている場合は、 Default configuration file: をチェックし /var/www/html/phpunit.xml.dist を入力します。 緑矢印をクリックしてテストを実行すると、次のように結果が表示されます。 (前節でオンにした、IDE右上の Start Listening for PHP Debug Connections はオフにしたほうがいいみたいです。) PHPUnitテスト結果が表示されたRunパネル これでPHPUnit連携ができ、IDEから実行可能になりました。ショートカットキーから一発で実行することも出来ますし、デバッグ実行すれば設定したブレークポイントでブレークすることも可能です。 var_dump() によるプリントデバッグも手軽なのですが、実行途中の変数情報を一覧できたほうがもっと効率よくテストを書くことが出来るのでとてもおすすめです。 PHP_CodeSnifferを使ってコーディングスタイルを適用する コーディングスタイル違反はCIで指摘するよう設定されていますが、コミット前に修正できると指摘されなくなり、開発しやすくなります。 (本当はコミット時に自動適用される設定を紹介したかったのですが、やってみると、コミット 後 のソースに反映されてしまったので、IDEとの連携設定だけ紹介します) 1. phpcs , phpcbf のパスを設定する 「Preferences」を開き、 Languages & Frameworks > PHP > Test Frameworks > Quality Tools を開く Configuration: 右側の ... ボタンをクリック PHP Code Sniffer path: で /path/to/your/project/vendor/bin/phpcs を入力 PHP Code beautifier and Fixer Settings - Path to phpcbf: で /path/to/your/project/vendor/bin/phpcbf を入力 OK ボタンを押して、「Preferences」を閉じる Code Snifferダイアログ 2. コーディングスタイルルールを選択する 「Preferences」を開き、 Editor > Inspections を選択 PHP Code Sniffer validation にチェックを付ける Coding standard: の右側の更新ボタンをクリックすると、リストが更新されるので、 PSR2 を選択 Editor > Inspections 以上で設定完了です。この状態で以下のコードのコーディングスタイルを修正してみます。 <?php // src/Sample.php class Sample { public function test () : void { if ( $ _SERVER [ 'HTTPS' ] === 'on' ) { header ( "Location: https:// { $ _SERVER [ 'HTTP_HOST' ]} " ) ; } } } メニューバーから Code > Code Cleanup... を選ぶと、以下のように変更されます。 <?php // src/Sample.php class Sample { public function test () : void { if ( $ _SERVER [ 'HTTPS' ] === 'on' ) { header ( "Location: https:// { $ _SERVER [ 'HTTP_HOST' ]} " ) ; } } } EditorConfig設定を追加してインデントを自動調整する .editorconfig ファイルを用意しておくと、エディタのインデント設定を無視してそれに従ってくれます。 .editorconfig ; .editorconfig root = true [*] end_of_line = lf insert_final_newline = true [*.php] charset = utf- 8 indent_style = space indent_size = 4 trim_trailing_whitespace = true PHPファイルを保存すると、行末尾のスペースを削除したり、最終行末尾に改行が挿入されるのがわかります。 自動化されていないとバラバラになりがちなので便利です。 以前のバージョンでは、プラグインをインストールする必要がありましたが、2019.2でバンドルされるようになったので、手間が減りました。 設定ドキュメントを書く 上記で紹介したように、PhpStormに限定されないようなDocker環境/PHPUnit/PHP_CodeSniffer などの設定ファイルはリポジトリで共有していますが、PhpStormの設定については管理してないので、社内情報共有ツール(Kibela)にドキュメントを書いて共有しています。例えば以下のようなドキュメントがあります。 PHPプロジェクト向けIDE PhpStorm 推奨設定 PHPUnit と IDE(PhpStorm) を連携させて、PHPアプリ開発を楽にしよう PhpStorm おすすめプラグイン PhpStorm + Xdebug (Remote Debug) CLI編 プロジェクトの .idea ディレクトリの特定のファイルをリポジトリに含めれば、もっと環境構築をスムーズにできそうですが、PhpStormにロックインさせすぎるのもどうかな、という気持ちがあり、やっていません。スクリーンショット付きで説明したような手順についてはドキュメントで共有しています。 まとめ PhpStorm で開発がしやすくなるようDocker環境、デバッグ、テストの設定を用意したり、情報共有ツールで、PhpStormの設定ドキュメントを共有する話を紹介しました。

こんにちは！ BASE BANK株式会社 Dev Divisionでソフトウェアエンジニアをやっている東口（ @hgsgtk ）です。先日、7月24日〜7月27日にアメリカ・サンディエゴで開催された GopherCon 2019 に参加してきました。初めてのアメリカ、初めての国際カンファレンスで、初めての英語でのLightning Talkをしてきました。当日の会場の様子も含めてGopherCon 2019の参加レポートをします！参加した結果、やっておいてよかったこと・やっておいたほうが良かったことといった反省点などもまとめます。 GopherCon 2019とは GopherCon 2019とは、プログラミング言語Go関連で世界最大級の国際カンファレンスです。今年は6年目となり、世界中から1800名弱のGopherが参加したようです。7月24日から27日にかけて4日間開催されました。 BASEでは、カンファレンスへの登壇や参加といったメンバーのコミュニティ貢献活動を積極的に支援しており、今回のGopherConにも業務として参加してきました。 www.gophercon.com 会場は、 Marriott Marquis San Diego Marina というアメリカ・サンディエゴにあるリゾートホテルでした。サンディエゴ国際空港から車で15分ほどの距離にあり立地的にも便利な場所にあります。 サンディエゴ国際空港より 会場のホテルはGopherCon一色に染まっていて、エントランスに入ると Welcome Gophers! とGopherCon参加者を迎えてくれます。 Welcome Gophers! 会場のホテルに泊まったのですがホテルのルームキーもGopher君が描かれています。 Gopherなホテルルームキー ホテルを出るとすぐ海岸なので、すこし散歩するだけで西海岸のきれいな夕焼けを見ることができます。 会場ホテルから見える西海岸の夕焼け 1800名弱が参加しているということで、世界中から集ったGoエンジニアがメイン会場を埋め尽くします。 メイン会場の様子 スケールが大きいカンファレンスで25日のWelcome Partyでは、 USS Midway Museum という実際に使われていた空母ミッドウェイという航空母艦を博物館にした観光名所を貸し切ってパーティが開催されました。 船上でのWelcome Party Lightning Talkでの発表 今回のGopherConでは、募集されていたCFPにうち、25分のKeynote style・7分のLightning Talkの2種類にプロポーザルを提出して、 Building API Server-side architecture for beginners というタイトルのプロポーザルが採択され発表しました。プロポーザルの内容自体については以下のブログで詳細について書いたので興味ありましたらそちらもご覧ください。 basebook.binc.jp GopherConは最終日（7/27）に10時から16時まで一日かけて約30名のスピーカーがLightning Talkに登壇しました。私は朝一の2番目の順番で発表しました。 LT登壇中 発表した内容は次のスライドでSpeakerDeckに公開しています。Goプロジェクトのサーバーサイドアーキテクチャを構築する考え方についてまとめたものです。特にGoを業務で採用し始めることを決断した"Beginners"な開発チームがどういうアプローチで取り組むかという視点で話を構成しています。 今回が私にとっては、初めての海外でのカンファレンス登壇で、初めての母国語ではない英語での発表でした。準備したこと・当日の発表について良かったこと・改善ポイントをまとめることは、きっと次同じようなチャレンジをされたい方に有益かなと思うので、ここで整理してみます。 CFPへのプロポーザルを振り返る 今回、Lightning Talkに提出したプロポーザルは以下の3つでした。 Building API Server-side architecture for beginner <- 発表 Design considerations for container-based Go applications Implementation example of OAuth 2.0 request handler with ensuring testability この3つのプロポーザルのうち最初3つとも採択いただきました。ただし、1人1トークということで運営の方より選んでいただき今回の発表内容になりました。 今回のプロポーザル提出を振り返って「良かったこと」・「やっておいたほうがよかったこと」は次のようなことです。 良かったこと Keynote(25min)にもプロポーザルを提出したこと 初めての国際カンファレンスで参加すること自体初めてな私にとって、KeynoteのCFPにプロポーザルを提出して英語で25分話すなど正気の沙汰ではないえげつない一歩でした。それができるほどのレベルの内容じゃないなとも思いました。 ただ、普段のカンファレンスでもそうですが、トークするに足る内容かどうかは採択していただく方々が決めることです。そう考えると、とにかく出してみることにしました。結果的にはKeynoteのCFPでは採択されなかったのですが、よりハードルが高いCFPに対してすでにプロポーザルを出していたので、Lightning Talkには大胆な心でプロポーザルを出せました。 国内で話した実績のある内容 国内カンファレンスのCFPに対しては、今まで話したことがない新規の内容について話すように心に決めているのですが、英語でトークすること自体がチャレンジなので、GopherCon 2019に限っては国内で話した内容を翻訳する形でプロポーザルを作成しました。 これにより、すでに話したことがある分、トークの内容の概要・詳細・構成についてプロポーザルの本文に込めることができました。また、いくつかやってきた過去のトークがあるので、何本か数を出すことができました。 やっておいたほうがよかったこと 締切に余裕を持った早期のプロポーザル提出 今回のプロポーザル提出は、いろいろ他のカンファレンスの発表準備をしているうちにギリギリの提出になってしまいました。ただ、GopherCon2019では早い段階で提出されたプロポーザルに対しては運営からのフィードバックをもらえたようです。たとえば、今回Tutorial style(45min)でスピーカーをされた、 @monochromegane さんは、早期にプロポーザルを提出したことから、運営からのフィードバックをもらいよりプロポーザルの内容・形式をブラッシュアップできたとおっしゃっていました。運営からのフィードバックをもらえるカンファレンスではしっかり早期に出したいなと思います（実際、 Go Conference'19 Summer in Fukuoka では、運営の方からのフィードバックでプロポーザルを見直すことができ非常によい体験でした）。 発表を振り返る これまで、色々なカンファレンス・イベントで発表してきたのですが、正直な話今回が過去最高に練習しました。実際に次のようなステップで練習を進めました。 発表資料作成 社内発表練習 現地発表練習 発表資料作成 発表資料作成にあたり工夫したことは「話す言葉をスライドに含める」という点です。一方で反省点としては、「スピード感を入れようとしない方がいい」という点です。 話す言葉をスライドに含める 発表資料の作成にあたっては、なるべく話すことをスライドに含めるようにしました。たとえば、母国語でのトークでは流れの中で口頭で補足するような言葉もスライドに入れました。 実際、現地の他の方の発表では、スライドは少なめで1枚のスライドで口頭補足を多く行う発表資料の方が多いです。英語での説明に苦がない方であればこのような工夫はいらないかもしれませんが、英語でのスピーチに不安がある場合には個人的には安心感がありました（いずれこういう工夫をしなくてよくなるように頑張りたい・・・！）。 スピード感を入れようとしない方がいい 一方で反省点として、Lightning Talkだしなとおもいスライド多めな構成にしたことが裏目に出ました。国内カンファレンスでLightning Talkする際はぎゅっと5分で詰め込んでスピードで駆け抜けるタイプの構成でやってしまうのですが、それは母国語だから（ぎりぎり）許されることだと感じました。 母国語じゃない不慣れな英語でやるのは今回の経験上、私はあまりおすすめできません（そもそもそういうスタイルがどうなんだみたいなツッコミもありますよね、過去の聴講者の方々すいません・・・！）。 不慣れな言語を早口で話すと聞き取りづらいですよね。普段、ネイティブの方が話してるのを聞いたときに感じる「話すの早いなぁ」と感じているあの速度で話そうとすると、聞き取りづらくなってしまいます。外国の方が片言の日本語でめっちゃ早口で話してきたらどうだろうかと想像していただくとガッテン行くかもしれません。 実際、一つ現地の方から頂いた感想で「日本人は英語を話すのが早い」というフィードバックでした。自分の想像している速度の0.75倍速くらいで話して、文節の区切りで話も区切るくらいがちょうどいいんだなと実感しました。 言い訳をすると、ゆっくり話すことは意識していました。しかし、意識していても緊張したら早口になってしまうのが人間というもの。その上で資料のスタイルがスピードトーク型だと、緊張との相乗効果が生まれて早くなってしまいます。 ゆっくり話す前提でトーク内容のボリューム・資料構成を考えると丁度いいスピードになるだろうと思います。 社内発表練習 資料が作成できたら発表練習を社内でやりました。普段のカンファレンス発表から練習に付き合っていただいている @nazonohito51 さんと、英語が得意なインターンでいらっしゃっていた 顧さん に2回ほど時間をもらい練習しました。 不自然な英語や発音・話すスピードなどについてフィードバックをいただき改善しました。 現地発表練習 現地サンディエゴに到着してから、日本人で発表する @monochromegane さん・ @hajimehoshi さん・私の3人と、 @go_sagawa さん・ @tenntenn さんでホテルの一室で発表練習をしました。現地で一回Gopherたちの前で発表しておいたことは「当日もなんとかなりそうだ」という安心感になりすごくよかったです（お付き合いいただいたみなさんありがとうございました！）。 のちに発表者全員の発表を終えたあとに記念撮影しました。 左: @hajimehoshiさん 中: @monochromeganeさん 右: @hgsgtk 初めての海外カンファレンス参加を振り返る 良かったこと Gophers slackのGopherCon参加者チャネル そもそもGopherCon 2019に参加してみたい・登壇してみたいと思ったときに、これまで参加したことがある人・登壇したことがある人が物理的に身近にはいませんでした。そんな迷いを雑にtwitterでつぶやいたところ、 @tenntenn さんがGopherCon 2019に参加しようか検討している人が集まるslackチャネルを作っていただきました。 Gophers Slackに gophercon-san-19-ja というチャンネルを作りました！ — tenntennʕ ◔ϖ◔ʔ ==Go (@tenntenn) January 10, 2019 このチャネルで参考になる過去採択された方のプロポーザルの内容を共有いただいたり、非常に参考になりました。また、会社の中では一人で参加するわけで不安があったのですが、同じ日本から参加される方とこのチャネルを通じて事前につながっておけるのに非常に心理的な安心感がありました。 海外で登壇する経験 国際カンファレンスで登壇することは、単純に憧れていた一つの目標だったので良かったです。 現地で良かったことしては、会場のエンジニアと話すときに「Lightning Talkでこういうこと話す予定なの」みたいな切り口で会話のネタとして使えました。 また、Lightning Talkをしたことがある方ならイメージ付きやすいと思うのですが 、Lightning Talkの始まる直前ってスピーカー同士で待ってる間待機場所で話したりすることがありますよね。GopherConでも同様に自分の前後のスピーカーたちと話す時間になり結構楽しい時間になりました。 毎日参加ブログを公開して振り返る カンファレンスで現地にいる間、毎日その日の内容について参加ブログを書いていました。 GopherCon2019 参戦記 DAY1 (7/24) GopherCon2019 参戦記 DAY2 (7/25) GopherCon2019 参戦記 DAY3 (7/26) GopherCon2019 参戦記 DAY FINAL (7/27) これは、その日を振り返ってわからないことをまとめたりとか、その日の反省点を言語化して翌日以降の振る舞い方を考えるいい時間になりました。たとえば、2日目に英語力で躊躇してコミュニケーションが取れなかったことを反省して、3日目はとにかくメチャクチャな英語でいいから話すことを心がけるようにしました。 やっておいたほうがいいこと 時差ボケを矯正する一日をおいたほうが良い 今回の会場であるサンディエゴと日本は時差にして16時間あります。私は、カンファレンス中時差ボケで睡眠時間が非常に少なくなり、早朝に前日の参加速報ブログを書くといった生活になってしまいました。一方で、国際カンファレンス遠征に慣れてらっしゃる方々は前々日入りして一日時差を矯正する時間をとっていました。一日英語漬けで技術トークを聞いて会場のエンジニアと交流するのはそれなりに体力を要するので、時差ボケ問題は早めに解消しておくのがカンファレンスでしっかり学びを得るためによいでしょう。 話のきっかけを用意しておく 日本のカンファレンスと大きく異なる点として、参加者同士のコミュニケーションが多いです。 参加者は、日本のカンファレンスのようにTwitter実況するといったことはほとんど無く、直接現地のエンジニア同士のコミュニケーション・ネットワーキングに時間を使っていました。これは、普段のカンファレンスで人見知りでコミュニケーションが苦手な私にとっては、結構衝撃をうけたことでした。 コミュニケーションしていくことにしっかり向き合おうとすると、英語力が云々はとりあえずなんでもいいから話しかければいいとして、その「なんでもいいから」の話のきっかけが思いつかないのが、人見知りが人見知りしている所以のところですよね。 「どのトークが面白かった？」とか「普段はどういうサービスでGo使ってるの？」とか話のきっかけになるような質問を英文セットで考えておくと良いと思います。 最後に 今回、GopherCon 2019に参加して、特にLightning Talkをした経験の振り返りをしました。自分が繋がりを持てると感じられる世界が広がった、そんな感覚を今回のカンファレンスで持てました。行くまでは不安がとても大きかったのですが、終わってみたら「また行きたい！」とそう思える経験になっています。 海外のカンファレンスに参加してみたい・何かしら発表したいと目論んでる方々にとって、少しでも後押しになる情報になることを願います。 また、きっと開催されるであろう GopherCon 2020 にプロポーザルを超自信を持って出せる知見を積み重ねられるように、これからも精進します。では、また、次のGopherConでお会いしましょう！

こんにちは。UIデザイナーの野村( @nomjic )です。 世のUIデザイナーの皆様は、デザインツールには何を使ってますか？私はSketchとFigmaを行き来して使ってますが、割とFigma推しです。ノンデザイナーでも割とすんなり使える優れものです。 先日Figmaのプラグイン機能がリリースされましたね。この記事書いてる時点でプラグイン数は100近くあり、この先便利機能がガンガン増えてくものと思われます。 いろいろ触って知っておきたいぞ！ということでBDI（※）でチームの数名とプラグイン触ってみることにしました。 ※ BASEのデザインチームでは、第2第4金曜にBDI Night (BASE Design Inspiration Night) を開催しています。洒落た名前つけてますけどいわゆる社内勉強会です。 （集まってくれたチームの皆さん） 30分ばかりで各々プラグインを触ってみて、用意していたスプレッドシートに簡単なレポートを書いていきます。 (こんな感じでキャプチャと2〜3行の解説を載っけていきます) 17個のプラグインを試せました。以下、特に便利そうだと感じた5個をピックアップしてご紹介します。 特選「これ便利」５件 [その１：Autoflow] site link 1クリックで2つのFrameを線で結んでくれます。シンプルゆえにとても便利。ノンデザイナーがFigma使う時などに便利そうですね。 その２：Charts site link 5種のグラフを生成できます。 色変更、フォントサイズ変更可能です。 生成するグラフのサイズの指定ができないのがちょっと不満... グラフは作ると手間だしサンプルも見つけづらいので、これはとても便利ですね。 その３：Color Contrast Checker site link 背景とテキストのコントラストチェックしてくれます。 それだけなら目新しくないのですが、「コントラストがNGかOKか」を確認しながら色調整が行えるようになってるのが、痒いところに手が届いてる感あっていいですね。 その４：Figmotion site link モーションアニメを作成できます。 レイヤー単位でのkeyframeを打てて、カスタムでイージングを設定できるので、簡単にアニメーションを書けます。json/cssへの書き出しもできます。 gifやmp4にもできますね。（が、書き出せたことが少々わかりづらい...。） その５：Nisa Text Splitter site link テキストボックスで入力した文章を、1行のテキストにばらしてくれます。 テキストボックス内の文章を、A→Zに並び替えしてくれます。 我々的にはベストヒットなプラグインでした。 すごい地味だけどすごく良い。スプレッドシートから文字列を持ってきた時とか、リストUIの文字を一つの大きなテキストボックスで組んだ時とか、とても便利ですね。素晴らしい一品。 その他、触ってみたプラグインたち せっかくなので触ったプラグインのキャプチャと一言説明を以下に全部掲載します。 ざっと流し見しとくと今後のFigma作業が捗るのではないでしょうか。 Color Palettes site link 画像から5つ色を抜き出します。 Color Blind site link 色覚障害者からの見え方をシミュレートします。 写真に対しては無効です。 Chroma site link 選択したオブジェクトのfill色とオブジェクト名からカラースタイルを生成します。 Content Reel site link Sketchの「Data」機能と同じで、用意されたAssetから要素を挿入できます。 テキスト 顔写真 アイコン など。 Border site link Frameに線をつけます。 オブジェクトには無効なのでご注意。 Find & Focus site link 文字列の検索と置換です。 以前はChrome拡張として提供されていた機能がプラグインとして実装されたようです。 テキストオブジェクトだけでなくレイヤー名にも有効ですね。 Google sheets sync site link Google sheets上のテキストデータとFigmaファイル上のテキストオブジェクトを同期させます。 文言管理に便利なのですが、Google sheetsがWeb公開されていないと使えないので業務ではちょっと扱いづらくもあります。 Iconify site link アイコンのライブラリを開いてアイコンを挿入します。 Super Tidy site link 選択したFrameを、 等間隔に配置できます。 グリッド状に1クリックで配置できます。 名前を一括で連番にできます。 Table Generator site link 表組みを生成します。cols/columnsとdataを入れるだけでサクッと作れる便利プラグインです。 Unsplash site link フォトライブラリから画像をもってきます。 カテゴリ内の画像をランダムに選ばせるか、キーワード検索で抽出した任意の画像を選んで挿入することができます。 Viewports site link デバイスに沿ったviewportサイズでFrameを切り替えてくれます。デバイスのシェア率が書いてあったりもするのですが... 使い道がイマイチ思い浮かばず、でした。 以上、「Figmaのプラグインを色々触ってみようの会」のご報告でした。 世のUIデザイナーのお役に立てたなら幸いです。

UIデザイナーの野村( @nomjic )と申します。 今回はフレームワークの話をしたいと思います。と言ってもRailsとかVueとかの開発フレームワークでなくて思考フレームワークです。 そうですデザイン思考です。 デザイン思考フレームワークを体験する2時間ワークショップを社内で行ったのでその様子をお伝えします。 まず、デザイン思考とは何なのか Wikipedia上では以下のように書かれています。 デザイン思考（でざいんしこう、英: Design thinking）とは、デザイナーがデザインを行う過程で用いる特有の認知的活動を指す言葉である よくわからないですね。 本読んだりWeb記事読んだりすると色々と書かれているのですが、コンテクストによって解釈は様々で、調べれば調べるほど混乱してしまいます。 私個人としては、 デザイナーの思考・行動パターンの中の、汎用的に適用しやすい部分を切り出したもの をデザイン思考と呼んでるのだと解釈してます。 デザイン思考はビジネスに限らず日常生活やレジャーの中でも役立つものなので、万人が知ってて損はないものだと思ってます。かといって万能って訳でもないですが。 そんなデザイン思考を体験してみませんか？と社内Slackで声かけたところ、そこそこ人が集まったので、ワークショップを実施した次第です。 ワークショップ風景 ワークショッププラン 参考にしたワークショップ 2018年夏に某所で開催された コペンハーゲン式デザイン思考を学ぶ！1dayワークショップ で実践されていたプロセス（図参照）を下敷きにして、2時間程度の尺に収まるようプランしました。 図: 参考にさせていただいた1dayワークショップでのプロセス このプロセスの後半あたりの、 CO-CREATION まで体験できることを目標にプランを立てました。 全体の流れ タイムスケジュールは以下の通り。 アサンプションマッピング（連想ワード書き出し）：8分 模擬ユーザインタビュー Round1：8分 模擬ユーザインタビュー Round2：8分 インタビュー分析（課題抽出）：16分 問い（仮説と"How Might We 〜 ?"）の作成：10分 　　--- 休憩5分 --- アイディエーションRound1：10分 アイディエーションRound2：10分 ソリューション検討：10分 シェアと振り返り：5分 てんこもりですね。 テーマ 「旅行の計画立ての体験を向上するプロダクトを作る」 をテーマに掲げました。 シンプルに「旅行」でも良かったのですが、短い時間のワークショップなのでテーマは狭めた方が良さそうと考え、このようなテーマに相成りました。 人数とか場所とか 12名のメンバーに集まってもらえたので、4人ずつの3チームに分けました。 社内の打ち合わせスペースで、大きいテーブル1つと小さい卓を1つ、それとホワイトボード3枚を使って実施しました。 ワークショップ内容（実施したこと・様子） 連想ワード書き出し まずは頭の体操がてら、「旅行計画」から連想する言葉をひたすら書き出してみます。 各々の頭の中の情報の可視化と共有をざっくり行うことを意図してます。 模擬ユーザインタビュー 各チーム内で、各々の「旅行計画にまつわる体験」を掘り下げるインタビューを行ってもらいます。 以下のような質問例を挙げはしましたが、基本自由に聞きたいことを聞いてもらいました。 過去に、どんな風に旅行を計画しました？ その中で、好ましく感じた体験は？ 良くなかった体験は？ インタビューに不慣れなためか最初はスムーズにコミュニケーションが進まなかったチームも見受けられましたが、一定程度は体験と価値観の共有ができたようです。 このあたりは、チームビルディングの観点でも組織の活動に貢献できると考えています。 ここで得た共通認識を踏まえて、以降の課題発見＆ソリューションのフェーズへと進んでいきます。 仮説立て（課題発見） インタビューで引き出した種々の体験を踏まえ、「良い旅行計画とは何か？」「悪い旅行計画とは何か？」についての仮説を立ててもらいます。この段階では複数の仮説を立てて、付箋に書いていきます。 うん、お腹減らさない、大事ですね。大事大事。 問いを作る 仮説をもとに、「いかにしてXXXを排除し、YYYをより良くするか」という問いを作ります。 （XXXには「悪い体験」、YYYには「良い体験」が入ります。） 作成された問いの一例 「いかにして、計画を固く定めず、旅行中のライブ感を大切にしてアクシデントを楽しむか」 いわゆるHMW（How Might We... ?）というやつなのですが、ここがなかなか慣れないと難しいところで、「問い」とは少し違う形になってしまったチームもありました。 とはいえ、次ステップでアイデア出しするための情報は出揃ったので、進めます。 アイデア出し 作成した「問い」に回答する形で、アイデア出しをします。 クレイジー8方式 で実施しました。 もう少しグラフィカルにアイデアを出してくれることを期待したのですが、付箋が小さすぎて描きづらかったかな、と反省。 「デザイナーはビジュアライズ必須」とか縛りを与えても良かったのかもしれないです。 ATI（圧倒的当事者意識） に強烈な思い入れを持つチームがあったりもしました。 こういうキャッチーなワードが取り上げられ、不思議な一体感が生じるのもワークショップの醍醐味かもしれません。 ソリューション提案作成 アイデアの取捨選択・統合をして1つのソリューションに整理します。 整理のためのヒントとして、以下のようなフォーマットを提示しました。 提案名・提案概要 想定ユーザ ユーザにもたらす価値 他サービスに対しての位置付け マネタイズ そして、複数のソリューション提案が作成されました。以下、一例。 提案名：いきなりトリップ 予算感とNG項目（アレルギー等）だけ伝えて、あとのプランは全て任せられるサービス。プランは当日、現地についてから伝えられるので、バラエティ番組の企画のような無茶振りを楽しめる。 割とどのチームもまとまった提案になりました。アイデア出しの途中で 「過酷な試練を与えて、それに耐え抜かないと旅行に参加できないシステムを...」 とか聞こえて、どんなソリューションに昇華するのか楽しみにしてたのですが、提案には採用されなかったようです。 プレゼンテーション 各チームよりアイデアのプレゼン＆シェアをしてもらいました。 そして片付け・解散と相成りました。お疲れ様でした。 今後の予定 単発で終わらせず、継続していきたいと思っています。 部活的なものにするとか、新人研修プログラムに組み込むとか... 個人的には、社外の人や「BASE」のユーザーも参加できるオープンな場にして、ユーザーリサーチを兼ねたりできたら良いなあ、なんていう野望もあります。 他の会社さんでもやってみたいなと思っていますので、ご興味のある方がいらっしゃいましたら @nomjic にDMいただけると嬉しいです。 以上、お読みいただきありがとうございました！参加してくれた12名はホントホントありがとうございました！

Product Dev Divisionの川島（ @nazonohito51 ）です。 BASEでは創業当時よりCakePHPによるWebアプリケーション開発を行っており、同時にそのテストも充実させてきました。ですがその過程で気づくのは、CakePHP標準の仕組みだけではテストを増やせば増やすほどテストデータの管理が難しくなり、テストをメンテナンスするのが困難になる問題でした。きちんと長期的にサービスを良くしてくれる資産価値の高いテストが書けるように、今回はその問題と向き合い、解決するために @sizuhiko さんの開発された Fabricate というライブラリを導入したお話を書かせていただこうかと思います。 BASEの直面した課題 CakePHP2のFixtureという仕組み 詳細は 公式ページ を参照していただきたいのですが、CakePHP2にはテストデータを作るためのFixtureという仕組みがあります。おおよそのWebフレームワークにもあるとは思いますが、事前にデータベースに対してテストに必要なテストデータを入れておくための仕組みです。 このFixture、テストの数が少ないうちは良いのですが、テストの数が増えてくると扱いが難しくなる面が出てきます。BASE内部で発生した問題を挙げますと、まずテストメソッド毎に個別のテストデータを用意することがFixtureだと大変なので、複数のテストメソッドで同じFixtureを共有していましたが、後の改修案件の際にテストデータを更新するとたくさんテストが失敗していました。どこがいじって良くて、どこがいじっちゃだめなのか、テストからそれを読み解こうと思っても各テストメソッドにとって本当に必要なカラムがどれなのかを理解することが困難でもはや手を出せません。ちょっとした改修でも本来なら全然関係ない箇所のテストの修正まで派生し、テストのメンテナンスに大きなコストがかかっていました。 もちろんFixtureという仕組みの問題というより、BASEの運用の問題もあったりしますが、本質的にFixtureはテストのスケールに耐えられる仕組みではないと捉えています。正確性には欠けますが、社内にFixtureの問題を理解していただくために簡易的に用意した図が以下となります。 CakePHP初期 CakePHP中期 CakePHP後期 xUTPから見る現状の問題整理 これらは具体的にどんな問題なのか、そして解決するにはどの方向へ向かうべきなのかを理解するにあたり、 xUnit Test Patterns の掲げるテスト原則を参考にしますと、 Keep Tests Independent（テストを独立させよ） と Communicate Intent（意図を明確にせよ） に違反している状況と捉えています。 Keep Tests Independent 原則の意味 テストが相互依存的あるいは順序依存的である場合に、テストが我々に提供するフィードバックが信用できなくなってしまうため独立させるべき、という原則 若干の読み替えはありますが、テストデータを含めてテストメソッド間の依存を取り払うべきとも解釈できます BASEにおける原則違反 複数のテストメソッドで同じFixtureを共有しているため、テストデータを介してテストメソッド同士が相互依存的になってしまっている 後にテストデータを更新すると多くのテストが壊れてしまい、変更しづらい・メンテナンスしづらいテストになってしまっている ※テストデータを共有すること自体が悪いことではないのだが、BASEではメンテナンスに支障をきたすほどの共有が行われている Communicate Intent 原則の意味 意図が明確なテストは理解することとメンテナンスすることが容易である、という目的で掲げられている原則 BASEにおける原則違反 そのテストメソッドが本当に必要としているテストデータをFixtureから読み解きづらいため、何故テストが成功/失敗しているのかその因果関係を読み解くことが出来ない 理解することが出来ないため、後から改修することも難しい 以上の原則から照らし合わせて、現状のBASEはテストを作ったは良いものの、後から理解し修正することが容易ではない、資産価値の低いテストコードを量産してしまっている状況であると言えます。（資産価値の低いテストコードとは、テストを通して開発コストを下げたかったはずが、逆にメンテナンスするコストが大きいようなテストコードを指しています）これらの問題を解決するには、各テストが独立しやすく、かつ可読性が高くできる新しい仕組みが必要であると考えました。そしてそれは後述のFabricateというライブラリが最適であると考えました。 Fabricateによる解決 Fabricateとはなにかを身も蓋もなく言ってしまえば「Railsの FactoryBot みたいなやつ」と言ってしまったほうが多くの人に伝わりやすいかもしれません。概要を書くなら「テストメソッドごとの差分をオーバーライドしながら実テストデータを生成する」ライブラリです。 Laravelにも同様の仕組み があります。 Usage まずはFabricateの1テーブル辺りの定義を書きます。これは実テストデータを作るためのテンプレートのようなものであり、コレ自体は実テストデータではありません。あらかじめ属性のセットないしはその生成方法を定義しておくと、これをベースにFabricateはテストデータを作成してくれます。この作業は必須ではありませんが、なるべくリアルなテストデータを使いたいという理由からBASEでは全テーブル分の定義を書いています。 <?php class FabricateUserFixture extends CakeTestFixture { public $ import = 'User' ; public function init () { parent :: init () ; Fabricate :: define ([ 'User' , 'class' => 'User' ] , function ( $ data , $ world ) { $ now = new DateTimeImmutable () ; return [ 'id' => $ world -> sequence ( 'user_id' ) , 'login_id' => $ world -> sequence ( 'login_id' , function ( $ i ) { return 'loginid' . $ i ; }) , 'last_name' => $ world -> faker () -> lastName, 'first_name' => $ world -> faker () -> firstName, 'state' => 0 , 'created' => $ now -> format ( 'Y-m-d H:i:s' ) , 'modified' => $ now -> format ( 'Y-m-d H:i:s' ) ] ; }) ; } } そしてテストメソッド内では以下のようにしてテストデータを作成します。 <?php class SomeClassTest extends CakeTestCase { public $ fixtures = [ 'app.Fabricate/fabricate_user' , ] ; public function testMethod1 () { Fabricate :: create ( 'User' ) ; $ this -> assertSame ( 1 , ClassRegistry :: init ( 'User' ) -> find ( 'count' ) ; ) ; } } 上記のうち Fabricate::create('user'); がFabricateによるテストデータ生成を行っている箇所となります。このステートメントでFabricateが事前に定義したテンプレートを元にテストデータを作成してデータベースに保存してくれています。これはサンプルなので特に意味のないテストではありますが、その後のアサーションでデータが1件保存されていることを確認しています。ちなみに実際のデータベースを覗くと以下のようなデータが保存されており、テンプレートの定義に沿ったデータが保存されていることが分かります。 mysql> select * from users; +----+---------------+-----------+------------+-------+---------------------+---------------------+ | id | login_id | last_name | first_name | state | created | modified | +----+---------------+-----------+------------+-------+---------------------+---------------------+ | 1 | loginid1 | 鈴木 | 裕太 | 0 | 2019-07-23 11:43:55 | 2019-07-23 11:43:55 | +----+---------------+-----------+------------+-------+---------------------+---------------------+ 1 row in set (0.00 sec) Fabricateで独立したデータを作成する さて前述の課題のうち、テストが密結合してしまっている課題をテストメソッド個別のテストデータを作ることで解消してみます。もちろんFixtureでもやろうと思えば出来なくもないのですが、Fabricateだととてもかんたんに実現できるという例になります。 <?php class SomeClassTest extends CakeTestCase { public $ fixtures = [ 'app.Fabricate/fabricate_user' , ] ; public function testMethod1 () { Fabricate :: create ( 'User' , [ 'state' => '0' ]) ; $ this -> assertSame ( '0' , ClassRegistry :: init ( 'User' ) -> find ( 'first' )[ 'User' ][ 'state' ]) ; } public function testMethod2 () { Fabricate :: create ( 'User' , [ 'state' => '1' ]) ; $ this -> assertSame ( '1' , ClassRegistry :: init ( 'User' ) -> find ( 'first' )[ 'User' ][ 'state' ]) ; } } 上記の例の場合、2つのテストメソッドで Fabricate::create() が呼ばれていますが、その第2引数に違いがあります。Fabricateは生成したいテストデータのうち、特定のカラムの値をオーバーライドすることでテストメソッド上から明示的に指定することが出来ます。上記の例の場合はtestMethod1では 'state' カラムの値を0として生成しており、testMethod2では1として生成しています。指定していないカラムの値はテンプレートの定義に従って作成されます。 このようにFabricateではテストメソッド個別に必要なテストデータを柔軟に用意することが出来ます。Fixtureで用意するテストデータは（多くの場合）固定値であるため柔軟に用意することは難しかったのですが、実際のところ各テストメソッドがそのテスト要件として本当に必要なデータはそれぞれ 微妙に 違うことがほとんどです。テストメソッドの数を増やせば増やすほどテスト全体として必要とするテストデータのバリエーションは膨大な数になりますが、Fabricateはそのようなバリエーションの違いをテストメソッド上のオーバーライドによって実現し、柔軟なテストデータの供給を実現しています。 また「必要なカラムだけオーバーライドする」というこの作成方法は後述の可読性にも寄与していると捉えています。 Fabricateで可読性の高いテストメソッドを書く <?php class SomeClassTest extends CakeTestCase { public $ fixtures = [ 'app.Fabricate/fabricate_user' , ] ; public function testMethod3 () { Fabricate :: create ( 'User' , [ 'login_id' => 'testuser' , 'state' => '1' ]) ; $ user = ClassRegistry :: init ( 'User' ) -> find ( 'first' )[ 'User' ] ; $ this -> assertSame ( 'testuser' , $ user [ 'login_id' ]) ; $ this -> assertSame ( '1' , $ user [ 'state' ]) ; } } 上記の例では 'login_id' と 'state' の2つのカラムをオーバーライドしてテストデータを作成しています。そしてこのステートメントは「このテストメソッドではlogin_idとstateが必要であり、その他のカラムの値に関心はない」と読むことが出来ます。仮にこのテストが他のカラムも実は必要としている場合でも（テンプレートの作り方にもよりますが）Fakerによるランダムな値生成により安定したテストとはならないでしょう。 このようにテストデータをオーバーライドで柔軟に用意する仕組みは、同時にそのテストに本当に必要なカラムをすべて明示的に指定することをある程度強制する力があると思っています。（色々な要素が絡むのでこの辺りをハッキリ断言することはとてもとても気後れがあります・・・・・・・・・こういう使い方もある程度に捉えていただけましたら幸いです）そしてそれはテストの可読性を上げ、メンテナンスしやすいテストにする効果があると考えています。 FactoryBotをご存知のかたは「traitで属性の集合に名前つければいちいちテストメソッドで全部指定しなくて良い」といった指摘もきっとあるかと思いますが、もちろんそういったこともBASEでは行っています。ですが今回はFabricateの詳細な機能まで触れる記事ではないので割愛させていただきます。 弊社内の工夫 Fabricate v1はCakePHP2での利用を想定されたライブラリでした。しかしFabricate v2ではフレームワーク非依存を目指し、アダプタを書けばどのフレームワークでも動くことを目指されています。（ただしアダプタはCakePHP3用のもののみが用意されているので、それ以外で動かす場合はアダプタを自作する必要があります）弊社ではこのうちあえてv2を使用しています。 というのも以下の標語が頭をかすめたためです。 テストコードのライフサイクルはフレームワークのライフサイクルよりも長い 要するにフレームワークのバージョンアップ時にアプリケーションの振る舞いが変わっていないことを確認できるようにテストを書いているのに、バージョンアップと同時に動かなくなるようなテストでは本末転倒だという話です。なのでテストコードはフレームワークとは関係なく動かなくてはなりません。そのためにもわざわざCakePHP2用のアダプタを自作して、フレームワーク非依存のFabricate v2を選択しました。 まとめ テスト原則と照らし合わせながら現状の課題を整理し、目指す方向を見据えて弊社ではFabricateを導入しました。Fabricateはまだまだ機能があり、実テストを書く上ではそれらも使いこなさないと実際の運用に耐えるテストは書けないのですが、今回はBASEにおいて導入して感じたメリットを端的にまとめる形でこのぐらいで記事は締めさせていただこうかと思います。 BASEではサービスを成長させながら同時にテストを充実させてきました。そして今度はテストをスケールさせる過程で発生する問題をどう解決するかを考えるフェーズに既にあります。今回はテストデータを供給する部分の問題をFabricateというライブラリの導入によって乗りこえようと試みました。まだ導入したてで効果の程は測りかねますが概ねうまく行っている感触です。

こんにちは！ BASE BANK株式会社 Dev Divisionでソフトウェアエンジニアをやっている東口（ @hgsgtk ）です！7月13日（土）に福岡で開催された Go Conference'19 Summer in Fukuoka で登壇してきました。登壇内容や当日についてざっとレポートします。 Go Conference'19 Summer in Fukuoka - Go Conference'19 Summer in Fukuoka 登壇内容 Cost-effective Go unit test thinking and practices というタイトルで発表させていただきました。 個人的な観測では、Go界隈はユニットテストを書くことやテスタビリティの良いコードへの意識は強く、すでにユニットテストの技法に関する良資料はたくさんあるのですが、今回は WHY に着目した観点でプロポーザルを出して採択いただきました。 PHP界隈のカンファレンスでも ユニットテストの現場の問題を原則に立ち返って考える など、「ユニットテストを作る設計指針」なるものを考えてきました。しかし、Goでは"Proper error handling, reporting"や"table-driven testing"など公式的に提案しているような基礎的な考え方・技法があるといった特殊な点があったので、ユニットテストの目的自体に立ち返って「 Goのこの考え方・技法にはどのようなメリットが有るか 」というところから抑えた内容としました。 また、現場でGoコードのテストを実践していく中で基礎を忘れてしまうと、 Goが狙っている方向性からずれてしまったり、費用対効果の低い"資産価値の低いテストコード"が生まれてしまう 事があるなと感じていました。なので、実践例を示した上で「ユニットテストの目的」までつながる背景論理を発表内容に投写することを試みました。現場での実践に参考になれば良いなという願いを込めつつ。 業務で使用している方なら一度は触っているであろうものについての解説なので、期待感に答えられたか不安でしたが、twitterや懇親会などでいい反応をいただけました、安堵...。 テストの話よく整理されてて良かった #gocon — songmu (@songmu) July 13, 2019 Go の Unit Test の話を聞いてる。 @hgsgtk さんの理論から積み上げて最適を追求していく姿勢はすごいなぁといつも思ってる #gocon — po3rin 📖 技術書典7 golang.tokyo (@po3rin) July 13, 2019 参加して 今回、福岡でのGo Conferenceは初めての試みのようでしたが、初めてと全く思えない運営の方々のきめ細やかで大変満足感を持ってカンファレンスを終えました。 また、去年からPHPのカンファレンスに出ていくことが多かった私にとっては、お世話になっているPHPerの方々がちらほらいらっしゃる安心感がありました。 PHPerの @hgsgtk さんじゃん #gocon pic.twitter.com/vk0N55GkIz — せいけしろー (@seike460) July 13, 2019 PHPerの @cakephper さんじゃん #gocon pic.twitter.com/oVggjZWe84 — せいけしろー (@seike460) July 13, 2019 スピーカーディナー終了後は、同じく登壇されていて普段から交流のあった @budougumi0617 さん・ @po3rin さんと天神の屋台に繰り出すなど福岡を堪能できた一日になりました！ 次は さて、次回繰り出すのは7月24日〜7月27日にアメリカ・サンディエゴで開催される GopherCon です。 Building API Server-side architecture for beginners というタイトルでLTしに行きます。 www.gophercon.com 帰国したら現地レポートブログを公開するのでお楽しみに！