マインドマップでスタートダッシュ

要求仕様化を行う際にとっかかりがつかめず何も進められないことがよくあります。書いていることが要求なのか、理由なのかもわからないし、そもそも要求を現時点で書いて良いのかもわからないし、書き始めた要求、理由、仕様は範囲がかぶったり、ピンと外れのような気がするし、設計してしまっていることに気づいたりもするし、懸案が次から次へと出てきてそれが決まらないとその先の作業を進めても無駄なような気がしたりするしと、一向に先に進まないのです。

これを解決するためには次の認識と実践が必要です。

一つは捨石にするつもりでいなければならない、どうしたってそうせざるをえないのだから

人月の神話　フレデリック・P・ブルックス, Jr. 著　滝沢 徹・牧野 祐子・富沢 昇一 訳　ピアソン・エデュケーション

この認識は失敗を恐れないというような生ぬるいものではありません。『最初の一回は必ず失敗しなければいけない』と言っているのです。どの道、それは避けられませんから。ので、さっさと始めて一回失敗するのが正解というわけです。

それで、これを実践する為に、まず行うのがマインドマップの作成です。ここで作成するマインドマップは人に見せるわけでも、システムに対する正しい分析を導き出すためのものでもない、前述の通りに失敗するために書くものです。ので、センターに配置するトピックも適当でいいし、各々のブランチから派生されるブランチの構成が元ブランチとの関連から逸脱する、親子が逆、各ブランチの粒度がバラバラなどといったことは一切気にする必要もなし、システムの分析以外の要素、例えばこのプロジェクトに対する感想「な～んか嫌な感じ」、「だるい」、「ぶっちゃけやる気でない」などもドンドン書く、グチも書く、スピード優先なので手書きで全然ＯＫ、というより手書きの方がいい。これを行うと、世にも見事なカオスが表現されたマップ（？）が出来上がります。これは誤りだらけの分析、状況把握になりますが、『何が誤っているのか』を知る貴重な材料になります。そして貴重な失敗になる。自分自身のイカレタ認識を見るのは愉快です。

やってみるとわかりますけど、このカオスマインドマップ（←造語）を作った後は、再度マインドマップを作るにしても、要求仕様化を進めるにしても、タスクを洗い出すにしても、懸案抽出と解決を図るにしても、とてもスムーズに進みます。これは、自分の思考の課題がカオスマインドマップによって認識済みであること、そしてでたらめでも取っ掛かりがあることによって得られる効果です。

ともかく、カオスマインドマップの作成のみならず、リリースするまではどんなに失敗したってかまわないんですから、『一回でも多く、早く、失敗をしまくりましょう』。それが結局早道です。

細かく刻むことの有効性

重厚なエンジニアリングとしてのウォーターフォール、軽量なエンジニアリングとしてのアジャイル。これらは対比して語られることが多いプロセスですが、決して対立するプロセスというわけではありません。

アジャイル手法に傾倒するエンジニアに散見されることに仕様化、設計の軽視がありますが、これは明らかに間違っています。アジャイルは（もちろん細かな違いはあるものの）ウォーターフォールと同じ工程（仕様化、設計、実装、検査、リリース）を短い期間で繰り返してシステムを段階的に作り上げていく手法であり、仕様化、設計をないがしろにする、ましてや省くような手法ではありません。

ここまでの理解の上に、WEBシステム（特にコンテンツ系）の開発において、ウォーターフォール、アジャイル各々のメリット、デメリットを考えると、アジャイル手法は顧客を取り巻く状況の変化に追随しやすいというメリットは明らかであると思います。コンテンツ系WEBシステムの場合、顧客に加えてシステムの最終利用者として一般のネットユーザがエンドユーザとして想定されるケースが多いことから、エンドユーザの需要の変化に併せて柔軟に開発の方向性を変化させられることはメリットがあるでしょう。ですが、WEBシステムとはいっても基幹系に関わるシステムや３年、５年単位で使い続けることを想定されるCMSベースのものである場合、初期にシステムの要求を時間をかけて洗い出し、最適なアーキテクチャの選定を行った方がメリットがあると考えられます。なぜなら、アジャイル手法で細かく刻んでいくことはイテレーションの代わり目での変化には追随できますが、各イレテーション間に発生し得る全体の矛盾に気づきにくく、また、その対応も難しくなる傾向があるからです。

仕様は変化し、増えるだけではなく、過去の仕様と新規の仕様が衝突することがあるということを認識していないと、安易にウォーターフォール否定に走ってしまいます。全体を一度見通すウォーターフォールの方が、要求と仕様と適切に抽出していれば、全体の仕様の衝突、矛盾に気づきやすく、また、後日にシステムアーキテクチャレベルで対応不可能になる可能性も減らしやすいのです。

その案件の（要求仕様の）予測性の低さ、そして開発チームの置かれた環境（例えば、直接顧客とやりとりできる直受けであれば柔軟に対応しやすいでしょうし、二次受けなどであれば柔軟性は落ちるでしょう）により刻むことのメリットとデメリットを判断してプロセスを選択、設計できるようになる必要があります。一般には予測性が低く、チームが柔軟性の高い環境にいるならアジャイル寄りの軽量な手法が、予測性が高く、チームが柔軟性の低い環境にいるならウォーターフォール寄りの重厚な手法が選択されるべきです。

ケアレスミスは検査モレ

僕はとてもケアレスミスが多い人間です。その傾向を悟ったのは小学２年生の梅雨、日々繰り返す傘の紛失、忘れ物に母親から「もう新しい傘は買ってあげません」と言われたその日です。普段から、完璧に準備したとしても必ず、そう必ず何か一つは落ち度がある自分。写生会の忘れ物がないように前日に絵の具セットを入念にチェックしたかと思えば、翌日一人だけお菓子を持ってきわすれたり、前日に完全を期して授業の準備をしてから床についたら、前日たまたまもって帰っていた内履きを持ってき忘れたり。小学２年生の秋には「この世には努力ではどうにもならないことがある・・」などと少し達観した少年ができあがるのも無理はありません。

それはともかく、そんなこんなで大人になり、仕事をしているわけなんですが、やはりケアレスミスは相変わらず多く、特に書類仕事では必ず何か一つ抜けがあるようなある意味安定した品質を示す始末。これまでずっと「いや、自分はそういう運命だから」の一言で抜本的解決を試みてこなかった自分ですが、さすがに仕事上で繰り返すに至ってこのままではマズイと思いやおら考えてみました、ケアレスミス削減法を。
（真面目な理由を言えば、下手にケアレスミスを気にして完璧主義に陥り、行動できなくなることを恐れて本格的にこれまで取り組んでこなかったというのが正直なところ）

それで考えてみるなかで気づいたのは、ケアレスミスってソフトウェア開発における検査モレとイコールだということです。ソフトウェアにはバグが必ずあり、一般に、リリース前に検査工程が配置されて、その品質をチェックされます。バグがないか入念にチェックし、潜んでいるバグをたたき出し、バグが市場に出ないようにするのです。検査、バグ出しをしないソフトウェア開発はありません（最近は怪しいところも増えてきましたけど）、仮に検査してみたところバグがなかった場合も、それはそれで結構なことなわけですからよいわけです（実際には最初からバグが全くでないケースでは検査のやり方に問題がある可能性が高いですけど）。ともかく必ず検査はして、市場に対して、顧客に対して品質を保証しようとするわけです。ひるがえって、自分自身の普段の作業、ケアレスミスを招いている作業に関してはどうか？そう、全く検査していないのです。これが。少なくとも意識してやってはいない。ソフトウェアに対しては「バグがないわけがない」と考えて行動しているのに、自身の普段の作業に関してはミス（バグ）がないことを何の根拠（検査）もなく信じて提出しているのです。これでは結果（市場）にミス（バグ）が潜むのも当たり前ですね。

自分自身の作業にも検査の考え方が必要だったということです。そして、検査の考えを取り入れるということは常に検証可能性を考えて作業を行うということも意味します。作業結果の成果物の検証もさることながら、その発展形として作業プロセスの設計も行うようになる、つまり、マニュアル化をするようになるということです。マニュアルといっても仰々しいものではなく、メモにまとめて手順を整理するとかですけど。

日々の労働の中で、時間をもっとも奪うのが手戻りの発生です。ケアレスミスはほんのちょっと注意して確認しミスを防いでいればそのミスの対応時間は０になり、数学上無限大の効率化が行われるわけです。自分のこれまでのケアレスミスに対する考え方は、ソフトウェア開発にあてはめるととんでもない考え方、無駄を招来する考え方だったなと深く反省せざるをえません。仕様も決めず、設計も決めず、実装に入って手戻りを繰り返し、品質を落とし、時間を失い、検査を充分にこなせないまま市場に投入。そんな開発プロセスを実施しているのとイコールなのですから。

顧客に提案することの矛盾

顧客は自分自身が望んでいるシステム像、要件を理解していない、わかっていない、だからSEがヒアリングして、提案してシステム像を作り上げていくべきだ。

こんなフレーズ散見されますが、ちょっと待ってと言いたいです。この言葉には非常に問題があります。この言葉はその前提に『顧客は自分の望んでいるシステムがわからないが、SEには顧客の望んでいるシステムがわかる（わかるべき）』というとてもエキセントリックな発想を有していることを理解できるでしょうか？何の根拠があってこんなことがまことしやかに言われているんでしょうか。

別にシステム構築に関わらず、その人が何を望んでいるかは、その人が一番良くわかっているとするのが素直な発想だと思うのですが。いかがなものか。確かに、人間は自分の望んでいることを本質的には理解していないものです。それは事実です。そして、また、家族や友人などの近しい人間が本人以上に本人の望みを推察できるということもままあります。が、顧客が自身の望みをわかっていないという言葉は、こうした哲学的な次元で云われているものではないでしょう。また、顧客とSEは所詮仕事上の付き合いであり、四六時中一緒にいるわけでもないのですから、その意味でも顧客の望みを顧客以上にわかるとするのは無理があります。さらには、SEは所詮システム構築のプロでしかなく、顧客が日々直面している業務に対しては全くの素人なわけですから、そんな業務の素人の提案に期待するのは自殺行為以外の何ものでもありません。

考えてもみてください。自分が顧客の立場であるとしてですよ、「私、自分が何をしたいのか、何が欲しいのか全然わからないんです。ですので、そちらでドンドン提案していただけますか？検討はずれだったら口を出しますから。とにかく私の満足のいくものを作ってください・・・」、こんな台詞、自分だったら恥ずかしすぎて絶対に言えませんよ。

自分の望むものがわからないこと自体を自分は問題視しているわけではないです、実際に顧客はシステム構築に関しては素人なわけですから、要件がシステムという形を取る時にSEに意見を聞く、提案を求めるのは自然なことです。ですが、望むものがわからない状態をよしとする態度は断じてＮＯといわざるを得ません。自分自身の要件を探ろうともせずに、業務の素人（どんなに勉強したところで、所詮顧客に比べれば素人にすぎません）に丸投げするのは、責任放棄です。

要件を決めるのは顧客自身です。要件を顧客が決めない限り、ゴールが決まらないわけですから、プロジェクトが破綻するのは目に見えています。ベンダの食い物にされたくなければ、システムを望む側が望みを訴えるという当たり前の姿を取り戻すべきです。そして、ベンダやSEはよい意味でもっと『身の程をわきまえるべき』です。提案ベースでと言われているものの多くがQCDまでしか見えていない開発側の都合のよい提案に過ぎないことをもっと自覚すべきです。自分達は驚くほどに顧客の業務を知らないのですから。

ただし、WEBの場合、顧客はシステム開発の素人であると同時に、WEBの活用に関しても素人である場合があり、開発側が提案比率を上げていかなければ立ち行かないという現実もあります。ですが、この場合においても顧客の望みは顧客自身が決定する権利と義務があることにはなんら変わりはありません。

さて、何を見積もるか

Lawrence H.Putnamが自身で創設、最高経営責任者を務めるQSM社で6300件のデータを元に算出した開発関係式には工数と開発時間の間に下記の乗算の関係を示す。

（工数/β)^(1/3) x 時間^(4/3) = 大きさ（ある品質レベルで）/プロセス生産性

※βは重み係数（＝定数）
※初めて学ぶソフトウェアメトリクス
ローレンス・Ｈ／パトナム＋ウェア・マイヤーズ 著 山浦恒夫 訳 日経ＢＰ社 より

大きさはプロジェクト開始前（または初期）に見積もられるべき値であり、プロセス生産性は過去のプロジェクトの計測によって求められるものであるから、式の右辺は定数とみなせる。（常識の^記号はべき乗を便宜的に表現しています）

以上から、

（工数/β)^(1/3) x 時間^(4/3) = Const(定数)

となり、工数と開発時間にはトレードオフがあることがわかる。つまり、工数（コスト）を抑えたければ開発時間を長くする必要があり、開発時間を短くするためには工数（コスト）の増大を覚悟しなくてはならない。加えて、注目すべきは工数と時間にかかっているべき乗の値で、式の右辺（Const)に与える影響は時間の方が大であることがみてとれるということ。理解しやすくするために、工数と時間それぞれで式を整理しなおすと

工数 = Const / (時間)^4
時間 = (Const / 工数)^(1/4)

この２式から読み取れるのは、時間は工数（コスト）に対して4乗で効くので、開発時間をわずかに長くするだけでも工数は劇的に下がる、または開発時間をわずかに短くするだけでも工数は劇的に上がるということ。そして時間は工数に対して(1/4)乗でしか効かないので、工数を増やしても開発時間の短縮に与える影響は低い(工数を従来の4乗にしてやっと1の効果が出る)ということだ。これはソフトウェアエンジニアリングの古典的名著、ブルックスの人月の神話の『銀の弾丸はない』や、自分達自身の経験や直感とも矛盾しない。
この２式はソフトウェア開発の真理『小さいことはいいことだ』をもまた証明している。工数の追加投入は開発時間の短縮に殆ど寄与せず、欠陥率が開発時間の短縮、工数（コスト）の過剰投入によって増大することも考えあわせると、一般に同じ機能量（サイズ）のシステムをあるプロセスで開発する場合に大人数（＝コスト大）で短期開発するよりも、少人数（＝コスト小）で開発時間を長くとった方が結果として品質も向上し、コストも予算内に収まる可能性が高くなる。そして、開発時間は工数の追加投入をしない場合と殆ど変化しないことにもなる。

プロジェクト初期の要件定義、仕様化フェーズでPM、SEが行わなければならないことは、この工数と開発時間の非対称のトレードオフを頭に入れた上で、最適な工数と開発時間の組み合わせを決定することだ。ソフトウェア開発には最短開発時間というものがあり、どんなに頑張っても(マネージャや顧客がどんなに青筋立てて、脅して、なだめて、すかしてきても）実現不可能な時間というもの、あるサイズに対して最低限必要な時間というものがある(1000人月と見積もった場合に1000人が1ヶ月かければ作れるなどと考えるドリーマーがこの世に存在しないことを祈る）。そしてまた、逆にシステム開発はタイムリーに市場に製品を投入する必要性があることから無限に開発時間を延ばしてゆくことはまたプロジェクトの存在意義からして無意味だ。Putnumによれば、開発時間の拡大が工数に現実的な範囲で良好な影響を与えるのは最短開発時間の130%程度までということらしい。これ以上に開発時間を延ばしても工数削減に与える利益は極小化してしまうようだ。

以上から、PM、SEは構築するシステムのサイズを見積り、欠陥率、プロセス生産性を計測値から導入して開発関係式の右辺を決定した後に、工数と開発時間のトレードオフを検討することが非常に重要な職務になる。そしてその為にはサイズ、欠陥率、プロセス生産性の３つの値を手に入れなければならない。

欠陥率、プロセス生産性は過去のプロジェクトからデータを取得し、計測、分析しなくてはならない。この時、重要な点はプロセスは最低限繰り返し可能なものである必要があるということ。でなければ、過去のデータから取得した生産性はまったく意味がなくなってしまう。欠陥率はトラッカーシステム（Wikiなどでも可）で管理してきていれば、計測は容易に可能になるはず。実際には欠陥数とその対応に費やした工数を算出し、開発工数に対する割合で算出するのがよい。

プロセス生産性の計測にも関連するが、サイズの見積り、これが非常に難しい。一般にはプログラム行数をカウントするケースが多いが、WEBシステムの場合、画面やHTMLのテンプレートファイル数、画像点数、遷移数（リンク数）、状態数などのファンクションで見積もるべきかもしれない。またはユースケース数か。プログラム行数は計測は行いやすいが、見積り時にプログラム行数をベースに考えることはWEBシステムの場合現実的ではないからだ。欠陥率、プロセス生産性は計測で取得するが、サイズはあくまで見積もらなくてはならないことに注意しなければならない。このWEBシステムにおけるサイズ見積りの方法とプロセス生産性の計測については追ってさらに追求してゆきたいが、一点現時点で注意すべきことは、常に同じ計測基準、見積り方法を用いるべきだということだ。当たり前だが、プロジェクトごとに行数で計測したり、ファンクションで計測したりしていたのでは当然結果はぶれてしまう。

ちなみに、プログラム行数を簡易に計測するにはソースコード管理システムを利用していれば比較的簡単に変更行数としてカウントできる。（下記はSubversionの例）

svn diff URI@BASE_REVISION URI@head > diff.txt &

これはこれで使えるとは思うが、先ほども述べたように計測には使えるが、見積りには使いづらい。さて、どうするかね。

遊びの重要さ

行わなければならないことは、効率化ではなく時間的なロスの減少である。プロジェクトにおいて多くの時間を必要とするものは、「考える作業」と「やり直し」である。（中略）それぞれの工程ごとに不良を出さないように作ることこそが、結果として納期の短縮と品質の向上につながることは言うまでもない。プロジェクトマネージャが見た目の進捗率のみに気を取られ、「一刻も早くプログラミングを開始せよ」という指示を行った瞬間から、納期と品質に対する要求を満足させることはできないと認識すべきである。

ハッピィ・エンジニアリング 吉田智彦 著 SoftBank Creative

差し迫ったスケジュール下にあるプロジェクトにあると、プロジェクトマネージャーは目先の進捗にばかり目を奪われてて、熟慮しない、準備しない、ＰＧを急かしたてることによって生まれる「手戻り（やり直し）」によるロスに気づかない。終了したプロジェクトを振り返ってみれば、投入時間に占めるタスクの割合は、仕様・懸案の問い合わせと（デバッグも含んだ）手戻りの時間が殆どを占めていることがわかる。これはつまり、要件定義、基本設計で時間をかけて検討すべきだったことを棚上げしてその「考える作業」を実装フェーズにおっかぶせているということです。そして、その結果、仕様障害、設計障害、実装障害の各種障害対応という名の不必要な手戻りをも増やしているということです。

納期に間に合わせるために、管理の手にあまる要員を確保し、各々の手が空かないようにひたすら作業を切り出してつめこむ。自分がＰＧであった頃はこのことの愚かしさを充分味わっていたはずですが、いざタイトスケジュールのプロジェクト管理をやることになれば余裕の重要さ、遊びがあることの重要さを忘れて目先の進捗を満たすことばかりにやっきになっている。でも、これは返って納期と品質にペナルティを追う行為です。第一にＰＧのモラルが下がる。早く終えてもその分仕事が入ってくるのだから、やる気が失せるのは想像に難くない。第二に急かすからミスが増える。第三にＰＭ、ＳＥが未決仕様や懸案を解決させることよりもＰＧを動かすことに注力するため、折角作ったものが後で無駄になるケースが頻発する。第４に各作業領域の分担を精査せず無理矢理進めてしまうために、担当領域のグレーゾーンが増え、必要なコミュニケーション量が増大し、誤解も指数関数的に増えて品質劣化が進む。そして第５にこんな状況で口頭であがってくる進捗報告には何の信憑性もなくなってしまう。つまり、形だけの進捗管理になる。

これでは、『一生懸命やったのですが・・・』と後で使う言い訳を見繕うための行為ととられても仕方がありません。プロジェクト（または組織）内に余裕のあるメンバーが一人もおらず、かつ、余裕があることが他メンバーから責められるような状態に陥っているなら、そのプロジェクトは致命的にまずいです。突発に対処するためにもリソースに余裕、遊びは必ず必要です。そして、それを認めないような雰囲気になっているなら、そのプロジェクトはまさに管理者が管理をせずにただただ目先の進捗、それも根拠の不確かな数字を追い求めている救いのない状態であるということとイコールなのです。

少し自分で実装してみる

設計を書いてPGに指示する。
そしてPGは作業を開始するが、実装を始めてみると疑問点が次から次へと出てくる。
結果、SEへの問い合わせが頻繁に生じて進捗に支障をきたすか、問い合わせしないまま独断で進めて指示と異なるものがあがってくるか、どちらにしても労力のロスは避けられない。

ポイントは実装開始前に実装上で疑問になることはクリアにしておくということです。これには幾つか方法があり、設計書のフォーマットを工夫して、それを埋めるように書くことで抜けを防いだりする方法や、PGと直接口頭で話つつホワイトボードや紙で説明する方法などがあります。しかし、前者は準備に時間がかかり、それほど詳細をつめなくてもよいケースでは手数がかかりすぎるという欠点が、後者はPGが常に近くにいなくてはならないという欠点があります。遠方にいるPGに対しても、簡易なタスクに関しても、あまり手数をかけずに誤解なく、そしてもれなく設計を示したい。その為に、実地でやってみてよいなと感じるのが、そのタスクの最初の少し、5%にも満たないぐらいの少量でよいので、自分で実装してみるという方法です。

この方法を取ると、実装に必要な必要十分な設計情報が具体的なイメージでもって速やかに把握できます。5%に満たないとはいえ、実装しているから当たり前なんですけど。設計を書く時にコードに向かっている気分になることは非常に重要ですが、なら実際コードに向かってしまえ、ただし、必要最小限だけ。という手法です。結構、便利ですよ。

バグを見積もる

多くのSEが省いている見積りがあります。それは「デバッグの工数」です。つまり「発生したバグに対応する」プロセスの工数が見積もられないのです。

SEの仕事を楽しくしよう　清水吉男 著　SRC

バグ発生率、つまり欠陥率は品質を表す一つのメトリクスになります。品質には機能要件、性能要件の達成、拡張性、保守性、操作性など多用な要素によって構成されるものではありますが、これらは一定の尺度で数値化することが難しく、従って計測できません。比べて欠陥率は完了したプロジェクトのデータを蓄積すれば計測できる値であり、また、欠陥率と平均対応時間を計測すればデバッグ工数を下記の式で算出することもできる重要なメトリクスになるのです。

予想バグ対応工数(時間) = 欠陥率(件/行数=KLOC) × ソースの見積り行数(行数=KLOC) × 平均対応時間(時間/件)

こうしたメトリクスを活かすためには完了したプロジェクトの各種データを計測、保持してデータベース化しておく必要があります。こうした積み重ねをしておかないと、適切な予想バグ対応工数を経営層の納得の元に見積りに乗せることが難しくなります（経営層はまだしも顧客に理解を求めるには必須といえます）。

こうしたメトリクスを利用した上で、算出した予想バグ対応工数はまた、スケジュール上にしっかりと配置するということが重要です。納期のプレッシャーからか、慣習依存による無思考状態がそうさせるのか、デバッグ工数を見積り上取ってはいてもスケジュール上に他の開発フェーズと同様の重みをもって配置しているケースは稀です。漠然とテストフェーズなどとしていることが多いでしょう。かくいう自分もそうしていました。ですが、テスト工数≠デバッグ工数であることも認識しておく必要があります。テスト工数はバグを発見し、修正を確認するための工数であり、『デバッグするための工数ではない』のです。従って、デバッグ工数はテスト工数とは別に算定しなくてはならないのです。

いずれにしても、予想デバッグ工数を算定し、見積りに加え、スケジュールに表現しなければそのスケジュールは現実を反映したものにはなりません。スケジュールに現実を無視した理想を入れてはいけないのです。業界で半年も経験を積めばデバッグのない開発など存在しえないことはわかるでしょう。なのに、そのデバッグをする時間がどこにも見当たらない『奇跡のような』スケジュールばかりが散見されるのはどうしたことでしょう。

組織によっては、バグを見積もることを認めてくれないかもしれません。「バグがあることを前提として仕事をしているのか」と怒鳴られてしまうかもしれません。残念ながら、このような管理者の下では、ソフトウェア開発のプロセスの改善は実現しません。

組織、管理者の理解が得られないケースもさることながら、SE自身がバグを出すこと自体を悪いこと、恥ずべきことと考えていることからスケジュール上に組み込むことに抵抗を感じるというケースも多いのではないでしょうか。確かにバグを出すことは恥ずべきことかもしれませんが、だからといってデバッグ工数という必要な時間を削ることはできないのです。それにデバッグ工数というものを意識して、計測に努めない限り、自分、または自分達の組織がどの程度の欠陥率で仕事をしているのかわからず、改善もおこなわれません。問題は見えなければ意識されず。意識されなければ解決されないからです。本当にバグを恥じる心構えがあるなら、欠陥率を計測して、デバッグ工数を見積もるべきです。

大事なことはソフトウェアには大なり小なりバグが必ずあるということです。バグを出すこと自体に問題があるのではなく、それを見つけ、対応する時間を確保せぬまま低品質でリリースし、顧客に、エンドユーザの信頼を、自分達自身の仕事に対する誇りを失することが問題なのです。現実から逃避して理想化された世界（スケジュール）に生きていることが問題なのです。SEはそれを回りに、特に顧客に説明できるスキルを持たなくてはいけないのだと思います。

工数を時間で算出する

あるプロセスの所要時間が、本当は２時間であっても「１日」と見積もった場合、実際に７時間かかっても問題が表面化しません。「１日」でできると思っていた作業が夕方までに仕上がらず、夜中の１２時過ぎまでかかってようやく終わったとしても、「１日」で終了したことになります。これは、進捗管理にとっては由々しき問題です。見積りと数倍の差が生じていてもそれが見えないというのでは、進捗管理をしていないのと同じです（中略）。見積りが「日数」になっているということは、「進捗管理はしません」と宣言しているようなものです。

SEの仕事を楽しくしよう　清水吉男 著　SRC

工数を「日数」で見積もることと「時間」で見積ること、そこには最大で24倍の精度差があります。１時間で終わっても「１日」、２４時間で終わっても「一日」です。24倍の精度差を生じてしまうようなツールを使って顧客に約束できるスケジュールを提示できるわけがありません。そしてまた、日単位で進捗を把握するということは、その日の消化工数の帳尻だけあっていればよしという考え方と通じています。そこには、進捗管理という作業が、進捗が予想通りかどうかをチェックし、もし進捗があがっていないなら、その原因を分析し、取り除く、もし進捗があがりすぎているなら、見積り精度の見直しに取り組み、同時にリスクの高いタスクを先倒して対処するようにリソースを割り振るという作業であるという認識は皆無です。内容には注意を払わず、ただ結果、しかも目先の結果だけ見て安心したり、不安になったりするだけで、何の障害も解決することも、分析することすらしないまま、神頼みのように「早くしろ、早くしろ」とチームメンバーをせかし続ける。こんなことが進捗管理だと思っている。

進捗管理とはチームメンバーに無理させて自分の計画を遵守させることではなく、日々チームメンバーの行く手に立ちふさがる障害を取り除いて、メンバーに開発に集中してもらう、いわばグラウンドの整備のような仕事です。荒唐無稽な計画を盾にとって鬼軍曹になることではないのです。そしてまた、進捗管理をする日々とは、自分の立てた計画、見積りの正確さが日一日と明らかになっていく過程でもあります。自分の立てた計画が現実と大きく乖離していた場合、当然速やかに計画の修正を検討し、事態に対処する必要がありますし、計画自体はそれほど乖離していなくても、想定外の事態が発生して進捗があがらなくなるようなことがあれば（必ずあります）、速やかに原因分析して解決を図らなくてはなりません。

そして、進捗管理という作業が、現状把握と原因分析、（進捗上の）障害解決であると認識すれば、進捗を「時間」で把握すべきであることもすぐに理解できます。なぜなら進捗管理にとって現状を素早く知り、問題箇所を特定するための詳細データが手に入れることがその成否の鍵を握るからです。４時間の作業も１２時間の作業も同じ１日で捉えているようなヌルいセンサーじゃダメなのです。時間で見積り、そしてその時間から前後25%以上振れがあるなら、問題視すべきです。問題は小さな内に見つけて解決する方がたやすいからです。

とはいえ、顧客に提示する見積りやスケジュールに時間レベルで詳細がみっちり記述されたものを提示するのは、顧客にとっては苦痛でしょう（中には喜ぶ顧客もいるかもしれませんが）。顧客は大枠で捉えたいのですから、顧客に対しては従来どおりの日数や週、大きなプロジェクトであれば月数などで提示すればよいと思います。しかし、内部では必ず、時間で作業を見積るべきです。最初に時間で見積るべきです。そうでなければ必ず顧客との約束を破る見積りになってしまいます。もちろん、時間で見積もってもずれは生じます。結果として約束できない見積りになってしまうこともあります。けれど、時間で見積もっていれば、詳細をログしておけば、必ず次の精度アップに寄与させることができます。日数で見積もっている限り、最初に述べたように最大２４倍の誤差が生じます。極端な例では１日と２４日の差を生むのです。こんなことを平然と繰り返す素人仕事はやめなくてはいけません。

「サイズ見積り」をはしょった「いきなりの工数見積り」、そして最大２４倍の誤差を生む「いきなりの日数見積り」、この二つが掛け算されたら一体にどんな夢のような見積り、スケジュールになってしまうのでしょう。しかも、これで通した見積りは夢では終わらず、それに沿って作業をしないといけないのです。悲劇です。でも、「いきなりの工数見積り」×「いきなりの日数見積り」は悲しいぐらい普通のコトとして業界には蔓延しているのです。

“ざっくり”見積りといきなりの工数見積

　「見積り」と「スケジュール」は別のものです。見積りとは、「サイズ見積り」「工数見積り」「金額見積り」であって、その中の工数見積りを基にして、リソース情報に見合う形で分担を分け、さらにリスクの対応などから見える工数情報を加味した上で、カレンダーに割り振ったものがスケジュールです。
　多くのプロジェクトでは、この見積りがいい加減なのです。最初から“ざっくり”見積もったものであったり、（うまくいかなかったはずの）“過去の経験”に基づいていたりして、まともな見積りを見ることはほとんどありません

SEの仕事を楽しくしよう　清水吉男 著　SRC

工数とはその定義上、直接見積れる対象にはなりえません。これは業界の多数が気づいていない、または意図的に無視していることです。工数とは要件から洗い出した実現すべき機能の「サイズ見積り」を『作業担当者の生産性（サイズ/時間）割ることによって算出される計算値』です。

工数 = サイズ見積り（サイズ） / 生産性（サイズ/時間）

実際にはこの計算式で算出される工数は単位が時間ですから、各々の作業担当者の単価をかけてコストにする必要がありますが、ここでは時間のみを見ることにします。
ともかく重要なのは、工数とは直接見積もるものではなく、まずサイズ見積りが先にあり、その上で作業担当者の生産性により著しい影響を受けるということです。
従って、本来、担当者も決まっていな状態で、そして担当者の生産性を計測してもいない組織において、工数を見積もることなど不可能なのです。さらに“ざっくり”だなんて、悪い冗談。将来の禍根を自ら招いているようなものです。
そして、スケジュールはこのバッドジョークであるところの『夢物語のような見積り』をベースに作成されるのですから、荒唐無稽になるのは自明の理です。

見積りの場では、よく「過去の経験で」というフレーズが使われます。（中略）。計測もされない組織の「過去の経験」が、ここで参考になることはありません。（中略）。「サイズ」を見積もるためには、作られる中間成果物がはっきりしなければなりません。残念ながら、多くのプロジェクトでは、具体的にどのような中間成果物を作りながら最終成果物に導くのか明らかにされていません。

中間成果物を考えていないということは、つまりプロセスを考えていないということです。スタートとゴールだけ見て、経路は考えていないのです。東京から大阪に向かうのに何時間かかるか？を考える時に、経路を考えないで見積るなんてあり得ないですが、これと同じことをやっているのです。経路を特定しないで“ざっくり”見積もった見積りがどれだけあてにならないものか、これでわかろうというものです。
工数見積りは、まず経路（プロセス・中間成果物）を決めて、その総距離（サイズ）を見積り、そして交通経路（生産性）を決めることで初めて決定するのです。“ざっくり”見積りは精度の点で詳細見積りより劣るというような生易しい話ではないのです、それは全然別物だという話なのです。４０人日かかると“ざっくり”見積ったものの詳細をつめると結果は38.5人日とか、43人日とかじゃ『ありません』。全然低いか、圧倒的に巨大になるのです（たいがい巨大になりますね）。だって、“ざっくり”見積りのときは、経路も、総距離も、交通経路も決めずに、過去の計測もまともにしていない状態で、イメージで見積もっているようなものなのですから。

しかし、現実問題、業界、特にWEBシステム構築案件では、まずは“ざっくり”が横行しています。それが、約束できないスケジュールしか出せず、自分達を常に時間がない状態に追い込む根本原因であることに気づかないまま。
また、営業レベルでは、あくまで顧客に予算感を『少しでも早く』提示したいということもあるので、詳細見積りを作る時間も情報も大抵与えられません。また、我々ＳＥ自身も日々の忙しさから、新規案件の見積りの営業からの「“ざっくり”でいいよ」にはついついほだされてしまいます。

しかし、ここで負けてはいけないのです。“ざっくり”見積もっているからいつまでたっても約束できるスケジュールが出せず忙しさに追われる現状が打開されないことは述べた通り。でも、与えらる時間と情報は少ない。だから、与えられた時間で、最大限粘って、少しでも詳細をつめる、そして、その結果、その案件の予測性は少し向上し、少し時間ができる。そしてその時間をまた次なる案件の見積りをより詳細にするために投入する。このループを繰り返してゆくしかない、そう思うのです。

計測もされていない、あてにならない「過去の経験」なんて捨てて、サイズをちゃんと見積もりましょう。そして、終了したプロジェクトは必ず計測しましょう。営業とは『いい意味で』対決しましょう。それが、結局会社全体も、営業スタッフも、ＳＥ自身もHappyになる方法なのですから。