Web開発・オンボーディング・採用の実例に学ぶ、リモートワークのコミュニケーションと文書術
リモートワークへの注目が高まっていますが、いざ運用すると対面とは異なるコミュニケーションに四苦八苦しているのではないでしょうか。本記事ではリモートワークを長年実践しているYassLab株式会社の安川要平（@yasulab）さんに、具体例を交えながら解説していただきます。
1
はじめまして！ 2012年に創業し、創業当初からリモートワークで働いているYassLab株式会社の安川（@yasulab）です。弊社では、RailsガイドやRailsチュートリアルといった大型コンテンツを日々更新し、36時間以上ある解説動画や1,400ページ超えの電子書籍などを個人・法人向けに提供しています。
本記事では、8年ほど実践してきたリモートワークの中で、読者の皆さんに役立つ（かもしれない）実例をいくつかご紹介します。日々のリモートワークを改善するアイデアの1つになれば嬉しいです。
- リモートワークはチームメンバーとの情報共有から始まる
- よりよい文書の読み書きがリモートワークに役立つ
- 開発に役立ったドキュメント事例集
- リモートワークの適性を見極める採用フロー
- リモートかオフィスかによらず、本質を見極め、改善を積み重ねよう
※本記事は、YouTubeのYassLabチャンネルで公開しているリモートワーク関連の動画から、一部のトピックを抜粋し、刷新したものです。
リモートワークはチームメンバーとの情報共有から始まる
弊社では、チーム内での情報共有にQiita Teamというサービスを使っています。ここに書き溜めた膨大な情報が日々活用され、リモートワークにおけるコミュニケーションやチームビルディング、そして開発などに役立っています。
新しいチームメンバーの不安を解消する
例えば、新しいチームメンバーへのサポート（オンボーディング）です。僕らにとっては日々の通常業務であっても、チームに加わる新規メンバーにとっては、1日の仕事のほぼ全てが新しい情報にあふれています。
よかれと思って、相手に役立つと思われる情報をいっぺんに渡してはいませんか？ いくら役立つ情報でも大量に渡されると、その情報量の多さに圧倒されてしまいがちです。
教育工学を専門とする向後千春（@kogo）教授の著書『いちばんやさしい教える技術』で次のように述べられているように†、こういった場面では相手に合わせて情報量を適切にコントロールすることが大事です。
- 相手にとってちょうどいい知識を与える
- 相手に教えたことを練習させて結果をフィードバックする
- 相手にできるようになってほしい具体的なゴールを決める
「分からないことがあったら聞いてね」と伝えても、「こんなことで声を掛けても大丈夫かな？」「とりあえず環境構築してるけど本当にコレでよいのかな？」と不安になってしまう新規メンバーもいるかもしれません。上記の点を意識するだけでも、大幅に改善できると思います。
†58～59ページに掲載されている「教え方のルール10カ条」より。
まずはチームの「README」を用意しよう
そこでオススメなのが、情報を適切なサイズに小分けしたREADMEを用意して、1つずつ小出しにしていくスタイルです。皆さんもツールやリポジトリを導入するときに「README」を目にした人がほとんどだと思いますが、その「README」のチーム版だと思ってください。
例えば弊社の場合は、新しいメンバーが加わったらまず次のような「README」を読んでもらうことにしています。
「セキュリティ」と「演習」がオススメ
チームごとにさまざまなまとめ方があってよいと思いますが、弊社のREADMEでは「セキュリティ」「リモートワーク」「各種チャンネル紹介」の順にまとめています。
最初に「セキュリティ」のREADMEを置いたのは、リモートワークにおいてもセキュリティが重要だということもありますが、それに加えて手を動かして進めやすいといった側面もあります。
演習で手を動かして理解してもらおう
例えば、GitHubを使っているチームであれば、実際にGPGやMFAを設定するような「演習」項目を、セキュリティのREADME中に設置することができます。
演習があると、役立つ情報を知るだけでなく、手を動かして理解することにもつながります。そのため弊社では、次のような演習をよく設けています。
さらに演習の良いところは、チェックポイントとしても機能させやすい点です。これは冒頭で紹介した「相手に教えたことを練習させて結果をフィードバックする」や、「相手にできるようになってほしい具体的なゴールを決める」とも合致しています。
例えば「この演習まで終わったら連絡してね」と伝えておくことで、新しいチームメンバーが声を掛けるきっかけにもなります。また、相手側にとっても、声を掛けるタイミングが事前に決まっていれば、先述した「こんなことで声を掛けても大丈夫かな？」という不安も払拭しやすく、チームメンバーとのやりとりを自然に発生させることにもつながります。
記事を書くのも、１つの演習
他にも「記事を書いてみよう」といった演習があります。
初めての投稿は何かと緊張しがちですが、事前にお題を用意したり過去の投稿例を示したりしておくと、「こんな投稿で大丈夫だろうか？」といった戸惑いを小さくできます。
演習のお題はさまざまですが、弊社では「躓（つまず）いたことや試してみたことを投稿しよう」といった演習も用意してあります。
これは新しいチームメンバーが投稿に慣れるようにするだけではなく、その投稿自体がREADMEに対するフィードバックになり、READMEを改善するキッカケにもなります。
そういった改善のループを回し続け、より良い体験が提供できるようになると、その後の良いチームワークにもつながるかもしれませんね！
よりよい文書の読み書きがリモートワークに役立つ
弊社のREADMEでは最初の3つ（「セキュリティ」「リモートワーク」「各種チャンネル紹介」）が完了したら、読む記事を選択式に切り替え、「次は“自分で”読む記事を決めてみよう」といった流れにしています。
用意しているトピックは多岐にわたっていて、例えば「コミュニケーション」「エンジニアリング」「デザイン」「プロジェクト・マネジメント」といったトピックがあります。
こうしてトピックを少しずつ発散させ、各自が必要だと思う内容を必要なときに読み進めるよう促しています。オープンワールドのゲームのように、最初はチュートリアル形式で進めつつ、少しずつ自由度を上げていくイメージです。
自由度が上がると、楽しさを感じる場面も増えやすいですからね😌
文書術を身につけてリモートワークを快適に
中でも手厚くまとめているのは「コミュニケーション」のトピックです。とりわけ「文書術」に関する記事の割合は大きいです。
これは対面でも同じですが、こちら側が伝えたかった意図とは異なる解釈がされ、勘違いされたまま仕事が進んでしまうと、リリース直前になって慌てることがあります。
「間違って解釈するのが悪い」と考えることも、「誤った解釈ができるのが悪い」と考えることもできますが、いずれにせよそういった認識のズレを小さくできると、チームでの仕事もうまく進みやすいですよね。
書き手のスキルを延ばしたい
弊社では両方のトピックについて用意していますが、書き手のスキルを伸ばすための記事が比較的多いです。というのも、チーム内に良い書き手が増えれば、読むスキルがまちまちでも認識のズレをより小さくできると考えているからです。
そのため弊社では「どうなると読みやすくなるのか？」「どう改善すると良いのか？」といった記事や事例紹介、演習、参考文献などを多くまとめています。
文書術の記事はレビューでも参照できる
文書術に関する記事は、リモートワークのさまざまな場面で役立ちます。例えば次のシーンでは、文章術に関する記事がレビューに貼られています。
Pull Request #106 · yasslab/yasslab.jp
レビューされる側にとって、ドキュメントがあれば「指摘された理由をもっと知りたい」と思ったときに、具体的な理解につなげやすくなります。レビューする側にとっても、指摘する理由をリンク先の記事に委ねることができます。
役に立つのは文書術だけではない
これは文書術に限らず、Gitの使い方などでも同じです。
例えば、チーム内で何らかのスタイルガイドがあったときには、記事を活用しながらレビューすることで、1回あたりのレビューのコストを小さくし、かつチーム内の取り決めをチームメンバー全員に広げていく効果も期待できます。
Pull Request #106 · yasslab/yasslab.jp
「過去に似たような指摘をしたかも……？」と感じるときがあれば、一度その考えを記事にまとめる良いタイミングかもしれませんね。そうやって用意した記事が、将来にわたって役に立つかもしれません。
目の前のタスクに忙殺されていると後回しにされがちですが、そういった地味な作業の積み重ねが、テキストコミュニケーションの比率が大きくなりがちなリモートワークにおいて、より重要になってくると感じています。
読むテクニックも身につけよう
なお、弊社では書くテクニックを重視していますが、読むテクニックも持っていると便利です。例えば「5段落のエッセイ（five-paragraph essay） 」という、よく使われる文書構造があります。
英語学習～海外発表までの流れ / Learn English to Enhance your Life - Speaker Deck
これを理解していれば、Skimming and Scanningというテクニック（動画「未踏ジュニア応募者向けフィードバック【2020年度】」を参照）と組み合わせて、効率的に記事を読み込むことができます。
詳しくはYouTubeにまとめているので、興味があれば下記の動画を参照してください😉
開発に役立ったドキュメント事例集
先ほどは文書術とGitの参照事例のみを紹介しましたが、他にはどんな場面で役立つのか、実例とともに見ていきましょう。
開発の進め方でドキュメントを参照する
弊社ではいくつかのWebサイトを開発・運営していますが、その一部は公開リポジトリとして誰でも参照できる状態となっています。
そこでも、先述したような場面をいくつか確認できます。
Pull Request #337 · coderdojo-japan/coderdojo.jp · GitHub
この「WIPでPRを出して後でsquashしよう」というドキュメント自体は、秘密情報が含まれていることもあって非公開としていますが、記事中には次のような社内における手順、OSSコミュニティにおける実例などが触れられています。
デプロイ時のトラブル対応や過去の対応例を参考に
もちろんGit/GitHub以外の記事が参照される場面もあって、例えばデプロイする場面でも役立ちます。
Pull Request #409 · coderdojo-japan/coderdojo.jp · GitHub
特にデプロイに関する場面は、トラブルが起こってから慌てて対処方法を調べるよりも、事前に対処方法を共有できた方が担当者も安心できるので、そういった点もドキュメントの良いところと言えますね😉
なお、上述のリンク先の記事も秘密情報が含まれているため非公開となっていますが、トラブル対応の手順や過去の対応例、対応時の心構えなどが解説されています。
必要性を感じた場面が記事の書きどき？
記事を参照するだけでなく、記事を作成することもあります。次の場面ではデザインに関する話題が挙がっていますが、それに該当する記事がなかったため、新たに「デザインを学ぶためのガイドライン」を書いて共有した場面です。
Pull Request #304 · coderdojo-japan/coderdojo.jp
こうして書いた記事が、今後また似たような場面があるたびに参照され、何度も何度も活用され続けます。文書術や記事作成（ドキュメンテーション）がリモートワークにおいて役立つと考えているのは、こういった場面を8年間頻繁に見かけてきたからです。
ちなみに最も役立つのは、冒頭でも触れたように新しいチームメンバーが加わったときです。最後に、新しいメンバーが加わる一歩手前のフロー、採用の場面についても考えてみましょう。
リモートワークの適性を見極める採用フロー
最後に紹介したいのが、採用フローに関する事例です。採用フローは各社が創意工夫を凝らしている箇所の1つだと思いますが、弊社では1人あたりにかける時間を大きくする方法を採っています。
規模や事業内容によって最適解が大きく異なる印象があるのであまり参考にならないかもしれませんが、あくまで小さなチームにおける1つの事例として読んでいただけると嬉しいです🙏
リモートワークという働き方に合うか・合わないか？
今でこそ認識も少しずつ広まっていますが、リモートワークは万能ではなく、人によって合う・合わないがあります。しかし、採用が決まってから「リモートワークという働き方が自分には合わなかった」と気づくのは、お互いにとって残念な結果になってしまいますよね😓
例えば弊社の場合は、先述したREADMEのような情報が至るところに用意されているため、情報を主体的に掴んで動きたい方との相性が良いです。
朝会や夕会といった同期的なコミュニケーションももちろんありますが、非同期的なコミュニケーションをする割合の方が大きいため、例えばテキストコミュニケーションがつらいと感じる方には、現時点ではあまりオススメできないかなと感じています（「現時点では」と書いているのは、そういった課題も未来のテクノロジーで解決できるかもしれないと信じているからです）。
お金をお支払いし、一緒に開発して、一緒に課題解決する
このようなリモートワークの特徴を鑑みて、弊社では一緒に開発してみる期間を設け、会社や働き方との相性を応募者自身にも判断してもらうスタイルを採っています。
とはいえ、これは応募者にとっても会社にとってもたくさんの時間を必要とする仕組みです。なので「せっかくお互いの貴重な時間を割くんだから、現実にある課題を一緒に解かない？」というスタイルを採っています。
リモートファースト企業 / Remote-first Company - Speaker Deck
具体的には、公開リポジトリ（yasslab/railsguides.jpや、yasslab/yasslab.jpや、coderdojo-japan/coderdojo.jp）から興味のあるイシュー（課題）を取ってもらい、一緒に解決しながら相性を見極めていく、といった流れになります（当該期間中も、作業期間に応じた対価をお支払いしています）。
対面でなくても相性は見極められる
この取り組みの対象となった課題の中には、例えばcoderdojo.jpというWebサイトの「近日開催の道場」をリリースしようという課題があります（本課題の詳細についてはcoderdojo-japan/coderdojo.jp#258をご参照ください）。
Pull Request #287 · coderdojo-japan/coderdojo.jp
現実の課題をお題にすることで、応募者も会社側も同じ目線に立って課題に取り組むことができ、仕事の状況に限りなく近づけることができます。さらに、もし公開リポジトリで解決した課題であれば、応募者の開発実績にもつながります。
実際、上記の機能は2番目によくアクセスされるページになり、今でもたくさんの方々に便利に使われているため、担当者の開発実績としても役に立つかなと思います（ちなみにこの方はその後本採用となりました）。
あくまでも1人1人に対して時間を掛けていくという意思決定のもとに実現できる採用フローではありますが、対面で話し合わなくてもお互いの相性を見極めていく方法はたくさんありそうですね🤝✨
リモートかオフィスかによらず、本質を見極め、改善を積み重ねよう
ここまで読んで気づいた方もいるかもしれなせんが、これまで紹介してきたさまざまな工夫は、リモートワークでなくとも役立つ話ではないかと思います。
2012年から8年以上リモートワークを続けていますが、振り返ってみるとリモートワークだからといって特別な考え方をしてきたわけではなく、こうした工夫はオフィス勤務でも十分に活用できる実例が多いのではと感じています。
僕らは「オンライン vs. オフライン」あるいは「オフィス vs. リモート」といった対立構造で捉えてしまいがちですが、本質はそこではなく、1つ1つの複雑な事例を高い解像度で分析し、昨日より良い環境になれるよう少しずつ改善を積み重ねていくことが大切かなと考えています。
長くなってしまいましたが、本記事が皆さんのご参考になれば嬉しいです！
