システム開発モデルから学ぶ仕事の進め方

IT人材を目指す人に実務に役立つ知識を解説する連載「使える！ITパスポート」。

今回、取り上げるのは「システム開発モデル」 です。

「システムの開発モデルなんてエンジニアではないので関係ない」と思われるかもしれません。

しかし、この開発モデルにはIT業界で積み上げられてきた、「作業を依頼する側」と「作業を依頼される側」が普遍的に意識しておくべきエッセンスがつまっています。

このモデルから、どんな業界のビジネスシーンにも通用する仕事の進め方を学ぶことができます。

システム開発手法とは

ソフトウェアが誕生し歴史が積み重なるにつれて、どうすれば効率的にソフトウェアを開発することができるのか、エンジニアたちは様々な現場で試行錯誤を行ってきました。

ここでいう効率的な開発というのは「エンジニアがいかに作業を早く済ませられるか」だけを指すのではありません。

重要なのは作業を進めるにあたって、ソフトウェアの開発を依頼した顧客など「エンジニア以外のステークホルダー」の要望を満たすことを意識している点です。

ソフトウェアはエンジニアが自分の思うように開発するだけでは完成とは言えません。ソフトウェアを使う顧客の要望が実現されていることが完成の前提条件となります。

ただ、顧客はエンジニアと一緒に作業を進めるわけではないため、会う機会も限られてきます。

その結果として、限られた時間や機会の中で「こうすればうまく開発できる！」と多くのエンジニアが思うような開発の進め方のパターンが生まれてきました。

顧客とエンジニアの関係は言ってみれば「作業を依頼する側」と「作業を依頼される側」の関係です。

これはIT業界に限ったものではなく、 企業でも家庭でも場合に応じて発生する関係です。

IT業界が積み重ねてきたシステム開発モデルを学ぶことで、作業を依頼する側・される側の両者が意識すべき仕事の進め方を学ぶことができます。

以下に代表的な開発モデルを3つ紹介します。

代表的なシステム開発モデル

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

この手法は必要な工程をひとつずつ段階的に進めていきます。

要するに「最初に綿密な計画を立てて、後は計画通りに作業を進める」というやり方です。

何か一定の時間がかかりそうな作業に取り掛かるときに、多くの方が採用するのがウォーターフォールモデルなのではないでしょうか。

最初に計画を立てて、その通りに作業を行い、最後にテストをして完成という流れです。

この手法を採用するときのメリットとデメリットは以下の通りです。

このモデルは作業を依頼する側と依頼される側のコミュニケーションが最も少なくなる仕事の進め方です。

作業を依頼する側は、最初に打ち合わせをするだけで、その後細かい管理をしなくて済みます。

作業を依頼される側のメリットは、あらかじめ作業時間や難易度など全体のスケジュールを把握しやすくなる点です。

一方で最大のデメリットは、成果物が終盤にならないと見えてこないことです。

そのため、ようやく成果物が出来ても、要望の内容からずれがあった場合、工程をさかのぼって修正しなければならず、大きな二度手間が発生します。IT業界では、これを「手戻り」と呼んでいます。

ウォーターフォールモデルは、まさに滝から水が落ちるように、工程を最短距離で突き進み、基本的に手戻りすることは想定していません。

そのため、このモデルを採用するときは、最初の打ち合わせで依頼する側とされる側の間で作業の完成イメージを高い精度で共有しておく必要があります。

イメージの共有ができない状態で、ウォーターフォールモデルで作業が走り始めてしまうと、後になって大きな痛手を被る可能性が大きくなってしまいます。

普段から仕事の進め方などが分かっていて、「阿吽の呼吸」が通じる相手であればウォーターフォールモデルでも差支えありません。

しかし、相手の作業の進め方や理解度がわからない場合は、この手法はおすすめできません。

プロトタイピングモデル

「ウォーターフォールモデルで仕事を進めるのは、後々リスクが大きくなるかもしれない」。

そうした発想から生まれたのが「プロトタイピングモデル」です。

プロトタイピングモデルの最大の特徴は、打ち合わせをしたらまず試作品をつくってみる点です。

作業を依頼された側が早い段階で試作品をつくり、作業を依頼する側と共有することで、完成イメージのずれを早めに解消し作業の手戻りを少なくすることができます。

このモデルを採用することで、作業を依頼する側は、抽象的な言葉で完成イメージを共有するのではなく、試作品を通じて具体的な要望や改善点を伝えることができます。

一方で、作業を依頼される側にとっては、作業の終盤で大きな手戻りが発生するリスクを小さくすることができます。

その分、全体の作業スケジュールを作業者自身が把握しにくいというデメリットもあります。

スパイラルモデル

最後に紹介するのはスパイラルモデルです。

プロトタイピングモデルで試作品を早めに作ることで、作業を依頼する側と依頼される側の認識のずれを小さくすることができますが、早めに試作品をつくることがそもそも難しい仕事もあります。

そうした仕事でもなるべく手戻りを少なくしたい。そのために提案されたのはスパイラルモデルです。

このモデルは言ってみれば、部分ごとにウォーターフォールモデルを繰り返し、部分的に少しずつ完成させていく進め方です。

このモデルであれば、全体の試作品をつくるのが難しい仕事でも、作業を依頼する側と依頼される側双方が徐々に成果物を確認しながら作業を進めることができます。

実際の業務に生かすポイント

ここまで3つの開発手法についてメリットとデメリットを確認してきました。

もちろん、システム開発以外の場面では事前に「ウォーターフォールでいこう」、「プロトタイピングでやろう」などと事前に決めて仕事にとりかかることは少ないと思います。

そのため、実際のビジネスシーンでは、作業を依頼した時、依頼された時、自らが意識的にどのモデルで作業を進めるのが適切か判断することが必要になります。

作業を依頼された側にとって、最もやりやすいのはウォーターフォールモデルかもしれません。自分のスケジュールで作業ができますし、途中でとやかく言われることもないからです。

しかし、作業を依頼した側にとって安心できるのはプロトタイピングモデルかスパイラルモデルです。作業の締め切り間際になって、初めて成果物を見せられるのは時に大きなリスクになります。

例えば、作業を依頼された側がウォーターフォールモデルで進めようとしていれば、作業を依頼した側は積極的に声をかけて進捗状況を把握しプロトタイピングモデルに近づけていく。

また、作業を依頼した側が最初の打ち合わせ以外に何も関与してこなければ（ウォーターフォールモデル）、依頼された側から途中成果を報告してフィードバックを求める（プロトタイピングモデル）。

どのモデルが良いという訳ではなく、３つのモデルを状況に応じて柔軟に組み合わせていくことが、効率的で完成度の高い仕事につながります。