システム開発工程がエンジニア目線だけではダメな理由

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

IT業界に入ると必然的にシステム開発工程について学ぶことになります。

その代表はウォーターフォールモデルスパイラルモデルなどです。

それぞれ開発するシステムによって向き不向きや長所短所があるので、良い悪いはないのですが、注意しなければならない点があります。

それは、システム開発工程をどれだけ学んでもトラブル案件は減らないし、システム開発工程だけに着目しても意味がないということです。

そもそもシステム開発工程だけを見ても、IT導入プロジェクト全体から見たら一部分でしかないのです。ITベンダー企業にいるシステムエンジニアが、もっと視野を広げるために必要な観点を解説します。

一般的なシステム開発工程

最も一般的なシステム開発工程といえば、ウォーターフォールモデルです。

ウォーターフォールモデルとは

ウォーターフォールモデルとは、システムの開発手順を示すモデルの一つ。システム開発モデルとしては古典的なものである。
システム全体を一括して管理し、分析・設計・実装・テスト・運用をこの順に行っていく。

出典:IT用語辞典 e-Words

ウォーターフォールモデルはV字モデルとしても良く知られています。

V字モデル概念図 出典:ウィキペディアより

V字モデル概念図 出典:ウィキペディアより

 

ウォーターフォールモデルは、文字通り高い所から低い所へ落ちる水のごとく「滝」であり、一度落ちた水は再び上に戻ることはないということ、つまり、

  • 前の工程がちゃんと完了してから次の工程へ進む
  • 前の工程が正しい前提である

という事を意味しています。

手戻りが発生することで失敗プロジェクトになる可能性がグンと上がってしまいます。

そもそも、先の見えないモノ、完成形の見えないシステム開発において手戻りなしで最後まで行くのは至難の業です。多くのプロジェクトでは、変更管理や一部決定の先送りをしながら綱渡りのように進行していきます。

 

スパイラルモデルとは

他にも、アジャイル開発で用いられるスパイラルモデルもあります。

スパイラルモデルとは、システムの開発手順を示すモデルの一つで、システムの一部分について設計・実装を行い、仮組みのプログラムを元に顧客からのフィードバックやインターフェースの検討などを経て、さらに設計・実装を繰り返していく手法のこと。

出典:IT用語辞典 e-Words

スパイラルモデルでは、プロトタイプ(試作)を創って、そこに手を加えて完成させていきます。

ちょうどV字モデルに当てはめるとV字の谷の部分が何度も発生するようなイメージです。

ウォーターフォールモデルの弱点である手戻りに対して柔軟に対応できますが、ユーザー企業主導でプロジェクトを進めていく必要があり、実施のハードルは高くなります。

状況によって使い分けが重要

  • これからはアジャイルだ
  • ウォーターフォールは古い

このような論争もありますが、創りたいシステムによって方法は様々です。

この方法論が正解というものはありませんが、世の中のニーズはよりスピードを要求する傾向にあります。発注側ユーザー企業の要求は「とにかく柔軟に対応してほしい」というのが本音でしょう。

こうした背景によって、ウォーターフォールとアジャイル(スパイラル)を組み合わせた、ハイブリッドアジャイルという考え方も注目されています。

システム開発の方法論に抜けている観点

システム開発の方法論に抜けている観点

ビジネスでは大局的な視点が大事です。

そもそも、システムを開発して導入する過程において、主要な登場人物はだれでしょうか。

システムを発注するユーザー企業と受託して開発するITベンダー企業。主にこの2社が存在します。

本来、システム開発は両社が協力して行うものなので、ITベンダー企業だけでシステム開発工程を論じても片手落ちなのです。

ITプロジェクト全体を見れば、発注側ユーザー企業が関わる部分が沢山あるのに、ITベンダー企業の担当領域だけを見てもトラブルが減るはずもありません。

ITベンダー企業に所属していると、開発工程において発注側ユーザー企業の存在が薄くなってしまいます。

案件の受注の方法が「私たちITベンダー企業にすべてお任せください」スタイルの営業だとしたら全部をITベンダー企業が引き受け、発注側ユーザー企業は全部を丸投げ、のような錯覚に陥ります。

よく「戦略のミスは戦術ではカバーできない」と言いますが、正しい開発手順にのっとってシステム開発を進めても、思わぬ大どんでん返しでプロジェクトが窮地に立たされることがあります。

ウォーターフォールでもスパイラルでも、そもそも開発を始める下準備が整わなければ成功しようがありません。プロジェクト失敗の原因は「もっと根本的な何か」である可能性がある、ということを知る必要があります。

正しい入口から入らなければ正しい出口に到達できません。正しい入口を決める工程、すなわち「戦略」は、システム開発に入る以前の工程です。

システム開発工程は「戦術」であるという事を忘れてはいけません。

まとめ

システム開発工程を知ることは、良いシステムを創るために必要な概念ではあるものの、良いシステムを創るすべての工程を網羅していません。

従って、全体の一部分であるシステム開発工程だけに着目すると視野が狭くなります。

現場のSEであっても、プログラマーであっても、「全体を見る目」が必要です。近視眼的になると世界が狭くなり行き詰まります。

全体を俯瞰して目の前の仕事に臨む姿勢を身に付けましょう。

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

無料レポート 失敗ITプロジェクト事例集 プレゼント

誰かの「やっちまった!」が明日のあなたを救う!

通常、失敗事例は世の中に出回りません。なぜなら、失敗は忌むべきもの、隠すべきもの、として扱われるからです。
しかし、失敗の共有こそ学びの宝庫です。

意識が上がり、もっと仕事ができるようになる
「これをやってはいけない」が学べる
自分の活動に当てはめて考えることができる
歴史から学ぶ
他人の失敗から勇気をもらえる

ITプロジェクト推進に役立つスキルアップのための失敗事例集です。
ぜひ、あなたのエンジニアライフの充実のため、キャリアアップのためにお役立てください。


無料レポートをダウンロード

SNSでもご購読できます。

スポンサーリンク

コメントを残す

*