EAIツール

今日は会社に行き、Web-Pressを読みながら、のんびり!と思って
いましたが、すぐに仕事が来ます。おまけに、2つも。。。



その中で、EAIの製品の評価という仕事があります。
CORBA-EAI-SOAという流れがありますが、先にSOAのプロジェクトに
参加した事もあり、EAIについては正直な所、概念しか理解せず、
製品を調査する事が初めてです。



HUFLTのようなイメージを持っていましたが、全く異なりました。
EAI製品はGUIを使い、マッシュアップを実行するというのが
私なりの結論です。
つまり、IN/OUTに該当するデータはGUIで定義し、ファイル名を
指定さえすれば、取込・出力が可能になり、取得したデータを
変換したり、結合したり、という部分もGUIの画面でDrag&Drop
From/Toを定義する事で全て完了になります(マッピング)。

ここ

ここも



ノンコーディングで全て可能です。但し、OSSではない、
という点が。おまけに値段が高いです。海外の製品ですと、OSS
同様の事が可能な製品はあります。しかし、運用する人が
日本人なので、日本のEAIの製品を選択するしかないでしょうね。

今日は会社に行き、Web-Pressを読みながら、のんびり!と思って
いましたが、すぐに仕事が来ます。おまけに、2つも。。。



その中で、EAIの製品の評価という仕事があります。
CORBA-EAI-SOAという流れがありますが、先にSOAのプロジェクトに
参加した事もあり、EAIについては正直な所、概念しか理解せず、
製品を調査する事が初めてです。



HUFLTのようなイメージを持っていましたが、全く異なりました。
EAI製品はGUIを使い、マッシュアップを実行するというのが
私の調査した結果です。
つまり、IN/OUTに該当するデータはGUIで定義し、ファイル名を
指定さえすれば、取込・出力が可能になり、取得したデータを
変換したり、結合したり、という部分もGUIの画面でDrag&Drop
From/Toを定義する事で全て完了になります(マッピング)。



ここ



ここも



ノンコーディングで全て可能です。但し、OSSではない、
という点が。おまけに値段が高いです。海外の製品ですと、OSS
同様の事が可能な製品はあります。しかし、運用する人が
日本人なので、日本のEAIの製品を選択するしかないでしょうね。



大量のデータを処理する事を想定して、スケールアウトの準備が
必要になります。処理するサーバーにはVMWareをインストールして
おくと、大量のデータにも対応する事ができると思います。
恐らく両方の製品共に、仮想化には対応していると思いますので。



どちらの製品がよいのか、という点については業務で必要な変換が
対応しているか否か、という点になると思います。ここは業務都合で。

今月は忙しい

理由はよく分からないですが、今月は異常に忙しい。
Googleカレンダーを普段は使用していますが、今見ていたら、週に1回はイベントがある。。。
暇で暇で何もする事がない!という状態よりは、何かしら対応しないといけない事がある方が
恵まれていると思っています。無理をしない程度にがんばります!!!



PS
どんなに忙しくとも、土曜日からはドラクエじゃ!!!

Open Source Conference

7/2、有楽町に行き、Open Source Conferenceに行きました。
1日から始まっていますが、1日は営業プロセスのセミナーに出席していましたので。。。



午前中は特に面白そうな講演がなかったので、午後から行きました。
最初はIBMの方の講演に出席しました。
・特に新しい情報は私にとってはありませんでした。
ポイントは以下の通りです。
・オンプレミスのプライベートクラウド自動販売機と同様にほしいと思ったら、
すぐに使用する事ができないといけない
(時間としても、約5分で)。
・人間が介入する場面を徐々に少なくする事で上記を実現する事が可能。
・全世界のサーバーの85%は待機状態である為、仮想化を実現する事で解決。
・既存インフラの人件費は全体の運用コストの70%もかかっている。
クラウドは今までできなかった事を解決するものでなければいけない。



NTTコムさんのZABBIXの講演にいきました。
・人がすごく混んでおりましたが、内容は非常にわかりやすかったです。
ポイントは以下の通りです。
・今回はJP1に変わるツールかどうかの調査をしていましたが、バッチ処理の対応は
ZABBIXではできないとの事。但し、問題が発生した時、メールをZABBIXのサーバーに
送信する事で、バッチ処理後の監視を続ける事は可能。
・色々な会社さんでは、ZABBIXのみ、というよりはサーバー監視のみZABBIXで、
という方法をとる会社さんが多いようです。そして、パイロット的に初めて、
徐々に既存のサーバーをZABBIXの環境に移行していく事になると思います。
・追加機能等はメンテナンス性を考えて、NTTコムさんではしない。よって、
ラトビア側に頼むことになるので、ほしい機能が全てそろうとは思えない。


・こちらがお金を払った対応がOSSに組み込まれるかどうかはむしろどうでもよく、
即座に対応できない事のほうが問題かも。OSSで一番問題になるのが、
バージョン管理なのです。特に、Suite系にの商品はそうです。
ライブラリーレベルであれば、対応したバグが使用している機能に影響するかどうか
を調べれば問題ないが、Suiteの場合、全てを変更するしかないのです。
単体と比べると、まとまっていてよいが、バージョン管理が面倒で、
かつ商品によっては再度設定しなおしもあるので、ここが永遠の課題かも。
・Suiteであるので、特殊な設定をしたくともできない。もし設定する場合は
恐らく別途料金が発生する、ステータスの区切りを変更する等。
思っている以上にサーバーの設定系がガチガチなので、下手な設定はできない印象がある。


・レポートやレプリケーションなどの機能を追加しようとすると、
別途料金が発生します。但し、コムさんが独自にラッピングしている部分は
コムさんの範囲なので、使用追加等は柔軟にできると思います。
・ZABBIXだけでしたら、アルクさんという会社がサーバー本体込みで、コムさんの
1/5以下の価格で販売していました。HP-UNIXをサポートする場合、別途料金が
かかるという点以外でしたら、非常に選択肢としては面白いと思います。



・あとは会場内を回り、色々なブースで話を聞いていました。
・大きい会社のブースは正直な所、おもしろくなく、ユーザー会とか小さい会社の
ブースは非常に面白かったです。



ここ

一番面白かったのが、ここです。Zoopsよりもいいですよ、と紹介されていきましたが、
Ajaxで実装されているので、DragアンドDropコンポーネントを設定したり、
権限管理もかなりできているツールだと思います。学校関係で使用されており、
触ってみた印象ではよさそうな感じがしました。



<まとめ>
大きい会社のブースはつまらないですが、小さい会社(失礼な言い方ですが)は
非常に活気があり、かつ気軽に話をすることができて、面白いですし、
ここでは書きませんが、なるほど!と思うことができる情報等もGetしました。
当初聞いていた通り、講演は確かに面白いですし、講演と講演の間の時間が20分
もあるので、気になるブースで話を聞いたりする事も可能で、時間配分は今まで
参加したカンファレンスでは一番よかったと思います。
うーん、会社の調査が関係しているので、あまり細かいことがかけない。。。

目からウロコの営業改革プロセス

・第二部
羽生さんのお話です。考えてみると、こういう場で羽生さんの話を聞くのは、
マジカ!の新しいカードが追加された時以来です。
最初に社名変更のお話。後でお話を聞いた時、本日が最初に発表したことの事です、
ラッキーな場所にいました。できたてほやほやの名刺も頂きました。



パッケージを導入する事で売上げがUPというイメージがありますが、それだけではNG。
成功するにはというよりも、「失敗しない為には何をするの?」と考える事が重要。
同感です。


そもそも論として、業務に対する基礎知識がない→無理やりIT化する
→よって、失敗する、という法則が発生。


そこで、仕事の整理・整頓が必要になる。
整理→いるものだけ残す。つまり、いらないものは捨てる。
整頓→秩序立てて物を置いていく。
この整理・整頓の順序を逆転するのは、間違い。整理・整頓の順序が重要。


業務は前もって考えられるものではなく、試行錯誤の繰り返しで生まれるもの。
だから、事前に業務を考えてとしても、むしろその通りにはならない。
一定のパターンができるまでは、試行錯誤の繰り返しを常に行うのである。
できたパターンは、社内の色々なノウハウによって構成されているので、フィットする。
上記のパターンを説明できるようになると、理解したという成熟度になる。
理解したという前に、たまたまうまくいった方法が身につくと、マイナスになるので、
ここが重要なポイント。なぜ?説明できる人がいないからです。

上記に対抗するものは、前職ではこうでした、という事。


IT化をする前に、重要なことは人間系のシステム化をして、業務が
きちんと回ることを確認する。つまり、人間系でもうまくいかないものを
IT化しても、結果は目に見えている。よって、紙で回る業務を最初に設計する。



マジカ!を使って、現状分析をすると、全て重要に見えてしまうことがある。
これは私もマジカ!を使って書いたことがあるので、理解できます。Tobeに
しろといわれても、何が重要なものかよくわからないと感じますね。
これは、プロセスを作る事に集中しすぎていて、ゴールがみていない、
ここが原因です。

つまり、ゴールをまず定義し、それから何が重要なのか、を整理するのです。
ゴールとは、ゲームで言うところのラスボスです。ラスボスを一気に倒しに行けばいいのです。
でも、まだ力がない、それなら何をするの、どういう武器がいるの、となり、
ゴールに向けていく前に必要なことがどんどん理解できるのです。
そして、仕事で言うと、チェックリストを作成し、お客さんに必要なことを記述し、
確認していくのです。ここで必要なことがかけない=言葉がない、という事は
改善しないといけない部分がある事を意味していますので、NG・差し戻しを
行い、まずはお客さんに自分でクリアしてもらいます(もちろんヘルプはします)。
チェックシートは成果を確認する為に、目に見える形で表すものです。


ここで重要なことは、満足・納得ではなく、要求のみが必要なこと。
つまり、こういう武器・道具があったらいいなぁ、は無視。もしかしたら、
ラスボスを倒すときには不要なものである可能性もあるので。
満足が増えていくと、無限大に色々なものが増えていき、かつ人によって
必要・不要の判断になるので、要求のみに集中。
満足は趣味と置き換えてもよいですね。
過剰品質といわれるのが実はここで、お客さんの中で声がでかい人を満足・
納得させる為に作成するので、結局他の人にとっては不要であった、という
事態が発生するのです。おまけに、コストは自分たちで負担。



設計 = 作業手順 完成基準 = 仕様
作業手順 チェックシート
完成基準 ゴール

このようなルールになります。
チェックシートの書き方としては、「〜を〜する」という形式で。



分業の発生=自分1人では対応ができなくなっているため
メモとして、Excelに対応する内容を自ら記述。同じ事を分業した人が
みなするので、Excelが重宝される。
トラブルが起きたとき、初めて自分だけではなく、みなが理解できる
共通の情報が必要になることを理解する。
現状の分業は、なりゆき任せになっている+個人の頑張りになっている
つまり、無意識でその場しのぎになっている為である。


これは私がいま出向している会社がまったく同じで、ここではシステム化というと
Excelがありますから、で終わる。では、みな定時には帰っているのか、というと
平気で3時間ぐらいの残業は当たり前のようにしています。トラブルが起きると、
だれだれさんが知っています、という一点張り。それもお互いに。だから、
マネージャークラスの人が自ら全てを見渡して、対応するしかないのです。
個人ではExcelに色々とメモを書いて頑張っていますが、会社全体としてみると
何をやっているんだ、あいつは、としか見られない。
全体の構造が問題なのです。


上からの突っ込みで、ミスをしないような対策をしろというと、またExcelの対応が
増えて、結局またミスが起きる。結局、何をやってもだめなんですよね、全体を
かえるようなことをしないと。このような現場にいるので、羽生さんの話を聞いて
いると、タイトル通り、目からウロコガ落ちるという感じでした。



上記を解決する方法としては、紙で回せるような業務プロセスをつくる、という事に
なり、紙でも問題ない場合、初めてシステム化がその先にあるのです。
紙を回すということは、情報を設計する、情報をうまくコントロールする
という事にもつながるのです。つまり、新入社員の時に最初に言われた
ほうれんそう +依頼(人との関係があるので) です。
そして、チェックシートに対して、ほうれんそうを対にして決めていくことで、
精度の高いチェックシートを完成させていきます。



ほうれんそうを定義する時、定量化=単位をしっかり決めることが重要 例えばお金
言葉が人によって定義・ルールが違うので、言葉も統一することが重要



紙があふれてきて、もう人の手ではむり!!!となったら、IT化になります。
つまり、定型化した内容をコンピューターに任せてしまえばいいので。

ゴールを定義

成果のチェックシートを作成

ほうれんそうの構造定義

紙でまわす

定型化したらコンピューター化

そして、仕事のための仕事はつくらない!
という内容になります。

<まとめ>
タイトルの通り、ITとは少し関係が薄い内容ですが、私はすごく面白かったですし、
何をするにしてもITITというまえに、まずは何をしないといけないのか、
という部分がすごく具体的になってきた感じがします。
これだけ見ていると、マジカ!は別にいらないのかも、と思いますが、29日に
その部分の説明があると思うので、参加の方向で調整していきます。

目からウロコの営業改革プロセス

今日は出向先が内部監査が入るという事もあり、会社にはいたくなかったので、
かつたまたま面白い営業プロセス改革セミナーがあるので、参加してきました。



非常に面白い内容です。
・第一部

  • 7つの習慣という有名な書籍の会社の講師をしている寺尾さんのお話。
  • SFAを導入する→利益UPという魔法はそもそもない。
  • 根本的な事として、実体と本質が一致したパラダイムの変化が必要。去年のオリンピックのスピード社の例をとり、水着がきつい=でも早いとよしとするか、水着がちょうどよい=でも早くない、どちらを選択するのか、という問いに対して、金メダルを取った人のほとんどは前者を選択。つまり、いやな事・好ましくないこと=実体を認識し、スピードが速い=という本質を理解している、ということ。成果として、金メダルが取れる、と。
  • これは実体と本質が一致したパラダイムが発生した為に起きたこと。売上げいくらとあほみたいにいう人がいますが、大体うまくいかない。理由は会社の実体がどのような状況で、会社の強みとかの本質がわかっていないから。
  • この意見は私も同感です。



<利益を最大化する法則>



有効利益の多い商談
+
利益増加
+
予測の精度を向上
/
商談時間の短縮



結局、商談時間を短くして、利益が多い商談への時間を増やす、という事。
商談時間を短縮する時、
ステージ
具体的イメージ
リピート率
を意識して、望んでいく必要がある。
つまり、リピート率が高い人は過去の仕事の関係から、ビジネスにつながる話は多いし、
新規はむしろぐだぐだながーい話が多いので、サクッときってしまい、さらに
具体的なイメージが浮かばないなら、仕切りなおしをして、一緒に考えるという事を
やめれば、時間という名のコストもかからない。
自分が主導的に時間をコントロールできれば、有効な時間は生まれてくるもの。



・アプローチ
・課題
・デモ
・見積もり
・クロージング
・フォロー
という一般的にはアクションがあります。

お客さんの行動と原因が一致 → よい
ここを実行できるようにする必要がある。


  • 売上をUPする為に新規顧客を見つけて、短期的にUPするよりは長期的な関係を結び、関係を継続できる営業プロセスが必要。長い間の付き合いになると、大体既存は適当になり、新規に力が入るが、利益という点から見ると、むしろ逆。だから、既存顧客のニーズを理解し、ニーズに合うものを常に追求する事で、利益もUPしていく。
  • つまり、長期の顧客との関係・ニーズの理解・利益UPは連動するもの


  • 開発の現場でそうですが、何故いるのかわからないものが機能に入っているケースが多く、無駄なお金を使っているケースが多い。そもそも、マーケットでもいるものなの?この機能を入れることで、何のメリットが具体的に数字などに表れるのか、を理解しないとだめ。
  • 私も開発の人なので、これはすごくよくわかります。こっちはお金をもらえるので、やりますけど、とか言わないですよ、開発の人からの立場では。もちろん、これいらないのでは、とアドバイスもしますが、ここは営業さんがどういう判断するのか、が全てなので、責務を自分が負っている点は認識してほしいですね、丸投げをしないで。



物事にはそもそも順序が存在する
・まずは社内の棚卸 長所や短所を見極めること
・将来を見据える
いきなり将来は、と考えるとOUT!

そもそも業務プロセスを改革するには色々な情報が必要であるので、情報を取得する必要がある
もし定着しない、無理がある場合はフォローだけすればよい



実行する時、パイロットプロジェクトとして進める。
そして、徐々にパイロットプロジェクトではじめた事を全社に適応していく。

1.現状の把握
2.チーム結成
3.チームのトレーニン
4.チームの成果
5.全社展開

上記のことをしないといけないので、SFAを導入するだけでは何も変わらない



結構長くなりそうなので、続きは明日に。

BP Study

今日はBPStudyという勉強会に行きました。ここに行くのは初めてです。
2つの内容があり、どちらも非常に楽しみにしています。



・GAEForJavaについて
量は非常にありましたが、今まで聞いたGAEの講演では
とくにBigtableについてはわかりやすい内容です。

  • まずはFlexBlazeDSで作成したご都合.comの説明。私もAIR+BlazeDSでプログラムを作成した事があり、GAEでもこの構成が実現できるのか、という点が印象的で、是非試してみたくなりますね。但し、単純にBlazeDSをそのまま使えず、コンパイルをしたり等、動かすまでには色々な苦労がありそうです。



その後は、GAEの説明、

  • クラスタ=ステートレスにしており、ステートフルを実現する場合はMemcacheを使う、
  • Memcacheにデータをいれ、Cronを使用し、いらないデータは削除する(容量オーバーすると、Sessionがきえてしまうらしい)
  • Memcacheはノードが変わっても、自分で挿入したデータを共有(どこからでも)されているので、ノードを意識する必要はないらしいメモリーに頼らず、Memcacheを有効的に使用する事がよいので、ここがGAEにて何を実現する時のポイントになりますね、JavaでWebアプリを作成する場合、Sessionに何でもいれてしまえという設計になり、使用ユーザーが多くなり、パンクすることになります。今後は一部はBigtableへ、画面遷移等でよく利用するデータはMemcacheに入れる、という設計を行い、Memcache←Bigtableを効率よく利用しないといけない事を理解しました。



その後はBigtableの説明、

  • 今回初めて知ったことは、大量のデータを処理する場合はlowerlevelAPIを使用し1件ずつ処理をする場合、JDOを使用するとよいみたいです。
  • Key・Entity・Propertyについて、色々な講演を聴きましたが、今回はじめて詳しく詳細について説明がありました(時間がかかる内容ですので)。
  • データベースからの取得件数は1000件までという制限があり、1001件目が存在する場合、NGのようです。ページングについてはPythonではAPI的なものが用意されていますが、Javaはまだないようです。
  • 条件式を作成する場合、イコール(=)をうまく使うと早いですが、<=や=>などを使用し、さらにOrderbyを使用すると、遅くなるということです、おまけにIndexも作成してしまうので。ここはデータを抽出する時、うまく設計しないといけないですね。Memcacheなどをうまく利用して、イコールでできる方法を考えます。



・Liftについて
Seasar2の時、EscafeFlowに出席しましたので、Liftは仕方なく参加できませんでしたが、
ここでもあるじゃん、と思い参加しました。
アメリカの開発者の人たちが継ぎはScalaだ!とみていっており、なんでなの?
Java+関数型という仕様の何がいいの?という部分についての私なりの疑問が
なるほど、と理解できました。講演のとき、関数を作り、この関数をどのように
呼び出したり、使用したりするというデモがあり、このようなことができる言語は
確かにないなぁ、特にオブジェクトに関数を代入する、という考えが印象的でした。

  • さらに関数を部分的に適応できる為、カリー化も可能になる。
  • Switch文で、Javaですと数字のみですが、文字・オブジェクトでも大丈夫のようです。
  • LiftはUSの書籍を購入して、一通りみてみた経験があり、美味しい所をとっています、色々なフレームワークの。Wicketに非常に近いですね、かつWicketはかなり評判がよいです、外人さんたちの話を聞いても。
  • Template・Snipet・Modelで構成され、Controllerに該当する部分はなく、Lift側でここは担当します。つまり、Viewが中心のフレームワークです。
  • ボタン実行→関数実行=パラメーターを設定しておく、つまりイベント処理ではブラウザーからSnipetを実行するまでの間で、上記の処理をレンダリング時に行うので、ルールさえしっかり守れば、Controllerを意識せず、画面に表示・設定したい情報をコーディングするれば、表示される、と。
  • 本当にViewが中心のフレームワークで、かつScalaを使うことでコード数を削減しようとしているので、非常に面白いフレームワークだと思います。



<まとめ>
今月は講演が多い月でしたが、どれも全体を通して、色々なことを学ぶことができ
非常に充実しています。いまはBigtable関係の講演が多く、今年はこのお話が
色々なところで聞かれると思います。
個人的にはScalaについては非常に面白いと思っており、時間を見つけて、サンプルを
作ってみようと思います(色々と試したい事が多くなってきています)。。。