視覚への疑い(『目の見えない人は世界をどう見ているのか』を読んで)

伊藤亜紗著『目の見えない人は世界をどう見ているのか』を読んだ。2015年に出版された本だが、私が本屋で偶然見つけたのは2017年2月初旬。私は「視点」関係の話が大好物なので、タイトルを見て0秒で手に取り購入。

目の見えない人は世界をどう見ているのか (光文社新書)

目の見えない人は世界をどう見ているのか (光文社新書)

 

「視点」というテーマがなぜ気になってしまうのか、とても個人的な経験・感覚を書いてみる。以下に書くのはこの本の内容と関係なさそうなことばかりだが、目の見えない人の世界の見方を知ることは、著者も書いているように認識の本質に迫るインスピレーションが私にも多くあったのだ。

自分の目での見え方を見つめる 

私は小学生の頃から、なぜだか自分の視覚を疑っていた。中二病?の一つなのだろう。目に見えるものがなぜそう見えるのか。見えていると認識しているものは、他の人と同じなのか、違うのか。そんなことを考えてしまう小学生だった。

目で見えているものへの疑いの姿勢は、今でも変わっていない。中二病が癒えないオッサンだ。自分の目でどのようなものが見えているのかを、日常の中で試して考えたりしてしまう。その中で、「連続に見えるのは思い込み」という些細な経験の話をしよう。

たとえば、まあまあの晴天の日の午後、青空に雲がゆっっっくりと動いているのが見える。その雲の近くを飛行機が飛んでいる。雲と飛行機の両方を、瞬きせずに凝視してみる。この凝視が私にはとても難しく、凝視しているつもりでもちょっと意識がそれて視点を少し横へ移動させてしまったりするのだけど、何とか数秒凝視することはできる。それを何度かやって確かに感じるのは、雲と飛行機の動きがどうも不連続に見えるということだ。ある瞬間見えた位置と向き(その瞬間の変化量)から滑らかに連続的に動いているように見えた直後、雲と飛行機の位置が一瞬前の位置に戻り、そこからまた連続的に動く。そしてまた少し戻る。そんな風に見える。

たとえば、仕事帰りに寄り道をして遅くに帰宅した日。私の家はまあまあ山奥なので、夜遅くなると人工的な明かりは全くない。満月の日でなければ、星の光のみでほんとうにうっすらと地面が見えるか見えないかという程度の暗闇だ。その状況で、私は懐中電灯などを持たずに、家の周辺を飼い犬を連れて散歩する。ほぼ暗闇なので私はゆっくり移動するのだが、犬にとっては問題ない暗さなのだろう。普段通りちょろちょろと動き回っている。白い毛の犬なので、暗闇の中、リードの先に白い塊が見える。その犬がちょこまかと動く様子をこれまた凝視してみる。すると私の目には、まるでとぎれとぎれにしかパケットが送られてこない動画のように、少し動く映像、その後スキップして、違う位置からまた少し動く映像、というように見える。

人の目が受け取っている情報は、不連続なんじゃないのか? 特に暗いところでは、目が受け取る情報の量(光の量や頻度)が少ないので、より不連続に見えるんじゃないのか? 自分の体感を説明するために、そんな私的な仮説を立ててみたりする。

 

こんなこと、世界のどこかで誰かがすでに研究してたりするから、世の中は面白い。2つほどリンクを紹介して、まとまりのない独り言を終わろう。  

渡辺幸三氏のブログ記事『システム設計に求められる適性』では、オリバー・サックスの著書に触れた以下の部分があった。

オリバー・サックスの名著「妻を帽子と間違えた男」の中で、嗅覚と視覚が3週間にわたって異常に鋭敏になった24歳の男性の実話が紹介されている。その結果、彼は事物を分類したり抽象化してとらえることができなくなったという。彼の感覚が受け取る事物は精妙な違いを伴う個々にユニークなものであるため、それらを上位概念でくくることが感覚的に許容できなくなる。「嗅覚が鋭くなってめちゃラッキー」なんて話ではまったくなくて、人間に特徴的な知性を行使できなくなるという致命的な問題が、一時的ではあるが生じてしまったのだった。 

 感覚が鋭くなることによって、抽象化できなくなる。これも、不連続が際立ってしまうこととつながっている話だと思う。

妻を帽子とまちがえた男 (ハヤカワ・ノンフィクション文庫)

妻を帽子とまちがえた男 (ハヤカワ・ノンフィクション文庫)

 

 

もう1つは、スゴ本ブログの『知覚を生み出す脳の戦略『音のイリュージョン』

こちらは不連続・連続の感覚を、音(聴覚)に対して取り扱ったものだ。

音のイリュージョン――知覚を生み出す脳の戦略 (岩波科学ライブラリー 168)

音のイリュージョン――知覚を生み出す脳の戦略 (岩波科学ライブラリー 168)

 

 

私的アンチパターン:本屋

ソフトウェアエンジニアは、本屋になってはいけないという話をする。Amazonのことではない。

 

私には、わりと本を買い漁ってしまう癖というか衝動がある。始まりは大学生の頃に遡る。京都に住んでいた私は、大学生協書籍部、四条にあるジュンク堂、丸善、それから大学の近くにある古本屋などへ行っては、数学や物理学の本を衝動的に買い漁った。まともに読みこなせたものは数少ないので、とんだ散財癖でしかなかったわけだが。この衝動の原因は、自分の根っこにあるコンプレックスが影響しているのだと分析してはいるが、その話はまた別の機会にしよう。

時は移り20代中盤、プログラマーになってみようと決意した私の衝動の対象は、ソフトウェア関係の書籍になった。現在は絶版になっている書籍を、その頃にたまたま購入していたりして、ラッキーだったと思えるものもなくはない。しかし、Windows 32 APIリファレンスなど、ほとんどは本棚の肥やしで高価なコレクションでしかなかった。とんだ散財癖だ。

ともかく私は、たくさんの本を買ってきた。ある趣味にハマって際限なくお金を使ってしまう現象やその対象を、底なしな状況とかけてだと思うが、沼と呼ぶようだ。まさに私は沼にハマり続けているのだろう。まだ抜け出せていない。

 

さて、しばらく前になるが、IT・Web系twitter界隈で以下のtweetが話題になった。 

私もこれが悪習だということには同意する。その理由を語ってみよう。

本を読むには、コストがかかる

本を買うには金銭的コストがかかる。図書館で借りるとしても、相応の労力が必要だ。また、本を読む速度は人によって違いはあるが、それなりに時間がかかることには違いないだろう。それがその人にとって娯楽にあたるのであればコストと考えることに意味はないが、仕事で使うような技術を学ぶための書籍となれば、読んで学ぶためにかかるコストを度外視することはできない。

また、読む対象の書籍が、良書・名著といわれるものの場合は、読んで理解するためのコストが相対的に高いことが多い。

コストのかかる行為を他人に求めるということには、慎重であるべきだ。 

本に書かれた知識には、受け手にとって最適な学び時がある

映画マトリックス(例えが古くて申し訳ない)のように、知識や技術を脳に直接インストールできたら理想的だ。分かりきっているが、現実はそうなってはいない。

そして、私たちソフトウェアエンジニアが身につけていく開発スキルというのは、ソフトウェアが高度に人間の脳内の活動から作られるものであるにも関わらず、アタマだけで学んでいくことが難しいスキルだと私は考えている。何らかの実践を伴わないと、作り手として成長していけないのは、何もソフトウェアエンジニアに限った話ではない。

そして、取り組む人間の持っている前提知識や問題意識、興味と技術レベルとがマッチすると、その実践によって人は大きく成長する。逆に言えば、実践で大きな学びの効果を得るには、問題意識や興味も育てておかないといけないということだ。

 

本の話に戻ろう。

文章には、文脈=コンテキストがある。著者の持つコンテキスト、時代的な背景などもある。そして、読み手の側にも、今置かれている状況としてのコンテキストがある。

自分が過去に読んで有益だった書籍だからといって、ソフトウェアエンジニアの新人に分厚い本を何冊も薦めるというのは、筋が悪い。コンテキストを無視しているからだ。むしろ、読んで何かを学んだ経験を元に、その学び時を見極めて推薦することこそが、先人の役目だ。

良書と言われる本でも、年を経て読み直すと違う面が見える

人は成長し変化していくものだから、問題意識の対象が同じであっても、別のものに見えてくることはある。また、異なった視点から見えるようになっていることだってある。人は常に何かを学んで成長しているからだ。逆に、見え方が何も変わらない場合もある。

ある本を、時期おいて何度か読むと、初めて読んだときには分からなかった部分が、なぜだかスッと分かるようになっていたという経験は誰しも持っているだろう。そして、さらにまた1年後に同じ内容を読んだら、今度は反論を持つようになっていたということだってあるはずだ。これは論理的にあり得るという話ではなく、現実にあるのだ。

ここから言えるのは、本に対する評価を常にアップデートしていくべきだということだ。もしある本の内容について、何年も評価をアップデートする必要がなかったとしたら、次の3つのどれかの状況だと言える。

  • 本の内容が普遍的
  • 本に書かれている対象に対して、自分の考え方が更新されていない
  • 本の内容を理解していない

 

私は本屋がとても好きだ。しかし、どの本屋へ行っても同じように並べられているような本には興味が湧かない。棚のすみにあってタイトルや背表紙の雰囲気が気になって手に取り、パラっとめくったら気になる文章や表現があった。そんな出会いが好きなのだ。そんな一期一会を逃すまいと、ついつい買ってしまうのだが・・・。

 

毎年毎年代わり映えのしない新人向け書籍リスト、そんなものは無視して良いと思う。それは退屈な本屋でしかないのだから。エンジニアは、本屋ではないのだから。

 

 一方私には、本の沼から抜け出す努力が必要だ。本屋へ行くことが、私にとっては人生のアンチパターンなのかもしれない。

ソフトウェアの機能要件と非機能要件についてのメモ

システム/ソフトウェア開発の方法論について議論をする際、機能要件や非機能要件といった言葉をあいまいに使ってしまっていることに気づいた。調査がてら、メモとして残しておく。

機能要件、非機能要件

機能要件と非機能要件はどちらも「要件」だ。それらが指すものは、ソフトウェアの外側にある。

簡単な例で示そう。

  • システムに保持する商品データをユーザーに表示できること。
  • ユーザーは表示された商品リストから選択して、注文情報として送信できること。
  • 受注担当者は注文情報を閲覧でき、出荷日は、該当する注文情報から出荷指示書を印刷できること。

このように、「何ができるか」を表すのが機能要件だ。英語ではfunctional requirementというが、英語の方がズバリその通りで分かりやすい。機能要件を表わす「何ができるのか」の内容は、関数のように、どんな入力に対してどのような出力を行うのか、と言い換えられるのだ。

これに対して、

  • 受注が1日に1000件処理可能で、5年間の運用に耐えること。
  • ソフトウェアの更新のためのメンテナンスによるシステムの停止は、1週間につき1時間以内とする。

のように、パフォーマンスや可用性、さらにはメンテナンス性などについて求めるのが非機能要件となる。

機能要件と非機能要件の違いを大雑把に言うと、機能要件を満たすとは、求められる処理を程度によらず完遂できることを指し、非機能要件を満たすとは、求められる程度をクリアしていることを指す。

要件と要求

ところで、機能要件と似た言葉として「機能要求」がある。「要件」と「要求」とでは指す対象が異なることに注意。「要件」はソフトウェアが満たすべき仕様を述べたものであるのに対して、「要求」は、ユーザーがソフトウェアに求めている事柄を指す。したがって、要求はユーザーの側にある。

要件と要求には、このような区別があるにはあるのだが、現代ではこれらを区別しなくなっているかもしれない。『ソフトウェアエンジニアリング基礎知識体系ーSWEBOK V3.0ー』では、第1章「ソフトウェア要求」として要求について語られており、この中で要求の仕様化というところまで含めてある。要件という言葉はこの本には登場しない。 

ソフトウェアエンジニアリング基礎知識体系 ―SWEBOK V3.0―

ソフトウェアエンジニアリング基礎知識体系 ―SWEBOK V3.0―

 

この周辺には、要求開発といったアクティビティの提唱もあるが、今回のメモのスコープ外なので割愛する。

 

図にするとこんな感じだろうか。

f:id:innx_hidenori:20170219021830j:plain

 

気になる点

以下は現時点で調べきれておらず、自分の答えが出ていない。今後の宿題だ。

  • 機能要件と非機能要件との関係性は構造的にどのようになっているのか。

 

 

ひとりごとを書くことにした

このブログで私のひとりごとを綴っていくことにした。

タイトルの「ひとりごと」は、このブログを書く上での自分に向けた指針でもある。

ひとりごとであること

ひとりごとは、自分自身との対話である。自分の外部の誰かと対話しているわけではないし、ましてや誰かに向けての発信を目的とするものではない。

 

あえて、ひとりごとであることにこだわってみる。

自問自答し、自分で考え、自分の言葉で語ってみよう。

 

不足であること

自分の考えや言葉を語ることには、不安がつきまとうものだ。その原因は、不足。

知識の不足、理解の不足、思考の不足、試行の不足、人生の不足。

常に何かが不足しているから不安なのだ。

しかし、不足が無くなることは無い。

 

「無無明、亦無無明尽」

 

私にとって、不足はあらゆることの出発点だ。だから、自分の不足には鋭く目を向け分析し、他人の不足に対しても尊重する。

だからこのブログでは、むしろ不足のあること、無明であることを楽しもう。

 

こんなことをルールにして、このブログを書いていってみる。

 

システム仕様(モデル・設計・実装)の本質について思ったこと

渡辺幸三氏のブログ記事『「科学研究」としてのシステム開発』を読んだ。プログラマ寄りな思考の私には、記事の趣旨を汲み取って発展させるような意見を述べることはできないが、インスピレーションを受けた部分があるので書き残しておきたい。

watanabek.cocolog-nifty.com

 

システム仕様(モデル・設計・実装)の本質って何だろう

記事の後半で、システム仕様の本質が次のように述べられている。

ところが、システム開発の成果物は、人間が世界のあり方を理解するためだけでなく、その記述自身として機能するという不思議な性質がある。成果物を機械に渡せば、機械がその内容にもとづいて振舞い始める。世界のあり方に関するモデルとして構築されたものが、世界の一部に組み込まれて機能し始める、と言ってもいい。

 これこそが、システム仕様の本質であり、強みなのだと思う。ある角度から眺めれば、人間に対する「現実に関する仮説(モデル)」の説明に見える。これを別の角度から眺めると、機械にとっての「その現実を制御するための動作仕様」に見える。人間と機械の双方の世界で機能する独特な「検証された仮説に関する研究論文」――それがシステム仕様というものだ。

渡辺氏の前提とは異なるかもしれないが、私はここに書かれている「システム仕様」を、モデル・設計・実装を含めた広義の仕様だと解釈した。以下では、このことを前提とする。

私がインスピレーションを受けたのは、システム仕様が、ある一面では人間が理解するためのモデルであり、別の一面では機械のための動作仕様である、という点だ。普段プログラムコードを書いている人間にとって、これは当たり前のことだと読み流してしまいそうな文だ。

だが、立ち止まって考えてみよう。ソフトウェアエンジニアが相手にしている「システム仕様」とは、本質的に二面性を持っているというのだ。この見方は、システムづくりは人間の考えを機械が分かるように翻訳するというような、二者間での一方通行な活動だという見方とは大きく異なる。成果として出来上がったシステム仕様は、人間向けの部分と機械向けの部分とがバランスよく兼ね備えられ、かつ、それが上手く機能しているのだ。

これこそ、私にとってシステム開発の難しさと面白さとが交差して極大になるポイントだ。

読みやすさファーストに対する違和感

システム仕様が本質として二面性を持っているということと関連して、脇道にそれるが、以前から感じている、ある違和感を書いておく。

良いプログラムコードを書くためだと、「読みやすさ」がことさら強調される。『リーダブルコード』がずっとベストセラーだという状況がこれをよく表している。この状況に私は違和感を持ち続けている。ソフトウェアとして大事なのは、人間の読みやすさだけではない。上手く問題を解決できること、そして将来に渡って上手く問題を解決し続けられることが肝要だ。それには、解決手段としてのソフトウェアを人間がメンテナンスし続けられることだけでなく、適切な解決方法が選択されていることも重要だろう。どちらかが上・下ということではなく、両輪なのだ。

そしてこの両輪は、上手く回り始めれば互いに補完しあい、強力な駆動力となっていく。今回取り上げた渡辺氏の記事で、次の表現で書かれている世界観にもつながる。

世界のあり方に関するモデルとして構築されたものが、世界の一部に組み込まれて機能し始める、と言ってもいい。

読みやすさファースト、人間ファーストという価値観を強調しすぎることは、上のような両輪で駆動されるシステム開発への道を阻んでしまってはいないだろうか。

二面性はバランス感覚を育む

ソフトウェアエンジニアは、早い段階で、「システム仕様とは、本質的に二面性を持つものだ」ということを学んで心得ておくのが良い。二面性を意識することで、機能するシステム仕様が持つ「バランス感覚」を早く身につけられるに違いない。

 

おっと、渡辺氏のブログの1つ前の記事は『「他人にとってのわかりやすさ」が至上の価値である』だった。私にはまだまだバランス感覚が足らないようだ。