2018-05-02

AWS Certificate Manager (ACM)のアップデートのメールが来ていたので確認してみた

AWS ACM

「Update on Certificate Transparency(CT) with AWS Certificate Manager(ACM)」という件名のメールがAWSから来ていたので確認してみた。

Google Chromeに対応したACMのアップデート

AWSのACMに関する今回のアップデートは、以前に内容を確認したCertificate Transparency（「証明書の透明性」、以下「CT」）に関連してGoogle Chromeに対応するためのものです。
www.prj-alpha.biz
AWSからのメールにも記載していありますが、簡単にGoogle Chromeに対応したACMのアップデート内容を要約すると以下のようになります。

Google Chromeでは2018/04/30以降に発行されたSSL証明書では少なくとも2つのCTログに記録がない場合、Google Chrome上でエラーメッセージが表示される可能性があります。
これに対応して、ACMで発行したSSL証明書の発行/更新時にCTログに記録するように更新しました。これは2018/04/24から対応しています。

Google Chromeの対応が2018/04/30以降ということで2018/05/01前後にアップデート情報がAWSよりメールで送られています。ACMを利用しているサイトはAWSが対応するので、特に何か作業を行う必要はありません。ただし、CTログにはサブドメインを含むドメイン名が記載されるので、CTログに記載され公開されることで何かしら問題がある場合のみ対応が必要です。

Google ChromeでACMでSSL証明書を発行したサイトを見てみる

ACMで発行したSSL証明書を使用しているサイトをGoogle Chromeでアクセスしてみてエラーメッセージが出るか確認してみます。今回は以下の我々が運営しているウェブサイトで確認してみました。
home.prj-alpha.biz
Google Chromeで表示すると以下のようになりました。

ブラウザのアドレスの部分には「保護された通信」と表示されているので、エラーメッセージが出ることなくAWSの対応が適用され問題なくできているようです。念のためサブディレクトリについても確認しましたが同様に特に問題ありませんでした。
CTログの状況はその提唱者でもあるグーグルが以下で提供しています。
Google Transparency Report
ドメイン名を入力してCTログ数を確認して下さい。
※実際に問題があるサイトの場合、エラーメッセージがGoogle Chrome上でどのような形式で表示されるかは確認できていません。

まとめ

今回はACMのCT対応に関するアップデートついて、Google Chromeで問題ないか確認しました。ACMを使用してSSL証明書の発行している方は、念の為問題がないか確認して下さい。またACMを使用していないサイトでもGoogle Chromeで確認しSSL証明書が問題ないかを確認した方が良いと思われます。
ACM以外のSSL証明書を使用している方は認証局に一応対応状況を確認した方が良いと思います。

以上

2018-04-30

ドメインの変更時に、AWSのS3を利用して旧ドメインから301リダイレクトさせる方法

AWS S3 SEO

今回は独自ドメインで運用していたウェブサイトのドメイン名を変更した場合の対応を紹介します。
今回はサブドメイン名を変更した状態を想定し、変更前のドメイン名を「旧ドメイン名」としその値を「old.domain.com」、変更後のドメイン名を「新ドメイン名」としその値を「new.domain.com」と記載していきます。

ドメイン名を変更するとどんな影響があるか

これまで運用していたウェブサイトについてドメイン名を変更した場合の対応について考えます。運用サイトのドメイン名の変更作業自体は済んでいるものとします。

まずドメイン名を変更することで一番大きな影響は、旧ドメイン名でリンクした内容が問題になります。ユーザが旧ドメイン名でお気に入りに追加していたり、コンテンツの中に旧ドメイン名で設定されたリンクについて対応が必要になります。対応しないと旧ドメイン名に接続しに行きページが存在しませんという状態になってしまいます。
そしてグーグルの検索結果にも旧ドメイン名で表示されます。
今回はこの部分の対応について考えていきます。

法人などで変更対象のウェブサイトが名刺や会社案内などの印刷物に記載されている場合、刷り直しなどが必要になってくるものもあるでしょう。

対応方針

ドメイン名を変更した場合、旧ドメイン名から新ドメイン名に301リダイレクトさせるのが一般的な対応となります。301リダイレクトについては以下参照して下さい。

www.prj-alpha.biz

旧ドメインにアクセスしてきたリクエストを新ドメインに301リダイレクトするには、Apacheなどのウェブサーバの設定の変更で対応することができますが、サーバの設定を変更できない場合があります。例えばこのはてなブログなどです。
このようなときに簡単な設定で301リダイレクトする方法を検討してみたいと思います。ドメインを取得する際に利用したドメイン登録サービスでリダイレクトするサービスを提供しているものがあります。ただしそのリダイレクトが301リダイレクトか確認する必要があります。例えばお名前ドットコムではURL転送Plusというサービスがありますが、これは302リダイレクトになっているようです。
AWSの Amazon S3（以下、S3）でリダイレクトができるようなので、今回はそれを利用することにします。

AWSのS3による301リダイレクト

S3はAWSのクラウドストレージサービスですが、静的ウェブホスティングの機能によりストレージにアップロードしたファイルをウェブサーバのように静的コンテンツとしてHTTP でやり取りすることができます。更にこの機能の中にはリダイレクトする機能があります。

S3のリダイレクト機能にはいくつかの方法がありますが、今回は一番簡単なバケットによるリダイレクト設定を行います。バケットの設定のみで、バケットにはファイルは不要です。
旧ドメイン名でS3の静的ウェブホスティングを行い、そこにきたリクエストを新ドメイン名にリダイレクトするように設定します。

S3を設定する

まずはバケットを作成します。名称は旧ドメイン名で作成します。これは独自ドメインでの静的ウェブホスティングするための制約です。

今回は「old.domain.com」となります。その他の設定はいったんなしで作成します。作成が完了した時点で、エンドポイントが確認できます。プロパティのタブを選択して、「Static website hosting」をクリックするとエンドポイントが表示されます。

Route53以外のドメイン登録サービスを利用している場合、独自ドメインのDNSにCNAMEレコードを作成して、このエンドポイントを登録することで独自ドメインでS3バケットが利用できます。

続いて、アクセス権限を設定します。アクセス権限のタブのベケットポリシーをクリックして以下のポリシーを設定して、パブリックユーザにGetObjectの権限を付与してアクセスできるようにします。Resourceの部分は旧ドメイン名となります。

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Sid":"AddPerm",
      "Effect":"Allow",
      "Principal": "*",
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::old.domain.com/*"]
    }
  ]
}

この状態で保存するとパブリックアクセス権が付与されたことが明示されます。

最後にリダイレクトの設定を行います。プロパティのタブを選択して、「Static website hosting」をクリックして「リクエストをリダイレクトする」を選択し、リダイレクト先に新ドメイン名を入力します。http/httpsを指定したい場合はプロトコルに設定します。

これで旧ドメインへのリクエストはバケットの設定により、全て新ドメインのホストにリダイレクトされることになります。このリダイレクトの設定はサブディレクトリも含まれます。

その他のリダイレクト設定は公式ページを参照して下さい。

docs.aws.amazon.com

301リダイレクトの設定ができているか確認する

設定ができた後に問題ないか確認しましょう。一番簡単なのはブラウザで旧ドメイン名をURLに入力して新ドメイン名に変更されるか確認する方法です。

この他に以下のサイトでは301リダイレクトされているかステータスコードが確認することができます。

HTTP Header Response Status Codes Check Tool

URLに旧ドメイン名を入力して、Checkボタンを押してしばらく待った後に以下のように301と結果が出ていれば問題ありません。

新ドメイン名 - 301 Moved Permanently
旧ドメイン名 - 200 OK

サブディレクトリが問題ないかもこちらで確認することができます。

ドメイン名に変更に関連して、その他にやること

ドメイン名に変更に関連してURLを保持しているシステムなどの設定も変更が必要になります。SEO関連のツールではグーグルの Google Analytics 、 Search Console はきっちり変更しましょう。特に Search Console はグーグルの検索結果のインデックスに影響しますので必ず対応しましょう。

www.prj-alpha.biz

まとめ

今回はAWSのS3を利用しての301リダイレクトの紹介でした。

以上

【関連するリンク】

www.prj-alpha.biz

2018-04-28

LaravelのマイグレーションでPKの設定時に注意する

Laravel Laravel5.5 PHP MySQL

今回はPHPフレームワークの一つのLaravelの中から、データベースのマイグレーションでのプライマリキー（以下、PK）の設定の注意事項について説明します。ユニークとインデックスから説明し、その後にPKについて説明します。

マイグレーションファイルでのユニークとインデックスの設定

以下はLaravelのマイグレーションファイルでのユニークとインデックスの設定例です。

    public function up()
    {
        Schema::create('samples', function (Blueprint $table) {
            $table->string('column_name1',5);
            $table->string('column_name2',5);
            $table->string('column_name3',5);
            $table->string('column_name4',5);
            $table->string('column_name5',5);
            $table->timestamps();
            
            //ユニーク設定
            $table->unique(['column_name1','column_name2','column_name3','column_name4']);
            //インデックス設定
            $table->index(['column_name2','column_name3','column_name4','column_name5']);
        });
    }

テーブルの定義の後にユニークとインデックスの設定をしています。基本的な設定方法はこの書き方になりますが、これを実行すると以下のようなエラーとなります。

$ php artisan migrate

SQLSTATE[42000]: Syntax error or access violation: 1059 Identifier name 'samples_column_name1_column_name2
_column_name3_column_name4_unique' is too long (SQL: alter table `samples` add unique `samples_column_name1
_column_name2_column_name3_column_name4_unique`(`column_name1`, `column_name2`, `column_name3`, 
`column_name4`))

これは自動で付与されるカラム名を連結したユニーク名称「samples_column1_column2_column3_column4_column5_unique」が長すぎるのが原因で発生しています。インデックスの設定についても同様の名称が設定されてエラーとなります。このため以下のようにして、名称を設定をします。

            //ユニーク設定
            $table->unique(['column_name1','column_name2','column_name3','column_name4'],'UNIQUE_NAME');
            //インデックス設定
            $table->index(['column_name2','column_name3','column_name4','column_name5'],'INDEX_NAME');

名称を設定することでエラーがなくなります。名称が設定されているかは以下のSQLで確認します。

select table_name,index_name,column_name,seq_in_index from information_schema.statistics
where table_name = 'samples';

結果は以下のようになっています。

table_name	index_name	column_name	seq_in_index
samples	UNIQUE_NAME	column_name1	1
samples	UNIQUE_NAME	column_name2	2
samples	UNIQUE_NAME	column_name3	3
samples	UNIQUE_NAME	column_name4	4
samples	INDEX_NAME	column_name2	1
samples	INDEX_NAME	column_name3	2
samples	INDEX_NAME	column_name4	3
samples	INDEX_NAME	column_name5	4

マイグレーションファイルでのPKの設定

続いてはLaravelのマイグレーションファイルでのPKの設定例です。

    public function up()
    {
        Schema::create('samples', function (Blueprint $table) {
            $table->string('column_name1',5);
            $table->string('column_name2',5);
            $table->string('column_name3',5);
            $table->string('column_name4',5);
            $table->string('column_name5',5);
            $table->timestamps();
            
            //PK設定
            $table->primary(['column_name1','column_name2','column_name3','column_name4']);
        });
    }

これを実行すると以下のようなエラーとなります。

$ php artisan migrate

SQLSTATE[42000]: Syntax error or access violation: 1059 Identifier name 'samples_column_name1_column_name2
_column_name3_column_name4_primary' is too long (SQL: alter table `samples` add primary key `samples_column
_name1_column_name2_column_name3_column_name4_primary`(`column_name1`, `column_name2`, `column_name3`
, `column_name4`))

PK設定についてもユニークやインデックスと同じようにカラム名を連結した名称をつけるように動作しているようです。通常、PK設定の場合は「PRIMARY」となるのですが、この自動で設定された名称が原因でエラーとなります。この対応として、ユニークやインデックスと同じように名称を設定することで回避することができます。

            //PK設定
            $table->primary(['column_name1','column_name2','column_name3','column_name4'],'DUMMY_NAME');

SQLの結果は以下のようになっています。設定した「DUMMY_NAME」は出てきません。

table_name	index_name	column_name	seq_in_index
samples	PRIMARY	column_name1	1
samples	PRIMARY	column_name2	2
samples	PRIMARY	column_name3	3
samples	PRIMARY	column_name4	4

ちなみに、以下のように「'PRIMARY'」として設定して実行しましょう。

            //PK設定
            $table->primary(['column_name1','column_name2','column_name3','column_name4'],'DUMMY_NAME');

すると以下のようなエラーとなります。これは「PRIMARY」はインデックス名称としては使用できないためです。

$ php artisan migrate

SQLSTATE[42000]: Syntax error or access violation: 1280 Incorrect index name 'PRIMARY' 
(SQL: alter table `samples` add primary key `PRIMARY`(`column_name1`, `column_name2`, `column_name3`
, `column_name4`))

PKの設定では通常は名称の設定は不要ですが、エラーとなった場合はダミーの名称を設定することで回避することができます。ここに注意してマイグレーションファイルを設定しましょう。

まとめ

今回はLaravelのマイグレーションのPK、ユニーク、インデックスの設定を説明しました。

以上

【関連するリンク】 www.prj-alpha.biz www.prj-alpha.biz www.prj-alpha.biz www.prj-alpha.biz

2018-04-27

301リダイレクトと302リダイレクト

SEO

今回は運用していたウェブサイトのドメイン名を変更した場合、変更前のドメインから変更後のドメインへリダイレクトの対応をすることが多いですが、そのリダイレクトのt対応について説明します。

ステータスコードとリダイレクト

301リダイレクト、302リダイレクトなどと言われる際の最初の3桁の数字はHTTPステータスコードのことを示しています。HTTPステータスコードとは以下になります。

HTTPステータスコードは、HTTPにおいてWebサーバからのレスポンスの意味を表現する3桁の数字からなるコードで、RFC 2616、RFC 7231等によって定められている。
（Wikipediaより引用）

「404 Not found」とかの「404」もこのステータスコードの一つです。

またウェブサイトにおけるリダイレクトとは以下になります。

ウェブサイトにおけるリダイレクト（英:redirect）とは、ウェブサイトの閲覧において、指定したウェブページから自動的に他のウェブページに転送されること。URLリダイレクト（URL redirection）とも言われる。
（Wikipediaより引用）

ドメイン変更を例にするとリダイレクトを設定することで、ユーザが変更前のドメインのURLに接続した場合に自動で変更後のURLに転送することで、常に新しいURLに接続させることができます。

301/302のステータスコードの違い

リダイレクトする際のステータスコードから、「301リダイレクト」と「302リダイレクト」と呼ばれたりしますが、リダイレクトの内容でどちらにするか検討します。

301：恒久的な変更
302：一時的な変更

301リダイレクト

恒久的に変更された場合はこのステータスコードを使用します。この301リダイレクトの使用例としてグーグルは以下のような場合を提示していました。

サイトを新しいドメインに移動し、できるだけスムーズに移行を行いたい場合
ユーザーが複数の異なる URL を介してサイトにアクセスする場合
2 つのウェブサイトを結合し、無効になった URL へのリンクが正しいページにリダイレクトされるようにしたい場合

support.google.com

ドメイン変更は正しく恒久的な変更となりますので、301リダイレクトを用います。
グーグルの提供する「Search Console」ではウェブサイト毎にグーグル検索結果でのパフォーマンスを監視・管理することができます。ウェブサイトのドメインが変更された場合、この「Search Console」でも監視・管理するウェブサイトのアドレスを変更して引き継ぐことが可能ですが、変更できる条件として301リダイレクトで動作していることがあります。この「Search Console」の変更により、変更後のサイトに変更前のサイトインデックス登録を移行しますので、SEO対策上では大きな意味を持ちます。このことも考慮して恒久的な変更の場合は301リダイレクトするようにしましょう。

302リダイレクト

一時的に変更された場合はこのステータスコードを使用します。一定期間だけメンテナンス画面にリダイレクトさせたいときなどが使用例です。

302リダイレクトの場合、グーグルの検索エンジンはリダイレクト後のページではなく、リダイレクト前のページを評価し続けます。ある程度の期間が長くなる場合はSEO対策上は302リダイレクトを避ける方が良さそうです。

301リダイレクトの設定はどの位の期間まで継続させるか

301リダイレクトは、ドメイン変更など恒久的な変更に対して、変更前へのURLへのアクセスを変更後の新しいURLへ転送するための設定であることは理解できたかと思います。この設定はどの位の期間まで継続させるのが良いでしょうか。
グーグルが新しいサイトやURLをフルに認識するには6ヶ月程はかかる場合があるようです。「Search Console」の変更リクエストの説明にも180日間は検索結果を自動で新しいサイトにリダイレクトするとあります。また変更前のURLにアクセスしようとするユーザーも十分に発生する可能性があるでしょう。
これらを踏まえると最低でも1年間は継続させておくことが良さそうで、可能であればできるだけそのままにしておくのが良いとのことです。

まとめ

今回はドメイン名を変更した場合などに対応するリダイレクトの説明でした。

以上

【関連するリンク】

www.prj-alpha.biz

2018-04-13

ガントチャート作成ツールのタイプ別の使い方

プロジェクト管理ガントチャート

ガントチャートを作成するツールには様々なものがありますが、タイプを別けて説明します。ガントチャートで管理される対象をプロジェクトと呼ぶこととします。プロジェクトは一定期間など期限のある活動で何らかの終了条件があるものとします。

ガントチャートの作成ツールのタイプ

ガントチャートの作成ツールはいくつもありますが、大きく2種類に別けることができます。①直接入力型と②積上げ型と命名してそれぞれの特徴や使い方、有効な利用方法を説明していきます。

またガントチャートを構成する行はタスク、チケットなどと色々な呼び方がありますが、アクティビティという表現で統一します。

①直接入力型

直接入力型とは、一覧表形式の入力欄に登録していくと、主にその右側にその入力内容に対応したチャートができる、ガントチャートを直接作成するタイプのツールです。代表例はMicrosoft Projectです。Excelで作成されたものもこのタイプということになります。我々の開発しているProject-Alphaもこのタイプです。

入力管理

このタイプでは、ガントチャートの更新を行うのはプロジェクトの管理者など一部のメンバーに限定して運用することが望ましい場合が多いです。
一覧表形式となっているため更新可能なメンバーは、全てのアクティビティについて編集可能となります。そのため誰でも更新できるようになっていると、自身の担当以外など予期せぬところを間違って編集してしまったりする可能性があるので、管理者など一部のメンバーが責任をもって管理した方が良いでしょう。またExcelなどではファイル共有機能で同時に編集することもできますが、同時で複数人で編集していると前後関係がおかしくなったりと意図しない結果になることもあります。

アクティビティに関連する特徴

アクティビティは管理者が登録するので、ある程度統一された粒度で管理する運用が可能となります。必要に応じて一部は細かい粒度で管理するといったこともあるでしょう。
管理者一人で更新する運用の場合、アクティビティの数が多いとステータスの変更など更新作業に多くの時間を割かれることになりますが、細かくすることで工数や進捗管理の精度が上がります。この辺りのバランスを考慮してガントチャート上でどの粒度で管理するか、プロジェクトの内容や性質、管理者の能力や性格に合わせて変わってくることになります。内容や期間にもよりますが200行を超えた辺りから苦しくなり始め、300行を超えるとガントチャート上での運用がかなり厳しいイメージです。この厳しいとは、「管理ができなくなる」ということだけでなく、「管理はできてるが負荷が高くなる」ということも含みます。
ここで「ガントチャート上で」と記載していますが、プロジェクトを管理するためのツールはガントチャートだけではないので、適切なツールを併用して使用していけば良いのです。運用が厳しく感じたら、管理方法を見直すタイミングかもしれません。大事なのは全てをガントチャートで管理することではなく、プロジェクトを成功に導くことです。

報告資料としてのガントチャート

このタイプを選択する理由の一つとして、プロジェクトのステークホルダーに報告する資料としてガントチャートを作成するという場合があります。これはガントチャートが視認性に優れていて、ステークホルダーが誰でもアクティビティの順序や進捗状況、スケジュールを理解し易くすることができるためです。ただ行数が多くなるにつれて視認性はどうしても下がりますので、必要に応じて他の資料と合わせて報告すると良いでしょう。
報告資料としての用途の場合、以下のようなことがポイントとなります。

アクティビティはステークホルダーが分かる・求める粒度にする。細かくし過ぎると煩雑で確認しにくいと言われ、抽象化しまとめ過ぎると分かりにくいと言われることがあります。
お客様との会議体などで報告する必要があり、誰でも参照できる状態を求められることがあります。具体的には紙に印刷できることやExcel化、PDF化してファイルを配布するように求められることがあります。
報告資料用と実際のアクティビティ管理用のガントチャートを共通で利用できるか。共通利用できると、効率的な運用をすることが可能です。逆に二重管理のような状態になってしまうと、負荷が高まります。

有効な利用パターン

アクティビティがある程度パターンが決まっているプロジェクトでは、過去のプロジェクトの設定をそのまま利用することができるので有効です。プロジェクトの内容により変更が必要な部分だけアクティビティの追加・修正・削除すれば良いので効率的に準備をすることができます。
ガントチャート上で管理が必要なアクティビティの数が多すぎないプロジェクト（例えば100個程度など）は、ガントチャートの視認性を活かせるので有効です。プロジェクトの状況をガントチャートを介して素早く理解することができます。

②積上げ型

積上げ型とは、ガントチャートを構成するアクティビティを一つ一つ個別に登録していき、登録されたアクティビティをまとめて表示することでガントチャートとして表現することができるタイプのツールのことです。代表例はRedmineです。
このタイプのツールでは、ガントチャートは数ある機能の一つとして提供されており、アクティビティの管理に関連して様々な機能を持つプロジェクト管理ツールとして提供されていることが多いです。

入力管理

このタイプでは、アクティビティを登録できるのはプロジェクトに参加しているメンバー全員などで運用することが多いです。自分の担当や関連するアクティビティを各自が登録できるようにする運用イメージです。ただし外部の組織のメンバーなどで、ツールにアクセスする権限がない場合は代行して入力することになります。
各アクティビティにはファイルを添付したりコメントしたりと、アクティビティ毎に個別に情報を追加する機能を備えてるツールもあります。

アクティビティに関連する特徴

アクティビティは色々なメンバーが登録するので、アクティビティを管理する上で一定のルールを策定して運用するのが一般的です。
アクティビティに対して集約するための分類情報を紐付けたり、親となるアクティビティを紐付けて登録することが可能となっているツールが多く、それらを集約し、まとめて表示することでガントチャートとして表示する仕組みになっています。
プロジェクトが進んでいく中で、必要になったアクティビティをどんどん追加していくことが多く、細かい作業単位で登録していくことで作業漏れをなくしつつ着実に進捗を管理をしていく運用が多いです。

ガントチャート以外の様々な機能

このタイプはプロジェクト管理ツールの中の一つの機能としてガントチャートでの表示機能が備えられていることが多いです。ガントチャートはコアな機能ではなく、周辺機能の一つという扱いです。
プロジェクト管理ツールとして、ガントチャート以外では以下のような機能があることが多いです。

アクティビティをカンバン方式・カレンダー形式・タイムラインなど様々な形式で表示することができる。
アクティビティ以外にToDoリストが管理できる。
メンバー間でチャットやメッセージなどでコミュニケーションすることができる。
プロジェクト毎にWiki機能がある。

これらは代表的な機能ですが、プロジェクト管理ツールによって他にも様々な機能を有しているものがありますので、活用できる機能がないか確認してみて下さい。

有効な利用パターン

参加するメンバーの多いプロジェクトで、そのメンバー全員がプロジェクト管理ツールを利用することができる状況で有効です。全員が利用できるので、必要な情報共有を素早くすることができます。
アクティビティの追加頻度が高く、細かい単位で大量のアクティビティを管理していくプロジェクトの場合に有効です。

ただし、このタイプではプロジェクト管理として様々な機能を提供しているツールが多いので、それらを含めてどの機能をどのように利用するかによって効果が変わってきます。導入するにあたって影響を受ける業務範囲やメンバーを確認の上、有効に利用できるようにしましょう。

まとめ

今回はガントチャート作成ツールを①直接入力型と②積上げ型というタイプ別にして、それぞれの特徴を中心に説明しました。ガントチャートを利用した方が良い場合はこちらの情報で検討にお役立て下さい。

以上

【関連するリンク】

www.prj-alpha.biz

home.prj-alpha.biz

2018-04-06

IEで「margin: 0 auto;」の左右中央揃えが効かない？

CSS

現象と原因と真因

現象

IE以外で問題ないのですが、以下のように左右中央揃するためにmarginを設定している要素（以下、box）が、なぜか右寄せになってしまう現象が発生しました。

.box {
  margin: 0 auto;
}

原因

この発生条件は、marginを設定したboxの親要素（以下、container）に以下のように、「display:flex;」と「position: fixed;」を設定している場合にIEで表示するときです。

.container {
  display:flex;
  justify-content: center;
  align-items: center;

  position: fixed;
}

このflexとその下2行のCSSの設定（以下、「display:flex;」）は、これを設定したcontainerの子要素boxに対して上下左右中央揃えにするためのものです。つまりこの設定があれば、「margin: 0 auto;」の設定自体が不要です。
boxのmarginの設定をなくすと、以下のように上下左右中央揃えで表示されました。

ちなみにcontainerのpositionをfixed以外にした場合も上下左右中央揃えで表示されます。

真因

この現象、発生条件がかなり限られたものように思えますが、問題が発覚したのは以下のようなモーダルウィンドウです。

当初はこのモーダルウィンドウのcontainerのCSSに以下のような設定をしていました。これはcontainerをブラウザ全体に広げて一番上に表示させるためです。

.container {
  z-index: 1000;
  position: fixed;
  top: 0;
  bottom: 0;
  left: 0;
  right: 0;
}

モーダルウィンドウは中央揃えにしたかったので「margin: 0 auto;」をしたのですが、上下中央揃えにはならない状態で設定を完了していました。
その後、上下中央揃えにするには「display:flex;」の設定でCSSで簡単にできるとのことを知って、containerのCSSに設定を追加したのです。「display:flex;」の設定で上下だけでなく左右も中央揃えになりますので、「margin: 0 auto;」は不要になりますが、そのままでもChromeなどのブラウザでは問題なかったので残してしまいました。
そしてIEでこの右寄せになる現象を見たときに、この残った設定の「margin: 0 auto;」を見て、IEで左右中央揃えが効かなくなってると勘違いしてしまったわけです。
設定変更時にIEで確認しなかったのも問題ですが、「設定の追加/変更を行う際に、以前の設定で不要になる部分を確認しなかった」のが今回の真因ですね。

というわけで、今回はIEでの「margin: 0 auto;」の左右中央揃えについてでした。

以上

2018-03-22

欧州「一般データ保護規則（GDPR）」の関連するリンクまとめ

法務

今回は2018年5月に施行される欧州のプライバシー法「一般データ保護規則（GDPR）」の関連するリンク集の紹介です。
まだまだ理解が進んでいないので、いったん参考にするための情報を集めておきました。

施行後の反応については以下を参考にして下さい。

www.prj-alpha.biz

GDPRの概要

2018年5月25日に、欧州のプライバシー法「一般データ保護規則 (GDPR)」が施行されます。GDPR は、EU加盟国（EU加盟国及び欧州経済領域（EEA）の一部であるアイスランド、ノルウェー、リヒテンシュタインを含む、以下同じ）の居住者に製品・サービスを提供する、あるいは EU加盟国の居住者に結び付くデータを収集、分析する企業、政府機関、非営利団体、その他の組織に課せられる規則です。GDPR は所在地に関係なく適用されます。

ここでポイントとなるのは「EUの居住者」というところ、組織の所在地は関係なく適用されるということです。国籍に関係なく（つまり日本人でも）「EUの居住者」に結び付くデータがGDPRの対象となり、所在地に関係ないので日本の企業も対象になりうるということです。

違反時の制裁金の規定がある

違反の内容により、制裁金が設定されています。かなり高額の設定となっています。

企業の全世界年間売上高の2％以下、または1000万ユーロ以下のいずれか高い方
企業の全世界年間売上高の4％以下、または2000万ユーロ以下のいずれか高い方

EU域外への個人データの移転について

GDPRではEU域内から域外への個人データの移転に関して規定があります。「十分な個人データ保護の保障」（欧州委員会が、データ移転先の国が十分なレベルの個人データ保護を保障していることを決定）があります。このように欧州委員会が「十分性の認定」をしている国地域は以下になります。
アルゼンチン共和国、アンドラ公国、イスラエル、ウルグアイ、東方共和国、英領ガーンジー、英領ジャージー、英領マン島、カナダ、スイス連邦、デンマーク自治領フェロー諸島、ニュージーランド、アメリカ合衆国（※プライバシーシールドに基づく）
ここに日本は含まれていません。

参考：個人情報保護委員会：GDPR（General Data Protection Regulation：一般データ保護規則）