これは、ウォーターフォール開発を採用するプロジェクトで私が頻繁に経験した失敗パターンであるが、アジャイル開発でも遭遇する。その理由は、そのままのテストモデルがアジャイル開発の中でも用いられるために、同様の失敗パターンに陥りやすくなるからだろう。ウォーターフォールと比べ、1サイクルあたりの開発期間が短いアジャイル開発ではなおさらではないか。
アジャイル開発において、このような従来から抱える問題を解消するテストプロセスとはどういったものか。その問いの中で思い出したのが「アジャイルテストの4象限」だった。"テスト" の4象限ではなく、"アジャイルテスト" の4象限と呼ばれていることに、より注意を向けて見直してみるべきだと思ったのだ。
そこで、その原典であるブライアン・マリックのシリーズ記事をあらためて読み直してみたのであるが、どうやら本質を理解できていなかったようだ。これまでは、アジャイルテストの4象限を単なる「テストの分類を理解するための図」といった程度でしか見てなかった。しかし、そこに描かれていたのは、アジャイル開発を補完するかのようにデザインされたソフトウェア開発手法だったのである。
本稿は、その深掘りを目的としている。
- アジャイルテストの4象限
- 左側象限：「チームをサポートする」
- 左側象限：イテレーションへの効果
- 右側象限：「プロダクトを批評する」
- 開発者テストとアジャイルテストの4象限の関係
- 開発者テスト：Q1
- 開発者テスト：Q2
- 開発者テスト：Q4
- 開発者はQ3にどう関わるのか
- 現実と現在を見る
アジャイルテストの4象限
「アジャイルテストの4象限（agile testing quadrants）」は、2003年にブライアン・マリック（Brian Marick）が、シリーズとしてブログ投稿した8つの記事 "Agile Testing Directions" の中に登場する図だ。このシリーズ記事は、アジャイルテストの将来を見据え、その方向性を示すために記された。その中心を構成するのが、テストの役割を4つに分類し、それらを4つのトピックに分けた解説である。2×2のマトリクスで描いたこの4つの分類こそが、「アジャイルテストの4象限」と呼ばれる図だ。ただしこの、"agile testing quadrants" という呼称は、シリーズ記事の中で出現しない。これはあとから名付けられたものだろう。
4つの象限は、左下をQ1（Quadrant 1, 第1象限）として、そこから時計回りに各順に、Q2, Q3, Q4と呼ぶことが多い。ただし、象限に付けられたこの順序を表す数字は、テストを実施する順序とは関係がない。
アジャイルテストの4象限の上下は、その領域に属すテストタイプが、「ビジネス面（business facing）」のテストを目的としているか、「技術面（technology facing）」のテストを目的としているかで分類されている。
上段に位置する「ビジネス面」のテストとは、顧客やユーザー視点でのテストだと考えると良い。そこで使われる用語は、プロダクトが対象とするドメイン領域で使われる言葉だ。テスト内容も、そこに接している顧客やユーザーが理解できるものであり、機能テストやユーザー受け入れテスト（UAT）といったテストタイプが該当する。
対象的に、下段に位置する「技術面」のテストは、開発者（ソフトウェアエンジニア）視点でのテストだ。ユニットテストや非機能テストなどが該当する。
アジャイルテストの4象限の左右における分類は、テストタイプが「チームを支援する（support team）」ものであるか、「プロダクトを批評する（critique product）」ものであるかを示す。原典の図で左側象限は、「チーム」ではなく「プログラミング」を支援するものとされていたが、シリーズ記事の途中で対象がチームに拡張されている。
左側に位置する「チームを支援する」テストは、機能開発をガイドする目的を持つものだ。基本的に、先にテストが書かれ、そのテストに合格する機能を開発する。TDD（test-driven development, テスト駆動開発）をイメージすると分かりやすいだろう。TDDは、技術面を扱うQ1に位置するユニットテストを先に書く開発手法であるが、ビジネス面を扱うQ2でも先にテストを書くことが想定されている。
右側に位置する「プロダクトを批評する」テストとは、その実施によって、仕様と期待との間のギャップを発見しようとするものだと考えると良い。定義された仕様が、必ずしも顧客やユーザーの期待に沿うものになるとは限らない。そのようなギャップを見つけ出し、それを新たな設計や仕様にフィードバックする役割が、右側に位置するQ3とQ4の役割だ。
この左右の分類こそが、従来のテストとの違いを理解するうえでの肝となるものだと、私は考えている。それが、短いイテレーションで反復的に開発するアジャイルソフトウェア開発プロセスの中でテストが実施されることを念頭に描かれているからだ。そこには大小のフィードバックサイクルが組み込まれている。おそらくこのような前提が、アジャイルテストを特徴づけるものなのだろう。以下でそれを説明する。
左側象限：「チームをサポートする」
左側象限におけるテストは、基本的に、プロダクトバックログアイテム単位や、それをさらに細分化した開発単位、あるいはもっと細かい単位で個別に実施されるものだ。リリースやイテレーションごとに実施する一括テストではない。むしろ後者は、右側象限で主に担うテストであり、それらは従来のプロセスで言うところの「テストフェーズ」以降で実施されるものが主だ。すると前者は、テストフェーズより前に実施されるテストだということだ。これは、品質の保証をテストフェーズに丸投げしていた失敗パターンと対比すれば、テストの「シフトレフト」と言えるだろう。
テストに限らず、シフトレフトがもたらす恩恵の1つは、手戻りコストの低減だ。欠陥を埋め込んでから、それが検出されるまでの時間が短いほど、その欠陥を生じさせている問題が何であるかを特定することが容易になる。欠陥を埋め込んだ本人が、自分がさっき加えた変更に原因があると気づきやすいからだ。最後の最後に位置するテストフェーズになってから欠陥を検出しても、誰のどの変更が原因であるか、解きほぐしていくコストが必要となる。不具合が生じた機能の実装が、必ずしも原因があるとは限らないからだ。
左側象限は、「作る前にテストを書く」というアプローチ、すなわち「テストファースト」という手法をとる。これには主に2つの恩恵がある。
その1つは、「何を作るのか」に対する曖昧さを排除できる点だ。テストを先に書くことによって、仕様を考えるだけでは気づけなかった矛盾点や、未定義のままの詳細などに気づくことができ、より精緻な仕様を定義できるようになる。むしろ、テストを書こうとする中で、仕様を考えるようにもなる。これで、本番稼働後に発生する障害の原因としてよく挙げられる「仕様の考慮漏れ」も生じにくくなるだろう。また、そうして明確に定義された仕様とそのテストがあれば、仕様と実装との間に生じやすいギャップ、すなわち欠陥（バグ）を減らすことも期待できる。もちろんここで言う「仕様」とは、Q2で扱う機能レベルの仕様だけでなく、Q1で扱うコードレベルの仕様も含んでいる。
もう1つの恩恵は、早期にフィードバックを得られるという点だ。テストを書くという行為は、想定する仕様を持つ機能やコードを「使用する」行為である。使用することで、使い手にとってそれが良い仕様なのか、悪い仕様なのか、自然に明らかとなる。テストを書きつつ、それが悪い仕様だと感じたならば、その時点で仕様を変更すれば良い。こうして、小さなフィードバックサイクルが形成され、仕様はより洗練されていくことになる。
これらの恩恵を最大限に享受するためには、仕様を定義する人とテストを書く人が同一人物であるか、あるいは両者が密接に協力する関係が求められる。Q1で用いられるTDDは、まさにこれを前提に置いた開発手法だ。テストコードの作成を他者に委ねることなく、プロダクションコードを書く人が担うことになる。Q2の場合、仕様検討段階から積極的にテスターが関わることになるだろう。「テスターは、テストフェーズだけでなく、プロジェクトの早い段階から関わるべきだ」といった話を聞くことがあるが、その理由はここにもあるのだろう。
このように左側象限は、シフトレフトとテストファーストを通して、仕様の精緻化、洗練化を促し、何を作るべきかを明らかにしていく。これが、「チームを支援する」と呼ぶ理由なのだろう。ブライアン・マリックは、Q1でのTDDになぞらえて、このような開発手法を「例駆動開発（example-driven development, EDD）」と呼んでいる。テストケースやテストシナリオとは、開発対象の使用方法について書かれた「例（example）」であるからだ。
左側象限：イテレーションへの効果
左側象限によるシフトレフトとテストファーストは、開発のあとに開始するテストフェーズの期間を削減する効果をもたらす。テストフェーズに至るまでに一定の品質を保証できるため、テストフェーズで検出される欠陥が減り、欠陥修正に要するコストが小さくなるからだ。また、そもそもテストフェーズまでに終わらせたテストケースは、テストフェーズ内で検証する必要がない。これも、期間の削減につながる。品質の保証を過度にテストフェーズに依存し過ぎてテストフェーズ期間が長くなってしまうこととは対照的である。
短いイテレーションでプロセスをまわすアジャイル開発では、長いテストフェーズは扱いに困る。イテレーション期間に長いテストフェーズを無理に組み込もうとすると、開発期間を圧迫してしまう。仕方なく、テストフェーズを後続のイテレーションに切り出したり、開発した機能のテストをテスターに任せ、エンジニアは新しいイテレーションを開始して次の機能開発に着手したりすることになる。複数のイテレーション分の成果物をまとめてテストするようなやり方もあるだろう。
そういったテストモデルが必ずしも悪いとは思わないが、気になる点もある。後続のイテレーションでテストするということは、欠陥を埋め込んでから、それが検出されるまでの時間を長くする。その時間が長ければ長いほど、検出された症状から原因を特定することが難しくなる。また、欠陥の存在に気づかないまま、その上に積み重ねられてしまう変更の量も、時間の経過とともに大きくなる。それが、修正による手戻りコストを大きくする。テスターにテストを任せて次の機能開発を進めるという方法も、機能開発と並行して欠陥を修正するというマルチタスクを生みやすい。それに、この手法では、次の機能開発のベースとなるコードが欠陥修正前のものとなり、欠陥修正後のコードとのマージがコンフリクト発生の温床となったりもする。スプリント開発であれば、いずれにしても、スプリントレビューをスプリント内に実施することが不可能になるだろう。
しかし、シフトレフトとテストファーストを実現できれば、品質の保証の大部分をイテレーション内の早い段階で完結させられる。テストフェーズを経なくても、多くの欠陥が開発の中で検出され、修正済みとなるからだ。
さらに、テストファーストで書いたテストが自動化されていれば、リグレッションテストに使用することもできる。ウォーターフォール開発プロジェクトに比べ、短いサイクルでのデプロイを繰り返すアジャイル開発プロジェクトでは、リグレッションテストの実施回数がそれだけ多くなる。リグレッションテストも含め、テストフェーズのコストが大きいと、デプロイの頻度を下げようとする意識が働いてしまう。それだけに、高い頻度でのデプロイを繰り返すためには、リグレッションテストの自動化比率を上げ、テストフェーズのコストを下げることが欠かせない。
リサ・クリスピン（Lisa Crispin）とジャネット・グレゴリー（Janet Gregory）は、書籍『実践アジャイルテスト』の中で、左側に位置するQ1とQ2でのテストを特に自動化すべき領域と述べている。
こうなるともはや、テストフェーズがイテレーションに組み込まれているか、そうでないかは大きな問題ではなくなる。欠陥を検出し、それを修正するというテストフェーズの役割の比重は小さくなるからだ。それならば、テストフェーズにもっと他の役割を与えることもできる。それが、右側象限の「プロダクトを批評する」ためのテストだ。
右側象限：「プロダクトを批評する」
左側に位置するQ1とQ2のテストで検出される欠陥は、仕様と実装との間に生じうるギャップだ。ギャップがあれば、仕様に合わせる必要がある。これは、あくまでも仕様を正としている。
右側に位置するQ3のテストでは、仕様を正としない。そこで検出される誤りは、優れたユーザー体験と仕様との間に生じうるギャップと言えば良いだろうか。ブライアン・マリックはこれをイシュー（issue）と呼んでいた。従来型のテストモデルで陥りがちな失敗パターンにおけるテストフェーズでは、仕様と実装のギャップの検出とその修正が目的であった。あくまでも仕様を正としたテストが行われていたのだ。この点が大きく違う。
ここでのテストは、動くソフトウェアをユーザーが実際に体験することが一番であるが、その代替手段として、テスターによる探索的テストの採用もありえるだろう。これが、テストフェーズの新たな役割となるのではないだろうか。探索的テストであれば、必ずしも開発と同期させてテストする必要はない。非同期でテストすることさえ可能だ。ユーザーによるテストにいたっては、リリース後のA/Bテストといった形での実施もあるだろう。なお、アジャイルテストの4象限の様々なバリエーションの中には、A/BテストをQ2に分類するバリエーションもあるが、Q3の方が合うと私は考えている。
一方で、「プロダクトを批評する」という点では、Q4も位置づけは同じだ。非機能テストにより、プロダクトのパフォーマンスやセキュリティ、堅牢性などを検証することになるからだ。これらのテストのいくつかは、自動化してビルドパイプライン内に組み込んでおくことも可能だろう。
いずれにおいても重要なことは、プロダクトを批評することで発見されるイシューは、その領域がQ3であるかQ4であるかに関わらず、欠陥（バグ）ではないということだ。もちろん、多少の欠陥も検出されるが、発見すべきものはあくまでもイシュー（課題）なのである。それが、左側象限で定義される仕様やテストにフィードバックされる。こうして、フィードバックサイクルが形成されるのだ。とても、アジャイル開発プロセスらしいではないか。私はそう感じた。
そういえば、最近、noteに書いた記事『ビジネスインパクトのない新機能に費やす時間とコストを低減する』も、これに関連するテーマを扱っている。このnoteの記事ではアジャイルテストの4象限については書いていないが、フィードバックサイクルがもたらす効率化・高品質化について整理している。
開発者テストとアジャイルテストの4象限の関係
さて、エンジニアリングマネージャーである私としては、アジャイルテストの4象限を、開発者視点でもう少し掘り下げてみたい。
開発者が担うべきテストを指して、「開発者テスト（developer testing）」と呼ぶことがある。私がこの言葉を知ったのは、gihyo.jpに連載された『［動画で解説］和田卓人の“テスト駆動開発”講座』だった。ここでは、開発者テストと並べて、顧客テストとQAテストも紹介されている。
書籍『Developer Testing』の著者であるAlexander Tarlinderは、開発者テストを次のように定義している。
Developer testing is the developers’ intentional and systematic employment of testing tools and techniques to create testable and maintainable software with as few defects as possible.
（開発者テストとは、開発者がテストツールやテクニックを意図的、かつ体系的に利用して、可能な限り欠陥が少なく、テスト容易で保守容易なソフトウェアを作成することである）
この定義からは、開発者テストの範囲が、Q1である「チームを支援する技術面のテスト」を中心として広がるものであることが読み取れるだろう。4象限図にその範囲を重ねたものが、次の図となる（Alexander Tarlinderの図をもとに作成）。
開発者テストの範囲は、Q1に加え、Q2の「チームを支援するビジネス面のテスト」やQ4の「プロダクトを批評する技術面のテスト」にも及んでいることがわかる。
開発者テスト：Q1
まずはQ1の「チームを支援する技術面のテスト」であるが、この象限で扱うテストは、理想的にはすべてが自動化され、もっとも多くのテストケースを有し、それゆえ自動テストの土台となる。テスト自動化ピラミッド（testing automation pyramid）で言えば、最下層に位置する。テストタイプとしては、ユニットテストやコンポーネントテストなどが該当し、テストサイズで言えば、部分的にはMediumテストを含みつつも、多くがSmallテストになるだろう。
ここでのテストにTDDが用いられる理由は、それがソフトウェアの内部品質を引き上げて保守性を高めるからであり、また、テスト自動化が促進されて機能面での外部品質を維持するコストを一定にする働きを持つからだ。TDDがもたらすこれらの効果は、ソフトウェアプロダクト開発には欠かせない。プロダクトは、その長いライフタイムの中で機能追加や機能改善を何度も繰り返す。もし保守性が低ければ、簡単な変更に長い時間を要するようになる。また、テストコストを一定に維持する意味は、先にも述べたとおりだ。
このように、TDDがもたらす価値は高いはずであるが、それを十分に実践し、そこから価値を享受しているソフトウェアプロダクト開発組織がどれだけ存在するのだろうか。その背景として、「そこに割く時間が取れない」といった話も聞く。プロダクションコードを書くことに精一杯で、テストコードを書く時間が無い、といった意味での発言である。では時間があれば、TDDを実践し、そこから十分な価値を引き出せるのだろうか。おそらく、そうはならない。問題はテストコードを書く時間が無いことではなく、テストコードを書くことやTDDを実践するための、知識や経験、そしてスキルの不足にあると感じるからだ。
開発者テストの学習のために、組織が時間を割いていないのだ。優れた品質のプロダクションコードを書くことが難しいように、優れた品質のテストコードを書くことも難しい。そして、その両方の能力を求められるTDDで価値を生み出すことは、さらに難しいのではないか。だからこそ実践だけでなく、そのための能力開発も必要なのだ。
Alexander Tarlinderは、開発者テストを実践するには、いくつかのコアコンピテンシーを習得する必要があると述べている。そして、それを次のような図にまとめている。
これらを体系的に学び、実践を重ねることで、開発者テストの定義である「可能な限り欠陥が少なく、テスト容易で保守容易なソフトウェアを作成すること」が可能になるということだ。
開発者テスト：Q2
ブライアン・マリックによれば、Q1のTDDも含め、左側象限で書かれるテストケースやテストシナリオは、例駆動開発（EDD）における「例（example）」である。その中でも、Q2の「チームを支援するビジネス面のテスト」における例の役割の1つに、「技術のエキスパートとビジネスのエキスパートとの対話の向上（improving conversations between the technology experts and the business experts）」を挙げている。ここで言う技術のエキスパートとは、開発者のことだ。また、ビジネスのエキスパートとは、顧客やそのプロキシを指しており、それはドメインエキスパートのことであるとも言える。
ドメインエキスパートと開発者の対話と言えば、ドメイン駆動設計（DDD, Domain-Driven Design）を思い出す。ブライアン・マリックも、DDDの実践を提案している。Q2で例を書くことでドメイン用語を形成し、その用語がオブジェクトに変換されていく。こうしてドメインエキスパートとの対話を通じて設計とモデリングを進めることが、ここでの開発者の役割なのではないだろうか。
Q2で書かれるテストケースは、テスト自動化ピラミッド内でほとんどが中層に位置し、一部が最上層といったところだろう。テストケース数はQ1のそれより少なく、かつ、実行時間がかかる。主なテストタイプは機能テストであり、テストサイズはMediumからLargeだろう。リサ・クリスピン（Lisa Crispin）らは、書籍『実践アジャイルテスト』の中で、Q2におけるテストの自動化は、可能であればプレゼンテーション層より内側をカバーし、さらに、クライアントアプリケーションがリモートで利用するAPIも範囲であると述べている。
シリーズ記事が書かれた時点ではこの象限におけるEDD実践の事例はあまりなく、どのように例が書かれていくかはまだ探求段階にあったようだ。また、現在においてもEDDの実践について事例をあまり見かけない。私が知らないだけの可能性もあるが、実態としては、それほど普及しなかったのかもしれない。ただし、コンセプトには共感できるところもある。エッセンスを抽出して活用したいところだ。
開発者テスト：Q4
Q4の「プロダクトを批評する技術面のテスト」とは、つまり非機能テストであり、テスト対象となる領域はさまざまである。エンジニアとして真っ先に思い浮かぶのはパフォーマンステストや負荷テストであるが、セキュリティやアクセシビリティなども対象となる。
この象限でのテストを設計し、実施して結果を検証するためには、そのそれぞれの領域において高度な専門的技術が求められる。専用のツールを使いこなすスキルも必要だ。シリーズ記事でブライアンマリックは、アジャイルプロジェクトで求められる人材は、スペシャリストよりジェネラリストだと述べているが、一方でこのQ4についてはスペシャリストが必要となる領域であることも認めている。
エンジニアに限らず、ソフトウェアプロダクト開発組織の中にそのようなスペシャリストが十分に存在するのかと考えると、不足しているというのが実態ではないだろうか。セキュリティについてはツールでカバーできる範囲も広がっていると感じているが、それ以外は人に頼らざるを得ないというのが実感だ。この象限を任せられるスペシャリストは、希少人材なのだろう。
必然的に、この象限のテストは手薄になってしまう。また、ここでのスペシャリストの多くは、テストだけでなく、同領域における設計のスペシャリストでもある。したがって、手薄になるのはテストだけでなく、設計も不十分になるだろう。ソフトウェアシステムに、非機能観点での設計や実装が適切に組み込まれないということだ。
私の実感では、周囲のエンジニアから「優秀なエンジニア」だと認められ、信頼されているエンジニアの多くは、これらの領域を担うスペシャリストだ。逆に言えば、このようなスペシャリストになることは、エンジニアにとって、自身の価値の向上につながる。当たり前ではあるが、エンジニアリング領域を預かるマネージャーは、こういった人材を育て、あるいは獲得することに注力する必要があるのだろう。
なお、ここで扱うテストサイズは当然ながらLargeである。テスト自動化ピラミッドの位置づけは、自動化可能なテストであれば、中層から最上層にあたるだろう。
開発者はQ3にどう関わるのか
開発者テストの範囲に含まれなかったQ3の「プロダクトを批評するビジネス面のテスト」は、開発者には無関係なのだろうか。
Q3のテストでは、ソフトウェアプロダクトを基本的にブラックボックスとして扱うため、その中身を知る開発者が効果的なテストを担えるかは疑問ではある。もちろん、担当外の範囲のテストを担うことで、「中身を知っている」という状況は緩和されるが、やはり中身の推測はできてしまう。
その上、作った本人である開発者が、公平な観点で「プロダクトを批評する」ことができるだろうか。
このように考えると、開発者がこの象限のテストを担うことは適切ではないと感じるのであるが、そうであるからこそ、そこで発見されたイシューは、開発者にとって価値のある情報となる。作り手としての認知の外での気づきとなるからだ。開発者が、このようなフィードバックに注意を傾けることができれば、プロダクトの価値をより高めるヒントを得ることになる。
したがって、Q3における開発者の行動は、テストをよく観察することになるのではないだろうか。例えば探索的テストであれば、テスターとペアを組み、テストの様子を観察しながらそこで発見されたイシューについてテスターと議論する。それは、有意義なインプットとなるだろう。
なお、この象限のテストは自動化対象ではなく、テスト自動化ピラミッドでは、ピラミッドの上にかかる雲のように描かれることが多い。
現実と現在を見る
開発者テストの実践を浸透させるにあたり、現実問題として、もう1つ大きな障壁がある。プロダクトを新規で開発するケースなら良いのだが、大抵のケースはそうではないだろう。それは、既存のレガシーコードと闘うことになるかもしれないということだ。
マイケル・フェザーズ（Michael Feathers）の定義では、レガシーコードとはテストのないコードだ。既存のプロダクションコードに、あとからテストコードを追加するのは非常に難しい。プロダクションコードのテスト容易性が低いのだ。これは経験者なら誰もが実感するところだろう。この現実が、Q1での開発者テストの実践に立ちはだかる高い壁となる。テストを書くためには、コードを書き換えなければならない。ここに割くためのコストが大きいのだ。
もちろん、テストコードを書く対象に優先順位を付けて、新機能開発などで変更が必要になった箇所に対して優先的にテストを書いたり、読む頻度が高いコードの可読性を上げつつ優先的にテストを書くといった進め方もある。しかし、この程度のテスト自動化では、いつまで経っても自動リグレッションテストとして十分に機能しない。結果、手動でのテストに時間がかかり、相変わらずそれらがテスターに丸投げされることになる。
本稿はテスト自動化をテーマとしていないため、この根深い問題への解決策を探求しないが、テスト自動化ピラミッドで示される理想像を目指しつつ、逆三角形からはじめてみるのも、戦略的に悪くはないだろうと考えている。E2Eテストの自動化から始めることで、リグレッションテストをなるべくカバーするのだ。これまで手動で行われていたリグレッションテストのテストケースを自動化するのだと考えると良い。そして、機能変更などによってE2Eテストが壊れる時が、その範囲の自動テストの階層を下げるタイミングだ。
とは言え、これはこれで、理想的なピラミッドに近づくまでにはやはり時間がかかる。やり遂げるために、根気が試されるだろう（ちなみに、ブライアン・マリックは逆に、ユニットテストなどの自動テストが壊れたら、階層を上にあげることを提案している）。
本稿で取り上げたシリーズ記事が書かれた2003年は、アジャイルソフトウェア開発のまだまだ黎明期だ。アジャイルソフトウェア開発宣言は2001年であり、ケント・ベック（Kent Beck）の『エクストリームプログラミング』の英語版書籍出版が2000年で、『テスト駆動開発』は2001年。ちなみに、エリック・エヴァンス（Eric Evans）の『ドメイン駆動設計』の英語版書籍出版は2003年。そのような時代に書かれた記事であることを念頭に置いて、参考にすべきだろう。
