2011年5月29日

アジャイルスタートアップの後で思ったこと

MIT Media Lab新所長、伊藤穰一とPivotalのCTO,Ian McFarlandが語る「アジャイルスタートアップ」に行ってきました。

自分の認識では Pivotal Labs は Pivotal Tracker を作っている会社でしたが、 アジャイル開発に関するコンサルティングにも取り組んでいるようです (コンサルの方がメイン？)。 クライアント企業 を見てみると、Twitter、 Best Buy、Groupon、Linden Labs、Salesforce、Alexa などが名前を連ねています。 IDEO と協力してコンサルティングに関わることもあるようで、ソフトウェア業界のひとつの最先端、 と呼べる立場だと思います。

今回はそんな会社の CTO と、 MIT Media Lab のディレクター のトークセッションでした。 セッション内容に関しては Twitter を見るなり、もしかしたらネットメディアに取り上げられるかもしれませんので、そちらを参照、ということで。 この記事では、自分がなんとなく思ったことをツラツラと。

自分のメモ:

  • 18:55 - 「今日は通訳がいない」と今気づいたw 今さっき相談して進め方を決めるとは、アジリティ高い。
  • 19:00 - アジャイルのストーリーボードとかスプリントの説明から。方向性だけ決めておく。Pivot で細かい部分はサクサク切り替える。Pivotal の由来はそれ。
  • 19:03 - 「テストを書く方が実際のコードより多い」。RoR での TDD の実例と絡めた話。テストは自然言語で書くから、ビジネスオーナーとのコミュニケーションやリリースタイミングが分かりやすい。
  • 19:08 - タスク群に対して velocity を管理し続けるから、開発者の健康には良いかも。締め切りを厳密にするのではなく、このままのペースで進めばいつまでに機能を充足できるかを見積りできそう。
  • 19:11 - 8時45分に朝ごはんを用意。それに合わせて出社。Pivotal さんは朝早い！125人くらい。
  • 19:14 - 「コードを書いてるときにイノベーションを生み出してはダメ！」新しいことはストーリーボードを作っているときに。
  • 19:19 - プロトタイプ (テスト無し) をプロダクション (テスト有り) に書き換えるときはバグも含めてそのままに。ついでに機能追加とかダメ。
  • 19:27 - 大きな機能や思い入れのある機能を捨て去るのは心情的に悩ましい。ストーリーが細かく分割されていれば、軌道修正 (Pivot) に取り組みやすい。
  • 19:40 - 「Zynga なんかのプロダクトマネージャーはみんな SQL をたたいて、データドリブン」... えっ(-_-;)
  • 20:18 - ペアプログラミングだとふたりで同じことやるから全体の生産性は落ちるのかも、とか思っていたけど、ペアプロ中はメールも YouTube も見ないから集中力が高い状態に追い込まれる、と。。普段がいかにぬるま湯かを思い知らされた感じ。とても勉強になりました。

朝会 (daily standup meeting) も良いですが、 朝食を用意した方が色々と嬉しい人も多いかもしれませんね。

アジャイルって？

アジャイルソフトウェア開発 を略して「アジャイル」で、英語だと "agile" です。 "agile" は日本語だと「機敏な」や「敏捷な」という意味で、 RPG (ロールプレイングゲーム) の「素早さ」を表すパラメータに "AGL" を使うものもありますが、 これは "agile" からの３文字になります。 要するに、高品質なソフトウェアを素早く提供するためにはどうすれば良いか？という課題に対する ひとつのアプローチと言えます。

より詳しくは「アジャイルソフトウェア開発宣言」 (The Agile Manifesto) があります。 今年の２月で10年を迎えていますので、この10年の変化を振り返りながらいろいろな記事が発表されました。 個人的に印象に残ったのは次の記事です。

ざっくりした内容は次のようになります。(引用や翻訳ではありません)

この10年で言葉と考え方が浸透してきたこと、実践すべきだ！との認識も増えてきており、 部門長に提案するときには議題に上げるべきでしょう。 また、- "We stop talking about agile." - つまり、それが何であるかを議論するフェーズから、 それをどのように実践するか、ベストプラクティスは何か、といったことを議論するフェーズになりつつあります。 例えば、オブジェクト指向プログラミングを語る際に、「オブジェクトとは何か？」を議論するフェーズは過ぎ去り、 OO (Object-Oriented) な考え方は当然ともみなされていますよね？ アジャイルに関しても同様です。もはや実践して然るべき概念なのです。

ウォーターフォール開発

アジャイル開発と比較してウォーターフォール開発が挙げられます。 "waterfall" は滝のことで、水が溜まったら上から下へと一気に流れる様子から、 要求獲得、仕様作成、システムの実装、検証を順番に実施する開発モデルを表現します。

滝が勢いよく流れ落ちるためにはたくさんの水を溜める必要があり、通り道に遮蔽物が存在しない方が望ましいですね。 ウォーターフォール開発も同様で、要求が適切に検討されて、実装がスムーズに進むように準備しておく必要があります。 要求 (実現したいこと) が曖昧で、製品開発と技術研修が混在している状態では、勢いよくシステムを開発することは難しいでしょう。 水はいつしか地面に辿りつき、地面に浸み込んだり蒸発したり、あるいは海に流れ出ることもあります。 しかし、コンピュータシステムはそうもいきません。 時流に乗って多くのユーザーを獲得できる Web サービスや、いつまでも使われる社内システムは確かにあります。 それは幸せなことですが、あくまで一握りの成功例。 予算を割り当てて多くの人員を投入し、せっかく作ったものが負債になってしまっても、それを無に帰すことはできません。

無かったことにはできない、という点ではアジャイルも同じですが、 ウォーターフォールに比べて、こまめにフィードバックを受け取って軌道修正を重ねる、という点が違います。 どちらも一長一短ですし、要は方法論なのでどっちでもいいじゃん、と言えばそうかもしれません。 しかし、いつフィードバックを受け取るか？という部分に心理的な違いがあります。

締め切り意識

たいていの受託開発は、契約で決めた納期に成果物を提出し、場合によってはその後の保守を請け負います。 契約開始時点では、期日と何らかの要件を決めますね。 機能の一覧だったり性能要件だったり内容は様々ですが、何らかのゴールが契約書という形で存在します。

一方で自社製品開発の場合は、社内の誰かしらが製品企画を取りまとめます。 売り上げ予測だったり開発工数だったりを算出し、リリース期日を設定します。 期日に合わせてプロモーションを進めているかもしれません。 これがプロジェクトメンバーのゴールとなります。

どちらの場合も、締切日が存在します。

ちょっと話題を変えて、小学校の夏休みの宿題を振り返ってみます。 多くの小学校 (地域により違いはある) は、9月1日が二学期の開始です。 この日が夏休みの宿題の締切日とも言えます (最初の授業で提出する場合もあるが、そこは気にしない)。 さて、宿題の進捗状況はどうだったでしょうか？

  • 最初の数日で計画を立て、徐々に進めて、最後の数日で細かい部分を調整する。
  • とりあえず最初は何もせず、最後の数日で一気に片付ける。
  • 時期とは無関係に自分のペースで進めて、夏休みの中盤には終わってる。
  • 時期とは無関係に自分のペースで進めたものの、全ては終わらなかった。

「なぜもっと早く着手しなかったの？」と問われれば、「ギリギリの方が本気出せるから」と答える人も多いでしょう。 それはそれで正しいことだと思います。 この場合、締め切りが存在すればその日までに完成するでしょうが、その前には完成しません。 フィードバックを受け取れる状態になるのは、締め切り直前でしかありません。

一方で、一定のペースで進めた場合には、終わるかもしれないし終わらないかもしれないし、 常に不完全かもしれませんが、いつでもフィードバックを受け取れます。 もしかしたら、スピードを上げるために友達に相談できるかもしれません。 爆発的な推進力に欠けるかもしれませんが、次に何をすべきかの判断材料には事欠かないでしょう。

夏休みの宿題は個人の話なのでどちらでも構いませんが、関係者が増えてくると状況が異なってきます。 最終成果物の前にレビューを実施するとなれば、その前に途中成果をまとめる必要があるかもしれません。 わざわざまとめる時間がかかるのに、その効果が分かり難い、という理由で、レビューが敬遠されるチームもあるでしょう。 レビュー結果を反映したものを再レビューになれば、もっと時間がかかります。 たとえ実施したとしても、いわゆる「締め切りに追われる」状態に陥ってしまい、体力的にも精神的にも長くは続かないかもしれません。

マインドを変える

締切駆動に反して、Velocity (速度) という考え方があります。 「いつまでにここまで進める」のではなく、「ここまで進むためにはこれだけ時間がかかった」ことを管理し続けていく手法です。 チームのメンバーが変わらない場合、速度が分かれば将来の予測を立てやすくなります。

同じ難易度のタスクが10個存在 (実際には有り得ないが) したら、ひとつに1週間かかるなら全部終わるまでには10週間かかる、と言えます。 同じペースで進める、それぞれのタスクが独立している、の二点が大事だと思います。 つまり、全てを実現しなくとも、競合企業に対抗するためやユーザーの反応を見るためには途中でリリースできる状態です。 4週間でリリースして4週間は反応を見ながら開発を進めて、実は不要だったと分かれば、その後の2週間は軌道修正できます。 締切駆動にパレードの法則が重なってしまうと、最後の2週間に全体の8割を実現する計画になるかもしれず、それを修正する術はありません。

「そうは言っても自分は計画的だ！」と主張する人もいるかもしれません。 ただ、その人の周りにいる全ての人も計画的だとは限りません。 人間がふたり以上集まれば意思疎通が必要です。 目的地を設定して出掛けるのか、とりあえず出掛けてみてから目的地を見つけるのか、その意識合わせが大切になります。

目標意識を共有せずとも良い、あるいは無計画でも良い、とは違います。 特定の部分 (時期の問題と人の問題) にしわ寄せがいかないようにしましょう、と言えるかもしれません。 極端かもしれませんが、特定の人が特定の工程に責任を持つモデルがウォーターフォール、 みんなが全体に責任を持つモデルがアジャイルとも考えられます。 チームの構成メンバーや何を実現すべきかに合わせて、考え方を切り替えるべきでしょう。

なお、チームとしての Velocity を維持するためには、そのタスクに要した時間を管理しておかなくてはなりません。 時間管理に関してはポモドーロテクニックなどが役立つかもしれませんね。

終わりに

興味のあったイベントに行ってきました。 簡単に感想でも書こうかな、と思いましたが、ちょっと違う切り口で自分の考えを整理してみることも良いかな、と考え直し、 アジャイルとウォーターフォールのひとつの側面を対比させてみました。

とにもかくにも、方法論を変えるためには、関係する人たちの考え方も変えなければなりません。 現在実践していることと検討していることを対比させながら、何に似ていて何とは違うのか、 メリットとデメリットは何かを明らかにしていく、という、普通のことを普通に実行する必要があるでしょう。

「ウォーターフォールは古臭いから、これからはアジャイルだ！」と主張したいのではなく、 いくつかの方法論がありますが、それぞれを使い分けるためにはチームメンバー (もしくは外部の関係する人たち) の考え方を変える必要がありますね、という話です。 どんな病気においても特効薬はありませんので、医師にすがりつくだけでなく、患者と医師が協力して健康を維持できるようになると良いですね。

まぁ「人月の神話」を読んで実践すれば良いんじゃ... という話なのかもしれません。 出版から数十年が経過しても変わらない考え方が存在することは間違いありません。 表現方法を少しずつ変えながら、多くの人に分かりやすくなっていくと良いのかな。

ラベル:

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)