開発系エンジニアのスキルロードマップ Part 2
（このエントリは Part 1 からの続きです。）
［システム開発プロセスの基本とエンジニアの分類］
業務システムの開発には様々な人が関与しますが、どのような規模のシステム開発であったとしても、少なくとも以下のような役割（ロール）のメンバーが必要になります。そして、それぞれのロールには、他のロールとは異なる専門性が求められます。この 5 つのロールを理解することは、開発系エンジニアが自らの専門性を深めていく上で極めて重要な指針となるものですので、これらについて解説します。
① 業務 SE
業務 SE とは、お客様から業務要件をヒヤリングし、その情報を元に、実装可能な業務仕様を取りまとめていくエンジニアです。上流寄りの業務 SE はどちらかというと業務コンサルに近く、下流寄りの業務 SE はどちらかというと開発者に近いロールになりますが、いずれにしても、お客様の業務内容を理解し、それを仕様や設計に落とし込んでいくというのがポイントになります。このため、業務 SE の人たちには、業務に関する専門知識（ドメインエキスパート）や、モデリングに関する専門知識（データモデリングなど）が要求されます。
② アーキテクト（アプリケーションアーキテクト）
アーキテクトとは、アプリケーションやシステムインフラに関する方式設計（アーキテクチャ設計）を行うエンジニアです。簡単に言うと、どのような方式（アーキテクチャ）でその業務システムを実現するのかを決定する役割になります。このため、この作業を行うためには、業務に関する知識と理解、そして開発技術に関する、幅広く深い知識と理解が必要になります。また、（後述しますが）業務 SE とデベロッパーの橋渡しをすることも、重要なロールの一つになります。
③ デベロッパー
デベロッパーとは、業務 SE のまとめた業務仕様に基づいて、内部設計と実装作業を行うと共に、テストチームに引き渡し可能な品質のアプリケーションを作り上げる人たちです。ひと昔前であれば、「プログラマー」と呼ばれていた人たちに相当します。ただし、現在のプログラム開発は、前回のエントリに書いた通り、いわゆるブルーカラー的なコピペ作業ではなくなっています。つまり、業務 SE から渡された業務仕様書を元に、プログラムの内部設計を書き起こし、それをコードとして組み立てられるスキルが求められているわけです。このような、内部設計作業からプログラミング（実装作業）、そしてプログラムコードから実際のバイナリファイル（成果物）を作り上げていく人たちを、デベロッパーと呼びます。ですので、デベロッパーの人たちには、プログラミングに関する深い専門知識が求められるだけではなく、業務仕様を理解し、プログラム内部設計を書き起こせるスキルも求められています。
④ テスター
テスターとは、デベロッパーの人たちが作ったアプリケーションを体系的・網羅的にテスト・評価する方法を考え、バグの発見と、アプリケーション品質の定量化を行っていく人たちになります。「テスター」というと、テスト計画やテストケースに基づいて、実際にアプリケーションの操作を行う人、というイメージがありますが、実際にテストを行う場合には、優れたテスト計画やテストケースを作成することの方が圧倒的に重要であり、この部分には極めて高いスキルが要求されます。こうした、優れたテスト計画の立案やテストケースの設計を行い、得られたテスト結果から各種の品質指標数値データを算出していく役割を担うのがテスターです。（このため、テスターは QA （Quality Assurance、品質保証）担当と呼ばれることもあります） ですので、テスターの人たちには、業務仕様や各種テストツールに関する深い知識はもちろんのこと、各種の統計解析・統計分析スキルを持っていることが要求されます。
⑤ プロジェクトマネージャー
プロジェクトマネージャーとは、前述したような各種のロールのメンバーが最大限の能力を発揮できるように各種の調整を行うと共に、プロジェクトの全体進行の進捗管理などを行う人になります。（小規模開発でロールを兼任せざるを得ない場合でなければ）プロジェクトマネージャー自身はシステム開発作業を直接行うことはなく、チームメンバーやステークホルダーとのコミュニケーションに力を注ぐことになります。このため、求められる専門知識やスキルも、技術知識というよりは、コミュニケーション能力、リーダーシップ、交渉力、問題解決力など多岐に渡ることになります。開発系エンジニアという枠組みで捉えるべきか否かは難しいところですが、開発系エンジニアとしてのスキルや知識がないと、システム開発のプロジェクトをうまく回すことは難しいのもまた事実なため、ここで取り上げておくことにしました。
なお、この 5 種類のロールに関して誤解されやすいポイントが 2 つありますので、少し補足説明を加えておきます。
- アーキテクトとデベロッパーは別物
- デベロッパーとテスターは別物
アーキテクトとデベロッパーの違い
システム開発において、チーム内にアーキテクト（アプリケーションアーキテクト）を置くのは、アプリケーションの作り方を一定化させて品質を安定させるためです。これについて説明します。
一般に、アプリケーションは、業務 SE が行った業務設計に基づいて、デベロッパーが作成していく、という流れになります。この際、統一的な設計思想のないまま業務要件定義書に基づいて実装が行われると、場所ごとに作り方がまちまちになってしまって保守できなくなったり、性能の出ないアプリケーションができてしまったり、セキュリティの確保の方法が一貫していないアプリケーションになってしまう危険性が高くなります。これを防ぐために、チーム内にアーキテクトを配し、アーキテクトの人が方式設計、すなわちアプリケーションの実現方式に関するプランを固め、これを徹底します。このようにすることで、複数人のデベロッパーが関わっても、同じようなアプリケーションが出来上がり、各種品質が担保されるようになります。
「アーキテクト」と聞くと、非常に華々しくカッコいい職種を思い描かれる方も多いかと思いますが、そうした方は、アーキテクトという職種を誤解しています。アーキテクトを設置する『目的』は、たくさんいるデベロッパーの方々に、一貫した設計思想に従った、品質の高いアプリケーションコードを書いてもらうことです。そのためにアーキテクトは、日常的にはかなり地味くさい ＆ 泥臭い仕事をたくさんします。例えば…
- 業務 SE の人たちに頭を下げて、業務のことを教えてもらう。
- 日々、開発技術を一生懸命勉強して、その要点をきっちり理解する。
- そのシステムをどんなふうに作るのがベストなのかを考え、それをアーキテクチャとしてまとめる。
- 自分が考えたアーキテクチャをデベロッパーの人たちに理解してもらうために、解説書（開発標準書）をまとめる。
- デベロッパーの人たちにその開発標準書を理解してもらうために、頭を下げてまわって一生懸命説明する。
- デベロッパーの人たちが作ったアプリケーションコードをレビューして、定着度を確認したり、修正を依頼したりする。
などです。編成された開発チームのデベロッパーのスキルが高くない場合には、「本当はこうするといいんだけど……」というところを断念して、意識的にアーキテクチャを簡単化するようなこともしばしばあります。この話からも分かるように、難しくてかっちょいいアーキテクチャを書いて、それを開発チームに丸投げして放置し、自分の書いたアーキテクチャが理解できないのはデベロッパーのスキルが低いのが悪いんだ！ などと思ってしまうような人は、アーキテクトには全く向いていません……というよりむしろ害悪です；。日々鍛錬に励み、他人に頭を下げることを厭わず、最終的に出来上がってくるアプリケーションの品質を高めるために何でもやろう！ という気概を持って、プロジェクトの最後まで面倒を見る覚悟のある人だけが、アーキテクトを名乗る資格があるのだと私は思います。
……と、ちょっと話が逸れましたが、アーキテクトのこのような業務内容を意識すると、アーキテクトはプロジェクトメンバ全体に対して 10～15 % 程度必要だろうと思います。もちろん、すべてのアーキテクトがハイスキルである必要はなく、一部のアーキテクトがリードを務め、残りのアーキテクトはサブの位置づけでアーキテクチャの定着に努めるメンバ、といった形にすることも多いと思います。が、いずれにしても開発現場を見てみると、このアーキテクトロールの人員が不足しているケースは多いです。このような場合には、適宜、社内の関連他部署や社外のコンサルティングサービスなどを活用し、アーキテクトロールの不足を補うようにすることをおすすめします。
デベロッパーとテスターの違い
デベロッパーとテスターも、日本では極めて混同されやすい職種ですが、やはりこの二つも、専門性が全く異なります。一言で言えば、デベロッパは「作ることの専門家」、テスターは「品質評価の専門家」 です。これは、実際の作業を意識しないとわかりにくいので、こちらの図を使って説明します。
例えば、マイクロソフトにおいてあるパッケージ製品（例えば Office 2010）を開発する場合を想定してみます。この場合、デベロッパーチームは、単純にコーディングをするだけではなく、それをビルドし、バイナリパッケージ（簡単に言えば半完成品）を作成します。テストチームはこの半完成品を受け取り、品質検査（テスト）を行い、品質評価を行います。品質に問題がある場合（すなわちバグがたくさん見つかってしまった場合）には、バグ報告票を起票してバグの修正を依頼し、デベロッパーチームに修正を要求する、という形になります。そして再度、デベロッパーチームから完成品を渡してもらい、これを再度、品質評価する、という流れを繰り返します。
この一連の流れにおいて重要なのは、テストチームのメンバーは、ソースコードを見たり触ったりせず、またバグの原因追究も行わない、という点です。あくまで完成品をエンドユーザと同様に触ったり使ってみたりして、問題がないかどうか、品質を検査します。そして問題があった場合には、その問題を的確に報告する（＝バグの再現手順をデベロッパーチームに報告する）ことを行いますが、そのバグの原因追及や修正作業はテストチームは一切行いません。バグの原因を追究し、それを修正するのはデベロッパーの責任だからです。というか、バグの修正方法などに中途半端にテスターが首を突っ込むと、「アプリの作りもよく知らないのに、適当な修正方法を言ってくれるな！」とケンカになります；。デベロッパーは料理人、テスターは料理評論家のようなものです。料理評論家は「おいしくないから修正すべき」ということだけを伝えるべきで、料理法やら素材やらを論じてうっかり踏み込むと、ケンカになってしまいます；。
このように、デベロッパーとテスターの間には、明確な役割の違いがあります。まとめると、以下のようになります。
| デベロッパー | テスター | |
| 主な役割 | 完成品を作る | 完成品の品質を評価する |
| ソースコード | 触ることが可能 | 触ってはいけない（出来上がったパッケージ品だけを触る） |
| 作業場所・作業環境 | 開発環境 | エンドユーザと同等の環境（テスト環境） |
| バグ出しの方法 | 場当たり的なデバッグ作業でバグ出しを行う | 事前に網羅的に設計したテストケースに基づいてバグ出しを行う |
| バグ出しのやり方・考え方 | ホワイトボックステスト（ソースコードを見ながら考えて作業） | ブラックボックステスト（ソースコードを見ずに作業） |
| バグを発見した場合 | その場ですぐにソースコードを直してよい （※ テストフェーズより前の場合） | バグ報告票（バグの修正依頼票）を起票し、デベロッパーチームに直してもらう |
| バグの修正 | 行う | 行わない（バグの再現手順を報告するのみ） |
日本の場合、テストとデバッグ作業が区別されていないことが多く、また、「完成品」を通して、デベロッパーチームとテストチームが連携する、という考え方が取られていないことも多いです（いやそれどころか、テストチームが独立していないことの方が多いでしょう）。しかし、『作ること』と『それを評価すること』とは全く異なるスキルセットが要求されますし、どちらが偉いという性質のものでもありません。実際、米国などでは、テスターとデベロッパーとの間に職位的上下関係はありません。
なお、稀に、バグ出しはテストチームの責任だと考えている人がいますが、これも誤りです。なぜなら、そもそもテストチームがテスト作業を始める前（すなわちテストフェーズに入る前）に、デベロッパーチーム側で十分な単体機能テストとデバッグを行い、ふつうに使ったぐらいではバグが出たりすることはない程度まで品質を高めておくことが必要だからです。というのも、テストフェーズに入った後、テストチームがバグを見つけた場合には、バグ報告票を起票してきちんとバグ管理をしなければならなくなりますが、バグの数があまりにも多い場合には、バグ管理そのものがまともに機能しなくなります。つまり、テストフェーズでバグ管理を適切に行うためには、管理できる程度までバグの数が減っていることが必要です。このためには、テストフェーズに入るまでに、デベロッパーチームが十二分にデバッグを行い、バグを摘出しておくことが必要です。
ちなみに、マイクロソフトの製品開発の場合には、テストフェーズに入ったのち、テストチームが一定期間以内に一定数以上のバグを発見した場合には、テスト不能として、テストチームがデベロッパーチームに対してフェーズの差し戻しを要求することができるルールになっています。
デベロッパーチームがきちんとデバッグしたものを、エンドユーザ視点で品質検査して、わずかに残っているバグを徹底的に摘出し、さらに品質を評価することが、テストチームのテスターには求められているわけです。かなりの高いスキルが要求されること、またデベロッパーとは全く違う視点やスキルが求められることが、容易に想像できるかと思います。
［システム開発のフェーズとエンジニアの対応関係］
さて、ここまで、システム開発に必要となる基本的な 5 つのロールを説明しました。
- 業務 SE
- アーキテクト
- デベロッパー
- テスター
- プロジェクトマネージャ
この 5 つのロールの人たちが、システム開発の各フェーズにおいて様々な作業を行い、システムを開発・リリースしていきます。プロジェクトのサイズや状況によって実施すべきタスクや期間はかなり変わってきますし、大型のプロジェクトでは構成管理チームやインフラチーム、運用チームなども編成される形になってきますが、おおざっぱには以下のような形になります。
……とまあ、こんな感じのイラストをよく見かけると思います。が、正直なところこうした作業図はとてもじゃないけれども覚えられない、というのが実際のところだと思います。私としてはこの図を暗記するよりも、以下のような形で勘所を覚えておくことをおすすめしたいです。
一般に、システムは「要求されたものを作る」わけですが、要件は以下の 2 つに大別されます。
- 機能要件：「どんな機能が必要なのか？」「何を作るのか？」
- 非機能要件：「各機能をどの程度の品質で作るのか？」
この二つの要件を明らかにし、それを満たすようにシステムを開発していくのがシステム開発です。このように考えると、システム開発の流れと大まかなタスクは、以下のようにまとめることができます。
この 2 つの流れにおける各タスクを実践していく際には、当然、得手不得手に応じたスペシャリストを割り当てることが必要です。先ほどの 5 つのロールとのマッピングを考えると、以下のようになります。
もちろん、実際の作業では、ここに示した人たちだけが各タスクを実施するわけではありません。例えば、結合機能テストを実施している最中は、当然、デベロッパーの人たちがバグの修正作業を行っているはずです。また、業務設計が終わった後、業務 SE の人たちはマニュアルを書いたり、場合によってはテスターロールとなってテスト計画やテストケース設計をしていることもあるでしょう。ですので、ここに書いたのはあくまで開発プロセスにおける骨組みで、ここに枝葉を補って、最終的には WBS やスケジュールを作成していく必要がありますが、こうした骨組みの部分を理解しておくことは極めて重要です。このような形で開発プロセスを理解しておくと、なぜ前述の 5 つのロールが開発において極めて重要な意味を持つのかがお分かりいただけるかと思います。
では、こうした作業を実践していくために、各ロールがどのようなスキルを持っているべきなのかについて考えていきたいと思います。（次エントリに続く。）