サブスクって何？怪しくない？【文系にもわかる簡単解説】
昨今、色々なサービスがサブスク化していますよね。
音楽や動画、車、子供のおもちゃ、生ビールにお花など、ありとあらゆるものがサブスクで便利にてに入ります。
音楽や動画など無形のものに関してはCDやDVDを借りるよりも圧倒的に安く享受することができます。
利用されているか他は多いのではないかと思われますが、
こういう風に思ってしまったことはないでしょうか？
「なぜこんなに安いのか」
「あやしい。詐欺じゃないか。」
確かにそう思ってしまうほどの価格破壊をサブスクはもたらしました。
詐欺とまでは言わなくとも、サブスクとは何か、を正しく認識されていないケースは多々あります。
先日、私の勤め先でも「期間限定サービス」や「レンタル」といった少しニュアンスの異なる認識がされていることがわかりました。
今回は、サブスクとは何か、を例えを使いながら説明したいと思います。
また、サービスによっては、
「サブスクなのに安くない」
と思ったことがある方もいらっしゃるのではないでしょうか。
サブスクとは何か、それが分かればその謎も解けます。
この記事はこういう方にオススメ！
- サブスクを利用しているが意味はよくわかっていない
- サブスクへの申し込みを躊躇している
- 理解の低い上司や子どもに説明したい
サブスクとは何の略？
サブスクとは
「サブスクリプション(subscription)」
の略です。
日本語にすると「登録」です。
つまり、サブスクとは「購入」ではなく「登録」であり、言い換えるなら「会員限定サービス」です。
「モノ」ではなく「サービス」の入手
音楽配信の例で考えてみましょう。
「月額1000円聞き放題」というサービスに申し込んでいる会員が手に入れることができるのは曲そのものではなく、「曲を聞く権利」です。
CDを購入した場合と微妙にニュアンスが異なります。
ある曲のCDを購入した場合、そのCDの所有者は言うまでもなく購入者です。
しかし、サブスクでダウンロードした場合、その曲ファイルの所有者はサブスク提供側です。
どちらのケースも音楽が聞けることには変わりありません。
では、何が違うのでしょうか？
それは配信停止の時に顕著になります。
アーティストがサブスク配信停止をした場合、CD購入者は引き続きその曲を聞くことができますが、サブスクからダウンロードした人は聞けません。
なぜなら、その曲を購入したわけでなく、聞く権利を入手していただけなので、配信が止まれば聞けないし、それに文句を言うこともできません。
CDという「モノ」を買うことと異なり、サブスクとは提供側の「サービス」を受けることです。
サブスクは安い？
勘違いしがちですが、あらゆるサブスクサービスがモノを買うより安いわけではありません。
安くなるサービスもあれば高くなるサービスもあります。
どういうケースで安く、どういうケースだとそうでないのかを説明します。
サブスクの方が安いケース：デジタル
大まかにいって、デジタル関係はサブスクの方が安くなります。
それはデジタルは複製・共有が簡単にできるためです。
前述のような音楽配信の場合、一つの音楽ファイルがサブスク提供社のサーバーに保存されており、そのファイルを登録者全員で共有する形になります。
そのため、一人辺りの負担額が小さいため、利用料は安くなります。
音楽だけでなく、動画や漫画などのデジタルファイルの利用も同様です。
デジタルが配りやすいので安いのです。
サブスクでも安くならないケース：デジタルでない
サブスクで安くなるのがデジタル
ということは、安くならないのはデジタル以外の「モノ」を扱うサブスクです。
例えば、花を定期的に配送してくれるサブスクがあります。
花は利用者一人につき１セット用意する必要があります。
デジタルのように複製したり共有したりできません。
そのため、花１セットの料金がそのままかかります。
※在庫過多になっている花をサブスクように回す場合は花代自体は安く原価計算されるケースもあります。
あとは配送料金など間接費用が乗っかるので、花屋で花を買うより高くなるケースがあります。
費用面でメリットがないのなら、デジタル以外のモノを扱うサブスクのメリットは何でしょうか。
それは「手間」です。
花のサブスクでいうと、花屋に花を買いにいく手間や花を選ぶ手間が省略されます。
「家に花を飾りたいけど買いにいく暇がない」
「季節の花がわからない」
そのような方のために、花屋さんが定期的に花を送ってくれるので、
買いに行かずとも、花屋さんが選んだ季節の花が届きます。
なので、「買いにいく手間」「選ぶ手間」とサブスク費用を天秤にかけて、利用すべきかを検討すればいいのかな、と思います。
サブスクの隠されたメリット
最後に、サブスクの隠されたメリットを紹介します。
サブスクとは多くの場合、ウェブ申請します。
年齢とか性別とかを登録したアカウントでサービスを利用することで、サービス提供側にデータが残ります。
「女性の登録者が多い」
「40代主婦層が多い」
「30代にはこの花が人気がある」
「特定の地域は利用者が低い」
そういうデータをサービス提供側がうまく活用できれば、サービスの向上や新たなサービスが誕生する可能性があります。
サービス提供側のDXですね。
まとめ
- サブスクとは「会員限定サービス」
- モノではなくサービスの享受
- デジタル系サブスクは安い
- 非デジタル系は安いとは限らない
- サブスクの利用者増はサービスの進化に繋がる
中小企業DX失敗例 失敗しないシステム更新 ～価格よりデータ移行～
業務システムの更新って面倒ですよね？
できればそのまま使い続けたいけど、値上がりがあったり、上から相見積もりをとるように指示を受けたり、他候補を探さなければならなくなることも多いと思います。
他候補を探しているうちに、
「こっちのシステムは安いな！」
「こんな機能があるのか！？」
など目移りしてしまうケースもよくあることです。
この記事では元上場企業SEの私がシステム更新のコツについて解説します。
この記事はこんな方にオススメ！
- 業務システム更新が迫る管理担当者の方
- システム更新を指示している上層部の方
システム更新の費用は参考程度
システム更新について、一番気になるのはやはり費用ではないでしょうか。
とりわけ中小企業においては費用を押さえることが優先度が高く、
比較表の一番上には費用を記載されることが多いのではないでしょうか。
私が現在勤める中小企業ももれなく費用重視です。
比較表を作成するときには初期費用とランニングコストが一番上の項目です。
表の一番左に現行システム、２列目に現行システムの後継品、３列目以降に他社製品が並びます。
レガシーからの更新は安くなって当然
こういう表を各システムで作ると、
ある傾向が見えてきます。
現行システムとその後継品、そのランニングコストは安くなることが多いです。
それはレガシーシステムの多くはオンプレミス型、
後継のソフトの多くはクラウド型だからです。
オンプレミスとは自社でサーバーも用意して自社だけでシステムを使う形式です。
そのため、サーバーのレンタル代や管理費などが必要になります。
一方でクラウド型はメーカーが管理するサーバーにあるシステムをみんなでシェアするものです。
そのため、サーバーの管理費はみんなで出し合う形になるのでオンプレミスよりも必然料金は安くなります。
オンプレミスは一棟買い、クラウドは賃貸のようなものです。
また、メーカーの立場から見ても、オンプレミス型のサポートはユーザーの数だけサーバーの面倒を見ないといけないので手間です。
後継にクラウド型があるなら、そちらに乗り換えて欲しくなります。
そのため、更新が近づくと料金をあげたり、新しいOSには対応させなかったりして、後継への移行を促します。
ちなみに、初期費用もあってないようなものです。
これから例えば５年間毎月支払いが発生するユーザーを確保するには初期費用のサービスくらいたいした値引率ではありません。
なので、多くのシステムで初期費用無料キャンペーンが展開されています。
他社から乗り換えてもらえるなら、キャンペーン期間を延長するなんて大したサービスではないので、変更時には初期費用は交渉の余地大いにあり、です。
要らない機能は要らない
お金が参考レベルにしかならないのなら、重要な指標は何でしょうか。
機能面で言えば、各社色々な特徴を持ったソフトを持っており、目移りしてしまうこともあるでしょう。
しかし、運用で使わない機能はあくまでも過剰な機能です。
カレーを作るためにスーパーに行ったら刺身が美味しそうだったのでついでに買ったとして、でもカレーには使わないしカレーにも合わない刺身は余計な買い物でしかない、ということです。
つまり、運用にあった機能さえ備えていれば、それ以上に余計な機能は必要ないので、要らないものは要らない、と割りきることが大事です。
詳細はこちらの記事を参照してください。
データはお金では買えない
システム更新の重要な指標、
「過去データの移行」はその代表的なものです。
例えば勤怠管理システムの場合、有給取得率、何月に有給は取られることが多いのか、平均残業時間など、現行システムから集計できるデータが蓄積されています。
５年使ったら５年分、１０年使ったら１０年分のデータがあります。
このデータ、捨てても大丈夫ですか？
システムを使う目的は効率化とデータ蓄積です。
過去の勤怠データをもとに、有給取得率が低い部署に原因をヒアリングして取得率が上がる施策を検討したり、残業時間の推移を監視して、過去平均対比で跳ね上がった部署があれば原因を調べて対策したり、勤怠状況の改善をするにはデータが必要です。
そのため、新しいシステムを選ぶ際には過去データが移行できるかを確認しましょう。
現行システムの後継品への移行はできるケースが多いです。
一方で他社製品への移行はハードルが高いです。
単純にCSVで移せればいいですが、そもそもの設計仕様がまるで違う製品への移行だと、かなりの工夫が必要か、出来ないケースも多いです。
また、現行システムが移行を許さない、あるいは難しい設計になっている可能性もあります。
私は前職で他社製品のデータを分析して自社製品用にコンバートする仕組みを開発していたことがありますが、製品によっては項目名がランダムな英数字だったりで、意地悪されている気分でした。。。
そのため、他社製に乗り換える際には過去データを捨てる覚悟をしましょう。
一つの良い機能を手に入れるには過去データが引き換えになる可能性があるということです。
蓄積されたデータというのはお金では変えません。
自社の過去５年の勤怠状況や販売実績、顧客情報を販売してくれる企業はありません。自社のデータは自社でしか持ち得ないので、過去データの移行については十分慎重に検討してください。
データ移行失敗例
私の勤め先では顧客管理システムをkintoneに変更しました。
現行システムはCSVを作成できましたが、kintoneで作成したアプリとはデータの持ち方がかなり異なり、CSVインポートでは移管できなくなってしまいました。
移行後１年くらいたった今でも、手作業でExcelで修正して移行できるように調整しています。何とか移行はできそうですが、手作業なので手間がかかりすぎているのと、制度にも疑問が残ります。
Kintoneなので簡単に移管できる形でアプリを作れればよかったのですが、担当者はデータ移行の必要を認識しておらず、作りたいようにアプリを作ってしまいました。
後から他部署より過去データを移すべきだという意見が出ましたが、そのときにはもう後の祭り、手作業での修正が発生することになってしまいました。
まとめ
システム更新で重要なこと！
- 安くなることは気にしすぎない
- 余計な機能に目移りしない
- 過去データの移行を意識する
中小企業失敗例～kintoneアプリ開発の進め方～
昨今、CMでもよく見かけるようになった「kintone」
うちの会社でも顧客管理システムの入れ換えで業者から提案を受け、その費用感や柔軟性を評価して導入されました。
kintoneがどんなソフトか、というのはこちらの記事をご確認ください。
しかし、安くて簡単なkintoneだからこそ、うちの会社はその進め方に戸惑っています。
その悩みの種の一つがアプリ開発の進め方です。
簡単に言うと、以下の二つです。
- 誰が作る
- 誰が承認する
ここの決め方が曖昧でうちの会社はスタートに失敗しました。。。
同じような失敗をされる方が一人でも減ることを願って、
恥をさらす気持ちでうちの会社の失敗談を交えて解説します！
この記事を読んでほしいのは、以下のような方々です！
- これからkintoneを導入される方
- Kintoneを導入したけど積極的には使えていない方々
Kintone開発権限の設定
大きく分けて2つの方法があります。
- 大勢で作る
- 少数精鋭で作る
結論から言うと、私は後者派です。
とはいえ、前者が間違えだ、とは思いません。
Kintoneアプリを大勢で作る方法
Kintoneはプログラマーでなくても簡単にアプリが作れる、というのが大きな特長です。
ノーコード開発といい、オブジェクトのドラッグ&ドロップでアプリを作ることができます。
そのため、情報システム部や社内SEに頼りすぎる必要もなく社内業務をシステム化していくことが出来ます。
営業なら営業、経理なら経理で各部署で現場担当者がお困りことをシステム化で解決することができるので現場目線のアプリを作ることが出来ます。
と、ここまではメリットのお話。
前述の通り、アプリ開発は少数精鋭はの私は次のような懸念をしています。
- 同じようなアプリが重複しない
- そもそも現場は本当に作るのか
１について、kintoneはクラウド型データベースという特長もあります。
各自がExcelなどでバラバラの書式で管理していたものなどをkintoneにまとめて一元管理できる、という利点があります。
例えば名刺管理。
人によっては名刺をファイリング、ある人はPDFにして保存、ある人はExcelに記載していたものを、kintoneで作ったアプリに入力すること！とすることで、自社のコネクションは一元管理できるので、過去の名刺を探す場合はkintoneを見ればいいのでアチコチ探す必要がありません。
しかし、複数拠点で別々で作ってしまうと、結局管理場所が複数になってしまいます。東京本社のもらった名刺はここ、大阪支店の名刺はあっち、技術部はそっち、なんて複数に分かれてしまうと結局複数箇所を探す必要があります。
実際にうちの会社でも顧客管理アプリを管理職３人がバラバラで作っていました。当事者たちはお互いに他の人が作っていたことを知らず、良かれと思って作業していたようです。
また、汎用性の高い情報である「商品一覧」のようなアプリは多くの部署で必要とする情報です。
見積作成アプリにも必要、在庫管理にも必要、売上管理にも必要なので複数部署が必要とする情報です。
こちらも複数部署が各自で作ってしまうと商品情報も多元管理されてしまうことになります。
たとえば新しい商品ができたとき、アプリが３つあれば３つ更新しなければいけないことになります。
つまり、誰が何を作るのか、事前に明確にできていれば良いのでしょうが、営業部が作った商品一覧アプリが技術部が使いたい形かどうかはわかりません。では事前に打合せしてから作りましょう、となっても誰が商品一覧アプリを欲しているかを把握して、各部署に声かけて、各自が言いたいことを言って、それをまとめてからアプリをつくって、とするのは「気軽にアプリが作れる」というkintoneの個性を潰す運用です。
つぎに、「２.そもそも現場は本当に作るのか」です。
Kintoneはあくまでもツールのひとつです。
Kintoneがなくても、業務効率化したい人はExcelやACCESSを使って業務の効率化を図っていたのではないでしょうか？
今までExcelしか使えるものがなかった人にとって新たな選択肢が増えるということは大きな前進となり得ます。
が、そんな人って何人いますか？営業で目先の営業のことだけでなく、「こうすれば見積を作るのが楽になる」なんて考えて上司に提案して、自分でExcelの書式を変えてくれる人は極めて優秀な人材ではないでしょうか。
また、現場は本当に困っているのでしょうか。慣れというのは恐ろしいもので、Excelで見積を作ることに慣れていれば別にそれを不便だとは思っていないケースも多々あります。
むしろ、慣れたものを変えられることを嫌がる人もいることでしょう。
私もSE時代に客先納品を実施したときに、導入担当者は「便利なソフトが入った」ということで喜んでくれていましたが、操作担当者の方操作方法を覚えないといけないことに途方にくれ、インストール作業中の私に愚痴を言ってくる、という経験が何回かあります。
なので、「使っていいぞ！」と現場に指示を出しても、現場は必要ないと思ってしまう可能性もあります。
実際にうちの会社では「作っていいぞ！」といわれて作り始めたのはプログラマー１人だけでした。号令の対象は３０人くらいなので、実際に動いたのは３％くらいで、それももともとプログラミングができる人だけでした。
これらを踏まえて、「少数精鋭開発」の特徴に移ります。
Kintoneアプリを少数で作る方法
上述の通り、大勢で作るとkintoneの中で同一情報の多元管理が発生してしまう恐れがあります。
少数精鋭だと、コミュニケーションをとる相手が限られているので、誰が何を作るのか、どのような項目を入れるのかなど打ち合わせもスムーズです。全体の設計を決めてから作り始めることができるので、開発行程もスムーズです。
また、作る人が明確なので「本当に作るのか」なんて心配は全くありません。
現場の声が活きないのではないか、という懸念もあるかもしれませんが、kintoneは修正も簡単なので、一度フィールドに出して、現場の声を聞いて、修正していくPDCAサイクルで十分対応できます。
私のもつ唯一の懸念は、「現場のIT教育にならない」ということです。
大勢にさわってもらうことで、ソフトウェアを身近なものに感じてもらい、ITリテラシーを自発的に養ってもらう可能性がない、ということは大勢開発派と比べて劣っていると言えるでしょう。
しかし、私はこうも思います。
「Kintoneはひとつのツールにすぎない。kintoneでのアプリ開発がうまくなる、ということはITリテラシーが高くなる、ということではない。要件に応じてExcelやACCESS、kintone、場合によってはパッケージソフトなどの選択肢の中からどれが最適か選べることが真のITリテラシーだ」
つまり、kintoneでアプリを作るのが上手な人を育てることはさして重要でなく、もっと全体像を見て考えることができる人を育てることが大切で、それはkintoneをさわらせる、くらいのことでは出来ないと思います。ワークマンがExcel経営で成功した事例もあるので、夢みたい気持ちもありますが、それは自由にさわらせるだけでなく研修の成果なので、大勢にさわらせるなら社内研修までがセットです。
Excelのようなすでに馴染みのあるツールと異なり、社内に精通した人がいない状態でワークマンがExcelで成し遂げたことと同じことをkintoneで再現することは難しいと思います。
ただし、その辺も見越してか、kintoneはヘルプも充実しており、ハウツー動画も充実しているので、勉強する環境は十分に揃っています。管理職側の持っていきかた次第で十分に現場にkintoneを覚えてもらう運用は可能だと思います。
まとめ
私はkintoneアプリは少数精鋭で進めるべきだと思います。
誰でもアプリを作れるのは魅力ですが、設計が上手とは限りません。料理がうまい人でもプロのシェフほどレシピのアイデアはなく、DIYが上手な人でも住宅の設計は設計士には敵わないと思います。
とはいえ、みんなに使ってもらいたい、という気持ちも十分理解できます。そこで、私の思うこの２策のハイブリッド案は以下の通りです。
まずは、少数で軌道に乗せる、社内での運用が浸透してきた頃に、修正案がある人には修正してもらう、あるいはそこから派生したアプリを思い付いたら作ってもらう、というものです。どんなソフトでも一番難しいのは導入だと思います。過去のデータの移管も必要です。それをITリテラシーに長けない人に丸投げしても進まないことはうちの会社が証明しています。。。
何回かレシピにしたがって料理を作っているうちに、もっと濃い方が好みだから調味料を足すとか、牛肉じゃなくて豚肉でやってみるというのは難しくなく、失敗のリスクも低いと思います。住宅が出来たあとに棚を増やしたりウッドデッキ作ったりすることも失敗しても生活に支障は出ません。それと同じように、大本は「プロ」が担当すべきだというのが私の意見です。
「そんなこといっても、うちにはITに詳しい人いないよ」って思われるかたもいるかもしれませんね。しかし、kintoneはCybozu社のパートナーが導入を支援してくれます。「やりたいこと」を伝えれば、アプリも作ってくれるので、その初期費用は惜しまないのが得策だと思います。
SDKとAPIって何？元上場企業SEのIT用語解説
ソフトウェアの設計や開発をしていると、高頻度で登場するアルファベット3文字語
エンジニアの方は理解されていても、
案外それを売る営業の方なんかは知らないことも多いようです。
私の勤め先の中小企業でもソフトウェア開発してますが、開発部隊以外はほぼ全壊状態です。
知らなくても困らないかもしれませんが、知っている方が営業の方はお客様との打合せではカッコよく振る舞えると思いますよ。
なので、この記事は以下の方にオススメ！
- IT関係の営業をしている
- 取引先との打ち合わせで今までは知ったかぶりしてた
- アルファベット3文字語を使いこなしたい
SDKとは？
Software
Development
Kit
の頭文字をとったものです。
日本語にするなら、
「ソフトウェア開発キット」
ですね。
これは自分のソフトウェアと他の人のソフトウェアを合体させるために使うキットです。
世の中には色んなソフトウェアがあります。
中には生体認証とかQRコード生成とか、汎用性の高いものもたくさんあります。
例えば自分が新しくQRコードを使った在庫管理ソフトを開発する際に、URLからQRコードを作る仕組みをお手製で一から作るのは、かなりの工数がかかり、専門性が高いので精度も不安です。
一方で、すでに実績多数のQRコード生成ソフトウェアが世の中には既に存在しています。それを使えれば精度は間違いありません。
自分の在庫管理ソフトと他社のQRコード生成ソフトを合体させるのにSDKを使います。
SDKがない時ー
一から作るのは前述の通り大変です。
また、先ほどの例だと、QRコードを実績ある他社のQRコード生成ソフトで作ってから、それを自社のソフトで使う、という方法もあります。
でも２つのソフトウェアを順に起動する必要があり、手順が多くなってしまいます。
SDKがある時ー
そこでSDKの登場です。
QRコード生成ソフトを自分の在庫管理ソフトに組み込んでしまいましょう。
QRコード生成ソフトはURLを渡せば任意のファイル名で任意の場所にQRコード画像を生成・保存してくれるという外部連携機能があります。
この外部連携に関するファイルなどの総称をSDKというのです。
それを使えば、自分の在庫管理ソフトのボタンを押せば、必要なQRコードが必要な形で出すことが出来ます。例えばラベル印刷ボタンを押せば、他社のソフトが作ったQRコードを、さも自分のソフトで作ったかのようにラベルに印刷して出す、という機能が作れます。つまり、２つのツールを立ち上げるという二度手間を回避できます。
SDKって何が入ってるの？
キットと呼ばれるからには、複数のものが含まれています。
では、何が入っているのか？これはソフトウェアに依存するので一括りでは言えません。
なので、よく入っているものを代表として紹介します。
API
これは
Application
Programming
Interface
の頭文字を取ったものです。
つまり、
アプリとアプリをつなぐプログラム
です。
これはSDKの肝になるものです。
先ほどのQRコード生成ソフトの例で言えば、自分のソフトウェアから、
「こんなQRコードを作ってください」
と依頼する窓口になります。
代表的なものはDLLファイルです。
ガイド
APIとは窓口だと記載しましたが、窓口には所定の書式で申請する必要があります。
各々が好きな書式でQRコード生成を申請されても窓口では対処できないので、
「こちらの書式で申し込んでください」
というマニュアルみたいなものが多くの場合SDKには含まれます。
例えばQRコードを作るのには元となるURLとか、QRコードの種類とかを伝える必要があるので、それを伝える順番とかがガイドには書いているので、自分のソフトウェアのコードの中に、
「QRコード生成ソフトさん、このURLでこの種類のQRコードを作ってください」
というコードを混ぜておけば、自分のソフトウェアからQRコード生成ソフトを呼び出してQRコードを作ることができます。
SDKは焼き鳥のタレ
さて、ここまでは実際のソフトウェアで説明させてもらいましたが、わかりやすいように、身近なものに例えてみます。
それは、焼き鳥のタレです。
名店の焼き鳥のタレは門外不出の秘伝のレシピで出来ています。
しかし、知り合いが
「鳥は自分で用意するから、タレちょうだい」
って頼まれたので、ボトルに入れて渡すことにしました。
つまり、レシピは渡せないけど、使ってもいいですよっていうことです。
レシピはソフトウェアでいうところのコードで、これは各メーカーの財産なのでオープンには出来ません。しかし、中身を知らないで良いなら使ってもいいですよ、ということでSDKを提供しています。
そしてタレを渡すからには美味しく食べて欲しいので、保存方法とか適量を書いてメモを渡してあげます。これがガイドです。
この場合、APIがタレです。
中小企業失敗例 システム化編～正しいソフトウェアの選び方～
DX関連の記事がビジネス情報誌を賑やかし、2025年の壁が近づき、さらにコロナ禍でシステム化に待ったなし！という状況の昨今、多くの企業がエクセルや紙でやっていた業務を見直し、システムの導入を検討されているのではないでしょうか？
私が勤める中小企業でも現行業務を見直し、システム化を検討しています。
ただし、ITリテラシーが高い人物が社内に多いわけでないのがIT分野に関して多くの企業に共通の悩みではないでしょうか。
本記事では、元上場企業SEの私が、失敗のないシステム導入の方法をご紹介させていただきます。
どのソフトを選べばいい？失敗しないソフトの選び方
今はIT企業は非常に多いので、ある一つのジャンルだけでも無数にシステムの選択肢があります。
例えば、チャットツール。
有名どころのSlack、LINE、Microsoftのteamsなどなど、他にも料金体系も仕様も様々なシステムがあります。
なので、全部見て、そこから選ぼうとすると途方もない作業になってしまいます。
そこでやってしまいがちなのは、一番最初に出会ったものに決めてしまうことです。
システム化の圧に負けて、とりあえず何かは買わないといけない、とはいえ色々見てそこから選ぶ時間もない。そんな中、一番最初に知ったものがそれなりに良さそうだと思えたら、もうそれしか見えなくなるかもしれません。
システムの導入で一番手間がかかるのは、導入時期です。既存のものからデータを移管したり、使い方を覚えたり、社内運用ルールを決めたり、システムによってはNDAなどの契約を交わす必要があるものもあるでしょう。
なので、買ったはいいけど、思ってたより使い勝手が悪い、社内での評判も悪く買い替えることになった、というのは出来るだけ避けたいですよね。
なので、システムの選び方は大切なのです！
現行システムとの比較
まず、今使っているシステムと比較してみます。
しかし、間違えてはいけないのは、費用も機能も、基本的には新しいものの方が良い、ということです。だから買い替えるので、現行と新しいものの比較表みたいなものを作って並べて比較するのは、あまり意味がないです。
安くなるのは当然
特に費用に関して、現行のものが社内にサーバー構築してるとか、レンタルサーバーを使用している、いわゆるオンプレミスの環境である場合、サーバーの維持費用など、ランニングコストが高いのは避けられないし、初期費用にしても、売り手はここで一気に原価を回収する必要があるので、それなりの価格になります。
一方、今は多くのサービスはクラウドで提供されています。こちらは一つの環境をユーザーみんなで分担して維持費を払うような形になるので、ランニングコストは安いです。また、最近の考え方として、サブスクに代表される、一人一人の使用期間を伸ばして定期的にお金をもらうような方式(LTV)が重視されることもランニングコストが高くない理由です。一つのサービスをみんなで使うので、売り手の原価回収も早く、遠隔地へのサポート要員もいらないため、初期費は「今ならサービス！」ってところも多いです。
なので、新しいものは基本的に安いので、切り替えたら安くなる！っていうことに過剰に反応するのは得策ではないです。
問題は何？どうしたい？
では、何を比較するのか。
それは、旧システムの問題用紙と新システムの解答用紙です。
旧システムに何か問題があるから、買い替えたいわけなので、何が問題なのかを明確にします。例えば、「タイムカードの集計作業を毎月経理が給与計算のために残業して手集計している、残業時間を減らしたい！」という問いに対して、新システムは何点の回答が出せるのか、それが、システム選びのコツです。
ソフトウェアの選択基準は「要件」
この問題用紙のことを「要件」といいます。
要件定義を決める、とかIT業界的には言ったりします。
どのシステムが自社の要件を満たすのか、それがシステム選びの失敗しない基準です。
市場である程度成熟したジャンルのシステムは、高いレベルで機能面の頭打ちを起こしています。その中で、それぞれ得意不得意があります。
要件を決めないままシステムを見ると、思いつく機能は全部入っているので、凄く良いシステムに思えます。
うちの会社でも、
「これさえあれば何でも出来るんだ！」
なんて嬉々として新しいシステムを紹介される方がいらっしゃいます。
しかし、あらゆる機能を持っているのはスタンダードで、その中で何が得意か、が大切です。
SNSで例えてみましょう。
FacebookやInstagram、Twitterなんかが有名どころだと思います。
どのSNSも友だちと繋がれるし、記事投稿できるし写真や動画投稿、ダイレクトメッセージもできます。
あとは、SNSで何がしたいか＝要件が大切です。
写真にこだわるならInstagram、実名で旧知の友達との関係を築くならFacebook、匿名で気楽に投稿したければTwitterなど、それぞれ特徴があります。
知ってる人とだけ絡みたい、と思っている人が
「Instagramなら何でも出来るんだ」
って言ってInstagramを始めたら、知らない人からフォローされたりDM来たりして嫌になり、やめてしまうかもしれません。
どのSNSも実装機能数はほぼ同じですが、特徴が異なるので、目的によって適切なSNSは変わってきます。
これと同じことが勤怠管理、経費精算、グループウェア、チャットツールなど、各業務システムにもいえます。
要件決める前にあるシステムを見ると、何でも出来る！って感じてしまいます。
要件が決まっていれば、説明を聞いたうえで、したいことが出来るのかを質問できます。出来なければバツにして、他のできるシステムを探した方が効率的です。
ソフトウェアの探しかた～比較表を手に入れる
まずは何が課題で、どうしたら良くなるのかを決める、というのは上述の通りです。
要件が決まったら、次はどうやってシステムを探すか、です。
大概のシステムは、どこかの企業が比較表を作って、無料ダウンロードをウェブサイトで案内しています。
自社の製品をアピールするためのものであれば、自社の強みを押した内容になるので、額面通り受け取らないように気をつけてください。
個人的には以下のウェブサイトがオススメです。無料会員登録であらゆる比較表をダウンロードできます。
比較表をみて、当てはまりそうなものから順に問い合わせして、話を聞いて、要件にハマればマル、要件を外していればバツをつけていきましょう。
マルが一つでたらそれで確定としても良し、納得いくまで追加で聞いていくのも良し、です。
基本的にはマルがついていれば大丈夫だと思いますが、予算の面だったり、会社風土として相見積が必要だったりで複数見る必要があることもあるでしょう。
大切なのは、いくら安くても要件から外れてるものはマルとしないことです。
まとめ
何よりもまず、要件を決めましょう。
先にシステムを見てしまうと、大概のシステムは魅力的に見えます。
要件を決めて、要件に合いそうなシステムを販売している会社から順に問い合わせしましょう！
ちなみに、うちの会社がkintoneの導入に失敗したときの紹介はこちらです。
matsublog2021.hatenablog.com
要件、運用が定まらずにズルズル進めて失敗したパターンです。
システムのパフォーマンスは「要件×仕様×運用」です。
とりあえず何かを買えばうまくいくわけでもない、ということです。
アドセンス合格記 ほぼスマホだけ、はてなブログ無料版で合格した方法
私ははてなブログの無料版を利用しています。
そのため、ドメインは独自ドメインでなく、WordPressも使用していません。
また、ブログの更新にパソコンもほとんど使用していません。必要なアプリは全てスマホに入るので、通勤時間などの隙間時間を使うには、スマホでの更新に慣れるのが良いと思ったのがスマホしか使わない主な理由です。小さい子どもがいるので、なかなか家でパソコン開いて作業する時間が取れないため、基本的に隙間時間に作業することにしています。
そのため、更新頻度はかなり低いです。
そんな私ですが、先日、Googleアドセンスに合格しました！
3回目の申請での合格でした。
つまり、独自ドメインでなくても、Googleアドセンスには合格できる、ということになります。
Googleアドセンスについては、合格基準は全てオープンにされているわけではないので、インターネットでも色んな噂が流れてます。
それを全部信じると、それなりの環境を揃えないといけないと思い、有料のものを使いたくなるかもしれません。
一方で、まだどうなるともわからないものに最初から課金することに抵抗がある人もいると思います。私もそうでした。時間が取れるともわからない、いつか収益化できるかもわからない、続けられるかもわからない、そんな中で先行投資するのは難しい、というのは仕方ない考え方だと思います。
そんな私と似た境遇の方々の参考になればと思い、私の合格記を書きたいと思います。
個人的見解がたっぷりなので、くれぐれも鵜呑みになさらないよう、予めご了承ください。
はじめに
私は全くの無課金でGoogleアドセンスに合格しました。
しかし、これは自慢でも何でもなく、有料で出来る方は、ぜひ有料でやるべきだと思います。
同じ目的地に行くのに、徒歩で行くかタクシーで行くか、だけの違いだと思います。
歩いていけるからと行って、タクシーに乗る人が間違えているわけではありません。
所要時間は短いし、空調など含め、快適に行けるので、懐事情さえ許せば、タクシーの方が断然良いです。
この記録は、タクシーに乗れない人のために、歩いても行けることを示すためだけの記録です。
「無課金でも合格するのに、わざわざお金を使う必要ないですよ」
とは決して思いません。
むしろ、
「どうしても歩いていくというなら参考にしてください」
くらいのニュアンスです。
なぜ無課金でも合格できると思ったか
Googleアドセンスに申請したのは、ある程度は勝算があったからです。もちろん自信はありません！
ただし、理屈で考えて、Googleが納得する環境は無課金でも作れそうだと考えました。
数ある合格基準の噂から、自分の理屈と照らし合わせて、信用できるものだけを採用しました。
理屈の根底にあるのは、
「Googleには広告を出させないメリットは基本的にはない」
ということです。
Googleも出稿してる企業などから収益を得るので、多く表示するに越したことはないはずです。ウェブ広告の市場は年々大きくなっているので、広告を貼れる場所は多いに越したことはありません。
例えば、あなたがチラシを貼るように依頼を受けていて、チラシを見たお客様の送客に成功すれば依頼主から報酬を得れるとすれば、色んなお店にチラシ貼りたいですよね？選り好みをする必要は特にありません。
なので、Googleは基本的には広告を出したいはずです。では、なぜ審査が必要なのでしょうか。それは、出稿元のイメージなどに依ると思います。
アダルトな内容や思想の強い内容など、ちょっと怖いイメージのところにチラシ貼られると印象悪いからやめてほしい、っていうのがシンプルな理由だと思います。
居酒屋のチラシを貼ってあげるのに、他の居酒屋や地域掲示板なら問題ありませんが、怖いお兄さんたちが出入りする何してるか分からない建物の入り口に貼られると、
「あの店、危ないのかも」
と逆効果になりかねません。なので、チラシを貼れそうな場所かどうかを点検に来ます。
つまり、コンテンツが広告を貼って、広告主の印象を損ねないものかどうかを判断しており、その基準の一つにテーマがYMYLかどうかなどがあるのではないか、と思います。
噂と照合、マストかベターか
上記理屈といくつかの噂を照らし合わせ、Googleがどこまで重視してそうかを考えます。
独自ドメインは必要ではない
これは、私が合格したことからもわかる通り、マストではありません。
ドメインはお金さえ払えば誰でも好きなものを取得できます。独自ドメインだからといって、運用主が善人かどうかはわかりません。とは言え、持っている人の方が熱心そう、とは思えますので、この基準は無くはなさそう、でも優先度は高くなさそう、と私は考えます。
プライバシーポリシーとお問い合わせフォームはマスト
これはマストであってもおかしくないと思います。なぜなら、簡単にふるいに掛けられるからです。Googleの持つクローラーの技術なら、そのコンテンツにこれらが含まれているかどうかは機械的に判断できるので、毎日数多く申請があがるであろうことを想定すると、第一関門的に機械的な判断はしていることが想像できるので、これはマストの可能性高そうです。信頼できるコンテンツかどうか、という意味でも連絡先が明確に示されていることは重要なので、これはかなり優先度高いと思います。クローラーに簡単に見つけてもらえるように、URLもそれっぽい名前にしとくと良いと思います。
ライティング能力
文章が上手かどうか、ですが、これは上手いに越したことはない、っていうところでしょうか。これって主観とか好みによるところが強いので、AIで機械的に判断するのも難しいので、単純に合格不合格は言えないと思います。
もはや言語として成立していないレベルならともかく、一定レベルを超えたら優劣はつけにくくなるので、ライティング能力が下手だから落とす、は難しいと思います。前述の通り、基本的には合格にしたいはずなので、各担当者の好みで分かれるような曖昧な基準のものに重きは置けないと思います。
PV数
これは、あまり関係ないと思います。チラシを貼るのに人が多い居酒屋と人が少ない居酒屋、前者の方が効果はありそうですが、後者に貼らないメリットもないですよね。むしろ、人が少ない居酒屋にも太客が来る可能性を消してしまうので、貼らないデメリットはあります。
実際、私のこのブログのPVは合格時点で月間300程度と決して多くないです。
考察まとめ
以上の理屈に則り、私はGoogleアドセンスに申請して合格しました。ただし、いずれも、ないよりはあった方が良さそうなので、それらを意識することは決して無駄ではないと思います。
私の理屈の矛盾
Googleは基本的に合格にしたいのに、なぜ合格率が低いのか、という疑問を持たれた方もいると思います。これは絶対数と相対数の印象によるものだと思います。
簡単に言うと、応募の絶対数がかなり多いので、5%しか合格しなくても、かなりの絶対数は確保できる、ということです。このマーケットはGoogleがほぼ独占状態なので、割合は低くても絶対数は大きくなると思います。
また、基準を緩めすぎると、広告が相応しくない場所に貼られた！と広告主が怒るトラブルが発生するリスクが上がります。トラブル対応は通常業務より工数とられるのでリスクは極力下げたいですよね。
なので、少しでも疑わしいものは取らない、っていうのはあると思います。
申請数はかなりの数あると思うので、審査するとすれば、機械的審査でふるい落とし、残りを人的に処理するものではないかと想定しています。人的に処理するときに全記事を確認するかは分かりませんが、記事が多すぎると、どの記事を見て落とされたのか分からないので、記事がまだ多くない段階で申請してみるのが良いと思っています。不合格の理由がメールで明確に記されないのは、人的処理によるある程度の不平等を見せないためでもあるのではないか、と思います。
「こんな理由で落とされたけど、誰々の記事も該当するのに合格してる！」
みたいなことです。
不親切に思える仕様ですが、取り扱う案件数を想像すると、仕方ないと思います。
私の使用ツール
上記考察の通り、私は敵を大きくは見ないようにしました。基準が明確でない以上、色々考えすぎても分からなくなるので、この理屈で無理ならもう無理！と思ってブログ更新していました。私のルールに則り、必要だったのは以下のツールでした。
-
- Google Chromeアプリ
- Googleアナリティクスアプリ
- Gメールアプリ
- Twitterアプリ
- はてなブログアプリ
- canvaアプリ
Chromeはサーチコンソールとアドセンスの申請、他調べ物に使っています。
サーチコンソールはGoogleに見つけてもらうために必須なので、分析用ではなく、インデックス用っていう感じです。
はてなブログアプリにてブログのデザインとかも更新してましたが、アプリでは変更できないCSSの部分などは、Chromeからはてなブログにログインして更新してました。
スマホだとそれでも項目は限定的なのですが、PC版をリクエストする、という開き方をすればPCと全く同じ画面で編集出来るので、項目に不足はありません。
CSSなんて、スマホで入力するの面倒だと思うかもしれませんが、現在、大抵のものはネットに落ちてて無料公開、コピペどうぞ！ってなってるので、基本的にはコピペだけです。色コードを触るかどうか、くらいなのでスマホでもそれほど苦ではありません。
とはいえ、PCの方が効率的には作業出来るので、時間ある時はPCでやってました。「ほぼスマホだけで作業していた」の、「ほぼ」にあたるのはこの作業が主です。
最後に
以上のとおり、無課金で屁理屈こねてGoogleアドセンスに合格しましたが、決してオススメはしません。本気で受かりたい人は、実績あるサービスでレクチャーを受けるなど、信頼できる人を探してください。上の私の考察は筋は通っているかもしれませんが、あくまでも推察の域を出ない、この記事こそ信頼出来ないコンテンツです。結果論として、合格はしていますが、この推察を裏付けるものではないので、あくまでも、参考程度に留めてください。ただし、これで合格できた、という事実はあるので、ブログを始めようと思うが費用は掛けれない、という方は、無課金でも希望はある！ということは示せたと思います。
なお、最初に述べたとおり、有料サービス使えるなら、絶対にその方が効率的です。デザインにもこだわれるし、満足度は高いと思います。予想外のエラーが出れば、その対応は勉強になるし、本業に活かしたいならWordPressに慣れる方が無料プランでやるよりも遥かに役立つスキルです。なので、決して無料プランでスマホだけでやる方法はオススメしません。ぜひ、ご自身にあった運用方法をご検討ください。
SCM 〜アルファベット3文字語解説〜
アルファベット3文字語って世の中にすごく多いですよね。
CRM, LTV, KPI, KGI......
十分な知識がないと、一つの記事を読むのに、いちいち調べないと読めません
しかし、調べてみると、アルファベット3文字語を新たなアルファベット3文字語で解説されており、どんどん深みにハマるケースもあります。
このアルファベット3文字語のことを個人的には「意識高い系語」＝イタ語と呼ぶことにしています。
https://matsublog2021.hatenablog.com/entry/2021/07/08/221202
以前、このブログ内でCRMとLTVについて、
クリームパンを例に説明してみました
今回も出来るだけわかりやすい形で難しい用語の説明をしてみます！
SCMとは？
supply
chain
management
の略で、日本語に訳すとしたら、
「流通管理」
って感じでしょう。
要は、商品の入出庫管理です。
特に入庫について、そのタイミングや量を適切にして、無駄な在庫を持たない、廃棄を少なくするなどコストを抑えることがSCMシステムを導入する目的です。
仕入れの管理
MD(マーチャンダイズ)計画とか生産管理、動態管理とか呼ばれてる仕組みがこれに含まれます。
難しい言葉が並んで、頭ボンってなりそうですが、一つずつ、パン屋さんで例えていきたいと思います！
MD計画
お客様のニーズや消費動向を予測して、必要な商品を必要な数だけ用意しておきましょう！っていうものです。
あるパン屋さんは高校と最寄駅の間にあるので、朝の登校時間に昼食を買って行ったり、夕方に寄り道して帰る学生の需要が高いです。
なので、その時間には焼きたてパンを多く並べて、足りずに機会損失！なんてことがないように注意しなければいけません。
逆に、昼間は比較的お客様は少ないので、パンをいっぱい焼いても夕方まで残ってしまう可能性があります。そうなると夕方の掻き入れ時に新しく焼くパンの数が減るので、焼きたてパンで学生を誘惑する作戦に影響が出ます。
この例えは1日単位ですが、実際には月とか年とか長いスパンで計画します。
春秋はピクニック需要があるからサンドウィッチ用の食パンは多めに作ろうとか、高校の夏休みの間は需要が落ちるので小麦粉の仕入れを控えようとか、そんな感じです。
生産管理
生産管理とは、簡単に言うと、
モノの流れの管理
あるいは、
情報の流れの管理
です。
在庫が今何個あって、それが何時には何個出ていくことになってて、何時には何個出来上がってくるのかを管理します。
パン屋さんでいうと、以下のようになります。
クリームパンが今は5個あります。
しかし、提携している移動販売のパン屋さんが30分後には10個取りに来ます。
それに気付いて急いで焼き始めますが、クリームパンを作るのには1時間かかります。
この杜撰な管理では、機会損失が起きてしまいます。
そこで、生産管理です！
何時にはクリームパンが10個出る、という情報をもとに、在庫を調整すべく、何時に焼き始めるか、何個焼くか、その予定を管理しておきます。
在庫が無くならないように、
または過剰在庫にならないように、
納期や在庫、その製造工程を管理しましょう！
というイメージのものです。
動態管理
こちらは物流の管理です。
パン屋さんだと小麦粉やパックのジュースを仕入れていると思いますが、GPSなどを利用して、リアルタイムで今どこに運転手はいるのか、その状況を確認します。
生産管理に繋がりますが、いつまでに仕入れて在庫に出来るか、も機会損失を防ぐための大切な情報なので、こちらもきっちり管理しましょう！ということです。
POS管理
アルファベット3文字語を説明していると、違うアルファベット3文字語が出てくる、というのはもはやアルファベット3文字語あるあるですね。
これは
POINT
Of
SALES
の略で、日本語にするなら
「販売時点管理」です。
何が、
いつ、
どこで、
何円で、
売れたのかを管理します。
主にレジに含まれる仕組みで、
バーコードを読んだ時点で上記情報を保存します。
そうすることで、5時にアンパンが平均10個くらい売れているとか、傾向を出すことが出来たり、リアルタイムで在庫を更新できるので、生産管理と連携して、機会損失や過剰在庫のリスク軽減に役立ちます。
