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

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

論文の第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人から「こういう機能を実際に各ツールが標準で備えてもいいのでは」とアイディアに賛同する意見をもらったので、本当に静的解析ツールが備えるべき一機能としておすすめできるかどうかまで調べるところが、この研究のゴールとなりそうです。

 

習熟度の高いプログラマは、瞬間的にプログラムの内容を把握する

 ソフトウェア工学研究室の幾谷吉晴さんがプログラム理解に関する実験結果を論文として発表しました。論文自体は英語ですが、内容の概略を日本語プレスリリースとして出してもらいました。

www.naist.jp 実験は、1画面に収まる程度の長さの Javaソースコードを10秒間読んで、それが何をしているか(数学のアルゴリズムか、文字列処理か、など)おおよその当たりを付けるという作業を、習熟度= AtCoder rate が異なる30人のプログラマたちに実施してもらうというものです。プログラマたちの脳活動をfMRIを使って計測した結果、レートの高い人と低い人では、脳の異なる領域が活動していることが確認されました。

 プレスリリースではレートと正解率に相関があったとだけ書かれていますが、レートが高い人の中には、4択問題として出された分類問題を90%以上正解するような人も目立っていました。競技プログラミングの訓練を積んだプログラマは、画面に映ったプログラムを素早く、しかも正確に認識する能力に長けている、ということになります。計測方法の都合上、ファイルの選択や画面のスクロールなどを伴う一般的なプログラム読解の状況とはだいぶ離れてしまう実験ではありますが、熟練者が、プログラムを眺めただけでその内容を素早く把握できるのは、それまでの経験の蓄積によるものだといえそうです。

 

ソフトウェア開発者は徹夜してはいけない

睡眠は大切とよく言われますが、睡眠不足が開発者に与える影響をまじめに調べた面白い論文が、ソフトウェア工学のトップ論文誌 IEEE Transactions on Software Engineering に掲載されていました。ソフトウェア工学研究室助教の Raula 先生から教えてもらいました。

Need for Sleep: The Impact of a Night of Sleep Deprivation on Novice Developers’ Performance - IEEE Journals & Magazine

 この論文での被験者はイタリアの大学生 45人。Test-First 開発でプログラムを書かせるタスクを行ってもらっています。23人には実験前日に睡眠を控えてもらい、平均で直近20時間程度は寝てない状態になっています。対照群は、前日に平均で6.5時間、通常通り寝た人です。

 これらの人たちに、90分でのプログラミングタスクを実行し、所定の機能を実装してもらい、その作業の成果物や作業自体の質を比較します。評価指標は以下の3つです。

  1. Percentage of acceptance asserts passed (PAAP)、自動受け入れテストにおける全 assert 文のうち、通過できた assert 文の割合。これを開発者が書いたコードの機能の正確さ(functional correctness)として計測します。
  2. #episodes、作業エピソードの数。テスト駆動開発単体テスト作成をして、コードを書いてからテストを実行して pass することを確認する)やテストを最後に実行する開発(コードを書いてからテストを作って pass することを確認する)などの一連の作業順序を、時間内に何回こなしたか、作業量を計測します。
  3. %conformance、指示の遵守率として、開発者が実行した全エピソードのうちテスト駆動開発の割合を評価します。

 PAAP の値の分布は以下の通りです。左端が通常通り睡眠した人々、右端が睡眠不足の23人です。中央が23人のうち本当に睡眠不足と思われる15人を PVT で抽出したものとなっています。

f:id:ishiotakashi:20200730131710p:plain

Fig. 4(a) in Fucci et al. Need for Sleep: The Impact of a Night of Sleep Deprivation on Novice Developers’ Performance, IEEE TSE 2020

 睡眠不足のグループのほうが下側に分布が移動していることが分かります。睡眠不足の23人は、睡眠をとった人に比べてテスト通過率がおよそ半分(平均値 28.57% → 14.36%、中央値 38.46% → 15.38%、第3四分位点 38.46% → 15.38%、最大値は 53.85% で変わらず)になっていました(論文 Table 6)。Mann-Whitney の U 検定で p 値が 5% を下回り、有意差があるという結果になっています。

 ほかの数値についての図は省略しますが、睡眠不足の人は #episodes もおよそ半分に低下しています(平均値 7.5 → 4.2、中央値 9 → 4、最大値 16 → 13)。Assert が通っていないのは、そもそもこなせた作業量自体が下がっていたせいである可能性もあります。さらに %conformance も低下しています(平均値 45% → 25%、中央値 50% → 0%、第3四分位点 73 → 55、最大値は 100% で変わらず)ので、作業手順も守れなくなっていたようです。これらも Mann-Whitney の U 検定で有意差が出ています。

 さらに追加分析として、睡眠不足の人たちは、構文誤りの修正作業が54%増加したとも書かれています。まとめると、睡眠不足だとコードを書くとき構文誤りのような単純なミスも多くなるし、書いてもちゃんと動かないし作業量も減るし手順も守れないと、いいことがまったくない結果となっています。

 結論としては、論文のタイトル通り、開発者はきちんと寝ることが大事であるということになります。この結果は、被験者実験を考えている研究者にとって重要な話で、被験者の睡眠状況の差による影響のほうが、下手をすると開発支援技術などの効果を上回る可能性があります。何かの被験者実験をするときは、被験者には前日にしっかり寝ておいてもらうよう伝えておく必要があるようです。

 

Python は C よりもプログラミング教育に適しているかもしれない

プログラミング言語を C から Python に変えた効果を報告した論文

 プログラミング言語として何を使うと良いのかは重要な問題です。生のコンピュータの挙動が直接見えるC言語と、人気の高い Python ではどちらがよいか、実際にプログラミングの授業で使う言語を切り替えてみた結果を分析した論文 「A Controlled Experiment on Python vs C for an Introductory Programming Course: Students’ Outcomes」 が2018年の ACM Transactions on Computer Education に掲載されていました。

 論文中 Table 1 に授業内容が書いてありますが、全30回の授業で、代入、数式、入出力、条件分岐やループ、配列(Pythonではリスト)、ソーティングなどはまったく同じように教えています。C言語ではポインタとメモリアクセスを扱っていたところが、Pythonでは正規表現と辞書型に置き換わっていますが、全体からみると30回中3回程度なので、大きな内容の変更はありません。

 論文中 Table 2 に詳しい数字と、Table 3 に統計的な有意差の分析があります。それらをまとめると結果は以下の通りです。

  • 途中でドロップアウトする学生の数は変わらない。
  • 合格点(10段階評価で5点)に足りなかった学生 (Fail) の数は、Python のほうが少ないが、統計的に有意な差ではない。
  • 中間試験の平均成績は10段階評価で C言語 6.41 に対してPython 7.08 で有意に上がっている。
  • 期末試験の成績も同様で、C言語 6.72 に対して Python は 7.55 と有意に上がっている。
  • 合格者が提出した宿題(プログラム)のうち、自動テストを通過したものの割合 (Proportion of completed labs) は C言語 76.0% に対して Python 82.3% で有意に上がっている。
  • 合格者が提出した宿題のうち、自動テストを通過するまでに提出した平均回数は C言語 2.91 に対して Pyhon 2.46 で有意に下がっている。

 以上の結果から、Pythonを使うほうがC言語よりも、学生への教育効果が高いのではないかと結論づけられています。毎年、受講している学生の数や試験問題の内容などは異なるので、偶然内容が簡単になってしまった可能性などのリスクはあります(そうでない証拠は出せないと論文中でも記述があります)が、Python を使ったほうが実際に学生は誤りの少ないプログラムを記述でき、学習効果が上がったと考えたほうが自然です。

 開発支援ツールの導入などの被験者実験では、通常、このような大きな違いが明確に出ることは少ないので、言語の切り替えでここまで明確な違いが出ている点は非常に驚きでした。

プログラミング言語の構文の違いは初心者にとって重要である

 Python のどこが良いのか?というのはこの論文単独で明確になっているわけではありませんが、C言語系のプログラムの構文が RubyPython よりも初心者にとっては難しいという指摘が「An Empirical Investigation into Programming Language Syntax」という2013年の論文で出されています。

 こちらの論文では、予約語としてすべて記号を使う人為的な言語 Randomo を導入し、複数の見本プログラム(内容に関する説明なし)を見ながらの一連のプログラミング作業(たとえば変数 x を定義して 175.3 を代入せよ、など)の正確さを評価しています。

 プログラムの見本は、たとえば Javaであれば

public static void main(String[] args) {

    double  x = z(1, 100, 3);

}

となるところが、PythonRuby ならば

x = z(1, 100, 3)

となります。Randomo は、構文自体はC言語系を採用していて、

^ Main {

  ~ x \ z (1, 100, 3)

}

となります(論文 Fig.3 より。~ が変数宣言、\ が代入です)。

 Ruby, Python, Quorum, Perl, Java, Randomo という6つの言語で学生がどのぐらい正しく作業できるかを調べた結果(論文中 Table XXIII)、

  • Ruby, Python, Quorum の3つは Randomo と有意差あり。
  • PerlJava は Randomo と有意差がない。
  • RubyJava とも有意差あり。

という結果になりました。Randomo では、記号の意味も通常とは異なっているにもかかわらず、学生たちは JavaPerl と違わない程度に作業をこなせていたことから、予約語の選び方よりも、初心者にとっては構文の違いが重要であると結論付けています。RubyPython の構文は初心者に優しい、というわけです。

 論文では、プログラミングのどこで間違うのか、構文エラーなしに正しく書けた確率を Token Accuracy Map という名前で可視化して分析しています。Ruby は正確さは一番高かったものの、 for 文における「in」や、数値の範囲を表す「..」の記述を半分以上の人が間違っていると報告されています(論文中 Fig.6)。また、Java における変数の型宣言は、既存研究でプログラマの作業に良い効果があると示されているのに、初心者には優しくない可能性があると指摘されています。

 プログラミング言語が変わっても概念は共通というふうに考えていましたが、この論文の結果からすると、初心者にとって分かるような教え方、どこに重点を置くべきかは、言語によって変えていく必要もあるのかもしれません。

 

文献管理ソフトウェアを使いましょう

文献管理ソフトウェアが必要な理由

研究成果を論文にまとめるとき、研究の動機の説明や、既存技術との比較を行うために、参考文献の引用が不可欠です。ソフトウェア工学研究室で修士論文を書く場合、少ない人で10件、多い人だと40件ぐらい、文献の引用を行うことになります。

 参考文献は、研究を進めるにつれて増えていきます。指導教員が知っている最新の研究や、研究室の先輩の過去の発表を最初の手がかりとして、それらの研究に至るまでの過去の経緯を調べたり、国際会議で新しく発表された論文や、検索して見つけた関連技術の情報などを集めていくことになります。

 ここで重要となるのが、参考文献の既読管理です。ソフトウェア工学界隈に限らないのかもしれませんが、最近は論文誌への投稿と同時に投稿版原稿を公開したり、国際会議の開催前にプレプリントとして採録済み原稿を配布する人が多くなっています。そうすると、論文を検索エンジンで見つけてから1年後に実際の論文誌の出版が行われ、その内容をさらに国際会議での発表(Journal-First 発表と呼ばれます)として再発見する、といったことが起こります。自分が読んだものをきちんと記録していないと、論文を読んでいる途中でようやく過去に読んだ論文と同じであることに気づくといった時間の無駄が発生します。また、文献を引用するときになって、実際の記述がどうだったかを再確認したくなることもしばしばありますから、自分が確認した PDF をきちんと保管していなければ、論文誌などの Web サイトからダウンロードしてくるところからやり直しとなってしまいます。

 文献管理ソフトウェアは、自分が集めた論文の PDF と文献引用のための書誌情報を管理し、上記のような作業の負荷を軽減してくれるツールです。本格的に論文を読み進める必要があると感じたら、ぜひ使ってほしいツールでもあります。世の中には複数の文献管理ソフトウェアがありますが、学生が修士論文で集める程度の利用規模であれば、無償で使えるものも多くあります。

おすすめは Zotero と Mendeley

 ツールの利用には、かなり好みが入りますが、筆者は Zotero を使っています。他に勧められるものとしては Mendeley を挙げます。これら2つのソフトウェア、Windows 版での話ですが、共通してできることは以下の通りです。

  • Web ブラウザ用のプラグインを使うと、ACMIEEE などの Digital Library を開いた状態から、直接 PDF と引用のための情報をデータベースに取り込めます。
  • 文献の出自(DOIなど)が分かる PDF をドラッグ&ドロップで放り込んでも、書誌情報を自動で探して取り込んでくれます。
  • 取り込んだ文献をダブルクリックすれば PDF を開くことができます。
  • 取り込んだ文献を選択して「BibTeX としてコピー」といった名前の操作をメニューから選ぶだけで、引用のための文献情報を取り出すことができます。
  • PDF などのデータをクラウドサーバ上に保管し、PC間で同期してくれます(DropboxEvernote などと同様です)。

 これらの機能だけで文献の PDF をいつでも参照できるようになりますし、引用するときに必要な BibTeX も簡単に取り出せるようになります。Zotero には、これに加えて、以下のような便利機能があります。

  • 1つの文献情報に、複数のファイルをドラッグ&ドロップで簡単に関連付けられます。たとえば発表スライドを一緒に保存しておけます。
  • ファイルの関連付けと同じ仕組みで、テキストメモを論文に付けることができます。このメモは、 文献情報(BibTeX 形式)の一部としていつでもツール外に取り出すことができます。
  • 文献に子要素としてテキストメモやファイルがぶらさがっているので、それらをドラッグ&ドロップだけで別の文献情報に移動できます。そのため、たとえばプレプリントに対応する出版された版を発見したときに、論文のテキストメモだけを移動して付け替えるといった編集操作が容易です。
  • ドラッグ&ドロップで PDF を簡単にファイルとして取り出せます。

 研究室では Slack で参考文献の PDF ファイルをやり取りすることが多いため、筆者の場合は、このドラッグ&ドロップでの操作が非常に便利であると感じます。Mendeley は、どちらかというとファイルを取り込んだら Mendeley 利用者間でのみ共有することを想定しているようで、ファイルの取り出しにはエクスポート機能をわざわざ呼びだす必要がありました。

 筆者の場合、Mendeley を使い始めてそれほど時間が経つ前に Zotero を見つけてしまったので使い込むには至りませんでしたが、Mendeley にも特有の強力な機能があります。

  • PDF を全文検索することが可能です。キーワード列を入れると、各 PDF ファイルのどこにマッチしたのか、その文章の内容まで論文一覧画面に一緒に表示してくれるます。これが、蓄えた文献の中から必要なものを探すときだけでなく、英語で論文を書いているときの文例の確認にも使えます(Zotero では書誌情報に書かれた Abstract やテキストメモの検索まではできますが、PDF 内の本文は検索できません)。
  • PDF 内部に注釈を簡単に書き込むことができるので、後から論文を読み直すときに注目すべき場所などにマークをしておくことができます(この注釈は検索の対象外という制限はありますが)。

 Zotero と Mendeley を比べてどちらが良いかというと、どの機能を重視するかによります。また、機能的な違いに加えて、ツールのユーザインタフェースにもかなりの違いがあります。2つのソフトウェアは1つのPCに共存できるので、いくつか手持ちの PDF ファイルをこれら2つに実際に登録してみて、その挙動を確認してみると良いのではないかと思います。個人的には、Zotero のほうが、同期機能でどこに何が保存されるか、データのバックアップをどのように行えばよいかなど、システムとしての挙動が把握しやすいという印象ですが、そういうところまで含めて好みがあるので、自分の判断でしっかり選んでみてください。