「httpdは停止していますがサブシステムがロックされています。」

この3連休をすべて費やしてしまいました。



何度立ち上げても、起動直後に、こうなるのです。



「error_log」はなーんにも出力されない。

/var/log/httpd/の下。



この時点で、気づくべきでした。

ログが出ないなんておかしすぎると。



ログはね、出ていました。探したら・・・

/etc/httpd/logs/

の下に。


あ、シンボリックリンク・・・


そうです。


私、httpd.conf 類を書き換えるのがめんどくさかったので、横着をして他のインスタンスから、
/etc/httpd/の下をすべてZIPで固めて持ってきたんです。

で、すべて解凍。


シンボリックリンクが実ディレクトリに置き換わってしまったんですね。


そのせいで、/var/run/のpidが書き込まれなくて、
httpdが起動しているにも係わらず、
起動していない扱いに・・・






あまりにも長くはまったので、書いておきます。


お休みが終わっちゃったよ。台風で遊びに行けなかったのが、せめてもの幸い。

次はIFRSs

10月からの組織改正でグループをひとつ任せられることになりまして、
職務分掌はIFRSs／内部統制・・・

これで何かビジネスをしろと・・・




さて、何して稼げばいいのやら。

アイディア募集中です。

クラウドの闇

前回、クラウドは中小企業にとって『美味しい』サービスですよとお話しました。

今回は、クラウドの『闇』部分についてお話します。


Googleをご存知ですか？Googleは実に多様なサービスを無料で利用者に提供しています。（利用すると、広告が目に触れて、広告主から広告料を取っているということですが）
たとえば、Mailサービスでは何GBものメールボックスを保有することができます。
ファイルを預けておくことになるサービスも多種あって、Googleが無料で提供しているディスクスペースは天文学的な数字になるでしょう。

Googleはこれを独自のノウハウで低コストで運営していけるのでサービスが成立するのですが、人件費が高い国にセンターを構えて・・・ではないことはわかりますよね。
安定電源の供給とかのインフラ面も考えると、人件費が安いだけでデータセンターを設置できるわけでもないですから、
まさに、どのようなハードウェアを購入して、どこにセンターを設置して、どういう人員で運用するかというのはそれだけで金がとれるビジネスノウハウです。

さて、つまり、Googleに預けた私の画像データは物理的にどこの国の誰が管理しているかは私にはまったく不明なのです。
ある日突然、ぱっと消えてなくなってしまったり、全世界に流出してしまったりしなければ、どこにあるかなんて知らなくてもなんら問題ないわけではあります。

しかし、これが、公共の情報だったらどうでしょう？

たとえば、住民情報のシステムを各自治体で独自に構築しているのは、あほみたいな多重投資なので、県でSaaSとして提供しましょう！
なんていうのが、誰でも思いつきそうなサービスです。
県でできるなら、日本全国でひとつでいいじゃないか・・・という考え方もありますよね。

本来のSaaSの考え方でいけば、利用者はそのデータがどこに格納されて、誰がどのように運用しているかなんて関係なくて、
サービスが何曜日の何時から何時までが利用可能で、年間に何時間利用できる・・・ということだけを気にすればいいわけです。


しかし、住民情報・・・本当にそれでいいですか？


そのSaaSがのっかているIaaSは、センタはどこにあって、誰が運用しているんでしょうか？
センタの『どこ』は１箇所ではないでしょう。仮想的に１箇所として扱えるというだけで、物理的にはインターネット上のどこでもいいんです。
南アフリカだろうが、ガラパゴスだろうが・・・


どう思いますか？

クラウドの話

IT業界では最近の流行は『クラウド』ってことになっていて、猫も杓子もクラウドなわけです。

ま、まさに雲をつかむような話なんですけど、要するに
『所有』から『使用』というのがトレンドです。

ネットワークインフラが発達したので、実態は、ネットの上に『雲』のように浮かんでいてもいいよねぇ・・・という考え方ですが、

SaaS　アプリケーションをサービス単位で課金提供
PaaS　アプリケーション作成のためのプラットフォームなどのサービス単位での課金提供
IaaS　ITインフラの課金提供

と言う構図で、
SaaS事業者がPaaSで提供されるプラットフォームを活用してサービス提供したり、
PaaS事業者がIaaSで提供されるインフラを利用していたり・・・

と、言う形態が可能なわけです。
つまり、事業者も小さな初期投資で『サービス』の提供が可能となるということ。

これまでのASPサービスは、プロバイダーがハードからインフラ、プラットフォームを丸がかえしていました。
ユーザが利用しやすいように、低価格でサービス提供しようとすると、多数のユーザを集める必要があります。
それなりのセキュリティ投資や、継続稼動のための設備投資が必要になります。
しかし、立ち上げ当初からそんなに大量のユーザが集まるわけではありませんから（通常は、稼動実績がある程度経過しないと『利用しても安全』と判断できませんよね。）、初期は赤字覚悟でランニングする必要があります。
それなりの資金力がないとASPの立ち上げはできないわけです。

これをPaaSを利用して開発しIaaSを利用して提供するならば、サービスの種類あたりでの採算ラインを低く抑えることができるのです。

利用者側は、ASPであれSaaSであれ自前のサーバー（ハード）や、データを保持せずに、サービスの提供のみを受けるという形態は一緒ですが、上記の理由から、サービスの種類が多くなることが期待できます。
所有しないことから、資産として償却せずに経費処理できます。
運用のための人員も不要です。

クラウドは、利用者も提供者も中小企業に有利になると言えると思いませんか？

IT内部統制の実務～業務処理統制の運用状況の有効性評価

総論：

テストできなければ、有効性の「評価」は完結しない。

【運用テスト手続を「整備状況の評価」の段階で考えることの重要性】

運用テスト手続の妥当性を「整備状況の評価」の段階で吟味しておかないと、運用状況の評価の段階に来てから、手戻りになるリスクがある。手戻りの原因は、「実際にはテストが出来ない」という「見込み違い」や、「テスト手続が妥当ではない（照合の方向が違う、資料間の照合を行っていない、母集団の網羅性と正確性が確かめられていないなど「意味がない」）」として「テストやり直し」とされるなどである。

【テスト手続の三つの構成要素】

（１）種類（内容）－どんなことを
　　　実行可能性、照合の方向、母集団の特定、エラーの定義　に注意要
（２）時期　－どのタイミングで
（３）範囲（件数）－どのくらい

照合の方向：

【順進と逆進】

テストは殆どが「照合」という手続に落とし込まれるが、その照合の方向には「順進」（「事実から帳簿へ」＝「発生から記録へ」という時間の流れと同じ方向）と「逆進」（「帳簿から事実へ」＝「発生から記録へ」という時間の流れと逆の方向）の二つの方向がある。

【逆進が求められるケース】

１．「実在性」目的の照合では、順進ではなく逆進でなければ意味がない。なぜなら、発見したいのは「帳簿にあって、事実はない」というもの（事実を伴わない帳簿記録）だから。
２．「事実」「実体」との照合のできない取引は、その正確性・正当性を「承認」に大きく依存している場合が多い。ということは、その「承認」の漏れがない、と言う心証を得るような手続（＝承認漏れがあれば見つかるような手続）を実施する必要がある。その手続は、申請書上だけで承認の有無をテストしても意味がないし、申請書からサンプル抽出しても意味がない。（見つけたいのは承認なし、そもそも申請なしにエントリされた情報）
３．承認が重要性を持つ場合のテスト手続においては特に、承認証跡さえあればＯＫとするのではなく、承認者が承認要件を守っているかどうかも、テストの対象とすることが必要である。

【順進が求められるケース】

「網羅性」目的の照合では、順進でなければ、意味がない。なぜなら、発見したいのは、「事実はあるのに、帳簿にない」というもの（帳簿に反映されていない事実）だから。
一般的には「負債科目」の過小計上を防止・発見するための統制活動となる。

母集団の適格性：

１．テスト手続策定において、母集団に関して明確にすべき事項
（１）どのような母集団であるかの明示（例：ＸＸ月ＸＸ日付けのＸＸＸリスト）
（２）なぜその母集団でよいのかの説明
（３）その母集団の適格性を確かめる手続

２．母集団の適格性に関するポイント
（１）母集団自体の網羅性（いくつあるのか／それで全部か）
（２）一つの母集団の中の、明細情報の正確性と網羅性

３．母集団の中の、明細情報の「網羅性」について心証を得るための手続の一つは、その母集団の合計金額を再計算し、「しかるべき財務数値に照合することである。

４．母集団の中の、明細情報の「正確性」について心証を得るための手続の例は、その母集団の合計の再計算や、明細を何件か原票や関連帳票に照合するなどである。

【母集団の中の網羅性】

１．悪魔の証明（あることが『全くない』ということを、証明することは、世の中のすべての事象・事実を確かめなければ言えないので、現実的には不可能であるというもの）という考え方にあるように、「帳簿から漏れているものはない」と証明するのは無理。
合理的な保証を得るという観点から、「見つかりうる方法（テストの目的に照らして「意味のある」テスト手続）」であればいい。

２．マスタファイルや全般統制関係のような非財務情報は、ストックの概念（ある時点における断面）の明細は確保できても、フローの概念（ある期間の取引明細・更新履歴など）の明細は確保できない場合がある。

３．内部統制そのものは従来から存在するはずのものであるが、その「有効性評価」というものが義務付けられたために、その有効性の検証が求められるようになった。

４．つまり「全部しっかりやっています、ということを第三者に示すことが出来る」かどうかが重要である。それが出来ないのであれば「有効ではない」という結論となる可能性がある。

テストの実行可能性：

「自動化された統制活動」のテストは、ＩＴ側に丸投げするのではなく、どの統制活動をテストすべきか（業務側が詳しい）と、それをどのようにテストできるか（ＩＴ側が詳しい）とについて、両者で協働して詰めていく、というやり方が望ましい。

エラーとは何か：

１．エラー定義（サンプルテストにおいて、それが所定件数以上見つかると統制に「運用上の不備がある」と判断されるもの）をある程度は事前にしておかないと、有効性評価の結論の誤りや不整合だけでなく、本来不要なコストを生み出す危惧がある。

２．エラー定義は事前に完全に出来るものではないので、事例を蓄積しておき、共有するとともに、それを絶対的なものと見なさず常に議論しつつ見直していくといった工夫が必要である。

３．照合時の不一致の許容度の違いも考慮に入れる必要がある。

４．運用テスト段階で「エラー」が頻発したら、まず疑ってみるとよいのは、「実はそもそもルールがないのではないか？」、あるいは「ルールがあっても明確ではない・伝わっていない・不足であった」ということである。つまりある意味、整備状況の有効性評価への手戻り、ということになる。これを防ぐ意味で出てきた工夫が、「運用テストの1件前倒し」である。

ロールフォワード：

【会計監査におけるロールフォワード】

（１）必要件数のサンプルテストは期中に済ませ
（２）それ以降の期末日までの期間については「内部統制に重要な変更がないこと」を確かめるための最低1件のテスト（ウォークスルーなど）を期末日後など適時に行うことで補完する。
（３）しかも「それ以降の期末日までの期間」が一定期間内であれば、テストを省略し質問・観察等で済ますことも認められている。

ただし、（３）は前提条件として
（あ）もともとその期間中に「内部統制の重要な変更」が予定されていない
（い）期末実証手続で入手する資料や情報によって、実際に「内部統制の重要な変更」がなかったという心証をある程度は得ることができる。
（う）当然のことだが、そもそもその内部統制は有効である。

母集団の「束ね」：

ＩＴ内部統制に固有のポイント＝自動化された統制活動は、手作業の統制活動よりも「束ね」が合理性を持つ場合が多い。支店・営業所など場所が異なっても、それを司っているシステムが一つであれば、一箇所でテストすればいいということになる。

IT内部統制の実務～業務処理統制の整備状況の有効性評価

総論：

「整備状況の有効性評価」での作業を「規定の有無を確かめて終わり」「現状をフローチャートやRCMに書いたら終わり」と考えていたのでは、運用テストができないだけでなく、「有効に出来ない」ことが懸念される。

「整備状況」と「運用状況」に分けて有効性評価を行う理由は、理論的にはともかく、実務的に見ると2点考えられる。
１．「運用状況の有効性評価」はいってみれば本番であり、多数のサンプルテストを行う。これをスムーズに行うためには「下見」と「練習」が必要である。
２．「不備」を改善する場合の影響範囲やコストは、「整備状況」に関連するｍののほうが大きいと思われる。システムや体制などの修正が必要になる可能性があるからである。

整備状況の有効性評価とは：

「整備状況の有効性評価」の目的は、実務的にはキーコントロールを選定する（運用テスト「すべき」で、且つ運用テスト「できる」であろう統制活動を絞り込む）ことだと言える。

【整備状況の有効性評価の構成要素と進行】

（１）現状の文書化「こうなっているはず」
（２）評価その１「RCM上での分析」
（３）ウォークスルーによる実地確認「要改善？」
（４）評価その２「運用テストの1件前倒し」
（５）整備状況「有効」の判定（４）で要改善じゃなければ

取引フローの現状の文書化：

デザイン＝「こうなっているはず」という「仕組み」

文書化の着眼点＝リスク発生源である「情報の変換点」
※ここでいう「情報」は仕訳の構成要素となる情報である。（つまり、勘定科目、経常日付、金額）

RCMによる分析：

デザイン評価、およびその結果としての「キーコントロールの選定」においては、統制活動ごとの（１）強弱（２）広狭（３）補完関係に注目する必要がある。
この点でRCMのマトリクス（行列）形式は有意義である。

【キーコントロールの具備要件】
１．強弱、広狭、保管関係、等を考慮して、「リスクを軽減する費用対効果」が高い強制活動であること。
２．テスト手続が意味のある形で、かつ実行可能である統制活動であること。
３．以上の両要件を満たせば、その統制活動は「テスト対象とする費用対効果が高い統制活動である」と言える。

【統制活動の「強弱」の着眼点】
１．業務には例外処理などの想定外処理がつきものだが、防止的統制ではこれに関連する『漏れ』が防げない場合が多い。また内部統制の限界の一つである人間の注意力の限界というべきヒューマンエラーも防ぎきれない。
２．発見的統制は以上のような点を補完できるが、事後に発見できても意味がないという場合もあるし、発見できても原因特定できない場合も多い。

【統制活動の「広狭」の着眼点】
守備範囲が「広い」統制活動は、効率的な統制活動であるから、これをRCMによる分析で洗い出す小t個によって、運用テストなどの有効性評価作業の効率性を大きく向上させることが可能である。

【統制活動の「強弱」と「広狭」：「マクロな統制」の認識】

既存のビジネスリスクに対処するための統制活動は、取引ごとの「防止的」な統制が多く、取引複数に包括的に網をかける「発見的」統制が少ない。
「財務諸表に重要な虚偽記載がない」という目的に照らすと、上記の既存の統制活動は効率が悪い可能性が高い。
マクロな統制は、管理者レベルの統制であるため、効率良く、テスト「すべき」だが「できる」といいきれないところが問題である。

【キーコントロール選定に関する補足】

１．キーコントロールの選定において、「自動化された統制活動」と手作業の統制活動とは、同じプールに入れて検討すべきである。
２．統制活動の「広狭」の検討は他の取引フローとも共通かどうかの検討も忘れずに。
３．防止的統制と発見的統制とは、完全に代替がきくものか？吟味が必要。
（どちらか一方のみへの依存は不健全）

実在実務確認（ウォークスルー）：

【ウォークスルーの目的】

ウォークスルーの目的は、文書の記載内容の確認であると言えるが、記載内容には統制活動も含まれる。この記載が正しいかどうかを確認するのだから、と時点統制テストの性質を持つ。

【ウォークスルーと「運用テスト」の違い】

ウォークスルー＝ある時点におけるその統制活動の実在を評価対象として、順進方向に照合し、1件をサンプルとして、対象の統制活動を多めに実施する。
運用テスト＝ある期間にわたる、その統制活動の継続を評価対象として、順進、逆進のどちらの照合もあり得る。サンプルは複数件であり、対象となる統制活動は、ウォークスルーに比較すると少ない。（キーコントロールのみ）

【ウォークスルーは必須か？】
１．ウォークスルーの実施は必須か？
　法的には経営者の裁量に任されている。
２．実施するとして、毎年実施する必要があるのか？
　変更がなかったということを確かめるのもウォークスルーである。変わっていないということを評価者が確かめ、その記録・証跡を残すことが必要である。

【ウォークスルーと運用テスト1件前倒しの違い】
目的が違う。
ウォークスルーは統制活動が「実在するか」を確認することが目的であり、1件テストは運用テストが「実行可能であるか」を確認することが目的である。

IT内部統制の実務～業務処理統制のスコーピング

総論：

１．キーコントロールとは、「運用テスト」（期間にわたる有効性の検証）対象となる統制活動のこととする。

２．財務会計数値の生成過程全体を「取引フロー」、その実際の処理や統制活動を受ける各局面を「プロセス」と呼ぶ。

３．キーコントロールとなり得るか（財務報告目的で重要な役割を負っているのか）は、会計仕訳までつながる「取引フロー」として、「プロセス」を「つなげて」認識しなければ判別できない。

４．どの業務処理統制（の中の「自動化された統制活動」）をテスト対象にするかは、その取引フローにおいてどの「自動化された統制活動」がキーコントロールであるかと、同義である。

５．ある業務システムの提供する「自動化された統制活動」が、一つもキーコントロールではないとしたら、その業務システムの全般統制は、有効性評価の対象とする必要がなくなる。

取引フローとしての「つながり」：

内部統制記述の文書の（担当組織ごとの）「プロセス」ごとの細分化は、作業実務上やむをえない。ポイントは、それらの文書を「つなげる」ことができるかである。
なぜなら、仕訳に結び付けて考えなければ、どれが重要であるか判断できないはずだから。
「財務報告に係る内部統制」の有効性評価という観点からは、プロセスにおける活動を常に仕訳に結び付けて考えなければ、リスクにせよ統制活動にせよ、どれが重要なのか、特にキーコントロールが何か、を的確に判断しにくくなる可能性が高い。

取引フローの終点＝分析の起点：

「T字分析」（勘定科目ごとの「仕訳パターン」の洗い出し）等による仕訳数値の構成要素分析によって、仕訳パターン別の金額を把握して、量的・質的に重要なものを判別した根拠とする。その仕訳数値の生成過程が「取引フロー」となる。

取引フローの「束ね」：

認識された「取引フロー」の数々は、あくまで「仕訳」としては別のものだったというだけで、その数値生成過程である「取引フロー」上の内部統制は同じかもしれない。
「束ね」られるものなら「束ね」て評価作業のボリュームをへらすにこしたことはない。

「束ね」についてある程度の基準の枠内で迷う場合は、とりあえず「分けて」であれ「一つにして」であれ進めてみて結果で判断するしかない場合もある。この見直しをかけるタイミングを前もって決めておくことも重要である。

取引フローの「始点」：

取引フロー（財務会計情報の生成過程）の、「どこが始点になるか」は、「どこまで遡るか」、つまり「どこまで『しばり』があるか」で決まる。

始点と終点の間に含めるプロセス：

仕訳から逆進して把握した取引フロー上に出てこないプロセスは、仕訳数値に対する直接の関連性は低いと解釈できる。

IT内部統制の実務～IT内部統制の実務とは

リスクベースであること：

必要とされる統制は「リスク」次第で異なり、その「リスク」は企業活動の「環境」と「目的」次第で異なる。

必要とされる統制について、上記の連環による合理的な絞込みや優先度を重視し、必要以上の現場負担が生じることを防ぐアプローチをリスクベースと呼ぶ。

【内部統制の目的の優先度付けの必要性と優先度付けのための判別の必要性】

プロジェクトの対象を「財務報告目的」以外にの目的の内部統制にまで広げる場合には、目的間の優先度付けを可能にしておくことが、プロジェクト管理上も、実際の監査対応の上からも、重要である。

１．従業員としても経営者としても、内部統制プロジェクトを「どうせやるなら」業務改善・品質向上に結び付けたいと思うのは自然なことでもある。

２．「財務報告目的」内部統制への優先度付けを推奨する考え方は、それを否定するものではない。要は、目的ごとのリスクや統制の違いを判別できることが重要である。

【「目的」と「リスク」が重要である理由】

１．「最低限これさえ守っておけばいい」という共通の基準・ガイドラインないしは「静態的な」達成目標（値）はない。「動態的な」プロセスの継続運用が発生目標と言うことになる。

２．やっていることの意義や合理性を見失いそうになったら、「目的」と「リスク」が何であったか、に立ち戻ることが有効である。

【統制ベースではなくリスクベースに】

「統制ベース」だと、「リスクがないから、明らかに必要がない」といような統制までも、必要かのごとく思い込む懸念がある。


全般統制と業務処理統制の関係：

【全般統制と「自動化された統制活動」と業務処理統制の関係】

業務処理統制の中の「自動化された統制活動」の、「時点における有効性」を、「期間にわたる有効性」へと引き伸ばす方法の一つが、全般統制である。

【IT固有の「反復性」の活用】

内部統制が「有効である」と言えるためには、「期間にわたる有効性」の検証が必要であって、ある時点のみの有効性の検証だけでは不足する。
したがって、普通は「複数件の直接テスト」が必要になるはず。
しかし、業務処理統制に含まれる「自動化された統制活動」に限っては、サンプル1件の有効性を「期間全域へ引き伸ばす」ための別の統制＝全般統制が有効に働いている場合は、サンプル1件のテストで事足りる。
「変えない限りは繰り返す」はずだというIT固有の反復性に着目するのが全般統制である。

【全般統制は目的ではなく手段＝＝＞コスパ考慮要】

「手作業の統制活動」であれば「期間にわたる有効性」を検証するには、期間全域にわたる母集団から抽出した複数のサンプルを検証するしか方法はない。しかし「自動化された統制活動」であれば、他にITならではの反復性を提供する統制（すなわち全般統制）の有効性を検証するという方法もある。

【全般統制に依存する費用対効果】

全般統制（の有効性に依存すること）の費用対効果は、その全般統制プロセスが、どのような「キーコントロールとなる自動化された統制」（を提供しているアプリケーション）をサポートしているか、で決まる。

「内部統制監査」と他の監査・認証等との関係：

【会計監査と内部統制監査とにおけるIT内部統制】

類似の実務
（１）会計監査の中の財務報告目的の内部統制の有効性評価＝＝＞対象期間全域にわたる有効性が求められる。
（２）米SOX404条適用会社において、同監査に備えた、財務報告目的の内部統制の有効性評価
（３）「日本版SOX法」における「内部統制監査」に備えた、財務報告目的の内部統制の有効性評価＝＝＞期末日基準での有効性が求められる。

【内部統制の評価実務の差分：「会計監査」と「内部統制監査」

●評価基準（厳しさ）は同じ＝＝＞目的が同じだから
●対象範囲も同じ＝＝＞目的が同じだから
●対象範囲の違い＝＝＞小規模会社などで、監査戦略次第で有り得る
会計監査人がその都度「実証手続き」を実施して内部統制の有効性に「依拠しない」選択が会計監査上は有り得る。（件数が少なくて、そのほうが安上がりな場合）
●手続種類の違い＝＝＞内部統制監査での追加：会社側の手続も評価対象
増分は
（１）企業自身によるテストの手続と結果
（２）上記テストの前提となった分析資料（RCM等）

「会計監査」と「内部統制監査」とを比較した場合に、
１．評価基準と対象範囲は同じ。目的が同じだから。
２．対象範囲は小規模会社などで、監査戦略故の違いは有り得る。

【ダイレクトレポーティング不採用」についての誤解

ダイレクトレポーティングは不採用だがテスティングではない。
レポーティングとは監査報告のことを言っている。米SOX404条対応では、内部統制について外部監査人は二つの報告をしている。（１）「経営者による内部統制評価」に関する監査意見（２）「自らの独自に行う内部統制評価」に基づく監査意見　であるが、ダイレクトレポーティング不採用とは、（２）をなくそうという話。

外部監査人による直接の理解と評価のための直接テストはなくせない。
しかしながら、外部監査人の「直接のテスティング」の範囲が、（１）の範囲（つまり経営者による内部統制評価の実施範囲）に限定されることが狙いである。
ということは、その対象範囲については、事前に企業と外部監査人で合意しておく必要がある。

【IT関連の認証（ISMS/ISO27000、BS7799等）との関係】

１．直接的には、監査（審査）結果やテスト結果を流用できる等のアドバンテージはない。（目的も手続きも異なるから）

２．間接的には、認証のおかげで整備された内部統制の「実体」が、「結果として」監査対応や監査結果に貢献することはあり得る。


【「システム監査」との異同および「内部監査」との異同】

「システム監査」における相違点
１．目的が自由
２．対象選択や手続き内容が自由

「システム監査」における共通点
１．手続種類＝＝＞決まり方が異なるが結果として同じ手続きが選ばれる場合（定番の手続き）

「内部監査」における相違点
１．実施者が限定されるが、目的や対象選択、手続内容はシステム監査以上に自由

「内部監査」と「IT内部統制の有効性評価」との関係

・手続内容（手続種類、時期、範囲）
・その手続を実施する内部監査人のスキル・経験
について外部監査人側の要件を満たせば、内部監査結果に「依存」できる。


１．「システム監査」と「IT内部統制の有効性評価」には、手続に同種のものも多いが、後者の目的ではテスト上の制約がある。

２．内部監査の手続や結果を外部監査に流用するには、内部監査計画段階における内部監査人と外部監査人との意思疎通が重要である。



社外への委託業務：

【社外への委託業務に関する論点】

もともとの原語「外部委託」の「外部」は「サードパーティ」であり、グループ内のシェアード・サービスは含まない。
日本企業を意識した場合、グループ内も含む「社外」委託管理としている。

【社外への委託業務に係る内部統制監査報告書とは】

日本基準では「18号（監査基準委員会報告書第18号　委託業務に係る内部統制の有効性の評価）」、米国基準では「SAS70（米国監査基準書　Statement Of Audit Standards　第70号）」と略称される監査報告書があり、内容は実質上同じもの。
受託側、委託側、監査人の効率化のために、受託業者の内部統制に関する監査手続の定型化を行い、その報告書を委託元企業に配布することで、委託元企業ごとの監査人による監査の繰り返しに代替しようとする仕組み。

【社外への委託業務だというだけで特別な対応が必要か？】

１．まずそもそも「文書化・テストの対象」であるかどうかをチェックする。
２．次に「普通に」文書化・テストができないものかを考える。


エンドユーザコンピューティング：

【EUCであることと、評価対象にする／しないは無関係】

※EUCとは、システム部の管理下にないデータ処理形態の総称とする。

１．EUCであろうとなかろうと、有効性評価の対象になるかどうかは、まず重要勘定からトップダウンで導いた取引フロー（仕訳数値の生成過程）に載ってくる統制活動であると言うことが最低条件であることに変わりはない。
２．マクロやクエリー利用により「自動化された統制活動」であると言えるとしても、時点統制テスト対象（キーコントロール）に該当しなければ、全般統制の有効性評価対象とはなり得ない。

【それは本当にキーコントロールなのか？】

キーコントロールの選定は「そこで間違ったらもう誰も気づかないのか？」という点をよく吟味する必要がある。

IT内部統制の実務～IT内部統制とは何か？

総論：

【IT統制の定義とイメージ】

１．ITの統制とは、ITを取り入れた情報システムに関する統制であり、自動化された統制を中心とするが、しびしば手作業による統制が含まれる。

２．財務報告の信頼性に係るITの統制は、会計上の取引記録の正当性、完全性及び正確性を確保するために実施される。

３．金融商品取引法による内部統制報告制度においては、財務報告の信頼性以外の他の目的を達成するためのITの統制の整備および運用を直接的に求めるものではない。

【ITの統制　全般統制と業務処理統制】

「IT内部統制」のに大分野は全般統制と業務処理統制である。

原文ではGeneral　Controls　と　Application　Controlsでそもそも対応関係がない。
本来は、IT全般（共通）統制に対比してのIT個別処理統制であったと思われる。

全般統制とは何か：

【実施基準「ITに係る全般統制」の定義】

「ITに係る全般統制」の定義上のポイントは、一つは業務処理統制との関係において捉えられていること、もう一つは複数の業務処理統制ないしシステムに関係しているとされていることである。

【「ITに係る全般統制」に関するいくつかの注意事項】

全般統制もプロセスである。「統制」と呼ばれるからには何らかの「リスク」に対応するものであり、それは何らかのプロセスにおいて「何かを誤る可能性」から生じている。

業務処理統制とは何か：

【実施基準「ITに係る業務処理統制」の定義

業務処理統制とは、業務プロセスに組み込まれたITに係る内部統制であると言える。
業務処理統制には、「手作業」（ITに依存し、人手とコンピュータ処理が一体となって機能している場合も含む）による場合と、「プログラムに組み込まれて自動化」されている場合がある。
統制活動が自動化されていても、テストは「手作業」でできる場合がある。

トップダウンであること：

評価対象システムの識別はゴール（財務諸表）からの逆算により、演繹的に行う。

財務諸表項目の「重要勘定」からスタートし、この数値を増減させる「仕訳」の生成過程である「業務プロセス」をつなげた「取引フロー」を確保し、その「取引フロー」上に出現する「自動化された統制活動」を提供する「アプリケーション」がITに係る業務処理統制の有効性評価対象となる。そして、このアプリケーションを束ねるシステム基盤がITに係る全般統制の有効性評価対象となる。

Ｊ－ＳＯＸ覚書

【根本的な誤解 】

内部統制といわゆるJ-SOXを混同している方が多い。

「内部統制」と言った場合には、「会社法」に定められているものと「金融商品取引法」に定められているものがあって、いわゆるJ-SOXは後者のこと。

今度の4月から施行！と騒いでいるJ-SOXは、「金融商品取引法」に定めているほうで、その目的は、株主が誤った財務諸表を見て、誤った投資判断をしないために、「財務諸表がちゃんと作られていますよ」ということを担保すること。だから、実務手続は「財務報告に係る内部統制」を経営者に評価させてその、報告書を開示させ、それを監査人が監査して監査報告を作成するということ。

つまり、財務報告に係らない部分はいわゆるJ-SOXには含まれません。

「個人情報の保護」とか、「法令遵守」とかは内部統制としてあるんだけど、J-SOXの範囲ではありません。

【心証の形成】

Ｊ－ＳＯＸに関する書物ではしばしば「心証」という用語が出てきます。
ここでいう心証とは、会計監査用語としての「心証」であって、一般的な「心証」とは、若干、意味合いが異なります。

会計監査用語的には、
「心証」は形成するものであって、良かったり、悪かったりするものではありません。

ですから、会計的には「心証」が悪いということはなく、
心証は「得られる」か「得られないか」
というものです。

会計監査用語でいう「心証」とは、
「だいたいＯＫ」
という意味なのです。
つまり、詳細に見ていけば少しくらいは問題があるかもしれないけど、大局的に見地から言えば、正しいと言えるでしょう！
という状態が「心証を形成できた」と言います。


で、Ｊ－ＳＯＸの文書化とは存在するはずの内部統制について（存続している上場企業の規模の会社において、内部統制がまったく機能していないとか、そもそも「ない」とかはあり得ないでしょう）、監査人の『心証』を形成するための手続なのです。

【検証可能性】

心証の項でも書きましたが、『内部統制』そのものは従来から存在しているはずです。

J-SOXではその「内部統制」が有効に機能していることを経営者が評価して報告することが『義務付け』られました。

「有効性評価」が義務付けられた時点で、「内部統制」は「それを検証できるか」という検証可能性が問われるようになったのです。
検証とは、「全部しっかりやってます」ということを第三者に示せるかが重要なのです。

検証できないとすれば「全部しっかりやっていた、と言い切れない」ということになり「有効ではない」と結論付けられる可能性があります。

最近、Ｊ－ＳＯＸ対応と謳っているソフトウエアが実は、すべての操作記録をログに残しておくだけだったりするのですが、これは「検証」の可能性を提供しているという点で、Ｊ－ＳＯＸに対応できる可能性があるということを言っているのです。
ログが残らないソフトウエアを使っていたとしても、他の方法で検証できればＪ－ＳＯＸに対応することは可能です。

【アサーション】

実在性
　架空じゃなくて、本当のこと
　（今期末に予算達成のために受注計上しておいて、来期早々に受注取り消しとかダメですから。）

網羅性
　もれなく

権利と義務の帰属
　他人のじゃなくて、自分の
　（例えば、別部署の売上を上げちゃうとか、子会社の売上を自分の会社の売上みたいに計上しちゃうとかはNG）

評価の妥当性
　サバをよまずに
　（10人月の工数を投入したからって、必ずしも仕掛が10人月じゃないよねぇ。）

期間配分の適切性
　遅れず、早すぎず
　（赤字確定するのが嫌だから、すでに納品済なのに売上を計上しないで、来期の仕掛にしておくなんてNGでしょ！）

表示の妥当性
　飾らず、ありのままの姿で
　（容姿端麗、成績優秀・・・・）

J-SOX文書化ソリューション

タイトルは、今週から私が携わっている仕事です。

お客様の所へ行って、お客様にお話を聞きながら、その場で、いわゆるJ-SOXの文書化3点セットの業務フローを書きます。
1日3から4の業務プロセスについて、記述します。

インタビューは二人一組で、一人が業務フローを作画。一人が、お客様の話を誘導しつつ、メモを取ったりします。
お客様は、内部統制の事務局が立ち会って、文書化のノウハウを学び、プロセスオーナーが選出した現場の責任者と、実担当者がインタビューに応えます。
大体、1プロセスのヒアリングは1時間から2時間です。

現場の担当者はなかなか口が重いので、「こんな感じですよね」とテキトーにでっちあげて「いえいえ、ちがいます。こうです。」という感じで口を割らせます。
現場の責任者は、「やばい」箇所を隠そうとか、統制のプロセスを追加することに抵抗を示すので、この辺のさじ加減もびみょーです。
また、まじめな責任者だと、やたら詳細な記述でないと不満なようですが、詳細に書きすぎると、将来的にお客様の仕事を増やすことになるので、テキトーに丸めながら書くのも難しいところです。

現在は、チーフコンサルタントではなくアシスタントコンサルタントの役割なので（なにしろ、初めてやる仕事だし）、お客様の誘導と、話の整理に専念していますが、チーフはフローを書きながら、お客様とお話しながらなので、大忙しですね。
時間がなくなってくると、一人二役でりゃん面でヒヤリングして、スピードを倍増することになるんでしょうね・・・

で、1日6時間6プロセス。平均的な200プロセス（弊社は400プロセスらしい）を書き上げるには、200時間。これにリスクコントロールの定義も加えると2ヶ月弱というところですか。


J-SOXのスタートまで早い会社で6ヶ月を切りました。

依頼するなら早いもの勝ちかもしれません。

モバイルソリューション

今日は暴風雨にもめげず、「モバイルソリューションフェア」に行ってきました。

思えば、14年前名古屋で初めてプロジェクトの取りまとめをした際に、開発したシステムはＰＣとハンディターミナルを連携させるものでした。
ハンディターミナル上で動くプログラムの開発言語は、Ｂａｓｉｃをベースにしたものですが、ハードメーカーが独自に準備したものです。（つまりクローズド）

テンキーとサーマルプリンタがついて、白黒液晶画面。1台30万円以上でした。

ハンディーターミナルを利用したシステムと言うと、ガスや電気の検針システムを見かける機会が多いと思います。
私が手がけたシステムは、『配置薬』の販売管理。いわゆる「富山の薬売り」ですね。
昔は家庭にもあったかと思うのですが、薬箱を薬屋さんから預かって、その中の薬を使ったら使った分だけ代金を払うというシステム。薬屋さんが定期的にやってきて、在庫管理をしていきます。
これ、家庭だと割が合わないのですが、工事現場だとかでは非常に重宝です。

システム的には、販売ルート分のお客様の前回の在庫情報をＰＣからハンディターミナルに吸い上げていって、現地で現物の個数とチェックして、販売個数を計算します。在庫を補充して、在庫数を入力し、在庫票を印刷して、置いてくる。
で、帰社したら最新の在庫情報をＰＣにダウンロードする。
という仕組。
今では一般的ですが、当時は、ＰＣで紙の伝票を印刷して持っていって、現地で手書きで書いていました。


他には、小売店の店頭在庫の管理などにもハンディターミナルを利用したりしましたが、最近でもハンディターミナルの価格は結構します。（10万円以下のものはなかなかない。）

携帯電話でiアプリが出たときに、真っ先に思ったのは、「これで安価なハンディターミナルが供給できる」でした。
iアプリで、在庫管理のアプリケーションを動かせば、安価で小型軽量なデバイスとして活躍します。
しかも、ＰＣとの通信インタフェースは標準装備。
証憑としての『伝票』が不要な業務であれば、もうハンディターミナルはいらないなぁ・・・

そしてスマートフォンの登場。
ＯＳの上で、ＰＣと同じ表計算ソフトが動く。
もう、アプリの開発すら不要です。

それでも、トリガだけは人間が明示的に与えてやる必要があったんですが、最近は、サーバーからのプッシュ機能というのがあって、端末側が何もしなくても、センター側から勝手にファイルを送りつけたりできるんだそうです。

毎朝、会社からスマートフォンに「本日のミッション」が届くなんて日も近いのかもしれません。

いわゆる J-SOX （２）

徐々に、仕事にも慣れて来て、展示会や営業に同行してのデモンストレーションなどを行っています。

というわけで、内部統制プロジェクトの事務局にあたる方とお話する機会が多いのですが・・・・



あまりの進捗の遅さに愕然とします。
「内部統制報告制度」は2008年4月以降に開始する事業年度から開示することが義務付けられました。
3月決算の会社であれば、来年の4月からスタートです。
これは来年の4月には内部統制の整備が終わった状態で、運用テストのPDCA＋モニタリングのサイクルを
まわしはじめなければいけないということです。
（2月決算の会社は、再来年の３月にスタートになります。）

すでに8月が終わろうとしています。
先日、お話したお客様は、「まだプロジェクトすら立ち上がっていない。」とおっしゃっていました。

弊社は米SOX対応の文書化に2年かかりました。（遅いだけ？）


財閥系の金融機関に勤める知人が「J-SOXは施行時には罰則規定なしの『骨抜き』になる予定だから、対応をあわてる必要はない。」と銀行が関連の会社に指導している。と、この春、語っていました。
ひょっとして、それを信じて動いていなかったのでしょうか？

もともと、銀行は、監督省庁からガチガチに業務を決められていて、それこそ箸の上げ下ろしまで規定・規則に縛られています。
それこそ、どこの銀行でも横並びに。
すなわち、業務プロセスに『内部統制上の不備』があればそれは監督省庁からの指導に不備があったということにもなりかねない。
業務の『見える化』さえ実施して、運用テストを定義すればスタートできるでしょう。

でも・・・・
一般の企業はどうでしょう？
現状の業務をフローに表して、現状のリスクコントロールの仕組みを洗い出して終わり！ってわけに行く会社は少数派でしょう。
必要な統制がなければ、新たなプロセスとして作る必要があるのです。コンピュータシステムで統制するなら、システムの改変が必要になります。
システムの改造ですよ！仕様を決めて、委託先を決めて、開発して、検証して・・・・残り6ヶ月なんですけど・・・。
マニュアル（手作業）での統制を追加するのであれば、承認の紙だのを追加して、これを定期的につき合わせチェックして、などというプロセスが必要になります。

そして、この不足しているリスクの洗い出しってのは、現状の業務を『見える化』した後の作業になるわけなんですよ。

不足している統制プロセスを追加して、検証して、文書を整えて、監査法人と「うちはこれでやります！」とレビュー。
監査法人さんは責任を持って、見てくれますから、ダメだって出す。
ダメだしにあったら、やり直しが発生する。

さらにさらに、対象範囲は海外の子会社も含まれます。
製造業だと最近じゃ、海外の子会社は「重要ではない」と無視できない影響を持っていることが殆どです。それどころか生産力の主体だったりします。
海外の子会社にも、文書化を実施させなければいけない。J-SOXの基準で。
それに、海外の子会社って12月決算のところが多いんですが、そうすると2008年1月にスタートしてもらう必要があります。
あと、4ヶ月しかないんですけど・・・・


みんな、焦ろうよ。
直前で駆け込まれても、御相談に乗れないんですよ。
-----------------
sent from W-ZERO3

いわゆるJ-SOX

6月から異動しました。
先月まで、前部署の仕事を中心にやっておりましたが、今の部署の仕事は「内部統制プロジェクト」です。

内部統制の中でもいわゆるJ-SOXの対応についての支援ソリューションを売り物にしている部署です。

弊社は、東証一部上場企業としてJ-SOX対応が必要な立場です。
それと同時に、米国で上場している親会社の連結決算子会社として米国SOXにも対応しています。

米国SOX対応の際には、当初、分散ばら撒き体制でのプロジェクトを発足し、初回の監査法人レビューでけちょんけちょんのだめだしを受けて、「やっぱ力仕事でやっつけるのってだめだわ」と、方向転換した経緯から、これからJ-SOX対応する企業に二の轍を踏んで欲しくないし、せっかくノウハウを蓄積したから売ろう！ということで、現在の部署が発足しました。

これからのエントリで、新しい仕事の内容について、少しまとめて行きます。


まず、SOX法ですが、これは主に株主の保護を目的として、上場企業が公開している財務諸表の内容の正確性を担保する法律です。
株主は投資する際に、企業を評価するにあたって財務諸表の内容を元に、判断するわけですが（財務諸表だけじゃないけどね。）、その財務諸表の内容が（意図していないにしても）虚偽であったら正確な判断ができず、倒産寸前のボロ株をつかまされる危険性があるわけです。
実際に、エンロン事件とかがあったわけで、それを受けての立法です。

これに倣い、日本でも少しアレンジして導入されたのがいわゆるJ-SOXです。
内部統制のうち財務報告に関係のある部分が対象です。

内部統制とは、企業の日々の業務について、善意・悪意にかかわらず、業務上の不備や不正が発生するリスクを防止・軽減する仕組と、その仕組が意図したとおりに機能しているかをチェックする一連の手続きのことを言います。

その手順としては、まず、企業内で行われている日々の業務について、フローチャート（業務フローと呼びます）にまとめて、業務の内容を可視化します。と、同時に業務の内容について、文書に整理記録します。（業務記述書と呼びます。）
この2点を検討し、業務上の統制ポイント（不備や不正が発生しそうな手続き上の箇所）を洗い出します。リスクと呼びましょうか。
このリスクについて、リスクを失くすまたは軽減する手続きがある場合は、それを文書化し、ない場合は、手続きを作って文書化します。これをコントロールと呼びます。
このリスクとコントロールを業務フロー上の発生箇所別に、まとめた表をリスクコントロールマトリクスと呼びます。

上記の、業務フロー、業務記述書、リスクコントロールマトリクスは3点セットと呼ばれています。これらは監査の対象になります。

J-SOXはこれらの文書を使って、経営者が自社内の財務報告に関わる業務に関する内部統制が有効に機能していることを担保することを求めています。
具体的には、これらの文書を財務諸表を監査する際に監査法人が監査することになります。
「有効に機能していること」を担保するために、文書を作るだけではなく、作った文書の通りに実行されているかを定期的にテストして、テスト結果を報告し、この結果を監査人が合わせて監査することになります。

すなわち、上場企業は、法律が施行されるまでに上記の3点セットの文書と、その有効性をテストするテスト方法を作成し、施行されたら早速、テストを定期的に実行する必要があります。

システム開発委託先選定の着眼点（規模見積）

前回、受託元がベンダーを選定する際の着眼点についてお話しましたが、今回は、元請ベンダーが下請のソフトハウスを選定する際の着眼点をお話します。

ユーザ企業のシステム部門の方が、委託先のベンダーを選定する際の着眼点としてもご参考になるはずです。

要求定義がだいたい確定してお客様に費用見積を提出する際には、見積作成したエンジニアにはそれなりの「規模」が想定されています。

それは、画面や帳票の数だったり、メニューの数だったり、機能の数だったりするわけですが、生産性や工数を算出するために、言語を想定してプログラムの出来上がりステップ数に換算するのが一般的です。

まず、要求定義から機能をニンゲンが運用する単位くらいまでにブレークダウンして、運用する際に「動かす」単位での画面や帳票の数に落とします。
このアウトプットの難易度や項目数を加味して、だいたいの出来上がりプログラムのステップ数を予想します。

この部分は、「女の勘」です。
（見積金額が気に入らない営業担当者は「この見積根拠はなんだ？！」と詰め寄るので、必ず「女の勘」と応えることにしています。どんな根拠を述べようが、自分が売りたい金額の見積が出てくるまで、あれやこれやと説明を求めるに決まっているので、言うだけ時間の無駄です。）

さて、この「勘」ですが、「男の勘」はだめです。
「管理職の男の勘」なんてのは最低です。
邪念が入りすぎて、あたったためしがない！

そもそも、「戦略的価格設定」という言葉はあったとしても、「戦略的見積」が存在してはならない。
この辺を取り違えている営業マンのなんと多いことか・・・
見積を根拠として、工程を作成して、人員を確保する。
この見積を「売値」から逆算して作成したら、完成前に納期が来て、人がいなくなるということは明白です。
この当たり前のことがわからなくなってしまうのが『邪念』の恐ろしさです。


話はそれましたが・・・
基本設計がある程度終わって、開発を外注に委託する際の見積では、必ず、金額だけではなく予想ステップ数を出してもらいます。
（所要工数ではありません。所要工数を出すと単価がバレバレですよね。）

この予想ステップ数が、私の予想よりも大きい場合は他を探します。

同じ機能なら、より小さなプログラムを仕上げてくれる会社を選びたい！
たいていは当初の予想ステップよりも出来上がりは2割増になるものです。

出来れば、こちらの予想ステップの2割減程度の目標値を掲げる会社とお付き合いしたいです。

同じ機能なら、小さなプログラムのほうがたいていは高品質になるからです。
これは、標準化・共通化・部品化（汎化・抽象化）が適切になされて、再利用可能なモジュールを組み合わせたつくりのほうが高品質になるからです。

例えば、似たような機能の処理Aと処理A'があったとしましょう。
甲社はこれを、共通な処理を一まとめにしたプログラムCと、処理Aの独自機能のプログラムA,処理A’のプログラムBの3本で作成します。
乙社は、処理AをプログラムAとして作成し、これをコピーしたプログラムBに処理A'の独自機能部分を追加変更して2本のプログラムを作成します。

乙社の納品プログラムのほうが大きくて、乙社の生産性のほうが高く見えます。

しかし、これで共通する処理部分に不良があった場合、その修正コストは乙社のプログラムのほうは2倍になります。
設計に不良があって、ドキュメントの改修が必要なら、修正コストはもっと差が出ます。

納品時の金額が同じなら、乙社のプログラムの品質は低い。
テストの手間を考えればわかるはずです。

きちんと仕事をしている会社であれば、プログラムは可能な限り「小さく」を目指すはずです。
だから、私は自分の見積よりも「大きな」規模見積をしてくるソフトハウスには製造を依頼したくないのです。


これは、委託元が元請ベンダーを数社から選定する際にも指標として使えますね。
ただし、使用する言語によって機能実現のためのステップ数が異なりますので、使用言語が違う場合は比較できませんので念のため。