改訂版：開発現場で役立つ論文の書き方のお話
•
1 like•2,223 views
ソフトウェア開発の現場では、ちょっとした行き違いから問題が大きくなります。今回取り上げる『論文』は情報伝達を目的とした最も高度な技術文書の一つです。今回は論文の構造に合わせた書き方を学ぶことで、パラグラフライティングをはじめとする情報伝達の基本を説明します。 これから論文を書いてみたいという方や、仕事に行き詰まりを感じている方に。
Recommended
More Related Content
What's hot
What's hot (16)
Similar to 改訂版：開発現場で役立つ論文の書き方のお話
Similar to 改訂版：開発現場で役立つ論文の書き方のお話 (20)
More from Makoto SAKAI
More from Makoto SAKAI (20)
Recently uploaded
Recently uploaded (9)
改訂版：開発現場で役立つ論文の書き方のお話
- 2. 自己紹介 2 阪井誠：さかば、@sakaba37、 ㈱SRA、博士（工学） • 論文誌、国際会議、シンポジウムの採録経験のほか、ソフトウェ アシンポジウムのプログラム委員や委員長の経験を持つ • ソフトウェア工学の国際会議で最も権威があるといわれている ICSEに、論文が2本同時に通ったことがちょっと自慢。 レビュー 監訳 New No.6
- 3. 1. 背景 • ソフトウェア開発においてコミュニケーションは重要 [1] F. P. ブルックス, ソフトウェア開発の神話, p.81, 企画センター,1977. • 情報伝達の問題の多くは，話や文章が論理的構造でない ことから生じる • 論理的な構造を実現するには構造の理解のほか， 構造(形)に合わせて物事の整理（論理的思考力）が必要 • 論理的思考力のトレーニングである論文形研修により 議論や技術文章も適切になることが期待できる 論文への理解を通して論理的思考の基礎を身につけて 開発現場の仕事に役立てる 3 目的
- 4. 目次 1. 背景 2. コミュニケーション問題 3. 論文の構造（形） – パラグラフライティング – IMRAD形式 4. 無駄のない（リーンな）論文 構造編 5. 無駄のない（リーンな）論文 「はじめに」編 6. シンポジウムに投稿しよう まとめにかえて 4
- 5. 2. コミュニケーション問題 こんなことありませんか？ • いつのまにか話が長くなって 打ち合わせがなかなか終らない • お客様や上司に理解してもらえず 意見が通らない • 話を直接聞いているのに勘違いする => 論理的思考力の問題です 5
- 6. 話が長い • 話の対称性が悪い – 問題と答えの関係になっていない – 話が変わっている – 余計な話をしている 6 今日は良いお肉をも らったからすき焼きよ 俺がすき焼きが嫌いなの 知ってるだろう。すき焼き は邪道だ すき焼きもおいしい じゃない 良い肉の油は甘いのに 砂糖を入れるなんて許せ ない。俺は食べないよ！ 勝手にしなさい 「好きじゃないから食べない」で終わる話なのに、言いたい ことを言うことで話が長くなって、怒らせている 参考： ドラマ「俺の話は長い」
- 7. 理解してもらえない • 構造が悪い – なぜかを説明していない – 結論から言わず、順序的な説明をしている – 全体の構造を示さず、適切な引用もない 7 例の問題はどうなりま した？ よくわからないので色々 と試してみたのですが、う まくいかなくて まだ直らないので すか？ ライブラリのバージョンを 変えるとうまくいくこともあ るんですよね ややこしい不具合 なんですね 「バージョンの問題なので、リリースノートでバージョンを 確認中です」と言えば通じたが、不具合と勘違いされた
- 8. 勘違いする • 体系的に整理できていない – わからないままに聞いている – 丸暗記しようとしている – 全体を体系的に差分で理解していない 8 BODっていいよね （えっ、BODってなに、 新しい投資方法？） リスク有るんでしょう 新聞よりいいよね （新聞？出世できる？） そうね。やってみるわ 出世できるかも 「BODってなに？」と聞けば良いのにそのままにしたので、 知識が増えないし、新聞との違いも判らない 参考： BOD（テレビ東京の映像サービス）のCM
- 9. 3. 論文の基本構造（形） 論理的思考力を阻むもの • 起承転結（Wikipedia）より – 起承転結は，漢詩の構成にすぎず，論理的な文章を書ける 構成ではない – 英語圏では，「パラグラフ・ライティング」が文章一般に 用いられている – 学術論文では「IMRAD形式」が主流である 「パラグラフ・ライティング」 「IMRAD形式」などの 形（かた）の理解・習得が必要 ※形（かた）：規範となる方式 https://ja.wikipedia.org/wiki/%E5%BD%A2 9
- 10. パラグラフライティング • 文章のまとまりを作るルールと，各まとまりの中での 文の配置のルールに則って文を書く方法 • 「共通の話題で括れる内容は一つのまとまりとする」 • 「各まとまりの先頭には最も重要な文を置き， それ以後にはその文の補足説明のための文を置く」 • まとまりのことをパラグラフと呼び，各パラグラフの 先頭の文のことをトピックセンテンス（話題文）と呼ぶ • パラグラフライティングの作法 -書き手にもメリットのある文配置ルール http://www.ams.eng.osaka-u.ac.jp/user/ishihara/?p=566 10 注： ・論文はパラグラフライティングの入れ子構造になっている
- 12. IMRAD形式 • IMRAD形式は，学術論文の典型的な構成 – 導入 (Introduction) – 方法 (Methods) – 結果 (Results) – および考察 (Discussion) • 派生的な形式も含めれば，学術論文の構成は IMRAD形式が主流 ※ Wikipediaより 12 注： ・実証を伴う技術文書全般に利用可能
- 14. 見た目だけでは評価が低い場合もある 【はじめに】 A社では，1980年の創業以来システム開発をしており， プロセス改善を進めてきた．しかし．Excelファイルによる 進捗管理では，情報収集に時間がかかっていた 【関連研究】 近年，チケット駆動開発と呼ばれるRedmineを用いたタスク 管理が注目されている．チケットと呼ばれるものでタスクを 管理することで，開発者が進捗を入力できる 【研究内容（提案，経験）】 これまでExcelのガントチャートで管理していたチームに， チケット駆動開発を導入した．導入に当たってはRedmineの 操作方法と運用ルールの説明会を実施した 【結果と考察】進捗確認が効率化され，プロジェクトも成功した 【まとめ】 チケット駆動開発により，効率化できた．他プロジェクトに 広げていきたい 【参考文献】 [1] 小川ほか, Redmineによるタスクマネジメント実践技法, 翔泳社, 2010. 14 一般的かわから ない 陳腐な内容 工夫していない 効果が定性的． 信頼できない 特に興味を持た ない 引用ではなく紹介 ※評価の高い例は右記参照のこと http://sakaba.cocolog-nifty.com/sakaba/2019/12/post-92b027.html
- 15. 評価が低くなる理由 • 解決した問題の背景ではなく，プロジェクトや組織を 自己紹介的に書いている • 解決した問題の新規性を示す研究ではなく，対象分 野の一般的な説明や文献紹介をしている • 工夫や再現性，定量的なデータを示していない 現場の特性 • 経験に基づいて問題を解決することや，手順的な 説明の機会が多いので，冗長なことを書いてしまう => 形から外れやすい 15
- 16. 無駄のない（リーンな）論文 • 冗長な（形からはずれた）論文 – 書きたいことを書いている – いわゆる仕掛けカンバン(実験の場合の書き方) – 長文で趣旨が不明瞭（「なんでや！」が不明） – 意見が分かれる論文 • 無駄のない（リーンな）論文 – 書かないといけないことを書いている – いわゆる引取りカンバン(現場の書き方) – 適切で明確な文章（すべてが説明されている） – 落としにくい論文 16
- 17. リーンな構成の論文 結果から新規性，有効性を説明する構成にする （それだけで6ページは十分埋まる） • はじめに • 関連研究 • 研究内容（提案，経験） • 結果と考察（定量的に) • まとめ • 参考文献 17 有効性の説明：やったことの裏返し 一般的な課題から解決した課題に導く 新規性の説明：過去に提案 が示されなかったことを示す 価値を高める：実践しないと わからない情報を提供する 巨人の肩に乗る：成果の前提と なる文献を関連研究で「引用」する
- 18. 文章の構造に合わせて書く(1/6) 何について書くか • やったこと（経験） – 初めてプロジェクトにチケット駆動開発を導入した • 論文を書こうとした理由 – とても効果があったことを、みんなに伝えたい 18
- 19. 文章の構造に合わせて書く(2/6) 文献を探して方向性を決める • 関連研究 – チケット駆動開発では残作業が明確で不安が解消され，プロジェクトを活 性化する[1]．しかし文献[1]では管理者の視点であり，開発者の評価は未 確認である． 研究内容（経験） – 初めてプロジェクトにチケット駆動開発を導入した（やったこと） • 参考文献 [1] 阪井誠,チケット駆動開発によるプロジェクトの活性化 ―見える化と運用ポリシーがプロ ジェクトを変えた,SPI Japan 2010,JASPIC, 2010. 19 新規性の説明：過去に提案 が示されなかったことを示す 巨人の肩に乗る：成果の前提と なる文献を「引用」する
- 20. 文章の構造に合わせて書く(3/6) 研究内容を洗練する • 関連研究 – チケット駆動開発では残作業が明確で不安が解消され，プロジェクトを活性化する [1]．しかし文献[1]では管理者の視点であり，開発者の評価は未確認である． • 研究内容（経験） – 初めてチケット駆動開発を導入したプロジェクトにアンケートを取った．アンケートで は，導入初期とそれ以降の作業時間と導入後の感想を集計した． • 結果と考察 – 進捗確認作業が導入時約50%増，習熟後約20%削減した．安心感も増えていた． • 参考文献 [1] 阪井誠,チケット駆動開発によるプロジェクトの活性化 ―見える化と運用ポリシーがプロジェクトを変 えた,SPI Japan 2010,JASPIC, 2010. 20 伝えたい経験を 試行＋結果・考察に分ける
- 21. 文章の構造に合わせて書く(4/6) • はじめに – 進捗の共有はプロジェクトを効率化し，活性化する [1]．本研究では，Excelに変え てチケット駆動開発(TiDD)を導入し，その効果をアンケートで評価した． • 関連研究 – チケット駆動開発では残作業が明確で不安が解消され，プロジェクトを活性化する [1]．しかし文献[1]では管理者の視点であり，開発者の評価は未確認である． • 研究内容（提案，経験） – 初めてチケット駆動開発を導入したプロジェクトにアンケートを取った．アンケートで は，導入初期とそれ以降の作業時間と導入後の感想を集計した． • 結果と考察 – 進捗確認作業が導入時約50%増，習熟後約20%削減した．安心感も増えていた． • まとめ – チケット駆動開発で作業と安心感が改善した．導入時講習が今後の課題である． • 参考文献 [1] 阪井誠,チケット駆動開発によるプロジェクトの活性化 ―見える化と運用ポリシーがプロジェク トを変えた,SPI Japan 2010,JASPIC, 2010. 21 価値を高める：実践しないと わからない情報を提供する
- 22. 文章の構造に合わせて書く(5/6) • はじめに – 進捗の共有はプロジェクトを効率化し，活性化する [1]．本研究では，Excelに変え てチケット駆動開発(TiDD)を導入し，その効果をアンケートで評価した． • 関連研究 – チケット駆動開発では残作業が明確で不安が解消され，プロジェクトを活性化する [1]．しかし文献[1]では管理者の視点であり，開発者の評価は未確認である． • 研究内容（提案，経験） – 初めてチケット駆動開発を導入したプロジェクトにアンケートを取った．アンケートで は，導入初期とそれ以降の作業時間と導入後の感想を集計した． • 結果と考察 – 進捗確認作業が導入時約50%増，習熟後約20%削減した．安心感も増えていた． • まとめ – チケット駆動開発で作業と安心感が改善した．導入時講習が今後の課題である． • 参考文献 [1] 阪井誠,チケット駆動開発によるプロジェクトの活性化 ―見える化と運用ポリシーがプロジェク トを変えた,SPI Japan 2010,JASPIC, 2010. 22 有効性の説明：やったことの裏返し 一般的な課題から解決した課題に導く
- 23. 文章の構造に合わせて書く(6/6) • はじめに – 進捗の共有はプロジェクトを効率化し，活性化する [1]．本研究では，Excelに変え てチケット駆動開発(TiDD)を導入し，その効果をアンケートで評価した． • 関連研究 – チケット駆動開発では残作業が明確で不安が解消され，プロジェクトを活性化する [1]．しかし文献[1]では管理者の視点であり，開発者の評価は未確認である． • 研究内容（提案，経験） – 初めてチケット駆動開発を導入したプロジェクトにアンケートを取った．アンケートで は，導入初期とそれ以降の作業時間と導入後の感想を集計した． • 結果と考察 – 進捗確認作業が導入時約50%増，習熟後約20%削減した．安心感も増えていた． • まとめ – チケット駆動開発で作業と安心感が改善した．導入時講習が今後の課題である． • 参考文献 [1] 阪井誠,チケット駆動開発によるプロジェクトの活性化 ―見える化と運用ポリシーがプロジェク トを変えた,SPI Japan 2010,JASPIC, 2010. 23
- 26. 「はじめに」について • 説明内容 – タイトルと言葉の定義 – 問題設定 – 議論の内容と構造 • 説明方法 – 関連文献で説明して信頼性を高める – 広い話から徐々に狭める – 評価基準にあわせて読者が興味を持つように書く 26
- 27. 「はじめに」を書いてみる • タイトル – プロジェクトの活性化を目的としたチケット駆動開発の導入 • 初期の文章 – チケットによる進捗の共有はプロジェクトを効率化し，活性化する [1]． 本研究では，Excelに変えてチケット駆動開発(TiDD)を導入し，その効 果をアンケートで評価した． • 構成 – Trac等ITSを用いるチケット駆動開発はソフトウェア開発を活性化する – チケット駆動開発を導入したプロジェクトは情報共有ができてなかった – アンケートの結果、進捗を共有することで、必要なタスクが明らかになり プロジェクトが活性化したことが分かった – 以下の章では、関連研究、プロジェクトの概要、アンケート内容と結果 について述べる 27 タイトルと言葉の定義 問 題 設 定 議論の内容と構造 徐 々 に 狭 め る
- 28. 「はじめに」第1段落 • 内容 – Trac等ITSを用いるチケット駆動開発はソフトウェア開発を活性化する • パラグラフライティング – Trac等ITSを用いるチケット駆動開発はソフトウェア開発を活性化する [1] – TracやRedmineなどのITSはチケットシステムとも言われ、プロジェクト のタスクなどの情報共有に用いられる – コミュニケーションは古くからプロジェクトの成否を決めるといわれてい るからである[人月の神話] – ※コメントがあれば発言してください 28
- 29. 「はじめに」第2段落 • 内容 – チケット駆動開発を導入したプロジェクトは情報共有ができてなかった • パラグラフライティング – チケット駆動開発を導入したプロジェクトは情報共有ができてなかった – 納期が厳しいが、必要なタスクが不明確で、担当も割り当てられていな かった – メンバーの状況も共有されず、帰れるうちに帰ろうとしていた – ※コメントがあれば発言してください 29
- 30. 「はじめに」第3段落 • 内容 – アンケートの結果、進捗を共有することで、必要なタスクが明らかになり プロジェクトが活性化したことが分かった • パラグラフライティング – プロジェクト終了後にアンケートし、以下の結果を得られた • 進捗を把握できるようになった • 抜けているタスクをチケット化したので作業の抜けが減った • お互いに協力できた – コミュニケーションがよくなってプロジェクトが活性化した – ※コメントがあれば発言してください 30
- 31. 「はじめに」第4段落 • 内容 – 以下の章では、関連研究、プロジェクトの概要、アンケート内容と結果 について述べる • パラグラフライティング – 以下の章では、関連研究、プロジェクトの概要、アンケート内容と結果 について述べる – ※無理にふくらます必要はありません。 31
- 32. 「はじめに」全体 Trac等ITSを用いるチケット駆動開発はソフトウェア開発を活性化するといわれている[1]． TracやRedmineなどのITSはチケットシステムとも言われ、プロジェクトのタスクなどの情 報共有に用いられる．コミュニケーションは古くからプロジェクトの成否を決めるといわ れているからである[2]． チケット駆動開発を導入したプロジェクトは情報共有ができてなかった．納期が厳しい が、必要なタスクが不明確で、担当も割り当てられていなかった．メンバーの状況も共 有されず、帰れるうちに帰ろうとしていた． プロジェクト終了後にアンケートし，以下の結果が得られた． – 進捗を把握できるようになった – 抜けているタスクをチケット化したので作業の抜けが減った – お互いに協力できた コミュニケーションがよくなり，プロジェクトが活性化した． 以下の章では、関連研究、プロジェクトの概要、アンケート内容と結果について述べる． [1] 阪井誠,チケット駆動開発によるプロジェクトの活性化 ―見える化と運用ポリシーがプロジェクトを変えた,SPI Japan 2010,JASPIC, 2010. [2] ブルックス, 人月の神話, 丸善, 1975. 32
- 33. 「はじめに」見直し Trac等ITSを用いるチケット駆動開発はソフトウェア開発を活性化するといわれている[1]． TracやRedmineなどのITSはチケットシステムとも言われ、プロジェクトのタスクなどの情 報共有に用いられる．古くからコミュニケーションはプロジェクトの成否を決めるといわ れているからである[2]． チケット駆動開発を導入したプロジェクトは情報共有ができてなかった．納期が厳しい が、必要なタスクが不明確で、担当も割り当てられていなかった．メンバーの状況も共 有されず、帰れるうちに帰ろうとしていた．チケット駆動開発を導入した結果、納期に間 に合わせることができた． プロジェクト終了後に7人のメンバーにアンケートし，コミュニケーションがよくなり，プロ ジェクトが活性化したことがわかった．以下の章では、関連研究、プロジェクトの概要、 アンケート内容と結果について述べる． [1] 阪井誠,チケット駆動開発によるプロジェクトの活性化 ―見える化と運用ポリシーがプロジェクトを変えた,SPI Japan 2010,JASPIC, 2010. [2] ブルックス, 人月の神話, 丸善, 1975. 33 つなぎで入れた 評価に合わせた 読みやすい順序にした 要旨になってしまうので短くした
- 35. 国際会議 シンポジウムの位置づけ • 年に1回のお祭り – 経験を整理 – 新しい技術を みんなで議論 – 優秀者を表彰 35 分科会 研究会 勉強会 シンポジウム • 通過点から 議論の場へ – 論文指導 – 研究 – 実証 – 産学連携 全国大会 論文誌 アワード フェロー
- 36. アカデミアと外部発表 • 査読あり – 論文誌（博士の審査基準になる） – 国際会議（博士の審査基準になるものもある） – シンポジウム（修士ならこれぐらいが期待されている） • 査読なし – 研究会（研究に対する専門家の意見をうかがう） – 全国大会（腕試し、研究の経験、査読ありの場合もある） • 社会貢献 – 講演、書籍、共同研究、ベンチャービジネス 36 産学が日本語で 議論できる最も 高度な「場」 完成度 速報性 特徴
- 37. アカデミアの変化 論文指導＋研究から実証、産業界との協調へ • エンピリカル（実証的）ソフトウェア工学 • 経験論文（昔は研究論文だけだった） • 産学連携 • 共同研究 • ベンチャービジネス 37 評価されるように なった
- 38. シンポジウムと査読 • 組織 – 実行委員長 - 実行委員会 - ローカルアレンジメントー事務局 – プログラム委員長 –プログラム委員会 • 査読 – プログラム委員会で手分けして査読 – コミュニティ内で互選する仕組みことが多い – 足切りで一定の品質を保つが、基本的には教育システムに なっている（査読者は通したい） – 査読者は評点をつけるほか、説明が求められる ＝＞説明が容易な論文や聞きたい聞かせたい論文が 採録されやすい 38
- 40. 論文の構成 おおむね以下のような構成になっている • はじめに • 関連研究 • 研究内容（提案、経験） • 結果と考察 • まとめ • 参考文献 => それぞれ書かないといけないことが決まっており、 形だけを整えても評価されない 40
- 42. 審査基準 • 電子情報通信学会 – 新規性：投稿の内容に著者の新規性があること． – 有効性：投稿の内容が学術や産業の発展に役立つものであること． – 信頼性：投稿の内容が読者から見て信用できるものであること． – 了解性：投稿の内容が明確に記述されていて読者が誤解なく理解でき るものであること． • 情報処理学会 – 学術、技術上の研究あるいは開発成果の記述であり、新規性、有用性 などの点から、会員にとって価値のあるもの • ソフトウェアシンポジウム – 新規性や信頼性（研究論文） – 知見の有用性（経験論文）:採点は新規性、有用性、信頼性、構成力: • SQiPシンポジウム – 有用性、信頼性、構成と読みやすさから総合的に判断 42
- 43. ソフトウェア品質シンポジウム（SQiP） • (1) 有用性 – 経験や、提案する方法が、有用であるかどうかで判定します。自明な方 法、すでに広く利用されている方法、陳腐な方法、あるいは、極めて特 殊な場合や、特殊な分野にのみ適用可能な場合は、有用性が低いと 評価します。投稿者及び関係者自身の長期間にわたる実践により得ら れた結果や考察は、単発や短期間の試行や他者が提供する公開情報 （オープンソースソフトウェアの情報を含む）を用いた評価よりも有用性 が高いと評価します。 • (2) 信頼性 – 提案手法の有用性が性能評価等により示されているか、または製品化 、あるいは公開された作品、プロダクト等（ソフトウェア、ハードウェア等 ）で技術的有効性が客観的に確認されているか、という観点から評価し ます。アブストラクト投稿時点では結果が出ておらず、経験論文、経験 発表を投稿する時点において結果が揃う場合には、査読者がそのこと を予想、判断できるような情報や根拠を示してください。 43
- 44. ソフトウェア品質シンポジウム（SQiP） • (3) 構成と読みやすさ – 趣旨が読み取れない場合、採録要件を満たさないと評価します。章構 成が適切か、論理の飛躍がないか、文章が長すぎないか、表現が適切 か、誤字脱字の修正をはじめとして推敲は十分に行われているかを評 価します。 • (4) その他 – 既発表の内容をもとに追加や改善した点を投稿する場合には、既発表 の文献を引用し追加、改善した点を明確にすることで査読者が既発表 分との違いを判断できる情報を示してください。過去の発表との差分が 小さい場合には、その点を加味して評価します。 44
- 45. チェック！評価の低い文章 • はじめに – A社では，1980年の創業以来システム開発をしており，プロセス改善を進めてきた． しかし．Excelファイルによる進捗管理では，情報収集に時間がかかっていた • 関連研究 – 近年，チケット駆動開発と呼ばれるRedmineを用いたタスク管理が注目されている． チケットと呼ばれるものでタスクを管理することで，開発者が進捗を入力できる • 研究内容（提案、経験） – これまでExcelのガントチャートで管理していたチームに，チケット駆動開発を導入し た．導入に当たってはRedmineの操作方法と運用ルールの説明会を実施した • 結果と考察 – 進捗確認が効率化され，プロジェクトも成功した • まとめ – チケット駆動開発により，効率化できた．他プロジェクトに広げていきたい • 参考文献 [1] 小川ほか, Redmineによるタスクマネジメント実践技法, 翔泳社, 2010. 45 一般的か？ 陳腐な内容 工夫していない 効果が定性的。信頼できない 特に興味を持たない 引用ではなく紹介
- 46. リーン論文作法の狙い • 冗長な論文 – 書きたいことを書いている – いわゆる仕掛けカンバン – 長文で趣旨が不明瞭になり易い（「なんでや！」） – 意見が分かれる論文 • 無駄のない論文 – 書かないといけないことを書いている – いわゆる引取りカンバン – 適切で明確な文章（すべてが説明されている） – 落としにくい論文 46
- 47. リーンな構成の論文 結果から新規性、有効性を説明する構成にする （それだけで6ページは十分埋まる） • はじめに • 関連研究 • 研究内容（提案、経験） • 結果と考察（定量的に) • まとめ • 参考文献 47 有効性の説明：やったことの裏返し 一般的な課題から解決した課題に導く 新規性の説明：過去に提案 が示されなかったことを示す 価値を高める：実践しないと わからない情報を提供する 巨人の肩に乗る：成果の前提と なる文献を「引用」する
- 48. チェック！評価の高い文章 • はじめに – 進捗の共有はプロジェクトを効率化し，活性化する [1]．本研究では，Excelに変え てチケット駆動開発(TiDD)を導入し，その効果をアンケートで評価した． • 関連研究 – チケット駆動開発では残作業が明確で不安が解消され，プロジェクトを活性化する [1]．しかし文献[1]では管理者の視点であり，開発者の評価は未確認である． • 研究内容（提案、経験） – 初めてチケット駆動開発を導入したプロジェクトにアンケートを取った．アンケートで は，導入初期とそれ以降の作業時間と導入後の感想を集計した． • 結果と考察 – 進捗確認作業が導入時約50%増，習熟後約20%削減した．安心感も増えていた． • まとめ – チケット駆動開発で作業と安心感が改善した．導入時講習が今後の課題である． • 参考文献 [1] 阪井誠,チケット駆動開発によるプロジェクトの活性化 ―見える化と運用ポリシーがプロジェク トを変えた,SPI Japan 2010,JASPIC, 2010. 48 一般的な課題、評価方法を説明 新規性を示す 再現性、工夫を示す 効果が定量的。信頼できる 実施してわかった課題 先行事例の引用
- 49. 基本的なTIPS • 言葉の定義を明確に • 評価基準に沿った内容を書く • 引用を組み合わせて問題設定する • 疑問が残らないように「なんでや？」と考える • 評価は定量的に。できれば検定を • 定性的な内容も工夫する • 客観的な事実と主観的な内容は分離する • 文献は論文の引用が基本 • 書籍の引用はページを書く 49
- 50. 査読者を意識したTIPS • 落としにくい論文より、聞いてみたい論文 – 合計点で勝負！ – 実践しないとわからない内容を示す • 内容を的確に示すタイトル – 「手法名： XXを目的としたXXの○○法の提案」など • 評価基準に沿った概要 – やったこと、効果、評価項目に合わせた特徴 50 チケット駆動開発導入による進捗管理の効率化と課題 本論文ではこれまで示されていなかったチケット駆動開発の 作業効率をアンケートにより評価した。チケット駆動開発で 進捗を共有した結果、従来よりも約20%進捗の共有作業が 効率化された。その反面、導入時は作業効率が50%低下して おり、教育が重要であることもわかった。
- 51. 最後まで全力で 実践しないとわからないことを示す • 定量的な情報 – 公開できない場合は相対値で • よかったこと – 主題でないこともアピールする • 難しかったこと、工夫したこと – 再現する際のノウハウを提供する • 今後の課題 – できていないことを明示して信憑性を高める 51
- 52. おわりに 論文を投稿してお祭りに参加しよう！ • シンポジウムはコミュニティのお祭り • 査読は技術力を向上させる • 評価基準に合わせて技術を整理する • 実践しないと知りえない情報はあなたにしか 書けない • 落ちても指導が受けられる（書き方、関連文献） => それでは、シンポジウムでお会いしましょう！ 52
- 53. 参考リンク • 電子情報通信学会 和文論文誌投稿のしおり （情報・システムソサイエティ） 5.1 査読の基準 – http://www.ieice.org/jpn/shiori/iss_5_1.html#5.1 • 情報処理学会 論文誌ジャーナル（IPSJ Journal） 原稿執筆案内 – https://www.ipsj.or.jp/journal/submit/ronbun_j_prms.html • ソフトウェア・シンポジウム 2021 論文・報告募集 – http://sea.jp/ss2021/call_for_papers.html – https://www.sea.jp/ss2021/call_for_papers.php • ソフトウェア品質シンポジウム一般発表募集 – https://www.juse.jp/sqip/symposium/ippanhappyou_boshu/ 53
- 54. 完 54