クラウドコンピューティング ~ EC2、Mosso、GoGrid
クラウドコンピューティングのプロバイダーであるEC2、Mosso、GoGridの新しいユーザーエクスペリエンスと、それぞれの機能の違いについて学びます。
作者 Vikas Hazrati, 翻訳者 渋川 よしき 投稿日 2008年5月24日 午前6時44分
「持続可能なペース」はXPのプラクティス(source)としてよく知られている。ソフトウェア開発というゲームの中にいるチームが長時間走り続けられるためのプラクティスである。このプラクティスはどんなに忙しく働かざるをえなかったとしても、そのペースが持続可能であれば、同じペースでいつまでも働き続けることができるということを示している。人々がいきいきしていれば、より創造的になることができるということである。
しかし、「持続可能なペース」と、一週間の就業時間との間にはなにか関係があるのだろうか?
Henrik Jernevad氏(source)は彼のblog(source)の中で、これらの二つの間には何らかの関係があるのではないかと分析しようとした。Henrik氏によると、すべてのプログラマはそれぞれ「最高の生産性」というものを持っている。もちろん、この生産力はそれぞれのプログラマの能力に依存している。そして、これとは別に「許容量」と呼ばれるものを持っている。これは、品質を下げることなく容易に行うことができる仕事量の最大値である。こられの二つよりも少ないところに「持続可能なペース」がある。もし驚くような結果が出てきたとしたら、彼は週40時間を維持しないで、持続可能なペースの時間を増やすこともできるとblogの中では語られている。安全に週40時間だけ活動するのは時間を無駄にしているように聞こえる。
もし「持続可能なペース」として週40時間ではなくて、週45時間を続けているなら、一年間の開発で一ヶ月余るでしょう。その1ヶ月は追加開発に使うことができます。特に私が働いているような、プロジェクトのスタートアップのところでは、週40時間は得ることができないぜいたくです。
このようにして得た追加の一ヶ月の期間を使うと、その期間の努力にみあったビジネス価値を提供することができるだろうか?
参加者がScrum開発の概念について議論を行っているグループ(source)があるが、このことに関する議論が行われた。多くの参加者は、労働時間数の増加と生産性の増加は線形にはならいないと述べた。他にも、この意見に対して時間数 != 価値(時間数と価値は違う)ということを述べる参加者もいた。労働時間の増加と生産性のグラフを描いた場合、このグラフの中には転換点があり、それを超えると生産性よりも非生産性の方が強くなってくる。Laurent Bossavit氏はこれらの意見とは違う意見(source)を述べた。開発者の時間の変化に対して、イテレーション中のビジネス価値の創出は、大きな視点で見ると関連性があるという意見である。
私の直感では、持続可能なペースで働き、良い開発プロセスを採用しているチームが「価値を作成する」数はイテレーションごとに変動すると思います。これをグラフにプロットすれば指数関数のグラフになるでしょう。開発時間の変動量に対して、全体の価値創造量の変化量は小さくなると思います。(訳注:指数でなくて対数では?)
A similar article on IGDA, summarized a similar finding似たような議論がIGDA(国際ゲーム開発協会)(サイト・英語)のサイトに掲載されている。この議論に関連すると思われる部分を要約してみて以下のような内容となっている。
労働者は稼働日5日、40時間という就業ペースであれば、ほぼいつまでも生産力を維持することができます。もしそれよりも長時間働くと生産力は下がり始めます。4日から2ヶ月という期限を区切って考えると、追加で働いて得られる成果というものは、時間ごとの生産力の低下で打ち消されます。極端な場合(一日の就寝時間を最低7-8時間取るというのを1,2晩やめてみる)には、生産力が急激に落ちることも考えられます。
Henrik 氏はGoogleやMicrosoftの例を引用して、週40時間以上の労働時間の論拠としようとした(source)。
GoogleはFortune誌が行っている「もっとも働きたい企業」に2回連続で選ばれたことがあります。Googleは働く時間を40時間までとは制限していません。
Dan Rawsthorne氏(source)は「持続可能なペース」は時間数とはまったく関係がないという意見を出した。Dan氏によると、コミットメントと技術的な負荷が持続可能なペースの決定要因である。もしチームが技術的な負担がない状態でペースを保つことができるのであれば、時間に関係なくペースを保てなければならないだろう。George Dinwiddie氏はこれに同調し、持続可能なペースというのは振り返りの中で議論されるものであるとしている(source)。
私の経験では、持続可能なペースというはソフトウェア開発の分野では、もっとも効果がない方法です。これはH.L.Menchen氏(アメリカのジャーナリストで、雑誌編集、エッセイ執筆なども行った)の「シンプルで、明確で、間違っている」という言葉ともマッチします。以前、Alistair cockburn氏が嬉々として説明していたように、人間は(時間に比例して結果を出せるような)線形のシステムではありません。インプット(より長時間の労働)と、アウトプット(すぐに得られる成果)が線形の関係であると考えるのは見当違いだと思います。
Joseph Little氏はこの議論の要旨をまとめ(source)るために「持続可能なペースを決定する要因は、労働時間ではなくてより少ない時間で創造的で成果を出せる労働をすることである」という結論を提示した。持続可能なペースを保つためには、働き方の文化や、技術的な負荷、モチベーションなどの数多くの要因に関係があると彼は説明した。そして、時間数からくる影響は少しはあるが、時間数の議論から始めるのは最善の方法ではないと締めくくった。
原文はこちらです:http://www.infoq.com/news/2008/05/sustainable-pace
クラウドコンピューティングのプロバイダーであるEC2、Mosso、GoGridの新しいユーザーエクスペリエンスと、それぞれの機能の違いについて学びます。
パート2では、ベンチマークの結果を検証するために用いられるテクニックについてさらに深く見ていきたいと思います。最後に、「なぜプロセッサが異なるとロックのコストも大きく異なるのか」と言う真の疑問に答えます。
本稿では、Stefan Tilkov氏が「RESTful」な設計であると主張するアプリケーションに見受けられる最も一般的なアンチパターンのいくつかについて説明し、それらを避けるための方法を提案しています。
Sven Efftinge氏、Peter Friese氏とJan Köhnlein氏が、MDDを取り入れて成功した経験から、ベストプラクティスの解説を行います。
Our panel of leading experts explores some of the challenges and thought processes that go into making their apps as scalable and performant as possible.
この記事は、Spring 2.5で導入されたアノテーションを探究する3部作の第2弾です。Web層におけるアノテーションのサポートを扱います。最後の論文では、統合と検査で利用できる追加機能を説明する予定です。
私は「浴衣」を着てパーティーに参加したことで、たくさん声を掛けていただけました。 そこで感じたことは、このカンファレンスが人との繋がりを生み出し、また言葉の壁を越えて積極的に交流する場所であることです。民族衣装はそれらを助けてくれるものでした。きっとこの交流が、新たなムーブメントをアジア圏の仲間たちにも与えてくれると確信しています。
No comments
返信