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

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

工数削減だけが嬉しさ？

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

手動テストを自動化して、工数を削減

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

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

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

これまで実行できていなかったテストも、自動テストでカバーする

　この右側（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" 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）・保全性*1（Serviceability*2）をまとめて呼んだものです。

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

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

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

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

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

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

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

MTBFとMTTR

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

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

参考

• 『Software Engineering - A Practical Approach』

  Software Engineering: A Practical Approach

• 質とスピード（2020秋100分拡大版）
• JIS Z 8115 : 2000
• JIS Z 8115 ディペンダビリティ（信頼性）用語の現状と将来

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

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

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

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

「ユーザ視点」とは何か

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

「QAなのでユーザー視点でテストできる」と言ったりするときの「ユーザー視点」の要素分解をしたい。（※私自身は、この言葉は言わないがよく聞く言葉）

「開発者はユーザー視点で見れないのか？」はNo（見れる）と思っていて、そこには結局「ユーザー視点」という単語で隠れている部分があると思う。

— broccoli (@nihonbuson) 2021年9月1日

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

とりあえずオレオレ定義

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

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

みたいな感じです。

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

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

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

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

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

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

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

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

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

あれ、これって・・・

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

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

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

"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..." by thienzieyung is licensed under CC BY 2.0

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

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

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

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

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

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

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

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

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

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

強化学習っぽい話

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

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・シリーズ 5036)

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

興味のある方は、ぜひ！

三体

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

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

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

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

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

積読をしがちなエンジニアに届けるケチケチ勉強法

新しいことについて学びたいんだけれど、まだ単語レベルの知識しかない。
書店に行ってみるとたくさん本があって、どれを選んで読んでいいかわからない。
仕方なくAmazonのレーティングとレビューを見て買ってみたものの、何か合わない。

そんな経験をしたことはないでしょうか。
わたしは超あります。でもそれなりのお金を払って買った本だから処分することもできず、積読。。。

本が「合わない」理由

買ってみた本が「合わない」理由はいくつかあります。

レベルが合わない

たとえば技術書にはそれぞれ、想定する読者がいます。気の利いた本なら、本の最初の部分に、その「想定する読者」や「前提知識」まで書いてくれています。これに合う本を読むことが大切です。

目的が合わない

技術の全体を俯瞰したい人と、その中の特定のことについて深掘りしたい人では、必要な本は違ってくるでしょう。
その人の目的と、本の意図が合っていないと、不幸なことになります。

デザインやノリが合わない

ぶっちゃけわたしは、表紙のジャケ買い、フォントの大きさと行間の広さ、「せっかくだからシリーズで揃えたい」みたいな、まったく本質的でない理由で技術書を選んで、1と2の理由で自分に合わず、失敗することが多いです。 でもそれくらい、見た目とか論調って大事なんですよ・・・それが合わないと買う気がしない。

以上のような理由で本を積んでしまうと、自分だけでなく、積まれてしまった本にとっても不幸です。

図書館貯蔵本濫読メソッド

そんな時にわたしが採用しているケチケチ勉強法・「図書館貯蔵本濫読メソッド」を紹介します。
やり方は単純。名前を付けるまでもない。

1. そのテーマの本をかたっぱしから図書館で借りる。
2. 難易度と、できればもう1軸くらいを見つけて、それぞれの本をマッピングしてみる。
3. 自分の目的とレベルに沿って、勉強に使う本を決める。
4. 選んだ本を買って勉強する。

これで、勉強を始めるコストが限りなく低くなります。

1. 図書館で借りまくる

図書館のWebサイトの検索は充実しているし、最寄りの図書館になくても市内であれば取り寄せしてくれたりもします。
「ソフトウェアテスト」なんて比較的マイナーな分野でも、意外に蔵書があったりします。わたしの地元だと6冊もありました。

当然ですが、図書館で扱う技術書のカバー率は高くなく、できるだけ「広く読まれる」本が多くなる傾向があります。
でも、右も左もわからないモノを学ぶのですから、その手の本で最初は十分なのです。

たとえばAWS（Amazon Web Services）について、すぐに借りられる本を4冊読んでみました。
なおこの時点での「読む」の目的は、深い理解ではなく、本の傾向をつかむことです。合わなければ読むのをやめて返せばいいです。

1. Amazon Web Services入門 ― 企業システムへの導入障壁を徹底解消
2. Amazon Web Services 徹底活用ガイド (日経BPムック)
3. AWSクラウドの基本と仕組み
4. Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂3版
5. Amazon Web Servicesインフラサービス活用大全 システム構築/自動化、データストア、高信頼化 (impress top gear) *1

2. 本をマッピングする

複数の本を読んでいくと、同じテーマを扱っていても、それぞれ立ち位置が微妙に異なることに気づきます。
AWSの本の場合だと、分類の軸として、「難易度」に加え、「ビジネス寄りか、技術寄りか」という軸があると感じました。

難易度というのは絶対的な尺度ではなく、自分が読んでみて平易と感じたか難解と感じたかという主観です。人によってもっている知識が違うので、他の人にとっては相対値ですね。

ビジネス⇔技術 という表現は妥当かわかりませんが、たとえば「オンプレの自社システムをパブリッククラウドの移行したいのだけれど、AWSのビジネス・課金・契約はどういうものなのかを知りたい人」*2と、「AWSにアカウントを作ってとりあえず触ってみたい人」*3では、必要とする本がまったく違います。

上の5冊をわたしの主観でマッピングすると、以下のようになりました。

AWSの本をマッピングしたマトリクス

図書館の本なので、「易しい」寄りの本が多いことがわかりますね。
当然ですが、このマトリクスのここにあるからいい本だ・悪い本だ、ということを意味していません。

3. 本を決める

わたしのレベルと目的を踏まえると、まずCを読んで全体を理解し、Dで手を動かしてみる、というのがよさそうに思えます。勉強の進め方は以下のようになります。

マトリクスから検討した勉強の針路

せっかくなので、CとDがどんな本か、紹介してみましょう。

AWSクラウドの基本と仕組み

↑この本は、AWSの主要サービスについて、技術的な解説も含めて概観的に網羅しています。全体を知りたい、忘れたときにぱっと概要を思い出したいという目的に合いそうです。
主要なサービス、VPC・S3・EC2・Lambdaなどについては、やや詳しく「このように使える」といったところまで説明されています。詳しい仕様や設定方法は対象外です。

Amazon Web Services 基礎からのネットワーク＆サーバー構築　改訂3版

↑こちらは、AWSを実際に使ってWordPressのサービスを立ち上げるところまでを案内しています。そのために必要なAWSサービスに解説を絞っている代わりに、スクリーンショットレベルで手順を詳説するものです。
また、AWS以前に必要な知識、たとえばネットワークなら、IPアドレス・DNS・ルーティングといった技術の基本的な解説もカバーしているため、「AWS以前の勉強から必要だった・・・」とならないですむようになっています。スクショ＆基本技術解説となると分厚くなりそうなものなのですが、200ページちょっとで収めているのがすごい。

4. 勉強する！

するだけです。簡単ですね？*4

図書館で借りられる本の特徴と注意点

特徴

• 書店では手に入りづらいムック（日経BPがよく出してる）を入手しやすい。
• 資格関連の本はあまりないかも。たとえばAWSだと、認定関連の本が少なかったです。
• 古い本も混じってきます。たとえばAWSについて調べるのに、5年前の本だときっと古い情報も多いでしょう。

注意点

• いっぺんに借りると、同じテーマを勉強したい人に迷惑なので、避けましょう。
• 技術書に限らず、人気のある本、良い本は貸出中の可能性も高いので、「そうでない本」が手元に集まりやすいという欠点があります。
• 「イイ！」と思った本は、著者の方に感謝し、お金を出して買いましょう。
• いや、公式ドキュメント読めよ！というのはその通りなので、次のステップではそうしましょう・・・。

レビューコメント

Amazonのレビューは参考になりますが、レビュアがその「想定する読者」に合っていたのかどうかまではわかりません。
たとえば「初歩的なことしか書いておらず、実務ではまったく使えない」というレビュー。レベル5の人向けに書いた本をレベル10の人が読めば、そうなるでしょう。でもレベル5の人には必要十分かもしれません。

このようなレビューコメントを見てしまうと、買うのにちょっと躊躇してしまいますよね。
なのでAmazonの評価はあまり気にしない方がいいですが、「事実誤認が多い」とか「内容が古い」、この辺は多少気にした方がよさそうです。

まとめ

図書館を利用して合う本を見つけ、合う本には金を払い、合う本で勉強しましょう。

"YDS Library" by Chris and Amy Stroup is licensed under CC BY-NC 2.0

*1:この本は図書館ではなく、買った本。

*2:こういう方向けには導入として、上のAの本が合うと思います。

*3:こういう方向けには、上のBの本もいいでしょう。

*4:と書くととても勉強している風ですが、自分を追い込むだけのプレッシャーにすぎません。