ブックマーク / zenn.dev/ubie_dev (27)

  • Ubie における、小さく泥臭くはじめる開発生産性改善

    記事では Ubie における最近の「開発生産性」というテーマで向き合っている事柄と実際のアクションについて紹介します。まだまだ発展途上ではあるのですが、何かの参考になれば嬉しいです。 背景 「開発生産性」とは一見シンプルな概念に見えますが、世のテック企業、取り組んでいる人々のアクティビティを見ていると複雑で深いものにも感じます。例えば SpeakerDeck で「開発生産性」と検索することで多様な情報発信を見ることができます。有名な書籍として「 Lean と DevOps の科学」も、初学者が内容を頭に叩き込むのも難しいのではないでしょうか。 これらの先行者の知見は素晴らしいものの、具体的に我々の現場の開発組織、事業状況などなど現実に近しい環境と密接に接続して、すぐに手応えが感じられる成果が得られるかというとそうでもないとも思います。 Ubie でも過去に開発生産性課題を感じて様々なアプ

    Ubie における、小さく泥臭くはじめる開発生産性改善
  • マツコの知らない LINE ログインの世界

    Ubie プロダクトプラットフォーム所属の nerocrux です。今回は Ubie において、 LINE ログインを成功させるために工夫したことをいくつか紹介したいと思います。 面白いこともすごいこともやってないし、対象読者もよくわかりませんが、興味があったら読んでみてください。 はじめに 症状検索エンジン「ユビー」について Ubie では、症状検索エンジン「ユビー」(以下、ユビーと呼ぶ)という一般ユーザー向けのサービスを展開しています。ユーザーが簡単な質問を回答することで、関連する病名や、適切な受診先情報を得ることができるサービスとなっています。 ユビーは Web ブラウザ経由で利用されることが多いですが、iOS / Android のネイティブアプリも提供しています。 ユーザーがユビーを利用する際に、ユビーのアカウントを作成することで、一貫性のある問診・受診・受診後のフォローアップ体

    マツコの知らない LINE ログインの世界
  • チームの生産性と向き合う

    こんにちは @glassmonekeyです。 Ubie 株式会社に転職してあっという間に二ヶ月が立ちました。 現在私は toC 向けのアプリケーションに配信する施策を入稿・管理するシステム「案件管理システム」の開発チームに所属しています。 そのチーム内で現在、私はテックリードというロールで、日々の開発を一人のエンジニアとして進めつつもチームの生産性改善、技術的な意思決定のファシリテーションなどに取り組んでいます。 今回のエントリでは、何かと話題となるエンジニアリングの生産性ですが、テックリードとしてどのように向き合ったのか、どのように改善し今後どうしていくのか?を紹介します。 生産性の定義 前提として生産性を正しく計測することは難しく、それこそ生産性を下げる行為だと私は考えています。 @hiroki_daichiさんの開発生産性について議論する前に知っておきたいことに詳細は譲るとして、一般

    チームの生産性と向き合う
  • TypeScriptとGraphQLで実現する型安全なAPI実装

    この記事はTSKaigi2024での以下の私の発表内容を書き下ろしたものです。 なぜAPIに型をつけたいのか 現代のWebのシステム開発において、クライアント・サーバーともに型のある言語で開発されることが増えてきました。静的な型検査はコードの堅牢性やよりよいメンテナンス性の向上をもたらします。 プログラミング内部だけで型検査をするだけでも十分メリットはありますが、外部I/Oに対する型付けが不十分だとそのメリットを最大限に発揮してるとは言えません。外部I/Oとは、例えばWebフロントエンドだとLocalStorageやDOMからの入力値、それからネットワーク通信(今回はこれをAPIと呼びます[1])などですね。サーバー側でいうとAPIからの入力・レスポンスやデータベースへの読み書きが該当します。 個人的な経験から言うと、Webシステムの開発におけるエラーの多くはAPIやデータベースとのやり取

    TypeScriptとGraphQLで実現する型安全なAPI実装
  • UbieにおけるGo言語のエラーハンドリング

    背景 Ubieでは以下の記事にあるように、一昨年から新しく始めるプロジェクトにはGoTypeScriptを積極的に採用しています。私は来プロダクトセキュリティが主な専門領域なのですが、公私ともに普段からGoでツールやサービスの開発をしているため、社内のGo言語の普及をサポートしたりプロダクト開発に参加したりしています。 Go言語で開発したことがある方はご存知かと思いますが、Goは標準パッケージで提供されているエラーハンドリングは最低限の機能しか提供されていません。これは、CLIツールなどではエラーの内容が簡潔に表せてよいのですが、サーバサイドアプリケーションのようにエラーにまつわる情報を詳細に残してあとから調査に利用する、という場面では不向きです。特に番環境でしか再現しないようなエラーの場合は、いかに関連情報を残せているかが、問題の解決に大きく影響します。 先日も話題になっていました

    UbieにおけるGo言語のエラーハンドリング
  • TypeScript 5.5で型述語を推論できて最高。配列のfilterも型安全に

    2024/6/20 TypeScript 5.5が正式リリースしたので追記しました。 TypeScriptの次バージョン5.5で、開発者が長い間求めていた機能がついに実現されました。 従来のTypeScript 5.4以前では、ユーザー定義型ガードを使う際には型述語(用語は後ほど解説します)の記述が必要です。 ▼ TypeScript 5.4 function isNumber(value: number | string): value is number { return typeof value === 'number'; } 2024年6月20日にリリースされたTypeScript 5.5では、関数の実体から型述語の型推論(infer type predicates)が可能になります。すなわち、次のようなコードが可能です。 ▼ TypeScript 5.5

    TypeScript 5.5で型述語を推論できて最高。配列のfilterも型安全に
  • 「情報アクセシビリティ好事例2023」に応募しました

    「症状検索エンジン ユビー」を総務省が募集している情報アクセシビリティ好事例2023に応募しました。(募集はすでに締め切っています。) 情報アクセシビリティ好事例2023 「情報アクセシビリティ好事例2023」は、総務省が主導する取り組みで、情報アクセシビリティに配慮したICT機器やサービスを対象とした募集活動です。この取り組みを通じてアクセシブルなICT機器・サービスの普及促進を目的としています。 応募には3つの書類が必要です。 情報アクセシビリティ自己評価様式(応募書式1-1及び1-2) 「情報アクセシビリティ好事例2023」応募資料 情報アクセシビリティ自己評価様式 情報アクセシビリティ自己評価様式とは、米国で採用されているVPAT (Voluntary Product Accessibility Template)に倣って定められた書式で、製品やサービスがJIS規格(JIS X 8

    「情報アクセシビリティ好事例2023」に応募しました
  • テーブル駆動テストを使った QA エンジニアとソフトウェアエンジニアの連携

    test.each([ {a: 1, b: 1, expected: 2}, {a: 30, b: 5, expected: 25}, ])('.sum($a, $b)', ({ a, b, expected }) => { expect(sub(a, b).toBe(expected); }); テーブル駆動テストは Go 言語を使った開発で良く使われるスタイルです。Go 言語の GitHub リポジトリの Wiki にはテーブル駆動テストに関するページがあるので、興味がある人はそちらを読んでみてください。 テーブル駆動テストを使った QA エンジニアとソフトウェアエンジニアの連携 テストがなくリファクタリングが困難なフロントエンド 症状検索エンジン ユビー には、ユビーのビジネスにとって重要な、とあるページがあります。そのページではフロントエンドからロギングサービスに対してたくさんのロ

    テーブル駆動テストを使った QA エンジニアとソフトウェアエンジニアの連携
  • Web版しかなかったサービスがGoogle Playのアプリ大賞を受賞するまで

    先日、症状検索エンジン「ユビー」のAndroidアプリが、Google Play ベスト オブ 2023 優れたAI部門で大賞を受賞しました。 リリースから約2年半、みんなで育ててここまで来ることができましたが、実は最初はWeb版のおまけで、1週間で突貫リリースしたアプリでした。そこからの成長を振り返り、技術的におもしろそうなトピックをいくつか紹介します。 Web版をWebViewで動かすだけ モバイルアプリ(以下アプリ)のリリース当時、Web版はすでに数百万MAUまでグロースしているプロダクトでした。そのため、ある程度PMFした体験がベースとしてあった上で、アプリを入れてもらえるのか、アプリ特有の体験(通知等)が刺さって継続的に使ってもらえるのか、といった点が主な不確実性でした。 そこを最速で検証するために Capacitor を採用しました。Capacitor は Ionic Fram

    Web版しかなかったサービスがGoogle Playのアプリ大賞を受賞するまで
  • Node.js でメモリ肥大化の原因を特定してみた

    はじめに ユビーでエンジニアをしているおおいしつかさです。 これは、Ubie Engineering Advent Calendar 2023の12月7日の記事になります。 何を書こうかなー、最近はユビーの根幹システムのリアーキテクチャをやっているのでその辺かなーと思ったのですが、まだ仕掛かり中だということと具体な業務に直結しそうな内容なので抽象化して書くのが面倒そうだなーと思ってたところに軽いトピックが飛び込んできたので、そのことを書くことにしました。 ChatGPTはみなさん使われていると思いますが、ぼくも別の業務でOpenAI関連の機能開発に携わっています(ユビーで働くといろんな業務に携われるのがいいところです) 。 その仕事の中で、Node.js環境でメモリ肥大化の事象に遭遇したので、それをどのように発見して改善したかについてお話します。 ぼくは今も昔もRubyが大好きですが、ふだ

    Node.js でメモリ肥大化の原因を特定してみた
  • Firebase Authから内製認証基盤に無停止移行して年間1000万円以上削減した

    症状検索エンジン「ユビー」 では、ローンチ当初から Firebase Auth (GCP Identity Platform) を使っていましたが、OIDCに準拠した内製の認証認可基盤に移行しました。 認証認可基盤そのものは m_mizutani と nerocrux と toshi0607(退職済) が作ってくれたため、僕は移行のみを担当しました。 結果として、強制ログアウトなし・無停止でビジネス影響を出さずに、年間1000万円以上のコスト削減に成功しました[1]。その移行プロセスについて紹介します。認証認可基盤そのものの紹介はあまりしません。 移行した理由 大量の匿名アカウント ユビーでは、アクセスした全ユーザーに対して自動的に匿名アカウントを発行しています。これにより、ユーザーがアカウント登録しているかどうかに関わらず、同じID体系で透過的に履歴情報等を扱うことができます。アカウント

    Firebase Authから内製認証基盤に無停止移行して年間1000万円以上削減した
  • Node.jsで作るモジュラモノリスの設計と技術選定

    この記事はUbie Engineering Advent Calendar 2023の一日目です。よろしくお願いします。 背景 ユビーのシステムは言語が多様化してきたことにより、認知負荷の増加や運用負荷の増加、開発支援に仕組みづくりかけるコストの増加などの問題が発生していました。この課題を解決するためにNode.jsとGoに言語を絞っていくという意思決定をしたのが昨年です。これについては以下の記事で詳しく解説しています。 ちょうど去年のアドベントカレンダーの記事なのでこれから一年経ちました。ここでは以下のように述べられています。 Server-Side Kotlin などで書かれている既存サービスを、この技術選定の文脈でリプレイスすることは今のところ考えていません。 ただし、多くの既存サービスはドメインたくさん抱えすぎ問題があったり、色々とレガシーだったりして、徐々に別サービスに切り出して

    Node.jsで作るモジュラモノリスの設計と技術選定
  • 開発スピードを維持しながらモブプログラミングを実施した話

    こんにちは、ユビーでプロダクト開発エンジニアをしている Sosuke Suzuki です。 最近、チームのエンジニア間の連携がいい感じだなーと思ったので、その要因の一つであるモブプログラミングについて、実践したことを紹介します。 はじめに 最近、私の所属するチームでは、データベース、バックエンド、そしてフロントエンドにも大きな変更を加える必要がある、規模の大きなプロジェクトに取り組んでいました(そして、今も同じチームで別の大きなプロジェクトに取り組んでいます!)。 そのプロジェクトの具体的な内容を書くことはできませんが、大雑把に事情を説明します。 数年前に設計されたいくつかのテーブルがあり、それは当時からずっとユビーのビジネスにとって重要でした。しかしそれらのテーブルは、この数年の間に複雑になったビジネス要件には耐えられなくなっていました。 このままではビジネスの機会を毀損することになりま

    開発スピードを維持しながらモブプログラミングを実施した話
  • Webアクセシビリティ学習リソースまとめ (2023年3月版)

    社内向けにまとめていたものを加筆修正して公開します。 アクセシビリティの学習を始める人の助けになれば嬉しいです。 YouTube freee アクセシビリティ研修動画~全職種対象~ freee アクセシビリティ研修動画~技術職対象(Basic) freee アクセシビリティ研修動画~技術職対象(Advance) a11ygogo A11yTokyoMeetup Webコンテンツ 全般 WCAG WAI-ARIA HTML/CSS デザインシステム、ガイドライン その他 書籍 アクセシビリティ全般 HTML

    Webアクセシビリティ学習リソースまとめ (2023年3月版)
  • UbieでのBI民主化の振り返り

    こんにちは。Ubie Discoveryのおきゆきです。アナリティクスエンジニア/データアナリストとして働いています。自己紹介ページはこちらです。 Ubieでは、各チームが適切にデータを利活用できるようにするためのBI民主化活動を行っています。この記事では、昨年行ったBI民主化の取り組みの一部を紹介します。 BI民主化が必要なわけ データチームが依頼の窓口となり、各チームの依頼に対応するというやり方は、ナレッジが独人化しがちで、チケット管理などの運用コストが増し、中長期的にみてもデータチームの生産性が低下しがちです。結果、質的なデータ基盤改善や攻めの分析活動が後手になりやすいです。また、ドメインに詳しい依頼元が分析実施できたほうが良い示唆を得られることが多々あります。 一方、データチームを介さずに各チームで分析の実施までできている以下のケースではどうでしょうか。 「あるデータが欲しいプロ

    UbieでのBI民主化の振り返り
  • CSSプロパティを自動ソートしただけで、CSSのファイルサイズを(少しだけ)減らせた話

    Ubie Discoveryでプロダクト開発をしている@jimboです。 今回は症状検索エンジン「ユビー」のCSSファイルを改善した話を紹介します。 きっかけ ある日、社内のSlackにこんなメッセージが流れてきました。 自分の中ではある程度レイアウト関連やテキスト関連にグループ化して書くようにはしていたのですが、こういう類のものは、個人個人が気をつけるのではなく、自動的に並び替わるほうがいいに決まっています。 いうことで、Stylelintとstylelint-config-recess-orderを導入することにしました。Pull Requestでは、400を超えるCSSファイルに変更が入り、そのほとんどがCSSプロパティの並びが変わっただけという内容でした。 ビルドした結果を変更前と比べてみると… と、ここで、この変更によって、ビルドファイルのサイズが全体的に減ってることに気づきまし

    CSSプロパティを自動ソートしただけで、CSSのファイルサイズを(少しだけ)減らせた話
  • ユビーにおけるシステムアーキテクチャを改善するための取り組み

    @hokaccha です。こんにちは。最近は主にプロダクト基盤チームで組織的な開発生産性の改善に取り組んでいます。この記事では開発生産性を改善の一環として、現在取り組んでいるシステムアーキテクチャの改善や技術的負債の返却の取り組みについて紹介します。 なぜアーキテクチャを改善するのか 最初に、なぜ我々がアーキテクチャ改善に取り組んでいるかの背景について説明します。 最終的にやりたいことは開発生産性を改善することにより、事業の成長速度を最大化することです。アーキテクチャの改善はそのための手段の一つであり、他にも開発プロセスの改善や開発組織の最適化など、開発生産性の改善のために並行しておこなっている施策は多岐にわたります。 ではアーキテクチャの改善がどう開発生産性に影響を与えるかという話ですが、これについては Martin Fowler の Design Payoff Line の図を引用しま

    ユビーにおけるシステムアーキテクチャを改善するための取り組み
  • 努力しないFigmaとの付き合い方

    この記事は12月22日に行われた「Figma Design File 大公開! デザイナー忘年会2022」で話した内容を記事化したものです。 デザインデータは中間成果物 これはこの記事のベースとなる考え方です。僕はデザインデータは中間成果物であり、いつか捨てられる(メンテされなくなる)ものだと考えています。 デザインデータを作る目的はエンジニアやBizDevの人たちとのコミュニケーションを円滑に進めることです。その目的を達成する以上に整っている必要はないと考えています。 また僕は実装されお客さんが実際に利用するアプリケーションの品質が全てだと考えていて、デザインデータをきれいに整えることは時間の無駄になることが多いと思っています。当に考えるべきことはデザインデータをきれいに運用することではなく、品質の高いUIがきちんとリリースされる仕組みです。 しかしあまりにも無秩序に散らかっているとコ

    努力しないFigmaとの付き合い方
  • Ubie における ESLint 活用

    Ubie では JavaScriptTypeScript で開発されているプロジェクトに対して、静的解析のために ESLint を導入しています。 この記事では Ubie での ESLint を活用事例を紹介します ESLint を活用する目的 まず私が ESLint を活用する目的は、コーディング規約やベストプラクティスを強制することで、コードレビューの手間を省き、結果として番環境でのエラーやパフォーマンスの悪化を減らすことです。 この記事で紹介するいくつかの設定もその目的を達成するためのものです。 no-restricted-syntax でアンチパターンを禁止する ESLint には no-restricted-syntax というルールがあります。 このルールはセレクタで指定した構文を禁止できます。簡単に言えば、簡易的に独自ルールを作成できます。 たとえば次のように設定する

    Ubie における ESLint 活用
  • デザイントークンを自動補完するVS Code拡張機能を開発しました

    Ubie Discoveryでプロダクト開発をしている@jimboです。 Ubieでは、デザイン生産基盤の整備の一環としてデザイントークンを開発し、npmに公開しています。開発の経緯などは次の記事をごらんください。 今回、このデザイントークン用のVS Code拡張機能を開発したのでご紹介します。 リポジトリはこちら。 主な機能 CSSファイルおよびSCSSファイルの編集時に次のような機能が使えるようになります。 自動補完 color や marginなど、CSSプロパティのあとに -- を入力すると、デザイントークンのCSSカスタムプロパティが候補として表示されます。 ホバー時のツールチップ表示 入力済みのデザイントークン(CSSカスタムプロパティ)にカーソルを当てると、その値を確認できます。 拡張機能を開発した背景 現在、デザイントークンは症状検索エンジン「ユビー」やユビー病気のQ&Aと

    デザイントークンを自動補完するVS Code拡張機能を開発しました