共通結合（Common coupling）

グローバル結合とも呼ばれ、二つのモジュールが同じグローバルデータ（例えば、グローバル変数）を共有する。共通のリソースを変更すると、それを使用したすべてのモジュールを変更することを意味する。

外部結合（External coupling）

二つのモジュールは、外部から供給されたデータ·フォーマット、通信プロトコル、またはデバイスインターフェイスを共有している場合に起こる。これは基本的に外部ツールやデバイスへの通信に関連している。

　どうせ海外発の概念だし、WikiPediaをうのみにするのもどうよ、と思ったので英語で検索。

　英語版のWikiPediaではこうでした。

Coupling (computer programming) - Wikipedia

Common coupling

Common coupling (also known as Global coupling) occurs when two modules share the same global data (e.g., a global variable).

Changing the shared resource implies changing all the modules using it.

External coupling

External coupling occurs when two modules share an externally imposed data format, communication protocol, or device interface. This is basically related to the communication to external tools and devices.

　日本語版は英語版の訳だったが…と思いつつ、言っていることはWikiPediaとそれ以外で相違しています。

　もう少し英語のネタを漁っていきます。

http://faculty.cs.uwlax.edu/~riley/CS741Sum10/lectures/8_CouplingCohesion.pdf

CPSC 333: Levels of Coupling

Common Coupling

Two or more modules exhibit common coupling if they refer to the same global data area - that is, to something that corresponds to a data store on a DFD or a “register” that must be shared by several processes.

External Coupling

Two or more modules exhibit external coupling if they share direct access to the same I/O device or are “tied to the same part of the environment external to software” in some other way.

　うーん。言っていることはWikiPediaとそう違ってはいません。

　日本語版WikiPediaを英語版の忠実な僕とすると、日本語圏の認識と英語圏の認識が相違しているわけです。興味深い。

どちらが正しいんだろう？

　私の感覚では英語の内容だと思うんですよね。

　外部結合は、例えば共通のI/Oインタフェースを参照する等、グローバル変数とは異なる同一のリソースを参照しているケースですが、この場合、

参照している内容、手順は第三者から明確に認識可能
明文化された手順、規約に従えば他のモジュールからもアクセスできる

　と、ある一定の明確な規約のもとでリソースを参照しています。

　いわば明示的な約束に基づいて(外から分かる形で)リソースを共有しているわけです。

　一方で共通結合は、グローバル変数を参照していることだけが分かっているだけであって、その変数がいつ、どのようにアクセスされるかは、参照関係にあるモジュール間だけの暗黙的な約束になっています。

　暗黙な約束を持つ、ということは、モジュールは相互にどのようなアクセスをしているのかを知っていなければならない、ということであり、その約束は外部から認識できない、ということ。

　要は、『共通の秘密を持っている方が結合度が高い』ということ。

　察するに、日本語の誤認識は『データ結合』(構造のない引数)と『スタンプ結合』(構造を持つ引数)の差を、英語のリソースを確認せず、外部結合と共通結合に敷衍したことから発生したんじゃないかなぁと、あまり深く考えずに思ったりしましたが、真相はよく分かりませんし、割とどうでも良いですね。

まとめ

誰かの話を聞いて、自然でない認識に至る場合は裏を取ったほうが良いですね。
古くて定説化されていても、怪しければ英語に当たったほうが良いですね。
なぜそう位置づけられているのか、という理由は大事ですね。

　という話でした。

2016-02-29

Developer's Summit 2016 【18-D-5】アジャイル開発でハードウェアをつくる～イノベーションはラーメン食えればいい！～聴講メモ

Developers Summit セミナー聴講メモ

講演資料

http://www.slideshare.net/YoshimasaKawano/20160218-devsumi

概要

　アジャイル的な視点でハードウェア開発を見た時、新しいハードウェアを安く早く作ることは可能である一方で、ソフトウェアとは異なる事項について注意しなければならない。これらの事柄を、実例を通して説明する。

スピーカー

秘密結社オープンフォース総統¹の河野さん。

『Raspberry Pi電子工作レシピ』の著者。
Iotの薄い本を今回のデブサミで売っている。

詳細

IoT時代。ハードウェアが次の波になってきていることは認識している。
Web開発の手法を使ってハードウェア開発ができないか？

ハードウェア開発の混沌

KickStarterとかを見ていると、『ガジェットの混沌』とでも言うべき状態であることが分かる。
例えば『充電ガジェット』。
- 割と誰でも思いつく。
- 焚き火で充電するとか。
- 体温で充電するとか。
例えば『インターネット鍵』。
- BlueToothで鍵を開けられる。
- 電池寿命は1年、とかね。
ところがこれらはエネルギー収支を満たしておらず、使いものにならない。
- 6時間焚き火に当たらないと充電できない。充電のために6時間も焚き火に当たるのか？
- 体温で充電できる量は電池電力の1/500。それっぽっち。
- BlueToothなら1年持つかもしれないが、Wifiだと3日しか持たない。
- この手のハードウェア開発、キックスターターで金は集まるが、結局うまく行かない。

何が悪いのか？

『デモムービーは実現できない』ということ。
- 物理法則とちょっとした計算で、エネルギーの収支計算はできるのだが、それをしていない。
お金を使わないと分からないこともあるかもしれない。
- 『浸透戦術』²を取る場合、開発のリミッターが人とか、未知のフィールドだから、という場合は有効に機能する。
- が、物理法則がリミッターの場合、『浸透戦術』では解決できない。
作ってみないとわからないこともあるが、『お金を集める前に作る』事が大事。
例えば自分はガイガーカウンターを作ったことがある。
- 2011年当時。海外製のガイガー管が手に入らない。
- 日本製のガイガー管もない(ディスコンしてしまったらしい)。
- そこで、ロシアから軍用品のお下がりを輸入した。
- 写ルンですを分解して組み合わせ、自作のガイガーカウンターを作ってみる。
- すると、ガイガーカウンターに関する特性がいろいろわかってきた。
  - この辺りの特性は、作って、使ってみないとわからない知見。

資金調達

ハードウェア作成、一体何にお金がかかるのか？
- よくあるパターン
  - 『コンサルや外注に聞いて作っている』
  - 『作ったけど思い通りにならない』
- 『(予算がかかるので)もう一度はできない』ではなく、何度もピボットする必要がある。
このあたりを考えて資金調達元を考えると…。
- 銀行はこの手のやり方に対して相性が悪い。
- VC(Venture Capital)は動くものがないと金を出さない。
- クラウドファンディングは、前述のとおりファンディング前にモノを作ることが肝心。
- 結局は個人で出資が一番いいのでは。

実例

リコーダーミューター³を作りたい人から相談を受けた。
- 自治体にアドバイスを受けたら、創業補助金の話をされた。
  - (ケース用)金型には数百万かかる。
  - 3D設計するなら3DCADが必要だと言われ、100万以上かかった。
- 投資を受けるために販路のエビデンスを取る必要がある。
  - そのためにステークホルダにヒアリングが必要。
- 大変、という相談。
そこで、
- LibreOfficeで図面を書きつつ、みんな大好き秋月電子から資材を調達してさくっと作った。
- カンファレンスで小学生向けのワークショップを開き、公開してフィードバックをもらった。
- それをそのままAmazonで売った。
  - Amazonでフルフィルメントしてもらうと、在庫を自分で持つ必要が無い。
  - Amazonで売ったことをエビデンスとして、育英資金から融資を受けた。

イノベーションを起こすためには

フロンティア、高齢化等、実は現在はブルーオーシャンの時代。
- 人手不足と言われるが、逆に人間がいないことでロボットの需要がある。
- とは言え大企業とは違って、いかに下から市場を取っていくかを考える必要がある。
  - これは、いかに市場にマッチさせていくか、ということ。
  - ピボットを繰り返してマッチさせていく。
電子、電気でやっていることは箱庭に過ぎない。
- が、ソフトウェアの世界では、そもそも新しい技術がイノベーションを起こしたのではない。
  - 新知見ではないIT化、クラウド化のスケーリングで流通革命が起きているように。
  - LAMPとかAWSとか、OSSの力。
  - チープであることは弱みではなく、スピードに転換される。
  - 安価でIoTが試せる、というのはそれだけでパワー。

OSSのエコシステム

アメリカはシリコンバレーで。
日本はIT勉強会で醸成されている。
昨今はハードウェア世界でもオープンソースのエコシステムができつつある。
- 勉強会やカンファレンスが増えている。
- 2/11にも、オープンハードカンファレンスが実施された。

ラーメンスタートアップ

ソフトウェアのスタートアップ形態の一つ。

AWSのt2.microで数ヶ月稼働させる。
LAMPを使う。
ソーシャルでPRしながらピボット。
ヒットしたら一気にスケールするモデル。
ヒットするまでの間は、ラーメンを食い続けられるレベルの費用があれば良い。

ラーメンスタートアップはハードウェアでは可能か？

ハードウェアは開発に数百万かかるが、ここしばらくで大きく進化している。
- 例えば、海外では10ドルで基盤ができる。
  - CADもオープンソース(Ki-CAD)でできる。
  - 基盤実装費用も安くなっている。
- (ケース用)金型を作るとそれに縛られてしまう。
  - お金をかけず、ギリギリまで量産しないこと。
- キーワード。
  - KiCAD(OSSのCADツール)
  - DigiKey(電子部品ストア)
  - SeeedStudio(基盤を作ってくれる会社)
  - レーザーカッター(ケースを作るためのもの)
  - 焼肉用ホットプレート(表面実装に使う)。
  - 半田ゴテ。
  - Arduinoやラズパイ。
  - Aliexpress。
  - Amazon。
ワークショップ、書籍、キットを組み合わせた商流。
- 例えば、自分はラズパイのアドオンボードを作った。
  - KiCADで設計。
  - 組み立てせずにキット販売した。

世界と戦うためには

中国が最大の敵。

知財の問題

特許を日本で取得することは簡単だが、海外展開する場合、なかなか取りきれない。
最近はアカデミックと連携しづらい。
- ITとか電子、電気は知財縛りがある印象。

本当に必要なのはコピーに勝つこと

中華より安いか、本物を担保する。
- 署名と暗号化。
  - 中国の地溝油を検出するデバイスの例。
    - より正確には酸化した油を可視化するデバイス。
    - 内部に暗号化チップを組み込み、本物と偽物を識別している。
- 本物の価値はユーザからの評価にある。
  - が、どんでん返しがすぐ起こってしまう。
  - 先行者利益が少ない。
  - 絶えず努力するしかない。

価格的には中国サイトで調達するという手もあるが

安い一方でトラブルも多い。
トラブル、偽物は当たり前。
トラブルマネジメントは必須と言える。
逆に、トラブルマネジメントのノウハウは、蓄積すると差別化要因になり得る。

中国国内でも偽物には辟易

質の悪い偽物に対しては差別化が可能。
もっともタチが悪いのは、『質の良い偽物』だが、大抵UIが弱い。
- 忍耐しながら使わないといけない。
- なのでUIを攻めると良い。

悪にならないためには

動く物ファースト。
- 見栄えよりも実証物を。
動いたデータは何よりも雄弁。
- Deliveという電気石窯を作ってみた。
  - ラズパイで制御している。
  - 温度制御の理論はある。
  - が、実際に作ってみるとデンプンのアルファ化による熱移動とか、新しいことが分かる。
  - 実際に焼いたデータにはかなわない。

ハードウェアのことを知るには？

とにかくやってみる。
- イニシャルコストは低い。
ものがないのに費用をつぎ込むな。
- 見栄えにこだわらない事が大事。

まとめ

(ソフトと比して)ハードウェアの世界は遅れている。
が、イノベーティブな手法を応用することはできる。
早く安く作ることはできる、ということ。

告知

9月にオープンハードカンファレンスを東京でやるらしい。

普通にそう紹介していましたね…。白衣の怪しげなマッドサイエンティスト。↩
第一次世界大戦でドイツ軍が取った戦術。敵の間隙を見つけてどんどん進む戦術。この文脈では『分からないけどまずやってみよう』的な進め方を指している。↩
リコーダーの音を小さくするためにリコーダーに取り付ける小型デバイス。子供がリコーダーの練習をすると、うるさいと言われる住宅事情のためのもの。↩

2016-02-26

Developer's Summit 2016 【18-E-2】Android6.0 対応！モバイルアプリセキュリティの最新トレンド聴講メモ

Developers Summit セミナー聴講メモ

講演資料

http://www.slideshare.net/devsumi/18e2android60

概要

　Androidアプリの脆弱性の現状を示した後、最近改版されたJSSECのセキュアコーディングガイドに基づき、6.0で特に留意すべきセキュリティ対策について説明する。

スピーカー

ソニー(SDNA)の奥山さん。

詳細

所属している会社

ソニーデジタルネットワークアプリケーションズ株式会社(SDNA)。
- VAIOのソフト部門が独立したソフト専門子会社。
- ソフト開発専門。
- ソニー製品の開発、検証。
- 比較的早い段階からセキュリティに携わっている。

Mode World

ファイル保存時の生成モード。
- MODE_WORLD_READABLE/MODE_WORLD_WRITABLEを使っているアプリが22%ある¹。

ダウンロード数と脆弱性の関係

ダウンロード数5000万ぐらいが脆弱性発見数のピーク。
そこからダウンロード数が増えると脆弱性が減少傾向になる。
- ダウンロード数が多くなるとお金が取れるようになるので、対策をしっかりしてきているのかもしれない。
- ちなみに2013年にはなかった傾向。

セキュアな開発をするには

JSSEC(Japan Smartphone Security Association)のセキュアコーディングガイドを参照。
- JSSECはスマートフォンのセキュリティを推進する組織。
- 総務省も紹介するような基準。
- セキュリティを意識している会社は結構使っている。
  - 三大キャリアとか、キャリアに関連する会社とか。
- デファクトスタンダードと言って良い。
- 2012年に初版を発行。
- 以降、半年～1年程度で改定している。
- 第6版が2/3に公開された。

セキュアコーディングガイド第6版で追加された内容

3つの内容について解説する。

1. 6.0のパーミッションモデル変更に対応

6.0では、インストール時にパーミッションを与えるのではなく、実行時に許可するようになった。
- 実行する必要が発生した場合にユーザ許諾を求める。
- iPhoneに合わせているらしい。
- パーミッションはある程度グループ化されており、グループ単位で権限を管理する。
- ユーザによる許可の取り消しもあり得る。
  - つまり、許可を得ていない段階でも動かなければならないケースが出てきた。
- アプリ開発者が明示的にAPIを呼ばなければならない。
  - iphoneは自動的にOSが許可を求める仕組みなので、開発者は意識しなくて良いが、
  - Androidでは明示的にAPIを呼ぶ必要があり、後方互換性に影響を与える。
  - コールバック関数で結果を受け取り、許可の可否によって動きを変える必要がある。

2. 指紋認証アプリ

Nexus5x/Nexus6Pでは、指紋認証機能がサポートされた。
- デフォルトではロック解除に使用しているが、個々のアプリで様々な用途で使える。
  - 端末ユーザ認証による実行制御に用いる。
  - 楽天銀行とかでも使っている。
- 指紋認証のセキュリティ強度はパスワードより弱い場所もある。
  - 秘匿困難性、非交換性、認証精度などを理解して使用する必要がある。
  - 指紋認証の弱点を理解して使う必要がある。
  - 指紋認証だけに頼らないこと。
    - 楽天銀行では指紋認証はオプション、ログインだけしかできない。
    - その他の処理はパスワードを使っている。
  - また、機密性の高い情報は扱わないほうがいい。
- Android FingerPrint Architectgure
  - アーキテクチャを見ると、最終的にFingerPrintは暗号鍵として扱われている。
  - 暗号処理と密接に関連しているので、暗号の使い方を理解して使うこと。

3. Lまでの新規事項に対応

Notification Visivirity
- ロック画面中の通知表示のこと。
- 表示可否を3段階で制御している。
  - Secret(ロック画面には何も表示しない)
  - Private(アイコンなどの基本的な情報を表示。デフォルト)
  - Public(すべての内容を表示)
- Privateだけ、ロック画面に表示する情報と、非表示の情報の両方を有している。
  - 実装を誤ると、ロック中にプライベート情報を表示してしまう可能性がある。
  - デフォルトなので特に注意が必要。
- 実装時には、Visivilityと通知内容の確認をすべし。
  - ロック中の表示情報とロック解除後の情報の内容を正しく切り分けること。

他のアプリからも読み書きができるファイルを作成するためのモード。既に非推奨とされている。↩

2016-02-24

Developer's Summit 2016 【19-B-7】ブロックチェーン技術の基本と応用の可能性聴講メモ

Developers Summit セミナー聴講メモ

講演資料

http://www.slideshare.net/ks91020/ss-58535780

概要

　ブロックチェーンの技術的特徴を分解しつつ、ブロックチェーンの限界と未来の可能性について語る。

スピーカー

Orbの斎藤さん。
- 慶応SFC研究所上席所員でもある。
- チーフサイエンティストだったが、色々相談を受けるのでチーフコンサルタントに改めた。
- 分散システム研究の花盛りだったコーネル大学で修士号を取得。
- 博士課程からデジタル通貨の研究をしてきた。
- 近著『未来を変える通貨』
  - この本でブロックチェーンは実装できるそうな。

詳細

ブロックチェーンとは

分散タイムスタンプ技術。
- デジタル通貨のためのものだが、応用可能性が出てきている。
- 技術的特性については語られていない。
- ブロックチェーンは新聞の代わり、と言われる。
  - これはサトシ・ナカモト¹の論文の中に出てくる。
  - 群衆が発行している新聞であり、証明のツールとして使われる。
  - ただし、証明ができる、というのは差し引いて考えないといけない。
- 塊(ブロック)の連鎖(チェーン)。
  - ブロックは取引記録の集まり。
    - トランザクションと呼ばれることもあるが、コンピュータ的なトランザクションとは違う。
    - 取引は状態の変化の記述。送金だけとは限らない。
- タイムスタンプサーバを分散的に実現するもの。
  - ただ、サトシ・ナカモトはこの仕組みをブロックチェーンとは呼んでなかったりする。
- ブロックチェーンの実現にはハッシュ関数と公開鍵暗号が不可欠。
  - ちなみにビットコインはハッシュ関数にSHA-256とRIPEMD-160を使っている。
  - 公開鍵暗号はECDSAを使っているが、署名だけの使用。

ブロックチェーンの課題

ブロックチェーンの技術は3層に分けて考えられるが、評価すると課題を解決しきっていない所もある。
1. コンセンサスのプロトコル
  - 実は現実と同期して動くのが苦手だったりする。
  - ほんとうの意味でコンセンサスは達成できていない。
2. ダイジェストを格納するブロックの連鎖の構造
  - 連鎖を連続して直していかないといけないから強固。
  - と言われていたが、想定されていたほど強固ではない。
3. デジタル署名によるデータ構造
  - ここは有用に機能する。
この3層を意識しておくと、他の層の設計を変えて実装することができたりする。
ブロックチェーンに課題があるが、実現しようとしていることには意味がある。
- なのでいろいろな方式を試していって、課題を発見、改善していったほうがいい。

コンセンサスのプロトコル

データブロックが連結していて、あるデータブロックの中に以下のものが入る。
- 取引の記録。
- 1つ前のブロックのハッシュ値(以降ダイジェストと呼ぶ)。
ブロックを連結する際のノード(マイナー)の動き。
1. 各マイナーは、取引データをブロックに格納し、マイニング(くじ引き)する。
2. マイニングに成功したら、そのブロックをネットワーク上にブロードキャストする。
3. 各マイナーは、そのブロックを新しい末尾と認めたら後ろにブロックをつなげ、再び1に戻る。
ネットワークのメカニズム上、以下の現象が発生する。
- 複数のマイナーが同時にマイニングに成功することがある。
- ネットワークの通信遅延によって、後続につなぐブロックがマイナー毎に異なる場合があり、この場合チェーンが分岐する
- ブロックの連鎖自体は時系列
- とはいえ、ブロックチェーンは取引履歴を一意に保証しなければならないので分岐していては困る
  - なので、チェーンをマージする必要がある。
  - より長いチェーンを優先し、切られる方の取引記録をチェーンに取り込む。
ビットコインでは、ブロック追加数が一定以上にならないと取引は有効にならない。
- 生成取引は100ブロック、通常取引は6以上。

ダイジェストを格納するブロックの連鎖の構造

Proof of workと呼ばれる。
- 計算コストの証明。
- 作業困難だが検証は楽というメカニズム。
- Hashcashというメカニズム。
  - メールスパムの抑止とかに使う。
  - 例えば、『ダイジェストがある値になるようにメールヘッダを構成せよ』という計算。
    - 送信側は一定の時間を掛けてハッシュ値を当てないといけない。
    - が、受信者側は一瞬で計算できる。
- ビットコインでは、『あるターゲット値以下になるようなダイジェストとなるデータを見つけよ』という計算。
- ターゲット値は前のブロックから引き継ぐ。
  - 2016ブロックごとにターゲットを自動調整する。
    - 約2週間おき。
    - 2016ブロックの計算を2週間で行えるように調整される。

取引の消去に対する保護

ブロックチェーンにおける取引の改ざんはデジタル署名で保護している。
- なので、攻撃者は取引を消すことしか出来ない。
  - 取引を消すとブロックのダイジェストが変わる。
  - 次のブロックはそのダイジェストを持っている。
  - よって次のブロックのダイジェストの再計算が必要。
  - 以降、現在進行中の最新のマイニングまで連鎖して計算しないと、取引消去が正当性を持たない。
  - 計算量が多く、取引を消すのは非現実的
  - という形で取引消去から保護している。
現在までのビットコインのハッシュレート(ハッシュ計算回数の推移)
- 2015年ぐらいは秒間30京回ぐらいで安定していた。
- ところが、今は秒間140京回。
  - 一見大変になっているようだが、1年前と比較して劇的に計算機性能が上がったわけではない。
  - つまり、2015年段階でその計算量を投入していたら、改ざんできた可能性がある、ということ。
エネルギー消費量による改ざん障壁
- 発電所数個分。大きいように見えるが…。
- 全世界の貨幣システムが書き換えられるとしたら、その投資は果たして高い投資だろうか？
- ASIC化やマイニングプール化のように、実は経済力を集中すると覆せる。
実は、ブロックチェーンの全データを持たなくてもマイニングは可能。
- みんなが持たずにやり始めるとブロックチェーンを誰も保持しない。
- 検証ができなくなってしまう。

デジタル署名

UTXO(unused transaction output)構造。
- 取引内に署名、公開鍵を含めている。
- 公開鍵ダイジェストを別に計算し、公開鍵の正当性を確保。

ブロックチェーンの応用可能性

通貨
- ビットコイン、ライトコイン
存在証明(Proof of Existence)
- タイムスタンプサービスのブロックチェーン版。
ネームサービス
- DNSみたいなもの。
組織運営や経営の自動化
- DAO/DAC
自律分散アプリケーションの可能性

金融機関

2015年から急速に金融機関が取り組む
- 安価な送金とかをされると、自分たちの存在が脅かされる。
- なのでそれを研究して対抗しようという流れ。
- NASDAQでは未公開市場で使っている。
- 中央銀行ですら注目している。
閉じた専用ブロックチェーンを作ろうとする動きもある。
- 銀行内だけとか。
- ただ、小さなチェーンは攻撃への耐性が弱い。
- また、小さければハイパーレッジャーのような従来のプロトコルが使える。

自律分散組織

経営の自動化ができるのではないか。
- ビットコインの活動は、
  - ユーザを株主、
  - コインを株式
  - マイナーたちを従業員と考えると、
  - 株式移転を業とする経営を実現するプログラムコードになっている。

イーサリアム

スマートコントラクトのための分散アプリケーション基盤。
- スマートコントラクト
  - デジタルに表現される資産を予め定められたルールで自動的に移転する仕組み
    - 例えば自動的な遺産相続とか。
現代の金融、貨幣、法務を時代遅れにするかもしれない。

ブロックチェーンと現実世界

ブロックチェーンはCAP定理²上、止まらないといけない(可用性を犠牲にしなければならない)はずなのだが、止まれない構造になっている。
ビットコインで支払うと、ドローンがジュースを落としてくれるサービスを考える。
- いつ落とすのか？
  - 原理上は落とせない。
  - (上述のチェーンのマージによって)取引が消える可能性があるから。
  - 現実的には誰かが(取引が消える)リスクを取らないとできないサービス。
ブロックチェーンとIoTは相性が悪い。
- アクチュエータを動かすタイミングを決められない。
  - ブロックを確定させられないから。
ブロックチェーンはビザンチン将軍問題を解いたと言われるが、実際には解けていない。
- ネットワークを分断すると攻撃が可能(エクリプス攻撃)。
スケーラビリティの問題。
- 取引増加に伴ってデータ構造のコストが増加する。
世界がひとつでなければ動かない
- ブロックサイズを変える、という決定でさえも、全ブロックチェーンが一致しないと適用できない。
  - 技術進化のガバナンスが効きにくい、ということ。

これからの可能性

前提となる共通理解
- ビットコインにより有益性は示された。
- 分散型合意システムのアプローチはいくつかある
  - あくまでブロックチェーンを使うべきか。
  - 他のアプローチもある。

まとめ

ブロックチェーンには一定の応用可能性がある。
- 不確実性を許容できるシステム向き
決定的な動作を要するシステムには向かない
貨幣経済や方を置き換えていく可能性があり、面白い探求、追求になるであろう。

ビットコインに関する論文をネットに投稿した匿名の開発者。↩
分散システムに於いて成立する定理。一貫性、可用性、分断耐性の3つを同時に保証することは出来ない(いずれか1つを諦める必要がある)。↩

2016-02-22

Developer's Summit 2016 【19-D-L】エンジニアを成長させるための組織作り聴講メモ

Developers Summit セミナー聴講メモ

講演資料

http://sssslide.com/speakerdeck.com/plasticscafe/enziniawocheng-chang-saserutamefalsezu-zhi-dukuri

概要

　リクルートコミュニケーションズにおいて行われている、エンジニアの成長を促進するための組織的な取り組みについて紹介する。

スピーカー

リクルートコミュニケーションズ(RCO)の阿部さん。
独立系SIで何でも屋をやった後、RCOに入ってアドテクを立ち上げた。
今年から、組織のスループット拡大を意識して、マネージャをやっている。

詳細

前回のデブサミ(Ask The Speaker)で、エンジニアの成長環境について質問をもらった。
- これを受けて、今回は組織的な取り組みを紹介したい。

リクルートコミュニケーションズ

リクルートグループは、事業分野ごとに事業会社を持っている。
- 一方で事業横断な事柄について、機能外車を持っている。
- リクルートコミュニケーションズは、事業横断でデジタルマーケティングを支援。
自分が属するアドテク部は、クライアントとユーザのマッチングにアドテクノロジーでアプローチする。
50名中、半分ぐらいがエンジニア。
エンジニアがプロダクトの開発、推進にコミットするスタイル。
- エンジニアとプランナー両方でアイデア出し。
- エンジニアの技術観点とプランナーのビジネス観点の両方で考える。
- 見立てがついたら予算をつける。
- 高速開発。
- KPIを設定して仮設検証を繰り返し改善。
- という流れ。

組織のスループットを上げる

組織をシステムとして捉える
- インプットされた経営資源に対して、何らかの組織価値をアウトプットするシステム。
- 変換部分の処理能力を上げてやれば価値を増大できる。
  - 個々のメンバーの成長でスループットを増大できる。
エンジニアの組織である以上、組織の価値を高めるコア要因はエンジニアの成長。
人的リソース管理の考え方
- 従来モデルは『似たスキルを持っているメンバーをスケールさせる』
  - 人を増やすことで組織を成長させる。
- 目指すモデルは『メンバー自身の成長で価値面積を拡大していく』
  - 各人の価値を増大させることで組織を成長させる。

エンジニアが発揮する価値

3つあると考えている。
現在開発しているプロダクトの価値を上げる
- 新規開発、機能追加によって得られる価値。
  - 営業、企画、運用というロールがあり、それぞれ貢献率がある。
  - アドテクはアルゴリズムに依存するので、エンジニアの貢献率が高い。
新規サービスにおいて、最終的に価値になるもの
- 直接の売上にならなくても、最終的に価値になればOK。
損失リスクの軽減的な意味での価値向上
- 可用性、セキュリティ等。
- 技術的負債を減らす、というのも入る。
まとめると、
- エンジニアの価値は、組織に対して何らかのプラスの変化を起こす力。
- これをいかに大きくできるか。

RCOにおける取り組み

マネージャとしての頑張りポイントは4つ。

『採用』

組織とマッチするか?
一緒に成長していけるか?
現場の人間も採用プロセスには強くコミット
RCOで活躍しているエンジニア
- プログラミングで高度な課題を解決していく。
- 3度の飯よりプログラム好き(楽しんでやれる人)
現場のエンジニアがコーディング試験を作成し採点
- 組織が求めるスキルや性格を評価している。

『目標設定』と『評価』

目標設定と評価は表裏一体
設定した目標を達成できたかを評価している。
目標は本人のWillとエンジニア価値から目標を設定
- Will: どういう価値のあるエンジニアになりたいか。
- エンジニア価値:課題解決によって実現できる価値は何か。
業務を通してどれだけ成長できたかで評価する。
- 査定ではなく、成長させるためのコミュニケーション
- 目標の高度化と達成が継続循環すれば成長につながる。
Willに近い目標を設定できれば成長を加速できる。
- なりたい姿に向けた活動は楽しい。
- 楽しく取り組めば結果が出やすい。
- 結果が出ればなりたい姿に近づける。
やりたいことと業務課題のマッチング
- 完全一致しない。
- が、業務課題にもWiilも幅がある。
- 選択肢を組み合わせて両方を設定。
本人のWillにより近いところを探してあげる。
RCOの文化として、以下を腹決めしている。
- 『メンバーは成長すべきである』
- 『マネジメントは成長を促進すべきである』
このマネジメントは結構しんどい。
- Will、業務課題ともにしっかり見ないといけない。
- 場合によっては案件自体を作りに行くことも。

『機会の提供』

成長が業務の幅に束縛されてしまうので、機会を広げていく。
- 勉強会
- 機械学習大会
  - AI同士でボンバーマンを対戦させてみたりした。
- 開発合宿
  - ドローンを機械学習で動かしてみたりした。
  - エンジニアがワクワクするチャレンジの場を提供する。
- カンファレンス参加支援
  - 技術トレンドに遅れないように。
最終的には組織に価値が戻ってくる。
- エンジニアのスキルベースアップ。
- 最新技術や理論の還元。
- エンジニアならではのチャレンジ。
  - 早稲田との共同研究事例(量子アーニング)
  - 外の勉強会でコネクションを作ったのがきっかけ

まとめ

エンジニアを成長させるための組織に必要なもの
- エンジニアがチャレンジできる業務
- ビジネス課題と価値発揮領域のマッチング
マネジメントの頑張りどころ
- 採用
- Willと業務課題のマッチング
- 成長を意識した評価
- 業務の枠にとらわれない成長の機会

2016-02-22

Developer's Summit 2016 【19-C-1】強いチームの作り方聴講メモ

Developers Summit セミナー聴講メモ

講演資料

http://www.ryuzee.com/contents/blog/7078

概要

　チームの課題解決(カイゼン)、スキルアップ、文化形成など、強いチームを作るための適切なアプローチについて、Amazonの例などを提示しつつ語る。

スピーカー

吉羽さん
- 野村総研、AWSを経て現在フリー。
- 新刊３冊出るので手に取ってね。

詳細

ピープルウェアの言葉

過去の経験上、失敗するときは技術ではなく人間、社会学系で失敗している。
そこを学ぶべきでは、という問題意識。

チームの課題とカイゼン

挙手でアンケート。
- 『現状のチームに課題があると思う人?』
  - 会場の8割が挙手。
  - 課題はないと答えた人、そんなはずはない。
- 『実際に改善に取り組んでいる人?』
  - 意外に少なかった。
  - 問題があるのに改善しない、というのは質が悪い。
  - できるところから改善してほしい。
大きな改善をドカンとやると失敗する。
- 目の前、手の届くところから改善していく。

カイゼンの進め方

バリューストリームを見る(全体を見る)事が重要。
- 全体を見ないと部分最適化が進むから。
- 『自分だけ改善しても、プロダクトをリリースする速度は変わりませんね』ってことになる。
人間系の知恵を使う。
- エンジニアはツール大好きなのでツールばかりに目が行くが、ツールに頼り過ぎないこと。
目標を数字で図れるようにする。
- 見えないものは改善できない。
自分だけがやったら心が折れる。
- チームでやる。
- 上からの押し付けはうまく行かない。
製品開発の考え方にリーンスタートアップがある。
- リーンスタートアップは製品だけじゃなく、組織運営にも必要。

なぜチームが必要か

一人で出来るなら一人でやったほうがコミュニケーションコストも不要。
- が、世の中の仕事は一人でできない仕事のほうが圧倒的に多い。
- だからチームを組む。
メンバーひとりひとりには得手不得手がある。
- 一人でフルスタックである必要はない。
- チームでフルスタックであれば良い。
強いチームの特徴は、以下3点を『続けられる』こと。
- ビジネス上の結果を出す。
- 変化に対応する。
- 成長を維持する。
スポット的に出来るだけではなく、継続して成果を出せることが大事。

強いチームの形成

工場労働のように、仕事が単純な場合、概ね以下の様な傾向になる。
- 単純な繰り返し作業ならばらつきを減らす方向に。
- 自分だけ別なやり方をすることは許容されない
- 安定性を追求する。機械化されやすい。
が、ソフトウェアに関する仕事は複雑な仕事。
- なぜならビジネスに紐づいているから。
- 多様性が必要。
  - 性別、年齢、国籍など、表面的な多様性もあるが、
  - 考え方などのバックグラウンドも多様性。
  - 複雑な問題には多角的な視点で対象に迫る必要がある。
  - フィードバックによる軌道修正も必要。
- 多様性がない場合
  - 従来のやり方に対してフィードバックしにくい。
  - 文句が外向きになる。愚痴ばかり言うようになる。
  - 思考を停止してあきらめる。

チームの形成ステージ

タックマンモデル。チーム形成のステージを5つに分類している。
- 形成期
- 混乱期
- 統一期
- 機能期
- 解放期
形成期、混乱期は、自分が良かれと思ったことをそれぞれやりだす時期。
当初、タックマンモデルは4つだったが、後に解放期が追加された。
安定して機能するチームの形成には半年、早くても３ヶ月はかかる。
形成期、混乱期から統一期へ至るには、以下を合意していることが必要。
- ゴール
- 目標
- 価値観
とはいえ、これらはそんな簡単には合意できない。
- そこで、上記の合意に至る前に、以下を合意する。
  - 『相手のことを良く知ろう』ということについて合意。
  - 『自分たちはまだ合意していない』ということについて合意。
  - 『引き続き検討していく』ということについて合意。

Amazonのリーダーシップ原則

Amazonでは社員全員がリーダー。
- 合意しないことについてどのように振る舞うか示されている。
  - 賛成出来ない場合は異議を唱える
  - が、一度チームが決定したら、全面的にコミット。
  - 『俺は反対したからやらない』はナシ。
- リーダーシップ原則は14箇条ある。
  - Webに載っているので見ておくと良い。

多数決の危険な罠

とある、なかなか話が進まない漫画の中で、多数決のリスクについて書いてある。
- 実は少数派の意見を抹殺している行為。
- 常に少数派に回る側の人は不満を募らせることになる。
- 初期の段階で多数決を決めるのはリスキー。
そこで、5本指で意見を聞くという方法がある。
- 意思決定をする際、挙手を求めるが、その際の指の数で賛成度合いを示す。
- この考え方はプランニングポーカーに通じる。
  - プランニングポーカーではフィードバックを行うことで理解を得る。

チームの責任

説明責任と改善責任。
- 完成責任をチームが負うことは無理。
- ただ、全力を尽くす責任はある。
チームのルール
- 外部のルールが障害になることがある
  - 思考停止しない事が大事。
  - 意図がわからないものや、不要なものは廃止する。
  - ルールにないものをやっていいと考えるか、やってはダメと考えるか。
    - その人のバックグラウンドによって大きく別れる。
    - やってはいけないわけではない。
- 大野耐一の言葉。
  - 『言う通りやる奴はバカで、やらん奴はもっとバカ。もっとうまくやる奴が利口』
- 自分たちのルールを自分で作ること。
硬い会社だと、できない理由を先に言ってしまう。
- 出来る方法を考えること。
- 部下が何か提案した時に『ルールだから駄目だ』と返すマネージャがいる。
  - 私見だが、これはマネージャの職責を果たしていないと言える。

スキルの見える化

チームでスキルマップを決める。
- 出来ること、できないこと、今後習得したいことをしるし付け。
- 1ヶ月ぐらいの単位で更新していく。
- スキルが見えると、そのチームのリスクが見える。
  - あるスキルを持った誰々が倒れたらヤバイ、とか。
- 『マネージャが人事評価に使おう』と言い出すことがある。
  - そう言い出した瞬間に、みんな甘くつけ始める。
  - 絶対にダメ。
- 『チームのためにやる』事が大事。
個人としてのスキルアップをどう考えるか。
- 『個人として変化に対応するか?』という問題。
  - 個々の価値観の問題。
  - 『1回限りのプロジェクトなので成長する気はない』
    - という人に対しては、
  - 『変化に対応しないなら生殺与奪の権利は自分以外の手に移るよ』
    - と一応言うことにしている。
- 自分を守るために自分にスキルをつける、ということ。
- 過去の成功体験と不安が変化を阻む。

単一障害点

チームに問題が起こった時のことを考える。
- 問題が起こっても許容できるなら放置すればよい。
- が、その結果夜も眠れないとしたら、何かが間違っている。
- この時の対策は『特定の人しか知らない情報』をなくすこと。
  - 一方で、誰しも、自分の仕事を守りたい要求がある。
    - その要求を捨てること。
    - 外で役に立たないものを守る意味はない。

マネージと委任

SL理論
- チームの成熟度に応じたマネジメント手法。
- 成熟度に応じて4種類のマネージを使い分ける。
  - 指示(S1)
    - マネージャが意思決定し作業指示。
  - 説得(S2)
    - 考えを説明して方向性を示す。
  - 参加(S3)
    - 意思決定に参加し助言。
  - 委任(S4)
    - 進め方、意思決定も含めて任せる。
- いきなり委任してもうまくいかない。

チームメンバーの入れ替え

一度に入れ替えた場合、既存のチーム文化は失われることを覚悟しなければならない。
一度に入れ替える人数は少なく(1,2人)。

採用

一緒に働く人が採用の判断をした方がいい。
- 期待値を明確に。
- チームがぶっ壊れない人を。
- 会社のカラーに合う人を。
- チームの平均以上の人を取り続ける。
退職
- やめる理由を生々しく聞いたほうがいい。
- その理由を聞いた上で改善すれば、同じ理由による退職を止められる。
- ちなみに、退職理由の中で『給与』は5番目。

組織構造とアーキテクチャ

システムを設計する組織の組織構造は、その組織が作る製品のアーキテクチャとそっくりになる。
- マイクロサービスをやりたい、と思うかもしれないが、
  - それができるかは組織に依存する。
  - 分業が増えるだけかもしれない。
  - 自分のチームに合うかどうかを考える。
- チームの外側を見る。
  - 開発(Dev)のスループットは高いが、運用(Ops)のリードタイムが長いかもしれない。

コミュニケーション

コミュニケーションはHow。
- 目的ではない。
- 何のためにそれが必要かの合意が要る。
コミュニケーションには段階がある。
- 送信済み
- 受信済み
- 理解
- 合意
- 行動
行動になって初めてコミュニケーションが成立した、と言える。
同期型と非同期型のコミュニケーションを使い分けること。
チームが生産性を保つためには、会議を減らす方向に持っていったほうがいい。
- 挙手アンケート『１日の業務のうち、会議の比率が25%を超えている人?』
  - 25%を超える人は3割ぐらい。
  - ドラッガー『1/4以上会議に使っているなら、組織構造に問題』
コミュニケーション頻度が高い場合、組織構造が問題。
技術的に解決する方法もある。
- Amazonの事例。
  - 昔、繁忙期のサーバ機能増強の際、都度インフラ部門に調達要求をしていた
  - この手続きをAPI呼び出しに置き換えた。
  - コミュニケーションのオーバヘッドを削減。
  - 人のリアルコミュニケーションにしておく必要は必ずしもない。
  - Amazonには他にも『2ピザルール』¹とか色々なルールがある。
    - 調べておくといい。

評価とフィードバック

評価の基本原則
- 価値観、優先度、期待値、求める成果を『先に合意せよ』。
  - 後出しを避ける
- 当たり前だが公平、公正であること。
- 定量評価と定性評価を組み合わせるとよい。
  - 定量だけにすると倫理観が崩壊する。
- 仕事をうまくやるのが目的。
  - 1ヶ月から3ヶ月程度のスパンで頻繁に行う。
  - ピアレビュー(1:1)で行う。
    - アマゾンだと1ヶ月に1度、全従業員が直属上長と1:1で話す。
フィードバック方法
- 頻繁に。
- 常時ネガティブなことを言ってはダメだが、必要に応じて。
  - 個人攻撃と取られないように言う。
  - 個人攻撃と取らないように聞く。
  - "I message"(私はこう思う/感じる…)を使う。
  - 対立構造に見える座り方を避ける。

チームの規模はピザ2枚でまかなえる程度にせよ、というルール。↩

2016-02-21

Developer's Summit 2016 【19-E-2】実演＆全員参加型 - 鳥肌必至のニューラルネットワークによる近未来の画像認識技術を体験し、IoTの知られざるパワーを知る聴講メモ

Developers Summit セミナー聴講メモ

講演資料

http://www.slideshare.net/nkjm/iot-58447760

概要

　ニューラルネットワークのライブラリを用いた画像認識のデモと、Oracle Database Clowdでリアルタイム機械学習を活用した例を通して、機械学習の可能性を紹介する。

スピーカー

Oracleの中島さん。

詳細

　デモをメインとしたセッション。

前準備

最初に、quiz.oracle.tokyo/ds というサイトにつなぐことを指示される。
- node.jsを使ったリアルタイムアンケートシステム。
- Oracle Database Clowdに興味があるか? と謎の質問をされる。
  - 割と『いいえ』が多かった。

Neural Network

脳の神経回路を模した機械学習のアルゴリズム
- めちゃめちゃ難しい
- 簡単に紹介してもらったと言いつつ難しい
画像認識や自動運転の世界で応用されている
- そこで、まずは画像認識がどれほどの精度を持っているのかを伝えたい

デモ(静止画像が何であるかを認識する)

キーとなるライブラリ

TensorFlow
- Googleの機械学習ライブラリ
- セットアップ、記述が簡単
Imagenet
- 今回の画像学習データのモデル
- 世界中の物体、名詞について1000個ぐらい保持
この組み合わせはTEDで有名になった。
- コンピュータが写真を理解するようになるまで (https://www.ted.com/talks/fei_fei_li_how_we_re_teaching_computers_to_understand_pictures?language=ja)
- めちゃくちゃわかりやすいので、後で興味のある人は見ておいてもらいたい。
このライブラリを使ったデモ¹を動かす(http://tf.oracle.tokyo/)。
- 画像をアップロードすると、その画像が何であるかを示すWebアプリ。
- 暖炉(薪ストーブ)っぽい写真をアップロードする
  - 『99%でストーブ』と認識
- ちなみに暖炉と薪ストーブは厳密には違うらしい
- ミニチュアダックスフンドの写真をアップロード
  - ゴールデンレトリバーとして認識された。
  - まぁその程度。ライブラリはゴールデンレトリバー好きらしい。

デモ(静止画像を自然言語で表現する)

キーとなるライブラリ

NeuralTalk2
- 画像認識ライブラリの一つ。
- 何ができるのかをビデオで紹介(https://vimeo.com/146492001)
  - スマホを持って町を歩くと、スマホのカメラが見ている景色を、リアルタイムで英語表示してくれる。
- このNeuralTalk2を使ったデモ。
  - 椅子の上に犬が座っている写真をアップロード。
  - 英語でdog on the chairみたいな文章が表示された。

IoTとどう繋がるのか

防犯カメラ
- 今は画像を撮影しておいて、インシデントがあったら解析のために後から使われるが…。
- 機械学習を併用すれば、撮影した画像をテキストに落とし込める
  - 撮影中にアラートを鳴らし、即現場に急行する事ができるかもしれない。
  - 加えて、テキストを元に動画内を検索できるようになるのではないか。
- メカニズムとしては、カメラ→画像解析→データベースに保存→異常検出という流れ。
  - もう少し実装の話をすると、カメラ→Node.js→TensorFlow→Oracle Database Clowdという流れで機械学習、異常検知を行う。
- ここでOracle Database Clowdという言葉が出てくる。
  - 昔はOracleは売りきりだったが、今は従量課金のクラウドデータベースを提供している。
  - データベースクラウドの中に機械学習を組み込んでいる。

デモ(普段と違う画像を検出する)

家の玄関ドアの画像を以下のバリエーションで数枚アップロード。
- 夜間、ドアの前に誰もいない画像。
- 夜間、ドアチャイムを鳴らす人が撮影されている画像。
- 朝、ドアの前に誰もいない画像。
この時、チャイムを鳴らす人が撮影されている画像を機械学習で検出できるかを見てみる。
SQL DeveloperでOracle Database Clowdをコントロール。
- 操作はアイコンベース。
- ワークフローを作成し、画像を格納したデータベースと機械学習のアイコンをマウスでつなぐ。
- すると、各写真毎にアノマリ検知の有無(0 or 1)と確率が出力された。
- 当初は他の写真もアノマリ検知に引っかかっていた。
  - が、NeuralTalk2で出力したテキストと併用して機械学習すると、ドアチャイムを鳴らす画像だけがアノマリ検知された。
データベース上に機械学習エンジンが組み込まれている。
- つまり、リアルタイム分析が可能ということ。
- また、SQL上でアノマリ検知をクエリに組み込んだり、分析対象をチューニングすることができる。
  - SQL上で分析可能ということは、アノマリ検知をそのままWebアプリに組み込むことが可能ということ。

Oracle Database Clowdの機械学習

Enterprise High Performance Edition以上だと機械学習が可能。
- OSS製品と比較すると高いけど、従来のOracleデータベースと比較すると安いんじゃないか、と思っている。
- Oracleもかつては企業向けデータベースを高値で売っていたが、今はクラウドへモデルチェンジを行っているところ。
- DBクラウドはREST APIでアクセス可能なので、様々なデバイスからでもアクセス可能。
- 使ってみてね。

告知

3/4 Oracle Cloud Developerというイベントを開催予定とのこと。

最後に

リアルタイムアンケートシステムで、Oracle Database Clowdに興味があるか? と再び質問をされる。
- 『はい』が増えていた。²

講演後も稼働しているみたい。気になる人はお試しあれ。↩
営業上手でした。↩

モジュール結合度(coupling)

外部結合と共通結合の違いは？

どちらが正しいんだろう？

まとめ

講演資料

概要

スピーカー

詳細

ハードウェア開発の混沌

何が悪いのか？

資金調達

実例

イノベーションを起こすためには

OSSのエコシステム

ラーメンスタートアップ

ラーメンスタートアップはハードウェアでは可能か？

世界と戦うためには

知財の問題

本当に必要なのはコピーに勝つこと

価格的には中国サイトで調達するという手もあるが

中国国内でも偽物には辟易

悪にならないためには

ハードウェアのことを知るには？

まとめ

告知

講演資料

概要

スピーカー

詳細

所属している会社

最新Androidの事情

アクセス制御リスク

HTTPS通信

暗号

Mode World

ダウンロード数と脆弱性の関係

セキュアな開発をするには

セキュアコーディングガイド第6版で追加された内容

1. 6.0のパーミッションモデル変更に対応

2. 指紋認証アプリ

3. Lまでの新規事項に対応

講演資料

概要

スピーカー

詳細

ブロックチェーンとは

ブロックチェーンの課題

コンセンサスのプロトコル

ダイジェストを格納するブロックの連鎖の構造

取引の消去に対する保護

デジタル署名

ブロックチェーンの応用可能性

金融機関

自律分散組織

ブロックチェーンと現実世界

これからの可能性

まとめ

講演資料

概要

スピーカー

詳細

リクルートコミュニケーションズ

組織のスループットを上げる

エンジニアが発揮する価値

RCOにおける取り組み

『採用』

『目標設定』と『評価』

『機会の提供』

まとめ

講演資料

概要

スピーカー

詳細

ピープルウェアの言葉

チームの課題とカイゼン

カイゼンの進め方

なぜチームが必要か

強いチームの形成

チームの形成ステージ

Amazonのリーダーシップ原則