無料ブログはココログ

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

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

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

おまけ

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

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


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

論文らしくする方法

技術発表のポイント、論文作法(構成注意点良い技術)を説明しましたが、論文を多くの人に読んでもらうには、読み易く、 よりわかり易くする必要があります。

学生の方なら見様見真似で書き始めるので自然と論文らしくなるかも知れませんが、社会人は書きたい気持ちが強過ぎて論文らしくしないままに論文を書き上げてしまいます。私も「これでバッチリだ!」と思った論文でたくさんの指摘を受けました。

その多くは見た目の問題ですが、開発標準に沿ったドキュメントと同じようにルールに従った論文は読みやすいものです。また、必要な項目がバランス良く書かれている論文は、必要な内容がきちんと書かれているとも言えます。

では、順に見ていきましょう。

タイトル

タイトルは論文に示す実績を的確に表現します。一般的に有効な論文であると主張するのでなければ、内容にあわせたターゲットの絞り込みが必要です。また、アピールする点がその方法によるなら、それもタイトルに入れます。

例:信頼性向上に関する一考察
  => リリース回数による業務ソフトウェアの残存障害数予測法

明確にするために句読点を入れたい場合は、明確でない可能性があります。

概要とまとめ

エッセンスを書きます。アピールすること、その効果を示します。論文の全体像を示す必要はありません。

例:
アジャイル開発の普及や社会の変化が激しくなったことから、業務ソフトウェア開発では複数回のリリースが増えている。一方、社会への影響が大きくなるに従い、ソフトウェアの信頼性へのニーズは高まっている。ソフトウェアの信頼性予測ができれば効果的にソフトウェアが開発できると考えられる。そこで、リリース回数と障害数の関係を調査し、その結果を示す。
  => 
本論文では,リリース回数に基づく残存障害数予測法を提案する.提案する方法は要件の詳細が不明確なソフトウェアはリリース回数が多いことに注目し,業務ソフトウェアの残存する障害数を予測する.要件の詳細な分析が不要な方法であり,リリース時にメンテナンス費用を概算することが可能である.20プロジェクトでモデル式を求め,異なる20プロジェクトに当てはめた結果,危険率5%で有意差が認められた.

問題設定と関連研究

問題設定は「 はじめに 」などで、その論文でアピールするものの価値を決まるものです。広い範囲から徐々にターゲットの領域を絞り込んでいきますが、論理展開の単位となる各段落ごとに文献を引用して客観的に示します。もし、文献がないなら、主観でなく、論理的にその領域の重要性を説明します。

関連研究はターゲットの領域の既存研究を示し、アピールする内容が実践されていない、あるいは不十分であり、論文に価値のあることを示します。また、論文中に利用する方法やツール等も問題設定や関連研究の中で示して、議論の土俵固めをします。

文献と引用

文献はなるべく最新の査読付き論文で示します。一般に、研究会等の査読なし論文、シンポジウムや国際会議等の査読付き論文、論文誌の(査読付き)論文、書籍、の順に研究が進んでまとめられますので、前のものほど新しく信頼性が低く、後のものほど一般的で信頼性が高いと言えます。

広く知られた内容ではなく、査読者に評価されていて、ほどほどに新しい査読付き論文が良いでしょう。書籍を引用する場合は全体でなく、示したい内容をページや文章の引用で示します。文献のURLは読者の参考になりますが、Webだけの情報は変化するのであまり良いと言えないでしょう。

文献の一覧は、学会により記法が異なりますが、引用マーク、著者、タイトル、文献、ページ、出版社、公開年、の順に示します。

例: [1] 阪井 誠,  中道 上,  島 和之,  中村 匡秀,  松本 健一, Webtracer:視線を利用したWebユーザビリティ評価環境, 情報処理学会論文誌, Vol.44, No.11, pp.2575-2586, 2003.

最後にピリオドを付けます。ソート順は出現順や名字(Sir name)順が多い様です。本文の引用マークは句読点の前に書きます。

例:阪井らは視線と画面、マウス操作を同時に記録・再生することで,ユーザビリティテストを支援した[1].

事実と推測の分離

結果と考察のように分けられる場合は章単位に分けます。はじめにのように構造上難しい場合やページ数の制約などで、一つの章に事実と推測が混ざる場合は、段落単位に分離します。

事実を示す関連研究が少ないなどバランスが悪い場合は、言いたいことを書きすぎていることが多いので、アピールする点をどのように説明すべきかを今一度見直すと良いでしょう。

とことん書く

論文の構造を整理していくと単純になりすぎる場合があります。実際に経験した人でないとわからない情報を付け加えることで、論文の価値が高まります。

イベントの参加者や論文の読者に知らせたい内容かどうかが、査読の最終判断に影響します。特に経験論文の場合は表面的な内容だけでなく、うまくいかなかった点やノウハウ的な内容で評価が変わる可能性があります。

細かな点

図表は上か下に寄せて配置します。表題は上に、図のタイトルは下につけますので、それぞれ上と下に寄せると本文との干渉が少なくなります。図表のページを独立させても良いでしょう。

文章にもルールがあります。括弧は論旨を曖昧にします。なるべく括弧をなくします。昔はJISに習って、カタカナ表記の最後に「ー」がある場合、4文字以上は「ー」をとるように言われましたが、最近は変わっている様です。

細かな内容も含めて、論文誌の場合は学会で基準が決められています(電子情報通信学会)。シンポジウム等では過去の論文誌を参考にすると良いでしょう。

おわりに

論文らしくする方法を思いつくままに書きました。論文らしくすることで、より読み易くしますし、バランス良く書くことでわかり易くなります。

良い研究は新しく、役に立ち、信じるに足る実証がされているものです。良い論文は、そのような良い研究を前提とした上で、論旨が明確で、読者の役に立つ内容が書かれたものです。

しかし、どんなに良い研究であっても、正しく伝わらなければ理解してもらえません。良い論文の構造は、少ない文章で明確に伝達する構造です。

良い論文に仕上げている間に、曖昧な考えが明確になる場合もあります。技術発表は読者のためだけでなく、自分自身の理解を深めるためでもあるのです。

あなたの経験をぜひ整理してください。そうすれば、その技術は積み上げ可能になり、きっと社会の役に立つでしょう。

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

構造化された技術発表 - アカデミアとの壁・その3 -

少し間があきましたが、アカデミアとの壁(言葉の定義巨人の肩に乗る)の第3回です。

技術発表には、読み易いバランスの比率がある

さかば流・論文作法 その1 - 論文の構成 -でまとめた各項目は、おおよそ以下の比率で書いています。

  • タイトル・概要:5%
  • はじめに:10%
  • 関連研究:15%
  • 提案手法:20%
  • 評価(実験)方法・結果と考察:25%
  • おわりに:10%

論文10ページなら10%が1ページになります。 これは口頭発表でもあまり変わらず、 20分の発表でスライド20枚なら5%で1枚です。内容によって分類を変えたり、比率を変えるなどします。

言葉の定義をしてから使う

仕様書の用語集のような書き方ではなく、「はじめに」や「関連研究」の説明の中で、説明に必要な用語を文献からの引用と共に示します。

前提やコンテキストが不明な用語で議論すると、イメージする言葉の意味は百者百様になってしまい、話が通じなくなるからです。

インパクトは不要。先に答えと内容を言う

上述のような構造に分けて説明することが前提なので、インパクトのある写真を入れると構造を乱すかもしれません(技術発表はわかってもらうことが目的です)。

技術発表では、先に答えを示すことで論理的な構成をわかり易くします。円蔵さんの落語、刑事コロンボ、偉人伝、の様な構成と言えば良いでしょうか。驚かせるのではなく、「なるほど」と味あわせる構成です。

内容は一つに絞る

上に書いたように本筋の話は半分ほどの時間しかありません。何とか時間におさめるようとすると、内容は必然的に限定されます。

巨人の肩に乗ることで、オリジナルの所だけに集中して説明できます。この方法は合理的で、いわば技術の差分プログラミングのような表現法です。余分な事は言わず、言いたい事と言わないといけない事を切り分けて、必要なことだけを説明します。

その反面、関連研究まで知らないと理解が困難になります。畑違いの研究会では、聞く場合も苦痛ですし、話す場合も基本的な内容から説明しないといけません。このようにして、色々な研究会ができたのだと思います。技術者がわからないと思うのも無理はないのです。

おわりに

このような技術発表は、技術の前提(あるいはコンテキスト)と限界を示しつつ、有効性と信憑性を示します。その内容がぴったりと当てはまる範囲はそれほど広くなく、自分の役に立たないと感じる方もおられるでしょう。でも、それが積み上げ可能な技術だと思います。

勉強会の増加に伴って、技術の敷居を下げる発表や、新しいムーブメントを紹介する発表が増えてきました。それらは、技術者のコミュニティを作り、参考になる情報の共有を促進しています。しかし、情報共有でとどまっていたのでは、技術力は向上しません。

色々な人に響くモノがあるスライドは、参加者の満足度を高めます。サービス精神に敬服するものもありますが、発言に裏付けがない場合は安心して使えません。

また、これからは「XXだ!」とブームを作ろうとする発表は、モチベーションを高める効果があります。その一方で、発表が一面的であったなら、多くの失敗プロジェクトを生み出してしまうでしょう。

巷には言いっぱなしの発表が満ちあふれています。これだけでは、様々な方法論が生まれては消えていった1980年代のソフトウェア工学ブームの二の舞です。技術は積み上げ可能にしないといけないのです。

今やチェスやオセロなどボードゲームは計算機にとっては難しくない分野になりつつあるのかもしれません。しかし、総当たりの単純なアルゴリズムでは時間がかかりすぎることが知られるまでは難しい研究分野だったと思います。

それが今のように進化できたのは、(私には難しかった)計算量の研究によって限界が示されてアルゴリズムの研究が進んだからでしょう。技術の前提や限界を示すことで、他の人が適用分野を広げてくれるのです。

全ての技術者が必ずしもアカデミアを意識する必要はないと思いますし、高度で複雑な実践をしているのは技術者でしょう。しかし、技術者同士のコミュニケーションが仲間内でとどまって発展性が無いのなら、それは国家的、いや世界的な損失だと思います。けっして、大げさな話ではないと思います。

巨人の肩に乗る - アカデミアとの壁・その2 -

前回の「言葉の定義」でも書きましたが、 私が最初に(人格)指導されたのは「謙虚になりなはれ」でした。

この指導、生意気な若者や、腕に自信を持つ現場の人間が良く注意される様です。なぜなら、わかったつもりになっているからです。

プロとして仕事をしているの以上、みんな一人前ですし、技術に自信を持って構いません。しかし、実際にはその技術の多くは既存技術から成り立っています。また、技術者が苦労して開発したものの多くは、既に誰かの発見した技術の再発明であることも多いでしょう。

研究成果を論文にする場合は、利用した技術や再発明した技術ではなくオリジナルの成果が必要です。そのためには、既存の技術はどのようなもので、どこまでを利用していて、何を実践して、 何を新しく発見したか、そして過去の発表とどのように違うかを明確にしなければいけません。

これは「巨人の肩に乗る」(はてな)と言われているもので、過去の偉大な成果を忘れずに謙虚に示す事で、自分の成果を際立たせる事ができるのだと思います。

「巨人の肩に乗る」には3つの方法に分けることができます。これは研究が、問題設定、手法、評価からなっているからです。

(1) 問題設定で過去の研究を否定する。これは過去の研究の少し乱暴な使い方です。XXXな観点からYYYが成果を上げているが、ZZZは考慮されていない。として、新たな問題設定をする。

(2) 問題設定はそのままで、手法を提案する。一般に「巨人の肩に乗る」というと、これをさす事が多い様です。新しい手法を提案し、なぜ優れているかと、どの程度優れているかを示します。

(3) 新たに評価します。これにはさらに3つの乗り方があります。

  • 新しい技術は評価が不十分なことが多いので、評価実験を追加してその技術の特性や限界を示します。
  • 評価方法を提案します。同じ手法でも新たな評価によって、結果が代わる事があります。この場合、評価の精度や特性がオリジナルな点になります。
  • 開発現場で実践した結果とノウハウを示します。現場の技術者が貢献しやすい方法です。事例の数を揃えるとインパクトのある報告になります。

このように分けると、現場の技術者ならではのアピール方法は(3)だけですが、実は(1)と(2)も日常的に行っています。しかし、どこまでが既存技術であるかを把握していないので、そのアピールができていないと思っています。

全てを自分の発見の様に言うのではなく、過去の技術をきちんと説明し、どこがすごいかを説明できれば、技術を積み上げ可能にできると思います。

言葉の定義 - アカデミアとの壁・その1 -

私が最初に研究指導されたのは、言葉の定義でした(ちなみに人格指導の最初は「謙虚になりなはれ」)。言葉の定義は、論文を書く場合だけでなく、より多くの人に技術的な内容を正確に伝える際には大切な事だと思います。

開発現場の人間は、その現場で通じる言葉を話します。しかし、論文などの研究成果は多くの人に理解してもらうものですので、誤解のないように伝えないといけません。誤解がないようにというのは、厳密と言うよりは「ここでは」の意味を定義して、制限して使うということです。

たとえば、「バグ」似た言葉は、欠陥、障害、故障、など色々な意味があり、学会によってもそれぞれの意味が異なる言葉です。プログラムの誤りの数なら英語で言う fault で、正常に動かなかったテストの数なら failure になります。一つのソフトウェアの誤りで、複数のテストが不合格になりますので、同じ数値でも単純に比較できません。

論文ではバグではなく障害と呼ぶ事が多いですが、本文中の障害が fault なのか failure を示すのか明確にしてから議論します。

バグの定義などは専門的ですが、これ以外にも工程や作業の名称、工数を「稼働」と呼んでも伝わらないですし、「1人月」といっても時間数にすると違うほか、見積もりと計画、実作業、で1人月の扱いが異なる事も多いでしょう。

アカデミアでは、一般に使われている定義であるだけなく、議論の前提として使える様に定義します。その際には経験的に示されたものを引用する事で無駄な議論を避けて、いわば定理として用いて、そこから演繹した世界で研究成果を説明します。

難しいのは、その議論を聞く人が「できる人」もいる事です。できる人は、頭の中で知識の構造を常にリファクタリングしています。曖昧な定義のままで説明しても混乱を招くだけで、わかってもらう事はできません。内容の説明にどのような用語が必要で、どのように定義すれば、既存技術との違いを説明できるかが明確になっていないといけません。

このように、自分の言いたい事を伝えるには豊かな表現やイメージではなく、伝えたい事の構造を整理しておかなければ、うまく伝わらない場合があります。言葉の定義は、より多くの人に技術的な情報を正しく伝えたい場合には、意識しておかないといけない事の一つだと思います。

できる人を観察して勝負する

なに気なくつぶやいたところ、評判が良かったのでブログにまとめておきます。

このように考えだしたきっかけは、会社から奈良先端大に留学した時の事です。周りは旧帝大の卒業生ばかりで、一流とは言えない大学の出身者である私は困ってしまいました。

仕事として留学しているので、下手な成績はとれません。しかし、先生も学生も阪大、京大、九大など、偏差値の高い人達です。昔のような勉強法では勝負になりません。

そこでしたのは観察です。できる人達がどのように考え、どのような行動をとり、どのような特性があるかを分析しました。元々は修士(博士前期)過程の授業対策ではじめましたが、その後の研究の中で感じた事や高校生時代の話を織り交ぜながら説明します。

知識の構造を常にリファクタリングしている

上のつぶやきに書いた様に、新しい情報に接する際には、既にある知識構造に当てはめながら、場合によっては構造を見直しながら理解しているようです。

論文で言葉の定義が重要視されるのはこの事が大きく影響していると思います。短い文章で論理的な事を説明するので、用語を端的に説明して一つの意味でだけ使わないと、理解してもらえなくなるからです。

日本人ならある程度我慢してくれますが、国際会議などではタイトルの意味や背景の説明が不十分だと、すぐに質問されてしまいます(失敗すると面倒くさくなるので「後で説明する」と言って我慢してもらう事が多い様です)。

このような事を考えていて思い出したのは、旧帝大に行った高校時代の友人達です。化学や物理の授業後の休憩になると、必ずと言って良いほど言葉の定義を話し合っていました。

彼らは「XXと言うのはYYということだ!」「でもZZと言う例があるから必ずしもそうではない」などと話しておりました。

当時は本当に勉強が好きな人たちだと思っていましたが、お互いの理解を説明し合って知識の構造を見直していたのだと思います。知識が体系化すると覚えないといけない情報が少なくなるからでしょう。

成績の良い彼らは、勉強していない振りをして陰で猛勉強しているに違いない。と思っていましたが、実は効率よく勉強していただけなのかもしれません。

それなのに凡人の私は、情報を整理しないまま放置して、試験の前日に大量の情報を覚えようとしていたので、勝てる訳がありません。知識獲得の際に随時整理しておくと言う事が大切だったのですね。わからない事は貯めずにきちんと理解して整理する。それが一つ目の戦略でした。

ゴールに合わせる

先端大の授業に出ていると、優秀な学生さん達の話し声が聞こえる事もありました。「大学の推薦を得るには、成績の順位が良くないといけない。」「それは成績の平均点だ。」「優が取れない科目は捨てる。」などと話しているのです。

その後、先端大では単位数も評価に入った様ですが、当時は優、良、可をそれぞれ3点、2点、1点として、その平均で学生を順位付けして推薦を与えていました。そのような評価方法に合わせて、彼らは授業を受ける科目を選んでいたのです。

学校の推薦を得ることが目的ですので、単位が取り易いかどうかではなく、優が取れそうかどうか、場合によっては「優でなければ落としてください」と試験に書いて、少しでも有利にしようとしていました。

私が高校生の時は、試験に合わせて勉強するのはおかしい。と言って予備校式の勉強を否定していたのですが、優秀な彼らは受験勉強はもちろん、大学の単位もゴールに合わせていたのですね。

彼らが大学の先生になったとします。もし、論文の数だけで評価するなら、社会の役に立つかどうかは関係なくなって、論文数を得ようとしても仕方ありません。

大学の先生の評価には、すでに社会貢献なども入っている様ですが、さらに社会貢献の比率を高めれば、もっとすごい研究成果が生まれるかもしれませんね。

価値観が明確

上記2点の影響からか、価値観も明確な人が多い様に思います。興味のある授業を取るという点は普通ですが、それ以外の科目はより多く優を取ることが優先されているようでした。さらに、同じ優なら苦労せず、確実に取れる科目が好まれている様でした。

価値観が明確であるので、就職先を選ぶ際もシンプルでした。彼らは、生活に必要な収入を得る事が就職の目的なので、待遇が良く安定した会社が好まれている様でした。

個人的には、昇格するか、会社が伸びるかどうかで収入は変わると思います。そして何より、その会社に居ると自分が成長できるとか、会社を利用して社会貢献できるとか、会社に居場所ができるとか、そう言った事が豊かな人生につながると思います。

#最近の若い人には難しいかもしれませんね。

戦略その1:授業の取り方

これらの観察を経て、授業の取り方を検討しました。ポイントは

  • 良いところはマネをする
  • 正面から喧嘩をしない
  • 勝てるところで勝負する

です。

まず、知識の構造を常にリファクタリングすることとゴールに合わせるの2点は採用しました。その上で自分の価値観は程々に、勝てるところで勝負しました。

具体的には、リファクタリングにつながると思われる課題(宿題)はきちんとこなしました。しかし、できる人には記憶力では負けていますので、リファクタリングしても雑多な記憶が求められる科目はあきらめました。

逆に、単位を取る事すら体力的に難しい科目は、学生さんは捨てると思われましたので積極的に取りました。大学の先生も単位が取れない学生ばかりではまずいので、必死になって付いていくと、意外と良い成績がもらえるのでした。

このように、戦略的に授業を受けた結果、単位数は少なかったですが、ほとんどの科目が優という予想以上の成績をいただく事ができました。

論文の書き方

論文の執筆も同じような戦略を取りました。論文誌(ジャーナル)に採録されるには完成度が求められますので、いわゆる「落としにくい論文」とされる「抜けのないきちんとした論文」が正攻法です。

このような論文を書くには問題設定が重要です。明確な問題があり、研究の成果が解決する。その2つがきちんと対応してなくてはなりません。そこでゴールに合わせるように、やった事を裏返して問題設定にする。という方法を考え出しました。

しかし、恩師曰く「確かにそうだが、シンプル過ぎても面白くない」とのこと。たしかにできる人の論文を読むと、シンプルな問題設定を重要なものであることを説明できる様に関連研究を充実させ、解決策だけでなく想定外の成果(発見)を示すという努力がされている様でした。

研究生活の短い人間には、このように立派な問題設定と発見は簡単ではありません。そこで、論文を別の方法で面白くする事を考えました。つまり、「落としにくい論文」ではなく「落としたくない論文」を目指しました。

具体的には、やった人でないとわからない事を書くように心がけました。再現するために必要な情報はもちろんの事、ツールの実装時の工夫、得られた結果の現場の人間としての評価を加えました。

これが意外とうまくいき、シンポジウムや国際会議だけでなく、論文誌にも採録されました。中でも、博士論文にも入れたrubyによるプログラムの分析ツールの論文(26枚目以降)は、翻訳までしていただいて海外論文誌にも紹介されました。

まとめ

このように、現状を分析して勝てるところで勝負する方法は、大きな効果が得られます。これはエンピリカルソフトウェア工学やPDCAサイクルによる改善、さらにはアダプタブルウォーターフォール開発にもつながるものです。

いま、目の前のプロジェクトをなんとかするなら、問題を明確にしてそれを解決するプラクティスを導入すべきです。今週末のXP祭り関西2013では、そのような視点でプラクティスを説明する予定です。

お申し込みは2013年4月26日までです。ぜひご参加ください(最後は告知ですみません)。

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