ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

『実践ソフトウェアエンジニアリング 第9版』を訳して、日本語の難しさを知る

 『Software Engineering - A Practitioner's Approach - Ninth Edition』の日本語版・『実践ソフトウェアエンジニアリング 第9版』が発売されました。
 わたしは「SEPA翻訳プロジェクト」の1メンバーとして、第3部「品質とセキュリティ」の3章分の翻訳と、周辺の章のレビュアを担当しました。

 メンバーのmasskanekoがアドベントカレンダーを作ってくれたので、記事を一つ書いてみます。
 本書の位置づけや意義については、ET&IoT2021で他のメンバーがヘヴィな発表をしているのでそちらを参照していただくとして、まだ全章読めてすらいないわたしは、言葉の面白さについての雑文をば。

www.slideshare.net

英語より日本語で悩む

 翻訳の専門家でないどころか、素人翻訳者としてすら長いキャリアがあるわけでもない身でえらそーな言い方になりますが、英語で書かれた技術書を翻訳するうえで必要な能力は大きく3つあります。

  1. 原文を理解する英語力
  2. 書かれた内容を咀嚼する知識
  3. 内容を文章に落とし込む日本語力

 1と2に比べて、3は影が薄いです。何せ、日本人の多くは、日本語を不自由なく操れるはずですから。
 でも実際、一番苦労するのは3だったりします。
 「原文が悪文だ」と原著者のせいにしたくなることもありますし、自然言語がそもそもあいまいさを許容していることも難しい問題なのですが、やはり、日本語と英語の文法の特性が大きく違うことが、翻訳を難しくする大きな要因に思えます。

 たとえば、「受動態」「無生物主語」「使役動詞」「関係詞」。
 こやつらは、訳文をぎこちなくさせる主犯格であり、同時にあまたの受験生を苦しめてもいる連中です。ただこういった英語の文法を考えていくと、いつしか日本語の問題に行き着いたりするのです。

 受動態について考えてみましょう。
 以下の文章、どちらが適切に思えますか?

  1. 「テストで摘出したバグのトリアージを行う。」
  2. 「テストで摘出されたバグのトリアージを行う。」

 「バグ」を修飾する言葉が、能動態的な「摘出した」なのか、受動態的な「摘出された」なのかだけの違いです。
 英語なら bugs detected in testing みたいに受動態的に修飾すると思う*1のですが、日本語だと両方許容されるように感じませんか? こんな場面で、ハタと迷うわけですね。
 わたしには、aもbも間違っているようには思えませんが、「何らかのロジックに基づいてどちらか選べ」と言われれば、以下のロジックで選びます。

「バグを摘出した」人と「バグのトリアージを行う」人が

  • 同一なら: a(摘出した)を選ぶ。
  • 同一でないなら: b(摘出された)を選ぶ。

 でも、正しいかどうかはよくわからないので、他の人にもそうすべきとは言えません。

 とまあこんな風に、英語のことを考えていたはずが、いつの間にか「日本語って難しいな!」ってなるのが、翻訳の面白いところです。

「ひっくり返さない」

 10代の多感な時期に身に着けた「英文法」の読解は今もわたしの心に暗い影を落としています。
 その1つが、「日本語とは逆に、英語は後ろから後ろから修飾していくので、日本語にするときには逆に訳していかなければならない。」ってやつです。

 たとえばこんな文章。

Your software team can develop a set of quality characteristics and associated questions that would probe the degree to which each factors has been satisfied.
(原書15.2.2 Qualitative Quality Assessment)

 that would ... が questions を後ろから修飾し、to which ... が the degree を後ろから修飾しているようです。修飾の順番を「逆に」すると、こんな訳になるでしょうか。

品質特性と、その品質特性がどの程度満たされているかを明らかにするための質問のセットを作ってもいいだろう。

 たぶん間違ってはいないんでしょうけれど、「品質特性」で宣言した、「『と』で結ばれるべき相手」である「質問」が、待てど暮らせど出てこないんですね。読み手は、「品質特性」と「と」で結ばれる相手がこの後出てくるはずだというアタマになっているのに。

 訳す方も実は同じです。
 characteristics をいったん脳に保管しておいて、次の修飾部1を訳しているうちにさらに修飾部2が現れる。修飾部1も脳に保管したうえで、修飾部2を訳し、終わったら修飾部1を脳から取り出し、最後に「品質特性」を脳から取り出して結合する。スタック構造が脳のキャパシティを浪費してしまいます

 こんな文章の翻訳について、『翻訳エクササイズ』(金原瑞人・著)では、「ひっくり返さない」という章で、こんな説明をしています(修飾筆者)。

なぜか中高の英語教育では、関係代名詞や接続詞の前後をひっくり返して訳すように教えることが多く、これが翻訳のときの足枷になっているのは間違いありません。いえ、英語を読むときの足枷にもなっています。

On a sunny day I met a beautiful girl whose name was Jane.

これを訳せというと、たいがいの学生は、
「ある晴れた日、私は、その名がジェインである美しい少女に会った」
と訳してきます。しかし英語は頭から読んでいくと
「ある晴れた日、美しい少女にあった。その子の名前はジェインだった」
と書かれている。だから、そう訳しましょうという、ただそれだけのことをいっているのです。じゃあ、英語の関係代名詞whoseはどこにいったんだ、whoseをand herとしてしまっていいのかと疑問に思う人もいるでしょう。しかしそれでいいのです。というか、翻訳の場合はこう訳したほうがいいということです。

 我が意をえたり~。受験脳のせいで、関係代名詞の限定用法と叙述用法の区別が頭をちらついたりしますが、「翻訳の場合はこう訳したほうがいい」のです!
 ということで、先の文章も

Your softaware team can develop a set of quality characteristics and associated questions that would probe the degree to which each factors has been satisfied.(原書15.2.2 Qualitative Quality Assesmentより)
品質特性とそれに関する質問のセットを作り、各要素がどの程度満たされているかを調べることも可能だ。

としています。これはこれで問題ナシというつもりはなく、主語が長すぎるという欠点があり悩ましいのですが・・・。

先ぶれの副詞も・・・

 『井上ひさしの作文教室』には、「先ぶれの副詞」という考え方が出てきます。以下抜粋。

 日本語というのは文のポイントが、そのおしまいに来る。判断個所が文の終わりに来るんですよね。
 私は昼御飯をー--というところで終わってしまったら、食べたのか食べなかったのかわかりません。
 そのときに「まだ」とついたら、食べてないということが、すぐにわかってしまいます。
 わたしたち日本人は「まだ」と聞くと、下に否定が来ると判断できるんです。こういう「まだ」のようなものを「先触れの副詞」と言います。文章が長くて、読み手が、いい加減ここらで判断の手掛かりを出してくれないかなと思いそうなところで、こういう副詞をちょっと出してやる。そうすると、その文章の判断が決まっていくわけです。

 主観ですが、原著は文章が比較的長く、節と節の間の論理関係が取りづらいと感じることが多かった。そういう時には文章を区切ったり、この「先触れの副詞」で早めに文章の意味の方向性を示したり、という工夫を盛り込んだりもしています。
 結局、いい訳文を作ろうとすると、日本語に立ち返っていくわけですね~。

おわりに

 本書の内容にはまったく触れず、「翻訳って日本語と難しさに気づかされて面白いよ!」という話を書いてみました。
 わたしの訳文はベストではないだろうと思いますし、英語のデキる人からすると笑止かもしれませんが、こういったことにできるだけ配慮して書いてみました。
 ぜひ、ご一読いただければと思います。

*1:能動態的に修飾するなら、「(誰かが)テストで摘出したバグ」と考えて、bugs someone has detected in testing みたいな感じでしょうけど、あまりそういう言い方はしなさそうです。

テスト自動化による効果としての工数削減を絵にすると

 最近ポエムしか書いていないのですが、今日も元気にポエム as a excuse(言い訳としてのポエム)です。
 「テスト自動化の目的は工数削減!」というのは筋悪な思考と言われがちですが、それをあえてお絵描きしてみました。

工数削減だけが嬉しさ?

 これまで、300時間かけて、AとBの手動リグレッションテストを行っていたとします(左下。数字は適当です)。このうち200時間分に相当するBを自動化することにしました。結果として、Bの実行にかかる工数が20時間になったとします(右下)*1

f:id:kz_suzuki:20211009153749p:plainf:id:kz_suzuki:20211009153843p:plain
手動テストを自動化して、工数を削減

 Cの180時間が、自動化によって削減できた工数です。
 全体では300時間(A+B+C)が120時間(A+B)になり、60%の工数削減を実現した!と言えなくもありません。ただこれだけだと、実行が手動から自動になって、所要工数が小さくなったことだけが嬉しさに見えますね。

できなかったことができるようになるのも嬉しさ

 自動化のご利益である「同じことを繰り返し実行できる」ことを活かすことができれば、こんな絵になります。

f:id:kz_suzuki:20211009154357p:plain
これまで実行できていなかったテストも、自動テストでカバーする

 この右側(DとE)は、「やりかったけど、できていなかった」テストです。手動でやると1,500時間(D+E)もかかるので手が出せていなかったけれど、自動化により150時間(D)に短縮されることで実行可能になったということを表しています。

 たとえば以下のようなものですね。

  1. ある機種ではテストできていたけど、それ以外の機種ではテストできていなかった。
  2. 連携する3rd party製品の特定のバージョンでしかシステムテストできていなかった。
  3. 実行できるテストパラメタの組み合わせが、少数に限られていた。
  4. リグレッションテストの頻度が低すぎた。

 もちろん、リスクを考慮したうえで不要と判断したテストであれば、自動化したからといって急に実行要になるわけではありません。一方で、本来はやるべきなんだけど、手動だとスケジュール的にどーーーしても無理。と涙をのんで落としているテストもあるでしょう。
 この「やりかったけど、できていなかった」範囲を自動テストでカバーすることで、テストのカバレッジを上げ、バグを見つける可能性を高めることができます。工数だけじゃなく、品質に寄与しているわけです。

「自動テストの効果」ってどれ?

 この絵をよく見ると、テストを増やすことで150時間(D)が「余分に」追加されています。自動化で削減したはずの180時間(C)のほとんどを食いつぶしていますね。自動テストの実装・メンテのコストを考えると、節約分を逆転することもあるかもしれません。つまり、「テストの工数は全然減ってない」と見なすこともできるわけです。

 自動テストの効果は、見る人によって変わります。
 今回のような単純なケースでも、以下3つの見方があるでしょう。

遠くから見ている人

「自動化したのに、テストにかかる時間は300時間(A+B+C)が270時間(A+B+D)になっただけで、10%の工数削減でしかない。どういうことだ!?」

もともと行っていたテストに注目する人

「300時間(A+B+C)が120時間(A+B)になったのだから、60%の工数削減だな。まあ、いいか。」

テスト実行全体に注目する人

「本来やるべきテストを手動で行うと1,800時間(A+B+C+D+E)かかっていたはずで、これが270時間(A+B+D)になったのだから、85%の工数削減である。しかもテストカバレッジが高まり、拾えるバグも増え、品質リスクを下げている。ヨシ!」

 ちょっと極端ですが、この辺の意識が合っていないと、「自動化って効果ないね」となりかねません。

まとめ

 単純な例で、自動化の効果の見え方について述べました。

 わかりやすいメトリクスとして「削減工数」を使うことは悪いとは思わないのですが、「何を測っているのか」「それは実態を表現できているのか」には注意を払わないないとマズいですよね。
 また工数削減を「一つの目標」にするのもいいのですが、「唯一の」「最終目標」にするとズレちゃうかなと。テスト工数ってプロダクトの価値とあまり関係のない指標なので。

 よく言われることですが、削減できた工数の一部をより良いテストの実現のための時間に充て、品質につなげることで、自動テストのご利益を最大限享受できるといいですね。

Automata"Automata" by the_junes is licensed under CC BY-NC 2.0

*1:自動化しても人の作業はゼロにはならないことを意味しています。

MTBF・MTTRなどを復習しておく

 和田卓人(@t_wada)さんの講演『質とスピード』の影響もあり、MTTR(Mean Time To Repair、平均復旧時間)という用語を聞く機会が増えてきたように思います。

speakerdeck.com

 情報処理技術者試験対策として、MTTRとその周辺の用語の復習をしておきましょう。

RAS

 RASとは、システムがどのくらい安定しているかを示す3つの属性、信頼性(Reliability)・可用性(Availability)・保全性*1Serviceability*2)をまとめて呼んだものです。

 これら3つの属性は、『JIS Z 8115:2000 ディペンダビリティ用語』では、以下のように定義されています。

信頼性
アイテムが与えられた条件の下で,与えられた期間,要求機能を遂行できる能力。

可用性
要求された外部資源が用意されたと仮定したとき,アイテムが与えられた条件で,与えられた時点,又は期間中,要求機能を実行できる状態にある能力。

保全性
与えられた使用条件で,規定の手順及び資源を用いて保全が実行されるとき,アイテムが要求機能を実行できる状態に保持されるか,又は修復される能力。

 正直あまりピンと来ないというか、信頼性と可用性の違いって何じゃい!ってなりますよね。
 ざっくりいうと、こうなります*3

  • 信頼性: 故障せずに稼働し続けられる時間はどのくらいか。
  • 保全性: 故障した状態が続く時間はどのくらいか。
  • 可用性: 全体の時間のうち、故障せずに稼働している時間の割合はどのくらいか。

 信頼性と保全性は絶対値、可用性は相対値って感じですかね。

MTBFとMTTR

 よく見る絵をここでも作ってみました。
 青い部分が稼働中、赤い部分が故障中です。

f:id:kz_suzuki:20210926090925p:plain
MTBFとMTTRのよくある絵

 MTBFは、これもJISによると「平均故障間動作時間」(Mean Operating Time Between Failures)と訳されています。
 故障と故障の間、つまり稼働している青い部分の平均値です。この例だと、(200+340+260+400)/4 = 300 ということになります。これが長ければ長いほど、信頼性の高いシステムと言えます。

 MTTRは、「平均復旧時間」です。
 復旧までにどのくらい時間がかかるかということなので、故障している時間、つまり赤い部分の平均値となります。この例だと、(6+2+12+4)/4 = 6 ということになります。短いほど復旧にかかる時間が短いということなので、保全性の高いシステムと言えます。

 可用性は、全体の時間のうち稼働している時間なので、MTBF/(MTBF+MTTR) = 300/(300+6) = 98.0% ということになります。

どちらを改善するのがいいのか

 MTBFが長くMTTRが短ければ最高ですし、MTBFが短くMTTRが長ければ最悪です。
 では、MTBFもMTTRも長いのと、MTBFもMTTRも短いのでは、どちらがよいのでしょうか?

  • MTBFもMTTRも長い: めったに障害にはならないけれど、ひとたび障害が起こると復旧まで時間がかかってしまう。
  • MTBFもMTTRも短い: 障害はそれなりに起こるけれど、起きた場合の復旧が速い。

 表現が恣意的かもしれませんし、提供するサービスにもよるでしょうが、後者をベターと考えるケースは多そうです。
 また、ソフトウェアの品質が直接的に顕れるMTBF・信頼性に比べて、短縮の努力がしやすいMTTR・保全性の改善を目指す方が有効だという捉え方もできるかもしれません。t_wadaさんはスライドの中で、MTTRを以下の3つに細分化し、この仕組みをSREが作るとしています。

  • TTD: Time To Detect、認知までの時間
  • TTE: Time To Engage、認知からエスカレーション、アサイン、対処開始までの時間
  • TTF: Time To Fix、対処開始から回復・緩和までの時間

 ハードウェアの世界で生まれたMTBF・MTTRをそのままソフトウェア信頼性の話に適用できるかは議論があるようですが、過去の自分たちと比較して継続的に改善するにはわかりやすいメトリクスに思えます。

余談: MTBFのJIS定義

 わたしが基本情報技術者試験を受けたn年前は、MTBFは「平均故障間隔」(Mean Time Between Failures)と教えられました。これは「ある故障の始まりから、次の故障の始まりまでの時間」の平均を表しているので、青い部分の幅ではなく、赤い部分の始まりから、次の赤い部分の始まりに対応します。(200+6) + (340+2) + (260+12) + (400+4) /4 = 306 ということになります。

 MTBFについて検索すると、平均故障間隔ではなく平均故障間動作時間の定義で説明されていることが多いようなので、この変更に対応しているようですね。

参考

*1:JISでは以下のように補足されています。

ソフトウェアアイテムの場合には,保守性と表現。
故障要因を修正したり,性能及びその他の特性を改善したり,環境の変化に合わせたりすることの容易さを表す数値化できない用語として用いられる場合がある。

*2:JISでは、ServiceabilityではなくMaintainabilityとなっている。

*3:可用性を最後にしているのは、可用性が信頼性と保全性から導かれるからです。

「ユーザ視点」とは何か

 「ユーザ視点」というキーワードが先日、ソフトウェアテスト/QA界隈でネタになっていました。
 ブロッコリーさんのこのスレッドです。

 「ユーザ視点をテストできるのは誰か?」という議論はさておき*1、そもそも「ユーザ視点」って何だろうという点について、思うところを書いてみたいと思います。
 語る人の数だけありそうな「ユーザ視点」の意味を知る由もなく、またわたし自身も複数の意味で使っていそうという前提でございます。いやっ考え浅すぎない!?というご意見もあろうかと思いますが、ご笑覧を。

とりあえずオレオレ定義

 わたしが第一に考える「ユーザ視点」というのは、「外部仕様や要件をあらためて問い直す姿勢」を意味しているようです。
 もう少しだけかみ砕くと、(あまりMECE的ではないのですが)以下の2つになります。

  1. 要件・仕様に合致しているのは前提として、「開発したこれって、ユーザが満足して使えるんだっけ」と我に返ること
  2. 各「部分」は正しくできたとして、「システム外も含めて業務*2全体はちゃんと流れるんだっけ」とシステムを業務の一部として見直すこと

みたいな感じです。

 たとえば図書館の業務のシステム化において、

  • ユーザの情報の登録・修正・削除を行う。
  • 蔵書の情報の登録・修正・削除を行う。
  • 蔵書の貸出・返却を行う。
  • 蔵書の貸出予約を行う。

といった機能の要件が出てきたとします。この要件は仕様として詳細化され、実装もうまくいき、テストでも個々の機能が仕様を満たしていることが言えたとしましょう。
 そのうえで、業務シナリオをイメージし、個々の機能に閉じない、システムの外も意識したテストを行ってみたとします。

 ここで初めて、「貸出予約のキャンセル機能がないな!? これで業務は回るっけ?」と気づくかもしれません*3。「性能要件」は満たしているけれど実際ユーザにとっては遅すぎたり、「画面遷移仕様」には完全に従っているけれどユーザにはまったく直観的でない遷移かもしれません。
 こういった問題を検出するのが、わたしの考える「ユーザ視点」です。

疑うことはけっこう難しい

 要件定義から仕様・設計を定め、実装し、それをテストする。
 この段階を踏む中で、エンジニアは多かれ少なかれ、「将来の変更は想定するにせよ、要件・仕様といった成果物は、現時点ではおおむね妥当なはずだ」と考えているのではないでしょうか。だからこそ、インシデントレポートに対する「仕様です」は強力かつ理不尽なチカラを持ちがちだし、「だとしたら仕様が適切ではないのでは」という説得は時に大きな労力を伴うことになります。

 開発成果物にもいろいろありますが、いわゆる「上流」で作られたものほど疑うのが難しくなってきます。要件ともなると、絶対無謬の存在のように捉えられかねませんし、覆すのも困難ですよね。
 ですが、要件もまた、神ならぬ人(発注者だったり、発注者の要求を整理した開発側メンバーだったり)が作ったもの。考え漏れ・記載漏れ、間違い、一貫性の欠如というのは紛れ込むものです。

 「ユーザ視点」というのはそういった潜在的な間違いを前提として、いつの間にか正しいと信じていたものを、「これ、大丈夫?」とあらためて問い直す行為なのかなとわたしは考えています。「ユーザ視点」という想像もつかないような職人芸があるわけではないと思いますが、かといって誰にでもできる簡単な作業とも思えません。

 テストエンジニアは、「作られたものにはおそらく間違いがあるだろう」という、ある意味悲観的な姿勢でレビューやテストに取り組みます。
 「すべてのものを疑い続ける」というのはなかなか大変なこと。インプットした様々な情報を、「正しいもの」としてテスト設計しながら、「正しくないかもしれないもの」として批判的にチェックするというのはジレンマです。このジレンマに日々さらされているテストエンジニアが、ユーザ視点というものに切り替えるスキルと経験を得やすいというのは考えられることだと思います。

あれ、これって・・・

 ここまで書いてみて、これってつまり、いわゆるvalidation(妥当性確認)の話なのかもしれないなと思えてきました。

妥当性確認(validation)【ISO-9000:2015】
客観的証拠を提示することによって,特定の意図された用途又は適用に関する要求事項が満たされていることを確認すること。

 ふと、レンガ職人の寓話を思い出します。
 「レンガは正しく積めたけど、大聖堂全体としてはちゃんとできてる?」と、レンガの壁からちょっと離れてみることが大切かなと考えています。

Helsinki Cathedral, White Night"Helsinki Cathedral, White Night" by Dimitry B is licensed under CC BY 2.0

*1:「ユーザ視点」が未定義なので、議論にならない気がする。。

*2:業務というと社内システムっぽいですが、そのシステムが提供しているフィーチャ一般のことだと思ってください。

*3:機能がまるっと抜けていることを検出するのがテストというのも遅すぎではありますが。

ソフトウェアそのものじゃないけど面白いアルゴリズムだなと思ったお話

この記事では、「プログラミングじゃないんだけど、すごくアルゴリズムっぽいな!」と思った話を2つ紹介します。タイトルそのままですね。

流量制御っぽい話

一つ目は、『ホルムヘッドの謎』という本からの紹介です。
本書は、国文学者・林望氏によるエッセイ集。英国を舞台の中心とした一つ一つのエッセイが含蓄と味わい、知識と考察に満ちていて、あっ「エッセイ」って本来こういうものなんだよな、単にその日あったことを書くのは「日記」なんだよ・・・と思い知らせてくれます。

エッセイの一つに、著者が絶賛してはばからない交通システム・「ラウンドアバウト」があります。
こんな構造の道路構造です。

The Cars At The Roundabout Go Round and Round..."The Cars At The Roundabout Go Round and Round..." by thienzieyung is licensed under CC BY 2.0

この写真だと四叉路くらいに見えますが信号はなく、入ってきた車が島の周りを回って、望む方向に出ていく、という形になっています。
本書によると、交通ルールは以下の通りです。

  1. なにはともあれ、ラウンドアバウトは一切の例外無く時計回りの一方通行である。
  2. そして、ともかくラウンドアバウトの内部に既に進入している車が全ての周辺流入路に対して絶対的優先通行権を有する
  3. 右側から来る車が優先権を持つので、ラウンドアバウトに入ろうと思うときはまず右から車が来ないかどうか確かめて、たといそれが自転車であろうと十トントラックであろうと、何らかの車が右からこのラウンドアバウトを周回してくるのを認めたら、その車が自分の前を通過してしまうまで周回路内に入ってはいけない
  4. もし、右から車が来ないことが容易に確認できる場合には、ラウンドアバウトに入るに際して一時停止するには及ばないので、安全を確認しつつそのまま進入してよい。
  5. 進入する道路から見てすぐ左隣の道に進みたいときは、左折信号を出しながら一番左の車線を進み、すぐに左折してラウンドアバウトを離脱する。
  6. それ以外の道に進みたいときは、右折信号を出しつつ進入してラウンドアバウトを周回し、目的の道の一つ前の道を過ぎたときに左折信号に切り換えて、目的の道に左折で入り、ラウンドアバウトを離脱する。

これはもう絵がないことには説明のしようもないので、東京海上日動さんのサイトから引用させていただきます。

f:id:kz_suzuki:20210815073136p:plain
ラウンドアバウトを通過するときのルールと注意点 (東京海上日動のサイトより)

上の絵で、たとえば赤の車が右折したければ、ラウンドアバウトに進入して270度ぐるっと回って抜けていくことで、論理的な右折をすることができます。
遠回りに見えますが、日本の普通の信号付き道路のように、対向車を伺いながら交差点の真ん中まで行き・・・とやるよりずっと安全に感じないでしょうか? また、クルマは常に時計回りなので、万一接触した際にも2台の車の相対速度が小さいという特性もあります。

右の道からの進入が続いたりすると、赤の車はいつまで経ってもラウンドアバウトに入れなくなるのではないか、と思えます。
しかし、車は右からだけでなく、左の道からも上の道からも入ってくるわけです。たとえば上から入ってくると、内部を進行を優先する原則から、右からの進入は保留せざるを得ません。すると下の車に進入のチャンスが生まれるというわけです。

面白いのは、「交通量の自然調節が行われる」(本書より)点。
どういうことか。

ラウンドアバウトでどれだけ車が通過するかは、経路によって異なります。
たとえば上の図で、左右方向の交通量が多く、上下方向は少ないとしましょう。左右方向にひっきりなしに車が流れていくと、上下方向からの車がラウンドアバウトに進入するタイミングがなくなるではないかと。
しかしそれでも、左右方向から来て上下方向に抜ける車がたまに現れるわけです。たとえば左からの緑の車が下に抜ける(論理的な右折をする)場合、その車が270度回る間に右からの流入をいったんせき止めることになります。その車が下に抜けることは左折信号から判断できるので、下からの赤の車は安心して進入できることになります。その赤の車がさらに左からの車の進入をせき止めて上の道に抜けるため、今度は上の道からの進入も可能になる、とこういうわけです。

しかしながら、B→D街道を直進する車の量は右折車両やA→C道の車の数に比しては圧倒的に多いだろうから、それだけ優先的にどんどん進むことができるというあんばいになる。つまりは、信号の時間をコンピュータで制御したりしなくとも、交通量の多寡によって、自然に自動的にラウンドアバウト内への流入量が制御される仕組みになっている*1

この見事な仕組み*2、流量制御のアルゴリズムっぽくないですかね?

強化学習っぽい話

こちらは『STATISTICS HACKS』からの紹介。
統計の本というと、抽象的な概念と数式が淡々と書かれていてだんだんつらくなっていくものなのですが、本書はその理論的な部分を、具体例や興味深い応用例で味付けしてくれており、最後まで読む気にさせてくれます。やたらとくだけた語り口に、訳者の方の苦労が偲ばれます。

本書で紹介しているのが、「どんどん強くなる三目並べ」の仕組みです。
用意するのは、以下だけ。

  • マッチ箱287個
    • 各マッチ箱は、三目並べでありうる盤面287パターンに対応している*3
      • たとえば、「真ん中にOが置かれて、あとはまだ空白」とか。これがマッチ箱の中に書かれている。
  • 9色の大量のビーズ
    • ビーズの色は、三目並べの9つのマスに対応している。
      • たとえば「真ん中のマスは赤」とか。
    • 各マッチ箱に、盤面に応じて選べるマスに対応するビーズだけを入れておく。
      • たとえば初期状態はすべてのマスが空なので、9色すべてのビーズを入れておく。一方「最後の一手」に対応する盤面では選べるマスが1つしかないので、そのマスに対応する1色のビーズだけを入れておくことになる。

これで準備完了。ゲームの進め方を引用します*4
なおゲーム自体は、地面の上にでも線を引いて行います。

  1. まずコンピュータの番だ。現在の盤面のマッチ箱を探す(第一手のときは、空白のもの)。目を閉じて適当にビーズを取り出す。
  2. ボード内の小石の色が示すマスにXを入れる。そのビーズを邪魔にならない場所に退ける。
  3. 自分が選んだ場所にOと記し、自分の番をこなす。
  4. 盤面は新しい配置になった。対応するマッチ箱の所に行って、ビーズを無作為に取り出す。ステップ2に戻る。
  5. 勝負がつくまでステップ2からステップ4までを繰り返す。
  6. コンピュータが負けた場合、マッチ箱から無作為に取り出したビーズを手にして、海に投げ込むことで罰する
  7. コンピュータが勝った場合、または引き分けた場合、ビーズを元のマッチ箱に戻し、同じ色のビーズを追加することで報酬を与える

一番最初のゲームでは、「コンピュータ」は可能な手すべてから、勝負の有利不利は関係なく、ランダムに(「目を閉じて」)手を選ぶことになります。
ですがゲームのたびに、負けにつながった手に対応するビーズが破棄され、勝ちにつながった手に対応するビーズが追加されるので、2ゲーム目以降、勝ちにつながる手を選ぶ確率がどんどん高くなっていくという仕組みです。

この章には明確に「強化」「学習」「罰する」「報酬を与える」という言葉が出てくるので、強化学習そのものにも見えるのですが、本書の原著が2006年でああり、そもそもこの話が雑誌に載ったのは1963年とのことで・・・先進が過ぎる。

まとめ

いかがでしたか?*5

「コンピュータっぽいことを人力でやる」話は、SFアンソロジー『折りたたみ北京』の中の一作、劉慈欣氏の『円』にも出てきます。周率を文字通り「人海戦術で」求める壮大なお話。

この『円』は、今話題の中国SF『三体』のエピソードを切り出したものとのこと。
『三体』自体も奇想天外なアイデアに満ちたスケールの大きいストーリーで、とてもお勧めです! わたしの好きなSFの条件って、「予想の上を行くファーストコンタクト」と「想像もつかないガジェット」なのですが、『三体』は特に後者、「智子(ソフォン)」と「宇宙社会学」がめちゃくちゃ効いていて、物語にガッシリとした芯を通しています。

興味のある方は、ぜひ!

三体

三体

Amazon

*1:ここでAが下、Bが左、Cが上、Dが右 に対応。

*2:こういった特性をもつラウンドアバウトですが、たとえば「全ての人が完全にルールを遵守する」ことを前提にしているといった欠点も紹介されています。

*3:ありうる盤面パターンのうち、回転・反転で同一になるものはを集約している。

*4:本文の「ココナッツ」を「マッチ箱」に、「小石」を「ビーズ」に読み替えている。他、一部修正

*5:未だにこの「いかがでしたか」ネタを愛している。