0時に寝て夜中に吐き気がして2回ほど起きて3時と5時に起きて8時に起きた。なかなか苦しい寝方をした。

ヤフートラベルと一休.comのシステム統合

アーカイブ公開されたらみようと思いつつ忘れてたので見返した。

雑なめも。また機をみて見返すこともあるかも。

  • バックエンドは完全に一休側に寄せるという大きな意志決定を2016年に行った
    • この意志決定はフロントエンド統合にも大きな影響を与えた
    • ふじもんさんの意志決定がよかった?
  • 今日の話しはマルチブランドデザインシステム統合がメイン
    • 開発者が50-60人程度で半年ぐらいで launch できた
    • nuxt/vuejs で開発している
    • スタイルは tailwindcss を使っている
    • 実は launch した後にこのシステムが必要だとわかった
      • 開発者とデザイナー間の細かい意思疎通が困難
      • 外部からデザインシステムに詳しい人にも来てもらっていろんな議論をした
      • ガイドラインを言語化するところから始め、最終的にソースコードの共有ができるようになった
    • 終わってからデザインシステムそのものは重要ではないと気付いた
      • この過程で開発者とデザイナー間のどのように共通化するか、あるいはしないかと議論を繰り返し行ったことが重要だったと当事者がインタビューで語っていた
      • デザインシステムの開発を通じてデザインの共通認識をもてたことがよかった
  • 波及効果
    • 同じソースコードから少し異なる体験の開発のノウハウができた
    • ふるさと納税に特化した宿泊予約サイトを作った
  • 統合は終わりではない、lauch したところが始まり
    • 統合後にいろいろな施策をすることで課題がみえてくることがある
  • 全国旅行支援は1つの開発で2つの体験をつくることができた
  • Q. デザイナーと開発者はわりと仲が悪いのでは?価値観や考え方が異なるのですり合わせるのは難しいのでは?
    • 過去の一休でも起きていた
    • 一休のチームはデザイナーと PM と開発者で構成されている
      • このチームが一緒に働いていてチームでなるべく意志決定している
      • 普段から一緒に働いていると仲が悪いということはなかった
      • とはいえ、仕事のプロセスが異なるので課題はあった
        • 地道に丁寧にすり合わせを行った
        • 外部から講師を読んで中立的な立場でワークショップを何度も行った
    • デザイナーと開発者を別の組織にしているとコミュニケーションの壁ができてしまうかもしれない

go の学び直し

テストの学び直し に引き続き、Gopher塾 #2 - Goらしいコードの書き方 - DAY 1 に参加した。

テストの次のプログラミングの話しだったので内容そのものは難しくはなかったけど、改めて重要な項目を選抜しているのだと考えると学びはあったと思う。参考になったことをいくつか覚えている範囲でまとめる。名前の付け方について感覚的に理解していたし、実際に私はそうしているけど、コードレビューしていて自然になっていないコードを指摘する機会も多いので一定の習熟を要するのかもしれない。いま毎週勉強会をやっていて私が講師として話している。ネタがなくなってきたり大変になったきたら準備の少ないコードリーディング会もやってみたいと思った。

  • google Go Style
  • derrors.Wrap
  • 名前に文脈を与えるという概念
    • 相対的な名前をつける
  • 準備の少ないコードリーディング会
    • お題(読むパッケージ)を決める
    • 選んだお題に期待することを当日話す
    • 時間を決めてみんなでそれぞれ読む(20分とか)
    • 読みながらSlackのスレッドにメモをしていく
    • 残りの時間で気になったところを議論する
    • 自分が気づけなかった点を知ることができる