「Good Enough」が市場に受け入れられるためには、少なくとも「Statistical Testing」や「ＣＭＭ」が必要であったと思っています。一般に、このような手法やフレームワーク（ＣＭＭは作業のフレームワークを提供するもの）は、市場の新たな要請を察知して現れてくるものです。そしてその後は相互に影響しあって、市場の要請もそれによって次なる要求に向かって膨らみますし、これらの技法やフレームワークも、それを受けてレベルアップし拡張されます。もちろん、この過程で、あたらな方法が提案されることもあるわけです。
私は、「Testing」については専門ではないので、ここでは先ず「ＣＭＭ」を中心に「Good
Enough」の関係について説明し、その後で、そのほかの幾つかの必要条件について説明します。
「Good Enough」が“凡庸なソフトウェアを作るための言い訳（文献３）”に使われないためには、それが事前に計画されたものでなければなりません。最初に製品に対する要求が示され、それを分析する過程で、先の３つの要素がバランスしないことが明らかに出来なければなりません。つまり、実際に開発に着手する前の段階で、このまま全ての要求を実現しようとすれば、開発期間がオーバーし、発売時期を逸してしまう危険があることが分からなければなりません。それが出来ない組織は「Good Enough」に取り組む資格はないのです。もちろん、開発能力が劣った組織では話にならないことは云うまでもありません。
「ＣＭＭ」と適切な分析・設計手法を組み合わせ、さらに「２０１の鉄則」で紹介されている「ノウハウ」を組み合わせることで、「Good Enough」に取り組む環境を手に入れることが出来ると考えています。
「Good Enough」は事前に計画されるべきであるという制限を弛めてしまうと、最後になって納期が間に合わなくなった時の「逃げ道」として使われてしまうことは、火を見るより明らかです。それでは、市場や顧客は納得しないでしょうし、もし、我が国のソフトウェア開発組織が、そのような安易な選択をしようものなら、取り返しのつかないことになってしまうでしょう。
（インデックスに戻るときはウィンドウをクローズしてください）
まず、要求を正確に把握しなければなりません。そのためにも、「分かる」の根本問題を理解していなければなりません。そのうえで、
ＣＭＭの取り組み＃１の「要求管理」と、
「２０１の鉄則」＃５２、＃５３、＃５０
をミックスして顧客の要求を正しく把握することです。もちろん、正しく把握できたかどうかは、顧客が判断することであって、設計者自身で判断することは出来ません。したがって、ここで顧客との間で「共通の認識」に達するための適切な行為が必要になります。
原理＃５２の「要求に識別番号を付ける」という方法を実現するためには、要求を個条書きにし、適切なカテゴリに分類しなければなりません。そうして顧客の要求を一旦設計者の言葉に置換えるのですが、それでも、この個条書きによる表現は顧客のイメージで十分認識できる表現であり、実際に、顧客との間で要求の確認をするのに、全く支障はありません。構造化分析の「イベント分析」や、オブジェクト指向の「ユースケース」による分析図も、この段階で効果を発揮するものと思われますが、顧客において、そのまま認識できるかどうか、問題が残るものと思われます。
一旦、個条書きになって要求番号が割り当てられるようになると、原理＃５３の「曖昧な表現をなくす」とか、原理＃５０の「要求に優先順位を付ける」ということも、比較的簡単にできるようになります。この「要求に優先順位をつける」というのは、「Good Enough」にとって有効に働きます。
ＣＭＭの「要求管理」の出番は、一旦決められた要求に対して、途中での変更要求を制御する考え方や仕組みを提供することにあります。これによって、勝手な要求の変更は防がれ、しかも、手続きとして変更のためのレビューなどが求められることで、その影響範囲の検討が強制されたり、設計工程まで進めてしまっているところでの要求の変更も追跡して修正できるように最初から想定してあります。
これだけの考え方やノウハウを身に付けていることでが、「Good Enough」に近づく最低の条件ということになります。
（インデックスに戻るときはウィンドウをクローズしてください）
次に、見積もり能力が求められます。開発者に求められた要求の内容を正しく把握し、それを実現するために「スケジュール」の形に変換することになりますが、その前に、「サイズ」の見積もりが出来ていなければなりません。このとき、「ファンクション・ポイント法」などの見積もり手法を使用することできますが、実際には、それだけでは「スケジュール」にはなりません。そこで得られるものは、全体のファンクション数に応じた作業量（総量）であり、コストに相当する値であって、「スケジュール」ではありません。スケジュールにするには、これを適切に分担し、連続した「作業」の形につなぐ必要があります。段取りの組み方によって、作業量は同じでも、スケジュールは変わってきます。
要求を最短距離で実現する段取りを考え、最終的な成果物の他に、段取りに沿って展開される途中の作業のアウトプットとしての成果物の「サイズ」の見積もりを間違えれば、「時間」への変換は根拠の無いものになってしまいます。
ソースプログラムの行数やドキュメントのページ数を、出来るだけ正確に見積もる訓練ができていなければなりません。ページ数を見積もるためには、そのドキュメントに書かれる内容や、その構成もイメージしていなければなりませんし、そのなかで、簡単に書ける項目もあれば、ちょっと骨の折れる項目もあるでしょう。それらをイメージすることです。
ソースプログラムの行数を見積もるためには、モジュール（あるいはクラス）の数なども、見積もらなくてはなりません。そのためにも、これまでに作られた類似のドキュメントやソースプログラムがあれば、そのサイズは参考になるでしょうが、必ずしも、これらについて精度の高い見積もりを、計画段階で手に入れることは出来ないかもしれません。それでも、できるだけ正確に見積もり、その中で曖昧な部分を含んでいる個所については、リスク管理の手法などを組みあわせて、このあとの作業の中で、それらを出来るだけ早い段階に明らかにする為の作業を組み立てることになります。
実現性の高いスケジュールが書けない理由は、殆どの場合、サイズ見積もりが出来ていないことにあります。そして本当はそのことに「当人」が一番良く気付いているのです。とてもこの作業が３日で出来るとは思っていないのに、スケジュール表には「３日」と記入しているのです。もっとも、その場合、当人も原因が、
・見積もりの前提としての要求の正確な把握が出来ていない。
・成果物のサイズが見積もれていない。
の、どっちが原因か分かっていないかもしれません。
もちろん、前者の要求の正確な把握が出来ていなければ、サイズの見積もりが出来ないのは当然です。
精度の高い見積もり能力は、「Good Enough」を安易な逃げ道に使われないためにも、是非確保して欲しい能力なのです。
（インデックスに戻るときはウィンドウをクローズしてください）
見積もられた成果物の「サイズ」と、それぞれの作業に対する担当者の「生産性」から、ようやく時間軸に編集し直した「スケジュール」を作ることができます。このとき求められるのは、最終成果物に至る最短コースを見つけだす能力です。もちろん、このときの作業は通常は一人ではなく、チームで担当しますので、ここで分担を考える必要があります。
そうなると、個人のスキルに関する情報が欠かせません。その人の設計能力やインプリメントの能力、あるいは、業務知識の程度も、それぞれの作業の生産性に影響を与えます。
それらを考慮して、最短のコースを考える方法として、最終成果物から作業をさかのぼる方法があります。この方法に付いては、別に詳しく説明する機会を設けますが、何れにしろここで、約束を実現する為の「詳細スケジュール」を作ることになります。
もちろん、表面的にはマイルストーンを中心としたスケジュールでも足りるのですが、そのマイルストーンを実現できるという「裏付け」があることが前提となります。
「詳細スケジュール」を作ることは、“自分を偽らないこと”に外ならないのです。多くの人は、マイルストーンに示された期日に出来上がるという裏付けが無いにも関わらず、スケジュールを“提出”しています。そして、そのことを“当人は知っている”のです。出来る保証が無いことを知っていて、「約束」しなければなりません。このような事を長く続けていると、物事の本当の姿を見る力を無くしてしまいますし、それ以上に自分を誤魔化さなくてはなりません。そしてそのような姿勢は、云うまでもなく「Good Enough」にはつながらないのです。
もちろん、この「作業」には、テスト工程はもちろん、テスト仕様書を書く作業も含まれています。その際に、先の「２０１の鉄則」の原理５０に従って用意した要求の優先順位なども参考になるでしょう。
（インデックスに戻るときはウィンドウをクローズしてください）
ある程度精度の高いスケジュールが立てられるようになったとしても、スケジュールを崩す要因の発生によって、実際には最初に考えた通りには進むことは殆どありません。開発組織内部の予定外の出来事もあるでしょうし、市場の中でも予測しなかったことが発生します。製品の開発期間が数ヶ月のものなら、それほど大きな問題が発生する余地は少ないでしょうが、１年という時間の中では、競争相手の動きも変わってくるでしょう。その方面の監視は続けていたとしても、新たな競争相手の参入までは予期しにくいものです。
また、性能や機能面の要求自体も途中で変更されることもあります。もちろん、その危険性を可能な限り減らすために、最初の段階で「２０１の鉄則」なども応用して、要求のすり合わせを行ったわけですが、その結果、安易な要求の変更はないとしても、製品の存在意義を高めるような新技術が現れたりしたときは、要求の変更は避けられないでしょう。
そして、要求の変更に応じて、既に着手した中で影響する部分を割り出したりして、新たに作業の計画を立て直さなければなりません。たとえ最初のスケジュールは上手く立てることが出来たとしても、殆どの開発組織は、途中の変更で崩れてしまいます。新たな要求を組み入れ、それにしたがって「サイズ」見積もりをやり直し、スケジュールを見直す必要があります。その上で、「約束」の実現性や実現方法について再検討し、選択の判断が為されなければなりません。その結果、必要なら、一旦決めた作業の標準や手順を、許される範囲でダイナミックに調整する必要があります。「Good Enough」を目指すには、この調整能力が必要です。
これは決して作業の質を低下させるものではなく、「目標に至る方法（道）は一つではない」という考えに基づくものです。とは言っても、最初から何通りもの方法（道）を考えて、その中から一つを選ぶということは、なかなか出来るものではありません。しかしながら、要求の変更や事態の変化によって、当初の方法では実現が困難であることが判明したとき、人は、別の方法を考えだすことは出来るものです。もちろん、これは誰にでも直にできるというものではないかもしれませんが、「詳細スケジューリング」などを通じて日頃のトレーニングによって、それが可能となります。
これは「戦術」の変更として認識することが出来ます。「約束」を実現するための基本的な「戦略」は変えないとしても、具体的な「戦術」は、状況に応じて変更することが求められます。特に、半年とか１年という期間の中で開発作業を行っているわけですから、当初の戦術を頑なに守るというのでは、プロジェクトに失敗する危険の方が高くなるでしょう。
もし、このような能力に欠けている状態で、要求の追加や事態の変化に遭遇したとき、スケジュールの立て直しは困難でしょう。その結果、安易にトレード・オフを選ぶか、納期を延ばすかという「二者択一」を顧客に迫ることになるでしょう。その結果、「Good Enough」が、開発者が凡庸なソフトを作成するための「蓑」として使われる危険が高くなります。
ちなみに、この種の「二者択一」を迫るソフトウェア・エンジニアを、私は信用しないことにしています。それはまさに、自らの「無能」を宣言しているようなものだからです。エンジニアの価値は、この「二者」をどうやって実現するかというところにあるのですから。たとえ、両方を完全に満たせなくても、「満足点」というものがあるはずです。それを求める姿勢こそが、「Good
Enough」の精神に繋がるものと考えています。
（インデックスに戻るときはウィンドウをクローズしてください）
こうした高い適応能力を活かすためにも、スケジュールの追跡がうまく出来ていなければなりません。いくら有事に対する適応能力が優れているといっても、事態の判断が遅れてしまっては、その能力も活かすことは出来ないでしょう。作業の進捗状況の認識が遅れ、気付いたときにはどうしようもない、という状態に陥った開発組織をしばしば目にします。要するに「選択肢」がない状態です。
プロセスのコンサルタントにとっても、この「時間がない」という状態においては、どうしようもないもので、もっとも忌々しい状態なのです。こうなる前に声を掛けてくれなければ、何も出来ないのですが。
私の提案する「詳細スケジュール」のような、日常の作業の状況を追跡し監視するのに適切なスケジュールが用意されていれば、「一日の作業の遅れが、その日に判明」します。そのとき、それが一時的なもので、明日には取り戻せるものか、作業の読み違いに基づくもので、今の工程の中では取り戻せないものなのか、といったことを判断し、適切な行動を執ることになりますが、そのためにも、スケジュールを追跡する優れた能力と、それを発揮させる作業上のインフラが必要になります。
今までのように、週に１回の「進捗会議」では、事態の判明が週単位になってしまいます。今まではそれでも足りたのでしょうが、組織内のネットワーク環境が発達し、「Web」環境が使い易くなった今日では、チームのメンバーの進捗状況は、「詳細スケジューリング」と組みあわせることで１日単位で把握することが出来ます。そして「問題」を感じたときには、担当者にその説明を求めればいいのです。もちろん、毎日説明を求めるような「愚行」はしないでしょう。
今日、開発組織によっては既に十分な「Web」の環境が整っていると思われます。しかしながら、そのような組織にあっても、未だに、週に１回の進捗会議を続けている理由は何処にあるのでしょう。それを“支えている”のは、単に「今までやってきたから」というだけだとすれば、そのような組織にとって、「Good Enough」はとても遠い目標となることでしょう。
こうした、タイムリー性の高いプロジェクトのマネージメントが、製品を予定通りに出せる背景に繋がるのです。そしてそれは、「Good Enough」の実現にとって、重要なポイントとなるのです。
（インデックスに戻るときはウィンドウをクローズしてください）