コミュニケーションにおけるハンドブックファーストアプローチの重要性
ハンドブックファーストのコミュニケーションアプローチは、適切に運営されるビジネスにとって密かに不可欠なものです。省略できるように感じられ、非効率にさえ見えますが、プロセス、文化、解決策を意図的に書き留めて整理することによる桁外れのメリットは驚異的です。逆に、構造化されたドキュメントを避けることは、全体的な成長を妨げる低レベルの混乱と混沌を植え付ける最善の方法です。
GitLab は単一の真実の情報源を生み出す方法でドキュメントを作成することを意図的に行っています。ハンドブックファーストで運営し、透明性を重視することで、ハンドブックをすべての人が公開アクセスできるようにしています。
用語の整理（ドキュメント、ハンドブックファースト、単一の真実の情報源）
「ドキュメント」という用語は、変更が伝達された後にドキュメントを作成するプロセスを指すことが多いです。GitLab では、まず書き留め、それを伝達します（例：最初に解決策をドキュメント化し、その後 Slack やメールで発表します）。こうすることで、コミュニケーション後のドキュメント作業が不要になり、そのステップが頻繁に省略されるという問題がなくなります。
目標はドキュメント作成のための文化を作ることではなく、新しい解決策が普及前に誰でもアクセスできるハンドブックでドキュメント化され、広く認識されている単一の真実の情報源がイテレーションされる環境を作ることです。各チームメンバーは、編集チームがスタイルガイドに従うのと同様に、同じ方法でドキュメントに取り組む必要があります。
ハンドブックファーストがなぜ重要なのか？
初期段階のスタートアップでは、ドキュメント戦略を避けたいという誘惑にかられることが特によくあります。チームメンバーが少数のうちは、ミーティング、Slack、またはメールスレッドですべての人に情報を伝えることは可能です。長期的には、この見落としはますます有害になります。
チームが拡大するにつれ、ドキュメントの必要性は、ドキュメント作成をしないことのコストと並行して増加します。言い換えると、効果的なコミュニケーション戦略の実装は、会社の成長と成熟に伴ってより困難になりつつ、より不可欠になります。
ドキュメントは、会社の創成期において、売上や顧客維持率などの指標と同じ台座に置かれることはほとんどありませんが、そうあるべきです。十分にドキュメント化された会社とハンドブックを軽視する会社との違いは歴然としています。
ハンドブックファーストの組織は、単一の真実の情報源に依拠できるメリットを受けるチームメンバーを擁しています。このタイプの組織は、ほとんど超自然的な効率性で運営できます。構造化されたドキュメントに真剣な努力を注がない組織は、チームメンバーが同じ情報を何度も何度も求め続けるのを見守るしかなく、中断、ミーティング、最適でない知識伝達の苦痛なループを生み出します。
今すぐ始める
コロケーションまたはハイブリッドリモートの確立された組織がオールリモートへの移行を望む場合、会社のハンドブックを作成するのが遅れてしまったことへの不安は共通の懸念事項です。この感情は、お互いにリモートである別々のオフィスを維持している会社でも共有されており、チームがシームレスに協力するために必要な基盤を作りたいと望んでいます。
過去を振り返ってここでの進歩を妨げないことが重要です。会社のハンドブックを開始する理想的な時期は創業時ですが、次善は今日です。
Slack やチャットメッセージをすぐに期限切れにする
GitLab では、90 日間の Slack アクティビティのみが保持されます。その後は消去されます。これは意図的なものであり、Slack がプロジェクトを端から端まで管理するためのツールとして役立つことを防ぎます。Slack、Microsoft Teams、および同様のツールはインスタントメッセージングプラットフォームであり、真の非同期文化にとってはかえって不利益になる場合があります。
チームが単一の真実の情報源に依拠できるようにすることを真剣に考えるリーダーは、インスタントメッセージの保持に関して容赦なくなるでしょう。チームメンバーが特定のプロジェクトの更新についてインスタントメッセージ履歴を検索できることを知っていれば、誰でもアクセスできる場所に進捗をドキュメント化する動機がなくなります。これは大規模な知識のギャップを生み出し、組織全体のコミュニケーション、整合性、理解をさらに分断させます。
限定された保持ポリシーは強制的な仕組みとして機能します。チームメンバーが最終的な単一の真実の情報源に直接結びついた場所で仕事の問題を議論するよう促します。GitLab では、すべての仕事、プロセス、方針はハンドブックにドキュメント化されています。
そのために、ディスカッションは GitLab Issues とマージリクエストで始まり、Slack ではありません。これにより、ハンドブックにマージされるものすべてに適切な履歴があり、コンテキストが充実していて誰でもアクセスできることが保証されます。
インスタントメッセージングツールは会話に人を追加するのが難しく、すべての作業履歴はそのプログラムに残り、作業が最終的に行き着く場所にはコンテキストが伴いません。
Slack をインフォーマルなコミュニケーションのためにのみ使用するよう組織を促すことは難しいですが、それだけの価値があります。そうしなければ、人々が更新情報やデータの断片を求めて他の人に ping し続けるという苦痛なパターンを確実に生み出し、同期ワークフローという混沌の火にさらに燃料を加えることになります。
圧倒されない
「ハンドブックファースト」の文化を根付かせることは、達成するにはあまりにも高い目標ではないかという本物の恐れがあります。目標は、その存在を会社に発表する前にハンドブックを完成させることであってはなりません。
確立された組織のコツは、イテレーションを会社内でハンドブックを立ち上げるという課題に適用することです。適切なインフラを整え（以下で説明します）、プロセスを一つずつドキュメント化し始めましょう。企業の創業期の後にハンドブックを構築することは、規模でビジネスを運営しながらプロセスと文化の両方を変更しているため、難しいです。しかし、リーダーは直感や共感を通じてハンドブックの挿入が理解しやすくなるよう期待値を管理できます。
ドキュメントに完成はない
ハンドブックは決して完成しません。それは進化し続ける生きた存在であり、ある程度包括的に感じられるようになるには数ヶ月から数年かかることがあります。
危機が訪れたときにドキュメント計画を放棄する誘惑に抵抗してください。最も強力なドキュメントは失敗から生まれます。得られた教訓は、将来何を避けるべきかと、どのようによりよく運営するかについての重要なロードマップを提供します。
ハンドブックを構築するためのツール
会社の Wiki がハンドブックとして機能できるという一般的な考えがありますが、現実には Wiki はスケールしません。Wiki は少数の選ばれた人々によって更新されるよう設計されており、いくつかの問題を引き起こします。第一に、コンテンツが頻繁に古くなり、別の人間に個人的に確認しなければ情報を信頼できないという会社全体の信念が生まれます（結果として、自己学習のプロセスに非効率性が注入されます）。
第二に、Wiki の更新を任された人々と、まだそうする権限がない人々というクラス分断が生まれます。
Wiki は高度にサイロ化されています。複数のページの複数の部分に触れる提案をサポートしません。
- GitLab（会社）は GitLab（プロダクト）を使用してハンドブックを維持・進化させています。規模に関わらず他の組織も同様にすることができます。分散バージョン管理を活用することで、会社内のすべての人（さらには会社外の人でさえ）が改善の提案を行えるようになります。
突然リモートになったためのクイックブートハンドブックガイド
ハンドブックを迅速に立ち上げる必要がある場合は、Suddenly Remote Handbook を検討してください。これは GitLab の Mike Terhar によって作成された無料ツールで、将来的にイテレーションされる可能性があります。
Getting Started セクションには、ハンドブックを立ち上げるためのステップバイステップの概要が記載されており、GitLab の学習に基づいたいくつかの事前入力セクションが含まれており、利用、調整、削除が自由にできます。
サンプルレンダリングとスターターテンプレートを動かすプロジェクトはこちらで見つかります。
GitLab を使って会社のハンドブックを構築・進化させる
GitLab は、同じ場所にいる人々も複数のタイムゾーンにまたがる人々も、より良く共同作業できるようにサポートするために設計されたコラボレーションツールです。元々、GitLab はソフトウェア開発者がコードの作成とソフトウェアアプリケーションへのパッケージ化で協力するためのものでした。今日では、GitLab は世界中のあらゆる種類の企業やロールで人々が使用する幅広い機能を持っています。
詳細については GitLab のリモートチームソリューションページをご覧ください。
チーム全体がハンドブックを進化させられるよう権限を与える
重要なのは、GitLab マージリクエストが提出者と承認者の役割を分離していることです。コードオーナーと DRI（直接責任を持つ個人）が最終的にそれぞれの提案をレビューし、マージまたは編集・マージすることに責任を持っているため、ハンドブックを提案のためにオープンにすることに問題はありません。
これにより、入社したばかりの人を含む会社の誰もが変更を提案し、会社の文化にすぐに投資した気持ちを持てます。
分散バージョン管理のパワーをハンドブックで示す例：
- このマージリクエストでは、最初の提案の一部のみが合意に達し、GitLab のハンドブックにマージされました。しかし、これにより関連するすべての関係者が意見を持つ機会を得ました。また、これらの変更がなぜ、いつ行われたかを誰でも理解できるように、最終的なドキュメントに至る思考プロセスがコンテキストとして記録されます。
- すべてのチームメンバーが提案できるよう権限を与えることで、新入社員が会社に利益をもたらす新鮮な視点を提供できます。このマージリクエストは、新入社員が GitLab のオンボーディングバディチェックリストを強化する提案を共有し、その後バディが最終的にマージされた提案を行った例です。
- このマージリクエストは GitLab でのオンボーディング段階にある人によって提案されました。ディスカッションスレッドは、学習がどのように起こるか、イテレーションがどのように提案を形成するか、そして誰もがハンドブックの進化に貢献できるかについての可視性を提供しています。
会社のハンドブックには何を入れるか？
GitLab のようなツールを使って会社のハンドブックを構築・進化させる良さは、完全な目次を事前にマッピングする必要がないことです。NotionやGuruのようなツールも使用できます。以下をトップレベルの組織化の初期ガイドとして検討しますが、会社の規模、範囲、ニーズに基づいて逸脱することをためらわないでください。
- 会社 / 基本ブロック： このセクションには、組織のほとんどまたはすべての部門に適用されるポリシー、価値観、KPI/OKR、文化的原則が含まれます。以下の推奨リストは、Luke Thomasが著書The Anywhere Operating Systemでキュレーションしたものです。
- 会社の創業ストーリー・歴史
- ミッション、ビジョン、価値観
- 誰にサービスを提供するか（顧客ペルソナ）
- 私たちが異なる理由（独自の差別化要因）
- 年間目標
- プロダクトの原則
- 採用方法
- グループ/部門： 部門ごとにハンドブックの残りの部分を構築します（例：People、Engineering、Marketing、Sales、Finance、Product、Legal）。これにより、読者は主にどのグループに影響するかという*コンテキスト*を把握できますが、ある部門のチームメンバーが他の部門にハンドブックの提案を行うことを妨げません。
- 組織構造
- 個人プロフィール
- チームプロフィール
- 日常業務
- ポリシー
- コミュニケーション方法
- 使用ツール
- 標準的な運用手順
- 月次または四半期目標
ほとんどのセクションは最初は空白で構いません。ドキュメントの精神にイテレーションを適用しましょう。セクションが薄いことを批判するのではなく、それ以前よりもわずかに改善した貢献者を称賛しましょう。
ハンドブックファーストを価値観にする
ハンドブックが継続的に成長することを確保するコツは、それを価値観として根付かせることです。チームメンバーは、まだドキュメント化されていない回答や解決策はすぐにドキュメント化されるべきだと認識すべきです。
上記の GitLab Unfiltered 動画で、Darren（GitLab Head of Remote）と Gabe（GitLab Senior Product Manager）が、ゆっくり進んで速く進むというトピックと、会社全体のドキュメントに対する「ハンドブックファースト」アプローチの重要性について話しています。
ドキュメントは価値観として根付かせる必要があると思います。そこから始まるべきであり、組織のリーダーシップチーム全体が賛同する必要があります。
リーダーシップ全員がドキュメントの重要性を理解する必要があります — 口先だけでなく。その価値についての真の、本物の理解が必要です。彼らが真にその価値を理解していれば、直属の部下にそれを浸透させるでしょう。
完全リモートへの移行を検討している企業にとって、リーダーシップに有益なステップは「OK、まずはリモートファーストで行こう」と言うことです。これは、移行中の会社が物理的なオフィス空間のすべてをリモートファーストに最適化することを意味します。例えば、多くのテーブルがある会議室を最適化する代わりに、各従業員が自分のオフィスに座り、一日中ヘッドセットを装着します。これにより、リモート従業員が切り離されたり孤立したりするのを防ぎます。
これがゆっくり進んで速く進むということです。最初に多くのエネルギーを使います — ゆっくり進みます — しかし、それは 1 年後に劇的に物事を加速させます。— Gabe W.、Senior Product Manager、GitLab
書き留めることは GitLab における効率性の運営原則です。チームメンバーは、e-group のメンバーが出したマージリクエストと、新入社員が出したマージリクエストを同様に目にする可能性があります。
会社全体が変更を提案できるよう権限を与えることで、広範な自律性と主体性が生まれます。これにより、恩送りのメンタリティを通じてドキュメントのペースを維持する共有責任が生まれます。
書記や編集チームを指定する
理想的には、誰もがハンドブックの進化に貢献するメンバーだと感じるようになります。これは、初期段階で「書き留める」ことを価値観として根付かせると、より育てやすくなります。拡大している会社が創業後多くの年数が経ってからハンドブックを追加する場合は、各チームに専任の書記を雇用することを検討してください。
元ジャーナリストはこの種の仕事に向いています。なぜなら、それは単純な書き起こし以上のものだからです。ミーティング中のメモをドキュメント化し、それを Google Docs からハンドブックに変換するには、ストーリーテリングの才能と何が重要か、どのようなコンテキストを追加すべきかについての理解が必要です。
エンジニアリングフレームワークを最新の状態に保ち、ページが更新なしに長期間放置された場合にコードオーナーに通知するハンドブック編集チームへの投資を検討してください。
このような人材はコストがかかりますが、そのコストは、何年も前にドキュメント化できたはずの回答を抽出するためにチームメンバーがミーティングに座るために継続的に払い続ける投資と比べればはるかに小さいものです。
これは機関的な知識のコストには触れていません。ドキュメント化された回答は、その後にキャリアの旅を進めたチームメンバーによってドキュメント化された情報を含め、新入社員が簡単に消化できます。
公開にする
法的に可能な範囲で、会社のハンドブックを公開することを検討してください。GitLab だけでなく、Glitch、MarsBased、Basecamp などの組織も同様にしています。公開ハンドブックは説明責任につながります。社内 Wiki を腐敗させることは、世界に公開されているハンドブックよりも簡単です。
これにより、業界の公衆や企業がプロセスを複製し、改善の提案をできます。これは、意見を提供した人々が聞かれ、考慮される権利を持つということではなく、単に自分たちの視野では考えもしなかった改善のための門を大きく開けるということです。
これはまた、志願者と新入社員にとってより歓迎的な環境を作り出します。プロセス、文化、戦略を共有することで、採用チームは、すでに会社を調査し、目標とミッションに共感していると信じる個人からのより資格のある応募者を集める可能性が高くなります。
ハンドブックファーストだけでなく…ウェブサイトファーストはさらに効率的
可能な限り、顧客、見込み客、またはより広いコミュニティがコンテンツから恩恵を受ける場合は、ドキュメントをウェブサイト（handbook.gitlab.com、docs.gitlab.com）に直接掲載する方がさらに効率的です。マーケター、プロダクトマネジメント、その他のコンテンツ生成者は、外部と内部の両方の対象者にとって SSoT（単一の真実の情報源）となる方法でコンテンツを書くことに挑戦すべきです。
例えば、あるトピックが公開ウェブサイトで説明されている場合、GitLab の内部対象者向けの必要なコメントのみをハンドブックに追加し、公開ウェブサイトの SSoT へのリンクを記載します。
GitLab ハンドブック使用法のプレゼンテーションを作成する代わりにハンドブックのスクリーンショットを使用するについての詳細をご覧ください。
ドキュメントについてさらに学ぶ
以下の GitLab リソースでドキュメントの重要性についてさらに学びましょう。
学んだことを貢献する
揺るぎない意図を持ってドキュメントに取り組むことは、すべての企業にとって課題です。あなたやあなたの組織が世界にとって有益となる経験をお持ちであれば、マージリクエストを作成し、このページに貢献することを検討してください。
メインの オールリモートページ に戻る。
bfd74782)