【体験談】SEの業務を分かりやすく解説！BtoBシステム開発の流れは？

現代社会はITなしでは成り立たないほど、私たちの周りはシステムで溢れかえっています。システムを利用しないで過ごしたければ、電気の通らない山や無人島にでも行かない限りほぼ不可能でしょう。

では、日頃から利用しているシステムはどのように作られているのでしょうか。システム開発会社が企業に向けて開発するシステム（＝BtoBシステム）に焦点を当てて、これらがどのようにして開発されていくのかを私の実体験を交えながらご紹介していきます。

難しいIT用語も出てきますがなるべくわかりやすく解説していきますので、ぜひ参考にしてみてください。

BtoBシステムとは
システムで採用される開発手法
ウォーターフォールモデルのメリット・デメリット

BtoBシステムとは

冒頭でもさっそく出てきましたが、BtoBシステムの意味から見ていきましょう。

一般的にBtoBというのは“Business to Business”の略で、企業から企業へ提供される商品やサービスのことを指します。たとえば、オフィスビルを持っている企業に対して清掃サービスを提供するビルの清掃業はBtoBビジネスといえます。

システムの話に戻すと、BtoBシステムというのはシステム開発会社が企業相手にシステムを開発・販売することです。顧客管理システムや物流管理システムなどが代表的な例でしょう。こういったBtoBシステムは複雑かつ大規模なものになりやすく、それでも企業は莫大なコストをかけてシステム開発を行います。

なぜシステム化を行うのか

システム開発というのはとにかくコストがかかります。規模にもよりますが、小さなもので数百万、大きなものになると億単位の金額が動きます。それでも企業は業務を効率化し、利益を最大化するためにシステム化を検討します。それはなぜか。もちろん、対価としてシステム化に成功すれば多大な恩恵を受けることができるためです。

システム化で自社の業務を人ではなく機械に任せることで、無駄なオペレーションや人的ミスを減らすことができます。たとえば、これまで10人で行っていたAという作業が1人でできるようになります。9人分の人員コストが節約できるわけです。この9人に毎月20万円の給料が発生していた場合、1ヶ月で180万円、1年で2160万円の節約になるのです。

たったの9人でもこれだけの効果があるのですから、従業員が多い企業であるほどシステム化の恩恵は大きなものになります。

なぜシステム開発会社が必要なのか

これだけ効果的なものであれば、わざわざ外注して高額なシステムを作らなくても、自社で開発すればいいではないか、という人もいます。しかし、基本的にシステム化要件というのは散発的に発生するものです。次々とシステム化を進めるのはリスクも伴います。

それだけでなく、システム開発会社はたくさんのシステムを開発することによって技術力やノウハウが蓄積されています。これによって常に最新の技術を使った効率的なシステム開発が期待できるのです。

たまに発生するシステム開発要件のためにSE（システムエンジニア）を雇っておくというのは極めて効率が悪いです。ちなみに、一般的にSEを1人働かせると80万円かかるというのが相場です。この金額の人材を何もせずに遊ばせておくのは無駄だということが分かると思います。

その証拠にあの世界のトヨタでさえ、自社でSEを雇っていません（システム開発をする子会社はあります）。自社で社内SEを雇っている企業もありますが、社内SEは基本的に少数精鋭であり、大規模なシステム開発には適していません。

では、システム開発会社はどのような方法でシステムを開発していくのでしょうか。

システムで採用される開発手法

システム開発手法というのはいくつもありますが、一般的なシステム開発では「ウォーターフォールモデル」と呼ばれる開発手法が採用されます。

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

ウォーターフォールモデルとは、上から下に流れるように作業工程が決まっている手法です。一度流れ始めたら後戻りすることを想定しないため、「ウォーターフォール＝滝」という名前がついています。

各工程を一歩ずつ丁寧に進めることで品質を確保し、顧客が求めるシステムを確実に提供する開発手法といえます。ただし、その作業工程の性質上、問題が起こると柔軟に対応しにくいという難点も抱えています。

＜SEこぼれ話＞
私が関わったシステムはほぼ100％この手法で開発されていました。もっとも、私が入社した当初は現在ほど多彩な開発モデルは出ていなかったというのもあります。Web業界やアプリ業界で「アジャイル」という手法が騒がれだしたのもしばらく経ってからでしたね。

続いてウォーターフォールモデルの各開発工程を確認していきましょう。

ウォーターフォールモデルの工程

ウォーターフォールモデルでは大きく9つに分類することができます。基本的に1つの工程は前の段階の工程が「完璧である」ことを前提に進めていきます。顧客の要求をすべて満たしているのか、考慮漏れはないか、万が一変更があった場合に対応しやすい作りになっているかを何度も確認し、石橋を叩きながら進めていくのが大きな特徴です。

それぞれの工程は以下のように分類できます。

要求分析
基本設計
機能設計
詳細設計
実装（コーディング）
単体テスト
結合テスト
システムテスト
受け入れテスト

各工程をみていきましょう。

１．要求分析

顧客が抱える問題や課題をヒアリングし、顧客がどのような要求を持っているのかを分析する工程です。要求には表面的なものから潜在的なものまでさまざまで、ここでいかに顧客が求めるものを引き出せるかがエンジニアの腕の見せどころでもあります。

顧客が求めるシステムはどういうものか、どういうシステムなら顧客の問題を解決できるのかを分析していきます。ここを曖昧なまま次の工程に進めてしまうと、後から別の要求が出てきてしまい、ウォーターフォールモデルで一番避けたい「仕様変更」が発生してしまいます。

＜経験談＞
要求分析で最もネックなのは顧客の要望を上手く引き出すことです。要求分析という名前がついていますが、経験豊富なSEになると、顧客から話を聞く前からどういうシステムが最適なのかアタリをつけて話せるようになります。そして、相手の望む機能と、こちらが開発しやすい機能を上手くすり合わせ（誘導し）ながら着地させるのです。
要件分析では、開発スキルがあるだけではダメで、相手の要望を引き出し、こちらの提案を納得させるコミュニケーション能力と、それに裏付けされた知識と経験が求められます。

２．基本設計

顧客の要求を引き出せたら、システムの基本設計に移ります。基本設計というのは、外側から客観的に見たときにシステムがどのような動きをするのかを設計する工程です。外部設計とも呼ばれます。たとえば、『画面にテキストボックスとボタンがあり、名前と生年月日を入力して「登録」ボタンを押すと、入力したデータが保存される』といったシステムの動きを定義していきます。

＜経験談＞
設計では理系よりも文系よりの能力が求められます。つまり、文章を書く能力です。機能の特徴を端的かつ明確に記載する。それぞれのドキュメントの章立て、フォントや行間といった読みやすさにも配慮が必要になります。表やグラフを用いてわかりやすくする、用語・主語を統一することで読み手を混乱させないようにするなどです。
これらはすべて「曖昧さを回避する」というシステム開発の基本的な考えに基づいています。設計書を読んだ人が勘違いして予期せぬシステムを作ってしまわないようにするSEの知恵といえるでしょう。
これらのスキルは文章を書くようになった現在でも私の血肉になっています。

３．機能設計

システム全体を大中小の機能（モジュール）ごとに分割し、それぞれの動作やロジック、データの持ち方などを定義します。画面がどのように遷移するのか、具体的にいえば、入力画面→登録確認画面→登録完了画面のような形で画面が移り変わっていく流れや、画面ごとにできる機能の一覧などを設計書にまとめていきます。

＜経験談＞
機能設計になってくるとかなり図や記号を使ったシステム的なドキュメントになってきます。私の会社はドキュメントをExcelで作ることが多かったので、とにかくExcelの使い方が上達しました。さまざまなショートカットを覚えて効果的にドキュメント作成をできるようになりましたし、そのスキルは今でも私の仕事で役立っています。

４．詳細設計

機能設計で分割・定義した機能（モジュール）の詳細を設計していきます。上記の設計が全体像を表すのに対し、詳細設計では細かく分割された機能単位で表します。ここまで来ると具体的にプログラムでどのように実装していくのかが見えてくるレベルになります。

ちなみに、あまりに開発時間が短くて余裕がないプロジェクトだと詳細設計をしない状態、つまり機能設計まで行って（下手すると基本設計のみで）プログラミングに入ることもありました。こういうプロジェクトは高い確率で炎上します。

＜経験談＞
ある程度、作り慣れたフレームワークでの開発になると、短期で納品するために詳細設計がスキップされるケースがありました。しかし、設計書を残さないと、何か障害が発生したときにプログラムを組んだ人にしかわからなくなってしまうのです。もちろん、プログラムを解析して原因を解明することも可能ではありますが、時間がかかります。また、「なぜこのようになってしまったのか」という根本原因がわからない状態になります。
設計書というのは作成するだけでも多大な時間と労力がかかるものです。しかし、何かの理由でメンバーが辞めてしまった、異動してしまった場合に、ほかのメンバーが見てもスムーズに状況が把握するために重要なものでもあるのです。

５．実装（コーディング）

詳細設計書を元にプログラムに落とし込んでいく工程です。いわゆるシステム開発の山場であり、一番プロジェクトの人員が膨らむ工程でもあります。一般的には詳細設計までは小規模のチームで進めていき、実装工程からメンバーを大量に投入します。

ウォーターフォールモデルでは工程ごとに人員の増減を調整できるため、大規模なシステムでも効率的に予算を組むことができるという特徴があります。

＜経験談＞
理想的な設計書というのは「日本語をそのままプログラム言語に書き直せばOK」というレベルまで作り込まれた設計書です。私の場合、そのレベルまで作り込まれた設計書を見たのはただの1度だけでした。
プログラミングはとにかく経験がものをいいます。しかし、誰もがハイレベルなプログラミングスキルを持っているとは限らない中で、一定の品質を保つにはやはり設計書が重要になるのです。
私が新人のときに大炎上したプロジェクトがあるのですが、クラス設計やコードレビューを行っておらず、私の経験が浅かったということもあり、1クラスで1万行を超えるソースコードを書いたことがあります。
「クラス」というのはシステムの部品のことです。一般的に1クラスのソースは500行くらいに収めるのが望ましいとされていますので、私の書いたコードがいかに異常であったかがわかるかと思います（当時はほかに方法がなかったのです。）

６．単体テスト

実装（コーディング）が終わったら、今度はそのプログラムが設計書どおりに動くのかをテストします。モジュール単体ごとにテストをするので「単体テスト」です。単体テストには単体テスト仕様書というものがあり、そのテスト項目をチェックしていき、バグがあれば修正します。すべて合格して初めて単体テストが完了です。

＜経験談＞
単体テストというのは、基本的に実装した人が行うようにします。自分で組んだプログラムですから、責任を持って自分でテストして品質を確かめておくのが目的ですが、「そのモジュールを作ってテストまでしたのは誰か」という責任の所在を明確にできるという面もあります。
しかし、大規模なプロジェクトになると、単体テストは新人が担当する業務にしていることもありました。単体テストというのは比較的誰でも行うことができる作業ですので、テストを行い、バグがあれば報告するという作業は新人にはうってつけなのです。
小さな会社のSEだと、下請けの下請け（孫受け）になってしまってどこのプロジェクトに入ってもテストしかできない、みたいなこともあるそうです。こうなってしまうとスキルを磨くこともできず、単純作業のみになってしまいキャリアを台無しにしてしまうので避けたほうが良いと思います。

７．結合テスト

単体テストが終われば、今度はそれぞれのモジュールを結合させて正しく動くかをテストします。単体テストではOKでも、モジュールを組み合わせることで新たなバグが見つかるので、必要に応じて修正を加えていきます。ちなみに、モジュールを組み合わせるため、テストパターンは単体テストよりも多くなりますし、複雑になります。

＜経験談＞
結合テストは一番バグが出る工程です。バグがたくさん出る＝悪いと考えるかもしれませんが、バグがたくさん出た＝それだけ品質が上がっているという考え方もできます。ある会社の品質の指標では、「◯◯行のプログラムあたり、☓☓件のバグが出ないといけない」といった基準まで設けられているほどです。一応、これまでの統計から算出された数字なのでしょうけど、個人的にはバカバカしい基準だと思っていました。
その基準に達するために、わざとバグを仕込んでいた人もいたからです。なんのためにテストをしているのかを見失うとこういったくだらない基準ばかりに囚われるようになってしまうのかもしれません。

８．システムテスト

結合テストが完了すれば、いよいよシステムとして利用できるのかをチェックしていきます。登録→閲覧→変更→削除といった複雑なシナリオを作り、最終的に画面に表示されるデータが想定されたものになっているのかを確認します。シナリオテストとも呼ばれます。数十、多いときは数百パターンにおよぶシナリオを用意して行うことで品質を高めていきます。これが終わればいよいよ納品となり、開発は終了です。

＜経験談＞
システムテストまでくればゴールはすぐそこまで来ているのですが、これがなかなかの曲者です。システムテストになると、バグもより高度になっていきます。複雑に絡み合った部品のどこにバグがあって、それがどこまで影響を及ぼしているのかを考えながら修正しないといけないためです。修正には細心の注意が求められます。
システムテストが完了しなくて徹夜したことも何度もありますし、走っても走ってもたどり着かない蜃気楼のように感じることがありました。ここが一番しんどい工程かもしれません。

各開発工程を簡単に解説しましたが、ウォーターフォールモデルはその特性から、メリットとデメリットがあります。

ウォーターフォールモデルのメリット・デメリット

ウォーターフォールモデルのメリット・デメリットはいくつかあります。それぞれ見ていきましょう。

＜メリット＞

 成果物と報酬の関係が明確

システム開発ではシステム本体だけが納品物ではありません。開発工程で作成されたドキュメント（設計書・仕様書）などすべてが納品物となります。こういったドキュメント類を納品することは、きちんと仕事をしているという証明にもなりますし、顧客も納得したうえで報酬を支払うことができるのです。

 計画を立てやすい

各工程でやることと成果物（設計書・仕様書・システム本体）がはっきりしているので、開発スケジュールが立てやすいのも特徴です。計画が立てやすいということはコストを計算しやすいということを意味しますので、顧客に対して納得感のある予算で提案することにも繋がります。

 品質を確保しやすい

設計段階では顧客が求める要求＝仕様を定め、それに基づいた設計書を作成します。顧客は設計書ができた段階で確認を行い、そこで承認を得たうえで次の工程に進むことになるので、品質を確保しやすい開発手法といえます。要求を伝えたまま開発を任せていたら、完成したシステムはまったく違うものだった！ということになりにくいのは双方にとって大きなメリットといえるでしょう。

 スケジュール管理がしやすい

ウォーターフォールモデルでは各工程での作業がはっきりしているだけでなく、それぞれを分業で進めやすいという特徴があります。そのため、プロジェクトメンバーに作業を割り当ててスケジュールの進捗を管理しやすいのです。たとえば、Aさんの作業が遅れているからBさんと一緒に進めてもらう、ということも容易になります。

 大人数での開発に向いている

システム開発というのは大きなものになると、数百人規模のプロジェクトになることも珍しくありません。だからといって初めから数百人のエンジニアを確保するということはなく、どのプロジェクトも最初は数人～数十人でスタートします。というのも、要求分析や基本設計段階では、そこまでの人手は必要ないためです。

最初から数百人のエンジニアを用意していても、いたずらに遊ばせてしまうだけで、大赤字になってしまいます。さきほど紹介したように、エンジニア1人を確保するのに平均で80万円が必要ですから、100人遊ばせたらそれだけで1ヶ月で8,000万円が無駄になるわけです。

本格的に人手が必要になるのは実装工程に入ってからですので、それまでは別の仕事をしてもらう、もしくは外注でエンジニアを確保するというのが一般的です。このように、工程に合わせてメンバーを調整しやすいのもウォーターフォールモデルのメリットです。

＜デメリット＞

 後から変更ができない

ウォーターフォールモデルは滝のように上から下に工程が落ちていく開発モデルです。そのため、途中で機能を変更したりすると大幅な手戻り（やり直し）が発生します。単純にプログラムを変えればいいだけではないかと思われるかもしれませんが、プログラムだけ変えると設計段階で作成したドキュメントとの整合性が取れなくなるのです。

また、システムの動きが変わってしまうため、テスト仕様書などもすべて書き直さなくてはいけません。ウォーターフォールモデルでは「仕様変更」は非常にリスクを伴います。私もこの仕様変更で何度も大変な目にあいました。

 作成するドキュメントが多い

ウォーターフォールモデルではたくさんのドキュメントを作成する必要があります。要件定義書、基本設計書、機能設計書、単体・結合・システムテスト仕様書を作成するには実装工程に匹敵する時間を要することも珍しくありません。

こうしてみるとそこまで数がないように思われるかもしれませんが、上記のドキュメント名は総称です。詳細に書けば機能設計書だけでもこれだけの種類があります。