先日、次女が保育園から「びくびくビリー」（アンソニー・ブラウン作、評論社）という絵本を借りてきました。次女にせがまれて読み聞かせをしているうちに、この本はメンタルヘルスマネジメントの物語だ、今のご時世を生き抜く大人にこそ必要なことが書かれている、と思いました。

　今回は、「びくびくビリー」の紹介と私が読んで思ったことを書いてみようと思います。

■「びくびくビリー」あらすじ

　この物語の主人公、ビリーは心配事がたくさんあっていつもびくびくしている男の子。パパやママになぐさめられても心配をやめることができません。あるとき、ビリーはおばあちゃんから「しんぱいひきうけにんぎょう」なる人形をもらいます。おばあちゃんの言うとおりに「しんぱいひきうけにんぎょう」に心配事を打ち明けて枕の下に入れて眠るとあら不思議、ビリーは心配をすることなくぐっすりと眠れるようになりました。

　ところが数日後、ビリーには新しい心配事ができてまた眠れなくなってしまいます。ビリーはそれを解消するためにある行動に出る......というお話です。

　ビリーがおばあちゃんからもらう「しんぱいひきうけにんぎょう」は中米のグアテマラに古くから伝わる人形です。マッチ棒くらいの大きさのこの人形に心配事を打ち明けてから枕の下に入れて眠ると、人形が代わりに心配事を引き受けてくれるのでぐっすり眠れるようになる、という言い伝えがあります。

■ビリーの心配を受け止めるおばあちゃん

　このお話を読んで、最初にはっとしたのはビリーのおばあちゃんの対応です。

　心配をやめられないビリーに対して、まずはパパとママがそれぞれ言葉でなぐさめます。「怖いことなんかない」「お前は考えすぎだ」「パパとママがついているから大丈夫」などなど。しかし、これらの言葉を聞いてもビリーの気持ちが晴れることはありません。

　しかし、心配で眠れないというビリーの言葉を聞いたおばあちゃんはまず「そうだったのかい」とビリーの気持ちを受け止めます。その後で、「おばあちゃんも子どものころは心配ばかりしていた」と語ります。

　子どもであるビリーにとっては、大人は心配なんかしたことがない完璧超人に見えているかもしれません。だからおばあちゃんの「子どものころは心配ばかりしていた」という言葉は新鮮だったことだと思います。

　逆の立場から考えると、子どもの心配は大人からしてみたらたいしたことがない、それこそ心配するだけ無駄なことかもしれません。しかし、子ども自身は真剣に心配しているのです。

　これは子どもと大人だけでなく、部下と上司、先輩と後輩といった大人同士の立場でも起こりうることかもしれません。私も親として、子どもが心配しているときにその気持をちゃんと受け止められているかどうか、思わず我が身を振り返ってしまいました。

■声に出して読みたい心配事

　ビリーがおばあちゃんからもらった「しんぱいひきうけにんぎょう」。人形を相手に心配事を声に出して打ち明ける、ここに心配事を解消する大きなヒントがありそうです。

　心配事を頭の中で考えるのではなく、声に出して打ち明ける。これだけで「今、自分は何を心配しているのか」がはっきり見えてきます。心配事の正体がわかってしまえばそれを解消する手がかりがつかめます。たとえすぐに心配事を解消するための方法が見つからなくても、漠然とした不安からは逃れられるでしょう。

　また、打ち明ける相手が物言わぬ人形というところもポイントです。もし打ち明ける相手が人間だと、話の途中で「でも」「ちょっと待って」と横槍を入れたり、「そんなしょうもないこと心配してるんだ、ダッサwww」などと茶化してきたりする可能性があります。

　しかし、人形であればまとまりのない話でも余計な口出しをせずに最後まで黙って聞いてくれます。おまけに、聞いた話を絶対に他の人に漏らしたりしません。

　「しんぱいひきうけにんぎょう」は単なる気休めやおまじないではなく、メンタルヘルスマネジメントの観点から考えてもちゃんと理にかなった存在だと思います。この人形を生み出したグアテマラの人の生活の知恵を感じます。

■心配を解消する方法を知ればもう怖くない

　「しんぱいひきうけにんぎょう」のおかげで一度は心配せずに眠れるようになったビリーでしたが、また新たな心配に見舞われます。しかし、ビリーはその心配を自分の力で解消してしまいます。それから、ビリーはびくびくすることが少なくなりました。

　ビリーは「しんぱいひきうけにんぎょう」によって単に心配をなくすだけでなく、「心配を自分で解消する力と自信」を手に入れた、ということが大きいと思います。

　心配事、というのはやっかいなもので、ひとつ解消してもまたすぐに別の心配事がやってきてしまいます。特に今のコロナ禍においては、心配事とは無縁の人はおそらくいないことでしょう。

　それでなくても、生きていれば心配事は避けられません。それでも、心配事を解消するための手段と、「自分には心配事を解消する力がある」という自信があれば、そこまで恐れることはないのかもしれません。

　今回は、次女が借りてきた絵本から考察を広げてみました。子どもや、子ども向けの絵本から大人が学べることは多いと思ったお話でした。

先日、カミュの「ペスト」という小説を読みました。2年ほど前、Eテレの「100分de名著」というテレビ番組でこの小説が紹介されていたのですが、そのときは興味をひかれつつも原典を読む機会がないままになっていました。

しかし、ここ数ヶ月のうちに新型コロナウイルスが世界中に拡がっていく様子をみて「これってまるで番組で見た『ペスト』の世界そのままじゃないか」と思うようになりました。ちょうどそのタイミングで、「100分de名著」の「ペスト」の回が再放送されることになり、この機会にちゃんと原典を読んでみようと思い書店に向かいました。

今回は、「ペスト」を読んで、いまこの世界で何が起こっているのか、このご時世にわたしにできることは何かを考えてみました。

■「ペスト」とは

小説「ペスト」は、ノーベル文学賞作家アルベール・カミュの代表作のひとつです。ペストが蔓延し、外部と完全に遮断されたアルジェの街オランを舞台に、医師リウーをはじめとする街の人々がペストに立ち向かう姿を描いた長編小説です。

ペストという「不条理」に直面したとき、人はどのように考え、行動するのか。「不条理」のなかで、それでも生きてゆくとはどういうことなのか。第二次大戦、ナチスドイツ占領という「不条理」を目の当たりにしたカミュ自身の体験が暗喩として描かれています。

■言葉の限界

物語は、主人公の医師リウーが、自宅のアパートで一匹のネズミの死骸につまずくところから始まります。そのときはそれほど気にも留めなかったリウーですが、ネズミの死骸は街に増え続け、最初の異変からわずか2週間ほどで原因不明の病気に倒れる人が続出します。ペストを疑うリウーですが、役人たちは責任を負うことを恐れてなかなかペストであることを認めようとしません。役所の対応が後手に回るうちに死者は増え続け、とうとう植民地総統府の命令によりオランの街は封鎖されます（今でいうロックダウンです）。

ネズミの死骸を見つけてから街にペストが蔓延しはじめるまでの時間の短さ、官僚的なしがらみによる対応の遅れ、街が封鎖されたあとも現実を受け入れられず「自分だけは感染しない」と言わんばかりに繁華街へと繰り出す市民たち......何から何まで現在のわたしたちの世界と同じで戦慄を覚えるほどです。

特にわたしが目をひかれたのは、封鎖された後のオランの人々のコミュニケーションについてです。街が封鎖された後は当然、人の出入りは一切できなくなりました。街の外にいる家族や友人、恋人と連絡を取るにも、手紙は病原菌を媒介する恐れがあるとして禁止されました。電話も回線のパンクを避けるために、冠婚葬祭レベルの緊急性の高い連絡以外には使えなくなってしまいました。

そうなると、残された手段は電報のみです。ところが、電報は文字数に制限があります。自分の気持ちや考えが限られた文字数、限られた言葉でしか伝えられないということです。さらに、街に取り残された人同士の会話でも、自分の気持ちを打ち明けても完全には伝わらない、それによって返ってくる返事が期待とは異なって傷ついてしまう、といったことが起こります。

わたしはこのくだりを読んで、これは現代のSNSと同じじゃないかと思いました。カミュがこの小説を書いた約70年前から通信手段はいくらか発達したかもしれませんが、言葉やコミュニケーションの本質はなにひとつ変わっていないことに愕然としました。言葉を生業にしていたカミュが、言葉の限界について描写しているということは興味深いです。

■疫病の中で快適に暮らす人たち

街が閉鎖され、ペストが猛威を振るってくるとオランの市民は絶望と恐怖、そして無気力にさいなまれていきました。しかし、ただひとりコタールという男だけは上機嫌でした。このコタールは密売に関わっており、街が封鎖される前は逮捕されることにおびえて自殺未遂までした人物です。ところが、街が封鎖されるとまず逮捕の心配がなくなりました。さらに、市民がペストの恐怖におびえているのを見て、かつて逮捕におびえていた自分と重ねて一体感を覚えます。そしてリウーたちの前で「ペストの中で暮らすほうが快適だ」とさえ言い放ちます。

これだけ書くとコタールとはなんともいけ好かない人物ですが、しかしカミュはコタールのことをどうしようもない極悪人のようには描いていません。実際、リウーはコタールと街中で出会ったときに会話はしますが、決して彼を非難したり説教をしたりはしません。このような状況になれば、必ずコタールのような人間も現れる、それも含めて人間の本質というものなのだ、というカミュの考えが見て取れます。

ところで今のこの状況、新型コロナウイルスの流行で世の中が不安と混乱に包まれている中のほうが快適だという人間はどんな人間でしょうか。わたしは、マスクなどを買い占めて高値で転売する人、不安につけこんだ詐欺をはたらく人、わざとデマやフェイクニュースを拡散させてますます世間を混乱させてやろうとたくらむ人、などがそうなのかなと思います。このような人が完全にいなくなることはないでしょう。しかし、こういう状況になれば必ずコタールのような人間が現れる、ということを心に留めておけば、適度な距離を取りつつ付き合っていくことができるかもしれません。

■人知れず活躍する冴えないおっさんが街を救うのかもしれない

リウーはペストと闘うため、友人タルーとともに、市民有志による「保健隊」を結成しました。保健隊は、各地区の衛生状態の調査や消毒、ペスト患者の搬送の手続きなど、医師のサポートや役人の手の回らない仕事を引き受けました。

この保健隊のメンバーに、グランという小役人がいました。彼は役人とはいっても臨時職員で給料は安く、女房には逃げられ、唯一の楽しみは誰にも見せない小説を書くこと、しかも納得のいく作品にしたくて冒頭の一文だけを何度も書き直しているという、一言でいえば「冴えないおっさん」です。

しかし、この冴えないおっさんであるグランが保健隊で思わぬ活躍を見せます。役所で登録や統計の仕事をしているグランは、いつしか保健隊の幹事役を果たしていました。それでも、別にヒーローとして持ち上げられることもなく、ささやかな仕事でみんなの役に立ちたいといい淡々と保健隊の仕事に励みます。ときには保健隊の仕事に入れ込むあまり本業がおろそかになって上司に叱られたり、自分が書いている小説の一文を書き直すたびにリウーたちに得意げに読んで聞かせてみたり、最後まで冴えない、けれど愛すべきおっさんとして描かれています。

決して顔も名前も出ることがないけれど、自分にできることを精いっぱいやっている。今、人知れず活躍しているグランのような人が世界中にたくさんいるのだと思うと、ありがたくもあり心強くもあります。

■それで、結局わたしにできることは何だ？

オランの街の封鎖から約10ヶ月後、ペストは下火となりついに封鎖が解除される日がやってきます。今の新型コロナウイルスが落ち着いて緊急事態宣言や自粛ムードが解除されるのがいつになるのか、現段階ではわかりません。もしかしたら、10ヶ月といわずもっと長い期間になるかもしれません。

まあ、いつかは終わると思いますが、それがいつかは現段階では誰にもわかりません。主婦である今のわたしにできることは、家族の健康を守ることくらいでしょうか。医療関係者などと比べると、あまりにも小さいなあと思います。わたしはグランのことを「冴えないおっさん」だなんて言えませんね。

「ペスト」の終盤、物語の語り手であるリウーは、ペストとの闘いの日々で得た知識と記憶を後世のために書き綴ってきたことを告白します。リウーは、いつかペストがよみがえる日が必ず来るであろうことに思いを馳せながらこの物語を閉じます。「ペスト」の執筆から約70年経って、それが現実になるとはさすがにカミュもリウーも想像できなかったことでしょう。しかし、わたしを含め多くの人が今の時代に「ペスト」を読んでいろいろなことを考えたりしているということは、カミュとリウーの知識と記憶がちゃんと受け継がれているということかもしれません。

わたしも今回のことで得た知識と記憶を、コラムを含め何かの形で残そうと思います。

　ちょっと前に、エンジニアライフで書評が流行っていましたね。わたしはエンジニアを引退して3歳と1歳の子どもの育児中なので、読む本といえばもっぱら絵本ばかりになってしまいました。

　子どもたちはふたりとも絵本が大好きで、お気に入りの絵本を一日に何度も「読んで」と催促します。かわいい子どもたちのためなら、同じ絵本を何度も読むことになっても苦ではありません（嘘です、たまにキツいです。一時期ノンタンは見るのも嫌になったことがあります。今は慣れました）。

　そういうわけなので、本屋さんに行くと必ず絵本のコーナーに立ち寄ります。絵本のコーナーには、「はらぺこあおむし」「からすのパンやさん」など、わたしが子どものころに読んだ定番の絵本もあれば、ボタンを押すと音が鳴る絵本、仕掛け絵本、外国の絵本など色々あって、なかなか楽しいものです。

　そのなかに、エンジニアが主人公の絵本がいくつかありました。わたしは女の子の母親なので、そのなかでも女性エンジニアが主人公の絵本に惹かれるものを感じました。というわけで、このコラムでは女性エンジニアの絵本を3冊、紹介したいと思います。

　コラムのタイトルには「エンジニアになりたい女の子」と書きましたが、もちろん男の子が読んでも、大人が読んでも楽しめる絵本だと思います。

■世界でさいしょのプログラマー――エイダ・ラブレスのものがたり

　エンジニアであれば、「世界初のプログラマは女性だった」という小ネタを耳にしたことがあると思います。その女性がエイダ・ラブレスという名前であることを知っている、という方も多いと思います。

　しかし、そのエイダ・ラブレスがどのような人生を歩んだのか、何をきっかけにプログラマになったのかを知っている人は意外と少ないのではないでしょうか。

　「世界でさいしょのプログラマー――エイダ・ラブレスのものがたり」（フィオナ・ロビンソン作、評論社）は、世界初のプログラマとなったエイダ・ラブレスの生涯が描かれています。

　エイダ・ラブレスは、1815年のイギリスに、詩人バイロンと数学者アン・イザベラ・ミルバンクの娘として生まれました。しかし、エイダが生まれてわずか1ヶ月で両親は離婚、エイダの母アンは彼女を連れて家を飛び出し、二度とバイロンに会うことはありませんでした。

　数学者であったアンは、幼いエイダに数学をみっちりと勉強させました。当時、イギリスでは産業革命が興り、上流階級の子女のあいだで工場見学が一大ブームとなりました。エイダも、母に連れられて工場を見学するうちに、機械にも興味を持つようになってきました。

　そしてエイダが17歳になったとき、転機が訪れます。発明家のチャールズ・バベッジに出会い、彼の発明品のひとつである「階差機関（ディファレンス・エンジン）」の試作品を見せてもらったのです。これは複雑な計算を人間よりも早く正確に行うことができる計算機でした。

　バベッジは階差機関をさらに発展させて、「解析機関（アナリティカル・エンジン）」の開発に取り掛かりました。これは機械に穴の空いたパンチカードを読み込ませて、計算結果を印刷できるという現代のコンピュータの原型ともなるものでした。このときラブレス伯爵と結婚して3児の母となっていたエイダは、パンチカードに書き込む計算式や、その解説書の作成に取り組みました。エイダが「世界初のプログラマ」となった瞬間でした。

　しかし、残念ながらバベッジの解析機関は世間の無理解と予算不足のため未完成に終わり、エイダも36歳の若さで世を去ってしまいました。世界初のコンピュータが作られて、エイダのプログラマとしての能力が認められるようになるのはそれから約100年後のことです。

　わたしはエイダ・ラブレスの名前はうっすらと知っていましたが、彼女が詩人バイロンの娘であること、若くして亡くなってしまったことは知りませんでした。エイダは解析機関の解説書に、「この機械を使えば計算だけでなく、絵や音楽、文章までもプログラムできる」と書いていました。今ではAI（人工知能）がそれを可能にしていますね。21世紀になってようやく時代がエイダに追いついたのかもしれません。

　また、わたしが個人的に気になったのはエイダの母アンのエピソードです。アンはエイダに数学だけではなく、上流階級の娘にふさわしい教養とたしなみを身に着けさせました。しかし、詩だけは絶対に教えようとしませんでした。エイダの父バイロンは素晴らしい詩人ではありましたが、自由奔放すぎる性格で夫婦関係を破綻させてしまいました。アンはエイダを父親のような人間にしたくなかったので詩には触れさせまいとしたのです。

　しかし、そんな母親の思惑とはうらはらに、エイダは成長とともにみずみずしい感性と想像力を発揮していきました。少女時代には蒸気の力で空飛ぶ馬を夢見て、大人になってからはまだ見ぬコンピュータの可能性にまで想像の翼を広げました。

　現代でも、「子どもをオタクにしたくない」と言って子どもにアニメを見せない、ゲームもさせないという親がいますが、いつの時代であってもこういう親は存在するのですね。しかし、たとえ親が子どもを制限しても、子どもの「好き」を止めることはできないということを忘れてはいけません。

■グレース・ホッパー――プログラミングの女王

　エイダ・ラブレスが亡くなって約50年後、1906年のアメリカでひとりの女の子が誕生しました。彼女の名前はグレース。後にアメリカ海軍で計算機科学者として大活躍し、「アメージング・グレース」と呼ばれることになるグレース・ホッパーその人です。

　「グレース・ホッパー――プログラミングの女王」（ローリー・ウォールマーク作、岩崎書店）には、そんなグレース・ホッパーの生涯と功績が描かれています。

　グレースは好奇心旺盛な少女で、機械をいじるのが大好きでした。時計を分解して仕組みを確かめたり、おもちゃのドールハウスにモーターと工具で人形のためのエレベーターを取り付けたりしました。

　大学で数学を修めたグレースは数学教師となりましたが、ときは第二次世界大戦前夜。アメリカ海軍では新兵器の開発のため優秀な数学者を必要としていました。当時36歳、体格も小柄なグレースは入隊を志願するものの年齢と体格のためにすぐには認めてもらえず、1年以上かけて海軍を説得しました。

　海軍に入ったグレースは、コンピュータ「Mark I」のプログラム開発に携わりました。ある日、新型コンピュータ「Mark II」が突然動かなくなってしまいました。グレースと技術者たちがコンピュータの内部を調べてみたところ、一匹の蛾が回路の間に挟まっていました。グレースはこの蛾をコンピュータから取り除いて業務日誌に貼り付け、「本物のバグが『不具合（バグ）』として発見されたはじめての例」と書き記しました。この一件からプログラムの不具合のことを「バグ」と呼ぶようになった、というのは有名なエピソードですね。

　さて、この時代のコンピュータプログラムは「1」と「0」のみの機械語で記述されていました。しかしこれでは人間には理解しづらいうえに、入力ミスもしょっちゅう起こります。おまけに、ミスした箇所を特定するにも一苦労です。

　グレースは、人間の言葉を用いてわかりやすくプログラミングをできる方法を考えました。当時最新のコンピュータであった「UNIVAC I」を用いて、「FLOW-MATIC」というコンパイラ言語を開発しました。これは、のちのCOBOLの原型となりました。

　海軍で計算機科学者として働いてきたグレースですが、60歳になると年齢を理由に退官させられてしまいます。しかし、すぐに「6ヶ月だけ」という条件で呼び戻されることになりました。現役復帰したグレースは、そのまま海軍で20年近く働き続けました。79歳で退役したとき、かつて海軍に入隊拒否された女性は准将にまで出世していました。

　グレースの人生は新記録の連続でした。女性初の数学博士号の取得、世界初のコンパイラ言語の開発、海軍最年長の士官、最高位勲章の授与、コンピュータ歴史博物館の第1回フェロー、まさにアメージングな人生ですが、そこに至るまでは現代では想像もつかないような苦労、苦悩があったと思います。

　グレースの言葉です。「人は変化が怖いのです。『今までと同じで何が悪い』そんな考えには反対です」わたしも普段の生活のなかで「これでいいとは思えないけど、いろいろ変えるのも面倒だし今のままでいいや」と思ってしまうことがあります。そんなとき、グレースの言葉にハッとさせられます。

■月とアポロとマーガレット――月着陸をささえたプログラマー」

　グレース・ホッパーが海軍に復帰してしばらく経った1969年、アメリカのアポロ11号が人類初の月着陸に成功しました。この功績の裏側で、ひとりの女性が人知れず活躍していました。彼女の名前はマーガレット・ハミルトン。NASAの女性プログラマです。

　「月とアポロとマーガレット――月着陸をささえたプログラマー」（ディーン・ロビンズ作、評論社）は、アポロ計画を影で支えた女性プログラマのお話です。

　幼き日のマーガレットは数学と宇宙に興味を持つ女の子。詩人で哲学者の父親から宇宙の話を聞いたり、夜空を眺めたりするのが大好きでした。そんなマーガレットが出会ったものがコンピュータでした。マーガレットはコンピュータに触れながらコードの書き方を学び、飛行機を追跡するプログラムや、天気予報のプログラムを作成しました。その業績が認められ、マーガレットはアポロ計画のソフトウェア開発責任者となりました。

　マーガレットにとって、いえ、人類にとって、「人間を月に送り込む」というのははじめての試みでした。月と地球は約38万キロメートル離れているので、月にたどり着く途中や、月に到着してからトラブルが起こってもすぐには地球に引き返せません。もちろん、誰かが救助に駆けつけたりすることもできません。

　マーガレットは月までの旅で起こり得るリスクを考え、その解決方法をプログラムに落とし込みました。そしていよいよアポロ11号打ち上げのときがやってきました。月への旅は順調でしたが、月着陸船「イーグル」が月面に降り立つまであと数分、というところで突然トラブルが発生しました。コンピュータの動作に重い負荷がかかってしまったのです。この状況を救ったのが、マーガレットがコンピュータにあらかじめ仕込んであったプログラムでした。より優先度の高い命令を先に実行するコードのおかげで、コンピュータは正常な動作を取り戻し、イーグルは無事に月面に着陸しました。

　思わぬピンチに皆が慌てるなか「こんなこともあろうかと！」とあらかじめ打っておいた手を繰り出す、というのはよくあるパターンです。しかし、それができるのはあらゆるリスクを事前に予測し、それぞれのリスクに対して正しい対処法を取れたときだけです。

　育児もリスクの連続です。家で過ごすとき、幼稚園に送り届けるとき、近所の公園に行くとき、遠出をするとき......小さなリスクもあれば、子どもの命にかかわる大きなリスクもあります。また、子どもの年齢や人数によっても違います。子どもの身の安全と笑顔を守るため、わたしはいつでも考えられるリスクに備えて手を打っています。打っているつもりです。まあそれでも常に大人の想像の斜め上をいくのが幼児というものですが。

■本という名の種を蒔く

　このコラムで紹介した本は、絵本といってもページ数が多く、文字も小さめなので内容を理解できるようになるのは小学生以上からと思われます。わたしの子どもたちが読むにはまだ早いので、しばらくは本棚の片隅に置いておこうと思います。

　子どもたちがもう少し大きくなったときにこれらの絵本に興味を持ってくれたら嬉しいと思います。もし興味を持たなくても、それはそれで仕方ないことです。たとえ興味を持って読んだとしても、それだけで将来エンジニアになるとは限らないものです。

　わたしは、子どもに本を与えるということは、子どもの持つ花壇に種を蒔くことだと思っています。花壇の土の状態は子どもによって異なります。同じ種を蒔いても、花壇によっては芽が出ないこともあります。種のほうにも蒔くのに最適な時期というものがあるので、それが早すぎたり遅すぎたりするとうまくいかないこともあります。それに、すぐに芽が出て大きくなる種もあれば、ゆっくり時間をかけて成長する種もあるでしょう。芽が出た後で育つかどうかは花壇の管理人である子ども次第です。そのうち、子どもが自分で種を選ぶ日がやってきます。

　そうなったら、親ができることは「こういう種があるよ」と子どもに伝えること、親自身が自分の花壇に種を蒔いて育てる姿を見せることくらいでしょうか。親であるわたしも、どんなに忙しくても本を読むことをやめてはいけないなと思う次第です。

　本日（2018年9月10日）でエンジニアライフはちょうど10周年を迎えるそうです。ちょうど節目のこのときに、わたしのコラムニストとしてのこれまでを振り返るため、久々にコラムを執筆してみました。

■エンジニアライフは10周年、第3バイオリンは9.5周年

　わたしの最初のコラムがエンジニアライフに掲載されたのは2009年3月5日です。つまり、コラムニスト第3バイオリンが誕生してから9年と約6ヶ月になります。

　あまり意識したことはないですが、コラムニストとしてはかなり古参だったのですね。とはいえここ最近はコラムを執筆していないのであまり大きな顔はできませんが。

■エンジニアライフとともに歩んだこの10年を振り返る

　エンジニアライフは、発足当時から一読者としてチェックしていました。他のコラムニストさんのコラムを読んだりコメントを書き込んだりしているうちに、自分でもコラムを書きたくなりました。当時はソフトウェアテストに関するコラムが少なかったので、それならば自分で書こうと思ったのです。

　エンジニアライフでコラムを書くようになって、他のコラムニストさんと交流を持ったりソフトウェアテストの勉強会やシンポジウムに参加するようになったりして、わたしの世界は広がりました。そこでの出会いが縁になって、当時暮らしていた新潟でシンポジウムの実行委員長を務めたり、勉強会の立ち上げに携わったりと、普通の会社員をしているだけでは絶対にできないような経験をさせていただきました。また、同じコラムニストである夫とも出会うことができました。

　そういう意味では、エンジニアライフはわたしの「人生」そのものを形成したといっても過言ではありません。このような場を設けてくださったアイティメディアさんには感謝してもしきれません。

■「わたしの前に道はない、わたしの後に道はできる」ってこういうことなのかも

　エンジニアライフ10周年というこの機会に自分の過去のコラムを読み返してみましたが、まあ良くも悪くも「若かったな」という感想です。コラムを書き始めた頃は、「テストエンジニアという職業をもっと知ってもらいたい」という使命感みたいなものがありました。ソフトウェアテストを一生の仕事にするつもりでもいました。

　しかし今はエンジニアを辞め、主婦として家事と育児に追われる日々を送っています。当時のわたしが今のわたしを見たらがっかりするかもしれません。それでも、コラムを書いたその瞬間瞬間はいつも本気でした。その時々の気持ちに嘘はありません。だから、後悔はありません。

　テストエンジニアは辞めてしまいましたが、わたしが立ち上げに携わったシンポジウムや勉強会はわたしが離れた今でも続いています。また、「第3バイオリンさんのコラムを読んで勉強会に参加した」というお言葉をいただいたこともあるので、コラムを通してできることは充分やれたかなと思っています。

■これまでの10年を振り返ったついでにこれからの10年に思いを馳せてみる

　さて、これまでの10年を振り返ってみましたが、せっかくなので今から10年後の未来のことも想像してみましょう。

　わたしには娘が二人います。今はそれぞれ2歳と0歳ですが、10年後にはこの子たちは12歳と10歳になっているわけですね。アンパンマンとノンタンが好きな2歳児と、数日前に寝返りができるようになったばかりの0歳児が小学生かあ......なんだか遠い未来のように思えてきます。

　この子たちが小学校に入学するころには、小学校でプログラミングが必修になっているわけです。わたしが小学生のころには想像もつかなかったことです。今では小学生が自分のスマホを所有するのも珍しくないことですが、10年後には、スマホに変わる新しいデバイスが登場しているかもしれません。

　そんなことを考えていると、昔わたしがエンジニアとして働いていたころの先輩の言葉を思い出しました。「今の時代、少し前には夢だと思っていた技術がどんどん現実になっていくのを見るのが楽しい」なるほど、ということは、今のわたしは先輩の夢の延長線上に立っているのか、そのわたしが見る夢は、先輩の夢の続きなのかな、と。

　今から10年後、もしかしたら「スマホに変わる新しいデバイス」どころではなく、今のわたしには想像もつかないようなモノが登場しているかもしれません（スマホだって、ここ10年で急速に普及したわけですからありえない話でもないと思います）。どんな未来が待っているかはわかりませんが、娘たちにはわたしの夢を飛び越えて、どこまでも遠くに駆けていって、わたしが見られない世界を夢見てほしいものです。

　ところでわたしが大学生くらいのころ、母親が携帯電話を持ったのですが、メールの操作を覚えるのに苦労していました。子どもたちに何度も同じ質問をしながらメールを操作する母親を見て、わたしは「もう、お母さんったらしょうがないな」と思ったものですが、今度はわたしが娘たちから同じように言われるようになるかもしれません。あまり娘たちを呆れさせないように、エンジニアを辞めた今でも最新技術や世の中の動向はある程度キャッチアップしておかないとな、と思っています。

　わたしはNHKの朝ドラが大好きです。現在放送中の「ひよっこ」も、毎朝楽しみに見ています。毎日を懸命に生きるヒロインに、かつての自分自身や娘の未来の姿を重ねて笑ったり泣いたりと朝から忙しいものです。

　そんな折、次のような記事を読みました。

50年間、朝ドラを見てきた私が断言したい「『ひよっこ』はスゴい」

　この記事を読んで、仕事や働くことについてわたしが考えていたことをズバリと言い当てられたような気がしました。今回は、それを書きつづってみようと思います。

■「ひよっこ」とは

　「ひよっこ」は、有村架純さん演じるヒロイン「谷田部みね子」が、集団就職で東京に出てきて、仕事や人々との出会いを通して少しずつ成長していくお話です。

　みね子は、茨城の田舎出身の女の子。高校を卒業したら実家の農業を手伝うつもりでしたが、東京に出稼ぎに出ていた父親が行方不明になったことで運命が変わります。みね子は、父親を捜すため、家計を支えるために上京し、トランジスタラジオの工場に就職します。

　6月に入り、ドラマは新展開を迎えました。みね子が勤める工場は倒産し、寮で一緒に暮らした仲間たちもそれぞれ新しい仕事を見つけ、旅立っていきます。みね子は行きつけの洋食屋で働かせてもらえることになり、店の裏手にあるアパートに引っ越します。洋食屋がある赤坂の商店街の人たちにアパートの住人といった新キャラも次々登場し、物語が大きく動き出すこれからが楽しみです。

■普通の人の、普通の暮らし

　朝ドラのストーリーでよくあるのは「戦前から戦後にかけて、苦労しながらも事業を起こす女性の一代記」または「夢を持った女の子が一生懸命、がむしゃらに頑張って夢を叶えていくお話」です。

　しかし、「ひよっこ」の時代設定は1960年代半ば。みね子は戦争を直接知らない世代です。それに、みね子には特に夢があるわけではありません。東京に出てきたのもなりゆきでそうなっただけです。みね子の親友には「女優になりたい」という夢を持って上京した子もいますが、そのような人はこのドラマでは少数派です。ほとんどの登場人物は大きな夢を持っているわけではありません。ただ、中学や高校を卒業してから就職し、実家に仕送りしつつ、ときどき小さな幸せをかみしめながら日々を生きています。

　大きな夢や野心を持っているわけではない、普通の人が地に足をつけて普通に暮らしている。それだけといえばそれだけなのですが、そんな姿に静かに感動できるドラマです。

■夢ってどうしても必要？成長って常にし続けないといけないの？

　「ひよっこ」を見ながら、ふと、わたしは自分が就職したころのこと、仕事をしていたころのことを思い出しました。わたしが就職したころは、今ほど働くことに対して「意味」とか「成長」とか求められる時代ではありませんでした。それでも、就職に関する書籍には「自己分析をして自分に向き合おう」「自分がこれまでやってきたことから、本当にやりたいことを見つけよう」「自分の強みと弱みを知ろう」という言葉が躍っていました。当時のわたしはそれを見るたびに辟易していました。

　わたしの大学の成績は普通で、大学院でもなかなか研究論文がまとまらず、ようやく学会発表できたのは修了直前の3月になってからでした。勉強以外でも、例えばサークル活動で大会やコンクールなどに出場した経験もないし、人よりも秀でた一芸もありませんでした。

　そんなわたしが、やりたいことや自分の強みと言われても「別にそんなものない。でも、それがなければ働くことすらできないのか。勘弁してくれ」としか思いませんでした。内定が出るのも周りより遅かったので、なおさら追い詰められていたのかもしれません。エンジニアという仕事を選んだのも、興味があったからというのもありますが、情報系の学部で、先輩も友達もほとんどがその道を選んでいたから、というのもあります。

　ようやくエンジニアとして働きだしてからも、悩みは形を変えてやってきました。

　エンジニアとして自分には何ができるのか、どうありたいのか。メディアに登場するスーパーエンジニアに憧れつつも、自分はそこまでの器ではないということにも早々に気が付いて、やれエンジニアとしての市場価値だ、他のエンジニアにはない自分だけの売りは何だ、とかいう言葉に「正直しんどい」と思うことがしょっちゅうでした。

　仕事に夢とか働く意味とか絶対に必要なのか、成長ってずっとし続けないといけないのか、それができなかったら仕事人としてはダメなのか。エンジニアとして働いている間、これらの悩みは心のどこかにずっと引っ掛かっていたような気がします。

■夢とか成長とか、あればそれに越したことはないけれど

　エンジニアを引退したいま、わたしは相変わらず夢らしい夢もなく（今の望みは、娘の成長を見届けたい、くらいかな）、成長らしい成長もせず（せいぜい身体が横方向に成長したくらい）、日々を生きています。それでも、なんとか生きていけるというのはありがたい限りです。

　エンジニアという職業は（他の職業でもそうですが）新しい技術を学ばないと仕事にならないので「成長できないならしなくてもいい」とはさすがに言えません。

　ただ、夢を持てない自分、成長していない（成長している実感がない）自分は他の人より劣っていると悩んでいる人がいれば、そこまで自分を卑下することはないと言いたいです。大きな夢を持てなくても、成長できてないと思ってもいいのです。大きな夢はなくてもいいし、成長していないと思っていてもちゃんと成長しています。ただ、自分の思った方向やスピードと違うから気づいていないだけです。

　もちろん、大きな夢がある人、自分がガンガン成長できる環境に身を置いている人はそのままでいいと思います。また、「夢を持ちたい」「今よりもっと成長したい」と思っている人に「そんなのしんどいからやめとけ」とは言いません。

　でも、「夢」とか「成長」とかいう言葉がしんどい、今はそんなの聞きたくないし考えたくないと思うことがあったら、どうかその気持ちを否定しないでください。しんどいと思ってしまう自分を否定しないでください。

　「ひよっこ」を見ていると、大きな夢を持たなくても生きていくことはできるし、成長しなければと焦らなくてもちゃんと成長しているんだよな、と、なんだか安心する次第です。

　わたしが実行委員をつとめるソフトウェアテストシンポジウム「JaSST'17 Niigata」が今年も開催されます。

■日時と場所

　日時：2017年4月28日　13:00開始（12:30受付開始）

　場所：朱鷺メッセ　中会議室201B

　開催概要、プログラムなど詳細はJaSSTのサイトをご覧ください。

■今年のテーマとプログラム

　今年のテーマは「ユーザビリティ / UX」です。ソフトウェアが日常生活に溶け込むようになり、誰もがソフトウェアに触れることができる現在において、人とソフトウェアの接点となるUI（ユーザインターフェース）の品質が重要となっています。

　「JaSST'17 Niigata」では、ユーザビリティ、UX（ユーザエクスペリエンス）とは何か、それらをテストするにはどのようなアプローチが必要かを考えることができるプログラムをご用意いたしました。

　基調講演は、利用品質ラボ代表の樽本徹也氏による「ユーザエクスペリエンスの要素とプロセス――UX / UCD概論」です。基調講演でユーザビリティの概要に触れたあとは日立ソリューションズの柳生大介氏による事例発表で具体的な取り組みをご紹介していただきます。

■参加申し込みについて

　本日（3月3日）より、参加申し込みの受付を開始しました。参加をご希望の方はこちらから申し込み手続きをお願いします。

　残念ながらわたしは当日参加することができませんが、参加者にご満足いただけるシンポジウムにするべく実行委員一丸となって準備に取り組んでいます。みなさまのご参加をお待ちしております。

　エンジニアライフのコラムニスト、リーベルGさんの小説「罪と罰」がタイトルを改め、書き下ろしの特別編を加えて書籍になりました。わたしはこの小説をエンジニアライフ連載時には毎週読んでいろいろ考えていましたが、今回ひと足先にドラフト版を読ませていただいて、あらためて考えてみたことを書いてみたいと思います。

■命の価値は誰が決める？

　エンジニアライフの連載を読んでいた読者にはあらすじを説明する必要はないかもしれませんが、物語は主人公の箕輪レイコが所属するWebシステム開発部に、ソフトウェア・エンジニア労働環境向上推進委員会（通称：イニシアティブ）の代表を名乗る五十嵐というコンサルタントがやって来るところから始まります。

　物語の中盤で、五十嵐は趣味で飼育しているレッドビーシュリンプというエビにたとえて、「エンジニアの地位を向上させ、純粋に技術力で評価されるようにするために、優秀なエンジニアをすくい上げ、向上心のない者は排除する」という持論を語ります。聞く人によっては過激な主張ととれなくもないですが、彼がこのような考えに至ったのには理由があります。書き下ろしの特別編では、五十嵐の過去――ある若手エンジニアを不幸にしてしまった苦い経験――が描かれています。

　この小説の元題は「罪と罰」言わずとしれたドストエフスキーの名作です。こちらのあらすじを簡単に説明すると、主人公ラスコーリニコフが「非凡人は新しい世界を作るためなら法を踏み越え、障害となる凡人を亡き者にする権利を持つ」という考えのもと、強欲な金貸しの老婆の殺害を計画、実行します。ところが、たまたまその場に居合わせた老婆の義理の妹で善良な女性リザヴェータをも殺してしまったことで苦悩と葛藤に見舞われる、というストーリーです。

　「目的は手段を正当化するか」「何千もの命を救えるなら、ひとつの命を犠牲にすることは許されるのか」19世紀にドストエフスキーが提示した問いが現代日本のIT業界で再度問われることになります。レイコは五十嵐の考えに賛同しつつも、ベテラン社員たちが追い詰められていく姿を目の当たりにして葛藤します。物語のラスト、クリスマス一色に染まる街でレイコは「ある光景」を見かけ、思わず涙します（ラストシーンはエンジニアライフ掲載時とほんの少し、変わっています）。この涙の意味は何なのか。ラスコーリニコフが自首する前に娼婦ソーニャから十字架を受け取ったように、レイコもまた十字架を背負うことになったのかもしれません。

■歩み去った者より

　普段から、「技術力ではたいしたことないのに年齢が上というだけで高い給料をもらって偉そうにしている上司がウザい」「休日も勉強会に行ったりして最新技術を学んでいる自分と、言われた仕事をやってるだけの同僚が同じ待遇だなんて納得いかない」そんな不満を抱えている人は躍進する若手エンジニアと対照的に徐々に追い詰められていくベテラン社員たちを見て「ざまあみろ！」と思うかもしれません。

　しかし、自らのエンジニアとしての能力に限界を感じて悩み続け、ついに退職したわたしにとっては、そんなベテラン社員がどこか他人事とは思えないという感覚もありました。もちろん、わたしも退職までに何もしなかったわけではありません。少しでも最新技術についていこうと土日に技術書を読み、勉強会に参加していました。しかしそれでも、学んだことを仕事にうまく落とし込むことができず、自分より優秀なエンジニアと比べて落ち込み、苛立ちを抱えるようになっていきました。結果だけ見れば、わたしは物語の中で逃げるように会社を去った久保やイニシアティブの改革についていけず居場所を失ったエヌ氏とそれほど変わらないのかもしれません。

　わたしはエンジニアを辞めたところで何をするかまるっきり当てがなく、どうすればいいかかなり迷いましたが夫の理解もあり退職という選択肢を取りました。しかし、もしシングルマザーの進藤カスミのように、自分が稼がないと家族が路頭に迷うという境遇だったら一体どのような人生が待ち受けていたのか、と今でも思うことはあります。

■答えのない問い

　わたしはエンジニアとしての道を究めることはできませんでしたが、技術力と向上心のあるエンジニアが正当な評価と報酬を得られるようになり、自分の仕事を誇りに思える世の中になってほしいと思います。しかし、「技術者が技術力で評価される」ことと「もし最新技術についていけなくなったらIT業界から去る（生活の保障はない）」ということはイコールなのでしょうか。

　純粋に技術や能力だけで評価される職業としてわたしがまっさきに思い浮かべるのはプロ野球選手です。よい成績を残し、チームの勝利に貢献できれば年俸は上がりますし、それができなければ年俸ダウン、あるいは戦力外通告となります。また、試合のある日だけでなくシーズンオフのときでも練習をするのは当たり前です。プロ野球選手なら誰でも毎日練習して、一日でも長く現役で活躍したいと考えていると思いますが、それでもイチローや山本昌のようになれる人はそういません。

　プロ野球選手とエンジニアは報酬も社会的な役割もまったく違うので、エンジニアもプロ野球選手と同じようになればいいとは思えません。ではどうなるのがいいのか、わたしはまだ答えを見つけていません。おそらく正解のない問いなのかもしれませんが、たとえそうであっても考える、考え続けるということが重要なのかもしれません。

　先日、「不機嫌な姫とブルックナー団」（高原英理著、講談社）という小説を読みました。わたしはブルックナーの交響曲が大好きです。ブルックナーはクラシック音楽に詳しくない人にとってはなじみのない作曲家ですが、たまたまこの本の存在を知り「ブルックナーがフィーチャーされるなんて珍しい」と思い手に取ってみました。今回は、この小説の感想を書いてみたいと思います。

■ブルックナー好きな女子＝オタサーの姫！？

　この小説の主人公は代々木ゆたき。独身のアラサー女子で図書館の非正規職員をしています。ブルックナーのコンサートに出かけた彼女が、たまたま隣に座った武田一真（タケ）という男性から声をかけられるところから物語は始まります。タケは、同じコンサートに来ていた仲間の玉川雪之進（ユキ）、一本橋完治（ポン）をゆたきに紹介し、「俺たち、ブルックナー団なんです」と語ります。

　それぞれ強烈な個性の持ち主であるブルックナーオタク（ブルオタ）3人組のペースに巻き込まれ、勝手に姫扱いされて憤慨するゆたきでしたが、タケがブルックナー団のサイトに掲載している「ブルックナー伝（未完）」という小説を読み進めていくうちに心境に変化が訪れます。そしてタケの意外な夢を知り、一度はあきらめた自分の夢を思い出す......というストーリです。

　わたしもブルックナーが好きですが、市民オーケストラをやっていてもブルックナーが好きな人に出会う機会は少ないです。特に女性でブルックナーが好きという人にはお目にかかったことがありません。以前所属していたオーケストラでブルックナーが好きだと言うと「女子でブルックナー好きなんて珍しいね」と言われたことがあります。オーケストラをやっている人ですらそうなのですから、ひとりでブルックナーのコンサートに来ていたゆたきがタケたちにひどく珍しがられたのもうなずけます。

■タイトルにも出てくるブルックナーってどんな人？

　ヨーゼフ・アントン・ブルックナーは、19世紀のオーストリアの作曲家です。敬虔なカトリック教徒でオルガンの名手、11曲の交響曲のほか、多くの宗教曲などを残しました。彼の大規模な編成による長大な交響曲は決して万人受けするわけではありませんが、そこがいいというコアなファンが大勢いることもまた事実です。わたし個人の意見ですが、ブルックナーの交響曲は「交響曲」というジャンルの最終形態だと考えています。

　ここまで言うとなんだかすごい人に思えるかもしれませんが、その生涯は決して順風満帆とはいえないものでした。ブルックナーの交響曲はあまりにも当時の常識から外れた作品だったため、オーケストラからは演奏を拒否され、批評家からは手厳しい批判をくらうことはしょっちゅうでした。作曲家としてようやく認められるようになったのは60歳近くになってのことです。他人の意見、こと権威ある人の意見に弱いブルックナーは批判を受けるたびに何度も作品を改訂するはめになりました。また、私生活では若い女性にいくども求婚しましたがすべて断られ、生涯独身を通しました。40歳を過ぎて10代の少女に結婚を迫り、拒絶されたことも一度や二度ではありません。

　タケが「ブルックナー伝（未完）」の中で描くブルックナーも、なんとも情けなくカッコ悪い人物です。自分が求婚して断られた女性のことを書き記したノートを「嫁帖」と名付け、ことあるごとに読み返して悦に入る姿はさながら二次元キャラを「俺の嫁」と呼ぶオタクのようですし、尊敬する大作曲家ヴァーグナーに出会ったときのエピソードは勉強会やセミナーで有名人と名刺交換しただけで舞い上がってしまう人のようです（その後、交響曲第3番の献呈を受けてもらえることになるので舞い上がっておしまいではないですが）。

　今風に言えば「非モテ」「非リア充」「ロリコン」「処女厨」「こじらせ男子」「マジメ系クズ」といった残念なワードがぴったりの人物といったところでしょうか。

■リア充たちにはわからない

　ゆたきが出会うブルオタ3人組は、自分たちのような人間はおしゃれとか優雅とかいう言葉とは無縁、そういう世界から締め出された人間には野暮で鈍重、クラシックの正統派とはいえないブルックナーがお似合いだと口々に語ります。容姿や金に恵まれ、人生がうまくいっている人間にはそうでない人間の気持ちなどわからないと憤り、でもブルックナーを聴いているときだけは「どうせ俺なんて」という気持ちから解放される、自分たちにとってブルックナーは隠れ家だ、とも。確かにこの3人、まるで自分自身を投影するかのようにブルックナーの不遇ぶりを小説に書くタケ、語尾に「ぽ」をつけて話し、初対面のゆたきに「ゆたきたん」と呼びかけるわかりやすいオタクキャラのユキ、過去にいじめられていたらしいポン、みんな劣等感を抱え、自分をイケてないと思っている人たちです。

　ゆたきにしてみても、32歳で独身、彼氏もいないし、仕事も好きで選んだ職業ではありません。それでも小さなやりがいを見出して働いていましたが、職場の事情でそれすらも失ってしまいます。ブルックナー団の面々には「あんたたちみたいなオタクと一緒にしないで！」と言ってはみるものの、どこか彼らに対して共感を覚えてしまう一面も見せます。

　なにをもってイケてる、イケてないを分けるのかは難しいところではありますが、わたし自身、エンジニア時代は仕事や勉強会で凄腕エンジニアを目の当たりにし、彼らに対する憧れとどこまでいってもかなわないという諦観を抱え、ついにはそこから退場するという選択を取りました。今は専業主婦として育児中ですが、仕事も育児もがんばりつつ女性らしさも忘れないワーキングママがテレビで紹介されているのを見ると「この人とわたしと、どこがどう違ってこうなってしまったのか」とこぼしたくなるときもあります。だからゆたきやブルックナー団のメンバーが抱えるどこか鬱屈した気持ちはわかるような気がします。

■イケてない人生に寄り添うもの

　よく「エンジニアは非モテ」「エンジニアはコミュ障」なんて言われることがあります。それに当てはまる人もそうでない人も、仕事で無理難題を押し付けられたり、人間関係に疲れたりして「自分はなんてイケてないんだろう」と落ち込むことがあるかもしれません。「生きていればそのうちいいことあるよ」「がんばっていれば誰かが見ていてくれるよ」なんて言葉もむなしいだけという日もあるでしょう。

　そんなときにそっと寄り添ってくれるのが、イケてない人生を送ったブルックナーと、彼が残した交響曲なのかもしれません。それは決して「こいつよりはマシ」と見下して笑うためではなく、イケてない人がそれでもひたむきに生きる姿に心を動かされるからです。

　自分の夢を思い出したゆたきも、「駄目な人には同じ駄目な人の必死さが胸にくるのだ」と思います。そして、どんなに下手でもいいから、もっと上手い人が出てくるまでのつなぎ役でもいいから今からでもやれ！ と自分自身を鼓舞します。

　無理にイケてる人になろうとするのではなく、どんなにカッコ悪くても腐らずに自分のやりたいことを追い求めて、ときどき自分だけの隠れ家に身を寄せる、そんな人生があってもいいのではないでしょうか。ブルックナーだって、確かにイケてない人生だったかもしれませんが、それでも生きている限り何度も曲を作り、書き直していたのですから。

　エンジニアライフのコラムニストであるキャリアコンサルタント高橋さんの書籍「マンガでやさしくわかるプログラミングの基本」。わたしはすでにエンジニアを引退しているし、読んでもいいんだろうか......と思っていました。しかし、夫がこの本を読んでいるのを見たり、他のコラムニストさんの書評を読んだりしているうちに、わたしも読んでみたくなりました。

　そこで、夫が読んでいた本を借りて読みました。最後まで読んでみて「もっと早く、学生時代か新人のころに読みたかった！」と思えるほど面白い本だったので、ちょっと出遅れてしまいましたが、わたしもこの本の書評を書いてみたいと思います。

■「この章、あとどれだけ読めばいい？」がわかると進みやすい

　この本は各章の前半部分がマンガ、後半部分が文章による解説、というスタイルを取っています。マンガの内容は、プログラミング未経験の主人公、野々原マイミが社運をかけたプロジェクトにプログラミング担当としてアサインされたことをきっかけに、謎の生き物エニアの助けを借りながらプログラミングを学び、成長していくというストーリーになっています。

　章の内容を先にマンガでさっと読むことで、各章のボリューム、重要なトピックスがだいたいわかります。文章のみの本を読んでいると「この章、あとどれだけ読めば終わるんだろう。そろそろ読むのがしんどくなってきたけど、章の途中で止めるのも中途半端だし......」と悩むことがあるかと思います。しかし、この本はマンガパートで章の内容を予習して文章パートを読むことができるので、「この章はあと○○の解説だけか、だったらもう少しがんばって読もう」と思って読み進めることができました。

　わたしはこの本を家事の合間や、生後8ヶ月の娘を寝かしつけたあとに読んでいました。自分のために取れる時間は決して多くはありませんが（それでもエンジニア時代よりは落ち着きましたが）、忙しくても読みやすい本だと思いました。

■学校課題のプログラミング≠開発現場のプログラミング

　この本は、単なるプログラミングのマニュアルではなく「ソフトウェア開発の現場でプログラミングをするということ」を学ぶことができます。わたしが「もっと早く、学生時代か新人のころに読みたかった！」と思ったのはここです。

　わたしがはじめてプログラミングを経験したのは、大学の実習でした。毎回、講義のあとに課題が出て、時間内に課題のプログラムを作成して担当教官に動作を確認してもらったり、終わらなかったときは後日ソースコードを提出したりしていました。そのころのわたしは、とにかく動くこと、担当教官にマルをもらうことを最優先に考えていました。だから課題を提出してマルをもらえばそれでおしまい、そのとき作ったプログラムは二度と実行されることはありませんでした。

　しかし、就職していざ現場でプログラミングを始めるとそうはいきません。まずは設計書を書いて、設計書のレビューをしてOKが出るまで設計書を書き直し、その後でやっと実装に移ったら今度はコードレビュー......大学の課題でしかプログラミングを経験したことがなかった新人時代のわたしは、この流れに戸惑った覚えがあります。さらに、無事に実装、テストが終わってリリースしたあとは、プログラムのメンテナンスをしたり、新しい機能を追加したりする仕事が待っていました。「マンガでやさしくわかるプログラミングの基本」には、プログラムは作って動けばそれでいいのではないこと、設計の大切さ、デバッグやメンテナンスについても解説されています。

　また、各章の終わりには著者の高橋さんの経験談がコラムとして掲載されています。プログラミングの楽しさ、工夫していること、苦労や失敗談といった生の声を聞く機会というのはあるようで意外とないものです。学生時代は「課題かったるいよねー（笑）」と言う友人には聞けないし、担当教官に聞くのもなんだか違う感じがするし、社会人になって上司や先輩に「プログラミングの楽しさって何ですか？」と面と向かって聞くことは照れもあったりしてなかなか難しいものです。だから、コラムで語られる高橋さんの経験談もわたしにとっては「もっと早く、学生時代か新人のころに読みたかった！」と思うポイントでした。

■もうひとつの人生

　この本を読んでわたしの印象に残った言葉、それは第3章の解説パートにあった「楽しみながらプログラミングを体験しましょう」という言葉です。

　この言葉を読んで、ふと「そういえば、わたしはプログラミングを楽しんだことがあっただろうか」と考えてみました。思えば、学生時代の課題でも、社会人になってからも、担当教官にマルをもらうこと、早くレビューを通して早くリリースすることばかり考えていて楽しいと思ったことはあまりなかったかもしれません。

　わたしは新卒でプログラマとなり、その後挫折を経験してテストエンジニアに転向し、そこでも限界を感じて引退してしまいました。今ではただの主婦です。この人生に後悔はありませんが、それでも「マンガでやさしくわかるプログラミングの基本」を読んで、学生時代か新人にこの本に出会っていれば、この本を読んでもっとプログラミングを楽しむ余裕を持つことができたならもう少し違う人生があったのではないか、そんなことを考えてみました。

　久々のコラムが宣伝になってしまいますが、ソフトウェアテストシンポジウム「JaSST’16 Niigata」を新潟で開催いたします。これまでわたしが実行委員長をつとめてきましたが、今年度で実行委員長をしりぞき、実行委員として準備に携わることになりました。

■開催概要

日時：2016年4月15日（金）

場所：朱鷺メッセ　中会議室302B

　今年度のテーマは「継続的インテグレーション」です。ソフトウェア開発においてビルドやテストを短いサイクルで繰り返し実施することによって早期に品質を確保する手法が「継続的インテグレーション」です。継続的インテグレーションを取り込みたいけど現場にどう適用していいのかわからない、継続的インテグレーションを実現するためのツールをうまく使いこなせない、そんなお悩みを抱えた方のお役に立てるプログラムをご用意しました。

　基調講演は、アトラシアン株式会社のエバンジェリストである長沢 智治氏をお招きします。また、Jenkinsを利用した継続的インテグレーションのチュートリアルを開催します。さらに、事例発表もご用意しました。

　本日3月1日より、参加申し込み受付を開始しました。プログラムの詳細情報および参加申し込みはJaSSTのサイトをご覧ください。

■開催レポートを書きたいのですが

　初開催の「JaSST’11 Niigata」から毎年開催レポートを執筆してきましたが、今回は諸事情があって当日参加できなくなってしまいました。なので、エンジニアライフで開催レポートを執筆することはできません。ご了承ください。

　わたしは当日参加できませんが、実行委員のメンバー一丸となって準備にあたってきました。実行委員一同、皆様のご参加をお待ちしております。

　わたし、第3バイオリンはエンジニアを引退するべく退職しました。タイトルだけ見ると「戦力外通告？ もしかして会社クビになったのか？」と思われるかもしれませんが、そうではないです。自分で自分に戦力外通告をしました。「代打、俺！」ならぬ「戦力外通告、俺！」です。

■なお35歳には間に合わんもよう

　退職を考えた最大の理由、それは今話題の「妊活」です。

　あまりこういうところでお話することではないかもしれませんが、わたしと夫は不妊治療に取り組んでいます。不妊治療ではストレスや疲労をためすぎないようにすることが重要です。しかし、エンジニアとして働いていると、どうして残業や休日出勤は避けられません。しかもわたしの場合、客先常駐の仕事が多かったので勤務時間をお客様の都合に合わせることが多く、ストレスと疲労はたまる一方でした。

　わたしは現在34歳、一般的に高齢出産といわれる35歳はもう目の前です。あまり悠長にしているとタイミングを逃してしまうかもしれません。だったら今、自分の心身をいたわりつつ不妊治療に専念しようと思い、決断しました。

■辛いです、テストが好きだから

　今だから言いますが、実はここ1～2年ほど前から退職について考えていました。そのころから、自分のテストエンジニアとしての能力の限界を感じていました。勉強したり社外活動に取り組んだりして得たことを実務にうまくフィードバックできないと悩み、自分より若く優秀な人をたくさん見て「自分はこの境地にたどり着くことはできない」ということにもうすうす感づいていました。SNSなどで技術の話題が議論されていても、いつの間にか同じテンションで話に加わることができなくなってしまいました。

　「だったら、優秀な人の2倍も3倍も猛勉強して少しでも近づけるようにすればいいじゃないか。自分の限界を自分で決めてしまったらそこでおしまいだ。だいたい、エンジニアなら勉強するのは当たり前、優秀な人だってものすごく勉強したから今があるんだ。それをやる前から『無理』とか言うのは甘え。気合いが足りない。その程度の気持ちでエンジニアになったのか」という意見もあるかと思います。

　ええ、わたし自身、ずっと悩みました。他のエンジニアの方々は勉強して、学んだことを現場で実践してどんどん先に進んでいます。同じように頑張ることがどうしてわたしにはできないのか。かといって自分に他に何ができるでもないし、生活するためには働かないといけない。いつも自分を責めて、苛立ちを抱えて、夫と口論になることもしょっちゅうでした。

　毎日のように苛立ち、落ち込み、残業で疲れたうえに家事もろくにできない、夫とも口論になる、こんな状態になってまでエンジニアを続けたいのか、ずっと考えていました。ちょうど同じ時期に不妊治療に本腰を入れることになり、また将来的に夫の地元に帰るかもしれないという話もあったりして、これが区切りになるかと思って夫とも相談のうえ、退職を決意しました。

■僕自身IT業界を出る喜びはあった

　退職前の有給消化期間も含めて、エンジニアの職から離れて1ヶ月ほどが経ちました。今ではすっかり落ち着いています。退職したことに後悔はありません。テストエンジニアとしてはたいした実績は残せませんでしたが、それでもできる限りのことはやったと思っています。

　とはいえ、いつまでも夫に経済的に頼ってばかりもいられないので、何か別の仕事を探そうと思っています。確かにテストエンジニアとしては終わってしまったのかもしれませんが、人生はまだまだ続くのです。

■わがエンジニアライフは永久に不滅です！

　エンジニアをやめるにあたって、このコラムはどうしようかとも考えましたが、ひとまずこのまま置いておきます。エンジニアをやっている方、エンジニアを目指す方が読んで面白いと思えそうなネタがあれば書くようにしようかと考えています。そのときは、「元エンジニアが何か言っとるわい」程度にとらえてくだされば幸いです。

　まあ、少なくともコラムのタイトルは変えようと思います。「感謝されるテストエンジニアになる」とか言っておきながら、誰からもたいして感謝されることなく退職するなんて情けない話かもしれませんが、それが現実なのですから仕方ないです。

　最後に、テストエンジニアとして働きながらこのコラムを書くことができて良かったと思います。普通に働いているだけではできない経験もできたし、出会うこともなかったであろう人とも出会うことができました。これまでわたしのコラムを読んでくださった読者の皆様にも感謝しています。これからは書く頻度は下がってしまうと思いますが、ときどき読んでくださると嬉しいです。

　ソフトウェアテストシンポジウム「JaSST’15 Niigata」開催レポートもいよいよ最終回です。今回は、QAタイムと情報交換会の様子をお届けします。

■QAタイム「教えて！ 秋山さん」

　今回は、ワークショップのあとでQAタイムを設けました。基調講演、ワークショップでもそれぞれ最後の数分間で質疑応答の時間を準備しましたが、そういう場面で意外と手が挙がらない、という光景を見かける方は多いと思います。こういう場合、決して質問がないわけではなく、なんとなく大勢の前で手を挙げづらい、気になることはあるもののどのように質問していいかわからない、という場合があります。また、そのときは気づかなくても後になって疑問が湧いてくる、ということもありえます。

　そのため、プログラムの最後に振り返りも兼ねてQAタイムを設けることにしました。もちろん、基調講演やワークショップに関する疑問のほかにも秋山さんに聞いてみたいこと、相談したいことがある方はどんどん質問してください、と声をかけたところ、多くの質問が寄せられました。それらを回答とあわせてご紹介します。

Q. 「禁則（仕様の上で、同時に選択できない部分。たとえばWordのフォントの文字飾りの「上付き」「下付き」など）の扱い方がわからない」
A. 「禁則は基本的に有則（仕様書に記載されている組合わせ）。禁則関係にある因子をまとめて一つの因子として他の因子に対して無則（仕様書にない組合わせ）の関係としてもよい。たとえば『上付き・下付き』を一つの因子として『ON・OFF』、『OFF・ON』、『OFF・OFF』の3つの水準とすれば禁則はなくなる」

Q. 「因子や水準の定義をどうやって決めたらいいのか。たとえば、仕様書に『ここが変わるとどうなる』など明確な記載がないときはどうやって判断すればいいのか」
A. 「仕様書に記載がないものは無則として扱う。だから仕様書を作る段階から有則、無則を明らかにして作りこまなくてはならない」

Q. 「最大値のテストについて。たとえば、『プリンタで100部の資料を印刷する』といったテストを実際にやるとなると時間と用紙をかなり消費する。最大値をなるべく減らしたい」
A. 「そもそも、最大値のテストが必要なのか。まずはそこから考える。たとえば、印刷のテストであれば印刷データのバッファの大きさの境目が怪しい。その境目でバグが出やすい組合わせテストには、異常値を含まないテストを実施する」

Q. 「エラー系の組合わせについて詳しく知りたい」
A. 「まずはエラー系の組合わせのみの表を作る。このとき正常系とは組合わせない。そして、エラーを回避するためのテストを実施する。例を挙げると、ロケットや人工衛星は宇宙線の影響でビット反転を起こすことがある。精密機器なので計算ミスはできないが、それでも限度がある。だから、2ヶ所同時にビット反転が起こったときは何とかするが3ヶ所以上同時に、となったときはもうどうにもならない、などの事情をステークホルダーに説明し、納得してもらう」

Q. 「アジャイル開発での妥当性確認はどのようにすればいいのか」
A. 「そもそも、要求がわかっている人でないと確認できない。もし開発者、テスト担当者が要求を理解していないということであれば、顧客をうまく巻き込むこと。もしそこがうまくいかない場合は、サイクルの長さが不適切である可能性がある」

　20分という短い時間でしたが、各セッションにちなんだ質問、現場のお悩みによる質問、さまざまな内容の質問が集まりました。プログラムの最後にあらためて参加者の皆様のご質問に回答できる時間を設けてよかったと思います。

■情報交換会

　本会の閉幕後は情報交換会です。場所を移して、お茶とお菓子をつまみながら遠く関西や東北からいらっしゃった方、他地域のJaSST実行委員の方ともたくさんお話できました。わたしにとって、普段なかなかお会いできない方々とお話できるのが情報交換会の楽しみのひとつです。

　3回にわたってお送りした「JaSST’15 Niigata」開催レポートは以上でおしまいです。参加者の皆様、実行委員会の皆様、そして講演とワークショップをお引き受けくださった秋山さんに感謝いたします。また、最後までこの開催レポートを読んでくださった読者の皆様にもお礼申し上げます。

　前回からだいぶ間があいてしまいましたが、ソフトウェアテストシンポジウム「JaSST’15 Niigata」開催レポート第2弾です。今回は、ワークショップの様子をお届けします。

■ワークショップ「検出したいバグから考える組合わせテスト技法」

　午前中の基調講演でソフトウェアテストの作り方のお話を聞いたあとは、いよいよワークショップで実践です。

　最初に秋山さんから「バグには『実装のバグ』と『仕様と設計のバグ』があります。If文の分岐ミスやメモリリークといった『実装のバグ』はユニットテストなどでプログラマ本人が見つけるものです。仕様の矛盾や理解不足、設計ミスなどに起因する『仕様と設計のバグ』こちらを見つけることがテストエンジニアの役割であり、本ワークショップが対象とするものです」と説明がありました。

　さて、この「仕様と設計のバグ」ですが、単独の機能よりも2つ、ないしは3つの機能の組合わせ部分で発生することが多いです。単機能のバグは割と見つけやすいものですが、これが2つ以上の機能の組合わせとなると話は違います。わかりやすく関係性がある因子であればまだ注意しやすいものの、直交関係にある（互いに影響を及ぼさない）因子であれば気が付きにくいものです。そもそも、本当に直交関係にあるのかどうかがわからないこともあります。組合わせテストでは、このような直交関係にある、あるいはそのように見える因子の組合わせを狙ってテストできるという利点があります。特に、仕様として想定していなかった組合わせや、多様な動作環境、エラー系の組合わせをテストするのに有効です。

　組合わせテストの第一歩、それはテスト対象の因子と水準を洗い出すことです。因子とは「結果に影響をおよぼず要因」、水準は「因子の取りうる値」です。文章だけで説明するのも面倒なので、皆さんお手持ちのWordを開いて右クリック→「フォント」を選択してください。「スタイル」や「サイズ」など、設定項目がいろいろありますね。各設定項目には「標準/斜体/太字/太字 斜体」といった選択肢があるもの、チェックボックスをON/OFFするもの、いろいろあります。この「スタイル」「サイズ」などの設定項目が因子、各因子で選択できる個々の設定値が水準です。何を因子とするかはテストの内容にもよりますが、まずはGUIから見つけることができるようになるのが大切です。

　組合わせテストは、各因子の水準を組合わせて作ります。水準には正常値と異常値がありますが、基本的には正常値のみを組合わせます。異常値は何と組合わせてもエラーとなるので異常値を含めると組合わせの意味がなくなってしまいます。だから、異常値は異常値だけで別にテストする必要があります。

　さて、水準を組合わせるといっても、ただやみくもに組合わせればいいというものではありません。単純に「因子と水準、全部を組合わせればいいじゃん」と考える人もいるかもしれませんが、因子と水準の数が増えれば、組合わせの数は爆発的に増えてしまいます。限られた時間でテストすることを考えると、すべての組合わせをテストするのはあまりに非現実的です。とはいえ、いくつかの組合わせをピックアップするとしても明確な根拠が必要です。「テストエンジニアの勘でなんとなく」などと言って納得する人はいません。

　すべての組合わせの中から偏りなく、効率的にテストできる組合わせをピックアップするためには方法があります。そのうちのひとつが「HAYST法」です。HAYST法は、秋山さんの所属する富士ゼロックスで確立されたソフトウェアテスト組合わせの手法です。一言でいうと、直交表をベースに組合わせの網羅率を高く保ちつつ、組合わせの数を抑えるためのテスト技法です。

　HAYST法のおおまかな内容は以下の順序です。

1. 因子を見つける
2. 因子を有則（仕様に記載されている規則）、無則（仕様に記載されていない規則）に分類する
3. 無則の因子について水準を洗い出す
4. 直交表に因子と水準を割り付ける

（HAYST法について詳細を知りたい方は、HAYST法の書籍「ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方」や「事例とツールで学ぶHAYST法―ソフトウェアテストの考え方と上達のポイント」などをご参照ください）

　HAYST法について説明したところで、いよいよ演習がスタートしました。手紙の料金計算システムのGUIを見ながら、HAYST法でテスト項目を作成する演習です。

　ワークショップの間、わたしを含めた実行委員のメンバーが参加者のフォローのためにテーブルを回っていましたが、因子と水準を作成したところで手が止まっていた方が多かったです。アンケートにも「難しかった」「時間が全然足りなかった」というご意見がありました。半日のワークショップで参加者の皆さんにご満足していただくために何ができるか、これは運営の課題として考えていきたいと思います。

　「JaSST'15 Niigata」レポート第2弾はここまでです。次回は最終回、QAタイムと情報交換会の様子をお伝えします。

　今年もソフトウェアテストシンポジウム「JaSST’15 Niigata」を開催しました。5年目となる今年は基調講演からワークショップ、QAタイムまですべてのセッションを富士ゼロックスの秋山浩一さんにお願いするという異例のプログラムでお届けしました。

■日時と場所

日時：2015年4月24日

場所：朱鷺メッセ　中会議室302B

■基調講演「ソフトウェアテストの作り方」

　講演のはじめに、秋山さんは「今日は数字の『2』にこだわりたいと思います。あまり多くのことを一度に言っても、たいていの人は一度にあれもこれもとできません。だから、重要な2つのことに絞ります。2つにすれば方向性がわかりやすくなるからです」と語りました。

　秋山さんは「品質とテストの改善はひとりではできません。そのため、人を動かす力が必要です」と語りました。確かに、組織のなかで品質とテストを改善しようと思ったら、仕事の進め方を変えたり、プロジェクトに関わる人のマインドを変えたりする必要があります。個人でできることには限度があります。では、周りの人を巻き込んで改善活動を進めるにはどうすればいいのでしょうか。

　秋山さんは続けます。「まず思いつくのは『○○さんが言っていた』と影響力のある人物を出すことです。上司や社長でもいいし、業界で活躍する有名人でもいいです。一種の思考停止ワードではありますが、自分自身がさっさと判断して行動するには効果ありです。ところが、同じ言葉で他人を動かそうとしても、うまくいかないことがあります。有名人の名前を出しても、相手がその人を知らないこともありますし、社内の人物であっても『その人が言ったから何なの？』と反論されたらそれまでです。結局、人を動かすのはあなた自身の思いの強さです。なぜ高品質が必要なのか、なぜテストを改善するのか、それをしないとどうなるのか、自分の心に引っ掛かるものを核として理論武装し、『思い』を作って説得するのです」

　さて、もし十分にテストをせずに市場に出た製品に致命的なバグがあったとき、どのような問題が発生するでしょうか。製品やシステムの欠陥で業務に支障をきたしたり、大事故が発生したりしたというニュースを聞くことがあると思います。もしそうなったら、企業は損害賠償やリコールで多額のお金を失うことになります。そして、企業の社会的信用も失墜してしまいます。

　そのような炎上状態におちいってしまったとき、火消しチームや対策本部が発足し、改善活動が始まります。そうしてある程度の効果を上げられたところまではいいです。ところが、改善活動をいつまで続ければいいのかわからない、あるいはだんだん活動に飽きてマンネリ化しまう、という状態におちいることがあります。そうしているうちに活動がどんどん縮小し、予算も減らされてしまう。そして再び炎上してしまうというケースがあります。このような状況を防ぐにはどうすればいいのでしょうか。

　秋山さんは、改善活動を続けるコツは『活動状況の見える化』と『炎上の気配をとらえること』のふたつである、と語りました。改善活動はたいてい3年目くらいで壁にぶつかるケースが多いのです。その時期に改善活動が停滞しはじめますが、そのときに再び炎上しそうになる気配をとらえて、炎が大きくなる前に初期消火してしまうことが大切なのです。

　ここからはいよいよタイトルにあるテストの作り方のお話になります。人が造り出すものには必ず目的があります。ソフトウェアには仕様がありますが、仕様書にそのソフトウェアの目的が記載されるとは限りません。「なぜこの機能が必要か」「なぜこのような要求があるのか」まで記載されている仕様書は意外と少ないものです。

　ここで秋山さんは、「テストのコツはモデルルームの見学と同じです。与えられたサンプルを、限られた時間でまんべんなく見るという意味では同じです」と語りました。家を買おうと考えている人がモデルルームを見るとき、玄関だけを見て満足して帰ることはまずありえません。中に入って、リビングルーム、キッチン、お風呂、トイレ、子ども部屋、さらには収納やベランダまで、すみずみまでチェックします。このとき、主婦であればキッチンの使い勝手はいいか、布団や洗濯物を干すのが大変ではないかが気になると思いますし、家族に小さい子どもやお年寄りがいる人はつまずくような段差がないか、お風呂で滑ったりしないかどうかが気になると思います。ただ何となく見ているだけでは、家を買ってしまった後で「なんかこの家、住みにくいなあ」と後悔するはめになることもあります。

　ソフトウェアテストも同じです。「なぜこの機能があるのか、この機能の意味するものはなにか、この機能が実は無駄だったり、悪い方向に作用したりする可能性はないのか」などを考えてテストをしないと十分なテストはできません。そのためには、機能仕様のテストを作成するのが効果的です。仕様書に赤ペンで確認するポイントを書き込むのです。また、テストの改良ポイントとしては、テスト対象を小さく分解してテストを分割する、ユーザーの声をよく聞く、できればテストする人自身がテスト対象を実際に使ってみることが挙げられました。テストをする人がよい製品、よいテストを知ることが、偽物を見破る一番の方法である、というお話で講演は締めくくられました。

　改善活動がうまくいかない、最初はうまくいっても途中から行き詰る、というのはよく聞く話なので、なぜそれが起こるのか、対策はどうするのかというお話はとても興味深いものでした。また、テストをモデルルーム見学にたとえる話もすごくわかりやすかったです。

　「JaSST'15 Niigata」レポート第1弾はここまでです。次回はワークショップの様子をお届けします。