A Systematic Literature Review of Software Engineering Research on Jupyter Notebook

arXiv:2504.16180（2025） · 論文 · siddik2025review

📅 この論文を見た日

初回 2026-06-09 ／ 最終 2026-06-10 ／ 計 6 回更新

少 多

AI解説

arXiv 版（全文ページ）: https://arxiv.org/abs/2504.16180 情報源: arXiv 現行版の全文（PDF・97頁）を精読して確認。一次研究199本・11トピック（最多=計算環境管理42／コード再利用・来歴41／ドキュメント22）・公開データセット22・CHI/ICSE 等は本文で確認済み。※ 初版（v1）は146本だったが現行版は199本で、本ノートは現行版に合わせている。

一言で

Jupyter ノートブックを対象にしたソフトウェア工学（SE）研究を体系的に棚卸しした系統的文献レビュー（SLR）。5つの主要 DB（IEEE Xplore / ACM DL / Elsevier / Springer / DBLP）から 2025年9月までの 199本の一次研究を選び、「どれくらい研究されてきたか（RQ1）」「どんなトピックか（RQ2）」を分析。研究を 11のトピック カテゴリに整理し、計算環境・ワークフロー管理（42本）／コード再利用・来歴（41本）／ドキュメンテーション（22本）／データセット（22本）が大きい一方、テスト・リファクタリング・ドキュメント生成のツール研究が手薄な空白だと指摘する。会場は意外にも SE よりも HCI（CHI 20本）が中心。

背景・問題

ノートブックの SE 研究はこの数年で急増したが、全体像が散らばっていて把握しにくい。どのトピックがよく研究され、どこが空白なのか、どの会場・どの組織が牽引しているのか——これらが体系立てて整理されていない。問題は「ノートブック×SE 研究の地図がない」こと。新規参入者も既存研究者も、次に何を研究すべきか／どこに穴があるかを判断しにくい。本研究はその地図を SLR の方法論で作る。

提案手法（調査の設計＝やったこと）

標準的な SLR プロトコルに沿う。

  1. 検索：IEEE Xplore・ACM DL・Elsevier ScienceDirect・Springer Nature・DBLP を対象に、2025年9月までの文献を収集。
  2. 選別：包含・除外基準でふるいにかけ、199本の一次研究（primary studies）を確定。選別の信頼性として評価者間一致 Cohen’s Kappa = 0.73（一次段階）/ 0.97（二次段階）を報告。
  3. 分類（RQ2）：各論文のトピックを11カテゴリへ分類。
  4. 計量（RQ1）：年・会場・著者所属（産学）・公開状況などを集計。

リサーチ クエスチョン

SE 研究のトピック分布

数式・アルゴリズム

メタ研究なので最適化やアルゴリズムはなく、計量と分類が中身。信頼性指標として一致度 κ = 0.73 / 0.97（Cohen’s Kappa。1 に近いほど評価者間の分類が一致）を用いる。トピック分布は単純な頻度 count(category) で提示する。

実験・結果（主要な発見）

本文 §5.2「計算環境・ワークフロー管理」の詳説

本ノートで最大トピック（42本）の中身を掘り下げる節。本文 §5.2 は 4 つのサブセクションに分かれており、ここではそれぞれの主張・扱う問題・引用研究を整理する。なお本文は冒頭で「42本がこのトピックに該当する（最多）」と述べるが、4 サブセクションの内訳（10＋22＋4＋7）を足すと 43 になり、表と本文の集計に1本のずれがある（本文表記をそのまま記す）。

このトピックが最多になる背景には、ノートブックの再現性（reproducibility）が環境の不一致で崩れやすいという根本問題がある。同じノートでも、別マシン・別時点では依存ライブラリやカーネル・OS レベルの設定が捕捉・記録されていないために同一には実行できない——この「環境が揃わない」問題が、コンテナ化・クラウド/HPC 展開・状態保存・依存管理・性能最適化という複数の研究系を生んでいる、というのが §5.2 全体の見立て。

5.2.1 ワークフローに関する実証研究（Empirical Studies on Workflows, 10本）

ユーザが実際にノートブックをどう使っているかを観察・分析する実証研究の束。探索的データ分析（EDA）や計算ワークフローの中で、利用者がどんなパターン・習慣で作業し、どこでつまずくかを明らかにする系統。設計実態の調査、利用の計量・マイニング、データサイエンス現場の実態調査、データフロー的な捉え方、視線（gaze）計測まで含む。引用例：lau2020design、raghunandan2023measuring、choetkiertikul2023mining、psallidas2022data（本リポジトリの psallidas2022datascience に対応）、rehman2019towards、koop2017dataflow、subramanian2020casual、golendukhina2024unveiling、zou2024mlpipeline、sparmann2023jugaze。位置づけとしては、後続の技術的解決（5.2.2〜5.2.4）が「何を解くべきか」を支える観察の土台。

5.2.2 ノートブックの計算環境（Computational Environments in Notebooks, 22本）

§5.2 の中核で最大の塊。主張の軸は、環境の不一致による再現性破綻をどう技術で埋めるか。ノートは依存関係・設定を正しく捕捉・文書化しないため、別環境・別時点で同一実行を保証しにくい。これに対し本文は次のような解決アプローチを整理する：

引用は他に ramsingh2024understanding、kinanen2024improving、cao2024jupyter、li2024demonstration、zhu2024facilitating、jayawardana2024enhancing、kim2024japper、tsai2024libyt、christophe2023moon、savira2021writing。このサブセクションが最多であること自体が、「環境を揃える／持ち運ぶ」がノートブック SE 研究の最大の実需であることを示す。

5.2.3 ライブラリ依存の管理（Managing Library Dependencies, 4本）

焦点をパッケージのバージョン競合と依存の追跡に絞った系統。本文の指摘は明快で、ノートブック形式はライブラリのバージョン情報を確実にはエンコードしない——従来のパッケージマネージャのように依存を記録・強制する仕組みが標準で備わっていない。そのため利用者は requirements.txt や environment.yml といったファイルで手作業で依存を管理せざるを得ず、これが再現性の恒常的な障害になる。引用：zhu2021restoring、wang2021restoring、fitzpatrick2022davos（davos）、wannipurage2022framework（本リポジトリの 絶対状態の捕捉・再現フレームワーク に対応）。わずか4本と手薄で、5.2.2 の「環境まるごと」志向に対し、依存解決そのものを正面から扱う研究は少ないことが読み取れる。

5.2.4 性能分析（Performance Analysis, 7本）

ノート実行の計算効率・スケーラビリティ・最適化を扱う系統。大規模データに対する性能、各種ワークロード／資源制約下での挙動、ボトルネックの特定や資源割り当ての監視が主題。引用：werner2021bridging、werner2024jumper、faenza2024containerized、oden2024integrating、prathanrat2018performance、grotov2025themisto。環境を「揃える／持ち運ぶ」（5.2.2）の次に来る、「揃えた環境で速く・大きく回す」という関心系。これら6本は 性能分析の関係マップ（overview） に整理した。

§5.2 から読み取れる空白

本 SLR が全体として指摘する空白（テスト・リファクタリング・集約的ドキュメント生成のノート向けツールが未開拓）は、この最大トピックの裏返しでもある。すなわち、研究は「環境を整え・移送し・速く回す」インフラ寄りには厚く積み上がる一方、整えた後のコード品質を保つ営み（テスト・リファクタ・文書化）には届いていない——次の狙い目はここ、という含意。

関連研究との関係（メモ）

Q&A

（自分がAIに実際に質問したことだけを Q/A 形式で残す。まだなし。）

自分のコメント

ヒューマンコンピュータインタラクション (HCI) 関連の学会に数多く投稿されている
特に研究の再現性に関する研究が多い

使えそうなフレーズ