はてなキーワード: 内部統制とは
ドイツのメルケル首相が「欧州の政治統合を深めるための条約改正」を提唱し、波紋を広げています。
ユーロゾーンには、たとえばマーストリヒト条約で定めた「国家財政赤字はGDPの3%以内」「累積債務はGDPの60%以内」という約束を守れない国がたくさんあります。
これまでは「赤信号、みんなで渡ればなんとやら」で罰則の適用も曖昧にされてきましたが、今後はそういう国に対して、何らかのペナルティーを課そうではないか、ということです。
ペナルティーには、法的手段に訴えてでも借金を返済させるとか、あるいはいっそユーロゾーンから離脱させるとかいった一種強権的な措置も視野に入れます。
ユーロゾーンは通貨同盟であり、加盟国の経済・財政の一元化はしていない。特に通貨の発行に関しては勝手なことをさせないが、国債の発行に関しては規律が緩かった。
したがって実質的には各国がそれぞれ国内経済の舵取りをしている。
その結果が今日のユーロ危機の原因のひとつになったのだから、今後は通貨のみならず経済・財政も一元化し、ユーロゾーンの統合をより強固なものにする狙いだ。
確かにユーロゾーン内での統一基準をもって各国政府の「放漫経営」を戒めれば債務危機などのリスクをかなり減らすことはできるだろう。
だが、私は「ユーロゾーンが経済・財政を一元化するのは至難の業だ」と考えている。なぜなら、それは各国が個別に予算案を作るのを禁止するということであり、内政干渉にも等しい。
もともと「社員」という身分だけが共通していて「目的」や「仕事」のあり方について意思疎通の仕組みを十分に構築せず、
空気に頼った放漫経営を行なっていた職場では、多様化した若者とのコミュニケーションの断絶に対し、
「飲みニケーション」を強化し、職場での統合をより強固なものにする狙いだ。
最近は「飲みニケーション」の概念化、半強制化、楽しめない奴は村八分にするなどの社会的制裁をちらつかせて、
むりやり「飲みニケーション」の維持や、チームとしての連帯を名目上維持しようとする動きが見られる。
たしかに規則や執拗なチェックで締め付ければ一時的には問題児は減り、「形だけは」結びつきが強くなるだろう。
飲みニケーションに限らず、すでに企業の「内部統制」や、学校の教育などで同じような徴候が見られている。
しかし、これは至難の業だと考えている。なぜならそれは、個々人の自由を制限するということであり、サービス残業にも等しい。
私はむしろ、ユーロ加盟国それぞれに自国の通貨発行を一部認めていくべきだと考える。
ユーロ17カ国では現在、ユーロの流通は当然ながら100%になっている。
これを段階的に90%、80%と2割程度まで減らしていき、その代わりにそれぞれの国に独自通貨を発行させる。
そして、独自通貨の加重平均はユーロと連動させた、いわゆるバスケット通貨(ユーロ導入前のECUと同じ原理)とする。
こうすれば当然、独自通貨を発行し過ぎた国の貨幣価値は下落する。しかし、それはそれで構わない。
こぼれ落ちる国も出てこようが、そういう国にはユーロから離脱していただく。
すると最終的には「本当に強い」7~8カ国が残るだろう。これらの国々でユーロ加盟国を再構築してから、落ちこぼれた国にも再出発できる機会を与えるのだ。
こうした根本的なプロセスを踏まなければ経済・財政一元化の道筋も見えてこない。
逆にいえば、こういう発想を持たないまま、やれギリシャの救済だ、それルール違反を犯した国にはペナルティーだとしているのは、まったく場当たり的な対策である。それではユーロの再建はおぼつかない。
マーストリヒト条約ではユーロ加盟の条件を決めたが、離脱の方法に関しては決めていなかった。そういう不備がここに来て一斉に露呈した。
私はむしろ、まず飲みニケーションの参加を自由意志に任せるべきだと考える。
というか、まずそんなに飲みにケーションが素晴らしいというなら、
まずは好きな奴らだけでも「楽しい」だけじゃいその素晴らしさを体現して、若者から「私も参加したい」と思わせるくらい魅力的になってみせやがれ、と。
飲みニケーションについて、ただ昔からやってるから、とか俺は楽しかったから、とかを根拠にしてゼロベースで考えなおすこともせず、
やれあいつは付き合いが悪いとか、こんなことでは出世できないとか、制裁とか言ってるのは全くの的外れである。それでは飲みニケーションの再建はおぼつかない。
飲みニケーションは形にこだわりすぎて、楽しくなくなったときどう自分を変えていくか、という点が全く考慮されていない。その不備が居間一斉に露呈している。
どの国も「仲間に入りたい」と言ってユーロゾーンに入ったはいいのですが、そこから離脱するとなると、地獄が待ち構えています。
各国政府から見れば、ユーロに加入した途端に通貨の自主的な発行権を奪われ、それはユーロをやめようが何をしようが、事実上は通貨の発行権は戻ってこなくなってしまうのと一緒です。
飲みニケーションが自然発生的に起こって、みんながそれに参加してたのしむ、という間は良かった。
しかし今では旨みがヘっているにもかからず「抜けようとすれば村八分」という制裁だけが残ったペナルティ装置になっている。
http://www.nikkei.com/news/latest/article/g=96958A9C93819696E0E6E2E3998DE0E6E2E5E0E2E3E2869891E2E2E2
なんだかんだ言って、会計士って大した仕事してないくせにもらいすぎなんだよね。
大半は業務もITも金融も経営も税務も法律も経済も知らないくせに。
会計監査の大半は「封筒に宛名シール貼って投函」「2つの書類の数字が一緒か確かめる」「書類の印鑑を確かめる」なんていうレベルだから、中学生でもできる。
「リスク考慮した上でどの監査手続を行うか決定する」「会計処理や内部統制の妥当性を検討する」「見積りの数値を検討する」なんてのは専門家がやるべきだけど、
それをやるのに、わざわざ「封筒に宛名書いて投函する」なんて雑務をする必要ないよ。何してるかさえわかればいい。
大卒の新入職員が事務所で一日you tube観て30ウン万も給料もらえるとか、この業界くらいじゃなかろうか。
完全に、規制で守られているぬるま湯業界ですよ。市場が有効に機能していない典型的な産業ですよ。
そのためには、企業の経済的実態を描くことと、比較可能性を担保することが必要。
経済的実態を正確に描きたいけれど、認識・測定・報告(作成)・利用それぞれの観点から制約が生じる。
例えば、「今後10年間に渡って企業のネット・キャッシュインフローを10億円増加させる事のできるを経営者を雇った」なんてことがあった場合、
経済的実態を正確に描くとすれば財務諸表に反映させたいけれども、認識・測定の点で問題が生じる。
報告の点では、財務諸表の種類をあまり多く出来ない、勘定科目をあまり多く出来ないとか。
制約がなければ、P/LもB/SもC/Sも、あと数通りあったほうがいい。
こんなくだらない「そもそも論」から、会計で何が出来るか書きたかったんだけれども、めんどくさくなってしまった。
簡単に言えば
・勘定科目間でどのような関連があるか
・数値がどのように造られるか
なんてことを考えると面白いんじゃないかな。
昨年来、日本のIT業界ではクラウド・コンピューティングがブームになっている。最近は短縮して単に「クラウド」と呼ばれることも多いようだ。そして、この業界ではよくあることだが、クラウド・コンピューティングについて、コンセンサスのとれた定義はない。
しかしそれでは議論が進まないので、まずはマッキンゼーが発表した"Clearing the air on cloud computing"という資料におけるクラウドの定義を引用するところから始めよう。大企業でのクラウド利用に懐疑的な見方を示したことで、話題になったリポートだ。
これによれば、クラウドとは「以下の条件を満たす、情報処理(コンピューティング)、ネットワーク、記憶装置(ストレージ)を提供するハードウエアベースのサービス」である。
1. 利用者にとって、ハードウエアの取り扱い(管理)が、高度に抽象化されている
3. インフラに、非常に柔軟性がある(スケーラビリティーがある)
クラウドと聞いて誰もが思い浮かべるのは、アマゾンが行っている、ネット経由でコンピューティング機能を提供する「EC2」や、同じくストレージを提供する「S3」といったサービス、あるいはウェブアプリケーション開発キットを提供する「Google App Engine」などだ。これらは上記の定義を満たしている。ユーザーは簡単に仮想サーバーや仮想ストレージをインターネット上に持つことができ、そのコストは使用量に応じて課金されるのが普通で、企業会計の中では経費として処理される。また、スケーラビリティーがあるので必要に応じてリソースを増やすことも減らすことも簡単かつスピーディーにできる。
クラウドがこれだけ話題になるのは、やはり多様な効用があるからだ。
まず、使いたい時にすぐに利用できる。ハードウエアやソフトウエアの調達は必要ない。ネットワークへの接続や各種環境設定などの作業も不要である。試験的なシステム構築も容易で、使えないと分かればすぐに止めることも可能。費用は、コンピューティング機能やストレージなどのリソースを使った量に応じて課金され、会計上は経費として処理でき、バランスシート上の資産が増えることがない。スケーラビリティーも高い。そもそもインターネットの“あちら側”にあるため、関係者でデータなどを共有することも容易である。
さらに、運用業務から解放される。内部統制やコンプライアンス(法令順守)強化の流れを考えると、利用するサービスが十分信頼できるものであれば、これはメリットが大きい。
特に中小、中堅企業にとっては、クラウドの持つ機能や信頼性、情報セキュリティーレベルは自社システムより優れていることが多い。信頼性や情報セキュリティーに対するユーザーの懸念は、クラウド普及の障害になると考える人が多いようだが、実際には追い風になるだろう。
こうしてクラウドの効用を並べてみると、企業規模が小さい企業ほどメリットが大きいことがわかる。そこで登場するのが、「プライベート・クラウド」である。
プライベート・クラウドとは、EC2やGoogle App Engineのような「パブリック・クラウド」とは異なり、一つの企業や組織の中に閉じたクラウドである。従って、そのコストはすべてその企業や組織が支払うことになる。
たとえば、米国防総省の国防情報システム局(DISA)が保有する「RACE (Rapid Access Computing Environment)」は、国防総省内部向けのクラウドであり、関係者以外は利用できない。実際に構築したのはヒューレット・パッカードであるが、その構築費用も国防総省が負担している。
したがってプライベート・クラウドは、最初に挙げたクラウドの定義のすべてを満たさない。つまり、条件の1と3(バーチャルなサーバーを簡単に構築でき、その規模を自由に変更できること)は満たすのだが、2の条件(コストを経費として支払うこと)を満たさない。
最初に挙げたクラウドの定義を正しいとするならば、プライベート・クラウドはクラウドではないことになる。
当然、クラウドのメリットであるはずの「使えないと分かればすぐに止めることも可能」「費用はリソースを使った量に応じて課金」「会計上は経費として処理でき、バランスシート上の資産が増えることがない」「リソースを増強することも縮小することも簡単にできる」というわけにはいかない。
もちろん、その組織内の個人や一部局は、クラウドの持ついくつかのメリットは享受できる。使いたいときにすぐに使うことができるだろうし、スケーラビリティーも高い。しかし、組織全体で見た場合にはクラウドのメリットの多くの部分は消滅する。
そう考えると、プライベート・クラウドは、仮想化技術を利用したサーバー統合だと考えた方がよいのではないだろうか。
さて、2009年度の補正予算には、電子行政クラウドの推進という項目がある。この中に、霞が関クラウドと自治体クラウドの構築が含まれている。これはそれぞれ、政府のプライベート・クラウド、地方自治体のプライベート・クラウドである。
当然のことながら、パブリック・クラウドのように「使えないと分かればすぐ止めること」はできないし、「費用は使った分だけ支払う」わけにもいかない(自治体クラウドについては、各自治体に利用量に応じて課金する方法も考えられるが、利用率が低い場合には、徴収できる利用料が運用コストを下回ることになってしまう)。
ただ電子行政クラウドにもメリットがないわけではない。分散されたサーバーを統合すれば、コンピューターリソースの利用効率を高めることが可能になるし、運用コストを削減できるだろう。また、自治体クラウドを利用して市町村や都道府県の業務システムをSaaS(ネット経由でソフトウエアを提供)化できれば、大幅なコスト削減も可能になる。
「うちの自治体は隣の自治体と業務のやり方が違うので同じシステムでは処理できない」という話を地方自治体の関係者から聞くことが多いが、優れたSaaSはそれぞれの組織や業務プロセスに合わせてデータの構成はもちろん、ワークフロー、業務プロセスをカスタマイズできる。そうした仕組みを取り入れた自治体向けSaaSを開発すれば、間違いなく自治体の情報処理コストは大幅に削減できる。
問題は、それを実現できるかにある。中央官庁のサーバー統合にしても、自治体向けSaaSにしても、机上の計算では、投資に見合う十分なコスト削減効果をはじき出すことはできるだろう。しかし、一歩誤れば稼働率が上がらず、税金の無駄遣いだと非難されることにもなりかねない。
そこで提案なのだが、電子行政クラウド構築のリスクを民間企業に委ねてはどうだろう。政府が構築するのではなく、民間企業が霞が関クラウドや自治体クラウドを構築し、各府省、自治体にサービスを提供する。もちろん、利用者である各府省や自治体からは利用量に応じた料金を徴収する。当初の構築費用については補正予算を使ってもよいが、数年間で国庫に返納してもらう仕組みにする。
利用料金は、ある一定の利用率で採算が取れるように設定する。つまり、利用率が予定以上になればその民間企業は大きな利益を得ることになるが、そうでないと損失を被ってしまう。
つまり、政府や自治体のプライベート・クラウドにするのではなく、政府や自治体をユーザーとするパブリック・クラウドにするという発想である。こういう仕組みにすれば、構築を担当する企業は知恵を絞り、多くのユーザーを獲得しようと使い勝手のよい電子行政クラウドを構築するのではないだろうか。
このコラムは日経デジタルコアによって企画・編集されています。
ご意見・問い合わせは同事務局あてにお願いします。
タイトル通りのことを思う。
WebのOSSな世界と、Windowsの閉じたネットワークの世界がくっついちゃって戸惑ってるんだろうね。クラウドなんて言い出したのもその辺の焦りが見受けられる。
だってメールクライアントなんて使ってるの社内だけでしょ?ねぇ?
一般ユーザーの大半はメールは携帯電話か、GmailなどWebメール。
クラウドがなぜ安いか、どこでも解説されてるじゃん。インフラ周りでWEB企業が最強って事でしょ。
クラウドを使いたいけど、事情があって「和製クラウド」を使うんだ。という話でしょ。
つまりIT内部統制とか大手同士の付き合いがなければ「舶来クラウド」に圧倒されてる。ってことでしょ
とあるWEB開発企業にいたんだけど、社長が企業向けSaaSにこだわるのよ。
絶対変だよね。クラウドもSaaSも「Web系企業」が一人勝ちしてる。その事実があるのに、企業向けなんかやっても未来がないよね。
エンタープライズシステムの会社がいくら焦っても遅いんじゃないかな。
Gmail使ってる世代が就職始めて、社内でそれなりの立場になる10年後考えてみたらいい。
「10年は泥のように」「無理です」
http://www.atmarkit.co.jp/news/200805/28/ipa.html
この考え方の違いは、10年後顕著に表れるだろうね。Gmail世代とメーラー世代。いまはメーラ使ってる世代が偉そうにITを土建屋みたいに言ってるけど。Gmail世代はWebAPIで従量課金とか使い放題とかインフラから切り離されて、土建みたいな事を言わなくなるんだよね。
【「重要な欠陥があり、内部統制は有効でない。」と評価結果に記載した会社(56社)について】
*
(1)「重要な欠陥」と判断した理由として、内部統制報告書に記載された例
(注)一部要約しており、内部統制報告書の記載そのものではないことに注意してください。また、開示例であり、当該内容が「重要な欠陥」に該当するかどうかは、会社の規模、事業の状況や取り巻く環境等により異なることに留意が必要です。
o
○全社的な内部統制
+ 当社は、財務報告に関するリスクの評価と対応を実施していない。
+ 前代表取締役が社内規定による職務分掌や承認手続を無視し、独断で約束手形の振り出しを行った。
+ 前取締役が、定められた取締役会の承認を得ずに債務保証を行った。
+ 内部統制の基本的要素である「統制環境」「情報と伝達」「モニタリング」に不備がある。
o
+ 子会社の繰延税金資産の回収可能性の判断の適用を誤り、さらに、それに対する牽制が十分機能しなかった。
+ 在外統括会社の「傘下会社に対するモニタリング」が適切に実施されなかったため、海外子会社による不適切な会計処理が行われた。
+ 当期の決算作業についての決算手順書等が整備、運用されていない。連結決算のために必要となる情報の収集に不足がみられる。開示資料の作成に際し、責任者による査閲等が実施されていない。
+ 連結決算及び開示に係るマニュアル・チェックリストが適切に作成されておらず、グループ会社への情報伝達、役割分担、数値検証等一連の処理手続にて、適正な査閲、分析及び監視する内部統制手続が不十分。
+ 決算処理手続における処理内容及び会計基準の適用の検討とその承認手続の運用が不十分であったため、たな卸資産への諸掛り経費の配賦計算、連結決算における未実現利益消去に伴う繰延税金資産の計上等について誤りがあった。
o
+ 営業部門において、適正な売上計上に必要な契約内容の確認及び承認手続の運用が不十分であったため、当期の売上高について重要な修正を行うことになった。
+ 輸入原材料仕入プロセス及び在庫管理プロセスの一部において、適正な仕入計上及び在庫計上に必要な承認手続の運用が不十分であったため、当期の買掛金及び棚卸資産について重要な修正を行うことになった。
+ 新規の非定型取引に係る業務プロセス並びに固定資産の減損会計及び税効果会計に係る業務プロセスにおいて、能力のある経理担当者によって適切に査閲、分析及び監視する内部統制が有効でない。
+ 連結子会社の売上プロセスにおいて、商慣習上顧客との間に契約書が一部未締結であったり、売上の基礎となる納品の事実を証する書類等を取り交わすことなく業務を遂行していたことが発見された。
+ システムの保守及び運用の管理を適正に行うため、「運用・保守管理規程」を定めて遵守することが義務づけられているが、コンピュータデータの保全手続において、当該規程の運用が不十分であったため、同データの一部が消失し、会計データの修復作業を行った。ただし、バックアップデータ復元作業のテスト実施が十分でなく、バックアップデータ消失のリスクを予見できなかった。
*
(2)評価結果に「重要な欠陥があり、内部統制が有効でない。」と記載した56社のうち、事業年度の末日後に重要な欠陥を是正するために実施した措置を記載し、かつ、内部統制報告書提出日までに、重要な欠陥が是正されたと記載した会社が11社ありました。
(注)事業年度の末日後内部統制報告書の提出日までに、記載した「重要な欠陥」を是正するために実施された措置がある場合には、その内容を付記事項に記載することができることになっています(内部統制府令第1号様式記載上の注意)。
*
(3)56社の内部統制報告書に対する内部統制監査報告書における監査人の意見は、55社が無限定適正意見、1社が意見不表明でした。
(注)監査人は、会社の内部統制の評価結果等を監査し意見を述べることになっています。例えば、「重要な欠陥があり、内部統制が有効でない。」と評価した会社の評価結果を適正であると判断した場合には、「適正意見」を表明することになります。
*
(4)評価結果に「重要な欠陥があり、内部統制が有効でない。」と記載した56社の財務諸表に対する監査報告書の監査意見は、54社が無限定適正意見、1社が限定付適正意見、1社が意見不表明でした。
バグ。
衛生環境が未整備で十分でなければ料理にバグ(虫)が入りこむことはある。
バグの入り込む確率は設備投資にしたがって各段に減らせるが完璧はありえない。
だがしかし、料理にバグが入っていることだけが問題なのだろうか?
頼んだ料理が塩からすぎて食べれないとか、頼んでもいつまでたってもできてこないとか、頼んだものと違うものがでてきたとか、そのすべてを評価した結果、こんな料理に金なんか払えるか!ということなのかもしれない。
問題は虫を取り除けばいいというシンプルなところにはない。
つくって出しとけばそれでいいでしょという心構えにある。
最初に値段を言ったのだからそれは払えよという傲慢なところにある。
虫さえはいってなければ瑕疵責任は免れる。お金をよこせという態度にある。
高額なシステムを発注したがために傾いた会社もすくなくはない。
腐った卵しかないとか、調理器具がそもそもナベひとつしかないとか、
この国のソフトウエア環境は貧困地区の屋台の調理環境の域を出ない。
正直言って、LDRがどんなものか知らなかったし、今ようやく意味を知っただけ。いまだにWEBアプリなのかクライアント側かすらわからない。mala氏にも興味ない。そんなに若かったのか、と今知った。名前は入社の件がトップページに出ていたので知った程度。品の無いidだなぁとは思ったが。
彼個人ではなく、はてなに対する人の出入りそのものが面白い事になっていると思う。はてなってのは口数が多い会社だ。普通の会社はあんなにおおっぴろげに会社や社員が話をしない。実際、はてなはプレスリリースの意味ねぇじゃんとか思ったくらい(とはいえ、株主に対する義務)。
内部統制どころか、俺の個人データすら不安を感じることがあるくらい、はてなの中の人はぺらぺらしゃべる。あの人とあったとか、だれそれが面白い事言っているとか、普通の会社だと業務のいっぺんを垣間見せてしまうので言えないことだ。それを言う。人間はご飯を永遠に食べ続けられるとかまで。
だからさ、将来のある人は、どの程度の人がどのくらいのチャンスを物にするのか、そのために何をしているか、そして何を得るか、ひとつはてなを観察してみるといいんじゃないか。はてなに限らないことだが、ここ数年のブログブームで、「がしがしやる奴は、外に出て人と接しまくってる」ということに引きこもりがちの連中も気づいたはずだぞ。
同じような発見があるかもしれないから、気になるならmala氏とはてなを追ってみたら?LDRと同じようなソフトを自分で作ってみると言うのは、ベンチマークとしてきわめて有効だと思う。