ios/Android/Windowsストアアプリのハイブリッド開発

デブサミ２０１４に行ってきた！シリーズ

２月１３日のC2セッション

ios/Android/Windowsストアアプリの
ハイブリッド開発における限界と可能性
日本IBM

をメモメモ

---

■スピーカー紹介
　２０１１　Android
　２０１２　HTML5＋CSS3
　２０１３　HTML5＋CSS3
　　　→ローカル、オフライン
　　　　ジオロケーションAPI
　ハイブリッド：いる

■いまハイブリッド開発基盤に関する相談が増加しています
・必要性
　　→AndroidとIOS：いるの？
　　　　→よのなかそうではない
　お客様ヒアリング重ねると、ハイブリッドが要件なことが多い
　　→複数アプリケーションが要件かも？
　　→BYODやりま～す！個人スマホを社内で・・・
　　→OSも端末も決まってないけど、とにかくやって！
　ネイティブの行き詰まり
　　重複管理、アップデートは？

　ユーザー、企画：新しいものを入れたい
　ITマネージャー：スキル・セキュリティ
　開発者：HTML5・ネイティブ
　→ステークホルダーのせめぎあい

■メッセージ
・サーバーサイドの資産がクライアントにシフト
　→ちゃらになってる新しく
・フロントエンドだけではだめ、
　バックエンド、セキュリティも
・ハイブリッド：イニシャルコストはかかるが、
　端末増えれば、生産性
　　→Windows8、サーフェス
　　　ChromeOS
　　→センサー

■フロントエンド開発の課題
　WebView／UIWebViewクラスの存在
　　Webブラウザ
　　アプリ内のブラウザ＝WebView
　　　　→HTML5と同じことが
　オフラインのときは？
　　→アプリケーション内に持ってくる
　　　Jasvascriptで書いて、オフライン

■OS and Native-Javascript Bridge
１WebとJavascriptに限定？
　　→既存コード、画面の再利用性は？
　　インターフェース部分をやっているのが
　　→Apache　CORDOVA
　　PhoneGAPとの違いは？
　　　　→もろもろのものを構築するかどうか
２Responsive Web Design(RWD)
　　単一のCSSで、メディアクエリーで分岐
　　Fluid Grid,Fluid　Image

IBM　Worklight　Studio
　→eclipseベース
　　　Android Studio XCode Visual Studio３つ＆共有
　OSSライブラリ
　　JQuery
　　Apache CordovaAPI
　　JQuery Mobile Dojo Sencha
　　Rhino Javascriptコンテナ
　　AngularJS BackboneJS Lo-Dash

　Mixed Hybrid Application
　　HTML5だけでがんばろうとしない
　　既存のコード再利用
　　Android4.0が境界線
　　リモートデバッガ
　　個別のデバッガ、ロガー
　マルチ開発対応のロガー
　サーバーへのクラッシュログ送信
　モバイルテスト自動化（実機もWebアプリも）
　MBaaS
　　ユーザー認証管理

■セキュリティの課題
　　オフラインデータ暗号化
　　デバイス紛失のサービス停止
　　　→MDM対象外のとき、アプリケーション単位でとめる

■Cordova(PhoneGap)とIBM Worklight

■まとめ
　MEAP（みーぷ）
　２０２０年まで、あと６年

■Developer Editionは無期限で無料
eclipse4.3.1のヘルプ、マーケットプレイス

JazzHub：リソースコード管理、クラウドIDS
IBM developerWorks

JavaからJavascriptへ！HTML5運用から見た次世代業務アプリケーション

デブサミ２０１４に行ってきた！
そのうちの２月１３日のD1セッション

をメモメモ

---

■朝はあいさつ

■自己紹介
佐川さん
@albatrosary
http://albatrosary.hateblo.jp
http://html5experts.jp/albatrosary

■HTML5が３０１４年に正式勧告
・エンタープライズ的には、今年盛り上がる？
・フロント業務アプリケーションに影響

■HTML/CSS/Javgascript
　アプリケーション開発環境も大きく変化
　　まだ、eclipseやSVN
　フロント開発の現場では、Java中心から
　　HTML/CSS/Javgascript中心へ

　※http://html5experts.jp/albatrosary/3191
　に今回話す内容あり

■Webの歴史
２０００年前後に動き
　　→HTML4.0の規格
　　　CSSも形ができてきたのが・・・
ここ数年大きく変わった
２０１１　CSS3
　XHTMLがなくなっている
　SPDY　HTTP2
　　→通信の技術的進歩
　　→かなり大きな影響（今後の話だが）

■Story
２０１２秋にHTML５業務アプリケーションを開発
２０１３年２月９日　HTML5CARNIVAL Fukuoka
　　Mozila Japanの浅井さんのFirefox OS
　　html5j白石さんのapplication cache
NTT Communivations 小松さんのSPDY WebSocket
２０１３年２月１８日　HTML5とか勉強会
　　白石さんにapplication cacheについて直接話を聞きに
２０１３年２月２３日　京都アジャイル勉強会
２０１３年４月２４日　Chrome＋HTML5　Developers　Live Japan＃４
　　村岡さん、GoogleによるYeomanハンズオン

■従来型のWebアプリケーション
　１．リクエストをサーバーへ送りControllerへ
　２．Controllerは必要な情報を
　　　POJO→Business Logic→O/Rマッパー→Database
　３．ページをJSPで生成し、こんとろーらー経由で

■次世代型のWebアプリ
　１．HTMLで生成された画面を表示
　２．必要な情報をAJAXで非同期にサーバー送信
　３．サーバーで受け取った情報をPOJOで
　４．クライアントで受け取り

■業務系システムは、今すぐ脱Strutsを
　次世代型のWebアプリケーションは次のような通信技術を使う
　　　JSON
　　　JAX-RS
　　　WebSocket
　http://gihyo.jp/news/report/2013/09/1901?page=2

■Single-page Application(SPA)とは
　　単一ページによるWebアプリケーション
　　ページはDOM操作により切り替える
　　サーバーは

■RIAに求められているもの
　　表現力の高さ
　　デスクトップアプリケーションと同等なUI
　　ユーザーエクスペリエンス

■RIAが・・・
　　２０１０年にJobsがFlashを激しく批判
　　プロプライエタリよりオープン性のあるHTML5
　　２０１１年SilverLight戦略を・・

■SPAに必要な技術
　　Javascriptフレームワーク
　　altJS
　　CSS　Preprocesser
　　開発環境
　　バックエンド技術－通信
　　バックエンド技術ーWebアプリケーションサーバー

■Javascriptフレームワーク
　Backbone.js
　Sencha
　AngularJS：最近聞く
（Kockout.jsも聞く）

JQuery：今まではよかった
　→すべてがJavascriptでかけますか？

■altJS
・altJSの言語の０多くはクラス機構のサポート
　→Javascriptお抱える問題の多くを解決

　coffeeScript 2009 http://coffeescript.org
　TypeScript 2012 http://typescriptlang.org/

納品したものが安全に

■CSS　プリプロセッサ
　膨大なCSSをどう整理するか

compass
less

■開発環境
yeoman（よーまん）
sencha cmd
git github

■Yeomanとは
・Googleが開発した総合解開発ツール
　　１．yoによる雛形作成
　 ２．grunt serverを使用し、アプリケーション開発
　　３．grunt buildによるビルド
　　※あとbowerがある

■バックエンド技術－通信
　Ajaxにおいて、XMLHttpRequestで非同期にJSON
　Webアプリケーションサーバー
　　　APIサーバーとしての役割

■SPAを構築する上で考えるべきこと
　　パフォーマンス
　　メモリーリーク
　　セキュリティ
　　フレームワークロックイン
　　設計思想の転換
　　フロントエンジニア不足
　　通信技術
　　バックエンド技術

■さらにHTML5
・通信
　　AJAX
　　WebSocket
　　SPDY

・バックエンド技術
　　WebSocketやSPDYをうまくコントロールする
　　Webアプリケーションサーバーが必要
　　　どうやってスケールするか

http;//html5experts.jp/albatrosary/4939

■SPAのメリット
・ページ遷移させてもJavascriptのグローバル環境が変わらない
・WebSocketが有効に使える

■SPAのデメリット
・フルOSSでの開発が必要
　　→自信なければSencha
・技術要素が多すぎる
・従来のWebアプリケーションに比べ、フロント開発が難しい

■最後に
　Java/RIA→Single Page Application
　　JSPはやめていい！！

■すぺしゃるさんくす
ぜのふぃー

デザイン思考やAppleのマウスで有名なIDEOさんの話を聞いてきた！

今回公開セミナー　知的資産経営新ビジネス塾は、デザイン思考で有名で、appleのマウスを作ったIDEOさんの東京オフィスの人のお話！

きいてきたあ！！

その内容を、メモメモ

---

IDEO（あいでお）さん
　１９９１年創業・パロアルト
　日本２０１１年にできる

EMBRACING CREATIVITY
・クリエイティビティをIDEOがどう捉えているか

■Who Is IDEO
・グローバルデザインコンサルタンシー
　　デザインシンキング（デザイン思考）
・シリコンバレーでマウスとか
・デザイン→IDEO自体でもかわっていった
・多様性を大事に
　　７カ国１１箇所に事務所６００人
　　→ただし、オフィス、場所にとらわれない
　バックグラウンドの多様性
　　心理、文化人類学、MBAも
　東京オフィス１０人
　　→他の人種も
　　　女性少ない
・幅広い仕事
　　分野、業界の多様さ

・デザインシンキングという言葉の意味を変えていった
　　ビジネスウィーク：The Power of Design
　　→イノベーションファームとして選ばれる

・ToyLAB
　　とにかく、おもちゃの開発
　　ELMO
・OpenIDEO
　　ユニリーバ
　　しっかり実現していく
　　プロセス

・Start up
　　ピルパック：IDEOの力を借りて
　　　→おくすりのパッケージング

IDEO Tokyoミッション
・日本の変化の触媒となる
　　Become a catalyst for change
　　方法論、マインドセット

■What is Design thinking
コアはデザインコンサルティング
　→デザインシンキング
もともとIDEOとして、
少ないリソースでインサイトを引っ張り出すか
　　→デザインシンキング

人からはじめる
→ビジネスとテクニカルから始める人が多い
→そうではなく、人からはじめる

自動車
　→もっと速い馬？ニーズ分からないとき

The Design Thinking Process
→いったりきたり、可変的プロセス
４ステップあるけど、かｗるかも
１．リサーチ
　　人がなに考えてる
２．シンセシス
　　まとめ
３．チャンス
　　アイデアを出す
４．プロトタイピング
→ストーリーテリング

観て
考えて
創って
伝える

■Shimano　の事例
＜＜目的：自転車の活性化＞＞
・リサーチ
　　エクストリームユーザーから聞く
　　　→コアユーザーは予測つく
　　お買い物、訪問、自転車ショップに不安そう
　　→インサイト

・ブレインストーム＆IDEATION
　　コースティング

・プロトタイピング
　　早いときにコストかけずにたたき台
　　　CGを形に
　　　売ってみる
　　　　→接客の人に化粧品のお店に行ってもらう

最終的には
　コースティング：
　IDEO,シマノ共同で協力を仰ぐ→サプライヤサイドから

■Air New Zealand
　モノだけではない
　→体験のデザイン
　アプローチ
　　そもそも、ニュージーランドって？
　飛行機で会話を楽しむ
　　プロトタイプをどんどん作っていく
　　　→ないな、あるながわかる
　　　→意外と出てくる情報
　　ねっころがれる
　ビジネスナイザー
　　　→ビジネスまで創りこみ
　　列を丸ごと買えるパッケージ

■Bank of America
・金融機関からの相談増えている
・デビッドカードの新規口座が減っているのを
　　盛り上げたい

・リサーチをかける
　　すぐにお金を払わなければいけないところって？
　ユーザーとご飯を食べる
　　端数は募金箱
　　切り上げ処理
　　小切手
　→端数の扱いが面白い
　貯金に苦労

・ブレスト＆IDEATION
　　エキスパートもブレストに：８０個から１２個

・プロトタイピング
　体験は見える化→漫画にするとか
　端数をどうするか

・プログラムKeep the Change
　デビッドカード：繰上げして自動的に端数はセービングへ
　→気がつくとセービングアカウントに・・・

・２５０万の新規、９３％が継続

モノのデザインから、体験のデザインへ

■P&G/
いいおきゃくさんだった
　　どういうふうにIDEOを創れるか？
　　現状維持が売上目標
　The GYM
　　既存の枠組みをはずして、コラボレート
　　コラボレーション→ファシリテーター重要


■サムソン
９５，６年ごろ戦略転換
→いきおいのってきた
パロアルトの隣に、はりつきで
デザインの捉え方が変わった
コンセプショナルな部分
　　液晶画面：デザイナーがサプライチェーンにも

■More About Design Thinking
・フェーズ１
　　マーケットリサーチ＋デザインリサーチ

デザインリサーチ
　インスピレーションを得るためのリサーチ

Individual emphasis
フォーカスは、個々の人たちのビヘイビア
→行動、ニーズに基づいたわけ型

自然な環境で
お互いに影響→本当のことをいえない
→家にいってインタビュー
　　→ギャップ

エクストリームユーザーを見ていく
子供、年配、手の不自由な人
　→子供の握り方

Empathic experience
病院
　　患者さん体験
　　患者さんが見ているのは・・・天井！

アナロガスインスピレーション
視野を広げる
ピットで観察
　　クルーはスパナを２つ持っている：落としたときのため
　　→類似性のあるところから学び

・フェーズ２　シンセシス
　パターン：類似性をみつける
　　→パズルを組み合わせていくかんじ
　暗中模索→新しいオポチュニティ：ブレストするための

・フェーズ３　ブレスト＆コンセプティング
　ブレインストーミングに７つのルール
　　　ぶっ飛んだアイデア→他の人のしげき
　　　すぐに判断するな
　　　視覚的
　　　他者のアイデアを広げる

・フェーズ４　プロトタイプ・ストーリーテーリング
　　美しさは追求しない
　　ものじゃない場合
　　感情移入はいらない
　　フィードバック大事→何を学べるか

■What is Business Design（ビジネスデザイン）
　デザインフォーム→ビジネスと切り分けてしまう
　　→IDEOはみんな一緒に（わいがや）
　ビジネス同様、正解は分からない
　　→何をよりどころに意思決定するか
　　→マインドセット

　日本の人：みんなしゃべらない、手を挙げない
　　→クライアントさんもいいアイデアある
　　→頭の中に：自分にブレーキ→そこをどうするか

　どれだけ高回転でまわせるか
　　→よく市場に出せたね
　　　　→でも４回くらいまわしていると、品質よくなる

　組織の中のビジネスデザイン
　　決済プロセス、どうドライブ
　　「もちはもちや」的
　　→カイゼンをベースにしている
　　　　→早い段階でよかったものが死んでしまう

■Things to remember in business design

（１）ビジネスは諸刃の刃
　　→やらない理由を考える天才
　　　アイデアを殺していないか？
　　→でも、ポジティブツールに使えることも

　　デザインシンキングの本質
　　　→イノベーションや新規事業のものさし
　　　　　　→どういうレンズで観ているか？
　　　　　　→新規事業が既存事業と同じPLでいい？

（２）型にはめこまない
　日本はフレームワークやプロセスにたよりがち
　フレームワークは意思決定ツールではない
　考えや視点を整理するツール

（３）先を見すぎることを恐れない
　　１０年くらい先の話ができるならシアワセ
　　　→もしそれができるなら、先のビジョンがあるということ
　　先にいくのを、引き伸ばすことはできる
　　アイデアのポートフォリオを戦略に落とし込む

■Today's　Take Aways？（今日持って帰ってほしいこと）
　クリエイティビティを発揮させるには？

　・Critical to Aspirational
　　（カルチャーの話）
　　他の人の刺激になること
　　ヒエラルキーがない

　・Fail early to Succeed sooner
　　　早く失敗したほうがいい

　・Look for questions not answer
　　　正しい問いかけの仕方
　　　　→正しくないとゴールも間違える

■Q&A
・仕事によって人が変わる
　　一緒に仕事をすると、マインドセット変わる
　　→そのあと持続できるか？

・話の内容は新しい話でない
　　→しかしやるのはむずかしい
　手法は既知、コンサルも「プロセスコンサルテーション」
　　（コンサルは２種類
　　　　コンテンツコンサルテーション
　　　　　　あなたはこうやるべきと報告書を出す
　　　　プロセスコンサルテーション
　　　　　　あなた自身を変えてしまう）
　なのに、IDEOにブランド力があるのは？

　　新しいタイプの人材→若さを保つ
　　相互学習をする相手
　　　→IDEOは仮説検証ではなく、探索学習

・依頼される部門
　　いろいろ、新規ビジネス、R&D、デザインはむしろ少ない
　　新人とか（＾＾）

・どこでマネタイズ
　　→気軽に遊びに来てもらう
　　もしこれで、大きなことをしたいなら、
　　　プロジェクトにする必要がある
　　→パートナー、友達、コラボレーターという感じ

・採用：人をみている
　　コラボレーションとフィードバック
　　会社：時間をくれる
　　過去は関係ない、入社時、ゼロスタート

・びっくりするくらい、マニュアルがない
　　でも、人間として、ドライバーが一緒
　　いい意味でミーハー
　　面白いことが生まれる興味

・IDEO：日本に
　　１回目　ふかざわなおき氏→撤退
　　２回目　地震の１０日前から
　１回目撤退の理由
　　１回目はプロダクトデザイン
　　　→IDEOとはちょっと違ったスタートだった
　　海外から日本に対する期待値が高い

・方法論
　　例：トヨタウェイ
　→そこに本質はあるのか？

・なぜ、アウトプットは単純になるの？
　→本当に面白いものは「そりゅあそうだよね」というのが多い
　　伝わらない、ささらない→アンカリングのキケン
　→何がうれしいのかはシンプル

「WindowsXPを安全快適に使い続けるための本」って・・・

売れるだろうけど・・・それでいいのか？
マイクロソフトさん的にはOKなの？


【画像】「WindowsXPを使い続ける本」 ←「バカがたくさんいるのが恐ろしい・・・」
http://sonicch.com/archives/36172515.html


または

https://twitter.com/r29_shirasagi/status/430965695216492544

線形計画問題の汎用ソルバーについて

きのうの授業で教わったことのうち
線形計画問題のソルバー関係のメモ
（一部追加）

---

■線形計画問題の汎用ソルバー
　定式化すればといてくれる
　　　　excel、
　　　　GLPK：フリーのソフト
　　　　cplex：ILOG社フランス人→IBM
　　　　GUROBI:CPLEXのスピンアウトメンバーが作った
　　　　NUOPT：数理システム、非線形につよい、ヒューリスティック

---

■Excelの場合

オプション→アドイン→ソルバーアドイン
・表を書く

具体的な方法


Ｅｘｃｅｌソルバーによる線形計画法の解法
http://www.kogures.com/hitoshi/webtext/or-lp-solver/index.html

---

■GLPKとlpフォーマット

GLPKは、以下のサイトからダウンロードできる

GLPK (GNU Linear Programming Kit)
http://www.gnu.org/software/glpk/


GLPKは、lpフォーマットで記述し、実行できる

　glpsol --lp example.lp


lpフォーマットにしておけば、ほかのソルバーでも使える
lpフォーマットについては、以下のサイト

http://p-www.iwate-pu.ac.jp/~takasima/cgi-bin/a-news/a-news.cgi?date=2004.08.07

の「● GLPKについて続き」を参照

---

　
■ダイエット問題

というLP問題がある。これを取り上げるとうける

---

派生開発のXDDPとかの話を、USDMの清水氏から聞いてきた！

昨日、リーンカンファレンス２０１４にいってきた。その中の講演の１つ「派生開発をリーンにするXDDP」をメモメモ
XDDPとUSDMの清水吉男氏ともう一人（だれだったっけ？）のかけあいの形で講演してました。

---

派生開発をリーンにするXDDP

■派生開発推進協議会（AFFORDD：あふぉーど)の紹介
　　２０１０年２月
・派生開発カンファレンス（次回６／６）
・１０テーマほどの研究会
　　・調整の克服方法
　　・USDMの入門
　　・XDDPの入門など
・研究会主催の「フォーラム」
・XDDPやUSDMに関する勉強会

■派生開発とは
・組み込みの現場では使われていた言葉
　　→改造（保守という言葉はつかわれなかった）
　　→既存のソースコードをベース
　　　機能追加が入る
　　　　→背景：競争＝予想できない→くずれていく
・派生どれくらい？
　組み込みの９０％以上は派生開発

・派生開発の課題とは？
　新規開発だと、工数と予算がつく
　でも、派生開発だと→変更＝納期がシビア
　　→変更行数で見積もられたら大変！
　要求仕様を書いて・・・
　　派生開発はそういううパターンではない
　　　　機能追加と変更がまじっている
　　　　変更のところで大きく
　　　　　→プロセスが合わない
　　新規開発くずし
　　　　変更箇所を完成させていく
　　　　　文章を完成させるように変更
　　ソースコードしかない会社
　　　　ソースコードをいきなり変更
　　→変更に対するデグレード：品質低下

・ソフトでリーンというと、アジャイル開発
　　XDDPとスクラムで発表されている
　　成果物が伴っていないと
　　変更という考え方がアジャイルでは対応しにくい

XDDPとは
・XDDP機能追加と変更依頼＝仕様知ってる人、国内にいない
　　→保守のプロセスではできない

・部分理解を前提としたレビュー中心の手法
　　→この方法でいける！
　　　ソースコードが分からないケースでも

・機能追加と変更を異なるプロセスで
　　AをBに変更→それいがいの箇所を探す
　　要求が異なる
　　変更３点セットの最小限の成果物を作る
　　　　変更箇所：Before→After
　　　　　Before：担当者の理解

・XDDP：コーディングをすぐしない

XDDPとリーン
・無駄をなくす
・品質を作りこむ

・知識を作り出す
　　AをBに直す→思わぬところに不具合＝わからない
　　　関係ないならバグでないはず！
　　　変更箇所を残している＝後ろから探れる
　　　→知識がたまる

・決定を遅らせる
　　いきなり変更：早く片付けたい→変更量を見積もっていない
　　　→変更同士が絡み合う：さっさと変更することが早くならない
　　　→１つの条件：見積もれている
　　　→生産性データを使う→ここまで遅らせるということがわかる

・似ている考えかた
　　手戻りを減らしたい
　　LAMDAプロセス→レビューを小さくまわす

ソフト
　　依存性が高い：XDDP
　　依存性が低い：アジャイル
ハード
　　依存性が高い：リーン製品開発
　　依存性が低い：リーン生産（TPS)

派生開発
　　変更してバグになった→ばんそこはってなおす
　　　→ソースコードは劣化している

レビュー
　変更要求仕様書：ここを、なぜ
　変更方法を考える：トレーサビリティマトリックス
　変更する
レビュアー：自分のシマにはいってしまう
トレーサビリティ　マトリックス（TM)
　原則、全部立てる。並べ方を変えない　

ソフトウェア開発を加速させるリーン開発の原則

昨日、リーンカンファレンス２０１４にいってきた。その中の講演の１つ「ソフトウェア開発を加速させるリーン開発の原則」をメモメモ

---

・リーン開発の原則
　ソフトウェア開発の現場で継続的な改善のきっかけを見つける視点を提供

・スピーカー：天野　勝　氏
　　これだけKPT（振り返りのときに使う）
　　日経コンピューターで連載

・会社
　　福井県にあるのが売り

・リーンソフトウェア開発とは
　リーンから、リーンソフトウェア開発へ
　リーンの日本語
　　　がりがり？
　　　贅肉を落とした（ほそまっちょ？）○

　リーンの起源
　　　トヨタ生産方式の研究
　　　TPSの家（出展「ザ　トヨタウェイ（上巻）」
　　　トヨタウェイ→ジャストインタイム、自働化

・リーン思考の原則
　　リーンシンキング
　　　製造、製品開発の原則：７つの原則
　　　→応用可能（金融業務、保険、医療）

・リーンソフトウェア開発
　　　日本だと２００５
　　　２００９年に本質 from concept to cash
　　　　→儲かるのが正義
　　　　　アイデアをいかにカネに変えるか

　ソフトウェア（ITサービス）の特徴
　　・開発のメインは設計
　　　　製造やデリバリーの開発／コストはわずか
　　　　　製造：コンパイルする、コピーする
　　　　　デリバリー：サーバーに配布する、利用者がサーバーにアクセスする

　　・リリース後の改修コストが低い
　　　　　回収は不要

　　・物理法則が及ばない
　　　　　重さ、大きさがない
　　　　　劣化しない
　　→製造の考え方は、そのままは通用しない

・リーン開発で重視する「品質」
　　品質の定義　SQuBOKから
　　　　→人の名前がはいっている（～がいった）
　　品質が高ければ儲かる：不具合があるかないかではない
　　余分な機能の無駄→まったく利用されない機能４５％

・リーン開発
　　言ったもん勝ち？
　　ニーズ→システム
　　　システム開発にはさまざまなリスクが潜んでいる

・ニーズに合う商品を提供するために
　　無駄を省いてニーズの獲得から商品提供をすばやく行う

・アジャイル開発
　　技術の総称：ひっくるめて！
　　アジャイルソフトウェア開発の誕生
　　　　→アジャイルソフトウェア開発宣言
　　AKB：事務所はちがうけど、同じ名前で
　　アジャイル：さまざま手法違うけど、同じ名前で

　　ポペンディック夫妻：この宣言の人ではない

　　アジャイルとリーンの関係
　　　図がある

・リーンソフトウェア開発の原則
（１）無駄をなくす
　　　ポペンディックさん「ソフトウェア７つの無駄」もかえている
　　　無駄に３つの種類
　　　　　お客さんの無駄：レビュー（レビューせずにいいものができれば）
　　　　→生産性があがる
　　　　　　組織の無駄を０にすれば、付加価値にあがる

　　　バリューストリームマップでプロセスの無駄を見る

（２）品質を作りこむ
　　作って直すのではなく、直さないように作る
　　→テスト駆動開発
　　　後で直すより、早く直せば安くつく

（３）知識を作り出す
　　学習サイクルをまわしながら進める
　　　　振り返り
　　　タイマー駆動／イベント駆動
　　　イテレーション内でPDCA

（４）決定を遅らせる
　決定を遅らせた分だけ知識が増え、ぎりぎりまで磨ける
　　　→ぎりぎりがどこまでか？
　　　→継続的インテグレーション　VS　ビッグバン結合
　　　　　モジュールを少しづつ足す

（５）早く提供する
　提供能力を上げる
　イテレーションからフローへ
　　　→カンバン、継続的デリバリーを自動で

（６）人を尊重する
　　ともに働く人
　　リーダーシップのあり方
　　　　支配型リーダーからサーバント型へ
　　見える化
　　　　異常を見えるようにし、行動を誘発する仕組み
　　　　カイゼンの道具で管理の道具ではない
　　タスクボード
　　KPT(けぷと）
　　バグレゴ
　　振り返り会で出た　「机を取り払う」を実行

（７）全体を最適化する
　　全体が滞りなく流れる
　　KANBAN＝タスクボード＋流量制限

　　システム開発からビジネス開発へ
　　　→ビジネスとシステムは一体

GSNとか、アシュアランスケースとか

昨日、KBSEの「アシュアランスケース超入門」を聞いてきた！
その内容をメモメモ

---

アシュアランスケース超入門

アシュアランスケース（AC)概要
AC研究課題
　プロセス開発
　言語設計・実装
AC超入門

・なぜACが必要なのか
　私たちを取り巻くシステム環境の変化
　　システムの大規模化
　　利害関係者の合意保証

・安全性、ディペンダビリティをどのように合意保証
　　１９８８年の北海油田事故
　　　→ACの提出義務付け
　従来は宣言的、これはゴール指向

・アシュアランスケース（AC)とは
　　システムが与えられた適用先と環境で
　　十分にディペンダブルであることを提供
　　する構造化された証拠ドキュメント

・ACの呼び方
　　日本語だと保証ケース
　　　ケース：証拠書類
　　安全性：Safety　Case
　　ディペンダビリティ；ディペンダビリティケース
　　　→ACは、全部を含めた言い方

・ACの背景
　　１９７４　一般的概要
　　１９８４　Seveso　Directive
　　　　　組織事故（日科技連）
　
・Safety　Caseの評価
　　肯定的：ゴールベースな規格認証
　　否定的：本当に効果的？Nancy Leveson

・ACとは何か
　　ゴール：システムは安全である
　　前提：ハザードリスト
　　議論の流れ
　　展開
　　テスト結果：確かな証拠
　　GSN

・ACとクリティカルシンキング
　　→トォールミン

・ACの研究課題

・ACプロセス開発
　　個別の規格認証のための方法はあるが・・
　　ACを行うことで、本当にシステムの安全性・
　　ディペンダビリティはあがるか？

・ACの実証実験
　　ACの評価→評価項目をどう作るの？

・ACの評価項目
　　プロセス品質
　　プロダクト品質

・効果：
　１．実施内容の確認
　２．成果物作成前の作業内容確認
　３．プロセス品質が達成されていることの検証
　４．プロダクト品質の証明→エビデンスで

・どこでやるのか？
　　要求分析のAC
　　　シナリオ分析
　　　モデルベース分析
　　　リスク分析

・ACのコスト

・目的が大切
・作成時に戦略を立てておかないと

・アシュアランスケースの記述法
　　→GSNパターン言語
　　→関数型言語では？
　　→D-Caseエディタ
・先行研究
　　定理証明器
　　パターン

・ＡＣ超入門
　　ＧＳＮ
　　ＣＡＥ

・表記法（７種類）
　　ゴール
　　戦略
　　前提（ガイド情報）
　　未達成
　　エビデンス
　　前提関係（ゴール、戦略と前提）
　　ゴール関係（ゴールと戦略）

・記述基本規則
　　ゴールはＳ＋Ｖの形をした命題
・戦略は、サブゴールに分割する議論の仕方
・前提：システム運用環境、定義
・前提ノードは文章ではなく、前提となるドキュメント
・証拠ノード

ＧＳＮの書き方
１）議論構造の図解
２）ドキュメントから作る方法
３）具体例
　　戦略で分割方法を示す場合は、
　　前提が上位ゴールか戦略にないといけない

リモート先でジョブが終わったときの戻り値と標準出力内容がほしいとき

以前、

リモート先でジョブが終わったかどうかを確認する
http://blog.goo.ne.jp/xmldtp/e/cbbdbadaae9c2c8eea8ed8b2ed3cb0dd

というのを書いた。

ここでは、結局
（１）SSHでバックグランドでジョブ起動
（２）動いているかどうか確認
（３）終了したら、データを取ってくる。
ということだった。

ここで、（１）について考えてみると、
たとえば、192.168.1.180から

　　ssh 192.168.1.192 /tmp/xmldtp 1234 &

を起動したとすると、
SSHコマンド実行の返り値は、/tmp/xmldtpを起動したことに対する
返り値であって、このxmldtp内で実行した処理に対する返り値は
わからない。

これらのxmldtp内部の処理の返り値と標準出力を受け取りたいというのが、
今日のお題

---

■お題
192.168.1.180から

　　ssh 192.168.1.192 /tmp/xmldtp 1234 &

を起動すると、192.168.1.192では、以下の/tmp/xmldtp内の
シェルが実行する。

touch "/tmp/job.txt"
/tmp/xmldtp1 > "/tmp/kekka1_.txt"
/tmp/xmldtp2 > "/tmp/kekka2_.txt"
cat "/tmp/kekka1_.txt" "/tmp/kekka2_.txt" > "/tmp/kekka.txt"
rm "/tmp/job.txt" "/tmp/kekka1_.txt" "/tmp/kekka2_.txt"

ここで、/tmp/xmldtp1、/tmp/xmldtp2の２つの処理を行っているが、
この返り値を取得し、それも/tmp/kekka$1.txtに入れて、返してほしい。

---

■２つの方法

返り値は、$?で取得できる。
このとき、大きく２つの方法が考えられる

（１）戻り値（$?）の値もファイルにechoで書き出し、
　　標準出力と共に、１つのファイルに書き出した後
　　不要な作業ファイルを削除する
　　　→すべてファイルに書き出す作戦

（２）バッククウォートで実行し、標準出力を変数に入れる
　　戻り値（＄？）の値も、何かの変数に入れる
　　これら変数をファイルに書き出す
　　　→すべて、変数に入れる作戦

これらの中間で、一部ファイル、一部変数に入れる形も考えられる。
が、今回はこの両極端を考える。

以下、スクリプトを記述する

---

■方法１：すべてファイルに書き出す作戦

こんなかんじ

touch "/tmp/job$1.txt"

/tmp/xmldtp1 > "/tmp/kekka1_$1.txt"

echo $? >  "/tmp/kekka3_$1.txt"

/tmp/xmldtp2 > "/tmp/kekka2_$1.txt"

echo $? >  "/tmp/kekka4_$1.txt"

cat "/tmp/kekka3_$1.txt" "/tmp/kekka1_$1.txt" "/tmp/kekka4_$1.txt" "/tmp/kekka2_$1.txt" > "/tmp/kekka$1.txt"

rm "/tmp/job$1.txt" "/tmp/kekka1_$1.txt" "/tmp/kekka2_$1.txt""/tmp/kekka3_$1.txt" "/tmp/kekka4_$1.txt"

まあ、説明は要らないだろう

---

■方法２：すべて変数に入れる作戦

こんなかんじ

touch "/tmp/job$1.txt"

job1out=`/tmp/xmldtp1`

job1ret=$?

job2out=`/tmp/xmldtp2`

job2ret=$?

echo $job1ret $job1out $job2ret $job2out > "/tmp/kekka$1.txt"

rm "/tmp/job$1.txt"

バッククウォートで実行（`/tmp/xmldtp1`）しているので、変数(job1out）
には、標準出力値が入る。
$?も変数にいれ、それらをまとめて書き出している。

はじめに作業ファイルを作るので（起動していることを示すため）
これを削除しているが、標準出力と戻り値に関しては、変数にいれ、
これらをファイル書き出ししていない。

---

■比較

ファイルを使わないので、削除し忘れの無い、方法２のほうが、
一見良いように見える。
しかし、方法２は変数に入れるため、大量のデータが変数領域に
はいることになる。これが、よいかどうか・・・

が問題になる。変数にいれるのがよろしくないとなると、
方法１になる。

Rでファジイ・クラスタリング

Rでnnetを使って、ニューラルネットワーク
http://blog.goo.ne.jp/xmldtp/e/30de99f0e8da5c8b5e91ae8523533b45

の授業、そのあと発表した人は、Rでファジイクラスタリングを
やっていたので、その内容もメモメモ

---

クリスプなクラスタリング　k-Means法

ファジークラスタリングのコンセプト
　クリスプなクラスタの問題点
　　　データはどれか１個のクラスタに属する：現実にはきれいにいかない？
　　　はずれ値の影響を受けやすい
　コンセプト
　　　複数のクラスタに属してよい
　　　クラスタに属している程度をメンバーシップ
　　　メンバーシップは中心点からのユークリッド距離

Fuzzy c-Means法
＜＜方法＞＞
・クラスタの中心点の初期値ｃ個をデータ範囲の中からランダムに設定
・各データ点の各クラスターへのメンバーシップを計算
・クラスターの重心を再計算して、新たな中心点
・中心点が収束するまでステップ２以降を繰り返す

＜＜Rでのやりかた＞＞
・パッケージe1071（ファジークラスタリング）、mlbench(データ用）を使う
・末尾にかいておきました

fuzzificationパラメタ＝１だと、クリスプ、１に近いほうがきっちり

＜＜問題点＞＞
・はずれ値の影響は受けやすい
・クラスタ数を間違えると・・・
・単位に依存→標準化（無次元化）
・楕円のクラスタは検出しずらい

クラスタ数の推定
・中心点の距離を見る
・事前分析による方法

Fuzzy　Adaptive Clustering
・メンバーシップの合計が各データ点で１という制約を緩める
・メンバーシップの計算式がちがう

クラスター＝予測ルールと読み替えられる→予測幅は？
・各クラスタについて標準誤差を算出
・Dispersion rate(標準誤差と最大値～最小値の比率）を算出
・中心のファジー数を算出

＜＜Rでのサンプル＞＞
※パッケージe1071（ファジークラスタリング）、mlbench(データ用）を
　　インストールしておいてください。


library(e1071)
library(mlbench)
p1<-mlbench.corners(100,d=2,sd=0.2)
p2<-mlbench.corners(100,d=2,sd=0.5)
x1<-p1$x
x2<-p2$x
n_cl<-4
cl1k<-kmeans(x1,n_cl,nstart=10)
cl2k<-kmeans(x2,n_cl,nstart=10)
cl1c2<-cmeans(x1,n_cl,iter.max=100,verbose=FALSE,dist="euclidean",method="cmeans",m=2,rate.par=NULL)
cl2c2<-cmeans(x2,n_cl,iter.max=100,verbose=FALSE,dist="euclidean",method="cmeans",m=2,rate.par=NULL)
cl1c5<-cmeans(x1,n_cl,iter.max=100,verbose=FALSE,dist="euclidean",method="cmeans",m=5,rate.par=NULL)
cl2c5<-cmeans(x2,n_cl,iter.max=100,verbose=FALSE,dist="euclidean",method="cmeans",m=5,rate.par=NULL)
par(mfrow=c(2,4))
plot(p1,main="test data")
plot(x1,col=cl1k$cluster,main="k-means")
plot(x1,col=cl1c2$cluster,main="c-means m=2")
plot(x1,col=cl1c5$cluster,main="c-means m=5")
plot(p2,main="test data")
plot(x2,col=cl2k$cluster,main="k-means")
plot(x2,col=cl2c2$cluster,main="c-means m=2")
plot(x2,col=cl2c5$cluster,main="c-means m=5")

＜＜結果＞＞

要求の形式言語Event-Bから、FPGA等で利用するVHDLに変換するプラグインEHDL その2

前に

要求の形式言語Event-Bから、FPGA等で利用するVHDLに変換するプラグインEHDL
http://blog.goo.ne.jp/xmldtp/e/b7184bb4d994d365ae8cc1380494ac04

を書いたとき、エラーダイアログが出て終わっていた。

今回は、そのエラーダイアログが出た原因についてと
FPGAへのつなぎ概要

---

■原因

コンテキストを作っていたから。
コンスタントを何も使ってないのに、コンテキストを使っていたのが
原因らしい。

コンテキストを削除し、
マシンだけにして、
マシンのSeeを削除

プロジェクトを選択して、メニューCode generation menu

Generate VHDL code without library compornents
をクリックすると

と保存先フォルダを聞いてくるので、適当に入れると
（すでにファイルがある場合、上書きしていいか聞いてくる。それに答えると）
最終的に

なダイアログができて、マシン名でvhdlファイルができる

---

■FPGAへのつなぎ概要

ごめん、アルテラしかわかんないし、今、CyclonⅢが手元にあるので、
それで説明。

QuartusⅡを立ち上げ、
新規プロジェクトを作成。
　　このとき、作成したVHDLファイルを読み込み。
　難しい問題に巻き込まれたくないので、
　プロジェクト名、その他もろもろはマシン名と同じM1にした。

そしたら、コンパイル→通る。

　ピン配置をして
　　　LED1_O　PIN_J1
　　　SW1_I PIN_F1

コンパイルをもう一度（フィッティングなども行う）

プログラマーを使って、sofファイルをFPGAに送り込むと・・・


・・・動かない（＞＿＜！）

がプログラムを書き換え、SW_OFFのときもSW_ONのときも
常にLED1_Oが１（TRUE)になるように書き換えたら、
付きっぱなしになった。

---

ということで、流れ的には、これでよさそう。
あとは、プログラミング内容だね・・・

FPGAの品質向上

11月２１日のET2013で聴いてきた話の続き

永遠の課題FPGAの品質向上の扉を開く！
実機デバッグの限界を解決するノウハウを教えます。
CMエンジニアリング（株）

の内容をメモメモ

---

はじめに
　会社紹介
　　検証サービス
　　仕様書からRTL自動生成ツール

FPGA設計品質向上のコツを教えます
・セミナー受講者の興味範囲
　　仕様書・検証項目に興味あり
　　テストベンチ・CDC検証に興味あり

・FPGAユーザーの声
　仕様書を書く暇はない
　　仕様は頭の中、個人資料しかない
　　　→ドキュメントの重要性は認識している

　シミュレーションに費やす時間ははい
　　実機検証で何とかなる
　　テストベンチ設計が難しい

　非同期回路の対策が明確になってない
　　非同期の真の問題点を理解していない
　　非同期設計、検証方法が確立されていない

　アサーションなどの最新手法導入の壁が高い
　　シミュレーターがサポートしていない
　　　最新手法がどんなものがあるかわからない

FPGA品質向上への問題解決の鍵
　FPGAの３つの課題
　　機能の複雑化
　　検証ボリューム増大
　　FPGA早期完動
　・シミュレーションと実機検証の併用
　・個人スキルからの脱却
　・非同期回路設計・検証手法の確立
　　→FPGA品質向上へ問題解決の鍵

品質問題事例

初期品質問題
　シミュレーションの役割
　　　シミュレーションの活用
　画像、映像系の各パラメーター
　　　設定パラメーター
　　　タイミングパラメーター
　　　画像データパラメータ
　各パラメータの振りを実機検証ですべて行うのは難しい

コーナーケース検証もれ
　　検証漏れ：検証すべき項目が挙がっていない
　　３大要因
　　　１．仕様の解釈を誤っていた
　　　２．検証項目からもれていた
　　　３．検証項目としてあがっていたが、実行していなかった
　　→仕様書の重要性

非同期回路の設計ミス
・シミュレーションも実機検証も問題なかったのに
　　→出荷後に発覚するケース
　　　メタ・ステーブルの問題：FF２段
　　でできないもの
　　　リコンバージェンスの問題
　　　データの取りこぼし問題
　→非同期回路の真の問題点を理解しよう

何をする

シミュレーションと実機検証の役割分担
シミュレーション得意
　　詳細な検証
　　ブロック単位での検証
　部分的、詳細、例外的な検証に向き、変更後の対応、確認もしやすい
実機検証
　　長時間検証
　　外部デバイスとの検証
　　ソフトウェアとの検証
　　システム検証
　外部デバイスとの長時間検証、ソフトウェアを含めたシステム検証にむいている

シミュレーションと実機検証の役割分担
シミュレーション：各設定パラメータ振り、組み合わせ
実機検証：ユースケースのシステム動作

テストベンチの基本構成の確立
　テストベンチを独立した部品と考え、再利用

チェックの自動化
　目視確認時の見落としなどのミスを低減することで
　品質が大幅に向上
　　　データチェック
　　　タイミング：アサーションチェック
アサーション適用
　　PSL,SVAを使いたいが、シミュレーターが対応していない
　　→OVLの導入
　　検証済みチェックIP

仕様書の重要性
１．回路の大規模化、短TAT化

仕様書を作成する上での３つの視点
　１．設計者の視点
　２．第三者の視点
　３．検証者の視点
　　　動作条件、競合、
ドキュメント記述ルール
用語集
非同期回路設計
　　D-^FF同期化
　　MUX同期化
　　ハンドシェーク
　　FIFO
検証戦略
　　ダイナミック検証
　　フォーマル検証
　　IPのため検証しない
まとめ
１．シミュレーションと実機検証の併用
２．仕様書の重要性を理解
３．非同期設計、検証手法の確立

設計レス・設計／検証自動化
（あとはすぺっくいんさいとのせんでん）

---

このあと、Microsoft conference 2013に行きました。

トレーサビリティのあるテスト項目と、その限界

テスト項目は、

・仕様書の内容Xテスト観点Xバラエティー

で規定される。たとえば、

画面設計書に
・受注検索・一覧画面
・受注詳細・入力画面
・商品検索・一覧画面
・商品詳細・入力画面
　　：
　　：
と画面があったとして、

画面のテスト観点として、
・初期入力画面
・項目入力チェック
　　選択　＝　選択できるか
　　複数選択＝　単一選択
　　　　　　　／複数選択
　　　　　　　／未入力
　　整数入力＝数字チェック
　　　　　　　境界値
　　　　　　　範囲外
　　　：
などとあった場合、

　受注検索・一覧画面X初期入力画面
　受注検索・一覧画面X（選択：選択できるか）
　　　　：
　受注詳細・入力画面X初期入力画面
　受注詳細・入力画面X（選択：選択できるか）
　　　　：

というように、

　　仕様書（画面）Xテスト観点

　の組み合わせとなる。もちろん、画面によっては、選択するものがない、入力するものがない等、テスト観点が該当しないものがあるので、これは行わない。

　また、境界値が２つ、３つある場合があるので、それはXバラエティとして、それぞれのケースを行うことになる。

---

　ここで、仕様書は、そこに書かれた機能を確認することになる。
　したがって、機能要件であることが多い。

　テスト観点は、テスト項目全般に関わること（非機能）になってくるため、
　　　　各種項目・画面等で守るべきこと
　　　　非機能要求
　などが、観点として挙げられることになってくる。

---

　よって、
　　　機能仕様X（守るべきこと＋非機能）
　に関しては、トレーサビリティが取れる。

　しかし、ここで問題となるのは、機能仕様の範囲だ。
　一般には、ビジネスモデルが機能仕様にあたるが、
　それだけだと、通信エラーのときの手順とかはどうなるの？
となる（通信エラーはビジネスじゃないだろう・・・）

　で、ここで問題になる。
　　　通信エラー
　　　ハードディスク障害
　などは、仕様書にかかれる。だから仕様書に書かれたとこだけ
調べればよいとなると、テスト範囲は狭まる。
　本来、通信エラー、ハードディスク障害はどこでも起きることなので、
テスト観点に含めて、すべての状況で確認すべきだ・・

---

　まあ、そこまでやるかどうかは別として、
　いいたいことは、
　ビジネスモデルをベースに機能を出し、

　　その機能Xテスト観点

　とやると、トレーサビリティは取れるが、ハードに依存した部分の障害（通信、メモリなど）が抜ける可能性が出てくる。

と、いうことだ。

要求の形式言語Event-Bから、FPGA等で利用するVHDLに変換するプラグインEHDL

要求仕様などに使う形式言語Event-Bについては、ここで
いろいろ書いてきたけど、このEvent-Bから、
FPGA等で利用するハードウェア記述言語VHDLに変換する
eclipseプラグインがあるらしい。

EHDLといいます。

EHDL - the plugin that enables VHDL code generation from Event-B models
http://www.eventb-to-vhdl.tk/


今回は、インストールしてみたんだけど、うまく行かないというところまでと、
参考文献として、Event-B→VHDL変換が書かれている論文について（まだ読んでない）

---

■Event-B→VHDL変換プラグインEHDLのインストール

まずは、eclipseをたちあげ、普通の新規プラグインの
インストールと同じように

を選択して、

というダイアログが出てきたら、addをクリック

Locationに

http://www.eventb-to-vhdl.tk/

と入力します。

ってかんじになるので、EHDLを選択

NEXT

I accept ・・・のほうを選んで、Finish

となって、インストールがはじまり、

となったら、OK

最終的に

がでてきたら、Restart Nowで再起動。

---

■うまくいかない・・・

マシーンとコンテキストをつくって、
プロジェクトを選択して、

Generate VHDL code without library compornents
をクリックすると、

というエラーダイアログが出る。
だけど、下のほう

Generate VHDL code with library compornents
や、EHDLと灰色の中に緑色で書いてあるボタンを
クリックすると、なにも起きないようにみえる・・・

う～ん、どうやったら、ソースが書き出せるんだ？？

---

■参考文献
１．
VHDL Code Generation from Formal Event-B Models


２．
Generation of Structural VHDL Code with Library Components from Formal Event-B Models

ってことは、UIをデザイナーさんに作ってもらったほうが安い？

デザイナーが動いて、ホームページって、いくらが相場
http://blog.goo.ne.jp/xmldtp/e/4fd6db23230ac81e48842fbf9f1c692e

と、

イマドキの１人月単価は、いくらが妥当なのか？
http://blog.goo.ne.jp/xmldtp/e/ecea12c3aa49fe1a325568da8d330221

を合わせて考えると、
　　Webのページデザインを、デザイナーに発注し、
　　そのデザイン内容を貼りこんで、UI設計書を作ったほうが
安いっていうことになっちゃうんだよね。
ここでいうWebシステムっていうのは、B2CとかB2Bだけでなく、
社内で使う、バックオフィスの社内システムですら・・・

---

たとえば、画面４０個あるシステムがあったとすると、

基本費用１５万＋ページ単価：４０＊１万円＝５５万

デザイナーだと５５万で、画面（固定だけど）作ってくれる。
UI設計書に貼り込むだけなら動かなくていい。
その上、HTMLで書かれているので、後工程でそれがそのまま利用できる。
Javascriptも入れてもらえば、お客さんにプロトタイプもできる。

それで、５５万。

SE頼むと、たぶん、UI設計４０画面は１人月ではできない。
（１画面半日（１日２画面）、１ヶ月（＝２０日）として、１人月ぴったし
　ちょっと、きついかな・・・）
で、そのSEの１人月単価は７０万。

---

実際のデザイン単価と、SEの単価でびみょーなところだけど、
見栄え重視なら、UIのプロト段階はデザイナーに頼んで、
UI設計書はそれをそのまま貼って、

サーバーサイドをSEさんが作るほうが、安上がりだし、
いいものができそうだよね。

---

さらに、最近のデザイナーはJQueryを使える人もいる。
そうすると、(JQueryで）Ajaxもできるので、
サーバーサイドにダミーのwebサービスを置いて
（ダミーの処理結果ファイルをサーバーにおいておく）
デザイナーさんにAjaxでそのダミーをアクセスしてもらう
ようにすれば、まさにサーバーサイド部分だけを
SEが作ればいいことになる。

こうするとたぶん、オフショアよりも安くなるんじゃないかなあ・・・