SQiPシンポジウムアブストラクト作成のポイント

Copyright © 2012 NTT DATA Corporation
ＳＱｉＰ２０１４投稿応援フォーラム
株式会社ＮＴＴデータ技術開発本部
大杉直樹
ＳＱｉＰシンポジウムアブストラクト作成のポイント
良い原稿を作る３つの要素、読み易い文章を作る５つのコツ
～実際に投稿したアブストラクトを示しながら～
２０１４年３月１４日（東京）、１７日（名古屋）

2Copyright © 2012 NTT DATA Corporation
投稿する × 旗を立てる

今日のアジェンダ
 投稿の種類
 募集テーマ
 準備するもの
 良い原稿を作る３つの要素
 ＳＱｉＰシンポジウムアブストラクト作成のポイント
 読み易い文章を作る５つのコツ
 一番大事なこと

だからお前は誰なんだよ
 名前：大杉直樹
 専門：ソフトウェア工学
（実証的ソフトウェア工学）
 経歴：
 2004年9月
 奈良先端科学技術大学院大学
博士後期課程修了
 2004年10月～2007年3月
 同大学特任助手
 2007年～現在
 株式会社ＮＴＴデータ技術開発本部勤務
 アクセス：
 Twitter: @ohsugi
 LinkedIn: www.linkedin.com/in/ohsugi

お約束
 本発表の内容は全て大杉直樹個人の見解であり、公式・非
公式を問わず所属組織の見解ではありません。
 実名で disりたい議論したいなら今日の講演で。
 匿名で disりたい議論したいなら twitter で直接大杉へ。
 派手に炎上すると会社員人生が＼(^o^)／ので、オンラインでの議
論では手加減を…

品質シンポジウム（ＳＱｉＰ）投稿の種類
 経験論文（論文）
 ソフトウェア品質に関する新たな提案、既存の方法・技術の実践などを
報告する論文。
 採録論文についてはさらに専門家がレビューし、論文の品質を改善す
るためのコメントが送付される。
 経験発表（パワーポイントスライド）
 実践活用事例、ノウハウなどをまとめた発表。現在取り組んでいる活動
の速報、問題提起などもＯＫ。
 スライド形式のプレゼンテーションのみでの投稿が可能。

募集テーマ
 要求やシステム開発などに関連した観点
 要求工学、要件管理、システム開発と業務改善、ベンダとの協調、保守・運用、SLA、
SLM、ITILなど。
 ソフトウェア開発技術の観点
 アジャイル開発、派生開発・プロダクトライン、形式手法、モデル検査、PSP/TSP、設
計品質、アーキテクチャ品質、コーディング規約など。
 マネジメント技術の観点
 オフショア開発、プロジェクトマネジメント、リスク管理、モチベーション・コミュニケーショ
ン、パートナーとの進め方、スキル・キャリア、人材育成、教育／トレーニング、小集団
活動など。
 品質管理・テスト技術の観点
 テスト技術、レビュー、デバッグ、プロセス改善、CMMI/ISO15504、監査、QMS構築、
構成管理、メトリクス、不具合管理、受け入れ検査、品質の定量的把握(予実管理・
EVM)など。

書くために準備するもの
 ネタ
 ソフトウェア品質に関して自慢したいこと！
 ソフトウェア品質に関するアイデア・技術・実践・ノウハウ。
 例：うちはレビューやテストを工夫してやっている。皆に自慢したい／意見を貰いた
い／同じ取り組みをしている人と議論したい。
 情熱
 ソフトウェア品質に関して伝えたい気持ち！
 目立ちたい、自慢したい、形にして残したい。
 時間
 ソフトウェア品質に関して体系化する時間！
 アイデア・技術・実践・ノウハウをいい感じに仕上げる。

良い原稿を作る３つの要素
1. ネタが美味しい
 多くの人が「美味しい！」と納得する王道食材。
 少数派だけど「美味しい！」とファンが絶賛する変化球食材。
2. ネタが新鮮
 メインフレームシステム新規構築のためのウォーターフォールモデルにお
ける品質管理について ⇒ 何年前の話やねん
 ＳＡＰアドオン開発のためのアジャイル品質管理について ⇒ 新鮮！
3. 産地表示
 そのネタは、いつ、誰が、どこで作り始めて、どういう風に育てられ、今
回発表するものは従来のものと何が違うのか。

例：コシヒカリＢＬ（Blast resistance Lines）
 1944年、新潟県農業試験場の高橋浩之により「農林22号」と「農林1
号」との交配により誕生。戦時下のため栽培中断。
 戦争終了後の1946年、仮谷桂と池隆肆が育種事業引き継ぎ。1947年
～1952年、石墨慶一郎と岡田正憲が福井の実験所で育成。
 1953年から、有望な種子系統である「越南17号」の適応性試験を20府
県で開始。1955年、新潟・千葉県の奨励品種となる。
 1956年、水稲農林100号「コシヒカリ」として命名登録。米の粘りが強く
食味に優れる品種であるが、栽培上は倒伏しやすい、いもち病などに弱い
などの欠点を持つ。
 コシヒカリBLは、いもち病に抵抗性を持つように改良された、コシヒカリを
親とする品種群。
via Wikipedia http://ja.wikipedia.org/wiki/コシヒカリ http://ja.wikipedia.org/wiki/コシヒカリBL

投稿する × 旅行する

ＳＱｉＰシンポジウムアブストラクト作成のポイント
 タイトル
 キーワード
 1. ねらい
 今回紹介する方法で、解決しようとする問題あるいは研究・開発の目
標・目的について記してください。
 2. 実施概要
 実施方法について工夫した点がわかるように概説してください。
 1で述べられた問題点を改善できることが分かるように記してください。
 3. 実施結果
 2の実施によって得られた効果について（できるかぎり具体的に）概説し
てください。
 4. 結論
 問題解決の度合い、今後の展開への期待などを主張してください。

「タイトル」の書き方
 嘘・大げさ・まぎらわしいは×
○ 軽量開発プロセスにおけるTracを用いたメトリクスの収集・蓄積・利用
× アジャイルプロセスにおける１００倍アジャイルなメトリクス環境
 短すぎない・大雑把すぎない
△ Tracを用いたメトリクスの収集・蓄積・利用
× メトリクスの収集・蓄積・利用
 長すぎない
× Wiki、SVN、IRCによるコミュニケーション非同期化による開発プロセスの
効率化と、Tracを用いたメトリクスの収集と蓄積、カスタムクエリの条件
検索による利用
 何かいい感じの言葉を入れるとさらに◎
△ 効率化プロセスにおけるTracを用いたメトリクスの収集・蓄積・利用

「キーワード」の書き方
 タイトルに入っていない関連用語を記述する。
 軽量開発プロセスにおけるTracを用いたメトリクスの収集・蓄積・利用
 計量開発プロセス、Trac、メトリクス ⇒ ×情報量が増えない
 バグ密度、生産性、見積り ⇒ ○情報量が増えた！
 何の分野の原稿なのか、代表的な用語を記述する。
 爆速効率化、メトリクス活用、Trac超利用 ⇒ ×なんの話やねん
 プロジェクト管理、品質管理、品質保証 ⇒ ○ああ、その分野の話ね

「1. ねらい」の書き方
 何についての発表か。
 なぜそれが問題・課題なのか。
 この発表でねらうことはなにか。
本稿では、開発要員20名未満の中小規模のエンタープライズシステム開発で用いられる軽量開発
プロセスにおいて、Tracでプロジェクト管理を実施する場合のメトリクスの収集と利用事例について述
べる。開発規模、工数、レビューやテストの量、発見したバグ数などのメトリクスを収集することで、シ
ステム開発における見積もり・進捗管理・品質管理などを系統的に実施できる。
一方で、信頼性の高いメトリクスを収集し、有効に実務利用するためには計測・蓄積ツールとルー
ルの準備、ルール遵守を担保する監視活動が必要であり、無視できない大きさのコストが必要となる
。多くの中小規模開発ではプロジェクト管理に割ける要員や工数が限られているため、メトリクスの収
集と利用に大きなコストを確保し難いという問題がある。本稿では、小さいコストでメトリクスを収集・蓄
積・利用した事例として、2つの社内システムの新規開発および維持保守開発におけるTracを用いた
メトリクスの収集と利用について述べる。
プロジェクトの体制や背景、用いたツールと実施手順、収集したメトリクスの分析結果や利用事例
紹介することで、同様の課題を抱えるプロジェクトの管理担当者に課題解決に向けた参考情報を提
供することがねらいである。
何についての発表か
なぜそれが問題・課題なのか
この発表でねらうことはなにか

「2. 実施概要」の書き方
 実際にやったことを Step by Step で書いていく。
 実践した結果や評価検証などについては「3. 実施結果」で書く。
 ここでは背景、準備作業、関係する文献やツールなどを書く。
主に次の点に留意して開発プロセス、計測ツール、ルールを準備し、可能な限り軽量化した開発
プロセスの中でも、小さいコストで現実的にメトリクスを収集・蓄積・利用できる環境を整備した。
Tracを開発プロセスの中心に置き、開発リーダ・作業担当者・レビュア・有識者間でTracのチケット
を取り回しながら開発を進めるプロセス（チケット駆動開発[1]で説明されているものと同様のプロセ
ス）を規定し、メトリクスがルール通りに計測・記入されていることを各種レビュー時に並行して監視し、
必要に応じて是正した。
収集するメトリクス（規模、工数、レビューやテストの量、各工程で発見したバグ数）を、全てTracの
カスタムフィールドで収集し、Tracのチケットとしてデータベースに蓄積した。
規模はオープンソースのStepCounter[2]、80行程度の自作バッチファイル、Microsoft Excelで計測
した。
ルールや手順書、議事録や技術情報はWiki、成果物はSubversion（SVN）、日々の雑談や詳細は
IRCを利用し、ルールや計測・利用手順の共有、ルール逸脱の是正指示なども席を動かずに実施
できる状態とした。
蓄積しているメトリクスはTracのカスタムクエリ機能を用いて条件検索し、CSV出力した検索結果を
Microsoft Excelに張り込むことでデータ集計できる状態とした。
集計したメトリクスは各週の進捗会議、各工程完了時の品質報告で必ず参照し、進捗・品質保証に
実際にやったことを Step by Step で
背景、準備作業、関係する文献やツール
引用した文献やツールは著者や出自を書きたい

「3. 実施結果」の書き方
 実際にやったことを Step by Step で書いていく。
 スペースの都合上数は限られるが、図表も入れると読み易い。
 実践や評価検証の結果を定量的なデータを併せて書く。
同様の開発プロセス、計測ツール、ルールを総規模40KS（ピーク時要員数4名）と240KS （20名）の
2つの社内システムの新規開発および維持保守開発で、のべ41ヶ月間運用し、工程毎の作業工数、
レビュー工数（人時）に加え、次のメトリクスを収集した。
ED/ID：レビュー頁数（頁）、指摘件数（件）
M/UT：追加変更規模（Step）、UT項目数
（項目）またはUT規模（Step）
IT： IT項目数（項目）またはIT規模（Step）、
ITバグ数（件）、すり抜けUTバグ数（件）
ST: ST項目数（項目）またはST規模（Step）、
STバグ数（件）、すり抜けUTバグ数（件）、
すり抜けITバグ数（件）
図 1に実施した開発プロセスのイメージを示す。画面追加、バグ修正、改善要望反映など、ひとま
とまりの開発内容を「案件」と呼び、案件単位で担当者へ作業をアサインした。案件毎に外部/内部
設計（ED/ID）、製造/単体テスト（M/UT）、結合テスト（IT）の各工程を実施し、複数案件をまとめたリ
リース単位で総合テスト（ST）を実施した。案件毎にチケットを発行し、さらに工程毎に発行したチ
ケットを開発リーダ・作業者・レビュア間で取り回して進捗と品質を管理した。STでは試験シナリオ毎
ITM/UTED/ID
案件1： A画面追加
案件2： B画面改善要望反映
開発要員I
案件3： B画面バグ修正
案件4： C画面バグ修正
開発要員II
案件5： C画面改善要望反映
案件6：移行ツール開発開発III
ST
案件7：次々バージョンリリース機能追加開発
移
行
作
業
次バージョンサービス開始
ITM/UTED/ID
ITM/UTED/ID
ITM/UTED/ID
ITM/UT
ITM/UTED/ID
ITM/UTED/ID
図 1. 開発プロセスのイメージ
実際にやったことを Step by Step で
図表も入れると読み易い
結果を定量的なデータを併せて書く

「4. 結論」の書き方
 書いたことのまとめや要点を再掲する。
 今後の課題、考察についても記述する。
 課題・他の実践・文献・研究との比較もあるとなおよい。
Tracを中心に置くことで、軽量開発プロセスにおいて現実的にメトリクスを収集・蓄積・利用できる環
境を整備できた。開発実施中にもルール、手順、ツールを継続的に改善し、メトリクス計測や利用に
要するコストを低減できた。
一方、導出して参照したメトリクスは、生産性、レビュー密度、テスト密度、バグ密度など、プロジェク
ト管理に最低限必要なものに留まっている。（1）工数・規模メトリクスから見積もりモデルを作成する
など、収集したメトリクスの計画時における利用促進、（2）サイクロマチック数、テストカバレッジ、コー
ドクローンなど、コードレビューやUT/ITレビューで観点としていたC0/C1網羅や、保守性低下防止を
担保する品質系メトリクスの利用が今後の課題である。
書いたことのまとめや要点の再掲
今後の課題、考察

投稿する × 共に競う

読み易い文章を作る５つのコツ
1. 正しいフォントを選ぶ
 文章は明朝体／Times系（Times New Romanなど）で。
 プレゼンテーションは Sans-serif系（Arial、Helveticaなど）で。
2. 段落の大きさを揃える
 段落に含まれる文の量をおよそ揃えて記述量のバランスをとる。
3. 段落の最初の文で一番大事なことを書く
 段落の最初の文を繋げて読むと、意味が通じるように。
4. ひとつの段落ではひとつのことだけを書く
 一番大事なこと→詳しい説明・理由・事例→付加情報・段落のまとめ
5. 段落同士が繋がって自然に流れるように
 段落の最後の文と、次の段落の最初の文が自然に繋がるように。

1. 正しいフォントを選ぶ
 原稿本文は明朝体／Times系（Times New Roman など）
 プレゼンテーションはゴシック／Sans-serif系（Arial など）
– Robin Williams（著）、吉川典秀（訳）、ノンデザイナーズ・デザインブック Second Edition、毎日コ
ミュニケーションズ、2004.
ＴｉｍｅｓＮｅｗＲｏｍａｎ
明朝体
ゴシック体

2. 段落の大きさを揃える
 段落に含まれる文の量をおよそ揃えて記述量のバランスをとる。
 書けることに限りあり。要点やストーリーに沿って取捨選択する。
段
落
の
記
述
量
を
お
よ
そ
揃
え
る

3. 段落の最初の文で一番大事なことを書く
 段落の最初の文を繋げて読むと、ひとつの自然な文章になって
意味が通じるように書く。
第１段落
第２段落
第３段落
第４段落
第５段落

4. ひとつの段落ではひとつのことだけを書く
 一番大事なこと（） → 詳しい説明・理由・事例（） → 付加
情報・段落のまとめ（）
第１段落
第２段落
第３段落
第４段落
第５段落

5. 段落同士が繋がって自然に流れるように
 段落の最後の文（か）と、次の段落の最初の文（）が
自然に繋がるように。
第１段落
第２段落
第３段落
第４段落
第５段落

一番大事なこと
まずは書いてみる。次に書いてみる。さらにどんどん書いてみる。
実は、あんまり深く考えないで、楽しんで書いてみる。
それが本当は一番大事で、本当は一番の近道です。

SQiPシンポジウムアブストラクト作成のポイント

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (7)

Similar to SQiPシンポジウムアブストラクト作成のポイント

Similar to SQiPシンポジウムアブストラクト作成のポイント (20)

SQiPシンポジウムアブストラクト作成のポイント