1. はじめに

ソフトウェア開発の現場では他の開発者とチームを組んで開発を進めることが当たり前となっています．そのため，単純なコーディングの記述だけでなく，マネジメント能力やコミュニケーションスキルといった様々な技術が昨今では求められるようになりつつあります．
ソフトウェア開発教育においても，PBL（Project Based Learning）など，学生がチームを組んで，実際にソフトウェア開発を行う形式の演習が多くの教育機関で実施されています（図1）．

一方で，チームによるソフトウェア開発演習には多くの課題が存在します．
P1. 品質の軽視
一般的なソフトウェア開発プロジェクトでは，品質，コスト，納期といった3種類の基準すべてを守ることが求められます．しかしながら教育としてのソフトウェア開発プロジェクトの多くでは，納期のみが重要視され，開発対象のソフトウェアはデモで動けばOKといったレベルのものになりがちです．実際のソフトウェア開発プロジェクトでは，実施されるべき様々な種類のタスクが存在します．開発対象の実装はもちろんですが，それ以外にもテストケースの実装や，レビュー（他の開発者が実装したソースコードを一定の基準に従って評価し，改善箇所の指摘を行うこと）等の品質保証のための活動を実施しなければいけません．しかしながら，多くのソフトウェア開発演習ではあまり考慮されていません．

P2．学生間における教育機会の不均衡
P1でも述べたとおり，ソフトウェア開発プロジェクトには様々な種類のタスクが存在します．品質保証のためのタスクを実施しないとしても，実装だけでなく，ユーザインタフェースデザインや成果物のプレゼンテーションからプロジェクトマネジメントなどは必ず行われる必要があります．ここで，一般的な（教育を目的としない）ソフトウェア開発プロジェクトでは，特定の種類のタスクしか実施しない開発者がいても問題にはなりません．しかしながら，教育を目的としたソフトウェア開発演習において，特定の学生が特定の種類のタスクしか実施しないということになると，学生が得られるはずだった教育機会の均衡を崩してしまうことに繋がります．過去に実際にあった事例ですと，ある学生が「私はコーディングが苦手なのでプレゼンだけ頑張ります．そのほうが開発がうまくいくので」と言ったことがありました．コーディングは人ごとに格差が大きくなりがちなスキルの一つです．実際にコーディングが苦手な学生が頑張って開発するより，コーディングが得意な学生が開発を行ったほうが明らかに開発は早く，うまく進むでしょう．しかし，その学生はチームでソフトウェアを開発・実装するという貴重な教育機会を得られなくなってしまいます．
我々はこのような課題を解決すべく，チームでのソフトウェア開発演習をどのように設計・運用するべきかについて研究を続けています．以降ではこれまでに実施したソフトウェア開発演習の成果を紹介していきます．

2. ソフトウェア品質や教育機会の均衡を考慮したチームソフトウェア開発演習

PBL等のチームソフトウェア開発演習では，教員が事前に必ずそのソフトウェア開発演習の目的を定めます．特定の開発技術の習得を目的としたものや，開発ではなく，プレゼン能力の向上を目的としたものなど，様々なものが実際に定められています．
我々はP1，P2で述べたような課題に取り組むにあたり，まずここで想定するチームソフトウェア開発演習の目的を以下のように定めました．

O1．演習で実施するソフトウェア開発プロジェクトでは，レビューやテストといった品質保証活動も含めたタスクの遂行が適正に(定められたルールに従って)行われること
O2．学生が様々な種類のタスクを経験できるようにすること

以降ではこれらの目的に従って，どのようにソフトウェア開発演習を実施しているか説明していきます．

3. 開発ルールの策定と記録

図2は我々が策定した開発ルールの一部です．開発対象のソフトウェアはそのソースコードの作成だけでなく，テストコードの作成・実施やレビューが必ず行われるべきであることを明記しています．我々はこのルールを策定し，さらに実際に書くタスクが適正に行われているかを教員が把握できるようにするために，タスクを記録するシステムを導入しました．

我々はTracと呼ばれるツールを我々のソフトウェア開発演習のためにカスタマイズしています．このツールは開発を進めていく際に，どのような種類のタスクをいつからいつまで，どの程度の時間をかけて実施したのか記録していくことを目的としています．教員は記録されたタスクを分析し，行うべきタスクが正しくルールに則って実施されているか確認することができます．

4.プロジェクト評価基準の策定

上でも述べたとおり，一般的なソフトウェア開発プロジェクトでは，品質，コスト，納期の基準を守る必要があります．我々はチームソフトウェア開発演習を進めるにあたり，品質，納期，タスク割り当て，という3つの基準を策定しました．ここで品質は前節で述べたルールに従って開発が行われており，それが正しく記録されているか，完成したソフトウェアが一定の品質評価基準をクリアしているかを表します．納期は開発が完了しているべき締め切りです．これら2つについては一般的なソフトウェア開発プロジェクトものと同等になっています．
最後のタスク割り当ては我々独自の評価基準になっています．具体的には，コーディングやテスト，レビューといった種類のタスクについて，チームメンバ全員が均等に実施・経験で来ているかを評価するための基準です．

図3はある年に実施したチームソフトウェア開発演習におけるタスク割り当ての状況をグラフ化したものです．このデータは上で述べたタスク記録システムから取得したものです．左がTeam7，右がTeam3の状況を示しています．横軸が開発期間を表しており，ソフトウェア開発が5回に分けて行われたことを示しています．縦軸はM31~M36,M71~M75が示す各学生があるタスクをそれぞれ何回実施したかを表しています．このグラフを見る限り，Team3のほうが各メンバが担当するタスクの数が等しい，すなわち均等にタスクを分担できていることが分かります．

このように開発ルールを明文化し，新しいプロジェクト評価基準を取り入れてソフトウェア開発演習を実施することで，品質の軽視や教育機会の偏りといった問題を改善できることが確認できました．

5. おわりに

図1は研究室で実際にチーム開発を行っている風景です．壁には誰がどのタスクを実施しているかを示す付箋が貼られており，学生らは学年の垣根なく協力し合い，相談をしながら様々な開発を進めています．当研究室では今後もチームでのソフトウェア開発を主眼に，社会に出て役に立つエンジニア育成のためのチームソフトウェア開発教育手法について研究を進めていく予定です．