開発系エンジニアのスキルロードマップ 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

MSDN の Windows Azure 実装ガイド、リニューアルしました!

というわけで本当にまた久しぶりなエントリなわけですが;、なぜこれほどまでに忙しいのかはまた今度改めて書くことにしまして、まずはひとつご報告を。社内関連部署の多大なる協力によって、昨年公開した Windows Azure 実装ガイドを、最新情報にリニューアルして公開することができました!(嬉) Visual Studio Workshop #451 Windows Azure 上での Web アプリケーション開発基礎 こちらのリンクから辿ってダウンロードしてください。  なんとページ数は前回から大幅増量の 600 ページ!(前回が 324 ページなので実に倍増……多すぎます;orz) マイクロソフトのコンサルタント陣が、実際の Windows Azure 案件でお客様から受けたツッコミ内容や、失敗なども含めて得られたノウハウ情報をかたっぱしから盛り込んで加筆修正したものになります。 以前のバージョンでも十二分に世界レベルで戦えたと思うのですが、今回のバージョンは他国のコンテンツの追随を許さない内容になっています^^。しかも内容も最新情報ベースでまとめていますので、VM Role や Traffic Manager などについても詳細に説明してます。ぜひ、現場の皆様でご活用ください! なお、こちらのマテリアルの利用にあたっては、以下の点にご注意いただければと思います。(お約束^^) このマテリアルは、あくまで現場の開発者の皆様の、セルフトレーニング(勉強)用にご提供するものです。複製、転載、商用利用はご遠慮下さるよう、お願いいたします。(例:この内容を社内で製本して配布するとか、このマテリアルを使って社内向けトレーニングを実施するとか、設計書や社内資料、お客様向け資料に引用したりコピペするとかしてはいけません。) ◦内容については、私が独自に調査しているものを多分に含んでおります。技術情報に関しては誤りがないように全力で調査をしていますが、万が一、間違いがあった場合には、こちらの blog などで報告をしていきたいと思います。 Azure のアップデートなどによりこちらの情報が古くなる可能性もありますが、現時点ではマテリアルの更新について行う予定はありません。申し訳ありませんが、差分情報については各自で調査をお願いできればと思います。(基本はこれからもそんなに変わらないと思いますが。) 開発秘話(?)については、以前の blog エントリもぜひお読みになっていただければ嬉しいです。 なお、Windows Azure 関連ではもうひとつ、そのうちご報告できる内容があるかも? なので、またそのときにでも blog エントリを書こうと思います。なにはともあれ、600 ページという膨大な量のコンテンツで恐縮ですが、パラパラとめくって Windows Azure の世界をお楽しみください!^^

0

SQL Azure データベースの課金について

※ (追加情報 2011/07/25) SQL Azure データベースの課金に関して、米国本社の担当者も交え、最終的な確認を行いました。結論としては、定義上の最大容量(MAXSIZE)ではなく、実際のデータ容量(Current Size)に基づく課金が行われるという、当初通りの情報が正しい、ということになりました。弊社内の一部の担当者が誤解しており、社内で情報が錯綜したのが誤りの原因でした。謹んでお詫びすると共に、修正した情報を以下に掲載します。なお、本件については SQL Azure の課金に関する FAQ として、近日中に Windows Azure のホームページに掲載される予定です。そちらも併せてご確認ください。 [SQL Azure の課金に関する基本的なポイント] SQL Azure の課金は、Web Edition と Business Edition とで分かれている。 例えば、Business Edition を含んだコミットメントプランを購入したサブスクリプションで、Web Edition データベースを利用すると、コミットメントプランに含まれないデータベースを使ったものとみなされ、従量課金されてしまう。 データベースは、実際のデータベースサイズ(Current Size)に基づき、日割りで課金される。 料金表は月あたりの金額で書かれているが、課金は日割りで行われる。(日割り計算の詳細なロジックは後述) master データベース、temp データベースなどは課金対象外。 ユーザデータベースのみが課金対象になる。 データ量は、テーブル内のデータの量だけでなく、インデックスデータの量なども含まれるが、ログデータは含まれない。(簡単に言えば .mdf データファイルの容量であり、.ldf ログファイルの容量は含まれない) [具体例その1] 上記のようにデータが含まれている場合の課金は、以下のようになります。 [課金の日割り計算に関するキーポイント] 従量課金の場合 その日のピークデータ量(Current Size)に基づいて、日割りで課金される。(データベース定義上のMAXSIZEではない) どの月であっても、常に”31”で日割り計算が行われる。(30日以下の月であっても、31で日割り計算が行われる) コミットメントプランの場合 基本的には、従量課金と同じ方式で計算が行われる。 しかし、その月の利用量が購入ユニット数よりも少なかった場合には、購入ユニット数まで繰り上げが行われる。 この繰り上げ計算は「月」単位で行われる。 [具体例その2.] 以下のような場合を考えてみます。(※…

0

東日本巨大地震(東北地方太平洋沖地震)

東北地方太平洋沖地震、時間が経つにつれて目を覆うばかりの甚大な被害が明らかになりつつあります。被災地の皆様には本当にお悔み申し上げると共に、亡くなられた方々のご冥福と、皆様のご無事と安全を本当にお祈りしております。社内でも何か手伝えることはないかという動きが出ておりますが、このエントリでは Azure 関連の各種の動きをまとめて随時お伝えしようと思います。 ミラーサイト構築支援 (New! 2011/03/18) 今回の地震に関連して、一部の Web サイトが高負荷でダウンする、という状況が発生しています。この問題を解決するため、Azure 上にミラーサイトを構築する(技術的には Azure 上にリバースプロキシキャッシュを構築する)支援をマイクロソフト側で始めています。お手を煩わせないようにするため、info311a@microsoft.com (電子メール) までメールで連絡をいただければ、構築そのものをマイクロソフト側で実施します。(← この件は私や MCS のコンサルタントも技術協力・構築協力しています。) 構築作業費用はもちろんかかりませんので、まずはとにかくご連絡を。福島県などの Web サイトがすでにこれを利用しています。概念的には下図のようなキャッシュサーバを構築する支援です。 Windows Azure Platform 無料パス クレジットカードの登録なしに、90 日間分の Azure (S インスタンス× 3、1GB SQL Azure Web Edition × 2)が利用できるというものです。様々なサイト立ち上げにご利用ください。アクティベーション作業も早急に行われているようです。 http://go.microsoft.com/?linkid=9766038 オープンソースソフトウェアの Azure 上へのインストール方法のまとめ 上記で立ち上げたサイトへオープンソースソフトウェア(WordPress, Movable Type, PukiWiki など)をインストールする方法をまとめたサイトです。インストールマニアクスに参加された方々により取りまとめられた情報です。(PHP に関しては、こちらが詳しいです。) http://maniax.jp/installmaniax/4/report/docs Azure Blob ストレージを簡易 Web サイトとして利用する 静的なファイル群から構成される情報提供サイトであれば、以下の方法によりミラーサイトを簡単に Azure 上に立ち上げることができます。CDN…

0