読者です 読者をやめる 読者になる 読者になる
スポンサーリンク

情報処理技術者試験の「資格ヒエラルキー」をAAで図示してみる

資格 SE 小ネタ 開発 例え話 アスキーアート

資格には,下記のような要因に基づく「価値のヒエラルキー」が存在することだろう。

  • 合格の難易度
  • 資格保持者の市場価値,需要の多さ

いわば,資格の偏差値のようなもの。

典型的なのが,資格のランキング。


この意味での「資格のヒエラルキー」は,IT業界の動向により,時と共に変わる。

技術の進歩とか景気によって需要は変化するし,また難関の資格であっても合格者が増えれば「平凡化」するからだ。


しかしそれとは別に,資格には

  • 命令系統や,成果物の流れに基づくヒエラルキー

も存在すると考えられる。

いわば,組織図から見た,その資格のポジションである。

こちらのヒエラルキーは,時代の流れに影響されない。


もしシステム開発工程を主体に考えた場合,

あの有名な「情報処理技術者試験」のそれぞれの資格は,

一案として,下記の図のように位置づけされると思われる。

情報処理技術者試験の資格ヒエラルキー図

 システム監査技術者
    ↓
    ↓
  (経営者)
    ↓
    ↓
  ITストラテジスト
    ↓
    ↓
┌───↓─────────(開発チームの枠) ┐
│   ↓                 │
│   ↓                 │
│プロジェクトマネージャ              │
│↓ ↓   ↓        ;     │
│↓ ↓   ↓        ;     │
│エン 情   ↓        ; 応 基 │
│ベ 報   ↓        ; 用 本 │
│デ セ   システムアーキテクト,    ; 情 情 │
│ッ  キュ→→データベーススペシャリスト,→→→報→報 │
│ド+リテ  ネットワークスペシャリスト   ; 技 技 │
│シス ィス            ; 術 術 │
│テム ペ            ; 者 者 │
│ス  シャ            ;     │
│ペ リス            ;     │
│シャ ト            SEとPGを    │
│リス             分ける壁    │
│ト                     │
└─────────────────────┘
    ↓
    ↓
  ITサービスマネージャ ←←← ITパスポート


図中の矢印は「命令系統」の場合もあるし,「成果物の流れ」でもあったりする。

この図を理解すれば,開発フローの全体像が理解できる。


まずは,これらの資格の位置付けを「宝石店」のたとえ話で理解してみよう。


システム開発の組織構成を,「宝石店」のたとえ話で理解する

システムを「宝石店」に例えてみよう。

店舗で宝石を販売し,利益を得る。という計画について考える。



まず,宝石店の開業を決める。資金も調達する。(経営者


開店に向けて,店舗の立地や客層,ブランドイメージなど,
基本的な企画・方針を立てる。(ストラテジスト



そして,開店準備作業をする。


きれいな宝石箱を作る。
箱はきれいで,その中身の見栄えを引き立てる役目をする。(SA


その箱の中に,宝石を慎重に格納する。(DB


そして,その宝石箱を展示ケースに入れて,値札を付けて並べ,
宝石店の内装を整える。(NW


これら全ての開店準備作業を,開店日に間に合うよう指揮する。(PM



宝石店なので,盗難が怖い。アコムに申し込んで防犯対策をする。(セキュリティ



お店は普通,建物の中にテナントを借りて本店舗を開くわけだが,

特殊な店舗形態として「移動式の宝石店(カー店舗)」を構築し,本店舗の補助として活用する。(エンべデッド



最後に,宝石店を開業する。

開店した宝石店を運営・管理し,接客・販売する。(サービスマネージャ



偽物の宝石を販売していないか,定期的に検査を行なう。(システム監査



このようにして,宝石店の経営が成立する。


どのポジションの人間も必要であって,全体として組織を構成しており,どの技能も欠かせないものだ。

命令系統や立場の「高低」差はあれど,職業の違いとして「優劣」はない。


なお,「応用情報・基本情報・ITパスポート」は,このたとえ話には出てこない。

あえて持ち出すとすれば,全体を通してジェネラルな作業を指示通りにこなす担当者たち,という事になる。

また,ITパスポートは開発側ではなくユーザ側の資格なので,運用サイドに物申す立場という事になる。



このような例え話で,各ポジションのおおまかな位置付けがわかるだろう。

続いて以下では,個々の資格保持者どうしの現実世界での関係を述べる。


※適宜下記URLも参照すること。

主なIT資格の一覧とリンク集
http://language-and-engineering.hatenablog.jp/entry/20101225/p1

(1)システム監査技術者

経営者は,システム監査人に監査を依頼する。

その目的は

  • 自社が用いているシステムの正当性を証明する事によって顧客の信頼を得る
  • 不足点があればIT活用方針を改善し,業務改革につなげる

という事である。



依頼を受けたシステム監査人は,該当企業のシステム利用状況を調査し,

システムの安全性や信頼性,会計的な健全性などを確認する。

いわば,その会社の「外部コンサルタント」としてふるまう。

監査の結果は,経営者に報告される。



経営者は監査結果を受け,社内におけるシステム利用の在り方を改善する。

改善の検討時に,もし経営陣の中で

業務改革のために既存のシステムを刷新すべきだ

みたいな声が上がると,リプレースのために新規システム開発プロジェクトが立ち上がる事になる。


(2)ITストラテジスト

経営者が経営方針を決めたら,その経営方針を忠実に反映したIT戦略を考案し,システム化計画を立ち上げる必要が生じる。

いわば,ビジネスとITの橋渡しをする「内部コンサルタント」の出番になる。

そういった役目を果たすのが,ITストラテジスト。

(もちろん,この業務を社外の人間に委託する場合もある。)

アナリストとも言う。


ITストラテジストは,要件定義で言う「ビジネス要件」を正確に理解する。

そして,As-Is業務を分析したうえで,ビジネス要件を基にTo-Be業務の全体像を描く事により,「業務要件」の構想を練る。

アナリスト=「分析屋」だけに,業務分析が得意なのだ。


次いで,その業務要件の全体像から,システム化の計画を立てる。

「要件定義」を理解しよう (要求・要件の3レベルのまとめ)
http://language-and-engineering.hatenablog.jp/entry/20100903/p1

  • ビジネス要件・業務要件・システム要件の3段階


このようにして,要件定義工程の最上流(超上流)の部分を手がけ,

その結果を企画書にまとめ,プレゼンテーションをし,

そのソリューションの実現について経営陣の判断を仰ぐ。



企画書が承認されたら,その企画を担当する部門が選定される。

該当部門は,プロジェクトの立ち上げに向けてリソースを集め始める。

まずは,プロジェクトマネージャの任命から。

(3)プロジェクトマネージャ

プロジェクトマネージャ(PM)は,企画が承認された段階で,外部ベンダや社内開発部門から抜擢される。

PMは,企画を持つ顧客(お客様)と,開発チームとの間で橋渡しの役目をする。



まずPMは,時間や予算などの制約を考慮に入れつつ,企画の概要を把握する。

次いでPMは,それらの予算を使いながら(お財布を預けられた状態で),お客さんと打ち合わせつつメンバを集めてゆく。

とりあえず上流を扱えるSE達を幾分か集め,見積もりに役立てる。



この段階でPMに求められるのは,荒削りな(ざっくりとした)ガントチャートを作成することである。

そのためには,工数のおおまかな見積もりが必要になる。

なので,画面数や機能の規模,アーキテクチャ,その他各種要件を取りまとめ,

初版ガントチャート類を作る。



その上で,作成したガントチャート類に基づいて見積書や契約書を取り交わし,

スケジュールが承認されれば,いよいよ開発が本格的に始まる。

PMは,下流工程を担うプログラマやテスタなどの人員を集めてゆき,

その後は進捗や問題を常に把握する。



※なお,エンジニアはPM系の資格取得を視野に入れておいたほうがよい。

そうしないと,いつまでも人にこき使われる立場のまま。

詳しくは下記の書籍を参照。

仕事がストレスなら,知識を増やせ。 SEの視点での書評:「勝ち残りSEへの分岐点」
http://language-and-engineering.hatenablog.jp/entry/20110411/p1


(4)システムアーキテクト,DBスペシャリスト,ネットワークスペシャリスト


いわゆる上流を担えるようなSE達が,プロジェクトの初期段階でPMによってチームに招待される。


SEたちは,密接に話し合いながら「業務要件」を考慮し,

要件定義の最後の段階である「システム要件定義」を完了させる。


そして,それぞれの担当分野における基本設計を完了させる。



ここであげた3つの資格は,それぞれ

  • SA(アーキテクチャ含む)
  • DB(モデル含む)
  • NW(基盤全般)

を担当する。


これら3種類の担当者の間に,上下関係はない。

この3者のつながりは密接だ。

宝石店のたとえ話でも触れたように,これらのSEは,

それぞれ「ハコ・中身・土台」を担う。

  • SA(またはシステムのアーキテクチャ)は基本設計においてデータモデルの影響をもろに受けるし,アーキテクチャを決定する際にインフラの制約を受ける。
  • DBはSAから利用される立場にあり,またNW上では1台ないし分散構成のサーバ群として機能する。
  • NWはSAからもDBからも利用される立場にあり,要件に応じたインフラを構築する務めがある。


つまり,もしこの3者の素質をだれか1人が全部持っていれば,「オールマイティなSE」という事になる。

これらSA・DB・NWが,「基本技術3要素」とでも言うべき軸になるのである。

技術者は,これら3分野の制覇を目標にするとよい。(特に,NW分野はおろそかになりがち)


(5)情報セキュリティスペシャリスト,エンべデッドシステムスペシャリスト

この2つの資格は「専門領域を持つ,横断的な資格」と言える。


つまり,特定の工程に限定せず,

全部の工程に対してかかわりを持ち,口や手を出す。

  • セキュリティは,SA・DB・NWの3要素すべてにとって,考慮・実装すべき分野。
  • 組み込みシステムの場合,SA・DB・NWの3要素すべては,「特殊なハードウェア上での動作」という制約を受ける。


これら2種類の資格保持者は,要件を正確に解釈しつつ,
PMの指導のもとで作業する。

そして,前項(4)で取り上げた3要素の技術者達を,セキュリティや組み込みといった観点で常に指導する。

(指導するとは言っても,もしかしたら双方のスキルを兼ね備えた同一人物かもしれない。)


前項が「技術領域」での区分だとすれば,本項のSEたちは

「技術の用い方」に関する方針を与える役目をする,と言える。


(6)応用情報技術者,基本情報技術者,ITパスポート

前項の技術者は「専門領域を持つ,横断的な資格」であったが,

ここで挙げる3資格は「専門領域を持たない,横断的な資格」と言える。


大抵はPGのような担当者として,下流工程に投入されることになるだろう。

「Javaアソシエイツ」とか,LPIC保持者(レベル2まで),Oracle Master保持者(Silverまで)も大体このへんに位置づけられると思われる。


SEになりたければ,自分の「軸」となる専門領域を何か身につけることだ。

そして,コンピュータだけではなく,ヒトを扱えるようになること。


特定のベンダのツール類を十分使いこなせるのも確かに良いことだが,

それは「コンピュータを相手にする」仕事。

ユーザの要求,つまり「ヒトを相手にする」ようになれるかどうかが,PGとSEを隔てる壁だと言える。

(7)ITサービスマネージャ

PMの指揮のもとで,開発チームが無事にシステムを納品できたら,

納品物は運用チームに引き渡される。

そこからは,ITサービスマネージャが主役になる。



とはいっても,この段階で初めて運用の話が持ち上がるのではなく,

要件定義の段階で運用設計から入り,SLAを決め,
SLAに基づいて非機能要件を提案する。


冒頭の図はあくまで開発を主体に考えているので,
運用の出番は最後,という見せ方になる。

成果物の流れで考えると,開発チームから運用チームへシステムや運用手順書が引き渡される,というフローなので。



ITサービスマネージャは,リリース済みのシステムの運用体制を管理する。


ITIL保持者とかCCNA・MCP保有者などを集めて,データセンタの監視業務に当たったりする。

そして,ITサービスがSLAの基準を下回らないよう,24時間ずっと神経をとがらせる。


インシデントや保守要望が発生すれば,適宜開発チームに連絡を取り,システムの変更管理を行う。



各資格の説明は以上。

結び

以上が,「情報処理技術者試験」の各資格を基にした,

システム開発時の組織構造(ヒエラルキー)の説明となる。


担当者の役割分担やタスクの流れが分かれば,

開発フローの全体像もわかりやすくなるだろう。

補足:「ヒエラルキー」とは何か

「ヒエラルキー」という語は,たいていマイナスの文脈で使用される。

例えば,ピラミッド型の官僚組織のトップ層に対して批判を述べる際に用いられる。



しかし単に「階層構造」という意味もある。

例えば,システム・アーキテクチャとして「3層の階層構造」という場合,

英語では「Three-Layer Hierarchical Model」という。

また,Linuxのディレクトリ構成の規格である「FHS(Filesystem Hierarchy Standard)」を耳にした事がある人も多いはずだ。



指揮系統・命令系統などがはっきりしている組織の構造について言及する際,

この語を用いるのは間違いではない。



システム開発を行なう組織やチームについても,

  • 責任者との上下関係があったり
  • 分業により役割分担がはっきりしていて,工程間での成果物の流れが,一種の「階層構造」を生んでいたり

するので,ヒエラルキーが存在すると言えるだろう。


それに,「いちプログラマ」よりもPMのほうが偉い,というのは,ごく普通の認識であるわけだし。


ただ,誤解を生みやすいので,何も悪い含みの意図がないという事を一言断っておく必要があるだろう。

Wikipedia:ヒエラルキー
http://ja.wikipedia.org/wiki/%E3%83%9...


Wikipedia:階層構造
http://ja.wikipedia.org/wiki/%E9%9A%8...