Blog

ブログ

ジョーレン社員旅行2023

少しばかり時が過ぎてしまいましたが、2023年11月、沖縄へ社員旅行に行って参りました。

思い返せば
2018熱海と初島へ
2019
千葉県台風被害の復興支援で房総へ(その後コロナ渦)
行っておりますが、今回の社員旅行はなんと飛行機で『沖縄』へ。
会社の成長を感じますね!

もちろん参加の強制は一切なく、行きたい人たちだけですが

今回は17人のメンバーが集まりました!
お仕事に影響の無いよう土日の2日間です。

普段からリモートワークが多めですから、なかなか会えないメンバーもいるので
たっぷり交流するチャンス♩slackで行きたい場所を募り、皆で計画を立てました。

初日の朝、なかなかの寒さの中 羽田空港に集合!
沖縄は暖かい予報ですが、、??

沖縄の有名ファーストフード店 A&Wの本店で昼食です。
不思議な注文機材やアメリカンな店構えにテンションがあがります。
たくさん頼んで良いとのことでしたがハンバーガーひとつでもかなりのボリュームでした♪

みんなが頼んだ名物のルートビア。
サロンパスの味がする飲み物で非常に新鮮&衝撃的なお味でした。

観光組とダイビング組で別れて行動するはずでしたが、この日は風が強く、予定していたダイビングは中止になってしまいまったので、

急遽調べて「おきなワールド」へ。

みんなで鍾乳洞を見たり
ヘビを担いだり

ハブとマングースショーを見て満喫させていただきました。

社長が最前列で、一番楽しんでいたのが印象的でした(笑)

それを撮影する社員たち・・・(^^)

 

そして夜。

国際通りど真ん中のホテルに宿泊です。

カチャーシーなどのステージを見ることのできる居酒屋さんで

豪華なコースをいただきました。

ありがとうございます!!

恒例の 社長音頭のもとみんなで一本締めをして、楽しい1日を終えました・・・

と思いましたが、宴会の後も国際通りはまだまだ営業中で賑わっていたので、お土産を買ったり2次会に行ったり各々楽しみました!

(噂によると瀬長島までサウナに行った面々もいたとか?)

 

– – – – – – – – – – – – – –

 

2日目はグループに分かれての行動でした。

私のいたグループでは 

ちゅら海水族館 〜 古宇利島 〜 なかむらそば(沖縄そば有名店) 〜 ウミカジテラス 

を回りました。

ジンベエザメの大きさには圧倒されて、普段の案件の細々した悩みも吹っ飛びそうです。

そして初めは空を覆っていた雲も、徐々に晴れて青い沖縄の海を拝むことができました。

もう帰ったらお仕事頑張るしかありません。

 

副社長がドローンで空から撮影もしてくれて

素敵な思い出が残せました(^^)

 

最後のウミカジテラスは空港のそばなのでギリギリまで遊べるだろうと言うことで、

みんなで本当のギリギリまでグルメを堪能。

そして素敵な景色に非日常を感じて大いにストレス発散させていただきました。

来年は好調であればまた飛行機で北の方へ・・?と言うお話もあったので、

是非とも実現できるよう頑張っていきたいと思います。

【MySQL】ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction が出て困った話

先日MySQLで下記エラーに出会いました。

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

対応に手間取ったので、振り返ってみようと思います。

このエラーは何を表している?

データへ書き込むために待機していたトランザクションが、待機時間上限を超えた時に出るエラーのようです。
待機させられている理由は、前のトランザクションによって更新対象がロックされている為とのこと。

ちなみに待機時間の上限は innodb_lock_wait_timeout に定められており、デフォルトは50秒です。

どうやら行ロックを取得したトランザクションがcommitしないまま残ってしまったようで、
該当の行を更新しようとすると、50秒後に上記エラーが出るようになってしまいました。

wait_timeout(非対話型の接続)またはinteractive_timeout(対話型の接続)の時間を経過すると自動で切断されるようですが、
デフォルトは8時間と長いので急ぎ解消するためには、つかみっぱなしのトランザクションをkillする必要があります。

kill対象を判断するのに時間がかかってしまったので、その時調べたことをまとめておこうと思います。

killするスレッドを判断するために情報を集める

検証用にusersテーブルを作成します。MySqlのバージョンは 8.2.0でやっています。

CREATE TABLE users (
 id INT NOT NULL AUTO_INCREMENT ,
 name VARCHAR(255) NOT NULL ,
 email VARCHAR(255) NOT NULL ,
 PRIMARY KEY (id)
 );

INSERT INTO users(name, email)
VALUES ('TARO', 'taro@example.com'),
('JIRO', 'jiro@example.com'),
('SABURO', 'saburo@example.com');

mysql> select * from users;
 +----+--------+--------------------+
 | id | name | email |
 +----+--------+--------------------+
 | 1 | TARO | taro@example.com |
 | 2 | JIRO | jiro@example.com |
 | 3 | SABURO | saburo@example.com |
 +----+--------+--------------------+
 3 rows in set (0.00 sec)

この時点では、スレッドは1つです。

mysql>  show processlist;
 +----+------+-----------+------------+---------+------+-------+------------------+
 | Id | User | Host      | db         | Command | Time | State | Info             |
 +----+------+-----------+------------+---------+------+-------+------------------+
 | 13 | root | localhost | example_db | Query   |    0 | init  | show processlist |
 +----+------+-----------+------------+---------+------+-------+------------------+
 1 row in set, 1 warning (0.00 sec)

テーブルを作った上記のセッションを1つ目として、2つ目のセッションを新しく開始し、レコードの削除をしてcommitしないままクライアントを強制的に閉じます。
次に3つ目のセッションを新たに開始して1レコードのアップデートを行います。

-- 2つ目のセッションを新しく開始し、オートコミットをOFF
mysql> set autocommit = 0;
Query OK, 0 rows affected (0.00 sec)

-- レコードの削除
mysql> DELETE FROM users;
Query OK, 3 rows affected (0.00 sec)

-- commitしないまま切断

 

-- 3つ目のセッションを新しく開始し、オートコミットをOFF
mysql> set autocommit = 0;
Query OK, 0 rows affected (0.00 sec)

-- アップデートすると、50秒後に今回のエラーが発生する
 mysql> UPDATE users set name = 'ichiro' WHERE id = 1;
 ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
 mysql> rollback;

再現できました。

ロックしているトランザクションを終了させないと、usersテーブルを更新出来ない状況になりました。
このまま8時間(デフォルト)経過すれば終了するのですが、8時間は長いので、どうにかkillしたいです。

show processlist

この時点でスレッドは3つ表示されます。

mysql> show processlist;
+----+------+-----------+------------+---------+------+-------+------------------+
| Id | User | Host      | db         | Command | Time | State | Info             |
+----+------+-----------+------------+---------+------+-------+------------------+
| 18 | root | localhost | example_db | Query   |    0 | init  | show processlist |
| 19 | root | localhost | example_db | Sleep   |  126 |       | NULL             |
| 20 | root | localhost | example_db | Sleep   |   53 |       | NULL             |
+----+------+-----------+------------+---------+------+-------+------------------+
3 rows in set, 1 warning (0.00 sec)

ちなみに、重いSQL等で処理が終わっていない場合は「Info」の部分にSQLステートメントが表示されますが、
今回はcommitまたはrallbackがされていないだけなので、Infoはnullになります。


SHOW ENGINE INNODB STATUS

killするならもう少し情報が欲しい、ということで、もう少し集めます。SHOW ENGINE INNODB STATUS で出てくる情報は多岐にわたりますが、トランザクションの情報も含まれています。

mysql> SHOW ENGINE INNODB STATUS;
-- (省略) --

------------
TRANSACTIONS
------------
Trx id counter 1871
Purge done for trx's n:o < 1870 undo n:o < 0 state: running but idle
History list length 0
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 421357384966952, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 421357384965336, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 421357384964528, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 421357384963720, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 1865, ACTIVE 771 sec
2 lock struct(s), heap size 1128, 4 row lock(s), undo log entries 3
MySQL thread id 19, OS thread handle 139881921705728, query id 218 localhost root

-- (省略) --

「TRANSACTIONS」の部分を確認します。

「undo log entries 3」の部分がコミットもロールバックもしていない行数です。

「MySQL thread id 19」がSHOW PROCESSLISTのIdと一致します。Id:19が長時間(771秒)経過しているという情報が取れました。加えて「3行変更しているのにコミットされていない」という情報を取得出来ました。

select * from information_schema.INNODB_TRX

information_schema.INNODB_TRX から現在実行されているすべてのトランザクションに関する情報を取得出来ます。

mysql> select * from information_schema.INNODB_TRX order by trx_id\G
*************************** 1. row ***************************
                    trx_id: 1865
                 trx_state: RUNNING
               trx_started: 2023-11-29 10:17:20
     trx_requested_lock_id: NULL
          trx_wait_started: NULL
                trx_weight: 5
       trx_mysql_thread_id: 19
                 trx_query: NULL
       trx_operation_state: NULL
         trx_tables_in_use: 0
         trx_tables_locked: 1
          trx_lock_structs: 2
     trx_lock_memory_bytes: 1128
           trx_rows_locked: 4
         trx_rows_modified: 3
   trx_concurrency_tickets: 0
       trx_isolation_level: REPEATABLE READ
         trx_unique_checks: 1
    trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
 trx_adaptive_hash_latched: 0
 trx_adaptive_hash_timeout: 0
          trx_is_read_only: 0
trx_autocommit_non_locking: 0
       trx_schedule_weight: NULL
*************************** 2. row ***************************
                    trx_id: 421357384966952
                 trx_state: RUNNING
               trx_started: 2023-11-29 10:30:55
     trx_requested_lock_id: NULL
          trx_wait_started: NULL
                trx_weight: 0
       trx_mysql_thread_id: 20
                 trx_query: NULL
       trx_operation_state: NULL
         trx_tables_in_use: 0
         trx_tables_locked: 0
          trx_lock_structs: 0
     trx_lock_memory_bytes: 1128
           trx_rows_locked: 0
         trx_rows_modified: 0
   trx_concurrency_tickets: 0
       trx_isolation_level: REPEATABLE READ
         trx_unique_checks: 1
    trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
 trx_adaptive_hash_latched: 0
 trx_adaptive_hash_timeout: 0
          trx_is_read_only: 0
trx_autocommit_non_locking: 0
       trx_schedule_weight: NULL
2 rows in set (0.00 sec)

2行出力されましたが、trx_started (トランザクション開始時間)が早い方が長い間完了していないことになります。

より長時間経過している1行目を見ると、trx_rows_modified(このトランザクションで変更および挿入された行の数)が3で、ここでも3行更新しているが完了していないことが読み取れます。また、trx_mysql_thread_id(MySQL スレッド ID)はSHOW PROCESSLISTのIdと一致するので、これはshow processlistのId:19を指しています。

過去発行したクエリも確認する

先ほどから目を付けているID:19が発行したクエリを見てみます。

まずはMySQL スレッド IDとperformance_schema.threadsからTHREAD_IDを取得します。

mysql> SELECT thread_id FROM performance_schema.threads WHERE processlist_id = 19;
+-----------+
| thread_id |
+-----------+
|        56 |
+-----------+
1 row in set (0.00 sec)

そのTHREAD_IDとperformance_schema.events_statements_historyから、過去のクエリが少し分かります。killして大丈夫かの判断材料になりそうです。

ただし、performance_schema.events_statements_history は最新10件(デフォルト)しか保持していないので、それより前の情報はここからは取得出来ません。

mysql> SELECT THREAD_ID,SQL_TEXT FROM performance_schema.events_statements_history WHERE thread_id = 56 ORDER BY TIMER_START;
+-----------+----------------------------------+
| THREAD_ID | SQL_TEXT                         |
+-----------+----------------------------------+
|        56 | select @@version_comment limit 1 |
|        56 | select $$                        |
|        56 | SELECT DATABASE()                |
|        56 | NULL                             |
|        56 | show databases                   |
|        56 | show tables                      |
|        56 | NULL                             |
|        56 | select * from users              |
|        56 | set autocommit = 0               |
|        56 | DELETE FROM users                |
+-----------+----------------------------------+
10 rows in set (0.00 sec)

情報を集めたので、最後にID:19をkillしてアップデートできるようになることを確認します。

mysql> kill 19;
Query OK, 0 rows affected (0.00 sec)

mysql> show processlist;
+----+------+-----------+------------+---------+------+-------+------------------+
| Id | User | Host      | db         | Command | Time | State | Info             |
+----+------+-----------+------------+---------+------+-------+------------------+
| 18 | root | localhost | example_db | Query   |    0 | init  | show processlist |
| 20 | root | localhost | example_db | Sleep   | 1911 |       | NULL             |
+----+------+-----------+------------+---------+------+-------+------------------+
2 rows in set, 1 warning (0.00 sec)

mysql> UPDATE users set name = 'ichiro' WHERE id = 1;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> commit;
Query OK, 0 rows affected (0.01 sec)

-- id1のnameがTAROからichiroに更新されている
mysql> select * from users;
+----+--------+--------------------+
| id | name   | email              |
+----+--------+--------------------+
|  1 | ichiro | taro@example.com   |
|  2 | JIRO   | jiro@example.com   |
|  3 | SABURO | saburo@example.com |
+----+--------+--------------------+
3 rows in set (0.00 sec)

usersテーブルをアップデート出来ました。

 

 

 

今回は【MySQL】ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transactionが発生しkillしないと解決しない場合の調査方法についてまとめてみました。まだまだ知らないことが多いので、今後もMySQLを学んでいきたいと思います。

Continue reading “【MySQL】ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction が出て困った話”

【ECCUBE3系】既存プロジェクトにPHPStanを導入して、コード品質向上しよう!

プロジェクトが大規模になるにつれて、コードの複雑性や保守性の向上が課題となります。このような課題に対処する手段として、いろいろなツールがあると思いますが、今回はPHPStanをプロジェクトに組み込むことで、コードの品質向上させたいと思います。

PHPStanの導入

PHPStanをプロジェクトに導入するために、まずComposerを使用して必要なパッケージをインストールします。

composer require --dev phpstan/phpstan

場合によっては下記のエラーが出るかもしれません。

Generating optimized autoload files> Illuminate\Foundation\ComposerScripts::postAutoloadDump> @php artisan package:discover –ansi
In PackageManifest.php line 122: Undefined index: name

このエラーはcomposer v2を使用している場合に発生するようです。
なので、一旦composerのバージョンを下げることで解決できます。

composer self-update --1

インストールが完了したら、プロジェクトのルートディレクトリに .phpstan.neon という設定ファイルを作成します。このファイルには、PHPStanの静的解析のレベル設定や解析対象となるディレクトリを指定します。

parameters:
    level: 8
    paths: src/Eccube/
    excludePaths: src/Eccube/Command/GeneratorCommand/*

これで準備が整ったので、一度PHPStanを実行してみましょう!

vendor/bin/phpstan analyze

すると、大量にエラーが…!

PHPDoc tag @param has invalid value \\(\\$value\\)\\: Unexpected token \”\\$value\”, expected type at offset 102$PHPDoc tag @param has invalid value \\(\\$value\\)\\: Unexpected token \”\\$value\”, expected type at offset 18PHPDoc tag @param has invalid value \\(\\$value\\)\\: Unexpected token \”\\$value\”, expected type at offset 57Parameter \\#1 \\$str of function trim expects string, string\\|null given\\.

8000件くらいエラーが出てしまいました。。既存のプロジェクトに途中から導入しているので仕方ないですね。
こういう時のために、PHPStanでbaselineというものを作成できます。baselineに含めたエラーは一旦無視できます。

vendor/bin/phpstan analyze --generate-baseline

`phpstan-baseline.neon`が自動生成されますので、こちら`phpstan.neon`に記載し読み込んでもらいましょう。

phpstan.neon
includes:
    - phpstan-baseline.neon

parameters:
    level: 8
    paths: src/Eccube/
    excludePaths: src/Eccube/Command/GeneratorCommand/*

これで大量のエラーは一旦無視できました!

型注釈の追加

エンティティやそれに関連するメソッドに型注釈を追加します。これにより、PHPStanはコードの型整合性を確認しやすくなります。

// src/Entity/YourEntity.php

class YourEntity
{
    /**
     * @var string
     */
    private $name;
    
    // ...

    /**
    * @param string
    * @return string
    ** /
    public function test(string $message)
    {
        return message;
    }
}

 

いかがでしたでしょうか?

PHPStanはコードの静的解析を行い、型の整合性や潜在的な問題を見つけてくれます。これにより、コードの品質向上や開発プロセスの効率化が期待できます。


PHPStanを導入することで、より安全で信頼性の高いコードを構築することができます。是非一度試してみて、プロジェクトのメンテナンス性や開発速度の向上を実感してください。

【eccube2系】マイグレーションツールのPhinx導入したい!2

前回、phinxをインストールしたところまでを説明しましたので、
今回は実際に使用してDBを更新してみたいと思います。

マイグレーションファイルを作成したり、実行する場合は下記のディレクトリで行います。

cd {dataのパス}/vendor/bin

まずはマイグレーションファイルを作成してみましょう!
ファイル名は見た感じわかりやすい方がいいですね。

今回はメンバーに誕生日カラムを追加してみましょう!

php phinx create AddDtbMember

下記のようなものが表示されればOKです。

Phinx by CakePHP – https://phinx.org. version 0.10.8

using config file ./phinx.yml
using config parser yaml
using migration paths
– {dataパス}/data/db/migrations
using seed paths
– {dataパス}/data/db/seeds
using migration base class Phinx\Migration\AbstractMigration
using default template
created {dataパス}/db/migrations/20231030045812_add_dtb_member.php

{dataパス}/db/migrationsディレクトリにファイルができているはずです。

change()メソッドが生成されているので、下記のソースを追加しましょう。

$this->execute(“alter table dtb_member add birth datetime null comment ‘誕生日’;”);

changeメソッド以外にも色々メソッドはあるので、こちらを参考に使い分けてもらってもいいと思います!
https://book.cakephp.org/3/ja/phinx/migrations.html

マイグレーションの実行をしてみましょう!

php phinx migrate -e development

マイグレーションが実行されていれば下記の表示がされます!

Phinx by CakePHP – https://phinx.org. version 0.10.8

using config file ./phinx.yml
using config parser yaml
using migration paths
– {dataパス}/db/migrations
using seed paths
– {dataパス}/db/seeds
using environment development
using adapter mysql
using database eccube2_db

== 20231030045812 AddDtbMember: migrating
== 20231030045812 AddDtbMember: migrated 0.2129s

All Done. Took 0.2522s

ちなみに、、、
下記のコマンドで実行前のSQLの確認もできますが、初回実行前に試したらphinxlogができておらずエラーになってしまいました。。。

php phinx migrate -e development –dry-run

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table ‘{DB名}.phinxlog’ doesn’t exist in {dataのパス}/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/PdoAdapter.php:194

phinxlogはマイグレーションファイルを管理しているテーブルになります。

CREATE TABLE `phinxlog` (
`version` bigint(20) NOT NULL,
`migration_name` varchar(100) DEFAULT NULL,
`start_time` timestamp NULL DEFAULT NULL,
`end_time` timestamp NULL DEFAULT NULL,
`breakpoint` tinyint(1) NOT NULL DEFAULT ‘0’,
PRIMARY KEY (`version`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

ちなみに今回実行したマイグレーションの情報はこんな感じで保存されていました。

version,migration_name,start_time,end_time,breakpoint
20231030045812,AddDtbMember,2023-10-30 14:25:13,2023-10-30 14:25:14,0

実際に私が担当した案件でphinxを導入したら格段にマイグレーションの管理がしやすくなりました!!

ぜひ2系を触る場合は初期構築時に導入することをお勧めします!!

 

【eccube2系】マイグレーションツールのPhinx導入したい!

eccube2系を複数人で開発しているときに思うこと。

「3系とか4系みたいにマイグレーション機能があればいいのに!!」

無くてもできるとは思いますが、他メンバーが作ったSQLを自分でいちいち叩くのは面倒。
しかもどのSQL叩いたかどこかにメモしておかないと忘れちゃう…

なんてことありますよね。

それを解消するために今回は2系にマイグレーションツールの「Phinx」を導入したいと思います。

まず、ローカル環境でdocker+eccube2を用意してください。

ここからphinxの導入をしたいと思います。

(1)composerからphinxをインストールする

composer require robmorgan/phinx

しかしエラーが発生。。

Cannot use robmorgan/phinx’s latest version 0.15.2 as it requires php-64bit >=8.1 which is not satisfied by your platform.
Using version ^0.14.0 for robmorgan/phinx
./composer.json has been updated
Running composer update robmorgan/phinx
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

Problem 1
– Root composer.json requires robmorgan/phinx ^0.14.0 -> satisfiable by robmorgan/phinx[0.14.0].
– robmorgan/phinx 0.14.0 requires symfony/console ^3.4|^4.0|^5.0|^6.0 -> found symfony/console[v3.4.0, …, v3.4.47, v4.0.0, …, v4.4.49, v5.0.0, …, v5.4.28, v6.0.0, …, v6.3.4] but the package is fixed to v2.8.52 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.

Use the option –with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
You can also try re-running composer require with an explicit version constraint, e.g. “composer require robmorgan/phinx:*” to figure out if any version is installable, or “composer require robmorgan/phinx:^2.1” if you know which you need.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.
# php composer require robmorgan/phinx
Could not open input file: composer

ふむふむ。。
phpとバージョンが合わないから使えないよー。
明示的にphinxのバージョンを指定してね的なことを言われました。
なので下記で再実行

composer require robmorgan/phinx:*

ちゃんとインストールされました!

(2)Phinxの設定ファイルを生成するためvendor/bin配下に移動

cd {dataのパス}/vendor/bin
php phinx init

そうすると /var/www/data/vendor/bin/phinx.php(Phinxの設定ファイル)が生成されます。

(3)Phinxの設定ファイルを編集する。

①migrationsを変更→{dataパス}/db/migrations
②seedsを変更→{dataパス}/db/seeds
③developmentもローカル環境に合わせて修正
※data/config/config.phpを参考

paths:
migrations: ①
seeds: ②

environments:
default_migration_table: phinxlog
default_database: development
production:
adapter: mysql
host: localhost
name: production_db
user: root
pass: ”
port: 3306
charset: utf8

development:③
adapter: mysql
host: localhost
name: development_db
user: root
pass: ”
port: 3306
charset: utf8

testing:
adapter: mysql
host: localhost
name: testing_db
user: root
pass: ”
port: 3306
charset: utf8

version_order: creation

(4)ディレクトリを作成する

mkdir {dataパス}/db
mkdir {dataパス}/db/migrations
mkdir {dataパス}/db/seeds

これで構築完了です。

一旦ここで終わりです。

次はマイグレーションファイルを実際に作って実行してみましょう。

【ECCUBE4系】よくある質問 〜支払方法設定〜

今日はECCUBE4系の管理画面の操作で、お客様から1番頂く質問について書いていこうと思います。

1番多い質問。。。それは、支払方法設定について!!!

「管理画面の支払方法設定画面で、支払方法を追加したのですが、フロント側で商品の購入手続き画面に出てこないのですが、不具合でしょうか。。。?」
そうですよね、そう見えますよね。。。

ですが、それは不具合ではないのです!
ECCUBE4系の立派な(?)仕様なのです!

まず、下記スクショがデフォルトの状態の支払方法設定画面ですね。

ここに、新しい支払方法を追加します。

ちゃんと表示で登録できていることが確認できました。ではフロント側の購入手続き画面の支払方法を確認してみましょう!

あれ。。。出てこない。。。

登録したはずの支払方法「後払い」が出てこない。。。

これは。。。不具合!?

いえいえ、不具合ではございません!

配送設定画面というのが、管理画面に存在するのはご存知でしょうか?

はい、「取り扱う支払方法」の項目に、新しく追加した「後払い」が選択できるようになっていますが、設定がされていないことにお気づきでしょうか?

ここで、購入手続き画面をもう1度見てみましょう。

「配送方法」の項目はサンプル業者が選択されていますね。

ですが、サンプル業者の設定では、支払方法に「後払い」が設定されていないのです。

そのため、購入手続き画面でお支払方法に追加した「後払い」が選択できないという事象が起こったのです。

サンプル宅配を選択してみると、「銀行振込」しか出力されていないですね。

これは、管理画面の配送方法設定のサンプル宅配が、「銀行振込」しか設定されていないためです。

このように、配送業者によって支払方法を設定できるため、支払方法設定画面で支払方法の追加を行っただけでは、購入手続き画面の「お支払方法」に出力されないというわけです。

支払方法設定画面は、支払方法の選択肢の設定が行える画面

配送方法設定画面は、配送方法ごとに詳細を設定できるので、支払方法の設定も行える画面

と、覚えておくと良いかもしれません。

なんでこうなるのかな〜?がわかっていないと、意外とハマってしまう支払方法設定の解説でした。

支払方法設定で困っている方のお役に少しでも立てれば幸いです。

消費者に求められる商品。そして選び方・買い方の移り変わりについて。

近年、個人ネットショップの活気さやメッセージ性が目につくことでしょう。
それぞれ独自の考えやメッセージ、世界観やブランド力が表現され、ショップのファンの存在を身近に感じます。
今回なぜこのようなショップが現代求められているのか。私自身はっきりとした結論は出ていないのですが、心に浮かんだことを参考サイトを交えながら考えをめぐらしていきたいと思います。

みなさんも一緒にこの問いについて向き合いながら、お付き合い頂けたらです。

ただ商品を売るだけではない

「なぜその商品を作り、売っているのか」

その理由について、ショップ内で語られているサイトが存在し目にします。

「安いからみんなが手にしているから何となく買う」から「ほんとうに自分が必要なものだけをじっくり考えて厳選して購入する」

そういったメッセージを私自身受け取りました。時代と消費者の購買意識の移り変わりに答えたショップです。ショップ内では、買い手と売り手がまるでコミュニケーションを取っているような空気感に触れることができることでしょう。

 

ファーメンステーション オンラインショップ

茶心  文化をインスパイアするお茶メディア

「茶心」サイトは、運営者を大々的に告知しない手法を取っており、
サイトフッターの部分をよく見てみると、「伊藤園」が運営しているサイトであることが分かります。
コンセプトとして、「伊藤園というブランドで商品を買うのではなく、消費者に本当によい商品を吟味して購入してもらいたい」という運営者の思いにより、このようなブランディングをしているのでしょう。
こういった事例は、他大手企業でも確認することができます。

ZOOM(トンボのブランド)

 

記事については、ついつい読みふけってしまうものもあり、私が実際に取った行動として、

「なぜこの地でこのショップを開くことにしたんだろう」という疑問を持って訪問したサイト
【石徹白洋品店】のコンセプトページ等を興味深く読んだことがあったのです。

そして生産者の日常を語った「いとしろの日々」では、より深く本サイトの成り立ちについて肌で感じることができました。

「石徹白洋品店」サイトは、【パンと日用品の店 わざわざ オンラインストア】で知りました。
https://waza2.com/

元祖、体験の記事発信をし成功した企業とも言えるのではないでしょうか。
代表の平田はる香さんのnoteでもその人気を伺えることも理由です。

その「わざわざ」代表平田はる香さん初の著書。【山の上のパン屋に人が集まるわけ

  • 公共交通機関のない長野の山の上で、年間3万人以上が来店
  • 商品を食事パン2種類だけに
  • 年商3億円

といったキーワードが目を引きます。
ネットショップ含め、しっかりと経営を成功されているのです。
背中を押してもらえたような元気が溢れますね✨✨
平田はる香さん出演のPodcastについても必聴です。わざわざがこの規模に拡大するまでのストーリーを聞くことができます。

Vol.151 職人と経営者の二面性〜地に足をつけたブランドの姿

Vol.152 あえて道化を埋め込むCIのちから〜ブランドの分人性

 

さて「わざわざ」も「石徹白洋品店」もその土地ながらの生活や空気感を感じることができるサイトです。
[そう「わざわざ」という名前は、「わざわざ(長野の山の上まで)来てくださってありがとうございます」という意味を込めて名付けられたそうです。]
記事を読み終えると思わずほっこりしてしまう理由が分かります。と同時に商品を大切に使おうという気持ちも消費者に培われることでしょう。

昨今、問われているファストファッションについて。
ある日たまたま付けたTVで、海外アジアの地で1着あたりの洋服の作成費について、コストを抑えようと日本人が値段交渉しているシーンが流れていました。

こういった背景には必ず、労働問題や環境汚染の問題に関与していることでしょう。今回取り上げたテーマがこの課題の解決の糸口、手助けになるのではないかと思うのと同時に、今求められていることにぴったり重なるかと思いました。

学びと体験を提供する

これらのショップの傾向として、ショップ主催のワークショップを実施していることが特徴として挙げられます。
ワークショップを通じて、そのショップや商品をリアルに体感し、顧客がより理解を深めることができる場。インターネット上では決して得ることができない情報や知識を手にすることができます。

ショップ側にとっては、顧客とコミュニケーションが取れる場にもなりますよね。
一方通行ではなく、顧客からの発信も受け止めることができ双方コミュニケーションが育める場が作られることでしょう。

 

「結わえる」寝かせ玄米炊き方教室
「FOOD&COMPANY Neighbors」薬膳ワークショップ

人気のワークショップはすぐに埋まるほどの盛況のよう。
ほんとうに欲しい商品を購入するためには、必要なステップとなりそうです。またワークショップの体験は、誰かに話したくなり発信を作る機会になりますよね。
(アメリカの調査会社調べによると、ショップ側の発信より顧客からの発信の方が、消費者にとって影響力が高いそうですよ)

「体験を通して商品を選定してほしい」ショップ側のコンセプトにも敵います。

トピックスとして、こういった類のネットショップは、「商品ランキング」を掲載していないことに気づきました。
https://waza2.com/
https://www.chagocoro.jp/shop
https://www.fermenstation.jp/

「商品ランキング」から商品を選ぶのではなく、自らの審美眼で選んでほしいメッセージなのではと私自身感じ取りました。
ネットショップでは定番となる「商品ランキング」。消費者にとって買うきっかけにはなりますが、「ほんとうに良いものだけを購入する」コンセプトからはずれてしまうのかもしれません。ランキングは分かりやすさはありますが、一歩踏み込んで商品を購入してもらいたいという思いを阻害させてしまうコンテンツになるかもしれません。
サイト運営者がしっかりコンセプトに基づいて、「どうしたら顧客に価値ある商品をもたらすことができるか」を思いめぐらせ、コンテンツ作りをしている現れを感じました。

ショップのファンを作る

どのサイトも共通して言えることがSNSの発信を積極的にやっていることです。

つまりは、顧客と1対1で直接メッセージができる環境があるということ。SNSがファン作りや伝播する役割を担っています。統計でも顧客の半数以上が「ショップが質問に回答してくれるとうれしい」「企業が会話に参加してくれるとうれしい」という結果が示しています。SNSは、顧客とのコミュニケーションを大切にしていることを企業メッセージとしても伝えられるプラットフォームでもあります。

SNSがない時代はこのコミュニケーションを取れる選択肢がなく、顧客がダイレクトに企業にメッセージを伝える環境もなかったため、商品の思いや背景を伝える機会も今よりぐっと少なくありました。SNSがなかったらこのようなユーザーとの関係性や、今回テーマとして取り上げたショップのありかたも成り立たなかったことが想像できます。

そのショップのファンになることで、モノを大切にし慈しみほんとうに必要なものを選択していく気持ちが芽生えていくことでしょう。

 

ここでは【中川政七商店】のSNSを紹介したいと思います。Facebook、Twitter、Instagramと頻繁に情報が発信されています。

   
https://www.nakagawa-masashichi.jp/shop/default.aspx

 

Twitterについては、リツイートが積極的に行われ、Instagramでは質問に対して答えるなど、
ユーザーとの相互コミュニケーションを取っていることが確認できました。

これらのショップで共通して言えることは、「商品に関することだけを発信していない」ということ。
例えば「中川政七商店」のSNSでは入社式の様子を発信していました。
ユーザーも一緒に祝い同じ心境になることで、そのショップの一員となったかのような運命共同体のような気持ちになることでしょう。この入社式の発信は、InstagramとTwitterで投稿されていましたが、表現を変え発信していたことが微笑ましく高い信頼を寄せました。

またInstagramのコメント内でユーザー同士が「この商品いいよね」といったコミュニケーションを取っている様子も確認できました。企業が存在しない場でこのような会話が生まれることは、SNSならではです。

「中川政七商店」さんがコメント内で絵文字を使ってあたたかみのあるコメントをしていたことも印象的でした。ユーザーを気にかけている様子が伝わり、信頼関係の築きやロイヤルティーも高まる効果を育成することでしょう。そしてその言葉遣いは、ショップのブランドやスタイルを確立させる要素の1つになります。

統計として、FacebookよりInstagramの方が画像の反応率(いいね、シェア等)が高いそうで、SNSの特徴を活かして、ファン作りの場として積極的に活用すべきことが伺えます。

 

顧客がショップの商品&サービスを把握してから、購入へと至るまで。この一連の過程は半分以上、インターネット上で行われます。つまりは顧客に直接、ショップの情報を伝える機会が多いにあることが言えます。
今回ご紹介したアプローチ方法は、TVや街頭ビジョンのような莫大な広告費をかけることなく実施できることですので、どのショップにもいつでも等しく実施できるチャンスがあります。そうすることで、このブログのように第3者が情報を発信する効果もありますので、やらない選択肢はありません✨顧客にとって価値ある商品を届けるために、サイト運営者はSNSも活用し情報発信を日課として続けて頂けたらです。

私はあるショップのInstagramをフォローしていますが、そのショップでは頻繁に情報発信が行われるため、情報を受け取ることが日常化しています。そしてそのショップの存在を身近に感じざるを得ません。

 

自分が必要としているモノを必要な分だけ、必要な時に。1つのモノを大切に愛用していく。生活に日常に自然になじみ、供に歩める商品と一緒に過ごす。

これらのショップがこの思いを叶えてくれる情報を届け、私達に問います。

 

さて本ブログ記事は、明確な答えを持たないままみなさんと一緒に考えていくことを目的に書き綴りましたので、そろそろこの辺りでクローズしたいと思います!お耳に入れていただきましてありがとうございました?

達成会・開催のご報告!!

社として2022年の営業利益を大幅に達成することができたため、Link松戸店を貸し切り、

3/24(金)に達成会を行いました✨✨

普段はリモートで顔を合わせないメンバーもいるため、ジョーレンメンバーが一堂に会することはとても貴重&心あたたまる場となりました。

私もこの機会にたくさんのメンバーと話すことができ、話足りないメンバーもいるくらいで胸がいっぱいとなった時間でした。

 

さて会場ではまず始めに、月末に「全社MTG」と題して通常はオンラインでやっている会社からの業務に関する発表について。今回は対面でのみ、Link松戸店の会場でプロジェクトを使い開催しました。

この日のアジェンダを特別公開!!

今回は達成会ということもあり議題が多くありましたが、いつもはこれよりミニマムな内容で行っていることが多いです。

他の議題例として、エンジニアからエンジニアに向けて課題が出される月もあり、メンバーもひやひや!?

翌月の全体MTGで課題について答え合わせをする流れになります。

 

また発表している最中、メンバーの反応がつぶさに感じられリモートにはない活気さがありました。

ひさびさ多くの社員を前に話す「副社長(盛田)&社長(中村)」は、「緊張する」発言が何度かあり、緊張を隠せなかったようです。声がいつもよりワントーン高かったのはその影響でしょうか?

 

アジェンダ最後は、待ちに待った「乾杯」です!

Link松戸店のバーカウンターに、弊社メンバーによる長蛇の列ができ、各々が好きなドリンクをオーダーし、自席に。

そしてドリンクを手にしたメンバーを前に社長の長い話も加わり!?ビールを頼んだメンバーのグラスの泡は、みるみるとなくなっていきました。「早く飲みたい!」という声が聞こえそう 笑。

その後、みんなで乾杯したドリンクはやっぱり最高で格別!お互いのグラスをコツンと響かせ、お互いの労をねぎらいました。

 

食事と共に歓談タイムを挟んだ後は、お待ちかねの全社員対抗のダーツ大会!

「第1回Joolen杯争奪ダーツ対抗戦!」と題して、全10チームに分かれて、対戦しました。

優勝チームに授与される賞品は、社長と高級焼き肉会!!!

 

ダーツを初めてやるメンバーや、腕利きのメンバーも

一度練習タイムを設けてから、トーナメント戦によりダーツ大会は幕を開けました。

ゲーム方式は、得点を加算していくカウントアップ。 1ラウンド各自3本ずつダーツを投げていき競い合いました。チーム内外でお互いを応援し合い励まし合い、一番白熱した時間です。

 

さて決勝に進んだ2チームは、

【Wさん&Sさん&Uさん:チーム】VS 【社長(中村)&副社長(盛田):チーム】

あれ?もし「社長(中村)&副社長(盛田)」が優勝したら、賞品はどうなるんだ!?笑

そんな疑問も持ちつつ、ゲームのスタートを切ったら、みんな優勝に向けて真剣勝負で闘志に火がつきます?

ゲーム中、副社長(盛田)のダーツがボードに刺さらず床に落ちるアクシデントも!?

社員を気遣っての忖度との声もあがっていました 笑。

 

接戦の末、優勝を手にしたのは【Wさん&Sさん&Uさんチーム】???

強かったーーー。

私たちのチームと対戦した時は、あまりにも強敵でWさんに眼鏡を取ってもらって戦ったくらいですから(笑

優勝記念にボードの前で写真撮影をさせてもらいました。みんないい笑顔!

「Wさん&Sさん&Uさんチーム」おめでとうございます!!!!!

 

そのあとはフリータイムを迎え、ビリヤードや卓球を楽しむメンバーや引き続き話に花を咲かせるメンバーも。

フリータイムは途中退場もOKになっていましたが、ほぼ全員退出することなく達成会の場を楽しんでいました。

(その後、二次会に行くメンバーもいたくらいですから★)

 

会のクロージングとして、最後は社長音頭のもとみんなで一本締めをし、お互いを称え合い達成会を締めました。

2023年の目標額も継続して達成し、またみんなで集まることができますように。

 

「CUSTOMIZE EXPERT&CREATIVE EXPERT」ダブル受賞!!|BRAVO MUSIC オンラインストア

去る2022年5月30日に、BRAVO MUSIC オンラインストアをEC-CUBEで構築しリリースいたしました。

本サイトはEC-CUBE社から、「CUSTOMIZE EXPERT」&「CREATIVE EXPERT」を授与されております。

ダブルで受賞した実績は、弊社初です!!!(パチパチパチ???)

エンジニアチーム&デザインチームの汗と涙の結晶となった案件です?

https://bravomusic.jp/

 

 

さて本リニューアルでは、以下EC-CUBE2系の2サイトを1サイトに統合し、リニューアルすることになりました。

 

このような多くの情報を整理し、まとめ上げたのは私自身初めての試みでした。

「こんなに多い情報どうする〜〜」と嘆きの声が私一瞬ありましたが、とてもやりがいがありハートが熱くなるお仕事となりました★

情報整理に精を出す

全て洗い出して情報整理!

本プロジェクトの趣旨。2サイト(「fitness musicサイト」と「yoga musicサイト」)を1サイトに統合するミッション!

2サイトある上、両サイトとも、とても情報が多いサイトであり、また整理されていないコンテンツもある状態でした。そのためまずやったこと!2サイト分のページを全て洗い出す作業を実施!!

Excelに全ページ、リストアップし、その後ブラボーグループ様にリプレイス先では必要なページかどうかをご判断頂きました。その上でWFを作成し、優先順位が高いものは、グルーピングやカテゴリとして位置づけし情報整理に努めました。

カテゴリ名や配置場所について熟考を重ね、ブラボーグループ様と対話しながら現在の内容で確定。

そして優先順位が低いものは、「フィットネス関連コンテンツ」&「ヨガ関連コンテンツ」としてスライドバナーエリアを設け集約することにしました。

ジャンル分けしきれないものや、コンテンツとして優先度が低いものはここにまとめ、情報整理することに努めたのです。(2023.02現在では、この部分はクローズさせています)

「お知らせ」については下の方に配置することにしたため、重要なトピックはファーストビューとなるメインビジュアル下で訴求エリアを確保。バナー点数を際限なく設置できるよう、スライドバナーを展開する見せ方でご提案いたしました。

これなら「お知らせ」エリアが下に配置されていても、しっかりと重要なトピックスをユーザーにお知らせすることができます!

 

さて1つトピックスをお話します。

ジャケ写下にある「視聴する」ボタン。きっと思うことがあるでしょう!

ボトムをそろえたい!!!!!(みんなの声が聞こえる〜〜)

一度ボトムをそろえたことがあるのですが、不自然に間のあいた空白が出きてしまい、そろえることをやめました。全て同じ文字数なら、きれいにレイアウトがまとまるでしょうが、動的部分になるためその選択肢は取れません。

一方で商品一覧ページでは、「視聴する」ボタンをそろえています。

本ページは整然としたページ内容となるため不自然さがなく、そろえる選択を取りました。ページの見せ方によって臨機応変にですね!

https://bravomusic.jp/products/list?product_type_id=1

メニューの見せ方はシンプルに!

今回譲れない点がありました。それは、ヘッダー周りのメニュー導線をシンプルに使い勝手よい導線とすること。ログイン時も気を配りこの点妥協せず、担当デザイナーと協議しました。

加えて「著作権について」アテンションをかけたいこと、ブラボーグループ様から要望を受けたため、ヘッダー周りが煩雑にならないよう、目に付きやすい赤ベタで配色。今回追求したシンプルさを叶えるため、スクロール時の追従からは外すことにしました。追従なしでもファーストビューに配置することで目的を達成できていたことも理由です。

ドロップダウンメニューも活用し、その中で多くのメニューを展開し整理することにしました。

検索も検索窓をトップページに表示せず、ドロップダウンメニュー内に展開することでコンパクトに見せる効果を発揮しています。

と同時にスマホのハンバーガーメニューについてもシンプルな設計にこだわりました。

全てメニューを表示すると縦にとても長くなり、ユーザーにとって使い勝手の悪いものになってしまいます。そのため、クリックしたら下位のメニューが展開する見せ方でブラボーグループ様からも了承いただくことができました。

(ブラボーグループ様もこの部分の見せ方について気にされており、解消できてよかったです!)

 

 

 

ここでときおり話題になるトピックを!ページトップについて。

スクロール時に追従させているサイトもありますが、「そこまで必要?」と思うことがあります。スマホだと特に、操作性も落としてしまう導線だと考えています。実際この「ページトップ」導線を使っているユーザーも少ないことでしょう。

iPhoneだとステータスバーをタップし、この動作を取るユーザーも多くいること想像しますよね。現在、「ページトップ」の導線がないサイトも存在しているくらいです。

そのため「ページトップ」は、フッターのデザインアクセント程度の役割とみなしてよいと考えています!実はこの「ページトップ」デザイン、メインビジュアルでもアクセント処理として扱われていることがあります。矢印の向きは ⬇ です。ぜひ他サイトでこの処理を探してみてください★

タブをフル活用!

今回タブが、情報整理に貢献しています。

 

そこでも一番複雑なタブ構成が「オススメ楽曲ベスト3」!

情報整理の仕方について一番悩んだコンテンツでもあります。スマホではプルダウンで選択する形式を取り、使いやすいUI設計を目指しました。

ただ!この設計はバックエンド側の処理工数について検討する必要がありました。今回はエンジニアと相談しこの設計を実現することができました★

こういった時の事前の対策として、WFの時点で&デザインが仕上がったタイミングでエンジニアに問題がないか前もって確認を取りながら進めるようにしています。

デザインはトレンド感を取り入れる

デザインリニューアルするからには、トレンド感を取り入れたい。デザイン制作に携わる者にとっては、ごく自然な考えです。それでは本サイトで取り入れたトレンドについてピックアップし、ご紹介します。

▼背面全面に写真を配置し、レイヤー構造を採用

その上をコンテンツがスクロールしていくことで、スクロール時に奥行きが加わり、スケール感ある迫力あるイメージを効果として与えています。

▼ブロック単位で横に流れる文字

デザインのアクセントになるだけでなく、リッチ感も演出してくれます。英字は配置するだけで華やかさが加わり、装飾として多用されています。

(この英字の装飾方法は使いやすくもあるので、安易に使うことなく上手に取り入れたいところです!)

この2つのデザイン処理について、デザインギャラリーサイトを見ていると同じような表現をしているサイトをいくつか見かけるかと思います。実はデザインって、基本パターン化して作られているのです。

似通ったサイトに見えないよう処理を組み合わせて、オリジナルのエッセンス等を取り入れデザインしていることが分かります。じゃあ誰でもトレンド感あるデザインが作れるんじゃないかって??

それは一朝一夕ではできません。が回答です★

余白感や細部のディティール、フォントについてもベストを尽くして完成させているためです。心地よいデザインにたどり着くまで何度も試行錯誤を重ねます。

ディレクターである私もラフデザインを作ることがあり、身を持って知りました〜〜!機会があったらみなさんもデザイン制作にチャレンジしてみてください♪

チームメンバー一丸で作ったサイト!

最後に本サイトの制作メンバーについて触れさせてください♪

本サイトはチームメンバー一丸となって作り上げ、思い出深いサイトとなりました。制作中はお互い遠慮することなく必要あらばみんなで集まって、すり合わせや進捗確認を行いました。リモートメンバーが多いため、そんな時はSlackのハドル機能を使って柔軟に集まります!

チームワークって大切!!

リリース日はみんなでオフィスに一同に集まり、追い込みました。オフィスにいた他メンバーも気にかけてくれて、応援してくれたりその場を和ませてくれたり?

22時前にオフィスに届いた出前(ビルの表の入り口が閉まっていて、出前のお兄さんが辿り付けず!予定より配達時間が遅くなってしまったのです 笑)をみんなで囲んだことは今でも良い思い出です。←ちなみにレアなことです。めったにありません!!22時はオフィスに誰もいないことが基本である弊社。

リリースできた時はみんな感極まり、喜びの声が上がりました!感動!!!私も嬉しかったー。ついに我が子が世にリリースされた気持ちです✨✨

今現在もブラボーグループ様がこまめに更新して下さり、サイトを育てている様子を見るととても嬉しく思います。

 

株式会社ジョーレンは「EC-CUBEインテグレートパートナー」ページで、プラチナランク企業として掲載されています。他EC-CUBE構築実績も掲載していますので、ぜひご覧ください!

https://www.ec-cube.net/integrate/partner/

https://www.ec-cube.net/integrate/partner/partner.php?partner_id=1431

Shopify多言語対応。「ゆとり屋」オンラインストアをリリース!

Tシャツやステッカー等、ゆとり屋様オリジナルグッズを販売するサイト。

ゆとり屋ONLINE STOREを2023年1月24日にリリースいたしました。弊社オリジナルデザインで、Shopifyにて構築しております。

https://onlineshop.yutoriya.shop/

  

 

鳥の種類から選ぶ」ページは弊社メンバー間でも人気のページ★

細かな描き分けをしているゆとり屋様のイラストは、思わず見入ってしまいます。

本サイトならではの魅力あるコンテンツです。

ゆとり屋様のInstagramでも本サイトへの導線が貼られ、商品のご案内をしていますので、合わせてチェックしてみてくださいね。

 

さて本ブログでは、本サイトの制作に関することについて 3つ!ご紹介したいと思います。

構成について変化にこだわる

デザインはリズム感が大事です。

リズム感って?

同じ拍子のリズムが継続して刻まれていると、単調となりリスナーにとってあきあきしてしまいますよね。

早いリズムだったり、ゆっくりなリズムだったり変化あるリズムを刻むことで、あきなくリスナーは聴けるのです。

サイトの見せ方も同じで単調な構成が続かないよう、リズム感ある構成で組んでいます。

本サイトの場合、以下構成を例にあげましょう。

・ランキング

 「もっと見る」の導線

・ゆとり屋が選ぶおすすめ

  「スライド」の展開

ゆとり屋様に提案し、この構成で設計することを確定。違いも出て、ユーザーにとっても分かりやすい効果が出ました。もちろん配色等でも違いを出しています。

またこの2つのコンテンツは、更新頻度が多いため上部に配置しています。より見せ方の差別化が重要になりますね。

スマホファーストを意識する

PCのメインメニュー(「Tシャツ、パーカー・トレーナー」等が並んでいるメニュー)は、

メニュー間の余白が狭いため少し窮屈に感じ、可読性・視認性が下がっているかもしれません。

ゆとり屋様と相談し、「メニューの文字数を短くする」or「メニュー数を減らす」ことも検討しましたが、ECサイトは特にスマホからの閲覧数が多いため、PCサイトのメインメニューはこの見え方でよしとしました。

それより、メニュー名&メニューの数を優先することを選択したのです。

近頃、「(PCデザインより)スマホデザインを先に確認したい」といったクライアント様の声が多くなりました。

至極当たり前のことではありますが、ますますスマホデザインの重要性は高くなること感じています。

デザイナーは、スマホからもデザイン作れるようにしておくといいですね!

心理学的法則を活用

ミラーの法則

サイト制作中にゆとり屋様から相談を受けました。

「【鳥の種類から選ぶ】のサブメニュー。たくさんメニューを設けてもいいと思いますか?」

この問いを受けた時に、私の頭の中でよぎったこと。

———————————

マジカルナンバー7

———————————

制作に携わるみなさんなら、一度は聞いたことがあることでしょう。

マジカルナンバー7とは。

【ナビゲーションの項目数は、7つ以下に制限しなければならない】

私もこの数字を意識して、10年以上今までサイト制作を行って来ました。

そしてクライアント様にもこの説明をしたことがあります。

と同時に著書「UXデザインの法則」にて、ミラーの法則として以下説明書きがあったことを思い出しました。

———————————————————————————————————————————————————————

ナビゲーションメニューのようなデザインパターンは、選択肢が常に目に見えていてユーザーが項目を覚える必要がないので、これらのリンク数を制限してもユーザービリティ上のメリットはない。メニューが効果的に設計されている限り、ユーザーは自分の目的さえ覚えておけば目当てのリンクを素早く識別できる。

———————————————————————————————————————————————————————

ゆとり屋さんサイトに訪れるユーザーは鳥好きが多くいるため、

「この鳥グッズを見たい!」という具体的な目的を持ってサイトを訪問することが予想されます。

そのため、メニュー数が多くても問題ないこと私はこの著書の裏付けにより回答をしました。

また多くの鳥の種類のグッズを取り揃えていることは、本サイトならではの優位性でもあります。

数多く見せるほど注目してもらえ、本サイトの最大の魅力にもつながるのです。

この続きの詳しい説明は、著書「UXデザインの法則」に書いてあるので、興味のある方は読んでみてくださいね。

さてその他2点、このサイトでも共通して語れることがこの著書に書いてありましたので、合わせて紹介させてください。

ヤコブの法則

ユーザビリティの専門家ヤコブ・ニールセンによって2000年に提唱。

———————————————————————————————————————————————————————

・ユーザーは他のウェブサイトでの経験の積み重ねを通じて「デザインはこうあるべき」という期待を築き上げる傾向がある

・ありふれた慣例に従ったデザインにすることで、ユーザーがサイトの中身やメッセージ、扱う商品にもっと集中できるようにすべき

———————————————————————————————————————————————————————

というものです。

本サイトでいくつかピックアップして例を挙げると以下になります。

1)サイトロゴ

2)ヘッダー右上にあるカート等のボタン

3)数量のセレクトボタン

4)カートに追加するボタン

5)フッターにある規約関係のページ、SNSの導線

どのサイトでも基本共通して本サイトのような配置、挙動をしているでしょう。

これはメンタルモデルという心理学の概念です。(詳しくは著書「UXデザインの法則」を参照)

この法則を意識した設計にすることで、ユーザーは快適に目標達成に集中できるため、本サイトでも基本事項として取り入れています。

美的ユーザビリティ効果

———————————————————————————————

見た目が美しいデザインはより使いやすいと感じられる。

———————————————————————————————

見た目の美しさは、ユーザビリティがUPすると研究結果により証明されています。

コストが捻出できないため、見た目は二の次。

とプロジェクトにより判断されることがありますが(とても悲しい事実(T_T))、この実証結果により今一度見直すべきかもしれません。

この著書で他注目した事例として、

・見た目が美しい携帯電話

・見た目が美しくない携帯電話

でユーザビリティテストをしたところ、

【ユーザビリティを高く評価しただけではなく、携帯電話の見た目によってパフォーマンスにもプラス効果があり、タスクの完了時間が短縮された】

という結果が出たそうです。

リリース後、本サイトを紹介したところみんなから「かわいい!」というコメントを寄せてくださいました。

それはユーザビリティだけではなく、パフォーマンスにも良い影響を与えること示唆してくれています。

「見た目が美しいデザインはユーザーにポジティブな反応を引き出し、デザインが信頼性を高めてくれる。」

ともこの著書で伝えていました。ユーザー体験が重要視されている昨今、深く同意することです。

成果を出すなら、デザインまでしっかり力を注ぎ実施すべきであることメッセージとして受け取れるでしょう。

まずは見た目を美しくしてからではないと、ユーザビリティテストも効果を発揮しない事実。

デザインの価値が重要であることこの著書が教えてくれました!

 

株式会社ジョーレンではShopifyやEC-CUBEの構築はじめ、デザインについてもお引き受けしております。

さまざまな課題を抱えている方、ご相談からでも構いませんのでお問い合わせください。

各専門スタッフがクライアント様と伴走し、制作を行わせて頂きます。