Basecampを使う理由(2)
Basecampは本当に私たちの開発スタイルに合っていると思っています。
一番大きな理由は、やはりアジャイルなスタイルに合うこと。
あと、私たちが開発元の37Signalsの考えともよく合うということ。
彼らが出しているGetting Realという本があります。日本語版もダウンロードして読めます。
（この存在は一緒に仕事をしている徳武さんに教えてもらいました。）
これを読むと、37Signalsのウェブ・アプリケーションに対する考えがよくわかります。
実用的なソフトウェアを作ることに振り切っているところもとても好感が持てます。
（例えば、Microsoft Projectなんかを「ゴリラのようなソフトウェア」と言っています。意味が分かりますか？）
また、彼らはとてもユニークで、
というようなこともやっているようです。おそらく、日本のほとんどの企業では理解されないと思います。もし少しでも理解できたなら、それだけで十分だと思います。
（うちは割りと似たところがあるかな。。。）
—-
「アジャイルなスタイルに合う」というのは、Basecampのビジョンにあります。
Getting Realから引用すれば、
「Basecamp」：プロジェクト管理はコミュニケーション
という、ビジョンです。このビジョンが、
このビジョンにより、我々は「Basecamp」を可能な限りオープンで透明性の高いものにしました。会社内の範囲だけでなく、我々はクライアントとのコ ミュニケーションにもアクセスを広げました。我々は、全てのメンバーの参加の垣根を低くし、サポートするよう考えました。ビジョンは、なぜ我々がチャート や、グラフ、テーブルやレポート、統計、スプレッドシートといったものを省き、代わりにメッセージやコメント、ToDoリスト、ファイルの共有といったコ ミュニケーション機能を重視したのか、という部分です。ビジョンついて大きな視点での決定をしましょう。そうすれば、これからの小さな判断がはるかに簡単 になります。
というサービスを生み出しました。この「ビジョン」こそがアジャイルなソフトウェア開発に合うところです。
—-
アジャイルなソフトウェア開発は、人とのコミュニケーションを重視します。
チームではドキュメントをやりとりする代わりに、コミュニケーションでカバーし、開発速度を上げます。
顧客コミュニケートすることで、問題領域を明らかにし、解決していきます。
また、今時のソフトウェアはネットワークを介して他のソフトウェアと連携しながら動くものがとても多いです。
そのような場合、クライアントや他の開発チームとのコミュニケーションも非常に重要になります。
逆に言えば、そのようなコミュニケーションの不足がプロジェクトが失敗するポイントになりやすいところです。
（今まで何度それで失敗するプロジェクトを見てきたことか。）
Basecampを利用することで、このような利害関係者と多くの情報を共有できます。
共有する上で大事なことは、各利害関係者がオーナーシップを持つことです。
ただ、参照可能な場所に置いてあるというだけでは、共有したことにはなりません。
Basecampの作りがシンプルであることも、メッセージやコメントがいたるところに残せることも、
利害関係者にオーナーシップを持たせることにすごく寄与していると思います。
—-
アジャイルなソフトウェア開発は、イテレーティブ（反復的）に行われます。
ソフトウェア開発は、最初から最後まで舗装された一本道を歩いていけるわけではないのです。
例えて言うなら、地図を頼りにチームでコミュニケーションをとり、周りを観察して山道を探しながらチェックポイントを目指す、オリエンテーリングのようなものです。
（この例えは増田さんに教わりました。）
途中で変だと気づいたら立ち止まる。反復して実践を行い、頻繁に計画を見直しながら進んでいく。
Basecampのマイルストーン・ToDoリストの考え方は、まさしくこれにマッチするものです。
ガントチャートで進捗を管理しているチームは、大抵、計画の変更を嫌がります。
一本道を一定の速度で歩いていって、時間内にゴールする計画を立てているわけですから、
何か起きたら時間内にゴールできないことが分かっているにもかかわらずです。
（時間内にゴールできないから嫌がるんですが。）
タスクの詰め込みすぎも、計画の変更を嫌がる要因のひとつです。
なんとか詰め込んでできた計画は、変更なんてできるわけがありません。
情熱を持ったエンジニアも、そんな計画のために酷使したら情熱が冷めてしまいます。
—-
他にも書きたいことはいくらもあるのですが、このあたりの話は、私が言うより、神崎さんのブログを読んだ方が早いかもしれませんね。。。
コメントはまだありません。