Ｅｘｃｅｌ方眼紙がなぜ悪いのか、良くわからない・・・ごめん（＞＿＜！）

最近、Ｅｘｃｅｌ方眼紙が血祭りに上げられている

日経ウーマンが美文書「Excel方眼紙」特集、古傷を刺激された皆さんの叫び声が響きわたる
http://matome.naver.jp/odai/2136948486965928001

が、正直、どうしてＥｘｃｅｌ方眼紙が血祭りになるのか・・・正直、よくわからない。

---

データの再利用という観点から言うと、
Ｗｏｒｄの表で書かれるよりも、
方眼紙でかまわないからＥｘｃｅｌで書いてくれたほうが、再利用しやすい。

なぜなら、普通、データを抜くときは、マクロを書いて抜く。
そのため、Ｅｘｃｅｌだと、たとえ方眼紙でも、たとえどんなに升目が多くても、
セル位置内に文字があれば、
RangeやCellsで位置取得し、テキストを取ってこれる。
そうすれば、後はテキトーにつなげて、ＣＳＶにすれば、
ExcelでもRでもWekaでも、MySqlに入れるにしても、なんでもできる。

ところが、Ｗｏｒｄやパワポでかかれると、このデータを抜きにくい。
（Ｗｏｒｄのマクロはあるけど、該当する部分のデータを指し示しにくい）
テキストでも、構文解析しなきゃいけなくなると、
Ｅｘｃｅｌ方眼紙よりも大変。

ほんと、Ｅｘｃｅｌなら、方眼紙でも何でもありがたい！っていうかんじ。
そのために仕様書はＥｘｃｅｌで書かれる。
仕様書からデータを抜いてプログラム自動生成しやすくするために。

---

実際に、Ｅｘｃｅｌからデータ抜いて、プログラムを自動生成している人
とかでないと、XMLのほうがいいんじゃないか？と思うかもしれないが、
XMLは、大変なのだ・・・

ＸＭＬのＤｏｍの場合、getElementsByTagNameで、タグ名で値をとってくることになる。
このElementsってなっていることろが、面倒なのだ。
NodeListで入ってきてしまう。
なので、１つの値をとってくるのに、一呼吸はいる感じになる。
Ｅｘｃｅｌマクロのように、のりのりに書けないのだ。

---

ちょっと怖いのは、最近、みんながＥｘｃｅｌで書いてくれて、
やっとデータ分析、ビッグデータ解析とかの前処理が
ちょっと楽して自動化できそうになったのに、

文書はＷｏｒｄで書け！
ＴｅＸで書け！

とか、理由わからんこといって、
前処理の仕事を増やすことだけはやめてくれ。

批判する人は、こうやって、データぶっこ抜くと、
Ｅｘｃｅｌ方眼紙よりぶっこ抜き易いという方法論と
ともに、批判をして欲しい。

ＰＳ．
「Ｅｘｃｅｌ方眼紙を利用したＢｉｇＤａｔａ処理」っていう
シリーズ、面白そうだね（＾＾）ｖ

採用ビッグデータ＝「タレントマネジメント」＋「データ分析」

日経情報ストラテジー２０１３年７月号の１７ページに
「採用ビッグデータ」という言葉が出ている
優秀な従業員を採用するために、採用に関してデータ分析するもの。

はっきりとは書いていないが、実際にやることは、

現在、企業で優秀とされる人材のデータを解析して、
それを、採用時データと突き合わせることにより
どういう人を採用するべきか、どういう試験をするべきか

などを提案することでしょうね


今、などと書いたように、これ以外でも、利用価値があって、
あの部長は、顔で選んでいる！
なんていうのを、数値的に表現できたり、できなかったりです・・・

---

ということで、採用試験のデータだけでなく、
現在従業員の経験、能力データ（タレントマネジメント）
が必要で、これをデータ分析するということになります。

文書、音声、顔写真・全身写真・・・のイメージデータが無い限り、
ビッグデータにはならないかも・・・

ただ、今後期待される分野ではある。

社内派閥や愛人関係「も」記述できる、ソフトウェア工学手法

　プロジェクトの多くは失敗し、それは、要求が変化することだということは、
なんかコンセンサスが取れているようだ。
　ただここで、その要求の変化は、社会環境の変化か？といわれると、（学者さんはそう思っているかもしれないが、事実上は）必ずしもそうではない。

　会社内の派閥人事にソフト開発が巻き込まれたりするケースも、
　あったり、なかったりです。

　そうすると、システム開発を成功させるには、会社内の派閥関係を記述でき、どのへんの要求がどこからでてきて、どんなかんじで、権力者の意向が変わるか、権力者自体が変わるかが分析できないといけない。

　もちろん、フォーマルな派閥だけでなく、インフォーマルな、愛人関係、友人関係（中小企業等の社長間では重要）なども表現できないと、要求は、どこから横槍を入れられるか判らない。

　とすると、社内派閥などが記述できるソフトウェア工学手法があるか・・・

　ということなんだけど・・・

　・・　　i*かな、やっぱり。

---

　i*（読みは、i star,iスター、あいすたー）の書き方は


iStarQuickGuide
http://istar.rwth-aachen.de/tiki-index.php?page=iStarQuickGuide


にあるとおり。これのＳＤモデルは、
アクター間の
リソース、タスク、ゴール、ソフトゴール
に関する依存関係を書いている。

２人のアクターがいたとき（i*は、アクターを、役割だけでなく、個人、地位のカタチで書き分けられる。そして、地位と個人、役割の関係を「Actor Association Links」で細かく書き分けられる）、

その２人の間にある、ゴール、リソース、タスクの依存関係（アクターＡが、してほしいといい、アクターＢがそれを受け実行する関係）を示せる。

---

ということは、

　　　「これは、本来の使い方ではありませんが！！」

例えば愛人関係なら、こんなかんじで書ける

ＤはＤｅｐｅｎｄのＤみたいだけど、→の矢が膨らんでいるとみると、見やすい。
矢のもとのほう（Ｄのぼうのほう）は、Depender：依頼する人
矢のさきのほう（Ｄの丸いほう）は、Dependee：依頼される人、実行する人になる。

会社の派閥関係で、派閥のボスと、子飼い社員を書くと、こんなかんじ

ここで仕事１は、いろいろかわる。
手作業の業務だったり
システム開発プロジェクトだったり、
そのプロジェクトを妨害することだったり・・・

こうすると、同じ「システム開発プロジェクト」というタスクに対しても、
違った依存関係に成ることがわかる。

社長は利益を得る為、プロジェクトを社員に依頼する。
社員は企業に対しては、お金（給料）を得るためだが、
同じ社員が、派閥のボスに対しては、昇進上有利になることを期待(依頼）する
派閥のボスは、昇進を依頼されているが、
システム開発の成功は、会社から依頼されていない・・・こともありえる。

---

こうやって、企業の欲望を可視化することで、（欲求工学？）
企業の同床異夢の構造は記述できるのだが、
これからどう動くかの「社畜のダイナミズム」は、
まだ判っていない。

・・・論文も出ていないと思う

・・・ってか、たぶんでないと思う（＾＾；）

---

Ｐ．Ｓ

　何回も書きますが、i*は、こういうように、
応用ができるという話なだけで、
　一般には、i*を、こういうことには使いません！！

　ただ、こういうように、企業のどろどろした構造を、
可視化できるところに、ソフトウェア工学のおもしろさが
あると思います。

　あんまり、微分方程式や数理モデル、統計モデルで、
愛人関係とか、子飼いの部下とか、かけないよね！

RubyやCによるOpenFlowのオープンソースなプラットフォーム Trema

きのう、
SCSKのOSSユーザーのための勉強会で、

「OpenFlowプログラミングフレームワーク Trema」

を聞いてきた。

TremaはRubyやCによるOpenFlowのオープンソースなプラットフォーム。
ここのサイト

Trema
Full-Stack OpenFlow Framework in Ruby and C
http://trema.github.io/trema/

にソース、使い方などある。

それでは、以下、聞いてきたお話のメモメモ

---

（講師の自己紹介）

SDNとOpenflowとTremaの関係

SDNとOpenFlow
　SDN
　　・明確な定義がない
　　・ソフトウェアでネットワークを制御・管理する技術全般またはコンセプト
　OpenFlow
　　・Openflowの規約できまっているもの

OpenFlowとは
・今までスイッチでできなかったこと
・スイッチの集中管理

SDNの概略図例

NECビッグローブのSDN
・MPLS　Japan(2012/10）発表
・矛盾のない一括設定
・データセンター仮想化を実現するクラウドコントローラー

GoogleでのSDN
・Open Networking Summit(2012/4)で発表
・G-Scale全体の開き帯域を一括して管理するため
　　トラフィックエンジニアリングサーバー
　　SDNゲートウェイ
　　Openflowコントローラー

OpenflowとTremaの関係
・Tremaは実装のひとつ

主なフレームワーク
　Trema
　POX
　NOX
　Floodlight

Tremaの考え方
　OpenFlowプロトコルをフルに実装
　Ruby,Cで簡単に開発できるように
　簡単にテスト
　１台のパソコンで

Tremaを利用したときの開発のイメージ
　簡単に作成・試してみる

Trema
　　Openflowコントローラー向けライブラリ
　　ネットワークエミュレーター

Tremaはどう使われている
　　よくわかっていない
　　大学、企業の研究で
　　日本で使われている
　　導入例も

Tremaコミュニティ
　Trema塾
　とれま寺
　OpenFlow実践入門
　TremaDay
　メーリングリスト、その他
　Twitter
　個人のブログ

コミュニティに参加している人
　TremaでOpenflowをはじめるために
　rubyを勉強している人
　既存のネットワークでの課題を持っている人
　SDN関連の最新情報を抑えておきたい人
　上司からOpenFlowを導入できないかといわれて
　ネットワークで有名になりたい
　ネットワークプログラミング

話題
　Trema-Sharkというデバッグツールのインストール
　Openflow version1.3
　TremaのAPIの設計方針とツール
　SDNのノースバウンドAPIの定義
　TremaのRuby
　人生相談
　　　上司の説得方法

課題と今後
　　Tremaの現行版（Ver1.0に対応）
　　Trema-edge（Openflow１．３対応）
　　TremaApps

Tremaの現状の課題
　　・ユースケース（アプリケーション）が不足
　　　　情報が公開されていない
　　・OpenflowV1.3対応
　　　　接続性の確認
　　　　１．０と１．３の動きが違う
　　・SDNノースバウンドAPIや抽象化、モデル化

Tremaの今後
　　・TremaDayを続ける。次回は７月を予定
　　・OpenFlow１．３

TremaとOpenDaylightの関係
　すみわけとかない
　なんかしていくというはなしもない
　ぜんぜんわかってない