システム開発のスピードアップのために発注側ができること【2024年最新版】

システム開発の外注を考えたとき、どのくらいの期間で納品してくれるのかという「開発のスピード」はとても重要です。
IT投資の本質は、ライバル企業に先駆けて現在の業務を効率化したり創造的にしたりすることです。
「断固としてIT投資を行うのだ」という意思決定が迅速にマネージメント層で行われたとしても、納品までに数ヵ月あるいは数年もかかってしまうようなシステム開発では、その間にライバル企業との差は開く一方です。

開発スピードの向上というと、プログラミングのスピードを向上させるなど、すべて開発会社の責任と考えてしまう発注者も多いのですが、実は発注側にも工夫できることはたくさんあります。
それどころか、きちんとした開発意図を発注者が開発者に間違いなく伝えることこそが開発のスピード向上のカギであると言えるでしょう。

さらに、素早い市場の変化やライバルの動向にスピーディーに対応できる開発体制こそ、今日システム開発に求められている重要なポイントだと言えますが、こうした対応は発注者の協力なしには実現できません。

この記事では、開発スピードの向上について発注側でも貢献できることがらを洗い出し、開発会社と良好な関係を維持しながら開発を進めるコツについてお伝えします。

企業活動において、「戦略」を「戦術」に落とし込み、トップマネジメント層の意思決定を素早く現場レベルで実行することは非常に大切です。
IT投資で言えば、取締役会などでの「経営戦略」の決定が素早く「システム部門」において実行に移されることが大切になってきます。

経営トップ層がIT投資の必要性は理解しながらも、具体的な戦略を明確化できず、現場のシステム部門はどのように新しい業務システムの中身を詰めていったらよいのかが分からないという状況にある企業は少なくありません。
こうした状態で開発会社との打ち合わせに臨んだとしても、開発会社からのヒアリングに対して「そうですね…上の意向を確認してからまた改めてご連絡いたします…」という発言を繰り返してしまうことになります。

この場合、システム開発プロジェクトで現場の「システム部門」に過剰な負担がかかってきます。
システム部門では、トップマネジメント層がビジネスプロセス・リエンジニアリングなどの、業務の本来あるべき理想の姿をしっかり検討してくれないので、現行の業務システムの効率化に目が行きがちになります。それでは現行のシステムに引きずられる形でプロジェクトの目的がはっきりしないままに、開発会社との打ち合わせが進んでいかざるを得ません。

結果として、開発会社としても抜本的な開発提案がしにくくなり、現状のシステムに新規のシステムを上乗せするような、まさに「屋上屋を架す」非効率なシステム開発が進行していくことになります。

こうならないためには、開発会社との打ち合わせに臨む前段階で、「トップマネジメント層」と「システム部門」の連携体制を整えておくことが大切です。

発注担当者の方は意外に思うかもしれませんが、開発の主役はあくまでも発注者です。
もちろん、実際にプログラムのコーディングを行ったり、細かなプログラミング上のテストを繰り返したりしていくのは開発会社の現場の技術者たちですが、システム開発の目的に沿ってプロジェクトが滞りなく、正しい方向に進んでいるかをチェックするのは発注者側の責任だということを肝に銘じましょう。

そのためには、システム開発がどのような体制で行われていくのかについても、概略を知っておく必要があります。

システム開発はこれまで、ウォーターフォール型という滝の流れが一方向に流れるようなイメージで、設計から開発、最終テストまで一気に行ってしまう形がとられていました。

このタイプの開発の場合には、初期段階のヒアリングでは発注者と開発会社の打ち合わせの機会なども多くありますが、次にじっくり顔を合わせるのは納品直前の「受け入れテスト」の段階である、といったことになります。

途中段階で試作品をチェックしながらプロジェクトを進めたいという場合には、開発会社に「プロトタイプ型開発」「スパイラル型開発」や「アジャイル型開発」などの採用を働きかけたほうがよいでしょう。

途中の段階で、こまめに開発会社と接触をして開発ステップを確認していけば、最後に「こんなものは頼んでいない！ やり直してくれ！」というような最悪の事態を避けることができますので、結果的に納品までの開発のスピードアップにもつながります。

開発のスピードアップのためには、余計なことは言わずに開発の専門家に任せるという態度ではなく、むしろ逆に「発注者側が開発をリードしていくのだ」という心構えが必要になってくるのです。

では具体的にはどのように発注者側が開発をリードしていくかですが、まずは開発会社の現状について発注側でも最小限のことを理解しておく必要があります。

従来のシステム開発では、先程述べたようにウォーターフォール型という、滝の流れが一方向に流れるようなイメージで、設計から開発、最終テストまで一気に行ってしまう形が主流でした。

このタイプの開発は市場の変化が緩やかで、業務革新のスピードものんびりしており、ライバルの動向などをさほど気にすることもなかった時代には適していました。

例えば、数十年前においては、業務処理にコンピュータを入れるということが、それだけで革新的なことであり、SFAだ、CRMだといった業務プロセスの内容にまで踏み込んで高度なシステムを組んでいこうという空気すらありませんでした。

こうした時代には、コンピュータを使った業務システムを導入すること自体が他社に対する差別化であり得たので、標準的な業務システムを一気に作ってしまうというウォーターフォール型の開発スタイルが有効だったのです。

ところが現在では、市場や顧客ニーズの変化スピードが加速し、ライバル会社も単にコンピュータを導入するだけでは満足せずに、他社に先駆けて先進の業務システムを導入することで差別化を図ろうとしています。

そのような時代において、ありきたりのシステムを設計して人海戦術でプログラミング作業をこなしていくというスタイルは限界を迎えています。

この状況を正確に理解していないと、開発のスピードアップに関してついつい人海戦術の徹底や作業の自動化をイメージしてしまいます。

しかし、下記のようなスピードアップは、開発側が生産性を上げるための努力に過ぎず、発注者側にとって本質的な意味を持つものではないので、誤解のないようにしておきましょう。

現在のシステム開発で求められているのは、こうした旧時代の「労働集約型の開発スピードアップ」ではありません。
より早く市場のニーズの変化やライバルの動向を読み取り、素早く状況に対応しながら開発を進めていく「知識集約型の開発スピードアップ」が求められているのです。

それでは、「知識集約型の開発スピードアップ」とはどのようなものでしょうか。

これまでのシステム開発におけるスピードアップとは、「作業効率化と機能向上」を目的としてきました。
先程も触れたように、これは開発会社側にとって必要な企業努力であって、スピードアップすることによって、人件費が削減できて開発会社の利益が大きくなるというメリットがあるものの、発注側企業にとっては本質的な価値の増大をもたらしません。

現在、発注側企業の開発の現場で求められているスピードアップでは、システム開発の領域にとどまらずビジネス開拓の領域に踏み込んだ価値の創出が期待されています。

具体的には、素早い市場環境の変化やライバルの動向に合わせて（あるいはそれを先取りするところまで踏み込んで）、その会社ならではの新しい価値を持ったシステムを、迅速に設計してリリースするということになります。
例えば、ECシステムを作るというプロジェクトの場合、商品が掲載できて、決済システムがついているというだけのシステムでは新しい価値をシステム化したことにはなりません。

市場のニーズやライバルの動向を見据えながら、商品レビューを気軽に書き込めて拡散してもらえるようなソーシャルメディア対応をしたり、価格比較機能をつけたりするなどの新しい付加価値をスピーディーに実現していくことが、これからの時代、求められているのです。

発注側が、素早い市場環境の変化やライバルの動向に合わせて開発のスピードアップを開発会社に要求していくためには、発注側の責任体制の明確化が必須となります。

「知識集約型の開発スピードアップ」では、朝令暮改のような意思決定のやり直しも当たり前になってきます。
旧来の価値観で言うと、いったん決定したことは実現できるまで担当者がやり抜くというのが常識ですが、市場環境の変化やライバルの動向によっては、決定したことを短期間のうちにくつがえして、より実情に沿った意思決定をやり直すことも必要になってくるのです。

そうした場合にポイントとなるのが、権限を持った上席の人間が、責任を持ってプロジェクトの修正を行うことです。
こうした責任あるポジションの人による仕切り直しが明確に行われない場合には、現場は混乱するだけです。

新しく戦略を立て直し、新たな権限と責任を再度割り当てるということで、意思決定のやり直しもスムーズに実行できるようになることを肝に銘じておきましょう。

旧来の管理職の役割イメージでは、プロジェクトの細部の「承認」を行ったあとにその「完了」を見守るというのが当たり前ですが、「知識集約型の開発」では新しい状況に素早く適合して「判断」する管理が求められます。

「知識集約型の開発」では開発会社のプロジェクト・マネージャーの役割も変わってきます。
従来型の「労働集約型の開発」においてはいったん決まった仕様を途中で改良するという発想は基本的にありません。
したがって、プロジェクト・マネージャーに求められる役割は、決められた仕様に従ってプロジェクトが納期通りに完了するようにマネージメントすることでした。

発注側が、新しく戦略を立て直し、新たな権限と責任を再度割り当てるということで、意思決定のやり直しをした場合には、それを直ちにプロジェクト・マネージャーと共有し、開発会社側にも新しい目標を共有してもらうことが必須となります。

この意思疎通を十分にとれるよう発注者側が積極的に働きかけることで、初めて短いサイクルで品質の高いプロダクトを納品し続けるという「知識集約型」開発スタイルが可能になります。

ここで整理したプロジェクト・マネージャーとの協業体制をさらに組織論にまで拡大した「スクラム開発」という手法が注目されています。

スクラム開発とは、システム構築を反復的で漸進的に進めていくアジャイル型の開発体制のことです。
組織全体が一つの目標に向かってスピーディーかつ機能的に動いていくための方法論ですが、ウォーターフォール型開発のように、トップダウン型で目標に一直線に突き進んでいくためのものではありません。

ウォーターフォール型開発では、作業工程を「要求定義」「設計」「開発」「テスト」「運用」などの作業工程に分割し、トップダウンで進捗管理を行いますので、開発のスピードを上げるということは、個々のフェーズの能率を上げて工期を短縮するということにほかなりません。

しかし、アジャイル開発をベースにした「スクラム開発」では、素早い市場の変化やライバルの動向を見据えながら、発注側と開発側が文字通りスクラムを組んで、スピーディーな開発を行います。

「知識集約型開発」でスピードアップを図りたい場合には、外注候補先企業が「スクラム開発」を経験したことがあるかどうかもぜひ確認してみましょう。

最後に、システム開発を外注した際にかかる費用相場をご紹介します。

システム開発の費用相場をご紹介しました。より正確な費用を知りたい方は料金シミュレーターをご利用ください。

以上、開発会社の作業の効率化とは違った、発注側企業にとって本質的な意味を持つ「開発のスピードアップ」について整理してきました。

繰り返しになりますが、開発会社の内部で行う企業努力としての開発スピードアップは、発注者に本質的な価値をもたらしません。
確かに工期は短くなるものの、短時間で仕事を終えることができて労働生産性が上がり利益が増大するのは開発会社です。

発注者にとって意味のある開発のスピードアップとは、市場のニーズやライバルの動向を先取りするような革新的な価値を持つシステムをスピーディーに開発して納品してもらうことです。

この点をしっかり押さえておけば、こうした開発を実施するために、発注側企業で整えておかなければならない組織体制や、権限、指揮命令系統の明確化、プロジェクト・マネージャーとのコミュニケーションの大切さなどが理解できると思います。

「言われたとおり早く作って！」という上から目線で開発会社と付き合っている限り、本当の意味での開発のスピードアップは図れないということを肝に銘じておきましょう。

とはいえ、知識集約型開発で価値あるシステムを作り上げよう！と準備を始めた会社にとって、こうしたプロジェクトを一緒に推進してくれる最適な開発会社を見つけることが現状ではなかなか難しいというのも事実です。

そのような場合には、経験豊富で業界の評判にも精通した「アイミツ」にぜひご相談ください。
御社に革新的な価値をもたらす、スピーディーな開発を実行できるパートナー候補企業をピックアップいたします。