Scrumの共同開発者、ケン・シュワバー氏への6つの質問
トッド・ビショップ著
ソフトウェア開発者であり業界コンサルタントでもある Ken Schwaber 氏は、Scrum ソフトウェア開発手法の考案者の 1 人であり、アジャイル開発手法の広く認められたリーダーでもあります。アジャイル開発手法は、チームがより柔軟に、プロジェクトの変化するニーズに対応できるようにする、ますます人気の高いアプローチです。
シュワバー氏は4月上旬にシアトルで開催されるALMフォーラムで基調講演を行い、「アジャイルの現状」と、これらのソフトウェア開発手法の有効性を定量化する新たな取り組みについて講演します。GeekWireはALMフォーラムのメディアパートナーであり、ALMに関する講演に先立ち、先週、シュワバー氏とSkypeで面談することができました。
私たちの会話の編集された抜粋を引き続きお読みください。
Scrum とアジャイル ソフトウェア開発手法について簡単に説明してください。
30日以内にソフトウェアを開発するお手伝いをしています。あなたの最も重要なものを教えてください。30日後に、できる限り多くの情報を提供します。
最初にこれらのコンセプトを思いついたとき、この方法がこれほど普及すると想像していましたか?
全く想像もつきませんでした。ジェフ（サザーランド）と私は、会社を救うためにウォーターフォール方式を採用しました。当時、私たちはどちらもかなり不安定なオブジェクトテクノロジーを使っていて、膨大な数の変更が必要な製品を開発していました。そのため、製品の増分を迅速にリリースし、変化する優先順位や不安定なテクノロジーに対応できる方法が必要でした。そこで、自分たちの生き残りのためにウォーターフォール方式を考案し、その後、所属していたいくつかの会社で実験しました。当時は想像もつきませんでしたが、ウォーターフォールは私たちの業界に起こった最悪の出来事だと考えています。ですから、ウォーターフォール方式が実現したことを嬉しく思っています。
ウォーターフォールはなぜこの職業史上最悪の出来事だったのでしょうか?
それは皆を失敗へと導きます。複雑な技術、人材、そして多種多様な態度やスキル、そして変化する要件や要望など、それら全てを事前に正確に予測できるという期待から始まり、その計画を維持し、堅持しようとする担当者を任命します。しかし、最も賢明なのは、前進する中で発見したものを変え、それを活用することです。ウォーターフォールはそうすべきではないと言います。それは常識と権威を対立させるだけです。これは良いことではありません。
アジャイルとスクラムのテクニックは、ビジネスや生活の他の分野にも同様に適用できますか?
デイビッド・スターは、毎日スクラムを実施し、毎週計画会議（PDF）を実施することで、家族経営をしています。ある営業部門はスクラムで運営されています。年間目標を設定し、毎月、何をやるかを計画し、達成できたかを確認し、それに応じて業務を調整し、前進していきます。経験的、反復的、漸進的なアプローチで行われなかった唯一のものは、ソフトウェアでした！ソフトウェアは、それらの中で最も複雑なものです。本当に奇妙です。
企業やソフトウェア開発チームがこれらの原則を実装する際に犯す最大の間違いは何でしょうか?
私たちの組織では、責任者がいて、部下を率いて、指示すれば物事は実現すると信じるように訓練されています。「スクラムで進めます。1年間で、あれこれ期待しています」と彼らは言います。彼らは、人々の創造性は強制できると考えています。ですから、最も難しいのは、マネージャーに、自分の仕事はチームが最善を尽くせるかどうかを見極め、それを実現できるように支援することであり、マネージャーが考える通りに行動させるべきではないことを理解させることです。親になったことがある人なら誰でも、自分の子供とのこの問題をよく理解しているはずです。
マイクロソフトの開発部門は、これらの技術を取り入れるためにオープンで柔軟なワークスペースに移転しました。社内を歩いていると、ヘッドフォンやイヤホンを使っている人が多いことに気づきました。どのようにコラボレーションと集中力のバランスをとっているのですか？
空間を開放し、騒音を響かせることがコラボレーションだと考えがちですが、そうではありません。騒音を響かせることです。人が見える場所にいて、そこに行って黒板に書き始めたり、必要な人をすぐに呼んだりできる。それがコラボレーションです。この不穏な騒音こそがコラボレーションだと誤解されることがよくあります。重要なのは視覚的な合図とアクセスです。
