単職能の時代は終わった——万能人材になる必要はない
IPA試験区分の見直しについて考えていると、そこから一つのメッセージが見えてくる。
単職能の時代は、終わりつつある。
もちろん、IPAがそのままそう言っているわけではない。
しかし、複数の専門区分を再編し、より横断的な能力を問う方向に向かっているのだとすれば、「ひとつの専門領域だけを深く知っていればよい」という時代認識からの変化があるように見える。
この流れ自体は、まったく新しい話ではない。
Web/DB開発の世界では、以前から「フルスタックエンジニア」という言葉が使われてきた。
フロントエンド、サーバサイド、DB、インフラ。
それぞれに専門性がある一方で、機能全体を見渡すには、それらがどうつながっているかを理解する必要がある。
画面で入力されたデータが、APIを通り、ビジネスロジックで処理され、DBに保存され、運用で監視される。
この流れを理解できなければ、局所的には正しくても、全体として使いにくいシステムになりやすい。
その意味で、横断的理解には価値がある。
しかし、現実の現場や転職市場で使われる「フルスタック」は、しばしば別の意味を帯びる。
それは、横断的に理解できる人ではなく、全部を一人で引き受けられる人である。
フロントも書ける。
サーバも書ける。
DBも設計できる。
インフラも見られる。
テストもできる。
運用も回せる。
要件も聞ける。
いわば、全部入りの役満人材である。
これは横断人材ではなく、万能人材を求める発想に近い。
「単職能だけでは足りない」という問題意識は正しい。
しかし、それを「一人で全部できる人材が必要だ」と受け取ると、話が歪む。
単職能の時代が終わるということは、万能人材になれという意味ではない。
V字モデルも、最初から横断的理解を求めていた
横断的理解が必要なのは、Web/DB開発やフルスタックという言葉が出てきてからの話ではない。
従来型のシステム開発でも、本当は同じだった。
たとえば、V字モデルがある。
左側に要件定義、基本設計、詳細設計、実装があり、右側に単体テスト、結合テスト、総合テスト、受入テストが並ぶ。
このモデルは、設計とテストが対応することを示している。
要件定義は、最終的に受入テストや総合テストで確認される。
基本設計は、結合テストや総合テストにつながる。
詳細設計や実装は、単体テストで確認される。
図としては非常にわかりやすい。
しかし、実務ではこの図を眺めているだけでは足りない。
設計フェーズにいる人は、前後の設計工程を意識する必要がある。
要件定義から何を受け取り、自分の設計で何を具体化し、次の設計や実装に何を渡すのか。
さらに、自分が作った設計が、右側のどのテストフェーズで、どのように確認されるのかも意識する必要がある。
テスト側も同じである。
テスト担当者は、単にテスト項目を消化する人ではない。
そのテスト項目が、どの設計に対応しているのか。
どの要件を確認しているのか。
前後のテスト工程とどう役割分担しているのか。
その観点を持つ必要がある。
つまり、V字モデルは最初から横断的理解を求めていた。
各フェーズだけしか意識できない人は、どうしても「手を動かす人」に近づく。
もちろん、手を動かすことには価値がある。
実装する人、テストする人、設計書を書く人がいなければ、プロジェクトは進まない。
ただ、プロジェクト全体の品質を担保するには、それだけでは足りない。
自分のフェーズが、前後のフェーズとどうつながっているのか。
左側の設計と右側のテストがどう対応しているのか。
要件が最終的にどう確認されるのか。
そこまで理解して、ようやくV字モデルは実務で機能する。
システム開発は、さらに外側へつながっている
V字モデルは、主に開発工程の中の流れを示している。
しかし、システム開発はV字モデルの中だけで閉じているわけではない。
要件定義の前には、企画や構想がある。
開発の後には、運用、保守、改善がある。
さらにその先には、プロダクトライフサイクルがある。
作って終わりではない。
リリースして終わりでもない。
システムは、業務、組織、予算、投資判断、利用者の行動とつながっている。
だから、システム開発に関わる人材には、自分の担当工程だけでなく、その前後や外側への理解も求められる。
もちろん、すべての人が経営、営業、組織、人材、会計、法務まで深く知る必要があるという話ではない。
それは無理がある。
ただ、自分の仕事がどこにつながっているのかを意識する必要はある。
自分の成果物が、前工程から何を受け取り、後工程に何を渡すのか。
その成果物が、運用や業務にどのような影響を与えるのか。
そこを意識できるかどうかで、仕事の質は変わる。
単職能資格は、無意味になるわけではない
ここで誤解したくないのは、単職能にフォーカスした知識や資格が無意味になるわけではない、ということだ。
ネットワーク、データベース、セキュリティ、テスト、プロジェクトマネジメント。
それぞれの領域には、固有の知識体系がある。
先人が整理してきた分類軸がある。
それらを学ぶことには意味がある。
むしろ、横断的に理解するためには、何らかの専門性が必要である。
何も専門性を持たないまま横断しようとしても、それは浅い一般論になりやすい。
どの領域にも足場がなければ、隣接領域との違いもわからない。
何が重要で、何が枝葉なのかも見えにくい。
だから、単職能の知識は不要になるわけではない。
ただし、その位置づけは変わる。
これまでは、ある単職能の知識を持っていることが、一定の場面では十分条件として機能していた。
この領域に詳しい。
この作業を任せられる。
この専門分野なら判断できる。
それで価値を出せる場面があった。
横断時代においては、それだけでは足りなくなる。
単職能の知識は、横断的に理解するための必要条件になる。
専門性は、そこで完結するものではなく、周辺と接続するための足場になる。
「この分野だけ知っていればよい」から、
「この分野を軸に、前後や周辺を理解する」へ。
単職能の価値が消えるのではない。
単職能だけで閉じる価値が下がるのだと思う。
横断人材は、万能人材ではない
ここで危険なのは、単職能だけでは足りないから、全分野を一人でできるようにならなければならない、という誤解である。
それは違う。
単職能の時代が終わるということは、万能人材になれという意味ではない。
開発もできる。
テストもできる。
インフラもできる。
DBもできる。
セキュリティもできる。
運用もできる。
営業もできる。
経営もわかる。
組織も動かせる。
プロジェクトもマネジメントできる。
このような全部入りを、一人の人材に期待するのは求めすぎである。
横断人材とは、全職能を自分で背負う人ではない。
自分の専門性を軸に、前後工程や周辺領域との関係を理解できる人である。
自分では実装しない領域でも、会話ができる。
自分では詳細設計しない領域でも、影響を想像できる。
自分では運用しない領域でも、運用負荷を無視しない。
自分では意思決定しない領域でも、意思決定者が何を気にするかを理解できる。
それが横断性だと思う。
万能性とは違う。
万能人材は、全部を自分でやる人として期待されやすい。
横断人材は、全部を自分でやるのではなく、全体の関係を理解し、専門家同士を接続する。
この違いを曖昧にすると、横断できる人ほど便利屋扱いされる。
「あの人なら何とかしてくれる」
「専門外だけど、少し調べればできるでしょう」
「どうせ全体を見ているのだから、これもお願いしたい」
こうして、横断性が万能性として消費される。
これは避けなければならない。
まずは、ひとつのコアコンピタンスを持つ
では、横断人材になるにはどうすればよいのか。
最初から全領域を学ぶ必要はないと思う。
まずは、ひとつのコアコンピタンスを持つことだ。
開発でもよい。
テストでもよい。
インフラでもよい。
DBでもよい。
セキュリティでもよい。
業務設計でもよい。
プロジェクトマネジメントでもよい。
PMOでもよい。
何か一つ、自分の軸になる専門性を持つ。
そのうえで、その前後を見る。
開発者であれば、要件定義とテストを見る。
テスト担当者であれば、設計と要件を見る。
インフラ担当者であれば、アプリケーションと運用を見る。
PMOであれば、現場の作業と意思決定者の関心を見る。
自分の専門性が、全体のどこに位置しているのかを理解する。
さらに、その周辺を見る。
技術は業務につながっている。
業務は組織につながっている。
組織は経営につながっている。
経営は投資判断につながっている。
投資判断は予算や稟議につながっている。
稟議はプロジェクトの制約条件につながっている。
こうして、自分の専門性から外側へ少しずつ視野を広げる。
横断人材とは、専門性を捨てた人ではない。
専門性を持たないまま、なんとなく全体を語る人でもない。
専門性を軸に、全体との接続を理解する人である。
単職能の時代が終わる、ということの意味
単職能の時代は終わった。
この言葉は少し強い。
しかし、私はこの言葉を、単職能が不要になるという意味では受け取っていない。
専門性は必要である。
知識体系も必要である。
資格で得られる分類軸にも意味がある。
特定領域を深く学ぶことの価値は、これからも消えない。
ただし、その専門性だけで閉じていられる時代ではなくなる。
自分の専門領域が、前後工程とどうつながっているのか。
設計とテストがどう対応しているのか。
開発と運用がどうつながっているのか。
プロジェクトとプロダクトライフサイクルがどうつながっているのか。
技術と経営、組織、人材、営業がどうつながっているのか。
そこを見ようとする姿勢が必要になる。
IPA試験区分の見直しから読み取れるのは、そういう変化なのかもしれない。
振り返れば、今までも本当はそうだった。
V字モデルの時代から、設計だけ、テストだけ、実装だけを見ていればよかったわけではない。
プロジェクトマネジメントの時代から、計画だけ、進捗だけ、課題管理だけを見ていればよかったわけでもない。
いつの時代も、できる人は横断的に見ていた。
それがこれからは、より明示的に求められるようになるのだと思う。
単職能の知識は、十分条件から必要条件へ変わっていく。
そして、横断人材であることは、万能人材になることではない。
まずは、自分のコアコンピタンスを持つ。
その前後を理解する。
周辺領域との接続を理解する。
自分の仕事が、全体のどこに位置しているのかを理解する。
そこから、横断人材への一歩が始まる。
専門性を捨てる必要はない。
むしろ、専門性があるから横断できる。
必要なのは、ひとつの専門性に閉じこもることではなく、その専門性を足場にして、少し外側を見ることなのだと思う。
前回の記事：
併せて読んでほしい関連記事：
