システム開発での上流工程と下流工程の違いと求められるスキルとは

The following two tabs change content below.

ITプロクラウド編集部

編集長は、ITプロパートナーズCTOの柳澤雄也。 10年以上プログラマとして活動し、国内外含め様々なプロジェクトを統括した後にITプロパートナーズにジョイン。 自分の人生の主導権を握った生き方をする人を増やすべく、日々奮闘中。
ITプロクラウド編集部はみなさんの事業開発に役立つ情報やノウハウをお届けします! ■PIECE https://crowd.itpropartners.com/piece/
■Morinig Pitch登壇 http://morningpitch.com/startups/11572/

こんにちは!

ITエンジニア・webディレクター・webデザイナーなどのIT人材の自立・キャリアを支援するITプロパートナーズのCTOの柳澤(やなぎさわ)です。 弊社は、独立精神旺盛な優秀なエンジニアの方々の独立・起業サポートや、フリーランス支援を行っている会社です。

こちらの弊社運営サイト、「スタートアップ開発ラボ STaP(スタップ)」では、企業の新規事業開発担当者の方や、システム開発責任者の方、事業責任者の方達に向けて、事業開発のコツや、自社プロダクトやWebサービスを立ち上げる際にポイントや注意点について、弊社ノウハウを包み隠さずにお伝えしています。

さて、今回はシステム開発についてです。

システム開発の話題をするとき、よく「上流工程」という言葉が出てきます。

Webサイト作成を含めて、システム開発のステップは大きく分けて上流工程と下流工程に分けられますが、下流工程よりも上流工程の方が重視される傾向にあります。

なぜ、上流工程がより重視されるのか、今回は確認していきましょう。

【システム開発の流れ】上流工程と下流工程って?

システム開発全体の流れ

システム開発における上流工程を確認していく前に、システム開発の各ステップを確認していきましょう。

システム開発の各ステップの呼び方は、会社や資料によって多少の表現などに差異がありますが、一般的に良く使われる開発のV字モデルでは、大きく分けて、

  • 要求分析
  • 要件定義
  • 機能設計
  • 詳細設計
  • コーディング
  • 各種テスト
  • 納品

以上のように分かれます。

システム開発における上流工程とは

このフェイズのうち、要求分析、要件定義、機能設計までを上流工程と呼ぶことが多いです。

それぞれどういったステップかを上から順番にお伝えします。

①要求分析

最初の要求分析とは要求を分析する、つまりこんなシステムを作って欲しいと思っています、というのをはっきりさせるステップです。

漠然と「良いシステムが欲しい!」と言われても開発する側が困ってしまいます。

そこで、こんなことができると嬉しいだとか、現在使っているシステムのここが使いにくい、といったことを具体的に整理し、どういったシステムを欲しているのか、誰が見ても分かるドキュメントを作るステップです。

この誰が見てもどんなシステムが欲しいのか分かるドキュメントは、システム発注側、システム開発側双方が合意する必要があります

でないと、発注側と開発側の間で認識がズレてしまい、思い描いていたものと納品されたものが全く異なっていた、という事態になってしまいます。

②要件定義

次の要件定義とは、要求分析で出てきた要望をもっとシステム的に具体化するフェイズです。

例えば、現在利用しているシステムのレスポンス(応答時間)が遅いので改善して欲しい、という趣旨の記載が要求分析にあったとしましょう。

要件定義では現在のレスポンスタイムを調べ、その妥当性を検討した上で、新システムではレスポンスは現在のシステムの三分の一以下にする、といった風に表現されます。

また、要件定義には要求定義で出てきた「あると便利な機能」について、本当に実装するべきかどうか確認するステップという側面もあります。

要求全てを実装し、システムで実現できれば良いですが、予算の兼ね合いなどから難しいかもしれません。

どの機能をシステム化するのか検討し、必要性が認められた機能のみ、要件定義の結果をまとめたドキュメントとして、要件定義書で表現するのです。

要件定義書もシステム発注側、システム開発側双方が合意する必要があります。

③機能設計

三つの機能設計とは、要件定義で実装することが確定された機能について、詳細を固めるステップです。

ショッピングサイトの会計機能は、ユーザーから見るとどのサイトも同じように見えますが、実は在庫管理の仕組み、カード会社や銀行口座との連携部分でショッピングサイトごとに異なる仕掛けがあります。

この仕掛けはショッピングサイトの運営会社ごとに異なるので、よくよく発注側と開発側とで内容を詰めておかないと、「使えないシステム」になるリスクがあります。

システム開発のV字モデルにおいての上流工程ステップは以上ですが、案件を進めるうえでもっと重要な要素があります。

それは、計画立案と構成管理です。

システム構築以前を行う前に、そもそも企画としてのシステム開発の計画を作成し定めることが必要。

システム開発を行う事になった経緯やスケジュール感、予算などが明らかになっていないと、システム開発は始められません。

システム開発における下流工程とは

では上流工程と対となるシステム開発の下流行程とはどういったものか簡単に確認していきましょう。

下流行程のステップの一つ目はコーディングです。つまり実際にシステムを構成するプログラムを作っていくステップです。

次の各種テストとは、システム作成途中での各ポイントで行われる単体テストシステムテストのことです。

単体テストとは、コーディングで作成されたシステムのパーツたるプログラムの確認テスト。

システムテストとはプログラムを組み合わせて、システムに求められている機能が提供できるかの確認です。

そして開発側の確認が終わり、システムに問題がなければいよいよ納品です。

通常、納品時に発注側が主体となって受入テストが行われます。

受入テストでは、システムが想定通り動くかの確認はもちろん、設計の段階で作られたドキュメントや取扱説明書などに問題がないか、そして受注側の要望通りの使いやすいシステムになっているかを確認します。

場合によっては修正が行われることもあります。

さて、次にシステム開発の上流工程がなぜ重要なのかについて見ていきましょう。

システム開発の上流工程がなぜ重要なのか?

簡単に言ってしまえば、下流行程は実際にシステムを作る段階なのに対し、上流工程はシステム開発の方針を決める段階です。

従って、上流工程で定めた方針に瑕疵があると、その瑕疵が原因となってシステム開発に難航し、スケジュールが遅延していくかもしれません。

また、開発側と受注側の認識に相違があることに気が付かないまま下流行程へ突入すると、完成したシステムが思っていたものと異なり、使い物にならないという事態になってもおかしくないです。

上流工程に失敗したシステム開発は、プロジェクト全体が失敗へと進む可能性が極めて高いといえます。

上流工程に失敗するとシステム開発が紆余曲折し、失敗する可能性が高いことをお伝えしましたが、具体的にはどういったリスクがあるのか整理します。

上流工程が引き起こす可能性のあるリスク

要件定義のミス

まず要件定義の段階でミスがあり、後から実装機能の追加や、機能の動作修正を行った結果、追加費用が発生するリスクです。

当初予定になかったものを追加するとなると、それだけ労力が増えるわけですから、当初予定より時間がかかったり、その追加実装をコーディングするITエンジニア分、当初より人件費が増加するかもしれません。

機能追加によるバグ

また一度、機能の追加を認めると、後から後から機能の見直しを求められてシステムの構成が奇々怪々になり、結果、バグが大量に包含されたシステムになってしまい、納品できる、できない、という話になることもあります。

システム開発に関係する訴訟問題の多くが、このような経緯で事実上開発に失敗してしまったプロジェクトの発注側と開発側の費用負担の問題で争われます。

では、なぜ上流工程で失敗してしまうのでしょうか?

上流工程でこける最大の理由

結論から言えば、上流工程が上手くいかなかった原因は、関係者のコミュニケーション不足によるものです。

システム開発側とシステム発注側のコミュニケーション不足だけでなく、システム発注側内部の発注部署とシステム利用部署・ユーザーとのコミュニケーション不足も考えられます。

前者の問題は下流行程でも影を落とし、進捗スピードの低下や行き違いとなるかもしません。

後者の問題は、システム納品後、実際の利用者が思っていたのと異なっていた、という問題に繋がることでしょう。

システム開発側が発注側のことを素人だと思って邪険に扱うことなく、どういったシステムを求めているのか親身になって密に確認することも大切ですが、発注側も素人だからと開発する側に任せておくがままにしないことが重要です。

そのためには、発注側もシステム開発において必要なことを理解しておくことが非常に重要なのです。

そんなシステム開発の上流工程を成功させるために必要なスキルを5つ紹介します。

システム開発の上流工程を成功させる4つのスキル

顧客のニーズや要望を引き出すヒアリング能力(コミュニケーション能力)

上流工程では、顧客とコミュニケーションをとる機会が数多くあります。

そして、そのコミュニケーションの不足が、システム開発の失敗を招いてしまうと言うのは先ほどもお話ししました。

そこで、上流工程担当者にとって必須なスキルは、顧客の要望やニーズをうまく引き出すヒアリング能力、コミュニケーション能力です。

多くのクライアントは、開発側の業務を理解することが難しく、どのようなシステムが欲しいのか、理想なのかを漠然としたイメージで伝えることができません。

そんな中で、クライアントの想定しているであろうシステムを、話しを聴きながら自分でイメージし、ある程度形にする必要があります。

さらに、相手はエンジニア用語とは無縁な世界でビジネスをしている場合も多いので、専門用語をなるべく使わず、わかりやすく説明をする必要もあります。

ドキュメント作成スキル

上流工程の段階では、様々なドキュメントを作成する必要があり、そのドキュメントはそのプロジェクトにおいて大変重要な役割を担います。

具体的には、要件定義書、詳細設計書などがあり、そのプロジェクトを推進するための道しるべとなります。

そのドキュメントは、誰がみても、どんな時に見ても理解できるような構成と文章で作成しなければいけません。

例えば、目次を作成して、一目で自分の情報がどこにあるかわかる構成にしたり、5W1Hを意識して文章を作成したりと、簡単なところから始めるだけでも、見違えるドキュメントを作成することができます。

要件定義の進め方については以下の記事をご参照ください。

できる人はやっている要件定義の進め方とは?

マネジメント能力

上流工程になればなるほど人は少なく、下流工程になればなるほど、メンバーは多くなります。

そして、その下流工程に携わる人たちを取りまとめるのも、上流工程に関わる人の役割であり、必要なスキルです。

チームとして動き成果を上げるためには、チームワークもそうですが、個々あってのチーム力ですので、一人一人の仕事に対する意識とその働く環境などが重要。

メンバー同士がいがみ合ったり、尊重し合えない環境では、良い成果はあげられませんし、意識も低くなってしまいますよね。

その環境を整え、メンバーの意識を高く維持させるチームマネジッメント能力は必須でしょう。

キャッチアップ能力

先ほども述べましたが、上流工程担当の人は、多くのクライアントと話す機会があります。

その人たちは、医療業界だったり、ファッション業界だったりと様々です。

そんなクライアントに対してヒアリングや、コミュニケーションをとっていく上で、ある程度クライアントの業界を理解する必要があります。

そうすると、ヒアリングも楽ですし、想定しているシステムの想像もしやすくなりますし、システム開発の成功に繋がるでしょう。

まとめ

今回はシステム開発における上流工程の重要性を見ていきました。どんなことでも最初のゴール決めが重要です。

ゴールが定まらないまま走りだすと、いつまでたってもゴールインできません。

上流工程の成否がシステム開発の成否を左右すると言っても過言でもありません。本当に上流工程は重要です。

この記事が皆様のお役に立てば幸いです。

ABOUTこの記事をかいた人

編集長は、ITプロパートナーズCTOの柳澤雄也。 10年以上プログラマとして活動し、国内外含め様々なプロジェクトを統括した後にITプロパートナーズにジョイン。 自分の人生の主導権を握った生き方をする人を増やすべく、日々奮闘中。
ITプロクラウド編集部はみなさんの事業開発に役立つ情報やノウハウをお届けします! ■PIECE https://crowd.itpropartners.com/piece/
■Morinig Pitch登壇 http://morningpitch.com/startups/11572/