2015-09-02 18.56.46.jpg 長崎IT技術者会の勉強会として,新たに「マインドマップ本読書会」が企画され,その第0回が実施されました。

 ★第0回マインドマップ本読書会
  http://nagasaki-it-engineers.connpass.com/event/18001/

 この勉強会は『初心者かつ20代のエンジニア限定』を対象としています(実際には,テスト技術分野の初級者であればOK)。「ソフトウェアテストのいろはを知りたい」「テストの基礎から勉強したい」「テストの勉強を始めて間もない」という人たちで集まって,本の読破&日々のテスト業務の改善をめざす勉強会ということです。

 筆者はというと,著者の一人ということで,予定が合うときには顔を出し適宜議論に加わるといったオブザーバー的な立場でご協力させていただきます。

当日は藤沢さん+参加者4名+筆者の計6名が集まりました。

 まず最初に発起人である藤沢さんから挨拶があり,各自の自己紹介がありました。
エンプラ系やWeb系,組込み系と分野がばらけており,また,今年の入社したばかりという方もおられ,バラエティに富んだ構成となったようです。議論にも幅が出そうですね。

 次に藤沢さんから「マインドマップ本」の概要について,解説がありました。
本の概要や各章ではどんな内容が取り上げられているのかという内容です。マインドマップ本を読むのはこれからという方々なので,読書に入る前に全体の概要を捉えられたのは良かったのではと思いました。質疑の時間もとられましたが,なにせ皆まだ読んでいないので,質問もほとんど出ませんでしたが,勉強会の会を追うごとにきっと活発になっていくのだろうと思います。そこにメンバの方々の理解具合というのが表れてくるのだと思います。

 その勉強会の今後ですが,どのように進めていくのかが話し合われ,藤沢さんから3つの案が出されました。

  • 案1:特に事前の準備なく,集まって輪読して議論
  • 案2:事前に読んできて,当日議論
  • 案3:内容を要約したスライド使って,解説&議論

 もちろんこの3つ目が一番効果はありますが,準備の工数も少しかかるということになります。

 議論の結果,基本的には案3をベースとしつつ,手を動かす時間も設けることとなりました。

  •  第II部(3章から9章)を読書会の対象とする
  •  各章の担当を決めて,その人が内容をスライドにまとめ,当日解説する
  •  当日まとめ担当ではないメンバも事前に該当の章を読んで議論したいリストを作っておく
  •  時間は2時間とし,前半をスライド解説&議論,後半を手を動かす&議論とする
  •  後半のためのテストベースは別途選定
  •  全6回として10月から3月まで,ひと月に一回集まる

 どうせやるならばしっかりやろうということになりました。

 さて,ここまで決まったところで,まだ40分ほど時間が残っていました。
さすがにこれで終わるのはもったいないよなぁと思ったので,次回からマインドマップも書くのだからそのおさらいをしておきましょうと,急きょ,筆者から昔の資料を使って30分ほどの講義をさせていただきました。「発想とは」「マインドマップとは」「マインドマップをソフト開発で使った時の効果」「コミュニケーションツールとしてのマインドマップ」「デジタルツール」といったあたりをさらりと解説しましたが,おさらいになっていればいいなぁと思います。ちなみにこの講義の内容自体がすでに書籍当時と今とでの記述上でのギャップということでもあるかもしれません。筆者自身,当時からは語れることが多くなっていることを実感しました。本の発売から随分たつわけですが,こうして勉強会を企画くださったことへ何か少しでもご恩返しができればとの想いからでしたが,少しはお役にたてていればいいのですが。

 講義が終了したところでちょうどお時間になりましたので,第0回は終了です。

 その後の懇親会では,引き続き議論が盛り上がりました。筆者は都合により早めに中座させていただいたのですが,いい会になりそうだなぁと想いながらの帰路でした。

 以上,第0回マインドマップ本読書会をまとめてみましたが,とても良い会になりそうで,今後が楽しみです。

 レポートも第7回目となりました。今回はクロージングトーク&クロージングの様子をレポートします。


 クロージングトークは予定では清水さんと筆者にて派生開発やUSDMについてその未来を語るというものでしたが,当日はこの内容は使わず,議論ができなかった「V字モデルのテスト工程のインプットがUSDMだったときに慌てないために」のディスカッション部分として実施することになりました。

長崎QDG2015_150812_164055.jpg 「V字モデルのテスト工程のインプットがUSDMだったときに慌てないために」では後半に「そもそもV字モデルでいいのか,本来のXDDPでのテストとは?」というテーマでディスカッションする予定でした。これについて,実は当日までにメールで清水さんと筆者で議論をしていました。これを受けて,まず最初に清水さんからXDDP提唱者の立場から,解説をしていただきながら議論することとなりました。その要点としては以下です。

  • XDDPではテストを語らないわけではなく,それ以前に品質を作りこむことを重視している
  • テストに必要な情報は変更要求仕様書を工夫することで盛り込める
  • 例えば,TMの列にテスト仕様書を加えるのもありだろう
  • さらに,テストモジュールやテストケースを加えたってよい
  • テストに必要な情報があるのであれば,それはテストチーム側から提案すべき
  • テストベースやテストウェアも派生開発の対象であることをテストチームが認識し,テストチームにより開発することが大切
  • XDDPに提案があれば是非! etc...

 ディスカッションと言いつつ,半ば清水さんに話を聞く時間となってしまいましたが,とても気づきが多く,各自熱心にメモをとっている姿が印象的でした。


 さて,結局最後まで時間が押し押しになってしまったわけですが,この一日を締めくくるクロージングの時間となってしまいました。なにせ会議室を返却する時間の10分前まで押してしまったので主催者としてはヒヤヒヤだったのですが,ここまで盛り上がってくださったことに大きな感謝の気持ちでした。

長崎QDG2015_150812_165602.jpg クロージングでは「今日勉強したことを月曜日から実際に生かしてください」とお願いさせていただきました。勉強会イベントに参加して頭でっかちになってしまうのはとても良くないことで,やはり現場で実践してナンボという感覚を持っていただければと思います。新しい工夫というものは実践するなかで生まれるものです。このレポートを掲載されるときには各自がなんらかの形で実践し,新しい工夫や技術を生み出していることを願っています。そしてそこで生まれたものを来年の長崎 SW Quality & Development Gathering に還流していただければ幸いです。

 おっと,「来年の長崎 SW Quality & Development Gathering」と書きましたね。

 もちろん来長崎QDG2015_150812_165820.jpg年もやります。同じ形態になるのか,はたまた全然違う形でやるのか,半日なのか終日なのか,しれとも合宿形式になるのか,まだわかりませんが,やることだけは決めています。

 現在,2016年10月7日を候補日としていますので,是非来年に向けてご予定いただければと思います。また,スタッフや登壇者としてご協力いただける方がいらっしゃいましたら,是非お力をお借りできればと存じます。よろしくお願いします。


 以上で,全7回にわたったレポートは終了となります。すべてをお伝えできたとは思いませんが,少しでも当日の熱気が伝わったらと願わざるをえません。ここまで読んでいただき,感謝申し上げます。

長崎QDG2015_150812_122738.jpg

 レポートの第6回目です。

 今回はコミュニティアピールセッションの様子をレポートします。コミュニティアピールセッションとは,休憩時間に実施されるレストタイムスライドショーセッションの資料を使って2分間アピールをするものです。(本記事掲載の写真は各発表者の許可を得て掲載しています)

長崎SWQuality&DevelopmentGathering2015 レストタイムスライドセッション スライド集



 今回は次のコミュニティから投稿をいただきました。
  •  長崎IT技術者会
  •  バグ票ワーストプラクティス検討プロジェクト
  •  九州ソフトウェアテスト勉強会

長崎QDG2015_150812_163235.jpg 「長崎IT技術者会」は本イベントの主催元であり,Facebookグループで活動中です。長崎に縁があったり興味があれば参加できるとし,長崎にこだわらず全国各地で勉強会を開催しています(県外開催の場合は,冒頭に長崎の宣伝つき)。

 これまでに東京地区でマインドマップによるテスト分析設計勉強会やISTQB-AL勉強会など5回の勉強会を実施,イベント後にも9/2に第6回を開催予定です。また,年に一度以上は長崎でもイベントや勉強会をやっていきたいので,現地の方のご協力をいただきたいとしました。


長崎QDG2015_150812_163316.jpg 「バグ票ワーストプラクティス検討プロジェクト」は鈴木しょうごさんによるアピールでした。

 悪いバグレポートがどのようなものかを共有し改善することで,ソフトウェア開発組織の問題解決や改善をしたいという想いを持っているコミュニティだそうです。これまでにSQiPシンポジウムやJaSSTでの発表活動に取り組んでいらっしゃいますが,今後はガイドの整備などさらに有益な活動としていきたいとのことです。

 バグ票の品質によりその後のデバッグの効率は大きく変わります。ソフトウェア開発においてとても重要な物のひとつであるので,今後に注目です。


長崎QDG2015_150812_163634.jpg 「九州ソフトウェアテスト勉強会」は福田里奈さんによるアピールでした。

 福岡にて活動しているソフトウェアテストの勉強会コミュニティです。2013年にコミュニティを設立,現在は190人で活動中という九州内では大規模なコミュニティです。勉強会はメンバーからの事例発表などを始め,来福された識者をゲストに迎えるなど,大きく盛り上がっているようです。これまでにPictMasterやテスト設計,バグ分析等,多様なテーマを取り上げていらっしゃいます。

 今後も勉強会を企画していくので,是非参加くださいとのことです。長崎の技術者も是非足を伸ばしてみてはいかがでしょうか?


 その他,公開しているスライドにはありませんが,JaSST'15Kyushuの宣伝もありました。来る2015年10月9日に富士通九州R&Dセンターにて開催される予定です(http://jasst.jp/symposium/jasst15kyushu.html)。長崎からは電車やバス一本なので,是非積極的に参加いただき,情報を現場改善に生かしていただくと良いのではと思います。


 以上,コミュニティアピールセッションのレポートでした。様々な地域に様々なコミュニティがありますが,それらについて情報を得るのは結構大変です。こういったセッションがきっかけで情報を入手したり,連携をとるきかっけになるといいいなぁと考えています。



 レポート第5回目です。

長崎QDG2015_150812_155321.jpg 株式会社ウェブレッジ 浦山さつきさんによる「テスト自動化の現場から」の様子をレポートします。(本記事掲載の写真やスライド画像 は浦山さんの許可を得て掲載しています)

 浦山さんは第三者検証会社であるウェブレッジに所属し,エンタープライズ・金融系システムのテストを対象にテスト設計や自動化,マ ネジメントや教育に取組んでいらっしゃいます。また,テスト自動化研究会やテスト設計コンテスト出場チームであるしなてすに所属,システムテスト自動化標準ガイドを共訳されるなど多方面で活躍されています。このセッションではテストを自動化したシステムの紹介と自動化あるあるについて解説いただきました。

テスト自動化の現場から~テスト自動化の保守の話~ from Satsuki Urayama


 自動化したシステムの紹介は「店舗情報ポータルサイトの品質管理業務」と「顧客管理システムのテスト」2つでした。

自動化の現場から_2.PNG自動化の現場から_1.PNG 「店舗情報ポータルサイトの品質管理業務」は,約60万軒の店舗情報を扱うWebサービスについての事例です。品質管理部は会亜h粒に対 してリリース判定やコンテンツの機能障害検地,リンク切れチェックや記法・非機能の確認といった業務をサービスとして対応していましたが,ユーザーが増えるに従い人手で行うのが困難になってきました。そこで,それらを自動テストという手段を使って改善したという事例でした。

 「顧客管理システムのテスト」は,数千万人の顧客情報を取り扱うクライアントシステムについての事例です。システムテストチームにテスト自動化チーム(10名)を設け,システムテストをスコープに回帰テストの自動化と自動テストの運用を実施したとのこと。2005年の 新規開発から2011年まで,運用し続けたそうです。

 大規模なシステムでは,きちんとテストチームを作り運用すること,自動化の促進や自動化されたテストの継続的な実施が大切なことだ と受け取りましたが,継続し続けられるのも自動化して俗人性が低くなっているからこそと思います。


 次にその二つの事例の経験から自動化あるあるが解説されました。

自動化の現場から_3.PNG自動化の現場から_4.PNG自動化の現場から_5.PNG 「あるある1 自動テストの認知度が低い」では,二つの事象が解説されました。「事象 急に動かなくなる自動テスト」は,ソフト修 正の情報が自動化チームに伝わらずに自動化したテストが大量に失敗するというもので,これの対策は「伝達体制の強化と回避策の規定」 とし,(自動化チームが)把握できていない箇所で問題が起きたときの回避策を用意しておくことが大切と解説されました。「事象 チケ ットの後回し」は,報告した不具合が改修されている雰囲気がないが同時期に報告した他のチームの不具合は回収されているというもので ,これの対策は担当者だけではなく上層部からの連携や認知されている部署への協力を仰ぐことが必要と解説されました。

 「あるある2 構造化されていないスクリプト」。「事象 修正が追いつかない」は似たようなスクリプトが多すぎるというもので,対 策として「スクリプトの構造化」が有効とし,スクリプトとパラメタタ部分を分けて管理すると良いと解説されました。

 「あるある3 サーバのパンク」。「事象 画面キャプチャでログサーバーがパンク」について,対策として「キャプチャ取得や保存タイミングの整理」が必要とし,エビデンスやログの解析に不要な画面キャプチャの削除や過去ログの保存ルールを決定するのが良いと解説されました。

 「あるある4 ほったらかしのテストケース」。「事象 テストしていないところからのバグ発見」は,テストの保守を怠った結果,テストケース以外の個所からデグレードを発見したというもので,対策として「テストの草刈り」が必要とし,テスト自身の保守(テストケ ースの追加と削除)が大切であるとしました。

 「あるある5 担当者の撤退」。「事象 主担当者が抜けたら自動テストが回らない」は,数年来の担当者がプロジェクトを抜けたが, 他者への一時的な引き継字によって自動化が途絶えてしまったというものです。これの対策は「担当者同士での引き継ぎをしよう」という ものですが,後継者と十分な引き継ぎ期間が必要であったり学習コストを下げる工夫が必要と注意がありました。


 浦山さんからは,最後に「自動化も保守が必要です。」という話があり,『テスト自動化標準ガイド』から7章の「保守性の高いテストを構築する」が参考になるという紹介がありました。

自動化の現場から_6.PNG テストの自動化は派生開発においても重要な関連技術の一つです。派生開発における一つの改造や機能追加がもともと動いていたシステムに影響を与えることを即座に検出することができなければ,派生開発はうまくいかないことでしょう。ひとつ前のセッションで「テストケースも派生開発の対象」という話がありましたが,自動化されたテストもまた派生開発が必要で,このセッションにおけるテストの保守とつながります。これから自動化に取り組む人は,このセッションで紹介された「自動化あるある」を参考にすることが,有効な自動化を実現するための最初の一歩となるであろうと思いました。


 派生開発に限らず,新規開発においてもテストの自動化はとても重要です。ただし,自動化技術の導入はそう簡単な物ではありません。基礎となる記述がないままに自動化に取り組むとコストが見合わなかったり失敗してしまったりということも起こりえます。そこで,ウエブレッジさんなどの自動化エキスパートが所属する企業に協力していただき,自組織の自動化スキルや仕掛けの高度化を図っていくことも大切なのではないかと思いました。最初のドライブさえうまくいえば,その後はそれで得た技術で時組織改善が計っていけると思います。

 折角地元でイベントを開催したのですから,筆者自身も何か技術を紹介したいという想いがありました。自身が主催するイベントとで自身がしゃべるというのはマッチポンプも過ぎるのではという考えも一瞬よぎったのですが,なかなかない機会でもありましたし,時間の調整セッションも必要だと自分を納得させしゃべることにしました。自身のスライドを簡単に解説します。(過去のBlog記事を改編して作成しています)

V字モデルのテスト工程のインプットがUSDM形式だったときに慌てないために from Ikedon

 イベントのテーマである「派生開発」それと,清水さんが「USDM」について講義下さっている,「テストの立場に立ったセッションも入れたい」といういうことで,こういったタイトルに落ちつきました。


V字モデルのテスト工程の_セッション内容.jpg USDMについてはすでに清水さんの講義で理解をしているはずです。また,XDDPについては藤沢さんの発表にて概要が紹介されています。これらを前知識として利用させていただくことにしました。どちらもあるべき姿に立って語られていますので,このセッションでは「そうはいっても現実いびつな状況ってあるよね」という(生臭い)現実側に立ってみました。

 もしあながたテストチームのテスト担当者だったときに,なんの前触れもなく「今回の開発はXDDPなので,仕様書はUSDMです」と言われ,面食らったときにどうなるか?ということですね。ただし面食らったとしても,テストはしなければなりません。納期は迫っているのです。

 こうした理想と現実の差を認識してもらい,ディスカッションにより,どのように差を埋めるか,この状況からどう抜け出すかを具体的にイメージしてもらうことがこのセッションの目的として設定しました。こうして,前半10分でスライドをお話しし,残りをディスカッションという構成とすることにしました。


V字モデルのテスト工程の_XDDPにおけるテスト.jpg 前知識と書きましたが,「XDDPにおけるテスト」についてはこれまでのセッションでは語られていません。ですので,おさらいとしてXDDPにおけるテスト,を簡単に整理します。

 まず,清水さんのXDDPの本の索引を見てほしいのですが,「テスト」についてはほとんどキーワードがありません。また本文を参照してみてもキーワードが出てくるくらいで,テストについては具体的に書かれていません。そう,XDDPの本にはテストについてはほとんど書かれていないのです。

 これには理由があります。本来,XDDPは実装までに品質を作り込むことを重視する(というか作り込まれる)ためだだからです。テスト工程ではバグはほとんど出ません。故にテストについての記述は少なくなります。考えてみれば実に当たり前であるわけですが,Vモデルの呪縛(!)にとらわれていると,Vモデルの左側である開発工程にXDDPを当て,Vの右側はそのままという導入の仕方をしてしまいがちです。特にQA部門によるプロセス監査などが厳格であればあるほどその傾向があるように思います。また,テストチームが自身でテストプロセスを設計できない場合,そうなりがちです。

 本来はテスト工程もまたプロセス開発しておく必要があるのですが,それをしないまま,テストに取り組もうとしているのが現実として多いというわけです。

 こういった現実について,もちろん最初からXDDPを綺麗に入れ直すということが理想なのですが,すでに進んでしまっている今回のプロジェクトでは当座をしのぐために,いびつとわかりつつも対処対応することが求められます。


V字モデルのテスト工程の_XDDPにおけるテスト要請.jpg もう少しシンプルに考えてみましょう。派生開発におけるテストへの要請は主に3つです。

  1. 変更箇所をテストする
  2. 影響箇所をテストする
  3. 全体としてデグレや非機能劣化がないかテストする

 このとき,XDDPやUSDMに慣れていないと,最初のステップである「1.変更箇所をテストする」でいきなり躓くことになります。

 新規開発と異なり,変更に注目してテストを実施します。XDDP(派生開発)の場合は,すでに動いているソフトやシステムが存在しています。新規の機能の集合体である新規開発と異なり,変更に注目してテストを実施するというスタイルになりますし,その要求や仕様がUSDM形式の変更要求仕様書で送付されてきますが,それにも慣れていません。

 慣れていないことが重なるわけです。

 こうして本を参照するわけですが,そこに求める解は書いてありません。

 こういったいびつな事態に直面した場合,どうすれば良いのでしょうか?


 理想的にはプロセス設計し,すでに定義済みのXDDPのプロセスと接続するのがよいでしょう。ただし,多くの場合,そういった時間はテストチームには残されていませんし,プロセス設計できるメンバが存在するかもわかりません。なので,いびつとわかりつつVモデルの右側そのままにテストを乗り切るこという対応を取らざるをえません。そうしてなんとか当該プロジェクトを乗り切ることになります。そして次のプロジェクトではその失敗を生かせば良いです。ただ,大きな組織になればなるほど厳格な設計規格が存在し,それを変えることが難しいです。変えるまでに1年を越えることもほとんどでしょう。その間はいびつな対応とわかりつつも,それでうまくやらざるを得ません。

こういった状況における,最初に装具する「慌てポイント」を4つ取り上げています。

  • 慌てポイント1:そもそも慌てない
  • 慌てポイント2:どこのインプット?
  • 慌てポイント3:どこのテストレベル?
  • 慌てポイント4:情報が足りません

どれも当たり前だよなという話なのですが,実際,現実として初めて遭遇したときに例外なく慌てます。なにぜならば,テスト担当者全員がXDDPやUSDMを知っているわけではないし,実戦経験があるわけでもないからです。


では,慌てポイントの1つ目です。

V字モデルのテスト工程の_慌て1.jpg 「そもそも慌てない」ということですが,要するに「心の準備ができていない」ということです。

 ある日送られてきた設計仕様書の形式がこれまでと大幅に異なっていたら,誰もが一瞬の時間を要します。それがWordによるリストタイプの物が,Excelによる階層表記の物になっていたらなおさらです。

 USDMでの階層表記は当たり前として,要求が階層になるとか,範囲があるとか,Before/Afterで書くとか,理由があるとか,TMがついているとか,・・・etcとなると,初見でサラリと読めというのは高い要求です。しかもテスト担当者はこれをつくったこともないわけですから。

 そうすると,やはり最低限「見たことはある」という状況にまずは持って行く必要があります。

 何ができるでしょうか。それは,書店に行ってUSDMの書籍を買ってくることです。半日もあれば,(USDM自体の深い理解は難しいとしても)中身を読むこと位はできるようになります。そうすれば,少しは落ちついて対応することができるようになるでしょう。


 慌てポイントの2つ目です。

V字モデルのテスト工程の_慌て2-1.jpgV字モデルのテスト工程の_慌て2-2.jpg 変更要求仕様書を受け取ったときに,それがどのテストレベルへのインプットなのかがわからずに慌てる場合があります。

 新規開発におけるVモデルの場合は開発工程のアウトプットがどのテスト工程のインプットになるかが明確です。ところがXDDPを無理矢理Vモデルに統合してしまうと,左側と右側の対応関係がわかりづらくなってしまい,いったいこの変更要求仕様書がどのテスト工程に対応しているのかわからなくなってしまいます。

 そこで,至極当たり前ではあるのですが,インプット先がどの工程になるのかを定義する必要があります。その際に忘れてはならないのはXDDPの三点セットの他の2つのドキュメントがどの工程に対応しているのか,合わせて定義することです。

 変更要求仕様書は変更要求と仕様がが書かれています。従って,受け入れテスト・システムテスト・統合テストへのインプットが考えられます。TMはトレーサビリティを確保する物なので,システムテスト以下が妥当かもしれません。変更仕様書は構造が書かれるのでコンポーネントテストだけかもしれません。

 ひとまずはこのように定義しておき,テストチーム内に周知しておくことが必要です。ただし,それが当座をしのぐために暫定的に決めた事であることは合わせて伝えておきましょう。


慌てポイントの3つ目です。

V字モデルのテスト工程の_慌て3-2.jpg V字モデルのテスト工程の_慌て3-1.jpg変更要求仕様書をシステムテスト・統合テストのインプットとして決めた場合,ではその中に記述されているものがどちらに対応しているのかがわからないということも起きやすいことです。

 これは要求と仕様の関係や範囲をどの程度しっかりと理解できるかに影響を受けますが,まずは割り切って対応するのが混乱を沈めやすいでしょう。

 そういったわけで,まずは「要求はシステムテスト」「仕様は統合テスト」とわけることが一案としてあります。それぞれに別けられたものをそれぞれのテストの目線で「そのテスト工程でのテストで良いのか」「他のテスト工程でもテストする必要は無いか」といった目線でチェックします。そこで違和感が生じたものについては,検討を実施します。

 これにより,ひとまず,変更要求仕様書に書かれている内容の振り分けはできるようになります。ただし,この方法は変更要求仕様書の記述内容に大きな影響を受けます。本来ならば要求や仕様を定義する際にどのようなテストが必要であるか,変更要求仕様の定義者にテスト担当者が気がつきやすいように記述してもらうなどの手立てが必要です。(変更要求仕様書の記述内容の云々についてはここでは議論を割愛)


 慌てポイントの4つ目です。

V字モデルのテスト工程の_慌て4-1.jpgV字モデルのテスト工程の_慌て4-2.jpg インプット工程も決まり,変更要求仕様書の内容の振り分けもざっくりできるようになってきたところで直面する問題が「これだけじゃテストできないんじゃない?」ということです。

 変更要求仕様書は「変更」が書かれているもので,それ以外は書かれていません。ですがテストを行う上では「それ以外」の情報も必要となります。このため,変更要求仕様書をテストするための唯一の情報としてしまうとテスト設計の難易度が極めて高くなります。

 ここで思い出してほしいのですが,派生開発ではすでに動いているシステムやソフトが存在します。即ち全体が書かれたドキュメントが存在しているはずです。これらも合わせて入手しておく必要があります。また,変更要求仕様の中身を定義するに当たっての関連ドキュメントも入手しておく必要があります。つまり,スペックアウト資料も入手しておく必要があります。これら2つのドキュメントを入手することを徹底しましょう。

 それから,忘れられがちですが,派生元のテストベースやテストウェアも入手しておく必要があります。なぜならば「テストベースやテストウェアも派生開発の対象」だからです。当然ながら,これらのドキュメントや資産がどのテスト工程のインプットとなるかも定義する必要があります。


 以上,これら4つの慌てポイントについて,簡単にアドバイスを紹介しました。もし同じような状況で慌てポイントに遭遇した際の参考にしていただければと思います。

 当日のセッションでは,これらを紹介した後に,では本来どうあるべきなのかを議論したかったのですが,他のセッションが押したこともあって,10分しか時間がなく,深い議論することができませんでした。なので,別途再演するなり何なりしたいなぁと考えています。その際はもう少し時間も増やして慌てポイントを 少し追加したいなぁとも考えています。

 レポート第3回目です。

長崎QDG2015_150812_153334.jpg このセッションは「コミュニティショートセッション」と題し,他の技術コミュニティから活動紹介を行っていただくものです。長崎の 聴講者は他の地域でどのようなコミュニティが,どのような活動しているのか知ることができます。また,県外のコミュニティは長崎の技術者に活動を知ってもらうことができ,お互いの技術交流のきっかけになることを期待しています。

 発表者の藤沢さんはSQuBOK読破会に所属し,定例会の運営に積極的に関わっていらっしゃいます。そのほか,品質やテストに関わるコミュニティで活動するほか,本イベントにも実行委員として関わっていただいています。本セッションでは,SQuBOK読破会メンバの立場から「SQuBOK読破会活動紹介とSQuBOKにおける派生開発」 というにタイトルで発表いただきました。(本記事掲載の写真やスライド画像は藤沢さんの許可を得て掲載しています)

SQuBOK読破会活動紹介とSQuBOKにおける派生開発 from Kosuke Fujisawa

 発表は, 前半は「SQuBOK読破会の活動紹介」,後半は「SQuBOK V2 における派生開発の記述」の二部構成です。

 前半は「SQuBOK読破会の活動紹介」でした。
SQuBOK読破会活動紹介.pngSQuBOK読破会活動紹介2.png SQuBOK読破会とはその文字通り「SQuBOK(第二版)を読破する」ことが目的の会です。とてもいい本なのですが,なにせ300ページを超え る分量です。一人での読破は大変だけれども,何人か集まって輪読スタイルをとれば読破できるはず!と8名(+オブザーバ1名)で活動し ています。
月一度の定例会では主に次の3つがなされます。
  1. 各自が読んだ書籍を紹介
  2. SQuBOKの輪読(音読)
  3. 懇親会
 1.は,SQuBOKに関連した本や,SQuBOKへの関連を限らずに書籍を紹介しあいます。これにより,普段自分は読まないだろうなという本( の感想)から幅広い知識を得ます。紹介された本はおすすめ書籍リストとして記録されており,現在その数は50冊を超えています。
 2.は,読破会のメインとなる活動です。輪読かつ音読のスタイルを取ります。音読でのいいところは"読み飛ばせない"ことにあります 。また,多人数での輪読なのでさぼることもできません。これによりあまり興味がないところでも頑張って読み進めることができます。あ る程度の塊で読み,その後議論を行います。疑問はないか,追加できる文献はないか,typoなど誤りはないか,等です。メンバーは所属企 業もチアがえばドメインも違うため,多角的な議論になり,それぞれに気づきが得られます。この議論は記録に残しており,typoのリストはSQuBOK策定部会へフィードバックした実績があります。
 3.は,せっかく集まるのですから,懇親会も実施しています。輪読から派生する話題もありますし,まったく関係ない話もありますが, そういった話を通して親睦を深めます。活動開始したばかりの時は堅かったのですが,今では気楽に語り合える人間関係を醸成でき,それ が輪読の議論にも良い影響を与えていると思います。
 現在は200ページほどを突破,7月に修善寺にて合宿を開くなど活発に活動をしています。今後は議論まとめや読み解き資料を作っていきたいとしていました。

 後半は,「SQuBOK V2 における派生開発の記述」でした。読破に取り組む藤沢さんの目線で,SQuBOK V2 で派生開発技術がどのように取 り上げられ,直接的な対応技術であるXDDPを解説していただきました。
SQuBOK読破会活動紹介3.png まず最初にSQuBOKの読み方が解説されました。
  • 普通に各項目を読む
  • 参考文献をたどる
  • 関連知識領域をたどる
 この読み方に従って解説が行われました。
 藤沢さんが考える派生開発に関する直接的なトピックとしては「2.2.3.7 T:派生開発」「3.5.3.2 T:USDM」があり,それらに関連したト ピックとして「1.3.2.2 T:モデル化」「2.2.3.6 T:プロダクトライン開発」「2.11.1 S-KA:変更管理」「3.12 KA:保守の技法」があるとし ました。SQuBOKのような辞書的なものを参照する場合,派生開発ならば派生開発を調べて満足してしまい,関連するトピックまで目が届き ませんが,このように実はたくさんのトピックと関係があるということが理解できました。つまり,派生開発をうまくやるためにはこれら 周辺の技術にも通じておく必要があるわけです。
 次にSQuBOKにおけるXDDPについて簡単な解説がありました。
SQuBOK読破会活動紹介4.pngSQuBOK読破会活動紹介5.png SQuBOKにおけるXDDPは「2.2.3 S-KA:プロセスモデル」の1トピックで,目的として「ミスや漏れによる手戻りを防止して短納期を達成し ,プロジェクトの混乱を未然に防ぐ」,「変更要求を「変更」と「機能追加」に分類し,それぞれ異なる手順で開発する」と解説されているとのことです。
 ただし,これだけだと概要すぎるので,実際の適用に向けて詳しく知るには参考文献をたどる必要があると続けました。参考文献ではXDDPの3つの成果物「変更要求仕様書」「トレーサビリティマトリクス」「変更設計書」についてに,より詳細な解説があると し,その内容が簡単に示されました。
 変更要求仕様書については「変更内容について"特定"」「変更箇所に関する情報を整理」するもの です。変更設計書は「関数など具体的な変更内容を"文章"で記述」します。それらをつなぐトレーサビリティマトリクスは「変更要求仕様書と変更設計書を関連付ける文書」としました。
 また,先ほど挙げられた関連トピックについても簡単に内容が紹介されました。XDDPを導入するためには,周辺の技術も併せて押さえておくことが大切と結ばれました。

SQuBOK読破会活動紹介6.png セッションの最後では「SQuBOK駆動品質改善」ということで,SQuBOKを起点にソフトウェア品質を改善していこうとメッセージが伝えら れました。まず「SQuBOKを読み」,「興味ある分野について理解を深め」,「得られた知識をもとに実践し」,「さらに勉強したい分野を 見つける」。これをぐるぐると回すことで自身の技術知識の向上はもちろん,継続的な品質改善ができるとしました。

 藤沢さんによると,自分も最初はBOKは辞書だから必要なときに調べるだけで活用しにくいと考えていたが,輪読をしていくとそのイメー ジは覆ったとのこと。読めば読むほどに関連知識が増えていき,品質改善に取り組むうえでの技術の全体像や抑えておくべき技術がわかる ことで,より効果の高い品質改善に取り組む手ごたえを感じているそうです。

 実は藤沢さんのセッションについてはその資料についてレビューに関わらせていただいていたので内容は把握しているつもりでしたが, 実際に藤沢さんの口から伝えられる情報は力強く,特にSQuBOK駆動品質改善については示唆をいただきました。自身はかなり乱読するほう だと思うのですが,乱読であるがゆえに,それらをきちんと実践するという観点が抜けてしまいがちです。SQuBOKに限らず,技術書の活用 の仕方について考えてみようと思いました。

 レポートの第2回です。

 今回はこの長崎 SW Quality & Development Gathering 2015 のメインとなるセッションです。

 「要求仕様記述手法「USDM」ってどんなの? -明日から使えるUSDMのエッセンス-」と題して,AFFORDD(派生開発推進協議会)の代表でありUSDMやXDDPの生みの親である清水吉男さんに講義&演習をしていただきました。
AFFORDD様にはこのイベントに共催としてご協力いただいており,本セッションは「AFFORDD共催特別セッション」としています。講師の清水さんにはAFFORDDから講師派遣支援という形で長崎まで来ていただきました。

 この場を借りてAFFORDD様,そして清水様に深く御礼申し上げます。


 セッションは清水さんの自己紹介から始まりましたが,この自己紹介が勉強会参加者に向けた強力なエールでした。

長崎QDG2015_150812_122712.jpg 清水さんは一度モノつくりの業界を去り,植木屋になりました。植木屋ではやることがほとんどきまっており,植木屋としての腕の良さは,その決まっていることをどれだけうまくやれるかということなのだそうです。つまり,経験を積んでいる「どうやっても先輩たちに勝てない」わけです。仮に自分が経験を積んだとしても,その時には先輩たちは同じくらいの経験を積んでいるわけで差はうまりにくいわけです。ただし開発技術は違います。様々な工夫の余地がありますし,追いつくことだってできます。それに気が付き業界に戻る決断をされたそうです。

 モノつくりの業界に戻った清水さんですが,追いつく追い越すため,武器を持つために,3年間徹底的に勉強をしました。そのときの睡眠時間は一日2時間から4時間ほどで,定時に会社を切り上げて,残った時間はすべて勉強に充てていたとのこと。このときに様々な技術に出合い,それを実践,工夫,融合,創生などに取組み,今回扱うUSDMやPFD,XDDPという技術を生み出しました。

 清水さんは聴講者に「自分をかぎることから抜け出しなさい」とエールをおくっていただき,聴講者も大きな刺激を受けたことが表情からうかがい知れました。

 我々は普段なにかしらの組織に属して生活しています。そういった組織には何かしらの"枠"があります。目的だったり責務だったり。知らず知らずに組織に属している自身がその"枠"にとらわれています。"枠"にとらわれると,その外に出るのが怖くなったり,そこに限界を引いてしまいます。これが自分をかぎることの一例です。

 気軽に「自分にはこれくらいしかできないよ」とか「私は〇〇者じゃないのでできません」とかいうのはかぎっていることの典型で,そんなことに陥らないように,定期的に自分を見直すことが大切なのだと居住まいを正す想いでした。


 清水さんの熱いエールの後は本編であるUSDMの講義と演習でした。この講義は次のアジェンダで進められました。

長崎QDG2015_150812_150757.jpg

  • 仕様の問題って?
  • USDMの特徴
  • まず要求を表現しよう
  • 次に要求を仕様化しましょう
  • 画面仕様も同じように書けるよ
  • 品質要求を表現するコツがあります
  • 演習ーちょっとUSDMで書いてみよう
  • おまけ:ところで、派生開発で威力を発揮するUSDMって?

 ソフト開発でのトラブルの原因の多くは仕様に関する問題です。不適切な要求仕様書を根源に持ち,それは仕様モレやあいまい表現という原因を持ちます。また,できてほしいことの「範囲」が見えなかったり,品質要求が十分に書かれていないこともあります。これがその後の「派生開発」で混乱を生みます。

 こういった問題に対してUSDMが一つの解決策となるわけですが,そのUSDMにはいくつかの特徴があります。第一に「要求と仕様を階層構でとらえる」ということがあります。また,「範囲」という考え方を持ち込みます。要求の範囲を狭め,そこに含まれる動詞をすべて表現することで,仕様の抜けや漏れを低減していきます。「動詞」という考えが出てきましたが,これはUSDMは基本的な考えとして「"仕様"は,要求の中の「動詞」および「目的語」に存在する」があるからです。動詞に対して仕様グループを立て,仕様が漏れないように定義していきます。動作を仕様化しているわけですから,それはソースコードに変換できる粒度まで落ちているといます。さらに要求には「理由」を付けます。人は,自分の想いを相手につい耐えることができるとは限らず,それが要求の誤認につながります。理由を付けることで,要求の意味を理解しやすくなり,要求の根拠の有無などに気が付きやすくなります。清水さんによると,要求よりその背景である理由の方が安定しているため,理由を抑えていれば要求は変化しにくいということでした。

 そのような特徴を持ったUSDMですが,USDMでは要求仕様書を「作るたの文書」としています。USDMにおける定義は「「USDM」では,要求仕様書とは,今回のプロジェクトで実現してほしいこと(Requirments)について,"作ることの関係者"が実現内容についての認識を特定(Specify)できている文書」です。そしてそれは機能要求と非機能要求を扱います。似たような言葉に「機能仕様書」があります。要求仕様書と機能仕様書は前者は作る為の文書であり,後者は説明している文書であり,異なるものであるとし,使い分けが必要であるとされました。

 以上,USDMの特徴について簡単に説明があったのち,では実際にUSDMで書くための考え方やコツ,おすすめ方法などが紹介されました。最後の小演習ではFAXの機能を仕様化してみようというものでしたが,参加者は慣れないながら一生懸命に取り組み,気付きを得ていたようです。



 本レポートでは,USDMの実際の書き方については,講演資料が非公開であるため取り扱いませんが,興味がある方はAFFORDD様主催の勉強会が定期的に開催されていますので,是非ご参加いただくことをお勧めします。

 長崎QDG2015はオープニングセッションから始まりました。

長崎SWQuality&DevelopmentGathering2015 オープニング資料 from Ikedon

 このセッションは勉強会イベントを開催するに当たってその概要と長崎IT技術者会について説明をするものです。


 長崎SWQuality & Development Gathering 2015 とはその名の通り,ソフトウェア品質技術と開発技術のどちらも取り扱いトータルとしてのソフトウェア開発を勉強し,またそういったロールの人が交流しようという想いが込められています。

 常々ソフトウェア開発技術というものは総合技術であると思っています。(体系化による)技術分野やロールの異なりがあるとしても,連携したり作用したり融合したりする必要があるはずです。ですので,今回は品質技術と開発技術にわけていますが,両方を取り扱う必要があると考えたわけです。勉強会等を利用して成長していくうえで,自身の専門技術はこれだとか,自分のロールはこれだとか決めてしまうのはある意味自分を限ることなのかもしれません。強みを認識してそれを伸ばしつつも周辺や関連する技術を習得していくことが大切だと思いますし,そもそも強みは1つでなくても良いはずですね。

 この長崎QDGは「ソフトウェア開発は総合技術である」ということと「自分を限らないこと」が考え方として暗黙的に存在します。


 さて,当日の参加状況です。参加申込みサイトでの事前申込み状況は14名でした。

長崎QDG2015_OP_参加者比率.jpg なにせ夏休み期間ですから,5人も参加いただけたら万々歳かなぁと思っていました。ですので,10名を込める方に参加いただき初回としては大成功でした。

 参加比率をみると,おおむね長崎から1/4,1/4が長崎以外の九州から,残り1/2が県外からということになりました。

 正直言いますと,もう少し地元長崎からの参加があればと思わないでもないのですが,東京在住の人間がなんのつてもなく宣伝もほとんどできずに開催したイベントでこれだけ参加の参加は嬉しいところです。また,佐賀や福岡の方の参加も嬉しいところでした。個人的に「西九州IT技術ベルト」という構想を持っているのですが,それにつながる希望と感じています。そして,県外から多くの方にご参加いただきました。主に・・・というか,コミュニティ活動で仲良くさせていただいている方々のご参加だったのですが,遠方かつ大きな交通費がかかる時期にご参加いただけたことに深謝申し上げます。

 長崎QDGの目的の1つに「県内外の技術者の交流」がありますので,それが果たされて良かったなと感じています。


 最後に長崎IT技術者会についてご説明申し上げました。

長崎QDG2015_OP_長崎IT技術者会とは.jpg 長崎IT技術者会は長崎出身である筆者が個人的に立ち上げたものです。ひとまずFacebookグループとして交流の場を作り活動しています。何かしらの関わりや興味がある方であればどなたにもご参加いただけます。

 "長崎"とついているので長崎で活動しているグループと誤解されそうですが,活動場所はこだわっていません。現に,勉強会は現在筆者が在住している関東エリアにて開催しています。ただし,その際は会の最初に(技術にこだわらない)長崎紹介を実施することにしています。長崎に興味を持っていただき,実際に足を運んでいただけたらなと考えています。後述しますが,年に一度は長崎でフラグシップイベントを開催しようと考えています。事前に興味を持っていただくことで,イベントに参加いただけたらという狙いもあります。

 また,"会"とありますが,何かしらの営利目的や営利を期待するような団体ではなく,あくまでもボランティアベースの会としています。よく「コミュニティと思って入ったら業界団体だった」や「コミュニティを名乗りつつも実態は業界団体」ということがありますが,この会にはそういう要素はありません。あくまでボランティアベースです。ちょっと堅い名前になっていますが,柔らかいイメージをお持ちいただけると嬉しいなぁと思います。


 最後に筆者の想いを簡単にお伝えしました。

長崎QDG2015_OP_長崎IT技術者会の今後.jpg 以前の記事にも書きましたが,この長崎IT技術者会の活動は筆者個人の地域貢献の想いから始まっている,とても独善的な活動です。ただし,これをこのままの形で続けていくつもりはありません。地域に作用するためには少しずつでも活動を充実させていく必要があります。ただし,それは(今回痛感したのですが)筆者1人だけでは難しいことです。それに,活動の主体は現地長崎の方であるべきです。より多くの方々にご協力を賜りながら,少しずつ大きな活動としていればと考えています。もし,ご協力いただける方がいらっしゃいましたら,是非ご連絡いただけたらと願っております。

 活動を頑張っていきます。そのために応援&ご強力のほど,よろしくお願いします。(スライド中のご強力は敢えてその表現にしています。強く前に進めていきたいという意思を表したつもりです。)


 以上,オープニングセッションは半ば小生の想い語りになってしまいましたが,ともあれこうして長崎IT技術者会の第一回目のフラグシップイベント「長崎SWQuality & Development Gathering 2015」は開幕しました。

 この時点で,筆者としては実際に開催できたことにある種の達成感を持ち,その熱に浮かされながら一日を過ごすこととなるのでした。

【開催レポート】長崎QDG2015

長崎QDG2015_150812_102319.jpg 去る2015年8月12日,長崎ブリックホール(長崎市茂里町)にて勉強会イベントを開催しました。半年ほど前に「何らかの形で地元貢献したい!」と考え至りまして,長崎IT技術者会をFacebookグループで立ち上げ,そのフラグシップ勉強会イベントとして具現化することができました。

 当日は,当初想定していた以上のご参加をいただき,イベントとして成功裏に終了することができました。開催にあたり,共催くださったAFFORDD(派生開発推進協議会)様や参加者,スタッフの方々に御礼申し上げます。

 さて,この勉強会イベント「長崎 SW Quality & Development Gathering 2015(略称:長崎QDG2015)」について,当日の様子を数回に分けて,簡単にレポートをしたいと思います。当日ご参加いただいた方には復習の一手として,ご参加いただけなかった方には当日の様子を知るためにご利用いただければと存じます。


■イベント詳細ページ

■レポート一覧(掲載次第リンクを更新します)

■参加者のレポート

去る2015年8月12日,長崎ブリックホール(長崎市茂里町)にて「長崎 SW Quality & Development Gathering 2015」が開催されました。

私は主催者としての参加でしたが,少しだけお話ししてきました。

「長崎SWQuality&DevelopmentGathering2015」
 V字モデルのテスト工程のインプットがUSDM形式だったときに慌てないために
from Ikedon

XDDPにおけるテストについて,現実的によくある話をとりあげ,理想と現実の差を認識してもらい,ディスカッションするというセッションでした。

本来XDDPは実装までに品質を作り込むことを重視する(というか作り込まれる)ため,清水さんの本にはあまりテストについては言及されていません。これ自体はそりゃそうだよねと納得するわけですが,現実としては今まであるVモデルベースの社内規格の左側である開発工程にXDDPを当てはめるということが多くあります。

こういったゆがんだ導入の場合,本にはテスト工程についての記述が少ないので,テスト工程の運用について混乱してしまうことがほとんどです。加えて,これまでWORDベースでの設計ドキュメントしか読んだことがないテスト担当者にExcel&USDMで書かれたドキュメントが渡ったときに,テスト担当者が混乱を起こしてしまいます。

こういった現実について,もちろん最初からXDDPを綺麗に入れ直すということが理想なのですが,すでに進んでしまっている今回のプロジェクトでは当座をしのぐために,いびつとわかりつつも対処対応することが必要です。

それから,大きな組織になればなるほど設計規格をかえることはとても大変で,1年を越えることもほとんどです。そのあいだはいびつな対応とわかりつつも,それでうまくやらざるを得ません。

こういった状況における,最初に装具する「慌てポイント」を4つ取り上げています。

  • 慌てポイント1:そもそも慌てない
  • 慌てポイント2:どこのインプット?
  • 慌てポイント3:どこのテストレベル?
  • 慌てポイント4:情報が足りません

どれも当たり前だよなという話なのですが,実際,現実として初めて遭遇したときに例外なく慌てます。なにぜならば,テスト担当者全員がXDDPやUSDMを知っているわけではないし,実戦経験があるわけでもないからです。

これら4つの慌てポイントについて,簡単にアドバイスを紹介しています。もし同じような状況で慌てポイントに遭遇した際の参考にしていただければと思います。

当日のセッションでは,これらを紹介した後に,では本来どうあるべきなのかを議論したかったのですが,他のセッションが押したこともあって,10分しか時間がなく,深い議論することができませんでした。なので,別途再演するなり何なりしたいなぁと考えています。その際はもう少し時間も増やして慌てポイントを少し追加したいなぁとも考えています。

最近のコメント

アイテム

  • 2015-09-02 18.56.46.jpg
  • 長崎QDG2015_150812_163634.jpg
  • 長崎QDG2015_150812_163316.jpg
  • 長崎QDG2015_150812_163235.jpg
  • 長崎QDG2015_150812_150757.jpg
  • 長崎QDG2015_150812_122712.jpg
  • 長崎QDG2015_150812_122738.jpg
  • 長崎QDG2015_150812_165141.jpg
  • 長崎QDG2015_150812_165602.jpg
  • 長崎QDG2015_150812_165820.jpg