必要条件 十分条件

小難しいタイトルにしましたが、実は中身は少し違います。

たまに、
・これを読めば年収アップ
・起業にはこの知識が必須
とか、そういう怪しげな広告を見かける。

それぞれ、補足しなくてはなるまい。
・これを読めば年収アップしたらいいよね
・起業にはこの知識が必須のこともあるよね
くらいにしないと。

サラリーマンの場合。給料を決めるのは会社、上司。なら、何か本読んで知識つけたところで、仕事に活用して認められて、うんと昇進でもしなければ年収なんてそうそうアップしないんじゃないか？
だからこそ、サラリーマン向けには堅実といえば堅実かもしれないけれど、株やら投資やらで設けるような雑誌の特集とかしかないんじゃないだろうか？

また、起業に大切なのは、知識よりも行動力である。行動力があれば、必要な知識は短期間で習得してしまうくらいの勢いがある。このブログを通じて知った、小さいながらも社長を名乗っている方は、金儲け臭がしないし、努力家で、行動力があり、スピーディーである。また、彼／彼女らは人を大切にしており、決して裏切らないし、陰口も言わない。ブログをやっていてよかったなとつくづく思う。

世の中には人の顔が「金」にしか見えていない人もいる。そこまで非情になれるのも凄いと思うが、それでは信頼を失う。残念ながら、ネット上にはそういう輩が結構居る。気をつけたいものである。

グルーポンというサービス 一休というサービス

クーポンの共同購入を斡旋する会社であるが、このサービス、果たして３年後には存在するだろうか？

例えば、ある高級レストランの50%オフのクーポンを入手し、その恩恵を受けたとする。そういう人が、次回正規料金で行ってみよう、と思うだろうか？ほとんどの場合、別の店のクーポンを探すのではないか？なぜなら、その人たちのニーズは「いいものをお得に」であるから、リピーターになることは考えにくい。

RFM分析、という分析手法がある。
・R（Recency）：最終の購買日（飲食店なら来店日）
・F（Frequency）：購買（飲食店なら来店）の頻度
・M（Monetary）：購買金額の合計
これでランクを分けても、グルーポンで来るお客さんはFとMが極めて低くなると予想されるので、客としては「ありがたくない客」に分類されるだろう。

安売り店なら「価格戦略」であるため、とことん安値を追求する。これは戦略として正しい。
グルーポンを採用するところは、ある程度高級店である。そこが中途半端な価格戦略をしても、結局は一見さんがやってくるだけで、リピータはつかめないだろう。

グルーポンは、そういう中途半端な戦略を助長するだけのものであるように思える。しばらくははやりものであるかもしれないが、スーパーの特売よりも効果は期待できないだろう。それが認知されていくのに１年半かかり、それ以降は下降線をたどるのではないかと思う。

それと反対なのが、一休のようなサービスだ。これは十分に生き残ろるだろう。航空会社の格安チケットと同じで、「キャパ」が決まっており、そのキャパを埋めれば埋めるほど良いわけだ。よって、「空気を泊めるくらいなら格安ででも人を泊めた方がまだマシ」なのである。
そのニーズをきっちり抑え、Win-Winの関係に持っていっている好例だろう。

サービスを提供するなら、本当に役立つもの、長く求められるものを考えたいものである。

クラスモジュールのメリット

クラスモジュールの利用の普及を促進すべく、VBAの若干クラスモジュールについて書いてみる。

ここで、クラスモジュールとは、とかオブジェクト指向とは、という話を始めると「？」となるだろう。よって、ちょっと観点を変えて、クラスモジュールのメリットから入ることにする。


このブログのタイトルに「メタボなコードにサヨナラ」と記しているが、「メタボリックなコード」とは、同じようなコードが何度も登場するようなムダの多いコードのことだ。これを解決できる、というのがメリットである。
例１）値が数字だけで構成されているかをチェックする処理で、チェックのロ処理が何度も出てくるケース。

例２）データベースと接続しSQL文を発行する処理で、ADOやDAOなどの接続処理が何度も記述されているケース。

また、メタボとは少し違うが、
例３）共通化はしてあるが、関数名やプロシージャ名が長く、利用しづらいケース。


上記、３例挙げたが、クラスモジュールを用いれば解決できる。
工夫すれば標準モジュールでもできなくはないが、クラスモジュールを用いた方が簡単に実現可能だ。


上記の例を考えながら、メタボリックなコードにサヨナラするとどうなるのか。それ自体がおそらくクラスモジュールを使うメリットといえるだろう。それを一般的な言葉で表現し、列挙してみよう。

・複数登場する再利用しやすい形で切り出しやすくなる。
　⇒冗長部分を減らせる。　
　　⇒メインロジックの可読性が高まる。
　　　⇒現在の処理の理解が理解しやすくなる。
　　　⇒変更時の影響を特定しやすくなる。
　　　⇒バグの混入を減らせる。
　　　⇒変更時の修正箇所を減らせる。

・再利用性が高まる。
　⇒開発工数を減らせる。
　⇒テスト工数を減らせる。


まだありそうだが、とりあえずこんなところか。