不可能への挑戦？
～100点開発の負のスパイラル～

システム開発は、ユーザー要件を完璧に満たしたバグのないリリースを目指し、長い間様々な開発方法論を研究してきました。しかし、いまだに、開発プロジェクト、特に基幹システム開発は失敗例が後を絶ちません。何故でしょうか。QCDの100％の達成は、不可能への挑戦だったのでしょうか。
ビジネスに、スピードと成果の両方が求められる時代です。システム開発も例外ではありません。スピードの時代におけるシステム開発とは何かを考えるにあたり、今回の考察では100点主義の開発が、何故不幸な結果を生み続けてきたのかを探ります。

スピードの時代と60点主義

世の中には、60点主義という仕事術が存在します。

60点くらいの出来で早く出す
フィードバックをもらって残りの40％をブラッシュアップする
内容重視で見た目の美しさは求めない

というのが大まかな考え方です。端的に言えば、「スピード重視」「目的が達成でていれば体裁や綺麗さにはこだわらない」という事です。

ビジネスの成功要因にスピードが不可欠になってきた時代において、イノベーターと言われる人たちも、このような考え方をよく述べています。例えば、マーク・ザッカーバーグは、IPO申請書に添付した有名な手紙でこんな事を言っています。
「ハッカーウエーとは、継続的な改善や繰り返しに近づくための方法なのです。（中略）ハッカーは長期にわたって最良とされるサービスを作るために、一度にすべてを完成させるのではなく、サービスを機敏に世に出し学びながら改良することを繰り返します。（中略）壁には『素早い実行は完璧に勝る』と書き記し、このことを肝に銘じています。」

また、いまやIT大国となったインドの強さは60点主義の精神にあるとも言われています。インドのIT産業の考え方は、まずはソフトウェアを顧客に提供し、顧客からの問題指摘や改善提案をオンラインで集めて改善していく、というものだそうです。これが今のスピードを求めるITのニーズに合っているのです。アルファベットもマイクロソフトもIBMもインド出身のCEOです。

システム開発は不可能への挑戦だった？

近年のデジタル技術の急速な進歩にあいまって、様々な分野でもデジタルツールによって精度と効率性の両立が図られています。3Dプリンタを使ったモックアップなどは、ある意味スピードとクオリティを両立させる60点主義の考え方のデジタル版とも言えます。

かたや、最もデジタル技術と関係性が深いと思われているシステム開発の領域はどうでしょうか。システム開発は長い間、いかに100％の品質を担保するにはどうしたらいいかを追求してきました。

漏れなく網羅的に要件を定義しよう。
細部にわたって完璧に仕様を固めよう。
固めた仕様で、誤差の少ない規模と工数を見積もろう。
バグをなくすために完璧にテストをしよう。

といった事を当たり前に目指してきました。というよりも、それを目指す事がエンジニアとしての矜持のような風潮がありました。しかし、これは不可能への挑戦だったのではないでしょうか。システム開発は、超労働集約型作業であり、かつ単純作業でないため、個人のスキルのバラつきを平準化し、型にはめる事が本質的には難しいのです。それを、方法論を作ったり、標準化したり、ガイドラインを徹底したりといった様々なエンジニアリング手法を考案し、品質を均質化しようとしてきましたが、結局は個人のスキルの問題が大きく影響するため限界があります。その不可能を可能するための気が遠くなるような努力の甲斐もなく、ある程度の規模以上の多くのシステム開発プロジェクトは、コストオーバー、期日オーバー、障害多発に見舞われてきました。

100点開発の負のスパイラル

システム開発で100％を目指す事が、何故負のスパイラルに陥ってしまうのでしょうか。

要件定義、設計の例

従来、要件定義や設計は机上の作業でした。所詮は頭の中での想像です。頭の中で仕様を100％漏らす事なく定義するのは端から不可能です。しかし、開発ベンダとしては、請負で開発する以上、仕様を固定化せざるを得ません。そのため、100％でないものを、100％として扱い開発を進めていくため、全てのしわ寄せが後工程に収斂され、システムテストやユーザーテストでその歪が一気に吹き出て、コスト超過、期間延長、果ては責任問題に発展します。

開発の例

前述のように、システム開発という労働特性上、100％の品質保証はそもそも不可能です。しかし、ユーザーはベンダに請負保証と過剰なコスト低減を求め、ベンダは受注獲得のために要員数とスキルレベルを絞り、ギリギリの見積を提示します。結果、品質低下→障害多発→仕様変更・障害の区別が曖昧になり工数逼迫→請負なので追加請求はできずやるべき事を端折りシステムテストに回す→システムテストやユーザーテストでの障害多発、といった死のスパイラルに陥る事になります。

これが負のスパイラルである事は、うすうす分かっていました。しかし、なかなか有効な解決手段がなかったのも事実です。

【図1】100点開発の負のスパイラル

60点主義開発を阻む三つの壁

近年、システム開発もスピードと柔軟性が求められる時代になってきました。アジャイル開発も一般的になりつつあります。ローコードやノーコードで手間かけずにモノを作ることも可能になってきました。システム開発は、従来の100点主義から脱却していけるように見ます。しかし、実際には、長年システム開発に携わる人々に染みついてきた100点主義の亡霊を払拭することは簡単な事ではありません。そこには、三つの壁が存在するからです。

意識の壁
業界構造の壁
ユーザースキルの壁

私たちは、これらの壁を乗り越え、死屍累々を生み出すような開発プロジェクトを、今風の言葉で言うならばウェルビーイングな開発プロジェクトに変えていかなければなりません。システム開発には、様々な開発形態（パッケージ、スクラッチ等）や開発工程が存在します。60点主義の開発には、それぞれの開発形態や工程に応じた適用方法があると考えます。次回以降、各開発形態や各工程を題材に、60点主義の開発方法を考えてみたいと思います。