確定申告シーズン到来

2019年の目標として「ブログ単独で利益が出るようにする」などと妄言を吐いてしまいましたが、 1月を思いの他忙しく過ごしてしまい、早くも2月になってしまいました。

仕事は少し落ち着きそうな感じが出てきましたが、ここから先2か月は個人的に繁忙期なので、 このままいくと2019年第1四半期はなんだかんだバタバタして終わりそうな気配が漂っています。

まずは2月と言えば確定申告シーズンです。

今年からはeTaxが進化し、ICカードリーダーが不要になったのと、スマホでも申告ができるようになったようですが、 まだまだ使い勝手が悪過ぎるので、おそらく今年もeTaxで申告書を作って、紙に印刷して提出するいつものパターンになりそうです。

完全に私事ですが、去年は色々とイベント盛りだくさんだった一年で、今年の確定申告はいつになく苦戦しています。

個人の所得税は給与所得や事業所得など10の区分に分類されていますが、 今年は数えてみたらなんと5つの区分で所得(損失)が発生しており、生まれて初めて、そして今後も書くことがないであろう申告書や明細書を書くのに四苦八苦しています。

www.nta.go.jp

税理士にお願いする手もないわけではないですが、 私の場合今年は確実に還付になるので、 この辺はできる限り自分でやることで余計なキャッシュアウトを避けたいところです。

個人の所得税の場合は2月16日から3月15日までが確定申告期間になりますが、 還付申告の場合は確定申告と異なり、1月1日から5年間行うことができます。 還付申告が早ければ早く入金されるので、キャッシュフローの観点からは一日も早く申告することがお得です。

過去の精算は1日も早く終わらせて思考を未来に向けなければ!

EC2停止時にEBSタイプを変更して課金を減らす作戦

今日はAWS関連のネタです。

AWSのEC2を使ってサーバを立てる場合、基本的にはEC2利用料とEC2にアタッチするEBS利用料がコストの大部分を占めると思います。 今回はEC2が止まっているという一定の条件下において、コストを抑える作戦をご紹介します。

EC2とEBSの課金体系

AWSは使った分だけ支払う従量課金が原則ですので、EC2はインスタンス(サーバ)が起動している間だけ課金されますが、 EBSはボリュームを確保している状態をもって使っていることになるため、サーバが稼働していても止まっていても関係なく、 さらに言えばサーバにアタッチされていない状態でも課金は発生します。

EC2もEBSも以下のAWSブログに記載されている通り、課金は1秒単位で計算されます。 aws.amazon.com

EBSの価格体系とコスト抑制の作戦

EC2がインスタンスタイプで料金単価が異なるように、 EBSの料金はボリュームサイズとボリュームタイプによって規定されます。 このうち、ボリュームサイズは拡張はできますが単純な方法での縮小は許可されていません。 そのため、当面の必要サイズを確保して、利用に応じて足りなくなってきたら拡張するのが基本的な使い方になります。

他方のボリュームタイプは主にIO性能の違いにより複数のタイプが用意されています。 通常はデフォルトである汎用SSD(gp2)を使うことが多いと思いますが、高いIO性能を必要とする場合はプロビジョンドIOPS SSD (io1)を使ったり、逆にIO性能が重要ではないボリュームの場合は、スループット最適化HDD (st1)やコールドHDD (sc1)といったHDDを採用することでコストを抑えることができます。

aws.amazon.com

オンプレ時代はサーバの設計時に各ディスクの用途や将来予測、求められるIO性能等から固定的にボリュームサイズとボリュームタイプを見積る必要がありましたが、 クラウド時代の現在ではボリュームサイズだけでなく、ボリュームタイプについても必要なときに必要なタイプを選択することができます。

今回の作戦は、EC2を停止している間はEBSタイプも安価なものに変更することでコスト削減を図ろうとするものです。 例えば、gp2は1GB当たり0.12USD/月ですが、sc1だと同0.03USD/月となるため、単純計算でコストを1/4にすることができます。

EBS ボリューム変更時の制限

上記の作戦が無条件に適用できればいいのですが、残念ながらAWSには一定の仕様制限があります。

docs.aws.amazon.com

AWSブログによると、次のような制限が存在します。

  1. 変更を行うために、ボリュームのデタッチやインスタンスの停止が必要になる場合もあります。
  2. ルートボリュームとしてインスタンスに接続されている gp2 ボリュームを st1 または sc1 ボリュームに変更することはできません。
  3. 要求されたボリュームサイズが st1 および sc1 ボリュームの最小サイズを下回る場合、gp2 ボリュームを st1 または sc1 ボリュームに変更することはできません。
  4. 既存の io1 ボリュームに 32,000 IOPS 以上のプロビジョニングを行う場合は、完全なパフォーマンスを確認するために、ボリュームをデタッチしてアタッチするか、インスタンスを再起動を実行する必要があります。
  5. EBS ボリュームのサイズを小さくすることはできません。
  6. ボリュームを変更した後、少なくとも 6 時間待ってから、同じボリュームにさらに変更を適用する前に、そのボリュームがin-use または available の状態にあることを確認してください。
  7. m3.medium インスタンスはボリュームの変更を完全にサポートしていますが、m3.large、m3.xlarge、および m3.2xlarge インスタンスのいくつかは、すべてのボリューム変更機能をサポートしているわけではありません。

結構制限が多いようにも見えますが、私の理解で簡潔に要約すると、以下の通りです。

現役世代のインスタンスタイプやボリュームタイプで構築された、 ルートボリュームを除く500GiB以上のボリュームについては、EBSタイプの変更が可能です。 ただし、頻繁な変更は許可されず、1度変更したら6時間は再度の変更はできません。 また、この変更は基本的にはEC2インスタンス起動中にオンラインで変更できますが、 一定の条件でio1を使用する場合はEC2の再起動等が必要が必要になります。

この作戦が使えるケース

開発機やテスト機など、24時間起動しておく必要がないインスタンスに対して適用することを想定しています。 例えば、データベース領域をルートボリュームとは別に専用のEBSとして設計することで、停止期間中のコストを大幅に抑えることが可能になります。

2019年の目標

一年の計は元旦にあり、ということで仕事も始まりましたが今年の目標を宣言することにしました。

去年はエネルギーを発散しまくってあまり結果が得られなかったので、2019年はもう少し的を絞りたいと思います。

 

1. 資格を3つ取る

10年近く資格熱が冷めてしまっているため、暖まるまで時間がかかりそうな気もしますが、2019年は資格を3つ取ります!

何を取るかはまだ悩み中ですが、とりあえず1つ目はAWS Certificate Cloud Practitionerを狙ってます。

AWSはこれまで遠い存在だったのですが、去年から仕事で関わる機会が増えました。

実際に触れてみて、これは社会インフラだと実感しました。既にサーバーの立て方なんか知らなくてもアプリケーションをリリース出来る時代ですが、そんな時流の中でこそ、インフラを理解することは重要だと思います。

ということで、まずはAWS、その先は取ってから考えます。

 

2. 新しいWebサービスを1つ作る

これまでの努力の甲斐あって、上場企業サーチ.comとscdb.jpが順調に推移していますが、私はWebサービスは資産だと考えています。

実際にこれまで色々な金融資産や実物資産に投資してきましたが、個人的な向き不向きもあってか、絶対額はともかくとして情報資産がもっとも高利回りになりました。

Webサービスはサーバ運営費さえ回収出来れば後は全て利益になるのでローリスクです。

今年は何か3つ目のWebサービスを立ち上げ、情報資産ポートフォリオを拡充したいと思います。

今のところフワフワしたアイディアはいくつかありますが、コレというものはまだありません。

 

3. 1週間以上のバケーションを取る

去年は諸事情により出来なかったので今年こそは。。。

会社員でもメリハリつけて働きたい。

ちなみに、お盆、正月、GWなどの繁忙期は論外です。ピークを外して休むことに意義があります。

 

4. 5kg痩せる

正月久々に体重計に乗って絶句しました。

薄々感づいてはいましたが、私の中でのギリギリライン一歩前です。

10kgとか壮大な夢を語るとまた挫折するので、現実的にまず5kg落とします。

 

5. ブログ単独で利益が出るようにする

はてなブログProを使っていますが、今のところ完全に赤字です。

元々営利ブログを意図したものではないので当然と言えば当然ですが、ダラダラして書かない期間も長くなっているため、これはこれできちんと単独で利益が出るようにしようと思います

時事ネタを扱ってアフィリエイトに上手く誘導したりすればそれ程難しくないのかも知れませんが、性格的に自分が信じてないものを人に奨められない質なので、コツコツ記事を増やして収益を高めて行きたいと思います。

 

 

ということで、思いつくままに5つの目標をあげつらってみました。

今年こそは本気だします!

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

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

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

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

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

Step1:ようこそ

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

Step2:権限チェック

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

Step3:サイトの設定

f:id:boost-up:20181018084517p:plain あなたの店名、メールアドレス、管理画面ログインID、管理画面のパスワードを入れていきます。

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

セキュリティの設定

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

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

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

メールの設定

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

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

Step4:データベースの設定

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

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

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

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

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

f:id:boost-up:20181018085813p:plain 上の画面が表示されたらインストールは完了です。

ハマったこと

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

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

ログはインストールディレクトリからの相対パスで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}は取得したドメイン名と読み替えてください。

アクセスすると以下のページが表示されます。 「さあ、始めましょう!」を押してください。 f:id:boost-up:20180810205224p:plain

データベース情報の入力

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

おわりに

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

この体験から思ったこと

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

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

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

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

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

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

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

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

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

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

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

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

blog.boost-up.net

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

XBRL版の有価証券報告書

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

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

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

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

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

XBRLのイメージ

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

※赤枠は加工です。 f:id:boost-up:20180711083956p:plain

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

※赤枠は加工です。 f:id:boost-up:20180711084153p:plain

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

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

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

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

PDFではこの辺です。 f:id:boost-up:20180711085211p:plain

次に、XBRLを示します。 f:id:boost-up:20180711085256p:plain

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

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

実際に、100行ほど上に行くと、下のようなタグがあります。 f:id:boost-up:20180711085859p:plain

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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