*begin*back*foward*end*contents

開発フェーズ編 -
第23章 システム共通設計

23.1 目的

システム共通設計フェーズは、問題領域分析フェーズの開発基盤検討書により決定されたシステム実装基盤を基に、システム構築における全体的な設計を行う。また、システム開発における共通的な作法(開発ルール)についても決定する。

問題領域分析フェーズで作成された要求モデルは、システム共通設計フェーズによって、実装環境における再利用コンポーネント・フレームワークをベースとしたアーキテクチャモデルに移行される。

23.2 作業ドキュメント

システム設計フェーズで作成するドキュメントの一覧を示す。

ドキュメント名 解説 様式番号
システム開発環境標準 システム全体の開発環境を統一的に管理するためのルール 2-01
システムアーキテクチャ仕様書 システムの基本構造、アプリケーション構成、アプリケーション間のコミュニケーション方式などについて仕様化したもの 2-02
システム機能仕様書 システムの提供する機能を解説する仕様書 2-03
システム操作説明書 ユーザの立場からシステムの操作方法を解説したもの 2-04

23.3 作業項目の解説

システム共通設計フェーズでの作業は、システムで総括的に決定すべき項目の設計が主となる。その留意点は、「個々の設計を深めながら、システム全体としてのバランスを取ることを早急に進めることで、早い時期にアプリケーション設計フェーズやコンポーネント分析フェーズに作業を引き継ぐ」ということである。 そのためにそれぞれの専門知識を持ったキーとなるエキスパート達を「システム共通ワークショップ」に呼ぶことで、専門知識を結集させ、それぞれの設計項目を統合的な視野で洞察しながら、共通的な設計や方針の決定をできるだけスピーディーに行っていくのである。

システム共通ワークショップ

「システム共通ワークショップ」の円滑な運営によって、個々の設計が統合化され、その上でコンポーネントやフレームワークが抽出・具体化されることになり、システム開発のための統合化されたフレームワークを形成することが可能となるのである。 つまり、システム共通設計フェーズは、システム開発において一貫した設計を遂行させるために、計画を立ててコントロールする期間と考えることもできる。

システム共通設計フェーズで行う設計を大きく分けると、システムの内面的な構造に着目する「内部ビュー設計」とシステムの外面的な構造に着目する「外部ビュー設計」に分類できる。 ADGチームはどちらかというと外部ビュー設計を先行させる。一方、ODGチームは内部ビュー設計面で先行した支援を行う。 決定後は、作業分担を明確にし、ADGチームとODGチームに作業を分配する。

外部ビュー設計(システムの仕様の視点)

ユーザに対してシステムを使いやすくするための仕様のを設計する。従って、外部ビューで取り扱う設計対象は、システムの使い勝手に密接に関係する項目が対象となっている。

内部ビュー設計(システム実現の視点)

システムの要求を実現するためのソフトウェア構造をとらえることが中心となる。よって、問題領域分析フェーズで作成された要求モデルをシステムの実装基盤(ハード・ソフトを含むアーキテクチャ)に適合させるための設計ということになる。

sorry this is image
図23-1 システム共通設計作業項目

外部ビュー設計

外部ビュー設計は「システムがどのように使われるのか?」「どのような構成が使いやすいのか?」といったアプリケーションユーザの視点に立って行うものである。ここで決められた細かな設計は、内部ビューでそれを実現するためのソフトウェア構造に落とされる。

ユーザインタフェース共通設計

ユーザインタフェース共通設計は、開発するシステムの操作性を共通化する作業である。システム全体の操作性を向上させることが目的となる。

「システム共通ワークショップ」により、システム全体としての統一的な操作基準を定める。操作基準は、システムを実装するOSまたはGUIにおける一般的な操作規約(または慣習となっている操作基準)をベースに、システムの仕様として新たに必要となる以下のような操作を共通化する。

  • 特殊なカーソル操作
  • 特殊なマウス操作
  • 連続的な流れが必要となる画面操作

また、この操作規約の決定過程では「ユーザインタフェースプロトタイプ」によって操作性と実現可能性を検証することが重要となる。

アプリケーション分割設計

要求仕様を基に、システムをアプリケーションの単位に分割する。このアプリケーションの単位とは、開発システムを利用者の使いやすい単位に分割したものでりある。たとえば、利用者が「運用者」と「管理者」に分かれる場合は、「運用アプリケーション」「管理者用ツール」といった形に分類できるだろう。

アプリケーション相互作用設計

分割されたアプリケーションは、システムを利用者にとって分かりやすい単位となる。しかし、これらのアプリケーションを統合したものとして見せることも重要となる場合もある。たとえば、利用者が使う複数のアプリケーションの間でデータを共有させたり、前工程のアプリケーションのアウトプットが次工程のアプリケーションのインプットとして必要になる場合などである。

このようなシステムでは、システムの統合環境を実現するために、アプリケーションが相互にデータ交換を行うための流れや、他のアプリケーションとデータや機能を連携させるための基盤となるアーキテクチャを決定する。

システム機能・操作設計

問題領域分析フェーズで定義された、要求仕様書とシネマスコープモデルにて作成されたシナリオを基に、システムの機能とシステムの操作方法を、分割されたアプリケーションごとに詳細化する。この作業の成果ドキュメントとして、「システム機能仕様書」と「システム操作説明書」がある。両ドキュメントは、要求仕様に記述された機能について、完全に実装されるOS、GUIに合わせて作成されるドキュメントである。

内部ビュー設計

内部ビュー設計は「システムをどのように作るか?」「どのようにすれば全体的な生産性が得られるか?」といったアプリケーション構築の視点に立って設計を行うものである。外部ビューで定められた共通仕様を、具体的なソフトウェアとして設計する。

まず、設計項目毎の概要を述べ、その後「要求モデルからアーキテクチャモデルへの移行」により、どのようにして要求オブジェクトをアーキテクチャレベルのオブジェクトに変換していくのかについて説明する。

データストア設計

ADGのシステム分析者が中心となり、要求モデルのオブジェクトの中でデータに永続性があるもの、そして、システム共通となるものを中心に具体的なデータストア方式について設計を行う。 データストア設計の対象となるものは、要求モデルの中で分類されたDataManageに属するクラスである。データストア方式は開発言語やクラスライブラリによって異なるものであるが、一般的には表23-1のようなものが考えられる。表の(1)や(4)を選択する場合、オブジェクト設計とは別にファイルフォーマットやデータベーステーブル設計が必要となり、DataManageオブジェクトからファイル(or データベース)に相互変換するためのProcessを設計しなければならない。

表23-1 データストア方式例とその特徴
NO 必要条件 ストレージ方式 主な特徴 効果
(1) 非リアルタイム処理 ファイル入出力クラスの利用 テキストベースの入出力 テキストファイルなので参照・変更が容易
(2) 非リアルタイム処理 オブジェクトシリアライズ機能 オブジェクト自身により入出力 入出力処理コード作成の省力化が可能
(3) リアルタイム処理・並行操作 オブジェクト指向データベース オブジェクトイメージによる入出力 入出力処理コード作成の省力化が可能
(4) リアルタイム処理・並行操作対応 リレーショナルデータベース テーブルイメージによる入出力 インタラクテイブな問い合わせに向いている
プロセス・スレッド設計

プロセス・スレッド設計とは、単1マシンの中でシステムを動作させるための資源管理の単位と動作単位を決めることである。この決定は、アーキテクチヤモデルにおけるオブジェクトの存在空間とその空間同士の関係構造を決定するものであり、システム構造図を使って図式化される。

それぞれの空間に存在する、オブジェクト同士の関係は並行性を持ち、共通的なオブジェクトはオブジェクト属性の共有性を持つ可能性がある。ここでは、この基本的な構造設計を行い、クラスレイアカテゴリのProcessに属するものである。

ネットワーク設計

ネットワーク設計はシステム開発の対象がネットワークシステムの場合に必要となる。 問題領域分析フェーズで作成された実装基盤検討書を元にして、具体的なネットワークモデルを形成する。その際には、プロセス・スレッド設計は、ネットワークモデルの1ノードとして設計され、データストア設計は、データベースの存在するマシンノードの設計となる。

ネットワークモデルは、単純な2層型や3層型、さらにはファンクション層とデータ層を業務毎に分割し、それぞれを結びつけた3層構成の統合システム型など、規模と目的に応じて選択される。

Dropにおけるクラスレイアカテゴリは、このネットワーク3層モデルとの相性がよい。クラスレイアカテゴリ設計によって分割されたカテゴリ中のオブジェクトは、それぞれデータ管理(DataManage)、機能(Process)、見せ方(View)となり、ネットワークモデルのデータ、ファンクション、プレゼーンテーションに関連性が強く、ネットワーク2層型や3層型の構成が取りやすい。

信頼性設計(エラー処理構造の設計)

信頼性設計とは、システム全体としてエラー処理のレベルを統一化した上で、システムの保証すべき信頼性のレベルを決定することである。これは、問題領域分析におけるシステム実装基盤の調査によって決定された基本コンポーネントの信頼レベルに大きく依存しており、利用するコンポーネントの信頼レベルはすでにシステムに要求される信頼性のレベルをクリアしていることが前提となる。これは、問題領域分析フェーズの「実装基盤ワークショップ」により十分検討されていなければならない。

信頼レベルとは、システムのどこかに異常が発生した際、完全に回復すべき範囲と、完全に回復ができない(または回復しようとしない)時に保証すべき範囲を決定することである。つまりフェールセーフな設計(機能やデータが一部失われても最低限の安全性が保持される設計)をシステム全体として統一しなければならない。

この信頼レベルを基に、クラスパッケージ(Dropにおけるソフトウェア配布単位)毎にエラーの構造化を図る。エラーの構造化とは、「エラーチェックすべき範囲」と「エラーを返却する範囲」を決めることである。この決定は、クラス設計の指針となり、最終的には、クラスパッケージ仕様書やコンポーネント仕様書の事前条件、使用条件、戻り値などにより明確化される。

23.4 要求モデルからアーキテクチャモデルへの移行(オブジェクト設計)

先に挙げた内部ビュー設計と外部ビュー設計は、開発する対象からオブジェクトを設計するということよりも、よりグローバルな視野を持っているものである。オブジェクト指向開発であっても、このような視点を持ってシステム共通設計フェーズを行わなければならない。

さらにオブジェクト指向開発においては、内部ビュー設計と外部ビュー設計で定められる設計内容を、オブジェクトという単位にまとめる設計が必要とされる。この設計では、、内部ビュー設計と外部ビュー設計の結果が複数のオブジェクトに体系化されて反映されることとなる。

このことは、「オブジェクトを入れる器を設計する」と「オブジェクトを設計する」ということに例えることができるだろう。すなわち、内部ビュー設計と外部ビュー設計は、ユーザの要求条件に合ったスケールやデザインに合ったオブジェクトを入れる器を設計することであり、オブジェクトの設計とは、器の中に入れるオブジェクトやオブジェクト同士の関係を設計するということである。

ここでは、オブジェクトの設計という視点で、システム共通設計フェーズで行う作業を取り上げる。

つまりここでは、問題領域分析フェーズで作成された要求モデルをどのようにしてアーキテクチャモデルに移行またはマッピングしていくかということについて論じている。

要求理解と要求実現の違い

要求モデルを一言でいうと「要求理解に力点をおいたモデル」である。また、アーキテクチャモデルを一言でいうと「要求実現に力点をおいたモデル」である。この「理解」と「実現」にはモデルの目的の性質に合わせた視点の違いとそれに伴うギャップが存在しているのは明らかである。つまり、「理解」のためのモデルが「実現」のためのモデルに適しているかというと、そうではないことが多い。

しかし、全く異なるものかというとそうではない。「理解」のモデルをソフトウェア環境の都合に合わせて手直ししながら「実現」のモデルを作り上げるのである。その過程では、要求モデルの中のクラスに実装環境に合わせてスーパクラスが付加されたり、内部属性が具体的な型で実装されたり、といったアーキテクチャモデルへの移行が行われる。また、時にはクラスの関係構造や内部構造をソフトウェア環境の都合に合わせて変更することもある。

何れにせよ、システム設計者は要求モデルからアーキテクチャモデルに移行する際に、「理解」のためのモデルが「実現」のためのモデルに適さないこともあり得ることを常に頭に入れておかなければならない。

ここで、このモデルの変更の必要性について、もっと詳しく論じてみよう。

要求モデルからアーキテクチャモデルへ移行する過程では、要求実現のために多くのコンポーネントの必要性が明らかになる。そして、それらは既存のクラスライブラリから再利用可能なものが選ばれ、開発対象のアーキテクチャモデルに導入されることになる。また、新たに必要とされるコンポーネントについてはODGによって開発されることになるだろう。

こうやって選択、または開発されるコンポーネントは、要求モデルが元になっていなければならないのであるが、現実的には、既存のコンポーネントやソフトウェア環境は、要求モデルが完成する前から存在している。よって、要求を最適な形で実現するためには、要求モデルで作成したオブジェクトの構造を、要求を損ねないよう注意しながら、既存のコンポーネントやソフトウェア環境に合わせて変更する必要が生じるのである。

ここでは、アーキテクチャモデルへ移行する際に、どのようにオブジェクトが変化するのか、また変化させるべきなのかという観点からアーキテクチャモデルを解説することにしよう。

アーキテクチャモデルへ移行するためのオブジェクト設計

要求モデルをアーキテクチャモデルへ移行するためのオブジェクト設計項目について以下に説明する。説明の中では、設計項目をGoFのデザインパターンを使って解説する。 なお、以下の設計項目には、どれが先かといった順序などはない。また、システムによっては不必要なものもあるので、対象とするシステムに合わせて必要となる設計項目を参考にしてほしい。

サブシステム分割

サブシステム分割は大規模開発には欠かせない。分析・設計する対象があまりにも広範囲になりすぎた場合、その問題をいくつかのサブシステムに分類することで、見通しの良い設計ができるようになる。

このサブシステムは、たとえば「経理システム」における「販売統計」や「財務管理」とうような外部ビューのアプリケーション分割にマッチすることもあれば、経理システムにおける「DBアクセス」「ネットワーク管理」といったような外部ビューにマッチしない処理単位であることも多い。

このようにして分割されたサブシステムは、システムとしては一つの固まりとして動作しつつも、サブシステム間の独立性は高くなければならない。そのためには、以下の点に注意してサブシステム間の設計を進める必要がある。

  • サブシステムの実装に依存する詳細を不必要に見せてはならない。
  • サブシステムはサブシステムを利用しやすいインタフェースだけを見せる。
  • サブシステム間の結合はできるだけ弱める。

これらのことは、如何にしてサブシステムを構成するクラスやメソッドを隠蔽し、必要なサービスだけを見せられるかというオブジェクトの設計方法にかかっている。このようなサブシステム分割設計においては、デザインパターンのFacadeパターンの考えが必要となる。Facadeパターンとは、図23-2のようにサブシステムの基本サービスだけを見せる(facadeは「外見」という意味)という役割を持つオブジェクトを設けるわけである。つまりFacadeの役割を持つクラスはサブシステムのサービスをインタフェースとして持つクラスである。このFacadeクラスは、上記(2)を実現するために、サブシステムを使うクライアント(これもサブシステム)に適したFacadeをクライアントごとに提供することもある。

また、サブシステムのインタフェースを抽象化することで、サブシステム内部実装を切り替えする際、他のサブシステムに影響を及ばさない方法も考慮すべきだろう。このようにサブシステムのインタフェースを抽象化するには、Abstract FactoryパターンやFactory Methodパターンが参考になる。Abstract Factoryパターンはサブシステムという大きな枠組みを抽象化するためのデザインパターンとして知られている。また、Factory Methodパターンは、Abstract Factoryの実現方法の一種として用いられるデザインパターンである。筆者らのIJAHOプロジェクトでは、FacadeパターンとFactory Methodパターンを使ってサブシステムを抽象化する方法を簡単なソフトウェア例として示したものだ。

sorry this is image
図23-2 Facadeパターン

sorry this is image
図23-3 Factory Methodパターン

*ネットワークノード分割

開発するシステムがネットワークシステムの場合は、2層型や3層型に論理的に分割されたシステムモデルを実際のマシン単位(ノード)に割り付けることになる。この際、それぞれのノードはサブシステムと考えるべきである。つまり、サブシステム分割で述べたようにサブシステム間の結合を弱めるようにしなければならない。このことは、クライアント/サーバ間やネットワーク3層モデルにおけるクライアントと中間層(ビジネスプロセス層)間の設計において重要となる。

このことはCORBAなどの分散オブジェクトを使う際にも同様に重要である。しかしながら、分散オブジェクトを使った設計では、ネットワーク透過性が強調されるばかりに、ノード間の結合度を弱める設計に労力をはらわないことがある。たとえば、サーバ側のリファレンスするオブジェクトを多用してしまう設計である。そのような設計をしてしまうと、異なるノード間に存在するオブジェクト同士の結合度が高くなってしまう。よってネットワークのノードをサブシステムと考え、ノードにFacadeパターンを応用するのである。

図23-4は、このことを解説するために作成したシンプルなモデルである。この図は、スーパマーケットの支店ごとの仕入れ先業者と仕入れ品を管理モデルである。もし、図のB1のアーキテクチャモデルを採用するならば、要求モデルをそのまま反映させたネットワーク透過なモデルとなる。しかし、その反面、クライアントは複数の支店オブジェクトの複数の仕入れ品オブジェクトのリファレンスオブジェクトをクライアントに持つこととなる。たとえば、千個の仕入れ品オブジェクトがあれば千個のリファレンスオブジェクトがクライアントに作成され、それぞれがサーバ側のオブジェクトをリファレンスする。 この結果、ネットワーク上にトラブルが発生した時に対処しにくいシステムとなったり、システム全体としてのスループットに悪影響を及ぼしたりしてしまうことになる。

そこで、B2のようにノードが行うサービスをインタフェースとするような支店管理コンポーネントを新たに設けることを設計として考えなければならない。しかしB2の問題は、サーバ側にある実オブジェクトと切り離されたオブジェクトがクライアントに存在してしまうという問題がある。つまり、クライアント側ではサーバ側の仕入れ品オブジェクトの複製を持つことになり、その属性値が不一致になってしまう瞬間が存在することを考慮しなければならない。よって、B2がよい設計とはいちがいには言えない。実際は、下記の設計要件を参考にそれぞれのトレードオフを考慮し、B1とB2の折衷案を見つける事が必要とされる。

  • クライアントで処理される最小単位のオブジェクトは、オブジェクト転送の方が望ましい。
  • ネットワーク転送するオブジェクトは少量になるよう考慮する(たとえば支店を転送する際は仕入れ先のリンクを切って転送するなど)。
  • 状態管理が複雑なものや、サーバ側で頻繁に属性値が変化するものは、リモートオブジェクトをリファレンスする方が望ましい。
  • 大きなデータを管理し、その中の局所的なデータがクライアントからの要求で更新されるようなオブジェクトはリモートオブジェクトをリファレンスする方が望ましい。

sorry this is image

  • Aは要求モデルである。
  • アーキテクチャモデル(B1、B2)の図では、分散オブジェクトの仕組み上必要となるstubオブジェクトやskeletonオブジェクトを省略している。
  • B1は要求モデルをそのままアーキテクチャモデルにしたもの。実際には、クライアントは、サーバ側のリモートオブジェクトをリファレンスオブジェクト(代理オブジェクト)により参照しているため、ネットワーク透過なモデルが実現されている。
  • B2は要求モデルをノード間の独立性を高めるように変化させたもの。支店管理クラスは、リファレンスオブジェクト(代理オブジェクト)によってクライアントから参照され、要求される支店オブジェクト、仕入先オブジェクト、仕入れ品オブジェクトをクライアント側に転送する。この形式では、クライアント側の空間にサーバ側の部分オブジェクトが転送されることになり、ネットワーク透過性という意味では、B1より劣っている。

図23-4 2つのアーキテクチャモデルの設計例

VPD(View、Process、DataManage)分割

Viewに属するクラスの分析は要求モデルでは対象外となっていた。従って、アーキテクチャモデルによって具体的化される。Viewの具体的なアーキテクチャモデルの構造は、Viewを構築する基盤となる言語、クラスライブラリよって決定されるものである。しかし、その論理的な基本構造は図23-5のように「表示制御部」と「イベント制御部」に分類できる。「表示制御部」とは、ウインドウなどの表示に関するロジックを持っているクラスグループである。また、「イベント制御部」は、ユーザがボタンなどのGUIコントロールによって発生させるイベント処理を行うクラスグループである。

イベント制御部の役割は、イベント要求を機能グループ毎に集結させ、Processへ橋渡し(委譲)することである。 また、関係するGUIコンポーネントを参照し、制御する役割も持つことになる。イベント制御部は、それぞれのGUIコンポーネントを独立させながら管理し、GUIイベントを集中的に受け付ける必要があり、その設計にはMediatorデザインパターンが参考となるだろう。Viewにイベント制御部を作るか否かは設計者の判断に委ねられるが、イベント制御部を作ることでViewとProcess間の結合度が弱くなり、見通しのよい設計ができるようになる。

Processの構造は、図のようにView側にとって使いやすいインタフェースを提供することが望ましい。(Facadeパターン)このようにViewとProcessの独立性を高めれば、ViewとPrcoessの仕様変更がしやすい構造をもたらすことになるだろう。また、Viewが得意な開発者とProcessが得意な開発者にそれぞれ作業を分担しやすくなる。Prcoessは、ネットワークシステムの場合はクライアントとサーバを接合するフレームワークとしても機能する。アーキテクチャモデルで新たに追加されるProcessクラスは、要求機能を効率的に実現するために、アーキテクチャに最適な構造によって実装されることになる。

DataManageに属するクラスは、永続エンジンを実現するProcessクラス(図中のAクラス。ODG作成または市販製品)によってデータベースやファイルに読み書きされる。実際のストレージ方式により、要求モデルに対して永続化のためのスーパクラスが付加されたり、クラスライブラリに属するためのプロトコルを実装するメソッドが付加されることになる。

sorry this is image
図23-5 アーキテクチャモデルにおけるView、Process、DataManageの実現

23.4 チェックリスト

システム共通設計フェーズの作業過程や完了時に、作業内容の評価を行う材料として以下のチェックリストを示す。

  • 安易にシステム固有の操作を共通仕様化してはいないか? システム固有な操作を安易に共通仕様化してしまうと、システムとしての操作性が逆に悪くなってしまったり、多大な開発工数が必要になってしまったりすることもある。 このような問題を回避するためには、ユーザインタフェース共通設計に対して、十分にその必要性と実現可能性を吟味しなければならない。そのためには、できるだけ早くビジュアルツールなどを使ってプロトタイプを作り検証することや、ユーザインタフェース仕様を実際の開発言語で実現するためのコンポーネント開発の実現検証がODGによって進めらていなければならない。プロジェクトリーダは、これらの並行的な意志決定・検証・開発を監視していくために「システム共通ワークショップ」を有効に使うことが重要となる。
  • 共通仕様決めだけを先行させてはいないか? あくまで、実現可能性を検証または把握できたものだけが共通仕様化の対象としなければならない。もし実現方法が分からないものを共通仕様化するのであれば、早急に「システム構造評価プロトタイプ」を使って、仕様の実現可能性とスケジュールの妥当性、そして、仕様自体の妥当性を検証する。そして、その検証結果によって共通仕様の調整を図って行く必要がある。 このようにシステムの類似性質を共通仕様化することは、大きなリスクが伴うものである。しかしながら共通仕様化すべき問題に対して、それをしなかった場合は、もっと大きな問題を抱えることになろう。よって、共通仕様化に対するリスク軽減が重要なポイントとなり、それは実現可能な方法とコストを早急に把握することである。このことがシステム開発において、最も効率がよく、システムの品質を高めるコツである。
  • 共通操作に関する方式仕様だけが決定され、部品化について検討が疎かになっていないか。 方式だけを示して後はアプリケーション任せというのでは、単なる理想を掲げているにすぎない。これでは、単に官僚的な押しつけにすぎない。共通仕様を実現するための共通コンポーネントの開発や、実現方式に対する手順書などを作成し、教育についても計画を立てること。

reference:

参考文献:

  • デザインパターン/Erich Gamma他著/本位田真一、吉田和樹/ソフトバンク
    GoFとは著者の4人組(Gang of Four)ということでGoFデザインパターンと呼ばれている。

参考WWW:

  • IJAHOプロジェクト(Intoranet Java and Horb)
    飛行船予約システムというシンプルな仕様を元に、3層システムのビジネスプロセス層とデータベース層を組み替え可能にしたプロトタイプ開発の事例を掲載している。このプロトタイプのデザイン解説では、View側にMediatorパターンを採用し、Process側にFacadeパターンの考えでAbstract Factoryパターンを採用していることを説明している。
    また、このプロトタイプを例題にした書籍として「最新オブジェクト指向技術応用実践」、萩本/福村/不破、エーアイ出版がある。

*begin*back*foward*end*contents

この記事のトップへ