大阪のIT企業がアジャイル組織で人事をどう設計するか

「うちのエンジニアチームはアジャイルで開発しているのに、人事制度は昭和のままなんですよ」

大阪・本町にあるIT企業のCTOが、苦笑いでそう話してくれました。従業員70名のソフトウェア開発会社で、クライアントのDX支援を主力事業にしています。開発チームはスクラムを導入し、2週間スプリントで開発を回している。プロダクトオーナー、スクラムマスター、開発者というロールが機能し、チームは自律的に動いている。

ところが、人事制度は従来のピラミッド型の等級制度のまま。スクラムマスターの等級は「主任級」なのか「課長級」なのか不明確。プロジェクトごとにチーム編成が変わるのに、評価は「固定の上司」が行う。チームの成果と個人の成果をどう切り分けるかのルールもない。結果として、アジャイルで自律的に動いているはずのチームメンバーが、評価や報酬の面では旧来の制度に縛られている。

この矛盾は、大阪のIT企業に限った話ではありません。アジャイル的な働き方を導入する企業が増える中、人事制度がそれに追いついていないケースは非常に多い。私は大阪を中心としたIT企業で人事設計に関わる中で、「アジャイル組織にふさわしい人事制度」のあり方を探ってきました。その知見を共有します。

---

アジャイル組織と従来型組織の違い

まず、アジャイル組織と従来型組織の違いを整理します。この違いを理解しないと、人事制度の設計方針が定まりません。

意思決定の違い

従来型組織では、意思決定は階層を上がって行われます。担当者が起案し、係長が確認し、課長が承認し、部長が決裁する。一方、アジャイル組織では、チームに権限が委譲されており、チーム内で意思決定が完結します。「上の承認を待つ」のではなく、「チームが判断して動く」。

役割の違い

従来型組織では、「課長」「部長」といった職位が役割を規定します。一方、アジャイル組織では、「プロダクトオーナー」「スクラムマスター」「開発者」といったロールが役割を規定します。職位とロールは必ずしも一致しません。

チーム編成の違い

従来型組織では、部門やチームの編成は比較的固定的です。一方、アジャイル組織では、プロジェクトの特性に応じてチーム編成が流動的に変わります。あるプロジェクトではリーダーを務め、別のプロジェクトではメンバーとして参加する——こうした役割の入れ替わりが日常的に起きます。

成果の捉え方の違い

従来型組織では、個人の成果（売上、目標達成率など）が評価の中心です。一方、アジャイル組織では、チームとしてのアウトプット（プロダクトの価値、顧客への提供価値）が重視されます。個人の成果とチームの成果が密接に絡み合っているため、「誰の功績か」を切り分けることが難しい。

---

アジャイル組織における人事制度の設計ポイント

ポイント① 等級制度：「職位」ではなく「スキルと影響力」で定義する

アジャイル組織では、従来の「係長→課長→部長」というピラミッド型の等級制度は合いません。代わりに、「スキルの深さ」と「影響力の範囲」を軸にした等級制度を設計します。

大阪のあるIT企業（従業員50名）では、エンジニアの等級を以下のように設計しました。

グレード1（ジュニア）：指導のもとで基本的な開発タスクを遂行できる グレード2（ミドル）：一人で設計・実装・テストを完遂できる。チーム内で技術的な相談を受ける グレード3（シニア）：複雑な技術課題を解決できる。チームの技術的方向性に影響を与える グレード4（リード）：複数チームにまたがる技術戦略を策定できる。組織全体の技術レベルを引き上げる グレード5（プリンシパル）：事業の技術戦略を策定し、外部にも影響力を持つ

この等級制度は、「管理職になること」を昇進の前提としていません。技術者としてのスキルと影響力を高めることで、管理職にならなくても等級が上がる仕組みです。

ポイント② 評価制度：「チーム成果」と「個人の貢献」の両面で評価する

アジャイル組織の評価制度で最も難しいのが、「チームの成果」と「個人の貢献」のバランスです。チーム成果だけで評価すると、個人の努力が報われない。個人成果だけで評価すると、チームワークが損なわれる。

効果的なアプローチは、評価を「チーム成果」と「個人の行動・成長」の2軸で構成することです。

チーム成果（40%）：チームが達成したプロダクトの価値、顧客満足度、品質指標 個人の行動（30%）：チームへの貢献、コラボレーション、問題解決行動 個人の成長（30%）：スキルの向上、新技術の習得、他メンバーの育成

大阪・梅田のあるSaaS企業（従業員40名）では、この3軸評価を導入しています。チーム成果の部分は、スプリントレビューでのデモの内容やプロダクトメトリクス（バグ率、リリース頻度など）をもとに評価。個人の行動は、チームメンバー同士の360度フィードバックで評価。個人の成長は、半年ごとのスキルマップの変化で評価しています。

ポイント③ 報酬制度：「市場価値」と「役割」に基づく報酬

IT業界では、スキルの市場価値が明確に存在します。アジャイル組織の報酬制度は、この市場価値と社内での役割を基準に設計するのが合理的です。

大阪のIT企業が報酬を設計する際に考慮すべきポイント：

市場相場の把握：関西のIT人材の市場相場は、東京と比較すると5〜15%程度低い傾向がありますが、リモートワークの普及により東京基準の報酬を提示する企業も増えています。自社の採用競合がどこかを把握し、競争力のある報酬レンジを設定する必要があります。

ロールベースの報酬加算：スクラムマスターやプロダクトオーナーなど、特定のロールを担う場合にロール手当を加算する仕組み。ロールは固定ではなく、プロジェクトによって変わるため、手当もプロジェクト期間に連動させます。

スキルベースの昇給：新しい技術や資格を習得した場合に、基本給に反映する仕組み。例えば、AWS認定資格やスクラムマスター認定などの取得を昇給の要件に組み込みます。

ポイント④ 配置と異動：「チーム自律」を尊重した人材配置

アジャイル組織では、「人事部門が一方的に配置を決める」よりも、「チームのニーズとメンバーの希望をマッチングする」アプローチが適切です。

大阪のあるWeb制作会社（従業員35名）では、新しいプロジェクトが立ち上がるたびに、「チーム編成会議」を開催しています。プロジェクトに必要なスキルセットを明示し、参加を希望するメンバーを募る。複数のメンバーが希望した場合は、スキルバランスや成長機会を考慮して調整する。この方法により、「やらされ感」のない配置が実現し、メンバーのモチベーションが高まっています。

ポイント⑤ 育成：「自律的な学習」を支援する仕組み

アジャイル組織では、「会社が研修を用意して、全員が受講する」という一方的な育成よりも、「個人が自律的に学習し、会社がそれを支援する」仕組みが効果的です。

自律的な学習を支援する仕組みの例：

• 学習予算の個人配分：一人あたり年間10〜30万円の学習予算を付与し、書籍、オンライン講座、カンファレンス参加などに自由に使えるようにする
• 20%ルール：業務時間の20%を自主学習やサイドプロジェクトに使えるようにする
• 社内勉強会の奨励：新しい技術やプラクティスについて、社内で勉強会を開催するメンバーを評価する
• ペアプログラミング・モブプログラミング：日常業務の中で自然にスキル移転が起きる仕組みを作る

---

大阪のIT企業特有の課題と対応策

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

リモートワークの普及により、大阪のエンジニアが東京のIT企業にリモートで働くケースが増えています。東京基準の報酬を提示する企業と競合する中で、大阪のIT企業はどう差別化するか。

報酬だけで東京の大企業と競うのは難しい。そこで、「大阪にいながら面白い仕事ができる」「フラットな組織で裁量が大きい」「意思決定のスピードが速い」——こうした中小企業・関西企業ならではの魅力を、採用メッセージと人事制度の両面で体現することが重要です。

課題② 「SIer文化」からの脱却

大阪のIT業界は、受託開発（SIer）の比率が高い傾向があります。SIerの文化は、「クライアントの仕様書通りに作る」「工程管理を重視する」「個人の稼働率で生産性を測る」——こうした特性があり、アジャイル組織の「チーム自律」「価値駆動」「継続的改善」とは相性が良くない部分があります。

SIer文化が根強い企業がアジャイル組織に移行する場合、人事制度の変更だけでなく、事業モデルそのものの転換が必要になることがあります。「工数ビジネス」から「価値ビジネス」への転換と、人事制度の変更を同時並行で進めることが求められます。

課題③ 非エンジニア部門との整合性

IT企業であっても、営業、管理部門、カスタマーサポートなど、エンジニア以外の部門が存在します。エンジニア部門だけアジャイル型の人事制度にすると、部門間の不公平感が生まれます。

このバランスを取るアプローチとして、「人事制度のフレームワークは全社共通にし、運用をチームの特性に応じて柔軟にする」方法があります。等級の考え方（スキルと影響力）は全社共通にしつつ、具体的なスキル項目や評価方法はチームごとにカスタマイズする。

大阪のあるIT企業（従業員60名）では、全社共通の5等級制度を設計した上で、エンジニアチーム、営業チーム、管理部門それぞれに「等級定義書」を作成しています。フレームワークは共通だが、中身はチームの実態に合わせてカスタマイズしている形です。

---

アジャイル人事の導入ステップ

ステップ① 現状の課題を可視化する

まず、現在の人事制度が「アジャイル組織の実態」とどこで乖離しているかを可視化します。エンジニアへのヒアリング、評価データの分析、退職理由の分析などを通じて、課題を具体的に特定します。

ステップ② 「あるべき姿」を定義する

経営者、CTO、エンジニアリーダーと協議し、「アジャイル組織にふさわしい人事制度のあるべき姿」を定義します。全面的にアジャイル型にするのか、部分的に取り入れるのか、組織の成熟度に応じて判断します。

ステップ③ パイロットチームで試行する

新しい人事制度を全社に一斉導入するのではなく、まずは一つのチームで試行します。試行期間は3〜6か月を目安とし、運用上の課題を洗い出します。

ステップ④ フィードバックをもとに改善する

パイロットチームからのフィードバックをもとに、制度を改善します。アジャイルの精神そのものを人事制度の設計にも適用し、「小さく試して、学んで、改善する」サイクルを回します。

ステップ⑤ 段階的に展開する

パイロットチームでの成功事例をもとに、他のチームへ段階的に展開します。各チームの特性に応じてカスタマイズしながら、全社への展開を進めます。

---

大阪のIT企業だからこそできること

大阪のIT企業には、東京の大手IT企業にはない強みがあります。意思決定が速い。経営者との距離が近い。組織がフラット。変化に柔軟に対応できる。

これらの強みは、アジャイル組織と人事制度の設計において大きなアドバンテージになります。「大企業が時間をかけて検討している間に、小さく試して先に動く」——このスピード感は、関西の中小IT企業が最も発揮しやすい競争優位性です。

アジャイル組織にふさわしい人事制度は、「完成形」がありません。組織の成長とともに進化し続けるものです。まずは現状の課題を直視し、小さな一歩から始めてみてください。

---

まとめ：アジャイル人事設計チェックリスト

• [ ] アジャイル組織と従来型組織の違いを人事面で整理したか
• [ ] 等級制度を「スキルと影響力」で再定義したか
• [ ] 評価制度に「チーム成果」と「個人の行動・成長」の両面を組み込んだか
• [ ] 報酬制度に市場価値とロールを反映したか
• [ ] チーム自律を尊重した人材配置の仕組みがあるか
• [ ] 自律的な学習を支援する仕組みを整備したか
• [ ] 非エンジニア部門との整合性を確保したか
• [ ] パイロットチームでの試行を計画したか
• [ ] エンジニアの声を制度設計に反映したか
• [ ] 「小さく試して改善する」サイクルを回す体制があるか