アプリなら、コメントが見やすい!
トップへ戻る
なごみ系Wikipedia
user-first.ikyu.co.jp
プロダクト開発部デザイナーの河村恵です。昨今、デザインシステムを用いた「UI / UXの品質担保」「トンマナの統一」「再利用性の向上による開発効率のUP」が注目されつつある中、一休.comでも本格的なデザインシステムの構築を目指し、プロジェクトが発足しました。 本記事では、プロジェクト発足から一休.comならではの課題・実際に作っているUIガイドラインについてなど赤裸々にお話ししたいと思います。 目次 1) プロジェクト発足に至る経緯 2) プロジェクトの進め方 3) 実際に作っているUIガイドライン 4) まとめ 1.プロジェクト発足に至る経緯 CTOからのフィードバック そもそも「デザインシステム導入しよう!」となったきっかけは、CTO(以下直也さん)から一休.com と Yahoo! トラベルの2システムを一つに統合することで実現した、Yahoo!トラベルのリニューアル(詳しくはこち
今から二ヶ月ほど前、10/1 に Yahoo! トラベル のリニューアルが完了しました。このリニューアルは、一休.com と Yahoo! トラベルの2システムを一つに統合することで実現しました。 ご存知の通り、ヤフーと一休は同じグループに所属する企業です。ざっくりいうと「同じグループで2つの宿泊予約システムを開発し続けるのは効率が悪いよね」という話があり、今回のシステム統合に至っています。 Yahoo! トラベルと一休のシステム統合は、(1) 2017年頃にホテルの空室管理や予約、決済、精算業務などを担うバックエンドのシステム統合を行い、そして (2) 今回 2021年春先から半年ほどをかけて、ユーザーが利用する画面も含めた全面統合を行いました。全面統合は総勢で 50名ほどのディレクター、エンジニア、デザイナーが関わる一休的には大きな規模のプロジェクトになりましたが、目立ったトラブルもな
こんにちは。 一休.comの開発基盤を担当しています、akasakasです。 宿泊サイトのPCリストページを ASP.NET Web Forms から Go + Nuxt でリニューアルしたお話をさせていただきます。 詳しいお話をする前に:PCリストページってどこ? こちらになります https://www.ikyu.com/tokyo/140000/ 宿泊PCサイト(検索導線)の問題点 ASP.NET Web Forms のレガシーアーキテクチャによる開発生産性低下 一休.comのほとんどはASP.NET Web Formsベースの独自フレームワークで構築されています。 大規模リプレイスをしたのが2009年頃なので、宿泊サービスを10年以上支えてきてくれました。 それ故、継続して開発をしづらくなってきたというのがあります。 似たような画面があり、修正コストが高い PCリストには条件検索画
はじめに データサイエンス部の平田です。 ディープラーニングのモデルを作る際、学習データが少ないことが原因で精度が上がらない場合、データのかさまし(augmentation)を行うことがあります。 画像の場合は、オリジナルに対して回転させたりノイズを少し加えることで同じラベル付けがされている別の画像を作り出すことができ、それを学習データに加えることで頑健なモデルになります。 ただし、テキストの場合は回転させると意味不明になるのでどういう操作をしてかさましするかというのを考える必要があります。 そこで、EDA(Easy Data Augmentation)というものが考案されました。参考 Synonym Replacement:文中の単語の内n個、同義語に置き換える Random Insertion:文中の単語をランダムに選んで同義語にしてランダムな場所にinsert、n回繰り返す Rand
こんにちは。宿泊事業本部 プロダクト開発部 UI/UXチーム の 岡崎です。 今回は、「個人的」に「プロダクト開発で大事にしていること」をテーマに話を進めます。 概要 なぜ大事にしているのか? 「ユーザーファースト」を大事にする 軽く機能を作成してフィードバックを得る 最終的なUI/UXの決定を長けている人に任せる CVRを確認する 「チームワーク」を大事にする プロジェクトがうまく進んでいるかを客観視する 「アーキテクチャ」を大事にする データフローを統一化する ビジネスルールをテストしやすいコードにする レイヤを責務毎に分けて実装する 最後に 概要 大事にしている事は下記3つあります。 それぞれにフォーカスして話を進めます。 1.「ユーザーファースト」 2.「チームワーク」 3.「アーキテクチャ」 なぜ大事にしているのか? 「ユーザーファースト」 ユーザーに価値を届けられないプロダクト
はじめまして、システム本部CTO室の松村です。 私は去年の4月に一休に入社しましたが、当時は緊急事態宣言の真っ只中でした。 一休も感染拡大防止のために多くの人が在宅勤務になり、私もいきなり週5で在宅で働く事になりました。 それから1年以上働いた経験から、一休での在宅勤務はどんな感じだったのか、新人だった自分はどんな感じで業務を行っていたのかについてご紹介したいと思います。 概要 チーム内外とのコミュニケーション 会話によるコミュニケーション 開発のフロー Githubによるコード管理、レビュー CIによる自動テスト、デプロイ 重要なアラートはSlackに通知が来る プロダクトのログやサーバのデータなどがDatadogに集約されている おわりに 概要 一休では10人以下のチームで1つのプロダクトの開発を行っていますが、 チームで開発をすすめる上で、重要な要素だと感じた以下の3つについて説明し
社内情報システム部 コーポレートエンジニアの大多和(id:rotom / tawapple)です。 最近はオフィスファシリティと、Jamf Pro や Dialpad や、情シスの採用をやっています。 今回は情シスの業務において外すことのできない、社内のヘルプデスクを改善した話をします。 一休のヘルプデスクについて これまでのヘルプデスク 2018年の記事でも紹介している通り、一休では営業やコーポレート部門のメンバーを含めた全メンバーで Slack・Google Workspace を導入しています。 user-first.ikyu.co.jp 社内からのヘルプデスクについては、Google フォームに入力してもらった内容が Slack に自動投稿され、Slack のスレッドでやりとりを行い、問題を解決していました。 この方法を導入することで、口頭、電話、Slack など分散していた問い合
こんにちは。プロダクト開発部の渥美 id:atsumim です。 今回サービス横断で利用できるログインコンポーネントを WebComponents で実装したのでその紹介をします。 1. 背景 今年の2月に電話番号での会員登録及び認証機能をリリースしました。 これに伴って一休の会員基盤も刷新しました。 一休のサービスは主に、宿泊、レストラン、スパとあるのですが、 歴史的経緯により会員基盤が分散してしまっていたので、ひとつにまとめる狙いもありました。 会員基盤 Before/After その一環として、一休のサービスで横断して使えるログインコンポーネントを WebComponents で実装しました。 このコンポーネントにログインや会員登録の処理を集約し、新会員基盤へのインターフェースとするようにしました。 また、電話番号認証や2段階認証設定のモーダルも実装しました。下記が実際の画面です。
メリークリスマスイブ! 皆様クリスマスイブはいかがお過ごしですか。 データサイエンス部所属のエンジニア 笹島 id:sisijumi です。 年末ということもあり、今日は一休という会社のエンジニア組織の変遷を振り返るとともに、現状に関してもお話させていただきます。 (現状はデータサイエンス部ですが、今年の10月までは宿泊事業部のエンジニアのマネージャーをやっておりました。) 一休における収益の変遷 宿泊事業に関してですが、過去発表した資料を元に説明させていただきます。 (近年非上場になった為、直近の収益に関しては資料はありません。) 創業期、成長期を経て、一時停滞したものの、きちんと再度成長していることがわかりますね。 事業のステージに合わせて変化してきました 創業期、成長期を支えてきた組織構造 各部署内に宿泊・レストランチームが存在しています 各部署が都度エンジニアのマネージャーとコミュ
こんにちは。宿泊事業本部の宇都宮です。この記事では、GraphQLサーバ実装時に遭遇するN+1問題と、その解決のために使えるライブラリを紹介します。 フィールド単位でresolverを用意する N+1問題 GoのDataLoaderライブラリ DataLoaderの仕組み DataLoaderのサンプルコード DataLoaderとDataDog APM むすび 採用情報 フィールド単位でresolverを用意する GraphQLでは、クライアントのクエリに応じてオンデマンドに結果を取得できます。 たとえば、以下のクエリを投げると… { accommodation(accommodationId: "00001050") { name } } 以下のようなレスポンスが取得できます。 { "data": { "accommodation": { "name": "マンダリン オリエンタル 東
来週1/29(水)にエンジニア向けの採用PRイベントとして一休.comのプロダクト改善事例と開発の裏側を開催します。 一休では、主力サービスである 一休.com、一休.comレストランのプロダクト開発に関わるエンジニア職種の方を積極採用中です。 本イベントでは約2年に渡る一休.comのプロダクト改善の歴史を振り返りながら、実際に取り組んだ課題と改善に対するアプローチについてエンジニアリングマネージャーの田中(id:kentana20)がお話します。 トークセッションの後は、CTOの伊藤 (id:naoya) と2人でパネルディスカッションをしながら参加者のみなさまからの質問にもお答えします。 イベントの詳細、参加方法については以下のconnpassイベントページをご覧ください。皆様のご参加をお待ちしています! ikyu.connpass.com
こんにちは。 システム本部CTO室のakasakasです。 今回は、Datadog Log Management を使ってアプリケーション稼働モニタリングをしている話をしたいと思います。 一休のモニタリング周りの話 インフラのリソースモニタリング 外形監視 モニタリング観点で一休が抱えていた課題 Datadog Log Management Datadog Log Management からダッシュボード作成 Datadog Log Management からアラート作成 必要なメトリクスはカスタムメトリクスを作る graph_snapshot API を使って、デイリーレポート まとめ 最後に 一休のモニタリング周りの話 Datadog Log Management とアプリケーション稼働モニタリングの話をする前に、一休でどのような監視をしているのか?という話を簡単にします。 一休ではD
Amazon EKS Windows Container を使ってみる。 今年の10月に、Amazon EKSがWindows ワーカーノードのサポートを開始しました。 aws.amazon.com 一休では、今年の初めから、既存アプリケーションのEKS移行を行っており、夏には、ほぼすべてのLinux系アプリケーションをEKSへ移行することができました。 user-first.ikyu.co.jp これを踏まえ、Windows系のウェブアプリケーションもEKSへ移行できないか、技術検証を行っています。具体的な検証ポイントは以下のふたつです。 Amazon EKS で、Linuxコンテナ同様、Windows コンテナが動作するか。 既存のWindowsのWebアプリケーション(ASP.NETアプリケーションをDockerコンテナ化できるか。 2については、公開されている各種チュートリアルやサ
この記事は 一休.com Advent Calendar 2019 の18日目の記事です。 qiita.com 社内情報システム部 コーポレートエンジニアの大多和(id:rotom)です。 一休ではコーポレートIT、オフィスファシリティを中心に「情シス」業務を行っています。 皆さんはワークフロービルダー、使っていますか 👋 📑ワークフロービルダーとは ワークフロービルダーは、2019年10月にリリースされた新機能で GUI ベースで Slack 上のワークフローを作成し、業務の効率化を図れるものです。 slackhq.com すでに多くの解説記事があるため、ここでの詳細な説明は割愛しますが 有料プラン契約中なら追加料金不要で使える プログラミング不要で作成できる 様々なトリガーでアクションを自動化できる ことから自動化、効率化の中でも導入・運用のコストが低く、気軽に始めることができます
こんにちは。宿泊事業本部の宇都宮です。この記事では、GraphQLをベースに、GoとTypeScriptでスキーマを共有しながら開発を進める方法について紹介します。 この記事は 一休.com Advent Calendar 2019 の16日目の記事です。 GraphQLとは ライブラリの選定 コードファースト vs スキーマファースト Goによるサーバ実装 TypeScriptによるクライアント実装 おわりに 参考文献 GraphQLとは GraphQLは、Facebookによって開発された、Web APIのための クエリ言語 です。その特徴もSQLに似ていて、データの取得や更新を宣言的な記述によって行うことが出来ます。 仕様は公開されており、リファレンス実装として graphql-js がありますが、それ以外にも様々な言語でGraphQLサーバを実装できます。 GraphQLでは以下の
一休.com レストランを開発している所澤です。この記事は一休.comアドベントカレンダーの10日目の記事です。 先日、一休.comレストランの管理画面をリニューアルしました。 この記事ではその際にAPIの実装方法として採用したGraphQLについてフロントエンド視点で利点や使い所について述べます。 GraphQLについて以下の記事がわかりやすかったです。 「GraphQL」徹底入門 ─ RESTとの比較、API・フロント双方の実装から学ぶ - エンジニアHub|若手Webエンジニアのキャリアを考える! 短いまとめ 新しくAPIサーバーを書くなら是非GraphQLで! というくらい良かった Apolloのエコシステムに乗り切らなくてもいい。ふつうのRESTfulなAPIサーバーの代わりに、くらいの気軽さでGraphQLを採用してもいい プロジェクトの概要 今回リニューアルした一休.comレ
こんにちは。宿泊事業本部の宇都宮です。この記事では、GoのDIライブラリgoogle/wireの使い方を紹介します。 この記事は一休.com Advent Calendar 2019の9日目の記事です。 DIとは GoのDIライブラリ wireの使い方 Providerのエラーハンドリング Injectorのカスタマイズ Provider Set インタフェースのバインド 構造体のフィールドを参照する 細かな注意点 値とポインタの違いに注意 go runするときはwire_gen.goも一緒に おわりに DIとは DI(Dependency Injection, 依存性の注入)とは、あるオブジェクトが依存しているオブジェクトを自ら用意するのではなく、外部から渡してもらう(外部から注入する)というデザインパターンです。 例として、以下のように、監督の名前を渡すとその監督の映画を全てリストにし
qiita.com この記事は、一休.com Advent Calendar 2019の6日目の記事です。 こんにちは、nakashunです。 普段は情シスみたいなことをやっています。 今年のAdvent Calendarについて、Slackでこんなご意見を頂いたので書いてみます。 意外と表に出てこない、入社時に支給されるパソコンに加え 追加で購入する場合・交換する場合のルールも公開してみようと思います。 パソコンの購入・交換ルールの基本スタンス パソコンの購入・交換のルールについては、Qiita:teamで告知しています。 社員はQiita:teamを参照し、自分のパソコンを追加購入するのか・交換するのかを判断します。 上長の承認を得た後、情シスが購入手続きを行う流れになっています。 ルールを簡単にまとめると 故障修理・故障交換などを除く全てのPC購入にこのルールが該当するよ 購入するP
この記事は、一休.com Advent Calendar 2019の3日目の記事です。 qiita.com 宿泊事業本部のいがにんこと山口です。id:igatea UIUXチームでフロントエンドをメインに開発しています。 一休の宿泊予約サイト の一部のフォームではVue.js、およびVeeValidateを用いてフォームのバリデーションを実装しています。 そのVeeValidateのバージョンを 2.2.15 から 3.0.11 へ移行しました。 VeeValidateはメジャーバージョンが2と3では大きく仕様が変わり、破壊的変更が多数入っています。 この記事ではVeeValidateのV2とV3の記述の比較を行い、VeeValidateのアップデートの参考になる情報をまとめたいと思います。 ライブラリバージョン情報 Vue.js 2.6.10 VueValidate 2.2.15 → 3
こんにちは。宿泊事業本部の宇都宮です。 この記事は、一休.com Advent Calendar 2019の2日目の記事です。 今日は、一休.com( https://www.ikyu.com )にService Worker + Workboxを導入した件について書きます。 Service Workerとは Service Workerはブラウザのバックグラウンドで動作するJavaScriptで、PWA(Progressive Web Apps)の基盤技術です。 Service Worker の紹介 https://developers.google.com/web/fundamentals/primers/service-workers?hl=ja はじめてのプログレッシブウェブアプリ https://developers.google.com/web/fundamentals/cod
フロントエンドエンジニアのid:ninjinkunです。この記事は一休.comアドベントカレンダーの1日目の記事です。 一休.comレストランの管理画面リニューアルプロジェクトにおいて、CSSフレームワークのBulmaを導入しました。結論としては、採用して良かったと思っています。 このエントリではBulmaを選定した理由と、採用後に見えたPros / Consについて述べたいと思います。 なお今回リニューアルした一休.comレストランの管理画面の概要は以下の通りです。 レストラン店舗向けの管理画面 店舗の方と一休スタッフの両方が使う DAUは数千の規模 主な用途は在庫の管理と、プラン(コース)や席の管理 現在は店舗を限定してリリース済み 具体的には以下のような画面で構成されています。 UIフレームワークは必要か? まずそもそもUIフレームワークは必要かという議論があります。 今回のプロジェ
文責 はじめに 『KIWAMINO』をどうやって構築したのか WordPress と AMP プラグインで Canonical AMP サイトを構成した方法 インフラ ミドルウェア WordPress Lighthouse なぜ WordPress と AMP プラグインで Canonical AMP サイトを構成したのか (1) AMP の制約によって、サイトスピードが速くなるから (2) エンジニア・デザイナーの学習および開発コストが低いから (3) 巨大な組織・コミュニティの恩恵を受けられるから おわりに 採用情報 文責 新規プロダクト開発部の伊勢( id:hayatoise )です。 新規プロダクト開発部は一休の新規事業の開発とデザインを担当する部署です。現在、新規プロダクト開発部は主に『一休.comスパ』、『一休コンシェルジュ』および『KIWAMINO』を担当しています。 はじめ
以前の記事でも簡単に紹介した通り、一休では、アプリケーションのAWS Elastic beanstalkからAmazon EKSへの移行を進めています。 user-first.ikyu.co.jp この記事では、その背景や、実際の設計、実際にAmazon EKSを活用してみて気付いた点、困った点、今後の展望を紹介したいと思います。 AWS Elastic beanstalkの辛い点 新しい環境の構築や運用が大変 一休ではAWSのリソースをTerraformを使って管理しています。新しくウェブアプリケーションを立ち上げて、Elastic beanstalkで動かす場合、以下の作業をする必要があります。 Terraformで、Elastic beanstalkの定義を作ってリリースする。 新しいアプリケーションのデプロイを通知するように自前で作ったAWS lambdaを修正。 アプリケーション
以前の記事でも紹介した通り、一休では、gRPCを使ったサービスを導入し始めています。 user-first.ikyu.co.jp この記事では、このサービスをAmazon EKSで提供するための設計や気をつけたポイントについて紹介します。 背景 一休では、ウェブアプリケーションの実行環境としてAWS Elastic Beanstalkを採用しています。 そして、この4月からElastic BeanstalkをAmazon EKSへ移行するプロジェクトを進めています。 このgRPCサービスもElastic Beanstalkで運用をしていましたが、以下の問題を抱えていました。 適切にロードバランシングできない。 Elastic BeanstalkでgRPCサービスを運用しようとするとNetwork Load Balancer(NLB)を使うことになります。NLBはレイヤ4のロードバランサです
こんにちは。宿泊事業本部の宇都宮です。 一休では、基幹データベースにSQL Serverを使用しています。また、Goアプリケーションでは、go-mssqldbというライブラリを使用して、データベースとのやりとりを行っています。 このgo-mssqldbには、タイムゾーンに関して厄介な挙動があります。タイトルにもあるように、タイムゾーンが常にUTCになってしまうのです。本記事では、go-mssqldbのタイムゾーン関係の振る舞いと、go-mssqldbを使いつつ正しくタイムゾーンを扱うための対処法を紹介します。 go-mssqldbのタイムゾーン問題 go-mssqldbのタイムゾーン問題は、以下のコードで再現できます。 package main import ( "database/sql" "fmt" "log" "os" "time" // blank import必須 _ "gith
こんにちは。宿泊事業本部の宇都宮です。6月に、Go + gRPCという構成のサービスを運用開始したという記事を書きました。 Go + gRPCによるマイクロサービス構築 - 一休.com Developers Blog 本番運用開始から2ヶ月ほどたち、いくつかのトラブルがありつつ、現在も元気に稼働中です。 運用していく中で定常的に発生していたgRPCのタイムアウトエラーについて、その対処法がわかったので、紹介します。 なお、本記事の知見はC#でのgRPCクライアント実装においては有用でしたが、他の言語では適用できない可能性が高いです。各言語のドキュメントもあわせてご参照ください。 gRPCのタイムアウト 以前の記事で紹介したマイクロサービスは、30~60req/sec程度のリクエストを常時受け付けます。 社内のサービスの中で、このマイクロサービスに最も頻繁にリクエストを送るのは認証基盤で、
はじめに こんにちは。データサイエンス部の平田です。 一休でのデータ分析はJupyter NotebookやJupyter Labを用いてDWHにアクセスして行われることが多いですが、サービスそのものと分析環境が乖離していることにより、分析結果を継続的にサービスに取り込むのが難しい状況でした。 また、マーケティング部の方々がJupyterを使用して分析した結果に基づいて継続的に施策を行おうとしても、Airflowに組み込む際のエンジニアの負担はそこそこありますし、修正するたびに依頼をしなければならないなどコミュニケーションコストも発生します。 さらに、マーケティングに機械学習を取り入れたい場合でもairflow側で全部やってしまうと密結合になってしまいます。 そこで、Airflowから別の場所にあるJupyterを直接実行することによりエンジニアの負担は最小限にとどめ、自由に施策を打てるよ
レストラン事業本部の田中( id:kentana20 )です。 先週末にDevLOVE Xというイベントで開発組織改善の取り組みについて5年間の取り組みと今後、というテーマでお話しました。 5年間でどれくらい一休の開発組織が変わったのか 技術面 組織面 それぞれで実施した改善について、改善の裏側で起こっていたことや自分の所感も含めてお話しました。 現在の一休について7/4(木)にお話します 来週開催するエンジニア向けの説明会で、上記の5年間の取り組みを経て、現在の一休がどうなっているのかをCTOの伊藤がお話します。 ikyu.connpass.com 説明会と書いていますが、会社・事業や開発体制のお話だけでなく 現在の開発組織やプロダクトの状況がどうなっているか 今後どのように改善を進めていくのか を含めてお話する予定です。 一休で働くことに興味がある方だけでなく いまの現場を改善するため
こんにちは。宿泊事業本部の宇都宮です。 最近、とあるマイクロサービスをローンチしました。このアプリケーションの業務的な役割は諸事情により省略しますが、以下のような特性をもっています。 社内の多くのサービスから利用される 一休.com 一休.comレストラン 一休.comギフト 一休.com海外 このサービスが落ちると、主要サービスの予約処理が止まる 😱 想定されるリクエスト数は、平常時で30req/sec、ピーク時には60req/sec程度になります。行う処理はシンプルで、DBにいくつかSELECT文を投げて、ビジネスロジックに沿った結果を返すことです。 また、基盤系のアプリケーションなので、各開発者の開発環境(WindowsとMacが混在)でも動作する必要があります。 したがって、このアプリケーションに求められる要件は、 高パフォーマンス 高信頼性 クロスプラットフォームで動作すること
次のページ
このページを最初にブックマークしてみませんか?
『一休.com Developers Blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く