Comments
Description
Transcript
PDF形式 - スプレッドシート統制 研究室
スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ スプレッドシート統制 スプレッドシート統制 研究室 「Excel に関する内部統制は、どうすればよいのか？」 スプレッドシート統制の要件、統制・評価の手法、 IT統制の手段、事例等を研究しましょう。 はじめに このシリーズは、エンドユーザコンピューティングに関する研究、特に、スプレッドシートの抱えるリスクと対策に 関する研究の第一人者であるハワイ大学Panko博士による最新論文の紹介です。 この論文の原題は、"A Framework for Controlling Spreadsheets for Regulatory Compliance and Good Practice"です。2007年の1月付けで公開されています。この論文は、まだ、ワーキングペーパーということで、粗 削りなところもありますが、専門家の深い知見に基く、幅広い議論は他に例を見ないものなので、参考文献とし てご紹介する次第です。 博士は、エラー及びその検出、開発プロセスを中心として、長年にわたりスプレッドシートを研究対象としていま す。近年は、研究範囲を、SOX法や21 CFR Part 11等の法令の順守を目的とするスプレッドシート統制に拡大し て、論文を発表しています。この研究分野の焦点と推移に留意の上、この論文を一読されることをお奨めしま す。 尚、この翻訳は、「スプレッドシート統制 研究室」(http://linkfinder.cocolog-nifty.com/)の管理人、通称 "linkfinder"によるものです。翻訳及び「スプレッドシート統制 研究室」での公開については、Panko博士の許諾 を受けています。翻訳の正確性及び信頼性に関する問題は、全て当該管理人の責任です。翻訳に関する問題 にお気付きの方は、「スプレッドシート統制 研究室」の掲示板または管理人宛てメールをご利用の上、当該管理 人にご連絡下さい。 1 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ Draft for Comments 2007年1月 COGS ワーキングペーパー 2007-1 法令順守及び適正実施の為に スプレッドシートを統制する為のフレームワーク Raymond R. Panko博士 IT管理学科 教授 経営管理学部 ハワイ大学 2404 マイリウェイ ホノルル、ハワイ州 96822 (808) 956-5049 [email protected] 筆者について 筆者について Ray Pankoは、ハワイ大学シドラー経営管理学部のIT管理学科の教授である。彼は、エンドユーザコンピュー ティングに関する最初のビジネススクール用のテキストを著した[Panko, 1988]。 1993年以来、彼の研究は、主 に、スプレッドシートのセキュリティ、エラー及び統制を中心とする。彼は、スプレッドシート研究のサイト(http: //panko.cba.hawaii.edu/ssr)を管理している。 要旨 産業界での研究は、企業が、スプレッドシートを、重大な業務で、広範に利用していることを示している。本稿で は、コンプライアンス法規の対象とすべき、或いは、単に、適正基準を実施したい業務で用いられるスプレッド シートに対して、企業が、適用すべき統制に関する議論の為にフレームワークを提供する。 キーワード 監査、コンプライアンス、統制、エラー、不正行為、適正実施、エンドユーザコンピューティング、ヒューマンエ ラー、検査、サーベンス-オックスリー法、スプレッドシート、レビュー、テスト 組織統制及びセキュリティセンター シドラー経営管理学部 2404 マイリウェイ ホノルル, ハワイ州 96822 (808) 956-5049 [email protected] 2 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ イントロダクション サーベンス-オックスリー サーベンス オックスリー 今世紀の初頭に、Enronその他の巨大企業に於ける大規模な不正行為が、米国上院による2002年サーベンスオックスリー法の立法を推進した。この法律によって、企業財務報告の規制に於いて、元々の1934年証券取引 法以来の最大の変化が生じた。米国の上場企業の全て、及び米国の証券市場に上場する外国企業の全てが、 サーベンス-オックスリー(SOX)によって、大きな負担を強いられた。これらの企業は、SOXによって、財務報告シ ステムを根本的に見直すことが必要となり、多くの場合、広範な変更を行うことになった。サーベンス-オックス リーは、衆目を集めたが、州、国の機関及び国際的な機関により次々と作成される企業統治法規の一つに過ぎ ない。 サーベンス-オックスリーが扱うのは、財務報告の効果的な統制だ。各企業は、その財務報告書の中で、報告期 間中、財務報告システムが効果的に統制されていたかを報告しなければならない。この報告書は、企業の上級 経営者によって署名され、企業内の独立した監査部門及び独立した外部監査人に評価されなければならない。 虚偽報告は、実刑に繋がるが、有効な統制の欠落を報告するだけでも、重大な結果を招く。より恐ろしいことに は、サーベンス-オックスリー報告の初年度に、有効な統制を報告できなかった企業は、その株価が4%低下した [Durfee, 2005]。これらの企業の最高財務責任者の60%以上が、望ましくない報告の3ヶ月以内に離職している [Durfee, 2005]。 企業は、たった一つの重要な統制不備(管理人注:内部統制の「重要な欠陥」の意味。)があるだけで、財務報告 システムが有効に統制されていると報告できない。重要な不備(管理人注:「重要な欠陥」の意味。)は、「年度ま たは中間期の財務報告に於いて、重要な虚偽記載が予防または発見されない蓋然性の実現に帰結し得る重大 な不備、或いは重大な不備の組み合わせ」により構成される[PCAOB, 2004]。言い換えると、現実に起きたエ ラーだけではなく、重要なエラーの無視できない単なる可能性が問われているのだ。さらに、報告エラーが、最 終的な利益額の僅か5%以上だと、重要なエラーになる[Vorhies, 2005]。サーベンス-オックスリーは、不完全で あることを許容しないのである。 スプレッドシートと スプレッドシートとサーベンス-オックスリー サーベンス オックスリー サーベンス-オックスリーの課題の大きさが明らかになるにつれ、幾つかのコンサルティング会社は、企業が、実 際にはどうやって財務報告をしてるのかを調査した[www.coda.com; RevenueRecognition.com; Durfee, 2004; www.thehacketgroup.com; TMCnet.com, 2004] 。結果は、専らスプレッドシートであった。しばしば、 200、若しくはそれ以上が複雑に連携するスプレッドシート、それらは、何千もの個別の(コピーされた式ではな い)式を備えていた。ハイペリオンの様な財務報告用ソフトウェアを使っている企業でさえ、期末調整等の最もリ スクの高い計算にスプレッドシートを使う傾向があった[Debreceny, 2005]。 2005年5月22日に、デロイトの為に行ったウェブキャストで、筆者は、スプレッドシートの重要性を再確認し、重要 な計算でのスプレッドシートの利用に光を当てることができた。彼は(管理人注：筆者を指す。)、観客に関する一 連の質問をした。それに対する平均回答者数(管理人注:出入りの自由なウェブキャストであるための変動が あったと推定されます。)は、会計専門家及び企業の役員、800人余りであった。「あなたの会社は、重要な(管理 人注：原文は、"of material importance")スプレッドシートを財務報告で使っていますか？」との質問に、回答 者の内、7.1%が、「いいえ」と答えたが、87.7%が肯定した。(他の5.2%は、「該当せず」を選択した。) 重要なスプレッドシートに大きく依存していることは、IT部員の多くを驚かせたが、業務現場でスプレッドシートが 著しく利用されているのは、財務報告以外にも、ヘッジファンド管理、販売奨励管理、及び企業の知的財産権管 理等の分野でも見受けられる。1990年に、Comshare社が会計及び予算管理の専門家700人を調査した際に、 3 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ 既に、スプレッドシートが、企業の予算管理を支配していると報告された[Modern Office Technology, 1994]。 一般に、かなりの率のスプレッドシートが、企業にとって極めて重要なものだという調査結果が、以前から示され ていた[Chan & Storey, 1996; Gable, et al., 1991; Hall, 1996] 。 広範なスプレッドシート利用には、スプレッドシートは、企業ITの暗黒物質なのかもしれないと思わせるものがあ る。物理学に於ける暗黒物質が、目に見える物質よりも遥かに大きいのと同様に、企業のビジネスロジックの構 成単位をどう計測するにしても、スプレッドシートは、その殆どを抱えているかもしれない。 スプレッドシートは、他の意味でも、企業ITの暗黒物質かもしれない。それは、IT部及び企業経営者には、目に 見えないものだ。IT部は、「スプレッドシート? あぁ、それは、業務現場の問題だよ(管理人注：情報システム部門 は、システム開発ではないので、担当業務外と主張するという意味。)。」と言う傾向がある。一方、経営トップ は、スプレッドシートが、彼らがしっかり管理している他の資産よりも、ずっと大きな企業資産であり、自社に対す る顕著なリスクだと気付いていない。 フレームワークの フレームワークの必要 コンプライアンスが、ますます重要となり、スプレッドシートがコンプライアンスに重大なものだとの認識が広がる 中で、企業は、スプレッドシートが直面する脅威、及びそれを合理的な程度に減じる為に必要な統制を理解する 為のフレームワークを必要としている。 このフレームワークは、コンプライアンス要件に左右されるかに拘らず、デリケートなスプレッドシートの為の適 正実施(管理人注:原文は"good practice")フレームワークとも捉えることができる。コンプライアンス要件を、一 般的な企業統治を理解する方法とする企業は、そうではない企業よりも、成功に近い位置にいる(管理人注： "generally"は、意味が不明確につき訳出せず)。 リスク 統制の枠組みは、スプレッドシートのリスクに関する知識の確かな基盤の上に構築しなければならない。この節 では、スプレッドシートに対するリスクの3分類について吟味する。図1に、このスプレッドシートリスクのトライアン グルを示す。 図1:スプレッドシートに関するリスクのトライアングル スプレッドシートに エラー スプレッドシートに関する脅威 する脅威Ⅰ 脅威Ⅰ類:エラー 財務報告に於けるスプレッドシートの広範な使用について警告されて、企業は、スプレッドシート開発に関する 4 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ 文献を読み出した。読むにつれ、心配になってきた。さらに重要なことに、スプレッドシートのエラーに関する研 究[Panko, 2007b]は、研究室での実験及び実務で、業務運営に用いるスプレッドシートに、高い頻度でエラーを 発見している。図2は、業務運営スプレッドシートに対する多数のテストの結果を列挙している。これらの研究に より、テストしたスプレッドシートの94%にエラーが見付かったことに注意。幾つかの研究が重大なエラーだけを 報告したにも拘らずである(管理者注：原文の"if these errors were significant"は意味不明につき訳出せ ず。)。さらに、検査されたスプレッドシートのほぼ全てが、暫くの間、使われて来たものだった。この事実は、自 社のスプレッドシートは正しいと信じる企業に対する挑戦であろう。 図2:業務運営スプレッドシートのテスト 監査 ｴﾗｰ 対象 執筆者 年 ｽﾌﾟﾚｯ ｻｲｽﾞ ｽﾌﾟﾚｯ ｴﾗｰ ﾄﾞ (ｾﾙ数) ﾄﾞ ｾﾙ率 ｺﾒﾝﾄ ｼｰﾄ率 ｼｰﾄ 数 Hicks Coopers & Lybrand KPMG 1995 1 1997 23 1998 22 3,865 150行 以上 100% 1998 2 100% 7,027 Butler 2000 7 86% Clermont Hanin, & 意思決定を左右する著しいエラーのみ。 2.2%, モデル2に於いて、投資の価値を、16%過大に報 2.5% 告。極めて深刻。 0.4% 税金の追徴となる程大きなエラーのみ。* 1.3%, 2002 3 100% Mittermeier 6.7%, 非空白セルのみでエラー率計算。 0.1% 2,182 Lawrence and かった。 大と判定される(Vorhies, 2005)。 91% & 1件の抜けが、$10億以上のエラーに繋がりかねな 少なくとも5%の誤差。5%の誤差で、会計エラーは重 91% 2,270 Lukasic 1.2% 2004 30 Lee 合計/平均 種類の 式 100% 6.9% Mercer Finace & Risk Consultingが、昨年度に監 査した最も会計上重要なスプレッドシート。 (平均) 88 94% 5.2%** * 低エラー率は、スプレッドシートの全てのセルを検査していないが、リスクの高い式に的を絞っている方法論を反映していると思わ れる。但し、エラーは、極めてランダムな成分なので、全ての式をチェックしないと、多くのエラーを見過す傾向がある。 ** この加重平均には、スプレッドシート数の多いLawrenceとLeeの研究の影響が大きい。LawrenceとLeeは、数量エラーよりも広い 概念である「問題」を計測している。 出所: Panko (2006c)。 殆ど全てのりスプレッドシートがエラーを抱えているのは何故か？その答えは、人がスプレッドシートモデルを開 5 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ 発する際に、式を入力するセルの2%から5%でエラーを産み出しているからだ[Panko, 2007b]。これは、高エ ラー率に見えるかもしれないが、数学的計算の95%から98%の精度は大変立派なものだ。複雑さが同等の他の 認識活動でも、同様のエラー率になることが分かっている[Panko, 2007a]。 個々の式のエラー率はとても低いが、研究によれば、重要なスプレッドシートは、通常、極めて大きく[Cale, 1994; Cragg & King, 1993; Floyd, Walls, & Marr, 1995; Hall, 1996] 、数千セルを持つ。個々の式のエラー率 が2%から5%であっても、相応のサイズのスプレッドシートでは、最終結果にエラーとなるのは確実だ。事実、企 業のスプレッドシートには、しばしば、何千もの個々に異なる式がある。これらの大きなスプレッドシートでは、エ ラーがあるかではなく、幾つのエラーがあるか及びどんなに深刻なエラーかが問題なのだ。 既に述べた様に、図2に示す研究の幾つかだけが、重大なエラーを報告している。サーベンス-オックスリー法に ついて言えば、Coopers and Lybrand[1997]の研究は、最終結果に5%以上のエラー、即ち、重要なエラーがな いとエラーを報告していない。この研究は、テストした会計スプレッドシートの91%に、この様なエラーを発見し た。KPMG[1998]もまた、同様のエラー率を見出した。但し、こちらでは、意思決定者に影響するエラーを抱えて いる場合にのみ、スプレッドシートが正しくないと報告している。総じて、スプレッドシートのエラーは、コンプライ アンス法規に服し、スプレッドシートを重要な計算に用いる企業財務報告及びその他分野での正確性に対する 深刻な脅威である様だ。 スプレッドシートに 不正行為 スプレッドシートに関する脅威 する脅威Ⅱ 脅威Ⅱ類:不正行為 しばしば、不正確、それも、深刻に不正確なのに加えて、スプレッドシートには、不正行為も生じやすい。大雑把 に言えば、不正行為は、他人または他組織に損害を与えるために、嘘をつく(或いは情報を出さない場合も)こと である。 例えば、Allfirst社の為替トレーダのJohn Rusnakは、1997年頃から、トレードで損失を出し始め、損失は増え続 けた。不正行為が遂に暴かれた時点で、彼の損失は6億912ドルに達していた[ABA Banking Journal, 2002; BBC, 2002; Butler, 2001; United States Department of Justice, 2002] 。 一方、英国の歳入税関庁は、以前から、スプレッドシートのエラー及び不正行為を検査する監査部門を持ってい る[Butler, 2000]。これまでに、この部門は、多くの不正行為を発見している。例えば、申告者が、数値の列を合 計していた。ところが、幾つかの数値は、合計の際にゼロとして扱われるラベルとして入力されていた。 サーベンス-オックスリー法は、明確に、2000年及び2001年の企業不正行為の連続に触発されたものだ。しか し、SOXは、スプレッドシートの不正行為に関する最初のコンプライアンス法規ではない。1997年に、米国食品医 薬品局(FDA)は、連邦規則集 第21章 第11部「電子的記録・電子署名」を公布(管理人注：同じ年の内に「施行」 にもなった。)した。21 CFR Part 11として知れられるこの法規は、製薬会社に、薬品の試験及び分析に用いるス プレッドシートを安全に保管することを求めている。この場合の脅威は、データの偽造及びテスト結果の変更等 である。 スプレッドシートに 伝統的な スプレッドシートに関する脅威 する脅威Ⅲ 脅威Ⅲ類:伝統的 伝統的なセキュリティ攻撃 セキュリティ攻撃 一般に、スプレッドシートは、機密性、データインテグリティ、及びデータ可用性に対する伝統的なセキュリティ攻 撃の全てに見舞われる可能性がある。不満を持った従業員及び元従業員が、機密性の高い情報を流したり、 データを壊したり、或いは、必要とする人にデータが渡らないようにしたりするかもしれない。犯罪者、企業スパ イ及び一般ハッカーが、これらを行うかもしれない。スプレッドシートは、高い価値を持つターゲットだ。何故なら、 それが、しばしば、アイデンティティ窃盗に役立つ重要な組織データ及び個人データを含むからだ。さらに、スプ レッドシートの式の論理は、それ自体が貴重な知的財産だ。 6 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ スプレッドシートに スプレッドシートに関する脅威 する脅威の 脅威の現実 スプレッドシートとサーベンス-オッスクスリー法に関する懸念は、単なる推測ではない。2005年の初回サーベン ス-オックスリー監査は、通常、甚だしい統制の欠陥だけに注目したものだったが、多くの企業が、スプレッドシー トに関する重大な不備を報告した。特に、調査会社のMcGladrey社は、証券取締委員会に提出された報告書を 調査し、Eastman-Kodak社を含む夥しい数の企業が、スプレッドシートに起因する統制の不備を報告していたと 報告した[Kelly 2005]。今後のサーベンス-オックスリー監査は、もっと厳格になり、より多くの問題が報告される だろう。 ガバナンス ガバナンスという語は、企業が業務に対して整備する統制の一種を指す。図3は、ガバナンスの一般的なモデル である。ITだけでなく、一般的な業務プロセスに対しても適用されることに注意。特に、業務プロセスは目標を持 つことに注意。財務報告システムの主要な目標は、勿論、その企業の財務状況及び業績の正確な投影図を作 成することである。ガバナンスの目的は、業務プロセスが目標を達成することについて、合理的な保証を提供す ることである。 図3:ガバナンスモデル 業務は、ITだけでは構成されていない点にも注意。もちろん、ハードウェア、ソフトウェア及びデータにより構成さ れる技術的な要素はある。しかし、業務プロセスは、人の能力や動機付け、業務プロセスで用いられている業務 手順、業務プロセスがどう組織化されているか、及び業務プロセスが主体的にどう管理されているかにも依存し ている。 脅威とは、業務プロセスを目標達成から遠ざける可能性の有るあらゆるものである。脅威には、エラー、不正行 為、攻撃、或いは単なる天気が含まれる。統制は、脅威に対する対策である。スプレッドシートは、明らかに、エ ラーと攻撃(不正を働く従業員及び外部のハッカーの両方を含む)により生じる脅威を、無視できる程度迄(管理 人注：原文の"non-negligible"は"negligible"の間違いと推定)、減じる為に統制を必要とする。 7 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ セキュリティ及び不正行為統制 この節では、スプレッドシートが関係する不正行為及び伝統的なセキュリティへの脅威を低減する統制を見て行 く。これらの脅威を倒す魔法の弾丸が無いことがわかるだろう。寧ろ、伝統的なセキュリティ及び不正行為が起 きないことを保証する為に、企業は、技術面、手続面、及び管理面のツールの強力なセットを用いることを必要 とする。 Vaultサーバ サーバ 伝統的なスプレッドシートは、大抵の企業が、重要なIT資産に用いる伝統的なセキュリティ保護をろくに提供して いない。しかし、21 CFR Part 11に対して、幾つかのベンダが、スプレッドシートセキュリティをサポートするVault サーバを生み出した。SOXにより、企業は、ますます、Vaultサーバに注目している。図4は、これらの製品がどう 動作するかを示している。個々のVaultサーバ製品が、これらの保護の全てを提供するわけではない。 図4:Vaultサーバ 認証、 認証、認可、 認可、及び監査 最初に、Vaultサーバは、業務プロセスで用いるスプレッドシートを安全に格納する。Vaultサーバは、認証、認 可、及び監査によって、アイデンティティ及びアクセスをしっかりと統制する。 認証は、ユーザに、全てのスプレッドシートにアクセスする前に、彼または彼女のアイデンティティ(管理人 注：ユーザIdを意味する。)を証明することを求める。アイデンティティ管理システムは、企業の認証情報を 一元的に管理する。アイデンティティ管理は、Vaultサーバ製品の弱点の一つである。さらに、脆弱な Vaultサーバの認証システムは、大変脆弱な認証手段であるパスワードしか求めない。より良いVault サーバは、2種類の形態のアイデンティティ確認を行う2要素認証を要求する。 認可は、個々の認証済ユーザが、如何なる操作を許可されるかを判定するルールにより構成される。殆 どの認証済ユーザは、幾つかのスプレッドシートでのみ業務ができれば良い。その上、そのユーザは、ス プレッドシートの一部だけを参照できるように制限されているかもしれない。さらに、そのユーザは、ロジッ クの変更或いはデータ入力ができたり、できなかったりする。 監査は、ユーザがスプレッドシートに対して行った全ての操作に関するデータの記録である。最も単純な Vaultサーバは、スプレッドシートが、チェックイン及びチェックアウトした際に、単にそれを記録するだけ だ。コンプライアンス要件を充たすには、これは不十分であろう。より良いVaultサーバは、スプレッドシー トに対して行った全ての操作を記録する。 8 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ バージョン管理 バージョン管理、 管理、ディザスタリカバリ、 ディザスタリカバリ、及び安全な 安全なアーカイブ アクセス制御の(管理人注:原文のまま。正確には、「アクセスに関する」が適当。)AAA保護(認証、認可、及び監 査)に加えて、Vaultサーバは、他の多くの統制を実施する。その一つがバージョン管理、即ち、ユーザが各スプ レッドシートの正しいバージョンを使うことを保証すること。Vaultサーバの他の重要な統制は、ディザスタリカバ リツール(バックアップを含むがそれ以上)、及び法の求めに応じて古いバージョンを保存するアーカイブツール である。 暗号による 暗号による保護 による保護 一般に、ユーザは、Vaultサーバにリモートから、恐らく、パソコンからアクセスする。ユーザ及びそのPCは、サー バにアクセスする前に、認証を受けなければならない。その後、各メッセージを、機密保護の為に暗号化しなけ ればならない。さらに、各メッセージには、メッセージ毎の認証及びインテグリティの為に、電子署名を付けるべ きである。メッセージのインテグリティは、メッセージが経路上で変更されていることを、受信者が判別できるよう にすることである。Vaultサーバは、これらの保護には、クライアントとの通信に、十分にテストされたプロトコルを 用いるべきである。SSL/TLSで恐らく十分だ。しかし、IPsecが好まれている。 ネットワークアクセス制御 ネットワークアクセス制御 (NAC) Vaultシステムは、通信が始まる前の時点ですら、ネットワークアクセス制御 (NAC)を利用できる。NACは、リ モートのPCをスキャンして、最新のアンチウィルスプログラムを持っているか、オペレーティングシステムが更新 されているか等、保護機能を調査する。 監査分析 Vaultサーバシステムは、監査データベースを、巨大な書込専用メモリ以上のものとする為に、監査分析機能を 備えるべきである。パターン分析は、監査データに於いて、同一個人が同時に複数ログインしている等の疑わし いパターンを探し出す。 カナリア分析は、問題の予兆を示す単一の数値である。(この用語は、良く知られている「炭鉱のカナリア」(管理 人注：ガス監視用に炭鉱にカナリアを持ち込んだことから、予兆検知するものを意味します。)に由来している。) 式セルに対して計算された安全なハッシュは、スプレッドシートがユーザから送信された時点と返信された時 点で変わってはならないというのが、その例である。 ポリシー中心 ポリシー中心の 中心の管理ツール 管理ツール 最後に、Vaultサーバシステムは、それを効率的且つ効果的にする為に、強力な管理ツールを必要とする。これ らのツールは、組織が監査可能なポリシーを作成し、それらを詳細な活動に於いて実施することができる様にす るポリシー管理ツールを含まねばならない。 9 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ デジタル著作権管理 デジタル著作権管理 (DRM) 殆ど全てのVaultサーバ製品には、一つの望ましい保護機能が欠落している。それは、デジタル著作権管理 (DRM)である。DRMは、ファイルに対して、ユーザができることを制限する。元々は、ダウンロードした音楽に対し て、ユーザができることを制限する為に開発されたものだが、DRMは、スプレッドシートファイルに対しても使え る。保存、印刷、コピー、その他のスプレッドシートに埋め込まれた企業の知的財産を盗むことになる操作の制 限、或いは、異なるシステム上に複数のバージョンを作成することの予防に用いることができる。 現実的な サーバ 現実的なValutサーバ 総じて、我々は、理想的なVaultサーバシステムを思い描いて来た。しかし、現実的なVaultサーバ製品は、一般 に、思い描く機能の一部しか持っていない。殆どのVaultサーバ製品は、元からVaultサーバとして使用する様に 考えられて開発されている。一方、マイクロソフトは、Excel、SharePoint、及びスプレッドシート参照の為のブラ ウザベースのサービスに、限られたVaultタイプの保護を付加している。 分離された 分離された開発 された開発プロセス 開発プロセスの プロセスの使用 セキュリティ及び不正行為のリスクを低減する方法の一つに、開発プロセスを安全にすることが挙げられる。 図5:分離された開発プロセス 図が言わんとしているのは、開発、テスト及び本番の分離である。このアプローチは、企業で、しばしば、一般的 な品質管理の為に用いられる。例えば、企業ウェブの変更の際には、通常、最初にテスト用サーバ、次に、本番 用サーバに移された複製に対して変更を行う。 しかし、ここで言う分離の目的は、開発者が不正行為及び伝統的なセキュリティ攻撃を犯す為のロジックを追加 することの予防である。この安全な開発プロセスでは、開発者は、本当に開発する際にのみ、コードに触れるこ とができる。開発が終わると、スプレッドシートは、開発者から取り上げられて、テスト専任のグループによってテ ストされる。理想的には、テスト担当グループは、単にエラーだけを探すのではない。コード中の不正行為及び セキュリティ上の欠陥の兆候を探すパラノイドテストも行う。 テストが終わると、スプレッドシートは、テスタから取り上げられ、恐らくはVaultサーバである本番サーバに置か れる。開発者もテスタも、スプレッドシートのロジックへの修正、或いはアクセスすら許されない。ロジックは、完 10 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ 全にロックされる。 そのでも尚、ロジックの変更が無いことを、頻繁にチェックすべきである。これを行う方法の一つに、スプレッド シート中の全ての式に対して横断的に、SHA-224またはSHAのより強力なバージョンを用いて、メッセージダイ ジェストを計算することが挙げられる。(MD5及びSHA-1は、アルゴリズムに既知の脆弱性があるので、用いるべ きではない。) スプレッドシートで計算されたダイジェストが、そのスプレッドシートの元々のダイジェストと一致し ない場合は、ロジックに変更があったことになる。 厳格な変更統制も必要である。修正要求は、特定の人だけに許可すべきであり、修正承認権限は、より制限 し、変更要求から厳格に分離すべきである。さらに、全ての修正は、開発－テスト－本番のサイクル全部を経る ようにして、不正な変更が無いことをテストによって確実にすべきである。 図5に示す安全な開発プロセスの問題は、高価につくことと、開発及び修正の時間が長くなることである。 組織面の 組織面の統制 技術による統制も良いが、それだけで十分ということはない。不正行為の場合には特にそうだ。公認不正検査 士協会の[ACFE, 2004]は、不正検査士を頻繁に調査している。その調査、The 2004(管理人注:[ACFE, 2004] を指すと推定される。)は、職務に於いて犯された不正行為が、最初に、どうやって発見されたかを尋ねている。 図6は、回答者が寄せた回答を示している。(幾つかの不正行為(管理人注: 発見手法に)に複数回答をしている ため、合計が100%以上になっている。) 図6:業務上不正行為の初期発見 初期発見手法 不正行為構成比 内部通報 39.6% 内部監査 23.8% 内部統制 18.4% 外部監査 10.9% 偶然 21.3% 警察からの通知 0.9% 出所: ACFE (2004)。 内部統制の全てを合わせても、内部統制が発見したのは、全ての事例の18.4%に過ぎなかったことに注意。こ れには、技術的な統制、人的及び組織的な統制を含んでいる。内部及び外部監査は重要だが、事例の1/3でし かなかった。他を大きく引き離した最大の「発見」方法は内部通報であり、事例の39.6%で挙げられた。さらに、 悪いことに、不正行為の1/5は、全くの偶然によって発見されている。 図6のデータは、組織が、受動的な内部統制だけに依存すべきではないことを示している。不正行為を発見する 為には、かなり主体的な監査が必要だ。最も重要かもしれない点は、組織は、不正行為を内部通報するの為の 匿名電話を設置する必要があるということである。(これは、サーベンス-オックスリー法で具体的に求められてい る。) 監査グループは、独立(管理人注：「役員の指揮命令下ではなく」の意味)している必要がある。不正行為 犯は、しばしば、上層部の役員だからである。監査グループは、役員会の直属とすべきである。 11 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ 行動の 行動の評価 個々の技法も重要だが、ユーザの行動に対する一般的な注意によって、潜在的な問題に対する警告を、早い 段階で得ることができる。米国シークレットサービスによる研究[DeCarlo, 2006]では、勤務先企業に攻撃を仕 掛けた従業員の80%が、事前に、不穏な行動を示していたことが分かった。さらに、92%は、解雇、降格、或いは 異動等の大きな職歴変更の後に攻撃している。半数は、勤務先企業を攻撃した時にも、その企業で働いてい た。研究では、調査対象とした企業の6%は、これらの攻撃で、甚大な損害を蒙っていたことも分かった。これらの プロファイル情報を用いて、企業は、これらの破壊的な行動を真剣に受け止め、破壊的な行動を示した全ての 従業員を疑ってみる必要がある。不穏な行動を、簡単に閑却すべきではない。 不正行為が脅威であるとき、企業は、不正行為に至る因子を予見すべきである。図7に示す動機－機会－正当 化トライアングルは、不正行為を予見する為のツールの一つである。このトライアングルは、強い動機があると きには、常に注意せよと、企業に教えてくれる。強い動機とは、例えば、金銭が掛かっているとか、従業員に、復 讐すべき現実或いは想像上の理由があるということである。整備されている統制が弱い場合、警備されていな いアクセスポイントがある場合等には、機会も予見すべきである。人が、どうやって、不正行為を正当化するか を理解することも役立つ。例えば、彼らに十分な給料を払わない会社の方が悪いとか、裕福な会社には、その 程度の損害はなんでもないと主張する。 図7: 不正行為のトライアングル 不穏な行動に対して敏感でいること、及び動機、機会、それに正当化を考えることは、重要な原則である。しか し、攻撃或いは不正行為の行動面での兆しに対する感度は、とても、複雑なトピックスである。行動面の兆候を 効果的に使う方法を学ぶ為には、企業は、多くの投資を必要とする。 セキュリティ及 セキュリティ及び不正行為 概して、セキュリティへの脅威は重要である。しかし、今日では、既存のセキュリティ手続き、及び、幾分か及ば ないが、セキュリティ製品によって、それに、対処することができる。一方、不正行為を阻止するのは、より困難 である。何故なら、それは、人的な発見の手法を要するからである。さらに、概して、不正行為統制については、 職務の分離及びローテーションの様な古典的な推奨策、人の行動及び行動の変化に敏感でいること、主体的な 監査の重要性以上には、多くを語ることができない。 12 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ エラー統制 この節では、エラー統制に目を向けてみる。スプレッドシートエラーは、その類型、頻度(管理人注: "and delectability"は、意味不明につき訳出せず。)の点で、ソフトウェア開発(管理人注：に於けるエラー)とほぼ等し いことが示されている[Panko, 2007a 2007b]。エラー統制は、この事実を活用している。この類似性から、ソフト ウェア開発に於ける伝統的なシステム開発ライフサイクル(SDLC)、或いはラピッドアプリケーション開発やアジャ イルアプリケーション開発の手法に用いられるSDLCを幾らか修正したものを、スプレッドシート開発者が用いる 必要があると分かるのだ。 ベストプラクティスガイドライン スプレッドシート開発へソフトウェア用のSDLCを適用することに関して、多くのベストプラクティスが公開されてい る[American Institute of Certified Public Accountants, 1993; Bewig, 1995; Caine & Robson, 1993; Freeman, 1996; Harrison & Yu, 1990; Howard, 2005; Institute of Chartered Accountants in England and Wales, 1966; Kee, 1988; Kee & Mason, 1988; Lally, 1995; Panko, 1988; PricewaterhouseCoopers, 2004; Raffensperger, 2003; Read and Bateson, 1999; Seymour, 1988; Wittig, 1990.] 。これらのベストプラ クティスガイドラインは、多様で複雑だが、いくつかの一般的なポイントは、しっかり確立されている。 リスク分析。 殆どの処方箋は、スプレッドシートに起因するリスクの分析や特別な考慮事項、例えば、限られた開発時 間、不正行為やセキュリティ上の脅威及びエラーの伏線となる曖昧な要件定義等に殆ど時間を割いてい ない。Read及びBatson[1999]は、リスク分析を、興味深い程度に論じている。しかし、さらに多くの仕事が 必要とされる。 要件及び設計。 ユーザは、スプレッドシートの開発に先立つ本式の要件定義及び設計に、めったに参加しないことが研 究[Brown & Gould, 1987; Panko & Halverson, 1997; Takaki, 2005] により明らかにされている。(その 対策として、管理人注:スプレッドシートの)開発前に設計を行う幾つかの手法が提示されている。ここで も、Read and Batson[1999]が、代替策に関する最も徹底した議論を提供している。 基本構造。 殆ど全ての情報源が、スプレッドシートを、入力、処理、及び出力に、3分割することを推奨している。しか し、Raffensperger[2003]は、このアドバイスに対して、処理部の式が、離れた場所のデータセルを参照し なければならなくなるとして、異議を唱えている。離れた場所を参照するために、式を入力する際の参照 エラーが増え易くなり、また、スプレッドシートの理解及びテストも難しくしてしまう。言い換えれば、この伝 統的な入力-処理-出力アドバイスは、有害なのかもしれない。これは、経験論的な研究を要する領域で ある。 詳細構造。 殆どのアドバイスは、詳細構造に注目している。例えば、(管理人注:ベストプラクティス作者である)先生 方は、ロジックは、左から右、上から下へと書くべきとか、範囲名を用いるべきとか、セルの保護を用いる べきと主張している。本稿では、ベストプラクティスを提案している沢山の詳細構造ガイドラインについて 論じることはできない。 文書化。 相当な注目を集めている分野に、スプレッドシートの文書化がある。ほぼ全ての処方箋が、スプレッド 13 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ シートの内部及び外部の両方の文書化を求めている。この大勢の推奨にも拘らず、文書化は、依然とし て、滅多に為されない[Pryor, 2006]。このことは、コンプライアンスにとって問題である。何故なら、殆ど のコンプライアンスの規定(管理人注:原文ではregime。SOX法、21 CFR Part 11等の法規・法令別の要 求事項体系を意味する。)が高い透明性を要求しており、それは、高度な文書化によってのみ達成される からである。スプレッドシート技術の改善は、文書化にも役立つ。今や、スプレッドシートを、ワープロ文書 に埋め込める。これと同様に、ワープロファイルやPowerPointファイルを、Excelワークシートに埋め込め る様にして、文書化の能力を改善すべきである。 テスト。 殆ど全ての処方箋がテストについて述べている。しかし、それだけだ。次の節では、テストを、より詳細に 見て行く。何故ならば、最も推奨されている実務ガイドラインに見られるテストに関する通り一遍の解決策 が示すよりも、全てのソフトウェア開発に共通する、もっと大きな話だからである。 導入。 処方箋は、総じて、開発後のスプレッドシートの導入について、トレーニングと文書化の点で論じてきた。 修正。 開発後のスプレッドシートの修正は、総じて、(人々が正しいバージョンを使うようにする為の)バージョン 管理、及び修正後のテストの必要性の観点で論じられてきた。一部の著者は、修正は、限られた従業員 だけが要求できるようにすべきであり、また、さらに少数マネージャーだけが、修正を承認できるようにす べきと主張している。いずれにしても、修正は、十分に文書化されるべきである。 テスト及 テスト及び検査の 検査の必要性 システム開発ライフサイクルに関する大量の文献が既にあるため、これを、ここで論じることはしない。その代わ り、一つの点に焦点を当てる。即ち、テスト及び検査である。ソフトウェア開発では、長い経験から、プログラミン グプロジェクトは、テストと検査に、そのリソースの多くの部分を費やす必要があると知られている。27組織に於 ける84プロジェクトをサンプルとして、Jones[1998]は、エラーを削減する為にテストに費やす時間は、プログラム の難しさによって、27%から34%の開きがあることを見出した。さらに、全ての事例で、被験者は、テストに不十分 な時間しか割当てられていなかったと報告している。Kimberland[2004]の研究では、マイクロソフトのソフトウェ ア開発チームは、全作業時間の40%から60%をテストに費やしたことが分かった。また、Grady[1995]では、殆ど のプロジェクトが1/3の時間をテストに費やしていたことが分かった。 対照的に、スプレッドシート開発者への調査は、企業のポリシーが、スプレッドシート及びその他エンドユーザア プリケーションを開発後にテストすることを求めることは稀であることを、長年にわたり示してきた[Cale, 1994; Cragg & King, 1993; Floyd, Walls, & Marr, 1995; Galletta & Hufnagel, 1992; Gosling, 2003; Hall, 1996; Speier & Brown, 1996]。一方、個人の開発者は、彼ら自身のスプレッドシートを、開発後に、体系立ててテスト することが滅多に無い[Cragg & King, 1993; Davies & Ikin, 1987; Hall, 1996; Schultheis & Sumner, 1994]。その代わりに、彼らは、スプレッドシートを、他人に、ざっと目を通させる等、良さそう「テスト」手法を用い る傾向がある。ソフトウェア開発では、徹底したテスト及び検査は、SDLCの必須要件である。徹底したテスト或い は検査/レビューが行われなければ、他の何事も意味が無い。これからも、余りにも大量のエラーを生じることに なるだろう。スプレッドシート統制でも同じことが言えるならば、スプレッドシート開発者は、作業の仕方を再設計 し、徹底したテストと検査をしなければならない。 14 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ テスト エンドユーザのスプレッドシート開発者は、「テスト」という語を、幅広いチェックプロセスを含むものとして、広義 に用いる。多くの場合、それは、単に、結果が合理的そうか、他人に、ざっと眺めさせることを意味している。スプ レッドシートのエラー率、プログラミングに於けるエラー率を相当に低減する為の徹底したテストの必要性を考え ると、虚勢を張って、本式のテスト及び検査手法を不要としても、安全でも、効果的でもなさそうだ。 しかし、一方で、プログラマは、テストという語を、とても限定的な用法で用いる。即ち、プログラム或いはプログ ラムモジュールに入力データを入力し、その出力を予想結果と比較するという意味で用いる。我々は、テストとい う語を、この限定されているが、良く知られた意味で用いる。ソフトウェア開発システムは、テスト担当者が、シス テム(モジュール)の一部を隔離してテストする機能すら備えている。 スプレッドシートの スプレッドシートのテストは テストは何故難しいのか 何故難しいのか テストは、大変効果的だが、プログラミングでそれを行うのは難しく、スプレッドシートのテスト担当者は、多くのこ の困難、或いはそれ以上のものに直面する。Panko[2006b 2006c]は、スプレッドシート開発者によるテストの利 用に関する幾つかの重大な問題について、まとめている。 最初に、人間は、総じて、上手く動作するテストケースを選ぶ強力な確証バイアスを持っている。動かな いかもしれないテスト値を使うように指導するのは困難だ。ソフトウェアテスト担当者は、しばしば、テスト ケースを上手く選ぶ方法に関する何週間かのトレーニングを受ける。単に、ベストプラクティスガイドの様 に、人々に、極端な値或いは負の値を用いるようにと言うだけでは、単純過ぎる。 二番目に、テストは、一つの変数の値に対してではなく、複数の変数に対する複数組の値を用いて行わ ねばならない。これは、テストケースの組合せ数の爆発的増大を招くので、テスト担当者は、組合せ数の 爆発的増大を低減する為に、同値類を見付けることを学ばねばならない。同値類とは、、同じ結果を生じ るデータの集合である。このため、各同値類につき、一件のテストケースで事足りる。同値類の定義は、 身に付けるのが大変なトピックスである。 三番目に、そして、これが最も基本的なことだが、テストには、各テストデータセットに対して、予見される 結果を予測するオラクル(管理人注：DBMSのオラクルとは無関係。「テスト中のソフトウェアの実際の結果 との比較に用いる予想結果を判定するためのソース」の意味。)が必要である。既知の変更が起きるだけ の振舞オラクルは、テストが容易だ。パスワード変更が、望んだ結果をもたらすかをテストするのが、この 一例だ。パスワードファイルを見れば、これをテストできる。しかし、スプレッドシートのテストには、殆どい つも、入力データの各セットに対する結果数値を予測する演算オラクルを必要とする。多くのスプレッド シートの計算は複雑で、スプレッドシートを使わないでテスト計算を行うことは、困難或いは不可能だ。こ れは、スプレッドシートのテストに関する極めて基本的な問題だ。スプレッドシートが、一旦、他の手段に よって検証すれば、その後のバージョンのスプレッドシートモデルの回帰テストには、(管理人注：作成済 の演算オラクルが利用できるので、)魅力的かもしれないが。 スプレッドシートへの スプレッドシートへの直接入力 への直接入力と 直接入力とテスト表示部 テスト表示部 スプレッドシートのテストに関する不安の一つに、Excelがテストを行うように設計されていないことが挙げられ る。オブジェクト志向プログラムのテストでは、オブジェクトへの入力を変更し、出力を観察することは簡単だ。ス プレッドシートの比較的小さいモジュールを、この方法でテストできれば、演算オラクルを開発することは、ずっと 容易になる筈である。 15 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ しかし、図8に示す単純な税引前利益モジュールをテストすると仮定して欲しい。この図では、収入及び支出セル は、前に出てくるセルを指している。これらのセルは、税引前利益、税、税引後利益を計算するのに使われてい る。 図8:スプレッドシートテスト表示部 収入及び支出セルに、収入及び支出テストケース値を入力して、式を上書きするのが、一つのアプローチだ。こ のやり方は、有効だが、しかし、大変危険である。テスト担当者が、テスト後に、収入の式を元に戻し、一方で、 支出の式を戻さなかったら、「値を直接入力された」式セルによって、このスプレッドシートは、既に、正しくないも のになる。多くのモジュールをテストしなければならないなら、直接入力値によるエラーを、少なくとも1件、起こし てしまう確率が、許容限度を越えてしまう。 この問題を低減する方法の一つは、Excel及び他のスプレッドシートプログラムにテストペイン機能を創ること だ。この例の場合、税引後利益モジュールに、テストペインが定義されれば、入力されている式を変更すること 無く、値を好きなだけ変更することができる。セルに入力される数値は、直接入力ではなく、従って、一時的な値 に過ぎない。セルの一つのエラーを修正する為の操作をしない限りは、テストペインが閉じられた時に、セル入 力は、最初の式に戻される。 多くのテストケースを実行すると、テストケース別に入力及び出力値をテーブルに記録することができれば、これ も、有難い。テストの文書化は、時間が掛かることが多い。テーブルへの記録機能は、テスト文書の作成時間を 削減し、テスト文書の正確性を向上させる。 検査/レビュー 検査 レビュー テストは、ソフトウェア開発で、最も広く用いられているフォーマルな検証手法だが、検査或いはレビュー等と様 々に呼ばれているもう一つの技法も、ソフトウェアコードの検証に大変役立つことが証明されている。ソフトウェ ア検査/レビューでは、知識豊富な専門家が、エラー(プログラマは故障と呼ぶ)が無いか、コードモジュールを吟 味する。 ソフトウェア検査 ソフトウェア検査/レビュー 検査 レビュー 検査/レビュープロセスは、高度に、統制されている必要があることが、苦い経験から示されている。Fragan [1976]が、フォーマルな検査をする為の最初のルールセットを提供した。それ以来、他の多くの処方箋が、 フォーマルな検査/レビューを統べる為に提案された。これらのルールは、一般に、以下に示す特徴を備えてい た。 16 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ 最初に、殆ど全ての手法が、検査担当者/レビュー担当者は、プログラムモジュールの目的、設計、及び コーディングを理解しなければならないという点を強調している。これには、通常、レビューチームが、エ ラーが無いか、コードをウォークスルーすることが求められる[Fagan, 1976]。 二番目に、検査/レビューは、プログラム全体ではなく、モジュール毎に行う必要がある。さらに、モジュー ルの規模は、かなり小さくする必要がある。殆どの手法が、50から150行のコードにすることを求めてい る。モジュールが大きくなる程、エラー発見率は低くなる。[Barnard & Price, 1994] 三番目に、検査/レビューは、焦ってはならない。1時間当たりの検査対象コード行数を制限しなければな らない。何故なら、もし、検査を急ぐと、発見率が大きく低下するからである[Basili & Perricone, 1993; Russel, 1991; and Weller, 1993] 。 四番目に、検査/レビューは、グループで行わなければならない。プログラマは、コードを製造する際に、 95%から98%は正確だ。しかし、個々の検査担当者は、検査の際に、全てのエラーの約40%しか捕捉しな い[Johnson ' Tjahjono, 1997; Myers, 1978] 。(エラー発見の際には、製造の際よりも高いエラー率を示 すことは、人的なエラーの研究では常識だ。)プログラミングでは、80%のエラー発見率を達成する為に は、3から8人のグループが必要とされる。 スプレッドシートコード検査 スプレッドシートコード検査 3件の実験が、スプレッドシートの検査/レビューについて行われた[Owe & Simkin, 2006; Galletta et al., 1993 1997; Panko, 1999;(管理人注：セミコロン後が空白なのは原文のまま)]。全ての研究で、被験者は、ソフ トウェア検査に関する文献の通りに、埋め込まれたエラーの約半分を発見した。これに対して、Panko[1991] は、単独で63%の発見率が、3人組のグループでは、83%に押し上げられることを発見した。グループ作業で最も 効果があったのは、個人では発見が困難だったエラーである。 マイクロソフトExcel式監査 式監査ツールバー マイクロソフト 式監査ツールバー及 ツールバー及びダブルクリック スプレッドシート検査/レビューは、しばしば、監査と呼ばれる[e.g., Galletta et al., 1993 1997]。しかし、「監 査」は、2つの大変異なることを意味するようになってきた。一方の極端では、スプレッドシートの「全ての」式を検 査する[e.g., Galletta et al., 1993 1997]。他方の極端には、品質を評価する為に、スプレッドシートのセルの サンプルを監査することを意味している。全てのセルに対する吟味には、曖昧さの少ない用語、即ち、検査/レ ビューを使った方が良さそうだ。 しかし、マイクロソフトExcelは、その中心的な検査/レビューメカニズムに監査を採用した。その結果が、式監査 ツールバー(管理人注:日本語版では「ワークシート分析」ツールバー)である。これは、標準のツールバーで、表 示/ツールバー/式監査(管理人注：メニューバーのメニュー階層を示し、日本語版のメニュー項目名は、「ワーク シート分析」)で、有効化及び無効化できる。図9は、このツールバーの要素を示している。 図9:マイクロソフト監査ツールバー 17 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ 検査/レビューには、参照元表示アイコン(管理人注:「参照元のトレース」ボタンのこと。)が中心的なツールであ る。図10が示す通り、式のセルをクリックして、参照元表示を選択すると、式の参照元セル、即ち、式の中から参 照しているセルが表示される。図中で、式セルはB6である。参照元セルは矢印で示されている。例えば、直ぐ下 を指す矢印は、セルB2からB5が参照元であることを示している。 図10:他ワークシートの参照元 しかし、右から来る矢印には、問題がある。その端には、小さなワークシートの様に見える小さなアイコンがあ る。この意味の分かり難いアイコンは、B6の式が、他のワークシートのセルを参照していることを示している。ど のワークシートのどのセルを参照しているのか？アイコンは、それについて何も語らない。他のワークシートへ のリンクをインテリジェントに扱うことができないことは、ワークブックの中に、入力用、処理用及び出力用に個別 にワークシートを持つと、参照元表示機能が、処理ワークシート中の式の検査には、殆ど使い物にならないこと を意味する。 この他にも、スプレッドシートは、B6の式の結果を示すが、セル中の式を示さない。これは、検査/レビューには 不十分である。 式監査ツールバーに加えて、Excelには、図11に示す様な検査/レビューツールがもう一つある。セルをダブルク リックすると(またはセルをクリックしてF2キーを叩くと)、式がセルの中に現れて、参照元のセルが表示される。 参照元セルは、色付きの境界線で示され、参照元セルを示す式の中の項は、同じ色で表示されている。 図11:ダブルクリックおよび参照元 ここでも、他のワークシートのセルへの参照に問題がある。この機能は、式監査参照元表示ツールよりも、多く の情報を示す。ワークシートは、セル同様に、名付けられる。しかし、セルが名前付き範囲でなければ、それ以 上の情報は得られない。 18 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ ダブルクリックのもう一つの問題は、検査担当者/レビュー担当者が、編集モードで使うことになるということだ。 セルを離れる際に、エスケープキーを叩くことが重要だ。さもなくば、変更が保存されてしまう。ダブルクリック は、不注意による変更が起きない非編集モードで利用する方法ができない。 少し前で述べた通り、参照元表示及びダブルクリックは、同じワークブックの他ワークシート上の参照元を実際 には表示しない。離れたスプレッドシートの参照元セルを表示するポップアップウィンドウは、両方で利用できる 便利な機能となる。このウィンドウは、ウィンドウが重要な情報を覆い隠したり、より広い表示領域を必要とする 場合に備えて、移動もサイズ変更も可能である。 図12:ポップアップ参照元ウィンドウ 検査/レビューの論点の一つはカバレージ、即ち、検査担当者/レビュー担当者に、可能な限り全ての参照元の 連鎖を吟味させることである。(管理人注:式に、)明確な上から下への流れがある場合ですらも、これは、かなり 難しいかもしれない。オレゴン州立大学の研究者は、カバレージに対処する為に、WYSIWYT(What You See Is What You Test)ツールを開発した。検査担当者/レビュー担当者がセルの式をチェックする際に、彼または彼女 は、チェックしたとマークすることができる。マークされると、そのセルは、色付きの輪郭線になる。色は、そのス プレッドシートの参照元セルを全てチェックしたか否かを示す。オレゴン州立の研究は、Forms/3という特別なプ ログラムを使って、そのWYSIWYT手法を実現している。もっと最近では、Randolph, Morris及びLee[2002]は、 Excelと、それにリンクされたJavaプログラムを用いて、WYSIWYT手法を用いた実装を作成している。 どのセルがカバーされたか、どのセルが次にカバーされるかを、現在のセルから始まる木として、論理的なフ ローを表示すると助かるだろう。Rothermel, et al. [1997]は、これをForms/3でやった。かれらの業績の中で、 Randolph、Morris、及びLee [2002]は、(例えば、分岐がIF文でなされるような)単純なフローが無いときには、 テーブルを用いたアプローチが必要だと示唆している。 19 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ 静的テスト 静的テスト 人が、ワープロプログラムで文書を書いているとき、よく、その文書に、スペリング及び文法のチェックを実行す る。ソフトウェア開発では、プログラマは、静的なテストツールを用いて、同様の探索をして、エラー(プログラマは 故障と呼ぶ)を探す。静的テストプログラムは、スプレッドシートのエラーを見付けるのにも使われる。スプレッド シート用の静的テストプログラムは、エラーの可能性の識別に加えて、検査担当者に、スプレッドシートの基本 構造構造を見せてくれる。 スプレッドシート用静的テストプログラムベンダは、ときどき、プログラムは間違わないことを理由に、彼らの製品 は、人間の検査担当者よりも優れていると宣伝している。しかし、ワープロとソフトウェア開発では、チェックプロ グラムは、或るタイプのエラー、通常は、人間が最も見付けやすいエラーにしか効果が無いことが分かってい る。 例えば、スペルチェックでは、静的チェックツールは、非単語エラー、つまり、辞書に載っている単語ではない文 字列になっているエラーの殆ど全てを見付けることができる。"work"の打つところを、"wotk"と打つのがその例 である。しかし、スペルチェックは、辞書に載っている単語を生成する単語エラーには、全く使い物にならない。 "work"と打つところを、"word"と打つのがその例である。人間は、非単語エラーを見付けるのが、とても得意で、 その90%を見付けることができる[Panko, 2007a]。これは、スペルチェッカーに、全く同等とは言えないまでも、か なり近い。単語エラーに関しては、人間は、全ての単語エラーの70%を発見する[Panko 2007a]。対して、スペル チェッカーは、殆ど見付けることができない。 同様に、スプレッドシートの静的テストプログラムでも、エラー発見率は、エラーの類型によって大きく異なる筈で ある。例えば、式が、空のセルを参照していたら、静的テストプログラムは、このエラーを指し示す筈である。しか し、開発者が、変数を一つ忘れたとすると、静的テストプログラムが、このエラーを見付けるのは困難だ。誤った アルゴリズムに基づく、またはアルゴリズムを間違って実装した式エラーは、静的テストでは、はやり、発見され そうもない。或る実験[Panko, 1999]では、スプレッドシートを検査した学生が、機械的な(指示間違え及び打ち 間違え)エラーについては、最高の成功率だった。ロジック(アルゴリズム)エラーについては、低い成功率だっ た。抜けエラーを見付けるのは、駄目だった。 また、静的テストプログラムには、単に、疑わしいものを検査担当者に示して吟味させるだけだという問題があ る。フォールスポジティブが多く、示されたエラーの殆どが、本当は正しかったら、検査担当者は、識別された項 目が、本当にエラーなのか分からなくなってしまう。さらに悪いことに、Galletta et al. [2005]が、文法チェッカー を研究したところ、文法チェック用製品を使う学生は、(管理人注:文法チェッカーから)多くの間違った提案を受け るため、文法が劣る論文を作成することを発見した。 Excel自体は、最低限の静的テスト機能しか備えていない。まず、問題の疑いを見付けると、Excelは、セルの左 上隅に、小さな緑色の三角形を表示する。ユーザがセルをそのクリックすると、疑わしいセルの隣に、警告の菱 形が出る。(この例の場合、式は、下部の二つの入力をカウントするだけだ。)その菱形をクリックすると、図13に 描かれている様に、オプションが表示される。 図13:Excelのエラーチェックに於ける警告の菱形 20 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ スペルチェック及び文法チェックと同様に、Excelは、より体系立ったエラーの見付け方もできる。この例の場合、 ユーザが、ツールメニューの下のエラーチェックメニューを選択する。図14が示す通り、Excelは、最初のエラー と疑わしいところを指示し、Excelのスペル及び文法チェッカーとどこか似ているオプションを示す。ユーザは、疑 わしいエラーを一つずつ見て行くことができる。ダイアログボックスが、式以外、例えば、ダブルクリック/F2また は参照元表示で表示される情報も表示すれば、この機能は、恐らく、もっと強力になるだろう。 図14:ツール/エラーチェック Excelは、大きなスプレッドシートの論理構造を理解する為に用いる可視化を支援していない。スプレッドシート 21 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ の構造を感覚的に把握するために、ズームアウトできることが、(管理人注：Excelが、)この領域で唯一提供する 「ツール」である。ユーザは、画面表示縮小アイコンを選択するか、或いは、コントロールキーを押したままで、マ ウスのスクロールホイールを自分に向かってスクロールさせると、これができる。 (管理人注:サードパーティーが発売する開発または監査支援用の)商用製品は、これ以上のことができる。商用 製品は、類似した式のブロックを示したり、ブロック間のリレーションシップのエラーを表示する。多くの製品は、 これを、ワークブックの中の複数ワークシートに横断的にできる。 O'Beirneの[2005]は、Excelの内部テスト及び検査/レビューツール(及びグッドプラクティスツール全般)に関す る情報源の決定版である。O'Beirneは、彼のsysmod.comウェッブサイトで、商用製品リストの維持もしている。 製品のリストを表示するページは、"http://www.sysmod.com/sslinks.htm#auditing.Detection rates"( 管理 人注：最後の"rates"までがURL。)。 業務パッケージ 業務パッケージによる パッケージによるスプレッドシート によるスプレッドシートの スプレッドシートの置換え 置換え スプレッドシートエラーの蔓延に対して、見込みのありそうな解決策の一つは、財務報告その他の目的用に開発 されたパッケージで、スプレッドシートを置き換えることだ。例えば、ハイペリオンは、財務報告用のポピュラーな パッケージである。それは、データの連結、調整、及び報告書作成の殆どの処理を自動化する。業務パッケージ ならば、スプレッドシートの大きなウェブ(管理人注：「複雑な参照関係を持つ多数のスプレッドシート」の意味)を 避けることができる、少なくとも、可能性がある。 しかし、パッケージは、(管理人注:個々の業務に)特化しており、制限がある点に問題がある。ギリシャの劇作家 であるアイキュロスの言葉に、「狐は多くを知っている。しかし、ハリネズミは、一つの大きなことを知っている」と ある。この意味に於いて、パッケージは、ハリネズミである。企業が、その業務を行う為には、多くの個別機能 パッケージを必要とする。一つの業務パッケージで事足りる領域ならばともかく、使うパッケージの全てに熟達す るのは困難だろう。ソフトウェアの一つに関する経験が無ければ、成功は覚束ない。 業務パッケージのベンダは、よく、「エラーを起こし易い」スプレッドシートプログラムを、業務パッケージ採用の主 要な理由として引き合いに出す。しかし、スプレッドシートエラーは、スプレッドシートプログラムのできの悪い設 計が惹き起こしていると揶揄或いは明言する。事実、人が(管理人注:実現したいことを、プログラムの設計に置 き換える際に)認知的な設計上の意思決定を行う際には、用いるプラットフォームに拘らず、常に、少々のエラー が生じるものである。スプレッドシートプログラムが、異常に高いエラー率を起こすとは、経験論的には示されて いない。これらのベンダは、ユーザがビジネスロジック文を作成しなければならないことがあることを、しばしば誤 魔化している。ラフな推測ではあるが、ヒューマンエラー研究は、ビジネスロジックの2-5%程度が間違って書か れることを示している。業務パッケージは、ビジネスロジックが著しく少数でなければ、結局のところ、相当のエ ラー率を示すことを覚悟しなければならない。業務パッケージの利用は、徹底したテストを含む、注意深いシステ ム開発ライフサイクルプロジェクトプロセス(管理人注：原文のまま)の実現の替わりになるものではない。それで も、エラーは残るのである。 さらに、多くの場合、業務パッケージのカスタマイズは、外付けでなければできない。ハワイ大学のRoger Debrecenyは、2005年の筆者との個人的な通信の中で、ハイペリオン及びその他財務報告パッケージのユー ザの多くが、多くの計算にスプレッドシートを用いていること、及びそれらが、期末調整の様な、最もリスクの高い 計算であることを示唆した。 業務パッケージに対する深刻な不安の一つに、コンプライアンス要件として重要性の増しているセキュリティが ある。以下に述べる通り(管理人注:前述のセキュリティやVaultサーバに関する記述を指すと推定されます。)、 実務レベルの保護強度を持つセキュリティは、今日のスプレッドシートでほぼ可能だ。しかし、業務パッケージに 22 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ 強力なセキュリティを付加するのは、全く不可能かもしれない。或いは、技術面の大変な努力及び経営者による 強力な統制を以ってして、漸く可能となるものだ。 全体的に見て、専門家は、スプレッドシートプラットフォームに囚われるあまり、業務パッケージを検討しなくなっ てはならない。より重要なメリット及びデメリットがあるかもしれないが、業務パッケージによって、エラーを減らせ るかもしれないのだ。但し、専門家は、業務パッケージを使うことが、エラーの無い情報を提供したり、注意深い 開発及びビジネスロジックのテストの為の業務を不要としたりすると考えてはならない。 結 論 過去、スプレッドシートは、企業のITに於ける暗黒物質であった。スプレッドシートが、本社及びITのマネージャ に見えないものなので、この「暗」(管理人注:原文では"Dark")という字がぴったりだ。ITマネージャは、スプレッド シートを、単純で、(管理人注:「彼らの担当するITではなく」の意味)業務現場のものとして相手にしない。経営陣 は、スプレッドシートを、単に、たまたま、使っているものとして、無視してきた。 物理学では、宇宙空間に於ける暗黒物質の量は、可視物質よりも遥かに大きい。そして、同じことが、伝統的な ITに対するスプレッドシートにも言えるかもしれない。企業が財務報告システムを見れば、最初に見付かるの は、スプレッドシート、それも、しばしば、200或いはそれ以上の複雑に連携したスプレッドシートである。以前、21 CFR Part 11規制が、製薬会社に(管理人注：薬品の)テストプロセスの検査を強いた際に、スプレッドシートの広 範な利用が明らかにされた。さらに、図2が示す通り、多くのスプレッドシートは、極めて大きく数百、或いは数千 の個々に異なる式を含むものだった。ITに関する詳細な調査事例が概して不足しているため、企業全体に於い て、どんなにスプレッドシートが利用されているかは分からない。しかし、ビジネスロジックの個数という点で言え ば(どう計測されようと)、スプレッドシートは、古典的なITよりも広く利用されているかもしれない。 スプレッドシートが、単に、極めて重要なだけだとしても、企業は、そこに生じるリスクに対処しなければならな い。スプレッドシートの重大なエラーの頻度が高いことは、繰り返し示されている。また、不正行為及び伝統的な セキュリティ攻撃のいずれもが、コンプライアンスの点でも、一般的にも、本当の脅威である。これらのリスクへ の対処には、チームワークが必要である。IT(管理人注：担当者)は、システム開発を知っている。IT監査(管理人 注：人)は、統制を知っている。業務機能(管理人注：担当者)は、彼らの業務を理解する。これらの3つのグルー プが、スプレッドシートへの対処に知恵を寄せ合うことが必要だ。 不幸にも、開発に関する知見、統制に関する知見、業務現場に関する知見は存在するが、スプレッドシートの管 理に関する知見は稀有である。公表されている処方箋は、概して、ヒューマンエラー、不正行為及び伝統的セ キュリティ攻撃に関する研究を無視している。この論文の目的は、企業に、スプレッドシートガバナンスを考え始 める為のフレームワークを提供することである。 参考文献 ABA Banking Journal (2002, November). "Their pain, your gain: Allfirst's very public, and large, currency trading fraud loss offers many lessons for other banks." ACFE (2004). 2004 Report to the Nation on Occupational Fraud and Abuse. Association of Certified Fraud Examiners: Austin Texas. American Institute of Certified Public Accountants. (1993). Assisting Clients in Developing Policies and Procedures for Electronic Spreadsheets Applications. Consulting Service Practice Aid 93-6. 23 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ Auditing Standards Board (2002). "Statement on Auditing Standards 99 (SAS 99)." Consideration of Fraud in a Financial Statement Audit. New York: The American Institute of Certified Public Accountants. Barnard, J., & Price, A. (1994). "Managing Code Inspection Information," IEEE Software, 11(2), 55-68. Basili, V.R. & Perricone, B.T. (1993). "Software Errors and Complexity: An Empirical Investigation," Software Engineering Metrics, Volume I: Measures and Validation. Ed. M. Sheppard. Berkshire, England: McGraw-Hill International. 168-183 BBC (2002, October 24). " 'Rogue' AIB Trader Pleads Guilty to Fraud." http://news.bbc.co.uk/1/hi/business/2358463.stm. Bewig, Philip L. (1995, July 12). How Do You Know Your Spreadsheet is Right? Principles, Techniques, and Practice of Spreadsheet Styles, Copyright Philip Bewig, Creative Commons. Brown, P. S., & Gould, J. D. (1987). "An Experimental Study of People Creating Spreadsheets." ACM Transactions on Office Information Systems, 5(3), 258-272. Butler, R. J. (2000, January 4-7). "Is this Spreadsheet a Tax Evader? How H. M. Customs & Excise Tax Test Spreadsheet Applications." Proceedings of the Thirty-Third Hawaii International Conference on System Sciences, Maui, Hawaii. Butler, Ray. The Role of Spreadsheets in the Allied International Banks/Allfirst Currency Trading Fraud, 2001. http://www.gre.ac.uk/~cd02/eusprig/2001/AIB_Spreadsheets.htm Caine, David J. & Robson, Andrew J. (1993). "Spreadsheet Modeling: Guidelines for Model Development," Management Decisions, 31(1), 38-44. Cale, E. G., Jr. (1994). "Quality Issues for End-User Developed Software," Journal of Systems Management, 45(1), 36-39. Chan, Yolande E. & Storey, Veda C. (1996, December). "The Use of Spreadsheets in Organizations: Determinants and Consequences," Information & Management, 31(3), 119-134. Clermont, M., Hanin, C. & Mittermeier, R. (2000, July). "A Spreadsheet Auditing Tool Evaluated in an Industrial Context." Proceedings of the EuSpRIG 2000 Symposium, Spreadsheet Risks-the Hidden Corporate Gamble. Greenwich, England: Greenwich University Press, 35-46. Coopers & Lybrand. (1997). Description available at http://www.planningobjects.com/jungle1.htm. Contact information is available at that webpage. Cragg, P.G., & King, M. (1993). "Spreadsheet Modelling Abuse: An Opportunity for OR?" Journal of the Operational Research Society, 44(8), 743-752. Davies, N., & Ikin, C. (1987). "Auditing Spreadsheets," Australian Account, 54-56. Debreceny, Roger. (2005). Professor of Accounting, University of Hawaii. Personal communication with the author. DeCarlo, Amy Larson. (2006, August 28). InternetWeek Newsletter. http://www.internetweek.com. Durfee, Don (2004, July/August). "SPREADSHEET HELL?" CFO Magazine,CIO.com, http://www.cfoasia.com/archives/200409-07.htm. Durfee, Don (2005, September 1). "The 411 on 404: Reporting Material Weaknesses in Control can Cost Shareholders Millions," CFO Magazine, CFO.com. http://www.cfo.com/article.cfm/4315498/c_4334841?f=magazine_alsoinside. Fagan, M. E. (1976). "Design and Code Inspections to Reduce Errors in Program Development," IBM Systems Journal, 15(3), 182-211. Floyd, B. D., Walls, J., & Marr, K. (1995). "Managing Spreadsheet Model Development," Journal of Systems Management, 46(1), 38-43, 68. 24 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ Freeman, David. (1996, May). "How to Make Spreadsheets Error-Proof," Journal of Accounting, 181(5), 75-77. Gable, Guy; Yap, C. S.; & Eng., M. N. (1991). "Spreadsheet Investment, Criticality, and Control." Proceedings of the Twenty-Fourth Hawaii International Conference on System Sciences, 3. Los Alomitos, CA: IEEE Computer Society Press. 153-162. Galletta, D.F.; Abraham, D.; El Louadi, M.; Lekse, W.; Pollailis, Y.A.; & Sampler, J.L. (1993, April-June). "An Empirical Study of Spreadsheet Error-Finding Performance." Journal of Accounting, Management, and Information Technology, 3(2), 79-95. Galletta, D.F., Durcikova, A., Everard, A., & Jones, B. (2005). "Does Spell-Checking Software Need a Warning Label?" Communications of the ACM, Volume 48, Number 7, pp. 82-85. Galletta, D. F.; Hartzel, K. S.; Johnson, S.; & Joseph, J. L. (1997, Winter). "Spreadsheet Presentation and Error Detection: An Experimental Study," Journal of Management Information Systems, 13(3). Galletta, D. F., & Hufnagel, E. M. (1992). "A Model of End-User Computing Policy: Context, Process, Content and Compliance," Information and Management, 22(1), 1-28. Gosling, C. (2003). "To What Extent are Systems Design and Development Used in the Production of Non Clinical Corporate Spreadsheets at a Large NHS Trust?" Unpublished MBA thesis, University of Wales Institute Cardiff (UWIC) Business School. Grady, R. B. (1995). "Successfully Applying Software Metrics," Communications of the ACM, 38(3), 18-25. Hall, A. (1996). "Using Formal Methods to Develop an ATC Information System," IEEE Software, 13(2), 66-76. Harrison, David & Yu, John W. (1990). The Spreadsheet Style Manual, Dow Jones-Irwin, Homewood, IL 60430. Hicks, L. (1995). NYNEX, personal communication via electronic mail. Howard, Philip. (2005). "Managing Spreadsheets," White Paper. Bloor Research, Suite 4, Town Hall, 86 Waitery Street East, Towchester, Northamptonshire, NN12 6BS, UK. Howe, Harry & Simkin, Mark F. (2006, January). "Factors Affecting the Ability to Detect Spreadsheet Errors," Decision Sciences Journal of Innovative Education, 4(1), 101-122. Institute of Chartered Accountants in England and Wales. (1966). Spreadsheet Design. IT Briefing Number 6. Johnson, P. & Tjahjono, D. (1997, May). "Exploring the Effectiveness of Formal Technical Review Factors with CSRS, A Collaborative Software Review System," Proceedings of the 1977 International Conference on Software Engineering, Boston, MA. Jones, T. C. (1998). Estimating Software Costs. New York: McGraw-Hill. Kee, Robert C. & Mason, John O. (1988, February). "Preventing Errors in Spreadsheets," Internal Auditor, XLV:1. Kee, Robert. (1988, April). "Programming Standards for Spreadsheet Software," CMA Magazine, 63(3), 55-60. Kelly, Matt (2005, August 23). "Spreadsheet Blues: Few Controls Yield Many Weaknesses," Compliance Week. http://www.complianceweek.com. Kimberland, K. (2004). "Microsoft's Pilot of TSP Yields Dramatic Results," news@sei, No. 2. http://www.sei.cmu.edu/news-at-sei/. KPMG Management Consulting (1998, July 30). "Supporting the Decision Maker - A Guide to the Value of Business Modeling," Press Release. http://www.kpmg.co.uk/uk/services/manage/press/970605a.html. Lally, Laura. (1995, Summer). "Supporting Appropriate User-Developed Applications: Guidelines 25 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ for Managers," Journal of End User Computing, 7(3), 3-10. Lawrence, R. J. and Lee, J. (2004, August 26-27). "Financial Modelling of Project Financing Transactions," Institute of Actuaries of Australia Financial Services Forum. Modetn Office Technology (1994, February). "Enterprise-Wide Budgeting Demands Flexibility Beyond Spreadsheets," 40, 42. Myers, G. J. (1978, September). "A Controlled Experiment in Program Testing and Code Walkthroughs/Inspections," Communications of the ACM, 21(9), 760-768. O'Beirne, Patrick (2005). Spreadsheet Check and Control: Detect and Prevent Errors, Systems Publishing. http://www.sysmod.com/scc.htm. Panko, R. R. (2007a). Human Error Website. (http://www.cba.hawaii.edu/panko/papers/ss/humanerr.htm). Honolulu, HI: University of Hawaii. Panko, R. R. (2007b). Spreadsheet Research (SSR) Website. Panko, Raymond R. (2006c, July 5-7). "Recommended Practices for Spreadsheet Testing" EuSpRIG 2006 Proceedings, Cambridge, UK, Sponsored by the European Spreadsheet Risks Interest Group (EuSpRIG). Panko, Raymond R. (2006b August 4-6) "Compliance-Appropriate Spreadsheet Testing," Proceedings of the 12th Americas Conference on Information Systems, Acapulco, Mexico. (http://www.cba.hawaii.edu/panko/ssr/). Honolulu, HI: University of Hawaii. Panko, Raymond R. (2006a, May). "Spreadsheets and Sarbanes-Oxley: Regulations, Risks, and Control Frameworks," Communications of the AIS, 17(9). Panko, Raymond R. (1999, Fall). "Applying Code Inspection to Spreadsheet Testing," Journal of Management Information Systems, 16(2), 159-176. Panko, R. R. (1988). End User Computing: Management, Applications, and Technology. New York: Wiley. Panko, R. R., & Halverson, R. P., Jr. (1997). "Are Two Heads Better than One? (At Reducing Errors in Spreadsheet Modeling?)" Office Systems Research Journal, 15(1), 21-32. PCAOB (2004, March 17). Standard No. 2: An Audit of Internal Control over Financial Reporting Performed in Conjunction with an Audit of Financial Statements, Public Company Accounting Oversight Board. PriceWaterhouseCoopers (2004, July). "The Use of Spreadsheets: Considerations for Section 404 of the Sarbanes-Oxley." http://www.pwcglobal.com/extweb/service.nsf/8b9d788097dff3c9852565e00073c0ba/cd287e403c0aeb718 Pryor, Louise (2006, July) "What's the Point of Documentation?" Proceedings of EuSpRIG 2006, Fitzwilliam College, Cambridge University. http://www.eusprig.org. Raffensperger, John F. (2003). "New Guidelines for Spreadsheets," International Journal of Business and Economics, 2(2) pp.141-154. http://www.mang.canterbury.ac.nz/people/jfraffen/spreadsheets/index.html. Randolph, Nick; Morris, John & Lee, Gareth. (2002). "A Generalized Spreadsheet Verification Methodology," Twenty-Fifth Australisian Computer Science Conference (ACSC 2002), Melbourne, Australia. Conferences in Research and Practice in Information Systems, Vol. 4, Michael Oudshoorn, Ed., Australian Computer Society. Read, Nick and Bateson, Jonathan (1999). Spreadsheet Modeling Best Practices, Business Dynamics, 1999. Copyright Institute of Chartered Accountants of England and Wales. RevenueRecognition.com. "The Impact of Compliance on Finance Operations," Financial Executive Benchmarking Survey: Compliance Edition, 2004. (www.softtrax.com.) Rothermel, G.; Burnett, M.; Li, L.; Dupuis, C.; & Sheretov, A. (2001). "A Methodology for 26 / 27 2007/05/01 19:27 スプレッドシート統制 研究室: Panko博士の最新ワーキングペーパー 公開サイトURL: http://linkfinder.cocolog-nifty.com/ Testing Spreadsheets," ACM Transactions on Software Engineering and Methodology, 10, 110-147. Russell, G. W. (1991). "Experience with Inspection in Ultralarge-Scale Developments," IEEE Software, 8(1), 25-31. Schultheis, R., & Sumner, M. (1994). "The Relationship of Application Risks to Application Controls: A Study of Microcomputer-Based Spreadsheet Applications," Journal of End User Computing, 6(2), 11-18. Seymour, Jim. (1988, March). "Twelve Steps to Better Spreadsheets," Office Today, 19(10), 39, 40, 43. Speier, C., & Brown, C. V. (1996, January). "Perceived Risks and Management Actions: Differences in End-User Application Development across Functional Groups," Proceedings of the Twenty-Ninth Hawaii International Conference on System Science, Maui, Hawaii. Takaki, S. T. (2005). "Self-Efficacy and Overconfidence as Contributing Factors to Spreadsheet Development Errors," Working Paper. Information Technology Management Department, College of Business Administration, 2404 Maile Way, Honolulu, HI, 96822. TMCnet.com (2004, September 20). "European Companies are taking a faltering approach to Sarbanes-Oxley." http://www.tmcnet.com/usubmit/2004/Sep/1074507.htm. United States Department of Justice (2002). United States of America v. John M. Rusnak. SMS/SD/USAO #2002R02005. http://www.usdoj.gov/dag/cftf/chargingdocs/allfirst.pdf. Vorhies, J. B. (2005, May). "The New Importance of Materiality," Journal of Accountancy (online). http://www.aicpa.org/pubs/jofa/may2005/vorhies.htm. Weller, M. (1993). "Lessons from Three Years of Inspection Data," IEEE Software, 10(5), 38-45. Wittig, Glenn R. (1990). "Spreadsheet Design: Role of Introductory Documentation in Creating Spreadsheets," Library Hi Tech, 30(1,2). * * * 以 上 * * * 27 / 27 2007/05/01 19:27