皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

『iOS 13.4.1』のリリース後、『iOS 13.4.5』がリリースされると思いきや、『iOS 13.4』から約2ヶ月で『iOS 13.5』のリリースとなりました。

今日はその情報をお伝えします。

iOS 13.5リリースノート

以下、『iOS 13.5』のリリースノートになります。

iOS13.5では、マスク着用時にFace ID搭載デバイスのパスコードフィールドに素早くアクセスできるようになります。また、公的保健機関から提供される新型コロナウイルス感染症（COVID-19）接触追跡Appに対応する接触通知APIが導入されます。このアップデートにはさらに、グループFaceTime通話のビデオタイルを自動的に目立たせる機能を制御できるオプションが追加され、バグ修正およびその他の改善も含まれています。

＜Face IDとパスコード＞

・Face ID搭載デバイスでのマスク着用時のロック解除操作を簡略化

・マスク着用時にロック画面の下端から上にスワイプすると、パスコードフィールドが自動的に表示

・App Store、Apple Books、Apple Pay、iTunesや、Face IDでのサインインに対応するその他Appでの認証時にも使用可能

＜接触通知＞

・公的保健機関から提供される新型コロナウイルス感染症（COVID-19）接触追跡Appに対応する接触通知API

＜FaceTime＞

・グループFaceTime通話で参加者が話しているときにビデオタイルのサイズが変更されないように、自動的に目立たせる機能を制御できるオプション

＜その他の改善など＞

・一部のWebサイトからストリーミングビデオを再生しようとしたときに黒い画面が表示されることがある問題を修正

・共有シートでおすすめやアクションが読み込まれないことがある問題に対処

・etc…

以上のようになっています。

また、『iPadOS 13.5』も同時リリースされていますが、『iPadOS』には接触追跡機能は含まれていないようです。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

冒頭に書いた内容、知名度の高い企業などではあり得ない話ではありますが、そうではないローカルな事業者のサイトなどにおいては当り前のように存在します。

では何故そのような状態のままなのでしょうか？

アドレスバーが見られていない

いくつか理由はあると思いますが、商品などを購入するショッピングサイト以外、多くのWebサイトにおいてはあまり気にされていない気がします。

特に、現在主要なブラウザで『HTTPサイト』に表示されている『安全ではありません』や『保護されていない通信』などの警告表示は『アドレスバー』の先頭部分に表示されますが、そこはあまり気にされていないのではないでしょうか。

気にされていないというよりも目に入ってきていない気もします。

ただし、それは訪問するユーザー側の話です。

運営者側からすると、『コストをかけてまで．．．』といった、あまりユーザー保護を意識していない運営者が多いことも事実でしょう。

では、これがもっと極端なん施策がとられていたらどうでしょうか？

そのサイトにアクセスした途端、ページ全面に『安全ではありません』や『保護されていない通信』などの警告表示が出た場合です。

流石にそれ以上先へ進もうとはしないはずです。

これは極端な施策ではありますが、ユーザー保護を目的とするならばもう少し極端な施策を半ば強制的にでも行わせるくらいのことが必要なのかもしれません。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

最近流行り？の『ダークモード』、これに批判的な方もいるようですが個人的には気に入っています。

単純な話で、少しでも目の負担を軽減したい、見やすくしたいということからです。

（私はブルーライト軽減のために昼間でもiPhoneは『ナイトシフト』を使っています。）

しかし、ベースとなるOSや一部のアプリケーションはそれに対応しているものの、Webサイトに関してはほとんど対応していないように思えます。

今日はそんな『ダークモード』の話題です。

Webサイトをダークモードに対応させる

Webサイトを『ダークモード』に対応させるためには『prefers-color-scheme』というものを使います。

この『prefers-color-scheme』を使って『ダーク（黒）』の場合の条件をCSSに記述すれば対応できます。

@media (prefers-color-scheme: dark) {
body {
background-color: #000;
color: #fff;
}
}

といった感じです。

変更箇所が複数に渡る場合は『var(–変数)』で対応すると便利です。

:root {
–main-bg: #fff;
–main-text: #333;
}
@media (prefers-color-scheme: dark) {
:root {
–main-bg: #000;
–main-text: #fff;
}
}

body {
background-color: var(–main-bg);
color: var(–main-text);
}

といった感じです。

さて、どれくらいのWebサイトが『ダークモード』に対応していくのでしょうか．．．

それは、ライセンスの有効期限が切れたことが理由ではありませんでした。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

冒頭に書いた話しですが、私も知人から聞いて驚きました。

突然の強制的なライセンス失効です。

セキュリティソフト製品の購入元に注意

さて、私の知人がセキュリティソフトのライセンスを突然失効された理由ですが、そのライセンス、発端は『クレジットカード不正利用』です。

AさんのクレジットカードをBが不正利用してライセンス購入し、それをCさんに転売した以降、それはD、E．．．と流通してしまったものになります。

クレジットカードを不正利用されたAさんはカード会社にその旨を申告し、その申告を受けたカード会社はセキュリティソフトメーカーへ連絡。

そして、その連絡を受けたセキュリティメーカーは該当するライセンスを割り出し、判明したものから順次、ライセンスの強制失効を行ったという流れです。

このような問題が絶対に起きないようにするにはメーカーのWebサイトで正規販売代理店を確認することですが、そこに掲載されていないからと言って違法行為が行われているとは限らず、法人パートナーが販売しているものもあります。

（法人パートナーは基本的には法人向け製品を販売しますが、中小・零細企業、小規模事業者には個人向け製品を販売することもあります。また、今回問題があったセキュリティソフトは個人向け製品です。）

小規模事業者ともなると特に、インターネット通販サイトで購入することも多いとは思いますが、あまり聞いたことがないような販売者からの購入は避けた方が良いです。

そこに掲載されている購入者のコメントもあまり当てにならないことも多いですから、それも額面通り受け止めない方が良いです。

ご参考までに。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

冒頭に書いたようなことは百も承知かと思いますが、この『PHP』で開発されている『WordPress』サイトで使われている『PHP』の現状は少々驚くべきものがあります。

WordPressサイトの多くは非推奨PHP

まず、『PHP』が使われているWebサイトで見てみると、

『PHP 5』が未だに約66%も使われており、『PHP 7』は約33%に留まっています。

（『PHP 4』や『PHP 3』もごくわずかに存在している。）

そして、これを『WordPress』で構築されたサイトで見てみると、

・『PHP 7.3』：8.2%

・『PHP 7.3』：8.2%

・『PHP 7.2』：21%

・『PHP 7.1』：13.4%

・『PHP 7.0』：15.4%

・『PHP 5.6』：27%

・『PHP 5.5』：3.3%

・『PHP 5.4』：6.3%

・『PHP 5.3』：3.8%

・『PHP 5.2』：1.6%

（WordPress公式分析より）

となっています。

『PHP 7.3』は未だに1割にも満たず、『PHP 5系』を使っているユーザーは未だ4割以上も存在します。

しかし、現在の『WordPress』公式要件はと言うと、

・PHPバージョン7.3以上

・MySQL バージョン 5.6 以上、または MariaDB バージョン 10.1 以上

・HTTPS対応

です。

『PHP 7』は『PHP 5.6』と比較して圧倒的に高速になった『ハイパフォーマンスPHP』バージョンなため、パフォーマンスを考慮すべき現在のWebからすれば『PHP 7』にしない方がデメリットと言えるほどです。

また、既にサポートが終了している『PHP 5系』と『PHP 7.0』を使い続けることはセキュリティ的にもリスクがあります。

私が見ている限り、日本国内のよく知られたホスティング会社の多くは『PHP 7.3』に対応しているはずですから、早い段階で『PHP 7.3』ベースに切り替えられることをお勧めします。

それによると、リニューアルしたWebサイトの7割で『CV』の改善効果がなく、半数以上は逆効果だったとされています。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

冒頭に書いた調査結果、読んで衝撃的でしたか？

これ、それなりに納得できるものなんです。

Webサイトのリニューアルは逆効果

まず、『CV』に関して説明しますと、『CV』は『Conversion』の略で『目標達成』のことです。

例えば、『お問い合わせフォーム』から『お問い合わせ』をもらうことを目標としている場合、Webサイトへの訪問者から『お問い合わせフォーム』を通して『お問い合わせ』が成された数ということになります。

また、アクセスユーザー数に対してこのアクションが成された件数の比率が『CVR（Conversion Rate）』と言われる『率』になります。

さて、話しを元に戻しますが、冒頭に書いた調査結果は普通の話しです。

すべてにおいて全く何も効果がないということではなく、『Webサイトのリニューアル』が『表層的変更』であった場合には『無意味』なものになる可能性を意味しています。

逆に、『Webサイトのリニューアル』が『構造的変更』であった場合には相応の効果があるとされています。

つまり、表面的な見た目を変えるのではなく、中身を見直さないとダメということです。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

冒頭に書いた『不正レビュー』の話し、これは『Amazon』に限った話しではありません。

他のショッピングモールや『中小・零細企業』、『小規模事業者』などの『オリジナルサイト』であっても存在しています。

Amazon以外にも不正レビュー有り

さて、『Amazon』の『不正レビュー』に関してはさておき、『ローカルビジネス』においても同じようなことが存在していると思ったことはありませんか？

例えば、昨今においては起業したばかりであっても『Webサイト（ホームページ）』を活用することは少なくありません。

そんな起業直後の『Webサイト（ホームページ）』において『お客様の声』が多数並んでいることは当たり前のようにあります。

これ、違和感を感じませんか？

長年『Webサイト（ホームページ）』を活用せずに『アナログ』だけで活動してきたのであれば理解はできますが、起業直後となると話しは別で、すべてではないにしろ一定量は『さくら』です。

何が言いたいのか？

消費者側に対しては『お客様の声（レビュー）』を完全に鵜呑みにしてはいけないということ、事業者側には『正直であれ』ということです。

『さくら』を並べているところは一見良いように見えますが、じっくり見ていくと何かしら疑問を感じる部分が閲覧者に見えてしまう可能性があります。

つまり、それが広がれば『信用されないサイト』ということになり兼ねません。

結局のところは『博打』をしているようなものです。

さて、どちらを選択されますか？

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

よくある話しですが、『お金をかけたのに効果がない。。。』とWebサイト（ホームページ）のオーナーが嘆きます。

そこで質問です。

『そのWebサイト（ホームページ）はちゃんと育てていますか？』

Webサイトからもっと情報配信を

Webサイト（ホームページ）のオーナーからの嘆きの声はよくあることですが、多くの場合においてはやるべきことをやっていません。

それは、構築した当初のまま放置し、新しい情報を何も提供していないことです。

そのような状況にあるオーナーに『何故更新しないのですか？』と聞くと、必ず同じ答えが返ってきます。

『それをやる人材もいなければ、やる時間もない。』です。

そのような答えに対して『業者に保守をお願いすれば良いのでは？』と突っ込むと、これも同じ答えが返ってきます。

『毎月のようにお金がかかるのは嫌だ。』です。

これには2通りの意味があります。

1つは『保守料まで支払う余裕はない。』というケースと、もう1つは『保守料を払うことに納得がいかない。』です。

前者のケースでWebサイト（ホームページ）構築をした場合は自社や自店にて情報配信をしていくしかありません。

その場合、前述のような答えが返ってきてしまうと『何のために構築したのですか？』となってしまい、それに対しては『単なる言い訳』としか聞こえません。

定期的に新しい情報を配信されている企業やお店であっても人材に余裕があったり時間に余裕があったりするわけではないのです。

何とか時間を作って『新しい情報』を提供されています。

後者のケースもよくある話しです。

単純に『IT系の人件費』をタダ同然のように思っている方の答えです。

しかし、そうは言っても保守する側もメンテナンスを行うのに人が時間を使って行うわけですから、そのように思われている方の会社やお店と同じように『人件費』がかかっているわけです。

話しがそれてしまいましたが、Webサイト（ホームページ）は構築したら終わりではありません。

その後も継続的に育てていくものです。

構築したWebサイト（ホームページ）にブログ機能があるのであれば定期的にブログ記事を書いてください。

もちろん自社や自店に関連した内容をです。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

既に『TLS1.0』と『TLS1.1』は多くのサービスで終了がアナウンスされており、現在の中心は『TLS1.2』となります。

しかし、それよりももっとセキュリティ的に安全で高速なのは『TLS1.3』での通信です。

TLS1.3対応で安全で高速な通信が間もなく

『Google Chrome』や『Mozilla Firefox』など、主要なブラウザでは既に『TLS1.3』に対応済みですが、ホストとなるサーバ側の方は一部のサーバが『TLS1.3』に対応し始めた程度の状況で、多くは未だ『TLS1.2』の状態です。

この『TLS1.3』は『TLS1.2』に比べてセキュリティ面、速度面の両面にて改善されている『暗号化通信プロトコル』であるため、早い段階で様々なところで対応がされることが望ましいわけですが、ホスト以外にも少々引っかかってしまう可能性があるものがあります。

それはセキュリティソフトです。

多くのセキュリティソフトでは各Webサイト（ページ）にブラウザからアクセスする際の通信を保護する機能が付いていますが、その部分が未だ『TLS1.2』までしか対応していないものがあります。

そのような場合、よく閲覧する『信頼できる』Webサイト（ページ）が『TLS1.3』に対応しているならばそれをチェック対象から外して通信を行うしかありません。

おそらく、各セキュリティソフトの次のバージョンにおいては間違いなく『TLS1.3』に対応したものがリリースされるはずですから、もう間もなくで環境が整ってくるのではないかと思われます。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

私もここ最近で気づかされたことがあります。

Webサーバーの『Apache』が『Apache 2.4』からアクセス制御の記述方法が大きく変わっていることを。

Apache2.4におけるアクセス制御

『.htaccess』などに記述するアクセス制御ですが、『Apache 2.2』と『Apache 2.4』では記述方法が異なります。

例えば、すべての要求を拒否する場合に『Apache 2.2』では

Order deny,allow
Deny from all

と記述していましたが、『Apache 2.4』では

Require all denied

と記述します。

ただし、多くのホスティング会社では従来の『Apache 2.2』の記述方法でアクセス制御が可能となるよう、『Apache』に『モジュール』を追加して対応していると思われます。

それならば問題はないのでは？

となるところですが、

サーバーの高負荷などが原因でその『モジュール』が正常に動作しないことが発生すれば別です。

『500 Internal Server Error』となりWebサイトが表示されなくなります。

つまり、そういったエラーの要因を一つでも減らしておくには『Apache 2.4』の記述に変更すべきと言えるわけです。

明日に続く。。。