寝ても覚めても.NET（？）

ＧＷを迎える直前の最終日、スプリント２のスプリントレビューが終了しました。
見事にＰＯ判断でリリースＮＧですｗｗｗ
少々（？）残念ではありますが、お互い様的な理由がある程度明確なので心置きなくＧＷを迎えようと思います。

-------- と書いていたのが4/27の深夜・・・
その後、ウイルス性感染症なるものに発症して悪夢のようなGWを迎えることになろうとは・・・。


さて、4/13のTFSUGにてアジャイルを始めるまでの経緯を短い時間で話してみましたが、
その後スプリント１、スプリント２を終えて今の感想をまとめてみたいと思います。

我々のスプリントはまぁ右も左もよくわからないままに半ば強行突入的に始まりました。
外部要因を排除することができず、他チームのための共通部品を早急に作らなければいけないというおまけつきで。


・前置き
以前からの続きとなっております。
この辺「TFS de アジャイル」とか
この辺「第5回TFSUG TFS de アジャイルを書いたわけ～WFからアジャイルへの変革～」とか
とかの続きの内容です。


・序章
初めてのスプリント計画ミーティングを迎える前にバックロググルーミングらしきものを行いました。
まぁとりあえずバックログがないと何も始まらないらしいということで。
フォーマットとしては「誰がなんのために何をするか」ということなのでまぁその辺を中心に洗い出しました。
（今思えば）FeatureというよりはFunctionというレベルかな？というぐらい細かい感じでしたが、
そのときはそんなことにはあまり気づかず。まぁできたねという感じでした。


・スプリント１
やらなければいけないことは冒頭にでてきた他チームのための共通部品の作成と作成したバックログのうち優先順位の高いものをいくつか。
というのがぼんやりと見えている感じで初めてのスプリント計画ミーティング第一部に突入です。
第一部では
・バックログの詳細を確認して、
・受け入れ基準が増えるようなら追加する、
・プランニングポーカーなどをして相対見積もりを行い、
・チームがこなせるバックログについてＰＯと合意する
という感じでしょうか。

ＰＯ自身もアジャイル／スクラムは初経験なので当然バックログの受け入れ基準は決まっていません。
上から順番に確認していくと、まぁ細かい仕様の話に落ちる落ちる。
ただ、ここで難しいと感じたのはバックログの受け入れ基準はＰＯが決定するということ。
ＰＯが言うことが全てだというのは正しくもあり危なくもあり。
開発チームの質問そのものであったり、ＰＯの意識であったリが要求ではなくシステムの振る舞い（＝仕様）にいってしまうと
ただ言われたとおりに作るだけになってしまう。
かといって、ＰＯの言っていることを無視すれば本来作るべきものとはかけ離れたものになってしまう。
というあたりでのバランスのむずかしさみたいなものを痛感しました。
理想的にはＰＯは、抱えている問題や実現したいことを示し、開発チームはそれはこうすれば実現できるという提案を行う
というバランスになるのかな～という感じですが、これを実践するのは相当に難しいという印象です。

もうひとつは合意する量について。
もちろん初めてなので自分たちがどれくらいこなせるかというのはよくわかっていません。
こういうとき、往々にして頭の中には必殺技の”逆線表”と言われるものが引かれます。
いつまでにこんだけ終わらせないといけないから今回はここまで終わらせてないとまずい、みたいなあれです。
とある人はものすごい量のバックログにアサインしなければいけないといい、
ある人は２～３個やったらキャパオーバーするはずだといい、なかなかに堂々巡りしました（ちなみにこの時点でポーカーはまだしていませんｗ）
結局、いろんな思いが中途半端なままに受け入れ基準を確認できたいくつかを数個対象にしてみることにしました。
（ここは打ち合わせのタイムボックスによって強制的に終了時間になったので終わるか終らないかは知らないけどエイヤでいってみた感じです）

そんなこんなでとりあえず第一部終了。

次はスプリント計画ミーティング第二部
第二部では
・ＰＯと合意したバックログをタスクに分解する
・タスクの作業時間を見積もる
・合計量がチームのキャパシティに収まっているか確認する
・収まっていなければ優先順位の低いほうから外す（少なかったら次のバックログを入れ込むのかな？）
という感じでしょうか。

よくわからないので、とにかくやらなきゃいけなさそうなことをバックログ単位で洗い出していきます。
幸いにもプログラムを作っていくというところに関してはそれなりに慣れているので、
感だとしてもそれなりにそれっぽい感じでタスクが洗い出されていきました。
この点はちゃんとプログラムを各部分に携わっているメンバーであればあまり心配はいらないのかなという感じです。
実質、タスクの洗い出しそのもので意見が割れるということはあまりなかった感じです。

我々のチームはタスクの見積もりを２点見積りで行うことにしました。
外的要因がすべてクリアされていて全力で走れた場合、自分のスキルや仕様の不明瞭その他外的要因などにより時間がかかる場合の２つを想定し
見積もり時間を洗い出していきました。
が、実質は全力で走り切れた場合の時間とその２倍の時間というなんとも定型的な状態にはなってしまいました。
この点は、チームとして経験を積んでいくことで２地点間の距離が短くなっていくのだろうと信じてはいます。

見積もり完了時点で理想的な時間だと１週間くらい、遅い時間だと２週間くらいで終わりそうな量があるということが判明し、
いったんこれで行ってみようということになりました。

問題はここまで来るのに相当な時間を要し（一部スタートから４時間とか５時間とか）
タスクの洗い出しと見積もりに関しても予定していた量の半分～４分の３くらいしかできなかったということ。
何をするにも初めは時間がかかるとは思うものの、一個一個について細かくやりすぎているのか、
そうしなければいけないほどに準備が不足しているのかといった問題を抱えているということをよく認識しました。

また、当初は相当量のバックログをやらなければいけないといっていたものが、第一部で数個しか話せなかったのでそれを対象とすることにし、
さらにタスク見積もりではそのすべてをこなせなかったにも関わらず、タスクの残存時間はすでにキャパシティーに迫っているっぽいという事実。
やらずに議論するということが大事な局面も多々あると信じて疑いませんが、それが空中戦となるようであれば
実際にちょっとやってみたほうがいいらしいぞということを改めて痛感する１日となりました。


で、これ結論から行くと２週間やっても終わりませんでしたｗ
要因は数え上げればきりがないですが、事実として当初言ってた量と実際できた量との驚くべきかい離に唖然とするばかりでした。


スプリント中はこれまたいろいろと楽しいことが起こります。
TFSUGセミナーでも紹介したとおりのことも含みますが、まずメンバーのスキル差というものが如実に表れてきます。
テクニカルな部分では、考えてもちんぷんかんぷんで結局頼りっきりになってしまう最底辺からどんどん進めていく人まで。
ヒューマンな部分では、とっとと聞きにいけばいいものを、あーでもないこーでもないと悩んでしまってフリーズする最底辺から
いろんな関係者にがつがつ突っ込んで行ってどんどん解決していく人まで。
ペアプロだったりペアプロもどきだったりをしてカバーしていく体制をとりましたが、自分たちとしてはあまり効率はよくなかった感じです。
実作業を集中的にこなす人とその人数よりも少ない人数で構成された集中して作業してもらうためのありとあらゆる問題を解決していく人
という体制（これは我々チームの普段の体制）のほうが、慣れていることもあり共有と効率を効果的に発揮していた感じがします。
体制的にはこれでいいんですが、そもそもこういう風にとらえる（見える？）根本の原因として
「チームで考え、チームで解決していく。もっと落とし込んで自分自身で考え、自分自身で解決していく」
という部分が「組織構造上のリーダーに頼らない」という解釈になってしまっている部分もあり、
リーダー側はCommand and Control型になることを恐れて積極的な決定や指示を行なわない、
一方、今まで指示を受ける側だったほうはいざ自分でやろうとしてもまったくうまくいかないことに苦悩する
というところで結局チームが止まってしまうという雰囲気を醸し出していたような気がします。

ユニットテストを行うことにこだわりすぎたという問題もありました。
教科書的に行くとユニットテストやらＣＩやらは必須事項となっている印象を受けていて、とにかく可能な限りユニットテストを書くべし
というあたりで、可能な限りの部分にかなり高い次元を求めすぎてしまったように思います。
多少慣れない作業であったり、ASP.NETに依存する部分でのテストをどう行うかであったりといった基礎的部分にはまってしまい、
多くの時間を使ってしまいました。
これについてはスプリント中にメンバー内から自発的に（？）切り替え案があがり、テストエビデンスを手動でとっていく方法に切り替えました。
本来やるべきことは動作するソフトウェアを作成し、その動作が正しいことを確認することであり、ユニットテストを書くことではありません。
ユニットテストでテストを行えればメリットは大きいですが、それそのものに時間がかかってしまうなら、本来やるべきことを優先しよう
という判断のもとでの決断です。技術的負債を抱えることにはなりますが、これはある意味勇気ある決断だったと思っています。

バーンダウンがバーンアップになったという問題もありました。
我々のチームは、TFSを使ってすべての物事を行っていますが、アナログツールも数多く導入しています。
紙に書くバーンダウンチャートもその１つで、自分たちで線を書き入れることで進捗を身を持って実感しようという趣旨でやっています。
実績管理はTFSで行っているので毎朝、朝会前にTFSに登録されている残存時間を確認して朝会で報告し書き入れるという感じです。
で、本題ですが、いろいろな角度から見ると、タスクが当初比３０％くらい増えてしまっていたり、
見積もりに対して実績時間がやたらとかかってしまったり、そもそもＴＦＳのデータをExcelで集計していた都合でそのミスで読み間違えたり
といった様々な理由によりバーンダウンがダウンしないという事象を２回くらい経験しました。
まぁそれでも最適な傾向線から著しくかい離しているということはよくわかるのであまり気にも止めてなかったんですが。。。

問題を問題と認識する（できる）水準にも大きな隔たりがあるということもありました。
初めての２週間を半ば強引に迎えていたこともあって、ソリューションやプロジェクトの構成の不備、
ＣＩ環境や必要な3rd party製ライセンスの不足、開発中のTFSのダウン（不可抗力ですが）、
書いたユニットテストが通っていないのに放置してしまうなど問題は山積みでした。
が、スプリントに入って自分がタスクを抱えてしまうと途端にそれに拘束されてしまい、
噴出する問題は誰かがやってくれるだろうといういつものスタンスに逆戻り。
挙句の果てには問題が起きていることすら聞かれるまで言わなくなってしまったり。
行動を起こさない割には勝手に片付けようとするとそれはやめてくださいと言われたりとなんだかよくわからないうっぷんが相当たまりましたｗ
ここについては、どんどん勝手に片付けていってしまうタイプの人にはちょっとつらい状況かもしれません。
この点、正直、性格によるところや通常の組織体での役割によるところの影響が非常に大きいと思うので一概には言えませんが
上司からは”我慢も大事”と諭されている感じですｗ


そんなこんなで連日それなりに長い時間の残業までしたにも関わらず、開発チームとしてもリリース可能と判断できるものが何一つないままに
スプリントレビュー＆ふりかえりの日を迎えてしまうことになりました。
スプリントレビューでは
・開発チームがスプリント中に作成したものをＰＯに報告する（デモやテスト結果の提示などにより受け入れ基準を満たしていることを証明する）
・ＰＯから成果に対するフィードバックを得る
・ＰＯがリリース判断を行う
といった感じでしょうか。

ところが、開発チームとしてもリリース可能と胸張って言えるものが１つもない状態なのでそもそも１つ目から破たんします。
しょうがないのでそれぞれの途中経過を進捗報告するという形でレビュー会を終えることになってしまいました。

続いて振り返りです。
ふりかえりはスプリント中に起こった問題についてあーでもないこーでもないというざっくばらんな話し合い＋ＫＰＴの２本立てで行いました。
前述のスプリント中に起こった問題は半分くらいはふりかえりで起案された内容だったりもします。

ふりかえりででた話題として他に特に印象に残っている点として２点。
ひとつ目は残存時間を管理しているバーンダウンチャートでは実績作業時間が分からないという点。
そもそもバーンダウンチャートは後どれだけ作業しなければいけない時間が残っているかということなので、
これそのものが悪いわけではありませんが、終わってない遅れているという事実がでてきたときに、
見積もりが甘くて作業をやってもやっても終わらない状態になっているのか、そもそも作業してなくて終わっていないのかがわからない
という点に本質的問題がありました。
TFSのScurmテンプレートをカスタマイズして実績時間を入れられるようにしているにも関わらず、
自分を含め誰一人としてそのデータをスプリントレビューやふりかえりに持ってこないというのも問題なわけですが、
デイリースクラムにおいても実績時間を気にして話をしているということもなく日々の活動にも問題を抱えているということが如実に表れました。

ふたつ目はバックログがバックログじゃないらしいぞ！？という点。
２週間やってみてやはり、自分たちが作成していたバックログは要求というより仕様だろう、FeatureよりFunctionだろうという印象が明確に。
端的な言葉で表せばもっと粒度を大きくしたほうがいいということなんだけど、
単純におおざっぱにすればいいというのではなく、分割統治的な粒度というよりはよき言葉でいえば要求駆動開発になるような
ちゃんと要求事項をトップにおいたトップダウンアプローチになるような視点で粒度を大きくするというか。
ここは自分でうまく説明できなかったりまだ実感がなかったりするので理想論になってしまうけど、
Visual Studio開発チーム（DevDiv）がやったシナリオ、エピック、テーマ、Featureという階層構造みたいな考え方をしなければいけないということのような。

【メモ】
ここまで、バックログの作成そのものをスクラムチーム全員でやっている？的な記述をしていますが実はそのとおりです。
ＰＯ役はもちろんプロダクトに求められるものが何であるか？を把握している人ではありますが、
スクラム的なやり方をするのは初めてだということもあって、
この初期の段階では開発チームと支援コーチの全員で集まってバックログの作成そのものをすったもんだとやっていました。
バックログがReadyになっていないのでみんなで集まってReadyにしようとしている。と書くと言葉上はすっきり収まる感じですがそんな感じです。


・スプリント２
スプリント１は問題だらけでした。
レビュー＆ふりかえりを行うまでもなく、行ってみてもそのことはいろいろとわかりました。

打ち合わせ時間の日程調整の都合もあって、そこから連続してスプリント２の計画ミーティングに突入してしまったので
悪いことに対策を立てる間もなく、良いことに今の反省を忘れる暇もなく
スプリント２のスプリント計画ミーティング第一部開始でした。

とはいえ、バックログ？？？な感じなのでいったん第一部は棚上げ。
再度、バックロググルーミングをみんなでやるというところからのスタートです。
２週間やってみてかつさきほどの反省を踏まえて、プロダクトとして実現したいこと、なぜそれを実現したいのか
実現したとしたらどんなときに使えてどんないいことが起こるのか？というあたりを重点的に話し合うことになり、
改めて実現したいこと（先のDevDivの例に当てはめるとたぶんシナリオかEpic的なあたりの）が出来上がりました。

これをもってスプリント計画ミーティング第一部に突入ということになりますが
前回の反省を踏まえて、コーチ陣からの提案もあり、スプリント期間を変更するという思い切った手段にでることになりました。
チームが成熟していないこともあり、２週間ですら長すぎるという判断です。
まずは本当にミニマムにアーキテクチャスパイクをするくらいのつもりでお試し１週間みたいな状態をやったほうがよいとの助言により
変則的ですが、スプリント２は１週間でやることにしました。

という前提のもとで、先ほどできたバックログを見積もりつつスプリントに収まるようにストーリーに分解して～
といく予定でしたが、この日はこの辺で半ば時間切れ。
とにかくミニマムなものを作るということを目的として終了です。

第二部では、とにかくミニマムなものを作るということが目的となっていたのでバックログ的に優先順位の高いものの中に含まれる
非常にシンプルな部分を抽出してそれをタスク分解、見積もってチームのキャパシティーに照らし合わせてやっていくということで
この辺に関してはスプリント１とほとんど変わらない方法がとられました。

---------- 以降自分が別件で退席してしまったため、想像と感想を含みます ----------

やり方は変わらないのですが、スプリント１のときにスプリント中にやたらとタスクが増えていくということを経験したため、
１週間先までのことをシステム的にもスケジュール的にもきちんと設計してタスクの洗い出しを行ってくれたようです。
画面レイアウトや挙動についてもこの場で議論して写真に残す等のことを行っていたようです。

---------- ここまで ----------

その他、スプリント２を開始するに当たり、ＰＯからの要求としてやはり実績の作業時間もみたいよーということだったのでそれについては準備を行うことに。
Visual Studio Scrum 1.0についているバーンダウンレポートは実績値がでないので、余計によくわからないという事態もあり、
ここは急きょMSF for AgileについているバーンダウンとバーンレートレポートをScrum 1.0用にカスタマイズして利用することにしました。
正直、Visual Studio Scrum 1.0よか、MSF for Agile使ったほうがレポート的には充実してていいような・・・。
でも、Scrum 1.0にあるベロシティとリリースバーンダウンレポートは捨てがたい。
もし、TFSでScrumを考えている場合でSSRSのレポートのカスタマイズに自信がない場合には初めにMSF for AgileとScrumの両プロセステンプレートが
出力してくれるレポートの内容を確認したうえでどちらを使うか考えるというのもありかと思います。


スプリント２の期間中はWindows Developer Days（私は参加していませんが）などもあり、人数的にも時間的にもあまりないということで
対象量もかなり絞られ、作業予定時間もかなり絞られていたのでタスク数としてもスプリント１の３分の１くらいの量になっていました。
このことにも助けられ、スプリント１のときのようにタスクが後から莫大に増えていくという事態は避けることができていたように思います。

ただし、自分たちを簡単に正当化しないために敢えてだめだった点を挙げておくと
意識的にタスク（付箋）を増やさないような意思決定をしてしまうという事態が発生しました。
スプリント１では大量に増えすぎてしまって収集がつかなくなりましたが、
スプリント２では逆に如何に最初に挙げたタスクの中に含まれていることにしてしまうか、といったことが起きました。
見た目としてバーンダウンレポートがバーンアップになるということはありませんでしたが、まぁこの辺はバランスの難しいところです。

とはいえ、それなりにスプリント１の反省を活かしながら作業をすることができたということもあり、
タスクが全部終わらないままにスプリントレビューを迎えるという最悪の事態は防ぐことができ、
一応（この部分が後で問題にｗ）対象としたバックログについては受け入れ条件を満たす部分まで作成することができてのスプリントレビューを迎えることとなりました。


スプリントレビューでは
・ものはなんであれ、動く画面をＰＯに見せることができたこと
・それに対してＰＯからフィードバックを得ることができたこと
というのが、純粋に目的を果たすことができたという意味で前回にはなかった合格ポイントです。

実はスプリント２を始める際に期間を１週間にしてとくにかく超ミニマムな動く画面（端的にはサンプルに近い）を作成せよとなったときに
それにどれだけ意味があるのか？ということでメンバー内で猛烈な議論になりました。
そんなことをしている時間があったらどんどん作らなきゃ！というまぁ至極もっともな話だったわけですが、
最終的にスプリント２を１週間にして超ミニマムな動く画面を作るという決定を行う際にはこの辺の話は半ば強引にねじ伏せる格好で決定しました。
異を唱えるというと少し語弊がありますが、この話の振り手にはいささか過酷な決定を下したと思います。

が、その話の振り手も上記２つのスプリント２のレビューでできたことというある種の成功体験を通して、”やって良かった”と発言するまでに至りました。
それほどに、得たものが大きかったということだと思います。
たかがサンプル、されどサンプル、今に始まったことでもアジャイルだからというわけでもありませんが、
実際に動くものを見ながら話をすることで得られるもののいかに大きいことかということを身をもって体験してくれたものと思います。

というわけで、良いも悪いも多種多様にＰＯからのフィードバックを得ることができ、
最終的に受け入れ判断となるわけですが、開発チームの期待を見事に裏切って（笑）受け入れＮＧ。
ただし、ＮＧ理由がもととなったプロダクトバックログの受け入れ条件には書かれていないというおまけつきで。

これはいささか大問題です。
問題へのアプローチとしては本当にわかりやすく２点あって、ＰＯが受け入れ条件を明確に示していない、開発チームが詳細まで聞けてない。
まぁこの２つに尽きるんだろうと思いながらこの時間帯を過ごしていました。
我々のＰＯはまだＰＯ単独でのバックログの整理に時間をかけるということができていない反面、
開発チームは今はまだ一緒にバックログの整理を行っているにも関わらず受け入れ条件を明確にしておけていない、
もっと言えばスプリント計画ミーティング第一部という枠の中でも明確にすることができていない
という部分もあるのだろうなーと思っています。

なにはともあれ事実として受け入れ条件に書いてないんだからなくて当たり前といういい方もあるかもしれませんが、
初めのうちはそんなにシビアにならず、まぁ少しずつ前に進めていきましょうという考え方でもいいのかなという気もします。

----- 後日談 -----
スプリント３のスプリント計画ミーティング第一部で前回フィードバックを新しいバックログとするというやりかたをとったので
結果としてスプリント２の内容は”受け入れられた”という判断でも問題ない気がしましたｗ
----- ここまで -----


・ここまでやってみて
いろいろなところに問題を抱えてはいますが、しいて何が一番問題か？と聞かれると現時点では
”バックログの運営”
と答えます。
次のスプリントまでにきちんとバックログをメンテナンスしたり受け入れ条件を明確に示したりというのは
単純に要求定義書書いてはいお終いというのとは比べ物にならないほど大変だと感じています。
自分の立ち位置は開発チームの１メンバーなのでここに大きく関与する必要もないのかもしれませんが、
ＰＯの負担軽減はそのまま開発チームの負担軽減にも直結しそうなくらいインパクトの大きい問題だと思って敢えてこれが一番と答えます。

また、少し視点が変わりますが、実際にミニマムなものを作成するアーキテクチャスパイク的なものを実体験したことで
いまならようやくRUP（Rational Unified Process）で定義されている4つのフェーズのフェーズごとの変化についても
その意味を身をもって理解できそうな感想を持ちました。
RUPのフェーズでは最初の数回は要件や設計に重きを置きコーディングは軽めにというファーストフェーズから始まり、
２フェーズ目、３フェーズ目と行くにつれてコーディングやテストの比重が高まり、最後のフェーズではテストやリリースの部分が最も比重が高まる感じだったはずです。
我々のスプリント１はいきなりRUPでいうところの２フェーズ目や３フェーズ目に行こうとしていたのだなとふりかえると
まぁそりゃ無理だよねというのも納得です。

未だ、デプロイという意味でのリリースにたどり着いていないので
その周辺にはまだまだ未知なる問題が山のように山積しているような気もしますが、
まずは一歩一歩ということでひとまずここまで。

先日、第5回TFSUGで「WFからAgileへの変革」というようなことを話してきました。
そのときのことはまた別途書くとして、その話のあと、組織運営に関わる考え方に参考になる部分があった
的なお話をいただいたので普段思っていることをなんとなくつらつら書いてみることにします。

・前提として
りばてぃさんは普段こんな感じの人ですってあたりを、前提条件としてインプットしておいてください。
・新しいことをしたり新しいものが大好きです。ただし、コンビニの新発売ドリンクには飛びつきませんｗ
・コンビニの新発売ドリンクはなんでこんなまずいもの出しちゃったの？と疑いたくなるものが多数あると思っています。
・継続することが苦手です。
・新しいものに取り組んだり、試したりすることは好きですが、それを継続することが大の苦手です。
Visual Studioを例に挙げるとCTPやBetaは大好きですが、RTMすると興味がなくなりますｗ
・基本的にわがままです。
・自分のやりたいことをやりたいようにやるという一面があります。
・好き嫌いが激しいです。
・人の好き嫌いも激しいです。食べ物の好き嫌いも激しいです。割とさっぱりばっさりという感じです。
・上記に関わりそうですがエゴグラムをやるとほとんどの場合、CPとFCが突出します。
参考までに
CP（Controlling Parent）：厳格的な父親。「理想主義」の自我状態
CPの方は、高い理想・向上心、使命感・責任感を強く持ち完全主義的な傾向を判定。
CPの得点が高い人は、誠実で、倫理観を持っています。
高い目標意識と責任感をもっており、規律を重んじるなどのよい面もありますが、マイナス作用としては、独尊的な態度になったり、頑固になってしまう傾向があります。
逆にCPが低すぎる人は、いい加減、中途半場、無責任、ルーズ、目標がない、または低いなど傾向があります。

FC（Free Child）：自由な子供。「純粋な子供」の自我状態
FCは、明朗性・活動性・積極性、好奇心など傾向を判定。
FCの得点が高い人は、どんな時も楽しい感情を大切にする傾向があり、周りの人を楽しませるユーモアセンスがあります。
自分の感情を開放的に表現し、好奇心をもち、新しいことにもチャレンジしていけます。
人見知りもせず、他の人と上手に交流も持つことが出来ます。
マイナス面は、度を越すと、TPO（時と場所をわきまえる）ことをせず、周りをわきまえず自己中心的に行動してしまいがちです。
思ったことをそのまま言ってしまうなど、調子にのりやすい。
人間関係のトラブルで、頭を抱える事になる場合もあります。
逆にFCが低すぎる人は、無気力で表情の変化にも乏しく、セックスや人生をうまく楽しめない、などの傾向があります。


さて、本題です。
自分が普段どんな感じで行動を起こしているか。


上司の思いはむげにはしません
私の上司は新しい取り組みを考えること、それを実現してみることをわりと好むタイプの人です。
この場合、自分の行動パターンとしては決してそれを頭ごなしに否定しません。
まずはその思いや実現したいことを聞いてみることにしています。
ですが、私の上司はテクニカルなことにも詳しい人ですが少し未来を見すぎるタイプの人なので、往々にして目の前の現実がおざなりになります。
そんなときは、もっとこうしたらいい、今直面している問題がこうだからこうしましょうというような話をしています。

私の同僚には、上司の思いを頭ごなしに否定してしまって毎度大ひんしゅくを買っている人も少なくありません。
そんな同僚も後で聞くと「コンセプトには同意できる」と普通に言っています。
コンセプトに同意できるならなぜ頭ごなしに否定するのか？という疑問もありますが、
諸事情あって（というか自分の先輩なので）そこにはあまり触れずに「そうですか～」で流してしまっています。

ここからは余談ですが、上記の同僚はそんなこんなでよく上司に怒られます。
私はあまり怒られたことがありません。
きっと、普段のこういう態度の差が重箱の隅をつつかれるようなことを言われるか言われないかの差になっていると思っています。
端的にいうと「神経逆なでする」ってことなんだと思います。
無駄です、馬鹿です、もったいないです。


期待はしません。信頼します。
期待するとは、一方的に相手が自分の望むことを実現してくれることだと思っています。
なので、期待するから裏切られると思っています。
一方で、信頼はただただ信じることだと思っています。
言葉尻がちょっと難しいんですが、一方的にやってくれるはずだ！と思うことはしないというあたりで理解していただけると。

ですが、もちろん誰彼かまわず信頼するということはありません。
信頼できる相手というのは本当にごくごくごくわずかです。
ですが、信頼している相手は変に期待をかけることをせずともきちんと成果を上げてきてくれます。

昔、一緒に仕事をしていたある相手は私を尊敬してくれ、私は相手を信頼するという関係で成り立っていました。
お互い、相手のやってくれることに期待はしませんが、
（またまた言葉尻が難しいんですが）自分は相手の期待に応えようと頑張るという関係だったように思います。


尊敬できる人の期待には全力で応えます。
自分はあまり期待するということはありません。
が、自分が相手の期待に応えないということとはまた別です。
相手が期待してくれているかどうかはわかりませんが、
何かを依頼してくるということはそれなりの期待があることだと捉えています。

冒頭で上げている通り、あまりよくないことだとは思いますが、りばてぃさんは基本的に好き嫌いが激しいので、
嫌いな人からの依頼だとむげにあしらうこともままあります。
が、一方で自分を信頼してくれている、自分を尊敬してくれている、自分が信頼している、自分が尊敬している相手からの依頼の場合、
その期待には全力で応えようとします。

最近は無茶ぶりをしてくれる誰かさんとか誰かさんがいたりいなかったりしますが、
彼らは自分が尊敬するに値する人物です。
そんな彼らからの依頼は自分への「チャンス」だと思って行動するようにしています。
チャンスは自分で掴み取るものだ！な～んて話もありますが、
無茶ぶりの依頼も全力で応えればチャンスを掴み取るなんてお茶の子さいさいです。

ここからはまた余談です。
自分のやる気とも比例する話なので私がいつもこういう行動をとっているわけではありません。
ですが、たまたまやる気のある時期（やる気を出させてくれた人との関わりが強い時期）に
自分にチャンスをくれる事案がたくさんあり、それに一つ一つ応えていたところ
先ごろ、ブログに書いた通りMSMVP for Visual Studio ALMを受賞するという目に見える形の成果を得ることもできました。


上司は責任をとるためにいるものだと思っています。
基本的に上司は責任をとるためにいるものだと思っています。
いつの時の上司に言われたか忘れてしまいましたが、そういうことを言ってくれた上司もいました（恵まれていると思います）。
組織上、上司からミッションを支持され、それをこなしていくというのが仕事ですが、
万が一、それに失敗した場合、責任を取るのは上司です。
会社組織の中で、責任を取らされるのはマネージャーであり、自分ではないことを自覚しています。
（しこたま怒られるということとは別です）
上司はそうならないように私に適切な助言をする義務を負っていると思いますが、
同時に、何の責任も取ることができない自分は、上司がそんなことをしなくてもいいように全力でやるべきだと思っています。

私は、与えられたミッションをこなすためにはいいように上司をこき使います。
部署間調整や偉い人への説明、社外的な問題などには問答無用で上司を引っ張り出します。
自分だけでは解決するのが難しく、上司が出ていけば解決しやすいということをわかったうえでの行動です。
会社組織の中でのことなので、肩書というものは非常に重要です。
部長は部長通しで話をするのが手っ取り早く、役員は役員通しで話をするのが手っ取り早いです。

もし、与えられたミッションを無視して自分の好き勝手、やりたいようにやりたいと思ってそうするのであれば
それは自分で責任を取るべきですが、会社組織の中では一介の平社員が責任をとるというのはなかなかに難しいと思います。

ここからはまたまた余談です。
先にも出てきた私の同僚は私の上司（もちろん同僚の上司でもある）を心底嫌っています。
が、私はあまりそんなことはありません。きっとうまく利用しているからということもあるのだと思います。

正直、自分が嫌っている相手から好かれるということはよっぽど杞憂な人でもなければないと思います。
自分が嫌い、相手も自分を嫌い、というのがよくある構図でしょう。
ですが、これはただただ単純に無駄でしかありません。
私も人の好き嫌いは激しいほうなので他人のことをとやかく言うことはあまりしないですが、
上っ面だけでも友好的な態度をとることによって劇的に改善するということを少しは覚えたほうがいいと思っています。


自分のやりたいことを上司が実現したいことの中に織り込ませます。
会社組織の中で、一介の平社員が責任をとるというのはなかなかに難しいことです。
難しいので、上司のミッション、ひいては組織のミッションにしてしまえばいいと思っています。
そうすれば、自分は自分のやりたいことをできるし、責任は組織として追うことができます。
ずるがしこいですが、自分で会社を起こすなどしないのであれば堅実な方法だと思っています。

そのためには、冒頭にあった上司の思いをむげにしないということが非常に重要になってきます。
上司の思いをくみ取り（くみ取ったふりをすることも）、自分のやりたいことを摺合せ、こういう手段で実現していきましょう
と、自分のやりたいことに徐々に問題をすり替えていきます。
上司としては自分のやりたかったことを部下が実現手段として提案してきてくれているという思いになりますので
こんなうれしいことはないでしょう（私の思い込みですｗ）。
喜んで、来期の計画検討の資料に織り込んでくれます。


非常にずる賢い方法をとっているような気がしますが、
りばてぃさんは基本的にわがままなので、自分のやりたいことしかやりません。
ですが、それが組織のミッションであれば誰も文句はいいません。
もちろん組織の方向性は無視しないようにしていますが、
今のやり方が、自分が組織のミッションに対して最も効果的に成果を上げていける道を辿っていくことができる道だと思っています。


最後にまたまた余談ですが、
踊る大捜査線というドラマでわくさんが青島に「正しいことをしたければ偉くなれ」と言っていたのを覚えている、知っている方もいるのではないでしょうか。
正しいことというのはドラマ上のニュアンスですが、要するに「自分のやりたいことをしたければ偉くなれ」ということだと思います。
自分の意見としては、偉い人を使えばいいので別に偉くなる必要はないと思いますが
組織運営という意味においては非常に重要な示唆を与える言葉であると今でも信じてやみません。

とある友人のつぶやきにこんなものがありました。

「ここまで火を付けるって、凄腕コーチがサポートしてるのかなー。」

自分がアジャイルやるぞ！オー！！って燃え上がっているらしいことに対しての純粋な疑問というところでしょうか。
あなたの周りには今までにもアジャイルに取り組んでいる人たちがいっぱいいて、いろんな気づきを与えてくれていたはずなのに、なんでまた急にそんなに燃え上がってる風なの？という疑問かもしれません。
正直自分でもよくわかりませんｗ

もう振り返れば６年くらい前になると思いますが、別の友人にこんなことを言われたことを今でも鮮明に覚えています。

「ウォーターフォールで開発している時点で負け組だ」
※注意：多少ニュアンスの違いや前後の文脈はあったと思います

どちらの友人も固有名詞を出すとびっくりするぐらい有名な方で、そんな気付きを与えてくれる人たちに囲まれているのになんてもったいない！って言われてしまいそうですが、少なくても６年前に言われたことに対しては、そんな前向きな思考はほとんどありませんでした。

「だってしょうがないじゃない。×××ってSIerで仕事してるんだから」

というような感想を持って終わったことも今でもよく覚えています。
でも、今言われたらきっと違う感想を持つと思います。

「それが良いと思えたらそうなるように働きかけてみる」と。

あの当時は、そしてついこの前までは良いらしいといわれても「ふ～ん」で終わらせてしまうほどにはまったくもって全然響くものはありませんでした。なんでまったく響いていなかったのか、何が心に響いてがらっと考え方が変わったのか（または変えようとしているのか？）を自分自身で考えてみるというのはなかなかに興味深いと思い、一生懸命悩んでます。悩んでなんだったんだろう？と思うのも変な話ですが、心に響くタイミングってほんとに不思議なものであるとき突然というのが今までのパターンでしたが、レトロスペクティブが大事らしいのでちゃんと考えてみようと思います。

自分で書いてて定かじゃないんですが、
往々にして言われても響かないときは、
「いいか悪いかじゃなく、仕事として言われたとおりにやるしかない」「自分には関係のないところで起こってる事実だ」
と思っているとかそういう思考のもとで行動しているというかそれが当たり前として特に考えることもなく行動している
というときのような気がします。
「とくにかくやるしかない」
というときも該当していそうです。特に目の前の作業、納期、キャパシティを超える量に忙殺されて、でも仕事としての責任は果たさなきゃというのだけはあって、まわりからはやんややんやとせっつかれて、というようなときなんかはこっちのパターンな感じです。
端的にまとめちゃうと「思考停止」と「ゆとりのなさ」ということになると思いますが、それが日常だとそれにも気づくことはなかったような。。。

途中、空白期間はあるもののまぁそれなりに技術コミュニティというところには顔を出しているような気はしますが、とはいえこのような思考状態なので、せっかくの勉強会も猫に小判、豚に真珠、馬の耳に念仏。。。よくこの手のコミュニティやちょっと先進的な研修などに行くと、「ここに参加されている皆さんは意識の高い人だと思いますが～」みたいな前振りがあったりしますが、自分の過去の経験から考えるに決してそんなことはなくｗ だれか知り合いがいるから行くとか、知り合いに呼ばれていくとか、それ以後は開催されているからなんとなく行くということを繰り返していただけなような。

このような状態からいかに脱却しようとしているのか、しようとさせられているのかを引き続き考えてみようと思います。

@ryuzeeさんがつぶやいていたので見つけたものがあります。

Scrum at Microsoft: See the TFS Agile Team do a Scrum (aka Stand Up) - Long
http://www.youtube.com/watch?v=-UUrLxNBK_g

Microsoftの中でTFS 11（と思われる）かTF Serviceかを利用してデイリースクラム（朝会）をしている様子です。
アナログの付箋でやるメリットはいろいろありそうですが、
必要な時にだけプロジェクターを使ってタスクボードを写し、
その場でドラッグ＆ドロップでタスクを動かし、リアルタイムでバーンダウンチャートが更新される
というのも便利なもんです。


--以下余談--

自分たちがスクラムでの開発を始めるに当たり、当然のように
タスクの管理を付箋でやるのか？ＴＦＳで全部やってしまうのか？という話題になりました。
便利さ、ユーザーストーリー、タスク、ソースコード、テストがすべてシステムで関連付けられるので
タスクもＴＦＳで全部管理してしまうのがベストだろうという話や
特に上司など第３者に立ち止まって見てもらうには常に張り出しておいたほうがいいし、
自分でバーンダウンチャートに線を引く達成感はシステムにはやらせたくないという話など
いろいろな話がでました。

結局、どちらも重要だということで、工夫をしながら両方使っていくことになりそうですが、
何のためにそれをやろうとしているのかが明確であれば、
”何、２重管理なんて手間ばっかかかることしてるの？”という圧力にも屈することなくやっていけそうな気がします。

VS 11 Developer Previewが発表された直後にも出ていましたが、
今回もBeta発表直後にちゃんと更新されていたみたいです。

というわけで、下記のブログにVS 11 ALM Betaの仮想マシンとハンズオンラボの一式が公開されています。

Visual Studio 11 Application Lifecycle Management Virtual Machine and Hands-on-Labs / Demo Scripts

中身をざっと見る感じでは、スクリーンショットがMetroスタイルのUIになっていたりするので、ハンズオンの流れそのものもBetaに合わせてちょこちょこ変わっているかもしれません。
評価にはHyper-V環境が必要ですが、ざっとALM関連の新機能を俯瞰するにはちょうどいいと思うので、再度やってみようと思います。

2/25（土）に名古屋アジャイル勉強会主催で

名古屋アジャイル勉強会分科会　第２回開発ツール勉強会

というものが開催されます。
今回なんと、TFSUGがその勉強会にお邪魔し、出張ワークショップをやらせていただくことになりました（パチパチパチ）

テーマはもちろんTFSがらみでズバリ「TFS入門」です。

今回は機会があって自分も参加できることになったので、
（というか、きっとハンズオンの講師を務めさせていただくことになると思いますが）
せっかくなんで前日の2/24（金）に開催される

第４０回名古屋アジャイル勉強会

にも参加してくる予定です。
東京以外の勉強会に参加するのは初めてなので今から楽しみです。

まだまだどちらも受付されていると思いますので、名古屋近隣の方はぜひぜひご参加ください。
TFS問わずALM分野では大活躍のあのエバンジェリストも来るらしいですよ！？

サイト：名古屋アジャイル勉強会

第４０回名古屋アジャイル勉強会申込み要綱

第２回開発ツール勉強会申込み要綱

今日から始まるTFS Advent Calendarの22日目です。
サイトはこちら：http://atnd.org/events/22819

TFSには無料で提供されている便利なアドインが数多く存在しています。
その中からいくつか便利な（というか私が普段使っている）アドインを紹介します。


Team Foundation Server Power Tools

言わずと知れた、というか絶対入れておくべきツールの１つです。
執筆日（2011/12/22）現在、「Team Foundation Server Power Tools December 2011」というものが
こちらのサイトで公開されています。
http://visualstudiogallery.msdn.microsoft.com/c255a1e4-04ba-4f68-8f4e-cd473d6b971f

このツールはTFSがインストールされているサーバーにもTFSのクライアントになる各端末にも
どちらにもインストールするべきツールです。

このツールを利用することで例えば、
TFS Advent Calendar Day 10 および TFS Advent Calendar Day 15で紹介したような
TFSのバックアップ＆リストアを簡単に行うための機能に加え
・TFSからのメール通知でありとあらゆるタイミングを利用できるようにカスタマイズ
・TFSの運用環境診断（TFS Advent Caledanr Day 17～TFS Best Practices Analyzer～ by kkamegawaさん）
・チームエクスプローラーへのプレゼンス情報の統合（Live Messengerや旧OCSなど）
・Windowsエクスプローラーからのチェックイン／チェックアウト
・PowerShellコマンドレット提供
・４種類のカスタムチェックインポリシーの追加
・作業項目新規作成用テンプレート機能の追加
・プロセステンプレートのGUIベースでのカスタマイズ
などなど、TFSを“実際に”使っていくときには手軽さ向上、運用負荷軽減になくてはならないツールです。

# 2011/12/22現在、Eclipse向けのPower Toolsがリリースされたという情報が
# bharry's blogにて公開されています。
# 「December 2011 TFS Power Tools Release」

Team Foundation Server Administration Tool

TFSの運用管理者にはやはりなくてはならないツールの１つです。
執筆日現在、「TFS Administration Tool 2.1」が、こちらのサイトで公開されています。
http://tfsadmin.codeplex.com/

このツールはTFS環境一式（WSS, Reporting Servicesを含む）への管理者権限を持った
ユーザーが利用する端末にインストールして利用します。

このツールを利用することでTFSのセキュリティ設定を非常に簡単に行うことができるようになります。
TFS環境一式での権限設定はTFSそのものに加え、WSSの対象サイトコレクション、Reporting Services
と３か所に渡って行う必要があり、この点を意識せずに設定してしまったがために
チームプロジェクトそのものには接続できるが、ドキュメントとレポートが見れない
といったことが割とよく発生します。

このツールでは、Active Directoryのユーザーまたはグループを
TFS, WSS, Reporting Servicesの３か所に対してまとめて権限設定できるようなGUIを提供してくれます。
もちろん、どの権限を振るかも状況に合わせて適宜選択することが可能です。


Team Foundation Server Build Extensions Power Tool

Team Foundation Serverは2010になってから、マイクロソフトとしてマルチプラットフォームへの
対応をきちんと行うようになりました。
現在は、Team Explorer Everywhereという製品を利用することでEclipseからもTFSを利用でき環境が整っています。
Eclipseから繋ぐということはまぁ大概はJavaによる開発であろうということで、
JavaソースコードのビルドをTFSのビルド機能にがっちゃんこするためのアドインです。
執筆日現在は「Team Foundation Server Build Extensions Power Tool Decemer 2011」というものが
こちらのサイトで公開されています。
http://visualstudiogallery.msdn.microsoft.com/2d7c8577-54b8-47ce-82a5-8649f579dcb6

このツールは基本的にはTFSサーバー（ビルドサーバー）にインストールしますが、
チームビルドの編集を行うクライアントにもインストールしておく必要があります。
# WFのアクティビティを認識して利用できるようにするため

このツールを利用することで、Javaでよく利用されているAntまたはMavenを使ったビルドを
チームビルドから利用できるようになります。
また、そのために必要となるtargetファイルや、チームビルド編集時に必要となる
WFのアクティビティなども同時に提供されます。
# Javaの場合はやっぱJenkinsだよね♪というのはこの際おいておいて、
# ちゃんとTFSからもJavaのビルドができるんだよ！というところがポイントです


Microsoft Visual Studio Scrum 1.0

スクラムというキーワードだけでもピピっと反応する人が多そうな一品です。
TFS 2005～2010まで一貫して、TFSに初期状態で用意されているプロセステンプレートは
「MSF for Agile」、「MSF for CMMI」の２種類のみでした。
TFS 2010用のプロセステンプレートとして、且つマイクロソフトブランドとして、
初めて上記２つ以外に提供されたのが「Microsoft Visual Studio Scrum 1.0」というプロセステンプレートで
こちらのサイトで公開されています。
http://visualstudiogallery.msdn.microsoft.com/59ac03e3-df99-4776-be39-1917cbfc5d8e?SRC=Featured

もう細かいことは説明いたしません。
TFSでスクラムのプラクティスに乗っ取ったやり方ができる
というだけですべてを物語れるのではないかと思います。

# ただし、英語版で提供されていますので、
# 日本語版TFSで利用するためにはプロセステンプレートそのものにいろいろと手を入れる必要があります。
# Team Foundation Server 2011 Developer Previewには標準でScrumテンプレートが付属してますので
# それはそのまま製品化へ！というフィードバックをしてあげると最初からちゃんと日本語化されて
# 製品に搭載された状態で出荷される可能性を高めることができると思います。


Team Review

こちらはTFSの仕組みを利用してコードレビューの依頼とレビューフィードバックのやりとりを
簡潔化しようとするためのアドインです。
執筆日現在は「Team Review Release 1.1.3」がこちらのサイトで公開されています。
http://teamreview.codeplex.com/

このツールはTFSのクライアントとなる端末にインストールすると同時に
ツールに付属する２つの作業項目をTeam Reviewを利用したいチームプロジェクトに登録する必要があります。

環境がすべて整うと、
Visual Studioのコードエディタ上からレビュー依頼作業項目を発行することができるようになります。
誰にどの部分を見てほしいかというような情報を登録して、レビュー依頼を登録します。
レビュー依頼を受け取った利用者はその作業項目を参照しながら
レビュー結果作業項目を作成していきます。
レビュー結果には指摘箇所に該当するソースコードを添付したり、コピペしたり指摘内容を入力したりします。
ここで、レビュー結果作業項目の数 = 指摘件数となります。

最終的にレビュー結果一式を受け取った側は
レビュー結果作業項目を参照しながら指摘事項を修正すると作業完了です。
このとき、レビュー結果作業項目を参照すると該当するソースコードをコードエディタ上で開いてくれる機能などもあるので
リズムよくどんどん修正してくことが可能となっています。

ちなみに、環境構築時にさらっと「作業項目を２つ追加」と書きましたが、
Team Reviewに用意された作業項目はちゃんと日本語化されていますのでご安心ください。
# 日本語化したのが私なので訳が変でも許していただければ・・・ｗ

このTeam Reviewの考え方ですが、
個人的にはTFS 11 Developer Previewにもその概念がふんだんに取り込まれたのではないかと思っています。
TFS 11 Developer Previewにはレビューリクエスト、レビュー結果という作業項目とシェルブセットを使った
コードレビューのワークフローを管理するための仕組みが用意されています。
機能は多少異なりますが、なんとなく通づるところがあるように思う今日この頃です。


TFS Timesheets

このアドインは作業項目のカスタムコントロール機能を利用して作成されているものです。
作業項目にカスタムコントロール使えたっけ？というあたりの時代の変遷が気になる場合は
「TFS Advent Calendar Day 1～Visual Studio Hawaiiはいずこへ～」あたりをご覧いただいたら良いかと思います。

執筆日現在、「TFS Timesheets 1.0.3」というものが、こちらのサイトで公開されています。
http://tfstimesheets.codeplex.com/

この作業項目用カスタムコントロールを利用すると、
純正作業項目ではなかなか難しい“計算処理”しかも、残存時間と実績時間の計算処理を行ってくれるようになります。
さらにさらに、日本の管理者が涙ちょちょぎれるんじゃないかと思うぐらい賢いのが
“日ごとの実績時間入力への対応”が行えてしまいます。
# まぁ日々レポート見ればどれくらい減ったかってわかるんですけどねｗ
実際には、このコントロールを作業項目上のどこかに配置しておき、
何年何月何日にどんだけ作業をしたかという数値を登録していきます。

すると入力された時間に応じて実績時間を増加させ、残存時間を減少させということをしてくれます。
予定通りに進んでいない場合はこの時点で残存時間だけを手入力で増加させます。
あら、不思議。
何日にどんだけ作業して、結果としてまだ残存時間がこんだけあるらしい
なーんて情報が一目瞭然です。

本来、TFSのタスク作業項目は１日以内に終わる粒度まで分解して登録されることが望ましい
というベストプラクティスがありますが、なかなかそうもいかないのが現状です。
このツールを利用することで日をまたがった場合でも経過状況が簡単に把握できるので便利ですね。


さいごに

あまり多くのアドインを紹介することができませんでしたが、
TFSには（もちろんVisual Studioにも）実に多くのアドインが提供されています。
それらについては大筋は以下の２サイトを検索することで発見することができます。

・Visual Studio Gallery ： http://visualstudiogallery.msdn.microsoft.com/
　マイクロソフト社のサイトとして公開されているもので、Visual Studioを中心とする開発系で便利なツール類が
　数多く登録されています。
　中には製品として有償のものであったり、製品のトライアルとして期間限定のものもありますが、
　無償提供（ライセンスはツールによりまちまち）されているものもたくさん存在しています。
　検索ワードとして「TFS」や「VS」などと検索カテゴリーを「Free」に設定して検索すると
　無償で利用可能で優良なツールを多く探し出せると思います。

・CodePlex ： http://www.codeplex.com/
　マイクロソフト社が（？）コミュニティーベースのツール開発を行うための基盤を提供しているサイトです。
　Wiki, SourceControl, Issue Trackなどの機能がありますが、中身はTFSだとかなんとか。。。
　このサイトではEnterprise Library（マイクロソフト社製ではありませんよ？）や
　なぜかpatterns & practicesのドキュメントなどが公開されていたりもします。
　他にもVisual Studio Rangersという主にALM MVPを中心としたグループの活動成果や
　個人で公開されているツール類などが数多く公開されています。

　ちなみに、一部界隈では有名なASP.NET MVCのサンプルアプリ「Edtter」なんかもCodePlexにて公開されています。


これらのサイトを徘徊し、ぜひともバニラＴＦＳから脱却し、フレーバーＴＦＳの世界を構築してみてください！！

TFS Adevent Calendarの１０日目です。
告知サイトはこちら：http://atnd.org/events/22819

今回は少し実用的なTFS 2010のバックアップとリストアについてざーっとまとめ記事です。
ただし、エントリーが長くなるのでまずはバックアップから。

TFS 2010のバックアップとリストアに関しては、バックアップ時の注意事項、
同一サーバーに復元するパターンや異なるサーバーに復元するパターンなどと合わせて
MSDNライブラリに詳細な記述が載っています。
http://msdn.microsoft.com/ja-jp/library/bb552295.aspx

しかし、かなりボリュームのある内容ですので正直読みながらやるのは結構大変です。
端的にまとめると
・TFSおよび関連するサービスが利用しているデータベースは同じタイミングでまとめてバックアップ／リストアしてね
ということになります。
で、いざやろうと思うとやっぱり大変です。

ということで、バックアップおよびリストアをそこそこシンプルに始めるための機能が
Team Foundation Server 2010 Power Tools August 2011に含まれています。
http://visualstudiogallery.msdn.microsoft.com/c255a1e4-04ba-4f68-8f4e-cd473d6b971f

まずは上記サイトからツールをダウンロードしてきたのち、
TFS 2010のアプリケーションサーバーになっている端末でPower Toolsのインストールを開始します。
※TFS 2010 Power Tools自体には多くの機能が備わっていて、もちろんTFSのクライアントとなる
　　各開発者端末にもインストールすることができます。
　　ただし、Backupを行うための機能についてはTFS管理コンソールにアドインされるため、
　　TFSのアプリケーションサーバーになっている端末でインストールを行う必要があります。

TFS 2010アプリケーションサーバーの端末でインストールを開始すると、
インストールする機能を選択する画面で、以下のように「tfs backup plan」を選択することができます。


インストールが完了したら、Team Foundation 管理コンソールを開きます。
先ほどインストールした「backup plan」がアドインされて以下の図の左側にあるようにメニューが１つ追加されます。
TFS環境一式のバックアップ／リストアは追加されたこの画面からすべて行うことができるようになります。


このメニューからは主要項目として
・バックアッププランの作成
・フルバックアップの実施
・リストア
を行うことができます。
※バックアッププラン未作成の状態では上記のような項目を選択することはできません。
　　まずはプランを作成しましょう。

ツールを使っていくためには、まずはバックアッププランを作成していきます。
画面上で「create backup plan」を開くとウィザードが起動するので順次設定していきましょう。
まずはバックアップデータの保存先と保存期間の設定です。
一つポイントは保存先をローカルフォルダに設定することができません。


次はレポーティングサービス関連データを含めるか否かです。
含める場合はレポーティングサービスの暗号化キーもバックアップ対象とするため、キーを復元する際に利用する予定の
パスワードを設定しておきます。
ここでのポイントはパスワードは複雑さの要件を満たす必要があるということです。


次は、Windows SharePoint Servicesのデータを含めるか否かです。
TFSが依存しているすべてのWSSを対象に含めることができます。


次にバックアップタスクを実行するためのユーザーを設定します。
図ではNetwork Serviceを利用していますが、自分たちの環境に合わせて設定してください。
当然のことですが、バックアップ先フォルダに対する書き込み権限を設定することをお忘れなく。


Team Foundation Serverの通知設定を有効にしている場合は
その設定もバックアップに含めることができます。
通知設定を有効にしていない場合は以下の画面のように選択肢を選ぶことができません。


最後に、スケジュールの設定を行います。
標準では毎晩フルバックアップが選択されていますが、
どのバックアップ形態を利用するか、どういったスケジュールでバックアップを行うかを設定することができます。


最後にチェックが行われ、エラーがなければウィザードを進めていくことでバックアッププランの作成を行うことができます。
バックアッププランの作成が終了した時点でReporting Servicesの暗号化キーバックアップデータも完成しているので、
復元の際に利用することができます。

プランの作成が終わって、Team Foundation 管理コンソールに戻ると
先に示したようにフルバックアップを実施したり、リストアを行ったりといったことができるようになっています。
バックアップが必要になった時に利用してみましょう。

なお、このバックアッププラン作成ウィザードで作成したプランはWindowsのタスクスケジューラに登録されています。
実行時間や間隔などを微調整したい場合にはそちらから編集してしまうことも可能となっています。