今年の風邪
は、どうやら、かなりしつこいらしい。
おかげで先週は仕事を休んじまった。さすがに今週もというわけにもいかないので、頑張って出てみた。
さすがにしんどいね。もう帰ろう。
は、どうやら、かなりしつこいらしい。
おかげで先週は仕事を休んじまった。さすがに今週もというわけにもいかないので、頑張って出てみた。
さすがにしんどいね。もう帰ろう。
Basecampは本当に私たちの開発スタイルに合っていると思っています。
一番大きな理由は、やはりアジャイルなスタイルに合うこと。
あと、私たちが開発元の37Signalsの考えともよく合うということ。
彼らが出しているGetting Realという本があります。日本語版もダウンロードして読めます。
(この存在は一緒に仕事をしている徳武さんに教えてもらいました。)
これを読むと、37Signalsのウェブ・アプリケーションに対する考えがよくわかります。
実用的なソフトウェアを作ることに振り切っているところもとても好感が持てます。
(例えば、Microsoft Projectなんかを「ゴリラのようなソフトウェア」と言っています。意味が分かりますか?)
また、彼らはとてもユニークで、
というようなこともやっているようです。おそらく、日本のほとんどの企業では理解されないと思います。もし少しでも理解できたなら、それだけで十分だと思います。
(うちは割りと似たところがあるかな。。。)
—-
「アジャイルなスタイルに合う」というのは、Basecampのビジョンにあります。
Getting Realから引用すれば、
「Basecamp」:プロジェクト管理はコミュニケーション
という、ビジョンです。このビジョンが、
このビジョンにより、我々は「Basecamp」を可能な限りオープンで透明性の高いものにしました。会社内の範囲だけでなく、我々はクライアントとのコ ミュニケーションにもアクセスを広げました。我々は、全てのメンバーの参加の垣根を低くし、サポートするよう考えました。ビジョンは、なぜ我々がチャート や、グラフ、テーブルやレポート、統計、スプレッドシートといったものを省き、代わりにメッセージやコメント、ToDoリスト、ファイルの共有といったコ ミュニケーション機能を重視したのか、という部分です。ビジョンついて大きな視点での決定をしましょう。そうすれば、これからの小さな判断がはるかに簡単 になります。
というサービスを生み出しました。この「ビジョン」こそがアジャイルなソフトウェア開発に合うところです。
—-
アジャイルなソフトウェア開発は、人とのコミュニケーションを重視します。
チームではドキュメントをやりとりする代わりに、コミュニケーションでカバーし、開発速度を上げます。
顧客コミュニケートすることで、問題領域を明らかにし、解決していきます。
また、今時のソフトウェアはネットワークを介して他のソフトウェアと連携しながら動くものがとても多いです。
そのような場合、クライアントや他の開発チームとのコミュニケーションも非常に重要になります。
逆に言えば、そのようなコミュニケーションの不足がプロジェクトが失敗するポイントになりやすいところです。
(今まで何度それで失敗するプロジェクトを見てきたことか。)
Basecampを利用することで、このような利害関係者と多くの情報を共有できます。
共有する上で大事なことは、各利害関係者がオーナーシップを持つことです。
ただ、参照可能な場所に置いてあるというだけでは、共有したことにはなりません。
Basecampの作りがシンプルであることも、メッセージやコメントがいたるところに残せることも、
利害関係者にオーナーシップを持たせることにすごく寄与していると思います。
—-
アジャイルなソフトウェア開発は、イテレーティブ(反復的)に行われます。
ソフトウェア開発は、最初から最後まで舗装された一本道を歩いていけるわけではないのです。
例えて言うなら、地図を頼りにチームでコミュニケーションをとり、周りを観察して山道を探しながらチェックポイントを目指す、オリエンテーリングのようなものです。
(この例えは増田さんに教わりました。)
途中で変だと気づいたら立ち止まる。反復して実践を行い、頻繁に計画を見直しながら進んでいく。
Basecampのマイルストーン・ToDoリストの考え方は、まさしくこれにマッチするものです。
ガントチャートで進捗を管理しているチームは、大抵、計画の変更を嫌がります。
一本道を一定の速度で歩いていって、時間内にゴールする計画を立てているわけですから、
何か起きたら時間内にゴールできないことが分かっているにもかかわらずです。
(時間内にゴールできないから嫌がるんですが。)
タスクの詰め込みすぎも、計画の変更を嫌がる要因のひとつです。
なんとか詰め込んでできた計画は、変更なんてできるわけがありません。
情熱を持ったエンジニアも、そんな計画のために酷使したら情熱が冷めてしまいます。
—-
他にも書きたいことはいくらもあるのですが、このあたりの話は、私が言うより、神崎さんのブログを読んだ方が早いかもしれませんね。。。
私たちの間では、主にBasecampをプロジェクト管理に利用しています。
「なぜBasecampを使うのか?」
と聞かれれば、
「私たちのやり方に合っているからです。」
と私たちは答えるでしょう。
ただし、万人に理解を得られるものではないこともどうやら事実のようです。
—-
そういえば、以前こんなことがありました。
とある企業にサービスを提供することになり、専用のアドオンを開発していたときのこと。
クライアントに提出工数と見積金額に納得してもらうために、スケジュールとタスクを出すよう営業マネージャから依頼がきました。
Basecampでマイルストーン・タスクを設定していたので、私はBasecampで一覧を出してそれに大体の予定工数を書き入れて提出しました。
営業マネージャは、それを見るなり驚いて、
「これが管理表なの?タスクって、開始日と終了日があるものなんじゃないの?これにはどうしてそれがないの?」
と言われました。どうやら彼はガントチャートが出てくることを予想していたようです。
(暗に「こんなんでいいのか?」って言われているわけです。)
—-
この問いに対する答えは、RDRAの開発者神崎さんのブログにいいものがあります。
私の考えもほぼ同じで、この時はマイルストーンをほぼ1Wおきに置いていました。
だいたいチェックのタイミングも週単位です。進路変更したり、手を打ったりするのもこのタイミングが多いですから、こういう単位でプロジェクトの進行を考えると、取扱いやすいです。
今でもプロジェクトを起こすときには、マイルストーンを1Wぐらいに置き、週単位の目標を明確にするようにしています。この時は1ヵ月半ぐらいの短期決戦だったので、結構タスクは見通せてはいたのですけれどね。
神崎さんのブログ記事を読めば分かるのですが、お互いの考え方やアプローチの違いがこういう発言につながっています。
正直、営業マネージャにいくら説明しても理解を得られるような気がしなかったので、
「うちはそういうスタイルなの。」
で、この時は押し切っちゃいました。
—-
この時はこれで済ませられましたが、おそらく、これで済ませられない場合もあるでしょう。
その時はどうするかって?神崎さんのブログ記事でも読んでもらいましょうか。
月 | 火 | 水 | 木 | 金 | 土 | 日 |
---|---|---|---|---|---|---|
« 3 月 | ||||||
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |