EC-Cube 4.0.0のインストールと気づいたこと

EC-Cube4.0.0がリリースされたので早速インストールしてみました。

中身は追々色々と見ながら書いていこうと思いますが、 とりあえず、インストールで引っかかった点を記録しておきます。

EC-Cube 4.0.0は画面の指示に従って操作すると簡単にインストールできます。 手順はたったの5ステップです。

Step1：ようこそ

基本的には「次へ進む」を押すだけです。 サイト情報の送信を承諾する場合には「送信を承諾する」をチェックします。

Step2：権限チェック

上記の画面が表示されればOKです。 エラーメッセージが表示される場合は大体サーバ上に配置したEC-Cubeのパーミッションが誤っています。 実行ユーザが必要なファイルに書き込みできるようにサーバ上で権限の変更を行う必要があります。

Step3：サイトの設定

あなたの店名、メールアドレス、管理画面ログインID、管理画面のパスワードを入れていきます。

管理画面のパスワードは1回しか入力が求められないため、 ここでミスるといきなりログインできなくなる可能性があります。。。

セキュリティの設定

管理画面のディレクトリ名は以下のようにURLの一部になります。 外部から推測されやすい名称は避けましょう。 「サイトへのアクセスをSSL（https）経由に制限します」は2018年現在は常識と言っていいと思います。 対応不可能な場合を除き、忘れずにチェックしておきましょう。

　https://[ドメイン名]/[管理画面のディレクトリ名]/

「管理画面へのアクセスを、以下のIPに制限します」は自分の通信環境次第です。 固定IPやプライベートネットワークからしかアクセスしない場合は設定しておいた方が安全ですね。

メールの設定

SMTPホスト、SMTPポート、SMTPユーザ、SMTPパスワードはそれぞれ適切な情報を入力します。 （この記事の本筋ではないので省略します）

ここまで終わったら「次へ進む」を押します。

Step4：データベースの設定

こちらはあらかじめ作っておいたデータベースへの接続情報を入力します。 最後に書きますが、ここにトラップがありました。。

必要な情報を入力したら「次へ進む」を押します。

Step5：データベースの初期化

新規インストールの場合は「次へ進む」を押すだけです。 インストールはサーバスペック等によっては多少変わるでしょうが、 私は1分もかからず終わりました。

Step6(Complete)：インストール完了

上の画面が表示されたらインストールは完了です。

ハマったこと

インストールの完了後、管理画面にログインしようとしたところ、システムエラーの画面が表示されました。 ユーザ用のトップページにアクセスしても同様にシステムエラーの画面が表示されます。

こういう時はまずはログを調べます。

ログはインストールディレクトリからの相対パスでvar/log/prod/site-yyyy-mm-dd.logにあります。 /var/logの方ではありませんので注意してください。

ログを見ると、データベースへのアクセスに失敗していることが分かりました。

次にデータベース接続情報を確認します。

データベース接続情報はインストールディレクトリ直下にある.envの16行目に書かれています。 DATABASE_URL="接続情報"

ここで、私が設定したパスワードと設定値が異なる事が分かりました。 私は「abc$defghijk」を設定したのですが、設定されていた値は「abcdefghijk」になっていました。 $が抜けています。。

DATABASE_URLを修正したり、データベースパスワードの方を変更してDATABASE_URLと合わせてみましたが、接続できませんでした。 （ここはEC-Cubeのキャッシュの考え方を正しく理解しているわけではないので、もしかしたら調査不足かもしれません。）

インストールが正常に完了していないリスクも考慮すると、パスワードを変えて再インストールすることが確実ですので、 データベースをdrop&createし、インストールディレクトリも削除&再展開してインストール作業をやり直しました。

改めてStep1からの手順を踏んで恐る恐るアクセスをしたところ、、、 無事に管理者用のログインが画面が表示されました！！

EC-Cube.4.0.0ではデータベースパスワードに$を使ってはいけないようです。

LHMP（CentOS、H2O、MySQL、PHP）＋Let's EncryptでWordPressを構築するまでの完全手順

LHMPとは

LAMP（Linux, Apache, MySQL, PHP）の構成をもじった私の造語です。 一般用語ではありませんのでご了承ください。

今回構築するWordPress環境

IaaSで調達したルート権限のあるサーバに以下の構成でインストールします。

OS

CentOS 7.5

Webサーバ

H2O 2.2

アプリケーションサーバ

PHP 7.2 (php-fpm)

データベースサーバ

MySQL 5.7

SSL証明書

Let's Encrypt

H2Oのインストール

インストール手順

過去記事参照（記事はCentOS7.3にインストールしたときの手順ですが全く同じです）

blog.boost-up.net

バージョン確認

h2o -v

実行結果

h2o version 2.2.5
OpenSSL: LibreSSL 2.4.5
mruby: YES

PHPのインストール

Webサーバにapacheを使う場合は割とmod_phpを使うことが多いのですが、 今回はphp-fpmを使ったサーバを構築します。

インストール手順

epelとremiリポジトリをインストールした後、yumで一括インストールします。

yum install epel-release
rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
yum -y install --enablerepo=remi,remi-php72 php php-devel php-mbstring php-pdo php-gd php-mcrypt php-mysql php-fpm

バージョン確認

php -version

実行結果

PHP 7.2.6 (cli) (built: May 23 2018 09:50:51) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies

MySQLのインストール

インストール前にMySQLと親戚関係にあるMariaDBのライブラリと既存のディレクトリを削除します。

yum remove mariadb-libs
rm -rf /var/lib/mysql/

インストール手順

yum localinstall http://dev.mysql.com/get/mysql57-community-release-el7-7.noarch.rpm
yum -y install mysql-community-server

バージョン確認

mysqld --version

実行結果

mysqld  Ver 5.7.22 for Linux on x86_64 (MySQL Community Server (GPL))

ここまでで、ソフトウェアのインストール作業は終了です。

Wordpressのダウンロード

最新版の取得

cd /{path-to-download}
wget https://ja.wordpress.org/latest-ja.tar.gz
tar zxvf latest-ja.tar.gz

{path-to-download}は任意のインストールディレクトリに読み替えてください。

{path-to-download}以下にWordpressが解凍されましたので、 ここからはこのパスを前提に各種の設定を進めていきます。

Let's Encryptの導入

無料のSSLサーバ証明書サービスであるLet's Encryptを導入します。 こちらは過去記事を参照して導入します。 過去記事はRails環境を構築する際に書いたものですが、WordPressでも同じです。

blog.boost-up.net

h2oの設定

ユーザとグループの作成

サービスを実行するユーザとそのユーザが所属するグループを作成します。 ここではいずれも「h2o」にしていますが、名称は何でも構いません。

groupadd h2o
useradd -g h2o --shell /sbin/nologin h2o

h2o.confの設定

h2oをyumでインストールした場合、h2o.confは"/etc/h2o/h2o.conf"にあります。

細かい設定は色々ありますが、今回は重要な部分のみ抜粋します。 環境や要件によって見直しが必要な部分があるかも知れません。

以下については適宜読み替えを行ってください。

{path-to-cert-file}にはLet's Encryptで作ったSSL証明書のパスを指定します。

{path-to-key-file}にはLet's Encryptで作った秘密鍵のパスを指定します。

{fqdn}にはドメイン名を指定します。このブログであれば“blog.boost-up.net”になります。

{path-to-wordpress}にはWordPressのディレクトリを指定します。解凍してできた最上位フォルダを含めて指定してください。

user: h2o  #実行ユーザ
gzip: ON  #コンテンツを圧縮して通信量削減を図る
http2-casper: ON  #接続してきたクライアントがキャッシュを持っている場合にserver-pushを行わないようにする

# php-fpmを利用するための設定
file.custom-handler:
  extension: .php
  fastcgi.connect:
    port: /var/run/php-fpm/php-fpm.sock
    type: unix

# リクエストされたURLがディレクトリの場合、以下のファイルが指定されたものとして処理
file.index: [ 'index.php', 'index.html' ]


# ホストの設定　※非SSLでのアクセスはSSLにリダイレクトします
hosts:
  "{fqdn}:443":
    header.add: "X-UA-Compatible: IE=Edge"
    listen:
      port: 443
      host: 0.0.0.0
      ssl:
        certificate-file: "{path-to-cert-file}"
        key-file: "{path-to-key-file}"
        # chpher-suiteは時代に合わせて見直す必要があります
        cipher-suite: "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"
        cipher-preference: server

    paths:
      "/":
        file.dir: {path-to-wordpress}
        redirect:
          url: /index.php/
          internal: YES
          status: 307

  "{fqdn}:80":
    listen:
      port: 80
      host: 0.0.0.0
    paths:
      "/":
        redirect:
          status: 301
          url: https://{fqdn}/

サービスの有効化と起動

systemctl enable h2o
systemctl start h2o
systemctl status h2o

画面にActive: active(running)と表示されれば正常に起動しています。 起動できない場合はh2o.confの文法や設定に誤りがあるので、"/var/log/message"などを確認しながら修正してください。

PHPの設定

php-fpm.confの設定

"/etc/php-fpm.conf"を見ると、以下のように他のconfファイルを読み込んでいることが分かります。

include=/etc/php-fpm.d/*.conf

今回は、読込先のフォルダにある"www.conf"を編集します。

実行ユーザとグループの変更

h2oユーザで実行するように変更します。 修正箇所は20行目辺りにあります。

; Unix user/group of processes
; Note: The user is mandatory. If the group is not set, the default user's group
;       will be used.
; RPM: apache user chosen to provide access to the same directories as httpd
user = h2o
; RPM: Keep a group allowed to write in log dir.
group = h2o

次に、38行目辺りを以下のように変更します。

;   '/path/to/unix/socket' - to listen on a unix socket.
; Note: This value is mandatory.
;listen = 127.0.0.1:9000
listen = /var/run/php-fpm/php-fpm.sock

同様に、45行目辺りも以下のように変更します。

; Set permissions for unix socket, if one is used. In Linux, read/write
; permissions must be set in order to allow connections from a web server.
; Default Values: user and group are set as the running user
;                 mode is set to 0660
listen.owner = h2o
listen.group = h2o
;listen.mode = 0660

次に、同一サーバ内のh2oからのみ接続できるように、allowed_clientsを指定します。 該当箇所は59行目付近になります。

; List of addresses (IPv4/IPv6) of FastCGI clients which are allowed to connect.
; Equivalent to the FCGI_WEB_SERVER_ADDRS environment variable in the original
; PHP FCGI (5.2.2+). Makes sense only with a tcp listening socket. Each address
; must be separated by a comma. If this value is left blank, connections will be
; accepted from any ip address.
; Default Value: any
listen.allowed_clients = 127.0.0.1

ここまで変更したら保存して閉じます。

サービスの有効化と起動

systemctl enable php-fpm
systemctl start php-fpm
systemctl status php-fpm

画面にActive: active(running)と表示されれば正常に起動しています。 起動できない場合はphp-fpm.conf(www.conf)の文法や設定に誤りがあるので、"/var/log/message"などを確認しながら修正してください。

MySQLの設定

初期パスワードの変更

まずはインストール時に自動生成されているパスワードを確認するため、"/var/log/mysqld.log"を開きます。 「temporary password」などでファイル内を検索すると以下のような記述が見つかると思います。

2018-06-04T14:40:32.797547Z 1 [Note] A temporary password is generated for root@localhost: {initial_password}

ここで、{initial_password}の箇所に記載されているのが初期パスワードになりますので、コピーするなどして記録しておきます。

MySQLの初期化

以下のコマンドを実行し、画面の指示に従って作業を進めます。

$ mysql_secure_installation

最初に「Enter password for user root:」と聞かれますので、ここで先ほど確認した初期パスワードを入力します。 以降は画面の指示に従って必要な情報を入力します（この部分は他のサイトで細かく解説しているところが沢山あるので省略します）。

データベースの作成

先ほど変更した新パスワードを使ってMySQLにログインします。 以下のコマンドを実行して「Enter password:」と表示されたら新パスワードを入力してください。

$ mysql -u root -p
Enter password:

ログインに成功すると以下が表示されます。

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 15681
Server version: 5.7.22 MySQL Community Server (GPL)

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

以下のコマンドを発行してデータベースを作成します。

{database_name}は作成したい任意のデータベース名を入力してください。 絵文字なども扱えるように、文字コードセットには"utf8mb4"を指定します。

mysql> CREATE DATABASE {database_name} CHARACTER SET utf8mb4;

次にデータベースの管理者ユーザを作成するため、以下のコマンドを実行します。

{db_user_name}には任意のDB管理者ユーザ名を、{db_user_password}には任意のDB管理者パスワードを指定します。 パスワードの複雑さ要件を満たすよう注意してください。

mysql> GRANT ALL PRIVILEGES ON {database_name}.* TO {db_user_name}@localhost IDENTIFIED BY '{db_user_password}';

エラーなくコマンドが実行出来たら、最後に以下のコマンドを実行し、変更を確定させます。

mysql> FLUSH PRIVILEGES;

以上でMySQLの設定は完了です。

ここで作った「データベース名」、「DB管理者ユーザ名」、「DB管理者パスワード」はこの後のWordPressのインストールで使用しますので控えておいてください。

Wordpressのインストール

いよいよ最後のWordpressのインストールを行います。

インストールページのURL

ブラウザを起動し、次のURLにアクセスします。 https://{fqdn}/wp-admin/install.php

{fqdn}は取得したドメイン名と読み替えてください。

アクセスすると以下のページが表示されます。 「さあ、始めましょう！」を押してください。

データベース情報の入力

次のページに進むと、データベースの情報を入力するように求められます。

上から３つ、「データベース名」、「ユーザー名」、「パスワード」には、 先ほどMySQLの設定のところで確認した「データベース名」、「DB管理者ユーザ名」、「DB管理者パスワード」をそれぞれ入力してください。

データベースのホスト名は、今回のようにWordPressと同じサーバでMySQLを動かす場合は「localhost」のままで大丈夫です。 WordpressをインストールするサーバとMySQLがインストールするサーバが異なる場合は、MySQLサーバのIPアドレスなどを入力することになります。

テーブル接頭辞は「_wp」のままでも構いませんが、少しでもセキュリティを高めておきたい場合は任意の文字列に変更しておきましょう。

入力し終わったら「送信」を押します。

「インストール実行」を押します。

サイト情報と管理者情報の入力

上の画面が表示されたらもう一息です。 以下の情報を入力していきます。 ここで設定する情報は後から変更できます。

サイトのタイトル：ブログのタイトルです。 ユーザ名：サイトの管理者IDです。 パスワード：サイトの管理者IDのパスワードです。出来るだけ複雑なものを使いましょう。 メールアドレス：サイトの管理者のメールアドレスです。 検索エンジンでの表示：世の人に見て欲しい場合はチェックしません。

ここまで入力したら、「Wordpressをインストール」を押します。

上のページが表示されたらWordPressの構築はすべて完了となります。 お疲れ様でした。

おわりに

ここまででサーバの構築は完了しましたが、WordPressで運営されているサーバを狙うクラッカーやBotが多数存在しており、日夜を問わず様々な不正アクセスのリスクがあります。 今回はセキュリティ面での対策には立ち入りませんが、WordPressサーバを自前で運営する場合は、セキュリティ対策を怠らないようにしましょう。

ヨドバシ・ドット・コムのお届け予定日時の連絡が正確すぎてちょっと怖い

ヨドバシエクストリームサービス便の配達スケジュールは分単位

先日、ヨドバシ・ドット・コムで消耗品を買った時の話です。

7月14日に買った商品の発送について、ヨドバシ・ドット・コムからメールが届きました。

ヨドバシエクストリームサービス便：ご注文商品配達開始のお知らせ

メールが届いたのは7月15日 12時54分です。 到着予定日時は、、っと、、！？

7月15日 13時28分頃、、 まさかの分単位です。

半信半疑ながら、ワクワクドキドキしながら待っていました。

電波時計が13:28を周り、30秒ほど過ぎた時です。 まさかの、ピンポーン♪！！？ ヨドバシエクストリームサービス便の到着です。

しかも、同サービスは他の宅配便サービスと異なりサインも不要で、玄関先で荷物を受け取るだけというシンプルさです。

配達員の方が帰られて程なくして、 またメールが届きました。

ヨドバシエクストリームサービス便：ご注文商品配達完了のお知らせ

■お届け日時 　07月15日（日）　13時29分頃　お渡ししました

ええ、確かに受け取りました。

この体験から思ったこと

実際には30分前に配達予定を通知されても、在宅でなければ受け取ることが難しいと思いますので、 凄いのは間違いないですが、冷静に考えると少々使いどころの難しい正確さのようにも思います。

むしろ、この仕掛けによって、その30分に予定している他の配達を正確にこなすことで、次の30分の精度も高まる効果を期待しているのではと邪推すると、 ロボットが配達する時代ならともかく、人間が配達する現代においては、配達員の方のストレスが心配です。

渋滞予測などはもはや当然として、暑くて倒れそうなときの休憩や急なトイレ、あるいはいつものお客さんとの少々の会話までもが全部否定されるか、それすらもAIなどにシステム的に予測されてバッファに組み込まれているか。

今日では、多くの企業ではシステムの上に立つ人（企画する側）と、システムに混み込まれる人（ユーザ）とが厳然と線引きされており、システムを企画するときにはどこからか専門家が現れるのが珍しくはありませんが、そのシステムが誰の為に何を優先するかによって、あるべきシステムは大きく異なります。

また、高品質と過剰品質の境界はとても曖昧で、人によってその境界は大きく違います。

そういう意味では私の感覚もあくまで個人的なものですが、一個人としては、宅配便で数分の正確さを競う先に幸せがあるとは思えません。

とはいいながら、時間が読めない宅配便は使いたくないですし、受取人の立場からは時間にルーズなよりは正確な方が有り難いのは間違いないわけで、人間立場変わればというか、勝手な生き物というか、匙加減が難しいです。

最近は多くの会社にシステム企画の部署が設けられていますが、彼らの思考が会社経営に与えるインパクトというのは非常に大きいんだなと、改めて思いました。

ヨドバシエクストリームサービス、 直訳すると、「ヨドバシの極端なサービス」。 名は体を表しているかも。。。

こんなこと書いてますが、分単位の事前連絡がなくてもサービス自体は大変便利なので、今後も使いたいと思います。

有価証券報告書の次世代タクソノミはそろそろ真剣に次世代を考えて欲しい

前回、「上場企業の有価証券報告書に対してモノ申したいこと」として、有価証券報告書にミスが含まれたまま開示されることがある点について書きましたが、言いたいこととしては実は今回が本丸となります。

blog.boost-up.net

今回はXBRLの中身に少しだけ入り込んでテクニカルな話をします。

XBRL版の有価証券報告書

有価証券報告書はPDF版とXBRL版の２種類が開示されており、 人が読む場合はPDF版、システムが処理する場合はXBRL版を使います。

XBRLというのは、eXtensible Business Reporting Languageの略称であり、事業報告のため標準化されたXMLベースの言語です。

その昔、有価証券報告書をはじめとする各種の開示書類は紙で提出されていました。 その後、PDF化されたファイルがインターネット経由で開示されるようになったものの、 PDFは（一定のテキスト検索はでいるとは言っても）テキストを画像化したファイルに過ぎず、 投資家が多くの企業の開示情報を処理するためには一つ一つ人間が読み込む必要がありました。

これでは折角IT化したのにやっていることは昔と変わらない、もっと効率的に処理する方法はないか、ということで発明されたのがXBRLになります。

XBRLはXMLベースの言語ですので、情報に対して自由にタグ付けして意味を持たせることが出来ます。 ただ、各企業が自由にタグ付けして開示したのではそれを受け取った投資家は結局各社のルールを理解して読み込まなければならなくなりますので、このタグ付けを標準化することで、企業間の比較可能性を確保しようとしたルールの一つがEdinetタクソノミという関係になります。

XBRLのイメージ

例えば、ユーグレナの最新事業年度の連結売上高を「主要な経営指標等の推移」で見ると、PDFでは次のように表示されています。

※赤枠は加工です。

これをXBRLで見ると次のように表現されます。

※赤枠は加工です。

「jpcrp_cor:NetSalesSummaryOfBusinessResults」が主要な経営指標等の推移における（連結）売上高を示すコードで、 「CurrentYearDuration」が最新の事業年度を示し、通貨は「JPY」、decimals="-3"は千円単位で表示することを意味します。 そして、タグに囲まれた値「13886603000」が値です。

これならXMLを扱う技術があればシステム的に処理できますね。

Edinetタクソノミの課題①　タグ付けが不十分

先ほどの連結売上高はわかりやすいのですが、 次に、上場企業サーチで拾い集めている「平均年間給与」という情報を見てみましょう。

PDFではこの辺です。

次に、XBRLを示します。

。。。あれ、タグがない？

現在のEdinetは全文XBRLを売りにしているものの、実は財務諸表や経営指標等など一部の計数情報以外はテキストブロック要素と呼ばれる文書のかたまり全体をタグ付けする形が採用されており、タグの中にはHTMLが記述されています。

実際に、100行ほど上に行くと、下のようなタグがあります。

要するに、５【従業員の状況】全体が「jpcrp_cor:InformationAboutEmployeesTextBlock」というテキストブロックとなっており、 ここから平均年間給与の情報を機械的に取得したいときには、利用者が要素内のHTMLを解析して文字列として取得しなければならないのです。

しかも、要素内のHTMLの記述は統一されておらず、はっきり言って100社あったら100通りの記述がされているのです。

数年前、初めてこの仕様を知ったときは愕然としました。

平均年間給与に関して言えば、ほぼ100%の企業が表で表現していますが、 ヘッダー行数、列数がバラバラであるうえに金額単位もバラバラ、挙句前回指摘したように表記されている金額単位と実際の金額が一致していないミスが存在する状況です。 表が行結合されていたりすると一層解析が面倒になります。

果たしてこれが利用者のことを考えた仕様と言えるでしょうか。

Edinetタクソノミの課題②　日本基準以外は標準化ができていない

EdinetにおけるXBRLの利用は、元々財務諸表から始まった経緯があり、以前は５【従業員の状況】などはXBRL化の対象ではありませんでした。 ところがここ数年、本丸である財務諸表に対するXBRLの適用について、大きな問題が起きています（少なくとも個人的には大問題だと思っています）。

XBRL化は標準化が前提となるため、例えば「売上高」や「現金」といった勘定科目に対して、原則として一意のタグを定義しなければなりません。 本来はそれを標準化するのがEdinetタクソノミのはずなのですが、実はEdinetタクソノミは未だ、事実上日本基準にしか対応していません。

以下は、金融庁 総務企画局 企業開示課が作成している平成29年2月版の「提出者別タクソノミ作成ガイドライン」の抜粋（赤線は加工）です。

赤線箇所を見ると、IFRSの詳細タグ付けは任意です。米国基準の詳細タグ付けはしない、と書かれています。 これが意味するところは以下の通りです。

例えば、上場企業の「のれん」の実態を調査する場合、 日本基準を採用している上場企業の場合、例えばルネサステクノロジのXBRLをみると、以下のような情報を見つけることができます。

「jppfs_cor:Goodwill」は日本基準での「のれん」を表します。この場合は17275000000(172億7,500万円)ということがわかります。

次に、IFRSを採用しているパナソニックのXBRLを見てみます。

わかりますか？ パナソニックの場合は、「のれん及び無形資産」としてグルーピングしており、 前期が”665,132”、今期が”738,251”がその金額になるのですが、データとしてみた場合、金額単位を特定することも困難です。 これが「詳細タグ付け」をしない場合の開示になります。

ちなみにこの例では「<jpcrp_cor:ConsolidatedStatementOfFinancialPositionIFRSTextBlock contextRef="CurrentYearDuration">」というタグで、IFRSに基づく連結財政状態計算書全体が一つのタグで括られています。

ハッキリ言って利用者からするとほぼ無価値です。これだったらPDF版を一社ずつ見ていった方が早いかもしれません。

Edinetタクソノミ、平成25年に「次世代Edinetタクソノミ」として導入されたのがこれです。 早くも次世代の登場を切に期待します。。。

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

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

blog.boost-up.net

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

有価証券報告書の信頼性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

xn--vckya7nx51ik9ay55a3l3a.com

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

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

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

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

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

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

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

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

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

Edinetコード一覧の入手方法

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

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

在処が分かりづらい。。

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

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

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

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

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

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

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

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

以下は、日本電気（NEC）の第180期の有価証券報告書の該当箇所になります。

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

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

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

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

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

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

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

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

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

blog.boost-up.net

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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