[{"data":1,"prerenderedAt":798},["ShallowReactive",2],{"/ja-jp/blog/tips-for-async-communication":3,"navigation-ja-jp":38,"banner-ja-jp":459,"footer-ja-jp":469,"blog-post-authors-ja-jp-GitLab Japan Team":705,"blog-related-posts-ja-jp-tips-for-async-communication":721,"blog-promotions-ja-jp":735,"next-steps-ja-jp":789},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":22,"description":17,"extension":23,"externalUrl":24,"featured":15,"heroImage":19,"isFeatured":15,"meta":25,"navigation":15,"path":26,"publishedDate":22,"rawbody":27,"seo":28,"slug":14,"stem":33,"tagSlugs":34,"tags":36,"template":13,"updatedDate":24,"__hash__":37},"blogPosts/ja-jp/blog/tips-for-async-communication.md","非同期コミュニケーションを機能させるには何が必要か？オールリモートのGitLabの働き方に見る “ルールと文化”のつくり方",[7],"gitlab-japan-team",[9],"GitLab Japan Team","*写真：左よりGitLab合同会社 シニアソリューションアーキテクト佐々木直晴、スタッフソリューションアーキテクト 伊藤俊廷。書籍 『[GitLabに学ぶ 世界最先端のリモート組織のつくりかた](https://www.shoeisha.co.jp/book/detail/9784798179421)』 と 『[GitLabに学ぶ パフォーマンスを最大化させるドキュメンテーション技術](https://www.shoeisha.co.jp/book/detail/9784798185736)』 を手に*\u003Cbr>\u003Cbr>\n\n## 目次\n1. リモートワーク＝非同期コミュニケーションが発生すること\n2. 非同期コミュニケーションを改善するには？\n3. 非同期・同期コミュニケーションはどう使い分ける？\n4. オールリモート環境における効率的なオンボーディング\n5. オールリモート環境における生産的なコミュニケーション法\n6. GitLabのソリューションアーキテクトの役割とスキル\n\u003Cbr>\n\u003Cbr>\n\nコロナ禍を経た昨今、リモートワークを廃止し出社を前提とする企業が増えています。公益財団法人日本生産性本部がおこなった「第16回 働く人の意識調査※」によれば、テレワーク実施率は14.6%で過去最低を更新したとのことです。\n\n※参考：2025年1月30日公開 [第16回 働く人の意識調査 | 調査研究・提言活動 | 公益財団法人日本生産性本部](https://www.jpc-net.jp/research/detail/007214.html)\n\nリモートワークではコミュニケーションが不足しがちだったり、生産性が低下しやすかったりなどさまざまな課題が指摘されています。コロナ禍で多くの企業が導入を急いだ期間が過ぎ、日本企業におけるリモートワークは曲がり角に差し掛かっているのでしょう。それでもなお、企業はリモートワーク導入をすすめるべきなのでしょうか。\n\n今回は、リモートワークを前提とした「[all-remote](https://handbook.gitlab.com/handbook/company/culture/all-remote/)（オールリモート）」を実践されているGitLab社の担当者に「GitLabの働き方」について詳しく聞きました。オフィスを持たないGitLab社の働き方に、興味を持たれている方も多いのではないでしょうか。\n\n![佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3704_resized.jpg)\n*GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 佐々木直晴*\n\nそういった方の期待を裏切るかもしれませんが、今回話を聞いた伊藤・佐々木は、リモートワークを無条件に肯定してはいません。リモートワークはあくまで目的を達成するための手段であり、目的ではないというのがふたりの考えです。\n\n佐々木によれば __”[Everyone can contribute](https://handbook.gitlab.com/teamops/equal-contributions/)（誰もが貢献できる）”__ というGitLab社のミッションを実現する手段として、all-remoteが役立つということです。たとえばGitLab社では「サンフランシスコに住んでいないとエンジニアとして働けない」といったことはありません。採用をおこなう地域に一定のルール（※）はあるものの、少なくともオフィスがある場所でしかGitLabで働けないわけではないのです。\n\nall-remoteを実現できているおかげで、通信環境さえあれば他の地域で暮らすエンジニアもGitLab社で活躍できます。「”[Everyone can contribute](https://handbook.gitlab.com/teamops/equal-contributions/)”を重視し、『オフィスがあった方がいいね』とならないのはGitLab社の企業文化の特徴的な部分だ」と佐々木は話しました。\n\n今回のインタビューでは、ふたりにGitLab社がどのようにリモートワークを活用しているかをうかがっています。GitLab社の働き方を知りたい方、自社のリモートワーク導入に悩んでいる担当者の方はぜひ参考にしてください。\n\n※現在は、エンティティがある地域やPEOを通じて雇用が可能な地域でのみ採用を行っており、地域によっては職種を限定しています。\n\n\u003Cbr>\n\n> ーー GitLabにおける、ふたりのお仕事・役割・入社の経緯を教えてください\n## GitLabの先進的な働き方に興味を持ち ソリューションアーキテクトとして入社\n\n__伊藤__：わたしは、GitLabのソリューションアーキテクトというプリセールスエンジニアです。お客様がGitLabを導入される際に、技術面・ビジネス面それぞれの課題に対して、どのように解決できるかを一緒に考え、最適な活用方法をご提案しています。また、製品の価値をお客様のビジネスにどう活かすかを検討しながら、継続的にエンゲージメントを築くことも私の重要な役割です。\n\nGitLabには、LinkedInでリクルーターに声をかけられたことがきっかけで興味を持ち入社しました。GitLabの製品自体にも興味があったのですが、ハンドブック中心にall-remoteでドキュメンテーションをしている点にも興味を持ったのです。きっと先進的な働き方が確立されていると想定し、それを体験したかったです。\n![伊藤 俊廷](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3669_resize.jpg)\n*GitLab合同会社 ソリューションアーキテクト本部 スタッフソリューションアーキテクト 伊藤 俊廷*\n\n__佐々木__：わたしも、伊藤と同じくソリューションアーキテクトです。ソリューションアーキテクトは、GitLabを導入することで、お客様の業務やビジネスがどう変わるかにも着目します。お客様の近くで、課題を発見するという面白さがある役割ですね。\n\n入社前からGitLabを使っていて、製品自体に興味があった点はわたしも同じです。それ以外に透明性がすごいという印象もありましたね。\n\nGitLabでは以前にオペレーションのミスで、本番データベースが喪失したという事故がありました。その際、GitLabはその復旧作業をYouTubeでライブ中継していて、すごいなと思っていたのです。GitLabに入社することになったと周囲に報告した際に『復旧作業をライブ中継していた会社だよね』と言われたのは覚えています。\n\n> ーー おふたりが考えるリモートワークの定義を教えてください。\n## リモートワーク＝非同期コミュニケーションが発生すること\n### オフィスに行かないことがリモートワークではない\n\n__伊藤__：GitLabというより我々の考えになりますが、一般に言われているようにオフィスに行かないことがリモートワークという風に定義していません。\n\nたとえば東京と大阪にオフィスがあれば、オフィス間での仕事は必然的にリモートです。東京にしかオフィスがない会社でも、目の前の人とメールやSlackでやり取りするなどして、リモートでコミュニケーションをとります。突き詰めると一般的なオフィスワーカーは、働いているほんとんどの時間をリモートワークな状態で進めているのではないかと考えるようになったのです。\n\n必ずしも人と人が、いつも同じ場所・タイミングで仕事をするわけではありません。メールやSlackなどで、[非同期のコミュニケーション](https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous/)が発生することになります。\n\nこういった非同期のコラボレーションが発生することが、リモートワークとも言えますね。一方で、対面や電話、Zoomでの会議などは、同期コミュニケーションです。\n\n> ーー GitLabで実践されているall-remoteとはどんなものか教えてください\n\n### all-remoteとは物理的に集まるオフィスがなく、在宅での業務を基本とすること\n\n__伊藤__： 物理的にみんなが集まるオフィスがなく、在宅で仕事をすることが基本となるのがall-remoteです。リモートの人がいたりリモートでない人がいたりという状態でなく、全員がリモートで働けることをall-remoteと呼んでいます。\n\nall-remoteは『ほかの人と一切会わない』 ”[strictly remote](https://handbook.gitlab.com/handbook/company/culture/all-remote/stages/#10-strictly-remote)” ではありません。GitLabは対面で会うことも重視しています。GitLabチームメンバーが少ないころは、9ヵ月に1度は世界のどこかで集まるということもしていました。  \n\n> ーー 全ての企業がリモートワークを実践すべきだと思いますか？\n\n### どんな企業でも、無理にリモートワークへ切り替える必要はない\n![佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3764_resize.jpg)\n\n__佐々木__： 非同期・同期どちらのコミュニケーションが良くて、どちらが駄目というわけではありません。それぞれの特性があります。\n\n同期コミュニケーションには、Slackやメールなどと違いすぐに返事が返ってくるという良さがありますね。柔らかい状態で何か議論をはじめて輪郭をはっきりさせるフェーズにおいては、早い同期コミュニケーションが合っています。\n\n一方、ある程度枠が決まり分担して作業できたり、確認にインターバルがとれたりするフェーズでは非同期コミュニケーションも可能です。非同期のコミュニケーションは早さが劣りますが、メールなどが残りあとで探すことができます。\n\n__伊藤__：我々もZoomでちょっと話しながら、互いにアイデアを出し合うということはします。あと、たとえば製品チームなどが、大枠の設計をする際などは同期のコミュニケーションを使っていますね。同期コミュニケーションならではの良さがあるのです。同期コミュニケーションが適している企業は、無理に[all-remote](https://handbook.gitlab.com/handbook/company/culture/all-remote/stages/#9-all-remote)や[hybrid-remote](https://handbook.gitlab.com/handbook/company/culture/all-remote/stages/#5-hybrid-remote)に切り替える必要はありません。\n\nただ、非同期コミュニケーションが必ず発生するということを意識できていない組織が大半を占める印象はあります。同期コミュニケーションが適している企業でも、非同期コミュニケーションが一切不要なわけではなく、情報を一元的にドキュメント化をするデメリットは基本的にはないはずです。\n\n### 手段が整っていないから「うちはリモートワークに向かない」と思い込んでいるケースも\n\n__佐々木__：自分のところはリモートに向いていない、というのを聞くことがありますが本当にそうなのか疑問に思うことはあります。手段が整っていないから、リモートワークが向いていないと感じているだけなのか、鶏と卵の関係のような問題だと思いますね。\n\nたとえばドキュメントが整備されていなかったり、情報が集まっていなかったりすれば、確認の作業が多くなります。『この場合って、どうすればいいんだっけ』という確認作業が、その都度必要になるときは同期的な速いコミュニケーションと相性がいいのです。その結果、同じ場所にいた方が効率はいいよねってことになります。\n\nそうして非リモートで常に同じ場所で仕事をしていると、速いコミュニケーションがより促進されるわけです。ドキュメントが残らず、その場限りのコミュニケーションになりがちで、リモートが合わないという風になってしまいます。リモートワークが向かない状況は、何が原因で作り出されているのかにフォーカスする必要がありますね。\n\n## 非同期コミュニケーションを改善するには？\n### 非同期コミュニケーションの難しさを認識したうえで、意識的に改善できるかどうかが課題\n![伊藤俊廷](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3736_resize.jpg)\n\n__伊藤__：リモートワークか否かは関係なく、非同期のコミュニケーションはどうしても比重が増すと思うのですね。ソフトウェアエンジニアでもマーケティングの広報担当でも、ペアプロや資料作りを他のメンバーとずっと一緒にやるということはありません。そのため、非同期のコミュニケーションをどうやってうまくやるかに着目する必要があるのです。\n\n同期のコミュニケーション自体は、皆さんもあんまり工夫せずにできると思います。しかし非同期につなげるため、同期した内容を残すという意味のドキュメンテーションが意識できていないことが多いのではないでしょうか。非同期のコミュニケーションをどう改善するかが、多くの組織における喫緊の課題のように思います。\n\n> ーー GitLabがリモートワークを成立させるうえで大切にされているSSOTとは何かを教えてください。\n\n### SSOTは信頼できる唯一の情報源\n__佐々木__：SSOTは『Single Source of Truth』の略語で、信頼できる唯一の情報源という意味の言葉です。普段仕事をしているなかで『この点に関する情報はこれが正しい』というのを、ひとつ持ちます。そうして、それに誰もが適切にアクセスできる状態にするのです。\n\n__伊藤__：たとえばどういうお金は会社の経費として申請してよくて、会計上のコードはこれですといった話がありますね。[GitLabでは、こういった情報をインターネット上のハンドブックにまとめて公開](https://handbook.gitlab.com/handbook/finance/expenses/)しているのです。そこに書いてあることが最も確からしく、議論の前提となる情報であるという信頼性があるのがSSOTになります。\n\nGitLabではハンドブックのほか、Google Docsに保存したミーティングノートやチケットなども利用している状況です。本当であれば全ての情報がハンドブックに集約できるとよいのですが、運用上それは現実的ではありません。\n\nここに正しい情報がある、という認識がみんな揃っていることが重要と考えています。たとえば交通費精算のルールがハンドブックにあるため、誰かに精算の基本ルールを何回も聞く必要はありません。\n\n### 「正しい情報がここにある」と社員の意識が向くことが大事\n![佐々木と伊藤](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3819_resize.jpg)\n\n__伊藤__：ハンドブックがあって、そこにSSOT性の高い情報が集約されていることが重要かと思います。SlackやZoom、チケットシステムを導入しても、ハンドブックのように情報を長期的かつ正しく保存する運用をしないと大人数での非同期コミュニケーションは難しいです。『ここに書いてあることが正』という情報としてハンドブックがあることで、みんなの意識がここへ向かうというのが重要かなと思います。\n\n> ーー 非同期コミュニケーション・同期コミュニケーションをどう使い分けているか教えてください。\n## 非同期・同期コミュニケーションはどう使い分ける？\n## 業務の枠組みが決まってくるなどしたら、非同期コミュニケーションへ移行を検討する\n\n__佐々木__：速いコミュニケーションは重要ですので、同期コミュニケーションも活用します。ある程度枠組みが決まってきたり分担して作業したりができるようになってから、非同期のコミュニケーションを検討するイメージです。非同期のコミュニケーションはスピードが劣るものの、情報を残してあとで確認することができます。\n\n### 同期のコミュニケーションはニュアンスを持たせやすい\n\n__佐々木__：Slackなどの文字上・非同期のコミュニケーションに比べ、同期のコミュニケーションはニュアンスを持たせやすいですね。ちょっと敏感な話をするときは、いきなりSlackでどーんとやるのでなく、Zoomで『そういえば、あれさ』という風に話すようにしています。\n\n> ーー 確かに文字ベースで厳しく注意されても、冷たく感じてしまうかもしれません。Zoomなど同期のコミュニケーションであれば、感情などのニュアンスを持たせられるのは分かります。\n全てにおいて、同期もしくは非同期のコミュニケーションが優れているわけではないということですね。コミュニケーションの特性や必要性を考えて、うまく使い分けることが重要ということでしょうか。\n\n__佐々木__：はい、そうですね。\n\n> ーー リモートワークが前提のGitLabにおいて、オンボーディングをどのように実践されているか教えてください。\n\n## オールリモート環境における効率的なオンボーディング\n### 数百のタスクが集まったチケットを自分のペースでこなす\n\n![佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3707_resize.jpg)\n\n> ーー GitLabに入社したい、転職したいという方は、all-remoteの現場でどのようなオンボーディングが実施されているか気になると思います。\n\n__伊藤__：[GitLabのオンボーディング](https://handbook.gitlab.com/handbook/people-group/general-onboarding/)では、ベースとしてメンバーごとにチケットが作成され、そこに数百のタスクが箇条書きで記載されています。それらを1ヵ月程度の時間をかけてこなすという感じですね。\n\nたとえばPCのセットアップや、トレーニングビデオの視聴といったタスクが並んでいます。『ここを学んで欲しい』『PCのセットアップをする』など入社にあたって当たり前に必要となることがチケットにまとめてあるのです。これらをこなせば、自分で仕事がすすめられるまでになります。\n\n全員が同じオンボーディングを完了することで、同じスタートラインに立てるわけです。たとえばハンドブックのどのあたりにどのようなことが記載されているという感覚が身につき、あとから適切に参照できるようになります。\n\n> ーー オンボーディングの際に、トレーナーのような役割の方はつきますか？\n\n__伊藤__：はい、[トレーナー役の『バディ』](https://handbook.gitlab.com/handbook/people-group/general-onboarding/onboarding-buddies/)が新人につきます。ずっとつくというより、毎日1回、1対1で状況や困ったことがないかを確認するイメージです。\n\n## オールリモート環境における生産的なコミュニケーション法\n### チケットによるオンボーディングのよいところは、研修の全体像が可視化されること\n\n__伊藤__：この仕組みのいいところは、全体像がみえる点です。ほかの会社でもオンボーディングの際は、ドキュメントを渡されると思います。一方でGitLabのオンボーディングでは、あちこち見に行かなくてもチケットをみれば研修の全体像が把握できるのです。\nチケットの仕組みを使っているので、チケット内で質問したりバディが状況をチェックして適宜フォローしたりもできます。all-remoteでは新人も不安になりやすいですが、それを取り除ける施策だと思いますね。\n\n> ーー 作業に集中するための「フォーカスタイム」をどのように確保されているか教えてください。\n\n### フォーカスタイムを入れておけば、自動的にミーティングが拒否される\n\n__伊藤__：\nフォーカスタイムは、Googleカレンダーに適宜登録します。なかにはフォーカスタイムの自動登録が可能なツールを使っているメンバーもいますね。\n\nフォーカスタイムを入れておけば、自動的にミーティングは拒否されます。それでも必要に応じて入ってきてしまうこともあるのですが、フォーカスタイムをしない場合に比べ入りづらくなりますね。作業に集中する時間の確保が求められるソフトウェア開発や技術調査、プレゼン作成などをする必要があるメンバーにとって、フォーカスタイムは特に必要です。 \n\n> ーー 非同期コミュニケーションを円滑にするためにおこなっているという「Coffee Chat」について教えてください。\n### Coffee Chatはオフィスで日常的におこなわれる立ち話を代替する手段\n\n__伊藤__：[Coffee Chat](https://handbook.gitlab.com/handbook/company/culture/all-remote/informal-communication/#coffee-chats)は雑談することを目的としたミーティングで、Zoomを使っておこないます。Coffee Chatは、非同期を加速させる手段として推奨されていますね。\n\nSlack上だけのやりとりとなり、なかなか会えないという人は社内にたくさんいます。こういった人たちと同期コミュニケーションをすることで、非同期のコミュニケーションを加速させるわけです。 \n\nただCoffee Chatは、どちらかというとall-remoteのデメリットを表しているとも思います。all-remoteでは、オフィスで日常的におこなわれるような立ち話はできません。立ち話で普通に話す方が、もっとスムーズに雑談ができるわけです。\n\nそういった観点では、Coffee Chatは立ち話の下位互換だとは思います。all-remoteで立ち話の役割を補助するのが、Coffee Chatの仕組みです。\n\n__佐々木__：普通のオフィスであれば、コーヒーを飲みにコーヒーサーバーの周りに集まって偶発的なコミュニケーションが生まれることがありますね。それをオンラインでできないか、というのがCoffee Chatのコンセプトだと理解しています。\n\nコーヒーサーバーのところで、たまたま顔を合わせた人とコミュニケーションをとるような、ランダムさが重要だと思うのです。たとえば、たまたまコーヒーサーバーのところで、隣の部署の人と顔を合わせることがありますね。そのとき『そういえばキャンプ好きでしたよね』といった何気ない会話で、雑談がはじまったりもします。\n\nそういった雑談で、繋がりができる良さがあると思いますね。困ったときに『そういえばマーケティング部門に、この前話した人がいたから相談してみよう』みたいなことがあります。\n\n僕はそういったランダムさが好きで、週1回ツールで自動的にマッチングされた人とCoffee Chatをしていますね。\n\n> ーー ふたりをはじめ、GitLabの皆さんがどのようにリモートワークを実践されているか伺いたいと思います。\u003Cbr>\n> 普段はどこでお仕事をされていますか？\n\n![伊藤俊廷](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3876_resize.jpg)\n\n__伊藤__：自宅で仕事をすることが多いです。海外や国内の出張時にはホテルのなかで仕事をしています。モバイルディスプレイを持ち込んで、自宅の環境となるべく遜色のないように工夫していますね。\n\n> ーー ワーケーションをされている方はいらっしゃいますか？\n\n__伊藤__：我々はロール的に対面でお客様と打ち合わせをする機会が多いので難しいですが、ロールによってはかなりしていますね。\n\nたとえばテクニカルサポートエンジニアは、メールベースで回答して時々Zoomでお客様と打ち合わせするといった感じなのでしやすいと思います。たとえば、シンガポール在住のサポートエンジニアがワーケーションとして日本に来るとか、そういったことができる環境は整備されています。\n\n__佐々木__：\nワーケーションとまではいかなくても、僕はリモートワークの良さを活用する意味で時間を有効活用するようにしています。\n\nたとえば2時間ほど隙間時間ができたら、休日だと混んでいる美術館へ行くとか髪を切りに行くなどして、その時間分は朝少し早く起きて仕事したり、夜にやって調整などをしていますね。そういう融通がきくという点は一部のエンジニアにとって福利厚生というか魅力だと思いますので、僕はあえてXに投稿したりしています。\n\nもちろん『本当はこの時間に打ち合わせをしたかったのに、いなかったからできなかった』といったような迷惑がかからないようにはしていますね。\n\n> ーー 仕事をする時間は決まっていますか？個人の裁量に委ねられているのでしょうか？\n\n__伊藤__：契約上は何時間働くなど最低限の決まりはありますが、基本的には個人の裁量に任せられていますね。たとえば我々はお客様対応が中心なので、それが滞りなく進められていれば良いということになります。\n\n__佐々木__：\nサポートエンジニアやSREの人などにはオンコール体制があり、その時間はトラブルや問い合わせに対応できるようにしないといけないというのはあります。ただ、それも毎日ずっとというわけではないので、ある程度柔軟にはできると思います。\n\n> ーー 他企業がリモートワークに失敗している原因について、ご意見をお聞かせください。\u003Cbr>\n> リモートワークでコミュニケーション不足になったり生産性が低下したりして、リモートワーク導入が失敗している企業が少なくありません。これらの原因について、ご意見をお聞かせいただければと思います。\n\n__伊藤__：リモートワークでは、コミュニケーション不足は絶対的に起こるので、工夫するしかないですね。たとえば会社の文化にも依存するのですが、オンライン会議などでカメラをオンにしない方もいます。そういった点も、コミュニケーション不足の原因になっているのではないかと思いますね。\n\n> ーー カメラは重要でしょうか？\n\n__伊藤__：はい。Coffee Chatのときも含め、GitLabでは全員ではないもののほとんどの人がカメラをつけています。カメラをつけるかつけないかで、Zoomでコミュニケーションをとるときなどの情報量も違いますね。\n\nコミュニケーション不足は避けられないにしても、その不足を補うという点でカメラをオンにするのは重要だと思います。\n\n> ーー コミュニケーションの工夫という点では、GitLab様の文化で素晴らしいと思った点があります。オンライン会議などでお子さんや飼い犬が映っても、それを悪とせずコミュニケーションのきっかけにするということですね。こういった文化も、GitLab様でコミュニケーション不足を防ぐ意味で有効かなと思いました。が起きにくい理由かなと思いました。\n\n__伊藤__：ミーティングの質にもよりますが、割と社内で許容されていますね。\n\n> ーー リモートワークにして生産性が低下した、という企業も存在するようですが、どう思われますか？\n\n__伊藤__：特にオフィスがある状態からの予期せぬ社会的変化によるリモートワークの強制導入においては、そのように感じる背景はよく理解できるが、そもそも本当にリモートワークの実施前後で生産性を測っているのかは気になりますね。何となくの印象で『生産性が落ちた』と言われていることも多いのではと考えています。特にマネジメント側からすると、リモートワークでは従業員の顔が見えず何をしているかわかりません。それで、『生産性が下がった』と感じていることもあると思います。単にチャットツールを多用するだけではない非同期コミュニケーションにおける工夫やドキュメント化を徹底的に推進してもやはりだめだったのかについて気になります。\n\n> ーー ソリューションアーキテクトという職種について教えていただきたいと思います。\u003Cbr>\n> まずはソリューションアーキテクトの職務範囲について教えてください。\n\n## GitLabのソリューションアーキテクトの役割とスキル\n![佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3907_resize.jpg)\n\n__佐々木__：[厳密な定義はHandbookに記載](https://handbook.gitlab.com/job-families/sales/solutions-architect/)されていますが、ここではもう少し主観的に紹介しますね。ソリューションアーキテクトには、仕事の方向性が大きく分けて3つあると考えます。\n\nひとつ目はお客様に向けた方向性で、これは一番重要で割合の大きな部分だと考えます。ソリューションアーキテクトは単に技術営業として製品を紹介したり、デモをしたりするだけではありません。\n\nお客様の組織やプロセスをよく観察し、ときにはお客様自身も気付いていない課題やその解決策を提示・提案する活動があります。この活動には自社製品の知識だけでなく、開発手法・クラウドネイティブ技術・プロジェクトマネジメントといったスキルも必要です。ソリューションアーキテクトの個性や強みが活きる領域だと思いますね。\n\nふたつ目は社内です。社内に対しても、ソリューションアーキテクトの価値を発揮できるチャンスがあります。たとえば営業メンバーに対し、製品の新機能が持つ価値や解決可能な課題を説明し全員が概念として扱えるようにするイネーブルの要素です。\n\n個人的にはこういう仕事も好きで、社内でGeneral (Yorozu) Discussion Lunch Chatという場を週1回運営しています。General (Yorozu) Discussion Lunch Chatでは昼ご飯を食べながら、メンバーが質問し合ったり情報をシェアしたりするのです。\n\n最後はマーケット全体に向けた方向性になります。たとえばDevSecOpsの取り組みについては認知度が高まってきているとはいえ、十分とはいえません。クラウド技術のように先行して広まった概念に比べると一般化しているとは言えず、まだまだ知ってもらう必要があると思っています。イベント登壇やマーケティング組織と連携してのコンテンツ作成といった手法で、認知度向上に努めるのも重要な仕事ですね。\n\nこのようにソリューションアーキテクトには、やるべきことがたくさんあるとは言えるでしょう。ただ個人的には、走り回れるホワイトスペースが多くて非常にやりがいがあり楽しく感じています。\n\n> ーー ソリューションアーキテクトに英語スキルはどのくらい必要ですか？\n\n__佐々木__：もちろん英語スキルが高ければ高いほどいいのですが、いくつかの観点でお答えできればと思います。\n\n__伊藤__：自分は経験的に入社時期と組織の規模に大きく相関すると考えています。日本で採用される場合、日本にいる関連するロールでのチームメンバーが増えるにつれて、英語の必要性が少しずつ減っていくことを、他社での経験も含めて、体感しました。\n\n> ーー どういった場面で必要になりますか？\n\n__佐々木__：日常的に英語を読み書きするシーンはありますが、AIやツールの使いやすいところではあります。一番地力が必要になるのは、対面で会話する必要があるシーンですね。定例のような事前準備がしやすいシーンでなく、初めて対面するお客様や海外支社のメンバーと話すシーンでは特に英語力が求められます。\n\n> ーー TOEICスコアなどは関係がありますか？\n\n__佐々木__：よく『TOEIC L&Rテストの点がよくても英語で活躍できるわけじゃない』『TOEIC  L&Rテストはスピーキングがないので意味がない』という説も聞きます。しかし、そもそも聞けないと答えられないので、リスニングパートについては関係があると思いますね。リーディングはツールの活用でなんとかなるケースもあると思います。\n\n__伊藤__：AIを翻訳領域で活用すれば、英語で会話できる必要はなくなるという意見も耳にします。しかし、たとえAIベースの翻訳ツールが今後さらに進化したとしても、翻訳処理の遅延が完全になくなることはありません。\nまた、ビジネスでもプライベートでも、AI翻訳を介した会話で本当に人間関係を築けるのかには疑問が残ります。たとえば、海外のメンバーを含む社内のアクティビティや食事に参加したとき、自分だけが翻訳デバイスを使っていたら、意図せずとも他のメンバーから声をかけられる機会が減ることは容易に想像できると思います。\n\n上級レベルの英語運用力が測れない欠点はあるものの、私はTOEICは客観的に英語力を図るひとつの手段と考えます。外資系ソフトウェアベンダーの世界に入る前に、TOEIC L&Rテストと並行してTOEIC S&Wテストも受け、自分の英語での会話力向上に継続的に取り組んできました。\n\n> ーー 英語スキルを向上させるために、どんな努力をしていますか？\n\n__佐々木__：GitLabでは業務の必要に応じ、研修やトレーニングを受けるための費用を年間＄10,000ほど支援してくれます。この支援を活用して、英会話などの研修を受けたりアプリを利用したりといったことをかなりしましたね。あとは積極的に海外のメンバーとCoffee Chatをして、英語力を磨いています。\n\n> ーー 入社時に比べ、英語をつかうのには慣れましたか？\n\n__佐々木__：GitLab入社前は英語を使う環境はなかったので、本当に不安だった記憶があります。今では社内のメンバーであれば、何とかなるだろうという気持ちは持てるようになりました。\n\n社内メンバーなら最悪何回か聞き直したり、表現を変えて話し直したりすることができますからね。ただ、お客様相手ではそれができずまだ緊張するので、継続して英語力向上に取り組んでいく必要があると思っています。\n\n> ーー ソリューションアーキテクトのお仕事をする際の、よくある1日のスケジュールを教えてください。\n\n__佐々木__：以下のような感じですね。\n    \u003Ctable>\n        \u003Cthead>\n            \u003Ctr>\n                \u003Cth width=\"100\">時間\u003C/th>\n                \u003Cth>イベント\u003C/th>\n            \u003C/tr>\n        \u003C/thead>\n        \u003Ctbody>\n            \u003Ctr>\n                \u003Ctd>08:00\u003C/td>\n                \u003Ctd>下の子を幼稚園のバス停まで送る。\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>09:00\u003C/td>\n                \u003Ctd>位置情報ゲーム（Ingress）をしながら帰宅。その後、コーヒーを飲みながら業務開始。\u003Cbr>\n                午前中は打ち合わせがなく、集中して技術検証と新規ハンズオンのコンテンツ作成をおこなう。\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>13:00\u003C/td>\n                \u003Ctd>昼食を食べながら、同僚とZoomで製品の新機能について議論\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>14:00\u003C/td>\n                \u003Ctd>新規のお客様とディスカバリーミーティング*\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>15:30\u003C/td>\n                \u003Ctd>APAC SA Weekly Call（定例）で最近の案件について共有\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>17:00\u003C/td>\n                \u003Ctd>上の子を習い事まで送り、近くのコワーキングスペース（個室）を借りてオンライン英会話と仕事\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>19:00\u003C/td>\n                \u003Ctd>習い事が終わった子どもを迎えに行って帰宅\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>20:00\u003C/td>\n                \u003Ctd>夕食をすませ子どもと遊ぶ\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>22:00\u003C/td>\n                \u003Ctd>なんだかんだ気になって、Slackなどで仕事の対応をしてしまう（良くない日）\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>24:00\u003C/td>\n                \u003Ctd>就寝\u003C/td>\n            \u003C/tr>\n        \u003C/tbody>\n    \u003C/table>\n\n＊ディスカバリーミーティング：顧客の業務プロセス、要件、課題を深く理解し、効果的なソリューション設計のための情報を収集する初期段階の重要な会議\n\n> ーー ありがとうございました。\n\n> [GitLabで募集中のポジションはこちら](https://about.gitlab.com/jobs/all-jobs/)","culture",{"template":13,"slug":14,"featured":15},"BlogPost","tips-for-async-communication",true,{"title":5,"description":17,"authors":18,"heroImage":19,"tags":20,"category":11,"date":22,"body":10},"GitLabのソリューションアーキテクトが語る、効果的なリモートワークの実践をご紹介。",[9],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662910/Blog/Hero%20Images/async_communication_key_visual.jpg",[21],"inside GitLab","2025-01-31","md",null,{},"/ja-jp/blog/tips-for-async-communication","---\nseo:\n  title: 非同期コミュニケーションを機能させるには何が必要か？オールリモートのGitLabの働き方に見る “ルールと文化”のつくり方\n  description: GitLabのソリューションアーキテクトが語る、効果的なリモートワークの実践をご紹介。\n  ogTitle: 非同期コミュニケーションを機能させるには何が必要か？オールリモートのGitLabの働き方に見る “ルールと文化”のつくり方\n  ogDescription: GitLabのソリューションアーキテクトが語る、効果的なリモートワークの実践をご紹介。\n  noIndex: false\n  ogImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662910/Blog/Hero%20Images/async_communication_key_visual.jpg\n  ogUrl: https://about.gitlab.com/blog/tips-for-async-communication\n  ogSiteName: https://about.gitlab.com\n  ogType: article\n  canonicalUrls: https://about.gitlab.com/blog/tips-for-async-communication\ntitle: 非同期コミュニケーションを機能させるには何が必要か？オールリモートのGitLabの働き方に見る “ルールと文化”のつくり方\ndescription: GitLabのソリューションアーキテクトが語る、効果的なリモートワークの実践をご紹介。\nauthors:\n  - GitLab Japan Team\nheroImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662910/Blog/Hero%20Images/async_communication_key_visual.jpg\ntags:\n  - inside GitLab\ncategory: culture\ndate: '2025-01-31'\nslug: tips-for-async-communication\nfeatured: true\ntemplate: BlogPost\n---\n\n*写真：左よりGitLab合同会社 シニアソリューションアーキテクト佐々木直晴、スタッフソリューションアーキテクト 伊藤俊廷。書籍 『[GitLabに学ぶ 世界最先端のリモート組織のつくりかた](https://www.shoeisha.co.jp/book/detail/9784798179421)』 と 『[GitLabに学ぶ パフォーマンスを最大化させるドキュメンテーション技術](https://www.shoeisha.co.jp/book/detail/9784798185736)』 を手に*\u003Cbr>\u003Cbr>\n\n## 目次\n1. リモートワーク＝非同期コミュニケーションが発生すること\n2. 非同期コミュニケーションを改善するには？\n3. 非同期・同期コミュニケーションはどう使い分ける？\n4. オールリモート環境における効率的なオンボーディング\n5. オールリモート環境における生産的なコミュニケーション法\n6. GitLabのソリューションアーキテクトの役割とスキル\n\u003Cbr>\n\u003Cbr>\n\nコロナ禍を経た昨今、リモートワークを廃止し出社を前提とする企業が増えています。公益財団法人日本生産性本部がおこなった「第16回 働く人の意識調査※」によれば、テレワーク実施率は14.6%で過去最低を更新したとのことです。\n\n※参考：2025年1月30日公開 [第16回 働く人の意識調査 | 調査研究・提言活動 | 公益財団法人日本生産性本部](https://www.jpc-net.jp/research/detail/007214.html)\n\nリモートワークではコミュニケーションが不足しがちだったり、生産性が低下しやすかったりなどさまざまな課題が指摘されています。コロナ禍で多くの企業が導入を急いだ期間が過ぎ、日本企業におけるリモートワークは曲がり角に差し掛かっているのでしょう。それでもなお、企業はリモートワーク導入をすすめるべきなのでしょうか。\n\n今回は、リモートワークを前提とした「[all-remote](https://handbook.gitlab.com/handbook/company/culture/all-remote/)（オールリモート）」を実践されているGitLab社の担当者に「GitLabの働き方」について詳しく聞きました。オフィスを持たないGitLab社の働き方に、興味を持たれている方も多いのではないでしょうか。\n\n![佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3704_resized.jpg)\n*GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 佐々木直晴*\n\nそういった方の期待を裏切るかもしれませんが、今回話を聞いた伊藤・佐々木は、リモートワークを無条件に肯定してはいません。リモートワークはあくまで目的を達成するための手段であり、目的ではないというのがふたりの考えです。\n\n佐々木によれば __”[Everyone can contribute](https://handbook.gitlab.com/teamops/equal-contributions/)（誰もが貢献できる）”__ というGitLab社のミッションを実現する手段として、all-remoteが役立つということです。たとえばGitLab社では「サンフランシスコに住んでいないとエンジニアとして働けない」といったことはありません。採用をおこなう地域に一定のルール（※）はあるものの、少なくともオフィスがある場所でしかGitLabで働けないわけではないのです。\n\nall-remoteを実現できているおかげで、通信環境さえあれば他の地域で暮らすエンジニアもGitLab社で活躍できます。「”[Everyone can contribute](https://handbook.gitlab.com/teamops/equal-contributions/)”を重視し、『オフィスがあった方がいいね』とならないのはGitLab社の企業文化の特徴的な部分だ」と佐々木は話しました。\n\n今回のインタビューでは、ふたりにGitLab社がどのようにリモートワークを活用しているかをうかがっています。GitLab社の働き方を知りたい方、自社のリモートワーク導入に悩んでいる担当者の方はぜひ参考にしてください。\n\n※現在は、エンティティがある地域やPEOを通じて雇用が可能な地域でのみ採用を行っており、地域によっては職種を限定しています。\n\n\u003Cbr>\n\n> ーー GitLabにおける、ふたりのお仕事・役割・入社の経緯を教えてください\n## GitLabの先進的な働き方に興味を持ち ソリューションアーキテクトとして入社\n\n__伊藤__：わたしは、GitLabのソリューションアーキテクトというプリセールスエンジニアです。お客様がGitLabを導入される際に、技術面・ビジネス面それぞれの課題に対して、どのように解決できるかを一緒に考え、最適な活用方法をご提案しています。また、製品の価値をお客様のビジネスにどう活かすかを検討しながら、継続的にエンゲージメントを築くことも私の重要な役割です。\n\nGitLabには、LinkedInでリクルーターに声をかけられたことがきっかけで興味を持ち入社しました。GitLabの製品自体にも興味があったのですが、ハンドブック中心にall-remoteでドキュメンテーションをしている点にも興味を持ったのです。きっと先進的な働き方が確立されていると想定し、それを体験したかったです。\n![伊藤 俊廷](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3669_resize.jpg)\n*GitLab合同会社 ソリューションアーキテクト本部 スタッフソリューションアーキテクト 伊藤 俊廷*\n\n__佐々木__：わたしも、伊藤と同じくソリューションアーキテクトです。ソリューションアーキテクトは、GitLabを導入することで、お客様の業務やビジネスがどう変わるかにも着目します。お客様の近くで、課題を発見するという面白さがある役割ですね。\n\n入社前からGitLabを使っていて、製品自体に興味があった点はわたしも同じです。それ以外に透明性がすごいという印象もありましたね。\n\nGitLabでは以前にオペレーションのミスで、本番データベースが喪失したという事故がありました。その際、GitLabはその復旧作業をYouTubeでライブ中継していて、すごいなと思っていたのです。GitLabに入社することになったと周囲に報告した際に『復旧作業をライブ中継していた会社だよね』と言われたのは覚えています。\n\n> ーー おふたりが考えるリモートワークの定義を教えてください。\n## リモートワーク＝非同期コミュニケーションが発生すること\n### オフィスに行かないことがリモートワークではない\n\n__伊藤__：GitLabというより我々の考えになりますが、一般に言われているようにオフィスに行かないことがリモートワークという風に定義していません。\n\nたとえば東京と大阪にオフィスがあれば、オフィス間での仕事は必然的にリモートです。東京にしかオフィスがない会社でも、目の前の人とメールやSlackでやり取りするなどして、リモートでコミュニケーションをとります。突き詰めると一般的なオフィスワーカーは、働いているほんとんどの時間をリモートワークな状態で進めているのではないかと考えるようになったのです。\n\n必ずしも人と人が、いつも同じ場所・タイミングで仕事をするわけではありません。メールやSlackなどで、[非同期のコミュニケーション](https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous/)が発生することになります。\n\nこういった非同期のコラボレーションが発生することが、リモートワークとも言えますね。一方で、対面や電話、Zoomでの会議などは、同期コミュニケーションです。\n\n> ーー GitLabで実践されているall-remoteとはどんなものか教えてください\n\n### all-remoteとは物理的に集まるオフィスがなく、在宅での業務を基本とすること\n\n__伊藤__： 物理的にみんなが集まるオフィスがなく、在宅で仕事をすることが基本となるのがall-remoteです。リモートの人がいたりリモートでない人がいたりという状態でなく、全員がリモートで働けることをall-remoteと呼んでいます。\n\nall-remoteは『ほかの人と一切会わない』 ”[strictly remote](https://handbook.gitlab.com/handbook/company/culture/all-remote/stages/#10-strictly-remote)” ではありません。GitLabは対面で会うことも重視しています。GitLabチームメンバーが少ないころは、9ヵ月に1度は世界のどこかで集まるということもしていました。  \n\n> ーー 全ての企業がリモートワークを実践すべきだと思いますか？\n\n### どんな企業でも、無理にリモートワークへ切り替える必要はない\n![佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3764_resize.jpg)\n\n__佐々木__： 非同期・同期どちらのコミュニケーションが良くて、どちらが駄目というわけではありません。それぞれの特性があります。\n\n同期コミュニケーションには、Slackやメールなどと違いすぐに返事が返ってくるという良さがありますね。柔らかい状態で何か議論をはじめて輪郭をはっきりさせるフェーズにおいては、早い同期コミュニケーションが合っています。\n\n一方、ある程度枠が決まり分担して作業できたり、確認にインターバルがとれたりするフェーズでは非同期コミュニケーションも可能です。非同期のコミュニケーションは早さが劣りますが、メールなどが残りあとで探すことができます。\n\n__伊藤__：我々もZoomでちょっと話しながら、互いにアイデアを出し合うということはします。あと、たとえば製品チームなどが、大枠の設計をする際などは同期のコミュニケーションを使っていますね。同期コミュニケーションならではの良さがあるのです。同期コミュニケーションが適している企業は、無理に[all-remote](https://handbook.gitlab.com/handbook/company/culture/all-remote/stages/#9-all-remote)や[hybrid-remote](https://handbook.gitlab.com/handbook/company/culture/all-remote/stages/#5-hybrid-remote)に切り替える必要はありません。\n\nただ、非同期コミュニケーションが必ず発生するということを意識できていない組織が大半を占める印象はあります。同期コミュニケーションが適している企業でも、非同期コミュニケーションが一切不要なわけではなく、情報を一元的にドキュメント化をするデメリットは基本的にはないはずです。\n\n### 手段が整っていないから「うちはリモートワークに向かない」と思い込んでいるケースも\n\n__佐々木__：自分のところはリモートに向いていない、というのを聞くことがありますが本当にそうなのか疑問に思うことはあります。手段が整っていないから、リモートワークが向いていないと感じているだけなのか、鶏と卵の関係のような問題だと思いますね。\n\nたとえばドキュメントが整備されていなかったり、情報が集まっていなかったりすれば、確認の作業が多くなります。『この場合って、どうすればいいんだっけ』という確認作業が、その都度必要になるときは同期的な速いコミュニケーションと相性がいいのです。その結果、同じ場所にいた方が効率はいいよねってことになります。\n\nそうして非リモートで常に同じ場所で仕事をしていると、速いコミュニケーションがより促進されるわけです。ドキュメントが残らず、その場限りのコミュニケーションになりがちで、リモートが合わないという風になってしまいます。リモートワークが向かない状況は、何が原因で作り出されているのかにフォーカスする必要がありますね。\n\n## 非同期コミュニケーションを改善するには？\n### 非同期コミュニケーションの難しさを認識したうえで、意識的に改善できるかどうかが課題\n![伊藤俊廷](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3736_resize.jpg)\n\n__伊藤__：リモートワークか否かは関係なく、非同期のコミュニケーションはどうしても比重が増すと思うのですね。ソフトウェアエンジニアでもマーケティングの広報担当でも、ペアプロや資料作りを他のメンバーとずっと一緒にやるということはありません。そのため、非同期のコミュニケーションをどうやってうまくやるかに着目する必要があるのです。\n\n同期のコミュニケーション自体は、皆さんもあんまり工夫せずにできると思います。しかし非同期につなげるため、同期した内容を残すという意味のドキュメンテーションが意識できていないことが多いのではないでしょうか。非同期のコミュニケーションをどう改善するかが、多くの組織における喫緊の課題のように思います。\n\n> ーー GitLabがリモートワークを成立させるうえで大切にされているSSOTとは何かを教えてください。\n\n### SSOTは信頼できる唯一の情報源\n__佐々木__：SSOTは『Single Source of Truth』の略語で、信頼できる唯一の情報源という意味の言葉です。普段仕事をしているなかで『この点に関する情報はこれが正しい』というのを、ひとつ持ちます。そうして、それに誰もが適切にアクセスできる状態にするのです。\n\n__伊藤__：たとえばどういうお金は会社の経費として申請してよくて、会計上のコードはこれですといった話がありますね。[GitLabでは、こういった情報をインターネット上のハンドブックにまとめて公開](https://handbook.gitlab.com/handbook/finance/expenses/)しているのです。そこに書いてあることが最も確からしく、議論の前提となる情報であるという信頼性があるのがSSOTになります。\n\nGitLabではハンドブックのほか、Google Docsに保存したミーティングノートやチケットなども利用している状況です。本当であれば全ての情報がハンドブックに集約できるとよいのですが、運用上それは現実的ではありません。\n\nここに正しい情報がある、という認識がみんな揃っていることが重要と考えています。たとえば交通費精算のルールがハンドブックにあるため、誰かに精算の基本ルールを何回も聞く必要はありません。\n\n### 「正しい情報がここにある」と社員の意識が向くことが大事\n![佐々木と伊藤](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3819_resize.jpg)\n\n__伊藤__：ハンドブックがあって、そこにSSOT性の高い情報が集約されていることが重要かと思います。SlackやZoom、チケットシステムを導入しても、ハンドブックのように情報を長期的かつ正しく保存する運用をしないと大人数での非同期コミュニケーションは難しいです。『ここに書いてあることが正』という情報としてハンドブックがあることで、みんなの意識がここへ向かうというのが重要かなと思います。\n\n> ーー 非同期コミュニケーション・同期コミュニケーションをどう使い分けているか教えてください。\n## 非同期・同期コミュニケーションはどう使い分ける？\n## 業務の枠組みが決まってくるなどしたら、非同期コミュニケーションへ移行を検討する\n\n__佐々木__：速いコミュニケーションは重要ですので、同期コミュニケーションも活用します。ある程度枠組みが決まってきたり分担して作業したりができるようになってから、非同期のコミュニケーションを検討するイメージです。非同期のコミュニケーションはスピードが劣るものの、情報を残してあとで確認することができます。\n\n### 同期のコミュニケーションはニュアンスを持たせやすい\n\n__佐々木__：Slackなどの文字上・非同期のコミュニケーションに比べ、同期のコミュニケーションはニュアンスを持たせやすいですね。ちょっと敏感な話をするときは、いきなりSlackでどーんとやるのでなく、Zoomで『そういえば、あれさ』という風に話すようにしています。\n\n> ーー 確かに文字ベースで厳しく注意されても、冷たく感じてしまうかもしれません。Zoomなど同期のコミュニケーションであれば、感情などのニュアンスを持たせられるのは分かります。\n全てにおいて、同期もしくは非同期のコミュニケーションが優れているわけではないということですね。コミュニケーションの特性や必要性を考えて、うまく使い分けることが重要ということでしょうか。\n\n__佐々木__：はい、そうですね。\n\n> ーー リモートワークが前提のGitLabにおいて、オンボーディングをどのように実践されているか教えてください。\n\n## オールリモート環境における効率的なオンボーディング\n### 数百のタスクが集まったチケットを自分のペースでこなす\n\n![佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3707_resize.jpg)\n\n> ーー GitLabに入社したい、転職したいという方は、all-remoteの現場でどのようなオンボーディングが実施されているか気になると思います。\n\n__伊藤__：[GitLabのオンボーディング](https://handbook.gitlab.com/handbook/people-group/general-onboarding/)では、ベースとしてメンバーごとにチケットが作成され、そこに数百のタスクが箇条書きで記載されています。それらを1ヵ月程度の時間をかけてこなすという感じですね。\n\nたとえばPCのセットアップや、トレーニングビデオの視聴といったタスクが並んでいます。『ここを学んで欲しい』『PCのセットアップをする』など入社にあたって当たり前に必要となることがチケットにまとめてあるのです。これらをこなせば、自分で仕事がすすめられるまでになります。\n\n全員が同じオンボーディングを完了することで、同じスタートラインに立てるわけです。たとえばハンドブックのどのあたりにどのようなことが記載されているという感覚が身につき、あとから適切に参照できるようになります。\n\n> ーー オンボーディングの際に、トレーナーのような役割の方はつきますか？\n\n__伊藤__：はい、[トレーナー役の『バディ』](https://handbook.gitlab.com/handbook/people-group/general-onboarding/onboarding-buddies/)が新人につきます。ずっとつくというより、毎日1回、1対1で状況や困ったことがないかを確認するイメージです。\n\n## オールリモート環境における生産的なコミュニケーション法\n### チケットによるオンボーディングのよいところは、研修の全体像が可視化されること\n\n__伊藤__：この仕組みのいいところは、全体像がみえる点です。ほかの会社でもオンボーディングの際は、ドキュメントを渡されると思います。一方でGitLabのオンボーディングでは、あちこち見に行かなくてもチケットをみれば研修の全体像が把握できるのです。\nチケットの仕組みを使っているので、チケット内で質問したりバディが状況をチェックして適宜フォローしたりもできます。all-remoteでは新人も不安になりやすいですが、それを取り除ける施策だと思いますね。\n\n> ーー 作業に集中するための「フォーカスタイム」をどのように確保されているか教えてください。\n\n### フォーカスタイムを入れておけば、自動的にミーティングが拒否される\n\n__伊藤__：\nフォーカスタイムは、Googleカレンダーに適宜登録します。なかにはフォーカスタイムの自動登録が可能なツールを使っているメンバーもいますね。\n\nフォーカスタイムを入れておけば、自動的にミーティングは拒否されます。それでも必要に応じて入ってきてしまうこともあるのですが、フォーカスタイムをしない場合に比べ入りづらくなりますね。作業に集中する時間の確保が求められるソフトウェア開発や技術調査、プレゼン作成などをする必要があるメンバーにとって、フォーカスタイムは特に必要です。 \n\n> ーー 非同期コミュニケーションを円滑にするためにおこなっているという「Coffee Chat」について教えてください。\n### Coffee Chatはオフィスで日常的におこなわれる立ち話を代替する手段\n\n__伊藤__：[Coffee Chat](https://handbook.gitlab.com/handbook/company/culture/all-remote/informal-communication/#coffee-chats)は雑談することを目的としたミーティングで、Zoomを使っておこないます。Coffee Chatは、非同期を加速させる手段として推奨されていますね。\n\nSlack上だけのやりとりとなり、なかなか会えないという人は社内にたくさんいます。こういった人たちと同期コミュニケーションをすることで、非同期のコミュニケーションを加速させるわけです。 \n\nただCoffee Chatは、どちらかというとall-remoteのデメリットを表しているとも思います。all-remoteでは、オフィスで日常的におこなわれるような立ち話はできません。立ち話で普通に話す方が、もっとスムーズに雑談ができるわけです。\n\nそういった観点では、Coffee Chatは立ち話の下位互換だとは思います。all-remoteで立ち話の役割を補助するのが、Coffee Chatの仕組みです。\n\n__佐々木__：普通のオフィスであれば、コーヒーを飲みにコーヒーサーバーの周りに集まって偶発的なコミュニケーションが生まれることがありますね。それをオンラインでできないか、というのがCoffee Chatのコンセプトだと理解しています。\n\nコーヒーサーバーのところで、たまたま顔を合わせた人とコミュニケーションをとるような、ランダムさが重要だと思うのです。たとえば、たまたまコーヒーサーバーのところで、隣の部署の人と顔を合わせることがありますね。そのとき『そういえばキャンプ好きでしたよね』といった何気ない会話で、雑談がはじまったりもします。\n\nそういった雑談で、繋がりができる良さがあると思いますね。困ったときに『そういえばマーケティング部門に、この前話した人がいたから相談してみよう』みたいなことがあります。\n\n僕はそういったランダムさが好きで、週1回ツールで自動的にマッチングされた人とCoffee Chatをしていますね。\n\n> ーー ふたりをはじめ、GitLabの皆さんがどのようにリモートワークを実践されているか伺いたいと思います。\u003Cbr>\n> 普段はどこでお仕事をされていますか？\n\n![伊藤俊廷](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3876_resize.jpg)\n\n__伊藤__：自宅で仕事をすることが多いです。海外や国内の出張時にはホテルのなかで仕事をしています。モバイルディスプレイを持ち込んで、自宅の環境となるべく遜色のないように工夫していますね。\n\n> ーー ワーケーションをされている方はいらっしゃいますか？\n\n__伊藤__：我々はロール的に対面でお客様と打ち合わせをする機会が多いので難しいですが、ロールによってはかなりしていますね。\n\nたとえばテクニカルサポートエンジニアは、メールベースで回答して時々Zoomでお客様と打ち合わせするといった感じなのでしやすいと思います。たとえば、シンガポール在住のサポートエンジニアがワーケーションとして日本に来るとか、そういったことができる環境は整備されています。\n\n__佐々木__：\nワーケーションとまではいかなくても、僕はリモートワークの良さを活用する意味で時間を有効活用するようにしています。\n\nたとえば2時間ほど隙間時間ができたら、休日だと混んでいる美術館へ行くとか髪を切りに行くなどして、その時間分は朝少し早く起きて仕事したり、夜にやって調整などをしていますね。そういう融通がきくという点は一部のエンジニアにとって福利厚生というか魅力だと思いますので、僕はあえてXに投稿したりしています。\n\nもちろん『本当はこの時間に打ち合わせをしたかったのに、いなかったからできなかった』といったような迷惑がかからないようにはしていますね。\n\n> ーー 仕事をする時間は決まっていますか？個人の裁量に委ねられているのでしょうか？\n\n__伊藤__：契約上は何時間働くなど最低限の決まりはありますが、基本的には個人の裁量に任せられていますね。たとえば我々はお客様対応が中心なので、それが滞りなく進められていれば良いということになります。\n\n__佐々木__：\nサポートエンジニアやSREの人などにはオンコール体制があり、その時間はトラブルや問い合わせに対応できるようにしないといけないというのはあります。ただ、それも毎日ずっとというわけではないので、ある程度柔軟にはできると思います。\n\n> ーー 他企業がリモートワークに失敗している原因について、ご意見をお聞かせください。\u003Cbr>\n> リモートワークでコミュニケーション不足になったり生産性が低下したりして、リモートワーク導入が失敗している企業が少なくありません。これらの原因について、ご意見をお聞かせいただければと思います。\n\n__伊藤__：リモートワークでは、コミュニケーション不足は絶対的に起こるので、工夫するしかないですね。たとえば会社の文化にも依存するのですが、オンライン会議などでカメラをオンにしない方もいます。そういった点も、コミュニケーション不足の原因になっているのではないかと思いますね。\n\n> ーー カメラは重要でしょうか？\n\n__伊藤__：はい。Coffee Chatのときも含め、GitLabでは全員ではないもののほとんどの人がカメラをつけています。カメラをつけるかつけないかで、Zoomでコミュニケーションをとるときなどの情報量も違いますね。\n\nコミュニケーション不足は避けられないにしても、その不足を補うという点でカメラをオンにするのは重要だと思います。\n\n> ーー コミュニケーションの工夫という点では、GitLab様の文化で素晴らしいと思った点があります。オンライン会議などでお子さんや飼い犬が映っても、それを悪とせずコミュニケーションのきっかけにするということですね。こういった文化も、GitLab様でコミュニケーション不足を防ぐ意味で有効かなと思いました。が起きにくい理由かなと思いました。\n\n__伊藤__：ミーティングの質にもよりますが、割と社内で許容されていますね。\n\n> ーー リモートワークにして生産性が低下した、という企業も存在するようですが、どう思われますか？\n\n__伊藤__：特にオフィスがある状態からの予期せぬ社会的変化によるリモートワークの強制導入においては、そのように感じる背景はよく理解できるが、そもそも本当にリモートワークの実施前後で生産性を測っているのかは気になりますね。何となくの印象で『生産性が落ちた』と言われていることも多いのではと考えています。特にマネジメント側からすると、リモートワークでは従業員の顔が見えず何をしているかわかりません。それで、『生産性が下がった』と感じていることもあると思います。単にチャットツールを多用するだけではない非同期コミュニケーションにおける工夫やドキュメント化を徹底的に推進してもやはりだめだったのかについて気になります。\n\n> ーー ソリューションアーキテクトという職種について教えていただきたいと思います。\u003Cbr>\n> まずはソリューションアーキテクトの職務範囲について教えてください。\n\n## GitLabのソリューションアーキテクトの役割とスキル\n![佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3907_resize.jpg)\n\n__佐々木__：[厳密な定義はHandbookに記載](https://handbook.gitlab.com/job-families/sales/solutions-architect/)されていますが、ここではもう少し主観的に紹介しますね。ソリューションアーキテクトには、仕事の方向性が大きく分けて3つあると考えます。\n\nひとつ目はお客様に向けた方向性で、これは一番重要で割合の大きな部分だと考えます。ソリューションアーキテクトは単に技術営業として製品を紹介したり、デモをしたりするだけではありません。\n\nお客様の組織やプロセスをよく観察し、ときにはお客様自身も気付いていない課題やその解決策を提示・提案する活動があります。この活動には自社製品の知識だけでなく、開発手法・クラウドネイティブ技術・プロジェクトマネジメントといったスキルも必要です。ソリューションアーキテクトの個性や強みが活きる領域だと思いますね。\n\nふたつ目は社内です。社内に対しても、ソリューションアーキテクトの価値を発揮できるチャンスがあります。たとえば営業メンバーに対し、製品の新機能が持つ価値や解決可能な課題を説明し全員が概念として扱えるようにするイネーブルの要素です。\n\n個人的にはこういう仕事も好きで、社内でGeneral (Yorozu) Discussion Lunch Chatという場を週1回運営しています。General (Yorozu) Discussion Lunch Chatでは昼ご飯を食べながら、メンバーが質問し合ったり情報をシェアしたりするのです。\n\n最後はマーケット全体に向けた方向性になります。たとえばDevSecOpsの取り組みについては認知度が高まってきているとはいえ、十分とはいえません。クラウド技術のように先行して広まった概念に比べると一般化しているとは言えず、まだまだ知ってもらう必要があると思っています。イベント登壇やマーケティング組織と連携してのコンテンツ作成といった手法で、認知度向上に努めるのも重要な仕事ですね。\n\nこのようにソリューションアーキテクトには、やるべきことがたくさんあるとは言えるでしょう。ただ個人的には、走り回れるホワイトスペースが多くて非常にやりがいがあり楽しく感じています。\n\n> ーー ソリューションアーキテクトに英語スキルはどのくらい必要ですか？\n\n__佐々木__：もちろん英語スキルが高ければ高いほどいいのですが、いくつかの観点でお答えできればと思います。\n\n__伊藤__：自分は経験的に入社時期と組織の規模に大きく相関すると考えています。日本で採用される場合、日本にいる関連するロールでのチームメンバーが増えるにつれて、英語の必要性が少しずつ減っていくことを、他社での経験も含めて、体感しました。\n\n> ーー どういった場面で必要になりますか？\n\n__佐々木__：日常的に英語を読み書きするシーンはありますが、AIやツールの使いやすいところではあります。一番地力が必要になるのは、対面で会話する必要があるシーンですね。定例のような事前準備がしやすいシーンでなく、初めて対面するお客様や海外支社のメンバーと話すシーンでは特に英語力が求められます。\n\n> ーー TOEICスコアなどは関係がありますか？\n\n__佐々木__：よく『TOEIC L&Rテストの点がよくても英語で活躍できるわけじゃない』『TOEIC  L&Rテストはスピーキングがないので意味がない』という説も聞きます。しかし、そもそも聞けないと答えられないので、リスニングパートについては関係があると思いますね。リーディングはツールの活用でなんとかなるケースもあると思います。\n\n__伊藤__：AIを翻訳領域で活用すれば、英語で会話できる必要はなくなるという意見も耳にします。しかし、たとえAIベースの翻訳ツールが今後さらに進化したとしても、翻訳処理の遅延が完全になくなることはありません。\nまた、ビジネスでもプライベートでも、AI翻訳を介した会話で本当に人間関係を築けるのかには疑問が残ります。たとえば、海外のメンバーを含む社内のアクティビティや食事に参加したとき、自分だけが翻訳デバイスを使っていたら、意図せずとも他のメンバーから声をかけられる機会が減ることは容易に想像できると思います。\n\n上級レベルの英語運用力が測れない欠点はあるものの、私はTOEICは客観的に英語力を図るひとつの手段と考えます。外資系ソフトウェアベンダーの世界に入る前に、TOEIC L&Rテストと並行してTOEIC S&Wテストも受け、自分の英語での会話力向上に継続的に取り組んできました。\n\n> ーー 英語スキルを向上させるために、どんな努力をしていますか？\n\n__佐々木__：GitLabでは業務の必要に応じ、研修やトレーニングを受けるための費用を年間＄10,000ほど支援してくれます。この支援を活用して、英会話などの研修を受けたりアプリを利用したりといったことをかなりしましたね。あとは積極的に海外のメンバーとCoffee Chatをして、英語力を磨いています。\n\n> ーー 入社時に比べ、英語をつかうのには慣れましたか？\n\n__佐々木__：GitLab入社前は英語を使う環境はなかったので、本当に不安だった記憶があります。今では社内のメンバーであれば、何とかなるだろうという気持ちは持てるようになりました。\n\n社内メンバーなら最悪何回か聞き直したり、表現を変えて話し直したりすることができますからね。ただ、お客様相手ではそれができずまだ緊張するので、継続して英語力向上に取り組んでいく必要があると思っています。\n\n> ーー ソリューションアーキテクトのお仕事をする際の、よくある1日のスケジュールを教えてください。\n\n__佐々木__：以下のような感じですね。\n    \u003Ctable>\n        \u003Cthead>\n            \u003Ctr>\n                \u003Cth width=\"100\">時間\u003C/th>\n                \u003Cth>イベント\u003C/th>\n            \u003C/tr>\n        \u003C/thead>\n        \u003Ctbody>\n            \u003Ctr>\n                \u003Ctd>08:00\u003C/td>\n                \u003Ctd>下の子を幼稚園のバス停まで送る。\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>09:00\u003C/td>\n                \u003Ctd>位置情報ゲーム（Ingress）をしながら帰宅。その後、コーヒーを飲みながら業務開始。\u003Cbr>\n                午前中は打ち合わせがなく、集中して技術検証と新規ハンズオンのコンテンツ作成をおこなう。\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>13:00\u003C/td>\n                \u003Ctd>昼食を食べながら、同僚とZoomで製品の新機能について議論\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>14:00\u003C/td>\n                \u003Ctd>新規のお客様とディスカバリーミーティング*\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>15:30\u003C/td>\n                \u003Ctd>APAC SA Weekly Call（定例）で最近の案件について共有\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>17:00\u003C/td>\n                \u003Ctd>上の子を習い事まで送り、近くのコワーキングスペース（個室）を借りてオンライン英会話と仕事\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>19:00\u003C/td>\n                \u003Ctd>習い事が終わった子どもを迎えに行って帰宅\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>20:00\u003C/td>\n                \u003Ctd>夕食をすませ子どもと遊ぶ\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>22:00\u003C/td>\n                \u003Ctd>なんだかんだ気になって、Slackなどで仕事の対応をしてしまう（良くない日）\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>24:00\u003C/td>\n                \u003Ctd>就寝\u003C/td>\n            \u003C/tr>\n        \u003C/tbody>\n    \u003C/table>\n\n＊ディスカバリーミーティング：顧客の業務プロセス、要件、課題を深く理解し、効果的なソリューション設計のための情報を収集する初期段階の重要な会議\n\n> ーー ありがとうございました。\n\n> [GitLabで募集中のポジションはこちら](https://about.gitlab.com/jobs/all-jobs/)\n",{"title":5,"description":17,"ogTitle":5,"ogDescription":17,"noIndex":29,"ogImage":19,"ogUrl":30,"ogSiteName":31,"ogType":32,"canonicalUrls":30},false,"https://about.gitlab.com/blog/tips-for-async-communication","https://about.gitlab.com","article","ja-jp/blog/tips-for-async-communication",[35],"inside-gitlab",[21],"bWAYcGpyF6mFCFlxy3F3gDyJdqhcyA5ameWvsAKeJnQ",{"logo":39,"freeTrial":44,"sales":49,"login":54,"items":59,"search":379,"minimal":412,"duo":429,"switchNav":438,"pricingDeployment":449},{"config":40},{"href":41,"dataGaName":42,"dataGaLocation":43},"/ja-jp/","gitlab logo","header",{"text":45,"config":46},"無料トライアルを開始",{"href":47,"dataGaName":48,"dataGaLocation":43},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp&glm_content=default-saas-trial/","free trial",{"text":50,"config":51},"お問い合わせ",{"href":52,"dataGaName":53,"dataGaLocation":43},"/ja-jp/sales/","sales",{"text":55,"config":56},"サインイン",{"href":57,"dataGaName":58,"dataGaLocation":43},"https://gitlab.com/users/sign_in/","sign in",[60,89,191,196,299,360],{"text":61,"config":62,"menu":64},"プラットフォーム",{"dataNavLevelOne":63},"platform",{"type":65,"columns":66},"cards",[67,73,81],{"title":61,"description":68,"link":69},"DevSecOpsに特化したインテリジェントオーケストレーションプラットフォーム",{"text":70,"config":71},"プラットフォームを探索",{"href":72,"dataGaName":63,"dataGaLocation":43},"/ja-jp/platform/",{"title":74,"description":75,"link":76},"GitLab Duo Agent Platform","ソフトウェアライフサイクル全体を支えるエージェント型AI",{"text":77,"config":78},"GitLab Duoのご紹介",{"href":79,"dataGaName":80,"dataGaLocation":43},"/ja-jp/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":82,"description":83,"link":84},"GitLabが選ばれる理由","エンタープライズがGitLabを選ぶ主な理由をご覧ください",{"text":85,"config":86},"詳細はこちら",{"href":87,"dataGaName":88,"dataGaLocation":43},"/ja-jp/why-gitlab/","why gitlab",{"text":90,"left":15,"config":91,"menu":93},"製品",{"dataNavLevelOne":92},"solutions",{"type":94,"link":95,"columns":99,"feature":170},"lists",{"text":96,"config":97},"すべてのソリューションを表示",{"href":98,"dataGaName":92,"dataGaLocation":43},"/ja-jp/solutions/",[100,125,148],{"title":101,"description":102,"link":103,"items":108},"自動化","CI/CDと自動化でデプロイを加速",{"config":104},{"icon":105,"href":106,"dataGaName":107,"dataGaLocation":43},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[109,113,116,121],{"text":110,"config":111},"CI/CD",{"href":112,"dataGaLocation":43,"dataGaName":110},"/ja-jp/solutions/continuous-integration/",{"text":74,"config":114},{"href":79,"dataGaLocation":43,"dataGaName":115},"gitlab duo agent platform - product menu",{"text":117,"config":118},"ソースコード管理",{"href":119,"dataGaLocation":43,"dataGaName":120},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":122,"config":123},"自動化されたソフトウェアデリバリー",{"href":106,"dataGaLocation":43,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"セキュリティ","セキュリティを犠牲にすることなくコード作成を高速化",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":43,"icon":132},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[134,138,143],{"text":135,"config":136},"アプリケーションセキュリティテスト",{"href":130,"dataGaName":137,"dataGaLocation":43},"Application security testing",{"text":139,"config":140},"ソフトウェアサプライチェーンの安全性",{"href":141,"dataGaLocation":43,"dataGaName":142},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":144,"config":145},"ソフトウェアコンプライアンス",{"href":146,"dataGaName":147,"dataGaLocation":43},"/ja-jp/solutions/software-compliance/","software compliance",{"title":149,"link":150,"items":155},"測定",{"config":151},{"icon":152,"href":153,"dataGaName":154,"dataGaLocation":43},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[156,160,165],{"text":157,"config":158},"可視性と測定",{"href":153,"dataGaLocation":43,"dataGaName":159},"Visibility and Measurement",{"text":161,"config":162},"バリューストリーム管理",{"href":163,"dataGaLocation":43,"dataGaName":164},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":166,"config":167},"分析とインサイト",{"href":168,"dataGaLocation":43,"dataGaName":169},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":171,"type":94,"items":172},"GitLabが活躍する場所",[173,179,185],{"text":174,"config":175},"エンタープライズ",{"icon":176,"href":177,"dataGaLocation":43,"dataGaName":178},"Building","/ja-jp/enterprise/","enterprise",{"text":180,"config":181},"スモールビジネス",{"icon":182,"href":183,"dataGaLocation":43,"dataGaName":184},"Work","/ja-jp/small-business/","small business",{"text":186,"config":187},"公共部門",{"icon":188,"href":189,"dataGaLocation":43,"dataGaName":190},"Organization","/ja-jp/solutions/public-sector/","public sector",{"text":192,"config":193},"価格",{"href":194,"dataGaName":195,"dataGaLocation":43,"dataNavLevelOne":195},"/ja-jp/pricing/","pricing",{"text":197,"config":198,"menu":200},"リソース",{"dataNavLevelOne":199},"resources",{"type":94,"link":201,"columns":205,"feature":285},{"text":202,"config":203},"すべてのリソースを表示",{"href":204,"dataGaName":199,"dataGaLocation":43},"/ja-jp/resources/",[206,239,257],{"title":207,"items":208},"はじめに",[209,214,219,224,229,234],{"text":210,"config":211},"インストール",{"href":212,"dataGaName":213,"dataGaLocation":43},"/ja-jp/install/","install",{"text":215,"config":216},"クイックスタートガイド",{"href":217,"dataGaName":218,"dataGaLocation":43},"/ja-jp/get-started/","quick setup checklists",{"text":220,"config":221},"学ぶ",{"href":222,"dataGaLocation":43,"dataGaName":223},"https://university.gitlab.com/","learn",{"text":225,"config":226},"製品ドキュメント",{"href":227,"dataGaName":228,"dataGaLocation":43},"https://docs.gitlab.com/ja-jp/","product documentation",{"text":230,"config":231},"ベストプラクティスビデオ",{"href":232,"dataGaName":233,"dataGaLocation":43},"/ja-jp/getting-started-videos/","best practice videos",{"text":235,"config":236},"インテグレーション",{"href":237,"dataGaName":238,"dataGaLocation":43},"/ja-jp/integrations/","integrations",{"title":240,"items":241},"検索する",[242,247,252],{"text":243,"config":244},"お客様成功事例",{"href":245,"dataGaName":246,"dataGaLocation":43},"/ja-jp/customers/","customer success stories",{"text":248,"config":249},"ブログ",{"href":250,"dataGaName":251,"dataGaLocation":43},"/ja-jp/blog/","blog",{"text":253,"config":254},"リモート",{"href":255,"dataGaName":256,"dataGaLocation":43},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":258,"items":259},"つなげる",[260,265,270,275,280],{"text":261,"config":262},"GitLabサービス",{"href":263,"dataGaName":264,"dataGaLocation":43},"/ja-jp/services/","services",{"text":266,"config":267},"コミュニティ",{"href":268,"dataGaName":269,"dataGaLocation":43},"/community/","community",{"text":271,"config":272},"フォーラム",{"href":273,"dataGaName":274,"dataGaLocation":43},"https://forum.gitlab.com/","forum",{"text":276,"config":277},"イベント",{"href":278,"dataGaName":279,"dataGaLocation":43},"/events/","events",{"text":281,"config":282},"パートナー",{"href":283,"dataGaName":284,"dataGaLocation":43},"/ja-jp/partners/","partners",{"config":286,"text":289,"image":290,"link":294},{"background":287,"textColor":288},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":291,"config":292},"ソースプロモカード",{"src":293},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":295,"config":296},"最新情報を読む",{"href":297,"dataGaName":298,"dataGaLocation":43},"/ja-jp/the-source/","the source",{"text":300,"config":301,"menu":303},"会社情報",{"dataNavLevelOne":302},"company",{"type":94,"columns":304},[305],{"items":306},[307,312,318,320,325,330,335,340,345,350,355],{"text":308,"config":309},"GitLabについて",{"href":310,"dataGaName":311,"dataGaLocation":43},"/ja-jp/company/","about",{"text":313,"config":314,"footerGa":317},"採用情報",{"href":315,"dataGaName":316,"dataGaLocation":43},"/jobs/","jobs",{"dataGaName":316},{"text":276,"config":319},{"href":278,"dataGaName":279,"dataGaLocation":43},{"text":321,"config":322},"経営陣",{"href":323,"dataGaName":324,"dataGaLocation":43},"/company/team/e-group/","leadership",{"text":326,"config":327},"チーム",{"href":328,"dataGaName":329,"dataGaLocation":43},"/company/team/","team",{"text":331,"config":332},"ハンドブック",{"href":333,"dataGaName":334,"dataGaLocation":43},"https://handbook.gitlab.com/","handbook",{"text":336,"config":337},"投資家向け情報",{"href":338,"dataGaName":339,"dataGaLocation":43},"https://ir.gitlab.com/","investor relations",{"text":341,"config":342},"トラストセンター",{"href":343,"dataGaName":344,"dataGaLocation":43},"/ja-jp/security/","trust center",{"text":346,"config":347},"AI Transparency Center",{"href":348,"dataGaName":349,"dataGaLocation":43},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":351,"config":352},"ニュースレター",{"href":353,"dataGaName":354,"dataGaLocation":43},"/company/contact/#contact-forms","newsletter",{"text":356,"config":357},"プレス",{"href":358,"dataGaName":359,"dataGaLocation":43},"/press/","press",{"text":50,"config":361,"menu":362},{"dataNavLevelOne":302},{"type":94,"columns":363},[364],{"items":365},[366,369,374],{"text":50,"config":367},{"href":52,"dataGaName":368,"dataGaLocation":43},"talk to sales",{"text":370,"config":371},"サポートを受ける",{"href":372,"dataGaName":373,"dataGaLocation":43},"https://support.gitlab.com","support portal",{"text":375,"config":376},"カスタマーポータル",{"href":377,"dataGaName":378,"dataGaLocation":43},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":380,"login":381,"suggestions":388},"閉じる",{"text":382,"link":383},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":384,"config":385},"GitLab.com",{"href":57,"dataGaName":386,"dataGaLocation":387},"search login","search",{"text":389,"default":390},"提案",[391,393,398,400,404,408],{"text":74,"config":392},{"href":79,"dataGaName":74,"dataGaLocation":387},{"text":394,"config":395},"コード提案（AI）",{"href":396,"dataGaName":397,"dataGaLocation":387},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":110,"config":399},{"href":112,"dataGaName":110,"dataGaLocation":387},{"text":401,"config":402},"GitLab on AWS",{"href":403,"dataGaName":401,"dataGaLocation":387},"/ja-jp/partners/technology-partners/aws/",{"text":405,"config":406},"GitLab on Google Cloud",{"href":407,"dataGaName":405,"dataGaLocation":387},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":409,"config":410},"GitLabを選ぶ理由",{"href":87,"dataGaName":411,"dataGaLocation":387},"Why GitLab?",{"freeTrial":413,"mobileIcon":417,"desktopIcon":422,"secondaryButton":425},{"text":45,"config":414},{"href":415,"dataGaName":48,"dataGaLocation":416},"https://gitlab.com/-/trials/new/","nav",{"altText":418,"config":419},"GitLabアイコン",{"src":420,"dataGaName":421,"dataGaLocation":416},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":418,"config":423},{"src":424,"dataGaName":421,"dataGaLocation":416},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":207,"config":426},{"href":427,"dataGaName":428,"dataGaLocation":416},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/get-started/","get started",{"freeTrial":430,"mobileIcon":434,"desktopIcon":436},{"text":431,"config":432},"GitLab Duoの詳細について",{"href":79,"dataGaName":433,"dataGaLocation":416},"gitlab duo",{"altText":418,"config":435},{"src":420,"dataGaName":421,"dataGaLocation":416},{"altText":418,"config":437},{"src":424,"dataGaName":421,"dataGaLocation":416},{"button":439,"mobileIcon":444,"desktopIcon":446},{"text":440,"config":441},"/switch",{"href":442,"dataGaName":443,"dataGaLocation":416},"#contact","switch",{"altText":418,"config":445},{"src":420,"dataGaName":421,"dataGaLocation":416},{"altText":418,"config":447},{"src":448,"dataGaName":421,"dataGaLocation":416},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":450,"mobileIcon":455,"desktopIcon":457},{"text":451,"config":452},"価格ページに戻る",{"href":194,"dataGaName":453,"dataGaLocation":416,"icon":454},"back to pricing","GoBack",{"altText":418,"config":456},{"src":420,"dataGaName":421,"dataGaLocation":416},{"altText":418,"config":458},{"src":424,"dataGaName":421,"dataGaLocation":416},{"title":460,"button":461,"config":466},"エージェント型AIがソフトウェア配信をどのように変革するかをご覧ください",{"text":462,"config":463},"6月10日のGitLab Transcendに申し込む",{"href":464,"dataGaName":465,"dataGaLocation":43},"/ja-jp/releases/whats-new/#sign-up","transcend event",{"layout":467,"icon":468,"disabled":29},"release","AiStar",{"data":470},{"text":471,"source":472,"edit":478,"contribute":483,"config":488,"items":493,"minimal":696},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":473,"config":474},"ページのソースを表示",{"href":475,"dataGaName":476,"dataGaLocation":477},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":479,"config":480},"このページを編集",{"href":481,"dataGaName":482,"dataGaLocation":477},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":484,"config":485},"ご協力をお願いします",{"href":486,"dataGaName":487,"dataGaLocation":477},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":489,"facebook":490,"youtube":491,"linkedin":492},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[494,539,592,635,662],{"title":192,"links":495,"subMenu":510},[496,500,505],{"text":497,"config":498},"プランの表示",{"href":194,"dataGaName":499,"dataGaLocation":477},"view plans",{"text":501,"config":502},"Premiumを選ぶ理由",{"href":503,"dataGaName":504,"dataGaLocation":477},"/ja-jp/pricing/premium/","why premium",{"text":506,"config":507},"Ultimateを選ぶ理由",{"href":508,"dataGaName":509,"dataGaLocation":477},"/ja-jp/pricing/ultimate/","why ultimate",[511],{"title":50,"links":512},[513,515,517,519,524,529,534],{"text":50,"config":514},{"href":52,"dataGaName":53,"dataGaLocation":477},{"text":370,"config":516},{"href":372,"dataGaName":373,"dataGaLocation":477},{"text":375,"config":518},{"href":377,"dataGaName":378,"dataGaLocation":477},{"text":520,"config":521},"ステータス",{"href":522,"dataGaName":523,"dataGaLocation":477},"https://status.gitlab.com/","status",{"text":525,"config":526},"利用規約",{"href":527,"dataGaName":528,"dataGaLocation":477},"/terms/","terms of use",{"text":530,"config":531},"プライバシーに関する声明",{"href":532,"dataGaName":533,"dataGaLocation":477},"/ja-jp/privacy/","privacy statement",{"text":535,"config":536},"Cookie 優先設定",{"dataGaName":537,"dataGaLocation":477,"id":538,"isOneTrustButton":15},"cookie preferences","ot-sdk-btn",{"title":90,"links":540,"subMenu":549},[541,545],{"text":542,"config":543},"DevSecOpsプラットフォーム",{"href":72,"dataGaName":544,"dataGaLocation":477},"devsecops platform",{"text":546,"config":547},"AI支援開発",{"href":79,"dataGaName":548,"dataGaLocation":477},"ai-assisted development",[550],{"title":551,"links":552},"トピック",[553,557,562,567,572,577,582,587],{"text":110,"config":554},{"href":555,"dataGaName":556,"dataGaLocation":477},"/ja-jp/topics/ci-cd/","cicd",{"text":558,"config":559},"GitOps",{"href":560,"dataGaName":561,"dataGaLocation":477},"/ja-jp/topics/gitops/","gitops",{"text":563,"config":564},"DevOps",{"href":565,"dataGaName":566,"dataGaLocation":477},"/ja-jp/topics/devops/","devops",{"text":568,"config":569},"バージョン管理",{"href":570,"dataGaName":571,"dataGaLocation":477},"/ja-jp/topics/version-control/","version control",{"text":573,"config":574},"DevSecOps",{"href":575,"dataGaName":576,"dataGaLocation":477},"/ja-jp/topics/devsecops/","devsecops",{"text":578,"config":579},"クラウドネイティブ",{"href":580,"dataGaName":581,"dataGaLocation":477},"/ja-jp/topics/cloud-native/","cloud native",{"text":583,"config":584},"コーディングのためのAI",{"href":585,"dataGaName":586,"dataGaLocation":477},"/ja-jp/topics/devops/ai-for-coding/","ai for coding",{"text":588,"config":589},"エージェント型AI",{"href":590,"dataGaName":591,"dataGaLocation":477},"/ja-jp/topics/agentic-ai/","agentic ai",{"title":593,"links":594},"ソリューション",[595,598,600,605,609,612,615,618,620,622,625,630],{"text":135,"config":596},{"href":130,"dataGaName":597,"dataGaLocation":477},"Application Security Testing",{"text":122,"config":599},{"href":106,"dataGaName":107,"dataGaLocation":477},{"text":601,"config":602},"アジャイル開発",{"href":603,"dataGaName":604,"dataGaLocation":477},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":606,"config":607},"SCM",{"href":119,"dataGaName":608,"dataGaLocation":477},"source code management",{"text":110,"config":610},{"href":112,"dataGaName":611,"dataGaLocation":477},"continuous integration & delivery",{"text":161,"config":613},{"href":163,"dataGaName":614,"dataGaLocation":477},"value stream management",{"text":558,"config":616},{"href":617,"dataGaName":561,"dataGaLocation":477},"/ja-jp/solutions/gitops/",{"text":174,"config":619},{"href":177,"dataGaName":178,"dataGaLocation":477},{"text":180,"config":621},{"href":183,"dataGaName":184,"dataGaLocation":477},{"text":623,"config":624},"公共機関",{"href":189,"dataGaName":190,"dataGaLocation":477},{"text":626,"config":627},"教育",{"href":628,"dataGaName":629,"dataGaLocation":477},"/ja-jp/solutions/education/","education",{"text":631,"config":632},"金融サービス",{"href":633,"dataGaName":634,"dataGaLocation":477},"/ja-jp/solutions/finance/","financial services",{"title":197,"links":636},[637,639,641,643,646,648,650,652,654,656,658,660],{"text":210,"config":638},{"href":212,"dataGaName":213,"dataGaLocation":477},{"text":215,"config":640},{"href":217,"dataGaName":218,"dataGaLocation":477},{"text":220,"config":642},{"href":222,"dataGaName":223,"dataGaLocation":477},{"text":225,"config":644},{"href":227,"dataGaName":645,"dataGaLocation":477},"docs",{"text":248,"config":647},{"href":250,"dataGaName":251,"dataGaLocation":477},{"text":243,"config":649},{"href":245,"dataGaName":246,"dataGaLocation":477},{"text":253,"config":651},{"href":255,"dataGaName":256,"dataGaLocation":477},{"text":261,"config":653},{"href":263,"dataGaName":264,"dataGaLocation":477},{"text":266,"config":655},{"href":268,"dataGaName":269,"dataGaLocation":477},{"text":271,"config":657},{"href":273,"dataGaName":274,"dataGaLocation":477},{"text":276,"config":659},{"href":278,"dataGaName":279,"dataGaLocation":477},{"text":281,"config":661},{"href":283,"dataGaName":284,"dataGaLocation":477},{"title":300,"links":663},[664,666,668,670,672,674,676,680,685,687,689,691],{"text":308,"config":665},{"href":310,"dataGaName":302,"dataGaLocation":477},{"text":313,"config":667},{"href":315,"dataGaName":316,"dataGaLocation":477},{"text":321,"config":669},{"href":323,"dataGaName":324,"dataGaLocation":477},{"text":326,"config":671},{"href":328,"dataGaName":329,"dataGaLocation":477},{"text":331,"config":673},{"href":333,"dataGaName":334,"dataGaLocation":477},{"text":336,"config":675},{"href":338,"dataGaName":339,"dataGaLocation":477},{"text":677,"config":678},"Sustainability",{"href":679,"dataGaName":677,"dataGaLocation":477},"/sustainability/",{"text":681,"config":682},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":683,"dataGaName":684,"dataGaLocation":477},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":341,"config":686},{"href":343,"dataGaName":344,"dataGaLocation":477},{"text":351,"config":688},{"href":353,"dataGaName":354,"dataGaLocation":477},{"text":356,"config":690},{"href":358,"dataGaName":359,"dataGaLocation":477},{"text":692,"config":693},"現代奴隷制の透明性に関する声明",{"href":694,"dataGaName":695,"dataGaLocation":477},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":697},[698,700,703],{"text":525,"config":699},{"href":527,"dataGaName":528,"dataGaLocation":477},{"text":701,"config":702},"Cookieの設定",{"dataGaName":537,"dataGaLocation":477,"id":538,"isOneTrustButton":15},{"text":530,"config":704},{"href":532,"dataGaName":533,"dataGaLocation":477},[706],{"id":707,"title":708,"body":24,"config":709,"content":711,"description":24,"extension":715,"meta":716,"navigation":15,"path":717,"seo":718,"stem":719,"__hash__":720},"blogAuthors/en-us/blog/authors/gitlab-japan-team.yml","Gitlab Japan Team",{"template":710},"BlogAuthor",{"name":9,"config":712},{"headshot":713,"ctfId":714},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659488/Blog/Author%20Headshots/gitlab-logo-extra-whitespace.png","5YWHF8vG80rluQ41QjgP7V","yml",{},"/en-us/blog/authors/gitlab-japan-team",{},"en-us/blog/authors/gitlab-japan-team","xs3yRNTInC3nd_gc5t_qSB_BOSquAfXSF9QA2S_y1g8",[722],{"content":723,"config":733},{"title":724,"description":725,"authors":726,"heroImage":727,"tags":728,"category":11,"date":731,"body":732},"OKRとは？ 導入や運用、MBOやKPIとの違い徹底解説","OKRについて、その意味や設定方法、導入、運用までを解説。MBOとの違いやエンジニア向けOKR導入の支援ツールについても詳しく説明します。",[9],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663217/Blog/Hero%20Images/AdobeStock_790549874.jpg",[729,730,629],"workflow","growth","2024-09-06","## OKR（Objectives and Key Results）とは？\n\nOKRとは、「Objectives and Key Results（目標と成果指標）」のことで、目標と成果指標を関連づけた目標管理方法のひとつです。OKRを活用することで、組織、チーム、個人が目指すゴールを共有しやすくなります。また、OKRは短期間での見直し、再設定を繰り返して運用するため、組織やプロジェクトメンバーの変化にも柔軟に対応できます。OKRは1970年代にアメリカのインテル社が導入したことをはじめ、Googleやメルカリ、Sansanなどの大企業で採用されています。\n\n## OKRの2つの目標設定方法とその使い分け \n目標管理の手法であるOKRは、企業の目標を部署や個人の目標とリンクさせて設定することが特徴です。企業の目標と部署や個人の目標を関連づけることで、高いモチベーション維持や連帯感の強化が期待できます。OKRの「Objectives（目標）」は、定性的でモチベーションアップにつながるもの、1-3ヶ月程度で達成できるものを設定します。「Key Results（成果指標）」は、達成難度を高めに設定し、60〜70%の達成度を現実的な目標として設定します。月または四半期といった短期間で目標設定、評価、最適化のサイクルを回します。OKRには2種類の目標設定方法があり、ひとつは、「ムーンショット」と呼ばれるもので「月に届く」ように難易度が高いものです。達成度は60%程度で成功とみなし、メンバーのチャレンジ精神やイノベーションを支援するものが目的です。もう1つは「ルーフショット」と呼ばれるもので、「屋根に届く」程度の難易度の目標を設定します。達成度は100%で成功とされ、確実に達成できる目標を設定します。一般的にOKRには「ムーンショット」が適しているとされていますが、導入初期など、まだOKRに慣れていない場合には「ルーフショット」を活用して、OKRが定着させるのがおすすめです。\n\n## OKRとMBOの違いとは？  \n目標管理方法には、OKRのほかにMBO（Management by Objectives）があります。OKRが定性的な目標と定量的な成果目標を組み合わせてサイクルを短期間で回すのに対して、MBOでは、社員それぞれの目標を企業の経営目標や部門の目標と連動させて業績アップにつなげます。それぞれのメリット・デメリットを把握して、チームの状態に合わせた目標管理手法を選びましょう。 \n\n### OKRのメリット・デメリット\nメリット\n\n* 月に一回、四半期などのサイクルで目標と成果指標を見直すため、柔軟に変更できる  \n* 高い目標設定とそれぞれに合わせた成果指標で、チームメンバーのモチベーションが維持できる \n\nデメリット\n\n* 全社的な取り組みとなるため、導入初期に時間と労力がかかる  \n* OKRを使ったことのある人が少ない（大手企業に限られがち）\n\n### MBOのメリット・デメリット  \nメリット \n\n* 目標を個人が設定するため、自主性が重んじられる  \n* 課題達成型でタスク管理がしやすい\n\nデメリット\n\n* 個人と組織の目標がずれる場合がある  \n* 部下の評価を行う管理職の精神的・時間的負担が大きくなりがち\n\n## OKRとKPIの違いとは？\n\nOKRとMBOはともに「Objective（目標）」を管理する手法でしたが、成果やパフォーマンスを図る指標には、OKRのほかにKPI（Key Performance Indicator）があります。OKRとKPIはどのように違うのでしょうか。下記の３つの項目について整理してみましょう。\n\n### 目的と焦点\n\nOKRは、目標（Objectives）とその達成に必要な鍵となる成果（Key Results）に焦点を当てて、組織やチームが達成したい大きな目標の達成度合いを定量的に測定します。一方KPIは、組織やチームのパフォーマンスを測定するための指標です。一般的に売上高、利益率、顧客満足度などが指標となり、ビジネスの健全性や成功を評価するのに使われます。\n\n### 範囲と対象\n\nOKRでは、組織やチーム全体の戦略的な目標や重要な取り組みに向けて成果を設定し、目標の達成度合いを測定し、進捗状況を追跡します。それに対して KPIは、特定のプロジェクト、部門、または個々の業務に関連するパフォーマンスを測定するために使用されます。KPIは、特定の業務やプロセスの効率性や成果の評価に使用されます。\n\n### 柔軟性と透明性\n\nOKRは、定期的なレビューやフィードバックを通じて目標を修正するため、柔軟性が高いことがメリットです。それぞれの目標は、チームや他のメンバーと共有されるため、透明性も高めます。一方KPIは、一度定めた指標は固定されることが多く、ほとんどの場合、定期的な見直しなどはありません。また、上級管理職や特定のチームによって管理され、外部に公開されることも滅多にありません。\n\nOKRとKPIは、それぞれ異なる目的や特性を持ちますが、ともに組織やチームの目標達成を促進する指標として、補完的に使用することができます。\n\n## なぜOKR？ OKRを導入する理由とは\n目標管理ツールであるOKRを導入することで期待される成果は大きく４つあります。 \n\n### 企業の目標を明確に共有できるため、組織としての一体感が期待できる\nOKRでは、まず企業としての大きな目標を設定し、その目標に対して各部署、プロジェクトチーム、社員一人ひとりの目標や具体的なアクションに落とし込んでいきます。このため、すべてのメンバーが最終的には企業の大きな目標達成を目指しているという一体感が持ちやすくなります。\n\n### 大きな目標に挑戦できる \nさきほどご紹介した２種類の目標設定方法の中でも、ムーンショットは60％ほどの達成率で成功とされるため、大きな目標を掲げて短いサイクルで取り組むことで、それに向かって何度も挑戦する経験を得られます。これにより、自然と大きな目標に取り組む姿勢が身につきます。\n\n### 部署間のコミュニケーションを促進   \n企業の目標を共有したうえで各部門の目標・成果指標が定められているため、同じ目標に向かってそれぞれの部門や個人がどう取り組むのかといった、部門間のコミュニケーションが期待できます。\n\n### モチベーションとエンゲージメントの向上\nOKRでは、社員の成果指標が企業の目標と紐づいているため、自分が何のためにこのタスクに携わっているかを日々意識することになります。自分の仕事が企業にどのように貢献しているか意識することで、モチベーションとエンゲージメントが向上すると考えられています。\n\n### 効果的なOKRの設定方法、運用方法とは？\nOKRの目的（Objectives）の設定では、「挑戦的であるか」「魅力的かどうか」「一貫性があるか」に注意します。次に成果指標（Key Results ) に関しては、「目的と関連性があるか」「計測可能か」「容易ではないが、達成が可能か」「重要なものにフォーカスしているか」という4点に基づき設定します。成果指標が達成されても目的が達成されないOKRの設定とは適切ではありません。これらの点に気をつけて設定した各部門や個人のOKRをチームで確認・運用します。一度設定したOKRは、1ヶ月または3ヶ月ごとに見直し、週1回程度のミーティングで進捗を確認し、必要であれば成果指標を調整します。\n\n## OKRがエンジニア部門にもたらすメリットと導入事例\nOKRの導入により、エンジニア部門が抱える以下のような課題が解決されます。\n\n* やっている業務が他部署に理解されづらい  \n* 運用部門など他の部門との連携が難しい  \n* エンジニア個人の成果が見えづらくエンゲージメントやモチベーションが低い  \n* 会社の目標とエンジニア部門の目標がリンクしづらい\n\n高度な専門性を求められる業務内容や、在宅・フレックス勤務を含む多様な勤務体制など、他部署と異なる部分も多く、他部署からの理解を得づらい場面もあるエンジニア部門。定性的な会社の目標やビジョンとエンジニア部門の目標が乖離してしまうこともしばしば起こります。OKRは、そんなエンジニア部門の課題を解決できるかもしれません。OKRがエンジニア部門にもたらすメリットを導入事例と共に見てみましょう。\n\n### Google \nGoogleでは2000年ごろから導入を開始し、3ヶ月ごとにOKRを見直し、定期的なミーティングでOKRの評価を行なっています。達成度は70%程度に設定され、作業の進捗や評価内容は全スタッフで共有、確認できるようになっています。わかりづらかったエンジニア部門のタスク内容や進捗が明確化され、部門間の連携強化につながっています。全社的に浸透度も高く、OKRの導入がGoogleを世界規模の会社へ押し上げたとの見方もあります。\n\n### メルカリ\n企業が急成長した2015年ごろより導入を開始。OKRとしてエンジニアは、担当するプロジェクトの他に「新しい技術習得」などの個人的なOKRも設定しています。定期的にエンジニアチームのマネージャーと進捗確認や振り返りを行いながら、OKRを運用します。マネージャーと成果目標を定めることで、チームの成長とエンジニアの成長がリンクし、エンジニア部門全体でモチベーションアップを実現しています。\n\n### Sansan\nMBOを採用していたものの、会社の目標とエンジニア部門の目標がリンクしづらくOKRに変更。会社の方針を受けて部門の方針を決め、その中で個人のOKRを設定することで、開発するプロダクトの方向性や業務の意義をエンジニアが理解しやすくなりました。また全社で掲げる定性的な目標への貢献度とOKRの達成度をバランスよく参考するなどし、独自の人事評価にもOKRを取り入れています。\n\n## OKR導入はツールで自動化するのがおすすめ  \nここまでOKR導入が企業にもたらすメリットについて述べてきましたが、どのようにOKRを始めたらいいのかお悩みの方もいらっしゃるのではないでしょうか。全社でOKRを導入するとなると管理にあてるリソースが増えてしまうことも事実です。企業が抱える課題に対する認識の共有や、短期的に見直されるOKRの内容、頻繁に変更される評価指標などをわかりやすく管理しなくてはなりません。こういった煩雑なステップを統括してくれるのがOKR支援ツールです。ツールを使うことで、目標の設定や成果指標の変更、社内共有までを一元管理できます。また、タスクに割り当てるユーザーの設定やタスク進捗の追跡なども簡単な操作で行うことができます。エンジニアなど特定業種に特化したOKR導入支援ツールもあり、運用までのすべてのステップを一括でサポートしてくれます。\n\n## OKR導入にあたってGitLabができること \nOKRの導入、運用を包括的にサポートし実現するAPIツールが「[GitLab](https://about.gitlab.com/ja-jp/)」です。GitLabなら、OKRの導入から運用までに必要な内容が一元管理できます。最適なOKRの設計、タスクの割り当て、進捗の共有など、OKRに必要なさまざまな業務を効率的に実施できます。初心者にも使いやすいUIや、[DevSecOps](https://about.gitlab.com/ja-jp/platform/)に強いGitLabならではのセキュアな環境を提供し、エンジニア部門だけでなく運用部門も含めて全社的に使っていただける「OKRの導入に最適なツール」です。\n\n## OKRについてよくある質問  \n### OKRはどんな意味ですか？\nOKRとは、「Objectives and Key Results」の略で、「目標と成果指標」などと呼ばれる目標管理手法のひとつです。\n\n### OKRとKPIの違いは何ですか？\nOKRは、企業としての目標から逆算された高い目標（60〜70%の達成を目指す）に向けて、よりイノベーティブな成長を目指す指標とされ、人事評価と強く結びつけないことがほとんどです。一方KPIは、最終目標に対してプロセスごとの定量的ゴールを設定し、目標達成のための成果進捗管理が主な役割となります。KPIでは、業績の向上に直結する指標を使って100%達成を目指す目標を設定します。\n\n### OKRを導入するときに気をつけることを教えてください   \n導入の際に気をつけるポイントとしては、以下の４つが挙げられます。\n\n* OKRは社内全体で公開、共有する  \n* 月1回または四半期に1回、内容確認を行い、成果指標などを最適化する  \n* OKRは、60〜70%の達成度でも成功とするチャレンジングな目標とする  \n* OKRの導入や運用の負担を軽減するため、適切なツールを導入することが望ましい\n\nOKRを始めるには、特化した支援ツールの導入がおすすめです。簡単かつ安全にOKRを自動化するなら[GitLab](https://about.gitlab.com/ja-jp/)にお問合せください。",{"template":13,"slug":734,"featured":29},"what-is-an-okr",{"promotions":736},[737,751,763,775],{"id":738,"categories":739,"header":741,"text":742,"button":743,"image":748},"ai-modernization",[740],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":744,"config":745},"Get your AI maturity score",{"href":746,"dataGaName":747,"dataGaLocation":251},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":749},{"src":750},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":752,"categories":753,"header":755,"text":742,"button":756,"image":760},"devops-modernization",[754,576],"product","Are you just managing tools or shipping innovation?",{"text":757,"config":758},"Get your DevOps maturity score",{"href":759,"dataGaName":747,"dataGaLocation":251},"/assessments/devops-modernization-assessment/",{"config":761},{"src":762},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":764,"categories":765,"header":767,"text":742,"button":768,"image":772},"security-modernization",[766],"security","Are you trading speed for security?",{"text":769,"config":770},"Get your security maturity score",{"href":771,"dataGaName":747,"dataGaLocation":251},"/assessments/security-modernization-assessment/",{"config":773},{"src":774},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":776,"paths":777,"header":780,"text":781,"button":782,"image":787},"github-azure-migration",[778,779],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":783,"config":784},"See how GitLab compares to GitHub",{"href":785,"dataGaName":786,"dataGaLocation":251},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":788},{"src":762},{"header":790,"blurb":791,"button":792,"secondaryButton":796},"今すぐ開発をスピードアップ","DevSecOpsに特化したインテリジェントオーケストレーションプラットフォームで実現できることをご確認ください。\n",{"text":45,"config":793},{"href":794,"dataGaName":48,"dataGaLocation":795},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/ja-jp/","feature",{"text":50,"config":797},{"href":52,"dataGaName":53,"dataGaLocation":795},1777934950684]