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

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

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

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

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

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

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

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

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

この記事は 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に別の知見を持ってこれるように、日々のサービス開発に精進していきたいと思います。 では、またっ。