システム奮闘記：その29

ネット販売システムの大改装

はじめに

  ネット販売システム。
  うちの会社は、2001年5月からネット販売を行なっている。
  当時のシステム構築の話は「システム奮闘記：その6」をご覧ください。
　(ネット販売システムの導入)

  しかし、月に2,3件しかネットでの注文がこない状態が続いていた。
  割引をしているのに、どうして利用が少ないのか。理由がわからなかった。

　最初の頃は・・・

  ネットを使っているお客さんが少ないから

　という感じだったが、2002年の半ばぐらいから、新規の競合他社が出てきて
ネット販売で成功している情報が飛び込んできた。

　なぜ競合他社は成功しているのか?

  普段なら、謎を解く鍵が見つけられず、七転八倒する運命の私だが、
今回は、身近な所に、その謎を解く鍵があった。

  ヒントになったのは、中学の時の友人Ｙ君が「システム奮闘記：その12」を
読んだ感想にあった。（「システム奮闘記：その12」の補遺に掲載しています）
  Y君は、お客さんが携帯からデータ検索をしてくれない理由として
「顧客側のコスト」を挙げている。

データを検索したりする場合…
電話による音声通話だと，顧客は自分が調べたいモノを言うだけで良い。
データの検索は，相手がやってくれる。

だけど，計算機や携帯経由の場合，顧客は，わざわざ自分でデータを
探さないといけない。例え，ページをどんなに検索しやすく作ろうとも、
客にとっては，手間が増える．

つまり，顧客側に検索の手間と時間、つまりコストを負わせると言うこと。
電話での問い合わせが減って自社が省力化が出来ると言うことは、
顧客にコストを肩代わりさせているということ。

  そこで、Y君から貰った「顧客側のコスト」を重要語句として考え
ネット販売などに関する本を読んだり、ネットを自宅で使っている、
うちの会社の営業マンと話をしながら、原因を調べる事にしてみた。
  調べていくうちに、アマゾンや旅の窓との決定的な違いが見えてきた。

  顧客側の利点が出にくい販売形態!

　だった。

アマゾンを使うと、本屋へ行かなくても、自宅で注文でき
品切れの心配もない。あとは届けられるのを待つのみ。

旅の窓の場合、航空券やホテルの予約状況の確認や
予約など、自宅にいながら簡単にできる。
今までのように、旅行代理店まで行く手間が省ける。

うちの会社の場合、電話での注文も、ネットでの注文も
同じように、お客さんの所へ品物を発送する。
そのため、お客さんは、ネットを使う利点を感じない。
電話で一言で済む所を、ネットの場合、接続する手間が発生し
顧客側の手間が増える結果になる。

  これは決定的な違いであり、ネット利用に移行しない大きな原因だと考えられる。
  私にとっては、大きな発見だった。


　上層部の中には、ネット販売の売上が少ない理由を

　宣伝しない営業が悪い!

　という声があった。

　そこで上層部に以下の内容の文書を送る事にした。

ネット販売を進めていく上で

　ネット販売を進めていきます上で、どうすれば、お客さんに活用してもらえるのか、
なぜ、ネット販売の件数が増えないのか。

○　顧客の手間の増加

　電話注文の場合、お客さんの側は「＊＊を10個ちょうだい」で済みますが、
ネット販売の場合、パソコンの電源を立ち上げて、ネットに接続し、
商品を選ぶ手間が発生します。
　そのため、顧客が手間よりも利点を感じるものでないと、
ネットへの移行は厳しいと思います。
　アマゾンのような書籍の販売ですと、価格が安いだけでなく、
本屋へ行く手間、品切れの心配がないという利点があります。
旅行などの宿の予約も、安いだけでなく、旅行代理店へ行く手間が省けます。
ネットで予約さえすれば、あとは現地へ行くだけなので、
ネットに接続する手間よりも、ネットで予約する利点が大きいというわけです。

うちの会社の場合、ピザの配達に似ています。
ピザの配達の場合、電話で注文を受けてから物を配達します。
うちの会社も、お客さんからの注文があれば、運送便などで物を届けます。

　ピザの場合、ネット販売を始めましても、はたして利用する人はいるかと
なりますと、2割引きなどの大きな値引きをしない限り、利用者は少ないと思います。
ネットにつなげるよりも電話で注文した方が、お客さんにとっては楽だからです。
　この場合、お客さんの利点は値引き額になりますが、
うちの会社のように5％でしたら、あまり利点は感じられないでしょう。
　ピザのネット販売で、5％値引きの場合、3000円分購入しても、
値引き額は150円です。150円の値引き額でしたら、
電話を使う人が大半だと思います。
　そのため、お客さんが感じる別の利点を考える必要があると思います。

　上層部からは

　なるほど、その通りや

　という声になった。
　だが・・・

　これ以上、値引きできへんし・・・

　という声になり、最後には

　良い考えを出してくれ!

　になった。

　丸投げされても販売戦略とは無縁の私に良い考えなんてない。
　もし、そんなのがあれば・・・

　既に独立して大儲けしているのだ (^^)


  うちの会社のネット販売がダメな理由は、アマゾンとの決定的な違いだけではない。
  なぜなら、競合他社が成功しているからだ。
  そこで、競合他社と比較してみると、いくつか原因が見つかった。

  これら3つは頭の痛い問題だ。これら3点について考えてみた。

元々、お客さんは商品を知っているという前提だった。
そして、うちの会社のカタログを見ているとい前提もあった。
2000年の終わり頃は、私は、ほとんど営業事務を経験した事がなかった。
だから、お客さんの商品知識が、どの程度なのかを考慮していなかった。
2001年から、営業事務もやる事になり、注文の電話をとったりしていると
意外と、お客さんが商品がわかっていなかったりする。
もちろん、カタログなんか見ていない事も実感できる。

 5%引きは小さい。宿の予約など2割引きなどが当たり前だ。
私は最低、2割くらい値引きしないと、顧客は利点を感じないと思う。
だが、単純に値段を安くするわけにはいかない。
過去の売上データを使って、もし、これがネット販売の売上だと仮定して
値引き率を1割、2割にした場合の粗利の計算をすると、ゾッとしてきた。
これだと、値引きをしたら、うちの会社の利益がなくなる・・・。

安易な値引きの危険性については管理会計の話になります。
詳しくは「システム奮闘記:その33」をご覧ください。
(事務員が知らなかった経理の話)

メルマガの発行。営業マンがとても忙しくて時間がない。
商品関係の部署も忙しく、そんな余裕がない。
ネット販売は片手間で行なうものではなく、一人か二人でも良いから
ネット販売専任の担当者を置くぐらいでないと、ダメだと思う。

  さて、問題点と反省点を出てきたが、改善しないと前に進まない。
  常に試行錯誤した上、問題点を洗い出して改善する必要がある。

値引きが2割だと、粗利も2割少なくなるという錯覚に陥りやすい。
実は、粗利はもっと落ちている。
以前、ある同僚に「どうして、この商品を3割値引きすると
粗利が44%も減るねん、3割とちゃうんか」と聞かれ、説明したが、
なかなか納得してもらえなかった。
売値を下げても仕入単価が変らないため、粗利が減る割合が増大するという
ちょっとした数学の魔法なのだ。 

  しかし、これらの問題点を改善すべく、ネット販売システムを新しく構築したいが
この時、私には、時間に余裕がなかった。
  なぜなら、この時、事務仕事で忙殺されていたからだった。
  いきなり営業所の事務員が長期入院するわ、いきなりパートさんが辞めるわで
私のいる総務が代行するハメになり、総務部が大混乱に陥っていたからだった。

  そして、何もできないまま、年度末まで、ズルズルいってしまう。
  2003年3月に、ある役員から

　総務も何かに粗利を出すよう考えなさい!

　との、お達しが来た。
  通常の業務では粗利が稼げない総務。
  となれば、ネット販売で稼ぐ事しかないという方向になってくる。

　必然的に私の所へ

  ネット販売充実の案を考えるように!

　と言われる。
　そして役員から、改善案と今後の改善の日程表を出すようにと言われた。

  ついに、今まで考えた事を具体化する時期にやってきた。
  商品の画像や、商品の説明の充実。使いやすさに、見やすさ等々。
  どうやって商品説明を充実させるのか？  デザインはどうするのか？
  もちろん、誰が、どの部分を担当するのか？  問題は山積していた。
  これらの問題を解決していく必要がある。

  そして、技術的な事で、PHPLIBの導入を考えると、相当、時間がかかると思った。

いきなりPHPLIBと出ている。そこには根拠があるので説明します。
PHPLIBは、セッション管理が容易になるという事を知っていた。
シーラカンス本(正式名称:PostgreSQL完全攻略ガイド)に、
PHPLIBが認証管理できる事が書いてあった。
この時点で、認証管理ができ、ログイン、ログアウトができる事は知っていた。
その上、PHPLIBは、セッション管理が容易になるという事を知っていた。
そこで、PHPLIBを使えば、便利になると考えた。

ちなみに、認証管理を設ける理由だが、業界の事情があり、不特定多数の顧客に
販売ができないため、会員制にして特定の顧客のみの利用を考えている。

  構築に時間がかかると思った理由は、それだけでなかった。

　単に技術の習得の時間だけでなく、事務仕事を兼ねている上
突発的な事が起これば、そちらを優先しなければならないため
どうしてもシステムは後回しになる。

  そこで半年くらいかかると予想した。

私が提出した案

　外注せず、自社開発(つまり私が開発)という事になった。


外注の問題点

　余談ですが、外注について触れたいと思います。
　外注(アウトソーシング)が良いと叫ばれている風潮があります。
　しかし、安易な外注が良いのでしょうか?

　外注する場合、結構、手間がかかります。

　外注する事で社員の負担を軽減や、人件費削減が叫ばれているが
そんなに世の中、うまくはいかない。結構、時間と手間がかかる。

  業者から見積もりを取る必要がある。
  単に「＊＊システムを構築してくれ」では見積もりはでない。
まず、うちの社の業務体系に合った形でシステムを構築してもらうために、
業務の流れなどを外注先の人にわかるように説明する必要がある。
  何回か打ち合わせをしながら、ようやく見積もりが出てくる。

  見積もりを出す時は、数社による相見積もりにするのが原則なので、
見積もりを出してもらう全ての業者に説明していくため、結構、大変だ。

  見積もりを出す業者も、見積もりが出してくるまで、結構、時間がかかる。

  ようやく出たと思ったら、今度は、安く構築するために色々な手を使う。
  業者に揺さぶりをかける。「＊＊社さんの方が安いですわ」と言ったりして
値段交渉をしたりする。
  そうかと思うと、業者の方が競合他社の情報を聞き出そうとするため、
腹の探り合いになったりする。これも結構、時間を食う。

  忘れてはならないのは、出てきた見積もりを見て、精査する事！
  まともに技術的な面まで踏み込んでいくと、私が勉強する必要が出てくる。
  かなり労力が必要となる。そうなると、自分で開発できる場合は
自力でやった方が早いという場合もある。

  何回か外注の打ち合わせを経験しているが、ハッキリ言って疲れる・・・ (--;;

  中小企業の経営コンサルタントの多くは「アウトソ─シング」と言っているが、
本当に、外注にかかる手間とかを考えているのかと思う。

　外注先の能力を見極めるのに、知識が必要だったりします。
　値段だけで決める安易な外注には危険が潜んでいるからです。

外注を行う利点は、専門要員を抱えなくて良い点が挙げられます。
しかし、「あくまでも外注先がまとも」という前提条件が必要です。

「システム奮闘記:その6」のネット販売システム導入でも書きましたが
中小企業だという事で、見下した態度で、強引な提案をしたりする
ベンダーはいます。中小企業を騙して儲ける企業も結構ある事を聞きます。
外注が良いのは、外注先が、まともな企業である事です。
それを忘れて、外注先に任せれば安心というのは損するだけでなく
技術力が低い所ですと、システム障害が頻発したり、データが消去などで
会社の信用にも関わってくるため、外注を行うには注意が必要です。

　自社開発
  ここで私の人件費という声が出てくるが、私はこう反論します。

　だって、安月給だもーん (TT)

　外注するより、私の人件費の方が安い。
  安月給だから「Linux好き事務員」が存在できる。喜ぶべきか悲しむべきか (TT)

　システム奮闘記で、自社開発を行なったりしているため、
私が外注を否定しているように、思われる方がおられるかもしれませんが、
否定はしていません。必要な場合は、外注の活用を考えています。
　現にAS400のメンテナンスは外注しています。

　ただ、外注を避けたいのは、目先の費用削減が目的だけでなく、
相見積もりをとったり各業者が提出した案などを理解した上で、
検討したりする作業を考えると、結構、手間がかかったりする。
　中には、いい加減な業者がいるため、目を光らせるとなると、しんどい。

　それだったら、自分で構築した方が早いし、実践で得られた知識も身に付くので
自力でできる範囲だと、どんどん自社開発している。

　外注で一番楽なので、Linux関係などで知り合った方に頼む事なのだが、
相見積もりでダメだった時の、ご足労を考えたり、無理な要求などをして
迷惑をかけて、それが原因で、疎遠になるのは、極力さけたいと考えている。
  Linux関係などで知り合った方に依頼できないという矛盾に陥っている。

　外注は否定する気はありません。
　つまり必要に応じて上手に外注業者を活用すれば良いのです。


なかなか着手できない状態


  半年ぐらい余裕を見れば大丈夫だろうと思っていたが、運悪く、予想は的中した。
  4月に大きな人事異動が行なわれ、事務処理で、てんてこ舞い。

  5月には、外的要因から、その処理に追われて全く身動きがとれない。
  とても、ネット販売システム改装には着手できない。

  役員から

　菅ちゃん、経過はどうや?

　と聞かれるのだが・・・

　優先事項の処理に追われて、手が出せません!!

　と返答せざる得なかった。
  役員も、わかっていたので、苦笑いしていた  (^^;;


　なんとか落ち着いた。でも、9月になった (--;;
　そろそろ取り掛からないとマズイなぁと思い、ネット販売システムに着手した。

ネット販売システムに着手。PHPLIBを活用

  さて、PHPLIBの導入。問題なのは、少なくとも私の知っている範囲では、
わかりやすい解説書がなかった。
  そのため、PHPLIBの設定ファイルなどを解読する必要がある。

  実は、PHPLIB導入に挑戦したのは、今回が始めてではなかった。
  2002年の秋ぐらいに挑戦しようとした。

  その時は、PHPLIBがどんな物か知るために、シーラカンス本に付属している
ソフト「pgimage」をインストールして、稼働させようとしたが

　エラ─が出て動かへん (TT)

  だった。その時は、必要に迫られていなかったので、あっさりと導入を断念した。

  どういうエラーが出たのか、覚えてなかったが、一度、失敗しているだけに、
トラウマ(?)があり、付属ソフトを解読する気が起らなかった。

  そのため、PHPLIBを知るには、どこを手がかりにすれば良いのかわからなかった(--;
  もちろん、シーラカンス本を見ても、説明が詳しく書いていないため、

　だから何やねん???

  という感じだった。
  まして、セッション管理が容易になるというが、具体的にどうすれば良いのか
全くわからない。

  でも、ここは落ち着いて、googleで、PHPLIBの事を調べてみる事にした。
  いくつか引っ掛かったので、早速、見てみる事にした。

  最初に見たホームページに書いてあったのは、セッション管理の話ではなかった。
  でも、PHPLIBの設定方法が簡単に書いてあったので、真似をしてみた。

  まず、phplib-7.2d.tar.gzを展開した。

  そして、展開した中に、phpのディレクトリーのprepend.php3ファイルがある。

_PHPLIB["libdir"] = "（prepend.php3のあるディレクトリ：絶対パス）"; 

require($_PHPLIB["libdir"] . "db_pgsql.inc");  /* Change this to match your database. */
require($_PHPLIB["libdir"] . "ct_sql.inc");    /* Change this to match your data storage container */
require($_PHPLIB["libdir"] . "session.inc");   /* Required for everything below.      */
require($_PHPLIB["libdir"] . "auth.inc");      /* Disable this, if you are not using authentication. */

  しかし、Webには次のように書いていた。
  「実は、セッション管理を利用したことがないんです・・・」  
  Webの作成者の方は、セッション管理ではなく、データベースに依存しない
移植性の高いスクリプトが書くために、PHPLIBを導入されたため、
セッション管理については、一切触れていなかった。

  でも、PHPLIBの設定方法がわかっただけでも大きな情報。
  それに、私が「セッション管理も載せるべし！」などと言えない。
  ボランティアでやっておられる方に、無理な要求など、できやしないからだ。

  逆の立場になったら、よくわかる。私に対して無理難題を言う人がいたら、
「そこまでできるか！」となるから (^^;;

  さて、PHP言語を使って、データベースを呼び出す時に、それぞれのデータベースに
合わせた命令を持っている。

  それぞれ固有の関数を持っている。
  しかし、PHPLIBを使えば、次の1行で統一される。

　$db->query("SQL文")

上の1行の前に

$db = new DB_Example

というようにデータベースの定義が必要。
データベースの定義などについては、後述しています。

  データベースに依存しない関数や命令。これは便利だと感心してしまった。

  さて、このWebの情報でわかったのは、セション管理ではなく、PHPLIBを使えば
データベースに依存しない命令が使える事だった。
  これだとデータベースを変更する時に、プログラムまで変更する事がなくなる。

  さて、どんな物かという事で、早速、Webの説明書き通りに、
local.incのファイルを次のように書き換えた。

class DB_Example extends DB_Sql {
  var $Host     = "サーバーのIP、又はホスト名";
  var $Database = "データベース名";
  var $User     = "データベースのユーザー名";
  var $Password = "";
}

  そして、Webに書いてあったスクリプトを、ちょっとだけ書き換えて
動かしてみる事にした。

<?php
include("php/prepend.php3");
$db = new DB_Exanple ;
?>

<HTML>
<HEAD><TITLE></TITLE></HEAD>
<BODY>
<?php
   $table_name = "テーブル名";
   $sql = "SELECT * FROM $table_name";
   $db->query($sql);
   while ( $db->next_record())
         {
         echo $db->f(1);
         }
?>
</BODY></HTML>

  Webに書いてあった通り、テーブルの1行目のデータが表示された！

　見事成功 V(^^)V

  後でわかった事だが、実は、この時、ある意味で「たまたま成功」したのだった。
  それはデータベースの定義（$db = new DB_Exanple ;）だった。
  local.incのデータベースのクラス定義で、初期設定だとDB_Exanpleになっている。
  それ以外のセッション管理などのクラス定義の記述でもExanple_***になっている。

  しかし、この時は、そんな事を知る由もなかった。
  もちろん「クラス」が何かも知らなかった (^^;;
  詳しくは後述しています。

  Webの最後の部分に書いてある利点(制作者の方の持論)を読み返した。

　その1と、その3について具体的にどういう事なのかを
まとめてみると、以下のようになります。

　PHPLIBのテストスクリプトを見ると、データベースへ接続のための関数に
サーバー名やデータベース名を書いていない。
　普通のPHPの記述(PostgreSQLの場合)なら

　pg_connect("dbname=データベース名");

　のように接続先のデータベースを書く必要がある。
スクリプトのあるマシンと、データベースサーバーが違えば
ホスト名も定義する必要がある。
  データベースの接続先が変更になると、PHPLIBを使わない場合だと、
全てのスクリプトを変更しないといけないが、PHPLIBを使うと、
local.incの変更だけなので、変更の手間が楽になる。

　次に「その3」について。

　PHPLIBのテストスクリプトを見ると、データベースへの接続・切断処理がない。
  普通のPHPの記述(PostgreSQLの場合)なら

　pg_connect("dbname=データベース名");

　でデータベースへの接続処理を行なったり

　pg_close(接続ID);

　という切断処理を行なっている。
  SQL文を実行させる度に、接続・切断処理を行なっている。
  その必要性がなくなるとなれば、ソースコードを書く量が減る。

  この3点を読み返して、セッション管理に使わなくても、PHPLIBを使うだけの
利点があるのだなぁと思った。


クラス、オクジェクト指向を知らずにPHPのプログラム

  さて、PHPLIBを使うと、コード量が少なくなったり、違うデータベースへの
変更が容易になる事がわかったのだが、肝心のセッション管理については
まだ、何もわかっていなかった。

　ところで、なぜPHP3で動くPHPLIBにこだわったのか。
　この時、既にセッション管理ができるPHP4を使わなかったのか。
　それは以下の事があったからだ。

当時、PHP3とPHP4が共存できる事を全く知らなかった私。
そのためPHP4を導入するには、PHP4への書き換えが必要だと思い込んでいた。

この時、PHP3で動くプログラムがいくつかあった上、
PHP3で動く携帯3社の振り分けソフト(JHP)を稼働させるため
PHP3が必要だった。
携帯3社の振り分けについては「システム奮闘記:その10」の
携帯3社コンテンツ作成物語をご覧下さい。

PHP3とPHP4との共存が可能である事を知らなかった上、
PHP4へ書き換えるだけの実力は全くないため
PHP3で動くPHPLIBにこだわっていたのだ。

  さて、PHPLIBでのセッション管理をする方法。
  ふりだしに戻ってしまったので、再度、シーラカンス本を見てみる事にした。
  PHPLIBを使ってセッション管理を行なうのかを調べる手がかりを探す事にした。

  まずは、付属のソフトについているpgimage_local.incから見てみる事にした。
  ちなみに、pgimage_local.incは、デフォルトのファイルはlocal.incファイルです。

PHPのクラスって何?

  ソースコードを見てみると、classという文字が使われている。

　クラスって何やねん?

  最初で、つまずいてしまった (^^;;
  そこで登場するのは、PHP言語の辞書的存在の「マンモス本」
(正式名称:PHP4徹底攻略)のP60を開けて、クラスとは何かを見てみた。

  本には次のように書いていた。
  変数と、それに付随する固有の手続きをカプセル化したものをクラスと呼びます。

  この文面を見て

　だから何やねん?

  だった (^^;;
  
  そこで、本に載っている参考ソースを使って、実際に目で確かめる事にした。

  どうやら、関数の詰め合わせの感じがする。

class foo {
      $var kazu ;  ← （変数の定義）

      function  kansuu {  ← （関数の定義）
                printf("なんでもええから表示する");
                }
}

class foo {
      $var kazu ;  ← （変数の宣言）

      function  kansuu {  ← （関数の定義）
                }
                printf("なんでもええから表示する");
}

　そして、クラス内だが、関数の外で定義された変数を、
定義関数の中で使う場合、以下のような使い方をする。

class foo {
      $var kazu ;  ← （変数の宣言）

      function  kansuu {  ← （関数の定義）
                $this->kazu = 10 ;
                printf("なんでもええから表示する");
                }
}

  関数の外の変数と中の変数。
  なんだか、C言語に出てくる、グローバル変数と、ローカル変数を思い出す。
  C言語の場合は、接頭辞みたいな物をつけなかったが、PHPでは
接頭辞みたいな物を付ける必要なのかと思った。 

  クラスを定義で便利な使い方が出ていた。
  あるクラスの定義を利用して、拡張したい場合があるとする。 
  その場合、下のような方法を使う。

class  kakucho  extends motomoto {
       function {
       printf("拡張やで \n");
       }
}

  何度も同じ定義をせずに済むので楽かもしれない (^^)

PHPのクラスの概念を理解したと思い込んでいたのだが
実は、クラスの使い方を知っただけで、どういう物かは
理解していなかった。

数学で例えると、公式の持つ意味を理解しないまま
例外があると、公式丸暗記、当てはめ型で解答するという方法だ。

実際に、PHPのクラスの理解をせざる得ない状況になったのは
2006年、Pukiwikiのプログラムを解読する時だった。
詳しくは「システム奮闘記:その52」の
「PukiwikiでCMS。手軽にホームページ作成・更新」をご覧下さい。

　クラスの事がわかった気になった私。

セッション管理を調べる

　次に、肝心のセッション管理を理解すべく、検索サイトで調べる事にした。
　すると、PHPLIBのセッション管理を応用したソフト

　pgCalendarを発見!

  pgCalendarとは、スケジュール管理ソフトで

　PostgreSQL + PHP3 + PHPLIB

　で動くソフトだ。
  このサイトには「詳しい事は、SoftwareDesign2000年6月号を参照」
と書いていた。
  
　もしかして、持っているかもと思いつつ、会社の本棚を調べてみると
案の定、SoftwareDesign2000年6月号が見つかった (^^;;

　パラパラとめくっていくと

　ほとんど読んでいない!

　というのがわかった (^^;;

　情報を得るために買ったが、読めるだけの実力がないため
そのまま放置されていたのが、バレバレだった。


  さて、pgCalendarの記事を読む事にした。
  しかし、PHPLIBの中身を触っていないだけに・・・

　読んでも、わからへん (TT)

　なので、根性でソースを解読していくしかないと考え、
pgCalendarが、どんな動きをするソフトなのか見ながら
ソースの解読を考えた。
  早速、動かしてみるが・・・

　エラーが出る (TT)

  だった。

  原因は、local.incのような設定ファイルの中で、
別のファイルを読みに行く際に、相対パスや絶対パスの指定が、
動作する環境と、合致していなかったからだった。
  しらみつぶしに、エラーを出しては、指定のディレクトリーを変更していき
なんとかエラーがでないようにした。


  そして、ようやく動作を見ながら、pgCalendarのソースを解読していく事になった。
  まずは設定ファイルlocal.incを改良したcal_local.incのファイルを見ていく事にした。

  pgCalendarの場合、いきなりログイン画面が出てくる。
  index.php3ファイルには、ログイン画面の表示する命令は見られない。
  そこで、それらしき物を探すと、cal_local.incの内で、cal_loginform.ihtmlという
ログイン表示の画面の設定（HTML形式での記述）ファイルを見つける。
  そこでに、$challengeという変数があるのを発見する。

  この変数。ログインの画面を出す度に、違う変数となって現れる。
  cal_local.incで、どういう風に、この変数を出しているのか見てみると

　$challenge = md5(uniqid($this->magic))

  md5関数や、uniqid関数って、どんな関数なんやろかと思った。

変数 $this->magicなのだが、ソースコードを読むと
var $magic = "FACTORY";  ## Challenge seed
となっている。
つまり$this->magicの変数の中身は"FACTORY"の文字列と定義されている。

  まず、マンモス本でuniqid(文字列)という関数を調べてみた。
  この関数は「入力した文字列の後ろに、ミリ秒まで表示した現在時刻の数字が
くっついてくる物」が出てくる。

  そして、md5(文字列)の関数を調べてみると

　入力した文字列のmd5ハッシュ値

　という暗号化した文字列が出てくる。

  これから言えるのは、ミリ秒単位まで表示された時間を使って、
暗号化した物を変数として使っている事になる。
  すなわち、余程の事がない限り、重複が起り得ない変数を出す方法だ。

  ふと思った。
  なぜ、$challengeという変数を追加しているのかが謎だ。

MD5は不可逆暗号（ハッシュ関数）として、電子指紋に利用されている技術だ。
IPSecは、パケット認証を行なう。その時のハッシュ関数として、
MD5かSHA1が使われる。
時間のデータをハッシュ関数に入れているのだが、ミリ秒単位のデータなので、
それ自体に、重複など考えにくい。もし、重複があれば、後ろに同じ文字列を
追加しても無意味になるはずだ。そのため、謎としか思えない・・・ (^^;;

  さて、ハッシュ関数を上手に活用すると、個別の接続の認識ができる。
  もちろん、同じ人からの接続でも、接続時間の違いの認識が可能になる。
  この時は「へぇ〜」という感じだったが、後に、無くてはならない物になってくる。

肝心のPHPLIBのセッション管理について

  PHPLIBを使った、PHPのスクリプトの先頭には、こんな呪文がある。

page_open(array("sess"=>"Cal_Session",
                "auth"=>"Cal_Challenge_Auth",
	        "perm"=>"Cal_Perm"));

  ここで、2つの関数が出てくる。array関数と、page_open関数だ。
  まず、着目したのはarray関数だ。そこで、マンモス本を調べてみた。

$a = array(3,5,8) ; とすると
$a[0] = 3  $a[1] = 5  $a[2] = 8 という意味になる。
配列に変数を代入する感じ。

　配列の並びは数字だけでなく、文字列でも可能になる。
　そのため

　$a = array("a"=>"鉄郎" , "b"=>"メ─テル" , "c"=>"車掌" );

　とすると

　$a[a] = "鉄郎"   $a[b] = "メ─テル"    $a[c] = "車掌"

　という意味になる。

  つまり上で出てきたpage_open関数で見てみると

  page_open(array("sess"=>"Cal_Session",
	          "auth"=>"Cal_Challenge_Auth",
		  "perm"=>"Cal_Perm"));

の場合、page_open関数に渡す変数で
配列の要素が"sess"の場合は、"Cal_Session"という文字列が入り
配列の要素が"auth"の場合は、"Cal_Challenge_Auth"という文字列が入り
配列の要素が"perm"の場合は、"Cal_Perm"という文字列が入る。

  さて、array関数を知った所、次に、page_open関数を調べる必要がある。
  マンモス本で調べたが、載っていなかったので、PHPLIB独自の関数だとわかった。

  設定ファイルを調べることにしたら、見つかった。
  page.incというファイルに、page_open関数が定義されていた。

  page_open関数の定義の中身を見てみる事にした。
  が、つまずいた。

　isset()関数って何?

  そこで、マンモス本を開いて調べてみた。

  これで、少しpage_open関数の定義の中身が見やすくなった。

  # enable sess and all dependent features.
  if (isset($feature["sess"])) {
    global $sess;
    $sess = new $feature["sess"];
    $sess->start();
    
    # the auth feature depends on sess
    if (isset($feature["auth"])) {
      global $auth;
      
      if (!isset($auth)) {
        $auth = new $feature["auth"];
      }
      $auth->start();

      # the perm feature depends on auth and sess
      if (isset($feature["perm"])) {
        global $perm;
        
        if (!isset($perm)) {
          $perm = new $feature["perm"];
        }
      }

もし、isset()関数で変数に格納されていない場合
初期値を入れる必要がいる事がわかる。

そこで変数に値が格納されていない場合は
初期値を入れる処理が行われているのだ。

  ここで、isset関数が出てくる理由がわかった。
  先ほども触れましたが、PHPLIBを使う際、PHPスクリプトの先頭には、
呪文を唱える必要がある。

page_open(array("sess"=>"Cal_Session",
                "auth"=>"Cal_Challenge_Auth",
	        "perm"=>"Cal_Perm"));

  配列の中の3つの要素「sess」、「auth」、「perm」を
宣言しているのだが、別に無理に3つの宣言を行う必要はない。

  もし、ユーザー認証をする必要がなければ、authを外しても問題はない。
  そのため、必要な物だけ使えば良いのだ。

  ちなみに、ソースを見れば、authを外すと、自動的にpermも外れる事がわかる。
  ユーザー認証の必要がなければ、ユーザー権限の制御も無意味になるからだと思う。

  さて、isset関数で、それぞれの役目が定義されているか、どうかをチェックしている。

  そして、定義されていたら、$sess->start();を使って関数を呼び出している。
  つまり、定義された部分の処理を行なっている。

  さて、次に、私は、$auth->start();に着目した。
特に、これを選んだ理由はないが、なんとかく重要そうに思えたからだ。

  そこで、auth.incのソースを見てみることにした。

  function logout($nobody = "") {
    global $sess;
    
    $sess->unregister("auth");
    unset($this->auth["uname"]);
    $this->unauth($nobody == "" ? $this->nobody : $nobody);
  }

  まさに「へぇ〜」と思いながら、ソースを解読（単なる拾い読み）をしていた。


  四苦八苦しながらも、以下の事だけは、わかった。

  お客さんがログインした場合、毎回、違う物を購入するため、
ログインしている時間の違いを認識できる情報が欲しい。
  しかし、セッション情報を引き出す関数が見つからない (TT)

　実は、この時、PHPLIBにセッションIDの有無だけでなく
セッションIDそのもの存在を知らなかった。

　だが、知恵は働く物で、認証画面に時間の関数にMD5関数を入れた結果を
隠れタグに埋め込んだ。
　それをセッションIDの役目とさせて、情報を受け渡しするような仕組みを作って、
その時ごとのログインの違いを認識できるようにした (^^;;


　もがき苦しんだ私なのだが、結局、セッション管理の事が
よくわからないまま、PHPLIBの表面的な扱い方しかわからなかった。

　セッション管理について詳しくは「システム奮闘記:その62」
(クッキー、セッション管理とは何か)をご覧ください。

ネット販売の画面の構成

  さて、肝心のホームページの構成は次のように考えた。

ネット販売の画面の構成

  商品の画像は、PostgreSQLのラージオブジェクトに格納する方向で考えた。
  理由は、商品データを格納するテーブルに、OIDも記録しておけば、
紐づけができるから便利と考えた。

  ところが問題点が出てきた。
  一枚だけ取り出すのは、簡単だが、同じカテゴリーに何種類か商品がある。
そのため、下図のように何枚か連続して写真を掲載する必要がある。

ネット販売の画面に画像を並べたい

　画像を載せる時のHTMLタグは

　<IMG SRC="picture-file">

　なので、通常の場合は<img>タグを並べれば良いのだが、
ラージオブジェクトに入っているデータを取り出す場合は、そのタグは使えない。

  そこで、以下のようなプログラムで出力させる必要がある。

<?php

      $dbcon = pg_connect("dbname=DB名");

      $sql = "SELECT * FROM テーブル名 WHERE 条件";
      $execid = pg_exec($dbcon,$sql);

      @$chec = pg_fetch_object($execid,0);

      header("Content-disposition: inline; filename=\"ファイル名\"");
      header("Content-type: 画像ファイルのタイプ");

      $oid = $chec->oid ; ←　DBに記録しているOIDを変数に代入  
      pg_close($dbcon);

      i18n_http_output("pass");

      $dbcon = pg_connect("dbname=DB名");
      $execid = pg_exec($dbcon,"BEGIN");
      $obj = pg_loopen($dbcon,$oid,"r");
      pg_loreadall($obj);  ←　画像を出力

      pg_loclose($obj);

      $execid = pg_exec($dbcon,"COMMIT");

      pg_close($dbcon);

?>

  という感じで手間がかかる。
  ここは普通にWhile文のようなループを作って、連続的に画像の出力をやってみた。

ループを作って連続的に画像を出力させようとした

　結果は、アカンかった (TT)

  どうやって画像を連続させて出すのか、わからない。
  マンモス本の例には、ラージオブジェクトに格納した複数の画像データを
取り出す部分がある事に気づく。そこで、ソースを見る事にした。
  そうすると、なんと

　<IMG SRC="XXX.php3">

　という記述を使っている。
　リンク先をファイル名ではなく、PHPのスクリプトなのだ。

  こんな技は思いつかない・・・ (--;;

  そこで、次のようなループで画像を複数、連続して出す事にしてみた。

ループを作って連続的に画像を出力させようとした
pic.php3は、上に書きました画像を出力するプログラム

　結果は、成功だった！！  (^^)V

  これで、また一歩前に進む。


意外とある綴り誤り(入力誤り)

  高度な技(?)を身につけるために、四苦八苦した部分だけでなく、
「そんなアホな・・・」という簡単な間違いで、ドツボにハマった事もある。

  <FORM>のタグを使う部分で、簡単な綴り間違いで<FROM>と書いてしまい、
ホームページの表示がグチャグチャになってしまった。
  意外と綴り間違いは気づかない上、単純なミスなだけに、見つけにくい。
  このような綴り間違いのために、原因究明に、かなりの時間を潰してしまった事も
何度となくあった (--;;


システム運用面での使い勝手も忘れてはならない。


  誰でも簡単に商品の差し換えや値段設定の変更ができないと、
運用面での手間の改善にはならない。

  この時、動いていたネット販売システムは、商品の追加や変更の場合、
私がLinux上のファイルの書き換えを行なっていた。
  つまり私がいないと、誰も追加・変更ができない状態だった。

  そこで、新規のネット販売システムは、Web上で社内の人間なら
誰でも簡単に商品の追加・変更ができるように、メンテナンス画面も作成した。



商品の掲載作業。商品知識を身につけていく

  2003年9月30日、七転八転の末、ネット販売システムの原型が完成した。

  早速、社内にデモ画面を作成した事を伝えた。

　商品関連の部長から以下の注文がやってきた。

　基本は合格。でも、これから発展させないとダメ!

  社内向けシステムなら「別に、細かい事は、ええやん」となるが、
ネット販売を成功させるには、徹底的にやらねばならない。

　ネット販売を早く開始を考えている役員と次の会話になった。

商品の説明を充実させて、品数をある程度載せて
お客さんが魅力を感じないと寄りつかないでしょう。
ネットの場合、一度、お客さんにダメと判断されると
その後は使ってくれないため、最初が肝心です。

  役員は納得してくれた。


  デザイン、内容、商品の並びなど、ネット大好きな商品関係の部長と
二人三脚が始まった。
  部長の助言を元に、商品の掲載や説明などを私が具体化していく事になった。


  さて、部長に「どんな感じでデザインすれば、良いですか？」と聞いてみた。
  部長が、いくつかの通販のサイトを開いて

　これくらいやってもらわんと

　お客さんは、こんけん(来ない）

　と言った。
　そして部長が通販のサイトを開いた。

  そして、部長がニヤニヤしながら

　菅ちゃんの好きな項目を見せてあげる

　と言って、女性用下着コーナーの所を開いた。
  私は

　部長、おねーちゃんの下着姿なら見たいですが、下着だけだとねぇ

　と言った。
　部長は

　お気に召さないのは残念

　と言った。

この問題、よく考えると不思議だと思う。
ヌードを見る場合、本能的に脳ミソがアドレナリンを分泌。
そのため、男はエロエロになってしまう。
しかし、下着姿を見てエロエロになるのは説明がつかない。
水着姿を見ても何ともないのに、下着姿だとエロエロになる。
考えれば不思議な問題だけに、この謎を誰か解明してくれないかなぁと思う。

女性下着の通販は、大抵、金髪の外国人女性がモデルになっている。
なぜか金髪の女性がモデルだと、エロさは感じない。
もし、モデルが日本人女性だったら、スケベ目になった男が
通販のパンフレットを、エロ本代わりにして見ると思う。
外人がモデルだとエロさがなくなる理由。これも解明して欲しいと思う。

  このネタを引きづると、私はエロオヤジになってしまう（既に、なっとる）ので、
ここで止めて、話を元に戻します。


  さすがは通販のサイト。デザインのプロがいる。
　私は、役員や商品関係の部長に対して

　他社の通販みたいに綺麗にするにはプロが必要です!

　と言った。

　しかし、デザインやネット販売の専門家の採用は
行わなかった。

　私は部長に対して次の事を言った。

　素人だけでネット販売を行い、利益を出せる程、甘くはない。
　この状況で、どう進めていくのか、悩んでしまう。


  デザインを、どうするのか。非常に困った。
  なにせ、デザインセンスが究極的にない私。
  うちの会社の最初のホームページを作成した時も、ボロカスに言われただけある。
  詳しくは「システム奮闘記：その4」(ホームページ公開)をご覧ください。


  「弱ったなぁ」と思っていたら、ふと、思いついた。
  最初の画面は、次のような文字を入れたら良いではないか。

こんな風な看板にしました

  「ロゴだよ〜」は試作品だが、この試作品を何人かに見せると

　かわいらしい感じですね

　優しい感じがする

　と言ってくれた。
  私は「もしかして、かわいい系のデザインでいけば、私でも制作は可能かも」
と思った。

  ネット通販のホームページ。デザインは洗練されていたり、格好良かったりする。
  とても素人には、そんなデザインなどできるわけがない。
  ましてや、究極的に芸術的センスがない私。


  しかし、かわいい系の画像を載せる事によって、デザインセンスの無さなどを
補間できるのではないかと考えた。

  デザインは、かわいい系でいく！

  かわいい系と親しみやすい系のデザインという方針が決まった。
  そして、商品に関連する絵を付けたり、説明書きの所に図を入れたりした。

  かわいい系と親しみやすい系のデザイン。無難な路線だと思った。

商品の展示と説明を作成

  商品の写真の掲載と商品の説明について。

  商品知識に疎い総務の私。しかし、商品説明など内容を作るのは私だけなので、
デジカメを持って商品を置いている倉庫に入って、商品をデジカメで撮影する一方で
商品を手に取ったり、定規で大きさや長さを測ったりした。

　商品に詳しい部署の人たちに

　これ、何に使うのですか?

　どうして、そんな使い方をするのですか?

　などと根掘り葉掘り聞く事になった。
  もちろん、ネット販売システムは、売上に関係するため協力的だった。

  どこまで詳しく商品説明をするのかが問題になる。そこで、考えた。

  お客さんの商品知識は私と同じと考える！

  実際、全てのお客さんが商品に詳しいわけではない。
  私と同様、ほとんど知らない人もいる。（ホントの話）
  私が読んで理解できる内容なら、全てのお客さんが読んで理解できると考えた。
  そこで、自分が「わからん」と思った事を、商品説明に反映させた。

  商品そのもの以外にも、商品の使い方を実践している所を、デジカメ撮影しては、
gimpを使って画像処理した。1つの商品の説明のために、半日費やした事もあった。

  でも、そこまで本気になってやらないと、部長の合格はもらえない。
  倉庫へ行っては、商品を1つ1つ手に取って見たり、定規で長さを測ったり、
撮影したりする毎日になった。

  毎日、商品に触れていたら、嫌でも商品に詳しくなる。

  ある日、注文の電話をとった。今までなら、お客さんに突っ込んだ質問をされると
わからないため、「詳しい者に変わりますので」と言って逃げていた。
  しかし、わかるようになった商品なので、問題なく、お客さんの質問に対応できた。
  我ながら「詳しくなったなぁ」と感心してしまった。


  さて、商品をデジカメで撮影。

  撮影方法を工夫する必要があった。

  最初、屋内で撮影していたが、金属製の商品などは蛍光灯の明かりが反射して
写りが悪くなる。
  そこで、均等に光が当たるように、屋外で行なう事にした。

  商品の写真の背景の色。
　最初は「gimpがあるから、どこでもええや」と思って撮影していたが
背景色と商品の色が似ていたら、gimpでは画像処理できない部分があったり、
金属製の商品だと背景の色が写ったりする。
  そこで、白い段ボールの上に、白い紙を敷いて撮影した。

  画像加工。最初はgimpを使って、綺麗にできなかった部分をWindowsの
おまけソフト(Windowsの付属のペイント)で処理していた。
  しかし、ペイントを使って画像を拡大表示させて、処理した方が早い。
  そのため

　ペイントが便利な画像処理ソフトになった!

  説明書き。もちろん文章だけでは伝わらないので、大きな、長さ以外にも、
用途や、実際に使っているシーンなどを撮影して、説明に加える。

  説明書きを見て注文をつける外野もいる。
  普段なら「あんたが参入すると話が引っ掻き回されるから、やめてくれ」となるが、
この時ばかりは外野の意見も助かる。

  別の視点で見てくれるため、私が気が付かなかった点を指摘してくれる。
  「これは、ええかも」と思って加えたりした。
  簡単な図を書き、画像処理、説明書き。なんだか事務員でもなければ、
技術者でもない。ヘボWebデザイナーになった感じがする。

  いかに、少ない図や文章で、わかりやすく商品説明を作るか。
  意外と労力が必要。そのため、自宅に帰ると疲れきっているためか
奮闘記の原稿を書く気がなくなっている日も多々あり (^^;;


  毎日のように倉庫へ行って、商品を調べたり撮影したりすると、
配送関係の人の苦労がわかる。
　夏は熱いし、冬は寒い。冷房・暖房の無い所で働くのだから
大変だと肌で感じる。

　12月になると寒くなる。厚着をして倉庫へ行く。鼻水が出てきそうになる。
  以前は、寒さに強かった私だが、30才になると、結構、弱くなっている。

  毎日、寒い中、倉庫へ通いつめた。
  とにかく倉庫は寒い。太陽が当らないだけに、冷えきっている。
  風邪だけは、ひかないようにと心掛けた。

  ついに、年が明けた。2004年になった。
  しかし、1月は、別の仕事が流れ込み、ほとんど作業ができず (TT)

  そして、２月になり、倉庫通いを再開した。黙々と商品登録するだけだった。

消費税の扱い

  3月1日、全ての商品の登録が終わった。
  つまり完成したのだった！！  

  本社の全部署へ、ネット販売システムの完成を知らせるメールを出した。
  「上手にできている」とか「わかりやすいねぇ」という声があった。
  膨大な時間と労力をつぎ込んだ甲斐があった。

  さて、4月から開始。
  ここまま勢い良く開始と思いきや、問題は価格の表示が発生した。

  2004年4月から消費税法の改正で価格の表示は税込みとなる。
  今までのネット販売の価格は税抜き価格だ。
  ネット販売の場合、税込みの価格にしないといけないため、
計算する部分を追加して、税込み価格と、税部分の表示をした。

消費税計算の扱いは、意外と面倒だ。
まず、110円の商品の場合、消費税は5.5円なので、0.5という端数が出る。
この場合、端数切り捨てか、切り上げか、四捨五入にするかは
税法では規定はなく、事業者の裁量で決められる。
 
なので、取引先とのやりとりで、相手側との消費税計算方法の際で
1円、2円の入金差異が生じたりする。
これを伝票処理するのだから手間がかかる。

消費税法改正のため、消費税込みの価格を表示しないといけなくなる。
私は、この改正を「改悪」だと断言する!

表向きは消費者にわかりやすくというが、実態は消費税を見にくくする
国の策略以外の何物でもない。
要するに、消費税率を上げても、直接、消費者が感じにくくする効果を狙っている。
これだと、消費税が10%になっても、「重税」という感覚がなくなる。
国家的詐欺というのか、犯罪というのか。

そもそもの財源不足は、政治家と高級官僚が無駄な金をばらまいた結果だ。
血税を無駄使いしておきながら、そのツケを国民に回すのは、非常に、腹立たしい！

  消費税問題は簡単に片付いた。
  そして、新しいネット販売システムが開始した。
  これから、どうなるの楽しみだ。

完成したネット販売システムの画面

　ついに2004年4月にネット販売システム・第二弾の稼働になった。

　どんな物かを公開できる範囲で紹介します。

ネット販売システムの最初の画面
IDとパスワードの認証画面が出てくる。

　ログインをすると以下の画面になる。

ログインした時の画面
左側のメニュー画面には商品の種類別の選択肢がある。 右側は「いらっしゃいませ」の文字を入れている。 あるネット販売の講習で「顧客名を表示させる事が重要だ」 という話を聞いて、それを反映させた。

　そして、左側のメニューにある商品の種類を選択すると
その種類の商品一覧が出てくる。

商品一覧の表示画面
青く塗りつぶしたのは商品の画像部分と簡単な説明が書いている。 その下には商品別の価格などの明細が出てくる。 より詳細を見たい場合は「備考」ボタンを押せば良い。

　「備考」のボタンを押すと以下の画面が出てくる。

より詳しい商品の説明
黒く塗りつぶしたのは、商品の写真と詳細な説明だ。 これによって、購入する側に商品の情報が伝わる。 この部分は、JavaScriptを使った。

　商品を買い物かごに入れてレジで清算する画面。

レジで清算の画面
この段階では商品の変更や個数の変更が可能にしている。

　そして清算画面を押すと、発送先の記入欄が出てくる。

商品の発送先の記入欄
顧客情報と異なる発送先の場合、発送先を入力できるようにしている。

　2001年5月に稼働したネット販売システム第1弾は
商品の説明や写真がなかっただけに、顧客にとって、わかりやすい物に
なったと思う。


これで終わらない。ネット販売システムの話

　第2弾ができて、半永久的に使えるのかなぁと思いきや
稼働している間にも、色々な問題点も出てきた。

　そこで2007年に第3弾に着手する事になった。
　詳しくは「システム奮闘記:その65」をご覧下さい。
　EC-CUBEでネット販売システム構築

まとめ

  長い期間を経て、なんとか導入にこぎつけた案件だった。
  いかに顧客に魅力を持ってもらうかが重要になってきます。
  そして、安易に価格を下げる事、利益を少なくするだけなので、
自分のクビを絞める結果になってしまう。

  それと同時に、うちの会社の手間も省いていく方向も考えなくてはならない。
  売上が良くても、手間が多いと人間を雇う必要が出てくる可能性もあるため、
人件費の問題が出てくる。

  顧客も売り手も満足できる事を可能にしてくれる方法の1つがITだと思う。
しかし、まだ、ITの世界で、最適解を探している状態だ。
  これからも最適解を探しつづけるため、試行錯誤が続きそうな感じです (^^;;