JaSST '22 Tokyoの発表資料を公開しました #jassttokyo

　JaSST '22 Tokyoで、翻訳メンバーとして参加した『実践ソフトウェアエンジニアリング 第9版』のセッションを担当しました。長過ぎるタイトル*1と概要は以下のとおりです。

「ソフトウェア開発にかかわる全てのエンジニアの一般教養「ソフトウェアエンジニアリング体系」における品質技術 ～翻訳者が語る「実践ソフトウェアエンジニアリング（第９版）」における品質技術の概観」

講演者４名を含むＳＥＰＡ翻訳プロジェクトでは、米国修士課程においてベストセラーとなっている体系的解説書「Software Engineering: A Practitioner's Approach 9th edition」を翻訳し、「実践ソフトウェアエンジニアリング（第9版）」としてオーム社より12月1日に発刊した。（https://www.ohmsha.co.jp/book/9784274227943/）
本書は米国を中心とした海外で大学生教育における教科書として採用されている世界的名著である。JaSST'09 Tokyoに著者であるプレスマン氏を招聘したことをご記憶されている方もいらっしゃるのではないだろうか。
本書は、QA/テストエンジニアにとっても、一般教養たりうる書籍である。
本セッションでは、最新版である第９版日本語版について、翻訳プロジェクトや書籍の全体概観を紹介し、「第３部　品質とセキュリティ」について訳者によるディスカッションを行う。

　本セッションは、大きく3つに分けられています。

　1つ目、「第9版」全体の概要や、過去の版からの推移などを水野昇幸さん*2が解説。
　2つ目が、JaSSTらしく本書第3部「品質とセキュリティ」の超概説をわたし鈴木が。
　3つ目は池田暁さん*3のファシリテートで、第3部の訳を担当した根本紀之さん*4とわたし、プラス水野さんがテストやレビューについてディスカッションするというものです。

　わたしのパートが予定より押してしまい、ディスカッションが少し短くなってしまったのですが、Discordのチャットにもたくさん投稿をいただき、ほっとしました。セッションタイトル的に割と真面目そうだし、10人くらいしかこない系か？とも思っていたので・・・。

　当日の資料はこちらで公開しています。

speakerdeck.com

　全9章ある第3部を20分で概説しようということで、最初に作ったドラフトは、「少ないっ・・・！ 情報がっ・・・！ これでは何ら変わらない・・・ 目次とっ・・・！」*5でした。目次を吟じるだけのセッション、さすがに許されない。

　で、もう少しちゃんと作ってみたところ、今度は早口でも40分以上かかるような内容に。
　結局、対象を5章に絞り、各章の説明を少し厚めにして、なんとか許容範囲の時間オーバーとなったのでした。

　ということで、公開されなかった残り4章分も、いつかどこから日の目を見させてあげたいと思います。
　参加いただいたみなさま、どうもありがとうございました！

実践ソフトウェアエンジニアリング (第9版)

*1:トラックオーナーの方が困っていた・・・。

*2:@noriyukimizuno。ファーストネームの漢字まったく思い出せず、検索した。

*3:@ikedon0505。ファーストネームの漢字をギリギリ思い出せたが、検索した。

*4:@nemorine。ファーストネームの漢字まったく思い出せず、検索した。

*5:最近読んでいる・・・ 『1日外出録ハンチョウ』！

１日外出録ハンチョウ（１） (ヤングマガジンコミックス)

ドキュメントテストって一見地味だけど、とても大事ですね

　JaSST '22 Tokyoのセッションの中で、『プレスマンの白本』*1の「21.12 ドキュメントとヘルプ機能のテスト」で言及されている、「ドキュメントテスト」*2についてお話しました。

実践ソフトウェアエンジニアリング(第9版)

　なおこの用語はISTQB用語集では見つからない*3 のですが、プログラムそのものと一緒に提供されるドキュメントに対するテストを意味しています。リリースノートや製品マニュアル*4などが対象になりますが、この記事ではマニュアルのテストについて書いていきます。

ドキュメントテストが難しい要因

　マニュアルはユーザが直接利用するものであり、製品の一部です。そのチェックに手を抜いていいと思う人はいないでしょう。それでも、品質が十分でないマニュアルが最後の方まで残っていることがあります。

　マニュアルのテストが不十分になる原因は、大きく2つあります。

1. マニュアルが製品と並行して完成に近づく性質があり、最後の最後まで更新が続けられがちなので、テストを後回しにしてしまう。
2. 他のテストに比べて単純で退屈に見えて、軽視してしまう。

　さらに、『アクティブユーザのパラドックス』という概念があります。Nielsen氏の記事から引用してみましょう。

ユーザは絶対にマニュアルを読まない。いきなりソフトウェアを使い始めるのだ。彼らには始めようという意欲が旺盛であり、目前には片付けるべきタスクもある。システムそのものには関心がなく、事前の取り決めや設定、学習パッケージに時間を割くつもりはないのだ。

　こうなると、ろくに読まれもしないドキュメントのテストの費用対効果って？と疑問に思うこともあるでしょう。

ドキュメントテストが大事な理由

　では、マニュアルはいつ読まれるのか。
　経験上、それは「最初の最初」と、「困ったとき」ではないでしょうか？
　そんな場合にマニュアルの品質が悪いと、どうなるか。

　「最初の最初」は、ソフトウェア製品でいうと「インストール」にあたります。インストール方法がわかりづらい、ましてや失敗するとあっては、どんなに魅力的な機能を謳ったところでむなしいだけです。
　「困ったとき」は、その時点ですでにストレスが溜まっているわけです。イライラしているところにきて、マニュアルに沿って操作してもうまくいかない。場合によっては事態を悪化させる。不愉快の二乗です。こんな最悪なユーザ体験ってあるでしょうか。

　またユーザからすると、「マニュアルに書いた通りに動く、ことすら確認していないのか、この製品は」ってなりますよね。
　ユーザを助けるためにも、また信頼を失わないためにも、ドキュメントの品質はとても重要なのです。

ドキュメントテストの2つの段階

　では、ドキュメントの品質はどのように評価*5するのでしょうか。
　白プレでは、ドキュメントテストを2段階に分けています。

1段階目はテクニカルレビューで、ドキュメントが明確な文章であるかを確かめる。2段階目は動的テストで、ドキュメントと合わせて実際のプログラムを動かす。

　マニュアルって、ユーザが直接目にするもので、つまりある種のUIなんですよね。
　決められた体裁に従っているか、文章が論理的で、長すぎず、主述のねじれがなく、適切に箇条書きや図表が利用され、・・・みたいな、テクニカルライティングのお作法に沿っているか、を確認する必要があります。これが1段階目で、レビューの対象になります。

　そのうえで、書かれたことが「正しい」かどうかは、テストの対象。2段階目です。 　

　時間のない中で作られたマニュアルは、「まるっきり間違っている」よりも、「部分部分は正しい、全体としては正しくない」になりやすいように思います。あることを実現するために10ステップ必要な場合に、1～5は正しい、7～10も正しい、でも6が抜けている。みたいなイメージです。

　こんなことが起こる要因にも、いくつか考えられます。

• マニュアルに載せる手順を、部分部分の切り貼りで作っている。
• 書き手が中身を知りすぎていて、暗黙のステップを飛ばしてしまう。
• いろいろと「設定済み」の開発環境で動かしているために、本来は必要な設定の手順が漏れる。

　ですのでマニュアルのテストはできる限り、「そのマニュアルを作った人以外」が、「ユーザがその操作を行うであろう状態を模擬した環境」で、「手順を一気通貫して」行うのがよいと思います。

　なお、ドキュメントテストを完全に独立したテストとして行うことが必須かといえば、そんなことはありません。インストールテストの中でマニュアル確認を兼ねたり、エラー系・障害系のテストでトラブルシューティングの章を検証したりというのは、悪くない作戦だと思います。

マニュアルを書くのは誰？

　マニュアルを誰が書くかは、組織によっていろいろでしょう。開発者がマニュアルまで書く場合もあれば、専門のテクニカルライターがいるケースもあるでしょう。今回の記事は、どちらかといえば前者の場合に当てはまるかなと思います。

　後者の場合は、開発部門とライター部門の垣根を低く、連携を密に、お互い敬意をもって、みたいなコミュニケーション上の留意事項も出てきます。
　ともあれ、「ユーザによって読みやすい文章を書ける」というのはプロフェッショナルのスキルであり、それがしっかりできるテクニカルライターさんには敬意を感じます。

"books" by whereisyourmind is licensed under CC BY-NC-SA 2.0

*1:『実践ソフトウェアエンジニアリング 第9版』の通称。略称は『白プレ』。

*2:なぜか資料内では「マニュアルテスト」と表現していました。これだと手動テストと混同されそうです。

*3:これをTwitterでつぶやいたところ、辰巳敬三さんが以下のように教えてくださいました。

documentation testingはGlossaryのVersion 3.1迄はあり、Version 3.2で"Not mentioned in any syllabus"という理由でremoveされています。
定義は、
documentation testing: Testing the quality of the documentation, e.g. user guide or installation guide. ドキュメンテーションテスト（documentation testing）： ユーザガイドやインストールガイドのようなドキュメントの品質をテストすること。

*4:取扱説明書、ユーザーズガイドなどと呼ばれることもありますが、以下「マニュアル」で統一しています。

*5:ドキュメントの品質の「作り込み」は、テクニカルライティングという別の分野の要素が強くなるため、この記事では触れていません。

JaSST '22 Tokyoの2日目でお話します。

　開催までもう1週間を切ってしまったのですが、3/10(木)から2日間開催される、JaSST '22 Tokyoのセッションの1つで、おはなしさせていただきます*1。

jasst.jp

　タイトルがめちゃめちゃ長いです。

「ソフトウェア開発にかかわる全てのエンジニアの一般教養「ソフトウェアエンジニアリング体系」における品質技術
～翻訳者が語る「実践ソフトウェアエンジニアリング（第９版）」における品質技術の概観」

　タイトルの通り、昨年出版された、『実践ソフトウェアエンジニアリング 第9版』についてのセッションです。
　この中でわたしは、本書の第3部「品質とセキュリティ」でどのようなことが書かれているかについて概説する予定です。
　「そんなことが書かれているのね～」というのを掴んでいただき、そのまま書籍購入の動線に乗っていただければ幸いです。

実践ソフトウェアエンジニアリング (第9版)

　ただ今、絶賛資料作成中です*2。

発表資料の表紙

　興味のある方、ご参加いただけると幸いです。

*1:「登壇」という言葉、かっこいいんだけど、わたしは身に余りすぎて恥ずかしくて使えない・・・。

*2:今気づいたんだけど、JaSST '21ってなってるな・・・あぶねえ・・・。

"test quality into the product" という不思議な言い回しをどう解釈すべきか

　miwaさんのこちらのツイートに、ソフトウェア品質・テスト関係の方々がいろんな意見を寄せていました。ぜひスレッドを追ってみてください！

"テストのビジネスのことわざで「製品の中で品質をテストできない」"

ここでいう"製品の中"というのは"開発全体のフェーズの最後の製品だけで"という意味なのかな? うちのチームだとチケット単位(2,3日のストーリー)で所謂V字の右上までいくので、このことわざを見たとき、え?? と考えてしまった。 pic.twitter.com/G4oG1E3NaG

— miwa (@miwa719) 2022年1月22日

いろんなところに現れる常套句

　上のツイートは、『実践アジャイルテスト』からの引用です。原著『Agile Testing』と合わせて、もう少し引用してみます。

An old saying in the testing business is, "You can't test quality into the product." This is, of cource, true of agile development as well. We feel you can't deliver high-quality software without following some fundamental practices.
テストのビジネスのことわざで、「製品の中で品質をテストできない」 というのがあります。これはもちろんアジャイル開発においても真実です。いくつかの基本的なプラクティスなしには、高い品質のソフトウェアは作れないと感じています。

　日本語も理解が難しいですが、原文なら理解できるかというとそれも難しい。
　似たような表現は随所に現れます。
　『テストから見えてくる グーグルのソフトウェア開発』とその原著『How Google Tests Software』から引用。

"Quality cannot be tested in" is so cliche it has to be true.
＜品質はテストできない＞という言葉はとても使い古されているので、真実であるに違いない。自動車からソフトウェアまで、最初の設計段階から品質が作り込まれていなければ、製品は決してまともなものにはならない。

　『実践ソフトウェア・エンジニアリング』*1とその原著『Software Enineering - A Practitioner's Approach』から引用。

As they say, "You can't test in quality. If it's not there before you begin testing, it won't be there when you're finished testing."
「品質はテストできない。テストを始める前に存在しなかった品質は、テストが終わったところでやはり存在しないのだ」という言葉の通りだ。

実践ソフトウェアエンジニアリング (第9版)

どう解釈するか

　少なくとも、3つの解釈が考えられます。

1. 品質は、テストより前に作り込むべきものである。
2. 品質を上げるのはテスト自体ではなく、その後の活動である。
3. 品質そのものはテストできない。

　辰巳さんからは、William Edwards Deming氏の言葉を教えていただきました。
　『Out of the Crisis』*2からの引用（翻訳筆者）です。

Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. As Harold F. Dodge said, “**You can not inspect quality into a product.”
品質は、検査によって改善されるわけでも、約束されるわけでもない。検査では遅すぎるのだ。良いにせよ悪いにせよ、品質はすでに製品に備わってしまっている。

　test（テスト）ではなくinspection（検査）という言葉に変わっていますが、意味合いは同じでしょう。
　この文章や、その引用の文章周辺を見ても、解釈1が一番原意に近く、広義には2も含む、みたいに考えられるのではないでしょうか。

test quality into って何！？

　ただそれでも、「test quality into the product」ってどういうニュアンスなのよというモヤモヤは残ります*3。日本人（主語デカ）は、動詞＋副詞/前置詞型の句動詞に弱いんだよ！

　Deming氏の引用にも出てくる*4、統計的品質管理のHarold F. Dodge氏のこの言葉がヒントになると思います。

You cannot inspect quality into a product; it must be built into it.

　build quality into a product と inspect quality into a product を対句と捉えることができます。
　build inが「作り込む」、push inが「割り込む」であるように、inやintoがもたらす「～込む」という語感。これをtestにくっつけることで、「テストを通じて品質を練り込む」みたいなニュアンスを表現しているのでは、というのがわたしの仮解釈です。どうでしょうかね？

　ということで、「テストの段階になって初めて品質を作り込もうなんて考えちゃいかんよ」と、何十年も前から言われ続けていることをあらためて噛み締めて、眠ることにしましょう。

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践)

テストから見えてくるグーグルのソフトウェア開発

Out of the Crisis (The MIT Press)

*1:この部分はわたし自身が、『グーグルのソフトウェア開発』の翻訳を参考に訳したので、完全に文責筆者ってやつです・・・。

*2:Amazonで新品の取り扱いがある・・・。

*3:この表現について社内のネイティブに聞いてみたところ、「It is awkwardly worded」というコメントをいただきました。ネイティブスピーカーn=1の意見で正しいというつもりはないけれど、信頼できる英語話者と考えられる方です。

*4:ググっているうちに、「In search sites, his name always come with Deming’s.」という文章に出会って笑ってしまった。確かにセットでした。

【読書メモ】発想の組み合わせが面白い本２冊

　ショートショートの大家・星新一は、その膨大な作品のもととなった発想の源泉について、「アイデアは、異質なものを結びつけるところから生まれる」と語っています。また、「技術革新」と訳される「イノベーション」は、実は既存のモノやコトの組み合わせから生まれたものが多いとも言います。

星新一〈上〉―一〇〇一話をつくった人 (新潮文庫)

　今日は、「おお、いい組み合わせだな～」って思った本を2刷紹介します。
　イノベーションの話は出てきません。

おとぎ話×SF、『百万光年のちょっと先』

百万光年のちょっと先 (ジャンプジェイブックスDIGITAL)

　『このライトノベルがすごい! 2018』で紹介されていた本です。
　ライトノベルは、本当に好きになれるものとそうでないものの落差が激しく、かつ表紙が40代男性にはだいぶ厳しいものが多いという欠点はあるのですが、やっぱり面白いものは面白い。

　『百万光年のちょっと先』は、型落ち気味の自動家政婦が、幼い少年に紡ぐ物語。宇宙や未来、この世界のどこかを舞台にした小さなお話の集まりです。

　SF的で、かつ短編といえば、星新一や筒井康隆や眉村卓の作品が思い出されますが、『百万光年のちょっと先』は、そこにおとぎ話のエッセンスを加えています*1。小さなエピソードから醸し出される、不思議だったり、寓意だったり、物悲しさだったり。

　正直最初は、SFとしてはちょっとライトすぎるなと感じました。また、「十億年の時間を要し、建造に関わった星間文明が百回も代替わりした末に完成」といったやたらと大げさな数字も安易に感じて、抵抗がありました。

　ですが、ふと思い出すのです。そうだ、これは「こどもに聞かせるおとぎ話」なのだと。
　おとぎ話だから、豆の木が天まで届いたり、お椀に乗って旅する侍がいたり、極端なことが当たり前に起きてもいいし、その根拠や背景や理屈を丁寧に解説することは、蛇足でしかないのですね。

　それぞれのお話にワクワクするようなガジェットが登場するのも魅力です。たとえば、「宇宙のあらゆる知識を詰め込んだような究極の百科事典」とか、「亜光速単原子生物や超弦生物までを展示している宇宙動物園」・・・。

　そこで起きる小さなお話を、ぜひ楽しんでみてください。
　わたしが特に気に入ったエピソードは、『夢見るものを、夢見るもの』と『最後の一冊』です。

落語×哲学、『落語―哲学』

落語―哲学

　タイトルがそのまんまですが、落語と哲学という異色の組み合わせ。
　と思うのですが、本書を読み進めていくとたしかに、落語には謎めいた、不条理な話が紛れ込んでいることに気づきます。紹介されているネタでいうと、

• 『芝浜』: 大金を拾った魚屋におかみさんが、それが夢だったと信じ込ませるおはなし。
• 『粗忽長屋』: 行き倒れの男の身元が熊五郎かどうかを、熊五郎自身を呼んできて確かめようとするおはなし。
• 『あたま山』: 頭に桜の木が生えたり池ができたりしてしまい、そこで人が花見や釣りをすることを嘆いた男が、その池に身を投げるはなし。

のように、単なる笑い話で片付けられない違和感を含んでいます。

　たとえば『芝浜』について、筆者は2つの視点で分析を試みています。
　1つは、多世界解釈。

この噺は、コペンハーゲン解釈ではなく、多世界解釈によって、さらに深みを増す。あるいは、この噺の背景には、多くの離接肢（可能世界）が隠れていて、芝浜という噺の内容が、現実になった離接的偶然として屹立しているともいえるだろう。

　大金を拾わなかったら、拾った金を散財してしまっていたら、そして3年働いた後に酒を飲んでしまったら。起こり得たかもしれないけれど、この世界線では起こらなかったたくさんのことを想像させるのが、この噺の魅力ではないかとしています。

　もう1つは章タイトル、「この世は夢ではないのか」*2という視点。

この一日で、熊は、何と三度起こされ、おかみさんも熊に一度起こされるのだ。眠りに眠った一日だといえるだろう。だからこそ、この日は、二人のあいだで、夢の現の境目が消えかけていた。どこまでが現実で、どこからが夢なのかわからなくなる条件は、十分そろっていたのである。　

　噺の中に、実は夢自体は一度も出てこないながら、睡眠と覚醒を繰り返す中、眠りの象徴である「海」から、覚醒の象徴である「陸」に財布が上がってきているという解釈が提示されます。

　一体、落語にそこまで深い意図が込められているのか。深読みに深読みを重ねていないか。
　そう感じる部分もけっこうあります。ですけど、落語のネタを呼び水にして、世界や人間のあり方を考えていく、話もやたらと広がっていく、それが面白いからオッケーです。

　あらためて、落語をちゃんと見てみたいなって思いました*3。

おわりに

　組み合わせの妙が面白い2冊を紹介しました。
　なおこの記事自体も、全然関係のない2冊の関連を見つけて、組み合わせて紹介するという試みをしてます！

*1:星新一にもその要素はありますね。というかそれをテーマにした作品集自体があった気がする。

*2:『胡蝶の夢』的な作品って、『マトリックス』『ザ・セル』『インセプション』という映画や、小説だと『完全なる首長竜の日』などたくさんあって使い古されているはずなんだけれど、なぜか惹かれてしまいますね。『百万光年のちょっと先』にも、これに属するエピソードがあります。

完全なる首長竜の日 (宝島社文庫)

*3:落語といえば『昭和元禄落語心中』も面白いんですが、『夏子の酒』でも有名な尾瀬あきらさんの『どうらく息子』もとても良いです。久しぶりに読もうかなあ。

どうらく息子（１） (ビッグコミックス)