ETSSインスタンス生成の実践講座 〜SESSAME版ETSSの事例解説〜 情報処理推進機構 ソフトウェア・エンジニアリング・センター 渡辺 登 ------ アジェンダ ○スキル基準 ○キャリア基準 ○教育カリキュラム ⇒今回はスキル基準をメインに話す ・開発現場の意見(アンケート) 求めるもの 1位 技術者の育成 2位 技術者の確保 以下 技術力，能力の向上など ⇒組込みソフトウェアの課題は人材の確保である． ・技術とスキルの違い 技術：工程，手順が知識として整理されている．伝達可能．(TCP/IPなどの規格) スキル：実際の作業ができる，作業遂行能力(Cが書ける⇒Cのスキルがある) ・2007年問題 長年の技術を蓄えてきた技術者が一斉に引退してしまう問題 技術，スキルを伝承しなくてはいけない． ETSSの構成は以下の3つ スキル基準：技術を体系的に整理したもの キャリア基準：職種ごとの役割を整理したもの 教育研修基準：スキルアップするには？キャリアアップするには？をまとめたもの ・組込みスキル基準の狙い スキルの可視化 教育研修基準：研修の雛形になる ・スキルカテゴリ 技術要素：システムの部品(交換機の部品は？通信機能，UI，蓄積昨日．．．) 開発技術：プログラミングスキル，モデリング，デバッグスキル．．． 管理技術：プロジェクト管理，プロセス管理．．． (詳細はIPAからダウンロード可能) ○技術要素のインスタンス例 第1階層，第2階層：ETSS定義．スキルの整理方法を標準化 第3階層，スキル項目：標準化は困難なためあえて未定義になっている．利用 者定義． -- 例) 第1階層 第2階層 第3階層 通信 有線 PAN 無線 電気通信 近距離通信 インターネット 透過的データ転送 応用処理 情報処理 情報入力 パターン認識 データ入力補完 データ処理 文字データ加工 情報出力 ビューア -- ETSSではスキルの整理方法までを行い，具体的なスキルには触れない (交換機の開発をやってた人がECU開発ができるかもしれない(どっちも通信な ので)) 分散システムの場合，どこのスキルを持っているのか? アプリケーション層？， データ層？などを考えるべきである． ・通信の場合， 通信デバイスを作れるスキルなのか？それを使えるスキルなのか？ 両方に共通するスキルもある(プロトコルなど) ・暗号化の場合 著作権保護を作るうえで，暗号化を知っているのか? 暗号を作れるのか? 暗号アルゴリズムを何で実現できるのか？ SW/HW/DSP 暗号アルゴリズムをたくさん知っている野ではなく，実現ができるというのがスキル ⇒技術の体系化のあとで，どのスキルが必要なのかを考えられるのがETSSのいいところ ・計測・制御(大変だった) 機能分割ができていないのでスキル標準として表現しにくい 入力→処理→出力：求められるスキルが考えズライ ○開発技術 ・開発技術スキルカテゴリ (詳細は組み込みスキル基準ver1.0を参照) 組込み特有の部分として リアルタイム(いかに高いリアルタイム性を実現するか)， ハード(どう制御することが必要か，システムとしての最適解を探せ)， 開発環境(クロス開発環境＋分析・設計環境や検証環境) がある． 他は汎用コンピュータ向けのスキルとほとんど同じ ・システム要求分析 マインドマップを見ると汎用機と換わらない 実際のプログラム作成手法．テストでなにをやらなくちゃいけないかの整理 →開発技術 ・ツールに関するスキルの継承 開発対象の評価系のツールのスキルが重要だと思う． A社のやりかたにB社のやり方を持ってきたほうが効率が良くなるのでは?など考えられる． 今まで何を使ってきたのかを議論することで開発効率が上がる． ＊技術 要素と開発技術の関係重要 技術要素：開発技術に依存しない要素に対する設計製造検査のスキル 通信品質保証の実現仕様策定スキル，伝送路媒体特有のノイズに対する理解と対策の 設計スキル．プロトコルアナライザの利用スキルなど 開発技術：技術要素に依存しない開発技術に関するスキル モデリングすきる・プログラミングスキル・デバッグスキルなど （文書として残しズライOJTなどで教えていくべき） ○管理技術 PMBOK マネジメントをしてもらうための技術というものもあるので開発者にも無関係ではない． 管理技術の個人での成功は難しい，組織としての取り組みをしなくては上手く いかない．マネージャを支援しなければ，管理技術スキルがたくさんあるから といって成功するとは限らない． やり方(知識)が根幹＋コミュニケーション：マネジメントスキル (スキル標準ではやり方しかサポートできない) ○スキル基準 (技術要素，開発技術，管理技術の)3つのスキルカテゴリを表にまとめるとス キルの可視化ができる． 通信が得意なつもりでも，じつは狭い部分のスキルしかなかったとかに気づけ る． スキルの可視化の良い面として， エンジニアのポテンシャルの有無に気付ける． 「やったことないけど，下地はできているだろう」などということをデータ に基づいて考えることが出来る．(今までは，こいつはこんなことをやってた からこれも大丈夫だろうとか，個人の感覚で決めるしかなかった) エンジニアのスキルは上からいわれた仕事に依存してしまっている．自分が 持っていなくてはいけないスキルは？自分の強みは？を考えていける ○キャリア基準 それぞれの職種の責任の明確化と責任を果たすために必要なスキルを整理 ・例えば，サッカー GKとFWで持っているスキルは違う マネジャとプログラマも責任も違う．決められた責任を果たすことが重要． ただし，共通するスキルもある ・職種毎の責任 こういった責任を果たすためにどういうスキルが必要か？ ・ドメインスペシャリスト 製品の知識 製品AにはこれBにはコレという設計 プロジェクトマネージャと連携して動く ・プロジェクトマネージャの特性 プロジェクトマネージャには2種類居る 技術志向PMと管理志向PM 大規模開発には管理志向PM 小規模には技術志向PM 明確な閾値はないが，だいたいこんな感じ ・開発プロセス改善スペシャリスト(SEPG) 責任：ソフトウェアの手法導入アセスメント ・QAスペシャリスト 責任：製品の品質レベルを各工程でチェック ・アーキテクトとドメスペの違い プロジェクト内か？外でやるのか？の違いである． アーキテクト：どのOSが良いのか等を考える ドメインスペシャリスト：プリンタに対してこういったものが必要とかアドバイス ○教育カリキュラム SECからダウンロードできるがETSSのうち，ドキュメント量は一番多い． 実際の開発でどう使われるのかを教えることで基礎の勉強に対するモチベーショ ンをあげるとか，モチベーションはどうやったらあがるのかを考えながら教育 するべきである．