CCT blog

Core Concept Technologies Inc.

main_contents

更新情報

工場(製造現場)向けIoTソリューション

自社のIoTシステムを利用した工場(製造業)向けソリューション「Orizuru」は、工場内の各種設備からデータを収集する「ゲートウェイ」、収集したデータ処理をする「データプラットフォーム」、リアルタイムにデータを見える化する「ダッシュボード」、3D CADデータをブラウザ上で表示する「3Dビュー」などの各システムを備えるトータルソリューションになります。

IoTソリューション「Orizuru」では、これらの各ソリューションの個別提供から、「ゲートウェイ」「データプラットフォーム」「ダッシュボード」をパッケージングした「Orizuru IoT」の提供をしております。また、3Dデータをクラウドで管理、表示、検索できる機能を備えた「Orizuru 3D」の提供もしております。

IoTソリューション全体像

IoTソリューション全体像

  • 設備のデータ収集
  • 設備の制御
  • 他のシステムへのデータ連携
  • サーバとのデータ送受信
  • リアルタイム通信
  • リアルタイム検知・通知
  • データの統計処理と機械学習
  • データ保存先選択
  • 各種データのグラフ化
  • 設備ごとの見える化
  • 設備のコントロール
  • ユーザ管理
  • 3Dデータの各種表示
  • 3Dデータの360°ビュー
  • 大容量データの表示

IoTソリューション「Orizuru」の特長

様々な設備のデータ収集
工作機械で使用するCNCやPLC、産業用ロボット、温度や振動などのセンサーなどのデバイスから各種データを収集することが可能です。様々なデバイスからデータを集約して収集できることで、管理メリットが生まれます。
データの他システムへの連携
昨今様々なwebサービスがありますが、それらの各種webサービスへのデータ連携が可能です。例えば、見える化のwebサービスやBIツールなどへのデータ連携、それ以外にも社内システムへ連携することができます。
データの一元管理
Gateway(ゲートウェイ)から送られてくる様々なデータを一元管理します。様々なソリューションやサービスを使うことによるデータ管理コストを抑えられ、御社の貴重なデータ資産を管理します。
AI、機械学習によるデータ活用
解析したデータを活用し、不良品の検知や製品需要予測、設備異常の検知、製品の故障予測などに繋げることができます。お客様の課題にあわせて必要なデータを取得することから始めていきます。
自動化、予兆保全の実現
AI・機械学習により予測や異常検知できたことをキーとして、次のアクション、すなわち自動化や予兆保全を実現することが可能です。データ活用としてコスト削減や品質改善などを実現します。
各種データのグラフ化
データを目的に応じて表示を変えることが可能です。時系列データーであれば折れ線グラフ、累積データであれば円グラフや棒グラフなどの形式で表示でき、データの取得間隔を狭めることで、リアルタイムデータでの表示も可能です。
巨大な3Dデータをwebで表示
数十GBに及ぶ巨大な3Dデータもスムーズにレンダリングして表示することができます。また、専用ソフトを必要とせず、様々な形式のデータをWebブラウザやスマートフォンで確認することが可能です。
3Dデータの検索
管理しているデータから類似する3Dデータを検索できます。データ形式を問わず、異なる3Dデータを横断して検索可能です。3Dデータ作成前に類似データを確認することで、設計の二度手間を防ぐことができます。
点群データを扱える
CADデータだけでなく、点群データも管理できます。従来は別々に管理していたデータを結合することで、複数のソフトウェアを立ち上げてデータを検索しなければならないといった手間がなくなります。

Orizuru IoT

工場IoT

Orizuru IoTは設備を制御しているCNCやPLC、ロボット、各種センサーとゲートウェイが通信することでリアルタイムにデータを取得、蓄積していくことが可能です。 Orizuru IoTは、マルチデバイス対応ができる国内唯一のソフトウェアです。多くのお客様が実現したいと考えられている、工場、ライン、設備単体の稼働監視や故障原因の特定も、Orizuru IoTでデータを取得することで可能になります。ゼロベースからIoTシステムの開発をすると大規模投資が必要になります。Orizuru IoTならば短時間で設備との通信を確立させることが可能です。 Orizuru IoTによって工場のスマート化を実現させてください。

Orizuru 3D

3Dデータのweb表示

Orizuru 3DはCAD・点群などの3Dデータを統合管理するソフトウェアです。これまで扱えなかった数十GBに及ぶ容量の巨大な3DデータをWebブラウザで表示できます。それぞれのデータ形式ごとの専用のソフトウェアを使う必要はありません。また、類似する他の3Dデータを、データ形式を問わず横断的に検索できます。クラウドサービスとして提供しているだけでなく、セキュリティや通信速度などのご要望に応じてオンプレミス環境で社内ツールとしてもご利用いただけます。​

「Orizuru 3D」の詳細はこちら

IoTソリューション紹介動画

IoTのお悩み解決

 お客様からIoTに関する様々なお悩みをご相談いただいております。IoTの導入に関することやデータの取得方法、取得したデータの活用方法や見える化など多岐にわたります。このようなお悩みごとに対して弊社としてもなんとか解決したく、日々ご提案をしています。こちらでは、その内容の一部をご紹介します。

パートナー・会員

三菱電機のe-F@ctoryパートナー

e-F@ctory Allianceとは、弊社FA機器との接続親和性の良いソフトウェア・機器を提供するパートナーとそれらを活用しシステムを構築するシステムインテグレーションパートナーとの強力な連携により、お客様に最適なソリューションを提供するためのFAパートナープログラムです。

  • e-F@ctory Allianceの詳細は、こちら をご覧ください。

e-F@ctory Alliance

AWSパートナーネットワーク(APN)

弊社はAPNコンサルティングパートナーとして、AWS上での顧客のワークロードとアプリケーションの設計、開発、構築、移行、および管理を支援することが可能です。AWSのシステムインテグレーションやアプリケーション開発などご相談いただけます。

AWSパートナーネットワーク(APN)

BECKHOFF社の開発パートナー

2018年よりベッコフオートメーション株式会社 の開発パートナーとして、弊社はソフトウエアの開発をサポートさせていただいております。BECKHOFF社製品とソフトウエアとのコミュニケーションを円滑にできる技術支援などを行わせていただいてます。

BECKHOFF

ORiN協議会の会員

ORiN (Open Resource interface for the Network)とは,メーカ・機種の違いを超え、統一的なアクセス手段と表現方法を提供する通信インターフェースです。ロボット、PLC、NC工作機械などの制御装置の情報にアクセスするための標準仕様であり、ORiN2SDKとして実用化されています。

ORiN協議会

次元の呪い

はじめに

 今回は、「次元の呪い」に関連した3つの話題を解説する。

次元の呪いとは?

 次元の呪い(The curse of dimensionality)とは、次元数を高くしたとき、3次元までの常識からは予想できない特異な振る舞いが出現することである。リチャード・ベルマン(強化学習で有名なベルマン方程式のひと)が1957年の論文で初めて使った概念である。以下3つの具体例で見られる高次元の特異な振る舞いを解説する。

  1. 高次元空間における球の体積と表面積の比
  2. 高次元空間における球の体積と球に外接する立方体の体積の比
  3. 高次元正規分布

高次元空間における球の体積と表面積の比

 最初に、2次元空間内の半径rの円を考える。このとき、円周S_2(r)と面積V_2(r)は次式で与えられる。

(1)    \begin{eqnarray*} S_2(r)&=&2\pi r \\ V_2(r)&=&\pi r^2 \end{eqnarray*}

次に、3次元空間内の半径rの球の表面積S_3(r)と体積V_3(r)を考える。

(2)    \begin{eqnarray*} S_3(r)&=&4\pi r^2 \\ V_3(r)&=&\frac{4}{3}\pi r^3 \end{eqnarray*}

一般に、D次元空間における球(これを超球と呼ぶ)の表面積S_D(r)と体積V_D(r)は次式で与えられる。

(3)    \begin{eqnarray*} S_D(r)&=&C_{D} r^{D-1} \\ V_D(r)&=&\frac{C_D}{D}r^D \end{eqnarray*}

ここで、C_{D}は定数であり、C_{2}=2\piC_{3}=4\piである。C_Dの正確な表式は、例えばBishop本の演習問題に掲載されている。表面積と体積の比を取ると次式を得る。

(4)    \begin{equation*} \frac{V_D(r)}{S_D(r)}=\frac{r}{D} \end{equation*}

したがって、D\rightarrow \inftyのとき、式(4)の右辺は0になる。すなわち、次元が高くなるほど体積よりも表面積からの寄与が大きくなるのである。このことはよく、次のように例えられることが多い。

高次元空間におけるメロンパンは表面のカリカリ部分が多くなり嬉しいが、高次元空間におけるシュークリームはクリームが減ってしまい残念である。

高次元空間における球の体積と球に外接する立方体の体積の比

 最初に2次元空間を考える。半径rの円の面積V_2(r)と円に外接する正方形の面積V_2^c(r)は次式で与えられる。

(5)    \begin{eqnarray*} V_2(r)&=&\pi r^{2} \\ V_2^c(r)&=&(2r)^2 \end{eqnarray*}

次に、3次元空間を考える。半径rの球の体積V_3(r)と球に外接する立方体の体積V_3^c(r)は次式で与えられる。

(6)    \begin{eqnarray*} V_3(r)&=&\frac{4}{3}\pi r^{3} \\ V_3^c(r)&=&(2r)^3 \end{eqnarray*}

一般に、D次元空間における立方体(これを超立方体と呼ぶ)の体積V_D^c(r)は次式で与えられる。

(7)    \begin{equation*} V_D^c(r)=(2r)^D \end{equation*}

したがって、球と立方体の比は次式で与えられる。

(8)    \begin{equation*} \frac{V_D(r)}{V_D^c(r)}=\frac{C_D}{2^{D}D} \end{equation*}

D\rightarrow \inftyのとき、式(8)の右辺は0になることを示すことができる(証明はBishop本の演習問題にある)。すなわち、高次元空間においては、球の体積の寄与が減るのである。

高次元空間では、箱に入れられた高級メロンはとても小さい。

さて、球の中心(立方体の中心でもある)から立方体の1つの角までの距離は\sqrt{r^{2}D}であるから(下図参照)、

球の半径rとの比をとると

(9)    \begin{equation*} \frac{\sqrt{r^{2}D}}{r}=\sqrt{D} \end{equation*}

となる。D\rightarrow \inftyのとき、式(9)の右辺は\inftyになる。すなわち、高次元空間における立方体の角は刺のように鋭く(スパイク状に)伸びていることになる。また、立方体の角の数は2^Dであるから、D\rightarrow \inftyのとき、角の数も\inftyになる。

高次元空間での立方体の形状は雲丹である。

ここで、モンテカルロ法を用いた\piの算出手順を紹介したい。図のような半径1の扇形を考え、以下の手順を行うことで\piの近似値を得ることができる。

  1. 変数sを0で初期化する。
  2. [0,1]の間の実数値を生成する乱数器を用いて座標(x,y)を作る。
  3. この座標が扇形内(x^2+y^2\leq 1,x\geq 0,y\geq 0)にあればsに1を加算する。
  4. この手順を適当な回数Nだけ繰り返す。
  5. 最後にs/Nを4倍すれば\piの近似値を得る。

ここで行っていることは、正方形内に生成した座標のうち、扇形内にある点だけを選ぶことである。これを高次元空間で考えた場合どうなるか。既に見たように高次元では、立方体(超立方体)に占める球(超球)の体積の割合は小さくなる。つまり、高次元になるほど、乱数で生成した座標が球内に収まる確率が小さくなっていくことになる。言い換えると、精度良く\piを求めるのに必要な座標の数が多くなっていくことになる。この現象は、次元の呪いが数値計算に及ぼす悪影響として良く取り上げられる。

高次元正規分布

 ここでは、高次元正規分布の振る舞いを見る。いま、D次元の等方的な正規分布を考える。

(10)    \begin{equation*} p_D(x)=\frac{1}{(2\pi\sigma^2)^{D/2}}\exp{\left(-\frac{\|x\|^2}{2\sigma^2}\right)} \end{equation*}

ただしx\in\mathbb{R}^Dである。このとき、確率分布p_D(x)の下での、ある量f(x)の期待値E[f]は次式で与えられる。

(11)    \begin{equation*} E[f]=\int dx f(x)p_D(x) \end{equation*}

積分範囲は全空間である。ここで、極座標変換を行う。f(x)が中心からの距離rだけに依存する場合、上式は以下のように変形することできる。

(12)    \begin{eqnarray*} E[f]&=&\int_0^{\infty} dr f(r)q_D(r) \\ q_D(r)&=&\frac{C_D\;r^{D-1}}{(2\pi\sigma^2)^{D/2}}\exp{\left(-\frac{r^2}{2\sigma^2}\right)} \end{eqnarray*}

C_Dは既出の定数である。ここで、関数q_D(r)に指数函数だけでなく、D-1次の項(r^{D-1})が現れることが重要である(この事実は、極座標変換を行ったときf(x)が角度依存性も持つ場合でも成り立つ)。関数q_D(r)の様子を下に示す。

Dが大きくなるに従い、極大値の位置が中心から離れていくことが分かる。極大値の位置\hat{r}q_D(r)を微分すれば容易に求めることができ、\hat{r}=\sqrt{D-1}\sigmaとなる。以上の事実を踏まえて期待値の式

(13)    \begin{equation*} E[f]=\int_0^{\infty} dr f(r)q_D(r) \end{equation*}

を眺めると、次元が高くなるほどf(r)の中心近傍の振る舞いが結果に反映されなくなることが分かる。この現象は、既に見た球の体積と表面積の関係や、球と立方体の体積の関係とよく似ている。高次元ほど、中心ではなく端の影響が大きくなるのである。

高次元正規分布は半径\hat{r}の超球の表面にへばりついた分布になる。

このことは、高次元正規分布を用いてサンプルされる点のほとんどは、球の表面近傍の点であると表現することもできる。これはモンテカルロ法などサンプリングを必要とする数値計算を行うときに注意しなければならない点である。

まとめ

 今回は、高次元空間では直観とは異なる現象が起きていることを見た。球の表面積と体積の関係や、立方体と球の体積の関係で解説したように、高次元空間内の点は、そのほとんどが中心から離れた薄い皮の表面にへばりつくように分布する。この事実が計算効率を落としたり、精度を維持するために膨大な数のデータ(空間内の点に対応する)を必要とする原因となる。同じ現象が正規分布でも起きていることを示した。機械学習や深層学習では高次元ベクトルを当たり前のように扱うが、「次元の呪い」があることに留意しなければならない。

見積もりと心理的安全性

アイスブレイク

A:「これどれぐらいでできそう?」
B:(自分が集中して取り組めば…)「5日ぐらいですかね~」

スケジュール:今日~5日後

ちょっと待てーーーい!

B:「5日ぐらいとは言ったが、5日後にできるとは言っていない… それには私がもう1人必要です…」

みたいな開発現場小話、ありますよね?
この話にはツッコミどころが色々ありますが、最大のポイントは
「見積もりがコミットメントになっている」というところ。

今回は見積もりの不確実性の話です。

見積もりの不確実性

みなさんご存知、不確実性コーンですよ。

知らなくても大丈夫、要は「見積もりって上手くいかんよね」って言ってるだけです。
https://xtech.nikkei.com/it/article/COLUMN/20131001/508039/

100%正確な見積もりなんて存在しない?
いえいえ、ここだけの話、ありますよ。
これ企業秘密なんですけどね。

見積もり期間中に実際に作ってしまう → なんと実際に掛かった時間だから100%正しい!

まあ見積もりにめちゃ時間掛かるんですけどね。半年ぐらい?
明日からレッツトライ!

コミットメント(約束)

冗談はさておき、見積もりって本来約束とは関係ないはずなんですよ。
でもなぜか約束=コミットメントになりがち。

約束って破ると怒られるじゃないですか。
5日って言ったのに8日掛かってるやん、理由と対策を述べなさい、的な。

ふつう人間て怒られるの避けますよね?
(世界は広いので… 怒られるのが好きな人も… 居るかもしれないけれど…)

なのでみんなバッファを積むわけですね。
5日で終わると思うけど安全を見て8日、とか。

そうするとですね、、、見積もりがファットになるんですよ。

そしてみんなバッファを積むもんだから
マネージャー:「ふーん、みんなそんな感じだしそんなもんなんかなー」

と思うわけですよ、そして大体予定通り終わるんですよね
余裕を見たはずなのにぴったり終わる、あらふしぎ。

これマネージャーから見ると

  • 予定通りスケジュールは進んでる
  • メンバーが暇してるとかなくて無駄がない様に見える

何も問題がない。みんな幸せ。めでたしめでたし。

開発速度低下

誰も遊んでるわけじゃないのに開発スピードが遅い気がする。。。
そうそんなプロジェクトは「スケジュール通りの罠」にはまっています。

この罠、気づき辛いんですよね。
スケジュール通りで目標達成率100%ですからね。
誰も困らないし、何も問題ない(様に見える)

実際に俯瞰して見ると「ただ目標が低いだけ」なんですが、それに自ら気づくことは難しいのです。
※本人たちに自覚がない場合が多い

心理的安全性

何年か前に流行りましたねこの言葉
「ミスしても怒られたり罰せられたりする心配のない状態」のことです。
「心理的安全性を確保しましょう」とかそこら中で言われてます。

いまだに言われてるってことは、まだ確保されていないんでしょう。ツチノコですかね?

そもそもなんでバッファ積むかと言うと、みんな不安だからです。
心理的安全性が低いと言えます。
「予定が守れないことによるペナルティを回避したい」ということですね。

原因が分かっているなら簡単なことですよ、心理的安全性を確保すれば良いのです。

そうです「見積もりなんか間違ってもええやん」ということです。

。。。あれ?ちょっとニュアンス違うな。。。

見積もりを間違えることはある(だって人間だもn)それを仕組みに取り入れて心理的安全性を確保すれば良いんじゃない?」です。

大切なのは「仕組み」です。
そんな仕組みを2つ紹介します。

CCPM

Critical Chain Project Management:クリティカル・チェーン・プロジェクト・マネジメント

クリティカルチェーン≒クリティカルパスみたいな感じです(若干違いますが大体一緒です)

ざっくり言うと以下のような感じです

  1. 各タスクはぎりぎり50%の確率で達成できる見積もりを立てる(アグレッシブな見積もり)
  2. タスクをクリティカルパスで並べプロジェクト期間を合計する
  3. プロジェクト期間の50%をプロジェクトバッファとして後ろにくっつける

※この達成確率50%とかは結構感覚です。
元の見積もりから2割ぐらい削るとか、5割削れば丁度良いとかいう無茶な理論もあります。

この手法の面白いところは「プロジェクトバッファ」という概念を作り
「各タスクは遅れても良い」としたことで心理的安全性を確保した点です。
遅れた(見積もりがブレた)場合、全体のバッファを削ることによりプロジェクトが進行していく、そんな手法です。

CCPMの肝は

  • クリティカルパスを早く完了させる計画を建てること
  • それにより問題の早期発見&対処をする時間を確保すること
  • それら全てを見える化すること

結局のところCCPMのバッファとは従来と同じ「時間」です。
ただバッファの積み方を工夫しているという一種のマジックですね。
マジックですが、意外と「締め切りがある」と「遅れても良い」という効果は大きいです。

まあでもウォーターフォールの一派です。なんていうか管理的な側面が強いですかね。。。
ウォーターフォールだとみんな守りに入るから、遅れても良いんだよというアメを与えて無理やりアグレッシブにさせてる、みたいな。。。

これは大規模プロジェクト向きで、短期プロジェクトには向きません。
もともとバッファそんなにないので、「大変」から「めちゃ大変」になるだけです。。。

アジャイル

アジャイルの見積もりは「時間という概念から独立」しています。
このタスクは「何日掛かる」ではなく「他のタスクと比べて相対的にどれぐらい」です。
それをストーリーポイントと呼びます。

例:タスク○○はタスク△△に比べて倍ぐらい大変そうだから13ポイントだね

結局「このタスクが何日で終わるかなんて人によるやん?」ということ。
誰がアサインされるかどうか分からない段階で時間を見積もる意味ないやん?、という現実的思考。

大切なことは、一定期間(スプリント)に、チームとしてどれだけのタスクをこなせるか(ベロシティ)。
1スプリント100ポイントのタスクをこなせる実績があるなら、次回もそのぐらいの計画を立てれば良いのです。

アジャイルの見積もりに対する考え方ははっきりしてます。
「どうせ見積もりなんて色んな要素でブレるんだから時間かけても仕方がない」です。

ただ、短時間でも効果的な見積もりができる様に属人性を排除する工夫があって

  • 時間ではなくストーリーポイントによる見積もり
  • プランニングポーカー等のチームによる見積もり

見積もりがブレたときに責められる人はいません。みんなで見積もったんだからみんな悪いよね理論。
というよりアジャイルの理念が「間違えないこと」ではなく「間違えても迅速にリカバリできる」を目指しています。
(アジャイル ← アジリティ ← 俊敏性。これが全ての基本です。)

アジャイルのバッファとは「タスク自体」です。
優先度の低いタスクをやらないことにより見積もりのブレを吸収します。

アジャイルが重視するのは「経験」。ここが「仮説」を積み上げるウォーターフォールとは異なる点です。
間違えたこと、それは知見を得たということです。
次回(スプリント)に活かせば良いのです。

わりとすぐ来ます。来週です。

終わりに

ソフトウェアの特性上、開発には常に未知の部分が存在します。
世の中に存在しないから開発するのです。同じならコピーすりゃ良いんですよ。
(OSS使うとか、パッケージ製品導入するとかの意味です)

つまりソフトウェア開発は不確実性との戦いです。
どうやっても見積もりはブレがちで、それを形式上ブレていない様に見せるためにバッファを積んでしまう。
それがプロジェクト全体で見ると非効率を生んでしまうというパラドクス。

どうせ戦わなきゃいけないなら仕組みに取り入れてしまいましょう。

アインシュタインの縮約記法

はじめに

 今回は、Pythonの数値計算モジュールNumPyが提供している関数einsumの使い方を解説する。einsumはアインシュタイン(Einstein)の縮約記法を実装した関数である。テンソル間の複雑な計算を1行で書くことができる。前回実装した変分推論においても用いたので、この機会に紹介したい。

アインシュタインの縮約記法とは

 いま、ベクトルxyの内積を考える。

(1)    \begin{equation*} x\cdot y=\sum_{i}x_i\;y_i \end{equation*}

ここで、上の式の和の記号\sumを省略し、同じ文字の添え字が2つ続く場合はそれらについて和を取ると約束する。

(2)    \begin{equation*} x_i\;y_i\equiv\sum_{i}x_i\;y_i \end{equation*}

左辺の簡略化した書き方をアインシュタインの縮約記法と呼ぶ。この記法を最初に考案したのはアインシュタインである。厳密な話をすると、アインシュタインが一般相対論を定式化する際に用いた数学(リーマン幾何学)では2種類の添え字を扱う。上付き添え字x^iと下付き添え字x_iである。前者を反変ベクトル、後者を共変ベクトルと呼び、これらは区別される。そして、同じ上付き添え字と下付き添え字が続く場合の和を簡略化する記法として、上の縮約記法が導入された。

(3)    \begin{equation*} x_i\;y^i\equiv\sum_{i}x_i\;y^i \end{equation*}

本解説では簡単のため、最初に説明した方(下付き添え字だけの場合)の記法もアインシュタインの縮約記法と呼ぶことにして、話を進める。

NumPy.einsumの使い方

 最初に、上で見た2つのベクトルの内積の場合を考える。コードは以下の通り。

10行目でeinsumに渡している第1引数の文字列"i,i"は、式(2)の添え字に一致している。すなわち、式(2)のx_{i}の添え字iy_{i}の添え字iとを対応させ和を取ることをeinsumに教えている。

 次に、2つの行列A,Bの積を考える。縮約記法で書くと以下のようになる。

(4)    \begin{equation*} (AB)_{ij}=A_{in}B_{nj} \end{equation*}

ここで、A_{ij}は行列A(i,j)成分を表す。コードは以下の通りである。

10行目でeinsumの第1引数に渡している文字列"in,nj->ij"は式(4)の添え字と一致している。すなわち、式(4)の右辺にあるA_{in}の添え字inB_{nj}の添え字njから、左辺の(AB)_{ij}の添え字ijを作る操作であることをeinsumに教えている。

 今度は、2つのベクトルx,yから行列を作る演算を考える。

(5)    \begin{equation*} A=x\;y^T \end{equation*}

xN次元、yM次元のとき、行列AのサイズはN\times Mとなる。成分で書くと

(6)    \begin{equation*} A_{ij}=x_i\;y_j \end{equation*}

となる。この式には和は出現しないが、以下のようにeinsumを用いて書くことができる。

5行目のeinsumに渡している引数"i,j->ij"は式(6)の添え字と対応している。すなわち、右辺にあるx_{i}の添え字iy_{j}の添え字jから、左辺のA_{ij}の添え字ijを作る操作であることをeinsumに教えている。本来の縮約記法は和記号を省略することを意味したが、NumPy.einsumの適用範囲は拡張されている。さらに、次の例を考えてみたい。

(7)    \begin{equation*} A=\sum_n x_n\;y_n^T \end{equation*}

ここで、x_n,y_nはベクトルである。成分表示すると

(8)    \begin{equation*} A_{ij}=x_{ni}\;y_{nj} \end{equation*}

となる。ここで、添え字nについて縮約記法を用いた。einsumを用いると次のよう書ける。

もう、説明は必要ないであろう。

 最後に、複雑な例を挙げて終わりにしたい。

(9)    \begin{equation*} A_{ij}=x_{iabc}\;y_{abc}\;z_{abcj} \end{equation*}

上の式は次式の縮約記法である。

(10)    \begin{equation*} A_{ij}=\sum_{abc}x_{iabc}\;y_{abc}\;z_{abcj} \end{equation*}

コードは以下の通り。

まとめ

 今回は、PyNum.einsumの使い方を説明した。通常であればループの入れ子を用いて書くことになる計算を1行で書くことができる。しかし、上のサンプルコードでも示したが、内積にはdot関数が、行列同士の積にはmatmulが用意されている。同じことをする関数がすでに存在するのであれば、既存関数を使った方が高速であるようだ。速度比較についてはこちらのサイトが詳しいので参照してほしい。

【新卒奮闘記】mainメソッド内のメソッド処理【~IT初心者からプロのSEへ~】

本記事のポイント

  • mainメソッドのクラス内で定義されたインスタンスメソッドは実行できない
  • クラスメソッドであればmainメソッドで直接アクセスできる
  • 別のクラスでインスタンスメソッドを定義し、mainメソッドでオブジェクトを生成すれば実行可能

はじめに

初めまして、2020年度新卒入社のsyoと申します。
私は、学生の頃は神経科学の研究室に所属しマウス(ネズミ)を使って遺伝子を調べたり、神経活動を計測する実験をしていました。学生の頃はプログラミングをほとんどやっていないので、プログラミングを本格的に勉強するのは弊社に入ってからでした。
なので、初心者の初心者による初心者のためのつまずいた点というものを自分の経験純度100%で紹介したいと思います。研修ではWebアプリケーションやシステムによく用いられるプログラミング言語のJavaを中心に学んでいます!

つまずいたところ

研修ではメソッドからクラスについて学ぶという流れで進んでいきました。クラスの項目に入った際に、インスタンスメソッドとクラスメソッドについて学びました。
mainメソッドが書かれているクラス内のメソッド定義には、staticというキーワードを付けて定義していることに気づきました。
メソッドには、
  • クラスメソッド:
    staticというキーワードを付けて(静的メンバで)オブジェクトを生成せずにメソッドを直接参照して実行できるメソッド
  • インスタンスメソッド:
    staticをつけず、オブジェクトを生成して実行するメソッド
の2つがあります。
mainメソッドはクラスメソッドとなっていますが、これがどういった意味を持つのかわかりませんでした。

いざ調査!

そこで先輩社員に質問したところ、「それならば一度mainメソッドでstaticを外して試してみよう」というアドバイスをいただきました。
早速実行したところ、次のような結果になりました。
インスタンスメソッドを定義してmainメソッドで実行

 実行してみた結果、次のようなエラーが起きました。

非staticメソッドをstatic参照することはできません、とはどういうことなのか、、、
調べてみたところ、次のような規則があることがわかりました。
javaにおいてあるクラスで定義したメソッドは、staticをつけてクラスメソッドとした場合のみ、同一クラス内の別メソッド内で実行することができます*1。この規則によって、mainメソッド内で、同一クラス内に定義したインスタンスメソッドを呼び出そうとしても呼び出すことができずエラーとなっていました。
エラーが起きないようにする方法は2つあります。
それは、
  1. 同じクラス内でクラスメソッドを定義して実行する
  2. 別のクラスでインスタンスメソッドを定義し、mainメソッド内でそのオブジェクトを生成して実行する

です。

  1. インスタンスメソッドは、宣言されているクラスがロードされるタイミングで展開されて参照可能となります。したがって、mainメソッドと同クラス内に定義されているクラスメソッドは最初にロードされるため実行可能となります。
  2. インスタンスメソッドはオブジェクトを生成しなければ使えるようになりません。したがって、オブジェクトを生成する工程が必要となります。ここでの注意点は、別のクラスで定義されたインスタンスメソッドはmainメソッド内でオブジェクト生成すれば実行可能となる点です*2

以上を踏まえて実行すると、

1.クラスメソッドの方法

実行結果

2. 別のクラスで定義したインスタンスメソッドの方法

実行結果

見事に実行ができました!

ちなみに、上記の通りmainメソッド内でメソッドを実行する方法は2通りあります。
保持したデータを元に処理をしたいときにはインスタンスメソッドを使い、データを持たないメソッド処理の時にはクラスメソッドを用いることで使い分けます。
以下に保持したデータを用いて処理をしたいときの例を挙げます。
処理は、3つの値の合計値を1つ, 2つ, 3つごとでのグループの足し算です。
  1. クラスメソッドの方法

実行結果

2. インスタンスメソッドの方法

実行結果

上記の通り、データを保持して計算できるインスタンスメソッドのほうがスッキリとしたコードになり柔軟な処理が可能となります!

結論

mainメソッドはクラスメソッドであるため、同一クラスで定義されたインスタンスメソッドを実行できないことがわかりました。そのため、mainメソッド内でメソッドを実行する方法は、
  1. 同一クラス内でクラスメソッドを定義して実行する
  2. 別のクラスでインスタンスメソッドを定義して実行する

となります。

今回つまずきを解消していくにあたり、コードについて疑問等が起きた場合はいったん自分で実行してみて、挙動を確認することが理解の第一歩であるということを強く実感しました。

今後も研修内でつまずいた点を記事に載せていきたいと思っています。ここまでお付き合いいただきありがとうございました!

参考文献

社員インタビュー第4弾:プログラミング未経験で入社した新卒エンジニアに色々聞いてみた

社員インタビュー第4弾:プログラミング未経験で入社した新卒エンジニアに色々聞いてみた

こんにちは!
採用担当の池田です。

今回はプログラミング未経験で弊社に入社した新卒エンジニアの脇さんにインタビューさせて頂きました。

弊社の説明会に参加した方からは、「未経験だとついていけないんじゃないか」という不安を抱える方が多い印象なので、その疑問を払拭すべく、脇さんに聞いてみましょう。


【脇謙太朗(わきけんたろう)2019年神戸大学工学部建築学科卒業。同年、コアコンセプト・テクノロジーに新卒として入社。】

池田
お疲れ様です!インタビューを引き受けて頂き、ありがとうございました。非常に断りづらい依頼だったと思うのですが、本当に大丈夫でしたか(笑)?
脇さん
全然大丈夫です!是非よろしくお願いします。

脇さんの大学生活について

池田
早速ですが、まずは脇さんの大学生活について教えて頂けないでしょうか?
脇さん
主に、部活動中心でした。体育会のサッカー部に所属していたのですが、未経験で入部したので体力的にもかなり辛く、授業もしっかり受けていたものの、どうしても部活動が中心でしたね。
池田
大学からサッカー部???高校まで何のスポーツやっていたんですか?
脇さん
小中は野球、高校は特にやっていないですね。
池田
そうなると大学から体育会のサッカー部に入部するのは相当大変ですよね???なぜ大学からサッカー部に入ろうと思ったんですか???
脇さん
最初は大変でした。元々サッカーに興味があって、高校入学時にサッカー部に入ろうと思っていたんですが、サッカー部の友人に「未経験なら辞めたほうが良い」というアドバイスを鵜呑みにして入らなかったんです。
ただ、その後徐々に「入っておけば良かった」という後悔の想いが増してきたので、大学で入った感じです。
池田
大学の部活って初心者で始める方はいるんですか?
脇さん
先輩は0で、同期だともう1人いた感じです。サッカー部全体で80人所属していますが初心者はほぼ皆無でした(笑)
池田
ですよね(笑)そうなると入部当初は実力差が周りと比べて相当あったと思うので、モチベーション下がらなかったですか???
脇さん
それはないですね。日々自分の成長を感じることが出来ましたし、先輩やチームメイトも頻繁に褒めてくれたりサポートしてくれたので楽しく出来ましたね。
池田
周りのサポートがあったからこそ、楽しく続けられたんですね。
脇さん
そうですね。ポジションはフォワードだったんですけど、最終的にはCチームでスタメンとして試合に出られました。神戸大学のサッカー部にはAチームとBチームとCチームがあるのですが、その中では下のチームですけど、試合に出られたので楽しかったです。
池田
練習は厳しかったんですか?
脇さん
週6日練習だったので、かなりきつかったですね。授業も普通にあったので、生活のほとんどが大学の行き来で終わる感じでした。
池田
(絶対私には出来ないな。。。)ちなみに建築学科を選んだ理由はありますか?
脇さん
モノづくりに興味があって、その中で建築が一番イメージしやすく入った感じです。
池田
なるほど。そうなると現在建築の道に進んでいないと思いますが、建築を学ぶ中で何かギャップを感じたことがあったんですか??
脇さん
いや、ギャップは感じていないですね。自分の中の想いとして、建築の道よりもプログラミングがやりたかったので、ITの道を選びました。
池田
そうなんですね。神戸大学の建築学科の進路実績ってどういう状況でしょうか?
脇さん
院進学が7割です。就職は3割ですが、その中の業界だとゼネコンや住宅メーカー、鉄道に行く方が多いですね。
池田
となるとITエンジニアの道を進まれている方はかなり少数派ですよね?
脇さん
私以外いないと思います。
池田
そのような状況の中で、なぜITエンジニアの道を選んだんですか?
脇さん
元々プログラミングをやってみたいなと思っていたんですよね。ゲームを作りたいという想いもあって。もちろん建築の道に進みながら家でプログラミングも出来ると思うんですけど、本業でがっつりやったほうがスキルも上がるだろうなと思い、ITの就職を選びました。
池田
大学時代にプログラミングはやっていたんですか?
脇さん
3年生の時に趣味の一環としてUnityの入門書を買って、一通り読んで作ってみた感じです。ただそこまで深くやっていないので、本当に初心者の領域でした。

新卒研修について

池田
未経験の状態で弊社に入り、入社後すぐに研修に臨んだわけですが、研修はついていけましたか?
脇さん
ついていけましたね。もちろん簡単では無かったんですけど、初心者にもしっかり合わせて講義を提供してくれていたのでそこまで大変な記憶はないです。
また同期の上級者のメンバーが丁寧に教えてくれたおかげもあり、周りのフォローにはかなり助けられました。
池田
脇さんの代は17名いると思いますが、お互い支え合いながら取り組んだ感じでしょうか?
脇さん
そうですね、同期の中には技術に非常に長けているメンバーもいて、僕自身は同期の中で下のレベルでした。初心者は3,4名くらいしかいなかったんですけど、上級者に教えてもらいながら一つずつ乗り越えた感じですね。

配属後について

池田
配属については第1希望の部署である製造ソリューション開発部(旧開発事業部)にアサインされたと思いますが、配属当初の仕事について教えて頂けますか。
脇さん
最初はWebサーバーのログの集計の業務を任されました。元々オフショアに依頼していたプログラムに不具合があったのでそれを直す仕事でした。Pythonの本とpandasというライブラリの本を渡されて一から勉強しました。期間は1か月と余裕があったので、既存のコードと見比べたり、動かしたりしながら、少しずつ進めていったと思います。
池田
なるほど。ただPythonって始めて触る感じですよね?研修はJavaメインだったと思うのでオブジェクト指向の基本的な部分は最低限学んだとは言え、いきなり違う言語を任されると不安じゃなかったでしたか?
脇さん
不安はそこまで無かったです。隣に上司や先輩がいた環境で、「何か分からなかったら質問して」という感じだったので特には困らなかったです。
基本的には書籍やネットの記事を見ながら進めていましたが、それでも分からないときは全て質問していました。
池田
上司や先輩には質問しやすかったですか?別のプロジェクトで忙しい上司や先輩達だとは思うので質問したくても出来ないとか無かったですか?
脇さん
かなり質問しやすく、1聞いたら5返ってくるみたいな(笑)。ただもちろん忙しそうにされていたときはあったので、そういうときは上手く避けて、まとめて質問するようにしていましたね。
ただその後の面談で「もっと積極的に質問して良いのに」と先輩に言われたぐらいなので、質問しにくいということは無かったです。
池田
つまり基本的には書籍中心に勉強するけど、分からないときはどんどん周りを使って学んでいくような環境だったんですね。
その案件が1か月で終わったと思いますが、その後はどんな仕事をやったんですか?
脇さん
かなり大きなプロジェクトにアサインされて、技術としてはサーバーサイドがScala、フロントエンドはJavaScriptでした。その中でまずは簡単な不具合の対応を中心にやっていました。また実業務とは別に、先輩エンジニアの方から課題を与えられて少しずつ技術に慣れていった感じです。こちらも時間的には余裕を設けて頂いたのでかなり助かりました。
池田
ScalaもJavaScriptも初めての技術だと思うのですが、どのように学んでいたんですか?
脇さん
書籍が渡されたのでまずは自学自習という感じです。ただ言語ももちろん学んでいたのですが、それ以上にアプリケーションの仕組みを重点的に学んでいた感じですね。不具合の原因を調べるなかでアプリケーションがどのように動いているのかを知っていったり、フロントエンドのデバッグをしてデータの流れを追って不具合を見つけたり、みたいな学びが大きかったです。
池田
なるほど、やりながら少しずつという感じですね。とはいえ、新しい技術を学ぶ時って不安になると思うのですが、具体的な勉強方法について教えて頂けますか?
脇さん
例えばScalaに関しては書籍を渡されていたのでそれを中心に学習していました。サンプルコードや既存のコードを参考にしてコーディングして慣れていく感じです。Scalaの文法については今も勉強中なんですけど、基本的な処理の流れや書き方は他の言語と特別違うことはないと思っているので、言語うんぬんよりもどういう仕組みで動いているのかという勘所を掴む方が重要だと思いますね。アプリケーション全体の理解というか。
その辺りは先輩社員にどんどん聞きまくって、説明の中でも分からない言葉が出れば後で調べて少しずつ理解していった感じです。

未経験の方が注意すること

池田
未経験で入社した立場として、注意しなければいけないことはありますか?
脇さん
自分で学んで自分で調べるクセがある方は大丈夫だと思います。例えば研修の頃に同期に教えてもらったんですけど、分からないことがあった際にどう調べたら上手くいくのかについて知ることが出来たんですよね。
そのため業務でも分からないことがあればまずは自分で調べるようにしています。その上で分からないことや時間が掛かり過ぎてしまう場合は先輩に相談しています。

一方で、先輩からは何でも質問して良いよとは言われるものの、その言葉をそのまま鵜呑みにしているようではダメで、自分で調べる中でどこが分からないのかをしっかり言語化し、まとまった上で質問しないと得られるものは少ないと思っています。

池田
なるほど。そういえば脇さんは体育会系出身では弊社では珍しい存在だと思います。一方CCTは体育会系の人は相当少ないと思うのですが、やりにくさとかギャップは無かったですか?
脇さん
それは感じていないですね。感じる場面はそもそもなかったような。。。
池田
ノリが悪いなぁとか思わなかったですか(笑)?
脇さん
ないですないです(笑)。現状プロジェクトで一緒のメンバーは部長の村澤さんを始め、温かい人が多いですね。
コミュニケーションを頻繁に取りながらも根本は優しい方ばかりの印象です。ピリピリしている人とか感情的な人は見たことないです。
池田
それは良かったです。
ちなみに新卒の就活生から「大学時代にしておくべきことはありますか」という類の質問をよく受けるのですが、何かアドバイスありますか
脇さん
何か一つ動くものを作ることですね。取っつきやすい視点で言えば、JavaScriptは目に見えて動くものが比較的簡単に作れるので、楽しいし成果としても感じられるのかなと思います。
池田
なるほど、ではそのまま伝えさせて頂きますね(笑)
また社会人と学生でギャップを感じたことはありますか?
脇さん
僕はあまり感じてないですね。よく聞くこととして時間の管理や責任の重さとかを挙げる方が多いと思いますが、私はその辺りについてあまり思わないです。
池田
(相変わらずしっかりしているなぁ)そうなると例えば大学時代の同期で就職した仲間と話す機会の際に、社会人の大変さとか愚痴とかで話題に挙がることはありますか?
脇さん
友人だと残業の多さとかでの不満は多少聞きますね。ただ同時にやりがいも感じている友人が多く、やりたいことが出来ていると話している方が多いかなぁという感じです。僕の場合はほとんど残業も無いので、あまり今のところは不満はないです。
池田
残業は月どのぐらいですか?
脇さん
月に3,4時間ですね。
池田
めっちゃ少ないですね。他の会社に就職した友人はどの程度やってるんですか?
脇さん
大体月3,40時間ぐらいですね。そのため僕は本当に恵まれていると思います。正直なところ、あまり今のところはCCTに対して不満や改善してほしいことは無く、池田さんが期待する回答が出来なくて申し訳ないんですけど。。。結構良い感じで働かせてもらっているので辞めたいなとか思ったことは無いです。
池田
(うーん、、、もうちょっと悪いこと聞きたいのになぁ(笑))そうなると説明会で聞いた印象と実際に入ったときの印象でギャップはありますか?
脇さん
僕自身は無いんですけど、同期の中では大変そうな方はいますね。時期の問題もありますけど、大変で辛そうだなぁと思うときはありました。
池田
彼らのことですね(笑)。それでは最後にCCTに入るか迷っている方にアドバイスをお願いします!
脇さん
僕個人の話ですけど、プログラミング技術を磨いて、何か物を作りたい気持ちがあって入社しました。同じ部署に配属された同期がもう1人いるんですけど、彼も同じ気持ちがあるので必死で勉強しています。そういう想いを持った人が僕の周りには多い会社なので、そういう気持ちがある方は合うんじゃないかなと思います。
池田
本日はお忙しい中、ありがとうございました!