品質保証に関する提言（終り：変化する要求）

最後になりますが、

システムは、「契約時の曖昧性」、「その後の変動性」、「その結果としての膨張性」という三大特性がある。

そして、厳しいシステムの損益は、見積り／契約条件（即ち契約内容）で５－８割が決まり、プロジェクトが開始してシステム仕様が固まるまでに８－９割、システム開発で残りの１－２割が決まるとまで言われている。

「始めが肝心」であり、見積り／契約の重要性はいくら強調してもしすぎることはない。

このようなシステムに対して、要求が、開発に着手する前にどれだけ合意に達するかは、プロジェクトを成功に導く大きなポイントである。

通常は、８０～９０％が合意点に達していることが目標である。

それでも、要求は変わる。

要求の内容を正確に把握するのが難しいだけでなく、要求そのものが変化しやすいものであることから、長期の開発プロジェクトを成功させることが難しくなるわけである。

プロジェクトの期間は長くても１年である。

このため２年という期間が設定されたプロジェクトは、最初から成功させる意図が存在しないものということもできる。

成功の目算はあるのかと言われると、明確に答えることは出来ない。

実際には、要求は変化させないとか、リスクが存在しないとか、非現実的な制限を付けないと、成立しない計画になる。

このような状況に対して、
「ウオーターフォールモデル」、
非ウォーターフォール・モデル（「スパイラルモデル」や「プロトタイピング」）、
繰り返し型開発モデル（「インクリメンタル開発」や「イテレーティブ開発」）、
「アジャイルソフトウエア開発」、
オープンソースにおける開発方法「伽藍（がらん）方式」や「バザール方式」等、
といった開発方法やモデルが提案されております。

最後になりますが提言としては、
第一に、第三者に品質保証作業を委託する仕組みを作る必要がある。
第二に、品質の質の向上という点で、プロセスの改善が必要である。
第三として、詳細な作業の工数見積りは困難を喫すが計画を立て挑戦し開発にあった手法やモデルを適用する必要がある。


終わり。

万年かめ

真福寺岡崎の万年かめです。

「鶴は千年、亀万年」この言葉の起源は、紀元前120年位に書かれた中国の書物『淮南子（えなんじ）』に出てくる言葉。

大晦日に晦日蕎麦を食べるのは、「鶴は千年、亀万年」から来ているとか。

「ツルツル、カメカメ」といいながら食べるのは、この長寿と繁栄のための縁起ものから来ているそうです。

鶴の寿命は推定約９０年。ゾウガメは約１８０年。

菊花石

菊花石（きくかせき、chrysanthemum stone）は鑑賞石の一種で、中にキクの模様がある石である。その美しさから、鑑賞石の最高峰とも言われている。

写真は、岡崎市真福寺にて。

 

品質保証に関する提言（その４：工数見積もりの意義について）

ソフトウェア開発における最大の問題の一つは、詳細な作業の工数が見積もれないことである。
現実には、事前調査に３週間、外部設計に５週間、詳細設計に１０週間、コーディングに2週間、テストに５週間などという形で予定が立てられる。
実際に「設計作業」と言っても、操作画面の構成を検討し、ファイルのレイアウト、メッセージのフォーマットなどを仕様の形にまとめる作業も入っているし、タスク分割、あるいは分割の根拠となる資料を作成する作業や、タスクの構造図を書くという作業もある。このような作業の中には、３０分や１時間で終わるものもある。
一方、「コーディング作業」でいえば、コンパイルオプションを決める作業や“コーディングベカラズ集”のようなものを作る作業も必要である。
チームのメンバーによっては、コーディングやテストの仕方、ツールの操作方法などに関してトレーニングを受ける必要もある。
こういった具体的な作業が必要であるにも拘らず、実際には大雑把に「設計に何ヵ月」という形でしか把握されていない。
こうなる理由は、このことについて考え続けていないからであり、考え続ける時間が確保できていないからである。

『プロジェクトが予定より１年も遅れるのはなぜなのか。それは１日の遅れが積み重なるからである。』
これは「ソフトウェア開発の神話」（「人月の神話」）の著者である、フレッド・ブルックスの言葉。

現実の混乱は、まさに、この言葉に集約されていると言える。現実は「１日の遅れ」を見ることはできない。
一体、今日は何を仕上げることになっていたのか、あるいは今週は何と何が終わっていなければならなかったのか、が見えない。
当人も、“何となく遅れているな．．．”というのは「感じ」られても、具体的に何が遅れているのか分からない。

「１日の遅れ」を認識するためには、どうしても「１日の予定」が必要なのである。

以下に、このように工数が読めない、あるいは工数が見積もれないことから、どのような問題が起きるかということについて考えて見る。

■今の作業がいつ終わるか分からない
その主な理由は、計画時に予想されていない作業が「その場になって」発生するのと、作業そのものは想定されていても、見積もった時間より多く掛かってしまうことである。
計画時に予想されていない作業が湧きだしてくるのは、作業を具体的にブレークダウンしていないから当然である。
また、一般にこの種のスケジュールが立てられるときには、ある程度の危険率が掛けられる。
危険率を掛けるのは、その時点で計画の甘さを感じているからであり、何かが湧き出してくることを予感している。
多くはスケジュールの中盤から後半にかけて、作業が行き詰まる形で出てくるため、結局、“危険率が必要であった”の神話が成立することになる。
実際の作業に入ったら、当初の予定を延ばす要因が次々と涌き出す。
しかもそれらの「遅れ」は、ほとんどが“自分の所業”ではない。
従って、この「遅れ」を回復するための動機は存在せず、遅れを主張することになる。
『予定外の作業が入ったのだから仕方ない』と。

見積もれない理由の多くは、それは前回のプロジェクト（今、遅れながら進行中のプロジェクト）の計画段階で詳細な工数を見積もらなかったことによって作業が遅れ、次のプロジェクトの開始時期に重なったことによって、次回も細かく見積もるための時間が確保できないまま、結局前回と同じ状態に突入する。
そしてこの問題は“マルチジョブ”が出来ないかぎり解決しない可能性がある。

■目前の業務以外のことに時間を割けない
実は先の問題よりもはるかに影響は大きく、広範囲に及ぶものであり、原因と結果が錯覚されている部分でもあるだけに、質の悪いものでもある。
たとえば心理面で、関係者はプロジェクトの進捗状況を隠そうとする意識が働く。
具体的な作業や、その工数、成果物などを明らかにしていないため、“今、やっている作業”に自信がないことなどが作用しているものと思われる。
工数が見えていないため、当然、自分にとって“余計”な作業を、ことごとく排除しようとする。
その結果、自分のスキルアップのために１日１時間も「勉強」に当てることができない。
他の人が書いた数枚の文書に“目を通す”ような作業も、当人にとっては『雑用』に見えてしまう。
或いはメールを読むことも『雑用』になるかもしれない。
組織において作業の見直しに取り懸かると、必ず、この種の「雑用」が槍玉に上げられる。
したがって、“優先順位を考えて作業をしよう”というスローガンも、彼にとって優先順位の高い作業は、コンカレント性にあるのではなく、自分の分担する作業にあるから、組織として何も変わることはない。

■仕様書ウォークスルーのドキュメントを、事前に読む事も出来ない
ウォークスルーの直前に１０分ぐらいでお茶を濁す程度にページをめくって、その場をやり過ごせた経験があるでしょう。
同じ理由で、メンバー相互のコード・ウォークスルーも出来ない。
それが、ソフトウェアの品質を確保する効果的な方法であることを理解していても、とても時間的に関わることは出来ない。
当然、今回の変更要求の仕様を「事前」に検討する時間もない。
実際にプロジェクトがスタートする前に、リーダークラスの人が事前に検討を終えていなければ、プロジェクトがスタートした後で、チーム内でコンカレントに作業が出来なくなる。
よく、メンバーの若手が、プロジェクトの初期の段階に、やることがなくてぶらぶらしている風景を目にすることがあるが、その殆どは、このような状況に陥っているものと予想される。
逆に、十分に検討しないまま仕事を分割して、各担当に割り振ってしまうのも、そうしなければ、メンバーが遊んでしまう、という理由も存在している。
当然、その結果として、具体的な設計に入ってから問題点が各所で表面化することになるし、もちろん、プロジェクトの後半に、彼らは地獄を味わうことになる．

■プロジェクトの進捗に対して、さらに効果的な進め方を検討することが出来ない
具体的な作業が明らかになっていないために、チーム内での作業の交換ができない。
一人でやる仕事なら、作業の順序はそれ程大きな意味を持たないが、チームで行うときには、比較的小さな単位で具体的な作業アイテムが明らかになっていて、その順序を制御することで、メンバー間の作業の待ち状態を避けることが出来る。
また幾つかの作業を事前に肩代わりしてあげることも出来る。
少々のトラブルがあっても、それが早い段階であればチームのメンバーがカバーして、遅れを表面化しないで済ませることも出来る。

作業展開は３日を限度に、工数を読む、ということは、作業の進捗を管理するために欠かすことができない。
「設計作業に１０週間」などと大雑把にしか把握していない以上、今日現在で作業が遅れているのかどうかを判断することは出来ない。

１日で終わる作業や数日で終わる作業などを中心に、長くても３日を限度として詳細な作業アイテムを把握することで、「予定より遅れたのか、予定より早く終わったのか」が見える。
作業が遅れたことが判明したとしても、残り１週間の時点ではなく、今はまだ設計作業に入って１週間目。
３週間のコーディング作業も、３週間かけて１つのモジュールをコーディングするようなことはない。

このようにして遅れを発見し、その原因を検討することで、この後、作業の把握状態の善し悪しを再検討してもよいし、遅れの原因が、単に担当者が風邪を引いて休んでしまったことにあるのなら、その後の作業をチームで吸収する方法を考えてもよい。

【チームが効果を増幅させる】
たとえば、５人それぞれの人に一つの仕事を割り当てるのと、５人で構成される１つのチームに５つの仕事を割り当てるのとでは全く違う。というより、違えることが出来る。
作業を細かく、且つ具体的に把握し、詳細に工数を読むことによって、チームとしての工数の合計を大幅に減らすことも可能になる。
勿論、プロジェクトの種類が、ある程度類似している事が条件となるが。
そして、このようなチームには、メンバー間の技術交流やスキルの向上という「おまけ」もついてくる。

逆に、工数を読まなかったチームでは、数年経ってもメンバーのスキルが変わらないということもしばしば見られる。

このようなことから、“工数を読む”ということを脇に追いやったままでは、その組織が抱える多くの問題を、何一つ改善することも叶わない。

明らかに、改善しなければならない項目がいくつか提起され、それに取り懸かっても、結局は「時間がとれない」という“事実”の前に、すごすごと『改善の旗印』を降ろさざるを得ないことになる。

このようなことからも、詳細な計画を立てることは、プロセスのレベルを改善するための第一歩である。　

愛知蒲郡市・竹島

蒲郡市の三河湾に浮かぶ小島で三河湾国定公園の中核。

下の写真は、ホテル竹島の３階から朝の８時頃に撮ったものです。（2013年2月16日撮影）

島を中心にアップしてみました。

島は、標高22m、周囲約680m、面積約1.9ha。基盤は花崗岩質。対岸とは約400m離れており、竹島橋によって、結ばれている。