そもそも、プライベートクラウドを使うケースを考える

　最近、プライベートクラウドに関して非難する意見が多い。
　(こことか）

　ただ、それを言ってるのが、研究者の人たちなどで、具体的にシステムを考えると？？？の場合があるので、

　もうちょっとシステム的に具体的な話にしてみる。頭の体操。

　で、その上で、論点をまとめてみよう。

---

■プライベートクラウドを使う具体的ケース

　A社は、全国に多数の販売店を持つ小売業である。
　移動販売等も行っているため、専用線を引くことはできない。
　各店舗において、数個のレジ（POS端末）があり、各レジとも、１分間に数件の清算処理をする
　（ってことは、スーパーか　＾＾；）

　A社ではこのたび、リアルタイムの売上管理、物流管理を行いたいとする。
　販売数量に応じて、本社バイヤーが一括的に発注、各物流センターから配送を行う。
　また本社では、BIツールを使って、売上分析を行う。

　A社は、成長中の企業であり（そんな企業はあるのか　＾＾？－ここ、重要な論点！）
　規模において、柔軟性が必要だとする。
　その場合、どのようなソリューションが考えられるか？

---

■要件のまとめ

＜＜トランザクション＞＞
売上関係
　１分間のトランザクション＝１分間数件の売上データXPOS数X店舗数
　→小さいデータが頻繁に発生する。ただし、アップロード

分析
　大量データ。ただし、急がない。不定期

バイヤーの発注データ？
　システム分けるべき？

＜＜接続＞＞
移動販売アリ
　専用線引けない
　通信で接続する必要アリ

＜＜レスポンス＞＞
一定のレスポンスは必要

＜＜その他＞＞
会社拡張のため、クラウド必要

※小売業に限らず、データ観測するようなものや、製造業で全国に広がる機械の状況を判断するには、
　このようなケースがおおい

---

■ソリューション

　移動販売については、専用線は引けないので、方法は２とおり

　　　・インターネット回線を使う
　　　・KDDIのDODのようなサービス

　インターネット回線の場合、パブリッククラウドを使うという手も考えられるが、レスポンスタイムが保障できるか分からないので、KDDIのDODサービスを使い、auデータ通信などでアクセスサーバー→社内サーバーに送ることとする。

　(移動店舗以外の）他店舗は、DODサービスを利用してもいいけど、インターネットを利用してもいい。

　そして、拡張性を出すために、社内サーバーをクラウドにする＝プライベートクラウドになる。

---

■論点

　結局、プライベートクラウドになった理由は、以下の１点

・インターネット回線＋パブリッククラウドで、レスポンスが保障できるのか？
　　プライベートクラウドのほうが、レスポンスがよくないか？

このほかに・・・

・電力的に考えると・・・
　電気はすでに、東京電力によって、クラウド化されている
　　(どこの発電所で発電したか分からない形で供給される）
　それを直接利用したほうが、Amazonなどパブリッククラウドで消費する電力量を、Amazonに払う利用料という形で負担するより、安くないか？

　パブリッククラウドの電力は、平均化された金額になる。
　プライベートクラウドなら、東京電力から供給される夜間電力をためておいて利用し、
　さらに足りない部分を、自社発電（工場・店舗の廃熱等を利用）したものを利用したほうが安くないか？

・仮想化の技術者をやとったり、合併したら、技術者の問題は解決できないのか？
　パブリッククラウドを利用するのは大手企業、大手企業なら、技術のある会社を買収しちゃえばいい。
　そこまで行かなくても、技術提携を結んだり、２４時間サポートは可能だろう・・・

・費用的にどっちが安いのか？
　本当にパブリッククラウドのほうが安い？

そしてそもそも、さっきも書いたけど・・・

・この不況下、規模拡大ってあるのか？
　なければ、スケールする意味がない。

(追加：１５：４０）
あ、後この論点もあった。忘れないようにメモメモ

・PaaSの場合、プラットフォームをアップデートされる危険はないか？
　パブリッククラウドでPaaSの場合、もし、プラットフォームをアップデートされて
　動かなくなったら、対応しないといけない
　　　→急にアップデートされるリスクがある。どこが変わったのかも分からない。
　機能が良くなるわけではない場合、この対応は、コストになる


　　　　

---

　ざっとこんなところかしら、具体的に考えると・・・

　別の機会に、会員制クラウド？の具体的なシステムと論点について考えてみたいと思います。

Excelに業務をまとめ、プログラムを自動生成する－その9 画面定義書(2) 作り方

　シリーズ「Excelに業務をまとめ、プログラムを自動生成する」の続きです。

　前回から、画面定義書の話を書いています。今回は、作り方についてです。

---

■画面の作成に関して

　まず、画面定義書を書くということは、画面の設計をすることになるのですが、画面の設計方法は、

（１）画面の共通概観などを決め
　　　→メニューとか、３つに分けるとか、パンくずつけるとか。。。

はいいのですが、ここからさき・・・

（２－１）出力内容から、こーいうデータ入力が必要だから、こーいう画面が必要だと割り出し、
　　　　　画面を決めていく

という方法と

（２－２）業務流れ図から、入力画面は分かっているので、とりあえず、そこから考える

という方法の２種類が考えられます（実際には両方のケースがある）

　後者のほうは、とくに、記入シート、申請書などがある場合や既存のシステムがある場合に有効です。
　その場合、入力すべきものが分かっているので、それを画面にしていきます。

　どっちにしろ、画面がきまってきたら・・・

（３）HTMLでその画面を作成する。
　　　　→ハードコピーをとって、画面レイアウトへ

（４）その画面の入出力項目（出力の場合、可変項目）を抜き出し、画面項目定義を埋めていきます
　　　　→型定義などは必要

（５）その画面のイベント（ボタンクリックなど）をチェックし、
　　　他の画面に遷移する場合、画面の行き先を確認し、
　　　画面遷移図にまとめます。

ってな感じの流れになります。

---

■電波利用の場合

　では、いつものサンプル、電波利用の場合で考えてみたいと思います。
　
（１）画面の共通概観などを決め

　ログイン→メインメニュー→各業務に流れるようにし、画面分割とかはしないことにします（装飾は特にナシ）
　各業務とは、
　　　・免許の申請
　　　・免許の審査
　　　・工事落成の届出
　　　・落成結果入力
　　　・バッチ起動
　　　・マスタ入力
　のことです。ログイン時、その人の権限（申請者、総合通信局、管理者）によって、メニューで表示される業務が変わるものとします（その人の権限でできるもののみ表示）

（２）画面を決めていく

　今回は、すでに申請書があるので、（２－２）のように、業務流れ図から考えます。

　今回の対象は、「免許の申請」とします。
　免許の申請は、
無線局免許手続様式
http://www.tele.soumu.go.jp/j/download/proc/index.htm
にあるように、
　　１．無線局免許申請書
　　２．無線局事項書
　　３．工事設計書
にわかれます。

さらに、開局する区分ごとに用紙が違います。ということは画面も変わります。

　このように、条件によって画面が違うような場合は、その画面を表示する前に(前画面または上部）、
　画面を表示するための条件を聞くところがあり、それに基づき表示することになります。

　今回の場合、
　　「無線局免許申請書」を表示する前、メニューで４種類の切り替えを行い
　　「無線局事項書」を表示する前、「無線局免許申請書」で、それぞれの区分を聞くことになりますが、

こうしちゃうと、「無線局免許申請書」を選ぶのが、ものすごーく難しくなってしまいます。
　結局、「区分」と、「免許／再免許」の２種類の情報が分かれば、画面は選べるので、

　メニューで、この「区分」と、「免許／再免許」を入力することとします。

---

　ここからさきの話は、長くなるので、今回はここまで。