Wantedly Engineering Handbook
  • Wantedly Engineering Handbook
  • まえがき
  • 第一部:開発チームへの案内
    • 技術とアーキテクチャ
    • プロダクト概要(未執筆)
    • 開発チームの構造
    • コミュニケーションの全体
    • ドキュメンテーション(未執筆)
    • カレンダー
    • 障害対応の心構え
    • 効率的な社内知識の調べ方
    • 外部発信(執筆中)
  • 第二部:技術領域への案内
    • Apps
      • アプリを提供するプラットフォーム
      • デザインシステム入門
      • Web アプリのアーキテクチャ
      • プロダクトデザイナーと上手に協働するための心得
      • Web アプリのデザインシステムライブラリ
      • Web アプリ共通ライブラリ "React Shared Component" の紹介
      • モバイルアプリのアーキテクチャ
      • モバイルアプリのデザインシステムライブラリ(未執筆)
    • The System
      • protobuf スキーマと gRPC 通信
      • 実践: gRPC in Ruby
      • 実践: gRPC in Go
      • GraphQL Gateway - アプリ向けに API を公開する
      • Wantedly Visit で BFF GraphQL サーバーを辞めた理由
      • 実践: GraphQL スキーマ設計(未執筆)
      • API での認可処理 (Authorization)
      • マイクロサービス共通ライブラリ "servicex" の紹介
      • 非同期メッセージング処理入門(未執筆)
      • バッチ処理入門(未執筆)
    • Infrastructure
      • Infrastructure Squad
      • プロダクト開発のための Kubernetes 入門
      • インフラ構成概要
      • リリース・デプロイ戦略を支える技術
      • SaaS を活用する:New Relic, Honeybadger, Datadog
    • Data
      • データ基盤入門
      • レコメンデーション
      • Looker 入門
      • 推薦システムの開発に使っているツール
    • 開発プロセス
      • Git の慣習
      • ポストモーテムの取り組み
      • 負債返済日の取り組み
      • プロダクトの課題発見及び解決
      • ソフトウェアデザインの基礎
      • コードレビュー
      • コーディング規約
      • リリース・デプロイ戦略
      • 上長承認が必要な作業
      • アーキテクチャディシジョンレコード(ADR)
      • 作業ログを残す意味
      • 多言語化対応(i18n)
      • メール開発
    • 開発ツール
      • 社内利用している開発ツールの最新状況
      • kube
      • Code Coverage
      • Kubefork
  • おわりに
    • ロードマップ(未執筆)
    • Handbook の書き方
    • コントリビューター
  • 付録
    • 社内用語集
    • 主要な GitHub レポジトリのリスト(未執筆)
    • 今後の挑戦・未解決イシュー(未執筆)
    • プロダクト開発組織のバリュー(未執筆)
    • 採用についての考え方(未執筆)
GitBook提供
このページ内
  • 3 ステップで調べる
  • 社内向け
  • 詳しく
  • 重要なことは大体 Handbook に書いてある
  • 詳細情報は BackStage で調べる
  • それでも分からなければ Slack で聞く、過去 Issue を調べる

役に立ちましたか?

  1. 第一部:開発チームへの案内

効率的な社内知識の調べ方

前へ障害対応の心構え次へ外部発信(執筆中)

最終更新 1 年前

役に立ちましたか?

ウォンテッドリーには大量の社内ドメイン知識が存在します。 それらは業務中頻繁に遭遇するため、はじめに効率の良いキャッチアップ手順を覚えておくとよいでしょう。

3 ステップで調べる

社内で何かを調べる際は以下の 3 ステップで調べましょう

  1. で調べる

  2. で調べる

  3. Slack で聞く・過去の Github Issue/PR で調べる

社内向け

現在 Handbook に対する社内フィードバックを積極的に集めています。「欲しい情報が見つからなかった」「知りたいことが知れて便利だった」などは是非にコメントしてください。

詳しく

重要なことは大体 Handbook に書いてある

Handbook は公開前提で書かれていたり、こともあって社内で一番読みやすいドキュメンテーションになっています。 そのため、New Joiner のオンボーディングや専門外の領域について調べる際はまず初めに Handbook で調べると良いでしょう。 また、検索だけでなく目次をざっと眺めて「こういう概念あるんだ〜」のインデックスを頭に作っておくことも重要です。

ただし特定のチームやマイクロサービスに紐づく詳細情報は Handbook ではなく、個々のリポジトリに記載する運用なので、それらは後述の Backstage を用いて検索してください。

詳細情報は BackStage で調べる

Backstage は複数の Github リポジトリに存在するマークダウンファイルを横断的に検索できるツールです。

Backstage には大量のドキュメンテーションが保存されています。そのため、検索キーワードさえ知っていれば簡単に目当ての情報を得ることが可能です。

一方で、ページ数が多すぎるがゆえ明確な検索キーワードを持っていないと非常に扱いづらいです。 New Joiner や専門外の領域について調べる際は、まずは Handbook で全体像を掴んだ上で個別のトピックを Backstage で検索すると良いでしょう。

それでも分からなければ Slack で聞く、過去 Issue を調べる

Handbook や Backstage を利用すればほとんどの調べ物は行えますが、時には目当ての情報にたどり着けないこともあります。 そんなときは Slack で質問をしたり、過去の Issue/PR を探すことで欲しい情報を探しましょう。

ただし、次回以降も違う人が Slack で質問したり、過去 Issue/PR を探したりするのは非効率です。 ドキュメンテーション化されていなくて困った情報は積極的に PR を作成しましょう。

話を聞きに行きたい

Slack:

#devops_guild
Handbook
Backstage
こちらの Discussion (internal)
元々オンボーディング資料として作られていた
検索窓の場所の画像
Backstage で検索したときの png
Slack で検索したときの png