『「納品」をなくせばうまくいく』というパラダイム

久しぶりのブログです。
コードの匂いが全くしない内容です。

「納品のない受託開発」のSonicGardenの社長 倉貫さんが、日々実践されていることを本にまとめられたので、早速読みました。

「納品のない受託開発」は、SIerとよばれるIT企業による受託開発モデルの課題を解決するためのビジネスモデルです。 SI型のシステム開発は、企業内の開発部隊が作る「内製」とは異なり、他の企業にシステム開発を発注します。 多くの場合、企業内の情報システム部門や大企業のIT系子会社が発注しています。

私はIT子会社(ユーザ系)に所属していますが、書籍に書かれているような課題は常日頃感じています。 そこで、受注側ではなく発注側における目線で、システム開発の「常識」と「課題」についてこの機会に書いてみます。

情報システム部門におけるSI型システム開発

1.役割分担

情報システム部門は、企業内に利用者(ユーザ部署)や企画部署があるという立場から、社内の資金や意思決定に関わる調整と開発のスケジュール管理を行うことが多いです。

技術は日々生まれては進歩しています。多くの問題を解決出来るようになっている一方、システム開発に必要な技術の複雑性は増しています。日々の業務をこなすだけでは、技術の進歩に置いていかれるため、実際にシステムの開発を行う部分をSI専門の企業に受託開発をお願いしています。

システム開発に関わることになると、いわゆるSI的なシステム開発をするケースが多いです。 要望・要求をベースに、システムの設計・開発・運用を含めてSIerと言われるシステム開発会社に発注すると言うものです。 システム開発は非常に難しいもので、過去の失敗から改善を繰り返し、そこから学んできたことを愚直に実践していると思います。

2.ドキュメントによるナレッジの蓄積

組織でシステムの開発や保守を行うと、担当者は定期的にローテーションで部署異動が行われます。 特定の個人しか知らない事が多い中で、担当者が抜けてしまうと、たちまち業務が立ち行かなくなってしまいます。 そのため、システムを開発する際はドキュメントを沢山作ることで、知識を人ではなく組織にためていきます。 次に来た担当者は、ドキュメントを読めば業務を引き継ぐことが可能です。

3.ウォーターフォール型の開発プロセス

ウォーターフォール型と呼ばれる要件定義から開発、テストまでのプロセスを1つずつ完了させ、次のプロセスにうつる方法が多くの案件で採用しています。 設計がちゃんと終わっていないまま開発を行うと、設計の変更によって作り直しが発生し、無駄な開発体力の消費とスケジュールの遅延を発生させます。前の土台がしっかりしていないのに次の土台を作れないという考え方がベースにあります。

とはいえ、現実には次のステップに進む前に、開発途中で発生するトラブルや、計画時に想定されていなかった作業などから遅延するということが起きがちです。スケジュールや見積りでバッファを設けますが、バッファを食いつぶすような問題が発生することも、まれによくあることです。 開発やテストなどのそれぞれのプロセスに直列的にスケジュールが引かれるため、1つでもスケジュールが遅延すると後続のプロセスもその分遅れていきます。デスマーチと呼ばれる過酷な労働は、納品期限に間に合わせるため遅延を取り戻そうとすることで発生します。

この開発手法は、過去の失敗からの改善を積み上げてきた結果です。 大規模なシステム開発を中心にこれまでに一定の成功を納めてきたと思います。

SI的開発手法の課題

ただし、とりまく環境が変わって来ました。 詳細は書籍を読んでいただくとして、ここでは簡単に今の開発プロセスの課題を簡単に記載します。

1.計画が全て = 計画を見誤れば失敗のリスク

ウォーターフォールという開発手法は計画が全てです。 計画が見誤っていたり、とりまく環境が変わった場合に、抜本的な変更を行うことができません。 つまり、変化に非常に弱い方法です。数年規模の開発を行っていた結果、開発していたものがリリース以前に不要なものとなるリスクを抱えています。 また、計画外のトラブルや検討漏れはどうしても発生します。

2.膨らみ続けるシステム・コスト

最初に計画したスケジュールよりも大きく前倒しで納品するような事例は、ほとんど聞いたことがありません。 計画よりも大幅に前倒しに終わるということは、発注側からすると「余分」なコストが発生しており、過剰見積りと見なされてしまいます。 また、もし次のシステム開発があったとして、見積り金額よりも低い金額でしか予算が獲得できなくなる「恐れ」があります。 これは、トラブル等のためのバッファ分が削られることを意味し、次の開発で納期に間に合わなくなるリスクが高まることにつながります。 そのため、システム開発の予算は膨らみやすくても縮小しにくいです。

3.引き返せないタイミングでの確認

情報システム部門は、開発しているシステムの直接的な利用者や業務の担当者ではありません。 作ったシステムに対して、計画通りかどうかは判断できたとしても、業務的に正しいかどうか、利用者が使いやすいと感じるものかどうかは、判断が難しく一般論の範囲でしか意見を言うことができません。 そこでシステム開発の最終段階で、担当者による受け入れテストが行われます。 受け入れテストでは、担当者が実業務を想定した動作検証や、利用者の操作シミュレーションを行います。 なぜ最終段階で行われるかというと、ウォーターフォール型の開発が1つずつのステップを経ることで動作するシステムを作るため、最終段階にならないと設計した機能が使えると保証できないためです。

ただし、もし受け入れテストで重大な問題があったとしても、最終段階のため取り返すことは絶望的です。
もちろん、そんなことが行われないために、沢山の認識合わせの打ち合わせと、設計書確認による言質のようなもので担保しようとします。それでも重大な問題が発生してしまった場合は、利用者に負担を強いる運用でカバーする方法がとられるか、また予算を確保して追加開発を行う方法か、それらの組み合わせで対応されます。 全部の機能が動かなくとも、優先度の高い部分だけでも早めに確認すれば、重大な問題となるリスクがおさえられるはずです。

なぜこれらの問題は変えられないか

企業によって事情は様々だと思いますが、これまで記載してきたような開発手法にビジネスモデルや業務スタイルをフィットさせてきたためといえます。
予算獲得のための提案から稟議承認までの各種ワークフローや、受発注手続きといった金銭周りの仕組みから、開発現場における成果物の定義からスケジュール管理、開発・運用の体制までが数十年をかけて、納品のある開発スタイルに最適化されてきました。
また、そうした環境で仕事を何年も何十年もやってきた方には、常識として考え方や取り組み方が染み付いていると思います。
また、少しずつ改善はしてきても根本的な問題として常に立ちはだかってきたため、「変えられないもの」と思い込んでしまっているのかもしれません。
そして本当のところは、「今の方法で成功はしていないけど、それほど失敗していないじゃない。目の前の仕事に追われてそれどころじゃないよ」と考える方の割合が多いのかもしれません。
でも翻って、目の前の忙しさって、実は今の開発プロセスの歪みから生まれている部分なのでは?とも思います。既存のパラダイムの限界で整合性が保てなくなってきていて、次のパラダイムへ移行する必要が出てきているフェーズなのかもしれません。
(この辺りの話は、『科学革命の構造』で語られている内容と同じなのかなと。)

「正しい」方法で、「一か八か」ではなく堅実な開発

SonicGardenさんの「納品のない受託開発」は、納品のある受託開発とは抜本的に異なる手法でありながら、システム開発を「一か八か」にしない方法だと思います。
全部を作らずに優先順位に基づく開発や、月額定額性、技術者の採用、どれをとっても堅実です。 既存の方法でうまく行っていない点を、「正しい」と思える方法で解決しています。

また、ともすれば「完成させること」が目的になりがちなシステム開発を、ビジネス成功のための手段とするアプローチです。
例え「銀の弾丸」でなかったとしても、パラダイムを変えて目線を変えれば、「変えられない」と思っていたことが実は変えられるものになり得ると教えてくれます。

どんな方法かは、ぜひ実際に書籍を手にとって読んでください。

さいごに

システム開発の新しいパラダイムとして、世の中に広がっていき、多くの人が喜んだり幸せになり価値を生むシステムが増える事を願うとともに、自身も何らかの形で実践していきたいと思います。

「納品」をなくせばうまくいく ソフトウェア業界の“常識

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル