ビジネス場面における“確かめる力”の向上 ～「検証力」養成についての研究ノート～ 学校法人産業能率大学 主任研究員 総合研究所 仁宮 裕 ●論旨 本稿は、ビジネスの場面で発生する不具合やトラブルを未然に防いだり、発生時の影響を限定的な ものとしたりするためのさまざまな取り組みの中から、人（あるいは人間集団）の“確かめる力”の 向上に焦点をあて、その必要性と能力向上の方向性について述べるものである。要点となるのは、仕 事上生み出されるモノやコトに対する検証力を養成するための考察である。特に、“確かめる”ための 仕組みとしての「レビュー」に着目し、その方法論を確認する。 ●はじめに 新聞やニュースで日々報じられる、鉄道や道路の設備の不具合を原因とする事故、銀行システムや 発電所といった社会的なインフラで生じる大きなトラブル。そこまで大きく取り上げられることはな いかもしれないが、我々の身近なところで起こっている商品やサービスの品質に関わる問題。こうし た事象の発生を減らす、あるいは影響を限定的なものにとどめるために、我々はどのようなことがで きるのだろうか。 リスクマネジメントや品質マネジメント、あるいは失敗学の知見から、さまざまな提言や取り組み の可能性が提示されているが、有効と思われるアプローチの一つとして「検証」を的確に行うという 方法が挙げられるだろう。つまり、仕事をしていく中で生み出すモノ（多くは商品と呼ばれる）やコ ト（多くはサービスと呼ばれる）といった成果物（中間成果物を含む）を「不具合なく当初の目論見 どおりの目的を果たすか」という目で（実際の利用に供する前に）確認する、というやり方である。 この「検証」を的確に行う能力を、組織を構成する個人および職場という人間集団が十分に身につけ ることができれば、問題の発生や影響を減らすことが可能であるだろうという想定は、受け容れやす いだろう。要は、「検証力」を養成することが問題の予防策の重要な柱の一つとなる、という考え方を とることができる。 ただ、 「検証」という言葉を辞書で引くと、「実際に調べて証拠だてること」（岩波国語辞典 第七版） という意味説明が出てくる。日々の仕事の場面で恒常的に「証拠だてる」ことまで求められると、気 軽さや手軽さが失われ、日常のビジネスシーンでの実践に躊躇が生まれる懸念もある。そこで、本稿 では「検証力」を、もう少しゆるやかに言い換えた“確かめる力”という言葉をキーコンセプトに据 え、その向上の必要性とアプローチについて論じようと思う。 ＜キーワード＞ 【リスク】 ・目的に対して、不確実性が引き起こす影響（ISO 31000シリーズにおける定義） 【品質】 ・本来備わっている特性の集まりが、要求事項を満たす程度（ISO 9000シリーズにおける定義） 【レビュー】 ・設定された目標を達成するための検討対象の適切性、妥当性、及び有効性を判定するために行われる活動 （ISO 9000シリーズにおける定義） 【ウォークスルー】 ①[演劇]立ちげいこ, リハーサル. ②手順の詳しい説明.（ジーニアス英和辞典 第４版） 1 １．問題意識 2012年12月２日に山梨県大月市笹子町の中央自動車道上り線笹子トンネルで衝撃的な事故が起きた。 いわゆる「笹子トンネル天井板落下事故」である。この事故では、100m以上にわたって１枚あたり重 さ約1.2トンもの天井板が次々と落下し、トンネルを通行していた車両を直撃したことにより、９人の 尊い命が失われた。 笹子トンネルは、トンネル上部に「アンカーボルト」と呼ばれる部材によって天井板を吊っている 構造となっており、これが抜けたことにより天井版の崩落が起こったものと見られている。トンネル を管理する中日本高速道路では、１年に一度の定期点検、５年に一度の詳細点検を実施しており、事 故の直前は2012年９月に詳細点検を実施していたが、このときは異常は特に見当たらなかったという。 しかし事故後の2012年12月13日の検査では、笹子トンネルの下り線に、つり金具のアンカーボルトの 脱落やゆるみ等、670以上の不具合が確認されている。（2012年12月14日付 毎日新聞朝刊 報） 事故の根本的な原因については、アンカーボルトの固定方法（接着剤による固定）の問題、トンネ ル構造自体の問題、メンテナンスの問題等、さまざまな可能性が議論されており、結論は出ていない （2013年１月現在） 。しかし、2012年９月の詳細点検時点で事故後の検査と同程度の緻密さで検査が行 われ、確認された不具合に対する何らかの処置がなされていれば、これほどの事故には至らなかった のではないかと感じる向きは多いだろう。また、仮に事故原因がまったく別のところにあったとして も、2012年９月時点での検査と2012年12月時点での検査の間にこれほどの差異が生じていること自体 が問題だという捉え方も可能である。 筆者はこの事故の報に触れ、日常の仕事場面での“確かめる力”が低下しているが故に起きた悲惨 な事故なのではないかという受け止めをした。そして、“確かめる力”の低下は、実にさまざまな場面 に事故やトラブルとして表出しているのではないかと推定したのである。 トンネルといういわば「ハードウェア」 領域から離れて、「ソフトウェア」領域に目を向けてみよう。 象徴的なのは、2012年６月20日に起きた、いわゆる「ファーストサーバ・データ消失事件」である。 このトラブルは、サーバーホスティングを手がけるファーストサーバ社が運営するレンタルサーバー 上のデータが消失し、約5700に及ぶ顧客が影響を受けたものである。法人顧客の多くは、ビジネスを 進めて行くうえで重要なデータ（自社Webサイト、メール、スケジュール、営業情報、顧客管理情報 など）をファーストサーバ社の提供するサービスに預けており、データ復旧を自らの手で行わなけれ ばならない状態に追い込まれた。預けていた自社データを独自にバックアップしていなかった顧客は、 当該トラブル以前に蓄積していたデータを諦めるか、手間をかけて再構築せざるを得なかったようで ある。 この出来事は前述の「笹子トンネル天井板落下事故」ほどにはセンセーショナルに報じられること はなかった。しかし、「クラウドに置いたデータが消失してしまう可能性は、ゼロではないとしても無 視して良い程度に低いだろう」という、それまでの一般的な感覚を崩壊させ、「クラウド系サービスの 危うさ」を考えるうえで、大きな転換点となる事故であったと言える。 データ消失の直接の原因は、運用担当の技術者がサーバーOSの脆弱性を修正する保守用のパッチ・ プログラムを適用する際、プログラムに「パッチ不要のサーバーは、ユーザーファイル等を一括削除」 という、本来一緒に実行してはいけない処理のコマンドを入れてしまったというものである。しかも この「誤ったパッチ・プログラム」を運用系のサーバーのみならず、バックアップ系のサーバーにも 同様に適用してしまった。これにより、通常、こうしたトラブル時に対応策として採用されるはずの 「バックアップからの復元」という手段もとることができず、サービスを提供するファーストサーバ 社としては、独力によるデータ復旧を断念せざるを得なかった（顧客自身にデータ復旧を依頼せざる を得なかった）。 この事故も、実際にパッチ・プログラムを適用する前に、 「意図どおりの結果が得られるプログラム に本当になっているか」 、「保守・運用の作業としてまっとうな手順であるか」という目で慎重に“確 かめる”作業を行っていれば、未然に防げたのではないかという思いを禁じえない。 これ以外にも、ここ数年の間に“確かめる力”が個人／組織にきちんと備わっていれば防げたので はないかと思える事故やトラブルが、いくつも起こっている（図表－１） 。 2 ビジネス場面における“確かめる力”の向上 図表－１ 印象的な事故・トラブル ＪＲ東日本の架線トラブル 2010年３月 ＪＲ目白駅付近の架線トラブルで、一時4700人が車両に閉じ込められる等、全 体で約26万人の帰宅の足に影響が出た。 原因は、同駅の周囲に通信ケーブルを設置する際、屋外用の留め具で固定すべ きところ、誤って屋内用の樹脂製の留め具で固定していたことに気づかないま ま、営業運転を行っていたことにある。 みずほ銀行システムトラブル 2011年３月 特定口座への振り込み集中をきっかけとして預金の引き出しや送金が一時不能 となり、数日間にわたってATMの利用停止や企業の給与振り込み遅延が生じる 等、大きな影響が出た。 直接の原因は、「義援金口座に関する処理上限の設定ミス」である。 福島第一原発のセシウム吸着装置のバルブ開閉ミス 2011年６月 福島第一原発で高濃度の放射能汚染水を浄化するシステムの効果が見込みより 少なくなっていた問題。放射性セシウムを吸着する装置の一部がバルブの開閉 状態の誤りにより稼働せず、本来の浄化能力の二十分の一の効果しか上げてい なかった。 原因は、 「開」と「閉」の表記が逆になった状態で配管が設置されていたことに 気づかず、浄化システムを稼動させてしまったことによる。 ビジネスの現場では、これに類似したような出来事が散見される。新聞やニュースで取り上げられ ることはないものの、「納品前にもっときちんと確認しておけば、こんなことにはならなかったのに」 であるとか、 「運用開始前にサービス内容をもっと吟味しておけば、お客様に迷惑をかけることはなか ったのに」といった話はよく聞く。民間企業だけでなく、行政体であっても事情はそう変わらないだ ろう。 およそ営利か非営利かにかかわらず、仕事の質を高め、顧客（利用者／住民）満足を得ようとする すべての組織は、その組織に属する個人や人間集団の“確かめる力”を養うことなしに安定的な業務 の運営を継続することは困難ではないか。本稿は、こうした問題意識から出発するものである。 3 ２．“確かめる力”の位置づけと意味 (1)対象とする領域 事故やトラブルを防いだり、生じた際の影響を少なくしたりということに関しては、リスクマネジ メントの知見が非常に役立つ。そこで、まずはリスクマネジメントの全体像の中で、ここまで“確か める力”と呼んできたものが、どのような領域をカバーするものであるのかを見ていこう。 ここでは、参照する枠組みとして、ISO31000シリーズを採用することにする。図表－２は、 ISO31000「4 枠組み『4.1 一般』」の記述に基づいて、リスクマネジメントの構成要素とその関連性 を示したものである（なお、内部統制システムとの一体運営と、それに対するインターフェース部分 に関する記述は省略して図解化してある）。 この図に照らしていえば、 “確かめる力”の向上とは「リスクマネジメントの実践」部分の強化に相 当する。もちろん、 “確かめる力”を向上させることにより、組織全体のリスクマネジメントがより効 果的に行われるようになり、成熟度が増す、という期待もできるのだが、ここでは、個々の仕事の成 果の品質を一定以上に保ったり、事故やトラブルやクレームに繋がらないようにしたりする活動領域 に限定して論を進めたい。 つまり、対象とする相手は、仕事に携わるすべての組織構成員であり、その個人として、（職場とい う）人間集団としての“確かめる力”の向上が、組織活動にプラスの影響を与える要因として重要な 位置を占める、という立場をとる。リスクマネジメントのための仕組み全体を設計したり、レビュー して改善したりといった活動が、どちらかというと上位方針を受けてマネジメント担当が行うトップ ダウンの方向性を持つものだとすれば、 “確かめる力”の向上はボトムアップの方向性を持つと言える だろう。 図表－２ リスクマネジメントの構成要素とその関連 指令とコミットメント リスクマネジメントフレームワークの設計 フレームワークの継続的改善 リスクマネジメントの実践 フレームワークのモニタリングレビュー では、リスクマネジメントの実践の中で、さらに詳細に見ると“確かめる力”はどのような領域を カバーするものと言えるだろうか。 リスクとは、 「目的に対して、不確実性が引き起こす影響」であるから、本来は悪影響を引き起こす 不確実性と好影響を引き起こす不確実性の両方を含む。しかし、出発点としての問題意識に照らして、 ここでは悪影響を引き起こす不確実性のほうだけに焦点をあてることにする。特に日本では、一般的 にリスクといえばネガティブなほうをイメージすることが自然なように思われるし、米国でもネガテ ィブな方をリスク、ポジティブなほうをオポチュニティと区別して呼ぶこともあるようだ。 悪影響を引き起こす不確実性への対応戦略としてよく知られたものに、図表－３に挙げられる４つ の選択肢がある。 図表－３ リスクへの対応戦略 回避 活動中止や活動制限等により、リスクそのものを避ける 転嫁 リスク発現時の損失を保険でまかなう等、第三者に転嫁する 軽減 リスク源の除去や、発生頻度や影響度の低減を図る 受容 リスク発現時の損失を認識したうえで受け容れる 4 ビジネス場面における“確かめる力”の向上 この４つの選択肢の中では、 “確かめる力”は「軽減」戦略の有効性を高める要因として働くと言え る。特に、成果物等を実際の利用に供する前に“確かめる”ことにより、発生頻度を低減することに 大きく資すると考えられる。もちろん、実際の利用が始まった後も（トンネルのような経年劣化が危 惧される構造物を含む場合は特に）、適切な機会を設定して“確かめ”続けることにより、発生の抑制 が期待できると言えるだろう。 ここまでをまとめると、リスクマネジメントの枠組みの中では、「リスクマネジメントの実践」場面 における「リスク軽減」が焦点をあてるべき領域、ということになろう。 (2)“確かめる力”の意味 リスクを「目的に対して、不確実性が引き起こす影響」と捉えたとき、「影響」とは何を指すのだろ うか。少し補足するならば、それは「期待されていることから好ましくない方向へ乖離が生じている こと」を指していると考えられる。 ここでISO31000シリーズ以外の知見に目を向けてみると、失敗学における「失敗」の定義が近似 のものとして想起される。失敗学の提唱者である畑村氏は、著書の中で失敗を「人間が関わって行う ひとつの行為が、はじめに定めた目的を達成できないこと」と説明している。この定義に従えば、 「人 間が関わるリスクの発生」ニアリーイコール「失敗」という解釈が可能だろう。天災によるリスク等 に行きあたることもまれにあるだろうが、日々の仕事の中では「人間が関わって行う行為」にまつわ るあれこれが不具合を生じさせている場合が圧倒的に多い。つまり、失敗を減らすことによって、リ スクの多くの部分をカバーできる可能性が高い。日常の仕事の中で犯してしまう失敗、これを減らす ための取り組みの一つが“確かめる”行為だ。 ただ、ここで注意したいのは、前述の「ボトムアップの方向性」という点である。畑村氏は、失敗 原因の階層性を図表－４のように示しているが、“確かめる力”はこの図の下から２番目までに関わる 要素とみなす。 図表－４ 失敗原因の階層性 未知への遭遇 社会システム不適合 社会性 組織怠慢・政治判断 行政・政治の怠慢 個人性 企業経営不良 組織構造不良・企画不良・経営不良 組織運営不良 運営不良 無知・不注意・不順守・誤判断・検討不足 個々人に責任のある失敗 （出典 「失敗学のすすめ」） 個人の“確かめる力”が向上すれば「個々人に責任のある失敗」が減り、職場（という組織）にお ける人間集団の“確かめる力”が向上すれば「組織運営不良」による失敗が減る、という仮説を立て たい。 「企業経営不良」から上の層は、リスクマネジメントのフレームワーク全体の改善と同様、（ト ップ・マネジメント側で取り組むべき）別次元の課題として本稿の対象外とする。 “確かめる力”を論じるうえで、もう一つ欠かせないキーワードがある。それは「品質」である。 リスクの定義でも失敗の定義でも、「目的に対して」 、 「はじめに定めた目的を」といったように、合目 的性に触れる記述が含まれている。目的は経済性であったり、安全衛生であったり、実にさまざまな 視点から設定されうるし、またその設定のレベルもさまざまだろう。しかしながら、ビジネスの現場 で設定される目的といえば、品質という視点から設定されるものが重要な位置を占めることは言をま たないだろう。 5 多くのビジネスパーソンは、日々の職場活動において「顧客に一定レベル以上の品質を備えた商品 ／サービスを提供したい（しなければならない）」という思いを持って仕事をしているはずである。当 初の目論見どおりの品質を持った商品／サービスが提供できず、クレームを受けたり売上が落ちたり すれば、それは品質に関わる「リスクが発生」したということであり、「失敗」をしてしまったという ことになる。社会に大きなインパクトを与える事故やトラブルが生じなくとも、個々のビジネスパー ソンや職場集団にとっては、深刻な事態であり、かつ遭遇する可能性が高い事態だとも言える。 品質を一定以上に保つために、人は、テストをしたり、読み合わせをしたり、検査をしたり、とい った“確かめる”作業を行う。理論的な背景はなくとも、それが品質の向上や維持に有効だというこ とを（なんとなくであっても）分かっているからである。そうした確認行為を通じて、リスクや失敗 を効果的に減らすことができる能力を、 “確かめる力”と捉えたい。 多少、我田引水気味に捉え直してみると、先に紹介した「笹子トンネル天井板落下事故」や「ＪＲ 東日本の架線トラブル」は、公共交通のインフラの品質が維持できなかったために生じたものと解釈 可能だし、「ファーストサーバ・データ消失事件」や「みずほ銀行システムトラブル」は、企業が提供 しているサービスの品質が（大規模に、かつ劇的な形で）低下したものと解釈可能である。事後的に 振り返れば、 “確かめる”行為の的確な実施によってこのような品質劣化は防げたのではないかという 考え方もできる。 ここまで述べてきたことをまとめて、いわゆる5W1Hの視点から“確かめる力”を整理すると、図 表－５のようになる。 図表－５ “確かめる力”とは Who 組織を構成する個人、もしくは人間集団 Why リスクの発生を予防したり、失敗を軽減したりするため What 商品／サービスの（主に品質）維持／向上 When 実際の利用に供する前、もしくは利用中の特定の機会をとらえて Where 仕事の場（職場）において How さまざまな種類の確認行為を通じて発揮 6 ビジネス場面における“確かめる力”の向上 ３．向上のためのアプローチ (1)確認する行為としての「レビュー」への着目 前段で、本稿における“確かめる力”がどのようなものであるかのイメージを形成できたと思う。 では、その能力を向上するには、どうすればよいのか。“確かめる力”を要素分解し、それぞれを強化 するというアプローチを考えた。 人の能力を捉える場合、「知識・技能・態度」の三要素で考えることが多い。ここでもその枠組みを 採用し、以下のように“確かめる力”を三本立てで捉えることにする。 a. よりよく“確かめる”ための有効な手法／技法を理解している（知識） b. その手法／技法を活用することができる（技能） c. “確かめる”ことの有用性を信じ、実際の仕事場面で実践しようとする（態度） 効果的に“確かめる”ためには、それなりの整理されたやり方というものがあるはずである。まず はそれを知っていなければならない。そして、そのやり方で確認行為ができなければならない。また、 「知っているし、やろうと思えばできるが、やろうとはしない」のでは、実務上の“確かめる力”が あるとは言えないから、「やろうとする（心の）姿勢」も欠かすことができない。 これら三つの要素を強化することで、実務上の“確かめる力”を向上させることができるだろう。 そこで、注目したいのが、 “確かめる”ための手法／技法としての「レビュー」である。レビュー （review）とは、語源的には「再び（re-）よく見る（view）」、つまり「見直し」という意味を含んだ 言葉であり、冒頭でも示した通りISO9000シリーズでも定義つきで使用されている言葉である。設備 等の「点検」も含むことができるだろうし、システムエンジニアリングの場においては、工程ごとに 行う「検討・評価」や「再検査」のことを指す。 レビューの形態にはさまざまなものがあるが、ここではソフトウェア工学における知見を援用する ことにしよう。 Karl E.Wiegersは、レビューの中でも特に「ピアレビュー（peer review）」の有効性を主張し、「Peer Reviews in Software」を著した。ピア（peer）には、「同僚」であるとか「同じ専門分野の人」とい う意味があり、ピアレビューは「同領域に携わる他者の目の入った検討・評価」というほどの意味を 持つ。Wiegersは、著書の中でピアレビューの種類を以下のように分類し、適切な使い分けを薦めて いる。 （図表－６） 図表－６ Karl E.Wiegerによるピアレビューの分類 種類 概要 a インスペクション 最も体系的で厳格な種類のピアレビュー。「計画」「概要説明」「準 備」 「ミーティング」「修整」「フォローアップ」「原因分析」といっ た活動を含む。 b チームレビュー 計画され、構造化されているが、インスペクションほど公式ではな い。一種の「軽インスペクション」と考えればよい。 c ウォークスルー 非公式のピアレビューであり、作成者が作業成果物をグループの同 僚たちに逐次説明し、コメントを求めるという形態をとる。 d ペアプログラミング ２人の開発者が1台のコンピュータを共有し、１つのプログラムを 一緒に作成する。これにより、継続的で漸進的で非公式なレビュー が可能となる。 e パスアラウンド 多重かつ同時進行のピアデスクチェック。作業成果物のコピーを何 人かに配布し、コメントをもらう。返ってきた複数のフィードバッ クを照合して改善に役立てる。 f アドホックレビュー 最も非公式のレビュー。同僚に「ちょっと手伝ってくれ」という調 子で作業成果物に対する意見を求めるような行為を指す。 これを見ると、ａからｆにかけて公式度（や規律）の程度が下がり、柔軟性の程度が上がっている のが分かる。公式度の高いものほど手間も時間もかかり、レビューに参加するメンバーの負担が大き い。逆に公式度の低いものほど負担は軽いが、いわゆるバグ（ソフトウェアの不具合）が見逃される 可能性が大きくなる。 7 “確かめる力”向上のためには、こうしたさまざまなレビューの方法論を知ったうえで、適切な場 面で適切に実践できるようにしていく必要がある。また、前述の「態度」の面から述べるならば「成 果物をユーザーに提供する前に不具合を見つけるにはピアレビューが有効だ」と信じ、積極的にレビ ューを行おうとする心性を獲得することも重要であろう。 システムエンジニアリングの場では、誤りの発見が後工程になればなるほど、修正の手間が増すこ とが知られている。そのため、こうしたピアレビューを行うことで、できるだけ“川上”で誤りを発 見する試みが体系的になされ、最終成果物の品質維持／向上に効果を上げてきた。 以上、ソフトウェア領域における知見を引きながらピアレビューの概要を紹介したが、これをソフ トウェア以外の領域にも適用することは可能だろうか。実は、Wiegers自身が著書の中で以下のよう に述べている。 『本書で説明している技法は、ソフトウェアプロジェクトで作成される成果物や文書に限定されま せん。実際それらを設計仕様、回路図、組み立て説明書、ユーザーマニュアルなど、どんなエンジニ アリングプロジェクトの技術的作業成果物にも応用できます。文書化されたタスク手順あるいは品質 管理プロセスを持った業務ならば、作成者ひとりだけでは見つけられなかった誤りも、ピアレビュー を慎重に行えば見つかるものである、ということを認識するでしょう。』 つまり、先ほどの問い（ソフトウェア以外の領域にも適用可能か？）に対する答えはイエスである。 もちろん、 「ペアプログラミング」等、一部システムエンジニアリングに特有の技法は適用困難な場合 もあると思われるが、大半の部分はソフトウェア領域以外にも適用可能だ。 本稿では紙面の都合上、先に紹介したすべての技法を取り上げることはできない。そこで、ペアプ ログラミング以外の技法の中から、「ウォークスルー」に絞って論を進めていくことにする。ウォーク スルーは、筆者がシステムエンジニアリングの仕事に関わっていた時期に、その有用性を直接的に実 感した経験があり、ここで取り上げるに相応しい技法であると考える。また、ウォークスルーは Wiegersの分類でいうとペアプログラミングを除く５つの技法の中で公式度の程度がちょうど中間に 位置するので、その他の技法と対比して語るのに都合が良いという事情にもよる。 (2)「ウォークスルー」の方法と有用性 ウォークスルー（walkthrough）は、あまり一般に知られた言葉ではないように思われるので、少し 補足しておく。この用語は、もともとは演劇における立ち稽古を指すものである。実際に舞台にかけ る（観客を会場に入れて公演する）前の稽古段階で、台本片手に役者同士が一通りの演劇の流れを確 認しながらセリフを発したり、動いてみたりすることをいう。 コンピュータシステムのエンジニアリングにおいては、プログラムのソースコード、つまり実行形 式のファイルに変換される前の（プログラム言語で記述された人の目で読める形の）元のファイルを 一行一行追いかけながら、どのように処理が行われるかを（主に机上で）確認する作業のことを指す ことが多い。もちろん、レビューの対象となる成果物は必ずしもプログラム・ソースコードでなくて もよいのだが、レビュー技法としての威力が最もよく発揮される場合の一つがソースコード対象のウ ォークスルーなのではないかと考えている。 ウォークスルーは、インスペクションやチームレビューのようにあらかじめスケジュールが決まっ ているわけではなく、対象となる成果物の作成者自身がチーム・メンバーに声をかけて自主的に運営 する。発起人である作成者（レビューイ)は参加者（レビューア）にコード（あるいはその他の作業成 果物）を提示し、全体の中でのレビュー対象成果物の位置づけや外部とのインターフェースがどうな っており、どのように処理を行うか、ロジックの流れや入出力の仕方を説明する。レビューアは、そ の説明を聞きながらコードの一行一行を追いかけ、本来の目的どおりに機能しないと思われる箇所を 見つけたら指摘をし、レビューイを含む参加者全員でその不具合を確認・共有する。 ウォークスルーは、定義された構造的な手順があるわけでもなく、終了基準も厳格に決められてい るわけでもなく、また正式な管理レポートも作成されない。しかしながら、この技法の適用によって、 驚くほど多くの誤りが発見されソフトウェア品質の向上に寄与し得るのである。実際、筆者もたった 百数十行程度しかない小規模なプログラム・ソースコードの中に、ウォークスルーを通して30を超え 8 ビジネス場面における“確かめる力”の向上 る不具合が指摘される場面に居合わせたことがある。しかも、この時のレビュー対象は、作成者が「単 体テスト完了」と宣言したプログラムであった。 ここでシステム構築のプロセスに明るくない読者のために補足しておくと、「単体テスト」とは、実 行形式のプログラムを実際に動かして行うテストのうち、個別のプログラムに閉じた処理を確認する ためのものを指す（なお、互いに関連する一連のプログラムを繋げて行うテストを「結合テスト」 、シ ステム全体を統合して行うテストを「システムテスト」という）。 つまり、プログラムを実際に動かしてさまざまな条件で動作確認した結果にもとづいて作成者が「プ ログラム単体レベルではこれで十分に目的どおりの機能を果たすことが確認できた」と考えたプログ ラムを対象としてウォークスルーを実施したところ、驚くほど多数の不具合が発見できたということ である。実際、作成者が一人で実際に動かしてみるよりも、動かさずに（机上で）他者の目を入れて コードの読み合わせをしたほうが、時としてはるかに効率的に不具合の除去を行うことができる。「テ スト」は「レビュー」と並ぶ“確かめる”ための重要な行為であるが、テスト偏重になってしまうと 思わぬ陥穽にはまり込む。 コンピュータシステムがビジネスシーンに活用されはじめた初期の頃、コンピュータに何らかの処 理を実行させるというのは非常に貴重な資源を使うことであった。プログラムのコンパイル（ソース コードを、コンピュータが解釈できる機械語としてのオブジェクトコードに変換すること）や、実行 可能形式となったプログラムを動かしてのテストというのは、気軽にできる行為ではなかった。それ ゆえに、ソースコードを対象として人間の目で検証することが品質管理活動の中で大きな比重を占め ていた。 だが、時代が進むにつれてコンピュータは劇的に高性能化・低価格化し、システム構築に携わる者 は、気軽にテストできるようになった。それにつれてウォークスルーに代表されるような一見手間の かかる確認手段が軽視される雰囲気も一部に出てきたように思う。ともすると、 「ソースコードを確認 するなんて面倒なことをする前に、ともかくプログラムを動かして思ったとおりに動作するかどうか 確認すればよいのでは？」という考えに傾きがちになる。 しかし、テストとレビューは互い補完し合うものであり、どちらか一方だけというのではバランス を欠くし、重大な誤りを見逃すことにも繋がりかねない。先に紹介した「ファーストサーバ・データ 消失事件」においても、事前にパッチ・プログラムをテスト環境で動かして確認を取っているのだが、 それでも不適切な処理が混入したままであることを見過ごし、運用環境およびバックアップ環境に適 用してしまったことが後に判明している。 “確かめる力”の不足に悩む組織があるならば、こうした要素から手をつける必要があるかもしれ ない。つまり、「知識・技能・態度」でいうならば、 「態度」要素に関わる側面である。たとえ一見遠 回りのように思えても、手間が余計にかかるように見えても、「自らが生み出す成果物の品質を上げる ために、できるだけ有効な確認手段を選択しよう」という信念と、実際にそれを実践しようとする意 志を育むことが重要である。“確かめる力”の向上／発揮には、ビジネスパーソンとしてのモラル（倫 理）とモラール（士気）が問われると言い換えてもよいだろう。 (3)レビュー技法の習得 ここからは、 「知識・技能・態度」の三要素に分けて、その習得上のポイントを述べていくことにする。 ①知識 まずは、組織内で行われているレビュー、あるいはそれに準じた確認行為を洗い出し、そのプロセ スの洗練化をねらうのが定石だろう。洗練化にあたっては、過去の研究成果なり、専門家の意見なり を参考にするとよい。そして、それを形式知化し、組織の構成員が等しく共有できるようにしておく。 特に経験の浅いメンバーや技術の未熟なメンバーに対しては、初期段階での手法・技法についての 集中的な知識付与が高い学習効果を上げる。ウォークスルーには定義された構造的な手順はない、と 述べたが、ガイドライン的な推奨手順を組織として策定し、まずはそれを身につけるという方法も便 宜的には有効だと思われる。 9 ②技能 レビューの技術を身につけるには、オブザーバーとしてでも構わないので、レビューの場に参加す ることが重要である。最初のうちはレビュー対象物に対して何のコメントも発することができないか もしれないが、注意深く他の参加者の言動を観察していれば、徐々にコツや勘所が見えてくる。 例えば、プログラムのソースコードを対象とするウォークスルーでは、外部プログラムとのやり取 りやデータベースとの入出力、複数の処理のどちらを実行するかの条件境界、といった何らかの“境 い目”に関する処理の周辺で誤りが発見されることが多いが、こうした着眼点を本当の意味で自分の ものにするには、実際に参加してみるしかない。 「この項目はデータベースの項目定義では小数点つき の10桁となっているのに、プログラム側では整数定義の変数で受け取っているね」といった熟練者た ちの指摘を聞きながら、誤りを発見する“嗅覚”を磨いていくのである。 ピアレビューの「ピア」には「同僚」の意味があると述べたが、参加者の技能を磨くという面から は、ベテランの参加が欠かせないという結論が導き出せる。この場合は「ピア」の意味として、「同じ 専門分野の人」（の中でも特にその分野に精通した人材）のほうを採用すべきということになる。 ウォークスルーのようなピアレビューにおけるミーティングは、欠陥検出や製品改善という目的の 他に、参加者育成の目的を持つことを忘れてはならない。 ③態度 レビューに熱心に取り組もうとする態度は、その効果を実感するところに源泉を求めるべきだろう。 他者から各種レビュー技法の有効性をいくら言い立てられても、本人が「手間の割りには効果が低い のではないか」という懸念を持っていたのでは、望ましい取り組み姿勢には繋がらない。 先に挙げたような、 「テストでは見つからなかった不具合が次々にウォークスルーの場で指摘され る」という経験を通じて、レビューの有効性に対する信念を内面化することができる。また、レビュ ーの目的とは最終成果物の品質維持／向上であり、作成者のミスをあげつらうことがレビューではな いことを実感できたときに、望ましい態度が醸成されるだろう。 ４．結語 本稿においては、“確かめる力”の必要性と意味、その向上のアプローチについて考察した。また、 “確かめる力”を向上させるために習得すべき技法として、レビュー技法の中でも特にピアレビュー としての「ウォークスルー」を取り上げて論じた。 今後の展開としては、ソフトウェア領域以外の領域へのピアレビュー適用時における課題について 掘り下げていきたい。また、各種のレビュー技法が、どのような業務でより有効性を発揮するのかと いった視点から、望ましい適用場面についての考察が必要だろう。加えて、“確かめる力”の向上に寄 与する個別具体的な学習方法／教授方法についても研究をすすめていきたい。 ＜参考文献＞ 1) 日本工業標準調査会「JISQ9000 品質マネジメントシステム－基本及び用語」 2) 日本工業標準調査会「JISQ9001 品質マネジメントシステム－要求事項」 3) 日本工業標準調査会「JISQ31000 リスクマネジメント－原則及び指針」 4) 日本工業標準調査会「JISQ31010 リスクマネジメント－リスクアセスメント技法」 5) ファーストサーバ株式会社 第三者調査委員会 「調査報告書（最終報告書）〈要約版〉」(2012) 6) 内田知男 7) 畑村洋太郎 著「リスクマネジメントの実務」 中央経済社(2011) 著「失敗学のすすめ」講談社(2000) 8) Karl E.Wiegers : Peer Reviews in Software - A Practical Guide 大久保雅一 監訳「ピアレビュー - 高品質ソフトウェア開発のために」 日経BPソフトプレス(2004) The SANNO Institute of Management Y.Nimiya 10
© Copyright 2024 Paperzz
