ソフトウェア見積りを大きいと感じさせる4つの要因を理解する

ソフトウェアエンジニアが作成する見積りはいつも大きすぎる。そういった声を聞くことが度々あります。これは、受託開発での顧客の声ではありません。社内でのやり取りです。ここでは自社ソフトウェアプロダクト開発の現場の話という前提で進めます。

この発言はもちろん、ソフトウェアエンジニア以外の人によるものです。ソフトウェアプロダクト開発には、エンジニア以外にも様々な職種の人々が関わります。ビジネス・企画、マーケティング、デザインなど。エンジニアの間では、これらの職種で働く人たちをまとめて「非エンジニア」と呼ぶことも多いようです。その非エンジニア職の中でも見積りをエンジニアと直接やり取りするのは、企画も含めたビジネス職が多いでしょう。「ソフトウェアエンジニアが作成する見積りはいつも大きすぎる」という声は主にそこから発せられています。

見積りを受け取る非エンジニア職からの指摘としては、「スケジュールにバッファを取りすぎているのではないか」「やることを複雑に考えすぎているのではないか」と言ったところが多いように感じます。そういった側面も無いとは言えませんが、実際の見積りに強く影響を及ぼしているのは、「アーキテクチャ」「保守性」「1日の長さ」「不確実性」に対する考慮です。これらを無視した見積りは、ソフトウェアシステムや計画の破綻を招きかねません。

本エントリでは、非エンジニア職にとって見積りを大きく感じさせるこれら4つの要因について明らかにしていきます。

1. アーキテクチャ

ソフトウェアアーキテクチャとは何であるか、非エンジニア職が理解することはとても困難です。アーキテクチャを扱うエンジニアですら、誰もが理解できているとは言い難いようにも感じるぐらいです。ここではアーキテクチャが何であるかはいったん脇に置いて、アーキテクチャがソフトウェアシステムやその開発・運用・保守活動に及ぼす影響を理解することから始めるのが良いように思います。

新しいソフトウェアシステムや、時には、新しく追加する機能には、アーキテクチャが必要です。アーキテクチャをないがしろにしたソフトウェアシステムは、機能要件・非機能要件を十分に満たせません。特に、非機能要件に影響が出ることが多いでしょう。その代表的な例が、ユーザーのアクションに対し、いらいらするほど反応が遅いアプリケーションです。ひどいケースでは、遅いことも通り越してシステム停止に陥り、アプリケーションが利用できなくなることが頻発するようなこともあります。機能だけはそれなりに形が整っていても、これではソフトウェアシステムとして使い物になりません。

アーキテクチャを軽んじたとしても、運良く機能要件・非機能要件ともに満たせることもあります。しかし、それが長く続くことは期待できません。いずれ破綻することが予想されます。使い続けるうちに、どんどん反応が遅くなるアプリケーションなんかがその代表です。

また、影響はユーザーに対してだけとは限りません。その影響は、リリースまでのリードタイムにも及びます。ソフトウェアプロダクトは、日々、機能追加や機能改善が繰り返されます。優れたアーキテクチャと組織体制があれば、そのような変更をテストし、本番稼働させるまでの時間を最短にすることができます。

さらに、アーキテクチャは、本番稼働中のソフトウェアシステムが障害を起こしたときの復旧時間にも影響します。優れたアーキテクチャであれば、問題を検知してからサービスを復旧させるまでの時間が短く済む可能性が高まります。この時間が短ければ短いほど、ユーザーにとってもビジネスにとっても、被害は小さく済みます。もし障害時間が数日や数週間に及んでしまったら大損害です。

以上が、アーキテクチャがソフトウェアシステムやその開発・運用・保守活動に及ぼす主だった影響です。見積りには、完成時の機能要件・非機能要件を満たすことに加え、本番稼働後にも要件を満たし続け、さらには、変更を本番稼働させるまでの時間を短くするために必要なアーキテクチャの実現に要する時間が含まれているということです。

アーキテクチャは、「後で変更することが難しい部分」とも言われます。最近では、それを容易にしようとする考え方も出てきてはいますが、現実的にはやはり、後で変更するのはまだまだ難しいというのが実感です。それだけに、変化が求められ続けるソフトウェアプロダクトにとって、その変化に対して都度、適切なアーキテクチャを組み込んだり適応させていくことは、欠かすことができない活動です。

2. 保守性

ソフトウェアシステムの品質上の問題として話題にあがるのは、顧客やユーザーに直接影響するような、「欠陥」や「バグ」と呼ばれるものです。それは主に、機能要件をもとに定義された仕様に対する違反です。時には、仕様自体の間違いもあります。また、機能の応答速度が遅いケースのように、ユーザーが体感できるタイプの非機能要件への不備かもしれません。いずれにしても、テストで検出できる問題です。

同じく品質上の問題であっても、顧客やユーザーには直接影響しないものもあります。このような品質問題は、ソフトウェアシステムとしての振る舞いは正しいため、テストでは検出されません。これが影響を及ぼすのは、機能追加や機能改善などに要する時間です。

多くのソフトウェアプロダクトでは、その長いライフタイムの中で、機能追加や機能改善が何度も繰り返されます。そのような変更に要する時間は、ソフトウェアシステム内部の状態の良し悪しに大きく影響を受けます。既存のソフトウェアシステムの設計や実装が酷い状態にあると、ちょっとした変更であっても予想外に長い時間を要したりします。

たとえ初期開発時は優れた設計・実装であったとしても、変更を繰り返すうちにその品質は徐々に悪化していきます。ましてや、初めから破綻した設計・実装であったなら、変更を繰り返すうちに手の付けようのない状態に陥ります。そのために、以前にやった変更と同程度の規模感の内容だとしても、前より見積りが大きくなってしまうのです。

つまり、見積りが大きくなる理由のひとつに、ソフトウェアシステムの設計や実装の悪さ、つまり「保守性」の低さがあるということです。保守性を左右する要素には、ドキュメンテーションや先述したアーキテクチャも含まれます。このようなコストをできる限り低減するためにも、初期開発時や変更の都度、高い品質の設計や実装を行うことや、定期的にコードのクリーンアップをするようなコストを支払うことも必要になります。

3. 1日の長さ

1日あたりの業務時間は、残業を除けば多くの企業で8時間程度だと思います。そうであるなら、見積りにおいての1日の長さも8時間だと考えてしまうかもしれません。工数で言えば、1人日=8時間、となります。しかし、私の観測範囲で言えば、1日の長さを8時間として見積もる開発チームはほとんどありません。感覚値で言えば、1日を6.5時間程度として見積りを作成する開発チームが多いように思います。もっと短いチームでは、5時間としているチームもあります。

1日の全ての時間をエンジニアが開発タスクに使えることなど滅多にありません。業務には、細々とした雑務もあります。頻繁にメンションされるチャットでのメッセージにも応答しなければいけません。各所とのミーティングも、定期的、あるいは不定期に入るものです。兼務する何らかの社内ワーキンググループでの活動にも時間が取られます。

エンジニアとしての業務においても、開発タスク以外のものがあります。本番稼働するソフトウェアシステムにトラブルが発生した時の緊急対応は、突発的に開発時間と集中力を奪う原因となります。また、自動化されていない運用業務にも時間を奪われます。

開発タスク外のこのような時間を考慮した結果が、見積りにおける1日を6.5時間前後とする背景です。1か月を20営業日とするなら、1日8時間なら1か月で160時間であることに対し、1日6.5時間であれば1か月は130時間となり、30時間の差が生じます。1日5時間なら1か月は100時間であり、60時間という大きな差になります。開発チームの時間を無駄にしないことがどれだけ大切なのか、それがよく分かります。

4. 不確実性

要件や仕様が明らかにされ、詳細な開発タスクにまで落とし込んでから算出した見積りと、要件がまだ曖昧な状態で算出した見積りとでは、同一の機能開発に対する見積りであってもその結果が大きく異なります。もちろん、前者の見積りの方がより正確な見積りとなります。これは、不確実性の大きさによる差です。要件が定まっていない状態での見積りは、「大体これぐらい」といった、経験や想像に基づく大まかな数字を出すしかありません。

このような不確実性の高い状態での見積りは、「何を作るのか」「どう作るのか」の選択肢が無数に存在します。そのどれを選ぶか、どこまで想定するかで見積りの「前提」に大きな違いができ、それが見積り結果に表れます。したがって、見積りを介してコミュニケーションする双方の前提が揃っていなければ、見積り結果が大きすぎるように感じたり、逆に小さすぎるように感じたりするのは当然のことです。

問題なのは、不確実性が高いことではありません。そういった状況下で見積りが必要となる場面はいくらでもあります。そもそも詳細が明らかになるまで見積りがまったく行われないことの方がめずらしいでしょう。

ここでの問題は、双方のコミュニケーションが不十分であることです。エンジニアが、見積りと共にその前提を明らかにするというアプローチも悪くはありませんが、手戻りコストが発生するリスクがあります。見積りの共有を受けた側が、その前提を否定する可能性があるからです。そうであれば、不確実性が高ければ高いほど、双方が集まって協力して見積りを作成するアプローチの方が良いように思えます。

「非エンジニア」という呼称に見るエンジニアの孤独

実は、「非エンジニア」なる呼称には違和感を感じています。「非営業」や「非マーケター」「非デザイナー」なんて呼び方は聞いたことがありません。そこには、特にエンジニアたちの間で、自分たちとそれ以外の職種で2つに分けて考えることで納得しやすい何かがあるのでしょう。

それほどまでに、エンジニアとそれ以外の職種の間の情報は非対称だということかもしれません。つまりソフトウェアエンジニアリングに関する業務には、専門職であるエンジニアにしか見えていない、エンジニアしか理解していないことが多いということです。エンジニア以外に理解されないそのもどかしさが、「非エンジニア」という呼称が使われるようになった背景であるように思います。なんだかエンジニアの孤独感さえ感じてしまいます。

見積りの問題も多くはこの「情報の非対称性」から生じています。専門職であるエンジニアにしか見えていない「何か」が見積りに含まれているからです。非エンジニア職が見積りを「大きい」と感じる要因には、こういった背景も含まれているということです。