« 2006年07月 | メイン

2006年08月18日

ひょんなことでNANAイベントに参加しました

今日、汐留で食事をしましたら、某テレビ局で"NANA”イベントをやっていました。

わたし自身は無骨者なので、NANAというのは、もともと少女コミックスが原作で、以前、中島美嘉と伊藤由奈がダブル主演の映画になってたなぁ、ですとか、伊藤由奈の劇中歌"ENDLESS STORY”がとてもいいなぁ、くらいしか知らなかったわけで、原作を読んだこともなければ、むろん映画をみたこともなかったわけです。

さらに知らなかったのは、このテレビ局でNANAのアニメもやってたんですね。ふむふむ、それでイベントですか、という感じです。

で通り過ぎればいいものを列に並んでしまいました。なんて物好きなんでしょう。しかしこの何気ない好奇心が事件を呼ぶことに・・・

イベントは5組が1チームになって、ガイドさんに引き連れられて、NANAのアパートのセットを訪問するという設定だったのですが・・・なんということでしょう。アパートに入る前の壁に4つのパネルが。そしてガイドさん曰く。

”この4つのパネルには、アニメ版NANAで評判だった決めゼリフが、ひとつづつ書いてあります。さぁ、みなさんは登場人物になりきって、このセリフをしゃべってください。”ですって。

私は講演でスピーチするときよりもひきつりましたよ。もうほとんどパニックといってもいいでしょう。なにげなく参加した自分を呪うことしきり。

しかし私の気持ちを察してか、ガイドさんは、私を除く4人の方々をご指名。

”ありがとう。ほんとに当ててくれなくてありがとう。でもみんな、何故そんなにセリフを嬉しそうにしゃべるの?しかも気持ちが完全に入ってるよ。悪いけど、みんな、完璧なアニメおたくだよ。”と回りに聞こえないように独白しながら、アパートに入ると、そこにはなんともうひとつのパネルが!!

"そうだよね。5組いるのに、なぜパネルが4枚しかなかったか、ちゃんと考えておくべきだったよね。でももう遅いよね。多分、この最後のセリフをぼくがしゃべるんだよね。”という感じです。

しかもガイドさん曰く、”このセリフは、NANAの中で、人気投票一番だったセリフです。”だって!!

もう皆さん、”わたしにやらせろ。”という気迫がむんむんです。最近、これほど場違いな場所に居たことってなかったんじゃないかと思うこと、しきり。

そして恐れたことが。

”はい、お兄さん、このセリフをお願いします。”

もうここまで来たら、後にはひけない。私にも意地がある、という感じです。で結果は。

しっかり噛んじゃいましたよ。ははは。笑ってごまかすしかありません。でも皆さんの視線が痛い。

せめて最近、言われたことがない、お兄さんと呼ばれたことで、自分をなぐさめるしかないでしょう。

しかしこれは、2006年度マイ事件トップ10のNo.1になることは間違いありません。

セリフはなんだったかな?

”今夜は一晩中、楽しませてあげる。”

これをしらふで言える人は、本当に立派だと思います。

2006年08月17日

医療サービスにTPSを適用する - その

***本日のエントリーはブログが停止していたときのバックナンバーを順次UPしています。

私が直接、関与するソフトウェア業界を思い浮かべながら、このトピックスを扱い始めて、もう12回にもなってしまいました。この論文は、特定の病院をさして「これこそ医療経営のトヨタである」と言えるものはまだない、としています。

しかし一方で、医療の現場で忙しく働いているのは、聡明にして献身的な人々である。彼ら彼女らはかねてから、検証しながら学習する才能を発揮して、専門領域の知識とスキルを習得してきた。さまざまな専門領域にまたがるプロセスを改善するうえで不可欠なスキルと知識を習得するのに、これほど適した人材がほかにいるだろうか、と締めくくっています。

私もそう思います。そして、私が関与するソフトウェア業界のひとびとも、やはり”これほど適した人材がほかにいるだろうか”とも思うのです。

---このシリーズ終わり---

2006年08月16日

医療サービスにTPSを適用する - その

***本日のエントリーはブログが停止していたときのバックナンバーを順次UPしています。

ただしここで注意を払う必要があると思われるのは、このように導出された解決方法が、他の状況の特定に問題の解決に常に適用できるとは限らないということです。

つまり誰かが導出した解決方法を、HOWとして記憶することが問題の解決につながる保証は無いわけです。ということは、問題解決に至るプロセスを習得することのほうが重要だということなのです。

製造業においても、TPSの導入がうまくいかないということが喧伝されることがありますが、これも本質的な問題はここにあるのでしょう。つまり、TPSをすべての問題を解決してくれる万能のツールだと期待してしまう。

しかし銀の弾丸はこの世の中には存在しないわけです。TPSとは決して問題の解決方法カタログではなく、問題解決に至るプロセスそのものであり、その観点から言えば、THINKING PROECESSでしかないということになりそうですね。

つまり、TPSとは、よく言われる、学習する組織を構築するためのプロセスのひとつなのでしょう。そうは言っても、カイゼンと英語にもなっているような、制度化のしくみを使うことで、このプロセスの定着・浸透を支援することが可能と思われます。

2006年08月15日

医療サービスにTPSを適用する - その

***本日のエントリーはブログが停止していたときのバックナンバーを順次UPしています。

そのためには、当然の帰結として、”あいまいさを排除し、具体性を高める”ことを目的とした対策をとることが解決手段だということになります。

つまり以下を改善の対象にするということになります。

・誰が、どのような処置(サービス)を受けるのか?
・ラインを実装するにあたって、だれが、どの作業を担当するのか(責任)?
・作業を始めるにあたって、どのような合図を用いるのか(連絡)?
・プロセスの各ステップを、どのように実行するのか(方法)?

そして設計と生産に関わるトヨタの従業員は、日常的に、改善のアイディアを、現場とスタッフや監督者と一緒に、何らかのシミュレーションや実験を繰り返し、アイデアをできる限り、早く、しかも安く検証する方法を繰り返し探るとしています。

これはまた、QC活動のような、現場発の改善活動によって支えられているということもあるでしょう。ちょっとおもしろいのは、やはりこれが米国の論文だなと思うのは、改善のアイディアの検証をどちらかというと、トップダウンに行うことについては言及していますが、QC活動のようなボトムアップの活動についての言及がないのですね。トップダウン文化の米国には、ボトムアップの活動はなかなかイメージしにくいということでしょうか。

2006年08月14日

医療サービスにTPSを適用する - その

***本日のエントリーはブログが停止していたときのバックナンバーを順次UPしています。

このように、小さなミスの積み重ねが重大事故を招いた例に加えて、もうひとつ、やはり頻繁に起こりうるであろう例が紹介されています。

これは複数の神経外科医、神経科医、無いか集中治療室のスタッフが病室のすぐ近く、あるいは電話できる場所にいたにも関わらず、ある患者の抗けいれん剤の投薬が遅れ、死亡に至った事故です。

その原因を問われた専門家たちと看護師は口を揃えて、「あの時は自分以外のだれかが投薬を担当していると思っていた」と説明したということです。

このような無意識のたらいまわしと呼ばれる問題は、複雑な組織のマネジメントに関わる”あいまいさ”が引き起こしたものと言えるでしょう。

これもそれまで問題が表面化しなかったとしたら、だれかが率先して行動していたおかげで大事に至らなかったということなのでしょう。

このような問題群を解決するにあたっては何が必要なのでしょう。この解決にあたって、TPSの、たとえばあんどん方式からヒントを得たいというのが、次のテーマになります。

2006年08月13日

医療サービスにTPSを適用する - その

***本日のエントリーはブログが停止していたときのバックナンバーを順次UPしています。

これが保険業界で言うハインツの法則で、300件の”ひやり・はっと”があれば、そのうちの1件は死亡事故のような重大障害につながるというものです。

この論文では、100件のひやりはっとに1件の重大事故としていますから、このケースでも、その背景には100件のミスがなんらかのかたちであったものと推定されます。

問題はそれが重大事故につながらなかったことから表面化せずに、”そのような細かなことは気にする必要がない”というかたちでの、その場しのぎの対処に終ったことが問題だということなのですね。

ソフトウェア開発であれ、製造業の生産管理であれ、医療サービスのマネジメントであれ、基本原則は共通で、同じ欠陥の除去コストは、後になればなるほど、膨らんでいく。しかも×10のオーダーで、ということなのですね。

したがって、重大障害のように、信頼性の阻害・ブランドの低下のような心理的な影響に加えて、訴訟費用ですとか、慰謝料ですとか、あるいは病院に来る患者さんが減って売上げが減るですとか、やはりコスト面のインパクトというものは、とても大きいものになるのです。

そういえば、みずほ証券が東証に対して、訴訟を起こしたというような、IT業界でも、同様な問題が起きるわけですね。これについても、その成り行きについて、結構な議論が沸き起こっていますね。

2006年08月12日

医療サービスにTPSを適用する - その

***本日のエントリーはブログが停止していたときのバックナンバーを順次UPしています。

TPSの”あんどん方式”の根幹をなすこの考え方を検討するにあたって、論文から障害の例を引用してくることにします。

68歳のグラント夫人は、心臓疾患の待機手術から順調に回復していたが、突然痙攣を起こした。・・・・患者は間もなく昏睡状態に陥った。そして7週間後、家族は延命装置の中止を決めた。・・・その後の調べから、当日の朝6時45分、動脈経路が血栓でふさがれていることを示すアラームが鳴り、看護士が処置していたことがわkった。抗凝結剤のヘパリンを投与して血液の流れをよくするつもりだったという。ところが、ヘパリンが投与された形跡はどこにもなかった。

代わりに発見されたのが、インシュリンの空き瓶だった・・・調査当局は看護士がヘパリンではなくインシュリンを誤って投与し、それが患者の死につながったと結論した。

振り返ってみれば、そのミスは無理からぬものであった。インシュリンとヘパリンはどちらも無色の液体である。しかも、それらは大きさも形も似たような瓶に入っていた。ラベルは貼ってあったとは言え、読みにくかった。悪いことjは重なるもので、カート上にそのふたつが隣り合わせて置かれていた。

この悲劇は、多くの医療現場につきまとうあいまいさと、その場しのぎの文化の欠点を描き出している。

・・・

安全性は看護師の注意深さにかかっていた。看護士の仕事がいかに部分的で、あわただしいものかを考えると、最良の状況でもその負担は相当重い。

2006年08月11日

医療サービスにTPSを適用する - その

***本日のエントリーはブログが停止していたときのバックナンバーを順次UPしています。

TPSからの学ぶをまとめた4つのオペレーショナル・エクセレンスのうちのひとつめ:

ゞ般海蓮¬簑蠅あれば、即座に特定し、検証を繰り返すように設計されている。

が意味するところをかんがえていきたいと思います。

TPSのひとつの特徴は、ひとつひとつは小さな改革だけれども、これらがあいまって全体のパフォーマンスに著しい改善をもたらすということだとよく言われます。つまり大規模かつ劇的な効果をもたらすような万能策(=銀の弾丸ですね)を探すのではなく、大きな問題を、扱いやすいように部分に分ける。そして、繰り返し改善を図るということなのです。

コンセプトはわかりました。ではどうやってそれを実行すれば良いかというのが問題ですね。あるいは、そのような文化・規範を、どのように組織に定着させるかが問題、ということになります。

これは単純に言えば、先延ばしにしない、その場しのぎにしない、そのためには、問題の根本原因が突き止められるまで先に進まない、ということなのです。これはTPSで、”あんどん方式”と呼ばれるシステムの、根幹をなす考え方なのですね。

2006年08月10日

今日は名古屋出張

それにしても暑いですね。
まるで太陽に焼かれるために名古屋に来ているような気がします。
東京だってもちろん暑いわけですが、今年も中部以西が暑いみたいですね。
名古屋は景気が良いので、電気をいっぱい使うからでしょうか(なわけ、ないですが)。
しかし駅ビル回りも立派になりましたね。せっかく名古屋に来たので、名物”ひつまぶし”でも食べて帰りたかったところですが、残念ながら夕方から東京で会議。次回の楽しみということにしましょう。

2006年08月09日

医療サービスにTPSを適用する - その

このように考えると、ミスが起こることは必然であり、すると
その何件かに1件かは、死亡事故のような、重大障害に
つながる。

このような状況下で、このようなミスを未然に防ぐことが
できていたとすれば、それは医師や看護士ひとりひとりの
注意深さに完全に依存しているということになります。

医師や看護士の仕事がいかに部分的で、あわただしいもの
かを考えると、最良の状況であってもその負担は大変重い
ことを、この論文は指摘しています。

さらには、根本原因の放置が問題の再発を招くことへの
対処も同時に行う必然性があるのです。

そこでTPSからの学びを、問題の解決に生かしたいという
ことになります。

この論文は、その学びを、"オペレーショナルエクセレンスを
実現させる4つの組織能力”としてまとめています。

ゞ般海蓮¬簑蠅あれば、即座に特定し、検証を繰り返す
  ように設計されている。

¬簑蠅蓮⊃彗な検証作業を通して、ただrちに対処される。

2魴荳は、異分野との協働による検証を通じて、各部門に
  ふさわしいかたちで広める。

ち反イ里△蕕罎覲層で、実験主義者たれと教えられる。

2006年08月08日

医療サービスにTPSを適用する - その

医療過誤の問題は、とどのつまり、

・医療システムは複雑である。
・この複雑なシステムの各機能を整然と統一するメカニズムが
 欠けていることがあまりにも多い。
・したがって、”いつ、誰が、どこで、どのように、なにを”実行
 すべきかがあいまいになってしまう。
・その結果、ミスが必然的に起こる。
・ミスの何件(100〜300)かに1件は重大障害につながる。
・しかし”その場しのぎ”の処置に留まり、根本原因分析と、
 その原因に対する処置がないと、同じ問題が繰り返し起こる。
・ミスの何件かに1件は重大障害につながる。

というロジックで発生することになります。

そしてこれは、医療システムの問題を述べているようでありながら、
このロジック自身は、”ソフトウェア開発システム”の問題、つまり
”ソフトウェア開発プロジェクトマネジメント”の問題でもあるということは
一目瞭然かと思います。

つまり”ソフトウェア開発プロジェクト”は十分に複雑であり、かつ
”マネジメントの本質は、複雑なこと、専門的なことを、実践に
 移すためのものである(ジョアン・マグレッタ)”であるということ
なのですね。

ともあれ、この”医療サービスにTPSを適用する”論文においては、
どのようにこの問題の解決を試みたのか、つまりどのようにTPSを
適用したのかが次の関心ごとということになります。

2006年08月07日

医療サービスにTPSを適用する - その

米国の病院に限定したお話ではないはずですが、医療過誤が起こる
問題のひとつは、”医療システムの複雑さ”にあるということです。

別の言い方をすれば、医療関係者が自分の仕事をどのように遂行
すべきか?さらにはこれらの人たちの仕事をどのように統合すかを
考えるにあたって、”あいまい”な部分があまりにも多いということです。

一般に病院は機能別組織です。したがって、薬の処方は薬剤師の仕事であり、
麻酔をかけるのは、麻酔医の仕事ということになります。
※もちろん、ある規模の病院をここでは想定しています。

このような分業体制では、各機能を整然と統一するメカニズムがえてして
欠けている。しかしこれは、安全かつ効果的な医療サービスを保証するうえで
不可欠のものなのです。

つまりこのメカニズムがないと、誰が、何を、いつ、どのように実行するのかが
あいまいになってしまうのです。

その結果、投薬ミスや患者の放置といったトラブルが必然的に起こるのです。

すると医師や看護士は、とにかく急場をしのごうとするわけです。

正しい調剤を大至急で調剤士に処方させる。紛失したカルテをさがしまわる。

いずれも泥縄の処置なのです。

さらに残念なことには、これが一段落すると、事の発端となった問題を分析し、改善策を
検討することなく、全員が次の問題に移ってしまうのです。

したがって、当然ながら、同じ問題が再発するわけです

そして医療の現場でも”ひやり・はっと”の法則があるようで、投薬ミスによる
死亡事故1件の背景には、死亡に至らなかった事故が10件、何とか被害を
免れた事故が100件あるといいます。

保険の領域のハインツの法則と同じですね。

つまり、確率の問題で、根本原因分析を放置し、同じ問題を100回繰り返せば、
1回は重大障害になるということなのですね。

2006年08月06日

医療サービスにTPSを適用する - その

この論文は米国で書かれたものですから、米国の医療の問題を
取り上げています。例えば、中心静脈ライン(静脈内カテーテル)
の挿入を原因とする血液感染の発症という問題があり、うち15%
以上が死亡しているという、ある種の医療ミスの問題を扱っています。

ちなみに、ある試算によると、1人感染するごとに、数万ドルのコストが
余計にかかるということですが、ピッツバーグの病院では、感染症の
発生率を50%以上、場合によっては90%以上も減らすことに成功して
いるというのです。

これが全米に広がれば、何千もの命と、数十億ドルのコストが救われる
という計算になります。

このような改善事例は、静脈内カテーテルによる感染に限定されないわけ
ですが、これらは医療の安全性、質、効率性、信頼性、適時性に”直接”に
効果をもたらすことができるわけです。

そこでこれらの改善をどのように図ったのかを理解したいわけですが、
そのためにはそもそも"このような障害を起こす問題はなにか”について
理解する必要があります。

2006年08月05日

医療サービスにTPSを適用する - その

”アジャイルソフトウェアマネジメントを考える”コーナーでは、ソフトウェア開発に、
製造業で培われた規範やプラクティス - 例えば TPS (トヨタ・プロダクション・システム) -
を適用することで、生産性と品質の革新が達成可能であることを述べています。

ところでHBR(ハーバードビジネスレビュー)誌の2006.8号が「ものづくりの戦略モデル」
特集ということで興味を引かれ手にとりましたら、医療サービスへのTPSの適用を
テーマとした特集”トヨタ生産方式で医療ミスは劇的に減らせる”が掲載されていました。

”アジャイルソフトウェアマネジメントを考える”が、ソフトウェア開発へのTPSの適用を
テーマとしたコーナーとすれば、この論文は医療へのTPSの適用を扱っているわけです。

どうもこの論文は、2005年度のマッキンゼー賞を受賞したようで、医療素人の私には
ちんぷんかんぷんな内容かと言えばまったくそういうことはなく、ソフトウェア開発の現場が
抱える課題と完全に共通していることに驚きすら感じます。

表面的には、技術や専門知識・技能の問題にみえても、それはヒトの問題である、と
考えれば、課題自身は普遍的な部分で完全に共通しているのですね。

ということで、この論文から得られた気付きを、”アジャイルソフトウェアマネジメントを考える”
のサイドストーリーとして、何回かにわたって取り上げてみたいと思います。

2006年08月04日

「ソフトウェア構成管理」の翻訳本、出ます

私からすると4冊目の翻訳本、「(仮)実践!ソフトウェア構成管理パターン」が
翔泳社から、9月1日に出版される予定です。(多分・・・)

ということで、UTADA HIKARUのULTRA BLUEを聞きながら、精訳に励んでいる
最中なんですよ。

私が最初にてがけた翻訳本は、ソフトウェアテストに関するものでしたが、
この翻訳をやってみようと思った動機は、当時、ソフトウェアテストに関する
良書が大変少なかったのですね。

これはまずかろうということで、2冊ほどてがけさせていただきました。

幸い、いずれもベストセラーになったということで、微力ながら技術情報の
発信に貢献できたかなぁ、と思っているのですが、ふと世の中をみてみると
「ソフトウェア構成管理」の書籍がない!!

日本には2冊しかありません。

しかも1冊は最近、絶版になったとのこと!

これでいいんですか!?という感じです。

ソフトウェアテストと同様に、欧米にはかなりの数の良書が流通しています。

ということで、(予定)9月1日発刊です。

ソフトウェア構成管理のトピックスは、また改めてどこかで扱ってみたいと
思います。

2006年08月03日

風立ちぬ いざ生きめやも

日経新聞の「私の履歴書」に、茶道家の小堀 宗慶さんが、
シベリアに4年間、抑留されていた、辛く厳しい時代のことを
書いていらっしゃいます。

良い時代の幸せを享受してきている私には、本当の意味では
理解が及ばない厳しい世界があったことは、想像に難くありません。

小堀さんは、疲労困憊し、自分の身をどう処すればいいのか、
考えることもできずに自暴自棄に過ごす日が続いていたある日、
長い冬を耐えて花を咲かせた一輪の花に「花の形をした勇気」を
もらい、生きる力をもらったとしています。

そして堀辰雄の「風立ちぬ いざ生きめやも」の言葉を思
い浮かべたと言います。

篠原暁子さんのWEBサイトの解説によると、堀辰雄は、自ら結核を
病みつつ、自分よりも重い病を持つ婚約者とサナトリウムに入り、
その婚約者を見送りながら、この言葉を書いたといいます。

 『風立ちぬ』は「序曲」から始まる。病気の予兆ははあるが、まだすこやかな様子の若い女性が、熱心に絵を描く姿が映し出される。そして、まだ少女らしさの残った無心な美しさに、心ひかれる青年(私)がいた。

 何もかも始まったばかりで、「何物かが生まれて来つつあるかのよう」な希望のひとときに、不意にどこからともなく、風が立ったのである。

  風たちぬ、いざ生きめやも

 不思議な美しさをもった詩句である。どこか不安な風のざわめきに、心をふるい立たせている繊細な魂、「さあ、何とか生きてみよう」と自分に言いきかせるような、また呼びかけるようなフレーズである。

 「生きめやも」という文語的な表現は、元来は反語の意味をもつ。しかし、作者がフランス語の副題、ポール・ヴァレリイの原詩をつけているところから、「生きることを試みなければならない」という直訳の通り、意志的にとるのがよいだろう。生きようとする意志と、その後に襲ってくる不安な状況を予覚した「いざ生きめやも」なのである。

たしかにこの言葉の解釈には、諸説あるようです。

しかし、私もあえて「さあ、何とか生きてみよう」と自分に言いきかせるような
フレーズとして、意志的に解釈したいと思います。

2006年08月02日

アジャイルソフトウェアマネジメントを考える - その

このテーマも10回目にして、ようやくひとつの結論に至ったようです。

昨日のセミナーで、JUASさまが主張された”プロセス志向からプロダクト志向へ”の変革!!まったくそのとおりなのです。

そして、”アジャイルソフトウェアマネジメントを考える − その”の結論は

そして、アジャイルソフトウェア生産システムによる、望ましい適応性のある振る舞いとは、”顧客にとって価値がある正常に機能するコード”で示されるのです。

でした。

これは、アジャイルソフトウェアマネジメントが、完全にプロダクト志向であることを意味しています。

昨日、私はこのように述べました。

でもクライアントにとって重要なのは、時間とコストを費やしたという結果ではなく、クライアントにとって必要なソフトウェア(プロダクト)が、どれだけのスコープでどこまでの品質を確保してデリバリされたかということ。

つまり顧客にとって意味を持つのは、顧客にとって価値がある正常に機能するコード、でしかないのです。そして、顧客にとって価値があるとは、顧客の要求を満たしているものに他なりません。

よってアジャイルソフトウェアマネジメントにおいては、”顧客の要求=フィーチャー”がすべてのベースラインとなるのです。従って、フィーチャー駆動型開発であるべきなのです。

だからアジャイルソフトウェアマネジメントは、完全に顧客志向の、よってプロダクト(成果物)志向の、フィーチャー駆動型の、さらに言い換えると品質駆動型のアプローチなのです。

品質とは誰かにとっての価値である。

              ワインバーグ

2006年08月01日

ソフトウェア・サーベランス・セミナー開催

IT記者会さま主催の「ソフトウェア・サーベランス・セミナー」で
JUAS細川専務理事さま、インドのテストアウトソーシングサービス
ベンダー、スタッグ社CEOのアショックさまと、講演をさせていただ
きました。

プログラムは以下のとおりです。

道先案内 「ソフトウェア・エンジニアリングとソフトウェアの品質」
             独立行政法人情報処理推進機構SEC
■ 「ソフトウェアのバグはなぜ発生するか」
   (プロセス志向からプロダクト志向へ)
   講師:細川泰秀氏(日本情報システム・ユーザー協会専務理事)
■ 「テスト駆動型開発によるテスト品質の確保−実践事例」
   講師:宗 雅彦
■ スタッグ社におけるソフトウェア・サーベランスの実際」
  講師:T.アショック氏(インドSTAG Software社創立者・CEO)

インドのテストアウトソーシングサービスベンダーの方から直接お話を
聞くのは初めてでしたので、大変楽しみにしておりました。

インドはCMMのレベル5をとっているソフトウェア会社が多数あることで
有名ですが、スタッグ社もその中でテストビジネスに取り組んでいるだけ
あって、テストアプローチは、技術的にみて、とても体系だっており、
確立されているなぁ、という印象です。

誤解を恐れずに言いますと、日本の検証サービスベンダーは、技術的に
学ぶべきところが大変あるのではないでしょうか。

一方、課題は、日本のお客様とどうやってコミュニケーションをとるかと
いうところかもしれません。スタッグ社の技術体系を適確に日本のクライアントに
伝えることができること、そのうえで、仕様をクライアントとスタッグ社の間で
橋渡しできること。

実績を楽しみにしたいと思います。

JUAS細川さまのお話は、いつもどおりの豊富なメトリクスに裏付けられた
示唆深いお話です。結論としての、開発プロジェクトのマネジメントを
プロセス志向からプロダクト志向へ変革しようとのご提案。

200%賛成です!!

ソフトウェアのバグを予防するため、という観点ではなく、プロジェクトゴールである
QSCD目標達成のためには、プロダクトのスコープと品質に焦点をあてた
マネジメントにすべきというご主張です。

そのとおりです。

私も質問を受けましたので、そのように回答しましたが、今のPMO(プロジェクト
マネジメントオフィス)は、時間とコストの消化についてのモニターだけをしている
という感じなんですね。つまり線表管理だけをしている。

でもクライアントにとって重要なのは、時間とコストを費やしたという結果ではなく、
クライアントにとって必要なソフトウェア(プロダクト)が、どれだけのスコープで
どこまでの品質を確保してデリバリされたかということ。

こう言えばあたりまのお話も、まったくあたりまえのお話になっていない現状が
あります。

したがって、PMOではなく、QMO(クオリティマネジメントオフィス)が必要。
※QMOは私の造語です。

そのための手段としての、テスト駆動型開発!!

これが私の主張です。