読者です 読者をやめる 読者になる 読者になる

MasaoApril's Library.

Software Testingなネタを書いてみた。

JaSST'14東京(4)

 ソフトウェアテストシンポジウム'14東京の続きです。前回は、「テスト設計コンテスト'14 決勝大会後半(らくてす/TFC KA・RI・YA/ちょび)」の話でしたが、今回はクロージングパネル「テストエンジニアの育成による組織力・チーム力の向上 ~現場が幸せになる育成とは?また、エンジニア自身が成長するためには?」です。

テストエンジニアの育成

 「どのように自ら育つか?」「育った暁に組織力・チーム力の向上」について、コンサル/大学教員/ベンダーの管理者/現場リーダの各々の立場からのパネルディスカッションでした。

状況

(1)テスト関連本

年ごとの出版数

 2003年を契機に加速的に増加

(2)JaSSTの開催地域

(3)ISTQB取得者数

 30万人越えた。

(4)テストスキル標準

(6)BOFの結果

・30名が参加
・想定外のいい結果が
キャリアパスが描けない
・組織の中での貢献
・テストエンジニアをサッカーに例えたことも
・スキルが多数あるけど、どこから始めるか?
・モチベーションの維持

(7)安達氏の分析

・テストは専門的スキルが必要ないと思われている
・テストスキルをとがらせると組織内で宙に浮く
・モチベーションが低い
・当事者意識がない

 ソフトウェアテスト関係の情報は、5年程前と比較すると入手しやすくなったと実感しています。また、JaSSTなどのシンポジウムや各地域の勉強会活動も活発になりました。しかし、会社組織内の問題(体制、(経営層の)テスト技術の認識、キャリアパスが描けない)があり、テストエンジニアの育成まで行き届かないことも多いです。私の現場も例外ではありませんが、私が担当するドメイン向けのテスト部隊は昨年度から今年度にかけて体制が多少強化され、部隊勢力が伸びる素地があることから、これから5年間のロードマップを経営層や中間管理職、現場メンバーと「何が伸びると何がうれしいのか?」という点を考える必要があります。

パネリスト:Stuart氏(ISTQB設立者/ISO/IEC JTC1/SC7 WG26議長 )

・大学がテストの基礎的教育

(1)大多数は、二の次な感じ。しかも、全カリキュラムの3割しかリソースを頂けない。

 大学の先生がテストの実践経験が無いため、学生への教育が不十分になりがち。

(2)ISTQB

 ・実用的なところが・・・。ただし、熱意はアピールできる?
 ・宣伝のやり方が誤っている。なぜなら、認定の価値を理解できていないから。換言すると、修士号のようなもの。

(3)キャリアパス

 ・テストエンジニアを昇格してテストマネージャ
  8割をテストマネージメントする必要があるが、マネージメントのスキルをそれほど得ていない。
 ・テスト技術を発展する

(4)報酬の与え方も一考する必要がある

 (3)については現在、私が悩んでいることの1つです。昨年度からテストマネージメントの立場になる場面がありますが、マネージメントのスキルが無いため、リスク低減するために何を考え行動すればよいかよく分からないことがあり、現場で苦労しています。また、リーダシップといったスキルをどう伸ばせばよいか、挫折しかかっている現実をどう突破するかが課題です。

パネリスト:片山氏(大学教員)

(1)学生の成長を間近に感じる環境

(2)育成への関わり方

・言っておかないといけないこと

  テストエンジニア、にこだわっているわけでは無い

・やりたいことを尊重

  自由な研究ができる

・自分でやった実感

  自信を持つ

・テストに興味を持たせる

  まずは勉強

(3)卒業後の人生は長い

・大学は踏み台でしかない

  将来的に自分で生きていくために必要な力

・学生の発想をつぶさない

  まずはやらせてみる

(4)成功体験がいいのか、失敗体験がいいのか、どちらがいいか分からない

(5)問題意識や難しいところ

・テストに興味持つ学生が少ない

  Web/ネットワーク/CGなどに目が行く

・興味の持たせ方が難しい

  学生が接する機会が少ない

・情報系でテストについての授業があったか?

  ソフトウェア工学のうち1コマ程度
  実務訓練では、プログラミングなどが多い

・大学のカリキュラム

  文科省が許可する構造であり、自由に授業のカリキュラムが組めないため、自由度は低い。

(6)・テストの授業を受けた人

 ・少数→数人程度が現状

 (2)の中で、「やりたいことを尊重」については、部長&課長に対しROIを含めて交渉する必要がありますし、メンバーでやりたいことがあればやれる余地を出すことも、私の課題になっています。ただし、どのように利益を出していくか、事業として検討する必要がありますので、道は険しいと思います。大学や研究所との共同研究の道も検討材料になりそうです。

パネリスト:佐々木氏(テストベンダー)

(1)人「財」育成の体系化

経営資産

(2)今年何人育ったか?

何人テスト設計ができるか?など

(3)企業内

・教育体系
・研究開発

(4)協会内

非競争領域での標準化

(5)企業の教育

何故○○を学ぶのか?

 理由を考えている人が少ないかもしれない。

 自社でも人「財」育成を進めていますが、ソフトウェアテストといった品質技術の体系化については、発展途上の状態です。開発技術に関しては、整備されつつありますが、(現場の私から見て)経営層で関心ある者がほとんどいないのが現状です。しかし、品質技術で設計品質がどの程度なのか検証できない状態で、いざテスト実施すると「製品として販売したら、お客さんからクレームが殺到するぞ!」という状況を目にすることが多々あります。設計品質の情報を何らかの形でフィードバックできないと、工程の手戻りが発生し、修正工程やテスト工程で工数が増大することで開発費用が膨大になるリスクがありますので、開発費用が膨大になる前に製品の欠陥を見つけるためのスキル育成もこれからの課題になると思います。

パネリスト:中野氏(テストリームのリーダ、テストマネージャ)

(1)育成への関わり

テストプロジェクトを通じ、テストエンジニアやマネージャを育成。

(2)育成で大事にしていること

(A)成功体験:次に繋げる
(B)失敗体験:次に改善すること
(C)知識よりセンス:テストの流れをつくる必要がある
(D)アドレナリンよりドーパミン

 ・苦しい状況
  アドレナリンが出てくる
 ・良い仕事
  ドーパミン。才能を感じるという気持ちよさを感じる

(E)開発力もあわせて磨く

 ・プログラマプログラマしか話しを聞かない
  テストエンジニアはプログラマの話を聞く。同じ目線で話す。

(3)問題意識、難しいところ(エンプラ系の現場)

(A)育成の環境や前提が整っていない

  ・テストの人材不足。供給不足。

(B)テストの専門性を高めた結果

 ・その後がふわっと。どこを目指すのか?

 「アドレナリンよりドーパミン」が最も印象に残っています。現状、アドレナリンが出ている場面が多く、心身ともに疲弊しています。しかし、良い仕事ができる環境を自分たちで整備して、ドーパミンが多い現場に変えていく必要があります。まずは、課長と協力して、「依頼者に喜ばれる仕事」を達成するために「自分たちのための仕事」を作り上げようと思います。

パネリスト:にし氏(大学教員、コンサル)

・ワクワクさせる話

 JSTQBは、無料で学べます。

(1)ASTER

(A)R&D活動

・ヨーロッパから輸入

 テストプロセス

・北米から輸入

 探索的テスト
 自動化
 アジャイルテスト

・内製

 バグ分析からのテスト
 派生開発でのテスト
 ドメイン固有のテストの形式知
 Wモデル

(B)人財育成トライアングル

・J層

 ISTQB FL取得

・M層

 WACATEなどの大型勉強会

・U層

 テスト設計コンテスト、地元勉強会、WACATE

・E層

 独自のテスト技法の開発、ISTQBの問題作成

(3)SWテストはきれいごとでない

技術を極めると、作業を売ることから脱却

(4)ワクワクして極める技術

(5)コミュニティ

 自分もスキルアップ、みんなもスキルアップ

(6)ロマンスと技術

 「人財育成トライアングル」の話は、これからのコミュニティ活動を進めていくための羅針盤になると思いました。私は、TEF東海での勉強会活動を中心に行っていますが、みんなで発展していく活動として私自身も更なるスキルアップを進める必要があると思いました。

現場が幸せになるTEの育成に必要なこと、欠かせないこと(不要、役に立たないこと)

●Stuart氏

・4つの技能(Tester skillspace)

 (1)Test skills
 (2)Soft skills
  コミュニケーションのスキル
 (3)IT skills
  テストのコンテキスト
 (4)Domain Knowledge
  ドメインの知見や経験

上記4点は、ISTQBのカバー範囲(FL、AL)だが、実務で求められる範囲はカバー範囲外のところもある。

●片山氏

・テストに限らず、何かに興味を持つ
・4年で成長しないといけない

 4年後に卒業したときに何をするのか?→卒業後○○でありたい。幸せなことである。

●佐々木氏

(1)超人で幸せになる?

 ムダにやらない

(2)提案ができることが必要

 「仕様が変だぞ!」というツッコミ(指摘)
 頑張って手を抜く

(3)意識つけて勉強する必要がある

 基礎体力、努力

(4)技術を理解できている人は少ない

 にし氏ならほっといても大丈夫

(5)自分がやること、得ること

 技術もスーパーマンも必要

●中野氏

現状は?

 (1)成功と失敗:9割5分は問題発生(失敗)
 ・スケジュール超過
 ・コスト超過
 ・稼働後のシステム障害
 ・関係者の悪化
 (2)スーパーマン
 ・超人的なパワー(テスト技術)
 ・独自の感性と価値観
 (3)信念
 ・失敗しない覚悟
 (4)必要なもの
 ・前提を変えてみる:成功してから、次へ繋げる
 ・何でも実験と考える
 ・不要なこと

●にし氏

(1)エンジニアとしてワクワクすると、自然に技術が身につく

 ・アーキテクト
 ・モデリング

(2)技術!!
(3)問題解決できる人財

 スーパーマンの発掘は必要ですが、現実は難しいかなと思います。しかし、各々のメンバーが自律的に考え行動して発展することが必須となると思います。そのためには、正社員/派遣社員/請負社員それぞれが発揮できるように、アイディアや意見を対等に出して受け止める仕掛けを(裁量のある)正社員から作り上げることが大切ではないでしょうか?私の現場では、「問題vs我々」の構図をインシデントレポートを媒体として3~5年程の間、築き上げました。

チーム、組織力の向上に何が必要か?

●Stuart氏

ある程度の組織

 (1)設計者と同じように扱う
 (2)テスターでも違う能力があることを認める
 ・コンサル
 ・自動化
 ・テストケース
 ・バグ検出
  テストエンジニアだけではないよ

●片山氏

佐々木氏と同意見

 (1)研究室でうまくいっている理由
 (2)先輩が後輩を教えている

●佐々木氏

・技術を教えられる人が必要

 自分であがるのは厳しい

●中野氏

(1)組織力は概念

 個々のエンジニア力に着目

(2)チームの活動から贅肉を見つける

 1日スミマセンを言わない。言わないところを言いたくなることが贅肉。

(3)己を見つめ直すために、活動を「ゆっくり」に

 時々でいいので...

●にし氏

(1)ロマンスでしょ?

・すごいことやっているんだったら、やってみろ!
 そして、みんなに与え、高い技術へ
トップダウンからはロマンスが無い。
 ボトムアップから

(2)受け身であってはいけない

 上記の中で「1日スミマセンを言わない」「受け身であってはいけない」が印象に残りました。日々のチーム活動の中で自律的に活動するためのヒントになると思いますので、時折意識してみて変化を感じてみます。

 次回は、「TEF東海勉強会参加レポート:2月某日に静岡でSWKYT(ソフトウェア危険予知トレーニング)のミニワークショップ」です。