お仕事がんばるぞい

「NEW GAME!」とか「社畜ちゃん」とか、お仕事ネタの作品が最近話題になってますね。
がんばるぞい!が最初に話題になったのはもう2年前ですが・・・。

どうも、オタク方面担当の三浦です。

来週の土日に予定している、今年の慰労会(全体会議&社員旅行)の幹事長まで任されちゃってます。
まぁ行先を大洗を挙げた代償なんですけどね!!
ブログの担当があと1週間遅ければ、慰労会の内容をネタに出来たのになぁ・・・・・・。

今まで大したことを勉強してこなかったせいで、既にネタ切れなのですが・・・。
この前、社畜ちゃんの単行本に載っていたJavaScriptを書いてみました。
大学の時以来だから、5年ぶりくらいに触ったな・・・。

後半を何も見ずにフンフンちやってみましたが、
箱を開けてみたらランダムとif文でおみくじを作る感じでした。
そりゃまぁ参考書でもない漫画に載ってるものなのでそんなレベルなんでしょうけど。
久しぶりにプログラム書きましたが、やっぱり楽しいなぁと。
社畜ちゃんの職場は勘弁ですが。

今の職場はNEW GAME!ほど温い感じではなく、社畜ちゃんほど厳しくはない感じで。
特に不満は無いです、無いですが・・・
可愛い美少女が一杯の職場いいなぁ・・・。

人にモノを教えるということ

ご無沙汰しております。
ishizawaです。

最近急に寒くなってきましたね。
先週体調を崩して熱を出したのは私です。
皆さんも体調には気を付けましょう。

今日は私が最近よく行う新人の教育について整理も兼ねて書こうと思います。

インド出張

インドへ出張

iPXの鹿又です。
また出番が回ってきました。

iPXの私の所属するユニットでは、仕事柄、海外出張があります。
この間には、Kawaguchiさんがアメリカ出張に行ったことを書いていました。
これまで他の人も含め、フィリピン、インドネシア、台湾、ドイツ、アメリカ、中国への出張がありましたね。
いろんな人がいろんな場所に行くことがありますが、私は7月にインドに出張に行ってきました。

行った場所

出張先はインド南部 コインバトールというところで、あるサプライヤの開発部隊のあるところです。
成田空港より飛行機で8時間30分、デリーで一泊、国内線で3時間と、移動だけで20時間ぐらいの長旅になります。

公用語は英語が含まれるため、かなりのお年寄り以外は英語で話せました。
とはいっても、一緒に行った2名と私を含め、英語が堪能にできる人は1人もおらず、意思疎通に苦労するという状態でした。
サプライヤの日本人担当者に会うまでの間、「これはたどり着けるのか?」と心配になってしまいます。
ここに2週間、英語漬けの日々が始まります。

ホテルから撮った写真です
結構綺麗です

小観光

2週間の行程でしたので、土日を挟むわけです。
地元の人に案内いただいて小観光を楽しみました。

寺院

内部は撮影禁止
シヴァ神を祭った寺院
有名な寺院だそうですが、名前はよくわかりませんでした
ありがたいお祈りをいただく (インドの人がよく額に付ける灰と赤いもの)

沐浴場

自然公園に地元の人が使う沐浴場があるということで行ってみました
雨の後なので水量が多い

自然公園の看板

自然公園内

滝

沐浴場

サプライヤの日本人担当者が地元民と沐浴していました
地元の学生が「ネパール人か?」と聞くので「日本人だ」と答えると、やたら一緒に記念写真を撮られました。

おさるさん

人にとても慣れている (悪い意味で)

その他にも、カメレオンやらがいました。
野良象が見えるときもあるそうですが、運はよくなかったみたいです。

ヨガセンター

有名なヨガセンターに行ってみました。
もちろん、内部は撮影禁止
中は沐浴しながらヨガする場所や音厳禁で洞窟内でヨガする場所などがありました。
全員で洞窟内で座って瞑想するヨガをやりました

シヴァ神の大きな胸像 (入口付近)

ショッピングセンター

お土産を購入

ぞうさん

うしさん

地元の祭り

子供がある年齢になるとやる祭りだとか

街並み

食事とか

あまり食事の写真を撮りませんでした...
ほとんどはホテルで食事を採り、周辺で食べることはなかったです。
ホテルではビュッフェ形式。
だいたい毎日カレーだったので、日に日に皆が窶れていくのがわかります。
きっと日本人は本場のカレーから栄養は採れないようになっているのだと思います。

カレーとか

種類は豊富
南部ではライスが主食でナンはあまり食べない感じ

ドーサ

ちょっと酸味のあるクレープのようなもの
マサラとかつけて食べる
美味しい

デリー国際空港のラウンジでもカレーが......

日本に帰ってきて

一番初めに食べたのは幸楽苑のラーメンです。
幸楽苑のラーメンが本当に「旨い」と感じました。
カレーもいいですが、慣れた味が一番ですね。
帰国後、まだココイチには行っていません。

サプライヤとの会議はおおむねうまくいきましたが、まだまだ状況がよくなっている感じではありません。
また行くかもしれません。
不満なのは出張ではなく、サプライヤのソフトがいつまでも未完成であるということです....

「安全」と「安心」

約半年ぶりに登場します、加藤です。

今回は「安全」と「安心」について取り上げてみたいと思います。

はじめに

テスラの自動運転車（実際は自動運転ではなく運転支援機能なのですが）が死亡事故を起こしたり、豊洲市場の地下が空洞になっていたり、というニュースが世間を騒がせていますが、どうも一般向けのニュースでは安全と安心を混同したまま語られているように感じます。

では「安全」と「安心」の違いは何でしょうか？
この二つの言葉の意味を説明できますか？

弊社も製造業、特に自動車業界に関わる企業と仕事をさせて頂いていますので、正しく理解している必要があります。

「安全」と「安心」の違い

「安全」の定義はISOの中では用語として定義されています。

Safety
freedom from risk which is not tolerable
（許容できないリスクがないこと）

Risk
combination of the probability of occurrence of harm and the severity of that harm
（危害の発生確率とその危害の重大性の組み合わせ）

（ISO/IEC Guideより引用 https://www.iso.org/obp/ui/#iso:std:iso-iec:guide:51:ed-3:v1:en）

ここで重要なのは「許容できないリスク」という表現でリスクの範囲を限定していることです。
リスクの定義も合わせて考えると、確率が低くて重大ではない危害まではカバーしていない、という事が分かります。

「安全」は「完全」ではないのがポイントです。

一方で「安心」については標準的な定義はありませんが、安全と対比しておおよそ以下のように定義されています。

安全：

• 客観的な事実
• 科学的に評価が可能
• 許容できないリスクがない状態

安心：

• 主観的な感情
• 科学的に（外部から）評価が出来ない
• リスクに対する寛容さは個人に依存する

安全はモノサシで測ることが可能ですが、安心は測ることが出来ない上に、安心かどうかの判断は完全に個人にゆだねられています。

「安心」できないのはなぜか？

上記の通り、安全と安心は異なる概念です。

多くの製造業ではISO規格などの品質マネジメントプロセスに則ることで「安全」を担保しています。

一方で一般の消費者にとって重要なのは「安心」です。

消費者に「安心」してもらうためには、製品を提供する側が「安全」であることを正しく説明することが必要です。

しかし、「安心」はは主観的な感情なので、全ての人に安心してもらうことは困難です。

なるべく多くの人に安心してもらうためには、以下のギャップを埋める事が必要となります。

その1：知識量のギャップ

ほぼ全ての事象において、説明する側は専門家であり、説明される側は素人です。
当然ながら、専門家と素人は持っている知識の量が異なる上に、素人の中でも知識量にもバラツキがあります。

また、

• 知識が無い人は、理解できないので不安に思わない
• ある程度知識がある人は、中途半端に理解するので不安度が高まる
• 十分な知識を持った人は、正しく理解できるので不安度は低い

といった傾向があるそうです。

その2：リスク感度のギャップ

安心と感じる基準は個人差があります。
さらに、特に不安度が高い人達には「ゼロリスクを求める」という傾向があります。

上記の「安全」の定義にあるように、基本的にリスクはゼロではありません。
想定できない範囲はもちろんですが、致命的でない問題については許容することがあります。

発生確率の非常に低い現象や危険度の低い現象など、小さなリスクまで対応するにはそれ相応のコストがかかります。
当然、そのコストは製品やサービスの価格にも反映されます。

この2つのギャップを埋めるためには、説明する側が相手のリテラシーを考慮した上で、説明の方法を工夫する必要があります。

消費者の安心を獲得するために

安心というのは信頼の上に成り立つもので、これらは一朝一夕で獲得できるものではありません。

日ごろから

• 正しい情報発信
• 的確な顧客サポート
• サービス、製品力の向上

に継続して取り組むことで、徐々に信頼感が蓄積されていくものです。

弊社では上記の取り組みの一つである「製品力の向上」を実現するための支援として、

• 開発プロセス全体の改善
• 新たな設計手法の導入
• 開発業務を支援する仕組み作り

をメニューとして取りそろえています。

SQLチューニング

SDU(System Development Unit)のタキヤマです

半年前にDB関係で何か記事を…と書いていましたが、
海老名/厚木で開催されていた某10周年のまつりが忙しい中
順番が迫っているのを知ったので、何の準備も無いまま書いてみようかと思います。
（まつりの記事書いたら突き返されるかな？）

…とはいったものの、チューニング関係だとやっぱり実際にDB作って計測しながらでないと書くのは難しいので
とりあえず今回はSQLに少し触れてみます。

これもDBの種類やバージョン、データの状態とかオプティマイザの実行計画等々…によって
何が最適なのかは変わってきてしまうのでこう書けば必ず早くなるといったものでもないです。

例えば以下のようなものがあります。

INよりEXISTSを使う ※Oracle, PostgreSQL除く

--【遅】
SELECT * FROM A WHERE A.id IN(SELECT B.id FROM B);
--【早】
SELECT * FROM A WHERE EXISTS(SELECT * FROM B WHERE A.id = B.id);

EXISTSでは*を使う

--【遅】
SELECT * FROM A WHERE EXISTS(SELECT B.name FROM B WHERE A.id = B.id);
--【早】
SELECT * FROM A WHERE EXISTS(SELECT * FROM B WHERE A.id = B.id);

COUNTはCOUNT(列)を使う ※Oracleを除く

--【遅】
SELECT COUNT(*) FROM A
--【早】
SELECT COUNT(id) FROM A

WHERE句の列に対して演算や関数を使うとインデックスが使用できない

--【遅】
SELECT * FROM A WHERE num * 10 > 100
--【早】
SELECT * FROM A WHERE num  > 100 / 10

ORはなるべくINを使う

--【遅】
SELECT * FROM A WHERE name = 'a' OR name = 'Bb'
--【早】
SELECT * FROM A WHERE name IN ('a','b')

ORDER BY句では列番号を使わない

--【遅】
SELECT id, name FROM A ORDER BY 1
--【早】
SELECT id, name FROM A ORDER BY id

テーブルの結合は絞り込んでから行う

--【遅】
SELECT * FROM A, B WHERE A.id = B.id AND B.num > 100;
--【早】
SELECT * FROM A, (SELECT * FROM B WHERE B.num > 100) C WHERE A.id = C.id;

などなどなどなど
書ききれないくらい色々あったりします。

では最後に
こんな3つのテーブルがあるとします。
主キー、外部キー以外にインデックスは作成しないものとします。
※SQLは標準SQLでは無くOracle準拠です

CREATE TABLE item (
	item_id		NUMBER	PRIMARY KEY
,	item_name	VARCHAR(40)
,	price		NUMBER
);


CREATE TABLE customer (
	cstmr_id	NUMBER	PRIMARY KEY
,	cstmr_name	VARCHAR(40)
,	age		NUMBER
);


CREATE TABLE order (
	order_id	NUMBER	PRIMARY KEY
,	item_id		NUMBER
,	cstmr_id	NUMBER
,	order_date	DATETIME
,	FOREIGN KEY (item_id)	REFERENCES item (item_id)
,	FOREIGN KEY (cstmr_id)	REFERENCES customer (cstmr_id)
);

20代の20時～22時の注文のうち、新しいものから順に1000件の中で
売上合計が高い商品順に並べる。

これを以下のようなSQLで検索しようとしたところ
想定していたよりもレスポンスが悪い結果となりました。

ではこのSQLをどのように書き換えたらレスポンスが改善できるでしょうか？

SELECT	NarrowOrder.item_name	as "商品名"
,	COUNT(*)		as "売上件数"
,	SUM(NarrowOrder.price)	as "売上合計"
FROM  (
	SELECT	item_name
	,	price
	FROM  (
		SELECT	item.item_name
		,	item.price
		FROM	order
		,	customer
		,	item
		WHERE	customer.cstmr_id	= order.cstmr_id
		AND	item.item_id		= order.item_id
		AND	customer.age		>= 20
		AND	customer.age		< 30
		AND	TO_CHAR(order.order_date, 'hh24:mi:ss') >= '20:00:00'
		AND	TO_CHAR(order.order_date, 'hh24:mi:ss') <  '22:00:00'
		ORDER BY	order.order_id	DESC
	)
	WHERE	ROWNUM >= 1000
) NarrowOrder
GROUP BY	NarrowOrder.item_name
ORDER BY	3	DESC
;

以下のSQLは一例となりますが、
おそらく先程のSQLと比較すると、
データ量が多ければ多いほどはっきりと差が出てくると思われます。
（実際に試してはいないので説得力は弱いですが）

SELECT	item.item_name	as "商品名"
,	COUNT(*)	as "売上件数"
,	SUM(item.price)	as "売上合計"
FROM  (
	SELECT	item_id
	FROM	(
		SELECT	item_id
		FROM	order
		WHERE	cstmr_id in (	SELECT	cstmr_id
					FROM	customer
					WHERE	age	>= 20
					AND	age	<  30
				)
		AND		TO_NUMBER(TO_CHAR(order.order_date, 'hh24miss')) BETWEEN 200000 AND 220000
		ORDER BY	order_id	DESC
	)
	WHERE	ROWNUM >= 1000
) NarrowOrder
JOIN	item
	ON	NarrowOrder.item_id = item.item_id
GROUP BY	item.item_name
ORDER BY	SUM(item.price)	DESC
;

※1000件の絞込みはOracle12cからインラインビューでROWNUMを使わなくとも
　Order by句の次に「FETCH FIRST 1000 ROWS ONLY」と記載することも出来ます。

ポイントはデータの絞込みと結合の順番になります。

まずはユニークなデータであるcustomerを絞り込んでおき、
対象のデータを減らした上でorderと結合しています。

また、itemの結合をデータ件数の一番多いであろうorderでは無く、
検索条件を満たした上で1000件に絞った状態のNarrowOrderに対して行うようにしています。

注文時間の絞込みについては文字列で行わず、数値で行うようにし、かつBETWEENを使用するようにしています。

※インデックスを作成する場合はorderテーブルにcstmr_idとorder_dateの複合インデックスを作りヒント句で強制、日付型のままBETWEENを使わない方が早くなります

と、ここまで書いてみましたが、実際にはコストベースオプティマイザだと
しばらく使っているうちに統計情報からどんな実行計画が作られるかにもよってくるので
実践でのチューニングは色々と手間が掛かってくるわけです。

次回順番が回ってきた時は、実際のDBを使用したチューニングでもやってみようかと思います（たぶん）

あ、そろそろ今シーズンのスノボ旅行の予約もしないと…
今回も雪まつりと重なりそうなので、次回更新が北海道日記にならないように気を付けます

Abaqus CAEで会社ロゴを自動でメッシュ分割する

EPLU(Engineering Process Leading Unit)のパルハットです。

以前仕事現場でCAE関連の業務に関わりました。今回それに関係する内容で書こうと思います。

CAE関連のソフトはたくさんありますが、今回はAbaqus14 Student Editionを使用して、簡単な会社ロゴ(iPXの文字)のメッシュをスクリプトで作ります。
Abaqusはスクリプト言語としてPython2.6を使用できます。Pythonは完全にオブジェクト指向の構造です。

AbaqusではPythonオブジェクトとしてSession, Mdb, Odbが提供されています。SessionオブジェクトにはViewportの定義、リモートキュー、ユーザ定義Views等を含みます。
Mdbオブジェクトはモデル情報を含みます。Odbオブジェクトは解析結果データ関連情報を含みます。プログラム作成手順は以下のとおりです。

1. 初期定義とモデル定義
2. 2次元スケッチ作成
3. パート作成
4. アセンブリ設定
5. メッシュ作成

初期定義とモデル定義

from abaqus import *
from abaqusConstants import *
from caeModules import *

# モデルオブジェクトの作成
Mdb()
mdl = mdb.Model(name="Model-iPXLogo")

2次元スケッチ作成

# 2次元スケッチ作成
stk = mdb.models['Model-iPXLogo'].ConstrainedSketch(name='Sketch iPX', sheetSize=200.0)

# i字の作成
# 指定座標に円を作成
stk.CircleByCenterPerimeter(center=(-12.5, 10.0), point1=(-10.0, 10.0))

#指定座標に長方形を作成
stk.rectangle(point1=(-15.0, 5.0), point2=(-10.0, -17.5))

#　P字の作成
xyCoords=[[6.25, 12.5],[-5.0, 12.5],[-5.0, 12.5],[-5.0, -17.5],[-5.0, -17.5],
          [0.0, -17.5],[0.0, -17.5],[0.0, -2.5],[0.0, -2.5],[6.25, -2.5],
          [0.0, 2.5], [5.0, 2.5], [0.0, 2.5], [0.0, 7.5], [0.0, 7.5], [5.0, 7.5]]

for i in range(0, len(xyCoords) - 1, 2):
    stk.Line(point1=xyCoords[i], point2=xyCoords[i+1])

stk.Arc3Points(point1=(5.0, 7.5), point2=(5.0, 2.5), point3=(7.5, 5.0))
stk.Arc3Points(point1=(6.25, 12.5), point2=(6.25, -2.5), point3=(12.5, 5.0))

# X字の作成
xyCoords1=[[15.0, 12.5],[23.75, -2.5],[23.75, -2.5],[15.0, -17.5],[15.0, -17.5],[20.0, -17.5],
           [20.0, -17.5],[27.5, -5.0],[15.0, 12.5],[20.0, 12.5],[20.0, 12.5],[27.5, 0.0],
           [27.5, 0.0],[35.0, 12.5],[35.0, 12.5],[40.0, 12.5],[40.0, 12.5],[31.25, -2.5],
           [31.25, -2.5],[40.0, -17.5],[40.0, -17.5],[35.0, -17.5],[35.0, -17.5],[27.5, -5.0]]

for i in range(0, len(xyCoords1) - 1, 2):
    stk.Line(point1=xyCoords1[i], point2=xyCoords1[i+1])

作成されたスケッチ図は以下の通りです。

パート作成

#パートを作成します。
p = mdb.models['Model-iPXLogo'].Part(name='iPXLogo', dimensionality=THREE_D, type=DEFORMABLE_BODY)
p = mdb.models['Model-iPXLogo'].parts['iPXLogo']
p.BaseSolidExtrude(sketch=stk, depth=5.0)
session.viewports['Viewport: 1'].setValues(displayedObject=p)

作成されたパート図は以下の通りです。

アセンブリ設定

# アセンブリにパートをインスタンス化します。
iPXAssambely = mdb.models['Model-iPXLogo'].rootAssembly
iPXInstance = iPXAssambely.Instance(name="iPXLogo A-1", part=p, dependent=OFF)

作成されたアセンブリ図は以下の通りです。

メッシュ作成

# メッシュを作成します。
partInstances = [iPXInstance] 
iPXAssambely.seedPartInstance(regions=partInstances, size=2.0)
iPXAssambely.generateMesh(regions=partInstances)

# viewportでメッシュインスタンスを表示します。
iPXViewport = session.Viewport(name="ipx viewport", origin=(10,10), width=400, height=200)
iPXViewport.assemblyDisplay.setValues(renderStyle=SHADED, mesh=ON)
iPXViewport.setValues(displayObject=iPXAssambely)

作成されたメッシュ図は以下の通りです。

まとめ

今回Abaqusを使用して簡単なロゴを作成して、メッシュまで作りました。メッシュサイズをもっと小さくすると、刻みがきれいに出来ます。
次回は材料情報の追加と何らかの境界条件を追加して、解析コンター図まで出してみたいです。

参考情報

1. http://www.jikosoft.com/cae/abaqus/index.html
2. Abaqus14 Student Editionドキュメント（インストール時に一緒にインストールされます。）

■

どうも。VFDU(Vehicle Function Development Unit)のカワグチです。

先日海外へ出張させていただいたので、その時の運転訓練の話をば少々。
写真と一緒に振り返ってみます。

初めての海外出張inアメリカ

ことの始まりは上長からの依頼。
業務としてアメリカ合衆国オハイオ州へ出張してほしいと打診があり、
私と同僚の二人で渡米することとなりました。

宿泊先はオハイオ州のとある街のホテル。
出張先は街はずれにある建屋でした。
ホテルから建屋まで自動車で60分程度かかり車での移動が必要不可欠なため、
レンタカーを借り、不慣れな右側通行・左ハンドル車両の運転訓練(慣らし運転)を行いました。

運転中に驚いたこと

・とにかく道路が広い
一般道もフリーウェイもアメリカサイズでした。

・とにかく道路が真っ直ぐ
特にフリーウェイはとにかく直線(と緩いカーブ)で長距離運転しても疲れませんでした。

・フリーウェイが無料
日本の高速道路のように料金を支払ったりしません。うらやましい！

・速度はマイル表示
アメリカなので当たり前ですが、車の速度メーターの表示がマイルでした。
フリーウェイは70mph(≒112km/h) 制限の箇所が多かったです。

・赤信号でも右折可
他車両が接近していない等、安全であれば赤信号でも右折することができます。
※ただし「NO TURN ONRED」の標識がある場合は赤信号時の右折禁止。

・果てしなく続くトウモロコシ畑
映画で観たことあるやつ

・ノーヘルライダー
映画で観たことあるやつ
※オハイオ州では基本的に１８才以下のみ要。詳細は下記参照。

所感

今までほとんど海外に行ったことがなく苦手意識がありましたが、
今回ありがたいことにお仕事で海外経験をさせていただきました。
おっかなびっくりの海外出張でしたが、
日本と比べて良いところ悪いところを発見するという楽しみを知れて良い勉強になりました。
次はプライベートで海外旅行というのも悪くないと思います。

最後に、出張中に色々対応して下さった方々、出張先でお世話になった皆様、ブログを読んで下さった読者様、どうもありがとうございました。

参考URL

車でアメリカを走るために必要なもの、交通ルール
abroad.driver.jp
www5b.biglobe.ne.jp
アメリカバイク事情
アメリカツーリング情報／交通規制ガイド／ヘルメット規制 - WWW.NPNY.COM

おまけ(オハイオの食事)