こんにちは! BASE BANKの松雪です。 来る2023/06/02(金)にオンラインでGo Conference 2023が開催されます。 我々BASE株式会社(BASE BANKチーム)は Goルドスポンサー で協賛し、スポンサーセッションにて1名登壇します! Go Conferenceとは Home | Go Conference 2023 GoCon2023 ※ The Go gopher was designed by Renee French. Illustrations by tottie. Go Conferenceは一般社団法人Gophers Japanが主催しているプログラミング言語Goに関するカンファレンスです。 今回10周年を迎えます。おめでとうございます! BASEでGoって使ってるの? ネットショップ作成サービス「BASE」のバックエンドはPHPで実装されており、 PHPerKaigi などPHPのカンファレンスに協賛、登壇しています。 しかしそれだけではなく、BASEのショップオーナー向けの金融決済事業を展開しているBASE BANKチームでは、資金調達サービスである「YELL BANK」、ショップの売上金をVisa加盟店の決済で利用できる「BASEカード」にてGoの分散サービスとして長く実装、運用をしています! thebase.com basecard-lp.thebase.com 登壇内容 次なるrouterパッケージ選定のしざまと決め手について by @Ren Ogaki https://sessionize.com/api/v2/jmtn42ls/view/Sessions 先日Goの軽量routerの代表格であるgorilla/mux擁するGorilla Web Toolkitがアーカイブされました。 私たちのチームで開発しているGoのWeb APIはすべてgorilla/muxに依存しており、対応を迫られました。 フォークしてチーム内でメンテナンスを行うことも考えられましたが、チームの規模的に無理があり他のパッケージへ移行する必要がありました。 そこで今回の発表では移行時に行った他のパッケージの比較検討や最終的な決断の意思決定について話します。 この発表を通してパッケージの選定基準などについて、同じくrouterや外部パッケージを移行したい方の手助けになれば幸いです。 router移行を主導した話をします！ あまり起こることでもないので知見が溜まりづらい領域と思いますが、次にこういったことが起こったときに皆さんの役に立てる発表になればと思っています。 オフィスアワーも開催します! イベント当日はreBakoにて、オフィスアワーを開き参加者のみなさんをお待ちしております。 オフィスアワー中の弊社ブースでは常時エンジニアがおりますので、 直近話題になったGo関連のトピック・ブログ記事について BASE BANKでGoをどうやって使っているか BASE BANKのプロダクトって? などなど、是非気軽にお話しましょう! 宣伝 BASE BANKチームでは、フルサイクルエンジニアとして、Go, Python, PHPを中心にフロントからインフラまでを一気通貫で開発~運用を行っています。 それだけでなく要件定義から分析、ユーザーサポートまで一連のソフトウェアライフサイクルに主体性を持って関わることができます! devblog.thebase.in BASE BANKの働きざま、Goについてなど話を聞いてみたいという方は以下のリンクから気軽にご連絡ください! youtrust.jp それでは当日にお会いしましょう!

こんにちは！BASE株式会社 上級執行役員の藤川です。今年からTech DepartmentというBASE社の開発の成功や情報システム、セキュリティ等に責任を持つチームを運営しています。 システム障害はWebサービスを自社運用する企業にとって最重要な問題であり、サービス改善のきっかけになることも多々あります。ただ単に目の前の問題を場当たり的に解決するだけでなく、再現性を減らすために体制やシステム投資の見直しなどにもつながるきっかけになるものなので、そこで起きている本質的、潜在的な課題を見つけ出すことも障害対応の重要なミッションです。 また事件は現場で起きているわけで、障害要因となるものは、何もバグやシステム設定の不足や不備などに基づくものだけではありません。インターネットの世界が日常的に変化しているので、外乱としての障害要因も多々存在し、これらの問題と常に戦っています。 そういう不確実な状況下で、障害に対する対応力を培うことはWebサービスのエンジニアにとっては重要な成長のチャンスです。必ずしも自分が把握しきっていないシステムであってもエラーログやシステムの挙動を見ながら、起きている事象を予想しながら解決すべき問題にあたりをつけていく力は、Webシステムのスキルをひろげる絶好のチャンスです。このスキルは、どんな開発言語であろうと関係なく、どの会社に行っても生きる経験であり、Webサービスエンジニアの基礎力とも言えます。 最近のBASE開発チームは、事業テーマに応じて開発チームが分かれ始めていますし、BASE BANKやPayID、AIチームなど担当するリポジトリそのものが分かれていたりして、以前のようなモノリシックな体制から分散型の開発運営体制に移行しています。 そのような状態で適切な部署に障害対応がエスカレーションされるようになると、障害対応に慣れているチームとそうでないチームが分かれてきますし、また、毎月中途入社がいるようなチームであれば、日常のフローがわからない人が常に存在することから、障害発生時の対応フローを決めてほしい、という言葉が頻繁に出てくるようになります。 更に、我々が特性として持つ、お客様の情報を守るWebサービスプラットフォームという視点、クレジットカードなどの決済を提供するサービスという視点において、ステークホルダーが多いのも特徴で、ただシステムとしてのサービスを復旧するだけでなく、そこで起きている事象をしっかり分析し、ショップオーナーさん、関係省庁やパートナー企業への報告が必要ではないか？なども常に精査する必要があります。 これらをスムーズに実行するために、開発、CS、渉外担当、法務、営業などが集まって議論を行った結果として、障害対応フローを整えることにしました。それが以下の図です。 base-incident-flow ステップとしては、 障害初期調査 初期対応決定 障害対応（アクション） クロージング で構成されます。 0.障害発生 主たる障害発覚の入り口は下記の誰かであることが多いです。 ショップからの問い合わせ システムアラート ショップから営業担当への連絡 主になんらかの経路でエンジニアやCTOやVPoPに直接連絡が来ることが多いです。slackの#incidentチャンネルが作成され、共有チャンネルで全社に共有されます。incidentチャンネルが作られると100人以上の関係者が自動的にチャンネル登録されるようになっていて、とりあえずワラワラと人が集まってくる体制が整います。 ちなみに、チャンネル登録の自動化は、個人の裁量で参加の判断をしてもらってるので、そんなにincidentチャンネルにとりあえず参加する人がいるんだと言うことには驚きです。 1. 障害発見後の初動フェーズ ここが最重要なフェーズとなります。 ここで如何に適切な関係者に話を広げられるかが、リスク対応の範囲と対応スピードを決定します。 やはりエンジニアはシステム復旧に意識を集中したいものであり、そっちに関心が行ってしまいますので、ついつい別の話はしずらかったり声もかけづらいものです。 一方で、個人情報流出にまつわる意思決定は１分１秒を争います。過小でも過剰でもない情報把握をするための的を絞っていくことが求められます。 そのためシステム復旧と並行して、これを実現するために障害対応は別に、インシデントの対応を別途に行うチームを整理しました。incidentが発生し、個人情報にまつわる懸念がある場合、なんにせよ一旦、エスカレーションしてもらう流れを整えています。 2. 初期対応決定 フェーズ１では、わらわらと集まってきた人たちで議論をしながら問題の把握をし、その後、復旧に繋がっていくのですが、ここで一度、集まって議論を整理するタイミングを入れてほしいというのを伝えています。 システム復旧だけなら勝手知ったるエンジニアだけで対処可能なのですが、もうちょっと範囲が広がった場合、足並みをしっかり整えていかないと適切な対応ができない可能性があるからです。 急がば回れという言葉がありますが、初動の足並みを揃えるのはとても重要です。また、意思決定者、リーダーを決めて、その人を中心にincidentのマネジメントの旗振りをしていくことも求められます。 3. 障害対応、アクション システム改修・パートナーやお客様、関係者への連絡の段取り データ修正、返金対応等・関係省庁への連絡など 広報の調整等 対応方針が決まったら、あとは各役割のプロフェッショナルに作業が移譲されていきますので、エンジニアは各チームが動きやすくなるようなデータの準備などを行います。 余談ですが、さまざまな情報を集めて集約する時には、GoogleスプレッドシートやExcelの関数やピボットテーブルで分析することが多いですが、昨今はChatGPTで実現したいことに対するプログラムを出力したりして非常に役に立ちます。 主にやることはCSVに落としたデータを読ませて、大量のデータを名寄せしたり整理したりする作業なので、慌てているときに落ち着いてコードを書いてる状況でもないことから、かなり助かります。 4. クロージング 関係者のふりかえりの実施 incidentドキュメントの完成 マネージャmtg / 経営会議等への報告や再発防止に関する議論 障害対応が終わったら、振り返りをし、再発防止策等を議論します。 もし、開発の優先順位を変えてでも対応が必要になるようであればビジネスチームとの調整や議論は必須です。そして、技術的負債の返済と同じか、それ以上に再発防止策をしっかり議論し、今やること、これからやっていくことをしっかりまとめて実行していくことが大切です。 ここで物事をスルーすると絶対に後悔するので、しっかり優先順位の整理をします。 あとがき：タイトルの意味とお気持ち 最後にタイトルに書いた意味と、自分の気持について述べておきます。サービスに携わる人数が増えてくると障害に対する感度がちょっと落ちてしまい「どうせ誰かが対応してくれるだろう」となりがちなところがあります。 システム復旧にとどまらず、ステークホルダーへの考慮すべき点が増えてくると、障害発生時の検討のレベルが一段、複雑になってきます。ここでどれだけ自分が全体視点で前のめりに踏み込めるか？がすごく大切だと思っていて、自分が前のめりに踏み込むためにも、あえてワークフローを設定したというのもあります。 特にリモートワークで仕事しているときに発生した障害は、飛び込むための関心のエネルギーが、普段以上に必要な時があります。slackを見て、誰かがシステム復旧してるなってことを確認だけして、パソコンを閉じてしまえば目の前から事象は消え去ってしまうわけです。でも、そこで適切に判断しなかったことが、あとからツケとなって返ってくることもあり、やはり都度都度、影響範囲をしっかり議論し、「それほど問題ではない」ということをしっかり確認し、そうでなければリスクを洗い出し、管理することが必要だなと思いました。 Webサービスというソフトウェアの固有の事象として、毎日、何回もリリースするという特徴がありますが、言い換えると毎日システムを壊すきっかけを生み出していると言い換えることも不可能ではありません。そのリスクと戦うことがWebサービスのスピード感を実現するわけで、常にトレードオフを迫られています。 その中でやむを得ず起きてしまったシステム障害についての問題解決は、そこに携わるメンバーの技術力や対応力を育てるという成長の機会と考えることも可能です。Webサービスに携わる方々は、是非、前のめりに問題解決に勤しむことをおすすめします。

はじめに フロントエンドエンジニアの @mk0812 です。自分は普段BackOfficeというチームで新規機能開発を担当しています。 2023年3月〜5月あたりで社内の有志を集めて、Webアクセシビリティの勉強会を行いました。この記事はその勉強会の振り返りをしていきます。 ⁠参加者 ⁠フロントエンドエンジニア: 4名　 デザイナー: 4名 ⁠勉強会で使用した参考書 Webアプリケーションアクセシビリティ──今日から始める現場からの改善 (WEB+DB PRESS plus) なぜアクセシビリティの勉強会を実施したか 私自身が今回、この勉強会の主催をやりました。私が実施した動機としましては下記にあたります。 フロントエンドの実装であまりアクセシビリティを意識してこなかった WAI-ARIAが定めた仕様に基づくHTML属性（例: aria-label 属性）をなんとなく使っている部分がある もっと社内でアクセシビリティを広めていきたい これらの動機を踏まえて勉強会を実施しました。 実施するにあたっての参加者の経緯 勉強会にあたってまずは人集めというところですが、上記に記載ある通り8名ほど勉強会に参加してくださりました。有志で集めた際にアクセシビリティの勉強会に参加した経緯を聞きました。 参加した経緯 ↑のようにfigjamを使ってディスカションをしながら勉強会を行った ⁠エンジニア視点 アクセシビリティ気になりつつあまりちゃんと勉強したことない 利用できるユーザを増やすためには「正しいHTMLの書き方=それがアクセシビリティにつながる」と思ったから ⁠デザイナー視点 マシンリーダブルに作るための前提知識が少ない、デザインを起こすときにどういう部分に意識すべきかわからなかった ユーザインタビューなどのリサーチを通じて興味を持ったから このような感じでエンジニアとデザイナーで勉強会に参加した経緯は違います。しかし今後取り組むにあたって、エンジニアとデザイナーの共通言語ができて、品質の良いデザインやコードが作れていけばいけるように頑張ろうかなと思いました。 勉強会の形式 figjamを使ってオンラインでやりました。 毎週1時間くらい 全8回くらいやりました。 勉強会の一例が下記のような感じです。毎回ではないですがディスカッションのテーマを考えて、BASEの今後の活動に少しでも役に立ててもらおうと工夫しました。 勉強会の流れ ⁠振り返り この勉強会で意識した点は下記2点になります。 ディスカッションの頻度を増やす BASEの現状あるUI/UXから改善点を探る ディスカッションの頻度を増やす 上記の「勉強会の形式」でも触れましたがディスカッションのテーマを考えて、事前にディスカッションのネタを用意しました。 下記添付画像はディスカッションの例になります。勉強会の後半部分はこのような感じで各章のテーマに沿って皆さんが「話す」「考える」「次に活かせる」といったいわゆる『参加型』を意識しました。 ディスカッションの流れ ディスカッションを通じて、私自身が実は知らなかったことがたくさん気づいたところでもありました。普段の画面確認などはあまりキーボード操作などを意識しなかったのですが実はその操作の中で改善点があったりと...さまざまな意見が出てとても良いディスカッションになりました。 BASEの現状あるUI/UXから改善点を探る 本に沿って、BASEが提供してるサービスそのもので使用してるコンポーネントが使いやすいかどうかをみなさんで議論して改善策を探ったりしました。 例えば第5章で「複雑なUIパターンの改善」という章があります。ここでは モーダル ⁠通知 ⁠ツールチップ などとある程度どのサービスでもあるようなコンポーネントとなりますが、これらのコンポーネントがきちんとアクセシビリティに配慮してるか、勉強会に参加した皆さんとUI見て探ったりしました。またこの本にはサンプルコードが載っていたのでサクッと試したりもできてとても助かりました。 ⁠感想 勉強会を終えて感想を参加していただいた皆さんからもらいました（下記添付）。 参加者の感想 ⁠エンジニア視点 セマンティックなHTMLを完全理解した。レビューの時もアクセシビリティを意識していきたい。 フロントエンドの知見が深まった、サンプルコードを踏まえてとても理解が深まった ⁠デザイナー視点 BASEのデザインを知るいいきっかけになった 普段プロジェクトに閉じたデザインしか見てなかった、全体のデザインを触れられてよかった ⁠全体 改善案を出すワークで結構意見が出てきたりしたので、アクセシビリティに限らず何かテーマを絞って、みんなが普段考えているBASEの改善点を話すのはいいのではないか 内容も濃くて、全員受けてもいいんじゃないというくらい良い内容だった 他職種の見解が聞ける機会（エンジニア⇄デザイナー）があったのはよかった まとめ BASEのミッションは「 Payment to the People, Power to the People 」を掲げています。そのミッションの中に「世界のすべての人に」というフレーズがあり、BASEを使っていただけるショップオーナーをはじめ、「どんな人でもショップオーナーになれる」ためにはやはりアクセシビリティ対応は不可欠だと思っています。 また私をはじめとしてアクセシビリティに対しての課題などを話し合ってちょっとずつではありますが、改善していく動きをしています。この改善を続けて良いサービスを作り上げていこうと思います。 以上です、最後までお読みいただきありがとうございました。

はじめに こんにちは、BASEのPay IDチームでAndroidエンジニアをしている 小林( @eijenson )です。 ショッピングアプリ「Pay ID」のAndroid版アプリの開発を担当しています。 本アプリでは2023年4月にあと払い（Pay ID）という、新しい決済方法の支払いに対応したアプリをリリースしました。 「あと払い（Pay ID）」を提供開始　新たな自社決済ネットワークへの第一歩 これらの機能はJetpack Composeで実装していますが、その際に解決に時間のかかった箇所の紹介と、解決した内容を紹介していきます。 使用言語/ライブラリのバージョン Kotlin 1.7.10 Jetpack Compose 1.3.0 Paging 3.1.1 paging-compose 1.0.0-alpha17 navigation-compose 2.5.2 1.非Compose画面からCompose Navigationを使って引数付きの画面に遷移する Compose間の画面遷移はCompose Navigationを使うと楽に書くことができます。 https://developer.android.com/jetpack/compose/navigation?hl=en @Composable fun NavigationApp( val startDestination: String /*最初の遷移先*/ ) { val navController = rememberNavController() NavHost(navController = navController, startDestination = startDestination) { composable( "profile" , ) { ProfileScreen( onNavigateToFriends = { navController.navigate( "friendsList" ) }, /*略*/ ) } composable( "friendslist" ) { FriendsListScreen( /*略*/ ) } } } これで、Profile画面からFriendList画面への遷移が実現できます また、例えばリスト画面から1つの詳細画面に飛びたいといった場合、itemId等の引数が必要になることが多いです。 その場合は url/{itemId}といった形で引数を渡すことができます. @Composable fun NavigationApp( val startDestination: String /*最初の遷移先*/ ) { val navController = rememberNavController() NavHost(navController = navController, startDestination = startDestination) { composable( "profile" , ) { ProfileScreen( onNavigateToFriends = { navController.navigate( "friendsList" ) }, /*略*/ ) } composable( "friendslist" ) { FriendsListScreen( onNavigateToFriends = { navController.navigate( "friend/1234" ) }, /*略*/ ) } composable( "friend/{itemId}" ) { FriendScreen( /*略*/ ) } } } 問題 しかし、Pay IDアプリは現状全画面がJetpack Navigationに移行していないため、非Compose画面からのCompose Navigationの画面遷移をすることになりました。 そこで問題になったのが、今回の機能は最初の遷移した画面から、引数が必要な画面ということでした。 アーキテクチャの原則として、アプリが最初に遷移する画面は固定であることが望ましく、それに準ずる形でCompose Navigationの制約で最初に指定する画面は固定である必要があります。 Android developers ナビゲーションの原則 Composeを使用したナビゲーション#NavHostの作成 画面遷移をJetpack NavigationやCompose Navigationに完全移行している場合は、NavHostが遷移する最初の画面が起動時の画面になるため、問題は無いです。 ですが、今回は途中からCompose Navigationを使うため、この制約に引っかかりました。 @Composable fun NavigationApp( val startDestination: String = "friend/1234" /* friend/1234に最初に遷移したい*/ ) { val navController = rememberNavController() NavHost(navController = navController, startDestination = startDestination) { /* 略 */ composable( "friend/{itemId}" ) { FriendScreen( /*略*/ ) } } } freind/1234の画面に直接遷移しようとした場合にはstartDestinationにfriend/1234を指定したいのですが、そうすると java.lang. IllegalArgumentException : navigation destination friend / 1234 is not a direct child of this NavGraph というエラーが表示されて失敗します。 解決策 調査や試行錯誤をした結果、 composable( "friend/itemId" , arguments = listOf(navArgument( "itemId" ) { type = NavType.StringType; defaultValue = "1234" }) ){ /* 略 */ } のように item_idを/{itemId}ではなく/itemIdにする argumentsにを設定し、defaultValueに最初に遷移したい値を指定する と期待した動作になりました。 前述のとおり、Navigation Composeでは初期遷移は固定の想定なので、ライブラリのバージョンアップによって動きが変わってしまう可能性があります。 今後もJetpack Composeへの移行と遷移処理をNavigation Composeに寄せる作業を進めていき、こちらの書き方は変えていく予定です。 2.スクショ禁止や明るさMAXをJetpack Composeで実現する あと払い（Pay ID）ではコンビニで支払いを行うためのバーコードを表示しています。 その際にトラブル防止のためにバーコードをスクリーンショットをできないようにしていたり、読み取りやすいように画面の明るさをMAXにしたりしています。 val window: Window? = activity.window // 画面をONのままにする と スクリーンショットを撮れないようにする window?.addFlags(FLAG_KEEP_SCREEN_ON or FLAG_SECURE) // 輝度を最大に指定する window?.attributes?.screenBrightness = BRIGHTNESS_OVERRIDE_FULL 問題と解決策 しかし、この設定は同じActivityの違う画面上でも明るい状態になってしまいます。 そのため、画面を閉じた際には明るさの設定等をもとに戻す必要があります。 Jetpack Composeの画面表示で、画面が閉じられたことを検知するにはDisposableEffectのonDIsposeイベントを使用します。 https://developer.android.com/jetpack/compose/side-effects?hl=en#disposableeffect そういったことを含めて、コードに表すと以下のような実装になりました。 @OptIn (ExperimentalMaterial3Api :: class ) @Composable fun MyScreen( viewModel: MyViewModel // 略 ) ){ val activity = LocalContext.current.findActivity() val uiState by viewModel.uiState.collectAsState() if (uiState is MyViewModel.UiState.Success) { activity?.let { activity -> val window: Window? = activity.window // 輝度を最大に指定する window?.attributes?.screenBrightness = BRIGHTNESS_OVERRIDE_FULL // 画面をONのままにする と スクリーンショットを撮れないようにする window?.addFlags(FLAG_KEEP_SCREEN_ON or FLAG_SECURE) } DisposableEffect( Unit ) { onDispose { activity?.let { val window: Window? = activity.window // 輝度を指定しない window?.attributes?.screenBrightness = BRIGHTNESS_OVERRIDE_NONE // "画面をONのままにする と スクリーンショットを撮れないようにする" の設定を解除 window?.clearFlags(FLAG_KEEP_SCREEN_ON or FLAG_SECURE) } } } // uiStateに応じたUI表示処理等 } uiStateはFlowのStateFlowを用いてAPIの実行結果を受け取れるようにしています。 ロード中や通信失敗時に明るくなったりスクショが撮れないようになったりしないように、通信成功時のみ設定を有効にしています。 3.ページングの最後項目取得 リストの一番下の要素にだけレイアウトを変更したいという事になり、最後の要素を検知する必要がありました。 そのため、 val pagingList = currentState.pagingData.collectAsLazyPagingItems() LazyColumn() { items(items = pagingList, key = { it.id }) { item -> val isLast = pagingList[pagingList.itemCount - 1 ]?.id == item.id, if (isLast){ // Text()等 } /* 略*/ } } のように実装していました。 問題 しかし上記のやり方は良くなかったことがわかり、pagingのListは要素にアクセスしようとした際にそれが最後間近の場合、Pagingライブラリ側の必要に応じて追加読み込みをします。 つまり、 pagingのリストの最後にアクセスする 追加読み込みする Composeの描画のため、isLastの判定するためにpagingListの最後の要素にアクセスする 追加読み込みが発生する 繰り返す と、全ての要素を読み込む事になってしまいました。 解決策 そのため、最後の要素かどうか判定する処理を少し変えました。 val isLast = pagingList[pagingList.itemCount - 1 ]?.id == item.id, // ↓ val isLast = if (pagingList.loadState.append.endOfPaginationReached){ pagingList[pagingList.itemCount - 1 ]?.id == item.id } else { false } endOfPaginationReachedは通信による情報の取得の結果、中身が空だった場合にtrueが返ってくるので、判定に使用しています https://developer.android.com/topic/libraries/architecture/paging/v3-network-db?hl=ja#implement-remotemediator 補足 実装時は上記のような書き方で解決をしていましたが、本記事を書くにあたり、より調べてみたところ val isLast = pagingList.itemSnapshotList.lastOrNull()?.id == item.id のようにすれば同じように追加読み込みが発生することなく判定ができました。 今までのは、全てを読み込んだ最後にしか最後用のレイアウトは適応できなかったです。 ですが、こちらは、現在のリストの中で最後の要素かどうかを判定できるため、 1ページ目の最後の要素に最後用のレイアウトを適応する 追加読込して、2ページ目の結果を表示した際には2ページ目の最後の要素に最後用のレイアウトを適応する とページそれぞれのタイミングでより適切なレイアウトを表示することができます。 まとめ 今回は、Jetpack Composeで機能を実装したときに困ったところとその解決策をいくつか紹介しました。 記事では大変だった箇所ばかり紹介していますが、Jetpack Composeは全体的には書きやすく、RecyclerViewやConstraintLayoutといった、汎用性は高いが使いこなすのに時間のかかるものを踏まえて、かんたんに似たようなことをできるようにしようといった雰囲気を感じることのできる良い仕組みだと思います。 これからも機能や対応レイアウトが増えていくのが楽しみです。 おわりに 最後になりますが、BASEではAndroid/iOSのエンジニアを募集しています。 興味のある方はぜひ気軽にご連絡ください！ Android: 採用情報 iOS: 採用情報

BASEのCartDevチームでバックエンドエンジニアをしている遠藤( @Fendo181 ) です。 自分が所属しているCartDevチームは主にBASEにおける決済開発を担当しております。 購入者様が商品を購入する際の決済だったり、オーナー様が利用するカート機能周りの開発、保守運用を行ってます。 今回、この記事では自分が所属するCartDevチームの取り組みを紹介する「月刊CartDev」というドキュメントを作った経緯や、運用方法について紹介します。 また、実際に社内で共有してみてどのような反応があったかについても書きます。 月刊CartDev が作られた背景について 月刊CartDev が作られた背景には2つ理由があります。 (1) 遠藤( @Fendo181 ) がそもそも入社したばかりで、CartDevでの働き方を理解したい。 (2) CartDevチームで取り組んでいる内容をチーム内で閉じるのではなく他部署に知見を積極的に共有して、他チームでも改善できる体制に貢献したい。 (1)はそのままの理由です。 (2)の理由についてはお話する前にまずCartDevチームの成り立ちについて説明します。 CartDevチームが作られた背景について CartDevチームはBASEの中でも 目的別組織 として作られたチームであり昨年の2022年の7月に結成しました。 BASEにおける「目的別組織」を少しだけ説明すると、特定の領域や機能に対してチーム全体が継続的に運用を行い、責任を持つ組織体制の1つになります。 CartDevチームが結成される前はカート機能の開発を行う専任チームはなく有志的に集まったメンバーが担当したり、お問い合わせ対応を行っていました。しかし、このままではスケールの面でも好ましくないということでカート機能の開発と保守運用に責任を持つ為に作られました。 CartDevチームの成り立ちについて以前テックブログで公開された以下の記事も参考になるので一部記述を抜粋します。 BASEの課題としてEOLを迎えたフレームワークからの移行を進めています。その中でもカート機能はまず初めに移行が完了した機能になります。ですが、移行して終わりではありません。サービスは成長していくので併せて機能を改修していく必要がありますが、新しいアーキテクチャを理解せずに間違った方向で改修が進むと複雑な負債を生み出してしまう可能性もあります。またアラート対応やパッケージ更新などの日々の運用もあり下記のような課題がありました。 新しいアーキテクチャをどう適切に開発していくのか？ アラート対応やパッケージ更新などの運用はどうするか？ 上記の課題をカート機能をリニューアルしたエンジニアが有志的に対応していましたが、スケール面において好ましくない状況だったため、カートチームとし>て組成して、開発・運用・グロースを含めて責任を持つのが望ましい形なのではないかと考えた結果、リニューアルしたエンジニアを集めてカートチームが誕生しました。 ref: カートチームを振り返る - BASEプロダクトチームブログ 上記の背景もありCartDevチームは他のチームと違い後述する Sentry の監視体制だったり、 Dependabot を使ったライブラリのアップデートに関して意欲的に取り組んでおります。 そういった取り組みは仕組みだけではなく、チームメンバーによる独自の文化が根付いていると配属してから感じました。 同時に、CartDevチームで出来ている事が、事情によって他チームでは出来ていない課題も気づきました。 こういった状況がある中でCartDevチームで取り組んでいる技術トピックを共有し、他チームにもCartDevチームの良い部分を積極的に取りくめる様に情報共有したいと思い「月刊CartDev」を作成しました。 CartDevで紹介した内容について 次に「月刊CartDev」でどんな内容を共有しているか説明します。 前述したように Cart DevチームはBASEの決済領域に関わる問題に対して責任を持ち、運用しております。 具体にこれは 担当大臣（運用業務) という名目で現在4つあります。 Dependabot担当大臣 Dependabot を用いた追従活動。 Dependabotによって届くライブラリアップデートの通知を確認し、定期実行や誰かが手動実行した際にも発生するPullRequestを確認し対応する。 Sentry担当大臣 Sentry の治安維持活動。 SlackでSentryのアラートが流れてくるチャンネルを見たり、メール通知を確認して対応する。 メンテナンス担当大臣 外部決済会社のメンテナンスエラーからの防衛活動 メンテナンスの連絡を毎回確認し、必要と判断した場合にメンテナンスの設定および 、 NewRelic アラート の ON / OFF を行う。 cs_q担当大臣 CSチーム経由で届くオーナー様からのお問い合わせ対応活動。 お問い合わせを起点に、 CartDevチーム宛てに飛んでくる調査依頼や仕様の質問などを NewRelic や Asana を使って一次対応する。 この4つの担当大臣を1ヶ月ごとにローテーションしながら各メンバーで対応するように現在運用しています。 また上記の「担当大臣」以外にもCartDevチームのメンバーが実際にプロジェクトで行った改善や、リリースした機能のPullRequestも取り上げて共有しました。 数値を計測して共有する 上記の担当大臣（運用業務)で紹介した4つの項目については対応時の計測値を共有しています。 Dependabot担当大臣で管理するPull RequestはGitHubで管理しているのでGitHubの検索で期間やラベルでフィルタリングして、Dependabotで作られたPull Requestがどれだけマージされているか?を計測できます。 以下は2023年1月辺りのDependabotで作られたPull Requestがマージされた数が取得できます。 is:pr is:closed label:dependencies merged:2023-01-01..2023-01-31 Sentry担当大臣の場合も簡単に計測ができます。 Issuesページから日付を指定できるので、その機能を使って絞り込みを行い計測をしています。 Sentryはただ対応した数を載せるよりも いかに早くアラートを検知してすぐに対応している様子 を伝えるのが大事だと思ったので、数だけではなく実際のSlackでのやりとりのキャプチャーも載せるようにしました。 メンテナンス担当大臣は、社内のドキュメントツールで活用している Kibela にまとめられるので対応数だったり、具体にどんなメンテナンスを行ったのか?を紹介しました。 cs_q担当大臣はAsanaの 高度な検索 を使って計測が可能でした。 これは自分が配属する前からユーザーから届いたお問い合わせに関しては調査が必要なものはCSチームのメンバーがAsanaで最初に管理しています。 従ってGitHub同様にAsanaでもタグや時間を指定してフィルタリングができます。 この機能を使ってメンバーがアサインされている且つ、時間を指定して1ヶ月辺りにCartDevチームが対応したお問い合わせ対応の数も計測できました。 以上より「月刊CartDev」では担当大臣（運用業務)の対応した実績数と、実績の詳細が確認できるURLを記述して社内に共有しました。 月刊CartDevを共有してからのフィードバックについて 月刊CartDevはまだ1月号と2月号しか出せてないのですが、「読者アンケート」を題して社内で読んだ人からフィードバックを頂いています。 フィードバックを一部取り上げると以下のコメントを頂きました。 Cartチームの活動内容がよくわかった Sentry担当大臣は結構みんながはまるエラーの宝庫なのでどんどん共有していきたいですね BASEの基盤なので、色々大変だとは思いますが頑張ってください!! 今後の月刊CartDevの改善について 現在作っている「月刊CartDev」のメインコンテンツが「担当大臣」の実績で、ほとんど数値を共有して終わっています。 読者アンケートのフィードバックで頂いた意見を読むと「担当大臣」の実績や数値を載せても他チームに需要がないケースもある事がわかりました。 アンケートを読むと、どのチームもSentryやNewRelicなどの監視ツールの運用や知見を読みたい事がわかったので今後は「担当大臣」の実績や数値よりも「CartDevでのSentryを使った監視体制について」など、テーマを絞って社内で共有していければと考えています。 まとめ 同じ会社でも規模が大きくなったりメンバーが増えると他チームが何をしているのかが、わかりづらい状況は常に発生してくると考えています。 他チームで改善が出来ている事を読んだり、聞いたりするだけでもモチベーションが上がったり、他チームの取り組みを知る事で相談しやすくなると思うので今後も「月刊CartDev」を通じて社内で積極的に情報共有される環境を目指して運営して行こうと思います。

こんにちは！ バックエンドエンジニアの高町咲衣です！ この記事では、PHPでDDD（ドメイン駆動設計）を扱う際に気になる「値オブジェクトを更新＝作り直した時のメモリ周りの挙動」について調査した結果をまとめています。 値オブジェクトは不変である DDDの文脈における値オブジェクト（ValueObject）の特徴の一つとして、 不変（immutable）である ことが挙げられます。 値オブジェクトは「値を表現する」オブジェクトであり、例えばプリミティブな値であるint、stringなどと同じように取り扱うべきだとされています。 // プリミティブな値を用いた、ごく一般的な感覚のコード例 $number = 1; // 値をセットする $number = 2; // 値を入れ直す var_dump($number); // 2 var_dump($number === 1); // false // プリミティブな値を用いて、値そのものを変更した例（実際にはこんなことできない） $number = 1; // 値をセットする $number- > setValue(2); // 今入っている値そのものに変更操作を行なう var_dump($number); // 1 var_dump($number === 1); // false // 左辺の「1」は内部的に2で、右辺の「1」は内部的に1なので等しくない。わけがわからないよ よって、次のようなコードはNGとされます。 // NGな値オブジェクトコード例 // 呼び出し元での操作 $valueObject = new ValueObject($value); // 値をセット $valueObject- > setValue($newValue); // 今入っている値そのものに変更操作を行なう // 操作対象の値オブジェクト class ValueObject { private $value; public function __construct ($value) { $this- > value = $value; } public function setValue($value) { $this- > value = $value; // 一度設定した値を変更してはいけない } } ではどうするのかというと、次の例のように「新たなインスタンスを生成して返す」ようにします。 // 一般的な値オブジェクトの変更コード例 // 呼び出し元での操作 $valueObject = new ValueObject($value); // 値をセット $valueObject = $valueObject- > setValue($newValue); // 値を入れ直す // 操作対象の値オブジェクト class ValueObject { private $value; public function __construct ($value) { $this- > value = $value; } public function setValue($value) { return new self($value); // 値は変更せず、新しい自身のインスタンスを返却する } } なるほどですね！ しかしここで一つ、懸念が生まれます。 回数を重ねるとメモリはどうなる？ return new self($value) が何度も行われた時、メモリはどうなるのでしょう？ 調べてみました！ まず前提として、 ValueObject を持つ集約 Aggregate に対して操作を行なうものとします。 // 検証コード // str_repeat("1234567890", 1024) は、10KBのデータを生成し、計測する値をある程度大きくすることで細かい誤差の影響を少なくします。 public function execute() { echo '------START------'."\n"; // 10KBの値を持たせる $aggregate = new Aggregate(str_repeat("1234567890", 1024)); echo "\n------集約生成直後------\n"; echo memory_get_usage()."\n"; echo "------集約生成直後------\n"; for ($i = 1; $i <= 10; $i++) { $aggregate-> setValue(str_repeat("1234567890", 1024)); echo "\n------{$i}回目の値セット------\n"; echo memory_get_usage()."\n"; echo "------{$i}回目の値セット------\n"; } echo "\n------END------\n"; } まずはNGとされる、値そのものを変更したパターンから まずはNGとされている例から見ていきます。 // 集約クラス class Aggregate { private $value; public function __construct ($value) { $this- > value = new ValueObject($value); } public function setValue($value) { $this- > value- > setValue($value); } } // 値オブジェクトクラス class ValueObject { private $value; public function __construct ($value) { $this- > value = $value; } public function setValue($value) { $this- > value = $value; } } オブジェクトの生成が何度も行われないので、メモリはそんなに使わなさそうな予感がします。 出力結果を見てみましょう。 // NGパターンの出力結果 >>> $test- > execute(); ------START------ ------集約生成直後------ 25078576 ------集約生成直後------ ------1回目の値セット------ 25078656 ------1回目の値セット------ ------2回目の値セット------ 25078752 ------2回目の値セット------ ------3回目の値セット------ 25078816 ------3回目の値セット------ ------4回目の値セット------ 25078944 ------4回目の値セット------ ------5回目の値セット------ 25079008 ------5回目の値セット------ ------6回目の値セット------ 25079136 ------6回目の値セット------ ------7回目の値セット------ 25079136 ------7回目の値セット------ ------8回目の値セット------ 25079264 ------8回目の値セット------ ------9回目の値セット------ 25079392 ------9回目の値セット------ ------10回目の値セット------ 25079392 ------10回目の値セット------ ------END------ 値そのものを変更している＝新規にオブジェクトを生成していないので、回数を重ねてもメモリ使用量に大きな変化はありませんね。 予想通りの結果であると言えます。 推奨される「値オブジェクトを毎回生成して入れ直す」パターン 次に、推奨されている（ return new self($value) する）パターンです。 // 集約クラス class Aggregate { private $value; public function __construct ($value) { $this- > value = new ValueObject($value); } public function setValue($value) { $this- > value = $this- > value- > setValue($value); } } // 値オブジェクトクラス class ValueObject { private $value; public function __construct ($value) { $this- > value = $value; } public function setValue($value) { return new self($value); } } こちらは懸念の通り、オブジェクトを毎回生成するのでメモリ使用量が比例的に上がってしまいそうな感じがします。 出力結果を見てみましょう。 // 推奨パターンの出力結果 >>> $test- > execute(); ------START------ ------集約生成直後------ 25078792 ------集約生成直後------ ------1回目の値セット------ 25078872 ------1回目の値セット------ ------2回目の値セット------ 25078968 ------2回目の値セット------ ------3回目の値セット------ 25079032 ------3回目の値セット------ ------4回目の値セット------ 25079160 ------4回目の値セット------ ------5回目の値セット------ 25079224 ------5回目の値セット------ ------6回目の値セット------ 25079352 ------6回目の値セット------ ------7回目の値セット------ 25079352 ------7回目の値セット------ ------8回目の値セット------ 25079480 ------8回目の値セット------ ------9回目の値セット------ 25079608 ------9回目の値セット------ ------10回目の値セット------ 25079608 ------10回目の値セット------ ------END------ おや？特にメモリ使用量が上がってはいませんね。 NGパターンとそんなに差がありません。 インスタンスは適宜破棄されている PHPでは「参照のなくなったインスタンス」はガベージコレクションにより破棄され、自動的にメモリ解放されます。 確かにこのテストケースでは return new self($value) した後「古いValueObject」を参照している箇所が存在しないので、インスタンスが破棄（＝メモリ解放）されていそうです。 気になるので、インスタンスの破棄タイミングを見てみましょう。 破棄タイミングの調査にメモリ使用量の出力は必要ないので、テストコードを次のように書き換えます。 // テストコード // メモリ使用量の出力をしないようにする public function execute() { echo '------START------'."\n"; // 10KBの値を持たせる $aggregate = new Aggregate(str_repeat("1234567890", 1024)); for ($i = 1; $i <= 10; $i++) { $aggregate-> setValue(str_repeat("1234567890", 1024)); } echo "\n------END------\n"; } また、インスタンスの生成・破棄のタイミングを知りたいので、値オブジェクトクラスで適宜文字列を出力するように書き換えます。 // 値オブジェクトクラス // インスタンスの生成と破棄のタイミングで文字列を出力する class ValueObject { private $value; public function __construct ($value) { echo "\n-----------インスタンスを生成します-----------\n"; $this- > value = $value; } public function setValue($value) { return new self($value); } public function __destruct () { echo "\n-----------インスタンスを破棄します-----------\n"; } } 出力結果を見てみましょう。 >>> $test- > execute(); ------START------ -----------インスタンスを生成します----------- -----------インスタンスを生成します----------- -----------インスタンスを破棄します----------- -----------インスタンスを生成します----------- -----------インスタンスを破棄します----------- -----------インスタンスを生成します----------- -----------インスタンスを破棄します----------- -----------インスタンスを生成します----------- -----------インスタンスを破棄します----------- -----------インスタンスを生成します----------- -----------インスタンスを破棄します----------- -----------インスタンスを生成します----------- -----------インスタンスを破棄します----------- -----------インスタンスを生成します----------- -----------インスタンスを破棄します----------- -----------インスタンスを生成します----------- -----------インスタンスを破棄します----------- -----------インスタンスを生成します----------- -----------インスタンスを破棄します----------- -----------インスタンスを生成します----------- -----------インスタンスを破棄します----------- ------END------ -----------インスタンスを破棄します----------- なるほどなるほど。 最初の生成と最後の破棄を除くと、交互に生成・破棄が行われていることがわかります。 つまり、次のような動作をしているのではないかと思われます。 // 値オブジェクトクラスの動作予想 public function setValue($value) { // インスタンスを生成する return new self($value); } // メソッドを抜けたら参照の消えた古いインスタンスが破棄される まとめ ということで、DDDの値オブジェクトの扱いで推奨される return new self($value) は、 メモリ的に心配はない ということがわかりました！ もちろん 他から参照があればインスタンスは破棄されません が、そのあたりをちゃんと考慮した設計にしたいですね！

懇親会で集合写真を撮るBASE株式会社メンバーの様子 こんにちは！桜が満開になり、心浮き立つお花見シーズンですね。 さて、この度は、2023/03/23(木)~2023/03/25(土)に開催された PHPerKaigi 2023 にプラチナスポンサーとして協賛し、3名のメンバーが登壇しました。 今回は、登壇者 3 名からコメントと、会場の様子やセッションについてお届けします！ PHP カンファレンス 2023 とは 2023/03/23(木)~2023/03/25(土)の 3 日間にわたって PHPerKaigi 2023 が開催されました。 BASE はこれまでにも開催されている PHPerKaigi への登壇並びにスポンサードをコミュニティ貢献活動として行って参りました。 今回はプラチナスポンサーとして当カンファレンスに協賛しています。 プラチナスポンサー一覧の左下にBASE株式会社のロゴ 登壇者のコメント 02 ( @cocoeyes02 ) speakerdeck.com 02です。今回は3年ぶりにメジャーバージョンアップとなったPHPUnit 10の話をしました。 今回の登壇準備の一環で、3年分のChangeLogを追って読んでいましたが、実際にやってみると想像以上に大変だということがわかりました。 ただ、IssueやPull Requestを読んでいく過程でPHPUnitのコミッター・メンテナーの考えや思想というのが徐々に見えてきて、とても勉強になりました。 今後もPHPUnitだけでなく、普段使用しているライブラリやフレームワークをChangeLogベースでリーディングしていこうと思います。 スライドにも書いていますが、今回のトークで話し切れなかった話題は後日テックブログに載せようと思っています。お楽しみに。 永野 ( @glassmonekey ) speakerdeck.com 永野です。今回はPHPをブラウザで動かすという面白内容で話をいたしました。 WebAssembly = ブラウザで用いられる技術 = PHPは関係ない、というイメージを払拭できた内容だったのではないでしょうか？ 個人的にはWebAssemblyに関してはプロダクションの利用が広まってきていると感じており、特に脱コンテナという文脈では結構身近になってきているなと感じております。バックエンドエンジニアとして考えると抑えておきたいスキルかなと考えています。 特に先日 OpenFunctionがWasmをサポートした という記事もあるようにFaaSを使う規模だとコンテナは結構ヘビーな印象を持っていたので活用の幅は広がると考えています。 また、発表にインパクトがあるようにデモ用のPHPのPlaygroundサービスである php-play.dev も便利やらの感想を聞けたことは大変作者冥利につきました。 ぜひご活用ください。 php-play.dev Futoshi Endo ( @Fendo181 ) speakerdeck.com 遠藤です。最終日のLTで「PsySHを使った効率的なデバッグ方法について」というタイトルで紹介しました。 普段PHPを使ってデバッグをしていると var_dump や pritn_r などを使って実行後に中身を見るという流れになると思うのですが、 PsySH を使う事で対話的にターミナル上で確認できて便利です。 PHPでのデバッグツールと言えば「Xdebug」が有名ですが、素早くブレイクポイントを貼ってデバッグする時には PsySHが便利な場面があるので、是非活用してみてください! オフライン会場の様子 オフライン会場の様子をお届けします！ こちらは Futoshi Endo さんのLTの時の様子ですね。制限時間間近になると聴講者の皆さんがペンライトを振る斬新な流れになっていました！ 他にも数年ぶりに懇親会が開催されたり、お菓子なども充実していました！ オフライン会場の様子は Googleフォト で共有されていますので、ぜひそちらも併せてご覧ください！ 現地で見たセッションを一部紹介 takemoto です！今回は一般参加者としてセッションを聴講していました！その中でも気になったセッションについて一部紹介します。 PHPの最高機能、配列を捨てよう！！ @uzulla 土曜の朝イチの発表でしたが、いい意味で眠気を吹き飛ばしてくれた発表でした。(是非アーカイブ動画を見てほしい) PHPの配列は他言語でいうところの「Vector, Map, Hash, List, Iterable」などの機能を備えており、なんでもできる最高機能です。しかし、なんでもできるが故にカオスを生み出しやすいので(自己責任で)捨てよう！と言った内容でした。 かくいう私も新卒の頃はPDOから取得してきたクソデカ連想配列を数ファイルにわたって引き回し、加工に加工を加えた末に出来上がった何かを型の支援もないまま、どういう風に扱っていたのかもう思い出せないですし、そういうコードはできればもうあまり書きたく(読みたく)ないと思うのでとても共感できる内容でした。 時間を気にせず普通にカンニングもしつつ ISUCON12 本選問題を PHP でやってみる @sji_ch オンライン登壇であったのにも関わらず、今年のPHPerKaigiのモリアガリトーク賞に選出された発表で、ISUCON12本選問題をPHPを使った実装で優勝チームと同等のスコア(Goでの実装で約34万点)を目指した試みが紹介されていました。 ISCCONは毎年Golangを使ったチームの活躍が目立っているので、「PHPがどこまでやれるのか」は非常に興味深いトピックでした。 発表の中で触れられていた作業は主に以下のような内容でした。 ミドルウェアの設定を優勝チームのリポジトリからコピってくる DBにインデックスを貼る PHPプロファイラで処理速度を計測 → ボトルネックになっているSQLを直す マスタ参照をキャッシュ利用するようにする シャーディングDB追加 PDOの生成コストが高いので、リクエスト間でPDOインスタンスを使い回せるようにする。 CPUがサチったので 余ってるDBサーバーのCPUでWebを回す ひたすらプロファイルを見て地道な改善 発表の途中で「CPU処理でネイティブコードの言語に勝てないのは自然なので、余ってるインスタンスはDBサーバーでも使え！」と言う主張があり非常に競技者的な目線の発想で思わず笑ってしまいました。 最終的なスコアは約35万点まで伸びて(制限時間という縛りはなかったですが)優勝チームを超えたので、PHPでも最適化すればかなりいいパフォーマンスが出せることを知れて、とても勉強になりました。 Laravelへの異常な愛情 または私は如何にして心配するのを止めてEloquentを愛するようになったか @KentarouTakeda Laravelがどのような思想で作られていて何を目指しているかを紹介した発表でした。 Laravelの思想に沿ってLaravelの機能をデフォルトのまま使うコードを書くことで、コンテナ化やスケールが容易になることが豊富なサンプルコードを例に説明されていて、改めてフレームワークの思想や基本設計を知ることは大切なことなんだなと感じました。 Laravelは何を目指しているのかを知ることができるエピソードとして、Laravel 10から戻り値アノテーションをタイプヒントへと修正する影響範囲の大きいPRが発表内で紹介されていました。 この修正は最終的にLaravelの作者自身が(長い議論の末)戻り値をmixedに戻したそうです。このことに対して登壇者の方は「Laravelはジュニアからシニアまで使っていけるFWを目指しており、その結果万人にとってちょっとづつ使いづらくはなっている」といった解釈をされていて「しかしLaravelのこういう思想は我々も採用や開発効率という点で恩恵を受けている。Laravelの利用を後押しすることでWeb開発をもっとより良くできる」という結論で締め括っていました。Laravelへの愛が詰まったとても心温まる発表でした。 謝辞 協賛・社員のスピーカー参加を通して PHP コミュニティの盛り上がりに貢献することができ、弊社としても大変有意義な時間となりました。 スタッフの方々には業務でお忙しいにも関わらず、多くの時間をカンファレンス準備へ注いでいただいたかと思います。この場を借りて御礼申し上げます。 それでは、また来年の PHPerKaigi でお会いしましょう！

BASEでバックエンドエンジニアをしている、遠藤( @Fendo181 )です。 2023年3月18日に開催された「 YAPC::Kyoto 2023 前日祭 」と、2023年3月19日に開催された「 YAPC::Kyoto2023 」に参加してきました。 「ブログを書くまでがYAPC」 という事でこの記事では参加レポートを書きます。 結論を先に言うと「 YAPC::Kyoto2023 最高でした。 」というのが自分の感想になります。 「何をもって最高だったのか?」というのはこの記事のまとめに書きますので、まずは参加レポートから紹介していきます。 この記事では自分のセッションも含めて「YAPC::Kyoto 2023 Reject Con」と「YAPC::Kyoto 2023」で発表されたセッションの中でも特に良かった8件を紹介しています。紹介しきれてなかった発表も沢山あるので、気になる方はタイムテーブルからセッションの詳細などを見て探しみてください。 YAPC::Kyoto 2023 タイムテーブル また、当日の感想や他の人が書いた参加レポートはTwitterでハッシュタグ、 #yapcjapan で追う事ができますので、こちらも是非ご覧になってみてください。 YAPC::Kyoto 2023 Reject Con PHP8によるデザインパターン入門 by FutoshiEndo speakerdeck.com ref: YAPC::Kyoto 2023 前日祭の「YAPC::Kyoto 2023 Reject Con」で登壇します - BASEプロダクトチームブログ 前夜祭での発表でしたがトップバッターだったので凄く緊張してました。 YAPCはPerlだけにとどまらない技術者たちが好きな技術の話をし交流するカンファレンスというのは知っていたのですが、PHPの話題で喋っても大丈夫かな...?という気持ちが強かったです。 また 「 Design Patterns: Elements of Reusable Object-Oriented Software 」で紹介されている23個のデザインパターンが作られた歴史的な背景も説明するスライドもあったので限られた時間でPHP8の文法も混ぜつつ説明ができるかは凄く悩みました。 結果的には社内の同僚から沢山レビューを貰い当日は時間内におさまる形で発表ができました。 お忙しい中でレビューしてくださった、 @glassmonekey さん、 @Panda_Program さん、 @nazonohito51 さん、 O2 さんの皆さんありがとうございました。 また、このスライドを作成するにあたってはBASEに在籍されていた Kazuki Higashiguchi さんの以下のスライドをとても参考にさせて貰いました。 改めてこの場で感謝を伝えさせてください。ありがとうございました。 デザインパターンを出自から深く理解する / understanding design pattern from the origin デザインパターンの使い方を パタン・ランゲージとの比較から考える / design-pattern-usage-inspired-by-pattern-language 自分が紹介したスライドを見た方はわかると思いますが「まとめ」の後の「最後に伝えたい事」で「 "How" age faster than "Why" 」をテーマに「手段にとらわれず、本質を追い求めましょう」というメッセージを追加しました。 YAPC::Kyoto には学生の方も参加される事をしっていたので少しでも響くメッセージがあればと思い入れました。 ただ、デザインパターンを覚えれば良いではなくて、本質を追い求めていく姿勢が大事という事が伝えれて良かったと思います。 インシデントレスポンスを自動化で支援する Slack Bot で人機一体なセキュリティ対策を実現する by hiboma speakerdeck.com hiboma さんによるSlack Botを使ったインシデント時の支援についての紹介でした。 具体的にはGMOペパボでの活用事例について紹介があり、インシデントマニュアルの呼び出しや、初期衝動を呼び出してチャンネルを作成したり、関係者に自動で連絡が飛ぶようにしたり、ポストモーテムの作成支援等で使われている事例が紹介されておりました。 インシデント対応に関して個人的に関心が高かったのでここで紹介されているSlack Botでの活用は現職でも今すぐに取り入れたいと思いました。 一時的なページにアクセスができない問題や、連携先の外部サービスによって機能が使えなくなる等と、影響範囲の規模は関係なく障害は常に起きるものだと認識しています。そういった常に発生するインシデントに対して、復旧作業を優先するように Slack Bot が支援する体制というのは、どこの企業でも取り入れて良いと思ったので、凄い参考になりました。 チーム開発における様々なボトルネックの整理 by すてにゃん speakerdeck.com この発表では すてにゃん さんが実際にチーム開発を通じて感じたボトルネックに対する考えた方や解決方法について紹介されていました。 改善サイクルが回っていない話から、チーム内の連携のイマイチになってしまっている例を提示しており、そこからの具体的な解決方法までわかりやすくて説明していました。チーム開発での課題は、リモート体制になってから顕著化していると思っていたのでともて刺さる内容で、スライドの中では「スコープ×カテゴリ」で絞るお話がされており参考になりました。 こういったボトルネックは放置しておくとチーム開発の速度低下になってしまうので自分も聞いていて実践したくなりました。 try { Support Engineer } catch($e) { joy, pride, and prospect } by kyanny docs.google.com kyanny さんの発表では GitHub Enterprise のサポートエンジニアとして、これまで行ってきた仕事や、やりがいについて紹介されていました。 自分が前職で CRE(Customer Reliability Engineering)をしていた事もあったので 「目の前の具体的な問題を解決するところ」や「フィードバックサイクルが短いところ」などはとても共感をしました。 また同時にしんどい所でもあげていた「小さい締め切りに追われるところ」も胸が痛くなるぐらいわかる部分でした。 サポートエンジニアやCREでも目の前で困っているユーザ様の課題を拾って解決したり、改善するというのは言葉では表しきれない達成感や喜びがあります。また、CS(Customer Support)さんとも連携したり、社内間で同僚とのコミュニケーションが必要なスキルなので 「（テキスト）コミュニケーションを通じて、いかに迅速に相手と意思疎通して問題点を明らかにし解決に導くか」 はとても納得しながら聞いてました。 YAPC::Kyoto 2023 小さく始め、長く続けるOSS開発と貢献 by Songmu ghq や peco を開発し、メンテナンスされているsongmu さんによりOSS開発に関する発表でした。 OSS開発によってどんなメリットがあるのか?の話では設計力が身についた話だったり、コミュニティにおいて仲間が出来たというお話がされておりました。またOSS開発について「ある意味プロダクトマネジメントができる」という視点での紹介もされており勉強になりました。 一番印象に残っているのが 「 正しいコードの先にある個性豊かな美しいコード 」 というワードで、とても心に響いたのを覚えています。 良い設計のために名前付けをする事が大事なのはわかっているのですが、「コーディングの世界でも文学のような個性が現れる世界があるのか...!」と気になりました。まるで小説の作家ごとの文体や行間の細かい癖が、コードの世界にもあり、個性豊かで美しく現れているのはOSS開発を始めたくなる強いメッセージだと思いました。 入門 障害対応 「サービス運用はTry::Catchの繰り返しだよ、ワトソン君」 by RyuichiWatanabe@gurasan speakerdeck.com Ryuichi Watanabe さんによる 障害対応フローにおける一連の作業の流れ紹介した上で、実際にサイトにアクセスが出来なくなったケースを例に具体的に対応する事を書いていました。このスライド、本当にわかりやすいです。 障害対応は常に発生する一方で、対応方法について属人化している部分があります。 影響範囲の特定から関係者への通知、早期復旧作業の一連の流れのエッセンスを上手くまとめており、非常に参考になると思いました。 またこのスライド中で紹介されていた 「障害対応能力向上施策」と障害対応時のナレッジと解決方法をまとめた 「Playbook」の作成は今すぐでも導入したい内容でした。 Playbookについては始めて聴く言葉だったのですが、メルカリのテックブログでも Playbook について言及されており勉強になったのでリンクを共有しておきます。 ref: メルペイのシステム運用とPlaybookの共通管理への挑戦 | メルカリエンジニアリング あの日ハッカーに憧れた自分が、「ハッカーの呪縛」から解き放たれるまで by あらたま speakerdeck.com cake.jp のCTOである あらたま さんによるハッカーに憧れた一人のエンジニアがギャップに苦しみながらキャリアを模索し、組織での役割も考えながら「ハッカーとは何であり、何でないのか?」を自分視点で説いた、素晴らしい発表でした。 自分もベストスピーカーとして投票をしたのですが1つの映画を見終わった後の満足感がありとても良かったです。 ハッカーになろう (How To Become A Hacker） という有名な記事があります。 何を隠そう自分もC言語のポインタが理解できない学生の頃からこの記事を何度も読んでは自分を鼓舞して、ハッカーに憧れていた一人のエンジニアでした。 そういった意味で「ハッカーの呪縛」というのはとてもわかる内容でした。 発表の中で「事業・技術の2つの軸を同時に極める事は難しい」という題材から第3の軸である「組織」を例に整理して「ハッカーにあり続けるために」へ導くまでのスライドは、今働いているエンジニアや、これからエンジニアになりたい人にも響く内容で素晴らしいスライドだったと思います。 そしてスライドの中で紹介されていた 「 Whatから出すケーパビリティがなくても、WhyからWhatまでを正しく理解し、Howに責任を持てるエンジニアにならなければならない 」はとても響いたメッセージでした。 改めてベストスピーカー賞おめでとうございます。 YAPC::Kyoto 2023 キーノート: 私とPerlとYAPCとはてなと私 モブがメインキャラを目指す話 by Yasuhiro Onishi speakerdeck.com 株式会社はてな の取締役 組織・基盤開発本部長の大西さんによる発表で、はてな誕生秘話の歴史から大西さんが、一人のモブ(社員)からエンジニアとして会社へ貢献し、組織を引っ張っていくメインキャラになる為の人生が紹介されていました。 個人的にはもう一つのベストスピーカー賞はこのキーノートだと思っています。 エモーショナルな話がメインだと登壇者のブログ記事に書いてあったのですが、一人のエンジニアとして組織に配属していれば誰もが共感する内容でとても良かったです。個人的にPerlコミュニティでの熱意が大西さんを動かして、キーノートで自らもYAPC::kyoto 2023で発表し、参加している方へ熱意を与えてる一連の流れが素晴らしく泣ける発表でした。 後日アーカイブ動画が公開されると思うので、機会があれば是非動画で見てその熱意を受け取って欲しいです。 発表お疲れ様でした。 そして、ありがとうございました。 まとめ YAPC::Kyoto 2023 が、自分にとって始めての「YAPC」参加でした。 YAPC参加する前からPHPやRubyの技術コミュニティでの勉強会やカンファレンスにも参加した事があったのですが「YAPC」ならではの良かった事の1つにPerl技術コミュニティの存在が大きいと感じました。 Yasuhiro Onishi さんのキーノートでも 「YAPC::Asia Tokyo 2006」の話が紹介されていたり、 あらたまさんのスピーカーでも 「YAPC::Asia 2011」の話が出ていたり等、過去の登壇者の発表に感化されて技術を磨き、そして再度「YAPC」で発表をするといった、一種の師弟継承が垣間見える瞬間がありました。 それはPerlに限らずどの技術コミュニティでも起きている話なのですが、YAPCに限った話で言うとPerlに限らず色んなプログラミング言語の技術コミュニティに影響を与えていると思いました。それはYAPCが「Yet Another Perl Conference」という意味であり、 Perlだけにとどまらない技術者たちが好きな技術の話をし、交流するカンファレンスだからだと思います。 そういった意味では全てのエンジニアが参加して楽しめるというのはとても素晴らしい事であり、参加できた事を嬉しく誇りに思いました。 本当にありがとうございました。 開催するにあたって沢山準備をして尽力された運営に皆さん、そして当日のスタッフの皆様お疲れ様でした。 次回も開催されると思うのでまた会場に足を運んで参加したいと思います。 おわり 記事内で紹介した登壇者のブログ記事一覧 https://tech.pepabo.com/2023/03/24/yapc-kyoto-2023/ https://blog.stenyan.jp/entry/2023/03/20/094654 https://blog.kyanny.me/entry/2023/03/20/005140 https://ryuichi1208.hateblo.jp/entry/2023/03/21/223424 https://onishi.hatenablog.com/entry/2023/03/20/141549

2023年3月19日に「YAPC::Kyoto 2023」が 開催されます。 yapcjapan.org その前日の2023年3月18日に前夜祭で開催される「YAPC::Kyoto 2023 Reject Con」に遠藤( @Fendo181 )が登壇します。 yapcjapan.connpass.com YAPC とは YAPCはYet Another Perl Conferenceの略で、Perlを軸としたITに関わる全ての人のためのカンファレンスです。 Perlだけにとどまらない技術者たちが好きな技術の話をし交流するカンファレンスで、技術者であれば誰でも楽しめるお祭りです! 今回の「YAPC::Kyoto 2023」のテーマは「try/catch」になります。 YAPC::Japanとして初めての試みとなる「会場と配信のハイブリッド形式」で開催されるカンファレンスなため、チケットを持っている方はオンラインでカンファレンスに参加する事ができます。 当日のタイムテーブルは以下をご覧ください。 https://yapcjapan.org/2023kyoto/timetable.html 発表する内容について 「PHP8によるデザインパターン入門」というタイトルで2023年3月18日の13:10~13:20の間で発表します。 このタイトルにした背景には「 PHPによるデザインパターン入門 」という、2006年に刊行された名書があります。この本では「Adapter」や「Singleton」など有名なデザインパターンをPHPを使って紹介されています。一方で本で書かれているPHPのバージョンは5.x系で、このとき型宣言も列挙型もまだ導入されていませんでした。 その後PHP7から「型宣言」が導入され、PHPは昔と比べて堅牢にコードが書けるプログラミング言語になりました。 読み進めながら写経していると「はたして最新のPHP8で書き直したらどんな違いがあるのか? もしくはデザインパターンで解決したい本質は変わらないのか?」という素朴な疑問が出てきて、掘り下げてわかりやすく説明したいと思い上記のタイトルになりました。 この発表では各PHPのバージョンで書き直したデザインパターンを比較し、PHP8で書き直した場合の変更点や、PHP8の新しい文法についても紹介したいと思います。 おわりに 自分としては本選考で選ばれなかったものの、前夜祭の「YAPC::Kyoto 2023 Reject Con」で採択して頂けた事に YAPC::Japanの運営の皆様に心から感謝しています。当日は参加者の方が少しでもtry/catchして、関心を持っていただけよう発表をしたいと思います。 また自分もYAPC::Kyotoに参加するのが始めてなので、一人の参加者としても「YAPC::Kyoto 2023」を楽しみたいと思います。

2023/03/23(木) ~ 2023/03/25(土) の日程で開催される PHPerKaigi 2023 へプラチナスポンサーとして協賛する他、BASE 株式会社に所属する 3 名のエンジニアが登壇します。 PHPerKaigi 2023 とは PHPerKaigiは、オープンソースのスクリプト言語 PHP （正式名称 PHP:Hypertext Preprocessor）を使用している方、過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、技術的なノウハウとPHP愛を共有するためのイベントです。 https://phperkaigi.jp/2023/ 弊社はプラチナスポンサーとして、当カンファレンスに協賛しています。 プラチナスポンサー一覧の左下にBASE株式会社のロゴ PHPerKaigi 2023は、オンラインおよびオフラインでのハイブリット開催となります。 セッションの内容について 02 ( @cocoeyes02 ) 2023/02/03 に約3年ぶりのメジャーバージョンアップデートであるPHPUnit 10がリリースされました。 3年ぶりということもあって、PHPUnit 9からの変更はとても多いです。 例えばPHPのrequireが7.3->8.1へと大きく変わったり、大量のクラスやメソッド、オプションが削除されたりなど・・・ 今回のトークではPHPUnit 10で何が変わったのか、時間が許す限り解説していきたいと思います！ 永野 ( @glassmonekey ) 最近注目のWebAssembly皆さん使っていますか？私は仕事ではまだです!! Frontendでの活用を始めとして、バックエンド含めて活用のシーンが広がってきたように感じます。 そんな状況なのでPHPerの私含めて少しでもWebAssemblyと仲良くなれるきっかけを作れたらと考えています。 今回の発表では 以下の内容になります。乞うご期待。 WebAssemblyがどのような技術なのかの紹介 ブラウザ上でPHPを動かすデモ そのために必要なノウハウ Futoshi Endo ( @Fendo181 ) 遠藤です。PHPerKaigi 2023の3日目にLTで登壇します。 タイトルは「PsySHを使った効率的なデバッグ方法について」です。 PsySHはPHPで作られたREPL (Read-Eval-Print Loop) でインタラクティブに変数の中身やクラスのオブジェクト中身を見る事ができます。 bobthecow/psysh: A REPL for PHP 普段PHPでデバッグをする時には var_dump や echo などを使うと思いますが、 PsySH を使う事でより効率的にデバッグする事が可能です。その理由が伝わるようにこの発表では以下の内容でLTをする予定です。 PsySH について簡単な紹介 具体的なインストール方法と使い方について紹介 PsySH を使ったデバッグ方法についてTipsを紹介 最後に さて、ここまで読んでくださったみなさまのために、PHPerチャレンジ用のPHPerトークンを書きます。 PHPerチャレンジはPHPerトークンを探してスコアを獲得し、そのスコアの合計を競う全員参加型の企画です。詳細はPHPerKaigi内でのアナウンスを聞くか、パンフレットをご覧ください。 PHPerトークンは #payment_to_the_people_power_to_the_people になります。 少し長いトークン名になりますが、BASE株式会社のミッションである「Payment to the People, Power to the People.」をトークン名に採用させていただきました。 また、PHPerKaigi 2023 の当日のチケットは下記よりお申し込みいただけます。 https://www.eventbrite.com/e/phperkaigi-2023-tickets-454900217797 それでは、みなさまにお会いできることを楽しみにしております！

初めに こんにちは。フロントエンドエンジニアの竹本です。 入社してそろそろ4ヶ月が経とうとしています。だいぶBASEの開発にも慣れてきました。 この記事では私が社内の静的アセットを管理しているリポジトリ(以降は便宜上 static-repository と呼びます)のNode.jsのバージョンを12から16にあげたら、webpack dev serverの立ち上がりが約12分から約5秒に短縮できた話を紹介したいと思います。 この作業は業務の隙間時間でやったのですが、どのように取り組んでリリースまで持っていったかをお伝えできればと思います。 結論3行 webpack dev serverの立ち上がりが遅かったのはApple シリコン搭載のMacでNode.js 12を動かしていたから。 Apple シリコン搭載のMacでNode.js 15未満を動かすと、rosetta経由になり非常に遅くなる。 Node.jsのバージョンを上げようとしたら、それなりに大変だった。 話の始まり 事の発端は私がBASEに入社して約2ヶ月ほど経ったときの事でした。その頃私はBASE10周年プロジェクトにアサインされ、 10周記念特設サイト の開発・リリースを担当することになりました。と言ってもWebサイト自体の制作自体は別の方が担当されるので、やることといえば成果物に対して既存のビルド処理を通してコンポーネント等を差し込み、リリースに備えて準備を行う程度のものでした。 ※ 余談ですが 10周記念特設サイト はリリース後、 Web Design Clipさんにも取り上げられました。 とても素敵な仕上がりになっているので、よければ一度ご覧になってください。 特設ページは基本的に static-repository で管理されており、静的ページにビルド処理を通して独自のコンポーネントを差し込んだりmetaタグを追加することができるようになっています。 特設サイトのソースコードを受け取った私はそれを static-repository に移して、webpack dev server起動コマンドの yarn run dev を実行、、、しますがローカルサーバーが立ち上がりません。あれ？？？と思いながら何度か同じコマンドを叩きますが、どうやらローカルサーバーが立ち上がらないわけではなく、 立ち上がりが非常に遅くなっているようでした。 static-repository は静的アセットを管理するだけのリポジトリなので、メンテナンス頻度はあまり高くなく考えられる原因はいくつかありましたが、この時の私は納期が迫っていましたし、立ち上がりが遅いだけでエラー等は起こってなかったのでとりあえず作業を完了させることにしました。10周記念特設サイトは無事にリリースされ反響も大きく、プロジェクトは大成功でした。 それから2ヶ月ほど経って、BASEのフロントエンドエンジニアが有志で集まって負債解消に取り組む frontend-yatteiki という集まりに参加させていただくことになり、そこでずっと気になっていた static-repository 遅い問題に取り組ませてもらうことになりました。 やったこと まずは現状の調査から始めました。 yarn run dev を実行してからローカルサーバーが立ち上がるまでの時間を測定したところ平均して12分くらいかかっていました。遅くなっている原因をざっとコードを眺めて探ってみましたが、 .node-version で指定されていたNode.jsのバージョンが12.14.1と非常に低いことが気になりました。 なので雑にNode.jsのバージョンをLTSである16まで上げるところから始めることにしました。 .node-version を16.18.0に書き換えて yarn install を実行すると以下のようなエラーが出力されました。 1 warning and 1 error generated. make: *** [Release/obj.target/binding/src/binding.o] Error 1 gyp ERR! build error gyp ERR! stack Error: `make` failed with exit code: 2 gyp ERR! stack at ChildProcess.onExit (/Users/XXXXXX/XXX/XXXXXXX/XXXXXX/static-repository/node_modules/node-gyp/lib/build.js:262:23) gyp ERR! stack at ChildProcess.emit (node:events:513:28) gyp ERR! stack at Process.ChildProcess._handle.onexit (node:internal/child_process:293:12) gyp ERR! System Darwin 21.6.0 gyp ERR! command "/Users/XXXXXX/.nodenv/versions/16.18.0/bin/node" "/Users/XXXXXX/XXX/XXXXXX/XXXXXX/static-repository/node_modules/node-gyp/bin/node-gyp.js" "rebuild" "--verbose" "--libsass_ext=" "--libsass_cflags=" "--libsass_ldflags=" "--libsass_library=" gyp ERR! cwd /Users/XXXXXX/XXX/XXXXXX/XXXXXX/static-repository/node_modules/node-sass gyp ERR! node -v v16.18.0 node-sass のビルドでコケているようです。node-sassのバージョンは 実行環境のNode.jsのバージョンに大きく影響を受けます。 なるほど、これがNode.jsのバージョンを上げにくくなっていた原因かもと思いました。しかし static-repository は直接 node-sass に依存してなかったので yarn why node-sass でどのライブラリが node-sass に依存を持っているか調べます。 ❯ yarn why node-sass yarn why v1.22.19 [1/4] 🤔 Why do we have the module "node-sass"...? [2/4] 🚚 Initialising dependency graph... [3/4] 🔍 Finding dependency... [4/4] 🚡 Calculating file sizes... => Found "node-sass@4.12.0" info Reasons this module exists - "base-kit#gulp-sass" depends on it - Hoisted from "base-kit#gulp-sass#node-sass" base-kit が依存している gulp-sass が node-sass に依存しているようです。 base-kit はBASEの社内ライブラリのようですが、今まで見かけた記憶がありません。調べたところ base-kit はフロントエンド開発の便利ツールを集めたライブラリとして過去には存在していましたが、数年前にメジャーバージョンが上がる際に bbq としてUIライブラリに生まれ変わっていました。困ったことに static-repository は base-kit の依存がそこそこあり、その中には base-kit をアップデートして bbq にすると削除されてしまうモジュールもありました。 どうして... ということで、頑張って base-kit への依存を剥がしていきます。 base-kit をアップデートして bbq の最新版にし、 node-sass を使っているところは dart-sass に置き換えていきます。この移行はビルド設定ファイルの変更はほとんどありませんでしたが、webpackのビルド時にSCSSのコンパイルで新しくエラーが出るようになったので、そこも一通り対応していきます。 bbq にアップデートすると消えてしまうモジュールに関してはコード量がそこまで大きくなかったので、コピペでそのまま持ってきます。 その他、軽微な修正をいくつか行なって yarn install を実行するとNode.js 16でインストールに成功しました！ yarn install 自体もかなり速くなってました。そのまま続けて yarn run dev を実行するとwebpack dev serverが数秒で立ち上がり、表示崩れ等もない状態でした。 static-repository はdevelop・masterブランチに新しい変更が加わればCIでビルド処理を行なって、成果物を自動的にS3に上げることが役割なので、ビルドが通ることとビルドの成果物が期待通りの状態になっていれば問題ないという考えのもと、ステージング環境で再ビルドされたものを入念に動作確認をして本番リリースしました。 リリースから数日の間はCIでエラーにならないか気を配っていましたが、2回ほどCIが落ちることがありヒヤリとしました。しかし、いずれもNode.jsのバージョンを上げたことが直接の原因ではなく、すぐに安定稼働してくれるようになったのでそこでようやく一安心することができました。 なぜstatic-repositoryが遅くなっていたのか たまたまNode.jsのバージョンアップをしたら動作が爆速になったので、てっきりNode.jsのバージョンが古かったことが遅くなっている原因だと思っていました。しかし、PRを作り始めた時にCTOの川口さんから以下のようなコメントを頂きました。 なんと！思っていたこととちょっと違っていました。 私は業務でしかM1 Macを使っておらず、プライベートでは基本的に最新版のNode.jsしか使っていないため全く気付きませんでした。他の方がIntel Macで試してみたところ、Node.js 12でも快適に動作したとのことだったので static-repository が遅くなっていた直接の原因は Apple シリコン搭載のMacでNode.js 15未満を動かしていた からでした。 後になってから知ったのですが、元々BASEではM1 Macbookを導入する際にCTOや基盤チームの方がM1でも開発できるよう開発環境を整備して下さっていました。BASEの主要リポジトリはその時にNode.jsのバージョンが引き上げられていましたが、更新頻度の低い static-repository は取り残されていたというのがこの話のオチになります。 やってみて得られた知見やBASEのいいところ バージョンアップ対応は溜め込むと大変 今回の事例でいうと static-repository が base-kit に依存しており、 base-kit が node-sass に依存し、 node-sass がNode.jsのバージョンに依存しているという構造になっていました。そのため、Node.jsのバージョンを上げるためにはコードを読み解いて依存関係を理解しつつ、一つ一つエラーを潰していく作業が必要でした。ライブラリ等のバージョンアップをしないでいると古い依存関係の上に新しい依存が作られていくことになるので、改めて日頃から依存ソフトウェアのバージョンを上げていくことの大切さを実感しました。 やらないといけないことはやっていく必要がある Webサービスを提供している事業会社はどうしても新機能の開発や既存機能の改善をしていくことが優先されます。それはユーザーに新しい価値を届けるためにとても大切なことですが、一方でプロダクトをより堅牢に, より速く変えていけるようにすることも同じくらい重要です。ライブラリのバージョンアップはまさにそういった作業の第一歩だと思うので、積極的に上げていきたいなと思いました。 BASEは「いつかやらないといけないこと」にも取り組めている BASEは創業10周年を迎え、会社もサービスも大きくなりましたが同時にやり残し・積み残し作業も数多く存在しています。ですがBASEはサービスを成長させていくのと同時に「いつかやらないといけないこと」についても今取り組んでいこうという空気を強く感じていますし、実際かなり取り組めていると思います。 今回私が参加した frontend-yatteiki ではプレイヤーとしてのフロントエンドエンジニアの他にフロントエンド領域に明るいセクションマネージャーの方や基盤チームの方も参加されており、BASEの負債や開発上の課題について活発に議論が行われていたりプロジェクトとは関係のないPRが出されていたりしています。BASEで責任ある立場にいる方がこういう問題に積極的に取り組んでいることは、開発チームとしてとても良い状態だと思いますし、私自身も何かしら貢献がしたいと思えるようになりました。私が入社する前の事例を見ても入社歴が長くないフロントエンジニアの方がVue.jsのバージョンを上げたりビルドパイプラインを改善したりと自発的に課題解決に取り組んでいる様子がslackから伝わってきて、非常にいい刺激をもらいました。 終わりに 今回は社内リポジトリのNode.jsのバージョンを上げた事例を紹介させていただきました。依存ソフトウェアのバージョンを上げていくことはとても大切です。社内にはたくさんのリポジトリがあり、中にはあまり頻繁にはメンテナンスされていないものもありますが、自分が関わったリポジトリに関しては来た時より綺麗な状態にしていけるよう努めていきたいですね。

はじめまして、2023年1月4日に入社しました遠藤( @Fendo181 )と言います。 所属は Cart Dev というチームでバックエンドエンジニアを担当します。 Cart Dev チームはBASEの決済開発を担当しているチームになり、主にショップオーナー様や購入者の決済、カート機能周りの開発を担当しています。 入社してそろそろ1ヶ月経つタイミングですのでこの記事では初リリースまでに行った事や実際にBASEに入社してから経験した事をご紹介します。 初リリースできるまでに経験した作業内容について 自分がはじめてリリースした機能は、ある処理が完了した際のログを追加する軽微な変更でした。 以下に入社してからリリースするまでに行った具体的な作業内容を時系列順にご紹介します。 (1)GitHubやOneLoginなどの業務で使うアカウントを作成する (2)オンボーディング用のドキュメントを参考に作業内容を確認する (3)BASEでショップを開設しながらサービスの仕様を把握する (4)開発環境を構築する (5)具体的な作業内容をメンターの方と相談しながら実装する (6)PullRequestを作成してDevelopment環境にデプロイする (7)Development環境で検証後に問題なければメンターやチームメンバーにレビューをしてもらう (8)レビュー後にApprovedを貰ったらPullRequestをマージしてStaging環境にデプロイする (9)Staging環境で問題なければProduction環境にリリースする (10)Production環境に動作確認をして問題ないか確認する 上記で紹介した作業以外にも PhpStorm の設定や、アーキテクチャの方針や、ドメインモデル図の紹介だったり細かい作業もありました。 紹介した作業の中で自分が特に掘り下げて説明したい内容は以下の2つです。 (2)オンボーディング用のドキュメントを参考に今後の業務内容を確認する (3)BASEでショップを開設しながらサービスの仕様を把握する オンボーディング用のドキュメントがとにかく充実している オンボーディング用のドキュメントには組織図の紹介からチームメンバーのプロフィール、グループでの活動、開発に入るまでの準備等、作業内容が丁寧に記述されていました。 また、Slackでオンボーディング専用のチャンネルが出来ておりドキュメントを読んでも分からない事があったとしてもチャンネルで質問をなげるとすぐにメンターやチームメンバーからフォローが入り1人で悩むというのが無かったです。 また、オンボーディング期間中は上長と1週間に1回、1on1のMTGで作業の進捗具合を相談する機会があります。 この時に「30days入社モニタリングシート」というのを使って進捗を確認するのですがオンボーディングで想定している作業と実際に行っている作業で大きな差が生じないよう1つ1つ状況を確認しながら相談にのっていただいたのが良かったです。モニタリングシートを使ってのふりかえりを行う事で次の1週間の動きが明確になり安心して業務に集中する事ができました。 このようにオンボーディング用のドキュメントが丁寧にまとまっていたり、30days入社モニタリングシートが用意されている等、BASEでは リモート環境で入社してもすぐに会社の環境に慣れる配慮 がされているのが個人的に素晴らしいと感じました。 オンボーディングについては Owners Marketing チームの竹本 さんが書かれた記事もあるので是非こちらもご覧ください。 devblog.thebase.in BASEでショップを開設しながらサービスの仕様を把握する BASE社内ではこの研修の事を「プロダクト習熟トレーニング」と呼んでいます。 この研修の目的は「新入社員・中途入社・業務委託向けに、BASEのプロダクトに対する理解を深めてもらう。」というコンセプトで用意されています。 最初にBASEでアカウントを作って商品を登録したり、Appをインストールして実際にショップ作成を体験する研修になりますが、作業内容がとにかく細かく書かれております。 以下に実際の作業内容をご紹介します。 商品を登録する。 商品にカテゴリを設定する。 １つの商品ページ内で、種類（Sサイズ、Mサイズ、Lサイズ）を登録する。※サイズごとに値段の変更は不要 登録済みの商品を複製して、別の商品を登録する。 登録している商品を一括で非公開にする。 登録している商品を任意で選択し、同時に削除する。 登録している商品を全削除（一括削除）する。 CSVで複数の商品を同時に登録する。 CSVで複数の商品へカテゴリを同時に登録する。 ... これは一部分で他にも同様なステップが続きます。 自分は空き時間を活用しながら作業してたのですが2~3日程かけて終えました。 この研修の素晴らしい所はただショップを作成して終わりではなく作成しながら「改善したい所も書く」というのがあり研修を通じて サービス利用者側から当事者側への意識 に変わりました。 開発業務外で経験した事について 次に開発業務外でBASEに入社して良いと思った文化や制度についてご紹介します。 Uniposで褒め合う文化について BASEでは Unipos という従業員同士が感謝したい事やお礼を伝えたい時に少額のインセンティブを贈り合うことができるサービスを活用しています。 自分が機能を初リリースする際にもこのサービスを使ってメンバーからポイント貰い嬉しかったのですが、相手への感謝の気持ち気軽に伝えられるのが個人的には素敵な取り組みだと感じました。 メンターランチ制度を使って他部署の方と交流する メンターランチ制度とはBASEに入社された方がいち早く会社に馴染んでいただけるようランチ代の補助する制度になります。 詳細は BASE Book でもご紹介していますのでご覧ください。 basebook.binc.jp 普段仕事していると自分が所属しているチームメンバーとの交流がメインになるのですがこの制度を使う事で他部署のエンジニアやグループマネージャーの方と交流できるきっかけになり良かったです。 まとめ 自分がBASEに入社して初リリースするまでに経験した内容をご紹介しました。 オンボーディング用のドキュメントが充実している事やメンターランチ制度が揃っているなどBASEではリモートで入社してもすぐに組織に馴染んで開発に集中できる環境が整っていると感じました。 またこの記事では紹介できなかったのですが頻繁に社内で読書会が開催されたり、ブロク記事や勉強会への登壇を推し進めるチャンネルがあったり組織の中で活発にインプットとアウトプットに取り組んでいる事も素敵だと感じました。 この記事を読んでBASEに興味を持った方は Youtube 、 BASE Book でも事業内容や現在取り組んでいる内容についてご紹介していますのでご覧ください。 この記事を読んでBASEに少しでも興味を持っていただけると幸いです。 読んでいただきありがとうございました。 binc.jp

はじめに この記事は BASE Advent Calendar 2022 の25日目の記事です。 CTOの川口 ( id:dmnlk ) です。 毎年技術ブログチームに勝手に組み込まれています。 タイトルと画像が一致してないのはデザインテンプレに合わせづらかっただけなので気にしないでください。 BASEでのエンジニアリングマネージャーについて エンジニアリングマネージャー(以下EM)は各社によって定義が分かれていることと思います。 どこに責任を持ってもらうか、という点が異なっており下記エントリーがまとまっていてわかりやすいです。 yigarashi.hatenablog.com BASEにおいてはEMは主にピープルマネジメントとデリバリマネジメントに責任を持ってもらっています。 ピープルマネジメントには採用も含んでいたりするのではないでしょうか。自分のチームの補強はEM自らが主体で採用していくということですね。 テクノロジーマネジメントはテックリードとCTOの僕がマネジメントしている構造となっています。プロダクトマネジメントに関しては、VPoP率いるチームが持っています。 EMがエンジニアのキャリアとしてどう捉えられているか 最近ではようやくEMがエンジニアキャリアと1つとして道筋になってきていますが、どうしても技術を伸ばすことを諦めてしまうといった捉え方をされることを聞くことが多いです。 実際のところ、BASEのEMが最先端の技術を検証したりバリバリとプロジェクトのコードを書くということは行っていません。 そういう点を見聞きしてしまうとEMはエンジニアのキャリアから外れてしまうという印象が出てしまうということなのだと思います。 ですが自分はそうは思っていません。 自分は人や組織はシステムアーキテクチャの1つというか同じであると考えています。 人というコンポーネントをどのように配置し、どのように相互作用してアウトプットを増やして開発をスケールさせていくかを考える必要があります。 人間はとてもグローバル変数が大きいのでいつでも同じアウトプットが出るものではそこも考慮する必要があります。 これら複雑な要素をうまくコントロール、ハックし、BASEという1つの大きなシステムアーキテクチャを運用していくことは疑いようもなくエンジニアリングといえるでしょう。 組織をシステムアーキテクチャと捉えたときのEMの役割 上記の事を踏まえたとき、EMの役割は何になるかと言えば所謂テックリードやシステムアーキテクトになるのではないでしょうか。 チームをリードしアウトプットを改善していくことが求められます。 時にはメンバーにハードなコミュニケーションをしてでもアウトプットのブロッカーをなくしていく必要もあります。 従来のやり方だけでは問題がある場合には、今までチームで取り入れていない技術要素（例えばスクラムの導入など)に取り組むこともあるでしょう。 チームという単位のマイクロサービスのようなもの(あくまで比喩です）をEMが運営し相互作用しそれら全体の設計や流れをコントロールすることがCTOたる自分の重要な責務の1つであります。 おわりに これからのキャリアに悩んでいるエンジニアの方にはEMにあまりネガティブな印象を持ちすぎず、新しいエンジニアリングに取り組むという気概を持ってエンジニアリングマネジメントにチャレンジして欲しいと思っています。 そして改めてここでいうことではないですが、BASEのEMの皆様は自分達がシステムアーキテクト、テックリードとしてチームというシステムをよりよく運用していけるように頑張ってください、よろしくおねがいします。 今年もBASEアドベントカレンダーをご覧いただきありがとうございました。 2023年もこのブログを積極的に更新していく予定ですのでご覧いただければ幸いです。

はじめに この記事は BASE Advent Calendar 2022 の25日目の記事です。 devblog.thebase.in はじめまして、BASE株式会社で執行役員 VP of Productをしている神宮司 ( id:h7jin16 )と申します。 メリークリスマス！アドベントカレンダーも最終日です。皆さま仕事納めはできたでしょうか？ BASE株式会社は今年で10周年を迎えたアニバーサリーイヤーでした。自身もBASE株式会社で働き始めて9年経ちます。今回は9年間の社会人経験を経て大切だと思ったことを4つ紹介させてください。 個人的なものなのでお役に立てるかは分かりませんが読んでいただけると嬉しいです。 想像力は大切 ユーザーさんが抱える課題に対しての想像力だったり、誰かとコミュニケーションをするときの想像力だったり、何かを計画するときの想像力だったり。とにかく生きていくうえで想像力は一番大事だと感じています。 想像力の欠如によって誰かを傷つけてしまうことや不要なアクシデントを招くこともあり得ます。さまざまな人のことを想像して適切な行動ができる人になりたいです。 常に意識を向けて日々を過ごす 職業柄自身が体験したことに対して「いい体験」 or 「悪い体験」のラベルを脳内で貼って過ごしています。 例えば、電車に乗ったとき、タクシーに乗ったとき、食事をしたとき、歯を磨いたとき、ボタンを押したとき...etc。なぜ自分は「いい体験」だと感じたのか、なぜ「悪い体験」だと感じたのか。 誰かと同じものを見ていても意識を向けている事柄によって受け取れる情報は人それぞれ違います。 信頼関係を築く 信頼があるから期待され、その期待に応えることでさらに信頼をされる。そんなループによって新たな機会を得ることができます。 信頼は一朝一夕では築くことができませんが失うことは簡単です。日々の所作によって信頼を築くこともできれば失うこともできます。自身も完璧には程遠いですが少しでも信頼を築けるように過ごしていきたいです。 アウトプットが重要 情報化社会なのでインプットの機会は得やすいです。知らないことがあったらAmazon、Google、SNS、ChatGPTに聞けば知ることができます。すごく便利で有り難いですが、個人的なくせとして、アウトプットよりもインプットのほうが楽なのでインプットに逃げてしまいがちです。 アウトプットするのは本当に辛く、解決しなければいけない面倒なことがたくさん起こります。しかし、アウトプットをしなければ何も起こりません。インプットはアウトプットのためにあります。 アウトプットをしなければ得られないインプットもたくさんあり、それこそが重要だったりします。なので意識的にアウトプットの機会を増やしていきたいです。 おわりに 読んでいただきありがとうございます。 今年からBASE DESIGNERブログも始めています。デザインチームもいろんな情報を発信しているので覗いてみてください note.com 今後も個人・スモールチームの経済活動をエンパワーメントしていくために精進します。BASE株式会社は次の10年に向かってより進化していきます。一緒に次の10年を作れるかたを探しているのでご興味あればぜひご応募いただけると嬉しいです。 binc.jp 引き続きBASE株式会社をよろしくお願いします。良いお年を！

はじめに この記事は BASE Advent Calendar 2022 の24日目の記事です。 devblog.thebase.in はじめまして。岡部（ @rerenote ）と申します。2022年6月にエンジニアリングマネージャーとして入社し、8月からPay ID Dev Groupでマネージャーを務めています。今回は購入者向けショッピングサービス「Pay ID」の開発組織について、マネージャーとして私が考えていることも少し織り交ぜながら紹介していきます。実用性というよりはパッション多めの内容でお送りします。 「Pay ID」と「Pay ID Dev Group」 ショッピングアプリ「BASE」とID決済サービス「PAY ID」を統合・刷新して2021年11月30日に提供を開始した購入者向けショッピングサービスが「Pay ID」です。「ネットショッピングの体験をより良くする」ことをミッションに掲げ、購入者が好きなショップや好きなモノとつながり続けられる関係構築の支援、ストレスフリーな決済体験の両方を提供するべく企画、開発、運用を行っています。統合前の2つのサービスの歴史があるため会員数こそ多いものの、現在の形になってからは1年強と歴史は短く、サービスとしてはまだまだ作り込みが必要という段階にあります。 Pay IDの開発組織である「Pay ID Dev Group」はPay IDのミッションを技術で実現するための組織です。具体的にはPay IDのスマートフォンアプリ、決済サービス領域の開発、運用を行っています。iOSエンジニア、Androidエンジニア、バックエンドエンジニア、フロントエンドエンジニア、エンジニアリングマネージャーが所属しており現在は約20名という規模です。 Pay IDのプロダクト開発スタイル プロダクト開発は主にプロダクトマネージャー、デザイナー、エンジニアでチームを組んで進めています。これから事業を伸ばしていくぞという段階にあるため、きっちり分業しています！ということはやっておらず、それぞれの専門領域で素案をつくり、チームで議論をしながら仕様や設計を決めていくというやり方をとっています。 「スクラムです」とか「アジャイルです」というような表現を用いていないのは、プロダクトに合った開発スタイルを試行錯誤しながらチームで発見していくこともプロダクト開発の一部だと思っていること、また、次で述べる特徴もあり、全チームこのやり方で進めています、とすることはないのかなという私の考えに基づいています。 システム運用についても安心して使っていただけるように、どういう体制でどのように実現していくかを設計して実行していく必要があってまだまだ未着手のことが多い。本当にこれから育てていくプロダクトとチームなんだなぁと痛感することが多いです。 開発組織運営視点でのPay IDのおもしろさと難しさ Pay IDというサービスは性質の異なる要素を内包しているため、異なる要素同士がいい感じに協調して1つの事業としてまとまりを出すことを意識して組織設計や採用要件等を決めています。サービスに対する解像度をできる限り高めた上で要素分解し、共通すること、共通しないことに分けた上で複数のチームに分割し、チームごとに味付けを変えていくイメージです。性質の異なる要素については下記のようなものがあると考えています。 「購入者」と「ショップオーナー」 Pay IDは購入者向けのサービスですが、実はPay IDのユーザーは購入者だけではありません。Pay IDでお買い物ができるショップは、ネットショップ作成サービス「BASE」で作成された自社ECのショップであり、ショップオーナーもユーザーです。プロダクトに機能という形で新しい価値を追加していく際には「購入者」「ショップオーナー」という違う立場と視点を持っているユーザーの両方を想像しながら取り組む必要があります。BtoCとBtoBの2つのビジネスモデルが同居しているようなイメージです。 「ショッピングサービス」と「決済サービス」 決済サービスは「メリットがある、便利だからこれを使おう」という理由が主になってくるもの。ショッピングサービスは「こういう買い物ができるからここで買おう」という理由が必要になってくるもの。特にPay IDでは「好きなショップ、好きな商品とつながる」ことを大事にしており「楽しくショッピングしてほしい」という想いと、「ストレスフリーに決済できるようにしたい」という想いがあり、目的が違うものが同居しています。 「スマートフォンアプリ」と「システム」 私自身の過去のエンジニア時代の肌感覚によるものなのでふんわりとしており伝えるのが正直難しいですが、感じていることをそのまま書いてみます。スマートフォンアプリを開発する際は、複数の機能群を有しながら1つのまとまった世界観を表現するように作るような感覚。システムについては機能群そのものを表現しており、それ自体が1つの世界を表現する感覚というよりは、複数のものが1つの船に乗っていますという感じ。あくまで個人の感覚ではあるのですが、このような違いを感じています。 Pay ID開発組織の現状とマネージャーとして考えていること サービス・プロダクトもこれからだし開発組織もまだまだこれから成長するよ、という段階です。 ネットショッピングの体験をより良くするために改善、変化を積み上げながらアプリやシステムを育てていく ユーザーを取り巻く環境の変化にアンテナを張りながら、長く愛されるサービスになるようプロダクトをメンテナンスしながら育てていく 上記を継続的に実行していくために、仕組みやカルチャーを自分たちの手で作っていく過程にあります。開発スタイル同様、課題解決についても試行錯誤を繰り返しながら前に進み続けることをしている状況です。 マネージャーとしての個人的な想いとしては、サービスや事業が成長することはもちろんですが「作り手が楽しいと感じながら開発をしている」というのも大切にしたいというのがあります。楽しさを感じるポイントは人によって異なるので実現が難しいことではありますが、「持っている力を駆使しながらなんかいい感じにうまいことやる」のがマネージャーとして求められることなので、1つ1つ試行錯誤しながらチームもサービスも変化させていければと思っています。 また、Pay IDのプロダクトチームについても社内では比較的規模が小さく、開発組織同様これから成長させるぞー、とやっている状況です。このような記事もありますので、あわせて読んでいただけると嬉しいです。 devblog.thebase.in note.com さいごに ほんの一部ではあるのですが、私個人の考えていることも織り交ぜながら、Pay ID開発組織の紹介をさせていただきました。歴史が短い分、課題も多いですが、1つ1つ向き合いながらグループ自体もなんかいい感じになるようやっていくのでどうぞよろしくお願いします！ 今回紹介したPay ID Dev Groupでは現在エンジニア（iOS、Android、バックエンド）を募集中です！興味あるかも？と思った方はぜひ一度お話を聞きに来ていただけるととても嬉しいです！！ A-1.Pay ID_バックエンドエンジニア / BASE株式会社 募集一覧 / BASE株式会社 募集一覧 / BASE株式会社 明日はアドベントカレンダーの最終日です。 CTOの @dmnlk とVP of Productの @7jin16 の記事が登場する予定です。乞うご期待ください！

はじめに はじめまして．経営戦略室の林田（@Linda）と申します． こちらは BASEアドベントカレンダー の23日目の記事です. 本記事では、今年1月に立ち上がったCEO鶴岡（@yt）直下のチームである 経営戦略室（Corporate Strategy Unit；略してCSU）について、立ち上げ時からの活動と、進める中で意識していたポイントを紹介したいと思います！ 経営戦略室（CSU）とは 一般的には「経営企画」と呼ばれ、企業の中長期の経営戦略の策定や、新規事業の創出検討などを行う組織機能・職種に分類されますが、実際の業務分掌や組織上の位置づけは各社様々です． 立ち上げ当初、初期メンバーとして参画した岩田（@joe）や鶴岡とともに、「そもそも経営戦略室、何をしようか？？」の議論から始めました． 侃々諤々の議論を行い、 経営戦略室は、「BASEをみんなで"より速く”、"より遠く”」へ導く「CEOの拡張機能」 として、目指す方向を定めました． ＜出所: 経営戦略室作成＞ ”より速く”、”より遠く”へ向かう先≒CEO機能としてコミットするものは何か？ 色々なステークホルダーの方がいらっしゃり、沢山の観点がありますが、1つと言われれば 「ミッション」である「Payment to the People, Power to the People.」の実現 です． ＜出所： コーポレートサイト ＞ ミッションの実現が全てで、これ以外は極論全て手段です． この立場に立つと、極端なことを言えば事業もプロダクトも、KPI管理も組織も全てが手段です． その時々で、ミッション実現に向けて解決すべき優先度の高い経営イシューは何か？ これを中長期観点で考え抜き、アプローチ（打ち手）を検討します． この打ち手候補には、最善解なのであれば心持ちとしては全ての選択肢が含まれます． 極論、経営戦略室が開発をやるべきなら開発をする、営業活動が必要ならする、採用活動をすべきなら採用活動を率先して進める． 限られた経営資源を踏まえ、中長期的な観点も考えてミッション達成へ向けた最善手だと判断すれば、論理的にはこれらの手段も取り得ます． しかし、 BASEには、ミッションに共感する各領域のプロフェッショナル・スペシャリストの仲間がたくさんいます． 1つの組織機能でできることは物理的に限界がありスケールが難しく、経営戦略室単体で閉じる・依存する傾向にある打ち手候補が最善手になることは少なく、 「中長期的なスケーラビリティ」が判断軸 の1つに入ることがほとんどです． ミッションの実現に向けて、 マクロ環境や未来・将来を考えて、つまずきそうなものがあれば先回りしてその障壁を特定し、取り除きにかかる． その障壁を取り除くために、必要な経営機能の獲得や習慣のインストールに資する活動、それらがスケールする仕組み・ルールを考える． 最終的には、各経営機能が有機的に連携し、優先度の高い経営イシューを特定し、解決に向けて自発的に推進・協議され、数多くの打ち手候補の中から最善手が打たれるPDCAが回る状態を目指す． 経営戦略室の最終目的は「経営戦略室がなくなること」 だよね、と立ち上げたばかりではありましたがメンバー間でも話をしています． これが経営戦略室チームです． 今年1年の振り返り チームの方向性を決めた4月以降 高橋（@Nao.takahashi）や米田（@aipon）もチームに加わり、 今年一年で色々な取組・活動をしてきましたが、本記事ではその一例として3つ簡単に紹介します． 【① 各部門との協働検討推進】 まずは「仲間を知り、共に走る活動」から始めました．BASEの組織は、経営戦略室以外に ネットショップ作成サービス「BASE」を管掌するBASE事業に加え、 購入者向けプロダクト「Pay ID」や決済・金融領域のプロダクト「BASE BANK」・「PAY.JP」を担うNEW Div.、 全社のサービス情報セキュリティを担うIT Strategy Div. グループ全体のコーポレート機能を担うCorporate Div. が存在しています（22年10月時点）．各部門のマネージャー中心に議論を行い、その内容を元に各経営課題の抽出を行ったり、解決に向けたアプローチの検討案を一緒に考えたりしてきました． ＜出所： BASE会社紹介資料 ＞ 【② 経営会議のガイドライン設計】 経営会議は、全社の重要事項の意思決定機関の1つであり、まさに経営イシューが議論される重要な機能です． BASEでは、経営の意思決定のプロセスの可視化やその姿勢として議事録を原則公開しているのですが、 どうすればよりよい意思決定につながるか、会議の在り方自体を経営陣で議論し、ガイドラインを定めました． 例えば、資料は事前提出＆参加者は前もって資料を読んで会議に臨むこと、と記載されており、 まだまだ試行錯誤中ではありますが、これにより質が高まってきていると感じています． *内容イメージ; 推奨アジェンダや会議参加に関するスタンス等が記載されています． ＜出所：経営戦略室作成＞ 【③ 中長期経営戦略の検討推進】 CEO機能の最重要テーマといっても過言ではない中長期経営戦略の策定・具体化、にも足元取り組んでいます． 各種現状を踏まえて、 ミッション・行動指針のレベルから、改めて経営陣で意味解釈やマインドを揃える その上で、これからのマクロ環境に関する見立ても立てながら、ミッション実現に向けたBASEグループ全体の企業戦略を議論する 上記を踏まえて、各プロダクト戦略やその実現に必要な組織ケイパビリティ獲得に向けた方針を議論する といったようなプロセスを経ながら、経営陣を中心に議論を重ねて検討推進を行っています． 進める中でチームとして意識していたポイント 経営戦略室チームとして検討を進める中でメンバー間で、 "チームとしてのマインドは揃っているか？" については、とても意識していました． 「ミッション」・「経営課題」・「事業戦略」・「組織」など抽象的な論点になりやすいトピックであるからこそ、 検討を進める際に、判断軸・議論の軸がブレないように、 些細な疑問点も、その内容や考え方自体のマインドのすり合わせ を行うようにしていました． 「マインドをすり合わせるためのTips」 として2点取組を紹介します． 【① チームミッションに紐づいた年間ロードマップと足元のOKR *1 設計】 BASEでは、クオーターごとに設定するOKRを活用しながら組織運営を行っているのですが、 足元のOKRがチーム方針に沿っているか、年間の活動方針に照らしたときにどの位置づけになっているか のすり合わせを各クオーターで行うことで、 期中に想定内容や進捗にGapが生じた際も、大方針・目的から逸れないような軌道修正が行える ようにしていました． ＜出所：経営戦略室作成＞ 【② 備忘メモチャンネルを活用した情報共有】 "普段の生活・仕事の中で生まれる些細な気になる点にこそマインドを揃えるヒントが有る” との考えのもと、そのチャンスを逃さないように、Slackの専用チャンネルを作り、 チャンネルのレスポンス義務なしで（投稿ハードルを下げる） 気になったニュースや、「これ議論したいな」と思った事項を備忘として投稿し、 その内容を日々のMTGや定例などで一気に共有して消化 をしていました．ちょっとした工夫と運用であるのですが、マインドも揃うし情報共有もできるし、おすすめです． 終わりに；僕たちの信じる未来 下記グラフはクリエイターエコノミー市場規模の将来予測ですが、 これからますます個人の力が経済的にも大きくなっていくことが予測されています． ＜出所： 三菱UFJリサーチ&コンサルティング株式会社 ＞ 22年12月11日、 BASE株式会社は創業10周年 を迎えることができました． これからの10年も、ミッションである「Payment to the People, Power to the People.」の実現に向けて、 ひとりひとりに眠る、想いが、感性が、才能が。 世界中の、必要な人に届くように。 そこから生まれる、作品に、アイデアに、活動に。 正当な対価を、受け取れるように。 ペイメントを、世界中の人へ解放する。 世界のすべての人に、 自分の力を自由に価値へと変えて 生きていけるチャンスを。 あたらしい決済で、あなたらしい経済を。 そんな世界の実現を信じて、個人やスモールチームをエンパワーメントする存在で有り続けたいと思っています． 以上、チーム取組紹介でした！ 明日は、岡部（@rerenote）さんの記事が公開予定です！お楽しみに！ *1 : OKRは、Objectives and Key Resultsの略称で、GoogleやFacebookなどシリコンバレーの有名企業が取り入れたことで近年注目を集めていると言われている組織の目標の設定・管理方法のひとつです．

この記事は、 BASE Advent Calendar 2022 の22日目の記事です。 同日公開の @02 の記事もぜひご覧ください！ こんにちは！BASEグループの新規事業 Pay IDでプロダクトマネージャーをしている坪内 ( @tsubo ）と申します。 12月で入社半年になるのですが、今更ながら入社エントリーを兼ねて、入社半年でチームでプロダクトマネジメントをしていくために取り組んだこと・意識したことをまとめたいと思います。 この記事では、主に事業多角化・マルチプロダクトにおける新規事業や新規プロダクトのPM、またチームを推進する役割として、働かれている方が対象の内容になります。 ⁠入社エントリー 改めて、22年6月にBASE株式会社に転職しました。 Pay IDという新規事業で、Pay IDチームでは2人目のプロダクトマネージャー（PM）としてジョインしました。 入社の軸は、PMとしてこれまでの経験を活かしつつ、新しいチャレンジをしたいという思いで、 ①（前職同様）BtoBtoCの事業で、2サイドに向けて価値を届けるプロダクト ② クリエーター（つくり手）とファン（購入者・支援者）のコミュニティ・コマース ③ 立ち上げで、出来上がっていない・自分が価値を発揮しやすい組織規模 という環境が、 自分の経験が活かせそうだ・関心を持てそう と感じました。 また分散化していくインターネット全体がモール化していて、購入前後の体験がすべて地続きであり、適した体験を届けていく価値を実感していたこと、スモールチームや個人のエンパワーメントや購入者としてのファン体験がユーザー目線で大切にしたいなど、 価値観が近かったことが決め手として大きかったです。 ▶ そのあたりのインタビュー記事は こちら やってきたこと さて、入社後半年間で、色んなことにチャレンジさせてもらっています！ 1〜3ヶ月目キャッチアップ プロダクトビジョンやプロダクトロードマップの言語化・可視化 社内コミュニティ（コーヒー部）の立ち上げ（ 詳細はこちら ） 2ヶ月目〜決済施策のPM ビジネスオーナーの高橋と一緒にBNPLのPJ立ち上げ と決済プロダクトのキャッチアップ 決済という領域から、全社横断PJだったこともあり、ステークホルダーとの関係づくりや共通理解づくり、全社に方針共有などリードとキャッチアップを並行する 5ヶ月目〜 チーム体制強化のため、PMチームのマネージャーに昇格 プロダクト全体の戦略や優先順位の判断など担うことになる FY23に向けた来年のプランニングを含め、事業方針やプロダクトのコア・戦略部分の定義・共通言語づくりをマネージャー中心に取り組むなど チームジョインして意識したこと 今回、新天地でリスタートするにあたり、「温故知新」というテーマで、これまでの積み重ねにリスペクトしながら、新しいことをつくっていく、ということを意識してきました。 新規事業の場合、非連続で新しい風を期待されることが多く、その期待のまま新参者が、課題をあれこれ定義・言及し、新しいことを提案するだけでは、なかなか共通認識/理解を作りにくく、結果的に到達したいところにたどり着けない、というのは、私自身の過去の失敗経験を踏まえて、よくあるアンチパターンかと思っています。 非連続な成長を狙い、早期にチームで推進していくために、これまでの経緯にリスペクトし、未来への想像を含む、共通言語化をつくり・つなげていきながら、チームでチャレンジできる方向性にいくことが、優先と考えていました。 似たようなお悩みをお持ちの方にとって、少しでもヒントになれば嬉しいです。 温故知新の『温故』 新規事業は、0からの立ち上げである、と同時に既存アセットの活用やチームが事業部として独立することで、既存事業とのシナジーを作っていく、という狙いで立ち上げるケースもよくあります。 その観点でPay IDという事業・プロダクト・組織において、 旧Pay ID（PAY ID）と旧BASEアプリの2つのプロダクトが統合したもの BASEのカスタマー領域のチームが事業部として独立した組織 BASEショップでお買い物をした購入者のアセットを活かす事業 新Pay IDとして21年冬にリブランディングして2年目 など、過去の経緯を踏まえた上で、まだ立ち上げていくというのも、新しいものをつくっていく・取り入れていく上で、重要だと考えます。 意識していること それを立ち上げフェーズのカオスな状況で、走りながら考え、作りながら言語化・共通理解をつくっていく中で、ブロッカーになることがあります。特に、過去のコンテキストについて、上記の状況から断片的な情報が多く、暗黙知や人によって尺度・観点が異なる理解というのが、キャッチアップや推進していく上での課題ではありました。 BASEグループとして、次の10年を見据えた新規事業をブレずに立ち上げきるには、当初の思想や狙い、当時の仕様や制約などを理解していくことが大切です。 中には未来に実現したいことと不整合になりえるものも少なくはないですが、「課題」や「べき論」の押し付けや過去の否定をするのではなく、それらを決めた人・作ってきた人たちへの敬意を持って、ヒアリング・ディスカッションしていくのが重要だと思います。 現状地点をドキュメントやFigjamなどで整理・定義しつつ、プロダクトビジョンやロードマップへの落とし込みも、その経緯や実態を踏まえた上で、物事を組み立て、理解していくのが大切だなと意識しました。 温故知新の『知新』 上記の通り、コンテキストを理解した上で、新しいことにチャレンジしていく上で、以下のような取り組みを行いました。 ①プロダクトビジョン・ロードマップの言語化 入社後の事業責任者や1人目PMと一緒に、プロダクトビジョン・ロードマップの言語化をチャレンジしました。抽象的・流動的な内容で、暗黙知、認識ズレなど起きやすいこともあり、以下の観点で整理をしてみました。 誰にどんな価値を届けるため、どんな世界を実現するのか？ プロダクト・ブランドとして、今後どんな戦略があって、なぜ独自決済（BNPL）に力をいれていくのか？ どのマーケットにどんな成長戦略で、どのポジションで、どのくらいシェアをつくりにいくのか？ これらを定義・整理し、PM内での共通言語はつくれてきましたが、残念ながらPay IDチーム内への浸透や活用という形には至っていませんでした。 ②事業責任者やマネージャーを含むチームオフサイト チームへの共通理解・浸透をするため、改めて「全社のミッション、事業・プロダクトの方針が 繋がってる状態」を目指して、事業責任者やマネージャーとオフサイトを通じて、チームでの対話や言語化を行いました。 KPIと企画・仕様とスケジュールだけではなく、「プロダクト全体像を理解し、施策をWhyから考えられる プロダクトチームに」という状態をつくりたいので、意思をもって、異なる職種とも共通理解で話せるテーマとファシリテーションで、あらゆる観点で議論や言語化をしました。 FY23-27の事業方針・計画素案 プロダクトのコアコンセプト 購入者・ショップオーナーからみた価値や体験、コアバリュー プロダクトの今後のブランドの方向性、何を大事にしたいか 市場におけるポジショニングと理想の状態 購入者・ショップオーナーを含め、社内外でどう認知してほしいか チームの一員としてこれからどうしたい？どうありたい？ 参加メンバーは一定の共通言語がつくれてきています。まだまだ誰もが分かる状態に、落とし込みができていないので、オフサイト後もメンバーへの普及や浸透・活用できるドキュメント整備、社内外の発信などやっていきます。 ③購入者向けの⁠ユーザーインタビューの仕組み化 BASEは、これまでオーナー向けに、 UXリサーチ を含め、ユーザー理解に力を入れてきましたが、Pay IDをはじめとする購入者向けのUXリサーチは、会社として初めてでした。 PMとして、「まず顧客を知ることが重要」と考えているので、入社後進めたい気持ちでした。特になぜ作るか？何を作るべきではないのか？どんな状況を避けるべきか？をチームで共通理解をもつために、自社プロダクトやコアユーザー特有の実態を掴んだ上で、組み立てるのは絵に描いた餅やビルドトラップを避ける上で重要です。 チーム内で読書会「 LeanUX 」という書籍を通じて、リーン思考のユーザー体験設計プロセスでプロダクト開発をしていきたい、という思いがあり、まだまだ実行まで落とし込めていないのですが、これからチャレンジしていきたいです。 これまでのリサーチでは、コアユーザーの利用実態を知るきっかけとして、ユーザー理解や初期仮説の検証が少しずつ始まっており、チームでユーザー理解や仮説検証を促進していきたいです。 ④改善フローの仕組み化・プロダクトチーム定例でプロダクトアップデートの共有機会 プロダクトチームが、継続的にプロダクトを良くしていけるための取り組みとして、改善のフローを改めて定義し、仕組み化しました。主に起票〜リリースまでのフローを定義し、要件ごとに優先順位や細かな要件決めを行う形にしました。 Pay ID チームの横の連携を強化して、プロダクトづくりをしやすくする ことを目的に、チーム定例を実施しており、そこで改善を担当したPMやデザイナー、エンジニアが発信する機会を持ちます。 Slack チャンネルで、プロダクトアップデートを担当したメンバーへの称賛をわいわいしながら行うことで、チームの連帯感や自信がついてくることを期待しています。 ⑤採用イベントや社内イベントでの縦横斜めの相互理解や発信機会づくり BASEは、今年の PMconf でBASEが協賛をしたことをきっかけに、PMの採用イベントなど、PM起点の社外への発信に取り組む機会が増えました。 PMconf内ではスポンサードチャンネル内で、合計20名以上のPMやEM、Bizなど各プロダクトリーダーたちのトークセッションを企画・運営。また開催後も、 採用イベント やプロダクトリーダーたちの社内イベントを企画運営する中で、PMやデザイナーの発信機会につながりました。 職種ごとのマネージャー主体で進行することで、発信機会やファシリテーションによって「普段は話さない、みんなが知らないこと」を、事業部横断でプロダクトに関わる縦横斜めの相互理解が促進され、社外への情報発信をしていく機会も増えてきました。 まとめ プロダクトマネジメントは、PMだけが行うものではなく、チームで取り組むものだと思っています。 そのためには、対話ができる共通言語（プロトコル）や相互理解の継続的な取り組みが欠かせません。 新規事業は、短中期の非連続性を目指す性質上、短期的な意思決定・推進の速度だけではなく、チームで対話しながら、自律的なプロダクト開発ができるように、チームでプロダクトマネジメントをしていく必要があると考えています。まだまだ山の麓ですが、これからも挑戦していければとおもいます。 今回紹介したPay ID チームでは、現在PMやデザイナー、エンジニアを募集中です！ 興味あるかも？と思った方はぜひ一度お話を聞きに来ていただけるととても嬉しいです！ ▶ 詳細はこちら 明日は @FUJIIMichiro さんや @Linda さんのお話です。お楽しみに！

この記事は BASE Advent Calendar 2022 の22日目の記事です。 こんにちは！ BASEでエンジニアをやっている大津( @cocoeyes02 )です。 BASEではエンジニアが外部へとアウトプットする文化があり、その中の一つに技術イベント・カンファレンスへの登壇があります。 2022年もBASEから様々な技術イベント・カンファレンスへ登壇したので、今回の記事ではその振り返りをしたいと思います。 直近3年間の登壇サマリー まず2022年の技術イベント登壇を定量的に振り返ってみます。比較のため2020年と2021年のサマリーも用意するとこのようになりました。 年 2020年 2021年 2022年 登壇したイベント数 9 17 17 各イベントでの登壇回数の合計 16 35 41 →うち1番登壇が多かった人の合計登壇回数 8 7 5 →うち1人あたりの合計登壇回数の中央値 2 1 2 ユニーク登壇人数 8 20 17 →うち去年登壇した人の中で今年も登壇した人 4 3 11 登壇した回数は毎年増えており、良い傾向にあります。 数字から読み取れるのは、段々と年に2回以上登壇している人が増えてきていることと、2021年に登壇した人で2022年も登壇している人が半数以上いるということです。 これは登壇が1回限りではなく、日々のアウトプットの機会として登壇を選択している人が徐々に増えていきていることを示しています。 登壇を文化として根付かせる上では、登壇「したことある」人だけでなく、登壇「している」人が増えていることが重要になってきます。その点において言えば、好ましい結果になったと言えます。 ユニーク登壇人数は2021年と比べると人数が減ってしまったので、iikanji-conference-toudanチームのメンバーとしては来年の目標としても追っていきたいです。 ちなみにiikanji-conference-toudanチームの活動については、去年のアドベントカレンダーの記事をご覧ください。 devblog.thebase.in 2022年はどのような分野の登壇が多かったか 2022年はバックエンド、アジャイル、フロントエンド、SaaSツールなどをテーマにした技術イベント・カンファレンスの登壇がありました。 去年までと比べると、比較的フロントエンド分野の登壇が増えてきました。特定の分野だけではなく、多方面の分野でアウトプットしていく文化があるのはとても良いことですね。 いくつかフロントエンド分野における登壇のイベントレポート記事がございますので、よければご覧ください。 devblog.thebase.in devblog.thebase.in また、2022年は協賛や招待による技術イベントの登壇が増えました。 今年は例年よりも「一緒にイベント開催しませんか？」「イベント登壇しませんか？」と声をかけて頂いた回数が多かったように感じます。この場を借りてお礼申し上げます。 こちらに関しても登壇のイベントレポート記事がございますので、よければご覧ください。 devblog.thebase.in devblog.thebase.in devblog.thebase.in basebook.binc.jp 登壇によって変わったことがあったか 面接や面談の場で「登壇によるアウトプットを見た！」という声がだんだん増えてきました。 社内slackで「登壇によるアウトプットを見た！」というコメントを頂いた様子 他にも内定承諾のきっかけの一つに、登壇によるアウトプットを挙げていた方も現れました。 社内slackで内定承諾のきっかけの一つに、登壇によるアウトプットを挙げていた様子 登壇によるアウトプットが採用のアトラクトに貢献できていて、大変嬉しい限りです。 ブランディングにおいて最も重要なことは、とにかく継続することだと思っています。 今後も技術ブランディングの向上をしていく上で、BASE外に継続したアウトプットが出ているかが重要であると再確認ができました。 最後に とはいえプロポーザルを出したけど採択されなかった人が出てきたなどまだまだ課題はあります。 プロポーザルが採択される上で重要な観点を社内kibelaにまとめるなど、2023年も引き続きエンジニアの登壇をサポートしていきたいと思います。 ちなみに、今回紹介した記事以外にも登壇のイベントレポート記事がたくさんあります。 カテゴリ「イベントレポート・スポンサー・登壇」の一覧を見ると一通り読むことができますので、ぜひご覧ください！ カテゴリ：イベントレポート・スポンサー・登壇の記事一覧 明日は @FUJIIMichiro さんの『BASEのUXライティング／コピーライティングについて2022』と @Linda さんの『経営戦略室と僕たちが信じる未来』のお話です。お楽しみに。

この記事は BASE Advent Calendar 2022 の21日目の記事です。 Platformグループでグループマネージャー をしている 松田 （ @tadamatu ） です。 先日、エンジニア15名に AWS JumpStart（AWS研修プログラム） に参加してもらいました。 この記事では、参加の目的や感想、実際参加してどうだったのか、などを伝えさせていただこうと思います。 「AWS JumpStart（AWS研修プログラム）」とは？ AWSが 無償 で提供してくれている研修プログラムで、 AWS初学者のエンジニアを対象とした、実践的な2日間の研修プログラム です。 https://awsjumpstart221020.splashthat.com 将来的にAWS活用をリードする人材になるための第一歩をスムーズに踏み出せるようなプログラムをご提供します 単なるAWSサービスの学習だけでなく、要件に合わせて適切なアーキテクチャを検討・設計する経験を積む部分にフォーカスした内容となっております 本イベントは、数時間の事前勉強会 (録画動画を事前配布)と2日間のワークショップ(参加必須)で構成されています 　 参加の目的 現在BASEでは、私達のグループが主導をして絶賛 リアーキテクチャ を進めています。 「モジュラモノリス」を中心 として、新しく環境を作り直そうとしているのですが、 インフラ環境としては今後もAWSを中心に構築 を予定しています。 「モジュラモノリス」を選んだ理由は様々あるのですが、理由の一つとして 「モジュールの独立性」 というものがあります。 BASEではエンジニアの数が多くなるにつれて、 現状のモノリシックな環境 では修正のたびに コード影響範囲の調査に時間が取られる 関係者が多いため意見も増えコンセンサスをとりづらくなる など、 多大なコストを支払わなければならない という状況が増えてきています。 これらを解決するために、 モジュールという単位で適切なコンテキスト分解 し、それぞれに コードオーナー（チーム単位）を設置 し、 責務の分離 を行う計画です。 責務の分離を行うことで、 よりスムーズな開発を促し、スケーラビリティも確保をしたい と考えています。 これにはチーム内で物事を考え、仕様を決定し、完結する力が求められることになります。 AWSでアーキテクチャを考えたり、試したり、インシデント調査したりするために、 アプリエンジニアのインフラ知識の底上げが課題 と考えていました。 そこで、まずは 初手として「AWS JumpStart」への参加 をしてもらったという流れです。 参加者はなんと15名！ 今回は各チームから1名ずつ 「エンジニアとしては中級〜上級だが、AWSの知識は初級〜中級」な15名 に参加してもらいました。 数回に分けるなどの案もありましたが、せっかくだからお祭り感も出たほうがよさそうといったノリで、全員一気に参加してもらうことになりました。 15名ｘ2日というのはなかなかの工数です。 しかし、ここはCTOが二つ返事でOKをくれました。ありがたい。 研修スペックを少しご紹介 研修内容は 公式ページ を見ていただきたいのですが、掲載されていない情報を載せておきます。 雰囲気 今回の研修には約130人のエンジニアが参加 Web、ゲームなど様々な業種からの参加 業種混同で34チームに分かれてアーキテクチャ検討などをを行う 参加者のレベル感は様々で、知識が豊富な方々から経験が浅い方々までといった感じでワイワイと進む 使用ツール Amazon Chime（zoomライクな動画ツール） Slack（申請をすると参加を促されます） Bluescape ハンズオン用のAWSアカウント 参加者の感想 参加者に感想をもらいましたので紹介させていただきます。 今後参加を検討されている方のために、 ポジティブな意見もネガテイブな意見も 包み隠さず書いておきます。 勉強になった どういう AWS サービスがあるのかを紹介するだけでなく、なぜそのようなアーキテクチャ設計にしたのか、非機能要件の評価基準も詳細に解説してくれてとても勉強になった。 AWSのサービスについて何か聞いたことがあるくらいでも安心して参加できる内容で、インフラ設計やその評価観点についても体系的に学べたのが良かった。 AWSとちょっとだけ仲良くなれそうだなと感じた2日間だった。 インフラに興味を持った これからが本番だぞ！と言う気持ちで色々調べたいなと思った。AWS詳しい人に向かっていく勇気がついた。 インフラは難しいという印象をずっと持っていたが、AWS Certified Solutions Architect の資格に興味を持った。 AWSのサービスやオプションが色々あり、まだまだアーキテクチャを構築する上で知らないといけないことは多いなと感じた。 ハンズオンが良かった 「ECSタスクの停止した場合の挙動」や「Aurora MySQLのフェールオーバー時の挙動」を実際にハンズオンで確認したけれどほとんど見る機会もないので少し感動した。 アーキテクチャを検討するにあたり、押さえるべきポイントを実例を踏まえて経験できたのは良かった。 やっぱり実際に手を動かすと理解が深まるなと思った。 AWSの進化に驚いた・新しい発見があった AWSサービスは日々進化しており、より使いやすくなっている。複雑なインフラ整備も、今となってはクリックだけで完結できるようになっていて驚いた。 主要なサービスを包括的に一覧する意味では大変有益だったと思います。事前学習動画は全社員見ておいた方が良いかも。 S3 の料金体系が様々あって下がっていってるのには驚いた。 他業種との交流が良かった Web系ではない業種の方からの質問が新鮮だった。 システムアーキテクトに相談できてよかった 予想が付くような質問に対しても、想定よりも多くの情報を頂けた。 AWSのテクニカルサポーターの方もナレッジが豊富で、さまざまなユーザーケースに対して適切なアドバイスを出してくれて、頼りに感じた。 AWSのSAならどうアーキテクチャを考えるかの思考プロセスが分かりやすかった。参考にしたい。 楽しかった 即席チームでのワーク、楽しく行えました。 ワイワイできて、非常に楽しかったです！ 時間が足りなかった 構成や負荷に対する懸念が出てきたが、二日間ではできなかった。残念。 アウトプットがアーキテクチャ図のみだったので、もっと細かい改善フィードバックを得たかった（発展編みたいな研修があれば参加したい） 疲れた 研修の中で一番タフだったのはアーキテクチャ検討でした。 ずっと思考している時間が続くので、一日の終わりには結構疲れがきます... その他 VPCを作るといった普段しない作業も合ったけれど、概ね知っている内容だったので、上級者の場合はただ手を動かすだけの作業になってしまう可能性があるかも。 アーキテクチャ検討のレベル感がやや高いと感じる場面があったので、人によっては大変な場合もありそう。 現在の業務に生かせそうか こちらもヒアリングしていますので、まとめておきます。 活かせそう 実はもう既に現在進行形で活かしている状況です！ SREチームが何をしているのか、また何を話しているのかの解像度が上がりそう。コミュニケーションロスは減らせそう。 インシデントなどでやり取りされている単語の意味がわかるようになった。 インフラ視点も考慮したシステム開発できるようになりそう。今後イチからインフラを構築するPJに参画する機会があれば大いに活かせそう。 今後の新規開発で考慮する点、考え方が少し分かった気がする（インフラも考慮に入れた提案などはできるかも） インフラに興味を持った。恐怖心がなくなった。 アプリケーションの後ろで何がどう動いてるかをイメージできるかどうかがとても重要だと感じた。 実際にインフラを構築しなくても、アプリケーションエンジニアとして開発を進めていく中、パフォーマンス向上・スケーラビリティなどの文脈でインフラ視点が大事になってくる場面も多いのでとても有意義であった。 微妙、活かせるか分からない 直接日々の業務にすぐに役立てられるというような類のものではなかったかなという印象です。 直近、インフラアーキテクチャを構築していく機会というのはなかなかないのでイメージがしづらい。 SREではないので、AWSのサービスを設定したりすることはないため直接的に活かすことは難しそう。 サービスのエンジニアだとゼロから構築することは稀で、既存のBASEのインフラ資産を活用する方向に行くことがほとんどなので微妙。 で、結局「AWS JumpStart」どうなの？ ちなみに私は提案者であり参加者ではありません。 参加後に研修レポートを書いてもらったものをまとめてこの記事を書いているのですが、 レポートには長文だったり、非常に臨場感あるものもあり、ハンズオン、検討会などが本当に楽しかったのだろうな ということがヒシヒシと伝わってきました。 次回は私も参加したいと思えるくらいに。 トータルしてプラスの意見が多く参加してもらって良かった なと感じています。 「微妙、活かせるか分からない」という意見もありましたが、実際のところアプリケーションの後ろで何がどう動いてるかをイメージできるようになったはずですし、 考え方の幅が広がったと思いますので、マイナスの意見を書いてるエンジニアでも全く無駄ではない と考えています。 また、 インフラの苦手意識の克服、耐性ができた のも非常に良かった点だと考えています。 最後に 「AWS JumpStart」について書いてきました。 SREを目指していない人でも、開発に活かせる内容ですし、後日談でAWSの方と話をしたときには「内容はさらにパワーアップさせるよう動いています」という話も聞いています。 しかし、 知識は使ってなんぼ 。 リアーキテクチャもまだまだれからが本番です。 今後も BASEエンジニア全体のナレッジ底上げを目的とした様々な施策を実施していきたい と考えています！ もしBASEにご興味を持っていただけたならば、カジュアル面談なども実施しておりますので、気軽にお話させていただければと思います！ 最後まで読んでいただきありがとうございました。 さて、明日は @02 @tsubo の記事が公開予定です！お楽しみに！

この記事は BASE Advent Calendar 2022 の21日目の記事です。 初めまして。 BASE株式会社Corporate Engineering CSEの緒方です。 CSE については こちら の記事をご参照ください。 ちなみに私はこの記事を読んだことがきっかけでBASEに入社しました。 上場して3年目 BASEは2019年10月25日に東証グロース（旧：東証マザーズ）に上場し、今年でちょうど3年目にあたります。 上場して3年目ということで、J-SOX法上の監査法人による「内部統制報告書」の監査の免除期間も終了し、2022年度から本格的な監査が始まりました。 このタイミングでエンジニアやプロジェクトマネージャー（以下、PM）を対象に、J-SOXのIT全般統制(ITGC)／IT業務処理統制(ITAC)に関する社内説明会を実施したので、そのエッセンスや統制整備する際に心掛けていることなどをお伝えできる範囲で、あまり専門的になりすぎずにお話しできればと思っています。 上場企業でJ-SOX対応やIT統制に拘られている方々の一助になれば幸いです。 そもそもJ-SOXとは 2006年6月に金融証券取引法が成立した際に、米国のSOX法をモデルに規定された制度です。 上場企業が自社内の業務の内部統制の有効性を評価し、 「うちの会社、誤りとか不正とかなく、ちゃんと正しくお金の勘定してますよ！」 という内部統制報告書を作成して、監査法人からお墨付きをいただく制度になります。 2000年代初頭、米国にてエンロン事件をはじめとする大規模な不正会計事件が相次ぎ、市場が混乱し、健全な株取引が行えなくなり、投資家たちの「なんとかしてくれ！」という声から生まれた法制度になります。 ですので、直接的には投資家や株主を保護するためのものです。 J-SOXにはそれに係る以下の統制の種類があります。 全社的な内部統制 決算・財務報告プロセスに係る内部統制 業務プロセスに係る内部統制 ITの統制 BASEとしてのIT統制の取り組み方 「上場したから」「制度だから」「法律だから」という後ろ向きな理由ではなく、むしろ本制度を活用し、統制を整備することで、よりスピード感のある開発を行っても事故を起こさないような安全装置の役割を目指しています。 具体的には、以下の仕組みを構築することで、日常業務上の不安を払拭したり、有事の際のリカバリコストの削減を図り、結果として従業員一人一人が安心安全に、かつスピード感をもって業務遂行できるようにすることを目指しています。 誤謬（意図しない誤り）や不正が起こりにくい仕組みの構築 万が一、誤謬や不正が起こった時に、検知しやすい仕組みの構築 「誤謬」と「不正」について 財務諸表において、 本来あるべき正しい形のものとは違うものを作ってしまう という点においては「誤謬（過失）」も「不正（故意）」も客観的な事実はほぼ同じで、取るべき対策も両者共通しています。 ですので、統制整備の際には 「誤謬を減らすため」に整備実施することに主眼を置き、その結果として 「不正防止のため」につながっている という形が取れるようにしています。 統制の目的として「不正防止」ばかりが先行してしまうと、一緒に働く仲間たちに不信感を抱いているようにも捉われてしまいかねない為、そうではなく、あくまで個々人が安心して日常業務に取り組んでいくための安全装置であることを理解していただけるよう心がけています。 統制のポイント では、 本来あるべき正しい形のものとは違うものを作ってしまう ことを無くしていくためにはどのようにすればよいか？そのためには財務諸表上、よりリスクの高いと思われるプロセスについては、 「複数人の目が入るチェックの仕組み」 を作る必要があります。 具体的には、以下２点が担保できるように心がけています。 Aさんが申請して、その内容をBさんが内容をチェックし、承認して、初めて行使できるしくみ。 上記、承認→申請の内容を第三者であるCさんが事後に客観的に確認できるしくみ。 要は 一人の担当者（あるいは管理者）が独断でなんでもかんでも出来てしまえないように する仕組みとなります。 ですので、一人一人に裁量権を与え、各人の判断でスピード感をもってゴリゴリ進めていくような自走的組織とは、そもそも相性があまり良くありません。 このジレンマが統制整備上の一番の悩みどころです。 統制「しすぎない」こと 統制により「やるべきこと」が増えてくると、業務のスピード感に支障を来します。 そうならないよう、開発エンジニアや各業務を遂行する各担当者たちとは密にコミュニケーションを取り、「スピード感（アクセル）」と「統制（ブレーキ）」のバランスは常に意識するようにしてます。 着眼点としては以下のようなところです。 チェック項目が多すぎないか？ 同じ内容について複数箇所でチェックしていないか？ チェック作業自体を簡略化できないか？ 財務諸表に影響のない部分にまで必要以上の統制を効かせていないか？etc. 最終的には 「統制のルールだから◯◯しないと！」みたいなことを出来るだけ意識させない統制の整備 が理想系だと考えます。 BASEのミッションとIT統制 当社のミッションである「Payment to the People, Power to the People.」を実現するべく、使っていただくショップオーナー様、購入者様をよりエンパワーメントするための機能を日々もりもり開発しております。 IT統制はそれらの開発をよりスピード感をもちつつ、かつ開発エンジニア各人が安心して開発を行えるようにするための必要不可欠かつ重要な機能だと捉えています。 そのためには、一度整備して終わりではなく、より安全かつスピード感を保てる統制を常に模索しつづけることが大切だと感じています。 明日は @cocoeyes02 さんの『BASE技術イベント登壇振り返り2022』と @mrhiro1112 さんの『PMconf 振り返り』のお話です。お楽しみに。