合理主義の人類学

はじめに

これから文化人類学、社会人類学を学ぶ予定であるため、現時点での自分自身の考えをまとめておく。現実には未確定な部分は多いが、ビジネスやエンジニアリング、場合によっては科学にかかわる人の思考や行動を分析したいと考えている。

現代の組織、企業や役所、研究機関などは、それぞれ目的を持っていて、自らの資源によってその目的を達成することを仕事としている。例えば企業の場合、ステークホルダーとの共存共栄や社会貢献などもあるが、基本的には利益を上げることが目的となっている。従業員個人としては別に目的を持っているとしても、組織の一員としては利益に貢献することを求められる。

ここでの合理主義とは、目的を設定したうえで、自らの行動を目的達成の手段として位置付ける考え方、としておく。利益のような数字にはっきり現れるものでも、そうでなくても、目的を達成する上では事象のモデル化や評価、広い意味での計算が必要であるが、目的を所与としても、論理だけですべきことがすべて決まるわけではない。逆に言うと、（あいまいな言葉ではあるが）「文化」が発生する余地がある。以下に挙げる問題は論理だけで決まる問題ではなく、そのために個人や組織によって異なる方法論やプラクティスが存在すると考えられる。

「計算」の諸問題

可能性の探索

個人や組織は判断に必要な情報をすべて持っているわけではない。なので調査やブレインストーミングなど情報を取得し、整理する活動が必要になるが、それ自体コストがかかるものであり、また情報の有用性は通常情報を得た後でないとわからない。何をどう調査するかをどのようにして決めるのか。過去の経験などを参照して可能な限り論理的に調査しようとする努力には価値があるかもしれないが、経験を生かそうとする場合は、検討対象となっているケースに過去の経験は当てはまるかという同定の問題が生じる。

多数の選択肢から選ぶ

数社の中から発注先を選ぶ、というのであればあまり問題はないが、さらに複雑なケースもありうる。買い物をする場合、各商品をいくつ買うか（買わないか）という選択を考えるだけでも、各商品の選択が独立でない場合、例えば商品Aについての選択が商品Bについての選択に依存する、といった関係が多数ある場合は人間が比較可能な範囲を超えてしまう。そうした事態を避けるため、明示的、暗黙的なルールはあるかもしれないが、ルールはどのように決まり、どう運用されるのか。

例えば、可能性の探索や選択の過程のどこかで、占い師に相談して決めるというのは、不合理とみなされる場合が多いと思われるが、それによって個人や組織が決定にコミットでき、その後のプロジェクトがスムーズに進むというのであれば、後述するコミュニケーションも含めた全体として考えた場合あながち不合理とはいえない。

他者とのコミュニケーション

コンテキストの形成

ほとんどの仕事は一人でできるものではなく、他の人とかかわりながら行うものである。上司と部下のように上下関係があるものもあれば、プロジェクトメンバー同士のように役割が異なるものの対等に近い関係、コンサルタントとクライアントのように組織をまたがる関係も存在する。ただ、個人の側から見た場合、どのような関係であっても相手を（人として敬意を払うにせよ）自分のために動いてもらう存在、と見ることはできる。以前会社で上司が部下に対して自分を使えと言っていたことを聞いたことがあるが、部下であっても上司からアドバイスをもらったり、キーパーソンにつないでもらったり、会議の場でフォローしてもらったりなどいろいろ「利用」する方法はある。

各個人も組織と同様に目的を持ち、合理的に行動している存在だとすれば、他者との関係は「道具的」(instrumental)になるのが自然である(Bateson 1972)。つまり、相手を自己の目的のために働きかけ、利用する対象と考え、その範囲内で自ら学習を行う。この道具的コンテキストで考えることが妥当な場合もあるかもしれないが、多くの場合、こうした関係だけが組織を支配しているわけではない。業務上の関係から出発したとしても、個人間の友情や愛につながり、目的-手段とは別のコンテキストが現れることもある。もっとも、業務上の関係も続いている場合、この合理性を超えた「我と汝」(Buber)の関係は目的達成を至上命題とする組織にとってはプラスにもマイナスにも働きうるものであり、組織の側でどう扱うかは課題となりうる。他の形の関係も考えられる。例えば、上司は道具的に、部下はパヴロフ的（宿命論的）に考えているような場合、上司は自分の指示への反応によって対応を決めようとしているのに対し、部下は自分が何をしても上司の行動に影響を与えられないと考え、（部下から見て）いつ来るか予想できない上司の制裁におびえるという状況である。

また、大きなコンテキストとしては道具的であるにせよ、チームとして活動するにあたり、自らを、またチームメンバーを一時的に対象に没入させることもある。心理学で「フロー」と呼ばれる状態はおそらくこれにあたる。合理主義的計算をゲームとして楽しんでいれば、道具的コンテキストとフローは両立するし、目的達成のために特定の心理状態を作り出すことができれば、そこでもフローが発生する。実際にどのような形をとるのかは検討の余地がある。

意味の解釈

他者との間で何らかの関係が成立している場合、情報のやりとりが行われるが、その情報が何を意味するかが常に明らかなわけではない。次の行動に移るに十分な程度に意味を解釈できなくてはならない。例えば、会議でビジネスプランについての調査結果が報告される場合に、通常は質疑応答が行われ、応答内容によって、さらには声の調子や身振りなどによって報告者が実際には何を考えているか、報告が判断材料としてどれだけ有用か、また報告者のスキルや性格、体調や精神状態といったメタ情報の判断材料になったりする。

道具的コンテキストで考えている場合、相手は機械とあまり変わらないので、近似として人間-機械から成るシステムで考える。人間が何か入力すると機械は出力を返すが、人間が予想しない出力が返ることもある。人間に予測できないのにはいくつか理由があるが、まず機械には人間が知らない仕様があり、多かれ少なかれブラックボックスである。そのため、機械の仕様を知るためにさまざまな入力を与えて反応を見たりすることがある。次に、機械が仕様どおりに動くとは限らない。ソフトウェアのバグやハードウェアの経年劣化など、機械が本来の仕様と異なる挙動をする理由はいくつか考えられる。相手が人間であっても基本的には同じで、人によってできることは異なるし、同じ人であっても状況によって異なるパフォーマンスを示すことがある。

相手が機械でも人でも、何を参照してどのように推論するか、どこまで探索を続けるかなど、合理主義から一義的に決まらない問題がある。相手が人の場合、それに加えて、相手との関係に依存して、相手側からの解釈も行われるので、それをどう扱うかで状況が変わってくる。

以上のような意味の明確化と判明した（と判断した）意味に対する（コンテキストに対応する）行動は現実には並行して行われる。

自己の統治

フーコー的なテーマである。自分とのコミュニケーションという意味では先に挙げた他者とのコミュニケーションと共通するところもある。現時点の合理的に考えられる自分が、別の時点のそうではない自分が暴走しないよう、（第三者の目を入れることを含め）あらかじめ策を講じる、というのであれば、主体としての自己が客体としての自己をコントロールするというデカルト的二元論がほぼ成立し、特に共通するところが多い。

しかし、様々な点で違いもある。自分に罰を与えることができるとしても、その際の精神状態は他人に罰を与えるときと通常は異なる（「自己と対話する」場合も同様）し、「自己欺瞞」は考えられるが、自分に対してうそをつくことは考えられない。

以下のような言葉を考えてみる。
「私はどうしようもなく罪深い人間だ。」
「私はどうしようもなく愚かな人間だ。」
これを次の言葉と比較してみる。
「あいつはどうしようもなく罪深い人間だ。」
「あいつはどうしようもなく愚かな人間だ。」

両者の違いは、「あいつ」を主語にした場合、「あいつ」が自分について同様の認識を持っているとは限らないのに対し、「私」が主語の場合には、文章の意味としてそうした自覚を持っている。他人が罪深い/愚かであるとしたら、自分が、または信頼できる第三者に依頼して何らかの訓練を行い、「あいつ」をまっとうな人間にすることが考えられるが、自分自身が罪深い/愚かなのであれば、そんな自分自身が行う自己改造の努力も信頼できるものでないし、第三者に依頼するとしても、第三者を判断する自分自身の目もあてにならない。これを徹底すると、神や阿弥陀仏のような絶対的な他者に対する信仰に行き着く。ビジネス（ここではエンジニアリングや科学なども含む）では徹底した自己否定から出発することは不可能かもしれないが（それでも信仰など基本的にはビジネスの外で培われた思想がビジネスに与える影響は排除できない）、自分自身に対する信頼と不信がどのような形をとるか、またそれがどのような行動につながるかは検討課題である。

参考文献（現在手元にない文献も含む）
塩沢由典(1998), 『複雑系経済学入門』
Bateson, G.(1972), Steps to an Ecology of Mind（G.ベイトソン（佐藤良明訳）(2000)『精神の生態学』）
Buber, M.(1957), Ich und Du（M.ブーバー（植田重雄訳）(1979)『我と汝・対話』）
Csikszentmihalyi, M.(1975). Beyond Boredom and Anxiety: Experiencing Flow in Work and Play（M.チクセントミハイ(1991)『楽しむということ』） Foucault, M., et. al.(1982), Technologies of the Self（M.フーコーほか（ 田村俶, 雲和子訳）(1999)『自己のテクノロジー』）

名前をつけるということ

中世ヨーロッパの思想史では、「実念論」と「唯名論」の対立があったとされる。Wikipediaの説明をそのまま借りると、実念論（実在論）は「言葉に対応するものがそれ自体として実在しているという立場」、唯名論は「実在するのは具体的な個物」という立場である。
一般的な「本質」が存在するかという問題はイスラーム教や禅など「東洋」思想においても議論の対象となってきたようである。（井筒俊彦『意識と本質』）

これらの思想で議論で議論の対象となってきたのは、主に「花」とか「犬」といった固体としては物質的な形をとるものである。「科学」や「宗教」、「社会」といった概念に対しては近代の学者がさまざまな定義を試みているが、純粋に分析のための概念と、多少なりとも規範的な概念は扱いが異なると思う。例えば、「社会」はそれ自体ではプラス、マイナスの価値を持って使われないが、「科学」は「非=科学」（疑似科学）より優れたものとして扱われる。

筆者がいるソフトウェア業界でも「科学」のように、純粋に記述的ではなく、規範的な意味を伴って概念が使われる。例えば、「ウォーターフォール」は今ではほぼ記述的に使われるが、「アジャイル開発」や「テスト駆動開発」などはある程度規範的な概念だと思う。（「偽アジャイル」という批判は聞くが、「偽ウォーターフォール」という批判はほとんど聞かない。）

少し前に"TDD is dead. Long live testing."（日本語訳）という主張が出て筆者の周りでも話題になっていた。自分ではあまり実践できていないし、著者はRuby on Railsなどのコンテキストを背景に主張を述べているためなじみのないところもあるが、TDDを記述的な概念、つまりやるべきことの組み合わせとして考えた場合、状況が違えば（変われば）のやり方のほうがよい場合もあるというのは当たり前で、特に衝撃的とは思えない。

なお、著者の主張はユニットテストだけに頼らずシステムテストなど上位のテストをより重視すべきというものだが、一般論としては状況次第であり、コンテキストとなっているRoRの開発においてどれほど当てはまるのかはわからない。極論をすれば、プロジェクトごとに何をすべきか異なる、ということになる。それでは、なぜ議論が行われるのか？

規範的な概念についての議論の方法

TDDのような概念に対する一つの受け取り方は前述のような記述的なものとみなすことである。コンテキストが特定されていない手法であるから、コンテキストが変わればそのままは適用されないのが当然ということになる。ただ、純粋に記述的な概念はマックス・ウェーバーの「理念型」のように外部の研究者が分析のために使うことはあるものの、内部にいる人にとってはあまり意味をもたない。

別のとらえ方は規範的なもので、「状況に適応する」ということも含め、ソフトウェア開発のあるべき姿を表すものである。この考えに立てば、概念自体を放棄することはありえないが、「成功すること」だけが意味内容であればほとんど無意味になる。

ソフトウェア関係で通常使われる方法論あるいはプラクティスに関する概念は記述的かつ規範的なものである。つまり、一定の条件下ですべきことが述べられており、それに従えば何らかの目的を達成できるものとされる。とはいえ、「条件」や「すべきこと」が常に明確なわけではない。どのような法律でも解釈の予知があるのと同様である。

こうした概念が「従ったがうまくいかない」または「よりよい方法がある」などと批判されるとき、反応としては以下のものが考えられる。

1. 擁護：考え方は間違っていない。あなたの理解が間違っている。ある宗教の教えに従いながら幸福になれない人に対し、教えを正しく信じ、理解し、実践していないあなたが悪い、と非難するのと構造は似ている。
2. 拡張：明示されてはいなかったが、もとの概念の中に暗に含まれていたものだ。条件が違う場合にはより一般化して適用すればよい。
3. 限定：そのケースは概念の適用対象としてふさわしくない。
4. 否定：もとの概念は間違っている。新しい、より良いものに置き換えるべきだ。

これらははっきり区別できるわけではない。また、同じ概念の中に含めるか、もとの概念を限定して別の概念を独立させるかはさまざまな事情による。

名前をつけるということ

ソフトウェア開発やさらに広くビジネスで使われる方法論の場合、一つの方法を適用すればすべてが成功するということはほとんどない。方法論は特定のコンテキストのもとでの複数のプラクティスの集まりであり、一部だけ適用して他は別のやり方で置き換えるなど、状況に応じて適用の仕方を調整することが求められる。ある意味ではパッケージ化され、名前のついた方法論は関係者を思考停止に導くものであり、害をなすこともあるが、それでも名前をつけることにはメリットもあるのだと思う。

一つはコミュニケーション上の必要である。名前がついていれば少ない言葉で概要を理解することができる。もっとも誤解の可能性もないわけではないが。
また、一つの理想型として参照されることにより、規律を保つというメリットもあると思う。何か違ったやり方をとろうとしても、理想型があればなぜ異なるやり方をするのか理由をはっきりさせることになるので、安易な方向に流れることを防ぐ効果がある。

意味のある議論？

ある方法論やプラクティスが特定のコンテキストのもとで成り立つ（有効である）、またコンテキストを言葉だけで表現することはできないと考える場合（基本的に妥当な仮定だと思う） 、意味のある議論としては、

1. 個別具体的なケースで特定の方法論やプラクティスを適用すべきか
2. 特定の条件が方法論やプラクティスの適用にどのような影響を与えるか（メタレベルの議論）

特定の現場にいない人は（ヒアリングを行うなどして）意味のあるアドバイスを与えることはできるとしても、コンテキストをすべて知っているわけではないので判断には限界がある、ということになると思う。

方法論の適用条件に関して、また定式化に関してどのようなことが議論の対象になりうるかについてはまた別の機会に投稿したい。

テスト方法論の位置づけ

先回の投稿に続きWACATE2013冬の話。
ブログの都合上実際のプログラムとは違う順番で書くことにする。

2日目最後のクロージングセッションでSQuBOKをはじめとした知識体系が紹介された。自宅にもSQuBOKの本はあったがしばらく読んでおらず、取り上げられるということで直前に少しだけ読んでいた。もっとも、本はあくまでもガイドであるということが強調されていた。本当に詳しく知りたいなら参考文献にあたる必要がある、ということだ。

確かに、膨大な知識体系を全て吸収して使える状態になっていればよいのだが、実際にそんなことができる人はほとんどいない。各人の職務や関心に応じて一定のレベルまで知識を持っておき、その先が必要になったら文献にあたる、という使い方を想定しているようだ。もっとも、手法があることを知っていてもベースとなる考え方がないと必要なときに吸収できないし、適切なときに文献を参照する、ステークホルダーに相談する、といった行動をとれるようにするためにもある程度のスキルが必要なのだろう。

私が業務の中でテストに関係して一番問題だと思うのは計画段階でテストすべきことをもれなく抽出することである。最初の段階で間違ってしまったら、その後でどれだけ（技法などを使って）詳細を詰めても十分にテストできないことになってしまう。不覚ながら知らなかったが、テストの研究も優れたエンジニアの思考方法を抽出する、という方向に向かっている、という話も聞いた（文脈を無視してはいけないのかもしれないが）。

発想が問われる問題なので、方程式を解くようなやり方は通用しない。そもそも創造性が問われる状況に対してどのようなアプローチが可能なのか、という問題は以前から疑問に思っていたことである。如何に考えられた話であっても、話を聞いて疑問がすべて解消する、というようなことは期待できないが、学んだこと、考えたことを書いてみたい。

テストの観点をめぐる2つのセッション

テストすべき観点を抽出する、ということに関係する話としては、1日目の「リスクベースドテストを活用しよう」と2日目の「探してみようテスト条件」があった。前者については講演者によって資料が公開されているので、興味を持たれた方はこちらを参照していただきたい。

「リスクベースドテストを活用しよう」 は講義と演習の形式で行われたが、「事象の原因（ハザード）」「事象」「危害」の区別のあたりから少し食傷気味。例題としてネットゲームの話が出てきた が、筆者自身は全くやらないのでアウェーな感じ。席が一緒だった方の一人はゲーム会社に勤めているとのことで、知識としては全く太刀打ちできないが想像力を働かせて考える。

演習では重大度と発生確率の検討、 危害のリストアップ、それから危害シナリオの検討、リスク管理表の作成を行ったが、意図としては重大度と発生確率の検討、 危害のリストアップは危害シナリオより前に、独立して行う、ということだったようだ。確かに考えた危害シナリオに引っ張られてそれ以外のリスクが出てこない、といった可能性もありそうだが、筆者の場合シナリオの方が先に思い浮かんでしまった。

「探してみようテスト条件」ではラルフチャートを使ったテスト条件の洗い出しが講義と演習で扱われた。ラルフチャートはソフトウェアテストではHAYST法で使われる。条件の洗い出しが目的であればマインドマップやブレインストーミングなど他にも方法はいろいろあるが、個人的には好きなやり方である。もっとも、演習で手を動かしてみると渡された仕様書に書いてある内容から洗い出すことはできるが、それ以外のことになかなか頭が回らない。
個人ワークの後で各人が書いたものを持ち寄ってグループワークを行ったが、自分が気づかなかった条件を書いていたりして、まだまだ甘いなと思った。それと同時に、複数人で見ることによって一人だけでは抜け落ちてしまう部分をカバーするというチームとしての使い方を身をもって体験した。（もっとも、チームとして使うことを前面に出すなら、よりインタラクティブに進めることもできただろうし、今回のワークの中ではおまけくらいに考えたほうがよい。）

各方法論の関係性

ラルフチャートの使い方として、「ノイズ」や「アクティブノイズ」を条件として考慮する、という話もあり、その中にはシステムのクラッキングやネットワークの切断なども含まれる。突き詰めれば、あえてリスクベースなる概念を使わなくてもリスク低減を図ることはできてしまうのではないか？一方、リスクベースの「リスク」の概念を拡大していけば、仕様ベースのテストとの境界もかなりあいまいになるのではないか？といった疑問も出てきた。論理的にはそうなのだと思うが、人による違いはあるにせよ、問題によってアイデアが出やすいツールがあるので、道具箱に沢山道具を持っておき、必要なときに使えるようにする、ということでよいのだと思う。

ソフトウェアテストの方法論については、例えばこちらにあるように、日本だけを考えても方法論が乱立している、という印象である。（大御所の先生方に対して）それが悪い、と言いたいわけでは全くなく、むしろ、各自の経験や思考方法の違いに応じて、それぞれ自らが納得でき、かつ他の人にも使える方法論を考えている、ということなのだと思う。
アジャイル開発におけるテストの話も少し出ていたのでアジャイルテストの本（これとか）を見直してみたが、 計画段階から詳細な技法レベルまで、「抜け漏れのないテストを行う方法」についてはほとんど記述がなく（！）、その一方でチームとしての協力の仕方や（自動化関係だけでなくアナログなものを含む）ツールの使い方などはストーリーを含めて豊富な記述がある（少なくとも筆者にはそう思える）。

アジャイル開発ではスキルもモチベーションも高いエンジニアが開発に参加するから、詳細な技術は必要になったら学ぶ、ということでテスト条件の抽出などは対象外としているのだろうか。あるいはクリティカルなシステムにアジャイル開発が適用されることは少ない、ということも影響しているかもしれない。

逆にテスト方法論を考える側は重いフレームワークを作っているように感じる。実際には一人でフレームワークに従って進める、というものではなくチームとして品質を保証していることは認識されているが、一人で完結させる前提のときと複数人で互いを補う場合とでは立ち位置は微妙に変わるのではないかと思う。

ソフトウェア開発が扱う仕事の幅は広い。それを単一の方法論でカバーしようとなると、どこかで現実に合わない部分ができるか、実務に使えない抽象的なものになるか、あるいは異なる前提に基づくものの寄せ集めになる可能性が高い。その意味で、クロージングセッションでも紹介されたSEMATのように、異なるプラクティスを組み合わせるという進め方は有効なのだろう。その際にはプロジェクトや個人、チーム、組織の状況に合ったものを採用する必要がある。それも「○○のときは××」といった機械的なものではなく、メンバー間やステークホルダーとの関係も考慮したものになるだろう。

個人と書いたのは、少し話がそれるが、以前あるイベントに参加したときに、どうしてもマインドマップが使えない、と話している方がいたことを思い出したからだ。その方ができることとしては、 無理やりにでもマインドマップを習得する、あるいはマインドマップを使わなくても豊かな発想ができる方法を身につけるなどである。どうするのがよいかは脳というハードウェアの構造次第である。それほど極端ではないにせよ、人による向き、不向きはあるので、外部の状況だけで一概にこのやり方がよいとはいえない。

以上、WACATEで学んだこと、考えたことを独断と偏見に基づいて書き連ねてみたが（一応今回の投稿で終わりのつもり）、ある程度はつながったかなと思う。Scienceの言葉で表現しようとすると一部しかできなさそう（むしろArtに近そう）だが、本当に奥が深い世界である。改めて関係者の皆さんに感謝するとともに、日々の業務で使えるようにしていきたい。

QAの論理、アジャイルの論理

一昨日、昨日とテストエンジニアのためのワークショップWACATE２０１３冬に参加してきた。
諸々の事情から参加は3年ぶりで久しぶりの再会という方も多く、 楽しかった、疲れたとともに懐かしかった。参加者、セッションの担当者・講演者、スタッフの皆さんありがとうございました。
学んだこと、考えたことを忘れないうちにブログを投稿することにする。

なお、今から書く内容はワークショップのセッションや分科会での話し合いなどから個人として考えたことであり、WACATEの全体像や雰囲気を再現するものではなく、時系列的に並べたものでもない。
また、投稿内容に含まれる誤りや意味不明な点はすべて筆者個人の責任である。

夜の分科会でのこと

夜の分科会（私はその一つに参加）の際に、ある参加者がQA（品質保証）として自社のソフトウェア（プロダクト・プロセス）に統一した基準を作り、守ってもらうことで品質を向上させたいと話していた。それについて別の参加者が結局は人に依存ものであり、基準を作ったとしても最低限のものでしかないと話していた。後者の方とはその後でも話す機会があり、（私が曲解したところもあるかもしれないが）大体の考え方を理解できたかと思っている。

私自身は以前テスト、品質保証を担当していて、プロセス改善などを行っていたこともあり、またアジャイル開発（本当のagilerの方から見ればfakeだとは思うが）に取り組んだこともあり、双方の利点や前提条件をある程度理解できる立場にあると思っている。

QAの論理としては、かなり大雑把にまとめると、開発チームは顧客や経営陣などからプレッシャーにさらされていて、開発者だけに任せていると期待に（少なくとも表面上は）応えるために品質をおろそかにする傾向がある、だから第三者が品質を守らせなければならない、ということになる。

一方、アジャイルなどを実践する開発者にとっては、プロジェクトによって正しいやり方は異なる、プロジェクト固有の事情を知らない第三者が口を出してもデメリットの方が大きい、さらには標準を守らせるという発想では守らせること自体が目的と化し、本来の目的が見失われるといったところだろうか。もちろんアジャイル開発でも「テスター」という役割は存在するが、開発チームの一部としての位置づけである。

私としては、特に人間にかかわる理論や思考については、一般化されたものであれば、ソフト開発に限らず、完全に間違っていて学ぶところが何もない、といった考え方はほとんどなく、 問題なのはどのような前提に基づいていてどの範囲で適用できるか、またどれだけ意味内容を持っているかだと思っている。どこまで成功するかはともかく、この観点から検討する。

コインの両面としての現実主義、理想主義

QAの論理は基本的には現実主義に立ったものだと思う。開発者が自らを律することは不可能、もしくは非常に困難だから、第三者の力を借りるしかないということなのだから。こうした考え方は三権分立や社外取締役の設置などソフトウェア開発以外の世界でもみられるものであり、ある種の知恵に基づくものである。ただ、上にあげたようなQAの論理（少なくとも洗練されていないもの）はその裏に素朴な理想主義も含んでいるように思える。

まず、QAに対する抑制と均衡が働いていない。QA自体がセクショナリズムに陥って自らの存在意義を示すために（と意識はしないかもしれないが）必要以上に開発に介入する、という可能性が考慮されていない。 また基準や標準の浸透が必ず品質の改善に結びつくというのも楽観的に過ぎる。（開発効率を示す指標としてコード行数が測定されているから、無駄にコードを書く、といった冗談を話すこともある。）

一方のアジャイルモデルは開発者（チーム）が自律的に品質を高めていけると考える点では理想主義的であるが、QAのような第三者がプロジェクトに貢献する能力や可能性については懐疑的であり。また、遠い昔に他人によって決められた重いプロセスや基準を現在の開発者（およびQA）が自らのものとして受け止めてその精神を守り、発展させていく可能性については悲観的である。

協力とモニタリング

以上に書いたことから、少なくともQAが自らが決めた基準を杓子定規に適用して開発チームを批判する、というのは正しくないものの、状況次第という面はあるが（アジャイル開発における「顧客」とは別に）品質を守るための第三者が必要な場面は多いと思う。その場合、QA（またはそれに似た立場の人）としては、開発者とどのように協力するかが課題となる。

プロジェクトについての十分な知識を持ち、かつ品質を守るために必要な意見を述べ、チームを動かす、というのが理想的な姿ではあるが、以下の理由から通常はあまり現実的ではないと思う。

• チームメンバーであってもプロジェクトや開発の詳細をすべて知っているわけではない。特にパートタイムでプロジェクトにかかわる場合、知識が不足することは避けられない。
• プロジェクトや開発内容にあまりに精通してしまうと、第三者として考えられなくなる。

もしこれができるなら開発者としても自ら規律をもって品質を高めることができる、 よってQAは不要、ということになるだろう。
より現実的なのは、開発者とQAが異なる情報を持ってコミュニケーションを行い、望ましい解決策を探ることだが、コミュニケーションに多少のコストがかかるとしても、画一的な基準の押し付けとなれ合いという両極端を避けるには必要なことなのだと思う。ただ、コミュニケーションの中身についてここで一般的に述べることはできない。個人間の関係によるところも大きいだろう。

小結

ここまで品質保証体制の背後にある前提を抽出しながらそれぞれのメリット、デメリットを考えたが、各種の前提が成り立つかは人次第である。（ただし、同じ人でも何らかのきっかけで変わることはあるかもしれない。）

開発や品質保証の体制をどうするかはプロジェクトの性質に依存するのはもちろんだが、メンバーにも依存するものであり、正しい方法は一つには決まらない。個人も組織も良い面と悪い面は表裏一体のことが多く、良い面だけを伸ばして悪い面は現れないようにするというのは（追求には値するが）簡単ではない。

WACATE1日目のBPPセッションとセッション2では相手のタイプによって接し方を変えることの必要性が説明された。BPPセッションでは「炎上駆動改善」なる方法が紹介され、意識が高くない人も改善に巻き込むための方法が解説された。これもメンバーの動き方についての仮定に基づいた方法論である。自分自身も理由をつけて改善を先延ばしにすることがあるので注意しなければならないと思ったが、意識が高い/高くない、というだけでなく、あることに意識が向いている人、別のことに意識が向いている人、…という面もあると思っている。付け加えるとすれば、相手だけでなく自分についても自分に合ったやり方、合わないやり方があると思う。

他のセッションについても（これもセッションの内容からは離れることになりそう）書きたかったが、時間がかかりそうなので後で別に投稿することにしたい。

自己啓発の論理（メモ）

先日久しぶりに書店に行った。
自己啓発本、もうすこし広くビジネス本を読むのはあまり気が進まないが手にとって見た。
以下に書く内容はいくつかの本をさらっと読んだ（見た）感想で、メモ程度のものである。
なので、出典も特に挙げない。

自己啓発を行うのは自分自身に不十分な点がある、あるいはさらに成長できる点があるからである。それを否定する人はまずいないと思うが、目的とそれを達成する手段は一つではない。

自己啓発本のスタンスとして、以下のような点で分かれるように思える。（後半に挙げるものは「各論」的な部分である。）
目的
・特定の目的（億万長者になるなど）を達成すること
・それぞれが自らの目的を達成すること

適用範囲
・一定の目的、性格などを持つ人
・すべての人（タイプ別に処方箋を示すものもある）
万人向けの書き方をしているように見えても、実際は特定の人だけを対象としていたり、わざとぼかしていたりする場合もあるのだろう。

自分への態度
・ブレない自分自身の軸を確立することを重視
・外部からの刺激を受けて自己変革していくことを重視
自己啓発本であるかぎりは後者の要素があることは当然であるが、それとある意味緊張関係にある前者の扱いが説得力を決めるのかもしれない。

自分自身の限界
・自分を追い込め。そうすればおのずとがんばる。
・無理をしろ。
・限界をわきまえろ。

社交
・「成功者」は正しい。彼（女）らに近づくためあらゆる手をつくせ。
・信用できる人か自分で見極めろ。

新技術
・役に立つかもしれないから試せ
・「デキる人」に見えるようにするためにもやってみろ
・自分に合えば続けろ

繰り返しになるが自己啓発は現在の自分自身に問題があると考えるから行う営みであり、それは情報の取得についてもしかりである。現在の限界がある地点から、有限の時間その他の資源を使って判断しなければならないから、多分に「経済的」な側面がある。そこからさまざまな方法が生まれるのだと思う。

ここではかなりパターン化した書き方をした。上に挙げたものを含めた各種の論点に対する態度の組み合わせで著者のスタンスが決まってくると思うが、いわゆるハウツー本ならそれほど期待できないかもしれないが、パターンでは表せないような深みのある本もあるかもしれない。

私としては、数時間読んだだけだが、方法論としても、価値観としてもかなり違和感を持ったものも多い。自己啓発本に書かれた内容にしたがった結果病気になったり、借金地獄に陥ったりするなど失敗したとしても、著者は責任を負ってはくれない。読者の不安をあおって儲けようと考えている悪質な著者や出版社はもとより、良心的な著者や出版社でも、個々の読者の状況に該当するかは保証できない。何に従って何を退けるかは結局自己責任で行うしかない。

少し読んだ後でも自己啓発本を読むのに気が進まないのは変わりないが、もう少し読んでみようと考えている。時代ごと、国ごとなどでの特徴もあると思う。同時に自己啓発を分析した本（例えばこれ）も読んでみたい。この種の読書のほうが個人的には好きである。好きでないことにどのように対処すべきかも本によってアドバイスがことなるが、私の場合は「分析」の観点から入るなら相対的に苦にならないかもしれない。

「原因」の語り-失敗を分析する視点

 人類学では、研究対象となる人々がある出来事の原因をどのように考え、説明しているかについて扱っているものがある。


 エヴァンズ=プリチャードによるアフリカのアザンデ族の研究はよく知られている。それによると、アザンデ族は何らかの不幸な出来事が起こった場合、原因として誰かが妖術(mangu, witchcraft)をかけたと考える。妖術は唯一の原因と考えられているわけではなく、人間と出来事を結びつけるものである。
 例えば、シロアリが穀物倉を侵食していった結果崩壊して、そこで涼んでいた人がけがをした場合に、なぜこの人がいるときに倉は崩れたのかと問う。アザンデ族の人々は、シロアリが穀物倉を侵食したために崩壊したことと、日中の熱と日射を避けるために人々が倉の陰で涼んでいたことは知っているが、この２つの偶然の一致を説明するために、妖術が持ち出されるのである。
 （なお、ここで妖術は意図的にかけられるものではない。意図的に行われるものについては別の概念があてられている。）


 また、ベイトソンはニューギニアのイアトムル族で用いら れるngglambiと呼ばれる概念について検討している。ベイトソンは「危険で伝染性のある罪(dangerous and infectious guilt)」と訳しているが、イアトムル族の観念では、ngglambiのある人（本人）やその親族に病気や死が及ぶ。ただし、病気や死の経路は様々で あり、何らかの危害を被った人が邪術を使って加害者（あるいはその親族）に復讐した場合にも、加害者はngglambiによって死んだ、あるいは病気に なったとされる。


  科学技術が発達した現代では「原因」に対する考え方はもちろん上に挙げたような例とは異なるが、何らかの出来事、特に不幸な出来事が起こったときに原因を知りたいという思いは強い。


 「原因」と一言で言っても、その意味するものは見方によって異なるものである。数値シミュレーションは原因分析の一つの方法であるが、自然法則はもとより人間 行動についても一定のパターンに従うものとして、システム全体がどのように振る舞うかを検討する。また、刑法や民法では、刑罰や損害賠償の責任の有無を決 めるために因果関係を検討する。
自分自身の勉強不足のため原因分析の体系をすべて挙げることはできないし、挙げたものについても理解が不十分なところはあると思うが、ここでは人間がかかわる現象としての失敗について、「なぜなぜ分析」と「失敗学」を例に、原因についての語り方を検討してみる。


 なぜなぜ分析については基本的に小倉仁志『なぜなぜ分析10則』および同『なぜなぜ分析実践編』によっている。失敗学については畑村洋太郎『失敗学のすすめ』を中心に、一部「失敗知識データベース」を参考にしている。（なお、畑村氏は政府の「東京電力福島原子力発電所事故における事故調査・検証委員会」の委員長となっているが、ここでは触れない。）


概要として両者の違いをまとめると、以下の表のようになる。

当事者主導のなぜなぜ分析が客観的な表現を徹底するのに対して、第三者主導の失敗学が主観的な語りも重視するのは以外な感じもするが、当事者、第三者それぞれの視点に立つ場合に抜けやすい側面であるためにあえて強調しているということだろう。
目的と対象の間に論理的な結びつきはないかもしれないが、他に波及させることを前提とせずに、専門の第三者を入れるコストをかけられるのは深刻な問題だけである、という経済的な側面はありそうである。


分析の目的と分析者の立ち位置


 なぜなぜ分析は当事者が自ら抱えている問題を解決するために使われることが想定されている。何らかのトラブルが発生した場合に、現場だけでなく管理職や経営層にも解決すべき課題があることは多いが、なぜなぜ分析では

管理監督職が、あるいはトップが、現場から上がった分析結果からマネジメント上の課題を見いだし、それぞれの役目に応じて分析し、再発防止策を打ち出すことが求められる。

と現場の従業員、管理者、経営者がそれぞれの立場で分析を行う、という形をとることが想定されている。


 なぜなぜ分析では個別具体的な現場の課題を解決することに主眼が置かれている。分析した内容を会社共通のデータベースに保存して、他の人が参照できるように することも勧められているが、これは「今後のトラブルが発生した時のチェックリスト」という位置づけで、これを社内の別の部署でトラブルを未然に防止する ために使う、といったことは強調されていない。


 基本的にだれもがなぜなぜ分析を実施することが想定されているの で、分析する人の問題を避けて通ることはできない。分析のスキルを習得することが必要とされ、そのためのプラクティス（「なぜなぜ分析10則）が紹介され る一方、（分析のスキルがあっても）トラブルの当事者であることや、知識・経験の特定分野への偏りは、個人の努力で克服すべきものというよりは避けられな いものとされ、偏りをなくすために複数人（5-6人）で、かつ「バランスのとれたメンバー編成」で臨むべきものとされる。


 一方、失敗学では第三者の視点で、会社さらには社会全体のために知識として残し、他人・他社の例を教訓としてトラブルを繰り返さないことを目的としている。


 失敗の当事者が自ら分析することも否定してはいないが、

組織として真剣に取り組む場合も、本来ならば失敗した当事者から話を聞き出す専門のスタッフを育成し、任にあたらせるぐらいのことが必要

と分析の専門家の育成を求めている。全体のトーンとしても、「当事者に聞いたあとで、聞き手自身が、第三者の立場でもう一度、失敗にいたるまでの客観的な脈絡を立ててみる」など、当事者自身よりも、第三者による分析を前提とした記述が多い。


 一部の専門家が（当事者などの協力を得て）行うもの、というスタンスのためか、分析者の偏りについての言及はあまりない。一方で、

データベース化すべき情報は、…合計三百個程度で十分です。この三百という数字は、ひとりの人間が知識として吸収できる限界でもあります。

と、分析者（人間）一般の制約が失敗情報の知識化にあたって考慮される。


 情報の数が制約されている分、引き出される教訓は一般的なものである。失敗情報を伝達するためのステップとして、「記述」、「記録」の次に「知識化」が行われるが、内容は以下のようなものである。

無理な注文をこなして取引先から評価されるには、必ず約束を守らなければならない。急なトラブルにも対応できるように、スケジュール調整には細心の注意を払うべきである。また、クレーム処理はとにかく誠実な対応が一番である。

かなり一般的な情報であり、この情報を知っていたからといって無理な注文を引き受けるという失敗がすべてなくなるとは考えられない。この情報を参照した人が生々しい現場の状況を追体験してより慎重になり、同様の失敗が減少する、というのが効果だろう。なぜなぜ分析では狭い射程に対して、より確実性の高い分析と対策が要求される。


  ニュアンスは微妙に異なるものの、どちらも原因究明を目的としていて、責任追求のために使うべきでないことが明言されていることは共通している。


分析の対象


 なぜなぜ分析の対象として取り上げられているのは、日々の業務（ルーチン）の中で発生する小さなトラブルが中心である。同じ作業が今後も繰り替えされることが想定されるような仕事が例として挙がっている。
  それに対して、失敗学で分析の対象となるのは、大事故、あるいは実際には起こらなくても大惨事になりうるような失敗である。


「原因」とされるもの


  無知や誤判断など、なぜなぜ分析と失敗学が共通して原因（の連鎖の一部）として挙げているものは多い。なぜなぜ分析の「間違いの4段階」（情報、受取、判断、行動）は失敗学での「誤判断」にほぼ対応する記述がみられる。その一方で、両者ではっきり扱いが異なるものもある。


  具体的な問題としては、多忙やそれに伴う疲労を背景とした失敗に対するアプローチに両者のスタンスの違いが表れている。なぜなぜ分析では、

作業者がどんなに焦っていたとしても、極力間違えないような仕組みに改善することが、本来の目的である。 

「誰でもはまりやすい罠に偶然にも当該者がはまってしまった」という前提で、個人的な話は避けながら、ミスの本質に迫っていかなければならない。

とされ、多忙や疲労などの「個人的な話」は、再発防止策につながらない「言い訳」として退けられる。管理職や経営者レベルの分析の例はもともと多くないので たまたま載っていないだけかもしれないが、上記の記述からすれば、（全社的な）過酷な労働環境などが挙げられることはなさそうである。


 失敗学では、失敗原因の分類の中に「不注意」の項目があり、

十分注意していれば問題がないのに、これを怠ったがために起こってしまう失敗です。体調不良や過労、あるいは多忙中や焦燥感を募らせて平常心を失っているとき、つい集中できずに起こしてしまうケースです。

 と原因のなかに含めており、またより上位のレベルの問題である「組織運営不良」の中に「構成員の疲労」が含まれている。


 失敗学では失敗にかかわる人的要素を一貫して重視しているが、なぜなぜ分析では、分析にあたるときは別として、分析対象の作業に関しては人に依存しない仕組みをつくることに重点が置かれていて、人の要素は可能な限り小さくしていく方向である。
 もっ とも、なぜなぜ分析でも再発防止策として、間違いがあっても被害が出ない（小さい）うちに気づいて、正しい処置を施せるようにするために、「当事者が気づ ける・処理できる能力を身につける」ことが挙げられている。「誰でもはまりやすい罠」自体は残っていて、担当者がはまらないようにする対策ではあるが、作業者の状況に依存せず、ほぼ確実に対応できることであれば認められているようである。


原因の語り方


なぜなぜ分析では「論理的」な分析が重視されるとともに、表現も当事者の主観や心理状態などをまじえず、客観的であることが推奨されている。（「知らなかった」とか「何も考えずに」といった知識や思考にかかわる表現は排除されていない。）
失敗学はこれとは異なり、主観的な情報を重視している。「客観的」な報告と「主観的」な報告を並べた後で、

身近な問題として実感できるのは、むしろ日記のように心理状態まで克明につづられた後者の記述の方です。人は自分の立場に置き換えてそれを実感できたときにはじめて、…他人の失敗から教訓を得ることができるからです。

と主観的な情報を高く評価している。もちろん、当事者の主張を鵜呑みにするわけではないが、「その時点で同感じたか、どう考えたかという当事者の見解」は重視され、後で「真の原因」が別のところにあることがわかってもデータベースからは消去されない。


なぜなぜ分析は前述のように当事者が自らの問題を解決することに主眼が置かれているが、当事者にとっては主観的な報告など書くまでもなく、トラブルが起こったときの心情や思考は思い出せるものである（時間がたってしまうと思い出せないものもあるかもしれないが）。しばしば当事者に欠けるのは客観的な視点であり、それを補うためになぜなぜ分析のような方法論が必要とされる。他の人が類似の状況で同じ失敗を避けるために分析結果を利用することはあまり想定されていないし、なぜなぜ分析での原因と対策は前述のように、基本的には人に依存しないものであるため、主観的な情報は必要とされない。
失敗学では他の人が教訓を得て失敗を繰り返さないようにすることが目的であるが、失敗情報を参照する人は通常失敗が起こったコンテキストについては知らない。客観的にコンテキストを記述していくことも可能かもしれないが、主観的な記述の方が実感がわくし、客観的な情報で必要なものは第三者がまとめるので、当事者が客観的に語る必要はない。情報を使う人のことを考えて主観的な情報を載せているということである。


自律と他律


 ここまでで述べたように、基本的にはなぜなぜ分析が当事者の視点に立ったものであるのに対して、失敗学は第三者の視点が強い。このことが原因を語る上での違いに表れていると考えられる。


 組織や文化の問題はなぜなぜ分析ではほとんど言及されない。「的確で漏れのない再発防止策を導き出すこと」が目的であり、「社長の首を欲しているわけではな い」ため、現場レベルの分析では現場で解決できるような原因と対策がとられ、また管理者・経営者による分析でも自らがとりうる具体的な再発防止策をとろう とする。
 一方、失敗学では失敗を活かす、また致命的な失敗をなくすための組織、制度、場、考え方が低減されるなど、しばしば言及されてい る。失敗をデータとして残すにあたっても、「技術的な原因の他に、強く影響している背景として経済的背景、心理的背景などの軸も加える」ほうがよいとされ る。


 当事者の視点で会社の組織や文化を扱うことには困難がある。仮に問題があって直されるべきだとした場合、組織内部の人が改革にあたる、ということも考えられ ないわけではないが、当事者は問題がある組織や文化にどっぷり浸かっているので、何らかの対策をとるとしても組織や文化が持つ問題を反映したものになると 考えるのが自然である。中にはそうではない人もいるかもしれないが、当事者自ら対策をとる場合、そうした人が対策チームで大きな役割を担うのはむしろ例外的なケースと考えられる。


 なぜなぜ分析で、分析を行う人の（知識や経験ではなく）心理や文化への言及は多くないが、主語を明示することとか、例えば「『何も考えずに』とか、『勝手に』といったダイレクトな表現をすることで、自ら腰ひもを締め直す」といった記述がある。
 なぜなぜ分析では仕事に必要な5つの力として、「論理力」、「観察力」、「直感力」、「改善力」、「チーム力」が挙げられており、直感力は論理力と観察力か ら生まれ、改善力は（論理力と観察力の裏付けのあるなぜなぜ分析の実践によって）「改善の基礎を学んだ上で、日頃から改善を実施していくことで培われ る」。これらができていれば組織や文化の問題も解決されているはずである。組織や文化は直接的に直す対象ではなく、なぜなぜ分析を実践する中で間接的に作 られていくもの、という位置づけのようである。当事者の視点に立つのであればこれがおそらく妥当な進め方だろう。


 一方、失敗学のように第三者が中心となって対策をとる場合、 主体と客体が重なることは本質的な（不可避な）問題ではない。第三者の力量が不足していても、それは失敗学自体の問題ではない。失敗の人間的な側面への対策は、モノに対するのと同じように、対象となる個人や組織にどのように影響を与えるのかという手段の問題として語られる。


  強力な第三者の介入を入れることによってなぜなぜ分析のような自律的なアプローチでは不可能な変化を引き起こそうとしているのであるが、これは強みである反面、外部の専門家への依存、裏を返せば自らを変化させる力が生まれない、という問題も引き起こす。（常に外部に依存するわけではないかもしれないが、少なくとも自律的な組織ができるような論理にはなっていない。）


おわりに


 以上のようになぜなぜ分析と失敗学にはいくつかの共通点と相違点が存在するが、これは方法論を提唱した人の視点であり、実際に使っている人の見方は入っていないので、それについては別に検討が必要である。また、海外のものを含め、原因分析の他の枠組みについてもさらに検討してみたい。
  自分自身の会社ではなぜなぜ分析は適用例があるが、失敗学についてはない。上に挙げた視点の違いも影響しているのかもしれないが、特に不作為に対して「なぜ」と言っても適切な答えが出てくるかわからない。失敗学は具体的な進め方についての記述がないので、使いにくいということもあるかもしれない。
  他にも気になるところはあるが、話が発散しそうなのでここではこのくらいにしておく。

TestLinkとRedmineによるテスト実行管理

 最近数ヶ月の間、新しいプロジェクトでテストケースもテスト管理システムも全くないところから作ることになり、以前のプロジェクトで使っていたExcelに代わる方法を検討した。Excelでもそれなりのことはできていたが、あまりにも自由過ぎて抜けもれがあったり、ミスしたり、といったことがあったので、他の方法をとれないか考えた。

 テスト管理システムで実現したかったことは以下のとおり。 実行管理以外にも、テスト計画やドキュメント管理も含んでいる。タスク管理システムとしては、他に以前のプロジェクトで使っていた影舞や、別プロジェクトで使われていたTracなどもあったが、既に現在のプロジェクトでRedmineを使っていたこともあり、Redmineにしぼって考えた。

 上記のように、TestLinkとRedmineはそれぞれ得意、不得意があり、どうするか迷った。TestLinkで大体のことはできるが、工数管理ができないのはかなり痛い。隠れ機能で工数集計できる、という話もあるようだが、そのために1.8.2を入れる気もしなかった。その他、テストを実行した結果テストケースの修正が必要、といった場合のフィードバックもできないことはないが、Redmineの方が（カスタムフィールドを設けてフラグを立てることで）簡単に運用できそうだった。

 結局両者を併用することにした。当然二重管理になるが、TestLinkはテストケースおよびテスト計画全般の管理、Redmineは個々のビルドに対する実行管理として使い分け、重複する部分を最小限にするよう努めた。（Redmineは実行管理用なので、自動テストはチケットに含めていない。）上記の表で色がついた部分が要求に対してTestLink、Redmineそれぞれの機能を利用したものである。

 何をテストすべきか、仕様変更に伴いどのテストケースを変更すべきかは、TestLinkのキーワードを使って影響範囲を判断することにした。

 「テスト実行時に関連するバグがわかる」ことをRedmineを使って実現しているのは、本来ならTestLinkとRedmineを連携させることでどのテストケースに対してどのようなバグがあるかわかるはずだが、設定がうまくいかなかったので、テスト用のRedmineチケットとバグを関連付けることにしたということ。バグはビルドではなくテストケースと関連付けられていたほうが自然なので、Redmineを使うにしても、TestLinkと連携させたほうがよいと考えている。

 なお、Redmineの使い方は次のようなものである。ビルドごとに前のビルドからのコピーでプロジェクトを作成する。これによってバグとの関連づけやテストケース要修正のフラグが引き継がれる。また、redmine_chartsプラグインを入れて、進捗や工数の予実が見えるようにする。

 この方法でテストを実行してみて、基本的にはうまく回っていたが、いくつか問題点も見えてきた。

• スケジュールの変更に対応しにくい。テストの実行予定日はRedmineで管理していたが、丸一日分ずらすとか、半日分ずらすとかは手作業になる。また、準備ができていないなどの理由で特定の機能がテストできないなどといった場合も対応が困難。テストケース数が少なかったから何とかなったが、期日ではなく優先度を設定するなど、別の対応が必要になりそう。
• 担当者による違いが考慮されない。今回はテスト担当者の対象システムに対する知識に違いはなかったためあまり考慮しなくてよかったが、2回目以降のビルドでは、前のビルドでテストを担当した人とそうでない人で違いが出てくる。人による違いが出てこないようなテストドキュメントを作る、というのが正しいとは思うが。
• テストケースの変更が追いつかない。これは管理システムというより、テストケースの問題。

 今回のテストでは要件管理や一部の集計機能など、TestLinkに備わっていながら使っていないものもあり、あるものをすべて使う必要はないが、機会があれば使ってみたい。