読者です 読者をやめる 読者になる 読者になる

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と異なる点。
  • IoTについては、『スタンドアローンだったものが、つながって異なる価値を創造する』 というざっくりとした理解でいい。

IoTの構成要素

  • 8つのレイヤに分けて考えている。

    • アプリ
    • クラウド
    • 通信規格
    • コアモジュール
    • ソフトウェア
    • 認識、検知
    • ハード、物理
    • 以上を横串で通すレイヤとして、セキュリティ。
  • こうしてレイヤ分けてして考えているのは、『組み合わせの柔軟性を確保すること』と、 『難しいところを特定する』ことが目的。

  • このレイヤ上だと、コアモジュールが一番難しいと思っている。
    • Raspberry Piとか、Armadilloとか
    • あるいはSIMとかハードウェア。

成功するIoTとは?

  • 『モノをネットにつなごう、ビッグデータを使おう』ではなく、
  • 『課題を明らかにし、その課題をIoTを使って解決できないか』が大事。

IoTの類型と課題解決価値

  • モノ型
    • モノがネットワークにつながること自体の価値を享受する。
  • データ型
  • これからは、課題解決型が重要では。
    • ITでは解決できなかった企業課題の解決に価値がある。

Usable

  • IoTをビジネスとして成立させるキーワードとして、『Usable』を掲げている。

    • 『User』+『Able』。
    • 使い手が、今までできなかったことができるようになるということ。
    • モノから発想すると課題解決にならないものが多い。
  • Usableには5つの観点がある。

    • 多くの人が欲しいと思える。
      • 使い手のニーズに耳を傾け、喉から手が出るほど欲しいものを。
    • すぐに使える。
      • 昨今ではiPhoneのように説明書なしに使える製品も多い。
      • 感覚的に使えるかどうか。
      • 一瞬で使えないと見向きもされない。
    • ITを意識させない。
      • ITに疎い人が使えるものがIoTでなければならない。
    • 便利になる。
      • それ、今までと何が違うの? 便利になるの? という視点。
    • 企業がきちんと儲かる
      • すべてのプレイヤーが儲かること。
      • これがないとプロトタイピングで終わる。
      • この辺りはトップダウンでやらないとなかなか難しいのではないか。
      • 明確な費用対効果がないと進まない。
  • 以下2点を出発点として意識するようにしてほしい。

    1. 課題を解決できているかどうか
    2. Usableであるかどうか

IoTプロジェクトの進め方

  • IoTプロジェクトの進め方がわからない。

    • ITだとSIerという存在があるが、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の試験とかでよく問われる単語ですね。

 このモジュール結合度、こんな感じで順序付けされています(昇順)。

  1. データ結合
  2. スタンプ結合
  3. 制御結合
  4. 外部結合
  5. 共通結合
  6. 内部結合

 この中で、"外部結合"と"共通結合"の差について、とある場所でとある先生がとある言説をしていたのを聞きとがめまして。

『外部結合は外部データをお互いが共有するというような情報の共有方法』

『共通結合は構造型の外部データを共有する方法』

 え、これおかしくないですか? と思った私は、先生の講義そっちのけで調べ物に入りました。

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

 なんとなくおかしいなと思ったのですが、この言説って結構あるんですよね。

モジュールの強度と結合度<システムの調達<Web教材<木暮

http://www.geocities.jp/nakamiya_town/ProModule.html

d.hatena.ne.jp

 で、WikiPediaによるとこうあるわけです。

結合度 - Wikipedia

共通結合(Common coupling)

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

外部結合(External coupling)

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

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

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

Coupling (computer programming) - Wikipedia, the free encyclopedia

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インタフェースを参照する等、グローバル変数とは異なる同一のリソースを参照しているケースですが、この場合、

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

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

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

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

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

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

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

まとめ

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

 という話でした。