Timee Product Team Blog

タイミー開発者ブログ

Rails の Service クラスの運用を CustomCop で厳格にする

タイミーでバックエンドエンジニアをしている新谷 id:euglena1215 です。

今回は社内で決めたコーディングルールに強制力を持たせるために CustomCop を作った話を紹介します。

背景

タイミーの Rails アプリケーションには /app/services ディレクトリがあり、 Service クラスが存在しています。

これまで社内で Service クラスは、なるべく使わない方が好ましいものの、どんな時に使っていいかは特段明言されていない状況でした。
その結果かは分かりませんが、一部の機能では Service クラスを多用し Service クラスが Service クラスを呼んでいるなど複雑になっており、コードリーディングの負荷が高まっていました。

この現状に課題感を持った @rhiroe が以下のような問題提起を行いました。

この問題提起を受け、チーム横断の技術領域ごとのトピックについて話し合うMTGで今後の Serivce クラスの運用方針は以下のように決まりました。

  • Serviceクラスは基本的に積極的な利用は推奨しない。
  • Service クラスは Controller や Sidekiq Worker から呼ぶものと位置付ける。それら以外から呼びたくなった場合は Model の作成を検討すること。

方針についてバックエンドエンジニア全体に周知は行われましたが、あくまで「きちんと覚えておきましょうね」に留まり、仮に実装者とレビュアーが思い出すことができなければそのままマージされてしまいます。

そのため「このルールを機械的に適用できるといいよね」という話があり、用途に合わせた CustomCop を作ることになりました。

特定のsuffixを持つクラス以外からのサービスクラス呼び出しを警告する cop

早速ですが、CustomCop の実装をまるっと公開します。

# frozen_string_literal: true

begin
  require 'rubocop'
rescue LoadError
  return
end

module CustomCops
  # 特定のsuffixを持つクラス以外からサービスクラスを呼び出した場合に警告します。
  # AllowSuffix は config パラメータで設定できます。
  #
  # @example
  #   # bad
  #   # AllowSuffix に Service が含まれていない場合
  #   class SampleService
  #     def call
  #      Service2Service.new.call
  #     end
  #   end
  #
  #   # good
  #   # AllowSuffix に Service が含まれている場合
  #   class SampleService
  #     def call
  #      Service2Service.new.call
  #     end
  #   end
  #
  class AllowServiceCallClassSuffix < RuboCop::Cop::Base
    MSG = '特定のsuffixを持つクラス以外からサービスクラスを呼び出すことはできません。%<suffixes>s のみが許可されています。'

    # ① 許可されている Suffix を持つクラスの定義かどうか
    # ② クラス定義の中で更にクラスかモジュールを定義しているかどうか
    #    この cop で重要なのは最も深いクラス定義での情報なのでネストしているものは無視(≒許容)する
    def_node_matcher :define_allow_class?, <<~PATTERN
      {
        (class (const ... #allow_class_name_suffix?) ...)
        (class const ... {class module})
      }
    PATTERN

    # (send (const nil? #service_class_name?) :new ...)  => FooService.new(...)
    # (send (const cbase #service_class_name?) :new ...) => ::FooService.new(...)
    # (send (const const #service_class_name?) :new ...) => Bar::FooService.new(...)
    def_node_matcher :call_service_class?, <<~PATTERN
      (send (const {nil? cbase const} #service_class_name?) :new ...)
    PATTERN

    # on_class はクラス定義が行われた時に呼び出されるメソッド
    def on_class(node)
      # 許容されるクラスであれば無視する
      return if define_allow_class?(node)

      node.each_descendant(:send) do |send_node|
        # サービスクラスの呼び出しをしていれば警告する
        add_offense(send_node, message:) if call_service_class?(send_node)
      end
    end

    private

    # AllowSuffix で指定した suffix を警告メッセージに加えたかったので上書きしている
    def message
      format(MSG, suffixes: allow_suffixes.join(', '))
    end

    # call_service_class? マッチャで使っている
    def service_class_name?(name)
      name.to_s.end_with?('Service')
    end

    # define_allow_class? マッチャで使っている
    def allow_class_name_suffix?(name)
      allow_suffixes.any? { |suffix| name.to_s.end_with?(suffix) }
    end

    def allow_suffixes
      # `cop_config` で rubocop.yml で指定した設定を取得できる
      @allow_suffixes ||= cop_config['AllowSuffix'] || []
    end
  end
end

rubocop.yml には以下のような記述を行います。

CustomCops/AllowServiceCallClassSuffix:
  AllowSuffix:
    - Controller
    - Worker

どんな cop かを軽く説明します。
rubocop.yml で指定した AllowSuffix を suffix に持つクラスからの Service クラスの呼び出しを許容し、それ以外のクラスからの呼び出し時には警告を出します。

タイミーでは、Service クラスに XXXService.call のような特異メソッドを用意せず、 XXXService.new.call というようにインスタンスを作成した上で呼び出すことが通例となっているため XXXServicenew メソッドが呼び出されたことを検知しています。 ここは、各社の通例に合わせてもいいですし、任意のメソッドを呼び出したことを検知しても良いと思います。

また、 service_class_name? メソッドではクラス名の suffix が "Service" かどうかをチェックしていますが、ここを変更すれば Service クラス以外にも適用可能です。 Model, View, Controller 以外のレイヤを採用している Rails アプリケーションであれば、Service クラス以外でも呼び出し箇所を制限したいことがあるかもしれません。

結果どうなったか

上記の CustomCop をタイミーの Rails アプリケーションに導入した結果、違反している箇所が67件見つかりました。違反しているファイルを rubocop_todo.yml から眺めてみると、Model から Service を呼び出しているケースと Service から Service を呼び出しているケースが半々くらいのようです。

2024/01/24 時点では、導入したばかりでこれらの違反を解決するための動きは取れていません。 ですが、増やそうとすると RuboCop に怒られるのでこれ以上増えることはないのではないかと考えています(そう信じています)。

タイミーのプロダクトは 1つのモノリスRails アプリケーションの上で動いています。その中での67件が多いか少ないかはみなさんの判断にお任せします。我々はこれが伸びしろだと捉え、がんばっていこうと思います。

仕事と育児と、それから社会人大学院

はじめに

こんにちは、株式会社タイミーのデータエンジニアリング部データサイエンス(DS)グループ所属の貝出です。

私は現在タイミーで働きながら、育児しつつ、社会人大学院(修士)に通っています。今回のブログでは、仕事・育児・社会人大学院をどう調整して進めていくかについて書いていきたいと思います。

私自身の事例

簡単な私のプロフィールとしては、以下となります。

  • 妻と一歳の息子の三人家族
    • 妻は2023年度までは育休を取得予定
  • タイミーで週5リモートワーク勤務
  • JAIST博士前期課程社会人コースの社会人大学院生(2023年4月から)

となります。

もともと大学時代では別分野を専攻していたということもあり、業務を進める上で情報科学の知識や研究経験が十分でないことに課題を感じていた私は、妻の後押しもあり、2022年2月頃に社会人大学院への進学を決意しました。研究室の先生や前職の同僚の助けもあり、無事にJAISTに入学することができました。

ただ、入学することよりも修了することの方が何倍も大変であり、そのためには、育児と仕事をこなしつつ、日々の学習や研究を進める必要がありました。

日々の学習・研究時間の確保

社会人大学院生は、通常の大学院生に比べて圧倒的に時間が足りなくなります。それに加え、育児によりさらに時間がなくなります。そのため、どうにか工夫をして時間を捻出する必要がありました。

時間を確保するアプローチとして、個人的には以下をとっています。

  1. 育児との折り合いをつけ、時間を確保する
  2. 日々の学習や研究を効率的に進める

育児との折り合い

基本方針としては、子供が寝ている間に学習・研究時間の確保が可能です。そのため、

  • 朝5時に起き、子供が起きるまで集中的に時間を確保する
  • 子供の寝かしつけが終わってからの時間を確保する

ができます。私の場合は、早朝の 5:00~7:00 と、夜の 21:00 ~ 22:30 のあたりを確保しています。ただ、子供が6:30ぐらいに起きることもあるので、そのときは早めに切り上げたりしています。

パートナーや家族のサポートの重要性

あとは、週末や休日の仕事がないとき、妻に子供を見てもらっている時間に、学習・研究時間を確保します。ただし、ここについては家庭内で十分コミュニケーションを取り、妻の理解を得ることが必要です。また、夫婦間でバランスが崩れないように調整することも必要です。

自分が子供を見る時間は、一緒に公園や近所の公民館に行き、妻のフリーの時間をなるべく確保できるように努力しています。最近は歩けるようになって、すごく楽しそう!

日々の学習や研究の効率化

時間を確保するアプローチの2つ目として挙げた、「日々の学習や研究を効率的に進める」を実施するために、

  • 効率的な進め方に関する文献を調査し、実践する
  • テクノロジーを活用したツールに惜しみなく投資する

を行っています。

効率的な勉強法や研究の進め方の文献

効率的な勉強法や研究の進め方ってそもそもどうやんの?というところを現役の学生になったつもりで再度勉強しました。参考になった本としては、以下の本があります。

学習については、「(1)こまめに復習をする と (2) 覚えたことをアウトプットする(口に出す、空で説明する、書く)」を大事にしています。あとは、時間を決めて集中できるようにして取り組むなど。

一年目は講義に集中していたため研究はあまり進んでいないですが、先程挙げた本を参考に研究の効率化も進めればと考えています。

社会人の特権のツールへの投資

社会人と現役の学生の最大の違いは時間とお金だと思っており、社会人は時間がない分、仕事で稼いだお金を使って自身の学習への投資が可能になります。

私のケースだと、論文読みやノートのために iPad Air を購入しました。便利なアプリとしては以下を利用しています。

  • Good Note 6(電子ノート)
  • Paperpile(論文管理ツール)
  • Kindle(本)

これらのツールを用いることで、ノートや本、論文を持ち歩かなくても、どこでも学習や論文読みが可能になります!

Good Note 6 は、空白のノートだけでなく講義のスライドも読み込めるので、デジタル上でスライドに書き込めるところがとても便利です。

Paperpile は論文管理ツールですが、講義の Class Note や PDF形式の教科書として読み込んでも便利です。例えば、目次や式の番号をパースしてくれて、リンクとして飛べるようになっているので、読む効率が上がります。自分の認識している範囲だと、Good Note 6にはこの機能がないので、使い分けています。ペンやマーカーなどの書き込む機能については、Good Note 6の方が自由度が高いですね。

ストレス管理と心の健康

日々の限られた時間の中で、仕事と育児、それから社会人大学院とたくさんやることがあり、生活に余裕がなくなってしまい、知らないうちにストレスを溜めてしまうことがありました。それが原因で、眠れなかったり、いらいらしたりしてしまうこともありました。心の健康を保つためにもストレス管理に注意する必要があります。

私が気をつけるようにしていることは、

  • 1,2 時間ぐらい机で作業した後は、10分ぐらいふらっと散歩したりストレッチしたりする。
  • 頭が疲れて回らない場合は、ぼーっと10分ぐらい何もしない、何も考えない(瞑想といえば瞑想)。
  • 眠いときは遠慮せずに寝る
  • 定期的に家族内や友達のイベントを作って、全力で楽しむ
  • ジムに行ったり、ジョギングをしたりなど、定期的な運動の習慣を作る
  • 1日の最後は夫婦でおしゃべりをして、リラックスする

です。

また、学習や研究がどうしても予定通りにいかないことがあります。子供が熱で体調を崩したり、急遽別の予定が入ったりなど。また、自分のタイムマネジメントがうまくいかず、思ったように学習や研究が進まないこともあります。

そのようなときは一旦無理なスケジュールを引いている状態を認識して、緊急度と重要度のマトリクスを作成し、優先度の低いものからは撤退するようにしています。やっぱり無理なものは無理なので。

タイミーという最適な環境

さて、これまでは育児や大学院での過ごし方などプライベートに関する話がほとんどでしたが、冒頭にも書いた通り、タイミーでは育児や自己研鑽への支援制度があり、私のような技術職には大変ありがたい環境となっています。

育児への支援制度

タイミーでは産休・育休とは別に以下の制度があります。

  • 出産休暇:配偶者が出産する際、産休・育休とは別に、出産当日までの間で3日間の特別休暇を付与(有給)
  • 子の看護休:子どもの看護を目的に、子ども1人につき年間5日付与(子ども2人以上は10日が上限)

corp.timee.co.jp

自己研鑽への支援制度

また、タイミーではエンジニアの市場価値向上につながる成長支援、学習支援、機会提供、生産性向上に資する取り組みも実施しています。そのための組織として DevEnable 室を設立し、「TDE10(Timee Dev Enable)」という、エンジニアの進化のための10の施策が進められています。

devenable.timee.co.jp

DSグループでの働き方

DSグループでは、フルリモート勤務も可能であり、フレックスタイム制コアタイム12:00~16:00/所定労働時間8時間00分、休憩60分)であるため、個人の状況にあわせて働き方を調整することができます。実際に、保育園に通っているお子さんがいる社員は、保育園へのお迎えの時間にあわせて就業時間を調整していたりします。

まとめ

今回の事例では、私のケースが育児と社会人大学院の両立というレアなケースでしたが、タイミーでは働きながら育児や自己学習に取り組む社員がたくさんいます。当社は多様な働き方が可能な職場環境を提供し、柔軟でサポートが充実している条件のもと、異なるバックグラウンドやライフスタイルを持つ方達が活躍しています。

現在、タイミーではデータサイエンティストやエンジニアなど、一緒に働く新しいメンバーを積極的に募集しています!

また、気軽な雰囲気でのカジュアル面談も随時行っておりますので、ぜひお気軽にエントリーしてください。↓

hrmos.co

hrmos.co

タイミーのデータアナリストの一日

自己紹介

こんにちは、タイミーのデータアナリストチームの一員、胡です。

私の日本でのキャリアは約10年前、早稲田大学院でMBA取得を目指して来日したことから始まりました。 学位取得後、開発ベンダー企業でエンジニアとしてキャリアをスタートし、その後中小企業でシステム統括の責任者、製造業のベンチャー企業での経験を積みました。

これらの職場で、データに関する多くの課題に直面し、自らの手で社内のデータ環境を整備することもありました。 この経験が、データアナリストとしてのスキルを磨く大きな契機となり、最終的にタイミーでのキャリアをスタートさせるに至りました。

プライベートでは、2歳になる娘を持つ三人家族の一員として、忙しい日々を過ごしています。 最近では、趣味と言えばすっかり子育てに夢中になっています。子育ては日々の新しい発見と喜びに満ちており、私の人生にとって大切な部分です。 家庭と仕事のバランスを保ちながら、日々成長を続けていけたらと思います。 タイミーで働くことで、充実したキャリアを築きつつ、家族との時間も大切にすることも可能です。

部署紹介

タイミーは、急速に成長を遂げているベンチャー企業です。その成長の基盤の一つが、私たちデータ統括部です。

データアナリストは、現場のチームと協力しながら、実際の業務に即した分析を行っています。また、経営層との密接な連携を通じて、経営に関する直接的な提案を行うことも可能です。

私はプロダクトアナリティクスチームに所属し、プロダクトの改善と向上に日々貢献しています。同じ部署での同僚であるtakahideさんの記事も参考になるでしょう。> takahideさんの記事はこちら

今日は、タイミーのデータアナリストとしての一日を紹介し、私たちの業務の流れを具体的にお伝えします。それでは、さっそく始めていきましょう。

一日の流れ

朝のルーチン:

朝は7時頃に起きます。家族との朝食は一日の始まりの大切なひととき。 娘を保育園に送り出した後、9時前後に自宅の仕事スペースへと移動し、一日の業務をスタートします。 仕事を始める前に、短い時間を使ってメールのチェックや一日のスケジュールを見直します。

午前中の仕事:

9:00~11:00 フォーカス課題の分析

直近のフォーカスしている課題として、時給と勤務状況の関係性に関する分析です。

こちらは、プロダクトマーケティング(PMM)部と連携しながら進めており、得られたデータから新たなビジネス洞察を得ることが目標です。

フォーカス課題は、担当する部署の目標から派生した課題や、日々の業務から得た気付きに基づく自由研究も含まれます。

進め方としては、議論を重ねて仮説を立てて、それを検証していくサイクルを回します。この過程に置いて、PMM部との協力は非常に重要です。彼らの市場に対する深い洞察と私たちのデータ分析能力が相乗効果を生み出すことで、最終的には、この分析がプロダクト機能の拡張という形で実現されることを目指しています。

11:00~11:30 データアナリスト全体のデイリーミーティング

この時間帯は、データアナリストチーム全体でのデイリーミーティングを行います。

ここでは、チーム全員で共通の連絡事項を共有し、データアナリスト部向けの依頼タスクの対応方法について話し合います。通常、このミーティングは30分間設定されていますが、内容によっては早く終わることもありますし、新しいアイデアや施策につながる議論が盛り上がることもあります。

依頼タスクについて少し詳しく説明します。現在、私たちのチームはマーケティング、ビジネス、プロダクトといったユニットごとに分かれており、各ユニットは通常、特定の課題に集中しています。しかし、全社からのデータ抽出依頼が多数寄せられるため、これらに対応するにはチーム全体でリソースを効率的に調整する必要があります。

Lookerの導入と普及により、多くのデータ抽出は各部署が自力で行えるようになりましたが、複雑なデータ集計やLookerで対応できない項目がある場合は、依然として私たちのチームへ依頼が来ます。

これらのタスクは専門性を要求されることは少ないですが、緊急性が高く迅速な対応が求められます。メンバー一人ひとりがこれらのタスクに取り組む頻度は、週に1回くらいです。

11:30~12:00 他のメンバーのクエリレビュー

一般的に、私たちの日常的な課題や依頼タスクの成果物は、データを抽出した後、そのまま提出して完了となります。

しかし、社外向けの資料や財務に関わるデータなど、特に正確性が重要視される場合があります。こうした場合には、原則としてレビュワーを割り当てて、二重チェックの体制を取ります。

この二重チェックプロセスは、データの品質を保証し、エラーや誤解を防ぐために不可欠です。レビューは、データの正確性だけでなく、使用される分析方法や導かれた結論の妥当性についても検証します。

これにより、提供するデータと情報の信頼性を向上させ、私たちのデータアナリスト業務の品質を高めることができます。

昼休憩:

昼休憩の時間は、日によって多少前後することがありますが、基本的には冷蔵庫にある食材を使って手早く料理を作り、食事をします。

時間が許せば、10〜15分の短い仮眠をとることもあります。

午後の仕事:

13:00~13:30 依頼タスクのヒアリング

午前中にアサインされた依頼タスクの取り組みに先立ち、依頼者へのヒアリングを行います。依頼タスクの要件は通常、事前に依頼者によって文書化されていますが、より詳細な情報が必要な場合はさらなる確認が行われます。

このステップは必ず行うわけではなく、要件が明確に定義された場合は、成果物を作成した後に依頼者とイメージをすり合わせたり、結果を直接チャットで伝えたりすることもあります。

  • 使い道の確認
    • 抽出データがどの程度の規模で、どれくらいの期間使用されるかを確認し、それに基づいて適切な出力形式を提案します。また、抽出データが他の目的にも汎用的に使用できる場合、今後の依頼タスクでの流用の可能性を検討して作成していきます。
  • 項目の定義のすり合わせ
    • 項目によっては、部署ごとに基準が異なることがあります。そのため、集計条件や項目の定義を明確にしておきます。
  • 抽出項目の提案
    • 時に依頼者がデータに関するリテラシーが低い場合や、要件が十分に記載されていない場合があります。このような状況では、実際に求められている内容を詳しくヒアリングし、最適な出力方法をアドバイスします。

13:30~14:30 依頼タスクの対応、納品

先ほどヒアリングで得た結論に基づいて早速作業に取り組みます。タスクの難易度にはばらつきがあるため、完了までの時間はさまざまです。通常は30分から60分で完了するタスクもありますが、依頼者との段階的なやりとりが必要な場合は、全体として数時間を要することもあります。

14:30~16:30 フォーカス課題の分析

午前中に取り組んでいたフォーカス課題の分析作業を続けます。この作業には、集中を要するため、中断されることなく継続的に取り組むことが重要です。そのため、あらかじめスケジュールをブロックしておくことで、分析に専念する時間を確保できます。

16:30~17:00 定例ミーティング(部署連携の持続PJT)

データ統括部以外の部署と協力して進めている持続的なプロジェクトの定例ミーティングを行います。プロジェクトの性質によって、その期間は通常数週間から数ヶ月に及び、状況に応じて定例ミーティング以外の方法での連携も行われることがあります。

この定例ミーティングでは、私が社内でリリースした営業用ダッシュボードの利用状況と改善点に重点を置いています。このダッシュボードは社外向けで、営業活動における重要なツールとして利用されています。現在、社内で最も頻繁に参照されるダッシュボードの一つであり、営業効率の向上と営業レベルの平準化に大きく寄与しています。

17:00~18:00 採用面接

急速に拡大しているタイミーでは、新たな才能とスキルを持つ仲間を増やすことが非常に重要です。

面接では、候補者の技術的能力やチームとの相性、将来のポテンシャルを評価します。これには、専門的なスキルだけでなく、組織文化への適合性やコラボレーション能力も含まれます。私たちは、優秀な人材を見極め、チームと会社全体の成長を支える人材を採用することを目指しています。

18時から中抜け(あるいはそのまま退勤):

一日の仕事を終えた後の夕方は、家族との大切な時間です。

最初に保育園に娘を迎えに行き、その後は家で夕食の準備に取り掛かります。家族みんなで食事を共にし、その後は子供と一緒に楽しいバスタイムを過ごします。

毎晩ではないものの、娘が就寝する時間が近づくと、その準備は妻が担当し、私はその間に追加の仕事に取り組むことがあります。

20~21時以後:

20:00~20:30 面接の議事録完成、評価の完了

行われた面接に関する議事録のまとめや、面接評価を行います。

また、この時間を使って追加分析やタスクの整理を行うこともあります。あるいは、そのまま切り上げてプライベートで映画や読書などに充てることもあります。

こちらは私のある一日の過ごし方です。タイミーでデータアナリストとして働く中で、仕事とプライベートのバランスを保ちつつ、様々な課題に取り組む毎日を送っています。 いかがでしょうか。少しでもタイミーでのデータアナリストとしての仕事のイメージをつけたら幸いです。

勤務体系

データ統括部では、フルリモートワークが可能であり、始業時間も柔軟に設定できます。これにより、私たちは自分のライフスタイルに合わせた働き方を選ぶことができます。

私の場合、育児のため、18時には仕事を切り上げることができます。これにより、家族との時間を大切にしながら、効率的に業務を進めることが可能になっています。

さらに、最近は娘が月に一度程度熱を出すことがあり、その都度スケジュールを調整したり、同僚からのサポートを受けたりしています。タイミーでは、このような状況にも柔軟に対応しやすい環境が整っています。

We’re Hiring!

私たちは、ともに働くメンバーを募集しています!!

カジュアル面談も行っていますので、少しでも興味がありましたら、気軽にご連絡ください。

Regional Scrum Gathering Tokyo 2024に参加しました(エンジニア編)

タイミーのyama_sitter、須貝、小林です。

国内最大級のアジャイルスクラム関連のイベント「Regional Scrum Gathering Tokyo 2024(RSGT2024)」 が1/10〜1/12の3日間にわたって開催されました。

2024.scrumgatheringtokyo.org

タイミーには世界中で開催されるすべての技術系カンファレンスに無制限で参加できる「Kaigi Pass」という制度があります。

productpr.timee.co.jp

こちらの制度を利用して今年はスクラムマスター3名、エンジニア3名が参加してきました。

前編に続き、後編の今回はエンジニア3名から参加レポートをお送りします。

SM/EMからエンジニアに視点を変えて参加

エンジニアの yama_sitter です。

参加は今年で2回目になります。前回は前職からSM/EMの立場として参加しましたが、今回はタイミーの現場エンジニアという立場で参加する形となりました。

「エンジニアからSMになり、EMを経てエンジニアに戻った人」という視点で、特に印象に残ったセッションが3つありましたので紹介します。

  1. Badプラクティスを選んで失敗しながら進めた新規プロダクト開発

    自分はSM時代に「形」に捕らわれ過ぎて色々な失敗を重ねてきました。一方で今所属するチームではいわゆるスクラムの形式では仕事をしておらず、それでもちゃんと成果が出せている状態です(※1)。これらの経験から、この1年ほどは「アジャイルは形じゃない」というのを自分なりに理解し、また考え続けていました。(この間、世に出回る「べき論」や「プラクティス」みたいなものをとにかく疑ってかかっていました)

    そんな中見たのがこの「Badプラクティスを選んで~」のセッションです。ここでは世間的にはNGとされるプラクティスを敢えて用い、(もちろん苦しみながらも)ちゃんと成果を出した事例が語られていました。Badと言われるものだと分かった上で、そのリスクを理解し取り入れ、結果に結び付ける。このあり方は教科書的でこそないものの、ちゃんとした一つの解だなぁ、と。

    つまるところ「価値に向き合い、自分たちが考えうる/持ちうる最大の力で成果を生み出す」ことが重要なのであって、形ではないなという話です。今の自分が感じていることを後押しし更に前に進めてくれたこのセッションは非常に有意義なものでした。

    こちらはスライドもあるので是非ご一読を。

    speakerdeck.com

    ※1 あくまで会社全体としてはスクラムに力を入れており、自チームは特殊なケースです

  2. Lack of curiosity: The silent killer of agile

    「好奇心の無さはアジリティを殺す」という話です。内容は勿論ですが、特にこのタイトルが強く印象に残っています。

    入社して半年、以前考えていた抽象的な問いからは離れて今はひたすらに具象と向き合っています。入社直後に感じていた様々な疑問も少しずつ薄れてきました。アウトプットこそ出せているとは思います。が、少しずつ「疑問に思う力」や「ワクワクする力」がマヒしていっているのを感じています。

    これだと、本当に向き合うべき課題に気付き向き合うことができないんですよね。セッションでも述べられていましたが、「人間はルーチンが好き」なので尚更です。

    自分や目の前のコードとひたすら向き合うだけでは高い視点からは物事を考えられません。疑問に思わなければ脳が刺激を受けずに鈍化していきます。ワクワクしていなければ途中で力尽きます。結果として気付ける課題、向き合う課題がすごくミニマムになっていく。

    現場にフォーカスするだけだと、巡り巡って良いエンジニアにはなれないなぁ、ちゃんと好奇心を持ち続ける努力をしないとなぁ、と感じさせるセッションでした。

  3. Solving The Value Equation

    「レガシーコード改善ガイド」の著者であるMichael Feathersさんのキーノートです。

    めちゃくちゃためになる話ばかりでしたが、個人的に刺さったのは「プロセス、アーキテクチャ、チームの能力、組織構造といった各レイヤーの目標は、 “価値に至るまでのプロキシ” でしかない」という話です。

    “プロキシ” というのが特に良くて、これを意識すると「今の取り組みとその結果は、必ず何らかの価値に転換されるために存在する」という考え方ができます。当然のことではあるんですが、目の前のことにフォーカスしたり「べき論」に囚われたりすると忘れがちだなぁ…と思ったりします。

    余談ですが、前職のSM最初期の頃は「それっぽいメトリクス」を見つけては右往左往していました。あれはあれで必要なプロセスだったものの、できればこの “プロキシ” の考え方を持っておきたかったです。

視点を変えての参加となりましたが、選ぶセッションも見るスタンスも感じることも得られるものもかなり違うし、得るものの幅が増えていることに気付いて面白かったです。一度全力でSMをやってからエンジニアに戻ると面白いですね。

とまぁここまで色々書きましたが、正直セッションよりも「素晴らしいセッションを見たあとに同じ熱量を持ったタイミーメンバーと集まり、酒を飲みながら議論する」時間が一番良かったです。こういった時間のために行っているフシすらある。

総じて、RSGTは今年も良いイベントでした。企画/運営の皆さま、ありがとうございます。

メンバーと自分たちの組織について語り合うきっかけに

エンジニアの須貝(CSM保持)です。

RSGTは今回が初参加でして熾烈なオンサイトチケットの争奪戦を勝ち抜いて現地に行ってまいりました。自分は現在はマネージャーでもスクラムマスターでも無いのですが、以前からチーム・組織で成果を出すにはどうすれば良いかといったテーマに興味があったので参加しました。

基本はセッションを聞くことを中心に、合間の休憩時間などで知り合いの方とお話をして過ごしました。中でも印象に残ったセッションのひとつはJoe Justiceさんの「ジョーが語る、Teslaでの衝撃的な開発スピード」です。電気自動車メーカーTeslaの開発サイクルのあまりの速さに本当に自動車の開発なのか!?と驚きの連続でした。と同時にハードでこのスピードでできているのだからソフトウェア開発をしている自分たちももっとやれるのでは、勝手にできないと思っているだけなのでは、という反省もありました。

オフトピックなところだと会場内でプロのカメラマンに写真を撮ってもらえるフォトブースがあったのが良かったです。Global Scrum Gathering Amsterdamで行われていたものが日本にも輸入されたそうです。

プロのカメラマンに撮影されるりっきーさんとShinoPさん

自分たちは普段フルリモートなので、弊社のメンバーと自分たちの組織などについて対面でじっくり話せたのも非常に良い体験でした。チャンスがあればまた参加したいと思います。

RSGTは気づきと学びの場

こんにちは!タイミーでQAスペシャリストを担当している小林依光です。

RSGTはオンラインで参加しましたが、今回も「やっぱりそうだったんだ」と自分の知識や経験を後押ししてくれる発表内容に、感謝の気持ちでいっぱいになりました。 事例/実績、考え方の共有は気づきと学びの場だと、改めて思いました。 少しですが、私が気になったセッションについて、紹介したいと思います。

ベロシティ Deep Dive」ではベロシティを生産性に活用することをやめましょう!ということを多様な角度から説明していました。どの角度からの説明も納得感のあるものばかりでしたが、一番印象的だったのが、“アジャイルスクラムが目指すのは価値の実現であり、この文脈での生産性は「付加価値生産」である”という説明でした。アジャイルを採用し探索的/実験的にプロダクトを開発し価値を提供するという基本を忘れてはいけないと学べました。

プロダクトをあきらめるとき」のセッションは一般的なスクラムの話ではありませんでしたが、実際のプロダクト開発で遭遇する実例でした。特に“プロダクトを終了させるときの費用”をプロダクトバックログの順位の下の方に入れておくという考えには共感でき、あきらめる判断やサービス撤退に必要な洗い出しは、プロダクトを止めるときでなく開発を始める際に決めておく必要があると何度か痛感していたので、改めていままでの経験は役に立つことがあると思いました。

紹介したセッション以外からも多くを学べたRSGT、来年は現地で参加できるようにしたいと思いました。

まとめ

いかがでしたでしょうか。

参加して満足して終了では意味がない!ということで後日参加者全員で振り返り(Fun Done Learn)も行いました。しっかりとネクストアクションも生まれたので、ここからチーム・組織に今回得た学びを還元していければと思います。

来年もまたGatheringしましょう!

Regional Scrum Gathering Tokyo 2024に参加しました(スクラムマスター編)

タイミーのmaho、ShinoP、りっきーです。

国内最大級のアジャイルスクラム関連のイベント「Regional Scrum Gathering Tokyo 2024(RSGT2024)」 が1/10〜1/12の3日間にわたって開催されました。

2024.scrumgatheringtokyo.org

タイミーには世界中で開催されるすべての技術系カンファレンスに無制限で参加できる「Kaigi Pass」という制度があります。

productpr.timee.co.jp

こちらの制度を利用して今年はスクラムマスター3名、エンジニア3名が参加してきました。

その参加レポートとして印象に残ったセッション、ワークショップや学びなどを参加者それぞれの視点で共有できればと思います。今回は前後編の前編としてスクラムマスター3名のレポートをお送りします!

初参加でOSTのホストに挑戦

スクラムマスターをしているmahoです。RSGTは今回が初参加で緊張していましたが、一緒に現地参加するメンバーがいたので心強かったです。

私はまだまだスクラムマスター初心者ということもあり、セッションを聴いて学びを深めることを一番の目的にしていました。どのセッションも興味深い内容でしたが、全体を通して感じた共通点は以下の三つです。

  • チームの基盤を支える重要な柱のひとつは関係性であること
  • 変化は時間がかかることを理解して忍耐を持つこと
  • システム全体を捉えるよう努めること

私もこれが体現できるように、学びを実践しながら精進していきたいと思います。

また、三日目のOSTには話したいテーマを発表し、ホストとしての参加に挑戦してみました。不安でいっぱいの中、いざ始まってみると集まってくださった方々と予想以上に議論が盛り上がり、とても楽しい時間を過ごすことができました。セッションを聴くだけでなく、Gatheringとしてもよい体験ができたので、もし次回も参加することになれば、より積極的に話す機会を作ってみたいと思いました。

どう社内に持ち帰るかを話す時間は何事にも変え難い

タイミーでスクラムマスターをやっているりっきーと申します。昨年に引き続き2回目の現地参加になります。

私は毎年年末にテーマを決めていまして、1年かけて達成したかどうかを振り返っています。

その中で、RSGTは年初一発目ということで年末に決めたテーマについて知見を得たり、ディスカッションをできるので非常に助かっています。

私の本年度のテーマは「スクラムマスターとして成長できる・やってみたくなる環境を作る」です!

テーマに最も関連していたので以下を紹介いたします。

スクラムマスターを職能にする挑戦 - 健全なチームを増やし組織をチームワークであふれさせる道のり

スクラムマスターをどのように増やしていったか、どのような仕組みを作っていったかは大変参考になり、勇気がもらえました!

1on1やコーチング、メンタリング活動は弊社としても取り組み始めていたのですが、給与レンジの検討や成長支援の予算などは検討できてない部分なので弊社ならではを組み合わせつつ、一つの事例として社内に紹介したいと思います。

また、メンターとしては初心者の方もRSGTで楽しめるように社外の人との会話に入ってもらったり、OSTに参加するように促したりを裏目標として持っていましたが、楽しめたようで何よりでした!

皆さんも書いてますが、同じものを見て聞いてそれについてどのように社内に持ち帰るかを話す時間は何事にも変え難いので、来年も参加したいなと思いました。(オフライン参加は難しいかもしれませんが)

RSGTのオススメの歩き方

こんにちは!タイミーでスクラムマスターをしているShinoPです!

今回のRSGTは現地参加としては2回目なのですが、前回はセッションを聴くことに夢中になっていて、本当の意味でのGatheringができませんでした。

その中でもOSTのホストをやった事で、参加者同士の触れ合いを体験しGatheringの本当の意味を理解しました。

ですので、セッションに関しての感想というよりは、RSGTのオススメの歩き方を紹介したいと思います!

今回のRSGTでの立ち回りはセッションを聴くだけでなく…
「廊下で初めて会った人と話す」
「お昼に社外の人と話す」
「研修やコミュニティーで面識のある人と話す」
「登壇者と話す」
「飲み会に参加する」
「お昼の30秒宣伝コーナーで話す」
などを積極的に行った結果、同じような悩みを抱えている方と話すことによってヒントを得られたり、登壇者の方と話してアドバイスをもらったり、面識のある方々とワイワイできたり…このような歩き方も学びがあるので是非試してみてください!

また、RSGTやスクラムフェスは人に話しかけやすい構造になっていると思いますので、隣に座っている人とかに話しかけたりすると繋がりが広がっていくと思っていますので、是非思い切って話しかける事がオススメです!

今回のレポートは以上となります。
続きの後編は「エンジニア編」として近日公開予定です。

社内版 Rails アップグレードガイドを公開します

こちらはTimee Advent Calendar 2023 シリーズ1の25日目の記事になります。
昨日は @tomoyuki_HAYAKAWA による Swift Concurrency AsyncStreamを使ってみる #Swift - Qiita でした。

タイミーでバックエンドエンジニアをしている id:euglena1215 です。
メリークリスマス🎄 みなさんの手元にはプレゼントは届いているでしょうか。

Ruby の世界では Ruby コミッターサンタさんがクリスマスプレゼントとして新しい Ruby バージョンをリリースしてくれます。 今年は Ruby 3.3 ですね。個人的には 3.3 の YJIT がどれだけ速くなるのか楽しみです。

また、新しいバージョンのリリースにはアップグレードがつきものです。アップグレードせずには新しいバージョンの恩恵を受けることはできません。 ということで、今回はタイミーが社内で運用している社内版 Ruby Rails アップグレードガイドを社外に公開します。

社内版の情報を黒塗りしては社内版を公開する意味がありません。そのため、最大限原文ママでお送りします。前提として足りない部分は「記事用補足」と追記しています。


社内版 Rails アップグレードガイド

このドキュメントは Rails アップグレードのために普段からやること、実際のアップグレードの際にやることをまとめたものです。基本的には一般的な Rails アップグレードガイドと同じですが、QAチェックの必要性など社内特有の事情も考慮されています。

下記のドキュメントは Rails のメジャーバージョン・マイナーバージョンを上げる際に意識すべきことです。パッチバージョンは普段のライブラリアップデート同様に上げてもらって構いません。

🟥 MUST: 安全なアップグレードのために必ず実施しなければいけません。
🟨 SHOULD: 必ず実施しなくてもいいですが、やっておくことを推奨します。
🟩 MAY: 行わなくてもアップグレードは実施できます。関心がある方だけで構いません。

以下の作業は基本的に並列かつ複数人で実施可能です。

普段やること

Rails Edge のキャッチアップ(🟩 MAY)

#guild_rails_edge には毎日 rails/rails の main branch にどんな変更がマージされたのかが流れてきます。ここで次のアップデートでどんな変更が入るのかをチェックしましょう。日頃からチェックしておくとアップデート時に情報の波に飲まれにくくなります。

(記事用補足:ここで流しているのは y-yagi さんのブログです)

y-yagi.hatenablog.com

Rails Edge 起因で失敗しているテストの修正(🟨 SHOULD)

通常の Rails バージョンでは動作するが Rails Edge で動かないテストは pending: pending_if_rails_edge をつけて pending してあります。grep して pending しているテストを見つけて問題を特定し修正しましょう。

(記事用補足:タイミーでは CI で Rails Edge を使ったテストを実行しています。詳しくは以下)

tech.timee.co.jp

Rails へのコントリビュート(🟩 MAY)

Rails Edge 起因で失敗しているテストの修正」の大半はアプリケーションコードに起因する問題であることが多いですが、たまに Rails 本体のバグに遭遇することもあります。その際は Rails にバグレポートや修正 PR を送ることを推奨しています。

リリース済みのバージョンの仕様を変えるのは難しいですが、betaやrc版ではissueやPRを送ることで仕様を変えられる可能性があります。意図しない破壊的変更を見かけた場合は積極的にやりとりしましょう。

参考: Get started with OSS contributions - Speaker Deck

アップグレード前にやること

アップグレード先のCIを用意する(🟨 SHOULD)

アップグレードを検討している頃には既にアップグレード先のバージョンがリリースされているため、Rails Edge はその次のバージョンになっていることが多いです。そのため、Rails Edge CI ではアップグレード先のバージョンでのテストは実行できません。

アップグレード先の Rails バージョンでの CI を用意しましょう。そうすることで、アップグレード先バージョンでのテストが普段から実行できるようになるので問題を早期発見できます。

参考
(ここに Rails 7.1 の CI を用意した Pull Request URL が貼ってありました)

Railsバージョン起因でスキップしているテストをなくす(🟥 MUST)

Rails バージョン起因でスキップしているテストはアップグレード後に動かなくなるテストです。このテストを放置したままアップグレードを実施すると該当機能が動かなくなるので必ずスキップしているテストがないことを確認しましょう。

Rails Edge 起因で失敗しているテストの修正」を実施していればスキップしているテストはほとんどなくなっているはずなので、このステップの対応が楽になります。

参考
(ここにRailsバージョン起因でスキップしているテストを修正している Pull Request URL が貼ってありました)

deprecation warning をなくす(🟨 SHOULD)

ほとんどの問題は「Railsバージョン起因でスキップしているテストをなくす」によって解消されますが、テスト環境では捉えきれない問題も存在します。それらの問題を洗い出すために、タイミーでは本番環境で発生した deprecation warning をログとして出力するようにしています。出力されたログは Datadog Logs で確認できます。

また、ログが出力されすぎて Datadog のコストを圧迫することを防ぐためにログ出力は確率的としています。deprecation warning が減ってきたら合わせて確率を100%に近づけ漏れなくキャッチできるようにすることを推奨します。

rails app:update の実行(🟥 MUST)

Rails ではapp:updateというコマンドが提供されています。Gemfileに記載されているRailsのバージョンを更新後、このコマンドを実行することで、新しいバージョンでのファイル作成や既存ファイルの変更を対話形式で行うことができます。

$ bin/rails app:update
       exist  config
    conflict  config/application.rb
Overwrite /myapp/config/application.rb? (enter "h" for help) [Ynaqdh]
       force  config/application.rb
      create  config/initializers/new_framework_defaults_7_0.rb
...

予期しなかった変更が発生した場合は、必ず差分を十分チェックしてください。

https://railsguides.jp/upgrading_ruby_on_rails.html#アップデートタスク

デフォルトに合わせていた方が今後のアップグレードが楽になるため、既存の挙動をなるべく変化させないように更新分を取り込みましょう。

変更差分を知りたい場合は https://railsdiff.org/ から確認できます。

Rails アップグレードガイドのバージョンに対応した変更を読んで問題ないことを確認(🟥 MUST)

公式の Rails アップグレードガイドにはメジャーバージョン・マイナーバージョンのアップグレードに対して破壊的変更など何らかの対応が必要な変更がまとまっています。これらを確認して問題がないことを確認してください。懸念がある場合は #prd_ch_ruby_on_rails で相談するなど適切な対応を行なってください。

例:7.0→7.1 Rails アップグレードガイド - Railsガイド

参考
(ここに確認したログをまとめた Notion リンクがありました)

リリース前の手動での動作確認(🟥 MUST)

リリース前の手動での動作確認は必須ですが、社内向け管理画面の最低限の疎通確認のみで問題ありません。
背景: (ここに意思決定の証跡として MTG 議事録リンクが貼ってありました)

また、社内向け管理画面においても十分なテストカバレッジがあれば動作確認を省略することができます。社内向け管理画面のテストカバレッジを上げるプロジェクトについては(Notion URL が貼ってありました)を確認してください。

(記事用補足:プロジェクトの Notion URL よりもTimee Advent Calendar 2023シリーズ1の5日目記事の方がより詳細にプロジェクトの説明をしています。興味があればご覧ください。)

tech.timee.co.jp

アップグレード作業中に行うこと

アップグレードの事前周知(🟥 MUST)

Rails アップグレードのリリース直後に rollback が困難な変更が行われると Rails アップグレード起因で問題が発生した際に rollback が困難になり、問題の復旧が遅れます。そのため、アップグレードを事前に周知しアップグレード後30分間はデプロイ(=マージ)を行なわないよう呼びかけてください。

rollback 用のコミットハッシュを取得する(🟥 MUST)

問題があった際の復旧を早めるために rollback で戻す先のコミットハッシュを用意しておきましょう。https://github.com/x/x/commits/master から確認できます。

Revert PR を作成する(🟩 MAY)

問題があった際の復旧を早めるために merge 後すぐに Revert PR を作成しておくことを推奨します。先に Revert PR を作っておけば feature branch での CI 待ちをショートカットすることができます。

問題が発生せずに無事リリースできた場合はきちんと PR を close しておきましょう。

各種監視を行う(🟥 MUST)

リリース直後は問題を早期発見するために各種の監視を行なってください。15分様子を見て問題が見つからなければ急いでrollbackする必要はありません。

  • Sentry
    • 普段見かけないエラーが発生していないかどうか
  • Datadog
    • ダッシュボード
      • 大きなメトリクスの変化がないかどうか
    • APM
      • レイテンシやエラーレートに変化がないか

(記事用補足:Sentry や Datadog など各種 URL が貼ってありましたがさすがに削除させていただきました)

アップグレード後にやること

new_framework_defaults_x_y.rbの有効化(🟨 SHOULD)

Rails をアップグレードしただけでは多くの新しい機能は有効化されていません。 rails app:update で作成された new_framework_defaults_x_x.rb のコメントアウトを1つずつ確認してデフォルトに合わせられそうなものは有効化しデフォルトに合わせ、意図を持ってデフォルトとは異なる設定を行う場合は application.rb に設定を追記しましょう。

config.load_defaultsの更新(🟨 SHOULD)

app:updateタスクでは、アプリケーションを新しいデフォルト設定に1つずつアップグレードできるように、config/initializers/new_framework_defaults_X.Y.rbファイルが作成されます(ファイル名にはRailsのバージョンが含まれます)。このファイル内のコメントを解除して、新しいデフォルト設定を有効にする必要があります。この作業は、数回のデプロイに分けて段階的に実行できます。アプリケーションを新しいデフォルト設定で動かせる準備が整ったら、このファイルを削除してconfig.load_defaultsの値を反転できます。 https://railsguides.jp/upgrading_ruby_on_rails.html#フレームワークのデフォルトを設定する

参考

railsguides.jp

qiita.com


いかがでしたか?

タイミーは上記の Rails アップグレードガイドを用いて Rails アップグレードを行なっています。とは言ったものの、このアップグレードガイドは Rails 7.1 アップグレードでやったことを体系的にまとめたもので本当に運用され始めるのは Rails 7.2 アップグレードのタイミングになります。
Rails アップグレードは属人的なタスクになりがちです。特定の人物がアップグレードの番人になるのではなく、誰でもアップグレードにチャレンジできるようにしたかったのがアップグレードガイドを作成した背景になります。

ネットには質の高いRailsアップグレードガイドがたくさん存在します。ですが、どのステップをどんな期待値で実施するか・動作確認はどこまでやるかは各社の状況に依ると思います。社内の暗黙値を減らすためにも社内版 Rails アップグレードガイドを作ってみてはいかがでしょうか。

静かなSquadの進化: エンゲージメントが高まるきっかけ

こんにちは!株式会社タイミーでプロダクトマネージャーをしているAndrewです。 私はオフショアメンバーが関与するSquadに所属しています。このSquadはエンジニア組織の中でもユニークな環境であり、ここで直面した問題とそれを乗り越えるための取り組みをこの記事で紹介したいと考えています。

オフショアメンバーとのコラボレーションの課題

約半年前、オフショアメンバーのいるSquadと関わり始め、このSquadの各メンバーを知るきっかけとなりました。 最初は、日本メンバーとオフショアメンバーのコミュニケーションがスムーズでないと感じました。ミーティングでは通訳担当の方以外、オフショアメンバー全員がほとんど発言しませんでした。 また、ミーティングで話されている内容が彼らが理解できる言語で記録されていないケースが多く、情報の透明性に欠けていました。開発した機能の目的が何かを理解しない場面を見かけたこともありました。

しかし、これは単なる課題ではなく、Squad全体のポテンシャルを引き出すためのチャンスでもあると考えました。 エンジニアは機能を作るだけでなく、プロダクトに関心を持ち、価値を届けることに注力すれば、より多くのアイディアやソリューションが生まれ、良いプロダクトが作れるのではないかと。そのためには、オフショアメンバーが積極的にディスカッションに参加できるようにする必要がありました。 最初は言語の壁があると感じたため、心配もありましたが、様々な施策を試してみました。その一環として、ドキュメントの整理とオンライン言語交流会を実施してみました。

情報透明性を向上するためのドキュメント

「ドキュメントのメンテナンスが面倒くさい!」、「コードを読む方が早い!」と思う方は少なくないでしょう。 コードにコメントがないと、そのコードが何をしているか理解することが難しくなります。それと同様に、ドキュメントがないと、システムや機能の全体像を把握するのに時間がかかり、理想的な状態と言えません。 コードで説明できない背景や設計の意図、特定の決定の背後にある論理をコメントで説明することで、コードを読む人が理解しやすくなります。しかし、コードのコメントでわかりやすく説明できる内容はテキストベースの情報に限られているということもあり、コードは特定のメンバーしかアクセスできないため、ここでドキュメントが強力な情報共有手段になります。

ドキュメントに対する工夫

ドキュメントを書くときにわかりやすくするためにいろんなテクニックがあります。 テキストに色をつけたり、フォントサイズを変えたり、ページの余白を活かすことで視覚的なメリハリをつけることが重要です。 これにより、複雑な情報も読みやすくなり、重要な情報を強調することができ、逆に強調したくない情報を目立たなくすることもできます。デザインが好きな私にとっては、ドキュメントは良いデザインを表現することのできる優れたツールです。

わかりやすいドキュメントを書くことは簡単ではありません。いろんなドキュメントの種類の中で、エンジニア向けのものもあれば、ステークホルダー(非エンジニア)向けのものもあるので、伝わるように読み手のバックグラウンドや知識に合わせて書くことが必要です。 難しい単語ではなく、あえてシンプルな単語を選び、物事を説明することで言語の壁をなくせるので、自分の言葉の知識を見せびらかす必要なんてありません。

このような意識をもって書けば、ドキュメントを書くことは単調な作業ではなく、実は楽しい作業なんです。

バランスがすべて

口頭でコミュニケーションが取りづらい状況では、ドキュメントは尚更重要です。 ドキュメントがあることで、メンバーはいつでも情報にアクセスでき、フィードバックや提案もしやすくなります。ただし、あまりにも詳細な内容、たとえばコード実装のレベルの情報まで書いてしまうと、細かなコードの変更が生じるたびにドキュメントを更新しないといけなくなってしまいます。 同様に、テキストだけの長い文章を書いてしまうと、ドキュメントの恩恵が受けられなくなり、わかりやすさが損なわれ、逆に効果が薄れてしまいます。適度な詳細と抽象度のバランスを取ることが大切であり、ドキュメントが管理の手助けとなるよう心がけが必要です。

活用されるドキュメント

実際にこの取り組みを導入して、Squadの振り返りミーティングで「ドキュメンテーションをよく参照するようになって、仕事において役立った」「ドキュメントが整理されていてわかりやすい」というメンバーからの声がありました。 今後、ドキュメントを書くのは私ではなく、オフショアメンバー全員も同じようなケイパビリティを持たせたいので、以上に書いたポイントを彼らに教えました。 今ではオフショアメンバー全員がドキュメントを書くようになり、ステークホルダーから仕様確認の問い合わせが来ても、すぐ回答できるようになりました。これにより、プロジェクト全体の透明性が向上し、知識の共有がスムーズになりました。

長期的な視点で見れば、ドキュメントはSquad全体の知識の蓄積として機能し、メンバーが増えても情報の共有の負担は軽減されます。

オンライン言語交流会

ドキュメント整理が進む中、私たちはSquadメンバーがより積極的に参加し、アイディアを共有できる環境を整えるためにもう一つの取り組みを始めました。それが、オンライン言語交流会です。

知っている人とコミュニケーションを取ることは楽ですが、知らない人となると相手の意図がどのようなものかもわからないし、ミスコミュニケーションの原因にもなります。できるだけオフショアメンバーとのコミュニケーションを増やすことで、彼らもより気軽に話しかけてくれるだろうと期待しています。しかし、日本語もできず、英語にも自信がないメンバーとどのようにすれば交流できるのか悩んでいました。そこで、オンラインで言語交流会を試してみました。

オンラインで実施しやすいアイスブレイク

いきなり何かを英語で話せと言われても難しいですよね。 そこでアイスブレイクゲームを導入し、わざわざ自分でトピックを考える必要がなく、よりカジュアルに話せる環境にしました。最初は簡単なものから始め、英語で自分のカバンに入っているものを紹介したり、謎解きをしたりしました。 カバンに入っているものを紹介する中で、お弁当の中身だったり、意外なエアコン用のリモコンの話も出てきて、会話が弾みました。謎解きをするときもトリッキーな謎が多く、あるメンバーがたくさん正解を回答できて、他のメンバーからカンニングしているだろうと冗談で言われたりしていた覚えがあります (笑)。 これにより、お互いの趣味や考え方を知ることができ、メンバー同士のコミュニケーションが深まりました。

伝わることの喜び

オフショアメンバーと会話を重ね、最初は英語に対して悲観的で、喋ろうとしないメンバーも自然と喋るようになりました。この記事を書く際に彼らにその理由を聞いてみました。 「英語の発音は下手ですが、理解してくれる人がいるので勇気が出る」「私の英語で喋っても笑われていないし、Andrewからの促進で一歩踏み出そうと思うようになって、ディスカッションに関与する重要性を理解できるようになった」という素敵なコメントをいただきました。 これらの言葉を通じて、協力し合いながら成長するプロセスに感謝しています。

このオンライン言語交流会のファシリテーションは最初は私が担当していましたが、現在はオフショアメンバーが積極的にファシリテーションすることもあります。今では毎回アイスブレイクゲームだけでなく、単純に英語で雑談することもできる環境になりました。 また、この会の名前の通り、英語に限らず、最近私が彼らから言語を学ぶ機会も得ました。

Squadの成長と今後

まだ完璧な状態には達していませんが、Squad全体がどんどん成長している実感があります。オフショアメンバーが積極的にコミュニケーションに参加し、自ら意見を言うようになったことは、大きな進歩と言えます。

異なる文化やバックグラウンドの人と仕事することは、チームが結束するまでには時間がかかりますが、結束ができた際には異なる視点から物事を判断でき、それによるメリットも大きいです。 私の過去の経験では、さまざまなバックグラウンドを持つ人々が集まれば、クリエイティブなアイディアが生まれやすくなります。そのため、このような多様性を大切にしていきたいです。

最後に、今後もSquad全体で協力し、より良いプロダクトを生み出すために努力していきたいと思います。