こんにちは、ソフトウェアエンジニアの@futaboooです。 先日スクリーンリーダーへ対応したプレスリリースを配信しました。今日はその裏側について紹介です。 10x.co.jp はじめに とあるパートナーのネットスーパーシステムをStailerへリプレイスして少しすると、お客様から「今まで使えていたのに使えなくなった！」という切実な声が届きました。この問い合わせを通じて、視覚障害者のお客様がスクリーンリーダーを使って買い物をしていたこと、そしてStailerがそのニーズに応えていないことに気づきました。 そこで、我々は視覚障害者のお客様へのヒアリングを開始し、どのような環境でアプリを使っているのか、使用しているデバイスやスクリーンリーダーソフトウェアの種類など、具体的な情報を収集しました。このプロセスを通じて、アプリがより多くの人々にとって使いやすいものになるための重要な改善点を発見しまし

データ基盤チームに所属しているデータエンジニアの吉田(id:syou6162)です。10X社内のデータマネジメントの仕事をしています。 10X社内では2022年10月にデータマネジメント成熟度アセスメントを実施していましたが、それから約一年半が経過し、データマネジメント上の課題が進捗 / 変化した箇所が出てきました。そこで、最近の成果を振り返りつつ今後のデータマネジメントの方針を改めて見直すため、データマネジメント成熟度アセスメントを再度行なうことにしました。本エントリではその内容についてまとめます。 前回のデータマネジメント成熟度アセスメントへの取り組み 今回のデータマネジメント成熟度アセスメントのやり方 成熟度アセスメントの実際の結果 前回実施時との差分が大きかった項目 データセキュリティ データ品質 メタデータ 優先度が高かったにも関わらずあまり進まなかった項目 まとめ 前回のデータ

こんにちは、セキュリティチームでソフトウェアエンジニアをしてる@sota1235です。 明けましておめでとうございます！本年も10X Product Blogを何卒よろしくお願いします。 さて、今回はセキュリティチームで今年の6月ごろから取り組んできたGitHub Dependabot Alertの削減についてお話しします。 サマリーとしては以下です。 今年の6月頃から取り組みを開始 初期はセキュリティチームで毎日トリアージ、泥臭くAlertの対応を行う 主要なRepositoryのAlertは一通り解消、一部は担当チームへの移譲等を行い継続的に維持できる状態へ 結果として半年間で500件弱のAlertをcloseし、残ってるAlertも対応方針が全て確定した状態になりました。 この数が多いか少ないかはソースコードの規模感にも依存するので言及しませんが、この記事では小さいリソースで取り組み

この記事は🎄10X プロダクトアドベントカレンダー2023の22日目の記事です。 21日目の昨日はaineさんによる「プロダクトマネージャーになった自分が大事にしていること」でした。 こんにちは。エンジニアリングマネージャーの坂本(kazu0620)です。 この記事では10XがStailerの開発に取り入れて来た仕組みやルールの中で、「もしも過去に帰れるならこれは早い段階で取り入れたい」と私個人が特に思ったものたちを紹介したいと思います。 過去に帰ることはできませんが、我々と同じようにプロダクト開発を行っている組織の方の参考になれば幸いです。 Stailer最初期の開発と現在 Stailerの開発が始まったは2019年末のことです。私が10Xに入社しStailerの開発に関わり始めた2020年3月の時点では、ソフトウェアエンジニアの数は6名でした。当時はプロダクトマネジメントはCTOであ

この記事は🎄10X プロダクトアドベントカレンダー2023 の17日目の記事です。 16日目の昨日はkazk1018さんによる「Data as a Product」について考える でした。 こんにちは、10XでProduct Managerをやっておりますkeiです。本日は10Xで行っているProduct Fridayという取り組みについてご紹介します。 Product Fridayとは もともと「開発共有会」という名の開発で共有した知識により全体のパフォーマンスがあがるものを定期的に共有できる場があり、エンジニアリング本部（SWEやQAを中心とした組織）により運営されていました。それをこの4月からプロダクト本部（PdMやDesigner, データプロダクト）と合同で運営することとなり、趣旨は引き継ぎつつ職種を超えて(主に開発に関わる)知見を共有すること、コミュニケーションを促進すること

こんにちは。SREの栗原です。 この記事は10Xアドベントカレンダーの15日目の記事です。 私がSREとして2022年の10月に入社し1年が経ちました。 この1年間でやってきたことについて書いていきます。 現在SREチームは採用募集中です。この記事を見てスキルがマッチしていたり興味が湧いた方は是非カジュアル面談をしましょう！ SRE（Site Reliability Engineer） / 株式会社10X 入社初期の取り組み 自動化と効率化への取り組み Terraform moduleへのresource追加 Redashやめる Kubernetes yamlのコピペ運用をやめる サービスアカウントキーの発行方法の見直し 育休の取得 その後の取り組み Deny policiesの導入 Terraform Planの権限修正 これから 入社初期の取り組み 弊社がGoogle Cloudを広範

こんにちは。セキュリティチームでソフトウェアエンジニアをしてる@sota1235です。 この記事は10Xアドベントカレンダーの13日目の記事です。 www.notion.so 昨日の記事はSuzuki Ryotaさんのお届けチームでオーナーシップを持っていくぞでした！ 今回はGitHubの監査ログを定期的にexportし、保存する仕組みを作った話をします。 監査ログとは GitHubの監査ログ GitHubの監査ログは永久には保存されない 監査ログの出力方法 この記事の本題 監査ログ出力の仕組み ざっくり要件 技術選定 ログの保存場所 ログの取得処理 ログの取得・保存処理はGitHub Actionsで行う 全体像 1. BigQueryに最新データを取得しに行く 2. 監査ログを取得する 3. 監査ログを保存する 権限管理 監査ログに含まれるデータについて考える 具体的にどこに制限をつけ

この記事は 10X アドベントカレンダー2023 の10日目（12/10）の記事です。9日目（12/9）の昨日は、 id:takanamito さんによる「grpc-dartのInterceptorを使う」でした。 10Xのお届けチーム エンジニアリングマネージャー(以下, EM)の id:hisaichi5518です。10Xではソフトウェアエンジニアとしてサーバサイド、Android、iOS、Flutterと色々やってきて、今は「人を動かして、ことを成す」を目指してEMとして活動しています。 今回は、自分が担当しているお届けチームについて「どんな雰囲気なのか」「どういうチームを目指しているのか」「具体的な活動」について書いていこうかなと思います。書き終わって気付いたんですが、今年のテーマは"開発・プロダクト"らしく、ちょっとテーマに沿ってない感があるけどまあいいかってなりました。人生って

10X の Kubernetes おじさん兼娘ちゃん好き好きおじさんこと SRE の @tapih です。 この記事は 10X プロダクトアドベントカレンダー2023 の 8 日目の記事です。昨日は PdM の @enaminnn さんの記事でした。 note.com 本記事では、 2023 年 1 月頃に行っていたインフラコスト削減の施策についての話をご紹介します。 施策を行った背景 Goals / Non Goals Node pool の命名規則 Pod の移行 AOT コンパイル リソース設定 振り返り インスタンスコスト削減 CronJob 実行時間の短縮 リソース使用の安定化 今後について マニフェストレポジトリの統一と自動化 Re-architecture の機運 Wrap up 施策を行った背景 弊社が提供している Stailer では、サービスローンチ当初から Kuber

CTOのishkawaです。 この記事は10X アドベントカレンダー2023の3日目の記事です。 先日、サーバーサイドのメンバーを中心として、コードをどのように分割管理していくか話すオフサイトを実施しました。オフラインで1日中話していたこともあり、話題は色々な方向に進んだのですが、その中でもモノリス解体にトピックを絞ってシェアしたいと思います(他の話は他のメンバーが書いてくれるはず！)。 前提 10Xには4つの開発チームがあります(お買い物チーム、お会計チーム、お届けチーム、マスターデータチーム)。今年の4月にチーム分割が始まり、コードやデータのオーナーシップも各チームにアサインしてきました。 この組織移行によってオーナーシップ分割は進んでいるものの、依然としてモノリスのパッケージ(Dartのパッケージ)は大きいままで、ほとんどのコードがそこにある状態でした。領域ごとのディレクトリ分割は進

この記事は 10X アドベントカレンダー2023 という企画の1日目（12/1）の記事です。 こんにちは、10Xでソフトウェアエンジニアをしている 岡野（@operandoOS）です。 今回 10Xで3回目となるアドベントカレンダー企画の1日目をありがたく担当させていただきます💪 目次 目次 10X アドベントカレンダー2023ってなに？ さてさて、本題へ CIは絶対に速い方がいい CIを高速化するテクニックの紹介 キャッシュの利用 マシン性能の調整 ジョブの並列実行とテスト分割 最適なテスト分割 ジョブの実行順序・依存関係の最適化 不要なジョブ・ステップを削除する テストコードの実行速度を上げる 紹介したテクニックを活用した10XでのCI高速化事例 アプリのビルド時間の大幅短縮に成功！！ APIのテスト実行時間の大幅短縮に成功！！ CIを高速化するために日々取り組んでいること CI/C

はじめに こんにちは！ソフトウェアエンジニアのyamakazuです。 普段はお会計チームで開発課題をなんとかする役で立ち回っています。 10月から下期が始まったことで、社内で「開発イシュー」と呼ぶ実装課題の大枠が定まり、チームのギアも徐々に上がってきました。 対して9月は上期を振り返るシーンが多くあり、お会計チームは総じて良い成果を残せた期だったなと振り返っています。 体感値での手応えもそうですが、計測数値にも表れていて、チームがQA Processをパスしてリリースしたプロダクトへの変更の数はチーム比較で見ると1番多かったです。 (2023上期にQA Processをパスした数) 色々な前提条件や状況があるので、一概にこの数字の妥当性を比較評価できるものではないとは理解しているものの、それでも自分たちがそれなりの成果を残したことは証明できると思っています。 この生み出した変化幅は何を起因

こんにちは！経営企画の仕事をしているudonです。1年半前の見習いQA以来、2度目の文章です。今回は10X社内の会議のルールを整理し、そして全社員の未来のカレンダー予定を一旦全部消す、通称「ビッグバン」の第一回を実施したのでその背景や内容について書きます。 (イメージ) 10Xでは社内におけるコミュニケーションを大きく「同期」「非同期」に分けています。同期は会議や突発的な電話など同じ場にいることが前提であるコミュニケーションを指し、Slackなど非同期は必ずしも同じ時間での往復を前提としない文章やドキュメントによるコミュニケーションを指します。入った当初は「ドウキ・・？ヒドウキ？？」とドキドキしてた私ですが、2年も経つと慣れてしまいました。慣れって怖いですね。 話が長いという皆様の期待を裏切ることなく、タイトルにもなっているビッグバン(会議の全削除)の話にいくまで5,000文字嵩んでしまっ

こんにちは、セキュリティチームの@sota1235です。 10Xのセキュリティチームではプロダクトに近い領域での権限管理に関して、リスク整理と対応を日々行なっています。 今回はその取り組みの一環であるGitHub Actionsのpermissionsに関しての取り組みをご紹介します！ なぜやるのか そもそもこの取り組みを始めたWhyを軽く説明します。 10XではGitHubで日々の業務が行われており、守るべき資産の数多くがGitHub上で管理されています。 また、アプリケーションのデプロイや日々の運用などもGitHub Acitonsを利用しながら行われており、もしGitHub上で何かしらのセキュリティリスクが顕在化した時のダメージは大きいです。 例えば守るべき主な資産は以下が挙げられます。 Git管理されているソースコード 業務上のやり取りが行われるIssue、Pull Request

こんにちは。品質管理部のブロッコリーです。 現在、品質管理部ではQA（Quality Assurance, 品質保証）エンジニア、テストエンジニア、シニアテストエンジニア、SET（Software Engineer in Test）の募集をしています。 この中で、10Xが目指している品質管理部全体の姿については、以前に記事にしています。（記事公開当時は「品質管理部」ではなく「QAチーム」と表現しています） product.10x.co.jp 品質管理部全体については示したものの、SET職種について明確に何を求めているのか示すことができていませんでした。そのため、SETで応募しようか悩んでいる方にも分かりづらい形になっていたと思います。 そこで10XにおいてSETに求めることを言語化したので、本記事ではそれを紹介していきます。 本記事で言いたいことを3行で ただ単にテストコードを書くことでは

こんにちは。 品質管理部のtarappoです。 早いもので2023年度も1Q（4月〜6月）が終わって上半期も後半戦です。 品質管理部は、次の記事に書いたとおり4月から組織体制を変えました。 上記の記事の執筆時点からさらに体制は変化しています。 ざっくりと執筆時点での体制を図にすると次のような感じです。 以前はチームへのアサインが固定化されてないメンバーもいましたが、今は各開発チームへのアサインは固定化されています。 上記のブログ記事や登壇含め、体制変化については伝えているものの、この体制になって各チームでどういったことを行なっているかについては話していません。 そこで、本記事ではこのチーム体制になってから各開発チームでの品管メンバーの動きについてフォーカスして話したいと思います。 その中で、まずは私が所属する「お会計チーム」についてフォーカスして話したいと思います。 開発チームごとの動きと

こんにちは。10Xのソフトウエアエンジニア(SWE)の石田です。 10Xでは採用に応募してくださる候補者様にむけて、プロダクトのStailerにおいて解決しなければいけないイシューリスト(課題一覧)を作りました。 イシューリスト 各課題をクリックすると各課題の詳細が確認できます。 イシュー 作った理由の１つは、候補者様に対して会社に応募してくださるときに、どんな中長期的な課題があって、どのような貢献ができるか具体的にイメージしてもらいたいからです。会社やプロダクトの情報はプレゼンテーションなどの資料で公開されていますが部署単位で実際にどのような課題があるかは表現できていませんでした。課題をあきらかにすることにより採用の初期の段階でよく質問のある「プロダクトの課題は何ですか？」に答える事ができ、より深い議論ができます。どのような課題が候補者様が興味があるかによって入社した後のアサインも話す事

Analytics Engineerの吉田(id:syou6162)です。BigQueryを中心に10X社内のデータ関連の管理をしています。10Xに入社してそろそろ一年になろうかとしていますが、データ基盤を適切に管理 / 運用するためにSQLによる監視を少しずつ取り入れています。この記事では、具体的にどのようなSQLを書いて監視しているのか紹介したいと思います。 なお、SQLを使ったデータ基盤の監視自体については私の前職のTech Blogで詳細に書いていますので、そちらを参照してください。 SQLを使った監視でデータ基盤の品質を向上させる - MonotaRO Tech Blog データ管理に役立つメタデータに関する勉強会を社内外で開催しました - MonotaRO Tech Blog 本エントリはこれをベースに「dbtをフルに活用している10Xの環境向けに入れた監視」や「BigQuer

こんにちは、Software Engineerの@sota1235です。最近の趣味はギター練習です。 今回は私が所属するセキュリティチームで新たにソフトウェアエンジニアを募集し始めた話をします。 採用目的が全開みたいなタイトルになっていますが、伝えたいことは「セキュリティエンジニアだけでなくソフトウェアエンジニアをセキュリティチームで募集するに至った」背景です。 10Xのセキュリティチームが組成されてから1年半でどのような変化があり、どんな課題を解決するためにこの意思決定に至ったのか。なぜソフトウェアエンジニアが必要なのか。 スタートアップにおいてプロダクトのセキュリティ品質を担保するための体制をどう組み立てていくかの一例として参考になれば幸いです。 目次 目次 ソフトウェアエンジニア(Product Security Ops)とは なぜソフトウェアエンジニアの募集をするのか 1. 現在の

障害プロセスを改善してきた話 こんにちは。Reliability & Securityチームに所属するSoftware Engineerの@sota1235です。 今回は10X内における障害対応プロセスの改善をご紹介します。 今が完成系ではなく道半ばではありますがこの半年 ~ 1年で大きく進化したので同じくらいのフェーズの会社で困ってる方がいたら参考にしてみてください！ ちなみに私ごとですが去年の5/26にこんな投稿をしてたのでやっと伏線を回収する形となります(※ ドヤ顔ではありません)。 目次 こんな感じで紹介していきます。 目次 障害対応プロセスの改善に踏み切った背景 課題1. 障害の報告フォーマットが統一されていない 課題2. 障害報のクオリティの差異が大きく後から振り返りが難しい 課題3. 障害対応者が特定の人に偏る 第一の改善 改善1. 障害報告書のフォーマット更新 改善2. S