上場企業の有価証券報告書に対してモノ申したいこと

前回、「上場企業の平均年収の調べ方」を紹介しました。

blog.boost-up.net

今回は、そのデータソースである有価証券報告書について、どうしても言いたいことがあります。

有価証券報告書の信頼性

以下は、株式会社ユーグレナという、東証一部に上場している会社の直近事業年度の有価証券報告書となります。 赤枠で囲った平均年間給与を見てください。

f:id:boost-up:20180709084152p:plain

5,732,793千円です。57億円です。。

同様に、以下は、株式会社あみやき亭という会社で、東証一部および名証一部に上場している会社の直近事業年度の有価証券報告書となります。

f:id:boost-up:20180709083818p:plain

5,366,170千円です。53億円です。。

私は日本の全上場企業の有価証券報告書を一定の範囲でチェックしていますが、 このようなミスは上記2社に限らず、年に数社は発生しています。

ここではたまたま年間平均給与を取り上げましたが、 誤りが発生している(可能性がある)のはこれに限らないと思います。

有価証券報告書って会計士も見ているのでは?

よくある質問ですが答えはNoです(ある部分ではYesですが、、)。

上場企業の金融商品取引法に基づき監査法人または公認会計士による会計監査を受けなければいけませんが、 ここでの監査対象はあくまで「財務諸表」のみとなっています。

有価証券報告書の末尾に「独立監査人の監査報告書および内部統制監査報告書」というものがありますので見てみましょう。 以下はユーグレナのものです。

f:id:boost-up:20180710082114p:plain

本文の書き出しにこう記載されています。

当監査法人は、金融商品取引法第193条の2第1項の規定に基づく監査証明を行うため、「経理の状況」に掲げられている株式会社ユーグレナの平成28年10月1日から平成29年9月30日までの連結事業年度の連結財務諸表、すなわち、連結貸借対照表、連結損益計算書、連結包括利益計算書、連結株主資本等変動計算書、連結キャッシュ・フロー計算書、連結財務諸表作成のための基礎となる重要な事項、その他の注記及び連結附則明細表について監査を行った。

これは定型文となっていますので、どの会社の監査報告書にも原則として同じ文言が記載されます。 ※この他、「独立監査人の監査報告書」というものも添付されていますが、こちらは上場企業単体の監査報告書になります。

このように、会計士は有価証券報告書の一部に含まれる(連結)財務諸表のみを監査しているにすぎず、それ以外の定量・定性的な記述についてはすべて監査対象外となっています。

上場企業には是非ともチェックの徹底を!

有価証券報告書は現在だけでなく将来の投資家に対する情報提供も目的として作成が義務付けられている書類となります。 是非、企業および開示担当者にはチェックの徹底をお願いしたいと思います。

上場企業の平均年収の調べ方

拙作:上場企業サーチ.comでは、2年位前から上場企業年収ランキングのコーナーを設けており、某経済紙で定期的に特集が組まれるような上場企業の年収ランキングを毎日更新しています。

xn--vckya7nx51ik9ay55a3l3a.com

今日はこのデータソースである上場企業の平均年収の調べ方についてご紹介します。

データソースとなるのは有価証券報告書

平均年収は、上場企業等が金融商品取引法に基づき年1回の開示が義務付けられている「有価証券報告書」という公開情報に記載されています。

有価証券報告書は上場企業のWebサイト上にあるIRコーナーに置いてある他、Edinetと呼ばれるシステムに登録され、誰でも自由に利用することができます。

以下がEdinetのトップページです。

f:id:boost-up:20180706090400p:plain

有価証券報告書を取得するためにはグローバルナビゲーションの左から2つめにある「書類検索」を選択し、「書類簡易検索画面」に移動します。 以下がその画面になります。

f:id:boost-up:20180706090635p:plain

[提出者/発行者/ファンド]の入力ボックスに提出会社の名称かコードを入力して検索ボタンを押すと、その会社がEdinetに提出している書類が表示されます。

名称で検索する場合は、ある程度の表記ゆれに対応しています。 例えば、リコーはリコーでも検索できますし、日本電気もNECで検索できます。 (この便利さはちょっと見習いたいところです、、、)

もう一つのコードというのは、証券コードとは異なり、E+数字5桁のEdinetコードか、G+数字5桁のファンドコードを入力する必要があります。 上場企業の有価証券報告書が欲しい場合はEdinetコードの方を使います。 EdinetコードはEdinetから一覧をダウンロードすることができます。

Edinetコード一覧の入手方法

一覧が欲しい場合は、Edinetのグローバルナビゲーションの一番右にある「ダウンロード」を押し、 左サイドバーにある「EDINETタクソノミ及びコードリスト」を選択します。

f:id:boost-up:20180706091917p:plain

表示されたページの一番下にいくと、Edinetコードリストが見つかります。

f:id:boost-up:20180706092149p:plain

在処が分かりづらい。。

有価証券報告書の2つの提供形態

少し脱線しましたが、これでようやく目的の上場企業の有価証券報告書が入手できます。

例えば、日本電気(NEC)で検索すると、検索結果には以下のように表示されます。 有価証券報告書はPDF版とXBRL版の2種類が提供されています。

f:id:boost-up:20180706092625p:plain

人間が読むときにはPDF版、システムに取り込むなどして使う場合はXBRL版を選択します。

上場企業サーチ.comではシステムで処理しているため、XBRL版を使っていますが、 今回は平均年収の記載箇所を示すのが目的ですので、PDF版を見ていきます。

平均年収の記載箇所と注意事項

これは様式で決められており、有価証券報告書の「第一部【企業情報】第1【企業の概況】5【従業員の状況】(2) 提出会社の状況」に記載されています。

書類によって若干異なりますが、だいたいP10~P15辺りにあることが多いかもしれません。

以下は、日本電気(NEC)の第180期の有価証券報告書の該当箇所になります。 f:id:boost-up:20180706093605p:plain

「平均年間給与(円)」として示される”7,890,103”が平均年収となります。

ここで注意事項が2つあります。

  1. 提出会社(上場企業)本体の平均である
  2. 会社によって集計対象が異なる

1つ目について、 上場企業の中には持株会社(ホールディングスまたはホールディング)を上場させ、 事業の中核となる会社をその子会社として会社が相当数存在します。

このような場合、持株会社はグループ経営管理の頭脳として、 少数精鋭の陣容で運営されていることが多く、グループ全体の平均年収と比べると高くなることが一般的です。 逆に、特定の戦略子会社の給料水準が突出して高い場合もあるかも知れませんが、 有価証券報告書から知ることができるのはあくまで、上場企業本体の平均年収のみとなります。

2つ目について、 NECの場合は注書きを見ると、「平均年間給与は、税込額であり、時間外給与および賞与を含んでいます。」との記載がありますが、 「平均年間給与」をどう定義するかは企業個々に裁量の余地が与えられています。 同業やライバル企業でも定義が異なることがありますので、注意が必要です。

今回は、有価証券報告書から上場企業の平均年収を知る流れを紹介しました。

【続報】運営するサーバのIPをアドレス変更してから「変」なことが続いています

昨年12月に投稿した記事になりますが、 Webサービスを運営するサーバを別のクラウドサービスに切り替えたあたりから、Search Consoleに表示されるインデックス数が激減した記事を書きました。

blog.boost-up.net

今日は久しぶりにその続報をお伝えします。

サイトマップのインデックス数はなんとゼロ!!

前回報告時には約4,000ページの10%程度まで落ち込んでいましたが、 その後も減少が止まらず、ついにはゼロになってしまいました。 本当にゼロです。1件もありません。

ほぼ時を同じくして、完全SSL化の対応も行ったため、 Search Consoleには以下2つのプロパティを登録していますが、いずれも完全にゼロです。。

http://上場企業サーチ.com https://上場企業サーチ.com

サイトマップにはきちんと約4,000件が送信済みとして認識され、直近では2018年5月19日に処理されています。 インデックスエラーもゼロです。

検索アナリティクスは復活!!

諸々の変更前には一日あたり5,000~10,000PVだったのが、一時100ページ程までに落ち込んでいましたが、 こちらは徐々に増加に転じ、Search Consolの表示上も完全に元に戻りました。

変更前サーバからのIPベースの被リンクは若干残ってる

以前の記事で書いた通り、サーバの切り替えの仕方に起因すると思われる謎の被リンクが大量に残っていた件は、 Googleの被リンク否認ツールに登録して以降徐々に減り始め、いまでは殆どなくなりました。

ただ、ゼロにはなっていないので、影響が完全に排除されたのかどうかはわかりません。

結局実害が出ているのか?

前回の記事を投稿してからここまで約半年間、大騒ぎしなかったことがすべてですが、 Google Analyticsに見る実際のアクセス数は完全に元に戻っており、 Organic Search経由の流入比率も変更前後で大きな差異は出ていません。

Search Consoleでサイトマップの情報が見れないこと以外は今のところ不自由も感じていません。

まとめ

ということで、問題が解消したらまた更新したいと思いますが、 前回の投稿時に書いた「大変なことが起きている」は取り下げさせていただき、 タイトルを「変なことが続いている」としたうえで、この件については当面静観したいと思います。

学校教育は洗脳であると主張する堀江さんの本を読んでみた

すべての教育は「洗脳」である~21世紀の脱・学校論~ (光文社新書)

堀江さんは、学校は従順な国民を量産するための洗脳機関であり、意欲や興味に対して行動するというシンプルな行動原理に心のブレーキを付ける場所でするとの考えから学校教育を否定しています。

一方で、没頭することの重要性を強調しており、その観点では勉学自体を否定しているわけではありません。 むしろ、自らの興味と意欲で経験したものは例え遊びからであっても学びに繋がり、その経験の中に無駄になるものはない、そう仰りたいのではないかと感じました。

型を持ち出す時点で分かっていない、と叱られそうですが、感覚と意志を重視し、やりたいとこもやりたくないことも自分で決める事を良しとする、モンテッソーリ教育に似た発想のように思います。

個人的にも社会人としてある程度経験を積んだ今、改めて学校教育を振り返ると、かなりの部分で共感出来ることがあります。

殆ど全ての人間が将来、国家、企業あるいは何らかのコミュニティ・集団に所属する一員である事を念頭に置くと、集団生活の中で最低限の常識を学ぶ環境としての学校には重要な存在意義があると思います。 その一方で、学校が教える授業は言葉の通り、授けるスタンスが背景にあるわけですが、確かに授業で教わった諸々、特に古典や歴史などはある解釈の集大成ですし、道徳教育もその背景にあるのは善悪や価値観に対する一面的な解釈を題材にしており、良い成績・評価を得るために出題意図を推し量る思考回路が知らず知らずのうちに出来上がっていたように思います。

私自身、アイディアを行動に移そうとしたことか幾度となくありましたが、その度にアクセルと同じくらいブレーキを考える論理フレームワークが働いてしまい、時間とともに熱意を冷まし、固化してしまうか第三者が先に行動に移してしまうことが何度もありました。

良書を読んだからと言って、行動原理や思考回路を急にガラガラポンする事も簡単ではないのでしょうが、心のブレーキの存在を意識して、やらない理由・言い訳を作らないよう自分のモチベーションを上げていこうと思います。

年明けからの仮想通貨の状況について、去年の主張を振り返る

f:id:boost-up:20171222203243j:plain

2018年に入って仮想通貨が軒並み暴落し、今も不安定な状況が続いています。

そんななか、先日はコインチェックからNEMが盗まれたという事件も発生し、ただでさえ怪しいと思われることが多かった仮想通貨が益々不審がられるのに十分な状況です。

以前の記事で、仮想通貨の本質的な価値はゼロであることを書き、また別の記事では、年末にポートフォリオを組み替えることのリスクを書きました。

blog.boost-up.net

blog.boost-up.net

国税庁の見解では、ポートフォリオの組み替えは利益の実現となりますので、年末にポートフォリオを組み替え、年明けの暴落に直面した方の中には、2月16日から始まる所得税の確定申告シーズンを控え、納税資金なき利益に頭を抱えている方もいらっしゃるかも知れません。

そこに来てNEMの事件の発生により、コインチェックに預けている仮想通貨は引出しや送金が停止になってしまっているため、コインチェック一本でやっていた方は利益の確定すら許されず、残った仮想通貨を処分して納税することも難しい状況です。

税金に関して、普通に考えれば仮想通貨投資家に対してこの件で救済措置が取られる可能性は限りなくゼロに近いと思われます。

租税債務は自己破産をしても消滅しません。

確定申告をしない場合には無申告加算税を含む厳しい措置が取られる可能性があるので、まずは確実に確定申告を行うようにしましょう。

2017年はもう終わってしまいましたので、残念ながら今から利益を調整することは出来ませんが、 国税には一定の要件を満たす場合に納税の猶予が認められる場合がある「換価の猶予」という制度が存在します。

[手続名]換価の猶予の申請手続|納税証明書及び納税手続関係|国税庁

https://www.nta.go.jp/shiraberu/ippanjoho/pamph/sonota/itiji_leaflet.pdf

厳しい現実ですが、利益を確定させるときは納税まで意識することが投資の鉄則ですね。

Webサービスの障害対応を終えて、、、

f:id:boost-up:20180124130503j:plain

暫く更新が滞ってしまいました。

前回の記事で、SCDB JAPANに年末からBingクローラーのアクセスが急増し始めた事と、それによってRedisに障害が起きたことを書きました。

blog.boost-up.net

Redisの障害は正月のうちに何とか対応を終えたのですが、その後もBingクローラーのアクセスは増え続け、日に20万アクセスを超えるようになりました。

クローラーのアクセスが増えることは、将来的にサーチエンジン経由での流入に繋がる可能性が高いので、基本的に嬉しいのですが、 実は年明けにRedisの件の他にもう1件、原因不明の障害が発生し、つい先日まで対応にかかりきりになっていました。

今回の障害は2台で負荷分散しているWebサーバがほぼ同時に通信を受け付けなくなるというもので、 障害が発生するとhttpだけでなくsshも受け付けなくなります。 他方、pingは通りますし、サーバ自体は活きておき、クラウドサービスのコンソール経由ではログインも出来ます。 tcpコネクションやローカルポートの枯渇も疑いましたがこちらは問題なさそうです。

困ったのは各サービスのログにもOSのログにも、それらしいエラーが何も記録されていないことでした。

決して負荷が高くないときでも2台が同時に通信不能となることから、Webサーバ側ではなく、ネットワーク周りかバックエンドのDBサーバ側に問題がある可能性も疑われる状況です。

ただ、バックエンドのサーバの多くは上場企業サーチと共有しているのですが、その上場企業サーチにはまったく影響が出ていないため、バックエンド側の可能性は低いと思われました。

それでも一応一通り各サーバのログは調べたところ、障害発生時に一回だけ、DB側との接続が切れたログがありました。

そこで、SCDB JAPANと上場企業サーチのDB接続周りの設定を比べたところ、1箇所だけ異なる点が見つかりました。

上場企業サーチはDBサーバに直接繋ぎに行くようになっている一方、SCDB JAPANは冗長化を試行錯誤する過程で、仮想ルータのロードバランサを経由してDBに繋ぎ行くようになっているのですが、改めて見るとグローバルIPを指定してしまっています。 本来なら内部ロードバランスには仮想ルータのプライベートIPを指定すべきなのかもしれません。

そこで、上場企業サーチと同じように直接接続に戻して再起動をかけたところ、めでたく現象が発生しなくなりました。

上場企業サーチに影響が出なかった理由は継続調査中ですが、何とか年末から続いていたゴタゴタも収束しました。 怪我の功名でサービスの安定性も向上させることができ、ワンステージ上のトラフィックにも対応できる体制が整ったと信じています。

今年こそはサービスの成長と躍進に向けて進んでいきたいと思います。

日々勝負

<解決済み>Bingクローラ急襲によりサーバが応答不能に。。。

2018年最初の投稿になります。

早速ですが、年始からSCDB JAPANにちょっとした事件(障害)がありました。 正月休みを返上して(というのはだいぶ大袈裟ですが)原因調査と対応に当たりましたのでその一部始終を記載します。

Bing襲来!?(Welcome!!)

f:id:boost-up:20180105215551p:plain

上はBingウェブマスターツール上から確認できるBingクローラーのアクセス状況です。

従来は1日当たりのクロール数は概ね数千から2万ページ程度だったのですが、 12月28日あたりからアクセス数が急増し始め、1月2日~本日まで10万ページ/日を記録し続けています。

1月1日までは「いよいよXデーが近いか」と期待して見守っていたのですが、1月2日の夕方に事件が起きました。

Redisサーバと正常な通信ができない事態が発生

blog.boost-up.net

上記の過去記事で、冗長化の話を書いたとき、 SCDB JAPANは100倍のアクセスが来ても耐えられると調子に乗って宣言していたのですが、 恥ずかしながら、たかが10倍程度のアクセスでまさかのサービス停止に追い込まれる障害を発生させてしまいました。

Webサーバの負荷

SCDB JAPANはフロントにLVSサーバを配置し、WebサーバはH2Oサーバ2台構成でロードバランシングを行っています。 Bingからのアクセスが急増し始めた後の1月1日の時点でも、CPU使用率はまだ一桁台、メモリ使用率もまだ50%を切る状況で十分に余裕がありましたので、この程度のアクセスが翌日のサービスダウンに繋がるとは初夢にも思いませんでした。

500エラーの急増とOOMの多発

Webサーバの負荷が十分低いにも関わらず、1月2日の18時頃から500エラーが急増し始めました。 実際にブラウザでアクセスしてもWebページが表示されず、一人緊急対策会議を始めました。

unicornのログ

まず調べたのはアプリケーションサーバであるunicornのログです。 恐れていた通り”FATAL”という致命的なエラーが発生してしまっています。

F, [2018-01-02T18:10:50.417908 #82334] FATAL -- : [6849ed35-e5bf-472e-8bf1-3da7413842a2] ActionView::Template::Error (OOM command not allowed when used memory > 'maxmemory'.):

このエラーメッセージをヒントにググってみると、先人の経験から、どうやらこのエラーはRedisに関して発生している可能性が高いことが分かりました。

qiita.com

SCDB JAPANではキャッシュサーバとアクセス数集計サーバにRedisを使っており、 リソースはまだ最低限しか割り当てていませんので、十分に可能性が考えられました。

キャッシュサーバ用のRedisとアクセス数集計サーバのRedisは別サーバで運営しているのですが、 普段、アクセス数集計サービスの方が数倍の負荷がかかっていることを見ていたこともあって、先入観からアクセス数集計サービスの方が原因と思い込んでしまい、対応に時間を要する羽目になりました。

先人の経験を参考に同様の対策を施してサービスを再起動しても減少は解消せず、一旦手探り状態となりました。

Redis以外の原因を疑う

Webサーバ越しにアクセスすると500エラーが頻発する状況の中、本番環境上のRails consoleを使ってRedisへの疎通を確認すると、キャッシュサーバ、アクセス数集計サーバともに、全くエラーなく接続できる状況だったため、Redis以外に原因がある可能性も否定できませんでした。

LVSサーバのログを調べたり、ロードバランサ越しのアクセスではなく、直接Webサーバに接続するなどして挙動を見ていましたが、LVSやWebサーバ自体のログには問題となりそうな異常は見つけられませんでした。

TCP接続エラーを疑う

解決のヒントを探して色々なブログ記事などを見ている中で、一つ気になる情報を見つけました。

dsas.blog.klab.org

この記事はmemcachedに関する記事なのですが、SCDBのredisもキャッシュサーバを担っていることから、もしかしてと思い調べてみることにしました。

キャッシュサーバのsomaxconn(TCPソケットが受け付けた接続要求を格納するキューの最大長)の設定値を調べてみます。

$ sysctl net.core.somaxconn
net.core.somaxconn = 128

、、、自らの知識不足に情けなさを感じると同時に、一筋の光が差した思いがしました。

念のため、netstatも見てみます。

Tcp:
    232712 active connections openings
    2956 passive connection openings
    13370619 failed connection attempts
    90 connection resets received
    5 connections established
    59221754 segments received
    39087217 segments send out
    10131 segments retransmited
    0 bad segments received.
    659 resets sent

上から3つ目に13370619 failed connection attemptsとあり、一千万を超えるTcp接続要求が失敗していることが判明しました。 この時点で疑惑は確信に変わりました。

somaxconnの設定値を変更する

早速sysctlの定義ファイルを作成し、somaxconnの設定値を変更します。 今回は128→4096に増やしてしばらく様子を見ることにします。

1.定義ファイルの作成

vi /etc/sysctl.d/custom.conf

net.core.somaxconn=4096

2.定義ファイルの反映

$sudo sysctl --system
(略)
* Applying /etc/sysctl.d/custom.conf ...
net.core.somaxconn = 4096
* Applying /etc/sysctl.conf ...

設定変更が反映されました。

3.Redisの再起動

$ systemctl restart redis.service

藁にも縋る思いでWebサーバ越しのアクセスを確認すると、待望の「http status 200」の文字が並び始めました!!

その後の経過

1月3日に対策を行って以降、この記事を書いている1月5日時点までにはその後問題は起きていません。 障害によってクロールペースがダウンすることが懸念されましたが、BingにもGoogleにも今のところ大きな変化は起きていないようです。

ただ今回設定した値の妥当性についてはまだ手探りですので、もしかしたらまたいつか同じ事象が起きる可能性があります。

実アクセスが原因でこの手の障害が起きてしまうと色々と損失が大きいので、正月という閑散期にクローラーが原因で起きたことは寧ろ非常にラッキーだったと言えると思います。

今回のようにクローラーではなく実アクセスを伴うようになって来ればサーバを増強する予算もついてくると思いますので、 財布と相談しながら早め早めに手を打てるように、今年も頑張りたいと思います。