この記事はBASEアドベントカレンダー 21日目の記事です。 まえがき BASE BANK株式会社でエンジニア兼Engineering Program Managerをやっている 松雪(@applepine1125) と 永野(@glassmonekey) です。 BASE BANKでは組織の拡大に伴って表出した課題を解決するために、プロダクトのデリバリー、クオリティに責任を持つEngineering Program Manager(以下EPM)という役割を導入しています。 今回はまだ馴染みのないであろうEPMについてと導入の背景、具体的な働きざまについてご紹介します。 Engineering Program Manager(EPM) とはなにか そもそもEPMという役割自体が日本で馴染みのないものだと思います。 Apple やAmazon、Meta(旧FaceBook)社などで正式なポジ

この記事は BASE アドベントカレンダーと Looker アドベントカレンダー 8 日目の記事です。 はじめに BASE BANK 株式会社にて事業開発を担当している猪瀬 (@Masahiro_Inose)です。 私達のチームでは、BASE ショップを運営しているショップオーナー様が簡単に資金調達をできる「YELL BANK」というサービスの開発・運営しています。 thebase.in 今回の記事は以下の二部構成となります。 前半部分は私からLookerという BI ツールを使って、サービス利用者の利用状況や関連情報を一元的に把握できる、「ショップカルテ」なるものを作成したことについて紹介します。 後半部分は Looker で扱いやすくするためのデータの加工を担当した永野(@glassmonekey)から、データ基盤周りやデータ加工の工夫した部分について解説します。 ちなみに過去の記事の

こんにちは。BASE BANK 株式会社 Dev Division にて Manager をしている東口（@hgsgtk）です。 昨年 2020 年は本ブログにて個人の足し算ではなく掛け算で成果が出せるようなチームを目指したアジャイル開発の取り組みを継続して紹介してきました。 チーム開発の潜在的課題が見つかる振り返りワーク「Mad Glad Sad(喜、怒、哀)」 少人数でのアジャイル開発への取り組み実例 （一歩目の踏みだし方） | 詳説 | July Tech Festa 2020 登壇レポート アジャイル開発におけるユーザーストーリー分割実践 〜画面リニューアルの裏側〜 これらの考え方やプラクティスは全体の一部で、開発チームとしての組織ローカルなプラクティスを『BANK DEV 白書』として整理しています。『BANK DEV 白書』では次のような内容を整理しています。 一般的なアジャイ

for_each文を使ったTerraformのリソース定義に対してもimportができるよという話。 なお、「どうしてそのようなことをする必要があるのか？」を説明する前置きのほうが長い。 TL;DR terraformで新規に定義を作るときはterraform importから始めるのが良い 複数の開発環境などで柔軟に利用できるリソースを定義する場合は`文を使う https://www.terraform.io/docs/language/meta-arguments/for_each.html for_each文を使ったリソース定義にimportするときは配列表記を使う 対応するterraformのバージョンは0.13以上ならば問題ないはず。2021年07月時点最新版の1.0.x系でも動作する。 凡人がTerraformで新規リソースを最速で定義する Terraformで新しいリソースを

最高の夏を迎える中庭 前回の記事投稿からだいぶあいていますが、あいかわらずGAFAではない会社でソフトウェアエンジニアをしています。今回は最近の個人的な大仕事であった家を買った話を書きます。ちなみにこの記事にソフトウェアエンジニア要素はほぼないので釣りタイトルになります、ただプロダクト設計やプロジェクトマネージャー的な感覚は必要になって非常に面白かったです。 注意事項: この記事は素人の個人的な意見や感想です、また家に関して何が一番良いかは人それぞれなのでそういった議論もしません。 なぜ家を買ったのか？ 子供の小学校入学前であることコロナ禍であることで決断しました。元々、自分や妻のキャリアや子供のことなども含め賃貸で暮らしてきましたが、子供も大きくなり小学校入学前には持ち家を買いたいなと漠然と考えていました。大体2年前くらいから都内で4LDKの戸建てやマンションを探していて、実際に買う寸前

AWSはARMベースの独自プロセッサGravition2を採用したインスタンスタイプをEC2/RDS/Elasticacheなどで提供しています。 このたび、Amazon AuroraでもGravition2を搭載したR6gインスタンスタイプがパブリックプレビューとして提供されました。東京リージョンもプレビュー対象です。 Introducing Amazon Aurora R6g instance types, powered by AWS Graviton2 processors, in preview AWS Graviton2-based database instances are now available in preview for Amazon Aurora with PostgreSQL compatibility and Amazon Aurora with MySQL

概要AWS Glueの環境構築は過去の記事にあるのですが、公式のDockerイメージが案内されているので改めて、構築してみます。 過去の類似する内容の記事 AWS Glueの単体テスト環境の構築手順 AWS Glueの開発エンドポイントがそこそこお高いのでローカル開発環境を用意しました なお、Glueの公式イメージでもJupyter Notebookは利用できるのですが、使い勝手を考慮し、Jupyterlabに差し替えています。 手順 Dockerfile作成 docker-compose.yml作成 動作確認 DockerfilePySparkのオプションを設定しつつ、gluepysparkを実行していますが、gluepysparkがPySparkのwrapperになっているため、こちらの設定で問題なく動作しています。 Dockerfile# ベースとなる公式イメージ FROM amaz

こんにちは、2021年4月にfreeeに新卒で入社したberryです。 今年は5月末にほぼリモートの新卒研修が終わり、6月頭から新卒はそれぞれの部署に配属されていきました。私はQA配属となり、現在テスト技法やテスト自動化の勉強に勤しんでおります。 本記事では2021年6月23日にfreee株式会社と株式会社メルペイさん合同で開催されたイベント、【freee x メルペイ】QA Tech Talk 〜リリースを早めるQA〜について、理解のために各ディスカッションをまとめ、新人なりに考えた/感じたことを残したいと思います。 目次 上流工程で何をやってQAを早めているか QAの方たちは難しい仕様をどうやってカバーしているのか 先ほどメルペイさんの回答にあったQAのオンボーディングとはどのようなことをやっているか 開発中のテストでどういうことをやってリリースを早めているか 自動テストの実装はQAエ

フロントエンド連載の5記事目です。 HTML5が2021年の1月に廃止されました。 Webエンジニアとしてバリバリ活躍されてる方やエグゼクティブテックリードのような肩書きを持つ方にとっては「何をいまさら」という話題かと思います。 しかしながら、今年も新人さん入ってきてくださったので、プログラミングを学習中にHTML5という文字列に悩まされないように、そもそもHTML5とは何かや、廃止された経緯をまとめてみます。 HTML5とはWebサイトを作るときに必ず書くことになるHTML。Webサイトのコンテンツ、つまり中身や構造を作るために使うマークアップ言語です。 そして、その最近版として10年ほど前に登場したHTML5。当時は Webニュースなどで盛んに特集が組まれていましたが、このHTML5がついこないだ、2021年1月28日に廃止されました。 広義のHTML5 / 狭義のHTML5HTML5

ポッドキャスト Today I Learned FMの28 回目はメンタルヘルスの話題について話しました。この記事はその収録に関する追記です。 anchor.fm 「なんとなく元気がない」 = languishing www.nytimes.com "バーンアウトでもないし、うつでもない。けどどこか希望がない。なんか楽しくないし、目的ももてない。なんだかモヤモヤする。" この症状に対し、社会学者の Corey Keyes 氏は languishing という名称をつけました。日本語だと"衰弱"という意味ですが、要はゆるやかに不調になっている状態を指します。 languishing のやっかいなところは、これまで明確に言語化されていなかったために、症状として認識されていなかった点です。認識されていないために早期の対応が遅れ、やがて本当のうつに移行していく可能性が高いです。 元記事では、パンデ

こんな桃、見たことない。 川上に目をやれば、どんぶらこ。 洗濯をしていたおばあさんが見つけたのは、世界でいちばん大きな、桃でした。 このような桃は、わたしたちも見たことがありません。もちろんおばあさんも、見たことがありませんでした。山に柴刈りに行っていたおじいさんも、見たことがなかったはずです。流れてきたのは、本当に大きな桃だったのです。 Hello, Momotaro. 家に持ち帰って割ってみれば、中にはなんと、玉のような赤ん坊。 おじいさんもびっくり。おばあさんもびっくり。わたしたちまで、びっくり。 おじいさんもおばあさんも、最初は食べるつもりで桃を切ろうとしたのです。でも、中から飛び出したのは、元気な男の赤ん坊でした。こどものいなかったおじいさんとおばあさんは、おおよろこび。桃から生まれた男の子は、桃太郎と名付けられました。 身長は4倍、パワーは最大300倍。 元気いっぱい、すくすく

受け入れテスト駆動開発（ATDD）が2013年からどのように変化してきたかについて、デロイトトーマツコンサルティング合同会社執行役員のkyon_mm氏とBASE BANK株式会社テックリード兼マネージャーの東口氏がトークをしました。全4回。1回目は、ATDDの歴史とkyon_mm氏の試みについて。 ATDDについて8年越しのリプライ kyon_mm氏（以下、キョン）：今日のイベントについて説明します。みなさんconnpassでお集まりいただいたと思うんですが、1990年代に広まりはじめたTDD（テスト駆動開発）について、2013年くらいに私がちょっと話をしました。 先日、日本でも有数の優秀なエンジニアたちが集ってプレゼンテーションする「July Tech Festa」というカンファレンスの中で、東口さんがATDD（受け入れテスト駆動開発）のプレゼンテーションをしていたんですね。そのときに私

はじめに 株式会社ラクス チャットディーラー開発課のエンジニアRakusMoritaです。 2021年3月26日（金）～3月28日（日）開催のPHPerKaigi2021に、ラクスエンジニア7名が参加してきました。 phperkaigi.jp PHPer（ペチパー）によるPHPerのためのこの大規模イベントは、今年はオンラインでの開催でした。 オンラインでありながらも、豪華な登壇者、絶えず流れるコメント、主催者の勉強になるコントなどなど・・・ お祭り騒ぎのような雰囲気伝わってきて、ワイワイと非常に楽しい勉強会でした。 ラクスは当イベントのスポンサーとして参加させていただいている他、社内から2名が登壇しました。 この記事では、PHPerKaigi2021に参加した社内のエンジニアが、参加したセッションの内容をまとめましたので、ご紹介したいと思います。 各セッションのスライドも用意しております

こんにちは。SRE の @chaspy です。 Quipper の SRE Team ではじめて「オンボーディング」と呼ばれるものを行って約2年経ちました。 quipper.hatenablog.com その後、3人の仲間が入社し、そのたびにオンボーディングプロセスを改善してきました。 本記事では、SRE Team のオンボーディングプロセスの"いま"を振り返るとともに、その効果や意義を、オンボーディングを受けたメンバーからのコメントを交えて紹介したいと思います。 オンボーディングの目的 あらためてオンボーディングの目的について言語化しておきます。これは今も昔も変わっておらず、「New Joiner の早期の戦力化」だと思っています。 早期の戦力化のためには何が必要か、ということを考えると、現在のチームのミッションから普段の業務へブレークダウンし、それらをスムーズに遂行するために何が必要か

※以下の記事は研修の内容を伝えることを意図したものではなく個人的な感想と学んだことを記載したものです。 Agile Testing for the Whole Team 研修 3/1~3/3の3日間で、アギレルゴコンサルティング主催のオンライン研修「Agile Testing for the Whole Team」に参加してきた。 www.jp.agilergo.com 講師は Janet Gregory（@janetgregoryca） さん。『実践アジャイルテスト』の著者の一人で、最近では『Agile Testing Condensed』という書籍も執筆している（こちらについても既にブロッコリーさん（id:nihonbuson） による邦訳がある）。 実践アジャイルテスト: テスターとアジャイルチームのための実践ガイド 作者:リサ クリスピン,ジャネット グレゴリー翔泳社Amazon

こんにちは！ BASEのInformation System(情シス)に所属している横山です。 さっそくですが、BASEでは毎月全社定例を行っています。去年から続くコロナ禍の中、以前までは当たり前のようにやっていたオフラインでの集会も難しくなっています。そしてWork From Homeの継続に伴い、全社定例はより重要なイベントになっています。 「今後すぐに在宅勤務がなくなることはないだろう。」 「月に一度の全社定例がより大事なコミュニケーションの場となるので、アップデートしたい。」 そんな想いで全社定例をより良くするために本格的な配信環境を整えて開催しました。 今回はその様子を振り返りたいと思います。 今までの全社定例では コロナ禍の今、100人以上の社員が出社し集まることは難しくなってからは、Zoomのウェビナー機能を使ってやっていました。 Zoom ウェビナーを使った全社定例 こちら

こんにちは！株式会社VOYAGE MARKETINGで働くエンジニアの yopidax です。 約20年ほど続くサービス、ECナビの技術的負債の返済に取り組んでいます。 ecnavi.jp 今回は直近で、レガシーコードを大量に削除したので、そのアプローチをご紹介したいと思います。 目次 目次 解析の対象と抱える課題 アプローチ 実行されるファイルを洗い出す ログを出力するモジュール 実行 ログのサンプル いざ、大量削除 Perlファイルをgrepする リリース単位を細かくする 結果 工数 実績 まとめ 合わせて読みたい 解析の対象と抱える課題 ECナビを長年支える、Perlで書かれたバッチが対象です。コードはGitLabのリポジトリで管理されていて、規模をまとめるとこんな感じです。 ファイルの数 バッチ関連全体 : 3,315 うち、Perlファイル(.pm, .pl) : 1,111 P

こんにちは丸山@h13i32maruです。システム全体を簡単な図とテキストでまとめる「ARCHITECTURE.md」というものを最近知りました。これは良さそうと思い、JasperのARCHITECTURE.mdを書いてみました。 jasperapp/jasper/ARCHITECTURE.md ARCHITECTURE.md自体の目的は「プロジェクトへの新規参加者が全体像の把握を効率的に行えるようにする」という感じです。書き方の指針や注意点などは考案者による記事を見てもらうのがよさそうです。また良いサンプルとしてrust-analyzerというOSSのARCHITECTURE.mdが紹介されています。 https://matklad.github.io//2021/02/06/ARCHITECTURE.md.html https://github.com/rust-analyzer/ru

以前から、インフラそのものの構成管理にはTerraformを利用しています。主にAWSのリソース管理に使っていて、Terraform自体はaws-sdkのラッパーみたいな感じなのですが、宣言的に構築できるので、複製が容易であったり、変更に必要な操作（modify系のAPI実行）を意識せずに、こうなってほしい、を記述することで、現状から必要な操作を計算してAPIを叩いてくれたりというメリットがあります。 で、実際に変更したい状態にするために、Terraformが何を行なうか、については「terraform plan」というコマンドで確認できるようになっています。まぁdry-runみたいなものなのですが、あくまでもTerraformの実行計画上のdry-runであって、aws-sdkのdry-runではないというのが結構困りポイントです。 具体的には、Terraform上で別のリソースの値を参

みなさんこんにちは。@ryuzeeです。 プロダクトバックログアイテムは、複数スプリントにまたがって1つのものに着手することはありません。 必ず、1スプリントで完成できる大きさになっている必要があります。 これは、複数にまたがってしまうと変化に柔軟に対応できなくなること、成果の量の把握が難しくなること、大きいものを扱うのはそもそも難しいことなどが理由です。 そのため、プロダクトバックログアイテムがプロダクトバックログのなかで上位になっていくにつれて、リファインメントなどを活用しながら、適切なサイズに分割していきます。 最初の段階から細かく分割してしまうと、変化に対応しにくくなったり、数が多くなりすぎて管理しきれなくなったりするので避け、着手が近づいてきたらジャスト・イン・タイムで分割していくのがポイントです。 こうすることで、チームの成長にあわせてプロダクトバックログアイテムのサイズを変え