暗黙的コンテキストが生み出す、技術用語の異なる解釈
発端
サーバーレスアーキテクチャ、なんかサーバーを自前で持たないでマネージドサービスで〜みたいな解説が多いんだけど、それ全然本質的じゃないんじゃないかね
— Naoya Ito (@naoya_ito) 2016年9月14日
最初の感想
これを聞いた時、ちょっと意外だったのです。
…あ、いや、意外というのは、『そういう解説や誤解があるんだー』という意外さです。*1
コンテキストの変化
マネージドサービスって言ったらAWS誕生時点でサーバーレスアーキテクチャじゃん、と後続のツイートを見ずに思ったりしたのですが、サーバーレスアーキテクチャの解説をgoogle先生に聞いてみたところ、こんな記事を見つけまして。
当初、サーバーレスという言葉は、バックエンドアプリケーションを動かすためのサーバーのセットアップと管理を、開発者が気にする必要がないことを意味していた。
ところが、Amazonがサーバーレスのパラダイムを別のレベルに引き上げた。彼らは2014年にAWS Lambdaを発表し、クラウドで動かすアプリケーションに新しいシステムアーキテクチャを取り入れたのだ。そこには、サーバー上で動作して、HTTPリクエストやAPI呼び出しを待つ永続的なプロセスはない。代わりに、AWSのサーバーのひとつで、コードの断片、通常は単なる関数の実行をトリガーするためのイベントメカニズムがある。
AWSがLambdaを世に送り出すまでは、サーバーレスという言葉はマネージドサービスインフラストラクチャのことを指していた、という説明でして。
これを見て、『サーバーレス』という言葉が、発せられる時代などのコンテキストによって多義性を生むことに気づいたわけです。
コンテキストによって変わる解釈
『サーバーレス』という言葉、
- プロセスレス、イベント駆動、使い捨てのコンテナ
- マネージドサービスインフラストラクチャ
という2通りの解釈が、コンテキストによって、それぞれ異なる正当性を帯びているわけですが、私がもう一つ思いついたのはPeer to Peer。
あれも『クライアントサーバモデルとの対比』というコンテキストを加えると、『サーバーレス』って言えちゃうんですよね。
そもそも、『Server』も『less』も、古くから使われる一般的な単語なわけで。そこに一意性を求めるのは結構難しいですよね。
まとめ?
あ、いや、いつもどおりそんな大したものは用意していません。
強いて言えば、
『一般的な単語で一意的な何かを表現するときには、きちんとコンテキストを相手と合意しないと雲をつかむ』
ってところですかね。
おまけ(という名の免責事項)
こういう俺はこう思うけど世間ではこう、みたいなのにギャップがあることを紙媒体に定義を書こうとするとなかなか悩ましい。紙媒体に「個人的にはこうおもうんすよねー、あとからちがってたらごめんね」とか書きづらい
— Naoya Ito (@naoya_ito) 2016年9月14日
個人的にはこうおもうんすよねー、あとからちがってたらごめんね。*2
Developers Summit 2016 Summer B-6 Webサービスベンダーのビジネスを支える足回り - アトラシアン事例 聴講メモ
講演資料
アトラシアンさんの資料は限定配布。
commerbleさんの資料はこちら。
http://www.commerble.com/contents/devsumi2016
概要
スポンサーセッション。Webサービス開発を行うある企業において、アトラシアン製品を使って少人数開発を実施した事例を紹介する。
スピーカー
アトラシアンの新村さんと、commerbleの竹原さん。
詳細
- 今回はcommerbleという会社での事例紹介になる。
- がスポンサーセッションなので、ちょっとだけ自社の宣伝をさせてもらう。
アトラシアン(atlassian)
まず最初に、『アトラシアンという会社を聞いたことがあるか?』という質問。
- 会場では結構手が挙がった(筆者も挙手)。
- 製品の認知度のほうが高いらしい。
2002年オーストラリアで創業された会社。
- チームのために何ができるかを考えるのがテーマ。
- あらゆるチームの可能性を解き放つ、というのがアトラシアンのミッション。
- 目立つ一人の天才の裏にもチームがある。
- チームのコミュニケーションとコラボレーションツールの提供をビジネスとしている。
- 企業のティッカーシンボルはたいてい会社名だったりするが、アトラシアンでは"TEAM"。
- あらゆるチームの可能性を解き放つ、というのがアトラシアンのミッション。
- チームのために何ができるかを考えるのがテーマ。
製品。
- JIRA ServiceDesk(サービスデスク向け)
- Confluence(ドキュメント管理)
- JIRA(プロジェクト管理)
- BitBucket(リポジトリ)とBamboo(CI)
- HipChat(チャット)
事例紹介
- ここでスピーカー交代。
- commerbleの竹原さん含め3人がデモを見せながら説明していく。
commerble
- ECのプラットフォームをマネージドで提供するサービスを実施している。
- 使っている技術
- AWSとAzureの組み合わせ。
- Keycdn。
- New Relic,logentriesなどなど。
端緒
2010年に初リリースしたが、いろんな失敗をした。
- 割と『あるある』な失敗。
- 要件の粒度がバラバラ
- 役割分担のあいまいさ
- まとめて検証(ビッグバンテスト)
- 課題共有されてない
- 割と『あるある』な失敗。
リリースが終わったあとで話し合って改善しようとした。
2年ぐらい前に組織変更があり、社長1人に開発者が3人という少数体制に。
- 管理手間をかけられなくなった。
余談
- リリース後からが大変。
開発の進め方
一般的には要求分析から始まるウォータフォールの工程が知られているが、自分たちの作り方は違う。
どんな問題があるのか考える、感じる
- 問題の定義を適切に行うことが大事
- 問題を課題に分解する
- 2,3日ぐらいの粒度で達成可能な課題に分割する。
- 大きすぎる課題はみんなを不安にする。
- 適切な課題粒度だと、日々の達成感を感じることができる。
- 2,3日ぐらいの粒度で達成可能な課題に分割する。
- チームで課題を共有する
- 課題を起票する。
- この時に担当を決めてしまう。
- お互いの褒め合いに役立つ。
- コード、テスト作成
- 採用する解決策によってはコードを書かないこともある。
- ソース管理
- ブランチ、プッシュ、プルリク、マージ
- 当初はMercurialだったが今はGit。
- 人数が少ないのでルールをきっちり決めてない。
- ビルド、デプロイ
少ない労力で管理する
この手順を愚直にやると、どうやって管理するか困る。
- 人数も少ない。
- 少ない労力で管理する方法が必要だった。
- もっと開発に注力したい。
- 人数も少ない。
解決方法として、各作業でアトラシアンの製品を導入している。
- JIRA、BitBucket,BAmboo,Hipchat。
- HipChatにすべてのオペレーションのログを残すようにしている。
- 何が起きたかトラッキングできるようにするため。
デモ
- ECサイトで販促のため、注文完了したらTwitterでツイートする、という問題解決を行う、というデモ。
その場で課題起票からデプロイまでを行った。
まず、『注文完了したらツイートする機能の追加』をJIRA上で起票。
- 起票するとバックログに入る。
- その後、BitBuckiet上でブランチを切ってチェックアウト。
- Microsoft Stack(Visual Studio)でコードを追加。
- コードを追加後にcommit。
- commit完了したらプルリクし、内容を確認してマージ。
- マージと同時にビルドを自動的に実行。
- いつもの開発環境まではデプロイまで自動で行っているが、今回はデプロイを手動で見せる。
- デプロイ。
- 当該デプロイに含まれるIssueとCommitの内容が画面上に出てくるので確認する。
- デプロイをビビっていると、デブロイ承認のような変なフローが増える。
- お客様の承認は当然必要だが、ステージ環境へのデプロイまでは自動で行うようにしている。
- デプロイが終わったあとに、各々のサーバが自律的にセットアップ(更新内容を自動で取り込んで環境構築)するようにしている。
最後に
- デベロッパーがビジネスのためにできることはたくさんある。
- このやり方が最善だとは思っていない。
- ハイペースでビジネス改善を回すためのツールとして使っている。
Developers Summit 2016 Summer B-2 事例で学ぶ、わかりやすいIoTプロジェクトの進め方 聴講メモ
概要
課題からIoT導入を進めてきた自社の経験を踏まえ、Usable、課題志向に代表されるIoTに対する重要な考え方、技術的な側面、そしてIoTプロジェクトの進め方について、自社事例を説明しながら示す。
スピーカー
詳細
大事にしている考え方
- 個人としても企業としても、『今ある課題にまだない技術を』大事にしている。
- 『まだない課題に今ある技術を』はダメ。
- 価値という点に目が行っていない。
自社ビジネスとIoT
- ECオレンジというサービス名で有名。
- 小売流通サービスが多い。オムニチャネル的なものを作っていた。
- が、サービスを作っていく中で、ソフトウェアだけでは解決できない課題が出てきた。
例えば配送。宅配ロッカーを作ったらどうか、というのがきっかけでIoTをはじめた。
かつては顧客と話をしていると、『ネットのデータとリアルのデータを統合管理したい』という需要が多かった。
- 例えば在庫とかポイントなど。
- 店頭とPOSレジを一括化したい、という需要からiPadを使っていたりしていた。
コンシューマに近い企業を相手にしているので、駐車場、宅配ボックスなど、IoTがソリューション化されているもの、分かりやすいものを作っている。
最近だと、『おかわりコースター』(グラスを置くだけでおかわりをオーダーできるコースター）とか。
IoTとは
- IoTの市場規模は、現状の5,402億円、197億個から13.8兆円、530億個(2020)へと拡大していく、という流れだが、取り組めていない企業が多い。
トップダウンで指示が来ても具体的に進められてない、という感じではないか。
- 『IoT担当になったんだけど、何やっていいか分からない』
何が分からないのか。顧客からはこういう話を聞くことが多い。
- 始め方が分からない。
- 繋ぎ方がわからない。
- アナログ企業だから。
- そもそも定義がわからない。
今までのITとIoTの文脈を同じに捉えている。
- 『IoTわかっている、わかってない』議論は意味がない。
- 方法論を持つことが大事だと思っている。
IoTの定義
- 概念が腹落ちしていないので、考える気にならない。
では、IoTの定義はというと、実はIoTにきちんとした定義はない。
M2Mとの差
- M2Mのシステムとして、コインパーキングのシステムがある。
- 実はネットワーク化はされているが、プログラムの更新が外部からできなかったりする。クローズドネットワーク。
- M2Mにインターネット的概念はないのでは。
- インターネットに出ることは、リスクと隣り合わせ。
- 個人情報、ハッキング等々。
- 最近はSORACOMがSIMを使ってインターネット閉域網を作ったりしている。
- インターネットに出ることは、リスクと隣り合わせ。
- 人が介在する点はM2Mと異なる点。
- M2Mのシステムとして、コインパーキングのシステムがある。
IoTについては、『スタンドアローンだったものが、つながって異なる価値を創造する』 というざっくりとした理解でいい。
IoTの構成要素
8つのレイヤに分けて考えている。
- アプリ
- クラウド
- 通信規格
- コアモジュール
- ソフトウェア
- 認識、検知
- ハード、物理
- 以上を横串で通すレイヤとして、セキュリティ。
こうしてレイヤ分けてして考えているのは、『組み合わせの柔軟性を確保すること』と、 『難しいところを特定する』ことが目的。
- このレイヤ上だと、コアモジュールが一番難しいと思っている。
- Raspberry Piとか、Armadilloとか
- あるいはSIMとかハードウェア。
成功するIoTとは？
- 『モノをネットにつなごう、ビッグデータを使おう』ではなく、
- 『課題を明らかにし、その課題をIoTを使って解決できないか』が大事。
IoTの類型と課題解決価値
- モノ型
- モノがネットワークにつながること自体の価値を享受する。
- データ型
- ビッグデータ活用、集積に価値がある。
- これからは、課題解決型が重要では。
- ITでは解決できなかった企業課題の解決に価値がある。
Usable
IoTをビジネスとして成立させるキーワードとして、『Usable』を掲げている。
- 『User』+『Able』。
- 使い手が、今までできなかったことができるようになるということ。
- モノから発想すると課題解決にならないものが多い。
Usableには5つの観点がある。
以下2点を出発点として意識するようにしてほしい。
- 課題を解決できているかどうか
- Usableであるかどうか
IoTプロジェクトの進め方
IoTプロジェクトの進め方がわからない。
企画、試作、評価、製品化の4つのステージ。
最近は3Dプリンタの登場もあり、少し前にブームになったリーンスタートアップができるようになった。
- IoTの始めもこれでなければ無理と考えている。
- ソフトウェアと同じで、作って壊してを繰り返していく。
企画
ゴールデン・サークル(Why, How, What)を意識する。
- Whyから始めよ。
- 何を作るかから始めるな。
- そうでないと無価値。
以下の流れ。
- 事業方針の確認
- 要件整理
- ニーズを探る
- コンセプトメイキング
- 企画ラップアップ
試作
- まずはプロトタイプしか作らない。
- 自分たちはCAD設計から始め、DMM.makeの3Dプリンタを使っている。
- が、CADの設計自体もDMM.makeとかで外注できるのでそうしてもいい。
評価
- はじめにできたモノは、99%うまくいくことはない。
- テストして改善案を検討する。
- このとき、改善対象はプロトタイプ。
- 製品として改善するのではない。
製品化
- 運用のフェーズでサイクルを止めてはダメ。
- 製品化後のPDCAをまわすこと。
事例紹介
スマート宅配ボックス
- オムニチャネルの概念は『いつでもどこでも購入して受け取れる』こと。
でも実際、受取は不便。
- 不在時に受け取れなかったり
- 宅配ボックスが無かったり埋まっていたり
- コンビニまで行かないといけないとか、近くにコンビニがないとか
そこで、『スマートフォンが鍵になる宅配ボックス』を2年前に作った。
- かねてから『○分後なら都合がいいです』『了解』等、ドライバーとのコミュニケーションが取れたほうがいいのでは と思っていた。
試作を繰り返す中で、
- 『屋外だから電池運用がいい』とか、
- 『中が空ならLEDは緑のほうが分かりやすい』とか、
- 作らないとわからない知見を蓄積していった。
が、実は製品としては販売されていない。しかし運用されている。
- これはプロトタイプと製品の利用形態が違うというケース。
グローバルWifi受け取りサービスへの転用
実は空港で『グローバルWifi』の受取に使われている。
グローバルWifiの空港受付で、ピーク時に受取に長蛇の列ができるという課題。
- 利用者側は『待たされる、飛行機に遅れる』という問題。
- 運営側は『窓口を増やすと人件費もかかる』という問題を抱えていた。
- 費用対効果が見込める案件と判断した。
試作の段階で、自分たちでは物理的なロッカーを作れないので、『アルファロッカー』にロッカーを作ってもらった。
- が、インターネットには繋げなかったので、自分たちでつなげるようにした。
商用システムなので、『基幹DBとの接続』とか『真夜中の運用』等、運用条件がシビアだった。
- が、実現した結果、真夜中でも、無人で素早く(30分以内)受け取れるようになった。
- 明確な導入効果。
eCoPA
自分はかねてから、駐車場について、『空き状況が事前にわからない』『事前予約もできない』点が不満だった。
そこで、スマホで予約決済できるパーキングを考えた。
- 車の後ろのポールでナンバーを認識(特許)し、費用取りっぱぐれを防ぐ。
実はこのeCoPAも試作と実際の運用が異なるケース。
普通のパーキングではなく、観光バスのパーキングに使われている。
- 京都などの観光地だと、観光バスの駐車場がないので、仕方なく運転手が市中をぐるぐるまわるという運用がされていた。
- 自治体としても、渋滞になるので駐車場を作ろう、という動き。
- 導入によって
- 駐車場の運営会社は『満空情報を取得する』という効果。
- バス会社は『駐車場の利用率向上』という効果が得られている。
宣伝
- 今回話したような内容を、『世界一わかりやすいIoTプロジェクトの進め方』という資料としてWeb上に用意している。無料なのでダウンロードして欲しい。
- 8月にIoTの書籍を出版する。
- Facebookでも『Usable IoT』として情報発信している。
- 10/18にIoTカンファレンスを開催する予定。
Developers Summit 2016 Summer A-1 すべてが繋がるIoT時代の共創のあり方 聴講メモ
概要
IoTシステム構築の背景に流れる考え方とビジネス構築時の課題、情報収集を超えて実ビジネスをどう作り上げるかのポイントについて、ウフルの事例と活動を示しながら概説する。
スピーカー
- ウフルの八子さん。
- 松下、シスコを経て現職。
詳細
ウフルという会社
- スワヒリ語で自由を意味する。
- クラウドインテグレータ。
最近IoTに着手。
資本としては、三井、セールスフォース、電通が入っている。
当初、Salesforceが案件の70％を占めていた。Public CloudとしてAWSやAzureも使っていた。
- 最近ioTの相談を多く受けてきたことから、事業部門を立ち上げた。
すべてがつながるIoT時代とは
- IoTは直訳するとモノのインターネット。
モノとデータの結合が一般的な解釈モデル。
だが、実際はデータの活用はできていない。
- 1日2エクサバイトと言われているデータのうち、活用できているのは5%。
- これは現場が忙しすぎるため。
シスコのInternet Is Everythingという言葉があるが、これが理想型だと思っている。
- 人に繋げていくことを重要視していく。
- つながっていないすべてをつなげていくのがIoTではないか。
事例紹介
三菱重工の風車
- 回線はSORACOM
- クラウドはSalesforce。
- 風車の稼働状況の監視。
- 風速に対して適切なアラインをしたり、設計仕様と稼働状況の乖離を調査、分析したりしている。
- 結果は現場の作業員にフィードバックしているが、いずれ追い付かなくなるであろう、という見立てをしていて予測のモデルを立てるところまで考えている。
サトウホールディングスという会社のプリンタ
- 製品用ラベル印刷用プリンタで、壊れると製品が出荷できなくなる。
- 故障予報的な使い方をしている。プリンタのSOS。
- ここには24時間365日、絶対に止めない、という価値がある。
- ので、ゆくゆくはSLAのビジネスモデルも考えている。
- 機会損失で損害が発生するよりも、防止のための費用を支払う、という考え方は受け入れられるのではないか。
境目がなくなる
- IoTの特徴として『いろいろなものをつなげる、境目がなくなる』という点がある。
この考え方はすでに結構浸透してきている。
- 社内と社外
- 自社と他社
- 企業と個人
- 広告とコンテンツなどなど。
convergence/connected the unconnectedという言葉でとらえている。
- 接続によって収斂が起こっていく、という考え方。
- 収斂が起こる際には崩壊が起こるといわれ、収斂元は壊滅的打撃を受ける、と言われている。
これからは業界の境目がなくなるのではないか。
- デジタルオーシャンの間で業界間の融合は実際に発生している。
IoTビジネス構築時の課題
以下のような声をよく聞く。
儲かるビジネスモデルが分からない。
- 騒がれ始めて久しいが、儲かっている人はほとんどいないのでは。
- 物売りはできるがサービスはやりにくい。
- 売り切りたい、という話。
- IoT時代において売り切りはもっとも忌むべき言葉。
- サービスに繋げられない、と言っているのと同義だから。
場所がない、顧客がいない。
- 検討団体もたくさんあるが、調査目的でビジネスにならない。
IoTシステムに対しては、従来の基幹系システムの考え方は全く通用しない。
- 従来は適用技術、稼働環境も含めて安定した環境だったが、
- IoTシステムは稼働環境も含めて不安定な環境。
- これまでの考え方で構築していくこと自体に無理がある。
- また、基幹系システムと違って、IoTビジネスを丸抱えでやる、という考え方が有効なのかは疑問がある。
商用化への道が遠い
コンセプトの検証(PoC)から商用化に結びつけるのが非常に困難なのが特徴。
- 初期の試作では、予算が限られているため、十分な検証が困難。
- 次にやってくるのは予算が割り当てられない事業計画活動。
- 試作とは求められるスキルセットが違う。
- また、追加検証の予算がないので、初期検証で未検証だった点を調べられない。
- 事業計画活動が暗黒のトンネルといえる。
- これを抜けられればいよいよ全社プロジェクト。
- 『体制構築、全社プラットフォーム化など、誰が調整するのか？』という難しい問題。
並列で考えつつ、作りながら考えながら走っていく、というアジャイルな考え方をせざるを得ない。
技術的問題の特徴
- テクニカルな問題の列挙。デバイスからのデータロギング事例から。
- 処理負荷やデータ量によっては、エッジ側デバイスの処理性能と処理ノウハウを要求される。
- これは設計段階では分からない。
- なぜなら予算が限られた中でデバイスを決めないといけないから。
- また、設置環境によってうまくいかない、ということも起こる。
- 設置環境がノイジーでデータが届かないとか。
- 顧客環境も含めたトラブル切り分けまでが必要で、時間をかければできる。
- が、そのトラブルシューティングが大変。これをすべて丸抱えでやりますか？ という話でもある。
- 処理負荷やデータ量によっては、エッジ側デバイスの処理性能と処理ノウハウを要求される。
IoTアーキテクチャ
レイヤ分けすると以下のような構成。
クラウド側
- 業界別サービス、コンテンツ
- 業界別アプリケーション
- プラットフォーム
- ネットワーク
オンプレミス
これに加えて全レイヤを串刺しにする考え方としてセキュリティがある。
- 多種多様、いろんなことを知ってないといけない。
- お客様の環境についても知っていることを含む。
- こうなると、全部自分でやるわけにはいかず、知っている人と連携せざるを得ない。
オープンコラボレーション
米国にIICという組織がある。
- 6月の時点で260社加入。
- 標準化団体ではない。
- IoTについて、どういう事例をどういうテストベッドで作っていくか、ということを検討する団体。
- ユースケースを実現することからビジネスを作ることを重要視している。
- 日本と違って商用化まで持っていく。
実は日本でも立ち上げられたがペンディングになっている。
- 『こういうのをやりたい』というアイディアがないから。
といって、別に日本企業が後れを取っているというわけではなくて、例えばIICにはInfoSysとサカタのタネのテストベッドがあったりする。
標準化について触れないと、『繋がるのか議論』が発生するが。
- そもそもインターネットだってはじめは繋がってなかった。
- まずはローカルで繋がるモデルを作ってくれという話。
IICの考え方で日本にイノベーションを起こせないか、と考えていて、ウフルはそのアクションを起こしている。
- OMGと一緒に日本らしいアプローチを学び、実装する団体の立ち上げ支援をしている。
- 情報収集ではなく、実際に作るということにコミットしている。
- 20社ぐらい。
- 実現したいことが明確だ、ということが重要。
- でないと米国IICのような団体に入っていけない。
- 何がやりたいのかわからない、というのは日本固有の課題。
共創の在り方
- ウフルの考え方は、お客様、パートナーと新しい価値を作るということ。
5つのキーワードを掲げている。
- Decide
- Collaboration
- Innovation
- Dream
- Ecosystem
IoTの真髄はビジネスモデルを変えていくこと。
- 米国の考え方に則りながら、解決する課題は日本の課題。
ウフルは4月にIoTイノベーションセンターを立ち上げた。
- 普通のIoT構築支援なら一気通貫で丸抱えするところ。
- だが、自分達はパーツ単位で提供している。
- 全部を取りに行ってしまうと、全部を買う人としか組めない、という弱点がある。
IoTパートナーコミュニティ
- 日本における企業間コラボレーションのコミュニティとして立ち上げ。
- 現在27社。
- 実ビジネスを構築することを主眼にしている。
- 実ビジネスにもっとフォーカスしてよい。
- 情報収集だけでは共創が生まれない。
- スピーディに検討推進できるかを条件としている。
- 検討や意思決定が遅い企業の参加は断っている。
- 我々だけでできない、という前提であらゆる会社と組んでいる。
コラボレーション
- ウフルのオフィスではあえて壁を作らない空間設計にしている。
- 共創カフェという場所があり、社外の人もコーヒーを飲めたりする。
- 気軽に来てほしい。
- 繋ぐことを重視している。
バックオフィス部門は共創本部と名付けられている。
- 社外の人から何をしているのかわからない、と言われることも。
コラボレーションとイノベーション、人と人との繋がりが重要。
昨日、ウフルは同業のクラウドインテグレータ(FLECT)とセミナーを共催した。
8/4にはSORACOMとセミナーをする予定。
- セミナーよりも懇親会の場が重要で、セミナーではみな本音を言わない。
- 懇親会の場になって、『実はうちもこういうことを…』とビジネスの話になる。
さいごに
- ポイントをまとめる。
- 様々な物事の境目を意識しない、繋いで解決する。
- 自分だけ、自社だけで取り組まない。
- 競合となる企業であっても競争ではなく共に作る。
- 競争の時代は終わっている。
- 小さな課題からスケールして大きな課題を解決することを狙う。
- 小さな課題では儲からないから。
- 生産性向上ではなく、新しいこと、イノベーションを狙う。
宣伝
- 11月に山崎直子さんと講演する。
- 今日の話とは全く違う内容を話すので、楽しみにしていてね。
とある文章を読んで書きたくなった、継承に対する私の印象
発端
http://qiita.com/koitaro/items/c3720d9c3ac1e7b0590f
荒削りですけど、まぁそうですね、という感じで見ていました。
一言書いてみたくなったのは、『継承はis-a関係』の
親クラス作ってまとめたら重複コード減らせる
具体的な判断の仕方
「親クラスで使っているプロパティ、メソッドを全て使える状態であるか」
この辺りですね。
『差分プログラミング』
継承に対する誤解を一番よく表現しているのはこの言葉ではないかなと。
デザインパターンも知られていなかった1990年代頃、当時私も学生でしたが、継承は専らこのコンテキストでもてはやされることが多かったんですよね。
おそらく『構造化プログラミング』からのアナロジーで継承を理解しようとした事による弊害なんだろうなぁ、と今となっては思います。
サブクラスとスーパークラスの可換性についてももちろん説明しようとはするのですが、自動車とトラックとか、動物と犬とか訳の分からない抽象論で終わってしまう所、
『おぉ、継承使えばプログラミングする手間が減って楽じゃん』
という即物的、安直的なメリットの示し方をしてしまった結果かなと。
個人的な経験上、デザインパターンを知ってから継承に対する考え方が180度変わったので、後述する可換性や接合点について、具体的なメリットと好設計例を示せれば、多分この手の誤解を減らすことはできるんじゃないかなぁという感もあります。 *1
『リスコフの置換規則』
上の判断でもそんなにおかしなことにはならないとは思いますが、もう少し厳密な原則で行くならこれかなと。
http://d.hatena.ne.jp/asakichy/20090127/1233109959
『スーパークラスと同一の取扱いをしてもよいか、むしろ同一の取扱いをすべき時にサブクラス化する』
というのが私が継承を使う時の一つの基準です。
接合点
あと、継承は『接合点(インタフェース)を合わせるための手段』だと認識している、というのもあるかなと。
デザインパターンで継承を使う最大の理由ってコレじゃないですか。
他にもモックやらスタブやら、OOPでテストダブルを使いはじめると、いやでもインタフェースを合わせないといけなくなるので、この辺の着想には到達しやすいかもしれません。
まとめ？
部品として使うだけだったら、とりあえずはHas-a(内部クラスや別クラスへの切り出し)を使っておきましょう。
無理して継承を使わなくても、
- 適切な粒度の機能を一つのクラスにまとめ
- インタフェースとして出すものは出し
- 中でしか使わないものは隠す
という基本を実施するだけで、機能的、情報的強度を確保できるので、ちゃんと再利用性も得られます。
今はOOPの原則は充実しているので、継承は差分プログラミング以外の動機にハラオチしてから使うのがいいのではないかしら、という感想でした。
*1: 個々の素養:抽象化力の影響は、当然あるのでしょうけど。
『モジュール結合度』が日本語で説明されている時の誤謬らしきもの
初めてBlogを書くときには軽めのネタがいいんじゃないかなぁと思っていたのですが、ちょうどそんなネタが回ってきたので。
モジュール結合度(coupling)
という言葉を聞いたことがおありの方はたくさんいらっしゃるかと思います。
IPAの試験とかでよく問われる単語ですね。
このモジュール結合度、こんな感じで順序付けされています(昇順)。
- データ結合
- スタンプ結合
- 制御結合
- 外部結合
- 共通結合
- 内部結合
この中で、"外部結合"と"共通結合"の差について、とある場所でとある先生がとある言説をしていたのを聞きとがめまして。
『外部結合は外部データをお互いが共有するというような情報の共有方法』
『共通結合は構造型の外部データを共有する方法』
え、これおかしくないですか？ と思った私は、先生の講義そっちのけで調べ物に入りました。
外部結合と共通結合の違いは？
なんとなくおかしいなと思ったのですが、この言説って結構あるんですよね。
http://www.geocities.jp/nakamiya_town/ProModule.html
で、WikiPediaによるとこうあるわけです。
共通結合（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
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インタフェースを参照する等、グローバル変数とは異なる同一のリソースを参照しているケースですが、この場合、
- 参照している内容、手順は第三者から明確に認識可能
- 明文化された手順、規約に従えば他のモジュールからもアクセスできる
と、ある一定の明確な規約のもとでリソースを参照しています。
いわば明示的な約束に基づいて(外から分かる形で)リソースを共有しているわけです。
一方で共通結合は、グローバル変数を参照していることだけが分かっているだけであって、その変数がいつ、どのようにアクセスされるかは、参照関係にあるモジュール間だけの暗黙的な約束になっています。
暗黙な約束を持つ、ということは、モジュールは相互にどのようなアクセスをしているのかを知っていなければならない、ということであり、その約束は外部から認識できない、ということ。
要は、『共通の秘密を持っている方が結合度が高い』ということ。
察するに、日本語の誤認識は『データ結合』(構造のない引数)と『スタンプ結合』(構造を持つ引数)の差を、英語のリソースを確認せず、外部結合と共通結合に敷衍したことから発生したんじゃないかなぁと、あまり深く考えずに思ったりしましたが、真相はよく分かりませんし、割とどうでも良いですね。
まとめ
- 誰かの話を聞いて、自然でない認識に至る場合は裏を取ったほうが良いですね。
- 古くて定説化されていても、怪しければ英語に当たったほうが良いですね。
- なぜそう位置づけられているのか、という理由は大事ですね。
という話でした。
Developer's Summit 2016 【18-D-5】アジャイル開発でハードウェアをつくる～イノベーションはラーメン食えればいい！～ 聴講メモ
講演資料
http://www.slideshare.net/YoshimasaKawano/20160218-devsumi
概要
アジャイル的な視点でハードウェア開発を見た時、新しいハードウェアを安く早く作ることは可能である一方で、ソフトウェアとは異なる事項について注意しなければならない。これらの事柄を、実例を通して説明する。
スピーカー
秘密結社オープンフォース総統1の河野さん。
- 『Raspberry Pi電子工作レシピ』の著者。
- Iotの薄い本を今回のデブサミで売っている。
詳細
- IoT時代。ハードウェアが次の波になってきていることは認識している。
- Web開発の手法を使ってハードウェア開発ができないか？
ハードウェア開発の混沌
KickStarterとかを見ていると、『ガジェットの混沌』とでも言うべき状態であることが分かる。
例えば『充電ガジェット』。
- 割と誰でも思いつく。
- 焚き火で充電するとか。
- 体温で充電するとか。
例えば『インターネット鍵』。
- BlueToothで鍵を開けられる。
- 電池寿命は1年、とかね。
ところがこれらはエネルギー収支を満たしておらず、使いものにならない。
何が悪いのか？
『デモムービーは実現できない』ということ。
- 物理法則とちょっとした計算で、エネルギーの収支計算はできるのだが、それをしていない。
お金を使わないと分からないこともあるかもしれない。
- 『浸透戦術』2を取る場合、開発のリミッターが人とか、未知のフィールドだから、という場合は有効に機能する。
- が、 物理法則がリミッターの場合、『浸透戦術』では解決できない。
作ってみないとわからないこともあるが、『お金を集める前に作る』事が大事。
例えば自分はガイガーカウンターを作ったことがある。
資金調達
ハードウェア作成、一体何にお金がかかるのか？
- よくあるパターン
- 『コンサルや外注に聞いて作っている』
- 『作ったけど思い通りにならない』
- 『(予算がかかるので)もう一度はできない』ではなく、何度もピボットする必要がある。
- よくあるパターン
このあたりを考えて資金調達元を考えると…。
- 銀行はこの手のやり方に対して相性が悪い。
- VC(Venture Capital)は動くものがないと金を出さない。
- クラウドファンディングは、前述のとおりファンディング前にモノを作ることが肝心。
- 結局は個人で出資が一番いいのでは。
実例
リコーダーミューター3を作りたい人から相談を受けた。
そこで、
イノベーションを起こすためには
フロンティア、高齢化等、実は現在はブルーオーシャンの時代。
- 人手不足と言われるが、逆に人間がいないことでロボットの需要がある。
- とは言え大企業とは違って、いかに下から市場を取っていくかを考える必要がある。
- これは、いかに市場にマッチさせていくか、ということ。
- ピボットを繰り返してマッチさせていく。
電子、電気でやっていることは箱庭に過ぎない。
OSSのエコシステム
- アメリカはシリコンバレーで。
- 日本はIT勉強会で醸成されている。
- 昨今はハードウェア世界でもオープンソースのエコシステムができつつある。
- 勉強会やカンファレンスが増えている。
- 2/11にも、オープンハードカンファレンスが実施された。
ラーメンスタートアップ
ソフトウェアのスタートアップ形態の一つ。
- AWSのt2.microで数ヶ月稼働させる。
- LAMPを使う。
- ソーシャルでPRしながらピボット。
- ヒットしたら一気にスケールするモデル。
- ヒットするまでの間は、ラーメンを食い続けられるレベルの費用があれば良い。
ラーメンスタートアップはハードウェアでは可能か？
ハードウェアは開発に数百万かかるが、ここしばらくで大きく進化している。
ワークショップ、書籍、キットを組み合わせた商流。
- 例えば、自分はラズパイのアドオンボードを作った。
- KiCADで設計。
- 組み立てせずにキット販売した。
- 例えば、自分はラズパイのアドオンボードを作った。
世界と戦うためには
- 中国が最大の敵。
知財の問題
- 特許を日本で取得することは簡単だが、海外展開する場合、なかなか取りきれない。
- 最近はアカデミックと連携しづらい。
- ITとか電子、電気は知財縛りがある印象。
本当に必要なのはコピーに勝つこと
- 中華より安いか、本物を担保する。
価格的には中国サイトで調達するという手もあるが
- 安い一方でトラブルも多い。
- トラブル、偽物は当たり前。
- トラブルマネジメントは必須と言える。
- 逆に、トラブルマネジメントのノウハウは、蓄積すると差別化要因になり得る。
中国国内でも偽物には辟易
- 質の悪い偽物に対しては差別化が可能。
- もっともタチが悪いのは、『質の良い偽物』だが、大抵UIが弱い。
- 忍耐しながら使わないといけない。
- なのでUIを攻めると良い。
悪にならないためには
動く物ファースト。
- 見栄えよりも実証物を。
動いたデータは何よりも雄弁。
- Deliveという電気石窯を作ってみた。
- ラズパイで制御している。
- 温度制御の理論はある。
- が、実際に作ってみるとデンプンのアルファ化による熱移動とか、新しいことが分かる。
- 実際に焼いたデータにはかなわない。
- Deliveという電気石窯を作ってみた。
ハードウェアのことを知るには？
とにかくやってみる。
- イニシャルコストは低い。
ものがないのに費用をつぎ込むな。
- 見栄えにこだわらない事が大事。
まとめ
- (ソフトと比して)ハードウェアの世界は遅れている。
- が、イノベーティブな手法を応用することはできる。
- 早く安く作ることはできる、ということ。
告知
- 9月にオープンハードカンファレンスを東京でやるらしい。
