ITILっていうより、Redmineでないチケット管理ソフトの話

３月１０日、オープンソースカンファレンス　Tokyo 2017 springで

ＯＳＳで実現するＩＴＩＬ運用事例

という演題の話を聞いてきたのでメモメモ

---

・会社紹介
・（いまさら）ＩＴＩＬとは
　ざっくりＩＴＩＬ
　　サービス戦略
　サービス設計：ＳＬＡ
　サービス移行：リリース承認、レビュー記録、アプリバージョン管理、ＦＡＱ、ミドル管理
　サービス運用：インシデント管理、監視、ヘルプデスク
　継続的サービスカイゼン
　→インシデント管理の話
・インシデント管理あるある
　Ｅｘｃｅｌの天気忘れ
　過去の経緯がメールのヤマ
　返答忘れ
・システム導入の動機
　件数・担当者増加、ＳＬＡ高度化
　→省力化、自動チェック、知識共有
　→ツールの導入

・チケット管理へのアプローチ
　開発ドリブン、サポートドリブン
　チケット管理　　ヘルプデスク
　RedMine：　　　　ＯＴＲＳ
　→別方向からのアプローチ

・ＯＳＳで実装したＩＴＩＬ運用
　　イベント管理（監視）Ｚａｂｂｉｘ、Ｈｉｎｅｍｏｓなど
　インシデント管理：ＯＴＲＳ
　資産管理ＣＭＤＢ
　構成管理：ＯＣＳインベントリー
　　　　　　オープンオーデョット
　リリース管理：Ａｎｓｉｂｌｅ

・ＯＴＲＳ
　オープンソース・チケット・リクエスト・システム
　　http://otrs.org
　ドイツの会社
　オープンソースだが、商用プロダクトをオープンにしたかんじ

・ＯＴＲＳが選ばれる理由

・デモ
　転記とかない
　ＦＡＱの公開：問い合わせを減らすためにという方向へ

・その他のチケット管理機能
　イベント管理
　インシデント管理
　要求実現
　問題管理

・プロセス管理
　ビジネス・プロセス管理（ワークフロー）

・ＯＴＲＳ利用者（弊社お客様）の傾向
　ユースケースは大きく２つ
　　運用の窓口
　　　監視結果
　　　リリースの管理
　　　セキュリティパッチが出たとき
　　保守・サポートサービスの窓口
　　　ＳＬＡ
　　　月次報告

　ユーザー数：３、４人～１００人くらいまで
　チケット数最大２０万件規模
　でも業務まわっている
　　　業務パッケージ的な位置づけ

・カスタマイズ例

・おまけ
　弊社のサービス
　Ｄｏｃｋｅｒ　Ｈｕｂにイメージがある（メールソフトまで入っている）
　　→さくらでもやっている
　Ｄｏｃｋｅｒ　Ｈｕｂで、otrs5を検索

ＮｏＳＱＬ、特にHBaseの話をきいてきた

３月１０日、オープンソースカンファレンス　Tokyo 2017 springで

ＮｏＳＱＬって結局どうなの？～HBaseを例に検証してみました～

を聞いてきたのでメモメモ

---

・自己紹介

・今日のお話

　ＩｏＴとＮｏＳＱＬ→HBase

・ＮｏＳＱＬとは
　ＲＤＢ以外
・一般に言われるＲＤＢの課題
　ビッグデータの３つのＶ
　　多様性
　　量
　　頻度
・ＲＤＢの特徴
　　データモデル：表形式→２列に
　　トランザクション機能→整合性不要
　　問い合わせ言語：ＳＱＬ→ＲＥＳＴ　ＡＰＩに
　→ＲＤＢの機能を絞る：ＮｏＳＱＬ

・世に中には、たくさんのＮｏＳＱＬ
　→データモデルで分類
　　キーバリュー型
　　ドキュメント型
　　ワイドカラム型：カラム指向ＤＢ列方向高速
　　グラフ型
　→複数のマルチモデル型というのがある

・HBaseの概要
・HBaseはワイドカラム型、バイト列で格納
・HBaseはHadoopの分散ファイルシステムHDFS上に構築
　３つのコンポーネント
　　HBase
　　YARN
　　MapReduce
　→この下にHDFS

・HBaseはマスタースレーブ
・HBaseのデータ管理
　　→HBaseはリージョンという単位でデータを分散する
　　　HBase→Namespace→Table
　　Tableは一見するとＲＤＢのような表形式に見える
　　実際はキーバリューで格納される
　　　Rowkeyの範囲とColumnFamilyの値でストアされる
　JavaAPI,HBaseシェル、ＲＥＳＴ　ＡＰＩ
　　ＳＱＬは使えない（Ｐｈｏｅｎｉｘ経由なら可能）
　　とらんざくしょん（Ｏｍｉｄをつかう）
・ＴａｌｌＴａｂｌｅとＷｉｄｅＴａｂｌｅの違い
　　スキャンはＴａｌｌＴａｂｌｅ
　　トランザクション　ＷｉｄｅＴａｂｌｅ
　　データの分散　Ｔａｌｌ
・書き出し
　リージョンサーバー
　ログ書く
　リージョン決定
　ストア決定
　memstore書き出し
　HFileに書き出し(定期的にこんぱくしょん）

・よみこみ
　リージョンサーバー
　ブロックキャッシュ
　memstore
　HFile
　→Blockキャッシュへ読んだもの書いておく

・検証
　スマートデータから収集したデータの管理
　検証項目
　　１．格納性能
　　２．圧縮性能
　　３．参照性能
　そると、めーたーＩＤ、電力消費量格納
　マルチスレッドで実行
・格納結果
　　送信クライアント数が多いほど格納は早い
　　リージョン数が少ないほうが格納スループット高い
　　リージョン数２００、送信クライアント６４でスループット３８万レコード／秒
　　１リクエストで複数レコード格納すると向上
　　マルチクライアント環境で性能発揮

・圧縮結果
　　エンコーディング
　　　PREFIX
　　　PREFIX_TREE：トライ木
　　　DIFF：差分
　　 FAST_DIFF：
　　GZIP圧縮大きい
　　組み合わせた場合、GZ+FAST_DIFF
　　サイズ１９％に減少、格納時間は増加

・参照結果
　少数データ（グラフ表示など）
　　１回のスキャンで１メーターとるとすると
　　メーターをスキャンでまとめて取得する
　→複数メーターをスキャンするとき、取得スレッド数を増やすとスループットが向上する
　多数データ（平均値をもとめるとか）
　　Ｇｅｔリクエストを使用：時間が離れているのでスキャンできない
　取得の並列度をあげることでスループットは向上
　Scanでまとめて取得できるように

・まとめ
　HBaseワイドカラム型のＮｏＳＱＬ、キーバリューストア
　分かったこと
　　スキャンでまとめて設計できるように
　　マルチクライアント・マルチスレッドで性能発揮
　　データ圧縮したほうがよい

「スマート向上の最先端は「中小企業」「ベンチャー」にあり！！」を聞いてきた！

3月9日、Cloud Days Tokyo 2017の

スマート向上の最先端は「中小企業」「ベンチャー」にあり！！

に行ってきたので内容をメモメモ

---

ファクトリー　４年目：いままで大企業、今回中小企業

【企業の取り組み】
・双葉工業
　ヒカリグループ：自動車省力化
　双葉工業：ＦＡ装置の精密部品加工など　４６名
　縦型ＭＣ，横型ＭＣ，複合旋盤など
　多品種少量生産
　経営課題
　　参加国のどこで作っても同じ本質
　　海外進出のリスク
　　技術継承

・カブク
　ベンチャー、創立４年目
　人工知能→製造業で生かせないか？　
　　ものづくりの民主化
　ファブレスベンチャー：工場をネットワーク化
　　→シェアリングエコノミー

　設計情報入力→自動マッチング→製造工場
　　３Ｄデータと各種製造要件より
　ＣＯＮＮＥＣＴとＭＭＳ

　お客様
　　ＴＯＹＯＴＡ，ＨＯＮＤＡ，スクウェア・エニックス
　事例
　　Ｈｏｎｄａ　マイクロコミューター
　　　分散製造ネットワーク
　　　電話１本ではとサブレ→１人用電気自動車
　メイキングムービー

・双葉工業から見てカブクは
　いろんなプラットフォーム
　グローバルな生産管理

・カブクさんから見て双葉工業は
　工場・メーカーのネットワーク
　現場でのネットワーク

・双葉工業の将来像
　グループネットワークの構築
　　図面情報の共有化とＣＡＤ，ＣＡＭ連携
　　作業の標準化と工具と切削条件の統一化
　　ビッグデータの解析と展開
　　生産管理システム

　中国でも同様のことを

・経緯は？
　ヒカリ鉄工所→ＦＡのとりくみ→ＣＡＤ→データをうまく→ＣＡＭ
　　２０年前からネットワーク・生産管理
　　今花開いて、加速

・カブクの将来像
　１個人のユーザーでも
　rinkak ctocのマーケットプレイス
　　３Ｄデータのアップロード

・Ｈｏｎｄａプロジェクトのチャレンジ
　　おおきな３Ｄプリンタ
　　同時に２、３社の工場展開

・３Ｄプリンタ：イメージしたものがすぐできる
　→試作品に有効、視野が広がる

・技術の活用
　現状の生産管理システム
　　・共有化は出来てきている
　生産管理システム
　現状の生産管理システムでは出来ないこと
　　ＪＴＥＣ　ＡＡＡ（とりぷるえー）
　　　オープンプラットフォーム
　　　設備管理
　　ＪＴＥＫＴ　ＩｏＴ
　　　工具寿命管理
　　　横型マシニングに機械の情報
　　　　工具の寿命
　　　　設備保全管理
　　　　進捗管理
　　表面処理：日本の技術はすごい！→３Ｄに応用（ここではいえない）
　　研磨：３Ｄ素材の相性としてよいのでは？

・見える化で技術の継承
　品質管理
　切削加工
　加工段取り
　工具の知識

　工程指示書→ワークセット→加工指示書：モノと情報に埋もれた個人作業
　パレットシステム・段取りステーション

　部品セット：パレットと一緒に流れる
　機械へ運ぶ：工程指示書、補正値、加工プログラム
　補正データ入力
　加工

　三位一体のグローバル

・カブク
　自ら変わることを恐れない
　どうミックスするか

クボタの自動運転トラクター、ＡＩ使ってないらしい？

そう、聞こえたんだけど・・・


3月9日、Cloud Days Tokyo 2017の

クボタのスマート農業戦略

に行ってきたので内容をメモメモ

---

・クボタの概要
　東京での知名度低い

・ＩｏＴを活用したスマート農業

１．クボタの概要
　農機・エンジン　１億　世界三位　６５％
　建機：小型建機に特化　Ｎｏ１
　パイプ・水処理

　日本で３５％、北米３０％、欧州１２％、アジア１９％　グローバル

　ミッション：食料・水・環境

　グローバルメジャーブランドＧＭＢ
　　製品供給→課題解決→新しい
　　　→ＩｏＴでレベルアップ

２．ＩｏＴを活用したスマート農業
・課題　農業人口は大幅減少、高齢化
　プロ農家は増加・大規模化
　担い手が抱える課題
　　平均年齢６６歳→担い手が受け皿
　　多数ほじょう管理
　　　作業者管理
　　　収量、品質低下
　　生産コスト、差別化、人材育成、販路拡大
　→求められる作物を求められる時期に求められる量
・担い手に対するクボタの取り組み
　１．高性能、高耐久性（Ｍ７）
　　、低価格（ワールドシリーズ）
　２．営農ソリューション
　３．スマート農業システム
　４．米の輸出、６次産業化
・農業の機械化のステップ
　　第一　尽力築力
　　第二　動力化、常用か
　　第三　機械化
　　第四　スマート農業

・クボタスマートアグリシステム（ＫＳＡＳ）
　　儲かるＰＤＣＡ型農業
・ＫＳＡＳの全体

　　　　クラウド
（営農情報）（機械・作物情報）
農業経営者　　農業作業者

・食味収量コンバイン
　　蛋白を量っている
　　収穫しながら、ほじょうごとのばらつきの把握が可能
　　　→仕分けをすることで、外れおこめ
　　　　水分仕分け：感想コストの低下
　施肥（せひ）設計が可能→自動で肥料
　どれだけ土壌をカイゼンするか
→トップ農家のノウハウを活用してＰＤＣＡをまわす
　２０１１年～２０１３年　モニターテスト
　　収量の増加１５％
・営農支援　１３００件（３６００くらいのお客様）
→一足飛びに１万、２万にはいかない
　本格コース　平均４０ha,150枚
・方向性
　　機械化一環体制
　　日本型精密農業の確立
　　 　　ＮＴＴとの包括契約
　　ＡＩなどによる高度営農支援システムの構築
　　　　最適作付け
・ＩｏＴロボット技術
　超省力・自動化

　ステップ１：オートステア（ハンドル操作なし）
　ステップ２：有人監視での自動化・無人化（協調運転）
　ステップ３：完全無人化（遠隔でほっておく）

　今ステップ１、２

　畑作向け大型トラクター
　　１７０馬力、フランス北部向上　ＧＰＳを利用したオートステア
　欧米の農業の紹介
　　ヨーロッパ、アメリカのメーカーを買収、作業機と一体化
　　北海道では使われている
　傾斜、夜間運転、カーブＯＫオーバーラップなくなる→ロスがなくなる

　直進キープ機能付き田植え機（２０１６年秋リリース）
　　熟練者でも作業ストレスが大きい
　　アルバイトが熟練しない
　　苗補給・効率悪い
　　既存のオートステアリング：日本は対応できない
　　Ｄ－ＧＰＳと姿勢制御ユニット（制御に工夫）安価に
　　安心機能
　→２０００件以上のモニター試験、高い精度（１００ｍで誤差１０ｃｍ）
　　→ＡＩを使っていないで出来る制御方法を開発

　基準線を覚えこませるだけ→平行移動：手放し運転、女性が1人で

　協調制御
　協調作業トラクタ（開発中）
　　ルート生成、マッピング、画像センサーとのセンサーヒュージョン
　人間がいたら停止：センサーフュージョン

・データ農業との平行進化→スマート農業
　農家の形態に応じて切り売り、サポート

・アシストスーツ
　　ラクベスト：ぶどう園　炭酸電池４本
　ウインチ型パワーアシスト
　　４段まで上げ下げ出来る（かっこよくはないが・・）

・提供する価値
　１．儲かる農業の実現
　２．環境負荷削減

まとめ
・新しいソリューションの普及・定着活動
　若い人はいいけど、なかなかたいへん
・システムの拡充と改良
・スマート農業のための基準・規格・インフラつくり

３．クボタファームでの実践

みなさんとオープンイノベーションで新しい価値