このプロジェクト実施当時59歳のプロジェクト・マネージャーの気づきです。
59歳にして初めてAgile開発で実施したプロジェクトのマネージャーです。

誤解をしていた”ペアプログラミング”
一人での作業だと、考えながらコード化する為、時間が掛る。
ペアプログラミングではナビゲータとドライバという位置づけでの
作業の為、考える時間が無く、ナビゲータは次の指示を事前に準備
する作業となるので更に無駄が無い。
ソースコード検証を行いながらの実装となるので、品質が確保出来た。
その為、仕様書作成＋レビュー＋ＰＧ開発＋単体テスト＋連結テスト
まで考慮すると、品質を確保出来て３～４倍の開発スピードが実現出来た。
また、タスク単位或いは午前・午後単位にペアを組み替える事で
設計共用が簡単に行え、コード実装を行いながら設計共用が出来た。
一部のメンバーは他のプロジェクトを抱え、１週間のうち１～２日は
必ず抜けるのですが、戻った時点でペアプログラミングに参加する為
１日以内には同期化の遅れを取り戻せる事が実感出来た。

”タスクの洗い出し”と”スタンドアップミーティング”
タスクの単位を３０分、１時間、２時間、４時間に決め、出来る限り実装を想定した。
タスクにする様、スタンドアップミーティングのたびに話し合った。
前日の実装と今日行う実装と、どうペアを組むかを毎日一人ひとりが
発言する事で、頭の中が整理されていく様が日を追う毎に分かった。
自然に『タスクの粒度が粗い』とか、『実装しにくいタスク』と云う
会話が出始めた事も事実です。
それは何故かというと、タスクを記入した人と、実装する人が違うからです。
”Todo”のタスクを誰が実装するかは、”皆で取り合う”作業を
するからで、だから実装しやすいタスクにする事が当たり前になります。
　
目で見る管理
最初スケジュール表をアローダイヤグラムで表し管理しようとしたのですが
タスクを”Todo”、”実行中”、”完了”に分け場所移動を行うと現在何を抱え、
何が完了しているのかが一目瞭然となったので、確実にタスク（ポストイット）を
移動する事でスケジュール表は必要無くなった。
さらに、**『タスクが洗えないとソースコードが書けない』**と云う言葉
までが出る様になった。

リズムと会話の実行
開発場所は静かで黙々と仕事をする既成概念があるが、それはタブーとした。
静かとは

ナビゲータが仕事をしていない
ペアプログラミングがうまくいっていない
設計共有していない

と云う心配があるからです。
休憩時間も基本を５０分開発、１０分休憩のリズムを保つ様心掛けました。
しかしそれは強制ではなくチーム内での話し合いで決めました。

チーム内の信頼感
人は好き嫌いがあり、合う人、合わない人が居ると思いますが、チームに
”和”が出来上がると、目的（目標）が共通な事もあるのか、個人の優れた
ものを分かち合おうと云う雰囲気が芽生えてくる事も実感出来ました。
これは『同じ釜の飯を食う仲間』と言われている事に近いものが有る様な気がします。
得意・不得意を見極め優しさを持って仕事をしているんだなぁと実感しました。

変化を恐れない勇気
今までの経験の中で、開発途中でＤＢ構造の変更依頼や、仕様変更といった
ものを口にすると、決まって『今頃何を言っている』、『設計の責任で解決
しろ』みたいな会話が飛び交うのですが、”設計の共用”と言う事が問題点を
スムーズに解決出来る事に気が付きました。
ＰＧと云う立場では無く、ＳＥ・ＰＧの意識と全員が知っているという恐怖感
の無さがそうさせているのかも知れません。
画面の変更・ＤＢ構造の変更・アルゴリズムの変更…等、
ユーザーから戻って、変更内容をまとめ、翌日ミーティング後に説明をすると、
すぐさまタスク出しを行い、”Todo"に貼り付け、今まで有ったタスクと同期化
している様を見ると不思議な気さえします。