組織開発2026-03-19

札幌のIT企業がアジャイル組織で人事をどう設計するか——従来型の人事制度では対応できない、変化に強い組織の人事設計

#採用#評価#組織開発#キャリア#制度設計

札幌のIT企業がアジャイル組織で人事をどう設計するか——従来型の人事制度では対応できない、変化に強い組織の人事設計

「半年前につくった組織図が、もう使えなくなっている」

札幌のSaaS企業のCTOが、苦笑まじりにこう話しました。プロダクトの方向性が四半期ごとに見直され、チーム編成もそれに合わせて変わる。従来の「部長→課長→係長→一般社員」というピラミッド型の組織では、このスピードについていけなかった——そこでアジャイル型の組織に移行した、というのがこの会社の経緯です。

アジャイル組織は、IT業界を中心に広がりを見せています。プロジェクトベースでチームを組成し、短いサイクルで成果を出し、状況に応じて柔軟に方向転換する。開発手法としてのアジャイルは広く認知されていますが、「アジャイル組織における人事制度」となると、多くの企業が手探りの状態です。

私はこれまで、札幌のIT企業を含む多くの組織の人事設計を支援してきました。その中で実感しているのは、アジャイル組織の人事は、従来型の人事の延長線上では設計できないということです。しかし、まったく新しい概念を一から構築する必要もありません。従来の人事制度の「考え方」を残しつつ、アジャイル組織の特性に合わせてカスタマイズする——この記事では、その具体的な方法を解説します。

アジャイル組織の特徴と人事への影響

特徴1：チーム編成が流動的

アジャイル組織では、プロジェクトやプロダクトの状況に応じてチーム編成が変わります。あるプロダクトのチームにいたエンジニアが、翌月には別のプロダクトのチームに移ることが日常的に起こります。

人事への影響は以下の通りです。

「固定的な部署」に基づく人事管理が機能しない
「誰が誰の上司か」が常に変わるため、評価者が固定できない
「部門予算」の概念が曖昧になる

特徴2：階層が少ない（フラット組織）

アジャイル組織では、意思決定のスピードを確保するため、組織の階層を少なくする傾向があります。「部長→課長→係長」という3階層ではなく、「チームリード→メンバー」の2階層、あるいはリーダーすら置かないチームもあります。

人事への影響は以下の通りです。

従来型の「昇格」を前提としたキャリアパスが機能しない
「管理職になること＝出世」という価値観が通用しない
等級制度の設計を根本から見直す必要がある

特徴3：役割がプロジェクトごとに変わる

同じ人が、あるプロジェクトではテックリードとして技術的な意思決定を行い、別のプロジェクトではメンバーとして実装に集中する——こうした「役割の流動性」がアジャイル組織の特徴です。

人事への影響は以下の通りです。

「職位」に基づく報酬設計が合わない
「役職手当」の概念を見直す必要がある
評価基準を「役職」ではなく「発揮した能力と成果」で設計する必要がある

特徴4：自律性を重視する

アジャイル組織のチームは、自律的に意思決定を行います。上司の承認を待たずに、チーム内でスプリントの計画を立て、優先順位を決め、課題を解決します。

人事への影響は以下の通りです。

「指示・命令」型のマネジメントスタイルでは機能しない
自律的に動ける人材の採用基準を明確にする必要がある
「権限委譲」の範囲と責任を明確にする必要がある

アジャイル組織の人事設計・5つの領域

領域1：等級制度の設計

従来型の等級制度は、「一般社員→主任→係長→課長→部長」という「管理職ラダー」が中心でした。アジャイル組織では、「スキルレベル」と「影響範囲」に基づく等級制度が適しています。

スキルレベルに基づく等級例

L1（ジュニア）：指導のもとで基本的な業務を遂行できる
L2（ミドル）：自律的に業務を設計・遂行できる。中程度の複雑さの問題を解決できる
L3（シニア）：高度な技術的判断ができる。チームの技術的な方向性に影響を与える
L4（スタッフ）：複数チームにまたがる技術的課題を解決できる。組織全体の技術方針に影響を与える
L5（プリンシパル）：会社全体の技術戦略をリードする。業界レベルでの影響力を持つ

この等級は「管理するかどうか」ではなく、「どの範囲にどの程度の影響を与えられるか」で定義されています。

札幌のWeb開発会社（従業員40名）では、この「影響範囲ベース」の等級制度を導入しました。「チーム内での影響」「複数チームへの影響」「組織全体への影響」の3段階で等級を定義。管理職にならなくても、技術力の向上によって等級が上がる仕組みにしたことで、エンジニアのモチベーションが大幅に向上しました。

領域2：評価制度の設計

アジャイル組織の評価制度で最も重要なのは、「誰が評価するか」と「何を評価するか」の2点です。

誰が評価するか

チーム編成が流動的なアジャイル組織では、「固定の上司が評価する」という仕組みが機能しません。代わりに、以下の方法が有効です。

360度評価：一緒に仕事をしたチームメンバー、プロジェクトマネージャー、関連部門のメンバーからフィードバックを収集する
ピアレビュー：同じチームのメンバー同士で相互に評価する
評価委員会：複数のプロジェクトを横断的に見ている管理者（エンジニアリングマネージャーなど）が評価を取りまとめる

何を評価するか

アジャイル組織での評価基準は、以下の3軸で設計します。

技術的な成果：プロダクトへの貢献、コードの品質、技術的な意思決定の質
チームへの貢献：コミュニケーション、知識共有、メンバーの支援
組織への貢献：採用活動への参加、社内勉強会の開催、プロセス改善への提案

札幌のモバイルアプリ開発会社では、四半期ごとの評価を「OKR（Objectives and Key Results）の達成度」と「ピアフィードバック」の組み合わせで実施しています。OKRはチームと個人の両方を設定し、達成度は「上司が判断する」のではなく「チーム全体で振り返る」方式です。

領域3：報酬制度の設計

アジャイル組織の報酬制度は、「等級（スキルレベル）に基づく基本給」＋「成果に連動する変動報酬」の組み合わせが基本です。

基本給

スキルレベルの等級に応じた報酬レンジを設定します。

L1（ジュニア）：年収300万〜400万円
L2（ミドル）：年収400万〜550万円
L3（シニア）：年収550万〜750万円
L4（スタッフ）：年収700万〜950万円
L5（プリンシパル）：年収900万〜1,200万円

札幌の水準として、東京の企業と比較すると基本給は低めに設定せざるを得ません。しかし、生活コストの差を考慮した「実質的な可処分所得」で見ると、十分に競争力のある水準を設計できます。

変動報酬

四半期または半期ごとの成果に連動するボーナスを設計します。チームの成果と個人の成果の両方を反映させることで、チームワークと個人のパフォーマンスのバランスを取ります。

領域4：キャリアパスの設計

アジャイル組織のキャリアパスは、「マネジメントトラック」と「個人貢献者（IC）トラック」の複線型が基本です。

マネジメントトラック

チームリード → エンジニアリングマネージャー → VP of Engineering → CTO
ピープルマネジメント（メンバーの育成・評価）が主な役割

ICトラック

シニアエンジニア → スタッフエンジニア → プリンシパルエンジニア
技術的なリーダーシップ（技術方針の策定、難題の解決）が主な役割

重要なのは、2つのトラック間の移動を可能にすることです。「マネジメントをやってみたけど、やはり技術に集中したい」という場合に、ICトラックに戻れる仕組みがあることで、社員のキャリアの柔軟性が確保されます。

札幌のクラウドサービス企業では、年1回の「キャリアチェンジウィンドウ」を設けています。この期間中に申請すれば、マネジメントトラックからICトラックへ（またはその逆の）移動が可能です。導入後2年間で4名がトラック変更を行い、全員が新しいトラックで高い成果を出しています。

領域5：採用の設計

アジャイル組織で活躍できる人材の採用基準は、従来型の組織とは異なります。

技術力に加えて重視すべき点

自律性：指示を待たずに自分で判断して行動できるか
コミュニケーション力：チーム内での議論に積極的に参加できるか。自分の考えを明確に伝えられるか
学習意欲：新しい技術やツールを自主的に学ぶ姿勢があるか
適応力：チーム編成や役割の変化に柔軟に対応できるか
フィードバック耐性：建設的なフィードバックを受け入れ、改善に活かせるか

面接では、技術的なスキルの確認に加えて、以下のような質問を通じてこれらの特性を評価します。

「チームで意見が対立したとき、どう対処しましたか」
「自分の担当範囲外の問題を発見したとき、どうしましたか」
「直近で自主的に学んだ技術やスキルは何ですか。なぜそれを学ぼうと思いましたか」

札幌のIT企業が直面する特有の課題と対処法

課題1：東京との人材獲得競争

リモートワークの普及により、札幌にいながら東京の企業で働くことが可能になりました。これは、札幌のIT企業にとって採用の競合が全国に広がることを意味します。

対処法としては、「札幌で働く意味」を明確に訴求すること。報酬面だけでなく、「チームの距離感の近さ」「意思決定への関与度の高さ」「北海道での生活の質」といった非金銭的な価値を、採用ブランディングに組み込みます。

課題2：エンジニアのキャリアの天井

従業員数50名以下の企業では、L4・L5レベルのポジションが物理的に存在しないことがあります。優秀なエンジニアが「これ以上成長できる場がない」と感じて転職するリスクがあります。

対処法としては、「社内」だけでなく「社外」も含めたキャリア支援を行うこと。OSS活動への参加支援、技術カンファレンスでの登壇支援、技術ブログの執筆支援など、社外での影響力を高める機会を提供します。

課題3：非エンジニア職との制度統一

IT企業にはエンジニア以外にも、営業、カスタマーサポート、経理、人事など様々な職種があります。アジャイル組織向けの人事制度とこれらの職種の制度をどう統一するかが課題になります。

対処法としては、「等級の考え方」は全社共通にしつつ、「評価基準」と「キャリアパス」は職種ごとにカスタマイズすること。スキルレベルと影響範囲で等級を定義するフレームワークは、エンジニア以外の職種にも適用可能です。

課題4：スクラムマスターやPOの人事上の位置づけ

アジャイル開発で重要な役割であるスクラムマスターやプロダクトオーナー（PO）を、人事制度上どう位置づけるかは悩ましい問題です。

対処法としては、これらを「役職」ではなく「役割」として定義すること。等級はスキルレベルで決まり、スクラムマスターやPOはプロジェクトにおける「役割」として別途手当（プロジェクト手当）を設定するのが現実的です。

実践事例：札幌のSaaS企業の場合

企業概要

札幌市中央区のSaaS企業。従業員62名（エンジニア35名、ビジネス職27名）
主力プロダクト：中小企業向けの業務管理SaaS
課題：急成長に伴い、従来の人事制度がスケールしなくなった

旧制度の問題点

創業5年目まで、「等級なし・評価基準なし・社長が全員の給与を直感で決める」という状態でした。社員数が30名を超えたあたりから、以下の問題が顕在化しました。

「なぜあの人のほうが給料が高いのかわからない」という不満
エンジニアの「マネジメントをやりたくないが、給料を上げたい」という要望に応えられない
中途採用時の年収提示に一貫性がない

新制度の設計

以下の制度を8ヶ月かけて設計・導入しました。

等級制度：L1〜L5の5段階。各レベルの定義を「技術的な影響範囲」「自律性」「チームへの貢献」の3軸で明文化。エンジニア職とビジネス職で別の定義書を作成。

評価制度：半期ごとの評価。「OKR達成度」（40%）＋「ピアフィードバック」（30%）＋「マネージャー評価」（30%）の加重平均。

報酬制度：各等級に報酬レンジを設定。レンジ内の位置は評価結果で決定。マネジメントトラックとICトラックで同等の報酬レンジ。

キャリアパス：複線型を導入。年1回のキャリア面談で、本人の志向とチームのニーズをすり合わせ。

結果（導入1年後）

エンジニアの離職率が年間20%から8%に低下
「評価の透明性」に関する社員満足度が35%から72%に向上
中途採用のオファー承諾率が60%から82%に向上
ICトラックを選択したシニアエンジニアが3名。うち1名はスタッフエンジニアに昇格し、アーキテクチャの全面改善をリード

CTOは「制度をつくるプロセス自体が、組織の成熟度を上げてくれた。『自分たちの組織は何を大切にするのか』をみんなで議論できたことが一番の成果かもしれない」と振り返っています。

はじめの一歩

ステップ1：現在の「評価の不透明さ」を可視化する

社員に匿名アンケートで「自分の評価基準が明確だと思うか」「現在の報酬に納得しているか」を聞いてみてください。この結果が、人事制度の見直しの起点になります。

ステップ2：「等級の定義」を仮で書いてみる

自社のエンジニアを3〜5段階に分類するとしたら、各段階の定義はどうなるか。「技術力」「影響範囲」「自律性」の3軸で、仮の定義を書いてみてください。完璧である必要はありません。この「たたき台」をもとに、エンジニアと議論を始めることが重要です。

ステップ3：ICトラックの可能性を検討する

「管理職にならなくてもキャリアが伸びる仕組み」を自社で実現するとしたら、どんな形になるか。エンジニアのリーダー層と対話し、彼らが求めるキャリアパスを聞いてみてください。

アジャイル組織の人事制度に正解のテンプレートはありません。自社のプロダクト、チーム、文化に合った形を、試行錯誤しながらつくっていく。その「つくるプロセス」自体が、アジャイルの精神に合致しています。札幌のIT企業が、変化に強い組織を支える人事制度を、自分たちの手で設計すること。その挑戦を、私は心から応援しています。