ソフトウェア工学研究の日々

ソフトウェア工学の学術研究を紹介しています。ソフトウェア開発に関する調査と実験が大好きです。

プログラム理解研究のまとめ本「プログラマー脳」

Felinne Hermans: プログラマー脳, 秀和システム, 2023 が、最近(ここ20年ぐらい)のプログラム理解系研究をよく整理しています。表紙には認知科学に基づくアプローチとありますが、認知科学の話がずっと続くわけではなく、プログラマーの行動に関する実験の話がたくさん含まれています。
 ソフトウェア工学、プログラム理解、プログラミングに関する国際会議・論文誌で発表された様々な論文が引用されており、1つの論文が、だいたい1段落~1節ぐらいに対応しています。日本からは、上野秀剛先生(現所属は奈良高専)、中川尊雄さん(現所属は富士通研究所)が奈良先端ソフトウェア工学研究室で行った研究の論文が引用されていました。たとえば、上野先生らの Analyzing Individual Performance of Source Code Review Using Reviewers' Eye Mevement (2006) の内容に基づいて、以下の一段落が述べられています。

アイトラッカーは、人がどのようにコードを読むのかを、研究者がより深く理解することを可能にしました。たとえば、奈良先端科学技術大学院大学の上野秀剛教授率いる研究チームは、プログラマーはまずはコードをスキャンして、つまりざっと眺めてプログラムの動作を把握することを見つけました。(中略) このようなクイックスキャンは、自然言語を読む際に、文章の構造を俯瞰するためによく行われる行動であり、人々はこの戦略をコードを読む際に転用するようでした。

元の論文は 8ページにわたるものですが、その大事なところが短くまとめられています。

 この書籍は、全体的に、多数の学術論文に基づいています。たとえば 8章「よりよい命名を行う方法」では、わずか20ページに7本の有名どころの論文が引用されていて、本文中に引用無しで出てくるものも数本あり、それらの知見をまとめて日本語で読むことができます。なので、プログラム理解についての研究をやりたい人には、歴史的な経緯を知る上で非常に良いスタート地点になると思います。一方、基本が学術研究の話なので、開発者の人が読んで「すぐ実践に使える何か」を得られるような、いわゆる How-to 本ではありません。開発者の人が持つ感覚的なところの分析をまとめているので、そういう要素を言語化をしたい人にとっては気づきが得られる本なのではないかと思います。

 

ペアプログラミングをすると作業に集中できる

2人でパイロットとナビゲーターの役割を分担して1つのタスクに取り組むペアプログラミングですが、その効果は分かっているような、分かっていないような、微妙なところです。ペアプログラミングを実際にやっている人を見かける機会もあったので、効果について何が言われているかを軽く調べてみました。

 この分野の先駆者は(おそらく) Laurie Williams で、The Costs and Benefits of Pair Programming (XP 2001) において、ペアでやると労力は(最初は時間が大幅増になるが、慣れれば)15%増し、テスト通過率は 70-80% → 85% と上昇するので、「労力が2倍になるわけではなく、バグ修正に要する時間を考えればお得」としています。

 このあといくつか実験が報告されていて、Two controlled experiments concerning the comparison of pair programming to peer review (JSS 2005) で、得られる品質と労力については、ペアプログラミングと、1人が作業したあとの peer review に、有意差がないことを報告しています。同著者は "Are Reviews an Alternative to Pair Programming?" (EMSE, 2004) でも、Peer Review が代替になると述べています。

 Hannay らによる The effectiveness of pair programming: A meta-analysis (IST 2009) で、これまでの論文のメタアナリシスが行われて、作業の correctness, duration, effort の3つの観点で分析した結果、

  • 難しいタスクでは、労力は大きくなるが、正確にこなせるようになる(個人でやるよりも困難なタスクに取り組める)

  • 単純なタスクでは、時間短縮になるが、正確さも下がる(作業が雑になる)

という結果を報告しています。前者の効果は、コードの Peer Review では代替できないので、ペアプログラミング特有の効果といえそうです。

 これらの結果と関係していそうなのが、Understanding the impact of Pair Programming on developers attention: A case study on a large industrial experimentation (ICSE 2012) で、開発者が開発作業に集中し、ブラウザやメーラなどの他のツールの使用時間、ツール切り替えの頻度が減ると報告されています。特に作業時間は、論文 Figure 2 に以下のように記載があります:

  • Visual Studio: Soloの場合 34% → Pairの場合 64%
  • Outlook: Solo 21% → Pair 13%
  • Browser: Solo 9% → Pair 3%
  • Word:  Solo 9% → Pair 2%

Pair の場合に Visual Studio の時間が増え、他の時間が減っているのは、ペアになる人が隣にいるので、開発以外の作業に気を取られにくくなっているということのようです。

 ペアプログラミングについて開発者は全体的には良い印象を持っているようだ、というのは  Pair programming: what's in it for me? (ESEM 2008) で出ていて、バグが少なくなる、ペアの人から学べるなどの良い面がある一方で、作業効率やスケジューリング、2人での意見対立が起きると解決が難しいなどの問題が指摘されています。パートナーとうまくいかない問題は Compatibility Issues とも言われていて、Laurie Williams の Examining the compatibility of student pair programmers (AGILE 2006) によれば、学生ペアを組むと 93% ぐらいはうまくいくが、評価(能力)が高めの学生は、低めの学生と組むのは嫌がるなどと書かれています。ただ、ペアの組み方なども研究が進められているようなので、授業のように必ず参加時間が合わせられる状況では、ペアプログラミングは簡単に導入できる工夫となりそうです。

 大学での教育効果については、最近でも研究がいろいろ行われているようで、Psychological Aspects of Pair Programming: A Mixed-methods Experimental Study (EASE 2023) では役割分担が学生の意欲を高める、 The Impact of Pair Programming on the Performance of Slow-Paced Students: A Study on Data Structure Courses (JIOS 2020) では、進度の遅い学生にとって助けが得られる機会になるという話が出ています。また、A Comparison of Solo and Pair Programming in Terms of Flow Experience, Coding Quality, and Coding Achievement (JECR 2020) で、Scratch での話ですが Flow Experience, コード品質の観点で良い影響が出ると報告されています。

 ペアプログラミングを常にやるべきというのは言い過ぎですが、難しいタスクに取り組む場合や、他に誘惑が多くて作業に集中できない人には良い選択肢である、というのが現状の私の理解となります。

 

実際のプログラミングで必要な内容と、授業や教科書の内容を比べた話

授業ではプログラミング言語の全部を教えられるわけではないので、どうしても一部重要だと考えるところをピックアップして教えることになります。それが「実際に世の中で役に立つ」内容なのかどうかを調べようということで、私たちのグループで1つ、比較方法を定義して試してみました。

まず、授業、教科書、そして実際のプログラミングの語彙 (vocabulary) を次のように集合として定義しました。対象は奈良先端大の Python プログラミング演習です。この授業は、大学院生が Python を使ってデータ分析ができるようになることを目標としていたので、「実際に世の中で」というところは、Kaggle におけるデータ分析プログラムが書けるか、と考えました。

  • 授業の語彙:学生に使えるようになってほしいプログラムの言語要素の集合。具体的には、模範解答として教員が作ったプログラムに登場した予約語演算子の集合。
  • 教科書の語彙:授業で使っていた教科書のサンプルプログラムに登場した予約語演算子の集合。
  • 実際に世の中で使われる語彙:KGTorrent というデータセットに収録された Kaggle 向け Python プログラムに登場した予約語演算子の集合。

比較の結果、見えてきたことは以下のようなものです。

  • 教科書はそこそこ広い範囲をカバーしていたが、is や None が登場するサンプルプログラムがなく(文章として説明には登場するが)、授業でも取り扱っていなかった。Kaggle に登場するプログラムでは頻繁に使われているので、授業で取り扱ったほうが良い可能性がある(来年度反映予定)。
  • 教科書では Lambda が登場しておらず、授業では何となく教員が必要そうだと思って追加していた。この判断は、Kaggle での利用頻度からすると、おそらく正しかったと確認できた。
  • Kaggleでは、while文やビット演算子がほとんど使われない。授業としては基礎なので教えたいが、実用性という点では、そこまで重要ではないかもしれない。

この結果を国際会議 CSEE&T 2023 のポスターとして発表しました(採択率 45.5%)。

K. Fukushima, T. Ishio, K. Shimari, K. Matsumoto: Towards Assessment of Practicality of Introductory Programming Course Using Vocabulary of Textbooks, Assignments, and Actual Projects.  Proc. CSEE&T, 2 pages, 2023.

私は都合により現地セッションには参加できませんでしたが、発表では、アイディアはわりと好意的に受け取ってもらえたようです。ドメインごとに必要な知識は違うという点は合意できるものの、特定のドメインに特化することが「授業として」良いのか、たとえば Pythonic な(Pyhthon 固有の)書き方に強く染めることは良くない可能性もあるなど、様々なコメント、有益な情報をいただくとともに、Best Poster Award をいただきました。

個人的には、授業における適切な教科書選びや、授業で教えていない内容を課題で要求してしまうといった授業進行上の問題の防止のような堅実な用途から考えていたのですが、もう少し幅広い展開も今後考えていきたいところです。

 

模擬授業「ソフトウェアの生態系」質疑応答

公立はこだて未来大学オープンキャンパスの模擬授業にお越しいただいた皆様、ありがとうございました。今回の模擬授業では、ソフトウェアの生態系に関する歴史的な話と、最新の研究から得られているいくつかの知見をご紹介しました。

SLIDO を使ってみたところ、授業中にたくさん質問をいただきました。時間内に答えきれなかったもの、授業後に口頭でいただいた質問もありますので、ここに整理しておきます。質問は、ここに掲載する都合上、私が記述を改めているものがありますのでご了承ください。

1. プログラムの構造上バグの修正が不可能であったり、困難であったりする事態が起こることはありますか。    

あります。プログラムが複雑すぎて直し方がわからない、プログラムをハードウェアに組み込んでしまって書き替えられないなどといったことが原因です。一度こうなってしまうと、使い方の工夫でどうにかするしかありません。

2. プログラミングを学ぶ為のおすすめの書籍などはありますか?

教科書は、ターゲット層がけっこう違うので、本屋さんなどで最初のあたりを読んでみて、自分に理解できそうな内容かを確認することをお勧めしています。初心者のために(厳密さは犠牲にしながら)難しい書き方を避けているものや、ある程度プログラミングの知識を持っている人向けの本などがあります。

雑誌などでも4月頃に入門記事が出たりしますので、色々な説明を、何度も読むのも良いと思います。

3. 一部のバグを解決すると、今までうまくいっていた所でバグが起きたり、何かが成り立たなくなって進まなかったりするのですか 。

あります。通称「モグラたたき状態」で、こうなった時点でかなり危険な状態です。こうならないよう、つくる段階で気をつける必要があります。

4. 他の分野などと関連して進められるようなことなどはありますか? 

ソフトウェア関係でいうと、自然言語や教育、チームワークのやり方など、言語や社会的な側面に関連します。情報技術全般に、情報+○○として、今までやってきたことをコンピュータでどう扱っていくか、という組み合わせの研究も多いと思います。

5. ソフトウェア開発にグリッチなどの概念はありますか?

ここでの「グリッチ」は、ゲーム等で裏技的に使われるバグ(あるいは障害)のことでしょうか。ソフトウェア開発の観点では、こういうものがなるべく発生しないようにする、ということと、発生しても大きな問題にならないようにする、というセキュリティ的な考え方はあります。

6. 学生時代に行っていたプログラムのバイトというのはどのようにして知りましたか。当時どれほど技術を持っていましたか。 

サークルの先輩による紹介でした。プログラミング技術としては、仕様書を読んでプログラムを書けていたので、それなりだったと思います。プログラミングの能力だけでなく、書いたプログラムをテストしたり、仕様書の不備を見つけたりといった、多くの知識はアルバイト先で身につけられたと思っています。

7. ゲーム開発のソフトウェアで既存ソフトウェアの利用の例はありますか?

ゲーム自体を扱うときは、「なるべくそのまま動かす」印象があります。また、知り合いの範囲でいうと、最新の環境で最高の性能が出るように、自分で素早く書く技術が求められている印象です。

8. AIなどを利用したバグのチェック・修正する技術はありますか?また、その技術について現在どのような課題がありますか? 

もちろんあります。しかし、修正内容自体が正しいかどうかを人間が理解できるとは限らないですし、AI が間違った修正例を出してくることもあるので、しっかり確認する作業が必要で、まだまだ改善の余地があります。

9. 既存ソフトウェアの利用について著作権法にあたる場合はありますか。

はい、あります。ソフトウェアの利用は勝手にやっていいわけではなく、ルールを守って行う必要があります。

10. 今からできる準備とかやっといた方がいいこととかありますか? 

高校3年生の場合は、数学、英語をしっかり勉強してほしいところです。数学は理論で使いますし、英語は、最新の文章を読んだり、書いたり、海外の人とコミュニケーションを取ったりと、勉強したらしたぶんだけ役立つことがあります。

あとはプログラミング言語を使ってみること、また、コンピュータで何ができるのか、コンピュータに親しんでおくと良いと思います。

11. 未来大で学ぶなら、今のうちからプログラミングを学ぶべきでしょうか。

必須ではありませんが、この分野に飛び込んでみたいと思っているなら、やってみてはどうでしょうか。

プログラミングを勉強するためだけに勉強していると長続きしないので、何かプログラムを自分なりに作ってみるのが良いと思います。

12. 自分でプログラムを書くとき、気をつけていることは何ですか。

自分が作ってみようと思ったソフトウェアの核となるところだけ、とにかく早く「動く」状態に持って行くことです。他人に見せたりして話をすると、モチベーションが上がってきます。

プログラムの構造は気をつけているつもりですが、それでもなかなかうまくいかず、後で直すことも多いです。

13. 最近AIによるコーティングが話題ですが、それによりプログラマーやエンジニアの仕事内容はどのように変わっていくと思いますか。

「よくあるプログラム」は AI が書いてくれるようになると、そのぶん、新しいプログラムを書いたり、創造的な仕事になると期待しています。コンピュータに何をさせたいかは人間が決めることなので、システム全体の動作の仕組みを考える人としての側面が強くなりそうに思います。

14. 昨日初めてGitHubを使ったのですが、プログラムを作っていくうえでGitHubを使うことはありますか?

私は愛用しています。たくさんの機能がありますが、とりあえず自分のプログラムの保管場所と思うだけでも十分に便利です。

15. ソフトウェア開発におけるおすすめのフレームワークIDE はありますか?

作りたいソフトウェアの形、使うプログラミング言語によって、ここはかなり違ってきますので、フレームワークについてはお答えできません。

開発環境については、無料で使える範囲で十分高機能なので、お金をかけない範囲で試してみると良いと思います。書籍で、使い方を説明しているものとセットで選ぶのもありです。

16. この分野の魅力だと思うところは何ですか?

プログラマ、ソフトウェア開発者が持つ共通の価値観や仲間意識みたいなものが感じられることがあるのは面白いと思っています。以前指導していた学生が、海外の人とやりとりをしていたとき「英語では通じなかったけどプログラムを書いたら通じた」ということがあり、通じるものがあるんだなと感心したことがあります。

(質問ここまで)

来場いただいた皆様、質問いただいた皆様、ありがとうございました。模擬講義の内容とこの質疑が、高校生の皆さんが将来を考える際のお役に立てば幸いです。

 

論文の第1章の書き方

論文の第1章を書くのは難しい、そもそも何から書いていいか分からない、という話をよく聞きます。私はここ最近、学生の国際会議(ワークショップ)投稿を連続で指導する機会があり、だいぶ言語化できたところがあるので、簡単にまとめてみることにしました。ここに書く話は、ソフトウェア工学の論文で、何か新しい手法を提案するタイプの論文を念頭に置いたものです。調査研究型の論文には、それにふさわしい別の型があると思いますので、ご注意ください。

 論文の序章の役割は、一言で言うと「なぜその研究をしたのか」を理解してもらうことにあります。タイトルを見て、そのキーワードに心を惹かれたが、研究内容はまったく知らない読者に対して、取り組んだ研究の重要性や特徴を伝えることを目指します。その目的を果たすために、具体的な文章として何を書くべきか。私が基本構成として挙げるのは、以下の4点です。

  1. 研究の対象。ソフトウェア開発のどのような工程、活動を研究対象とするのか。
  2. 研究が解決する課題。その工程において、どのような問題があり、それを解決することはなぜ重要か。
  3. 既存研究の限界。その課題を解決するためには、既知の技術を単に適用するだけでは足りず、研究が必要であること。
  4. 研究の新規性。この研究ではどのような方法で問題を解決するのか。既存研究ではできなかった課題を、なぜこの研究成果だと解決できるのか。

 まず最初に、研究対象としたいソフトウェア開発の工程や活動の紹介から話を始めます。論文を読み始めた時点では、読者は研究についてタイトル以外の何も知りません。そこで、この研究が何に興味を持っているのかを説明します。たとえば、私たちの研究室で VISSOFT 2022 で発表した NIER Track 論文の書き出しは、日本語に直すと以下のような一文から始まっています。

オープンソースソフトウェアのリポジトリは、よくフォークされている。

これだけでは読者は間違いなく「本当?」「なぜ?」「どれぐらい?」などの疑問を持つので、後ろに具体的な証拠などの引用を伴う文章を書き足して、「フォーク」が研究対象であることを紹介して、1段落目を終わります。ここでは、ソフトウェア工学の国際会議の論文を読む人なら、オープンソースソフトウェア、リポジトリという概念は既知であることを仮定しています。

 2つめの段落として、研究対象とした工程や活動に潜んだ研究課題を提示します。先の例文の場合、フォークという活動の何が問題なのかを続ける必要があります。

フォークは新機能の導入やバグ修正に便利だが、有益な変更の情報が分散してしまう。

これだけだと、それがどれぐらい重要な問題なのかが伝わりません。なので、参考文献を引用しながら状況や事例を紹介します。以下は事例紹介の一例です。

たとえば、フォークリポジトリ間で共有されるバグ修正が、本家のリポジトリには入っていないという事例が報告されている[Stănciulescu, ICSME2015]。

ここまでで、読者が課題に納得したとします。しかし、技術情報に明るい読者であれば、「この問題は○○という既存の手法(ツール)が対応しているのでは?」と疑問を抱くことがあります。そこで3段落目では、既存研究の限界、つまり、この問題は解決されていないことを説明します。なるべく最先端の論文や、実際に利用可能な最新ツール群を持ち出して、「○○という手法で××まではできるが、この問題を解決してはいない」と述べます。以下、そのような文章の一例です(実際の論文では、ここからさらに複数の関連技術を引用して、1段落分説明を続けています)。

フォークを可視化する技術は存在するが、フォーク集合の中でソースコードの変更を比較することは難しい。たとえば、GitHub Network Graph は、GitHub上のフォーク群をすべて可視化しようとするため、多数のフォークに対しては機能しない[Zhou et al., ICSE2018]。

 4段落目で言うことは、未解決の問題を本研究では解決する、ということです。ただし、言うのは単純ですが、今まで解決されていなかった問題を、なぜ本研究では解決できるのか、理由が分からないと説得力がありません。そのため、この研究で提案する手法の特徴と、導入する工夫点を合わせて述べます。

本研究では、フォークリポジトリでの開発活動の概要を可視化する手法を提案し、有用なフォークを選べるようにする。自動的に少数のフォークを選択するため、本研究では各フォークに固有のコミットの数を使用する。バグ修正などを行ったフォークは、他のフォークには含まれない固有のコミットを含んでいる可能性が高いためである。

 導入した工夫、これがいわゆる「新規性」で、何がこれまでの研究と違うのかを明示的に述べることで、研究の位置づけが完了します。提案手法の核となるアイディア(上記の例では「固有のコミット」)を示したことで、あとは、そのアイディアが具体的にどのように使われるかを提案手法の説明の章で、その効果を評価実験等の章で、それぞれ読者に確認してもらえばよいことになります。

 5段落目以降に、提案手法がツールの形で提供されることや、評価実験の方法などを述べると、それがきちんと実現されていることまで確認できるので読みやすくはなります。一方で、これらは研究を行った理由ではないので、短い論文では割愛しても特に影響ありません。

 4段落目までの1章の内容は、論文として書こうとしている研究が始まるまでに行われている既存研究の話が占めています。提案手法の詳細を詰めていくのと並行して、これまでの論文をよく調査し、自分の研究と類似した問題を扱っている論文の研究動機や、問題を報告している調査研究の結論部分などを読み込んで、自分の研究が誰のためのものか、何が既存研究と違うのかをよく考えておく必要があります。今回は1つの型として書きましたが、歴史のある技術分野なら、「○○という技術がこれまで研究されてきた、しかし……」というように、いきなり課題意識から入ることもできますし、逆に1つの問題事例を詳しく説明して、一見簡単そうな課題が難しいことを力説する論文もあります。有名な技術、そうでない技術など、状況によっても書き方は変わってきますので、幅広く論文を読んで、色々な書き方があることを知ると、それだけ選択肢が広がります。

 研究によっては、個人の興味や思いつきから始まることもよくありますが、論文の1章は新商品(提案手法)の宣伝文句のようなものです。実際の発端や、裏に隠れた試行錯誤のことは隠して、誰のどんな状況で役に立つ、どこが新しい技術なのかを首尾一貫して説明する、読みやすい文章を書いてください。

 

コードレビューはコーディングスタイルも整えている

タイトル通りですが、そんな調査をやってみた結果を5月のリポジトリマイニングの国際会議 (MSR) で発表しました。

ieeexplore.ieee.org

論文の内容をまとめると、以下の通りです。

  • 投稿されたパッチ(Pull Request) の最初の版と、最後の版で、n-gram ベースで見て、対象プロジェクトのコード「らしさ」を比べた。
  • コードレビューの前と後では、後のほうが、対象プロジェクト「らしさ」は上がっているので、レビューで何かしらコードが整えられている。
  • 受理されたパッチと、拒否されたパッチでは、前者のほうが対象プロジェクト「らしさ」が高い。

「コーディングスタイル」というと、ぼやっとした印象がありますが、そういうのも数値化できるのか?、ということを実験的に試してみた論文となっています。結果として、コードレビューはやっぱり機能しているんだなというのを数値で確認できました。スタイルを整えるのもレビューのうちかもしれませんが、レビューでそういう作業をするぐらいなら、パッチ投稿前に、ちゃんとそのプロジェクトのスタイルに合わせてコードを整えておくのも、レビュアーの手間が減るので大事と言えそうです。また、これは相関関係であって因果関係ではないのですが、対象プロジェクトのコードの書き方を守っているほうが、パッチが受け入れられやすかった可能性もあります。

 

静的解析ツールはデフォルト設定で使うと見逃しが多くもったいない

 ソフトウェア工学研究室D2の上田君がソフトウェア解析・進化に関する国際会議 SANER 2021 で、「Automatically Customizing Static Analysis Tools to Coding Rules Really Followed by Developers」(開発者が実際に従っているコーディングルールに合わせた静的解析ツールの自動設定)という論文を発表しました。以下が SANER チャンネルに公開されている発表動画です。

www.youtube.com

論文のコンセプトは単純で、以下の通りです。

  • コーディングエラーなどをチェックしてくれる ESLint のような静的解析ツールは、多数のルールを持っているが、デフォルトではそのごく一部しか有効でない。
  • そこで、開発者の現在のコードを見て、「現在守っているルール」を自動で有効に、守っていないルールを無効にするように、静的解析ツールの設定ファイルを自動で作ってくれるツールを作ってみた。
  • 開発者が、あるバージョンの時点で守っているルールを有効にすると、その後のバージョンで(実際には静的解析ツールなしで)修正されている警告を、かなり検知できるようになる。
  • 開発者が、あるバージョンの時点で守っていないルールを無効にすると、その後のバージョンで、やはり放置されたままの警告を、かなり出力から減らせるようになる。

 実際に「修正されている警告」は警告数の増減から推定したものなので、現実と多少の乖離がある可能性はありますので、本当の有効性は少し割り引いてみる必要があります。それでも、静的解析ツールのデフォルト設定では無効なルールが多く、ときどき違反して修正していると思われる問題を検知できるルールがあるのに使われていない勿体ない状態になっている、という点は示せたと考えています。

 この論文はショートペーパーでしたが、他のフルペーパー論文などに劣らず聴衆の興味を引いたようで、

  • ディレクトリごとにルールが違う場合は?
  • 特定の人がルールを守らない場合もあるのでは?
  • 警告を見せなくしてしまうことで、バグなどにつながる可能性はないか?

など、考慮すべき点について、多くの意見をもらいました。また、この論文では ESLint のみを対象にしているので、実験対象の拡張も必要です。論文投稿したときの査読者の1人から「こういう機能を実際に各ツールが標準で備えてもいいのでは」とアイディアに賛同する意見をもらったので、本当に静的解析ツールが備えるべき一機能としておすすめできるかどうかまで調べるところが、この研究のゴールとなりそうです。