35
36
表 10 各ミーティングでの実施内容
ミーティングの種類 実施内容 キックオフ
ミーティング
1. 割り振られた担当機能について優先度を設定する 2. 優先度が高い順番に2週間単位のタスクを割り当てる デイリー
スクラム
1. 進捗報告 2. 問題・課題報告 スプリント計画
ミーティング
1. 前スプリントでできた機能へのフィードバック
2. 2週間単位のチケットの詳細化(スプリントバックログ) 非定例
ミーティング
問題・課題報告について挙げられた事柄について対策及びリソースを割 り当てる
7.2 スケジュールの計画と推移
ここでは筆者の計画とその推移について述べる。図 24に開発スケジュールの計画と実績、
マイルストンを示す。
図 24 開発のスケジュール
外部設計を最初に行い、機能ごとに実装を行った。実装と書かれている部分には実装のほ かに簡単な動作テスト、使用後のフィードバックおよび修正が含まれており、機能単位でシ ステムを作っていった。
実装が早く終了したためテスト仕様に基づいた試験を早めに挟むことで品質の向上を図り、
使用性向上のためのデザイン変更やリファクタリングおよび変更に伴う試験を行った。次に、
コムドアカスタマイズが伸びたのは音声通信部分によるシステムトラブルが起こったためで あり、実行環境を変えることで解決した。次に、システム結合/試験の開始が遅れたのは、シ ステム準備が整っていなかったためである。このことに対して、アーキテクチャの変更が生 じたが、試験において品質要件を満たしていることを確認できた。
37
7.3 開発の振り返り
本プロジェクトの開発では、外部設計以降、機能で担当を決めて進めている。そのため、
お互いの接点が尐なくなり、他メンバの進捗や課題を把握することは難しい。そのような状 況においてデイリースクラムの効果は大きく、他メンバが現在何をやっているか分からない という状況は発生しなかった。さらに、スクラムに遵守した形で担当箇所の課題は自分で処 理する方針であったが、他メンバの活動内容の共有ができているため、他メンバの抱える課 題へのアドバイスや解決法の相談がスムーズに行うことができた。また、Tele Scouterで動 作するソフトウェアは、文献が尐なく実際に作って動かしてみないと分からない状況にあり、
NEC への技術的な問い合わせが待ちタスクになることが大きなリスクであった。しかし、
毎日の進捗確認の中で待ちの間で何ができるか動的にタスクを考えられたことで、結局作っ てみたが、動作しなかったなどの作業のオーバーヘッドはあったものの、何もできるタスク がない状態を防ぐことができた。
毎日行うスクラムミーティングでは、やり方を形式化したことにより短時間で効率的に行 うことができた。しかし、スプリント計画ミーティングがうまく機能しておらず、スプリン ト毎にできあがる成果物に対して十分なフィードバックを得る機会が尐なかった。原因とし ては、急な問題の発生や遅れ等により、スプリントのリズムが崩れたためだと考えられる。
このことに対して、余裕を持ったスプリント計画を行うことや、状況によらず期間内に必ず スプリントを締めることが必要であったと考えられる。
メールベースで NEC の方とほぼ毎日やりとりを行うことで、チーム内で解決できること なのか、技術的なサポートが必要なのかを早期に判断することができ、致命的な遅延を防ぐ ことができた。ただ、複数のメンバが自分に関係する部分について、それぞれ問い合わせを 行っており、その対応で負担をかけてしまったため、問い合わせ内容を整理し担当者を立て て行う必要があったと考える。
38