Ｎｏ．：0004 投稿日：1999年09月27日(月) 13時38分01秒 投稿者：ｙｏｒｉｃ メール：makoto_matsunaga/ast＠ast.co.jp タイトル：開発業務と保守業務の違い 本文： 今日も多くのＳＥが、稼動を夢見てプログラムを作成している。 納期を迎えたプログラムはやがて、利用され顧客の資産として 貯えられる。 作られたものは、稼動することにより価値が発揮され、 顧客は開発によって発生した費用やストレスを稼動後、 回収・発散させようとする。 システム構築の業務を開発、稼動後の安定利用を提供する業務を 保守と呼ぶ。開発のプロジェクト運営と保守のプロジェクト運営 はさまざまな違いがある。性質として、 開発は １） 納期が決まっており ２） 要件も明確 ３） 手順を追って作業 保守は １） 納期は決まっていない。 作業期間は、自動的に継続される。 ２） 要件も局部的には明確であるが、全体との整合性 合理性は判断困難な場合が多い。 ３） 手順を組んで作業することが困難。 作業は、大概割り込みによって発生する。 プロジェクトの性質上、構成要員に求められる能力も異なってくる。 製品に求められる物は、機能と性能である。 プロジェクトとして考えれば、生産性と品質が重要である、 もちろんコストも重要であるが、これはひとまず置く。 開発プロジェクトは、必要とされる技術に特化した要員を、 工程として必要な時期に確保しておけばよい。 これは、建築を例にとれば理解しやすい。 段取り（適正な工程管理）をすることにより コストを最小におさえることができる。 保守プロジェクトは、 組みあがったシステムに必要とされた技術はすべて必要となる。 いつ、どんなことが起こるかわからない。それに備えて、 いつでも提供できる体制であることを求められる。しかし、 現実的には、それは不可能である。 この事は、保守要員にとって、体制的な不完全性による 恐怖、あるいは一種後ろめたい気分となって、心理的圧迫 を強いることになる。 Ｎｏ．：0005 投稿日：1999年09月28日(火) 09時00分30秒 投稿者：ｙｏｒｉｃ メール：makoto_matsunaga/ast＠ast.co.jp タイトル：保守の抱える問題 本文： １．新技術 「開発」は、常に新しい技術を適用して行くことを使命と している。場合によっては、前人未踏の荒野を進む必要がある。 新しい手法・新しい設計方法･新しいﾌﾟﾛｸﾞﾗﾑ技術を利用して、 顧客の情報戦略に付加価値を提供する。 「保守」は、新しい技術を特に必要とはされない。 それよりも、他の人が作成したﾌﾟﾛｸﾞﾗﾑを解析する能力が要求される。 また、問題判別、影響範囲の特定、顧客に対して、代替案の提示 という能力が必要である。 ２．心理的な問題 「開発」はスケジュールに追われるが、そのスケジュールは 妥当性のある計画によってあらかじめ算出されている。 ただ、新たな試みを実施することで、不安を持つ。 「保守」は、あらゆる種類の攻撃にさらされるが、 「知りません、わかりません」という答えは、許されない。 基本的にスケジュールは、引けない。顧客からの 割り込みを優先するため、自分のペースで仕事ができない。 常に緊急の対応を迫られる。任期切れのあてがない。 個人プレー（担当部分）が主体となり、リスクが分散されにくい。 ３．総合評価 全体的に「開発」は華々しく、注目を浴びるが、「保守」は常に 縁の下の力持ちで陽の目を見ない。また、周囲からの評価も、 新規開発チームに入れない人々が保守にまわされているのだとい う見方をする場合がある。 ＳＥ自身も自分のペースで、工夫をこらして作業をするというより、 なりふり構わぬ顧客の依頼に、振り回され、厳しい期限で作業する という負担を負わされる。 「開発」と「保守」では、どちらがより高い技術を必要とされるか は、意見の別れるところである。一口で技術と言っても、開発と 保守では求められる部分がまったく異なる。 Ｎｏ．：0006 投稿日：1999年09月28日(火) 09時13分21秒 投稿者：ｙｏｒｉｃ メール：makoto_matsunaga/ast＠ast.co.jp タイトル：「開発」と「保守」の本質的な違い 本文： 「開発」と「保守」では同じプログラム、システムを相手にして いるのにさまざまな違いが発生している。これはどこから来るの であろうか。 「保守」を「開発」の延長であると見たり、「開発」を「保守」 の前段であるととらえる見方はある。しかしこれは、一元的な 工程としての見方でしかなく、ビジネスとしてこれを捉えれば、 まったく違う物であることがわかる。 １．製造業とサービス業 情報産業全体はサービス業と位置づけられているが、｢開発｣ 中のシステムは何のサービスも未だしていない。使用されること により初めてサービスとなる。 「開発」プロジェクトは製造業に組すべきである。ただし出来上 がったものが物体としての様相を備えていないだけである。シス テムが稼動し「保守」のプロジェクトになって初めてサービスと なる。 ２．狩猟民族と農耕民族 人類の歴史は、狩猟民族として始まる。獲物を求めて原野を駆 け、海に潜り自分たちの技術や知恵、経験を頼りに自然の中で生 きる道をさぐる。獲物が豊富である時、また優れた技術や道具を 持つとき、彼らは生活に困らない。しかし、獲物が少なくなると、 彼らは獲物が豊富な場所に移動する。自然社会が、彼らの生活に 困らない程度に獲物を供給し続けてくれるならば、平穏な生活が できる。自然社会のバランスが崩れ、生活の安定を得られないよ うに成ると、彼らは二重の勝利を勝ち取らなければならない。 一つは、他の狩猟民族（同業他社）との競争に勝つこと、もう一 つはその獲物をしとめることである。この二つの困難を乗り越え て初めて、一時的な平安をえる。この方法の困難なこと、またよ り安定した生活を求める人々は、農耕というまったく新しい仕組 みを自分たちの生活に取り入れた。それは、移動せず、土地を耕 し収穫する方法である。一攫千金は望めないが、自分たちの努力 がむくわれる生き方である。狩猟民族は、攻撃的で決断力を持つ。 俊敏な肉体と知恵を駆使し、エキサイティングな生き方をする。 農耕民族は、忍耐力と努力、勤勉さを身につけた。彼らは、安定 した生活に価値を見出した。 「開発」と「保守」にまとわりつくさまざまな違いは、狩猟民族 と農耕民族の違いとして捉えると理解が進む。それぞれの生き方 の違いは、世界というものの捉えかたの違いであると言っても過 言ではない。 「世界は我が表象である」と言い放ったショウぺンハウエルの思 想は、未だ健在であるが、その表象としての世界をどのように意 義づけ、定義するかは個人のまた会社の自由裁量に任されている。 この定義が正しく行われたとき、それは現実社会の乖離と矛盾を 乗り越えて繁栄していく。逆に、誤って定義すれば、齟齬やあつ れきを生じて、やがて没落していく。 この事は、企業が持つ「コンセプト」またそれを具現化する組織 形態や機能が結局、その企業を繁栄させるか、没落されるかを決 定する重要なファクタであることを示している。 ３．恋愛と結婚 ｢開発｣､｢保守｣の違いについて顧客を中心とした関係で見るこ ともできる。顧客と「開発チーム」の間には、未だ現実とならな いシステムのイメージがある。顧客は「開発チーム」にシステム の夢を託し、「開発チーム」は顧客に潤沢なる資金を夢見る。 お互いは相手を見つめ合い、相手の魅力に熱中するのである。 これは、幸福な恋愛関係に似ている。相思相愛であれば、稼動ま での多くの障害をものともせず、立派にゴールインすることであ ろう。つまらぬ誤解や嫉妬から言い争いをする場合もある。それ ぞれは、立脚点を異にして決められたゴールまでは、相手を気づ かうやさしさや思いやりを持つ。この時期は、お互いが甘い夢を 追いかける幸福な時期でもある。 システムが稼動は、華々しいセレモニーによってはじまる。ここ では、困難な道のりが回顧され、お互いの努力に感謝の言葉が述 べられる。新しい生活に生じるさまざまな不都合は、しばらくは 「開発チーム」が対応するが、二つの独立した立場は、一挙に接 近する。やがて業務的には不可分の関係にさえ成る。お互いを見 詰め合う暇はない。お互いが、協力して、別の巨大な敵に対応し なけらばならない。この時は、「開発チーム」ではなく「保守チ ーム」となっている。｢開発チーム｣から「保守チーム」への移行 は、多くの場合、開発担当者がそのまま保守チームに繰り入れら れる形で行われる。これがリスクを最小にする方法である。しか しながら、ビジネス形態は異なることを理解しておくべきである。 顧客の側も、開発フェーズでは｢開発チーム｣に対し、契約窓口と なった部署が、顧客の代表として、要件のとりまとめ、機能の確 定を行うが、稼動後は、利用顧客の不用意にふくらんだ夢によっ て発生する小さな火事を消し止める役目をになうことになる。 「開発チーム」や「保守チーム」と強力に組んで、利用顧客を説 得していく必要がある。大海に乗り出してしまった船は、後戻り できない。船はすでに造られ、業務を乗せ､利用者を抱えて現実 の波を感じつつ進んでいる。 これは結婚してしまった関係に似ている。夢や、あこがれはも はや待った無しの現実の問題に置き換わって､押し寄せてくる。 視点は、共通した問題に向けられる。稼動後に発生する問題は、 バグと仕様変更に切り分ける必要があるが、それだけでも多大な 労力が必要となる。 初期稼動から数ヶ月経過することにより、トラブル連絡は減少し ていくのが普通である。安定稼動という見極めにより、顧客側の 体制も、保守チームの体制も適正化される。ここで、顧客側の対 応として、考えてみるならばシステム管理に関する部分は、顧客 本来の業務であるとはいえない。近年、アウトソーシング化とい う流れの中で、顧客はできるだけ保守に関わる部分を外出ししよ うとする傾向を持つ。したがって、顧客は、できるだけ多くを 「保守チーム」業務として囲い込むことを望んでいる。ここで最 も重要になるのは、顧客の視点で｢保守｣を進める事ができるかど うかということである。 顧客が指示した通りに動く｢保守チーム｣ではなく、顧客に代わっ て、動くことのできる「保守チーム」が望まれている。それは、 固有システムを掌握するのと同様、顧客の業務や慣例、企業文化 にまで及ぶ広い範囲の知識とバランス感覚が必要となってくるの であり、顧客業務を支える一員としての自覚が求められることで ある。 Ｎｏ．：0007 投稿日：1999年09月28日(火) 09時20分41秒 投稿者：ｙｏｒｉｃ メール：makoto_matsunaga/ast＠ast.co.jp タイトル：保守の落とし穴 本文： 「保守」には、不可解なことや矛盾がついてまわる。これは逆説 でしか説明ができない様なことである。経験的によって貯えられ たこれらの現象をまとめておけば、今後有効利用できるかも知れ ない。 ・ トラブルはしばしばシステム担当者が不在の場合に発生する。 ・ トラブルは単発ではなく、他の多くのトラブルと重なって一緒 にやってくる。 ・ 顧客は常に急いでいる。 ・ 「とにかく、できるようにしてくれ」と言われて、やむをえず やったことが、後になって「どうしてそんなことをしたのか！？」 と怒られる。 ・ 改善をすればするほど、システムはもろくなり、トラブルは多 くなる。 ・ 問題は、隠そうとすればするほど、大きくなって現れる。 ・ 結局、何を言おうと、どう言おうと、顧客の方が正しい。 ・ 顧客は常に被害者である。保守チームが加害者でないにも関わ らず。 ・ 急いで、やっつけようとすればするほど、正しい解決から遠ざ かる。 ・ どんなに素早く対応しても、顧客はそれを当然と感ずる。 ・ システムは使って見なければわからない。しかし、使ってみて わかるのは、「どんなに使いにくいか」という事だけである。 ・ 顧客にとっては、トラブルが無いことがよいことであるが、 保守チームにとては、必ずしもそうではない。 ・ 利用されないシステムだけが、決してトラブルを起こさない。 ・ 改善･修復作業は、やればやるほどやるべきことが増えてくる。 ・ 設計書には、ある機能が他に与える影響については、決してど こにも何も記述していない。 ・ おおよそ、納品されたシステムと設計書は、ちぐはぐである。 ・ 改善を繰り返していくと、何が正しいかわからなくなってくる。 ・ すべて、結果には理由がある。今ある物は、確かに意にそぐわ ないかも知れないが、それにはそれなりの理由がちゃんとある。 ・ トラブルは、悪人が悪意を持って引き起こすものより、善人が 悪意を持たずに引き起こすものの方がはるかに多い。 ・ 顧客はしばしば、自分の業務の内容を保守チームに問い合わせ てくる。 ・ 何かを習得する最良の方法は、それを教育する側にまわること である。 ・ 急いでいる仕事は、忙しい人にやらせよ。きっと、すぐに片づ けてくれる。暇な人にやらせようとすると、いつまでたっても 出来上がらない。彼が暇であるのは、それなりに理由のあるこ となのだ。 ・ 困難な仕事は、今すぐやっつけてしまえ。不可能なものは、も う少し時間をかけてもよい。 ・ スペシャリストが生きていくためには、特殊な技術が必要であ るが、スペシャリストではない多くの民衆は、自分を守る知恵 だけがなくてはならないものである。 ・ 良いと思ったことは、思い切ってやってみよう。結果が悪くと も、きっとやらずにおくよりは良かったに違いない。人が失敗 して後悔するのは、良いと思わないのにやってしまったためで ある。 ・ 相手をだまそうとするのは、嘘をつくことになる。しかし、自 分が信じてしまった嘘は相手をだますことにならない。そのた めに相手が損害を受けたとしても、自分は加害者である前に被 害者のはずなのだ。 ・ 誰か人の話を信用しやすく、だまされやすいコンピュータシス テムを作ってくれないだろうか？それが実現したら、われわれ は（一瞬の間）どんなにか幸福になれるだろう。 ・ コンピュータほど、説教を聞かせて効果のあがらないものはない。 ・ 同じようなトラブルを何度も何度も引き起こすシステムに、人 はうんざりするが、システムは少しもうんざりもへこたれもめ げたりもしない。 ・ 自分は悪くないと思い込んでいる人間を直すのは、不可能である。 ・ 病気じゃない、と思っている病人ほど治しにくいものはない。 ・ システムの問題というのは、つまるところ人間の問題である。 ・ どうしてこんなにトラブルが多いのかとシステムにくってかかる 保守要員もいる。腕まくりしてシステムに取り組むが、結局納得 せざるを得ない。彼がシステムのことを理解すればするほど、 トラブルが起きないことが不思議に思えてくる。 ・ こちらに食ってかかる顧客がいたら、反発してはいけない。ス ピード違反で捕まったときのことを考えよう。どんなに警官に 反論しても、墓穴をほるだけのことだ。強敵であれば、思い切 って相手の懐に飛び込んでいくのも手である。同苦し、一緒に 憤り不満や怒りをぶちまけよう。真の敵がこちらではないこと を身を持って示そう。システムは、われわれが身を隠すような 秘密をいくらでも持っている。いざとなれば、ハードウエアの せいにしてしまうことだってできる。 ・ ユーザーとは、システムを自分の業務に支障がでないように利 用している人のことである。 ・ 事態は常に悪化する。今動いているシステムもいずれは、確実 に動かなくなる。 ・ 問題は、必ず発生する。今来ないなら、後で来る。後で来ないなら今来る。 ・ 技術は日々に進歩する。しかし人間の本質はそれほど進歩しない。１０年後の技術は予想できないが、１０年後にその技術を使用している人間は予想できる。つまり、今の人々と同様である。 Ｎｏ．：0008 投稿日：1999年09月28日(火) 09時41分33秒 投稿者：ｙｏｒｉｃ メール：makoto_matsunaga/ast＠ast.co.jp タイトル：保守チームの心構え 本文： 保守チームには「呪い」がかけられている。これを理解して おかないと後で大きな痛手を受けることになる。 ・「やります」の悲劇 顧客は、好き勝手な理由で保守チームに圧力をかける事がある 「いったい、どうなっているんだ。どうしてくれるんだ」と、こ の時「はい、やります」と言ってはならない。顧客が疑問を投げ かけて、保守チームが「やります」と答えたら顧客はただ（無料） で作業を請け負ったとみなす。行為に対する請求は、拒否される 事もある。どんな場面であろうとも、保守ﾁｰﾑは、顧客の依頼を 受ける事が必要である。「どうするつもりだ。どうしてくれるん だ？」と詰め寄られてても、ふんばって次のように応えよう「本 当に困りました。どうしましょう？どうしたらいいでしょうか？」 ・「知っていながら､知らないそぶり」 トラブルは大概､思ってもいないところから、思ってもいない 現象として発生する。顧客はトラブルの犠牲者である。保守チー ムも同じ犠牲者でなければならない。トラブルが予想されたもの であったとしても、保守チームは意外であったという反応を示す 必要がある。信頼を失ったら、すべてを失う。そのために場合に よっては、うそをつく必要もある。 ・「危険思想」 システムはトラブルを発生させないと思い込んでいるユーザー がいたら、これほど危険な思想はない。システムは、トラブルが つきものであり、避けて通れないのである。この事をよくよく徹 底し、理解を浸透させておく必要がある。できれば、保守ﾁｰﾑの 責任のないトラブルに対して、広くアピールすべきである。 「ほらね、こういうこともあるんですよ」 ・「コスト管理」 本来は、かけた労力に対してではなく、確保した労力に対して 対価を求めるべきであるが、顧客はなかなか納得しない。これに たいする合理的な手法を確保しておきたいが、世論として確立す るまでいたっていない。保守チームは人間の切り売りをしなけれ ばならない。顧客は「人間の１／４だけ下さい。とか１／１０だ け売ってくれ」ということを平気で言ってくる。 ・「ユーザーのわがまま」 今更言うまでもないことであるが、ユーザーは、不合理で無理 な事を平気で依頼してくる。何より恐ろしいのは、自分が、無理 な依頼をしているという自覚がない事である。ユーザーはしばし ば、自分の業務をシステム担当者にたずねる。この時、保守チー ムのストレスは極限に達する。 ・「けんかにならない」 保守チームは、決して顧客とけんかをしてはいけない。しよう としてもできないし、それをしようとして事態が好転することは 決してない。１００％相手のミスによって発生したトラブルを攻 撃すれば、２０％のこちらのミスで発生させたトラブルにより壊 滅する恐れがある。 ・「手抜き工事の法則」 完成度の低いシステム程、保守費用は増大する。これは、当た り前のことであるが、顧客にとっての呪いとみなすこともできる。 ・「不可解なものは機能にしてしまえ」 時にプログラムは、不可解な動きをすることがある。どのよう にとらえてよいか判断に苦しむ。仕様が明確で、明らかにプログ ラムに問題がある場合は、バグとして対応するが、それ以外はう やむやに成りやすい。この時は、勇気を持って次のように言って のけよう「これは、機能です。このようにつくりこんであるので す。」システムには、意識して作り込んだ機能の他に、知らぬま に作り込まれてしまっている機能が、ふんだんにある。「バグ」 を退治するのは無償であるが、「機能」を変更するのは、改善と して有償で行う。 ・「みんなの問題にしてしまえ」 時には保守チーム固有の問題で進退きわまる場合もある。顧客 に言い訳をしようにも言い訳できる要素がまったく見つからない ような状況である。この時は、言い逃れすべきではない。事実を 事実として踏まえた上で、顧客の方にも何かの考慮が必要であっ たということを気づかせるよう気を配ろう。これは、非常に困難 なことである。もし、それが不可能であれば、保守チーム固有の 問題を、顧客を巻き込んだ共通の問題にしてしまおう。頑固にが んばって、そこに生きる道を見出そう。 ・ 「文句を言うのは良い便り」 ユーザーの中には、あれこれ注文して、文句を言ってくる人々 がいる。保守チームがうるさがって、いいかげんに対応すると、 エキサイトして口汚くののしってくる。これは、われわれの対応 が誤っているのである。使いにくいシステムを「こういうものだ」 と割り切って、物分かり良く不便をこらえて使うユーザーもいる が、彼らに払うべき注意は存在しない。苦情を叩き付けてくるユ ーザーこそ、最大、最強の顧客である。われわれは、丁重に彼ら を扱わなければならない。彼らこそ、われわれの見方であり、敵 の中深く進入し、われわれのために道なき道を切り開いてくれて いる最高の協力者である。時に同苦し、時に励まし、賞賛を惜し みなく降り注ぐべきである。そこから、新たなビジネスが必ず開 けてくる。恐れず、立ち向かっていくべきだ。 Ｎｏ．：0011 投稿日：1999年10月29日(金) 18時00分25秒 投稿者：馬場　辰男 メール：baba＠ccs.co.jp タイトル：「文化としてのソフトウエア開発」のご紹介 本文： 当社に勤めていた中堅エンジニアのS氏が社内の勉強会の報告書としてまとめ たペーパーに「文化としてのソフトウエア開発」というものがありました。 　S氏は、この勉強会において美術、工芸、建築等の分野における「ものを作る」 過程とそれを取り巻く環境をヒントに、ソフトウエア開発のパラダイムや方法論 を反省し、「作る」心と「学ぶ」姿を回復するための手がかりを得ようとしたの でした。 　筆者(S氏)の言を借りれば、地質屋の本性である「1を知って十を語る壮語癖」 を遺憾なく発揮して書き上げられたこの報告書は、楽しみながら(あるいは批判 の目におびえながら)あっという間に読み終えることができる出来映えであり、 その後九州へ移り住むため当社を退職したS氏の遺稿となって当社社員に愛読 されています。 　報告書は、1.はじめに　2.様式と文化、3.不幸の構図、4.機械的パラダイムの 破綻、5.新しいパラダイムの模索、6.位相、7.おわりに　という構成です。 　 　これからこの報告書の骨子をご紹介します。 　この掲示板をご覧になった方々のご意見をいただければ幸いです。　(づづく) Ｎｏ．：0012　（0011） 投稿日：1999年10月29日(金) 18時08分03秒 投稿者：馬場　辰男 メール：baba＠ccs.co.jp タイトル：4.　機械的パラダイムの破綻　前半 本文： 4章の機械的パラダイムの破綻の骨子をみなさんにご紹介します。　 4.　機械的パラダイムの破綻 4.1　大量生産原理 　　1908年に売り出されたフォードT型車は、自動車を大衆のものとし、自動車 　産業の黄金時代の幕を開いた。ソフトウエア開発に関する議論の際にしばしば 　引き合いに出される自動車の製造のパラダイムについて見直すことは、ソフト 　ウエアについて考えるうえで無駄ではないだろう。 　　ヘンリー・フォード自身、Encyclopedia Britannica 22版の「大量生産」の項目 　を執筆し、大量生産の基礎についてこう述べている。 　(a) 作られる商品が計画どおりに順序よく連続的に工場内を進行していくこと。 　(b)仕事の仕方を、労働者のイニシアティブに委ねて自分で見つけさせるのでは 　　なく、こちらから与えること。 　(c)作業を分析してその構成要素に分けること。 　　これら3つの原理を見直し、ソフトウエアにとってどういう意味があるかを 　考えてみたい。 4.2　仕様化可能性の幻想 　　フォードT型車の専用工場として1914年頃に完成したハイランド・パーク工場 　では、日産1200台の生産能力を示す大量生産が行われた。 　　この工場で具現化されたような大量生産原理(a) には、前提として「仕様化」 　というものが要求される。対象物(T型フォード車)が予め仕様化可能であり、 　従ってその製造工程(原材料、部品、加工機械、ツーリング、を含む)も予め 　仕様化可能な場合にのみ、生産ラインを整備し秩序正しく製造を続けることが 　できるのである。 　　バベッジの考案した解析機関は、演算列と変数値を与えると順次実行する汎用 　的計算機械であった。彼の動機は当時の間違えだらけの数表にあったらしく、 　計算法のわかっている膨大な「機械的」計算は人間が行うべきではない、という 　発想がそこにはあった。彼はJacquard機械からアイデアを得たといわれており、 　その意味ではコンピュータの興りは、1760年代から始まった英国産業革命の精神 　を体現したものであると言える。19世紀に入って欧州は帝国主義の旋風が吹き荒れ 　激動の時代となるが、それを尻目に米国は1830年代からの産業革命期を迎え、世紀 　末にはもうフロンティアが消滅する程の大発展を遂げる。1896年のTabulatin Machine 　社(後のIBM社)の設立は、このような時代背景のもとで行われた。 　　この時代のソフトウエアの中心課題は、計算機による大量データの反復演算処理 　であった。 　　ロッキード社のロイスが提案したウオーターフォールモデルはハードウエア製造 　プロセスのアナロジーであり、当時のソフトウエア様式の主流には適合するもので 　あったかもしれない。しかし今日のソフトウエアが対象とする問題領域は、かつて 　のようなソフトウエア様式では何の助けにもならないところまで広がった。いきお 　いウオーターフォールモデルは、無明な発注者や管理者のためのモデルとなりはて、 　この開発の現場から全く乖離してしまった管理方式は、ソフトウエア技術者の創造 　性を疲弊させるばかりである。 　　ソフトウエアの大規模化・複雑化に加えて、予め仕様化不可能な領域へのソフト 　ウエアの適用が進んできた今日、ウオーターフォールモデルに代表されるような線 　形完結的な製造工程のパラダイムは、ソフトウエアプロセスのモデルとしてはまっ 　たく不適当なものなのである。　(つづく) Ｎｏ．：0013　（0011） 投稿日：1999年10月29日(金) 18時59分30秒 投稿者：馬場　辰男 メール：baba＠ccs.co.jp タイトル：機械的パラダイムの破綻　後半 本文： 4.3　個人と技能の軽視 　　大量生産原理(b)の背景として、当時のアメリカでの工場生産を低教育・非 　技能的労働者が担っていたという事実は無視できまい。現にその後、教育や 　技能といった点で良質な工場労働者のいた日本では、労働者の主体的な運動 　であるQC活動が大きな成果を収めている。 　　振り返ってソフトウエア業界をみてみれば、業界を席巻しているのは、優 　れた技能者が発想し、優れた技能者たちのグループが育ててきたものばかり 　ではないか。表計算ソフト然り、ワープロソフト然り、UNIX/C然り、分散 　処理然り。 　　技術は人に付く。機械は機械であり、人に技能無くして組織に技術革新は 　ない。 4.4　還元主義の呪縛 　　大量生産原理(c) には「どんな複雑な現象も、構成要素に還元すればすべて 　の側面が理解できる」というデカルト的還元論の妄信がある。 　　現在、ソフトウエアの開発工程もまたこのような観点で管理されているし、 　ソフトウエアそのものも、機能を階層的に分割し、分割されたパーツごとに 　プログラムとして実現し、これらのパーツを寄せ集めることによって、所望 　の機能が実現される、と長い間信じられてきた。 　　還元主義は、「方法序説」からの300年間、西欧合理主義と、従って西欧 　近代科学の本流を形作ってきたが、ここ20年ほど、自然科学における還元論 　に対する見直しが定着してきている。またこれを受けたかのように、西欧合 　理主義が産業革命を契機として生み出した「モノの生産」重視の社会風土に 　対して、市民社会からの批判も活発である。 　　ソフトウエアは保守・改造を繰り返すうちに、構造的に劣化する。ソフト 　ウエアも放っておけばエントロピーが増大し続いて熱的死を迎える。ソフト 　ウエア開発を、ただ作るだけでなく保守まで視野に収めた動的な観点から見 　れば、分割と統合のパラダイムの破綻は明らかである。 4.5　弾み車の穴 　　例えばソフトウエアの生産性とは何だろうか。たくさんのコードを短い時 　間で書けば生産性は高いのだろうか。　 　　単位時間あたりのコード作成量は確かにソフトウエア生産性の一つの指標 　ではある。しかしそれはまた一つの指標でしかなく、生産性そのものではな 　いのだ。どんな立派な情報処理システムも、それが利用者に何らかの価値を 　提供しなかればただのゴミである。ソフトウエアの生産性は効率よりも、 　単位資源(人、時間)で提供される効果で計られるべきであろう。効果なくして 　効率はあり得ない。 　　ソフトウエア工学の提唱からこのかた、生産性や品質について様々な提言 　がなされてきたが、多くの場合それは、静的で機械論的な製造のパラダイム 　に基づいている。これまで見てきたとおりそのようなソフトウエア製造のモ 　デルは、今日のソフトウエア開発にとっては不適当である。ソフトウエアの 　諸問題に関する議論や戦術が悉く空回りしているのは、そもそも問題設定そ 　のものを間違っていることに起因するのではないだろうか。 　　ある工場で生産している弾み車には、小さな穴を開けることになっていた 　という。技師たちはこの穴をどうすれば簡単に安価に開けることができるか 　を検討した。検討も最終段階になってある技師が、なぜそこに穴を開けるの 　かという疑問を呈した。それは「ずっとそうなっていた」のだが、調べてみ 　ると次のことが分かった。かつて製品品質が悪く弾み車の重量バランスが偏 　っていた頃、設計者が片側に穴を穿ってそれを補正していたのだ。品質の改 　善された今日では、穴をなくすということが良い弾み車を安く作るための最 　良の解法なのであった。 　　プログラム開発のプロセスにおいて正しい問題設定、議論領域の十分な把 　握、解法の熟考が大切なように、そのメタプロセスにおいても立ち止まって 　考えることが必要な時期がある。 Ｎｏ．：0014 投稿日：1999年11月18日(木) 17時33分48秒 投稿者：松永 真 メール：makoto_matsunaga/ast＠ast.co.jp タイトル：「ＳＭＳＧの考える保守とは」グループ議事録 本文： このグループは、ＳＭＳＧの研究成果をもとに、ソフトウエア保守の 重要性を一般に知って頂く材料やＳＭＳＧに参加され、研究活動する 方の基礎知識として利用できる「用語集」や「ＦＡＱ」の作成を中心 に活動を進めてまいりました。昨年は、一般の意見を投稿できるディ スカッション・フォーラムを立ち上げ、コンテンツの充実を目標に活 動しております。 ここには、毎月１回行われる作業部会の内容が掲載されています。 Ｎｏ．：0015　　（0014） 投稿日：1999年11月18日(木) 17時38分28秒 投稿者：松永 真 メール：makoto_matsunaga/ast＠ast.co.jp タイトル：議事録「99.07.14」 本文： 日時　1999.7.14（水） 14:15 − 16:00 出席者　岸田さん、長谷川さん、馬場さん、増井さん、松永（記） 欠席者　なし 議題 １．検討テーマ ･残件整理 ・本年度の研究テーマについて ・次回以降のスケジュール ２．残件整理 ･ホームページからのリンクを予定していて実現していない ものがある。 これについて、どのようにしていくか。 (1)フリーディスカッション 各グループの進捗発表の場（議事録掲載）として利用 して行く。 「ＳＭＳＧが考える保守とは」のグループの討論結果を 掲載する。 説明文書を見直しし、会員にアナウンスする。 文面は馬場さんが作成、当グループ員にＭＡＩＬし、添削後 ホームページににリンクする。 (2)Ｙ２Ｋコーナー 今のまま（掲載記事なし）でリンクさせる。 事件・意見があれば、自由に投稿していただく。 ３．本年度の研究テーマについて ・検索エンジンへの登録申請 次回の作業部会で増井さんが登録の為の資料持参。 KEYWORDを抽出し、登録手続きを進める。 ・ディスカッションの有効利用 (1) ＳＭＳＧ各グループの情報交換の場を提供 進捗状況、問題点、他のグループ員に対する協力依頼等 積極的に利用していただく。また随時コメントを入れられる形で 運用していく。報告のないグループに対しては松永が ”催促”のＭＡＩＬを出していく。 (2)「ＳＭＳＧが考える保守とは」のグループの討論結果を掲載 作業部会でテーマを提供担当者を決め、討論していく。 討論結果を掲載。結論に至らなくともそのまま掲載していく。 テーマについては、特に制約を設けない。部員各自の問題意識・ 話題に任せる。 ４．次回作業部会 ・検索エンジン登録検討 ・テーマ提供（松永）ディスカッション ・次回作業部会 日時 99/8/23（月） 15:00〜18:00 場所 エイ・エス・ティ（東池袋） Ｎｏ．：0016　　（0014） 投稿日：1999年11月18日(木) 17時48分58秒 投稿者：松永 真 メール：makoto_matsunaga/ast＠ast.co.jp タイトル：議事録｢99.08.23｣ 本文： 日時　1999.8.23（月） 15:00 − 17:30 出席者　岸田さん、長谷川さん、増井さん、松永（記） 欠席者　馬場さん 議題１．検討テーマ ・ディスカッションフォーラムについて ・検索エンジン登録検討 ・テーマ提供 ・次回以降のスケジュール ２．ディスカッションフォーラムについて ･馬場さんの説明文書ば異議無し。 ･ホームページからのリンクを8月25日に予定。（増井さん） ･各グループの進捗発表の場（議事録掲載）として利用して 行く。 まず「ＳＭＳＧが考える保守とは」のグループの議事録を掲載 全員にＭＡＩＬを出す（松永） ３．検索エンジンへの登録検討 ・ＩＮＴＥＲＮＥＴ掲載資料をもとに登録内容を検討 ADDRESS：http://www.submit.ne.jp/regist/index.asp ●お申込者本人 名前：ＳＭＳＧ メール：smsg-secretariart ●サーバー管理・運営者 指定しない 名前： メール： ●会社名 （省略した場合は申し込み者の名前になります。） ＳＭＳＧ ●登録代行業者 （登録代行業者以外の方は空白で かまいません。） 名前： メール： ●ご住所またはサーバの所在地 〒：170-8454 　 都道府県：東京都 市区郡：豊島区 （ＵＮＥＴの所在を記入？） ●電話・FAX番号 電話：03-5395-2981 FAX：03-5395-2981 ●ホームページのタイトルとふりがな タイトル：ソフトウェアメンテナンス研究会 ふりがな：そふとうぇあめんてなんすけんきゅうかい ●ホームページのURL 日本語ページURL：http://www.smsg.or.jp/ 英語ページURL：http://www.smsg.or.jp/index_e.htm ●キーワード 保守、ソフトウェア、研究会、 プロセス、開発、ドキュメント、リポジトリ （検討要） ●ホームページの紹介文 紹介文1（40字程度） (CSJなどに使われます) −＞ソフトウェアのメインテナンスを 専門に研究する非営利任意団体(NPO)です。 紹介文2（60字程度） (一般的なサーチエンジン用です) −＞ソフトウェア・メインテナンス研究会（ＳＭＳＧ）は ソフトウェアのメインテナンスを 専門に研究する非営利任意団体(NPO)です。 紹介文3（100字以上） (InfoNavigatorなどに使います) −＞松永 ●ページの内容は子供が見ても大丈夫？ 特に制限なし ４．検討議題提出 松永より「サービスとしてのシステム保守のありかた についての考察」を提示。 「開発」と「保守」では、同じコンピュータシステムを扱うが ビジネス形態はまったく異なる。 この本質的な違い、また保守の矛盾や落とし穴について、 まとめてみました。収集つかないまま、時間切れ終了。 ５．次回作業部会 ・テーマ提供（増井さん：構成管理）ディスカッション ・次回作業部会 日時 99/9/22（水） シンポジウム終了後 場所 労働スクエア東京 Ｎｏ．：0017　　（0014） 投稿日：1999年11月18日(木) 17時56分24秒 投稿者：松永 真 メール：makoto_matsunaga/ast＠ast.co.jp タイトル：議事録「99.09.22」 本文： 日時　1999.9.22（水） 18:00 − 20:30 出席者　岸田さん、長谷川さん、増井さん、馬場さん、松永（記） 欠席者　なし議題 １．検討テーマ ・ディスカッションフォーラムについて ・検索エンジン登録検討 ・テーマ提供 ・次回以降のスケジュール ２．ディスカッションフォーラムについて ･８月に実施したとき配布した資料を、登録します。（松永） ･８月、９月に実施した作業部会議事録を登録しました。（松永） ･シンポジウムでも案内したが、今後各グループの進捗発表 の場（議事録掲載）として利用して行く。 全員にＭＡＩＬを出す（松永） ３．検索エンジンへの登録検討 ・ＩＮＴＥＲＮＥＴ掲載資料をもとに登録内容を検討 ADDRESS：http://www.submit.ne.jp/regist/index.asp ･松永宿題分 紹介文3（100字以上） (InfoNavigatorなどに使います) ホームページの研究会案内の「１．ソフトウェア・メイン テナンンス研究会とは」に掲載されている紹介文をその まま利用。 ソフトウェア・メインテナンス研究会(SMSG)は、 1990年12月に設立された日本で初めてのソフト ウェア・メインテナンス問題の研究を行う非営 利の任意団体です．過去8年間、法人会員形式 （個人会員形式の参加も可）で、いくつかの作 業部会での研究や成果の相互交流を中心に活動 を行ってきました．作業部会では、ソフトウェ ア保守の現場の第一線で活躍されている方々の 活発な議論や検討が行われており、その研究成 果は毎年報告書として整理され、一般に公開さ れています．また、7年前からは年１回のソフ トウェア・メインテナンスに関するシンポジウ ムを開催しています．ICSM(International Conference on Software Maintenance)等の国際 会議への参加を通して、日本における技術やビジ ネスの状況について発表してきました． 　こうした当研究会の活動は、保守に関する研究 や論文があまり数多くは見られないという現在の 学界・産業界の現状からすれば、きわめて貴重な ものだ自負しております．メインテナンスという テーマ自体、その対象範囲があまりに多岐に渡っ ているために、個々の研究課題の絞り込みにかな りの時間を要し、1年間というタイムリミットの中 では、議論が充分に深められないきらいもありま すが、年度をまたがって研究することで、より高 い成果をあげるようにしてます。 　日頃ソフトウェア・メインテナンスに関して切実 な問題意識を持ち、解決を心がけておられる方々に 多数ご参加いただき、メインテナンス技術や作業の 重要性に関する認識の向上に貢献できれば幸いです． ４．検討議題提出 増井さんより本日発表の「構成管理」を議題として提出。 シンポジウムの中で、他のパネラーとともに討論されました。 ディスカッションフォーラムに投稿願う（増井さん）。 ５．次回作業部会 ・テーマ提供（馬場さん）ディスカッション ・合宿についての詳細検討 ・次回作業部会 日時 99/10/21（木） 14:00〜 場所 CCS新橋オフィス8階会議室 Ｎｏ．：0018　　（0014） 投稿日：1999年11月18日(木) 18時00分29秒 投稿者：松永 真 メール：makoto_matsunaga/ast＠ast.co.jp タイトル：議事録「99.10.21」 本文： 日時　1999.10.21（木） 14:00 − 16:30 出席者　岸田さん、馬場さん、松永（記） 欠席者　長谷川さん、増井さん 議題 １．検討テーマ ・ディスカッションフォーラムについて ・検索エンジン登録検討 ・合宿にむけて ・次回以降のスケジュール ２．ディスカッションフォーラムについて ･馬場さんから「文化としてのソフトウエア開発」のテーマが 出された。 ･論文は1995年に馬場さんの部下、Ｓさんが書かれたもの。 ･馬場さんより補足説明を受けつつ理解。 ･6章までを３人で分担し、ディスカッションに登録する。（宿題） 1章から3章：松永、4章：馬場さん、5章から6章：岸田さん 本日欠席の長谷川さん、増井さんにはコメントを入れて頂く。 ３．検索エンジンへの登録検討 ･ＩＮＴＥＲＮＥＴ登録内容をもとに登録（松永） ･全員に案内を出す（松永） ４．合宿に向けて ･Ｙ２Ｋフォーラムに登録データ収集。 初日にＹ２Ｋについてのアンケートを提示する。 発生の有無、対策は（自社、顧客）、 年末年始の体制（出勤、待機、なし） 何が起こるか予想を立てて頂く。深刻度予想。 ･年明けに結果をもとに予想の評価、実際何が起こったか 現象データの収集・登録を行う。 ･今年のグループの主要活動は、デスカッションフォーラムの充実。５．次回作業部会 ・合宿で行う ・次回作業部会 日時 99/11/12（金） 9:00〜 場所 小浜市公民館 Ｎｏ．：0019　　（0011） 投稿日：1999年11月22日(月) 17時05分53秒 投稿者：松永 真 メール：makoto_matsunaga/ast＠ast.co.jp タイトル：はじめに 本文： 第３回部内勉強会がはじまったのはもう２年半も前のことになる。 筆者らのグループでは、ソフトウェア開発という作業を大きく見た 場合に、そこにたゆまぬ練習や練習の評価という過程が欠如している こと、また、ソフトウェア技術者から製造や保守に対する責任と誇り が喪失される傾向の見受けられること、といった日頃の問題意識に 基づき、「美術に学ぶソフトウェア技術養成法」というテーマで勉強 会に取り組んだ。 所期の目的は、美術、工芸、建築等のコンピューター・ソフトウェ ア以外の分野における、「ものを作る」過程とそれを取り巻く環境を ヒントに、ソフトウェア開発のこれまでのパラダイムや方法論を反省 し、「作る」心と「学ぶ」姿を回復するための手掛かりを得るという ことであった。 しかしそこには、勉強会を進めようとすればするほど大きく立ちはだ かる３つの疑問があった。 ・ソフトウェアとは何か ・ソフトウェア開発とはどういうことか ・ソフトウェア技術者とは何者か 結局のところ筆者らの勉強会は、のたうつこれらの疑問を「文化」 という俎板の上に乗せ、鈍包丁で入れた雑駁な切口から中を覗き見 る作業であったとも言える。一年前の発表会では、そこで得られた 知見を無理矢理まとめて「文化としてのソフトウェア開発」と題し て発表した。 Ｎｏ．：0020　　（0011） 投稿日：1999年11月30日(火) 09時45分49秒 投稿者：松永 真 メール：makoto_matsunaga/ast＠ast.co.jp タイトル：２.様式と文化 本文： バルセロナのシンボルとも言える教会建築、サグラダ・ファミリア は、1883年、異才アントニオ・ガウディ(1852-1929)が設計者として 任命されて以来断続的に造営が続けられ、100年以上を経た今日もい まだに未完成である。形体的にはネオ・ゴシックという分類がされる らしいが、その幾何学的造型と象徴主義的装飾の渾然たる融合は、ど のような既存の様式とも異なった生命的存在感を放っている。 建築様式の判別・同定も、その建築の依って立つ歴史的文化的背景と、多かれ少なかれそれを反映した形態とが基準とされよう。たとえ ば、リブ・ボールトやファサードの尖塔アーチを見てゴシック様式だ と思い、それが、農村を基盤とした安定的な封建制の表れであるロマ ネスク様式に対して興った、都市生活者の現実的な関心の信仰的具象 化であることが連想されるのである。 ある様式が「様式」として認識可能であるということは、そこに 「ドミナントデサイン」というものがあり、そのドミナントデザイン が時間的空間的に一定の広がりを持っているということである。そし て共通のドミナンドデザインに基づく建築の間では、建築材の規格化 や工法の標準化によって基盤技術の共有や転用が可能となる。 ソフトウェア開発でも同様のことが言える。たとえば何らかの適用 システムに改造を施し、別のサイトでの利用に供するという形のソフ トウェアの再利用は、既存システムからその高次モデルを抽出し、そ れをスーパクラスとして新たなサイトに適合するサブクラスを定義し 直すという行為である。再利用が有効であるためには、適応業務やプ ラットフォームが共通であり、それを反映するあるドミナンドデザイ ンに基づいて作られていることが前提となる。 逆に言えば建築もソフトウェアも、その適用領域と様式とを限定し てはじめてある程度までの基盤技術の標準化・共有化が可能であると いうことであろう。これまでの、適用領域や様式に対する戦略をなお ざりにしたままのソフトウェアの部品化や工程の標準化の努力が、具 体的な成果のない模索に終わっているのは当然と言えば当然なのであ る。 ムーアという高名な建築家があった。彼はある町の人たちに請われ て教会を建てた。人々の要望を聞き入れながら設計を進めて完成した 教会は、木造で大変素晴らしいディテールと空間を持ち、教会の構成 員皆、これは自分たちが作った教会であると誇らしげに語るものとな った。しかし建築関係者の目から見れば、それは明らかにムーアのデ ザインであったという。 ソフトウェアにも同じようなことがある。社会情勢や技術動向や適 応領域を環境とする中で、業界や技術者が何らかのアイデンティティ を獲得する時、彼らの方法論や技法やデザインには、そういったもの を反映したアキタイプが形成される。ソフトウェアを語る時、そういった様式と文化的背景とを念頭におかなければならないように思われる。いずれにせよソフトウェアの使われた方、作られ方、学び方は、適用 領域や様式によって当然異なるには違いなかろう。 Ｎｏ．：0021　　（0011） 投稿日：1999年11月30日(火) 10時06分59秒 投稿者：松永 真 メール：makoto_matsunaga/ast＠ast.co.jp タイトル：３．不幸の構図 本文： ソフトウェア開発が技術者の労働単価と所要人工数で受発注されて いる限り、契約形態がどうであろうと指揮・監督をだれがやろうと、 「月いくらの人を何ヶ月間お宅のために働かせますからいくらいくら 下さい」というのであるから、それは本質的に人材派遣業である。 ソフトウェア開発業は、作業場所と若干の設備とを容易してお抱えの 要員をそこで客のために奉仕させる「置き屋」と言ってもよい。客が 満足しようがしまいが一定の料金を取る。現在のソフトウェア開発業 の姿がこれである。 ソフトウェア開発のための方法論なり要素技術なりが応用分野や様 式によって異なるのならば、ソフトウェアの価格が依然として単純な 人工ベースでしかないのはあまりに芸がなかろう。 我々に支払われる給与は、 本給＋付加給＋職能給＋α であり、組織内に於ける役割やさまざまなスキルの反映されたものに （式の形だけは）なっている。 ならばソフトウェア開発の価格も、せめて、 人月ベースの基本料金 × 作業種別係数 × 要素技術係数 × 業務種別係数 × α ぐらいになっていてよさそうだがそうではない。何故か。 一つには、各係数を決定するためのクライテリアが欠如しているた めである。ある対象領域に適用されるある様式のソフトウェアを開発 するにあたって、そのソフトウェアプロセスにどういう作業種別があ りどういう要素技術が使えるかが整理されておらず、また、それらの 習得に要する労力や開発における功罪や製品に寄与する度合いなどが、 定量的にどころか定性的にも押さえられていない。 いま一つは、契約の段階でどのような対象領域に適用されるどのよ うな様式のソフトウェアを開発するのかが充分に把握されていないか らである。そうして作られるものは、発注者にとっても開発担当者に とっても少なからぬ不満が残るものであり、結果として契約にそう違 わずプロジェクトが完了したとしてもそれは偶然であり、僥倖と言っ てよい。 このような中にあって心あるソフトウェア技術者は、日々技術を研 さんし作業環境を整える。がしかし契約が人月ベースで行われる限り、 努力の甲斐あって今まで６ヶ月掛かっていた作業を３ヶ月でできるよ うになった途端、６人月の仕事だったものが３人月の仕事になってし まう。同じ成果を半分の期間で達成するするのに、報酬が半分に減っ てしまうのである。以前と同じ売上をたてるためには、以前の倍の仕 事量をこなさなければならない。 自らの努力が評価されないばかりか、却って作成しなければならな いソフトが倍増し、従って保守しなければならないソフトが倍増し、 心あるソフトウェア技術者はますます寡黙にシシュフォスの苦行を繰 り返す。ソフトウェア企業も雇用者を増やして業容拡大をはかるが、 従業員数の伸びほど売上が伸びないばかりか、利益は必然的に漸減す る。生産されるソフトウェアはますます品質が落ち、保守のために思 わぬコストが発生する。ソフトウェアからバグを締め出しコストを引 き下げるための究極奥義は、ソフトウェアを作らぬことだが、これで はソフトウェア業が生業として成り立たないので、免許皆伝の者にの み許される秘奥義としておくほかない。 かくしてソフトウェア業は、構造的に不幸な「構造不幸業種」とな ってしまった。ことの起こりは、この業界が未成熟のまま、ソフトウ ェアとは何か、ソフトウェア開発とはどういうことかといったことに ついての、文化的な洞察や様式的戦略なしに、根拠のない好況の波に 無節操に乗ってしまったことにある。 Ｎｏ．：0022　　（0020） 投稿日：1999年12月02日(木) 15時37分53秒 投稿者：長谷川　亨 メール：hasegawa＠sra.co.jp タイトル： Re:２.様式と文化 本文： > > 逆に言えば建築もソフトウェアも、その適用領域と様式とを限定し >てはじめてある程度までの基盤技術の標準化・共有化が可能であると >いうことであろう。これまでの、適用領域や様式に対する戦略をなお >ざりにしたままのソフトウェアの部品化や工程の標準化の努力が、具 >体的な成果のない模索に終わっているのは当然と言えば当然なのであ >る。 この見方には、賛同を感じます。 ここで言う「ソフトウェアの部品化や工程の標準化の努力」がなぜ できないのかと言うのが問題だと思います。 1.努力する時間とコストが大変。 2.効率よく努力し、コストを最小限に抑えようとするには、 　適用分野の見極めが必要だと思いますが、これが難しい。 3.多分、建築など分野は目に見える世界なので、頭の中だけで 　なく、目から入る情報でもその適用分野を絞ることが 　できるのではないかと推察してます。 長谷川 Ｎｏ．：0023　　（0022） 投稿日：1999年12月06日(月) 19時36分44秒 投稿者： e-tamura メール：Re:Re:２.様式と文化 タイトル： 本文： >> 逆に言えば建築もソフトウェアも、その適用領域と様式とを限定し >>てはじめてある程度までの基盤技術の標準化・共有化が可能であると >>いうことであろう。これまでの、適用領域や様式に対する戦略をなお >>ざりにしたままのソフトウェアの部品化や工程の標準化の努力が、具 >>体的な成果のない模索に終わっているのは当然と言えば当然なのであ >>る。 >この見方には、賛同を感じます。 >ここで言う「ソフトウェアの部品化や工程の標準化の努力」がなぜ >できないのかと言うのが問題だと思います。 > >1.努力する時間とコストが大変。 ◆1点目 複雑だとソフトウェア業が成り立つから。 Mac のインターフェースだと簡単でも Windows のインターフェース だと大変。でも売れているのは色々理由があるにせよご存知の通り。 ◆２点目 標準化に対して対価を直接払う仕事を取るビジネスをしないから Ｎｏ．：0024　　（0021） 投稿日：1999年12月06日(月) 21時50分35秒 投稿者：e-tamura メール：Re:３．不幸の構図 タイトル： 本文： > かくしてソフトウェア業は、構造的に不幸な「構造不幸業種」とな >ってしまった。ことの起こりは、この業界が未成熟のまま、ソフトウ >ェアとは何か、ソフトウェア開発とはどういうことかといったことに >ついての、文化的な洞察や様式的戦略なしに、根拠のない好況の波に >無節操に乗ってしまったことにある。 文脈のゴールはなんですか？ ・もっとお金を俺にくれ。 ・もっと時間かけて品質良いものを作って提供したい。 ・もっと楽にソフト業をこなしたい。 ・もっとスマートにソフト業を行いたい。 ・おれらはこんなに苦労してるんだぜ、偉いでしょ。 ・現実はこうなんだぜ、の暴露。 ・これからソフト業界に入ってくる人へのアドバイス。 ・ユーザに対して圧力がかけられる。 ・保守業の実態を分析する為の材料提供。 ・ 問題・課題を認識した上での解決策の提示。 ---------------------------------------------- 解決策＝お金になることなので、開示するかな？ 画期的な策(すっごくお金になる事)を開示できないなら、その不安は無いですね。 Ｎｏ．：0025　　（0014） 投稿日：2000年01月04日(火) 16時23分53秒 投稿者：松永 真 メール：makoto_matsunaga/ast＠ast.co.jp タイトル：議事録「99.12.27」 本文： 日時　1999.12.27（月） 16:00 − 18:00 出席者　岸田さん、馬場さん、長谷川さん、増井さん、松永（記） 欠席者　なし 議題 １．検討テーマ ・ディスカッションフォーラムについて ・ホームページのコメントにつて ・ディスカッションフォーラム掲載個別テーマ ・次回のスケジュール ２．ディスカッションフォーラムについて ･現在の「説明書き」に以下の文章を追加（松永） 「なお、商用ＰＲの書き込み等はお断り申し上げます。 さらに、こちらでふさわしくないと判断したコメントは 削除いたしますので、ご了承ください。」 ･小浜合宿でのＹ２Ｋアンケート調査結果をＹ２Ｋフォーラム に登録しました。（松永） ３．ホームページのコメントにつて ･コメントとしてふさわしくないので、変更する。（増井さん） ･Ｙ２Ｋ関連リンクについても整理する。 ･Ｙ２Ｋについては、発生した事件等をフォーラムに入れて 頂くよう案内。 ４．ディスカッションフォーラム掲載個別テーマ ･「目標原価型価格決定方式」長谷川さんが提示。説明頂いた。 ･内容要約版をディスカッションフォーラムに掲載（長谷川さん） ５．次回作業部会 ・１月２７日（木）16:00〜 ・場所は全日空の朝倉さんと連絡をとり決定する。 Ｎｏ．：0026　　（0011） 投稿日：2000年01月20日(木) 11時16分09秒 投稿者：松永 真 メール：makoto_matsunaga/ast＠ast.co.jp タイトル：５.新しいパラダイムの模索 本文： ５．１ ソフトウエアは変容する フォン・ベルタランフィーの一般システム理論の流れを汲む有機 システム論では「システムとは、その性質がそれ以上小さな単位の 性質に還元しない統合された全体のことをさす」。つまり、システ ムは本質的に、分割すると意味を喪失する。いわゆるシステムと呼 ばれるもののうちでも社会的システムが、この様な性質を持ってい ることは、異論なかろう。 そもそもソフトウエアは、そういった現実世界の事象を計算機の 世界に投影したものである。その目的は、数値計算の実行や情報の 蓄積や金銭の授受などを記号の世界で実現することであり、さまざ まなバリエーションはある。しかし基本的な構図に変わりはない。 現実世界の具体的事象を抽象的な概念モデルにクラス化し、それを 計算機上にインスタンス化したものがソフトウエアである。 われわれは経験的に、ソフトウエアの仕様が常に変化することを 知っている。開発後であれば機能拡張とか保守という名目のもとに 対処されるが、開発途中ではこれはしばしばトラブルのもとになる。 しかし考えてみれば、現実世界が有機システムである以上、それを 投影した計算機システムも有機的な振る舞いをせざるを得ず、現実 世界の変化に伴って仕様が変更されソフトウエアが変容するのは、 ソフトウエアの本質なのである。そしてこのように時とともに変容 するものだからこそソフトウエアの部分と全体との関係は機械的・ 静的には仕様化できないのだ。 Ｎｏ．：0027　　（0011） 投稿日：2000年01月20日(木) 11時23分11秒 投稿者：松永 真 メール：makoto_matsunaga/ast＠ast.co.jp タイトル：５．２ ソフトウエア・プロセスは流転する 本文： ソフトウエアは、それ自身で意味があるものではなく、使われ 動作することによって意味を発現さるものである。ソフトウエア はモノではなくコトである。 計算機利用はユーザーの諸活動を支援するものであり、従がっ てコンピューティング・プロセスはユーザー・プロセスのサブプ ロセスであるといえる。ならば、ソフトウエアを開発するソフト ウエア・プロセスもまたユーザーの諸活動の一部であり、ユーザ ー・プロセスのサブプロセスであることを認めなければならない。 われわれは得てしてソフトウエアプロセスを、開発者サイドの 業務プロセス内で閉じた系と錯覚しがちだが、実はそれは、発注 者と受注者の業務プロセスが重なりあったところにある二面的サ ブプロセスなのである。ソフトウエア開発の際に、スパイラル・ モデルやプロトタイピングのアプローチを採用するということは、 ソフトウエアがあらかじめ仕様化不可能であることを認めた上で ユーザー・サブプロセスとしてのソフトウエアプロセスと開発者 サイドの業務プロセスとのインターフェースをとるということを 意味している。いわゆるＳＩやアウトソーシングの潮流も、ここ を踏み外しては破綻しよう。 ソフトウエア技術者は、このような受注者プロセスと発注者プ ロセスの共有場を舞台として、パフォーマンスを演じていると見 ることができる。オフ･ブロードウェイからブロードウェーへと至 る過程で観客の反応を見、楽屋の様子をうかがい、改良を加えな がら繰り返し繰り返し演じ続ける。ソフトウエアプロセスは、パ フォーミング・アートなのである。歌って踊れるプログラマとい う言説は、このような文脈において戯れ言ではない。しかもこの パフォーマンスは、劇団があり、観客がいる限り、止むことはな い。ストーリーが変わり、配役が変わっても、パフォーマンスは 繰り返される。 パフォーマンスが成功したか失敗したかを判断する手がかりは 観客の反応である。観客が拍手し、立ち上がり、喝采を叫べば、 そのパフォーマンスは成功したと見て良い。そのようなパフォー マンスにあっては、客席は舞台と一体となっており、観客はパフ ォーマンスに没入している。 印象派の絵画が見るものに見るということへの参加を要請した ように、パフォーミング・アートとしてのソフトウエア・プロセ スには観客の参加が必要である。 では、このようなソフトウエアやソフトウエア・プロセスは、 われわれソフトウエア技術者に何を要求しているだろうか。 Ｎｏ．：0029　　（0011） 投稿日： 2000年01月20日(木) 11時31分36秒 投稿者：松永 真 メール：makoto_matsunaga/ast＠ast.co.jp タイトル：５．４ 修行 本文： 技術変遷のめまぐるしさと対象領域の多様化、さらに境界領 域の拡大により、今日のソフトウエア技術者にとっての技術開 発、技術習得は、高度に困難なものになっている。画家にとっ てデッサンやコンクールや鑑賞などの日々の訓練とそれを支え る機構が必要なように、ソフトウエア技術者にとっても教育と 修行の場が必要である。 一般に、様式の発生期には一握りの創始者が先駆的な仕事を 積み上げ、定着期にはマスエデュケーションによる流布が行わ れる。しかし今日のソフトウエア業界のような様式の発展期に あっては、かつての画家や手工業者たちの徒弟制度あるいはギ ルドといった、伝搬と改良のメカニズムが有効であろう。師匠、 職人、徒弟という縦方向と職人の遍歴やギルドを通じての横方 向の技術移転が、技術者の育成文化の定着とを促進すると共に 新たな発展への可能性を育む。 Ｎｏ．：0030　　（0011） 投稿日：2000年01月20日(木) 11時44分35秒 投稿者：松永 真 メール：makoto_matsunaga/ast＠ast.co.jp タイトル：６ 位相 本文： 本稿では、受託開発型のカスタムメード・アプリケーション ソフトウエアに限定して議論を進めてきた。システムソフトは 一部のベンダーのものであるし、準システムソフトと呼べるよ うなツール類はパッケージソフトとして市場を形成している。 一方では技術の囲い込みによるテクノヘゲモニーに対し異を唱 える人々が、これらのフリーソフトウエア化に邁進しており、 いずれにせよこのような分野のソフトウエアは様式なり価格な り市場に問う体制が整いつつある。ひとりカスタム・アプリケ ーションソフトウエアだけが全く展望の無いまま取り残されて いる。 昨今合い言葉のように語られる「ネオダマ」は、芽吹いて日 の目を見るのは１９８０年代になってからであるが、その種が １９７０年前後に既に蒔かれていたのを知る人は少ない。しか しソフトウエア業界のこれら技術へのキャッチアップは、いま 緒についたばかりである。われわれはこの２０年間、何を見、 何をしてきたのだろうか。 たとえば家電需要のＡＶ機器から白ものへの回帰は、多品種 少量生産に象徴された差異動機の終息を意味しても、少品種大 量生産に象徴された欠乏動機の再興を意味するわけではない。 そこが不況の不況たるゆえんである。この不況を複合不況など という経済の枠組みで語り捨ててしまってはならない。これは 生活意識の変容であり、時代精神の変革なのである。 根拠の無い好景気は耳障りなノイズとともに消え去り、視界 はこれまでになくクリアである。人々が地に足のついた生活を 取り戻そうとし、コミュニティーの意味を再発見しようとして いる今こそ、コンピューティングが真に文化たりえるかが問わ れている。どのようなソフトウエアやソフトウエア・プロセス が会社に受け入れられるのか。どのようなフトウエアやソフト ウエア・プロセスが会社に貢献できるのか。ソフトウエア技術 者の目は、コンピュータと会社の両方を向いていなければなら ない。 Ｎｏ．：0031　　（0011） 投稿日：2000年01月20日(木) 11時52分41秒 投稿者：松永 真 メール：makoto_matsunaga/ast＠ast.co.jp タイトル：５．３ ソフトウエア技術者は照観する 本文： 現実世界と不整合に陥り不可逆的に劣化するソフトウエアは、 それ自身で自己組織化できるほど「生き物」ではない。従がっ てその維持・修復や変化への適応をソフトウエア技術者が手伝 わなければならない。 植木職人の仕事が庭に木を植えるだけでないのと同様、ソフ トウエア技術者の仕事も線形完結的なものではない。顧客が欲 しいのは木そのものではなく、木々が庭として生活空間の一部 を構成し続けることであり、ソフトウエア技術者はその変容す る全体の調和を保ち、境界の連続性を保つための長期的な維持 管理者とならなければならない。例えばオブジェクト指向が定 着するとすれば、言語処理系に添付されるよう低次のクラスラ イブラリや、業界団体などによって規定されるかも知れない高 次の汎化クラスに加えて、顧客サイトごとのプロプライエタリ なクラス群すべてに精通しなければシステム構築において適切 なアプローチを取り得ないことになる。ソフトウエア技術者に、 あるいはソフトウエア企業に、それだけの覚悟があるだろうか。 ソフトウエアの偶発的複雑さは排除できてもソフトウエアの 本質的複雑さはアプリオリなものであり、対象領域の拡大と共 に非線形的に増大する。しかもそこには現実世界から計算機の 世界に至るまでのあまりに深い概念的階層が広がり、全体が部 分に還元できないとすれば、ソフトウエア技術者は三千世界を あまねく照観せねばならない。ソフトウエアがかくも難しいも のであることを顧客は知っているだろうか。神ならぬ身でかく の如き能力が求められていることをソフトウエア技術者は心得 ているだろうか。 Ｎｏ．：0032 投稿日：2000年02月04日(金) 16時20分29秒 投稿者：宮田 メール：miyata＠sra.co.jp タイトル：Cグループ議事録1999.7.14 本文： ＳＭＳＧ・Ｃ・Ｇｒｏｕｐ「保守のペーパーレス環境」 第１回定例会議事録 １．開催日時：１９９９年７月１４日（水）１３時３０分〜１７時 ２．場所：労働スクエア（八丁堀） ３．出席：蜂須賀（ＣＣＣ）、倉岡（ＳＲＡ）、高橋（ＴＫＣＣ） 仲本（ＣＣＳ）、田中（ＡＳＴ） ４．検討事項 （１）定例会の運用方法 毎月第３金曜日に定期的なミーティングを行なう。 ただし、開催予定日は毎回出席者に確認して決定する。 内容は課題（宿題）のレビューを行なう。 開催場所は参加各社の会議室を利用させていただく。 とりあえず、以下のように仮決めさせていただきました。 ９９年８月２５日（水） ＡＳＴ（池袋） ９９年９月 ＴＫＣＣ（群馬県高崎） ９９年１０月 ＣＣＣ（芝公園） ９９年１１月 全体合宿（福井県小浜） ９９年１２月 ＣＣＳ（亀戸） ２０００年１月 ＳＲＡ（大阪） ２０００年２月 ＳＣＩ（千代田区一番町） ２０００年３月 未定 ２０００年４月 部会合宿（場所未定） （２）世話役 リーダー：田中（ＡＳＴ） サブリーダー：蜂須賀（ＣＣＣ） （３）研究内容 ○保守現場におけるテストの実態と成果物 ○テスト作業の標準化（作業工程と成果物） ○標準適用上の問題点（２０％程度解決させるには） ○テスト工程におけるグループウェアの活用 等々の意見がでましたが、今後のミーティングで 順次、決めていくことになりました。 （４）次回の課題（宿題） 次回出席の折には次の調査報告を各社の方々に発表して いただきますので、準備のほど、よろしくお願いします。 「保守現場におけるテストの実態を以下の点について調査し まとめる」 (1)テストの種類 (2)テストの作業内容 (3)テストの成果物 (4)テストの参加者／関係者 (5)テストの工数 (6)テストの問題点 (7)その他の特徴的な事項 ５．次回開催案内 日時：９９年８月２５日（水）午後１時３０分から午後５時 場所：（株）エイ・エス・ティ（東京都豊島区） ＡＳＴビル１Ｆ会議室（当日、案内板に部屋番号を掲載します） 最寄りの駅はＪＲ池袋駅またはメトロ有楽町線東池袋駅です。 詳細は添付ファイルを参照ください。 ミーティング終了後、懇親会を予定しておりますのでこちらも なるべく参加していただきますようにお願い申し上げます。 Ｎｏ．：0033 投稿日：2000年02月04日(金) 16時21分41秒 投稿者：宮田 メール：miyata＠sra.co.jp タイトル：Cグループ議事録1999.8.25 本文： 99第2回ｿﾌﾄｳｪｱ･ﾒｲﾝﾃﾅﾝｽ研究会Ｃグループ(SMSG・Ｃ) 定例会議事録 １．日　時：平成１１年8月25日（水）１３：３０〜１７：００ ２．場 所：（株）エイ・エス・ティ　（池袋） ３．出席者：田中（ＡＳＴ）（進行）、蜂須賀（ＣＣＣ）、植田（ＣＣＣ）、仲本（ＣＣＳ）、宮田（ＳＣＩ）、 （敬称略）倉岡（ＳＲＡ）、高橋（ＴＫＣＣ）（書記） 　　　　　　欠席：・中（ＪＦＩＴ）、小林（ＴＡＳ）　 ４．議 題： 　　　　　　＜１＞自己紹介（前回欠席の方） ＜２＞Ｃグループ運用ルール確認 ＜３＞保守現場に於けるテストの実態（各社報告） ＜４＞保守の定義付け（意識合わせ） 　　　　　　　　　＜５＞今後の活動 ------------------------------------------------------------------- １．自己紹介 　　前回欠席された、ＣＣＣ・植田氏、ＳＣＩ宮田氏に自己紹介していただく。 ２．Ｃグループ運用ルール確認 　　毎月第３金曜日の午後を定例会とする 　　定例会は、各社持ち回りで開催 　　　 　　　９９年９月 ＴＫＣＣ（群馬県高崎） ９９年１０月 ＣＣＣ（芝公園） ９９年１１月 全体合宿（福井県小浜） ９９年１２月 ＣＣＳ（亀戸） ２０００年１月 ＳＲＡ（大阪） ２０００年２月 ＳＣＩ（千代田区一番町） ２０００年３月 CCC（大阪）　　　　　……前回は未定だったが、植田氏に依頼 ２０００年４月 部会合宿（場所未定）…論文の仕上げを目的として　 　 ３．保守現場に於けるテストの実態（各社報告） 　　今年度のテーマである「保守のペーパーレス環境（テスト工程）」を検討していく上で、 　　現状のテスト工程の実態について報告する　　 　　（テストの種類） 　　　　　　・単体テスト、検証テスト　 　　　　　　・ホワイトボックステスト、ブラックボックステスト　 　　　　　　・単体テスト、結合テスト、運用・総合（ユーザ）テスト 　　　　　　・単体テスト、組合せテスト、システムテスト、性能テスト、回復テスト、運用テスト 　　（テストの作業内容） 　　　　　　・テスト手順書（シナリオ）作成 　　　　　　・テスト項目洗い出し　、テスト仕様書作成 　　　　　　・データ作成、環境整備、スタブ・ドライバ・データ移行プログラム作成 　　　　　　・チェック、検証　 　　　　　　・完了報告 　　（テストの成果物）　 　　　　　　・作業依頼書 　　　　　　・仕様確認Ｑ／Ａ、議事録 　　　　　　・テスト手順書（シナリオ） 　　　　　　・テスト仕様書、テスト結果報告書、機能確認報告書　 　　　　　　・作業状況、経過（電子メール等で管理） 　　　　　　・結果確認のリスト類（ダンプリスト、画面ハードコピーなど） 　　　　　　・作業完了報告　 　　（テストの参加者） 　　　　　　・保守担当者（プログラマ、ＳＥ） 　　　　　　・開発者、設計者 　　　　　　・利用者　 　　（テストの工数）　 　　　　　　・新規と同じに総ステップから、生産性で求める（解析工数を考慮し） 　　　　　　・作業日数を予想し、そちらから逆にステップ数を出してしまう（経験値から） 　　　　　　・「経験」と「勘」で　 　　　　　　・ソースコード量に依存 　　　　　　・テストケースに依存 　　（テストの問題点）　 　　　　　　・手順書、仕様書作成のノウハウ不足（設計者不在） 　　　　　　・保守担当者のローテーションが困難　 　　　　　　・着手が遅い、時間がない、期間が短い　 　　　　　　・再利用ができない 　　　　　　・テスト項目が少ない 　　　　　　・既存システムへの影響がある　 　　　　　　・何をもって検証ＯＫとするか、物理的な証拠が残らない　 　　　　　　・テストに対する注目度が低い　 　　　　　　・他の人が再現できない 　　　　　　・開発者がそのままテストしてしまっている 　　　　　　・テストケースは個人まかせ、変更箇所のみのテストにとどまる 　　　　　　・環境設定に時間が・かる 　　（その他特徴的な事項）　 　　　　　　・テスト資料が新規システムより少ない（入出力中心） 　　　　　　・テストデータに本番データを用いることが多い　 　　　　　　・ブラックボックステストのツールがない　 　　　　　　・プログラム変更の影響を最小限にとどめ、テスト工数やリスクを軽減しようとしている 　　　　　　・比較テスト（修正前と修正後）を行うことが多い　 ３．保守の定義付け（意識合わせ） 　３．１　定義　 　　「保守作業でのテスト」について、メンバーの意識が違うと今後の討論に影響が出るた 　　め、定義付けを行う　 　　 　　「保守」　　　　　：既存プログラムの修正作業を行ったもの 　　「保守のテスト」：プログラム修正したもののテスト　 　　「テストの種類」： 　　　　　　　　　　　　　　工程　　　単体　　　　　　結合　　　　　　　総合　　　　　 　　　　　　　　　　　　　　手法　　　ホワイト　　　　ブラック　　　　　ストレス　　　　 　　　　　　　　　　　　　　技法　　　 　　　　　　　　　　　　※　上記マトリックスをＡＳＴ田中氏が作成（各メンバーにメール） 　　　　　　　　　　　　　　　メンバーは、各自［色分け］を行う（次回までに）　 　　「修正規模」　　：小（１日、１本）、中（５日、数本）、大（３０日、数十本） 　　「アプリの種類」：基幹系、事務系、情報系　 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　品質保証のレベルに関わってくる　　 　　「利用者」　　　　：社内、社外 　 　　また、これら上記の項目は、保守のテストの形態を考える上でのパラメタとなるのではないか。 　　３．２　保守の作業フローを考える　 　※　次回までに、各自作業フローを作成してくる 　　　　　　　　　　　　　　　　　　理想も取り入れて（「こうあるべき」の形） 　　　　　　　　　　　　　　　　　　事例として、画面への項目追加・１本１日程度の保守作業で考える ４．今後の活動　 　　「次回までに」　 　　　保守のテストの作業フローを考える（実態と理想を取り入れて） 　　　テスト作業項目のマトリックスを考え、必須、推奨、不要など色分けをしてみる　 　　「今後の活動テーマ」　 　　　・品質の計数化　 　　　　　　　何のためにテストするのか　、品質保証　 　　　　　　　カバレッジ分析　 　　　・再利用について　 　　　　　　　テスト仕様、データ　 　　　・テストの自動化について　 　　　　　　　テストデータ自動生成　 　　　・テスト仕様書のサンプル集め 　　　　　　　標準化に向けての判断材料 　　　・次頁に次回開催案内を添付　 　　（次回開催のご案内） 　　　日時：　９／１７（金）　１３：３０〜　１７：００　 　　場所：群馬県高崎市栄町４・１１　原ビル３Ｆ　 　　　　　（株）高崎共同計算センター　（ＴＫＣＣ）　　　 　　担当：高橋　 Ｎｏ．：0034 投稿日：2000年02月04日(金) 16時22分40秒 投稿者：宮田 メール：miyata＠sra.co.jp タイトル：Cグループ議事録1999.9.17 本文： ソフトウェアメインテナンス研究会 Ｃグループ 『保守のペーパーレス環境』 第３回定例会議事録 =================================================================== １．日　時　　１９９９年９月１７日(金) １３時３０分〜１７時００分 ２．場　所　　(株)高崎共同計算センター（群馬県高崎） ３．出席者　　高橋(ＴＫＣＣ)※進行，田中(ＡＳＴ)，倉岡(ＳＲＡ)， 　 (敬称略)　 仲本(ＣＣＳ)，植田(ＣＣＣ)，小林(ＴＡＳ)， 　　　　　　　蜂須賀(ＣＣＣ)※書記 　 欠席：宮田(ＳＣＩ)，・中(ＪＦＩＴ) =================================================================== 　　　　 ４．議　事 (1)保守の作業フローを考える（各自作成のフローより議論） 　　@作業項目 　　・大規模保守でも小規模でも実施すべき作業項目は同じではないか。　　 　　・いや、小規模ならば省く作業もあるのでは。 　　・画面１項目追加程度の修正では総合テスト以降は省いている。 　　Aテストの実施者 　　・あるべき論で考えると前回定例会で宮田氏が述べられていたテスト 　　　部隊の独立は必要。 　　・いや、現実の与えれた工数を考えると難しいのでは。 　　・品質保証のレベルに応じて変わるのでは。 　　・設計〜移行まで一人で担当する縦割り体制の方が効率が良いのか、 　　　テスターをつける方が効率的なのか？？　 　　B作業見積り 　　・契約形態によりまちまち。 　　　案件毎に見積もり、実績精算、半期に一度の見積、見積しない・・・　 (2)保守作業で必要と考えられるテスト工程 　　・結合テストTはみな必要と考えているが、 　　　単体テストや結合テストU〜運用テストは保守の規模が拡大するに 　　　つれてその範囲もひろがる。 　　・受入れテストの必要性は各自の考えにばらつきあり。 　　 (3)保守のテストで有効と考えられるテスト技法は？ 　　・テスト技法という呼び名を今後はテストケースとしたい。 　　・なんとなく、リグレッションテストがキーワードとなりそう。 　　　リグレッションテストをどう効果的、効率的に実施するか？ 　　　過去のテストデータの再利用、修正前／修正後の比較検証・・・ 　　・単体テストではホワイトボックス、結合テストではブラックボックス 　　　のテストが必要。 　　・ホワイトボックステストでは机上のコーディング確認で大半が有効性 　　　を確認できるのでは？ 　　　設計者(指示者)に対し、何も質問してこないプログラマについて特に 　　　有効だと思う。 (4)保守のテストで必要と考えられるドキュメントは？ 　　・運用テストフェーズのドキュメントとして操作マニュアルを追加する。 　　　操作マニュアルの作成もとは？ユーザ？ 　　・テスト仕様書を要件確認書として代用できないか？ 　　　(同じようなドキュメントをいくつも作成することを避けたい) 　　・新規開発時には設計書にテストチェック欄を設け、テスト仕様書作成 　　　を省いた経験がある。 　　・テスターへ指示するテスト仕様書とユーザ受入れテスト時に使用する 　　　検証要領書を兼ねて、ドキュメント作成負荷を軽減している。 (5)保守のテストで有効と考えられるツールは？ 　 ＡＳＴ田中氏より紹介 　　・ＥＳＷ・ＳｍａｒｔＴＥＳＴ（アプライドテクノロジー） 　　　ＣＯＢＯＬソースをＰＣ上でテスト支援する。 　　　評価：ＨＯＳＴ資産をＰＣへダウンロードする必要があり、 　　　　　　その手間が活用を阻害する。・・・　導入経験より 　　・ＴＥＳＴＡＩＤ２０００（ＮＲＩ情報） 　　　Ｙ２Ｋテスト支援ツール。テストデータ(日付項目)作成を支援。 　　　評価：不明 　　テストツールに関しては、これといったものが無く種類も少ない。 　(6)ペーパーレスへの期待 　　テスト対象の規模・目的等のパラメタを入力すると、 　　テスト範囲(工程)、品質目標、テストケース、ドキュメントなどが 　　示されるといいな。 　(7)今後の予定 　　以上の検討事項内容から見えてくるものとして、テスト仕様書(報告書) 　　の重要性があげられる。 　【次回検討事項】 　　@テスト仕様書(報告書)の研究 　　A合宿11/11(木)〜13(土)福井県小浜 の活動予定検討 　【課題】テスト仕様書(報告書)のサンプル持ち寄り、 　　　　　どんな項目が必要か？、問題点、あるべき論 などなど 　　　　　をまとめてくること。 =================================================================== ５．次回開催案内 　　日　時　　１９９９年１０月１５日(金) １３時３０分〜１７時００分 　　場　所　　中央コンピューター(株) 東京事業部会議室 　　　　　　　芝公園ＮＤビル２Ｆ　　 東京都港区芝２・５・１０ 　　　　　　　　　　　　　　　　　 TEL 03(5440)1680 　　　　　　　最寄り駅は 　　　　　　　都営三田線芝公園(Ａ１口より徒歩５分)， 　　　　　　　ＪＲ浜松町(南口より徒歩１２分)となっています。 　　　　　　　詳細は添付ファイル(ＧＩＦファイル)を参照してください。 　　　　　　　２Ｆエレベーターを降りた向かいが、事務所入口となって 　　　　　　　おります。入ったすぐのところが受付カウンターです。 　　　　　　　蜂須賀を呼び出してください。 　　　　　　 ９／２０現在、当ビル目印の１Ｆ日産ショールームが無く 　　　　　　　なり、正面入口が閉鎖されています。 　　　　　　　当ビル入館はビル両わきの通用口からとなります。 　　　　　　　　　　　 　　ミーティング終了後、懇親会を予定しておりますので、 　　こちらもなるべく参加して頂きますようにお願いします。 Ｎｏ．：0035 投稿日：2000年02月04日(金) 16時28分35秒 投稿者：宮田 メール：miyata＠sra.co.jp タイトル： Cグループ議事録1999.11.11 本文： ======================================================================== 　　ＳＭＳＧ・Ｃ第４回小浜議事録・次回開催案内 ======================================================================== 打合せ議事録 （記入者：ＣＣＳ　仲本） （１）打合せ内容 ：ＳＭＳＧ全体研究会 （２）日　・　時 ：１９９９年１１月１１日（木）〜１３日（土） （３）打合せ場所 ：小浜市中央公民館 （４）出席者（敬称略）：小林（ＴＡＳ） 植田（ＣＣＣ） 宮田（ＳＣＩ） 高橋（ＴＫＣＣ） 田中（ＡＳＴ） 倉岡（ＳＲＡ） 仲本（ＣＣＳ） 欠席 ：・中（ＪＦＩＴ） 蜂須賀（ＣＣＣ） ======================================================================== １．議事「１１月１１日（木）」ＰＭ１５：００〜１７：００ （１）オリエンテーション（岸田代表幹事あいさつ） （２）基調講演「保守におけるソフトウエアー構成管理を楽にしよう」 ニルソフトウエアー代表取締役 伊藤 昌夫氏 ２．議事「１１月１２日（金）」ＡＭ９：００〜１３：００ （１）前回の宿題について １）テスト仕様書（報告書）のサンプル持ち寄り。 ２）どんな項目が必要か？（テストケースについて考える） @レンタルビデオ店の顧客管理システムのメンテナンス （年齢項目の追加・会員区分に不良会員を追加する例） AＹ２Ｋのケースでは？等をまとめる。 B設計書とテスト仕様書を１つにできるか考察する。 （２）前回の宿題について討議 １）宿題について考察したが答えが出せなかった。 ２）過去のテスト仕様書が再利用できるか疑問である。また必要ないのでは？ ３）ストケースが単純すぎた。またＹ２Ｋは範囲が広すぎた。 ４）Ｙ２Ｋは範囲が広すぎて過去のケースデータがそろっていないのではないか。 但し、過去のケースがあることを前提とすれば運用はある程度可能ではないか。 ５）過去のケースを調べるよりシステム担当者に仕様を聞いてしまう。また検索も も難しいのではないか。 ６）設計書とテスト仕様書を１つにすることはある程度は可能であるが性能テスト は無理があるのではないか。 ７）Ｋａｍｉｌａｎの運用を考えたとき、要求仕様とテスト仕様のマッチングが 大変である。 ８）変更仕様書とテスト仕様書はレベルが違いすぎて１つにするのは無理があるので はないか。 ９）各社どの様な設計書を作成されているのか知りたい。 １０）Ｋａｍｉｌａｎの運用について、過去の変更仕様のデータ蓄積がない状況から 考え直したい。 １１）現状行っているテスの方法が正しいのか、また保守テストの課題について見直し を行いたい。 １２）保守のテスト範囲も押さえておく必要がある。 １３）保守における問題提起として。 @システム全体についてテストする余裕があるのか？しかし変更部分のテスト だけだは不十分である。 A開発時の設計資料がメンテナンスされないと稼動しているシステムと設計書が 乖離してしまう。 Bホワイトボックステストは、テスト作業の範囲が広すぎてしまう。 Cバグ発生率などの統計的分析は、結果であって何をどれだけテストすれば良い と言うことはわからない。 D必要なテスト範囲についてパターンを考察することとした。 テストパターン詳細については、田中氏送付の「ＳＭＳＧ中間報告991113」を ご参照下さい。 １４）テストパターン（Ｗ：ホワイトボックス Ｂ：ブラックボックス） ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 全体ＴＳ 部分ＴＳ I コスト 網羅率 発見した 評価 Ｗテスト Ｂテスト Ｗテスト ＢテストI 不具合数 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ １ ― ― ― ― I ０ 無 無 無 ２ 有 I １ ― △ □ ３ 有 I ２ △ ― ４ 有 有 I ３ △ △ 勧 ５ 有 I ３ ― ○ × ６ 有 有 I ４ ― ○ □ ７ 有 有 I ５ △ ○ × ８ 有 有 有 I ６ △ ○ 勧 ９ 有 I ４ ○ ― × １０ 有 有 I ５ ○ △ × １１ 有 有 I ６ ○ ― １２ 有 有 有 I ７ ○ △ １３ 有 有 I ７ ○ ○ × １４ 有 有 有 I ８ ○ ○ × １５ 有 有 有 I ９ ○ ○ × １６ 有 有 有 有 I １０ ○ ○ ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 評価：無：ケース外 □：現状保守で行っているテストケース 勧：テストケースとして評価できるケース ×：ありえないケース ３．議事「１１月１２日（金）」ＰＭ１３：００〜 （１）小浜市内見学 ４．議事「１１月１３日（土）」ＡＭ９：００〜１０：３０ （１）テスト仕様について前日に引き続き討議 １）開発時にテスト仕様のぺーパレスを実現するにはどのようにするべきか。 ２）システムの規模を明確にしないとテストの前提が決らないのでは。 @大規模なシステム改造は、新規開発と同じ A小規模なシステムではテスト仕様書も必要ないのではないか。 B開発規模は、１つの修正に対して３人日程度のものが前提か？。 ３）前提とする保守は、最低単位の要件の集合と考えている。 ４）昨日は、テストが必要な範囲の定義を考察した。 ５）エラーのテストケースを作る作業は煩雑である。 ６）テストの為のプログラムを作成する必要はある。 ７）テスト仕様書を作成しているが事前の記入項目は整備されていない。 ８）担当していないシステムのメンテナンスはシステムを知っている担当者 資料を作成してくれれば、作業が楽になる。 ９）テスト仕様の再利用しようとしても修正箇所が変るので本当に再利用 できるのであろうか？ １０）テストの準備資料等のノウハウは残す必要があるのではないか。 １１）テストデータの保存をレコード単位に保存できない。 １２）テストデータのコンバージョンプログラムは準備している。またテスト データは、ＭＯ等に保存している。 １３）テストデータとしてでなく、テストパターン表として保存しておくのも 再利用としては有効ではないか。 １４）テスト仕様書の項目の標準化の必要はないのか？ １５）テストデータをツールとして保存させる手間もかかる。 １６）今後検討課題として @テスト仕様書の項目を引き続き検討する。 ・テスト結果の報告資料を集める。 ・バグ報告書を集める。 A過去のデータの再利用と保守管理の仕方の２つが重要であり、後者についても 検討を行う。 B修正ドキュメントの検索方法を検討する。 Cホワイトボックステストのガバレッジ（運用基準）を決める。 DＫａｍｉｌａｎの機能ＵＰを検討する。 ５．議事「１１月１３日（土）」ＡＭ１０：３０〜１２：００ （１）各グループごとの発表会 １）Ａグループ オープンシステムの保守 「ＣＳ顧客満足度の向上のための方策」 ２）Ｂグループ 保守作業改善の基盤技術の調査 ３）Ｃグループ 保守のぺーパレス環境 ４）Ｄグループ ＳＭＳＧが考える保守とは。 ======================================================================== ６．次回開催ご案内 （１）日時：９９年１２月１７日（金） 午後１時３０分から午後５時 （２）場所：ＣＣＳ（株） （東京都江東区亀戸６・４１・１０） Ｋ・スクエアービル（７Ｆ第三会議室） ２Ｆに受付がございますので、ここで、第一ビジネスシステム部 第一課の仲本を呼び出して下さい。 最寄りの駅は、総武線の亀戸駅です。 駅のホームは、進行方向千葉方面の出口ににおりて下さい。 詳細は添付資料を参照下さい。 ミーテイング終了後、懇親会も予定しておりますのでこちらも なるべくご参加して頂きます様にお願い申し致します。 以上 Ｎｏ．：0036 投稿日：2000年02月04日(金) 17時29分43秒 投稿者：宮田 メール：miyata＠sra.co.jp タイトル：Cグループ議事録1999.12.17 本文： ================================= SMSG Cグループ12月定例会議事録 日時：1999年12月17日 13:30〜17:00 場所：CCS（株）7F第三会議室 出席者：仲本(CCS)、高橋(TKCC)、蜂須賀(CCC)，宮田(SCI) 倉岡(SRA)-->議事録 欠席 ：田中(AST)，植田(CCC)、小林(TAS)，・中(JFIT) （敬称略） ○過去のデータについて再利用できるか検討してみた。 ・テストに使ったファイルは残るが、画面やＤＢが残らない。 ・（オンライン操作の）通信のテストができない。 ・画面のハードコピー、ＤＢのコピーの検索はkamilanでは無理。 ・汎用機の端末から入力したデータは再利用できるか？ ---> やり取りしたデータを保存できるツールがあれば可能。 --->3270エミュレータのログがある。 ・入力した操作を保存しておく機能をあらかじめホスト側に作っておく。 --->IBMの地図情報システムパッケージ(GPG)に操作した情報をコマンド レベルで入力した座標までもテキストとしてファイルに保存できる 機能がある。 ・通信のデータの保存は、他社とのデータのやり取りとなるので難しい。 但し、理論的には再実行は可能である。 ・画面またがりのテストも難しい。 ・キーボード情報は保存できる。（バーコード） ・システムはメインテナンスされて行くので、古いデータはその内容が変更され なければ再利用できない。 ・条件をつけた検索で、保存されたデータは検索可能か？ ->GPGのテキストファイルならば、座標○○以上という条件でも検索可能 ->エミュレータ、通信、キーボードは無理 ->画面の絵もビットイメージでは無理 ===>これだけ厳しい条件では、再利用できるテストケースは限られてくる。 ・テストデータのkamilanへの入力の手間も問題である。 ここで、入力についてまとめてみた。入力データとして =入力した操作したことやデータをテキストとしてファイルしておく =GPGのようなファイル =エミュレータ =通信したものから横取りしたもの =キーボード入力から横取りしたもの を考える。以上に対して、 1.保存できるのか 2.再実行できるのか 3.修正して再実行できるのか 4.検索できるのか を検討し、まとめてみた。 テキスト エミュレータ GPG 通信 キーボード 保存できるか - ○ - ○ - ○ - ○ - ○ - 再実行できるか - ○ - ○ - ○ - ○ - ○ - 修正して再実行できるか - ○ - × - ○ - × - × - 検索できるか - ○ - × - ○ - × - × - ○ＤＢの再利用について ・パラメータを与えて発生させる。 ・ＤＢその物を保存する --> テープ、ディスク ・保存できるか --> テスト機があると前提して考えないようにする ・リストアできるか --> 上に同じ ・修正してリストアできるか ＊内容の変更 ＊レイアウトの変更 --- レコード長変更、項目追加、リンク --- 実行時間、容量は? ＊インデックス変更 ・検索できるか ・ＤＢの種類は？ ＊リレーション型 ＊ネットワーク型 ＊リスト型 ＊ISAM型 ＊VSAM型 --------> 下に行くほど、複雑 --> 簡単になる ・ＤＢテストデータの再利用方法 ＊本番データから抜き出す ＊不足分は入力する ＊プログラムによるデータ作成 ＊プログラムでデータを選択する（本番データより） ＊本番データを全て保存し利用する ＊全てのデータを作成する ・ＤＢについて保存できる物 ＊ＤＩＳＫ ＊ＭＴ ＊プログラム（テストデータ作成） ＊誰が、いつ、目的 ＊分散しているＤＢ ○通信について ・他社どうしの通信でのテスト（例えば銀行） ---> これは難しいので考えない ○修正すべきドキュメントを検索する方法を考える ---> kamilanに検索ルールを憶えさせる （現kamilanではプログラムからドキュメントは検索できない） ・機能（英数字）、連番（数字４桁）で管理する 例えば、プログラム名（ABC1234） ドキュメント（ABC) ---> ABCで両者は結びつく ○修正ドキュメントの検索方法を検討 ・検索ルールボタンを押すと、ホルダから検索するか、名前から検索するか 選べるようにする ○議事録の掲示板への登録は宮田さんが担当する。 ○宿題 ・ＤＢの再利用、保守管理の方法を考える ・今回議論できなかった残りの課題を考える ========================================================== 次回開催ご案内 （１）日時：2000年01月21日（金） 午後１時３０分から午後５時 （２）場所：（株）ＳＲＡ関西支社 （大阪市西区阿波座2-1-1） プレゼンテーションルーム http://www.sra.co.jp/public/sra/company/address/osaka.html 大阪本町西第一生命ビル５Ｆです。 エレベータで５Ｆで降りて下さい。 左に行けば受付がありますが、右へ進んで下さい。 直接プレゼンテーションルームに入れるドアがあります。 直接お入り下さい。 最寄りの駅は、地下鉄本町駅です。難波寄りの出口から出て下さい。 地図を見ていらっしゃって下さい。駅から１５分ほどかかります。 中央大通り（上を阪神高速が走っている）の南側の歩道を西に向かって 歩いて下さい。中央大通りを右に見て歩くことになります。 中央大通りとなにわ筋の交差点の南西角のビルです。 以前あったビル１Ｆの日産のショールームは現在ありません。 ミーテイング終了後、懇親会も予定しておりますのでこちらも なるべくご参加して頂きます様にお願い申し致します。 Ｎｏ．：0037 投稿日：2000年02月04日(金) 17時30分35秒 投稿者：宮田 メール：miyata＠sra.co.jp タイトル：Cグループ議事録2000.1.21 本文： SMSG Cグループ1月定例会議事録 日時：2000年1月21日 13:30〜16:00 場所：（株）ＳＲＡ関西支社 5Fプレゼンテーションルーム 出席者：田中(AST)、仲本(CCS)、倉岡(SRA)、植田(CCC)-->議事録 欠席 ：宮田(SCI)、高橋(TKCC)、蜂須賀(CCC)、小林(TAS)、・中(JFIT) （敬称略） １．保守管理について検討を行う。 　　テスト段階での管理項目は何か？以下の５項目が上がり検討した。 　●進捗･･･kamilan対象○ 　　テストでの進捗とは･･･計画実績 　　進捗で共有化するもの---パート図 　　kamilanでは進捗に関しては入力の分散化を目指す（管理者が一人で入力するのは大変） 　●品質（統計）･･･kamilan対象外× 　　バグの件数（０件ならテストが足りない、予定している件数が出ているか） 　　テストカバレッジ率（１００％が理想、コスト的には困難） 　　(1) テストのカバレッジ率---１００％が理想であるが･･･ 　　(2) コードインスぺクション---机上で第三者が行う 　　 カバレッジ率を求めるならば１００％で無ければならない。 　 　１００％を満たせないものはコードインスぺクションで行う。 　　カバレッジ率とコードインスぺクションの切り分けの基準は修正量２０％以上で行う。 　　　２０％以上はがカバレッジ率１００％。 　　　　　　　　追加＋削除のステップ数 　　　　修正量＝─────────── 　　　　　　　　元のステップ数 　　　 　　　修正方法（機能追加）はどの様な方法があるか？ 　　　　・モジュール化　┐ 　　　　・コピー化　　　├テストカバレッジ１００％が必要（修正量２０％以上） 　　　　・マクロ　　　　┘ 　　　 　　　コードインスぺクションは全て行うか、抜き取りで行うかは、担当者、重要度によって決める。 　　　　　　↓↓↓ 　　　以上の検討を行ったが、これらはkamilanに入れる機能ではないという結論となった。 　　　（ペーパーレス、共有化する必要はない） 　●問題管理･･･kamilan対象○ 　　不具合に対して対応しているか 　　仕様のバグの公開（共通モジュールのバグの場合） 　●変更管理･･･kamilan対象外× 　　保守フェーズでは、スパイラル型の開発形態が多いのであえて考えない（仕様凍結がない） 　●コスト管理･･･kamilan対象外× 　　テストフェーズに予算の概念は無い ２．今後の進め方の検討を行った 　　２／１８---章立て、担当者を決める 　　３／１７---ドラフトレビュー 　　４／１４---最終チェック 　　合宿時期、候補地（熱海、箱根など）検討。結論は出ていない。 ３．次回の課題 　　テスト工程におけるkamilanの各機能の画面イメージ、紙芝居を作る。 　　それぞれについてデータの蓄積と検索がある（入力と検索）。 　　以下の様に担当を振り分けたので、担当の機能について作ってきて頂く。 　　作成はＥＸＣＥＬ、ＷＯＲＤ、ＰＰ、ＶＩＳＩＯ特に指定はしないが、ＦＤでもってきて頂きたい。 　　（次回プロジェクターを使用して議論したい） 　　＜kamilanの機能＞　　　　　　　　　　　　　　　 ＜担当＞　 　・進捗管理　　　　　　　　　　　　　　　　　　　　：仲本 　・テストデータ　　　　　　　　　　　　　　　　　　：蜂須賀 　・テスト仕様／テストケース　　　　　　　　　　　　：高橋 　・修正仕様の検索　　　　　　　　　　　　　　　　　：宮田 　・画面遷移（テストの為のオペレーションマニュアル）：植田 　・テスト計画書／テスト報告書　　　　　　　　　　　：小林 　・業務マニュアル（テストの為の業務フロー）　　　　：田中 　・問題管理　　　　　　　　　　　　　　　　　　　　：倉岡 　　　　 ＜以上＞ Ｎｏ．：0038 投稿日：2000年02月07日(月) 14時58分21秒 投稿者：宮田 メール：miyata＠sra.co.jp タイトル：Cグループ議事録1999.10.15 本文： 1999.10.15 SMSG議事録 (以下すべて会社名と敬称を略させていただきました) 出席者:蜂須賀,宮田,高橋,仲本,田中 場所:芝公園CCC会議室 [個別発表-宮田] 1.画面遷移を並べて始めて1つのテストケースになるようなテスト仕様が存在 この場合各画面に入力した項目を残さなければならないがどう保存するか？ 2.テスト終了マークとして、日付を記入,印を押す,チェックマークを付ける, テスト検証者の名前を書く等いくつかのパターンが存在。どうペーパレス化するか? 3.作成した人がテストしてはいけないと主張してる本の紹介(2冊) プログラミングの心理学より認知的不協和の記述を抜粋 4.テストケースは保存して再利用しなければならないという記述の紹介 [個別発表-宮田QA] ・作成した人がテストしてはいけないというのは本当か? 　自分の間違いを見つけるのは大変だが他人に指摘されるのも嫌では? ・本来は、発注者が作成とテストを別会社に発注するべき ・カーナビでそのような例が有った。 ・ホストシステムでできるだろうか?経費が2倍かかるのでは? ・4が事実であり実施されると仮定すると3は考えなくて良くなる。 　既に存在するテストケースを実施するのは実施する人に依存しないので。 ・テスト時とDBの内容が違うので再テストは難しい。DBはどう保存するのか？ ・DBを保存してるところもある。 ・画面に入力したデータはどう保存するか? 　現状は、入力テストケースを日本文で説明し出力結果のハードコピーを保存 ・画面,DB以外に、外部との通信をどう保存するかという問題もある。 [個別発表-高橋] 1. テスト仕様書はなぜ必要か? ・契約にあるので ・テスト手順の確認 ・テスト資料との関連付け ・ないとテストしなくなる(したかどうか確認できない) 2. テスト仕様書は、何に使うか? ・見ない→問題があったときは、見る ・保管→保証 3. テスト仕様書は、紙としてなければだめ? ・テストされたかどうかが、わかればよい ・設計書の仕様がインプリメントされたかどうか確認できればよい ・今は、紙でしかない ・本当にテストされたかどうかも、テスト資料を確認しないとわからないが 　細かくは、確認していない(テスト担当者まかせ) ・よって、紙という媒体で、保証書として捉えている 新しい項目が増え、ファイルが1260byteから1580byteに変更され、 複数画面に渡って項目が増えるメインテナンス案件について、 「システム変更設計書」と「テスト報告書」の例を提示。 この例で設計書とテスト報告書を１つにするとどうなるか検討。 →１つにできる。 [個別発表-高橋QA] 確認資料をどう保存するか？ 現在はファイルのダンプリスト それを保証書として使用できるか？ ペーパレス化した場合何を渡すか？ 媒体を渡して保証物とできる。 作成者承認者欄には名前を記入している。 [個別発表-仲本] 「2000年対応テスト手順書」、 「プログラム作成の手順と作業書」について説明 [個別発表-蜂須賀] --テスト仕様書に必要な項目-- 仕様書作成日、作成者、テスト内容、 テスト対象範囲(プログラム〜システム,業務)、テスト手順、 テスト対象へのＩＮＰＵＴ条件、 テスト対象からのＯＵＴＰＵＴ(結果予測を含む)、 ＯＵＴＰＵＴの検証方法、合否基準 --テスト成績書に必要な項目-- 実施日、実施者、テスト完了日、結果予測との相違点とその原因 障害事項／対処方法、処理時間、ＣＰＵ、 テスト実施時の環境(ホスト負荷状況) [個別発表-田中] 「単体テスト〜総合テストの品質基準値」 「単体テスト予実績表」,「単体テスト項目表」,「結合テスト1項目表」, 「テスト概要書」,「テスト・イント記述書」,「テストサイクル記述書」 「テストコンディション記述書」,「テスト報告書」について説明。 結合テスト１は、サブシステム内。結合テスト２は、サブシステム間。 品質基準値の項目数は、画面に表示される項目の数。 [個別発表-田中QA] テスト・イントとテストサイクルはリンクしているか？ →番号でリンクしている。 バグ予定類型のグラフが見事にＳ字カーブになっているが、わざとか？ →配員を作業期間の真中付近で増やしたら偶然こうなった。 普通に作業すると、こうなるのではないか？ 以下 山村吉信著「えー全部テストするんですか？」より紹介 三元社 ISBN4-88303-056-3 2200円 http://www.yarne.funabashi.chiba.jp/Users/NewBook-61.html http://zdseek.pub.softbank.co.jp/pcweek/news/books/990802.html できあがったソフトをどううまくメインテナンスしても駄目。 作るときから考えるべき。これはダイエット計画と同じである。 しかしソフト作成の外注化により作成時に考慮することが難しく なってきており、メインテナンス時のテストの重要性が増している。 ブラックボックステストだけでは不充分 ホワイトボックステストでテスト網羅率100%は作業負荷のかかりすぎ 間をとって、統計的手法によりテストを行なうべき。 [全員での会話] テスト仕様書の品質が大事。 テストケースのテストが必要。 わざとバグを入れて発見できるかどうかを試すのも１つの手。 ハードコピーとファイルダンプでテストしたことの証明になっている。 テスト検証者の承認に認証システムは必要ない。 テスト仕様書の再利用方法を、kamilanのバージョンアップという事で考える。 [合宿までの宿題1] ビデオレンタル店のシステムが存在し、新規開発時のドキュメントは 完全に保存されている。下記のメインテナンス事項について テスト仕様書の再利用方法を考える。 (1) 顧客情報に新たに年齢を追加 (2) 会員区分 1:一般 2:特別 であったものに、3:不良会員 を追加 (3) このシステムの2000年問題に対処 [合宿までの宿題2] テスト仕様書の形式(フォーム)を考える。 設計仕様書と兼用できるかも考察する。 (a) 修正点だけの仕様書の場合 (b) リグレッション(回帰)テスト用すべての仕様の場合 の両方の場合について考える [次回は合宿] 11月11日(木)　 13:35 集合：湖西線近江今津駅 　→　ホテル送迎バスで小浜市公民館へ移動 （京都駅12:45発　湖西線新快速と連絡） Ｎｏ．：0039　　（0014） 投稿日：2000年02月16日(水) 13時17分02秒 投稿者：松永 真 メール：makoto_matsunaga/ast＠ast.co.jp タイトル：議事録「2000.2.10」 本文： 日時　2000.2.10（木） 16:30 ・ 18:00 場所 全日空情報システムセンタービル７Ｆ会議室 出席者　岸田さん、馬場さん、長谷川さん、増井さん、松永（記） 欠席者　なし 議題 １．検討テーマ ・ディスカッションフォーラムの活性化 ・Ｙ２Ｋについて ・今後の進め方 ・次回のスケジュール ２．ディスカッションフォーラムの活性化 ホームページに掲載されているコメントを川柳ふくめ プリントアウトし回覧、今までの成果の確認と今後について 意見交換。 ・議事録について Ｃグループが議事録の掲載をしてくださいました。 馬場さんから、WebBoardの問題点「”」ダブルコーテーションが 利用できないとの報告あり。 Ｄグループから、感謝と激励のＭＡＩＬを出す（メンバー全員） 今後、ディスカッションを分離し、議事録だけまとめた方がよい のでは。 ・活性化 話題性あるテーマを投げかけ、グループ内から盛り上げていく。 岸田さんから「ＳＥＡＭＡＩＬ」冊子をいただく。意見交換の 場としてディスカッションの参考に利用できないか。 他のサイトに入って、投稿者を引き連れてくる方法がある。 他の場所でＳＭＳＧを話題にする。（他流試合方式） 参加しやすい生の意見を受付やすいテーマを検討する。 新しいシステム構築の手法、保守のありかた、未来のソフト ウエア等 ３．Ｙ２Ｋにつて（意見交換） ・大きな問題は発生しませんでした。固有のシステムで障害が でましたが事件となるには至らず。 ４．今後の進め方 ・報告書については、ディスカッションに記載されたものを提出 する形とする。 ・３月は各員多忙のため、次回は４月に実施。できれば合宿と する。予定地としては静岡。 ５．次回作業部会 ・４月ＸＸ日（不明）松永よりＭＡＩＬにて連絡。 補足） 今回、朝倉さまには大変ご無理を言いまして、申し訳なく思い ます。御忙しいこと、かねてうかがっていたのですが、 「本当に」忙しいことがよく分かりました。今後も御見捨てにな らず、よろしくお付き合いいただけますこと、心より念願申し 上げます。 Ｎｏ．：0040 投稿日：2000年02月28日(月) 17時40分21秒 投稿者：増井　和也 メール：masui＠ls.tas.co.jp タイトル：ソフトウェアの寿命について 本文： ソフト保守に関心を持つ皆様 最近，私はソフトウェア保守の経済性や必要性を考える上 で，ソフトウェアの寿命がどのくらいなのかまた気になっ てきました。 第２年次（92年度）のSMSG報告書に，日石情報システムの 鳥光氏が「ソフトウェアシステムの寿命と要因について」 という論文で，当時の調査の結果，ソフトウェアの平均寿 命は約10年あったという報告がありました。 ソフトウェア保守の経済性や必要性を考える場合，保守対 象ソフトウェアの寿命が後どの位あるのかが重要なファク タの一つになるのではないでしょうか。 そうするとソフトウェアの寿命を見積もるモデルが欲しく なりますよね。 そこで，このフォーラムで保守の経済性や必要性に感心の ある方々のご協力を得て，ソフトウェア寿命を決定する要 因をまず洗い出し，それぞれの重み付けを検討し，最後に ソフトウェア寿命算出モデルを構築できればと考えていま す。 どなたか，ソフトウェアの寿命を左右する要因の洗い出し にご協力いただけませんでしょうか？ 洗い出しですので，要因のレベルや影響の多少，影響範囲 の広狭はまったく問いません。 たとえば対象ソフトの「品質の良否」「標準化の度合い」， 「競合ソフトの出現」などがそのソフトの寿命に影響があ るのかも知れませんね。こんな感じで，思い付くものをで きるだけ多くあげて頂けるとありがたいです。 よろしくお願いします。 Ｎｏ．：0041 投稿日：2000年03月23日(木) 14時58分35秒 投稿者：宮田 メール：miyata＠sra.co.jp タイトル：Ｃグループ議事録1999.2.18 本文： SMSG Cグループ2月定例会議事録 日時：2000年2月18日 13:30〜16:00 場所： 出席者：田中(AST)、宮田(SCI)、高橋(TKCC)、植田(CCC)、小林(TAS)-->議事録 欠席 ：仲本(CCS)、倉岡(SRA)、蜂須賀(CCC)、 （敬称略） １．課題のKamilanの各機能の検討（類似項目別に検討） （１）業務マニュアル、テストデータ、画面遷移 　・紙芝居を仕立てる上で、業務フロー自体を業務マニュアルの機能確認と考えて、フロー 　　中の画面別にテストデータ、画面遷移へ検索出来る様にリンクさせる。 　　※ 会議中では、田中さんのVisio業務フローのハイパーリンクでイメージ確認 　・テストデータのエビデンス保存項目 　　・テストで入力した内容、テスト結果　−−＞　HCP等を業務フローとリンクさせる。 　　・テスト中に利用したマスタ、データはCSV形式で保存 　・画面遷移も業務フローとリンクを考える 　　・説明、注釈等を保持しテストケース等にリンクしてみる。 　　・その他、業務名称・プログラムIDなどからの検索を考える。 （２）進捗管理、テスト計画書／報告書 　・進捗管理を機能に取組むと、テストのみに留まらず案件またがりや集計を検討する事と 　　なる為、今回の機能では対象外とする。 　　但し、テスト報告にリンクして参照できる様に利用する。（EXCEL等で作成） 　・テスト計画書／報告書は、スケジュール（日程）基準ではなく、品質基準で考察する。 　　基本的には、案件ベースでの検索となる。 　　報告書としては、次回の参考になる様に、反省項目（失敗談 等）を登録する。 （３）テスト仕様／テストケース、テスト仕様の検索 　・テスト仕様／テストケースについては、案件単位or業務フローの呼び出しが、考えられるが、 　　業務フロー（処理画面単位）での呼び出しを検討する。 　　入力時には、案件単位で考える。 　　−＞フローを階層化する必要性あり（ﾋﾞｼﾞﾈｽ･ｼﾞｮﾌﾞ･ﾌﾟﾛｾｽ･ﾌﾟﾛｸﾞﾗﾑ･画面･帳票 等） 　　−−＞更に、フローと各テーマ(＝案件)をリンクさせる（各テーマ毎にフロー作成が必要） 　・テスト仕様の検索は、上記階層化した内容別に検索出来る様に考える。 　　世代管理は、日付別ではなく案件別に対処する。但し、追加時は、常にモディファイする。 （４）問題（バグ）管理 　・テスト報告と同様に次回参考を考え、テスト報告とのリンクを考える。 　　検索は、案件検索・業務フロー（画面）検索の両方で検討。 （５）その他 　・全てのドキュメントには、全文検索で対応出来る様 　　DATA項目名、画面名、帳票名、PRG名を表記して作成する。 　・リンク方法は、ｴｸｽﾌﾟﾛｰﾗの様に一覧を出して選択（ドラッグ）する。　階層別に 　・今回のテーマは、共通認識としてメインフレーム上の保守業務で４〜５日程度の保守作業を 　　１案件とする。 ２．今後の進め方 　・章立てと担当者の決定 　　テストの問題点（テストの現状)小林 　　解決策(kamilanの機能アップ)宮田 ドキュメントのリンク,構造,世代管理 　　操作の流れ 　　＜kamilanの機能＞　　　　　　　　　　　　　　　 ＜担当＞　 ・案件登録編　　　　　　：仲本 　 ・テスト計画書／テスト報告書　　　　　　　　　　　　　：仲本 　 ・テスト仕様／テストケース　　　　　　　　　　　　　　：倉岡 ------------------------------------------------------------ 　　・業務マニュアル（テストの為の業務フロー）　　　　　　：高橋 　 　・画面遷移（テストの為のオペレーションマニュアル）　　：植田 　 　・テストデータ　　　　　　　　　　　　　　　　　　　　：蜂須賀 ------------------------------------------------------------- 　 ・問題(バグ)管理　　　　　　　　　　　　　　　　　　　：倉岡 ・(再利用のための)検索編：仲本 　　・業務マニュアル（テストの為の業務フロー）　　　　　　：高橋 　 ・テスト仕様／テストケース　　　　　　　　　　　　　　：倉岡 　 ・テスト仕様の検索(世代管理+追加再帰テスト) 　　　　　：倉岡 　 　・画面遷移（テストの為のオペレーションマニュアル）　　：植田 　 　・テストデータ　　　　　　　　　　　　　　　　　　　　：蜂須賀 　 ・テスト計画書／テスト報告書　　　　　　　　　　　　　：仲本 　 ・問題(バグ)管理　　　　　　　　　　　　　　　　　　　：倉岡 　　効果：田中 　　終わりに田中 　　次回定例会３／１７---レビュー 　　合宿時に最終チェック４／？（田中さんより別途メールにて日程調整中） ３．次回定例会予定 　　SMSG Cグループ3月定例会 　　日時：2000年3月17日 13:30〜16:00 　　場所：CCC植田さんより別途連絡 Ｎｏ．：0042　　（0014） 投稿日：2000年05月08日(月) 10時25分31秒 投稿者：松永 真 メール：makoto_matsunaga/ast＠ast.co.jp タイトル：議事録「2000.4.25」 本文： 日時　2000.4.25（火） 16:10 − 18:00 場所 ＳＲＡ四谷事務所会議室 出席者　岸田さん、馬場さん、長谷川さん、増井さん、松永（記） 欠席者　なし 議題 １．検討テーマ 　・ホームページについて ・ディスカッションフォーラムの活性化 ・今後の進め方 ・次回のスケジュール １．ホームページについて 　・Ｙ２Ｋについての案内は、再考する必要がある。 　・ディスカッションの中に議事録が記録されているが、 　　今後は各グループに割り当て、自由に利用して頂く形にしたい。 　・ＳＭＳＧという名称についても再度考えてみる必要があるかも 知れない。(メインテナンスという言葉が、既に死語になている のではないか。今や、まったくの新規開発など考えにくい。 討論するのもよい） ２．ディスカッションフォーラムの活性化 ・今後の方向性の確認。以下のテーマが出ました。 　　プロセス改善（ＳＰＡ、ＣＭＭ、ISO/IEC TR 15504） 　　構成管理 　　保守の成熟度 　　標準化 　　アウトソーシング 　　討論する場の提供（賛成派と反対派に分かれて行なう： 保守の有料化等） 　　要員のローテーション 　　保守とは何か 　　ソフトウエアの変化に伴う保守のありかた ・プロセス改善については、別のグループの研究テーマに なっているが 　　Ｄグループでは、大きな手法ＳＰＡ、ＣＭＭ等の立場から 検討していく。 　　トップダウン方式での検討をすれば、他のグループが行な っている事例に基づくボトムアップ方式と競合することは ないだろう。相互に補完する 　　ものであれば望ましい。 ・今年のテーマは「ディスカッションフォーラムの活性化」 メンバー間でのディスカッション登録は実施してきたが、 　　広く参加者を巻き込むところまで至っていない。来年の課題。 ３．今後の進め方 ・今年度の報告書を合宿にてまとめる。素案（松永）。 ４．次回作業部会 ・５月１９日（金）１７：００東海道線由比駅そば、 「見晴らし旅館」集合。合宿とする。 ・電話：０５４３−７５−２５０３（松永で予約） Ｎｏ．：0043 投稿日：2002年03月01日(金) 20時15分00秒 投稿者：松永　真 メール：matsunaga_makoto＠itfrontier.co.jp タイトル：漁師と魚屋 本文： 漁師と魚屋は共に魚を扱うという点で似通っている。だから、漁師が魚屋をやってもおかしくは無い。 しかしこの二つの職業は、全く性質が異なっている。一方は、魚を上手に捕まえる技術が必要であり、 もう一方は安くて良い魚を仕入れ、上手に売ることが商売の秘訣となる。一方が必要としている能力は、 必ずしも他方の必要とすることではない。したがって、良い漁師が、そのまま良い魚屋になることは まれである。それどころか、一方の職業に必要とされる能力が勝っていればいるほど、他方にとっては 不利になる場合が多い。それは、自分が誇れる能力を発揮できないところから来る不満であるといえる。 漁師と魚屋の違いは誰にでもわかるが、ソフトウェア・ビジネスにおける開発ＳＥと保守ＳＥの違いは それほど明確ではない。どちらもソフトウェアを扱うという意味では同じである。共に、バグやトラブ ルと戦っている。われわれは、この違いを十分見抜くことができずにいる。しかしながら、ビジネスの 形態から見るならば、漁師が魚屋と違うほどに開発と保守には本質的な違いがある。ＳＥというものは、 開発であろうと保守であろうと何か有益なものを作ることによって、社会に自己の価値を反映させよう とする。それは、思い通りに動くプログラムであり、設計書通りの機能を提供することである。しかし 保守ＳＥは、しばしば自分が行うべき仕事と顧客が求めている要求に大きなギャップを発見する。] トラブルを修復することは、何かを作ることとは違うのである。自分に過失があるわけでもないのに、 彼は不利な立場に追い込まれる。このことは、十分大きな衝撃である。彼等は混乱し、自分の仕事が 正しく評価されないことに不満を持ち、その状況が継続して発生し続けることに不安と恐怖を覚える。 絶望的な、暗澹たる思いにかられ、願わくば一刻も早くこの場を逃れたいと渇仰する。「ぼくは、いつ までこんなことをしているのだろう？」まわりの人々が新しい技術の上に、思い思いのプログラムを 工夫して作っていくのを見ながら、他人のこさえたバグを果てしなく修復していくだけの、さえない 自分の姿を発見する。生きがいの喪失にもつながるこの思いは、無為に過ぎ行く時間と共にあせりと なり、重くのしかかってくる。 稼動を始めたシステムの裏には、このような思いをかかえている人たちがたくさん存在している。 コンピュータシステムが生まれてから、宿命のように付いてまわる保守要員の問題は、現在もなお 根本的な解決を見出していない。この根本的な問題はどこから来るのか？視点を変えるだけで、 回避できるものではない。残念ながら、誰もがこの根本問題の深さを測りかね、たじろいでふたを してしまうのが精一杯となる。 これについて、ひとつの仮定を設定しよう。保守は、サービスである。これはソフトウェアを製造 することで終着を迎える開発とは異なり、顧客が存在する限りなくなることないビジネスである。 われわれは、晴れた日にも雨の日にもシステムを通して顧客と接しなければならない。サービスの 本質は、対面する人間そのものによって決定づけられてしまうものである。ソフトウェア開発は漁師 に似ている。彼らは、新たな獲物を最新の武器で捕まえるのが好きだ。ソフトウェア保守は、魚屋に 似ている。彼らは、顧客と直接対面し、自分の可能な手助けをするのが好きだ。要は、漁師は漁師の 価値観、好み、目標があり、魚屋は魚屋としての喜び、達成感がある。ただ魚を扱うからといって 両者を一緒に考えてはならない。特性に応じた体制、また仕組みがなければならないのである。 個人の特性については、それを判別するために両者を体験させてみる必要があるかもしれない。 自ずから人間は万能ではないのだから。 開発の価値観は、安い、うまい、早い。生産性の向上と品質を保つといっていい。 保守の価値観は、顧客満足度の向上である。これは必ずしも、ソフトウェアの品質と一体である とは言い切れない。 開発の価値感を保守に適応してはいけない。保守の価値観を開発に当てはめてもだめである。 このことをよく踏まえて、プロジェクトの体制、教育を行うのであれば、不満とあつれきは少なく なるであろう。 Ｎｏ．：0044 投稿日：2002年03月07日(木) 18時29分17秒 投稿者：松永　真 メール：matsunaga_makoto＠itfrontier.co.jp タイトル：法則 本文： 混乱する社会。これによって不幸に陥る人々の姿を見て、 何とか解決の糸口はないかと思い悩むことに特別な能力は 必要はない。しかし、心配することと、これを解決に導く こととは、まったく別のことだと認識すべきである。 場合によると、何とかしようと積極的に関与しようとすれば するほど、事態を悪化させる事になる。「黙っていてくれ れば良かったのに。口を出したばっかりに問題は余計にこじ れてしまう。」こういう現実に出会うことは少なくない。 保守の問題は非常に微妙で、解決困難なものが潜んでいる。 なぜ困難な問題があるかというと、現実のビジネスの世界と 人間の頭の中の論理的な世界との大きなギャップを保守担当 者は埋めなければならないからである。これは、情報処理の 基本的なシステム構築手法を離れて、いきなり手段をえらば ず、結果を出さなければならないというところにある。基本 ができる前から、彼は応用を強いられる。さらに言うなら、 彼は人間を相手にしなければならないのに、知っているのは コンピュータシステムなのである。しかも誰かが忍び込ませ たバグが潜むプログラムの固まりである。ユーザーとシステ ム保守担当者がけんかをしてみたところで、勝負にはならない。 保守の仕事を楽にする方法は、ユーザーとシステムそのもの のギャップを埋めるものを持つことだ。ユーザーがシステム になるか、保守要員がユーザーにならない限り両者の溝は 埋まることはない。 ところで、このギャップを埋めることを新たな仕組みでとり 組む人々がいる。しかし、結果は芳しくない。これは出口の 見えない迷路のようだ。なぜ、だろう？努力を傾けても、こ れを嘲笑うかのように、努力を帳消しにしてしまう作用が働 く。これは、ひとつの法則に違いない。 その昔、アダムスミスは社会に大きな影響を与える理論を構築 した。彼にとっての関心事は「社会を構成するひとりひとりが まったく自由に行動したとしても、社会それ自体は秩序を保つ ことができるか」さらに「みずからの努力に応じて、個々人が 正当に報われる社会、つまり正義が守られる社会はどうしたら 実現できるのか」というものであった。そして、この世界に対 して政府はどのように関与すべきかというのが問いであった。 彼の結論は次のようなものだった。「政府は、市場に介入しな いこと。」当時の市民社会の哲学者たちの考えは、「神は世界 を創造したが、創造と同時に事象の背後に退いた」というもの だ。神と世界の関係が絶たれ、人間社会は神の命令ではなく、 社会独自の法則に従って運行するというのである。しかし、ア ダムスミスはこの法則として、ただ「神の手」を発見した。 ここにもう一つ、似通った皮肉屋の言葉がある。「自らにとっ て、都合の良い原理だけを取り出しても、歴史そして実在は、 その原理と相矛盾する原理を必然の帰結として求めていく」 −−難波田春男−−私は彼が皮肉屋かとうか実は知らない。 しかし、この法則の示すものは重い。必然の帰結としての矛盾 する原理に追いつかれる前に逃げる方法があるかも知れない。 でも、残念ながらわれわれの足はそれほど速くない。 Ｎｏ．：0045 投稿日：2002年03月08日(金) 11時06分56秒 投稿者：松永　真 メール：matsunaga_makoto＠itfrontier.co.jp タイトル：保守の戦略 本文： 保守の戦略というのは、おもしろい。場合によっては、人をドキッ とさせるほどの効果がある。なぜなら、保守には戦略などいらない。 開発した組織から、いやがおうでも押し付けられ、逃げようがない のが実は保守なのだから、今更戦略など立てる必要はない。戦略は なかなか取得できない優良なビジネスについてのみ考えるべきだ。 黙っていても、向こうからやってきて、招かざる客のように戸をた たき、引き受けてくれと言ってくるのに、戦略も何も無いではない か。 もしも保守の法則が正しく、それが「今の現状に対して改善の努力 をしても、その反作用によってすべてがぶちこわされる」というも のであるなら、その場合にも戦略はみあたらない。努力は無駄で せめて何もしない事が唯一の戦略だとうそぶくしかない。それでは、 あまりに悲しいことだ。 しかし、戦略はある。いかなる場合であれ、自分が相手より有利で あることを証明することは不可能ではない。もしも不可能であると すれば、それはまったくすべてにおいて自分の方に非がある場合だ けである。たとえ、そんな場合でも「こういう自分と付き合ってい る相手のミス」をなじれない訳ではない。とはいえ、優位性こそ、 ビジネスの生命である。それは、どんなに強調されても強調されす ぎることはないし、悪いことでも、嘘をつくことでもない。自己を アピールすることは、必要なことなのである。 積極的行為が、その意欲とは裏腹に事態を好転させないとしたら、 戦略とは何かということになる。自由競争が成り立つのなら、市場 に放り出してみるがいい。押し付けや、不公平から来る不満はきっ と解消されるだろう。このためにビジネスを取り逃がしても、どん な不利があるというのか、現場は喜んでいる。われわれは、もう充 分痛い目にあってきた、別の会社がこれを引き受けようというなら、 望むところさ。笑って、別のビジネスを追いかければよい。 もしも自由競争が成り立たないのであれば、つまり１対１ののっぴ きならない関係で、逃れようがないのなら。できるだけ契約の決着 を長引かせ、ビジネスボリュームを小さくするように工夫しよう。 そして、次のように言おう「こういう時は、このサービスは受けら れません」「こんな時は手当てできませんので、あきらめてくださ い」極力否定的なこと、この金額で”できること”ではなく、この 金額では”できないこと”を並べててよう。さまざまなリスクを大 袈裟に吹聴しよう、そして相手が青ざめるまで繰り返すことを辞め てはいけない。たとえ、契約金額を釣り上げても、あえてできない ことがあることを、勇気を持って語ろう。われわれは、できないこ とを請け負うべきではない。そして、世の中には、できることとは 別に実にたくさんの対処不能な事態があることを訴えよう。 保守は保険と同じだと言いながら、われわれは保険の外交員がいと も簡単にやってのけることを十分学んでいない。安い金額で、でき るはずのない相手の保証をしなければならない義務がどこにあるの だろう？相手に不安を売ることは、悪いことでも嘘をつくことでも ない。それは正当なビジネスである。その不安こそが売上になるこ とを保険業界は100年もまえから承知している。何も作ることが無い のにかくも巨大なビジネスとして繁栄しているではないか。 Ｎｏ．：0046 投稿日：2002年04月19日(金) 17時08分46秒 投稿者：岸田孝一 メール：k2＠sra.co.jp タイトル：MIZUHO Trouble 本文： みずほ銀行のシステム・トラブルが世の中を騒がせていますが， SMSG のみなさんは，これについてどのようにお考えでしょうか？ 企業合併にともなうシステムの統合は，メインテナンス問題の 一種なので，SMSG としても，この際 Web Page で一言発言し ておくべきかと思うのですが，..... Ｎｏ．：0047 投稿日：2002年04月19日(金) 17時12分23秒 投稿者：田中一夫 メール：tanaka＠jfits.co.jp タイトル：MIZUHO Toruble 本文： いくつかのMLで議論されてますが、メンテ研としてはY2K以来の テーマではないでしょうか？ 私は、証券会社しか知りませんが、システム統合のパターンは 大別して、３種類だそうです。 a.両社のシステムを存続し、連携システムを開発 b.一方のシステムに移行 c.まったく新しくシステムを作る 今回のMIZUHOは、a であった訳で、そうなるとメンテンス領域が 多くなり、大変そうです。逆に云うと岸田さんが云うようにメンテ研から 発言すべきではないでしょうか。 （UFJは、b のようですね） 証券会社の場合も、ほとんどが b ではないでしょうか？ と云うことで、b の経験は無いのですが、情報を見る限り、以下の 事が言えるのではないでしょうか 1.メンテ側から見ると無理な計画 　多分、現場は「できない」という発言があったと思うが、スケジュールを 遅らせる事ができなかった。 2.上記が正しいなら違う計画にすべき 　三井住友銀行は、三井系のATMは、そのまま残したのではないでしょうか 顧客にとって、ATMが統合される必要性は低く、支店に両方のATMがあっても 良いはず。。。現に、名古屋・伏見店(旧さくら）には、両方設置されている。 この様な観点での、システム統合によるRiskを減らす事はできなかったのか 3.移行日 　何も期末を選んで、システム統合する必要があったんだろうか？先行して 統合を実施したUFJは、３連休を選んだ。実は、証券会社での２次オン・３次 オン移行時は、３連休を狙った。 4.データのインターフェース 　今回の事件で再度、認識させられたのだが、企業と銀行間のデータは 各企業毎(業種）にインターフェースが違う。やはり、標準化ってのは 大切な事だと認識しました。今回の件で、各企業側も標準化に前向きに なって頂ければ幸いです。 とりあえず、ここまで。。。 Ｎｏ．：0048 投稿日：2002年04月19日(金) 17時14分33秒 投稿者：塩谷和範 メール：hioya＠sra.co.jp タイトル：MIZHUHO (Migaration Problem) 本文： To: smsg-all＠smsg.or.jp Subject: Migration problem (Re: How do you think about Mizuho Trouble?) > 個人的な推測ですが，「現場」ではおそらく「リスク」を実感して > いたでしょうね．ポイントは，それを「組織として」きちんと文書 > 化し，プロジェクト・マネージャが「高リスクの領域」について， > きちんとレビューし，適切な対策をとっていたかどうか？ たぶん、現場の技術者は危険を承知で、上の決断だから責任はない？ とか、もしかしたらうまくいくかも？？とか考えていたのかな? 制定中の、JIS-X0161「ソフトウェア保守」には、“移行”の際のタスク として、以下の重要事項を示しています。X-0160は、SLCPのJIS番号です。 例えば，移行計画を立てる際に、 8.5.2.2 移行計画 システムの移行を適切に制御するには，移行計画を作成し， 文書化し，それを実行する。計画立案には，利用者を参加させる。 計画には次の項目を含める。(JIS X 0160 5.5.5.2参照) 　a)　 移行のための要求分析及び要求定義 　b)　 移行のためのツールの開発 　c)　 ソフトウェア製品及びデータの変換 　d)　 移行の実施 　e)　 移行の検証 　f)　 移行後の旧環境の支援 　移行計画の策定は，利用者からの入力を含むことが望ましい。 このタスクの一部として，保守者は，次のタスクステップを実施することが望ましい。 　a)　 移行要求事項を分析する。 　b)　 ソフトウェア製品の移行の影響を決定する。 　c)　 移行実施のスケジュールを確立する。 　d)　 運用後レビューのためにデータ収集要求事項を明確にする。 　e)　 移行作業量を定義し，文書化する。 　f)　 リスクを決定し，軽減する。 　g)　 必要な移行ツールを明確にする。 　h)　 旧環境に必要な支援を明確にする。 　i)　 移行ツールを開発及び/又は取得する。 　j)　 変換のためにソフトウェア製品及びデータを細分化する。 　k)　 ソフトウェア製品及びデータの変換の優先順位を付ける。 　l)　 ソフトウェア製品及びデータを変換する。 　m)　 ソフトウェア製品及びデータを新しい環境に移行する。 　n)　 並行運用を行う。 　o)　 テストを通して移行検証を行う。 　p)　 旧環境に対して支援を提供する。 いろいろきちんとやらなかったことがあるのでしょうが、きっと a)の「移行要求事項」を小さくしたのはよいが、 b)の「移行の影響を(*過小*)評価」し， c)の「スケジュール」に至っては＊大甘の神頼み＊で、 f)の「リスク」についても＊大甘の神頼み＊で過少に見込んで＊軽減＊し、 m)の並行運用以降もおざなりにしてしまったのでしょうね。 Ｎｏ．：0049 投稿日：2002年04月19日(金) 17時16分44秒 投稿者：小嶋勉 メール：t-kajima＠sra.co.jp タイトル：NIZUHO Trouble 本文： > みずほ銀行のシステム・トラブルが世の中を騒がせていますが， > SMSG のみなさんは，これについてどのようにお考えでしょうか？ CMM的な見方でプロジェクトスタート時のプロセスを考えてみました． 3行を合弁するというビジネスレベルの活動（作業？）の下位に コンピュータシステムの統合という作業があるとすると， この「３行合弁」を一つの巨大プロジェクトと見て，その下に複数の サブプロジェクトがあり，その一つがシステム統合というソフトウェア プロジェクトであると考えてみました． #CMMではこういう巨大なプロジェクトに当てはめるほうがすっきり #対応しますね． で，このような巨大体制の中でソフト側が何をすべきか？という ヒントをTR25の「ソフトウェアプロジェクト計画」プロセスの活動１から 活動４あたりで述べています． （原文を適当な固有名詞に入れ替えてみました） 活動１：システム統合グループは3行合弁プロジェクトの提案 チームに参加する． 活動２：システム統合プロジェクト計画の策定は，3行合弁プロジェ 　　　　クト全体計画の早期段階から，かつ並行して開始する． 活動３：システム統合グループは，他の影響を受けるグループ 　　　　とともに，3行合弁プロジェクトの全期間にわたって3行合弁 　　　　プロジェクト全体計画に参加する． 　　　　（システム統合グループはプロジェクトレベルの計画を 　　　　レビューする） 活動４：上級管理層は，組織外の個人とグループに対してなされ 　　　　たシステム統合プロジェクトのコミットメントを文書化された手 　　　　順に従ってレビューする． それらの活動がきちんと行われていると ゴール３：影響を受けるグループおよび個人が，システム統合 　　　　グループに関連する各自のコミットメントに合意している． という状態になるとCMMでは言っています． （要するに活動１から４のところでソフト側の意見は言っておけって ことです） 現実はどうだったのでしょう？システム統合のプロジェクトマネージャ は上位の3行合弁プロジェクトに参加していたのか？ （たんに3行合弁プロジェクトの決定事項を通達されただけだったの ではないか？） 意見を言える状態（タイミング）にあったのか？ という疑問があります． つまり，システム統合プロジェクト側は「各自がコミットメントに合意し ておらず」，みんな疑心を抱いたままプロジェクトが進んでいったの ではないかと思います．（スケジュールやコストだけではなく政治的 な面も含めて） と考えると，こういう例はめずらしくなくて，最近はやりのe-Business がらみの小規模Web-baseシステムなんかもよくありますね． 先に納期（ビジネスのスタート日）が決まっていて，ソフト側の言い分は 全然通らないでプロジェクトがスタートします．無理なことは，顧客側 の責任者もわかっているけど，もっと上位のビジネスレベルでの決定 事項なのでどうにもできないという状態です． その結果，プロジェクトのメンバは休日返上で働くような事態になる． # なんかオムロンさんの士農工商・メカ・エレキ・ソフトと似ているかも このようなプロジェクトにCMM的なSQAレビューをした結果 以下のようなやりとりになりました... ^^; Q:メンバ全員が開発計画に関するコミットメントに合意できていますか？ A：メンバ全員がコミットメントに合意できるようなプロジェクトが世の中 　にあるのですか？ こんな現実は，上位のビジネスレベルで検討する管理層達がシステム やソフトウェアについての理解が足りないという面もあるとは思いますが， 岸田さんが書いているように，ソフトウェア側が「リスクを特定して明文 化」したり，「各種見積りを根拠とともに明文化」したりというようなこと を出来ないから，あるいはしてこなかったから，上級管理層を説得で きない．という現実もあるかもしれません． Ｎｏ．：0050　　（0048） 投稿日：2002年04月19日(金) 17時45分52秒 投稿者：馬場　辰男 メール：baba＠ccs.co.jp タイトル：Re:MIZHUHO (Migaration Problem) 本文： >　制定中の、JIS-X0161「ソフトウェア保守」には、“移行”の際のタスク >　として、以下の重要事項を示しています。X-0160は、SLCPのJIS番号です。 　塩谷さんは、JIS-X0161「ソフトウェア保守」のプロセスを例に問題箇所の 　推論をしておられましたが、今回の場合、ソフトウェア保守プロセスよりも、 　より上流のプロセスの方がよくなかったのではないでしょうか？つまり合併 　に伴う組織編成のプロセスに問題があったという見方が一般的に語られて 　いるように感じます。 　強いて、ソフトウェアプロセスで表現するならば、主ライフサイクルプロセス 　の5.1　取得プロセスの開始アクティビティに、そもそも問題が潜んでいたと 　でもこじつけましょうか？ 　X-0160　SLCPの主ライフサイクルプロセスの定義では、最初に、 　「１つの主プロセスの中のアクティビティ及びタスクは、そのプロセスを 　開始し、実行する組織が責任をもつ。この組織は、そのプロセスを存在させ、 　かつ機能させる。」とあります。 　そして、主ライフサイクルプロセスの先頭に取得プロセスを定義してあり、 　その開始アクティビティの中に、取得者が実行することが望ましい取得計画 　として、以下の6項目を挙げています。 　 　(a) システム要求事項　 　(b) システム利用計画 　(c) 契約形態 　(d) 関係する組織の責任分担 　(e) 支援方法 　(f) 考え得る危険度及び危機管理手法 　この取得計画タスクに問題があったのではないかという推論です。特に 　(d) と(f)がうまくいっていないために、組織的に以後のプロセス（この 　場合、開発プロセスか保守プロセスかは判断できませんが）を存在させ、 　かつ機能させることができなかったとは考えられませんか？ >　CMM的な見方でプロジェクトスタート時のプロセスを考えてみました． 　小嶋さんのシステム統合プロジェクト側は「各自がコミットメントに合意し 　ておらず」，みんな疑心を抱いたままプロジェクトが進んでいったの 　ではないかという推論も、十分ありえる話だと思われます。 　 　参院財政金融委員会に参考人として出席した前田社長が、「３月２２日の 　経営会議の段階では完ぺきにテストも終わり、問題なかったので移行する 　と判断した。（テストが）うまくいかなければ移行しなかった」などと、 　釈明したそうですが、経営とシステム統合プロジェクト側とが乖離して 　いる様子をうかがわせる発言です。システム統合プロジェクト側の発言が 　聞き取れない、あるいは、提示された書類を読むことができないという程に、 　経営陣の視聴覚が病んでいたのかもしれません。　 　どこかの掲示板に、「検査の結果みずほさんは合併症を引き起こしている 　疑いがあります。とりあえずご入院をお勧めします。末期症状には至りま 　せんが屈強なナースを介添え役にお願いいたしました。」という皮肉な 　投稿があったことを思い出しました。 　 この投稿に対するコメントはありません。 Ｎｏ．：0051　　（0046） 投稿日：2002年04月20日(土) 09時12分42秒 投稿者：増井　和也 メール：masui.kazuya＠toshiba-it.co.jp タイトル：Re:MIZUHO Trouble 本文：>みずほ銀行のシステム・トラブルが世の中を騒がせていますが， >SMSG のみなさんは，これについてどのようにお考えでしょうか？ >企業合併にともなうシステムの統合は，メインテナンス問題の >一種なので，SMSG としても，この際 Web Page で一言発言し >ておくべきかと思うのですが，..... 増井です。 「メインテナンス」は長いので「保守」で代用します。 今回の障害について明確なコメントや問題提起をするには， 私的には，まだ情報がかなり不足していると考えています。 ただ，MIZUHOのシステム統合に伴う作業は，少なくともソフト ウェアの新規開発ではなく，ＳＭＳＧやISO14764がいう広い 意味のソフトウェア保守だとの岸田さんのご指摘に全面的に 賛同します。 （次のコメントに続く） Ｎｏ．：0052　　（0051） 投稿日：2002年04月20日(土) 09時30分26秒 投稿者：増井　和也 メール：masui.kazuya＠toshiba-it.co.jp タイトル：Re:MIZUHO Trouble 本文： （コメント続き） 増井です。 今回の件は，ソフトウェア保守のタイプで言うと，大規模な適応 保守だといえます。 ３行統合という環境の変化に対し，既存システムのソフトウェア を適応させようとした保守物件です。 適応保守といえども，場合によりソフトを新規に作る部分も 出てきます。今回で言えば，３行をつなぐリレー（相互接続）コン ピュータのソフトは新規に作成したのではないかと思います。 相互接続コンピュータのソフト開発量は，単なる変換中心で 大量の人員を投入すれば短い期間に十分開発でき，問題ないとの 認識があったとすれば，私は今回のようなことが起きても全然 不思議ではないと考えます。 4/20付け読売朝刊の検証記事には「2000年末頃に，片寄せ方式 から相互接続方式に方針を変更があった」と出ていました。 後１年少ししかない状況で大きな方針変換をしたのも，相互接続 方式なら開発量が少ないので，間に合うと判断したのかも知れま せん。 もし，そうなら保守本質を知らなかったことが障害発生の大きな 要因といえます。 （次のコメントに続く） Ｎｏ．：0053　　（0051） 投稿日：2002年04月20日(土) 09時53分24秒 投稿者：増井　和也 メール：masui.kazuya＠toshiba-it.co.jp タイトル：Re:Re:MIZUHO Trouble 本文： （コメント続き） 増井です。 保守全体の作業量は，新規開発とは異なり，既存システム （ハード，ソフト，データ等）の規模，複雑さ，不統一さ， ISO9126で代表されるような品質（機能，信頼，効率，使用，保守， 移植の品質）レベルなどに大きく影響をうけ，ソフトの修正量や 追加作成量とは相関関係が薄いのです。 新規開発の場合は，開始から完了までの工数投入のトレンドは ヒトコブラクダの背中のイメージです。 しかし，巨大，複雑，不統一レベルが高い既存システムへの 保守作業に対する投入する工数は，フタコブラクダの背中のように ソフトの修正や追加作成の工数よりも上流と試験の工数が大きく なることも決して珍しくありません。 今回，３行の既存システムの調査分析と要件定義（上流工程）， ３行や顧客のあらゆるデータ形式や負荷状態での試験（最終工程）， そして移行に，莫大な工期と工数が掛かかると見積もる必要が あったはずです。 統合１年少し前に方針転換し，相互接続方式ソフト作成の開始を 決定したとき，どれだけの調査，要件定義，試験，移行の 期間で済むと考えていたのでしょうか。 このあたり，今回の大きなポイントの一つだと推測します。 （ここまで）