Team Foundation Server を利用してアジャイルな開発を (Part I)

金曜日のセミナーにご来場いただきました皆様、どうもありがとうございました！
いつも以上に笑いもいただけて、個人的にはとても楽しく皆さんと接することができたと思います。

そんな中、本日の F1 オーストラリア GP を見逃して、本国の大学バスケットボール大会の試合もミスって、少々落ち込み気味です (；＿； )
なので、ラザニアを作ってお腹も心も落ち着きました♡

そんな余談はさておいて。金曜日に約束しました通り、アジャイルにプレゼンテーションを変えてしまったので、その内容を含めて、こちらで当日のお話の内容をシェアさせていただきます。

因みに、当日のお話のタイトルは以下:

『Team Foundation Server 2008 が支援するアジャイルな開発』

元々は、 『マイクロソフト基盤におけるアジャイル開発』 と言うタイトルだったのですが、気分でタイトルを変えました。
内容は・・・・・・・・・・当然、当日変わったので、タイトルに拘る必要もないかも知れませんね (笑)

さて、アジェンダそのものは特に変更しませんでした。
内容を追加したと言うのが主なところです。
理由としては… 僕の前にお話をして下さった長瀬様と三井様が、「この後の MS さんのセッションで～」と、その時までサラッと触れる予定だった内容を、もう少しきちんと皆さんにお伝えする必要ができ、せっかくなのでアジャイルな話をアジャイルに紹介しようと言う試みでした。

前半は、「アジャイル」と「ツール」の位置づけとして、アジャイルな開発をするにおいてツールをどのように利用すべきかと言うことを話しました。
ただ、ツールの話をする前に、改めて「アジャイル」について。

Agile と言う単語は、開発用の用語ではありません。
普通の単語です。「素早い」とか「機敏」と言う意味です。
よく、スポーツ選手の性能を表現する時に使われる単語です。

どれだけ変化に対応できるか、応用力があるか…

なので、僕の中では一番「アジャイルな開発」を説明するのは「臨機応変な開発」だと思ったのです。

考えてもみて下さい。
アジャイルな開発の話において必ず皆さんに認識いただく必要があることは、「物事は計画どおりにはいきません」と言うこと。
まして、計画どおりにしか動かない…変化に対応しないと、プロジェクトは遅れる、問題は解決できない、コストがガンガンと上がって行く。

「でも、そんな臨機応変な対応をプロジェクトにおいてやれと言われても、慣れていないことをいきなり…」

そんなことは絶対ありません。
皆さんの人生で、物事が計画どおりに行ったことって、どれだけありますか？
アメリカではこんな言葉があります: “When life gives you lemons, make lemonade.”
人生において、レモンを投げられた時には、そのレモンを使ってレモネードを作れば良い。
まぁ、日本的に言い換えると… なんでしょう？きっといい諺があると思います。

要は、人生に変化はつきもの。思い通りにことは行きませんよね？
でも、だからと言って、諦めてきましたか？それなりに考えて、臨機応変に対応して、自分で最も適していると言う判断をしてきませんでしたか？

人として、皆アジャイルに生きているんです。当たり前のようにやってきていることです。
仕事だって同じことです。開発だって同じです。どんなプロジェクトだって同じことです。

このスライドに関しては多くは語りませんでした。せっかくなので、Agile Manifesto を英語で皆さんに読み上げて差し上げようかと思いましたが･･･逆に嫌がらせになっちゃうので、やめました (笑)
ただ、一部分だけピックアップさせてもらいました。

“Business people and developers must work together daily throughout the project.”

「プロジェクトの期間中、ビジネス側の人と開発者は**必ず毎日一緒に作業せねばならない**」

これが一体なにを意味するか。
ごく、当り前のことなんです。
要は、誰が開発したものを利用するか… その人たちと会話をして、必要なものを作っていかないことには、そのプロジェクトの価値は下がってしまいます。それは、言い換えると、開発をしている人たちの価値を下げてしまうことになります。
そう思いませんか？

アジャイルに開発しようがしまいが、そこは個々にお任せするところではありますが、プロジェクトにおいてビジネス バリューを常に確認して必要とされているものを再認識しながらプロジェクトを進めることがあるべき姿だと思います。

この話を社内の人たちと話ていた時に、色んな議論をしました。
その中で、「守破離」と言う考え方についても話ました。

「受け継がれた物を守り
現代合わなくなった物を捨て去り
新しく、独自の工夫を加え、そして今までの型を越える」

と言った考えらしいです。
個人的にも、とても好きな考え方です。

守るべきものをそのまま捨てると言うことではありません。
伝統のようなものは、それこそ、守るべきだと思います。
ただ、伝統であっても、現代社会においてそのやり方が最も適しているとは限らない…
守るものは守りつつ、そこから離れていく必要も出てくると思います。

開発においてもそうであって、ウォーターフォールのような開発手法と言うのはベースラインとして必要です。
無論、そのようなコンセプトがなければ、他のコンセプトだって生まれていないのですから。
でも、そのやりかたが必ずも合理的かと言うと、そうではありません。
コスト的にも、効率の観点から考えても、あまり良いとは言えません。非効率的だし、コストが嵩張ることが多いです。

間違ってはいなくても、もっと良い物事のやりかたはあるということです。

変化に臆病にならないでください。

では、いざ、アジャイルな開発を実装してみようと言う時に、ツールやプロセスってどうなるの？？

アジャイルな開発の話を聞いてよく勘違いされることがあります。
それは、「プロセスやツールより個人と相互作用を重視する」と言う考えから、それがプロセスが不要と言う考えだったりツールが使えないと言うこととイコールだと思われることです。

逆です。
確かに、人やコミュニケーション、コラボレーションを重視すると言う考えですが、ツールやプロセスは必要です。大事です。むしろ、それらがなくては実装できません。

ただ、問題はツールの使い方にあるんだと僕は思います。
どういうことか？
ツールは道具でしかないのです。製品の中に含まれる色んな機能はツールとして絶対ではありません。

「鶏と卵」 と言うスライドがありますが、要は、開発プロジェクトにおいての考え方です。
ありがちなパターンとして、「ツールにはこんな機能があるから、それらを活かしてこんなプロジェクト構成にせねばならない…こんな風にプロジェクトを進めねばならない」と意図していなくても考えてしまうことです。

それも逆です。
ツールは道具。直訳です。道具は「必要なところに使う」べきものであって、その道具があるから何かをするんじゃないです。
カメラがあるから写真を撮りますか？それとも、写真を撮りたいからカメラを使うんですか？
写真を撮りたいけど、カメラとしての機能もあり、ビデオレコーダーとしての機能もあり、電話としての機能もあるツールだってあります。
その場合はどうです？そのツールがあるから、写真もとって、電話もしますか？必要がないとしても？ (ロジックとしてだけ考えて下さい。屁理屈なら、僕だって負けません (爆)
いや、そのツールが手元にあるとしても、必要としているのは写真を撮ることなので写真を撮りますよね。

分かりづらいですか？
言いたいことは、つまり、製品・ツールの機能を必要な時に必要なだけ利用すれば良いんです。
アジャイルな開発をするにしても、それだけのツールを求めるのではなく、世に存在する複数のツールから必要な部分だけを利用すれば良いんです。

もちろん、マイクロソフトとして、それが Visual Studio Team System であって、Team Foundation Server の機能であってくれたら、嬉しいです。
そして、製品担当として、僕は胸を張って、それを実現する機能を Visual Studio Team System が持っていると思います。
更に言えば、それ以上の機能も持っていますよ！

アジャイルの考えを促進する一人の Kent Beck も、アジャイルとツールの関連性についてマイクロソフトのためにホワイトペーパーを書いてくれました。

約束した通り、ホワイトペーパーのリンクをこちらに用意しました (翻訳してあります！)

アジリティ (俊敏性) 向上のためのツール (PDF 形式 / 1.48 MB)

他にも、 Visual Studio のホワイトペーパー をこちらからご確認できます。

要は、僕が上記で要訳 (できてたかな…) した内容なんですけどね。

プロセスもツールも大事です。必要です。なくしては、アジャイルな開発だって簡単にできやしません。
Visual Studio Team System は、アジャイルな開発を支援する機能を用いています。
それ以上にも機能はありますが、要は、実現するための機能があるので、その機能を利用していただきたい。

Visual Studio Team System のコンセプトは、アプリケーション ライフサイクル管理 (ALM) であると言うことはご存じの方もいるかと思います。
以前にもシェアしました 。

アジャイルについて上記で説明をした際に、これが「当たり前」で「あるべき姿」だと書きました。

“Business people and developers must work together daily throughout the project.”

「プロジェクトの期間中、ビジネス側の人と開発者は**必ず毎日一緒に作業せねばならない**」

VSTS のコンセプトもそこにあります。

ALM のコンセプト、そしてアジャイルな開発のコンセプトにおいても中心にあるのはビジネス バリューのデリバリーだと思います。
そして、そのためにはビジネス側の人間も開発側の人間が関わり、ALM の観点から言うと、更に運用の人間が関係しています。
それらの方達がプロジェクトにおいて皆関わっているのです。皆がステークホルダーなのです。

ただ、通常のプロジェクトの中ではこれらのステークホルダーがコミュニケーション、コラボレーションしていることはないかと思います。

理想の世界では、繋がっているべきです。
関係者なのですから。

コミュニケーションやコラボレーションを実現するために、ツールを利用しましょう。
それがコンセプトです。
もちろん、それだけではなく、アプリケーション開発のライフサイクル全体において、情報管理をすると言うことが目的です。
そうなると、当然、これらの関係者がコミュニケーションすることができ、透明性が必要になります。

VSTS はその中心に入り、実現しようと言う考えです。そして、それを実現するために Team Foundation Server のようなツールが開発されました。

ソースコード管理のツールだけではなく、作業管理、チームの管理などと、関わる情報管理をするためのものです。

思考変更…パラダイム シフトが必要なんだと思います。
これまで1年半以上、このパラダイム シフトについて色んな方達にお話をしてきました。
伝わっている方たも、伝わらなかった方もいるかと思います。

でも、僕は、あるべき姿だと思います。
バリューアップ…要は、アプリケーションを開発するにおいての価値を見出して行くのが、あるべき方向だと思います。

価値ある製品を、価値あるサービスを提供していくのが、開発プロジェクトの醍醐味だと思います。
そして、VSTS はそれを実現するために、皆さんを支援します。

なんだか、アジャイルからかけ離れて行きましたが･･･
ここまでを PART I とさせていただきます。

書くのも結構大変なので、2回に分けさせて下さい。

ちなみに、これが今晩作ったラザニアです♪♪ パスタの部分以外はすべて手作りです☆
ミートソース、ホワイトソース、チーズソース。

それでは、次回、続きをお楽しみに！