S.O.C.とは、海上コンテナの中で荷主（シッパー）が所有するコンテナのこと^[1]。

スペルアウトとしては

• Shipper's own Container
• Shipper owner Container
• Shipper own Container ^[1]

等の略語として規定されている。対義語はCOC（Carrier's Own Container）。

通常、海上コンテナは船会社ないしリース会社が所有しているものをブッキングした荷主に貸し出す形式を取っている。しかし、タンクコンテナ等、特殊用途に使用されることが多いコンテナは使用頻度が少ないため高コストであり、船会社所有のものはドライコンテナ等と比べて数が少ない状態にある。そのため、荷主・NVOCC自身がコンテナを所有し、必要に応じて使用する形式が取られる。

この荷主・NVOCCが所有するコンテナをS.O.C.と呼ぶ。

• シッパー

表 話 編 歴 インターモーダル輸送
概要	コンテナリゼーション 海上コンテナ ISO 668 ISO 6346コード TEU
輸送	コンテナ船 ドレージ（牽引自動車/セミトレーラー） 鉄道輸送 長物車 コンテナ車 複層貨物鉄道輸送とダブルスタックカー
荷役	コンテナターミナル/貨物駅 コンテナヤード/コンテナフレートステーション 港湾クレーン リーチスタッカー ストラドルキャリア トップリフター フォークリフト 緊締装置 沖荷役
その他	輸送コンテナ 日本のコンテナ輸送（JIS Z1610 - 日本の鉄道コンテナ） フォワーダー 繁忙コンテナ港一覧

SOC

科学技術

• Security Operation Center
• System-on-a-chip
• SOC (航空機) (Scout-Observation) - アメリカ海軍の偵察・観測機
• スピン軌道相互作用、Spin-orbit coupling。
• 充電状態（state of charge）

その他

• SOC(Salon Omnichannel Communication) - 店舗運営を支えるITマーケティングの仕組み
• social overhead capital → 社会資本
• アディスマルモ国際空港のIATAコード
• S.O.C.(Shipper's own Container)
• Service Organization Control - 米国公認会計士協会（AICPA）の基準を利用して提供される内部統制の保証義務の仕組み
• Survivability Overpack Container
• Service Oriented Computing
• Server Object Container
• The Sculpture of Cthulhu
• 関心の分離 (Separation of Concerns)
• 住友大阪セメント
• 首尾一貫感覚 (Sense of Coherence) - ストレス耐性の強さを表す言葉で、ストレスのある経験をしてもそれを人間的成長の糧として捉え、心の健康を保てる能力のことをいう。
• 加群の socle

このページは曖昧さ回避のためのページです。一つの語句が複数の意味・職能を有する場合の水先案内のために、異なる用法を一覧にしてあります。お探しの用語に一番近い記事を選んで下さい。このページへリンクしているページを見つけたら、リンクを適切な項目に張り替えて下さい。

関心の分離（かんしんのぶんり、英語: separation of concerns、SoC）とは、ソフトウェア工学においては、プログラムを関心（責任・何をしたいのか）毎に分離された構成要素で構築することである。

プログラミングパラダイムは開発者が関心の分離を実践することを手助けするものもある。その為には、モジュール性とカプセル化の実装のしやすさが重要となる。

関心の分離は複雑で依存関係が入り乱れたシステムの理解・設計・運用を容易にすることが出来るので他の工学分野でもみられる。

「関心の分離」を意味する英語「separation of concerns」は、エドガー・W・ダイクストラが1974年に論文「On the role of scientific thought」（Dijkstra 1974: 科学思想の役割）で初めて使用したとされている。1989年にChris Reade が「Elements of Functional Programming」（Chris Reade 1989: 関数型プログラミングの要素）というタイトルの書籍で関心の分離を説明している。

関心の分離の例として構造と見た目の分離（英：separation of presentation and content）がある。

以降、ReactというJavaScriptライブラリ（Metaとコミュニティにより開発）での例を挙げる。このライブラリには、ライフサイクルメソッド という考え方を持っている。ライフサイクルメソッドがもたらした機能的凝集度の低さをhookによって克服し、SoCを実現している。

ライフサイクルメソッドは周期（ライフサイクル）のある時点で自動的に呼び出されるメソッドである。例えばコンストラクタはインスタンス作成時のメソッドであり、onMemberChangedメソッドはメンバ更新時に毎回呼び出されるメソッドである。ライフサイクルメソッドとして時間的に適切な処理を実装すれば、ある時点でおこなわれる処理が一か所に集約され時間的凝集度が高いコードになる（時間的なSoCがおこなわれている）。

例えばタイマー2つによるカウントダウンUIを考える。ライフサイクルメソッドを利用する場合、開始時（constructor）でcount変数を用意し、UI作成時（componentDidMount）にタイマーをセットし、レンダリング時（render）にカウント表示を更新、UI破棄時（componentWillUnmount）にタイマーを破棄する。

class Clock extends React.Component {
  constructor(props) {
    super(props);
    this.state = { countA: 0, countB:0 };
  }

  componentDidMount() {
    this.timerIDa = setInterval(() => this.tickA(), 1000)
    this.timerIDb = setInterval(() => this.tickB(), 1000)
  }

  componentWillUnmount() {
    clearInterval(this.timerIDa);
    clearInterval(this.timerIDb);
  }

  tickA() {
    this.setState({ countA: this.state.countA + 1});
  }
  tickB() {
    this.setState({ countB: this.state.countB + 1});
  }

  render(){
    return <div>now count: A/{this.state.countA} - B/{this.state.countB}</div>
  }
}

ある時点で何が起きるかが一見してわかる（時間的凝集度が高い）一方、機能的に見ると一連の処理を時間ごとに別の関数に切り出していることになる。また1つのサイクルメソッドの中にタイマーAの処理とタイマーBの処理が混在することになる。このようにライフサイクルメソッドを用いたコードは時間的凝集度が高くても機能的凝集度は低いといえる。 そこでReactでは機能的凝集度を高めるhookと名付けられた機能を導入した。hookはライフサイクルメソッドのようなclass interface実装ではなく、関数の暗示的状態（非透過的な参照）を利用している。コンポーネントあたり1つしか持てないライフサイクルメソッドと異なり、関数であるhookは何度でも利用ができる。また各hook関数が状態の保持やライフルサイクルの管理といった個別機能を持つため、機能Aに必要なすべてのhookを1箇所に集めることができる。すなわち機能的凝集度が高い状態、機能的なSoCが実現できる。

function Clock() {
  // Timer A /////////////////////////////////////////
  const [countA, setCountA] = useState(0);
  useEffect(()=>{
    const id = setInterval(() => setCountA(n=>n+1), 1000);
    return ()=> clearInterval(id)
  }, []);
  // Timer A /////////////////////////////////////////

  // Timer B /////////////////////////////////////////
  const [countB, setCountB] = useState(0);
  useEffect(()=>{
    const id = setInterval(() => setCountB(n=>n+1), 1000);
    return ()=> clearInterval(id)
  }, []);
  // Timer B /////////////////////////////////////////

  return <div>now count: A/{countA} - B/{countB}</div>
}

"It can take input from the user and display information, but it should not manipulate the information other than to format it for display." p.96

プレゼンテーションとドメインの分離（英: Presentation Domain Separation）は「ユーザーインターフェースコードをその他のコードを分離する」という設計原則である^[1][2][3]。すなわちソフトウェアをプレゼンテーションとドメインという2つの関心に基づき分離するという原則である^[4][5]。

関心の分離により様々な利点が得られる。

• 特定の機能（PresentationかDomainか）に凝集したコードのみへの集中^[6]
• 分業と専門家の活用^[7]
• UIモジュールの切り替え^[8]
• ドメイン部分のテスタビリティ向上^[9]

明確な分離が必要になるか否かはソフトウェアの複雑性に依る^[10]。例えばデータがViewと完全に一致するのであればマッパーでSQLとViewを密結合に生成するライブラリが有用であろう^[11]。しかし複雑性が増すにつれプレゼンテーションとドメインを分離する上記の利点が大きくなる^[12]。

• 凝集度
• 結合度

1. ^ ^{a b c d e f g h i j k l} Fowler, M. (2001-03). “Separating user interface code”. IEEE Software 18 (2): 96–97. doi:10.1109/52.914754. ISSN 0740-7459. http://ieeexplore.ieee.org/document/914754/.