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回しか開催されません。次回の試験の準備をしようかと思います(^^;;

【JaSST13Tokyoメモ】 「過失に着目した欠陥のモデリング~バグ分析はなぜうまく行かないのか?~」

だいぶ遅くなってしまい、かなり時期を外した感がありますが、
2013年1月30日~31日に行われたJaSST13Tokyoのセッションに参加した際のメモをまとめてみました。

当日の講演資料は以下のサイトで公開しているようです。
http://jasst.jp/symposium/jasst13tokyo/pdf/C4.pdf

不具合分析

不具合分析は多くの組織で行なわれているが、効果が出ていないのではないか。 近年、ソフトウェア開発は大規模化、複雑化している。

  • 一人ですべてを把握できない
  • 全て範囲をテストできない
  • 複雑度の増加
  • 組み合わせ数の爆発

そういった中で、バグとどのように立ち向かう、または扱っていく必要があるか。

「ワナ」

「ワナ」にはまることを繰り返さないようにするために、モデル化が必要

  • 「開発者が埋め込んでしまう「ワナ」→開発プロセスで何があったのか?
  • 品質担当者が見逃してしまう「ワナ」→テスト工程で何があったのか?

なぜ不具合分析がうまくいかない理由

バグ分析の失敗要因

  • バグ分析の目的が明確でない
  • バグ票に必要な情報がない
  • 事実認識が甘すぎる
  • なぜなぜ分析で論理の飛躍がある
  • 失敗事例が共有されていない

なぜなぜ分析がなぜ失敗するのか?

  • 分析することにどんな意味があるか理解していない。 (なぜ、なぜなぜ分析はなぜ5回なのか?4回や6回でない理由は?)
  • なぜなぜ分析結果を受け取る人の喜びそうな分析結果にしてしまう

なぜなぜ分析ではなく、なになに分析を行なう。

  • 「なぜなぜ分析」と「なになに分析」の違い
    •  なぜなぜ分析:人の責任と現象を同時に追求
    •  なになに分析:人と現象を分離させている
  • 「なになに」は、現象そのものに好奇心があることの強調する

バグの話をしていると暗い雰囲気になる

  • 暗くなるように分析している限り良い方向にはならない
  • ニュアンスが大きい

バグは資産

バグは、組織にとって資産である。

  • 同じバグは、他のプロジェクトなどで再現できない
  • バグは、保存し、共有し、語りつぐべき資産である
  • ワクワクして獲得するものである

アンチパターン

分析におけるアンチパターン

  • 現象と原因がごっちゃになっている
  • 「うっかり」、「きちんとできない」 etc その時何があったか、を分析していない
  • 決め付け、犯人探しになっている 他人ごとだったり、根本解決にならない
  • 「設計の問題」 設計でどんな問題が起きているか踏み込んで考える必要がある
  • テスト漏れ 何がどう漏れたのか? テスト網羅はどんな状態であったのか?

対策におけるアンチパターン

  • チェックリストに項目追加
  • 全体会議で周知する 継続した周知は無理。異動してきた人や新人の対応はどうするのか?
  • 教育や研修 誰に対して、どのような教育をすべきなのかを考える必要がある。
  • 文化の醸成、属人性の排除、適した人をメンバに追加 そもそも、コントロールできるか?

QA部門について

QAが指摘できる内容は少ない。指摘のレベルも深刻なものは多くない。

  • 品質技術が高いとはどういうことか?
  • どのようなQAならリスペクトされるのか?

QA部門が上のことを考える必要がある。 技術のウデとしてどうるべきか

対策編

どのようなバグを減らしたいのか。 →バグ分析の目的の共有、合意、優先順位付け 事実をヒアリングでとらえる 原因追求は、なぜなぜ分析 対策は、なになに分析 自責と他責は分けて考え、多くの仮説を作る 視点を変えていく →バグによってかえる バグの水平展開(同僚や製品グループへ) →必ずしも全社単位でなくても良い なぜなぜ分析 →なぜの間の「線の意味」を考える 「なぜ」でないことがある 本来、「原因→結果」となるが、「なぜ」でないとループしてしまう うまくできていないところはループする →「結果→原因」になっていないから 「欠陥がどいう経緯で作られたか?」を考える。

  • 思考の過程に「過失」があった
  • ソフトの欠陥は、必ず人間の副産物
  • 「人間がどう思考をミスったか?」「バグが入り込む余地があったか?」
  • 欠陥とバグ(過失)をセットで。

ソフトウェアの故障モード

  • バグの入りやすさ、誤りの入りやすさ

「だれでも間違える」という認識が重要

  • 「優れたエンジニアでも吸い込まれるようにまちがえてしまうのはなぜか?」を考える
  • 「不具合はだれでも起きた」ということを合意する。 どんなに気をつけていてもミスしてしまうような ワナがある。
  • そのワナを明らかにする ために「なになに分析」を行なう。
  • 間違えた人を、「ワナのありかを提供してくれるありがたい人」として扱えるようにする必要がある。
  • 全員がワナに共感することが必要
  • だれでも間違えるところを一緒に探しに行こう、という姿勢が大事。
  • 個人による誤りではなく、人間一般のあやまりをさあす。
  • 欠陥は過失 →誰々の過失、ではない。 →そこにいる人全員が共感してあたかう必要がある
  • ワナを公開しないと対策にならない
  • バグを前提とした社会 →バグが有ることを受け入れない
  • 憎むべきは「誤った人」ではなく、「バグそのもの」
  • バグが生まれる経緯の過失を公開する →落とし穴にはまらないようにする
  • バグの種類と、どう誤るのかをセットで覚える パターンとして自分たちに蓄積していく バグそのものをシェアする。
  • どのように吸い込まれるかを覚える

欠陥モデル

欠陥モデルは、欠陥知識の移転と理解が早くなる。モデル(絵)でバグの状態を伝える →欠陥知識を伝えることが難しくなっているところをわかりやすく伝える。

  • 誘発因子(ワナ)
  • 過失因子(引っかかる人間の要素)
  • 増幅因子(拡大した理由)
  • 欠陥
  • 表出現象

誘発因子をレビューやテストで引っ掛ける努力をする

過失因子で共感しやすくする

抽象度をあげると多くの範囲で伝えられる
→自分たちで抽象度をきめて移転の範囲をきめる

ご参考

プロジェクトファーブル http://aster.or.jp/business.html#fabre

原さんの「なになに」はもう一度お聞きしたい・・・(ぼそ

(2/3(日)) コミティア103に参加します。

2/3(日) に東京ビックサイトで開催されるコミティア103に参加します。(ただし、知り合いのサークルのお手伝い・・・)
このイベントでは、今までの活動内容のまとめ、森さまより寄稿頂きました「ODC分析(直交欠陥分類法)」についてまとめた冊子(「バグ票について考えよう!」)を頒布いたします。

バグ票本表紙表紙です^^;

※今回は印刷所に依頼しました。以前頒布しました内容とほぼ同様の内容となっております。ご注意ください。冊子の概要についてはこちらの 2012年8月の活動の辺りをご覧ください。

もしかしたら、先着20名分くらい特典グッズを付けられるかも・・・しれません。

イベント当日は、以下のスペースでご来場をお待ちしておりますm(__)m

2/3(日) 東京ビックサイト 11:00~16:00
東5ホール な21b サークル:品質公団

品質公団では、既刊の本を頒布するようです。内容詳細については品質公団公式ページをご参照ください。よろしくお願いいたします。

 

(1/30~31)JaSST’13 Tokyoに参加します。

1/30(水)~31(木)に目黒雅叙園にてJaSST’13 Tokyo が開催されます。 詳細は以下のサイトを参照してください。

開催概要 http://jasst.jp/symposium/jasst13tokyo.html

セッション概要 http://jasst.jp/symposium/jasst13tokyo/details.html

個人としては聴講だけですが、私が関わっているバグ票コミュニティ(バグ票ワーストプラクティス検討プロジェクト)がLT(Lightning Talks)で発表します。今までの活動内容や今後の方針などについて発表いたします。 LTの概要等はこちらを御覧ください。

興味ある方その他の多くの方々のご来場をお待ちしております。

※来年は発表者側で参加したいなぁ・・・(ボソッ

 

2013/1/29 08:30追記

1/31(2日め)は、当日券の発売があるようです。急に予定が変わり時間があいた方などは是非♪
http://jasst.jp/symposium/jasst13tokyo/query.html#charge