無料ブログはココログ

論文研修会最終回 - タイトルとあらましは論文を示す -

SRA Advent Calendar 2019 の記事です。

論文を書き方に最も大切なことを書きます。

ふりかえり

ここまで論文の書き方を説明してきました。

そのポイントは構造で、論理的思考につながるもので技術文書全般に利用できるものです。
私たちが学んだ起承転結(wikipedia)ではなく、パラグラフライティングを基本としたあらかじめ全体像や見通しを示した後に詳細を示す構造です。

重要性

パラグラフ(段落)だけでなく文章全体がその示す単位の全体像や見通しから始まっているのですから、タイトルやあらましは論文そのものの価値を示す最も重要な部分です。

「論文の採否はタイトルとあらましで6~7割決まる。いや8割かもしれない」そう教わりました。実際、論文の査読の際はタイトルとあらましで大まかに担当者が決められたりするでしょうし、論文を読む際もタイトルとあらましで期待を高めたり、困惑しながら読み始めます(ちなみに、タイトルとあらまし、はじめに、結論と読んでから他の部分を読む人が多いようです)。

何を書くか

端的に言うとアピールすべきことです。論文というのは、書きたいことを書くものではありません。もちろん採録されることだけが目的ではないですが、中身を理解してもらって採録されなければ論文を読んでもらうこともできません。書きたいことではなく、書かないといけないことを書いてください。

論文は研究者あるいは現場の人が研究成果や経験を書くもので、研究論文なら新規性、一般性、信頼性、経験論文なら有効性、一般性、信頼性を評価されます(シンポジウムなら参加者のニーズなどが入る場合もあるでしょう)。ですので、文字数は少ないながらもタイトルやあらましにこれらの内容を書書ないといけません。

タイトルには色々な流派がありますが、例えば「Aを目的としたB法によるC(問題)の(対策)D」のように対象分野、問題、手法、どこまで解決しを明確にするとともに示します。こう書くと一般性に制限を付けたように読めるかもしれませんが、そもそも論文とはこれまで積み上げられてきた研究という巨人の肩に乗って、少しだけ良くしたものです。適用分野明確にすることや方法を示すことで信頼性を上げています。一般性や有効性はXXを目的としたで示します。新規性は問題と解決法の組み合わせで示すことが多いようです。

あらましにも色々な流派がありますが、整理しやすいパターンとしては以下のような項目を書いています。

  • 本論文ではXX(タイトルの内容)を示す
  • YYによる評価の結果、ZZだとわかった
  • XXを用いることで、これまで××だったAがより〇〇に△△できるようになった

さらに必要なら、課題と将来性にふれることもあります。

タイトルとあらましは最後に書く

タイトルとあらましは論文の顔です。明確な問題設定がなければ書くことができません。開発現場の人が論文を書く際に難しいのは、経験しすぎていることです。自分の実現したことも、なかなか端的に表現できません。

そこで「はじめに」を書いて問題を絞っていくことから始めましたが、結論まで書いたところで一度「はじめに」を見直してください。問題とはやったことの裏返しです。解決したことがどのような問題を解決したかをよく考えて、必要なら書き直してください。

はじめにの見直しができたなら、ようやくタイトルとあらましを書くことができます。発表準備にタイトルとあらましが必要になるかもしれませんが、それはあくまで仮のものです。問題設定がふらついているのに魅力的なタイトルと思ってしまうとそれに引きずられて、わかりにくくなりますので、注意してください。

おわりに

これまで説明した論文の書き方を踏まえて、タイトルとあらましの書き方を説明しました。ここに書いた内容は筆者の限られた経験から書いていますので、他にももっと良い書き方があるでしょう。ぜひ、多くの論文を読んであなた流の書き方を作ってください。その際にこのブログが少しでも役立ったなら幸いです。

さて、今回の研修は論理的思考を身に着けてもらうために実施しました。論文を書く行為は、説明しないといけない内容を、決められた構造に合わせて、組み立て、整理することです。整理された内容は構造化されていますので、検索して容易に取り出すことができますし、組み合わせることも可能です。また、新しい情報に出会った際にも応用や修正が可能でしょう。(参考: 実装者のための計算量のはなし - O(logN)などをわかり易く説明しました -

説明しないといけない内容は、相手の求めていることです。相手の求めていることに合わせて、説明し、アピールする、そういった当たり前のことが難しいのは、説明すべき構造に合わせて単純化できていないからです。論文の書き方を応用することで、話が長い、理解されない、勘違いするといったことが改善されるでしょう。ぜひ、実社会に役立ててください。

このエントリーをはてなブックマークに追加

論文研修会(情報を正確に伝える構造)

SRA Advent Calendar 2019 17日目の記事です。

論文をはじめとする技術文書はパラグラフライティングが基本です。パラグラフライティングの作法 -書き手にもメリットのある文配置ルール- によると、

パラグラフライティングは,文章のまとまりを作るルールと,各まとまりの中での文の配置のルールに則って文を書く方法です.そのルールを簡単に言えば,「共通の話題で括れる内容は一つのまとまりとする」というものと,「各まとまりの先頭には最も重要な文を置き,それ以後にはその文の補足説明のための文を置く

というものです。これはパラグラフ(段落)だけでなく、文章全体も同じような構造になっています。いわゆる起承転結と違い、結果を先に示した上で詳細を説明します。

このような構造はドラマ「刑事コロンボ」や円蔵師匠の落語、最近ではドラマ「時効警察」の一部でもそのような構造になっています。先に結果を示すことで結果に至る過程を楽しむことができます。

論文の構成は基本的に以下のような構成になっていて、随所で要点と全体の見通しが示され、情報が正確に伝わるようにガイドします。

あらまし

論文で何を提案するか、評価の結果、その価値などアピールする点を説明します。

はじめに

対象とする問題とその一般的な意味を説明します(これは問題設定と呼ばれます)。そして最後に論文の構成を示します。

関連研究

この章でどのような関連研究を示すかを述べた後、関連研究の説明をします。この説明は一般にどういわれているかではありません。提案の扱う問題と解決手法がこれまでどこまで行われ、提案する手法以外では解決されていないこと、いわゆる新規性を示します。

提案手法、評価方法、結果、考察

これらも先に構造を示すと、見通しが良くなり読みやすくなります。また、それぞれの説明の中で互いの関係を示すと内容をよく理解してもらえるでしょう。

おわりに

論文で提案した内容とその効果、将来展望と課題を示します。

あらまし、はじめに、おわりに、は同じような内容です。それぞれの位置づけに合わせて、どこを詳しく書くかが異なるだけです。

正確に情報が伝わるように

論文を読みなれている人は、あらまし、はじめに、おわりに、結論の順に読んで論文の主張を理解した上で、他の章を読み出します。これらの内容に一貫性があり、さらにほかの章が論文の適切なアピールに役立っているなら、読者はきちんと評価してくれるでしょう。

逆に、各章や全体の見通しが悪かったり、話がずれていると、素晴らしい成果であっても読者は理解できないでしょう。論文はある問題に対する解決法を提案するものであって、それ以外の情報は要りません。書かないといけないものを書くのであって、書きたいことを書くのではありません。

このことは論文だけではありません。技術文章をはじめ、お客様への提案賞など、仕事にかかわる文章すべてが同じです。要点を絞り、結論と全体像を示せは、情報を正しく伝えることができるでしょう。

最終回に続く

このエントリーをはてなブックマークに追加

論文研修会(WS はじめに編)

この記事は SRA Advent Calendar 2019 16日目の記事です。
今回は実際に論文(実際は事例報告の要旨)の「はじめに」を書いてもらいました。「はじめに」は論文の問題設定と問題に対する論文のアプローチを説明します。実際に書いてもらって気になる点を指摘しました。なかなか面白い事例が出てきて、基本の3点さえ押さえれば良い事例報告になりそうでした。

解説

まず、前回の振り返りを兼ねてパラグラフライティングを説明しました(サンプル1)。各段落の先頭だけを読むだけで全体の論理展開がわかるようになっています。ただし最初の1段落目は2行目に趣旨があります。

これは興味を引くように「ツールやプロセスが重要」ということをアジャイルソフトウェア開発宣言を用いて逆説的に説明しているからです。また、最初の段落の最後が「つなぎ」になっていることも説明しました。

ワークショップ

採録された(普通レベルの)サンプル2を示して、各自の事例の「はじめに」を書いてもらいました。

事例を5行の箇条書きで書いてくるように課題を出していました。これはサンプル1の最初の1行に相当するものですが、それを2段落ごとにまとめて、問題設定、事例の内容、結論で1段落ずつになるように書いてもらいました。

実際に書いたものをみんなで読みながらコメントしました。コメントの多くは以下の基本的なものでした。

1.問題設定はやったことの裏返し、関係ないことは書かない
2.問題設定は広い内容から狭い具体的な内容に狭めていく
3.評価に合わせて書く。具体的すぎない一般的問題として説明すると汎用性が上がる。評価者が興味を持つようにする。

特に3番目は仕事でも重要なところで、お客様に合わせた提案でないとうまくいかないですね。このように論文を書くことは、実際の仕事にもつながる学びがあって面白いです。

次回は残りの本文を書きます。「全体を示してから詳細を書く」というパラグラフライティングの構造が入れ子になっていることを説明するつもりです。

 

このエントリーをはてなブックマークに追加

 

論文研修会(座学 本編)

この記事は SRA Advent Calendar 2019 9日目の記事です。

前回(論文研修会(導入編)- 論理的思考のすすめ -)に続き、論文の書き方を情報伝達あるいは論理的思考の観点で説明しました。
大まかな構造を理解してもらえたかと思います。

 

 

同じスライドを以前はシンポジウム参加の勧めとして書いていました(社会人のためのシンポジウム発表入門 リーン論文作法

次回はいよいよワークショップです。事例報告の「はじめに」を書き始めてもらいます(16日目の記事に続く)。

 

このエントリーをはてなブックマークに追加

論文研修会(導入編)- 論理的思考のすすめ -

この記事は SRA Advent Calendar 2019 2日目の記事です。

私の所属する関西事業部では、社内研修会というものを実施しています。個人的には、勉強会のようなものはオープンに行う方が、新しい技術を身につけられてよいし、社内を知ることができると思っています(社内勉強会より社外の勉強会)。しかし、社内でないと話しにくい内容もあるもので、今回行う論文の書き方などがそれで、論文と言いながら事例報告の概要を書くのですが、外に出せるネタがあるとは限らないので、社員だけが知ることのできる事例をもとに書き方を学び、それを通じて論理的思考を学ぶ。なんていうのは社内だからできることです。

論文というのは技術情報を伝達する方法の一つです。古くからソフトウェア開発では「コミュニケーション」が問題とされることが多くありました。しかし、この「コミュニケーション」には2つの側面があって、一つは情報伝達、もう一つが人間関係に起因する協力的な関係が気づけるかどうかだと思います。

このうち情報伝達のトラブルは、論理的思考力を身に着けることで大きく改善します。スライド中にある

  • いつのまにか話が長くなって 打ち合わせがなかなか終らない。
  • お客様や上司に理解してもらえず 意見が通らない。
  • 話を直接聞いているのに勘違いする。

などは、論文作成を通じて論理的思考力が身についていれば、多くの混乱を避けることができるでし
ょう。

参加者は社外発表をきたされている人や、昇格に向けて一皮むけてほしい人たちでした。内容はそれなりに伝わったようで、納得したり、耳が痛かったりしたようです。

スライドの説明のあと、以前日科技連でお話しした論文の書き方を説明しました(9日目の記事に続く)。

 

このエントリーをはてなブックマークに追加

 

刑事コロンボは東尋坊に関係者を集めない - 論旨の伝達に起承転結は不要 -

日本の学校では国語の授業で起承転結を習いますが、論旨が伝わりにくいので技術文章やビジネス文章としては良くない書き方です。 起承転結は後半にならないと結論がわからないからです。

Wikipediaによると、英語圏ではパラグラフ・ライティングが一般的とされています。そして、「パラグラフ・ライティングでは、結論にあたる主張が、文章全体の最初のパラグラフ (段落) に書かれる」とされています。

今回は、初めに結論が書いてあって、その後に説明が続く構造のメリットを考えてみます。

刑事コロンボは東尋坊に関係者を集めない

外国ドラマの「刑事コロンボ」では初めに犯人を示しておいて、刑事コロンボが犯人のトリックの矛盾を示していきます。日本の推理ドラマの様に、誰が犯人かわかりにくくする話をはさんでおいて、最後に東尋坊の断崖絶壁で関係者を集め、犯人を明らかにするということはありません。

刑事コロンボは犯行シーンから始まるので、見ている人に犯人は明らかです。誰が犯人かドキドキする必要はなく、犯人がどのように追い込まれていくかをじっくりと楽しむことができます。探偵や刑事の心境だけではなく、犯人がどのように考えているかまで推測することができます。

圓蔵(元円鏡)さんは先にオチを言う

日本でも、圓蔵(元円鏡)さんの落語は、同じような構造になっています。落語というと最後のオチがどうなるかを楽しみに聞くものですが、先にオチを言ってしまうのです。そして、どうやってそのオチに持っていくかを楽しませる落語をされます。

そもそも古典落語の常連はオチを知っていて、話の膨らませ方や話術を楽しんでいます。圓蔵さんは先にオチを言うことで、初めて聞く人にも、常連のような楽しみを与えているのでしょうね。

論理的な構造や内容に集中できる

刑事コロンボは論文や技術文書と似ています。結論を知ることで、論理的な展開や周辺の事情が見える様になります。

結論を初めに持っていくと言いたいことが予めわかるので、読者は論理的な構造や内容に集中できます。これは論文にふさわしいだけではなく、技術文書にも適切な構造です。

早めに考え始めることができる

もう一方の圓蔵さんの落語はビジネス文書に似ています。何が言いたいかわからない文章をダラダラ読まされることなく、結論がわかるからです。

判断を求められている時に結論がわからなければ、考え始めることができません。結論を先に示しておけば、その結論をどう判断すべきかを考えながら読むことができます。

エグゼクティブサマリ

もし長い文章を回覧するなら、エグゼクティブサマリ(偉い人向けの事業計画)のような概要を付けましょう。社会人のためのシンポジウム発表入門 リーン論文作法 のスライドに書いた様に、概要は具来的なエッセンスで書くことができるからです。

そして、許可をお願いする時もダラダラと話すのではなく、結論とエッセンスを先に話しましょう。きっと業務がはかどるでしょうし、上司のイライラがなくなって良い結果が得られるでしょう。

論文投稿はアクティブラーニング

大学では論理的な思考を教育すると言われていますが、実は論文投稿を通じて論理的な構造の文章作成や発表のアクティブラーニングの場です。実践を繰り返す中で、物事を論理的に整理することができ、新たな論理も組み立てられる様になります。

それは大学でなくてもできることです。日々構造を意識して文書を書く、シンポジウムに論文を書いて議論するということが、そのような繰り返しになります。そのような実践を通じて、技術者はより能力を高められる様になるのです。

おわりに

技術文書やビジネス文書は論理的な情報を端的に伝えるものです。論旨を明確にするには起承転結は不要で、初めに結論を示すべきです。

初めに結論を示せば、内容が明確に伝わり、読み手に考える時間を与えます。これは、会話や発表でも有効な方法です。

文書は構造を考えることでその価値が高まります。ぜひ一度、結論を始めに書いてみてください。難しいならエグゼクティブサマリを付けてみてください。

#キャッチーなタイトルのつもりが、古すぎたかなぁと思いつつ、、

このエントリーをはてなブックマークに追加

社会人のためのシンポジウム発表入門 リーン論文作法

ソフトウェアエンジニアのシンポジウム投稿のススメ」というイベントで発表してきました(論文の善し悪しをサンプルで見るを元にしました)。

このイベントは SQiPシンポジウム実行委員会主催で、ソフトウェアシンポジウムに関わっているSEA関西からも協力させていただく形で実現しました。

シンポジウムとか論文というとアカデミックで真面目イメージがあるかも知れませんが、それだけではなくコミュニティのお祭りなんだから、みんなで楽しく議論しようよ。という思いで発表させていただきました。

真面目な論文の話は世の中に色々と出回っていますので、現場の人が実践者として査読をどう乗り切るかを裏話を交えてお話ししました。

具体的には、審査基準にあわせて書くことでボーダーラインに乗る。ボーダーラインではプログラム委員が推してくれるかが勝負なので、聞きたい、聞かせたいと思ってもらえるような実践者でないとわからないことを書きましょう。と説明しました。

Q&Aで興味深かったのは、司会の細谷さんが「論文だけでなく仕事にも繋がる」とコメントされたことです。

実はこの論文の書き方は、このブログに書いた「できる人を観察して勝負する
にあるように、右も左もわからなかった私が社会人留学生として生き抜いた成果でもあります。

この他にも論文の書き方で仕事に繋がることとしては、段落の構成など色々あると思いますので、仕事に向けた視点でまとめてみたいと思っています(刑事コロンボは東尋坊に関係者を集めない - 論旨の伝達に起承転結は不要 -に続く)。

おまけ

今回引用した中で、ソフトウェア品質シンポジウム2016一般発表募集 –申込書(Word)は審査基準の詳細が載っていいて、参考になると思います。

また、今回は文章の表記法等には触れませんでしたが、ソフトウェア・シンポジウム 2016 投稿要領にあるスタイルの注釈を読むと基本的なところはカバーできる、つまりボーダーラインに載り易くなると思います。

より詳細には電子情報通信学会の和文論文誌投稿のしおり(情報・システムソサイエティ)を下の方までしっかり見ると、文献の書き方や送り仮名、略語まで載っています。今回の主旨とは異なりますが、ここまでできると論文誌に出しても恥ずかしくない体裁になります。

このエントリーをはてなブックマークに追加

論文の善し悪しをサンプルで見る

今週金曜日の勉強会に向けて評価の低い論文と評価の高い論文のサンプルを作りました。論文の大まかな構成を書くだけでも違いがわかります。

評価の低い論文のサンプル

【はじめに】
A社では,1980年の創業以来システム開発をしており,プロセス改善を進めてきた.しかし.Excelファイルによる進捗管理では,情報収集に時間がかかっていた

【関連研究】
近年,チケット駆動開発と呼ばれるRedmineを用いたタスク管理が注目されている.チケットと呼ばれるものでタスクを管理することで,開発者が進捗を入力できる

【研究内容(提案、経験)】
これまでExcelのガントチャートで管理していたチームに,チケット駆動開発を導入した.導入に当たってはRedmineの操作方法と運用ルールの説明会を実施した

【結果と考察】
進捗確認が効率化され,プロジェクトも成功した

【まとめ】
チケット駆動開発により,効率化できた.他プロジェクトに広げていきたい

【参考文献】
[1] 小川ほか, Redmineによるタスクマネジメント実践技法, 翔泳社, 2010.

評価の高い論文のサンプル

【はじめに】
進捗の共有はプロジェクトを効率化し,活性化する [1].本研究では,Excelに変えテチケット駆動開発(TiDD)を導入し,その効果をアンケートで評価した.

【関連研究】
チケット駆動開発では残作業が明確で不安が解消され,プロジェクトを活性化する[1].しかし文献[1]では管理者の視点であり,開発者の評価は未確認である.

【研究内容(提案、経験)】
初めてチケット駆動開発を導入したプロジェクトにアンケートを取った.アンケートでは,導入初期とそれ以降の作業時間と導入後の感想を集計した.

【結果と考察】
進捗確認作業が導入時約50%増,習熟後約20%削減した.安心感も増えていた.

【まとめ】
チケット駆動開発で作業と安心感が改善した.導入時講習が今後の課題である.

【参考文献】
[1] 阪井誠,チケット駆動開発によるプロジェクトの活性化 見える化と運用ポリシーがプロジェクトを変えた,SPI Japan 2010,JASPIC, 2010.

違いがわかられるでしょうか?これらの違いをきちんと理解するには、論文がどのように評価されるか、査読者がどのように考えるかを知る必要があります。

このブログでも紹介していくつもりですが、金曜日の勉強会ならまとめて聞くことができますので、是非ご参加ください。(社会人のためのシンポジウム発表入門 リーン論文作法につづく)

ソフトウェアエンジニアのシンポジウム投稿のススメ
申し込み:こくちーずプロ(告知'sプロ)
日時:  2016年3月11日(金) 19:00〜21:00
場所:  一般財団法人日本科学技術連盟 大阪事務所(新藤田ビル11階) 1102室(PDF
住所:  大阪府大阪市北区堂島2-4-27 新藤田ビル11階
参加費: 無料

このエントリーをはてなブックマークに追加

【告知】 ソフトウェアエンジニアのシンポジウム投稿のススメ 2016/3/11(金)夜

ソフトウェア技術者の仕事は、ソフトウェア開発を通じてシステムを開発することです。そして日々の経験を重ねることで、技術力を向上させています。

そんな技術者にとってシンポジウムは最高のコミュニティです。シンポジウムは査読と呼ばれる審査を通った人だけが発表できます。査読によって、発表する経験や発明が本当に広く役に立つ情報か、これまでの技術との違いをきちんと説明できるかを審査されています。

シンポジウムは、そんな役に立つ最新の技術が聞けるだけでなく、発表者と直接議論できる「場」です。

あなたもシンポジウムに投稿してみませんか?

もちろん、参加するだけでも議論に参加し、多くの仲間を作ることができるでしょう。でも、発表者になったなら、あなたの技術は広く知られ、より良くするためのアドバイスをもらうこともできるでしょう。

そして何よりも発表者自身が技術を整理することで、社会との関係を見直すことができます。明確になった技術によって仲間が得られ、その技術をさらに高めることができます。

しかしうまく整理できないと、査読で落とされることになります。きちんと整理するには、査読でどのように評価されるかを知り、無駄なく適切な表現で、客観的に説明できないといけません。

これは、簡単な様で難しい作業です。特に現場で働く社会人は説明したいことが多く、話が流れる、ポイントが絞れない、一貫性がない、などわかりにくくなりがちです。

そこで、ソフトウェア品質シンポジウム(SQiPシンポジウム)実行委員会の主催、
ソフトウェア技術者協会 関西支部の後援で、ソフトウェアエンジニアのシンポジウム投稿に向けた勉強会が開かれることになりました。

ソフトウェアエンジニアのシンポジウム投稿のススメ
申し込み:こくちーずプロ(告知'sプロ)
日時:  2016年3月11日(金) 19:00〜21:00
場所:  一般財団法人日本科学技術連盟 大阪事務所(新藤田ビル11階) 1102室
住所:  大阪府大阪市北区堂島2-4-27 新藤田ビル11階
参加費: 無料

この勉強会では、「社会人のためのシンポジウム発表入門 - リーン論文作法」と題して発表させていただくことになりました。短い時間ですが、ポイントを絞ってご説明する予定です。

ぜひ、勉強会に参加して、あなたの技術をシンポジウムに投稿してください。きっと新たな世界が広がることでしょう。

【おまけの告知】

SS2016のプログラム委員をしています。今回の勉強会より前の3月4日(金)が締め切りです。事例報告は要旨とスライド原稿で応募できます。応募の際に「阪井から聞いた」と書き添えていただければ幸いです。

ソフトウェア・シンポジウム 2016 in 米子 (SS2016)
論文・報告募集

このエントリーをはてなブックマークに追加

現場の人が論文を書く際に気をつけたい事

久しぶりに論文を書きました。私の様に現場にいる人間が論文を書くとき、熱い気持ちで思いの丈を書き綴っていても論文は採択されません。それは論理的に整理しないといけないのに、複雑な要素が絡み合う現場にいるからです。

今回、論文を書く際に気をつけた事を以下にまとめておきます。

現場はリアル

現場で問題に思っているのは、目の前の出来事です。スゴいものを実現したからと論文風にまとめてもなかなか採録されません。お客様に認められているのですから、決してつまらないのということはありません。それをきれいに説明できないからです。

ついつい苦労した事や工夫した事を色々と書きたくなりますが、そのままでは論旨がわかりにくくなってしまいます。書きたい事を書くのではなく、報告する内容を明確にするように、書かないといけないことを書きます。

これは、論文の構成をオーソドックスにまとめる事でかなり改善します。論文風にまとめるのではなく、論文らしくします。具体的には広い話題から徐々に話題を絞っていく、ページ比率を予め決めて書いて詳細すぎる内容は付録にまわす、全体の論理構成を決めてから書く、段落は短過ぎず長過ぎない同程度の長さに揃える、ことで見通しが良くなります。

論文には有効性が求められますが、論理的な構造が明確でなくては伝わりません。読み手が求めている事は何かを考えて書くと良いと思います。

現場にはネタがいっぱい

書いている事がわかり易くなっても、問題設定が適切でなければ評価されません。現場には論文のネタがたくさんあり、その絞り方で論文の価値が決まります。

まずはアピールできる成果を絞って、その成果を裏返してみます。「XXができていないので、XXを実現した。」という論文を考えます。そして、XXはなぜ必要なのか?あるいは、XXができると、他に何か良い事が無いか?また、なぜ、今までなぜ無かったか?などを考えて説明を膨らまして、適切な場所に配置していきます。

初めに書きたい事を書いてからスリム化をしようとしてもうまくいきません。書きたい情報が多いのでそもそも論理的な構造になりにくいですし、ネタが多過ぎてポイントがぼやけるからです。あたりまえの内容は参考文献にまかせて、新規性に関わる内容だけに絞ってフォーカスをあてます。

現場の成果はあるユーザに役立つ成果物ですが、論文に書かれた成果には一般の人に役立つ新規性が必要です。そのような成果を見つけ出すことが論文の成否に繋がります。論文を書き出してからも概要がスッキリかけるような成果を追い続けると良いと思います。

現場に引用はあまり要らない

開発現場のドキュメントでも用語集を作ることもあり、言葉の定義は重要です。しかし、その根拠となる文献が詳細に示されている事は少ないでしょう。

現場では巨人の肩にのる必要はありませんので、輪講をしていたり、常に文献を探している人は少ないでしょう。このため、意識して書かないと引用が雑になってしまいます。

具体的には、論理の組み立てが荒く、本や論文の具体的な文章やページを示さずに引用するといった事はなるべく避けたいものです。また、そもそも参考文献が少ないのは、ほとんど全てがオリジナルだと言っているのですから、良い内容であってもあまり信頼されないでしょう。

現場は独自文化

多くの開発現場には独特の社内文化があり、一般的でない言葉が定義されている場合があります。だいたいの意味は同じでも使い方を限定していることもあります。議論の展開に必要な言葉は、きちんと引用するか定義して使いたいものです。

独自文化で育てられた技術は、なぜその技術が成り立つかをきちんと説明しないと、利用が難しいでしょう。しかし、ふだん使っている技術のどこが他社と違っているのは、考えるだけではわかりません。関連する文献を読んでおくことや、勉強会などで他社の人とお話しする機会を持つことが大切だと思います。

現場の数字が出せない

現場の数字、特に生産性や信頼性に関わる数字は表に出しにくいものです。許可を得る事が難しい場合は、相対値で示す、出しやすいプロジェクトのデータを選ぶなど、色々工夫をしてみましょう。

定量的に示さずに感想を書いても信頼できる情報にはなりません。論文を書く際に最初に乗り越えておくべき課題かも知れません。

おわりに

上述の様に現場で論文を書くことは、困難を伴います。しかし、現場の情報を出さないでおいて「ソフトウェア工学は役に立たない」とぼやいていても何も変わりません。

ソフトウェア開発はエンジニアリングそのものですから、そこで見つけた技術を共有し合えば、技術はもっと向上するはずです。これは自分たちだけのノウハウだなどといって隠し持っていても技術は陳腐化してしまうでしょう。

技術はGIVE and GIVEのつもりで、情報提供すれば自然とアイデアがもらえ、より洗練された技術になるでしょう。ぜひ、論文を書いて技術を磨きましょう。

おまけ

これまで何度か論文の書き方を書いてきましたが、大学の先生方が言われる書き方と大きく違います。これは、ここに書いたような問題があって素直に書いたのではうまく書けないからです。

これまでの記事はカテゴリ「論文の書き方」にまとめましたので、是非参考にしてください。


このエントリーをはてなブックマークに追加