こんにちは。いわもとです。

現在は、WebサービスのQAやリグレッションテストの自動化を日々行っています!

本記事は3/9,10に開催された、JaSST’23Tokyoに初めてオンライン参加した時のレポートです。 毎年参加レポートを読んだりはしていましたが「やっぱり実際の講演も聞いてみたい!」と思い、初参加しました。

その中で今回は『自社の眠っている技術を論文にして世の中に広めよう! 論文の書き方講座』についてレポートしていきたいと思います。

JaSSTとは

JaSSTとは「ソフトウェアテストおよびソフトウェア品質に関心のある方が深い学びを得ることを目指して、 ソフトウェアテスト分野の幅広い情報と、参加者同士の交流や議論ができる場を提供」するため、特定非営利活動法人ソフトウェアテスト技術振興協会 (ASTER)が主催する日本最大級のソフトウェアテストのシンポジウムになります。

JaSST公式ページ

JaSST’23 Tokyoのテーマは「相互理解で広がる世界」ということで、関連するセッションが多数催されました。

JaSST’23Tokyo公式ページ

自社の眠っている技術を論文にして世の中に広めよう! 論文の書き方講座

この講演は、喜多 義弘さん(長崎県立大学)が登壇されました。

論文というと「お堅い・取っつきにくい」というイメージがあり、それだけで遠ざけてしまう人も多い。また、論文を書いてみたいと思っても書き方がよくわからない人も多い。

そんな人を対象に「そもそもなぜ論文を書くのか?」「実際に書く手順」をとても分かりやすく教えていただきました。

きっかけ

まずは、なぜ今回のセッションを受けてみようと思ったかをお話ししようと思います。

私は論文を読むことに苦手意識があり、難しそうで敬遠してきました。(まさに今回の対象!)

ただ、だからこそ実際に執筆している方のお話を聞いたら何かいいきっかけがあるんじゃないか?論文を書く以外にも何か学びがあるのではないか?と思い参加しました。

なぜ論文を書くのか?

自分たちが伝えたいこと(主張)を書く!」そのために論文を書くとのお話でした。

伝えたいこと、というのは以下のようなことを指します。

  • 【研究目的】なぜこんな研究をしたのか?
    • 自分たちが現状どんなことに困っていて何を解決したいのか
  • 【実験概要】どうやって研究したのか?
    • その研究を進める上でどんな困難や課題があったのか
  • 【結果と考察】研究してどうなったのか?
    • 研究してどのような成果が出たのか。解決はできたのか。
      • 解決できた →残された課題はあるのか?
      • 解決できなかった →原因や新たな課題は何なのか?

「課題解決していなかったとしても論文として成立する」というのは目から鱗でした。 ここで、論文と事例発表の差もお話しされていて「なるほど!」と思ったので紹介します。

「事例発表」(JaSSTの各セッションもここの位置づけですね)

事例発表は「成功したこと」「やって良かったこと」しか書かれない。

事例発表するときにこんなことをして失敗しました…。ということはまずない。

確かに「失敗を元に新たな取り組みを実践し、いい結果が得られた」というのは聞きますが、「失敗して新たな課題が見つかりました」で終わってしまう事例発表は、ほぼない印象です。

「論文」

上にも書いた通り、自分たちが伝えたいことを書くので、「解決した」「解決してない」は関係ない。ただし、解決してない場合には、その原因解決するために別の解決せねばならない事柄などの理由をしっかりと書くことが大事。解決していなかったとしてもその論文を読むことで「得られるもの」がなければならない。

論文を書くまでの手順

手順の前に、論文(研究)に必要な要素のお話がありました。

  • 「新規性」:他で提示されたことがない、新しい知見か?
  • 「有用性」:大多数の者にとって役に立つ知見か?
  • 「信頼性」:提示されている知見が信頼できるものか?

💡 「新規性」と「有用性」の違い 「新規性」:論文のテーマに関連するキーワードを元に参考文献を集めた結果、他の文献でカバーできない部分や行われていない研究のこと。 「有用性」:他文献で解決されていない課題を解決したり、従来の結果と比較して優れていることを示す研究のこと。

①論文のテーマを決める

まずはテーマ決めです。テーマで大事なことは「自分たちが最も関心を持つこと」をテーマにすることが大事で、この時にはまだフワフワしたイメージでも構わないとのことでした。

確かに関心が高ければ高いほど、解決するためにモチベーションを高い状態で続けていくことができますし、途中で飽きてしまうということはなさそうだなと納得感がありました。

テーマに関連する文献(参考文献)をあつめる

ここが超重要ポイントです。

決定直後のテーマはまだフワフワとしているので、研究テーマに関連するキーワードを元に参考文献(直近5年くらいがベスト)を集めて外堀を埋め、自分たちが取り組むことを絞り込んでいきます。

絞り込んでいく中で、「新規性」に取り組むのか、「有用性」に取り組むのかの方向性を決めていきます。

ちなみに、**参考文献が多く色々な視野で書かれていると「読みたい(面白い)論文」**になるのだそうです。とはいえ、多ければいいというものではなく、内容が重複していたり、テーマからかけ離れているものはあまり意味がないので省きます。

逆に参考文献が少なすぎると、他に文献は本当にないの?調べてないだけなのでは?都合のいいことだけ集めたんじゃないの?という印象を与えてしまうのだそうです。

この辺りは我々が普段行っているテストベース集めに少し近いなと思いました。テストベースが不十分だとテスト分析やテスト設計で抜け漏れがあったり、その影響で後工程で手戻りが発生してしまうということは私も経験しました。

③自分たちの主張をまとめる

取り組むものが決まったら自分たちの主張を「1行(1文)でいえるようにシンプルに」まとめます。

論文を書く際、書いているうちにどんどん脇道にそれてしまったり、論点がよくわからなくなってしまうことを防ぐためにもシンプルにまとめることが大事とのことでした。

④論文を書く

主張がまとまり、研究結果が出たら論文を書いていきます。

その中で特に学びになったのは、

「論文を書く上で大事なことは、シンプル イズ ベスト!

たとえば

  • 難しい言葉は使わない
  • 不要な言い回しはしない
  • 「とても」「極めて」「非常に」など、程度を表す言葉は使わない
  • 論文内で背景の深堀りや用語の説明を行うことで、読む人の目線に合わせる
  • 「一般的」「普通は」「よく知られている」等、主観的な表現や判断をしない

そして最も大切なのは「自分たちの主張がその論文の読者へ正確に伝わるか」つまり、読者ファーストで論文を書く。

まとめ

以上、『**自社の眠っている技術を論文にして世の中に広めよう! 論文の書き方講座』**を紹介させていただきました。

論文を書く上で大事なことは、日々の業務で発生する「テスト設計書」や「テスト報告書」を書く時にも同じように大事にしなければならないなと感じました。

ステークホルダー間で認識合わせをするとき、全員に伝わる言葉や理解できる内容でないと認識合わせの意味がないですし、すれ違って余計な時間がかかってしまうことになります。

今回の講演は、論文をほとんど読んだことのない私でも順序だててとても分かりやすく、今回の講演を聞いて、論文の概要部分を読んで内容に興味を惹かれたら本文も頑張って読んでみようかと意識が少し変わりました!

以上、最後までご覧頂き、ありがとうございました。

SHARE

  • facebook
  • twitter

SQRIPTER

AGEST Engineers

AGEST

記事一覧

AGESTのエンジニアが情報発信してます!

株式会社AGEST

Sqriptsはシステム開発における品質(Quality)を中心に、エンジニアが”理解しやすい”Scriptに変換して情報発信するメディアです

  • 新規登録/ログイン
  • 株式会社AGEST