SQuBOK V2からこれからのソフトウェア品質について考える

1. はじめに

本稿は、「SQuBOK V2 読破会」のメンバによる Advent Calendar になります。今回で第19日めのエントリになります。短いようで長いような、長いようでも次回ような感覚です。
http://www.adventar.org/calendars/1020
ところで、12/19に開催された読破会で、「SQuBOK V2」を、すべて(巻頭言、はじめに、序章、第1章から第3章まで)読み終えたことになります。私たちは、ほぼ1年かけて、368ページまで読みました。長かった・・・。

今回は、SQuBOKを読み終えたということで、SQuBOK V2 と、私が良く見る「小説」からソフトウェア品質の考え方の変化を考えてみたいと思う。(っていうか私がそんなこと書いたら、どこかから怒られるのではないかとか思ってみたり・・・)

2. 「品質の考え方」は不変?

最近、お仕事して思うことの1つに、「品質に対する考え方が古いのではないか」と思う言動をする方が、とくにベテラン層に、一定数いるように思う。「品質がよい≒バグが少ない」「設計ド キュメントなどのフォーマットが数年~10数年も変わっていない」というようなことを聞いたことがあり、なんだかなぁ、と(註:あくまで「小説」です・・・)。

では、どのように変化してきているのか?それを SQuBOK V2から見てみる。
SQuBOK V2において、品質の定義については、「1.1.1 品質の定義(品質の考え方の変遷)」に記載がある。ここでは、13の人や規格などから「品質の定義」を紹介している。その内容をまとめてみたのが以下の図である。

SQuBOKV2_AdventCalendar_1219_01

このように、時代とともに、ソフトウェアを取り巻く環境と、人々のライフスタイルなどどともにソフトウェアの品質に対する考え方が変化してきている。このような変化は今後も続いていくと考えられるため、どのように変わっていくかを考えながら、お仕事に取り組む必要があると思っている。
例えば、IoTを取り込んだシステム、人工知能(機械学習やディープラーニングなど)を取り込んだシステムなどの品質保証はどのように行なうのか?は従来の枠組みのなかでできるのか、拡張や変更を行なう必要があるのかは、今後考えていくことが必要であると思う。(少なくとも、今までの伝統的なSIerが行なう品質保証のやり方、ではビジネス戦略を含めた品質保証という意味では難しいような気がする。)

3. これからのソフトウェア品質を、どのように考えるか

前章で書いたように、ソフトウェア品質は変化し続けている。では今度どのようなことを考えていく必要があるのだろうか。これを考えるためには以下の資料が参考になるのではないだろうか。

「SQuBOK V3の開発プロジェクトについて」
https://www.juse.jp/sqip/symposium/timetable/files/happyou_E1-2.pdf

この講演資料では、「欠陥エンジニアリング」「DevOpsやアジャイルでの品質保証」「サービス品質、感性品質」などが「新しい品質への取り組み」として説明されている。

また、ソフトウェア品質で変わってきたと思うものの1つに、以下の講演が聞けたことも影響しているのではないかと思う。

「ビジネスが変わる・・・品質が変わる」
http://www.juse.jp/sqip/symposium/2014/detail/day1/#kichou_1

この講演では、ユーザ側企業からデリバリーの早いことが品質に大きな影響があることを説明している。ツールベンダーがデリバリーの早さの価値をセールストークのように聞いたことがあるが、ユーザ企業側が強く主張していることを聞いたのは初めてなような気がしたため強く印象に残った。
これらのようなことを、お仕事や自分の活動の中で考えていく必要があるのだと思う。

4. さいごに

今回、(一応)SQuBOK V2を読み終えたということで、「ソフトウェア品質」の定義を振り返って、その推移を書いてみた。またこれからのソフトウェア品質を考える上での参考なりそうな情報を示した。なぁ、と思います。
いろいろ書きましたが、半分以上の要素は、自分に対する戒めでもあります。1年後に見た時、ここに書いたことが少しでも解決できていたり、よい方向に進んでいたりすればいいなぁ、と思います。これからの SQuBOK と ソフトウェア品質に少しでもお手伝いできれば、と思います。

F.蛇足

記事投稿前には以下のようになっていたと思いますが、特に意味はありませんw

SQuBOKV2_AdventCalendar_1219_02
仮タイトルの多くが「xxxなにか」で終わっていたことに触発されました。
あと個人的には、ペルソナウェア(正確には、その後継のプロジェクト)が最近まで続いていることに少し衝撃を受けましたw

ということを、「アレ以外のStay. -YO-MA Mix-」を聞きながら書いてみました。。。

えんいー。

 

「不具合管理」を見てみる

記事の納期に遅延が発生して申し訳ありません。

1. はじめに

本稿は、「SQuBOK V2読破会」メンバによるAdvent Calendar 2015になります。
http://www.adventar.org/calendars/1020

今回が第11日目となります。
メンバ執筆も、2週めに入り、温まってきた・・・のだろうか?

筆者は、バグレポートを改善を目的としたコミュニティに所属しています。
https://sites.google.com/site/swworstpracticesite/

コミュニティの活動成果などを、JaSSTSQiPシンポジウムなどで発表してきました。そのなかでいろいろな文献などを調査してきました。このようなことから、今回は、SQuBOK V2のなかの「不具合管理」の記載を見てみるとともに、実際に業務で有効に使うために役に立ちそうな書籍や文献を考えてみたいと思います。

2. 「SQuBOK V2」のなかの「不具合管理」

「不具合管理」については、「2.11 構成管理」(142ページ)の中で説明されています。「構成管理」の中にくくられており、「変更管理」「バージョン管理」とならび、「不具合管理」(146ページ)と説明されています。146ページから147ページのなかの半ページほどという程度の説明になっています。「不具合管理」について以下のように説明されています。

1. 現象の再現と調査
2. 対応時には変更管理とバージョン管理を同時に行う

さらには、「不具合管理」ではステータス管理が必要であることが述べられています。また、不具合は、複数検出されることが多いため、対応の優先順位を決める必要性も説明されています。
ところで、「構成管理のアンチパターン」が参考文献として紹介されています。書籍は入手し読んでいます。まだ熟読はできていないのですが、「不具合管理」そのものというより「構成管理」のアンチパターン(やってはいけないパターン)についての説明に思いました。「不具合管理」の参考文献としてあげられているのはどのような理由か、少し気になりました。

3. お仕事で使うために

SQuBOK V2の中では、上記2章のように説明されていますが、お仕事で活用するためには、この記載だけでは十分ではないように思います。そこで実際にお仕事で役に立つと思われる文献などを示したいと思います。

3.1 「ソフトウェアエンジニアリング基礎知識体系(SWEBOK V3)」

SQuBOK V2の関連文献として、紹介されています。SWEBOK V3では、大きく2か所
に、「不具合管理」に類する記載があるように思います。
まず、「第4章 ソフトウェアテスティング」「5. テストプロセス」の「5.2 テストアクティビティ」で、「5.2.6 問題報告/テストログ」「2.6.7 欠陥追跡」の項に説明があります。
もう1つは、「第6章 ソフトウェア構成管理」「3.1 ソフトウェア構成コントロール」です。SQuBOK V2と比較すると、テスティングの時の「不具合管理」が、もう少し詳細に記述されているように思います。
「ソフトウェア構成コントロール」は、SQuBOK V2とほぼ同じ内容を表現を変えて説明されている印象でした。テクニカルタームが、SQuBOK V2よりやや多い感じなので、人によっては少し読みにくいかもしれません。
SQuBOK V2の「不具合管理」には、「テスティング」との関係が明示されていないように思います。「不具合」の定義に含まれていて抽象度をあげているように思います。そのあたりが、SWEBOK V3では少し掘り下げられているように思いました。SWEBOK V3を合わせて読むともう少し深く理解ができると思います。

 3.2 「ソフトウェアテスト 293の鉄則」

個人的には、テスティングに関わる人すべてが読む本だと思います。「第4章 バグ報告」が「不具合管理」に関係が深いと思います。
読み物に近いため、BOK(知識体系)のように、規格や文献などの話は薄いのです。しかし経験ベースで書かれているものが多いため、実務に役立つTips的な事例、テストエンジニアとしての心構え、振る舞いが詰まっている内容だと思います。

 3.3 「Bug Advocacy」

「3.2 ソフトウェアテスト 293の鉄則」のオリジナルの著者の1人である、Cem Kanerらが著した書籍です。バグ報告に関する改善、注意点、ふるまい、心構えなどの講義資料などをまとめた内容になっています。一言で強引にまとめると、「「ソフトウェアテスト 293の鉄則」の「第4章 バグ報報告」を、論理的に体系的に説明している内容」と思います。バグレポートにかかわる人すべてが一度は目を通す本だと思います。
バグレポートの報告や改善の重要なポイントとして “RIMGEN” としてまとめられています。ちなみに、R(Replicate),I(Isolate),M(Maximize),G(Generalize),E(External),(Neutral)の頭文字になってます。また、開発者に調査を渋られる、拒否されるバグレポートはどのようなものか、やそれらの取るべき対応などがまとめられています。

 3.4 「TPI NEXT ビジネス主導のテストプロセス改善」

テストプロセス改善について書かれている本です。テストプロセスを16のキーエリア(領域)に分けて、それぞれのキーエリアについて評価を行ない、キーエリアの改善することでテストプロセスの改善を行おうとするものです。16のキーエリアには、「テスト戦略」「テスト組織」「コミュニケーション」「メトリクス」「テストケース設計」「テストツール」などがあります。こうした中に「欠陥管理」という領域があり、これが「不具合管理」にかかわるものと考えます。
「TPI NEXT」では、レベル(「コントロールレベル」、「効率化レベル」、「最適化レベル」:右に行くほど成熟度が高い)が定義されています。「欠陥管理」では、「バグが管理されているか?」「バグの特徴分析ができているか?」「バグの未然防止に利用できているか?」という内容になっています。
また「TPI NEXT」には、「基本クラスタ」というものが定義されており、まずこれに沿ってテストプロセス改善を進めたらどうか?というプロセス改善モデルがある。その基本クラスタにおいて、「欠陥管理」は、「コントロールレベル」の2ブロックに位置されています。これは、「欠陥管理」はかなり早期に改善を行なうべき重要なキーエリアであると考えられます。バグレポートの改善を行なう際には参考になる点が多いと思いました。

 3.5 JSTQB Advanced Level シラバス

JSTQBは、「ソフトウェアテスト技術者資格」の認定を行ない組織です。この組織が、ソフトウェアテスト技術者に必要なレベル、ロールやスキル内容をもとに学習するべき内容をきめたもの(シラバス)を公開しています。
JSTQBには、Fundationレベル、Advancedレベル、Expertレベルの3つがあります。(ただし、日本で試験が実施されているのは、Fundationレベル、Advancedレベルの2つです)。それぞれ、初級者、中級者というように分けられています。
Advancedレベルには、3つのロールがあり、それぞれ「テストマネジャー」「テストアナリスト」「テクニカルテストアナリスト」が定義されています。
「不具合管理」は、JSTQBでは、「欠陥マネジメント」が該当する個所と考えられます。JSTQB Advanced Levelでは、テストマネジャーとテストアナリストで「欠陥マネジメント」のスキルが定義されています。テストアナリストでは、「欠陥の分類体系を設計する」、テストマネジャーでは、「欠陥のライフサイクルのマネジメント、プロセス能力の評価」などが求められる内容となっています。
ソフトウェア開発のロールにおいて、どのようなスキルや能力が必要かを記載している点が「SQuBOK V2」と異なる点だと考えます。

4. バグレポート1件の報告時間はどれくらいなのか?(Twitterによる調査)

ふと、バグレポート1件にかけられる時間はどれくらいか?ということが気になりました。そこで、Twitterで最近実装された「アンケート機能」を使い、1件につきどれくらい時間をかけられるのか調査を行ないました。なお、アンケート機能は、無記名で情報を収集しています。簡易的な機能であるため、詳細な背景や情報は収集できません。組織やプロダクトの特性、ドメインなどによって様々な回答が想定できますが、今回は収集していません。
今回は35件の回答を得たました。結果は以下の通りです。

twitter_アンケート

もっとも回答が多かったのは、「10分くらい」というものである。これは予想の範囲で
ある。筆者の経験でも、それくらいの印象である。
次に多かったのは、20分以上かかるケースがあることである。これは予想外であった。もう少し、少ないのではないかと思っていた。
5分でも多いと思っている人と、20分以上かかる人の違いが気になってきました。BTSかExcelかではあまり違いはでないような気がします。Toolsそのものの問題ではない、と思います。Twitterによる簡易調査なのであまり詳しくわかりませんが、Twitter、Facebookからいただいた意見を参考にしながら考えると、以下のような要因が考えられます。

  • テストレベル
    CT(コンポーネントテスト)、IT(統合テスト)、ST(システムテスト)では  バグレポートの報告に要する時間が異なるのではないかという意見をいただいた。筆者は品質保証部門に所属しているため、総合テスト以降の上位レベルのテストにかかわっていることが多いためアンケート開始時にはすぐに思い至らなかったが、影響はありそうである。
  • ドキュメント(テストベース、テストケースの記載の粒度など)
    きちんとしていないドキュメントから、バグレポートを作成するのは、確認事項などが多くなるため、作成時間が多くなることが想定されます。
  • ドメイン
    金融系システムなどは、問題が発生したときに監督省庁などから監査がはいることがあるため、ドキュメントも監査時にわかるような内容や粒度で作成する、とどこかで聞いたことがあります。そうしたことから、関係者の多さと求められる記載レベルなどが影響を与えそうです。組込み系も、上位レベルのテストは、調査などに手間がかかり時間がかかるような気がします。このあたりは根拠がなく想定になりますが。
  • バグレポートのステークホルダーの量と質
    上述の内容と少し重複しますが、バグレポートは、だれが見るのか?見る人が理解できるのか?を考慮する必要があります。そのため、見る人の理解力やわかる用語をあわせて記載する必要があることから、ステークホルダーが多ければ多いほど記載内容や表現、エビデンスを考える必要があるため、バグレポートの作成時間に影響がありそうです。
  • その他特別な運用
    オフショア先(例えば中国、ベトナムなど)が理解できるように英訳する必要がある、という意見をいただきました。そうした、組織やプロジェクトに固有な運用ルールも時間がかかる要因になりそうです。

機会があれば、使いやすいBTSをつくることを考える、ために調査したいと思います。

5. さいごに

今回は、「不具合管理」が、SQuBOK V2ではどのように説明されているか、ということと、不具合管理を実務で使えるようにするための書籍や文献、Twitterでの調査結果を書いてました。
みなさまの「バグや問題との戦い」の参考になれば幸いです。

F.おまけ

コミュニティのメンバ全員で、バグレポート改善にまつわることをテーマとして記事を書きました。寄稿先は、Software Testing ManiaX という同人誌です。次の冬コミ(2015/12/31)に頒布されます。今回で10巻めになります。

第10巻では、以下のような記事を執筆しました。

  • 「Bug advocacy」の紹介
  • 「TPI NEXT」「JSTQB Advanced Level テストアナリストシラバス」中のバグレポートにフォーカスした記事
  • 最近の活動内容

http://circle-official.wacate.jp/#stm_10

もし、興味を持っていただける方がいましたら、12/31とお忙しい日だと思いますが、
ビックサイトでお手に取っていただければと思います。よろしくおねがいいたします。

次回は、Dj Mass さんです。

 

JCSQEを受験してきました。

1. はじめに

本稿は、「SQuBOK V2読破会Advent Calendar2015」の一環で執筆しています。
http://www.adventar.org/calendars/1020

「SQuBOK V2読破会」というクローズドなコミュニティの中でほぼ1年通して、
「ソフトウェア品質知識体系ガイド(第2版)」(以下「SQuBOK」)を読んできました。
活動の内容等は、12/1のいけどんさんのポストを参照いただければと思います。
http://swquality.jp/?p=178
IMG_20150711_135716

そんなコミュニティの中から「アドベントカレンダーやろうぜ!」ということでメンバ全員で書くことになった次第です。
個人的には、2013年の vimアドベントカレンダーのような事態になることを少しだけ危惧しましたが、幸か不幸か、そのような事態にならなそうなのでよかったかもしれません。
https://atnd.org/events/45072
※物足りなくなんて思ってないです、ホントに・・・(^^;

今回は、先日受験してきたJCSQEについて少し書いていきたいと思います。

2. JCSQEとは

2.1 JCSQEの概要

JCSQEとは、「ソフトウェア品質技術者資格認定制度」です。
http://juse-sqip.jp/jcsqe/
JCSQEは、”JUSE Certified Software Quality Engineer”の略になっています。
名前の通り、日本科学技術連盟が主催している資格認定試験です。
「ソフトウェア品質」と書きましたが、まれによくある例として、「ソフトウェア品質≒テスト」と考える方がいます。これは正しい理解ではありません。「ソフトウェア品質」は、ソフトウェア開発ライフサイクル全般に関係するものです。そのような理由から以下のような広い範囲から、JCSQEの問題が出題されます。
(※詳細は、JCSQEのシラバス( http://juse-sqip.jp/jcsqe/gakushu.html )参照)
・品質の概念
・品質モデル
・信頼性/ユーザビリティ/セーフティ/セキュリティ
・ソフトウェア品質マネジメント
・プロセスモデル
・プロセス改善マネジメント
・各種のスキル標準(ITSS/ETSS/UISS/CCSF等)と教育育成のマネジメント
・知的財産の法的権利と法的責任のマネジメント
・システムの構成管理(変更管理、バージョン管理、不具合管理、トレーサビリティ管理等)
・プロジェクトマネジメントとプロジェクトマネジメント体系
・要求管理
・設計のマネジメントや設計技法
・実装のマネジメントや実装の技法
・レビューのマネジメント
・テストのマネジメント
・運用のマネジメント
・保守のマネジメント
・メトリクス(プロダクトメトリクス、プロセスメトリクス 等)
・モデル化の技法(MBD,MDD,UML,SysML,PAD 等)
・テスト技法
・テスト自動化の技法
・品質分析、評価の技法
・障害分析に関する技法(バグ分析、ODC(直行欠陥分類)、なぜなぜ分析等)
・データ解析や表現に関する技法(QC7つ道具、新QC七つ道具)

このように、マネジメントからテクニカルな技法まで、要求から保守までと
非常に広い範囲から、またそれなりの深度は要求されていることが分かるかと思います。

さらに、JCSQEの試験区分は、2区分(初級と中級)があります。
初級は初学者向けということで、用語や概念の説明が中心になっております。
一方中級では、初級の内容に加え、技法や概念の業務への適用など応用力が問われます。問題の中で事例が与えられその事例に対応した改善内容を決められた字数で回答する(記述式)、といったような内容となっています。

(回答方式は、初級はマークシートのみ、中級はマークシート+記述式 となっています。)
問題のイメージは、以下のサイトにサンプル問題があるので参照してください。
http://juse-sqip.jp/jcsqe/gakushu.html

この試験ではソフトウェア品質に関する理解度や応用などについて知識やスキルが計られるものだと考えています。

2.2 JCSQEとSQuBOKの関係

JCSQEとSQuBOKには深い関係があります。JCSQEは、SQuBOKの内容をベースに出題されるからです。SQuBOKに記載されている内容(概念や規格(ISO,JIS,IEEEなど)、関連している著名な論文など)から、用語や定義を回答させる問題などが出題されます。
さらに中級でも、用語や定義・概念を問うような選択肢や用語を回答させる問題もありますが、そのような問題の比重は軽く、むしろ、考え方に重きが置かれています。つまり、実務に応用するための考え方が必要になるため、SQuBOKに記載されている内容だけでは不十分です。例えば、「レビューの改善案」や「開発プロセスの改善案」を回答する場合、解答そのものはSQuBOKには記載がないため、SQuBOKの内容をベースにして考えた内容を回答する必要があります。

2.2 JCSQEとJSTQBの違い

ソフトウェア品質に関わる試験として、「JSTQB(ソフトウェアテスト技術者資格認定)」(以下「JSQTB」)があります。
http://jstqb.jp/
JSTQBでは、シラバスを参照すると、テストプロセスやレビュー、テスト自動化というように、テストプロセスやテストの技法にフォーカスされているように思います。
そのようなことから、JSCQEのほうが、ソフトウェア開発工程全般にわたり広い範囲で、「ソフトウェア品質」を確保するためのスキルや知識が問われていると考えられます。
実際にテストを実務として行なっている テスト担当者、そのような部門のテストマネジャーはJSTQBのほうがマッチしており、テストに加えプロセス改善や規格や規準を検討する立場の人は、JCSQEにマッチしているように思います。

3. JCSQE受験記録

ここでは、2015年11月28日に実施されたJCSQEの試験について書きます。なお、筆者は、東京会場で中級を受験しました。

IMG_20151128_125858

 

3.1 雰囲気

ここ数回は、東高円寺の日本科学術連盟で実施していたように思うが、今回は有明の会場で実施されました。
人数はうろ覚えではあるが、250~300人程度の受験者がいたように思います。
マネジメントなどが試験範囲に含まれている影響なのか不明ではあるが、比較的ベテランの方が多く年齢層が高いように思いました。

3.2 問題とか

今回から第2版の範囲に変更になりました。つまり前回からベースが100ページほど増えてます・・・。第2版になり、「開発技術(マネジメント領域の拡充やモデル化、形式手法等)の追加」や「専門領域(ユーザビリティ、セーフティ、セキュリティ)の追加」などが行なわれいいます。
※初版と第2版の違いは以下の資料を参照ください。
http://www.juse.jp/sqip/symposium/2014/timetable/files/happyou_E1-1.pdf

今回追加された分野、セキュリティやモデル化などの分野からいくつか出題がありました。
記述問題では、コーディング規準に関する問題、開発プロセスの改善に関する問題、レビュー(ウォークスルー)に関する問題などが出題されました。

他には、リエンジニアリング・リバースエンジニアリングと知的財産権、コードクローン、品質の定義(狩野モデル)、調達のマネジメント、QMS、プロセスモデル(ウォータフォール、アジャイル)、PS(Partner Satisfaction)、費用便益分析、再利用、ソフトウェア信頼性モデル などに関係する問題があったように思います。

細かく書くと、どこからか怒られそうな気がしますので、キーワード的に並べておきます。

 

3.3 所感

私の業務から大きく外れることがないせいか、問題を読んで全く手が出ない問題はなかったと思っています。しかし、細かい記述の内容で思い出せないものがいくつかあってはがゆい思いをしました。「あのあたりに出ていた内容だけど・・・詳しく思い出せないorz..」と。
試験の合否は別として、JCSQEを受けることで得られたことがあると思っています。
普段業務だと半ばルーチン化してあまり頭を使わないプロセスであっても、本来考えるべき内容などに気づかされた点や、業務では担当でない部分の領域や知識を触れられたり、知ることができたことである。FMECAなど普段業務では使っていないがそのようなものの概要を知ることができた。
最後になったが、「SQuBOK V2読破会」に参加してきた影響も大きかったと思います。毎月開催される「SQuBOK V2読破会」に参加していたからこそ回答できた内容もいくつかありました。・・・継続的学習ってほんと大事ですね。

4. JCSQEの学習法

地道にSQuBOKを読む、業務でSQuBOKを利用して習熟度を上げるということが考えられれます。また、他の人と一緒に勉強することで、楽しくまた身につきやすいこともあると思います。
私が参加した「SQuBOK V2読破会」のような有志で勉強することも1つの方法であると思います。そのほかの例として、以下2点をあげます。
会社の支援が受けられる、かつ業務として早急に習得することが望まれているなら、
日本科学技術連盟のセミナーがあります。(別に回し者ではありません・・・)
http://juse-sqip.jp/juse_seminar/syokyu_2015.html

また、個人の活動であるなら、「SQiP SIG」として資格試験勉強と通して、ソフトウェア品質について理解するという集まりがあるので興味がある方はこちらに参加してみてはいかがでしょうか。

「試験を通して品質を学習する会」
http://juse-sqip.jp/sig/#shiken

5. さいごに

本稿では、本稿執筆の背景、JCSQEの説明や内容、勉強法法などについて書いてみました。
業務で品質保証に関わっている方でも、SQuBOKの範囲すべてを業務で使っている方は少なく、テストあるいはプロセス改善といった一部で業務を行なっている方がほとんどではないだろうか。業務は狭い範囲のスキルや知識でなんとかこなせるのかもしれないが、開発工程の他のプロセスの知識や技法を知ることや理解するも、自分の作業の質を高める上でも有益ではないかと考えます。
本稿で、JCSQEに興味を持ってもらえたり、SQuBOKに書かれているような
ソフトウェア品質体系に興味をもってもらえれば非常にうれしく思います。

※写真は、失意の中、試験会場から帰るときに撮ったものです。

F. 蛇足

当初、「不具合管理」について書くことを予定しておりました。期待していた方は、ほとんどいらしゃらないと思っていますが、(仮に、そんなレアな方が)いらしゃったらすいませんorz…
数回にわたる戦略的執筆が必要なようでしたので、予定を変更させていただきました。あと、先日試験が実施されたばかりなので「ホットな話題であろう」ということも考慮しました。
ところで、受験された方の復習会とか答えあわせ会とかやってみたいような気がしますけど、需要とかありますかね・・・?(^^;

 

SQuBOKユーザ会勉強会第17回に参加してきました

4/17(木)にSQuBOKユーザ会勉強会第17回に参加してきました。
ここ1ヶ月くらい忙しかったので久しぶりの参加でした^^;

SQuBOKユーザー会 第17回勉強会
http://kokucheese.com/event/index/161006/

今回のテーマは、「品質エンジニアのスキル育成&ソフトウェア品質管理の人的要素」でした。
今回は2人の方が発表しました。

はじめの発表者は藤沢さん。
SIer会社の品質保証部門に所属していて入社2年目の若手。
品質エンジニアは、広い範囲のスキルや知識を求められ、さらにテクニカルな面だけでなく、
対人面(交渉力、行動力など)も求められるが、どのように学んだら良いのか?といった疑問や、
SEなどと異なり、どのような道に進んだら良いか?(キャリアパス)について悩んでいたため
今回参加することにしたそうです。

発表の中で、以下の様なことを言っていました。

  • 品質エンジニアはモチベーションを保ちにくい
  • 成長がわかりにくいことも

藤沢さんの発表のあと、5グループについてディスカッションをしました。
議論のテーマとしては、以下の2点でした。

  1. 優秀な品質エンジニアとはどんな人物か?
  2. 品質エンジニアの育成にはなにが必要か?
    (人を育てる&自分が成長するために必要なもの)

テーマが難しいこともあって多くのグループは結論まで出せなかったものの
それぞれのグループでいろいろな意見が出ました。
1.では、「開発現場が気付かない問題を見つけてくれる人」「相手から問題を引き出す力がある人」
「現場にうまく伝えることが出来る人」などが上がりました。
また、2.については「人間的魅力」「データを揃えて納得させる力」「コミュニケーション能力、聞き上手」などがありました。
いずれも、一朝一夕にできることでなく、積み重ね続けることができることが重要だと思う、ということでまとめていました。

2人めの発表者は、堀さんです。
品質のお仕事をして16年というベテランです。プロジェクトに入り込んで、プロジェクト内の品質管理のお仕事をされているとのこと。
アンチパターン、これをやったら品質エンジニアは育成できない、という視点から発表をされました。
品質エンジニアのよくある失敗としては、「上から目線での指摘」「メトリクス(数値)だけで判定」「開発現場と敵対的に対立」といったことを
あげられました。
また、品質エンジニアのお仕事の1つにはプロセス改善がありますが、このプロセス改善が進まない理由として、
「現場が問題があると思っていない、問題がないと思っている」「自分のやることだと思っていない」
「改善は日々の作業ではなく、別のタスクを積まれるという、余計な仕事が増えたと思われてしまう」といったことを説明されていました。
「おもしろいからやる、というエモーションが大事」とまとめてくださいました。
会場からの意見としては、以下のようなものがありました。

  • 成長する気がないひとにどうすればいいか
    • 動機付けが難しい。どうやればいいか?
      • 文化が違う人との交流をつくる、とか。
      • いろいろな人と話したりして刺激を受けることが必要。
      • 相手に目標をもってもらうようにしむける。成長にも通じると思う
  • 教育を推進する上司や先輩が「育成しろ、成長しろ」というばかりで「鏡」になっていない。
  • 工場などのモノ作りの現場は、神様みたいな職人が身近にいるので、目標がわかりやすい
    • ソフトウェアはメンバそれぞれ違う。またお手本になる人を見つけることが難しいのではないか。
  • 改善が進まない理由として、外の世界を知らない、というのがある。
    • 大きな異動がない。
  • 評価されるということは、けっこうおおきなモチベーションになる
  • 育成する側は、本気で成長してほしい、と思って行動することが大事。
    • 自分の子供だと思って育成する

 

テーマが大きく、まとまった結論をだすのは難しいですが、いろいろ考えさせる内容で刺激になりました。
自分の今後のエンジニア生活にどう生かそうか考え中です。

中級ソフトウェア品質技術者(JCSQE中級)を受験してきました

11/30(土)に、表題の資格試験、中級ソフトウェア品質技術者(JCSQE中級)を受験してきました。
ここでは、受験の概要や自分自身への反省をかねて文章として残してみようと思います。

※公式サイト
ソフトウェア品質技術者資格 JCSQE|日本科学技術連盟  ( http://juse-sqip.jp/jcsqe/index.html )

どんな資格試験か

公式サイトには、「SQuBOK(ソフトウェア品質 知識体系ガイド)をベースとしたソフトウェア品質全般に関する知識を問う資格試験」と書かれているようです。また目的として「すべてのソフトウェア技術者が品質技術を身につけ、実践していくことにより、ソフトウェア品質の向上を実現すること」と記載されています。

この試験、公式サイトで見た方は分かるかと思いますが、初級と中級があります。

公式サイト「学習方法/出題問題解説」のシラバスをみると、初級・中級ともにソフトウェア品質全般を対象にしていますが、
初級は、基本的な知識を問う問題が中心であり、レビュー技法やテスト技法などについてはある程度の範囲でつかいこなせるレベルの
知識やスキルが要求されているようです。
対して中級は知識を問うというより、概念を理解した上で、問題解決に応用できる知識やスキルが要求されているようです。

初級と中級のちがいは、理解の深さ、などにあるようです。
過去の統計をみてみると、初級は過去10回開催さていて、合格率はだいたい38%くらい、
中級は、過去3回開催さていて、合格率は14%となっているようで、中級はなかなか狭い門ともいえそうです。

なお、JSTQB とはちがい、初級を受験していなくても、中級から受験することが可能です。
※JSTQBは、FL(Faundation Level)に合格しなければ、AL(Advanced Level)を受験できません。

ちなみに、JSTQB Advanced Levelも状況を与えられて回答する問題だと思うのでおもしろいかと思います。

所感

どんな問題かは、サンプル問題 が公開されているのでそちらをみると良いと思います。
初級はマークシートのみですが、中級はマークシート+記述なので、運だけでなく、理解度がかなり試されます(^^;

マークシートでは、選択式なので、基本的な知識を回答するような問題でした。いかにも資格試験という内容でした(^^;
記述式の問題ですが、こちらは、私個人としては、おもしろい問題だと思いました。
状況を説明され、その状況にあう施策や、改善案のようなものを決められた文字数(だいたい30字や50字など)の文章で回答するような問題でした。
状況も、突飛なものなどではなく、業務ではよくあるような状況です。自分ならどういう施策や改善を考えるか?と思いながら
回答してみました。・・・・落ちたらその回答はまちがっているということになるのかもしれません・・・(^^;;

勉強方法

資格の合否が、業務に直截係るものではないとしても、資格試験ですし、受験料も安くない(15000円程度)なので、合格したいものです。
初級は基本的な問題を問うものが中心なので、SQuBOKや問題集、副参考書に目を通せば対策になるような気がします。
中級は基本的な知識は初級と同じで、SQuBOKや参考書に目を通す、良いかもしれませんが、記述問題は知識だけでは難しいと思います。
SQuBOKの内容を理解した上で、普段の業務でのソフトウェア品質への取り組み、普段からどれだけ考えているか、が合否につながりそうです。

さて、中級は年1回しか開催されません。次回の試験の準備をしようかと思います(^^;;

第8回SQuBOKユーザ会勉強会で発表してきました

おそくなりましたが、4/18に日科技連(東高円寺)で行われたSQuBOKユーザ会勉強会で発表してきました。会場にいらしていただいた方々、Ustreamで視聴してくださった皆様、ありがとうござましたm(__)m

—-
SQuBOKユーザー会 第8回勉強会
http://kokucheese.com/event/index/85079/
—-

ちょっと時期を外した感がありますが、記録と振り返りをかねて書いてみようと思います。

はじめての発表

はじめの発表でした、2つの意味でです。1つはテーマ、もう1つは私自身がです(^^;
テーマについては、今まで、JaSSTのLTやポスターセッション、SQiPシンポジウムのSIGなどで
発表してきましたが、このようにプレゼン形式で内容を発表したのははじめてでした。
私自身についてですが、社外で発表したのは、勉強会などを除けば、初めてでした。
比較的軽い気持ち(?)で引き受けてしまったのですが、参加申し込みが38人と聞いいて更に緊張(^^;
就業後に、資料を作ったりと、少し大変でしたが、社内での発表とは別の意味で良い経験になったかなぁ、と思います。

当日の発表は、時間をオーバしてしまったせいで議論の時間が減ってしまい、すいませんでした。
あと、発表もそうですが、司会のような経験もなかっため、進行がダメダメでしたね。
参加前アンケートの回答のようなものを用意していましたが半分くらいしか出せませんでした。
この辺りは今後改善していこうと思います。

みなさまからのアンケート回答

お世話係さまより、勉強会後の発表に庵するコメントをいただきました。
ご意見をくださったみなさま、ありがとうございますm(__)m
多くの方からご指摘、ご意見を頂きました。これからの活動に取り入れていければと考えています。
実践的な話が聞きたくていらしゃったかたすいません。今後に期待していただければ・・・とおもいます。
あと、声が小さくて聞こえづらかったというご意見も、今後改善していきます。

謝辞

資料に関してご指摘ご意見を頂いたコミニティのみなさま(特に森崎先生、近江さん)ありがとうございました。
発表前の緊張しているところにtwitterやFacebookなどでメッセージ頂いた方々、ありがとうございます。
皆様のご支援はとても支えになりましたm(__)m

その他

初めての発表だったので、写真をとってもらえばよかったかなぁ、とか(ぼそ
Ustreamではどんなようにみえたかとっても気になります(^^;

読書録:価値を増幅させ、繋がりを極めよ

猫珠求聞史紀

こんにちは! @nekoasukaです。

最近読んだ本から読み取った事をまとめます。
最近読んだ本はこちら↓

『わかりやすいアジャイル開発の教科書』

アジャイルという言葉に対しては、本当に多くのエントリが公開されています。
この言葉を、自分の言葉で言い換えたいと思い、本著にも手を伸ばしました。

内容を圧縮すると、
『価値の最大化を図るために、人との繋がりを大切にせよ。』
ということ。

さすがに圧縮しすぎな感があるので、3つだけトピックを取り出してまとめます。

1.変化にネガティブなイメージを持たないこと
仕様変更を筆頭に、”変化”が起きるという事を嫌うプロジェクトは多いです。
※私が体験してきたプロジェクトはすべて、”変化”をネガティブに捉えるプロジェクトでした。

変化する事がネガティブに捉えられる理由は、端的に言えば『面倒だから』。
変化することで…
・予定を立てなければならない。
・資料を作成しなければならない。
・確認や承認の作業をこなさなければならない。
と、よくあるプロジェクトでは作業が増えて見えます。
それぞれに対して誰が、いつまでにやることと表形式でまとめられており、
遅れると色が変わったりしてくるわけです。

…いい気分になりようがありません。

仕事だから仕方のないこと、仕事に気分を持ち込むな、という方は多くいます。
しかし、その変化はよりよい結果へと向かう過程で起きたことではないのでしょうか?
例えば今動かないものが、動くようになったのではないのでしょうか?
例えば業務改善に直結する機能が、追加になったのではないのでしょうか?

それは、ソフトウェアが少し素敵な方向へと進んだ結果とは取れないでしょうか?

変化を喜び、より良い方向へ”プロジェクトの仲間全員で”進めていく方法をこの本では薦めています。

2.プロジェクトにペースメーカーをつけること
締め切りありきで大概の仕事は進みます。
それまでの間は、大雑把に切り分けた作業に得意な人を割り当て、淡々とこなさせ続ける。
そのような開発をやってきました。
締め切りが断頭台のように見え、シワのよる作業だけがゾンビのように絡みついてきました。
気付けばプロジェクトの仲間は皆、ゾンビのようでした。

”鼓動”がないのです。

淡々と、真っ直ぐな心電図のように”行軍”するその様は、ゾンビのようでした。
活発さなんてあるわけがなかったのです。

プロジェクトに”鼓動”を与えるために、この本ではペースメーカーをつけることを必須としています。
固定期間でプロジェクトの時間を切り分けておくのです。
その時間内にできる作業量へと分割し、こなしていくという方針です。
固定期間でこなせる量は、そのプロジェクトの脈拍を教えてくれます。

3.ギャップは対話で埋めていくこと
要求と納品物のイメージとには、入れ違いや思い違いがあるのが常です。
納品までに解消されなかった”ボタンのかけ違い”は、不幸を呼ぶことがほとんどです。
不具合だ、バグだ、瑕疵だと叩くお客様もいらっしゃることでしょう。
それに反して、あれだけ注意したのに、聞いていないほうが悪いとイラつく仲間もいたことでしょう。

それらは、”紙の上で戦争をした結果”ではありませんでしたか?

”紙の上の戦争”は所詮”紙の上の戦争”です。
戦争ですから勝敗があり、どちらかが我慢をし、疑問を抱えて倒れた時もあったはずです。

大量の印刷物を押し付けて、『~についてよろしいですか? ・・・では次に』
といった姿を見ると、城壁の上から歩兵へ向かって大岩を落としているかのような気分になります。

ギャップは紙では埋まりません。
多少は埋めることができますが、やはり止まった言葉では”今のあなたの生きている頭の中”を表現しきれないのです。
対話をしましょう。
その結果を、シンプルな止まった言葉で表しましょう。
そういったことが、この本には書いてあります。

以上が、私が 『わかりやすいアジャイル開発の教科書』を読んで感じたことです。
このエントリが、どなたかの目と心に留まることを祈って。

元の投稿を表示