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…
数回にわたる戦略的執筆が必要なようでしたので、予定を変更させていただきました。あと、先日試験が実施されたばかりなので「ホットな話題であろう」ということも考慮しました。
ところで、受験された方の復習会とか答えあわせ会とかやってみたいような気がしますけど、需要とかありますかね・・・?(^^;