コンサルティング

完成した機能の64%は使われないというムダを回避するためには?

  • このエントリーをはてなブックマークに追加

こちらに表示した調査結果は、完成したソフトウェアの全機能を100とした時に、実際に業務で利活用されている…

つまりビジネスに貢献している機能の割合をグラフ化したものです。

standish group xp 2002

この調査結果は、アメリカの調査機関であるスタンディッシュグループが発表したもので、様々なレポートでも引用されている非常に信頼性が高く、そして何よりショッキングな調査結果です。

その結果は、実に完成した機能のうち「いつも使う」そして「よく使う」はたったの2割。

そして「ほとんど使わない」と「全く使わない」を合計するとじつ64%。3分の2は、ビジネスにほとんど、もしくは全く貢献していないという結果でした。

これはつまり、貴重な事業資金を投資して完成したソフトウェア開発費用の3分の2がドブに捨てられているようなものですね…

こんにちは。
株式会社ライジングサン・システムコンサルティングの岩佐です。

私たちは、長野県北信地区にある年商100億円未満の企業様を中心に、小予算でムダがなく、そして投資対効果の極めて高い情報システム投資の実現をサポートしています。

こちらの記事では、なぜこのような大いなるムダが発生してしまうのかの根本原因を追求し、そしてその問題を解決するために私達が実践している新しいソフトウェア開発手法をご説明します。

少し長い記事になりますが、必ずあなたのソフトウェア開発プロジェクト、そして情報システム投資に役に立つ内容だと確信しています。

※この記事の最後に期間限定の無料動画プレゼントのご案内を掲載しています。お見逃しなく!

 

大いなるムダの諸悪の根源は「一括請負契約」にある。

私はこの大いなるムダの最大の原因は、一括請負契約という契約方法に原因があると考えています。

一括請負契約とは、ソフトウェア開発会社が、ソフトウェアを「完成」し「納品」することが義務になっている契約のことです。

つまり、ソフトウェア開発を受託する開発会社は、最初に決めたすべての機能を完成させ、そして納品するまで、お金を受け取ることができないという契約です。

こう聞くと、ごくあたり前のように思えますが、ここに「完成したソフトウェアの3分の2が使われることなくムダになっている」問題の原因が見え隠れしています。

一括請負契約では、プロジェクトの最初の段階…

つまりそのプロジェクトに対して一番情報が少ない状態で、完成させるべきすべての機能要件を定義してしまいます。

そして一度定義されてしまった機能要件の数やその機能要件を実現するための技術的難易度に応じて「予算」と「スケジュール」が決定されます。

このように、プロジェクトの初期段階…

つまりそのプロジェクトに関して最も情報が少なく、習熟度の未熟な状態の中で決められた「全機能」「全予算」「全スケジュール」を頑なに順守して開発を進めることが前提になっている…

これが一括請負契約です。

しかし、このプロジェクトに関して最も情報が少なく、習熟度の未熟な状態の中で決められた機能は、本当に全て必要なのでしょうか?

最初に決めた機能…ということは、恐らくビジネス上の課題解決に貢献してくれるだろうという「仮説」にすぎません。

しかもそのプロジェクトに関して最も情報が少なく、習熟度の未熟な状態の中で決めたものなので、その仮説が誤っている可能性は極めて高いでしょう。

そんな信頼性の低い仮説の中で決められた機能を、全て完成させたとしても、本当にそれらの機能がビジネス上の課題解決に貢献するでしょうか?

その答えが、冒頭に申し上げた「ソフトウェアの3分の2の機能はほとんど使われていない」に帰結しているのです。

つまり、最初に決めた機能で実際にビジネスに貢献しているのはたったの2割。そして45%は全く使われておらず、19%の機能はほとんど使われていないという結果になります。

 

システム開発プロジェクトを新ビジネスに例えると…

この最初に「全機能」「全予算」「全スケジュール」を固定してプロジェクトを開始するスタイルは、新しいビジネスを立ち上げるプロジェクトに当てはめて考えると、極めて不都合なことが多いということがわかります。

例えばあなたがこれから起業して、新しいビジネスをスタートするとしましょう。

その時、起業時点で思い描いている完成状態の「全人員」「全予算」「全スケジュール」を完ぺきに予測することができるでしょうか?

もし完ぺきに予測できたとして、その予測にはどれだけの信ぴょう性があるでしょうか?

もちろん、限りある資本金をどの様に使ってビジネスを組み立てるか、それをどのような計画で遂行していくかの青写真は絶対に必要です。また、もしあなたがそのビジネスを立ち上げるために、銀行や公的機関から最初の事業資金の融資を受けるとなると、事業計画書が必要になります。

しかし、その最初につくった青写真や事業計画通りにビジネスが立ち上がっていくことはまずありません。特に昨今は、従来の延長線上にあるようなビジネスではなく、あまり前例がないような新しいビジネスに挑戦しなければ他者との差別化ができません。

なので、最初の計画はもちろん必要ですが、その最初に立てた計画通りに仕事をすすめるのではなく、計画をもとにした行動からのフィードバックを受けて、柔軟に計画を変更しながらビジネスを立ち上げていくことになります。

しかし、これを一括請負形式に当てはめると、プロジェクト内で最初につくった計画…つまり完成の定義と、実際のビジネスで起きていることにどれだけ大きなギャップがあっても、原則として最初に合意した完成の定義を満たすことが優先されます。

何故なら、その最初に合意した完成の定義を満たすソフトウェアを完成させることが、契約上のゴールになっているからです。

私が、ソフトウェア開発プロジェクトと新ビジネスの立ち上げを重ねたのにはわけがあります。

今、ビジネスとITは不可分…つまり分けられない時代です。

何か新しい事業、何か新しいビジネスを立ち上げようとした時に、全く情報システム投資無しでそれを実現することはほぼ不可能でしょう。

それだけビジネスと情報システム投資は切っても切れない関係になっています。

そして新規ビジネスの立ち上げは「予測不可能な事」の連続です。

つまり新しいソフトウェアの開発プロジェクトも「予測不可能なこと」の連続ということです。

これだけ不確定要素の高いプロジェクトにもかかわらず、最初に合意した完成の定義をただ満たすことだけに邁進することが目的の一括請負契約では、「ビジネスに貢献するソフトウェア」を手にする確率は極めて低いものになるでしょう。

そしてその大きな困難によってもたらされたソフトウェアの3分の2は、ビジネスに貢献しないという結果をもたらします。

さて、すこし長くなってきたので、ここまでの内容を一度まとめましょう。

  • 完成したソフトウェアの3分の2はビジネスに貢献していない。
  • その原因は一括請負形式という契約方法にある。
  • 一括請負形式は、情報が最も少ない初期段階で全機能を定義し、そして固定化する。
  • しかし、この固定化した全機能が全て有益に機能するか否かは仮説に過ぎない。
  • しかも、プロジェクトの初期段階で立てた仮説なので、その確証は極めて低い。
  • その結果が、完成した機能の3分の2はビジネスに貢献していないという結果である。

このように、一括請負形式の前提となっている「最初に全部を決めてしまわないと前に進めない」という構造的な特徴が、ビジネスに貢献しないムダな機能を作りこんでしまう温床であるというのが私達の考え方です。

 

ムダな機能を作りこまないための具体的な手法

それでは具体的に、この大いなるムダを生まないためにはどのような手法を用いればよいのでしょうか。

私は、新規ソフトウェア開発プロジェクトも、新規ビジネスの立ち上げと同じように、仮説と検証を繰り返しながら、らせん状に成長させていくことが、結果的に一番リスクが低く、そして何よりも完成した機能の3分の2は使われないといった大いなるムダを抑制するための最も重要なアプローチだと考えています。

つまり、最も価値が高く、そして最もビジネスに貢献する機能のみを最初に完成させ、そしてそれを実際のビジネス環境下で利活用いただく。

その結果から得られたフィードバックを受けて、次に必要な機能を追加開発し、少しづつシステムを成長させていく。

このようなアプローチを実践することで、ムダな機能を作りこんでしまい、不必要な費用と時間が消費されてしまうことを抑制しています。

また、一度に開発する機能は概ね1〜2ヶ月、どんなに長くても3ヶ月以内でで開発可能な機能をターゲットとします。

さらに私たちは、この1〜2ヶ月の開発期間を、さらに1〜2週間単位に分割します。

そして、1〜2週間毎に「実際に動くソフトウェア」を使って、お客様と共に機能の過不足や品質を確認しながら、開発作業を進めていきます。

伝統的なソフトウェア開発手法のように「設計書」や「仕様書」を確認しながら合意形成をはかるという方法は取りません。

なぜなら、具体的に動くソフトウェアを用いて対話を重ねながら合意形成をはかるほうが、よりお客様の望む…

そして何よりビジネスに貢献する機能を最小限の時間とコストでご提供することが可能だからです。

実際、私達のお客様には全てこのアプローチをとっていますが、ムダに作りこんでしまった機能はほとんどありません。

また、完成したソフトウェアのビジネス貢献度は極めて高く、ソフトウェアの導入効果を示す計数(KPI:Key Performance Indicator)にも如実に現れるほどです。

 

弊社のお客様の事例

例えば私達のお客様で、物流業務の効率化を計画されているお客様がいらっしゃいました。こちらのお客様は当初、一般的なソフトウェア開発のように、物流業務全体を最適化するための包括的なシステムの導入を検討されていました。

しかし、数社のシステム開発ベンダーに見積り依頼をしたところ、最初の機能を洗い出す「要件定義」と呼ばれるフェーズだけで数千万の見積もりが提示されました。

この金額ではとてもシステムの導入はムリと諦めかけている時に、弊社にお声がけいただきました。

私はそのお客様に、「解決したい課題はたくさんあると思いますが、それに優先順位を付けて、何をどういう順番で解決することが、よりビジネス上の利益になるか考えましょう」とご提案しました。

こうしてお客様と対話を重ねた結果、数ある問題の中でも最も解決したい問題は「配送ミスの撲滅」となりました。

私達は、まずその配送ミスを抑制するためのソフトウェアを2ヶ月で完成させ、そしてリリースしました。

結果、システムリリースの当日から「配送ミス」はピタリと止まりました。

そしてこの記事を執筆時点で、システムリリースから数ヶ月が経過していますが、その間もこの「配送ミスゼロ」の記録は更新され続けています。

この成功を受けて、こちらのお客様とは「配送ミス撲滅」の次に解決したい問題に対応するための機能を開発し、その1ヶ月後には、また新しい機能をリリースしました。

このように、私達はシステム全体を細かく分解し、ビジネス貢献度という視点から重要性の高い機能から順に開発しリリースしていきます。

そして、実際のビジネスで利活用いただき、そこからの具体的なフィードバックを受けて、次の開発スケジュールを立て、そして実際に開発し、そしてリリースして実際に利活用いただき、またそこからの具体的なフィードバックを受け…というサイクルでプロジェクトを進めていきます。

成功の要因はP.D.C.Aサイクルを確実に回すこと

このアプローチは、業務改善活動等に用いられる「P.D.C.Aサイクル理論」にもとづいています。

PDCAサイクル(PDCA cycle、plan-do-check-act cycle)は、事業活動を円滑に進める手法の一つで、Plan(計画)→ Do(実行)→ Check(検証)→ Act(改善)の 4 段階を何度も繰り返すことによって、業務プロセスを継続的に改善するフレームワークです。

そして私達も、このP.D.C.Aサイクルの考え方に習い、仮説と検証を繰り返しながら、ソフトウェアを継続的に成長させていくことが、ビジネス貢献度の高いシステムを確実にお客様に届けるための最も確実な方法であるという考え基いて、このようなアプローチを実践しているのです。

 

一括請負形式では「らせん状にシステムを成長させていく」アプローチが取れない

私たちは、この仮説と検証を繰り返しながら、「らせん状にシステムを成長させていく」アプローチをとるために、一括請負形式での契約は行っていません。

全てが「準委任」と呼ばれる契約方法をとっています。

なぜなら、完成したシステムを納品することが義務となっている一括請負形式では、この「仮説と検証を繰り返しながららせん状にシステムを成長させていく」という手法が取れないからです。

一方準委任契約というのは、ソフトウェアを完成させる義務は追っていません。

この順委任契約は、ソフトウェアの完成が目的ではなく、契約で合意した内容を実現するための作業を遂行することを目的とする契約です。つまり、結果を確約できないような類(たぐい)の仕事を外部に委託する時に使われる契約形態です。

一括請負契約を締結しようとした場合、完成したシステムの納品が前提となっているので、まず「完成基準」を定義しなければなりません。そして一括請負形式では、この完成の定義が満たされてはじめて、私達ソフトウェア開発者はお金をいただくことができます。

しかし、このらせん状にシステムを成長させていくというアプローチでは、最初にシステムの完成状態を定義することができません。そもそも私たちは、プロジェクトの初期段階という、そのプロジェクトに対して最も情報が少なく、そして学習の習熟度が最も低い状態で完成を定義し、そして固定化してしまうことが、完成したソフトウェアの3分の2をムダにしている根源だと考えています。

私達は、仮説と検証を繰り返しながら、ソフトウェアをらせん状に成長させていくことが、ビジネス貢献度の高いシステムを確実にお客様に届けるための最も確実な方法であるという考え基いてサービスをご提供しています。

結果、一括請負形式による契約を締結することは不可能なので、準委任契約を締結してサービスをご提供しています。

 

準委任契約によるデメリットは予算とスケジュールが見えないこと

このように「ソフトウェア開発に関連する全ての仕事を準委任で請け負っている」というお話をすると、必ず出てくる質問があります。

それは、準委任だと予算とスケジュールが確定できないので、社内で稟議上申できないというご質問です。

私達は、この問題に対して「経営トップが率先してバジェットキャップ(予算制限)を設けるようにしましょう」そして、「予算とスケジュールのコントロールにもP.D.C.Aサイクルを導入して細かく仮説と検証を繰り返すことで、ムダな費用と時間の発生を抑制しましょう。」とアドバイスするようにしています。

一般的な企業におけるIT予算の決め方は、まず最初に情報システム部門が中心となって各部署からの要望を拾い上げ、それに必要な開発費用を数社のベンダーから見積もりを取得します。

その後、その見積内容を評価して、アウトソーシングするベンダーを決定して予算枠を確保するという手法を取ります。

しかし、私たちはこのボトムアップ型のアプローチを明確に否定します。

そもそもこの考え方は、例えば自分で家やクルマなどの高額なものを購入する時に当てはめると非常におかしなことが解ります。

多くの人は、車を買う時も家を買う時も、まず最初に「予算」を確定し、その予算内で、最大限自分の要求を満たすものを購入します。つまりまず予算ありきということです。

私達も、IT投資に関してはまず予算ありき。

そしてその予算内で、最大のリターンを得るためにはどうすればよいのかを考え、それを仮説と検証を繰り返しながら最適化していくことが重要だと考えています。

この考えに基いて私たちは、経営トップが財務諸表の数字をもとにトップダウンで予算上限を最初に決定するようにアドバイスしています。

バジェットキャップの決め方

この時、経営トップが基準となるIT予算枠を決める目安が必要になります。

まず、日本企業における売上高のIT予算比率は概ね1〜1.5%程度と言われています。

そうすると、売上高に対するIT予算枠の比率の目安は簡単に算出することができます。

そしてさらに、この算出された予算枠の80%を実行可能なIT予算枠として固定してしまいます。

経営トップは、何があってもそれを超える予算は絶対に承認しないようにします。

これがバジェット・キャップ(予算制限)です。

このバジェットキャップは基本的に何があっても超えることは許されません。

あくまでもこの予算内で、最大のリターンを得るためにはどうすればよいのかを、経営トップとシステムの利用部門が真剣に議論し、投資計画を策定します。

この時、経営トップは利用部門や情報システム部門に「何に投資をすれば最大のリターンを得られるか」の計画立案を丸投げしてはいけません。あくまでも、経営トップがイニシアティブを取って、投資計画を策定することが重要です。

投資計画が立案できたら、2〜3ヶ月毎に、この計画の実行状況を振り返り、投資計画の見直しや更新を行います。

私達が行っているPDCAサイクルに基いたシステム開発プロジェクトを実践していれば、少なくとも3ヶ月後には大なり小なり何らかの具体的な結果が現れています。

その結果は、「システム開発の進捗率が◯◯%」といった抽象的なものではなく、どんなシステムが完成し、そのシステムがどんな効果をもたらしているかといった具体的な結果です。

経営トップと利用部門は、お互いに相互協力しながら、その具体的な結果からのフィードバックを受けて、投資計画を見直します。

当然この時にも、最初に決めた予算上限は超えないことを条件に計画の見直しを行います。

このようなアプローチを取ることで、準委任契約にある「予算とスケジュールが見えない」というリスクを回避することができます。

そしてこちらも私達が実践しているPDCAサイクル理論に基いた予算コントロールの方法なのです。

何のために予算とスケジュールを策定するのか?

そもそも予算とスケジュールは何のために策定するのでしょうか?

それはリスクコントロールのためです。

予算とスケジュールを策定することはリスクコントロールのための手段です。予算とスケジュールを策定させることそのものが目的ではありません。

つまり、会社の貴重な事業資金と時間がムダに消費されてしまうかもしれないという「リスク」をコントロールするための手段だということです。

準委任契約はリスクが高い契約方法と思われがちですが、そのリスクはこのような手段でコントロールすることができます。

もちろん、この考え方を受け入れられる企業はそれほど多くはないでしょう。

多くの企業においてIT投資は、未だに一般的な「設備投資」と同列でみられてしまいます。

そのために、調達部門や購買部門のチェックが入り、◯◯◯万円以上の費用がかかるものに関しては、最低3社以上の相見積もりを取ること…といった購買管理規程があり、ソフトウェア開発プロジェクトに関しても、この購買管理規程が当てはめられることがほとんどです。

しかし、この記事をここまで読んでいたたいたあなたであれば、情報システム投資が一般的な設備投資とは異なる類の性質を持つことをよくご理解いただいていると思います。

私達は新しいお客様と取引をスタートする時に、この記事の内容をお客様に正直にお話します。

その結果として、「購買管理既定」の壁を超えることができず、取引に至らないケースもございます。

しかし多くの場合、私達が推奨するPDCAサイクル理論に基いたシステム開発手法を用いるのであれば、準委任契約以外不可能であることをご理解いただけます。

そして、この方法論の有効性をご理解いただくと、窓口となるご担当者様が熱心に社内調整をいただき、時には経営トップを説得してまでお取引にいたるケースがほとんどです。

私達は、このPDCAサイクル理論に基いたシステム開発手法に絶対的な自信を持っております。

その証拠に、この理論を取り入れるようになってからの失敗プロジェクトはゼロです。

そして何よりもありがたいのが、お取引に至ったほとんどのお客様から、継続的なお仕事をいただいている顧客満足度の高い方法論だからです。

この継続的にお仕事をいただけているということが、たとえ準委任契約であったとしても、リスクコントロールの不安がない何よりの証拠だと思います。

まとめ

この記事では、情報システム投資に潜む大きなリスク…

完成したソフトウェアの64%はほとんど、もしくは全くビジネスに貢献していないという問題提起、そしてその問題が起こる根本的な原因と、それを解決するために弊社で実践している具体的な手法についてご説明してきました。

この記事でご説明してきたシステム開発手法は、一般的に「アジャイルソフトウェア開発手法」と呼ばれています。

このアジャイルソフトウェア開発手法。

欧米ではあたり前のように用いられている手法ですが、日本ではまだまだ普及していません。

それはこちらの記事でも指摘した「一括請負契約の常識」からまだまだ抜け出せていないことが原因です。

一方、この問題をいち早く察知し、新しい考え方を柔軟に取り入れて新たな一歩を踏み出した企業は次々に情報システム投資を成功させ、企業の情報システム基盤を確固たるものに強化しています。

そして、私達がご支援させていただいているお客様も、この手法を使って次々に成果を上げられています。

しかし、やはり従来の方法ではない新しい考え方なので、この手法をすぐに受入れることは難しいでしょう。

恐らくこの記事を最後までお読みになっていただいたあたなも、もしかしたらこのように思われているかもしれません。

「そうは言ってもうちの会社は古い体質だからな…」

「新しい動きを見せると上からも横からも叩かれる…」

「うちの会社じゃ絶対無理だな…」

その気持ち、わかります…

私も10年以上、社内の情報システム部門で予算を上申する仕事をしていました。

なので、この考え方が一般的にはなかなか受け入れがたいということは十分に理解しています。

そして弊社にお問い合わせいただくお客様も、担当者としては「ぜひこの方法でやりたい!」と思っていながらも、社内の状況を考えると、とても提案できるような状況ではない…

皆さんそのようにおっしゃいます。

そういった時に有効なのが、「具体的な成功事例を提示する」という方法です。

このページの最後に、私達が過去に手がけたアジャイルソフトウェア開発プロジェクトの具体的な成功事例をご紹介する無料のプレゼント動画のご案内があります。

まずはそちらをご覧いただき、具体的な成功事例を感覚として掴んでください。

またこちらの動画には、ソフトウェア開発プロジェクトを成功させるための様々なヒントを散りばめています。

このヒントは必ずしも、アジャイルソフトウェア開発に限ったものではなく、どのような開発プロジェクトにもあてはまる定石のヒントです。

ぜひ、このページの最後にご案内している無料のプレゼント動画を今すぐお受取りください。

  • このエントリーをはてなブックマークに追加

Warning: extract() expects parameter 1 to be array, bool given in /home/rsc2017/risingsun-system.biz/public_html/wp-content/themes/xeory_extension/lib/functions/bzb-functions.php on line 299

無料プレゼント動画

 

「アジャイルソフトウェア開発の概要はわかったので

具体的な事例を知りたい。」


そう思ったことはございませんか?

私達は数年前から、アジャイル開発プロジェクトに取り組み

短期間で顧客満足度の高いシステムを構築してきました。

この無料プレゼント動画では

納期の3週間前には全ての開発を完了したという

非常に成功したアジャイル開発プロジェクトの


実践事例をご紹介します。