“インプット”のこと （T3:Pt0:Ch02)
“インプット”、していますか。
建築家のスケッチ展で思ったこと
今年(2024年)の7月に、友人の建築家が開いた個展を訪れました。
建築家として独立する直前に一年ほどヨーロッパを旅し、訪れた先先で描きためたスケッチ、30年間倉庫に眠っていたというその一部を、訪問地ごとに分けて壁に貼り出した展覧会でした。
(https://x.com/NobMoti/status/1815226030694727808)
友人のヨーロッパスケッチ旅行話はどれも楽しく興味深いものでしたが、ひときわ印象に残ったのが、ある絵の前で話してくれた
「ある建築家の建物が好きで、ここにはどうしても行きたかった。
後年、自分がある建物の設計を手がける時に参考にした（インスパイアを受けた）」
というエピソードです。
その話を聞いた後は、たくさんの絵を観ながら、
……何であれ、「（現地に行って）現物を見る」のは大切だよな……
……建築物は、写真で一部分（限られたアングルからの、限られた画角）を見るだけでは感じ取れることが少ないだろうというのは、素人でも想像がつく。だから「現物を見る」重要性は高まる。その「実際に現物を見た」経験が、自身のデザインの「抽斗」への貴重な入力になる……
……見るだけでも大きな刺激、勉強かも知れないけれど、見て感じたことを「描く」ことが、その効果を高める……美術(絵画や彫刻など)もそうだし……
……「自分の手を動かして描く」は、「見た」こと、「見て感じたこと」をアウトプットしながら、脳にインプットする手段……
……これは「技芸」に類することなら何にでも当てはまるだろうし、(当然)ソフトウェアの仕事にも通じる（んだ）よな……
そんなことを改めて思い起こしていました。なんだか当たり前のことと感じてその大切さを忘れてしまっていた気がする。
以降は筆者の話です。
Cの思い出
美術や音楽、スポーツや芸事、自然言語の習得と“同じ”で、
プログラミング言語、プログラムやソフトウェアのデザインも、
教科書や参考書や実際のプログラム(コード)を「読む＝インプット」が大事なのは言うまでもありませんが、自分で書いてみて（それも結構相当な量を書いて）やっと自分の抽斗に入れられるものです。
「書く＝インプット」でもある、というか、フィードバックループみたいなものでしょう。
プログラミング言語のレベル(文法や組み込み関数/標準ライブラリの使い方など)ですが、三年目になったばかりの頃、三ヶ月くらいプログラムを書かない時間を挟んだら、確か構造体の定義や参照・代入が書けず、愕然としたことを思い出します。
二年間勉強と実作を続けてCはひと通り覚えたつもりでいたけれど、必要な時に咄嗟に呼び出せるレベルではなかったということでしょう。
「書く＝インプット」ソフトウェアデザイン編
データ構造とアルゴリズム、プログラムのデザインやソフトウェのデザインでも、よい教科書や参考書はたくさんありますが、読むだけでは「ふんふん。(なんか)判った(気がする)」で終わってしまいがち。
自分の手を動かし、実際に書いてみることで、実際にやったらどうなるかをイメージできるし、“勘所”とでもいうべき箇所の感覚を得られる。
（なおその際、書かれてあることをなぞるにせよ、自分の目的に合わせてアレンジするにせよ、「実際に動くプログラム作例」「本気の設計実例」に習うのは大切です）
しかし……
プログラミング言語、アルゴリズム、プログラムの構造のデザインといった相対的に低水準の世界では、「自分の手で書く＝インプット」は実践しやすいですが、
相対的に高水準――規模が大きくなり複雑さが増すソフトウェアのデザインレベルになると、「本気の実作例」に習うのは難しくなります。
「本気の実作例」自体になかなかお目にかかれませんし、あったとして、それを参考に書いてみるのも時間がかかってしまう。
筆者の場合は、OSやコンパイラの解説書などで、責務の分担の考え方やアーキテクチャの考え方、階層(レイヤー)の考え方を「読んで理解したつもり」になるのがせいぜいって感じでした。自分の手を動かせない代わりに？ たくさん読みましたが。
「書く＝インプット」テストデザイン編
テスト技法のトレーニングをしていると、「技法の理屈というか考え方は判ったが、実務で使えるかどうか判らない」という受講者によく出会います。
これも「自分の手を動かせていない（から、その技法の“勘所”が判った感じがしない）」でしょうが、トレーニング(研修)の場の制約を考えると原因には2通りありそうです。
①実際に問題を解いてみる、その時間が少ない
トレーニングでは時間の制約から「小さな問題を、たかだか数問」程度しか解く時間を取れません。
弊社のトレーニングでは、例題やワークを多く用意し、ワークの時間も長くとるように努めていますが、問題を数多く消化することで理解を深めるなら、フィーチャーや仕様が異なる問題を多数解くのが望ましいでしょう。
②「本気の実例を相手にする」に匹敵する経験ができない
トレーニングの例題やワークは、諸諸の制約から「本気の事例」をトリミングした「規模も小さくノイズもない、要点だけ絞ったきれいな問題」になりがちです。
問題を解く達成感はあっても、「実際のテスト対象でこんな風に使うのか」という“勘所”をつかみづらいという感想を抱くのは理解できます。
（ひとつの大きめの問題に丸一日かけて取り組めるワークショップもございます。ぜひご利用ください）
③テスト技法の例題やワークは「技法を理解し習得する」のが目的だが、「この技法はどんな対象に使えるのか」「どんな対象にはどの技法がいいのか」を考えるのには向いていない
これがけっこう大きな課題ではないかと思っているんですが、テスト技法のトレーニングの域を超えています。
「デザインを学ぶ」というよりは「プロセスを学ぶ」の域かも知れません。
テスト分析で「書く＝インプット」……
テスト分析～初期のテスト設計は、教科書、参考書の類も少なく、また「本気の実例」を相手にしての「書く＝インプット」がしづらいプロセスです。
テスト分析について、ISTQBのシラバスやISO/IEC/IEEE 29119（テスト分析という用語は出てきませんが）の記述は抽象度が高く、「実際のテスト対象を前にして、テスト分析という作業にどう取り組むか」の解説はまだまだ多くありません。
テスト分析活動の実際について、「本気の実例」を使って丁寧に解説する参考書類がもっと増えてくれたらいいのにと願っています。
（ASTERが開催しているテスト設計コンテストは数少ない例かと思いますが、コンテストでなくてよいんですよね……）
ISTQBシラバスの記述を読んでやるべきことが何となく判る、という人なら、「本気の実例」で“手を動かす”のは難しいことではありません。
私たちの身の回りにはソフトウェア製品やソフトウェアを使った製品には事欠きませんから、目についたそれらについて、何をテストするとよいか、見つけたテスト条件についてどんなテストをするのがよいかを考えてみるのは、時間さえあればいつでもできます。
そしてそれは、テストの達人と呼ばれる人が何の気なしに日々やっていることでもあります。
むすび
(･ω･｡)｡｡oＯ（建築家の個展での感想をもとに心に浮かんだことを文に認めましたが、エッセイというか随筆みたいになりました）
(･ω･｡)｡｡oＯ（書いていて思ったんですが、最近の人はソフトウェアの勉強をするのに「書物」を読んだりしているのでしょうか？……「ネット上で記事を漁って勉強した」「動画で勉強した」だったりして？……）
(2024-10-31 R001)