トップスポーツチームの監督に教わる秘訣
この論文では、氏が発見した原則を要約し、その原則をいかにしてソフトウェア開発に応用するかを説明します。
News
カムリ・ハイブリッドのチーフ・エンジニアの死亡に対して、過重労働であるとの判決が出た。
作者 Mark Levison, 翻訳者 James Neoman 投稿日 2008年7月31日 午後12時42分
先月、日本の裁判所で、カムリ・ハイブリッド・プロジェクトのチーフ・エンジニアの死亡(リンク)は『過労死』（働き過ぎが原因の死）であるとの裁定がおりた。そのチーフ・エンジニアは、最後の数ヵ月は、1ヵ月につき80時間以上も時間外労働をしていた。彼は、デトロイトの自動車ショーへ飛んで行く前日に、心臓発作で亡くなった。
この物語は、我々に、トヨタから学べること、持続可能な努力、我々がソフトウェアを開発する理由について、数多くの興味深い問題を提示してくれた。
Joe Little(リンク)は次のように言っている。「リーンは、システムに必要以上に負担を掛けないという原則を持っています。」そして続けて、「過度の時間外労働は、トヨタでのリーンの根本的な部分なのか、それともあるいは、特定のグループに固有のものなのかでしょうか？」と問いかけている。最後に、Joeは「たとえリーンがトヨタが考え出したものだとしても、それは完璧だという訳ではないでしょう。(リンク)」と指摘している。それでも、我々はトヨタからも他のリーンの実践者からまだまだ学べることはある。
Robin Dymond(リンク)は以下のように述べている。
これは、悲しいことだが、その一方で興味深いことでもあります。トヨタが採用しているリーン製品開発モデルは、製品のオーナー、スクラム・マスター、技術的なリードをチーフ・エンジニアという1つの役割に纏めてしまいます。Mary Poppendeickと私は、どうやったら、このリーダーシップ・モデルをソフトウェア開発にもあてはめられるだろうかという話をしてきました。私の抱えている問題は、製品のオーナーがすでに過負荷な役割で、スクラム・チームにとってもアキレスのかかとであるということです。私はいつも、さらなる技術的およびプロセス上の責任を追加するには、あまりに英雄的でなければならず、持続可能でないように感じてきました。このことこそが問題なのではないかというように見えます。
Lean Software Developmentの著者でもあるMaryは、自身が3M社で製品チャンピオンであった頃を思い出しながら以下のように言っている(リンク)。
良いチームでは、自分たちが開発している製品への情熱から、過負荷や時間外労働を、チーム・メンバー自身が、自分たちに課したものです。私も、製品チャンピオンが、全知全能だとは思いません。そうではなくて、単に、チームに情熱を起こさせることができるビジョンをもつ人です。製品チャンピオンだった頃、私は、確かに、自分だけでは、製品のオーナーに期待されるものでさえ全部を実行することはできませんでした。しかし、私はチームに適切な人々を引っ張ってくる術を確実に知っており、ゴールを達成できるように彼らを仕事をしてもらうこともできました。それで、技術的なおよびマーケティングで必要なことは全ては実行できたのです。
Maryは、さらに、いかなる役割も、それが、チームと共有している責任のチェックリストではなく、自身でやらないといけないことを並べた長いリストになるとひどいことになると続けた。
最後に、厳しいデッドラインの問題とマネージメントに仮定されている一定の能力に関して、Maryは次のようにコメントしてくれた(リンク)。
おそらく、先に述べたような症状にしてしまうような最大の問題点は、ソフトウェアが何らかの理由でシステム全体、もしくはそのシステムの全体的なビジネス上の目的から分離されているらしいことです。そうすると、もちろん、それに熱心になることができるような人はいません。チーム・メンバーが、スケジュールが本当にどれくらい重要かとか、実現が困難なその機能は、本当のところどのくらい重要なのか、長期的に見たとき、どのテスト戦略がベストなのか、本当のシステム・コストどこに起因しているのかについて、有効な判断ができるように、我々はソフトウェアを開発するのを止めて、重要な目的達成を支援するようなシステム構築を始めないといけません。
原文はこちらです：
関連情報
12/16 ～野村総合研究所が提案～ 「不況を乗り切る！効果的なIT投資を考えるセミナー」
12/5 CSQ会員限定技術情報交換会にてJCP議長が標準化について語る
【無償】「Google Apps 企業向けソリューションセミナー」のご案内
No comments
返信