【第54回 プログラミング・シンポジウム 発表資料 7-2】 Many new software development methods such as agile and iterative development require closer communication among developers compared to traditional ones. However today, many IT engineers are not good at communicating with others. Therefore, we are developing software engineer education curriculum with enhancement of communication skills (more specifically, consensus-building skills) in mind. We are adopting case-centered methods, in which both software development process and importance of consensus can be understood through actual experiences. For evaluation, we have applied our educational case method to six computer science undergraduates, composed in two groups of three persons each. As the result, consensus-building workshop in our curriculum was effective in achieving closer communication. 近年、アジャイルや反復開発など緊密なコミュニケーションを前提とする開発手法が普及してきている。しかし、他者とのコミュニケーションを拒むソフトウェア技術者の存在をはじめ、現在 のソフトウェア業界ではコミュニケーションスキルの向上は必ずしも実現されていない。そこで筆者らは、新人に対しコミュニケーションスキル、特に合意形成スキルを重視した技術者教育を行うことが重要だと考え、教育手法を設計・試行している。具体的には、開発プロセスをこなす中で合意形成の重要性を体験できるような、ケース中心の教育手法を採用している。その検証のため、大学4年生6名に集まってもらい、それぞれ3名のグループに分かれ、ケースを基に開発を進める実験を行った。その結果、コンセンサスを体感するワークショップを行う事で、コミュニケーションをより密にする開発を行う事が出来ることを確認した。

1. コミュニケーションスキルを重視した
ソフトウェア技術者教育手法の研究
斎藤 祐一郎・久野 靖
筑波大学 ビジネス科学研究科 経営システム科学専攻
2013/1/13
斎藤・久野 (筑波大学) 2013/1/13 1 / 38

2. はじめに
ソフトウェア開発とコミュニケーション
コミュニケーション 大切！
※この後、コミュニケーションは「 c 」と略す。
• ソフトウェア開発は チームプレー
• チームメンバーとの c が必ずある。
でも…
斎藤・久野 (筑波大学) 2013/1/13 2 / 38

3. はじめに
ソフトウェア開発とコミュニケーション
現状
• c が苦手なソフトウェア開発の技術者
(以下、技術者) の存在。
• c が不得手な新人技術者。
c が出来ている人とそうでない人の差はどこ？
• どのような方法で c を学べばいいのだろうか。
• 新入社員として 働く前に解決 できないのか？
斎藤・久野 (筑波大学) 2013/1/13 3 / 38

4. はじめに
ソフトウェア開発とコミュニケーション
私の経験した できごと
• できるものが違う
— 「そう言われたんでこう作りました。 」
• チームワークの意識が希薄
— 「それとこれ、結合できるよう調整したの？」
• 自身の知識に固執する
— 「なんだ聞いてくれれば良いのに。」
• 他者の境遇を理解しない
— 「はぁ？そんな事も知らないんですか。 」
斎藤・久野 (筑波大学) 2013/1/13 4 / 38

5. はじめに
ソフトウェア開発とコミュニケーション
開発プロセスとコミュニケーション
• 成果物を基に c が発生する。
Figure: コミュニケーションの流れ
• ウォーターフォールでも、アジャイルでも、
c が必要 なのは変わらない。
斎藤・久野 (筑波大学) 2013/1/13 5 / 38

6. はじめに
本研究について
本研究について
ソフトウェア開発に必要な「コミュニケーション」
を学ぶ教育を試行
• チームメンバー同士が
成果物をもとにインタラクション を行う。
• ケースを通じ、実践を通じて学習する実験を行う。
• 事前指導の有無から効果を比較する。
斎藤・久野 (筑波大学) 2013/1/13 6 / 38

7. はじめに
本研究について
大切な事なので二回言います
ソフトウェア開発に必要な
「コミュニケーション」は
成果物をもとにインタラクション を行うこと
• ≠とっても分かりやすく聞こえる話
• ≠リア充 (合コン・笑いを引き出せる話)
• ≠ゴマすり (ええこと言っちゃう！)
斎藤・久野 (筑波大学) 2013/1/13 7 / 38

8. 教育カリキュラム作成の基本方針
新人教育における目標と重視する内容
新人教育における目標と重視する内容 - 1
• Katz が述べている
「管理者に必要な 3 つのコアスキル」をもとに…
• テクニカルスキル
• 技術的な事項を理解 — プログラミング・設計
• ヒューマンスキル
• 対人活動を円滑に進める — c スキル
• コンセプチュアルスキル
• 全体像を把握し新しい体系を構築 — 標準化・体系化
斎藤・久野 (筑波大学) 2013/1/13 8 / 38

9. 教育カリキュラム作成の基本方針
新人教育における目標と重視する内容
新人教育における目標と重視する内容 - 2
• c スキルとして必要な 3 つの軸を設定
• ステークホルダーの 役割分担を理解 し業務に結
びつけている
• ステークホルダーに自らの プレゼンスが理解され
業務で活かされている
• 人に頼る部分・自らが関与する部分を 切り分け
ながら c を行える
斎藤・久野 (筑波大学) 2013/1/13 9 / 38

10. 教育カリキュラム作成の基本方針
教育方法
教育方法の検討
• 「ケースメソッド」を
採用。
• 仮想の開発プロジェクト
を作成。
• ロールプレイングの要素
も取り入れる。
• 役割分担 を設定。メン
バー間の c が期待で
きる。
Figure: 検討した教育方法と
分布
斎藤・久野 (筑波大学) 2013/1/13 10 / 38

11. 教育カリキュラム作成の基本方針
ケースメソッドの進め方
どのようにケースが進むのか？
(1) ガイダンス — 筆者から進め方の説明
(2) ケースの読解 — 被験者がケースを理解
(3) 作業の実施 — 被験者が開発
(4) プレゼンテーション — 被験者が説明
(5) 振り返り — 被験者が獲得したスキルの確認
斎藤・久野 (筑波大学) 2013/1/13 11 / 38

12. 実験実施計画
被験者及び実験工程の選定
被験者及び実験工程の選定
• 被験者 — 2 大学 合計 6 名の学生が参加
• ケースメソッドの実施期間 — 1 週間
• 事前指導の有無で c スキル獲得状況が変わるか？
日程 所要時間 第1回 第2回 作業内容
開始前 30 分 × ○ 事前指導
1 日目 1∼2 時間 ○ ○ コンセプト作成・外部設計
2 日目 1∼2 時間 ○ ○ 外部設計
3 日目 1∼2 時間 ○ ○ 内部設計
4 日目 1∼2 時間 ○ ○ 内部設計・画面設計
5 日目 1∼2 時間 ○ ○ テスト計画・リソース制作
6 日目 1∼2 時間 ○ ○ ・テストプログラム試作
7 日目 6 時間 ○ ○ プログラム開発・テスト実施
斎藤・久野 (筑波大学) 2013/1/13 12 / 38

13. 実験実施計画
ケースの作成
ケースの作成
— 「Twitter の mash-up サイトを作ろう」
• mention の流れを見やすくするツールを開発。
• ケース作成時に留意した事項は次の 5 点。
1. 普段慣れ親しんだものを利用する
2. 7 日間で形に出来る
3. 役割分担を作る
4. 工程を設定する
5. 能動的に楽しめる
斎藤・久野 (筑波大学) 2013/1/13 13 / 38

14. 実験実施計画
成果物の定義
成果物の定義
• 成果物とその提出日を次の通りに定義した。
日程 成果物
第1回 選択したプラットフォームの情報
(2 日目) コンセプトのメモ
作業分担リスト
外部設計の図面
第2回 機能設計書
(4 日目) 画面遷移図
画面設計図
第3回 テスト計画書
(6 日目)
最終回 完成品のプレゼンテーション
(7 日目) ソースコード
テスト結果が記入されたテスト計画書
斎藤・久野 (筑波大学) 2013/1/13 14 / 38

15. 実験実施計画
評価のための準備
評価のための準備
• 3 つの方法を準備。
(a) アンケート
(b) SYMLOG
(c) ビデオ撮影 — 分析中
• SYMLOG は、集団構造分析を行う。3 つの軸「友
好度」 「冷静さ」そして「リーダーシップ」の水
準を定量化する。
• SYMLOG の採点は、今回は筆者が実施している。
斎藤・久野 (筑波大学) 2013/1/13 15 / 38

16. 第 1 回実験
第 1 回実験 概要
• 被験者
国立α大学 情報系学科所属 大学 4 年生 3 名
• 日時
2012/09/16∼2012/09/22 (7 日間)
• 場所
1∼6 日目は被験者の大学・自宅
7 日目は筑波大学 東京キャンパス
斎藤・久野 (筑波大学) 2013/1/13 16 / 38

17. 第 1 回実験
被験者 プロフィール
被験者 プロフィール
• 事前アンケートから得た情報をもとにまとめる。
• A — プログラム担当
個人的にもコードを書く経験をしている。
• B — デザイン担当
チームをリラックスした雰囲気にしたい。
• C — リーダー・テスト担当
当初よりリーダーを希望していた。
斎藤・久野 (筑波大学) 2013/1/13 17 / 38

18. 第 1 回実験
実験中の状況
実験中の状況
• 1∼6 日目 — 課題は滞りなく提出を受けた。
• 7 日目 — 次のスケジュールで作業が進む。
時刻 作業内容
10:30∼10:45 本日の作業の流れの整理
10:45∼12:30 各自 担当作業
12:30∼13:30 昼食
13:30∼15:00 各自 担当作業
15:00∼15:50 プログラム・画面 結合作業
15:50∼16:00 問題点の整理
16:00∼16:40 プログラム・画面 結合作業
16:40∼17:00 問題点の整理
17:00∼19:50 プログラム・画面 結合作業
19:50∼20:00 作業結果確認 ソフトウェアの内容のプレゼンテーション
斎藤・久野 (筑波大学) 2013/1/13 18 / 38

19. 第 1 回実験
完成品のスクリーンショット
完成品のスクリーンショット
斎藤・久野 (筑波大学) 2013/1/13 19 / 38

20. 第 1 回実験
7 日目の状況
7 日目の状況
前半
• 全員、冷静。静かに続く作業。
• ほぼ出来上がっているけど、会話がなくて大
丈夫？
後半
• 結合がうまく行かない事がわかってきた。
• プログラマに負荷が集中。他の人、手を出せず。
• プログラマ、テンパる。髪の毛ぼさぼさ、参っ
た感。
斎藤・久野 (筑波大学) 2013/1/13 20 / 38

21. 第 1 回実験
アンケート結果
実験前後のアンケート結果比較
• 実験前
• c : 周りの邪魔をしない。
• 開発: UI を作ってから機能は後から盛り込む。
• 実験後
• c : 技術部分の理解を共有できなかった。
• 開発: 自分が考えている事と相手が考えている事に
相違があるとプログラムは結合できない。
実験後 c の重要性に気づいている
斎藤・久野 (筑波大学) 2013/1/13 21 / 38

22. 第 1 回実験
SYMLOG
SYMLOG
• 後半、被験者 A の冷静さが失われていく点に注目。
Figure: 7 日目 前半 Figure: 7 日目 後半
斎藤・久野 (筑波大学) 2013/1/13 22 / 38

23. 第 1 回実験
結果の評価
結果の評価
• ヒューマンスキル
• 理解度合いの齟齬 — c を通じ実装をすりあわせる必
要があった
• 合意形成の機会が少ない — 進捗確認の遅れ
• テクニカルスキル
• 企画・デバッグ力の向上
• コンセプチュアルスキル
• 能動的な情報収集力の向上
斎藤・久野 (筑波大学) 2013/1/13 23 / 38

24. 第 2 回実験
第 2 回実験 概要
• 被験者
国立β大学 情報系学科所属 大学 4 年生 3 名
• 日時
2012/10/14∼2012/10/20 (7 日間)
• 場所
1∼6 日目は被験者の大学・自宅
7 日目は筑波大学 東京キャンパス
斎藤・久野 (筑波大学) 2013/1/13 24 / 38

25. 第 2 回実験
事前指導の追加
事前指導の追加
• 1 回目の実験を踏まえて —
問題の理解度合いの齟齬を埋める
• 課題は —
「インターネットブラウザに必要な機能を挙げる」
• 自分と人との「必要」の認識は 違う 事を知り、
c の重要性を知る。
斎藤・久野 (筑波大学) 2013/1/13 25 / 38

26. 第 2 回実験
事前指導の状況
事前指導の状況
• オリエンテーション時 時間 作業内容
に実施。 19:00∼19:20 (全体像説明)
19:20∼10:35 必要な機能を各個人で列
• 「必要」の理解が人そ 挙
19:35∼19:40 全員の情報を集めて共通
れぞれであり、かつ 部分とそうではない部分
c を通じて仲間の考え 19:40∼19:47
を分類
共通しなかった部分から
を理解する。その上 1 つを選び選択理由を考
える
で、結論を導く。 19:47∼19:50 選択した項目についてプ
レゼンテーションを行う
19:50∼21:00 (実験に関する説明)
斎藤・久野 (筑波大学) 2013/1/13 26 / 38

27. 第 2 回実験
被験者 プロフィール
被験者 プロフィール
• 事前アンケートから得た情報をもとにまとめる。
• X — プログラム担当
チーム内で最もプログラミングスキルがある
• Y — デザイン担当
研究でも UI について取り組んでいる
• Z — リーダー・テスト担当
当初よりメンバー集めに積極的 技術の知見もメン
バー随一
斎藤・久野 (筑波大学) 2013/1/13 27 / 38

28. 第 2 回実験
実験中の状況
実験中の状況
• 1∼6 日目 — 課題は滞りなく提出を受けた。
• 7 日目 — 1 回目に比べて c が積極的に行われた。
時刻 作業内容
11:10∼12:30 技術調査
12:20∼12:30 調査状況 共有
12:30∼13:30 技術調査・プログラミング
13:00∼13:10 作業進捗 共有
(13:20∼13:40) 昼食・技術調査・プログラミング
13:40∼13:50 調査状況 共有
13:50∼15:00 技術調査・プログラミング
15:00∼15:15 作業進捗 共有
15:15∼16:30 技術調査・プログラミング
16:30∼16:55 作業進捗 共有
16:55∼17:00 問題点の整理
17:00∼18:20 本日の作業を踏まえ設計資料の更新
18:20∼18:30 作業結果確認 ソフトウェアの内容のプレゼンテーション
斎藤・久野 (筑波大学) 2013/1/13 28 / 38

29. 第 2 回実験
完成品のスクリーンショット
完成品のスクリーンショット
斎藤・久野 (筑波大学) 2013/1/13 29 / 38

30. 第 2 回実験
7 日目の状況
7 日目の状況
前半
• わからない事、知りたい事、積極的に会話。
• 段取りも初めに計画して予定通り進行。
後半
• .oO ○「やっぱり技術を学ぶ事は大切だね…」
• 問題を一つずつ潰さず、別の方にそれてしまい結
局進まない。
• モティベーションは最後まで持続。
斎藤・久野 (筑波大学) 2013/1/13 30 / 38

31. 第 2 回実験
アンケート結果
実験前後のアンケート結果比較
• 実験前
• c : 進捗を常に把握、質問しやすい状態にする、一緒
に考える、積極的に声がけする。
• 開発: ひな形を作り、動きを考えながら機能を追加。
• 実験後
• c : 声がけすることで互いの状況を把握できた。
• 開発: 設計の段階で話し合っておく事で、作業の流れ
がはっきりし、マンネリ化しづらくなる。緊張感も高
まる。
斎藤・久野 (筑波大学) 2013/1/13 31 / 38

32. 第 2 回実験
SYMLOG
SYMLOG
• 全被験者、チームワークを維持。
Figure: 7 日目 前半 Figure: 7 日目 後半
斎藤・久野 (筑波大学) 2013/1/13 32 / 38

33. 第 2 回実験
結果の評価
結果の評価
• ヒューマンスキル
• 頻繁な状況確認 — 事前指導の効果を確認
• テクニカルスキル
• 技術調査が不充分
• 実装時の 基礎知識が不足
• コンセプチュアルスキル
• Z の積極性が際立つ
• 一方 後半の問題解決方法に問題
斎藤・久野 (筑波大学) 2013/1/13 33 / 38

34. まとめ
まとめ
• 成果物を基にした c が欠かせない。
• c スキルは後天的に育成可能。
• プログラミングを学んだ上での教育が効果的。
• 今後、工程毎に必要な c を分析するなど、より教
育効果を高めるための実験が必要。
斎藤・久野 (筑波大学) 2013/1/13 34 / 38