開発系エンジニアのスキルロードマップ Part 1


ここ最近、組織改変などの影響もあって忙しい日々が続いている今日この頃。なかなか  blog エントリ書きも滞ってしまっていて申し訳ないのですが;、最近はコンサルの現場を離れて、少しバックエンド系のお仕事をしていたりします。といっても、プロジェクトの技術レビューや提案活動は以前と変わらず実施しているのですが、そんな中、営業支援でお手伝いをしていた案件のひとつが、全社開発標準の整備・強化プロジェクト。簡単に言えば、SIer のコアコンピテンスのひとつともいえる全社開発標準を整備・強化していくことで、より強い SIer を目指していきたい、という話です。

全社開発標準の整備・強化プロジェクト、確かに SIer の強化のために開発標準のような「モノ」が重要な役割を占めるのは間違いないのですが、けれどもそれだけではダメで、それを作り、回していく「ヒト」の強化、つまり人材育成にもかなりの力を注がないと、なかなかうまくいかないものです。こうした組織強化の中でも特に人材育成の話は、私自身がずっとこだわって携わってきた領域でもあったりします。おそらく現場の開発系エンジニアにとって、ひとつ参考になる考え方になるのではとも思いますので、今回、blog エントリとして取り上げてみることにしたいと思います。

※ なお、このエントリの内容は、ITSS などの標準的なスキルマップを使ったものでもなければ、マイクロソフトとしての標準的なスキルロードマップというものでもありません。私自身が現場の『肌感覚』として、開発系エンジニアがどうやってスキルアップし、生き残っていくべきなのか? というものを考えてきた結果としての、一つの考え方にすぎません。その点についてはあらかじめご了承ください。

[Agenda]

  • システム開発の在り方の変質と、開発系エンジニアへの要求の変質
  • SIer にとってのテクニカルスキルの重要性
  • 開発系エンジニアのスキルアップの難しさ
  • 座学(トレーニング)と OJT のバランス
  • システム開発プロセスの基本とエンジニアの分類
  • システム開発のフェーズとエンジニアの対応関係
  • スキルタイプごとのトレンドと育成ポイント
  • キャリアパスとしての技術コンサルタント

[システム開発の在り方の変質と、開発系エンジニアへの要求の変質]

昨今の開発系エンジニアは、開発現場で過酷な労働を強いられていることが多いと思います。一昔前は花形産業としてもてはやされていた IT 産業は、今や 21 世紀の新しい “3K” (キツい、帰れない、給料が安い)と揶揄されるような状況。中でも SI (システム開発)の仕事の厳しさは、私が改めてここで書くまでもないことと思います。なぜこんなひどいことになってしまったのか? それを総合的に語ることは簡単ではありませんが、私自身が開発現場にコンサルタントとして携わっていて強く感じることのひとつに、「開発技術の理解や習得(テクニカルスキル)が相対的に軽んじられてしまっている」ことがあります。実際、「スキル不足」「スキルの低さ」が開発のトラブルや失敗を招いているケースは後を絶たず、現場のトラブルを見てみると、そもそもどうしてこんなことをしたのか?と言いたくなることもしばしば。今の時代ほど、テクニカルスキルが重要な時代はないとすら私は思うのですが、なぜテクニカルスキルが重要なのか、どうしてそうなったのかについては、あまり理解されていないように思います。

テクニカルスキルが従来以上に重要になったのは、現在のシステム開発が、数十年前に見られたような労働集約型のビジネスとは言いづらくなってきたことに起因しています。システム開発における SIer のゴールは、システムを「早く・安く・上手く」作ることであり、それを実現するために、以下のような考え方とアプローチをとっていました。

  • 開発標準化を行い、プロセスと開発方法を標準化し、「誰でも彼でも作れる」ようにする。
  • これにより、スキルの低いエンジニアや単価の安いエンジニアでも、品質の高いアプリケーションを作れるようにする。

端的に言えば、「エンジニアのスキルの低さ」を「開発標準化」でカバーする、という方法だったと言えますが、この考え方は、残念ながら現在ではなかなか通用しなくなっています。

image

従来の考え方が通用しなくなった最大の理由、それは昨今の開発ツールやフレームワークなどの技術進化です。例えば今から約 10 年前、VB6 の時代に、データベースからデータを取得しようと思った場合には、以下のようなコードを記述する必要がありました。(※ コードを理解する必要はありません、なんとなく見てください)

Dim con As ADODB.Connection
Dim cmd As ADODB.Command
Dim rs As ADODB.Recordset 
 
Set con = CreateObject("ADODB.Connection")
Set cmd = CreateObject("ADODB.Command")
Set rs = CreateObject("ADODB.Recordset")
 
' データベース接続を開きます。
con.Open "Provider=SQLOLEDB;Data Source=sqlsrv00;Initial Catalog=pubs;Trusted_Connection=yes" 
 
' Commandオブジェクトで利用するコネクションを指定します。
Set cmd.ActiveConnection = con
' コマンドタイプをSQL文実行として指定し、SQL文をセットします。
cmd.CommandType = adCmdText
cmd.CommandText = "SELECT * FROM authors"
' 読み出し専用の切断レコードセットのためのオプションを指定します。
rs.CursorLocation = adUseClient
rs.CursorType = adOpenStatic
rs.LockType = adBatchOptimistic 
 
' レコードセットを取得します。
rs.Open cmd
 
' 切断レコードセットにするため、コネクションを切断します。
' また同時に、不要となったオブジェクトを破棄していきます。
Set cmd.ActiveConnection = Nothing
Set cmd = Nothing
Set rs.ActiveConnection = Nothing
 
' データベース接続を切断し、解放します。
con.Close
Set con = Nothing
 

ところが、今の時代、例えば ADO.NET や LINQ to Entity Framework を使うと、上記の処理は数行で書けてしまいます。

using (pubsEntities pubs = new pubsEntities())
{
    var query = from a in pubs.authors select a;
    List<author> result = query.ToList();
}

ひと昔前であれば、数 10 行~数 100 行のコードを書かなければいけなかった作業が、今や本質的な作業を表す数行のコードを記述するだけで済むようになった、ということなわけですが、この変化は、以下の 2 つを意味します。

  • ブルーカラー的な単純労働作業がなくなった、端的に言えばコピペ作業はなくなった、ということ。
  • 設計と実装の距離が非常に短くなった、端的に言えば設計者がその内容を直接コードとして表現できるようになった、ということ。

つまり、現在の開発技術のトレンドは、手を動かすだけの労働集約的な作業は少なくなり、ホワイトカラー的な設計者が直接かつ素早くモノ作りをしていくことができる方向に進化している、ということを意味します。結果として、現在の技術トレンドは、シニアな開発メンバによる、少数精鋭の SWAT チーム的な開発に適したものに進化してきている、ということになります。

image

これは .NET、Java を問わず、昨今の開発技術全般について言えることですが、現在の開発技術(言語やツール)の怖いところは、ジュニアなコピペエンジニアの仕事をなくしてしまう、ということです。実際、現在の .NET Framework や Visual Studio は極めて高い生産性ツールであるものの、誰もがその高生産性を十分に引き出せるというわけではありません。設計スキルやアーキテクト的な素養があればあるほど、その高開発生産性をうまく引き出すことができる、という類のツールです。その結果、スキルの高い人はますます稼ぎ、スキルの低い人は簡単に淘汰され価格競争に巻き込まれる、という構図ができあがります。こうしたことからも、特にデベロッパーにとってスキルが極めて重要であることがわかるかと思います。

image

[SIer にとってのテクニカルスキルの重要性]

このテクニカルスキルの重要性は、直接、内部設計や実装などの開発作業に携わらない SIer にも当てはまります。なぜ SIer においてもテクニカルスキルが重要なのかは、以下のようなことを考えてみればすぐにわかります。

SI では、たくさんの人がプロジェクトに関与します。こうした中で、開発にかかる総コストを低減し、自社の付加価値を高めていくために SIer が行ったことは、実装作業やテスト作業といった、比較的ブルーカラー色の強い業務を、協力会社やオフショアに移転していくことでした。すなわち、自社のプロパー要員を、極力、リーダーやプロジェクト管理業務に注力させ、自社のコアコンピテンスを、単価の高い高付加価値業務にシフトしていくことで、企業価値を高めていこうと考えたわけです。

image

この考え方自体はごく普通の話ですし、市場原理に基づけば、ごく当たり前の流れともいえます。しかし問題なのは、コアコンピテンスにリソースを集中させすぎると、かえってコアコンピテンスを失う結果につながってしまう、というポイントです。例えば、F1 レーサーを考えてみてください。F1 レーサーのメインの仕事は F1 カーを走らせることであり、その部分がお金を生み出しています。ですが、だからといってそればかりに注力して、日々の筋トレを怠ってしまったらどうなるでしょうか? しばらくの間は高付加価値業務を維持できるかもしれませんが、その後は筋力を失い、結果として F1 カーをドライブできなくなり、仕事を失うことにつながっていきます。筋トレで稼いでいるわけではありませんが、だからといって筋トレをやめたら F1 カーを走らせられなくなる、という側面があるわけです。

この例からも明らかなように、コアコンピテンスというのは、それが単体で存在しているわけではありません。実際には、コアコンピテンスを支えているベースラインスキルというものが存在します。ベースラインスキルというものは、それ単体では価値を生み出すものではなく、またそれ自体を専門にする必要性のあるものではありませんが、それを失ってしまうとコアコンピテンスを維持できなくなる、という類のものです。コアコンピテンスを考える場合には、それがベースラインスキルとは不可分であることを意識することが重要であり、日々、ベースラインスキルを維持すること(簡単に言えば基礎トレ)も同時に考えなければなりません。

imageimage

SIer の場合、プロジェクト管理やチームリードを専門として行うことで付加価値を守っており、自ら実装や内部設計を行うわけではありません。これは今後も同じでしょう。ですが、だからといって技術のことを知らなくてもよいということではないはずです。自ら開発をしなくても、技術の肝を理解していなければ、協力会社やオフショアに依頼したものをレビューすることすらできなくなってしまいます。「自分ができないから外注する」のか、「自分でもできるけれどもコストが安いから外注する」のか、どちらであるのかは天と地ほどの違いがあります。SIer のコアコンピテンスを守るためには、やはりテクニカルスキルがベースラインスキルとして求められるのだと思います。

そういう意味において、SIer の場合、協力会社やオフショアなどの外注に依存しきらないようにすることが大切です。例えば、小規模案件であれば自社のみで開発したり、大規模案件であっても若手のプロパーメンバーを実作業員として参画させて現場経験を積ませたりすることで、実作業の『勘所』を見失わないようにすることが重要です。そうすることで、本当の意味での自分たちのコアコンピテンスを守っていかないと、企業価値が損なわれていってしまいます。

image

プログラマーではなく SE、SE ではなく PM、PM ではなくコンサル……といった具合に、名前を付け替えていったとしても、中身が伴わなければいつかは破綻します。我々エンジニアが自分たちの市場価値を守っていくためには、足腰をきちんと鍛え、地に足の着いた、本当の意味での実力を身に着け、発揮していかなければなりません。そのベースラインとして、テクニカルスキルが極めて重要であることを、今一度改めて認識することが大切なのだと思います。私自身、コンサルタントをしているときは、(別にコーディングを業務として行うわけではないのですが)折に触れてコーディングの訓練をしていましたし、マネージャ業務をやっている現在でも、折に触れて最先端技術を学習するようにしています。勘所がわからなければ、コンサルティング業務もマネージャ業務もきちんとできないからです。

[開発系エンジニアのスキルアップの難しさ]

……などと、とりあえず理屈をこねてみたわけですが、現場にいる開発系エンジニアの実感としては、「理屈は分かるけど実際にはムリでしょ;;;」というのが偽らざる本音だと思います。実際、開発現場のエンジニアのスキルアップや育成を拒む要因はたくさんあります。代表的なものという意味だと、以下のようなものでしょうか。

  • 技術要素が多すぎて、とても追いつけない。
  • 勉強しようにも、どこからどうやって勉強していけばよいのか、ロードマップがない。
  • そもそも物理的に時間が取れない。

image

こうした厳しい状況の中で、羅針盤もなしに「勉強しろ」と命じたところで回るわけがないですし、意欲的なエンジニアもどうやって勉強すればよいのか途方に暮れてしまうと思います。自分で勉強するにせよ、会社として育成するにせよ、しっかりと基本に立ち返った考え方をする必要があります。そのための要点は、以下の 2 つです。

  • 座学(トレーニング)と OJT のバランスを取ること
  • 「開発系エンジニア」を適切にタイプ分類し、それぞれに適した学習ロードマップを持つこと

それぞれについて、説明していきたいと思います。

[座学(トレーニング)と OJT のバランス]

スキル強化を考える際、昨今は OJT (現場で業務をしながら仕事を覚える)が非常に重視されるようになりました。なぜなら、IT 業界では座学では学べないノウハウがたくさんあり、それは現場の実務経験からしか学ぶことができないからだ、だから新入社員のトレーニングは最小限で済ませて早く現場に送り出すのだ……などと言われていますが、私自身の肌感覚からすると、それはトレーニング予算を削減するための、体(てい)の良い言い訳ではないか? と正直思います。というのも、現場の OJT 経験だけでは、確たる実力が身につかない、あるいは身についたとしてもとてつもなく効率が悪くて時間がかかりすぎるからです。

小学生や中学生の頃の勉強を思い返して欲しいのですが、勉強するときに、教科書もろくに読まずにいきなり問題集に取り掛かる方法は、どう考えても学習効率が悪いです。仮にその方法で問題集を丸暗記して直近の期末試験を何とか乗り越えたとしても、ほとんど定着しませんし、ちょっと角度を変えた応用問題を出されたとたんに解けなくなるものです。言うまでもなく、「理論」と「実践」の両方が伴って、初めて応用力のある実力、すなわち現場での実力となるものですが、昨今のシステム開発の現場では、こうした基礎トレーニングが思ったようにできていないのが実際ではないでしょうか?

特にここ最近は、教育に対する投資を後ろ向きに考えがちな風潮があるようにも思います。トレーニングを受講してもらって人を育成しても、すぐに辞めてしまうのではないか? そもそも多忙を極める現場からトレーニングに人を出したら現在のプロジェクトが回らなくなるのではないか? などなど、心配事項は尽きません。確かに、座学で理論ばっかり勉強していても頭でっかちになるばかりですが、かといって OJT だけでは基礎学力は身に付きませんし、基礎学力が身についていないと、場当たり的・その場しのぎのパッチ的な解決策に走りやすくなります。例えば、インターネットから検索したソースコードを、意味も理解せずにそのままコピペしたようなアプリケーションコードを現場で見かけたりしませんか? そうしたアプリケーションコードは、潜在バグも多いものです。こうしたことを防ぐためには、まずトレーニングや座学で幹を作り、そこに OJT で枝葉を補い、応用力をつけていくことが大切です。枝葉だけかき集めても、しっかりとした幹を持った大木にはなりません

image

私自身の肌感覚としては、座学(業務時間外での学習や書籍などでの自習も含む)と OJT とのバランスは、だいたい 1 : 4~5 ぐらいではないかと思います。座学ばっかりやっている必要はないけれども、最低でも時間ベースで 10~15% ぐらいは基礎トレをしていないと、現場で力を発揮できないという印象を持っています。私自身、コンサルタントをやる上では、意識的にこうした学習時間を取るようにしていました。

ただし、座学での学習は、やみくもに時間をかければよいというものではありません。きちんとした学習・成長ロードマップを持ち、「どこを目指すのか?」(=自分の専門性)を意識した学習が必要になります。この部分に関しては、日本の考え方は少し遅れているように感じていますので、少し深掘りしてみたいと思います。

[開発系エンジニアのタイプ分類]

開発系エンジニアがスキルアップを考える際に重要なのは、自分の専門性をどのように捉えるのか?という点です。日本の場合、開発系エンジニアに関しては比較的考え方が古く、今でもゼネラリスト的な考え方を取ることが多いです。もう少し説明すると、下図にあるように、

  • まず新入社員は、情報工学の基礎や、ネットワーク、DB、プログラミングなどの基礎を学習する。
  • 次に、システム開発プロセスや運用管理、セキュリティなどを学習する。
  • それが終わったら、業界業種知識などを伸ばす。
  • さらにプロマネスキルやコンサルティングスキルを伸ばしていく。

のように、ひとつのロードマップで成長していくようなモデルを取っていることが多いと思います。実際、日本の場合、プロジェクトマネージャ、SE、プログラマー、テスターの間には明確な職位的上下関係があり、まるで昔の士農工商制のように扱われていることも多いと思います。新人はまずテスターを経験し、頭角を現した場合にはプログラマーを経験させ、そこでさらに頭角を現した人には SE になってもらい……といった具合です。

しかし、米国などでは、より専門性の強い職種への細分化が進んでいます。新卒エンジニアはまず基礎学力をつける、というところは変わりがないでしょうが、ある程度の経験を積んだあとは、業務 SE やアーキテクト、デベロッパー、テスター、プロジェクトマネージャーなどに職種が分かれ、それぞれの職種の専門スキルを深めていくことになります。

image

もちろん米国などにおいても、小規模な組織や開発においては、一人が複数の職種を兼任することは当然あるでしょう。しかし、少なくともそれぞれの職種には専門性がある、と考えているところが重要なポイントです。簡単に言えば、上級のテスターには上級のテスターとしてのスキルやノウハウや専門知識というものが存在するし、上級のアーキテクトには上級のアーキテクトとしてのスキルやノウハウや専門知識が存在する、ということが認知されているというところがポイントです。このため、特に高度な専門性を要求する会社の場合、中途採用の枠などは、最初から個別に分かれています。例えばこちらはマイクロソフトの採用ページですが、募集されている職種を見てみると、ソフトウェアエンジニアリングにおいて、製品計画、開発、製品テストなどが最初から分かれていることが確認できると思います。

image

開発系エンジニアの職種(=専門性・専門分野)をどのように細分化するのか? に関しては、様々な方法があります。例えば、Visual Studio にも組み込まれている MSF (Microsoft Solution Framework)と呼ばれる方法論でよく使われるロール(職種)としては、① プロダクト管理、② プログラム管理、③ アーキテクチャ、④ 開発、⑤ テスト、⑥ リリース管理、⑦ ユーザーエクスペリエンス、があります。が、開発対象となるシステム規模によってもこの細分化の程度は変わってくるため、私自身はこれをもう少し簡素化した以下の 5 つのロールを、基本的な開発系エンジニアの専門分野と捉えるとよいと思っています。これぐらいの方が覚えやすいし、使いやすいでしょう。

  • 業務 SE(要件定義や業務設計を担当)
  • アーキテクト(方式設計などの設計・実装標準化を担当)
  • デベロッパー(内部設計や実装を担当)
  • テスター(テストと品質評価を担当)
  • プロジェクトマネージャ(プロジェクト管理を担当)

なぜ開発系エンジニアがこのような 5 つの専門職種に分類されるのかは、システム開発のプロセスを理解すれば自ずと理解できます。これについて解説します。(次回に続く……;)

Comments (0)

Skip to main content