なんでもかんでも

お店で、商品に、同じカテゴリ(?)でのランキングを表示している、というニュースか何かを見た。

このようなことは、何も今に始まったことではないし、お店でなくても、ランキングはいたるところに出てくる。

ランキングは売上に影響し、売上はランキングに影響する。

「影響」とはどのようなことか?

売れるのは上位にランキングされたものが多くなる、ということ。
上位にランキングされるのは、文字どおり(?)、人気があるということだから、上位の位置づけが強化される、ということ。
なので、上位と下位の差がますますひろがる、ということ。

もちろん、時間がたてば、飽きやその他の要因でランキングは変わるけれど、ある期間内でみると、上記のようなことが言えると思う。

どうなるか?

売るほうからいえば、品ぞろえを(あるていど)絞れる、ということになるだろう。
買うほうからいえば、選択に気を使わなくても、ハズレをつかむ可能性が低くなる、であろう。
(上位にランキングされているものは、多くの人を満足させる可能性が高いという前提)

日常使いのものであれば、このようなやりかたで、売るほうも買うほうもハッピーということになるのではないか?

以上は、あまりにもイマサラの話なのでしょうね。
コンビニエンスストアの経営は、ランキング表示はしないにしても、陳列されていることがすなわち高いランキングということで、上記のような話があてはまるのでしょう。

日常使いでない、たとえば、趣味的なものだと、このようなやりかただけでは、買う側が満足できないが、売る側は少ししか売れないものを用意するともうけがでない。

これに対応したのが「ロングテイル」でしたね。

(3)の記事の最後で、「ソフトウェアのテストの仕事は、製品の品質に関する情報を提供することである。」を引用した。

そうなのです。テストというと、書いたコードを動かして確認するという意味で使うことが多いと思いますが、ちがうのです。

この本でいうテストには、上記のとおり、関連する活動がすべてはいるので、当然コードレビューもふくまれることになります。

そう考えると(?)、どこまでテストするかを考える場合(ここでいうテストはコードを動かすこと)、品質を確認する活動全体の中で考えないといけないことになります。

まぁ、これもアタリマエで、たとえば、明らかに変更箇所が影響しないところはテストしなくていい、と判断するわけです。
(「明らかに」というのがクセものなんですけどね)

で、これも(上記のような判断のこと)、品質を確認する活動なわけですね。ここからすでに(この本でいう)テストが始まっている、と。

「テスト」ということばを2つの意味で使ったせいか、テスト設計はどなるんだろう、と思ってしまいます。
(考えたテスト内容が妥当かどうかの確認はどうするのか?)

『倫理21』をなんとなく読み返しています。
(おととい、さがしものをしていたら出てきて、最初のほうだけ読んで最後まで読んでなかったなぁ、と思って、読みだしたのですが、パラパラしてみると、ところどころ線が引いてあって、最後のほうにもあったので、ひととおりは読んでいたようです)

そのせいかどうかわかりませんが、さきほど駅から会社に向かって歩いているとき、なぜかふと、小学生のころに教頭先生に言われたことを思い出しました。

どちらでもないならそうはっきり言えばいいんだよ、だったか、考え中ならそうはっきり言えばいい、という内容でした。

おそらくそのときまで、学級会のような場で意見を言わなければならないときは、シロクロはっきりさせないといけない、となんとなく思っていたのでしょう...いま、思い出しましたが、学校委員会というのがあって(高学年の各クラスの学校委員(学級委員でなく)が集まる会)、だから、教頭先生がいたのでした。

教頭先生というのは(校長先生もそうでしょうが)、あいさつするくらいで、それ以上の接点はなかったのですが、わたしは、これだけで、この教頭先生が好きになりました。

これがきっかけで、教頭先生がいうような発言/態度ができるようになって、今日に至っていると思っています。

『やさしい統計入門』の付録に"ペテルスブルクのパラドックス"という話が載っています。
(これについては、期待値って何だろう、という観点で思ったことを書こうと思っています)

直感との差異という意味で、よく引き合いに出されるのは、地球の地面から1mの高さを保つようにして、地球のまわりにロープを張ると、その長さは、地面に沿って地球のまわりに張ったロープとどれだけちがうか?、という話だと思います。

もちろん、地球のデコボコは考えずに完全な球体とみなして、...というより、(大)円として計算してみればよくて、地球の半径をRmとすると、前者は2π(R+1)、後者は2πR、となるので、その差は、2π、すなわち約6.28mとなります。

この話を最初に聞くか読むかしたのは、小学生か中学生のころ。へぇっと思いました。

で、そのときは気づかなかったかもしれませんが、いや、先生か誰かに言われたか?、...ポイントはもう1つあって、それは、この差が地球でも太陽でも同じだというところです。

上記の話に(当時)感心したということは、「直感」にしたがえば、差はこんな小さなものでなく、また、大きい星ほど差が大きい、ということになります。

では、こうした「直感」はどのように形成されたのでしょうか?

むつかしい。

円(球)でなく、正方形(立方体)ではどうでしょうか?

1mの高さと地面とのちがいは、4つの角のところを見ればよく、1つの角につき2m差が出るから、2×4=8mの差、ということになります。

こちらのほうは、「直感」にたよらず(?)、わりとはっきり差を意識できるようです。
(こちらも正方形の大きさは関係ありません)

こう考えてくると...わずか数行ですが:-)、...パッとはわからないところに「直感」が入り込みやすいようです。
そして、入り込んだものが、実際とズレていても気づきづらい、と。

第8章"良いテストの条件とは?"を読みなおして思ったこと。

テスト対象を、あるインプットに対して何かのアウトプットをするシステム、とみなすと、完璧な"テスト"ができるとしても、それは、考えられるすべてのインプット(の組み合わせ)に対して期待するアウトプットとなるかを確認する行為、ということになると思う。

つまり、ここでテストされないインプットに対しては何も保証されない、ということになる。

「考えられるすべてのインプット(の組み合わせ)」に対してテストするのだから、ここにふくまれないインプットは、実用上どうでもよいのであるけれど。

とすると、(想定する)実用上のケースとそうでないケースとに、分けることができることになる。

繰り返すが、実質的には、前者がカバーできれば「完璧」であるが、これは「実用上」という条件がつく。
「実用上」にふくまれない例が何かといえば、ムダな機能、がすぐに思いつく。

何が言いたいかというと、上記の意味で「完璧」なテストをして修正をきわめたとしても、(たとえば)ムダな機能の排除にかんしては何もできない、ということです。
(排除できなかったものが、その後のエンハンスで顔を出すことがある、ということは、すぐに想像していただけますね?)

つぎに「実用上」の話。

現実には「考えられるすべてのインプット(の組み合わせ)」に対してテストできるものではない...学生が学ぶ練習問題のように小さいシステムなら可能かもしれないが。

ここへ来て、この本であつかっている話題に戻っていく。
(けれど、以下もこの本に書いてあることではなく、わたしが思ったこと(のつづき)です)

どんなにたくさんであっても「すべて」を確定できるなら、それとの差分を見ることで、テストできなかった部分を、何らかの方法で定量的に把握することができるだろう。

しかし、組み合わせの爆発で、とんでもないことになるとしたら、たとえ数値で表すことができるとしても(10の肩に大きな数字が乗るような)、無限としてあつかっていいと思う。
こうなると、テストできなかった部分を、把握することがむつかしいだろう。

後者の場合、どこまでテストしたらよいのだろうか?
いや、納期は決まっているので、納期までの目標をどのように決めたらよいのだろうか?

前回の記事で、この本を、3つの部分に分けてみました。

で、その最初の部分を、再度ざっとポイントになりそうなところだけ読みなおしてみたのですが、それはアンマリでは?、少なくとも、それはチョット...、という内容で、直接的に参考になるようなところはなかったようです。

ただ、この本を読んでいると、ソフトウェアのテストのことを考えてしまいます...というほど考えこんではいないのですが、少なくとも、これまでよりは考えてしまっています。

今日から出社で、仕事はじめは、昨年中に片付かなかったテストの残りをやっています...数ヶ月ほど前にやった案件を別機種に適用する、というもののテストなので、テスト内容もそのときのものを使っています。

果たしてこのテスト内容でよかったのか、ということは、さておき、どういう類のテストをやったのか(やろうとしているのか)、というふうに見てみると、提供する追加機能が期待どおりに動くかどうかを中心に、いくつかのパラメータを限界値にしたときのテストと、追加機能に関連する既存機能との組み合わせのうち、実際にお客様のところで、使われそうなパタンの確認テスト、...大きくわけてこの3種類だけです。

あまり意識していなかったですが、この程度のテストで済ませているのは(テスト操作数としてもトータル50程度...確認ポイントはその倍くらい...と書いてもあいまいさは変わりませんが)、追加機能以外の既存機能については、テストが終了していて問題がない(はず)、という前提があるからなのです。

では、その前提としているテストの中身はどのようなものでしょうか?

まず、はっきりわかることは、その前提としているテストの中身には、基本的に関与しません...これは、自分の役割上そうなっている、ということです。

もちろん、組織で仕事をしている以上、情報はそれなり共有することができるようになっていて、知ろうとすれば、きっとそれなりに知ることができるはずです。

ところが、上記のような書き方でおわかりのように、知ってはいません、...それが実情です。

自分のまわりの情報共有、この本のことばでいうなら、情報伝達プロセスには、このような問題がある、と言えそうです。

[追記120105]
「直接的に参考になるようなところはなかった」と書いてしまいましたが、第5章"メタテスト ― テストをテストする"の冒頭を引用しておきます。

ソフトウェアのテストの仕事は、製品の品質に関する情報を提供することである。多くの人は、そのような情報を入手するには、コンピュータでソフトウェアを実行するか、少なくともコードを見直さなければならないと考えている。しかし、その考えは視野が狭い。なぜか。製品の品質に関する情報は、ほかにもそこら中に転がっているからだ。ただし、注意深く観察し、それが重要だとわかるマネジャーでなければ、情報は手に入らない。

第3章"全部テストしたらいいのでは？"の最初の節、実行しうるテストの数は無限である、...読んでみると、たしかにそうだ、と思う。

と同時に(?)、ふだんやっているテストを考えると、無限などと意識していないことに気づく。

このギャップが何かといえば、論理的には無限だし、現実的にも無限だろうが、その現実を考えても、有効なテストというものは有限といってよい場合が多く、その有限の範囲でどうにかしようと考えている、ということだと思う。

ここまで思い至れば、しごく当然のことが書いてあるだけだ。

以下、この章のように、テストをいろいろな角度から眺め直してみている部分と、それにつづいて"情報伝達のプロセス"として4章にわたって書いている部分、さいごにその他の部分(適当に要約できなかったので「その他」としました)、という構成になっているようだ。

上記の分類でいうと、最初の部分は、テストというものを見直す、いいきっかけを与えてくれる興味深い話が多いように思われる。

このあと、自分に課す作業は、自分(たち)がやっているテストとこの本のテストとのギャップを洗い出して、改善できるポイントを実践していくことです。

1章づつ、点検するように読みなおしていかないとダメですね。

「パーフェクトソフトウェア」。テストの本であるが、タイトルどおり、ソフトウェアの本である。"はじめに"にあるとおり、ワインバーグさんはテストの本を書かなくては、と思ったということで、テストとは何かから始めて、すこし高いところからテストを見ていると思う。

そういった視点からだと、ソフトウェアの問題が浮き彫りになるようだ。第15章の"ソフトウェアを難しくしないために"にいたって、システムはできるだけ小さく抑える、ときたひには、参りました、というかんじ。

アタリマエといってしまえば、それまでですが、こういうところに行き着くわけね、と。

いま自分がおかれている状況から見ると、それはアンマリという話も多いが、コンサルタントなどしていると、信じられないような組織というものをいろいろ見て来ているのでしょうね。

なので、そういうところは、世の中いろいろね、と思って面白く読めばよろしいかと思いました。

ということで、どんな内容かということは、ほとんど触れませんでしたが、つづきはまた今度。

計画をひとめで見られるように、ガントチャートのようなものをカンタンにつくれるツールがないか、さがしてみたのですが、短時間では(?)、見つかりませんでした。

これは、おいおいやるとして、...。

まずは、to doリストに書き出して、各項目について、締め切りを、仮でもいいから設定することだな、と思いました。
締切は状況に応じて変更してもいいし、to do項目を、必要におうじて分割したり、...つねに更新していくことがたいせつかな、と。

そして、何より大事なのは、それをdoするのは何が目標か、そしてdoし終わったときに、その目標が達成できたのかできなかったのか、足りないところがあるとすれば何で、どのようにフォローしていくかを、つぎのto doとして追加する、という一連の活動が、日常のこととしてできるようになっていく、ということですよね、きっと。

上記のようなことは、そのテの本を開けばいくらでも書いてあるでしょう、きっと。

自分で実践して、分割した小さな目標の達成を積み上げていくことです!

[追記] 念のためですが、...
目標というのは、たとえば、xxxという本を読み終えること、ではありません。
本を読むというのは、あくまで手段ですから。
その本がテキストブックのようなものなら、その中にある、あるいは、別売りの練習問題をやってみるのがよいように思います。
練習問題とはいえ、読むだけより、実際にやってみる/使ってみる、という意味でだいぶマシかな、と。

唐突ですが、中長期的なチェックリストを管理するのって、むつかしいのでしょうね。

長くても数週間で終えられるようなものなら、通常のチェックリストで管理できるけれど...。

何が言いたいかというと、よくある話になってしまいますが、掲げた目標を確実に達成していくには、どのようにすると、うまくいきやすいか、ということなんです。

たとえば、それを達成しないことには何も始まらないという状況であれば、何はともあれ一所懸命やるでしょう。が、いそがしい仕事をやりながら、という状況だと以外とむつかしい、と感じるかたは少なくないはず。

今後しばらくこのテーマで書いていこうと思います。

さしあたり、統計の基本的な事項について、仕事に使えるレベルで理解する、ということを目標にしようと思います。
...これだと、具体的になってないので、いかに具体化してスケジュールするかをふくめて。