少数の原理を活用する（その３）

概要

本エントリーは前回に続き、『ソフトウェア品質のホンネ』に寄稿した記事の復活です。

前後の原理

“上下の原理”と“左右の原理”を使用することで問題を分析し、とらえることができます。しかし、問題を分析する真の目的は、「現状を改善し問題を解決すること」ですから、解決のための施策を見つけることが必要です。
解決のための施策を探す原理を“前後の原理”と名付けました。

問題の解決策には、
　①　すでに解決策が存在しているケース
　②　まだ解決策が発見されていないケース
　③　解決策がないケース
の3つのケースがあります。以下、順番に確認していきましょう。

・　すでに解決策が存在しているケース

「すでに解決策が存在しているケース」とは、過去（つまり“前”）に、誰かが研究あるいは工夫したことによって解決策がブログや論文や書籍などで公にされているもののことです。
まずは、Googleで検索してみるのがよいでしょう。そして、ヒットしたページが多いときには、たとえば、ソフトウェアテスト関連の情報をググるなら「site:jasst.jp」をつけてJaSSTサイトで絞り込みます。また、論文やプレゼン資料を探すときには「filetype:pdf」をつけることでPDFフォーマットのファイルに絞り込む手もあります。

ところで、検索するためには基礎的な知識が必要です。それがありませんと、Googleに入力する検索ワードが思いつきませんので、一通りの基礎知識は身に着けておいた方が有利です。ソフトウェア工学の教科書的な『実践ソフトウェアエンジニアリング』（プレスマン著）を読むと良いと思います。

ただし、『実践ソフトウェアエンジニアリング』は2005年に出版された本ですので、その後の情報を補強したいところです。そんなときには、技術領域ごとに、BOK（Body of Knowledge＝基礎知識体系）という書籍にまとめられているものがありますので、それを拾い読みして、そこから論文に当たるのが良いでしょう。有名なBOKをリストします。カッコ内は読み方です。

・ 　ソフトウェア工学知識体系： 「SWEBOK」（スウェボック）
・ 　プロジェクト管理知識体系： 「PMBOK」（ピンボック）
・　 ソフトウェア品質知識体系： 「SQuBOK」（スクボック）
・ 　ビジネスアナリシス知識体系： 「BABOK」（バボック）
・ 　要求工学知識体系： 「REBOK」（アールイーボック）

BOKは、知識を体系的に整理し、構造化、可視化したものですから、まずは、分からなくて良いから一通り読んで、ぼんやりとで構わないので全体をつかむことをおすすめします。その後、何か知りたいことが発生したら、これらBOKに記載されている参考文献（規格、書籍、論文等）を読むのがよいでしょう。

なお、BOKの理解を確認し資格認定を行う資格認定試験も各種ありますので、合格することを目指して試験日までに集中して勉強するのもおすすめです。何も目的がないと、なかなか勉強する気にならないですから。
ところで、書籍はどうしてもタイムラグがあります。したがって、最新の論文については、以下のウェブで検索します。

・ CiNii（サイニィ）： 日本の論文検索サイト
・ Google scholar（グーグル・スカラー）：論文専門検索サイト

また、各種学会、セミナー、シンポジウム、勉強会、オンラインのコミュニティ等々に参加して、情報を交換することも非常に有効な手段です。
究極的には、人のつながりを持って「この内容ならこの人に相談すればよい（この人に聞いてもわからないと言われたら諦めよう）」という識者を技術領域ごとに持っていると心強いです。

・　まだ解決策が発見されていないケース

八方手を尽くして探しても既存の解決策が見つからない場合もあります。この場合は未来で（“後”で）解決策が見つかると信じて自分で考えるしかありません。
この時、司馬 正次氏の唱える未知の対象への研究アプローチである「金魚鉢理論」が参考になります。

司馬氏は、

金魚鉢の中で泳いでいる魚のことが知りたかったら、金魚鉢の外から魚についてあれこれと仮説を立ててそれを検証する方法よりも、金魚鉢にドブンと飛び込んで共に泳ぎながら直観を働かせて仮説を創造した上で、金魚鉢を飛び出して、はて金魚とは何か？と考える

という方法を取るようにと勧めています。
これを仮説創造といいますが、『研究には現場での共同活動が欠かせない』ということでしょう。

ところで、新しいことを適用するのを嫌がる現場マネージャがいるのは事実です。そんな時には、そのチームの技術を率いている若く熱意のある人を巻き込み、一緒に活動することが大切です。それから、一人で考えるのではなく社内外の知見者と一緒に考えることも重要です。

・　解決策がないケース

解決策が絶対にあると信じて仮説検証活動を始めたものの、一向に成果が表れない場合もあります。このようなときに、“前後の原理”は使えるのでしょうか。
そのようなときには、仮説が間違っていたことを早く認めるための原理が必要になります。色々と繰り返し仮説検証作業を行ってしまうのは、思いついた仮説を捨てられないからです。実は、“前後の原理”では「解決策がないケース」は解決しません。本ケースについては次回に議論したいと思います。

まとめ

今回は、私が、“前後の原理”と呼んでいるものについて説明しました。

1958年にプリンストン大学教授のJohn Wilder Tukeyが、“Software”という言葉を生み出しました。したがって、ソフトウェアは、まだ半世紀強しか経っていません。
“前”、すなわち過去に学び解決策を得ることが問題解決活動の中心となりますが、現在より“後”の未来に解決策が発明されることを信じて現場に飛び込み全員が一丸となって解決策を模索することも大切なことと思います。