【IT勉強】 APIを公開するのは長期的に儲かるからか（自社への囲い込みの一環）

　今更ながら、何故APIを公開する会社が多いのか不思議に思いました。せっかく自社でデータ集めたり、使いやすいように加工・分析してサービス展開をしているのに、それを他社が利用できるように公開しているのか。

　勿論、ただ単にデータ集めて加工するサービス自体をサービス提供するなら素直に理解できますが、普通にその整理したデータを使ってレコメンドしたり、付加価値つけてサービス化してるのに、なんでわざわざ他サイトを助けるのだろうか、疑問に思いました。

　頭の整理として調べてみた結果、結論としてAPIを公開しておく事で、ユーザないし類似業界の他社に対して、自社サービス使用頻度を高めて、結果的に囲い込みにつながるため、というのが答えかなと思います。

■備忘メモ

ーAPIとは（データ公開や再利用のための口）

「Application programming interface」の略であり、他のハード/ソフトの提供している機能を利用するための接続点になる。APIから必要なデータやサービスを活用する事で、高速にサービス開発ができる。（車輪の再発明を防げる）

ーAPIのマネタイズ（2つの作戦）

　①ブランド価値向上

　　開発者に対して魅力的なAPIを提供し、優れたアプリが開発されることを期待する。そのアプリによって自社サービスのブランド価値が上がったりする。

　また、ライバルよりもユーザーの利便性を高めることが、間接的に自社サービスの拡大に結び付く。

　②API利用課金

  価値の高い情報の有償提供を行う。データ整理して、売るモデルであり、塵も積もれば山となる作戦で1回1回の価格は非常に低めに設定する事が通例。

ーAPIを実装するための主要プロトコルは２つ（RESTとSOAP）

使用されているのは、融通が利くRESTの方が圧倒的に多い。

「WEBを支える技術　P23」より、REST:SOAPの利用率は「8:2」

※2000年代との事であり、今でももっとRESTが多いと想定

ー留意点

　他社の公開されているAPIを活用して、付加価値を出したい本業に集中して素早く効率的なサービスを作成する、という事ができますが、当然ながら他社に依存している部分があるので、他社影響を強くうけます。

　いかにAPIを実装するためのプロトコルを共通化しているとはいえ、仕様変更入れば自社もそれにあわせないといけませんし、仮に公開停止にでもなれば、その部分は代替手段を準備する必要があります。

ーまとめ

　自社サービスを他社にも使いやすいようにすることで、今まで届かなかったユーザにも間接的に認知度を上げて、結果的には自社サービスの儲けにつなげられるため、APIを公開する会社も多いのだと理解しました。

参考）

xtech.nikkei.com

 

【IT勉強】 デジタルガバメント推進標準ガイドラインより予算要求の章だけを読んで圧縮（他は別途・・・）

　政府がまとめてくれた、システム開発における発注者側の考える事やふるまいが記載されています！　おそらく、このガイドブック内容が実践できる時、私が悩んでいたり、将来悩みそうな大部分はなくなりそうです。嬉しい事に非常に量も質も多いです。

　しかし、その分全てを読むのは骨が折れるため・・・特に発注側でやりきらないといけないであろう【3章：予算要求】について読んでみました。

　特に、参考になったポイント中心に下記にまとめていきます。

【経営戦略】 マスユーザ相手はコールセンタ/コンタクトセンタを委託で用意する（アーランC式で必要オペレータ数を想定）

　お客様から問い合わせをいただいたり、トラブル時にクレームいただく際など、コールセンタはあると便利だと思いますが、そのために人員や施設用意するのは、コストを高くする要因になります。とはいえ、窓口対応を除けば（そして全国津々浦々に用意はできないので）、コールセンタによる電話がお客様の問い合わせ内容と感情的な部分含めて情報を得やすく大事になります。

　お客様の生生の声を大事にしない企業はないと思いますが、同時に毎年固定的にコストがかかるコールセンタを新設したり運営するのも悩むべき問題化と思い、調べてみました。

　結論としては、マスユーズ相手にはコールセンタを用意、ただし技術の進歩でなく、将来的にはなくなる可能性が高いので自社で育成せずに委託するのが無難。

■備忘メモ

 　●問い合わせ対応の種類

　　－有人の窓口対応：非常にコスト高いが、応対も速く、融通が利く

　　－コールセンタ：コスト高いが、応対も早く、融通が利く

　　－メール：コスト安いが、応対に時間がかかる。

　　　　　　　意図を取り間違える可能性がある。

　　－自動チャットボット：意図をくみとれない可能性が高く、回答が困難な可能性がある。ランニングコストは非常に安い。※現時点の技術力

　　結論として、コールセンタとメール窓口が中心としておく。

　　自動チャットボットは今はユーザ心証を損ねる可能性があり、主力にはできない。

　●コールセンタの現状

　　－地方に拠点を置き、人件費削減を進めている。

　　－オペレータ/SV(指導・管理）ともに採用が困難。

　　－辞職率も高く、長く続かない。

　　－IT支援が進み、昔よりは対応のしやすくなっている。

　●ざっくり相場

　規模やオペレータ数や運営時間で変化が大きいため、参考値

　　【自社の立ち上げ】

　　ー初期コスト：２０万～３００万

　　－ランニングコスト：１０万～６０万

　　【委託】

　　－定額で数十万

 参考）

コールセンターの費用は開設と委託でどう違う？費用対効果も検証 | クラウドソーシングTimes[タイムズ] |

　●必要なオペレータ数の定量的な求め方（アーランC式）

　　　オペレータが多いと、電話は逃さないが、人件費が増加

　　　オペレータが少ないと、人件費は下がるが、電話を逃す

　　　　※激務すぎて辞めるかもしれない・・・

　　そこで、定量的なオペレータ数の求めかたとして、「アーランC式」がある。

　条件

　　　①会話と後処理の時間（平均）

　　　②1時間当たりの電話数

　　　③サービスレベル目標値（一般的には、20秒以内に80%の電話にでる）

　の３つをアーランC式に入れると、トラフィック理論に基づいて必要なオペレータ数が算出できる。

■まとめ

　ビジネスユーザと違ってマスユーザは、説明力や共通する知識の理解度に差が大きいので、電話によって密なコミュニケーションは必要だと考えます。となると、コールセンタを設けるのがよさそうです。

　ただし、AIの技術進歩や問い合わせ自体がサービスが枯れてくれば定型問い合わせも増えてくるので、自社では立ち上げず委託するのが無難ですかね。その際は、基本は一般的なレベルを求めつつ、アーランC式のような定量的な考え方でだいたいの目途をつけて、そこから品質（オペレータ数）を上げ下げしていくのが、面白みはないですが現実解の一つですかね。

■Tips

 コールセンタ白書がありますね。こちらは、目次だけみる限りかなりコアな内容があるので、もし会社で検討するとなった際には目を通すといいかもしれません。

【IT勉強】 ログ設計方針の確認を求められた時に備えてみた (全部取れでは意味がないので）

　エラーが発生した際に、根本的な対応策の検討および改修するためには、その時エラーが発生した時の状況がわかるログを確認する必要があります。ただし、エラーが起きた後に当時のログ出力させる事はできないので、システム開発時にログをどのように残すべきか考える必要があると思います。実際の細かいログの設計はプロに任せるとして、発注側で考えるべき事をまとめてみました。

■備忘メモ

　●大前提として、ログの役割を整理すること。

　－監視、エラー対応、マーケティング活用など、そもそもログを何の目的でとるか検討し、関連メンバで認識をあわせる事

　●ログが必要な時に使えるように準備しておく事（消えない事）

　－あるハードに障害が起きて起動しなくなったとする、その際に、同一ハードにしかログがない場合はログが確認できず、原因が掴めない恐れがある。

　※別途、ログ保存領域が具備されている物なら、ベンダなら拾える可能性はあるが・・・ログを見て対応する原因解析や説明根拠を用意する時間が長くなる。

　（ログ収集サーバでストレージを多く積んだサーバを別途用紙するのが通例）

　●ログを見やすくする事

　－緊急度の基準を考え、特定の緊急度以上のログだけを表示するなど工夫する。

　　例、Syslogの基準を参考にするならば、出すべきログを下記のように分け、それぞれ割り当てておく。　　

      <Syslogの緊急度>

　　　debug デバッグ情報

　　　info 情報

　　　notice 通知

　　　warn 警告

　　　err 一般的なエラー

　　　crit 致命的なエラー

　　　alert 緊急に対処すべきエラー

　　　emerg システムが落ちるような状態

※また、crit以上なら、呼び出し、それ未満はメール通知等のエスカレ判断に使用。

　●解析しやすように出力を工夫する事

　json形式にしておくなど後々解析しやすいようにな出力だと活用が楽になる。

　●時刻を正確に記す事

　特に、エラー対応時にどの処理がどのように発生したのか時系列で追うためにも、時刻を正確に整えておく事。

　（ntp/sntp、特にntpの方がより正確なんですかね）

　●5W1Hを意識して出力項目をととのえる事

　誰が、いつ、どこで、何を、どうしたのか、どのような処理かなど、そのログを見て目的とする事が可能ななのか確認する。

　●ログ保存期間を定める事（保存しきれないので、上書きする）

　法律対応、監査対応、ユーザからの問い合わせ対応などを考慮して、ログ保存期間を決定する。それに応じて、ログ保存期間を超えた古いログは破棄する、最新のログで上書きするローテションを行い、不必要にストレージを使用しない。

　●残してはいけないログを書かない事。

　個人情報など記載してはいけないログもある。設計に含まれていないか、本番稼働時に出力されていないか、確認する。

　●改ざんされない事

　ログをいいように改ざんされると攻撃者を検知できなくなるので、セキュリティを担保すること。

　※内部不正防止や監査としても必要ですね。

参考)Software Design 2014/08号

　　 Software Design 2020/07号

■まとめ   

　自分で一つ一つのシステムのログ設計を行う機会は、開発者以外は少ないと思いますが、後々に困らないように開発・運用側だけで設計してくれというのも負担が大きいので、ビジネスにも応用がきくように性能面を記録しておくとか、トラブル発生時に理由が説明できるようにさせておきたいなど、要望をつたえてそれを満たすしている設計かどうか確認する事がベターかなと思いました。

　勿論、これ以外の観点もあるかと思いますが、もし発注者側でログどうしますか？と問われた時や、質問ありますか？という時にログについても完全にお任せではなく、上記の考えで一緒によいシステムを開発できればと思います。

　※細かい所までつっこんでくるな～と敬遠されるかも・・・

【IT勉強】 オープンソースのリスク（ライセンス違反とセキュリティリスク）

　システム開発する際に、費用がからないオープンソース(OSS)を使ってコスト抑えられないか疑問がでてきました。無償で使用できるので、システム開発を大分安くできるかと思いました。

　結論として、私がオープンソースを担ぐなら、社内の新コンセプトの評価等、社外への責任がないシステムには使う。ソースコードも確認でき、「商用利用」に当らない？と思うのでライセンス違反にもならないからです。

　※時により厳しい使用条件や作成したソースコード公開義務もあるので注意。

　逆に、商用提供を行うサービスや止めてはいけないシステムの場合は、上記の公開義務、セキュリティ、問題発生時のサポートの必要性を考えると、この手の不安がない有償ソフトウェアを活用する方が無難だと考えます。

■備忘メモ

　●オープンソースの長短

　（長所）

　ーコストが低い

　ーソースコードが見れるので、【有スキル者】はカスタマイズや保守ができる

　ー特定のベンダーに依存しない

　　→ロックイン避けられるのは大きいですね。

　（短所）

　ーサポートがない（問い合わせ対応や廃りも早い事が多い）

　ーライセンス　※商用利用可否、ソースコードの公開義務等

　ーセキュリティ（低い傾向）

　　→全体の60%はセキュリティリスクが内在している恐れ。

　　　※有償ソフトは責任もあるので脆弱性をつぶしていると考えます。

xtech.nikkei.com

xtech.nikkei.com

■まとめ

　オープンソースは無償でソースコードも見れるので、セキュリティリスクが低い場面かつどんどんカスタマイズしたい時に活用したいです。例えば、社内の閉じた環境で、新コンセンプトがイケてるかどうか、確認するケースです。

　それ以外の時は、有償ソフトを活用した方が、セキュリティは（ある程度）担保され、トラブル時のサポート対応もうけられるので無難かと思います。

■Tips

　オープンソースのライセンス違反してないかどうか、一つ一つしっかり確認していく事が理想ですが思いますが、多く利用していると、ちゃんと規約を読み込んで、ライセンス関係を読みとくことは難しくなってきます。

　どこまで、頼れるかわかりませんが、オープンソースのライセンス違反や脆弱性を調査するソフトも売られているようです。

xtech.nikkei.com

　GPL違反やGPL汚染・・・複数のオープンソースが使用されている場合のライセンスは厳しい物が適用されるので、公開義務があるオープンソースを一つまぎれていた場合、全てを公開しないといけないです。

　ソースコードを公開したら、ライバル企業に真似されるなど、ライセンスは非常にシビアなので注意が必要ですね。

　※後々で言われると破綻するので、そんなリスク考えなら有償ソフトにしたいと思ってしまいますね。

【IT勉強】 バックアップやBCPの基準について（２拠点でよさそう）

　人の操作ミスや特定地域の被災により、システムダウンはこのご時世やむを得ない時があります。とはいえ、通常時はコストにしかならないバックアップにどこまでコストかけられるかという問題はあります。

　いろいろ事例を見てみて、現実的なライン、【メイン・スタンバイの２系統（東西で分ける）】を整理してみました。

■備忘メモ

　行政やインフラや有名サービスでもDR拠点は、２つや３つみたいですね。

なので、普通のサービスは２つで十分になるかと思います。

　サービス例）

　・全国銀行業界のシステム：「東京」と「大阪」

xtech.nikkei.com

　・奈良、兵庫、埼玉のDR設計。（おそらく２つ）

xtech.nikkei.com

　・Netflex:３つのリージョン

xtech.nikkei.com

■まとめ

　バックアップやBCPは大事なのは理解するが、じゃあどれだけやればいいのかという基準もないと思います。そこで、有名サービスや行政・インフラサービスを見てみましたが、多くて３拠点レベルかと思います。

　なら、普通のサービスは２拠点（距離が離れている、東京と大阪等）にあればいいと思います。

　※国まで分けると更によそさそうですが、遅延や海底ケーブル被災もあるので、２+１の１側の本当非常時くらいですかね。普段コストかけるのは厳しいので、一部のコア情報だけにするとより安心ですかね。

【IT勉強】 WEB広告の不正（最終的にはサービスへの問い合わせ数で評価か）

　前にインターネットによる広告は他媒体（TV・新聞等）よりも、初期コストが安く、ユーザのWEB滞在時間も伸びており、技術も進化している有力な広告手段と考えました。

　ただし、問題もあるようなので勉強しました。この問題自体を解決する根本的には手段ないのですが、広告をお願いする立場からすると、一定期間のお試しの上で信頼できる広告会社を見つけるしかないのかと思います。

■備忘メモ

　前提として、WEB広告はクリックされた数やサイトに掲載された数で広告主からお金をもらう方式が多いです。その上で、WEB広告には３つの問題がある。

　①不正なツール等によるクリック数の不正増加（アドフラウド）

　　→BOTによる不正な大量クリックでクリック数を増やす。

　②ユーザが事実上見えない所に掲載（ビューアビリティ問題）

　　→サイトの遥か下や広告が何枚もかぶっていて見えない・見られない。

　　　※でもサイト掲載されているので、広告主からお金をもらえる

　③ブランド価値を毀損するサイトへの広告掲示

　　→Aの物で起こした事故ニュースの横に、そのAと同じ物を掲載。

　　→サイト内容が狙っている客層と明らかに異なる

　　→不法に近い（グレー）なサイトに掲載。

　●対策の一つとして、「アドフラウド保険」

　保険会社が、広告の推移や閾値を評価して不正な時は、補填する。このサービスによって、広告代理店が保険にはいっておけば、その補填から依頼主に補填する。

　　（依頼主　⇔　広告代理店　⇔　保険会社）

　防げないなら、補填するは現実的ですね。

xtech.nikkei.com

■まとめ

　電子上だと悪用された時のパワーも大きいですね。広告をお願いする立場で考えれば、クリック数や表示数もそうですが、あくまで自社の製品に常識的に常駐してくれたユーザ数で評価したいですね。ただ、今度はユーザっぽくふるまう操作がでるかもしれないので、問い合わせ数までいれて広告評価としたいですね。

　こうなると、不正に確保しにくく、人がもつであろう、電話番号やBOTを十分に弾き、そのサービス（メールやSNS）はほぼ人の確率が高い連絡先に広告を打つサービスがあればそれをお願いしたいです。

　ただそれが難しいので、長期的に何社か広告をお願いして、高い結果を出してくれた複数社を見つけてそこにお願いしていく、こんなアプローチが現実的な行動ですかね。

　※この手のいたちごっこで消耗するのは本当に避けたいですが、無理ですよね・・・