-
Notifications
You must be signed in to change notification settings - Fork 0
Making Software――エビデンスが変えるソフトウェア開発
- ソフトウェア開発において、集中できる個室がいいのか？コミュニケーションの取れる共同作業場がいいのか？を論じた章
- 結論としては、プロジェクトの性質によって使い分けろということ
- 細かい仕様が固まっていてそんなに多数の人と密なコミュニケーションが必要でないなら個室
- アジャイル的な大きな目標だけあって、多数とコミュニケーションを取る必要があるなら共同作業場
- パーティションは両者の悪いところどりなので、どっちかを選択すべきとのこと
- 共同作業場が基本にあって、いくつかのプライベートな集中作業場があるようなハイブリッドな環境もよかったとのこと
- 下記は特に心に残った部分をメモする
そのような深い集中の最も望ましい状態をフロー(flow)呼び、完全な没入状態、人の活動とスキルと目標が調和する体験であるとしています[Csikszentmihalyi 1990]。フローの話を聞いたことがあれば、フロー状態に入るには時間と努力を必要とすること、その状態はとても壊れやすい状態だということ、創造的活動を成功させる上で極めて重要なものだということもご存じでしょう。
あいにく、フロー状態はソフトウェア開発者たちを通常の環境に置いておいたのでは、なかなか到達しにくいのです。このことは、多くの研究で開発者たちが常に割り込み攻撃に遭っていることが報告されているので、分かります。
*snip*
必要なら開発者たちが自分 1 人になれるようにオフィス空間のレイアウトを設計する方向に導きます。その根拠は、1 人になることで割り込みが減り、より多くのより深い集中ができるようになり、それにより効率が高まり製品の品質が向上する、という推論が成り立つからです。
*snip*
理屈は分かりますが、それを裏付けるエビデンスはあるのでしょうか? 実はあるのです。トム・デマルコとティム・リスターによる、ソフトウェア開発に関する最も有名で世に知られた著書のうち 1 冊 を構成する中心的側面の 1 つが、そのようなエビデンスです
-
コーディング合戦と名づけたコンテストを行った結果、戦績が良かった人は悪かった人と比べて良好な環境があった- 作業空間が広く、静かで邪魔が入りにくい環境だった
- よって、閉じるドアな環境には優位性がある
前節の議論には問題があります。デマルコとリスターの調査では、競技者は「個人で」作業していました。個人でコードを書き、テストし、そして個人別に順位をつけます。重要なのは、「自分の」問題を解くのにできる限りの最善のやり方で「自分が」集中できるか、ということでした。
しかし多くの場合、ソフトウェアはそのようには開発されません。1 人ずつが自力で問題と戦うのでなく、チームの一部として戦います。個別の作業の成果が、多数の他者の成果と相互に作用し合うのです。一緒のチームに属して、助けてもらったり、助けたりします。従って誰もが、プロジェクトのあいだじゅう常に、同僚とコーディネーションを行ったり、コミュニケーションを図る必要があります
- 通常のプロジェクトは1人で行うものではないので、
コーディネーションが重要になる
Herbsleb と Grinter は、直接性の欠如が問題になったケースを報告しています。彼らは地理的に分散したプロジェクトによって構築されたコードを統合しようとする様子を観察し、インフォーマルなコ ミュニケーションチャネルが無いことが原因で、統合がプロジェクトの一番困難な作業となったことを報告しました[Herbsleb and Grinter 1999]。
*snip*
それほど離れた場所ではなくても、そういうことはあるのです。問題の 1 つは、互いが自分の机から ちょっと歩いたところ(30 メートルくらい)にある場合でも、それは異なる都市にあるも同然だということです。なぜなら、気軽にしゃべりに相手を訪れる機会が劇的に減るからです[Allen 1977]。Olson らは、チームが全く同じ場所にいるのでない時に、コミュニケーションが無くなる理由を他にもたくさん列挙しています。
*snip*
私が見つけたうちで最も確信できるエビデンスは、Teasley らの調査によるものです。彼らは、自社のソフトウェア開発プロジェクト用に、ウォールーム†を、最初は試験的プログラムとして、後にはほとんどの自社開発向けに採用した、Fortune 100 に入る自動車会社を対象として調査をしました。ウォールームでは、全プロジェクトメンバーがそれぞれワークステーションを持ち、彼らの大半は巨大な机の周囲に座っていて、壁にはホワイトボードがあります。すぐ近くにいくつかのプライベートなパーティションが利用できるようになっていて、そこにも電話とコンピュータが備わっているので、チームメンバーは静けさやプライバシーが必要ならそちらへ行くことも選択できます。調査では、いくつかの生産性メトリクスとチームメンバーのウォールームに対する満足度を記録しました[Teasley et al. 2002]。
結果は、パイロットチームを強く支持するものでした。彼らは生産性に関して会社の基準よりも 2 倍 も良い性能を挙げ、さらに少数のチームメンバーはその設備では居心地よくないと言いましたが、大半の人はウォールームを気に入り、高密度なやり取りを心地よく感じるようになり、以前のパーティションよりも気に入ったのでした。
*snip*
このエビデンスに基づくと、ある種の共同作業場、1 つの部屋で仕切りのない 1 つか 2 つの大きな机 のまわりに皆が一緒に座っているようなチームを持つのが有利なように思われます。たっぷりある壁はホワイトボード用のスペースで、誰かが本当に孤独になる必要がある時は、すぐ近くに 2、3 室のプライベートルームもあります。このようなレイアウトが、メンバーのコーディネーションと互いに対する意識を最大化するでしょう。
- チームのワークフローにはいくつか種類がある
- ウォーターフロー的に事前に計画があって、コミュニケーションが上から下に単純に流れる場合はコミュニケーションはそんなに必要がない
- 逆にアジャイル的に直近の計画しかなく、多数の人と密がコミュニケーション必要な場合
自分が仮想的なプロジェクトの一員になることを想像してみてください。そのプロジェクトには明確な要求はなく、システムがすべき事柄の大まかなアイデアがあるだけです。目標もはっきりしておらず、できるだけ頻繁にクライアントに機能を提供していくという約束をしただけです。さらに、あなたとチームメイトたちはお互いをあまりよく知りません。彼らとはずいぶん長い間一緒に仕事をしていなかったので、チームメイト 1人ひとりの強みと弱点も知りません。その状態で、みんなが自分の個室に鍵を掛けてこもっているところを想像してみましょう。この状態では、よほど本質的なこと以外では他人に割り込むことはできそうにありません。このような環境で、あなたは何か達成することができるでしょうか?
次に正反対の場合を思い浮かべましょう。チームはやらなくてはいけない事柄をかなりはっきりと思い描いており、広い範囲をカバーし見事に作成された仕様があり、個々の責任範囲は正確に定められています。そして、注意深い計画のおかげで、統合作業もおそらく問題なさそうです。あなたもチームメイトも、1 日数時間のあいだ自分のタスクに 1 人で集中できさえすれば、プロジェクトは完璧に進んで 行きそうですが、ところが、あなたは大きな共同作業空間に座っていて、しょっちゅう邪魔が入って注意が逸らされます。このような環境で、あなたは何か達成することができるでしょうか?
残念ながら、特定のソフトウェア開発チームの事例に対して正しい選択を行うための明確なガイドラインについては、まだ研究結果が出ていません。ここまでに示したエビデンスから得られる最善の結論は、閉じるドアと共同作業場の 2 つのレイアウトいずれもが、チームの実践内容や作業スタイルと適合していれば、利点をもたらすだろう、ということです。
「共同作業場か、閉じるドアか?」に対する答えは「はい」です。つまり、両者は連続スペクトルの両端にあるにも関わらず、双方のレイアウトが、現在標準的なパーティションレイアウトに対する大きな改善をもたらすのです。
パーティションの問題は、それがここまで議論してきた 2 つの極端なレイアウトが持つ欠点のほとんどを兼ね備えているうえに、これらの長所のほとんどは持っていない、ということです。第一に、パーティションでは個室のように孤立できませんから、近くの会話で邪魔されたり注意が逸らされることが 頻繁にあります。ですがパーティションは全くの共有空間でもないので、共同作業場のような、常に互 いにコーディネーションしたり意識しあえる場というわけでもありません。
私の知る限りでは、ソフトウェア開発作業のための他のあらゆる選択肢よりもパーティションの方が優れている、ということを示すエビデンスを提示する文献はまったく存在しません。とにかく可能な限り、パーティションは避けるべきです。集中できること、もしくはコーディネーションできることの、いずれかを選択してください。 どちらも選ばないというのは、かなり馬鹿げたことです。