富士通の人の特許利用の話を聞いてきた！

１０月６日、おおた研究開発フェアに行ってきて、
富士通の人の特許利用の話を聞いてきたのでメモメモ

---

■埋もれた技術を掘り起こせ
　開放特許を活用した中小企業の新ビジネス創生

プロフィール

事例
・マック様　抗菌包丁
　富士通の光触媒
　堺市長が「市内企業と大手企業のマッチングによる新商品開発について」
・宝養生資材　光触媒チタン
　東京大学の名前が入ると、売上が上がる
・JINS様　花粉　CUT　CLEAN
　末吉ネームプレートで開発された塗料
・味の海翁堂さま「印刷画像へのコード埋め込み技術」の活用
　コミニティで広める
・行動状態検知技術
　動画で
　寝たきりの人：動きの大きさをデータベース
　　→大きな動きだとナースコール鳴る
→現在使っている技術を提供
　なぜできるか？
　　１つの事業：１００から１０００億
　　→５億くらいしかならない技術を出す
　ALCO-EX様
　　コミニティで売っていく

・活動紹介
　全国に展開が進む未利用特許のビジネスマッチング
　未利用特許のビジネスマッチングとは
　　国や地方自治体、金融機関などが主催者となって
　　大企業保有特許を核とした中小企業の新規ビジネスを創生
　→イベントは成果が出ない
　　信用金庫にもんでもらい、
　横浜市内中小企業の売上
　新規事業：１０００万あれば、やる意義ある

・ものづくりプロセス
　　もの
　　　「理」の世界：頭の世界
　　　　設計思想
　　　　　↓うめこむ
　　　　マテリアル　　人

　　つくり
　　　「気」の世界：手足を動かす世界

・ものの理：アップル
　つくり：東南アジア

・過剰品質について
　　「品質」は顧客が決めるもの
　　　　メーカー側が押し付けるものではない
　　　　品質にも松、竹、梅
　　顧客は購入価格により品質を追求する
　　　　百円ショップの商品→壊れやすいがクレーム少ない
　　　　５百円のうなどん、３千円のうな重

　　～さは個人の感覚に依存し、絶対評価に繋がらない
　　　そこで競争を続けていけば、高コスト

・中小企業向け知財活用で重要なことは
　　ライセンス契約締結がゴールではない(スタートである）
　　顧客の顧客を考える
　　特許は単なるドキュメント、活用してこそ価値が生まれる
　→中小企業様で売上が立たなければ、意味がない
　　　お客さんはだれで、買ってくれるところは？
　　　　買ってくれるところをつれてくる
　　　　顧客の顧客を探す：金融機関→販促品
　　　　出口戦略が一番：パブリシティ　ただで書いてもらう
　　　→自治体になげこむ
　　　出口戦略：得意なのは文系　マーケティングの人

・不安と戦う起業家
　　キャッシュフロー
　　　そこを浅く、損益分岐点を手前に
　　→そこを深くしたほうが利益が大きくなるかもしれないが
　　コミニティの知恵と大企業のシーズを使う

・市場のメカニズム
　　マニアマーケット
　　　新し物ずき
　　　目利き
　　　　　市場の断層
　　　流行に敏感：ここを捉える
　　　流行後追い
　　　無関心

・最初の顧客の獲得
　B2Cの場合
　　マニア層への直接アピール
　B2Bの場合
　　技術・サービスの優位性

・アトリビュートマトリックスを活用したディスカッション

・新事業開発は四輪駆動車のイメージで
　　特許
　　　らいセンサー企業
　　　ライセンシー企業
　　　自治体
　　　金融企業
　川崎モデル
　埼玉モデル

・地域企業１０００社のデータベース
　　ビジョン、設備（の写真）、中期事業計画

・知的財産研究会
　　静岡盛ん：磐田信用金庫
　地域金融機関が地域創生の中核となる！

・人文・デザイン系学部連携による
　出口戦略の創出

　アイデアではない。出口までやる
　信用金庫に連れて行ってもらう（自治体の場合も）
　昭和女子大が優勝
　ことしは６つ

・そのうちの１つ：視線検出技術
　小型視線検出センサー
　　スポットと目じりの計測

・方向誘導技術

・まとめ
　特許だけではビジネスは進まない
　情報を持った人をつなぐネットワーク
　　利他の心、熱意

　信金さんでも
　　骨を折ってやってくれる人：失敗しない
　　HE

　知財活用事業失敗の要因
　　責任所在が不明確
　　地域企業データの圧倒的不足
　　自治体・関係者のローテーション
　　コーディネーターの適正・孤立化
　　成果につながらないイベントはやらない
　　成功に繋がるキーワード
　　　受動→能動
　　　机上→現場（アクティブラーニング）
　　　権利化→活用

　松下さんの「商いの心得」

・昭和女子大の発表
　　チームトルストイ　RFIDのゲーム
　　小型ドローンゲートターゲット

「Springをなんとなく使っている人が抑えるべきポイント」などを聞いてきた！

１０月５日、JSUG勉強会　２０１６年その８～今から始めるSpringに言ってきたので、その内容をメモメモ・・・するんだけど、

もう、ちゃんとしたメモがネットにでていた

「JSUG勉強会 2016年その8 ～ 今から始めるSpring」に行った
http://qiita.com/y_q1m/items/d8e12d5ad1b7b71aeef5

ので、ちゃんとしたいのが見たい人はそちら！
（ここのメモは、ろりぽじさんんIT用語説明レベルのアバウトさ＝雰囲気レベルです）・・・
なので、ここでは、最後に「所感」を書いておこう！

---

■DI/AOPについて学んでみた
・自己紹介
・会社紹介（TIO）
・Springと私
　基礎知識なしでなんとなく使っていたレベル
　インターフェース、applicationContext.xml
　右に倣え
・なぜ
　DI/AOPを調べれば分かるよ
・DIについて調べてみました
　概要
　　依存性の注入：外部の設定ファイルなど※
　　※ApplicationContext.xml　アノテーションで設定
　メリット
　　結合性低下によるコンポーネント化の促進
　　単体テストの効率化
　手法
　　インターフェース注入
　　Setter注入など
・DIとは（イメージ）
　class Service 利用:Dao　　class DaoImple
　　　　注入　　　　　　　で異性
　　　　　　DIコンテナ
　　　　　　　参照
　　　　　　ApplicationContext.xml→依存関係を定義
　→newすることがなくなる

・これっておいしいの
　　脳内アプリ；会員サイトの検索機能
　　イメージ：ブラウザ→アプリケーション→DB
　　登場クラス
　　　Action
　　　サービス
　　　DAO
　　　user：値格納・情報返却

・DIを使わない構成
　　利用する側のクラスが必ずnewする→密結合
　　利用する側・される側が密結合している

・DIを使った構成
　　DIコンテナで生成して利用する側に注入する
　　利用する側、される側が疎結合になっている
　　　DIコンテナ→ApplicationContext.xml

・で、メリットは
　クラスの関係が疎結合
　　変更に対応しやすい
　　試験を実施しやすい
　　　　固定された値でテスト

・AOPについてしらべてみた
　本来すべき処理とすべきでない処理
　本来すべきではない処理をあとから呼びだす

・AOPを使った場合と使わない場合の確認
　AOPを使う→トランザクション管理クラスを作る
　　本来すべきではない処理の実装ミスを防げる
　　一元管理できる
　　処理を変更せずに後から追加できる

・まとめ
　SpringにはDI/AOPを利用する機能が備えられている
　疎結合ナシステムを構築できる

■Springをなんとなく使っている人が抑えるべきポイント
・自己紹介
・概要
　Springｗ９おなんとなく使っていませんか
　　上手く動かないときの対応ができない
　　応用が利かない
　　面白くない
　主要なポイントを抑えて、開発を面白くしましょう
・主要なポイント
　　Beanのコンフィギュレーション：３通りある
　　DI/AOPの使いどころ
　　データアクセス

・コンフィグレーションの方法
　３種類選べる：結果は同じ
　　XML
　　アノテーション　@Compornemt
　　JavaConfig　@Bean
　→DIコンテナが管理するオブジェクトをBeanと呼ぶ

XML
　　メリット：分離できる。一元的に管理、再ビルド不要
　　デメリット：メンテが大変
アノテーション
　　メリット；記述が楽
　　デメリット：プログラムとBeanの定義が混在
JavaConfig
　　メリット：分離できる、タイプセーフ
　　デメリット：メンテが大変

　一般的と思われる使い分け
　　業務個別のBean(コントローラー、サービス、Dao)はアノテーション
　　裏方のBeanはXMLまたはJavaConfig
　　　　→そもそも、アノテーションが付けられない

・DI/AOPの使いどころ
　DI：すべてをBeanで管理するわけでない
　　ステートレスなオブジェクト（コントローラー、サービス、Dao）　
　　　→BeanにしてDIで紐付け、ASOP
　　処理のたびにオブジェクトが生成され、個別のフィールド値を設定する
　　　Entity,DTOはBeanにしない

　AOP：
　　レイヤー間にAOPで共通処理（BeanにしかAOPできないという事情も）
　　業務的な処理は基本的にAOPは使わない
　　　→わかりにくくなる（例：税率かける）

・同じオブジェクトが使われている
　　リクエストのたびに、コントローラー、サービス、Daoのオブジェクトが
　　　作成されるわけではない
　　リクエスト間でデータ共有（キャッシュ）
　　スレッドセーフにする必要

・インターフェースは必須じゃない
　　インターフェースを介さなくてもDIは可能
　　用途の例：各レイヤーの補助的なBean

・コネクション・トランザクション周りの仕組み
　　トランザクションの開始・終了はSpringが行う
　　　ソースは書かなくていい

　画面周りの処理の流れ
　　Dispatcher Servlet
　　　HandlerMapping：コントローラー特定
　　　HandlerAdapter：引数の値を用意
　　　ViewResolver：Viewの形式ファイルを特定

　コントローラー
　モデル
　View

・認証・認可の仕組み
　認証とURLの認可はServletFilterで行われている
　DispacherServletに依存していない（SpringMVCに依存しない）
　認可の主な対象はURL、メソッド、画面描画の３種類

　認証のサーブレットフィルターなど
　　セキュリティコンテキスト：HTTPSession.ThreadLocalなど
　　SpringMVCを使わなくても使える

・サーバーを起動しなくてもBeanをテストできる
@before
public void setup()
　{
　　　ApplicationContext ctx = new AnnotationConfigApplicationContext(TestConfig.class);
fooserve = ctx.getBean(Fooservice.class);

・Spring Bootが行っていること
　　　必要なJarファイルのダウンロード、
　　　Beanのコンフィグレーション、
　　　サーバーの実行
　業務固有のBeanのプログラムつくりは変わらない
　組み込みじゃないTomcatにデプロイ可能

・最後に
　　おすすめ
　　　改訂新版Spring入門
　　　Spring徹底入門

■悩めるJava初心者のためのSpringをどーんとやってみよう
　「よい子・悪い子・普通の子」

・自己紹介
　よい子のやまざきさん
　普通の子　ときさん
　わるいこ　てらひでさん

・どうやってSpringを勉強したか
　よい子
　　仕事で使うのが一番！SpringOne
　　苦労：良くも悪くもドキュメントが豊富
　普通の子
　　本を読んで独学。Springを使う開発現場がなかった
　わるいこ
　　勉強などしていない。
　　　　勉強しなくても使えるフレームワークがよいフレームワーク
　　苦労したこと：仕事にならない

・事前に勉強することはあるか
　JSP-Servlet、DDDとか
　よい子
　　Reactive！
　普通の子
　　Java文法（例外などのややマイナー部分）
　　DBまわり、Webまわり、JSP-Servlet、JUnit
　　→ローカル変数の生成と消滅
　わるいこ
　　男気のある優しい先輩の見分け方
　　　たばこをすうか、おさけをのむか
　　　姉御みたいなひと
　　→会社にいますか？
バージョンは６の人は
　　よいこ
　　　８にする
　　普通の子
　　わるいこ
　　　いいんだよ、すごくいいんだよ
　→８にあげられない場合は
　　わるいこ：８に使える現場にうつる

Spring初級者になるための勉強範囲は
　よいこ
　　・だめだ、全部だ、ドキュメント全部読め
　ふつうのこ
　　・データアクセス、トランザクション、SPりんｇMVC
　わるいこ
　　・難しいことは全部Springがやってくれる

初心者にぜひ理解してほしいこと、１つ上げるとしたら何
　よい子
　　理解して使うこと！なんとなくでは、正しく動いてないぞ
　普通の子
　　newが１つもなくなるわけではない
　だめなこ
　　Springは開発者が仕事をサボる生産性をあげるための
　　便利な道具

SpringBootから勉強するのはあり
　よいこ
　　　いいんじゃないか。興味を持つため
　ふつうのこ
　　　おすすめはしない。何が起こっているかわからない
　わるいこ
　　　超おすすめ。Gradle最高！

初級者・中級者になったことは、どう確認すればよいか
　よいこ
　　システム作って、誰かに売る
　普通の子
　　すう画面のWebアプリを自分で設計・実装して、上級者に見てもらう
　悪い子
　　GitHubにソースコードを公開してTwitterで自慢する

発表するのはどのレベル
　よいこ
　　いつでも
　普通の子
　　いつでも
　悪い子
　　難しいことをする前に、ビアハッシュでLTだ

最後の一言
　よいこ
　　JSUGに参加しましょう
　普通の子
　　本を買って・・・
　悪い子
　　こまったら、つぶやく

SpringDay2016
　１１月１８日
　すごいセッション
　全て無料、懇親会、LT

---

■所感
　DIの「依存性」や「AOP」などはソフトウェア工学から来ている用語だと思う。
　なので、そこから入らないと、？？？になってしまう。

　たとえば、AOPのとことで、「本来すべきでない処理」のところで、
　ログ処理が入っているのはいいとして、
　「トランザクション処理」は、どうなのどうなの？
　いや、それは、しなきゃだめな子な処理でしょ！

　これは、「横断的関心事」というソフトウェア工学の概念を
　テキトーに言い換えてしまったから起こることで、
　ソフトウェア工学的に言うと、

　処理は

　　　その機能内で閉じて考えてすべき処理（局所化すべき処理）
　　　その機能内で閉じて考えず、（横断的に考えて）すべき処理（横断的関心事）

　にわけられる。

　前者は、機能要件で記載されるもので、受注なら受注、発注なら発注のオブジェクトが
担当するというように、担当するオブジェクトが決められ、そのオブジェクトが、他オブジェクト
を監視・制御することで、処理が決定できる。

　後者は、主に非機能要件で議論されるもので、受注・発注のみならず、横断的に
調停するオブジェクトが必要となるものである。これが横断的関心事
　たとえば、トランザクションは、受注・発注・取引先など、いくつもの機能に
同時にかかわり、矛盾ないように調停しないといけない。これが横断的関心事
　ログも、受注と発注が別々だと、わかりにくい（時間がずれてたりすると、
前後関係不明になる）
　このほかには、セキュリティなどがある（受注はセキュリティばっちりだけど、
発注はザルとかだと、意味ない）

　Diについても、ソフトウェア工学的に、背景がある（文脈＝コンテキスト）
そのへんについては・・・いつか、かく

富士通のオープンソースへの取組みを聞いてきた

10月5日、Redhat forum 2016　The power of participationに行ってきた！のでその内容をメモメモの続き（Redhat forum 2016は、これで最後）

次は
「デジタル革新」を支える富士通のオープンソースへの取組み

をメモメモ（これははじめから聞けた）。

---

■デジタル革新を支える富士通のオープンソースへの取り組み
プラットフォームソフトウェア事業本部　富士通Linux開発統括部　統括部長

・富士通の想い
　ヒューマンセントリック

・富士通の２０１６年のテーマ
　driving デジタル・・

・デジタル化への期待
　　世界のCEO,CIOはビジネスのデジタル化に期待は高い

・デジタル化の加速

・デジタル技術の波
　　AIとロボティクス
　　IoT
　　モバイル
　　Internet

・ビジネスを大きく変えるデジタル技術
　　行動
　　IoT
　　データ
　　アルゴリズム・AI技術

・様々な製品、サービスやプロセスにデジタル技術を取り入れて新たな顧客価値

・デジタルビジネスプラットフォーム　MetaArc
　　　IoT　AIなどの新技術を活用したSoE
　　　現行の基幹系・情報系SOR

・MetaArc
　　企業の枠を超えてデジタル革新

・デジタルビジネス・プラットフォーム　MetaArc
　APIで多様なサービスをつなぎ、デジタル革新を実現
　　ハイパーコネクテッドAPIエコノミー

・Fujitu　Cloud　Service　K5
　MetaAｒｃの中核、新たなクラウド基盤K5
　　K5：ナレッジ　５：５大陸7
　　IaaS、PaaS

・K5の話が中心
　　いろんな提供形態
　　　バーチャルクラウド
　　　デディケート
　　　プライベートクラウド　primeFX
　　基盤はオープンソース

・社内システムのクラウド移行
　　K5に移行　６４０システム　５年間で３５０億円
　　９４システム現在稼動
　→インターネットに

・社内実践によるリファレンス化
　富士通社内システムで自ら実践
　７割がSoR→高信頼性

・K5ロードマップ
　順次エンハンス

・富士通のオープンソースへの取り組み
　お客様のICT投資を守る最適なプラットフォームの提供に向け
　　塩漬けミッションクリティカルから
　　エンタープライズ・サービスプラットフォームへ

・デジタル革新を支える開発領域へ拡大
　　１０年以上にわたるLinux　OS開発　LinuxのMC化
　　OpenStack/SDN/IoT/コンテナに開発領域拡大
　　　デジタル革新牽引
　　　KVNに投資、OpenStack,SDNに投資、今はコンテナに投資

・富士通か開発するソフトウェア
　　ハイパーれっジャーも（ブロックチェーンも）
・OpenStackコミュニティでの開発状況
　　修正コミット数　WWで７位、国内No1
　　ベアメタルのマルチテナント・ネットワーク配備
　　　→富士通推奨構成でできる
　　無停止アップグレード
　　いんたーおぺらびりてぃ

・コンテナの標準化
　　ポータビリティを担保するコンテナ標準実装に向け
　　OCIコミュニティ開発をリード
　　コンテナ認証プログラム

・What is Open Source for you
　　Over 80% of the software in our handsets is open source
　　　カール・エリックもりす
　　オープンソースを使わないと製品が作れない
・Who writes Linux
　　ドライバ　５８％
　　あーき　１６％
　　コア　３Mステップ以下
　１位　レッドハット　２５％
　４位　グーグル
　９位　富士通　　　　　４％

・オープンソース活用しビジネス実行する
　OSSに足りないときの選択肢
　　製品で補完；将来にわたる優位性確保が課題
　　OSSを強化：OSSコミュニティでの開発が課題
　きょうは２

・OSS開発は何が難しいのか
　世界中のベンダーがそれぞれの目的で開発
　開発目的、優先度、スケジュール、実装方式がばらばら
　以下に製品開発にあわせてOSS開発するか

・ビジネスを実行する
　　OSSコミュニティで必須機能を実現するためには、
　　世界で通用するエンジニア
　　　発注するか、育てるか
　　　　発注すると、うまくできない
　　　　育ててインハウスにもったほうがよい
・あいちゃん、本田さん、まつやまさん、いちろーさん
　もう一人「イチロー、福原愛・・」を作る
　　これらタレントの共通事項は？
　　厳しい競争環境で育ってきた
　　たくさんの経験→待てない→準備するしかない

・市場の変化、トレンドを理解する
　環境変化の上にロードマップを作る
　ビジネス経験領域を増やす
　サーバーでべろっぷめんと

・OSSで製品・サービスビジネスを実行する
　　技術トレンドに先回りする
　　OSSコミュニティで機能開発する
　　時には技術トレンドをつくる

・富士通の製品・サービス　デリバリモデル

・OSSを活用
　Primeflex for cloud K5
　Primeflex for RHOSP
　　対応版２０１６年９月
　　安いもの１０月にだせるかなあ
　Enterprose Service Catalog Manager

　Server Viewクラウドもにたりんぐマネージャー
　ハイパースケールストテージ　Eternus CD10000 S2
　　Cephベース

　Virtuora(NFV)にも適用
　RHEL 長期サポート on K5 2016年度３Q提供開始予定
　Containerサービス on K5
　RHEL5　来年２０１７年３月３１日終了→その後のサポート
　アップデートに伴うコスト削減

　イノベーションがもたらす豊かな未来

JBOSS EAP ７(JavaEE7、Wildfly10に対応）について聞いてきた。

10月5日、Redhat forum 2016　The power of participationに行ってきた！のでその内容をメモメモの続き

次は

最新のJava EE 7仕様準拠 、クラウドレディアーキテクチャ JBoss Enterprise Application Platform7紹介

をメモメモ。なんだけど、会場が違っていて（当日入れ替わった？）これも、はじめ聞けかなった
（１～２分くらい？）

---

■途中から

EAP7提供開始
JBOSS EAP7とは
・JavaEE7の０サポートWebプロファイル、fullプロファイル対応
　セキュリティ
・コミュニティ版、製品版対応
　JBOSS EAP7 WildFly１０対応
　製品版：なにがいいか
　　テストしている
　　パッチ：９月　２つでている
　JBoss Enterprise Middlewareのリリースとメンテナンス

・主要コンポーネント・対応技術
　JDK8
　Webコンテナ変更
　メッセージング active MQ あるてみす
　EAP6から変更されたコンポーネント：移行する
　　JBOS　CLIでマイグレート　６を７に
　ドメインコントローラー

・JavaEE6からJavaEE7
　７で何が新しくなったか？
　　WebSocket
　　JBatch
　　　→エンタープライズアプリケーションで
・JBOSS　EAP　７　機能
　　最小かつフレキシブルなアーキテクチャ
　　高速起動
　　コンフィグレーションファイルの単一化
　　高いモジュラリティ
　　軽量稼動
　　　８０８０，９９９０の２つのポート
　　　わいんどあっぷ
　　柔軟性のある運用管理
　　　CLI,Web、API

・クラウドーレディ　アプリケーション

・オペレーショナル・モード
　　ドメインモード：
　　スタンドアロンモード：設定を個々に管理

・新機能
　　運用管理効率化
　　　Webコンソールを使いやすく
　　　サーバーに対する操作
　　　　デモで
　　　　　　データソーステンプレート
　　　　　　メトリックス
　　　　　　サスペンド：シャットダウンと振舞い違う
　　　オフラインCLI
　　　グレースシャットダウン
　　　HAとパフォーマンス
　　　　　ソフトウェアバランサとしてできる
　　　HTTP/2（テクノロジープレビュー）
　　　ポート番号の削減：８０８０と９９９０→時下打ちの場合注意

　　開発生産性
　　　モジュラリティとコンポーザビリティ
　　　互換性
　　　軽量：必要なものしか、アクティベーとしない
　　　高速起動

　　テクノロジートレンド
　　　クラウド対応
　　　メッセージング　HornetQ～変更
　　　　　messaging-activeMQ
　　　　　上位互換性：コード変更なし
　　　　　　（コンフィグレーションにlegacy-connection-factor)
　　　　　下位互換性

・JBOS EAP7
　　NoSQL
　　JDK9
　　セキュリティ
　　Wildfly10.1

・旧バージョンからの移行
　　移行ガイドを見てください
　　移行ツール：アプリケーション・コンフィグレーション（まだ未サポート）
　　JBOSS　CLIのマイグレーションをサポート
　移行ツールについて（アプリケーション）
　　Windup：アプリケーション移行のためのツール→レポートしてくれる
　ポート変更で、あるある
　　JNDI　Lookupのポートがみつけられない

・開発生産性
　　Redhat JBOSS Developer Studio 9
　　OpenShift
　　生産性：JBOSS　WAY
　生産性ー各種機能要素