toggle holdings Engineering Handbook
  • toggle holdings Engineering Handbook
  • 🏫Chapter 1 : toggle holdings engineer 101
    • 📏バリューとポリシー
    • 💟勤務体制と福利厚生
    • 💻開発環境
    • 🐣基礎研修
      • 我々は何者か・何を目指すのか
      • エンジニアの道徳
      • エンジニアの自己理解
      • 意思決定と認知負荷
      • 効果的なコミュニケーションスキル
      • クリティカルシンキングとロジカルシンキング
      • 依頼の受け方、依頼の出し方
      • 効果的な質問の仕方
      • ミスの要因と対策
      • 成長マインドセット
      • 文書作成の基本
      • 技術ドキュメントの書き方
      • 会社の収益構造
      • Webアプリケーションの基本概念
      • HTTPとDNS
      • コンピューターネットワーク
      • メールの基本概念
      • VSCode
      • Typing
      • Linuxとシェル
      • Makefile
      • GitおよびGitHub概要
      • Git
      • GitHub
      • 要件定義
      • ソフトウェア設計とテスト
      • データベース
      • SQL
      • コンテナ技術
      • フロントエンド開発
      • バックエンド開発
      • Webアプリケーションのセキュリティと認証・認可
      • エラーメッセージの読み方
      • IaCツール
      • TypeScript
      • Python
      • MySQL
      • PostgreSQL
      • Redis
      • Docker
      • Pulumi
      • Google Apps Script
      • 推奨書籍・Webサイト
    • 🧑‍💻テックリード研修
      • 技術者がリーダーになることの重要性
      • テックリードの適格性と要件
      • テックリードのスキルセット
      • リーダーとしての自己成長
    • 📙マネージメント研修
      • エンジニアリングマネージャーの役割と責任
      • エンジニアリングマネージャーの適格性と要件
      • リーダーシップとコミュニケーション
      • プロジェクトマネジメント
      • 技術リーダーシップとイノベーション
      • パフォーマンス管理と成果の追跡
      • 変化管理と組織文化の推進
      • エンジニアリングマネージャーとしての倫理と責任
      • マネージャーとしての自己成長
    • 🤝エンジニア採用
      • 📨中途採用
      • 🥚新卒採用
    • 🛫オンボーディング
    • 📊人事制度
  • 🌐Chapter 2 : Products & Development
    • 🏢デベNAVI
    • 🧪トグルラボ
  • 📃Appendix
    • 用語集
    • 用語集(土地売買特化)
GitBook提供
このページ内
  • 等級制度
  • 等級を定義するための要素
  • 運用されている等級
  • 会社制度としての評価
  • 評価制度の構造
  • 成果評価
  • 行動評価
  • エンジニア組織における評価
  1. Chapter 1 : toggle holdings engineer 101

人事制度

toggle holdingsで働くにあたり、知っているべき人事制度

前へオンボーディング次へデベNAVI

最終更新 1 年前

人事制度とひと口に言っても、その領域やテーマは多岐にわたります。

このページでは「等級制度」と「評価制度」について説明します。

※その他の人事制度については、社内文書にある人事制度説明資料を参照してください。

等級制度

等級を定義するための要素

等級定義の要素ごとに、後述の評価制度に基づいて等級が決定されます。

運用されている等級

等級はそれぞれのキャリアステージを示し、それぞれに報酬レンジの設定があります。

会社制度としての評価

評価制度の構造

評価は「成果評価」と「行動評価」の2面で行われます。

成果評価

成果評価の目的は、会社のミッションと個人のミッションの方向性を揃え、会社が進むべき方向に共に前進できるようにすることです。また、個々人のもたらした成果を客観的に説明可能にすることで、より妥当なフィードバックを得られるような組織文化醸成も目指します。

行動評価

エンジニア組織における評価

但し、このことは会社のミッションやクレドを無視してよいということを意味しません。会社のミッションやクレドに沿った目標設定、行動評価を行うためにエンジニア組織として重視するポイントを設定しているとご認識ください。

※会社としての評価制度も、エンジニア組織の運営も始まったばかりなので、今後運用状況を鑑みてこれらの内容は変更されることがあります。

行動評価の目的は、成果を継続的に出す=再現性をもって成果を出せるようにするために行います。会社のは「継続的に成果を出す」ために必要な行動指針として設定されているものであり、これに基づいた行動が出来ているかによって評価・フィードバックを行います。

これまでに説明した会社の評価制度を踏まえ、エンジニア組織では「」に基づいた行動、すなわち「トラブルシューティングに積極的に参加して問題解決に貢献した者」「他のメンバーのPull Requestの品質を上げることに貢献した者」「積極的に業務改善し、組織全体の生産性向上に寄与する行いをした者」が成果評価につながり、実務の遂行においてはポリシーに準拠しているか、その実務は他者の模範となっているかという観点で行動評価が行われます。

🏫
📊
クレド
バリューとポリシー