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

(このエントリは Part 2 からの続きです。) さて、Part 2 のエントリでは、開発系エンジニアの 5 つの分類を示しました。この 5 つのロールに関して、昨今のトレンド及び育成ロードマップがどのようなものであるべきか、自身のスキルを高め、市場価値を高めるためにはどうならなければいけないのかについて考えてみたいと思います。 [① 業務 SE (要件定義・業務設計)について] 私がこの IT 業界に飛び込んだ頃は、まだ要件定義や業務設計に関してはあまり情報が整理されていませんでした。しかし、最近は要件定義手法に関する研究が進んできており、書店にも多数の書籍が並ぶようになりました。「要求開発」といった手法や考え方が出てきたり、また特に品質特性(非機能要件)の領域に関する研究の深化などにより、従来に比べてかなり方法論が整ってきた感があります。また、パッケージ製品や SaaS が適用できる領域も増えつつあり、メールなどの IT インフラ領域だけでなく、販売管理や顧客管理などの領域でも、パッケージ製品や SaaS 利用ができるようになってきています。こうした中で、「業務」のことだけを見て、技術のことを知らずに業務設計を行うと、「実現不可能な」システムになってしまったり、「コストがかかりすぎる」システムになってしまう危険性もあります。 こうしたことを踏まえると、業務 SE のスキルロードマップとしては以下のようなものが考えられます。すなわち、まず入社直後は一般的なモデリング技術や業務分析手法を習得して基本的なスキルを身に着け、その後、技術スキルをベースとして、業界・業種知識を伸ばしていきます。最後には、業界・業種に関する深い造詣を元に業務コンサルティング領域へと踏み出していき、業務の To-Be モデルの策定や、実現可能な業務システムの提案・設計ができるようになっていくことが一つのゴールとなってくるでしょう。 [② アーキテクト(方式設計)について] 前述したように、アーキテクトはシステムの実現方式やアプリケーションの作り方を決定し、それを開発チームで実践する役割を担っています。このため、アーキテクトロールは開発チームの中で非常に重要な役割を担っていますが、アーキテクトを取り巻く環境は厳しくなる一方です。特に厳しいのは、昨今の開発技術の複雑化です。UI の多様化(Web, RIA, スマクラ, モバイル)、クラウドコンピューティングなど、システムのプラットフォームが一気に複雑化してきており、こうした多種多彩な技術に深い造詣を持つエンジニアの希少性が一段と高くなってきています。このため、どこの会社もアーキテクト不足に悩んでいる、というのが実情でしょう。 また、アーキテクトの重要性が頻繁に語られる割には、「アーキテクチャ」の詳細に関する業界標準がないのも大きな課題です。例えば、何を以て「アーキテクチャ」とするのか? また標準化としては何をすべきか? に関しては、業界内で統一的な見解がなく、例えば SIer 各社がノウハウを持っていたとしても、社外に対して公開されたり share されたりすることがなく、ノウハウを外部から入手することが困難、という難しさもあります。また、方式設計(アーキテクチャ設計)は「机上の空論」ではなく「実践可能」でなければなりませんので、高度なテクニカルスキルも求められます。簡単に言えば、多種多彩な開発技術に対して深い造詣を持つと共に、そこからアーキテクチャに関して自分なりの見解を組み立てるスキルが求められるのが、アーキテクトというロールだと言えます。 ただし、最終的なゴールは前述したように、自分でアーキテクチャを考えるだけではなく、それを流布させ定着させていくことです。ここまで含めて考えると、アーキテクトとして目指すべき最終的なゴールは、教育的視点まで含んだ開発標準化の実践、というところになっていくでしょう。 [③ デベロッパー(内部設計・実装)について] Part 1 にて解説したように、昨今のアプリケーション開発の特徴は、内部設計と実装の距離が大きく縮まっていることです。すなわち、実装の手間が軽減されることで、内部設計がダイレクトに実装に直結するスタイルに近づいてきており、内部設計者がそのまま実装することが可能になってきています。このことは、裏を返せば、内部設計スキルのないエンジニアがツールやフレームワークを誤用すると、品質に大きな難のあるアプリケーションが出来やすいということでもあります。このため、デベロッパーの人たちは、コーディングのスキルだけでなく、内部設計のスキルを高めていくことが非常に重要になっていると言えます。 ところが現場の実情を見ると、特に若手デベロッパーに、基礎スキルの不足の傾向がみられます。これは、ウィザードやツールを多用した開発の練習ばかりしているためで、内部の動きや作業の意味を理解しないまま、技術の勉強を進めているためでしょう。ひどいケースになると、変数定義やインスタンス生成などの基本的な意味がわかっていないことすらありましたが;、こうしたことを避けるためには、単に表面的なツールの使い方やコーディング方法を勉強するのではなく、裏側の動きまで含めた、一歩踏み込んだ学習をしていかなければなりません。そうしたことを怠ると、その場しのぎの作業がどんどん増えていき、最後にはインターネットからコードをコピペしまくる「Copy & Paste」デベロッパーになってしまいます。でも、こうしたデベロッパーは確実に淘汰されます。オフショアなどとの価格競争に巻き込まれないようにするには、デベロッパーとしての生産性や付加価値をどのように守っていくのか、どのようにそれらを向上させていくのかを、真剣に考える必要があります。なぜなら、今でもフレームワークや共通部品群、アプリケーションの中核部分は開発が難しく、スキルの高いデベロッパーにしか作れないからです。基本的には、デベロッパーが自身の市場価値を維持・向上する方法は以下の 2 つのいずれかだと思います。 ツールを最大限に生かし、開発生産性を大幅に高めること…

0

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

(このエントリは Part 1 からの続きです。) [システム開発プロセスの基本とエンジニアの分類] 業務システムの開発には様々な人が関与しますが、どのような規模のシステム開発であったとしても、少なくとも以下のような役割(ロール)のメンバーが必要になります。そして、それぞれのロールには、他のロールとは異なる専門性が求められます。この 5 つのロールを理解することは、開発系エンジニアが自らの専門性を深めていく上で極めて重要な指針となるものですので、これらについて解説します。 ① 業務 SE 業務 SE とは、お客様から業務要件をヒヤリングし、その情報を元に、実装可能な業務仕様を取りまとめていくエンジニアです。上流寄りの業務 SE はどちらかというと業務コンサルに近く、下流寄りの業務 SE はどちらかというと開発者に近いロールになりますが、いずれにしても、お客様の業務内容を理解し、それを仕様や設計に落とし込んでいくというのがポイントになります。このため、業務 SE の人たちには、業務に関する専門知識(ドメインエキスパート)や、モデリングに関する専門知識(データモデリングなど)が要求されます。 ② アーキテクト(アプリケーションアーキテクト) アーキテクトとは、アプリケーションやシステムインフラに関する方式設計(アーキテクチャ設計)を行うエンジニアです。簡単に言うと、どのような方式(アーキテクチャ)でその業務システムを実現するのかを決定する役割になります。このため、この作業を行うためには、業務に関する知識と理解、そして開発技術に関する、幅広く深い知識と理解が必要になります。また、(後述しますが)業務 SE とデベロッパーの橋渡しをすることも、重要なロールの一つになります。 ③ デベロッパー デベロッパーとは、業務 SE のまとめた業務仕様に基づいて、内部設計と実装作業を行うと共に、テストチームに引き渡し可能な品質のアプリケーションを作り上げる人たちです。ひと昔前であれば、「プログラマー」と呼ばれていた人たちに相当します。ただし、現在のプログラム開発は、前回のエントリに書いた通り、いわゆるブルーカラー的なコピペ作業ではなくなっています。つまり、業務 SE から渡された業務仕様書を元に、プログラムの内部設計を書き起こし、それをコードとして組み立てられるスキルが求められているわけです。このような、内部設計作業からプログラミング(実装作業)、そしてプログラムコードから実際のバイナリファイル(成果物)を作り上げていく人たちを、デベロッパーと呼びます。ですので、デベロッパーの人たちには、プログラミングに関する深い専門知識が求められるだけではなく、業務仕様を理解し、プログラム内部設計を書き起こせるスキルも求められています。 ④ テスター テスターとは、デベロッパーの人たちが作ったアプリケーションを体系的・網羅的にテスト・評価する方法を考え、バグの発見と、アプリケーション品質の定量化を行っていく人たちになります。「テスター」というと、テスト計画やテストケースに基づいて、実際にアプリケーションの操作を行う人、というイメージがありますが、実際にテストを行う場合には、優れたテスト計画やテストケースを作成することの方が圧倒的に重要であり、この部分には極めて高いスキルが要求されます。こうした、優れたテスト計画の立案やテストケースの設計を行い、得られたテスト結果から各種の品質指標数値データを算出していく役割を担うのがテスターです。(このため、テスターは QA (Quality Assurance、品質保証)担当と呼ばれることもあります) ですので、テスターの人たちには、業務仕様や各種テストツールに関する深い知識はもちろんのこと、各種の統計解析・統計分析スキルを持っていることが要求されます。 ⑤ プロジェクトマネージャー プロジェクトマネージャーとは、前述したような各種のロールのメンバーが最大限の能力を発揮できるように各種の調整を行うと共に、プロジェクトの全体進行の進捗管理などを行う人になります。(小規模開発でロールを兼任せざるを得ない場合でなければ)プロジェクトマネージャー自身はシステム開発作業を直接行うことはなく、チームメンバーやステークホルダーとのコミュニケーションに力を注ぐことになります。このため、求められる専門知識やスキルも、技術知識というよりは、コミュニケーション能力、リーダーシップ、交渉力、問題解決力など多岐に渡ることになります。開発系エンジニアという枠組みで捉えるべきか否かは難しいところですが、開発系エンジニアとしてのスキルや知識がないと、システム開発のプロジェクトをうまく回すことは難しいのもまた事実なため、ここで取り上げておくことにしました。 なお、この 5 種類のロールに関して誤解されやすいポイントが 2 つありますので、少し補足説明を加えておきます。 アーキテクトとデベロッパーは別物 デベロッパーとテスターは別物 アーキテクトとデベロッパーの違い システム開発において、チーム内にアーキテクト(アプリケーションアーキテクト)を置くのは、アプリケーションの作り方を一定化させて品質を安定させるためです。これについて説明します。 一般に、アプリケーションは、業務 SE が行った業務設計に基づいて、デベロッパーが作成していく、という流れになります。この際、統一的な設計思想のないまま業務要件定義書に基づいて実装が行われると、場所ごとに作り方がまちまちになってしまって保守できなくなったり、性能の出ないアプリケーションができてしまったり、セキュリティの確保の方法が一貫していないアプリケーションになってしまう危険性が高くなります。これを防ぐために、チーム内にアーキテクトを配し、アーキテクトの人が方式設計、すなわちアプリケーションの実現方式に関するプランを固め、これを徹底します。このようにすることで、複数人のデベロッパーが関わっても、同じようなアプリケーションが出来上がり、各種品質が担保されるようになります。 「アーキテクト」と聞くと、非常に華々しくカッコいい職種を思い描かれる方も多いかと思いますが、そうした方は、アーキテクトという職種を誤解しています。アーキテクトを設置する『目的』は、たくさんいるデベロッパーの方々に、一貫した設計思想に従った、品質の高いアプリケーションコードを書いてもらうことです。そのためにアーキテクトは、日常的にはかなり地味くさい…

0

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

ここ最近、組織改変などの影響もあって忙しい日々が続いている今日この頃。なかなか  blog エントリ書きも滞ってしまっていて申し訳ないのですが;、最近はコンサルの現場を離れて、少しバックエンド系のお仕事をしていたりします。といっても、プロジェクトの技術レビューや提案活動は以前と変わらず実施しているのですが、そんな中、営業支援でお手伝いをしていた案件のひとつが、全社開発標準の整備・強化プロジェクト。簡単に言えば、SIer のコアコンピテンスのひとつともいえる全社開発標準を整備・強化していくことで、より強い SIer を目指していきたい、という話です。 全社開発標準の整備・強化プロジェクト、確かに SIer の強化のために開発標準のような「モノ」が重要な役割を占めるのは間違いないのですが、けれどもそれだけではダメで、それを作り、回していく「ヒト」の強化、つまり人材育成にもかなりの力を注がないと、なかなかうまくいかないものです。こうした組織強化の中でも特に人材育成の話は、私自身がずっとこだわって携わってきた領域でもあったりします。おそらく現場の開発系エンジニアにとって、ひとつ参考になる考え方になるのではとも思いますので、今回、blog エントリとして取り上げてみることにしたいと思います。 ※ なお、このエントリの内容は、ITSS などの標準的なスキルマップを使ったものでもなければ、マイクロソフトとしての標準的なスキルロードマップというものでもありません。私自身が現場の『肌感覚』として、開発系エンジニアがどうやってスキルアップし、生き残っていくべきなのか? というものを考えてきた結果としての、一つの考え方にすぎません。その点についてはあらかじめご了承ください。 [Agenda] システム開発の在り方の変質と、開発系エンジニアへの要求の変質 SIer にとってのテクニカルスキルの重要性 開発系エンジニアのスキルアップの難しさ 座学(トレーニング)と OJT のバランス システム開発プロセスの基本とエンジニアの分類 システム開発のフェーズとエンジニアの対応関係 スキルタイプごとのトレンドと育成ポイント キャリアパスとしての技術コンサルタント [システム開発の在り方の変質と、開発系エンジニアへの要求の変質] 昨今の開発系エンジニアは、開発現場で過酷な労働を強いられていることが多いと思います。一昔前は花形産業としてもてはやされていた IT 産業は、今や 21 世紀の新しい “3K” (キツい、帰れない、給料が安い)と揶揄されるような状況。中でも SI (システム開発)の仕事の厳しさは、私が改めてここで書くまでもないことと思います。なぜこんなひどいことになってしまったのか? それを総合的に語ることは簡単ではありませんが、私自身が開発現場にコンサルタントとして携わっていて強く感じることのひとつに、「開発技術の理解や習得(テクニカルスキル)が相対的に軽んじられてしまっている」ことがあります。実際、「スキル不足」「スキルの低さ」が開発のトラブルや失敗を招いているケースは後を絶たず、現場のトラブルを見てみると、そもそもどうしてこんなことをしたのか?と言いたくなることもしばしば。今の時代ほど、テクニカルスキルが重要な時代はないとすら私は思うのですが、なぜテクニカルスキルが重要なのか、どうしてそうなったのかについては、あまり理解されていないように思います。 テクニカルスキルが従来以上に重要になったのは、現在のシステム開発が、数十年前に見られたような労働集約型のビジネスとは言いづらくなってきたことに起因しています。システム開発における SIer のゴールは、システムを「早く・安く・上手く」作ることであり、それを実現するために、以下のような考え方とアプローチをとっていました。 開発標準化を行い、プロセスと開発方法を標準化し、「誰でも彼でも作れる」ようにする。 これにより、スキルの低いエンジニアや単価の安いエンジニアでも、品質の高いアプリケーションを作れるようにする。 端的に言えば、「エンジニアのスキルの低さ」を「開発標準化」でカバーする、という方法だったと言えますが、この考え方は、残念ながら現在ではなかなか通用しなくなっています。 従来の考え方が通用しなくなった最大の理由、それは昨今の開発ツールやフレームワークなどの技術進化です。例えば今から約 10 年前、VB6 の時代に、データベースからデータを取得しようと思った場合には、以下のようなコードを記述する必要がありました。(※ コードを理解する必要はありません、なんとなく見てください) Dim con As ADODB.Connection Dim cmd As…

0