EC-CUBEのドキュメントはどこに?
昨日の記事、グロースハックってなに?の評判が良かったので、調子に乗って今日も書きます。
EC-CUBEを使ってネットショップを構築する場合、よくドキュメントの話になります。
こういったオープンソースのパッケージの場合、特に日本語のドキュメントが少ないのがよく問題になります。
DB定義書や仕様書、コーディングガイドラインなど、あると開発がスムーズに進みます。
さて、EC-CUBEのこれらのドキュメントはどこにあるのでしょうか?
公式サイトにも記載がなく、慣れていない方は探すのに苦労すると思うのでご紹介です。
実はソースコードに同梱されています。
EC-CUBEをダウンロードして展開すると、docsというディレクトリができます。
実はこの中にドキュメントが入っています。
- eccube-diagram.jude
- astah* community - 無償UMLモデリングツール( http://astah.change-vision.com/ja/product/astah-community.html )用のER図とかのデータベースの定義ファイルです。
これが一番見やすいですね。
- astah* community - 無償UMLモデリングツール( http://astah.change-vision.com/ja/product/astah-community.html )用のER図とかのデータベースの定義ファイルです。
- ER-D_Logical.pdf
- 上記のeccube-diagram.judeに含まれているER図(論理)です。
- 上記のeccube-diagram.judeに含まれているER図(論理)です。
- ER-D_Physical.pdf
- 上記のeccube-diagram.judeに含まれているER図(物理)です。
- 上記のeccube-diagram.judeに含まれているER図(物理)です。
- table_definition.xls
EC-CUBEのテーブルに独自のカラムを追加したり、新しいテーブルを追加する場合はこれらのドキュメントに追加して管理しておくと何かと便利です。
ソースコードに同梱されていないドキュメント
実はEC-CUBEには、カスタマイズする上で指標となるドキュメントが存在しています。
これらはEC-CUBEの開発Trac( http://svn.ec-cube.net/open_trac/ )上にあります。
カスタマイズされる方はぜひ一度目を通してください。
技術情報
- 開発手順
(Trac上でのチケットの切り方などです。)- EC-CUBE標準規約
(EC-CUBEの標準コーディング規約です。)- EC-CUBE標準規約/リファクタリングガイドライン
(何年か前にやったリファクタリング大会の時に使ったガイドラインですね。Pageクラスの書き方など、少し詳しい内容が記載されています。) - EC-CUBE標準規約/単体テストガイドライン
(EC-CUBEのテストを書くためのガイドラインです) - EC-CUBE標準規約/開発効率向上のためのTips
(EC-CUBE内でのエラーハンドリングの書き方とか、汎用的な少し詳しい内容が書かれています。)
- EC-CUBE標準規約/リファクタリングガイドライン
- EC-CUBE標準規約
- カスタマイズと移行の手引(v2.0)
(1.3系から2.0系にバージョンアップされた時に記述された物ですが、現在のバージョンにも該当します。カスタマイズする際に、どこにどういうファイルを作ってコードを書けば良いかなど記載されています。) - テストデータ生成スクリプト(v2.0)
(商品データ等のテスト用のダミーデータ生成スクリプトです。) - ロードマップ
(EC-CUBEのロードマップです) - コミットログML
(コミットログのMLへの参加登録ページです) - リリースノート
(各バージョンのリリースノートです。) - EC-CUBE2.4系と2.11.1の定数比較表(株式会社Reaps-Factory.様)
- attachment:EC-CUBE_定数名比較表.xls ダウンロード
(2.4系と2.11.1の定数を比較した物です。最新版では多少ズレがありますが、大体一緒です)
- attachment:EC-CUBE_定数名比較表.xls ダウンロード
- EC-CUBE運用マニュアル(株式会社サイバーウィル様)
(プラチナパートナーであるサイバーウィルさんが作成された運用マニュアルです。非常にありがたい...) - プラグイン関連情報
(EC-CUBEのプラグインを開発する時に役立つドキュメント類です。) - API関連情報
(現状ではAPI関連のチケットへのリンクが貼られているだけですが、リンク先のチケットのコメントでAPIに関する基本的な事が記述されています。)
増えましたねー。
昔はこんな便利なドキュメントありませんでした...皆自分たちで一所懸命作っていました。
あと、EC-CUBEは専門の書籍が何冊か出版されています。
これらの書籍も役に立つと思いますが、本によっては内容が古くてあまり使い物にならない事が多いので注意が必要です。
以下に比較的最近の本を挙げておきます。これらの本も一部内容が古くて最新版のEC-CUBEではそのまま適用できない点があるので注意してください。
EC-CUBE3対応!デザインカスタマイズガイドブック
新しくなったEC-CUBE3に対応したデザインカスタマイズブック。2017年1月現在 EC-CUBE3のデザインカスタマイズについて解説されている書籍はこれだけです。とりあえず買いましょう!
余談ですが、最近のEC-CUBEではテスト駆動開発ちっくな事もやっており、テストのカバレッジを上げる事に尽力しています。
皆さんも、もし「EC-CUBEがあってよかったなー」と思って頂けたらテストを書いたりとか、EC-CUBE本体の開発にご協力をお願いします。
グロースハックってなに?
最近、香ばしい感じで「グロースハック」という言葉をまわりで良く聞きます。
ハックという単語が入る言葉には「ライフハック」「ハッカソン」など色々ありますが、「グロース」をハックするとは初耳です。
そもそも「グロース」ってなんぞや?
新し物好きなので、調べてみました。
直訳すると「成長ハッキング」
「訳せてないじゃん!」というツッコミは置いといて、グロースハックの「グロース」とは英語で書くと
Growth
日本語に訳すと、
- 成長
- 育成
- 発展
です。
いや困った、「成長をハック」ってどういう意味なんだろ?
ググると難しい単語が並んだ色々な事例の紹介などの記事がヒットします。
でもどれを読んでもいまいちスッキリしない。
よくわからない事をなんとなくで知ったかぶりしたくないので、専門家の方に聞いてみました。
イノーバの佐藤さーん!グロースハックって何か教えて!!
弊社でコミットしている汎用CMS、concrete5のユーザグループに、concrete5を使ってグロースハック!というお仕事をされている、最近イケイケな株式会社イノーバの佐藤さんという方がいまして、この疑問をスッキリさせてくれるだろうとfacebookで聞いてみました。
そしたら社長の宗像さんまで解説してくれて非常に勉強になりました。
以下その時の会話(コメント)を記載します。
- 緑:佐藤さん
- 青:僕
- 茶色:宗像さん
佐藤さん、グロースハックってわかりやすく言うと何ですか?
webマーケティングもエンジニアが担当することになりました
なんだいつものかw
そうなんですよw
想像ですが、アメリカだと職種の専門性が高いし、マーケティングの概念も実践も行われているので、エンジニアは口を出せなかったのかもしれません。(日本と比較して)
なので注目されましたと。
日本のフリーランスエンジニアとか、エンジニア社長からしてみれば、いつものやつです。
面白いので宗像さんにも聞いてみたいけど、見えるかな?
宗像さん、あってます?
うーん、合ってるといえば合ってますし、合ってないと言えば合ってない。
グロースハックは、横串の組織(担当者)なのがポイントなんだと思います。
製品開発からマーケティングまで全部の領域に口を出す。定量的な最適化と、定性的な最適化のバランスを取りながら、ユーザー数の最大化を目指す。
エンジニアが担当する事が多いのもまた事実ですが、テックに詳しい文系の人が担当するのも可なりです。(ただ、あまり後者が居ないので、エンジニアがやっているのだろうと理解しています)
えええと、わかりやすく言うと
製品の企画、開発段階から音頭取る人がいて、各部署の思惑や都合による妥協とかブレを無くして、目標のために最適な行動だけする様にする。
って事ですか?
で、そのためにはエンジニアリングとマーケティングをよくわかってないといけなくて、マーケッターのほとんどがエンジニアリングわかんないから結局エンジニアがやってると
もう少し、視点がユーザーよりな気がします。
ユーザー視点で、そもそも、どういう経路でサービスの存在を知って、サービスを使いながら定着して、友達を招待していって、
という一連のプロセスを最適化していく事で、お金をかけずにユーザー数を伸ばしていこうっていう感じかと。
なるほど。
今までやってきた一連の流れに名前が付いた感じなんですね。
うーんと例えばですが、ユーザー獲得っていうのは、マーケティングに任せると、リスティングを大量に買ったり、SEOやったりとか、LPの改善ぐらいしか出来ないのですが、開発面にも口を出すとすると、ソーシャルでの友人招待、ユーザーのアドレス帳連携、みたいな機能に機能的な部分でのユーザー獲得も進められる感じです。
あー、そうです。名前が付いただけです。
ありがとうございます!
スッキリしました!
名前がついたのと、全体が絵になって、フレームワーク化された感じでしょうか。
ありがとうございます!
勉強になります!
あと、有名な例だと、airBnBが、craiglistっていう外部の掲示版サイトに自動投稿する仕組みを作って、ユーザー獲得をしたりもしてまして、こういうtipsというか、ハッキング的なものも含むようです。
いえいえー。
いつもお世話になっておりますので!!
こちらこそです!
今後も何かと佐藤さんをお借りすると思いますが、よろしくお願いします!w
議論がすげー伸びてるw
これテックブログにした方がいいんじゃないか説w
宗像さん、ブログに書いていいですか?w
いいです!
ありがとうございますー < イマココ
と言うわけで非常に貴重な事を教えてもらいました。
持つべき物はグロースハッカーの友人ですねw
「聞くは一時の恥、聞かぬは一生の恥」昔の人はいい事を言うもんです。
グロースハックをまとめると
ここまで読んで「なんだ名前が付いただけか」と思われた方もいるかもしれません。
でも名前が付くという事は、方法論が確立され、ぼんやりしていた物がはっきりとわかりやすい形になるという事です。
有名な「PDCAサイクル」も、ウォルター・シューハートが提唱する前からあったハズです。こういうものはある日突然沸いてきたりしません。
大切な事はこういった言葉に踊らされずに本質を見極める事です。
最近思うのは、Webのプロフェッショナルな人達に求められるスキルセットの幅がどんどん広がってるなーという事です。
特に今まで「文系=マーケッター」「理系=エンジニア」というなんとなくの区分けが無くなってきてると思います。
得手不得手はあると思いますが、目的を達成するために得意な事だけやっていれば良いという時代ではなくなってきたのを感じます。
グロースハックはこのPDCAをWebサービスやモバイルアプリなどのIT関連のプロダクトに特化したかたちで落とし込み、わかりやすく使いやすくした物だと言えると思います。
せっかくわかりやすくしてくれたんですから存分に学んで使い倒しましょう!
特に、目的や目標が明確なECサイトでは応用が効き効果も確認しやすいと思います。
最後に本題ですがw ぜひ私たちと一緒にグロースハックしましょう!
レッツ!グロースハック!
EC-CUBEの消費税率変更の対応について
東京オリンピックも決まり、身の回りでもチラホラと景気の良い話が聞こえる様になってきました。*1
来年4月に予定されている、消費税率の5%から8%への増税もいよいよ現実味を増してきました。
もうほぼ確定でしょう。
先日、EC-CUBEも新バージョン、2.13.0がリリースされ、この税率変更に正式に対応しました。
今までも管理画面から消費税率は設定できたのですが、これではオープン後の税率変更に問題が出てしまいます。
その辺の事を、毎月下北沢オープンソースカフェで行っているEC-CUBE東京ユーザグループの勉強会でやってきたので、今日はこの消費税率変更について書きます。
旧バージョンだと、どのような不具合があるのか?
先日リリースされたEC-CUBEの新バージョン、2.13.0では税率変更対応がなされています。*2
ただ、受注メールテンプレート等に細かいバグがあり、その辺を修正した2.13.1が10月ごろにリリースされる見込みです。
では、2.13.0より前のバージョンでは税率変更をした場合にどの様な不具合が起きるのでしょう?
マイページでの過去の注文の金額表示がおかしくなる
この画像はマイページの注文履歴の詳細画面です。
5%の時に注文した情報ですが、管理画面から税率を8%に変更すると、商品単価と商品小計が新しい税率で計算されてしまっています。
合計金額は正しい金額で表示されています。
管理画面で受注情報を編集すると、新しい税率で再計算されてしまう
管理画面で税率変更前の受注情報詳細を見ると、マイページと同様に新しい税率で商品単価が計算されてしまっています。
このまま何も変えずに登録すると、新しい税率で再計算され、合計金額まで変わってしまいます。
カード決済等の決済金額が変わる
これは2.13でも起こりうる事なのですが、決済モジュールによっては、翌日に決済の確定通知を送ってくる物があります。
売上をどのタイミングで計上するか?という会計上のルールも関係してくるのですが、決済が確定した場合や発送時に売上を立てる場合、消費税率が5%で注文を受け8%の時に決済確定や発送をすると、3%分金額がおかしくなってしまいます。
決済モジュールの付加機能が死ぬ
これは2.13で発生する不具合ですが、現在各決済代行会社さんから提供されている決済モジュールには、定期購入やワンクリック購入など、決済以外の追加機能が付属している場合があります。
2.13.0以降では、消費税の計算方法が変わったため、この付属機能が軒並み使えなくなる様です。
これはもう決済代行会社さんに早急にモジュールを修正してもらうしかありません。
対応策は?
さて、色々問題があり頭が痛い問題ですが、どう対応すれば良いのでしょうか?
大きく分けて3つです。
2.13系にアップグレードする
まずコレが思いつきます。
最も確実で間違いのない方法です。
ただ、EC-CUBEを利用しているサイトは、機能的なカスタマイズをしていることが多いです。
また、バージョン毎にテンプレートの作りも細かく違ったりするので、結局ほとんど作り直すのと同様の費用と時間がかかるケースがあります。
サイトを構築してからある程度期間が経っているサイトであれば、これを機にリニューアルされても良いかもしれません。
2.13.0と同様の消費税率変更機能を独自に追加実装する
「バージョンアップは大変だから...」と、今のサイトに2.13系と同様の消費税率変更機能を実装するというものです。
ただ、今回の問題になっている消費税計算関数は、EC-CUBE内のいたる所で使われているので、改修範囲が多岐にわたりこれもそれなりの費用がかかります。
とにかく準備は早めに!!
消費税率変更時の切り替え時期は6ヶ月の猶予期間があり、また売上をどのタイミングで計上するか?などの会社ごとの会計ルールによって変わる部分も多くあります。
その為、会社の経理や税理士さんと相談し、社内でどういうルールで運営するか?を決め、それに沿って対応する必要があります。
改修やリニューアルであればそれなりの時間と費用も必要になります。
変更までもう半年しかありませんし、年末年始も挟みます。
3月決算とかであれば、ちょうど期の切り替わりの時期なので、税率変更の時期はただでさえ忙しい時期です。
どういう方法で対応するにせよ、早い段階からの準備が必要になってきます。
*1:僕には来ませんが...
*2:それ以外にもMySQLでのセッションの不具合や「決済処理中」の時のポイントや在庫の不具合など、いくつか不具合の修正がされているので、http://svn.ec-cube.net/open_trac/query?group=status&milestone=EC-CUBE2.13.0 をぜひご確認ください。
ECサイトのセキュリティの原則 - 最近の情報漏洩に対して
どうもお久しぶりです。
今日は、最近多発しているECサイトの情報漏洩についてです。
最近、いくつかのWebサイトでおきた情報漏洩のニュースを良く聞きます。
特に、ECサイトでの通常考えられない様な漏洩もあったりするので、発注者側、開発者側の人に対して強く言いたい事があります。
漏れたら危険な情報は持たない
こう言ってしまうと余計な危機感をあおりそうで嫌ですが、基本的に全てのWebサーバは侵入可能です。
どれくらい難しいかという話で、時間や労力を考えなければインターネットに繋がっている全てのサーバは侵入可能なのです。
Webサイトのセキュリティは、それを踏まえた上で、「侵入されても最悪の事態を防ぐ」「侵入させにくくする」という視点で対策を施す必要があります。
なんだか原発と似てますね。
「事故が起きない事を前提に考えてはいけない」という事です。
その為には、基本的なログインIDやパスワードの管理や接続IPの制限、ミドルウェアの保守等も当然ですが、なによりかにより最強なのが「情報を持たない」という事です。
持っていない情報は漏洩のしようがありません。コレが最強です。
では、ECサイトで漏れたら致命的な情報とは何でしょうか?
実害が発生しうる可能性が最も高く、危険度MAXなのが決済情報、それもクレジットカードの情報です。
最近起きた情報漏洩の最悪なケースがコレです。
クレジットカード決済で必要な情報は、カード番号と有効期限、カード名義人情報です。
それだけだとあまりにも危険なので、インターネットで決済する場合に追加で付与された情報がセキュリティコードという、クレジットカード裏面に記載されている3桁の番号です。
この漏洩を起こしたグローバルデータのサイトの場合、なんとこの情報をセットでサーバ内に保持していたのす。
僕らECサイトを制作する事を生業としている人間からは信じられない仕様です。
原発に例えると、「燃料棒を監視も施錠も無い庭の物置に積んどいた」くらいの危険度です。
通常、ECサイトでクレジットカード決済を行う場合、カード番号や有効期限などの決済に必要な情報を、Webサイト上で入力してもらいますが、その情報はECサイト側では保持しません。
ECサイトでは受け取ったカード番号等を、保存せずにそのまま決済代行会社のサーバに安全な通信で送信し、結果を受け取ります。
保存したとしても一時的にサーバのメモリ上にその分だけ保存され、1/100秒くらいで消えてしまいます。
また、カード情報を入力しないでも、1度カード決済をすれば2回目以降はカード番号の入力を省略できる機能があります。
これは、ECサイト内の顧客IDとカードの決済情報を決済代行会社側が結びつけておいて、顧客IDと店舗の契約情報を結びつけて決済ができるという仕組みです。
この場合、店舗の決済ID、暗号鍵、顧客IDが無いと決済できず、そのECサイトのサーバからしか決済を受付ない様になっています。
つまり、カード情報なんかWebサーバで持っていなくても、正規の手順を踏めば正常な決済は可能なのです。
これは予想ですが、グローバルデータではレンタルした端末を返却した後に決済をするので、それまでカード情報を持っていないといけないと思ったのでしょう。
あまりにも決済についての知識が無さ過ぎる仕様です。
考えられる理由としては、
- 制作会社が顧客IDで決済できる事を知らなかった。
- グローバルデータ側がこの仕様を強要した
のいずれかだと思います。
ECに詳しくない制作会社の方へお願いです。
決済については決済代行会社の方が聞いて無い事まで詳しく教えてくれます。ちゃんとサービス内容や仕様を勉強してください。
ECサイトを発注者の方へお願いです。
利便性を優先するあまりに、危険な仕様を強制しないでください。概ね利便性とセキュリティの強さは反比例します。
それにより事故が起きた場合の被害額を考えれば、おのずと正しい判断ができるはずです。
できれば、個人情報についても決済代行会社さんで持って頂きたい位ですね。
EC-CUBEの脆弱性について
さて、お話し変わってEC-CUBEです。
先日、2.11系に危険度の高い脆弱性が発見されました。
http://www.ec-cube.net/info/weakness/
まだパッチを当てていないサイトはすぐにでもバックドア等の確認をして、パッチを当ててください。バージョンアップの必要はありませんが、パッチを充てるだけでは不十分です!改ざんされていないか確認してください。*1
制作会社にお願いしても大した金額は取られません。
今回の脆弱性についての詳細は、EC-CUBE東京ユーザーグループで、EC-CUBEのエバンジェリストでもある川口先生が詳しく解説もしてくれています。
これを機会に、東京近郊の方はぜひユーザグループへの参加もお願いします。「参加」ボタンクリックするだけです。
今回の脆弱性についてですが、SQLインジェクション、XSSとWebアプリの脆弱性のお手本の様な脆弱性のオンパレードです。
でも、EC-CUBEのクレジットカード決済モジュールは、サーバ内にカード情報を保持する様には作られていません。
なので、顧客のカード情報が漏洩する事はありません。
ある条件が揃った際に情報が漏洩する危険性があるというもので、EC-CUBEでは会員のログインパスワードは暗号鍵を混ぜた状態で暗号化されており、ショップの管理者でさえもパスワードを知る事はできません。*2
EC-CUBEはオープンソースであり、株式会社ロックオン主導で開発が進められていますが、多くをボランティアの開発者に支えられています。
その為、時にこういったバグが出てしまう事が稀にあります。
でも、川口先生をはじめ、主要メンバーはECサイト構築のプロなので、漏れても最悪の事態を招かない様に作られています。
また、公式のインテグレートパートナーやコミッターには、一般公開前にこういった脆弱性情報が通知され、公開前にパッチを当てる事ができる様になっています。
コミッターのひとりとして、EC-CUBEのこういった「事故が起きる前提で考える」体制も評価のひとつに加えて頂きたいと思います。
海外向けショッピングサイトも制作可能! EC-CUBEに多言語対応版が登場!!
ついにリリースされました!EC-CUBEの多言語対応版です。
過去に中国語版がこそっとリリースされて無かった事にされたりと、EC-CUBEで日本語以外の言語を扱う事は色々ありましたが、今回ついに正式にリリースされました!
今回僕は開発にはあまり関わっていませんが、concrete5のローカライズでの経験をふまえ、多言語化する際に翻訳のしかたなど色々口を出させて頂きました。
今回のEC-CUBEの多言語版ですが、残念ながらひとつのサイトで日本語、英語など複数の言語を使えるものではありません。
英語のECサイトやスペイン語のECサイトなど、ひとつのサイトでひとつの言語を使える様になるという物です。
それでも、使い慣れたEC-CUBEで海外向けにECサイトを作る事ができるというのは、ショップオーナーさんにとっては嬉しいことなのではないでしょうか?
ついでに英語版のフォーラムもスタート!
多言語版のEC-CUBEがリリースされた事により、英語のサポートフォーラムもオープンしました。
まだまだ書き込みは少ないですが今後どんどん書き込みが増えていくことでしょう。
僕も英語の勉強がてらなるべく書き込む様にしたいと思っています。
余談ですが、このフォーラムには日本語版のフォーラムと同じ様にバッチ制度があるのですが、その名前にちょっと違和感を覚えますw
一番下のランクは「芸者」じゃないと思うんですよねw
あと一番上は「NINJYA」でしょ!富士山じゃない!!
今は英語版のみ
多言語版といっても、現在は英語の言語ファイルのみリリースされています。
今後、他の言語ファイルも順次追加されていくとの事で、予想ですがスペイン語とか早めに出るんじゃないかなー?と思ってます。
もちろん、オープンソースなので自分で言語ファイルを作る事もできます。
言語ファイルの作り方
言語ファイルは、
/data/locales/
に格納されています。
ここのja.poというファイルをpoeditというソフトで編集し、言語ファイルを作ります。
EC-CUBEの言語ファイルはconcrete5等の言語ファイルと違って、メッセージID(msgid)に普通の英文ではなく、どんな文章、単語なのかをあ表す英語ベースのIDを使っています。
これは、日本語では同じ表記でも英語など他の言語にした場合に表記が変わるものがあるためです。*1
一通り翻訳が終わったら言語ファイルを同じディレクトリに別名で保存すればOKです。
拡張子が.poファイルとは別に、拡張子が.moのファイルができると思います。この.moファイルがプログラム内で使われます。
プラグイン作者は大変
さて、こうなってくるとプラグインが大変です。
日本語だけでなく、英語や他の言語にも対応させた方が利用者は増えるのですが、言語ファイル作るのが面倒です。
また、日本語版と多言語版両方に対応させるとなると、また一苦労です。
将来的には多言語版1本にまとめて欲しいですね。
ロックオンさんに強く言っていきたいと思います。
海外向けECサイトをやってみよう!
せっかく多言語版が出たので海外向けECサイトをやってみましょう。
最初は英語サイトだけで充分です。世界の多くの国で英語は第二言語として利用されており、想像以上に自社の顧客の絶対数を増やしてくれます。
ただ、何点か気をつけないといけない点があります。
税金
関税や消費税など、国や販売主体をどこに置くかによって税金の計算が変わってきます。
だいたい、関税は計算する事が難しいので、「だいたいこれくらいだよ〜」という案内にだけとどめておき、あとはその国の税関でかかったのを大人しく払ってもらう感じです。
消費税も国によっては商品によって税率が変わったり、別途別の税金がかかったりと複雑になりがちなので、事前によく調査しましょう。
配送
日本の配送業者は素晴らしいんです。
よく、「佐川は扱いが荒い」とか話を聞きますが、海外だと「届かない」「遅れれる」なんて結構ざらです。
お客さんの手元に届く前に商品が紛失してしまった場合や、配送中に破損があった場合など、「届ける」事に関しては国内の常識が通用しません。
売れないもの
販売先の国や販売する商品によっては届け出が必要だったり、そもそも販売できないもの等があります。
これも事前にしっかり調査しておきましょう。
日本の商品って結構売れます。
さいごに、日本の商品って意外と海外に売れます。
商売柄、海外向けに日本の商品を販売されているオーナーさんとお話しする機会が何回かありましたが、皆さん口を揃えて言うのが
「日本製はすごい!」
という事です。
よく、「Made in Japanはもう終わった」みたいな話を聞きますが、水にはじまり生活雑貨(特に生理用品)などは日本のものがダントツな様です。
「ウチの商品は外人には売れないよ〜」と思ってらっしゃる方、一度しらべてみてください。
本当に日本の商品って海外で人気なんです。
今後、日本は少子化や色々な要因で国内の需要は減少していきます。
需要の減っていく国内で、少ない利益率で奮闘していくよりも、広く世界に対して売っていく必要があるのではないでしょうか?
*1:複数系など
古巣のエスキュービズムという会社で学んだ事
あけましておめでとうございます。
クロスキューブの佐々木です。本年もよろしくお願いします。
今日は、古巣の噂話が耳に入ったので、株式会社エスキュービズムという会社について書こうかと思います。
確か今から5年くらい前の27才の頃、僕はこのエスキュービズムという会社で働いていました。
それまで働いていた会社では自社の社内システムの開発と保守が主な仕事だったのですが、自分たちのためではなく、お客様のためにシステムを作りたくてこの会社に入りました。
当時、エスキュービズムはEC-CUBEのゴールドパートナーで、ベンチャーキャピタルから出資を受けビジネスマッチンングの自社サービスの開発に集中しているときでした。
そんな時に
「ECやりたい」と面接を受け、
「もうEC-CUBEやめるつもり」と言われ
「もったいないなぁ」と言ったら
「じゃあ、やって」と採用されました。
この会社は、社長が東大 > リクルート > 起業で、CTOも早稲田の理工学部の院とかを出てる、インテリ起業でした。
今思うと「よく僕なんかを採用したなー」と思います(笑。
正直、ツライ事もたくさんありましたが、今日はこの会社で学んだ素晴らしいことについて書こうと思います。
続きを読むなぜWordPressではなくconcrete5なのか その2
前回、長くなってしまったの分けた記事の第2弾です。前回の記事はこちらからどうぞ。
なぜWordPressではなくconcrete5なのか その1
concrete5は素人向けのCMS
concrete5は素人向けのCMSです。
こう言うと変な誤解を受けそうですが、concrete5はMicrosoftのWordが普通に使えるレベルの人をターゲットに設計されています。
つまり、Webの素人です。
これはどういう事かと言うと、実際にコンテンツを作るべき人はWebの素人である事が殆どだという事です。
Webサイトは公開したら終わりではありません。
SEO的にも常に更新し続け、情報を発信し続ける事が必要です。
しかも最近は求められるそのスピードもドンドン速くなっています。
昔の様に、制作会社に更新を依頼して、上がってきた物を確認して...ではチャンスを逃し、間に合わない事が多いのです。
管理画面を見て「ウッ!」とならない
EC-CUBEとconcrete5に共通する所に「直感的に扱える」という点があります。
僕はEC-CUBEに出会う前はosCommerceやZenCart等を利用していました。
EC-CUBEに出会った時に感激したのが管理画面の出来の良さです。
正直、osCommerceやZenCartの管理画面は字やメニューが多く開いた瞬間に「ウッ!」となっていたのですが、EC-CUBEの管理画面はごくごく自然に馴染めました。
これと同じ様にXoopsやJoomla!等の汎用CMSの管理画面には正直「ウッ!」となっていました。
concrete5にはそれを感じなかったのが興味を持つキッカケでした。
これはどういう事かと言うと、「迷わない」という事です。
僕は一般の人よりも多くのWebサイトを見て、CMSやツールをいじっています。そんな僕ですら「ウッ!」となる管理画面なら、一般の人にとっては、ただただ恐怖でしょう。
UXの勉強をするとわかるのですが、ユーザにとってWebサイトを閲覧するという行為は想像以上にストレスを与えています。
ボタン一つクリックするのも、画面をスクロールさせるのも嫌がり、如実に直帰率やCVRに結びつきます。
極端に言うと、ユーザは求めている情報を探す事が大嫌いです。
そこにある事を求めています。
これは管理画面でも一緒です。
使いにくい管理画面はユーザのモチベーションや効率を下げ、コンテンツの作成の足を引っ張り、結果としてサイトの価値を下げてしまいます。
その点、concrete5は管理画面を見ずとも、作っているページを直接見ながら編集出来るので非常に直感的にコンテンツを作る事ができます。
concrete5は運用フローを作るCMS
concrete5はそのドラック&ドロップによる直感的なページレイアウトの作成機能ばかり目立ってしまいますが、一番重要な機能は細かな権限設定機能にあります。
これがどういう事かと言うと、ユーザ、グループ毎に使えるメニューを制限し、運用フローを限定出来ると言う事です。
例えば、ニュースページだけ更新する業務の広報担当者がいたとします。
その人にとって製品情報ページは関係ありません。日々の業務で必要なのは正確な情報を「新着情報一覧」というページの下層に速やかに作っていく事だけです。
concrete5では広報担当者に「新着情報一覧」ページの下層にのみページを追加できる権限を設定する事ができます。
また、余計なヘッダーやサイドバーを設定する必要もありません。そういった要素はサイト管理者が事前に管理画面からテンプレートとして設定しておく事ができます。
また、コンポーザーという機能があり、Wordpressの様なフォームに上から順番に入力していけばサイト設計者の意図通のページができあがる機能もあります。(このフォームも管理画面から自由に設定できます。)
- 広報担当者はconcrete5にログインしたら、メニューバーからコンポーザーの「書き込み」というメニューを選択し、用意されたフォームに上から順番に入力していきます。
- リリースに添付するPDFファイルを同じ画面でアップロードし、画像があれば画像もアップロードし、同じ画面内で見出し画像用にクロップします。
入力画面拡大 - その後、作成したページを保存し、上長に報告します。
- 上長は承認前のページを閲覧し、内容に問題が無ければ「承認」ボタンをクリックしてページを公開します。
この様に、concrete5ではそのユーザの業務に必要なメニュー、権限だけを付与し不要な物を表示してユーザを迷わせる事をしない様にWebサイトを構築することが出来ます。
ページを作れる作れないだけでなく、承認作業や、挿入出来るコンテンツの種類まで設定する事ができます。
concrete5でサイトを構築する際は、実運用時の効率を考えた「業務に合わせた運用フロー、UIのデザイン」が最も重要な要素になってきます。
つまりCMSで「ユーザを迷わせない」事ができるわけです。
それも自由に細かく設定できます。
しかもHTML構造を崩される心配もありません。
次回は「カスタマイズ前提」の構造? です。
なぜWordPressではなくconcrete5なのか その1
どうも、お久しぶりです。
お仕事に追われている間に、あれよあれよと時間が過ぎ、あっと言う間に前回の更新から4ヶ月近く経ってしまいました。
実は先日、僕が参加しているconcrete5というCMSの日本語コミュニティの主要メンバーで、コンクリート ファイブ ジャパン株式会社という新会社を設立しました。*1
僕も一応CTOという肩書きを頂きました。
そのせいか、最近ではEC-CUBEのお仕事よりもconcrete5のお仕事の方がずっと増えてきています。
今日は、なぜ今最も熱く、ノリにノっているWordPressではなくconcrete5という少しマイナーなCMSなのか?という事を書きたいと思います。
(書いてたら随分と長くなってしまったので、何回かに分ける事にしました。)
EC-CUBE3対応!デザインカスタマイズガイドブック
新しくなったEC-CUBE3に対応したデザインカスタマイズブック。2017年1月現在 EC-CUBE3のデザインカスタマイズについて解説されている書籍はこれだけです。とりあえず買いましょう!
concrete5でブログ?
EC-CUBEのカスタマイズを主な事業としてきたクロスキューブですが、ECサイト以外のWebサイトも数多く制作してきました。ただ、クロスキューブでは単純なHTMLのサイトを作った事は無く、私達に求められるのは何かしら機能的なWebサイトばかりで、WordPressやJoomla!を使ったりもしてきましたが、どうもしっくりきませんでした。
そんな時に出会ったのがconcrete5という非常に直感的な汎用CMSでした。
WordPressは非常に優秀な素晴らしいプロダクトです。
長年、多くの有志によって開発が続けられ、熟成した非常に考えられた素晴らしいプロダクトになっています。
ただ、僕がWordPressを使った時に思ったのは
「これはCMSじゃないな、ブログツールだ」
という感想です。
CMSとは「コンテンツ マネジメント システム」略です。解りやすく言うと「コンテンツ管理システム」です。
ここで言うコンテンツには様々な種類がありますが、WordPressはその歴史から「記事」というものをベースに構成されているので、記事以外のコンテンツの扱いは少々苦手です。
ただ、WordPressの素晴らしい点にプラグインの豊富さがあります。
こういったプラグインを活用し、ページやカスタムフィールドを活用する事によって汎用CMS的な使い方ができ、多種多様なWebサイトを構築する事ができます。
しかし、それはconcrete5でブログを作る様な物です。
もっと解りやすく言うとフライパンでケーキを焼く様な物です。
はたしてそれは最適解なのでしょうか?
これは何もWordPressに限った事ではありません。
EC-CUBEでもありますし、もっ身近なところでは何でもエクセルで作ってしまう「エクセル職人」という人々がいます。
多分、皆さんの会社にも1人2人はいると思うのですが、どんな物でもエクセルで作ってしまう人々です。
こういった場合、多くのケースで「一番慣れてるから」という理由でツールを決めてしまいます。
自分だけが使う物であればそれで問題ありません。きっと最も効率が良いと思います。
ただ、僕らの様なお客様の為にWebサイトを作る人間はそうはいきません。
僕らが求めないといけないのは、「クライアントに提供する価値の最大化」です。
「一番得意だから」「慣れているから」「いつも使っているから」「他所もそうだから」という理由で採用するツールを決めてしまうのは、ある意味思考停止と言えます。
クライアントにとって何が最適なのか?という思考をすっ飛ばして、「○○で作るためにはどうすれば良いか?」という考えに移ってしまっています。
- 「一番得意」
- 作業効率が良く学習コストがかからないので短期間で安価に提供できる
- 「他所もそうだから」
- ベンダーが数多く存在し、開発後のクライアントの選択肢が広い
など、何となく考えている理由にもちゃんとした理由はあります。
ただ、制作会社はもっと考える必要があると思っています。
- リリース後の管理運用は?
- ユーザの使いやすさは?
- 後々機能を追加したくなったら?
等々です。
だから僕らはconcrete5でブログは作りません。
ブログを作る時はWordPressを使い、国内向けのECサイトを作る時はEC-CUBEを使います。*2
次回は「concrete5は素人向けのCMS」です。
メンバー募集中です!
4年が経ちました
先月、おかげ様で法人として登記してから無事最初の決算を迎える事ができました。
最初、会社を辞めフリーランスとして活動し始めた時には「いつまで続けられるかな?」と思っていたのですが、独立してかれこれ4年になろうとしています。
今、こうして振り返ると、何とお客様に恵まれていた事かと驚きます。
正直、少人数でやっていると何かトラブルが発生した時にリカバリに時間がかかり、お客様にご迷惑をかけてしまう事もありました。
そんな時でも、一方的にこちらを責めるのでは無く、プロジェクトを成功させるために進んで協力して頂けるお客様ばかりでした。
本当にありがとうございます。この場をかりて御礼申し上げます。
人手が足りません。
とは言え、いつまでもお客様の好意に甘えている訳にもいきませんし、ご迷惑をかけるなんて二度とご免です。
そこで体制を強化すべく、今まで以上に広くメンバーを募集する事にしました。
募集ポジションは、
- アルバイト(時給)
- 役員(年棒制)
です。
「働いてもいいよ」と言う方は、 info@xross-cube.com までぜひご連絡願います。
求める人物像
- 国籍年齢経験学歴性別職種一切不問
- 「独立しようかな」って思ってる方、又は現在フリーランスで活動されている方はちょうど良いと思います。
- 「仕事をもらう」のではなく、「仕事を作れる」人
- 僕らが「一緒に仕事したい」と思える人
弊社で働く事について、メリットとデメリットをご案内しておきます。
メリット
- 自由です。
- 好きな事をやってください。
- 勤務時間、業務内容は法に触れない範囲で自由です
- 仲間がサポートします
- あなたがやりたい仕事に足りない部分を補います。マーケティングや営業、技術的なサポートなど、可能な限り協力します。
- 報酬は自分で決める
- 稼げる額だけ好きに決めてください。
- 出社しなくていい
- 弊社は基本在宅勤務です。出社する所がありません。
- コワーキングスペース、喫茶店、友達の家、プールサイド、好きな場所で仕事してください。
- 家族との時間を多くとれます
デメリット
- 責任があります
- 自由の代わりに重い責任があります。あなたの事業は全てあなたの肩にかかっています。
- あなたが稼がないと、あなたの報酬が支払えません。
- 資金力は皆無です
- 吹けば飛ぶ様な小さな会社です。
- まだまだ安定していません
- 安定を第一に求める方には不向きです
- オフィスはありません
- かっこいいオフィスで働きたい方には不向きです。
ここで、弊社の企業風土というか、どんな会社なのかをご案内します。
一般的な企業とは大きく違います。
独立した理由
僕は金銭的な理由から17才で社会に出たので、様々な企業でいろんな仕事をしました。
イケイケのバイト仲間で始めたベンチャーから、高学歴で頭の良い人ばかりのスタートアップ、1部上場企業など、大小様々です。
それぞれの会社で素晴らしい所があり、また欠点もありました。
ただ、共通して存在する問題は「雇う側」と「雇われる側」に埋められない非常に大きな溝がある事です。
どんなに社長と従業員の距離が近い会社でも、そこの溝はとても深く大きいものでした。
酷い場合だと、経営陣は従業員の事を使い捨ての駒としか考えておらず、従業員も自分の給料の事しか考えていませんでした。
その結果、
- 無駄な残業
- 今の自分の業務への固執
- 不信
- 不当解雇
などなど様々な問題がありました。
でも溝があって当然なんです。
なぜなら経営者と従業員には法で定められた責任や立場が大きく違うからです。
この事が解ったとき、少なくとも国内には自分が求める企業が無い事を知り、独立しました。
法人化した理由
お客様に「個人事業主だと稟議通しにくいよー」と言われた事も大きいですが(笑)、一番大きな理由は
1人の力は非常に小さいという事です。
人間の場合、1=1ですが、1+1=2じゃないって事です。
信頼出来る仲間と助け合って目標に向かって進んで行く時の破壊力は以前経験して知っていました。
「雇う側」と「雇われる側」に大きく溝が出来てしまうなら、「雇う側」しかいない会社を作ればいいと思ったんです。
僕らが目指すところ
僕らの求めるものは、非常に小さく一般的で「充実した人生」を求めています。
金銭的に困窮する事無く生活し、幸せな家庭を持って、自分がやりがいを感じられる仕事をして笑って死にたいです。
なので会社の目指すところは会社で働く人が幸せになる事です。
これは良く誤解されるのですが、自分さえ幸せならいいという物ではありません。
「自分さえ儲かっていればいい」という状況で本当に幸せでしょうか?
僕はそんな社会は嫌です。皆で笑い合える様な社会が良いです。
「自分さえ儲ればいい」と思っている人となんか働きたく無いです。
でも僕にはやりたい事がたくさんありお金もたくさん必要です。
お金大好きです(笑)
小さい会社のまま終わる気もありません。
なので弊社のスローガンは、「目指せ堅実に一攫千金!」です。
書き始めたら長文になってしまいましたが、興味を持って頂けたらぜひご連絡願います。
あなたがどうしたら充実した人生を送れるか聞かせてください。
FuelPHPとCodeIgniterでCMS作ってパフォーマンスを比べてみた
FuelPHP Advent Calendar 2011 ということで、PHP フレームワーク FuelPHP に関するブログをクリスマスまでお届けしています。前日の@9ensanさんの記事はFuelPHPで作るログイン管理
過去記事一覧は、FuelPHP Advent Calendar 2011
CodeIgniterという軽量で高速な非常に気に入っているPHPのフレームワークがあるのですが、最近ライセンス問題が怪しいのと、バージョン2系になってから開発体制も怪しくなっていたので似た様なフレームワークを探していました。
すると、concrete5でもお世話になっている@kenji_sさんがFuelPHPをベタ褒めしていたので試してみる事にしました。
なるべく実際の環境に近い様にと超簡単なCMSを作って比べてみます。
このWebアプリがやっている事は、
- ページのパスからDB叩いてページID取得
- ページIDからそのページのコンテンツをDBから取得
- テンプレートファイルで指定してある描画エリアをキーにしてコンテンツをテンプレートファイル内に描画
と言う様なconcrete5っぽい動きをしています。
時間の都合でトップページ分のデータしか登録していませんし、そもそもCMSなのにコンテンツの登録機能とか作っていません。
まあ、でもベンチには充分だと思います。
可能な限り似た様な処理になる様に同じ様にコントローラとモデル、ビューファイルを作って同じ様に処理しています。
DBも同じテーブルを使っており、両方ともmysqli関数で接続しています。
サーバはさくらのクラウドです。
使ったバージョンはCodeIgniterはVer.2.1.0、FuelPHPはVer.1.1-RC1です。
ちょっとFuelPHPのDBまわりの設定で手間取りましたし、そもそもFuelPHPの正しいお作法に則って書かれているか怪しいですが、とりあえず出来ました。
で、例のごとくapacheベンチをかけて見ます。
ab -n200 -c200 http://cloud.xross-cube.net/CI/ ab -n200 -c200 http://cloud.xross-cube.net/Fuel/
ベンチ結果
で、結果は以下の通りです。
Requests per second | CodeIgniter | FuelPHP |
---|---|---|
1回目 | 42.74 | 39.38 |
2回目 | 30.51 | 46.43 |
3回目 | 17.15 | 17.46 |
4回目 | 45.06 | 46.77 |
5回目 | 44.87 | 21.95 |
平均 | 36.06 | 34.39 |
結論から言うとパフォーマンスは変わらなそうな感じです。
今回の環境はクラウド環境なのでどうもムラがある様です。
ちなみに、APCを有効にしてベンチかけたら下記の様な感じでした。*1
Requests per second | CodeIgniter | FuelPHP |
---|---|---|
1回目 | 126.33 | 72.11 |
2回目 | 119.95 | 26.98 |
3回目 | 37.30 | 17.46 |
4回目 | 25.92 | 93.03 |
5回目 | 119.19 | 49.71 |
平均 | 85.74 | 51.86 |
ちょっとCodeIgniterの方が速いですね。
結論
FuelPHPは書き方や使い方もCodeIgniter近いですし、なによりライセンスがMITでパッケージ機能があるのでかなり良い感じです。
今後も引き続き使ってみたいなーと思いました。
次は@ounziwさんの「FuelPHP の view に PHPTAL デザインテンプレートを使う」です。
*1:アプリ側でキャッシュ指定とかはしていません。