写真：左よりGitLab合同会社 シニアソリューションアーキテクト佐々木直晴、スタッフソリューションアーキテクト 伊藤俊廷。書籍 『GitLabに学ぶ 世界最先端のリモート組織のつくりかた』 と 『GitLabに学ぶ パフォーマンスを最大化させるドキュメンテーション技術』 を手に
目次
- リモートワーク＝非同期コミュニケーションが発生すること
- 非同期コミュニケーションを改善するには？
- 非同期・同期コミュニケーションはどう使い分ける？
- オールリモート環境における効率的なオンボーディング
- オールリモート環境における生産的なコミュニケーション法
- GitLabのソリューションアーキテクトの役割とスキル
コロナ禍を経た昨今、リモートワークを廃止し出社を前提とする企業が増えています。公益財団法人日本生産性本部がおこなった「第16回 働く人の意識調査※」によれば、テレワーク実施率は14.6%で過去最低を更新したとのことです。
※参考：2025年1月30日公開 第16回 働く人の意識調査 | 調査研究・提言活動 | 公益財団法人日本生産性本部
リモートワークではコミュニケーションが不足しがちだったり、生産性が低下しやすかったりなどさまざまな課題が指摘されています。コロナ禍で多くの企業が導入を急いだ期間が過ぎ、日本企業におけるリモートワークは曲がり角に差し掛かっているのでしょう。それでもなお、企業はリモートワーク導入をすすめるべきなのでしょうか。
今回は、リモートワークを前提とした「all-remote（オールリモート）」を実践されているGitLab社の担当者に「GitLabの働き方」について詳しく聞きました。オフィスを持たないGitLab社の働き方に、興味を持たれている方も多いのではないでしょうか。
GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 佐々木直晴
そういった方の期待を裏切るかもしれませんが、今回話を聞いた伊藤・佐々木は、リモートワークを無条件に肯定してはいません。リモートワークはあくまで目的を達成するための手段であり、目的ではないというのがふたりの考えです。
佐々木によれば ”Everyone can contribute（誰もが貢献できる）” というGitLab社のミッションを実現する手段として、all-remoteが役立つということです。たとえばGitLab社では「サンフランシスコに住んでいないとエンジニアとして働けない」といったことはありません。採用をおこなう地域に一定のルール（※）はあるものの、少なくともオフィスがある場所でしかGitLabで働けないわけではないのです。
all-remoteを実現できているおかげで、通信環境さえあれば他の地域で暮らすエンジニアもGitLab社で活躍できます。「”Everyone can contribute”を重視し、『オフィスがあった方がいいね』とならないのはGitLab社の企業文化の特徴的な部分だ」と佐々木は話しました。
今回のインタビューでは、ふたりにGitLab社がどのようにリモートワークを活用しているかをうかがっています。GitLab社の働き方を知りたい方、自社のリモートワーク導入に悩んでいる担当者の方はぜひ参考にしてください。
※現在は、エンティティがある地域やPEOを通じて雇用が可能な地域でのみ採用を行っており、地域によっては職種を限定しています。
ーー GitLabにおける、ふたりのお仕事・役割・入社の経緯を教えてください
GitLabの先進的な働き方に興味を持ち ソリューションアーキテクトとして入社
伊藤：わたしは、GitLabのソリューションアーキテクトというプリセールスエンジニアです。お客様がGitLabを導入される際に、技術面・ビジネス面それぞれの課題に対して、どのように解決できるかを一緒に考え、最適な活用方法をご提案しています。また、製品の価値をお客様のビジネスにどう活かすかを検討しながら、継続的にエンゲージメントを築くことも私の重要な役割です。
GitLabには、LinkedInでリクルーターに声をかけられたことがきっかけで興味を持ち入社しました。GitLabの製品自体にも興味があったのですが、ハンドブック中心にall-remoteでドキュメンテーションをしている点にも興味を持ったのです。きっと先進的な働き方が確立されていると想定し、それを体験したかったです。
GitLab合同会社 ソリューションアーキテクト本部 スタッフソリューションアーキテクト 伊藤 俊廷
佐々木：わたしも、伊藤と同じくソリューションアーキテクトです。ソリューションアーキテクトは、GitLabを導入することで、お客様の業務やビジネスがどう変わるかにも着目します。お客様の近くで、課題を発見するという面白さがある役割ですね。
入社前からGitLabを使っていて、製品自体に興味があった点はわたしも同じです。それ以外に透明性がすごいという印象もありましたね。
GitLabでは以前にオペレーションのミスで、本番データベースが喪失したという事故がありました。その際、GitLabはその復旧作業をYouTubeでライブ中継していて、すごいなと思っていたのです。GitLabに入社することになったと周囲に報告した際に『復旧作業をライブ中継していた会社だよね』と言われたのは覚えています。
ーー おふたりが考えるリモートワークの定義を教えてください。
リモートワーク＝非同期コミュニケーションが発生すること
オフィスに行かないことがリモートワークではない
伊藤：GitLabというより我々の考えになりますが、一般に言われているようにオフィスに行かないことがリモートワークという風に定義していません。
たとえば東京と大阪にオフィスがあれば、オフィス間での仕事は必然的にリモートです。東京にしかオフィスがない会社でも、目の前の人とメールやSlackでやり取りするなどして、リモートでコミュニケーションをとります。突き詰めると一般的なオフィスワーカーは、働いているほんとんどの時間をリモートワークな状態で進めているのではないかと考えるようになったのです。
必ずしも人と人が、いつも同じ場所・タイミングで仕事をするわけではありません。メールやSlackなどで、非同期のコミュニケーションが発生することになります。
こういった非同期のコラボレーションが発生することが、リモートワークとも言えますね。一方で、対面や電話、Zoomでの会議などは、同期コミュニケーションです。
ーー GitLabで実践されているall-remoteとはどんなものか教えてください
all-remoteとは物理的に集まるオフィスがなく、在宅での業務を基本とすること
伊藤： 物理的にみんなが集まるオフィスがなく、在宅で仕事をすることが基本となるのがall-remoteです。リモートの人がいたりリモートでない人がいたりという状態でなく、全員がリモートで働けることをall-remoteと呼んでいます。
all-remoteは『ほかの人と一切会わない』 ”strictly remote” ではありません。GitLabは対面で会うことも重視しています。GitLabチームメンバーが少ないころは、9ヵ月に1度は世界のどこかで集まるということもしていました。
ーー 全ての企業がリモートワークを実践すべきだと思いますか？
どんな企業でも、無理にリモートワークへ切り替える必要はない
佐々木： 非同期・同期どちらのコミュニケーションが良くて、どちらが駄目というわけではありません。それぞれの特性があります。
同期コミュニケーションには、Slackやメールなどと違いすぐに返事が返ってくるという良さがありますね。柔らかい状態で何か議論をはじめて輪郭をはっきりさせるフェーズにおいては、早い同期コミュニケーションが合っています。
一方、ある程度枠が決まり分担して作業できたり、確認にインターバルがとれたりするフェーズでは非同期コミュニケーションも可能です。非同期のコミュニケーションは早さが劣りますが、メールなどが残りあとで探すことができます。
伊藤：我々もZoomでちょっと話しながら、互いにアイデアを出し合うということはします。あと、たとえば製品チームなどが、大枠の設計をする際などは同期のコミュニケーションを使っていますね。同期コミュニケーションならではの良さがあるのです。同期コミュニケーションが適している企業は、無理にall-remoteやhybrid-remoteに切り替える必要はありません。
ただ、非同期コミュニケーションが必ず発生するということを意識できていない組織が大半を占める印象はあります。同期コミュニケーションが適している企業でも、非同期コミュニケーションが一切不要なわけではなく、情報を一元的にドキュメント化をするデメリットは基本的にはないはずです。
手段が整っていないから「うちはリモートワークに向かない」と思い込んでいるケースも
佐々木：自分のところはリモートに向いていない、というのを聞くことがありますが本当にそうなのか疑問に思うことはあります。手段が整っていないから、リモートワークが向いていないと感じているだけなのか、鶏と卵の関係のような問題だと思いますね。
たとえばドキュメントが整備されていなかったり、情報が集まっていなかったりすれば、確認の作業が多くなります。『この場合って、どうすればいいんだっけ』という確認作業が、その都度必要になるときは同期的な速いコミュニケーションと相性がいいのです。その結果、同じ場所にいた方が効率はいいよねってことになります。
そうして非リモートで常に同じ場所で仕事をしていると、速いコミュニケーションがより促進されるわけです。ドキュメントが残らず、その場限りのコミュニケーションになりがちで、リモートが合わないという風になってしまいます。リモートワークが向かない状況は、何が原因で作り出されているのかにフォーカスする必要がありますね。
非同期コミュニケーションを改善するには？
非同期コミュニケーションの難しさを認識したうえで、意識的に改善できるかどうかが課題
伊藤：リモートワークか否かは関係なく、非同期のコミュニケーションはどうしても比重が増すと思うのですね。ソフトウェアエンジニアでもマーケティングの広報担当でも、ペアプロや資料作りを他のメンバーとずっと一緒にやるということはありません。そのため、非同期のコミュニケーションをどうやってうまくやるかに着目する必要があるのです。
同期のコミュニケーション自体は、皆さんもあんまり工夫せずにできると思います。しかし非同期につなげるため、同期した内容を残すという意味のドキュメンテーションが意識できていないことが多いのではないでしょうか。非同期のコミュニケーションをどう改善するかが、多くの組織における喫緊の課題のように思います。
ーー GitLabがリモートワークを成立させるうえで大切にされているSSOTとは何かを教えてください。
SSOTは信頼できる唯一の情報源
佐々木：SSOTは『Single Source of Truth』の略語で、信頼できる唯一の情報源という意味の言葉です。普段仕事をしているなかで『この点に関する情報はこれが正しい』というのを、ひとつ持ちます。そうして、それに誰もが適切にアクセスできる状態にするのです。
伊藤：たとえばどういうお金は会社の経費として申請してよくて、会計上のコードはこれですといった話がありますね。GitLabでは、こういった情報をインターネット上のハンドブックにまとめて公開しているのです。そこに書いてあることが最も確からしく、議論の前提となる情報であるという信頼性があるのがSSOTになります。
GitLabではハンドブックのほか、Google Docsに保存したミーティングノートやチケットなども利用している状況です。本当であれば全ての情報がハンドブックに集約できるとよいのですが、運用上それは現実的ではありません。
ここに正しい情報がある、という認識がみんな揃っていることが重要と考えています。たとえば交通費精算のルールがハンドブックにあるため、誰かに精算の基本ルールを何回も聞く必要はありません。
「正しい情報がここにある」と社員の意識が向くことが大事
伊藤：ハンドブックがあって、そこにSSOT性の高い情報が集約されていることが重要かと思います。SlackやZoom、チケットシステムを導入しても、ハンドブックのように情報を長期的かつ正しく保存する運用をしないと大人数での非同期コミュニケーションは難しいです。『ここに書いてあることが正』という情報としてハンドブックがあることで、みんなの意識がここへ向かうというのが重要かなと思います。
ーー 非同期コミュニケーション・同期コミュニケーションをどう使い分けているか教えてください。
非同期・同期コミュニケーションはどう使い分ける？
業務の枠組みが決まってくるなどしたら、非同期コミュニケーションへ移行を検討する
佐々木：速いコミュニケーションは重要ですので、同期コミュニケーションも活用します。ある程度枠組みが決まってきたり分担して作業したりができるようになってから、非同期のコミュニケーションを検討するイメージです。非同期のコミュニケーションはスピードが劣るものの、情報を残してあとで確認することができます。
同期のコミュニケーションはニュアンスを持たせやすい
佐々木：Slackなどの文字上・非同期のコミュニケーションに比べ、同期のコミュニケーションはニュアンスを持たせやすいですね。ちょっと敏感な話をするときは、いきなりSlackでどーんとやるのでなく、Zoomで『そういえば、あれさ』という風に話すようにしています。
ーー 確かに文字ベースで厳しく注意されても、冷たく感じてしまうかもしれません。Zoomなど同期のコミュニケーションであれば、感情などのニュアンスを持たせられるのは分かります。 全てにおいて、同期もしくは非同期のコミュニケーションが優れているわけではないということですね。コミュニケーションの特性や必要性を考えて、うまく使い分けることが重要ということでしょうか。
佐々木：はい、そうですね。
ーー リモートワークが前提のGitLabにおいて、オンボーディングをどのように実践されているか教えてください。
オールリモート環境における効率的なオンボーディング
数百のタスクが集まったチケットを自分のペースでこなす
ーー GitLabに入社したい、転職したいという方は、all-remoteの現場でどのようなオンボーディングが実施されているか気になると思います。
伊藤：GitLabのオンボーディングでは、ベースとしてメンバーごとにチケットが作成され、そこに数百のタスクが箇条書きで記載されています。それらを1ヵ月程度の時間をかけてこなすという感じですね。
たとえばPCのセットアップや、トレーニングビデオの視聴といったタスクが並んでいます。『ここを学んで欲しい』『PCのセットアップをする』など入社にあたって当たり前に必要となることがチケットにまとめてあるのです。これらをこなせば、自分で仕事がすすめられるまでになります。
全員が同じオンボーディングを完了することで、同じスタートラインに立てるわけです。たとえばハンドブックのどのあたりにどのようなことが記載されているという感覚が身につき、あとから適切に参照できるようになります。
ーー オンボーディングの際に、トレーナーのような役割の方はつきますか？
伊藤：はい、トレーナー役の『バディ』が新人につきます。ずっとつくというより、毎日1回、1対1で状況や困ったことがないかを確認するイメージです。
オールリモート環境における生産的なコミュニケーション法
チケットによるオンボーディングのよいところは、研修の全体像が可視化されること
伊藤：この仕組みのいいところは、全体像がみえる点です。ほかの会社でもオンボーディングの際は、ドキュメントを渡されると思います。一方でGitLabのオンボーディングでは、あちこち見に行かなくてもチケットをみれば研修の全体像が把握できるのです。 チケットの仕組みを使っているので、チケット内で質問したりバディが状況をチェックして適宜フォローしたりもできます。all-remoteでは新人も不安になりやすいですが、それを取り除ける施策だと思いますね。
ーー 作業に集中するための「フォーカスタイム」をどのように確保されているか教えてください。
フォーカスタイムを入れておけば、自動的にミーティングが拒否される
伊藤： フォーカスタイムは、Googleカレンダーに適宜登録します。なかにはフォーカスタイムの自動登録が可能なツールを使っているメンバーもいますね。
フォーカスタイムを入れておけば、自動的にミーティングは拒否されます。それでも必要に応じて入ってきてしまうこともあるのですが、フォーカスタイムをしない場合に比べ入りづらくなりますね。作業に集中する時間の確保が求められるソフトウェア開発や技術調査、プレゼン作成などをする必要があるメンバーにとって、フォーカスタイムは特に必要です。
ーー 非同期コミュニケーションを円滑にするためにおこなっているという「Coffee Chat」について教えてください。
Coffee Chatはオフィスで日常的におこなわれる立ち話を代替する手段
伊藤：Coffee Chatは雑談することを目的としたミーティングで、Zoomを使っておこないます。Coffee Chatは、非同期を加速させる手段として推奨されていますね。
Slack上だけのやりとりとなり、なかなか会えないという人は社内にたくさんいます。こういった人たちと同期コミュニケーションをすることで、非同期のコミュニケーションを加速させるわけです。
ただCoffee Chatは、どちらかというとall-remoteのデメリットを表しているとも思います。all-remoteでは、オフィスで日常的におこなわれるような立ち話はできません。立ち話で普通に話す方が、もっとスムーズに雑談ができるわけです。
そういった観点では、Coffee Chatは立ち話の下位互換だとは思います。all-remoteで立ち話の役割を補助するのが、Coffee Chatの仕組みです。
佐々木：普通のオフィスであれば、コーヒーを飲みにコーヒーサーバーの周りに集まって偶発的なコミュニケーションが生まれることがありますね。それをオンラインでできないか、というのがCoffee Chatのコンセプトだと理解しています。
コーヒーサーバーのところで、たまたま顔を合わせた人とコミュニケーションをとるような、ランダムさが重要だと思うのです。たとえば、たまたまコーヒーサーバーのところで、隣の部署の人と顔を合わせることがありますね。そのとき『そういえばキャンプ好きでしたよね』といった何気ない会話で、雑談がはじまったりもします。
そういった雑談で、繋がりができる良さがあると思いますね。困ったときに『そういえばマーケティング部門に、この前話した人がいたから相談してみよう』みたいなことがあります。
僕はそういったランダムさが好きで、週1回ツールで自動的にマッチングされた人とCoffee Chatをしていますね。
ーー ふたりをはじめ、GitLabの皆さんがどのようにリモートワークを実践されているか伺いたいと思います。
普段はどこでお仕事をされていますか？
伊藤：自宅で仕事をすることが多いです。海外や国内の出張時にはホテルのなかで仕事をしています。モバイルディスプレイを持ち込んで、自宅の環境となるべく遜色のないように工夫していますね。
ーー ワーケーションをされている方はいらっしゃいますか？
伊藤：我々はロール的に対面でお客様と打ち合わせをする機会が多いので難しいですが、ロールによってはかなりしていますね。
たとえばテクニカルサポートエンジニアは、メールベースで回答して時々Zoomでお客様と打ち合わせするといった感じなのでしやすいと思います。たとえば、シンガポール在住のサポートエンジニアがワーケーションとして日本に来るとか、そういったことができる環境は整備されています。
佐々木： ワーケーションとまではいかなくても、僕はリモートワークの良さを活用する意味で時間を有効活用するようにしています。
たとえば2時間ほど隙間時間ができたら、休日だと混んでいる美術館へ行くとか髪を切りに行くなどして、その時間分は朝少し早く起きて仕事したり、夜にやって調整などをしていますね。そういう融通がきくという点は一部のエンジニアにとって福利厚生というか魅力だと思いますので、僕はあえてXに投稿したりしています。
もちろん『本当はこの時間に打ち合わせをしたかったのに、いなかったからできなかった』といったような迷惑がかからないようにはしていますね。
ーー 仕事をする時間は決まっていますか？個人の裁量に委ねられているのでしょうか？
伊藤：契約上は何時間働くなど最低限の決まりはありますが、基本的には個人の裁量に任せられていますね。たとえば我々はお客様対応が中心なので、それが滞りなく進められていれば良いということになります。
佐々木： サポートエンジニアやSREの人などにはオンコール体制があり、その時間はトラブルや問い合わせに対応できるようにしないといけないというのはあります。ただ、それも毎日ずっとというわけではないので、ある程度柔軟にはできると思います。
ーー 他企業がリモートワークに失敗している原因について、ご意見をお聞かせください。
リモートワークでコミュニケーション不足になったり生産性が低下したりして、リモートワーク導入が失敗している企業が少なくありません。これらの原因について、ご意見をお聞かせいただければと思います。
伊藤：リモートワークでは、コミュニケーション不足は絶対的に起こるので、工夫するしかないですね。たとえば会社の文化にも依存するのですが、オンライン会議などでカメラをオンにしない方もいます。そういった点も、コミュニケーション不足の原因になっているのではないかと思いますね。
ーー カメラは重要でしょうか？
伊藤：はい。Coffee Chatのときも含め、GitLabでは全員ではないもののほとんどの人がカメラをつけています。カメラをつけるかつけないかで、Zoomでコミュニケーションをとるときなどの情報量も違いますね。
コミュニケーション不足は避けられないにしても、その不足を補うという点でカメラをオンにするのは重要だと思います。
ーー コミュニケーションの工夫という点では、GitLab様の文化で素晴らしいと思った点があります。オンライン会議などでお子さんや飼い犬が映っても、それを悪とせずコミュニケーションのきっかけにするということですね。こういった文化も、GitLab様でコミュニケーション不足を防ぐ意味で有効かなと思いました。が起きにくい理由かなと思いました。
伊藤：ミーティングの質にもよりますが、割と社内で許容されていますね。
ーー リモートワークにして生産性が低下した、という企業も存在するようですが、どう思われますか？
伊藤：特にオフィスがある状態からの予期せぬ社会的変化によるリモートワークの強制導入においては、そのように感じる背景はよく理解できるが、そもそも本当にリモートワークの実施前後で生産性を測っているのかは気になりますね。何となくの印象で『生産性が落ちた』と言われていることも多いのではと考えています。特にマネジメント側からすると、リモートワークでは従業員の顔が見えず何をしているかわかりません。それで、『生産性が下がった』と感じていることもあると思います。単にチャットツールを多用するだけではない非同期コミュニケーションにおける工夫やドキュメント化を徹底的に推進してもやはりだめだったのかについて気になります。
ーー ソリューションアーキテクトという職種について教えていただきたいと思います。
まずはソリューションアーキテクトの職務範囲について教えてください。
GitLabのソリューションアーキテクトの役割とスキル
佐々木：厳密な定義はHandbookに記載されていますが、ここではもう少し主観的に紹介しますね。ソリューションアーキテクトには、仕事の方向性が大きく分けて3つあると考えます。
ひとつ目はお客様に向けた方向性で、これは一番重要で割合の大きな部分だと考えます。ソリューションアーキテクトは単に技術営業として製品を紹介したり、デモをしたりするだけではありません。
お客様の組織やプロセスをよく観察し、ときにはお客様自身も気付いていない課題やその解決策を提示・提案する活動があります。この活動には自社製品の知識だけでなく、開発手法・クラウドネイティブ技術・プロジェクトマネジメントといったスキルも必要です。ソリューションアーキテクトの個性や強みが活きる領域だと思いますね。
ふたつ目は社内です。社内に対しても、ソリューションアーキテクトの価値を発揮できるチャンスがあります。たとえば営業メンバーに対し、製品の新機能が持つ価値や解決可能な課題を説明し全員が概念として扱えるようにするイネーブルの要素です。
個人的にはこういう仕事も好きで、社内でGeneral (Yorozu) Discussion Lunch Chatという場を週1回運営しています。General (Yorozu) Discussion Lunch Chatでは昼ご飯を食べながら、メンバーが質問し合ったり情報をシェアしたりするのです。
最後はマーケット全体に向けた方向性になります。たとえばDevSecOpsの取り組みについては認知度が高まってきているとはいえ、十分とはいえません。クラウド技術のように先行して広まった概念に比べると一般化しているとは言えず、まだまだ知ってもらう必要があると思っています。イベント登壇やマーケティング組織と連携してのコンテンツ作成といった手法で、認知度向上に努めるのも重要な仕事ですね。
このようにソリューションアーキテクトには、やるべきことがたくさんあるとは言えるでしょう。ただ個人的には、走り回れるホワイトスペースが多くて非常にやりがいがあり楽しく感じています。
ーー ソリューションアーキテクトに英語スキルはどのくらい必要ですか？
佐々木：もちろん英語スキルが高ければ高いほどいいのですが、いくつかの観点でお答えできればと思います。
伊藤：自分は経験的に入社時期と組織の規模に大きく相関すると考えています。日本で採用される場合、日本にいる関連するロールでのチームメンバーが増えるにつれて、英語の必要性が少しずつ減っていくことを、他社での経験も含めて、体感しました。
ーー どういった場面で必要になりますか？
佐々木：日常的に英語を読み書きするシーンはありますが、AIやツールの使いやすいところではあります。一番地力が必要になるのは、対面で会話する必要があるシーンですね。定例のような事前準備がしやすいシーンでなく、初めて対面するお客様や海外支社のメンバーと話すシーンでは特に英語力が求められます。
ーー TOEICスコアなどは関係がありますか？
佐々木：よく『TOEIC L&Rテストの点がよくても英語で活躍できるわけじゃない』『TOEIC L&Rテストはスピーキングがないので意味がない』という説も聞きます。しかし、そもそも聞けないと答えられないので、リスニングパートについては関係があると思いますね。リーディングはツールの活用でなんとかなるケースもあると思います。
伊藤：AIを翻訳領域で活用すれば、英語で会話できる必要はなくなるという意見も耳にします。しかし、たとえAIベースの翻訳ツールが今後さらに進化したとしても、翻訳処理の遅延が完全になくなることはありません。 また、ビジネスでもプライベートでも、AI翻訳を介した会話で本当に人間関係を築けるのかには疑問が残ります。たとえば、海外のメンバーを含む社内のアクティビティや食事に参加したとき、自分だけが翻訳デバイスを使っていたら、意図せずとも他のメンバーから声をかけられる機会が減ることは容易に想像できると思います。
上級レベルの英語運用力が測れない欠点はあるものの、私はTOEICは客観的に英語力を図るひとつの手段と考えます。外資系ソフトウェアベンダーの世界に入る前に、TOEIC L&Rテストと並行してTOEIC S&Wテストも受け、自分の英語での会話力向上に継続的に取り組んできました。
ーー 英語スキルを向上させるために、どんな努力をしていますか？
佐々木：GitLabでは業務の必要に応じ、研修やトレーニングを受けるための費用を年間＄10,000ほど支援してくれます。この支援を活用して、英会話などの研修を受けたりアプリを利用したりといったことをかなりしましたね。あとは積極的に海外のメンバーとCoffee Chatをして、英語力を磨いています。
ーー 入社時に比べ、英語をつかうのには慣れましたか？
佐々木：GitLab入社前は英語を使う環境はなかったので、本当に不安だった記憶があります。今では社内のメンバーであれば、何とかなるだろうという気持ちは持てるようになりました。
社内メンバーなら最悪何回か聞き直したり、表現を変えて話し直したりすることができますからね。ただ、お客様相手ではそれができずまだ緊張するので、継続して英語力向上に取り組んでいく必要があると思っています。
ーー ソリューションアーキテクトのお仕事をする際の、よくある1日のスケジュールを教えてください。
佐々木：以下のような感じですね。
| 時間 | イベント |
|---|---|
| 08:00 | 下の子を幼稚園のバス停まで送る。 |
| 09:00 | 位置情報ゲーム（Ingress）をしながら帰宅。その後、コーヒーを飲みながら業務開始。 午前中は打ち合わせがなく、集中して技術検証と新規ハンズオンのコンテンツ作成をおこなう。 |
| 13:00 | 昼食を食べながら、同僚とZoomで製品の新機能について議論 |
| 14:00 | 新規のお客様とディスカバリーミーティング* |
| 15:30 | APAC SA Weekly Call（定例）で最近の案件について共有 |
| 17:00 | 上の子を習い事まで送り、近くのコワーキングスペース（個室）を借りてオンライン英会話と仕事 |
| 19:00 | 習い事が終わった子どもを迎えに行って帰宅 |
| 20:00 | 夕食をすませ子どもと遊ぶ |
| 22:00 | なんだかんだ気になって、Slackなどで仕事の対応をしてしまう（良くない日） |
| 24:00 | 就寝 |
＊ディスカバリーミーティング：顧客の業務プロセス、要件、課題を深く理解し、効果的なソリューション設計のための情報を収集する初期段階の重要な会議
ーー ありがとうございました。
